> For the complete documentation index, see [llms.txt](https://t1t.gitbook.io/t1t-ocra-client/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://t1t.gitbook.io/t1t-ocra-client/overview/introduction.md).
# Introduction
## Introduction
Challenge–response authentication: is a family of protocols in which one party presents a question ("challenge") and another party must provide a valid answer ("response") to be authenticated. It may be used for mutual authentication e.g. when a server needs to install a new version on a client. In the case of the example, the client has to verify that the server is the one it claims it is (otherwise a malicious version may be downloaded) and the server has to verify that it downloads the new version to the right client.
The OATH Challenge-Response Algorithm (OCRA) is a generalization of HOTP with variable data inputs not solely based on an incremented counter and a secret key values.
The definition of OCRA requires a cryptographic function, a key K and a set of DataInput parameters
DataInput =**{OCRASuite | 00 | C | Q | P | S | T}**where:
```
OCRASuite is a value representing the suite of operations to compute an OCRA response
```
* 00 is a byte value used as a separator
* C is an unsigned 8-byte counter value processed high-order bit
* Q (mandatory) is a 128-byte list of (concatenated) challenge question(s) generated by the parties
* P is a hash (SHA-1, SHA-256 and SHA-512) value of PIN/password that is known to all parties
* S is a UTF-8 encoded string that contains information about the current session
* T is a number of time-steps (seconds, minutes, hours) since midnight UTC of January 1, 1970
All parameters in the OCRA suite are optional except for the Q (challenge questions).
## Authentication Modes
OCRA provides 3 Authentication modes:
* One-Way Challenge Response
* Mutual Challenge Response
* Algorithm modes for Signature (plain signature, and signature with server authentication)
The OCRA API provides a REST API in order to add a second factor to your login process.
The OCRA API implements the 'Mutual Challenge Response' Authentication Mode. The OCRA API roadmap contains both other modes, but in the current version they are not yet available.
### One-Way Challenge-Response
A challenge-response is a security mechanism in which the verifier presents a question (challenge) to the prover, who must provide a valid answer (response) to be authenticated
### Mutual Challenge-Response
Mutual challenge-response is a variation of the one-way challenge- response mechanism where both the client and server mutually authenticate each other.
### Plain Signature
To use this algorithm in plain signature mode, the server will communicate a signature-challenge value to the client (signer). The signature-challenge is either the data to be signed or is derived from the data to be signed using a hash function
### Signature with Server Authentication
This mode is a variation of the plain signature mode where the client can first authenticate the server before generating an electronic signature.
## Data Protection Policy
The OCRA API is a stateless REST service, no personalized transaction data is persisted. The audit trail generated at the end of a flow is returned to the application or service consumer of the OCRA API and is NOT persisted in the OCRA-API.
## References
[OCRA Specifications](https://tools.ietf.org/html/rfc6287)
[HMAC-Based One-Time Password Algorithm Specifications](https://tools.ietf.org/html/rfc4226)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://t1t.gitbook.io/t1t-ocra-client/overview/introduction.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.