Enhancing the Vouched Access API to include group membership

[William Reynolds]

Hi #commtools,

I propose we enhance the Vouched Access API to let apps know if a user
is a member of a specific group. Please share your feedback on this thread.

Multiple teams and individuals want to use the Mozillians API to provide
access to contributors who are members of specific groups. This saves
them from creating their own access control system and it provides an
easy way to manage who has access to a tool. If they don't use the
Mozillians.org API, they have to spend a lot of time to create their own
solution, or they may limit the tool so that only paid staff (those with
a mozilla.com email address) can use it.

I think there's a useful, simple opportunity for Mozillians.org to
enable teams to better collaborate and share appropriate access with
both volunteers and paid staff. Currently, this is only possible if the
app is reviewed and gets a Reviewed Access API key, which also provides
the app with lots of profile information. That is extra data access they
don't need.

= Our existing API access levels =
Our API has 2 access levels for apps: Vouched Access and Reviewed
Access. Any vouched Mozillian can create apps with Vouched Access. A
vouched Mozillian can get Reviewed Access for their app after going
through a thorough review process:
https://wiki.mozilla.org/Mozillians/API#Process_for_.22Reviewed.22_API_keys

Apps with Vouched Access can currently answer this question:
- Does su...@mozilla.org have a vouched profile on Mozillians.org?
Answer: Yes or No

Apps with Reviewed Access can currently answer the above question as
well as:
- What groups is su...@mozilla.org a member of on Mozillians.org? Answer:
A list of her groups.

= Proposal =
I suggest we change our API so that an app with Vouched Access can also
answer this question:
- Is su...@mozilla.org a member of the 'NDA' group on mozillians.org? Yes
or No

Teams can create and manage groups for any access they want to provide.
Their app will then provide an email address and a group name to check
if the email address belongs to a person in the group.

= Privacy =
This change has privacy considerations and I had an initial conversation
with the privacy team. Since this proposal allows apps to use a Vouched
Access API (less data) than a Reviewed Access API (more data), this
feels like a privacy win. I have opened a privacy bug (1078728) to track
that discussion and check if this proposal would be covered by the
current privacy policy. Also, the team says the privacy policy is not a
blocker for implementing this proposal.

William

[Justin Crawford]

+1. This is elegant. Requiring requesters to know those pieces of information helps limit exposure.

One addition that might mitigate more concerns would be to allow group curators to decide whether their group will "respond" to queries about its membership. Display that in the infobox about the group, or in a popup when someone tries to join, and you have given folks a way to opt out of this: Don't join the group.



> William Reynolds <mailto:will...@mozilla.com>
> October 9, 2014 11:53 AM

> _______________________________________________
> dev-community-tools mailing list
> dev-commu...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-community-tools

--
Justin Crawford
Product Manager, Developer Relations | Mozilla
hoos...@mozilla.com

[jop...@gmail.com]

> One addition that might mitigate more concerns would be to allow group curators to decide whether their group will "respond" to queries about its membership.

Hmm, this might be nice... but do we have a lot of groups where memberships are sensitive information?
It is not like groups offer message boards, wiki pages, photo books, or any features, other than membership. So if you want to hide your group memberships from other mozillians one could ask what groups are good for.

Privacy is important, but too many settings and special cases can also be crippling in the long run.

Anyways, I really want to see this API end-point, so I can offer temporary credentials to mozillians who are member of the taskcluster-users group.
The setup would involve requiring people to authenticate with persona, and checking if their email is member of my curated group.

I think delegating access through mozillians.org is brilliant. It'll drive adoption of mozillians.org and make mozillians.org a lot more useful.

[Pierros Papadeas]

Thanks WilliamR, for bringing this up as a suggestion.
This indeed sounds like something we should be looking into, as part
of our second story arc "Mozillians.org as a service to other Mozilla
properties".

I would like to point out though, that relying on the group
functionality we currently have in mozillians.org and especially about
the privacy controls of it, could be tricky. This new proposed
functionality of our API should be dependent on a groups UX and
privacy clean up (curated vs organic etc), and then based on the
changes on groups we will proceed with implementing this.

William, please make sure to file all the tracking bugs and cards
nevertheless, so we can keep track of this.

Thanks,

~pierros

On Fri, Oct 10, 2014 at 1:27 AM, <jop...@gmail.com> wrote:
>> One addition that might mitigate more concerns would be to allow group curators to decide whether their group will "respond" to queries about its membership.
>

