Talk:Requests for comment/OAuth handover

approval requirements

(moved to the subject page)

comments

Thanks @CSteipp (WMF):! Just to clarify, all top-level bullet points are required; second-level ones are alternatives. (That is, the consumer needs to both respect intent and protect privacy; to protect privacy, it either needs to have a privacy policy or not store private data.)

Mostly. The top-level bullets are what need to happen, the sub-points are indicators that I would use to show that the Consumer fulfills the top-level point. So as a policy, I'd say Consumers *should* fulfill <some number> of <subpoints> to be approved, or the approver should make document why they think the top-level item is being fulfilled. CSteipp (WMF) (talk) 13:56, 23 September 2015 (UTC)

Can you expand on the last bullet point? My (probably incorrect) understanding is that a request will only result in MediaWiki redirecting to the callback URL if it has been signed by the consumer secret, so a malicious callback URL will only be requested if the consumer itself is malicious, in which case there is not much difference between sending back to the consumer and some other site. How careful do admins need to be there? --Tgr (WMF) (talk) 23:24, 14 September 2015 (UTC)

This is a broad mitigation against "Covert Redirect" attacks, which also require that the attacker has access to the Consumer id/secret, as you pointed out. So right now this isn't an issue for us-- we also (by policy... which I need to add to the above list) shouldn't approve Consumers that make their secret public ("public" consumers, in OAuth 2 terminology). So that would be things like javascript "thick" apps, or mobile apps that embed their secret in their code, where anyone can get access to it. CSteipp (WMF) (talk) 13:58, 23 September 2015 (UTC)

Reduce number of total requests

I propose that we autoapprove all requests that are 'Authentication only' and do not require any special rights. This should reduce the burden on whoever is doing the approval and also make it faster for developers to get started. Thoughts? YuviPanda (talk) 21:12, 24 September 2015 (UTC)

For an interim period, that makes sense. Eventually T87395 would take care of that; auth-only apps are not security-sensitive but they should still have a privacy policy and preferably be opensource. --Tgr (WMF) (talk) 21:32, 24 September 2015 (UTC)

Are we trying to kill OAuth?

Established developers only. Open source only. No Apps. Your just going back to developers asking for passwords. Dispenser (talk) 19:28, 28 September 2015 (UTC)

No apps is a technical limitation as apps cannot safely store the consumer secret (see e.g. section 5.1 of this study). As for the other two, I believe they reflect current practice (but note that these are possible ways of fulfilling the requirement of "respect the intent of the users", not requirements in themselves). Of course, if you think the current practice should change, feel free to recommend alternatives - that's pretty much the point of this discussion. --Tgr (WMF) (talk) 21:36, 28 September 2015 (UTC)

The client secret could actually be public in some circumstances. Example: I want to run pywikibot on a shared hosting provider with a history of security problems. With OAuth my password isn't saved and the credentials are limited if the config is compromised. Is the client secret is public with the framework, nobody is expecting the framework to be verifiable. Dispenser (talk) 06:49, 4 November 2015 (UTC)

non-developer, mass uploaders separate group & process? Slowking4 (talk) 03:54, 4 October 2015 (UTC)

Sorry, I don't understand the question. Can you elaborate? --Tgr (WMF) (talk) 00:32, 5 October 2015 (UTC)

what is the permissions path, communication channel for uploaders ? what is the engagement / onboarding process? what specific steps will be taken to avoid the GWtool permissions / username fiasco ? what assurance that requests will be handled in a timely manner for expert editors? Slowking4 (talk) 00:26, 14 October 2015 (UTC)

We can start with none whatsoever, which is the status quo, and work upwards from there. If you have any proposals, feel free to amend the page :) --Tgr (WMF) (talk) 01:13, 14 October 2015 (UTC)

I'd prefer if this remained in the hands of developers and WMF

Looks like a very sensitive and technical permission to me to allow external aplications or sites to perform actions on your behalf, and authorizing those. This requires technical and security knowledge, and a high level of confidence. As such, I'd prefer if this remains in the hands of those who really know how the code works, so we can continue trusting OAuth and applications using this system. As such I oppose this proposal. Thanks. —MarcoAurelio 09:39, 4 October 2015 (UTC)

Yes, I quite agree. If at all, the questions in Requests_for_comment/OAuth_handover#Proposal should be dealt with first ("policy or guideline by which new apps are judged", "necessary documentation"). --MF-W 01:32, 10 October 2015 (UTC)

I generally agree as well. I wouldn't mind seeing this in the hands of the community, but at this point anyway it's probably best left to the technical experts. Ajraddatz (talk) 01:51, 10 October 2015 (UTC)

My third OAuth request expired yesterday, that's nearly 3 months of them sitting around in a queue. Those "technical experts" aren't working on this. Its either community approvals or its dead and developers ask for passwords again. Dispenser (talk) 19:35, 29 October 2015 (UTC)

