OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Martin Atkins]

Allen Tom wrote:
> Hi Martin,
> 
> The intent is to be able to identify applications which were not 
> deliberately designed to be malicious. Well designed malicious apps 
> would piggy back off of another app's CK or just cycle through a list of 
> CKs to evade detection.
> 
> However, there have been occasions where legitimate apps behave 
> strangely, and we'd like to be able to contact the developer of the app 
> for more information. Having the CK present in the server logs makes it 
> a lot easier for us to diagnose problems on our side, especially if 
> we're able to use the CK to look up information about the app and its 
> developer.
> 
> We've also seen apps that are well intentioned, but extremely buggy. 
> It's very helpful to be able to easily identify requests originating 
> from these apps if we need to disable them.
> 

It sounds like there are really two things that need identifying here. 
Your description above seems to be less a security requirement and more 
just a means for well-meaning authors to be notified about unintentional 
bugs.

There's also the need to have something to point at as what the user 
trusted, so that other applications can't piggy-back off the trust of a 
popular app.

It doesn't matter so much if the former is compromised, but it is very 
important that the second isn't compromised.

It seems like there needs to be two tokens here. One is provisioned by 
going through some registration flow on the SP site, and the other is 
provisioned automatically *by each installation* of a desktop/mobile 
app. The latter is known only to that installation and so a user trusts 
only their installation of the app, not an installation of the same app 
on someone else's system.

I guess the flow I'm imagining is as follows:

* App author applies for an application identifier through web forms as 
normal.
* App author creates a desktop app that is distributed with that 
application identifier embedded in it.
* On install or first run, the app makes a back-channel request to an 
endpoint at the SP to get a consumer key that's attached to the 
application identifier but known only to that install.
* Henceforth, the app does OAuth as normal using the single-instance 
consumer key.

If the consumer key becomes invalid for some reason (because the user 
removed the trust of that app, for example) the app would need to do the 
same steps it did on first-run to provision a new key, re-establish 
trust and so forth.

Since the consumer key is indirectly mapped to the application 
identifier, you retain the ability to contact the registered author of 
the application.

Does this sound reasonable?