Changes

no edit summary
Line 40: Line 40:  
1. Emails
 
1. Emails
   −
[[File:Email_sign1.PNG]]
+
[[File:Email_sign1.PNG|center]]
    
Above example is when sending the email. Note the use of /s/ to show intent to sign, though this may or may not be necessary and we are not implying that it is required in a signed email.
 
Above example is when sending the email. Note the use of /s/ to show intent to sign, though this may or may not be necessary and we are not implying that it is required in a signed email.
   −
[[File:Email_sign2.PNG]]
+
[[File:Email_sign2.PNG|center]]
    
Above shows the Inbox of the recipient including a red icon to indicate digital signature.
 
Above shows the Inbox of the recipient including a red icon to indicate digital signature.
   −
[[File:Email_sign3.PNG]]
+
[[File:Email_sign3.PNG|center]]
    
Above is as the email will appear to the recipient when opened.
 
Above is as the email will appear to the recipient when opened.
Line 54: Line 54:  
2. PDF documents
 
2. PDF documents
   −
[[File:Pdf_sign1.PNG]]
+
[[Image:Pdf_sign1.PNG|center]]
    
3. Microsoft Word documents
 
3. Microsoft Word documents
   −
[[File:Word_sign1.PNG]]
+
[[File:Word_sign1.PNG|center]]
    
We won’t go into detail here about how to set these up, as each technology choice could be a blog post on its own, but there are pros and cons to each of the choices that would have to be weighed by the business owner for the specific situation. The major takeaway is that each of these options can be used today by GC officials needing to sign documents as well as those verifying the signatures. Note that this latter step of verifying signatures is not always performed with physical, ink signatures, so the digital replacement using PKI has additional benefits. GC PKI credentials using soft tokens (epf files), which is the majority of such credentials within the GC, achieve an LoA 2. See [https://www.cse-cst.gc.ca/en/node/2454/html/28582 CSE ITSP.30.031 V3] for more details. GC PKI credentials using hard tokens and a rigorous identity-proofing process may achieve LoA 3 or even 4, if implemented in accordance with the level 4 requirements identified in the e-signature guidance document. In addition, GC PKI credentials come with strong LoA 2 identity-proofing baked in at a minimum (higher for many).
 
We won’t go into detail here about how to set these up, as each technology choice could be a blog post on its own, but there are pros and cons to each of the choices that would have to be weighed by the business owner for the specific situation. The major takeaway is that each of these options can be used today by GC officials needing to sign documents as well as those verifying the signatures. Note that this latter step of verifying signatures is not always performed with physical, ink signatures, so the digital replacement using PKI has additional benefits. GC PKI credentials using soft tokens (epf files), which is the majority of such credentials within the GC, achieve an LoA 2. See [https://www.cse-cst.gc.ca/en/node/2454/html/28582 CSE ITSP.30.031 V3] for more details. GC PKI credentials using hard tokens and a rigorous identity-proofing process may achieve LoA 3 or even 4, if implemented in accordance with the level 4 requirements identified in the e-signature guidance document. In addition, GC PKI credentials come with strong LoA 2 identity-proofing baked in at a minimum (higher for many).
Line 65: Line 65:  
If the user can log in to an account using an LoA 2 authentication, a straightforward option is to have the user log in and “click to sign”. There should be well-described consequences of the signing action so that the user is aware that she is performing a signing action. This option is already in wide use. An example from the GC is the e-signatures applied by both manager and employee as part of the Performance Management process.
 
If the user can log in to an account using an LoA 2 authentication, a straightforward option is to have the user log in and “click to sign”. There should be well-described consequences of the signing action so that the user is aware that she is performing a signing action. This option is already in wide use. An example from the GC is the e-signatures applied by both manager and employee as part of the Performance Management process.
   −
[[File:PSPM sign3.png]]
+
[[Image:PSPM sign3.png|center]]
    
=== Outside the GC - PKI-based E-Signature Solutions ===
 
=== Outside the GC - PKI-based E-Signature Solutions ===
Line 75: Line 75:  
As above, if the external user can log in to an account using an LoA 2 authentication, a simple approach is to have the user log in and “click to sign”. The CRA process for adding a child for child benefits within [https://www.canada.ca/en/revenue-agency/services/e-services/e-services-individuals/account-individuals.html My Account for Individuals] is an example of an e-signature where a user outside the GC is associated with an account. In these cases, the LoA of the e-signature is largely determined by the LoA of the authentication process used for logging in to the account. This is an example of LoA 2 because the credentials used to log in to those accounts are LoA 2. You can find more details on this in the e-signature guidance.
 
As above, if the external user can log in to an account using an LoA 2 authentication, a simple approach is to have the user log in and “click to sign”. The CRA process for adding a child for child benefits within [https://www.canada.ca/en/revenue-agency/services/e-services/e-services-individuals/account-individuals.html My Account for Individuals] is an example of an e-signature where a user outside the GC is associated with an account. In these cases, the LoA of the e-signature is largely determined by the LoA of the authentication process used for logging in to the account. This is an example of LoA 2 because the credentials used to log in to those accounts are LoA 2. You can find more details on this in the e-signature guidance.
   −
[[File:CRA_signature_example.png]]
+
[[File:CRA_signature_example.png|center]]
    
== Level of Assurance (LoA) 3: ==
 
== Level of Assurance (LoA) 3: ==