RE: [security-services] Third-party AuthnRequest use case

["Scott Cantor" <cantor.2@osu.edu>]

> Ok, I see what you're suggesting: an IdP could accept additional third 
> party keys, besides those described in an SP's metadata, to validate 
> signatures on AuthnRequests issued on an SP's behalf. That's certainly 
> one solution, and one that doesn't require any protocol changes. I 
> think I'd be happier if the third party was explicitly identified in 
> the request, say as the issuer, and there was some other place to 
> identify the target SP, but would require a protocol change...

Sure, and as I said, this is conceptually possible today using an
AuthnRequest, but it needs to be profiled, and it is more complex. It's also
not optimal because it is true that while "requester" and "relying party"
are both named as potential actors in the prose, the "relying party" isn't
specifically identified in the request except perhaps in an Audience in the
input Conditions.

Adding something like a "RespondTo" attribute in the Request base type would
probably adequately have handled this general case of a requester asking a
responder to send an unprompted response to somebody else.

Alternatively of course it could be handled at the binding layer outside the
protocol. In either case, fields like AssertionConsumerServiceIndex would be
based on the identity of the intended recipient, not the original requester
as today.

Since we really can't do any of this without revving the spec, it's probably
preferable to look for a simpler solution that might at least allow for
signing by such a portal. The tight binding of the portal to the IdP
(domain-wise) made that seem at least feasible.

-- Scott