yes®

About yes®

yes® (https://www.yes.com/) is an identity scheme that aims to provide a centralized point for user onboarding and authentication for the German market. Through Signicat, yes® can also be used for authentication-based electronic signing. Through yes®, users can register with third-party providers, pay, or conclude contracts using their online banking login. End-users that use yes® do not have to create a new account to use it, since they will use their bank’s credentials. Since the user’s identity is verified through their bank, merchants who use yes® operate with a high level of assurance.

Integrating with yes® through Signicat

Web integration with yes® is done via the same API as Signicat’s other ID methods. yes® relies on the OIDC standard (see “Get started with authentication“ for more information). Through a single point of integration, one will get access to Signicat’s wide portfolio of integrated ID methods, including yes®, as well as other services like identity paper verification, lookups, and video assurance. For our customers, this means a shorter deployment time and a more efficient setup and maintenance of the integrations with one or several identity providers.

Digital onboarding

yes® can be used for digital onboarding of a user through user identification. This ID method can be used as standalone or in combination with other services that Signicat provides for identity assurance.

After you redirect the user to yes®, they will first be asked to choose their bank from a list.

After this, they will be redirected to the bank’s website, where they can enter their access credentials to verify their identity.

Authentication

When the user has completed the digital onboarding process, yes® can be used for authentication in the same way that it can be used for registering a new customer.

As in the digital onboarding process, the user will be asked to choose their bank from a list and then they will be redirected to the bank’s website, where they will enter their credentials to verify their identity.

The following scopes are available:

Scope Claims
email email, email_verified
phone phone_number, phone_number_verified
address address

These are all the available claims and their corresponding descriptions:

Claim Description
email The end-user’s preferred e-mail address.
email_verified Boolean value. True if the end-user’s e-mail address has been verified, false otherwise.
phone_number The end-user’s preferred phone number.
phone_number_verified Boolean value. True if the end-user’s phone number has been verified, false otherwise.
address JSON object which contains the following information:

  • locality: city or other locality
  • postal_code: zip code or equivalent component
  • country: represented using ISO 3166-1 Alpha-2, e.g. “DE” for Germany
  • street_address: street name and number or post office box number
  • formatted: complete, formatted
https://www.yes.com/claims/salutation How the end-user should be addressed, e.g. “Mr.”
https://www.yes.com/claims/title The end-user’s title, e.g. “Dr.”
given_name Given name(s) or first name(s) of the end-user. Note that in some cultures people can have multiple given names; all can be listed. If the end-user has more than one given name, they will be separated with space characters.
family_name Surname(s) or last names(s) of the end-user. Note that in some cultures people can have multiple family names, or no family name. If the end-user has more than one, they will be separated with space characters.
https://www.yes.com/claims/place_of_birth JSON Object with the place of birth containing:

  • country: represented using ISO 3166-1 Alpha-2, e.g. “DE” for Germany
  • locality: city or other locality
birthdate The end-user’s birthday in the YYYY-MM-DD format. If the year is 0000, it means that it has been omitted. If only the birth year is provided, it will be in the YYYY format. Note that, depending on the underlying platform’s date-related function, providing just the year can result varying month and day values, so the implementer needs to take this factor into account to correctly process the dates.
https://www.yes.com/claims/nationality The end-user’s nationality.
gender The end-user’s gender. The values defined by this specification are female and male. Other values may be used when neither of the defined values are applicable.
https://www.yes.com/claims/tax_id The end-user’s tax identification number.
https://www.yes.com/claims/
preferred_iban		 The IBAN of the debit account that the end-user wants to use for transactions.
https://www.yes.com/claims/
transaction_id		 Generated by default when requesting verified person data. It can also be requested explicitly through the claims parameter to be included in the ID token or user information, and persisted by the RP as a reference to this transaction for potential dispute resolution.
https://www.yes.com/claims/
verified_person_data		 The attestation and the respective claims of type https://www.yes.com/claims/verified_person_data with the following sub-elements:

verification: this element contains all the data about the verification process

  • date: when the verification occurred
  • method: method used for identity verification. Possible values are:
    • “identity_document”: verification of a physical document
    • “qes”: the person verification was derived from a QES
    • “eID”: verification using an electronic ID Card
      Depending on the value of “method”, there will be different additional sub-elements with the name of the method in the verification element
  • organization: organization that performed the verification
  • id: Unique reference to the verification process performed by the verifying organization. Used for backtracking in case of disputes or audits.

verified: marks the verified user claims

Electronic signing

Signicat enables electronic signing with yes® with an authentication-based process. That is, even though yes® does not provide a native option for electronic signing, it can be used to obtain electronic signatures through Signicat’s own signing solution. Users can use yes® (or any of the identity methods in Signicat’s hub) to authenticate themselves and access the solution. The authentication result is then reused for signing. This solution ensures a unified output format in accordance with EU specifications, as well as a scalable, responsive flow supporting modern device standards and window sizes.

How to get started with yes®

If you want to start using yes® through Signicat, get in touch with us and our sales team will guide you through the process.

Test information

Signicat’s test environment preprod.signicat.com is available 24×7, and may be used during your development and test phase.

After you register with yes® as a service provider, you will receive a client ID which will allow you to access the testing environment.

Other sources