adding link tool tips for #46 (maybe that's all it takes)

this took much longer than it should have. MD is horrible. in this
case, escaping '<' in link tool tips seems to be necessary in jekyll,
even though it is not necessary in atom. it would be good to have a
proper function for MD output that handles all necessary escaping.

concepts/http-authentication-scheme.md

@@ -10,16 +10,16 @@ The following 10 HTTP Authentication Scheme values were found in [all available
 
 HTTP Authentication Scheme | Specification
 -------: | :-------
-[`Basic`](/concepts/http-authentication-scheme/Basic) | [**RFC 7617**: The 'Basic' HTTP Authentication Scheme](/specs/IETF/RFC/7617 "This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/password pairs, encoded using Base64.")
-[`Bearer`](/concepts/http-authentication-scheme/Bearer) | [**RFC 6750**: The OAuth 2.0 Authorization Framework: Bearer Token Usage](/specs/IETF/RFC/6750 "This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.")
-[`Digest`](/concepts/http-authentication-scheme/Digest) | [**RFC 7616**: HTTP Digest Access Authentication](/specs/IETF/RFC/7616 "The Hypertext Transfer Protocol (HTTP) provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.")
-[`HOBA`](/concepts/http-authentication-scheme/HOBA) | [**RFC 7486**: HTTP Origin-Bound Authentication (HOBA)](/specs/IETF/RFC/7486 "HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.")
-[`Mutual`](/concepts/http-authentication-scheme/Mutual) | [**RFC 8120**: Mutual Authentication Protocol for HTTP](/specs/IETF/RFC/8120 "This document specifies an authentication scheme for the Hypertext Transfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password.")
-[`Negotiate`](/concepts/http-authentication-scheme/Negotiate) | [**RFC 4559**: SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows](/specs/IETF/RFC/4559 "This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of "negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed. This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism. Details of Simple And Protected Negotiate (SPNEGO) implementation are not provided in this document.")
-[`OAuth`](/concepts/http-authentication-scheme/OAuth) | [**RFC 5849**: The OAuth 1.0 Protocol](/specs/IETF/RFC/5849 "OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.")
-[`SCRAM-SHA-1`](/concepts/http-authentication-scheme/SCRAM-SHA-1) | [**RFC 7804**: Salted Challenge Response HTTP Authentication Mechanism](/specs/IETF/RFC/7804 "This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.")
-[`SCRAM-SHA-256`](/concepts/http-authentication-scheme/SCRAM-SHA-256) | [**RFC 7804**: Salted Challenge Response HTTP Authentication Mechanism](/specs/IETF/RFC/7804 "This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.")
-[`vapid`](/concepts/http-authentication-scheme/vapid) | [**Internet Draft ietf-webpush-vapid**: Voluntary Application Server Identification (VAPID) for Web Push](/specs/IETF/I-D/ietf-webpush-vapid "An application server can use the method described to voluntarily identify itself to a push service. This identification information can be used by the push service to attribute requests that are made by the same application server to a single entity. An application server can include additional information that the operator of a push service can use to contact the operator of the application server. This identification information can be used to restrict the use of a push subscription a single application server.")
+[`Basic`](/concepts/http-authentication-scheme/Basic "The Basic authentication scheme is based on the model that the client needs to authenticate itself with a user-id and a password for each protection space ("realm"). The realm value is a free-form string that can only be compared for equality with other realms on that server.") | [**RFC 7617**: The 'Basic' HTTP Authentication Scheme](/specs/IETF/RFC/7617 "This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/password pairs, encoded using Base64.")
+[`Bearer`](/concepts/http-authentication-scheme/Bearer "All challenges defined by this specification MUST use the auth-scheme value "Bearer". This scheme MUST be followed by one or more auth-param values.") | [**RFC 6750**: The OAuth 2.0 Authorization Framework: Bearer Token Usage](/specs/IETF/RFC/6750 "This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.")
+[`Digest`](/concepts/http-authentication-scheme/Digest "The Digest scheme is based on a simple challenge-response paradigm. The Digest scheme challenges using a nonce value and might indicate that username hashing is supported. A valid response contains an unkeyed digest of the username, the password, the given nonce value, the HTTP method, and the requested URI.") | [**RFC 7616**: HTTP Digest Access Authentication](/specs/IETF/RFC/7616 "The Hypertext Transfer Protocol (HTTP) provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.")
+[`HOBA`](/concepts/http-authentication-scheme/HOBA "An HTTP server that supports HOBA authentication includes the "HOBA" auth-scheme value in a WWW-Authenticate header field when it wants the client to authenticate with HOBA.") | [**RFC 7486**: HTTP Origin-Bound Authentication (HOBA)](/specs/IETF/RFC/7486 "HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.")
+[`Mutual`](/concepts/http-authentication-scheme/Mutual "The scheme provides true mutual authentication between an HTTP client and an HTTP server, using just a simple password as a credential.") | [**RFC 8120**: Mutual Authentication Protocol for HTTP](/specs/IETF/RFC/8120 "This document specifies an authentication scheme for the Hypertext Transfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password.")
+[`Negotiate`](/concepts/http-authentication-scheme/Negotiate "Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".") | [**RFC 4559**: SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows](/specs/IETF/RFC/4559 "This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of "negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed. This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism. Details of Simple And Protected Negotiate (SPNEGO) implementation are not provided in this document.")
+[`OAuth`](/concepts/http-authentication-scheme/OAuth "Protocol parameters can be transmitted using the HTTP "Authorization" header field as defined by RFC 2617 with the auth-scheme name set to "OAuth" (case insensitive). Servers MAY indicate their support for the "OAuth" auth-scheme by returning the HTTP "WWW-Authenticate" response header field upon client requests for protected resources.") | [**RFC 5849**: The OAuth 1.0 Protocol](/specs/IETF/RFC/5849 "OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.")
+[`SCRAM-SHA-1`](/concepts/http-authentication-scheme/SCRAM-SHA-1 "HTTP SCRAM is an HTTP Authentication mechanism whose client response and server challenge messages are text-based messages containing one or more attribute-value pairs separated by commas. SCRAM-SHA-1 is registered for database compatibility with implementations of RFC 5802 that want to also expose HTTP access to a related service, but it is not recommended for new deployments.") | [**RFC 7804**: Salted Challenge Response HTTP Authentication Mechanism](/specs/IETF/RFC/7804 "This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.")
+[`SCRAM-SHA-256`](/concepts/http-authentication-scheme/SCRAM-SHA-256 "HTTP SCRAM is an HTTP Authentication mechanism whose client response and server challenge messages are text-based messages containing one or more attribute-value pairs separated by commas. For interoperability, all HTTP clients and servers supporting SCRAM MUST implement the SCRAM-SHA-256 authentication mechanism.") | [**RFC 7804**: Salted Challenge Response HTTP Authentication Mechanism](/specs/IETF/RFC/7804 "This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.")
+[`vapid`](/concepts/http-authentication-scheme/vapid "This authentication scheme carries a signed JWT, plus the key that signed that JWT. This authentication scheme is for origin-server authentication only. Therefore, this authentication scheme MUST NOT be used with the Proxy-Authenticate or Proxy-Authorization header fields. ") | [**Internet Draft ietf-webpush-vapid**: Voluntary Application Server Identification (VAPID) for Web Push](/specs/IETF/I-D/ietf-webpush-vapid "An application server can use the method described to voluntarily identify itself to a push service. This identification information can be used by the push service to attribute requests that are made by the same application server to a single entity. An application server can include additional information that the operator of a push service can use to contact the operator of the application server. This identification information can be used to restrict the use of a push subscription a single application server.")
 
 <br/>
 <hr/>