Overview

Keyp’s core technology is an authentication infrastructure: an identity platform combining decentralized architecture with a market place approach to ensure data sovereignty (users) & market efficiency (companies) leading to an agile and secure authentication ecosystem while providing a convenient one-click user experience.

The infrastructure connects three main players: (1) companies providing a service that is secured by (2) authentication apps which are used by (3) users on their Keyp Wallet.

Service Provider

Service providers install an existing Keyp Connector or use Keyp’s SDK to develop one for their dedicated services. Then they configure an authentication workflow for their service by chaining authentication apps available on the marketplace with Keyp’s Login Manager. The resulting workflow configuration is then copied to the Keyp connector.

Authentication App

Authentication apps collect information (identity attributes) through widgets running on the Keyp Wallet which sends it to the authentication app server where the attributes are verified and signed. The resulting identity factors are sent back to the wallet where they are stored.

Keyp Wallet

When a user wants to log into the service they use the Keyp Wallet Android/iOS app to consume an authentication trigger, e.g. scan a QR code or NFC token. The wallet app downloads the workflow configuration from the service and displays all included authentication apps. After all required identity factors are available they are sent to the service where the Keyp Connector validates the correctness of all factors and in case the validation is successful authenticates the user for the service.

Example

Simplified Keyp infrastructure
Figure 1. Keyp infrastructure overview

Transaction with a workflow containing two simple authentication apps: verified email and GPS location. The latter was configured during workflow creation with a center and a radius.

  1. User scans QR code

  2. Wallet requests the workflow configuration from the service

  3. Service returns configuration

  4. Wallet request auth app widget

  5. Auth app returns widget

  6. Wallet requests identity attribute (e.g. email or location) from user through auth app widget

  7. User enters information / widget records it from sensors

  8. Wallet sends attribute to authentication app server

  9. Authentication app applies business logic, verifies attribute and returns identity factor

  10. Wallets stores and sends all requested factors to service / connector

  11. Connector validates factors, authenticates user and displays secured content to user

Whenever an identity attribute and the according identity factor already exist steps 3 - 6 may be skipped and users do not need to interact anymore

Simplified transaction

The following sequence diagram visualizes a simplified authentication and all the involved entities. It should be helpful - especially for (future) authentication app and Keyp Connector developers - when trying to get an idea of the requirements for authentication apps or Connectors.

Interaction diagram
Figure 2. Interaction diagram

Develop an authentication app

Implementing your authentication solution as an authentication app includes two parts: server and client. The server is called authentication app server while the client is referred to as authentication app widget.

The first part is setting up the authentication app server. The Keyp SDK helps you spin up the main server which handles all necessary requests and takes care of the included cryptography. You may easily extend this server with your own code in order to reflect your business logic.

The second part is the authentication app widget which is rendered and displayed by the Keyp Wallet. There is an SDK for developing widgets, too. It simplifies the interaction between wallet and widget and comes bundled with a set of UI/UX best practices which help you to develop a neat user experience.

Connect your product/service with Keyp

In order to connect your service or product to the Keyp infrastructure you either install one of the existing Keyp connectors or you develop a connector yourself.

The main tasks of a connector are

  • responding with a (customized) workflow configuration whenever a wallet asks for it

  • validating the identity factors received from a wallet at the end of a transaction

  • and passing the identity attributes included in the received factors on to the connected service

Connector

Keyp Connectors are adapters between services and the Keyp Protocol. On the one side they handle the authentication of users using the infrastructure provided by Keyp and on the other side they pass the necessary Identity Attributes to a service.

Specification

Trigger

Each Connector needs to be able to provide a starting point for Keyp transactions. Such a trigger allows to transfer information from the Connector to the Keyp Wallet, e.g. a QR-Code or an NFC token. The transferred information mainly contains the URL pointing to the Workflow Configuration for the connected service.