Drop the requirement for approval.

So far I have seen no clear argument why we even need approval. Most other OAuth providers in the wild do not require approval. The MW approval process was supposed to be a temporary thing (see csteipp's comment on Phab:T67750. It's been years and we still have it. Why are we trying to keep it? --Halfak (WMF) (talk)

IMO there are some cases where auto-enabling is a good idea. (Most other OAuth providers do not allow you to interfere with the activity of other users of the service in any significant way, so they are not in a similar situation.)

• access to high-risk permissions (blocking etc.) should probably require some level of trust
• access to private data should require a privacy policy at the very least
• if the application cannot keep its secret key secret, the configuration and use cases should be appropriate
• less transparent applications (not opensource, not from the community) should receive a higher level of scrutiny

I'm not sure about simple editing. There is not much security risk, but most wikipedias require approval for bots and an oauth application is basically a global bot. It does not get a bot flag, but it still can perform mass edits.

Applications that don't edit and don't access private data should probably not require approval. --Tgr (WMF) (talk) 23:39, 28 October 2015 (UTC)

If we can't kill the approval process, I agree with making it smaller and more narrowly defined.

It also seems like it might be valuable, if author trust is an issue, to take into account how long the person seeking approval has been around Wikimedia. I'm hearing stories from people who have been around for ten years filing submissions that then expire? That seems pretty wrong to me. --MZMcBride (talk) 04:39, 29 October 2015 (UTC)

OT

Is https://phabricator.wikimedia.org/T103587 an umbrella task related to this proposed change? Any (other) Phab links that could be handy to people interested in the topic? Thanks, and good luck. --Elitre (WMF) (talk) 16:53, 28 October 2015 (UTC)

phab:T59336 is more or less the task for this. Workflow improvements are of course going to be interesting for the people who will manage OAuth approval, but they are currently not considered blocking, except maybe phab:T116681. --Tgr (WMF) (talk) 23:17, 28 October 2015 (UTC)

Requests for approval expire?

Do requests for approval expire if not acted upon? I've read a few comments that indicate that the long queue seemingly empties itself after a defined period of time. Is this accurate? If so, why? --MZMcBride (talk) 04:41, 29 October 2015 (UTC)

Yes, in $wgMWOAuthRequestExpirationAge (defaults to a month). Not sure what the reason is. --Tgr (WMF) (talk) 00:23, 30 October 2015 (UTC)

Moving forward

Hi all. It's been quite a few months since anything was discussed on this, but I think we should start to move forward with implementation. What I see that needs to be done:

• Move the draft approval policy to it's own page, after being confirmed by discussion here (or perhaps on a separate page?)
• Perhaps allow other, technically experienced and trusted users to approve OAuth applications as well?
• Create / expand on guidelines made for steward use of OAuth both here and on the stewardwiki summary
• Add oauth rights to the local steward group on meta, or have stewards add themselves to the local OAuth group if interested in that work

Sound reasonable? Have I missed anything? Ajraddatz (talk) 07:15, 21 March 2016 (UTC)

I've added myself to the OAuth admin group to approve some requests that were about to expire, which meet the proposed criteria on the main page. If stewards are going to be using this (as intended as of the SF meeting), then we can probably +oauthadmin ourselves for approving requests, and direct people to SRM with concerns on how OAuth applications are being used. I don't want to create further documentation without some kind of participation, though... Ajraddatz (talk) 07:57, 22 March 2016 (UTC)

I appreciate the efforts on moving this forward, however I should insist that authorizing other applications with our accounts is IMHO a very sensitive task which should be done by people with good knowledge of coding, to protect our users from malicious or malfunctioning applications. Best regards, —MarcoAurelio 10:26, 22 March 2016 (UTC)

I understand your concerns - if you look up the page a bit, you'll even see that I expressed the same ones earlier in the year! However, as explained in SF, this isn't much of a technical action to do. No code review is really required - what counts is the grants that are being requested. The system is designed to not allow a user to perform any actions that they wouldn't have permission to by default, so carte blanc approval for any trusted user who is requesting either basic editing rights or authentication only is essentially possible, given need for it of course. Basically, it isn't as much of a sensitive task as it seems (take it from someone who was opposed to the transition 6 months ago), and having active people looking at and monitoring these applications could probably help protect users from malicious applications, rather than having over-worked tech staff quickly approving tasks in their off time. If you want some bed-time reading material, the page on the stewards' wiki explains the rationale and process pretty well. Ajraddatz (talk) 16:24, 22 March 2016 (UTC)

The lack of discussion here is indicative of a bigger problem - I don't think that the steward group is comfortable taking on this role. As such, it is probably best if Wikimedia technical staff continue to handle these requests, maybe while allowing some community members to approve and manage requests as well given interest and competence in the area. I don't want to be involved in that, though. Ajraddatz (talk) 04:24, 27 March 2016 (UTC)

Or that its poorly organized. Every other OAuth provider has gotten back to me within the week. Wikimedia? Five requests expired after 30 days each before the sixth was approved on the 13th day (over 160 days).

This request was for reduced grants because the interface text is scary enough that users are using the older, complicated method that grants me even more privileges. I cannot prompt for less, nor can users deny grants before connecting. However, grants can be denied after connecting!?! There no source code check (Labs has no FLOSS distribution requirement outside of Labs) and we tools like WiDaR that shares an OAuth in several tools. Dispenser (talk) 20:34, 30 March 2016 (UTC)

I think this may encourage participation here, and have us informed too. Best regards. —MarcoAurelio 10:07, 12 April 2016 (UTC)

Special:OAuthManageConsumers gives you access to private data

@Jalexander-WMF, Mdennis (WMF), Kbrown (WMF), and Kalliope (WMF): Special:OAuthManageConsumers gives oauth administrators access to private user data such as email addresses. It is my understanding that email addresses are covered by the wmf:Privacy policy. As such, no oauth administrator should be appointed without signing the confidentiality agreement for nonpublic information if comes from the community, or employees/contractos NDAs if holders are hired by WMF. Policies and documents should be updated to reflect this, and users holding this permission should be required to sign either the volunteer NDA or or the employee/contractor NDA if they've not done so already. Thanks, —MarcoAurelio 08:55, 14 April 2016 (UTC)

FWIW app developers have to enter their email address manually when registering the consumer, although it's not explained who is going to see it. The whole email field seems somewhat pointless to me (T121330). --Tgr (WMF) (talk) 11:40, 14 April 2016 (UTC)

If the email is gone, then no issues, but until it's there I think no one without NDA should be allowed to the oauthadmin right. I understand that all of you (WMF accounts) already have signed some sort of document. I'll let SuSa decide on this of course though. —MarcoAurelio 15:20, 14 April 2016 (UTC)

Hmmm, fair point, given that the email address has to be given independently (I do think it might be compared automatically but I'm not sure) I think there are two options here:

* We put in a warning (there is already a checkbox they have to check that talks about what they are agreeing to, we could talk to legal and add something there, probably just a sentence that says "you understand that the information you submit on this form, including your email address, will be seen by [linked|OAuth administrators]" added to the paragraph that's already there.

* We require them all to have gone through the confidentiality agreement process.

Is there an opinion on which one of those? Jalexander--WMF 23:54, 15 April 2016 (UTC)

It is compared automatically, yes. @CSteipp (WMF) might know better what the reason for that field was, but IMO it is worth rethinking. It cannot differ from the user's MediaWiki email address, but does not track that (in fact like most consumer fields it cannot be updated at all), and submitting it is a jarring user experience (T121330). If it is really important that OAuth admins can contact app owners via an email client (and not MediaWiki's email form / their talk page), we should just expose the user's current email address (and warn them about that), otherwise just drop it. --Tgr (WMF) (talk) 10:26, 16 April 2016 (UTC)

OAuth proposal suppression

Hi all, I noticed that the rights were available for OAuth suppression today and so I tested them out. It's kind of clunky - the only option is to reject and suppress (makes sense), but the log entry appears in the OAuth log and not the suppression log, and is publicly viewable. This in itself does not reveal sensitive info, so no issue there. The suppressed request is listed on the rejected page, but only visible by those with the appropriate permissions.

This requires the mwoauthmanageconsumer right to use, though, so it might be worth keeping in our global group regardless of what we eventually decide to do in terms of the steward role in the process. FWIW, approving or rejecting apps is publicly logged, so if we are going to handle these then there isn't much need to +/- ourselves from the group. The rights could also be added to our local group, since all oauth activity is coordinated on Meta-Wiki. Ajraddatz (talk) 21:08, 5 June 2016 (UTC)

Closed

I've closed this RFC as no consensus. After more than one year, this topic has attracted little attention and there are outstanding questions that I feel need to be addressed before we can start giving out this right to non-WMF people. I suggest that stewards keep the right because we're likely the only ones noticing requests to have OAuth consumers approved. —MarcoAurelio 16:53, 20 November 2016 (UTC)

Link to this RFC

@MarcoAurelio: even though this RFC has been closed for over a year now, the interface message MediaWiki:mwoauthconsumerregistration-propose-text, prominently displayed on Special:OAuthConsumerRegistration/propose, still links to it. I guess that should be updated? --Lucas Werkmeister (talk) 11:01, 3 August 2018 (UTC)

Updated, thanks. – Ajraddatz (talk) 17:21, 3 August 2018 (UTC)