Difference between revisions of "Verifier"

From MgmtWiki
Jump to: navigation, search
(Full Title or Meme)
Line 1: Line 1:
==Full Title or Meme==  
==Full Title or Meme==  
In this wiki the common therm for a [[Verifier]] is a [[Relying Party]]. The distinction seems to be moot.
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]].

Revision as of 05:50, 2 June 2022

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.


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


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


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.


Proposed list of requirements on a Verifier.

  1. The Verifier will be clear what purpose is being served on behalf of the Relying Party and who the Relying Party is.

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

  1. Holder = a real-world entity that has a collection of centennials in a digital format contained in a digital wallet.
  2. 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.
  3. PEP = policy enforcement point accepts sources of attributes and assures that they presenter is the holder.



  1. MITRE https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/test-and-evaluation/verification-and-validation