fix: markup for riki

Sponsored-by: author

3 files changed, 26 insertions, 26 deletions

diff --git a/blog/2018/09/11/planning_meeting_iteration_29.mdwn b/blog/2018/09/11/planning_meeting_iteration_29.mdwn
index 0cdfb5a..0c9e093 100644
--- a/blog/2018/09/11/planning_meeting_iteration_29.mdwn
+++ b/blog/2018/09/11/planning_meeting_iteration_29.mdwn
@@ -273,7 +273,7 @@ Task descriptions
   confirm they can log in and become root with sudo.
 
 * **Prepare React App framework repository and populate with Hello
-  World app**: The application should say "hello, world" (or some
+  World app:** The application should say "hello, world" (or some
   similar greeting), and use the React machinery to do so: npm to
   install dependencies, whatever the React build command is chosen to
   do the build.
diff --git a/install.mdwn b/install.mdwn
index 2b215d5..4e3a21a 100644
--- a/install.mdwn
+++ b/install.mdwn
@@ -173,4 +173,4 @@ If you did not use Let's Encrypt, you may need to give `icktool` the
 
 If there's an error, something went wrong.
 
-See [[Using icktool]] for more on how to use icktool.
+See [[Using icktool|icktool]] for more on how to use icktool.
diff --git a/yuck.mdwn b/yuck.mdwn
index 1be250e..fe3fe8d 100644
--- a/yuck.mdwn
+++ b/yuck.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Yuck - an authentication server"]]
 
-**NOTE**: Yuck is in its planning phase at the moment. No code exists,
+**NOTE:** Yuck is in its planning phase at the moment. No code exists,
 only this document. Feedback on this document is welcome, via normal
 Ick channels. Ick will continue to use Qvisqve for the
 time being, until Yuck is ready to replace it.
@@ -52,16 +52,16 @@ Muck JSON store, but support for, say, LDAP can be added.
 
 ## Terminology and concepts
 
-* **access token**: a token which grants access to a service or
+* **access token:** a token which grants access to a service or
   resource; usually quite short-lived (maybe less than a minute),
   since it can't be easily revoked, but see refresh token
 
-* **API client**: a program that uses the API, either on behalf of an
+* **API client:** a program that uses the API, either on behalf of an
   end-user, or on its own behalf
 
-* **application**: software that provides a service using the RP
+* **application:** software that provides a service using the RP
 
-* **authenticate**: prove the identity of someone or something; "this
+* **authenticate:** prove the identity of someone or something; "this
   is how you know I am who I say am"; authentication can happen in any
   number of ways, and different relying parties may have different
   requirements: government ID; being able to read email sent to an
@@ -69,53 +69,53 @@ Muck JSON store, but support for, say, LDAP can be added.
   in a particular way; having particular body features (fingerprint,
   face, voice, hand shape, ...); etc, the list is almost endless
 
-* **authorize**: grant access to an authenticated entity; "what are
+* **authorize:** grant access to an authenticated entity; "what are
   they allowed to do?"
 
-* **end-user**: a human using the system, typically the reason the
+* **end-user:** a human using the system, typically the reason the
   system exists, can also be a subject
 
-* **front end**: provides the user interface to an end user via the
+* **front end:** provides the user interface to an end user via the
   user agent or browser; typically provides HTML, JS, CSS, and images,
   statically or generated dynamically, but could audio, video, or
   anything the user can interact with
 
-* **IDP**: short for identity provider
+* **IDP:** short for identity provider
 
-* **identify**: claim an identity; "this is who I say I am"
+* **identify:** claim an identity; "this is who I say I am"
 
-* **identity**: who a human is, or which instance of a program is
+* **identity:** who a human is, or which instance of a program is
 
-* **identity provider**: software the authenticates an end user and
+* **identity provider:** software the authenticates an end user and
   non-human entities, and also stores authorizations for them
 
-* **JWT**: a standard way to represent tokens, see [JWT][]; Yuck will
+* **JWT:** a standard way to represent tokens, see [JWT][]; Yuck will
   use digitally signed tokens
 
-* **OAuth2**: a protocol for authenticating software; see [OAuth2][]
+* **OAuth2:** a protocol for authenticating software; see [OAuth2][]
 
-* **OIDC**: short for OpenID Connect; a protocol for authenticating
+* **OIDC:** short for OpenID Connect; a protocol for authenticating
   end users; see [OIDC][]
 
-* **refresh token**: a token that can be used to get a new access
+* **refresh token:** a token that can be used to get a new access
   token; usually long-lived, but can be revoked, since every use can
   be checked by the IDP
 
-* **relying party**: software that relies on the IDP for
+* **relying party:** software that relies on the IDP for
   authentication and authorization; often a resource provider, but can
   also do things on request instead of merely storing things
 
-* **resource**: data stored by a resource provider
+* **resource:** data stored by a resource provider
 
-* **resource provider**: stores resources and allows authorized access
+* **resource provider:** stores resources and allows authorized access
   to it; "database"
 
 * **RP** is short for relying party or resource provider
 
-* **subject**: a person whose personal information is handled by the
+* **subject:** a person whose personal information is handled by the
   system, see end-user
 
-* **user agent**: typically a web browser, but can be a mobile
+* **user agent:** typically a web browser, but can be a mobile
   or desktop application; assumed to be under complete user control,
   and so trusted by the user, but not the ecosystem
 
@@ -311,11 +311,11 @@ owners of the RP. See below for an example.
 As examples of how an authentication server might be used, consider a
 an online banking system. It should support at least three scenarios.
 
-**End user interactively accesses their account**: The end user opens up
+**End user interactively accesses their account:** The end user opens up
 the bank web page, and logs in, and can interactively do whatever
 they're allowed to do: view their bank statement, transfer money, etc.
 
-**End user authorizes an API client**: The end user, who happens to be
+**End user authorizes an API client:** The end user, who happens to be
 a Unix sysadmin, might want to automatically retrieve their bank
 statement and feed it to their accounting system. They create an
 authorization for an API client that only allows it to retrieve the
@@ -324,7 +324,7 @@ API client identity, which is tied to the end user's identity, so that
 whatever the API client does, it is known to act on behalf of the end
 user.
 
-**Bank pays interest automatically**: The bank runs an API client,
+**Bank pays interest automatically:** The bank runs an API client,
 authorized by the bank to act autonomously and without end user
 authorization, which annually transfers interest from the bank's own
 account to each end user's account.