Machine Readable Governance - Revision history

Tom: /* Reference */

2024-09-01T18:13:09Z

‎Reference

Tom: /* Reference */

2024-09-01T18:11:07Z

‎Reference

Tom: /* Reference */

2023-08-03T17:40:11Z

‎Reference

Tom: /* Context */

2022-05-22T16:26:18Z

‎Context

Tom: /* Reference */

2022-03-28T20:27:34Z

‎Reference

Tom: /* Commentary */

2022-03-25T18:22:03Z

‎Commentary

Tom at 23:29, 24 March 2022

2022-03-24T23:29:24Z

Tom: /* Commentary */

2022-03-24T23:25:51Z

‎Commentary

Tom: /* Commentary */

2022-03-24T23:23:21Z

‎Commentary

Tom: /* Commentary */

2022-03-24T23:20:11Z

‎Commentary

@@ Line 470: / Line 470: @@
 ==Reference==
 * See wiki page [[Policy-Based Access Control]].
-* See the wiki page on [[Digital Governance]].
+* See the wiki page on [[Governance Framework]].
 [[Category: Authorization]]
 [[Category: Regulation]]
 [[Category: Governance]]

@@ Line 470: / Line 470: @@
 ==Reference==
 * See wiki page [[Policy-Based Access Control]].
 [[Category: Authorization]]
 [[Category: Regulation]]
 [[Category: Governance]]

← Older revision		Revision as of 17:40, 3 August 2023
Line 473:		Line 473:
	[[Category: Authorization]]		[[Category: Authorization]]
	[[Category: Regulation]]		[[Category: Regulation]]
		+	[[Category: Governance]]

@@ Line 3: / Line 3: @@
 ==Context==
-This output was provided by the Cardea project early in their development process and is no where near the final format.
+* For more information on the general topic see the wiki page on [[Digital Governance]].
 ==Current Draft==

← Older revision		Revision as of 20:27, 28 March 2022
Line 471:		Line 471:

	[[Category: Authorization]]		[[Category: Authorization]]
		+	[[Category: Regulation]]

@@ Line 451: / Line 451: @@
 </pre>
 ==Commentary==
 # While it is clear that this document will be changed often during an infection, even daily, it is not clear how to tell what is valid at any pariticular time. F or example could the traveller be assure that the policy in force at the time of departure would be applied at the time of debarkation? See the user journey of a [https://kantarainitiative.org/confluence/display/PEMCP/Credential+Policy+Coordination Credential Policy Coordination] for details.

@@ Line 455: / Line 455: @@
 # "schemas" These appear to be the document formats for credentials. Not clear that a country of the size of this document could ever keep up the the potential formats. It seems that a "trust framework" is required to establish the scope of schemas to be accepted by immigration officials.
 # "participants" It seems like there are the relying parties, or the sites that actually grant (or deny) access. A common taxonomy of venues would be good, but perhaps might (in the US) even be state specific.
-# "permissions"
+# "permissions" It seems like this is a collection of issuers and verifiers. At first glance that is troubling, but I can see some relying parties issuing their own "tickets" for entry.  I personally believe we need to break the relying party / verifier into separate sections as show in other use case; namely: the policy definition point that sets the policy for each site and the policy execution point that accepts the tickets and acts on them.
 # "actions" This is the largest section and appears to written an a UX program that tells the immegration officials what questions to ask and what answers to expect. In some cases the request is to the user wallet and the evaluation of the values returned.  These values are actually dependent on the country where the certificates were issued so the result is likely to be uneven.  Here is the place where some sort of rules engine would be most useful. It is unlike that most countries would be in a position to create such a rules engine, so the source would like be established on a continental bases. It is presumed that the only action available is is to grant or deny access to the country.
 # "others"