[
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@gateway/web/freenode/ip.141.211.43.157) 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 ([email protected]) 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
([email protected]) 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
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
