Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues

[Mark Mcgloin <[e-mail]>]

Eran Hammer-Lahav <[e-mail]> 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