For example, a Connector for a web service would render a QR-Code when accessed on a desktop browser to bridge the gap between the desktop computer and the mobile device running the Keyp Wallet. When accessed mobile, the Connector would display a login button linking directly to the Wallet application. In both cases the trigger transfers the Workflow Configuration URL and some session information in order to authenticate the current user / session later.

Workflow Configuration

When processing a trigger, the Keyp Wallet extracts the Workflow Configuration URL and starts a transaction, i.e. downloads the configuration. A Workflow Configuration tells the Wallet which Authentication Apps (Identity Factors) need to be processed in what order. It may also define optional Authentication Apps or optional chains of Authentication Apps.

For each included Authentication App in a Workflow, the Workflow Configuration may list parameters defined by the Authentication App. Those parameters allow administrators to customize apps for their service.

Every Workflow Configuration must contain a callback URL used by the Wallet to post all collected Identity Factors to the Connector.

Identity Factor verification

In order to perform correct authentication it is necessary that Connectors validate received Identity Factors. Therefore, a Connector verifies the signature of each Identity Factor - posted to the callback URL by the Wallet - with the public key of the corresponding Authentication App.

After all Identity Factors required by the Workflow Configuration are successfully verified a Connector may extract the Identity Attributes and process them to authenticate the Identity Owner.

Existing Connectors

Integrations currently in development:

  • SAML

  • OpenID Connect

  • OAuth

  • LDAP

  • Active Directory

  • Ping Identity

If you are interested in the current status and timeline of the integrations projects please use our request form.

Connector interactions

Workflow Configuration

This interaction is used to receive the configured workflow for a service. E.g. Keyp Wallet wants to know which Authentication Apps the user has to pass in order to access the service.

Table 1. Actors
Role Actor

Requester

Keyp Wallet

Responder

Auth app

Interaction diagram
Figure 3. Interaction diagram
Request Workflow Configuration
Triggers

Keyp Wallet receives a transaction trigger (e.g. QR-scan) and starts the transaction.

Semantics

The requester issues a HTTP GET request to the configuration resource specified in the trigger contents, like https://service.com/keyp-connector/config.

  • Request contains a X-Keyp-Auth header holding the initialization token found inside the trigger

  • HTTPS is required

  • The requester can expect to receive an error response or the data requested

curl -H "X-Keyp-Auth: Bearer eyJhbGciOiJSUzI1NiIsInR5...nIFnHwalc" https://service.com/keyp-connector/config
Expected Actions

The responder parses the request, adds dynamic parameters (e.g. session information) to the configuration and responds with the modified configuration. While the configuration is JSON formatted and included in the response body the related configuration token resides in the Authorization response header.

Config response
Triggers
  • incoming "request workflow configuration" message

Semantics

The configuration is embedded in a HTTP POST response body with an Content-Type: application/json; header. Additionally, the configuration token with detached payload (!) is returned via the Authorization header. .Response header

< HTTP/1.1 200 OK
< Date: Tue, 06 Jun 2017 15:10:07 GMT
< Server: Apache
< Authorization: Bearer eyJhbGciOiJSUzI1NiIs...R1hrIgr9-M
< Content-Type: application/json; charset=utf-8
Response body
{
    "nbf":1496761807,
    "iat":1496761807,
    "exp":1496765407,
    "iss":"service.com",
    "kit":"eyJhbGciOiJBMjU2S1...H2ActY-b71",
    "cfg":{
        "id":"service.com",
        "title":"Example resource",
        "desc":"You may access our intranet if you have a valid email and are near our HQ",
        "authURL":"https:\/\/service.com\/keyp-connector\/auth",
        "guards":[{
            "id":"com.example.guard.location",
            "manifest":"https:\/\/location.guards.example.com\/",
            "version":"1",
            "prefill":false,
            "guardTitle":"Location",
            "guardTitleShort":"Location",
            "params":{"center":{"lat":48.151766,"lon":11.57547},"radius":1} (1)
        },{
            "id":"com.example.guards.verifiedmail",
            "manifest":"https:\/\/verifiedmail.guards.example.com\/",
            "version":"1",
            "prefill":true,
            "guardTitle":"Verified mail",
            "guardTitleShort":"Mail",
            "params":{}
        }]
    }
}
1 in a real world scenario those params would be encrypted and readable only for the desired Authentication App
Expected Actions

