"Password leak at Elsevier"
steven_carmody at brown.edu
Thu Apr 4 11:43:28 EDT 2019
some comments from Andrew (who is not on this list)
Steven (and feel free to forward to the list if it bounces a non-member
I'd expect regulators to be very happy if the ecosystem distinguished
between attributes that were necessary to provide the service and those
optional ones that were consent-based. Our Information Commissioner has
talked about consent in exactly those terms - as allowing the individual
to control the depth of the relationship they want to have with a service.
I've been discussing that for years - see a post from 2013 at
and I sketched an interface (though the graphic seems to have got lost
in a blog platform transfer - it showed the consented attributes with
individual tickboxes and the necessary ones without) at least a year
But I keep being told the technology can't express that. The mail chain
you've included doesn't tell me whether we are now moving in that
On 4/3/19 3:00 PM, Steven Carmody wrote:
> (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.
More information about the users