So, are we talking about the authz request or resource request? =nat via iPhone
On Aug 15, 2012, at 5:49 AM, Justin Richer <[email protected]> wrote: > I would argue that it's exactly the process that you describe below that > makes my original comparison accurate. As a strawman example, OAuth2 core > specifies a bunch of parameters that get sent to the Auth Endpoint, like > scope and response_type. OpenID Connect defines a few more, like display. In > order to get these protected by a signature, I have to take them out of the > HTTP parameters and put them into a secondary object for message transit. > What I believe you're missing is that there are times where I don't *want* to > bundle everything up into a container object. Sure it's a relatively > straightforward process to create a JSON object and sign it with JWS, but > then the server has to unfurl the whole thing. What if I *want* to use my > existing HTTP processors for pulling out variables? What if I need to do > routing based on these? Connect takes the approach of letting you specify > things in both the object and the query params and has rules about how their > values have to match. The way we've had to do this in one of our systems is to take that signed JSON, preprocess it, and pretend that it's a parameter map so that other parts of the system can make any sense of it. I don't want to have to repeat that for every API I want to protect in a similar manner. > > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