The requester handles the transaction according to the given workflow with the given configuration.

Authentication

This interaction is used to transfer collected Identity Factors from the Wallet to the Connector.

Table 2. Actors
Role Actor

Requester

Keyp Wallet

Responder

Connector

Interaction diagram
Figure 4. Interaction diagram
Request authentication
Triggers

Keyp Wallet finishes collecting all identity factors required by the Workflow Configuration and user decides to request access to the service.

Semantics

The requester issues a HTTP POST request to the authentication resource specified in the workflow configuration, like https://service.com/keyp-connector/auth.

  • Request contains a X-Keyp-Auth header holding the configuration token received together with the Workflow Configuration

  • The request body is a comma-separated list of Identity Factor tokens

  • HTTPS is required

  • The requester can expect to receive an error response or the data requested

curl -H "X-Keyp-Auth: Bearer eyJhbGciOiJSUzI1NiIs...R1hrIgr9-M" -X POST --data 'eyJjdH...fA5jRc,eyJjdH...ESXhaa' https://service.com/keyp-connector/auth
Expected Actions

The responder parses the request, checks if all authentication apps, i.e. the related Identity Factors, configured in the workflow are included and validates if the factors were issued by the correct Authentication Apps.

Authentication response
Triggers
  • incoming "request authentication" message

Semantics

The response is embedded in a HTTP POST response body with an Content-Type: text/html; header.

Response
< HTTP/1.1 200 OK
< Date: Tue, 06 Jun 2017 15:22:07 GMT
< Server: Apache
< Content-Type: text/html; charset=UTF-8
<
Wohoo! All guards passed. Congrats!
Expected Actions

The requester tells the user whether or not the authentication was successful and optionally redirects them to the service.

Authentication App

Within the Keyp universe Authentication Apps consist mainly of a server and a client (widget) component. While the client side widget only provides a user-interface for entering identity information (Identity Attributes), the server side takes care of the heavy work like validating the provided information.

Server specification

Authentication Apps must set up a server that serves at least the following 4 resources

  • manifest

  • zip

  • pubkey

  • sign

Manifest

Defines properties of Authentication Apps

  • id

  • title

  • author

  • desc

  • version

  • url of sign resource

  • url of pubkey resource

  • url of zip resource

The manifest may also define/document parameters (and their types) the app will accept. There are two types of app parameters:

  • widget params → allow customization of app widget (e.g. change labels, colors, …​)

  • server params → allow configuration of app server (e.g. regex a specific mail is matched against, circle (defined by center & radius) a location must be within, …​)

ID, version, URL pointing to manifest and widget/server parameters will be included in Workflow Configurations which define how a specific service (e.g. intranet website, door, …​) is protected. ID and version are used for caching purposes while the manifest URL tells the Wallet where to look for the manifest of each Authentication App included in the Workflow.

Authentication Apps depending on specific device sensors or hardware features (GPS, camera, …​) need to request permissions before the widget can be granted access. This may also be done in the manifest.

Example manifest
<?xml version="1.0" encoding="UTF-8"?>
<guard>
    <id>myguard.guards.example.com</id>
    <author>Keyp</author>
    <version>0.7.0</version>
    <title>Example guard</title>
    <resources>
        <resource name="zip">https://myguard.guards.example.com/static/guard.zip</resource>
        <resource name="pubkey">https://myguard.guards.example.com/static/pubkey.pem</resource>
        <resource name="sign">https://myguard.guards.example.com/sign</resource>
    </resources>
