Couple comments on the comments inline: On Wed, Aug 10, 2011 at 3:39 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > > 4.1. Using Assertions for Client Authentication: Comment on “client_id”: > “It seems like a bad idea to have the client_id outside of the assertion. > It’s either redundant or insecure.” >
I tend to agree with this. Now that treatment of client_id seems to have stabilized in the core spec, this draft is probable due for some reconciliatory changes around the parameter. > > 7. Error Responses: Comment on “Audience validation failed”: “Isn’t > returning this kind of information just helping an attacker to hone their > attack by trying various values and seeing what errors they get? I’m not > sure how serious this threat is though. But I get nervous any time we leak > data about security validation failures.” Trying to walk the line between security and having useful feedback available for troubleshooting during the early stages of deployments. Given that there's a signature over the assertion, providing details about other semantic validation issues doesn't seem like an issue to me. But I know that such information disclosure is usually considered a no no in security related contexts. Anyway, the error_description parameter is optional so individual implementation/deployments can make their own decisions about what, if anything, to put there and/or when to put info there. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
