Implement RFC 9540 #47
Conversation
|
Opened as draft because of the breaking nature of this change, and in case #46 is rejected in which case this should be rebased to not depend on it. |
There was a problem hiding this comment.
Do I understand correctly that if #46 is merged as well as this PR, the changes will not break our practical use of this relay implementation in the wild that we're aware of?
Or is your preference not to support both /ohttp-keys AND this change?
#46 should be fine to merge for the stated reason. However, this PR will break unless the payjoin-directory is also updated (2nd commit of payjoin/rust-payjoin#530 which I will shortly make into its own separate PR).
Actually I think we should support both at least for some transition period as it's just 2 lines in the code, and because the ohttp-keys endpoint is depended on not just by the ohttp-relay but also payjoin receivers. I did remove support for it in payjoin/rust-payjoin#530, but only for testing purposes. |
nothingmuch
force-pushed
the
rfc-9540
branch
from
c70c91d to
a736c5f
Compare
nothingmuch
force-pushed
the
rfc-9540
branch
from
a736c5f to
7f07cf8
Compare
There was a problem hiding this comment.
utACK 7f07cf8
This requires a change to payjoin-directory to use this gateway uri order to work. Our payjoin-directory change must be backwards compatible, and then once we're convinced ohttp-relays have updated we can roll out a payjoin-directory that removes the backwards compatibility.
nothingmuch
force-pushed
the
rfc-9540
branch
3 times, most recently
from
cdb6b6a to
3f22f93
Compare
Use a non optional Scheme & Authority for representing the internal state, instead of a Uri which may be relative, and may contain a path. Authority is normalized to have an explicit port, as before. Resolution of authority to a socket addr is now async, to avoid blocking while waiting for host resolution, in anticipation of gateway opt-in allowing adversary chosen hostnames to be resolved which may be a DoS concern. Closes payjoin#51.
RFC 9540 specifies a standard location (/.well-known/ohttp-gateway) for the OHTTP gateway, where the keys can be fetched with a GET request and OHTTP requests to the target resource can be POSTed.
Note: This is a breaking change, and requires directory support for RFC 9540 as well.
This change modifies the relay to assume that both the the OHTTP gateway
and the ohttp keys reside at /.well-known/ohttp-gateway, with POST
requests implementing the OHTTP gateway functionality and GET requests
fetching the OHTTP keys.
Extends #46, but does not strictly depend on it.
Depends on #53