spec-up-t 0.11.1 → 0.11.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (901) hide show
  1. package/package.json +1 -1
  2. package/src/get-xrefs-data.js +1 -0
  3. package/.history/.gitignore_20240529170917 +0 -107
  4. package/.history/.gitignore_20240606150429 +0 -108
  5. package/.history/.gitignore_20240606191801 +0 -108
  6. package/.history/.gitignore_20240607110342 +0 -109
  7. package/.history/.gitignore_20240607142705 +0 -108
  8. package/.history/.gitignore_20240607142706 +0 -108
  9. package/.history/.gitignore_20240609141423 +0 -108
  10. package/.history/.gitignore_20240609141451 +0 -108
  11. package/.history/.gitignore_20240609141501 +0 -109
  12. package/.history/.gitignore_20240609142401 +0 -109
  13. package/.history/allMatches copy_20240601213017.json +0 -18
  14. package/.history/allMatches copy_20240601213051.json +0 -20
  15. package/.history/allMatches copy_20240602135208.json +0 -32
  16. package/.history/allMatches_20240602125822.json +0 -32
  17. package/.history/allMatches_20240602135405.json +0 -32
  18. package/.history/allMatches_20240602135952.json +0 -32
  19. package/.history/assets/css/addAnchorsToTerms_20240608220511.css +0 -9
  20. package/.history/assets/css/addAnchorsToTerms_20240608221010.css +0 -9
  21. package/.history/assets/css/search_20240531083123.css +0 -180
  22. package/.history/assets/css/search_20240531103506.css +0 -178
  23. package/.history/assets/css/search_20240531105144.css +0 -106
  24. package/.history/assets/css/search_20240531105324.css +0 -178
  25. package/.history/assets/css/xrefs_20240608224957.css +0 -16
  26. package/.history/assets/css/xrefs_20240608225047.css +0 -2
  27. package/.history/assets/css/xrefs_20240608225112.css +0 -10
  28. package/.history/assets/css/xrefs_20240608225143.css +0 -18
  29. package/.history/assets/css/xrefs_20240608230229.css +0 -16
  30. package/.history/assets/js/addAnchorsToTerms_20240608220500.js +0 -19
  31. package/.history/assets/js/addAnchorsToTerms_20240609144843.js +0 -18
  32. package/.history/assets/js/addAnchorsToTerms_20240609144845.js +0 -18
  33. package/.history/assets/js/addAnchorsToTerms_20240609144847.js +0 -17
  34. package/.history/assets/js/backToTop_20240529170917.js +0 -49
  35. package/.history/assets/js/backToTop_20240531091120.js +0 -49
  36. package/.history/assets/js/edit-term-buttons_20240606152249.js +0 -27
  37. package/.history/assets/js/edit-term-buttons_20240609075155.js +0 -49
  38. package/.history/assets/js/edit-term-buttons_20240609075210.js +0 -49
  39. package/.history/assets/js/edit-term-buttons_20240609075515.js +0 -58
  40. package/.history/assets/js/edit-term-buttons_20240609075522.js +0 -58
  41. package/.history/assets/js/edit-term-buttons_20240609075556.js +0 -55
  42. package/.history/assets/js/edit-term-buttons_20240609075601.js +0 -48
  43. package/.history/assets/js/edit-term-buttons_20240609075816.js +0 -48
  44. package/.history/assets/js/edit-term-buttons_20240609080158.js +0 -49
  45. package/.history/assets/js/edit-term-buttons_20240609080219.js +0 -49
  46. package/.history/assets/js/edit-term-buttons_20240609080438.js +0 -49
  47. package/.history/assets/js/edit-term-buttons_20240609080526.js +0 -49
  48. package/.history/assets/js/edit-term-buttons_20240609090024.js +0 -49
  49. package/.history/assets/js/edit-term-buttons_20240609144730.js +0 -47
  50. package/.history/assets/js/fetch-commit-hashes_20240602160837.js +0 -49
  51. package/.history/assets/js/fetch-commit-hashes_20240602161039.js +0 -22
  52. package/.history/assets/js/fetch-commit-hashes_20240602161142.js +0 -24
  53. package/.history/assets/js/fetch-commit-hashes_20240602161708.js +0 -26
  54. package/.history/assets/js/fetch-commit-hashes_20240602161715.js +0 -26
  55. package/.history/assets/js/fetch-commit-hashes_20240602162233.js +0 -33
  56. package/.history/assets/js/fetch-commit-hashes_20240602162610.js +0 -39
  57. package/.history/assets/js/fetch-commit-hashes_20240602162620.js +0 -41
  58. package/.history/assets/js/fetch-commit-hashes_20240602162633.js +0 -23
  59. package/.history/assets/js/fetch-commit-hashes_20240602162707.js +0 -46
  60. package/.history/assets/js/fetch-commit-hashes_20240602162754.js +0 -46
  61. package/.history/assets/js/fetch-commit-hashes_20240602162800.js +0 -47
  62. package/.history/assets/js/fetch-commit-hashes_20240602162850.js +0 -51
  63. package/.history/assets/js/fetch-commit-hashes_20240602165658.js +0 -52
  64. package/.history/assets/js/fetch-commit-hashes_20240602165838.js +0 -55
  65. package/.history/assets/js/fetch-commit-hashes_20240602165843.js +0 -55
  66. package/.history/assets/js/fetch-commit-hashes_20240602170109.js +0 -57
  67. package/.history/assets/js/fetch-commit-hashes_20240602170146.js +0 -57
  68. package/.history/assets/js/fetch-commit-hashes_20240602170317.js +0 -59
  69. package/.history/assets/js/fetch-commit-hashes_20240602171009.js +0 -59
  70. package/.history/assets/js/fetch-commit-hashes_20240602171632.js +0 -60
  71. package/.history/assets/js/fetch-commit-hashes_20240602171739.js +0 -67
  72. package/.history/assets/js/fetch-commit-hashes_20240602172039.js +0 -73
  73. package/.history/assets/js/fetch-commit-hashes_20240602172044.js +0 -73
  74. package/.history/assets/js/fetch-commit-hashes_20240602172815.js +0 -73
  75. package/.history/assets/js/fetch-commit-hashes_20240602172942.js +0 -78
  76. package/.history/assets/js/fetch-commit-hashes_20240602173109.js +0 -78
  77. package/.history/assets/js/fetch-commit-hashes_20240602173309.js +0 -80
  78. package/.history/assets/js/fetch-commit-hashes_20240602173324.js +0 -80
  79. package/.history/assets/js/fetch-commit-hashes_20240602173441.js +0 -80
  80. package/.history/assets/js/fetch-commit-hashes_20240602173531.js +0 -80
  81. package/.history/assets/js/fetch-commit-hashes_20240602192722.js +0 -82
  82. package/.history/assets/js/fetch-commit-hashes_20240603121015.js +0 -83
  83. package/.history/assets/js/fetch-commit-hashes_20240603121356.js +0 -83
  84. package/.history/assets/js/fetch-commit-hashes_20240603121508.js +0 -83
  85. package/.history/assets/js/fetch-commit-hashes_20240603122953.js +0 -83
  86. package/.history/assets/js/fetch-commit-hashes_20240603123007.js +0 -83
  87. package/.history/assets/js/fetch-commit-hashes_20240603123009.js +0 -83
  88. package/.history/assets/js/fetch-commit-hashes_20240603123246.js +0 -83
  89. package/.history/assets/js/fetch-commit-hashes_20240603123253.js +0 -83
  90. package/.history/assets/js/fetch-commit-hashes_20240603123324.js +0 -83
  91. package/.history/assets/js/fetch-commit-hashes_20240603123525.js +0 -83
  92. package/.history/assets/js/fetch-commit-hashes_20240603125354.js +0 -65
  93. package/.history/assets/js/fetch-commit-hashes_20240603125404.js +0 -63
  94. package/.history/assets/js/fetch-commit-hashes_20240603125412.js +0 -62
  95. package/.history/assets/js/fetch-commit-hashes_20240603132635.js +0 -64
  96. package/.history/assets/js/fetch-commit-hashes_20240603133045.js +0 -64
  97. package/.history/assets/js/fetch-commit-hashes_20240603174102.js +0 -73
  98. package/.history/assets/js/fetch-commit-hashes_20240603174238.js +0 -77
  99. package/.history/assets/js/fetch-commit-hashes_20240603174410.js +0 -77
  100. package/.history/assets/js/fetch-commit-hashes_20240603174423.js +0 -77
  101. package/.history/assets/js/fetch-commit-hashes_20240603174930.js +0 -77
  102. package/.history/assets/js/fetch-commit-hashes_20240603175018.js +0 -77
  103. package/.history/assets/js/fetch-commit-hashes_20240603175102.js +0 -78
  104. package/.history/assets/js/fetch-commit-hashes_20240603175118.js +0 -78
  105. package/.history/assets/js/fetch-commit-hashes_20240603175215.js +0 -78
  106. package/.history/assets/js/fetch-commit-hashes_20240603175536.js +0 -78
  107. package/.history/assets/js/fetch-commit-hashes_20240603195342.js +0 -78
  108. package/.history/assets/js/fetch-commit-hashes_20240603195351.js +0 -78
  109. package/.history/assets/js/fetch-commit-hashes_20240603195629.js +0 -78
  110. package/.history/assets/js/fetch-commit-hashes_20240603195641.js +0 -78
  111. package/.history/assets/js/fetch-commit-hashes_20240603195716.js +0 -78
  112. package/.history/assets/js/fetch-commit-hashes_20240603195854.js +0 -79
  113. package/.history/assets/js/fetch-commit-hashes_20240603195938.js +0 -87
  114. package/.history/assets/js/fetch-commit-hashes_20240603195940.js +0 -87
  115. package/.history/assets/js/fetch-commit-hashes_20240603201055.js +0 -88
  116. package/.history/assets/js/fetch-commit-hashes_20240603201136.js +0 -88
  117. package/.history/assets/js/fetch-commit-hashes_20240603201152.js +0 -88
  118. package/.history/assets/js/fetch-commit-hashes_20240603202306.js +0 -91
  119. package/.history/assets/js/fetch-commit-hashes_20240603202316.js +0 -91
  120. package/.history/assets/js/fetch-commit-hashes_20240603202454.js +0 -91
  121. package/.history/assets/js/fetch-commit-hashes_20240603202632.js +0 -91
  122. package/.history/assets/js/fetch-commit-hashes_20240603202732.js +0 -91
  123. package/.history/assets/js/fetch-commit-hashes_20240603202824.js +0 -91
  124. package/.history/assets/js/search_20240529170917.js +0 -300
  125. package/.history/assets/js/search_20240531092328.js +0 -301
  126. package/.history/assets/js/show-commit-hashes copy_20240608214152.js +0 -87
  127. package/.history/assets/js/show-commit-hashes_20240603202823.js +0 -91
  128. package/.history/assets/js/show-commit-hashes_20240607211151.js +0 -91
  129. package/.history/assets/js/show-commit-hashes_20240607211159.js +0 -92
  130. package/.history/assets/js/show-commit-hashes_20240607211207.js +0 -92
  131. package/.history/assets/js/show-commit-hashes_20240607211637.js +0 -93
  132. package/.history/assets/js/show-commit-hashes_20240607211642.js +0 -93
  133. package/.history/assets/js/show-commit-hashes_20240607212344.js +0 -94
  134. package/.history/assets/js/show-commit-hashes_20240608111144.js +0 -95
  135. package/.history/assets/js/show-commit-hashes_20240608173322.js +0 -95
  136. package/.history/assets/js/show-commit-hashes_20240608182243.js +0 -95
  137. package/.history/assets/js/show-commit-hashes_20240608184558.js +0 -95
  138. package/.history/assets/js/show-commit-hashes_20240608184653.js +0 -95
  139. package/.history/assets/js/show-commit-hashes_20240608184937.js +0 -103
  140. package/.history/assets/js/show-commit-hashes_20240608184949.js +0 -103
  141. package/.history/assets/js/show-commit-hashes_20240608185150.js +0 -99
  142. package/.history/assets/js/show-commit-hashes_20240608191345.js +0 -99
  143. package/.history/assets/js/show-commit-hashes_20240608192245.js +0 -98
  144. package/.history/assets/js/show-commit-hashes_20240608192644.js +0 -98
  145. package/.history/assets/js/show-commit-hashes_20240608192806.js +0 -96
  146. package/.history/assets/js/show-commit-hashes_20240608192829.js +0 -94
  147. package/.history/assets/js/show-commit-hashes_20240608214252.js +0 -90
  148. package/.history/assets/js/show-commit-hashes_20240608214302.js +0 -89
  149. package/.history/assets/js/show-commit-hashes_20240608214320.js +0 -78
  150. package/.history/assets/js/show-commit-hashes_20240608214600.js +0 -78
  151. package/.history/assets/js/show-commit-hashes_20240608225341.js +0 -77
  152. package/.history/assets/js/show-commit-hashes_20240608225536.js +0 -77
  153. package/.history/assets/js/show-commit-hashes_20240608230124.js +0 -77
  154. package/.history/assets/js/show-commit-hashes_20240608230156.js +0 -77
  155. package/.history/assets/js/show-commit-hashes_20240608230432.js +0 -77
  156. package/.history/assets/js/show-commit-hashes_20240609075424.js +0 -77
  157. package/.history/assets/js/show-commit-hashes_20240609075430.js +0 -70
  158. package/.history/assets/js/show-commit-hashes_20240609075435.js +0 -70
  159. package/.history/config-repos_20240601110401.json +0 -12
  160. package/.history/config-repos_20240602140026.json +0 -12
  161. package/.history/config-repos_20240602192212.json +0 -14
  162. package/.history/config-repos_20240602192312.json +0 -19
  163. package/.history/config-repos_20240602192337.json +0 -19
  164. package/.history/config-repos_20240602212639.json +0 -19
  165. package/.history/config-repos_20240602212659.json +0 -18
  166. package/.history/config-repos_20240602212843.json +0 -18
  167. package/.history/config-repos_20240602215004.json +0 -25
  168. package/.history/config-repos_20240602221921.json +0 -21
  169. package/.history/config-repos_20240602221925.json +0 -19
  170. package/.history/config-repos_20240602222038.json +0 -19
  171. package/.history/get-commit-hashes_20240531120832.js +0 -0
  172. package/.history/get-commit-hashes_20240531121058.js +0 -5
  173. package/.history/get-commit-hashes_20240531121116.js +0 -7
  174. package/.history/get-commit-hashes_20240531121754.js +0 -8
  175. package/.history/get-commit-hashes_20240531121858.js +0 -9
  176. package/.history/get-commit-hashes_20240531121919.js +0 -9
  177. package/.history/get-commit-hashes_20240531122001.js +0 -11
  178. package/.history/get-commit-hashes_20240531122029.js +0 -11
  179. package/.history/get-commit-hashes_20240531122213.js +0 -24
  180. package/.history/get-commit-hashes_20240531122929.js +0 -80
  181. package/.history/get-commit-hashes_20240531123005.js +0 -80
  182. package/.history/get-commit-hashes_20240531123311.js +0 -80
  183. package/.history/get-commit-hashes_20240531123318.js +0 -81
  184. package/.history/get-commit-hashes_20240531123327.js +0 -81
  185. package/.history/get-commit-hashes_20240531123516.js +0 -82
  186. package/.history/get-commit-hashes_20240531152007.js +0 -83
  187. package/.history/get-commit-hashes_20240531152011.js +0 -84
  188. package/.history/get-commit-hashes_20240531152126.js +0 -88
  189. package/.history/get-commit-hashes_20240531153027.js +0 -89
  190. package/.history/get-commit-hashes_20240531153046.js +0 -89
  191. package/.history/get-commit-hashes_20240531153155.js +0 -90
  192. package/.history/get-commit-hashes_20240531153200.js +0 -90
  193. package/.history/get-commit-hashes_20240531153244.js +0 -90
  194. package/.history/get-commit-hashes_20240531153246.js +0 -90
  195. package/.history/get-commit-hashes_20240531153324.js +0 -90
  196. package/.history/get-commit-hashes_20240531153358.js +0 -90
  197. package/.history/get-commit-hashes_20240531153415.js +0 -89
  198. package/.history/get-commit-hashes_20240531153505.js +0 -91
  199. package/.history/get-commit-hashes_20240531153520.js +0 -92
  200. package/.history/get-commit-hashes_20240531153603.js +0 -93
  201. package/.history/get-commit-hashes_20240531153604.js +0 -93
  202. package/.history/get-commit-hashes_20240531153649.js +0 -94
  203. package/.history/get-commit-hashes_20240531153652.js +0 -94
  204. package/.history/get-commit-hashes_20240531153812.js +0 -95
  205. package/.history/get-commit-hashes_20240531153907.js +0 -96
  206. package/.history/get-commit-hashes_20240531154448.js +0 -106
  207. package/.history/get-commit-hashes_20240531154504.js +0 -106
  208. package/.history/get-commit-hashes_20240531154509.js +0 -106
  209. package/.history/get-commit-hashes_20240531154620.js +0 -106
  210. package/.history/get-commit-hashes_20240531154706.js +0 -107
  211. package/.history/get-commit-hashes_20240531154737.js +0 -107
  212. package/.history/get-commit-hashes_20240531154840.js +0 -107
  213. package/.history/get-commit-hashes_20240531154910.js +0 -107
  214. package/.history/get-commit-hashes_20240531155045.js +0 -107
  215. package/.history/get-commit-hashes_20240531160915.js +0 -108
  216. package/.history/get-commit-hashes_20240531161355.js +0 -109
  217. package/.history/get-commit-hashes_20240531161411.js +0 -108
  218. package/.history/get-commit-hashes_20240531161439.js +0 -109
  219. package/.history/get-commit-hashes_20240531161459.js +0 -108
  220. package/.history/get-commit-hashes_20240531161526.js +0 -108
  221. package/.history/get-commit-hashes_20240531161534.js +0 -109
  222. package/.history/get-commit-hashes_20240531161630.js +0 -110
  223. package/.history/get-commit-hashes_20240531161631.js +0 -110
  224. package/.history/get-commit-hashes_20240531161727.js +0 -110
  225. package/.history/get-commit-hashes_20240531161752.js +0 -110
  226. package/.history/get-commit-hashes_20240531161825.js +0 -110
  227. package/.history/get-commit-hashes_20240531161841.js +0 -110
  228. package/.history/get-commit-hashes_20240531162409.js +0 -110
  229. package/.history/get-commit-hashes_20240531162424.js +0 -110
  230. package/.history/get-commit-hashes_20240531162723.js +0 -131
  231. package/.history/get-commit-hashes_20240531162817.js +0 -131
  232. package/.history/get-commit-hashes_20240531162839.js +0 -131
  233. package/.history/get-commit-hashes_20240531163313.js +0 -157
  234. package/.history/get-commit-hashes_20240531163353.js +0 -158
  235. package/.history/get-commit-hashes_20240531163439.js +0 -160
  236. package/.history/get-commit-hashes_20240531164620.js +0 -160
  237. package/.history/get-commit-hashes_20240531164644.js +0 -160
  238. package/.history/get-commit-hashes_20240531164744.js +0 -165
  239. package/.history/get-commit-hashes_20240531164757.js +0 -165
  240. package/.history/get-commit-hashes_20240531165054.js +0 -165
  241. package/.history/get-commit-hashes_20240531165131.js +0 -166
  242. package/.history/get-commit-hashes_20240531165134.js +0 -166
  243. package/.history/get-commit-hashes_20240531165200.js +0 -166
  244. package/.history/get-commit-hashes_20240531165239.js +0 -166
  245. package/.history/get-commit-hashes_20240531165313.js +0 -166
  246. package/.history/get-commit-hashes_20240531165410.js +0 -166
  247. package/.history/get-commit-hashes_20240531165522.js +0 -171
  248. package/.history/get-commit-hashes_20240531165536.js +0 -171
  249. package/.history/get-commit-hashes_20240531181149.js +0 -173
  250. package/.history/get-commit-hashes_20240531181401.js +0 -174
  251. package/.history/get-commit-hashes_20240531181402.js +0 -174
  252. package/.history/get-commit-hashes_20240531181418.js +0 -174
  253. package/.history/get-commit-hashes_20240531181534.js +0 -175
  254. package/.history/get-commit-hashes_20240531181631.js +0 -175
  255. package/.history/get-commit-hashes_20240531181707.js +0 -175
  256. package/.history/get-commit-hashes_20240531181735.js +0 -175
  257. package/.history/get-commit-hashes_20240531181751.js +0 -175
  258. package/.history/get-commit-hashes_20240531182413.js +0 -184
  259. package/.history/get-commit-hashes_20240531182532.js +0 -184
  260. package/.history/get-commit-hashes_20240531184314.js +0 -186
  261. package/.history/get-commit-hashes_20240531184318.js +0 -186
  262. package/.history/get-commit-hashes_20240531185027.js +0 -188
  263. package/.history/get-commit-hashes_20240531185039.js +0 -188
  264. package/.history/get-commit-hashes_20240531185939.js +0 -188
  265. package/.history/get-commit-hashes_20240531190020.js +0 -189
  266. package/.history/get-commit-hashes_20240531211337.js +0 -189
  267. package/.history/get-commit-hashes_20240531211340.js +0 -189
  268. package/.history/get-commit-hashes_20240531211410.js +0 -189
  269. package/.history/get-commit-hashes_20240601074249.js +0 -190
  270. package/.history/get-commit-hashes_20240601074253.js +0 -191
  271. package/.history/get-commit-hashes_20240601074322.js +0 -191
  272. package/.history/get-commit-hashes_20240601074323.js +0 -190
  273. package/.history/get-commit-hashes_20240601081142.js +0 -190
  274. package/.history/get-commit-hashes_20240601081153.js +0 -190
  275. package/.history/get-commit-hashes_20240601081522.js +0 -187
  276. package/.history/get-commit-hashes_20240601110518.js +0 -187
  277. package/.history/get-commit-hashes_20240601110532.js +0 -187
  278. package/.history/get-commit-hashes_20240601110536.js +0 -187
  279. package/.history/get-commit-hashes_20240601112652.js +0 -192
  280. package/.history/get-commit-hashes_20240601112720.js +0 -192
  281. package/.history/get-commit-hashes_20240601112815.js +0 -192
  282. package/.history/get-commit-hashes_20240601112856.js +0 -191
  283. package/.history/get-commit-hashes_20240601112858.js +0 -193
  284. package/.history/get-commit-hashes_20240601112904.js +0 -192
  285. package/.history/get-commit-hashes_20240601113645.js +0 -206
  286. package/.history/get-commit-hashes_20240601113735.js +0 -206
  287. package/.history/get-commit-hashes_20240601113925.js +0 -215
  288. package/.history/get-commit-hashes_20240601113948.js +0 -215
  289. package/.history/get-commit-hashes_20240601113950.js +0 -215
  290. package/.history/get-commit-hashes_20240601114021.js +0 -217
  291. package/.history/get-commit-hashes_20240601114046.js +0 -217
  292. package/.history/get-commit-hashes_20240601114102.js +0 -217
  293. package/.history/get-commit-hashes_20240601114108.js +0 -217
  294. package/.history/get-commit-hashes_20240601114113.js +0 -217
  295. package/.history/get-commit-hashes_20240601115329.js +0 -217
  296. package/.history/get-commit-hashes_20240601115346.js +0 -217
  297. package/.history/get-commit-hashes_20240601115425.js +0 -217
  298. package/.history/get-commit-hashes_20240601115633.js +0 -217
  299. package/.history/get-commit-hashes_20240601120947.js +0 -217
  300. package/.history/get-commit-hashes_20240601121029.js +0 -217
  301. package/.history/get-commit-hashes_20240601121036.js +0 -217
  302. package/.history/get-commit-hashes_20240601122109.js +0 -44
  303. package/.history/get-commit-hashes_20240601122229.js +0 -46
  304. package/.history/get-commit-hashes_20240601122245.js +0 -46
  305. package/.history/get-commit-hashes_20240601122329.js +0 -45
  306. package/.history/get-commit-hashes_20240601122803.js +0 -48
  307. package/.history/get-commit-hashes_20240601160925.js +0 -48
  308. package/.history/get-commit-hashes_20240601161348.js +0 -48
  309. package/.history/get-commit-hashes_20240601162043.js +0 -49
  310. package/.history/get-commit-hashes_20240601162223.js +0 -51
  311. package/.history/get-commit-hashes_20240601162225.js +0 -51
  312. package/.history/get-commit-hashes_20240601162413.js +0 -51
  313. package/.history/get-commit-hashes_20240601164221.js +0 -43
  314. package/.history/get-commit-hashes_20240601164815.js +0 -46
  315. package/.history/get-commit-hashes_20240601173418.js +0 -42
  316. package/.history/get-commit-hashes_20240601173846.js +0 -42
  317. package/.history/get-commit-hashes_20240601194854.js +0 -42
  318. package/.history/get-commit-hashes_20240601194943.js +0 -42
  319. package/.history/get-commit-hashes_20240601200145.js +0 -46
  320. package/.history/get-commit-hashes_20240601201337.js +0 -46
  321. package/.history/get-commit-hashes_20240601202333.js +0 -44
  322. package/.history/get-commit-hashes_20240601202336.js +0 -43
  323. package/.history/get-commit-hashes_20240601202722.js +0 -48
  324. package/.history/get-commit-hashes_20240601202756.js +0 -52
  325. package/.history/get-commit-hashes_20240601202802.js +0 -52
  326. package/.history/get-commit-hashes_20240601203102.js +0 -60
  327. package/.history/get-commit-hashes_20240601203454.js +0 -69
  328. package/.history/get-commit-hashes_20240601212654.js +0 -74
  329. package/.history/get-commit-hashes_20240601213519.js +0 -74
  330. package/.history/get-commit-hashes_20240601213737.js +0 -74
  331. package/.history/get-commit-hashes_20240601214140.js +0 -74
  332. package/.history/get-commit-hashes_20240601214233.js +0 -74
  333. package/.history/get-commit-hashes_20240602082939.js +0 -88
  334. package/.history/get-commit-hashes_20240602083015.js +0 -88
  335. package/.history/get-commit-hashes_20240602083047.js +0 -88
  336. package/.history/get-commit-hashes_20240602083306.js +0 -89
  337. package/.history/get-commit-hashes_20240602083328.js +0 -89
  338. package/.history/get-commit-hashes_20240602083402.js +0 -89
  339. package/.history/get-commit-hashes_20240602083441.js +0 -89
  340. package/.history/get-commit-hashes_20240602083512.js +0 -90
  341. package/.history/get-commit-hashes_20240602083554.js +0 -91
  342. package/.history/get-commit-hashes_20240602083619.js +0 -93
  343. package/.history/get-commit-hashes_20240602083808.js +0 -94
  344. package/.history/get-commit-hashes_20240602083833.js +0 -94
  345. package/.history/get-commit-hashes_20240602083847.js +0 -94
  346. package/.history/get-commit-hashes_20240602085310.js +0 -94
  347. package/.history/get-commit-hashes_20240602085735.js +0 -89
  348. package/.history/get-commit-hashes_20240602085741.js +0 -86
  349. package/.history/get-commit-hashes_20240602085745.js +0 -90
  350. package/.history/get-commit-hashes_20240602085752.js +0 -89
  351. package/.history/get-commit-hashes_20240602091821.js +0 -126
  352. package/.history/get-commit-hashes_20240602091924.js +0 -127
  353. package/.history/get-commit-hashes_20240602092041.js +0 -128
  354. package/.history/get-commit-hashes_20240602092046.js +0 -128
  355. package/.history/get-commit-hashes_20240602093827.js +0 -133
  356. package/.history/get-commit-hashes_20240602094545.js +0 -135
  357. package/.history/get-commit-hashes_20240602094610.js +0 -137
  358. package/.history/get-commit-hashes_20240602094742.js +0 -133
  359. package/.history/get-commit-hashes_20240602095329.js +0 -135
  360. package/.history/get-commit-hashes_20240602095341.js +0 -135
  361. package/.history/get-commit-hashes_20240602095454.js +0 -139
  362. package/.history/get-commit-hashes_20240602101827.js +0 -142
  363. package/.history/get-commit-hashes_20240602112400.js +0 -144
  364. package/.history/get-commit-hashes_20240602112401.js +0 -144
  365. package/.history/get-commit-hashes_20240602112408.js +0 -144
  366. package/.history/get-commit-hashes_20240602112656.js +0 -145
  367. package/.history/get-commit-hashes_20240602112721.js +0 -145
  368. package/.history/get-commit-hashes_20240602113021.js +0 -151
  369. package/.history/get-commit-hashes_20240602113224.js +0 -148
  370. package/.history/get-commit-hashes_20240602113231.js +0 -131
  371. package/.history/get-commit-hashes_20240602113240.js +0 -127
  372. package/.history/get-commit-hashes_20240602113246.js +0 -126
  373. package/.history/get-commit-hashes_20240602113253.js +0 -125
  374. package/.history/get-commit-hashes_20240602113300.js +0 -102
  375. package/.history/get-commit-hashes_20240602121420.js +0 -117
  376. package/.history/get-commit-hashes_20240602121813.js +0 -118
  377. package/.history/get-commit-hashes_20240602121827.js +0 -118
  378. package/.history/get-commit-hashes_20240602121845.js +0 -118
  379. package/.history/get-commit-hashes_20240602121902.js +0 -118
  380. package/.history/get-commit-hashes_20240602121906.js +0 -118
  381. package/.history/get-commit-hashes_20240602122001.js +0 -121
  382. package/.history/get-commit-hashes_20240602122005.js +0 -121
  383. package/.history/get-commit-hashes_20240602122306.js +0 -126
  384. package/.history/get-commit-hashes_20240602122508.js +0 -126
  385. package/.history/get-commit-hashes_20240602122512.js +0 -126
  386. package/.history/get-commit-hashes_20240602122740.js +0 -131
  387. package/.history/get-commit-hashes_20240602122753.js +0 -133
  388. package/.history/get-commit-hashes_20240602123402.js +0 -137
  389. package/.history/get-commit-hashes_20240602123506.js +0 -137
  390. package/.history/get-commit-hashes_20240602123539.js +0 -136
  391. package/.history/get-commit-hashes_20240602123600.js +0 -137
  392. package/.history/get-commit-hashes_20240602123652.js +0 -137
  393. package/.history/get-commit-hashes_20240602123655.js +0 -137
  394. package/.history/get-commit-hashes_20240602124201.js +0 -134
  395. package/.history/get-commit-hashes_20240602124214.js +0 -134
  396. package/.history/get-commit-hashes_20240602124235.js +0 -134
  397. package/.history/get-commit-hashes_20240602124246.js +0 -134
  398. package/.history/get-commit-hashes_20240602124300.js +0 -134
  399. package/.history/get-commit-hashes_20240602125154.js +0 -134
  400. package/.history/get-commit-hashes_20240602125220.js +0 -135
  401. package/.history/get-commit-hashes_20240602125236.js +0 -136
  402. package/.history/get-commit-hashes_20240602125316.js +0 -135
  403. package/.history/get-commit-hashes_20240602125359.js +0 -135
  404. package/.history/get-commit-hashes_20240602125435.js +0 -135
  405. package/.history/get-commit-hashes_20240602125535.js +0 -136
  406. package/.history/get-commit-hashes_20240602125552.js +0 -136
  407. package/.history/get-commit-hashes_20240602125650.js +0 -136
  408. package/.history/get-commit-hashes_20240602125734.js +0 -136
  409. package/.history/get-commit-hashes_20240602125813.js +0 -136
  410. package/.history/get-commit-hashes_20240602125815.js +0 -136
  411. package/.history/get-commit-hashes_20240602125935.js +0 -131
  412. package/.history/get-commit-hashes_20240602134402.js +0 -138
  413. package/.history/get-commit-hashes_20240602140122.js +0 -138
  414. package/.history/get-commit-hashes_20240602140501.js +0 -139
  415. package/.history/get-commit-hashes_20240602140751.js +0 -217
  416. package/.history/get-commit-hashes_20240602145433.js +0 -216
  417. package/.history/get-commit-hashes_20240602150301.js +0 -222
  418. package/.history/get-commit-hashes_20240602150311.js +0 -222
  419. package/.history/get-commit-hashes_20240602150528.js +0 -224
  420. package/.history/get-commit-hashes_20240602150616.js +0 -224
  421. package/.history/get-commit-hashes_20240602150642.js +0 -224
  422. package/.history/get-commit-hashes_20240602150809.js +0 -224
  423. package/.history/get-commit-hashes_20240602150821.js +0 -225
  424. package/.history/get-commit-hashes_20240602151117.js +0 -225
  425. package/.history/get-commit-hashes_20240602151258.js +0 -225
  426. package/.history/get-commit-hashes_20240602151302.js +0 -225
  427. package/.history/get-commit-hashes_20240602151400.js +0 -225
  428. package/.history/get-commit-hashes_20240602151449.js +0 -227
  429. package/.history/get-commit-hashes_20240602151720.js +0 -222
  430. package/.history/get-commit-hashes_20240602151727.js +0 -217
  431. package/.history/get-commit-hashes_20240602152723.js +0 -243
  432. package/.history/get-commit-hashes_20240602152732.js +0 -239
  433. package/.history/get-commit-hashes_20240602153015.js +0 -236
  434. package/.history/get-commit-hashes_20240602153158.js +0 -236
  435. package/.history/get-commit-hashes_20240602153203.js +0 -236
  436. package/.history/get-commit-hashes_20240602153714.js +0 -238
  437. package/.history/get-commit-hashes_20240602154523.js +0 -240
  438. package/.history/get-commit-hashes_20240602191724.js +0 -243
  439. package/.history/get-commit-hashes_20240602191941.js +0 -247
  440. package/.history/get-commit-hashes_20240602191948.js +0 -242
  441. package/.history/get-commit-hashes_20240602221944.js +0 -243
  442. package/.history/get-commit-hashes_20240602222314.js +0 -243
  443. package/.history/get-commit-hashes_20240602222404.js +0 -249
  444. package/.history/get-commit-hashes_20240602222620.js +0 -251
  445. package/.history/get-commit-hashes_20240602222748.js +0 -251
  446. package/.history/get-commit-hashes_20240602223201.js +0 -251
  447. package/.history/get-commit-hashes_20240602223356.js +0 -251
  448. package/.history/get-commit-hashes_20240602223422.js +0 -251
  449. package/.history/get-commit-hashes_20240602223425.js +0 -249
  450. package/.history/get-commit-hashes_20240603060408.js +0 -250
  451. package/.history/get-commit-hashes_20240603060422.js +0 -250
  452. package/.history/get-commit-hashes_20240603060722.js +0 -254
  453. package/.history/get-commit-hashes_20240603060746.js +0 -254
  454. package/.history/get-commit-hashes_20240603111712.js +0 -218
  455. package/.history/get-commit-hashes_20240603112018.js +0 -218
  456. package/.history/get-commit-hashes_20240603112033.js +0 -218
  457. package/.history/get-commit-hashes_20240603114051.js +0 -220
  458. package/.history/get-commit-hashes_20240603114104.js +0 -220
  459. package/.history/get-commit-hashes_20240603114123.js +0 -220
  460. package/.history/get-commit-hashes_20240603114139.js +0 -219
  461. package/.history/get-commit-hashes_20240603114224.js +0 -219
  462. package/.history/get-commit-hashes_20240603114249.js +0 -219
  463. package/.history/get-commit-hashes_20240603114339.js +0 -220
  464. package/.history/get-commit-hashes_20240603114412.js +0 -220
  465. package/.history/get-commit-hashes_20240603115456.js +0 -220
  466. package/.history/get-commit-hashes_20240603115739.js +0 -220
  467. package/.history/get-commit-hashes_20240603125515.js +0 -207
  468. package/.history/get-commit-hashes_20240603125616.js +0 -206
  469. package/.history/get-commit-hashes_20240606210743.js +0 -207
  470. package/.history/get-commit-hashes_20240606211024.js +0 -205
  471. package/.history/get-commit-hashes_20240606211030.js +0 -204
  472. package/.history/get-commit-hashes_20240606211106.js +0 -204
  473. package/.history/get-commit-hashes_20240607054002.js +0 -206
  474. package/.history/get-commit-hashes_20240607054123.js +0 -210
  475. package/.history/get-commit-hashes_20240607054552.js +0 -210
  476. package/.history/get-commit-hashes_20240607054634.js +0 -210
  477. package/.history/get-commit-hashes_20240607054635.js +0 -210
  478. package/.history/get-commit-hashes_20240607055520.js +0 -210
  479. package/.history/get-commit-hashes_20240607075051.js +0 -224
  480. package/.history/get-commit-hashes_20240607075211.js +0 -231
  481. package/.history/get-commit-hashes_20240607075222.js +0 -231
  482. package/.history/get-commit-hashes_20240607075808.js +0 -231
  483. package/.history/get-commit-hashes_20240607075945.js +0 -231
  484. package/.history/get-commit-hashes_20240607075949.js +0 -224
  485. package/.history/get-commit-hashes_20240607075956.js +0 -224
  486. package/.history/get-commit-hashes_20240607080930.js +0 -224
  487. package/.history/get-commit-hashes_20240607081009.js +0 -226
  488. package/.history/get-commit-hashes_20240607081018.js +0 -225
  489. package/.history/get-commit-hashes_20240607081019.js +0 -226
  490. package/.history/get-commit-hashes_20240607081050.js +0 -227
  491. package/.history/get-commit-hashes_20240607114800.js +0 -227
  492. package/.history/get-commit-hashes_20240607114819.js +0 -226
  493. package/.history/get-commit-hashes_20240607120057.js +0 -226
  494. package/.history/get-commit-hashes_20240607122410.js +0 -229
  495. package/.history/get-commit-hashes_20240607152331.js +0 -229
  496. package/.history/get-commit-hashes_20240607152359.js +0 -229
  497. package/.history/get-commit-hashes_20240607152417.js +0 -229
  498. package/.history/get-commit-hashes_20240607152455.js +0 -229
  499. package/.history/get-commit-hashes_20240607152457.js +0 -229
  500. package/.history/get-commit-hashes_20240607152559.js +0 -229
  501. package/.history/get-commit-hashes_20240607152606.js +0 -229
  502. package/.history/get-xrefs-data_20240607152605.js +0 -229
  503. package/.history/get-xrefs-data_20240607193045.js +0 -229
  504. package/.history/get-xrefs-data_20240607194536.js +0 -230
  505. package/.history/get-xrefs-data_20240607194751.js +0 -231
  506. package/.history/get-xrefs-data_20240607195622.js +0 -231
  507. package/.history/get-xrefs-data_20240607201239.js +0 -232
  508. package/.history/get-xrefs-data_20240607201354.js +0 -233
  509. package/.history/get-xrefs-data_20240607201441.js +0 -236
  510. package/.history/get-xrefs-data_20240607201940.js +0 -237
  511. package/.history/get-xrefs-data_20240607202124.js +0 -238
  512. package/.history/get-xrefs-data_20240607202139.js +0 -238
  513. package/.history/get-xrefs-data_20240607202409.js +0 -238
  514. package/.history/get-xrefs-data_20240607202436.js +0 -239
  515. package/.history/get-xrefs-data_20240607202557.js +0 -240
  516. package/.history/get-xrefs-data_20240607202624.js +0 -239
  517. package/.history/get-xrefs-data_20240607212903.js +0 -241
  518. package/.history/get-xrefs-data_20240608111123.js +0 -238
  519. package/.history/get-xrefs-data_20240608111952.js +0 -239
  520. package/.history/get-xrefs-data_20240608112057.js +0 -238
  521. package/.history/get-xrefs-data_20240608112121.js +0 -240
  522. package/.history/get-xrefs-data_20240608112633.js +0 -239
  523. package/.history/get-xrefs-data_20240608112654.js +0 -239
  524. package/.history/get-xrefs-data_20240608112728.js +0 -239
  525. package/.history/get-xrefs-data_20240608112736.js +0 -239
  526. package/.history/get-xrefs-data_20240608112819.js +0 -239
  527. package/.history/get-xrefs-data_20240608113141.js +0 -240
  528. package/.history/get-xrefs-data_20240608144253.js +0 -240
  529. package/.history/get-xrefs-data_20240608150442.js +0 -241
  530. package/.history/get-xrefs-data_20240608150803.js +0 -242
  531. package/.history/get-xrefs-data_20240608150941.js +0 -238
  532. package/.history/get-xrefs-data_20240608150959.js +0 -238
  533. package/.history/get-xrefs-data_20240608151005.js +0 -237
  534. package/.history/get-xrefs-data_20240608152437.js +0 -237
  535. package/.history/get-xrefs-data_20240608152452.js +0 -237
  536. package/.history/get-xrefs-data_20240608152518.js +0 -234
  537. package/.history/get-xrefs-data_20240608152550.js +0 -236
  538. package/.history/get-xrefs-data_20240608152837.js +0 -237
  539. package/.history/get-xrefs-data_20240608152840.js +0 -236
  540. package/.history/get-xrefs-data_20240608152918.js +0 -236
  541. package/.history/get-xrefs-data_20240608153032.js +0 -236
  542. package/.history/get-xrefs-data_20240608153105.js +0 -235
  543. package/.history/get-xrefs-data_20240608153306.js +0 -235
  544. package/.history/get-xrefs-data_20240608153439.js +0 -236
  545. package/.history/get-xrefs-data_20240608153441.js +0 -236
  546. package/.history/get-xrefs-data_20240608153934.js +0 -236
  547. package/.history/get-xrefs-data_20240608154001.js +0 -234
  548. package/.history/get-xrefs-data_20240608154002.js +0 -234
  549. package/.history/get-xrefs-data_20240608154021.js +0 -235
  550. package/.history/get-xrefs-data_20240608154134.js +0 -242
  551. package/.history/get-xrefs-data_20240608154457.js +0 -243
  552. package/.history/get-xrefs-data_20240608154504.js +0 -242
  553. package/.history/get-xrefs-data_20240608154538.js +0 -242
  554. package/.history/get-xrefs-data_20240608154542.js +0 -241
  555. package/.history/get-xrefs-data_20240608154635.js +0 -248
  556. package/.history/get-xrefs-data_20240608154646.js +0 -248
  557. package/.history/get-xrefs-data_20240608154703.js +0 -249
  558. package/.history/get-xrefs-data_20240608155349.js +0 -249
  559. package/.history/get-xrefs-data_20240608155443.js +0 -248
  560. package/.history/get-xrefs-data_20240608155516.js +0 -249
  561. package/.history/get-xrefs-data_20240608164456.js +0 -251
  562. package/.history/get-xrefs-data_20240608164532.js +0 -251
  563. package/.history/get-xrefs-data_20240608164715.js +0 -252
  564. package/.history/get-xrefs-data_20240608170147.js +0 -254
  565. package/.history/get-xrefs-data_20240608170221.js +0 -255
  566. package/.history/get-xrefs-data_20240608171000.js +0 -255
  567. package/.history/get-xrefs-data_20240608172204.js +0 -275
  568. package/.history/get-xrefs-data_20240608172229.js +0 -275
  569. package/.history/get-xrefs-data_20240608172249.js +0 -265
  570. package/.history/get-xrefs-data_20240608172411.js +0 -266
  571. package/.history/get-xrefs-data_20240608172513.js +0 -266
  572. package/.history/get-xrefs-data_20240608172641.js +0 -266
  573. package/.history/get-xrefs-data_20240608172732.js +0 -266
  574. package/.history/get-xrefs-data_20240608185227.js +0 -264
  575. package/.history/get-xrefs-data_20240608185241.js +0 -257
  576. package/.history/get-xrefs-data_20240608185255.js +0 -256
  577. package/.history/get-xrefs-data_20240608185416.js +0 -256
  578. package/.history/get-xrefs-data_20240608185427.js +0 -250
  579. package/.history/get-xrefs-data_20240608185516.js +0 -250
  580. package/.history/get-xrefs-data_20240608185713.js +0 -250
  581. package/.history/get-xrefs-data_20240608190605.js +0 -244
  582. package/.history/get-xrefs-data_20240608190731.js +0 -256
  583. package/.history/get-xrefs-data_20240608190737.js +0 -256
  584. package/.history/get-xrefs-data_20240608190834.js +0 -265
  585. package/.history/get-xrefs-data_20240608190853.js +0 -260
  586. package/.history/get-xrefs-data_20240608190854.js +0 -260
  587. package/.history/get-xrefs-data_20240608190909.js +0 -260
  588. package/.history/get-xrefs-data_20240608191008.js +0 -253
  589. package/.history/get-xrefs-data_20240608191108.js +0 -243
  590. package/.history/get-xrefs-data_20240608191120.js +0 -243
  591. package/.history/get-xrefs-data_20240608191301.js +0 -242
  592. package/.history/get-xrefs-data_20240608191322.js +0 -242
  593. package/.history/gulpfile_20240529170917.js +0 -78
  594. package/.history/gulpfile_20240607085343.js +0 -79
  595. package/.history/index_20240529170917.js +0 -366
  596. package/.history/index_20240529171907.js +0 -366
  597. package/.history/index_20240531080235.js +0 -367
  598. package/.history/index_20240531080317.js +0 -368
  599. package/.history/index_20240531080355.js +0 -369
  600. package/.history/index_20240531121208.js +0 -370
  601. package/.history/index_20240531121244.js +0 -371
  602. package/.history/index_20240531121441.js +0 -371
  603. package/.history/index_20240531205230.js +0 -371
  604. package/.history/index_20240531205235.js +0 -371
  605. package/.history/index_20240531205239.js +0 -371
  606. package/.history/index_20240601075844.js +0 -372
  607. package/.history/index_20240601121107.js +0 -371
  608. package/.history/index_20240602170625.js +0 -371
  609. package/.history/index_20240602170636.js +0 -371
  610. package/.history/index_20240602170835.js +0 -371
  611. package/.history/index_20240602172140.js +0 -371
  612. package/.history/index_20240602172203.js +0 -371
  613. package/.history/index_20240602172254.js +0 -371
  614. package/.history/index_20240602172350.js +0 -371
  615. package/.history/index_20240602172443.js +0 -371
  616. package/.history/index_20240602223132.js +0 -375
  617. package/.history/index_20240603060852.js +0 -375
  618. package/.history/index_20240603111306.js +0 -375
  619. package/.history/index_20240603122144.js +0 -375
  620. package/.history/index_20240606203934.js +0 -367
  621. package/.history/index_20240606210811.js +0 -367
  622. package/.history/index_20240606210947.js +0 -369
  623. package/.history/index_20240606210948.js +0 -369
  624. package/.history/index_20240606211118.js +0 -369
  625. package/.history/index_20240606211128.html +0 -871
  626. package/.history/index_20240607061244.html +0 -4182
  627. package/.history/index_20240607103533.js +0 -371
  628. package/.history/index_20240607103544.js +0 -372
  629. package/.history/index_20240607103644.js +0 -372
  630. package/.history/index_20240607103709.js +0 -372
  631. package/.history/index_20240607103755.js +0 -377
  632. package/.history/index_20240607103825.js +0 -377
  633. package/.history/index_20240607104831.js +0 -378
  634. package/.history/index_20240607104906.js +0 -378
  635. package/.history/index_20240607114825.js +0 -378
  636. package/.history/index_20240607114901.js +0 -376
  637. package/.history/index_20240607114924.js +0 -376
  638. package/.history/index_20240607114938.js +0 -373
  639. package/.history/index_20240607114943.js +0 -374
  640. package/.history/index_20240607115039.js +0 -374
  641. package/.history/index_20240607152922.js +0 -382
  642. package/.history/index_20240607152929.js +0 -380
  643. package/.history/index_20240607152933.js +0 -379
  644. package/.history/index_20240607152947.js +0 -378
  645. package/.history/index_20240607192712.js +0 -378
  646. package/.history/index_20240607193051.js +0 -378
  647. package/.history/index_20240607193255.js +0 -378
  648. package/.history/index_20240607193923.js +0 -381
  649. package/.history/index_20240607193924.js +0 -381
  650. package/.history/index_20240607200916.js +0 -382
  651. package/.history/index_20240607200941.js +0 -381
  652. package/.history/index_20240607202747.js +0 -382
  653. package/.history/index_20240607203343.js +0 -395
  654. package/.history/index_20240607203451.js +0 -396
  655. package/.history/index_20240607203511.js +0 -396
  656. package/.history/index_20240608182321.js +0 -396
  657. package/.history/index_20240608191607.js +0 -396
  658. package/.history/index_20240608192106.js +0 -396
  659. package/.history/index_20240609122452.js +0 -396
  660. package/.history/index_20240609123904.js +0 -394
  661. package/.history/index_20240609125351.js +0 -394
  662. package/.history/index_20240609125659.js +0 -394
  663. package/.history/index_20240609125703.js +0 -393
  664. package/.history/index_20240609125729.js +0 -393
  665. package/.history/index_20240609125730.js +0 -393
  666. package/.history/index_20240609125741.js +0 -394
  667. package/.history/index_20240609125800.js +0 -394
  668. package/.history/index_20240609125804.js +0 -393
  669. package/.history/index_20240609125807.js +0 -393
  670. package/.history/index_20240609130005.js +0 -393
  671. package/.history/index_20240609130011.js +0 -394
  672. package/.history/index_20240609130024.js +0 -394
  673. package/.history/index_20240609130031.js +0 -393
  674. package/.history/index_20240609131301.js +0 -366
  675. package/.history/index_20240609131311.js +0 -365
  676. package/.history/index_20240609131420.js +0 -366
  677. package/.history/index_20240609131815.js +0 -393
  678. package/.history/index_20240609131847.js +0 -394
  679. package/.history/multi-file-test/abstract_20240529170917.md +0 -3
  680. package/.history/multi-file-test/abstract_20240529171417.md +0 -3
  681. package/.history/multi-file-test/getting-started_20240529170917.md +0 -21
  682. package/.history/multi-file-test/getting-started_20240601200253.md +0 -24
  683. package/.history/multi-file-test/getting-started_20240601200322.md +0 -21
  684. package/.history/multi-file-test/getting-started_20240601200328.md +0 -21
  685. package/.history/multi-file-test/getting-started_20240601200635.md +0 -24
  686. package/.history/multi-file-test/getting-started_20240601200947.md +0 -23
  687. package/.history/multi-file-test/getting-started_20240601201356.md +0 -24
  688. package/.history/package_20240529170917.json +0 -61
  689. package/.history/package_20240606152842.json +0 -61
  690. package/.history/package_20240606153019.json +0 -61
  691. package/.history/package_20240606153034.json +0 -61
  692. package/.history/package_20240606153048.json +0 -61
  693. package/.history/package_20240606153056.json +0 -61
  694. package/.history/package_20240606153733.json +0 -61
  695. package/.history/package_20240606153752.json +0 -61
  696. package/.history/package_20240606153821.json +0 -61
  697. package/.history/package_20240606192324.json +0 -62
  698. package/.history/package_20240606193058.json +0 -62
  699. package/.history/package_20240609111343.json +0 -62
  700. package/.history/package_20240609111345.json +0 -62
  701. package/.history/package_20240609111357.json +0 -62
  702. package/.history/package_20240609123350.json +0 -61
  703. package/.history/references_20240529170917.js +0 -91
  704. package/.history/references_20240531085208.js +0 -92
  705. package/.history/references_20240531205331.js +0 -93
  706. package/.history/references_20240531205530.js +0 -93
  707. package/.history/references_20240531205648.js +0 -94
  708. package/.history/references_20240531205653.js +0 -94
  709. package/.history/references_20240531205827.js +0 -94
  710. package/.history/references_20240531211225.js +0 -94
  711. package/.history/references_20240531211257.js +0 -94
  712. package/.history/references_20240531212203.js +0 -94
  713. package/.history/repos_20240601065523.json +0 -0
  714. package/.history/repos_20240601065607.json +0 -6
  715. package/.history/repos_20240601065721.json +0 -8
  716. package/.history/repos_20240601065735.json +0 -12
  717. package/.history/repos_20240601070711.json +0 -12
  718. package/.history/repos_20240601110402.json +0 -12
  719. package/.history/single-file-test/spec_20240529170917.md +0 -536
  720. package/.history/single-file-test/spec_20240529171145.md +0 -537
  721. package/.history/single-file-test/spec_20240529171146.md +0 -537
  722. package/.history/single-file-test/spec_20240529171645.md +0 -537
  723. package/.history/single-file-test/spec_20240531085345.md +0 -537
  724. package/.history/single-file-test/spec_20240531090748.md +0 -540
  725. package/.history/single-file-test/spec_20240531090808.md +0 -540
  726. package/.history/single-file-test/spec_20240531091229.md +0 -541
  727. package/.history/single-file-test/spec_20240531092508.md +0 -541
  728. package/.history/single-file-test/spec_20240531121310.md +0 -541
  729. package/.history/single-file-test/spec_20240531210312.md +0 -541
  730. package/.history/single-file-test/spec_20240531210313.md +0 -541
  731. package/.history/single-file-test/spec_20240602212745.md +0 -541
  732. package/.history/single-file-test/spec_20240602215524.md +0 -537
  733. package/.history/single-file-test/spec_20240602215642.md +0 -541
  734. package/.history/spec/access-control_20240603080857.md +0 -15
  735. package/.history/spec/access-control_20240603120417.md +0 -13
  736. package/.history/spec/access-control_20240603120429.md +0 -15
  737. package/.history/spec/access-control_20240603121147.md +0 -15
  738. package/.history/spec/access-control_20240603174617.md +0 -13
  739. package/.history/spec/term-definitions/access-control_20240603061012.md +0 -10
  740. package/.history/spec/term-definitions/access-control_20240603080858.md +0 -15
  741. package/.history/spec/term-definitions/access-control_20240609114334.md +0 -8
  742. package/.history/spec/term-definitions/term-1_20240607183037.md +0 -0
  743. package/.history/spec/term-definitions/term-1_20240607183120.md +0 -2
  744. package/.history/spec/term-definitions/term-1_20240607183122.md +0 -3
  745. package/.history/spec/term-definitions/term-1_20240607183340.md +0 -3
  746. package/.history/spec/term-definitions/term-1_20240607192721.md +0 -3
  747. package/.history/spec/term-definitions/term-1_20240607204948.md +0 -9
  748. package/.history/spec/term-definitions/term-1_20240607205022.md +0 -9
  749. package/.history/spec/term-definitions/term-1_20240607205104.md +0 -9
  750. package/.history/spec/term-definitions/term-1_20240607205105.md +0 -9
  751. package/.history/spec/term-definitions/term-1_20240607205110.md +0 -9
  752. package/.history/spec/term-definitions/term-1_20240607205256.md +0 -9
  753. package/.history/spec/term-definitions/term-2_20240607183041.md +0 -0
  754. package/.history/spec/term-definitions/term-2_20240607183534.md +0 -3
  755. package/.history/spec/term-definitions/term-2_20240607183827.md +0 -3
  756. package/.history/spec/term-definitions/term-2_20240607183850.md +0 -3
  757. package/.history/spec/term-definitions/term-3_20240607183041.md +0 -0
  758. package/.history/spec/term-definitions/term-3_20240607183534.md +0 -3
  759. package/.history/spec/term-definitions/term-4_20240607183041.md +0 -0
  760. package/.history/spec/term-definitions/term-4_20240607183534.md +0 -3
  761. package/.history/spec/term-definitions-back-up/term-1_20240607205256_20240609143033.md +0 -0
  762. package/.history/spec/term-definitions-back-up/term-1_20240607205256_20240609143034.md +0 -9
  763. package/.history/spec/term-definitions-back-up/term-2_20240607183850_20240609143016.md +0 -0
  764. package/.history/spec/term-definitions-back-up/term-2_20240607183850_20240609143017.md +0 -3
  765. package/.history/spec/term-definitions-back-up/term-3_20240607183534_20240609142958.md +0 -0
  766. package/.history/spec/term-definitions-back-up/term-3_20240607183534_20240609142959.md +0 -3
  767. package/.history/spec/term-definitions-back-up/term-4_20240607183534_20240609142930.md +0 -0
  768. package/.history/spec/term-definitions-back-up/term-4_20240607183534_20240609142931.md +0 -3
  769. package/.history/spec/terms_and_definitions_20240607151034.md +0 -2778
  770. package/.history/spec/terms_and_definitions_20240607185523.md +0 -10
  771. package/.history/spec/terms_and_definitions_20240609114242.md +0 -2766
  772. package/.history/spec/terms_and_definitions_20240609143300.md +0 -1
  773. package/.history/spec/terms_and_definitions_20240609143312.md +0 -2766
  774. package/.history/spec/terms_and_definitions_20240609143350.md +0 -2766
  775. package/.history/spec/terms_and_definitions_20240609143352.md +0 -2766
  776. package/.history/spec/terms_and_definitions_20240609144335.md +0 -10
  777. package/.history/specs_20240529170917.json +0 -54
  778. package/.history/specs_20240531154112.json +0 -57
  779. package/.history/specs_20240531154116.json +0 -57
  780. package/.history/specs_20240531210248.json +0 -57
  781. package/.history/specs_20240601065224.json +0 -59
  782. package/.history/specs_20240601065327.json +0 -57
  783. package/.history/specs_20240602101746.json +0 -65
  784. package/.history/specs_20240602101751.json +0 -65
  785. package/.history/specs_20240602101756.json +0 -65
  786. package/.history/specs_20240602101801.json +0 -65
  787. package/.history/specs_20240602101910.json +0 -65
  788. package/.history/specs_20240602124536.json +0 -65
  789. package/.history/specs_20240603061447.json +0 -65
  790. package/.history/specs_20240603062120.json +0 -29
  791. package/.history/specs_20240603062127.json +0 -29
  792. package/.history/specs_20240603062221.json +0 -29
  793. package/.history/specs_20240603062318.json +0 -32
  794. package/.history/specs_20240603062405.json +0 -32
  795. package/.history/specs_20240603103530.json +0 -32
  796. package/.history/specs_20240603110456.json +0 -32
  797. package/.history/specs_20240603113847.json +0 -32
  798. package/.history/specs_20240603113945.json +0 -33
  799. package/.history/specs_20240603120159.json +0 -33
  800. package/.history/specs_20240606160740.json +0 -33
  801. package/.history/specs_20240606195013.json +0 -71
  802. package/.history/specs_20240606195033.json +0 -61
  803. package/.history/specs_20240607150623.json +0 -90
  804. package/.history/specs_20240607151120.json +0 -90
  805. package/.history/specs_20240607151526.json +0 -90
  806. package/.history/specs_20240607151536.json +0 -113
  807. package/.history/specs_20240607151739.json +0 -113
  808. package/.history/specs_20240607151741.json +0 -113
  809. package/.history/specs_20240607152157.json +0 -123
  810. package/.history/specs_20240607152206.json +0 -66
  811. package/.history/specs_20240607185424.json +0 -72
  812. package/.history/specs_20240609084604.json +0 -73
  813. package/.history/specs_20240609084622.json +0 -73
  814. package/.history/specs_20240609132103.json +0 -73
  815. package/.history/specs_20240609134016.json +0 -73
  816. package/.history/specs_20240609151122.json +0 -73
  817. package/.history/src/asset-map_20240529170917.json +0 -32
  818. package/.history/src/asset-map_20240529181204.json +0 -33
  819. package/.history/src/asset-map_20240529181216.json +0 -34
  820. package/.history/src/asset-map_20240529185951.json +0 -33
  821. package/.history/src/asset-map_20240529190049.json +0 -34
  822. package/.history/src/asset-map_20240529190105.json +0 -34
  823. package/.history/src/asset-map_20240531105353.json +0 -28
  824. package/.history/src/asset-map_20240531105526.json +0 -32
  825. package/.history/src/asset-map_20240602161130.json +0 -33
  826. package/.history/src/asset-map_20240606152137.json +0 -33
  827. package/.history/src/asset-map_20240608220613.json +0 -36
  828. package/.history/src/asset-map_20240608220634.json +0 -37
  829. package/.history/src/asset-map_20240608221300.json +0 -36
  830. package/.history/src/asset-map_20240608225209.json +0 -37
  831. package/.history/src/asset-map_20240608225940.json +0 -37
  832. package/.history/src/asset-map_20240609134637.json +0 -36
  833. package/.history/src/asset-map_20240609134701.json +0 -37
  834. package/.history/src/asset-map_20240609134704.json +0 -37
  835. package/.history/src/asset-map_20240609134707.json +0 -37
  836. package/.history/src/fix-content_20240516184008.js +0 -58
  837. package/.history/src/fix-content_20240609101013.js +0 -60
  838. package/.history/src/fix-content_20240609101024.js +0 -60
  839. package/.history/src/fix-content_20240609101043.js +0 -59
  840. package/.history/src/fix-content_20240609101105.js +0 -59
  841. package/.history/src/get-xrefs-data_20240608191321.js +0 -242
  842. package/.history/src/get-xrefs-data_20240609145329.js +0 -240
  843. package/.history/src/get-xrefs-data_20240609145436.js +0 -235
  844. package/.history/src/get-xrefs-data_20240609145437.js +0 -235
  845. package/.history/src/get-xrefs-data_20240609145555.js +0 -234
  846. package/.history/src/get-xrefs-data_20240609145812.js +0 -206
  847. package/.history/src/get-xrefs-data_20240609145841.js +0 -205
  848. package/.history/src/get-xrefs-data_20240609145912.js +0 -204
  849. package/.history/src/get-xrefs-data_20240609151558.js +0 -211
  850. package/.history/src/get-xrefs-data_20240609151617.js +0 -211
  851. package/.history/src/get-xrefs-data_20240609151755.js +0 -211
  852. package/.history/src/get-xrefs-data_20240609151836.js +0 -211
  853. package/.history/src/split-terms-and-definitions-test_20240609092631.js +0 -115
  854. package/.history/src/split-terms-and-definitions-test_20240609092711.js +0 -37
  855. package/.history/src/split-terms-and-definitions-test_20240609092735.js +0 -34
  856. package/.history/src/split-terms-and-definitions-test_20240609093929.js +0 -38
  857. package/.history/src/split-terms-and-definitions_20240606134813.js +0 -113
  858. package/.history/src/split-terms-and-definitions_20240609085141.js +0 -115
  859. package/.history/src/split-terms-and-definitions_20240609085426.js +0 -115
  860. package/.history/src/split-terms-and-definitions_20240609102010.js +0 -117
  861. package/.history/src/split-terms-and-definitions_20240609102601.js +0 -117
  862. package/.history/src/split-terms-and-definitions_20240609105235.js +0 -117
  863. package/.history/src/split-terms-and-definitions_20240609105323.js +0 -117
  864. package/.history/src/split-terms-and-definitions_20240609105531.js +0 -117
  865. package/.history/src/split-terms-and-definitions_20240609105609.js +0 -117
  866. package/.history/src/split-terms-and-definitions_20240609110049.js +0 -118
  867. package/.history/src/split-terms-and-definitions_20240609110622.js +0 -118
  868. package/.history/src/split-terms-and-definitions_20240609110706.js +0 -118
  869. package/.history/src/split-terms-and-definitions_20240609110744.js +0 -119
  870. package/.history/src/split-terms-and-definitions_20240609110946.js +0 -119
  871. package/.history/src/split-terms-and-definitions_20240609113715.js +0 -120
  872. package/.history/src/split-terms-and-definitions_20240609114017.js +0 -120
  873. package/.history/src/split-terms-and-definitions_20240609114934.js +0 -130
  874. package/.history/src/split-terms-and-definitions_20240609115214.js +0 -133
  875. package/.history/src/split-terms-and-definitions_20240609115433.js +0 -136
  876. package/.history/src/split-terms-and-definitions_20240609120001.js +0 -137
  877. package/.history/src/split-terms-and-definitions_20240609120333.js +0 -140
  878. package/.history/src/split-terms-and-definitions_20240609120406.js +0 -141
  879. package/.history/src/split-terms-and-definitions_20240609120453.js +0 -142
  880. package/.history/src/split-terms-and-definitions_20240609120545.js +0 -144
  881. package/.history/src/split-terms-and-definitions_20240609120604.js +0 -144
  882. package/.history/src/split-terms-and-definitions_20240609120608.js +0 -143
  883. package/.history/src/split-terms-and-definitions_20240609120626.js +0 -143
  884. package/.history/src/split-terms-and-definitions_20240609120637.js +0 -142
  885. package/.history/src/split-terms-and-definitions_20240609120658.js +0 -142
  886. package/.history/src/split-terms-and-definitions_20240609120725.js +0 -142
  887. package/.history/src/split-terms-and-definitions_20240609120745.js +0 -142
  888. package/.history/src/split-terms-and-definitions_20240609121121.js +0 -138
  889. package/.history/src/split-terms-and-definitions_20240609121206.js +0 -140
  890. package/.history/src/split-terms-and-definitions_20240609121207.js +0 -140
  891. package/.history/src/split-terms-and-definitions_20240609121209.js +0 -138
  892. package/.history/src/split-terms-and-definitions_20240609123618.js +0 -148
  893. package/.history/src/split-terms-and-definitions_20240609123623.js +0 -147
  894. package/.history/src/split-terms-and-definitions_20240609123724.js +0 -147
  895. package/.history/src/split-terms-and-definitions_20240609133621.js +0 -154
  896. package/.history/src/split-terms-and-definitions_20240609133805.js +0 -155
  897. package/.history/src/split-terms-and-definitions_20240609134507.js +0 -155
  898. package/.history/src/split-terms-and-definitions_20240609134935.js +0 -150
  899. package/.history/xrefs_20240607081059.js +0 -17
  900. package/.history/xrefs_20240607082311.js +0 -17
  901. package/.history/xrefs_20240607082321.js +0 -17
