Draft CORS guidance for an IVOA JSON protocol

[Markus Demleitner]

Hi Russ,

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

> When it comes to CSRF protection, though, I think registry support would
> only be needed for hypothetical x-www-form-urlencoded POST network
> encoding where there may be CSRF protection mechanisms that the client has
> to be aware of.

...or (probably rather): not use form-posting at all.

> The possibly-authenticated part, though, is a really good idea because
> portals will need to know whether they may need to send credentials to get
> full API access.  Although hopefully at least some of that will be obvious
> when they get a 401 response to an attempt to use some API.

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

> > * and 'In-Browser clients MUST perform pre-flight checks and do
> >   <whatever> when rr.interface.ward_off_csrf is 1.  They MUST NOT
> >   expect other intervaces to implement CSRF mitigation measures.
>
> I don't think we need to say this, and in fact I don't think it's a good
> idea to say this because it implies that someone implementing an astronomy

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

        -- Markus