SSO major editing

[Mark Taylor]

Dear Sara and GWS,

[TL;DR: I suggest even more radical reform of the SSO document]

thank you for starting this revision.  I've read through the
document and although it does include some of the new content
required from the SSO_next wiki page there are several things
I disagree with, for instance:

   - Contrary to section 3.1.1 the standard_id parameter for
     challenges is not intended to contain the (SecurityMethod) ID
     for the SSO authentication mechanism; instead it identifies
     the bootstrapping method for the authentication mechanism in
     question, which is currently one of "tls-with-password" or
     "BasicAA" regardless of the authentication mechanism itself.
     (I've argued before that the name "standard_id" is not very
     helpful for this item, but it is by now in place in working 
     services so should not be changed).

   - In view of the previous point, I don't think that the
     SecurityMethod identifiers are doing useful work, so I'd say
     that they can indeed be retired.

   - Use of the ivoa_bearer challenge should not be recommended for
     now, since we don't know how to specify the scope of the
     returned token, rendering this option intrinsically insecure.

   - The HTTP Basic Authentication challenge example in Sec 4.1 is
     mixing bearer tokens and BasicAA.  BasicAA should instead be
     done purely according to RFC7617, no VO customisation required.

   - The with-parameters variant of the TLS-with-client-certificate
     challenge in Sec 4.3.1 has to explain how the certificate
     is returned in the HTTP response.

   - A number of the authentication challenges listed in Sec 4
     (ivoa_saml, ivoa_bearer, ivoa_openid) are listed without 
     really saying how they would work, i.e. what the challenge 
     responses would be; it's not clear to me how/whether they 
     would work at all.  Given the subtleties we've encountered 
     with the challenge types that we have experimented with,
     I'd argue that none of these should be included until we
     have a prototype working service or at least a much clearer
     idea of what the client-server interaction would look like.

My personal feeling about the SSO document up till now is that 
there's quite a bit of text that's not serving much purpose.  
It contains a list of auth technologies "approved for use in the 
IVOA-SSO profile", but since these don't have to be interoperable, 
I don't see the purpose of constraining the list in this way, 
or of discussing them in a VO standard.  These sections also come
with some "commentary", but IMHO there is little useful information in 
there, since they reference back to the original (e.g. IETF) standards.

So I think the scope of this document should be reconsidered.
We no longer require the SecurityMethod definitions, having
decided that this is not a Registry matter.  And I don't see much 
point in providing an "approved" list of web-based technologies 
for authentication.

What we do need is the description of how to initiate authenticated
access to VO services from non-browser clients, since there are in 
general not standards on the wider internet about how to do this.
That is more or less the scope of what's written in the SSO_next wiki 
page, though the text there is somewhat out of date; I claim that the 
standards text we really require in this area is basically what I 
presented on the pages labelled (bottom right) 3, 4 and 6 of my Apps
presentation from Tucson:
https://wiki.ivoa.net/internal/IVOA/InterOpNov2023Apps/auth.pdf

So I make the provocative suggestion that the SSO document should be
rewritten more or less from scratch, including some but not much text
from its current form, describing only(?) how non-browser clients
can interact with authenticated services in a VO-standard way.
It should describe in detail how such interaction works,
but only for those authentication methods where we actually
understand how to do it (currently: BasicAA, cookies and X.509
certificates; hopefully bearer tokens will be added at some point).
The document would perhaps acquire a new name or become a different
document in the process.  If GWS agrees this is a good way forward,
I'm willing to draft such a document.

I am aware that this suggestion is highly oriented to the requirements
of TOPCAT/me (as well as other non-browser clients like PyVO).
But I don't currently see what else we need in terms of VO-specific
standardisation in this area.  If you have examples of such things,
please disagree with me!

Mark

On Fri, 3 May 2024, Bertocco, Sara via grid wrote:

> Hi all and particularly SSO authors,
> I did a major editing of the single sign-on document re-organizing it and
> proposing some content. I would like to have your comments and input.
> Because it is really work in progress, I left it in a fork with a dedicated
> branch in
> https://github.com/bertocco/  branch major_editing
> Trying to make easier read and comment, I put my comments and things that
> need attention in red and here I summarise the main changes:
> 1) The arguments order is changed: before the accepted authentication
> mechanisms, then bootstrapping and ivoa-challenge and then how to use them
> all with examples (trying to address issue #6). Examples need a deep review
> and, possibly, contributions.
> 2) I specified well that OAuth is an authorization and not authentication
> protocol (issues #7 and #8) and how it is used
> 3) I did not remove SecurityMethod (as I proposed in issue #5) because I
> used it to indicate the standard_id and left, as optional (MAY), the
> possibility to register a service declaring the supported SecurityMethod.
> This accepts the Brian's comment in Issue #5 to support a transition period.
> 4) Has to be decided if the ivoa-challenge MUST or SHOULD be implemented.
> Someone proposed SHOULD, to allow a smooth transition to the new version of
> the standard and I agree and put SHOULD, by the moment.
> By the moment, I'm sending this e-mail to the GWS list.
> If someone is interested, let me know and I'll try to arrange an on-line
> meeting before the Sydney interop.
> Cheers, Sara
> Cheers, Sara
> 

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/