SubjectConfirmation Method is read but never checked

Start in lua/resty/saml.lua by tracing saml.doc_assertions into confirmation_ok and reading how SubjectConfirmation methods are currently handled. Confirm that only bearer confirmations are satisfiable, while holder-of-key and sender-vouches are refused; the unused method field may alternatively be removed as described.

What

saml.doc_assertions reports method for every SubjectConfirmation it reads, and confirmation_ok in lua/resty/saml.lua never looks at it. Every method is treated as satisfiable once the Recipient and the time window hold.

Why it matters

The method states how the presenter is meant to prove they are the subject. urn:oasis:names:tc:SAML:2.0:cm:bearer asks for nothing beyond presentation, and it is the one this callback implements. holder-of-key asks for proof of a key and sender-vouches rests on an attesting party, and nothing here performs either. Accepting them claims work that never happened.

The practical impact is small for the deployments this library serves. An IdP configured for browser SSO issues bearer assertions only, and AudienceRestriction already refuses an assertion minted for whatever other service a holder-of-key flow serves.

It sits above zero because a holder-of-key assertion is built to be safe to leak: its security rests on the recipient checking the key, so it circulates with far less care than a bearer one. One reaching this callback under a matching audience is accepted today as though it were bearer.

Fix

Count a confirmation as satisfiable only when its Method is bearer. There is nothing extra to verify, since bearer means presentation is the proof, so the change only refuses the methods this code cannot honour. The alternative is dropping method from the reader, so that no unused field dangles for the next person auditing this.

Noticed on #42, which added the field. Left out of that PR to keep it to the scope of #37.