@@ -1,2766 +0,0 @@
1
-
2
- [//]: # (Pandoc Formatting Macros)
3
-
4
- [//]: # (Portable Document Format)
5
-
6
- [//]: # (blank)
7
-
8
- [//]: # (: file format defined by ISO 32000-2)
9
-
10
- ## Terms & Definitions
11
-
12
- [[def: AAL]]
13
- ~ See: [[ref: authenticator assurance level]].
14
-
15
- [[def: ABAC]]
16
- ~ See: [[ref: attribute-based access control]].
17
-
18
- [[def: acceptance, accept, accepts]]
19
- ~ The [[ref: action]] of a [[ref: party]] receiving any form of [[ref: verifiable data]] and using it to make a [[ref: trust decision]].
20
-
21
- ~ See also: [[ref: acceptance network]].
22
-
23
- [[def: acceptance network]]
24
- ~ A [[ref: trust network]] designed to facilitate [[ref: acceptance]] of [[ref: verifiable data]] for its members.
25
-
26
- [[def: access control, access controls]]
27
- ~ The process of granting or denying specific requests for obtaining and using information and related information processing services.
28
-
29
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/access_control).
30
-
31
- ~ Supporting definitions:
32
-
33
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Access_control): In [physical security](https://en.wikipedia.org/wiki/Physical_security) and [information security](https://en.wikipedia.org/wiki/Information_security), access control (AC) is the selective restriction of access to a place or other resource, while access management describes the process. The act of accessing may mean consuming, entering, or using. Permission to access a resource is called [[ref: authorization]].
34
-
35
- [[def: accreditation, accredit, accredited]]
36
- ~ Formal declaration by an accrediting [[ref: authority]] that an information system is approved to operate at an acceptable level of [[ref: risk]], based on the implementation of an approved set of technical, managerial, and procedural safeguards.
37
-
38
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/accreditation)
39
-
40
- [[def: ACDC, ACDCs]]
41
- ~ See: [[ref: Authentic Chained Data Container]].
42
-
43
- [[def: action, actions, act, acts]]
44
- ~ Something that is actually done (a 'unit of work' that is executed) by a single [[ref: actor]] (on behalf of a given [[ref: party]]), as a single operation, in a specific context.
45
-
46
- Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#action).
47
-
48
- [[def: actor, actors]]
49
- ~ An [[ref: entity]] that can act (do things/execute [[ref: actions]]), e.g. people, machines, but not [[ref: organizations]]. A [[ref: digital agent]] can serve as an actor acting on behalf of its [[ref: principal]].
50
-
51
- Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/terms/actor).
52
-
53
- [[def: address, addresses, addressing]]
54
- ~ See: [[ref: network address]].
55
-
56
- [[def: administering authority, administering authorities]]
57
- ~ See: [[ref: administering body]].
58
-
59
- [[def: administering body, administering bodies]]
60
- ~ A [[ref: legal entity]] [[ref: delegated]] by a [[ref: governing body]] to administer the operation of a [[ref: governance framework]] and governed infrastructure for a [[ref: digital trust ecosystem]], such as one or more [[ref: trust registries]].
61
-
62
- ~ Also known as: [[ref: administering authority]].
63
-
64
- [[def: agency]]
65
- ~ In the context of decentralized digital trust infrastructure, the empowering of a [[ref: party]] to act independently of its own accord, and in particular to empower the party to employ an [[ref: agent]] to act on the [[ref: party]]'s behalf.
66
-
67
- [[def: agent, agents]]
68
- ~ An [[ref: actor]] that is executing an [[ref: action]] on behalf of a [[ref: party]] (called the [[ref: principal]] of that [[ref: actor]]). In the context of decentralized digital trust infrastructure, the term “agent” is most frequently used to mean a [[ref: digital agent]].
69
-
70
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#agent).
71
-
72
- ~ See also: [[ref: wallet]].
73
-
74
- ~ Note: In a ToIP context, an agent is frequently assumed to have privileged access to the [[ref: wallet]](s) of its principal. In market parlance, a mobile app performing the [[ref: actions]] of an agent is often simply called a [[ref: wallet]] or a [[ref: digital wallet]].
75
-
76
- [[def: AID]]
77
- ~ See [[ref: autonomic identifier]].
78
-
79
- [[def: anonymous]]
80
- ~ An adjective describing when the [[ref: identity]] of a [[ref: natural person]] or other [[ref: actor]] is unknown.
81
-
82
- ~ See also: [[ref: pseudonym]].
83
-
84
- [[def: anycast]]
85
- ~ Anycast is a network [[ref: addressing]] and [[ref: routing]] methodology in which a single [[ref: IP-address]] is shared by devices (generally servers) in multiple locations. [[ref: Routers]] direct packets addressed to this destination to the location nearest the sender, using their normal decision-making algorithms, typically the lowest number of BGP network hops. Anycast [[ref: routing]] is widely used by content delivery networks such as web and name servers, to bring their content closer to end users.
86
-
87
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Anycast).
88
-
89
- ~ See also: [[ref: broadcast]], [[ref: multicast]], [[ref: unicast]].
90
-
91
- [[def: anycast address, anycast addresses]]
92
- ~ A [[ref: network address]] (especially an [[ref: IP address]] used for [[ref: anycast]] routing of network transmissions.
93
-
94
- [[def: appraisability, appraisable, appraise]]
95
- ~ The ability for a [[ref: communication endpoint]] identified with a [[ref: verifiable identifier]] (VID) to be appraised for the set of its [[ref: properties]] that enable a [[ref: relying party]] or a [[ref: verifier]] to make a [[ref: trust decision]] about communicating with that [[ref: endpoint]].
96
-
97
- ~ See also: [[ref: trust basis]], [[ref: verifiability]].
98
-
99
- [[def: assurance level, assurance levels]]
100
- ~ A level of confidence in a [[ref: claim]] that may be relied on by others. Different types of assurance levels are defined for different types of trust assurance mechanisms. Examples include [[ref: authenticator assurance level]], [[ref: federation assurance level]], and [[ref: identity assurance level]].
101
-
102
- [[def: appropriate friction]]
103
- ~ A user-experience design principle for information systems (such as digital wallets) specifying that the level of attention required of the [[ref: holder]] for a particular transaction should provide a reasonable opportunity for an informed choice by the [[ref: holder]].
104
-
105
- ~ Source: [PEMC IGR](https://kantarainitiative.org/download/pemc-implementors-guidance-report/).
106
-
107
- [[def: attestation, attestations]]
108
- ~ The issue of a statement, based on a decision, that fulfillment of specified [[ref: requirements]] has been demonstrated. In the context of decentralized digital trust infrastructure, an attestation usually has a [[ref: digital signature]] so that it is [[ref: cryptographically verifiable]].
109
-
110
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/attestation).
111
-
112
- [[def: attribute, attributes]]
113
- ~ An identifiable set of data that describes an [[ref: entity]], which is the [[ref: subject]] of the attribute.
114
-
115
- ~ See also: [[ref: property]].
116
-
117
- ~ Supporting definitions:
118
-
119
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#attribute): [Data](https://essif-lab.github.io/framework/docs/terms/data) that represents a characteristic that a [party](https://essif-lab.github.io/framework/docs/terms/party) (the [owner](https://essif-lab.github.io/framework/docs/terms/owner) of the [attribute](https://essif-lab.github.io/framework/docs/terms/attribute)) has attributed to an [entity](https://essif-lab.github.io/framework/docs/terms/entity) (which is the [subject](https://essif-lab.github.io/framework/docs/terms/subject) of that attribute).
120
-
121
- ~ Note: An [[ref: identifier]] is an attribute that uniquely identifies an [[ref: entity]] within some context.
122
-
123
- [[def: attribute-based access control, attribute-based access controls]]
124
- ~ An [[ref: access control]] approach in which access is mediated based on [[ref: attributes]] associated with [[ref: subjects]] (requesters) and the objects to be accessed. Each object and [[ref: subject]] has a set of associated [[ref: attributes]], such as location, time of creation, access rights, etc. Access to an object is [[ref: authorized]] or denied depending upon whether the required (e.g., policy-defined) correlation can be made between the [[ref: attributes]] of that object and of the requesting [[ref: subject]].
125
-
126
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/attribute_based_access_control).
127
-
128
- ~ Supporting definitions:
129
-
130
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Attribute-based_access_control): Attribute-based access control (ABAC), also known as policy-based access control for [IAM](https://en.wikipedia.org/wiki/Identity_management), defines an access control paradigm whereby a subject's authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment attributes.
131
-
132
- [[def: audit, audits]]
133
- ~ Independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established [[ref: policies]] and operational procedures.
134
-
135
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/audit).
136
-
137
- [[def: audit log, audit logs]]
138
- ~ An audit log is a security-relevant chronological [[ref: record]], set of [[ref: records]], and/or destination and source of [[ref: records]] that provide documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure, event, or device.
139
-
140
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Audit_trail).
141
-
142
- ~ Also known as: audit trail.
143
-
144
- ~ See also: [[ref: key event log]].
145
-
146
- [[def: auditor, auditors]]
147
- ~ The [[ref: party]] responsible for performing an [[ref: audit]]. Typically an auditor must be [[ref: accredited]].
148
-
149
- ~ See also: [[ref: human auditable]].
150
-
151
- [[def: authentication, authenticate, authenticates, authenticated, authenticating]]
152
- ~ Verifying the [[ref: identity]] of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.
153
-
154
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/authentication).
155
-
156
- ~ See also: [[ref: authenticator]], [[ref: verifiable message]].
157
-
158
- ~ Supporting definitions:
159
-
160
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Authentication): The act of proving an [assertion](https://en.wikipedia.org/wiki/Logical_assertion), such as the [identity](https://en.wikipedia.org/wiki/Digital_identity) of a computer system user.
161
-
162
- [[def: authenticator]]
163
- ~ Something the claimant possesses and controls (typically a cryptographic module or password) that is used to [[ref: authenticate]] the claimant’s [[ref: identity]].
164
-
165
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/authenticator).
166
-
167
- [[def: authenticator assurance level, authenticator assurance levels, AAL, AALs]]
168
- ~ A measure of the strength of an [[ref: authentication]] mechanism and, therefore, the confidence in it.
169
-
170
- ~ Also known as: [[ref: AAL]]
171
-
172
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/authenticator_assurance_level).
173
-
174
- ~ See also: [[ref: federation assurance level]], [[ref: identity assurance level]], [[ref: identity binding]].
175
-
176
- ~ Note: In [NIST SP 800-63-3](https://pages.nist.gov/800-63-3/sp800-63-3.html), AAL is defined in terms of three levels: AAL1 (Some confidence), AAL2 (High confidence), AAL3 (Very high confidence).
177
-
178
- [[def: Authentic Chained Data Container]]
179
- ~ A digital [[ref: data]] structure designed for both cryptographic [[ref: verification]] and [[ref: chaining]] of data containers. ACDC may be used for [[ref: digital credentials]].
180
-
181
- ~ For more information, see: [ToIP ACDC Task Force](https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force).
182
-
183
- [[def: authenticity, authentic]]
184
- ~ The [[ref: property]] of being genuine and being able to be [[ref: verified]] and trusted; confidence in the [[ref: validity]] of a transmission, a [[ref: message]], or message originator.
185
-
186
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/authenticity).
187
-
188
- ~ See also: [[ref: confidentiality]], [[ref: correlation privacy]], [[ref: cryptographic verifiability]].
189
-
190
- [[def: authoritative]]
191
- ~ Information or [[ref: data]] that comes from an [[ref: authority]] for that information.
192
-
193
- [[def: authoritative source, authoritative sources]]
194
- ~ A source of information that a [[ref: relying party]] considers to be [[ref: authoritative]] for that information. In ToIP architecture, the [[ref: trust registry]] authorized by the [[ref: governance framework]] for a [[ref: trust community]] is typically considered an authoritative source by the members of that [[ref: trust community]]. A [[ref: system of record]] is an authoritative source for the data records it holds. A [[ref: trust anchor]] is an authoritative source for the beginning of a [[ref: trust chain]].
195
-
196
- [[def: authority, authorities]]
197
- ~ A [[ref: party]] of which certain decisions, ideas, [[ref: policies]], [[ref: rules]] etc. are followed by other [[ref: parties]].
198
-
199
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/terms/authority).
200
-
201
- [[def: authorization, authorizations, authorize, authorized, unauthorized, authorizing, unauthorizing, authorisation, authorisations, authorise, authorised, unauthorised, authorising, unauthorising]]
202
- ~ The process of [[ref: verifying]] that a requested [[ref: action]] or service is approved for a specific [[ref: entity]].
203
-
204
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/authorization).
205
-
206
- ~ See also: [[ref: permission]].
207
-
208
- [[def: authorized organizational representative]]
209
- ~ A [[ref: person]] who has the authority to make [[ref: claims]], sign documents or otherwise commit resources on behalf of an [[ref: organization]].
210
-
211
- ~ Source: [Law Insider](https://www.lawinsider.com/dictionary/authorized-organizational-representative#:~:text=Authorized%20Organizational%20Representative%20means%20the,the%20resources%20of%20the%20organization.)
212
-
213
- [[def: authorization graph]]
214
- ~ A graph of the [[ref: authorization]] relationships between different entities in a [[ref: trust-community]]. In a [[ref: digital trust ecosystem]], the [[ref: governing body]] is typically the [[ref: trust root]] of an authorization graph. In some cases, an authorization graph can be traversed by making queries to one or more [[ref: trust registries]].
215
-
216
- ~ See also: [[ref: governance graph]], [[ref: reputation graph]], [[ref: trust graph]].
217
-
218
- [[def: autonomic identifier, autonomic identifiers]]
219
- ~ The specific type of [[ref: self-certifying identifier]] defined by the [[ref: KERI]] specifications.
220
-
221
- ~ Also known as: [[ref: AID]].
222
-
223
- [[def: biometric, biometrics]]
224
- ~ A measurable physical characteristic or personal behavioral trait used to recognize the [[ref: AID]], or verify the [[ref: claimed]] [[ref: identity]], of an applicant. Facial images, fingerprints, and iris scan samples are all examples of biometrics.
225
-
226
- ~ Source: [NIST](https://csrc.nist.gov/glossary/term/biometric)
227
-
228
- [[def: blockchain, blockchains]]
229
- ~ A [[ref: distributed ledger]] of cryptographically-signed transactions that are grouped into blocks. Each block is cryptographically linked to the previous one (making it tamper evident) after [[ref: validation]] and undergoing a consensus decision. As new blocks are added, older blocks become more difficult to modify (creating [[ref: tamper resistance]]). New blocks are replicated across copies of the ledger within the network, and any conflicts are resolved automatically using established rules.
230
-
231
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/blockchain)
232
-
233
- ~ Supporting definitions:
234
-
235
- ~ [Wikipedia:](https://en.wikipedia.org/wiki/Blockchain) A [distributed ledger](https://en.wikipedia.org/wiki/Distributed_ledger) with growing lists of [records](https://en.wikipedia.org/wiki/Record_\(computer_science\)) (blocks) that are securely linked together via [cryptographic hashes](https://en.wikipedia.org/wiki/Cryptographic_hash_function). Each block contains a cryptographic hash of the previous block, a [timestamp](https://en.wikipedia.org/wiki/Trusted_timestamping), and transaction data (generally represented as a [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree), where [data nodes](https://en.wikipedia.org/wiki/Node_\(computer_science\)) are represented by leaves). Since each block contains information about the previous block, they effectively form a chain (compare [linked list](https://en.wikipedia.org/wiki/Linked_list) data structure), with each additional block linking to the ones before it. Consequently, blockchain transactions are irreversible in that, once they are recorded, the data in any given block cannot be altered retroactively without altering all subsequent blocks.
236
-
237
- [[def: broadcast]]
238
- ~ In computer networking, telecommunication and information theory, broadcasting is a method of transferring a [[ref: message]] to all recipients simultaneously. Broadcast delivers a message to all [[ref: nodes]] in the network using a one-to-all association; a single [[ref: datagram]] (or [[ref: packet]]) from one sender is routed to all of the possibly multiple endpoints associated with the [[ref: broadcast address]]. The network automatically replicates [[ref: datagrams]] as needed to reach all the recipients within the scope of the broadcast, which is generally an entire network subnet.
239
-
240
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Broadcasting_\(networking\)).
241
-
242
- ~ See also: [[ref: anycast]], [[ref: multicast]], [[ref: unicast]].
243
-
244
- ~ Supporting definitions:
245
-
246
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/broadcast): Transmission to all devices in a network without any acknowledgment by the receivers.
247
-
248
- [[def: broadcast address, broadcast addresses]]
249
- ~ A broadcast address is a [[ref: network address]] used to transmit to all devices connected to a multiple-access [[ref: communications]] network. A [[ref: message]] sent to a broadcast address may be received by all network-attached [[ref: hosts]]. In contrast, a [[ref: multicast address]] is used to address a specific group of devices, and a [[ref: unicast address]] is used to address a single device. For network layer communications, a broadcast address may be a specific [[ref: IP address]].
250
-
251
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Network_address).
252
-
253
- [[def: C2PA]]
254
- ~ See: [[ref: Coalition for Content Provenance and Authenticity]].
255
-
256
- [[def: CA, CAs]]
257
- ~ See: [[ref: certificate authority]].
258
-
259
- [[def: CAI]]
260
- ~ See: [[ref: Content Authenticity Initiative]].
261
-
262
- [[def: capability, capabilities]]
263
- ~ The ability for an [[ref: actor]] or [[ref: agent]] to perform a specific [[ref: action]] on behalf of [[ref: party]].
264
-
265
- [[def: certificate, certificates]]
266
- ~ See: [[ref: public key certificate]].
267
-
268
- [[def: certificate authority, certificate authorities]]
269
- ~ The entity in a [[ref: public key infrastructure]] (PKI) that is responsible for issuing [[ref: public key certificates]] and exacting compliance to a PKI policy.
270
-
271
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/certificate_authority).
272
-
273
- ~ Also known as: [[ref: certification authority]].
274
-
275
- ~ Supporting definitions:
276
-
277
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Certificate_authority): In [cryptography](https://en.wikipedia.org/wiki/Cryptography), a certificate authority or certification authority (CA) is an entity that stores, signs, and issues [digital certificates](https://en.wikipedia.org/wiki/Public_key_certificate). A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate.[<sup>\[1\]</sup>](https://en.wikipedia.org/wiki/Certificate_authority#cite_note-1) The format of these certificates is specified by the [X.509](https://en.wikipedia.org/wiki/X.509) or [EMV](https://en.wikipedia.org/wiki/EMV) standard.
278
-
279
- [[def: certification, certifications]]
280
- ~ A comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security [[ref: accreditation]], to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security [[ref: requirements]] for the system.
281
-
282
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/certification).
283
-
284
- ~ See also: [[ref: accreditation]]
285
-
286
- [[def: certification authority, certification authorities]]
287
- ~ See: [[ref: certificate authority]].
288
-
289
- [[def: certification body, certification bodies]]
290
- ~ A [[ref: legal entity]] that performs [[ref: certification]].
291
-
292
- ~ For more information: <https://en.wikipedia.org/wiki/Professional_certification>
293
-
294
- [[def: chain of trust, chains of trust]]
295
- ~ See: [[ref: trust chain]].
296
-
297
- [[def: chained credentials]]
298
- ~ Two or more [[ref: credentials]] linked together to create a [[ref: trust chain]] between the credentials that is [[ref: cryptographically verifiable]].
299
-
300
- ~ Note: [[ref: ACDCs]] are a type of [[ref: digital credential]] that explicitly supports [[ref: chaining]].
301
-
302
- [[def: chaining]]
303
- ~ See: [[ref: trust chain]].
304
-
305
- [[def: channel, channels]]
306
- ~ See: [[ref: communication channel]].
307
-
308
- [[def: ciphertext, ciphertexts]]
309
- ~ [[ref: Encrypted]] (enciphered) [[ref: data]]. The [[ref: confidential]] form of the [[ref: plaintext]] that is the output of the [[ref: encryption]] function.
310
-
311
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/ciphertext).
312
-
313
- [[def: claim, claims, claimed, claiming]]
314
- ~ An assertion about a [[ref: subject]], typically expressed as an [[ref: attribute]] or [[ref: property]] of the [[ref: subject]]. It is called a “claim” because the assertion is always made by some [[ref: party]], called the [[ref: issuer]] of the claim, and the [[ref: validity]] of the claim must be judged by the [[ref: verifier]].
315
-
316
- ~ Supporting definitions:
317
-
318
- ~ [W3C VC](https://www.w3.org/TR/vc-data-model/#terminology): An assertion made about a [subject](https://www.w3.org/TR/vc-data-model/#dfn-subjects).
319
-
320
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Claims-based_identity): A claim is a statement that one subject, such as a person or organization, makes about itself or another subject. For example, the statement can be about a name, group, buying preference, ethnicity, privilege, association or capability.
321
-
322
- ~ Note: If the [[ref: issuer]] of the claim is also the [[ref: subject]] of the claim, the claim is [[ref: self-asserted]].
323
-
324
- [[def: Coalition for Content Provenance and Authenticity]]
325
- ~ C2PA is a Joint Development Foundation project of the Linux Foundation that addresses the prevalence of misleading information online through the development of technical standards for certifying the source and history (or provenance) of media content.
326
-
327
- ~ Also known as: [[ref: C2PA]].
328
-
329
- ~ See also: [[ref: Content Authenticity Initiative]].
330
-
331
- [[def: communication, communications]]
332
- ~ The transmission of information.
333
-
334
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Communication).
335
-
336
- ~ See also: [[ref: ToIP communication]].
337
-
338
- [[def: communication endpoint, communication endpoints, communications endpoint, communications endpoints]]
339
- ~ A type of communication network node. It is an interface exposed by a communicating party or by a [[ref: communication channel]]. An example of the latter type of a communication endpoint is a publish-subscribe topic or a group in group communication systems.
340
-
341
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Communication_endpoint).
342
-
343
- ~ See also: [[ref: ToIP endpoint]].
344
-
345
- [[def: communication channel, communication channels]]
346
- ~ A communication channel refers either to a physical transmission medium such as a wire, or to a logical [[ref: connection]] over a multiplexed medium such as a radio channel in telecommunications and computer networking. A channel is used for information transfer of, for example, a digital bit stream, from one or several senders to one or several receivers.
347
-
348
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Communication_channel).
349
-
350
- ~ See also: [[ref: ToIP channel]].
351
-
352
- ~ Supporting definitions:
353
-
354
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/terms/communication-channel): a (digital or non-digital) means by which two [actors](https://essif-lab.github.io/framework/docs/terms/actor) can exchange messages with one another.
355
-
356
- [[def: communication metadata, communications metadata]]
357
- ~ [[ref: Metadata]] that describes the sender, receiver, [[ref: routing]], handling, or contents of a [[ref: communication]]. Communication metadata is often observable even if the contents of the [[ref: communication]] are encrypted.
358
-
359
- ~ See also: [[ref: correlation privacy]].
360
-
361
- [[def: communication session, communication sessions, communications session, communications sessions]]
362
- ~ A finite period for which a [[ref: communication channel]] is instantiated and maintained, during which certain [[ref: properties]] of that channel, such as authentication of the participants, are in effect. A session has a beginning, called the session initiation, and an ending, called the session termination.
363
-
364
- ~ Supporting definitions:
365
-
366
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/session): A persistent interaction between a subscriber and an end point, either a relying party or a Credential Service Provider. A session begins with an authentication event and ends with a session termination event. A session is bound by use of a session secret that the subscriber’s software (a browser, application, or operating system) can present to the relying party or the Credential Service Provider in lieu of the subscriber’s authentication credentials.
367
-
368
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Session_\(computer_science\)): In [computer science](https://en.wikipedia.org/wiki/Computer_science) and [networking](https://en.wikipedia.org/wiki/Computer_network) in particular, a session is a time-delimited two-way link, a practical (relatively high) layer in the [TCP/IP protocol](https://en.wikipedia.org/wiki/Internet_protocol_suite) enabling interactive expression and information exchange between two or more communication devices or ends – be they computers, [automated systems](https://en.wikipedia.org/wiki/Automation), or live active users (see [login session](https://en.wikipedia.org/wiki/Login_session)). A session is established at a certain point in time, and then ‘torn down’ - brought to an end - at some later point. An established communication session may involve more than one message in each direction. A session is typically [stateful](https://en.wikipedia.org/wiki/Stateful), meaning that at least one of the communicating parties needs to hold current state information and save information about the session history to be able to communicate, as opposed to [stateless](https://en.wikipedia.org/wiki/Stateless_server) communication, where the communication consists of independent [requests](https://en.wikipedia.org/wiki/Request-response) with responses. An established session is the basic requirement to perform a [connection-oriented communication](https://en.wikipedia.org/wiki/Connection-oriented_communication). A session also is the basic step to transmit in [connectionless communication](https://en.wikipedia.org/wiki/Connectionless_communication) modes. However, any unidirectional transmission does not define a session.
369
-
370
- [[def: complex password, complex passwords]]
371
- ~ A [[ref: password]] that meets certain security requirements, such as minimum length, inclusion of different character types, non-repetition of characters, and so on.
372
-
373
- ~ Supporting definitions:
374
-
375
- ~ [Science Direct](https://www.sciencedirect.com/topics/computer-science/complex-password): According to Microsoft, complex passwords consist of at least seven characters, including three of the following four character types: uppercase letters, lowercase letters, numeric digits, and non-alphanumeric characters such as & $ \* and !
376
-
377
- [[def: compliance, comply, complies, complied, complying, compliant]]
378
- ~ In the context of decentralized digital trust infrastructure, compliance is the extent to which a system, [[ref: actor]], or [[ref: party]] conforms to the requirements of a regulation, [[ref: governance framework]], or [[ref: trust framework]] that pertains to that particular [[ref: entity]].
379
-
380
- ~ See also: [[ref: Governance, Risk Management, and Compliance]].
381
-
382
- ~ Supporting definitions:
383
-
384
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#compliance): The state of realization of a set of conformance criteria or normative framework of a [party](https://essif-lab.github.io/framework/docs/terms/party).
385
-
386
- [[def: concept, concepts]]
387
- ~ An abstract idea that enables the classification of [[ref: entities]], i.e., a mental construct that enables an instance of a class of [[ref: entities]] to be distinguished from [[ref: entities]] that are not an instance of that class. A concept can be [[ref: identified]] with a [[ref: term]].
388
-
389
- ~ Supporting definitions:
390
-
391
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#concept): the ideas/thoughts behind a classification of [entities](https://essif-lab.github.io/framework/docs/terms/entity) (what makes [entities](https://essif-lab.github.io/framework/docs/terms/entity) in that class 'the same').
392
-
393
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Concept): A concept is defined as an [abstract](https://en.wikipedia.org/wiki/Abstraction) [idea](https://en.wikipedia.org/wiki/Idea). It is understood to be a fundamental building block underlying principles, [thoughts](https://en.wikipedia.org/wiki/Thought) and [beliefs](https://en.wikipedia.org/wiki/Belief). Concepts play an important role in all aspects of [cognition](https://en.wikipedia.org/wiki/Cognition).
394
-
395
- [[def: confidential computing]]
396
- ~ Hardware-enabled features that isolate and process [[ref: encrypted]] [[ref: data]] in memory so that the [[ref: data]] is at less risk of exposure and compromise from concurrent workloads or the underlying system and platform.
397
-
398
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/confidential_computing).
399
-
400
- ~ Supporting definitions:
401
-
402
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Confidential_computing): Confidential computing is a security and [privacy-enhancing computational technique](https://en.wikipedia.org/wiki/Privacy-enhancing_technologies) focused on protecting [data in use](https://en.wikipedia.org/wiki/Data_in_use). Confidential computing can be used in conjunction with storage and network encryption, which protect [data at rest](https://en.wikipedia.org/wiki/Data_at_rest) and [data in transit](https://en.wikipedia.org/wiki/Data_in_transit) respectively. It is designed to address software, protocol, cryptographic, and basic physical and supply-chain attacks, although some critics have demonstrated architectural and [side-channel attacks](https://en.wikipedia.org/wiki/Side-channel_attack) effective against the technology.
403
-
404
- [[def: confidentiality, confidential]]
405
- ~ In a [[ref: communications]] context, a type of privacy protection in which [[ref: messages]] use [[ref: encryption]] or other privacy-preserving technologies so that only [[ref: authorized]] [[ref: parties]] have access.
406
-
407
- ~ See also: [[ref: authenticity]], [[ref: correlation privacy]].
408
-
409
- ~ Supporting definitions:
410
-
411
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/confidentiality): Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
412
-
413
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Confidentiality): Confidentiality involves a set of rules or a promise usually executed through [confidentiality agreements](https://en.wikipedia.org/wiki/Confidentiality_agreements) that limits the access or places restrictions on certain types of [information](https://en.wikipedia.org/wiki/Information).
414
-
415
- [[def: connection, connections]]
416
- ~ A [[ref: communication channel]] established between two [[ref: communication endpoints]]. A connection may be ephemeral or persistent.
417
-
418
- ~ See also: [[ref: ToIP connection]].
419
-
420
- [[def: Content Authenticity Initiative]]
421
- ~ The Content Authenticity Initiative (CAI) is an association founded in November 2019 by Adobe, the New York Times and Twitter. The CAI promotes an industry standard for provenance [[ref: metadata]] defined by the [[ref: C2PA]]. The CAI cites curbing disinformation as one motivation for its activities.
422
-
423
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Content_Authenticity_Initiative).
424
-
425
- ~ Also known as: [[ref: CAI]].
426
-
427
- [[def: controller, controllers]]
428
- ~ In the context of digital [[ref: communications]], the [[ref: entity]] in control of sending and receiving digital [[ref: communications]]. In the context of decentralized digital trust infrastructure, the [[ref: entity]] in control of the [[ref: cryptographic keys]] necessary to perform [[ref: cryptographically verifiable]] [[ref: actions]] using a [[ref: digital agent]] and [[ref: digital wallet]]. In a ToIP context, the [[ref: entity]] in control of a [[ref: ToIP endpoint]].
429
-
430
- ~ See also: [[ref: device controller]], [[ref: DID controller]], [[ref: ToIP controller]].
431
-
432
- ~ Supporting definitions:
433
-
434
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#controller): the role that an [actor](https://essif-lab.github.io/framework/docs/terms/actor) performs as it is executing actions on that [entity](https://essif-lab.github.io/framework/docs/terms/entity) for the purpose of ensuring that the [entity](https://essif-lab.github.io/framework/docs/terms/entity) will act/behave, or be used, in a particular way.
435
-
436
- [[def: consent management]]
437
- ~ A system, process or set of policies under which a [[ref: person]] agrees to share [[ref: personal data]] for specific usages. A consent management system will typically create a [[ref: record]] of such consent.
438
-
439
- ~ Supporting definitions:
440
-
441
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Consent_management): Consent management is a system, process or set of policies for allowing consumers and patients to determine what health information they are willing to permit their various care providers to access. It enables patients and consumers to affirm their participation in e-health initiatives and to establish consent directives to determine who will have access to their protected health information (PHI), for what purpose and under what circumstances. Consent management supports the dynamic creation, management and enforcement of consumer, organizational and jurisdictional privacy policies.
442
-
443
- [[def: controlled document, controlled documents]]
444
- ~ A [[ref: governance document]] whose authority is derived from a primary document.
445
-
446
- [[def: correlation privacy]]
447
- ~ In a [[ref: communications]] context, a type of privacy protection in which [[ref: messages]] use [[ref: encryption]], [[ref: hashes]], or other privacy-preserving technologies to avoid the use of [[ref: identifiers]] or other content that [[ref: unauthorized]] [[ref: parties]] may use to correlate the sender and/or receiver(s).
448
-
449
- ~ See also: [[ref: authenticity]], [[ref: confidentiality]].
450
-
451
- [[def: counterparty, counterparties]]
452
- ~ From the perspective of one [[ref: party]], the other [[ref: party]] in a [[ref: transaction]], such as a financial transaction.
453
-
454
- ~ See also: [[ref: first party]], [[ref: second party]], [[ref: third party]].
455
-
456
- ~ Supporting definitions:
457
-
458
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Counterparty): A counterparty (sometimes contraparty) is a [legal entity](https://en.wikipedia.org/wiki/Juristic_person), [unincorporated entity](https://en.wikipedia.org/wiki/Unincorporated_entity), or collection of entities to which an exposure of [financial risk](https://en.wikipedia.org/wiki/Financial_risk) may exist.
459
-
460
- [[def: credential, credentials]]
461
- ~ A container of [[ref: claims]] describing one or more [[ref: subjects]]. A credential is generated by the [[ref: issuer]] of the credential and given to the [[ref: holder]] of the credential. A credential typically includes a signature or some other means of proving its [[ref: authenticity]]. A credential may be either a [[ref: physical credential]] or a [[ref: digital credential]].
462
-
463
- ~ See also: [[ref: verifiable credential]].
464
-
465
- ~ Supporting definitions:
466
-
467
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/terms/credential): data, representing a set of [assertions](https://essif-lab.github.io/framework/docs/terms/assertion) (claims, statements), authored and signed by, or on behalf of, a specific [party](https://essif-lab.github.io/framework/docs/terms/party).
468
-
469
- ~ [W3C VC](https://www.w3.org/TR/vc-data-model/#terminology): A set of one or more [claims](https://www.w3.org/TR/vc-data-model/#dfn-claims) made by an [issuer](https://www.w3.org/TR/vc-data-model/#dfn-issuers).
470
-
471
- [[def: credential family, credential families]]
472
- ~ A set of related [[ref: digital credentials]] defined by a [[ref: governing body]] (typically in a [[ref: governance framework]]) to empower [[ref: transitive trust decisions]] among the participants in a [[ref: digital trust ecosystem]].
473
-
474
- [[def: credential governance framework, credential governance frameworks]]
475
- ~ A [[ref: governance framework]] for a [[ref: credential family]]. A credential governance framework may be included within or referenced by an [[ref: ecosystem governance framework]].
476
-
477
- [[def: credential offer, credential offers]]
478
- ~ A protocol request invoked by an [[ref: issuer]] to offer to [[ref: issue]] a [[ref: digital credential]] to the  [[ref: holder]] of a [[ref: digital wallet]]. If the request is invoked by the [[ref: holder]], it is called an [[ref: issuance request]].
479
-
480
- [[def: credential request, credential requests]]
481
- ~ See: [[ref: issuance request]].
482
-
483
- [[def: credential schema, credential schemas]]
484
- ~ A [[ref: data schema]] describing the structure of a [[ref: digital credential]]. The [[ref: W3C Verifiable Credentials Data Model Specification]] defines a set of requirements for credential schemas.
485
-
486
- [[def: criterion]]
487
- ~ In the context of [[ref: terminology]], a written description of a [[ref: concept]] that anyone can evaluate to determine whether or not an [[ref: entity]] is an instance or example of that [[ref: concept]]. Evaluation leads to a yes/no result.
488
-
489
- [[def: cryptographic binding, cryptographic bindings]]
490
- ~ Associating two or more related elements of information using cryptographic techniques.
491
-
492
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/cryptographic_binding).
493
-
494
- [[def: cryptographic key, cryptographic keys, cryptographic key pair, cryptographic key pairs]]
495
- ~ A key in cryptography is a piece of information, usually a string of numbers or letters that are stored in a file, which, when processed through a cryptographic algorithm, can encode or decode cryptographic [[ref: data]]. Symmetric cryptography refers to the practice of the same [[ref: key]] being used for both [[ref: encryption]] and [[ref: decryption]]. Asymmetric cryptography has separate [[ref: keys]] for [[ref: encrypting]] and [[ref: decrypting]]. These keys are known as the [[ref: public keys]] and [[ref: private keys]], respectively.
496
-
497
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Key_\(cryptography\)).
498
-
499
- ~ See also: [[ref: controller]].
500
-
501
- [[def: cryptographic trust]]
502
- ~ A specialized type of [[ref: technical trust]] that is achieved using cryptographic algorithms.
503
-
504
- ~ Contrast with: [[ref: human trust]].
505
-
506
- [[def: cryptographic verifiability, cryptographic verification]]
507
- ~ The [[ref: property]] of being [[ref: cryptographically verifiable]].
508
-
509
- ~ Contrast with: [[ref: human auditability]].
510
-
511
- [[def: cryptographically verifiable, cryptographically verified]]
512
- ~ A property of a data structure that has been [[ref: digitally signed]] using a [[ref: private key]] such that the [[ref: digital signature]] can be verified using the [[ref: public key]]. [[ref: Verifiable data]], [[ref: verifiable messages]], [[ref: verifiable credentials]], and [[ref: verifiable data registries]] are all cryptographically verifiable. Cryptographic verifiability is a primary goal of the [[ref: ToIP Technology Stack]].
513
-
514
- ~ See also: [[ref: tamper evident]], [[ref: tamper resistant]].
515
-
516
- ~ Contrast with: [[ref: human auditable]].
517
-
518
- [[def: cryptographically bound]]
519
- ~ A state in which two or more elements of information have a [[ref: cryptographic binding]].
520
-
521
- [[def: cryptography]]
522
- ~ TODO
523
-
524
- [[def: custodial wallet, custodial wallets]]
525
- ~ A [[ref: digital wallet]] that is directly in the custody of a [[ref: principal]], i.e., under the principal’s direct personal or organizational control. A [[ref: digital wallet]] that is in the custody of a [[ref: third party]] is called a [[ref: non-custodial wallet]].
526
-
527
- [[def: custodian, custodians]]
528
- ~ A [[ref: third party]] that has been assigned rights and duties in a [[ref: custodianship arrangement]] for the purpose of hosting and safeguarding a [[ref: principal]]'s [[ref: private keys]], [[ref: digital wallet]] and [[ref: digital assets]] on the [[ref: principal]]’s behalf. Depending on the [[ref: custodianship arrangement]], the custodian may act as an exchange and provide additional services, such as staking, lending, account recovery, or security features.
529
-
530
- ~ Contrast with: [[ref: guardian]], [[ref: zero-knowledge service provider]].
531
-
532
- ~ See also: [[ref: custodial wallet]].
533
-
534
- ~ Supporting definitions:
535
-
536
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/custodian): A third-party [[ref: entity]] that holds and safeguards a user’s [[ref: private keys]] or digital assets on their behalf. Depending on the system, a custodian may act as an exchange and provide additional services, such as staking, lending, account recovery, or security features.
537
-
538
- ~ Note: While a custodian technically has the necessary access to in theory [[ref: impersonate]] the [[ref: principal]], in most cases a custodian is expressly prohibited from taking any action on the [[ref: principal]]’s account unless explicitly [[ref: authorized]] by the [[ref: principal]]. This is what distinguishes custodianship from [[ref: guardianship]].
539
-
540
- [[def: custodianship arrangement, custodianship arrangements]]
541
- ~ The informal terms or formal legal agreement under which a [[ref: custodian]] agrees to provide service to a [[ref: principal]].
542
-
543
- [[def: dark pattern, dark patterns]]
544
- ~ A design pattern, mainly in user interfaces, that has the effect of deceiving individuals into making choices that are advantageous to the designer.
545
-
546
- ~ Source: Kantara PEMC Implementors Guidance Report
547
-
548
- ~ Also known as: [[ref: deceptive pattern]].
549
-
550
- [[def: data, datum]]
551
- ~ In the pursuit of [[ref: knowledge]], data is a collection of discrete values that convey information, describing quantity, quality, fact, statistics, other basic units of meaning, or simply sequences of symbols that may be further interpreted. A datum is an individual value in a collection of data.
552
-
553
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Data).
554
-
555
- ~ See also: [[ref: verifiable data]].
556
-
557
- ~ Supporting definitions:
558
-
559
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#data): something (tangible) that can be used to communicate a meaning (which is intangible/information).
560
-
561
- [[def: datagram, datagrams]]
562
- ~ See: [[ref: data packet]].
563
-
564
- [[def: data packet, data packets]]
565
- ~ In telecommunications and computer networking, a network packet is a formatted unit of [[ref: data]] carried by a packet-switched network such as the Internet. A packet consists of control information and user [[ref: data]]; the latter is also known as the payload. Control information provides data for delivering the payload (e.g., source and destination network addresses, error detection codes, or sequencing information). Typically, control information is found in packet headers and trailers.
566
-
567
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Network_packet).
568
-
569
- [[def: data schema, data schemas]]
570
- ~ A description of the structure of a digital document or object, typically expressed in a [[ref: machine-readable]] language in terms of constraints on the structure and content of documents or objects of that type. A credential schema is a particular type of data schema.
571
-
572
- ~ Supporting definitions:
573
-
574
- ~ [Wikipedia](https://en.wikipedia.org/wiki/XML_schema): An XML schema is a description of a type of [XML](https://en.wikipedia.org/wiki/Extensible_Markup_Language) document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntactical constraints imposed by XML itself. These constraints are generally expressed using some combination of grammatical rules governing the order of elements, [Boolean predicates](https://en.wikipedia.org/wiki/Boolean_predicates) that the content must satisfy, data types governing the content of elements and attributes, and more specialized rules such as [uniqueness](https://en.wikipedia.org/wiki/Uniqueness_quantification) and [referential integrity](https://en.wikipedia.org/wiki/Referential_integrity) constraints.
575
-
576
- [[def: data subject, data subjects]]
577
- ~ The [[ref: natural person]] that is described by [[ref: personal data]]. Data subject is the term used by the EU [[ref: General Data Protection Regulation]].
578
-
579
- [[def: data vault, data vaults]]
580
- ~ See: [[ref: digital vault]].
581
-
582
- [[def: decentralized identifier, decentralized identifiers, DID, DIDs]]
583
- ~ A globally unique persistent [[ref: identifier]] that does not require a centralized [[ref: registration]] [[ref: authority]] and is often generated and/or registered cryptographically. The generic format of a DID is defined in section [3.1 DID Syntax](https://www.w3.org/TR/did-core/#did-syntax) of the [W3C Decentralized Identifiers (DIDs) 1.0](https://www.w3.org/TR/did-core/) specification. A specific DID scheme is defined in a [[ref: DID method]] specification.
584
-
585
- ~ Source: [W3C DID](https://www.w3.org/TR/did-core/#terminology).
586
-
587
- ~ Also known as: [[ref: DID]].
588
-
589
- ~ See also: [[ref: DID method]], [[ref: DID URL]].
590
-
591
- [[def: decentralized identity, decentralized identities]]
592
- ~ A [[ref: digital identity]] architecture in which a [[ref: digital identity]] is established via the control of a set of [[ref: cryptographic keys]] in a [[ref: digital wallet]] so that the [[ref: controller]] is not dependent on any external [[ref: identity provider]] or other [[ref: third party]].
593
-
594
- ~ See also: [[ref: federated identity]], [[ref: self-sovereign identity]].
595
-
596
- [[def: Decentralized Identity Foundation]]
597
- ~ A non-profit project of the [Linux Foundation](https://www.linuxfoundation.org/) chartered to develop the foundational components of an open, standards-based, [[ref: decentralized identity]] [[ref: ecosystem]] for people, [[ref: organizations]], apps, and devices.
598
-
599
- ~ See also: [[ref: OpenWallet Foundation]], [[ref: ToIP Foundation]].
600
-
601
- ~ For more information, see: <http://identity.foundation/>
602
-
603
- [[def: Decentralized Web Node, Decentralized Web Nodes]]
604
- ~ A decentralized personal and application data storage and message relay node, as defined in the DIF Decentralized Web Node specification. Users may have multiple nodes that replicate their data between them.
605
-
606
- ~ Source: [DIF DWN Specification](https://identity.foundation/decentralized-web-node/spec/).
607
-
608
- ~ Also known as: DWN.
609
-
610
- ~ For more information, see: <https://identity.foundation/decentralized-web-node/spec/>
611
-
612
- [[def: deceptive pattern, deceptive patterns]]
613
- ~ See: [[ref: dark pattern]].
614
-
615
- [[def: decryption, decrypt, decrypts, decrypting, decrypted]]
616
- ~ The process of changing [[ref: ciphertext]] into [[ref: plaintext]] using a cryptographic algorithm and [[ref: key]]. The opposite of [[ref: encryption]].
617
-
618
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/decryption).
619
-
620
- [[def: deep link, deep links, deep linking, deep linked]]
621
- ~ In the context of the World Wide Web, deep linking is the use of a hyperlink that links to a specific, generally searchable or indexed, piece of web content on a website (e.g. "https\://example.com/path/page"), rather than the website's home page (e.g., "https\://example.com"). The URL contains all the information needed to point to a particular item. Deep linking is different from [[ref: mobile deep linking]], which refers to directly linking to in-app content using a non-HTTP URI.
622
-
623
- ~ See also: [[ref: out-of-band introduction]].
624
-
625
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Deep_linking).
626
-
627
- [[def: definition, definitions]]
628
- ~ A textual statement defining the meaning of a [[ref: term]] by specifying [[ref: criterion]] that enable the [[ref: concept]] identified by the [[ref: term]] to be distinguished from all other [[ref: concepts]] within the intended [[ref: scope]].
629
-
630
- ~ Supporting definitions:
631
-
632
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#definition): a text that helps [parties](https://essif-lab.github.io/framework/docs/@) to have the same understanding about the meaning of (and [concept](https://essif-lab.github.io/framework/docs/@) behind) a [term](https://essif-lab.github.io/framework/docs/@), ideally in such a way that these [parties](https://essif-lab.github.io/framework/docs/@) can determine whether or not they make the same distinction.
633
-
634
- ~ Wikipedia: A definition is a statement of the meaning of a term (a [word](https://en.wikipedia.org/wiki/Word), [phrase](https://en.wikipedia.org/wiki/Phrase), or other set of [symbols](https://en.wikipedia.org/wiki/Symbol)). Definitions can be classified into two large categories: [intensional definitions](https://en.wikipedia.org/wiki/Intensional_definition) (which try to give the sense of a term), and [extensional definitions](https://en.wikipedia.org/wiki/Extensional_definition) (which try to list the objects that a term describes). Another important category of definitions is the class of [ostensive definitions](https://en.wikipedia.org/wiki/Ostensive_definition), which convey the meaning of a term by pointing out examples. A term may have many different senses and multiple meanings, and thus require multiple definitions.
635
-
636
- [[def: delegatee, delegatees]]
637
- ~ The [[ref: second party]] receiving a [[ref: delegation]] from a [[ref: first party]] (the [[ref: delegator]]).
638
-
639
- [[def: delegation, delegate, delegated, delegates]]
640
- ~ The act of a [[ref: first party]] [[ref: authorizing]] a [[ref: second party]] to perform a set of [[ref: actions]] for or on behalf of the [[ref: first party]]. Delegation may be performed by the first party (the [[ref: delegator]]) issuing a [[ref: delegation credential]] that gives a certain set of [[ref: capabilities]] to the [[ref: second party]] (the [[ref: delegatee]]).
641
-
642
- [[def: delegator, delegators]]
643
- ~ The [[ref: first party]] making a [[ref: delegation]] to a [[ref: second party]] (the [[ref: delegatee]]).
644
-
645
- ~ Supporting definitions:
646
-
647
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab): the transferral of [ownership](https://essif-lab.github.io/framework/docs/terms/ownership) of one or more obligation of a [party](https://essif-lab.github.io/framework/docs/terms/party) (the [delegator](https://essif-lab.github.io/framework/docs/terms/delegate)), including the associated accountability, to another party (the [delegatee](https://essif-lab.github.io/framework/docs/terms/delegate)), which implies that the delegatee can realize such obligation as it sees fit.
648
-
649
- [[def: delegation credential, delegation credentials]]
650
- ~ A [[ref: credential]] used to perform [[ref: delegation]].
651
-
652
- [[def: dependent, dependents]]
653
- ~ An [[ref: entity]] for the caring for and/or protecting/guarding/defending of which a [[ref: guardianship arrangement]] has been established with a [[ref: guardian]].
654
-
655
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#dependent)
656
-
657
- ~ See also: [[ref: custodian]].
658
-
659
- ~ Mental Model: [eSSIF-Lab Guardianship](https://essif-lab.github.io/framework/docs/terms/pattern-guardianship)
660
-
661
- [[def: device controller, device controllers]]
662
- ~ The [[ref: controller]] of a device capable of digital [[ref: communications]], e.g., a smartphone, tablet, laptop, IoT device, etc.
663
-
664
- [[def: dictionary, dictionaries]]
665
- ~ A dictionary is a listing of lexemes (words or [[ref: terms]]) from the lexicon of one or more specific languages, often arranged alphabetically, which may include information on [[ref: definitions]], usage, etymologies, pronunciations, translation, etc. It is a lexicographical reference that shows inter-relationships among the [[ref: data]]. Unlike a [[ref: glossary]], a dictionary may provide multiple [[ref: definitions]] of a [[ref: term]] depending on its [[ref: scope]] or context.
666
-
667
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Dictionary).
668
-
669
- [[def: DID]]
670
- ~ See: [[ref: decentralized identifier]]
671
-
672
- [[def: DID controller, DID controllers]]
673
- ~ An [[ref: entity]] that has the capability to make changes to a [[ref: DID document]]. A [[ref: DID]] might have more than one DID controller. The DID controller(s) can be denoted by the optional `controller` property at the top level of the [[ref: DID document]]. Note that a DID controller might be the [[ref: DID subject]].
674
-
675
- ~ Source: [W3C DID](https://www.w3.org/TR/did-core/#terminology).
676
-
677
- ~ See also: [[ref: controller]].
678
-
679
- [[def: DID document, DID documents, DID doc, DID docs]]
680
- ~ A set of data describing the [[ref: DID subject]], including mechanisms, such as cryptographic public keys, that the [[ref: DID subject]] or a DID [[ref: delegate]] can use to [[ref: authenticate]] itself and prove its association with the [[ref: DID]]. A DID document might have one or more different representations as defined in section 6 of the [W3C Decentralized Identifiers (DIDs) 1.0](https://www.w3.org/TR/did-core/) specification.
681
-
682
- ~ Source: [W3C DID](https://www.w3.org/TR/did-core/#terminology).
683
-
684
- [[def: DID method, DID methods]]
685
- ~ A definition of how a specific DID method scheme is implemented. A DID method is defined by a DID method specification, which specifies the precise operations by which [[ref: DIDs]] and [[ref: DID documents]] are created, resolved, updated, and deactivated.
686
-
687
- ~ Source: [W3C DID](https://www.w3.org/TR/did-core/#dfn-did-methods).
688
-
689
- ~ For more information: <https://www.w3.org/TR/did-core/#methods>
690
-
691
- [[def: DID subject, DID subjects]]
692
- ~ The [[ref: entity]] identified by a [[ref: DID]] and described by a [[ref: DID document]]. Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc.
693
-
694
- ~ Source: [W3C DID](https://www.w3.org/TR/did-core/#dfn-did-subjects).
695
-
696
- ~ See also: [[ref: subject]].
697
-
698
- [[def: DID URL, DID URLs]]
699
- ~ A [[ref: DID]] plus any additional syntactic component that conforms to the definition in section 3.2 of the [W3C Decentralized Identifiers (DIDs) 1.0](https://www.w3.org/TR/did-core/) specification. This includes an optional DID path (with its leading / character), optional DID query (with its leading ? character), and optional DID fragment (with its leading # character).
700
-
701
- ~ Source: [W3C DID](https://www.w3.org/TR/did-core/#dfn-did-urls).
702
-
703
- [[def: digital agent, digital agents]]
704
- ~ In the context of ​​decentralized digital trust infrastructure, a [[ref: software agent]] that operates in conjunction with a [[ref: digital wallet]] to take [[ref: actions]] on behalf of its [[ref: controller]].
705
-
706
- ~ Note: In a ToIP context, a digital agent is frequently assumed to have privileged access to the [[ref: digital wallets]] of its principal. In market parlance, a mobile app that performs the [[ref: actions]] of a digital agent is often simply called a [[ref: wallet]] or a [[ref: digital wallet]].
707
-
708
- [[def: digital asset, digital assets]]
709
- ~ A digital asset is anything that exists only in digital form and comes with a distinct usage right. [[ref: Data]] that do not possess that right are not considered assets.
710
-
711
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Digital_asset).
712
-
713
- ~ See also: [[ref: digital credential]].
714
-
715
- [[def: digital certificate, digital certificates]]
716
- ~ See: [[ref: public key certificate]].
717
-
718
- [[def: digital credential, digital credentials]]
719
- ~ A [[ref: credential]] in digital form that is signed with a [[ref: digital signature]] and held in a [[ref: digital wallet]]. A digital credential is issued to a [[ref: holder]] by an [[ref: issuer]]; a [[ref: proof]] of the credential is [[ref: presented]] by the [[ref: holder]] to a [[ref: verifier]].
720
-
721
- ~ See also: [[ref: issuance request]], [[ref: presentation request]], [[ref: verifiable credential]].
722
-
723
- ~ Contrast with: [[ref: physical credential]].
724
-
725
- ~ Supporting definitions:
726
-
727
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Digital_credential): Digital credentials are the digital equivalent of paper-based [credentials](https://en.wikipedia.org/wiki/Credentials). Just as a paper-based credential could be a [passport](https://en.wikipedia.org/wiki/Passport), a [driver's license](https://en.wikipedia.org/wiki/Driver%27s_license), a membership certificate or some kind of ticket to obtain some service, such as a cinema ticket or a public transport ticket, a digital credential is a proof of qualification, competence, or clearance that is attached to a person.
728
-
729
- [[def: digital ecosystem, digital ecosystems]]
730
- ~ A digital ecosystem is a distributed, adaptive, open socio-technical system with properties of self-organization, scalability and sustainability inspired from natural ecosystems. Digital ecosystem models are informed by knowledge of natural ecosystems, especially for aspects related to competition and collaboration among diverse [[ref: entities]].
731
-
732
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Digital_ecosystem).
733
-
734
- ~ See also: [[ref: digital trust ecosystem]], [[ref: trust community]].
735
-
736
- [[def: digital identity, digital identities, digital ID, digital IDs]]
737
- ~ An [[ref: identity]] expressed in a digital form for the purpose representing the identified [[ref: entity]] within a computer system or digital network.
738
-
739
- ~ Supporting definitions:
740
-
741
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary): [Digital data](https://essif-lab.github.io/framework/docs/essifLab-glossary#data) that enables a specific [entity](https://essif-lab.github.io/framework/docs/essifLab-glossary#entity) to be distinguished from all others in a specific context.
742
-
743
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Digital_identity): Digital identity refers to the information utilized by [computer systems](https://en.wikipedia.org/wiki/Computer_systems) to represent external entities, including a person, organization, application, or device. When used to describe an individual, it encompasses a person's compiled information and plays a crucial role in automating access to computer-based services, verifying identity online, and enabling computers to mediate relationships between entities.
744
-
745
- [[def: digital rights management]]
746
- ~ Digital rights management (DRM) is the management of legal access to digital content. Various tools or technological protection measures (TPM) like [[ref: access control]] technologies, can restrict the use of proprietary hardware and copyrighted works. DRM technologies govern the use, modification and distribution of copyrighted works (e.g. software, multimedia content) and of systems that enforce these policies within devices.
747
-
748
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Digital_rights_management).
749
-
750
- ~ Also known as: [[ref: DRM]].
751
-
752
- [[def: digital trust ecosystem, digital trust ecosystems]]
753
- ~ A [[ref: digital ecosystem]] in which the participants are one or more interoperating [[ref: trust communities]]. Governance of the various [[ref: roles]] of [[ref: governed parties]] within a digital trust ecosystem (e.g., [[ref: issuers]], [[ref: holders]], [[ref: verifiers]], [[ref: certification bodies]], [[ref: auditors]]) is typically managed by a [[ref: governing body]] using a [[ref: governance framework]] as recommended in the [[ref: ToIP Governance Stack]]. Many digital trust ecosystems will also maintain one or more [[ref: trust lists]] and/or [[ref: trust registries]].
754
-
755
- [[def: digital trust utility, digital trust utilities]]
756
- ~ An information system, network, distributed database, or [[ref: blockchain]] designed to provide one or more supporting services to higher level components of decentralized digital trust infrastructure. In the [[ref: ToIP stack]], digital trust utilities are at [[ref: Layer 1]]. A [[ref: verifiable data registry]] is one type of digital trust utility.
757
-
758
- [[def: digital signature, digital signatures, digitally sign, digitally signed, digital signing, cryptographic signature, cryptographic signatures]]
759
- ~ A digital signature is a mathematical scheme that uses cryptography for verifying the authenticity of digital [[ref: messages]] or documents. A valid digital signature, where the prerequisites are satisfied, gives a recipient very high confidence that the [[ref: message]] was created by a known sender ([[ref: authenticity]]), and that the message was not altered in transit ([[ref: integrity]]).
760
-
761
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Digital_signature).
762
-
763
- ~ Supporting definitions:
764
-
765
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/digital_signature): The result of a cryptographic transformation of data which, when properly implemented, provides the services of: 1. origin authentication, 2. data integrity, and 3. signer non-repudiation.
766
-
767
- [[def: digital vault, digital vaults]]
768
- ~ A secure container for [[ref: data]] whose [[ref: controller]] is the [[ref: principal]]. A digital vault is most commonly used in conjunction with a [[ref: digital wallet]] and a [[ref: digital agent]]. A digital vault may be implemented on a local device or in the cloud; multiple digital vaults may be used by the same [[ref: principal]] across different devices and/or the cloud; if so they may use some type of synchronization. If the capability is supported, [[ref: data]] may flow into or out of the digital vault automatically based on [[ref: subscriptions]] approved by the [[ref: controller]].
769
-
770
- ~ Also known as: [[ref: data vault]], [[ref: encrypted data vault]].
771
-
772
- ~ See also: [[ref: enterprise data vault]], [[ref: personal data vault]], [[ref: virtual vault]].
773
-
774
- ~ For more information, see: <https://en.wikipedia.org/wiki/Personal_data_service>, <https://digitalbazaar.github.io/encrypted-data-vaults/>
775
-
776
- [[def: digital wallet, digital wallets]]
777
- ~ A [[ref: user agent]], optionally including a hardware component, capable of securely storing and processing [[ref: cryptographic keys]], [[ref: digital credentials]], [[ref: digital assets]] and other sensitive private [[ref: data]] that enables the [[ref: controller]] to perform [[ref: cryptographically verifiable]] operations. A [[ref: non-custodial wallet]] is directly in the custody of a [[ref: principal]]. A [[ref: custodial wallet]] is in the custody of a [[ref: third party]]. [[ref: Personal wallets]] are held by individual persons; [[ref: enterprise wallets]] are held by [[ref: organizations]] or other [[ref: legal entities]].
778
-
779
- ~ See also: [[ref: digital agent]], [[ref: key management system]], [[ref: wallet engine]].
780
-
781
- ~ Supporting definitions:
782
-
783
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#wallet): a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to securely store data as requested by [colleague agents](https://essif-lab.github.io/framework/docs/terms/colleague), and to provide stored data to [colleague agents](https://essif-lab.github.io/framework/docs/terms/colleague) or [peer agents](https://essif-lab.github.io/framework/docs/terms/peer-agent), all in [compliance](https://essif-lab.github.io/framework/docs/terms/compliance) with the rules of its [principal](https://essif-lab.github.io/framework/docs/terms/principal)'s [wallet policy](https://essif-lab.github.io/framework/docs/terms/wallet-policy).
784
-
785
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Digital_wallet): A digital wallet, also known as an e-wallet, is an [electronic device](https://en.wikipedia.org/wiki/Consumer_electronics), [online service](https://en.wikipedia.org/wiki/Online_service_provider), or [software program](https://en.wikipedia.org/wiki/Computer_program) that allows one party to make [electronic transactions](https://en.wikipedia.org/wiki/Electronic_transaction) with another party bartering [digital currency](https://en.wikipedia.org/wiki/Digital_currency) units for [goods and services](https://en.wikipedia.org/wiki/Goods_and_services). This can include purchasing items either [online](https://en.wikipedia.org/wiki/Online_and_offline) or at the [point of sale](https://en.wikipedia.org/wiki/Point_of_sale) in a [brick and mortar](https://en.wikipedia.org/wiki/Brick_and_mortar) store, using either [mobile payment](https://en.wikipedia.org/wiki/Mobile_payment) (on a [smartphone](https://en.wikipedia.org/wiki/Smartphone) or other [mobile device](https://en.wikipedia.org/wiki/Mobile_device)) or (for online buying only) using a [laptop](https://en.wikipedia.org/wiki/Laptop) or other [personal computer](https://en.wikipedia.org/wiki/Personal_computer). Money can be deposited in the digital wallet prior to any transactions or, in other cases, an individual's bank account can be linked to the digital wallet. Users might also have their [driver's license](https://en.wikipedia.org/wiki/Driver%27s_license), [health card](https://en.wikipedia.org/wiki/Health_Care_Card), loyalty card(s) and other ID documents stored within the wallet. The credentials can be passed to a merchant's terminal wirelessly via [near field communication](https://en.wikipedia.org/wiki/Near_field_communication) (NFC).
786
-
787
- ~ Note: In market parlance, a mobile app that performs the [[ref: actions]] of a [[ref: digital agent]] and has access to a set of [[ref: cryptographic keys]] is often simply called a [[ref: wallet]] or a digital wallet.
788
-
789
- [[def: distributed ledger, distributed ledgers, DLT, DLTs]]
790
- ~ A distributed ledger (also called a shared ledger or distributed ledger technology or DLT) is the consensus of replicated, shared, and synchronized digital [[ref: data]] that is geographically spread (distributed) across many sites, countries, or institutions. In contrast to a centralized database, a distributed ledger does not require a central administrator, and consequently does not have a single (central) point-of-failure. In general, a distributed ledger requires a [[ref: peer-to-peer]] (P2P) computer network and consensus algorithms so that the ledger is reliably replicated across distributed computer [[ref: nodes]] (servers, clients, etc.). The most common form of distributed ledger technology is the [[ref: blockchain]], which can either be on a public or private network.
791
-
792
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Distributed_ledger).
793
-
794
- [[def: domain, domains]]
795
- ~ See: [[ref: security domain]].
796
-
797
- ~ See also: [[ref: trust domain]].
798
-
799
- [[def: DRM]]
800
- ~ See: [[ref: digital rights management]].
801
-
802
- [[def: DWN]]
803
- ~ See: [[ref: Decentralized Web Node]].
804
-
805
- [[def: ecosystem, ecosystems]]
806
- ~ See: [[ref: digital ecosystem]].
807
-
808
- [[def: ecosystem governance framework, ecosystem governance frameworks, EGF, EGFs]]
809
- ~ A [[ref: governance framework]] for a [[ref: digital trust ecosystem]]. An ecosystem governance framework may incorporate, aggregate, or reference other types of governance frameworks such as a [[ref: credential governance framework]] or a [[ref: utility governance framework]].
810
-
811
- - Also known as: [[ref: EGF]]
812
-
813
- [[def: eIDAS]]
814
- ~ eIDAS (electronic IDentification, Authentication and trust Services) is an EU regulation with the stated purpose of governing "electronic identification and trust services for electronic transactions". It passed in 2014 and its provisions came into effect between 2016-2018.
815
-
816
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/EIDAS).
817
-
818
- [[def: encrypted data vault, encrypted data vaults]]
819
- ~ See: [[ref: digital vault]].
820
-
821
- [[def: encryption, encrypt, encrypts, encrypted, encrypting]]
822
- ~ Cryptographic transformation of [[ref: data]] (called [[ref: plaintext]]) into a form (called [[ref: ciphertext]]) that conceals the [[ref: data]]'s original meaning to prevent it from being known or used. If the transformation is reversible, the corresponding reversal process is called [[ref: decryption]], which is a transformation that restores encrypted [[ref: data]] to its original state.
823
-
824
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/encryption).
825
-
826
- [[def: end-to-end encryption, end-to-end encrypt]]
827
- ~ [[ref: Encryption]] that is applied to a [[ref: communication]] before it is transmitted from the sender’s [[ref: communication endpoint]] and cannot be [[ref: decrypted]] until after it is received at the receiver’s [[ref: communication endpoint]]. When end-to-end encryption is used, the [[ref: communication]] cannot be [[ref: decrypted]] in transit no matter how many [[ref: intermediaries]] are involved in the [[ref: routing]] process.
828
-
829
- ~ Supporting definitions:
830
-
831
- ~ [Wikipedia](https://en.wikipedia.org/wiki/End-to-end_encryption): End-to-end encryption (E2EE) is a private communication system in which only communicating users can participate. As such, no one, including the communication system provider, [telecom providers](https://en.wikipedia.org/wiki/Telecommunications_service_providers), [Internet providers](https://en.wikipedia.org/wiki/Internet_providers) or malicious actors, can access the [cryptographic keys](https://en.wikipedia.org/wiki/Key_\(cryptography\)) needed to converse. End-to-end [encryption](https://en.wikipedia.org/wiki/Encryption) is intended to prevent data being read or secretly modified, other than by the true sender and recipient(s). The messages are encrypted by the sender but the third party does not have a means to decrypt them, and stores them encrypted. The recipients retrieve the encrypted data and decrypt it themselves.
832
-
833
- [[def: End-to-End Principle]]
834
- ~ The end-to-end principle is a design framework in computer networking. In networks designed according to this principle, guaranteeing certain application-specific features, such as reliability and security, requires that they reside in the communicating end [[ref: nodes]] of the network. [[ref: Intermediary]] nodes, such as [[ref: gateways]] and [[ref: routers]], that exist to establish the network, may implement these to improve efficiency but cannot guarantee end-to-end correctness.
835
-
836
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/End-to-end_principle).
837
-
838
- ~ For more information, see: <https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf>
839
-
840
- [[def: endpoint, endpoints]]
841
- ~ See: [[ref: communication endpoint]].
842
-
843
- ~ See also: [[ref: ToIP endpoint]].
844
-
845
- [[def: endpoint system, endpoint systems]]
846
- ~ The system that operates a [[ref: communications]] [[ref: endpoint]]. In the context of the [[ref: ToIP stack]], an endpoint system is one of three types of systems defined in the [[ref: ToIP Technology Architecture Specification]].
847
-
848
- ~ See also: [[ref: intermediary system]], [[ref: supporting system]].
849
-
850
- [[def: enterprise data vault, enterprise data vaults]]
851
- ~ A [[ref: digital vault]] whose [[ref: controller]] is an [[ref: organization]].
852
-
853
- [[def: enterprise wallet, enterprise wallets]]
854
- ~ A [[ref: digital wallet]] whose [[ref: holder]] is an [[ref: organization]].
855
-
856
- ~ Contrast with: [[ref: personal wallet]].
857
-
858
- [[def: entity, entities]]
859
- ~ Someone or something that is known to exist.
860
-
861
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary).
862
-
863
- [[def: ephemeral connection, ephemeral connections]]
864
- ~ A [[ref: connection]] that only exists for the duration of a single [[ref: communication session]] or [[ref: transaction]].
865
-
866
- ~ Contrast with: [[ref: persistent connection]].
867
-
868
- [[def: expression language, expression languages]]
869
- ~ A language for creating a computer-interpretable ([[ref: machine-readable]]) representation of specific [[ref: knowledge]].
870
-
871
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Expression_language).
872
-
873
- [[def: FAL]]
874
- ~ See: [[ref: federation assurance level]].
875
-
876
- [[def: federated identity, federated identities]]
877
- ~ A [[ref: digital identity]] architecture in which a [[ref: digital identity]] established on one computer system, network, or [[ref: trust domain]] is linked to other computer systems, networks, or [[ref: trust domains]] for the purpose of identifying the same [[ref: entity]] across those domains.
878
-
879
- ~ See also: [[ref: decentralized identity]], [[ref: self-sovereign identity]].
880
-
881
- ~ Supporting definitions:
882
-
883
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/federated_identity_management); A process that allows for the conveyance of identity and authentication information across a set of networked systems.
884
-
885
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Federated_identity): A **federated identity** in [information technology](https://en.wikipedia.org/wiki/Information_technology) is the means of linking a person's [electronic identity](https://en.wikipedia.org/wiki/Digital_identity) and attributes, stored across multiple distinct [identity management](https://en.wikipedia.org/wiki/Identity_management) systems.
886
-
887
- [[def: federation, federate, federates, federated]]
888
- ~ A group of [[ref: organizations]] that collaborate to establish a common [[ref: trust framework]] or [[ref: governance framework]] for the exchange of [[ref: identity data]] in a [[ref: federated identity]] system.
889
-
890
- ~ See also: [[ref: trust community]]
891
-
892
- ~ Supporting definitions:
893
-
894
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/federation): A collection of realms (domains) that have established trust among themselves. The level of trust may vary, but typically includes authentication and may include authorization.
895
-
896
- [[def: federation assurance level, federation assurance levels, FAL, FALs]]
897
- ~ A category that describes the [[ref: federation]] protocol used to communicate an assertion containing [[ref: authentication]]) and [[ref: attribute]] information (if applicable) to a [[ref: relying party]], as defined in [NIST SP 800-63-3](https://pages.nist.gov/800-63-3/) in terms of three levels: FAL 1 (Some confidence), FAL 2 (High confidence), FAL 3 (Very high confidence).
898
-
899
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/federation_assurance_level).
900
-
901
- ~ See also: [[ref: authenticator assurance level]], [[ref: identity assurance level]].
902
-
903
- [[def: fiduciary, fiduciaries]]
904
- ~ A fiduciary is a person who holds a legal or ethical relationship of trust with one or more other [[ref: parties]] (person or group of persons). Typically, a fiduciary prudently takes care of money or other assets for another person. One [[ref: party]], for example, a corporate trust company or the trust department of a bank, acts in a fiduciary capacity to another [[ref: party]], who, for example, has entrusted funds to the fiduciary for safekeeping or investment. In a fiduciary relationship, one person, in a position of vulnerability, justifiably vests confidence, good faith, reliance, and trust in another whose aid, advice, or protection is sought in some matter.
905
-
906
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Fiduciary).
907
-
908
- [[def: first party, first parties]]
909
- ~ The [[ref: party]] who initiates a [[ref: trust relationship]], [[ref: connection]], or [[ref: transaction]] with a [[ref: second party]].
910
-
911
- ~ See also: [[ref: third party]], [[ref: fourth party]].
912
-
913
- [[def: foundational identity, foundational identities]]
914
- ~ A set of [[ref: identity data]], such as a [[ref: credential]], [[ref: issued]] by an [[ref: authoritative source]] for the [[ref: legal identity]] of the [[ref: subject]]. Birth certificates, passports, driving licenses, and other forms of government ID documents are considered foundational [[ref: identity documents]]. Foundational identities are often used to provide [[ref: identity binding]] for [[ref: functional identities]].
915
-
916
- ~ Contrast with: [[ref: functional identity]].
917
-
918
- [[def: fourth party, fourth parties]]
919
- ~ A [[ref: party]] that is not directly involved in the trust relationship between a [[ref: first party]] and a [[ref: second party]], but provides supporting services exclusively to the [[ref: first party]] (in contrast with a [[ref: third party]], who in most cases provides supporting services to the [[ref: second party]]). In its strongest form, a [[ref: fourth party]] has a [[ref: fiduciary]] relationship with the [[ref: first party]].
920
-
921
- [[def: functional identity, functional identities]]
922
- ~ A set of [[ref: identity data]], such as a [[ref: credential]], that is [[ref: issued]] not for the purpose of establishing a [[ref: foundational identity]] for the subject, but for the purpose of establishing other attributes, qualifications, or capabilities of the subject. Loyalty cards, library cards, and employee IDs are all examples of functional identities. [[ref: Foundational identities]] are often used to provide [[ref: identity binding]] for functional identities.
923
-
924
- [[def: gateway, gateways]]
925
- ~ A gateway is a piece of networking hardware or software used in telecommunications networks that allows [[ref: data]] to flow from one discrete network to another. Gateways are distinct from [[ref: routers]] or switches in that they communicate using more than one protocol to connect multiple networks[<sup>\[1\]\[2\]</sup>](https://en.wikipedia.org/wiki/Gateway_\(telecommunications\)#cite_note-1) and can operate at any of the seven layers of the open systems interconnection model (OSI).
926
-
927
- ~ See also: [[ref: intermediary]].
928
-
929
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Gateway_\(telecommunications\)).
930
-
931
- [[def: GDPR]]
932
- ~ See: [[ref: General Data Protection Regulation]].
933
-
934
- [[def: General Data Protection Regulation]]
935
- ~ The General Data Protection Regulation (Regulation (EU) 2016/679, abbreviated GDPR) is a European Union regulation on information privacy in the European Union (EU) and the European Economic Area (EEA). The GDPR is an important component of EU privacy law and human rights law, in particular Article 8(1) of the Charter of Fundamental Rights of the European Union. It also governs the transfer of [[ref: personal data]] outside the EU and EEA. The GDPR's goals are to enhance individuals' control and rights over their personal information and to simplify the regulations for international business.
936
-
937
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation).
938
-
939
- ~ Also known as: [[ref: GDPR]].
940
-
941
- [[def: glossary, glossaries]]
942
- ~ A glossary (from Ancient Greek: γλῶσσα, glossa; language, speech, wording), also known as a _vocabulary_ or _clavis_, is an alphabetical list of [[ref: terms]] in a particular domain of [[ref: knowledge]] ([[ref: scope]]) together with the [[ref: definitions]] for those terms. Unlike a [[ref: dictionary]], a glossary has only one [[ref: definition]] for each term.
943
-
944
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Glossary).
945
-
946
- [[def: governance]]
947
- ~ The [[ref: act]] or process of governing or overseeing the realization of (the results associated with) a set of [[ref: objectives]] by the [[ref: owner]] of these [[ref: objectives]], in order to ensure they will be fit for the purposes that this [[ref: owner]] intends to use them for.
948
-
949
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#governance).
950
-
951
- ~ See also: [[ref: governing body]], [[ref: governance framework]]
952
-
953
- [[def: Governance - Risk Management - Compliance]]
954
- ~ [[ref: Governance]], [[ref: risk management]], and [[ref: compliance]] (GRC) are three related facets that aim to assure an [[ref: organization]] reliably achieves [[ref: objectives]], addresses uncertainty and acts with integrity. [[ref: Governance]] is the combination of processes established and executed by the directors (or the board of directors) that are reflected in the [[ref: organization]]'s structure and how it is managed and led toward achieving goals. [[ref: Risk management]] is predicting and managing risks that could hinder the [[ref: organization]] from reliably achieving its [[ref: objectives]] under uncertainty. [[ref: Compliance]] refers to adhering with the mandated boundaries (laws and regulations) and voluntary boundaries (company's policies, procedures, etc.)
955
-
956
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Governance,_risk_management,_and_compliance).
957
-
958
- ~ Also known as: [[ref: GRC]].
959
-
960
- [[def: governance diamond, governance diamonds]]
961
- ~ A term that refers to the addition of a [[ref: governing body]] to the standard [[ref: trust triangle]] of [[ref: issuers]], [[ref: holders]], and [[ref: verifiers]] of [[ref: credentials]]. The resulting combination of four [[ref: parties]] represents the basic structure of a [[ref: digital trust ecosystem]].
962
-
963
- [[def: governance document, governance documents]]
964
- ~ A document with at least one [[ref: identifier]] that specifies [[ref: governance requirements]] for a [[ref: trust community]].
965
-
966
- ~ Note: A governance document is a component of a [[ref: governance framework]].
967
-
968
- [[def: governance framework, governance frameworks]]
969
- ~ A collection of one or more [[ref: governance documents]] published by the [[ref: governing body]] of a [[ref: trust community]].
970
-
971
- ~ Also known as: [[ref: trust framework]].
972
-
973
- ~ Note: In the [[ref: digital identity]] industry specifically, a governance framework is better known as a [[ref: trust framework]]. ToIP-conformant governance frameworks conform to the [[ref: ToIP Governance Architecture Specification]] and follow the [[ref: ToIP Governance Metamodel]].
974
-
975
- [[def: governance graph, governance graphs]]
976
- ~ A graph of the [[ref: governance]] relationships between [[ref: entities]] with a [[ref: trust community]]. A governance graph shows which [[ref: nodes]] are the [[ref: governing bodies]] and which are the [[ref: governed parties]]. In some cases, a governance graph can be traversed by making queries to one or more [[ref: trust registries]].Note: a [[ref: party]] can play both [[ref: roles]] and also be a participant in multiple [[ref: governance frameworks]].
977
-
978
- ~ See also: [[ref: authorization graph]], [[ref: reputation graph]], [[ref: trust graph]].
979
-
980
- [[def: governance requirement, governance requirements]]
981
- ~ A [[ref: requirement]] such as a [[ref: policy]], [[ref: rule]], or [[ref: technical specification]] specified in a [[ref: governance document]].
982
-
983
- ~ See also: [[ref: technical requirement]].
984
-
985
- [[def: governed use case, governed use cases]]
986
- ~ A use case specified in a [[ref: governance document]] that results in specific [[ref: governance requirements]] within that [[ref: governance framework]]. Governed use cases may optionally be discovered via a [[ref: trust registry]] authorized by the relevant [[ref: governance framework]].
987
-
988
- [[def: governed party, governed parties]]
989
- ~ A [[ref: party]] whose [[ref: role]](s) in a [[ref: trust community]] is governed by the [[ref: governance requirements]] in a [[ref: governance framework]].
990
-
991
- [[def: governed information]]
992
- ~ Any information published under the authority of a [[ref: governing body]] for the purpose of governing a [[ref: trust community]]. This includes its [[ref: governance framework]] and any information available via an authorized [[ref: trust registry]].
993
-
994
- [[def: governing authority, governing authorities]]
995
- ~ See: [[ref: governing body]].
996
-
997
- [[def: governing body, governing bodies]]
998
- ~ The [[ref: party]] (or set of [[ref: parties]]) authoritative for governing a [[ref: trust community]], usually (but not always) by developing, publishing, maintaining, and enforcing a [[ref: governance framework]]. A governing body may be a government, a formal legal entity of any kind, an informal group of any kind, or an individual. A governing body may also [[ref: delegate]] operational responsibilities to an [[ref: administering body]].
999
-
1000
- ~ Also known as: [[ref: governing authority]].
1001
-
1002
- [[def: GRC]]
1003
- ~ See: [[ref: Governance - Risk Management - Compliance]].
1004
-
1005
- [[def: guardian, guardians]]
1006
- ~ A [[ref: party]] that has been assigned rights and duties in a [[ref: guardianship arrangement]] for the purpose of caring for, protecting, guarding, and defending the [[ref: entity]] that is the [[ref: dependent]] in that [[ref: guardianship arrangement]]. In the context of decentralized digital trust infrastructure, a guardian is issued [[ref: guardianship credentials]] into their own [[ref: digital wallet]] in order to perform such [[ref: actions]] on behalf of the [[ref: dependent]] as are required by this [[ref: role]].
1007
-
1008
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#guardian)
1009
-
1010
- ~ See also: [[ref: custodian]], [[ref: zero-knowledge service provider]].
1011
-
1012
- ~ Mental Model: [eSSIF-Lab Guardianship](https://essif-lab.github.io/framework/docs/terms/pattern-guardianship)
1013
-
1014
- ~ Supporting definitions:
1015
-
1016
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Legal_guardian): A legal guardian is a person who has been appointed by a court or otherwise has the legal authority (and the corresponding [duty](https://en.wikipedia.org/wiki/Duty)) to make decisions relevant to the personal and [property](https://en.wikipedia.org/wiki/Property) interests of another person who is deemed incompetent, called a [ward](https://en.wikipedia.org/wiki/Ward_\(law\)).
1017
-
1018
- ~ For more information, see: [On Guardianship in Self-Sovereign Identity V2.0](https://sovrin.org/wp-content/uploads/Guardianship-Whitepaper-V2.0.pdf) (April, 2023).
1019
-
1020
- ~ Note: A guardian is a very different role than a [[ref: custodian]], who does not take any [[ref: actions]] on behalf of a [[ref: principal]] unless explicitly [[ref: authorized]].
1021
-
1022
- [[def: guardianship arrangement, guardianship arrangements, guardianship, guardianships]]
1023
- ~ A guardianship arrangement (in a [[ref: jurisdiction]]) is the specification of a set of rights and duties between [[ref: legal entities]] of the [[ref: jurisdiction] that enforces these rights and duties, for the purpose of caring for, protecting, guarding, and defending one or more of these [[erf: entities]]. At a minimum, the entities participating in a guardianship arrangement are the [[ref: guardian]] and the [[ref: dependent]].
1024
-
1025
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#guardian)
1026
-
1027
- ~ See also: [[ref: custodianship arrangement]].
1028
-
1029
- ~ Mental Model: [eSSIF-Lab Guardianship](https://essif-lab.github.io/framework/docs/terms/pattern-guardianship)
1030
-
1031
- ~ For more information, see: [On Guardianship in Self-Sovereign Identity V2.0](https://sovrin.org/wp-content/uploads/Guardianship-Whitepaper-V2.0.pdf) (April, 2023).
1032
-
1033
- [[def: guardianship credential, guardianship credentials]]
1034
- ~ A [[ref: digital credential]] [[ref: issued]] by a [[ref: governing body]] to a [[ref: guardian]] to empower the [[ref: guardian]] to undertake the rights and duties of a [[ref: guardianship arrangement]] on behalf of a [[ref: dependent]].
1035
-
1036
- [[def: hardware security module, hardware security modules, HSM, HSMs]]
1037
- ~ A physical computing device that provides tamper-evident and intrusion-resistant safeguarding and management of digital [[ref: keys]] and other secrets, as well as crypto-processing.
1038
-
1039
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/hardware_security_module_hsm).
1040
-
1041
- ~ Also known as: [[ref: HSM]].
1042
-
1043
- ~ Supporting definitions:
1044
-
1045
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/hardware_security_module_hsm): A physical computing device that provides tamper-evident and intrusion-resistant safeguarding and management of digital keys and other secrets, as well as crypto-processing. FIPS 140-2 specifies requirements for HSMs.
1046
-
1047
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Hardware_security_module): A physical computing device that safeguards and manages secrets (most importantly [digital keys](https://en.wikipedia.org/wiki/Digital_keys)), performs [encryption](https://en.wikipedia.org/wiki/Encryption) and decryption functions for [digital signatures](https://en.wikipedia.org/wiki/Digital_signature), [strong authentication](https://en.wikipedia.org/wiki/Strong_authentication) and other cryptographic functions. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a [computer](https://en.wikipedia.org/wiki/Computer) or [network server](https://en.wikipedia.org/wiki/Server_\(computing\)). A hardware security module contains one or more [secure cryptoprocessor](https://en.wikipedia.org/wiki/Secure_cryptoprocessor) [chips](https://en.wikipedia.org/wiki/Integrated_circuit).
1048
-
1049
- [[def: hash, hashes, hash value, hash output, hash result]]
1050
- ~ The result of applying a [[ref: hash function]] to a [[ref: message]].
1051
-
1052
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/hash_value).
1053
-
1054
- ~ Also known as: hash output, hash result, hash value.
1055
-
1056
- [[def: hash function, hash functions]]
1057
- ~ An algorithm that computes a numerical value (called the [[ref: hash value]]) on a [[ref: data]] file or electronic [[ref: message]] that is used to represent that file or message, and depends on the entire contents of the file or message. A hash function can be considered to be a fingerprint of the file or message. Approved hash functions satisfy the following properties: _one-way_ (it is computationally infeasible to find any input that maps to any pre-specified output); and _collision resistant_ (it is computationally infeasible to find any two distinct inputs that map to the same output).
1058
-
1059
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/hash_function).
1060
-
1061
- [[def: holder, holders]]
1062
- ~ A [[ref: role]] an [[ref: agent]] performs by serving as the [[ref: controller]] of the [[ref: cryptographic keys]] and [[ref: digital credentials]] in a [[ref: digital wallet]]. The holder makes [[ref: issuance requests]] for [[ref: credentials]] and responds to [[ref: presentation requests]] for [[ref: credentials]]. A holder is usually, but not always, a [[ref: subject]] of the [[ref: credentials]] they are holding.
1063
-
1064
- ~ See also: [[ref: issuer]], [[ref: verifier]].
1065
-
1066
- ~ Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.w3.org/TR/vc-data-model/#roles)
1067
-
1068
- ~ Supporting definitions:
1069
-
1070
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/terms/holder): a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to handle [presentation requests](https://essif-lab.github.io/framework/docs/terms/presentation-request) from a [peer agent](https://essif-lab.github.io/framework/docs/terms/peer-agent), produce the requested data (a presentation) according to its [principal](https://essif-lab.github.io/framework/docs/terms/principal)'s [holder-policy](https://essif-lab.github.io/framework/docs/terms/holder-policy), and send that in response to the request.
1071
-
1072
- ~ [W3C VC](https://www.w3.org/TR/vc-data-model/#dfn-holders): A role an [entity](https://www.w3.org/TR/vc-data-model/#dfn-entities) might perform by possessing one or more [verifiable credentials](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials) and generating [presentations](https://www.w3.org/TR/vc-data-model/#dfn-presentations) from them. A holder is usually, but not always, a [subject](https://www.w3.org/TR/vc-data-model/#dfn-subjects) of the [verifiable credentials](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials) they are holding. Holders store their [credentials](https://www.w3.org/TR/vc-data-model/#dfn-credential) in [credential repositories](https://www.w3.org/TR/vc-data-model/#dfn-credential-repository).
1073
-
1074
- [[def: holder binding, holder bindings]]
1075
- ~ The process of creating and verifying a relationship between the [[ref: holder]] of a [[ref: digital wallet]] and the wallet itself. Holder binding is related to but NOT the same as subject binding.
1076
-
1077
- [[def: host, hosts]]
1078
- ~ A host is any hardware device that has the capability of permitting access to a network via a user interface, specialized software, [[ref: network address]], [[ref: protocol stack]], or any other means. Some examples include, but are not limited to, computers, personal electronic devices, thin clients, and multi-functional devices.
1079
-
1080
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/host).
1081
-
1082
- ~ Supporting definitions:
1083
-
1084
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Host_\(network\)): A network host is a [computer](https://en.wikipedia.org/wiki/Computer) or other device connected to a [computer network](https://en.wikipedia.org/wiki/Computer_network). A host may work as a [server](https://en.wikipedia.org/wiki/Server_\(computing\)) offering information resources, services, and applications to users or other hosts on the network. Hosts are assigned at least one [network address](https://en.wikipedia.org/wiki/Network_address). A computer participating in networks that use the [Internet protocol suite](https://en.wikipedia.org/wiki/Internet_protocol_suite) may also be called an IP host. Specifically, computers participating in the [Internet](https://en.wikipedia.org/wiki/Internet) are called Internet hosts. Internet hosts and other IP hosts have one or more [IP addresses](https://en.wikipedia.org/wiki/IP_address) assigned to their network interfaces.
1085
-
1086
- [[def: hourglass model, hourglass models]]
1087
- ~ An architectural model for layered systems—and specifically for the [[ref: protocol layers]] in a [[ref: protocol stack]]—in which a diversity of supporting protocols and services at the lower layers are able to support a great diversity of protocols and applications at the higher layers through the use of a single protocol in the [[ref: spanning layer]] in the middle—the “neck” of the hourglass.
1088
-
1089
- ~ See also: [[ref: trust spanning protocol]].
1090
-
1091
- ~ For more information, see: <https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf> and <https://cacm.acm.org/magazines/2019/7/237714-on-the-hourglass-model/abstract>
1092
-
1093
- ~ Note: The Internet’s [[ref: TCP/IP stack]] follows the hourglass model, and it is the design model for the [[ref: ToIP stack]].
1094
-
1095
- [[def: HSM]]
1096
- ~ See: [[ref: hardware security module]].
1097
-
1098
- [[def: human auditable, human auditability]]
1099
- ~ A process or procedure whose [[ref: compliance]] with the [[ref: policies]] in a [[ref: trust framework]] or [[ref: governance framework]] can only be [[ref: verified]] by a human performing an [[ref: audit]]. Human auditability is a primary goal of the [[ref: ToIP Governance Stack]].
1100
-
1101
- ~ Contrast with: [[ref: cryptographically verifiable]].
1102
-
1103
- [[def: human experience]]
1104
- ~ The processes, patterns and rituals of acquiring [[ref: knowledge]] or skill from doing, seeing, or feeling things as a [[ref: natural person]]. In the context of decentralized digital trust infrastructure, the direct experience of a [[ref: natural person]] using [[ref: trust applications]] to make [[ref: trust decisions]] within one or more [[ref: digital trust ecosystems]].
1105
-
1106
- ~ Note: Human experience includes social experiences (e.g., rituals, behaviors, ceremonies and rites of passage), as well as customer experience, worker or employee experience, and user experience.
1107
-
1108
- [[def: human-readable, human-readability]]
1109
- ~ Information that can be processed by a human but that is not intended to be [[ref: machine-readable]].
1110
-
1111
- [[def: human trust]]
1112
- ~ A [[ref: level of assurance]] in a [[ref: trust relationship]] or a [[ref: trust decision]] that can be achieved only via human evaluation of applicable [[ref: trust factors]].
1113
-
1114
- ~ Contrast with: [[ref: technical trust]].
1115
-
1116
- [[def: IAL]]
1117
- ~ See: [[ref: identity assurance level]].
1118
-
1119
- [[def: identification, identify, identified, identifies, identifying]]
1120
- ~ The [[ref: action]] of a [[ref: party]] obtaining the set of [[ref: identity data]] necessary to serve as that [[ref: party]]’s [[ref: identity]] for a specific [[ref: entity]].
1121
-
1122
- ~ Note: The act of identification of a specific [[ref: entity]] is relational to each [[ref: party]] that needs to perform that action. Therefore each party may end up with their own set of [[ref: identity data]] that meets their specific [[ref: requirements]] for their specific [[ref: scope]].
1123
-
1124
- [[def: identifier, identifiers]]
1125
- ~ A single [[ref: attribute]]—typically a character string—that uniquely identifies an [[ref: entity]] within a specific context (which may be a global context). Examples include the name of a [[ref: party]], the URL of an [[ref: organization]], or a serial number for a [[ref: man-made thing]].
1126
-
1127
- ~ Supporting definitions:
1128
-
1129
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#identifier): a character string that is being used for the identification of some [entity](https://essif-lab.github.io/framework/docs/terms/entity) (yet may refer to 0, 1, or more [entities](https://essif-lab.github.io/framework/docs/terms/entity), depending on the context within which it is being used).
1130
-
1131
- [[def: identity, identities]]
1132
- ~ A collection of [[ref: attributes]] or other [[ref: identity data]] that describe an [[ref: entity]] and enable it to be distinguished from all other [[ref: entities]] within a specific [[ref: scope]] of [[ref: identification]]. Identity attributes may include one or more [[ref: identifiers]] for an [[ref: entity]], however it is possible to establish an identity without using [[ref: identifiers]].
1133
-
1134
- ~ Supporting definitions:
1135
-
1136
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#identity): the combined [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge) about that [entity](https://essif-lab.github.io/framework/docs/terms/entity) of all [parties](https://essif-lab.github.io/framework/docs/terms/party), i.e. the union of all [partial identities](https://essif-lab.github.io/framework/docs/terms/partial-identity) of which that [entity](https://essif-lab.github.io/framework/docs/terms/entity) is the [subject](https://essif-lab.github.io/framework/docs/terms/subject).
1137
-
1138
- ~ Note: Identity is relational to the [[ref: party]] performing the identification. For example, if 100 different [[ref: parties]] have an identity for the same [[ref: entity]], each of them may hold a different set of [[ref: identity data]] enabling identification of that [[ref: entity]].
1139
-
1140
- [[def: identity assurance level, identity assurance levels, IAL, IALs]]
1141
- ~ A category that conveys the degree of confidence that a person’s claimed [[ref: identity]] is their real [[ref: identity]], for example as defined in [NIST SP 800-63-3](https://pages.nist.gov/800-63-3/sp800-63-3.html) in terms of three levels: IAL 1 (Some confidence), IAL 2 (High confidence), IAL 3 (Very high confidence).
1142
-
1143
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/identity_assurance_level).
1144
-
1145
- ~ See also: [[ref: authenticator assurance level]], [[ref: federation assurance level]].
1146
-
1147
- [[def: identity binding, identity bindings]]
1148
- ~ The process of associating a set of [[ref: identity data]], such as a [[ref: credential]], with its [[ref: subject]], such as a [[ref: natural person]]. The strength of an identity binding is one factor in determining an [[ref: authenticator assurance level]].
1149
-
1150
- ~ See also: [[ref: identity assurance level]], [[ref: identity proofing]].
1151
-
1152
- [[def: identity controller]]
1153
- ~ The [[ref: controller]] (e.g., a [[ref: natural person]] or [[ref: organization]]) of an [[ref: identity]], especially a [[ref: digital identity]].
1154
-
1155
- [[def: identity data]]
1156
- ~ The set of [[ref: data]] held by a [[ref: party]] in order to provide an [[ref: identity]] for a specific [[ref: entity]].
1157
-
1158
- [[def: identity document, identity documents]]
1159
- ~ A physical or digital document containing [[ref: identity data]]. A [[ref: credential]] is a specialized form of identity document. Birth certificates, bank statements, and utility bills can all be considered identity documents.
1160
-
1161
- [[def: identity proofing, identity proof, identity proofs]]
1162
- ~ The process of a [[ref: party]] gathering sufficient [[ref: identity data]] to establish an [[ref: identity]] for a particular [[ref: subject]] at a particular [[ref: identity assurance level]].
1163
-
1164
- ~ See also: [[ref: identity binding]].
1165
-
1166
- ~ Supporting definitions:
1167
-
1168
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/identity_proofing): The process of providing sufficient information (e.g., identity history, credentials, documents) to establish an identity.
1169
-
1170
- [[def: identity provider, identity providers, IdP, IdPs]]
1171
- ~ An identity provider (abbreviated IdP or IDP) is a system [[ref: entity]] that creates, maintains, and manages [[ref: identity]] information for [[ref: principals]] and also provides [[ref: authentication]] services to relying applications within a [[ref: federation]] or distributed network.
1172
-
1173
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Identity_provider).
1174
-
1175
- ~ Note: The term “identity provider” is used in [[ref: federated identity]] systems because it is a required component of their architecture. By contrast, [[ref: decentralized identity]] and [[ref: self-sovereign identity]] systems do not use the term because they are architected to enable [[ref: entities]] to create and control their own [[ref: digital identities]] without the need to depend on an external provider.
1176
-
1177
- [[def: IDP]]
1178
- ~ See: [[ref: identity provider]].
1179
-
1180
- [[def: impersonation, impersonate, impersonates, impersonated]]
1181
- ~ In the context of cybersecurity, impersonation is when an attacker pretends to be another person in order to commit fraud or some other digital crime.
1182
-
1183
- ~ Supporting definitions:
1184
-
1185
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Impersonator): An impersonator is someone who imitates or copies the behavior or actions of another. As part of a [criminal act](https://en.wikipedia.org/wiki/Crime) such as [identity theft](https://en.wikipedia.org/wiki/Identity_theft), the criminal is trying to assume the identity of another, in order to commit [fraud](https://en.wikipedia.org/wiki/Fraud), such as accessing confidential information, or to gain property not belonging to them. Also known as [social engineering](https://en.wikipedia.org/wiki/Social_engineering_\(security\)) and [impostors](https://en.wikipedia.org/wiki/Impostor).
1186
-
1187
- [[def: integrity]]
1188
- ~ In IT security, data integrity means maintaining and assuring the accuracy and completeness of [[ref: data]] over its entire lifecycle. This means that [[ref: data]] cannot be modified in an [[ref: unauthorized]] or undetected manner.
1189
-
1190
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Information_security#Integrity).
1191
-
1192
- [[def: intermediary system, intermediary systems, intermediary, intermediaries]]
1193
- ~ An intermediary system [[ref: routes]] [[ref: messages]] between [[ref: endpoint systems]] but is not otherwise involved in the processing of those [[ref: messages]]. In the context of [[ref: end-to-end encryption]], intermediary systems cannot [[ref: decrypt]] the [[ref: messages]] sent between the [[ref: endpoint systems]]. In the [[ref: ToIP stack]], intermediary systems operate at [[ref: ToIP Layer 2]], the [[ref: trust spanning layer]]. An intermediary system is one of three types of systems defined in the [[ref: ToIP Technology Architecture Specification]]; the other two are [[ref: endpoint systems]] and [[ref: supporting systems]].
1194
-
1195
- ~ See also: [[ref: endpoint system]], [[ref: supporting system]].
1196
-
1197
- [[def: Internet Protocol]]
1198
- ~ The Internet Protocol (IP) is the network layer [[ref: communications]] protocol in the Internet protocol suite (also known as the [[ref: TCP/IP]] suite) for relaying [[ref: datagrams]] across network boundaries. Its [[ref: routing]] function enables internetworking, and essentially establishes the Internet. IP has the task of delivering [[ref: packets]] from the source host to the destination host solely based on the [[ref: IP addresses]] in the packet headers. For this purpose, IP defines [[ref: packet]] structures that encapsulate the data to be delivered. It also defines addressing methods that are used to label the datagram with source and destination information.
1199
-
1200
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Internet_Protocol).
1201
-
1202
- ~ Also known as: [[ref: IP]].
1203
-
1204
- ~ See also: [[ref: Transmission Control Protocol]], [[ref: User Datagram Protocol]].
1205
-
1206
- [[def: Internet protocol suite]]
1207
- ~ The Internet protocol suite, commonly known as [[ref: TCP/IP]], is a framework for organizing the set of [[ref: communication]] protocols used in the Internet and similar computer networks according to functional criteria. The foundational protocols in the suite are the [[ref: Transmission Control Protocol]] (TCP), the [[ref: User Datagram Protocol]] (UDP), and the [[ref: Internet Protocol]] (IP).
1208
-
1209
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Internet_protocol_suite)
1210
-
1211
- ~ Also known as: [[ref: TCP/IP]].
1212
-
1213
- ~ See also: [[ref: protocol stack]].
1214
-
1215
- [[def: IP]]
1216
- ~ See: [[ref: Internet Protocol]].
1217
-
1218
- [[def: IP address, IP addresses]]
1219
- ~ An [[ref: Internet Protocol]] address (IP address) is a numerical label such as 192.0.2.1 that is connected to a computer network that uses the [[ref: Internet Protocol]] for [[ref: communication]]. An IP address serves two main functions: network interface [[ref: identification]], and location [[ref: addressing]].
1220
-
1221
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/IP_address).
1222
-
1223
- [[def: issuance, issue, issues, issued, issuing]]
1224
- ~ The [[ref: action]] of an [[ref: issuer]] producing and transmitting a [[ref: digital credential]] to a [[ref: holder]]. A [[ref: holder]] may request issuance by submitting an [[ref: issuance request]].
1225
-
1226
- ~ See also: [[ref: presentation]], [[ref: revocation]].
1227
-
1228
- [[def: issuance request, issuance requests]]
1229
- ~ A protocol request invoked by the [[ref: holder]] of a [[ref: digital wallet]] to obtain a [[ref: digital credential]] from an [[ref: issuer]].
1230
-
1231
- ~ See also: [[ref: presentation request]].
1232
-
1233
- [[def: issuer, issuers]]
1234
- ~ A [[ref: role]] an [[ref: agent]] performs to package and [[ref: digitally sign]] a set of [[ref: claims]], typically in the form of a [[ref: digital credential]], and transmit them to a [[ref: holder]].
1235
-
1236
- ~ See also: [[ref: verifier]], [[ref: holder]].
1237
-
1238
- ~ Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.w3.org/TR/vc-data-model/#roles)
1239
-
1240
- ~ Supporting definitions:
1241
-
1242
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#issuer): a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to construct [credentials](https://essif-lab.github.io/framework/docs/terms/credential) from data objects, according to the content of its [principal](https://essif-lab.github.io/framework/docs/terms/principal)'s [issuer](https://essif-lab.github.io/framework/docs/terms/issuer)-Policy (specifically regarding the way in which the [credential](https://essif-lab.github.io/framework/docs/terms/credential) is to be digitally signed), and pass it to the [wallet](https://essif-lab.github.io/framework/docs/terms/wallet)-component of its [principal](https://essif-lab.github.io/framework/docs/terms/principal) allowing it to be issued.
1243
-
1244
- ~ [W3C VC](https://www.w3.org/TR/vc-data-model/#terminology): A role an [entity](https://www.w3.org/TR/vc-data-model/#dfn-entities) can perform by asserting [claims](https://www.w3.org/TR/vc-data-model/#dfn-claims) about one or more [subjects](https://www.w3.org/TR/vc-data-model/#dfn-subjects), creating a [verifiable credential](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials) from these [claims](https://www.w3.org/TR/vc-data-model/#dfn-claims), and transmitting the [verifiable credential](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials) to a [holder](https://www.w3.org/TR/vc-data-model/#dfn-holders).
1245
-
1246
- [[def: jurisdiction, jurisdictions]]
1247
- ~ The composition of: a) a [[ref: legal system]] (legislation, enforcement thereof, and conflict resolution), b) a [[ref: party]] that governs that [[ref: legal system]], c) a scope within which that [[ref: legal system]] is operational, and d) one or more [[ref: objectives]] for the purpose of which the [[ref: legal system]] is operated.
1248
-
1249
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#jurisdiction)
1250
-
1251
- ~ Mental model: [eSSIF-Lab Jurisdictions](https://essif-lab.github.io/framework/docs/terms/pattern-jurisdiction)
1252
-
1253
- [[def: KATE]]
1254
- ~ See: [[ref: keys-at-the-edge]].
1255
-
1256
- [[def: KERI]]
1257
- ~ See: [[ref: Key Event Receipt Infrastructure]].
1258
-
1259
- [[def: key, keys, key pair, key pairs]]
1260
- ~ See: [[ref: cryptographic key]].
1261
-
1262
- [[def: key establishment]]
1263
- ~ A process that results in the sharing of a [[ref: key]] between two or more [[ref: entities]], either by transporting a [[ref: key]] from one entity to another (key transport) or generating a [[ref: key]] from information shared by the [[ref: entities]] (key agreement).
1264
-
1265
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/key_establishment).
1266
-
1267
- [[def: key event, key events]]
1268
- ~ An event in the history of the usage of a [[ref: cryptographic key pair]]. There are multiple types of key events. The inception event is when the key pair is first generated. A rotation event is when the key pair is changed to a new key pair. In some [[ref: key management systems]] (such as [[ref: KERI]]), key events are tracked in a [[ref: key event log]].
1269
-
1270
- [[def: key event log, key event logs]]
1271
- ~ An ordered sequence of [[ref: records]] of [[ref: key events]].
1272
-
1273
- ~ Note: Key event logs are a fundamental data structure in [[ref: KERI]].
1274
-
1275
- [[def: Key Event Receipt Infrastructure]]
1276
- ~ A decentralized permissionless [[ref: key management]] architecture.
1277
-
1278
- ~ Also known as: [[ref: KERI]].
1279
-
1280
- ~ For more information, see: <https://keri.one/>, [ToIP ACDC Task Force](https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force)
1281
-
1282
- [[def: key management system, key management systems, key management, KMS, KMSs]]
1283
- ~ A system for the management of [[ref: cryptographic keys]] and their [[ref: metadata]] (e.g., generation, distribution, storage, backup, archive, recovery, use, [[ref: revocation]], and destruction). An automated key management system may be used to oversee, automate, and secure the key management process. A key management is often protected by implementing it within the [[ref: trusted execution environment]] (TEE) of a device. An example is the [[ref: Secure Enclave]] on Apple iOS devices.
1284
-
1285
- ~ Also known as: [[ref: KMS]].
1286
-
1287
- ~ Source: [NIST-CRSC](https://csrc.nist.gov/glossary/term/key_management_system).
1288
-
1289
- [[def: keys-at-the-edge]]
1290
- ~ A [[ref: key management]] architecture in which [[ref: keys]] are stored on a user’s local edge devices, such as a smartphone, tablet, or laptop, and then used in conjunction with a secure protocol to unlock a [[ref: key management system]] (KMS) and/or a [[ref: digital vault]] in the cloud. This approach can enable the storage and sharing of large [[ref: data]] structures that are not feasible on edge devices. This architecture can also be used in conjunction with [[ref: confidential computing]] to enable cloud-based [[ref: digital agents]] to safely carry out “user not present” operations.
1291
-
1292
- ~ Also known as: [[ref: KATE]].
1293
-
1294
- [[def: KMS]]
1295
- ~ See: [[ref: key management system]].
1296
-
1297
- [[def: knowledge]]
1298
- ~ The (intangible) sum of what is known by a specific [[ref: party]], as well as the familiarity, awareness or understanding of someone or something by that [[ref: party]].
1299
-
1300
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#knowledge).
1301
-
1302
- [[def: Laws of Identity]]
1303
- ~ A set of seven “laws” written by Kim Cameron, former Chief Identity Architect of Microsoft (1941-2021), to describe the dynamics that cause digital identity systems to succeed or fail in various contexts. His goal was to define the requirements for a unifying identity metasystem that can offer the Internet the identity layer it needs.
1304
-
1305
- ~ For more information, see: <https://www.identityblog.com/?p=352>.
1306
-
1307
- [[def: Layer 1]]
1308
- ~ See: [[ref: ToIP Layer 1]].
1309
-
1310
- [[def: Layer 2]]
1311
- ~ See: [[ref: ToIP Layer 2]].
1312
-
1313
- [[def: Layer 3]]
1314
- ~ See: [[ref: ToIP Layer 3]].
1315
-
1316
- [[def: Layer 4]]
1317
- ~ See: [[ref: ToIP Layer 4]].
1318
-
1319
- [[def: legal entity, legal entities]]
1320
- ~ An [[ref: entity]] that is not a [[ref: natural person]] but is recognized as having legal rights and responsibilities. Examples include corporations, partnerships, sole proprietorships, non-profit [[ref: organizations]], associations, and governments. (In some cases even natural systems such as rivers are treated as legal entities.)
1321
-
1322
- ~ See also: [[ref: Legal Entity Identifier]], [[ref: legal person]], [[ref: organization]].
1323
-
1324
- [[def: Legal Entity Identifier, Legal Entity Identifiers, LEI, LEIs]]
1325
- ~ The Legal Entity Identifier (LEI) is a unique global [[ref: identifier]] for [[ref: legal entities]] participating in financial transactions. Also known as an LEI code or LEI number, its purpose is to help identify [[ref: legal entities]] on a globally accessible database. Legal entities are [[ref: organisations]] such as companies or government entities that participate in financial transactions.
1326
-
1327
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Legal_Entity_Identifier).
1328
-
1329
- ~ Note: LEIs are administered by the [Global Legal Entity Identifier Foundation](https://www.gleif.org/) (GLEIF).
1330
-
1331
- [[def: legal identity, legal identities]]
1332
- ~ A set of [[ref: identity data]] considered [[ref: authoritative]] to identify a [[ref: party]] for purposes of legal accountability under one or more [[ref: jurisdictions]].
1333
-
1334
- ~ See also: [[ref: foundational identity]], [[ref: functional identity]].
1335
-
1336
- [[def: legal person, legal persons]]
1337
- ~ In law, a legal person is any person or 'thing' that can do the things a human person is usually able to do in law – such as enter into contracts, sue and be sued, own property, and so on.[<sup>\[3\]\[4\]\[5\]</sup>](https://en.wikipedia.org/wiki/Legal_person#cite_note-3) The reason for the term "legal person" is that some legal persons are not people: companies and corporations are "persons" legally speaking (they can legally do most of the things an ordinary person can do), but they are not people in a literal sense (human beings).
1338
-
1339
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Legal_person).
1340
-
1341
- ~ Contrast with: [[ref: natural person]].
1342
-
1343
- ~ See also: [[ref: legal entity]], [[ref: organization]].
1344
-
1345
- [[def: legal system, legal systems]]
1346
- ~ A system in which [[ref: policies]] and [[ref: rules]] are defined, and mechanisms for their enforcement and conflict resolution are (implicitly or explicitly) specified. Legal systems are not just defined by governments; they can also be defined by a [[ref: governance framework]].
1347
-
1348
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#legal-system)
1349
-
1350
- [[def: LEI]]
1351
- ~ See: [[ref: Legal Entity Identifier]].
1352
-
1353
- [[def: level of assurance, levels of assurance, LOA, LOAs]]
1354
- ~ See: [[ref: assurance level]].
1355
-
1356
- [[def: liveness detection]]
1357
- ~ Any technique used to detect a [[ref: presentation attack]] by determining whether the source of a biometric sample is a live human being or a fake representation. This is typically accomplished using algorithms that analyze biometric sensor data to detect whether the source is live or reproduced.
1358
-
1359
- ~ Also known as: [[ref: proof of presence]].
1360
-
1361
- [[def: locus of control]]
1362
- ~ The set of computing systems under a [[ref: party]]’s direct control, where [[ref: messages]] and [[ref: data]] do not cross [[ref: trust boundaries]].
1363
-
1364
- [[def: machine-readable, machine-readability]]
1365
- ~ Information written in a computer language or [[ref: expression language]] so that it can be read and processed by a computing device.
1366
-
1367
- ~ Contrast with: [[ref: human-readable]].
1368
-
1369
- [[def: man-made thing, man-made things]]
1370
- ~ A[[ref: thing]] generated by human activity of some kind. Man-made things include both active things, such as cars or drones, and passive things, such as chairs or trousers.
1371
-
1372
- ~ Source: [Sovrin Foundation Glossary V3](https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit)
1373
-
1374
- ~ Contrast with: [[ref: natural thing]].
1375
-
1376
- ~ Note: Active things are the equivalent of non-human [[ref: actors ]]in the eSSIF-Lab mental model [Parties, Actors, Actions](https://essif-lab.pages.grnet.gr/framework/docs/terms/pattern-party-actor-action). Also see[Appendix B](https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit#heading=h.mq7pzglc1j96) and[Appendix C](https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit#heading=h.uiq9py7xnmxd) of the Sovrin Glossary.
1377
-
1378
- [[def: mandatory]]
1379
- ~ A [[ref: requirement]] that must be implemented in order for an implementer to be in [[ref: compliance]]. In [[ref: ToIP governance frameworks]], a mandatory [[ref: requirement]] is expressed using a MUST or REQUIRED keyword as defined in IETF RFC 2119.
1380
-
1381
- ~ See also: [[ref: recommended]], [[ref: optional]].
1382
-
1383
- ~ For more information, see: <https://www.rfc-editor.org/rfc/rfc2119>.
1384
-
1385
- [[def: metadata]]
1386
- ~ Information describing the characteristics of [[ref: data]] including, for example, structural metadata describing data structures (e.g., data format, syntax, and semantics) and descriptive metadata describing data contents (e.g., information security labels).
1387
-
1388
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/metadata).
1389
-
1390
- ~ See also: [[ref: communication metadata]].
1391
-
1392
- ~ Supporting definitions:
1393
-
1394
- [Wikipedia](https://en.wikipedia.org/wiki/Metadata): Metadata (or metainformation) is "[data](https://en.wikipedia.org/wiki/Data) that provides information about other data", but not the content of the data itself, such as the text of a message or the image itself.
1395
-
1396
- [[def: message, messages]]
1397
- ~ A discrete unit of [[ref: communication]] intended by the source for consumption by some recipient or group of recipients.
1398
-
1399
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Message).
1400
-
1401
- ~ See also: [[ref: ToIP message]], [[ref: verifiable message]].
1402
-
1403
- [[def: mobile deep link, mobile deep links, mobile deep linking]]
1404
- ~ In the context of mobile apps, [[ref: deep linking]] consists of using a uniform resource identifier (URI) that links to a specific location within a mobile app rather than simply launching the app. Deferred deep linking allows users to deep link to content even if the app is not already installed. Depending on the mobile device platform, the URI required to trigger the app may be different.
1405
-
1406
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Mobile_deep_linking).
1407
-
1408
- [[def: MPC]]
1409
- ~ See: [[ref: multi-party computation]].
1410
-
1411
- [[def: multicast]]
1412
- ~ In computer networking, multicast is group [[ref: communication]] where [[ref: data]] transmission is addressed (using a [[ref: multicast address]]) to a group of destination computers simultaneously. Multicast can be one-to-many or many-to-many distribution. Multicast should not be confused with physical layer point-to-multipoint communication.
1413
-
1414
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Multicast).
1415
-
1416
- ~ See also: [[ref: anycast]], [[ref: broadcast]], [[ref: unicast]].
1417
-
1418
- [[def: multicast address, multicast addresses]]
1419
- ~ A multicast address is a logical [[ref: identifier]] for a group of [[ref: hosts]] in a computer network that are available to process [[ref: datagrams]] or frames intended to be [[ref: multicast]] for a designated network service.
1420
-
1421
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Multicast_address).
1422
-
1423
- ~ See also: [[ref: broadcast address]], [[ref: unicast address]].
1424
-
1425
- [[def: multi-party computation]]
1426
- ~ Secure multi-party computation (also known as secure computation, multi-party computation (MPC) or privacy-preserving computation) is a subfield of cryptography with the goal of creating methods for [[ref: parties]] to jointly compute a function over their inputs while keeping those inputs private. Unlike traditional cryptographic tasks, where cryptography assures security and [[ref: integrity]] of [[ref: communication]] or storage and the adversary is outside the system of participants (an eavesdropper on the sender and receiver), the cryptography in this model protects participants' privacy from each other.
1427
-
1428
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Secure_multi-party_computation).
1429
-
1430
- ~ Also known as: [[ref: MPC]], [[ref: secure multi-party computation]].
1431
-
1432
- [[def: multi-party control]]
1433
- ~ A variant of [[ref: multi-party computation]] where multiple parties must act in concert to meet a control requirement without revealing each other’s data. All parties are privy to the output of the control, but no party learns anything about the others.
1434
-
1435
- [[def: multi-signature, multi-sig]]
1436
- ~ A [[ref: cryptographic signature]] scheme where the process of signing information (e.g., a transaction) is distributed among multiple [[ref: private keys]].
1437
-
1438
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/multi_signature).
1439
-
1440
- [[def: natural person, natural persons]]
1441
- ~ A person (in legal meaning, one who has its own legal personality) that is an individual human being, as distinguished from the broader category of a [[ref: legal person]], which may refer to either a natural person or an [[ref: organization]] of any kind.
1442
-
1443
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Natural_person).
1444
-
1445
- ~ See also: [[ref: legal entity]], [[ref: party]].
1446
-
1447
- ~ Contrast with: [[ref: legal person]]
1448
-
1449
- [[def: natural thing, natural things]]
1450
- ~ A [[ref: thing]] that exists in the natural world independently of humans. Although natural things may form part of a [[ref: man-made thing]], natural things are mutually exclusive with [[ref: man-made things]].
1451
-
1452
- ~ Source: [Sovrin Foundation Glossary V3](https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit).
1453
-
1454
- ~ Contrast with: [[ref: man-made thing]].
1455
-
1456
- ~ For more information see: [Appendix B](https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit#heading=h.mq7pzglc1j96) and[Appendix C](https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit#heading=h.uiq9py7xnmxd) of the Sovrin Glossary
1457
-
1458
- ~ Note: Natural things (those recognized to have legal rights) can be [[ref: parties]] but never [[ref: actors]] in the eSSIF-Lab mental model [Parties, Actors, Actions](https://essif-lab.pages.grnet.gr/framework/docs/terms/pattern-party-actor-action).
1459
-
1460
- [[def: network address, network addresses]]
1461
- ~ A network address is an [[ref: identifier]] for a [[ref: node]] or [[ref: host]] on a telecommunications network. Network addresses are designed to be unique [[ref: identifiers]] across the network, although some networks allow for local, private addresses, or locally administered addresses that may not be unique. Special network addresses are allocated as [[ref: broadcast]] or [[ref: multicast]] addresses. A network address designed to address a single device is called a [[ref: unicast address]].
1462
-
1463
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Network_address).
1464
-
1465
- [[def: NIST-CSRC]]
1466
- ~ Abbreviation for the [NIST Computer Security Resource Center Glossary](https://csrc.nist.gov/glossary/).
1467
-
1468
- [[def: node, nodes]]
1469
- ~ In telecommunications networks, a node (Latin: nodus, ‘knot’) is either a redistribution point or a [[ref: communication endpoint]]. The definition of a node depends on the network and [[ref: protocol layer]] referred to. A physical network node is an electronic device that is attached to a network, and is capable of creating, receiving, or transmitting information over a [[ref: communication channel]].
1470
-
1471
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Node_\(networking\)).
1472
-
1473
- [[def: non-custodial wallet, non-custodial wallets]]
1474
- ~ A [[ref: digital wallet]] that is directly in the control of the [[ref: holder]], usually because the holder is the [[ref: device controller]] of the device hosting the [[ref: digital wallet]] (smartcard, smartphone, tablet, laptop, desktop, car, etc.) A [[ref: digital wallet]] that is in the custody of a [[ref: third party]] is called a [[ref: custodial wallet]].
1475
-
1476
- [[def: objective, objectives]]
1477
- ~ Something toward which a [[ref: party]] (its [[ref: owner]]) directs effort (an aim, goal, or end of [[ref: action]]).
1478
-
1479
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/terms/objective).
1480
-
1481
- [[def: OOBI, OOBIs]]
1482
- ~ See: [[ref: out-of-band introduction]].
1483
-
1484
- [[def: OpenWallet Foundation]]
1485
- ~ A non-profit project of the [Linux Foundation](https://www.linuxfoundation.org/) chartered to build a world-class open source [[ref: wallet engine]].
1486
-
1487
- ~ See also: [[ref: Decentralized Identity Foundation]], [[ref: ToIP Foundation]].
1488
-
1489
- ~ For more information, see: <https://openwallet.foundation/>
1490
-
1491
- [[def: operational circumstances]]
1492
- ~ In the context of privacy protection, this term denotes the context in which privacy trade-off decisions are made. It includes the regulatory environment and other non-technical factors that bear on what reasonable privacy expectations might be.
1493
-
1494
- ~ Source: [PEMC IGR](https://kantarainitiative.org/download/pemc-implementors-guidance-report/)
1495
-
1496
- [[def: optional]]
1497
- ~ A [[ref: requirement]] that is not [[ref: mandatory]] or [[ref: recommended]] to implement in order for an implementer to be in [[ref: compliance]], but which is left to the implementer’s choice. In [[ref: ToIP governance frameworks]], an optional [[ref: requirement]] is expressed using a MAY or OPTIONAL keyword as defined in IETF RFC 2119.
1498
-
1499
- ~ See also: [[ref: mandatory]], [[ref: recommended]].
1500
-
1501
- ~ For more information, see: <https://www.rfc-editor.org/rfc/rfc2119>.
1502
-
1503
- [[def: organization, organizations, organisation, organisations]]
1504
- ~ A [[ref: party]] that consists of a group of [[ref: parties]] who agree to be organized into a specific form in order to better achieve a common set of [[ref: objectives]]. Examples include corporations, partnerships, sole proprietorships, non-profit organizations, associations, and governments.
1505
-
1506
- ~ See also: [[ref: legal entity]], [[ref: legal person]].
1507
-
1508
- ~ Supporting definitions:
1509
-
1510
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#organization): a [party](https://essif-lab.github.io/framework/docs/terms/party) that is capable of setting [objectives](https://essif-lab.github.io/framework/docs/terms/objective) and making sure these are realized by [actors](https://essif-lab.github.io/framework/docs/terms/actor) that it has [onboarded](https://essif-lab.github.io/framework/docs/terms/onboarding) and/or by (vetted) [parties](https://essif-lab.github.io/framework/docs/terms/party) that are committed to contribute to these [objectives](https://essif-lab.github.io/framework/docs/terms/objective).
1511
-
1512
- [[def: organizational authority, organisational authority]]
1513
- ~ A type of [[ref: authority]] where the [party](https://essif-lab.github.io/framework/docs/terms/party) asserting its right is an [[ref: organization]].
1514
-
1515
- [[def: out-of-band introduction, out-of-band introductions, OOBI, OOBIs]]
1516
- ~ A process by which two or more [[ref: entities]] exchange [[ref: VIDs]] in order to form a [[ref: cryptographically verifiable]] [[ref: connection]] (e.g., a [[ref: ToIP connection]]), such as by scanning a [[ref: QR code]] (in person or remotely) or clicking a [[ref: deep link]].
1517
-
1518
- ~ Also known as: [[ref: OOBI]].
1519
-
1520
- [[def: owner, owners]]
1521
- ~ The [[ref: role]] that a [[ref: party]] performs when it is exercising its legal, rightful or natural title to control a specific [[ref: entity]].
1522
-
1523
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#owner).
1524
-
1525
- ~ See also: [[ref: controller]].
1526
-
1527
- [[def: P2P]]
1528
- ~ See: [[ref: peer-to-peer]].
1529
-
1530
- [[def: packet, packets]]
1531
- ~ The logical unit of network [[ref: communications]] produced by the [[ref: transport layer]].
1532
-
1533
- ~ Source: [NIST-CRSC](https://csrc.nist.gov/glossary/term/packet).
1534
-
1535
- [[def: party, parties]]
1536
- ~ An [[ref: entity]] that sets its [[ref: objectives]], maintains its [[ref: knowledge]], and uses that [[ref: knowledge]] to pursue its [[ref: objectives]] in an autonomous (sovereign) manner. [[ref: Natural persons]] and [[ref: organizations]] are the typical examples.
1537
-
1538
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary).
1539
-
1540
- ~ See also: [[ref: first party]], [[ref: second party]], [[ref: third party]]
1541
-
1542
- [[def: password, passwords]]
1543
- ~ A string of characters (letters, numbers and other symbols) that are used to authenticate an identity, verify access authorization or derive cryptographic keys.
1544
-
1545
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/password).
1546
-
1547
- ~ See also: [[ref: complex password]].
1548
-
1549
- [[def: peer, peers]]
1550
- ~ In the context of digital networks, an [[ref: actor]] on the network that has the same status, privileges, and communications options as the other actors on the network.
1551
-
1552
- ~ See also: [[ref: peer-to-peer]].
1553
-
1554
- ~ Supporting definitions:
1555
-
1556
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#peer-actor): the [actor](https://essif-lab.github.io/framework/docs/terms/actor) with whom/which this other [actor](https://essif-lab.github.io/framework/docs/terms/actor) is communicating in that [communication session](https://essif-lab.github.io/framework/docs/terms/communication-session).
1557
-
1558
- [[def: peer-to-peer]]
1559
- ~ Peer-to-peer (P2P) computing or networking is a distributed application architecture that partitions tasks or workloads between [[ref: peers]]. [[ref: Peers]] are equally privileged, equipotent participants in the network. This forms a peer-to-peer network of [[ref: nodes]].
1560
-
1561
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Peer-to-peer).
1562
-
1563
- [[def: permission, permissions]]
1564
- ~ [[ref: Authorization]] to perform some [[ref: action]] on a system.
1565
-
1566
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/permission).
1567
-
1568
- [[def: persistent connection, persistent connections]]
1569
- ~ A [[ref: connection]] that is able to persist across multiple [[ref: communication sessions]]. In a ToIP context, a persistent connection is established when two [[ref: ToIP endpoints]] exchange [[ref: verifiable identifiers]] (VIDs) that they can use to re-establish the [[ref: connection]] with each other whenever it is needed.
1570
-
1571
- ~ Contrast with: [[ref: ephemeral connection]].
1572
-
1573
- [[def: person, persons]]
1574
- ~ See [[ref: natural person]].
1575
-
1576
- [[def: personal data]]
1577
- ~ Any information relating to an identified or identifiable [[ref: natural person]] (called a [[ref: data subject]] under [[ref: GDPR]]).
1578
-
1579
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/personal_data).
1580
-
1581
- [[def: personal data store, personal data stores, PDS, PDSs]]
1582
- ~ See: [[ref: personal data vault]].
1583
-
1584
- ~ Note: In the market, the term “personal data store” has also been used to generally mean a combination of the functions of a personal [[ref: digital agent]], [[ref: personal wallet]], and [[ref: personal data vault]].
1585
-
1586
- [[def: personal data vault, personal data vaults]]
1587
- ~ A [[ref: digital vault]] whose [[ref: controller]] is a [[ref: natural person]].
1588
-
1589
- [[def: personal wallet, personal wallets]]
1590
- ~ A [[ref: digital wallet]] whose [[ref: holder]] is a [[ref: natural person]].
1591
-
1592
- ~ Contrast with: [[ref: enterprise wallet]].
1593
-
1594
- [[def: personally identifiable information, PII]]
1595
- ~ Information (any form of [[ref: data]]) that can be used to directly or indirectly [[ref: identify]] or re-identify an individual person either singly or in combination within a single [[ref: record]] or in correlation with other [[ref: records]]. This information can be one or more [[ref: attributes]]/fields/[[ref: properties]] in a [[ref: record]] (e.g., date-of-birth) or one or more [[ref: records]] (e.g., medical records).
1596
-
1597
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/personally_identifiable_information)
1598
-
1599
- ~ Also known as: [[ref: PII]].
1600
-
1601
- ~ See also: [[ref: personal data]], [[ref: sensitive data]].
1602
-
1603
- [[def: physical credential, physical credentials]]
1604
- ~ A [[ref: credential]] in a physical form such as paper, plastic, or metal.
1605
-
1606
- ~ Contrast with: [[ref: digital credential]].
1607
-
1608
- [[def: PII]]
1609
- ~ See: [[ref: personally identifiable information]].
1610
-
1611
- [[def: PKI]]
1612
- ~ See: [[ref: public key infrastructure]].
1613
-
1614
- [[def: plaintext, plaintexts]]
1615
- ~ Unencrypted information that may be input to an [[ref: encryption]] operation. Once encrypted, it becomes [[ref: ciphertext]].
1616
-
1617
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/plaintext).
1618
-
1619
- [[def: policy, policies]]
1620
- ~ Statements,[[ref: rules]], or assertions that specify the correct or expected behavior of an [[ref: entity]]. For example, an [[ref: authorization]] policy might specify the correct [[ref: access control]] rules for a software component. Policies may be [[ref: human-readable]] or [[ref: machine-readable]] or both.
1621
-
1622
- ~ Example: An authorization policy might specify the correct access control rules for a software component.
1623
-
1624
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/policy)
1625
-
1626
- ~ See also: [[ref: governance framework]], [[ref: governance requirement]], [[ref: rule]].
1627
-
1628
- [[def: PoP]]
1629
- ~ See: [[ref: proof of personhood]].
1630
-
1631
- [[def: presentation, presentations, present, presents, presenting, presented]]
1632
- ~ A [[ref: verifiable]] [[ref: message]] that a [[ref: holder]] may send to a [[ref: verifier]] containing [[ref: proofs]] of one or more [[ref: claims]] derived from one or more [[ref: digital credentials]] from one or more [[ref: issuers]] as a response to a specific [[ref: presentation request]] from a  [[ref: verifier]].
1633
-
1634
- ~ Supporting definitions:
1635
-
1636
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/terms/presentation): A (signed) digital [[ref: message]] that a [[ref: holder]] component may send to a [[ref: verifier]] component that contains [[ref: data]] derived from one or more [[ref: verifiable credentials]] (that (a [colleague](https://essif-lab.github.io/framework/docs/terms/colleague) component of) the [holder](https://essif-lab.github.io/framework/docs/terms/holder) component has received from [issuer](https://essif-lab.github.io/framework/docs/terms/issuer) components of one or more [parties](https://essif-lab.github.io/framework/docs/terms/party)), as a response to a specific [[ref: presentation request]] of a  [[ref: verifier ]]component.
1637
-
1638
- [[def: presentation attack, presentation attacks]]
1639
- ~ A type of cybersecurity attack in which the attacker attempts to defeat a [[ref: biometric]] [[ref: liveness detection]] system by providing false inputs.
1640
-
1641
- ~ Supporting definitions:
1642
-
1643
- [NIST-CSRC](https://csrc.nist.gov/glossary/term/presentation_attack): Presentation to the biometric data capture subsystem with the goal of interfering with the operation of the biometric system.
1644
-
1645
- [[def: presentation request, presentation requests]]
1646
- ~ A protocol request sent by the [[ref: verifier]] to the [[ref: holder]] of a [[ref: digital wallet]] to request a [[ref: presentation]].
1647
-
1648
- ~ See also: [[ref: issuance request]].
1649
-
1650
- [[def: primary document, primary documents]]
1651
- ~ The [[ref: governance document]] at the root of a [[ref: governance framework]]. The primary document specifies the other [[ref: controlled documents]] in the governance framework.
1652
-
1653
- [[def: principal, principals]]
1654
- ~ The [[ref: party]] for whom, or on behalf of whom, an [[ref: actor]] is executing an [[ref: action]] (this [[ref: actor]] is then called an [[ref: agent]] of that [[ref: party]]).
1655
-
1656
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#principal)
1657
-
1658
- [[def: Principles of SSI]]
1659
- ~ A set of principles for [[ref: self-sovereign identity]] systems originally defined by the Sovrin Foundation and republished by the [[ref: ToIP Foundation]].
1660
-
1661
- ~ For more information, see: <https://sovrin.org/principles-of-ssi/> and <https://trustoverip.org/wp-content/uploads/2021/10/ToIP-Principles-of-SSI.pdf>
1662
-
1663
- [[def: privacy policy, privacy policies]]
1664
- ~ A statement or legal document (in privacy law) that discloses some or all of the ways a [[ref: party]] gathers, uses, discloses, and manages a customer or client's [[ref: data]].
1665
-
1666
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Privacy_policy)
1667
-
1668
- ~ See also: [[ref: security policy]].
1669
-
1670
- [[def: private key, private keys]]
1671
- ~ In [[ref: public key cryptography]], the [[ref: cryptographic key]] which must be kept secret by the [[ref: controller]] in order to maintain security.
1672
-
1673
- ~ Supporting definitions:
1674
-
1675
- [NIST-CSRC](https://csrc.nist.gov/glossary/term/private_key): The secret part of an asymmetric key pair that is typically used to digitally sign or decrypt data.
1676
-
1677
- [[def: proof, proofs]]
1678
- ~ A digital object that enables [[ref: cryptographic verification]] of either: a) the [[ref: claims]] from one or more [[ref: digital credentials]], or b) facts about [[ref: claims]] that do not reveal the [[ref: data ]] itself (e.g., proof of the [[ref: subject]] being over/under a specific age without revealing a birthdate).
1679
-
1680
- ~ See also: [[ref: zero-knowledge proof]].
1681
-
1682
- [[def: proof of control]]
1683
- ~ See: [[ref: proof of possession]].
1684
-
1685
- [[def: proof of personhood]]
1686
- ~ Proof of personhood (PoP) is a means of resisting malicious attacks on [[ref: peer-to-peer]] networks, particularly, attacks that utilize multiple fake [[ref: identities]], otherwise known as a [[ref: Sybil attack]]. Decentralized online platforms are particularly vulnerable to such attacks by their very nature, as notionally democratic and responsive to large voting blocks. In PoP, each unique human participant obtains one equal unit of voting power, and any associated rewards.
1687
-
1688
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Proof_of_personhood).
1689
-
1690
- ~ Also known as: [[ref: PoP]].
1691
-
1692
- [[def: proof of possession]]
1693
- ~ A [[ref: verification]] process whereby a [[ref: level of assurance]] is obtained that the owner of a [[ref: key pair]] actually controls the [[ref: private key]] associated with the [[ref: public key]].
1694
-
1695
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/proof_of_possession).
1696
-
1697
- [[def: proof of presence]]
1698
- ~ See: [[ref: liveness detection]].
1699
-
1700
- [[def: property, properties]]
1701
- ~ In the context of digital communication, an [[ref: attribute]] of a digital object or [[ref: data]] structure, such as a [[ref: DID document]] or a [[ref: schema]].
1702
-
1703
- ~ See also: [[ref: attribute]], [[ref: claim]].
1704
-
1705
- [[def: protected data]]
1706
- ~ [[ref: Data]] that is not publicly available but requires some type of [[ref: access control]] to gain access.
1707
-
1708
- [[def: protocol layer, protocol layers]]
1709
- ~ In modern protocol design, protocols are layered to form a [[ref: protocol stack]]. Layering is a design principle that divides the protocol design task into smaller steps, each of which accomplishes a specific part, interacting with the other parts of the protocol only in a small number of well-defined ways. Layering allows the parts of a protocol to be designed and tested without a combinatorial explosion of cases, keeping each design relatively simple.
1710
-
1711
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Communication_protocol#Layering).
1712
-
1713
- ~ See also: [[ref: hourglass model]], [[ref: ToIP stack]].
1714
-
1715
- [[def: protocol stack, protocol stacks]]
1716
- ~ The protocol stack or network stack is an implementation of a computer networking protocol suite or protocol family. Some of these terms are used interchangeably but strictly speaking, the _suite_ is the definition of the communication protocols, and the _stack_ is the software implementation of them.
1717
-
1718
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Protocol_stack)
1719
-
1720
- ~ See also: [[ref: protocol layer]].
1721
-
1722
- [[def: pseudonym, pseudonyms, pseudonymous, pseudonymity]]
1723
- ~ A pseudonym is a fictitious name that a [[ref: person]] assumes for a particular purpose, which differs from their original or true name (orthonym). This also differs from a new name that entirely or legally replaces an individual's own. Many pseudonym [[ref: holders]] use pseudonyms because they wish to remain [[ref: anonymous]], but anonymity is difficult to achieve and often fraught with legal issues.
1724
-
1725
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Pseudonym).
1726
-
1727
- [[def: public key, public keys]]
1728
- ~ In [[ref: public key cryptography]], the [[ref: cryptographic key]] that can be freely shared with anyone by the [[ref: controller]] without compromising security. A [[ref: party]]'s public key must be verified as [[ref: authoritative]] in order to verify their [[ref: digital signature]].
1729
-
1730
- ~ Supporting definitions:
1731
-
1732
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/public_key): The public part of an asymmetric key pair that is typically used to verify signatures or encrypt data.
1733
-
1734
- [[def: public key certificate, public key certificates, PKC, PKCs]]
1735
- ~ A set of [[ref: data]] that uniquely identifies a [[ref: public key]] (which has a corresponding [[ref: private key]]) and an [[ref: owner]] that is authorized to use the [[ref: key pair]]. The certificate contains the owner’s [[ref: public key]] and possibly other information and is [[ref: digitally signed]] by a [[ref: certification authority]] (i.e., a trusted [[ref: party]]), thereby binding the [[ref: public key]] to the [[ref: owner]].
1736
-
1737
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/public_key_certificate).
1738
-
1739
- ~ See also: [[ref: public key infrastructure]].
1740
-
1741
- ~ Supporting definitions:
1742
-
1743
- ~ Wikipedia : In [cryptography](https://en.wikipedia.org/wiki/Cryptography), a public key certificate, also known as a digital certificate or identity certificate, is an [electronic document](https://en.wikipedia.org/wiki/Electronic_document) used to prove the validity of a [public key](https://en.wikipedia.org/wiki/Key_authentication). The certificate includes information about the key, information about the identity of its owner (called the subject), and the [digital signature](https://en.wikipedia.org/wiki/Digital_signature) of an entity that has verified the certificate's contents (called the issuer). If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate's subject. In [email encryption](https://en.wikipedia.org/wiki/Email_encryption), [code signing](https://en.wikipedia.org/wiki/Code_signing), and [e-signature](https://en.wikipedia.org/wiki/Electronic_signature) systems, a certificate's subject is typically a person or organization. However, in [Transport Layer Security](https://en.wikipedia.org/wiki/Transport_Layer_Security) (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices.
1744
-
1745
- [[def: public key cryptography]]
1746
- ~ Public key cryptography, or asymmetric cryptography, is the field of cryptographic systems that use pairs of related [[ref: keys]]. Each key pair consists of a [[ref: public key]] and a corresponding [[ref: private key]]. [[ref: Key pairs]] are generated with cryptographic algorithms based on mathematical problems termed one-way functions. Security of public key cryptography depends on keeping the [[ref: private key]] secret; the [[ref: public key]] can be openly distributed without compromising security.
1747
-
1748
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Public-key_cryptography).
1749
-
1750
- ~ See also: [[ref: public key infrastructure]].
1751
-
1752
- [[def: public key infrastructure, public key infrastructures, PKI, PKIs]]
1753
- ~ A set of policies, processes, server platforms, software and workstations used for the purpose of administering [[ref: certificates]] and public-private [[ref: key pairs]], including the ability to [[ref: issue]], maintain, and [[ref: revoke]] [[ref: public key certificates]]. The PKI includes the hierarchy of [[ref: certificate authorities]] that allow for the deployment of [[ref: digital certificates]] that support [[ref: encryption]], [[ref: digital signature]] and [[ref: authentication]] to meet business and security requirements.
1754
-
1755
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/public_key_infrastructure).
1756
-
1757
- ~ Supporting definitions:
1758
-
1759
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Public_key_infrastructure): A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke [digital certificates](https://en.wikipedia.org/wiki/Public_key_certificate) and manage [public-key encryption](https://en.wikipedia.org/wiki/Public-key_cryptography). The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email.
1760
-
1761
- [[def: QR code, QR codes]]
1762
- ~ A QR code (short for "quick-response code") is a type of two-dimensional matrix barcode—a [[ref: machine-readable]] optical image that contains information specific to the identified item. In practice, QR codes contain data for a locator, an identifier, and web tracking.
1763
-
1764
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/QR_code).
1765
-
1766
- ~ See also: [[ref: out-of-band introduction]].
1767
-
1768
- [[def: RBAC]]
1769
- ~ See: [[ref: role-based access control]].
1770
-
1771
- [[def: real world identity, real world identities]]
1772
- ~ A term used to describe the opposite of [[ref: digital identity]], i.e., an identity (typically for a [[ref: person]]) in the physical instead of the digital world.
1773
-
1774
- ~ Also known as: [[ref: RWI]].
1775
-
1776
- ~ See also: [[ref: legal identity]].
1777
-
1778
- [[def: recommended]]
1779
- ~ A [[ref: requirement]] that is not [[ref: mandatory]] to implement in order for an implementer to be in [[ref: compliance]], but which should be implemented unless the implementer has a good reason. In [[ref: ToIP governance frameworks]], a recommendation is expressed using a SHOULD or RECOMMENDED keyword as defined in [IETF RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).
1780
-
1781
- ~ See also: [[ref: mandatory]], [[ref: optional]].
1782
-
1783
- ~ For more information, see: <https://www.rfc-editor.org/rfc/rfc2119>.
1784
-
1785
- [[def: record, records]]
1786
- ~ A uniquely identifiable entry or listing in a database or [[ref: registry]].
1787
-
1788
- [[def: registrant, registrants]]
1789
- ~ The [[ref: party]] submitting a [[ref: registration]] [[ref: record]] to a [[ref: registry]].
1790
-
1791
- [[def: registrar, registrars]]
1792
- ~ The [[ref: party]] who performs [[ref: registration]] on behalf of a [[ref: registrant]].
1793
-
1794
- [[def: registration, registrations]]
1795
- ~ The process by which a [[ref: registrant]] submits a [[ref: record]] to a [[ref: registry]].
1796
-
1797
- [[def: registration agent]]
1798
- ~ A [[ref: party]] responsible for accepting [[ref: registration]] requests and [[ref: authenticating]] the [[ref: registrant]]. The term may also apply to a [[ref: party]] accepting [[ref: issuance requests]] for [[ref: digital credentials]].
1799
-
1800
- [[def: registry, registries]]
1801
- ~ A specialized database of [[ref: records]] that serves as an [[ref: authoritative source]] of information about [[ref: entities]].
1802
-
1803
- ~ See also: [[ref: trust registry]].
1804
-
1805
- [[def: relationship]]
1806
- ~ See [[ref: ToIP relationship]].
1807
-
1808
- ~ See also: [[ref: trust relationship]].
1809
-
1810
- [[def: relationship context, relationship contexts]]
1811
- ~ A context established within the boundary of a [[ref: trust relationship]].
1812
-
1813
- [[def: relying party, relying parties]]
1814
- ~ A [[ref: party]] who [[ref: accepts]] [[ref: claims]], [[ref: credentials]], [[ref: trust graphs]], or any other form of [[ref: verifiable data]] from other [[ref: parties]] (such as [[ref: issuers]], [[ref: holders]], [[ref: trust registries]], or other [[ref: authoritative sources]]) in order to make a [[ref: trust decision]].
1815
-
1816
- ~ See also: [[ref: verifier]].
1817
-
1818
- ~ Note: The term “relying party” is more commonly used in [[ref: federated identity]] architecture; the term “verifier” is more commonly used with [[ref: decentralized identity]] architecture and [[ref: verifiable credentials]].
1819
-
1820
- [[def: reputation, reputations]]
1821
- ~ The beliefs or opinions that are generally held about an [[ref: entity]], typically developed as a result of social evaluation on a set of criteria, such as behavior, performance, or [[ref: trustworthiness]].
1822
-
1823
- [[def: reputation graph, reputation graphs]]
1824
- ~ A graph of the [[ref: reputation]] relationships between different entities in a [[ref: trust community]]. In a [[ref: digital trust ecosystem]], the [[ref: governing body]] may be one [[ref: trust anchor]] of a reputation graph. In some cases, a reputation graph can be traversed by making queries to one or more [[ref: trust registries]].
1825
-
1826
- ~ See also: [[ref: authorization graph]], [[ref: governance graph]], [[ref: trust graph]].
1827
-
1828
- [[def: reputation system, reputation systems]]
1829
- ~ Reputation systems are programs or algorithms that allow users to rate each other in online communities in order to build [[ref: trust]] through [[ref: reputation]]. Some common uses of these systems can be found on e-commerce websites such as eBay, Amazon.com, and Etsy as well as online advice communities such as Stack Exchange.
1830
-
1831
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Reputation_system).
1832
-
1833
- [[def: requirement, requirements]]
1834
- ~ A specified condition or behavior to which a system needs to [[ref: comply]]. [[ref: Technical requirements]] are defined in [[ref: technical specifications]] and implemented in computer systems to be executed by software [[ref: actors]]. [[ref: Governance requirements]] are defined in [[ref: governance documents]] that specify [[ref: policies]] and procedures to be executed by human [[ref: actors]]. In [[ref: ToIP specifications]], requirements are expressed using the keywords defined in [Internet RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).
1835
-
1836
- ~ See also: [[ref: mandatory]], [[ref: recommended]], [[ref: optional]].
1837
-
1838
- ~ For more information, see: <https://www.rfc-editor.org/rfc/rfc2119>.
1839
-
1840
- [[def: revocation, revocations, revoke, revokes, revoked, revoking]]
1841
- ~ In the context of [[ref: digital credentials]], revocation is an event signifying that the [[ref: issuer]] no longer attests to the [[ref: validity]] of a [[ref: credential]] they have [[ref: issued]]. In the context of cryptographic keys, revocation is an event signifying that the [[ref: controller]] no longer attests to the [[ref: validity]] of a public/private key pair for which the [[ref: controller]] is [[ref: authoritative]].
1842
-
1843
- ~ See also: [[ref: issuance]], [[ref: presentation]].
1844
-
1845
- ~ Supporting definitions:
1846
-
1847
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#revokerevocation): the act, by or on behalf of the [party](https://essif-lab.github.io/framework/docs/terms/party) that has issued the [credential](https://essif-lab.github.io/framework/docs/terms/credential), of no longer vouching for the correctness or any other qualification of (arbitrary parts of) that [credential](https://essif-lab.github.io/framework/docs/terms/credential).
1848
-
1849
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/revocation): **​​For digital certificates**: The process of permanently ending the binding between a certificate and the identity asserted in the certificate from a specified time forward. **For cryptographic keys**: A process whereby a notice is made available to affected entities that keys should be removed from operational use prior to the end of the established cryptoperiod of those keys.
1850
-
1851
- [[def: risk, risks]]
1852
- ~ The effects that uncertainty (i.e. a lack of information, understanding or [[ref: knowledge]] of events, their consequences or likelihoods) can have on the intended realization of an [[ref: objective ]]of a [[ref: party]].
1853
-
1854
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary)
1855
-
1856
- ~ Supporting definitions:
1857
-
1858
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/risk): A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.
1859
-
1860
- [[def: risk assessment, risk assessments]]
1861
- ~ The process of identifying [[ref: risks]] to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other [[ref: organizations]], and the overall [[ref: ecosystem]], resulting from the operation of an information system. Risk assessment is part of [[ref: risk management]], incorporates threat and vulnerability analyses, and considers [[ref: risk mitigations]] provided by security controls planned or in place.
1862
-
1863
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/risk_assessment).
1864
-
1865
- ~ Also known as: risk analysis.
1866
-
1867
- ~ Supporting definitions:
1868
-
1869
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Risk_assessment): Risk assessment determines possible mishaps, their likelihood and consequences, and the [tolerances](https://en.wikipedia.org/wiki/Engineering_tolerance) for such events.[<sup>\[1\]</sup>](https://en.wikipedia.org/wiki/Risk_assessment#cite_note-RausandRisk13-1) The results of this process may be expressed in a [quantitative](https://en.wikipedia.org/wiki/Quantitative_property) or [qualitative](https://en.wikipedia.org/wiki/Qualitative_data) fashion. Risk assessment is an inherent part of a broader [risk management](https://en.wikipedia.org/wiki/Risk_management) strategy to help reduce any potential risk-related consequences. More precisely, risk assessment identifies and analyses potential (future) events that may negatively impact individuals, assets, and/or the environment (i.e. [hazard analysis](https://en.wikipedia.org/wiki/Hazard_analysis)). It also makes judgments "on the [tolerability](https://en.wikipedia.org/wiki/Tolerability) of the risk on the basis of a risk analysis" while considering influencing factors (i.e. risk evaluation).
1870
-
1871
- [[def: risk decision, risk decisions]]
1872
- ~ See: [[ref: trust decision]].
1873
-
1874
- [[def: risk management]]
1875
- ~ The process of managing [[ref: risks]] to organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals resulting from the operation of an information system, and includes: (i) the conduct of a [[ref: risk assessment]]; (ii) the implementation of a [[ref: risk mitigation]] strategy; and (iii) employment of techniques and procedures for the continuous monitoring of the security state of the information system.
1876
-
1877
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/risk_management).
1878
-
1879
- ~ Supporting definitions:
1880
-
1881
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#risk-management): a process that is run by (or on behalf of) a specific [party](https://essif-lab.github.io/framework/docs/terms/party) for the purpose of [managing](https://essif-lab.github.io/framework/docs/terms/management) the [risks](https://essif-lab.github.io/framework/docs/terms/risk) that it [owns](https://essif-lab.github.io/framework/docs/terms/owner) (thereby realizing specific [risk objectives](https://essif-lab.github.io/framework/docs/terms/risk-objective)).
1882
-
1883
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Risk_management): Risk management is the identification, evaluation, and prioritization of [risks](https://en.wikipedia.org/wiki/Risk) (defined in [ISO 31000](https://en.wikipedia.org/wiki/ISO_31000) as the effect of uncertainty on objectives) followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events or to maximize the realization of opportunities.
1884
-
1885
- [[def: risk mitigation, risk mitigations]]
1886
- ~ Prioritizing, evaluating, and implementing the appropriate [[ref: risk]]-reducing controls/countermeasures recommended from the [[ref: risk management]] process.
1887
-
1888
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/risk_mitigation).
1889
-
1890
- [[def: role, roles]]
1891
- ~ A defined set of characteristics that an [[ref: entity]] has in some context, such as responsibilities it may have, [[ref: actions]] (behaviors) it may execute, or pieces of [[ref: knowledge]] that it is expected to have in that context, which are referenced by a specific role name.
1892
-
1893
- ~ Source: [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#role).
1894
-
1895
- ~ See also: [[ref: role credential]].
1896
-
1897
- [[def: role-based access control, role-based access controls]]
1898
- ~ [[ref: Access control]] based on user [[ref: roles]] (i.e., a collection of access [[ref: authorizations]] a user receives based on an explicit or implicit assumption of a given [[ref: role]]). [[ref: Role]] [[ref: permissions]] may be inherited through a [[ref: role]] hierarchy and typically reflect the [[ref: permissions]] needed to perform defined functions within an [[ref: organization]]. A given [[ref: role]] may apply to a single individual or to several individuals.
1899
-
1900
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/role_based_access_control).
1901
-
1902
- ~ Supporting definitions:
1903
-
1904
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Role-based_access_control): In computer systems security, role-based access control (RBAC) or role-based security is an approach to restricting system access to authorized users, and to implementing [mandatory access control](https://en.wikipedia.org/wiki/Mandatory_access_control) (MAC) or [discretionary access control](https://en.wikipedia.org/wiki/Discretionary_access_control) (DAC).
1905
-
1906
- [[def: role credential, role credentials]]
1907
- ~ A [[ref: credential]] [[ref: claiming]] that the [[ref: subject]] has a specific [[ref: role]].
1908
-
1909
- [[def: router, routers]]
1910
- ~ A router is a networking device that forwards [[ref: data packets]] between computer networks. Routers perform the traffic directing functions between networks and on the global Internet. Data sent through a network, such as a web page or email, is in the form of [[ref: data packets]]. A packet is typically forwarded from one router to another router through the networks that constitute an internetwork (e.g. the Internet) until it reaches its destination [[ref: node]]. This process is called [[ref: routing]].
1911
-
1912
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Router_\(computing\)).
1913
-
1914
- [[def: routing, routes, routed]]
1915
- ~ Routing is the process of selecting a path for traffic in a network or between or across multiple networks. Broadly, routing is performed in many types of networks, including circuit-switched networks, such as the public switched telephone network (PSTN), and computer networks, such as the Internet. A [[ref: router]] is a computing device that specializes in performing routing.
1916
-
1917
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Routing).
1918
-
1919
- [[def: rule, rules]]
1920
- ~ A prescribed guide for conduct, process or [[ref: action]] to achieve a defined result or [[ref: objective]]. Rules may be [[ref: human-readable]] or [[ref: machine-readable]] or both.
1921
-
1922
- ~ See also: [[ref: governance framework]], [[ref: policy]].
1923
-
1924
- [[def: RWI]]
1925
- ~ See: [[ref: real world identity]].
1926
-
1927
- [[def: schema, schemas]]
1928
- ~ A framework, pattern, or set of [[ref: rules]] for enforcing a specific structure on a digital object or a set of digital [[ref: data]]. There are many types of schemas, e.g., data schema, credential verification schema, database schema.
1929
-
1930
- ~ For more information, see: W3C [Data Schemas](https://www.w3.org/TR/vc-data-model/#data-schemas).
1931
-
1932
- ~ Note: `credentialSchema`is a Property Definition in the [W3C VC Data Model, see 3.2.1](https://www.w3.org/2018/credentials/#credentialSchema)
1933
-
1934
- [[def: scope, scopes]]
1935
- ~ In the context of [[ref: terminology]], scope refers to the set of possible [[ref: concepts]] within which: a) a specific [[ref: term]] is intended to uniquely identify a [[ref: concept]], or b) a specific [[ref: glossary]] is intended to identify a set of [[ref: concepts]]. In the context of [[ref: identification]], scope refers to the set of possible entities within which a specific entity must be uniquely identified. In the context of [[ref: specifications]], scope refers to the set of problems (the problem space) within which the specification is intended to specify solutions.
1936
-
1937
- ~ Supporting definitions:
1938
-
1939
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#scope): the extent of the area or subject matter (which we use, e.g., to define [pattern](https://essif-lab.github.io/framework/docs/@), [concept](https://essif-lab.github.io/framework/docs/@), [term](https://essif-lab.github.io/framework/docs/@) and [glossaries](https://essif-lab.github.io/framework/docs/@) in, but it serves other purposes as well).
1940
-
1941
- [[def: SCID, SCIDs]]
1942
- ~ See: [[ref: self-certifying identifier]].
1943
-
1944
- [[def: second party, second parties]]
1945
- ~ The [[ref: party]] with whom a [[ref: first party]] engages to form a [[ref: trust relationship]], establish a [[ref: connection]], make a [[ref: delegation]], or execute a [[ref: transaction]].
1946
-
1947
- ~ See also: [[ref: third party]].
1948
-
1949
- [[def: Secure Enclave, Secure Enclaves]]
1950
- ~ A coprocessor on Apple iOS devices that serves as a [[ref: trusted execution environment]].
1951
-
1952
- [[def: secure multi-party computation]]
1953
- ~ See: [[ref: multi-party computation]].
1954
-
1955
- [[def: Secure Sockets Layer, SSL]]
1956
- ~ The original transport layer security protocol developed by Netscape and partners. Now deprecated in favor of [[ref: Transport Layer Security]] (TLS).
1957
-
1958
- ~ Also known as: [[ref: SSL]].
1959
-
1960
- [[def: security domain, security domains]]
1961
- ~ An environment or context that includes a set of system resources and a set of system entities that have the right to access the resources as defined by a common [[ref: security policy]], security model, or security architecture.
1962
-
1963
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/domain)
1964
-
1965
- ~ See also: [[ref: trust domain]].
1966
-
1967
- [[def: security policy, security policies]]
1968
- ~ A set of [[ref: policies]] and [[ref: rules]] that governs all aspects of security-relevant system and system element behavior.
1969
-
1970
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/security_policy)
1971
-
1972
- ~ See also: [[ref: privacy policy]].
1973
-
1974
- [[def: self-asserted]]
1975
- ~ A term used to describe a [[ref: claim]] or a [[ref: credential]] whose [[ref: subject]] is also the [[ref: issuer]].
1976
-
1977
- [[def: self-certified]]
1978
- ~ When a [[ref: party]] provides its own [[ref: certification]] that it is [[ref: compliant]] with a set of [[ref: requirements]], such as a [[ref: governance framework]]. The term is also applied to data structures that are [[ref: cryptographically verifiable]] such as [[ref: self-certifying identifiers]].
1979
-
1980
- [[def: self-certifying identifier, self-certifying identifiers, SCID, SCIDs]]
1981
- ~ A subclass of [[ref: verifiable identifier]] (VID) that is [[ref: cryptographically verifiable]] without the need to rely on any [[ref: third party]] for [[ref: verification]] because the [[ref: identifier]] is cryptographically bound to the [[ref: cryptographic keys]] from which it was generated.
1982
-
1983
- ~ See also: [[ref: autonomic identifier]].
1984
-
1985
- ~ Also known as: [[ref: SCID]].
1986
-
1987
- [[def: self-sovereign identity, SSI]]
1988
- ~ Self-sovereign identity is a [[ref: decentralized identity]] architecture that implements the [[ref: Principles of SSI]] — principally that it puts the [[ref: identity controller]] (e.g., a [[ref: natural person]] or [[ref: organization]]) directly in control of the [[ref: identifiers]] and [[ref: credentials]] they use to assert their [[ref: digital identity]].
1989
-
1990
- ~ See also: [[ref: federated identity]].
1991
-
1992
- ~ Also known as: [[ref: SSI]].
1993
-
1994
- ~ Supporting definitions:
1995
-
1996
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#ssi-self-sovereign-identity): SSI (Self-Sovereign Identity) is a term that has many different interpretations, and that we use to refer to concepts/ideas, architectures, processes and technologies that aim to support (autonomous) [parties](https://essif-lab.github.io/framework/docs/terms/party) as they negotiate and execute electronic [transactions](https://essif-lab.github.io/framework/docs/terms/transaction) with one another.
1997
-
1998
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Self-sovereign_identity): Self-sovereign identity (SSI) is an approach to [digital identity](https://en.wikipedia.org/wiki/Digital_identity) that gives individuals control over the information they use to prove who they are to [websites](https://en.wikipedia.org/wiki/Website), services, and [applications](https://en.wikipedia.org/wiki/Application_software) across the web. Without SSI, individuals with persistent accounts (identities) across the [internet](https://en.wikipedia.org/wiki/Internet) must rely on a number of large identity providers, such as [Facebook](https://en.wikipedia.org/wiki/Facebook) (Facebook Connect) and [Google](https://en.wikipedia.org/wiki/Google) (Google Sign-In), that have control of the information associated with their identity.
1999
-
2000
- [[def: sensitive data]]
2001
- ~ [[ref: Personal data]] that a reasonable [[ref: person]] would view from a privacy protection standpoint as requiring special care above and beyond other [[ref: personal data]].
2002
-
2003
- ~ Supporting definitions:
2004
-
2005
- ~ [PEMC IGR](https://kantarainitiative.org/download/pemc-implementors-guidance-report/): While all Personal Information may be regarded as sensitive in that an unauthorized processing of an individual’s data may be offensive to that person, we use the term here to denote information that a reasonable person would view as requiring special care above and beyond other personal data. For reference see [GDPR Recital #51](https://www.privacy-regulation.eu/en/recital-51-GDPR.htm) or [Sensitive Personal Data](https://w3c.github.io/dpv/dpv/#SensitivePersonalData) in the W3C [Data Privacy Vocabulary](https://w3id.org/dpv).
2006
-
2007
- [[def: session, sessions]]
2008
- ~ See: [[ref: communication session]].
2009
-
2010
- [[def: sociotechnical system, sociotechnical systems, sociotechnical]]
2011
- ~ An approach to complex organizational work design that recognizes the interaction between people and technology in workplaces. The term also refers to coherent systems of human relations, technical objects, and cybernetic processes that inhere to large, complex infrastructures. Social society, and its constituent substructures, qualify as complex sociotechnical systems.
2012
-
2013
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Sociotechnical_system)
2014
-
2015
- [[def: software agent, software agents]]
2016
- ~ In computer science, a software agent is a computer program that acts for a user or other program in a relationship of [[ref: agency]], which derives from the Latin _agere_ (to do): an agreement to act on one's behalf. A [[ref: user agent]] is a specific type of software agent that is used directly by an end-user as the [[ref: principal]].
2017
-
2018
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Software_agent).
2019
-
2020
- ~ See also: [[ref: digital agent]].
2021
-
2022
- [[def: Sovrin Foundation]]
2023
- ~ A 501 (c)(4) nonprofit organization established to administer the [[ref: governance framework]] governing the Sovrin Network, a public service utility enabling [[ref: self-sovereign identity]] on the internet. The Sovrin Foundation is an independent [[ref: organization]] that is responsible for ensuring the Sovrin [[ref: identity]] system is public and globally accessible.
2024
-
2025
- ~ For more information, see: <https://sovrin.org/>
2026
-
2027
- [[def: spanning layer]]
2028
- ~ A specific layer within a [[ref: protocol stack]] that consists of a single protocol explicitly designed to provide interoperability between the [[ref: protocol layers]] above it and below it.
2029
-
2030
- ~ See also: [[ref: hourglass model]], [[ref: trust spanning layer]].
2031
-
2032
- ~ For more information, see: <https://www.isi.edu/newarch/iDOCS/final.finalreport.pdf>, National Academies of Sciences, Engineering, and Medicine. 1997. The Unpredictable Certainty: White Papers. Washington, DC: The National Academies Press. <https://doi.org/10.17226/6062>.
2033
-
2034
- [[def: specification, specifications]]
2035
- ~ See: [[ref: technical specification]].
2036
-
2037
- [[def: SSI]]
2038
- ~ See: [[ref: self-sovereign identity]].
2039
-
2040
- ~ Note: In some contexts, such as academic papers or industry conferences, this acronym has started to replace the term it represents.
2041
-
2042
- [[def: SSL]]
2043
- ~ See: [[ref: Secure Sockets Layer]].
2044
-
2045
- [[def: stream, streams]]
2046
- ~ In the context of digital [[ref: communications]], and in particular [[ref: streaming media]], a flow of [[ref: data]] delivered in a continuous manner from a server to a client rather than in discrete [[ref: messages]].
2047
-
2048
- [[def: streaming media]]
2049
- ~ Streaming media is multimedia for playback using an offline or online media player. Technically, the stream is delivered and consumed in a continuous manner from a client, with little or no intermediate storage in network elements. Streaming refers to the delivery method of content, rather than the content itself.
2050
-
2051
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Streaming_media).
2052
-
2053
- [[def: subject, subjects]]
2054
- ~ The [[ref: entity]] described by one or more [[ref: claims]], particularly in the context of [[ref: credentials]].
2055
-
2056
- ~ Supporting definitions:
2057
-
2058
- ~ [W3C VC](https://www.w3.org/TR/vc-data-model/#terminology): A thing about which [claims](https://www.w3.org/TR/vc-data-model/#dfn-claims) are made.
2059
-
2060
- ~ [eSSIF-Lab:](https://essif-lab.github.io/framework/docs/essifLab-glossary#subject) the (single) [[ref: entity]] to which a given set of coherent [[ref: data]] relates/pertains. Examples of such sets include attributes, [[ref: Claims]]/Assertions, files/dossiers, [[ref: verifiable credentials]], [(partial) identities](https://essif-lab.github.io/framework/docs/terms/partial-identity), [employment contracts](https://essif-lab.github.io/framework/docs/terms/employment-contract), etc.
2061
-
2062
- [[def: subscription, subscriptions]]
2063
- ~ In the context of decentralized digital trust infrastructure, a subscription is an agreement between a first [[ref: digital agent]]—the _publisher_—to automatically send a second [[ref: digital agent]]—the _subscriber_—a [[ref: message]] when a specific type of event happens in the [[ref: wallet]] or [[ref: vault]] managed by the first [[ref: digital agent]].
2064
-
2065
- [[def: supporting system, supporting systems]]
2066
- ~ A system that operates at [[ref: ToIP Layer 1]], the [[ref: trust support layer]] of the [[ref: ToIP stack]]. A supporting system is one of three types of systems defined in the [[ref: ToIP Technology Architecture Specification]].
2067
-
2068
- ~ See also: [[ref: endpoint system]], [[ref: intermediary system]].
2069
-
2070
- [[def: Sybil attack, Sybil attacks]]
2071
- ~ A Sybil attack is a type of attack on a computer network service in which an attacker subverts the service's [[ref: reputation system]] by creating a large number of [[ref: pseudonymous]] [[ref: identities]] and uses them to gain a disproportionately large influence. It is named after the subject of the book _Sybil_, a case study of a woman diagnosed with dissociative identity disorder.
2072
-
2073
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Sybil_attack).
2074
-
2075
- [[def: system of record, systems of record]]
2076
- ~ A system of record (SOR) or source system of record (SSoR) is a data management term for an information storage system (commonly implemented on a computer system running a database management system) that is the [[ref: authoritative source]] for a given data element or piece of information.
2077
-
2078
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/System_of_record)
2079
-
2080
- ~ See also: [[ref: authoritative source]], [[ref: trust registry]], [[ref: verifiable data registry]].
2081
-
2082
- [[def: tamper evident, tamper-evident]]
2083
- ~ A process which makes alterations to the data easily detectable. Form digital data objects, this is typically achieved via [[ref: cryptographic verification]].
2084
-
2085
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/tamper_evident).
2086
-
2087
- [[def: tamper resistant, tamper resistance, tamper-resistant, tamper-resistance]]
2088
- ~ A process which makes alterations to [[ref: data]] difficult (hard to perform), costly (expensive to perform), or both. For digital data objects, this is typically achieved via [[ref: cryptographic verification]].
2089
-
2090
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/tamper_resistant).
2091
-
2092
- [[def: TCP]]
2093
- ~ See: [[ref: Transmission Control Protocol]].
2094
-
2095
- [[def: TCP/IP]]
2096
- ~ See: [[ref: Internet Protocol Suite]].
2097
-
2098
- [[def: TCP/IP stack, TCP/IP protocol stack]]
2099
- ~ The [[ref: protocol stack]] implementing the [[ref: TCP/IP]] suite.
2100
-
2101
- [[def: technical requirement, technical requirements]]
2102
- ~ A [[ref: requirement]] for a hardware or software component or system. In the context of decentralized digital trust infrastructure, technical requirements are a subset of [[ref: governance requirements]]. Technical requirements are often specified in a [[ref: technical specification]].
2103
-
2104
- ~ For more information, see: <https://datatracker.ietf.org/doc/html/rfc2119>
2105
-
2106
- ~ Note: In ToIP architecture, both technical requirements and [[ref: governance requirements]] are expressed using the keywords defined in IETF RFC 2119.
2107
-
2108
- [[def: technical specification, technical specifications]]
2109
- ~ A document that specifies, in a complete, precise, verifiable manner, the [[ref: requirements]], design, behavior, or other characteristics of a system or component and often the procedures for determining whether these provisions have been satisfied.
2110
-
2111
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/specification)
2112
-
2113
- ~ See also: [[ref: governance framework]], [[ref: governance requirement]], [[ref: policy]], [[ref: rule]].
2114
-
2115
- [[def: technical trust]]
2116
- ~ A [[ref: level of assurance]] in a [[ref: trust relationship]] that can be achieved only via technical means such as hardware, software, network protocols, and cryptography.[[ref: Cryptographic trust]] is a specialized type of technical trust.
2117
-
2118
- ~ Contrast with: [[ref: human trust]].
2119
-
2120
- [[def: TEE]]
2121
- ~ See: [[ref: trusted execution environment]].
2122
-
2123
- [[def: term, terms]]
2124
- ~ A unit of text (i.e., a word or phrase) that is used in a particular context or scope to refer to a [[ref: concept]] (or a relation between [[ref: concepts]], or a [[ref: property]] of a [[ref: concept]]).
2125
-
2126
- ~ Supporting definitions:
2127
-
2128
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#term): a word or phrase (i.e.: text) that is used in at least one [scope](https://essif-lab.github.io/framework/docs/terms/scope)/context to represent a specific [concept](https://essif-lab.github.io/framework/docs/terms/concept).
2129
-
2130
- ~ [Merriam Webster:](https://www.merriam-webster.com/dictionary/term) a word or expression that has a precise meaning in some uses or is peculiar to a science, art, profession, or subject.
2131
-
2132
- ~ Note: A term MUST NOT be confused with the concept it refers to (which is an extremely common mistake).
2133
-
2134
- [[def: terminology, terminologies]]
2135
- ~ Terminology is a group of specialized words and respective meanings in a particular field, and also the study of such [[ref: terms]] and their use; the latter meaning is also known as _terminology science_. A [[ref: term]] is a word, compound word, or multi-word expressions that in specific contexts is given specific meanings—meaning which may deviate from the meanings the same words have in other contexts and in everyday language. Terminology is a discipline that studies, among other things, the development of such [[ref: terms]] and their interrelationships within a specialized domain. Terminology differs from _lexicography_, as the former involves the study of [[ref: concepts]], conceptual systems and their labels ([[ref: terms]]), whereas lexicography studies words and their meanings.
2136
-
2137
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Terminology).
2138
-
2139
- [[def: terms community, terms communities]]
2140
- ~ A group of [[ref: parties]] who share the need for a common [[ref: terminology]].
2141
-
2142
- ~ See also: [[ref: trust community]].
2143
-
2144
- [[def: terms wiki, terms wikis]]
2145
- ~ A wiki website used by a [[ref: terms community]] to input, maintain, and publish its [[ref: terminology]]. The Concepts and Terminology Working Group at the [[ref: ToIP Foundation]] has created a simple template for GitHub-based terms wikis.
2146
-
2147
- [[def: thing, things]]
2148
- ~ An [[ref: entity]] that is neither a [[ref: natural person]] nor an [[ref: organization]] and thus cannot be a [[ref: party]]. A thing may be a [[ref: natural thing]] or a [[ref: man-made thing]].
2149
-
2150
- [[def: third party, third parties]]
2151
- ~ A [[ref: party]] that is not directly involved in the [[ref: trust relationship]] between a [[ref: first party]] and a [[ref: second party]], but provides supporting services to either or both of them.
2152
-
2153
- [[def: three party model]]
2154
- ~ The [[ref: issuer]]—[[ref: holder]]—[[ref: verifier]] model used by all types of [[ref: physical credentials]] and [[ref: digital credentials]] to enable [[ref: transitive trust decisions]].
2155
-
2156
- ~ Also known as: [[ref: trust triangle]].
2157
-
2158
- [[def: timestamp, timestamps]]
2159
- ~ A token or packet of information that is used to provide assurance of timeliness; the timestamp contains timestamped data, including a time, and a signature generated by a [[ref: trusted timestamp authority]] (TTA).
2160
-
2161
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/timestamp).
2162
-
2163
- ~ Supporting definitions:
2164
-
2165
- ~ [TechTarget](https://www.techtarget.com/whatis/definition/timestamp#:~:text=A%20timestamp%20is%20the%20current,minute%20fractions%20of%20a%20second.): A timestamp is the current time of an event that a computer records. Through mechanisms, such as the [Network Time Protocol](https://www.techtarget.com/searchnetworking/definition/Network-Time-Protocol), a computer maintains accurate current time, calibrated to minute fractions of a second. Such precision makes it possible for networked computers and applications to communicate effectively.
2166
-
2167
- [[def: TLS]]
2168
- ~ See: [[ref: Transport Layer Security]].
2169
-
2170
- [[def: ToIP]]
2171
- ~ See: [[ref: Trust Over IP]]
2172
-
2173
- [[def: ToIP application, ToIP applications]]
2174
- ~ A [[ref: trust application]] that runs at [[ref: ToIP Layer 4]], the [[ref: trust application layer]].
2175
-
2176
- [[def: ToIP channel, ToIP channels]]
2177
- ~ See: [[ref: ToiP relationship]].
2178
-
2179
- [[def: ToIP communication, ToIP communications]]
2180
- ~ [[ref: Communication]] that uses the [[ref: ToIP stack]] to deliver [[ref: ToIP messages]] between [[ref: ToIP endpoints]], optionally using [[ref: ToIP intermediaries]] to provide [[ref: authenticity]], [[ref: confidentiality]], and [[ref: correlation privacy]].
2181
-
2182
- [[def: ToIP connection, ToIP connections]]
2183
- ~ See: [[ref: ToIP relationship]].
2184
-
2185
- [[def: ToIP controller, ToIP controllers]]
2186
- ~ The [[ref: controller]] of a [[ref: verifiable identifier]] (VID) used with the [[ref: ToIP stack]].
2187
-
2188
- [[def: ToIP Foundation]]
2189
- ~ A non-profit project of the [Linux Foundation](https://www.linuxfoundation.org/) chartered to define an overall architecture for decentralized digital trust infrastructure known as the [[ref: ToIP stack]].
2190
-
2191
- ~ See also: [[ref: Decentralized Identity Foundation]], [[ref: OpenWallet Foundation]].
2192
-
2193
- ~ For more information, see: <https://trustoverip.org/>.
2194
-
2195
- [[def: ToIP endpoint, ToIP endpoints]]
2196
- ~ An [[ref: endpoint]] that communicates via the [[ref: ToIP Trust Spanning Protocol]] (TSP) as described in the [[ref: ToIP Technology Architecture Specification]].
2197
-
2198
- [[def: ToIP Governance Architecture Specification]]
2199
- ~ The specification defining the [[ref: requirements]] for the [[ref: ToIP Governance Stack]] published by the [[ref: ToIP Foundation]].
2200
-
2201
- ~ For more information, see: <https://trustoverip.org/our-work/deliverables/>.
2202
-
2203
- [[def: ToIP governance framework, ToIP governance frameworks]]
2204
- ~ A [[ref: governance framework]] that conforms to the requirements of the [[ref: ToIP Governance Architecture Specification]].
2205
-
2206
- [[def: ToIP Governance Metamodel]]
2207
- ~ A structural model for [[ref: governance frameworks]] that specifies the recommended [[ref: governance documents]] that should be included depending on the [[ref: objectives]] of the [[ref: trust community]].
2208
-
2209
- [[def: ToIP Governance Stack]]
2210
- ~ The governance half of the four layer [[ref: ToIP stack]] as defined by the [[ref: ToIP Governance Architecture Specification]].
2211
-
2212
- ~ See also: [[ref: ToIP Technology Stack]].
2213
-
2214
- [[def: ToIP identifier, ToIP identifiers]]
2215
- ~ A [[ref: verifiable identifier]] (VID) for an [[ref: entity]] that is addressable using the [[ref: ToIP stack]].
2216
-
2217
- ~ See also: [[ref: autonomic identifier]], [[ref: decentralized identifier]], [[ref: self-certifying identifier]].
2218
-
2219
- ~ For more information, see: [Section 6.4](https://github.com/trustoverip/TechArch/blob/main/spec.md#64-toip-identifiers) of the [[ref: ToIP Technology Architecture Specification]].
2220
-
2221
- [[def: ToIP intermediary, ToIP intermediaries]]
2222
- ~ See: [[ref: intermediary system]].
2223
-
2224
- [[def: ToIP layer, ToIP layers]]
2225
- ~ One of four [[ref: protocol layers]] in the [[ref: ToIP stack]]. The four layers are [[ref: ToIP Layer 1]], [[ref: ToIP Layer 2]], [[ref: ToIP Layer 3]], and [[ref: ToIP Layer 4]].
2226
-
2227
- ~ For more information, see: [[ref: ToIP Technology Architecture Specification]], [[ref: ToIP Governance Architecture Specification]].
2228
-
2229
- [[def: ToIP Layer 1]]
2230
- ~ The [[ref: trust support]] layer of the [[ref: ToIP stack]], responsible for supporting the [[ref: trust spanning protocol]] at [[ref: ToIP Layer 2]].
2231
-
2232
- [[def: ToIP Layer 2]]
2233
- ~ The [[ref: trust spanning layer]] of the [[ref: ToIP stack]], responsible for enabling [[ref: trust task protocols]] at [[ref: ToIP Layer 3]].
2234
-
2235
- [[def: ToIP Layer 3]]
2236
- ~ The [[ref: trust task]] layer of the [[ref: ToIP stack]], responsible for enabling [[ref: trust applications]] at [[ref: ToIP Layer 4]].
2237
-
2238
- [[def: ToIP Layer 4]]
2239
- ~ The [[ref: trust application]] layer of the [[ref: ToIP stack]], where end-users have the direct [[ref: human experience]] of using applications that call [[ref: trust task protocols]] to engage in [[ref: trust relationships]] and make [[ref: trust decisions]] using ToIP decentralized digital trust infrastructure.
2240
-
2241
- [[def: ToIP message, ToIP messages]]
2242
- ~ A [[ref: message]] communicated between [[ref: ToIP endpoints]] using the [[ref: ToIP stack]]. ToIP messages are transmitted over the [[ref: ToIP Trust Spanning Protocol]] (TSP) at [[ref: Layer 2]] of the [[ref: ToIP stack]].
2243
-
2244
- [[def: ToIP relationship]]
2245
- ~ A [[ref: VID-to-VID]] relationship formed between two [[ref: entities]] over the [[ref: ToIP Trust Spanning Protocol]].
2246
-
2247
- [[def: ToIP specification, ToIP specifications]]
2248
- ~ A specification published by the [[ref: ToIP Foundation]]. ToIP specifications may be in one of three states: _Draft Deliverable_, _Working Group Approved Deliverable_, or _ToIP Approved Deliverable_.
2249
-
2250
- [[def: ToIP stack, ToIP stacks]]
2251
- ~ The layered architecture for decentralized digital trust infrastructure defined by the [[ref: ToIP Foundation]]. The ToIP stack is a dual stack consisting of two halves: the [[ref: ToIP Technology Stack]] and the [[ref: ToIP Governance Stack]]. The four layers in the ToIP stack are [[ref: ToIP Layer 1]], [[ref: ToIP Layer 2]], [[ref: ToIP Layer 3]], and [[ref: ToIP Layer 4]].
2252
-
2253
- ~ For more information, see: [[ref: ToIP Technology Architecture Specification]], [[ref: ToIP Governance Architecture Specification]].
2254
-
2255
- [[def: ToIP system, ToIP systems]]
2256
- ~ A computing system that participates in the [[ref: ToIP Technology Stack]]. There are three types of ToIP systems: [[ref: endpoint systems]], [[ref: intermediary systems]], and [[ref: supporting systems]].
2257
-
2258
- ~ For more information, see: [Section 6.3](https://github.com/trustoverip/TechArch/blob/main/spec.md#63-high-level-system-architecture) of the [[ref: ToIP Technology Architecture Specification]].
2259
-
2260
- [[def: ToIP trust network, ToIP trust networks]]
2261
- ~ A [[ref: trust network]] implemented using the [[ref: ToIP stack]].
2262
-
2263
- [[def: ToIP Technology Architecture Specification]]
2264
- ~ The [[ref: technical specification]] defining the [[ref: requirements]] for the [[ref: ToIP Technology Stack]] published by the [[ref: ToIP Foundation]].
2265
-
2266
- ~ For more information: [[ref: ToIP Technology Architecture Specification]].
2267
-
2268
- [[def: ToIP Technology Stack]]
2269
- ~ The technology half of the four layer [[ref: ToIP stack]] as defined by the [[ref: ToIP Technology Architecture Specification]].
2270
-
2271
- ~ See also: [[ref: ToIP Governance Stack]], [[ref: ToIP layer]].
2272
-
2273
- [[def: ToIP trust community]]
2274
- ~ A [[ref: trust community]] governed by a [[ref: ToIP governance framework]].
2275
-
2276
- [[def: ToIP Trust Registry Protocol]]
2277
- ~ The open standard [[ref: trust task protocol]] defined by the [[ref: ToIP Foundation]] to perform the [[ref: trust task]] of querying a [[ref: trust registry]]. The ToIP Trust Registry Protocol operates at [[ref: Layer 3]] of the [[ref: ToIP stack]].
2278
-
2279
- [[def: ToIP Trust Spanning Protocol, TSP]]
2280
- ~ The ToIP Trust Spanning Protocol (TSP) is the ToIP Layer 2 protocol for [[ref: verifiable messaging]] that implements the [[ref: trust spanning layer]] of the [[ref: ToIP stack]].  The TSP enables [[ref: actors]] in different digital [[ref: trust domains]] to interact in a similar way to how the Internet Protocol (IP) enables devices on different local area networks to exchange data.
2281
-
2282
- ~ Mental model: [[ref: hourglass model,]] see the [Design Principles for the ToIP Stack](https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf).
2283
-
2284
- ~ For more information, see: [Section 7.3](https://github.com/trustoverip/TechArch/blob/main/spec.md#73-layer-2-trust-spanning) of the [[ref: ToIP Technology Architecture Specification]] and the [Trust Spanning Protocol Task Force](https://wiki.trustoverip.org/display/HOME/ToIP+Trust+Spanning+Protocol+Specification).
2285
-
2286
- [[def: transaction, transactions]]
2287
- ~ A discrete event between a user and a system that supports a business or programmatic purpose. A digital system may have multiple categories or types of transactions, which may require separate analysis within the overall digital identity [[ref: risk assessment]].
2288
-
2289
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/transaction).
2290
-
2291
- ~ See also: [[ref: connection]].
2292
-
2293
- ~ Supporting definitions:
2294
-
2295
- ~ eSSIF-Lab: the exchange of goods, services, funds, or data between some [parties](https://essif-lab.github.io/framework/docs/terms/party) (called [participants](https://essif-lab.github.io/framework/docs/terms/participant) of the [transaction](https://essif-lab.github.io/framework/docs/terms/transaction)).
2296
-
2297
- [[def: transitive trust decision, transitive trust decisions]]
2298
- ~ A [[ref: trust decision]] made by a [[ref: first party]] about a [[ref: second party]] or another [[ref: entity]] based on information about the [[ref: second party]] or the other [[ref: entity]] that is obtained from one or more [[ref: third parties]].
2299
-
2300
- ~ Note: A primary purpose of [[ref: digital credentials]], [[ref: chained credentials]], [[ref: trust registries]], and the [[ref: ToIP stack]] is to facilitate transitive trust decisions.
2301
-
2302
- ~ For more information, see: [Design Principles for the ToIP Stack](https://trustoverip.org/our-work/design-principles/).
2303
-
2304
- [[def: Transmission Control Protocol, TCP]]
2305
- ~ The Transmission Control Protocol (TCP) is one of the main protocols of the [[ref: Internet protocol suite]]. It originated in the initial network implementation in which it complemented the [[ref: Internet Protocol]] (IP). Therefore, the entire suite is commonly referred to as [[ref: TCP/IP]]. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport Layer of the TCP/IP suite. [[ref: SSL]]/[[ref: TLS]] often runs on top of TCP.
2306
-
2307
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Transmission_Control_Protocol).
2308
-
2309
- ~ Also known as: [[ref: TCP]].
2310
-
2311
- ~ See also: [[ref: User Datagram Protocol]].
2312
-
2313
- [[def: transport layer]]
2314
- ~ Layer of the [[ref: TCP/IP protocol stack]] that is responsible for reliable connection-oriented or connectionless end-to-end [[ref: communications]].
2315
-
2316
- ~ Source: [NIST-CRSC](https://csrc.nist.gov/glossary/term/transport_layer).
2317
-
2318
- [[def: Transport Layer Security]]
2319
- ~ Transport Layer Security (TLS) is a cryptographic protocol designed to provide [[ref: communications]] security over a computer network. The protocol is widely used in applications such as email, instant messaging, and [[ref: Voice over IP]], but its use in securing HTTPS remains the most publicly visible. The TLS protocol aims primarily to provide security, including privacy ([[ref: confidentiality]]), integrity, and [[ref: authenticity]] through the use of cryptography, such as the use of [[ref: certificates]], between two or more communicating computer applications.
2320
-
2321
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Transport_Layer_Security).
2322
-
2323
- ~ Also known as: [[ref: TLS]].
2324
-
2325
- ~ Note: TLS replaced the deprecated [[ref: Secure Sockets Layer]] (SSL) protocol.
2326
-
2327
- [[def: tribal knowledge]]
2328
- ~ [[ref: Knowledge]] that is known within an “in-group” of people but unknown outside of it. A tribe, in this sense, is a group of people that share such a common [[ref: knowledge]].
2329
-
2330
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Tribal_knowledge)
2331
-
2332
- [[def: trust, trusts, trusted]]
2333
- ~ A belief that an [[ref: entity]] will behave in a predictable manner in specified circumstances. The [[ref: entity]] may be a [[ref: person]], process, object or any combination of such components. The entity can be of any size from a single hardware component or software module, to a piece of equipment identified by make and model, to a site or location, to an [[ref: organization]], to a nation-state. Trust, while inherently a subjective determination, can be based on objective evidence and subjective elements. The objective grounds for trust can include for example, the results of information technology product testing and evaluation. Subjective belief, level of comfort, and experience may supplement (or even replace) objective evidence, or substitute for such evidence when it is unavailable. Trust is usually relative to a specific circumstance or situation (e.g., the amount of money involved in a transaction, the sensitivity or criticality of information, or whether safety is an issue with human lives at stake). Trust is generally not transitive (e.g., you trust a friend but not necessarily a friend of a friend). Finally, trust is generally earned, based on experience or measurement.
2334
-
2335
- ~ Source: [NIST Special Publication 800-39](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-39.pdf) p.24
2336
-
2337
- ~ See also: [[ref: trust decision]], [[ref: transitive trust decision]].
2338
-
2339
- ~ For more information, see: [Design Principles for the ToIP Stack](https://trustoverip.org/our-work/design-principles/).
2340
-
2341
- [[def: trust anchor, trust anchors]]
2342
- ~ The [[ref: authoritative source]] that serves as the origin of a [[ref: trust chain]].
2343
-
2344
- ~ Also known as: [[ref: trust root]].
2345
-
2346
- ~ For more information, see: [Design Principles for the ToIP Stack](https://trustoverip.org/our-work/design-principles/).
2347
-
2348
- ~ Note: The term “trust anchor” is most commonly used in cryptography and [[ref: public key infrastructure]].
2349
-
2350
- [[def: trust application, trust applications]]
2351
- ~ An application that runs at [[ref: ToIP Layer 4]] in order to perform [[ref: trust tasks]] or engage in other [[ref: verifiable messaging]] using the [[ref: ToIP stack]].
2352
-
2353
- [[def: trust application layer]]
2354
- ~ In the context of the [[ref: ToIP stack]], the [[ref: trust application]] layer is [[ref: ToIP Layer 4]]. Applications running at this layer call [[ref: trust task protocols]] at [[ref: ToIP Layer 3]].
2355
-
2356
- [[def: trust assurance, trust assurances]]
2357
- ~ A process that provides a [[ref: level of assurance]] sufficient to make a particular [[ref: trust decision]].
2358
-
2359
- [[def: trust basis]]
2360
- ~ The [[ref: properties]] of a [[ref: verifiable identifier]] (VID) or a [[ref: ToIP system]] that enable a [[ref: party]] to [[ref: appraise]] it to determine a [[ref: trust limit]].
2361
-
2362
- ~ See also: [[ref: appraisability]].
2363
-
2364
- [[def: trust boundary, trust boundaries]]
2365
- ~ The border of a [[ref: trust domain]].
2366
-
2367
- [[def: trust chain, trust chains]]
2368
- ~ A set of [[ref: cryptographically verifiable]] links between [[ref: digital credentials]] or other [[ref: data]] containers that enable [[ref: transitive trust decisions]].
2369
-
2370
- ~ See also: [[ref: chained credentials]], [[ref: trust graph]].
2371
-
2372
- ~ For more information, see: [Design Principles for the ToIP Stack](https://trustoverip.org/our-work/design-principles/).
2373
-
2374
- [[def: trust community, trust communities]]
2375
- ~ A set of [[ref: parties]] who collaborate to achieve a mutual set of [[ref: trust objectives]].
2376
-
2377
- ~ See also: [[ref: digital trust ecosystem]], [[ref: ToIP trust community]].
2378
-
2379
- ~ Note: A trust community may be large or small, formal or informal. In a formal trust community, the set of [[ref: policies]] and [[ref: rules]] governing behavior of members are usually published in a [[ref: governance framework]] or [[ref: trust framework]]. In an informal trust community, the policies or rules governing the behavior of members may be [[ref: tribal knowledge]].
2380
-
2381
- [[def: trust context, trust contexts]]
2382
- ~ The context in which a specific [[ref: party]] makes a specific [[ref: trust decision]]. Many different factors may be involved in establishing a trust context, such as: the relevant interaction or [[ref: transaction]]; the presence or absence of existing [[ref: trust relationships]]; the applicability of one or more [[ref: governance frameworks]]; and the location, time, network, and/or devices involved. A trust context may be implicit or explicit; if explicit, it may be identified using an [[ref: identifier]]. A [[ref: ToIP governance framework]] is an example of an explicit trust context identified by a [[ref: verifiable identifier]] (VID).
2383
-
2384
- ~ See also: [[ref: trust domain]].
2385
-
2386
- ~ For more information, see: [Design Principles for the ToIP Stack](https://trustoverip.org/our-work/design-principles/).
2387
-
2388
- [[def: trust decision, trust decisions]]
2389
- ~ A decision that a [[ref: party]] needs to make about whether to engage in a specific interaction or [[ref: transaction]] with another [[ref: entity]] that involves real or perceived [[ref: risks]].
2390
-
2391
- ~ See also: [[ref: transitive trust decision]].
2392
-
2393
- ~ For more information, see: [Design Principles for the ToIP Stack](https://trustoverip.org/our-work/design-principles/).
2394
-
2395
- [[def: trust domain, trust domains]]
2396
- ~ A [[ref: security domain]] defined by a computer hardware or software architecture, a [[ref: security policy]], or a [[ref: trust community]], typically via a [[ref: trust framework]] or [[ref: governance framework]].
2397
-
2398
- ~ See also: [[ref: trust context]], [[ref: digital trust ecosystem]].
2399
-
2400
- [[def: trust ecosystem, trust ecosystems]]
2401
- ~ See [[ref: digital trust ecosystem]].
2402
-
2403
- [[def: trust establishment]]
2404
- ~ The process two or more [[ref: parties]] go through to establish a [[ref: trust relationship]]. In the context of decentralized digital trust infrastructure, trust establishment takes place at two levels. At the technical trust level, it includes some form of [[ref: key establishment]]. At the human trust level, it may be accomplished via an [[ref: out-of-band introduction]], the exchange of [[ref: digital credentials]], queries to one or more [[ref: trust registries]], or evaluation of some combination of [[ref: human-readable]] and [[ref: machine-readable]] [[ref: governance frameworks]].
2405
-
2406
- [[def: trust factor, trust factors]]
2407
- ~ A [[ref: property]], [[ref: relationship]], or other signal that can contribute to a [[ref: party]] making a [[ref: trust decision]].
2408
-
2409
- [[def: trust framework, trust frameworks]]
2410
- ~ A term (most frequently used in the [[ref: digital identity]] industry) to describe a [[ref: governance framework]] for a [[ref: digital identity]] system, especially a [[ref: federation]].
2411
-
2412
- [[def: trust graph, trust graphs]]
2413
- ~ A [[ref: data]] structure describing the [[ref: trust relationship]] between two or more [[ref: entities]]. A simple trust graph may be expressed as a [[ref: trust list]]. More complex trust graphs can be recorded or registered in and queried from a [[ref: trust registry]]. Trust graphs can also be expressed using [[ref: trust chains]] and [[ref: chained credentials]]. Trust graphs can enable [[ref: verifiers]] and [[ref: relying parties]] to make [[ref: transitive trust decisions]].
2414
-
2415
- ~ See also: [[ref: authorization graph]], [[ref: governance graph]], [[ref: reputation graph]].
2416
-
2417
- [[def: trust limit, trust limits]]
2418
- ~ A limit to the degree a [[ref: party]] is willing to trust an [[ref: entity]] in a specific [[ref: trust relationship]] within a specific [[ref: trust context]].
2419
-
2420
- ~ For more information, see: [Design Principles for the ToIP Stack](https://trustoverip.org/our-work/design-principles/).
2421
-
2422
- [[def: trust list, trust lists]]
2423
- ~ A one-dimensional [[ref: trust graph]] in which an [[ref: authoritative source]] publishes a list of [[ref: entities]] that are trusted in a specific [[ref: trust context]]. A trust list can be considered a simplified form of a [[ref: trust registry]].
2424
-
2425
- [[def: trust network, trust networks]]
2426
- ~ A network of [[ref: parties]] who are connected via [[ref: trust relationships]] (such as via a membership agreement) conforming to [[ref: requirements]] defined in a legal regulation, [[ref: trust framework]] or [[ref: governance framework]]. A trust network is more formal than a [[ref: digital trust ecosystem]]; the latter may connect parties more loosely via transitive trust relationships and/or across multiple trust networks.
2427
-
2428
- ~ See also: [[ref: ToIP trust network]].
2429
-
2430
- [[def: trust objective, trust objectives]]
2431
- ~ An [[ref: objective]] shared by the [[ref: parties]] in a [[ref: trust community]] to establish and maintain [[ref: trust relationships]].
2432
-
2433
- [[def: Trust over IP]]
2434
- ~ A term coined by John Jordan to describe the decentralized digital trust infrastructure made possible by the [[ref: ToIP stack]]. A play on the term _Voice over IP_ (abbreviated _VoIP_). The term was adopted as the name for the Trust over IP Foundation aka [[ref: ToIP Foundation]].
2435
-
2436
- ~ Also known as: [[ref: ToIP]].
2437
-
2438
- [[def: trust registry, trust registries]]
2439
- ~ A [[ref: registry]] that serves as an [[ref: authoritative source]] for [[ref: trust graphs]] or other [[ref: governed information]] describing one or more [[ref: trust communities]]. A trust registry is typically [[ref: authorized]] by a [[ref: governance framework]].
2440
-
2441
- ~ See also: [[ref: trust list]], [[ref: verifiable data registry]].
2442
-
2443
- [[def: trust registry protocol]]
2444
- ~ See: [[ref: ToIP Trust Registry Protocol]].
2445
-
2446
- [[def: trust relationship, trust relationships]]
2447
- ~ A relationship between a [[ref: party]] and an [[ref: entity]] in which the [[ref: party]] has decided to [[ref: trust]] the [[ref: entity]] in one or more [[ref: trust contexts]] up to a [[ref: trust limit]].
2448
-
2449
- ~ Supporting definitions:
2450
-
2451
- ~ [NIST](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v1r1.pdf): An agreed upon relationship between two or more system elements that is governed by criteria for secure interaction, behavior, and outcomes relative to the protection of assets.
2452
-
2453
- ~ For more information, see: [Design Principles for the ToIP Stack](https://trustoverip.org/our-work/design-principles/).
2454
-
2455
- [[def: trust root, trust roots]]
2456
- ~ See: [[ref: trust anchor]]
2457
-
2458
- [[def: trust service provider, trust service providers]]
2459
- ~ In the context of specific [[ref: digital trust ecosystems]], such as the European Union’s eIDAS regulations, a trust service provider is a [[ref: legal entity]] that provides specific [[ref: trust support]] services as required by legal regulations, [[ref: trust frameworks]], or [[ref: governance frameworks]]. In the larger context of [[ref: ToIP]] infrastructure, a trust service provider is a provider of services based on the [[ref: ToIP stack]]. Most generally, a trust service provider is to the trust layer for the Internet what an Internet service provider (ISP) is to the Internet layer.
2460
-
2461
- ~ Supporting definitions:
2462
-
2463
- ~ Wikipedia: A trust service provider (TSP) is a person or legal entity providing and preserving [digital certificates](https://en.wikipedia.org/wiki/Digital_certificate) to create and validate [electronic signatures](https://en.wikipedia.org/wiki/Electronic_signature) and to authenticate their signatories as well as websites in general. Trust service providers are qualified [certificate authorities](https://en.wikipedia.org/wiki/Certificate_authority) required in the [European Union](https://en.wikipedia.org/wiki/European_Union) and in Switzerland in the context of regulated [electronic signing](https://en.wikipedia.org/wiki/Electronic_signature) procedures.
2464
-
2465
- ~ Note: In the industry, the acronym "TSP" is used for both [[ref: trust service provider]] and the [[ref: ToIP Trust Spanning Protocol]]. In the ToIP Glossary, the acronmym "TSP" will only be used for the latter.
2466
-
2467
- [[def: trust support, trust supports]]
2468
- ~ A system, protocol, or other infrastructure whose function is to facilitate the establishment and maintenance of [[ref: trust relationships]] at higher [[ref: protocol layers]]. In the [[ref: ToIP stack]], the [[ref: trust support layer]] is [[ref: Layer 1]].
2469
-
2470
- [[def: trust support layer]]
2471
- ~ In the context of the [[ref: ToIP stack]], the [[ref: trust support]] layer is [[ref: ToIP Layer 1]]. It supports the operations of the [[ref: ToIP Trust Spanning Protocol]] at [[ref: ToIP Layer 2]].
2472
-
2473
- [[def: trust spanning layer]]
2474
- ~ A [[ref: spanning layer]] designed to span between different digital [[ref: trust domains]]. In the [[ref: ToIP stack]], the trust spanning layer is [[ref: ToIP Layer 2]].
2475
-
2476
- ~ Mental model: [[ref: hourglass model,]] see [[ref: ToIP Technology Architecture Specification]]
2477
-
2478
- ~ For more information, see: [Section 7.3](https://github.com/trustoverip/TechArch/blob/main/spec.md#73-layer-2-trust-spanning) of the [[ref: ToIP Technology Architecture Specification]].
2479
-
2480
- [[def: trust spanning protocol]]
2481
- ~ See: [[ref: ToIP Trust Spanning Protocol]].
2482
-
2483
- [[def: trust task, trust tasks]]
2484
- ~ A specific task that involves establishing, verifying, or maintaining [[ref: trust relationships]] or exchanging [[ref: verifiable messages]] or [[ref: verifiable data]] that can be performed on behalf of a [[ref: trust application]] by a [[ref: trust task protocol]] at [[ref: Layer 3]] of the [[ref: ToIP stack]].
2485
-
2486
- ~ For more information, see [Section 7.4](https://github.com/trustoverip/TechArch/blob/main/spec.md#74-layer-3-trust-tasks) of the [[ref: ToIP Technology Architecture Specification]].
2487
-
2488
- [[def: trust task layer]]
2489
- ~ In the context of the [[ref: ToIP stack]], the [[ref: trust task]] layer is [[ref: ToIP Layer 3]]. It supports [[ref: trust applications]] operating at [[ref: ToIP Layer 4]].
2490
-
2491
- [[def: trust task protocol, trust task protocols]]
2492
- ~ A [[ref: ToIP Layer 3]] protocol that implements a specific [[ref: trust task]] on behalf of a [[ref: trust application]] operating at [[ref: ToIP Layer 4]].
2493
-
2494
- [[def: trust triangle, trust triangles]]
2495
- ~ See: [[ref: three-party model]].
2496
-
2497
- [[def: trusted execution environment, trusted execution environments, TEE, TEEs]]
2498
- ~ A trusted execution environment (TEE) is a secure area of a main processor. It helps code and data loaded inside it to be protected with respect to [[ref: confidentiality]] and [[ref: integrity]]. Data [[ref: integrity]] prevents [[ref: unauthorized]] [[ref: entities]] from outside the TEE from altering [[ref: data]], while code integrity prevents code in the TEE from being replaced or modified by [[ref: unauthorized]] [[ref: entities]], which may also be the computer [[ref: owner]] itself as in certain [[ref: DRM]] schemes.
2499
-
2500
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Trusted_execution_environment).
2501
-
2502
- ~ Also known as: [[ref: TEE]].
2503
-
2504
- ~ See also: [[ref: Secure Enclave]].
2505
-
2506
- [[def: trusted role, trusted roles]]
2507
- ~ A [[ref: role]] that performs restricted activities for an [[ref: organization]] after meeting competence, security and background [[ref: verification]] [[ref: requirements]] for that [[ref: role]].
2508
-
2509
- [[def: trusted third party, trusted third parties, trusted 3rd party, trusted 3rd parties, TTP, TTPs]]
2510
- ~ In [[ref: cryptography]], a trusted [[ref: third party]] (TTP) is an entity which facilitates interactions between two [[ref: parties]] who both trust the third party; the third party reviews all critical transaction communications between the parties, based on the ease of creating fraudulent digital content. In TTP models, the [[ref: relying parties]] use this trust to secure their own interactions. TTPs are common in any number of commercial transactions and in cryptographic digital transactions as well as cryptographic protocols, for example, a [[ref: certificate authority]] (CA) would issue a [[ref: digital certificate]] to one of two [[ref: parties]]. The CA then becomes the TTP to that certificate's issuance. Likewise transactions that need a third party recordation would also need a third-party repository service of some kind.
2511
-
2512
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Trusted_third_party).
2513
-
2514
- ~ Also known as: [[ref: TTP]].
2515
-
2516
- ~ Supporting definitions:
2517
-
2518
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/trusted_third_party): A third party, such as a CA, that is trusted by its clients to perform certain services. (By contrast, the two participants in a key-establishment transaction are considered to be the first and second parties.)
2519
-
2520
- [[def: trusted timestamp authority, trusted timestamp authorities, TTA, TTAs]]
2521
- ~ An [[ref: authority]] that is trusted to provide accurate time information in the form of a [[ref: timestamp]].
2522
-
2523
- ~ Source: [NIST-CSRC](https://csrc.nist.gov/glossary/term/trusted_timestamp_authority).
2524
-
2525
- ~ Also known as: [[ref: TTA]].
2526
-
2527
- [[def: trustworthy]]
2528
- ~ A [[ref: property]] of an [[ref: entity]] that has the [[ref: attribute]] of [[ref: trustworthiness]].
2529
-
2530
- [[def: trustworthiness]]
2531
- ~ An [[ref: attribute]] of an [[ref: entity]], such as a [[ref: person]] or [[ref: organization]], that provides confidence to others of the qualifications, capabilities, and reliability of that [[ref: entity]] to perform specific tasks and fulfill assigned responsibilities. Trustworthiness is also a characteristic of information technology products and systems. The attribute of trustworthiness, whether applied to people, processes, or technologies, can be measured, at least in relative terms if not quantitatively. The determination of trustworthiness plays a key role in establishing [[ref: trust relationships]] among [[ref: persons]] and [[ref: organizations]]. The [[ref: trust relationships]] are key factors in [[ref: risk decisions]] made by senior leaders/executives.
2532
-
2533
- ~ Source: [NIST Special Publication 800-39](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-39.pdf) p.24
2534
-
2535
- [[def: TSP]]
2536
- ~ See: [[ref: ToIP Trust Spanning Protocol]].
2537
-
2538
- [[def: TTA]]
2539
- ~ See: [[ref: trusted timestamp authority]].
2540
-
2541
- [[def: TTP]]
2542
- ~ See: [[ref: trusted third party]].
2543
-
2544
- [[def: UDP]]
2545
- ~ See: [[ref: User Datagram Protocol]].
2546
-
2547
- [[def: URI]]
2548
- ~ See: [[ref: Uniform Resource Identifier]].
2549
-
2550
- [[def: Uniform Resource Identifier, Uniform Resource Identifiers, URI, URIs]]
2551
- ~ A Uniform Resource Identifier (URI) is the generic standard for all types of [[ref: identifiers]] used to link resources in the World Wide Web. The most common type of a URI is a URL ([[ref: Uniform Resource Locator]]). The URI standard is defined by [IETF RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986). URNs ([[ref: Uniform Resource Names]]) are another type of URIs intended for persistent [[ref: identifiers]].
2552
-
2553
- [[def: Uniform Resource Locator, Uniform Resource Locators, URL, URLs]]
2554
- ~ A Uniform Resource Locator (URL) is the standard form of a Web address used to link resources in browsers and other Internet applications. Technically, it is a specific type of [[ref: Uniform Resource Identifier]] (URI).
2555
-
2556
- ~ Contrast with: [[ref: Uniform Resource Name]].
2557
-
2558
- [[def: Uniform Resource Name, Uniform Resource Names, URN, URNs]]
2559
- ~ A Uniform Resource Name (URN) is a type of URI ([[ref: Uniform Resource Identifier]]) designed for persistent identifiers that are intended to be assigned once to a resource and never changed to identify a different resource. In some cases a URN is also intended to serve as a persistent way to locate the identified resource over time even as it moves locations on the network. The URN standard is defined by [IETF RFC 8141](https://datatracker.ietf.org/doc/html/rfc8141).
2560
-
2561
- ~ Contrast with: [[ref: Uniform Resource Locator]].
2562
-
2563
- [[def: URL]]
2564
- ~ See: [[ref: Uniform Resource Locator]].
2565
-
2566
- [[def: URN]]
2567
- ~ See: [[ref: Uniform Resource Name]].
2568
-
2569
- [[def: unicast]]
2570
- ~ In computer networking, unicast is a one-to-one transmission from one point in the network to another point; that is, one sender and one receiver, each identified by a [[ref: network address]] (a [[ref: unicast address]]). Unicast is in contrast to [[ref: multicast]] and [[ref: broadcast]] which are one-to-many transmissions. [[ref: Internet Protocol]] unicast delivery methods such as [[ref: Transmission Control Protocol]] (TCP) and [[ref: User Datagram Protocol]] (UDP) are typically used.
2571
-
2572
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Unicast).
2573
-
2574
- ~ See also: [[ref: anycast]].
2575
-
2576
- [[def: unicast address, unicast addresses]]
2577
- ~ A [[ref: network address]] used for a [[ref: unicast]].
2578
-
2579
- [[def: user agent, user agents]]
2580
- ~ A [[ref: software agent]] that is used directly by the end-user as the [[ref: principal]]. Browsers, email clients, and [[ref: digital wallets]] are all examples of user agents.
2581
-
2582
- ~ Supporting definitions:
2583
-
2584
- ~ [Wikipedia](https://en.wikipedia.org/wiki/User_agent): On the [Web](https://en.wikipedia.org/wiki/World_Wide_Web), a user agent is a [software agent](https://en.wikipedia.org/wiki/Software_agent) capable of and responsible for retrieving and facilitating [end user](https://en.wikipedia.org/wiki/End_user) interaction with Web content.[<sup>\[1\]</sup>](https://en.wikipedia.org/wiki/User_agent#cite_note-1) This includes all common [web browsers](https://en.wikipedia.org/wiki/Web_browser), such as [Google Chrome](https://en.wikipedia.org/wiki/Google_Chrome), [Mozilla Firefox](https://en.wikipedia.org/wiki/Mozilla_Firefox), and [Safari](https://en.wikipedia.org/wiki/Safari_\(web_browser\)), some [email clients](https://en.wikipedia.org/wiki/Email_client), standalone [download managers](https://en.wikipedia.org/wiki/Download_manager) like [youtube-dl](https://en.wikipedia.org/wiki/Youtube-dl), other [command-line](https://en.wikipedia.org/wiki/Command-line) utilities like [cURL](https://en.wikipedia.org/wiki/CURL), and arguably [headless](https://en.wikipedia.org/wiki/Headless_software) [services](https://en.wikipedia.org/wiki/Service_\(systems_architecture\)) that power part of a larger application, such as a [web crawler](https://en.wikipedia.org/wiki/Web_crawler).
2585
-
2586
- ~ The user agent plays the role of the [client](https://en.wikipedia.org/wiki/Client_\(computing\)) in a [client–server system](https://en.wikipedia.org/wiki/Client%E2%80%93server_model). The [HTTP](https://en.wikipedia.org/wiki/HTTP) [User-Agent header](https://en.wikipedia.org/wiki/User-Agent_header) is intended to clearly identify the agent to the server. However, this header can be omitted or [spoofed](https://en.wikipedia.org/wiki/User_agent_spoofing), so some websites use [other agent detection methods](https://en.wikipedia.org/wiki/Browser_sniffing).
2587
-
2588
- [[def: User Datagram Protocol]]
2589
- ~ In computer networking, the User Datagram Protocol (UDP) is one of the core [[ref: communication]] protocols of the [[ref: Internet protocol suite]] used to send [[ref: messages]] (transported as [[ref: datagrams]] in [[ref: packets]]) to other hosts on an [[ref: Internet Protocol]] (IP) network. Within an IP network, UDP does not require prior communication to set up [[ref: communication channels]] or data paths.
2590
-
2591
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/User_Datagram_Protocol).
2592
-
2593
- ~ Also known as: [[ref: UDP]].
2594
-
2595
- [[def: utility governance framework, utility governance frameworks]]
2596
- ~ A [[ref: governance framework]] for a [[ref: digital trust utility]]. A utility governance framework may be a component of or referenced by an [[ref: ecosystem governance framework]] or a [[ref: credential governance framework]].
2597
-
2598
- [[def: validation, validity]]
2599
- ~ An [[ref: action]] an [[ref: agent]] (of a [[ref: principal]]) performs to determine whether a digital object or set of [[ref: data]] meets the [[ref: requirements]] of a specific [[ref: party]].
2600
-
2601
- ~ See also: [[ref: verification]].
2602
-
2603
- ~ Supporting definitions:
2604
-
2605
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#validate): The act, by or on behalf of a [party](https://essif-lab.github.io/framework/docs/terms/party), of determining whether or not that data is valid to be used for some specific purpose(s) of that [party](https://essif-lab.github.io/framework/docs/terms/party).
2606
-
2607
- ~ [NIST](https://csrc.nist.gov/glossary/term/validation)Confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled.
2608
-
2609
- [[def: vault, vaults]]
2610
- ~ See: [[ref: digital vault]].
2611
-
2612
- [[def: VC]]
2613
- ~ See: [[ref: verifiable credential]].
2614
-
2615
- [[def: verifiable, verifiability]]
2616
- ~ In the context of digital [[ref: communications]] infrastructure, the ability to determine the [[ref: authenticity]] of a [[ref: communication]] (e.g., sender, contents, [[ref: claims]], [[ref: metadata]], provenance), or the underlying [[ref: sociotechnical]] infrastructure (e.g., [[ref: governance]], [[ref: roles]], [[ref: policies]], [[ref: authorizations]], [[ref: certifications]]).
2617
-
2618
- ~ See also:[[ref: appraisable]], [[ref: digital signature]].
2619
-
2620
- [[def: verifiable credential, verifiable credentials, VC, VCs]]
2621
- ~ A standard data model and representation format for [[ref: cryptographically-verifiable]] [[ref: digital credentials]] as defined by the [[ref: W3C Verifiable Credentials Data Model Specification]].
2622
-
2623
- ~ Source: [W3C DID](https://www.w3.org/TR/did-core/#terminology)
2624
-
2625
- ~ Also known as: [[ref: VC]].
2626
-
2627
- ~ See also: [[ref: digital credential]].
2628
-
2629
- ~ Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.w3.org/TR/vc-data-model/#roles)
2630
-
2631
- ~ Supporting definitions:
2632
-
2633
- ~ [W3C VC](https://www.w3.org/TR/vc-data-model/#terminology): A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build [verifiable presentations](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations), which can also be cryptographically verified. The [claims](https://www.w3.org/TR/vc-data-model/#dfn-claims) in a credential can be about different [subjects](https://www.w3.org/TR/vc-data-model/#dfn-subjects).
2634
-
2635
- [[def: verifiable data]]
2636
- ~ Any digital [[ref: data]] or object that is [[ref: digitally signed]] in such a manner that it can be [[ref: cryptographically verified]].
2637
-
2638
- ~ Note: In the context of ToIP architecture, verifiable data is signed with the [[ref: cryptographic keys]] associated with the [[ref: verifiable identifier]] (VID) of the data [[ref: controller]].
2639
-
2640
- [[def: verifiable data registry, verifiable data registries, VDR, VDRs]]
2641
- ~ A [[ref: registry]] that facilitates the creation, [[ref: verification]], updating, and/or deactivation of [[ref: decentralized identifiers]] and [[ref: DID documents]]. A verifiable data registry may also be used for other [[ref: cryptographically-verifiable]] data structures such as [[ref: verifiable credentials]].
2642
-
2643
- ~ Source: [W3C DID](https://www.w3.org/TR/did-core/#terminology)
2644
-
2645
- ~ Also known as: [[ref: VDR]].
2646
-
2647
- ~ See also: [[ref: authoritative source]], [[ref: trust registry]], [[ref: system of record]].
2648
-
2649
- ~ Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.w3.org/TR/vc-data-model/#roles)
2650
-
2651
- ~ For more information, see: [[ref: W3C Verifiable Credentials Data Model Specification]].
2652
-
2653
- ~ Note: There is an [earlier definition in the W3C VC 1.1. glossary](https://www.w3.org/TR/vc-data-model/#terminology) that is not as mature as this one (it is not clear about the use of cryptographically verifiable data structures). We do not recommend that definition.
2654
-
2655
- [[def: verifiable identifier, verifiable identifiers, VID, VIDs]]
2656
- ~ An [[ref: identifier]] over which the [[ref: controller]] can provide cryptographic [[ref: proof of control]]. VIDs are the [[ref: cryptographically verifiable]] identifiers used in the [[ref: ToIP stack]].
2657
-
2658
- ~ See also: [[ref: decentralized identifier]], [[ref: autonomic identifier]].
2659
-
2660
- - Also known as: [[ref:VID]]
2661
-
2662
- [[def: verifiable message, verifiable messages, verifiable messaging]]
2663
- ~ A [[ref: message]] communicated as [[ref: verifiable data]] by virtue of being [[ref: digitally signed]].
2664
-
2665
- ~ See also: [[ref: ToIP messages]]
2666
-
2667
- [[def: verification, verify, verifies, verified, verifying]]
2668
- ~ An [[ref: action]] an [[ref: agent]] (of a [[ref: principal]]) performs to determine the [[ref: authenticity]] of a [[ref: claim]] or other data object. [[ref: Cryptographic verification]] uses [[ref: cryptographic keys]].
2669
-
2670
- ~ See also: [[ref: validation]].
2671
-
2672
- ~ Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.w3.org/TR/vc-data-model/#roles)
2673
-
2674
- ~ Supporting definitions:
2675
-
2676
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#verify): The act, by or on behalf of a [party](https://essif-lab.github.io/framework/docs/terms/party), of determining whether that data is authentic (i.e. originates from the [party](https://essif-lab.github.io/framework/docs/terms/party) that authored it), timely (i.e. has not expired), and conforms to other specifications that apply to its structure.
2677
-
2678
- [[def: verifier, verifiers]]
2679
- ~ A [[ref: role]] an [[ref: agent]] performs to perform [[ref: verification]] of one or more [[ref: proofs]] of the [[ref: claims]] in a [[ref: digital credential]] or other [[ref: verifiable data]].
2680
-
2681
- ~ See also: [[ref: relying party]]; [[ref: issuer]], [[ref: holder]].
2682
-
2683
- ~ Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.w3.org/TR/vc-data-model/#roles)
2684
-
2685
- ~ Supporting definitions:
2686
-
2687
- ~ [W3C VC](https://www.w3.org/TR/vc-data-model/#terminology): A role an [entity](https://www.w3.org/TR/vc-data-model/#dfn-entities) performs by receiving one or more [verifiable credentials](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials), optionally inside a [verifiable presentation](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations) for processing. Other specifications might refer to this concept as a [[ref: relying party]].
2688
-
2689
- ~ [eSSIF-Lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#verifier): a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to request [peer agents](https://essif-lab.github.io/framework/docs/terms/peer-agent) to present (provide) data from credentials (of a specified kind, issued by specified [parties](https://essif-lab.github.io/framework/docs/terms/party)), and to verify such responses (check structure, signatures, dates), according to its [principal](https://essif-lab.github.io/framework/docs/terms/principal)'s [verifier policy](https://essif-lab.github.io/framework/docs/terms/verifier-policy).
2690
-
2691
- ~ [NIST](https://csrc.nist.gov/glossary/term/verifier) The entity that verifies the authenticity of a digital signature using the public key.
2692
-
2693
- [[def: VID]]
2694
- ~ See [[ref: ​​verifiable identifier]].
2695
-
2696
- [[def: VID relationship, VID relationships]]
2697
- ~ The [[ref: communications]] relationship formed between two [[ref: VIDs]] using the [[ref: ToIP Trust Spanning Protocol]]. A particular feature of this protocol is its ability to establish as many VID relationships as needed to establish different [[ref: relationship contexts]] between the communicating [[ref: entities]].
2698
-
2699
- [[def: VID-to-VID, V2V]]
2700
- ~ The specialized type of [[ref: peer-to-peer]] [[ref: communications]] enabled by the [[ref: ToIP Trust Spanning Protocol]]. Each pair of VIDs creates a unique [[ref: VID relationship]].
2701
-
2702
- [[def: virtual vault, virtual vaults]]
2703
- ~ A [[ref: digital vault]] enclosed inside another [[ref: digital vault]] by virtue of having its own [[ref: verifiable identifier]] (VID) and its own set of [[ref: encryption]] [[ref: keys]] that are separate from those used to unlock the enclosing vault.
2704
-
2705
- [[def: Voice over IP, VoIP]]
2706
- ~ Voice over Internet Protocol (VoIP), also called IP telephony, is a method and group of technologies for voice calls for the delivery of voice [[ref: communication]] sessions over [[ref: Internet Protocol]] (IP) networks, such as the Internet.
2707
-
2708
- ~ Also known as: [[ref: VoIP]].
2709
-
2710
- [[def: VoIP]]
2711
- ~ See: [[ref: Voice over IP]].
2712
-
2713
- [[def: W3C Verifiable Credentials Data Model Specification]]
2714
- ~ A W3C Recommendation defining a standard data model and representation format for [[ref: cryptographically-verifiable]] [[ref: digital credentials]]. Version 1.1 was published on 03 March 2022.
2715
-
2716
- ~ For more information, see: <https://www.w3.org/TR/vc-data-model/>
2717
-
2718
- [[def: wallet, wallets]]
2719
- ~ See: [[ref: digital wallet]].
2720
-
2721
- [[def: wallet engine, wallet engines]]
2722
- ~ The set of software components that form the core of a [[ref: digital wallet]], but which by themselves are not sufficient to deliver a fully functional wallet for use by a [[ref: digital agent]] (of a [[ref: principal]]). A wallet engine is to a [[ref: digital wallet]] what a [browser engine](https://en.wikipedia.org/wiki/Browser_engine) is to a web browser.
2723
-
2724
- ~ For more information: The charter of the [[ref: OpenWallet Foundation]] is to produce an open source [[ref: digital wallet]] engine.
2725
-
2726
- [[def: witness, witnesses]]
2727
- ~ A computer system that receives, [[ref: verifies]], and stores [[ref: proofs]] of [[ref: key events]] for a [[ref: verifiable identifier]] (especially an [[ref: autonomic identifier]]). Each witness controls its own [[ref: verifiable identifier]] used to sign [[ref: key event]] [[ref: messages]] stored by the witness. A witness may use any suitable computer system or database architecture, including a file, centralized database, distributed database, [[ref: distributed ledger]], or [[ref: blockchain]].
2728
-
2729
- ~ Note: [[ref: KERI]] is an example of a [[ref: key management system]] that uses witnesses.
2730
-
2731
- [[def: zero-knowledge proof, zero-knowledge proofs, ZKP, ZKPs]]
2732
- ~ A specific kind of cryptographic [[ref: proof]] that proves facts about [[ref: data]] to a [[ref: verifier]] without revealing the underlying [[ref: data]] itself. A common example is proving that a person is over or under a specific age without revealing the person’s exact birthdate.
2733
-
2734
- ~ Also known as: zero-knowledge protocol, [[ref: ZKP]].
2735
-
2736
- ~ Supporting definitions:
2737
-
2738
- ~ [Ethereum:](https://ethereum.org/en/zero-knowledge-proofs/) A zero-knowledge proof is a way of proving the validity of a statement without revealing the statement itself.
2739
-
2740
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Zero-knowledge_proof): a method by which one [[ref: party]] (the prover) can prove to another party (the verifier) that a given statement is true, while avoiding conveying to the [[ref: verifier]] any information beyond the mere fact of the statement's truth.
2741
-
2742
- [[def: zero-knowledge service, zero-knowledge services]]
2743
- ~ In cloud computing, the term “zero-knowledge” refers to an online service that stores, transfers or manipulates [[ref: data]] in a way that maintains a high level of [[ref: confidentiality]], where the data is only accessible to the [[ref: data]]'s [[ref: owner]] (the client), and not to the service provider. This is achieved by [[ref: encrypting]] the raw data at the client's side or end-to-end (in case there is more than one client), without disclosing the password to the service provider. This means that neither the service provider, nor any [[ref: third party]] that might intercept the [[ref: data]], can [[ref: decrypt]] and access the [[ref: data]] without prior permission, allowing the client a higher degree of privacy than would otherwise be possible. In addition, zero-knowledge services often strive to hold as little [[ref: metadata]] as possible, holding only that [[ref: data]] that is functionally needed by the service.
2744
-
2745
- ~ Source: [Wikipedia](https://en.wikipedia.org/wiki/Zero-knowledge_service).
2746
-
2747
- ~ Also known as: no knowledge, zero access.
2748
-
2749
- [[def: zero-knowledge service provider, zero-knowledge service providers]]
2750
- ~ The provider of a [[ref: zero-knowledge service]] that hosts [[ref: encrypted]] [[ref: data]] on behalf of the [[ref: principal]] but does not have access to the [[ref: private keys]] in order to be able to [[ref: decrypt]] it.
2751
-
2752
- [[def: zero-trust architecture, zero-trust architectures, ZTA, ZTAs]]
2753
- ~ A network security architecture based on the core design principle “never trust, always verify”, so that all [[ref: actors]] are denied access to resources pending [[ref: verification]].
2754
-
2755
- ~ Also known as: perimeterless security, zero-trust security, [[ref: ZTA]].
2756
-
2757
- ~ Contrast with: [[ref: attribute-based access control]], [[ref: role-based access control]].
2758
-
2759
- ~ Supporting definitions:
2760
-
2761
- ~ [NIST-CSRC](https://csrc.nist.gov/glossary/term/zero_trust_architecture): A security model, a set of system design principles, and a coordinated cybersecurity and system management strategy based on an acknowledgement that threats exist both inside and outside traditional network boundaries. The zero trust security model eliminates implicit trust in any one element, component, node, or service and instead requires continuous verification of the operational picture via real-time information from multiple sources to determine access and other system responses.
2762
-
2763
- ~ [Wikipedia](https://en.wikipedia.org/wiki/Zero_trust_security_model): The zero trust security model, also known as zero trust architecture (ZTA), and sometimes known as perimeterless security, describes an approach to the strategy, design and implementation of [IT systems](https://en.wikipedia.org/wiki/IT_system). The main concept behind the zero trust security model is "never trust, always verify," which means that users and devices should not be trusted by default, even if they are connected to a permissioned network such as a corporate [LAN](https://en.wikipedia.org/wiki/Local_area_network) and even if they were previously verified.
2764
-
2765
- [[def: ZKP]]
2766
- ~ See: [[ref: zero-knowledge proof]].