On Thu, May 27, 2010 at 8:56 AM, David Recordon <record...@gmail.com> wrote:
> I thought Allen clearly said that signing with the client secret won't work > for Yahoo!? Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures at all. So I think we're good from the Yahoo! side of things. Allen - did I get this right? Dirk. > > Hi Dirk- > > >> We at Yahoo would be very much against using the client secret for signing >> requests to Protected Resources, since this would require that the client >> secret be distributed to the PR endpoints. For security reasons, one of the >> design goals for WRAP was to keep the client secret a secret between only >> the AS and the Client – deliberately separating the authentication of the >> client (on the AS) from the serving of the protected resource. > > >> From your post, it’s not quite clear what the disadvantage is with using >> the Access Token secret for generating signatures. > > >> (forgive me if this was already discussed today - I was very zonked out >> after 3 days of IIW) > > >> Thanks > > Allen > > > > On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz <balf...@google.com> wrote: > >> Sorry, I didn't mean to turn this into a debate over whether we should >> have signatures. I think you guys stated your case clearly, and there are >> other use cases as well. >> >> The questions I was trying to figure out was whether >> >> - you'd be ok using the client secret to sign instead of the token secret >> (I think I heard David say that that was ok), >> - you'd be ok with a signature scheme that's sufficiently factored out of >> the rest of the spec that it might warrant it's own companion spec (I agree >> that this is getting close to bikeshed territory, so let's worry about this >> once we know what the signatures look like). >> >> Dirk. >> >> >> On Wed, May 26, 2010 at 2:17 PM, Luke Shepard <lshep...@facebook.com>wrote: >> >>> So, when I argued for signatures, the specific use cases we are concerned >>> with: >>> >>> - Mobile handsets and networks that don't support SSL very well >>> - High-volume applications where SSL is a significant cost to both sides >>> - for Facebook, the top few apps make up a significant amount of API >>> traffic, so we could do signatures for them and not for everyone else >>> >>> I expect that these are issues that others will encounter as they expand >>> into these areas- especially on the mobile side. These are not >>> Facebook-specific issues. >>> >>> That said, I agree with David that we should just figure out what the >>> signatures are - I don't really care where they live. If they need to live >>> in a separate spec then whatever, as long as the specs interoperate very >>> cleanly. But I would like to hear from other mobile developers if they have >>> tried OAuth 2.0 with success (Brian, I think you mentioned you may have some >>> data about that?) >>> >>> On May 26, 2010, at 11:20 AM, David Recordon wrote: >>> >>> How about we figure out the technical details of signatures before >>> figuring out where they're placed? :) </bikeshed> >>> >>> >>> On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz <balf...@google.com>wrote: >>> >>>> Ok - to those advocating a separate spec: What if the separate spec was >>>> really simple (a couple of pages), and we just pasted it as "Section X" >>>> into >>>> the core OAuth spec? >>>> >>>> To Facebook: What if the core OAuth spec had a section called "Signed >>>> OAuth Requests" that (in its extreme form) had the single sentence: "If PRs >>>> require signing, then Clients use the XYZ mechanism to sign their OAuth >>>> requests" (with a link to XYZ)? >>>> >>>> Dirk. >>>> >>>> >>>> On Wed, May 26, 2010 at 10:55 AM, David Recordon >>>> <record...@gmail.com>wrote: >>>> >>>>> I'd prefer that we keep signatures simple enough that they can remain >>>>> in the core spec. >>>>> >>>>> --David >>>>> >>>>> >>>>> >>>>> On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz <balf...@google.com>wrote: >>>>> >>>>>> Repeating what I said before: >>>>>> >>>>>> - separate spec is fine by me >>>>>> - part of the point I'm trying to make is that that spec shouldn't be >>>>>> about signed _tokens_, but instead about signed _HTTP requests_ (so >>>>>> instead >>>>>> of merely proving that you know a secret that came with the token, you >>>>>> prove who you are when you use the token). >>>>>> >>>>>> I'd be interested what the Facebook guys think about this - I believe >>>>>> the current signature scheme is in there mostly to address a use case >>>>>> they >>>>>> had. >>>>>> >>>>>> Luke, Dave - would a separate signing spec be ok with you guys? >>>>>> >>>>>> Dirk. >>>>>> >>>>>> >>>>>> On Tue, May 25, 2010 at 6:56 PM, Allen Tom <a...@yahoo-inc.com>wrote: >>>>>> >>>>>>> +1 >>>>>>> >>>>>>> I fully agree with Dirk and Brian that there needs to be some work on >>>>>>> signatures. There are many types of applications that require higher >>>>>>> levels >>>>>>> of security than what bearer tokens can provide. >>>>>>> >>>>>>> That being said, I think that bearer token/refresh token model can >>>>>>> satisify >>>>>>> the majority of use cases - in fact it would satisfy 100% of all >>>>>>> public APIs >>>>>>> that we have at Yahoo. >>>>>>> >>>>>>> Perhaps in the interest of keeping the spec focused, it would make >>>>>>> more >>>>>>> sense to split out a Signed Token Spec, as Justin proposes, that is >>>>>>> focused >>>>>>> solely on uses cases that require a signature? >>>>>>> >>>>>>> Allen >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 5/21/10 11:27 AM, "Richer, Justin P." <jric...@mitre.org> wrote: >>>>>>> >>>>>>> > I have a slightly more radical proposal. What if we factor out the >>>>>>> signed >>>>>>> > token use case into a parallel spec? The OAuth 2.0 Signed Token >>>>>>> spec, given >>>>>>> > the same attention by the group and all that like Eran was talking >>>>>>> about >>>>>>> > yesterday. What this would take is taking out all reference to >>>>>>> signing and >>>>>>> > making core OAuth just about bare tokens, then have a separate spec >>>>>>> that >>>>>>> > details what to call your shared secret parameters, how to get >>>>>>> them, and how >>>>>>> > to sign with them. This makes the core spec a lot simpler (as >>>>>>> detailed below) >>>>>>> > but makes the overall use case of using signed tokens more >>>>>>> complicated to >>>>>>> > follow, as it'd be split in two. >>>>>>> > >>>>>>> > -- justin >>>>>>> > ________________________________________ >>>>>>> > From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of >>>>>>> Dirk >>>>>>> > Balfanz [balf...@google.com] >>>>>>> > Sent: Thursday, May 20, 2010 7:39 PM >>>>>>> > To: OAuth WG >>>>>>> > Subject: [OAUTH-WG] proposal for factoring out request signing in >>>>>>> OAuth 2 >>>>>>> > >>>>>>> > Hi guys, >>>>>>> > >>>>>>> > at today's interim meeting, we were discussing Brian Eaton's >>>>>>> proposal for >>>>>>> > OAuth signatures. He was proposing a mechanism that would (1) do >>>>>>> away with >>>>>>> > base string canonicalization, (2) allow for symmetric and public >>>>>>> keys, and (3) >>>>>>> > allow for extensibility. >>>>>>> > >>>>>>> > He got homework from the group to prove the feasibility of his >>>>>>> proposal by >>>>>>> > showing a couple of implementations. >>>>>>> > >>>>>>> > In this post, I would like to introduce another improvement of the >>>>>>> OAuth 2 >>>>>>> > signing mechanism, one which is orthogonal to Brian's proposal >>>>>>> (i.e., it would >>>>>>> > work both with the signing mechanism in the current spec, as well >>>>>>> as with >>>>>>> > Brian's signature mechanism). The goal of my proposal is twofold: >>>>>>> > >>>>>>> > - it simplifies the spec. It will become more readable and >>>>>>> therefore easier to >>>>>>> > implement >>>>>>> > - it separates out the mechanisms for delegated authorization and >>>>>>> for >>>>>>> > integrity protection into two independent pieces, which can be put >>>>>>> together by >>>>>>> > Servers and/or Clients like LEGO blocks. >>>>>>> > >>>>>>> > Summary: >>>>>>> > >>>>>>> > - use the client secret instead of the token secret for signing PR >>>>>>> access >>>>>>> > requests. >>>>>>> > >>>>>>> > Long version of the proposal: >>>>>>> > >>>>>>> > - remove all references to access tokens that are not bearer tokens >>>>>>> from the >>>>>>> > spec. >>>>>>> > - stop calling the access tokens "bearer tokens". Call them just >>>>>>> "access >>>>>>> > tokens". >>>>>>> > - remove all references to token secrets from the spec >>>>>>> > - remove all parts of the spec that are of the kind "if >>>>>>> bearer_token then X, >>>>>>> > else Y", and replace them with X. >>>>>>> > - delete section 5.3 >>>>>>> > - add a section called "Request Authentication" that goes something >>>>>>> like this: >>>>>>> > >>>>>>> > "Servers may require that requests be authenticated by the Client, >>>>>>> so that >>>>>>> > presentation of the access token alone is not sufficient to access >>>>>>> a Protected >>>>>>> > Resource. This has several use cases, including, but not limited >>>>>>> to, the >>>>>>> > following: >>>>>>> > >>>>>>> > - Non-repudiation: high-security deployments may require that >>>>>>> requests be >>>>>>> > authenticated (signed) in a non-repudiateable way[1] >>>>>>> > - Access to protected resources is not protected by SSL, so that >>>>>>> access tokens >>>>>>> > may leak. >>>>>>> > - End-to-end-integrity: even if SSL _is_ used, network >>>>>>> infrastructure may >>>>>>> > strip SSL protection before the request reaches the protected >>>>>>> resource. The >>>>>>> > protected resource, however, may require end-to-end integrity. >>>>>>> > >>>>>>> > If the Server requires that the Client authenticate PR access >>>>>>> requests, then >>>>>>> > the Client uses the following mechanism to sign their HTTP >>>>>>> requests: [...]" >>>>>>> > >>>>>>> > Then, we basically drop the old Section 5.3 here (except we use the >>>>>>> client >>>>>>> > secret instead of the access token secret). Eventually, instead of >>>>>>> Section >>>>>>> > 5.3, we may have Brian's new signature scheme section here, which >>>>>>> would add >>>>>>> > the option of public-key crypto[1], etc. >>>>>>> > >>>>>>> > What do you guys think? >>>>>>> > >>>>>>> > Dirk. >>>>>>> > >>>>>>> > [1] Technically speaking, the goal of non-repudiation can only be >>>>>>> achieved >>>>>>> > once we have public-key crypto. >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > OAuth mailing list >>>>>>> > OAuth@ietf.org >>>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>> >>>> >>> <ATT00001..txt> >>> >>> >>> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
