How do we stitch all components together? The most important task for Open
Console is to authenticate people for services for real. Here is the global
picture:
The four blocks in above diagram:
- right-bottom: the website, which offers a service.
It has a "login via Open Console" button.
- right-top: someone is administrator of a group which is responsible for the
service. He has specified the conditions how to use the service.
- left-top: an innocent user of Open Console. The first time he clicks on the
"login" button on the website, he will be directed to a new
contract page to agree on the
service's requirements.
- left-bottom: the Open Console algorithm (as described below)
The authentication algorithm
To describe what is happening from the viewpoint of Open Console at runtime:
- The registered service logs-in on an Open Console "connect" server, presenting
its service unique identifier and its configured secret token. This results
in a server specific, short lived, service session token.
- Some user clicks on the "login" button on the website of the service. He gets
redirected from the service to Open Console, with the service session token.
- When the user does not have an Open Console account
yet, he gets a chance to create one.
- When the user is not yet logged-in, he will be prompted to login.
- Now (1) the service
information is collected, to get the internal service configuration.
- Lookup the contract for the user with
this service identifier (2). When there is no such contract,
the user gets a chance to create it, with defaults from one of his
identities.
- Is the contract still valid? When it has expired, or when the service has
changed since last login, the user gets redirected to update/resign the
contract.
- Is the contract new or did the contract change since last login, then show which data is
passed (3) to comply.
This data is a mix of account,
identity, and
proofs and assets.
- When the contract has not changed since last login, give the user a few
seconds to interrupt for changing the comply settings.
- Generate a "Grant" object: this is the data collected to Comply plus protocol handling information.
The Grant is available in the fast "connect" system component of Open Console.
- Finally, user gets redirected (OAuth2 style) to the website of the service.
- It depends on the authentication protocol how the information which is collected
in the Grant gets shipped (4) to the website.
For the login algorithm, it does not really matter how Open Console and the Service
communicate. This could be classical OAuth2, OpenID Connect, or other schemes.
The produced "Grant" contains a super-set of information.
Authentication protocol
The specifics of the Grant and the protocols can be found at the
wiki of the connect repo.
At the moment of this writing (2026), an OAuth2 like implementation is available, which
exchanges the full Grant. In a later version, this will also be provided as JWT (signed Jason
Web Token). Go to the our demo application website
to see how it work.
OpenID Connect data is a subset of the Grant, and expected once a sponsor is found.