Draft CORS guidance for an IVOA JSON protocol

[Russ Allbery]

Markus Demleitner via grid <grid at ivoa.net> writes:
> On Mon, May 27, 2024 at 09:27:49AM -0700, Russ Allbery via grid wrote:

>> BTW, I wasn't sure whether this was obvious, but the above work *only*
>> has to be done on the server side.  The client side doesn't need to do
>> anything at all.

> Well, if we want to outlaw form-posting *where CSRF may be an issue",
> they do: They need to avoid form-posting interfaces for these and use
> something else.

Oh, I see.  Hm, I think I would handle that at a different layer, because
in my mind the JSON-based protocol and the x-www-form-urlencoded POST
protocol are two different protocols that should be advertised separately
in the registry, similar to sync and async.

If a given IVOA service advertises (via the registry) the JSON protocol
but not the x-www-form-urlencoded POST protocol, then a browser-based
client will need to use the JSON protocol.

In other words, can we use the registry for this type of protocol
negotiation the same way that we use it now to discover whether sync or
async are supported for protocols like SODA?

> Oh, for *that* part we've been moving away from the Registry towards
> service-side negotiation.  You're probably aware of this, but in case
> anyone is not, see what Mark has reported on "SSO_next" in Tucson:
> <https://wiki.ivoa.net/internal/IVOA/InterOpNov2023Apps/auth.pdf>.

Sure, but my point is that it still seems like a good idea to flag this in
advance in the registry so that clients and humans are aware that an
account may be needed for some operations without having to try them
speculatively.

> Oh, right.  Can I pretend I just mistyped things and I had really wanted
> to write:

>   "In-Browser clients MUST use <newly specified JSON-magic> on
>   interfaces for which ward_off_csrf is 1 and MUST NOT form-post.
>   On other services, they MAY try <JSON-magic>, but they MUST fall
>   back to form-posting if the former is not available."

I feel like letting archives register which of the JSON-based and
x-www-form-urlencoded POST protocols they implement achieves the same
thing in a somewhat more straightforward way, but maybe I'm missing
something.  The logic is then the same for all clients, browser-based or
not: if only JSON is supported, you have to use JSON; if only
x-www-form-urlencoded POST is supported, you have to use that; and if both
are supported, you can choose.

The remaining gap is whether there are two variations of
x-www-form-urlencoded POST: the current protocol and a revised one that
fits into the encoding profile framework that we've been talking about and
that may have some sort of CSRF protection mechanism available.

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>