RE: [security-services] AssertionConsumerServiceIndex vs. AssertionConsumerURL

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

>  > <SubjectConfirmationData Recipient="URL submitted by bad provider">
> 
> Ahh... makes more sense now.  I thought the Recipient would have a
> ProviderID in it, not the URL that the response was sent to.

Right. See lines 548-549 of CD SSO profile, and related text later on. It's
clear that whatever the potential use of the attribute, this profile calls
out placing the URL there, whereas the entityID of the SP is in the
Audience, as in ID-FF.

> I'm not sure we want the URL in there in cases where this assertion
> isn't being used on an browser based SSO transaction.  Need to
> think about this some more.

Please do...clarifying my thinking on this, this doesn't support a use case
for the assertion to be re-used in a context in which the bearer
confirmation really is being satisfied by anybody but the browser in the
initial delivery, thus baking the URL and the short time window into that
data element.

Contrast this with a scenario in which the SP exchanges the assertion for a
new "bearer token" it can use by returning it to the issuer. In such a case,
we've discussed the "special" sense in which the original issuer isn't
really processing the assertion in a normal fashion (i.e. it knows the SP
isn't claiming to be the subject but would be able to show that it's the
relying party).

Also note that additional subject confirmations could be placed into the
token to enable the SP to use the token with holder-of-key semantics, and in
such a case, the bearer confirmation isn't valid, but doesn't need to be.

Freely admit this needs more thought, but that was the idea.

-- Scott