OpenID challenge

[Mark Taylor]

On Mon, 9 May 2022, Paul Harrison wrote:

> 
> > On 2022-05 -09, at 13:13, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
> > 
> > Service providers (e.g. ESO?) that are only willing to serve data to
> > users authenticating via browser-based flows won't use these ivoa_*
> > schemes at all. Those (e.g. CADC?) who are willing to accept a
> > username+password acquired by a non-browser client can use these
> > schemes in order to give clients enough information to supply them.
> 
> 
> Then CADC are going to have to do something different on the server side for browsers and non-browsers and you as TOPCAT author have to support both, so from a software author’s point of view, I do not see where the win is.
> 
> I don’t have a strong objection to the proposal, but the “market forces” behind AAI mean that the prevailing way of doing things will have to be supported whatever standards the IVOA comes up with.

I as topcat author may not support both.  If the browser-based
authentication flow is sufficiently onerous (either for client
implementors or for client users) maybe desktop clients like topcat
just won't support those services in authenticated mode - as has
been the case up till now.

Till now, non-browser clients such as python and the shell have
mostly got by with non-browser-based authentication that relies
on specialised knowledge (buried in per-service user documentation)
about where to go to submit initial authentication to obtain a
cookie or token; see e.g.:

   https://www.cosmos.esa.int/web/gaia-users/archive/programmatic-access#Command_Sect2
   https://archive.eso.org/cms/eso-data/programmatic-access/authentication-and-authorisation.html

The purpose of this proposal is to codify that specialised knowledge
so that clients can perform authentication along those lines without
a user having to find the right web page and paste in relevant
per-service URLs.

If VO service providers mostly or all decide that such arrangements
are unacceptable and that desktop clients must use browser-based
flows in order to authenticate, then yes some of these details
won't be much use.  However, even in that case and supposing I'm
prepared to implement a browser-based flow, as a client author
I still don't know how to go from a bare "www-authenticate: bearer"
challenge to finding out where I can go to get a suitable bearer
token, so I still don't know how to offer the user a browser-based
authentication flow.  Are there standardised rules about redirection
flows that could enable me to work that out?

Mark

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