Suggestions/ideas/comments

[aragilar]

• Naming: You could call it "Authentication in the Virtual Observatory" with the shortname "Auth-VO"?
• One example that I think would be good to think about is how to handle a unauthenticated user requesting something that requires authentication/being a member of a group on a server which has both unauthenticated and authenticated access (e.g. private tables on TAP).
• RFC 9110 uses credentials for what is called "permits" in the document (at least from I can see, it's not clear if cookies/certificates are permits or not).
• I think for proxy authentication, the same rules apply as for www-authenticate, so we could add a comment to that effect (thought I'm not sure I've ever seen the proxy authentication used)?
• On OAuth 2/OIDC, I've not yet had time to write the implementation of what I presented at Malta (been busy with PhD, which is finally submitted), but if you want to use content from that (or leave that as a separate document), that's cool with me.
• I think copying out the standard-ids from SSO 2 makes sense, and you may want to consider how the less defined ones from SSO 2 (e.g. OAuth 2) would interact with the cookie/x509 challenges?

[mbtaylor]

Thanks for these comments @aragilar.

Naming: You could call it "Authentication in the Virtual Observatory" with the shortname "Auth-VO"?

Yes that would make sense and it's less opaque than e.g. IAP. I'll raise it for discussion at the Interop.

One example that I think would be good to think about is how to handle a unauthenticated user requesting something that requires authentication/being a member of a group on a server which has both unauthenticated and authenticated access (e.g. private tables on TAP).

Sections 4.1 and 4.2 are supposed to cover this territory. The example in sec 5.1 (Reactive authentication with HTTP Basic Auth) covers an unauthenticated user attempting to access a protected resource.

For the case of an unauthenticated user requesting a single resource having both unauth and auth options (with different content) - there is no provision for this in general. The response could be a 200 with challenges, but the document doesn't currently advise clients to follow this up by trying to authenticate.

The example in sec 5.2 (Optional authentication with cookies) is supposed to cover the case of a client talking to a service such as a TAP service, with optional authentication: it probes the authentication up front and may decide to authenticate; then it carries on communications with that service in authenticated mode.

Does that cover what you're thinking of? If so, maybe I haven't written the document clearly enough, suggestions/PRs for how to improve the explanation welcome.

RFC 9110 uses credentials for what is called "permits" in the document (at least from I can see, it's not clear if cookies/certificates are permits or not).

Credentials as defined in sec 11.4 of RFC 9110 is something more specific than what I'm calling permits, it seems to rule out cookies, and the credentials BNF includes the auth-scheme (which doesn't apply for cookies and certificates). So for what I'm calling permit I wanted something that didn't have an existing meaning, since I don't know of an existing term that covers the things I want to include here (token, cert, cookie, maybe encoded user+pass).

On the other hand I am using "credentials" to mean something specific (more or less: username+password, or at least something which the user, rather than a client operating on behalf of the user, could be expected to know) which is different from its sense in RFC9110 and elsewhere, so maybe that's confusing. Would it be better to come up with a different term for that, maybe something like "user-secret"?

I think for proxy authentication, the same rules apply as for www-authenticate, so we could add a comment to that effect (thought I'm not sure I've ever seen the proxy authentication used)?

I half-way convinced myself that this kind of interaction is not going to be useful for the case of proxy certificates, though I might be wrong. I'm a bit reluctant to write something about proxies here if we haven't seen it done. But if you disagree maybe you could come up with a suitable sentence or so.

On OAuth 2/OIDC, I've not yet had time to write the implementation of what I presented at Malta (been busy with PhD, which is finally submitted), but if you want to use content from that (or leave that as a separate document), that's cool with me.

My suggestion would be to leave it as a separate document for now, while people discuss and hopefully implement it. If it looks like it's something that people are actually doing or going to do for OAuth2, incorporate it here at that stage.

I think copying out the standard-ids from SSO 2 makes sense, and you may want to consider how the less defined ones from SSO 2 (e.g. OAuth 2) would interact with the cookie/x509 challenges?

The standard-ids that I've included here (BasicAA and tls-with-password) only require username+password and target URL to work, so they can stand on their own, assuming that the user has a username and password, which I think is a reasonable place to start. The others require something else (e.g. a cookie or certificate) that needs additional information to acquire, which is the problem that we're trying to solve with this login step; and in some cases (saml2.0, OpenID) it's not clear how you'd even use them to communicate for login. So unless/until I can see a specific details for how they can be used in this step, I don't think it's helpful to reference them in the document.

[aragilar]

Sections 4.1 and 4.2 are supposed to cover this territory. The example in sec 5.1 (Reactive authentication with HTTP Basic Auth) covers an unauthenticated user attempting to access a protected resource.

For the case of an unauthenticated user requesting a single resource having both unauth and auth options (with different content) - there is no provision for this in general. The response could be a 200 with challenges, but the document doesn't currently advise clients to follow this up by trying to authenticate.

The example in sec 5.2 (Optional authentication with cookies) is supposed to cover the case of a client talking to a service such as a TAP service, with optional authentication: it probes the authentication up front and may decide to authenticate; then it carries on communications with that service in authenticated mode.

Does that cover what you're thinking of? If so, maybe I haven't written the document clearly enough, suggestions/PRs for how to improve the explanation welcome.

So the case I was thinking of is you have a TAP service which has public data (say AllWISE) and private data (say LSST). It would seem to me you want to send back 200 (with www-authenticate) as unauthenticated users should be able to access AllWISE, but if the unauthenticated user tries to access LSST data (which isn't appearing in the publicly visible TAP_SCHEMA tables), should the TAP service:

1. send back 403 (as the user is not authenticated, but then the user knows that LSST is an option, which if it was for user uploads rather than a big project might reveal something that it shouldn't). You could always send back a 403 for any valid but non-existent tables, but I'm not sure if that would cause other issues
2. send back 401 (which has the same issues as the 403)
3. send back 400, which is correct in that it is a client error, but should the presence of www-authenticate suggest that authentication should be performed (in case the table is available).

I suspect this mixed case is going to be more common, so we (implementers of clients and servers) should agree on what we are sending in cases like this.

RFC 9110 uses credentials for what is called "permits" in the document (at least from I can see, it's not clear if cookies/certificates are permits or not).

Credentials as defined in sec 11.4 of RFC 9110 is something more specific than what I'm calling permits, it seems to rule out cookies, and the credentials BNF includes the auth-scheme (which doesn't apply for cookies and certificates). So for what I'm calling permit I wanted something that didn't have an existing meaning, since I don't know of an existing term that covers the things I want to include here (token, cert, cookie, maybe encoded user+pass).

On the other hand I am using "credentials" to mean something specific (more or less: username+password, or at least something which the user, rather than a client operating on behalf of the user, could be expected to know) which is different from its sense in RFC9110 and elsewhere, so maybe that's confusing. Would it be better to come up with a different term for that, maybe something like "user-secret"?

I think way I would express it is use "credentials" in the same way as RFC 9110, and explicitly state that "permits" is more general, and includes things like cookies and TLS client certificates?

I think for proxy authentication, the same rules apply as for www-authenticate, so we could add a comment to that effect (thought I'm not sure I've ever seen the proxy authentication used)?

I half-way convinced myself that this kind of interaction is not going to be useful for the case of proxy certificates, though I might be wrong. I'm a bit reluctant to write something about proxies here if we haven't seen it done. But if you disagree maybe you could come up with a suitable sentence or so.

Maybe the phrase "While the use of proxy-authenticate (and associated headers) with the additional authentication schemes is not forbidden by this document, there are no requirements placed on clients or services on their acceptance or use." would be enough?

On OAuth 2/OIDC, I've not yet had time to write the implementation of what I presented at Malta (been busy with PhD, which is finally submitted), but if you want to use content from that (or leave that as a separate document), that's cool with me.

My suggestion would be to leave it as a separate document for now, while people discuss and hopefully implement it. If it looks like it's something that people are actually doing or going to do for OAuth2, incorporate it here at that stage.

That sounds like a good plan. Hopefully I will have time by the November interop to have at least one server implementation (my plan is to make a dummy one that just serves out a fixed client id and secret, and a real one which connects to the Data Central authentication infrastructure to be able to mint per client ids and secrets) and a client implementation (either a dummy one in Python for testing, or something that can be integrated into pyvo), but we'll see if that happens.

I think copying out the standard-ids from SSO 2 makes sense, and you may want to consider how the less defined ones from SSO 2 (e.g. OAuth 2) would interact with the cookie/x509 challenges?

The standard-ids that I've included here (BasicAA and tls-with-password) only require username+password and target URL to work, so they can stand on their own, assuming that the user has a username and password, which I think is a reasonable place to start. The others require something else (e.g. a cookie or certificate) that needs additional information to acquire, which is the problem that we're trying to solve with this login step; and in some cases (saml2.0, OpenID) it's not clear how you'd even use them to communicate for login. So unless/until I can see a specific details for how they can be used in this step, I don't think it's helpful to reference them in the document.

How about something like "The standard_ids ivo://ivoa.net/sso#tls-with-certificate and ivo://ivoa.net/sso#cookie are replaced by the above challenges, and hence cannot be used in challenges. The lack of clarity on how the challenge should be completed as part of the standard_ids ivo://ivoa.net/sso#OAuth, ivo://ivoa.net/sso#saml2.0 and ivo://ivoa.net/sso#OpenID means that these standard ids also cannot be used."?