</guard>

ZIP / Widget

Each Authentication App must provide a HTML widget which will be displayed by the Keyp Wallet application inside a WebView. The widget is distributed as a compressed ZIP file which will be downloaded and cached by the Keyp Wallet. Details on the ZIP file content and the widget structure can be found in the [Client / Widget] section.

Signing

After the widget finishes requesting user input the Keyp Wallet app sends the identity information (e.g. email address, employee ID/card, …​) collected by the widget to the sign resource of the Authentication App server. The unit behind this URL will check and validate the provided information. After a successful verification (which may for example include checking an employee ID against an existing IAM service) the server signs the given Identity Attribute with its private key (belonging to the provided public key) and returns the signed data package back to the Keyp Wallet. This signed data package is called Identity Factor.

Guard Unit

In fact, Keyp provides a toolkit for Authentication App developers that takes care of the signing. This SDK also helps developers to parse the config params and Identity Attributes from the incoming requests and passes the data structured as a JSON string to the input stream of the program responsible for verifying the identity information. The main business logic an Authentication App provides will be implemented in this unit. When the unit is done processing the identity information it returns the given information optionally enhanced with additional properties (e.g. position inside a company that results from the employee ID). The SDK expects the output to be formatted as a valid JSON string, uses it to automatically create an Identity Factor and returns the factor to the Wallet.

Public Key

In order to verify signed data received from a Authentication App other entities (Keyp Wallet, Keyp Connectors, other Authentication Apps …​) need to be able to access the public key of an app. Each server must provide a PEM formatted public key.

Client / Widget specification

The Authentication App Widgets displayed in the Wallet are in fact static HTML websites. They are downloaded, cached and executed in a WebView inside the Wallet. Widgets are distributed as a compressed ZIP file.

The ZIP file contains one folder named like the Authentication App identifier, e.g myguard.guards.example.com. Inside this folder there needs to be at least an index.html and a manifest.xml file. There may be additional CSS, JS and image files a widget needs to provide a proper user experience.

Upon loading the widget receives the widget params defined in the current Workflow Configuration and may adjust the appearance accordingly.

Icons

Authentication App developers may provide different icons to customize the appearance of their app throughout the Wallet:

icon.png

The Authentication App icon is displayed besides the title and helps users to remember the Authentication App. Developers must provide multiple density specific resolutions of the icon. If for whatever reason the icon can’t be displayed a default icon for apps is used.

card.png

For each Identity Attribute saved by an app the Wallet displays a card-like visualization. Those cards may have custom icons (e.g. an icon for Gmail mail addresses). An Authentication App developer may also provide a default card icon (card.png) which is used for all cards without a custom icon.

If for whatever reason the card icon can’t be displayed the Wallet checks if there is an app-specific default card icon and falls back to a global default icon for cards if no card.png is found inside the widget package.

header.png

Cards may also display a custom header graphic which provides a certain level of recognizability for Identity Attributes. Like with card icons developers may save custom headers for each card. They may also provide a default card header (header.png) which is used for all cards without a custom icon.

If for whatever reason the card header can’t be displayed the wallet checks if there is an app-specific default card header and falls back to a global default header for cards if no header.png is found inside the widget package.

The header graphic is resized and placed as if you specified the background-size: cover CSS property on a HTML element. Thus, it is centered within the header area and completely covers it.

Icon resolution

Icon

Usage

Resolution (px)

mdpi

hdpi

xhdpi

xxhdpi

icon.png

Guard icon in overview lists and detail views

36x36

54x54

72x72

108x108

card.png

Icon for card preview and card title

20x20

30x30

40x40

60x50

header.png

Background graphic for card header

375x240

563x360

750x480

1125x720

iOS developers used to the @2x and @3x suffixes should put the @2x files in the xhdpi folder. @3x go in the xxhdpi folder. Both of course without the suffix.

Folder structure

