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 >>> >>> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
