sorry to jump in late here - but i would also be interested in making signatures simple(r) to keep them in the core spec. i would be very interested in helping out on that front if need be.
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 >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
