SMART Permission Tickets, published by . This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/jmandel/smart-permission-tickets-wip/ and changes regularly. See the Directory of published versions

Quickstart: Issuers

This page tells you what to build for one role. It is non-normative; the specification governs. Read it to scope the work, then implement against the normative sections it links to.

You verify real-world facts and sign a JWT. The Data Holder relies on your verification, so most requirements are about what you do before signing.

1. Publish keys at {iss}/.well-known/jwks.json. (Issuer Key Publication)
2. Run your verification workflow for the ticket type: identity proofing for the patient (self access), the patient and the delegate plus delegation authority (delegated access), the linked claim and payer identity (payer claims adjudication), the member attribution and measure (payer quality gap queries). What you must verify per type is in the Use Case Catalog.
3. Mint the ticket with the required claims (iss, aud, exp, iat, jti, ticket_type, subject, access), presenter binding where the ticket type requires it (the individual-access types do), and identity evidence for each person whose verification is the basis of the grant. (Issuer Requirements)
4. Host a revocation status list for any ticket that outlives a session, and give the authorizing person a revocation URL they can reach later without the app. (Revocation)
5. Keep your records. The ticket carries facts; you keep the evidence behind them, retrievable by jti. (Issuer vs. Data Holder Responsibility, Proposal 007)

One deployable kickoff for delivering tickets to clients — a standard SMART App Launch whose token response carries tickets — is drafted in Proposal 003.