RE: [security-services] A browser/POST question...

>In the browser/artifact profile, we now say that ConfirmationData SHOULD NOT
>be supplied.  But in Browser/POST, we say nothing about ConfirmationData. I
>looked back through the mail archive, but couldn't find a conclusive
>statement.  For consistency and completeness of the B&P spec, I think we
>should provide a normative statement about it.  I've assumed MUST NOT
>applies, but then I haven't thought about it a lot.  So is ConfirmationData
>a "MUST NOT", "SHOULD NOT", "MAY", or something else?

I hadn't considered the possibility until Irving made a comment at the presentation we gave this week, but one *could* put a key in
there and tie that to an SSL client certificate as a way of restricting the validity of the assertion, while relieving the target of
the burden of validating the cert. But that wouldn't really be a bearer assertion any more, and the profile dictates use of Bearer
rather than Holder of Key.

So I'd think that as currently defined, it ought to be a MUST NOT, but could be revisited in 2.0 to permit such a use case if
there's interest.

-- Scott