[
https://jira.duraspace.org/browse/DS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20761#action_20761
]
Tim Donohue commented on DS-937:
--------------------------------
Overall, I like this as a concept, but I have a few minor quibbles to express:
* Not all authentication mechanisms support NetID or similar. So, we cannot
depend entirely on a NetID being there. I think this was one of the main
reasons why email was used as the "identifier" to begin with (it's similar to
how Google/Yahoo/etc. use your email as your primary User Profile identifier).
That being said, DSpace minimally needs to allow users to *change* their email
addresses -- we definitely cannot assume that emails are persistent (similarly
you can change your email associated with your Google/Yahoo account at any
time). However even if emails are not persistent, they could still act as a
form of unique identifier in DSpace (but the *persistent* user identifier may
need to be just a table ID or similar).
* In regards to MarkD's #4 above, the purpose of provenance information is to
track what change was made, when it was made, and by whom. So, although I
agree with MarkD's concept of removing emails from dc.description.provenance, I
think we still need some form of user identifier in that field (preferentially
a *persistent* user ID) (Sidenote: technically, we shouldn't even be storing
plain text provenance information -- it'd be better to look at things like
PREMIS, etc. but that's a much larger issue.)
* Although I also like MarkW's points above (not duplicating data), I still see
a need for DSpace to duplicate some data (like Email / Name) as a form of
"caching". If we didn't store Email/Name in a "cache", then we'd be contacting
LDAP every time we need to do something with a user's email or name (like
display it or send an email, etc.). However, we *should* treat that
information more like a "cache" (so, for some authentication mechanisms, like
LDAP, we should overwrite that cached info when we find that it has changed
externally)
Just a few things to think about. Again, I think these concepts are good
overall. But, we may need to nail down more exact use cases for these changes,
and ensure any changes will be of benefit to all Authentication mechanisms
(LDAP, Shib, internal DB authN, etc.)
> 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 contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
