Eran Hammer-Lahav <e...@hueniverse.com> wrote on 29/09/2010 15:50:33:
> > > > -1 to splitting acquiring and using a token. It may not confuse > people actively > > engaged in the WG but what about everyone else? > > We are already splitting it, by putting signatures elsewhere. Just > because you might think bearer tokens are the 'obvious choice' and > signatures are the 'optional more advance choice', you are still > splitting the protocol over multiple parts. It is just that your > preferred way of splitting it is optimized to what you care most > about. I have made the same argument about the readability of the > specification without signatures in core and was shut down because > it will delay the work too much and other reasons. > Yes I know and I realise there are conflicting opinions and you want a compromise. I do not want to block that, hence my mild -1, but want to raise these 2 points now before the split in case others feel they are important points. > > Also, as Torsten and I look at security considerations, I wonder > if there are > > some examples that link the threat model for acquiring a token and using a > > token. > > This is possible, but there is absolutely no benefit from the way > the draft is structured today. If you strive to offer a complete and > comprehensive solution and security review, you clearly have to > include signatures in the same document. How would you discuss these > examples and dependencies without the full picture? IOW, how is > including bearer token but not other alternatives make answering > these questions in the core specification any easier? Why is it any > less useful to discuss these questions in each of the token > authentication schemes? After all, it is the nature of the scheme > that dictates everything else. > > This argument is valid but has nothing to do with moving section 5 out. > I think acquiring and using a token can be considered core as you always need both. I don't have valid security consideration linkage between acquiring and using the token to back up my assertion that it may confuse developers if we separate them (yet) > This leaves readability as the only potential argument against > splitting. Why not try it out? What's the worse that will happen? We > have to put it back in and look for a different compromise? > > And last, if you are going to opposed this proposal, then the burden > is on you to offer an alternative that is going to address the > concerns and parameters presented in my original post. By > definition, a compromise means you don't get everything you want, so > what are you willing to give up to help resolve these otherwise > blocking issues? I am not trying to tease anyone, but asking an > sincere question. Every other proposal has been rejected with > sufficient resistance to suggest it will not last through the > multiple review stages. > I am fine with breaking the spec if it means progress towards review stages > EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
