Add Open Payments auth server discoverability

[matdehaast]

Currently the incoming/outgoing payment urls are inferred via the URL pattern. An example is the following IP

https://ilp.rafiki.money/mattusd/incoming-payments/a4885cd0-2318-468b-9194-4b30787c4ddd

Assume a payment pointer URL of https://ilp.rafiki.money/mattusd

Removing the coupling does present a problem, in that clients need to know where the auth server is for resources. GNAP has a spec to define RS first discovery

[sabineschaller]

Duplicate of

• https://github.com/interledger/rafiki/issues/1897 ?

I think this is already being worked on by @njlie and @BlairCurrey.

[mkurapov]

@sabineschaller @njlie @BlairCurrey I think we need a separate issue to "include resourceUrl in the wallet address response", right?

[sabineschaller]

That we do indeed.

[sabineschaller]

I get the issue now. Let's get that one worked on!

[njlie]

So uh...it looks like we already implement this. We could return this header on the unauthenticated GET /incoming-payments response, though - it is an unauthenticated request to a GNAP resource, after all.

[sabineschaller]

Yes please. Let's add the header to all unauthed requests, wether they are successful or return 401. So that means public incoming payment and wallet address. Should we then also roll back the inclusion of the auth server url in the body of the public incoming payment? Like roll that back right away and get the auth server url from the header in the receiver service?

[njlie]

On the heartbeat call, we discussed rolling back the authServer field in the unauthenticated GET /incoming-payments response body. We decided to keep it in the body, so it's more straightforward for the Open Payments client to retrieve and return that field and avoid some type breakage with having to return a header. Will still add the header so the endpoint behaves in a GNAP-y way.