You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+3-44Lines changed: 3 additions & 44 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -35,17 +35,14 @@ Add the following lines to `composer.json` to include the Web eID authentication
35
35
36
36
### Configure the log file location
37
37
38
-
Define the constant `LOGFILE` for log file location.
38
+
By default, log entries are written to the server log. If there is a need to collect log entries in a separate file, define the constant `LOGFILE` for the log file location.
In case, when you don't want to collect log at all, define this constant like so:
45
-
46
-
```php
47
-
define("LOGFILE", false);
48
-
```
45
+
It is essential, that your log file directory has write access.
49
46
50
47
## 2. Configure the challenge nonce store
51
48
@@ -231,44 +228,6 @@ The Web eID authentication token validation library for PHP contains the impleme
231
228
232
229
The authentication protocol, authentication token format, validation requirements and challenge nonce usage is described in more detail in the [Web eID system architecture document](https://github.com/web-eid/web-eid-system-architecture-doc#authentication-1).
233
230
234
-
# Authentication token format
235
-
236
-
In the following,
237
-
238
-
-**origin** is defined as the website origin, the URL serving the web application,
239
-
-**challenge nonce** (or challenge) is defined as a cryptographic nonce, a large random number that can be used only once, with at least 256 bits of entropy.
240
-
241
-
The Web eID authentication token is a JSON data structure that looks like the following example:
-`unverifiedCertificate`: the base64-encoded DER-encoded authentication certificate of the eID user; the public key contained in this certificate should be used to verify the signature; the certificate cannot be trusted as it is received from client side and the client can submit a malicious certificate; to establish trust, it must be verified that the certificate is signed by a trusted certificate authority,
256
-
257
-
-`algorithm`: the signature algorithm used to produce the signature; the allowed values are the algorithms specified in [JWA RFC](https://www.ietf.org/rfc/rfc7518.html) sections 3.3, 3.4 and 3.5:
258
-
259
-
```
260
-
"ES256", "ES384", "ES512", // ECDSA
261
-
"PS256", "PS384", "PS512", // RSASSA-PSS
262
-
"RS256", "RS384", "RS512" // RSASSA-PKCS1-v1_5
263
-
```
264
-
265
-
- `signature`: the base64-encoded signature of the token (see the description below),
266
-
267
-
- `format`: the type identifier and version of the token format separated by a colon character '`:`', `web-eid:1.0` as of now; the version number consists of the major and minor number separated by a dot, major version changes are incompatible with previous versions, minor version changes are backwards-compatible within the given major version,
268
-
269
-
- `appVersion`: the URL identifying the name and version of the application that issued the token; informative purpose, can be used to identify the affected application in case of faulty tokens.
270
-
271
-
The value that is signed by the user’s authentication private key and included in the `signature` field is `hash(origin)+hash(challenge)`. The hash function is used before concatenation to ensure field separation as the hash of a value is guaranteed to have a fixed length. Otherwise the origin `example.com` with challenge nonce `.eu1234` and another origin `example.com.eu` with challenge nonce `1234` would result in the same value after concatenation. The hash function `hash` is the same hash function that is used in the signature algorithm, for example SHA256 in case of RS256.
0 commit comments