"Password leak at Elsevier"

[Steven Carmody]

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 
response).

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 
https://community.jisc.ac.uk/blogs/regulatory-developments/article/how-much-complexity-should-we-see 
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 
earlier 
https://community.jisc.ac.uk/blogs/regulatory-developments/article/explaining-attribute-release. 


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 
direction...

Cheers
Andrew


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.
>> -peter
>>
>