[media-types] Provisional media type registration request: a pplication/authorization-evidence-challenge+json

--===============5392161935356277392==
Content-Type: multipart/alternative; boundary="000000000000e3e4f70655d752ad"

--000000000000e3e4f70655d752ad
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; I request a provisional registration
because that specification is still in development.

Type name: application
Subtype name: authorization-evidence-challenge+json
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary. The content is JSON (RFC 8259) encoded in
UTF-8.
Security considerations: See Section 4 of
draft-schrock-authorization-evidence-challenge-00. A challenge authorizes
nothing by itself: a forged challenge cannot make an action admissible, and
a fully satisfied challenge yields a verdict under the relying party's
policy, never a promise of execution. Challenges are single-use (nonce) and
expiring, which bounds replay and hoarding. Verification of evidence
presented in answer to a challenge proves signature, binding, and log
integrity, never the business correctness of the underlying action.
Interoperability considerations: Uses the +json structured syntax suffix
(RFC 6839); processors that treat the content as generic JSON can parse it
but lose the challenge semantics (single-use nonce, expiry, action-digest
binding). Consumers encountering an unrecognized "@version" value should
treat the document as unprocessable rather than guessing.
Published specification: draft-schrock-authorization-evidence-challenge-00,
"An Authorization Evidence Challenge for High-Risk Agent Actions", Section
2. An active individual Internet-Draft, not IETF-adopted or endorsed;
intended status Informational. Available at:
https://datatracker.ietf.org/doc/draft-schrock-authorization-evidence-challenge/
Applications that use this media type: Relying-party enforcement points
that refuse a high-consequence machine-initiated action with HTTP 428 and a
machine-readable statement of the evidence required; agents that parse the
challenge to obtain and present that evidence.
Fragment identifier considerations: As specified for +json in RFC 6839,
Section 3.1. No type-specific fragment identifier syntax is defined.
Additional information:
Deprecated alias names for this type: none
Magic number(s): none
File extension(s): none
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: IETF (on permanent standards-tree registration; the
draft author until then)
Provisional registration (standards tree): Yes

Thank you,
Iman Schrock
EMILIA Protocol, Inc.
[email protected]

--000000000000e3e4f70655d752ad
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; I request a provisional registration because t=
hat specification is still in development.<br><br>Type name: application<br=
>Subtype name: authorization-evidence-challenge+json<br>Required parameters=
: N/A<br>Optional parameters: N/A<br>Encoding considerations: binary. The c=
ontent is JSON (RFC 8259) encoded in UTF-8.<br>Security considerations: See=
 Section 4 of draft-schrock-authorization-evidence-challenge-00. A challeng=
e authorizes nothing by itself: a forged challenge cannot make an action ad=
missible, and a fully satisfied challenge yields a verdict under the relyin=
g party&#39;s policy, never a promise of execution. Challenges are single-u=
se (nonce) and expiring, which bounds replay and hoarding. Verification of =
evidence presented in answer to a challenge proves signature, binding, and =
log integrity, never the business correctness of the underlying action.<br>=
Interoperability considerations: Uses the +json structured syntax suffix (R=
FC 6839); processors that treat the content as generic JSON can parse it bu=
t lose the challenge semantics (single-use nonce, expiry, action-digest bin=
ding). Consumers encountering an unrecognized &quot;@version&quot; value sh=
ould treat the document as unprocessable rather than guessing.<br>Published=
 specification: draft-schrock-authorization-evidence-challenge-00, &quot;An=
 Authorization Evidence Challenge for High-Risk Agent Actions&quot;, Sectio=
n 2. An active individual Internet-Draft, not IETF-adopted or endorsed; int=
ended status Informational. Available at: <a href=3D"https://datatracker.ie=
tf.org/doc/draft-schrock-authorization-evidence-challenge/" target=3D"_blan=
k">https://datatracker.ietf.org/doc/draft-schrock-authorization-evidence-ch=
allenge/</a><br>Applications that use this media type: Relying-party enforc=
ement points that refuse a high-consequence machine-initiated action with H=
TTP 428 and a machine-readable statement of the evidence required; agents t=
hat parse the challenge to obtain and present that evidence.<br>Fragment id=
entifier considerations: As specified for +json in RFC 6839, Section 3.1. N=
o type-specific fragment identifier syntax is defined.<br>Additional inform=
ation:<br>  Deprecated alias names for this type: none<br>  Magic number(s)=
: none<br>  File extension(s): none<br>  Macintosh file type code(s): none<=
br>Person and email address to contact for further information: Iman Schroc=
k, <a href=3D"mailto:[email protected]" target=3D"_blank">team@emiliap=
rotocol.ai</a><br>Intended usage: COMMON<br>Restrictions on usage: none<br>=
Author: Iman Schrock, EMILIA Protocol, Inc.<br>Change controller: IETF (on =
permanent standards-tree registration; the draft author until then)<br>Prov=
isional registration (standards tree): Yes<br><br>Thank you,<br>Iman Schroc=
k<br>EMILIA Protocol, Inc.<br><a href=3D"mailto:[email protected]" tar=
get=3D"_blank">[email protected]</a></div></div></div>

--000000000000e3e4f70655d752ad--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWVkaWEtdHlw
ZXMgbWFpbGluZyBsaXN0IC0tIG1lZGlhLXR5cGVzQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNl
bmQgYW4gZW1haWwgdG8gbWVkaWEtdHlwZXMtbGVhdmVAaWV0Zi5vcmcK

--===============5392161935356277392==--