standard_id value namespace

[mbtaylor]

In the current draft, information about how to interact with the login access_url is given by the standard_id challenge parameter. Permitted values in the initial draft are

• ivo://ivoa.net/sso#BasicAA
• ivo://ivoa.net/sso#tls-with-password

These are taken from from the document SSO 2.0, see for example SSO 2.0 Sec 3.1. There are a few issues with this.

1. SSO doesn't associate the required semantics with URIs, for instance it doesn't give details of how to supply a username and password with tls-with-password. So these semantics have to be supplied by this document not by SSO.

2. We may need to define some additional options for the standard_id parameter, for which SSO may not have defined suitable values. If we wanted them all to be in the SSO namespace it would really involve revising SSO, which is otherwise IMO not providing much of use to the standardisation of authentication in the VO.

3. It looks to me like the URIs in the text of SSO and used in the current draft of this document are all wrong anyway. They are all fragments within the URI ivo://ivoa.net/sso, and that URI has no registry record. I think they should be fragments within ivo://ivoa.net/std/sso instead. Can some registry expert like @msdemlei confirm?

Given all this, I think it would make more sense to define the standard_id values within the IAP document itself rather than calling out to a different standard (which should, really, have errata to make it correct for this purpose).

There are some existing service and client implementations using the current values, which would complicate such a change, but since there's not so far all that much usage (service implementations at two sites, client implementations in one library) it could be done without all that much pain.

Opinions?

[msdemlei]

On Mon, Jun 02, 2025 at 03:21:43AM -0700, Mark Taylor wrote: 3. It looks to me like the URIs in the text of SSO and used in the current draft of this document are all wrong anyway. They are all fragments within the URI `ivo://ivoa.net/sso`, and that URI has no registry record. I think they should be fragments within `ivo://ivoa.net/std/sso` instead. Can some registry expert like @msdemlei confirm?

Well... the id is just a string. That we register our standards as ivo://ivoa.net/std/<short name> is a convention that, for all I can remember, has no normative source. If the standard says its identifier is ivo://ivoa.net/sso then, I think, we should just create that record and be done with it. I'd volunteer to create it if the DSP WG asks me to. Perhaps we should describe the problem on their mailing list?

Given all this, I think it would make more sense to define the standard_id values within the IAP document itself rather than calling out to a different standard (which should, really, have errata to make it correct for this purpose).

I have no strong feelings about *which* StandardsRegExt record the standardIds reside in. But I am fairly strongly convinced that SSO and and IAP shouldn't have two different ids for the same thing, and I'd prefer if IAP didn't muck around in SSO's StandardsRegExt record (but that's a weaker sentiment).

There are some existing service and client implementations using the current values, which would complicate such a change, but since there's not so far all that much usage (service implementations at two sites, client implementations in one library) it could be done without all that much pain.

Probably, but I think accepting a StandardsRegExt record with a slightly unconventional identifier is even less painful.

[mbtaylor]

If the standard says its identifier is ivo://ivoa.net/sso then, I
think, we should just create that record and be done with it. I'd
volunteer to create it if the DSP WG asks me to. Perhaps we should
describe the problem on their mailing list?

The standard text doesn't explicitly say its identifier is ivo://ivoa.net/sso or anything else, but it does refer to a number of keys in that namespace. However there is a registry record for ivo://ivoa.net/std/sso, and there is not one for ivo://ivoa.net/sso. So it would be a case of moving or duplicating the existing StdRegExt record, not just creating a new one, if we wanted to legitimise those URIs. Though I suppose they could just be opaque strings that happen to look a bit like IVO-IDs.

I have no strong feelings about which StandardsRegExt record the
standardIds reside in. But I am fairly strongly convinced that SSO
and and IAP shouldn't have two different ids for the same thing, and
I'd prefer if IAP didn't muck around in SSO's StandardsRegExt
record (but that's a weaker sentiment).

"The same thing" is a bit arguable - ivo://ivoa.net/sso#BasicAA probably does mean just the same in both places, but while ivo://ivoa.net/sso#tls-with-password refers to something similar in both places, more needs to be said in IAP (details of how username and password are transmitted) than what's present in SSO.

[msdemlei]

On Wed, Jun 11, 2025 at 01:38:29AM -0700, Mark Taylor wrote: mbtaylor left a comment (ivoa-std/AuthVO#7) The standard text doesn't explicitly say its identifier is `ivo://ivoa.net/sso` or anything else, but it does refer to a

No, it wouldn't. No standard does that.

number of keys in that namespace. However there is a registry record for `ivo://ivoa.net/std/sso`, and there is not one for `ivo://ivoa.net/sso`. So it would be a case of moving or duplicating the existing StdRegExt record, not just creating a new one, if we wanted to legitimise those URIs. Though I suppose they could just be opaque strings that happen to look a bit like IVO-IDs.

If there are no references to ivo://ivoa.net/std/sso anywhere, I'm all for moving the record (and hence delete the std/sso one). And no, if there is an ivo:// in front of a string, we should try hard to make it an ivoid.

"The same thing" is a bit arguable - `ivo://ivoa.net/sso#BasicAA` probably does mean just the same in both places, but while `ivo://ivoa.net/sso#tls-with-password` refers to something similar in both places, more needs to be said in IAP (details of how username and password are transmitted) than what's present in SSO.

This sounds to me like a case of "close enough to be even more confusing when there are two identifiers".

[mbtaylor]

If there are no references to ivo://ivoa.net/std/sso anywhere, I'm
all for moving the record (and hence delete the std/sso one).

No objection from me, though I don't know how to be sure there are no references to the existing record. I'm pretty sure there are none in SSO itself.