Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SEP-6,12,24,31: allow omission of X-Stellar-Signature #1335

Merged
merged 3 commits into from
Jan 10, 2023
Merged

SEP-6,12,24,31: allow omission of X-Stellar-Signature #1335

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
a2d8095
SEP-6,12,24,31: allow omission of X-Stellar-Signature
JakeUrban Jan 10, 2023
846266e
add PR link to changelog
JakeUrban Jan 10, 2023
1101fd1
missed and->or for SEP-31 spec
JakeUrban Jan 10, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 7 additions & 6 deletions ecosystem/sep-0006.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,8 @@ Title: Deposit and Withdrawal API
Author: SDF
Status: Active (Interactive components are deprecated in favor of SEP-24)
Created: 2017-10-30
Updated: 2023-01-06
Version 3.17.0
Updated: 2023-01-10
Version 3.17.1
```

## Simple Summary
Expand Down Expand Up @@ -158,9 +158,9 @@ This protocol involves the transfer of value, and so HTTPS is required for all e

## Callback signature

This protocol involves the optional use of callbacks that the Anchor can issue to update the wallet on `status` of a transaction. In order to validate the integrity and provenance of the callback, the Anchor MUST include a signature in the HTTP Header `Signature` and `X-Stellar-Signature` (deprecated).
This protocol involves the optional use of callbacks that the Anchor can issue to update the wallet on `status` of a transaction. In order to validate the integrity and provenance of the callback, the Anchor MUST include a signature in the HTTP Header `Signature` or `X-Stellar-Signature` (deprecated).

Anchors and wallets should support both headers until the `X-Stellar-Signature` header is removed for the sake of ecosystem compatibility.
Wallets should support both headers until the `X-Stellar-Signature` header is removed from the specification.

These headers MUST follow the specification: `t=<timestamp>, s=<base64 signature>` where:
* __timestamp__ is the current Unix timestamp (number of seconds since epoch) at the time the callback is sent. This is used to assure the freshness of the request and to prevent this request to be replayed in the future.
Expand All @@ -173,7 +173,7 @@ It is the wallet's responsibility to:

### VERIFY signature

* Check that callback request has `Signature` and `X-Stellar-Signature` (deprecated) header
* Check that callback request has `Signature` or `X-Stellar-Signature` (deprecated) header
* Parse the header and extract:
* Key `t`: __timestamp__
* Key `s`: __base64 signature__
Expand All @@ -199,7 +199,7 @@ It is the wallet's responsibility to:
* The callback request body
* Sign the payload `<timestamp>.<host>.<body>` using the Anchor private key
* Base64 encode the signature
* Build the `Signature` and `X-Stellar-Signature` (deprecated) header:
* Build the `Signature` or `X-Stellar-Signature` (deprecated) header:
* `Signature: t=<current timestamp>, s=<base64 encoded signature>`
* `X-Stellar-Signature: t=<current timestamp>, s=<base64 encoded signature>`

Expand Down Expand Up @@ -1414,6 +1414,7 @@ If the information was malformed, or if the sender tried to update data that isn

## Changelog

* `v3.17.1`: Allow anchors to omit the deprecated `X-Stellar-Signature` header ([#1335](https://github.com/stellar/stellar-protocol/pull/1335))
* `v3.17.0`: Deprecate `X-Stellar-Signature` in favor of `Signature` ([#1333](https://github.com/stellar/stellar-protocol/pull/1333))
* `v3.16.0`: Add `refund_memo` and `refund_memo_type` to requests initiating transactions. ([#1321](https://github.com/stellar/stellar-protocol/pull/1321))
* `v3.15.0`: Add `lang` to `/transactions` & `/transaction` parameters, update format to [RFC 4646]. ([#1320](https://github.com/stellar/stellar-protocol/pull/1320))
Expand Down
13 changes: 8 additions & 5 deletions ecosystem/sep-0012.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,8 @@ Title: KYC API
Author: Interstellar
Status: Active
Created: 2018-09-11
Updated: 2023-01-06
Version 1.11.0
Updated: 2023-01-10
Version 1.11.1
```

