On Tue, Jul 13, 2010 at 8:11 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > - client credentials information was always problematic because people > expressed interest in using it with pre-arranged authorizations, in which > case, the client may be acting on behalf of an end-user. ... > I suggested adding actual profiles to the spec, which would accomplish what > your want to see "restored". However it is not clear to me how to name these > and how to guide developers when to use them. ...
I've been giving some thought to this problem. As far as I can tell, here is what has happened. 1) several people have gotten together and put together a tightly-specified proposal to meet a particular use case 2) that's gotten added 3) others have chimed in with slight modifications to meet slightly different use cases 4) that's gotten added 5) step 3 and 4 repeat for a while. 6) the detailed proposal written in step 1 and 2 has gotten screwed up We haven't gotten to step 7 yet, but I'm pretty sure it involves non-interoperable implementations. I think the problem here is step 4. Rather than making everything optional so we can meet every possible use case, we need to start telling people to go write up new profiles to meet their use cases. Given the choice between two tightly specified protocol flows and a single vague protocol flow, we should prefer tightly specified. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
