"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 

-- j

More information about the users mailing list