Best Practice and Example Trust Registry - Revision history

Tom: /* Model of the User in the Database */

2022-10-12T16:36:40Z

‎Model of the User in the Database

Tom: /* Model of the User in the Database */

2020-08-11T19:58:31Z

‎Model of the User in the Database

Tom: /* Registry Server Build and Deploy */

2020-08-09T19:19:34Z

‎Registry Server Build and Deploy

Tom: /* Trust Registry Build and Deploy */

2020-08-01T16:44:09Z

‎Trust Registry Build and Deploy

Tom: /* Trust Registry Build and Deploy */

2020-08-01T16:42:15Z

‎Trust Registry Build and Deploy

Tom: /* Trust Registry Build and Deploy */

2020-08-01T16:41:51Z

‎Trust Registry Build and Deploy

Tom: /* Protection of Keys */

2020-08-01T05:19:18Z

‎Protection of Keys

Tom: /* Next steps */

2020-07-05T21:56:20Z

‎Next steps

Tom: /* Trust Registry Build and Deploy */

2020-07-05T18:18:42Z

‎Trust Registry Build and Deploy

Tom: /* Trust Registry Build and Deploy */

2020-07-05T18:17:37Z

‎Trust Registry Build and Deploy

@@ Line 62: / Line 62: @@
 For more information see this page on [[User Private Information]].
 ====Model of the User in the Database====
-The goal of the data collected (as a [[User Object]]) about the individual and organizational users is to model the [[User]]s that are served by the web site with [[User Private Information]] intended for release by the users. Field names taken from other standards, like Open ID Connect, are highlighted in blue. This is a practice where the RP can determine the category tag used on each data field in advance based on the needs of the site. It may be necessary for the RP get user consent which requires that some fields are dynamically tagged based on user intent or user actions. In those cases are more complex design might be required. For example a deletion date may need to be associated with some fields.
+The goal of the data collected (as a [[User Object]]) about the individual and organizational users is to model the [[User]]s that are served by the web site with [[User Private Information]] intended for release by the users. Field names taken from other standards, like Open ID Connect, are highlighted in blue. This is a practice where the RP can determine the category tag used on each data field in advance based on the needs of the site. It may be necessary for the RP get user consent which requires that some fields are dynamically tagged based on user intent or user actions. In those cases a more complex design might be required. For example a deletion date may need to be associated with some fields.
 {|border="1" padding="2" width="799px"

@@ Line 73: / Line 73: @@
 |Type || numeric || 1 || (1)individual, (2)organization (can be a parent), (3) pseudonym (avoid any linkage)
 |-
-|Parent || link (exactly one) || 2 || link to an organization in this db, the default parent is the Kantara root entry
+|Parent || link (exactly one) || 2 || link to an organization in this db, the default parent is the federation root entry
 |-
 | Member || code || 1 || 0=none, 1= member in good standing, 2=candidate for membership, 3=suspended or resigned

@@ Line 193: / Line 193: @@
 ===Registry Server Build and Deploy===
 This is the API process designed to run under Kestrel so that it can support HTTP/2 access to the Simple Service.
 In this example the date should be the current date.

@@ Line 174: / Line 174: @@
 This is the front end process designed to run under IIS.
 * Windows Registry settings to enable a windows event log for this application
-* Note that these are in the local machine branch and so must be run the admin creds.
+* Note that these are in the local machine branch and so must be run with admin creds.
   C:\certs> reg import .\trustregistry.reg
   or

@@ Line 174: / Line 174: @@
 This is the front end process designed to run under IIS.
 * Windows Registry settings to enable a windows event log for this application
-* Note that these are in the local machine branch as so must be run the admin creds.
+* Note that these are in the local machine branch and so must be run the admin creds.
   C:\certs> reg import .\trustregistry.reg
   or

← Older revision		Revision as of 05:19, 1 August 2020
Line 136:		Line 136:

	Best Practice for micro-services in internal, hardware protection of keys and self-signed certs that are included in the cert:\localmachine\root storage locations.		Best Practice for micro-services in internal, hardware protection of keys and self-signed certs that are included in the cert:\localmachine\root storage locations.
		+	* [https://docs.microsoft.com/en-us/windows/win32/seccng/key-storage-and-retrieval CNG Key Storage and Retrieval] in Windows.

	===Discovery Endpoint===		===Discovery Endpoint===

@@ Line 162: / Line 162: @@
 -a----       2020-06-07   4:53 PM            288 SimpleService.runtimeconfig.json
-PS C:\Users\rp_to_000\Documents\TopCat\Repos\TrustRegistry3\RegistryServer\bin\Debug\netcoreapp3.1> copy C:\Users\rp_to_000\Documents\TopCa
+PS C:\Users\rp_to_000\Documents\TopCat\Repos\TrustRegistry3\RegistryServer\bin\Debug\netcoreapp3.1> copy C:\Users\rp_to_000\Documents\TopCat\Repos\TrustRegistry3\SimpleService\bin\Debug\netcoreapp3.1\sim*config*.json .
 PS C:\Users\rp_to_000\Documents\TopCat\Repos\TrustRegistry3\RegistryServer\bin\Debug\netcoreapp3.1> .\SimpleService.exe
 Hosting environment: Development

@@ Line 177: / Line 177: @@
   or
   C:\certs> regedit /s .\trustregistry.reg
-Where the following in the that file:
+Where the following content is in that file:
 <pre>
 Windows Registry Editor Version 5.00

@@ Line 175: / Line 175: @@
 *Windows Registry settings to enable a windows event log for this application
   C:\certs> reg import .\trustregistry.reg
 <pre>
 Windows Registry Editor Version 5.00
@@ Line 186: / Line 189: @@
 ,73,00,61,00,67,00,65,00,73,00,2e,00,64,00,6c,00,6c,00,00,00
 </pre>
 ===Registry Server Build and Deploy===