Rationale

Frameworks requiring multi-factor authentication, such as Teacups or Woob, require implementing multiple kinds of interactive challenges targeted towards the end user:

• Challenges that require entering a challenge computed by or received on an external medium.

• Challenges that require polling a status regularly.

• Challenges that require listening for external events, such as a received callback or ping/push requests[1].

While both local and hosted clients, i.e. clients accessible through an HTTP URL by both the remote server, are able to do the first two challenges, only hosted clients are able to do the third one. Plus, if multiple hosted clients are used within a single organization, by default, only one can safely be registered for any institution[2].

In order to centralize catching such events, we make a single component responsible for such elements: TeaL. This allows:

• Having only one URL for a given purpose for all institutions.

• Allowing local clients to receive ping/pull events.

• Allowing local clients to receive callbacks from the local browser without having to set up a local web server.

• Allowing local clients to receive callbacks from public browsers (e.g. generating a redirect URL on a local host, sending it to an end user for resolution, and receiving the callback URL directly).

• Allowing multiple hosted clients to interact with institutions.

This project was originally thought out for Teacups.

[1]

Ping and push requests here are defined as for OpenID CIBA Modes, i.e. push requests are sufficient in a given transaction, whereas ping requests require the client to make at least one more request to get required information.

[2]

Some institutions may allow multiple redirect URLs, or pushing events to multiple URLs until it is accepted on one, but by adopting a conservative approach and only presenting one URL for a purpose, we augment our chances to being compatible with all institutions.