"Password leak at Elsevier"

[Steven Carmody]

(adding Andrew)

Peter --

thanks for your mention of FIM4L; I had missed that effort. I'll skip 
saying anything like "energy and momentum have moved to the EU/GEANT". ;-)

There's the obvious technical/deploy problem that not all IDPs and not 
all SPs support the use of this type of identifier. And the recommended 
identifier may be changing.

But there's also the problem that we've oversimplified the library use 
case. Brown's a relatively small community, and yet we have 1000+ people 
who have created identities at Elsevier. Those people have prioritized 
the value they get from giving up PII over the value they get from 
anonymity. Lots of people are still anonymous, but a significant number 
have given that up, presumably in a thoughtful way.

It seems that one solution, defined by central it, doesn't work for 
everyone. THat brings up the topic of consent, an idea that has fallen 
into disfavor with GDPR.

But, I'm wondering if this is a use case where Consent might not run 
afoul of the data regulators. The online publisher service is usable 
without releasing the PII; its just that the service "is moreuseful" if 
you share PII.

Thoughts on whether that hair-splitting would make it past the regulators ?

On 4/1/19 6:26 AM, Peter Schober wrote:
> * 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.
>>
>> Do any of these publishers support that model ? Is there any
>> approach we can give to our users to help them avoid creating
>> passwords at these sites ?
> 
> By far not all IDPs support persistent NameIDs so IDP and federation
> operators will often prefer to only provide authorization (e.g. using
> the common-lib-terms eduPersonEntitlement attribute value or an agreed
> upon eduPersonScopedAffiliation attribute value) but not provide an
> identifier allowing to recognise a returning subject.
> (This may stem from the desire to avoid sending personal data/PII,
> ignoring AssertionIDs and other technical artifacts.)
> 
> So while many publishers would probably support so far most of those
> SPs also work without sending an identifier in the SAML and therefore
> requre manually registering/setting up Yet Another Account at each of
> those SPs.
> Clearly this is an anti-pattern in many respects (UX, security, etc.),
> but a very common model nonetheless.
> 
>  From recent comments on the FIM4L mailing list it seems that some
> publishers intend to move to a model with *only* federated logins
> doing away with IP-based access control completely usually argued by
> enabling them to block individual users, but I'm guessing the fact
> that this also enables them to create personal usage profiles more
> easily will not exactly be unwelcome.
> 
> 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.
> -peter
>