Verifiers must identify themselves (should?) to the user with enough detail to provide confidence in the transaction.

Verifiers should provide levels of assurance about their identity depending on the operational context.

Verifiers must share a form of identification (e.g. certificate) with a provider during a presentation so that a user can reliably identify the requesting party. The form of identification should be unique to the verifier and challenging to fake, such that the provider should have high confidence in the identity of the verifier.

Tom Jones reminds us that provider is an inappropriate term and that we had talked about using 'platform'

Level of Assurance for Vefifier needed: PeterD (Deactivated)

Do we need any suggestions? Christopher Williams i.e. leave the specification generic

Discussion:

• Since this is a physical presence-only presentation can this be assumed?
• Need to worry about skimmer in BOPIS (Buy Online, Pick Up in Store) Detecting terminal tampering
• We need to be specific enough to provide reasonable real-world assurance
• The intent is that the verifier should identify themselves in a reasonable way. this is not covered in 18013-5 (method of passing certificate to mdoc and how the mdoc behaves is contingent)
• Should be a matching requirement for Providers where the Device communicates to the User
• Operational context may provide the required level of assurance
• From an issuing authority perspective, it's important to be able to log who the data went to - hence the holder needs a technical reference for logging
• Issuers that provision credentials to a solution do not want another provider intervening
• We should be setting a higher bar than a 'flash pass'.
• Depending on the operational context the platform may require different levels of authentication from the verifier.
• At some prior point, the verifier should have provided some qualification to enter into the transactions
• At some point the verifier and ath
• Suggests matching requirements for logging and identity assurance on the platform side?
• A question raised about authoring and levels of assurance (do we use shall,

To be continued

• Part A: Verifiers
• Part B: Issuers
• Part C: Providers

• CC (Consent and Choice)
  
• PL (Purpose legitimacy and specification)
  
• CL (Collection limitation)
  
• DM (Data minimization)
  
• UR (Use, retention, and disclosure limitation)
  
• AQ (Accuracy and quality)
  
• OT (Openness, transparency, and access)
  
• IA (Individual access & participation)
  
• AC (Accountability)
  
• IS (Information Security)
  
• PS (Privacy compliance)
  

• CC (Consent and Choice)
  
• PL (Purpose legitimacy and specification)
  
• CL (Collection limitation)
  
• DM (Data minimization)
  
• UR (Use, retention, and disclosure limitation)
  
• AQ (Accuracy and quality)
  
• OT (Openness, transparency, and access)
  
• IA (Individual access & participation)
  
• AC (Accountability)
  
• IS (Information Security)
  
• PS (Privacy compliance)

• Direct
• Indirect
• Unique

Purpose legitimacy and specification

Collection limitation

Data minimization

Use, retention, and disclosure limitation

Accuracy and quality

Openness, transparency, and access

Individual access & participation

Accountability

Information Security

Privacy compliance