## Abstract
Expand Down Expand Up @@ -509,7 +509,9 @@ POST [url from PUT request]
See [`GET /customer reponse`](#response) for the POST request fields.


In order to validate the integrity and provenance of the request, the Anchor MUST include a signature in the HTTP Header `Signature` and `X-Stellar-Signature` (deprecated). These headers MUST follow the specification: `t=<timestamp>, s=<base64 signature>` where:
In order to validate the integrity and provenance of the request, the Anchor MUST include a signature in the HTTP Header `Signature` or `X-Stellar-Signature` (deprecated). Wallets should support both headers until the `X-Stellar-Signature` header is removed from the specification.

These headers MUST follow the specification: `t=<timestamp>, s=<base64 signature>` where:
* __timestamp__ is the current Unix timestamp (number of seconds since epoch) at the time the callback is sent. This is used to assure the freshness of the request and to prevent this request to be replayed in the future.
* __base64 signature__ is the base64 encoding of the request signature. We explain below how to compute and verify this signature. The signature is computed using the Stellar private key linked to the `SIGNING_KEY` field of the anchor's [`stellar.toml`](sep-0001.md). Note that the timestamp and the Wallet hostname will be part of the signature to prevent replay and relay attacks.

Expand All @@ -520,7 +522,7 @@ It is the wallet's responsibility to:

### VERIFY signature

* Check that callback request has `Signature` and `X-Stellar-Signature` (deprecated) header
* Check that callback request has `Signature` or `X-Stellar-Signature` (deprecated) header
* Parse the header and extract:
* Key `t`: __timestamp__
* Key `s`: __base64 signature__
Expand All @@ -546,7 +548,7 @@ It is the wallet's responsibility to:
* The callback request body
* Sign the payload `<timestamp>.<host>.<body>` using the Anchor private key
* Base64 encode the signature
* Build the `Signature` and `X-Stellar-Signature` (deprecated) header:
* Build the `Signature` or `X-Stellar-Signature` (deprecated) header:
* `Signature: t=<current timestamp>, s=<base64 encoded signature>`
* `X-Stellar-Signature: t=<current timestamp>, s=<base64 encoded signature>`

Expand Down Expand Up @@ -667,6 +669,7 @@ All responses should return `200 OK`. If no files are found for the identifer us

## Changelog

* `v1.11.1`: Allow anchors to omit the deprecated `X-Stellar-Signature` header ([#1335](https://github.com/stellar/stellar-protocol/pull/1335))
* `v1.11.0`: Deprecate `X-Stellar-Signature` in favor of `Signature` ([#1333](https://github.com/stellar/stellar-protocol/pull/1333))
* `v1.10.0`: Clarify that the `account` and `memo` fields should be inferred from the decoded SEP-10 JWT's `sub` value even when not provided in the request body.
* `v1.9.1`: Callback signature: using expected host instead of HTTP Header to validate signature
Expand Down
13 changes: 7 additions & 6 deletions ecosystem/sep-0024.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,8 @@ Title: Hosted Deposit and Withdrawal
Author: SDF
Status: Active
Created: 2019-09-18
Updated: 2023-01-06
Version 2.9.0
Updated: 2023-01-10
Version 2.9.1
```

## Simple Summary
Expand Down Expand Up @@ -91,9 +91,9 @@ This protocol involves the transfer of value, and so HTTPS is required for all e

_Note that the signature discussed here is only for **URL callbacks** and does not apply to **`postMessage` callbacks**_

This protocol involves the optional use of URL callbacks that the Anchor can issue to update the wallet on `status` of a transaction. In order to validate the integrity and provenance of the callback, the Anchor MUST include a signature in the HTTP Header `Signature` and `X-Stellar-Signature` (deprecated).
This protocol involves the optional use of URL callbacks that the Anchor can issue to update the wallet on `status` of a transaction. In order to validate the integrity and provenance of the callback, the Anchor MUST include a signature in the HTTP Header `Signature` or `X-Stellar-Signature` (deprecated).

Anchors and wallets should support both headers until the `X-Stellar-Signature` header is removed for the sake of ecosystem compatibility.
Wallets should support both headers until the `X-Stellar-Signature` header is removed from the specification.

These headers MUST follow the specification: `t=<timestamp>, s=<base64 signature>` where:
* __timestamp__ is the current Unix timestamp (number of seconds since epoch) at the time the callback is sent. This is used to assure the freshness of the request and to prevent this request to be replayed in the future.
Expand All @@ -106,7 +106,7 @@ It is the wallet's responsibility to:

### VERIFY signature

* Check that callback request has `Signature` and `X-Stellar-Signature` (deprecated) header
* Check that callback request has `Signature` or `X-Stellar-Signature` (deprecated) header
* Parse the header and extract:
* Key `t`: __timestamp__
* Key `s`: __base64 signature__
Expand All @@ -132,7 +132,7 @@ It is the wallet's responsibility to:
* The callback request body
* Sign the payload `<timestamp>.<host>.<body>` using the Anchor private key
* Base64 encode the signature
* Build the `Signature` and `X-Stellar-Signature` (deprecated) header:
* Build the `Signature` or `X-Stellar-Signature` (deprecated) header:
* `Signature: t=<current timestamp>, s=<base64 encoded signature>`
* `X-Stellar-Signature: t=<current timestamp>, s=<base64 encoded signature>`

Expand Down Expand Up @@ -1021,6 +1021,7 @@ There is a small set of changes when upgrading from SEP-6 to SEP-24.

## Changelog

* `v2.9.1`: Allow anchors to omit the deprecated `X-Stellar-Signature` header ([#1335](https://github.com/stellar/stellar-protocol/pull/1335))
* `v2.9.0`: Deprecate `X-Stellar-Signature` in favor of `Signature` ([#1333](https://github.com/stellar/stellar-protocol/pull/1333))
* `v2.8.0`: Add `updated_at` to transaction records. ([#1329](https://github.com/stellar/stellar-protocol/pull/1329))
* `v2.7.0`: Add `refund_memo` and `refund_memo_type` parameters to withdraw endpoint. ([#1321](https://github.com/stellar/stellar-protocol/pull/1321))
Expand Down
13 changes: 8 additions & 5 deletions ecosystem/sep-0031.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,8 @@ Title: Cross-Border Payments API
Author: SDF
Status: Active
Created: 2020-04-07
Updated: 2023-01-06
Version 2.3.0
Updated: 2023-01-10
Version 2.3.1
```

## Simple Summary
Expand Down Expand Up @@ -846,7 +846,9 @@ POST [url from PUT request]

See the response to [`GET /transaction/:id`](#get-transaction) for the POST request fields.

In order to validate the integrity and provenance of the request, the Receiving Anchor MUST include a signature in the HTTP Header `Signature` and `X-Stellar-Signature` (deprecated). These headers MUST follow the specification: `t=<timestamp>, s=<base64 signature>` where:
In order to validate the integrity and provenance of the request, the Receiving Anchor MUST include a signature in the HTTP Header `Signature` or `X-Stellar-Signature` (deprecated). Sending Anchors should support both headers until the `X-Stellar-Signature` header is removed from the specification.

These headers MUST follow the specification: `t=<timestamp>, s=<base64 signature>` where:
* __timestamp__ is the current Unix timestamp (number of seconds since epoch) at the time the callback is sent. This is used to assure the freshness of the request and to prevent this request to be replayed in the future.
* __base64 signature__ is the base64 encoding of the request signature. We explain below how to compute and verify this signature. The signature is computed using the Stellar private key linked to the `SIGNING_KEY` field of the Receiving Anchor's [`stellar.toml`](sep-0001.md). Note that the timestamp and the Sending Anchor hostname will be part of the signature to prevent replay and relay attacks.

Expand All @@ -857,7 +859,7 @@ It is the Sending Anchor's responsibility to:

### VERIFY signature

* Check that callback request has `Signature` and `X-Stellar-Signature` (deprecated) header
* Check that callback request has `Signature` or `X-Stellar-Signature` (deprecated) header
* Parse the header and extract:
* Key `t`: __timestamp__
* Key `s`: __base64 signature__
Expand All @@ -883,7 +885,7 @@ It is the Sending Anchor's responsibility to:
* The callback request body
* Sign the payload `<timestamp>.<host>.<body>` using the Receiving Anchor private key
* Base64 encode the signature
* Build the `Signature` and `X-Stellar-Signature` (deprecated) header:
* Build the `Signature` or `X-Stellar-Signature` (deprecated) header:
* `Signature: t=<current timestamp>, s=<base64 encoded signature>`
* `X-Stellar-Signature : t=<current timestamp>, s=<base64 encoded signature>`

Expand All @@ -897,6 +899,7 @@ It is important to note that the Receiving Anchor is not obligated, at least by

## Changelog

* `v2.3.1`: Allow anchors to omit the deprecated `X-Stellar-Signature` header ([#1335](https://github.com/stellar/stellar-protocol/pull/1335))
* `v2.3.0`: Deprecate `X-Stellar-Signature` in favor of `Signature` ([#1333](https://github.com/stellar/stellar-protocol/pull/1333))
* `v2.2.0`: Add `refund_memo` & `refund_memo_type` to `POST /transactions` request. ([#1321](https://github.com/stellar/stellar-protocol/pull/1321))
* `v2.1.0`: Add the `refunded` status and updated the Detailed Receiving Anchor Flow. ([#1311](https://github.com/stellar/stellar-protocol/pull/1311))
Expand Down