Home » DIF Presentation Exchange & SIOP v2

Presentation Exchangewith SIOP v2

Presentation Exchange

The Presentation Exchange enables  a Verifier and a Holder to exchange Verifiable Credential data and the Verifier to validate that data.

Sphereon has developed a Typescript/Javascript Library  that implements the functionality described in the DIF Presentation Exchange specification.OpenID Connect with Presentation Exchange The presentation exchange operates generally as follows:

  1. The verifier creates a Presentation Definition asking for credentials from the holder.
  2. The definition for the credentials is sent to the holder,
  3. The holder checks and returns a presentation as a response,
  4. Now the verifier will verify the presentation by checking the signature and other accompanying proofs.

The presentation exchange will ensure that the model used by the verifier, can be interpreted by the holder. It then ensures that the correct parts from the holders credentials are used to create the presentation. Our PE implementation contains all the logic to interpret the models, therefore removing the need for the verifier and holder to align their specific models.

The presentation Exchange is part of Sphereon VDX, our Verifiable Data Exchange platform.

 

Self Issued OpenID Provider v2 (SIOP)

SIOP v2 is an extension of OpenID Connect to allow End-users to act as OpenID Providers (OPs) themselves. Using Self-Issued OPs, End-users can authenticate themselves and present claims directly to the Relying Parties (RPs), typically a webapp, without relying on a third-party Identity Provider. This makes the solution fully self sovereign, as it does not rely on any third parties and strictly happens peer 2 peer, but still uses the OpenID Connect protocol.

Next to the user acting as an OpenID Provider, this library also includes support for Verifiable Presentations using the Presentation Exchange support provided by our pe-js library.

This works as follows:

  1. The Relying Party (RP), the Verifier, poses a submission requirements on the Verifiable Credentials it would like to receive from the client/OP.
  2. The Holder is the client, the OpenID Provider (OP). The OP checks whether it has the credentials to support the submission requirements.
  3. Only if that is the case it will send the relevant (parts of the) credentials as a Verifiable Presentation in the Authentication Response destined for the Webapp/Relying Party.
  4. The Relying Party in turn checks validity of the Verifiable Presentation(s) as well as the match with the submission requirements.
  5. Only if everything is verified successfully the RP serves the protected page(s).

This means that the authentication can be extended with claims about the authenticating entity, but it can also be used to easily consume credentials from supporting applications, without having to setup DIDComm connections for instance.

The term Self-Issued comes from the fact that the End-users (OP) issue self-signed ID Tokens to prove validity of the identifiers and claims. This is a trust model different from that of the rest of OpenID Connect where OP is run by the third party who issues ID Tokens on behalf of the End-user to the Relying Party upon the End-user’s consent. This means the End-User is in control about his/her data instead of the 3rd party OP.

Github:

Demo: https://vimeo.com/630104529

 

 

This Presentation Exchange project has received funding from the European Union’s
Horizon 2020 research and innovation programme within the framework of the
ESSIF-Lab Project funded under grant agreement No 8 71932”

Logo Sphereon

Sorry

De versie van de browser die je gebruikt is verouderd en wordt niet ondersteund.
Upgrade je browser om de website optimaal te gebruiken.