> Hmm, this might be nice... but do we have a lot of groups where memberships are sensitive information?
> It is not like groups offer message boards, wiki pages, photo books, or any features, other than membership. So if you want to hide your group memberships from other mozillians one could ask what groups are good for.
>
> Privacy is important, but too many settings and special cases can also be crippling in the long run.
>
> Anyways, I really want to see this API end-point, so I can offer temporary credentials to mozillians who are member of the taskcluster-users group.
> The setup would involve requiring people to authenticate with persona, and checking if their email is member of my curated group.
>
> I think delegating access through mozillians.org is brilliant. It'll drive adoption of mozillians.org and make mozillians.org a lot more useful.
>

> _______________________________________________
> dev-community-tools mailing list
> dev-commu...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-community-tools



--

Pierros Papadeas
Community Architect
pierros @ irc.mozilla.org

[Giorgos Logiotatidis]

Mozillians as a service (MaaS) is a great idea. It's something that's
already in use from sites (like airmo) which have "Reviewed Access". I
agree that we should broaden the audience but only when keeping in mind
the privacy settings that we have currently on the site.

I advice against extending the current API (APIv1) because it's privacy
model is older than account privacy settings and it's confusing.
Extending APIv1 will duplicate efforts to bring this functionality to
APIv2, delaying even more it's arrival and probably the result will not
be as good as building on APIv2 anyway. Finally APIv1 it's not really an
API one can enjoy using or extending.

APIv2 solves the privacy issue by respecting the privacy settings per
user for all API keys. Thus if a user chooses not to share groups, there
will be no group exposure. There is no need to alter group setting to
achieve that. Lot's of thought has been put into how we can make this
work, we should be building upon this.

APIv2 is not vaporware. There is big pull request [0] that solves many
of the issues of APIv1, adds some functionality (like fetch a user using
email or any of their external account identifiers) and it's a great
platform to further extend the API.

APIv2 is not ready either. Schema / endpoint discussion must open here
and all current API consumers should be informed about the upcoming
changes and asked for feedback.


-Giorgos

[0] https://github.com/mozilla/mozillians/pull/1081/

> _______________________________________________
> dev-community-tools mailing list
> dev-commu...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-community-tools

--

Sent with my mu4e

[Pierros Papadeas]

Giorgos thanks a lot for the clarifications and suggestions.

Indeed it make sense to invest into APIv2 and use it as a base for all
future enhancements (like exposing groups).

@William, can you set up a meeting for the team to brainstorm on a
solid proposal that we can then share with current consumers and get
feedback?

Thanks!

~pierros

[Jonas Finnemann Jensen]

> APIv2 is not vaporware... APIv2 is not ready either.

What is the time frame on APIv2 ?
Off-topic, from skimming the PR I would suggest considering hawk for
authentication and perhaps using JSON schemas for validating and
documenting input and output.

APIv2 solves the privacy issue by respecting the privacy settings per
> user for all API keys. Thus if a user chooses not to share groups, there
> will be no group exposure. There is no need to alter group setting to
> achieve that.

Privacy settings per user is great, but can also very crippling.
Choosing whether or not to share t-shirt size, etc... is perfectly
reasonable.
But if a user chooses not to share group memberships, then the use-case
breaks.

*Imagine the following scenario:*
1) User signs up for mozillians and sets very restrictive privacy settings
(a few years passes)
2) User joins a curated group *taskcluster-users*
3) User authenticates against taskcluster with persona
4) taskcluster looks up email on mozillians to validate membership of the
*taskcluster-users* group
5) mozillians.org returns "false" (or says it can't answer because of
privacy settings)
6) taskcluster tells your his group membership could be verified
(authentication failed)
7) User reports bug against taskcluster, that nobody else can reproduce...
and we loose a potential contributor.

Let's try to avoid unfortunate corner cases like this. Most "properties"
using mozillians for authentication won't care to implement rare corner
cases. And even then users (me included) rarely read the details of an
"authentication failed message" :)

If the API should have the option to refuse answering group memberships,
that option should be configured by the group curator as a setting on the
group. And then people can choose to join or not.

Slightly off-topic, but I think we should be careful with offering too many
privacy settings. They sure makes sense for somethings. But if you join a
community directory (phonebook) it makes limited sense to hide your email.
Too many settings is also confusing for users (facebook used to be
criticized for being confusing/complicated).
And too many privacy settings makes the resource (in this case community
phonebook) a lot less useful.
Anyways, just something to keep in mind.


--
Regards Jonas Finnemann Jensen.