Persist the current resource owner through the assertion handler

[danielevans]

This is intended to allow assertion handlers to have context to the current resource owner if it is provided by parse call.

Specifically meant to allow a user to associate social networks to their existing and authorized account in an api via assertions.

[jcoglan]

Can you explain your intended use case more fully? It sounds rather close to a documented security hole that allows you to steal accounts via OAuth, depending on how it's implemented.

The purpose of the assertion handler is to determine who the resource owner is, based on the assertion. Passing it in seems rather odd.

[danielevans]

Sure.

Given that I am an authorized user (in other words, that I have a valid token given via the authorization header)
When I post an authorization assertion for a social network with a valid access token
That social network account is associated and authorized with my account
So that future assertions with the same social network account will authorize my account

I realize that this could also be achieved with a separate endpoint to associate the user to a social network, however the fact that the Provider#parse method and Exchange#initializer method took it as and argument seemed to indicate to me that this was intended but never implemented.

I also realize that this puts the requirement on the user (me) to implement verification of the assertion token with the external oauth provider, which is in place for my application.