Skip to content

IN GROUPE - Playground

Introduction

Overview

The IN GROUPE Playground is developed and designed to a relying party verification request.

The simulator allows developers and testers to configure, execute, and analyze various use cases and scenarios of verification.

By simulating real-world interactions, the RP Simulator helps identify potential compatibility issues early in the development process. Supporting a wide range of test cases and implementing various setting options, the simulator enables efficient and thorough testing of digital wallet implementations. This helps accelerate deployment and enhances the user experience across the EUDI ecosystem.

Playground can be used also by credential issuer, to check issued VC validity and compatibility.

Supported standards

IN GROUPE playground supports the latest version of Openid4Vp V1.0.

It offers many key features like:

  • DCQL querying
  • Support of Direct and Direct Jwt response mode
  • Support both Sd-Jwt and Mso-Mdoc formats
  • Include Keys by reference or as JSON Web Key Set : RFC7591
  • Verification request as JWT-Secured Authorization Request : RFC 9101
  • Encrypted response as JWE : RFC7518
  • Verifying Issuer authenticity against Verified Issuer Certificate Authority List (VICAL)
  • Verifying Credential state against status list : W3C Bitstring Status List
  • Support technical profils : iso-18013-7 and age-verification
  • Support both flows : same device et cross device

Getting Started

Accessing the simulator

To access the simulator, you can use the following link: https://rp-playground-ingroupe.utoconnect.com/

The access is public and no need for authentication.

The playground contains four main menu :

  1. Presentation request : to create VP request and start verification test
  2. Setting : Configure the playground setting
  3. Vical : view and manage Vical
  4. History : view the history of verification test

Presentation Request

Create a simple VP Request

To create a new verification request, first we choose one or more attestations from the list as bellow:

Once Credentials choosed, we can add or remove attributs from the verification request as bellow.

Attributes marked as mandatory on the corresponding attestation rulebook are selected by default.

We can also change the format of the credential if it supports more than one format.

Advanced DCQL querying

In the openid4vp specification, DCQL querying allow dynamic and flexible verification request as described:

https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-digital-credentials-query-l

Among the key feature of dcql are:

  • Possibility to define complex path to access desired attribute
  • Possibility to define value to limit the search
  • Possibility to describe alternative ways a given Credential can satisfy the request amon claims set

IN GROUPE playground support these three features, with simple and user friendly way.

DCQL Path

To add path value to a selected attribute, we follow steps bellow:

In this example the verifier asks for all “vehicule_category_code” of the citizen driving privileges

DCQL Value

To add a value to a selected attribute, we follow steps bellow:

In this example the verifier asks for the citizen nationaly if only it equals to “FR”

When a value or path are added to an attribute, a visual indicator allow to distinguish them:

DCQL Claims Set

Claims Set allow verifier to specifies which combinations of claims for the Credential are requested, the array ordering expresses the Verifier's preference for how to fulfil the request.

Claims Set is composed of already selected attributes.

To configure a Claims Set we can follow step below:

We can repeat the operation to add Claims Set as needed.

As a resut we will have a list of Cliams Set ordered to express the priority defined by the verifier.

We can remove a Claims Set and also re-order them by clicking on a line and move it (Drag and Drop).

In the sample above, verifier needs to know if citizen has more than 21 years old, so he asks in addition of the family and given name, for age_over_21 attribute in priority 1, then if it missing he asks for “age in years” and so on.

Querying dynamic fields

Many attestation rulebook defines attributes that are not static and can vary and change according to verification needs.

For example:

  • age_over_NN and biometric_template_xx in the MDL attestation rule book
  • health_id in the Health ID attestation rule book, who Must be at least one of the following ids: health_insurance_id, patient_id, tax_number …

IN GROUPE Playground allow dynamic querying for these kind of attributes as described below:

We ca add or remove dynamic attributes values, no constraints are made on the value imputed.

For Health ID, we can choose one or more Ids according to rules book :

Generate VP QR request

One attestations and attributes selected and defined, we can generate the VP request by clicking on the button:

We can see the content of the QR code by passing the mouse hover it.

The QR code can then be scanned by the Eudiw Wallet to launch oid4vp flow.

To facilitate doing same test several time if need, the last verification request is always stored and we can run it again simply by clicking on new button that appears in the main page, see below.

Receive and Analyse VP Response

Once user approve sharing requested data, the playground run many validations and presents results wih technical details to help understanding of results.

They are two kind of validation:

  • Technical validations: Check technical compatibility with oid4vp standard or rules book, as issuer signature, device binding, attributes formats …
  • Functional validations: Checks attributes or document functional content as document validity

The validation tags are often clickable and show more details on the corresponding validation.

Technical Profile

Technical profile presents the list of selected values of oid4vp variants: the VP schema, the clientId Schema, the response modeHow to embed the verifier JWK and finally the request type.

The vp schema is an updatable list of value, so user can add new values if need.

User can change the default profile, or can choose one of the already defined profiles

Developer tools

The playground offers a lot of feature that help developer and tester debug their verification in case of error or failure and even in case of success.

Debug

The debug mode allow user to see and by consequence analyse some technical data that transit while presentation flow is processing. This is very helpful to control and check theses information to understand the verification behaver.

The debug mode can be activated as below:

This will concretely, show the content of the VP Request before generating the VP QR code, and show the wallet response content before parse and validate it.

Log console

The console is the UI part where the playground logs all action, event and errors.

To show the console, we check it as below:

Don’t forget to check the console in case of any error that occurs during verification process, it may contains helpful information to understand the cause

Transaction history

The playground stores in the user session every verification that has been initiated or completed

The history is accessible by clicking on the menu :

History of transactions contains for every verification: Transaction date, the oid4vp profile used for the verification, state …

The user can consult all transaction technical data as JWt request, JWE Response or the VP token received in response

The user can perform the following actions:

  • : Delete the transaction
  • : Export the full transaction information
  • : Show the response evaluation
  • : Copy the transaction Id

Miscellaneous

Vical (Verified Issuer Certificate Authority List)

The playground supports establishing trust of credential issuers relying on the Vical mechanism defined in the ISO/IEC 18013-5 standard.

We include a recent version of the Vical from the latest potential Event. However user can also add a new IACA dynamically to the list (Temporary at a user session level), the IACA must be a valid pem payload.

Dynamic load of issuer credentials

For more flexibility and the playground can extract dynamically all attestations from an issuer wellknow data, this can be very useful when playground didn’t integrate yet a new attestation or new attributes updates.

To accomplish this, in the setting page, we can set the issuer well-known data uri, save the setting and then in the presentation request page, the list of attestation will contain these issuer attestations.

For example, for the reference Eudiw issuer, the uri is: https://issuer.eudiw.dev/.well-known/openid-credential-issuer