myguard.guards.example.com
├── assets
│   ├── images
│   │   ├── res-hdpi
│   │   │   ├── custom.png
│   │   │   ├── ...
│   │   │   ├── card.png
│   │   │   ├── header.png
│   │   │   └── icon.png
│   │   ├── res-mdpi
│   │   │   ├── custom.png
│   │   │   ├── ...
│   │   │   ├── card.png
│   │   │   ├── header.png
│   │   │   └── icon.png
│   │   ├── res-xhdpi
│   │   │   ├── custom.png
│   │   │   ├── ...
│   │   │   ├── card.png
│   │   │   ├── header.png
│   │   │   └── icon.png
│   │   └── res-xxhdpi
│   │       ├── custom.png
│   │       ├── ...
│   │       ├── card.png
│   │       ├── header.png
│   │       └── icon.png
│   ├── scripts
│   │   ├── ...
│   │   └── custom.js
│   └── styles
│       ├── ...
│       └── custom.css
├── index.html
└── manifest.xml

Authentication App interactions

auth app interactions

Manifest

This interaction is used to retrieve the manifest of an Authentication App. E.g. because the Keyp Wallet wants to check if locally cached versions of apps are up-to-date.

Table 3. Actors
Role Actor

Requester

Keyp Wallet

Responder

Authentication App Server

Interaction diagram
Figure 5. Interaction diagram
Request manifest
Triggers
  • Comparing Authentication App versions

  • Checking possible input params

  • Reading Authentication App title

  • …​

Semantics

The requester issues a HTTP GET request to the base URL of the Authentication App, like https://myguard.guards.example.com/.

  • HTTPS is required

  • The requester can expect to receive an error response or the data requested

curl -v https://myguard.guards.example.com/
Expected Actions

The responder parses the request and responds with an XML formatted Authentication App manifest.

Manifest response
Triggers
  • incoming "request manifest" message

Semantics

The manifest is embedded in a HTTP GET response body with an Content-Type: application/xml; charset=utf-8 header

Response header
< HTTP/1.1 200 OK
< Server: nginx/1.4.6 (Ubuntu)
< Date: Tue, 06 Jun 2017 15:21:38 GMT
< Content-Type: application/xml; charset=utf-8
Response body
<?xml version="1.0" encoding="UTF-8"?>
<guard>
    <id>myguard.guards.example.com</id>
    <author>Keyp</author>
    <version>0.7.0</version>
    <title>Example guard</title>
    <resources>
        <resource name="zip">https://myguard.guards.example.com/static/guard.zip</resource>
        <resource name="pubkey">https://myguard.guards.example.com/static/pubkey.pem</resource>
        <resource name="sign">https://myguard.guards.example.com/sign</resource>
    </resources>
</guard>
Expected Actions

The document is processed according to business logic of the requester.

Widget ZIP

This interaction is used to retrieve the ZIP file containing the Authentication App widget.

Table 4. Actors
Role Actor

Requester

Keyp Wallet

Responder

Authentication App Server

Interaction diagram
Figure 6. Interaction diagram
Request widget
Triggers

Keyp Wallet wants to display the Authentication App Widget. The request is triggered if the widget was

  • never downloaded/cached before

  • the cached version is lower than the current version of the Authentication App

  • or the Workflow Configuration defines a different than the cached version

Semantics

The requester issues a HTTP GET request to the ZIP resource specified in the Authentication App manifest, like https://myguard.guards.example.com/guard.zip.

  • HTTPS is required

  • The requester can expect to receive an error response or the data requested

Expected Actions

The responder parses the request and responds with an ZIP compressed archive containing the widget files.

Widget response
Triggers
  • incoming "request widget" message

Semantics

The widget archive is embedded in a HTTP GET response body with an Content-Type: application/zip; header

Expected Actions

The archive is downloaded, inflated, cached and loaded locally by the requester.

Public Key

