feat: add draft data, gap analysis report, and workspace config
This commit is contained in:
@@ -0,0 +1,35 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<reference anchor="I-D.ietf-scitt-architecture" target="https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22">
|
||||
<front>
|
||||
<title>An Architecture for Trustworthy and Transparent Digital Supply Chains</title>
|
||||
<author initials="H." surname="Birkholz" fullname="Henk Birkholz">
|
||||
<organization>Fraunhofer SIT</organization>
|
||||
</author>
|
||||
<author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-Lavaud">
|
||||
<organization>Microsoft Research</organization>
|
||||
</author>
|
||||
<author initials="C." surname="Fournet" fullname="Cedric Fournet">
|
||||
<organization>Microsoft Research</organization>
|
||||
</author>
|
||||
<author initials="Y." surname="Deshpande" fullname="Yogesh Deshpande">
|
||||
<organization>ARM</organization>
|
||||
</author>
|
||||
<author initials="S." surname="Lasker" fullname="Steve Lasker">
|
||||
</author>
|
||||
<date month="October" day="10" year="2025" />
|
||||
<abstract>
|
||||
<t> Traceability in supply chains is a growing security concern. While
|
||||
verifiable data structures have addressed specific issues, such as
|
||||
equivocation over digital certificates, they lack a universal
|
||||
architecture for all supply chains. This document defines such an
|
||||
architecture for single-issuer signed statement transparency. It
|
||||
ensures extensibility, interoperability between different
|
||||
transparency services, and compliance with various auditing
|
||||
procedures and regulatory requirements.
|
||||
|
||||
</t>
|
||||
</abstract>
|
||||
</front>
|
||||
<seriesInfo name="Internet-Draft" value="draft-ietf-scitt-architecture-22" />
|
||||
|
||||
</reference>
|
||||
@@ -0,0 +1,23 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<reference anchor="I-D.nennemann-wimse-ect" target="https://datatracker.ietf.org/doc/html/draft-nennemann-wimse-ect-00">
|
||||
<front>
|
||||
<title>Execution Context Tokens for Distributed Agentic Workflows</title>
|
||||
<author initials="C." surname="Nennemann" fullname="Christian Nennemann">
|
||||
<organization>Independent Researcher</organization>
|
||||
</author>
|
||||
<date month="February" day="25" year="2026" />
|
||||
<abstract>
|
||||
<t> This document defines Execution Context Tokens (ECTs), a JWT-based
|
||||
extension to the WIMSE architecture that records task execution
|
||||
across distributed agentic workflows. Each ECT is a signed record of
|
||||
a single task, linked to predecessor tasks through a directed acyclic
|
||||
graph (DAG). ECTs reuse the WIMSE signing model and are transported
|
||||
in a new Execution-Context HTTP header field alongside existing WIMSE
|
||||
identity headers.
|
||||
|
||||
</t>
|
||||
</abstract>
|
||||
</front>
|
||||
<seriesInfo name="Internet-Draft" value="draft-nennemann-wimse-ect-00" />
|
||||
|
||||
</reference>
|
||||
@@ -0,0 +1,13 @@
|
||||
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
|
||||
<front>
|
||||
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
|
||||
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
|
||||
<date month="March" year="1997"/>
|
||||
<abstract>
|
||||
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
|
||||
</abstract>
|
||||
</front>
|
||||
<seriesInfo name="BCP" value="14"/>
|
||||
<seriesInfo name="RFC" value="2119"/>
|
||||
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
|
||||
</reference>
|
||||
@@ -0,0 +1,14 @@
|
||||
<reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7515">
|
||||
<front>
|
||||
<title>JSON Web Signature (JWS)</title>
|
||||
<author fullname="M. Jones" initials="M." surname="Jones"/>
|
||||
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
|
||||
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
|
||||
<date month="May" year="2015"/>
|
||||
<abstract>
|
||||
<t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
|
||||
</abstract>
|
||||
</front>
|
||||
<seriesInfo name="RFC" value="7515"/>
|
||||
<seriesInfo name="DOI" value="10.17487/RFC7515"/>
|
||||
</reference>
|
||||
@@ -0,0 +1,14 @@
|
||||
<reference anchor="RFC7519" target="https://www.rfc-editor.org/info/rfc7519">
|
||||
<front>
|
||||
<title>JSON Web Token (JWT)</title>
|
||||
<author fullname="M. Jones" initials="M." surname="Jones"/>
|
||||
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
|
||||
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
|
||||
<date month="May" year="2015"/>
|
||||
<abstract>
|
||||
<t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
|
||||
</abstract>
|
||||
</front>
|
||||
<seriesInfo name="RFC" value="7519"/>
|
||||
<seriesInfo name="DOI" value="10.17487/RFC7519"/>
|
||||
</reference>
|
||||
@@ -0,0 +1,17 @@
|
||||
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126">
|
||||
<front>
|
||||
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
|
||||
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
|
||||
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
|
||||
<author fullname="T. Narten" initials="T." surname="Narten"/>
|
||||
<date month="June" year="2017"/>
|
||||
<abstract>
|
||||
<t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
|
||||
<t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
|
||||
<t>This is the third edition of this document; it obsoletes RFC 5226.</t>
|
||||
</abstract>
|
||||
</front>
|
||||
<seriesInfo name="BCP" value="26"/>
|
||||
<seriesInfo name="RFC" value="8126"/>
|
||||
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
|
||||
</reference>
|
||||
@@ -0,0 +1,13 @@
|
||||
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
|
||||
<front>
|
||||
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
|
||||
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
|
||||
<date month="May" year="2017"/>
|
||||
<abstract>
|
||||
<t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
|
||||
</abstract>
|
||||
</front>
|
||||
<seriesInfo name="BCP" value="14"/>
|
||||
<seriesInfo name="RFC" value="8174"/>
|
||||
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
|
||||
</reference>
|
||||
@@ -0,0 +1,13 @@
|
||||
<reference anchor="RFC8615" target="https://www.rfc-editor.org/info/rfc8615">
|
||||
<front>
|
||||
<title>Well-Known Uniform Resource Identifiers (URIs)</title>
|
||||
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
|
||||
<date month="May" year="2019"/>
|
||||
<abstract>
|
||||
<t>This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
|
||||
<t>In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.</t>
|
||||
</abstract>
|
||||
</front>
|
||||
<seriesInfo name="RFC" value="8615"/>
|
||||
<seriesInfo name="DOI" value="10.17487/RFC8615"/>
|
||||
</reference>
|
||||
@@ -0,0 +1,16 @@
|
||||
<reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9110">
|
||||
<front>
|
||||
<title>HTTP Semantics</title>
|
||||
<author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
|
||||
<author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
|
||||
<author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
|
||||
<date month="June" year="2022"/>
|
||||
<abstract>
|
||||
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
|
||||
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
|
||||
</abstract>
|
||||
</front>
|
||||
<seriesInfo name="STD" value="97"/>
|
||||
<seriesInfo name="RFC" value="9110"/>
|
||||
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
|
||||
</reference>
|
||||
@@ -0,0 +1,16 @@
|
||||
<reference anchor="RFC9334" target="https://www.rfc-editor.org/info/rfc9334">
|
||||
<front>
|
||||
<title>Remote ATtestation procedureS (RATS) Architecture</title>
|
||||
<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
|
||||
<author fullname="D. Thaler" initials="D." surname="Thaler"/>
|
||||
<author fullname="M. Richardson" initials="M." surname="Richardson"/>
|
||||
<author fullname="N. Smith" initials="N." surname="Smith"/>
|
||||
<author fullname="W. Pan" initials="W." surname="Pan"/>
|
||||
<date month="January" year="2023"/>
|
||||
<abstract>
|
||||
<t>In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.</t>
|
||||
</abstract>
|
||||
</front>
|
||||
<seriesInfo name="RFC" value="9334"/>
|
||||
<seriesInfo name="DOI" value="10.17487/RFC9334"/>
|
||||
</reference>
|
||||
Reference in New Issue
Block a user