Third-party AuthnRequest use case

[Greg Whitehead <grw@trustgenix.com>]

The portal "push" use case is one example where it would be useful to 
have a third-party, the portal, create an AuthnRequest that can be 
delivered to the IdP and ultimately deliver the authenticated user to 
an SP.

This sort of works with the existing AuthnRequest, but I'm not sure it 
was intended and there are a few issues:

1) The AuthnRequest issuer is expected to be the SP to send the 
Response to. This means that a third-party issuer has to lie about who 
it is, precluding the use of request authentication (signing). Note 
that if the SP advertises that it signs AuthnRequests, IdPs are 
justified in rejecting unsigned requests.

2) The Response's inResponseTo won't make sense to the SP. I believe we 
have text that talks about receiving a Response without an inResponseTo 
(an unsolicited response), but we don't discuss the possibility of 
receiving a Response with an inResponseTo that refers to an 
AuthnRequest that the SP didn't generate.

3) Handling RelayState. I'm not sure where we stand on using RelayState 
in unsolicited responses to convey TARGET information, but I think the 
current language is weak enough that it really can't be expected to 
work... it certainly won't work if SP's are keying on an empty 
inResponseTo to decide that RelayState might contain a TARGET.

-Greg