├── .github ├── workflows │ ├── LICENSE.md │ ├── update.yml │ ├── archive.yml │ ├── ghpages.yml │ └── publish.yml └── CODEOWNERS ├── LICENSE.md ├── .editorconfig ├── Makefile ├── .gitignore ├── README.md ├── CONTRIBUTING.md └── draft-deshpande-secevent-http-multi-push.md /.github/workflows/LICENSE.md: -------------------------------------------------------------------------------- 1 | This project is in the public domain. 2 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # License 2 | 3 | See the 4 | [guidelines for contributions](https://github.com/aaronpk/draft-deshpande-secevent-http-multi-push/blob/main/CONTRIBUTING.md). 5 | -------------------------------------------------------------------------------- /.editorconfig: -------------------------------------------------------------------------------- 1 | # See http://editorconfig.org 2 | 3 | root = true 4 | 5 | [*.{md,xml,org}] 6 | charset = utf-8 7 | insert_final_newline = true 8 | trim_trailing_whitespace = true 9 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Automatically generated CODEOWNERS 2 | # Regenerate with `make update-codeowners` 3 | draft-deshpande-secevent-http-multi-push.md apoorva.deshpande@okta.com aaron@parecki.com 4 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | LIBDIR := lib 2 | include $(LIBDIR)/main.mk 3 | 4 | $(LIBDIR)/main.mk: 5 | ifneq (,$(shell grep "path *= *$(LIBDIR)" .gitmodules 2>/dev/null)) 6 | git submodule sync 7 | git submodule update $(CLONE_ARGS) --init 8 | else 9 | git clone -q --depth 10 $(CLONE_ARGS) \ 10 | -b main https://github.com/martinthomson/i-d-template $(LIBDIR) 11 | endif 12 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.html 2 | *.pdf 3 | *.redxml 4 | *.swp 5 | *.txt 6 | *.upload 7 | *~ 8 | .tags 9 | /*-[0-9][0-9].xml 10 | /.gems/ 11 | /.refcache 12 | /.targets.mk 13 | /.venv/ 14 | /.vscode/ 15 | /lib 16 | /node_modules/ 17 | /versioned/ 18 | Gemfile.lock 19 | archive.json 20 | draft-deshpande-secevent-http-multi-push.xml 21 | package-lock.json 22 | report.xml 23 | !requirements.txt 24 | -------------------------------------------------------------------------------- /.github/workflows/update.yml: -------------------------------------------------------------------------------- 1 | name: "Update Generated Files" 2 | # This rule is not run automatically. 3 | # It can be run manually to update all of the files that are part 4 | # of the template, specifically: 5 | # - README.md 6 | # - CONTRIBUTING.md 7 | # - .note.xml 8 | # - .github/CODEOWNERS 9 | # - Makefile 10 | # 11 | # 12 | # This might be useful if you have: 13 | # - added, removed, or renamed drafts (including after adoption) 14 | # - added, removed, or changed draft editors 15 | # - changed the title of drafts 16 | # 17 | # Note that this removes any customizations you have made to 18 | # the affected files. 19 | on: workflow_dispatch 20 | 21 | jobs: 22 | build: 23 | name: "Update Files" 24 | runs-on: ubuntu-latest 25 | steps: 26 | - name: "Checkout" 27 | uses: actions/checkout@v4 28 | 29 | - name: "Update Generated Files" 30 | uses: martinthomson/i-d-template@v1 31 | with: 32 | make: update-files 33 | token: ${{ github.token }} 34 | 35 | - name: "Push Update" 36 | run: git push 37 | -------------------------------------------------------------------------------- /.github/workflows/archive.yml: -------------------------------------------------------------------------------- 1 | name: "Archive Issues and Pull Requests" 2 | 3 | on: 4 | schedule: 5 | - cron: '0 0 * * 0,2,4' 6 | repository_dispatch: 7 | types: [archive] 8 | workflow_dispatch: 9 | inputs: 10 | archive_full: 11 | description: 'Recreate the archive from scratch' 12 | default: false 13 | type: boolean 14 | 15 | jobs: 16 | build: 17 | name: "Archive Issues and Pull Requests" 18 | runs-on: ubuntu-latest 19 | steps: 20 | - name: "Checkout" 21 | uses: actions/checkout@v4 22 | 23 | # Note: No caching for this build! 24 | 25 | - name: "Update Archive" 26 | uses: martinthomson/i-d-template@v1 27 | env: 28 | ARCHIVE_FULL: ${{ inputs.archive_full }} 29 | with: 30 | make: archive 31 | token: ${{ github.token }} 32 | 33 | - name: "Update GitHub Pages" 34 | uses: martinthomson/i-d-template@v1 35 | with: 36 | make: gh-archive 37 | token: ${{ github.token }} 38 | 39 | - name: "Save Archive" 40 | uses: actions/upload-artifact@v4 41 | with: 42 | path: archive.json 43 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Multi-Push-Based Security Event Token (SET) Delivery Using HTTP 2 | 3 | This is the working area for the individual Internet-Draft, "Multi-Push-Based Security Event Token (SET) Delivery Using HTTP". 4 | 5 | * [Editor's Copy](https://aaronpk.github.io/draft-deshpande-secevent-http-multi-push/#go.draft-deshpande-secevent-http-multi-push.html) 6 | * [Datatracker Page](https://datatracker.ietf.org/doc/draft-deshpande-secevent-http-multi-push) 7 | * [Individual Draft](https://datatracker.ietf.org/doc/html/draft-deshpande-secevent-http-multi-push) 8 | * [Compare Editor's Copy to Individual Draft](https://aaronpk.github.io/draft-deshpande-secevent-http-multi-push/#go.draft-deshpande-secevent-http-multi-push.diff) 9 | 10 | 11 | ## Contributing 12 | 13 | See the 14 | [guidelines for contributions](https://github.com/aaronpk/draft-deshpande-secevent-http-multi-push/blob/main/CONTRIBUTING.md). 15 | 16 | Contributions can be made by creating pull requests. 17 | The GitHub interface supports creating pull requests using the Edit (✏) button. 18 | 19 | 20 | ## Command Line Usage 21 | 22 | Formatted text and HTML versions of the draft can be built using `make`. 23 | 24 | ```sh 25 | $ make 26 | ``` 27 | 28 | Command line usage requires that you have the necessary software installed. See 29 | [the instructions](https://github.com/martinthomson/i-d-template/blob/main/doc/SETUP.md). 30 | 31 | -------------------------------------------------------------------------------- /.github/workflows/ghpages.yml: -------------------------------------------------------------------------------- 1 | name: "Update Editor's Copy" 2 | 3 | on: 4 | push: 5 | paths-ignore: 6 | - README.md 7 | - CONTRIBUTING.md 8 | - LICENSE.md 9 | - .gitignore 10 | pull_request: 11 | paths-ignore: 12 | - README.md 13 | - CONTRIBUTING.md 14 | - LICENSE.md 15 | - .gitignore 16 | 17 | jobs: 18 | build: 19 | name: "Update Editor's Copy" 20 | runs-on: ubuntu-latest 21 | steps: 22 | - name: "Checkout" 23 | uses: actions/checkout@v4 24 | 25 | - name: "Setup" 26 | id: setup 27 | run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" 28 | 29 | - name: "Caching" 30 | uses: actions/cache@v4 31 | with: 32 | path: | 33 | .refcache 34 | .venv 35 | .gems 36 | node_modules 37 | .targets.mk 38 | key: i-d-${{ steps.setup.outputs.date }} 39 | restore-keys: i-d- 40 | 41 | - name: "Build Drafts" 42 | uses: martinthomson/i-d-template@v1 43 | with: 44 | token: ${{ github.token }} 45 | 46 | - name: "Update GitHub Pages" 47 | uses: martinthomson/i-d-template@v1 48 | if: ${{ github.event_name == 'push' }} 49 | with: 50 | make: gh-pages 51 | token: ${{ github.token }} 52 | 53 | - name: "Archive Built Drafts" 54 | uses: actions/upload-artifact@v4 55 | with: 56 | path: | 57 | draft-*.html 58 | draft-*.txt 59 | -------------------------------------------------------------------------------- /.github/workflows/publish.yml: -------------------------------------------------------------------------------- 1 | name: "Publish New Draft Version" 2 | 3 | on: 4 | push: 5 | tags: 6 | - "draft-*" 7 | workflow_dispatch: 8 | inputs: 9 | email: 10 | description: "Submitter email" 11 | default: "" 12 | type: string 13 | 14 | jobs: 15 | build: 16 | name: "Publish New Draft Version" 17 | runs-on: ubuntu-latest 18 | steps: 19 | - name: "Checkout" 20 | uses: actions/checkout@v4 21 | 22 | # See https://github.com/actions/checkout/issues/290 23 | - name: "Get Tag Annotations" 24 | run: git fetch -f origin ${{ github.ref }}:${{ github.ref }} 25 | 26 | - name: "Setup" 27 | id: setup 28 | run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" 29 | 30 | - name: "Caching" 31 | uses: actions/cache@v4 32 | with: 33 | path: | 34 | .refcache 35 | .venv 36 | .gems 37 | node_modules 38 | .targets.mk 39 | key: i-d-${{ steps.setup.outputs.date }} 40 | restore-keys: i-d- 41 | 42 | - name: "Build Drafts" 43 | uses: martinthomson/i-d-template@v1 44 | with: 45 | token: ${{ github.token }} 46 | 47 | - name: "Upload to Datatracker" 48 | uses: martinthomson/i-d-template@v1 49 | with: 50 | make: upload 51 | env: 52 | UPLOAD_EMAIL: ${{ inputs.email }} 53 | 54 | - name: "Archive Submitted Drafts" 55 | uses: actions/upload-artifact@v4 56 | with: 57 | path: "versioned/draft-*-[0-9][0-9].*" 58 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | This repository relates to activities in the Internet Engineering Task Force 4 | ([IETF](https://www.ietf.org/)). All material in this repository is considered 5 | Contributions to the IETF Standards Process, as defined in the intellectual 6 | property policies of IETF currently designated as 7 | [BCP 78](https://www.rfc-editor.org/info/bcp78), 8 | [BCP 79](https://www.rfc-editor.org/info/bcp79) and the 9 | [IETF Trust Legal Provisions (TLP) Relating to IETF Documents](http://trustee.ietf.org/trust-legal-provisions.html). 10 | 11 | Any edit, commit, pull request, issue, comment or other change made to this 12 | repository constitutes Contributions to the IETF Standards Process 13 | (https://www.ietf.org/). 14 | 15 | You agree to comply with all applicable IETF policies and procedures, including, 16 | BCP 78, 79, the TLP, and the TLP rules regarding code components (e.g. being 17 | subject to a Simplified BSD License) in Contributions. 18 | ## Working Group Information 19 | 20 | Discussion of this work occurs on the [Security Events 21 | Working Group mailing list](mailto:id-event@ietf.org) 22 | ([archive](https://mailarchive.ietf.org/arch/browse/id-event/), 23 | [subscribe](https://www.ietf.org/mailman/listinfo/id-event)). 24 | In addition to contributions in GitHub, you are encouraged to participate in 25 | discussions there. 26 | 27 | **Note**: Some working groups adopt a policy whereby substantive discussion of 28 | technical issues needs to occur on the mailing list. 29 | 30 | You might also like to familiarize yourself with other 31 | [Working Group documents](https://datatracker.ietf.org/wg/secevent/documents/). 32 | -------------------------------------------------------------------------------- /draft-deshpande-secevent-http-multi-push.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Multi-Push-Based Security Event Token (SET) Delivery Using HTTP" 3 | abbrev: "Multi-Push SET" 4 | category: std 5 | 6 | docname: draft-deshpande-secevent-http-multi-push-latest 7 | submissiontype: IETF 8 | number: 9 | date: 10 | v: 3 11 | area: "Security" 12 | workgroup: "Security Events" 13 | keyword: 14 | - security event 15 | - secevent 16 | venue: 17 | group: "Security Events" 18 | type: "Working Group" 19 | mail: "id-event@ietf.org" 20 | arch: "https://mailarchive.ietf.org/arch/browse/id-event/" 21 | github: "aaronpk/draft-deshpande-secevent-http-multi-push" 22 | latest: "https://drafts.aaronpk.com/draft-deshpande-secevent-http-multi-push/draft-deshpande-secevent-http-multi-push.html" 23 | 24 | author: 25 | - 26 | fullname: Apoorva Deshpande 27 | organization: Okta 28 | email: apoorva.deshpande@okta.com 29 | - 30 | fullname: Aaron Parecki 31 | organization: Okta 32 | email: aaron@parecki.com 33 | 34 | normative: 35 | RFC8417: 36 | RFC7231: 37 | RFC8935: 38 | RFC9110: 39 | RFC8446: 40 | I-D.ietf-oauth-resource-metadata: 41 | RFC8259: 42 | 43 | informative: 44 | 45 | 46 | --- abstract 47 | 48 | This specification defines how multiple Security Event Tokens (SETs) can be 49 | delivered to an intended recipient using HTTP POST over TLS. The SETs 50 | are transmitted in the body of an HTTP POST request to an endpoint 51 | operated by the recipient, and the recipient indicates successful or 52 | failed transmission via the HTTP response. 53 | 54 | --- middle 55 | 56 | # Introduction 57 | 58 | This specification defines a mechanism by which a transmitter of a Security Event Token (SET) {{RFC8417}} can deliver multiple SETs to an intended SET Recipient via HTTP POST {{RFC7231}} over TLS in a single POST call. {{RFC8935}} focuses on the delivery of the single SET to the receiver. This specification builds onto {{RFC8935}} to transmit multiple SETs to the receiver in a single POST call. 59 | 60 | Multi-push SET delivery is intended to help in following scenarios: 61 | 62 | - The transmitter of the SET has multiple outstanding SETs to be communicated to the receiver 63 | - The transmitter wants to reduce the number of outbound calls to the same receiver to optimize performance, avoid being ratelimited when number of SETs to be communicated is high 64 | - The receiver wants to optimize processing multiple SETs 65 | 66 | Multi-push specification will handle all the usecases and scenarios for the {{RFC8935}} and make it more extensible to support multiple SETs per one outbound POST call. 67 | 68 | Similar to {{RFC8935}} this specification makes mechanism for exchanging configuration metadata such as endpoint URLs, cryptographic keys, and possible implementation constraints such as buffer size limitations between the transmitter and recipient is out of scope. 69 | 70 | # Multi-Push Endpoint 71 | 72 | Each Receiver that supports this specification MUST support a "multi-push" endpoint. This endpoint MUST be capable of serving HTTP POST {{RFC7231}} requests. This endpoint MUST be TLS {{RFC8446}} enabled and MUST reject any communication not using TLS. 73 | The Transmitter obtains the multi-push endpoint outside the scope of this specification. 74 | 75 | 76 | # SET delivery semantics 77 | 78 | In a multi-push based SET delivery using HTTP over TLS, zero or more SETs are delivered in a JSON {{RFC8259}} document 79 | to the SET Receiver. The receiver either acknowledges the successful receipt of the SETs or indicates failure in processing of one or more SETs in a JSON document to the Transmitter. 80 | 81 | After successful (acknowledged) SET delivery, SET Transmitters are not required to retain or record SETs for retransmission. Once a SET is acknowledged, the SET Recipient SHALL be responsible for retention, if needed. Transmitters may also discard undelivered SETs under deployment-specific conditions, such as if they have not been acknowledged (successful or failure) for over too long a period of time or if an excessive amount of storage is needed to retain them. 82 | 83 | Upon receiving a SET, the SET Recipient reads the SET and validates it in the manner described in {{Section 2 of RFC8935}}. The SET Recipient MUST acknowledge receipt to the SET Transmitter, and SHOULD do so in a timely fashion (e.g., miliseconds). The SET Recipient SHALL NOT use the event acknowledgement mechanism to report event errors other than those relating to the parsing and validation of the SET. 84 | 85 | ## Acknowledgement for all SETs 86 | A Transmitter MUST ensure that it includes the `jti` value of each SET it receives, either in an ack or a setErrs value, to the Transmitter from which it received the SETs. A Transmitter SHOULD retry sending the same SET again if it was never responded to either in an ack value or in a setErrs value by a receiver in a reasonable time period. A Transmitter MAY limit the number of times it retries sending a SET. A Transmitter MAY publish the retry time period and maximum number of retries to its peers, but such publication is outside the scope of this specification. 87 | 88 | ## Uniqueness of SETs 89 | A Transmitter MUST NOT send two SETs with the same `jti` value if the SET has been either acknowledged through ack value or produced an error indicated by a setErrs value. If a Transmitter wishes to re-send an event after it has received a error response through a setErrs value, then it MUST generate a new SET that has a new (and unique) jti value. 90 | 91 | ## Transmitting SETs 92 | 93 | A Transmitter may initiate communication with the receiver in order to: 94 | 95 | - Send SETs to the Receiver 96 | - Receive acknowledgement of the SETs in response 97 | 98 | The body of this request is of the content type "application/json". It MAY contain the following fields: 99 | 100 | `sets` 101 | OPTIONAL. A JSON object containing key-value pairs in which the key of a field is a string that contains the jti claim of the SET that is specified in the value of the field. This field MAY be omitted to indicate that no SETs are being delivered by the initiator in this communication. The Transmitter SHOULD limit 20 SETs in the sets. 102 | 103 | 104 | The following is a non-normative example of a response. 105 | 106 | { 107 | "sets": { 108 | "4d3559ec67504aaba65d40b0363faad8": 109 | "eyJhbGciOiJub25lIn0. 110 | eyJqdGkiOiI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsImlhdC 111 | I6MTQ1ODQ5NjQwNCwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwi 112 | YXVkIjpbImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MW 113 | ZhNWJiYzg3OTU5M2I3NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0Zl 114 | ZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybj 115 | ppZXRmOnBhcmFtczpzY2ltOmV2ZW50OmNyZWF0ZSI6eyJyZWYiOiJodHRwczov 116 | L3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1Mj 117 | FkOSIsImF0dHJpYnV0ZXMiOlsiaWQiLCJuYW1lIiwidXNlck5hbWUiLCJwYXNz 118 | d29yZCIsImVtYWlscyJdfX19.", 119 | "3d0c3cf797584bd193bd0fb1bd4e7d30": 120 | "eyJhbGciOiJub25lIn0. 121 | eyJqdGkiOiIzZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIsImlhdC 122 | I6MTQ1ODQ5NjAyNSwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwi 123 | YXVkIjpbImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MW 124 | ZhNWJiYzg3OTU5M2I3NzU0IiwiaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0Zl 125 | ZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciXSwic3ViIjoiaHR0cHM6Ly 126 | 9zY2ltLmV4YW1wbGUuY29tL1VzZXJzLzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIx 127 | ZDkiLCJldmVudHMiOnsidXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3 128 | dvcmRSZXNldCI6eyJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkifSwi 129 | aHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeH 130 | QiOnsicmVzZXRBdHRlbXB0cyI6NX19fQ." 131 | } 132 | } 133 | 134 | _Figure 1: Example of SET Transmission_ 135 | 136 | In the above example, the Transmitter is sending 2 SETs to the Receiver. 137 | 138 | { 139 | "sets": {}, 140 | } 141 | 142 | _Figure 2: Example of empty SET transmission_ 143 | 144 | In the above example, the Transmitter is sending zero SETs to the Receiver. This placeholder/empty request provides the Receiver to respond back with ack/err for previously transmitted SETs 145 | 146 | ## Response Communication 147 | 148 | A Receiver MUST repond to the communication by sending an HTTP response. The body of this response is of the content type "application/json". It contains MAY contain the following fields: 149 | 150 | `ack` 151 | OPTIONAL. An array of strings, in which each string is the jti value of a previously received SET that is acknowledged in this object. This array MAY be empty or this field MAY be omitted to indicate that no previously received SETs are being acknowledged in this communication. 152 | 153 | `setErrs` 154 | OPTIONAL. A JSON object containing key-value pairs in which the key of a field is a string that contains the jti value of a previously received SET that the sender of the communication object was unable to process. The value of the field is a JSON object that has the following fields: 155 | 156 | `err` 157 | OPTIONAL. The short reason why the specified SET failed to be processed. 158 | 159 | `description` 160 | OPTIONAL. An explanation of why the SET failed to be processed 161 | 162 | ### Success Response 163 | 164 | If the Receiver is successful in processing the request, it MUST return the HTTP status code 200 (OK). The response MUST have the content-type "application/json". 165 | 166 | HTTP/1.1 200 OK 167 | Content-type: application/json 168 | 169 | { 170 | "ack": [ 171 | "3d0c3cf797584bd193bd0fb1bd4e7d30" 172 | ] 173 | } 174 | 175 | _Figure 3: Example of SET Transmission response with ack_ 176 | 177 | In the above example, the Receiver acknowledges one of the SETs it previously received. There are no errors reported by the Receiver. 178 | 179 | HTTP/1.1 200 OK 180 | Content-type: application/json 181 | 182 | { 183 | "ack": [ 184 | "f52901c499611ef94540242ac12000322", 185 | "0636e274399711ef9454-0242ac120002", 186 | "d563c72479a04ff0ba415657fa5e2cb11" 187 | ], 188 | "setErrs": { 189 | "4d3559ec67504aaba65d40b0363faad8" : { 190 | "err": "invalid subject", 191 | "description": "subject format not supported" 192 | } 193 | } 194 | } 195 | 196 | _Figure 4: Example of SET Transmission response, ack and errors_ 197 | 198 | In the above example, the Receiver acknowledges three of the SETs it previously received. There are errors reported by the Receiver for acklowledging one SET. 199 | 200 | #### Out of order delivery 201 | 202 | A Response may contain `jti` values in its ack or setErrs that do not correspond to the SETs received in the same Request to which the Response is being sent. They MAY consist of values received in previous Requests. 203 | 204 | ### Error Response 205 | 206 | The receiver MUST respond with an error response if it is unable to process the request. The error response MUST include the appropriate error code as described in {{Section 2.4 of RFC8935}}. 207 | 208 | # Authentication and Authorization {#authn-and-authz} 209 | 210 | The Transmitter MUST verify the identity of the Receiver by validating 211 | the TLS certification presented by the Receiver, and verifying that 212 | it is the intended recipient of the request, before sending the SETs. 213 | 214 | The Transmitter MUST attempt to obtain the OAuth Protected Resource 215 | Metadata {{I-D.ietf-oauth-resource-metadata}} for the Receiver's multi-push endpoint. If such metadata is 216 | found, the Transmitter MUST obtain an access token using the metadata. 217 | If no such metadata is found, then the Transmitter MAY use any means to 218 | authorize itself to the Receiver. 219 | 220 | # Delivery Reliability 221 | A Transmitter MUST attempt to deliver any SETs it has previously attempted to deliver to a Peer until: 222 | - It receives an acknowledgement through the ack value for that SET in a subsequent communication with the Peer 223 | - It receives a setErrs object for that SET in a subsequent communication with the Peer 224 | - It has attempted to deliver the SET a maximum number of times and has failed to communicate either due to communication errors or lack of inclusion in ack or setErrs in subsequent communications that were conducted for the maximum number of times. The maximum number of attempts MAY be set by the Transmitter for itself and SHOULD be communicated offline to the Peers 225 | 226 | Additionally consider Delivery Relieability aspects discussed in {{Section 4 of RFC8935}} . 227 | 228 | # Conventions and Definitions 229 | 230 | {::boilerplate bcp14-tagged} 231 | 232 | 233 | # Security Considerations 234 | 235 | ## Too many SETs in the response 236 | Receiver MUST inform the transmitter (out of band) the maximum number of SETs that could be consumed in a single call. The Transmitter MUST obey the maximum number of SETs to be communicated to the receiver. This will avoid any potential truncations/loss of information at the receiver. 237 | 238 | ## Authentication and Authorization 239 | Transmitter MUST follow the procedures described in section {{authn-and-authz}} in order to securely authenticate and authorize Peers 240 | 241 | ## HTTP and TLS 242 | Transmitter MUST use TLS {{RFC8446}} to communicate with Receiver and is subject to the security considerations of HTTP {{Section 17 of RFC9110}}. 243 | 244 | Additional security consideration in {{Section 5 of RFC8935}}. 245 | 246 | # Privacy Considerations 247 | 248 | Privacy Considerations from {{Section 6 of RFC8935}} apply. 249 | 250 | # IANA Considerations 251 | 252 | This document has no IANA actions. 253 | 254 | 255 | --- back 256 | 257 | # Acknowledgments 258 | {:numbered="false"} 259 | 260 | TODO acknowledge. 261 | --------------------------------------------------------------------------------