Discovery by Email, Domain, or entityID

[Peter Schober]

* Nate Klingenstein <ndk at signet.id> [2019-08-08 17:43]:
> I otherwise concur with everything Peter wrote, but I don't think
> we're going to be able to teach users how to type in a URL, whereas
> they naturally use their email address as their username even on
> consumer sites now.

To be fair though noone ever (AFAIR, but you've been at this longer
than I have) suggested that discovery be done by having subjects enter
URLs (I'm guessing you mean entityIDs, from the email's subject).

Mapping "something you know about your institution" (parts from
display name, DNS-domain, keywords, whathaveyou) to something unique
(that allows to initiate SSO using some protocol) works the same way
independent of input, so if anything we're currently being more
flexible and more accomodating by not insisting on email addresses as
the only format (and more sensible in avoiding PII early on, of
course).
And our discovery services could easily be taught to work from an
email address just as well (by looking for matches in the RHS/domain
portion of the email address) for those already shaped by
commsumer-space experiences.

Personally I'd be interested in feedback and possible contributions to
this community's (or communties') best current option, which I think
is https://thiss.io/ (or whatever comes out of RA21), either as
software or as service.

I don't claim to understand how it works (or how using HTML5
localStorage for storing previously used IDPs can work around
same-site issues that require a common DNS domain for cookies to work)
but I don't consider the information what IDPs I used in the past to
be PII and so I wouldn't care about storage that much either way, not
even on an central service.
(Not that I ultimately /want/ a central service or care about sync'ed
disco memory all that much, but if it works -- and the demos and UIs
are beautiful, if you ask me -- it may well be preferable to most
alternatives.)

-peter