On Aug 10, 2012, at 3:00 AM, Hannes Tschofenig wrote: > Justin wrote: > " > I believe that there's value in per-message signing completely apart from the > channel level encryption. > " > > May well be. But we have to figure out what exactly the reasons are why there > is value.
Yes, there is value in this, and that's why we're collecting a handful of use cases to support this. Otherwise, people wouldn't keep reinventing this. See SAML and OpenID Connect's signed request object for other examples. > > Bill wrote: > " > I find the idea of starting from scratch frustrating. MAC solves a set of > specific problems and has a well defined use case. > " > > This would be a very quick process if we had ever done our home work > properly. It's not done, but it's not empty. Why throw it out? Whether or not we continue the draft itself or import its best ideas into a new draft is beside the point. > > So, what are the problems it tries to solve? Yesterday I found an old > presentation about MAC and the basic argument was that it has better > performance than TLS. While that's true it is not a good argument per se. > However, performance is not the only factor to look at and the negative > performance impact caused by TLS is overrated. This is a red herring, as pointed out by other use cases. > > Here is the slide set I am talking about: > http://www.tschofenig.priv.at/Why_are_we_Signing.pdf > > In many cases I had noticed that more time was spent with the pictures (in > slides and blog post) than with the content. That's not good IMHO. > > Bill, we can hardly call a specification "complete" if many of us don't know > what problem it solves. John phrases it nicely as "Part of the problem with > MAC has been that people could never agree on what it was protecting > against." I am also interested in hearing about deployment constraints that > people have. Blaine always said that many developers cannot get TLS to work. > I am sure that's true but OAuth 2.0 requires TLS to be used anyway to secure > the interaction with the authorization server. It solves this problem: How can I use the framework of OAuth to get a temporary signing key that I can use to protect HTTP messages with signing (without stuffing my parameters into a structured document like a SAML or JWT assertion)? There are many justifications for that problem and use cases that expand on this, but that's the core thing that the MAC does. > > Note: I am not saying that we are not going to standardize something like the > MAC token (maybe with different details) but let us spend a little bit of > time to figure out what threats we want to deal with. It's not just about threats, it's about capabilities and features. -- Justin > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
