[ https://jira.duraspace.org/browse/DS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24049#comment-24049 ]
Mark Diggory commented on DS-937:
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-937 ] - [#DS-937] Stop using Email Address as Identifier for DSpace User. - DuraSpace JIRA
[20:02] * JoseBlanco (8dd32b9d@...) has joined #duraspace
[20:02] <tdonohue> obviously this is a new feature / idea. But, do we have any immediate thoughts around this idea that we want to voice now?
[20:03] <mhwood> It's a good time to be thinking about it, with 3.0 being pulled together.
[20:03] <tdonohue> +1 mhwood
[20:04] <robint> Sounds good, although its not something that has been a problem personally
[20:04] * benoitg (~benoitg@...) has joined #duraspace
[20:05] <richardrodgers> I guess I'd like to see a bit more of a fleshed out proposal...
[20:05] <tdonohue> I think the only area where I've seen this as a potential "problem" is that we currently don't allow folks to change their associate email (cause it's tied into so much other stuff, as it's the main user ID)
[20:05] <mhwood> Exactly: it pins down something that should be a mutable attribute of the profile.
[20:06] <tdonohue> i.e it'd be nice to allow users to easily change their email addresses, and use something else as the permanent "user ID"
[20:06] <robint> The last para of the last comment by Mark seems to be on a slightly different topic, or have I misunderstood ?
[20:07] <mhwood> If I move to a different institution, or switch ISPs, then I get a new address. So I either have to re-register and abandon the old registration, or give up on subscribing to change notices, etc.
[20:07] <tdonohue> ok, sounds like there's some general "interest" here, just need a direction/proposal/prototype mapped out a bit better
[20:08] <tdonohue> robint: yea, mdiggory has a few topics interwoven here in his discussion of "provenance"
[20:08] <tdonohue> robint: I think the main point is that 'email' is currently tied into so many things -- we need to "untie" it a bit, and think about using something else as the ID, so that folks can change their email
[20:08] <mhwood> I think the provenance stuff comes in because we record NetID there instead of EPerson_ID?
[20:08] <hpottinger_> One thing to at least keep in mind, if we switch to truly unique identifier, there will be some pressure to utilize our repository to produce metrics
[20:09] <tdonohue> provenance currently uses email actually, I believe
[20:09] <mhwood> Define "unique".
[20:09] <hpottinger_> emplid
[20:09] <mhwood> Unique within a DSpace instance?
[20:10] <mhwood> Hmmm, the user might not *be* an emp, anywhere.
[20:10] <hpottinger_> unique within DSpace is fine, an ID used institutionally or more widely might lead to situations where certain researchers get "spooked"
[20:10] <tdonohue> yea, I was just thinking this new "ID" needs to just be unique within a DSpace instance (and it may even be generated/created internal to DSpace). It may be "mappable" to an employee ID or similar, but we don't have to use an External/Institutional ID as this "ID"
[20:11] <tdonohue> it may just be that all we're moving towards is having a dspace "username". You may even be able to choose your own username, it just needs to be unique in your DSpace.
[20:11] <mhwood> The storage layer already creates a unique-within-instance EPerson ID. We should use that, for example to look up external identifying information related to a provenance record.
[20:11] * grahamtriggs (~Graham@...) has joined #duraspace
[20:12] <mhwood> Suppose your "username" is your EPerson ID, but you identify yourself as an EPerson by presenting your current email, NetId, retina scan, whatever.
[20:12] <richardrodgers> db keys are a bit fragile as IDs...
[20:13] <tdonohue> yea, I'd rather avoid having db keys as the "ID". It makes things like "Backup & Restore" much harder (as you then have to try and retain DB IDs)
[20:14] <tdonohue> So, I prefer something like a "username" which is required to be unique
[20:14] <mhwood> OK, whatever, but it doesn't have to be either visible or enterable by the user whom the EPerson represents.
[20:14] <tdonohue> in any case, it seems like we have a lot of useful ideas here. I'll take an action to post a copy of this discussion into comments of Ds-937
[20:15] * hpottinger_ remembers Kim Shepherd's slide at OR11 urging us to treat people as objects
[20:15] <tdonohue> mhwood : point taken
> Stop using Email Address as Identifier for DSpace User.
> Key: DS-937
> URL: https://jira.duraspace.org/browse/DS-937
> Project: DSpace
> Issue Type: Improvement
> Components: DSpace API
> Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1, 1.7.2, 1.8.0
> Reporter: Mark Diggory
> Priority: Major
> Use of email address as a persistent identifier for the DSpace conflicts with the fact that email addresses are not persistent. Email addresses go away and/or are reassigned to other individuals. There are also policy concerns with Authenticators like Shibboleth and CAS that may or may not deliver an email address as a organizational policy.
> This Task is a placeholder to identify a solution to correct for the problem.
> 1.) DSpace should use a different identifier / key for the EPerson (netid? or combination of "authenticator + netID")
> 2.) DSpace should make providing an email address as optional for cases where the Authentication features lack this specific capability.
> 3.) Issuing emails should be optional for accounts without email addresses.
> 4.) Stop storing email address (or any other detail about who made the change) in dc.description.provenance field.
> One proposed solution to this problem is that the Authentication Method should be broken off of EPerson and stored separately, making EPerson a "Profile" and the method of Authentication be stored separately (Password, Certificate, LDAP, Shibboleth, CAS, Facebook, Google) Different AuthenticationMethods may store the data as they see fit. And the Profile would store only those local details for that user.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira