OpenID challenge

[Mark Taylor]

Pat,

[I'm taking this to the GWS list for transparency, I take it you
 don't object, probably I should have done that in the first place]

If #tls-with-password has to define all those return type options,
then #BasicAA would have to do the same thing too.
Coupling the standard_id with the auth scheme like this mixes up
concerns in a messy way.

If you want to separate What and How, it would be cleaner to define
schemes:

   "ivoa_bearer" with params standard_id, access_url:
      get back a Bearer token in the x-vo-bearer header
      (at access_url, presenting user/pass as per standard_id)

   "ivoa_cookie" with params standard_id, access_url:
      get back a cookie in the usual way (set-cookie header)
      (at access_url, presenting user/pass as per standard_id)

   "ivoa_x509" with params standard_id, access_url:
      get back a certificate in PEM format in the body
      (at access_url, presenting user/pass as per standard_id)

and standard_ids:

   ivo://ivoa.net/sso#tls-with-password:
      submit username and password as POST params

   ivo://ivoa.net/sso#BasicAA:
      submit username and password as per RFC7617

OpenID defines both how to submit credentials (like standard_id)
and how to receive and use a token for subsequent authenticated usage
(like scheme) so it should have its own scheme:

   "ivoa_openid" with param access_url:
      do OIDC interaction in the usual way
      (at access_url)

Do you forsee other challenge types that we will need to define?

Seen like this, "standard_id" is not a very good name for "how to
supply username and password", something like "login_type" would
be better.

Mark


On Tue, 3 May 2022, Patrick Dowler wrote:

> I think you are right that the scheme can't really define the return, so
> we'll have to specify that #tls-with-password has these input form params
> and returns tokens like this (x-vo-bearer header), cookies like that
> (set-cookie header), and x509 proxy certs in pem format in the body (body
> because multi-line format).
> If we introduce a new scheme (type of returned credential) we'll have to
> augment what #tls-with-password says.
> 
> Then #OpenID also defines input and output (starting with appending the
> well-known path to the access_url and on from there).
> 
> 
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
> 
> 
> On Tue, 3 May 2022 at 09:00, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
> 
> > Pat (or Brian),
> >
> > I'm talking to Alberto about use of SSO_next at ESO.
> > There are some difficulties, which I'll probably bring to the mailing
> > list before too long, but I have a query to help me understand how
> > usage is currently envisioned.
> >
> > CADC services currently issue a challenge like this:
> >
> >    www-authenticate: ivoa_bearer standard_id="ivo://ivoa.net/sso#OpenID",
> > access_url="https://ws-cadc.canfar.net/ac"
> >
> > How do you envisage this being used, and in particular, how is the
> > token returned to the client?  My (possibly incorrect) understanding
> > of OpenID Connect is that it requires return of the token as a
> > JSON Web Token.
> >
> > SSO_next says
> >
> >    "The #tls-with-password standard defines the input (form params)
> >     and the challenge (ivoa_bearer) defines the output."
> >
> > but in the case of OpenID it seems that the standard_id
> > defines both the input and the output, so that the "ivoa_bearer"
> > scheme is not doing any work.  Then the scheme and standard_id
> > are not orthogonal, and the existence of such cases is why I was
> > resistant to organising the challenges in this way earlier in
> > the discussion.
> >
> > Have I got it right, or is the OpenID response required to include
> > the x-vo-bearer header as well as the JWT content?
> >
> > Mark
> >
> > --
> > Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
> > m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/
> >
> 

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