1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
<?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>What if something goes wrong?</h1>
<p>
The library will raise an exception whenever something fishy
occurs. For instance, if a signature is invalid, or the
expiration date has passed. All exception types are defined in
<emph>(webid-oidc errors)</emph>.
</p>
<info:deffn type="function" name="error->str" arguments="error [#depth]">
<p>
Return a string explaining the <info:var>error</info:var>. You
can limit the <info:var>depth</info:var> of the explanation as
an integer.
</p>
</info:deffn>
<info:deftp type="exception type" name="&not-base64" arguments="value cause">
<p>
This exception is raised when the base64 decoding function
failed. <info:var>value</info:var> is the incorrect input,
and <info:var>cause</info:var> is a low-level error.
</p>
</info:deftp>
<info:deftp type="exception type" name="&unsupported-crv" arguments="crv">
<p>
The identifier <info:var>crv</info:var> does not identify an
elliptic curve.
</p>
</info:deftp>
<info:deftp type="exception type" name="&not-a-jwk" arguments="value cause">
<p>
<info:var>obj</info:var> does not identify a JWK.
</p>
</info:deftp>
<h1 type="appendix">GNU Free Documentation License</h1>
<info:gfdl />
<h1 type="unnumbered">Index</h1>
<info:printindex />
</body>
</html>
<!-- Local Variables: -->
<!-- mode: nxml -->
<!-- End: -->
|
