SSO major editing

[Markus Demleitner]

Dear Sara and GWS,

On Tue, May 07, 2024 at 03:54:03PM +0100, Mark Taylor via grid wrote:
> [TL;DR: I suggest even more radical reform of the SSO document]

I have prepared a few editorial changes, for which I have just opened
a PR (and I'd volunteer to update the architecture diagram in that
PR, too, if you want), but I have to say I largely agree with Mark's
points and thus I'll let this sit in its somewhat unfinished form for
now (and feel free to just close the PR, in particular if we do
Mark's even more radical reform).

While going through the document, I had also jotted down a few review
comments:

Disclaimer: I've always maintained a healthy distance from proper
cryptography, and I have done virtually no thinking about whether
certain regulations increase the attack surface; x-vo-authenticated,
for instance, feels potentially dangerous.  Perhaps we should solicit
a few more opinions whether that's indeed harmless.  Also... What's
the use case for letting people discover who they are?

On having SecurityMethod in the Registry (mainly mirroring Mark's
concerens)... I do believe being able to say "you have to have
credentials to use this service" is a valid use case, although mainly
as inverting it to "give me only open services".  To cover this use
case, however, 3.3 needs to say "Services not offering public
interfaces MUST include SecurityMethod elements".

I can't see a big case for saying just which authentication methods
are supported -- what use case would that cover?  I *would* see a big
case for being able to figure out "what services can I use with my
credentials from IdP X?"  But that probably goes quite a bit beyond
what we can do, at least at this point.

So... I think we should clearly state the use case ("to allow users to
filter out services requiring authentication...") in 3.3, and then
perhaps say "giving one of the available authentication methods is
optional and probably not useful".  I'm pretty sure we don't want
multiple SecurityMethod-s per interface or even multiple interface
element with the same access URL and different SecurityMethod-s; the
benefit of knowing these methods is just too low.

I hope I've not sounded too negative -- I'm really grateful that you
tackle this document, and I'm happy to contribute whatever I can to
SSO-reform (but realistically, I'm afraid that'll mainly be the
Registry aspects...)

Thanks,

          Markus