diff options
Diffstat (limited to 'doc/manual.html')
| -rw-r--r-- | doc/manual.html | 118 |
1 files changed, 118 insertions, 0 deletions
diff --git a/doc/manual.html b/doc/manual.html new file mode 100644 index 0000000..1b17e75 --- /dev/null +++ b/doc/manual.html @@ -0,0 +1,118 @@ +<?xml version="1.0" encoding="utf-8"?> +<html xmlns="http://www.w3.org/1999/xhtml" + xmlns:info="http://planete-kraus.eu/ns/info" + xml:lang="en"> + <head> + <link rel="stylesheet" type="text/css" href="style.css"/> + <title>Webid-oidc manual</title> + <info:subtitle>for version <info:version />, + <info:updated /></info:subtitle> + <info:copying> + <p> + This is the manual of webid-oidc (version <info:version />, + <info:updated />), an implementation of the Solid + authentication protocol for guile, client and server. + </p> + <p>Copyright <info:copyright-symbol /> 2020, 2021 Vivien + Kraus</p> + <info:quotation> + <p> + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation + License, Version 1.3 or any later version published by the + Free Software Foundation; with no Invariant Sections, with no + Front-Cover Texts, and with no Back-Cover Texts. A copy of the + license is included in the section entitled ``GNU Free + Documentation License'' + </p> + </info:quotation> + </info:copying> + <info:author> + <a href="mailto:vivien@planete-kraus.eu">Vivien Kraus</a> + </info:author> + <info:dircategory> + Software libraries + </info:dircategory> + <info:direntry> + <info:direntry-entry name="webid-oidc"> + Decentralized Authentication on the Web. + </info:direntry-entry> + </info:direntry> + </head> + <body> + <h1>Decentralized Authentication on the Web</h1> + <p> + Authentication on the web is currently handled in the following + way: anyone can install a server that will authenticate users on + the web. The problem is interoperability. If a client (an + application) wants to authenticate a user, it has to be approved + by the authentication server. In other words, if + <info:var>useful-program</info:var> wants to authenticate + <info:var>MegaCorp</info:var> users, then + <info:var>useful-program</info:var> has to register to + <info:var>MegaCorp</info:var> first, and get approved. This goes + against the principle of permission-less innovation, which is at + the heart of the web. + </p> + <p> + In the decentralized authentication web, the best attempt so far + is that of ActivityPub. All servers are interoperable with + respect to authentication: if user A emits an activity, it is + forwarded by A's server to its recipients, and A's server is + responsible for A's identity. + </p> + <p> + The problem with that approach is that the data is tied to the + application. It is not possible to use another application to + process the data differently, or to use multiple data sources, + in an interoperable way (without the ActivityPub server + knowing). This means that on Activitypub, microblogging + applications will not present different activities + correctly. This also means that it is difficult to write a free + replacement to a non-free application program, because it would + need to manage the data. + </p> + <p> + In the Solid ecosystem, there is a clear distinction between + servers and applications. An application is free to read data + from all places at the same time, using a permission-less + authentication system. Since the applications do not need to + store data, the cost of having users is neglectible, so users do + not need prior approval before using them (making captchas and + the like a thing of the past). Servers do not have a say in + which applications the user uses. + </p> + <p> + The authentication used is a slight modification of the + well-established OpenID Connect. It is intended to work in a web + browser, but this package demonstrates that it also works + without a web browser. + </p> + <h1>The Json Web Token</h1> + <p> + The Json Web Token, or <info:dfn>JWT</info:dfn>, is a terse + representation of a pair of JSON objects: the + <info:dfn>header</info:dfn>, and the + <info:dfn>payload</info:dfn>. The JWT can be + <info:dfn>encoded</info:dfn> as a Json Web Signature + (<info:dfn>JWS</info:dfn>), in which case the header is encoded + to base64 with the URL alphabet, and without padding characters, + the payload is also encoded to base64, and the concatenation of + the encoding of the header, a dot, and the encoding of the + payload is signed with some cryptography algorithm. In the + following, we will only be interested by public-key + cryptography. The concatenation of header, dot, payload, dot and + signature in base64 is the encoding of the JWT. + </p> + + <h1 type="appendix">GNU Free Documentation License</h1> + <info:gfdl /> + + <h1 type="unnumbered">Index</h1> + <info:printindex /> + </body> +</html> + +<!-- Local Variables: --> +<!-- mode: nxml --> +<!-- End: --> |