[media-types] Provisional media type registration request: a pplication/ep-receipt+json

--===============3416964164412691169==
Content-Type: multipart/alternative; boundary="0000000000001f5dc4065670d790"

--0000000000001f5dc4065670d790
Content-Type: text/plain; charset="UTF-8"

To the media-types reviewers,

I request a provisional registration in the standards tree for the media
type below, per RFC 6838. The defining specification is a publicly
available individual Internet-Draft; provisional registration is requested
because the specification is a work in progress. This registration supports
carrying an EMILIA authorization receipt as a SCITT Signed Statement (RFC
9943), where the COSE_Sign1 protected content-type header names this type.

Type name: application

Subtype name: ep-receipt+json

Required parameters: none

Optional parameters: none

Encoding considerations: binary; the content is a UTF-8-encoded JSON text
using the I-JSON profile (RFC 7493). The JSON is canonicalized per JCS (RFC
8785) for signing.

Security considerations: An EP receipt is a signed assertion (Ed25519 over
the JCS-canonical payload) that a named human authorized a specific action,
bound to the action by a canonical digest. Verifiers MUST verify the
signature against a key pinned out of band and MUST NOT trust key material
carried in the object. Receipts are not confidential by construction;
deployments carrying sensitive action parameters should apply transport
confidentiality and data minimization. Verification is offline and requires
no callback to any issuer. Full considerations are in the defining
specification.

Interoperability considerations: The payload is I-JSON (RFC 7493) with a
canonicalization (RFC 8785) so the signed bytes are byte-identical across
implementations. A COSE/CBOR serialization is described separately
(draft-schrock-ep-authorization-receipts and companion profiles); this type
names the JSON serialization.

Published specification: draft-schrock-ep-authorization-receipts (
https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-schrock-ep-authorization-receipts/&source=gmail&ust=1783976989915000&sa=E
)

Applications that use this media type: agent-authorization and audit
systems that need offline-verifiable evidence that a named human approved a
specific action; SCITT Transparency Services registering such evidence as
Signed Statements; relying parties, auditors, and regulators verifying the
evidence.

Fragment identifier considerations: none

Additional information:
Deprecated alias names for this type: none
Magic number(s): none
File extension(s): .json
Macintosh file type code(s): none

Person and email address to contact for further information: Iman Schrock,
[email protected]

Intended usage: COMMON

Restrictions on usage: none

Author: Iman Schrock (EMILIA Protocol, Inc.)

Change controller: Iman Schrock ([email protected]) until the defining
specification is adopted on the IETF stream, at which point change control
transfers to the IETF.

Thank you,
Iman Schrock
EMILIA Protocol

--0000000000001f5dc4065670d790
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div dir=3D"auto">To the media-types reviewers,<br><b=
r>I request a provisional registration in the standards tree for the media =
type below, per RFC 6838. The defining specification is a publicly availabl=
e individual Internet-Draft; provisional registration is requested because =
the specification is a work in progress. This registration supports carryin=
g an EMILIA authorization receipt as a SCITT Signed Statement (RFC 9943), w=
here the COSE_Sign1 protected content-type header names this type.<br><br>T=
ype name: application<br><br>Subtype name: ep-receipt+json<br><br>Required =
parameters: none<br><br>Optional parameters: none<br><br>Encoding considera=
tions: binary; the content is a UTF-8-encoded JSON text using the I-JSON pr=
ofile (RFC 7493). The JSON is canonicalized per JCS (RFC 8785) for signing.=
<br><br>Security considerations: An EP receipt is a signed assertion (Ed255=
19 over the JCS-canonical payload) that a named human authorized a specific=
 action, bound to the action by a canonical digest. Verifiers MUST verify t=
he signature against a key pinned out of band and MUST NOT trust key materi=
al carried in the object. Receipts are not confidential by construction; de=
ployments carrying sensitive action parameters should apply transport confi=
dentiality and data minimization. Verification is offline and requires no c=
allback to any issuer. Full considerations are in the defining specificatio=
n.<br><br>Interoperability considerations: The payload is I-JSON (RFC 7493)=
 with a canonicalization (RFC 8785) so the signed bytes are byte-identical =
across implementations. A COSE/CBOR serialization is described separately (=
draft-schrock-ep-authorization-receipts and companion profiles); this type =
names the JSON serialization.<br><br>Published specification: draft-schrock=
-ep-authorization-receipts (<a href=3D"https://www.google.com/url?q=3Dhttps=
://datatracker.ietf.org/doc/draft-schrock-ep-authorization-receipts/&amp;so=
urce=3Dgmail&amp;ust=3D1783976989915000&amp;sa=3DE" target=3D"_blank">https=
://www.google.com/url?q=3Dhttps://datatracker.ietf.org/doc/draft-schrock-ep=
-authorization-receipts/&amp;source=3Dgmail&amp;ust=3D1783976989915000&amp;=
sa=3DE</a>)<br><br>Applications that use this media type: agent-authorizati=
on and audit systems that need offline-verifiable evidence that a named hum=
an approved a specific action; SCITT Transparency Services registering such=
 evidence as Signed Statements; relying parties, auditors, and regulators v=
erifying the evidence.<br><br>Fragment identifier considerations: none<br><=
br>Additional information:<br>  Deprecated alias names for this type: none<=
br>  Magic number(s): none<br>  File extension(s): .json<br>  Macintosh fil=
e type code(s): none<br><br>Person and email address to contact for further=
 information: Iman Schrock, <a href=3D"mailto:[email protected]" targe=
t=3D"_blank">[email protected]</a><br><br>Intended usage: COMMON<br><b=
r>Restrictions on usage: none<br><br>Author: Iman Schrock (EMILIA Protocol,=
 Inc.)<br><br>Change controller: Iman Schrock (<a href=3D"mailto:team@emili=
aprotocol.ai" target=3D"_blank">[email protected]</a>) until the defin=
ing specification is adopted on the IETF stream, at which point change cont=
rol transfers to the IETF.<br><br>Thank you,<br>Iman Schrock<br>EMILIA Prot=
ocol</div></div></div>

--0000000000001f5dc4065670d790--


--===============3416964164412691169==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWVkaWEtdHlw
ZXMgbWFpbGluZyBsaXN0IC0tIG1lZGlhLXR5cGVzQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNl
bmQgYW4gZW1haWwgdG8gbWVkaWEtdHlwZXMtbGVhdmVAaWV0Zi5vcmcK

--===============3416964164412691169==--