|
Type
|
Reference
|
Content
|
|
web
|
github.com
|
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
|
|
web
|
www.rfc-editor.org
|
A Permission Ticket is a signed access ticket
: an issuer-signed JWT that a client presents to a Data Holder's token endpoint via OAuth 2.0 Token Exchange (RFC 8693)
. It lets a client ask a Data Holder for a local access token without repeating the whole authorization or verification workflow at every Data Holder. The ticket is portable: the same ticket can be presented at any Data Holder within its intended audience, without requiring the issuer to know where the subject has received care.
|
|
web
|
www.rfc-editor.org
|
A trusted issuer mints a Permission Ticket and delivers it to the client. The client presents the ticket as a subject_token
in an RFC 8693
token exchange request, authenticating itself separately. The Data Holder authenticates the client using its supported OAuth client-authentication mechanism, then validates the ticket: signature, issuer trust, audience, presenter binding, and access constraints. If valid, it issues an access token scoped per Access Calculation
.
|
|
web
|
www.rfc-editor.org
|
Permission Tickets are presented via OAuth 2.0 Token Exchange (RFC 8693)
. The client authenticates using a standard OAuth client-authentication mechanism and presents the Permission Ticket as a separate subject_token
parameter. A common pattern is a JWT client_assertion
per RFC 7523
, as profiled by
SMART Backend Services
and UDAP
. This cleanly separates client authentication
from the authorization grant
: the client-authentication artifact proves client identity; the subject_token
carries the Permission Ticket.
|
|
web
|
www.rfc-editor.org
|
Note on cnf (decided).
Standard JWT confirmation uses the cnf
claim ( RFC 7800
). This specification diverges: both binding modes live in one presenter_binding
discriminated union rather than splitting key binding into cnf
and framework binding into a custom claim. The key-binding semantics are exactly cnf.jkt
— the same RFC 7638 thumbprint comparison, so thumbprint code written for cnf.jkt
is reusable as-is — and only the claim shape differs. Recorded as a resolved design decision in the Open Questions registry
.
|
|
web
|
www.rfc-editor.org
|
Data Holder computes the JWK Thumbprint ( RFC 7638
) of the client_assertion
signing key and compares it to presenter_binding.jkt
. Reject on mismatch.
|
|
web
|
www.rfc-editor.org
|
must_understand
lists top-level claim names
that the Data Holder MUST understand beyond the base kernel. Each entry is a string matching a top-level claim in the ticket payload. This is inspired by the JWS crit
header parameter ( RFC 7515
Section 4.1.11) but applied to payload claims rather than header parameters.
|
|
web
|
www.rfc-editor.org
|
Binding:
When present, presenter_binding.method = "jkt"
binds redemption to a specific client key via its JWK Thumbprint ( RFC 7638
). presenter_binding.method = "trust_framework_client"
binds redemption to a trust-framework-recognized entity. When presenter_binding
is absent, aud
+ client authentication provide the trust boundary.
|
|
web
|
openid.net
|
This proposal details how Permission Ticket issuers can participate in OpenID Federation 1.0
to publish their ticket-signing keys, and how Data Holders consume that publication when verifying tickets. It builds on the issuer key publication requirements in the main specification
.
|
|
web
|
github.com
|
Hand-authored TypeScript definitions
|
|
web
|
github.com
|
Canonical Zod schema
|
