A full draft specification is being written. We can begin with an example s-link and then describe the syntax in detail:

<a link-security="expiry=1357849989; 
href="https://www.example.com">a secure link!</a>

This links specifies two public keys, one of which must appear somewhere in certificate chain presented by example.com.

S-link syntax
Syntax is based on the proposed HPKP standard, with a few changes. S-links contain a series of directives, specified as:


Directive names may consist of ASCII alphanumeric strings only. The optional directive value may consist of any ASCII string not containing a ';'. The semi-colon terminates any directive.

Adding s-link directives
A string consisting of a series of s-link directives can be added as a link-security attribute to any HTML element containing a src or href attribute: A, AREA, IMG, SCRIPT, INPUT, IFRAME, FRAME, EMBED, VIDEO, AUDIO, SOURCE, TRACK. We refer to the site specified by the src or href attribute as the destination site.

Core directives
The following directives are the core of s-links, which all compliant user agents must process:
  • expiry: All s-links must include an expiry date whose value is specified as a number of seconds since midnight UTC 1970-01-01. User agents must ignore all directives if the expiry time is in the past. An s-link without an expiry date is considered invalid and all other directives must be ignored. User agents should limit any expiry date to be 30 days after a page is initially loaded if the page is cached.
  • pin-[hash_algorithm]: Identical to the syntax of HPKP, key pins are specified as the hash (in Base64) of the Subject Public Key Info as specified in an X.509 certificate. The hash_algorithm component may currently be any of {sha1, sha256, sha512, sha3-256, sha3-512}. If any pin directives are present then the user agent must verify that AT LEAST one of the keys in the certificate chain used to authenticate the destination site matches any of the pin values specified. Note that the pin may be to the server's TLS key (sent in a leaf certificate), the server's CA key, or any intermediate certificate. Multiple pins may be specified if servers use multiple keys or have a backup key. Unlike HPKP, s-links may pin to a single key.
Following s-links
A compliant user agent must not load any data from a destination site over a connection which violates any directive specified in a s-link. Any violation of the s-link security directives should be treated equivalently to the domain specified in a src or href attribute being unreachable. S-links must leave no persistent changes on the user agent regardless of the success or failure of the security directives.

Interaction with local caching
When accessing any resource protected by an s-link, a compliant user agent must not use a cached version of that resource unless it can be verified that the connection originally used to load the resource satisfied all security directives in the s-link. If insufficient information about the original connection has been maintained by the user agent, the resource must be re-loaded. In the absence of these requirements, a network attacker could detect and stall the s-link protected resource request while injecting a modified version of the resource with long-lived caching directives in real-time to prevent the resource from being securely loaded.

Future directives
The following directives may be added in the future. User agents may ignore any directives if they do not understand them. Some of these directives relate to protocols (DNSSEC, DANE, CT, TACK, Sovereign Keys) which aren't yet widely deployed, but they demonstrate the power of the s-link framework.
  • min-tls-version: This directive must include a value for the minimum TLS version used when negotiating a TLS session with the destination site. This can prevent version rollback attacks.
  • ev-required: This directive take no value. If present it requires that the destination site present an Extended Validation certificate. This can prevent EV downgrade attacks.
  • dnssec-required: This directive takes no value. If present it requires that the IP address for the destination site must be resolved using DNSSEC with records signed up to the root.
  • dane-required: This directive takes no value. If present it requires that the certificate presented by the destination site must be included in DNS records using DANE. This can be satisfied using DNSSEC stapling in place of client resolution of DNSSEC records.
  • ct-required: This directive takes no value. If present it requires that the destination site present a signature showing that its certificate has been logged by Certificate Transparency logs.
  • tack-pin: This directive must specify a value which is a TACK-signing key fingerprint. The destination site must present a valid TACK using at least one of the TSKs specified.
  • sovereign-key-pin: This directive must specify a value which is the hash of a Sovereign Key which the destination site must use to sign its certificate chain.