Quick Trusted Response (QTR) Codes

Version: 0.5
Status: Draft
Last updated: 23 August 2026

1. Introduction

A Quick Trusted Response (QTR) Code is a QR code containing data and a digital signature from an identified domain. For an HTTPS URL, the exact URL text is signed by a key controlled by its host. A QTR-aware scanner can therefore determine which domain authorised the scanned data before it displays or acts on that data.

QTR authenticates data to a domain. It does not establish that the domain, data, URL, or content returned by a URL is safe. A malicious domain can sign malicious data, and a valid QTR signature must not be presented as a general safety endorsement.

Version 1 supports absolute HTTPS URLs and arbitrary UTF-8 text. Both bindings retain the original data and append a detached JWS signature. Version 1 has two mandatory public-key discovery methods: DNS and a well-known HTTPS resource. URL shortening and additional discovery methods are out of scope.

2. Conventions and terminology

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in BCP 14 when, and only when, they appear in capitals.

QTR URL: An HTTPS URL containing a valid x-qtr query field.
QTR text: UTF-8 text followed by the QTR text-binding suffix.
Target URL: The URL obtained by removing the complete x-qtr query field from a QTR URL.
Target data: The target URL or original UTF-8 text authenticated by a QTR signature.
Issuer domain: The authority whose key verifies the QTR data. It is the canonical target URL host for the URL binding and is carried in the protected header for data without an intrinsic host.
QTR token: The protected-header and signature segments of a detached JWS, serialized canonically as <protected-header>.<signature>. Verifiers also accept the JWS-compatible <protected-header>..<signature> form.
Key ID (kid): A short identifier used to select a public key.
Discovery method: The method encoded in the protected qtr value: d for DNS or w for a well-known HTTPS resource.
base64url: The URL-safe Base64 encoding from RFC 4648, without = padding, whitespace, or line breaks.

3. Version 1 format

3.1 QTR token and protected header

Version 1 uses the JWS signing calculation with a detached payload, as described by RFC 7515 Appendix F. To save one character in a QR symbol, the canonical QTR token omits the empty JWS payload segment and has two segments:

<protected-header>.<signature>

Producers MUST emit this one-dot form. For compatibility with the JWS Compact Serialization, verifiers MUST also accept the equivalent form containing an empty payload segment:

<protected-header>..<signature>

The two forms carry identical protected-header and signature values and use the same signing input. The choice between these serializations is not part of the signing input.

Both parts use canonical unpadded base64url. The protected header is a UTF-8 JSON object containing:

Member	Requirement	Meaning
`alg`	REQUIRED	Exactly `Ed25519`.
`kid`	REQUIRED	Public-key identifier.
`qtr`	REQUIRED	Version and discovery method: `1d` or `1w`.
`iss`	Text binding only	Issuer domain for non-URL text.
`iat`	OPTIONAL	Issued-at NumericDate.
`exp`	OPTIONAL	Expiry NumericDate.

An HTTPS URL header therefore looks like:

{"alg":"Ed25519","kid":"2026-01","qtr":"1w"}

A text-binding header also identifies its issuer:

{"alg":"Ed25519","kid":"2026-01","qtr":"1w","iss":"example.com"}

The qtr value is the decimal protocol version followed by one discovery method character. Version 1 permits only 1d and 1w.

The kid value MUST be 1 to 63 lowercase ASCII letters, digits, or hyphens. It MUST begin and end with a letter or digit. This restricted form can be used both as a JWK key ID and as a DNS label.

iss MUST be present in the text binding and MUST NOT be present in the URL binding. It MUST be a lowercase ASCII IDNA2008 domain name without a trailing dot or port. It MUST NOT be an IP address.

The optional iat (issued at) and exp (expires at) members are integer NumericDate values: seconds since 1970-01-01T00:00:00Z, ignoring leap seconds, as defined by RFC 7519. If exp is present, a verifier MUST reject the QTR data at or after that time. If both are present, exp MUST be later than iat. A verifier MUST reject an iat that is in the future, but MAY allow a small, locally configured clock-skew tolerance. Absence of either member has no implied value.

