"Password leak at Elsevier"
Jorj Bauer
jorj at temple.edu
Mon Apr 1 12:42:55 EDT 2019
> * Steven Carmody <steven_carmody at brown.edu> [2019-03-29 20:54]:
>> There was an early Shib Use Case that described sending a persistent
>> opaque identifier to these sites; the publisher would recognize the
>> user across multiple sessions but wouldn't know who the person
>> is. That was intended to avoid this exact situation.
Then the second thing we hear is "but we need an email address and
<opaque_identifier>@temple.edu bounces." Because every scoped attribute
looks like an email address. And then: if I'm giving out an email
address, I've lost the opacity I was looking for initially.
I'd love to have more voice in getting real-world systems to stop
expecting any scoped attribute to be an email address. And I'd love to
have more real-world systems that don't expect email as a communications
vehicle. In practice I have no idea how to approach either of those.
> So this may well become more common in the future, possibly to the
> point of becoming the only way to use many of those services that
> traditionally could be used pretty much anonymously.
That's a concern of mine, too. I'm glad to see it getting a little
exposure on-list.
A related train of thought that's been playing out in discussions here:
Fundamentally, we rely on InCommon to identify "bad actors" and prevent
them from joining the federation, so we can use membership in the
federation as a mitigating control against bad actors, so that we don't
release information about people to bad actors.
From a technology perspective, this feels like a very nascent (or
perhaps just naive) approach to attribute release. Consent-based release
is a good try, where I worry users just don't have the understanding to
do the right thing - and therefore (in my eyes) it falls short. I'm not
sure what the step beyond that would be that would give us adequate
controls, from a technology/usability/policy perspective. I haven't
spent a lot of time dedicated to thinking about it either...
From an administrative perspective, I'm concerned about "bad actor
acquires formerly good actor that's already in the federation." But
that's a discussion about the policies and governance rather than the
technology.
-- j
More information about the users
mailing list