Good catch Brian - client_id and client_secret now seem mandatory when reading draft 9. When those were originally added to the flow, they were clearly marked as optional. That is lost in the latest drafts.
We'd be happy with either optional or removed. Mandatory doesn't work for us at all. -cmort On 7/7/10 9:40 AM, "Brian Eaton" <bea...@google.com> wrote: Hi folks - What is the story with the evolution of the assertion profile? As far as I can tell, it keeps changing for no good reason. Everyone who wants to implement the profile has the exact same requirements, and agreed on how it should work a long time ago. Here's the timeline: - a bunch of people get together and do WRAP. It contains a flow that exchanges a signed assertion for a short-lived bearer token. - WRAP becomes OAuth2. Assertion profile is dropped. - People protest. - Assertion profile is added back. - OAuth2 interim meeting: a bunch of people stand up and say they either have implemented or are implementing the assertion profile. (Note that this is a superset of the people who worked on WRAP. More organizations have come on board.) - Everything is fine until draft 7 of the OAuth 2 spec is published. Assertion profile has changed, security is screwed up. People protest. - Draft 8 makes it even worse, adding new secrets with no visible purpose. - Yaron notices, complains, is told that he should write new spec language. - Yaron writes new language. - Argument starts over whether this is really necessary. This is beginning to seem brain dead. Can we please put the assertion profile back the way it was in WRAP and Draft 6 of the OAuth 2 spec? This is a critical use case for a bunch of companies, all of whom have already agreed on how it should work, and most of whom already have working implementations. It's fine with me if people have other use cases for assertions, and need new protocol flows to support those use cases. But that's a terrible reason to screw up the existing use cases. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
