Hi Nat, in the MAC discussions I was only talking about the interaction between the client and the resource server.
Ciao Hannes On Aug 15, 2012, at 4:41 AM, Nat Sakimura wrote: > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
