Errata comments

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

PE39:

I think the wording here is off. Leaving aside recent discussions about this
stuff in parallel, Prateek proposes:

"The holder of a specified key is considered to be an acceptable attesting
entity for the assertion by the relying party."

I think it's the asserting party that considers this, not the relying party.
Not sure if that's an accidental mistake or intentional change.

PE43:

I'm unclear on one issue in the closing paragraph of the proposed addition:

"In some cases, legacy implementations of SAML may implicitly identify the
KeyInfo, simply through inclusion of EncryptedKey, together with
EncryptedData, within the SAML EncryptedID. Note that this approach MUST NOT
be used when there is to be more than one instance of EncryptedID in the
transmitted XML or more than one EncryptedKey is included in the transmitted
XML."

I don't understand how I can possibly use this feature of XML Encryption if
I DO want to include multiple EncryptedKey elements (e.g. multicasting the
encryption). The spec seems to require that a given EncryptedData reference
a single key. The whole reason the SAML schema was setup this way was due to
that limitation. So how can I transmit multiple keys but follow the
restrictions here?

Or did I misread the XML Encryption spec/schema? If so, sorry about that. I
wouldn't have bothered to add the EncryptedKey with maxOccurs="unbounded" if
that's possible to express some other way.

If not, I think XML Encryption is broken, personally, but then SAML needs
its own mechanism to express this and this seems to preclude using it.

-- Scott