Draft CORS guidance for an IVOA JSON protocol

[Markus Demleitner]

Hi Russ,

On Tue, May 28, 2024 at 10:08:09AM -0700, Russ Allbery via grid wrote:
> Markus Demleitner via grid <grid at ivoa.net> writes:
> > On Mon, May 27, 2024 at 09:27:49AM -0700, Russ Allbery via grid wrote:
> > 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.

Oh, but we don't.  There has been attempt to do that in TAP 1.1
drafts, but it turned out to be extremely painful to do, and actually
fundamentally flawed in some respect.  Hence, TAP 1.1 retained the
registration pattern established in 1.0, i.e., a common interface
declared with the "base" access URL.  The main thing that's wrong
with it is that this interface is typed vs:ParamHTTP, which is
semantically wrong (but in a way that does not hurt us much).

A bit more on the history of this is in
<https://wiki.ivoa.net/internal/IVOA/InterOpMay2019Reg/caproles.pdf>,
and there is a note on the wider vicinity of that issue that I wish
got more attention: <http://ivoa.net/documents/caproles/>.

Conceivably, having two different *interfaces* may be a good idea, in
particular because json-POST probably does not fit very well with the
semantics of vs:ParamHTTP; but I'd much rather think about letting
both run on the same endpoint for starters and see if it becomes too
ugly.

> 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.

*That* is something I would like to avoid, because it would lock out
legacy clients without a good reason.  As you say, form-posting only
is a problem for in-browser clients, and I think a solution where
only they would need to worry about CSRF (and hence shun
form-posting) would be highly preferable.

> 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?

SODA is still a different issue, because it (currently, but largely
by its nature) is not registry-driven.  Clients will only encounter
SODA because of information left by the data provider in the VOTables
returned from a Datalink endpoint (or a Datalink block in a result
set, but I wish we'd never have specified that).

There, we currently do not have a way to convey anything but
form-posting (or GET) access URLs.  On the other hand, that is
probably a particularly low-hanging fruit because the only standard
involved would be Datalink.  Perhaps that's where we should start
prototyping JSON-posting?

> >   "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

Well... it's more that I am convinced we need to keep requiring
form-posting; it's really not much effort to implement, and it will
ensure that we don't end up with a VO where some services only work
with client A but not client B, and others only with client B but not
client A. At the moment, this kind of thing only happens when there's
bugs.  Writing the standard in a way that standards-compliant
behaviour could lead to it seems unwise to me.

> 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.

It sounds as if your preferred CSRF mitigation is JSON-posting.  If
that is so, then let's not confuse the situation by creating a third
option.

Thanks,

             Markus