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