As an implementer, I have an app that accesses 10 different resources. Some are OAuth 1.0A, some are a variant of OAuth 2. All have a slightly different code path since each resource is its own beautiful snowflake. I did not use any libraries for OAuth 2. Supporting MAC would give me yet another library to integrate with.
I'd be interested in what signing problems OAuth 1.0A has. I have my own list of how writing to OAuth 1.0A is hard. On Aug 9, 2012, at 10:53 AM, William Mills wrote: > MAC fixes the signing problems encountered in OAuth 1.0a, yes there are > libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model > and will provide for a single codepath for sites that want to use both Bearer > and MAC. > > From: Dick Hardt <[email protected]> > To: William Mills <[email protected]> > Cc: "[email protected]" <[email protected]> > Sent: Thursday, August 9, 2012 10:27 Aa > Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 > > > On Aug 9, 2012, at 9:52 AM, William Mills wrote: > >> I find the idea of starting from scratch frustrating. MAC solves a set of >> specific problems and has a well defined use case. It's symmetric key based >> which doesn't work for some folks, and the question is do we try to develop >> something that supports both PK and SK, or finish the SK use case and then >> work on a PK based draft. >> >> I think it's better to leave them separate and finish out MAC which is *VERY >> CLOSE* to being done. > > Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. > > For my projects, I prefer the flexibility of a signed or encrypted JWT if I > need holder of key. > > Just my $.02 > > -- Dick > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
