OpenID challenge

[Mark Taylor]

If you agree, I can draft a PR setting this out as an update
for the text in the current Section 2.1.

On Wed, 4 May 2022, Mark Taylor wrote:

> 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/
> 

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