"Password leak at Elsevier"

[Steven Carmody]

On 4/4/19 11:58 AM, Steven Carmody wrote:

Hi Andrew,

Thanks (as always) for sharing that very helpful information about how 
the regulators view consent.

re "I keep being told the technology can't express that" ... the Swiss 
developed the original uApprove extension to the Shib IDP; that 
implementation did not support optional release. However, the Japanese 
Federation extended uApprove to support this idea. I've attached their 
poster from TNC 2012 showing the user view of this support. 
Unfortunately, that implementation only worked with IDP v2.x; the 
current IDP implementation is 3.x and I don't think it supports optional 
release.

> 
> On 4/4/19 5:45 AM, Andrew Cormack wrote:
>> 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
>>
>>> -----Original Message-----
>>> From: Steven Carmody <steven_carmody at brown.edu>
>>> Sent: 03 April 2019 20:01
>>> To: users at shibboleth.net
>>> Cc: Andrew Cormack <Andrew.Cormack at jisc.ac.uk>
>>> Subject: Re: "Password leak at Elsevier"
>>>
>>> (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
>>>>
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tnc2012_poster_TNC2012-poster-motonori-2.jpg
Type: image/jpeg
Size: 52800 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20190404/61dd31a5/attachment.jpg>