As I see, the current draft is half way towards the complete modularization. It has abstracted what parameters are needed for each end points from various flows but failed to stop there and included how they are to be passed as well. IMHO, how they are passed is the profile/binding issue and all these language should be removed and moved to profile specs.
=nat @ Tokyo via iPhone On 2010/07/15, at 14:32, Brian Eaton <bea...@google.com> wrote: > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
