Rename ivo://ivoa.net/std/sso to ivo://ivoa.net/sso?
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Mon Jun 16 13:22:34 CEST 2025
Dear DSP WG,
Mark Taylor noticed a problem with your SSO standard
<https://ivoa.net/documents/SSO/20170524/REC-SSOAuthMech-2.0.html> --
benign in some sense, but nevertheless a problem. You see, the
document assigns IVOA identifiers to various authentication methods.
For instance, one such identifier reads
ivo://ivoa.net/sso#saml2.0
While clients can live with this opque (modulo, sob, case) string as
is, as an IVOID, it is to some extent actionable: you can resolve
ivo://ivoa.net/sso in the Registry, and you will get back a
StandardsRegExtDocument with a StandardKey saml2.0; this allows you
to (a) see whether this is a valid identifier (or else you'll get a
404 or won't find the standardsKey) and (b) find some documentation
about what that key means (a description).
The only trouble is that the sso identifiers are not (actionable):
ivo://ivoa.net/sso does not resolve.
It is also of an unusual form for a standards identifier; by VO
convention, these start with ivo://ivoa.net/std/. Indeed,
ivo://ivoa.net/std/sso does exist:
<http://dc.g-vo.org/I/ivo%3A//ivoa.net/std/sso>. And it actually has
the key saml2.0 with the description
Service supports authentication via SAML (most likely,
"Shibboleth") as per section 9 of the Recommendation.
So, the registry and the SSO standard are in contradiction with each
other.
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.
The alternative would be to just move the registry record to match
the ivoids mentioned in the the SSO document. I'm not aware of
anything that would require IVOA standards to have a "std" in their
identifiers (StandardsRegExt
<https://ivoa.net/documents/StandardsRegExt/20240125/PR-StandardsRegExt-1.1-20240125.html>
has not, for one. But while I'm speaking let me point out that there
is currently an RFC open on it, so please have a look at it and
comment
<https://wiki.ivoa.net/twiki/bin/view/IVOA/StandardsRegExt11RFC>).
I would certainly prefer the latter.
Does anyone here expect trouble when we do that renaming? That
would, for instance, possibly be the case when some deployed
technology relies on std/sso#whatever IVOIDs. Does anyone know such
a thing? Frankly, even then there probably won't be operational
consequences, but since we're out to make the world a somewhat tidier
place, making it uglier somewhere would count as a showstopper.
If I don't hear from anyone, I'd go ahead and ask the RofR to do the
move next week or so.
Thanks,
Markus
More information about the dsp
mailing list