Are there use cases for putting everything into a single object? Absolutely! It's a great thing to be able to do, and we are using JWT and its kin all over the place to do just that. In Connect's case, there were other, more complex data structures that were at play that the request object uses. But if I just wanted to protect the default parameters with a signature, why should I jump through the hoops of putting it into a container? Are you really suggesting that in order to get signature protection on parameters, we should put everything into container objects? To me, this feels like a move back to SOAP more than anything else, and I'd like an alternative.
Could the MAC-draft be a lot better at defining these parameters? Absolutely, which is why I think we need to fix it. History informs us but it doesn't define us: Just because it hasn't been done right yet doesn't mean that it can't be done. Signing with the MAC algorithm *should* be simple. It should be at least as easy and powerful as OAuth1, and hopefully much easier if we do it right. I think that there have been real suggestions about *how* to do this as well.
At the end of the day, I think we need both approaches for different uses and deployments.
-- Justin On 08/14/2012 03:17 PM, Mike Jones wrote:
Replying to Justin's point about the OpenID Connect signed request object, Justin, I don't believe this comparison is accurate. When an OpenID Request Object is signed, a single, self-contained object is being signed. The signing described in the MAC spec signs a combination of payload elements and transport elements. It's a testament to the complexity of this approach that Eran kept changing which elements were signed and which weren't in successive drafts. Signing an OpenID Connect Request Object is simple (just apply JWS). Signing using the MAC algorithm is an exercise left to the reader... -- Mike -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Phil Hunt Sent: Friday, August 10, 2012 10:03 AM To: Richer, Justin P. Cc: [email protected] WG Subject: Re: [OAUTH-WG] MAC Discussion There's no reason why the spec, or key elements of it can't be re-used. But to assume it should be "THE" spec, goes against previous formal consensus (can't remember if it was Quebec or Paris meeting) and jumps the gun on defining what the problem is. If we jump into a spec without defining the problem, we're guessing. What I saw of the previous email discussion was a lot of circular debate indicating no clear problem definition. I agree, it would be nice to re-use code from previous implementations. But that strikes me as an issue to raise when we discuss the implementation based upon future consensus of the problem. Phil @independentid www.independentid.com [email protected] On 2012-08-10, at 7:49 AM, Richer, Justin P. wrote: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_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
