Statement (Single phrase or sentence)

Verifiers shall identify themselves to the Holder with enough detail in the context of the transaction to help the Holder to make a decision to proceed with the transaction.

Description

In order for the Holder to proceed with a transaction, the first step is that the Verifiers should identify themselves in context. A context might be admission to a stadium. Another context might be a medical office. The Holder can verify that they are in the stadium or the doctor’s office themselves and the Holder Agent should be able to validate that.

Scope (applies to)

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

Select the Primary Consideration

• 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)

Reference

4_A_AC

Other considerations

• 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)

Select the Identifiers

• Direct
• Indirect
• Unique

Related Requirements

Explanatory Notes (Text or Link)

• Tom Jones to add some details about what context means
  

One in person context might be an office where the ….

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.

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

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 was raised about authoring and levels of assurance (do we use shall,

• The root of trust for the verifier should be at least as authoritative as the root of trust for the credential presented

To be continued