motivation for SSO_Next custom www-authenticate: {auth-scheme}

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Mon Nov 18 19:23:02 CET 2024


Hi Paul (and Mark),

Two brief interjections from the Registry side of this matter:

On Mon, Nov 18, 2024 at 03:46:29PM +0000, Paul Harrison via grid wrote:
> > On 18 Nov 2024, at 15:17, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
> >> This is a more compelling reason on the face of it, but if you
> >> accept my initial premise that services should not be handing
> >> out datalink references to protected URLs outside their security
> >> domain, then this can also be solved by the datalink response
> >> containing the ivorn of the service that produced the datalink
> >> response.
> >
> > Where?  As it stands the DataLink response table has no column
> > for such an ivorn.

(a) Please don't say IVORN; while we wrote Identifiers 2, we tried to
figure out what that might be and couldn't find a meaning that would
actually make sense.  So: it's IVOID (or ivoid if you prefer; we're
talking to humans, and so a certain amount of case insensitivity is
fine even with me) throughout.

(b) We don't *have* a way to attach information on Authn requirements
in the Registry at this time either, and for now we have largely
given up on defining any.  So, before we think about...

> If the mechanism does not exist yet it could be added, but the
> service self description
> https://www.ivoa.net/documents/DataLink/20231215/REC-DataLink-1.1.html#tth_sEc4.4
> would seem to be the place. The example shown does not have the

...going this way, we'd first have to say at least *what sort* of
information clients would find when resolving the IVOID.  I'm happy
to cast any sensible plan into the VOResource schema, but so far I
don't even know what to cast.

          -- Markus



More information about the grid mailing list