This interaction is used to retrieve the public key of an Authentication App.

Table 5. Actors
Role Actor

Requester

Keyp Wallet, Keyp Connector, Keyp Marketplace

Responder

Authentication App Server

Interaction diagram
Figure 7. Interaction diagram
Request pubKey
Triggers

Keyp Wallet wants to verify the signature of an Identity Factor and therefore needs the public key of the Authentication App that issued the factor.

Semantics

The requester issues a HTTP GET request to the pubKey resource specified in the Authentication App manifest, like https://myguard.guards.example.com/pubkey.

  • HTTPS is required

  • The requester can expect to receive an error response or the data requested

Expected Actions

The responder parses the request and responds with a PEM formatted public key belonging to the private key used to sign identity data.

PubKey response
Triggers
  • incoming "request pubKey" message

Semantics

The pubKey is embedded in a HTTP GET response body with an Content-Type: application/octet-stream; header

Expected Actions

The key is downloaded and used by the requester for signature verification.

Signing

This interaction is used to receive an Identity Factor containing verified identity information.

Table 6. Actors
Role Actor

Requester

Keyp Wallet

Responder

Authentication App Server

Interaction diagram
Figure 8. Interaction diagram
Request Identity Factor
Triggers

Keyp Wallet receives data collected by the Authentication App Widget and wants to transform the collected Identity Attribute into an Identity Factor.

Semantics

The requester issues a HTTP POST request to the sign resource specified in the Authentication App manifest, like https://myguard.guards.example.com/sign.

  • Collected data is sent as a JSON-string inside the POST body of the request

  • Necessary data for validation/verification (but not part of the identity information) may be passed through POST params (e.g. verification codes)

  • HTTPS is required

  • The requester can expect to receive an error response or the data requested

curl -v -H "Content-Type: text/plain; charset=utf-8" -X POST --data "eyJhbGciOiJSU...kq0h1iG8ksae3wrxMRFU" https://myguard.guards.example.com/sign
Expected Actions

The responder parses the request, applies his business logic to the input params and the message body and responds with a signed version of the received message body (Identity Factor).

Identity Factor response
Triggers
  • incoming "request Identity Factor" message

Semantics

The factor is embedded in a HTTP POST response body with an Content-Type: plain/text; header

< HTTP/1.1 200 OK
< Server: nginx/1.4.6 (Ubuntu)
< Date: Tue, 06 Jun 2017 15:49:07 GMT
< Content-Type: text/html; charset=utf-8
<
eyJjdHkiOiJLU1QiLC...rYBbTlwRIH_k1uPyendM
Expected Actions

The factor is sent to a Keyp-secured resource where it gets verified and potentially grants permission to access the resource.

Glossary

Identity Factor Federation

Keyp offers federated Identity Factors that are created and stored decentrally. Identity Factors are Identity Attributes verified by Authentication Apps like e.g. an email address, a driver’s license or a company position. Identity Factors may be reused with all [Service Provider]s being part of the federation thus enabling an SSO experience for Identity Owners. Keyp’s Identity Factor Federation platform differs from existing identity federations in a way that Identity Factors

This means [Service Provider]s participating in the Identity Factor Federation gain flexible access to trust-worthy identities while respecting users' privacy.

Identity Attribute

Claim, identity information

Characteristic or property of an Identity Owner. This may be something like an address, a phone number, a membership card, etc. Attributes always have a name, are usually typed and may have a value. In general, they are used to describe the state of an Identity Owner. Identity Attributes are defined by Authentication Apps and [Authentication App Widget]s are used to fill in the values. Those are send to the related [Authentication App Server]s, validated, verified and finally returned in the form of Identity Factors to the Identity Owner's Wallet.

Identity Factor

Badge, assertion

