Hi Wolf, Not an impertinence at all, and very topical. You can find an ongoing discussion on the same topic here https://jira.duraspace.org/browse/DS-937. Feel free to add your own comments.
Cheers, Robin. On Thu, 2011-06-23 at 16:20 +0100, Wolf Halton wrote: > Hi, I am very new here, and perhaps you will consider this an > impertinence, > > "Make things as simple as possible, but no simpler." > Why cannot we have an internal, private 'userID' and alias to it an > email and/or a public username. This would let the users change their > emails or 'real name' as much as they want. An ldap user name could > (perhaps) be associated with the dspace internal userID (maybe just > another alias inside dspace). This would lead to the structure not > having to be changed depending on whether netIDs are in use or not, > and would make changes thereto irrelevant. This would make > cloud-based implementations with multi-organizational centralized > databases simpler as well. Or maybe you have already covered this in > detail... > > Wolf > > Date: Thu, 23 Jun 2011 14:56:51 +0000 (UTC) > From: "Mark H. Wood (DuraSpace JIRA)" <[email protected]> > Subject: [Dspace-devel] [DuraSpace JIRA] Commented: (DS-937) > Stop > using Email Address as Identifier for DSpace User. > To: [email protected] > Message-ID: > <2116959226.5451.1308841011234.JavaMail.jira@atlas> > Content-Type: text/plain; charset=UTF-8 > > > > [ > https://jira.duraspace.org/browse/DS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20765#action_20765 > ] > > Mark H. Wood commented on DS-937: > --------------------------------- > > Would someone please tell me where we document what we think a > NetID *is*? Is it just a string that is probably an email > address, only we don't assume we can send an email there? > > Exactly what our actual user identifier is, is a topic > requiring some more thought. > > > 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 > > > End of Dspace-devel Digest, Vol 61, Issue 16 > ******************************************** > > > > -- > This Apt Has Super Cow Powers - http://sourcefreedom.com ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