Producers MUST emit a protected UTF-8 JSON header without duplicate member names and SHOULD omit insignificant whitespace. Verifiers MUST reject duplicate or unknown members, invalid UTF-8, non-canonical or padded base64url, a token with no dot or more than two dots, a nonempty middle segment in the three-part form, or a decoded signature whose length is not 64 bytes.

The following expression accepts the two permitted serializations. It is useful only for splitting a QTR token; protected-header and semantic validation are still required:

^(?<protected>[A-Za-z0-9_-]+)\.{1,2}(?<signature>[A-Za-z0-9_-]{86})$

Equivalently, a parser can split on . and accept either two nonempty parts, or three parts whose middle part is empty. It MUST NOT merely take the first and last parts while ignoring arbitrary intervening parts.

3.2 JWS signing input

The external JWS payload is the exact target data before QTR metadata is appended:

for the URL binding, the ASCII bytes of the complete target URL, including any fragment; or
for the text binding, the exact UTF-8 bytes of the original text.

With the normal JWS base64 payload encoding, the signing input is:

ASCII(BASE64URL(UTF8(protected header)) || "." || BASE64URL(target data))

The payload's base64url value is used in the signing calculation but omitted from both QTR token serializations. QTR does not use the RFC 7797 b64=false option. No URL or Unicode normalisation is performed before signing.

3.3 URL binding

A version 1 target URL:

