Difference between revisions of "Verifier"

Latest revision as of 09:07, 3 June 2025

Full Title or Meme

In this wiki the common term for a Verifier is a Relying Party. The distinction made here is that the Verifier is a collection of roles, while the Relying Party, the Data Controller and the Data Processor are real-world objects, that is, each is a named Entity.

What may be confusing is that some standards in the IETF (like RFC 9334) use the term Verifier for an Entity that is a remote service provider distinct from the Relying Party.

Context

• Verification of identity is typically requited for a grant of access to a physical location or grant of privilege, for example to fish or to drive on public roads.
• Context is situational and dependent on the use case. The particular access requirements will determine whether any identity presentation is sufficient to grant access.
• This particular page is focused on entities called holders that have a collection of credentials that bind attributes to them and assures that the entity presenting them is the holder.
• The traditional name for an entity that needs validated data is a Relying Party. A Verifier may be a Relying Party or only a process that performs a function for one.
• For the purposes of the GDPR the Relying Party may be considered to be the Data Controller.
• Verification is the process for determining whether or not an applicant fulfills the requirements or specifications established - a definition derived from the MITRE Systems Engineering Guide.^[1]
• Functionality is an active feature of an Identification process. Some functionality, like Proof of Presence can reside in a variety of entities depending on the use case.

Problems

• The term Verifier could be limited to just the role played by any Entity in assuring that the data received meets its own criteria for acceptance.
• Some verticals, like finance and health, are highly regulated and typically require that their data controllers are certified for conformance with very restrictive regulations. Others have lighter regulation like the US Federal Trade commission.
• In all cases the verifier will be given a set of policies that they apply to Claimants seeking access. In a world where policies can change will little notice, it behooves the Verifier to create a Policy-Based Access Control applications that does not require reprogramming of the application to meet changing policies.

Privacy

The protection of release of holder attributes or behaviors is called Privacy in this page.

• The purpose for which holder data attributes are required
• The behaviors of the holder with the Relying Party that are retained by the Relying Party shall be explained to the holder.

Data Hoarders

These are Enterprises that collect vast amount of people's data as a part of their very existence. Many of them have proven to have very poor security.

• Lexus/Nexus
• Credit Agencies
• Internal Government security Agencies, like the US DHS in "The DHS Bought a ‘Shocking Amount’ of Phone-Tracking Data"^[2]

  FOR YEARS, PEOPLE have wondered not if, but how much, the Department of Homeland Security accesses mobile location data to monitor US citizens. The week of 2022-07-28, the American Civil Liberties Union released thousands of heavily redacted pages of documents that provide a “glimpse” of how DHS agencies came to leverage “a shocking amount” of location data, apparently purchasing data without following proper protocols to ensure they had the authority to do so.

Payment

There is some discussion about whether the Verifier should pay for every verification. Since the Verifier also has to pay for the equipment that is needed, this might be a killer requirement.

• 2025-05 Comments in favor of Verifier Pays

One of the biggest concerns from organizations when it comes to issuing digital ID credentials is this: "What's stopping someone else, even our competitors, from verifying the credentials we issue without paying for them?"

This is what's known as the freeloader problem, and at Dock Labs, we're proud to say we've solved it. With our platform, organizations can issue and manage digital credentials with the confidence that unauthorized third parties won't exploit their work and data. Here's how it works:

• Credential verification can be restricted to authorized ecosystem members, meaning only approved companies (typically the issuer's clients or partners) can verify the credentials.
• Membership is controlled by ecosystem administrators, who decide who gets access and under what conditions.
• Credential issuers can choose to charge for each verification, creating a clear path for monetization.

In other words, if you want, credential verification can be gated by ecosystem membership and rules that you define. This ecosystem approach offers a powerful safeguard: anyone trying to verify a credential must first prove they're part of the ecosystem.

Without that access, they can't even tell whether a credential is valid or not.

And to be clear: this approach doesn't replace open standards; it builds on them. Our platform fully supports interoperable, standards-based credentials. What we've added is a way for issuers to protect their work and create a sustainable revenue model around credential verification.

Solutions

See the wiki page Verifier Management for one way to determine how the User and Verifier could negotiate a relationship. Proposed list of requirements on a Verifier.

1. The Verifier SHALL be clear what purpose is being served on behalf of the Relying Party and who the Relying Party is.
2. The purpose SHALL have a standardized list of attributes, behaviors and functionality that is appropriate to the context.
3. The request for presentation of proofs SHALL indicate the Data Controller and any Data Processor that sees user private data.
4. Proof of Presence is typically required in Identity Verification. The original Driver's License Card enabled this function by virtue of a facial image with complex card physical indications. This function may be provided by manual or automated image validation for mobile identity credential verification.
5. The Wallet is an application that runs on the holder's smart phone. It is responsible for keeping the user data secure.
6. The wallet may be the named originator of signed statements about the security of the data or the identity of the holder. This is required for automated high assurance Proof of Presence.

Real-world Entities:

1. Holder = a real-world entity that has a collection of centennials in a digital format contained in a digital wallet.
2. Data Controller = a real-world entity that has the purpose for collecting data from the holder.
3. Data Processor = a real-world entity that is in any part of the data flow and acts on behalf of the Data Controller.

CA mDL Veifiers

• OPENCRED FOR RELYING PARTIES
• mDL for Technology Developers

For this wiki we break the Verifier into two roles from SAML:

1. PDP = policy definition point may act as a Credential Aggregation process that accepts a collection of sources and produces a ticket for the holder that still needs to be bound to the person presenting the ticket.
2. PEP = policy enforcement point accepts sources of attributes and assures that they presenter is the holder. In some implementations the PEP can be installed in a native app on the client-side device.

Amazon

2025-05 Dock Labs recently had Paul Grassi (Principal Product Manager for Identity Services at Amazon) in our podcast and he mentioned that the ecommerce giant wants to move from verification to acceptance.

Traditionally, Amazon handled all the heavy lifting: scanning physical documents, running credit checks, and matching selfies to confirm a user’s identity. While effective, those steps create extra friction for customers and risk collecting more data than necessary.

Now, Amazon aims to accept digital ID credentials that have already been verified by trusted issuers (like state governments). Here’s why it’s a game-changer:

> Less Friction for Users: Fewer hurdles during sign-up or checkout, speeding up the purchase of restricted goods (e.g., alcohol or other age-gated items). No more scanning or uploading physical documents. Users simply tap to confirm their identity.

> Improved Privacy: Some Digital ID credentials allow for the use of selective disclosure and zero-knowledge proofs. Prove “Yes, I’m over 21” without handing over your full name and birth-date.

> A Push Towards Broader Industry Adoption: Large-scale acceptance accelerates adoption. Other companies, states, and issuers may follow suit when they see a global retailer leading the charge.

A key part of Amazon’s plan involves integrating mobile driver’s licenses (mDLs), digital versions of your standard license stored on a smartphone. Several states have already issued mDLs, while others are in various stages of testing or legislation. Despite the fragmented rollout, Amazon sees itself as a perfect fit for the acceptance model.

If Amazon successfully streamlines these technologies, it could reshape how we prove who we are for countless transactions.

References

1. ↑ MITRE https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/test-and-evaluation/verification-and-validation
2. ↑ Ashley Belanger, The DHS Bought a ‘Shocking Amount’ of Phone-Tracking Data Wired (2022-07-28) https://www.wired.com/story/dhs-surveillance-phone-tracking-data/