Identity Attribute verified, i.e. signed, by an Authentication App. After receiving the Identity Attributes from the [Authentication App Widget] the [Authentication App Server] validates and if the validation is successful signs the attribute with the Authentication App's private key. Thus, [Service Provider]s can easily check whether an Identity Factor was generated by the correct Authentication App. As long as their validity period is not exceeded Identity Factors may be reused in multiple Workflows. If this is the case, Identity Owners have a real SSO experience as no more interaction is necessary for logging into different services as long as the Identity Attributes required by the different Workflows match.

Identity Owner

User, device

Owner of Identity Attributes. Keep Identity Factors in their Wallets. Whenever Identity Owners access a service through a Workflow they can either use existing Identity Factors given that they are still valid and fit the required factors from the Workflow. Or they simply create new Identity Factors through the Authentication Apps specified in the Workflow by entering the defined Identity Attributes. Identity Owners benefit from the implicit SSO feature offered by Keyp which enables one-click logins while keeping data stored decentrally on terminals.

Authentication App

Guard

Software that validates and signs Identity Attributes and generates Identity Factors. Authentication Apps may be developed by anyone. Just like apps on the PlayStore or the AppStore. After they are submitted to the Keyp Marketplace they are reviewed, licensed and certified in order to assert basic trust. In case the review process succeeds the apps are published and available to all [Service Provider]s which may from then on include them in their Workflows. All Authentication Apps provide a frontend called [Authentication App Widget] which submits Identity Attributes to a backend called [Authentication App Server]. There the verification of the attributes takes place and the Identity Factors are generated. While [Authentication App Server]s may run on practically any machine with an internet connection [Authentication App Widget]s are always executed inside a Wallet where Identity Owners can access them. Each Authentication App defines configurable options in the [Authentication App Manifest]. The [Login Manager] uses those definitions to display standardized input elements.

Wallet

Android/iOS App, Browser extension, …​

Connecting piece between [Service Provider]s and Authentication Apps. When Identity Owners start a login process on a Service the Wallet downloads the Workflow specified for the Service and checks for each included Authentication App if the required Identity Factor already exists. Else the [Authentication App Widget] is loaded and rendered. As soon as Identity Factors for all Authentication Apps defined in the Workflow are available the Identity Factors are submitted to the Service. There the Keyp Connector takes care of the validation of the received Identity Factors and passes the Identity Attributes on to the Service. The Wallet also provides the possibility to manage existing Identity Attributes like editing and deleting. It is also possible to synchronize Wallets so that the same Identity Attributes and Identity Factors are available on multiple devices. A Wallet may also be backed up. Thus, Identity Attributes may be quickly restored in case a mobile phone is lost or irrevocable broken. In order to provide maximum security for the Identity Owner's data, Wallets should only run on platforms using hardware encryption. Wallets should at least enforce strong user credentials like fingerprints or alpha-numeric passwords.

Service

  • Website

  • Web-App or –service

  • Intranet

  • Door

  • …​

Service Provider, SP

Resource, Relying Party

Company running a service

Keyp Connector

Integration Plugin, Identity Provider , IdP

Connection between a service and the Keyp Protocol, e.g. a Wordpress Plugin. General purpose connectors offered by Keyp support the following services / standards:

  • AD / LDAP

  • SAML

  • OpenID Connect

Workflow

Describes which Authentication Apps are used during a login process in order to authenticate / identify an Identity Owner. In general, Workflows define chains of Authentication Apps. Such sequences form sub-workflows with at least one Authentication App. Sub-workflows may themselves be sub-divided into sub-sub-workflows. All Workflows (no matter at which level) define the order of included Authentication Apps / sub-workflows and list potential alternatives. A Workflow may also include optional Authentication Apps / sub-workflows. Conditional Authentication Apps / sub-workflows are supported, too. Workflows are created using Keyp’s Login Manager which provides an intuitive drag & drop interface that allows easy adding, deleting, re-ordering and configuring of Authentication Apps. The configurations of all Authentication Apps included in a Workflow together form the Workflow Configuration.