MUST be an absolute URL with the https scheme;
MUST be serialized as an ASCII URI; non-ASCII path, query, or fragment data MUST use UTF-8 percent-encoding, and an internationalized host MUST use its IDNA2008 A-label form;
MUST contain a DNS host, not an IP address;
MUST NOT contain user information (for example, https://[email protected]/);
MUST NOT already contain a query field named x-qtr; and
MUST NOT have an empty query or a query ending in &.

The QTR URL appends x-qtr=<QTR token> as the last query field, immediately before any fragment. It uses ? when the target has no query and & otherwise. The field name MUST be lowercase ASCII and MUST NOT be percent-encoded. A QTR URL MUST contain exactly one such field and MUST use & to separate fields.

Examples of valid placement:

https://example.com/?x-qtr=<protected>.<signature>
https://example.com/pay?invoice=123&x-qtr=<protected>.<signature>
https://example.com/page?x-qtr=<protected>.<signature>#section-2

The target URL is reconstructed by removing the complete x-qtr field and its adjacent ? or & delimiter while preserving any fragment. Its canonical issuer domain is its exact host as defined in Section 6.1.

3.4 Text binding

The text binding signs any sequence of valid UTF-8 text. The original text is retained verbatim and followed by this suffix:

<original text>\n\nx-qtr=<protected>.<signature>

The two separator characters are exactly two LF characters (U+000A), not a platform-specific line ending. The QTR token extends to the end of the QR payload; there is no trailing newline. A verifier finds the last occurrence of the exact \n\nx-qtr= marker, treats everything before it as the target data, and requires everything after it to be one valid QTR token. This rule remains unambiguous even when the original text contains the marker.

The original text MAY contain any Unicode scalar value and MUST be signed and verified as its exact UTF-8 representation without Unicode normalisation. Its protected header MUST contain iss, which supplies the issuer domain for key discovery and user display.

A reader that does not understand QTR can still display the original text, but will also display the appended QTR metadata. Formats whose legacy parsers reject appended text need a future format-specific binding; they MUST NOT be labelled as version 1 QTR text merely by adding this suffix.

3.5 QR symbol encoding

The complete QTR URL or QTR text MUST be encoded into QR Byte mode using the bytes defined by its binding. For QTR text containing non-ASCII characters, the QR symbol MUST use Extended Channel Interpretation (ECI) assignment 26 to identify UTF-8. Producers SHOULD also emit ECI 26 for ASCII-only QTR text so that one decoding rule applies to every text payload.

QTR does not support arbitrary binary target data in version 1. A decoder MUST preserve the decoded URL or Unicode text exactly until verification is complete.

4. Generation and verification

4.1 Generation

Given target data and a signing key, a producer MUST:

Select either the URL or text binding and validate the target data against Section 3.
Derive the issuer domain from the URL host, or set iss to the issuer domain for text.
Select a kid and either discovery method d or w.
Construct and base64url-encode the protected header.
Construct the JWS signing input from the protected header and target-data bytes as specified in Section 3.2.
Sign the JWS signing input with Ed25519.
Form the QTR token as <protected-header>.<signature>.
Append the token using the selected binding without altering the target data.

4.2 Verification

A verifier MUST perform these steps before displaying, opening, or otherwise acting on target data:

Apply implementation-defined input and decoded-size limits.
Identify and strictly parse one binding, extracting the detached token and exact target data. Reject duplicate URL fields or a malformed text suffix.
Split the token, strictly decode its protected header and signature, and enforce all Section 3.1 requirements.
Derive the issuer domain from the target URL or the protected iss value.
Validate iat and exp when present.
Retrieve and validate the identified public key using Section 6.
Reconstruct the JWS signing input from the original target-data bytes. Do not decode, re-encode, reorder, or normalise the target data.
Verify the Ed25519 signature.
Only after successful verification, report that the target data was authorised by the displayed issuer domain and allow the user to act on it.

Any change to the target data or protected header causes verification to fail.

5. Cryptography and public keys

5.1 Signature algorithm

Version 1 JWS signatures support only Ed25519 as specified by RFC 8032. The alg value MUST be Ed25519, the fully specified JOSE algorithm name registered by RFC 9864. The older polymorphic EdDSA JOSE name MUST NOT be emitted.

Ed25519 uses SHA-512 internally. Implementations MUST use the ordinary Ed25519 mode, not Ed25519ph and not an external SHA-256 preprocessing step.

5.2 JWK validation

Public keys are represented as JWKs. A usable version 1 key MUST contain:

{
  "kty": "OKP",
  "crv": "Ed25519",
  "x": "<32-byte public key as base64url>",
  "kid": "<matching key ID>",
  "alg": "Ed25519",
  "use": "sig"
}

A verifier MUST require all six members, an exact kid match, and a decoded x length of 32 bytes. It MUST reject a JWK containing the private d member. If key_ops is present, it MUST permit verification and be consistent with use. Other unknown JWK members MAY be ignored.

6. Public-key discovery

Version 1 verifiers MUST implement both discovery methods. A producer chooses one method in each QTR token; a verifier MUST NOT silently fall back to the other method if the selected method fails.

6.1 Issuer domain

For a QTR URL, the issuer domain is the target URL's host, converted to lowercase IDNA2008 A-label form as specified by RFC 5890 and RFC 5891, with one trailing root dot removed. For QTR text, it is the validated iss protected header value. IP addresses are not valid issuer domains. Discovery is performed for this exact domain; clients MUST NOT walk up through parent domains.

This exact-domain rule binds URL signatures to the displayed URL host, avoids public-suffix ambiguity, and prevents implicit parent-domain fallback. For text, the verifier MUST display iss so that a signature by one domain cannot be misrepresented as a signature by another.

6.2 DNS (`qtr == "1d"`)

The verifier queries the TXT RRset at:

<kid>._qtr.<issuer-domain>.

Each label of the resulting owner name MUST be no more than 63 octets, and the complete wire-format name MUST be no more than 255 octets including the root label, as required by RFC 1035. If it does not fit, DNS discovery fails.

The RRset MUST validate as DNSSEC Secure. An Insecure, Bogus, Indeterminate, or unsigned response cannot produce a verified result. A verifier using a remote validating resolver MUST use an authenticated channel to that resolver; it must not trust an unauthenticated DNS AD bit.

There MUST be exactly one TXT record in the RRset. Its character-strings are concatenated in wire order and have this form:

v=QTR1;k=<base64url-encoded UTF-8 JWK JSON>

For example:

2026-01._qtr.example.com. 300 IN TXT "v=QTR1;k=eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5IiwieCI6IjdreVVSZFBwbFY4NWhRNkJjVnV2RWJjQlRNUmhvc09zNUp2NW9HZnUyOGsiLCJraWQiOiIyMDI2LTAxIiwiYWxnIjoiRWQyNTUxOSIsInVzZSI6InNpZyJ9"

The decoded JWK is validated using Section 5.2. Multiple TXT records, an unknown record version, invalid encoding, or an invalid JWK cause discovery to fail.

6.3 Well-known JWKS (`qtr == "1w"`)

The verifier performs a credential-free HTTPS GET (no cookies, authorisation, or referrer) to:

https://<issuer-domain>/.well-known/qtr-jwks.json

The request MUST use the default HTTPS port and normal Web PKI certificate and hostname validation as specified by RFC 9525. Redirects MUST NOT be followed. A successful response MUST have status 200, media type application/jwk-set+json, and a body no larger than 64 KiB.

The body is a JWK Set as defined by RFC 7517. Exactly one key must have a kid equal to the QTR header's kid; that key is then validated using Section 5.2. No match or multiple matches cause discovery to fail.

qtr-jwks.json is the proposed well-known URI name and must be registered before this draft becomes a standard. It is QTR-specific so that an origin need not mix QTR keys with keys used by unrelated protocols.

6.4 Caching and rotation

Cache entries MUST be scoped by issuer domain, discovery method, kid, and algorithm. DNS results MUST NOT outlive the DNS TTL. HTTPS results MUST respect HTTP caching rules. Verifiers SHOULD cap either freshness lifetime at 24 hours to limit exposure after key withdrawal.

Publishers SHOULD introduce a new key under a new kid before using it, retain the old public key while previously issued QTR data remains valid, and remove a compromised key as quickly as their cache policy permits.

7. Optional BIMI branding

After a signature has been successfully verified, a verifier MAY use BIMI to obtain an issuer-supplied brand indicator. Branding is a separate optional result: its presence, absence, or validity MUST NOT change the QTR signature outcome or imply that the target is safe.

QTR reuses the BIMI assertion-record and image formats but not BIMI's email authentication workflow. A QTR verifier:

Queries the TXT RRset at default._bimi.<issuer-domain>. without walking to a parent or organisational domain.
Requires the RRset to validate as DNSSEC Secure. Otherwise no brand indicator is returned.
Parses one valid v=BIMI1 assertion record and obtains the HTTPS indicator location from its l tag. If an a tag is present, the verifier MAY also validate the referenced VMC or CMC under its BIMI certificate policy, using the same network protections as indicator retrieval.
Retrieves the indicator without cookies, credentials, or a referrer, applies the same network and SSRF protections as Section 10, and MUST NOT follow redirects.
Accepts only the BIMI-supported SVG or SVGZ profile, enforces a decoded size limit, and renders it with scripts, animation, external references, and network access disabled.

The user interface MUST associate the indicator with the exact displayed issuer domain. Unless a VMC or CMC has also been validated, it SHOULD describe the image as domain-provided branding rather than a verified mark.

BIMI is still an Internet-Draft. Implementations should track its current assertion-record, certificate, and SVG profile requirements rather than copying the abbreviated processing summary above indefinitely.

8. Worked example

The following values are for testing only and MUST NOT be used in production:

Private key seed: XdIlrwpzVw51QcI7SRQYcY8VMjKSrXtvtbxauvsC_tk
Public key:       7kyURdPplV85hQ6BcVuvEbcBTMRhosOs5Jv5oGfu28k
Key ID:           2026-01
Discovery:        w

8.1 QTR URL

For this target URL:

https://example.com/testing?test=abc123

the protected header is:

{"alg":"Ed25519","kid":"2026-01","qtr":"1w"}

The JWS signing input is the base64url protected header, a ., and the base64url target URL:

eyJhbGciOiJFZDI1NTE5Iiwia2lkIjoiMjAyNi0wMSIsInF0ciI6IjF3In0.aHR0cHM6Ly9leGFtcGxlLmNvbS90ZXN0aW5nP3Rlc3Q9YWJjMTIz

The resulting QTR URL is:

https://example.com/testing?test=abc123&x-qtr=eyJhbGciOiJFZDI1NTE5Iiwia2lkIjoiMjAyNi0wMSIsInF0ciI6IjF3In0.eWY50edAObL-4l48HVLDqTAmGFuBRdpj5BixAW9OoBnGGjRD88ODoHRQhvTS224JQv8oz8Akb2rnVXPIWXlIDQ

8.2 QTR text

For the original text Hello, QTR!, the protected header is:

{"alg":"Ed25519","kid":"2026-01","qtr":"1w","iss":"example.com"}

The resulting QTR text is:

Hello, QTR!

x-qtr=eyJhbGciOiJFZDI1NTE5Iiwia2lkIjoiMjAyNi0wMSIsInF0ciI6IjF3IiwiaXNzIjoiZXhhbXBsZS5jb20ifQ.JyuOy1aiL_Kv-m3MTv0s2ZVPO5DZxcQcxIegT7TEt7cM-P4AALDWazlU64UmD7mB4lgCM1yN-KuGaOXVvCvqCg

8.3 Public key and Python example

For well-known discovery, the illustrative response from https://example.com/.well-known/qtr-jwks.json is:

HTTP/1.1 200 OK
Content-Type: application/jwk-set+json
Cache-Control: public, max-age=300

{"keys":[{"kty":"OKP","crv":"Ed25519","x":"7kyURdPplV85hQ6BcVuvEbcBTMRhosOs5Jv5oGfu28k","kid":"2026-01","alg":"Ed25519","use":"sig"}]}

example.com does not serve this test key; the response above is illustrative.

This Python example generates both exact QTR payloads and verifies their signatures. It requires the cryptography package.

import base64
import json

from cryptography.hazmat.primitives.asymmetric.ed25519 import (
    Ed25519PrivateKey,
    Ed25519PublicKey,
)


def b64url_encode(value: bytes) -> str:
    return base64.urlsafe_b64encode(value).rstrip(b"=").decode("ascii")


def b64url_decode(value: str) -> bytes:
    return base64.urlsafe_b64decode(value + "=" * (-len(value) % 4))


private_seed = b64url_decode(
    "XdIlrwpzVw51QcI7SRQYcY8VMjKSrXtvtbxauvsC_tk"
)
public_key_value = "7kyURdPplV85hQ6BcVuvEbcBTMRhosOs5Jv5oGfu28k"
private_key = Ed25519PrivateKey.from_private_bytes(private_seed)
public_key = Ed25519PublicKey.from_public_bytes(
    b64url_decode(public_key_value)
)


def sign_detached(target: bytes, header: dict) -> str:
    protected = b64url_encode(
        json.dumps(header, separators=(",", ":")).encode("utf-8")
    )
    signing_input = f"{protected}.{b64url_encode(target)}".encode("ascii")
    signature = b64url_encode(private_key.sign(signing_input))
    return f"{protected}.{signature}"


def parse_token(token: str) -> tuple[str, str]:
    parts = token.split(".")
    if len(parts) == 2:
        protected, signature = parts
    elif len(parts) == 3 and parts[1] == "":
        protected, _, signature = parts
    else:
        raise ValueError("invalid QTR token serialization")
    if not protected or not signature:
        raise ValueError("empty QTR token segment")
    return protected, signature


def verify_detached(target: bytes, token: str) -> None:
    protected, signature = parse_token(token)
    signing_input = f"{protected}.{b64url_encode(target)}".encode("ascii")
    public_key.verify(b64url_decode(signature), signing_input)


target_url = "https://example.com/testing?test=abc123"
url_token = sign_detached(
    target_url.encode("ascii"),
    {"alg": "Ed25519", "kid": "2026-01", "qtr": "1w"},
)
qtr_url = f"{target_url}&x-qtr={url_token}"

assert qtr_url == (
    "https://example.com/testing?test=abc123&x-qtr="
    "eyJhbGciOiJFZDI1NTE5Iiwia2lkIjoiMjAyNi0wMSIsInF0ciI6IjF3In0."
    "eWY50edAObL-4l48HVLDqTAmGFuBRdpj5BixAW9OoBnGGjRD88ODoHRQhvTS224J"
    "Qv8oz8Akb2rnVXPIWXlIDQ"
)

target_text = "Hello, QTR!"
text_token = sign_detached(
    target_text.encode("utf-8"),
    {
        "alg": "Ed25519",
        "kid": "2026-01",
        "qtr": "1w",
        "iss": "example.com",
    },
)
qtr_text = f"{target_text}\n\nx-qtr={text_token}"

assert qtr_text == (
    "Hello, QTR!\n\nx-qtr="
    "eyJhbGciOiJFZDI1NTE5Iiwia2lkIjoiMjAyNi0wMSIsInF0ciI6IjF3IiwiaXNz"
    "IjoiZXhhbXBsZS5jb20ifQ."
    "JyuOy1aiL_Kv-m3MTv0s2ZVPO5DZxcQcxIegT7TEt7cM-P4AALDWazlU64UmD7mB4"
    "lgCM1yN-KuGaOXVvCvqCg"
)

verify_detached(target_url.encode("ascii"), url_token)
verify_detached(target_text.encode("utf-8"), text_token)
protected, signature = parse_token(url_token)
verify_detached(target_url.encode("ascii"), f"{protected}..{signature}")
print("Both signatures are valid for example.com")

Complete runnable URL, Wi-Fi, and vCard examples, including PNG QR output, are available in the examples directory.

9. Errors, timeouts, and caching

The design aim is to complete all network-assisted verification within one four-second total budget. This is a user-experience target, not a conformance requirement or recommendation. Whatever budget an implementation chooses, it MUST treat a timeout as an unverified result and MUST NOT imply that a timeout is a valid or safe result.

Implementations SHOULD expose stable machine-readable outcomes at least as specific as:

Outcome	Meaning
`malformed`	The binding, token, base64url, or protected header is invalid.
`unsupported`	The version, discovery method, or algorithm is unsupported.
`key-unavailable`	Discovery failed, timed out, or returned an insecure DNS result.
`key-invalid`	A key was ambiguous or failed JWK validation.
`signature-invalid`	Ed25519 verification failed.
`verified`	The signature is valid for the displayed issuer domain.

User interfaces SHOULD distinguish a malformed or invalid signature from a temporary inability to retrieve a key, but neither condition is verified.

10. Security considerations

Meaning of verification: A valid signature proves control of a QTR key published by the displayed issuer domain. It does not prove legal identity, reputation, safety, or the truth of the signed data.
Verify before acting: A scanner MUST NOT display trusted UI, open, prefetch, follow redirects from, or execute target data before verification and user confirmation.
SSRF: Before well-known retrieval, a verifier SHOULD block loopback, link-local, private-use, and other non-public destination addresses unless an explicit local policy permits them. It should defend against DNS rebinding by validating every address actually used for the connection.
Algorithm confusion: The verifier selects Ed25519 because version 1 requires it, then confirms that the header and JWK agree. It must not let attacker-controlled metadata select arbitrary cryptographic code.
Exact bytes: Parsing libraries often normalise URLs, query fields, line endings, or Unicode. The signature must be checked against the original target bytes, not a parsed and reserialised equivalent.
DNS: An unsigned DNS TXT record is not an authenticated key. DNS discovery requires a validated DNSSEC chain.
HTTPS: Well-known discovery requires valid TLS and forbids redirects so that key authority cannot move silently to another origin.
Key compromise: Anyone with the private key can create valid QTR data for its issuer domain. Publishers need protected key storage, rotation, and an incident-response process.
Resource limits: Implementations should bound URL length, JSON depth, decoded object size, DNS answers, HTTP response size, redirects, and total network time before processing attacker-controlled input.
Display: Interfaces should show the exact issuer domain prominently and account for Unicode lookalikes. A generic green tick without the domain is misleading.
Nested text: Original text can itself contain a QTR-looking suffix. A verifier processes only the final suffix and must not imply that an embedded marker or signature was also verified.

For URLs, QTR signs the URL text present in the QR code. It does not authenticate a later HTTP response or prevent the destination from changing its content.

11. Privacy considerations

Key discovery reveals the issuer domain and kid to a DNS resolver or reveals the issuer domain and verifier IP address to the HTTPS origin. Verifiers SHOULD use caching, avoid cookies and referrers, avoid fetching the target before user approval, and disclose this network activity in their privacy documentation.

The protected header contains no user identifier by default. Publishers should not encode user-specific information in kid, iss, iat, exp, paths, queries, fragments, or text unless it is necessary and appropriately disclosed.

12. Compatibility

A QTR URL is an ordinary HTTPS URL. A non-QTR-aware reader will usually open it with the x-qtr query field still present, so publishers MUST make their servers tolerate and ignore that field. A QTR-aware reader SHOULD remove the field and open the target URL after successful verification.

QTR text retains the complete original text before a visibly appended metadata suffix. Non-QTR-aware readers can display or copy it, although they will not automatically remove the suffix. QTR-aware readers remove the suffix only after extracting the exact bytes needed for verification.

QTR does not change the QR symbol format or require a new QR decoder.

13. Future work

Possible future versions or companion specifications may define:

format-specific bindings for non-URL payloads whose legacy grammar does not tolerate the text suffix;
signed short URLs and redirect handling;
additional signature algorithms, including post-quantum algorithms;
per-link revocation; and
offline key bundles or transparency mechanisms.

The version 0.5 design decisions are recorded in questions.md.

Name		Name	Last commit message	Last commit date
examples		examples
.gitignore		.gitignore
LICENSE		LICENSE
README.md		README.md

Navigation Menu

Uh oh!

Repository files navigation

Quick Trusted Response (QTR) Codes

Contents

1. Introduction

2. Conventions and terminology

3. Version 1 format

3.1 QTR token and protected header

3.2 JWS signing input

3.3 URL binding

3.4 Text binding

3.5 QR symbol encoding

4. Generation and verification

4.1 Generation

4.2 Verification

5. Cryptography and public keys

5.1 Signature algorithm

5.2 JWK validation

6. Public-key discovery

6.1 Issuer domain

6.2 DNS (`qtr == "1d"`)

6.3 Well-known JWKS (`qtr == "1w"`)

6.4 Caching and rotation

7. Optional BIMI branding

8. Worked example

8.1 QTR URL

8.2 QTR text

8.3 Public key and Python example

9. Errors, timeouts, and caching

10. Security considerations

11. Privacy considerations

12. Compatibility

13. Future work

14. References

About

Releases

Packages

Used by

Contributors

Uh oh!

Latest commit

History

Folders and files

Repository files navigation

Quick Trusted Response (QTR) Codes

Contents

1. Introduction

2. Conventions and terminology

3. Version 1 format

3.1 QTR token and protected header

3.2 JWS signing input

3.3 URL binding

3.4 Text binding

3.5 QR symbol encoding

4. Generation and verification

4.1 Generation

4.2 Verification

5. Cryptography and public keys

5.1 Signature algorithm

5.2 JWK validation

6. Public-key discovery

6.1 Issuer domain

6.2 DNS (qtr == "1d")

6.3 Well-known JWKS (qtr == "1w")

6.4 Caching and rotation

7. Optional BIMI branding

8. Worked example

8.1 QTR URL

8.2 QTR text

8.3 Public key and Python example

9. Errors, timeouts, and caching

10. Security considerations

11. Privacy considerations

12. Compatibility

13. Future work

14. References

About

Resources

Stars

Watchers

Forks

Releases

Packages

Used by

Contributors

6.2 DNS (`qtr == "1d"`)

6.3 Well-known JWKS (`qtr == "1w"`)