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
