Currently the Origin has a special meaning in the code and signed and unsigned transactions follow different paths in the validation and execution phase.

We could attempt to unify them and encapsulate all the logic in Extra. So that SignedExtensions would be allowed to return additional Origin information that would then be passed to dispatch.

That would make ValidateUnsigned and all _unsigned functions of SignedExtension obsolete, since both signed and unsigned extrinsics would follow the same path.

Possible simplifications in:

1. im-online - we introduce another SignedExtra which would check the signature inside the payload (not the signature of the transaction, since it's an unsigned transaction) and provide a special Origin containing the AuthorityId that signed that payload.
2. claims - details below
3. Any module using ValidateUnsigned trait or SignedExtension::validate_unsigned.
4. Clean and elegant srml::executive validation and dispatch.

Original convo (from Gav):

we could, i guess, extend SignedExtension API to include Origin-specification.
though it's a fairly fundamental change and i'm not sure how aggregation could work
but if we did it, then claims module would introduce a new Origin::EthereumClaimant(EthereumAddress)
and return that from its SignedExtension's validate (or pre_dispatch)
but there's a lot of interplay that would need to be figured out.
signed and unsigned are currently handled very differently.