What does the bearer subject confirmation method mean, and which fields limit the damage if such an assertion is stolen?

"Bearer" means whoever presents the assertion is treated as the subject, with no proof of key possession; NotOnOrAfter, Recipient and InResponseTo narrow when, where and in reply to what it may be used.

<SubjectConfirmation> answers "how does the SP know the party presenting this assertion is entitled to it?" With urn:oasis:names:tc:SAML:2.0:cm:bearer, the answer is: it doesn't. Like cash or a concert ticket, possession is enough. That is simple and works with any browser, but it means a stolen assertion works for the thief.

The <SubjectConfirmationData> attributes therefore act as damage limiters:

• NotOnOrAfter: a short deadline (ten minutes in the example) after which the assertion may no longer be used to log in.
• Recipient: the exact assertion consumer service URL at the SP where it must be delivered; an assertion posted to any other endpoint is rejected.
• InResponseTo: the ID of the SP's own <AuthnRequest>; the SP accepts the assertion only as an answer to a request it actually sent.

On top of this the SP should remember the IDs of assertions it has already consumed and reject repeats (one-time use), so a captured assertion cannot simply be replayed in the remaining minutes.

Tip: The alternative method, holder-of-key, binds the assertion to a key the user must prove they hold. It is the cure for exactly the weakness bearer assertions have.

Go deeper:

• SAML 2.0: Bearer assertion (Wikipedia) — the subject confirmation fields and how an SP must check them.
• OASIS: SAML V2.0 Profiles (PDF) — section 4.1.4 lists the assertion processing rules for Web Browser SSO.