[ 
https://jira.duraspace.org/browse/DS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20767#action_20767
 ] 

Tim Donohue commented on DS-937:
--------------------------------

MarkW:  Good point.  We really don't document what "NetID" means in DSpace -- 
that's left up to the institution to determine.  Some institutions consider 
one's email address to be their NetID.  Others actually just strip off the 
"@myu.edu" and take the first portion of the email address to be the NetID 
(e.g. when I was at U of Illinois, my email was '[email protected]', and my 
NetID was 'tdonohue').   So, NetID really is a vague term which I would 
generally define as "one's user identifier or login/username at one's 
institution".

In the end, I think your definition is mostly accurate:  NetID is just a user 
identifier string that may or may not be a user's email address (or related to 
one's email), but we don't assume that it is an email address. NetID should be 
unique within one's institution (but it may or may not be unique outside of 
one's institution -- this is an area where email address is better than NetID, 
in that it is unique even outside of one's institution). NetID also may or may 
not be a persistent identifier (depending on the institution's policies).

I agree, the proper DSpace user identifier requires much more thought.  
Personally, I'm not sure I'd even go so far as to throw out usage of Email as a 
DSpace user identifier (as it is unique, both inside and outside of one's 
institution).  But, DSpace definitely should not be assuming that email 
addresses are persistent identifiers.

> 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

Reply via email to