It's right to focus on ease-of-invitation as the motivation for enabling Google authentication on our tenant. But John's right to point out that this alone doesn't sort out the sharing problem, and how there remains an interest in easing collaboration while still respecting a natural scope for limited sharing. I don't think the OAE concept of 'anyone who can log in' is proving to be a good fit for the mental models of our users.
Expressed in different words, the kind of question that comes up in our conversations with pilot users amounts to something like, "What are you afraid of?" People are afraid of something being public even if they don't know why (or often because they don't know why), but not afraid if it's just the local campus community; even if the latter bounded set is illusory (we have a fairly permissive guest account policy, and many external research groups), that's the mental model they're comfortable with. If we tell them, "it's actually everyone with a campus account as well as anyone invited," they just lump that in with the 'public' option of their mental model, and be just as afraid. We're giving them a distinction without a difference, from their perspective. In order to keep sharing as open as possible while giving our users choices they understand, I feel like we'll need to have some way for invited collaborators to be separated from first-class tenant participants. As John suggests, oaeproject.org identities (or identities pulled from some external profiling service) in some sense rather than, say, Georgia Tech identities. ~Clay On Wed, Dec 11, 2013 at 12:58 PM, John Norman <jr...@cam.ac.uk> wrote: > Saying nothing about priority, I think this is an important consideration. > > With Sakai CLE we maintained a 'friends' LDAP, modelled on Michigan. A site > admin could invite anyone to join the site by email, which would then > trigger a password selection with email as the username. The created account > would only have access privileges in the group that issued the invitation. A > different group could issue an invitation to the same email address and then > the account would get access to two sites, but never 'institutional' access. > > It is desirable to support something similar. With apps like Dropbox you can > invite someone to join by email. I believe we want guest access of this type > for anyone in the world. If the person being invited wants to reuse Google, > or Twitter credentials it would be nice to permit it, but we have to > anticipate some users may not have such credentials or may not want to use > them for this purpose. We also need to worry about handling academics at a > peer institution that does not have a tenant but later acquires one and the > account transfers/merges that might imply. I think one option might be to > issue oaeproject.org identities as someone is invited by email. These can > use whatever identifier the invited person prefers with the regular account > login and then be given guest access in the inviting tenant. The same > account could then be used for guest access in other tenants and would be a > known entity for any account merges. > > That said, I haven't thought it through very carefully. Just conscious that > we want to be able to provide guest access to anyone by invitation. There > may be other scenarios, but this is my top concern. > > J > > On 11 Dec 2013, at 16:03, Clay Fenlason <clay.fenla...@et.gatech.edu> wrote: > > We have (apparently) contradictory desires: > > a) We want to open up other OAuth routes of authentication to the OAE > (we have Google logins turned on now) > > b) We want to be able to share things only with people who have used > their local campus credentials to log in > > Is there some way to do this now, or would this actually require a > significant change to OAE authorization? > > ~Clay > _______________________________________________ > oae-dev mailing list > oae-dev@collab.sakaiproject.org > http://collab.sakaiproject.org/mailman/listinfo/oae-dev > > > John Norman > Director - Digital Services > University Library > University of Cambridge > jr...@cam.ac.uk > +44-1223-765367 > > > _______________________________________________ oae-dev mailing list oae-dev@collab.sakaiproject.org http://collab.sakaiproject.org/mailman/listinfo/oae-dev
