# yes®
Page contents
# About yes®
yes® (https://www.yes.com/ (opens new window)) is an identity scheme that aims to provide a centralised point for user onboarding and authentication for the German market. Through Signicat, yes® can also be used for authentication-based electronic signatures.
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.
Page contents
# 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 Getting 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 identity paper verification services.
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.
# OIDC response example
For response examples with two different scopes, see the OIDC response examples page.
# OIDC scopes
The following scopes are available:
| Scope | Claims |
|---|---|
email | email, email_verified |
phone | phone_number, phone_number_verified |
address | address |
# OIDC claims / SAML attributes
These are all the available claims/attributes and their corresponding descriptions:
| Claim | Description |
|---|---|
email | The end-user’s preferred email address. |
email-verified | Boolean value. true if the end-user’s email 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 | A set of claims containing the details for the user's address: locality: city or other locality postal_code: zip code or equivalent component country: represented using ISO 3166-1 Alpha-2 (opens new window), e.g. “DE” for Germany street_address: street name and number or post office box number formatted: complete, formatted. |
delivery-address | A set of claims containing the details of the user's address for deliveries. See address.* for the full details of the attributes available. |
place-of-birth | A set of claims containing the details about the place of birth of the end-user: country: represented using ISO 3166-1 Alpha-2 (opens new window), e.g. “DE” for Germany locality: city or other locality. |
salutation | How the end-user should be addressed, e.g. “Mr.”. |
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. |
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. |
nationalities | An array containing the end-user’s nationality (or nationalities). |
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. |
tax-id | The end-user’s tax identification number. |
preferred-iban | The IBAN of the debit account that the end-user wants to use for transactions. |
transaction-id | A transaction identifier used for audit purposes. |
verified | A set of claims containing the verified information about the end-user. The following claims can be verified: birthdate given-name family-name nationalities birthdate address place-of-birth |
verification | A set of claims containing identity attestation information: trust-framework: The trust framework describing how the end-user's identity has been verified. The only supported value is de_aml. process: An identifier for the end-user's identification for audit purposes. evidence: Verification based on any kind of government issued identity document. type: The type of evidence. Only value supported is id_document. method: The method used to verify the ID document. time: Time stamp in ISO 8601:2004 [ISO8601-2004] YYYY-MM-DDThh:mm[:ss]TZD format representing the date when this ID document was verified. verifier: Information about the legal entity that performed the identity verification: organization: organisation that performed the verification. txn: Identifier referring to the identity verification transaction. This transaction identifier can be resolved into transaction details during an audit. document: Information about the ID document used to perform the identity verification. It consists of the following properties: issuer.country: String denoting the country or organization that issued the document as ICAO 2-letter code. issuer.name: Designation of the issuer. number: The number of the identity document. date-of-issuance: The date the document was issued at. date-of-expiry: The date the document will expire at. type: The type of ID document. |
yes-issuer | An unique identifier for the actual entity who authenticated the user. |
For a more detailed overview of the semantics and format of these claims, please read the OpenID Connect for Identity Assurance 1.0 specification (opens new window).
# Electronic signatures
Signicat enables electronic signatures with yes® with an authentication-based process. That is, even though yes® does not provide a native option for electronic signatures, it can be used to obtain electronic signatures through Signicat's own electronic signature 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 signing interface supporting modern device standards and window sizes.
# How to get started with yes®
If you want to start using yes® through Signicat, contact Signicat (opens new window) 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
- Information about yes®: https://www.yes.com/ (opens new window)
- Style guide: https://www.yes.com/styleguide (opens new window)
← WebID