Rename ivo://ivoa.net/std/sso to ivo://ivoa.net/sso?

[Patrick Dowler]

On Mon, 16 Jun 2025 at 04:23, Markus Demleitner via dsp <dsp at ivoa.net> wrote:
> We *could* fix this by changing the standard and make it say, for
> instance, ivo://ivoa.net/std/sso#saml2.0.  But that's really a
> breaking change, because string comparisons that clients would use to
> figure out with auth they could use will no longer match.  I don't
> think there are too many of those, but I've been wrong on such takeup
> estmates before.

We've used these identifiers (securityMethod in capabilities and in
related SSO-next www-authenticate headers) and this kind of fix would
essentially be:
- we include both forms in capabilities and headers for some period of time
- we update some constants in a library to use the new form
- we rebuild a lot of server side code and redeploy (well, this
happens frequently enough that maybe we don't do it explicitly)
- we update client code (astropy.cadc and other places) that we know about
Usually at this point we wait for users to upgrade clients, but it is
hard to make them do it before we break something and other than
knowing which versions of which clients look for the new identifiers
we can't actually tell from any requests that the old/incorrect one is
being used or not.

Still, fixing the standard does seem overly painful and we'd probably
leave the backwards-compat identifiers there forever because no one
would want to pull them.

On the other hand, what does it mean in the future that a standard
kind of squats on the root of the ivo://ivoa.net/ namespace with it's
short name? What other top-level paths are used (other than "std") in
the ivoa.net authority that we need to consider?



--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada