Re: [OAUTH-WG] Proposal: OAuth 1.0 signature in core with revision

I also think we should focus on finishing OAuth 2 core and deal with
signatures in a separate spec.

Not sure what are optional 1.0a signatures really buying.

Client developers given an option in most cases will go with bearer
tokens. If server developers want to enforce signatures, or provide
the option, they can always implement OAuth 1.0a (for the time being).
Is that much worse than enforcing OAuth 2 with 1.0a signatures?

The only other argument I am aware of is that IETF will not approve
OAuth 2 core if there are no signatures in it. Is this a guess? How
come this was not an issue until recently?

Marius

On Mon, Sep 27, 2010 at 9:36 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> Since you were asking for votes earlier, I’ll add a -1.  I believe the
> industry would be better served by approving a draft soon without
> signatures, and then working on signatures separately.
>
>
>
>                                                             -- Mike
>
>
>
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of
> Eran Hammer-Lahav
> Sent: Sunday, September 26, 2010 11:44 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: [OAUTH-WG] Proposal: OAuth 1.0 signature in core with revision
>
>
>
> Building on John Panzer’s proposal, I would like to ask if people have
> strong objections to the following:
>
>
>
> - Add the 1.0a RFC language for HMAC-SHA-1 signatures to the core
> specification in -11
>
> - Discuss the signature language on the list and improve both prose and
> signature base string construction
>
> - Apply improvements to -12
>
>
>
> Keeping the 1.0a signature in the core specification makes sense and builds
> on existing experience and deployment. If we can reach quick consensus on
> some improvements, great. If not, we satisfy the need of many here to offer
> a simple alternative to bearer tokens, without having to reach consensus on
> a new signature algorithm suitable for core inclusion.
>
>
>
> ---
>
>
>
> I have seen nothing to suggest that this working group is going to reach
> consensus on a single signature algorithm worthy of core inclusion. I agree
> with John that at least the 1.0a algorithm is well understood and already
> deployed. I can live with it used without changes, which will also allow
> reusing existing code with 2.0. I think we can improve it by making small
> changes, but have better things to do with my time than spend the next few
> months arguing over it.
>
>
>
> By including the 1.0a text in -11, we will have a feature complete
> specification that I hope many people here can live with if it doesn’t
> change (which looks more likely).
>
>
>
> My question is, who here has strong objections to this, and cannot live with
> the core specification including the 1.0a HMAC-SHA1 algorithm?
>
>
>
> EHL
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>