I received the below over the weekend and, although [email protected] is cc'd, it didn't post to the list - I assume because [email protected] isn't subscribed. I thought I should send to the WG list so folks are aware.
I don't believe EncryptedAssertion should be supported, for three main reasons. 1) It is very late in the document process, which is currently in IESG review. It's too late, really, for a change like this. 2) It adds complexly that's not necessarily needed as the Subject and/or individual attributes of a SAML Assertion can be encrypted to the authorization server 3) It greatly increases the risk that usage of this profile be vulnerable to attacks such as those described in http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/ whereas having the encrypted parts appear under a signature (and not attempting decryption if the signature validation fails) mitigates the risk ---------- Forwarded message ---------- From: <[email protected]> Date: Sat, Oct 18, 2014 at 4:05 PM Subject: EncryptedAssertion in draft-ietf-oauth-saml2-bearer-21 To: [email protected] Cc: [email protected], [email protected] Seems sec 3, list item 10 (p.8) mentions that encryption per SAML2 is allowed, but I think it would be helpful to call out that specifically EncryptedAssertion is allowed. Mentioning EncryptedAssertion as valid possibility in secs 2.2 and 2.3 would also help. The Privacy Considerations section should mention use of EncryptedAssertion to protect against eavesdropping by intermediaries that handle assertions (e.g. OAUTH Client which gets it from STS and passes it to AS). Cheers, --Sampo
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
