|
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 an issuer-signed JWT presented to a Data Holder's token endpoint via OAuth 2.0 Token Exchange (RFC 8693)
. It allows a client to redeem a portable authorization grant at any Data Holder that falls within the ticket's intended audience and satisfies its constraints, 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 to the intersection of requested and ticket-authorized access.
|
|
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:
Standard JWT confirmation uses the cnf
claim ( RFC 7800
). This specification uses presenter_binding.method = "jkt"
with a sibling jkt
field instead, keeping all presenter-binding semantics in one place. The binding semantics are the same as cnf.jkt
; only the claim shape differs.
|
|
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
|
