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

[Eran Hammer-Lahav <[e-mail]>]

> -----Original Message-----
> From: Mark Mcgloin [mailto:[e-mail]]
> Sent: Wednesday, September 29, 2010 12:55 AM

> I echo Dick's sentiment, mildly
> 
> -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.

> 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.  So:
> 
> 1) Will the decisions a service provider make when granting a token depend
> on, or affect, the use case for using that token?
> 2) Will the use case, grant type or other flow parameters a client selects for
> acquiring a token, depend on how they will use that token?
> 
> I don't have concrete examples to back this up but possibilities include:
> automatic granting of access token, refresh tokens, non-secure channels, ??

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.

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.

EHL