From oleg_gryb@yahoo.com Fri Nov 2 09:16:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4FC21F8CB9 for ; Fri, 2 Nov 2012 09:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXUeEvPO21dv for ; Fri, 2 Nov 2012 09:16:53 -0700 (PDT) Received: from nm30-vm2.bullet.mail.ne1.yahoo.com (nm30-vm2.bullet.mail.ne1.yahoo.com [98.138.91.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1F321F8CB1 for ; Fri, 2 Nov 2012 09:16:53 -0700 (PDT) Received: from [98.138.226.176] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 02 Nov 2012 16:16:46 -0000 Received: from [98.138.89.254] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 02 Nov 2012 16:16:46 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 02 Nov 2012 16:16:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 737920.12364.bm@omp1046.mail.ne1.yahoo.com Received: (qmail 56746 invoked by uid 60001); 2 Nov 2012 16:16:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351873006; bh=Jo0MsA7PuXw5ViUKtdslm9Wuy0Oqrp/E4igCYcGIJw0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=q4vTuJcNkMYjpApXnSRwNTbBW65AqHBeuyynCQxKa0VkTBgXL1cIuNbaKTwKa3T77B3VHevZGXkKqCwZtezjHs6XI8xmUfVrjhstUi0katgsqtltj1MK2jNbtBxnLfw9BGOKgRhi93HrQp8uh8QS3UpMgE/SQszw9bhieY9Ec7A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=BWL7DPQ+MiNVhzVPbf9Vd3TKUnOqL4oOPTeusG3f2X/Z8xxNDyz1mdiRZxSHOa6dxNDjawa8a2Iit8EhqV3m4i8faiItYt6y4qnPdLFr6zi2IuDmSSi20yo4miTHYyM9hZ9Gz3MjWuNyxysQcfG4VgK0AzQ5cQZ+8nBkcKaCxII=; X-YMail-OSG: hqFwNvcVM1mpthNRAAVEmpcgWNSdYM5BIjH1KcteC.4Ku8Q Nbk4qISuq3rTa5Bhezhv5nu3vJW7fkk1HRvMAVS1CeeV0JXBztCTwFXKaayj RIMWmtDGw9aC3jtY.XtCOBYFBH2ze80Kzaw3e4O3CO4PHBiPP0OyKpD1gAkr J7v00DDsgmh21WK5kK3HkyTCrDBzByaOt1KT5aAtm58g8qGARobda9V8izKE B5Cj5SXUNvaFNHyj85dYsztLjseff0oApgMYDAbRDQXmMJ5V54a9h4qvh7vz rsm54wCMFZgE3qmfqp0knI3NdLaZHKxEphPVKARUZup6AVa9GiOPoEAoNgt6 cLSjl1qgF29tkqHadJl2UXmdK5guXB8HdcLoJZJrXwUxwTCNx.IUy1mFKnjF gZZwefG59JbZUYU_RzKJhSZ6AJR2aTu6qJLCjmRQFR8HApNTAerL6bT4v.34 zqYlt4cNI.Ud0X.baGaCsHoFuEvp0Q9gihtHSgfqEU3OjBth2LOGu2aFD6dn 7HMuuLqUkiVbLWanAgxUW_V1_dZZuaq2Egqn6wqlHadp_YTVg3gm9MHLh3y5 syuU7Xu_8hcjSZNH3MA8rnaS6c0UsGyPRXVYQbcvWJoK8RY03w1RDJamWSLZ I51Bj_JCBwbJC5x2.8AE- Received: from [199.16.140.30] by web121003.mail.ne1.yahoo.com via HTTP; Fri, 02 Nov 2012 09:16:46 PDT X-Rocket-MIMEInfo: 001.001, Q2FuIHNvbWVib2R5IHBsZWFzZSBwcm92aWRlIGNsYXJpZmljYXRpb24gZm9yIHRoaXM6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLXRocmVhdG1vZGVsLTA1I3NlY3Rpb24tNS4xLjQuMi4yNS4xLjQuMi4yLiAgSGlnaCBlbnRyb3B5IG9mIHNlY3JldHMuLi4KICAgVGhlIHByb2JhYmlsaXR5IG9mIGFueSB0d28gQXV0aG9yaXphdGlvbiBDb2RlCiAgIHZhbHVlcyBiZWluZyBpZGVudGljYWwgc2hvdWxkIGJlIGxlc3MgdGhhbiBvciBlcXVhbCB0byAyXigtMTI4KSBhbmQBMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1351873006.52556.YahooMailClassic@web121003.mail.ne1.yahoo.com> Date: Fri, 2 Nov 2012 09:16:46 -0700 (PDT) From: Oleg Gryb To: torsten@lodderstedt.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2027350018-1941087300-1351873006=:52556" Cc: oauth@ietf.org Subject: [OAUTH-WG] OAuth token entropy X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: oleg@gryb.info List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:16:53 -0000 ---2027350018-1941087300-1351873006=:52556 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Can somebody please provide clarification for this: http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.4= .2.25.1.4.2.2. High entropy of secrets...=0A The probability of any two = Authorization Code=0A values being identical should be less than or equal= to 2^(-128) and=0A should be less than or equal to 2^(-160). Is there any reason why we have two inclusive conditions in this statement = or is it a typo and you meant something else? =A0 ---2027350018-1941087300-1351873006=:52556 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Can somebody please provide clarification for= this:
http://tools.ietf=
.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.4.2.2
5.1.4.2.2.  =
High entropy of secrets
...=0A   The probability of any two Auth=
orization Code=0A   values being identical should be less than or equal to =
2^(-128) and=0A   should be less than or equal to 2^(-160).


Is= there any reason why we have two inclusive conditions in this statement or= is it a typo and you meant something else?
 
---2027350018-1941087300-1351873006=:52556-- From bcampbell@pingidentity.com Fri Nov 2 11:19:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572021F0C59 for ; Fri, 2 Nov 2012 11:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM4AM2wYaldU for ; Fri, 2 Nov 2012 11:19:52 -0700 (PDT) Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAEF1F0C60 for ; Fri, 2 Nov 2012 11:19:52 -0700 (PDT) Received: from mail-vc0-f198.google.com ([209.85.220.198]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKUJQOx5X9SUBDX6k7mgvtvSFfYKhCvdah@postini.com; Fri, 02 Nov 2012 11:19:52 PDT Received: by mail-vc0-f198.google.com with SMTP id d16so6560930vcd.1 for ; Fri, 02 Nov 2012 11:19:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=r5JKq6EsBAxMzA1zJDxZrf9/RWcHQOvOWWq0zsZjUa8=; b=AlfqFm6NgAdmelHjDI0sd6qL8J046yr+27dSnFKUnH3h1/GRjx5gAN/I7fj41oDL03 yb27bEjcsskoW9OyiDgtxVuYDiWVzKWPbkv/HbjhWrQ1j0FxW0PNu/zgWHEaAs1EAbLX vIbD1z/Jzzxeh6JPraTr+KuUDxxoiIx1qUrseEmk3NAOvsTQyrz2M/3zHDYlNLjFg7Ri fp+LNbaNhIXsDvOmDfItneCwVoOiiYyKDVGZBx60MbpS8H/EwEAm0BOR9FIXrAQyfOLg KjC9sOEB++97fzA4nT95TA8MSSO3b3ZFnU987qXRkgLWXE3m4lC+mk4mCHgbn89AkESf zjPg== Received: by 10.49.85.202 with SMTP id j10mr3922520qez.59.1351880390818; Fri, 02 Nov 2012 11:19:50 -0700 (PDT) Received: by 10.49.85.202 with SMTP id j10mr3922485qez.59.1351880390468; Fri, 02 Nov 2012 11:19:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.6.3 with HTTP; Fri, 2 Nov 2012 11:19:20 -0700 (PDT) In-Reply-To: <1351873006.52556.YahooMailClassic@web121003.mail.ne1.yahoo.com> References: <1351873006.52556.YahooMailClassic@web121003.mail.ne1.yahoo.com> From: Brian Campbell Date: Fri, 2 Nov 2012 12:19:20 -0600 Message-ID: To: Oleg Gryb Content-Type: multipart/alternative; boundary=047d7bdc8d2073e2ba04cd872ef8 X-Gm-Message-State: ALoCoQkG7FDoaHEpy+oCvunzc+n1QzJPl9AkwgguLNgXnelNM36zX49yp82wEIlPXNFsLmya002XtzCPJ/9w8oHGVQzOGI1ZcJo2e58wfOHb+/ZzqHc8Lcm+kM+q0p+3MC4somEvmRqk Cc: oauth Subject: Re: [OAUTH-WG] OAuth token entropy X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:19:53 -0000 --047d7bdc8d2073e2ba04cd872ef8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe the original text (which was borrowed from elsewhere) had a must followed by a should rather than two shoulds like that. The text seems to have drifted a bit in various places but the threat model text should probably be aligned with what's in core OAuth at http://tools.ietf.org/html/rfc6749#section-10.10 On Fri, Nov 2, 2012 at 10:16 AM, Oleg Gryb wrote: > Can somebody please provide clarification for this: > > http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-= 05#section-5.1.4.2.25.1.4.2.2 . High entropy of secrets... > The probability of any two Authorization Code > values being identical should be less than or equal to 2^(-128) and > should be less than or equal to 2^(-160). > > > > Is there any reason why we have two inclusive conditions in this statemen= t > or is it a typo and you meant something else? > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --047d7bdc8d2073e2ba04cd872ef8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe the original text (which was borrowed from elsewhere) had a must = followed by a should rather than two shoulds like that. The text seems to h= ave drifted a bit in various places but the threat model text should probab= ly be aligned with what's in core OAuth at http://tools.ietf.org/html/rfc6749#section= -10.10


On Fri, Nov 2= , 2012 at 10:16 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:=
Can somebody please provide clarification= for this:



http://tools.ietf.o=
rg/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.4.2.2



5.1.4.2.2.  High entropy of secrets
...
   The probability of any two Authorization Code
   values being identical should be less than or equal to 2^(-128) and
   should be less than or equal to 2^(-160).


Is there any reas= on why we have two inclusive conditions in this statement or is it a typo a= nd you meant something else?
=A0

______= _________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--047d7bdc8d2073e2ba04cd872ef8-- From phil.hunt@oracle.com Fri Nov 2 11:29:03 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8238411E80E2 for ; Fri, 2 Nov 2012 11:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=4.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9a71Qy0RbNb for ; Fri, 2 Nov 2012 11:29:02 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 77C5B11E80DE for ; Fri, 2 Nov 2012 11:29:02 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA2IStnc013053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Nov 2012 18:28:56 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA2IStfw015188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2012 18:28:55 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qA2ISs8U000862; Fri, 2 Nov 2012 13:28:54 -0500 Received: from [192.168.1.131] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Nov 2012 11:28:17 -0700 MIME-Version: 1.0 Message-ID: <35A9F1DF-798C-4649-A000-EA122760B330@oracle.com> Date: Fri, 2 Nov 2012 11:28:23 -0700 (PDT) From: Phil Hunt To: Brian Campbell References: <1351873006.52556.YahooMailClassic@web121003.mail.ne1.yahoo.com> In-Reply-To: X-Mailer: Apple Mail (2.1283) Content-Type: multipart/alternative; boundary="__1351880934583197732abhmt105.oracle.com" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Oleg Gryb , oauth Subject: Re: [OAUTH-WG] OAuth token entropy X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:29:03 -0000 --__1351880934583197732abhmt105.oracle.com Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I believe the IESG wanted a higher level of entropy. It looks like the = text may have gotten mangled along the way. Torsten do you recall? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-11-02, at 11:19 AM, Brian Campbell wrote: > I believe the original text (which was borrowed from elsewhere) had a = must followed by a should rather than two shoulds like that. The text = seems to have drifted a bit in various places but the threat model text = should probably be aligned with what's in core OAuth at = http://tools.ietf.org/html/rfc6749#section-10.10 >=20 >=20 > On Fri, Nov 2, 2012 at 10:16 AM, Oleg Gryb = wrote: > Can somebody please provide clarification for this: >=20 >=20 >=20 >=20 > = http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.= 4.2.2 >=20 >=20 >=20 > 5.1.4.2.2. High entropy of secrets >=20 > ... > The probability of any two Authorization Code > values being identical should be less than or equal to 2^(-128) and > should be less than or equal to 2^(-160). >=20 >=20 > Is there any reason why we have two inclusive conditions in this = statement or is it a typo and you meant something else? > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --__1351880934583197732abhmt105.oracle.com Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I = believe the IESG wanted a higher level of entropy. It looks like the = text may have gotten mangled along the way.  Torsten do you = recall?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-11-02, at 11:19 AM, Brian Campbell wrote:

I believe = the original text (which was borrowed from elsewhere) had a must = followed by a should rather than two shoulds like that. The text seems = to have drifted a bit in various places but the threat model text should = probably be aligned with what's in core OAuth at http://tools.iet= f.org/html/rfc6749#section-10.10


On Fri, = Nov 2, 2012 at 10:16 AM, Oleg Gryb <oleg_gryb@yahoo.com> = wrote:
Can somebody please provide = clarification for this:



http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmod=
el-05#section-5.1.4.2.2



5.1.4.2.2.  High entropy of =
secrets
...
   The probability of any two Authorization Code
   values being identical should be less than or equal to 2^(-128) and
   should be less than or equal to 2^(-160).


Is there any = reason why we have two inclusive conditions in this statement or is it a = typo and you meant something = else?
 

_________________________= ______________________
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

= --__1351880934583197732abhmt105.oracle.com-- From oleg_gryb@yahoo.com Fri Nov 2 11:58:57 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D381C11E80E4 for ; Fri, 2 Nov 2012 11:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9lIzDUkLp7B for ; Fri, 2 Nov 2012 11:58:57 -0700 (PDT) Received: from nm1-vm0.bullet.mail.ne1.yahoo.com (nm1-vm0.bullet.mail.ne1.yahoo.com [98.138.91.74]) by ietfa.amsl.com (Postfix) with ESMTP id E2CAE11E80E2 for ; Fri, 2 Nov 2012 11:58:56 -0700 (PDT) Received: from [98.138.90.52] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 02 Nov 2012 18:58:53 -0000 Received: from [98.138.89.252] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 02 Nov 2012 18:58:53 -0000 Received: from [127.0.0.1] by omp1044.mail.ne1.yahoo.com with NNFMP; 02 Nov 2012 18:58:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 942454.43630.bm@omp1044.mail.ne1.yahoo.com Received: (qmail 81527 invoked by uid 60001); 2 Nov 2012 18:58:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351882733; bh=WrX5nUSY2Ojh5pjVZ4/4oLC1iVJdo5U3ARzgNvOIWzw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=l2sJ+kwFt4DazmM/BIYG7czBgJ+1S0VznrzjhTBg+ZWwIxiBcAbI8GEVhNXxbdtaf/WEfZp6IyxNThbenSllRzkec2h/GAHMPQWXadibsJFaAORZj/lV5/MDfapC58AqLrlbqTOBlEHguCAhfbNHBgtcwrVmPGu/ttt9nkfAYdU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RLc9TCd91ER60UOObxsJE4h2idGMeNr0njJD3pZi95NIYoTzxDQqkajn4pBPWaYvA4eWV/maLV9udhF7gix8s7OVKUTorvAUiSb5D0lpxJ+llgXaKoRWnx839nnlJf9lmFopK+jDhBslqHW/7lnOXMaheyExum2B2CmQfapbhIg=; X-YMail-OSG: zZOxEDgVM1mKqiQ_6Qqmf0qyvN1N49V9SXo2Mt2k2ISEZO3 Rt.tEArnyDkHK68hWS1DYpP4sYtLeoiGi9FM6hw_7hVG5dmj2lmD0MD9Pm9w vKoOPTgcCbeFGgSLiDqqb3khJEzBkt1NG3DBcox.gmR2MN0tVHI6Vx.zH63V TzcJ5C8MNJUTiAVPNpLAroWdaU4MqjwWfGhOY6RxNyT.M9YhWvksEQzCMTPt MeV1zjKvlroiHdVNGXJHy6uEr6vI0SQRnzR1rWkteSA7vMcthcY86FK0zwo0 uenF_MlX2CyX3rBHfqZSehEOkcUEWG62XVmB6LK2pIA7eZtWbjR8Nm8czQR4 OsPxpZ0aBzPuhvCcdpTIPqXYQ.o2u2q3SOgfiACljJE3R8NS5_mjqdALxpp9 n55Hh0oRC1zA32qtLjKBlZaaNcmGTnYgR8xCx5q5Co1b1rAZcFDYjBYkf9Ow 8BrY3akYOahTTmOsm1MS7k7d7qIVKs0eL6vMuJz9atsJS_8_V7GgY5zvgcWD 8AFH4mcNNMNbDFZ93LmjovbAyQ.rHGKh_pEZbnWV880zdWwTuYw9_YgB2lL3 FlEFsCbf7fKU5s10mCLQyiJ6qmfSzGg-- Received: from [199.16.140.30] by web121004.mail.ne1.yahoo.com via HTTP; Fri, 02 Nov 2012 11:58:53 PDT X-Rocket-MIMEInfo: 001.001, VGhhbmtzLCBCcmlhbi4gIk11c3QiIGZvciAxMjggYml0cyBtYWtlcyBwZXJmZWN0IHNlbnNlLiAxNjAgYml0cyBsb29rcyBnb29kIGFzIGEgcmVjb21tZW5kZWQgZW50cm9weSBhcyB3ZWxsLg0KDQpXRywNCg0KUGxlYXNlIHVwZGF0ZSB0aGUgZG9jLiBJdCdzIGltcG9ydGFudCB0byBwcm92aWRlIGNsZWFyIGd1aWRlbGluZXMgZm9yIE9BdXRoIGltcGxlbWVudGVycywgd2hpY2ggYXJlIG1hbnkgbm93YWRheXMuIA0KDQotLS0gT24gRnJpLCAxMS8yLzEyLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmcBMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1351882733.77358.YahooMailClassic@web121004.mail.ne1.yahoo.com> Date: Fri, 2 Nov 2012 11:58:53 -0700 (PDT) From: Oleg Gryb To: Oleg Gryb , Brian Campbell In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1562933420-397370934-1351882733=:77358" Cc: oauth Subject: Re: [OAUTH-WG] OAuth token entropy X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: oleg@gryb.info List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:58:58 -0000 ---1562933420-397370934-1351882733=:77358 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Brian. "Must" for 128 bits makes perfect sense. 160 bits looks good= as a recommended entropy as well. WG, Please update the doc. It's important to provide clear guidelines for OAuth= implementers, which are many nowadays.=20 --- On Fri, 11/2/12, Brian Campbell wrote: From: Brian Campbell Subject: Re: [OAUTH-WG] OAuth token entropy To: "Oleg Gryb" Cc: "Torsten Lodderstedt" , "oauth" Date: Friday, November 2, 2012, 2:19 PM I believe the original text (which was borrowed from elsewhere) had a must = followed by a should rather than two shoulds like that. The text seems to h= ave drifted a bit in various places but the threat model text should probab= ly be aligned with what's in core OAuth at http://tools.ietf.org/html/rfc67= 49#section-10.10 =0A=0A On Fri, Nov 2, 2012 at 10:16 AM, Oleg Gryb wrote: =0A=0ACan somebody please provide clarification for this: =0A=0Ahttp://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section= -5.1.4.2.2=0A=0A5.1.4.2.2. High entropy of secrets...=0A The probability= of any two Authorization Code=0A values being identical should be less t= han or equal to 2^(-128) and=0A should be less than or equal to 2^(-160). Is there any reason why we have two inclusive conditions in this statement = or is it a typo and you meant something else? =A0 _______________________________________________ =0A=0A=0AOAuth mailing list =0AOAuth@ietf.org =0Ahttps://www.ietf.org/mailman/listinfo/oauth =0A =0A ---1562933420-397370934-1351882733=:77358 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable ---1562933420-397370934-1351882733=:77358-- From ve7jtb@ve7jtb.com Fri Nov 2 14:40:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B8A11E80F2 for ; Fri, 2 Nov 2012 14:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vbzty2ZW+koK for ; Fri, 2 Nov 2012 14:40:22 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E22DB11E80E3 for ; Fri, 2 Nov 2012 14:40:21 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j40so1154990qab.10 for ; Fri, 02 Nov 2012 14:40:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=vOlVR+QugZgTvue68AhqvHdSaFEgx6emmgoMkTnNjlU=; b=HtJoxc27zJvQclf/0Ofgcb/Zl1I56g3a/PbXsfUItuaZzpxucak057WKNMEnI35/yY Eejrr4vsZH2F+Avb1J6EIskNI/tTxCBOcXVY9EDCoxRwg4z2vwt8NQtp0JEiEkC0KxJs 9w2sL+rl9oZ8uGE63fT/9yvM+qvOzu7a4upzdIhoi5cW/vq0mnbQ0AyRiaXmFLD7CMZY h/nmPWrlWsyHFcIDOFYMl5byHGUIjXjfqVX3HPIN+KIkalxl0LzwcO4VOmWil2H3ExHE DuxBFxTCkMJxxwQMgOV8AgMS0NYv8TTzW62ng8sBygYWOyzl++eyBEdPFX8REYrFPsYU eAWg== Received: by 10.49.1.43 with SMTP id 11mr4842155qej.41.1351892421149; Fri, 02 Nov 2012 14:40:21 -0700 (PDT) Received: from [192.168.1.35] (190-20-34-233.baf.movistar.cl. [190.20.34.233]) by mx.google.com with ESMTPS id y17sm5418087qaa.6.2012.11.02.14.40.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 14:40:20 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_09EEEFF0-06B9-4672-AE45-DD48150AEFBC" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <1351882733.77358.YahooMailClassic@web121004.mail.ne1.yahoo.com> Date: Fri, 2 Nov 2012 18:40:08 -0300 Message-Id: References: <1351882733.77358.YahooMailClassic@web121004.mail.ne1.yahoo.com> To: oleg@gryb.info X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmMX+0A09pU//dmNVuRury8j7ynb0qL8bZtsMd3t4t9kI0Tb7nLrXPrVjL1Q6zq3mX7gZBL Cc: oauth Subject: Re: [OAUTH-WG] OAuth token entropy X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 21:40:23 -0000 --Apple-Mail=_09EEEFF0-06B9-4672-AE45-DD48150AEFBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The change we did to the last ish draft of OAuth to have the client send = its client ID to the token endpoint even if it is not using a password = reduces the need for additional entropy. Originally for public clients using code, an attacker had the address = space of all the inflight codes for all clients. We reduced that to = only being able to attack one client_id at a time. For confidential clients it should not be possible to brute force the = token endpoint. =20 Trying to explain all the issues is hard so those are not bad defaults, = 128 bits is a 20 character character password using the printable ascii = character set for out of band code delivery. John B. On 2012-11-02, at 3:58 PM, Oleg Gryb wrote: >=20 > Thanks, Brian. "Must" for 128 bits makes perfect sense. 160 bits looks = good as a recommended entropy as well. >=20 > WG, >=20 > Please update the doc. It's important to provide clear guidelines for = OAuth implementers, which are many nowadays.=20 >=20 > --- On Fri, 11/2/12, Brian Campbell = wrote: >=20 > From: Brian Campbell > Subject: Re: [OAUTH-WG] OAuth token entropy > To: "Oleg Gryb" > Cc: "Torsten Lodderstedt" , "oauth" = > Date: Friday, November 2, 2012, 2:19 PM >=20 > I believe the original text (which was borrowed from elsewhere) had a = must followed by a should rather than two shoulds like that. The text = seems to have drifted a bit in various places but the threat model text = should probably be aligned with what's in core OAuth at = http://tools.ietf.org/html/rfc6749#section-10.10 >=20 >=20 > On Fri, Nov 2, 2012 at 10:16 AM, Oleg Gryb = wrote: > Can somebody please provide clarification for this: >=20 >=20 >=20 >=20 > = http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.= 4.2.2 >=20 >=20 >=20 > 5.1.4.2.2. High entropy of secrets >=20 > ... > The probability of any two Authorization Code > values being identical should be less than or equal to 2^(-128) and > should be less than or equal to 2^(-160). >=20 >=20 > Is there any reason why we have two inclusive conditions in this = statement or is it a typo and you meant something else? > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_09EEEFF0-06B9-4672-AE45-DD48150AEFBC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 The = change we did to the last ish draft of OAuth to have the client send its = client ID to the token endpoint even if it is not using a password = reduces the need for additional entropy.

Originally = for public clients using code, an attacker had the address space of all = the inflight codes for all clients.   We reduced that to only being = able to attack one client_id at a time.

For = confidential clients it should not be possible to brute force the token = endpoint.  

Trying to explain all the = issues is hard so those are not bad defaults,  128 bits is a 20 = character character password using the printable ascii character set for = out of band code delivery.

John = B.
On 2012-11-02, at 3:58 PM, Oleg Gryb <oleg_gryb@yahoo.com> = wrote:

Thanks, Brian. "Must" for 128 bits makes perf= ect sense. 160 bits looks good as a recommended entropy as well.

WG,=

Please update the doc. It's important to provide clear guidelines f= or OAuth implementers, which are many nowadays.

--- On Fri, 11/2= /12, Brian Campbell <bcampbell@pingidentity.com> wrote:

From: Brian Campbell <bcampbell@pingidenti= ty.com>
Subject: Re: [OAUTH-WG] OAuth token entropy
To: "Oleg Gryb= " <oleg@gryb.info>
Cc: "Torsten Lodderstedt" <torsten@lodderste= dt.net>, "oauth" <oauth@ietf.org>
Date: Friday, November 2, 201= 2, 2:19 PM

I believe the original text (whi= ch was borrowed from elsewhere) had a must followed by a should rather than= two shoulds like that. The text seems to have drifted a bit in various places = but the threat model text should probably be aligned with what's in core OA= uth at http://tools.ietf.org/html/rfc6749#section-10.1= 0
=0A=0A


On Fri, Nov 2, 2012 at 10:16 AM, Oleg Gryb <oleg_gryb@y= ahoo.com> wrote:
=0A=0A
Can somebody please provide cla= rification for this:
=0A=0A=

http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-=
05#section-5.1.4.2.2
=0A=0A
5.1.4.2.2. =
 High entropy of secrets
...=0A   The probability of any two Aut=
horization Code=0A   values being identical should be less than or equal to=
 2^(-128) and=0A   should be less than or equal to 2^(-160).


I= s there any reason why we have two inclusive conditions in this statement o= r is it a typo and you meant something else?
 

_______________________________________________
=0A=0A=0AOA= uth mailing list
=0AOAuth@ietf.org=
=0Ahttps://www.ietf.org/mailman/listinfo/oauth<= br>=0A

=0A
Thanks, Brian. "Must" for 128 bits makes perfect sense. 160 = bits looks good as a recommended entropy as = well.

WG,

Please update the doc. It's important to provide = clear guidelines for OAuth implementers, which are many nowadays. =

--- On Fri, 11/2/12, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

From: Brian = Campbell <bcampbell@pingidentity.com&= gt;
Subject: Re: [OAUTH-WG] OAuth token entropy
To: "Oleg Gryb" = <oleg@gryb.info>
Cc: = "Torsten Lodderstedt" <torsten@lodderstedt.net>, = "oauth" <oauth@ietf.org>
Date: Friday, = November 2, 2012, 2:19 PM

I believe the = original text (which was borrowed from elsewhere) had a must followed by = a should rather than two shoulds like that. The text seems to have drifted a bit in various = places but the threat model text should probably be aligned with what's = in core OAuth at http://tools.iet= f.org/html/rfc6749#section-10.10


On Fri, Nov 2, 2012 at 10:16 AM, Oleg = Gryb <oleg_gryb@yahoo.= com> wrote:
Can somebody please provide = clarification for this:



http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-=
05#section-5.1.4.2.2



5.1.4.2.2.  High entropy of secrets
...
   The probability of any two Authorization Code
   values being identical should be less than or equal to 2^(-128) and
   should be less than or equal to 2^(-160).


Is there any = reason why we have two inclusive conditions in this statement or is it a = typo and you meant something = else?
 

_________________________= ______________________
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

= --Apple-Mail=_09EEEFF0-06B9-4672-AE45-DD48150AEFBC-- From Adam.Lewis@motorolasolutions.com Fri Nov 2 15:23:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC1B21F9AD7 for ; Fri, 2 Nov 2012 15:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.216 X-Spam-Level: X-Spam-Status: No, score=-1.216 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdsD6deEW8UH for ; Fri, 2 Nov 2012 15:23:24 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id AB68321F8599 for ; Fri, 2 Nov 2012 15:23:22 -0700 (PDT) Received: from mail251-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 2 Nov 2012 22:23:22 +0000 Received: from mail251-va3 (localhost [127.0.0.1]) by mail251-va3-R.bigfish.com (Postfix) with ESMTP id 55B339201E6 for ; Fri, 2 Nov 2012 22:23:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.160.210.20; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg01.am.mot-solutions.com; RD:ct11msg01.mot-solutions.com; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371Ic89bhc857hzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received-SPF: pass (mail251-va3: domain of motorolasolutions.com designates 192.160.210.20 as permitted sender) client-ip=192.160.210.20; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg01.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT001.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail251-va3 (localhost.localdomain [127.0.0.1]) by mail251-va3 (MessageSwitch) id 1351894999409721_15383; Fri, 2 Nov 2012 22:23:19 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.244]) by mail251-va3.bigfish.com (Postfix) with ESMTP id 5751D104006D for ; Fri, 2 Nov 2012 22:23:19 +0000 (UTC) Received: from ct11msg01.am.mot-solutions.com (192.160.210.20) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 2 Nov 2012 22:23:16 +0000 Received: from ct11msg01.am.mot-solutions.com (ct11vts02.am.mot.com [10.177.16.160]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id qA2Mggpr004460 for ; Fri, 2 Nov 2012 17:42:42 -0500 (CDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id qA2Mgf36004457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 2 Nov 2012 17:42:42 -0500 (CDT) Received: from mail88-co1-R.bigfish.com (10.243.78.227) by CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id 14.1.225.23; Fri, 2 Nov 2012 22:23:14 +0000 Received: from mail88-co1 (localhost [127.0.0.1]) by mail88-co1-R.bigfish.com (Postfix) with ESMTP id 53E4A20460 for ; Fri, 2 Nov 2012 22:23:14 +0000 (UTC) Received: from mail88-co1 (localhost.localdomain [127.0.0.1]) by mail88-co1 (MessageSwitch) id 1351894991994579_13486; Fri, 2 Nov 2012 22:23:11 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.244]) by mail88-co1.bigfish.com (Postfix) with ESMTP id F0577640019; Fri, 2 Nov 2012 22:23:11 +0000 (UTC) Received: from BY2PRD0411HT001.namprd04.prod.outlook.com (157.56.237.133) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 2 Nov 2012 22:23:11 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.11.21]) by BY2PRD0411HT001.namprd04.prod.outlook.com ([10.255.128.36]) with mapi id 14.16.0233.002; Fri, 2 Nov 2012 22:23:07 +0000 From: Lewis Adam-CAL022 To: "Manger, James H" Thread-Topic: [OAUTH-WG] access tokens & refresh tokens of different scopes Thread-Index: AQHNt6vR6QY+tO/6l0C3kf8asw9cT5fT71MggAAruyCAAt30wIAAKL0Q Date: Fri, 2 Nov 2012 22:23:07 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A92F16775E@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A92F166F7F@BY2PRD0411MB441.namprd04.prod.outlook.com> <5BFC7B8F-8E2E-40B5-A0BD-769DCFC3DA2A@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F166FF5@BY2PRD0411MB441.namprd04.prod.outlook.com> <433A47F7-EED9-4BB7-B781-95430B204D75@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F167058@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A92F1670F6@BY2PRD0411MB441.namprd04.prod.outlook.com> <255B9BB34FB7D647A506DC292726F6E114FFCE6960@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {59AAFDBB-7BD7-4DCA-88EF-3017BF4B112F} x-cr-hashedpuzzle: BUDt DFWn EIOn GceE GfjP G9D8 IC1z IaT9 JMVN KV6O OHDb OeK3 PWFY Pd0B Vg9n VuYA; 2; agBhAG0AZQBzAC4AaAAuAG0AYQBuAGcAZQByAEAAdABlAGEAbQAuAHQAZQBsAHMAdAByAGEALgBjAG8AbQA7AG8AYQB1AHQAaABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {59AAFDBB-7BD7-4DCA-88EF-3017BF4B112F}; YQBkAGEAbQAuAGwAZQB3AGkAcwBAAG0AbwB0AG8AcgBvAGwAYQBzAG8AbAB1AHQAaQBvAG4AcwAuAGMAbwBtAA==; Fri, 02 Nov 2012 22:22:58 GMT; UgBFADoAIABbAE8AQQBVAFQASAAtAFcARwBdACAAYQBjAGMAZQBzAHMAIAB0AG8AawBlAG4AcwAgACYAIAByAGUAZgByAGUAcwBoACAAdABvAGsAZQBuAHMAIABvAGYAIABkAGkAZgBmAGUAcgBlAG4AdAAgAHMAYwBvAHAAZQBzAA== x-originating-ip: [184.78.105.93] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A92F16775EBY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%TEAM.TELSTRA.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 22:23:25 -0000 --_000_59E470B10C4630419ED717AC79FCF9A92F16775EBY2PRD0411MB441_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmFtZXMsDQoNCldpc2ggSSB3ZXJlIGFyb3VuZCBhdCB0aGUgdGltZSB0aGF0IHdhcyBkaXNj dXNzZWQsIGJ1dCBkb3VidCBteSBwcmVzZW5jZSB3b3VsZCBoYXZlIHRpcHBlZCB0aGUgc2NhbGVz IDopDQoNCllvdSBhY3R1YWxseSBtYWtlIGFub3RoZXIgcG9pbnQgdGhhdCBJIHdvdWxkIGZpbmQg dmVyeSB2YWx1YWJsZSBhbmQgdGhhdCBpcyB0byBvYnRhaW4gbXVsdGlwbGUgYWNjZXNzIHRva2Vu cyAob2YgZGlmZmVyZW50IHNjb3BlcykgaW4gYSBzaW5nbGUgcmVxdWVzdC4gIE15IHVzZSBjYXNl cyB3aWxsIGhhdmUgYSBjbGllbnQgYWNjZXNzaW5nIGF0IGxlYXN0IHRocmVlIGRpZmZlcmVudCBy ZXNvdXJjZSBzZXJ2ZXJzIG9uIGJlaGFsZiBvZiB0aGUgdXNlci4gIFVzaW5nIHZhbmlsbGEgT0F1 dGggSSBoYXZlIHRvIGdvIHRocm91Z2ggdGhlIGZvbGxvd2luZyBPQXV0aCByb3VuZCB0cmlwcyAo bm90IGluY2x1ZGluZyBwcmltYXJ5IGF1dGhlbnRpY2F0aW9uIHRvIHRoZSBBUyk6DQoNCg0KMS4g ICAgICBBdXRob3JpemF0aW9uIHJlcXVlc3QgLyBhdXRob3JpemF0aW9uIHJlc3BvbnNlICh3aXRo IHNjb3BlPXJzMStyczIrcnMzKQ0KDQoyLiAgICAgIEFjY2VzcyB0b2tlbiByZXF1ZXN0IC8gYWNj ZXNzIHRva2VuIHJlc3BvbnNlIChnaXZlcyBtZSBBVCB3aXRoIHNjb3BlPXJzMStyczIrcnMzIGFu ZCBSVCkuICBJIG5lZWQgdG8gZGlzY2FyZCB0aGUgQVQgYmVjYXVzZSBpdHMgc2NvcGUgaXMgdG9v IHByb21pc2N1b3VzIHRvIHNlbmQgdG8gYW55IGdpdmVuIFJTLg0KDQozLiAgICAgIEFjY2VzcyB0 b2tlbiByZXF1ZXN0ICh1c2luZyBSVCkgd2l0aCBzY29wZT1yczEgLyBhY2Nlc3MgdG9rZW4gcmVz cG9uc2UgKEFUIGZvciByczEpDQoNCjQuICAgICAgQWNjZXNzIHRva2VuIHJlcXVlc3QgKHVzaW5n IFJUKSB3aXRoIHNjb3BlPXJzMiAvIGFjY2VzcyB0b2tlbiByZXNwb25zZSAoQVQgZm9yIHJzMikN Cg0KNS4gICAgICBBY2Nlc3MgdG9rZW4gcmVxdWVzdCAodXNpbmcgUlQpIHdpdGggc2NvcGU9cnMz IC8gYWNjZXNzIHRva2VuIHJlc3BvbnNlIChBVCBmb3IgcnMzKQ0KDQpGaXZlIHJvdW5kIHRyaXBz IGlzIGdvaW5nIHRvIGtpbGwgbWUuICBBbmQgbXkgZ3Vlc3MgaXMgdGhhdCB3ZSB3aWxsIGFkZCBt b3JlIHJlc291cmNlIHNlcnZlcnMgaW4gdGhlIGZ1dHVyZSB0byB0aGF0IHRoaXMgY2xpZW50IHdp bGwgYWNjZXNzIG1ha2luZyBpdCBldmVuIHdvcnNlLiAgSWYgdGhlcmUgd2FzIGEgd2F5IHRvIGdl dCBhbGwgdGhyZWUgZG93bi1zY29wZWQgYWNjZXNzIHRva2VucyArIHRoZSBmdWxseSBzY29wZWQg cmVmcmVzaCB0b2tlbiBpbiBzdGVwIDIsIHRoZW4gdGhpcyB3b3VsZCBiZSBoaWdobHkgZWZmaWNp ZW50Lg0KDQpJ4oCZbSBub3JtYWxseSBhIGNvbnN1bWVyIG9mIElFVEYgZWZmb3J0cyByYXRoZXIg dGhhbiBhIGNvbnRyaWJ1dG9yLCBidXQgSeKAmWQgYmUgaW50ZXJlc3RlZCBpbiB3b3JraW5nIG9u IHRoaXMgaWYgdGhlIFdHIGFncmVlcyBpdOKAmXMgd29ydGh3aGlsZS4gIEl0IHNlZW1zIGF0IGxl YXN0IHlvdSBhbmQgVG9yc3RlbiBhZ3JlZSBpbiBwcmluY2lwbGUg4oCmIHdoYXQgbGV2ZWwgb2Yg Y3JpdGljYWwgbWFzcyBpcyByZXF1aXJlZCB0byBnZXQgc29tZXRoaW5nIG1vdmluZz8NCg0KYWRh bQ0KDQoNCkZyb206IE1hbmdlciwgSmFtZXMgSCBbbWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0u dGVsc3RyYS5jb21dDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMzEsIDIwMTIgODowMSBQTQ0K VG86IExld2lzIEFkYW0tQ0FMMDIyDQpDYzogIldHIDxvYXV0aEBpZXRmLm9yZz4iQGlsMDZleHIw MS5tb3QuY29tDQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBhY2Nlc3MgdG9rZW5zICYgcmVmcmVz aCB0b2tlbnMgb2YgZGlmZmVyZW50IHNjb3Blcw0KDQpBZGFtLA0KDQpJ4oCZbGwgY2hpbWUgaW4g YW5kIHNheSB5b3UgaGF2ZSBhIHJlYXNvbmFibGUgcmVxdWlyZW1lbnQgKGdldHRpbmcgdG9rZW5z IHdpdGggZGlmZmVyZW50IHNjb3BlcyAoZm9yIGRpZmZlcmVudCByZXNvdXJjZSBzZXJ2ZXJzKSBl ZmZpY2llbnRseSkuIE92ZXIgdGhlIGxhc3QgZmV3IHllYXJzIHRoZXJlIGhhdmUgYmVlbiBhIG51 bWJlciBvZiBwcm9wb3NhbHMgZm9yIE9BdXRoIHRvIHN1cHBvcnQgdGhpcyAoYnkgYWxsb3dpbmcg YW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gcmV0dXJuIG11bHRpcGxlIHRva2VucywgZWFjaCB3 aXRoIHRoZWlyIG93biBzY29wZSkuIFVuZm9ydHVuYXRlbHksIGRlc3BpdGUgc29tZSBzdXBwb3J0 LCB0aGUgcHJvcG9zYWxzIHdlcmUgcmVqZWN0ZWQgZm9yIHRoZSBjb3JlIHNwZWMuIFRoZXJlIHdh cyBzdHJvbmcgcmVzaXN0YW5jZSB0byBhbnkgY29tcGxleGl0eSB0aGF0IHdhc27igJl0IGFic29s dXRlbHkgbmVjZXNzYXJ5IGZvciB0aGUgYmFzaWMgdXNlIGNhc2Ug4oCUIGFuZCBmbGV4aWJpbGl0 eSBmb3IgbGlrZWx5ICh0aG91Z2ggbWF5YmUgbmljaGUpIHNjZW5hcmlvcyBzdWNoIGFzIHlvdXJz IHdhcyBub3Qgc3VmZmljaWVudCBtb3RpdmF0aW9uLg0KDQpBcyBpdCB0dXJucyBvdXQsIG9uZSBz aWduaWZpY2FudCBlYXJseSB1c2Ugb2YgT0F1dGgyIGRvZXMgbmVlZCBhbiBleHRyYSB0b2tlbiAo dGhlIElEIHRva2VuIGluIE9wZW5JRCBDb25uZWN0KS4gVGhhdCBpcyBiZWluZyBzdXBwb3J0ZWQg d2l0aCBzb21lIGFkZGl0aW9ucyB0byBPQXV0aDIgdGhhdCBhcmUgaGlnaGx5IHNwZWNpZmljIHRv IE9wZW5JRCBDb25uZWN0IHNvIGl0IGRvZXMgbm90IGhlbHAgeW91ciByZXF1aXJlbWVudC4NCg0K LS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExld2lzIEFkYW0tQ0FMMDIyDQpT ZW50OiBUaHVyc2RheSwgMSBOb3ZlbWJlciAyMDEyIDQ6MDEgQU0NClRvOiBvYXV0aEBpZXRmLm9y Zw0KU3ViamVjdDogW09BVVRILVdHXSBhY2Nlc3MgdG9rZW5zICYgcmVmcmVzaCB0b2tlbnMgb2Yg ZGlmZmVyZW50IHNjb3Blcw0KDQpJIGhhdmUgYSB1c2UgY2FzZSB3aGVyZSBJIHdvdWxkIGxpa2Ug dG8gcmVxdWVzdCBib3RoIGFuIGFjY2VzcyB0b2tlbiBhbmQgYSByZWZyZXNoIHRva2VuLCBidXQg SSB3b3VsZCBsaWtlIHRoZSBhY2Nlc3MgdG9rZW4gdG8gaGF2ZSBhIHNjb3BlIGxlc3MgdGhhbiB0 aGF0IG9mIHRoZSByZWZyZXNoIHRva2VuLiAgSXQgaXMgc3RhbmRhcmQgT0F1dGggYmVoYXZpb3Ig Zm9yIHVzaW5nIHRoZSByZWZyZXNoIHRva2VuIHRvIHJlcXVlc3QgYWRkaXRpb25hbCBhY2Nlc3Mg dG9rZW5zIChvZiBlcXVhbCBvciBsZXNzZXIgc2NvcGUpIGJ1dCB0aGUgZmlyc3QgYWNjZXNzIHRv a2VuIHRoYXQgY29tZXMgYmFjayBhbHdheXMgaGFzIHRoZSDigJxtYXN0ZXIgc2NvcGXigJ0gb2Yg dGhlIHJlZnJlc2ggdG9rZW4uDQoNCkZvciB2YXJpb3VzIHNlY3VyaXR5IGNvbmNlcm5zLCBJIGFs d2F5cyB3YW50IG15IGFjY2VzcyB0b2tlbnMgdG8gYmUgb2YgYSBzdHJpY3RlciBzY29wZSB0aGF0 IHRoZSByZWZyZXNoIHRva2VuLiAgRm9yIGV4YW1wbGUsIGNvbnNpZGVyIHRoZSBzY2VuYXJpbyBv ZiBhIHN0cnVjdHVyZWQgKEpXVCkgYWNjZXNzIHRva2VuIHRoYXQgZG9lcyBub3QgcmVxdWlyZSB0 aGUgUlMgdG8gY2FsbCBiYWNrIHRvIHRoZSBBUyBpbnRyb3NwZWN0aW9uIGVuZHBvaW50LiAgRm9s bG93aW5nIHR5cGljYWwgT0F1dGggZ3VpZGFuY2UsIGl0IGlzIGJlc3QgcHJhY3RpY2UgdG8gdXNl IHNob3J0IGxpdmVkIGFjY2VzcyB0b2tlbnMgd2l0aCBsb25nIGxpdmVkIHJlZnJlc2ggdG9rZW5z LiAgQnV0IEnigJlkIHJhdGhlciBhIGNvbXByb21pc2VkIGFjY2VzcyB0b2tlbiBub3QgY29tcHJv bWlzZSBhY2Nlc3MgdG8gQUxMIG15IHJlc291cmNlIHNlcnZlcnMuDQoNClVzaW5nIHRoZSBleGlz dGluZyBzdGFuZGFyZCBJIGNvdWxkIHNpbXBseSBkZXN0cm95IHRoZSBmaXJzdCBhY2Nlc3MgdG9r ZW4gd2hlbiBpdCBpcyByZWNlaXZlZCBhbmQgdGhlbiByZXF1ZXN0IGFub3RoZXIgb2YgbGVzc2Vy IHNjb3BlIHVzaW5nIHRoZSByZWZyZXNoIHRva2VuLCBidXQgbm93IEnigJl2ZSBqdXN0IHdhc3Rl ZCBhIHJvdW5kIHRyaXAgb3ZlciB0aGUgYWlyLCBjb25zdW1pbmcgYmFuZHdpZHRoIGFuZCBhZGRp bmcgbGF0ZW5jeSB0byB0aGUgZW5kIHVzZXIgZXhwZXJpZW5jZS4NCg0KSXMgdGhlcmUgYW55Ym9k eSBpbiB0aGUgd29ya2luZyBncm91cCB0aGF0IGZlZWxzIHRoaXMgd291bGQgYmUgdmFsdWFibGU/ DQoNCg0KYWRhbQ0K --_000_59E470B10C4630419ED717AC79FCF9A92F16775EBY2PRD0411MB441_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly8yNjg0LyI+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2Ut MToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOm9saXZlOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsN Cglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4u RW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy Mg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOm9saXZlOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0 eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHls ZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6b2xpdmU7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0K CWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6 MTE5NTExNDU3MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTY3MzAxOTkzMiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDox LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOm9saXZlIj5IaSBKYW1lcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm9saXZlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm9saXZlIj5XaXNo IEkgd2VyZSBhcm91bmQgYXQgdGhlIHRpbWUgdGhhdCB3YXMgZGlzY3Vzc2VkLCBidXQgZG91YnQg bXkgcHJlc2VuY2Ugd291bGQgaGF2ZSB0aXBwZWQgdGhlIHNjYWxlcyA6KTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6b2xpdmUiPllvdSBhY3R1YWxseSBtYWtlIGFub3RoZXIgcG9pbnQgdGhhdCBJIHdv dWxkIGZpbmQgdmVyeSB2YWx1YWJsZSBhbmQgdGhhdCBpcyB0byBvYnRhaW4gbXVsdGlwbGUgYWNj ZXNzIHRva2VucyAob2YgZGlmZmVyZW50IHNjb3BlcykgaW4gYSBzaW5nbGUgcmVxdWVzdC4mbmJz cDsgTXkgdXNlIGNhc2VzIHdpbGwgaGF2ZQ0KIGEgY2xpZW50IGFjY2Vzc2luZyBhdCBsZWFzdCB0 aHJlZSBkaWZmZXJlbnQgcmVzb3VyY2Ugc2VydmVycyBvbiBiZWhhbGYgb2YgdGhlIHVzZXIuJm5i c3A7IFVzaW5nIHZhbmlsbGEgT0F1dGggSSBoYXZlIHRvIGdvIHRocm91Z2ggdGhlIGZvbGxvd2lu ZyBPQXV0aCByb3VuZCB0cmlwcyAobm90IGluY2x1ZGluZyBwcmltYXJ5IGF1dGhlbnRpY2F0aW9u IHRvIHRoZSBBUyk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpvbGl2ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 b2xpdmUiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y Om9saXZlIj5BdXRob3JpemF0aW9uIHJlcXVlc3QgLyBhdXRob3JpemF0aW9uIHJlc3BvbnNlICh3 aXRoIHNjb3BlPXJzMSYjNDM7cnMyJiM0MztyczMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 b2xpdmUiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y Om9saXZlIj5BY2Nlc3MgdG9rZW4gcmVxdWVzdCAvIGFjY2VzcyB0b2tlbiByZXNwb25zZSAoZ2l2 ZXMgbWUgQVQgd2l0aCBzY29wZT1yczEmIzQzO3JzMiYjNDM7cnMzIGFuZCBSVCkuJm5ic3A7IEkg bmVlZCB0byBkaXNjYXJkIHRoZSBBVCBiZWNhdXNlIGl0cyBzY29wZSBpcyB0b28gcHJvbWlzY3Vv dXMgdG8gc2VuZCB0byBhbnkNCiBnaXZlbiBSUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpv bGl2ZSI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 b2xpdmUiPkFjY2VzcyB0b2tlbiByZXF1ZXN0ICh1c2luZyBSVCkgd2l0aCBzY29wZT1yczEgLyBh Y2Nlc3MgdG9rZW4gcmVzcG9uc2UgKEFUIGZvciByczEpPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6b2xpdmUiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOm9saXZlIj5BY2Nlc3MgdG9rZW4gcmVxdWVzdCAodXNpbmcgUlQpIHdpdGggc2NvcGU9cnMy IC8gYWNjZXNzIHRva2VuIHJlc3BvbnNlIChBVCBmb3IgcnMyKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOm9saXZlIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj41LjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpvbGl2ZSI+QWNjZXNzIHRva2VuIHJlcXVlc3QgKHVzaW5nIFJUKSB3aXRoIHNjb3Bl PXJzMyAvIGFjY2VzcyB0b2tlbiByZXNwb25zZSAoQVQgZm9yIHJzMyk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm9saXZlIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOm9saXZlIj5GaXZlIHJvdW5kIHRyaXBzIGlzIGdvaW5nIHRvIGtpbGwgbWUuJm5ic3A7 IEFuZCBteSBndWVzcyBpcyB0aGF0IHdlIHdpbGwgYWRkIG1vcmUgcmVzb3VyY2Ugc2VydmVycyBp biB0aGUgZnV0dXJlIHRvIHRoYXQgdGhpcyBjbGllbnQgd2lsbCBhY2Nlc3MgbWFraW5nIGl0IGV2 ZW4gd29yc2UuJm5ic3A7IElmIHRoZXJlIHdhcw0KIGEgd2F5IHRvIGdldCBhbGwgdGhyZWUgZG93 bi1zY29wZWQgYWNjZXNzIHRva2VucyAmIzQzOyB0aGUgZnVsbHkgc2NvcGVkIHJlZnJlc2ggdG9r ZW4gaW4gc3RlcCAyLCB0aGVuIHRoaXMgd291bGQgYmUgaGlnaGx5IGVmZmljaWVudC4mbmJzcDsN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6b2xpdmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPknigJltIG5vcm1hbGx5IGEgY29uc3VtZXIg b2YgSUVURiBlZmZvcnRzIHJhdGhlciB0aGFuIGEgY29udHJpYnV0b3IsIGJ1dCBJ4oCZZCBiZSBp bnRlcmVzdGVkIGluIHdvcmtpbmcgb24gdGhpcyBpZiB0aGUgV0cgYWdyZWVzIGl04oCZcyB3b3J0 aHdoaWxlLiZuYnNwOyBJdCBzZWVtcyBhdCBsZWFzdCB5b3UgYW5kIFRvcnN0ZW4NCiBhZ3JlZSBp biBwcmluY2lwbGUg4oCmIHdoYXQgbGV2ZWwgb2YgY3JpdGljYWwgbWFzcyBpcyByZXF1aXJlZCB0 byBnZXQgc29tZXRoaW5nIG1vdmluZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm9saXZlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm9saXZlIj5hZGFt PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpvbGl2ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpvbGl2ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBNYW5nZXIsIEphbWVzIEggW21haWx0bzpKYW1lcy5ILk1hbmdl ckB0ZWFtLnRlbHN0cmEuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgT2N0b2Jl ciAzMSwgMjAxMiA4OjAxIFBNPGJyPg0KPGI+VG86PC9iPiBMZXdpcyBBZGFtLUNBTDAyMjxicj4N CjxiPkNjOjwvYj4gJnF1b3Q7V0cgJmx0O29hdXRoQGlldGYub3JnJmd0OyZxdW90O0BpbDA2ZXhy MDEubW90LmNvbTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRILVdHXSBhY2Nlc3MgdG9r ZW5zICZhbXA7IHJlZnJlc2ggdG9rZW5zIG9mIGRpZmZlcmVudCBzY29wZXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFkYW0sPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJlsbCBjaGltZSBpbiBhbmQgc2F5IHlvdSBoYXZlIGEgcmVh c29uYWJsZSByZXF1aXJlbWVudCAoZ2V0dGluZyB0b2tlbnMgd2l0aCBkaWZmZXJlbnQgc2NvcGVz IChmb3IgZGlmZmVyZW50IHJlc291cmNlIHNlcnZlcnMpIGVmZmljaWVudGx5KS4gT3Zlcg0KIHRo ZSBsYXN0IGZldyB5ZWFycyB0aGVyZSBoYXZlIGJlZW4gYSBudW1iZXIgb2YgcHJvcG9zYWxzIGZv ciBPQXV0aCB0byBzdXBwb3J0IHRoaXMgKGJ5IGFsbG93aW5nIGFuIGF1dGhvcml6YXRpb24gc2Vy dmVyIHRvIHJldHVybiBtdWx0aXBsZSB0b2tlbnMsIGVhY2ggd2l0aCB0aGVpciBvd24gc2NvcGUp LiBVbmZvcnR1bmF0ZWx5LCBkZXNwaXRlIHNvbWUgc3VwcG9ydCwgdGhlIHByb3Bvc2FscyB3ZXJl IHJlamVjdGVkIGZvciB0aGUgY29yZSBzcGVjLg0KIFRoZXJlIHdhcyBzdHJvbmcgcmVzaXN0YW5j ZSB0byBhbnkgY29tcGxleGl0eSB0aGF0IHdhc27igJl0IGFic29sdXRlbHkgbmVjZXNzYXJ5IGZv ciB0aGUgYmFzaWMgdXNlIGNhc2Ug4oCUIGFuZCBmbGV4aWJpbGl0eSBmb3IgbGlrZWx5ICh0aG91 Z2ggbWF5YmUgbmljaGUpIHNjZW5hcmlvcyBzdWNoIGFzIHlvdXJzIHdhcyBub3Qgc3VmZmljaWVu dCBtb3RpdmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBpdCB0 dXJucyBvdXQsIG9uZSBzaWduaWZpY2FudCBlYXJseSB1c2Ugb2YgT0F1dGgyIGRvZXMgbmVlZCBh biBleHRyYSB0b2tlbiAodGhlIElEIHRva2VuIGluIE9wZW5JRCBDb25uZWN0KS4gVGhhdCBpcyBi ZWluZyBzdXBwb3J0ZWQgd2l0aCBzb21lDQogYWRkaXRpb25zIHRvIE9BdXRoMiB0aGF0IGFyZSBo aWdobHkgc3BlY2lmaWMgdG8gT3BlbklEIENvbm5lY3Qgc28gaXQgZG9lcyBub3QgaGVscCB5b3Vy IHJlcXVpcmVtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkphbWVzIE1hbmdl cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5MZXdpcyBBZGFtLUNBTDAyMjxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgMSBOb3ZlbWJlciAyMDEyIDQ6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IG9hdXRoQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gYWNjZXNzIHRva2VucyAmYW1w OyByZWZyZXNoIHRva2VucyBvZiBkaWZmZXJlbnQgc2NvcGVzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhIHVzZSBjYXNlIHdo ZXJlIEkgd291bGQgbGlrZSB0byByZXF1ZXN0IGJvdGggYW4gYWNjZXNzIHRva2VuIGFuZCBhIHJl ZnJlc2ggdG9rZW4sIGJ1dCBJIHdvdWxkIGxpa2UgdGhlIGFjY2VzcyB0b2tlbiB0byBoYXZlIGEg c2NvcGUgbGVzcyB0aGFuIHRoYXQgb2YgdGhlIHJlZnJlc2ggdG9rZW4uJm5ic3A7IEl0IGlzIHN0 YW5kYXJkIE9BdXRoIGJlaGF2aW9yIGZvciB1c2luZyB0aGUgcmVmcmVzaCB0b2tlbg0KIHRvIHJl cXVlc3QgYWRkaXRpb25hbCBhY2Nlc3MgdG9rZW5zIChvZiBlcXVhbCBvciBsZXNzZXIgc2NvcGUp IGJ1dCB0aGUgZmlyc3QgYWNjZXNzIHRva2VuIHRoYXQgY29tZXMgYmFjayBhbHdheXMgaGFzIHRo ZSDigJxtYXN0ZXIgc2NvcGXigJ0gb2YgdGhlIHJlZnJlc2ggdG9rZW4uJm5ic3A7DQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHZhcmlvdXMgc2VjdXJpdHkgY29uY2VybnMsIEkgYWx3YXlz IHdhbnQgbXkgYWNjZXNzIHRva2VucyB0byBiZSBvZiBhIHN0cmljdGVyIHNjb3BlIHRoYXQgdGhl IHJlZnJlc2ggdG9rZW4uJm5ic3A7IEZvciBleGFtcGxlLCBjb25zaWRlciB0aGUgc2NlbmFyaW8g b2YgYSBzdHJ1Y3R1cmVkIChKV1QpIGFjY2VzcyB0b2tlbiB0aGF0IGRvZXMgbm90IHJlcXVpcmUg dGhlIFJTIHRvIGNhbGwgYmFjayB0byB0aGUgQVMgaW50cm9zcGVjdGlvbg0KIGVuZHBvaW50LiZu YnNwOyBGb2xsb3dpbmcgdHlwaWNhbCBPQXV0aCBndWlkYW5jZSwgaXQgaXMgYmVzdCBwcmFjdGlj ZSB0byB1c2Ugc2hvcnQgbGl2ZWQgYWNjZXNzIHRva2VucyB3aXRoIGxvbmcgbGl2ZWQgcmVmcmVz aCB0b2tlbnMuJm5ic3A7IEJ1dCBJ4oCZZCByYXRoZXIgYSBjb21wcm9taXNlZCBhY2Nlc3MgdG9r ZW4gbm90IGNvbXByb21pc2UgYWNjZXNzIHRvIEFMTCBteSByZXNvdXJjZSBzZXJ2ZXJzLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Vc2luZyB0aGUgZXhpc3Rpbmcgc3RhbmRhcmQgSSBjb3VsZCBz aW1wbHkgZGVzdHJveSB0aGUgZmlyc3QgYWNjZXNzIHRva2VuIHdoZW4gaXQgaXMgcmVjZWl2ZWQg YW5kIHRoZW4gcmVxdWVzdCBhbm90aGVyIG9mIGxlc3NlciBzY29wZSB1c2luZyB0aGUgcmVmcmVz aCB0b2tlbiwgYnV0IG5vdyBJ4oCZdmUganVzdCB3YXN0ZWQgYSByb3VuZCB0cmlwIG92ZXIgdGhl IGFpciwgY29uc3VtaW5nIGJhbmR3aWR0aCBhbmQNCiBhZGRpbmcgbGF0ZW5jeSB0byB0aGUgZW5k IHVzZXIgZXhwZXJpZW5jZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhlcmUgYW55Ym9k eSBpbiB0aGUgd29ya2luZyBncm91cCB0aGF0IGZlZWxzIHRoaXMgd291bGQgYmUgdmFsdWFibGU/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+YWRhbTxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_59E470B10C4630419ED717AC79FCF9A92F16775EBY2PRD0411MB441_-- From oleg_gryb@yahoo.com Sun Nov 4 09:41:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C132821F8774 for ; Sun, 4 Nov 2012 09:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7vgRFe9VEtf for ; Sun, 4 Nov 2012 09:41:55 -0800 (PST) Received: from nm16-vm1.bullet.mail.ne1.yahoo.com (nm16-vm1.bullet.mail.ne1.yahoo.com [98.138.91.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1959521F8770 for ; Sun, 4 Nov 2012 09:41:40 -0800 (PST) Received: from [98.138.226.176] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 04 Nov 2012 17:41:37 -0000 Received: from [98.138.89.164] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 04 Nov 2012 17:41:37 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 04 Nov 2012 17:41:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 772222.88938.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 10635 invoked by uid 60001); 4 Nov 2012 17:41:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352050897; bh=68lUoom06arXHTGcsvuaGV+LoAey5ETd9At/25HkPfk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EJcDXG7eSG0tZeVFjixuHoFv1tLpF7C3+1EcuQ6UWigQww89U/2Yydhcz5DhqYkadrkzRFItOG7iFikVo/h0eDIAE8ZhOh5EUh+dyrezg8lyNnRS1m7cEkRPxZKurfyrOKJbEQBiWxMqFX84l2rU/fvgqcLAfhstng7h7s6XgCw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mNskpzNjAv98sgAnOJCJLiHr2xKalPH2wdjnyUFN3tOa0iLWjnQf6MhQF6hkcDkl3Vi0o6ODFkx908kmbi+UNpwLq6iMyNwZAYEBNNME0bARrZWKnlSkgL3N4JJve+fowygcpWr5iXhZczUyanUtA0GhmhD/oS377dcE2GwM/hU=; X-YMail-OSG: cNJ1da4VM1l44qcemH_7n4qgPutkY8t8OYAK_X.8kVwb8_Q XrTOUb9qYedvDkBPcNxjSL6HTCf44zJMkPOYiPaj1aYPdYK5fiSMtNinDNTj mnV7xA9osgyV6zMYoGd0C3YqYbLapcBsKrpbFNZQseG1PG4FhM4UtnkDr8vy ATfJvM4MBRm01i0xk0l.xN3c.N6a4PXrPs2081MKGmsDJTmkQ.qEz4FRu0jw t1kc0mgclflP5D1CPeDOePQPvAUohc15jtiaXhNK4tk9RxXqWxuPnkmhoY6t ooCBvxDs99WkMXpMH8l2jOJhqH.IHVkJCOyfD5Oc2TGpa6B3TqAwhNqDUPD6 oUO4qlzY8RpXxsSEko90Ikuzo0KZQodJ6guDdOMhZk1LXL8N5FsXlRlO31kO zTzD0yhz1Lwq3_voCSHdDq6mvMS3pwPeupDl15.MnUyT1xtFUgCTMB84XTFK lld2_NkJV1EpmG_nFfVRsCP6i_0qN_m3zn0sTwgYbirwvo4h4dMf_qjgDKuh ja6MxntqN5TG2buQeC4V26ZisrafkJJVsF6JNXC008Wi5CsCqInMi8naBedi BFylNOnj07vcEpLTkMWxjHG0txOd6ZQ-- Received: from [67.121.113.70] by web121004.mail.ne1.yahoo.com via HTTP; Sun, 04 Nov 2012 09:41:37 PST X-Rocket-MIMEInfo: 001.001, Sm9obiwNCg0KSXQgbWFrZXMgcGVyZmVjdCBzZW5zZSB0byBhZGQgY2xpZW50X2lkIGFuZCB2ZXJpZmljYXRpb24gYXMgeW91J3ZlIGRlc2NyaWJlZCwgc2luY2UgdW5saWtlIDEuMCwgY2xpZW50IHNlY3JldHMgYW5kIHNpZ25hdHVyZXMgYXJlIG5vdCByZXF1aXJlZCBpbiAyLjAuIFN0aWxsLCBpZiBhIHB1YmxpYyBjbGllbnQgaXMgYSBiaWcgaGlnaC12b2x1bWUgd2Vic2l0ZSB0aGF0IHRhbGtzIHRvIGEgYmlnIGF1dGhvcml6YXRpb24gc2VydmVyIChlLmcuIFlhaG9vIHRvIEZCKSwgaGF2aW5nIGEgZ29vZCABMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1352050897.2907.YahooMailClassic@web121004.mail.ne1.yahoo.com> Date: Sun, 4 Nov 2012 09:41:37 -0800 (PST) From: Oleg Gryb To: oleg@gryb.info, John Bradley In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1562933420-1141609334-1352050897=:2907" Cc: oauth Subject: Re: [OAUTH-WG] OAuth token entropy X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: oleg@gryb.info List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 17:41:56 -0000 ---1562933420-1141609334-1352050897=:2907 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable John, It makes perfect sense to add client_id and verification as you've describe= d, since unlike 1.0, client secrets and signatures are not required in 2.0.= Still, if a public client is a big high-volume website that talks to a big= authorization server (e.g. Yahoo to FB), having a good entropy (at least 1= 28 bits) is a good idea.=20 Another good idea would be to make a provision in a spec that would say tha= t most likely the entropy will increase in the future OAuth versions. It wo= uld help implementers to make their systems (both clients and authz servers= ) more flexible and avoid 2K like effects in the future. Just think about fast opinion change about the "safe" symmetric key entropy= in SSL for the last 15 years. That opinion was changing so fast that some = privacy/compliance officers could not catch up with that pace and continued= writing in their official privacy policies something like that: "your priv= ate information is protected in transition by SSL with a strong 56-bit encr= yption" in which cases I had to get back to them asking to remove number of= bits from the policy to make it more universal and durable :)=A0 =A0 =A0 = =A0 =A0=20 --- On Fri, 11/2/12, John Bradley wrote: From: John Bradley Subject: Re: [OAUTH-WG] OAuth token entropy To: oleg@gryb.info Cc: "oauth" Date: Friday, November 2, 2012, 5:40 PM The change we did to the last ish draft of OAuth to have the client send it= s client ID to the token endpoint even if it is not using a password reduce= s the need for additional entropy. Originally for public clients using code, an attacker had the address space= of all the inflight codes for all clients. =A0 We reduced that to only bei= ng able to attack one client_id at a time. For confidential clients it should not be possible to brute force the token= endpoint. =A0 Trying to explain all the issues is hard so those are not bad defaults, =A0= 128 bits is a 20 character character password using the printable ascii cha= racter set for out of band code delivery. John B. On 2012-11-02, at 3:58 PM, Oleg Gryb wrote: Thanks, Brian. "Must" for 128 bits makes perfect sense. 160 bits looks good= as a recommended entropy as well. WG, Please update the doc. It's important to provide clear guidelines for OAuth= implementers, which are many nowadays.=20 --- On Fri, 11/2/12, Brian Campbell wrote: From: Brian Campbell Subject: Re: [OAUTH-WG] OAuth token entropy To: "Oleg Gryb" Cc: "Torsten Lodderstedt" , "oauth" Date: Friday, November 2, 2012, 2:19 PM I believe the original text (which was borrowed from elsewhere) had a must = followed by a should rather than two=0A shoulds like that. The text seems t= o have drifted a bit in various places but the threat model text should pro= bably be aligned with what's in core OAuth at http://tools.ietf.org/html/rf= c6749#section-10.10 =0A=0A On Fri, Nov 2, 2012 at 10:16 AM, Oleg Gryb wrote: =0A=0ACan somebody please provide clarification for this: =0A=0Ahttp://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section= -5.1.4.2.2=0A=0A5.1.4.2.2. High entropy of secrets...=0A The probability= of any two Authorization Code=0A values being identical should be less t= han or equal to 2^(-128) and=0A should be less than or equal to 2^(-160). Is there any reason why we have two inclusive conditions in this statement = or is it a typo and you meant something else? =A0 _______________________________________________ =0A=0A=0AOAuth mailing list =0AOAuth@ietf.org =0Ahttps://www.ietf.org/mailman/listinfo/oauth =0A =0A_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -----Inline Attachment Follows----- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ---1562933420-1141609334-1352050897=:2907 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
John,

It makes perfect sense to add cl= ient_id and verification as you've described, since unlike 1.0, client secr= ets and signatures are not required in 2.0. Still, if a public client is a = big high-volume website that talks to a big authorization server (e.g. Yaho= o to FB), having a good entropy (at least 128 bits) is a good idea.
Another good idea would be to make a provision in a spec that would say th= at most likely the entropy will increase in the future OAuth versions. It w= ould help implementers to make their systems (both clients and authz server= s) more flexible and avoid 2K like effects in the future.

Just think= about fast opinion change about the "safe" symmetric key entropy in SSL fo= r the last 15 years. That opinion was changing so fast that some privacy/co= mpliance officers could not catch up with that pace and continued writing i= n their official privacy policies something like that: "your private informa= tion is protected in transition by SSL with a strong 56-bit encryption" in = which cases I had to get back to them asking to remove number of bits from = the policy to make it more universal and durable :)      &nb= sp;  

--- On Fri, 11/2/12, John Bradley <ve7jtb@ve7jt= b.com> wrote:

From: John Bradley= <ve7jtb@ve7jtb.com>
Subject: Re: [OAUTH-WG] OAuth token entropyTo: oleg@gryb.info
Cc: "oauth" <oauth@ietf.org>
Date: Friday,= November 2, 2012, 5:40 PM

The change = we did to the last ish draft of OAuth to have the client send its client ID= to the token endpoint even if it is not using a password reduces the need = for additional entropy.

Originally for public clients using code, an attacker had the address space of all the inflight codes fo= r all clients.   We reduced that to only being able to attack one clie= nt_id at a time.

For confidential clients it shoul= d not be possible to brute force the token endpoint.  

<= /div>
Trying to explain all the issues is hard so those are not bad def= aults,  128 bits is a 20 character character password using the printa= ble ascii character set for out of band code delivery.

=
John B.
On 2012-11-02, at 3:58 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote= :

Thanks, Brian. "Must" for 128 = bits makes perfect sense. 160 bits looks good as a recommended entropy as well.

WG,
Please update the doc. It's important to provide clear guidelines for = OAuth implementers, which are many nowadays.

--- On Fri, 11/2/12= , Brian Campbell <bcampbell@pingidentity.com> wrote:

From: Brian Campbell <bcampbell@pingidentity.com>
Subject: Re:= [OAUTH-WG] OAuth token entropy
To: "Oleg Gryb" <oleg@gryb.info>
Cc: "Torsten Lodderstedt" <= torsten@lodderstedt.net>, "oaut= h" <oauth@ietf.org>
Date= : Friday, November 2, 2012, 2:19 PM

I belie= ve the original text (which was borrowed from elsewhere) had a must followe= d by a should rather than two=0A shoulds like that. The text seems to have = drifted a bit in various places but the threat model text should probably b= e aligned with what's in core OAuth at http://tools.ie= tf.org/html/rfc6749#section-10.10
=0A=0A


On Fri, Nov 2, 20= 12 at 10:16 AM, Oleg Gryb <oleg_gr= yb@yahoo.com> wrote:
=0A=0A
Can somebody please provide= clarification for this:
=
=0A=0A
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatm=
odel-05#section-5.1.4.2.2
=0A=0A
5.1.4.2.2<=
/a>.  High entropy of secrets
...=0A   The probability of any tw=
o Authorization Code=0A   values being identical should be less than or equ=
al to 2^(-128) and=0A   should be less than or equal to 2^(-160).

=
Is there any reason why we have two inclusive conditions in this statem= ent or is it a typo and you meant something else?
 

_______________________________________________
=0A=0A= =0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth
=0A

=0A
_= ______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf= .org/mailman/listinfo/oauth

-----Inline Attachment Follows-----

______= _________________________________________
OAuth mailing list
OAuth= @ietf.org
https://www.ietf.org/mailman/listinfo/oauth
---1562933420-1141609334-1352050897=:2907-- From aanganes@mitre.org Sun Nov 4 12:33:21 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A61121F8500 for ; Sun, 4 Nov 2012 12:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sy+pt8QSDS1Q for ; Sun, 4 Nov 2012 12:33:20 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F351921F84F3 for ; Sun, 4 Nov 2012 12:33:19 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4517A1F06D4; Sun, 4 Nov 2012 15:33:19 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 29F801F06CC; Sun, 4 Nov 2012 15:33:19 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.53]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Sun, 4 Nov 2012 15:33:19 -0500 From: "Anganes, Amanda L" To: Lewis Adam-CAL022 , "Manger, James H" Thread-Topic: [OAUTH-WG] access tokens & refresh tokens of different scopes Thread-Index: AQHNt6vRvMvKMVfMaEeBhwOb4WD1tJfT71MggAAruyCAAt30wIAAKL0QgAME7z0= Date: Sun, 4 Nov 2012 20:33:17 +0000 Message-ID: References: <59E470B10C4630419ED717AC79FCF9A92F166F7F@BY2PRD0411MB441.namprd04.prod.outlook.com> <5BFC7B8F-8E2E-40B5-A0BD-769DCFC3DA2A@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F166FF5@BY2PRD0411MB441.namprd04.prod.outlook.com> <433A47F7-EED9-4BB7-B781-95430B204D75@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F167058@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A92F1670F6@BY2PRD0411MB441.namprd04.prod.outlook.com> <255B9BB34FB7D647A506DC292726F6E114FFCE6960@WSMSG3153V.srv.dir.telstra.com>, <59E470B10C4630419ED717AC79FCF9A92F16775E@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A92F16775E@BY2PRD0411MB441.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: multipart/alternative; boundary="_000_B61A05DAABADEA4EA2F19424825286FA1E630AFBIMCMBX04MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:33:21 -0000 --_000_B61A05DAABADEA4EA2F19424825286FA1E630AFBIMCMBX04MITREOR_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Adam, Justin may chime in at some point about this, but he has a draft out that I= think addresses what you (and James) are looking for: http://tools.ietf.or= g/html/draft-richer-oauth-chain-00. He's posted it to the working group onc= e or twice to get feedback and called a meeting about it at IIW last week, = but so far he hasn't found many people who actually agree this is a valuabl= e addition (at least, that has been my read of the room the times its been = discussed). Take a look at the draft and see if it looks like it's headed in the right = (or wrong) direction - feedback would be great. --Amanda ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of Lewis Ad= am-CAL022 [Adam.Lewis@motorolasolutions.com] Sent: Friday, November 02, 2012 6:23 PM To: Manger, James H Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes Hi James, Wish I were around at the time that was discussed, but doubt my presence wo= uld have tipped the scales :) You actually make another point that I would find very valuable and that is= to obtain multiple access tokens (of different scopes) in a single request= . My use cases will have a client accessing at least three different resou= rce servers on behalf of the user. Using vanilla OAuth I have to go throug= h the following OAuth round trips (not including primary authentication to = the AS): 1. Authorization request / authorization response (with scope=3Drs1+rs= 2+rs3) 2. Access token request / access token response (gives me AT with scop= e=3Drs1+rs2+rs3 and RT). I need to discard the AT because its scope is too= promiscuous to send to any given RS. 3. Access token request (using RT) with scope=3Drs1 / access token res= ponse (AT for rs1) 4. Access token request (using RT) with scope=3Drs2 / access token res= ponse (AT for rs2) 5. Access token request (using RT) with scope=3Drs3 / access token res= ponse (AT for rs3) Five round trips is going to kill me. And my guess is that we will add mor= e resource servers in the future to that this client will access making it = even worse. If there was a way to get all three down-scoped access tokens = + the fully scoped refresh token in step 2, then this would be highly effic= ient. I=92m normally a consumer of IETF efforts rather than a contributor, but I= =92d be interested in working on this if the WG agrees it=92s worthwhile. = It seems at least you and Torsten agree in principle =85 what level of crit= ical mass is required to get something moving? adam From: Manger, James H [mailto:James.H.Manger@team.telstra.com] Sent: Wednesday, October 31, 2012 8:01 PM To: Lewis Adam-CAL022 Cc: "WG "@il06exr01.mot.com Subject: RE: [OAUTH-WG] access tokens & refresh tokens of different scopes Adam, I=92ll chime in and say you have a reasonable requirement (getting tokens w= ith different scopes (for different resource servers) efficiently). Over th= e last few years there have been a number of proposals for OAuth to support= this (by allowing an authorization server to return multiple tokens, each = with their own scope). Unfortunately, despite some support, the proposals w= ere rejected for the core spec. There was strong resistance to any complexi= ty that wasn=92t absolutely necessary for the basic use case =97 and flexib= ility for likely (though maybe niche) scenarios such as yours was not suffi= cient motivation. As it turns out, one significant early use of OAuth2 does need an extra tok= en (the ID token in OpenID Connect). That is being supported with some addi= tions to OAuth2 that are highly specific to OpenID Connect so it does not h= elp your requirement. -- James Manger From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of L= ewis Adam-CAL022 Sent: Thursday, 1 November 2012 4:01 AM To: oauth@ietf.org Subject: [OAUTH-WG] access tokens & refresh tokens of different scopes I have a use case where I would like to request both an access token and a = refresh token, but I would like the access token to have a scope less than = that of the refresh token. It is standard OAuth behavior for using the ref= resh token to request additional access tokens (of equal or lesser scope) b= ut the first access token that comes back always has the =93master scope=94= of the refresh token. For various security concerns, I always want my access tokens to be of a st= ricter scope that the refresh token. For example, consider the scenario of= a structured (JWT) access token that does not require the RS to call back = to the AS introspection endpoint. Following typical OAuth guidance, it is = best practice to use short lived access tokens with long lived refresh toke= ns. But I=92d rather a compromised access token not compromise access to A= LL my resource servers. Using the existing standard I could simply destroy the first access token w= hen it is received and then request another of lesser scope using the refre= sh token, but now I=92ve just wasted a round trip over the air, consuming b= andwidth and adding latency to the end user experience. Is there anybody in the working group that feels this would be valuable? adam --_000_B61A05DAABADEA4EA2F19424825286FA1E630AFBIMCMBX04MITREOR_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Adam,

Justin may chime in at some point about this, but he has a draft out t= hat I think addresses what you (and James) are looking for: http://tools.ietf.= org/html/draft-richer-oauth-chain-00. He's posted it to the working group once or twice to get feedback and call= ed a meeting about it at IIW last week, but so far he hasn't found many peo= ple who actually agree this is a valuable addition (at least, that has been= my read of the room the times its been discussed). 

Take a look at the draft and see if it looks like it's headed in the r= ight (or wrong) direction - feedback would be great.

--Amanda
From: oauth-bounces@ietf.org [oauth-boun= ces@ietf.org] on behalf of Lewis Adam-CAL022 [Adam.Lewis@motorolasolutions.= com]
Sent: Friday, November 02, 2012 6:23 PM
To: Manger, James H
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] access tokens & refresh tokens of differ= ent scopes

Hi James,

 

Wish I were around at the time that was dis= cussed, but doubt my presence would have tipped the scales :)

 

You actually make another point that I woul= d find very valuable and that is to obtain multiple access tokens (of diffe= rent scopes) in a single request.  My use cases will have a client accessing at least three different resource servers on behalf of = the user.  Using vanilla OAuth I have to go through the following OAut= h round trips (not including primary authentication to the AS):

 

1. &n= bsp;    Authorization request / authorization respons= e (with scope=3Drs1+rs2+rs3)

2. &n= bsp;    Access token request / access token response = (gives me AT with scope=3Drs1+rs2+rs3 and RT).  I need to disc= ard the AT because its scope is too promiscuous to send to any given RS.

3. &n= bsp;    Access token request (using RT) with scope=3D= rs1 / access token response (AT for rs1)

4. &n= bsp;    Access token request (using RT) with scope=3D= rs2 / access token response (AT for rs2)

5. &n= bsp;    Access token request (using RT) with scope=3D= rs3 / access token response (AT for rs3)

 

Five round trips is going to kill me. = And my guess is that we will add more resource servers in the future to th= at this client will access making it even worse.  If there was a way to get all three down-scoped access tokens + the fully scoped re= fresh token in step 2, then this would be highly efficient. 

 

I=92m normally a consumer of IETF efforts r= ather than a contributor, but I=92d be interested in working on this if the= WG agrees it=92s worthwhile.  It seems at least you and Torsten agree in principle =85 what level of critical mass is required to get some= thing moving?

 

adam

 

 

From: Manger= , James H [mailto:James.H.Manger@team.telstra.com]
Sent: Wednesday, October 31, 2012 8:01 PM
To: Lewis Adam-CAL022
Cc: "WG <oauth@ietf.org>"@il06exr01.mot.com
Subject: RE: [OAUTH-WG] access tokens & refresh tokens of differ= ent scopes

 

Adam,

 

I=92ll c= hime in and say you have a reasonable requirement (getting tokens with diff= erent scopes (for different resource servers) efficiently). Over the last few years there have been a number of proposals for OAuth to= support this (by allowing an authorization server to return multiple token= s, each with their own scope). Unfortunately, despite some support, the pro= posals were rejected for the core spec. There was strong resistance to any complexity that wasn=92t absolute= ly necessary for the basic use case =97 and flexibility for likely (though = maybe niche) scenarios such as yours was not sufficient motivation.<= /p>

 

As it tu= rns out, one significant early use of OAuth2 does need an extra token (the = ID token in OpenID Connect). That is being supported with some additions to OAuth2 that are highly specific to OpenID Connect so it = does not help your requirement.

 

--

James Ma= nger

 

From: oauth-= bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Lewis Adam-CAL022
Sent: Thursday, 1 November 2012 4:01 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] access tokens & refresh tokens of different = scopes

 

I have a use case where I would like to request both= an access token and a refresh token, but I would like the access token to = have a scope less than that of the refresh token.  It is standard OAut= h behavior for using the refresh token to request additional access tokens (of equal or lesser scope) but the fir= st access token that comes back always has the =93master scope=94 of the re= fresh token. 

 

For various security concerns, I always want my acce= ss tokens to be of a stricter scope that the refresh token.  For examp= le, consider the scenario of a structured (JWT) access token that does not = require the RS to call back to the AS introspection endpoint.  Following typical OAuth guidance, it is best practice to u= se short lived access tokens with long lived refresh tokens.  But I=92= d rather a compromised access token not compromise access to ALL my resourc= e servers.

 

Using the existing standard I could simply destroy t= he first access token when it is received and then request another of lesse= r scope using the refresh token, but now I=92ve just wasted a round trip ov= er the air, consuming bandwidth and adding latency to the end user experience.

 

Is there anybody in the working group that feels thi= s would be valuable?

 

 

adam

--_000_B61A05DAABADEA4EA2F19424825286FA1E630AFBIMCMBX04MITREOR_-- From jricher@mitre.org Sun Nov 4 19:56:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D4021F8986 for ; Sun, 4 Nov 2012 19:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRZUana-i73W for ; Sun, 4 Nov 2012 19:56:43 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A65C621F88C1 for ; Sun, 4 Nov 2012 19:56:34 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 78D084390018; Sun, 4 Nov 2012 22:56:33 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 558001F0469; Sun, 4 Nov 2012 22:56:33 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.132]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Sun, 4 Nov 2012 22:56:33 -0500 From: "Richer, Justin P." To: Pedro Felix Thread-Topic: [OAUTH-WG] Dynamic registration of client application instances Thread-Index: AQHNrg2OcjSuzItl/kWRCdt1oXVQqZfbCsqA Date: Mon, 5 Nov 2012 03:56:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.37.149] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06846692IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: Lukasz Moren , "" , Maciej Machulak Subject: Re: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 03:56:44 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E06846692IMCMBX01MITREOR_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are a couple of potential approaches to this. You can either use dyna= mic registration to get a new client_id for each instance, or you can tie i= nstance-specific information to a single client_id. In the former case, you can protect the registration endpoint with develope= r key of some kind. This key represents the class of clients and provides a= n audit trail for registration. In connect (and with the new dyn-reg draft = I'm working on uploading this week) we're using an OAuth2 Bearer token for = this use. By tying the instance-specific client_ids to the single root deve= loper key/token, you can limit how many instances you want to support of an= y client/user combination. In the latter case, you can use the instance extension draft (http://tools.= ietf.org/html/draft-richer-oauth-instance-00 -- needs to be updated but the= basics are there) to send information to the Authorization Endpoint. Here,= you use the same client_id for each client instance, which makes it trivia= l to track and limit the client/user combinations. But the extra instance i= nformation that the client provides here can help you differentiate the ins= tances. -- Justin On Oct 19, 2012, at 11:22 AM, Pedro Felix wrote: I have a native app scenario where - There are multiple app instances - The same user user can have multiple app instances (phone, tablet) - I would want to use confidential clients - the native app instance dynami= cally receives the client_secret - There should be a way to limit the number of app instances that are creat= ed. For instance, one could associate an app instance to the user's email. = Namely, I would like to explore the idea that an app instance is something = that is simultaneous associated with the client app but also to the user (r= esource owner). Thanks Pedro On Fri, Oct 19, 2012 at 3:53 PM, Maciej Machulak > wrote: Hi Pedro, With reference to your question posted on the OAUTH WG regarding dynamic re= gistration of OAuth clients, could you please provide us with the descripti= on of your use case. We've implemented dynamic registration on one of our s= ystems based on the specification that we've co-authored (http://tools.ietf= .org/html/draft-ietf-oauth-dyn-reg-00). It would be great to learn more abo= ut what you're trying to achieve and if we can help. Thanks, Maciej _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B33BFB58CCC8BE4998958016839DE27E06846692IMCMBX01MITREOR_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <7B101D501B485B4EB25A75E97ADE9BBB@imc.mitre.org> Content-Transfer-Encoding: quoted-printable There are a couple of potential approaches to this. You can either use dyna= mic registration to get a new client_id for each instance, or you can tie i= nstance-specific information to a single client_id. 

In the former case, you can protect the registration endpoint with dev= eloper key of some kind. This key represents the class of clients and provi= des an audit trail for registration. In connect (and with the new dyn-reg d= raft I'm working on uploading this week) we're using an OAuth2 Bearer token for this use. By tying the instan= ce-specific client_ids to the single root developer key/token, you can limi= t how many instances you want to support of any client/user combination.

In the latter case, you can use the instance extension draft (http://tools= .ietf.org/html/draft-richer-oauth-instance-00 -- needs to be updated bu= t the basics are there) to send information to the Authorization Endpoint. Here, you use the same client_id for each c= lient instance, which makes it trivial to track and limit the client/user c= ombinations. But the extra instance information that the client provides he= re can help you differentiate the instances.

 -- Justin

On Oct 19, 2012, at 11:22 AM, Pedro Felix wrote:

I have a native app scenario where
- There are multiple app instances
- The same user user can have multiple app instances (phone, tablet)
- I would want to use confidential clients - the native app instance d= ynamically receives the client_secret
- There should be a way to limit the number of app instances that are = created. For instance, one could associate an app instance to the user's em= ail. Namely, I would like to explore the idea that an app instance is somet= hing that is simultaneous associated with the client app but also to the user (resource owner).

Thanks
Pedro

On Fri, Oct 19, 2012 at 3:53 PM, Maciej Machulak= <maciej.machulak@cloudidentity.co.uk> wrote:
Hi Pedro,

With reference to your question posted on the OAUTH WG regarding dynam= ic registration of OAuth clients, could you please provide us with the desc= ription of your use case. We've implemented dynamic registration on one of = our systems based on the specification that we've co-authored (http://tools.ietf.org/html/draft-ietf-oa= uth-dyn-reg-00). It would be great to learn more about what you're tryi= ng to achieve and if we can help.

Thanks,
Maciej

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_B33BFB58CCC8BE4998958016839DE27E06846692IMCMBX01MITREOR_-- From internet-drafts@ietf.org Mon Nov 5 14:12:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2B111E8099; Mon, 5 Nov 2012 14:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJRvXKU58OHS; Mon, 5 Nov 2012 14:12:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA56921F8A8A; Mon, 5 Nov 2012 14:12:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121105221233.23937.33477.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 14:12:33 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 22:12:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : OAuth Dynamic Client Registration Protocol Author(s) : Justin Richer Thomas Hardjono Maciej Machulak Eve Maler Christian Scholz Nat Sakimura John Bradley Michael B. Jones Filename : draft-ietf-oauth-dyn-reg-01.txt Pages : 20 Date : 2012-11-05 Abstract: This specification proposes an OAuth Dynamic Client Registration protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jricher@mitre.org Mon Nov 5 14:20:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8257121F86D6 for ; Mon, 5 Nov 2012 14:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbJWLwoxb+BN for ; Mon, 5 Nov 2012 14:20:41 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8E47221F84E6 for ; Mon, 5 Nov 2012 14:20:41 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EC6311F08DB; Mon, 5 Nov 2012 17:20:38 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D08721F08AC; Mon, 5 Nov 2012 17:20:38 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.132]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Mon, 5 Nov 2012 17:20:38 -0500 From: "Richer, Justin P." To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt Thread-Index: AQHNu6K/gTD8Jz0XzkGvHVaHZq5C5pfbzoG4 Date: Mon, 5 Nov 2012 22:20:37 +0000 Message-ID: References: <20121105221233.23937.33477.idtracker@ietfa.amsl.com> In-Reply-To: <20121105221233.23937.33477.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "openid-specs-ab@lists.openid.net" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 22:20:42 -0000 This draft combines the best-usable parts UMA and OpenID Connect dynamic re= gistration drafts into one document that's designed to facilitate dynamic c= lient registration. I've significantly reorganized the document and I've tr= ied to exorcise any obvious dependencies on OpenID Connect or UMA. This pro= tocol follows the OpenID Connect registration model most closely, in that i= t's form-parameters in and JSON out (as opposed to JSON round trip). This m= atches the rest of the OAuth protocol. It's a push model only for metadata = as well, but it allows clients to push updates.=0A= =0A= General formatting is still rough, but I think that the text is mostly read= able and complete. There are several Editor's Notes in the document that br= ing up what I consider to be open questions or issues with the functionalit= y. One that I forgot to leave a note for is client unregistration. Does it = make sense to provide mechanisms for a full lifecycle for well-behaved clie= nts?=0A= =0A= We'll be discussing this draft in person at the IETF meeting for the OAuth = working group on Thursday for anybody who wants to throw tomatoes at me*.= =0A= =0A= -- Justin=0A= =0A= =0A= *Please do not actually throw tomatoes at me.=0A= =0A= ________________________________________=0A= From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of internet= -drafts@ietf.org [internet-drafts@ietf.org]=0A= Sent: Monday, November 05, 2012 5:12 PM=0A= To: i-d-announce@ietf.org=0A= Cc: oauth@ietf.org=0A= Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt=0A= =0A= A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=0A= This draft is a work item of the Web Authorization Protocol Working Group = of the IETF.=0A= =0A= Title : OAuth Dynamic Client Registration Protocol=0A= Author(s) : Justin Richer=0A= Thomas Hardjono=0A= Maciej Machulak=0A= Eve Maler=0A= Christian Scholz=0A= Nat Sakimura=0A= John Bradley=0A= Michael B. Jones=0A= Filename : draft-ietf-oauth-dyn-reg-01.txt=0A= Pages : 20=0A= Date : 2012-11-05=0A= =0A= Abstract:=0A= This specification proposes an OAuth Dynamic Client Registration=0A= protocol.=0A= =0A= =0A= The IETF datatracker status page for this draft is:=0A= https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg=0A= =0A= There's also a htmlized version available at:=0A= http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-01=0A= =0A= A diff from the previous version is available at:=0A= http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-01=0A= =0A= =0A= Internet-Drafts are also available by anonymous FTP at:=0A= ftp://ftp.ietf.org/internet-drafts/=0A= =0A= _______________________________________________=0A= OAuth mailing list=0A= OAuth@ietf.org=0A= https://www.ietf.org/mailman/listinfo/oauth=0A= From twbray@google.com Mon Nov 5 14:38:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FAA11E80A2 for ; Mon, 5 Nov 2012 14:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eW-TOtLFP6Do for ; Mon, 5 Nov 2012 14:38:52 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6B34911E80A3 for ; Mon, 5 Nov 2012 14:38:52 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hr7so2982706wib.13 for ; Mon, 05 Nov 2012 14:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=9mwCj57ng+4Kc4UnVFH9v+Qt7WFrxH44vEjXtGH511Y=; b=DcjhYgCqaaQkq37edFoQZOqXDip2M2hTl7qB7lgLC//oobwAEUrPBaWXQeULRkekVk 5OZSBUTJThF4VecfXeJXkN/swAGKFrMqtFvWRRyQNH/AnBaSOYz6Kt+bqnRE0qGu2eRC A8q75f8KAb3+vpnvgQ1E8y9Y2wNr8delF1Yc5p0NlXpcgMpDPALSRkzFLzDTjbaVs9sw UYxYs4i6qFKiYoPe+humViBg6sR84RjPLKLepqr1mkp6zmmg3rscIREVuOsW7CLKHH3J yGo1lw6wH6TLXBWLaGJixWIFZRAA6U8HdKqmD9jTD0sX8s6zpLngnj9I25WDt666pC+n iotA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=9mwCj57ng+4Kc4UnVFH9v+Qt7WFrxH44vEjXtGH511Y=; b=JqJFG3VyWGEV84pD/1UYxeSaMuAfKf2X7znUr/te9tMH4EJDY6zkDfor4cJABcViqB 4ToGfY9DZwVw2w6PShFdmcLoOpJ/SFdKLcT3Jsu5irzMWX4gvb975j3yXop60d/DdWiC 1G/Bsp3a7vDnU91x1s0iexAXQeTOwkopZKvK0tUall5Cbe4u+j6vF2Kae7SjqDfRswTx ThbgHPHWktzmEiOKNfjSHRXX01TDYIf6dD3bfhNXFpmFd1nMSSz5hvpt5wuWTYkH5ubj 78hJ1Lua3f8/gq2ehPkyvlM3EpezquJBEy4j9Ivqgaf2cLv0sjMPl4neOOTagFjLFrys 2Vqg== Received: by 10.180.104.97 with SMTP id gd1mr15431962wib.4.1352155131420; Mon, 05 Nov 2012 14:38:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.90.207 with HTTP; Mon, 5 Nov 2012 14:38:21 -0800 (PST) In-Reply-To: References: <20121105221233.23937.33477.idtracker@ietfa.amsl.com> From: Tim Bray Date: Mon, 5 Nov 2012 14:38:21 -0800 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=f46d044280e64a1f5104cdc726b5 X-System-Of-Record: true X-Gm-Message-State: ALoCoQku3Y1N26JFSLY/N6wf6AZ2I498g2FvtxRc4yDJFPZ7qJLhH2ZBuwoGwzPVvvPlRefF4uhHVMq9aoBY1gh1NIi0Laewk3IjPUd/BYR5CLfm/3gB8bmcOanyRnUOdioIO2LM1v9k5PJSCs1ceI2nWM7biVufTd5b2QhZwFsUnbGOnXIUfUvjgtM/Xc467mLEXNv9q4Gb Cc: "openid-specs-ab@lists.openid.net" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 22:38:53 -0000 --f46d044280e64a1f5104cdc726b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Quick question: Why is it =E2=80=9Cassociation request=E2=80=9D, not =E2=80= =9Cregistration request=E2=80=9D? Nearly everywhere the term =E2=80=9Cassociation=E2=80=9D= appears, it seems like you could insert =E2=80=9Cregistration=E2=80=9D and achieve better clarity.= -T On Mon, Nov 5, 2012 at 2:20 PM, Richer, Justin P. wrote= : > This draft combines the best-usable parts UMA and OpenID Connect dynamic > registration drafts into one document that's designed to facilitate dynam= ic > client registration. I've significantly reorganized the document and I've > tried to exorcise any obvious dependencies on OpenID Connect or UMA. This > protocol follows the OpenID Connect registration model most closely, in > that it's form-parameters in and JSON out (as opposed to JSON round trip)= . > This matches the rest of the OAuth protocol. It's a push model only for > metadata as well, but it allows clients to push updates. > > General formatting is still rough, but I think that the text is mostly > readable and complete. There are several Editor's Notes in the document > that bring up what I consider to be open questions or issues with the > functionality. One that I forgot to leave a note for is client > unregistration. Does it make sense to provide mechanisms for a full > lifecycle for well-behaved clients? > > We'll be discussing this draft in person at the IETF meeting for the OAut= h > working group on Thursday for anybody who wants to throw tomatoes at me*. > > -- Justin > > > *Please do not actually throw tomatoes at me. > > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of > internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Monday, November 05, 2012 5:12 PM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol Working Grou= p > of the IETF. > > Title : OAuth Dynamic Client Registration Protocol > Author(s) : Justin Richer > Thomas Hardjono > Maciej Machulak > Eve Maler > Christian Scholz > Nat Sakimura > John Bradley > Michael B. Jones > Filename : draft-ietf-oauth-dyn-reg-01.txt > Pages : 20 > Date : 2012-11-05 > > Abstract: > This specification proposes an OAuth Dynamic Client Registration > protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 > --f46d044280e64a1f5104cdc726b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Quick = question: Why is it =E2=80=9Cassociation request=E2=80=9D, not =E2=80=9Creg= istration request=E2=80=9D? =C2=A0Nearly everywhere the term =E2=80=9Cassoc= iation=E2=80=9D appears, it seems like you could insert =E2=80=9Cregistrati= on=E2=80=9D and achieve better clarity. -T

On Mon, Nov 5, 2012 at 2:20 PM, Richer, Just= in P. <jricher@mitre.org> wrote:
This draft combines the best-usable parts UMA and OpenID Connect dynamic re= gistration drafts into one document that's designed to facilitate dynam= ic client registration. I've significantly reorganized the document and= I've tried to exorcise any obvious dependencies on OpenID Connect or U= MA. This protocol follows the OpenID Connect registration model most closel= y, in that it's form-parameters in and JSON out (as opposed to JSON rou= nd trip). This matches the rest of the OAuth protocol. It's a push mode= l only for metadata as well, but it allows clients to push updates.

General formatting is still rough, but I think that the text is mostly read= able and complete. There are several Editor's Notes in the document tha= t bring up what I consider to be open questions or issues with the function= ality. One that I forgot to leave a note for is client unregistration. Does= it make sense to provide mechanisms for a full lifecycle for well-behaved = clients?

We'll be discussing this draft in person at the IETF meeting for the OA= uth working group on Thursday for anybody who wants to throw tomatoes at me= *.

=C2=A0-- Justin


*Please do not actually throw tomatoes at me.

________________________________________
From: oauth-bounces@ietf.org = [oauth-bounces@ietf.org] on b= ehalf of internet-drafts@ietf.o= rg [internet-drafts@ietf.or= g]
Sent: Monday, November 05, 2012 5:12 PM
To: i-d-announce@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : OAut= h Dynamic Client Registration Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Justin Richer<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Thomas Hardjono
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Maciej Machulak
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Eve Maler
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Christian Scholz
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nat Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Michael B. Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-oauth-dyn-reg-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2012-11-05

Abstract:
=C2=A0 =C2=A0This specification proposes an OAuth Dynamic Client Registrati= on
=C2=A0 =C2=A0protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg<= br>
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-r= eg-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--f46d044280e64a1f5104cdc726b5-- From jricher@mitre.org Mon Nov 5 14:50:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB7021F856E for ; Mon, 5 Nov 2012 14:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fkz3191drp66 for ; Mon, 5 Nov 2012 14:50:45 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 392B021F8512 for ; Mon, 5 Nov 2012 14:50:45 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CEFF1451001A; Mon, 5 Nov 2012 17:50:35 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B93581F07EE; Mon, 5 Nov 2012 17:50:35 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.132]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Mon, 5 Nov 2012 17:50:35 -0500 From: "Richer, Justin P." To: Tim Bray Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt Thread-Index: AQHNu6K/gTD8Jz0XzkGvHVaHZq5C5pfbzoG4gABaj4CAAANpAA== Date: Mon, 5 Nov 2012 22:50:34 +0000 Message-ID: References: <20121105221233.23937.33477.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.38.253] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06847606IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "openid-specs-ab@lists.openid.net" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 22:50:46 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E06847606IMCMBX01MITREOR_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I thought of this during the merge process as well -- "associate" is a dire= ct import from OIDC. The reasoning behind this verb is that you're "associa= ting" a set of client metadata to a particular client identifier. I'd be happy to change this term to "client_register" if there's consensus = for a move to that terminology. Also, forgot to mention this before: The latest version of it will always b= e on my github: https://github.com/jricher/oauth-spec This has the added benefit of allowing you all to fork the repo, make edits= , file issues, and make pull requests against the document in between uploa= ds to the IETF datatracker. -- Justin On Nov 5, 2012, at 5:38 PM, Tim Bray wrote: Quick question: Why is it =93association request=94, not =93registration re= quest=94? Nearly everywhere the term =93association=94 appears, it seems l= ike you could insert =93registration=94 and achieve better clarity. -T On Mon, Nov 5, 2012 at 2:20 PM, Richer, Justin P. > wrote: This draft combines the best-usable parts UMA and OpenID Connect dynamic re= gistration drafts into one document that's designed to facilitate dynamic c= lient registration. I've significantly reorganized the document and I've tr= ied to exorcise any obvious dependencies on OpenID Connect or UMA. This pro= tocol follows the OpenID Connect registration model most closely, in that i= t's form-parameters in and JSON out (as opposed to JSON round trip). This m= atches the rest of the OAuth protocol. It's a push model only for metadata = as well, but it allows clients to push updates. General formatting is still rough, but I think that the text is mostly read= able and complete. There are several Editor's Notes in the document that br= ing up what I consider to be open questions or issues with the functionalit= y. One that I forgot to leave a note for is client unregistration. Does it = make sense to provide mechanisms for a full lifecycle for well-behaved clie= nts? We'll be discussing this draft in person at the IETF meeting for the OAuth = working group on Thursday for anybody who wants to throw tomatoes at me*. -- Justin *Please do not actually throw tomatoes at me. ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@= ietf.org] on behalf of internet-drafts@ietf.= org [internet-drafts@ietf.org] Sent: Monday, November 05, 2012 5:12 PM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : OAuth Dynamic Client Registration Protocol Author(s) : Justin Richer Thomas Hardjono Maciej Machulak Eve Maler Christian Scholz Nat Sakimura John Bradley Michael B. Jones Filename : draft-ietf-oauth-dyn-reg-01.txt Pages : 20 Date : 2012-11-05 Abstract: This specification proposes an OAuth Dynamic Client Registration protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 --_000_B33BFB58CCC8BE4998958016839DE27E06847606IMCMBX01MITREOR_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable I thought of this during the merge process as well -- "associate"= is a direct import from OIDC. The reasoning behind this verb is that you'r= e "associating" a set of client metadata to a particular client i= dentifier.

I'd be happy to change this term to "client_register" if the= re's consensus for a  move to that terminology.

Also, forgot to mention this before: The latest version of it will alw= ays be on my github:


This has the added benefit of allowing you all to fork the repo, make = edits, file issues, and make pull requests against the document in between = uploads to the IETF datatracker.

 -- Justin


On Nov 5, 2012, at 5:38 PM, Tim Bray wrote:

Quick = question: Why is it =93association request=94, not =93registration request= =94?  Nearly everywhere the term =93association=94 appears, it seems l= ike you could insert =93registration=94 and achieve better clarity. -T

On Mon, Nov 5, 2012 at 2:20 PM, Richer, Justin P= . <jricher@mitre.or= g> wrote:
This draft combines the best-usable parts UMA and OpenID Connect dynamic re= gistration drafts into one document that's designed to facilitate dynamic c= lient registration. I've significantly reorganized the document and I've tr= ied to exorcise any obvious dependencies on OpenID Connect or UMA. This protocol follows the OpenID Connect registr= ation model most closely, in that it's form-parameters in and JSON out (as = opposed to JSON round trip). This matches the rest of the OAuth protocol. I= t's a push model only for metadata as well, but it allows clients to push updates.

General formatting is still rough, but I think that the text is mostly read= able and complete. There are several Editor's Notes in the document that br= ing up what I consider to be open questions or issues with the functionalit= y. One that I forgot to leave a note for is client unregistration. Does it make sense to provide mechanism= s for a full lifecycle for well-behaved clients?

We'll be discussing this draft in person at the IETF meeting for the OAuth = working group on Thursday for anybody who wants to throw tomatoes at me*.
 -- Justin


*Please do not actually throw tomatoes at me.

________________________________________
From: oauth-bounces@ietf.org = [oauth-bounces@ietf.org] on b= ehalf of internet-drafts@ietf.org [<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org] Sent: Monday, November 05, 2012 5:12 PM
To: i-d-announce@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF.

        Title           : OAut= h Dynamic Client Registration Protocol
        Author(s)       : Justin Richer<= br>                      = ;     Thomas Hardjono
                     = ;     Maciej Machulak
                     = ;     Eve Maler
                     = ;     Christian Scholz
                     = ;     Nat Sakimura
                     = ;     John Bradley
                     = ;     Michael B. Jones
        Filename        : draft-iet= f-oauth-dyn-reg-01.txt
        Pages           : 20         Date            := 2012-11-05

Abstract:
   This specification proposes an OAuth Dynamic Client Registrati= on
   protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg<= br>
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-r= eg-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--_000_B33BFB58CCC8BE4998958016839DE27E06847606IMCMBX01MITREOR_-- From hannes.tschofenig@gmx.net Tue Nov 6 06:47:55 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EEF21F8952 for ; Tue, 6 Nov 2012 06:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJbpM05vRXHz for ; Tue, 6 Nov 2012 06:47:54 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 593AE21F8951 for ; Tue, 6 Nov 2012 06:47:54 -0800 (PST) Received: (qmail invoked by alias); 06 Nov 2012 14:47:52 -0000 Received: from dhcp-17ac.meeting.ietf.org (EHLO dhcp-17ac.meeting.ietf.org) [130.129.23.172] by mail.gmx.net (mp069) with SMTP; 06 Nov 2012 15:47:52 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/H31tn15fHO7iRZ+KnSzrFZFjo8CRNAKHi0cWh3t Mi1z9z+5MABQkN From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 6 Nov 2012 09:47:50 -0500 Message-Id: <4953004B-1632-4B1A-9916-6AD154A77A40@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Slides, please X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 14:47:55 -0000 Hi all, this is a remember to send me your slides. ---- 2. Token Revocation (Thorsten) http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ 3. Assertions (Mike) http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ 4. OAuth Use Cases (Zachary) http://datatracker.ietf.org/doc/draft-ietf-oauth-use-cases/ 5. JWT (Mike) http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ 6. Security (Phil) http://datatracker.ietf.org/doc/draft-tschofenig-oauth-security/ 7. Dynamic Client Registration (Justin) http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-01 ---- Ciao Hannes From hannes.tschofenig@gmx.net Tue Nov 6 06:59:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B2521F88E4 for ; Tue, 6 Nov 2012 06:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT1TiOTdB8TE for ; Tue, 6 Nov 2012 06:59:42 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9926521F884B for ; Tue, 6 Nov 2012 06:59:41 -0800 (PST) Received: (qmail invoked by alias); 06 Nov 2012 14:59:12 -0000 Received: from dhcp-17ac.meeting.ietf.org (EHLO dhcp-17ac.meeting.ietf.org) [130.129.23.172] by mail.gmx.net (mp017) with SMTP; 06 Nov 2012 15:59:12 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/EiVtTn9jEiSRdwvKEPEDLXfVHe8/7pigMiiP58S k5LvV5mPl8wGS9 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Nov 2012 09:59:09 -0500 Message-Id: <7C0172BC-1D34-4C96-9220-0496BF14B262@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Please review draft-ietf-oauth-json-web-token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 14:59:42 -0000 Hi all,=20 you may have noticed that the JOSE working group had made good progress = with their work and they are getting closer to a WGLC. This is a good = point in time for us to review the JWT spec (see = http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/). = Please read through it in preparation for the meeting.=20 It would be good to hear who has implemented it and whether there is = feedback on the document. Given the OpenID Connect interoperability = tests there seem to be lots of implementations.=20 We would like to start a WGLC as soon as the WGLC for the JOSE documents = starts.=20 Ciao Hannes From aanganes@mitre.org Tue Nov 6 12:41:01 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B4521F89EE for ; Tue, 6 Nov 2012 12:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNUGzExbhfwp for ; Tue, 6 Nov 2012 12:41:00 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF7A21F89CA for ; Tue, 6 Nov 2012 12:41:00 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C6F6653100C0 for ; Tue, 6 Nov 2012 15:40:59 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7822653100EE for ; Tue, 6 Nov 2012 15:40:59 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.53]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Tue, 6 Nov 2012 15:40:59 -0500 From: "Anganes, Amanda L" To: "oauth@ietf.org" Thread-Topic: Review of Assertions drafts Thread-Index: Ac28Xk9nIr2tXJNOQqS8h5pHWczTlQ== Date: Tue, 6 Nov 2012 20:40:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: multipart/alternative; boundary="_000_B61A05DAABADEA4EA2F19424825286FA1E63101FIMCMBX04MITREOR_" MIME-Version: 1.0 Subject: [OAUTH-WG] Review of Assertions drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 20:41:01 -0000 --_000_B61A05DAABADEA4EA2F19424825286FA1E63101FIMCMBX04MITREOR_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hannes requested that some folks read through the assertion drafts and give= feedback in light of the upcoming shepherd review. [1] http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ [2] http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ [3] http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ I can't speak to the security considerations or advisability of these draft= s, but as far as the documents go I think they are well-organized, consiste= nt (internally and across all 3 documents) and straightforward. A few comments: [1] Section 4.2.1 says in passing that it is an error condition "if more th= an one client authentication mechanism is used". If this is a true requirem= ent / error state I think it should be called out more strongly. Perhaps 4.= 2 should say at the top that "Other client authentication mechanisms MUST N= OT be used in conjunction with an assertion". If so, [2] 3.2 and [3] 3.2 should also indicate that additional client cred= entials MUST NOT be used in addition to the assertion for Client Authentica= tion. [3] Section 2.2 first sentence: "client authentication grant" should just b= e "client authentication". --Amanda Anganes --_000_B61A05DAABADEA4EA2F19424825286FA1E63101FIMCMBX04MITREOR_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hannes requested that some folks= read through the assertion drafts and give feedback in light of the upcomi= ng shepherd review.


I can't speak to the security cons= iderations or advisability of these drafts, but as far as the documents go = I think they are well-organized, consistent (internally and across all 3 do= cuments) and straightforward. 

A few comments:

[1] Section 4.2.1 says in pas= sing that it is an error condition "if more than one client authentica= tion mechanism is used". If this is a true requirement / error state I= think it should be called out more strongly. Perhaps 4.2 should say at the top that "Other client authentication mechanism= s MUST NOT be used in conjunction with an assertion". 

If so, [2] 3.2 and [3] 3.2 should&= nbsp;also indicate that additional client credentials MUST NOT be used in a= ddition to the assertion for Client Authentication.

[3] Section 2.2 first sentence: &q= uot;client authentication grant" should just be "client authentic= ation".

--Amanda Anganes
--_000_B61A05DAABADEA4EA2F19424825286FA1E63101FIMCMBX04MITREOR_-- From aanganes@mitre.org Tue Nov 6 13:46:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A5A21F8A5E for ; Tue, 6 Nov 2012 13:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdUGwZhKChEO for ; Tue, 6 Nov 2012 13:46:18 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 703E521F8A44 for ; Tue, 6 Nov 2012 13:46:18 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D357D1F0425; Tue, 6 Nov 2012 16:46:17 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C1FDF1F032C; Tue, 6 Nov 2012 16:46:17 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.53]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Tue, 6 Nov 2012 16:46:17 -0500 From: "Anganes, Amanda L" To: Mike Jones , "oauth@ietf.org" Thread-Topic: Review of Assertions drafts Thread-Index: Ac28Xk9nIr2tXJNOQqS8h5pHWczTlQACK85AAABJo4A= Date: Tue, 6 Nov 2012 21:46:16 +0000 Message-ID: In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668A4CF4@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [172.31.38.41] Content-Type: multipart/alternative; boundary="_000_B61A05DAABADEA4EA2F19424825286FA1E631087IMCMBX04MITREOR_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Review of Assertions drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 21:46:19 -0000 --_000_B61A05DAABADEA4EA2F19424825286FA1E631087IMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good catch, thanks for double-checking. --Amanda From: Mike Jones > Date: Tuesday, November 6, 2012 4:40 PM To: "Anganes, Amanda L" >, "o= auth@ietf.org" > Subject: RE: Review of Assertions drafts Amanda wrote: [3] Section 2.2 first sentence: "client authentication grant"= should just be "client authentication". This change should also be applied to the first sentence of 2.2 in SAML dra= ft, where the same phrase occurs. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Anganes, Amanda L Sent: Tuesday, November 06, 2012 12:41 PM To: oauth@ietf.org Subject: [OAUTH-WG] Review of Assertions drafts Hannes requested that some folks read through the assertion drafts and give= feedback in light of the upcoming shepherd review. [1] http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ [2] http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ [3] http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ I can't speak to the security considerations or advisability of these draft= s, but as far as the documents go I think they are well-organized, consiste= nt (internally and across all 3 documents) and straightforward. A few comments: [1] Section 4.2.1 says in passing that it is an error condition "if more th= an one client authentication mechanism is used". If this is a true requirem= ent / error state I think it should be called out more strongly. Perhaps 4.= 2 should say at the top that "Other client authentication mechanisms MUST N= OT be used in conjunction with an assertion". If so, [2] 3.2 and [3] 3.2 should also indicate that additional client cred= entials MUST NOT be used in addition to the assertion for Client Authentica= tion. [3] Section 2.2 first sentence: "client authentication grant" should just b= e "client authentication". --Amanda Anganes --_000_B61A05DAABADEA4EA2F19424825286FA1E631087IMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-ID: <7BEBBCA5456D194B9FCE2DAADD9930BB@imc.mitre.org> Content-Transfer-Encoding: quoted-printable
Good catch, thanks for double-checking. 

--Amanda

From: Mike Jones <Michael.Jones@microsoft.com>
Date: Tuesday, November 6, 2012 4:4= 0 PM
To: "Anganes, Amanda L" &= lt;aanganes@mitre.org>, "= oauth@ietf.org" <oauth@ietf.org>
Subject: RE: Review of Assertions d= rafts

Amanda wrote: [3] Section 2.2 first sentence: "client authentication= grant" should just be "client authentication".=

 

This change should also be applied= to the first sentence of 2.2 in SAML draft, where the same phrase occurs.<= o:p>

 

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Anganes, Amanda L
Sent: Tuesday, November 06, 2012 12:41 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Review of Assertions drafts

 

Hannes requested that some folks read throu= gh the assertion drafts and give feedback in light of the upcoming shepherd= review.

 

 

I can't speak to the security consideration= s or advisability of these drafts, but as far as the documents go I think t= hey are well-organized, consistent (internally and across all 3 documents) and straightforward. =

 

A few comments:

 

[1] Section 4.2.1 says in passing that= it is an error condition "if more than one client authentication mech= anism is used". If this is a true requirement / error state I think it should be called out more strongly. Perhaps 4.2 s= hould say at the top that "Other client authentication mechanisms MUST= NOT be used in conjunction with an assertion". 

 

If so, [2] 3.2 and [3] 3.2 should also= indicate that additional client credentials MUST NOT be used in addition t= o the assertion for Client Authentication.

 

[3] Section 2.2 first sentence: "clien= t authentication grant" should just be "client authentication&quo= t;.

 

--Amanda Anganes

 --_000_B61A05DAABADEA4EA2F19424825286FA1E631087IMCMBX04MITREOR_-- From internet-drafts@ietf.org Wed Nov 7 01:41:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6757121F8B5C; Wed, 7 Nov 2012 01:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hd+IkxkySrxI; Wed, 7 Nov 2012 01:41:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16E221F8B74; Wed, 7 Nov 2012 01:41:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121107094145.22519.26623.idtracker@ietfa.amsl.com> Date: Wed, 07 Nov 2012 01:41:45 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 09:41:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : JSON Web Token (JWT) Author(s) : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-05.txt Pages : 24 Date : 2012-11-07 Abstract: JSON Web Token (JWT) is a means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is digitally signed or MACed using JSON Web Signature (JWS) and/or encrypted using JSON Web Encryption (JWE). The suggested pronunciation of JWT is the same as the English word "jot". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-json-web-token-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Nov 7 01:44:13 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B0A21F8BA9; Wed, 7 Nov 2012 01:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVKa8ZBgUbhS; Wed, 7 Nov 2012 01:44:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2004121F8BAB; Wed, 7 Nov 2012 01:44:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121107094413.5327.13795.idtracker@ietfa.amsl.com> Date: Wed, 07 Nov 2012 01:44:13 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bearer-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 09:44:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 Author(s) : Michael B. Jones Brian Campbell Chuck Mortimore Filename : draft-ietf-oauth-jwt-bearer-03.txt Pages : 11 Date : 2012-11-07 Abstract: This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-bearer-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From michael_b_jones@hotmail.com Wed Nov 7 02:13:14 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95BC21F8A0B for ; Wed, 7 Nov 2012 02:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL29zL-072D5 for ; Wed, 7 Nov 2012 02:13:14 -0800 (PST) Received: from bay0-omc1-s17.bay0.hotmail.com (bay0-omc1-s17.bay0.hotmail.com [65.54.190.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2543721F89FE for ; Wed, 7 Nov 2012 02:13:14 -0800 (PST) Received: from BAY171-W138 ([65.54.190.60]) by bay0-omc1-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 02:13:13 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_1feab312-44d6-48da-a66c-d0239bafe1e7_" X-Originating-IP: [130.129.71.146] From: Michael Jones To: Date: Wed, 7 Nov 2012 02:13:12 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2012 10:13:13.0139 (UTC) FILETIME=[7EDF3830:01CDBCD0] Subject: [OAUTH-WG] JOSE and JWT specs updated for IETF 85 working group meetings X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 10:13:15 -0000 --_1feab312-44d6-48da-a66c-d0239bafe1e7_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I=92ve made a small set of updates to the JSON Object Signing and Encryption (JOSE) and JSON Web Token (JWT) specs in preparation for the= JOSE and OAuth working group meetings at IETF 85. These updates incorporate resolutions to issues that have been discussed by the working groups since publication of the previous drafts. =20 Normative changes to the working group specs were to add length fields for PartyUInfo and PartyVInfo values for key derivation calculations and to change the JWK field identifiers for RSA keys from (mod= =2C xpo) to (n=2C e). Fields for representing the RSA private key values neede= d for Chinese Remainder Theorem (CRT) calculations were added to the JSON Pri= vate Key specification. =20 The updated specs are available at: =B7 =20 http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07 =B7 =20 http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07 =B7 =20 http://tools.ietf.org/html/draft-ietf-jose-json-web-key-07 =B7 =20 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-07 =B7 =20 http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05 =B7 =20 http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03 =B7 =20 http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-03 =B7 =20 http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-03 =B7 =20 http://tools.ietf.org/html/draft-jones-jose-json-private-key-01 =20 HTML formatted versions are available at: =B7 =20 http://self-issued.info/docs/draft-ietf-jose-json-web-signature-07.html =B7 =20 http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-07.html =B7 =20 http://self-issued.info/docs/draft-ietf-jose-json-web-key-07.html =B7 =20 http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-07.html =B7 =20 http://self-issued.info/docs/draft-ietf-oauth-json-web-token-05.html =B7 =20 http://self-issued.info/docs/draft-ietf-oauth-jwt-bearer-03.html =B7 =20 http://self-issued.info/docs/draft-jones-jose-jws-json-serialization-03.htm= l =B7 =20 http://self-issued.info/docs/draft-jones-jose-jwe-json-serialization-03.htm= l =B7 =20 http://self-issued.info/docs/draft-jones-jose-json-private-key-01.html =20 See the history entries in the specs for detailed change descriptions. =20 =20 =20 -- Mike = --_1feab312-44d6-48da-a66c-d0239bafe1e7_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I=92ve made a small set of updates to the JSON Obje= ct Signing and Encryption (JOSE) and JSON Web Token (JWT) specs in preparation for the= JOSE and OAuth= working group meetings at IETF 85. =3B These updates incorporate resolutions to issues that have been discussed by the working groups since publication of the previous drafts.

 =3B

Normative changes to the working group specs = were to add length fields for PartyUInfo and PartyVInfo values for key derivation calculations and to change the JWK field identifiers for RSA keys from (mod= =2C xpo) to (n=2C e). =3B Fields for representing the RSA private key value= s needed for Chinese Remainder Theorem (CRT) calculations were added to the JSON Pri= vate Key specification.

 =3B

The updated specs are available at:

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B = http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07=

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http:/= /tools.ietf.org/html/draft-ietf-jose-json-web-key-07<= /p>

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-07

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B htt= p://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05<= /o:p>

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://= tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-03<= /font>

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-03<= /font>

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B h= ttp://tools.ietf.org/html/draft-jones-jose-json-private-key-01

 =3B

HTML formatted versions are available at:

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-ietf-jose-json-web-signature-07.h= tml

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-07= .html

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-ietf-jose-json-web-key-07.html

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-07= .html

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-ietf-oauth-json-web-token-05.html

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B = http://self-issued.info/docs/draft-ietf-oauth-jwt-bearer-03.html=

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-jones-jose-jws-json-seriali= zation-03.html

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-jones-jose-jwe-json-seriali= zation-03.html

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-jones-jose-json-private-key-01.htm= l

 =3B

See the history entries in the specs for deta= iled change descriptions.

 =3B

 =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B -- Mike

= --_1feab312-44d6-48da-a66c-d0239bafe1e7_-- From internet-drafts@ietf.org Wed Nov 7 06:38:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A2721F8595; Wed, 7 Nov 2012 06:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yj2O195zYs7Z; Wed, 7 Nov 2012 06:38:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C598F21F8604; Wed, 7 Nov 2012 06:38:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121107143821.17516.39233.idtracker@ietfa.amsl.com> Date: Wed, 07 Nov 2012 06:38:21 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:38:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : Assertion Framework for OAuth 2.0 Author(s) : Brian Campbell Chuck Mortimore Michael B. Jones Yaron Y. Goland Filename : draft-ietf-oauth-assertions-07.txt Pages : 22 Date : 2012-11-07 Abstract: This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-assertions-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-assertions-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Nov 7 07:02:26 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300BA21F8BE6; Wed, 7 Nov 2012 07:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRMxFJQF7n8k; Wed, 7 Nov 2012 07:02:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5FC21F8BE0; Wed, 7 Nov 2012 07:02:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121107150225.23174.65843.idtracker@ietfa.amsl.com> Date: Wed, 07 Nov 2012 07:02:25 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-15.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:02:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Brian Campbell Chuck Mortimore Filename : draft-ietf-oauth-saml2-bearer-15.txt Pages : 17 Date : 2012-11-07 Abstract: This specification defines the use of a SAML 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-saml2-bearer-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prateek.mishra@oracle.com Wed Nov 7 07:16:39 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB4021F8BB1 for ; Wed, 7 Nov 2012 07:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9w16d5OKxTt for ; Wed, 7 Nov 2012 07:16:38 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7620E21F8BAE for ; Wed, 7 Nov 2012 07:16:38 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA7FGZdh020247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Nov 2012 15:16:36 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA7FGYM7009082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Nov 2012 15:16:35 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qA7FGXUt013612; Wed, 7 Nov 2012 09:16:34 -0600 Received: from [192.168.1.2] (/71.184.95.145) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Nov 2012 07:16:33 -0800 Message-ID: <509A7B47.8050308@oracle.com> Date: Wed, 07 Nov 2012 10:16:23 -0500 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: oauth@ietf.org References: <7C0172BC-1D34-4C96-9220-0496BF14B262@gmx.net> In-Reply-To: <7C0172BC-1D34-4C96-9220-0496BF14B262@gmx.net> Content-Type: multipart/alternative; boundary="------------040707070203090209050604" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [OAUTH-WG] Please review draft-ietf-oauth-json-web-token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:16:39 -0000 This is a multi-part message in MIME format. --------------040707070203090209050604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hannes - here a couple of comments on the 05 draft - (i) Section 4 - [quote] Note however, that the set of claims that a JWT must contain to be considered valid is context-dependent and is outside the scope of this specification. When used in a security-related context, implementations MUST understand and support all of the claims present; otherwise, the JWT MUST be rejected for processing. [\quote] I am not sure what is being stated here. I understand the general sense of the paragraph but I found the two sentences to be contradictory. The second sentence is also very strong - suppose we find some private claim in a JWT that the recipient is unable to understand - perhaps an optional attribute-value pair - MUST it then reject the token? (ii) Section 6 - [quote] A plaintext JWT is a JWS using the "none" JWS "alg" header parameter value defined in JSON Web Algorithms (JWA) [JWA ]; it is a JWS with an empty JWS Signature value. [\quote] It is later clarified that by "empty JWS Signature value" the draft means "empty string". That could be added as a parenthetical remark at the end of the sentence. I actually spent some time looking up the term "empty JWS Signature value" in the JWS specification. Thanks, prateek > Hi all, > > you may have noticed that the JOSE working group had made good progress with their work and they are getting closer to a WGLC. This is a good point in time for us to review the JWT spec (see http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/). Please read through it in preparation for the meeting. > > It would be good to hear who has implemented it and whether there is feedback on the document. Given the OpenID Connect interoperability tests there seem to be lots of implementations. > > We would like to start a WGLC as soon as the WGLC for the JOSE documents starts. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040707070203090209050604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hannes - here a couple of comments on the 05 draft -

(i) Section 4 -

[quote]
Note however, that the set of claims that a JWT must contain to be
considered valid is context-dependent and is outside the scope of this specification. When
used in a security-related context, implementations MUST understand and support all of the
claims present; otherwise, the JWT MUST be rejected for processing.
[\quote]

I am not sure what is being stated here. I understand the general sense of the paragraph but I found the
two sentences to be contradictory. The second sentence is also very strong - suppose we find
some private claim in a JWT that the recipient is unable to understand - perhaps an optional
attribute-value pair - MUST it then reject the token?

(ii) Section 6 -

[quote]
A plaintext
   JWT is a JWS using the "none" JWS "alg" header parameter value
   defined in JSON Web Algorithms (JWA) [JWA]; it is a JWS with an empty
   JWS Signature value.

[\quote]

It is later clarified that by "empty JWS Signature value" the draft means "empty string". That could
be added as a parenthetical remark at the end of the sentence. I actually spent some time looking
up the term "empty JWS Signature value" in the JWS specification.

Thanks,
prateek
Hi all, 

you may have noticed that the JOSE working group had made good progress with their work and they are getting closer to a WGLC. This is a good point in time for us to review the JWT spec (see http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/). Please read through it in preparation for the meeting. 

It would be good to hear who has implemented it and whether there is feedback on the document. Given the OpenID Connect interoperability tests there seem to be lots of implementations. 

We would like to start a WGLC as soon as the WGLC for the JOSE documents  starts. 

Ciao
Hannes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------040707070203090209050604-- From bcampbell@pingidentity.com Wed Nov 7 07:18:08 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9C821F8BAE for ; Wed, 7 Nov 2012 07:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEal2lnrvFOW for ; Wed, 7 Nov 2012 07:18:08 -0800 (PST) Received: from na3sys009aog128.obsmtp.com (na3sys009aog128.obsmtp.com [74.125.149.141]) by ietfa.amsl.com (Postfix) with ESMTP id 24CCE21F8BDD for ; Wed, 7 Nov 2012 07:18:06 -0800 (PST) Received: from mail-ye0-f198.google.com ([209.85.213.198]) (using TLSv1) by na3sys009aob128.postini.com ([74.125.148.12]) with SMTP ID DSNKUJp7rSYrNZCsveUxkF84uFmQPB8No/rY@postini.com; Wed, 07 Nov 2012 07:18:06 PST Received: by mail-ye0-f198.google.com with SMTP id q10so3131963yen.1 for ; Wed, 07 Nov 2012 07:18:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=6o66zZ+NTkSmcc06d4jftUY/L9hq/+6vGnukEUNy9aY=; b=oqj4nbYJQFnIJK6rjLKdATqUnssZSwfXAQNXlS5B7S+jaDqrln9+ovNqG//ZzNauRt SzzyZLgZ6IUkm8KIu0alpRf1+qD5NCX7g9akM476UonFNaxcrscTE9VH2DCgYF7hG3cq gBNp9m/JKe2Ih/on+fxME80yS3FdT4trNsXuZUDbIEr0QzAKrVqAtzQCTnq0ATlXAyz8 dgqCQ9lqi2y9CgHIh/UrnJaTrh07SZaxfSoWVedwoAcZ/LVVEJ0JT0f5mi/24U46cCt4 U97YIWszntCKv43bxJKx1Aaa522n1K9FT/aghtguaknimb5o1xX4Hl5nYJqnU1VKf4YB VGUQ== Received: by 10.220.157.75 with SMTP id a11mr4393047vcx.27.1352301485069; Wed, 07 Nov 2012 07:18:05 -0800 (PST) Received: by 10.220.157.75 with SMTP id a11mr4393039vcx.27.1352301484949; Wed, 07 Nov 2012 07:18:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.151.44 with HTTP; Wed, 7 Nov 2012 07:17:34 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943668A4CF4@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Brian Campbell Date: Wed, 7 Nov 2012 08:17:34 -0700 Message-ID: To: "Anganes, Amanda L" Content-Type: multipart/alternative; boundary=f46d043be1dea3c01804cde93907 X-Gm-Message-State: ALoCoQlinlSJPj25CuSUSo2+x1SKfNtVUB0/Wn9YF2QWY6G93wHAnKk+CJ5Pyme2ki78BH0E4VnmD/1Pkk/Rw73ke6eWk9ddr3kxnkIoZrpYFY9C9hN+oYtttQqrMOHEWkkrwm8dHhzJ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of Assertions drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:18:09 -0000 --f46d043be1dea3c01804cde93907 Content-Type: text/plain; charset=ISO-8859-1 Fixed that one in -15 of the SAML draft. Thanks for the review. FWIW, the requirement about only one client authentication mechanism being used actually comes from core OAuth at http://tools.ietf.org/html/rfc6749#section-2.3 and is worded pretty strongly there where it says, "The client MUST NOT use more than one authentication method in each request." On Tue, Nov 6, 2012 at 2:46 PM, Anganes, Amanda L wrote: > Good catch, thanks for double-checking. > > --Amanda > > From: Mike Jones > Date: Tuesday, November 6, 2012 4:40 PM > To: "Anganes, Amanda L" , "oauth@ietf.org" < > oauth@ietf.org> > Subject: RE: Review of Assertions drafts > > Amanda wrote: [3] Section 2.2 first sentence: "client authentication > grant" should just be "client authentication".**** > > ** ** > > This change should also be applied to the first sentence of 2.2 in SAML > draft, where the same phrase occurs.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > *On Behalf Of *Anganes, Amanda L > *Sent:* Tuesday, November 06, 2012 12:41 PM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Review of Assertions drafts**** > > ** ** > > Hannes requested that some folks read through the assertion drafts and > give feedback in light of the upcoming shepherd review.**** > > ** ** > > [1] http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > [2] http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > [3] http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/**** > > ** ** > > I can't speak to the security considerations or advisability of these > drafts, but as far as the documents go I think they are well-organized, > consistent (internally and across all 3 documents) and straightforward. ** > ** > > ** ** > > A few comments:**** > > ** ** > > [1] Section 4.2.1 says in passing that it is an error condition "if more > than one client authentication mechanism is used". If this is a true > requirement / error state I think it should be called out more strongly. > Perhaps 4.2 should say at the top that "Other client authentication > mechanisms MUST NOT be used in conjunction with an assertion". **** > > ** ** > > If so, [2] 3.2 and [3] 3.2 should also indicate that additional client > credentials MUST NOT be used in addition to the assertion for Client > Authentication.**** > > ** ** > > [3] Section 2.2 first sentence: "client authentication grant" should just > be "client authentication".**** > > ** ** > > --Amanda Anganes**** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --f46d043be1dea3c01804cde93907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fixed that one in -15 of the SAML draft. Thanks for the review.

FWIW= , the requirement about only one client authentication mechanism being used= actually comes from core OAuth at http://tools.ietf.org/html/rfc6749#section-2.3 and i= s worded pretty strongly there where it says, "The client MUST NOT use= more than one authentication method in each request."


On Tue, Nov 6, 2012 at 2:46 PM, Anganes, Amanda L <= ;aanganes@mitre.org= > wrote:
Good catch, thanks for double-checking.=A0

--Amanda

From: Mike Jones <Michael.Jones@microsoft.= com>
Date: Tuesday, November 6, 2012 4:4= 0 PM
To: "Anganes, Amanda L" &= lt;aanganes@mitre.o= rg>, "oauth= @ietf.org" <oauth@ietf.org>
Subject: RE: Review of Assertions d= rafts

Amanda wrote: [3] = Section 2.2 first sentence: "client authentication grant" should = just be "client authentication".

=A0

This change should also be applied to the fi= rst sentence of 2.2 in SAML draft, where the same phrase occurs.<= /u>

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike=

=A0

From: oauth-bounces@i= etf.org [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Anganes, Amanda L
Sent: Tuesday, November 06, 2012 12:41 PM
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Review of Assertions drafts=

=A0

Hannes requested that some folks read through the assertion dra= fts and give feedback in light of the upcoming shepherd review.

=A0

=A0

I can't speak to the security considerations or advisabilit= y of these drafts, but as far as the documents go I think they are well-org= anized, consistent (internally and across all 3 documents) and straightforward.=A0

=A0

A few comments:

=A0

[1] Section=A04.2.1 says in passing that it is an error conditi= on "if more than one client authentication mechanism is used". If= this is a true requirement / error state I think it should be called out more strongly. Perhaps 4.2 s= hould say at the top that "Other client authentication mechanisms MUST= NOT be used in conjunction with an assertion".=A0

=A0

If so, [2] 3.2 and [3] 3.2 should=A0also indicate that addition= al client credentials MUST NOT be used in addition to the assertion for Cli= ent Authentication.

=A0

[3] Section 2.2 first sentence: "client authentication gra= nt" should just be "client authentication".

=A0

--Amanda Anganes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--f46d043be1dea3c01804cde93907-- From bcampbell@pingidentity.com Wed Nov 7 07:38:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902FE21F8BAC for ; Wed, 7 Nov 2012 07:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.476 X-Spam-Level: X-Spam-Status: No, score=-5.476 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_57=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVXxKZLZX7bw for ; Wed, 7 Nov 2012 07:38:23 -0800 (PST) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5687F21F8A3E for ; Wed, 7 Nov 2012 07:38:23 -0800 (PST) Received: from mail-yh0-f70.google.com ([209.85.213.70]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKUJqAbm/pmuiZ4v+Y7ugjp+yiMJ0pSh+q@postini.com; Wed, 07 Nov 2012 07:38:23 PST Received: by mail-yh0-f70.google.com with SMTP id o21so2943065yho.1 for ; Wed, 07 Nov 2012 07:38:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=4aKmTMwftKG4Vf3xFFzISur5THsix2C9dLNoDArPbbE=; b=nX+wHif9rv4uhGGj9Htzn5xBsj18eW5m1vLt/iGRmKb9eYBZGVqHuaJ27fNgnKrtB+ +bMEZgWQZe7Gq48qM9CmI1A2hLvfDnBQtx7TFs+C4NsqPzXe1vXzpl02OXCfxYduV/HA cmWa0dsSLLFVTSVHaM/LPhTaxeRBH2qrhe6T/yT1mdxnMo0sZ9M2xkZdvRTRQCvrvEUM jOx8o0c82+Xr3f2VRTGkKUN+c6odv5nBqwTV+dJoFsU/sbGOwYptUJDyAzfFJ7A3KK31 F3LP4c7b40DeGp/VqYi1Xnuyw7NvoZDIT1Spnpo/DwL2zXoNLYKPnNo9NJc/ZXXtkQPb 3sLQ== Received: by 10.52.27.100 with SMTP id s4mr3841110vdg.105.1352302702330; Wed, 07 Nov 2012 07:38:22 -0800 (PST) Received: by 10.52.27.100 with SMTP id s4mr3841101vdg.105.1352302702222; Wed, 07 Nov 2012 07:38:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.151.44 with HTTP; Wed, 7 Nov 2012 07:37:52 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Wed, 7 Nov 2012 08:37:52 -0700 Message-ID: To: Michael Jones Content-Type: multipart/alternative; boundary=bcaec5015e2b31ddbf04cde98280 X-Gm-Message-State: ALoCoQlCPZw3KI6N6VSJL3Lsbb6mGggAiDV80ivyWjfs1m1ouYIEyuT7pLU9Ji1pAmMN0mF1ShgPMwmaxAaOPEbzqnWJpjmm+UAnmVCNVkNq+siuDklPY6SFoKatDH1E+kkoZMwfnHpK Cc: oauth Subject: Re: [OAUTH-WG] JOSE and JWT specs updated for IETF 85 working group meetings X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:38:25 -0000 --bcaec5015e2b31ddbf04cde98280 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On the heels of this, I've just published new versions of the "Assertion Framework for OAuth 2.0" and "SAML 2.0 Bearer Assertion Profiles for OAuth 2.0" that update references to the new RFCs and fix some typos recently identified by folks in the WG. The updated documents are available at: http://tools.ietf.org/html/draft-ietf-oauth-assertions-07 http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 On Wed, Nov 7, 2012 at 3:13 AM, Michael Jones wrote: > I=92ve made a small set of updates to the JSON Object Signing and > Encryption (JOSE) and JSON Web Token (JWT) specs in preparation for the > JOSE and OAuthworking group meetings at IETF > 85 . These updates incorporate > resolutions to issues that have been discussed by the working groups sinc= e > publication of the previous drafts.****** > > ** ** > > Normative changes to the working group specs were to add length fields fo= r > PartyUInfo and PartyVInfo values for key derivation calculations and to > change the JWK field identifiers for RSA keys from (mod, xpo) to (n, e). > Fields for representing the RSA private key values needed for Chinese > Remainder Theorem (CRT) calculations were added to the JSON Private Key > specification.**** > > ** ** > > The updated specs are available at:**** > > =B7 http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-= 07* > *** > > =B7 http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption= -07 > **** > > =B7 http://tools.ietf.org/html/draft-ietf-jose-json-web-key-07**** > > =B7 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms= -07 > **** > > =B7 http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05*= *** > > =B7 http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03**** > > =B7 > http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-03**** > > =B7 > http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-03**** > > =B7 http://tools.ietf.org/html/draft-jones-jose-json-private-key-0= 1** > ** > > ** ** > > HTML formatted versions are available at:**** > > =B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-signature-07.html**= * > * > > =B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-07.html*= * > ** > > =B7 http://self-issued.info/docs/draft-ietf-jose-json-web-key-07.h= tml > **** > > =B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-07.html*= * > ** > > =B7 > http://self-issued.info/docs/draft-ietf-oauth-json-web-token-05.html**** > > =B7 http://self-issued.info/docs/draft-ietf-oauth-jwt-bearer-03.ht= ml* > *** > > =B7 > http://self-issued.info/docs/draft-jones-jose-jws-json-serialization-03.h= tml > **** > > =B7 > http://self-issued.info/docs/draft-jones-jose-jwe-json-serialization-03.h= tml > **** > > =B7 > http://self-issued.info/docs/draft-jones-jose-json-private-key-01.html***= * > > ** ** > > See the history entries in the specs for detailed change descriptions.***= * > > ** ** > > -- Mike**** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --bcaec5015e2b31ddbf04cde98280 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On the heels of this, I've just published new versions of the "Ass= ertion Framework for OAuth 2.0" and "SAML 2.0 Bearer Assertion Profiles= for=20 OAuth 2.0" that update references to the new RFCs and fix some typos= =20 recently identified by folks in the WG.

The updated documents are av= ailable at:
http://tools.ietf.org/html/draft-ietf-oauth-assertions-07
htt= p://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15


On Wed, Nov 7, 2012 at 3:13 = AM, Michael Jones <michael_b_jones@hotmail.com> wr= ote:

I=92ve made a small set of updates to the JSON Object Sig= ning and Encryption (JOSE) and JSON Web Token (JWT) specs in preparation for the= JOSE= and OAuth = working group meetings at IETF 85.=A0 These updates incorporate resolutions to issues that have been discussed by the working groups since publication of the previous drafts.

=A0

Normative changes to the working group specs were t= o add length fields for PartyUInfo and PartyVInfo values for key derivation calculations and to change the JWK field identifiers for RSA keys from (mod= , xpo) to (n, e).=A0 Fields for representing the RSA private key values neede= d for Chinese Remainder Theorem (CRT) calculations were added to the JSON Pri= vate Key specification.

=A0

The updated specs are available at:

=B7=A0=A0=A0= =A0=A0=A0=A0 http://tools.ietf.org/html/draft-ietf-jose-json-web-signa= ture-07

=B7=A0=A0=A0= =A0=A0=A0=A0 http://tools.ietf.org/html/draft-ietf-jose-json-web-encr= yption-07

=B7=A0=A0=A0= =A0=A0=A0=A0 http://tools.ietf.org/html/draft-ietf-jose-json-web-key-07

=B7=A0=A0=A0= =A0=A0=A0=A0 http://tools.ietf.org/html/draft-ietf-jose-json-web-algo= rithms-07

=B7=A0=A0=A0= =A0=A0=A0=A0 http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-0= 5

=B7=A0=A0=A0= =A0=A0=A0=A0 http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03=

=B7=A0=A0=A0= =A0=A0=A0=A0 http://tools.ietf.org/html/draft-jones-jose-jws-jso= n-serialization-03

=B7=A0=A0=A0= =A0=A0=A0=A0 http://tools.ietf.org/html/draft-jones-jose-jwe-jso= n-serialization-03

=B7=A0=A0=A0= =A0=A0=A0=A0 http://tools.ietf.org/html/draft-jones-jose-json-private-k= ey-01

=A0

HTML formatted versions are available at:=

=B7=A0=A0=A0= =A0=A0=A0=A0 http://self-issued.info/docs/draft-ietf-jose-json-= web-signature-07.html

=B7=A0=A0=A0= =A0=A0=A0=A0 http://self-issued.info/docs/draft-ietf-jose-json= -web-encryption-07.html

=B7=A0=A0=A0= =A0=A0=A0=A0 http://self-issued.info/docs/draft-ietf-jose-json-web-ke= y-07.html

=B7=A0=A0=A0= =A0=A0=A0=A0 http://self-issued.info/docs/draft-ietf-jose-json= -web-algorithms-07.html

=B7=A0=A0=A0= =A0=A0=A0=A0 http://self-issued.info/docs/draft-ietf-oauth-json-= web-token-05.html

=B7=A0=A0=A0= =A0=A0=A0=A0 http://self-issued.info/docs/draft-ietf-oauth-jwt-bearer-= 03.html

=B7=A0=A0=A0= =A0=A0=A0=A0 http://self-issued.info/docs/draft-jones-jose= -jws-json-serialization-03.html

=B7=A0=A0=A0= =A0=A0=A0=A0 http://self-issued.info/docs/draft-jones-jose= -jwe-json-serialization-03.html

=B7=A0=A0=A0= =A0=A0=A0=A0 http://self-issued.info/docs/draft-jones-jose-json-= private-key-01.html

=A0

See the history entries in the specs for detailed c= hange descriptions.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--bcaec5015e2b31ddbf04cde98280-- From leifj@mnt.se Thu Nov 8 08:02:14 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBA921F8B7C for ; Thu, 8 Nov 2012 08:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-ByCM+MijPE for ; Thu, 8 Nov 2012 08:02:14 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A998A21F8A60 for ; Thu, 8 Nov 2012 08:02:10 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1325230dan.31 for ; Thu, 08 Nov 2012 08:02:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=3cV6+r/91s7/Ak1pzpSmEOudRfCRXlgUyXcKBNbWrpA=; b=Pzjl6EwdFpEaN/jGdH1gnqewF7GschQ0Y+rVo3zr8eWhbmYSJksiqNFvpT1ooKKxkI +bA12J89LfPHFDWk7TcAj1qlyj2/+N4p/VEftfj/S3DDx/WSCTshxpbJYnv7BrK7Z/rm TkjXHdtyjnbPbtQm+xUaXOULm0CcZsyILV49uR4z8jeYW6gvqDDVA/f8lKKlcHWWr56d 5oBf0r3OBXTYAy42SgV89++yXM+WByfbbMmyLVxgcXALKP/IgpdJlBt7BmFhwdPmYGdz +27oaSZxbR9EbdBHAIzisNliOnMvEFumEb9zrHa5Y1fuyNvvhlog5LZZ10aIDRtgYb7a /KBQ== Received: by 10.68.192.5 with SMTP id hc5mr25595714pbc.16.1352390522274; Thu, 08 Nov 2012 08:02:02 -0800 (PST) Received: from ?IPv6:2001:df8:0:8:e98e:2773:e7a0:457f? ([2001:df8:0:8:e98e:2773:e7a0:457f]) by mx.google.com with ESMTPS id m7sm11093511paz.3.2012.11.08.08.01.59 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 08:02:01 -0800 (PST) Message-ID: <509BD776.3090106@mnt.se> Date: Thu, 08 Nov 2012 17:01:58 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: multipart/alternative; boundary="------------060605000603090804000706" X-Gm-Message-State: ALoCoQnHdGUD9XKJn22VxzENulY++wGYw0W4dW617kBBugT9TX4h35AwJM4gPzB8Q0xZaNwV9dPU Subject: [OAUTH-WG] bag-of-keys metadata UC for the "mac" discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:02:14 -0000 This is a multi-part message in MIME format. --------------060605000603090804000706 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I promised to send a UC to the list as input to the discussion around new token formats. --- Several large-scale deployments of public-key use a "bag-of-keys" model for key management: you stick endpoint information together with public keys for those endpoints in a signable container which is then signed with a private key associated with some "trust provider" an distributed to all entities/relying parties. Examples include various trust status lists formats and things like SAML metadata. The latter case (SAML metadata) isn't necessarily tied to the SAML v2 _protocol_ but it is used for that. Large-scale SAML federations are often setup to depend on distribution of signed SAML metadata. Consider the case when a large number of relying parties of such a SAML federation are also either OAUTH2 resource or authorization servers. Today all of those OAUTH2 entities have to be provisioned with separate client secrets that have no relationship to the trust infrastructure already in use in the federation. It is not uncommon for such federations to have 1000s and sometimes 10000s of entities making client secret management something of a scalability issue. Even with dynreg the problem of managing all of those client secrets would still remain a *huge* (operational) security and scalability issue. There is therefore a desire among communities that have such deployments to be able to re-use the key-management already in place for OAUTH2. Note that this example isn't tied to the SAML protocol at all. Leif --------------060605000603090804000706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
I promised to send a UC to the list as input to the discussion around new
token formats.

---

Several large-scale deployments of public-key use a "bag-of-keys" model
for key management: you stick endpoint information together with public
keys for those endpoints in a signable container which is then signed with
a private key associated with some "trust provider" an distributed to all
entities/relying parties.

Examples include various trust status lists formats and things like SAML
metadata.

The latter case (SAML metadata) isn't necessarily tied to the SAML v2
_protocol_ but it is used for that. Large-scale SAML federations are often
setup to depend on distribution of signed SAML metadata.

Consider the case when a large number of relying parties of such a SAML
federation are also either OAUTH2 resource or authorization servers. Today
all of those OAUTH2 entities have to be provisioned with separate client
secrets that have no relationship to the trust infrastructure already in use
in the federation.

It is not uncommon for such federations to have 1000s and sometimes
10000s of entities making client secret management something of a
scalability issue.

Even with dynreg the problem of managing all of those client secrets
would still remain a *huge* (operational) security and scalability issue.

There is therefore a desire among communities that have such deployments
to be able to re-use the key-management already in place for OAUTH2.

Note that this example isn't tied to the SAML protocol at all.

        Leif
--------------060605000603090804000706-- From ve7jtb@ve7jtb.com Thu Nov 8 09:43:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0732621F84FC for ; Thu, 8 Nov 2012 09:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KxAsLHuGWd4 for ; Thu, 8 Nov 2012 09:43:31 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 19AA321F8206 for ; Thu, 8 Nov 2012 09:43:31 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2341494pbb.31 for ; Thu, 08 Nov 2012 09:43:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=/6CkwOP+GtEC/m1P7TS/YSMbKERzm0ivs4ouktVPJe4=; b=UtyjHcOzQHp2r18BtzpBGn2KzU/b9cRg7Mzo1lsB7r4W0vVqquCx/TxM0iE4utbdgI k9UKNsnoAzasYindlI0focoOhtbP8m2MjvkhUkPsNgWyTuC4oHejqCbSjcFoUTuo947q 4Qjm80owX3NhxgPgcWnKx/GhZA0AhqdWOOUCFmRuahdhMmyW50Cr36OnU7QwlKpJHS9s Sd3D/5a4ruukYsNv9Hlbn38ifjXScQWrNilcdElxQBO9sbibN1XJKLv1nxzXMJamStWm RwXiiMon71U8ciF/cd9jUt8xVn2Q/Eql46PztRifDECOnnzo/ovkUSyluUeNcbcYwSMx ZnFg== Received: by 10.66.87.167 with SMTP id az7mr24174041pab.69.1352396606771; Thu, 08 Nov 2012 09:43:26 -0800 (PST) Received: from ?IPv6:2001:df8::64:70cf:8418:2460:4d64? ([2001:df8:0:64:70cf:8418:2460:4d64]) by mx.google.com with ESMTPS id ug6sm8147413pbc.4.2012.11.08.09.43.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 09:43:25 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D7304022-4939-46F0-8AC5-10B74CAB01FC" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Thu, 8 Nov 2012 12:43:21 -0500 Message-Id: <7AA04640-AC9C-4C9E-B1E1-77F92CEE2ABF@ve7jtb.com> References: <20121105221233.23937.33477.idtracker@ietfa.amsl.com> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkTAC2KGK822dlfjiSN1gOy/nHeOfLbkhkRcBO3kLNqJZ5fc7Sq8A2IlIL4EiXdgjOnh13v Cc: "openid-specs-ab@lists.openid.net" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Openid-specs-ab] I-D Action: draft-ietf-oauth-dyn-reg-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 17:43:33 -0000 --Apple-Mail=_D7304022-4939-46F0-8AC5-10B74CAB01FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Also in openID 2 there was an association endpoint that is similar where = the client got its secret. Mostly the term is a carryover from that. I don't have any real objection to changing it to registration to align = better with OAuth terminology in the IETF version. John B. On 2012-11-05, at 5:50 PM, "Richer, Justin P." = wrote: > I thought of this during the merge process as well -- "associate" is a = direct import from OIDC. The reasoning behind this verb is that you're = "associating" a set of client metadata to a particular client = identifier. >=20 > I'd be happy to change this term to "client_register" if there's = consensus for a move to that terminology. >=20 > Also, forgot to mention this before: The latest version of it will = always be on my github: >=20 > https://github.com/jricher/oauth-spec >=20 > This has the added benefit of allowing you all to fork the repo, make = edits, file issues, and make pull requests against the document in = between uploads to the IETF datatracker. >=20 > -- Justin >=20 >=20 > On Nov 5, 2012, at 5:38 PM, Tim Bray wrote: >=20 >> Quick question: Why is it =93association request=94, not = =93registration request=94? Nearly everywhere the term =93association=94 = appears, it seems like you could insert =93registration=94 and achieve = better clarity. -T >>=20 >> On Mon, Nov 5, 2012 at 2:20 PM, Richer, Justin P. = wrote: >> This draft combines the best-usable parts UMA and OpenID Connect = dynamic registration drafts into one document that's designed to = facilitate dynamic client registration. I've significantly reorganized = the document and I've tried to exorcise any obvious dependencies on = OpenID Connect or UMA. This protocol follows the OpenID Connect = registration model most closely, in that it's form-parameters in and = JSON out (as opposed to JSON round trip). This matches the rest of the = OAuth protocol. It's a push model only for metadata as well, but it = allows clients to push updates. >>=20 >> General formatting is still rough, but I think that the text is = mostly readable and complete. There are several Editor's Notes in the = document that bring up what I consider to be open questions or issues = with the functionality. One that I forgot to leave a note for is client = unregistration. Does it make sense to provide mechanisms for a full = lifecycle for well-behaved clients? >>=20 >> We'll be discussing this draft in person at the IETF meeting for the = OAuth working group on Thursday for anybody who wants to throw tomatoes = at me*. >>=20 >> -- Justin >>=20 >>=20 >> *Please do not actually throw tomatoes at me. >>=20 >> ________________________________________ >> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of = internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Monday, November 05, 2012 5:12 PM >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >>=20 >> Title : OAuth Dynamic Client Registration Protocol >> Author(s) : Justin Richer >> Thomas Hardjono >> Maciej Machulak >> Eve Maler >> Christian Scholz >> Nat Sakimura >> John Bradley >> Michael B. Jones >> Filename : draft-ietf-oauth-dyn-reg-01.txt >> Pages : 20 >> Date : 2012-11-05 >>=20 >> Abstract: >> This specification proposes an OAuth Dynamic Client Registration >> protocol. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-01 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-01 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 >>=20 >=20 > _______________________________________________ > Openid-specs-ab mailing list > Openid-specs-ab@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab --Apple-Mail=_D7304022-4939-46F0-8AC5-10B74CAB01FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Also = in openID 2 there was an association endpoint that is similar where the = client got its secret.   Mostly the term is a carryover from = that.

I don't have any real objection to changing it = to registration to align better with OAuth terminology in the IETF = version.

John B.

On = 2012-11-05, at 5:50 PM, "Richer, Justin P." <jricher@mitre.org> = wrote:

I thought of this during the merge process as well -- "associate" is a = direct import from OIDC. The reasoning behind this verb is that you're = "associating" a set of client metadata to a particular client = identifier.

I'd be happy to change this term to "client_register" if there's = consensus for a  move to that terminology.

Also, forgot to mention this before: The latest version of it will = always be on my github:


This has the added benefit of allowing you all to fork the repo, = make edits, file issues, and make pull requests against the document in = between uploads to the IETF datatracker.

 -- Justin


On Nov 5, 2012, at 5:38 PM, Tim Bray wrote:

Quick= question: Why is it =93association request=94, not =93registration = request=94?  Nearly everywhere the term =93association=94 appears, = it seems like you could insert =93registration=94 and achieve better clarity. -T

On Mon, Nov 5, 2012 at 2:20 PM, Richer, = Justin P. <jricher@mitre.org> wrote:
This draft combines the best-usable parts UMA and OpenID Connect dynamic = registration drafts into one document that's designed to facilitate = dynamic client registration. I've significantly reorganized the document = and I've tried to exorcise any obvious dependencies on OpenID Connect or UMA. This protocol follows the OpenID Connect = registration model most closely, in that it's form-parameters in and = JSON out (as opposed to JSON round trip). This matches the rest of the = OAuth protocol. It's a push model only for metadata as well, but it allows clients to push updates.

General formatting is still rough, but I think that the text is mostly = readable and complete. There are several Editor's Notes in the document = that bring up what I consider to be open questions or issues with the = functionality. One that I forgot to leave a note for is client unregistration. Does it make sense to provide = mechanisms for a full lifecycle for well-behaved clients?

We'll be discussing this draft in person at the IETF meeting for the = OAuth working group on Thursday for anybody who wants to throw tomatoes = at me*.

 -- Justin


*Please do not actually throw tomatoes at me.

________________________________________
From: oauth-bounces@ietf.org= [oauth-bounces@ietf.org] = on behalf of internet-drafts@ietf.org = [internet-drafts@ietf.org]
= Sent: Monday, November 05, 2012 5:12 PM
To: i-d-announce@ietf.org
= Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts = directories.
 This draft is a work item of the Web Authorization Protocol = Working Group of the IETF.

        Title           : = OAuth Dynamic Client Registration Protocol
        Author(s)       : Justin = Richer
                    =       Thomas Hardjono
                    =       Maciej Machulak
                    =       Eve Maler
                    =       Christian Scholz
                    =       Nat Sakimura
                    =       John Bradley
                    =       Michael B. Jones
        Filename        : = draft-ietf-oauth-dyn-reg-01.txt
        Pages           : = 20
        Date           =  : 2012-11-05

Abstract:
   This specification proposes an OAuth Dynamic Client = Registration
   protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-re= g

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-= reg-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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


_______________________________________________
Openid-specs-ab = mailing list
Openid-specs-ab@lists.ope= nid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab

= --Apple-Mail=_D7304022-4939-46F0-8AC5-10B74CAB01FC-- From nichole.richardson.27@facebook.com Fri Nov 9 14:23:03 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B0E21F8652 for ; Fri, 9 Nov 2012 14:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.16 X-Spam-Level: X-Spam-Status: No, score=-100.16 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0KAnN6xIeKS for ; Fri, 9 Nov 2012 14:23:02 -0800 (PST) Received: from smtpout.mx.facebook.com (unknown [69.171.244.65]) by ietfa.amsl.com (Postfix) with ESMTP id D49F221F8650 for ; Fri, 9 Nov 2012 14:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=facebook.com; s=s1024-2010-q3; c=relaxed/simple; q=dns/txt; i=@facebook.com; t=1352499773; h=From:Subject:X-:Date:To:MIME-Version:Content-Type; bh=OWonfYHDA+k++z9tNWPFaCSNV3HDYFKAdr2J5UHCyrg=; b=sNUDoVxe5yLSKYnk3pJsB0CtgHk5fftYk3DfOOKwzzrosUCNroDipm5f8V++nBpD ikwbvUAVeVjSNkIj0nif+4OE5TML0/i+pKYczrTQHPaV6pDHQ9bkAtfRxgRnR1+D cXLCEZPQqUsd8GmJlrwzgBtEm0uUVJGGG7pQ7JSl8VY=; Received: from [10.148.86.69] ([10.148.86.69:62914] helo=www.facebook.com) by 10.148.130.55 (envelope-from ) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id C1/28-20431-D328D905; Fri, 09 Nov 2012 14:22:53 -0800 Date: Fri, 09 Nov 2012 14:22:53 -0800 From: Nichole Richardson To: , Message-ID: In-Reply-To: References: , MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14476_1510960106.1352499773675" Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 9 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 22:23:03 -0000 ------=_Part_14476_1510960106.1352499773675 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit help On November 8, 2012 12:00:32 PM PST, oauth-request@ietf.org wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/oauth > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. bag-of-keys metadata UC for the "mac" discussion (Leif Johansson) > 2. Re: [Openid-specs-ab] I-D Action: > draft-ietf-oauth-dyn-reg-01.txt (John Bradley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 08 Nov 2012 17:01:58 +0100 > From: Leif Johansson > To: oauth@ietf.org > Subject: [OAUTH-WG] bag-of-keys metadata UC for the "mac" discussion > Message-ID: <509BD776.3090106@mnt.se> > Content-Type: text/plain; charset="iso-8859-1" > > I promised to send a UC to the list as input to the discussion around new > token formats. > > --- > > Several large-scale deployments of public-key use a "bag-of-keys" model > for key management: you stick endpoint information together with public > keys for those endpoints in a signable container which is then signed with > a private key associated with some "trust provider" an distributed to all > entities/relying parties. > > Examples include various trust status lists formats and things like SAML > metadata. > > The latter case (SAML metadata) isn't necessarily tied to the SAML v2 > _protocol_ but it is used for that. Large-scale SAML federations are often > setup to depend on distribution of signed SAML metadata. > > Consider the case when a large number of relying parties of such a SAML > federation are also either OAUTH2 resource or authorization servers. Today > all of those OAUTH2 entities have to be provisioned with separate client > secrets that have no relationship to the trust infrastructure already in use > in the federation. > > It is not uncommon for such federations to have 1000s and sometimes > 10000s of entities making client secret management something of a > scalability issue. > > Even with dynreg the problem of managing all of those client secrets > would still remain a *huge* (operational) security and scalability issue. > > There is therefore a desire among communities that have such deployments > to be able to re-use the key-management already in place for OAUTH2. > > Note that this example isn't tied to the SAML protocol at all. > > Leif > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Thu, 8 Nov 2012 12:43:21 -0500 > From: John Bradley > To: "Richer, Justin P." > Cc: "openid-specs-ab@lists.openid.net" > , "oauth@ietf.org" > Subject: Re: [OAUTH-WG] [Openid-specs-ab] I-D Action: > draft-ietf-oauth-dyn-reg-01.txt > Message-ID: <7AA04640-AC9C-4C9E-B1E1-77F92CEE2ABF@ve7jtb.com> > Content-Type: text/plain; charset="windows-1252" > > Also in openID 2 there was an association endpoint that is similar where the client got its secret. Mostly the term is a carryover from that. > > I don't have any real objection to changing it to registration to align better with OAuth terminology in the IETF version. > > John B. > > On 2012-11-05, at 5:50 PM, "Richer, Justin P." wrote: > > > I thought of this during the merge process as well -- "associate" is a direct import from OIDC. The reasoning behind this verb is that you're "associating" a set of client metadata to a particular client identifier. > > > > I'd be happy to change this term to "client_register" if there's consensus for a move to that terminology. > > > > Also, forgot to mention this before: The latest version of it will always be on my github: > > > > https://github.com/jricher/oauth-spec > > > > This has the added benefit of allowing you all to fork the repo, make edits, file issues, and make pull requests against the document in between uploads to the IETF datatracker. > > > > -- Justin > > > > > > On Nov 5, 2012, at 5:38 PM, Tim Bray wrote: > > > >> Quick question: Why is it ?association request?, not ?registration request?? Nearly everywhere the term ?association? appears, it seems like you could insert ?registration? and achieve better clarity. -T > >> > >> On Mon, Nov 5, 2012 at 2:20 PM, Richer, Justin P. wrote: > >> This draft combines the best-usable parts UMA and OpenID Connect dynamic registration drafts into one document that's designed to facilitate dynamic client registration. I've significantly reorganized the document and I've tried to exorcise any obvious dependencies on OpenID Connect or UMA. This protocol follows the OpenID Connect registration model most closely, in that it's form-parameters in and JSON out (as opposed to JSON round trip). This matches the rest of the OAuth protocol. It's a push model only for metadata as well, but it allows clients to push updates. > >> > >> General formatting is still rough, but I think that the text is mostly readable and complete. There are several Editor's Notes in the document that bring up what I consider to be open questions or issues with the functionality. One that I forgot to leave a note for is client unregistration. Does it make sense to provide mechanisms for a full lifecycle for well-behaved clients? > >> > >> We'll be discussing this draft in person at the IETF meeting for the OAuth working group on Thursday for anybody who wants to throw tomatoes at me*. > >> > >> -- Justin > >> > >> > >> *Please do not actually throw tomatoes at me. > >> > >> ________________________________________ > >> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of internet-drafts@ietf.org [internet-drafts@ietf.org] > >> Sent: Monday, November 05, 2012 5:12 PM > >> To: i-d-announce@ietf.org > >> Cc: oauth@ietf.org > >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. > >> This draft is a work item of the Web Authorization Protocol Working Group of the IETF. > >> > >> Title : OAuth Dynamic Client Registration Protocol > >> Author(s) : Justin Richer > >> Thomas Hardjono > >> Maciej Machulak > >> Eve Maler > >> Christian Scholz > >> Nat Sakimura > >> John Bradley > >> Michael B. Jones > >> Filename : draft-ietf-oauth-dyn-reg-01.txt > >> Pages : 20 > >> Date : 2012-11-05 > >> > >> Abstract: > >> This specification proposes an OAuth Dynamic Client Registration > >> protocol. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-01 > >> > >> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-01 > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> 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 > >> > > > > _______________________________________________ > > Openid-specs-ab mailing list > > Openid-specs-ab@lists.openid.net > > http://lists.openid.net/mailman/listinfo/openid-specs-ab > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > End of OAuth Digest, Vol 49, Issue 9 > ************************************ ------=_Part_14476_1510960106.1352499773675 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable help

On November 8, 2012 12:00:32 PM PST, oauth-request@ietf.= org wrote:

If you have received this digest without all t= he individual message
attachments you will need to upda= te your digest options in your list
subscription.  = ;To do so, go to

https://www.ietf.= org/mailman/listinfo/oauth

Cli= ck the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can se= t this option
globally for all the list digests you rec= eive at this point.



Send OAuth mailing list submissions to
=09oauth@ietf.org

To s= ubscribe or unsubscribe via the World Wide Web, visit
<= a href=3D'https://www.ietf.org/mailman/listinfo/oauth' target=3D'_blank'>ht= tps://www.ietf.org/mailman/listinfo/oauth
or, via e= mail, send a message with subject or body 'help' to
=09= oauth-request@ietf.org

You can rea= ch the person managing the list at
=09oauth-owner@ietf.= org

When replying, please edit you= r Subject line so it is more specific
than "Re: Co= ntents of OAuth digest..."

Today's Topics:

  1. bag-of-keys metadata UC for the "mac" discussion (Lei= f Johansson)
  2. Re: [Openid-specs-ab] I-D Actio= n:
     draft-ietf-oauth-dyn-reg-01.txt= (John Bradley)


----------------------------------------------------------------------
Message: 1
Date= : Thu, 08 Nov 2012 17:01:58 +0100
From: Leif Johansson = <leifj@mnt.se>
To: oauth@ietf.org
Subject: [OAUTH-WG] bag-of-keys metadata UC for the "mac" di= scussion
Message-ID: <509BD776.3090106@mnt.se>Content-Type: text/plain; charset=3D"iso-8859-1"= ;

I promised to send a UC to the l= ist as input to the discussion around new
token formats= .

---

Several large-scale deployments of public-key use a "bag-= of-keys" model
for key management: you stick endpo= int information together with public
keys for those end= points in a signable container which is then signed with
a private key associated with some "trust provider" an distribu= ted to all
entities/relying parties.

Examples include various trust status lists formats = and things like SAML
metadata.

The latter case (SAML metadata) isn't necessarily tied to = the SAML v2
_protocol_ but it is used for that. Large-s= cale SAML federations are often
setup to depend on dist= ribution of signed SAML metadata.

= Consider the case when a large number of relying parties of such a SAML
federation are also either OAUTH2 resource or authorizatio= n servers. Today
all of those OAUTH2 entities have to b= e provisioned with separate client
secrets that have no= relationship to the trust infrastructure already in use
in the federation.

It is not unc= ommon for such federations to have 1000s and sometimes
= 10000s of entities making client secret management something of a
scalability issue.

Eve= n with dynreg the problem of managing all of those client secrets
would still remain a *huge* (operational) security and scalabil= ity issue.

There is therefore a de= sire among communities that have such deployments
to be= able to re-use the key-management already in place for OAUTH2.

Note that this example isn't tied to the SAML= protocol at all.

    &= nbsp;  Leif

-------------- ne= xt part --------------
An HTML attachment was scrubbed.= ..
URL: <= http://www.ietf.org/mail-archive/web/oauth/attachments/20121108/89d3b3f1/at= tachment.htm>

-------------= -----------------

Message: 2
Date: Thu, 8 Nov 2012 12:43:21 -0500
Fro= m: John Bradley <ve7jtb@ve7jtb.com>
To: "Ric= her, Justin P." <jricher@mitre.org>
Cc: &quo= t;openid-specs-ab@lists.openid.net"
=09<openid-= specs-ab@lists.openid.net>,=09"oauth@ietf.org" <oauth@ietf.= org>
Subject: Re: [OAUTH-WG] [Openid-specs-ab] I-D A= ction:
=09draft-ietf-oauth-dyn-reg-01.txt
Message-ID: <7AA04640-AC9C-4C9E-B1E1-77F92CEE2ABF@ve7jtb.com><= br clear=3D'none' />Content-Type: text/plain; charset=3D"windows-1252&= quot;

Also in openID 2 there was a= n association endpoint that is similar where the client got its secret. &nb= sp; Mostly the term is a carryover from that.

I don't have any real objection to changing it to registration = to align better with OAuth terminology in the IETF version.

John B.

= On 2012-11-05, at 5:50 PM, "Richer, Justin P." <jricher@mitre.= org> wrote:

> I thought of t= his during the merge process as well -- "associate" is a direct i= mport from OIDC. The reasoning behind this verb is that you're "associ= ating" a set of client metadata to a particular client identifier.
>
> I'd be happy to change this= term to "client_register" if there's consensus for a  move = to that terminology.
>
> Als= o, forgot to mention this before: The latest version of it will always be o= n my github:
>
>   https://git= hub.com/jricher/oauth-spec
>
> This has the added benefit of allowing you all to fork the repo, mak= e edits, file issues, and make pull requests against the document in betwee= n uploads to the IETF datatracker.
>
>  -- Justin
>
&g= t;
> On Nov 5, 2012, at 5:38 PM, Tim Bray wrote:>
>> Quick question: Why is= it ?association request?, not ?registration request??  Nearly everywh= ere the term ?association? appears, it seems like you could insert ?registr= ation? and achieve better clarity. -T
>>
>> On Mon, Nov 5, 2012 at 2:20 PM, Richer, Justin P. <= ;jricher@mitre.org> wrote:
>> This draft combi= nes the best-usable parts UMA and OpenID Connect dynamic registration draft= s into one document that's designed to facilitate dynamic client registrati= on. I've significantly reorganized the document and I've tried to exorcise = any obvious dependencies on OpenID Connect or UMA. This protocol follows th= e OpenID Connect registration model most closely, in that it's form-paramet= ers in and JSON out (as opposed to JSON round trip). This matches the rest = of the OAuth protocol. It's a push model only for metadata as well, but it = allows clients to push updates.
>>
>> General formatting is still rough, but I think that the tex= t is mostly readable and complete. There are several Editor's Notes in the = document that bring up what I consider to be open questions or issues with = the functionality. One that I forgot to leave a note for is client unregist= ration. Does it make sense to provide mechanisms for a full lifecycle for w= ell-behaved clients?
>>
>= > We'll be discussing this draft in person at the IETF meeting for the O= Auth working group on Thursday for anybody who wants to throw tomatoes at m= e*.
>>
>>  -- Jus= tin
>>
>>
>> *Please do not actually throw tomatoes at me.
>>
>> ___________________________= _____________
>> From: oauth-bounces@ietf.org [oa= uth-bounces@ietf.org] on behalf of internet-drafts@ietf.org [internet-draft= s@ietf.org]
>> Sent: Monday, November 05, 2012 5:= 12 PM
>> To: i-d-announce@ietf.org
>> Cc: oauth@ietf.org
>> Subject: [OA= UTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt
>= ;>
>> A New Internet-Draft is available from = the on-line Internet-Drafts directories.
>>  = ;This draft is a work item of the Web Authorization Protocol Working Group = of the IETF.
>>
>> &nb= sp;       Title           : OAuth D= ynamic Client Registration Protocol
>>   &nb= sp;     Author(s)       : Justin Richer
>>                = ;           Thomas Hardjono
&g= t;>                    = ;       Maciej Machulak
>>   =                      = ;   Eve Maler
>>        =                   Christian S= cholz
>>            = ;               Nat Sakimura
>>                 &= nbsp;         John Bradley
>>=                     &nbs= p;     Michael B. Jones
>>    = ;     Filename        : draft-ietf-oauth-dyn-= reg-01.txt
>>         Pages &= nbsp;         : 20
>>   =       Date            : 2012-1= 1-05
>>
>> Abstract:>>    This specification proposes an OAu= th Dynamic Client Registration
>>    pr= otocol.
>>
>>
>> The IETF datatracker status page for this draft is:>> https://datatracker.ietf.org/doc/d= raft-ietf-oauth-dyn-reg
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-0= 1
>>
>> A diff fro= m the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-01<= /a>
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:>> ftp://ftp.ietf.org/internet-drafts/
>>
>> ________________________________= _______________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ie= tf.org/mailman/listinfo/oauth
>> ____________= ___________________________________
>> OAuth mail= ing list
>> OAuth@ietf.org
&g= t;> https://www.ietf.org/mailman/listinfo/oauth
&= gt;>
>
> _______________= ________________________________
> Openid-specs-ab m= ailing list
> Openid-specs-ab@lists.openid.net
> http://lists.openid.net/mailman/listinfo/op= enid-specs-ab

-------------- n= ext part --------------
An HTML attachment was scrubbed= ...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20121108/10d1d87b/a= ttachment.htm>

------------= ------------------

_______________= ________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth


End of OAuth Digest, Vol 49, Issue 9
******= ******************************
------=_Part_14476_1510960106.1352499773675-- From phil.hunt@oracle.com Mon Nov 12 13:08:57 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CDE21F8685 for ; Mon, 12 Nov 2012 13:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.07 X-Spam-Level: X-Spam-Status: No, score=-3.07 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rC+xxBxipQW for ; Mon, 12 Nov 2012 13:08:55 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 831EC21F8625 for ; Mon, 12 Nov 2012 13:08:55 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qACL8riS024853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Nov 2012 21:08:54 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qACL8qPg013115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 21:08:52 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qACL8pDN016635; Mon, 12 Nov 2012 15:08:51 -0600 Received: from [192.168.1.131] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Nov 2012 13:08:51 -0800 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_6DFBA2C6-2A67-4D10-9BE0-8C2C65056817" From: Phil Hunt In-Reply-To: <509BD776.3090106@mnt.se> Date: Mon, 12 Nov 2012 13:09:11 -0800 Message-Id: <7EF786E1-18E2-4974-A6BC-2C72BE9F5C11@oracle.com> References: <509BD776.3090106@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac" discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:08:57 -0000 --Apple-Mail=_6DFBA2C6-2A67-4D10-9BE0-8C2C65056817 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Leif, I've read this a couple of times and I think I'm getting lost in partial = SAML vs. OAuth terminology. As a result, I thought you were saying: 1. It isn't practical to issue client credentials even with Dynamic = Registration 2. You want to re-use key management already in place with OAuth2. These statements seem to be in conflict. Did you mean to say for number = 2 that you want to re-use key management already in place for SAML? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-11-08, at 8:01 AM, Leif Johansson wrote: > I promised to send a UC to the list as input to the discussion around = new > token formats. >=20 > --- >=20 > Several large-scale deployments of public-key use a "bag-of-keys" = model > for key management: you stick endpoint information together with = public > keys for those endpoints in a signable container which is then signed = with > a private key associated with some "trust provider" an distributed to = all > entities/relying parties. >=20 > Examples include various trust status lists formats and things like = SAML > metadata. >=20 > The latter case (SAML metadata) isn't necessarily tied to the SAML v2 > _protocol_ but it is used for that. Large-scale SAML federations are = often > setup to depend on distribution of signed SAML metadata. >=20 > Consider the case when a large number of relying parties of such a = SAML > federation are also either OAUTH2 resource or authorization servers. = Today > all of those OAUTH2 entities have to be provisioned with separate = client > secrets that have no relationship to the trust infrastructure already = in use > in the federation. >=20 > It is not uncommon for such federations to have 1000s and sometimes > 10000s of entities making client secret management something of a > scalability issue. >=20 > Even with dynreg the problem of managing all of those client secrets > would still remain a *huge* (operational) security and scalability = issue. >=20 > There is therefore a desire among communities that have such = deployments > to be able to re-use the key-management already in place for OAUTH2. >=20 > Note that this example isn't tied to the SAML protocol at all. >=20 > Leif > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_6DFBA2C6-2A67-4D10-9BE0-8C2C65056817 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On 2012-11-08, at 8:01 AM, Leif Johansson wrote:

=20 =20 
I promised to send a UC to the list as input to the =
discussion around new
token formats.

---

Several large-scale deployments of public-key use a "bag-of-keys" model
for key management: you stick endpoint information together with public
keys for those endpoints in a signable container which is then signed =
with
a private key associated with some "trust provider" an distributed to =
all
entities/relying parties.

Examples include various trust status lists formats and things like SAML
metadata.

The latter case (SAML metadata) isn't necessarily tied to the SAML v2
_protocol_ but it is used for that. =
Large-scale SAML federations are often
setup to depend on distribution of signed SAML metadata.

Consider the case when a large number of relying parties of such a SAML
federation are also either OAUTH2 resource or authorization servers. =
Today
all of those OAUTH2 entities have to be provisioned with separate client
secrets that have no relationship to the trust infrastructure already in =
use
in the federation.

It is not uncommon for such federations to have 1000s and sometimes
10000s of entities making client secret management something of a
scalability issue.

Even with dynreg the problem of managing all of those client secrets
would still remain a *huge*=
 (operational) security and scalability issue.

There is therefore a desire among communities that have such deployments
to be able to re-use the key-management already in place for OAUTH2.

Note that this example isn't tied to the SAML protocol at all.

        Leif
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_6DFBA2C6-2A67-4D10-9BE0-8C2C65056817-- From leifj@mnt.se Mon Nov 12 13:12:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BECA21F8561 for ; Mon, 12 Nov 2012 13:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTZ+jSrJmNTd for ; Mon, 12 Nov 2012 13:12:44 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 695E621F852D for ; Mon, 12 Nov 2012 13:12:44 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1384889lah.31 for ; Mon, 12 Nov 2012 13:12:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=F1z0iYoGb9ESIyZJrt7opClHlOG1FIwYT3kF/XvMjx4=; b=LwZnvabQhVuwMaIr2GIqCmJgiZX9PhOjVR9EH1M7tIE5lOu38YnHKKV6TczjI7b1Ox i/aZpzAnyYv+G8OMu9nffYMpqjWDscJTsCYOJpxtvjSgohX7xci9yyp+I0BaHo7Gsqgr 5QBRLC2DtxKx9YuJtTRtNYy6NLKeK+Nn2gmaPepjIDPAvTUxDX5rm60r58Pc+Hs4vJFY phnFmQKvyCey5veSK0NOjsyrEYx4c7kCbLHiwODz21PqRPIkdUC5wUSs2TZfxOVjxD8Y 9kjU931B3D3NPO+XP6Ku0W8jx0VhXoeQvhj23Gx87YbTqUOvcxcia8XUsQkEdSVkAPE6 g2tA== Received: by 10.152.123.103 with SMTP id lz7mr19239961lab.21.1352754763237; Mon, 12 Nov 2012 13:12:43 -0800 (PST) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPS id pw17sm2980549lab.5.2012.11.12.13.12.41 (version=SSLv3 cipher=OTHER); Mon, 12 Nov 2012 13:12:42 -0800 (PST) Message-ID: <50A16648.1030604@mnt.se> Date: Mon, 12 Nov 2012 22:12:40 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Phil Hunt References: <509BD776.3090106@mnt.se> <7EF786E1-18E2-4974-A6BC-2C72BE9F5C11@oracle.com> In-Reply-To: <7EF786E1-18E2-4974-A6BC-2C72BE9F5C11@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlkz5cPzgcVbRPySAn2iBwBQHR4Fluo3ogaapykLrAn4TrDk6n0fQsDLixWUCbQu4fE9cF0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac" discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:12:45 -0000 On 11/12/2012 10:09 PM, Phil Hunt wrote: > Leif, > > I've read this a couple of times and I think I'm getting lost in > partial SAML vs. OAuth terminology. As a result, I thought you were > saying: > > 1. It isn't practical to issue client credentials even with Dynamic > Registration > 2. You want to re-use key management already in place with OAuth2. > > These statements seem to be in conflict. Did you mean to say for > number 2 that you want to re-use key management already in place for SAML? > yep - "for" as in "for use by" From hannes.tschofenig@gmx.net Tue Nov 13 07:19:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949AF21F86E3 for ; Tue, 13 Nov 2012 07:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfavWSebpqkm for ; Tue, 13 Nov 2012 07:19:46 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6E3DC21F86A9 for ; Tue, 13 Nov 2012 07:19:43 -0800 (PST) Received: (qmail invoked by alias); 13 Nov 2012 15:19:25 -0000 Received: from 70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net (EHLO [192.168.2.103]) [70.91.193.41] by mail.gmx.net (mp041) with SMTP; 13 Nov 2012 16:19:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+IR4UJwFqIu5K49D1D63oGwnpQvfH2l65XZUCght yWc3rWbZCsrc+t From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Nov 2012 10:19:24 -0500 Message-Id: <9ABA26C3-1B06-4D15-9268-5F75B20E941D@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Review Volunteers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:19:48 -0000 We collected a number of action items last week. Here is my list 1. Token Revocation ACTION: Torsten to publish a draft update this week.=20 ACTION: Volunteers to review the draft: - Amanda=20 - Justin - Tony 2. draft-ietf-oauth-jwt-bearer ACTION: Justin to review JWT Bearer Token Profiles 3. OAuth Use Cases=20 ACTION: Tony to work with Zachary on building out use cases and = clarifying the audience of the doc. 4. JWT ACTION: Jeff Hodges, Klaas, and Leif to review the draft. 5. Security http://datatracker.ietf.org/doc/draft-tschofenig-oauth-security/ ACTION: working group to provide feedback on the requirements.=20 6. Dynamic Client Registration=20 ACTION: Hannes to ask UMA folks to review the doc.=20 ACTION: Nat, John, Torsten to review the doc.=20 From hannes.tschofenig@gmx.net Tue Nov 13 07:50:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744DE21F8744 for ; Tue, 13 Nov 2012 07:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqmmtoK9Gag9 for ; Tue, 13 Nov 2012 07:50:32 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 763CB21F8555 for ; Tue, 13 Nov 2012 07:50:30 -0800 (PST) Received: (qmail invoked by alias); 13 Nov 2012 15:50:27 -0000 Received: from 70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net (EHLO [192.168.2.103]) [70.91.193.41] by mail.gmx.net (mp024) with SMTP; 13 Nov 2012 16:50:27 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18SAmAPPucSTkcBCsqwpkeVpwteH8QwrGTqN1Oj/O k1K0wm5aMDtu6k From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 13 Nov 2012 10:40:21 -0500 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:50:36 -0000 Hi all, please have a look at the meeting minutes from last week: http://www.ietf.org/proceedings/85/minutes/minutes-85-oauth Thanks to Amanda & Jean for taking notes. Ciao Hannes & Derek From nichole.richardson.27@facebook.com Tue Nov 13 14:31:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B108821F8470 for ; Tue, 13 Nov 2012 14:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.16 X-Spam-Level: X-Spam-Status: No, score=-100.16 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiZ9CtIjQIar for ; Tue, 13 Nov 2012 14:31:18 -0800 (PST) Received: from smtpout.mx.facebook.com (unknown [69.171.244.69]) by ietfa.amsl.com (Postfix) with ESMTP id 285CA21F846C for ; Tue, 13 Nov 2012 14:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=facebook.com; s=s1024-2010-q3; c=relaxed/simple; q=dns/txt; i=@facebook.com; t=1352845871; h=From:Subject:X-:Date:To:MIME-Version:Content-Type; bh=D0Pl70kYvmKUbDZikcJw9pPNTGA4oxSwW+5rc1YIHC8=; b=TC1SW2sorEjMSO2VVtZGYLl4MaAr4nDPHgKbZnYloKnxjBpdt1/Dn+YyBM3n75Sn pqml4TMUttyCA2HQs/xwg4F2tZCG+RvyrZGSCXov+8oqY8Q0SlUzNrx28I8jNcaE qcxJedVUwqmnQTxwyIycWzpH+XSRX7E0TWs+mRALl2c=; Received: from [10.148.86.69] ([10.148.86.69:42288] helo=www.facebook.com) by 10.148.129.23 (envelope-from ) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id 6A/03-14058-F2AC2A05; Tue, 13 Nov 2012 14:31:11 -0800 Date: Tue, 13 Nov 2012 14:31:11 -0800 From: Nichole Richardson To: , Message-ID: In-Reply-To: References: , MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_568_319162522.1352845871491" Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 22:31:19 -0000 ------=_Part_568_319162522.1352845871491 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit get mime On November 13, 2012 12:00:08 PM PST, oauth-request@ietf.org wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/oauth > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: bag-of-keys metadata UC for the "mac" discussion (Phil Hunt) > 2. Re: bag-of-keys metadata UC for the "mac" discussion > (Leif Johansson) > 3. Review Volunteers (Hannes Tschofenig) > 4. Meeting Minutes (Hannes Tschofenig) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 12 Nov 2012 13:09:11 -0800 > From: Phil Hunt > To: Leif Johansson > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac" > discussion > Message-ID: <7EF786E1-18E2-4974-A6BC-2C72BE9F5C11@oracle.com> > Content-Type: text/plain; charset="iso-8859-1" > > Leif, > > I've read this a couple of times and I think I'm getting lost in partial SAML vs. OAuth terminology. As a result, I thought you were saying: > > 1. It isn't practical to issue client credentials even with Dynamic Registration > 2. You want to re-use key management already in place with OAuth2. > > These statements seem to be in conflict. Did you mean to say for number 2 that you want to re-use key management already in place for SAML? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-11-08, at 8:01 AM, Leif Johansson wrote: > > > I promised to send a UC to the list as input to the discussion around new > > token formats. > > > > --- > > > > Several large-scale deployments of public-key use a "bag-of-keys" model > > for key management: you stick endpoint information together with public > > keys for those endpoints in a signable container which is then signed with > > a private key associated with some "trust provider" an distributed to all > > entities/relying parties. > > > > Examples include various trust status lists formats and things like SAML > > metadata. > > > > The latter case (SAML metadata) isn't necessarily tied to the SAML v2 > > _protocol_ but it is used for that. Large-scale SAML federations are often > > setup to depend on distribution of signed SAML metadata. > > > > Consider the case when a large number of relying parties of such a SAML > > federation are also either OAUTH2 resource or authorization servers. Today > > all of those OAUTH2 entities have to be provisioned with separate client > > secrets that have no relationship to the trust infrastructure already in use > > in the federation. > > > > It is not uncommon for such federations to have 1000s and sometimes > > 10000s of entities making client secret management something of a > > scalability issue. > > > > Even with dynreg the problem of managing all of those client secrets > > would still remain a *huge* (operational) security and scalability issue. > > > > There is therefore a desire among communities that have such deployments > > to be able to re-use the key-management already in place for OAUTH2. > > > > Note that this example isn't tied to the SAML protocol at all. > > > > Leif > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Mon, 12 Nov 2012 22:12:40 +0100 > From: Leif Johansson > To: Phil Hunt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac" > discussion > Message-ID: <50A16648.1030604@mnt.se> > Content-Type: text/plain; charset=ISO-8859-1 > > On 11/12/2012 10:09 PM, Phil Hunt wrote: > > Leif, > > > > I've read this a couple of times and I think I'm getting lost in > > partial SAML vs. OAuth terminology. As a result, I thought you were > > saying: > > > > 1. It isn't practical to issue client credentials even with Dynamic > > Registration > > 2. You want to re-use key management already in place with OAuth2. > > > > These statements seem to be in conflict. Did you mean to say for > > number 2 that you want to re-use key management already in place for SAML? > > > yep - "for" as in "for use by" > > > ------------------------------ > > Message: 3 > Date: Tue, 13 Nov 2012 10:19:24 -0500 > From: Hannes Tschofenig > To: "oauth@ietf.org WG" > Subject: [OAUTH-WG] Review Volunteers > Message-ID: <9ABA26C3-1B06-4D15-9268-5F75B20E941D@gmx.net> > Content-Type: text/plain; charset=us-ascii > > We collected a number of action items last week. Here is my list > > 1. Token Revocation > > ACTION: Torsten to publish a draft update this week. > > ACTION: Volunteers to review the draft: > - Amanda > - Justin > - Tony > > 2. draft-ietf-oauth-jwt-bearer > > ACTION: Justin to review JWT Bearer Token Profiles > > 3. OAuth Use Cases > > ACTION: Tony to work with Zachary on building out use cases and clarifying the audience of the doc. > > 4. JWT > > ACTION: Jeff Hodges, Klaas, and Leif to review the draft. > > 5. Security > > http://datatracker.ietf.org/doc/draft-tschofenig-oauth-security/ > > ACTION: working group to provide feedback on the requirements. > > 6. Dynamic Client Registration > > ACTION: Hannes to ask UMA folks to review the doc. > ACTION: Nat, John, Torsten to review the doc. > > > > > > ------------------------------ > > Message: 4 > Date: Tue, 13 Nov 2012 10:40:21 -0500 > From: Hannes Tschofenig > To: "oauth@ietf.org WG" > Subject: [OAUTH-WG] Meeting Minutes > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Hi all, > > please have a look at the meeting minutes from last week: > http://www.ietf.org/proceedings/85/minutes/minutes-85-oauth > > Thanks to Amanda & Jean for taking notes. > > Ciao > Hannes & Derek > > > > ------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > End of OAuth Digest, Vol 49, Issue 11 > ************************************* ------=_Part_568_319162522.1352845871491 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable get mime

On November 13, 2012 12:00:08 PM PST, oauth-request@= ietf.org wrote:

If you have received this digest without = all the individual message
attachments you will need to= update your digest options in your list
subscription. =  To do so, go to

https://www.= ietf.org/mailman/listinfo/oauth

Click the 'Unsubscribe or edit options' button, log in, and set "Get=
MIME or Plain Text Digests?" to MIME.  You c= an set this option
globally for all the list digests yo= u receive at this point.



Send OAuth mailing list submissions to
=09oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, = via email, send a message with subject or body 'help' to
=09oauth-request@ietf.org

You ca= n reach the person managing the list at
=09oauth-owner@= ietf.org

When replying, please edi= t your Subject line so it is more specific
than "R= e: Contents of OAuth digest..."


Today's Topics:

  1. Re: bag-of-keys metadata UC for the "mac" discus= sion (Phil Hunt)
  2. Re: bag-of-keys metadata UC= for the "mac" discussion
    &nbs= p;(Leif Johansson)
  3. Review Volunteers (Hannes= Tschofenig)
  4. Meeting Minutes (Hannes Tschofe= nig)


--------= --------------------------------------------------------------

Message: 1
Date: Mon, 12 N= ov 2012 13:09:11 -0800
From: Phil Hunt <phil.hunt@or= acle.com>
To: Leif Johansson <leifj@mnt.se>Cc: oauth@ietf.org
Subject: Re: [OAUT= H-WG] bag-of-keys metadata UC for the "mac"
= =09discussion
Message-ID: <7EF786E1-18E2-4974-A6BC-2= C72BE9F5C11@oracle.com>
Content-Type: text/plain; ch= arset=3D"iso-8859-1"

Lei= f,

I've read this a couple of time= s and I think I'm getting lost in partial SAML vs. OAuth terminology. As a = result, I thought you were saying:

1. It isn't practical to issue client credentials even with Dynamic Regist= ration
2. You want to re-use key management already in = place with OAuth2.

These statement= s seem to be in conflict.  Did you mean to say for number 2 that you w= ant to re-use key management already in place for SAML?

Phil

@indepe= ndentid
www.independentid.com
phil.= hunt@oracle.com





On 2012-1= 1-08, at 8:01 AM, Leif Johansson wrote:

> I promised to send a UC to the list as input to the discussion a= round new
> token formats.
> =
> ---
>
> Several large-scale deployments of public-key use a "bag-of-keys= " model
> for key management: you stick endpoin= t information together with public
> keys for those = endpoints in a signable container which is then signed with
> a private key associated with some "trust provider" an = distributed to all
> entities/relying parties.
>
> Examples include various trus= t status lists formats and things like SAML
> metada= ta.
>
> The latter case (SAM= L metadata) isn't necessarily tied to the SAML v2
> = _protocol_ but it is used for that. Large-scale SAML federations are often<= br clear=3D'none' />> setup to depend on distribution of signed SAML met= adata.
>
> Consider the case= when a large number of relying parties of such a SAML
= > federation are also either OAUTH2 resource or authorization servers. T= oday
> all of those OAUTH2 entities have to be provi= sioned with separate client
> secrets that have no r= elationship to the trust infrastructure already in use
= > in the federation.
>
> = It is not uncommon for such federations to have 1000s and sometimes
> 10000s of entities making client secret management someth= ing of a
> scalability issue.
&g= t;
> Even with dynreg the problem of managing all o= f those client secrets
> would still remain a *huge*= (operational) security and scalability issue.
> > There is therefore a desire among communities that h= ave such deployments
> to be able to re-use the key-= management already in place for OAUTH2.
>
> Note that this example isn't tied to the SAML protocol at = all.
>
>      = ;   Leif
> ____________________________________= ___________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/l= istinfo/oauth

-------------- n= ext part --------------
An HTML attachment was scrubbed= ...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20121112/ede07590/a= ttachment.htm>

------------= ------------------

Message: 2
Date: Mon, 12 Nov 2012 22:12:40 +0100
F= rom: Leif Johansson <leifj@mnt.se>
To: Phil Hunt = <phil.hunt@oracle.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "= mac"
=09discussion
Message-ID:= <50A16648.1030604@mnt.se>
Content-Type: text/pla= in; charset=3DISO-8859-1

On 11/12/= 2012 10:09 PM, Phil Hunt wrote:
> Leif,
>
> I've read this a couple of times and = I think I'm getting lost in
> partial SAML vs. OAuth= terminology. As a result, I thought you were
> sayi= ng:
>
> 1. It isn't practical= to issue client credentials even with Dynamic
> Reg= istration
> 2. You want to re-use key management alr= eady in place with OAuth2.
>
>= ; These statements seem to be in conflict.  Did you mean to say for> number 2 that you want to re-use key management alre= ady in place for SAML?
>
yep - &= quot;for" as in "for use by"


------------------------------

Message: 3
Date: Tue, 13 = Nov 2012 10:19:24 -0500
From: Hannes Tschofenig <han= nes.tschofenig@gmx.net>
To: "oauth@ietf.org WG&= quot; <oauth@ietf.org>
Subject: [OAUTH-WG] Review= Volunteers
Message-ID: <9ABA26C3-1B06-4D15-9268-5F7= 5B20E941D@gmx.net>
Content-Type: text/plain; charset= =3Dus-ascii

We collected a number = of action items last week. Here is my list

1. Token Revocation

ACTIO= N: Torsten to publish a draft update this week.

ACTION: Volunteers to review the draft:
= - Amanda
- Justin
- Tony

2. draft-ietf-oauth-jwt-bearer

ACTION: Justin to review JWT Bearer Token Pro= files

3. OAuth Use Cases

ACTION: Tony to work with Zachary on build= ing out use cases and clarifying the audience of the doc.

4. JWT

ACT= ION: Jeff Hodges, Klaas, and Leif to review the draft.
=
5. Security

<= a href=3D'http://datatracker.ietf.org/doc/draft-tschofenig-oauth-security/'= target=3D'_blank'>http://datatracker.ietf.org/doc/draft-tschofenig-oauth-s= ecurity/

ACTION: working group= to provide feedback on the requirements.

6. Dynamic Client Registration

ACTION: Hannes to ask UMA folks to review the doc.
ACTION: Nat, John, Torsten to review the doc.





------------------------------

Message: 4
Date: Tue, 13 Nov 201= 2 10:40:21 -0500
From: Hannes Tschofenig <hannes.tsc= hofenig@gmx.net>
To: "oauth@ietf.org WG" &= lt;oauth@ietf.org>
Subject: [OAUTH-WG] Meeting Minut= es
Message-ID: <F640899A-B4E4-40B4-B961-64199C600AAD= @gmx.net>
Content-Type: text/plain; charset=3Dus-asc= ii

Hi all,
please have a look at the meeting minutes from last week= :
http://www.ietf.org/proceedings/85/min= utes/minutes-85-oauth

Thanks t= o Amanda & Jean for taking notes.

Ciao
Hannes & Derek



------------------= ------------

_____________________= __________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/= listinfo/oauth


End of OAuth Digest, Vol 49, Issue 11
***********= **************************
------=_Part_568_319162522.1352845871491-- From michael_b_jones@hotmail.com Tue Nov 13 15:33:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DB321F8691; Tue, 13 Nov 2012 15:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntI5ZIMOsIXx; Tue, 13 Nov 2012 15:33:26 -0800 (PST) Received: from bay0-omc1-s25.bay0.hotmail.com (bay0-omc1-s25.bay0.hotmail.com [65.54.190.36]) by ietfa.amsl.com (Postfix) with ESMTP id D57B521F868F; Tue, 13 Nov 2012 15:33:26 -0800 (PST) Received: from BAY171-W47 ([65.54.190.60]) by bay0-omc1-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Nov 2012 15:33:26 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_2df8537d-c1b1-4a26-b683-96413d67d4ed_" X-Originating-IP: [174.7.255.77] From: Michael Jones To: , , Date: Tue, 13 Nov 2012 15:33:26 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 13 Nov 2012 23:33:26.0611 (UTC) FILETIME=[479C2230:01CDC1F7] Cc: cfrg@irtf.org Subject: [OAUTH-WG] Vacationing this week & e-mail address X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:33:27 -0000 --_2df8537d-c1b1-4a26-b683-96413d67d4ed_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all=2C I wanted to let you know that I'm vacationing this week=2C and so= mostly won't be participating in discussions. I'll respond next week. Als= o=2C at present I=92m using the e-mail address michael_b_jones@hotmail.com to send e-mail to IETF mailing lists because currently I=92m unable to send= e-mail to any IETF lists using my normal e-mail address Michael.Jones@microsoft.com.=20 When corresponding with me individually=2C it would be better to use the Microsoft address=2C as the message is likely to be seen more quickly. Have= a good week=2C everyone! -- Mike=20 = --_2df8537d-c1b1-4a26-b683-96413d67d4ed_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all=2C
 =3B
I wanted to let you know that I'm vacationing this= week=2C and so mostly won't be participating in discussions. =3B I'll = respond next week.
&nbs= p=3B

Also=2C at present I=92m using the e-ma= il address michael_b_jones@hotmail.com to send e-mail to IETF mailing lists because currently I=92m unable to send= e-mail to any IETF lists using my normal e-mail address Michael.Jones@microsoft.com. =3B When corresponding with me individually=2C it would be better to use the Microsoft address=2C as the message is likely to be seen more quickly.

 =3B
Have a good week=2C everyone!
 =3B
-- Mike
 =3B


= --_2df8537d-c1b1-4a26-b683-96413d67d4ed_-- From dgq2011@gmail.com Wed Nov 14 06:51:39 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6777A21F8518 for ; Wed, 14 Nov 2012 06:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.489 X-Spam-Level: **** X-Spam-Status: No, score=4.489 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bfnuJoMDzBs for ; Wed, 14 Nov 2012 06:51:37 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE7F21F8500 for ; Wed, 14 Nov 2012 06:51:34 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so424739pbc.31 for ; Wed, 14 Nov 2012 06:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:x-priority:x-has-attach:x-mailer :mime-version:message-id:content-type; bh=fyeCOkn6zBiIs7bFRuq03EZp1KD5BTrTAMzACLn3eNE=; b=XtqLIaugM2flPs7xSXT0LrEqXuVUX0jSiv/BHfuMDM7UCmsO68OpwnxFYdYz9Mpx6S Z4OHzZ5928mRW9XPHSQS8otDYomcNJiKyN03/D3TS8+vcwJDiYDCJeVe955PwbHu31Lv reeo+1uHyMAkgZcvrckGUWyctC7j1g1K3FEm0glwqWFNBa1MhTycWoszSSdtaA4V34EL 1kuNo6lieMXzsmWOpe8ZmLjErrMIteuhkPWGpkSn6q6LG8xEbZ2ghyfKW+nM5cFdj61m wcMFdAsPLtJ+Jwh9RzcsxU9tu6NGpSqPMUE3ceSzeRGGj/+5AoWhzyGQTaHcIqTSwqwm xj0w== Received: by 10.66.84.196 with SMTP id b4mr7130630paz.41.1352904694598; Wed, 14 Nov 2012 06:51:34 -0800 (PST) Received: from dgq-PC ([123.116.133.116]) by mx.google.com with ESMTPS id wf8sm7835423pbc.65.2012.11.14.06.51.24 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 06:51:30 -0800 (PST) Date: Wed, 14 Nov 2012 22:51:27 +0800 From: dgq2011 To: "oauth@ietf.org" X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201211142251220430822@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart573203012282_=----" Subject: [OAUTH-WG] =?gb2312?b?aXMgT0F1dGggcHJvdG9jb2wgYmFzZWQgb24gSFRU?= =?gb2312?b?UKO/?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dgq2011 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 14:51:39 -0000 This is a multi-part message in MIME format. ------=_001_NextPart573203012282_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIGFsbCEgSXQgaXMgc2FpZCBpbiBSRkMgNjc0OSAoVGhlIE9BdXRoIDIuMCBBdXRob3JpemF0 aW9uIEZyYW1ld29yaykgdGhhdCChsHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBkZXNpZ25lZCBmb3Ig dXNlIHdpdGggSFRUUCAoW1JGQzI2MTZdKaGxIGFuZCChsFRoZSB1c2Ugb2YgT0F1dGggb3ZlciBh bnkgcHJvdG9jb2wgb3RoZXIgdGhhbiBIVFRQIGlzIG91dCBvZiBzY29wZS6hsSBEbyB0aG9zZSBz dGF0ZW1lbnRzIG1lYW4gdGhhdCB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGFueSB0d28gcm9s ZXMgaW4gT0F1dGggcHJvdG9jb2wgKG5hbWVseSByZXNvdXJjZSBvd25lciwgcmVzb3VyY2Ugc2Vy dmVyLCBjbGllbnQgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyKSBpcyBiYXNlZCBvbiBIVFRQIHBy b3RvY29sPyBJIGFtIG5vdCBmYW1pbGlhciB3aXRoIHRoZSBPQXV0aCBwcm90b2NvbCBhbmQganVz dCB3b3VsZCBsaWtlIHRvIGNvbmZpcm0gdGhpcyBxdWVzdGlvbi4gQW55IHJlc3BvbnNlIGlzIGFw cHJlY2lhdGVkIQ0KDQoNCkJlc3Qgd2lzaGVzo6ENCkd1YW5ncWluZyBEZW5nDQoNCg0KDQpkZ3Ey MDEx ------=_001_NextPart573203012282_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, all! It is said in RFC 6749 (The OAuth 2.0 Authorizatio= n=20 Framework) that =A1=B0this specification is designed for use with HTTP ([R= FC2616])=A1=B1=20 and =A1=B0The use of OAuth over any protocol other than HTTP is out of sco= pe.=A1=B1 Do=20 those statements mean that the communication between any two roles in OAut= h=20 protocol (namely resource owner, resource server, client and authorization= =20 server) is based on HTTP protocol? I am not familiar with the OAuth protoc= ol=20 and just would like to confirm this question. Any response is=20 appreciated!

 
 
Best wishes=A3=A1
Guangqing Deng
dgq2011
------=_001_NextPart573203012282_=------ From jricher@mitre.org Wed Nov 14 07:04:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EEF21F85EA for ; Wed, 14 Nov 2012 07:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWAxm0ALcCXP for ; Wed, 14 Nov 2012 07:04:11 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2F69821F85A2 for ; Wed, 14 Nov 2012 07:04:11 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 523A45310418; Wed, 14 Nov 2012 10:04:10 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4108A5310409; Wed, 14 Nov 2012 10:04:10 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 14 Nov 2012 10:04:09 -0500 Message-ID: <50A3B2A0.4000107@mitre.org> Date: Wed, 14 Nov 2012 10:02:56 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: dgq2011 References: <201211142251220430822@gmail.com> In-Reply-To: <201211142251220430822@gmail.com> Content-Type: multipart/alternative; boundary="------------070107090300000705010200" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] =?utf-8?q?is_OAuth_protocol_based_on_HTTP=EF=BC=9F?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 15:04:12 -0000 --------------070107090300000705010200 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit That's correct, the OAuth protocol is only defined over HTTP. This constitutes the overwhelming majority of use cases, and the specifics of HTTP operation are central to the assumptions made in OAuth's design. While it's plausible that the interactions between the parties could take place over some other protocol, this is outside the scope of the core definition, and such use is considered an extension. For instance, there's a method for presenting an OAuth bearer token over SASL: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth This extension doesn't define a method of getting a token, but it does define a method of presenting a token over a non-HTTP protocol. Hope this helps, -- Justin On 11/14/2012 09:51 AM, dgq2011 wrote: > > Hi, all! It is said in RFC 6749 (The OAuth 2.0 Authorization > Framework) that “this specification is designed for use with HTTP > ([RFC2616])†and “The use of OAuth over any protocol other than HTTP > is out of scope.†Do those statements mean that the communication > between any two roles in OAuth protocol (namely resource owner, > resource server, client and authorization server) is based on HTTP > protocol? I am not familiar with the OAuth protocol and just would > like to confirm this question. Any response is appreciated! > > Best wishesï¼ > Guangqing Deng > ------------------------------------------------------------------------ > dgq2011 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------070107090300000705010200 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
That's correct, the OAuth protocol is only defined over HTTP. This constitutes the overwhelming majority of use cases, and the specifics of HTTP operation are central to the assumptions made in OAuth's design. While it's plausible that the interactions between the parties could take place over some other protocol, this is outside the scope of the core definition, and such use is considered an extension. For instance, there's a method for presenting an OAuth bearer token over SASL:

  http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth

This extension doesn't define a method of getting a token, but it does define a method of presenting a token over a non-HTTP protocol.

Hope this helps,
 -- Justin

On 11/14/2012 09:51 AM, dgq2011 wrote:

Hi, all! It is said in RFC 6749 (The OAuth 2.0 Authorization Framework) that “this specification is designed for use with HTTP ([RFC2616])†and “The use of OAuth over any protocol other than HTTP is out of scope.†Do those statements mean that the communication between any two roles in OAuth protocol (namely resource owner, resource server, client and authorization server) is based on HTTP protocol? I am not familiar with the OAuth protocol and just would like to confirm this question. Any response is appreciated!

 
 
Best wishesï¼
Guangqing Deng
dgq2011


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------070107090300000705010200-- From hannes.tschofenig@gmx.net Wed Nov 14 07:10:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E208E21F8546 for ; Wed, 14 Nov 2012 07:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZtQZWhO2-Ty for ; Wed, 14 Nov 2012 07:10:34 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D8ADD21F84EA for ; Wed, 14 Nov 2012 07:10:33 -0800 (PST) Received: (qmail invoked by alias); 14 Nov 2012 15:09:58 -0000 Received: from 31-33-236.wireless.csail.mit.edu (EHLO 31-33-236.wireless.csail.mit.edu) [128.31.33.236] by mail.gmx.net (mp016) with SMTP; 14 Nov 2012 16:09:58 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19U/VYsXQVU6fjB/YZuToxFUZoYkmzEZNPi+CoQer IkKz0CwmRNQieG Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=GB2312 From: Hannes Tschofenig X-Priority: 3 In-Reply-To: <201211142251220430822@gmail.com> Date: Wed, 14 Nov 2012 10:09:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4638B09A-9FD6-4F4C-B83D-C56BBDE521C6@gmx.net> References: <201211142251220430822@gmail.com> To: dgq2011 X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] =?utf-8?q?is_OAuth_protocol_based_on_HTTP=EF=BC=9F?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 15:10:35 -0000 Hi Guangqing,=20 RFC 6749 should have explained this a bit more.=20 RFC 6749 uses HTTPS to interact with an authorization server to obtain = access tokens (among other things). RFC 4749 does, however, not specify = what protocol is used to present these access tokens to a resource = server. RFC 6750 explains how this is done for resource servers that use = HTTP. There is, however, also ongoing work to provide OAuth support for = non-HTTP-based protocol, see = http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-08. SASL and the = GSS-API is used for integrating OAuth into a range of protocols.=20 Ciao Hannes On Nov 14, 2012, at 9:51 AM, dgq2011 wrote: > Hi, all! It is said in RFC 6749 (The OAuth 2.0 Authorization = Framework) that =A1=B0this specification is designed for use with HTTP = ([RFC2616])=A1=B1 and =A1=B0The use of OAuth over any protocol other = than HTTP is out of scope.=A1=B1 Do those statements mean that the = communication between any two roles in OAuth protocol (namely resource = owner, resource server, client and authorization server) is based on = HTTP protocol? I am not familiar with the OAuth protocol and just would = like to confirm this question. Any response is appreciated! > =20 > =20 > Best wishes=A3=A1 > Guangqing Deng > dgq2011 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Adam.Lewis@motorolasolutions.com Wed Nov 14 07:20:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6986821F8417 for ; Wed, 14 Nov 2012 07:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.169 X-Spam-Level: X-Spam-Status: No, score=0.169 tagged_above=-999 required=5 tests=[AWL=-1.835, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_ISO2022JP=0.413, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnQyprFtWKrZ for ; Wed, 14 Nov 2012 07:20:08 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 559AF21F8202 for ; Wed, 14 Nov 2012 07:20:08 -0800 (PST) Received: from mail207-co9-R.bigfish.com (10.236.132.232) by CO9EHSOBE019.bigfish.com (10.236.130.82) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Nov 2012 15:20:07 +0000 Received: from mail207-co9 (localhost [127.0.0.1]) by mail207-co9-R.bigfish.com (Postfix) with ESMTP id 203636601C8 for ; Wed, 14 Nov 2012 15:20:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.160.210.20; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg01.am.mot-solutions.com; RD:ct11msg01.mot-solutions.com; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(z3e0fhz98dI9371Id6eah542M1432Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275dhz2fh2a8h683h839h945hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received-SPF: pass (mail207-co9: domain of motorolasolutions.com designates 192.160.210.20 as permitted sender) client-ip=192.160.210.20; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg01.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT003.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail207-co9 (localhost.localdomain [127.0.0.1]) by mail207-co9 (MessageSwitch) id 1352906400405873_20353; Wed, 14 Nov 2012 15:20:00 +0000 (UTC) Received: from CO9EHSMHS003.bigfish.com (unknown [10.236.132.226]) by mail207-co9.bigfish.com (Postfix) with ESMTP id 57BC094004C for ; Wed, 14 Nov 2012 15:20:00 +0000 (UTC) Received: from ct11msg01.am.mot-solutions.com (192.160.210.20) by CO9EHSMHS003.bigfish.com (10.236.130.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Nov 2012 15:19:58 +0000 Received: from ct11msg01.am.mot-solutions.com (ct11vts02.am.mot.com [10.177.16.160]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id qAEFdqhC009552 for ; Wed, 14 Nov 2012 09:39:52 -0600 (CST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id qAEFdp7Z009546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 14 Nov 2012 09:39:52 -0600 (CST) Received: from mail67-db3-R.bigfish.com (10.3.81.235) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Nov 2012 15:19:55 +0000 Received: from mail67-db3 (localhost [127.0.0.1]) by mail67-db3-R.bigfish.com (Postfix) with ESMTP id 8A1441200C4 for ; Wed, 14 Nov 2012 15:19:55 +0000 (UTC) Received: from mail67-db3 (localhost.localdomain [127.0.0.1]) by mail67-db3 (MessageSwitch) id 1352906393656056_16207; Wed, 14 Nov 2012 15:19:53 +0000 (UTC) Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.245]) by mail67-db3.bigfish.com (Postfix) with ESMTP id 946203C0050; Wed, 14 Nov 2012 15:19:53 +0000 (UTC) Received: from BY2PRD0411HT003.namprd04.prod.outlook.com (157.56.237.133) by DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Nov 2012 15:19:52 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.123]) by BY2PRD0411HT003.namprd04.prod.outlook.com ([10.255.128.38]) with mapi id 14.16.0233.002; Wed, 14 Nov 2012 15:19:52 +0000 From: Lewis Adam-CAL022 To: Hannes Tschofenig , dgq2011 Thread-Topic: =?iso-2022-jp?B?W09BVVRILVdHXSBpcyBPQXV0aCBwcm90b2NvbCBiYXNlZCBvbiBIVFRQ?= =?iso-2022-jp?B?GyRCISkbKEI=?= Thread-Index: AQHNwnpWsjd95Cg7VkO+SqcFevU8I5fpcHJQ Date: Wed, 14 Nov 2012 15:19:51 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A92F18F307@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <201211142251220430822@gmail.com> <4638B09A-9FD6-4F4C-B83D-C56BBDE521C6@gmx.net> In-Reply-To: <4638B09A-9FD6-4F4C-B83D-C56BBDE521C6@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [184.78.105.93] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMX.NET$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMAIL.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] =?iso-2022-jp?b?aXMgT0F1dGggcHJvdG9jb2wgYmFzZWQgb24g?= =?iso-2022-jp?b?SFRUUBskQiEpGyhC?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 15:20:10 -0000 Hi Guangqing, Just to build on what Justin and Hannes said, I have use cases that involve= sending OAuth access tokens over MANY non-HTTP protocols including SIP, RT= SP, SOAP (though you could argue that it is HTTP underneath), and other pro= prietary protocols. (I also have use cases for the more conventional RESTfu= l API access as well.) The way my clients get the token (as Hannes mentione= d) is always done over HTTPS between the client and RS. =20 -adam -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Wednesday, November 14, 2012 9:10 AM To: dgq2011 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] is OAuth protocol based on HTTP=1B$B!)=1B(B Hi Guangqing,=20 RFC 6749 should have explained this a bit more.=20 RFC 6749 uses HTTPS to interact with an authorization server to obtain acce= ss tokens (among other things). RFC 4749 does, however, not specify what pr= otocol is used to present these access tokens to a resource server. RFC 675= 0 explains how this is done for resource servers that use HTTP. There is, h= owever, also ongoing work to provide OAuth support for non-HTTP-based proto= col, see http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-08. SASL a= nd the GSS-API is used for integrating OAuth into a range of protocols.=20 Ciao Hannes On Nov 14, 2012, at 9:51 AM, dgq2011 wrote: > Hi, all! It is said in RFC 6749 (The OAuth 2.0 Authorization Framework) t= hat =1B$B!H=1B(Bthis specification is designed for use with HTTP ([RFC2616]= )=1B$B!I=1B(B and =1B$B!H=1B(BThe use of OAuth over any protocol other than= HTTP is out of scope.=1B$B!I=1B(B Do those statements mean that the commun= ication between any two roles in OAuth protocol (namely resource owner, res= ource server, client and authorization server) is based on HTTP protocol? I= am not familiar with the OAuth protocol and just would like to confirm thi= s question. Any response is appreciated! > =20 > =20 > Best wishes=1B$B!*=1B(B > Guangqing Deng > dgq2011 > _______________________________________________ > 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 From security.developer22@gmail.com Thu Nov 15 12:03:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34FD21F842E for ; Thu, 15 Nov 2012 12:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdo+ZbjdbY8D for ; Thu, 15 Nov 2012 12:03:20 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EEE6721F842B for ; Thu, 15 Nov 2012 12:03:16 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so2291768vcb.31 for ; Thu, 15 Nov 2012 12:03:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yeYP7jCtBW4+rBixNwfEgaOz+xaQma+/eQScH5jGbj4=; b=s9yDXBiXhhX2x25pDDKKNlMF0IDFc9gWqYikU92KS98nGzw4NBf0iU/pIGLKrTh0Cl U+dPjxG9s6ry/C+JNBwydYj3c/bUnZpGMSNXNawWGuq7fYeQV9WDZl0XHyllqWEpZjp5 CJ5Zqn19vIBIfBEIt/wuT3xAZAJMgSdN0EtQShZ9yd+8rAHqHTiW2ap/adjrBrvDA4Su wis6LA27PFB2tYsuxxHuCp4AipnwQokuT7/fRYX5iMpO2L31kumyjerkTm+9ieCy0v7X dW2m/3j1b/RI2UMNDJCqdaajFSZ0TPu9URPiHOe75spc9/TvPi9vd12hoZLHlGaTakcJ TzWQ== MIME-Version: 1.0 Received: by 10.52.89.35 with SMTP id bl3mr2597377vdb.87.1353009796237; Thu, 15 Nov 2012 12:03:16 -0800 (PST) Received: by 10.221.12.81 with HTTP; Thu, 15 Nov 2012 12:03:16 -0800 (PST) Date: Fri, 16 Nov 2012 01:03:16 +0500 Message-ID: From: Security Developer To: OAuth@ietf.org Content-Type: multipart/alternative; boundary=20cf307d034e484b7c04ce8e2414 Subject: [OAUTH-WG] Question related to OAuth access token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:03:20 -0000 --20cf307d034e484b7c04ce8e2414 Content-Type: text/plain; charset=ISO-8859-1 Hi, If an access token is either SAML or JWT in OAuth then what would be the value in subject either resource owner or client application name? Thanks for your time. Regards, --20cf307d034e484b7c04ce8e2414 Content-Type: text/html; charset=ISO-8859-1 Hi,

If an access token is either SAML or JWT in OAuth then what would be the value in subject either resource owner or client application name?

Thanks for your time.

Regards,
--20cf307d034e484b7c04ce8e2414-- From nichole.richardson.27@facebook.com Sun Nov 18 05:26:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AC121F84C4 for ; Sun, 18 Nov 2012 05:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.212 X-Spam-Level: X-Spam-Status: No, score=-101.212 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7XWMgH8maVj for ; Sun, 18 Nov 2012 05:26:47 -0800 (PST) Received: from smtpout.mx.facebook.com (smtpout003.ash3.facebook.com [69.171.244.66]) by ietfa.amsl.com (Postfix) with ESMTP id A7E9021F8431 for ; Sun, 18 Nov 2012 05:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=facebook.com; s=s1024-2010-q3; c=relaxed/simple; q=dns/txt; i=@facebook.com; t=1353245200; h=From:Subject:X-:Date:To:MIME-Version:Content-Type; bh=99fjam1iaIpGNETZf8wU9tev8puqalZQDnsUk1W4MqQ=; b=m0rMhHuMHTOyG/rPXdTkZtmqr0oK0l6jQPhx6O5SWWI6AO9RZArJRTx5c9tR+qOa yzWmjTfD+kGHcnySmmWqhWLAn+hUXwTLJDKKGFdsWfQXlkScYuuS3dXnp0tKJeRY sMOfTuNiC2mPtKzrp5fVRTId0OkstSpm2I3umIyihBs=; Received: from [10.148.86.69] ([10.148.86.69:51471] helo=www.facebook.com) by 10.148.131.37 (envelope-from ) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id 1A/2D-18460-012E8A05; Sun, 18 Nov 2012 05:26:40 -0800 Date: Sun, 18 Nov 2012 05:26:40 -0800 From: Nichole Richardson To: , Message-ID: In-Reply-To: References: , MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7207_739200358.1353245200888" Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 14 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 13:26:48 -0000 ------=_Part_7207_739200358.1353245200888 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit help On November 16, 2012 12:00:14 PM PST, oauth-request@ietf.org wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/oauth > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Question related to OAuth access token (Security Developer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 16 Nov 2012 01:03:16 +0500 > From: Security Developer > To: OAuth@ietf.org > Subject: [OAUTH-WG] Question related to OAuth access token > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > If an access token is either SAML or JWT in OAuth then what would be the > value in subject either resource owner or client application name? > > Thanks for your time. > > Regards, > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > End of OAuth Digest, Vol 49, Issue 14 > ************************************* ------=_Part_7207_739200358.1353245200888 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable help

On November 16, 2012 12:00:14 PM PST, oauth-request@ietf= .org wrote:

If you have received this digest without all = the individual message
attachments you will need to upd= ate your digest options in your list
subscription. &nbs= p;To do so, go to

https://www.ietf= .org/mailman/listinfo/oauth

Cl= ick the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can s= et this option
globally for all the list digests you re= ceive at this point.



Send OAuth mailing list submissions to
=09oauth@ietf.org

To = subscribe or unsubscribe via the World Wide Web, visit
= h= ttps://www.ietf.org/mailman/listinfo/oauth
or, via = email, send a message with subject or body 'help' to
= =09oauth-request@ietf.org

You can = reach the person managing the list at
=09oauth-owner@ie= tf.org

When replying, please edit = your Subject line so it is more specific
than "Re:= Contents of OAuth digest..."


Today's Topics:

  1. Question related to OAuth access token (Security Developer)<= br clear=3D'none' />

-------------= ---------------------------------------------------------

Message: 1
Date: Fri, 16 Nov 20= 12 01:03:16 +0500
From: Security Developer <security= .developer22@gmail.com>
To: OAuth@ietf.org
Subject: [OAUTH-WG] Question related to OAuth access token
Message-ID:
=09<CAD-drXstwtoAtd=3Dvz= 43mOpLjNRTjisYWoYUOWuE3mdU_9r3n_A@mail.gmail.com>
Co= ntent-Type: text/plain; charset=3D"iso-8859-1"

Hi,

If an a= ccess token is either SAML or JWT in OAuth then what would be the
value in subject either resource owner or client application na= me?

Thanks for your time.

Regards,
-------------= - next part --------------
An HTML attachment was scrub= bed...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20121116/258a14c= 4/attachment.htm>

---------= ---------------------

____________= ___________________________________
OAuth mailing list<= br clear=3D'none' />OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


End of OAuth Digest, Vol 49, Issue 14
***= **********************************
------=_Part_7207_739200358.1353245200888-- From nichole.richardson.27@facebook.com Sun Nov 18 05:27:17 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6E321F84DA for ; Sun, 18 Nov 2012 05:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.446 X-Spam-Level: X-Spam-Status: No, score=-101.446 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1MBxn1UzPhs for ; Sun, 18 Nov 2012 05:27:16 -0800 (PST) Received: from smtpout.mx.facebook.com (smtpout004.ash3.facebook.com [69.171.244.67]) by ietfa.amsl.com (Postfix) with ESMTP id BE88821F84D3 for ; Sun, 18 Nov 2012 05:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=facebook.com; s=s1024-2010-q3; c=relaxed/simple; q=dns/txt; i=@facebook.com; t=1353245235; h=From:Subject:X-:Date:To:MIME-Version:Content-Type; bh=Alz4YnQJtZKn9Z7CcjhODt2Zu6ksJTR2IIt38QXskP8=; b=kBOWJkwdvSpLraQAYvqbBykzMv5q8Q6Bgz435K1FzD99YL3d7IsynrNsQ8Z6Wzdt G8GGKW2JGAmPZwZiE5tdbifJfD1ujSQByCRSdMhHQG0WVZMFsJhyNVNa3mO/Wr7m 6ETRVqYqkwtyH5PN1xTzlp4EvXy2uNmjQ/UQBsNSilU=; Received: from [10.148.86.69] ([10.148.86.69:51471] helo=www.facebook.com) by 10.148.131.37 (envelope-from ) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id A9/E5-18460-332E8A05; Sun, 18 Nov 2012 05:27:15 -0800 Date: Sun, 18 Nov 2012 05:27:15 -0800 From: Nichole Richardson To: , Message-ID: In-Reply-To: References: , MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7208_1850176399.1353245235341" Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 13:27:17 -0000 ------=_Part_7208_1850176399.1353245235341 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit help On November 14, 2012 6:51:40 AM PST, oauth-request@ietf.org wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/oauth > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: OAuth Digest, Vol 49, Issue 11 (Nichole Richardson) > 2. Vacationing this week & e-mail address (Michael Jones) > 3. is OAuth protocol based on HTTP? (dgq2011) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 13 Nov 2012 14:31:11 -0800 > From: Nichole Richardson > To: , > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 11 > Message-ID: > Content-Type: text/plain; charset="utf-8" > > get mime > > On November 13, 2012 12:00:08 PM PST, oauth-request@ietf.org wrote: > > If you have received this digest without all the individual message > > attachments you will need to update your digest options in your list > > subscription. To do so, go to > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > MIME or Plain Text Digests?" to MIME. You can set this option > > globally for all the list digests you receive at this point. > > > > > > > > Send OAuth mailing list submissions to > > oauth@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/oauth > > or, via email, send a message with subject or body 'help' to > > oauth-request@ietf.org > > > > You can reach the person managing the list at > > oauth-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of OAuth digest..." > > > > > > Today's Topics: > > > > 1. Re: bag-of-keys metadata UC for the "mac" discussion (Phil Hunt) > > 2. Re: bag-of-keys metadata UC for the "mac" discussion > > (Leif Johansson) > > 3. Review Volunteers (Hannes Tschofenig) > > 4. Meeting Minutes (Hannes Tschofenig) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 12 Nov 2012 13:09:11 -0800 > > From: Phil Hunt > > To: Leif Johansson > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac" > > discussion > > Message-ID: <7EF786E1-18E2-4974-A6BC-2C72BE9F5C11@oracle.com> > > Content-Type: text/plain; charset="iso-8859-1" > > > > Leif, > > > > I've read this a couple of times and I think I'm getting lost in partial SAML vs. OAuth terminology. As a result, I thought you were saying: > > > > 1. It isn't practical to issue client credentials even with Dynamic Registration > > 2. You want to re-use key management already in place with OAuth2. > > > > These statements seem to be in conflict. Did you mean to say for number 2 that you want to re-use key management already in place for SAML? > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > > > On 2012-11-08, at 8:01 AM, Leif Johansson wrote: > > > > > I promised to send a UC to the list as input to the discussion around new > > > token formats. > > > > > > --- > > > > > > Several large-scale deployments of public-key use a "bag-of-keys" model > > > for key management: you stick endpoint information together with public > > > keys for those endpoints in a signable container which is then signed with > > > a private key associated with some "trust provider" an distributed to all > > > entities/relying parties. > > > > > > Examples include various trust status lists formats and things like SAML > > > metadata. > > > > > > The latter case (SAML metadata) isn't necessarily tied to the SAML v2 > > > _protocol_ but it is used for that. Large-scale SAML federations are often > > > setup to depend on distribution of signed SAML metadata. > > > > > > Consider the case when a large number of relying parties of such a SAML > > > federation are also either OAUTH2 resource or authorization servers. Today > > > all of those OAUTH2 entities have to be provisioned with separate client > > > secrets that have no relationship to the trust infrastructure already in use > > > in the federation. > > > > > > It is not uncommon for such federations to have 1000s and sometimes > > > 10000s of entities making client secret management something of a > > > scalability issue. > > > > > > Even with dynreg the problem of managing all of those client secrets > > > would still remain a *huge* (operational) security and scalability issue. > > > > > > There is therefore a desire among communities that have such deployments > > > to be able to re-use the key-management already in place for OAUTH2. > > > > > > Note that this example isn't tied to the SAML protocol at all. > > > > > > Leif > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > > ------------------------------ > > > > Message: 2 > > Date: Mon, 12 Nov 2012 22:12:40 +0100 > > From: Leif Johansson > > To: Phil Hunt > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac" > > discussion > > Message-ID: <50A16648.1030604@mnt.se> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On 11/12/2012 10:09 PM, Phil Hunt wrote: > > > Leif, > > > > > > I've read this a couple of times and I think I'm getting lost in > > > partial SAML vs. OAuth terminology. As a result, I thought you were > > > saying: > > > > > > 1. It isn't practical to issue client credentials even with Dynamic > > > Registration > > > 2. You want to re-use key management already in place with OAuth2. > > > > > > These statements seem to be in conflict. Did you mean to say for > > > number 2 that you want to re-use key management already in place for SAML? > > > > > yep - "for" as in "for use by" > > > > > > ------------------------------ > > > > Message: 3 > > Date: Tue, 13 Nov 2012 10:19:24 -0500 > > From: Hannes Tschofenig > > To: "oauth@ietf.org WG" > > Subject: [OAUTH-WG] Review Volunteers > > Message-ID: <9ABA26C3-1B06-4D15-9268-5F75B20E941D@gmx.net> > > Content-Type: text/plain; charset=us-ascii > > > > We collected a number of action items last week. Here is my list > > > > 1. Token Revocation > > > > ACTION: Torsten to publish a draft update this week. > > > > ACTION: Volunteers to review the draft: > > - Amanda > > - Justin > > - Tony > > > > 2. draft-ietf-oauth-jwt-bearer > > > > ACTION: Justin to review JWT Bearer Token Profiles > > > > 3. OAuth Use Cases > > > > ACTION: Tony to work with Zachary on building out use cases and clarifying the audience of the doc. > > > > 4. JWT > > > > ACTION: Jeff Hodges, Klaas, and Leif to review the draft. > > > > 5. Security > > > > http://datatracker.ietf.org/doc/draft-tschofenig-oauth-security/ > > > > ACTION: working group to provide feedback on the requirements. > > > > 6. Dynamic Client Registration > > > > ACTION: Hannes to ask UMA folks to review the doc. > > ACTION: Nat, John, Torsten to review the doc. > > > > > > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Tue, 13 Nov 2012 10:40:21 -0500 > > From: Hannes Tschofenig > > To: "oauth@ietf.org WG" > > Subject: [OAUTH-WG] Meeting Minutes > > Message-ID: > > Content-Type: text/plain; charset=us-ascii > > > > Hi all, > > > > please have a look at the meeting minutes from last week: > > http://www.ietf.org/proceedings/85/minutes/minutes-85-oauth > > > > Thanks to Amanda & Jean for taking notes. > > > > Ciao > > Hannes & Derek > > > > > > > > ------------------------------ > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > End of OAuth Digest, Vol 49, Issue 11 > > ************************************* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Tue, 13 Nov 2012 15:33:26 -0800 > From: Michael Jones > To: , , > Cc: cfrg@irtf.org > Subject: [OAUTH-WG] Vacationing this week & e-mail address > Message-ID: > Content-Type: text/plain; charset="windows-1252" > > > > > > Hi all, I wanted to let you know that I'm vacationing this week, and so mostly won't be participating in discussions. I'll respond next week. Also, at present I?m using the e-mail address michael_b_jones@hotmail.com > to send e-mail to IETF mailing lists because currently I?m unable to send e-mail to any IETF lists using my normal > e-mail address Michael.Jones@microsoft.com. > When corresponding with me individually, it would be better to use the > Microsoft address, as the message is likely to be seen more quickly. Have a good week, everyone! -- Mike > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 3 > Date: Wed, 14 Nov 2012 22:51:27 +0800 > From: dgq2011 > To: "oauth@ietf.org" > Subject: [OAUTH-WG] is OAuth protocol based on HTTP? > Message-ID: <201211142251220430822@gmail.com> > Content-Type: text/plain; charset="gb2312" > > Hi, all! It is said in RFC 6749 (The OAuth 2.0 Authorization Framework) that ?this specification is designed for use with HTTP ([RFC2616])? and ?The use of OAuth over any protocol other than HTTP is out of scope.? Do those statements mean that the communication between any two roles in OAuth protocol (namely resource owner, resource server, client and authorization server) is based on HTTP protocol? I am not familiar with the OAuth protocol and just would like to confirm this question. Any response is appreciated! > > > Best wishes? > Guangqing Deng > > > > dgq2011 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > End of OAuth Digest, Vol 49, Issue 12 > ************************************* ------=_Part_7208_1850176399.1353245235341 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable help


On November 14, 2012 6:51:40 AM PST, oauth-request@= ietf.org wrote:

If you have received this digest without = all the individual message
attachments you will need to= update your digest options in your list
subscription. =  To do so, go to

https://www.= ietf.org/mailman/listinfo/oauth

Click the 'Unsubscribe or edit options' button, log in, and set "Get=
MIME or Plain Text Digests?" to MIME.  You c= an set this option
globally for all the list digests yo= u receive at this point.



Send OAuth mailing list submissions to
=09oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, = via email, send a message with subject or body 'help' to
=09oauth-request@ietf.org

You ca= n reach the person managing the list at
=09oauth-owner@= ietf.org

When replying, please edi= t your Subject line so it is more specific
than "R= e: Contents of OAuth digest..."


Today's Topics:

  1. Re: OAuth Digest, Vol 49, Issue 11 (Nichole Richardson)   2. Vacationing this week & e-mail address (Mi= chael Jones)
  3. is OAuth protocol based on HTTP= ? (dgq2011)


-= ---------------------------------------------------------------------

Message: 1
Date: Tu= e, 13 Nov 2012 14:31:11 -0800
From: Nichole Richardson = <nichole.richardson.27@facebook.com>
To: <oaut= h@ietf.org>,  <oauth-request@ietf.org>
Su= bject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 11
Me= ssage-ID: <a8044d50234c082dcb53112e4b433fcb@messages.facebook.com>Content-Type: text/plain; charset=3D"utf-8"

get mime

On November 13, 2012 12:00:08 PM PST, oauth-request@ietf.org w= rote:
> If you have received this digest without all= the individual message
> attachments you will need = to update your digest options in your list
> subscri= ption.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/oauth
&g= t;
> Click the 'Unsubscribe or edit options' button= , log in, and set "Get
> MIME or Plain Text Dig= ests?" to MIME.  You can set this option
>= globally for all the list digests you receive at this point.
>
>
>
> Send OAuth mailing list submissions to
> =09oauth@ietf.org
>
> = To subscribe or unsubscribe via the World Wide Web, visit
> =09https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> =09oauth-request@ietf.org
> > You can reach the person managing the list at
> =09oauth-owner@ietf.org
>
> When replying, please edit your Subject line so it is mo= re specific
> than "Re: Contents of OAuth diges= t..."
>
>
> Today's Topics:
>
= >    1. Re: bag-of-keys metadata UC for the "mac" di= scussion (Phil Hunt)
>    2. Re: bag-of-ke= ys metadata UC for the "mac" discussion
> =       (Leif Johansson)
>    = ;3. Review Volunteers (Hannes Tschofenig)
>   &= nbsp;4. Meeting Minutes (Hannes Tschofenig)
>
>
> -----------------------------= -----------------------------------------
>
> Message: 1
> Date: Mon, 12 Nov 201= 2 13:09:11 -0800
> From: Phil Hunt <phil.hunt@ora= cle.com>
> To: Leif Johansson <leifj@mnt.se>= ;
> Cc: oauth@ietf.org
> Subj= ect: Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac"
> =09discussion
> Message-ID: <7E= F786E1-18E2-4974-A6BC-2C72BE9F5C11@oracle.com>
> = Content-Type: text/plain; charset=3D"iso-8859-1"
>
> Leif,
>
> I've read this a couple of times and I think I'm getting l= ost in partial SAML vs. OAuth terminology. As a result, I thought you were = saying:
>
> 1. It isn't prac= tical to issue client credentials even with Dynamic Registration
> 2. You want to re-use key management already in place with= OAuth2.
>
> These statement= s seem to be in conflict.  Did you mean to say for number 2 that you w= ant to re-use key management already in place for SAML?
>
> Phil
>
> @independentid
> www.independentid.com<= br clear=3D'none' />> phil.hunt@oracle.com
>
>
>
> <= br clear=3D'none' />>
> On 2012-11-08, at 8:01 A= M, Leif Johansson wrote:
>
>= > I promised to send a UC to the list as input to the discussion around= new
> > token formats.
> = >
> > ---
> >
> > Several large-scale deployments of public-key use= a "bag-of-keys" model
> > for key mana= gement: you stick endpoint information together with public
> > keys for those endpoints in a signable container which is th= en signed with
> > a private key associated with = some "trust provider" an distributed to all
&= gt; > entities/relying parties.
> >
> > Examples include various trust status lists formats a= nd things like SAML
> > metadata.
> >
> > The latter case (SAML metadat= a) isn't necessarily tied to the SAML v2
> > _pro= tocol_ but it is used for that. Large-scale SAML federations are often
> > setup to depend on distribution of signed SAML me= tadata.
> >
> > Consid= er the case when a large number of relying parties of such a SAML
> > federation are also either OAUTH2 resource or authori= zation servers. Today
> > all of those OAUTH2 ent= ities have to be provisioned with separate client
> = > secrets that have no relationship to the trust infrastructure already = in use
> > in the federation.
> >
> > It is not uncommon for such feder= ations to have 1000s and sometimes
> > 10000s of = entities making client secret management something of a
> > scalability issue.
> >
> > Even with dynreg the problem of managing all of those clien= t secrets
> > would still remain a *huge* (operat= ional) security and scalability issue.
> >
> > There is therefore a desire among communities that= have such deployments
> > to be able to re-use t= he key-management already in place for OAUTH2.
> >= ;
> > Note that this example isn't tied to the S= AML protocol at all.
> >
>= ; >         Leif
> > _____= __________________________________________
> > OA= uth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> -------------- next part ----------= ----
> An HTML attachment was scrubbed...
> URL: <http:/= /www.ietf.org/mail-archive/web/oauth/attachments/20121112/ede07590/attachme= nt.htm>
>
> ---------= ---------------------
>
> Me= ssage: 2
> Date: Mon, 12 Nov 2012 22:12:40 +0100
> From: Leif Johansson <leifj@mnt.se>
> To: Phil Hunt <phil.hunt@oracle.com>
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] = bag-of-keys metadata UC for the "mac"
> = =09discussion
> Message-ID: <50A16648.1030604@mnt= .se>
> Content-Type: text/plain; charset=3DISO-88= 59-1
>
> On 11/12/2012 10:09= PM, Phil Hunt wrote:
> > Leif,
> >
> > I've read this a couple of times= and I think I'm getting lost in
> > partial SAML= vs. OAuth terminology. As a result, I thought you were
> > saying:
> >
> &= gt; 1. It isn't practical to issue client credentials even with Dynamic
> > Registration
> > 2. Yo= u want to re-use key management already in place with OAuth2.
> >
> > These statements seem to be = in conflict.  Did you mean to say for
> > nu= mber 2 that you want to re-use key management already in place for SAML?> >
> yep - "for" = as in "for use by"
>
= >
> ------------------------------
>
> Message: 3
> D= ate: Tue, 13 Nov 2012 10:19:24 -0500
> From: Hannes = Tschofenig <hannes.tschofenig@gmx.net>
> To: &= quot;oauth@ietf.org WG" <oauth@ietf.org>
>= ; Subject: [OAUTH-WG] Review Volunteers
> Message-ID= : <9ABA26C3-1B06-4D15-9268-5F75B20E941D@gmx.net>
= > Content-Type: text/plain; charset=3Dus-ascii
> =
> We collected a number of action items last week. = Here is my list
>
> 1. Token= Revocation
>
> ACTION: Tors= ten to publish a draft update this week.
>
> ACTION: Volunteers to review the draft:
> - Amanda
> - Justin
>= ; - Tony
>
> 2. draft-ietf-o= auth-jwt-bearer
>
> ACTION: = Justin to review JWT Bearer Token Profiles
>
> 3. OAuth Use Cases
>
> ACTION: Tony to work with Zachary on building out use case= s and clarifying the audience of the doc.
>
> 4. JWT
>
>= ACTION: Jeff Hodges, Klaas, and Leif to review the draft.
>
> 5. Security
> > http://datatracker.ietf.org/doc/= draft-tschofenig-oauth-security/
>
> ACTION: working group to provide feedback on the requirements.=
>
> 6. Dynamic Client Regi= stration
>
> ACTION: Hannes= to ask UMA folks to review the doc.
> ACTION: Nat,= John, Torsten to review the doc.
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 13 Nov 2012 10:40:21 -0500
> From= : Hannes Tschofenig <hannes.tschofenig@gmx.net>
&= gt; To: "oauth@ietf.org WG" <oauth@ietf.org>
> Subject: [OAUTH-WG] Meeting Minutes
> Mes= sage-ID: <F640899A-B4E4-40B4-B961-64199C600AAD@gmx.net>
> Content-Type: text/plain; charset=3Dus-ascii
>
> Hi all,
>
> please have a look at the meeting minutes from last week:=
> http://www.ietf.org/proceedings/85= /minutes/minutes-85-oauth
>
> Thanks to Amanda & Jean for taking notes.
&g= t;
> Ciao
> Hannes & Der= ek
>
>
= >
> ------------------------------
>
> _____________________________________= __________
> OAuth mailing list
= > OAuth@ietf.org
> https://www.ietf.org/mailman/li= stinfo/oauth
>
>
> End of OAuth Digest, Vol 49, Issue 11
> *************************************
----------= ---- next part --------------
An HTML attachment was sc= rubbed...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20121113/d475= 2114/attachment.htm>

------= ------------------------

Message: = 2
Date: Tue, 13 Nov 2012 15:33:26 -0800
From: Michael Jones <michael_b_jones@hotmail.com>
To: <jose@ietf.org>, <oauth@ietf.org>, <apps-discuss@i= etf.org>
Cc: cfrg@irtf.org
Subje= ct: [OAUTH-WG] Vacationing this week & e-mail address
Message-ID: <BAY171-W4767242AC702446BF30539B76C0@phx.gbl>
Content-Type: text/plain; charset=3D"windows-1252"




Hi all, I wanted to let you= know that I'm vacationing this week, and so mostly won't be participating = in discussions.  I'll respond next week. Also, at present I?m using th= e e-mail address michael_b_jones@hotmail.com
to send e-= mail to IETF mailing lists because currently I?m unable to send e-mail to a= ny IETF lists using my normal
e-mail address Michael.Jo= nes@microsoft.com.
When corresponding with me individu= ally, it would be better to use the
Microsoft address, = as the message is likely to be seen more quickly. Have a good week, everyon= e! -- Mike

=09=09 =09   =09= =09  
-------------- next part --------------
An HTML attachment was scrubbed...
URL:= <http://www.ietf.org/mail-ar= chive/web/oauth/attachments/20121113/8b3a4b36/attachment.htm>

------------------------------

Message: 3
Date: Wed, = 14 Nov 2012 22:51:27 +0800
From: dgq2011 <dgq2011@gm= ail.com>
To: "oauth@ietf.org" <oauth@ie= tf.org>
Subject: [OAUTH-WG] is OAuth protocol based = on HTTP?
Message-ID: <201211142251220430822@gmail.co= m>
Content-Type: text/plain; charset=3D"gb2312&= quot;

Hi, all! It is said in RFC 6= 749 (The OAuth 2.0 Authorization Framework) that ?this specification is des= igned for use with HTTP ([RFC2616])? and ?The use of OAuth over any protoco= l other than HTTP is out of scope.? Do those statements mean that the commu= nication between any two roles in OAuth protocol (namely resource owner, re= source server, client and authorization server) is based on HTTP protocol? = I am not familiar with the OAuth protocol and just would like to confirm th= is question. Any response is appreciated!


Best wishes?
Guangqing Den= g



dgq2011
-------------- next part ----------= ----
An HTML attachment was scrubbed...
URL: <http://www.ietf.or= g/mail-archive/web/oauth/attachments/20121114/e1240784/attachment.htm&g= t;

------------------------------<= br clear=3D'none' />
__________________________________= _____________
OAuth mailing list
OA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=


End of O= Auth Digest, Vol 49, Issue 12
*************************= ************
------=_Part_7208_1850176399.1353245235341-- From nichole.richardson.27@facebook.com Sun Nov 18 05:44:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDDE21F84C4 for ; Sun, 18 Nov 2012 05:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.554 X-Spam-Level: X-Spam-Status: No, score=-101.554 tagged_above=-999 required=5 tests=[AWL=0.710, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5gCeW0xzeRP for ; Sun, 18 Nov 2012 05:44:23 -0800 (PST) Received: from smtpout.mx.facebook.com (smtpout004.ash3.facebook.com [69.171.244.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4D921F84C0 for ; Sun, 18 Nov 2012 05:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=facebook.com; s=s1024-2010-q3; c=relaxed/simple; q=dns/txt; i=@facebook.com; t=1353246255; h=From:Subject:X-:Date:To:MIME-Version:Content-Type; bh=ljOL4TTOgAPBSnDvKqqYkhhqnKpBgtIcKPE7s8543+4=; b=EY/O6I54DbBUv9Fp7kRXDRuwF/RncuXGtp6/ZK5mLqf7dHQnAA94m5lKJg4CSr8r nsmpCviLiUAFR89PjNVyFVFj8Gti27u9TMM8UBdJ5RMbv+jqpOmMMve4ZZIAEUll qYQ6r63bSp5QCbhiTBcSkwIEzB73d0N6QcbDEi0yWaY=; Received: from [10.148.86.69] ([10.148.86.69:39337] helo=www.facebook.com) by 10.148.131.45 (envelope-from ) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id 08/F1-20039-F26E8A05; Sun, 18 Nov 2012 05:44:15 -0800 Date: Sun, 18 Nov 2012 05:44:15 -0800 From: Nichole Richardson To: , Message-ID: In-Reply-To: References: , MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7211_535967378.1353246255966" Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 15 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 13:44:25 -0000 ------=_Part_7211_535967378.1353246255966 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit help subscribe to oauth digest, Vol 49,Issue 15 On November 18, 2012 5:27:18 AM PST, oauth-request@ietf.org wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/oauth > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: OAuth Digest, Vol 49, Issue 14 (Nichole Richardson) > 2. Re: OAuth Digest, Vol 49, Issue 12 (Nichole Richardson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 18 Nov 2012 05:26:40 -0800 > From: Nichole Richardson > To: , > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 14 > Message-ID: > Content-Type: text/plain; charset="utf-8" > > help > > On November 16, 2012 12:00:14 PM PST, oauth-request@ietf.org wrote: > > If you have received this digest without all the individual message > > attachments you will need to update your digest options in your list > > subscription. To do so, go to > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > MIME or Plain Text Digests?" to MIME. You can set this option > > globally for all the list digests you receive at this point. > > > > > > > > Send OAuth mailing list submissions to > > oauth@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/oauth > > or, via email, send a message with subject or body 'help' to > > oauth-request@ietf.org > > > > You can reach the person managing the list at > > oauth-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of OAuth digest..." > > > > > > Today's Topics: > > > > 1. Question related to OAuth access token (Security Developer) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Fri, 16 Nov 2012 01:03:16 +0500 > > From: Security Developer > > To: OAuth@ietf.org > > Subject: [OAUTH-WG] Question related to OAuth access token > > Message-ID: > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > Hi, > > > > If an access token is either SAML or JWT in OAuth then what would be the > > value in subject either resource owner or client application name? > > > > Thanks for your time. > > > > Regards, > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > > ------------------------------ > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > End of OAuth Digest, Vol 49, Issue 14 > > ************************************* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Sun, 18 Nov 2012 05:27:15 -0800 > From: Nichole Richardson > To: , > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 12 > Message-ID: > Content-Type: text/plain; charset="utf-8" > > help > > > On November 14, 2012 6:51:40 AM PST, oauth-request@ietf.org wrote: > > If you have received this digest without all the individual message > > attachments you will need to update your digest options in your list > > subscription. To do so, go to > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > MIME or Plain Text Digests?" to MIME. You can set this option > > globally for all the list digests you receive at this point. > > > > > > > > Send OAuth mailing list submissions to > > oauth@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/oauth > > or, via email, send a message with subject or body 'help' to > > oauth-request@ietf.org > > > > You can reach the person managing the list at > > oauth-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of OAuth digest..." > > > > > > Today's Topics: > > > > 1. Re: OAuth Digest, Vol 49, Issue 11 (Nichole Richardson) > > 2. Vacationing this week & e-mail address (Michael Jones) > > 3. is OAuth protocol based on HTTP? (dgq2011) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 13 Nov 2012 14:31:11 -0800 > > From: Nichole Richardson > > To: , > > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 11 > > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > > > get mime > > > > On November 13, 2012 12:00:08 PM PST, oauth-request@ietf.org wrote: > > > If you have received this digest without all the individual message > > > attachments you will need to update your digest options in your list > > > subscription. To do so, go to > > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > > MIME or Plain Text Digests?" to MIME. You can set this option > > > globally for all the list digests you receive at this point. > > > > > > > > > > > > Send OAuth mailing list submissions to > > > oauth@ietf.org > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://www.ietf.org/mailman/listinfo/oauth > > > or, via email, send a message with subject or body 'help' to > > > oauth-request@ietf.org > > > > > > You can reach the person managing the list at > > > oauth-owner@ietf.org > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of OAuth digest..." > > > > > > > > > Today's Topics: > > > > > > 1. Re: bag-of-keys metadata UC for the "mac" discussion (Phil Hunt) > > > 2. Re: bag-of-keys metadata UC for the "mac" discussion > > > (Leif Johansson) > > > 3. Review Volunteers (Hannes Tschofenig) > > > 4. Meeting Minutes (Hannes Tschofenig) > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Mon, 12 Nov 2012 13:09:11 -0800 > > > From: Phil Hunt > > > To: Leif Johansson > > > Cc: oauth@ietf.org > > > Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac" > > > discussion > > > Message-ID: <7EF786E1-18E2-4974-A6BC-2C72BE9F5C11@oracle.com> > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > Leif, > > > > > > I've read this a couple of times and I think I'm getting lost in partial SAML vs. OAuth terminology. As a result, I thought you were saying: > > > > > > 1. It isn't practical to issue client credentials even with Dynamic Registration > > > 2. You want to re-use key management already in place with OAuth2. > > > > > > These statements seem to be in conflict. Did you mean to say for number 2 that you want to re-use key management already in place for SAML? > > > > > > Phil > > > > > > @independentid > > > www.independentid.com > > > phil.hunt@oracle.com > > > > > > > > > > > > > > > > > > On 2012-11-08, at 8:01 AM, Leif Johansson wrote: > > > > > > > I promised to send a UC to the list as input to the discussion around new > > > > token formats. > > > > > > > > --- > > > > > > > > Several large-scale deployments of public-key use a "bag-of-keys" model > > > > for key management: you stick endpoint information together with public > > > > keys for those endpoints in a signable container which is then signed with > > > > a private key associated with some "trust provider" an distributed to all > > > > entities/relying parties. > > > > > > > > Examples include various trust status lists formats and things like SAML > > > > metadata. > > > > > > > > The latter case (SAML metadata) isn't necessarily tied to the SAML v2 > > > > _protocol_ but it is used for that. Large-scale SAML federations are often > > > > setup to depend on distribution of signed SAML metadata. > > > > > > > > Consider the case when a large number of relying parties of such a SAML > > > > federation are also either OAUTH2 resource or authorization servers. Today > > > > all of those OAUTH2 entities have to be provisioned with separate client > > > > secrets that have no relationship to the trust infrastructure already in use > > > > in the federation. > > > > > > > > It is not uncommon for such federations to have 1000s and sometimes > > > > 10000s of entities making client secret management something of a > > > > scalability issue. > > > > > > > > Even with dynreg the problem of managing all of those client secrets > > > > would still remain a *huge* (operational) security and scalability issue. > > > > > > > > There is therefore a desire among communities that have such deployments > > > > to be able to re-use the key-management already in place for OAUTH2. > > > > > > > > Note that this example isn't tied to the SAML protocol at all. > > > > > > > > Leif > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: > > > > > > ------------------------------ > > > > > > Message: 2 > > > Date: Mon, 12 Nov 2012 22:12:40 +0100 > > > From: Leif Johansson > > > To: Phil Hunt > > > Cc: oauth@ietf.org > > > Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac" > > > discussion > > > Message-ID: <50A16648.1030604@mnt.se> > > > Content-Type: text/plain; charset=ISO-8859-1 > > > > > > On 11/12/2012 10:09 PM, Phil Hunt wrote: > > > > Leif, > > > > > > > > I've read this a couple of times and I think I'm getting lost in > > > > partial SAML vs. OAuth terminology. As a result, I thought you were > > > > saying: > > > > > > > > 1. It isn't practical to issue client credentials even with Dynamic > > > > Registration > > > > 2. You want to re-use key management already in place with OAuth2. > > > > > > > > These statements seem to be in conflict. Did you mean to say for > > > > number 2 that you want to re-use key management already in place for SAML? > > > > > > > yep - "for" as in "for use by" > > > > > > > > > ------------------------------ > > > > > > Message: 3 > > > Date: Tue, 13 Nov 2012 10:19:24 -0500 > > > From: Hannes Tschofenig > > > To: "oauth@ietf.org WG" > > > Subject: [OAUTH-WG] Review Volunteers > > > Message-ID: <9ABA26C3-1B06-4D15-9268-5F75B20E941D@gmx.net> > > > Content-Type: text/plain; charset=us-ascii > > > > > > We collected a number of action items last week. Here is my list > > > > > > 1. Token Revocation > > > > > > ACTION: Torsten to publish a draft update this week. > > > > > > ACTION: Volunteers to review the draft: > > > - Amanda > > > - Justin > > > - Tony > > > > > > 2. draft-ietf-oauth-jwt-bearer > > > > > > ACTION: Justin to review JWT Bearer Token Profiles > > > > > > 3. OAuth Use Cases > > > > > > ACTION: Tony to work with Zachary on building out use cases and clarifying the audience of the doc. > > > > > > 4. JWT > > > > > > ACTION: Jeff Hodges, Klaas, and Leif to review the draft. > > > > > > 5. Security > > > > > > http://datatracker.ietf.org/doc/draft-tschofenig-oauth-security/ > > > > > > ACTION: working group to provide feedback on the requirements. > > > > > > 6. Dynamic Client Registration > > > > > > ACTION: Hannes to ask UMA folks to review the doc. > > > ACTION: Nat, John, Torsten to review the doc. > > > > > > > > > > > > > > > > > > ------------------------------ > > > > > > Message: 4 > > > Date: Tue, 13 Nov 2012 10:40:21 -0500 > > > From: Hannes Tschofenig > > > To: "oauth@ietf.org WG" > > > Subject: [OAUTH-WG] Meeting Minutes > > > Message-ID: > > > Content-Type: text/plain; charset=us-ascii > > > > > > Hi all, > > > > > > please have a look at the meeting minutes from last week: > > > http://www.ietf.org/proceedings/85/minutes/minutes-85-oauth > > > > > > Thanks to Amanda & Jean for taking notes. > > > > > > Ciao > > > Hannes & Derek > > > > > > > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > End of OAuth Digest, Vol 49, Issue 11 > > > ************************************* > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 13 Nov 2012 15:33:26 -0800 > > From: Michael Jones > > To: , , > > Cc: cfrg@irtf.org > > Subject: [OAUTH-WG] Vacationing this week & e-mail address > > Message-ID: > > Content-Type: text/plain; charset="windows-1252" > > > > > > > > > > > > Hi all, I wanted to let you know that I'm vacationing this week, and so mostly won't be participating in discussions. I'll respond next week. Also, at present I?m using the e-mail address michael_b_jones@hotmail.com > > to send e-mail to IETF mailing lists because currently I?m unable to send e-mail to any IETF lists using my normal > > e-mail address Michael.Jones@microsoft.com. > > When corresponding with me individually, it would be better to use the > > Microsoft address, as the message is likely to be seen more quickly. Have a good week, everyone! -- Mike > > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 14 Nov 2012 22:51:27 +0800 > > From: dgq2011 > > To: "oauth@ietf.org" > > Subject: [OAUTH-WG] is OAuth protocol based on HTTP? > > Message-ID: <201211142251220430822@gmail.com> > > Content-Type: text/plain; charset="gb2312" > > > > Hi, all! It is said in RFC 6749 (The OAuth 2.0 Authorization Framework) that ?this specification is designed for use with HTTP ([RFC2616])? and ?The use of OAuth over any protocol other than HTTP is out of scope.? Do those statements mean that the communication between any two roles in OAuth protocol (namely resource owner, resource server, client and authorization server) is based on HTTP protocol? I am not familiar with the OAuth protocol and just would like to confirm this question. Any response is appreciated! > > > > > > Best wishes? > > Guangqing Deng > > > > > > > > dgq2011 > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > > ------------------------------ > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > End of OAuth Digest, Vol 49, Issue 12 > > ************************************* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > End of OAuth Digest, Vol 49, Issue 15 > ************************************* ------=_Part_7211_535967378.1353246255966 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable help subscribe to oauth digest, Vol 49,Issue 15

On November 1= 8, 2012 5:27:18 AM PST, oauth-request@ietf.org wrote:

If = you have received this digest without all the individual message
attachments you will need to update your digest options in your= list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/oauth=

Click the 'Unsubscribe or edit op= tions' button, log in, and set "Get
MIME or Plain = Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



= Send OAuth mailing list submissions to
=09oauth@ietf.or= g

To subscribe or unsubscribe via = the World Wide Web, visit
https://www.ietf.org/mailman/l= istinfo/oauth
or, via email, send a message with su= bject or body 'help' to
=09oauth-request@ietf.org

You can reach the person managing the l= ist at
=09oauth-owner@ietf.org

When replying, please edit your Subject line so it is more= specific
than "Re: Contents of OAuth digest...&qu= ot;


Today's T= opics:

  1. Re: OAuth Digest= , Vol 49, Issue 14 (Nichole Richardson)
  2. Re: = OAuth Digest, Vol 49, Issue 12 (Nichole Richardson)

------------------------------------= ----------------------------------

Message: 1
Date: Sun, 18 Nov 2012 05:26:40 -0800
From: Nichole Richardson <nichole.richardson.27@facebook.= com>
To: <oauth@ietf.org>,  <oauth-req= uest@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Digest,= Vol 49, Issue 14
Message-ID: <dacb75681fda6ccceb10c= aa6dc61d725@messages.facebook.com>
Content-Type: tex= t/plain; charset=3D"utf-8"

help

On November 16, 2012 12:00= :14 PM PST, oauth-request@ietf.org wrote:
> If you h= ave received this digest without all the individual message
> attachments you will need to update your digest options in your l= ist
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/list= info/oauth
>
> Click the= 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can s= et this option
> globally for all the list digests y= ou receive at this point.
>
>= ;
>
> Send OAuth mailing li= st submissions to
> =09oauth@ietf.org
>
> To subscribe or unsubscribe via the Wo= rld Wide Web, visit
> =09https://www.ietf.org/mailman= /listinfo/oauth
> or, via email, send a message = with subject or body 'help' to
> =09oauth-request@ie= tf.org
>
> You can reach the= person managing the list at
> =09oauth-owner@ietf.o= rg
>
> When replying, please= edit your Subject line so it is more specific
> tha= n "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>    1. Question related to= OAuth access token (Security Developer)
>
>
> --------------------------------= --------------------------------------
>
> Message: 1
> Date: Fri, 16 Nov 2012= 01:03:16 +0500
> From: Security Developer <secur= ity.developer22@gmail.com>
> To: OAuth@ietf.org> Subject: [OAUTH-WG] Question related to OAuth acces= s token
> Message-ID:
> =09&l= t;CAD-drXstwtoAtd=3Dvz43mOpLjNRTjisYWoYUOWuE3mdU_9r3n_A@mail.gmail.com><= br clear=3D'none' />> Content-Type: text/plain; charset=3D"iso-8859= -1"
>
> Hi,
>
> If an access token is either SAML o= r JWT in OAuth then what would be the
> value in sub= ject either resource owner or client application name?
= >
> Thanks for your time.
&g= t;
> Regards,
> ------------= -- next part --------------
> An HTML attachment was= scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20121= 116/258a14c4/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth>
>
> = End of OAuth Digest, Vol 49, Issue 14
> ************= *************************
-------------- next part ----= ----------
An HTML attachment was scrubbed...
URL: <http://www.= ietf.org/mail-archive/web/oauth/attachments/20121118/cea4d9c7/attachment.ht= m>

------------------------= ------

Message: 2
Date: Sun, 18 Nov 2012 05:27:15 -0800
From: Nichole= Richardson <nichole.richardson.27@facebook.com>
= To: <oauth@ietf.org>,  <oauth-request@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 12
Message-ID: <b3bcaf3b2487b7eebc3c8ecbde1843a9@messages.faceb= ook.com>
Content-Type: text/plain; charset=3D"u= tf-8"

help


On November 14, 2012 6:51:40 AM= PST, oauth-request@ietf.org wrote:
> If you have re= ceived this digest without all the individual message
&= gt; attachments you will need to update your digest options in your list> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/oa= uth
>
> Click the 'Unsub= scribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this o= ption
> globally for all the list digests you receiv= e at this point.
>
>
>
> Send OAuth mailing list submis= sions to
> =09oauth@ietf.org
>= ;
> To subscribe or unsubscribe via the World Wide = Web, visit
> =09https://www.ietf.org/mailman/listinfo= /oauth
> or, via email, send a message with subj= ect or body 'help' to
> =09oauth-request@ietf.org>
> You can reach the person m= anaging the list at
> =09oauth-owner@ietf.org
>
> When replying, please edit you= r Subject line so it is more specific
> than "R= e: Contents of OAuth digest..."
>
>
> Today's Topics:
= >
>    1. Re: OAuth Digest, Vol 49, Is= sue 11 (Nichole Richardson)
>    2. Vacati= oning this week & e-mail address (Michael Jones)
&g= t;    3. is OAuth protocol based on HTTP? (dgq2011)
>
>
> -----------= -----------------------------------------------------------
>
> Message: 1
> Dat= e: Tue, 13 Nov 2012 14:31:11 -0800
> From: Nichole R= ichardson <nichole.richardson.27@facebook.com>
&g= t; To: <oauth@ietf.org>,  <oauth-request@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 11> Message-ID: <a8044d50234c082dcb53112e4b433fcb@mes= sages.facebook.com>
> Content-Type: text/plain; c= harset=3D"utf-8"
>
&g= t; get mime
>
> On November = 13, 2012 12:00:08 PM PST, oauth-request@ietf.org wrote:
> > If you have received this digest without all the individual mess= age
> > attachments you will need to update your = digest options in your list
> > subscription. &nb= sp;To do so, go to
> >
>= > https://www.ietf.org/mailman/listinfo/oauth
&g= t; >
> > Click the 'Unsubscribe or edit optio= ns' button, log in, and set "Get
> > MIME or= Plain Text Digests?" to MIME.  You can set this option
> > globally for all the list digests you receive at this= point.
> >
> >
> >
> > Send OAuth mailing = list submissions to
> > =09oauth@ietf.org
> >
> > To subscribe or unsub= scribe via the World Wide Web, visit
> > =09https:= //www.ietf.org/mailman/listinfo/oauth
> > or,= via email, send a message with subject or body 'help' to
> > =09oauth-request@ietf.org
> >
> > You can reach the person managing the list at
> > =09oauth-owner@ietf.org
> = >
> > When replying, please edit your Subject= line so it is more specific
> > than "Re: C= ontents of OAuth digest..."
> >
> >
> > Today's Topics:
> >
> >    1. Re: ba= g-of-keys metadata UC for the "mac" discussion (Phil Hunt)
> >    2. Re: bag-of-keys metadata UC for the= "mac" discussion
> >     &nb= sp; (Leif Johansson)
> >    3. Review V= olunteers (Hannes Tschofenig)
> >    4.= Meeting Minutes (Hannes Tschofenig)
> >
> >
> > ---------------------= -------------------------------------------------
> = >
> > Message: 1
> >= ; Date: Mon, 12 Nov 2012 13:09:11 -0800
> > From:= Phil Hunt <phil.hunt@oracle.com>
> > To: L= eif Johansson <leifj@mnt.se>
> > Cc: oauth@= ietf.org
> > Subject: Re: [OAUTH-WG] bag-of-keys = metadata UC for the "mac"
> > =09discus= sion
> > Message-ID: <7EF786E1-18E2-4974-A6BC-= 2C72BE9F5C11@oracle.com>
> > Content-Type: tex= t/plain; charset=3D"iso-8859-1"
> > > > Leif,
> >
> > I've read this a couple of times and I think I'm gett= ing lost in partial SAML vs. OAuth terminology. As a result, I thought you = were saying:
> >
> > 1= . It isn't practical to issue client credentials even with Dynamic Registra= tion
> > 2. You want to re-use key management alr= eady in place with OAuth2.
> >
> > These statements seem to be in conflict.  Did you mean to= say for number 2 that you want to re-use key management already in place f= or SAML?
> >
> > Phil<= br clear=3D'none' />> >
> > @independentid=
> > www.independentid.com
&g= t; > phil.hunt@oracle.com
> >
> >
> >
> >= ;
> >
> > On 2012-11-= 08, at 8:01 AM, Leif Johansson wrote:
> >
> > > I promised to send a UC to the list as input t= o the discussion around new
> > > token format= s.
> > >
> > > -= --
> > >
> > > S= everal large-scale deployments of public-key use a "bag-of-keys" = model
> > > for key management: you stick endp= oint information together with public
> > > ke= ys for those endpoints in a signable container which is then signed with> > > a private key associated with some "t= rust provider" an distributed to all
> > >= ; entities/relying parties.
> > >
> > > Examples include various trust status lists formats= and things like SAML
> > > metadata.
> > >
> > > The latter c= ase (SAML metadata) isn't necessarily tied to the SAML v2
> > > _protocol_ but it is used for that. Large-scale SAML fede= rations are often
> > > setup to depend on dis= tribution of signed SAML metadata.
> > >
> > > Consider the case when a large number of rel= ying parties of such a SAML
> > > federation a= re also either OAUTH2 resource or authorization servers. Today
> > > all of those OAUTH2 entities have to be provisioned = with separate client
> > > secrets that have n= o relationship to the trust infrastructure already in use
> > > in the federation.
> > > > > > It is not uncommon for such federations to= have 1000s and sometimes
> > > 10000s of enti= ties making client secret management something of a
>= ; > > scalability issue.
> > >
> > > Even with dynreg the problem of managing all of = those client secrets
> > > would still remain = a *huge* (operational) security and scalability issue.
= > > >
> > > There is therefore a des= ire among communities that have such deployments
> &= gt; > to be able to re-use the key-management already in place for OAUTH= 2.
> > >
> > > N= ote that this example isn't tied to the SAML protocol at all.
> > >
> > >     &nb= sp;   Leif
> > > ________________________= _______________________
> > > OAuth mailing li= st
> > > OAuth@ietf.org
&g= t; > > https://www.ietf.org/mailman/listinfo/oauth
> >
> > -------------- next part ----= ----------
> > An HTML attachment was scrubbed...=
> > URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20121112/ede= 07590/attachment.htm>
> >
> > ------------------------------
> >=
> > Message: 2
> > Da= te: Mon, 12 Nov 2012 22:12:40 +0100
> > From: Lei= f Johansson <leifj@mnt.se>
> > To: Phil Hun= t <phil.hunt@oracle.com>
> > Cc: oauth@ietf= .org
> > Subject: Re: [OAUTH-WG] bag-of-keys meta= data UC for the "mac"
> > =09discussion=
> > Message-ID: <50A16648.1030604@mnt.se><= br clear=3D'none' />> > Content-Type: text/plain; charset=3DISO-8859-= 1
> >
> > On 11/12/201= 2 10:09 PM, Phil Hunt wrote:
> > > Leif,
> > >
> > > I've read = this a couple of times and I think I'm getting lost in
= > > > partial SAML vs. OAuth terminology. As a result, I thought y= ou were
> > > saying:
>= > >
> > > 1. It isn't practical to issu= e client credentials even with Dynamic
> > > R= egistration
> > > 2. You want to re-use key ma= nagement already in place with OAuth2.
> > >> > > These statements seem to be in conflict. =  Did you mean to say for
> > > number 2 t= hat you want to re-use key management already in place for SAML?
> > >
> > yep - "for&qu= ot; as in "for use by"
> >
> >
> > -------------------------= -----
> >
> > Message:= 3
> > Date: Tue, 13 Nov 2012 10:19:24 -0500
> > From: Hannes Tschofenig <hannes.tschofenig@gmx= .net>
> > To: "oauth@ietf.org WG" &l= t;oauth@ietf.org>
> > Subject: [OAUTH-WG] Revi= ew Volunteers
> > Message-ID: <9ABA26C3-1B06-4= D15-9268-5F75B20E941D@gmx.net>
> > Content-Typ= e: text/plain; charset=3Dus-ascii
> >
> > We collected a number of action items last week. Here= is my list
> >
> > 1.= Token Revocation
> >
> &= gt; ACTION: Torsten to publish a draft update this week.
> >
> > ACTION: Volunteers to review th= e draft:
> > - Amanda
> &= gt; - Justin
> > - Tony
> = >
> > 2. draft-ietf-oauth-jwt-bearer
> >
> > ACTION: Justin to revi= ew JWT Bearer Token Profiles
> >
> > 3. OAuth Use Cases
> >
> > ACTION: Tony to work with Zachary on building out use= cases and clarifying the audience of the doc.
> >= ;
> > 4. JWT
> >
> > ACTION: Jeff Hodges, Klaas, and Leif to review th= e draft.
> >
> > 5. Se= curity
> >
> > http://datatracker.ietf.org/doc/draft-tschofenig-oauth-securit= y/
> >
> > ACTION:= working group to provide feedback on the requirements.
> >
> > 6. Dynamic Client Registration <= br clear=3D'none' />> >
> > ACTION: Hannes= to ask UMA folks to review the doc.
> > ACTION:= Nat, John, Torsten to review the doc.
> >
> >
> >
> >
> >
> > = ------------------------------
> >
> > Message: 4
> > Date: Tue, 13 Nov= 2012 10:40:21 -0500
> > From: Hannes Tschofenig = <hannes.tschofenig@gmx.net>
> > To: "o= auth@ietf.org WG" <oauth@ietf.org>
> >= Subject: [OAUTH-WG] Meeting Minutes
> > Message-= ID: <F640899A-B4E4-40B4-B961-64199C600AAD@gmx.net>
> > Content-Type: text/plain; charset=3Dus-ascii
> >
> > Hi all,
>= ; >
> > please have a look at the meeting min= utes from last week:
> > http://ww= w.ietf.org/proceedings/85/minutes/minutes-85-oauth
= > >
> > Thanks to Amanda & Jean for ta= king notes.
> >
> > C= iao
> > Hannes & Derek
&g= t; >
> >
> >
> > ------------------------------
> >
> > ________________________________= _______________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://= www.ietf.org/mailman/listinfo/oauth
> >
> >
> > End of OAuth Diges= t, Vol 49, Issue 11
> > *************************= ************
> -------------- next part ------------= --
> An HTML attachment was scrubbed...
> URL: <http://www= .ietf.org/mail-archive/web/oauth/attachments/20121113/d4752114/attachment.h= tm>
>
> -------------= -----------------
>
> Messag= e: 2
> Date: Tue, 13 Nov 2012 15:33:26 -0800
> From: Michael Jones <michael_b_jones@hotmail.com>> To: <jose@ietf.org>, <oauth@ietf.org>, = <apps-discuss@ietf.org>
> Cc: cfrg@irtf.org> Subject: [OAUTH-WG] Vacationing this week & e-ma= il address
> Message-ID: <BAY171-W4767242AC702446= BF30539B76C0@phx.gbl>
> Content-Type: text/plain;= charset=3D"windows-1252"
>
>
>
>
>
> Hi all, I wanted to let you know= that I'm vacationing this week, and so mostly won't be participating in di= scussions.  I'll respond next week. Also, at present I?m using the e-m= ail address michael_b_jones@hotmail.com
> to send e-= mail to IETF mailing lists because currently I?m unable to send e-mail to a= ny IETF lists using my normal
> e-mail address Micha= el.Jones@microsoft.com.
> When corresponding with m= e individually, it would be better to use the
> Micr= osoft address, as the message is likely to be seen more quickly. Have a goo= d week, everyone! -- Mike
>
&g= t;  =09=09 =09   =09=09  
> ---------= ----- next part --------------
> An HTML attachment = was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20= 121113/8b3a4b36/attachment.htm>
>
> ------------------------------
> > Message: 3
> Date: Wed, 14 N= ov 2012 22:51:27 +0800
> From: dgq2011 <dgq2011@g= mail.com>
> To: "oauth@ietf.org" <oa= uth@ietf.org>
> Subject: [OAUTH-WG] is OAuth prot= ocol based on HTTP?
> Message-ID: <20121114225122= 0430822@gmail.com>
> Content-Type: text/plain; ch= arset=3D"gb2312"
>
&g= t; Hi, all! It is said in RFC 6749 (The OAuth 2.0 Authorization Framework) = that ?this specification is designed for use with HTTP ([RFC2616])? and ?Th= e use of OAuth over any protocol other than HTTP is out of scope.? Do those= statements mean that the communication between any two roles in OAuth prot= ocol (namely resource owner, resource server, client and authorization serv= er) is based on HTTP protocol? I am not familiar with the OAuth protocol an= d just would like to confirm this question. Any response is appreciated!>
>
> = Best wishes?
> Guangqing Deng
&g= t;
>
>
> dgq2011
> -------------- next part -----------= ---
> An HTML attachment was scrubbed...
> URL: <http://ww= w.ietf.org/mail-archive/web/oauth/attachments/20121114/e1240784/attachment.= htm>
>
> ------------= ------------------
>
> _____= __________________________________________
> OAuth m= ailing list
> OAuth@ietf.org
>= ; https://www.ietf.org/mailman/listinfo/oauth
> <= br clear=3D'none' />>
> End of OAuth Digest, Vol= 49, Issue 12
> ************************************= *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web= /oauth/attachments/20121118/05fa82f1/attachment.htm>

------------------------------

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


End of OAuth Digest, Vol 4= 9, Issue 15
*************************************
<= /blockquote>
------=_Part_7211_535967378.1353246255966-- From nichole.richardson.27@facebook.com Sun Nov 18 05:47:01 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC94D21F84CF for ; Sun, 18 Nov 2012 05:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.656 X-Spam-Level: X-Spam-Status: No, score=-101.656 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47blRaAYJ7Ou for ; Sun, 18 Nov 2012 05:46:59 -0800 (PST) Received: from smtpout.mx.facebook.com (smtpout003.ash3.facebook.com [69.171.244.66]) by ietfa.amsl.com (Postfix) with ESMTP id A791B21F84C2 for ; Sun, 18 Nov 2012 05:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=facebook.com; s=s1024-2010-q3; c=relaxed/simple; q=dns/txt; i=@facebook.com; t=1353246412; h=From:Subject:X-:Date:To:MIME-Version:Content-Type; bh=irTGPU1YogXYonscKSwA4phzw1/1dLSoNAFxH3EBpys=; b=DEG8rFBkrPaQzOrTl3A2G+06HjfT/sByRouFs5TsWlz1WpvFtWv/FrDfV/URfN+B Nz7LkmLdV2ERQWClEwiFD8Fl6T2SFE1uZefHWE8ttXzNmDkyZOK4Ws4R5Sf044ad /O+ozJiEEWoJ/C1+nCb6fi68MwamoPtW4xo1IOcjDZA=; Received: from [10.148.86.69] ([10.148.86.69:41821] helo=www.facebook.com) by 10.148.129.59 (envelope-from ) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id DD/8F-09804-CC6E8A05; Sun, 18 Nov 2012 05:46:52 -0800 Date: Sun, 18 Nov 2012 05:46:52 -0800 From: Nichole Richardson To: , Message-ID: <50b3a288714b4d7a01c9ea8ce809237b@messages.facebook.com> In-Reply-To: References: , MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7212_535604041.1353246412143" Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 13:47:01 -0000 ------=_Part_7212_535604041.1353246412143 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit get plain text On November 18, 2012 5:44:25 AM PST, oauth-request@ietf.org wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/oauth > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: OAuth Digest, Vol 49, Issue 15 (Nichole Richardson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 18 Nov 2012 05:44:15 -0800 > From: Nichole Richardson > To: , > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 15 > Message-ID: > Content-Type: text/plain; charset="utf-8" > > help subscribe to oauth digest, Vol 49,Issue 15 > > On November 18, 2012 5:27:18 AM PST, oauth-request@ietf.org wrote: > > If you have received this digest without all the individual message > > attachments you will need to update your digest options in your list > > subscription. To do so, go to > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > MIME or Plain Text Digests?" to MIME. You can set this option > > globally for all the list digests you receive at this point. > > > > > > > > Send OAuth mailing list submissions to > > oauth@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/oauth > > or, via email, send a message with subject or body 'help' to > > oauth-request@ietf.org > > > > You can reach the person managing the list at > > oauth-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of OAuth digest..." > > > > > > Today's Topics: > > > > 1. Re: OAuth Digest, Vol 49, Issue 14 (Nichole Richardson) > > 2. Re: OAuth Digest, Vol 49, Issue 12 (Nichole Richardson) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Sun, 18 Nov 2012 05:26:40 -0800 > > From: Nichole Richardson > > To: , > > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 14 > > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > > > help > > > > On November 16, 2012 12:00:14 PM PST, oauth-request@ietf.org wrote: > > > If you have received this digest without all the individual message > > > attachments you will need to update your digest options in your list > > > subscription. To do so, go to > > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > > MIME or Plain Text Digests?" to MIME. You can set this option > > > globally for all the list digests you receive at this point. > > > > > > > > > > > > Send OAuth mailing list submissions to > > > oauth@ietf.org > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://www.ietf.org/mailman/listinfo/oauth > > > or, via email, send a message with subject or body 'help' to > > > oauth-request@ietf.org > > > > > > You can reach the person managing the list at > > > oauth-owner@ietf.org > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of OAuth digest..." > > > > > > > > > Today's Topics: > > > > > > 1. Question related to OAuth access token (Security Developer) > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Fri, 16 Nov 2012 01:03:16 +0500 > > > From: Security Developer > > > To: OAuth@ietf.org > > > Subject: [OAUTH-WG] Question related to OAuth access token > > > Message-ID: > > > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > Hi, > > > > > > If an access token is either SAML or JWT in OAuth then what would be the > > > value in subject either resource owner or client application name? > > > > > > Thanks for your time. > > > > > > Regards, > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > End of OAuth Digest, Vol 49, Issue 14 > > > ************************************* > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > > ------------------------------ > > > > Message: 2 > > Date: Sun, 18 Nov 2012 05:27:15 -0800 > > From: Nichole Richardson > > To: , > > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 12 > > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > > > help > > > > > > On November 14, 2012 6:51:40 AM PST, oauth-request@ietf.org wrote: > > > If you have received this digest without all the individual message > > > attachments you will need to update your digest options in your list > > > subscription. To do so, go to > > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > > MIME or Plain Text Digests?" to MIME. You can set this option > > > globally for all the list digests you receive at this point. > > > > > > > > > > > > Send OAuth mailing list submissions to > > > oauth@ietf.org > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://www.ietf.org/mailman/listinfo/oauth > > > or, via email, send a message with subject or body 'help' to > > > oauth-request@ietf.org > > > > > > You can reach the person managing the list at > > > oauth-owner@ietf.org > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of OAuth digest..." > > > > > > > > > Today's Topics: > > > > > > 1. Re: OAuth Digest, Vol 49, Issue 11 (Nichole Richardson) > > > 2. Vacationing this week & e-mail address (Michael Jones) > > > 3. is OAuth protocol based on HTTP? (dgq2011) > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Tue, 13 Nov 2012 14:31:11 -0800 > > > From: Nichole Richardson > > > To: , > > > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 11 > > > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > > > > > get mime > > > > > > On November 13, 2012 12:00:08 PM PST, oauth-request@ietf.org wrote: > > > > If you have received this digest without all the individual message > > > > attachments you will need to update your digest options in your list > > > > subscription. To do so, go to > > > > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > > > MIME or Plain Text Digests?" to MIME. You can set this option > > > > globally for all the list digests you receive at this point. > > > > > > > > > > > > > > > > Send OAuth mailing list submissions to > > > > oauth@ietf.org > > > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > or, via email, send a message with subject or body 'help' to > > > > oauth-request@ietf.org > > > > > > > > You can reach the person managing the list at > > > > oauth-owner@ietf.org > > > > > > > > When replying, please edit your Subject line so it is more specific > > > > than "Re: Contents of OAuth digest..." > > > > > > > > > > > > Today's Topics: > > > > > > > > 1. Re: bag-of-keys metadata UC for the "mac" discussion (Phil Hunt) > > > > 2. Re: bag-of-keys metadata UC for the "mac" discussion > > > > (Leif Johansson) > > > > 3. Review Volunteers (Hannes Tschofenig) > > > > 4. Meeting Minutes (Hannes Tschofenig) > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > Message: 1 > > > > Date: Mon, 12 Nov 2012 13:09:11 -0800 > > > > From: Phil Hunt > > > > To: Leif Johansson > > > > Cc: oauth@ietf.org > > > > Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac" > > > > discussion > > > > Message-ID: <7EF786E1-18E2-4974-A6BC-2C72BE9F5C11@oracle.com> > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > > > Leif, > > > > > > > > I've read this a couple of times and I think I'm getting lost in partial SAML vs. OAuth terminology. As a result, I thought you were saying: > > > > > > > > 1. It isn't practical to issue client credentials even with Dynamic Registration > > > > 2. You want to re-use key management already in place with OAuth2. > > > > > > > > These statements seem to be in conflict. Did you mean to say for number 2 that you want to re-use key management already in place for SAML? > > > > > > > > Phil > > > > > > > > @independentid > > > > www.independentid.com > > > > phil.hunt@oracle.com > > > > > > > > > > > > > > > > > > > > > > > > On 2012-11-08, at 8:01 AM, Leif Johansson wrote: > > > > > > > > > I promised to send a UC to the list as input to the discussion around new > > > > > token formats. > > > > > > > > > > --- > > > > > > > > > > Several large-scale deployments of public-key use a "bag-of-keys" model > > > > > for key management: you stick endpoint information together with public > > > > > keys for those endpoints in a signable container which is then signed with > > > > > a private key associated with some "trust provider" an distributed to all > > > > > entities/relying parties. > > > > > > > > > > Examples include various trust status lists formats and things like SAML > > > > > metadata. > > > > > > > > > > The latter case (SAML metadata) isn't necessarily tied to the SAML v2 > > > > > _protocol_ but it is used for that. Large-scale SAML federations are often > > > > > setup to depend on distribution of signed SAML metadata. > > > > > > > > > > Consider the case when a large number of relying parties of such a SAML > > > > > federation are also either OAUTH2 resource or authorization servers. Today > > > > > all of those OAUTH2 entities have to be provisioned with separate client > > > > > secrets that have no relationship to the trust infrastructure already in use > > > > > in the federation. > > > > > > > > > > It is not uncommon for such federations to have 1000s and sometimes > > > > > 10000s of entities making client secret management something of a > > > > > scalability issue. > > > > > > > > > > Even with dynreg the problem of managing all of those client secrets > > > > > would still remain a *huge* (operational) security and scalability issue. > > > > > > > > > > There is therefore a desire among communities that have such deployments > > > > > to be able to re-use the key-management already in place for OAUTH2. > > > > > > > > > > Note that this example isn't tied to the SAML protocol at all. > > > > > > > > > > Leif > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > -------------- next part -------------- > > > > An HTML attachment was scrubbed... > > > > URL: > > > > > > > > ------------------------------ > > > > > > > > Message: 2 > > > > Date: Mon, 12 Nov 2012 22:12:40 +0100 > > > > From: Leif Johansson > > > > To: Phil Hunt > > > > Cc: oauth@ietf.org > > > > Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac" > > > > discussion > > > > Message-ID: <50A16648.1030604@mnt.se> > > > > Content-Type: text/plain; charset=ISO-8859-1 > > > > > > > > On 11/12/2012 10:09 PM, Phil Hunt wrote: > > > > > Leif, > > > > > > > > > > I've read this a couple of times and I think I'm getting lost in > > > > > partial SAML vs. OAuth terminology. As a result, I thought you were > > > > > saying: > > > > > > > > > > 1. It isn't practical to issue client credentials even with Dynamic > > > > > Registration > > > > > 2. You want to re-use key management already in place with OAuth2. > > > > > > > > > > These statements seem to be in conflict. Did you mean to say for > > > > > number 2 that you want to re-use key management already in place for SAML? > > > > > > > > > yep - "for" as in "for use by" > > > > > > > > > > > > ------------------------------ > > > > > > > > Message: 3 > > > > Date: Tue, 13 Nov 2012 10:19:24 -0500 > > > > From: Hannes Tschofenig > > > > To: "oauth@ietf.org WG" > > > > Subject: [OAUTH-WG] Review Volunteers > > > > Message-ID: <9ABA26C3-1B06-4D15-9268-5F75B20E941D@gmx.net> > > > > Content-Type: text/plain; charset=us-ascii > > > > > > > > We collected a number of action items last week. Here is my list > > > > > > > > 1. Token Revocation > > > > > > > > ACTION: Torsten to publish a draft update this week. > > > > > > > > ACTION: Volunteers to review the draft: > > > > - Amanda > > > > - Justin > > > > - Tony > > > > > > > > 2. draft-ietf-oauth-jwt-bearer > > > > > > > > ACTION: Justin to review JWT Bearer Token Profiles > > > > > > > > 3. OAuth Use Cases > > > > > > > > ACTION: Tony to work with Zachary on building out use cases and clarifying the audience of the doc. > > > > > > > > 4. JWT > > > > > > > > ACTION: Jeff Hodges, Klaas, and Leif to review the draft. > > > > > > > > 5. Security > > > > > > > > http://datatracker.ietf.org/doc/draft-tschofenig-oauth-security/ > > > > > > > > ACTION: working group to provide feedback on the requirements. > > > > > > > > 6. Dynamic Client Registration > > > > > > > > ACTION: Hannes to ask UMA folks to review the doc. > > > > ACTION: Nat, John, Torsten to review the doc. > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > Message: 4 > > > > Date: Tue, 13 Nov 2012 10:40:21 -0500 > > > > From: Hannes Tschofenig > > > > To: "oauth@ietf.org WG" > > > > Subject: [OAUTH-WG] Meeting Minutes > > > > Message-ID: > > > > Content-Type: text/plain; charset=us-ascii > > > > > > > > Hi all, > > > > > > > > please have a look at the meeting minutes from last week: > > > > http://www.ietf.org/proceedings/85/minutes/minutes-85-oauth > > > > > > > > Thanks to Amanda & Jean for taking notes. > > > > > > > > Ciao > > > > Hannes & Derek > > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > End of OAuth Digest, Vol 49, Issue 11 > > > > ************************************* > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: > > > > > > ------------------------------ > > > > > > Message: 2 > > > Date: Tue, 13 Nov 2012 15:33:26 -0800 > > > From: Michael Jones > > > To: , , > > > Cc: cfrg@irtf.org > > > Subject: [OAUTH-WG] Vacationing this week & e-mail address > > > Message-ID: > > > Content-Type: text/plain; charset="windows-1252" > > > > > > > > > > > > > > > > > > Hi all, I wanted to let you know that I'm vacationing this week, and so mostly won't be participating in discussions. I'll respond next week. Also, at present I?m using the e-mail address michael_b_jones@hotmail.com > > > to send e-mail to IETF mailing lists because currently I?m unable to send e-mail to any IETF lists using my normal > > > e-mail address Michael.Jones@microsoft.com. > > > When corresponding with me individually, it would be better to use the > > > Microsoft address, as the message is likely to be seen more quickly. Have a good week, everyone! -- Mike > > > > > > > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: > > > > > > ------------------------------ > > > > > > Message: 3 > > > Date: Wed, 14 Nov 2012 22:51:27 +0800 > > > From: dgq2011 > > > To: "oauth@ietf.org" > > > Subject: [OAUTH-WG] is OAuth protocol based on HTTP? > > > Message-ID: <201211142251220430822@gmail.com> > > > Content-Type: text/plain; charset="gb2312" > > > > > > Hi, all! It is said in RFC 6749 (The OAuth 2.0 Authorization Framework) that ?this specification is designed for use with HTTP ([RFC2616])? and ?The use of OAuth over any protocol other than HTTP is out of scope.? Do those statements mean that the communication between any two roles in OAuth protocol (namely resource owner, resource server, client and authorization server) is based on HTTP protocol? I am not familiar with the OAuth protocol and just would like to confirm this question. Any response is appreciated! > > > > > > > > > Best wishes? > > > Guangqing Deng > > > > > > > > > > > > dgq2011 > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > End of OAuth Digest, Vol 49, Issue 12 > > > ************************************* > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > > ------------------------------ > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > End of OAuth Digest, Vol 49, Issue 15 > > ************************************* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > End of OAuth Digest, Vol 49, Issue 16 > ************************************* ------=_Part_7212_535604041.1353246412143 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable get plain text

On November 18, 2012 5:44:25 AM PST, oauth-req= uest@ietf.org wrote:

If you have received this digest wit= hout all the individual message
attachments you will ne= ed to update your digest options in your list
subscript= ion.  To do so, go to

https:/= /www.ietf.org/mailman/listinfo/oauth

Click the 'Unsubscribe or edit options' button, log in, and set &quo= t;Get
MIME or Plain Text Digests?" to MIME.  = You can set this option
globally for all the list diges= ts you receive at this point.



Send OAuth mailing list submissions t= o
=09oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
=09oauth-request@ietf.org

Y= ou can reach the person managing the list at
=09oauth-o= wner@ietf.org

When replying, pleas= e edit your Subject line so it is more specific
than &q= uot;Re: Contents of OAuth digest..."


Today's Topics:

  1. Re: OAuth Digest, Vol 49, Issue 15 (Nichole Richards= on)


---------= -------------------------------------------------------------

Message: 1
Date: Sun, 18 No= v 2012 05:44:15 -0800
From: Nichole Richardson <nich= ole.richardson.27@facebook.com>
To: <oauth@ietf.o= rg>,  <oauth-request@ietf.org>
Subject: R= e: [OAUTH-WG] OAuth Digest, Vol 49, Issue 15
Message-ID= : <dff6e304647c36163b05b18af78cec9f@messages.facebook.com>
Content-Type: text/plain; charset=3D"utf-8"

help subscribe to oauth digest, Vol 49,Iss= ue 15

On November 18, 2012 5:27:18= AM PST, oauth-request@ietf.org wrote:
> If you have= received this digest without all the individual message
> attachments you will need to update your digest options in your list=
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo= /oauth
>
> Click the 'Un= subscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set thi= s option
> globally for all the list digests you rec= eive at this point.
>
>
>
> Send OAuth mailing list sub= missions to
> =09oauth@ietf.org
= >
> To subscribe or unsubscribe via the World Wi= de Web, visit
> =09https://www.ietf.org/mailman/listi= nfo/oauth
> or, via email, send a message with s= ubject or body 'help' to
> =09oauth-request@ietf.org=
>
> You can reach the perso= n managing the list at
> =09oauth-owner@ietf.org
>
> When replying, please edit = your Subject line so it is more specific
> than &quo= t;Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>    1. Re: OAuth Digest, Vol 49= , Issue 14 (Nichole Richardson)
>    2. Re= : OAuth Digest, Vol 49, Issue 12 (Nichole Richardson)
&= gt;
>
> -------------------= ---------------------------------------------------
>= ;
> Message: 1
> Date: Sun, = 18 Nov 2012 05:26:40 -0800
> From: Nichole Richardso= n <nichole.richardson.27@facebook.com>
> To: &= lt;oauth@ietf.org>,  <oauth-request@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 14
> Message-ID: <dacb75681fda6ccceb10caa6dc61d725@messages.= facebook.com>
> Content-Type: text/plain; charset= =3D"utf-8"
>
> hel= p
>
> On November 16, 2012 1= 2:00:14 PM PST, oauth-request@ietf.org wrote:
> >= If you have received this digest without all the individual message
> > attachments you will need to update your digest opt= ions in your list
> > subscription.  To do s= o, go to
> >
> > https= ://www.ietf.org/mailman/listinfo/oauth
> > > > Click the 'Unsubscribe or edit options' button= , log in, and set "Get
> > MIME or Plain Tex= t Digests?" to MIME.  You can set this option
> > globally for all the list digests you receive at this point.
> >
> >
> >
> > Send OAuth mailing list submis= sions to
> > =09oauth@ietf.org
> >
> > To subscribe or unsubscribe via = the World Wide Web, visit
> > =09https://www.ietf.= org/mailman/listinfo/oauth
> > or, via email,= send a message with subject or body 'help' to
> >= ; =09oauth-request@ietf.org
> >
> > You can reach the person managing the list at
> > =09oauth-owner@ietf.org
> >
> > When replying, please edit your Subject line so it= is more specific
> > than "Re: Contents of = OAuth digest..."
> >
&g= t; >
> > Today's Topics:
= > >
> >    1. Question related t= o OAuth access token (Security Developer)
> > > >
> > ----------------= ------------------------------------------------------
= > >
> > Message: 1
>= ; > Date: Fri, 16 Nov 2012 01:03:16 +0500
> > = From: Security Developer <security.developer22@gmail.com>
> > To: OAuth@ietf.org
> > Subject= : [OAUTH-WG] Question related to OAuth access token
>= ; > Message-ID:
> > =09<CAD-drXstwtoAtd=3Dv= z43mOpLjNRTjisYWoYUOWuE3mdU_9r3n_A@mail.gmail.com>
&= gt; > Content-Type: text/plain; charset=3D"iso-8859-1"
> >
> > Hi,
> >
> > If an access token is either SA= ML or JWT in OAuth then what would be the
> > val= ue in subject either resource owner or client application name?
> >
> > Thanks for your time.
> >
> > Regards,
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
>= ; > URL: <http://www.ietf.= org/mail-archive/web/oauth/attachments/20121116/258a14c4/attachment.htm= >
> >
> > ---------= ---------------------
> >
&g= t; > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org<= br clear=3D'none' />> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > End of OAuth Digest, Vol 49, Issue 14
> > *************************************
> = -------------- next part --------------
> An HTML at= tachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/oauth/attac= hments/20121118/cea4d9c7/attachment.htm>
> > ------------------------------
= >
> Message: 2
> Date: Su= n, 18 Nov 2012 05:27:15 -0800
> From: Nichole Richar= dson <nichole.richardson.27@facebook.com>
> To= : <oauth@ietf.org>,  <oauth-request@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 12
> Message-ID: <b3bcaf3b2487b7eebc3c8ecbde1843a9@messages= .facebook.com>
> Content-Type: text/plain; charse= t=3D"utf-8"
>
> he= lp
>
>
= > On November 14, 2012 6:51:40 AM PST, oauth-request@ietf.org wrote:
> > If you have received this digest without all the= individual message
> > attachments you will need= to update your digest options in your list
> > s= ubscription.  To do so, go to
> >
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> > Click the 'Unsubscri= be or edit options' button, log in, and set "Get
&= gt; > MIME or Plain Text Digests?" to MIME.  You can set this = option
> > globally for all the list digests you = receive at this point.
> >
&= gt; >
> >
> > Send= OAuth mailing list submissions to
> > =09oauth@i= etf.org
> >
> > To sub= scribe or unsubscribe via the World Wide Web, visit
>= ; > =09https://www.ietf.org/mailman/listinfo/oauth
> > or, via email, send a message with subject or body 'help' to> > =09oauth-request@ietf.org
&= gt; >
> > You can reach the person managing t= he list at
> > =09oauth-owner@ietf.org
> >
> > When replying, please = edit your Subject line so it is more specific
> >= than "Re: Contents of OAuth digest..."
> = >
> >
> > Today's = Topics:
> >
> >  =  1. Re: OAuth Digest, Vol 49, Issue 11 (Nichole Richardson)
> >    2. Vacationing this week & e-mail ad= dress (Michael Jones)
> >    3. is OAut= h protocol based on HTTP? (dgq2011)
> >
> >
> > ----------------------= ------------------------------------------------
> &= gt;
> > Message: 1
> >= Date: Tue, 13 Nov 2012 14:31:11 -0800
> > From: = Nichole Richardson <nichole.richardson.27@facebook.com>
> > To: <oauth@ietf.org>,  <oauth-request@ietf.o= rg>
> > Subject: Re: [OAUTH-WG] OAuth Digest, = Vol 49, Issue 11
> > Message-ID: <a8044d50234c= 082dcb53112e4b433fcb@messages.facebook.com>
> >= ; Content-Type: text/plain; charset=3D"utf-8"
> >
> > get mime
>= >
> > On November 13, 2012 12:00:08 PM PST, = oauth-request@ietf.org wrote:
> > > If you hav= e received this digest without all the individual message
> > > attachments you will need to update your digest options i= n your list
> > > subscription.  To do so= , go to
> > >
> > = > https://www.ietf.org/mailman/listinfo/oauth
>= ; > >
> > > Click the 'Unsubscribe or e= dit options' button, log in, and set "Get
> >= ; > MIME or Plain Text Digests?" to MIME.  You can set this op= tion
> > > globally for all the list digests y= ou receive at this point.
> > >
> > >
> > >
> > > Send OAuth mailing list submissions to
> > > =09oauth@ietf.org
> > >
> > > To subscribe or unsubscribe via the World W= ide Web, visit
> > > =09https://www.ietf.org/ma= ilman/listinfo/oauth
> > > or, via email, = send a message with subject or body 'help' to
> >= > =09oauth-request@ietf.org
> > >
> > > You can reach the person managing the list at> > > =09oauth-owner@ietf.org
> > >
> > > When replying, please= edit your Subject line so it is more specific
> >= ; > than "Re: Contents of OAuth digest..."
> > >
> > >
&g= t; > > Today's Topics:
> > >
> > >    1. Re: bag-of-keys metadata UC for = the "mac" discussion (Phil Hunt)
> > &g= t;    2. Re: bag-of-keys metadata UC for the "mac" disc= ussion
> > >       (Leif Johans= son)
> > >    3. Review Volunteers (= Hannes Tschofenig)
> > >    4. Meeti= ng Minutes (Hannes Tschofenig)
> > >
> > >
> > > ------------= ----------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Mon, 12 Nov 2012 13:09:11 -0800
> > > From: Phil Hunt <phil.hunt@oracle.com>
> > > To: Leif Johansson <leifj@mnt.se>
> > > Cc: oauth@ietf.org
>= > > Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "ma= c"
> > > =09discussion
> > > Message-ID: <7EF786E1-18E2-4974-A6BC-2C72BE9F5C11@oracl= e.com>
> > > Content-Type: text/plain; char= set=3D"iso-8859-1"
> > >
> > > Leif,
> > >
> > > I've read this a couple of times and I think I= 'm getting lost in partial SAML vs. OAuth terminology. As a result, I thoug= ht you were saying:
> > >
> > > 1. It isn't practical to issue client credentials even with= Dynamic Registration
> > > 2. You want to re-= use key management already in place with OAuth2.
> &= gt; >
> > > These statements seem to be in= conflict.  Did you mean to say for number 2 that you want to re-use k= ey management already in place for SAML?
> > >=
> > > Phil
> > >= ;
> > > @independentid
&g= t; > > www.independentid.com
> > > phil.= hunt@oracle.com
> > >
>= ; > >
> > >
> &= gt; >
> > >
> >= > On 2012-11-08, at 8:01 AM, Leif Johansson wrote:
= > > >
> > > > I promised to send = a UC to the list as input to the discussion around new
= > > > > token formats.
> > > > =
> > > > ---
> > = > >
> > > > Several large-scale depl= oyments of public-key use a "bag-of-keys" model
> > > > for key management: you stick endpoint information t= ogether with public
> > > > keys for those = endpoints in a signable container which is then signed with
> > > > a private key associated with some "trust pro= vider" an distributed to all
> > > > e= ntities/relying parties.
> > > >
> > > > Examples include various trust status lists= formats and things like SAML
> > > > metad= ata.
> > > >
> >= > > The latter case (SAML metadata) isn't necessarily tied to the SA= ML v2
> > > > _protocol_ but it is used for= that. Large-scale SAML federations are often
> >= > > setup to depend on distribution of signed SAML metadata.
> > > >
> > > > C= onsider the case when a large number of relying parties of such a SAML
> > > > federation are also either OAUTH2 resou= rce or authorization servers. Today
> > > >= all of those OAUTH2 entities have to be provisioned with separate client> > > > secrets that have no relationship to= the trust infrastructure already in use
> > >= > in the federation.
> > > >
> > > > It is not uncommon for such federations to = have 1000s and sometimes
> > > > 10000s of = entities making client secret management something of a
> > > > scalability issue.
> > > = >
> > > > Even with dynreg the problem = of managing all of those client secrets
> > > = > would still remain a *huge* (operational) security and scalability iss= ue.
> > > >
> > = > > There is therefore a desire among communities that have such depl= oyments
> > > > to be able to re-use the ke= y-management already in place for OAUTH2.
> > >= ; >
> > > > Note that this example isn'= t tied to the SAML protocol at all.
> > > >=
> > > >         Leif<= br clear=3D'none' />> > > > ___________________________________= ____________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
>= ; > > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> > > -------------- = next part --------------
> > > An HTML attachm= ent was scrubbed...
> > > URL: <http://www.ietf.org/mail-archive/web/oauth/= attachments/20121112/ede07590/attachment.htm>
&g= t; > >
> > > --------------------------= ----
> > >
> > >= Message: 2
> > > Date: Mon, 12 Nov 2012 22:12= :40 +0100
> > > From: Leif Johansson <leifj= @mnt.se>
> > > To: Phil Hunt <phil.hunt@= oracle.com>
> > > Cc: oauth@ietf.org
> > > Subject: Re: [OAUTH-WG] bag-of-keys metadata U= C for the "mac"
> > > =09discussion<= br clear=3D'none' />> > > Message-ID: <50A16648.1030604@mnt.se&= gt;
> > > Content-Type: text/plain; charset=3D= ISO-8859-1
> > >
> >= ; > On 11/12/2012 10:09 PM, Phil Hunt wrote:
> &g= t; > > Leif,
> > > >
> > > > I've read this a couple of times and I think I'm ge= tting lost in
> > > > partial SAML vs. OAut= h terminology. As a result, I thought you were
> >= ; > > saying:
> > > >
> > > > 1. It isn't practical to issue client credentials = even with Dynamic
> > > > Registration
> > > > 2. You want to re-use key management al= ready in place with OAuth2.
> > > >
> > > > These statements seem to be in conflict. &= nbsp;Did you mean to say for
> > > > number= 2 that you want to re-use key management already in place for SAML?
> > > >
> > > yep - = "for" as in "for use by"
> > = >
> > >
> > >= ; ------------------------------
> > >
> > > Message: 3
> > > = Date: Tue, 13 Nov 2012 10:19:24 -0500
> > > Fr= om: Hannes Tschofenig <hannes.tschofenig@gmx.net>
> > > To: "oauth@ietf.org WG" <oauth@ietf.org>> > > Subject: [OAUTH-WG] Review Volunteers
> > > Message-ID: <9ABA26C3-1B06-4D15-9268-5F75= B20E941D@gmx.net>
> > > Content-Type: text/= plain; charset=3Dus-ascii
> > >
> > > We collected a number of action items last week. Here= is my list
> > >
> &g= t; > 1. Token Revocation
> > >
> > > ACTION: Torsten to publish a draft update this week= .
> > >
> > > A= CTION: Volunteers to review the draft:
> > > -= Amanda
> > > - Justin
&g= t; > > - Tony
> > >
> > > 2. draft-ietf-oauth-jwt-bearer
> >= ; >
> > > ACTION: Justin to review JWT Bea= rer Token Profiles
> > >
= > > > 3. OAuth Use Cases
> > >
> > > ACTION: Tony to work with Zachary on buildin= g out use cases and clarifying the audience of the doc.
> > >
> > > 4. JWT
> > >
> > > ACTION: Jeff Hodges,= Klaas, and Leif to review the draft.
> > > > > > 5. Security
> >= >
> > > http://datatr= acker.ietf.org/doc/draft-tschofenig-oauth-security/
> > >
> > > ACTION: working group t= o provide feedback on the requirements.
> > >=
> > > 6. Dynamic Client Registration
> > >
> > > ACTION: Ha= nnes to ask UMA folks to review the doc.
> > >= ; ACTION: Nat, John, Torsten to review the doc.
> &= gt; >
> > >
> >= >
> > >
> > &g= t;
> > > ------------------------------
> > >
> > > Message: = 4
> > > Date: Tue, 13 Nov 2012 10:40:21 -0500<= br clear=3D'none' />> > > From: Hannes Tschofenig <hannes.tscho= fenig@gmx.net>
> > > To: "oauth@ietf.o= rg WG" <oauth@ietf.org>
> > > Subje= ct: [OAUTH-WG] Meeting Minutes
> > > Message-I= D: <F640899A-B4E4-40B4-B961-64199C600AAD@gmx.net>
> > > Content-Type: text/plain; charset=3Dus-ascii
> > >
> > > Hi all,
> > >
> > > please have = a look at the meeting minutes from last week:
> >= > http://www.ietf.org/proceedings/85/minutes/minutes-85-= oauth
> > >
> >= > Thanks to Amanda & Jean for taking notes.
&g= t; > >
> > > Ciao
&= gt; > > Hannes & Derek
> > >
> > >
> > >
> > > ------------------------------
> > >
> > > _____________________= __________________________
> > > OAuth mailing= list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> > >
> > > End of OAuth Digest, Vol 49, Issue 11
> > > *************************************
> > -------------- next part --------------
>= > An HTML attachment was scrubbed...
> > URL:= <http://www.ietf.org/mail-ar= chive/web/oauth/attachments/20121113/d4752114/attachment.htm>
> >
> > --------------------= ----------
> >
> > Mes= sage: 2
> > Date: Tue, 13 Nov 2012 15:33:26 -0800=
> > From: Michael Jones <michael_b_jones@hotm= ail.com>
> > To: <jose@ietf.org>, <oa= uth@ietf.org>, <apps-discuss@ietf.org>
> &g= t; Cc: cfrg@irtf.org
> > Subject: [OAUTH-WG] Vaca= tioning this week & e-mail address
> > Messag= e-ID: <BAY171-W4767242AC702446BF30539B76C0@phx.gbl>
> > Content-Type: text/plain; charset=3D"windows-1252"> >
> >
> >
> >
> &g= t;
> > Hi all, I wanted to let you know that I'm= vacationing this week, and so mostly won't be participating in discussions= .  I'll respond next week. Also, at present I?m using the e-mail addre= ss michael_b_jones@hotmail.com
> > to send e-mail= to IETF mailing lists because currently I?m unable to send e-mail to any I= ETF lists using my normal
> > e-mail address Mich= ael.Jones@microsoft.com.
> > When corresponding = with me individually, it would be better to use the
>= ; > Microsoft address, as the message is likely to be seen more quickly.= Have a good week, everyone! -- Mike
> >
> >  =09=09 =09   =09=09  
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> >= ; URL: <http://www.ietf.org/m= ail-archive/web/oauth/attachments/20121113/8b3a4b36/attachment.htm><= br clear=3D'none' />> >
> > --------------= ----------------
> >
> &g= t; Message: 3
> > Date: Wed, 14 Nov 2012 22:51:27= +0800
> > From: dgq2011 <dgq2011@gmail.com>= ;
> > To: "oauth@ietf.org" <oauth@ie= tf.org>
> > Subject: [OAUTH-WG] is OAuth proto= col based on HTTP?
> > Message-ID: <2012111422= 51220430822@gmail.com>
> > Content-Type: text/= plain; charset=3D"gb2312"
> >
> > Hi, all! It is said in RFC 6749 (The OAuth 2.0 Author= ization Framework) that ?this specification is designed for use with HTTP (= [RFC2616])? and ?The use of OAuth over any protocol other than HTTP is out = of scope.? Do those statements mean that the communication between any two = roles in OAuth protocol (namely resource owner, resource server, client and= authorization server) is based on HTTP protocol? I am not familiar with th= e OAuth protocol and just would like to confirm this question. Any response= is appreciated!
> >
> &g= t;
> > Best wishes?
> >= ; Guangqing Deng
> >
> &g= t;
> >
> > dgq2011> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <http://www= .ietf.org/mail-archive/web/oauth/attachments/20121114/e1240784/attachment.h= tm>
> >
> > ---= ---------------------------
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@iet= f.org
> > https://www.ietf.org/mailman/listinfo/oa= uth
> >
> >
> > End of OAuth Digest, Vol 49, Issue 12
> > *************************************
> -------------- next part --------------
> An H= TML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/oauth= /attachments/20121118/05fa82f1/attachment.htm>
&= gt;
> ------------------------------
>
> ______________________________________= _________
> OAuth mailing list
&= gt; OAuth@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/oauth
>
>
> End of OAuth Digest, Vol 49, Issue 15
> *************************************
-----------= --- next part --------------
An HTML attachment was scr= ubbed...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20121118/3ded9= 254/attachment.htm>

-------= -----------------------

__________= _____________________________________
OAuth mailing lis= t
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth


End of OAuth Digest, Vol 49, Issue 16
*= ************************************
------=_Part_7212_535604041.1353246412143-- From nichole.richardson.27@facebook.com Sun Nov 18 05:48:08 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DA121F84CC for ; Sun, 18 Nov 2012 05:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.732 X-Spam-Level: X-Spam-Status: No, score=-101.732 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd-AjrVAMBIf for ; Sun, 18 Nov 2012 05:48:05 -0800 (PST) Received: from smtpout.mx.facebook.com (smtpout003.ash3.facebook.com [69.171.244.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5CB21F84C2 for ; Sun, 18 Nov 2012 05:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=facebook.com; s=s1024-2010-q3; c=relaxed/simple; q=dns/txt; i=@facebook.com; t=1353246485; h=From:Subject:X-:Date:To:MIME-Version:Content-Type; bh=BJdD+RMfyls32BepaXX7MeSiEfzInbb59CJs4asjBm0=; b=VHfBiomB0T2pbVY+YWN5hc1hkF3ix7q41iGWxLJZ6MmtuFA85D4GsO/K2zxtIs+L Bidnr2EwoH02Olriw+j7IOFmf+vsXzjMLX2GqTDlDiuKDTGb8uTeEauiw6UodfJX YjrdDQH6WOK/GbxR7p5VEqql5t99tsjhgc3K8opRGFU=; Received: from [10.148.86.69] ([10.148.86.69:43580] helo=www.facebook.com) by 10.148.131.59 (envelope-from ) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id 24/FA-26344-517E8A05; Sun, 18 Nov 2012 05:48:05 -0800 Date: Sun, 18 Nov 2012 05:48:05 -0800 From: Nichole Richardson To: , Message-ID: <120289d8b362be09a5d8bd8dfda53c80@messages.facebook.com> In-Reply-To: References: , MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7213_817419805.1353246485050" Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 13:48:08 -0000 ------=_Part_7213_817419805.1353246485050 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit get plain text On November 18, 2012 5:44:25 AM PST, oauth-request@ietf.org wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/oauth > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: OAuth Digest, Vol 49, Issue 15 (Nichole Richardson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 18 Nov 2012 05:44:15 -0800 > From: Nichole Richardson > To: , > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 15 > Message-ID: > Content-Type: text/plain; charset="utf-8" > > help subscribe to oauth digest, Vol 49,Issue 15 > > On November 18, 2012 5:27:18 AM PST, oauth-request@ietf.org wrote: > > If you have received this digest without all the individual message > > attachments you will need to update your digest options in your list > > subscription. To do so, go to > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > MIME or Plain Text Digests?" to MIME. You can set this option > > globally for all the list digests you receive at this point. > > > > > > > > Send OAuth mailing list submissions to > > oauth@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/oauth > > or, via email, send a message with subject or body 'help' to > > oauth-request@ietf.org > > > > You can reach the person managing the list at > > oauth-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of OAuth digest..." > > > > > > Today's Topics: > > > > 1. Re: OAuth Digest, Vol 49, Issue 14 (Nichole Richardson) > > 2. Re: OAuth Digest, Vol 49, Issue 12 (Nichole Richardson) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Sun, 18 Nov 2012 05:26:40 -0800 > > From: Nichole Richardson > > To: , > > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 14 > > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > > > help > > > > On November 16, 2012 12:00:14 PM PST, oauth-request@ietf.org wrote: > > > If you have received this digest without all the individual message > > > attachments you will need to update your digest options in your list > > > subscription. To do so, go to > > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > > MIME or Plain Text Digests?" to MIME. You can set this option > > > globally for all the list digests you receive at this point. > > > > > > > > > > > > Send OAuth mailing list submissions to > > > oauth@ietf.org > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://www.ietf.org/mailman/listinfo/oauth > > > or, via email, send a message with subject or body 'help' to > > > oauth-request@ietf.org > > > > > > You can reach the person managing the list at > > > oauth-owner@ietf.org > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of OAuth digest..." > > > > > > > > > Today's Topics: > > > > > > 1. Question related to OAuth access token (Security Developer) > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Fri, 16 Nov 2012 01:03:16 +0500 > > > From: Security Developer > > > To: OAuth@ietf.org > > > Subject: [OAUTH-WG] Question related to OAuth access token > > > Message-ID: > > > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > Hi, > > > > > > If an access token is either SAML or JWT in OAuth then what would be the > > > value in subject either resource owner or client application name? > > > > > > Thanks for your time. > > > > > > Regards, > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > End of OAuth Digest, Vol 49, Issue 14 > > > ************************************* > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > > ------------------------------ > > > > Message: 2 > > Date: Sun, 18 Nov 2012 05:27:15 -0800 > > From: Nichole Richardson > > To: , > > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 12 > > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > > > help > > > > > > On November 14, 2012 6:51:40 AM PST, oauth-request@ietf.org wrote: > > > If you have received this digest without all the individual message > > > attachments you will need to update your digest options in your list > > > subscription. To do so, go to > > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > > MIME or Plain Text Digests?" to MIME. You can set this option > > > globally for all the list digests you receive at this point. > > > > > > > > > > > > Send OAuth mailing list submissions to > > > oauth@ietf.org > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://www.ietf.org/mailman/listinfo/oauth > > > or, via email, send a message with subject or body 'help' to > > > oauth-request@ietf.org > > > > > > You can reach the person managing the list at > > > oauth-owner@ietf.org > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of OAuth digest..." > > > > > > > > > Today's Topics: > > > > > > 1. Re: OAuth Digest, Vol 49, Issue 11 (Nichole Richardson) > > > 2. Vacationing this week & e-mail address (Michael Jones) > > > 3. is OAuth protocol based on HTTP? (dgq2011) > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Tue, 13 Nov 2012 14:31:11 -0800 > > > From: Nichole Richardson > > > To: , > > > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 11 > > > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > > > > > get mime > > > > > > On November 13, 2012 12:00:08 PM PST, oauth-request@ietf.org wrote: > > > > If you have received this digest without all the individual message > > > > attachments you will need to update your digest options in your list > > > > subscription. To do so, go to > > > > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > > > MIME or Plain Text Digests?" to MIME. You can set this option > > > > globally for all the list digests you receive at this point. > > > > > > > > > > > > > > > > Send OAuth mailing list submissions to > > > > oauth@ietf.org > > > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > or, via email, send a message with subject or body 'help' to > > > > oauth-request@ietf.org > > > > > > > > You can reach the person managing the list at > > > > oauth-owner@ietf.org > > > > > > > > When replying, please edit your Subject line so it is more specific > > > > than "Re: Contents of OAuth digest..." > > > > > > > > > > > > Today's Topics: > > > > > > > > 1. Re: bag-of-keys metadata UC for the "mac" discussion (Phil Hunt) > > > > 2. Re: bag-of-keys metadata UC for the "mac" discussion > > > > (Leif Johansson) > > > > 3. Review Volunteers (Hannes Tschofenig) > > > > 4. Meeting Minutes (Hannes Tschofenig) > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > Message: 1 > > > > Date: Mon, 12 Nov 2012 13:09:11 -0800 > > > > From: Phil Hunt > > > > To: Leif Johansson > > > > Cc: oauth@ietf.org > > > > Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac" > > > > discussion > > > > Message-ID: <7EF786E1-18E2-4974-A6BC-2C72BE9F5C11@oracle.com> > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > > > Leif, > > > > > > > > I've read this a couple of times and I think I'm getting lost in partial SAML vs. OAuth terminology. As a result, I thought you were saying: > > > > > > > > 1. It isn't practical to issue client credentials even with Dynamic Registration > > > > 2. You want to re-use key management already in place with OAuth2. > > > > > > > > These statements seem to be in conflict. Did you mean to say for number 2 that you want to re-use key management already in place for SAML? > > > > > > > > Phil > > > > > > > > @independentid > > > > www.independentid.com > > > > phil.hunt@oracle.com > > > > > > > > > > > > > > > > > > > > > > > > On 2012-11-08, at 8:01 AM, Leif Johansson wrote: > > > > > > > > > I promised to send a UC to the list as input to the discussion around new > > > > > token formats. > > > > > > > > > > --- > > > > > > > > > > Several large-scale deployments of public-key use a "bag-of-keys" model > > > > > for key management: you stick endpoint information together with public > > > > > keys for those endpoints in a signable container which is then signed with > > > > > a private key associated with some "trust provider" an distributed to all > > > > > entities/relying parties. > > > > > > > > > > Examples include various trust status lists formats and things like SAML > > > > > metadata. > > > > > > > > > > The latter case (SAML metadata) isn't necessarily tied to the SAML v2 > > > > > _protocol_ but it is used for that. Large-scale SAML federations are often > > > > > setup to depend on distribution of signed SAML metadata. > > > > > > > > > > Consider the case when a large number of relying parties of such a SAML > > > > > federation are also either OAUTH2 resource or authorization servers. Today > > > > > all of those OAUTH2 entities have to be provisioned with separate client > > > > > secrets that have no relationship to the trust infrastructure already in use > > > > > in the federation. > > > > > > > > > > It is not uncommon for such federations to have 1000s and sometimes > > > > > 10000s of entities making client secret management something of a > > > > > scalability issue. > > > > > > > > > > Even with dynreg the problem of managing all of those client secrets > > > > > would still remain a *huge* (operational) security and scalability issue. > > > > > > > > > > There is therefore a desire among communities that have such deployments > > > > > to be able to re-use the key-management already in place for OAUTH2. > > > > > > > > > > Note that this example isn't tied to the SAML protocol at all. > > > > > > > > > > Leif > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > -------------- next part -------------- > > > > An HTML attachment was scrubbed... > > > > URL: > > > > > > > > ------------------------------ > > > > > > > > Message: 2 > > > > Date: Mon, 12 Nov 2012 22:12:40 +0100 > > > > From: Leif Johansson > > > > To: Phil Hunt > > > > Cc: oauth@ietf.org > > > > Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "mac" > > > > discussion > > > > Message-ID: <50A16648.1030604@mnt.se> > > > > Content-Type: text/plain; charset=ISO-8859-1 > > > > > > > > On 11/12/2012 10:09 PM, Phil Hunt wrote: > > > > > Leif, > > > > > > > > > > I've read this a couple of times and I think I'm getting lost in > > > > > partial SAML vs. OAuth terminology. As a result, I thought you were > > > > > saying: > > > > > > > > > > 1. It isn't practical to issue client credentials even with Dynamic > > > > > Registration > > > > > 2. You want to re-use key management already in place with OAuth2. > > > > > > > > > > These statements seem to be in conflict. Did you mean to say for > > > > > number 2 that you want to re-use key management already in place for SAML? > > > > > > > > > yep - "for" as in "for use by" > > > > > > > > > > > > ------------------------------ > > > > > > > > Message: 3 > > > > Date: Tue, 13 Nov 2012 10:19:24 -0500 > > > > From: Hannes Tschofenig > > > > To: "oauth@ietf.org WG" > > > > Subject: [OAUTH-WG] Review Volunteers > > > > Message-ID: <9ABA26C3-1B06-4D15-9268-5F75B20E941D@gmx.net> > > > > Content-Type: text/plain; charset=us-ascii > > > > > > > > We collected a number of action items last week. Here is my list > > > > > > > > 1. Token Revocation > > > > > > > > ACTION: Torsten to publish a draft update this week. > > > > > > > > ACTION: Volunteers to review the draft: > > > > - Amanda > > > > - Justin > > > > - Tony > > > > > > > > 2. draft-ietf-oauth-jwt-bearer > > > > > > > > ACTION: Justin to review JWT Bearer Token Profiles > > > > > > > > 3. OAuth Use Cases > > > > > > > > ACTION: Tony to work with Zachary on building out use cases and clarifying the audience of the doc. > > > > > > > > 4. JWT > > > > > > > > ACTION: Jeff Hodges, Klaas, and Leif to review the draft. > > > > > > > > 5. Security > > > > > > > > http://datatracker.ietf.org/doc/draft-tschofenig-oauth-security/ > > > > > > > > ACTION: working group to provide feedback on the requirements. > > > > > > > > 6. Dynamic Client Registration > > > > > > > > ACTION: Hannes to ask UMA folks to review the doc. > > > > ACTION: Nat, John, Torsten to review the doc. > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > Message: 4 > > > > Date: Tue, 13 Nov 2012 10:40:21 -0500 > > > > From: Hannes Tschofenig > > > > To: "oauth@ietf.org WG" > > > > Subject: [OAUTH-WG] Meeting Minutes > > > > Message-ID: > > > > Content-Type: text/plain; charset=us-ascii > > > > > > > > Hi all, > > > > > > > > please have a look at the meeting minutes from last week: > > > > http://www.ietf.org/proceedings/85/minutes/minutes-85-oauth > > > > > > > > Thanks to Amanda & Jean for taking notes. > > > > > > > > Ciao > > > > Hannes & Derek > > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > End of OAuth Digest, Vol 49, Issue 11 > > > > ************************************* > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: > > > > > > ------------------------------ > > > > > > Message: 2 > > > Date: Tue, 13 Nov 2012 15:33:26 -0800 > > > From: Michael Jones > > > To: , , > > > Cc: cfrg@irtf.org > > > Subject: [OAUTH-WG] Vacationing this week & e-mail address > > > Message-ID: > > > Content-Type: text/plain; charset="windows-1252" > > > > > > > > > > > > > > > > > > Hi all, I wanted to let you know that I'm vacationing this week, and so mostly won't be participating in discussions. I'll respond next week. Also, at present I?m using the e-mail address michael_b_jones@hotmail.com > > > to send e-mail to IETF mailing lists because currently I?m unable to send e-mail to any IETF lists using my normal > > > e-mail address Michael.Jones@microsoft.com. > > > When corresponding with me individually, it would be better to use the > > > Microsoft address, as the message is likely to be seen more quickly. Have a good week, everyone! -- Mike > > > > > > > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: > > > > > > ------------------------------ > > > > > > Message: 3 > > > Date: Wed, 14 Nov 2012 22:51:27 +0800 > > > From: dgq2011 > > > To: "oauth@ietf.org" > > > Subject: [OAUTH-WG] is OAuth protocol based on HTTP? > > > Message-ID: <201211142251220430822@gmail.com> > > > Content-Type: text/plain; charset="gb2312" > > > > > > Hi, all! It is said in RFC 6749 (The OAuth 2.0 Authorization Framework) that ?this specification is designed for use with HTTP ([RFC2616])? and ?The use of OAuth over any protocol other than HTTP is out of scope.? Do those statements mean that the communication between any two roles in OAuth protocol (namely resource owner, resource server, client and authorization server) is based on HTTP protocol? I am not familiar with the OAuth protocol and just would like to confirm this question. Any response is appreciated! > > > > > > > > > Best wishes? > > > Guangqing Deng > > > > > > > > > > > > dgq2011 > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > End of OAuth Digest, Vol 49, Issue 12 > > > ************************************* > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > > ------------------------------ > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > End of OAuth Digest, Vol 49, Issue 15 > > ************************************* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > End of OAuth Digest, Vol 49, Issue 16 > ************************************* ------=_Part_7213_817419805.1353246485050 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable get plain text

On November 18, 2012 5:44:25 AM PST, oauth-req= uest@ietf.org wrote:

If you have received this digest wit= hout all the individual message
attachments you will ne= ed to update your digest options in your list
subscript= ion.  To do so, go to

https:/= /www.ietf.org/mailman/listinfo/oauth

Click the 'Unsubscribe or edit options' button, log in, and set &quo= t;Get
MIME or Plain Text Digests?" to MIME.  = You can set this option
globally for all the list diges= ts you receive at this point.



Send OAuth mailing list submissions t= o
=09oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
=09oauth-request@ietf.org

Y= ou can reach the person managing the list at
=09oauth-o= wner@ietf.org

When replying, pleas= e edit your Subject line so it is more specific
than &q= uot;Re: Contents of OAuth digest..."


Today's Topics:

  1. Re: OAuth Digest, Vol 49, Issue 15 (Nichole Richards= on)


---------= -------------------------------------------------------------

Message: 1
Date: Sun, 18 No= v 2012 05:44:15 -0800
From: Nichole Richardson <nich= ole.richardson.27@facebook.com>
To: <oauth@ietf.o= rg>,  <oauth-request@ietf.org>
Subject: R= e: [OAUTH-WG] OAuth Digest, Vol 49, Issue 15
Message-ID= : <dff6e304647c36163b05b18af78cec9f@messages.facebook.com>
Content-Type: text/plain; charset=3D"utf-8"

help subscribe to oauth digest, Vol 49,Iss= ue 15

On November 18, 2012 5:27:18= AM PST, oauth-request@ietf.org wrote:
> If you have= received this digest without all the individual message
> attachments you will need to update your digest options in your list=
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo= /oauth
>
> Click the 'Un= subscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set thi= s option
> globally for all the list digests you rec= eive at this point.
>
>
>
> Send OAuth mailing list sub= missions to
> =09oauth@ietf.org
= >
> To subscribe or unsubscribe via the World Wi= de Web, visit
> =09https://www.ietf.org/mailman/listi= nfo/oauth
> or, via email, send a message with s= ubject or body 'help' to
> =09oauth-request@ietf.org=
>
> You can reach the perso= n managing the list at
> =09oauth-owner@ietf.org
>
> When replying, please edit = your Subject line so it is more specific
> than &quo= t;Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>    1. Re: OAuth Digest, Vol 49= , Issue 14 (Nichole Richardson)
>    2. Re= : OAuth Digest, Vol 49, Issue 12 (Nichole Richardson)
&= gt;
>
> -------------------= ---------------------------------------------------
>= ;
> Message: 1
> Date: Sun, = 18 Nov 2012 05:26:40 -0800
> From: Nichole Richardso= n <nichole.richardson.27@facebook.com>
> To: &= lt;oauth@ietf.org>,  <oauth-request@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 14
> Message-ID: <dacb75681fda6ccceb10caa6dc61d725@messages.= facebook.com>
> Content-Type: text/plain; charset= =3D"utf-8"
>
> hel= p
>
> On November 16, 2012 1= 2:00:14 PM PST, oauth-request@ietf.org wrote:
> >= If you have received this digest without all the individual message
> > attachments you will need to update your digest opt= ions in your list
> > subscription.  To do s= o, go to
> >
> > https= ://www.ietf.org/mailman/listinfo/oauth
> > > > Click the 'Unsubscribe or edit options' button= , log in, and set "Get
> > MIME or Plain Tex= t Digests?" to MIME.  You can set this option
> > globally for all the list digests you receive at this point.
> >
> >
> >
> > Send OAuth mailing list submis= sions to
> > =09oauth@ietf.org
> >
> > To subscribe or unsubscribe via = the World Wide Web, visit
> > =09https://www.ietf.= org/mailman/listinfo/oauth
> > or, via email,= send a message with subject or body 'help' to
> >= ; =09oauth-request@ietf.org
> >
> > You can reach the person managing the list at
> > =09oauth-owner@ietf.org
> >
> > When replying, please edit your Subject line so it= is more specific
> > than "Re: Contents of = OAuth digest..."
> >
&g= t; >
> > Today's Topics:
= > >
> >    1. Question related t= o OAuth access token (Security Developer)
> > > >
> > ----------------= ------------------------------------------------------
= > >
> > Message: 1
>= ; > Date: Fri, 16 Nov 2012 01:03:16 +0500
> > = From: Security Developer <security.developer22@gmail.com>
> > To: OAuth@ietf.org
> > Subject= : [OAUTH-WG] Question related to OAuth access token
>= ; > Message-ID:
> > =09<CAD-drXstwtoAtd=3Dv= z43mOpLjNRTjisYWoYUOWuE3mdU_9r3n_A@mail.gmail.com>
&= gt; > Content-Type: text/plain; charset=3D"iso-8859-1"
> >
> > Hi,
> >
> > If an access token is either SA= ML or JWT in OAuth then what would be the
> > val= ue in subject either resource owner or client application name?
> >
> > Thanks for your time.
> >
> > Regards,
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
>= ; > URL: <http://www.ietf.= org/mail-archive/web/oauth/attachments/20121116/258a14c4/attachment.htm= >
> >
> > ---------= ---------------------
> >
&g= t; > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org<= br clear=3D'none' />> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > End of OAuth Digest, Vol 49, Issue 14
> > *************************************
> = -------------- next part --------------
> An HTML at= tachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/oauth/attac= hments/20121118/cea4d9c7/attachment.htm>
> > ------------------------------
= >
> Message: 2
> Date: Su= n, 18 Nov 2012 05:27:15 -0800
> From: Nichole Richar= dson <nichole.richardson.27@facebook.com>
> To= : <oauth@ietf.org>,  <oauth-request@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 12
> Message-ID: <b3bcaf3b2487b7eebc3c8ecbde1843a9@messages= .facebook.com>
> Content-Type: text/plain; charse= t=3D"utf-8"
>
> he= lp
>
>
= > On November 14, 2012 6:51:40 AM PST, oauth-request@ietf.org wrote:
> > If you have received this digest without all the= individual message
> > attachments you will need= to update your digest options in your list
> > s= ubscription.  To do so, go to
> >
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> > Click the 'Unsubscri= be or edit options' button, log in, and set "Get
&= gt; > MIME or Plain Text Digests?" to MIME.  You can set this = option
> > globally for all the list digests you = receive at this point.
> >
&= gt; >
> >
> > Send= OAuth mailing list submissions to
> > =09oauth@i= etf.org
> >
> > To sub= scribe or unsubscribe via the World Wide Web, visit
>= ; > =09https://www.ietf.org/mailman/listinfo/oauth
> > or, via email, send a message with subject or body 'help' to> > =09oauth-request@ietf.org
&= gt; >
> > You can reach the person managing t= he list at
> > =09oauth-owner@ietf.org
> >
> > When replying, please = edit your Subject line so it is more specific
> >= than "Re: Contents of OAuth digest..."
> = >
> >
> > Today's = Topics:
> >
> >  =  1. Re: OAuth Digest, Vol 49, Issue 11 (Nichole Richardson)
> >    2. Vacationing this week & e-mail ad= dress (Michael Jones)
> >    3. is OAut= h protocol based on HTTP? (dgq2011)
> >
> >
> > ----------------------= ------------------------------------------------
> &= gt;
> > Message: 1
> >= Date: Tue, 13 Nov 2012 14:31:11 -0800
> > From: = Nichole Richardson <nichole.richardson.27@facebook.com>
> > To: <oauth@ietf.org>,  <oauth-request@ietf.o= rg>
> > Subject: Re: [OAUTH-WG] OAuth Digest, = Vol 49, Issue 11
> > Message-ID: <a8044d50234c= 082dcb53112e4b433fcb@messages.facebook.com>
> >= ; Content-Type: text/plain; charset=3D"utf-8"
> >
> > get mime
>= >
> > On November 13, 2012 12:00:08 PM PST, = oauth-request@ietf.org wrote:
> > > If you hav= e received this digest without all the individual message
> > > attachments you will need to update your digest options i= n your list
> > > subscription.  To do so= , go to
> > >
> > = > https://www.ietf.org/mailman/listinfo/oauth
>= ; > >
> > > Click the 'Unsubscribe or e= dit options' button, log in, and set "Get
> >= ; > MIME or Plain Text Digests?" to MIME.  You can set this op= tion
> > > globally for all the list digests y= ou receive at this point.
> > >
> > >
> > >
> > > Send OAuth mailing list submissions to
> > > =09oauth@ietf.org
> > >
> > > To subscribe or unsubscribe via the World W= ide Web, visit
> > > =09https://www.ietf.org/ma= ilman/listinfo/oauth
> > > or, via email, = send a message with subject or body 'help' to
> >= > =09oauth-request@ietf.org
> > >
> > > You can reach the person managing the list at> > > =09oauth-owner@ietf.org
> > >
> > > When replying, please= edit your Subject line so it is more specific
> >= ; > than "Re: Contents of OAuth digest..."
> > >
> > >
&g= t; > > Today's Topics:
> > >
> > >    1. Re: bag-of-keys metadata UC for = the "mac" discussion (Phil Hunt)
> > &g= t;    2. Re: bag-of-keys metadata UC for the "mac" disc= ussion
> > >       (Leif Johans= son)
> > >    3. Review Volunteers (= Hannes Tschofenig)
> > >    4. Meeti= ng Minutes (Hannes Tschofenig)
> > >
> > >
> > > ------------= ----------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Mon, 12 Nov 2012 13:09:11 -0800
> > > From: Phil Hunt <phil.hunt@oracle.com>
> > > To: Leif Johansson <leifj@mnt.se>
> > > Cc: oauth@ietf.org
>= > > Subject: Re: [OAUTH-WG] bag-of-keys metadata UC for the "ma= c"
> > > =09discussion
> > > Message-ID: <7EF786E1-18E2-4974-A6BC-2C72BE9F5C11@oracl= e.com>
> > > Content-Type: text/plain; char= set=3D"iso-8859-1"
> > >
> > > Leif,
> > >
> > > I've read this a couple of times and I think I= 'm getting lost in partial SAML vs. OAuth terminology. As a result, I thoug= ht you were saying:
> > >
> > > 1. It isn't practical to issue client credentials even with= Dynamic Registration
> > > 2. You want to re-= use key management already in place with OAuth2.
> &= gt; >
> > > These statements seem to be in= conflict.  Did you mean to say for number 2 that you want to re-use k= ey management already in place for SAML?
> > >=
> > > Phil
> > >= ;
> > > @independentid
&g= t; > > www.independentid.com
> > > phil.= hunt@oracle.com
> > >
>= ; > >
> > >
> &= gt; >
> > >
> >= > On 2012-11-08, at 8:01 AM, Leif Johansson wrote:
= > > >
> > > > I promised to send = a UC to the list as input to the discussion around new
= > > > > token formats.
> > > > =
> > > > ---
> > = > >
> > > > Several large-scale depl= oyments of public-key use a "bag-of-keys" model
> > > > for key management: you stick endpoint information t= ogether with public
> > > > keys for those = endpoints in a signable container which is then signed with
> > > > a private key associated with some "trust pro= vider" an distributed to all
> > > > e= ntities/relying parties.
> > > >
> > > > Examples include various trust status lists= formats and things like SAML
> > > > metad= ata.
> > > >
> >= > > The latter case (SAML metadata) isn't necessarily tied to the SA= ML v2
> > > > _protocol_ but it is used for= that. Large-scale SAML federations are often
> >= > > setup to depend on distribution of signed SAML metadata.
> > > >
> > > > C= onsider the case when a large number of relying parties of such a SAML
> > > > federation are also either OAUTH2 resou= rce or authorization servers. Today
> > > >= all of those OAUTH2 entities have to be provisioned with separate client> > > > secrets that have no relationship to= the trust infrastructure already in use
> > >= > in the federation.
> > > >
> > > > It is not uncommon for such federations to = have 1000s and sometimes
> > > > 10000s of = entities making client secret management something of a
> > > > scalability issue.
> > > = >
> > > > Even with dynreg the problem = of managing all of those client secrets
> > > = > would still remain a *huge* (operational) security and scalability iss= ue.
> > > >
> > = > > There is therefore a desire among communities that have such depl= oyments
> > > > to be able to re-use the ke= y-management already in place for OAUTH2.
> > >= ; >
> > > > Note that this example isn'= t tied to the SAML protocol at all.
> > > >=
> > > >         Leif<= br clear=3D'none' />> > > > ___________________________________= ____________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
>= ; > > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> > > -------------- = next part --------------
> > > An HTML attachm= ent was scrubbed...
> > > URL: <http://www.ietf.org/mail-archive/web/oauth/= attachments/20121112/ede07590/attachment.htm>
&g= t; > >
> > > --------------------------= ----
> > >
> > >= Message: 2
> > > Date: Mon, 12 Nov 2012 22:12= :40 +0100
> > > From: Leif Johansson <leifj= @mnt.se>
> > > To: Phil Hunt <phil.hunt@= oracle.com>
> > > Cc: oauth@ietf.org
> > > Subject: Re: [OAUTH-WG] bag-of-keys metadata U= C for the "mac"
> > > =09discussion<= br clear=3D'none' />> > > Message-ID: <50A16648.1030604@mnt.se&= gt;
> > > Content-Type: text/plain; charset=3D= ISO-8859-1
> > >
> >= ; > On 11/12/2012 10:09 PM, Phil Hunt wrote:
> &g= t; > > Leif,
> > > >
> > > > I've read this a couple of times and I think I'm ge= tting lost in
> > > > partial SAML vs. OAut= h terminology. As a result, I thought you were
> >= ; > > saying:
> > > >
> > > > 1. It isn't practical to issue client credentials = even with Dynamic
> > > > Registration
> > > > 2. You want to re-use key management al= ready in place with OAuth2.
> > > >
> > > > These statements seem to be in conflict. &= nbsp;Did you mean to say for
> > > > number= 2 that you want to re-use key management already in place for SAML?
> > > >
> > > yep - = "for" as in "for use by"
> > = >
> > >
> > >= ; ------------------------------
> > >
> > > Message: 3
> > > = Date: Tue, 13 Nov 2012 10:19:24 -0500
> > > Fr= om: Hannes Tschofenig <hannes.tschofenig@gmx.net>
> > > To: "oauth@ietf.org WG" <oauth@ietf.org>> > > Subject: [OAUTH-WG] Review Volunteers
> > > Message-ID: <9ABA26C3-1B06-4D15-9268-5F75= B20E941D@gmx.net>
> > > Content-Type: text/= plain; charset=3Dus-ascii
> > >
> > > We collected a number of action items last week. Here= is my list
> > >
> &g= t; > 1. Token Revocation
> > >
> > > ACTION: Torsten to publish a draft update this week= .
> > >
> > > A= CTION: Volunteers to review the draft:
> > > -= Amanda
> > > - Justin
&g= t; > > - Tony
> > >
> > > 2. draft-ietf-oauth-jwt-bearer
> >= ; >
> > > ACTION: Justin to review JWT Bea= rer Token Profiles
> > >
= > > > 3. OAuth Use Cases
> > >
> > > ACTION: Tony to work with Zachary on buildin= g out use cases and clarifying the audience of the doc.
> > >
> > > 4. JWT
> > >
> > > ACTION: Jeff Hodges,= Klaas, and Leif to review the draft.
> > > > > > 5. Security
> >= >
> > > http://datatr= acker.ietf.org/doc/draft-tschofenig-oauth-security/
> > >
> > > ACTION: working group t= o provide feedback on the requirements.
> > >=
> > > 6. Dynamic Client Registration
> > >
> > > ACTION: Ha= nnes to ask UMA folks to review the doc.
> > >= ; ACTION: Nat, John, Torsten to review the doc.
> &= gt; >
> > >
> >= >
> > >
> > &g= t;
> > > ------------------------------
> > >
> > > Message: = 4
> > > Date: Tue, 13 Nov 2012 10:40:21 -0500<= br clear=3D'none' />> > > From: Hannes Tschofenig <hannes.tscho= fenig@gmx.net>
> > > To: "oauth@ietf.o= rg WG" <oauth@ietf.org>
> > > Subje= ct: [OAUTH-WG] Meeting Minutes
> > > Message-I= D: <F640899A-B4E4-40B4-B961-64199C600AAD@gmx.net>
> > > Content-Type: text/plain; charset=3Dus-ascii
> > >
> > > Hi all,
> > >
> > > please have = a look at the meeting minutes from last week:
> >= > http://www.ietf.org/proceedings/85/minutes/minutes-85-= oauth
> > >
> >= > Thanks to Amanda & Jean for taking notes.
&g= t; > >
> > > Ciao
&= gt; > > Hannes & Derek
> > >
> > >
> > >
> > > ------------------------------
> > >
> > > _____________________= __________________________
> > > OAuth mailing= list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> > >
> > > End of OAuth Digest, Vol 49, Issue 11
> > > *************************************
> > -------------- next part --------------
>= > An HTML attachment was scrubbed...
> > URL:= <http://www.ietf.org/mail-ar= chive/web/oauth/attachments/20121113/d4752114/attachment.htm>
> >
> > --------------------= ----------
> >
> > Mes= sage: 2
> > Date: Tue, 13 Nov 2012 15:33:26 -0800=
> > From: Michael Jones <michael_b_jones@hotm= ail.com>
> > To: <jose@ietf.org>, <oa= uth@ietf.org>, <apps-discuss@ietf.org>
> &g= t; Cc: cfrg@irtf.org
> > Subject: [OAUTH-WG] Vaca= tioning this week & e-mail address
> > Messag= e-ID: <BAY171-W4767242AC702446BF30539B76C0@phx.gbl>
> > Content-Type: text/plain; charset=3D"windows-1252"> >
> >
> >
> >
> &g= t;
> > Hi all, I wanted to let you know that I'm= vacationing this week, and so mostly won't be participating in discussions= .  I'll respond next week. Also, at present I?m using the e-mail addre= ss michael_b_jones@hotmail.com
> > to send e-mail= to IETF mailing lists because currently I?m unable to send e-mail to any I= ETF lists using my normal
> > e-mail address Mich= ael.Jones@microsoft.com.
> > When corresponding = with me individually, it would be better to use the
>= ; > Microsoft address, as the message is likely to be seen more quickly.= Have a good week, everyone! -- Mike
> >
> >  =09=09 =09   =09=09  
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> >= ; URL: <http://www.ietf.org/m= ail-archive/web/oauth/attachments/20121113/8b3a4b36/attachment.htm><= br clear=3D'none' />> >
> > --------------= ----------------
> >
> &g= t; Message: 3
> > Date: Wed, 14 Nov 2012 22:51:27= +0800
> > From: dgq2011 <dgq2011@gmail.com>= ;
> > To: "oauth@ietf.org" <oauth@ie= tf.org>
> > Subject: [OAUTH-WG] is OAuth proto= col based on HTTP?
> > Message-ID: <2012111422= 51220430822@gmail.com>
> > Content-Type: text/= plain; charset=3D"gb2312"
> >
> > Hi, all! It is said in RFC 6749 (The OAuth 2.0 Author= ization Framework) that ?this specification is designed for use with HTTP (= [RFC2616])? and ?The use of OAuth over any protocol other than HTTP is out = of scope.? Do those statements mean that the communication between any two = roles in OAuth protocol (namely resource owner, resource server, client and= authorization server) is based on HTTP protocol? I am not familiar with th= e OAuth protocol and just would like to confirm this question. Any response= is appreciated!
> >
> &g= t;
> > Best wishes?
> >= ; Guangqing Deng
> >
> &g= t;
> >
> > dgq2011> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <http://www= .ietf.org/mail-archive/web/oauth/attachments/20121114/e1240784/attachment.h= tm>
> >
> > ---= ---------------------------
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@iet= f.org
> > https://www.ietf.org/mailman/listinfo/oa= uth
> >
> >
> > End of OAuth Digest, Vol 49, Issue 12
> > *************************************
> -------------- next part --------------
> An H= TML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/oauth= /attachments/20121118/05fa82f1/attachment.htm>
&= gt;
> ------------------------------
>
> ______________________________________= _________
> OAuth mailing list
&= gt; OAuth@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/oauth
>
>
> End of OAuth Digest, Vol 49, Issue 15
> *************************************
-----------= --- next part --------------
An HTML attachment was scr= ubbed...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20121118/3ded9= 254/attachment.htm>

-------= -----------------------

__________= _____________________________________
OAuth mailing lis= t
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth


End of OAuth Digest, Vol 49, Issue 16
*= ************************************
------=_Part_7213_817419805.1353246485050-- From internet-drafts@ietf.org Sun Nov 18 08:37:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710B221F8580; Sun, 18 Nov 2012 08:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-BbLpXva8MN; Sun, 18 Nov 2012 08:37:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE11021F8566; Sun, 18 Nov 2012 08:37:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> Date: Sun, 18 Nov 2012 08:37:09 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 16:37:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : Token Revocation Author(s) : Torsten Lodderstedt Stefanie Dronia Marius Scurtescu Filename : draft-ietf-oauth-revocation-02.txt Pages : 7 Date : 2012-11-18 Abstract: This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same access grant. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-revocation-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From torsten@lodderstedt.net Sun Nov 18 08:40:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7CD21F84ED for ; Sun, 18 Nov 2012 08:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HELO_EQ_DE=0.35, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+iYNHVmH-zT for ; Sun, 18 Nov 2012 08:40:47 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) by ietfa.amsl.com (Postfix) with ESMTP id 55A3A21F84CC for ; Sun, 18 Nov 2012 08:40:47 -0800 (PST) Received: from [79.253.38.18] (helo=[192.168.71.42]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Ta7vJ-0001EL-Jb for oauth@ietf.org; Sun, 18 Nov 2012 17:40:45 +0100 Message-ID: <50A90F8B.5080100@lodderstedt.net> Date: Sun, 18 Nov 2012 17:40:43 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 CC: oauth@ietf.org References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> In-Reply-To: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 16:40:48 -0000 Hi, the following changed were applied to the revocation draft: - focused draft on client-initiated token revocation, cut out self-care/portal stuff - added implementation note on access token revocation. - extended abstract - removed normative language from introduction regards, Torsten. Am 18.11.2012 17:37, schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol Working Group of the IETF. > > Title : Token Revocation > Author(s) : Torsten Lodderstedt > Stefanie Dronia > Marius Scurtescu > Filename : draft-ietf-oauth-revocation-02.txt > Pages : 7 > Date : 2012-11-18 > > Abstract: > This document proposes an additional endpoint for OAuth authorization > servers, which allows clients to notify the authorization server that > a previously obtained refresh or access token is no longer needed. > This allows the authorization server to cleanup security credentials. > A revocation request will invalidate the actual token and, if > applicable, other tokens based on the same access grant. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-revocation-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ib.lundgren@gmail.com Sun Nov 18 08:57:07 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6475621F8527 for ; Sun, 18 Nov 2012 08:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUeB9gvnc82Z for ; Sun, 18 Nov 2012 08:57:07 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD3F521F84EC for ; Sun, 18 Nov 2012 08:57:06 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so4487607oag.31 for ; Sun, 18 Nov 2012 08:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=O99BTc+8CqSg9qtdKcnKcbH5oA5eP3IFLHqUjOYM4eg=; b=rE/QF2jRJh/by39+UHgqfhMn209r3mItE1nfw4WDiMMpPzfCXC0MgLAm+XQUVOCsL6 b9GgwAy9VoDMdEqZfmMgKHcp7Ap7ivItTnVrkgADgSmCl1GYe+kiVJUNxdBhVR1wb7I2 KFQoUqS9Ik20hk4YfHMFU4/bIU7+H4XpX+V9vKAIfOh8dhwOqbV+pP3b4KFJb/sScrfj lFU85X1lze92B9/NgQkEKPTdGtV1TkgDOZ8IdgdAnvf9Adl4W5Rcc8gcopYZcyWcJSVC Nc5F9bPchHpqjr4ox9fIbwCELcxSHLTQw/jehTq7Yj8e38L+eVREhEf6kNlZy+FO4p4t L7TQ== MIME-Version: 1.0 Received: by 10.60.169.243 with SMTP id ah19mr8561395oec.127.1353257826405; Sun, 18 Nov 2012 08:57:06 -0800 (PST) Received: by 10.76.172.168 with HTTP; Sun, 18 Nov 2012 08:57:06 -0800 (PST) Date: Sun, 18 Nov 2012 17:57:06 +0100 Message-ID: From: Ib Lundgren To: oauth@ietf.org Content-Type: multipart/alternative; boundary=bcaec517a6b4084e6004cec7e4d6 Subject: [OAUTH-WG] Identifying token type during protected resource access X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 16:57:07 -0000 --bcaec517a6b4084e6004cec7e4d6 Content-Type: text/plain; charset=ISO-8859-1 Hey everyone, http://tools.ietf.org/html/rfc6749#section-7 provides examples of MAC and Bearer tokens being supplied when accessing a protected resource. It also mentions that it is up to each type of token to define additional parameters. However it is not quite clear whether there exists a recommended/intended way of differentiating the token type of any particular request as the token_type parameter is not supplied. Consider a bearer token supplied as the access_token query component. Then I invent and register Bearer+ which in addition has the plus query component. Then later Super Bearer is created with the additional super query component. The only way to differentiate would be to inspect present parameters and make an educated guess. Am I missing something obvious? Thanks, Ib --bcaec517a6b4084e6004cec7e4d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey everyone,

http://tools.ietf.org/html/rfc6749#section-7=A0provides = examples of MAC and Bearer tokens being supplied when accessing a protected= resource. It also mentions that it is up to each type of token to define a= dditional parameters. However it is not quite clear whether there exists a = recommended/intended way of differentiating the token type of any particula= r request as the token_type parameter is not supplied.

Consider a bearer token supplied as the access_token qu= ery component. Then I invent and register Bearer+ which in addition has the= plus query component. Then later Super Bearer is created with the addition= al super query component. The only way to differentiate would be to inspect= present parameters and make an educated guess.=A0

Am I missing something obvious?

Thanks,
Ib



--bcaec517a6b4084e6004cec7e4d6-- From wmills_92105@yahoo.com Sun Nov 18 10:05:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4069621F8477 for ; Sun, 18 Nov 2012 10:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+Xgt0eigRLR for ; Sun, 18 Nov 2012 10:05:21 -0800 (PST) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) by ietfa.amsl.com (Postfix) with ESMTP id 4E75421F845B for ; Sun, 18 Nov 2012 10:05:21 -0800 (PST) Received: from [98.139.212.150] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 18 Nov 2012 18:05:20 -0000 Received: from [98.139.212.209] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 18 Nov 2012 18:05:20 -0000 Received: from [127.0.0.1] by omp1018.mail.bf1.yahoo.com with NNFMP; 18 Nov 2012 18:05:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 371186.46552.bm@omp1018.mail.bf1.yahoo.com Received: (qmail 58826 invoked by uid 60001); 18 Nov 2012 18:05:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353261919; bh=fPItg6mUjBtRiY363iVEBiYi7iBzqAiXxaxWISyem0I=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=aa/cs1vmw/FOUJuEL1gYkaruvFFgExbVj0abEXnlEFuSppgaccxNwjx21HN+A5zRzRmVAuIaB4RT5/2KmD7Y2t7wJOLXnMB366IRjnr2H+0LOoNWTnvOJaC2hbMiebaBlLfeCf647Wx0wUcWHjZlPsquKGU3aEFpl5igfmjmbhM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=NkDvrFKqQvBkqrqHMiOxVLYN8HzT9cOb+oa4EQjh/FuOT/ASwRjdoGLcnLpcoRx1ODBMlwhixBjhq9uThFqOhSslTaMdzFHmB5PSKG0gJMmWJ/RntatJxenfdYpLgIcwUUsLJFDtXcdk6k6xpa8y5+fTn0u7KQDCp5Pr4/kAc9A=; X-YMail-OSG: tMZJtvgVM1kxzIjcTyoOda4kizwbk3vgbWvebRVw09SWewK yRT2AOKWkOWJ84DMwGY66JBjr0BCKij8l4CVq9eXIbo5_s8p.Zv9YOhrDibJ sa4ihxQp.8.97AbwAAiO1mG0c5Bg5l_eK8VgUrs_yzgzPhlppVpGEPZEdMeM 1XPTIa5a3qEQSYaVolckdu1sh6ri6Pg_HZXMtU.jhihw6ILEYAt1oNu7RoG. 8S4g02DzSZ0W25cOGZjybgBssKGJpzrxWiaaAoIs.OK5j3.rJR9hc3hs5uob r0l5ewhGNx8NW9nXZ.4YhfwtG4wYYgN0IUbaLp.JJ7feRTiRGABfYb.R8tE0 RwLzyCWHSSCxuGECZN0nhKzQSYZtsg4wIxdjxRFSCTWBazV80KyGDl6BJE35 LZcVXBSOfaT84DhByonXdDzKmZkVtGMKgjWq2KVCzeFer1nC9oQJWAy6M8h7 4JmCbxnCwRF7FBHoEu66iH9AQLnb26qy1BAuUK6iseV4fUS0RUMRRVXacvPp 47KD3j0RqP.aNoosQpJk9RTBK05QhZd.QT73xHMQ- Received: from [99.31.212.42] by web31803.mail.mud.yahoo.com via HTTP; Sun, 18 Nov 2012 10:05:19 PST X-Rocket-MIMEInfo: 001.001, VGhlIEF1dGhvcml6YXRpb24gc2NoZW1lIG5hbWUgaW4gdGhlIEF1dGhvcml6YXRpb24gaGVhZGVyIHRlbGxzIHlvdQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogSWIgTHVuZGdyZW4gPGliLmx1bmRncmVuQGdtYWlsLmNvbT4KVG86IG9hdXRoQGlldGYub3JnIApTZW50OiBTdW5kYXksIE5vdmVtYmVyIDE4LCAyMDEyIDg6NTcgQU0KU3ViamVjdDogW09BVVRILVdHXSBJZGVudGlmeWluZyB0b2tlbiB0eXBlIGR1cmluZyBwcm90ZWN0ZWQgcmVzb3VyY2UgYWNjZXNzCiAKCkhleSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.126.469 References: Message-ID: <1353261919.53948.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Sun, 18 Nov 2012 10:05:19 -0800 (PST) From: William Mills To: Ib Lundgren , "oauth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-1126840323-1353261919=:53948" Subject: Re: [OAUTH-WG] Identifying token type during protected resource access X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 18:05:22 -0000 --1502656925-1126840323-1353261919=:53948 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The Authorization scheme name in the Authorization header tells you=0A=0A= =0A=0A________________________________=0A From: Ib Lundgren =0ATo: oauth@ietf.org =0ASent: Sunday, November 18, 2012 8:57 AM=0A= Subject: [OAUTH-WG] Identifying token type during protected resource access= =0A =0A=0AHey everyone,=0A=0Ahttp://tools.ietf.org/html/rfc6749#section-7= =A0provides examples of MAC and Bearer tokens being supplied when accessing= a protected resource. It also mentions that it is up to each type of token= to define additional parameters. However it is not quite clear whether the= re exists a recommended/intended way of differentiating the token type of a= ny particular request as the token_type parameter is not supplied.=0A=0ACon= sider a bearer token supplied as the access_token query component. Then I i= nvent and register Bearer+ which in addition has the plus query component. = Then later Super Bearer is created with the additional super query componen= t. The only way to differentiate would be to inspect present parameters and= make an educated guess.=A0=0A=0AAm I missing something obvious?=0A=0AThank= s,=0AIb=0A=0A=0A=0A_______________________________________________=0AOAuth = mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --1502656925-1126840323-1353261919=:53948 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The Authorization scheme name in the Authorization header tells you


claim. Information about = the client identifier is not carried in a standardized format inside the = JWT.=20 We have not standardized a SAML-based access token format in the OAuth = working group. So, there is no information available about that.=20 I hope this answers your question.=20 Ciao Hannes On Nov 15, 2012, at 10:03 PM, Security Developer wrote: > Hi, >=20 > If an access token is either SAML or JWT in OAuth then what would be = the value in subject either resource owner or client application name? >=20 > Thanks for your time. >=20 > Regards, > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Tue Nov 20 07:59:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A7921F86C6 for ; Tue, 20 Nov 2012 07:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCsTdA6qVrlk for ; Tue, 20 Nov 2012 07:59:29 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA1A21F85C4 for ; Tue, 20 Nov 2012 07:59:29 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 706851F079F; Tue, 20 Nov 2012 10:59:28 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 634DA1F0A52; Tue, 20 Nov 2012 10:59:28 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 20 Nov 2012 10:59:28 -0500 Message-ID: <50ABA88F.4030500@mitre.org> Date: Tue, 20 Nov 2012 10:58:07 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Torsten Lodderstedt References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> In-Reply-To: <50A90F8B.5080100@lodderstedt.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 15:59:29 -0000 Comments on the latest draft. Overall, it's in good shape, with a little bit of tweaking to some of the new language I think it's about ready for last call. 1. Introduction: - "cleanup" as a verb should be two words here, "clean up" - Remove extraneous commas, change "This prevents a situation, where there is still a valid access grant for that particular client, which the end- user is not aware of." text to something more like: "This behavior prevents a situation where there is still a valid access grant for a particular client which the end user is not aware of." 2. Token Revocation: - grammatical parallelism, suggest wording: "Implementations MUST support the revocation of refresh tokens and SHOULD support the revocation of access tokens." - questionable whether the above is really a SHOULD, though I understand Google's argument for this as detailed in the Note - Consider moving the Note on access tokens to a Section and including a cross-reference to it - "It therefore validates..." reads awkwardly, suggest rewording with: "These checks are used to validate whether the token being presented has been issued to the client presenting it." 3. Acknowledgements - You don't need to list my middle initial, it sounds pretentious. ;) 5. Security Considerations - "liklyhood" should be spelled "likelihood" - countermeasures: make this a normative SHOULD? or MUST? - "legitimate client to loss" should be "legitimate client to lose" -- Justin On 11/18/2012 11:40 AM, Torsten Lodderstedt wrote: > Hi, > > the following changed were applied to the revocation draft: > - focused draft on client-initiated token revocation, cut out > self-care/portal stuff > - added implementation note on access token revocation. > - extended abstract > - removed normative language from introduction > > regards, > Torsten. > > Am 18.11.2012 17:37, schrieb internet-drafts@ietf.org: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol Working >> Group of the IETF. >> >> Title : Token Revocation >> Author(s) : Torsten Lodderstedt >> Stefanie Dronia >> Marius Scurtescu >> Filename : draft-ietf-oauth-revocation-02.txt >> Pages : 7 >> Date : 2012-11-18 >> >> Abstract: >> This document proposes an additional endpoint for OAuth >> authorization >> servers, which allows clients to notify the authorization server >> that >> a previously obtained refresh or access token is no longer needed. >> This allows the authorization server to cleanup security >> credentials. >> A revocation request will invalidate the actual token and, if >> applicable, other tokens based on the same access grant. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-oauth-revocation-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-02 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 From sberyozkin@gmail.com Wed Nov 21 03:50:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B7C21F8958 for ; Wed, 21 Nov 2012 03:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGs5VAKkcSyu for ; Wed, 21 Nov 2012 03:50:10 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEC221F862E for ; Wed, 21 Nov 2012 03:50:09 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so5745300lah.31 for ; Wed, 21 Nov 2012 03:50:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4j5RVA1F6OjMtQk7W69883Lm5+L1kPGfk1m6oOSYlQ0=; b=myfwudPJqpjDOik1eKkc0Fe2mpGEZ6qQNAByUa9v0jMe8uBFHK4VgwbB10mTxZ2f9U X/m1hUFYHR7yRQSRr4uAGAYjbKUKe1HelLaxPu/vOwVP2ZPCe4QgiN2z12JzsjEg0HBJ +nAfBIh3ykSLg2rClb9ZUSx6hBud67HLo42aSuMSeU71VYFJ9b9tKSZWLL/cK9BMRqBn oaaYNk2q14DEXbOM0XXPfe9D0+dGcixebOV41fEES9owzdhCwnjXifYgUqk1i81oK2uh YgsJN8jYyX0rBeL63aCPxTlKXl/Pc7ZtWdzyW84qrdojFv2L4s0oB0Ey9IEoIdVIPEk0 2/zw== Received: by 10.152.108.48 with SMTP id hh16mr596557lab.25.1353498608253; Wed, 21 Nov 2012 03:50:08 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id pw17sm5979762lab.5.2012.11.21.03.50.07 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 03:50:07 -0800 (PST) Message-ID: <50ACBFEE.7020606@gmail.com> Date: Wed, 21 Nov 2012 11:50:06 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> In-Reply-To: <50ABA88F.4030500@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 11:50:12 -0000 Hi I'm looking for some guidance on how the client which already owns an access token can decide, after getting HTTP 400 back from the resource server it tries to access on behalf of the end user/resource owner, can decide that the refresh token it has can now be used to get a new access token. [1] refers to various error conditions but it is not obvious to me that the same conditions (some of them) should or can be reported during the actual client accessing the protected resource. My question is, what error condition, if any, from [1] should be reported back to the client failing to access a protected resource due to the access token being invalid or expired, so that it can help the client who also owns the refresh token to decide it can use it now... Thanks, Sergey [1] http://tools.ietf.org/html/rfc6749#section-5.2 From jricher@mitre.org Wed Nov 21 06:12:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6FC21F8650 for ; Wed, 21 Nov 2012 06:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CReoivQsF61R for ; Wed, 21 Nov 2012 06:12:34 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B0E1D21F862C for ; Wed, 21 Nov 2012 06:12:34 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E18ED1F0B18; Wed, 21 Nov 2012 09:12:33 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CE89F1F0B46; Wed, 21 Nov 2012 09:12:33 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 21 Nov 2012 09:12:33 -0500 Message-ID: <50ACE0FF.4060807@mitre.org> Date: Wed, 21 Nov 2012 09:11:11 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Sergey Beryozkin References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> In-Reply-To: <50ACBFEE.7020606@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 14:12:35 -0000 There's no signaling regarding the validity of the refresh token from the protected resource. In more distributed setups, the protected resources know nothing about the refresh tokens because the PR never sees them. In any case. the code path is fairly straightforward, even if both tokens are expired: - client presents AT to resource - resource returns data, AT worked - [or] resource returns 400 error to client, AT didn't work - client presents RT to auth server - auth server returns new AT, RT worked - [or] auth server returns 400 error to client, RT didn't work - client has to go get a new auth grant from the resource owner, start over -- Justin On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: > Hi > > I'm looking for some guidance on how the client which already owns an > access token can decide, after getting HTTP 400 back from the resource > server it tries to access on behalf of the end user/resource owner, > can decide that the refresh token it has can now be used to get a new > access token. > > [1] refers to various error conditions but it is not obvious to me > that the same conditions (some of them) should or can be reported > during the actual client accessing the protected resource. > > My question is, what error condition, if any, from [1] should be > reported back to the client failing to access a protected resource due > to the access token being invalid or expired, so that it can help the > client who also owns the refresh token to decide it can use it now... > > Thanks, Sergey > > [1] http://tools.ietf.org/html/rfc6749#section-5.2 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sberyozkin@gmail.com Wed Nov 21 06:18:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2FB21F844E for ; Wed, 21 Nov 2012 06:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkCiGqi3jfJj for ; Wed, 21 Nov 2012 06:18:53 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4EA21F8513 for ; Wed, 21 Nov 2012 06:18:52 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so5876584lah.31 for ; Wed, 21 Nov 2012 06:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VcUTfLez5A2GUuunX73wDYLX0ldorQ+iZ296ISLf7Tc=; b=ogWCa1MMUkANcdQgF44oXAAHRvPT/rysv6z8phCAD0klgehKHykUjGHyVrhSN7eOR5 sD2JlXiOZkQbsPUwvL6nxkHZWARO7DPB9qY7Ai0h8CtoTAFkZ9dQMAVtiPuo3TIMF5FY /7n1GsaIAAaGMt9rrgslko8GtfqG0+stiA8YpOhYkFWQwUGjKMbYxhrJtTrWWZZHh6if ozDgd19uE15Y4KeRSEm3rog6nM677QyiPu/pTzA+hsDzNSeeDUssiYB92dlxPbzgmI+c Huu8lbjyNJ/Uap5iBn9bpOI+3hFBzfDTox8IhY875xJm3Q7OOUqHXke86a0xDyx3rsGQ Uhlg== Received: by 10.112.42.34 with SMTP id k2mr7795078lbl.26.1353507531916; Wed, 21 Nov 2012 06:18:51 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id m3sm311523lbb.13.2012.11.21.06.18.50 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 06:18:51 -0800 (PST) Message-ID: <50ACE2CA.4020904@gmail.com> Date: Wed, 21 Nov 2012 14:18:50 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Justin Richer References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> In-Reply-To: <50ACE0FF.4060807@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 14:18:54 -0000 Hi On 21/11/12 14:11, Justin Richer wrote: > There's no signaling regarding the validity of the refresh token from > the protected resource. In more distributed setups, the protected > resources know nothing about the refresh tokens because the PR never > sees them. I was just asking how the client decides it can use the refresh token, and > In any case. the code path is fairly straightforward, even if > both tokens are expired: > > - client presents AT to resource > - resource returns data, AT worked > - [or] resource returns 400 error to client, AT didn't work > - client presents RT to auth server > - auth server returns new AT, RT worked > - [or] auth server returns 400 error to client, RT didn't work > - client has to go get a new auth grant from the resource owner, start over > the answer seems to be that whenever it gets 400 after presenting AT to resource it should try to use RT next to get a new AT, I guess it was not really obvious to me though now that I think about it, it makes sense, 400 at the initial try means that the current AT is not good enough for whatever reasons Thanks, Sergey > -- Justin > > > On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: >> Hi >> >> I'm looking for some guidance on how the client which already owns an >> access token can decide, after getting HTTP 400 back from the resource >> server it tries to access on behalf of the end user/resource owner, >> can decide that the refresh token it has can now be used to get a new >> access token. >> >> [1] refers to various error conditions but it is not obvious to me >> that the same conditions (some of them) should or can be reported >> during the actual client accessing the protected resource. >> >> My question is, what error condition, if any, from [1] should be >> reported back to the client failing to access a protected resource due >> to the access token being invalid or expired, so that it can help the >> client who also owns the refresh token to decide it can use it now... >> >> Thanks, Sergey >> >> [1] http://tools.ietf.org/html/rfc6749#section-5.2 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From wmills_92105@yahoo.com Wed Nov 21 06:53:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF9921F85CB for ; Wed, 21 Nov 2012 06:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grAJj1hB4ISO for ; Wed, 21 Nov 2012 06:53:33 -0800 (PST) Received: from nm15.bullet.mail.ne1.yahoo.com (nm15.bullet.mail.ne1.yahoo.com [98.138.90.78]) by ietfa.amsl.com (Postfix) with ESMTP id AEF6621F856D for ; Wed, 21 Nov 2012 06:53:32 -0800 (PST) Received: from [98.138.90.57] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 21 Nov 2012 14:53:29 -0000 Received: from [98.138.89.169] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 21 Nov 2012 14:53:29 -0000 Received: from [127.0.0.1] by omp1025.mail.ne1.yahoo.com with NNFMP; 21 Nov 2012 14:53:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 569548.23838.bm@omp1025.mail.ne1.yahoo.com Received: (qmail 45577 invoked by uid 60001); 21 Nov 2012 14:53:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353509608; bh=px7Q7zOwu/TxPvt8ZSsld9o34qhTYBtO4LmXkJ4w5ys=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=r+RY8MqjU9sy5wMx7CzxJ45hdJG5/C/f/sOSYv7WQxtPo6BeabdDiPiWSRk1+ZqAOd0qTGVtkQVmrUIwKthbFYiMeXLCT/26wcb9j8ZFqj2cf4rPEZR7XCJXA0SeQMf4B1k3eqZ0Ige+P5LGd7kMehYoO1frn2gYTlUETkLWxfQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Fw7vSYL1+kIgXzFOh38R9J8PBfgACXQ7EZ5yWk60qYDqaMh0E0E94yJnwkKz6zFXoHQcy30kARwng774qDYR1aGzSyYWXyQqkR32PaF77ii8iI6axF+ZRKAQYT1JnIXWTgqy9reaV+zhLjNZJWFDk0FuC3fWhkslhJFk+zNTnJo=; X-YMail-OSG: POjA1oIVM1nryR.OV2fexTlilhaFH3sPAI17DQdXgY6b2J6 1VslOWcXlc5PymwXR_j97CCU.LvPzrl.E0w28hlBvROGrruk1.4P7.W6x8u2 06d_LlmaQWWaMKG7ebmw9GwvN1pTueGkZ2Xm4VK8oleFUj96lN1_bpVsHUgH 3YOqFZfqI1JUujomgPTUIDftuTzgKMi9bZ83bYFR_hV_cvgJhypis0NEFSIt BX5ZuqgICHHaP0tyDONyhT_nrUZ85JcB3GaXVyLCax_b2ud.uRDcGu_n7jkl NmNOoWMfV_uktLRJXPa2sZjk1sNMgjzOtQEphkDpr2Urgda0mwlRVL_qxjjF q9SpEPtw.CNobpm8RWQmiKf.J1m1eLLvl5yAAb9DkN9Ux.9F3_GzduNiYTkg WdebNyDRAIwWfR7F1JC9xunh2riSm7Uy5HT9ke66xBT0CG2Ad.bMGnBGi2pj frJvYA9Hwtl.xBC4NU4FoQC2rEZzhhlHtngLJawpoz8GzG_5ArpFnJRXQPqB 6Ox8wDSINayoqojgN35ooHnFMT6Cpvrlvusj_wR9TelE- Received: from [209.131.62.115] by web31801.mail.mud.yahoo.com via HTTP; Wed, 21 Nov 2012 06:53:27 PST X-Rocket-MIMEInfo: 001.001, WWVzLCBleGFjdGx5IHJpZ2h0LiDCoFRoZSBjbGllbnQgZ2V0cyBhIGhpbnQgYWJvdXQgdGhlIEFUIGxpZmVzcGFuLCBidXQgbXVzdCBhbHdheXMgaGFuZGxlIHRoZSBlcnJvciByZXNwb25zZSB0b28uIMKgSWYgdGhlIEFUIGZhaWxzIHdpdGggYSA0MDEgdGhlbiB5b3UgdHJ5IGEgcmVmcmVzaC4gwqBJZiB0aGUgcmVmcmVzaCBmYWlscyBhbmQgeW91IGdldCBhIDQwMSByZXNwb25zZSB0aGVuIHlvdSByZS1hdXRoZW50aWNhdGUgdGhlIHVzZXIuIMKgT3RoZXIgNFhYIGVycm9yIGNvZGVzIG1lYW7CoHNvbWV0aGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.127.475 References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> <50ACE2CA.4020904@gmail.com> Message-ID: <1353509607.45415.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Wed, 21 Nov 2012 06:53:27 -0800 (PST) From: William Mills To: Sergey Beryozkin , Justin Richer In-Reply-To: <50ACE2CA.4020904@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-1301387149-1353509607=:45415" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 14:53:34 -0000 ---368338466-1301387149-1353509607=:45415 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yes, exactly right. =A0The client gets a hint about the AT lifespan, but mu= st always handle the error response too. =A0If the AT fails with a 401 then= you try a refresh. =A0If the refresh fails and you get a 401 response then= you re-authenticate the user. =A0Other 4XX error codes mean=A0something=A0= different of course.=0A=0A=0A________________________________=0A From: Serg= ey Beryozkin =0ATo: Justin Richer = =0ACc: oauth@ietf.org =0ASent: Wednesday, November 21, 2012 6:18 AM=0ASubj= ect: Re: [OAUTH-WG] How the client can decide it is time to use the refresh= token=0A =0AHi=0AOn 21/11/12 14:11, Justin Richer wrote:=0A> There's no si= gnaling regarding the validity of the refresh token from=0A> the protected = resource. In more distributed setups, the protected=0A> resources know noth= ing about the refresh tokens because the PR never=0A> sees them.=0A=0AI was= just asking how the client decides it can use the refresh token, and=0A=0A= > In any case. the code path is fairly straightforward, even if=0A> both to= kens are expired:=0A>=0A> - client presents AT to resource=0A> - resource r= eturns data, AT worked=0A> - [or] resource returns 400 error to client, AT = didn't work=0A> - client presents RT to auth server=0A> - auth server retur= ns new AT, RT worked=0A> - [or] auth server returns 400 error to client, RT= didn't work=0A> - client has to go get a new auth grant from the resource = owner, start over=0A>=0A=0Athe answer seems to be that whenever it gets 400= after presenting AT to =0Aresource it should try to use RT next to get a n= ew AT, I guess it was =0Anot really obvious to me though now that I think a= bout it, it makes =0Asense, 400 at the initial try means that the current A= T is not good =0Aenough for whatever reasons=0A=0AThanks, Sergey=0A=0A> -- = Justin=0A>=0A>=0A> On 11/21/2012 06:50 AM, Sergey Beryozkin wrote:=0A>> Hi= =0A>>=0A>> I'm looking for some guidance on how the client which already ow= ns an=0A>> access token can decide, after getting HTTP 400 back from the re= source=0A>> server it tries to access on behalf of the end user/resource ow= ner,=0A>> can decide that the refresh token it has can now be used to get a= new=0A>> access token.=0A>>=0A>> [1] refers to various error conditions bu= t it is not obvious to me=0A>> that the same conditions (some of them) shou= ld or can be reported=0A>> during the actual client accessing the protected= resource.=0A>>=0A>> My question is, what error condition, if any, from [1]= should be=0A>> reported back to the client failing to access a protected r= esource due=0A>> to the access token being invalid or expired, so that it c= an help the=0A>> client who also owns the refresh token to decide it can us= e it now...=0A>>=0A>> Thanks, Sergey=0A>>=0A>> [1] http://tools.ietf.org/ht= ml/rfc6749#section-5.2=0A>> _______________________________________________= =0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://www.ietf.org/mail= man/listinfo/oauth=0A>=0A_______________________________________________=0A= OAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo= /oauth ---368338466-1301387149-1353509607=:45415 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, exactly right.  The client gets a hint about t= he AT lifespan, but must always handle the error response too.  If the= AT fails with a 401 then you try a refresh.  If the refresh fails and= you get a 401 response then you re-authenticate the user.  Other 4XX = error codes mean something different of c= ourse.

From:<= /b> Sergey Beryozkin <sberyozkin@gmail.com>
To: Justin Richer <jricher@mitre.org>
Cc: oauth@ietf.org
Sent: Wednesday, November 21, 2012 6:= 18 AM
Subject: Re: [OA= UTH-WG] How the client can decide it is time to use the refresh token
<= /font>

=0AHi
On 21/11/12 14:11, Justin Richer wrote:
> = There's no signaling regarding the validity of the refresh token from
&g= t; the protected resource. In more distributed setups, the protected
>= ; resources know nothing about the refresh tokens because the PR never
&= gt; sees them.

I was just asking how the client decides it can use t= he refresh token, and

> In any case. the code path is fairly stra= ightforward, even if
> both tokens are expired:
>
> - cli= ent presents AT to resource
> - resource returns data, AT worked
&= gt; - [or] resource returns 400 error to client, AT didn't work
> - c= lient presents RT to auth server
> - auth server returns new AT, RT w= orked
> - [or] auth server returns 400 error to client, RT didn't wor= k
> - client has to go get a new auth grant from the resource owner, = start over
>

the answer seems to be that whenever it gets 400 = after presenting AT to
resource it should try to use RT next to get a new AT= , I guess it was
not really obvious to me though now that I think about= it, it makes
sense, 400 at the initial try means that the current AT i= s not good
enough for whatever reasons

Thanks, Sergey

>= ; -- Justin
>
>
> On 11/21/2012 06:50 AM, Sergey Beryozki= n wrote:
>> Hi
>>
>> I'm looking for some guidan= ce on how the client which already owns an
>> access token can dec= ide, after getting HTTP 400 back from the resource
>> server it tr= ies to access on behalf of the end user/resource owner,
>> can dec= ide that the refresh token it has can now be used to get a new
>> = access token.
>>
>> [1] refers to various error condition= s but it is not obvious to me
>> that the same conditions (some of= them) should or can be reported
>> during the actual client accessing the protected resource.
>>
>> My questi= on is, what error condition, if any, from [1] should be
>> reporte= d back to the client failing to access a protected resource due
>>= to the access token being invalid or expired, so that it can help the
&= gt;> client who also owns the refresh token to decide it can use it now.= ..
>>
>> Thanks, Sergey
>>
>> [1] http:= //tools.ietf.org/html/rfc6749#section-5.2
>> _____________________= __________________________
>> OAuth mailing list
>> OAuth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/oauth
>_______________________________________________
OAuth mailing list
= OAuth@ietf.org
https://www.ietf.org/m= ailman/listinfo/oauth


---368338466-1301387149-1353509607=:45415-- From wmills_92105@yahoo.com Wed Nov 21 06:53:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF72721F8634 for ; Wed, 21 Nov 2012 06:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0i4aypKezDX for ; Wed, 21 Nov 2012 06:53:56 -0800 (PST) Received: from nm37-vm6.bullet.mail.ne1.yahoo.com (nm37-vm6.bullet.mail.ne1.yahoo.com [98.138.229.134]) by ietfa.amsl.com (Postfix) with ESMTP id E930D21F862E for ; Wed, 21 Nov 2012 06:53:55 -0800 (PST) Received: from [98.138.226.176] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 21 Nov 2012 14:53:52 -0000 Received: from [98.138.89.194] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 21 Nov 2012 14:53:52 -0000 Received: from [127.0.0.1] by omp1052.mail.ne1.yahoo.com with NNFMP; 21 Nov 2012 14:53:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 792992.97620.bm@omp1052.mail.ne1.yahoo.com Received: (qmail 45654 invoked by uid 60001); 21 Nov 2012 14:53:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353509632; bh=NdHocHYzGLB6pyIKuIBZnadZDXufvCUuc92mGoFNuIA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=d9ORZn4df8nA7Fc/cmCXM4Caibu2+qf30jTIIv5qjfLI5zz8khu2Tr/0MMgUiSUbgBM0u83bA8XfOJhpS+S+pSjcmGnXJGIIwKD5u7ezEKo1hxDbZaDDDU4Ve25dlu99cpP8yRKnUbzzyY0A13RqT0w/kPiFlOF+47dsDzdvp/g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=curH2kMBDAfr6kelh7l3VE7nxICiw3u4Yx92i6H5JeoqEoqdLBVuCI7H/2C3YtxYiFxlYzsyPnlhIQjQDoCzNZeR7NQWsyCz72TyUA/MIvX3loZbEd0o6cPASnEzYYUVFsjohOnJJn0//ELwU+UfAoaQ41/hAYihS8qmvJxGe6Q=; X-YMail-OSG: MN22AWsVM1mxUL7yIbHNAv840gT_LSPtJYZ9LvI7sgsoNc7 k0324jxSZmwjMzq6ofDNcDSLeNUWo4cgIwWhzC9Od8k5XAvP9rc8DYFhwlDj Iu_FV6.DKPmz8zPE9vZHgGrRX6najFGh192A87eKYb4Zaej0ezCm2WgS89Qv WCY8Iz64HuaufE2rUEjTjzY6u3hWemQwRWO1IbNwaenCjOMAetkcRZGmqIVY q9GYyYCkCYh1rYkYb6rE_ABK_7364NyvQlL.A4twUcp460NxCYqNut5YocZR 3Wjjr0MRrpJUQ9XyatYbgJpAx8bIBUnCxvc7DRgMFiWqmMgYflkzdxZvM3Ny JmK14BXAK6fOReyilc1EVALyBtB5zW_Du7lvWa3RgACYNkIAbV.u2q4jEUEE NEbCpwFJeFU0crTMlFLY3OEKOonTxMdCzD07Rmt.kRk27SjRDkcaaqDoCoWa 0zz7_CBanITSQWSsYYfd0YG50kSZu29TjvDZoz2.AhbTwvU_ksqMDDrJ84U5 HcwwsJBIQv5Ne9BGxuunACcflRA9twifgAd6YaxLejtw- Received: from [209.131.62.115] by web31801.mail.mud.yahoo.com via HTTP; Wed, 21 Nov 2012 06:53:52 PST X-Rocket-MIMEInfo: 001.001, NDAxIG5vdCA0MDAKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXRyZS5vcmc.ClRvOiBTZXJnZXkgQmVyeW96a2luIDxzYmVyeW96a2luQGdtYWlsLmNvbT4gCkNjOiBvYXV0aEBpZXRmLm9yZyAKU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyMSwgMjAxMiA2OjExIEFNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEhvdyB0aGUgY2xpZW50IGNhbiBkZWNpZGUgaXQgaXMgdGltZSB0byB1c2UgdGhlIHJlZnJlc2ggdG9rZW4KIApUaGVyZScBMAEBAQE- X-Mailer: YahooMailWebService/0.8.127.475 References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> Message-ID: <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Wed, 21 Nov 2012 06:53:52 -0800 (PST) From: William Mills To: Justin Richer , Sergey Beryozkin In-Reply-To: <50ACE0FF.4060807@mitre.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-1011579846-1353509632=:36061" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 14:53:56 -0000 ---368338466-1011579846-1353509632=:36061 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 401 not 400=0A=0A=0A________________________________=0A From: Justin Richer= =0ATo: Sergey Beryozkin =0ACc: o= auth@ietf.org =0ASent: Wednesday, November 21, 2012 6:11 AM=0ASubject: Re: = [OAUTH-WG] How the client can decide it is time to use the refresh token=0A= =0AThere's no signaling regarding the validity of the refresh token from t= he protected resource. In more distributed setups, the protected resources = know nothing about the refresh tokens because the PR never sees them. In an= y case. the code path is fairly straightforward, even if both tokens are ex= pired:=0A=0A- client presents AT to resource=0A=A0 - resource returns data= , AT worked=0A=A0 - [or] resource returns 400 error to client, AT didn't w= ork=0A=A0 =A0 =A0 - client presents RT to auth server=0A=A0 =A0 =A0 =A0 - = auth server returns new AT, RT worked=0A=A0 =A0 =A0 =A0 - [or] auth server= returns 400 error to client, RT didn't work=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 - client has to go get a new auth grant from the resource owner, start = over=0A=0A-- Justin=0A=0A=0AOn 11/21/2012 06:50 AM, Sergey Beryozkin wrote:= =0A> Hi=0A> =0A> I'm looking for some guidance on how the client which alre= ady owns an access token can decide, after getting HTTP 400 back from the r= esource server it tries to access on behalf of the end user/resource owner,= can decide that the refresh token it has can now be used to get a new acce= ss token.=0A> =0A> [1] refers to various error conditions but it is not obv= ious to me that the same conditions (some of them) should or can be reporte= d during the actual client accessing the protected resource.=0A> =0A> My qu= estion is, what error condition, if any, from [1] should be reported back t= o the client failing to access a protected resource due to the access token= being invalid or expired, so that it can help the client who also owns the= refresh token to decide it can use it now...=0A> =0A> Thanks, Sergey=0A> = =0A> [1] http://tools.ietf.org/html/rfc6749#section-5.2=0A> _______________= ________________________________=0A> OAuth mailing list=0A> OAuth@ietf.org= =0A> https://www.ietf.org/mailman/listinfo/oauth=0A=0A_____________________= __________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://= www.ietf.org/mailman/listinfo/oauth ---368338466-1011579846-1353509632=:36061 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
401 not 400

From: Justin Richer <= jricher@mitre.org>
To:<= /b> Sergey Beryozkin <sberyozkin@gmail.com>
Cc: oauth@ietf.org
Sent: Wednesday, November 21, 2012 6:11 AM
Subject: Re: [OAUTH-WG] How = the client can decide it is time to use the refresh token
=0AThere's no signaling regarding the validity of the refresh token f= rom the protected resource. In more distributed setups, the protected resou= rces know nothing about the refresh tokens because the PR never sees them. = In any case. the code path is fairly straightforward, even if both tokens a= re expired:

- client presents AT to resource
  - resource = returns data, AT worked
  - [or] resource returns 400 error to cli= ent, AT didn't work
      - client presents RT to auth se= rver
        - auth server returns new AT, RT worke= d
        - [or] auth server returns 400 error to c= lient, RT didn't work
              &= nbsp; - client has to go get a new auth grant from the resource owner, star= t over

-- Justin


On 11/21/2012 06:50 AM, Sergey Beryozki= n wrote:
> Hi
>
> I'm looking for some guidance on how t= he client which already owns an access token can decide, after getting HTTP 4= 00 back from the resource server it tries to access on behalf of the end us= er/resource owner, can decide that the refresh token it has can now be used= to get a new access token.
>
> [1] refers to various error co= nditions but it is not obvious to me that the same conditions (some of them= ) should or can be reported during the actual client accessing the protecte= d resource.
>
> My question is, what error condition, if any, = from [1] should be reported back to the client failing to access a protecte= d resource due to the access token being invalid or expired, so that it can= help the client who also owns the refresh token to decide it can use it no= w...
>
> Thanks, Sergey
>
> [1] http://tools.ietf= .org/html/rfc6749#section-5.2
> _____________________________________= __________
> OAuth mailing list
> OAuth@iet= f.org
> https://www.ietf.org/mailman/listinfo/oauth

___= ____________________________________________
OAuth mailing list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth


=
---368338466-1011579846-1353509632=:36061-- From sberyozkin@gmail.com Wed Nov 21 08:07:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2097221F8665 for ; Wed, 21 Nov 2012 08:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEwjH16SdbeY for ; Wed, 21 Nov 2012 08:07:52 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3161B21F8654 for ; Wed, 21 Nov 2012 08:07:51 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so5973562lah.31 for ; Wed, 21 Nov 2012 08:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6He+bIjiEM0o5Bp4+5oq13DA8u6q96sHh51TmBzWk2Y=; b=1BMCXZMKhb514bPObGPS1ZJ6x6Q9rnjbXQtK0MfBnoqIWuFIgqDhChccmS3fO97eRM 7Pjei5WNRBm6M1U4ssQIeoXarsJoWeDffBowVKk38K6JqT0/E0JEDjRZ9qzeWsyBXTIU 9IJGfaQ9igyXzFhrD4fo5Y1fNQP5SzqM3lORQEzURjv+Yc7AUvdxh07XWtZwPDiW8u1l ArIMUCyE+L+e/2Z6QfwgwgGw8nM/+tQDryvjiXknvLJDXs6pSU+kW/eqh6nMy5mr2dnO vvM90/m22rGODMgX8UjBtIHtbIcB3aeztSk+wN4ps44ZjtvZHF5oxDErGGlcPWKvtnT/ D6CA== Received: by 10.152.132.3 with SMTP id oq3mr18038395lab.18.1353514071108; Wed, 21 Nov 2012 08:07:51 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id gr12sm243155lab.3.2012.11.21.08.07.49 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 08:07:49 -0800 (PST) Message-ID: <50ACFC53.5080103@gmail.com> Date: Wed, 21 Nov 2012 16:07:47 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: William Mills References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com> In-Reply-To: <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 16:07:53 -0000 On 21/11/12 14:53, William Mills wrote: > 401 not 400 Yes, thanks,our code does return 401 in the client to resource path failure case. I wonder it would make sense to clarify it in the future revision somehow. I guess it is just HTTP at the stage of the client accessing the resource and may be no extra clarification is needed; That said the only place where 401 is mentioned is the section I linked to below which says "MAY" while 400 is also mentioned at the the top of the section, where the section itself deals with errors to do with the client requesting an access token, while the 'client to resource' path is not covered. Either way, thanks for the answers/help Sergey > > ------------------------------------------------------------------------ > *From:* Justin Richer > *To:* Sergey Beryozkin > *Cc:* oauth@ietf.org > *Sent:* Wednesday, November 21, 2012 6:11 AM > *Subject:* Re: [OAUTH-WG] How the client can decide it is time to use > the refresh token > > There's no signaling regarding the validity of the refresh token from > the protected resource. In more distributed setups, the protected > resources know nothing about the refresh tokens because the PR never > sees them. In any case. the code path is fairly straightforward, even if > both tokens are expired: > > - client presents AT to resource > - resource returns data, AT worked > - [or] resource returns 400 error to client, AT didn't work > - client presents RT to auth server > - auth server returns new AT, RT worked > - [or] auth server returns 400 error to client, RT didn't work > - client has to go get a new auth grant from the resource owner, start over > > -- Justin > > > On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: > > Hi > > > > I'm looking for some guidance on how the client which already owns an > access token can decide, after getting HTTP 400 back from the resource > server it tries to access on behalf of the end user/resource owner, can > decide that the refresh token it has can now be used to get a new access > token. > > > > [1] refers to various error conditions but it is not obvious to me > that the same conditions (some of them) should or can be reported during > the actual client accessing the protected resource. > > > > My question is, what error condition, if any, from [1] should be > reported back to the client failing to access a protected resource due > to the access token being invalid or expired, so that it can help the > client who also owns the refresh token to decide it can use it now... > > > > Thanks, Sergey > > > > [1] http://tools.ietf.org/html/rfc6749#section-5.2 > > _______________________________________________ > > 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 > > From jricher@mitre.org Wed Nov 21 12:22:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F73421F87C8 for ; Wed, 21 Nov 2012 12:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPtXvayA2YiR for ; Wed, 21 Nov 2012 12:22:18 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3A021F85FC for ; Wed, 21 Nov 2012 12:22:18 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9F7121F08AD; Wed, 21 Nov 2012 15:22:17 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 934661F08A8; Wed, 21 Nov 2012 15:22:17 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 21 Nov 2012 15:22:17 -0500 Message-ID: <50AD37A6.9070805@mitre.org> Date: Wed, 21 Nov 2012 15:20:54 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: William Mills References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com> In-Reply-To: <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------030502070404040505080906" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 20:22:19 -0000 --------------030502070404040505080906 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Yes, thank you. I should have said 4XX for what I really meant there -- "whatever the right authorization error code is". :) -- Justin On 11/21/2012 09:53 AM, William Mills wrote: > 401 not 400 > > ------------------------------------------------------------------------ > *From:* Justin Richer > *To:* Sergey Beryozkin > *Cc:* oauth@ietf.org > *Sent:* Wednesday, November 21, 2012 6:11 AM > *Subject:* Re: [OAUTH-WG] How the client can decide it is time to use > the refresh token > > There's no signaling regarding the validity of the refresh token from > the protected resource. In more distributed setups, the protected > resources know nothing about the refresh tokens because the PR never > sees them. In any case. the code path is fairly straightforward, even > if both tokens are expired: > > - client presents AT to resource > - resource returns data, AT worked > - [or] resource returns 400 error to client, AT didn't work > - client presents RT to auth server > - auth server returns new AT, RT worked > - [or] auth server returns 400 error to client, RT didn't work > - client has to go get a new auth grant from the > resource owner, start over > > -- Justin > > > On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: > > Hi > > > > I'm looking for some guidance on how the client which already owns > an access token can decide, after getting HTTP 400 back from the > resource server it tries to access on behalf of the end user/resource > owner, can decide that the refresh token it has can now be used to get > a new access token. > > > > [1] refers to various error conditions but it is not obvious to me > that the same conditions (some of them) should or can be reported > during the actual client accessing the protected resource. > > > > My question is, what error condition, if any, from [1] should be > reported back to the client failing to access a protected resource due > to the access token being invalid or expired, so that it can help the > client who also owns the refresh token to decide it can use it now... > > > > Thanks, Sergey > > > > [1] http://tools.ietf.org/html/rfc6749#section-5.2 > > _______________________________________________ > > 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 > > --------------030502070404040505080906 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Yes, thank you. I should have said 4XX for what I really meant there -- "whatever the right authorization error code is". :)

 -- Justin

On 11/21/2012 09:53 AM, William Mills wrote:
401 not 400

From: Justin Richer <jricher@mitre.org>
To: Sergey Beryozkin <sberyozkin@gmail.com>
Cc: oauth@ietf.org
Sent: Wednesday, November 21, 2012 6:11 AM
Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token

There's no signaling regarding the validity of the refresh token from the protected resource. In more distributed setups, the protected resources know nothing about the refresh tokens because the PR never sees them. In any case. the code path is fairly straightforward, even if both tokens are expired:

- client presents AT to resource
  - resource returns data, AT worked
  - [or] resource returns 400 error to client, AT didn't work
      - client presents RT to auth server
        - auth server returns new AT, RT worked
        - [or] auth server returns 400 error to client, RT didn't work
                - client has to go get a new auth grant from the resource owner, start over

-- Justin


On 11/21/2012 06:50 AM, Sergey Beryozkin wrote:
> Hi
>
> I'm looking for some guidance on how the client which already owns an access token can decide, after getting HTTP 400 back from the resource server it tries to access on behalf of the end user/resource owner, can decide that the refresh token it has can now be used to get a new access token.
>
> [1] refers to various error conditions but it is not obvious to me that the same conditions (some of them) should or can be reported during the actual client accessing the protected resource.
>
> My question is, what error condition, if any, from [1] should be reported back to the client failing to access a protected resource due to the access token being invalid or expired, so that it can help the client who also owns the refresh token to decide it can use it now...
>
> Thanks, Sergey
>
> [1] http://tools.ietf.org/html/rfc6749#section-5.2
> _______________________________________________
> 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



--------------030502070404040505080906-- From hannes.tschofenig@gmx.net Wed Nov 21 13:05:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FFA21F8818 for ; Wed, 21 Nov 2012 13:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhs5sBm5CBt9 for ; Wed, 21 Nov 2012 13:05:24 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8834621F8816 for ; Wed, 21 Nov 2012 13:05:23 -0800 (PST) Received: (qmail invoked by alias); 21 Nov 2012 21:05:22 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp004) with SMTP; 21 Nov 2012 22:05:22 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/TPCB9mRbTMK1wT8++7BhbsADkhMz11vJH/a0fYF u9fGUXpMpHRHUc From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Nov 2012 23:05:21 +0200 Message-Id: <2CD2AA8A-C55E-455B-B380-D8846A3C5F85@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Security Requirements / Security Use Cases - Conference Call Poll X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 21:05:25 -0000 Hi all,=20 Based on the discussions at the OAuth WG meeting at IETF#85 we are = trying to determine suitable dates for conference calls for the OAuth WG = to discuss security requirements and use cases. Here is the link to the Doodle poll: http://www.doodle.com/smvh5pmcqc43dti3 Deadline for providing your input is the **28th November 2012**. Then, we will see whether we can find suitable dates for conference = calls and announce them on the list.=20 It is difficult to find a convenient time for everyone since we have = active participants from everywhere.=20 For this reason we have provided lots of options.=20 Ciao Hannes & Derek From hannes.tschofenig@gmx.net Thu Nov 22 04:30:39 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB23821F8958 for ; Thu, 22 Nov 2012 04:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NGQKqGSnIRv for ; Thu, 22 Nov 2012 04:30:38 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 570BD21F8963 for ; Thu, 22 Nov 2012 04:30:37 -0800 (PST) Received: (qmail invoked by alias); 22 Nov 2012 12:30:36 -0000 Received: from unknown (EHLO [10.255.131.102]) [194.251.119.201] by mail.gmx.net (mp032) with SMTP; 22 Nov 2012 13:30:36 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18eP9NNu4Aes1D/xcWhAA2zASskEp8H2RqngQRh6t 3yJ5k5vnntIWPJ From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Nov 2012 14:30:35 +0200 Message-Id: <3B84788E-05E5-4AE4-B819-458BBBB36664@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Writeup for Assertion Framework for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 12:30:40 -0000 Here is the writeup I am going to send to Stephen. If there are some = last remarks please let me know. I will submit it once I get the confirm = from the authors that appropriate IPR disclosures have been made.=20 ------- Writeup for Assertion Framework for OAuth 2.0 = (1) What type of RFC is being requested (BCP, Proposed Standard, = Internet Standard, Informational, Experimental, or Historic)? Why is = this the proper type of RFC? Is this type of RFC indicated in the title = page header? The RFC type is 'Standards Track' and the type is indicated in the title = page. Although the document is architectural in nature it is the = umbrella document for two other 'Standards Track' specifications that = extend this document with SAML and JSON specific details.=20 (2) The IESG approval announcement includes a Document Announcement = Write-Up. Please provide such a Document Announcement Write-Up. Recent = examples can be found in the "Action" announcements for approved = documents. The approval announcement contains the following sections: Technical Summary: The Assertion Framework for OAuth 2.0 allows the use of assertions in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. Working Group Summary: Was there anything in WG process that is worth noting? For example, was = there controversy about particular points or were there decisions where = the consensus was particularly rough? There was no controversy around this document.=20 Document Quality: The working group decided to separate the framework for assertion = handling from instance documents supporting SAML assertion and = JSON-based encoded tokens. Readers who want to implement the = functionality also need to consult one of the extension documents.=20 Personnel: The document shepherd is Hannes Tschofenig and the responsible area = director is Stephen Farrell.=20 (3) Briefly describe the review of this document that was performed by = the Document Shepherd. If this version of the document is not ready for = publication, please explain why the document is being forwarded to the = IESG. The draft authors believe that this document is ready for publication. = The document shepherd has reviewed the document and provided detailed = comments. Those review comments have been taken into account and have = lead to clarifications regarding the claimed security benefits. =20 (4) Does the document Shepherd have any concerns about the depth or = breadth of the reviews that have been performed? This document has gotten feedback from the working group but certainly = not to the extend other OAuth working group documents, like the OAuth = Core specification and the OAuth Bearer Token specification, had = received. This can be explained by the focused use cases. The ability to = use assertions in the way described by the document is not needed in = every deployment.=20 (5) Do portions of the document need review from a particular or from = broader perspective, e.g., security, operational complexity, AAA, DNS, = DHCP, XML, or internationalization? If so, describe the review that took = place. Feedback from the security community would certain be appreciated. = Additionally, it would be helpful to get reviews from outside the group = to ensure that the use cases and the offered security benefits are = understood.=20 (6) Describe any specific concerns or issues that the Document Shepherd = has with this document that the Responsible Area Director and/or the = IESG should be aware of? For example, perhaps he or she is uncomfortable = with certain parts of the document, or has concerns whether there really = is a need for it. In any event, if the WG has discussed those issues and = has indicated that it still wishes to advance the document, detail those = concerns here. The shepherd still believes that the document authors could have done a = better job in explaining the use cases for which the proposed = functionality are applicable. The concerns have been raised in = http://www.ietf.org/mail-archive/web/oauth/current/msg09961.html (7) Has each author confirmed that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed. If not, explain why? [Hannes: Dropped authors a mail.] (8) Has an IPR disclosure been filed that references this document? If = so, summarize any WG discussion and conclusion regarding the IPR = disclosures. No IPR disclosures have been filed.=20 (9) How solid is the WG consensus behind this document? Does it = represent the strong concurrence of a few individuals, with others being = silent, or does the WG as a whole understand and agree with it? Only a few working group participants have reviewed the document but = enough to move forward with the publication.=20 (10) Has anyone threatened an appeal or otherwise indicated extreme = discontent? If so, please summarise the areas of conflict in separate = email messages to the Responsible Area Director. (It should be in a = separate email because this questionnaire is publicly available.) No appeal or extreme discontent has been raised.=20 (11) Identify any ID nits the Document Shepherd has found in this = document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts = Checklist). Boilerplate checks are not enough; this check needs to be = thorough. There is one outdated reference: draft-ietf-oauth-urn-sub-ns has been = published as RFC 6755 (12) Describe how the document meets any required formal review = criteria, such as the MIB Doctor, media type, and URI type reviews. There is no such review necessary.=20 (13) Have all references within this document been identified as either = normative or informative? Yes.=20 (14) Are there normative references to documents that are not ready for = advancement or are otherwise in an unclear state? If such normative = references exist, what is the plan for their completion? Yes.=20 (15) Are there downward normative references references (see RFC 3967)? = If so, list these downward references to support the Area Director in = the Last Call procedure. No, there is no need for a downref.=20 (16) Will publication of this document change the status of any existing = RFCs? Are those RFCs listed on the title page header, listed in the = abstract, and discussed in the introduction? If the RFCs are not listed = in the Abstract and Introduction, explain why, and point to the part of = the document where the relationship of this document to the other RFCs = is discussed. If this information is not in the document, explain why = the WG considers it unnecessary. The publication of this document does not change the status of other = RFCs.=20 (17) Describe the Document Shepherd's review of the IANA considerations = section, especially with regard to its consistency with the body of the = document. Confirm that all protocol extensions that the document makes = are associated with the appropriate reservations in IANA registries. = Confirm that any referenced IANA registries have been clearly = identified. Confirm that newly created IANA registries include a = detailed specification of the initial contents for the registry, that = allocations procedures for future registrations are defined, and a = reasonable name for the new registry has been suggested (see RFC 5226). The document adds three values to an existing registry established with = RFC 6749.=20 (18) List any new IANA registries that require Expert Review for future = allocations. Provide any public guidance that the IESG would find useful = in selecting the IANA Experts for these new registries. The document only adds entries to existing registries and does not = define any new registries.=20 (19) Describe reviews and automated checks performed by the Document = Shepherd to validate sections of the document written in a formal = language, such as XML code, BNF rules, MIB definitions, etc. There are only snippets for examples and no pseudo code is contained = that requires validation.=20 =20= From pathogenix@gmail.com Fri Nov 23 04:43:23 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC05721F85C2 for ; Fri, 23 Nov 2012 04:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djj+o5ffl+rV for ; Fri, 23 Nov 2012 04:43:23 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 17BAE21F8590 for ; Fri, 23 Nov 2012 04:43:22 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so409582wgb.13 for ; Fri, 23 Nov 2012 04:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tboaxI8KCcYpTOl4VbDdUrB1qLNBWLrRTmZjSrz4MaE=; b=woXPB3yDvcOsEtNaFdvdeVrwpB51/rjBPM7I/Ji8arQzB3VxRbLAvh5CTz1D4wFtiG 6JS2K/YZwAA129v5YTpLFS0uXDxfpmImUyd+4ALY9Ap9g3406C05ngjm7qYf+zaRNazH Mdr3QCiUcsyUlvadzZV9F3cEUQSFuSl2FIsgVNoYSTkmtzOSU4gCFbHDhgDg5i/bPaPy pPrUQ/YZFBW7iX7121j2oGKWyyLsoZRM3a5cD6cblDV3OJdlDC3SOauumvtIyC1HSfOo 22IsYlyJm9Z4kR0Lj0/p7Xup7OHixFTO0bptTeafkqsXpwHDmTM98446wLs6VbRIJwOz calA== MIME-Version: 1.0 Received: by 10.180.73.80 with SMTP id j16mr6043677wiv.5.1353674601980; Fri, 23 Nov 2012 04:43:21 -0800 (PST) Received: by 10.194.25.202 with HTTP; Fri, 23 Nov 2012 04:43:21 -0800 (PST) Date: Fri, 23 Nov 2012 12:43:21 +0000 Message-ID: From: Bob Gregory To: OAuth WG Content-Type: multipart/alternative; boundary=f46d043bdf38cae36e04cf28ed64 Subject: [OAUTH-WG] Token refresh and The Two Generals X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 12:43:24 -0000 --f46d043bdf38cae36e04cf28ed64 Content-Type: text/plain; charset=ISO-8859-1 We've had OAuth2 running successfully for a while now, but we're finding that mobile applications have frequent problems with the refresh flow where a refresh request is made, but the network connection fails before the new AT/RT pair is received, leading to a "lost grant". In server-logs we can see that the token has been refreshed, and a new RT issued, but the client is stuck with the old invalidated RT. This problem has been reported by two separate client applications, both of whom are using a retry-mechanism for API requests since they expect an unreliable network connection. Does anybody have any guidance on this issue, or is there any work in an extension to address the issue of lost grants for token refreshes? -- Q. How many members of a demographic group does it take to perform a specified task? A. A finite number; one to perform the task, and the remainder to act in a manner stereotypical of the group in question. --f46d043bdf38cae36e04cf28ed64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We've had OAuth2 running successfully for a while now, but we're fi= nding that mobile applications have frequent problems with the refresh flow= where a refresh request is made, but the network connection fails before t= he new AT/RT pair is received, leading to a "lost grant".=A0

In server-logs we can see that the token has been refreshed,= and a new RT issued, but the client is stuck with the old invalidated RT.<= br>

This problem has been reported by two separate = client applications, both of whom are using a retry-mechanism for API reque= sts since they expect an unreliable network connection.

Does anybody have any guidance on this issue, or is the= re any work in an extension to address the issue of lost grants for token r= efreshes?


--
Q. How many mem= bers of a demographic group does it take to perform a specified task?
A. A finite number; one to perform the task, and the remainder to act in a = manner stereotypical of the group in question.

--f46d043bdf38cae36e04cf28ed64-- From Michael.Jones@microsoft.com Fri Nov 23 12:32:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521EA21F8660 for ; Fri, 23 Nov 2012 12:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB9nBUT8gdwV for ; Fri, 23 Nov 2012 12:32:32 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id B36A121F8644 for ; Fri, 23 Nov 2012 12:32:31 -0800 (PST) Received: from mail36-db3-R.bigfish.com (10.3.81.227) by DB3EHSOBE009.bigfish.com (10.3.84.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 23 Nov 2012 20:32:30 +0000 Received: from mail36-db3 (localhost [127.0.0.1]) by mail36-db3-R.bigfish.com (Postfix) with ESMTP id 34D5138046A; Fri, 23 Nov 2012 20:32:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371I542Mzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h) Received-SPF: pass (mail36-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail36-db3 (localhost.localdomain [127.0.0.1]) by mail36-db3 (MessageSwitch) id 1353702748318856_4501; Fri, 23 Nov 2012 20:32:28 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.247]) by mail36-db3.bigfish.com (Postfix) with ESMTP id 4AD934A0240; Fri, 23 Nov 2012 20:32:28 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 23 Nov 2012 20:32:27 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Fri, 23 Nov 2012 20:32:23 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] Writeup for Assertion Framework for OAuth 2.0 Thread-Index: AQHNyK06wdvTmPUQ9kuN8B1BpRChUpf33rDg Date: Fri, 23 Nov 2012 20:32:23 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943668FD06A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <3B84788E-05E5-4AE4-B819-458BBBB36664@gmx.net> In-Reply-To: <3B84788E-05E5-4AE4-B819-458BBBB36664@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Writeup for Assertion Framework for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 20:32:34 -0000 You answered the question "(14) Are there normative references to documents= that are not ready for advancement or are otherwise in an unclear state? I= f such normative references exist, what is the plan for their completion?" = with a "yes". Shouldn't this be "no"? If it's really "yes", what document= are you referring to? I'd change: "Feedback from the security community would certain be appreciated. Additi= onally, it would be helpful to get reviews from outside the group to ensure= that the use cases and the offered security benefits are understood." to: "Additional feedback from the security community would be appreciated. Als= o, it would be helpful to get additional reviews from outside the group fro= m people already using assertions to ensure that the use cases and the offe= red security benefits are well understood." I'd change: "Only a few working group participants have reviewed the document but enou= gh to move forward with the publication." to: "Only a subset of working group participants have reviewed the document bu= t enough to move forward with the publication. However, because the SAML a= nd JWT Assertion Profiles based on it have been implemented and are being u= sed by a number of parties, we have high confidence in the sufficiency and = accuracy of the document text." Also, I didn't see the implementation statement. Does that go separately? -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Thursday, November 22, 2012 4:31 AM To: oauth@ietf.org WG Subject: [OAUTH-WG] Writeup for Assertion Framework for OAuth 2.0 Here is the writeup I am going to send to Stephen. If there are some last r= emarks please let me know. I will submit it once I get the confirm from the= authors that appropriate IPR disclosures have been made.=20 ------- Writeup for Assertion Framework for OAuth 2.0 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? The RFC type is 'Standards Track' and the type is indicated in the title pa= ge. Although the document is architectural in nature it is the umbrella doc= ument for two other 'Standards Track' specifications that extend this docum= ent with SAML and JSON specific details.=20 (2) The IESG approval announcement includes a Document Announcement Write-U= p. Please provide such a Document Announcement Write-Up. Recent examples ca= n be found in the "Action" announcements for approved documents. The approv= al announcement contains the following sections: Technical Summary: The Assertion Framework for OAuth 2.0 allows the use of assertions in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. Working Group Summary: Was there anything in WG process that is worth noting? For example, was the= re controversy about particular points or were there decisions where the co= nsensus was particularly rough? There was no controversy around this document.=20 Document Quality: The working group decided to separate the framework for assertion handling = from instance documents supporting SAML assertion and JSON-based encoded to= kens. Readers who want to implement the functionality also need to consult = one of the extension documents.=20 Personnel: The document shepherd is Hannes Tschofenig and the responsible area directo= r is Stephen Farrell.=20 (3) Briefly describe the review of this document that was performed by the = Document Shepherd. If this version of the document is not ready for publica= tion, please explain why the document is being forwarded to the IESG. The draft authors believe that this document is ready for publication. The = document shepherd has reviewed the document and provided detailed comments.= Those review comments have been taken into account and have lead to clarif= ications regarding the claimed security benefits. =20 (4) Does the document Shepherd have any concerns about the depth or breadth= of the reviews that have been performed? This document has gotten feedback from the working group but certainly not = to the extend other OAuth working group documents, like the OAuth Core spec= ification and the OAuth Bearer Token specification, had received. This can = be explained by the focused use cases. The ability to use assertions in the= way described by the document is not needed in every deployment.=20 (5) Do portions of the document need review from a particular or from broad= er perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML= , or internationalization? If so, describe the review that took place. Feedback from the security community would certain be appreciated. Addition= ally, it would be helpful to get reviews from outside the group to ensure t= hat the use cases and the offered security benefits are understood.=20 (6) Describe any specific concerns or issues that the Document Shepherd has= with this document that the Responsible Area Director and/or the IESG shou= ld be aware of? For example, perhaps he or she is uncomfortable with certai= n parts of the document, or has concerns whether there really is a need for= it. In any event, if the WG has discussed those issues and has indicated t= hat it still wishes to advance the document, detail those concerns here. The shepherd still believes that the document authors could have done a bet= ter job in explaining the use cases for which the proposed functionality ar= e applicable. The concerns have been raised in http://www.ietf.org/mail-arc= hive/web/oauth/current/msg09961.html (7) Has each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 have= already been filed. If not, explain why? [Hannes: Dropped authors a mail.] (8) Has an IPR disclosure been filed that references this document? If so, = summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed.=20 (9) How solid is the WG consensus behind this document? Does it represent t= he strong concurrence of a few individuals, with others being silent, or do= es the WG as a whole understand and agree with it? Only a few working group participants have reviewed the document but enough= to move forward with the publication.=20 (10) Has anyone threatened an appeal or otherwise indicated extreme discont= ent? If so, please summarise the areas of conflict in separate email messag= es to the Responsible Area Director. (It should be in a separate email beca= use this questionnaire is publicly available.) No appeal or extreme discontent has been raised.=20 (11) Identify any ID nits the Document Shepherd has found in this document.= (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).= Boilerplate checks are not enough; this check needs to be thorough. There is one outdated reference: draft-ietf-oauth-urn-sub-ns has been publi= shed as RFC 6755 (12) Describe how the document meets any required formal review criteria, s= uch as the MIB Doctor, media type, and URI type reviews. There is no such review necessary.=20 (13) Have all references within this document been identified as either nor= mative or informative? Yes.=20 (14) Are there normative references to documents that are not ready for adv= ancement or are otherwise in an unclear state? If such normative references= exist, what is the plan for their completion? Yes.=20 (15) Are there downward normative references references (see RFC 3967)? If = so, list these downward references to support the Area Director in the Last= Call procedure. No, there is no need for a downref.=20 (16) Will publication of this document change the status of any existing RF= Cs? Are those RFCs listed on the title page header, listed in the abstract,= and discussed in the introduction? If the RFCs are not listed in the Abstr= act and Introduction, explain why, and point to the part of the document wh= ere the relationship of this document to the other RFCs is discussed. If th= is information is not in the document, explain why the WG considers it unne= cessary. The publication of this document does not change the status of other RFCs.= =20 (17) Describe the Document Shepherd's review of the IANA considerations sec= tion, especially with regard to its consistency with the body of the docume= nt. Confirm that all protocol extensions that the document makes are associ= ated with the appropriate reservations in IANA registries. Confirm that any= referenced IANA registries have been clearly identified. Confirm that newl= y created IANA registries include a detailed specification of the initial c= ontents for the registry, that allocations procedures for future registrati= ons are defined, and a reasonable name for the new registry has been sugges= ted (see RFC 5226). The document adds three values to an existing registry established with RFC= 6749.=20 (18) List any new IANA registries that require Expert Review for future all= ocations. Provide any public guidance that the IESG would find useful in se= lecting the IANA Experts for these new registries. The document only adds entries to existing registries and does not define a= ny new registries.=20 (19) Describe reviews and automated checks performed by the Document Shephe= rd to validate sections of the document written in a formal language, such = as XML code, BNF rules, MIB definitions, etc. There are only snippets for examples and no pseudo code is contained that r= equires validation.=20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From internet-drafts@ietf.org Sat Nov 24 10:04:13 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD79D21F857E; Sat, 24 Nov 2012 10:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpYNwGEZqMHb; Sat, 24 Nov 2012 10:04:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1AD21F8570; Sat, 24 Nov 2012 10:03:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121124180345.16559.59853.idtracker@ietfa.amsl.com> Date: Sat, 24 Nov 2012 10:03:45 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 18:04:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : Token Revocation Author(s) : Torsten Lodderstedt Stefanie Dronia Marius Scurtescu Filename : draft-ietf-oauth-revocation-03.txt Pages : 7 Date : 2012-11-24 Abstract: This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same access grant. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-revocation-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From torsten@lodderstedt.net Sat Nov 24 10:07:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3892C21F850D for ; Sat, 24 Nov 2012 10:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwsL74iENunp for ; Sat, 24 Nov 2012 10:07:30 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4135E21F850B for ; Sat, 24 Nov 2012 10:07:30 -0800 (PST) Received: from [79.253.55.20] (helo=[192.168.71.42]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TcK8V-0008Fv-QP; Sat, 24 Nov 2012 19:07:28 +0100 Message-ID: <50B10CD7.7010806@lodderstedt.net> Date: Sat, 24 Nov 2012 19:07:19 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Justin Richer References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> In-Reply-To: <50ABA88F.4030500@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 18:07:35 -0000 Hi Justin, thanks for your review. I incorporated your comments/proposals into a new revision -03, which I just published (http://tools.ietf.org/html/draft-ietf-oauth-revocation-03). best regards, Torsten. Am 20.11.2012 16:58, schrieb Justin Richer: > Comments on the latest draft. Overall, it's in good shape, with a > little bit of tweaking to some of the new language I think it's about > ready for last call. > > 1. Introduction: > - "cleanup" as a verb should be two words here, "clean up" > - Remove extraneous commas, change > > "This prevents a situation, where there is > still a valid access grant for that particular client, > which the end- > user is not aware of." > > text to something more like: > "This behavior prevents a situation where there is > still a valid access grant for a particular client which > the end user is not aware of." > > 2. Token Revocation: > > - grammatical parallelism, suggest wording: > > "Implementations MUST support the revocation of refresh > tokens and > SHOULD support the revocation of access tokens." > > - questionable whether the above is really a SHOULD, though I > understand Google's argument for this as detailed in the Note > - Consider moving the Note on access tokens to a Section and > including a cross-reference to it > - "It therefore validates..." reads awkwardly, suggest rewording with: > > "These checks are used to validate whether the token > being presented > has been issued to the client presenting it." > > 3. Acknowledgements > - You don't need to list my middle initial, it sounds pretentious. ;) > > 5. Security Considerations > - "liklyhood" should be spelled "likelihood" > - countermeasures: make this a normative SHOULD? or MUST? > - "legitimate client to loss" should be "legitimate client to lose" > > > > -- Justin > > On 11/18/2012 11:40 AM, Torsten Lodderstedt wrote: >> Hi, >> >> the following changed were applied to the revocation draft: >> - focused draft on client-initiated token revocation, cut out >> self-care/portal stuff >> - added implementation note on access token revocation. >> - extended abstract >> - removed normative language from introduction >> >> regards, >> Torsten. >> >> Am 18.11.2012 17:37, schrieb internet-drafts@ietf.org: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Web Authorization Protocol >>> Working Group of the IETF. >>> >>> Title : Token Revocation >>> Author(s) : Torsten Lodderstedt >>> Stefanie Dronia >>> Marius Scurtescu >>> Filename : draft-ietf-oauth-revocation-02.txt >>> Pages : 7 >>> Date : 2012-11-18 >>> >>> Abstract: >>> This document proposes an additional endpoint for OAuth >>> authorization >>> servers, which allows clients to notify the authorization server >>> that >>> a previously obtained refresh or access token is no longer needed. >>> This allows the authorization server to cleanup security >>> credentials. >>> A revocation request will invalidate the actual token and, if >>> applicable, other tokens based on the same access grant. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-02 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-02 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 > From hannes.tschofenig@gmx.net Sat Nov 24 10:13:49 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C3921F8569 for ; Sat, 24 Nov 2012 10:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnhAuJb3m5-k for ; Sat, 24 Nov 2012 10:13:49 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id ABCD821F8554 for ; Sat, 24 Nov 2012 10:13:47 -0800 (PST) Received: (qmail invoked by alias); 24 Nov 2012 18:13:45 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp072) with SMTP; 24 Nov 2012 19:13:45 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18xuIV5zKgxPEEbYeW/XUsBVEUlyAP756pmtuAr1a YePQek+aBt8oQW From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 24 Nov 2012 20:13:42 +0200 Message-Id: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 18:13:49 -0000 Hi all,=20 this is a working group last call for draft-ietf-oauth-revocation-03 on = "Token Revocation". The draft is available here: http://tools.ietf.org/html/draft-ietf-oauth-revocation-03 Please send you comments to the OAuth mailing list by December 10, 2012. = =20 Thanks, Hannes & Derek From torsten@lodderstedt.net Sat Nov 24 10:18:03 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995F521F8569 for ; Sat, 24 Nov 2012 10:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31gU5YDalRPO for ; Sat, 24 Nov 2012 10:18:03 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.95]) by ietfa.amsl.com (Postfix) with ESMTP id D936F21F8570 for ; Sat, 24 Nov 2012 10:18:02 -0800 (PST) Received: from [79.253.55.20] (helo=[192.168.71.42]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TcKIj-0005W5-70; Sat, 24 Nov 2012 19:18:01 +0100 Message-ID: <50B10F50.4070700@lodderstedt.net> Date: Sat, 24 Nov 2012 19:17:52 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Security Developer References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090307050905070209060405" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: OAuth@ietf.org Subject: Re: [OAUTH-WG] Question related to OAuth access token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 18:18:03 -0000 This is a multi-part message in MIME format. --------------090307050905070209060405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, both options are viable. It depends on the purpose the token is used for in a particular deployment, esp. whether it carries the data about the resource and it owner or whether it merely represents the authorization of the particular client. regards, Torsten. Am 15.11.2012 21:03, schrieb Security Developer: > Hi, > > If an access token is either SAML or JWT in OAuth then what would be > the value in subject either resource owner or client application name? > > Thanks for your time. > > Regards, > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------090307050905070209060405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

both options are viable. It depends on the purpose the token is used for in a particular deployment, esp. whether it carries the data about the resource and it owner or whether it merely represents the authorization of the particular client.

regards,
Torsten.

Am 15.11.2012 21:03, schrieb Security Developer:
Hi,

If an access token is either SAML or JWT in OAuth then what would be the value in subject either resource owner or client application name?

Thanks for your time.

Regards,


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------090307050905070209060405-- From torsten@lodderstedt.net Sat Nov 24 10:42:21 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A74B21F852E for ; Sat, 24 Nov 2012 10:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueOuhFj+CzkT for ; Sat, 24 Nov 2012 10:42:21 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by ietfa.amsl.com (Postfix) with ESMTP id D29BE21F850B for ; Sat, 24 Nov 2012 10:42:20 -0800 (PST) Received: from [79.253.55.20] (helo=[192.168.71.42]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TcKgE-0000ZI-RP; Sat, 24 Nov 2012 19:42:19 +0100 Message-ID: <50B11502.2000509@lodderstedt.net> Date: Sat, 24 Nov 2012 19:42:10 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Richer, Justin P." , OAuth WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: [OAUTH-WG] Comments on draft-ietf-oauth-dyn-reg-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 18:42:21 -0000 Hi Justin, I think your draft is a significant step forward. Thanks for putting it together. Here are my detailed comments/questions: Whats the advantage of having two secrets for the same client_id, namely request_access_token and client_secret? Why not always issuing a secret and use it for authentication on this endpoint (in the same way as at the token endpoint)? Section 2.1. Some of those parameters seems to be OIDC-specific, e.g. default_max_age. I would suggest to remove those. I would also recommend to state the relation of the parameters to core _or_ extension features. For example, "jwk_url" is only be used if the AS supports JWT Bearer Tokens, right? When reading the document the first time, I was a bit lost since none of the parameters is explained in this section. I would therefore suggest to change order of sections 2 and 3. Security Considerations "An IdP can also make warnings against untrusted RPs in all cases, especially if they're dynamically registered, have not been trusted by any users at the IdP before, and want to use the logo feature." This reads funny since this whole document is about dynamic client registration, isn’t it? I think AS should generally be careful when displaying client meta data if they did not previously validate them. A client could also call itself Google or Facebook. This section must call this out aloud. Should external URLs be sanitized in order to prevent CSS and Request Forgery? regards, Torsten. From torsten@lodderstedt.net Sat Nov 24 10:47:17 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DD221F8527 for ; Sat, 24 Nov 2012 10:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.913 X-Spam-Level: X-Spam-Status: No, score=-0.913 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_40=-0.185, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnHxMM5gI0wL for ; Sat, 24 Nov 2012 10:47:17 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by ietfa.amsl.com (Postfix) with ESMTP id F242621F850D for ; Sat, 24 Nov 2012 10:47:16 -0800 (PST) Received: from [79.253.55.20] (helo=[192.168.71.42]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TcKl1-0005Sg-6D; Sat, 24 Nov 2012 19:47:15 +0100 Message-ID: <50B1162A.8020506@lodderstedt.net> Date: Sat, 24 Nov 2012 19:47:06 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Mike Jones , Nat Sakimura , John Bradley , OAuth WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: [OAUTH-WG] Comments on draft-ietf-oauth-json-web-token-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 18:47:17 -0000 Hi, I've got a few comments on your draft. I’m wondering why neither acr nor auth_time (which are used in OIDC) made their way into this spec? What is the difference between prn and the user_id claim OIDC uses? regards, Torsten. From Hannes.Tschofenig@gmx.net Sun Nov 25 11:49:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD93321F8671 for ; Sun, 25 Nov 2012 11:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwB3iaJbfAlK for ; Sun, 25 Nov 2012 11:49:00 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8285B21F8670 for ; Sun, 25 Nov 2012 11:48:59 -0800 (PST) Received: (qmail invoked by alias); 25 Nov 2012 19:48:57 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp040) with SMTP; 25 Nov 2012 20:48:57 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/8VSAL3M789f0z62Lsta1s0gEGniCyekv45nCoLJ dy8WIYCqba1+KH From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Nov 2012 21:48:56 +0200 Message-Id: <0DC3825F-D600-4239-8283-FB7E2CAC4514@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 19:49:00 -0000 Hi all,=20 I reviewed the document and I have a few questions (see below). I also = think that this document has to wait for the JOSE documents to complete = WGLC before it can be moved forward. It will have to wait anyway in the = queue because of the normative dependency.=20 =20 - Header In Section 3.1 you have an example of a JWT with an HMAC SHA-256 keyed = message digest.=20 I would have assumed that the header contains the key id so that the = receipient can actually decode it. I am sure you assume it implicitly = determines it (somehow) but wouldn't it be better practice to = additionally include the kid field to make it less ambigious?=20 - Namespace The document defines a couple of claims. Quite naturally one wants to = provide extension points since others will quite likely come up with new = claims in the near future. The obvious approach would be to use an IANA = registry to maintain uniqueness of the labels but without using a = namespace declaration concept like XML does.=20 =20 For some reason that does not seem to be enough to use IANA alone: the = document introduces three types of claims, namely Reserved Claim Names, = Public Claim Names, and Private Claim Names No mechanism is stated how these claims can be differentiated but = essentially everything is allowed. Section 2 ("Terminology") says that = the claims that are not registered through IANA may be Domain Names, = Object Identifiers (OIDs), UUIDs, etc.=20 Later in Section 4.2 it is said that public claims could be a URI, which = is again different to what is said in Section 2.=20 Furthermore, Private Claims (as defined in Section 4.3) do not seem to = have the requirement for uniqueness anymore even though Section 4 says = that claim names in a JWT have to be unique.=20 The danger is obviously that two parties define claim names that have = different semantic. This will lead to confusion. When claims with the = same names are added to a JWT then, per specification, the receiver will = have to fail.=20 Do we really need to support claims where uniqueness cannot be = guaranteed? Can we decide on a few namespace concepts rather than leaving the list = open-ended? What are the JOSE guys going to do about this issue? Btw, is it allowed to use JavaScript reserved keywords as claim names? * "Mandatory to Implement"/"Mandatory to Understand" Section 4 you write: " When used in a security-related context, implementations MUST understand and support all of the claims present; otherwise, the JWT MUST be rejected for processing. " In the same paragraph you write:=20 " Note however, that the set of claims that a JWT must contain to be considered valid is context-dependent and is outside the scope of this specification. " Wouldn't it also be application context dependent to decide how unknown = claims are dealt with. I fear that the above statement would lead to the problem that no = extensions are possible anymore since you cannot be sure that the = recipient understands all the extensions.=20 Then, in Section 4.1 you write: " The following claim names are reserved. None of the claims defined below are intended to be mandatory, but rather, provide a starting point for a set of useful, interoperable claims. " What does mandatory mean here? Given the statement you made above all = claims must be understood anyway.=20 Almost every claim description contains the following statement: "This = claim is OPTIONAL." What does this mean? Here are a few choices of what it could mean:=20 * A library does not need to implement it.=20 * When an entity receives a JWT with an optional claim it can safely = ignore it.=20 * When constructing a JWT payload this claim is optional to include.=20 =20 * Data Types I would suggest to move the two data types (IntDate & StringOrURI) into = a separate Section instead of leaving them in the terminology since you = are using RFC 2119 language there.=20 * MTI Algorithms You list a number of algorithms that must be implemented, namely = "RSA-PKCS1-1.5 with 2048 bit keys, AES-128-KW, AES-256-KW, AES-128-CBC, = and AES-256-CBC". While this may be a good choice for a Web environment = I doubt it is useful for other, more constrained use cases.=20 There are a few ways to deal with this, such as:=20 - Avoid a MTI list and use RECOMMENDED language. =20 - State the usage environment and thereby provide an escape clause for = other use cases.=20 - Outsource these algorithsm into a separate document that can be = updated independently.=20 * Security Consideration Section I think the text could be improved. I was hoping to see some text about = the plaintext JWS.=20 I will try to make a suggestion in the next few days. =20 * Examples To me it seems that Appendix A & Appendix B are a copy-and-paste of the = text in = http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07.=20 Maybe it would be better to replace the text with a reference to = draft-ietf-jose-json-web-signature-07. No need to artificially increase = the size of the document.=20 * References=20 The references to [JWA], [JWK], and [JWS] are incomplete. [JWS] and = [JWK] has to be, IMHO, a normative reference.=20 [USA15] is not a normative reference, IMHO.=20 Ciao Hannes= From hannes.tschofenig@gmx.net Mon Nov 26 00:36:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD8721F8550 for ; Mon, 26 Nov 2012 00:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SEOO7TW5a62 for ; Mon, 26 Nov 2012 00:36:09 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4B9E921F8532 for ; Mon, 26 Nov 2012 00:36:08 -0800 (PST) Received: (qmail invoked by alias); 26 Nov 2012 08:36:07 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp024) with SMTP; 26 Nov 2012 09:36:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18dksNxgjcdRngytEL89tlEIolgCXXRB02SMLfyzm LE7W0Gejm8iWqB From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Nov 2012 10:36:06 +0200 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] draft-ietf-oauth-revocation-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 08:36:10 -0000 Hi Torsten, thanks for the draft update. It looks good to me.=20 I only have a minor wording suggestion for Section 3.=20 Instead of=20 " Depending on the authorization server's token design, revocation of access tokens might be a costly process. For example, revocation of self-contained access tokens requires (time-consuming) backend calls between resource and authorization server on every request to the resource server or to push notifications from the authorization server to the affected resource servers. Alternatively, authorization servers may choose to issue short living access tokens, which can be refreshed at any time using the corresponding refresh tokens. In this case, a client would revoke the refresh token and access tokens issued based on this particular refresh token are at most valid until expiration. Whether this is an viable option or whether access token revocation is required should be decided based on the service provider's risk analysis. " what about the following text: " OAuth 2.0 allows deployment flexibility with respect to the style of = access tokens. The access tokens may be self-contained so that an = resource server needs no further interaction with an authorization = server issuing these tokens to perform an authorization decision of the = client requesting access to a protected resource. A system design may, = however, instead use access tokens that are opaque to the resource = server. This consequently requires a resource server to issue a request = to an authorization server to retrieve the content of the access token = every time a client presents an access token. While these are not the = only options they illustrate the implications for revocation. In the = latter case the authorization server is able to revoke an access token = previously issued to a client when the resource server relays a received = access token. In the former case some (currently non-standardized) = back-end interaction between the authorization server and the resource = server may be used when immediate access token revocation is desired or = another design alternative is to issue short-lived access tokens, which = can be refreshed at any time using the corresponding refresh tokens. = This allows the authorization server to have a limit on the time revoked = access tokens are in use.=20 Which approach of token revocation is chosen will depend on the overall = system design and on the application service provider's risk analysis. = The cost of revocation in terms of required state and communication = overhead is ultimately the result of the desired security properties. =20= " Ciao Hannes From sberyozkin@gmail.com Mon Nov 26 01:53:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB37221F86B3 for ; Mon, 26 Nov 2012 01:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGy9EzGAx6Il for ; Mon, 26 Nov 2012 01:53:51 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76BD821F86AC for ; Mon, 26 Nov 2012 01:53:50 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so8946606lah.31 for ; Mon, 26 Nov 2012 01:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=LsmxXy4z68w0njvfEoT0TYLz2SjRDwpjCSaP7QA5kJM=; b=czPkOkn+f3Q3RaohZkLWIaFXPp1F2l+48FVKNHkVz8QoTM9NvL9guAygTx0e4sAHK6 ZMiO5JfKkepUccgwj0pXh4QTZ8BtmuBbL9ephuY7YMt+krorlQsXyqm8//63f7taSm6F ldNsDV8Yzic3JT/GrBzxQoWBDqmFZxMsgduliC9fx6qCb5EWOxQu6ERvj7A8pvYILlc5 RZaTDJabu/kXP3W1Y5t18S+zt3jRpuJbCpA3yijA4xt2ArsSF6jfUrOhRuUPI07F1X9I k5tQmQ2rH/eAoESmo3UuqmHI6t/i0ZkYNnwk9eSjCieYuBVjXk7WtOCPEZVLos7HvpF+ q62w== Received: by 10.112.29.231 with SMTP id n7mr4905480lbh.107.1353923629366; Mon, 26 Nov 2012 01:53:49 -0800 (PST) Received: from [192.168.2.5] ([89.100.140.144]) by mx.google.com with ESMTPS id m3sm5336872lbb.13.2012.11.26.01.53.47 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 01:53:48 -0800 (PST) Message-ID: <50B33C2A.605@gmail.com> Date: Mon, 26 Nov 2012 09:53:46 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Token refresh and The Two Generals X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 09:53:52 -0000 On 23/11/12 12:43, Bob Gregory wrote: > We've had OAuth2 running successfully for a while now, but we're finding > that mobile applications have frequent problems with the refresh flow > where a refresh request is made, but the network connection fails before > the new AT/RT pair is received, leading to a "lost grant". > > In server-logs we can see that the token has been refreshed, and a new > RT issued, but the client is stuck with the old invalidated RT. > > This problem has been reported by two separate client applications, both > of whom are using a retry-mechanism for API requests since they expect > an unreliable network connection. > > Does anybody have any guidance on this issue, or is there any work in an > extension to address the issue of lost grants for token refreshes? > I wonder if a RM support is needed at the transport/protocol level for this to work reliably ? The same issue would also arise when an authorization code grant which is expected to be used only once is validated on the server and a new access token has not made it back to the client due to a connection loss... Sergey > > -- > Q. How many members of a demographic group does it take to perform a > specified task? > A. A finite number; one to perform the task, and the remainder to act in > a manner stereotypical of the group in question. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sberyozkin@gmail.com Mon Nov 26 03:47:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61D921F8452 for ; Mon, 26 Nov 2012 03:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCfnk9C00ht1 for ; Mon, 26 Nov 2012 03:47:04 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB91F21F8458 for ; Mon, 26 Nov 2012 03:46:59 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so9173161lbk.31 for ; Mon, 26 Nov 2012 03:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gmA/e+yZXhURSz/rQ8QHy4YDo2wtS4CrMa3l/I+XhWo=; b=HsIniOUbzlM+kCRY/CUKNig816ear0qyaEwlxNpIFbNsMMw+h/9iUce9rAYFmMrSb9 rorJ08tRpL2+EapUCriyJhq9ex1xKjYPYYJEeR9rfqeeNWkZILA+KuKtgwiwfJ/CQpf+ 3IgK8yoAlB7uBebJzWywGdg2blQo/SrRmaDEbuhpAnU8qKo00pra7TfcK2SD/X2jHBmu w1PV2ijfc7s+CRtHgoME3VYqLou6g2nce9J/jsCSIXLoE66fvYBkBDbZp3gJqXIbjpOs qKcDw1NXznE4wbZFwRfg9crpXIeC52RkASIt1BcRIa+qQc9o9GdvJonpmCxViVM6oqd3 16Zw== Received: by 10.152.110.42 with SMTP id hx10mr10865418lab.0.1353930418712; Mon, 26 Nov 2012 03:46:58 -0800 (PST) Received: from [192.168.2.5] ([89.100.140.144]) by mx.google.com with ESMTPS id z9sm5519429lby.8.2012.11.26.03.46.56 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 03:46:57 -0800 (PST) Message-ID: <50B356AF.10509@gmail.com> Date: Mon, 26 Nov 2012 11:46:55 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "oauth@ietf.org" References: <50B33C2A.605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [OAUTH-WG] Token refresh and The Two Generals X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 11:47:05 -0000 Hi Bob, On 26/11/12 10:47, Bob Gregory wrote: > Hi Sergey, > > We are less concerned about failure during the initial authorization, > since an end-user might reasonably expect to be asked to sign in again > if a failure occurs. Indeed > What's awkward here is that the user has been > successfully using the application for some time, and - from their > perspective - is suddenly signed out for no obvious reason. > I guess the issue can be treated in principle the same as if a client has had its current access token expired and no refresh token has been provided, which I guess has to be dealt the same way when an authorization code grant has been lost, as you suggested above... I'd consider some sort of RM support really helping to mitigate, but I may be wrong :-) Sergey > Can anybody with experience in deploying OAuth2 for mobile applications > proffer advice? We can't be the only people seeing this, so I wonder if > other implementers are mitigating the problem somehow. > > -- Bob Gregory > > > On Mon, Nov 26, 2012 at 9:53 AM, Sergey Beryozkin > wrote: > > On 23/11/12 12:43, Bob Gregory wrote: > > We've had OAuth2 running successfully for a while now, but we're > finding > > that mobile applications have frequent problems with the refresh flow > > where a refresh request is made, but the network connection fails > before > > the new AT/RT pair is received, leading to a "lost grant". > > > > In server-logs we can see that the token has been refreshed, and > a new > > RT issued, but the client is stuck with the old invalidated RT. > > > > This problem has been reported by two separate client > applications, both > > of whom are using a retry-mechanism for API requests since they > expect > > an unreliable network connection. > > > > Does anybody have any guidance on this issue, or is there any > work in an > > extension to address the issue of lost grants for token refreshes? > > > > I wonder if a RM support is needed at the transport/protocol level for > this to work reliably ? > > The same issue would also arise when an authorization code grant which > is expected to be used only once is validated on the server and a new > access token has not made it back to the client due to a connection > loss... > > Sergey > > > > > -- > > Q. How many members of a demographic group does it take to perform a > > specified task? > > A. A finite number; one to perform the task, and the remainder to > act in > > a manner stereotypical of the group in question. > > > > > > > > _______________________________________________ > > 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 > > > > > -- > Bob Gregory | Application Architect | Huddle – manage projects, files > and people in the cloud > > Email: bob@huddle.com | Skype: flinkywistypomm > Web: www.huddle.com | Blog: blog.huddle.net > | Twitter: @bobfromhuddle > > UK office: Unit B, Gemini House, 180 Bermondsey Street, London, SE1 3TQ > US office: 425 Bush Street, Suite 435, San Francisco CA 94108 > > Free Huddle trial! Sign up for a 14-day free trial and find out why > 85,000 businesses use Huddle > From internet-drafts@ietf.org Mon Nov 26 06:01:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9663E21F8449; Mon, 26 Nov 2012 06:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJUqhI3tLQyV; Mon, 26 Nov 2012 06:01:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2951221F845F; Mon, 26 Nov 2012 06:01:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121126140110.32381.41347.idtracker@ietfa.amsl.com> Date: Mon, 26 Nov 2012 06:01:10 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 14:01:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : Assertion Framework for OAuth 2.0 Author(s) : Brian Campbell Chuck Mortimore Michael B. Jones Yaron Y. Goland Filename : draft-ietf-oauth-assertions-08.txt Pages : 22 Date : 2012-11-26 Abstract: This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-assertions-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-assertions-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bcampbell@pingidentity.com Mon Nov 26 06:09:43 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F321A21F8554 for ; Mon, 26 Nov 2012 06:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QloWnwQUxw1w for ; Mon, 26 Nov 2012 06:09:42 -0800 (PST) Received: from na3sys009aog135.obsmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by ietfa.amsl.com (Postfix) with ESMTP id 09DE621F8444 for ; Mon, 26 Nov 2012 06:09:42 -0800 (PST) Received: from mail-ye0-f198.google.com ([209.85.213.198]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKULN4JZ68mYtd0uy1iUDq3Vlz/tYzcN0G@postini.com; Mon, 26 Nov 2012 06:09:42 PST Received: by mail-ye0-f198.google.com with SMTP id r9so10823270yen.1 for ; Mon, 26 Nov 2012 06:09:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=mbFZeMrEPaNxprUNc1caAD3TFkqMC210joDJM3HuLyk=; b=ns9R+XPZO/EPTTA7B5Ss9BFJpyYiKU79RrlgEAfbLpYpCOTjeZFDqADprSa7lQ4xWp 42lYGDCM7ZWkosTGZ02+boy0dYiW5TWpbmvqlSt7gg//rM4ZNiWRUGplMM3PTGLYptoV 6M1f8FQUYKAslIfiB7aeklQuFaDpiY4ngsiWZhyzmSuEmASlXdvEjvoEe9r7X2hWKPe1 hPM+q3gwlfztEL8hsYbTsSTIMI0OMJwo55OhvdxKH/uSaVBtd7O/OcJMCgxhyptpjcls cJZQAnAo1VitFop0pBzBfgxQr5nw56ElJDLm6+VhP1NDIWmp9sd5LIAfRVYBYK816SSP oe5g== Received: by 10.229.171.130 with SMTP id h2mr2744004qcz.95.1353938981044; Mon, 26 Nov 2012 06:09:41 -0800 (PST) Received: by 10.229.171.130 with SMTP id h2mr2744001qcz.95.1353938980836; Mon, 26 Nov 2012 06:09:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.6.3 with HTTP; Mon, 26 Nov 2012 06:09:10 -0800 (PST) In-Reply-To: <20121126140110.32381.41347.idtracker@ietfa.amsl.com> References: <20121126140110.32381.41347.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Mon, 26 Nov 2012 07:09:10 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=005045015f5500140704cf667cb7 X-Gm-Message-State: ALoCoQnaBSIx+onVnFCBLGso5npvCK3l0YiN+vu6s1TNfimsGGmghMPshiBC5MK6KDDQzIDZJCxsG/gCh1a1htBGMgWS3NNEq83vZ6njWXq0/yeXJNQ79nvfnxB26uXC0sbVPg0d4LWr Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-assertions-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 14:09:43 -0000 --005045015f5500140704cf667cb7 Content-Type: text/plain; charset=ISO-8859-1 Draft -08 of the Assertion Framework for OAuth 2.0 has been published with only minor changes to clean up the IANA Considerations section and to update references from draft-ietf-oauth-urn-sub-ns to RFC 6755. ---------- Forwarded message ---------- From: Date: Mon, Nov 26, 2012 at 7:01 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-08.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Assertion Framework for OAuth 2.0 Author(s) : Brian Campbell Chuck Mortimore Michael B. Jones Yaron Y. Goland Filename : draft-ietf-oauth-assertions-08.txt Pages : 22 Date : 2012-11-26 Abstract: This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-assertions-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --005045015f5500140704cf667cb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Draft -08 of the Assertion Framework for OAuth 2.0 has been published with = only minor changes to clean up the IANA Considerations section and to updat= e references from draft-ietf-oauth-urn-sub-ns to RFC 6755.

---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: Mon, Nov 26, 2012 at 7:01 = AM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-08.txt
To: <= a href=3D"mailto:i-d-announce@ietf.org">i-d-announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Web Authorization Protocol Working Grou= p of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Assertion Framework for OAuth 2= .0
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Brian Campbell
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Chuck Mortimore
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Michael B. Jones
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yaron Y. Goland
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-assertions-08.tx= t
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 22
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-11-26

Abstract:
=A0 =A0This specification provides a framework for the use of assertions =A0 =A0with OAuth 2.0 in the form of a new client authentication mechanism<= br> =A0 =A0and a new authorization grant type. =A0Mechanisms are specified for<= br> =A0 =A0transporting assertions during interactions with a token endpoint, a= s
=A0 =A0well as general processing rules.

=A0 =A0The intent of this specification is to provide a common framework fo= r
=A0 =A0OAuth 2.0 to interwork with other identity systems using assertions,=
=A0 =A0and to provide alternative client authentication mechanisms.

=A0 =A0Note that this specification only defines abstract message flows and=
=A0 =A0processing rules. =A0In order to be implementable, companion
=A0 =A0specifications are necessary to provide the corresponding concrete =A0 =A0instantiations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-assertion= s

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-assertions-08<= br>
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-as= sertions-08


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--005045015f5500140704cf667cb7-- From ve7jtb@ve7jtb.com Mon Nov 26 06:12:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A2021F854E for ; Mon, 26 Nov 2012 06:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aj4pD2N4GRO for ; Mon, 26 Nov 2012 06:12:37 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8CDF21F8594 for ; Mon, 26 Nov 2012 06:12:36 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id r1so192244ggn.31 for ; Mon, 26 Nov 2012 06:12:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=r/jO4not4Zmqi5STI+jIyxZzodxW126irGE3a4Bh9Hc=; b=joEhcH1eH8eYjN61xgPwEJ21Q71obVphvp8AaN5xu1AyEULkx8lO5R0plya3T38ZaX HF71dAPRgEYgtAHJT4Jj9pqn7AA09JYWRyYw9yVpaRgnna3qnr2RNJxCHoCxczFproWW HTIVY9AqXehB9KxC5jHGCn5aJRq0z/Cvy5qep/jfgJJ6T688MT4FPSaWmeozrCH/cS4n kWJ7QPDSZZn206LoaBqnaTLColaz9OR3JJS4bA7glyiXLyKqk2JW0gEg1nbnLMMRWB82 ly6f+gH+Ig9JhkVwdDHYI0t5zKbA5uMkKnnhOnoY+9EuJRQQXAv6Rtogz1HHh9VEFUzK 6G1Q== Received: by 10.236.161.233 with SMTP id w69mr11523532yhk.74.1353939156229; Mon, 26 Nov 2012 06:12:36 -0800 (PST) Received: from [192.168.1.211] (190-20-23-36.baf.movistar.cl. [190.20.23.36]) by mx.google.com with ESMTPS id l17sm13809426ank.4.2012.11.26.06.12.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 06:12:35 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <50B11502.2000509@lodderstedt.net> Date: Mon, 26 Nov 2012 11:12:09 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50B11502.2000509@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlhso6ZXghdCxLY742jr/m7+oq8xGAgj5E8FQ2pSEcXR9rU4erNPorUrbMnC5e/cesqQ38x Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-dyn-reg-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 14:12:37 -0000 Torsten, Originally in OIC we defined using the client secret to access the = registration endpoint. We received a lot of feedback that having it bearer protected for the = first access and password protected for subsequent access was confusing. There are also the cases where there is no need for a client secret. = In the case of the token grant type. There was also feedback that using the same secret for both makes = rotation of the client secret more challenging when errors occur. I think having them separate made the OIDC spec cleaner. =20 So there was a fair amount of thought that went into that decision. In OIDC the jwk_url is used most commonly for the authorization server = to validate the signature of a request object coming from the client or = the signature of the request to the token endpoint using the JWT = assertion spec. Nether of those are part of the core spec but I can = see keeping it to standardize registration for those clients using the = Assertion spec for authentication to the token endpoint. John B. On 2012-11-24, at 3:42 PM, Torsten Lodderstedt = wrote: > Hi Justin, >=20 > I think your draft is a significant step forward. Thanks for putting = it together. >=20 > Here are my detailed comments/questions: >=20 > Whats the advantage of having two secrets for the same client_id, = namely request_access_token and client_secret? Why not always issuing a = secret and use it for authentication on this endpoint (in the same way = as at the token endpoint)? >=20 > Section 2.1. > Some of those parameters seems to be OIDC-specific, e.g. = default_max_age. I would suggest to remove those. >=20 > I would also recommend to state the relation of the parameters to core = _or_ extension features. For example, "jwk_url" is only be used if the = AS supports JWT Bearer Tokens, right? >=20 > When reading the document the first time, I was a bit lost since none = of the parameters is explained in this section. I would therefore = suggest to change order of sections 2 and 3. >=20 > Security Considerations >=20 > "An IdP can also make warnings against untrusted RPs in all > cases, especially if they're dynamically registered, have not been > trusted by any users at the IdP before, and want to use the logo > feature." >=20 > This reads funny since this whole document is about dynamic client = registration, isn=92t it? > I think AS should generally be careful when displaying client meta = data if they did not previously validate them. A client could also call = itself Google or Facebook. This section must call this out aloud. >=20 > Should external URLs be sanitized in order to prevent CSS and Request = Forgery? >=20 > regards, > Torsten. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Mon Nov 26 06:27:13 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB5A21F8554 for ; Mon, 26 Nov 2012 06:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQk79cAFICQO for ; Mon, 26 Nov 2012 06:27:12 -0800 (PST) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1FF21F8546 for ; Mon, 26 Nov 2012 06:27:12 -0800 (PST) Received: by mail-gh0-f172.google.com with SMTP id z22so975198ghb.31 for ; Mon, 26 Nov 2012 06:27:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=zvGLlYlGS5b42ManIg2w3bh3q37GhyJYWHZok1blRVA=; b=e4uiyYmFVJ+IKJjLfwk83jl290S0s5jZlcEz2yFf8EUbZIjX4yGPRLvD6/WTvOHXaK 5A8R+8x9FBMWNrYqqDiQSD9k2+ytB+zYAA3u4kkwCNuNmOJZERnODb5A8lnce90vzk4h L6OOdR1VezMt2Z13DViccdOYK91NMig0My7wEBMfISFIs1JJ3UYZwdrZ8giit/hHjI+t oitjlSxdt8Y8dQp8k7nIxa8WwDqB8bqqbljZDBqoCmjoiGoZxQ+Cr6gGjvdSNjtBnz+z HltX9z+Q5ti+cZCsPoHnxjZa/Eylb2wc9kFHhBn43Ed0Xvi0AAPpDrZ4sfOqhfdreYZm DgNA== Received: by 10.236.81.242 with SMTP id m78mr11579442yhe.36.1353940031928; Mon, 26 Nov 2012 06:27:11 -0800 (PST) Received: from [192.168.1.211] (190-20-23-36.baf.movistar.cl. [190.20.23.36]) by mx.google.com with ESMTPS id y9sm13814964anh.20.2012.11.26.06.26.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 06:27:10 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <50B1162A.8020506@lodderstedt.net> Date: Mon, 26 Nov 2012 11:26:39 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5BB14099-C30A-4CB1-9B9A-39EB8D12863C@ve7jtb.com> References: <50B1162A.8020506@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQl9d8p9nenpJZRutB0EH3AilwRXNGbNmSeTvAyT/5Iv6ReumlSh3jjtvO/5MtNgmazrB7dv Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-json-web-token-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 14:27:13 -0000 JWT is more generic than OIDC. prn and user_id as used by OIDC are similar. user_id is already in = wide use with Facebook's signed request. =20 We were hoping that Facebook would be more likely to migrate from signed = request to JWT if the parameter names stayed the same for developers. In the generic case of a JWT the prn may not be a user. =20 The other discussion that I recall around prn was a notion that they are = fully qualified and globally unique. We wanted to be clear with user_id that it is scoped to the iss and not = globally unique. So a prn was seen as a User Principal name and the user_id was seen as a = persistent non reassignable identifier for the user in the context of = the iss. John B. On 2012-11-24, at 3:47 PM, Torsten Lodderstedt = wrote: > Hi, >=20 > I've got a few comments on your draft. >=20 > I=92m wondering why neither acr nor auth_time (which are used in OIDC) = made their way into this spec? >=20 > What is the difference between prn and the user_id claim OIDC uses? >=20 > regards, > Torsten. >=20 From jricher@mitre.org Mon Nov 26 06:52:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D203921F851B for ; Mon, 26 Nov 2012 06:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1usYiWX7oo8 for ; Mon, 26 Nov 2012 06:52:37 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C7EA321F850B for ; Mon, 26 Nov 2012 06:52:37 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3C5C253100AC; Mon, 26 Nov 2012 09:52:37 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 26A975310090; Mon, 26 Nov 2012 09:52:37 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 26 Nov 2012 09:52:36 -0500 Message-ID: <50B381DC.3070003@mitre.org> Date: Mon, 26 Nov 2012 09:51:08 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Torsten Lodderstedt References: <50B11502.2000509@lodderstedt.net> In-Reply-To: <50B11502.2000509@lodderstedt.net> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [129.83.31.58] Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-dyn-reg-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 14:52:38 -0000 Hi Torsten, thanks for the comments. > Whats the advantage of having two secrets for the same client_id, > namely request_access_token and client_secret? Why not always issuing > a secret and use it for authentication on this endpoint (in the same > way as at the token endpoint)? Two things are at play here, from what I understand of the discussions that went into this: 1) The audience of the secret is different. The client_secret is intended for the Token Endpoint, while the registration_access_token is intended for the Registration Endpoint. 2) Clients can use all different kinds of authentication at the Token Endpoint, not just a client_secret. This gives us a way to support dynamic registration of those clients without conflating the functionality of the Registration Endpoint itself. Additionally, there's a strong desire from Google and others for a semi-registered use case, where the app developer gets a "developer key" that they present to the registration endpoint. This "developer key" is effectively a bootstrapped registration access token, and if you look at it that way this lets us keep the same mechanisms here. > > Section 2.1. > Some of those parameters seems to be OIDC-specific, e.g. > default_max_age. I would suggest to remove those. I definitely want to trim any OIDC or UMA specific stuff. However, the session-age-management stuff I think makes sense to keep. I'll pull it out if others feel strongly about it though. > > I would also recommend to state the relation of the parameters to core > _or_ extension features. For example, "jwk_url" is only be used if the > AS supports JWT Bearer Tokens, right? I think it's a good idea to be more explicit about what each of the parameters relates to - jwk_url for instance is the key of the *client* and has more to do with using JWT Assertion for client credentials than it does the server's token format. > > When reading the document the first time, I was a bit lost since none > of the parameters is explained in this section. I would therefore > suggest to change order of sections 2 and 3. That is a really good idea, I'll do that. I've been struggling at how best to present this information without it being overwhelmingly repetitive. > > Security Considerations > > "An IdP can also make warnings against untrusted RPs in all > cases, especially if they're dynamically registered, have not been > trusted by any users at the IdP before, and want to use the logo > feature." > > This reads funny since this whole document is about dynamic client > registration, isn’t it? > I think AS should generally be careful when displaying client meta > data if they did not previously validate them. A client could also > call itself Google or Facebook. This section must call this out aloud. I think this can be stated better, but the idea is that you should tell people that a client was dynamically registered since the trust model is going to be different from a background-registered one. The spoofing of the client name is exactly one of the reasons for this, and it should be stated explicitly. > > Should external URLs be sanitized in order to prevent CSS and Request > Forgery? If someone can give me the right text and tell me which URLs it needs to be applied to, I'd be happy to incorporate it. Potential targets: - redirect_uri - logo - homepage - TOS - privacy Any others I'm missing? Everything is being tracked in GitHub: https://github.com/jricher/oauth-spec/issues Again, thanks, -- Justin From jricher@mitre.org Mon Nov 26 07:14:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B6721F85A6 for ; Mon, 26 Nov 2012 07:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnnGLL0tmMcN for ; Mon, 26 Nov 2012 07:14:51 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4709821F8469 for ; Mon, 26 Nov 2012 07:14:51 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 973151F0A47; Mon, 26 Nov 2012 10:14:50 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 867AC1F02AB; Mon, 26 Nov 2012 10:14:50 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 26 Nov 2012 10:14:50 -0500 Message-ID: <50B38712.4060209@mitre.org> Date: Mon, 26 Nov 2012 10:13:22 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Hannes Tschofenig References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> In-Reply-To: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 15:14:52 -0000 I have reviewed the document, and it looks ready to go. -- Justin On 11/24/2012 01:13 PM, Hannes Tschofenig wrote: > Hi all, > > this is a working group last call for draft-ietf-oauth-revocation-03 on "Token Revocation". The draft is available here: > http://tools.ietf.org/html/draft-ietf-oauth-revocation-03 > > Please send you comments to the OAuth mailing list by December 10, 2012. > > Thanks, > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sberyozkin@gmail.com Mon Nov 26 10:15:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291DA21F852D for ; Mon, 26 Nov 2012 10:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-YOAGx5hPkk for ; Mon, 26 Nov 2012 10:15:27 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E97D421F8531 for ; Mon, 26 Nov 2012 10:15:19 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so5449563bku.31 for ; Mon, 26 Nov 2012 10:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=InUwKjAvPrpkyIVWjyHTbknqLYh2+am8paLsTalvhCY=; b=U7PdpBq+oECyi2yl5xxPqfTZYaLtkrCAq5jDyAOazf/EaOwoi7aFKbnFv6JWudlfAv lOtxqu8K7S39n+ET5sip9TsLOSVocxgpNefaht3nsayVoNqTOZD0mGX3XIYHGqYKoQVO 6NnmtPblB0FXnd9rCN2lE+Bu5ducXgI5udPZ3O0Urj2OwF4SlKfHXUAFf5DUqrg3OzX8 ob+e1hT+InrZ5HpQHnK9fRwVE/EyqvFiAOM1QXd17JZkZnyoYPCNrLObyWdvSdITXyFy RVeBd4RdHjEk+0bfGkhVYP6049A/ggtaz7znBFs0ttvP875geKZ23svBBWwFYg0pp09O idvQ== Received: by 10.204.128.148 with SMTP id k20mr3753417bks.107.1353953718732; Mon, 26 Nov 2012 10:15:18 -0800 (PST) Received: from [192.168.2.5] ([89.100.140.144]) by mx.google.com with ESMTPS id t11sm8723201bkv.11.2012.11.26.10.15.16 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 10:15:17 -0800 (PST) Message-ID: <50B3B1B3.50502@gmail.com> Date: Mon, 26 Nov 2012 18:15:15 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 18:15:28 -0000 Hi What needs to be done to complete the MAC token spec ? Without having it signed off it will be difficult to get people working with OAuth 1.0 convinced to move to 2.0. I'm seeing another user request for getting OAuth 1.0 support extended further because the user expects it is more secure, and I guess because it is proven to work for people, and I guess because many OAuth 1.0 users feel that should stay from OAuth 2.0 because of some bad press. Without MAC being completed the division will continue, with even more misleading anti-OAuth2 posts appearing (though I guess some of the better posts point to some level of complexity in 2.0). Is it a matter of a security expert validating the text, fixing few typos, and basically signing it off ? If someone is interested then I can provide the info offline on how it MAC supported in our framework to get things tested easily and such... Cheers, Sergey From phil.hunt@oracle.com Mon Nov 26 10:28:17 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547CD21F853D for ; Mon, 26 Nov 2012 10:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOWPc+J2f3u8 for ; Mon, 26 Nov 2012 10:28:16 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9944921F84F8 for ; Mon, 26 Nov 2012 10:28:16 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAQISEnc031873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Nov 2012 18:28:15 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAQISEx7023182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2012 18:28:14 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAQISDgw030370; Mon, 26 Nov 2012 12:28:14 -0600 Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Nov 2012 10:28:13 -0800 References: <50B3B1B3.50502@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <50B3B1B3.50502@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A523) From: Phil Hunt Date: Mon, 26 Nov 2012 10:28:12 -0800 To: Sergey Beryozkin X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 18:28:17 -0000 If we want to get this done we have to get agreements on the requirements fo= r HOK. Several meetings ago (quebec) the group indicated that mac wasn't app= ropriate to anyone's needs.=20 Some would argue that OAuth1 users arguably have less security than the simp= ler bearer token /tls model in OAuth2. This just shows the real issue of dem= onstrated need has not been properly defined and understood.=20 More dialog on use cases is very helpful to moving HOK/MAC/etc forward.=20 Phil On 2012-11-26, at 10:15, Sergey Beryozkin wrote: > Hi >=20 > What needs to be done to complete the MAC token spec ? Without having it s= igned off it will be difficult to get people working with OAuth 1.0 convince= d to move to 2.0. > I'm seeing another user request for getting OAuth 1.0 support extended fur= ther because the user expects it is more secure, and I guess because it is p= roven to work for people, and I guess because many OAuth 1.0 users feel that= should stay from OAuth 2.0 because of some bad press. >=20 > Without MAC being completed the division will continue, with even more mis= leading anti-OAuth2 posts appearing (though I guess some of the better posts= point to some level of complexity in 2.0). >=20 > Is it a matter of a security expert validating the text, fixing few typos,= and basically signing it off ? >=20 > If someone is interested then I can provide the info offline on how it MAC= supported in our framework to get things tested easily and such... >=20 > Cheers, Sergey >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills_92105@yahoo.com Mon Nov 26 10:41:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE7821F84BC for ; Mon, 26 Nov 2012 10:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3z7tcQZoM-Z for ; Mon, 26 Nov 2012 10:41:41 -0800 (PST) Received: from nm40-vm5.bullet.mail.ne1.yahoo.com (nm40-vm5.bullet.mail.ne1.yahoo.com [98.138.229.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC0721F842C for ; Mon, 26 Nov 2012 10:41:41 -0800 (PST) Received: from [98.138.90.55] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 26 Nov 2012 18:41:35 -0000 Received: from [98.138.89.193] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 26 Nov 2012 18:41:35 -0000 Received: from [127.0.0.1] by omp1051.mail.ne1.yahoo.com with NNFMP; 26 Nov 2012 18:41:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 834601.63629.bm@omp1051.mail.ne1.yahoo.com Received: (qmail 22672 invoked by uid 60001); 26 Nov 2012 18:41:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353955295; bh=9d8auZ5v/uyd20Hozgnu1Aq4myIf2LAjedL/+S33/FE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=j+ufwNmvRSPxJB2fQMfSs/ada3Dc3/+/9nb8tH80heEZs2BTIEpaxffxIpZS07faXHD1zEts79AtFP+/gwzHQ29+SQSg5NhNQqSjmtjW+LUmHCoRp9ENeiF/R84w3SCCGoC+KZja9VQaxXE6dX4UtxwwdU1LIdZOG2gGCRPjRrY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=btuRsdSgfdQVLvFSe2O5ngfMJ682TfRKoeaj2U5K5UMCgcy1LlD8gk7+Sbw2YPow0IcSrx/3iE38hjBk9sM0l6s7mSmI+mJot65w4OEzd6sTl25U1+/DLu+kbg2XLCEaaEjhMc6YYaTLRNsMnOn4dxAYOBE34gy0sMupCxPtCV4=; X-YMail-OSG: Yrl.t2kVM1kDvaA8M1mN9zTRlVfth7u_HI1aqlfJUfrjhmv DK9ykeiTJ9NEvOUCBm3EUsVBt.TSPpnphpcaUmXpXJPRAVy5QZazAsYZMw0w Hh4ClnxPRcWHfmKG54lXNe8hi_.HjKMwL9cvzkrS2O3Jp3Rf.qz7M6xz4kkJ badSBn_tl50EwS_nyKSD9JkFyOIOKe9Z6tLznmWFt4nvRjdfkpKD.OW5f1WC dopdOfAKIbJ47AeB2BMkpHclrjuH5UxF5ZbFaZ58ZbEE8V00QnoaqonTqabk Fs7A0yiML2Q.rDuWKFbuAYCV62ijRC8Gk3qMFgN_UNuMkbWqJrtR7JACqzFs KoUGLMpgKUaTWyLQqPo_LyGsOayRdF2WR26KTG8JnegkcWRB9XIHHt.iRN1b eJj3_Yt0Uy_rEFy4o0GfGqrQLbwecJpNwymbATTeujeeI4kE4FXtQTcoZ886 OYDYcI59UqC8cF6oUwCeI0ajQ.IDNS_GIj_fghpokB1qPFhzPLyXn5RoLPaR J8GorcjSY03ws0zwUAOKYMHpzlO_UuuC6HHy5HFEkUus- Received: from [209.131.62.115] by web31801.mail.mud.yahoo.com via HTTP; Mon, 26 Nov 2012 10:41:35 PST X-Rocket-MIMEInfo: 001.001, SSBvYmplY3QgdG8gdHlpbmcgTUFDIHRvIEhPSywgSSBzZWUgdGhlbSBhcyBpbmRlcGVuZGVudCBhbmQgSSBmcmFua2x5IGRvbid0IHVuZGVyc3RhbmQgd2h5IGZvbGtzIGluc2lzdCB0aGF0IE1BQyBjYW4gbm90IHByb2NlZWQgd2l0aG91dCBhIGJyb2FkZXIgSE9LIHNwZWMuIMKgCgotYmlsbAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPgpUbzogU2VyZ2V5IEJlcnlvemtpbiA8c2JlcnlvemtpbkBnbWFpbC5jb20.IApDYzoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.127.475 References: <50B3B1B3.50502@gmail.com> Message-ID: <1353955295.11494.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Mon, 26 Nov 2012 10:41:35 -0800 (PST) From: William Mills To: Phil Hunt , Sergey Beryozkin In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-1636422194-1353955295=:11494" Cc: "" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 18:41:42 -0000 ---368338466-1636422194-1353955295=:11494 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I object to tying MAC to HOK, I see them as independent and I frankly don't= understand why folks insist that MAC can not proceed without a broader HOK= spec. =A0=0A=0A-bill=0A=0A=0A________________________________=0A From: Phi= l Hunt =0ATo: Sergey Beryozkin = =0ACc: "" =0ASent: Monday, November 26, 2= 012 10:28 AM=0ASubject: Re: [OAUTH-WG] What needs to be done to complete MA= C=0A =0AIf we want to get this done we have to get agreements on the requir= ements for HOK. Several meetings ago (quebec) the group indicated that mac = wasn't appropriate to anyone's needs. =0A=0ASome would argue that OAuth1 us= ers arguably have less security than the simpler bearer token /tls model in= OAuth2. This just shows the real issue of demonstrated need has not been p= roperly defined and understood. =0A=0AMore dialog on use cases is very help= ful to moving HOK/MAC/etc forward. =0A=0APhil=0A=0AOn 2012-11-26, at 10:15,= Sergey Beryozkin wrote:=0A=0A> Hi=0A> =0A> What nee= ds to be done to complete the MAC token spec ? Without having it signed off= it will be difficult to get people working with OAuth 1.0 convinced to mov= e to 2.0.=0A> I'm seeing another user request for getting OAuth 1.0 support= extended further because the user expects it is more secure, and I guess b= ecause it is proven to work for people, and I guess because many OAuth 1.0 = users feel that should stay from OAuth 2.0 because of some bad press.=0A> = =0A> Without MAC being completed the division will continue, with even more= misleading anti-OAuth2 posts appearing (though I guess some of the better = posts point to some level of complexity in 2.0).=0A> =0A> Is it a matter of= a security expert validating the text, fixing few typos, and basically sig= ning it off ?=0A> =0A> If someone is interested then I can provide the info= offline on how it MAC supported in our framework to get things tested easi= ly and such...=0A> =0A> Cheers, Sergey=0A> =0A> ___________________________= ____________________=0A> OAuth mailing list=0A> OAuth@ietf.org=0A> https://= www.ietf.org/mailman/listinfo/oauth=0A_____________________________________= __________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mai= lman/listinfo/oauth ---368338466-1636422194-1353955295=:11494 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I object to tying MAC to HOK, I see them as independent and I frankly don= 't understand why folks insist that MAC can not proceed without a broader H= OK spec.  

From: Phil Hu= nt <phil.hunt@oracle.com>
T= o: Sergey Beryozkin <sberyozkin@gmail.com>
Cc: "<oauth@ietf.org>" <oaut= h@ietf.org>
Sent: = Monday, November 26, 2012 10:28 AM
sberyozkin@gmail.com> wrote:

> Hi
>
> What needs to be done to comp= lete the MAC token spec ? Without having it signed off it will be difficult= to get people working with OAuth 1.0 convinced to move to 2.0.
> I'm= seeing another user request for getting OAuth 1.0 support extended further= because the user expects it is more secure, and I guess because it is proven to work for pe= ople, and I guess because many OAuth 1.0 users feel that should stay from O= Auth 2.0 because of some bad press.
>
> Without MAC being comp= leted the division will continue, with even more misleading anti-OAuth2 pos= ts appearing (though I guess some of the better posts point to some level o= f complexity in 2.0).
>
> Is it a matter of a security expert = validating the text, fixing few typos, and basically signing it off ?
&g= t;
> If someone is interested then I can provide the info offline on= how it MAC supported in our framework to get things tested easily and such= ...
>
> Cheers, Sergey
>
> ______________________= _________________________
> 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


<= /div>
---368338466-1636422194-1353955295=:11494-- From tonynad@microsoft.com Mon Nov 26 10:45:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8104321F8441 for ; Mon, 26 Nov 2012 10:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsdLf5pSqjGW for ; Mon, 26 Nov 2012 10:45:57 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id B942A21F8436 for ; Mon, 26 Nov 2012 10:45:57 -0800 (PST) Received: from mail208-co1-R.bigfish.com (10.243.78.253) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.23; Mon, 26 Nov 2012 18:45:56 +0000 Received: from mail208-co1 (localhost [127.0.0.1]) by mail208-co1-R.bigfish.com (Postfix) with ESMTP id C850720081 for ; Mon, 26 Nov 2012 18:45:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: VS-16(zz98dI9371I936eIc85fh1432I1b2fkzz1de0h1202h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dh18c673hz2fh2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h9a9j1155h) Received-SPF: pass (mail208-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail208-co1 (localhost.localdomain [127.0.0.1]) by mail208-co1 (MessageSwitch) id 1353955554748129_11400; Mon, 26 Nov 2012 18:45:54 +0000 (UTC) Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.254]) by mail208-co1.bigfish.com (Postfix) with ESMTP id B37A76C001D for ; Mon, 26 Nov 2012 18:45:54 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 26 Nov 2012 18:45:52 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 26 Nov 2012 18:45:50 +0000 Received: from mail166-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.23; Mon, 26 Nov 2012 18:45:41 +0000 Received: from mail166-va3 (localhost [127.0.0.1]) by mail166-va3-R.bigfish.com (Postfix) with ESMTP id 4153D260207 for ; Mon, 26 Nov 2012 18:45:41 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(299001);DIR:OUT;LANG:en; Received: from mail166-va3 (localhost.localdomain [127.0.0.1]) by mail166-va3 (MessageSwitch) id 1353955538426120_16141; Mon, 26 Nov 2012 18:45:38 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.245]) by mail166-va3.bigfish.com (Postfix) with ESMTP id 6142D36004D; Mon, 26 Nov 2012 18:45:38 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 26 Nov 2012 18:45:35 +0000 Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.239.5; Mon, 26 Nov 2012 18:45:34 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.545.9; Mon, 26 Nov 2012 18:45:27 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.10.178]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.10.252]) with mapi id 15.00.0545.000; Mon, 26 Nov 2012 18:45:26 +0000 From: Anthony Nadalin To: William Mills , Phil Hunt , Sergey Beryozkin Thread-Topic: [OAUTH-WG] What needs to be done to complete MAC Thread-Index: AQHNzAIcZeNpj7xxpUqkFpaadM1a2pf8b5EAgAADvYCAAACXYA== Date: Mon, 26 Nov 2012 18:45:26 +0000 Message-ID: <574223ac87e94e14b59d29611a1d5fe4@BY2PR03MB041.namprd03.prod.outlook.com> References: <50B3B1B3.50502@gmail.com> <1353955295.11494.YahooMailNeo@web31801.mail.mud.yahoo.com> In-Reply-To: <1353955295.11494.YahooMailNeo@web31801.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.93.19] x-forefront-prvs: 0677FFABBF Content-Type: multipart/alternative; boundary="_000_574223ac87e94e14b59d29611a1d5fe4BY2PR03MB041namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%YAHOO.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 18:45:58 -0000 --_000_574223ac87e94e14b59d29611a1d5fe4BY2PR03MB041namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that HOK may be independent of MAC and should be a separate issue, = as MAC does not solve my proof of possession for a HOK solution From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of W= illiam Mills Sent: Monday, November 26, 2012 10:42 AM To: Phil Hunt; Sergey Beryozkin Cc: Subject: Re: [OAUTH-WG] What needs to be done to complete MAC I object to tying MAC to HOK, I see them as independent and I frankly don't= understand why folks insist that MAC can not proceed without a broader HOK= spec. -bill ________________________________ From: Phil Hunt > To: Sergey Beryozkin > Cc: ">" > Sent: Monday, November 26, 2012 10:28 AM Subject: Re: [OAUTH-WG] What needs to be done to complete MAC If we want to get this done we have to get agreements on the requirements f= or HOK. Several meetings ago (quebec) the group indicated that mac wasn't a= ppropriate to anyone's needs. Some would argue that OAuth1 users arguably have less security than the sim= pler bearer token /tls model in OAuth2. This just shows the real issue of d= emonstrated need has not been properly defined and understood. More dialog on use cases is very helpful to moving HOK/MAC/etc forward. Phil On 2012-11-26, at 10:15, Sergey Beryozkin > wrote: > Hi > > What needs to be done to complete the MAC token spec ? Without having it = signed off it will be difficult to get people working with OAuth 1.0 convin= ced to move to 2.0. > I'm seeing another user request for getting OAuth 1.0 support extended fu= rther because the user expects it is more secure, and I guess because it is= proven to work for people, and I guess because many OAuth 1.0 users feel t= hat should stay from OAuth 2.0 because of some bad press. > > Without MAC being completed the division will continue, with even more mi= sleading anti-OAuth2 posts appearing (though I guess some of the better pos= ts point to some level of complexity in 2.0). > > Is it a matter of a security expert validating the text, fixing few typos= , and basically signing it off ? > > If someone is interested then I can provide the info offline on how it MA= C supported in our framework to get things tested easily and such... > > Cheers, Sergey > > _______________________________________________ > 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 --_000_574223ac87e94e14b59d29611a1d5fe4BY2PR03MB041namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that HOK may be i= ndependent of MAC and should be a separate issue, as MAC does not solve my = proof of possession for a HOK solution

 <= /p>

From: oauth-= bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Monday, November 26, 2012 10:42 AM
To: Phil Hunt; Sergey Beryozkin
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] What needs to be done to complete MAC

 

I object to tying MAC to HOK, I see = them as independent and I frankly don't understand why folks insist that MA= C can not proceed without a broader HOK spec.  

 

-bill

 

From: Phil Hunt <phil.hunt@oracle.com>
To: Sergey Beryozkin <sbe= ryozkin@gmail.com>
Cc: "<oauth@ietf.org&g= t;" <oauth@ietf.org>
Sent: Monday, November 26, 2012 10:28 AM
Subject: Re: [OAUTH-WG] What needs to be done to complete MAC=


If we want to get this done we have to get agreements on the requirements f= or HOK. Several meetings ago (quebec) the group indicated that mac wasn't a= ppropriate to anyone's needs.

Some would argue that OAuth1 users arguably have less security than the sim= pler bearer token /tls model in OAuth2. This just shows the real issue of d= emonstrated need has not been properly defined and understood.

More dialog on use cases is very helpful to moving HOK/MAC/etc forward.
Phil

On 2012-11-26, at 10:15, Sergey Beryozkin <sberyozkin@gmail.com> wrote:

> Hi
>
> What needs to be done to complete the MAC token spec ? Without having = it signed off it will be difficult to get people working with OAuth 1.0 con= vinced to move to 2.0.
> I'm seeing another user request for getting OAuth 1.0 support extended= further because the user expects it is more secure, and I guess because it= is proven to work for people, and I guess because many OAuth 1.0 users fee= l that should stay from OAuth 2.0 because of some bad press.
>
> Without MAC being completed the division will continue, with even more= misleading anti-OAuth2 posts appearing (though I guess some of the better = posts point to some level of complexity in 2.0).
>
> Is it a matter of a security expert validating the text, fixing few ty= pos, and basically signing it off ?
>
> If someone is interested then I can provide the info offline on how it= MAC supported in our framework to get things tested easily and such...
>
> Cheers, Sergey
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--_000_574223ac87e94e14b59d29611a1d5fe4BY2PR03MB041namprd03pro_-- From torsten@lodderstedt.net Mon Nov 26 10:47:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA1121F8608 for ; Mon, 26 Nov 2012 10:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHBd46fHoUbN for ; Mon, 26 Nov 2012 10:46:59 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6CABB21F8446 for ; Mon, 26 Nov 2012 10:46:59 -0800 (PST) Received: from [91.2.82.133] (helo=android-7b8e761b2a5c1607.fritz.box) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1Td3hp-0007od-1p; Mon, 26 Nov 2012 19:46:57 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <5BB14099-C30A-4CB1-9B9A-39EB8D12863C@ve7jtb.com> References: <50B1162A.8020506@lodderstedt.net> <5BB14099-C30A-4CB1-9B9A-39EB8D12863C@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----XL81IA4EBFO7OFJHDXGN7I7UKTHC7Q" From: Torsten Lodderstedt Date: Mon, 26 Nov 2012 19:46:51 +0100 To: John Bradley Message-ID: <39488346-171f-4623-9d2b-a125c8444959@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-json-web-token-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 18:47:00 -0000 ------XL81IA4EBFO7OFJHDXGN7I7UKTHC7Q Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi John thanks for the explanatian. Just to make sure I got you right. A prn can be a user_id. A prn is bound to the scope of an iss. Regards, Torsten. John Bradley schrieb: >JWT is more generic than OIDC. > >prn and user_id as used by OIDC are similar. user_id is already in >wide use with Facebook's signed request. >We were hoping that Facebook would be more likely to migrate from >signed request to JWT if the parameter names stayed the same for >developers. > >In the generic case of a JWT the prn may not be a user. > >The other discussion that I recall around prn was a notion that they >are fully qualified and globally unique. > >We wanted to be clear with user_id that it is scoped to the iss and not >globally unique. > >So a prn was seen as a User Principal name and the user_id was seen as >a persistent non reassignable identifier for the user in the context of >the iss. > >John B. > > >On 2012-11-24, at 3:47 PM, Torsten Lodderstedt > wrote: > >> Hi, >> >> I've got a few comments on your draft. >> >> I’m wondering why neither acr nor auth_time (which are used in OIDC) >made their way into this spec? >> >> What is the difference between prn and the user_id claim OIDC uses? >> >> regards, >> Torsten. >> ------XL81IA4EBFO7OFJHDXGN7I7UKTHC7Q Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi John

thanks for the explanatian. Just to make sure I got you right. A prn can be a user_id. A prn is bound to the scope of an iss.

Regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com> schrieb:
JWT is more generic than OIDC.

prn and user_id as used by OIDC are similar.   user_id is already in wide use with Facebook's signed request.  
We were hoping that Facebook would be more likely to migrate from signed request to JWT if the parameter names stayed the same for developers.

In the generic case of a JWT the prn may not be a user.   

The other discussion that I recall around prn was a notion that they are fully qualified and globally unique.

We wanted to be clear with user_id that it is scoped to the iss and not globally unique.

So a prn was seen as a User Principal name and the user_id was seen as a persistent non reassignable identifier for the user in the context of the iss.

John B.


On 2012-11-24, at 3:47 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi,

I've got a few comments on your draft.

I’m wondering why neither acr nor auth_time (which are used in OIDC) made their way into this spec?

What is the difference between prn and the user_id claim OIDC uses?

regards,
Torsten.


------XL81IA4EBFO7OFJHDXGN7I7UKTHC7Q-- From jricher@mitre.org Mon Nov 26 10:47:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1A221F8621 for ; Mon, 26 Nov 2012 10:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qzm3zLaycZ-e for ; Mon, 26 Nov 2012 10:47:30 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2212121F8446 for ; Mon, 26 Nov 2012 10:47:30 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 87B271F0896; Mon, 26 Nov 2012 13:47:29 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 78DFD1F0A61; Mon, 26 Nov 2012 13:47:29 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 26 Nov 2012 13:47:29 -0500 Message-ID: <50B3B8E8.2030709@mitre.org> Date: Mon, 26 Nov 2012 13:46:00 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: William Mills References: <50B3B1B3.50502@gmail.com> <1353955295.11494.YahooMailNeo@web31801.mail.mud.yahoo.com> In-Reply-To: <1353955295.11494.YahooMailNeo@web31801.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------070206050207030909000103" X-Originating-IP: [129.83.31.58] Cc: "" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 18:47:31 -0000 --------------070206050207030909000103 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I agree with Bill's statement and have stated so on several occasions. I think it's clear that we've got several use cases that are interested in different things, and I think that there's very little chance that we're going to have one super amazing specification that can cover all of them. I think we're going to end up with several different kinds of tokens with different properties, and we should work on them independently, openly, and in parallel. It was decided at IETF85 that we should put together a regular discussion to help decide the fate of MAC, HOK, and other similar efforts. For those interested in the discussion, Hannes is setting up a series of phone conversations about this very topic: http://www.doodle.com/smvh5pmcqc43dti3#table -- Justin On 11/26/2012 01:41 PM, William Mills wrote: > I object to tying MAC to HOK, I see them as independent and I frankly > don't understand why folks insist that MAC can not proceed without a > broader HOK spec. > > -bill > > ------------------------------------------------------------------------ > *From:* Phil Hunt > *To:* Sergey Beryozkin > *Cc:* "" > *Sent:* Monday, November 26, 2012 10:28 AM > *Subject:* Re: [OAUTH-WG] What needs to be done to complete MAC > > If we want to get this done we have to get agreements on the > requirements for HOK. Several meetings ago (quebec) the group > indicated that mac wasn't appropriate to anyone's needs. > > Some would argue that OAuth1 users arguably have less security than > the simpler bearer token /tls model in OAuth2. This just shows the > real issue of demonstrated need has not been properly defined and > understood. > > More dialog on use cases is very helpful to moving HOK/MAC/etc forward. > > Phil > > On 2012-11-26, at 10:15, Sergey Beryozkin > wrote: > > > Hi > > > > What needs to be done to complete the MAC token spec ? Without > having it signed off it will be difficult to get people working with > OAuth 1.0 convinced to move to 2.0. > > I'm seeing another user request for getting OAuth 1.0 support > extended further because the user expects it is more secure, and I > guess because it is proven to work for people, and I guess because > many OAuth 1.0 users feel that should stay from OAuth 2.0 because of > some bad press. > > > > Without MAC being completed the division will continue, with even > more misleading anti-OAuth2 posts appearing (though I guess some of > the better posts point to some level of complexity in 2.0). > > > > Is it a matter of a security expert validating the text, fixing few > typos, and basically signing it off ? > > > > If someone is interested then I can provide the info offline on how > it MAC supported in our framework to get things tested easily and such... > > > > Cheers, Sergey > > > > _______________________________________________ > > 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 --------------070206050207030909000103 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
I agree with Bill's statement and have stated so on several occasions. I think it's clear that we've got several use cases that are interested in different things, and I think that there's very little chance that we're going to have one super amazing specification that can cover all of them. I think we're going to end up with several different kinds of tokens with different properties, and we should work on them independently, openly, and in parallel.

It was decided at IETF85 that we should put together a regular discussion to help decide the fate of MAC, HOK, and other similar efforts. For those interested in the discussion, Hannes is setting up a series of phone conversations about this very topic:

http://www.doodle.com/smvh5pmcqc43dti3#table

 -- Justin

On 11/26/2012 01:41 PM, William Mills wrote:
I object to tying MAC to HOK, I see them as independent and I frankly don't understand why folks insist that MAC can not proceed without a broader HOK spec.  

-bill

From: Phil Hunt <phil.hunt@oracle.com>
To: Sergey Beryozkin <sberyozkin@gmail.com>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Sent: Monday, November 26, 2012 10:28 AM
Subject: Re: [OAUTH-WG] What needs to be done to complete MAC

If we want to get this done we have to get agreements on the requirements for HOK. Several meetings ago (quebec) the group indicated that mac wasn't appropriate to anyone's needs.

Some would argue that OAuth1 users arguably have less security than the simpler bearer token /tls model in OAuth2. This just shows the real issue of demonstrated need has not been properly defined and understood.

More dialog on use cases is very helpful to moving HOK/MAC/etc forward.

Phil

On 2012-11-26, at 10:15, Sergey Beryozkin <sberyozkin@gmail.com> wrote:

> Hi
>
> What needs to be done to complete the MAC token spec ? Without having it signed off it will be difficult to get people working with OAuth 1.0 convinced to move to 2.0.
> I'm seeing another user request for getting OAuth 1.0 support extended further because the user expects it is more secure, and I guess because it is proven to work for people, and I guess because many OAuth 1.0 users feel that should stay from OAuth 2.0 because of some bad press.
>
> Without MAC being completed the division will continue, with even more misleading anti-OAuth2 posts appearing (though I guess some of the better posts point to some level of complexity in 2.0).
>
> Is it a matter of a security expert validating the text, fixing few typos, and basically signing it off ?
>
> If someone is interested then I can provide the info offline on how it MAC supported in our framework to get things tested easily and such...
>
> Cheers, Sergey
>
> _______________________________________________
> 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

--------------070206050207030909000103-- From ve7jtb@ve7jtb.com Mon Nov 26 10:51:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8CB21F86C9 for ; Mon, 26 Nov 2012 10:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov1cCWo5V-wW for ; Mon, 26 Nov 2012 10:51:27 -0800 (PST) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 52D8B21F86C6 for ; Mon, 26 Nov 2012 10:51:27 -0800 (PST) Received: by mail-gh0-f172.google.com with SMTP id z22so1066529ghb.31 for ; Mon, 26 Nov 2012 10:51:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=xuBa3AugvHmZBxHt7/VV6fGWiAK4bD13Eyc2qP3ZckQ=; b=dHkcJGndCqULtPRW3PDPpTCXcApdsEtJFVjDcmIJDgmMj/LggFwj2wuDu1LTmOikTx 5pQo6UIMAqyowrbl7xfVnK+4lM224RPI57yKOQxGMhc+EDc55FvQG+3kGiw59Ou6Ppmc rIZcxBFCMHUTZ3++dIgBvv8E/vJHjGHBKBhICMPnzo6SHXoyl+jf7DYyaGmznzKX24qv ifvQfXpCc+3NmzcPyXnlzFJDl0DJlHR9uHSmC/EWHL534YRJIg6eMum1yOCgcooUSJS3 gU0hsyy4zG8f4OoNtjSlpqQjjdwFEiKJXbKRB5OB5Z1s8jN4KT62G0HnviqIv8jYZOT9 pk6g== Received: by 10.236.87.77 with SMTP id x53mr12973964yhe.7.1353955886795; Mon, 26 Nov 2012 10:51:26 -0800 (PST) Received: from [192.168.1.43] (190-20-23-36.baf.movistar.cl. [190.20.23.36]) by mx.google.com with ESMTPS id s19sm14505481anl.22.2012.11.26.10.51.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 10:51:26 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_206D61AB-E883-4870-BB9C-65C61DE3821B" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <39488346-171f-4623-9d2b-a125c8444959@email.android.com> Date: Mon, 26 Nov 2012 15:51:05 -0300 Message-Id: <5A0D91C3-4C97-44F3-81D8-5BF0E9FA4453@ve7jtb.com> References: <50B1162A.8020506@lodderstedt.net> <5BB14099-C30A-4CB1-9B9A-39EB8D12863C@ve7jtb.com> <39488346-171f-4623-9d2b-a125c8444959@email.android.com> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmVi82a7PkkcLNuh1AoQvifpjSNSSXbjxFRAFyGO4y9QH/MfkmKHS/SW045K9/MVHqeBr4G Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-json-web-token-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 18:51:28 -0000 --Apple-Mail=_206D61AB-E883-4870-BB9C-65C61DE3821B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 A user_id is scoped to a iss. There is some notion that a prn is globally unique, though the JWT spec = is not clear on that. I think people are thinking of it like a UPN in = LDAP/AD. John B. On 2012-11-26, at 3:46 PM, Torsten Lodderstedt = wrote: > Hi John >=20 > thanks for the explanatian. Just to make sure I got you right. A prn = can be a user_id. A prn is bound to the scope of an iss. >=20 > Regards, > Torsten. >=20 >=20 >=20 > John Bradley schrieb: > JWT is more generic than OIDC. >=20 > prn and user_id as used by OIDC are similar. user_id is already in = wide use with Facebook's signed request. =20 > We were hoping that Facebook would be more likely to migrate from = signed request to JWT if the parameter names stayed the same for = developers. >=20 > In the generic case of a JWT the prn may not be a user. =20 >=20 > The other discussion that I recall around prn was a notion that they = are fully qualified and globally unique. >=20 > We wanted to be clear with user_id that it is scoped to the iss and = not globally unique. >=20 > So a prn was seen as a User Principal name and the user_id was seen as = a persistent non reassignable identifier for the user in the context of = the iss. >=20 > John B. >=20 >=20 > On 2012-11-24, at 3:47 PM, Torsten Lodderstedt = wrote: >=20 > Hi, >=20 > I've got a few comments on your draft. >=20 > I=92m wondering why neither acr nor auth_time (which are used in OIDC) = made their way into this spec? >=20 > What is the difference between prn and the user_id claim OIDC uses? >=20 > regards, > Torsten. >=20 >=20 --Apple-Mail=_206D61AB-E883-4870-BB9C-65C61DE3821B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 A = user_id is scoped to a iss.

There is some notion that = a prn is globally unique, though the JWT spec is not clear on that. =   I think people are thinking of it like a UPN in = LDAP/AD.

John B.
On 2012-11-26, at = 3:46 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

Hi John

thanks for the explanatian. Just to make sure I got you right. A prn can = be a user_id. A prn is bound to the scope of an iss.

Regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com> = schrieb:
JWT is more generic than OIDC.

prn =
and user_id as used by OIDC are similar.   user_id is already in wide =
use with Facebook's signed request.  
We were hoping that Facebook =
would be more likely to migrate from signed request to JWT if the =
parameter names stayed the same for developers.

In the generic =
case of a JWT the prn may not be a user.   

The other discussion =
that I recall around prn was a notion that they are fully qualified and =
globally unique.

We wanted to be clear with user_id that it is =
scoped to the iss and not globally unique.

So a prn was seen as a =
User Principal name and the user_id was seen as a persistent non =
reassignable identifier for the user in the context of the =
iss.

John B.


On 2012-11-24, at 3:47 PM, Torsten =
Lodderstedt <torsten@lodderstedt.net> =
wrote:

Hi,

I've got a few comments on your draft.

I=92m =
wondering why neither acr nor auth_time (which are used in OIDC) made =
their way into this spec?

What is the difference between prn and =
the user_id claim OIDC =
uses?

regards,
Torsten.


<= /div>

= --Apple-Mail=_206D61AB-E883-4870-BB9C-65C61DE3821B-- From torsten@lodderstedt.net Mon Nov 26 10:56:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407F921F849F for ; Mon, 26 Nov 2012 10:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[AWL=1.597, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqpl8Td3qifV for ; Mon, 26 Nov 2012 10:56:32 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by ietfa.amsl.com (Postfix) with ESMTP id 65A2D21F849E for ; Mon, 26 Nov 2012 10:56:32 -0800 (PST) Received: from [91.2.82.133] (helo=[192.168.71.42]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Td3r3-0005Pj-L2; Mon, 26 Nov 2012 19:56:29 +0100 Message-ID: <50B3BB4F.6050404@lodderstedt.net> Date: Mon, 26 Nov 2012 19:56:15 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: OAuth WG References: <50B1162A.8020506@lodderstedt.net> <5BB14099-C30A-4CB1-9B9A-39EB8D12863C@ve7jtb.com> <39488346-171f-4623-9d2b-a125c8444959@email.android.com> <5A0D91C3-4C97-44F3-81D8-5BF0E9FA4453@ve7jtb.com> In-Reply-To: <5A0D91C3-4C97-44F3-81D8-5BF0E9FA4453@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------080309010204040100040406" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-json-web-token-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 18:56:33 -0000 This is a multi-part message in MIME format. --------------080309010204040100040406 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi John, does it make sense to change the spec as follows: - specify the prn claim as being globally unqiue - add user_id as scoped by iss claim What do you think? regards, Torsten. Am 26.11.2012 19:51, schrieb John Bradley: > A user_id is scoped to a iss. > > There is some notion that a prn is globally unique, though the JWT > spec is not clear on that. I think people are thinking of it like a > UPN in LDAP/AD. > > John B. > On 2012-11-26, at 3:46 PM, Torsten Lodderstedt > > wrote: > >> Hi John >> >> thanks for the explanatian. Just to make sure I got you right. A prn >> can be a user_id. A prn is bound to the scope of an iss. >> >> Regards, >> Torsten. >> >> >> >> John Bradley > schrieb: >> >> JWT is more generic than OIDC. >> >> prn and user_id as used by OIDC are similar. user_id is already in wide use with Facebook's signed request. >> We were hoping that Facebook would be more likely to migrate from signed request to JWT if the parameter names stayed the same for developers. >> >> In the generic case of a JWT the prn may not be a user. >> >> The other discussion that I recall around prn was a notion that they are fully qualified and globally unique. >> >> We wanted to be clear with user_id that it is scoped to the iss and not globally unique. >> >> So a prn was seen as a User Principal name and the user_id was seen as a persistent non reassignable identifier for the user in the context of the iss. >> >> John B. >> >> >> On 2012-11-24, at 3:47 PM, Torsten Lodderstedt > wrote: >> >> Hi, I've got a few comments on your draft. I’m wondering why >> neither acr nor auth_time (which are used in OIDC) made their >> way into this spec? What is the difference between prn and >> the user_id claim OIDC uses? regards, Torsten. >> >> >> > --------------080309010204040100040406 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi John,

does it make sense to change the spec as follows:

- specify the prn claim as being globally unqiue
- add user_id as scoped by iss claim

What do you think?

regards,
Torsten.

Am 26.11.2012 19:51, schrieb John Bradley:
A user_id is scoped to a iss.

There is some notion that a prn is globally unique, though the JWT spec is not clear on that.   I think people are thinking of it like a UPN in LDAP/AD.

John B.
On 2012-11-26, at 3:46 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John

thanks for the explanatian. Just to make sure I got you right. A prn can be a user_id. A prn is bound to the scope of an iss.

Regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com> schrieb: 
JWT is more generic than OIDC.

prn and user_id as used by OIDC are similar.   user_id is already in wide use with Facebook's signed request.  
We were hoping that Facebook would be more likely to migrate from signed request to JWT if the parameter names stayed the same for developers.

In the generic case of a JWT the prn may not be a user.   

The other discussion that I recall around prn was a notion that they are fully qualified and globally unique.

We wanted to be clear with user_id that it is scoped to the iss and not globally unique.

So a prn was seen as a User Principal name and the user_id was seen as a persistent non reassignable identifier for the user in the context of the iss.

John B.


On 2012-11-24, at 3:47 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


Hi,

I've got a few comments on your draft.

I’m wondering why neither acr nor auth_time (which are used in OIDC) made their way into this spec?

What is the difference between prn and the user_id claim OIDC uses?

regards,
Torsten.


--------------080309010204040100040406-- From torsten@lodderstedt.net Mon Nov 26 11:03:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF02021F84C9 for ; Mon, 26 Nov 2012 11:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSoB5HO3vORV for ; Mon, 26 Nov 2012 11:03:18 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by ietfa.amsl.com (Postfix) with ESMTP id 67A2821F8441 for ; Mon, 26 Nov 2012 11:03:18 -0800 (PST) Received: from [91.2.82.133] (helo=[192.168.71.42]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Td3xb-0001N5-Vv; Mon, 26 Nov 2012 20:03:16 +0100 Message-ID: <50B3BCE8.3010608@lodderstedt.net> Date: Mon, 26 Nov 2012 20:03:04 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Justin Richer References: <50B11502.2000509@lodderstedt.net> <50B381DC.3070003@mitre.org> In-Reply-To: <50B381DC.3070003@mitre.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-dyn-reg-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 19:03:19 -0000 Hi Justin, Am 26.11.2012 15:51, schrieb Justin Richer: > Hi Torsten, thanks for the comments. > >> Whats the advantage of having two secrets for the same client_id, >> namely request_access_token and client_secret? Why not always issuing >> a secret and use it for authentication on this endpoint (in the same >> way as at the token endpoint)? > Two things are at play here, from what I understand of the discussions > that went into this: > 1) The audience of the secret is different. The client_secret is > intended for the Token Endpoint, while the registration_access_token > is intended for the Registration Endpoint. I would rather intend to use the same credential for a particular client_id on all _AS_ endpoints. That's the way the revocation endpoint is designed. I would not want to have another client cedential there. > 2) Clients can use all different kinds of authentication at the Token > Endpoint, not just a client_secret. This gives us a way to support > dynamic registration of those clients without conflating the > functionality of the Registration Endpoint itself. I don't get this argument. I would assume if clients use another credential (than client_secret) at the token endpoint they use it at the registration endpoint as well. > > Additionally, there's a strong desire from Google and others for a > semi-registered use case, where the app developer gets a "developer > key" that they present to the registration endpoint. This "developer > key" is effectively a bootstrapped registration access token, and if > you look at it that way this lets us keep the same mechanisms here. Ok, it seems the whole design of the registration endpoint is optimized to have the same credential type for bootstrapping and "ordinary" usage on the registration endpoint (in contrast to use the same credential on all endpoints). regards, Torsten. From ve7jtb@ve7jtb.com Mon Nov 26 11:04:43 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1FE21F8441 for ; Mon, 26 Nov 2012 11:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.793 X-Spam-Level: X-Spam-Status: No, score=-2.793 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o5dyxEXEO7k for ; Mon, 26 Nov 2012 11:04:43 -0800 (PST) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36DD321F84C9 for ; Mon, 26 Nov 2012 11:04:42 -0800 (PST) Received: by mail-gh0-f172.google.com with SMTP id z22so1070259ghb.31 for ; Mon, 26 Nov 2012 11:04:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=ksQcl+ieyqlvYVM3+Zb/iWagJL+qgl2Of1lC0s0jLZE=; b=TXC+/oU1MsP+nozBmBOW+1WdD1YrIoGfNeFb8LX+SouH9/dJLa0Pk8brHTuSxWFumK 4fWmcVQ8HSzWz2QJawICVyS6PAS6rKOMpts+vqIU1iOeMSBhx+FaZcCFfpzQxP/RNNIi hehZMlXmosUjOAjAoEll629m6PIqLqSQckkeVI0dYLAYL0B1R9tV4b8rmXCEOT73n1so q9sgZqGJphtcTUrB1Kqec83vqMat+5IxxUcBqiV8gw/PvYuLaPkir5IovXoOqrhaEaA5 QaQ5Oh/aJTBUtMMD25i/fit2x7fnVow2N9gNLWzHbuKhCugWFQJHSw3PNwhV586xhAJh aD9w== Received: by 10.236.122.143 with SMTP id t15mr12589018yhh.26.1353956681882; Mon, 26 Nov 2012 11:04:41 -0800 (PST) Received: from [192.168.1.43] (190-20-23-36.baf.movistar.cl. [190.20.23.36]) by mx.google.com with ESMTPS id z1sm14551877anj.2.2012.11.26.11.04.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 11:04:30 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_90685522-4AB9-43B8-B3C8-A52E0FADE86E" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <50B3BB4F.6050404@lodderstedt.net> Date: Mon, 26 Nov 2012 16:04:10 -0300 Message-Id: <008C8EB5-9962-47B7-811C-2E0F0AF39654@ve7jtb.com> References: <50B1162A.8020506@lodderstedt.net> <5BB14099-C30A-4CB1-9B9A-39EB8D12863C@ve7jtb.com> <39488346-171f-4623-9d2b-a125c8444959@email.android.com> <5A0D91C3-4C97-44F3-81D8-5BF0E9FA4453@ve7jtb.com> <50B3BB4F.6050404@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQk7VGBm7XNAAKh/zjzd5EQRo/kYsEiVhlu6JUZasYgEBZpaIiew2H5d2ROCwkhB8P62Kpwo Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-json-web-token-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 19:04:44 -0000 --Apple-Mail=_90685522-4AB9-43B8-B3C8-A52E0FADE86E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I don't know that we need user_id in the JWT spec it may be enough to = have it as a OIDC extension if it is not globally useful. I agree that the definition of prn should be more specific. On 2012-11-26, at 3:56 PM, Torsten Lodderstedt = wrote: > Hi John, >=20 > does it make sense to change the spec as follows: >=20 > - specify the prn claim as being globally unqiue > - add user_id as scoped by iss claim >=20 > What do you think? >=20 > regards, > Torsten. >=20 > Am 26.11.2012 19:51, schrieb John Bradley: >> A user_id is scoped to a iss. >>=20 >> There is some notion that a prn is globally unique, though the JWT = spec is not clear on that. I think people are thinking of it like a = UPN in LDAP/AD. >>=20 >> John B. >> On 2012-11-26, at 3:46 PM, Torsten Lodderstedt = wrote: >>=20 >>> Hi John >>>=20 >>> thanks for the explanatian. Just to make sure I got you right. A prn = can be a user_id. A prn is bound to the scope of an iss. >>>=20 >>> Regards, >>> Torsten. >>>=20 >>>=20 >>>=20 >>> John Bradley schrieb: >>> JWT is more generic than OIDC. >>>=20 >>> prn and user_id as used by OIDC are similar. user_id is already in = wide use with Facebook's signed request. =20 >>> We were hoping that Facebook would be more likely to migrate from = signed request to JWT if the parameter names stayed the same for = developers. >>>=20 >>> In the generic case of a JWT the prn may not be a user. =20 >>>=20 >>> The other discussion that I recall around prn was a notion that they = are fully qualified and globally unique. >>>=20 >>> We wanted to be clear with user_id that it is scoped to the iss and = not globally unique. >>>=20 >>> So a prn was seen as a User Principal name and the user_id was seen = as a persistent non reassignable identifier for the user in the context = of the iss. >>>=20 >>> John B. >>>=20 >>>=20 >>> On 2012-11-24, at 3:47 PM, Torsten Lodderstedt = wrote: >>>=20 >>> Hi, >>>=20 >>> I've got a few comments on your draft. >>>=20 >>> I=92m wondering why neither acr nor auth_time (which are used in = OIDC) made their way into this spec? >>>=20 >>> What is the difference between prn and the user_id claim OIDC uses? >>>=20 >>> regards, >>> Torsten. >>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_90685522-4AB9-43B8-B3C8-A52E0FADE86E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = don't know that we need user_id in the JWT spec it may be enough to have = it as a OIDC extension if it is not globally = useful.

I agree that the definition of prn should be = more specific.
On 2012-11-26, at 3:56 PM, Torsten = Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20
Hi John,

does it make sense to change the spec as follows:

- specify the prn claim as being globally unqiue
- add user_id as scoped by iss claim

What do you think?

regards,
Torsten.

Am 26.11.2012 19:51, schrieb John Bradley:
A user_id is scoped to a iss.

There is some notion that a prn is globally unique, though the JWT spec is not clear on that.   I think people are = thinking of it like a UPN in LDAP/AD.

John B.
On 2012-11-26, at 3:46 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John

thanks for the explanatian. Just to make sure I got you right. A prn can be a user_id. A prn is bound to the scope of an iss.

Regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com> schrieb: 
JWT is =
more generic than OIDC.

prn and user_id as used by OIDC are similar.   user_id is already in =
wide use with Facebook's signed request. =20
We were hoping that Facebook would be more likely to migrate from signed =
request to JWT if the parameter names stayed the same for developers.

In the generic case of a JWT the prn may not be a user.  =20

The other discussion that I recall around prn was a notion that they are =
fully qualified and globally unique.

We wanted to be clear with user_id that it is scoped to the iss and not =
globally unique.

So a prn was seen as a User Principal name and the user_id was seen as a =
persistent non reassignable identifier for the user in the context of =
the iss.

John B.


On 2012-11-24, at 3:47 PM, Torsten Lodderstedt <torsten@lodderstedt.net> =
wrote:


Hi,

I've got a few comments on your draft.

I=92m wondering why neither acr nor auth_time (which are used in OIDC) =
made their way into this spec?

What is the difference between prn and the user_id claim OIDC uses?

regards,
Torsten.



= --Apple-Mail=_90685522-4AB9-43B8-B3C8-A52E0FADE86E-- From ve7jtb@ve7jtb.com Mon Nov 26 11:10:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CF621F849E for ; Mon, 26 Nov 2012 11:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.831 X-Spam-Level: X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKQYEP7g6Iao for ; Mon, 26 Nov 2012 11:10:51 -0800 (PST) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 736EE21F849B for ; Mon, 26 Nov 2012 11:10:51 -0800 (PST) Received: by mail-gh0-f172.google.com with SMTP id z22so1071754ghb.31 for ; Mon, 26 Nov 2012 11:10:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=xJkyW37nUja+WLqRZR/gG/2KlIKL3sP2kREqkmBUOqg=; b=dz4mL9BBErHqCfnI0ehejL0mrivloScWYGGrF04zo5FC+/wUziOeEwbX7uVpT91Dna AAjUGtwp4tMFeytCWrwOPy7CgIljgb5pKPWlyE4FCZSFBhvMLGHrgpVZA4fwKswvIwlR IJ1qI50CdN+Kct77MzfB3iLz8rJfwsYOPwsgQ7kb+tboj5fLTDw2rH8QRBitrwDfGbPZ G707h10izL8NrsR4UpyUZm1PbRC0GKqFEdqvsCSYyB31MMfLBfQLNARJ46FbWHdXcYb0 kr2xBDcbP3OE/YSnaMVYTt2YZcyE+f0ieNSCXi3Xbz8Ki6so02kF/Cgp5rUWGAjYvSGl UjvQ== Received: by 10.236.86.43 with SMTP id v31mr12863285yhe.62.1353957050747; Mon, 26 Nov 2012 11:10:50 -0800 (PST) Received: from [192.168.1.43] (190-20-23-36.baf.movistar.cl. [190.20.23.36]) by mx.google.com with ESMTPS id k49sm16074527yhj.13.2012.11.26.11.10.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 11:10:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <50B3BCE8.3010608@lodderstedt.net> Date: Mon, 26 Nov 2012 16:10:27 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <50262FE4-D91B-44B4-A16E-0E71179A515F@ve7jtb.com> References: <50B11502.2000509@lodderstedt.net> <50B381DC.3070003@mitre.org> <50B3BCE8.3010608@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkrTbrngQB0dao8oownJiNNcfftyY/qLVxVHQ0xaCQMn8g8MAUCOvzbnBxswaauYaHZ5P5+ Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-dyn-reg-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 19:10:52 -0000 The idea is that registration is how you get/set the credential to use = at the other endpoints. Bootstrapping and updating that with a bearer token is not unreasonable. The larger problem is that the password credential at the token endpoint = is a bit of an anachronism. In my opinion we should be using the assertion profile for that.=20 Basically we are trying to stick with using access tokens for endpoint = authorization. I think that is in the spirit of OAuth. Getting a password to use at the token endpoint with http basic auth is = supported but I prefer to see less basic auth not more. John B. On 2012-11-26, at 4:03 PM, Torsten Lodderstedt = wrote: > Hi Justin, >=20 > Am 26.11.2012 15:51, schrieb Justin Richer: >> Hi Torsten, thanks for the comments. >>=20 >>> Whats the advantage of having two secrets for the same client_id, = namely request_access_token and client_secret? Why not always issuing a = secret and use it for authentication on this endpoint (in the same way = as at the token endpoint)? >> Two things are at play here, from what I understand of the = discussions that went into this: >> 1) The audience of the secret is different. The client_secret is = intended for the Token Endpoint, while the registration_access_token is = intended for the Registration Endpoint. >=20 > I would rather intend to use the same credential for a particular = client_id on all _AS_ endpoints. That's the way the revocation endpoint = is designed. I would not want to have another client cedential there. >=20 >=20 >> 2) Clients can use all different kinds of authentication at the Token = Endpoint, not just a client_secret. This gives us a way to support = dynamic registration of those clients without conflating the = functionality of the Registration Endpoint itself. >=20 > I don't get this argument. I would assume if clients use another = credential (than client_secret) at the token endpoint they use it at the = registration endpoint as well. >=20 >>=20 >> Additionally, there's a strong desire from Google and others for a = semi-registered use case, where the app developer gets a "developer key" = that they present to the registration endpoint. This "developer key" is = effectively a bootstrapped registration access token, and if you look at = it that way this lets us keep the same mechanisms here. >=20 > Ok, it seems the whole design of the registration endpoint is = optimized to have the same credential type for bootstrapping and = "ordinary" usage on the registration endpoint (in contrast to use the = same credential on all endpoints). >=20 > regards, > Torsten. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Mon Nov 26 11:25:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7835D21F84F3 for ; Mon, 26 Nov 2012 11:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsUyx6Lb6oey for ; Mon, 26 Nov 2012 11:25:58 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7D2E821F84F5 for ; Mon, 26 Nov 2012 11:25:57 -0800 (PST) Received: (qmail invoked by alias); 26 Nov 2012 19:01:43 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp030) with SMTP; 26 Nov 2012 20:01:43 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19SVno8omJSSml18sxLt/RN9wabmHfkFFmGBSciMa MxeXqv5apJTJ+m Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 26 Nov 2012 21:01:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> References: <50B3B1B3.50502@gmail.com> To: Phil Hunt X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 19:25:58 -0000 Hi Sergey,=20 as Phil said it would be helpful for us to receive reviews of this = document: http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 The document lists requirements and threats.=20 Ciao Hannes On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote: > If we want to get this done we have to get agreements on the = requirements for HOK. Several meetings ago (quebec) the group indicated = that mac wasn't appropriate to anyone's needs.=20 >=20 > Some would argue that OAuth1 users arguably have less security than = the simpler bearer token /tls model in OAuth2. This just shows the real = issue of demonstrated need has not been properly defined and understood.=20= >=20 > More dialog on use cases is very helpful to moving HOK/MAC/etc = forward.=20 >=20 > Phil >=20 > On 2012-11-26, at 10:15, Sergey Beryozkin = wrote: >=20 >> Hi >>=20 >> What needs to be done to complete the MAC token spec ? Without having = it signed off it will be difficult to get people working with OAuth 1.0 = convinced to move to 2.0. >> I'm seeing another user request for getting OAuth 1.0 support = extended further because the user expects it is more secure, and I guess = because it is proven to work for people, and I guess because many OAuth = 1.0 users feel that should stay from OAuth 2.0 because of some bad = press. >>=20 >> Without MAC being completed the division will continue, with even = more misleading anti-OAuth2 posts appearing (though I guess some of the = better posts point to some level of complexity in 2.0). >>=20 >> Is it a matter of a security expert validating the text, fixing few = typos, and basically signing it off ? >>=20 >> If someone is interested then I can provide the info offline on how = it MAC supported in our framework to get things tested easily and = such... >>=20 >> Cheers, Sergey >>=20 >> _______________________________________________ >> 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 From hannes.tschofenig@gmx.net Mon Nov 26 13:31:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE60E21F8586 for ; Mon, 26 Nov 2012 13:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyi7W0lF0cRP for ; Mon, 26 Nov 2012 13:31:27 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5677021F8588 for ; Mon, 26 Nov 2012 13:31:27 -0800 (PST) Received: (qmail invoked by alias); 26 Nov 2012 19:15:47 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp029) with SMTP; 26 Nov 2012 20:15:47 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/cqCpZXofc6OJXUcc/MQoi+K4/EhxcdIYvFmY5DF +ufE3qG8t+qONb From: Hannes Tschofenig Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Nov 2012 21:15:38 +0200 Message-Id: To: " WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Reminder: Security Requirements / Security Use Cases - Conference Call Poll X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 21:31:28 -0000 --- As Justin pointed out please indicate your availability for the = conference calls.=20 ------ =95 From: Hannes Tschofenig =95 To: "oauth at ietf.org WG" =95 Date: Wed, 21 Nov 2012 23:05:21 +0200 Hi all,=20 Based on the discussions at the OAuth WG meeting at IETF#85 we are = trying to determine suitable dates for conference calls for the OAuth WG = to discuss security requirements and use cases. Here is the link to the Doodle poll: http://www.doodle.com/smvh5pmcqc43dti3 Deadline for providing your input is the **28th November 2012**. Then, we will see whether we can find suitable dates for conference = calls and announce them on the list.=20 It is difficult to find a convenient time for everyone since we have = active participants from everywhere.=20 For this reason we have provided lots of options.=20 Ciao Hannes & Derek From beaton@google.com Mon Nov 26 18:27:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CED21F8670 for ; Mon, 26 Nov 2012 18:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvlwYBJMslmb for ; Mon, 26 Nov 2012 18:27:24 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5859A21F8641 for ; Mon, 26 Nov 2012 18:27:24 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so9880670lbk.31 for ; Mon, 26 Nov 2012 18:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OFgx3gHlqBGToVTa0kyNlihV5ZkDOCoJShSexCAmfIA=; b=jF5WZ1zJTmaBuJoFwxcVZM3T1BrYAqIYq1d0NkP/BtD/2DvJ5FpSnvIAdPA0KzA7ex 15HqMOr0+vQB02dlAs4PaUa/RDJ7KPWWbn0vru2VU3FRKZFqM8ifmfll/wvJxDZ2i7W0 Ni/YrJ4rZtXIKvFXFZo81oH39WHhj/7qhPXVepeiQ5yjpd0vJlP/a9pMf23YY/tOMobL SmHy39iwSYYeqCEvrxz5WaoypPJVk0vspupognh5tNdL95x7wpm02ccESdcSMJmiqwBW sSxDNwOf5o9bG+jFq5DfYp8wYQCHREc94OCmJfagKMD6Vq9wL1yqu+0orkTqb8JRneCW 4PKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=OFgx3gHlqBGToVTa0kyNlihV5ZkDOCoJShSexCAmfIA=; b=gpp/JvLeUjz+M+e6EsF+Ot1dFjuBPrQvN+TE7eIHe1mn6Kl45Yv32AIwEilWGiR1tr haZhz93jQUeVRpb/nC+47qRUx+Q1NMHYQNFHIJmH+e/gX8dQJ+YfuHNLC6yC9vl9D0mM GhCPga/M33HaTXM4tATuPJiG8OKJ4/Fxw0V9qogKkTJhs7lram/NXGBb8HmhnQoPOVtK agOqnQ0KZOYV4keK4JMsgbqy45rpcwxbIbriyX/GgaO+ralSXpURZ1jwJo9cnuDhI6eR oTkJ571AsBmi3fTr22yZooCnQyQyjP4fUW63t8UAa5op5eq2eLjh3inuC3/+SDr+HPpu Rskg== MIME-Version: 1.0 Received: by 10.112.39.105 with SMTP id o9mr5904560lbk.123.1353983243120; Mon, 26 Nov 2012 18:27:23 -0800 (PST) Received: by 10.112.24.98 with HTTP; Mon, 26 Nov 2012 18:27:22 -0800 (PST) In-Reply-To: References: Date: Mon, 26 Nov 2012 18:27:22 -0800 Message-ID: From: Brian Eaton To: Bob Gregory Content-Type: multipart/alternative; boundary=e0cb4efe2d7e3cf2da04cf70ca8c X-Gm-Message-State: ALoCoQlQxb0yDX0IaDOHDjg/kWgnSdaL19JyCFGvXWHS19b9ZhlOmTcNRibAOOb37Oo6WS2KmPCPIwIXwmMO12sXB5ED4i/DzVi+TmP78nDJ2hP38zHxg1v8LAXzQg0fpAcEKsBiy5w7ZXoQBMKwBQ5skOZyJBQg72HCaerHcLbtZ/V+cKMjy2aNBU2eKKVkL2DLGwvFXpec Cc: OAuth WG Subject: Re: [OAUTH-WG] Token refresh and The Two Generals X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 02:27:25 -0000 --e0cb4efe2d7e3cf2da04cf70ca8c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory wrote: > We've had OAuth2 running successfully for a while now, but we're finding > that mobile applications have frequent problems with the refresh flow where > a refresh request is made, but the network connection fails before the new > AT/RT pair is received, leading to a "lost grant". > > In server-logs we can see that the token has been refreshed, and a new RT > issued, but the client is stuck with the old invalidated RT. > > This problem has been reported by two separate client applications, both > of whom are using a retry-mechanism for API requests since they expect an > unreliable network connection. > > Does anybody have any guidance on this issue, or is there any work in an > extension to address the issue of lost grants for token refreshes? > Have you considered not revoking the old RT until the new RT has been successfully used? You might also need to consider what happens with requests that are in-flight at the time the old RT is revoked. For example: 1) client starts token exchange, hangs for some reason. 2) client starts token exchange, succeeds, receives new refresh token 3) client uses new refresh token 4) request 1 completes That could all happen in the space of a second or two. So you might want to think about not revoking the old token until you see the new refresh token used and a bit of time has passed. Cheers, Brian --e0cb4efe2d7e3cf2da04cf70ca8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
O= n Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory <pathogenix@gmail.com= > wrote:
We've had OAu= th2 running successfully for a while now, but we're finding that mobile= applications have frequent problems with the refresh flow where a refresh = request is made, but the network connection fails before the new AT/RT pair= is received, leading to a "lost grant".=A0

In server-logs we can see that the token has been refreshed,= and a new RT issued, but the client is stuck with the old invalidated RT.<= br>

This problem has been reported by two separate = client applications, both of whom are using a retry-mechanism for API reque= sts since they expect an unreliable network connection.

Does anybody have any guidance on this issue, or is the= re any work in an extension to address the issue of lost grants for token r= efreshes?

Have you consid= ered not revoking the old RT until the new RT has been successfully used?

You might also need to consider what happens with reque= sts that are in-flight at the time the old RT is revoked. =A0For example:

1) client starts token exchange, hangs for some rea= son.
2) client starts token exchange, succeeds, receives new refresh token<= /div>
3) client uses new refresh token
4) request 1 completes=

That could all happen in the space of a second or= two. =A0So you might want to think about not revoking the old token until = you see the new refresh token used and a bit of time has passed.

Cheers,
Brian
--e0cb4efe2d7e3cf2da04cf70ca8c-- From twbray@google.com Mon Nov 26 18:48:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B162C21F8625 for ; Mon, 26 Nov 2012 18:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iCYTaYd-V2Y for ; Mon, 26 Nov 2012 18:48:43 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id A52E121F8686 for ; Mon, 26 Nov 2012 18:48:43 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so3681295qaa.10 for ; Mon, 26 Nov 2012 18:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KCCxZSjn/cECD/jnxY9kcRSJPuatFhiZt4UQ86LPh4k=; b=ZjDWQLOLRz4XIlN0m0DCrl7BnhKb7nZk+E9GaM94h8uLwKBuuJl6iH9mE8q5SNgSTW XUCJcNfaFJcP+09RPL0DvI0VqHUffWp9J21f+dPfgoNVJ53vR9NejZ12Ej8uVi6Ulygx +hwFAu8TadK1GHZe9VBoVOtcEv8bd9nSvLzNG+3ByfsVv5FPpSm6N1wMg2ZWaafyZWMl mERIIzKZoVIeeNY4vaShqWsa7mw+SVl7PCnzOBMt3IJLq9GZOzaTXy+4aYdCAzHCAp8q L0F4APDRhqI96NYSxQVpuOKZwHPXUiKq4zOCMfp6Dz90QAHeIxoEGhpmjscO3Fi1xxnr 7gcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=KCCxZSjn/cECD/jnxY9kcRSJPuatFhiZt4UQ86LPh4k=; b=IZ5FmWbZCrVplb/RYCvHvee1sTtNJhVYTA8LSkN7RHSl+bmxdRRNkZWNAQJEpteNUF P+9lELb5lyBi3YN5a9cjpwINcnv2P0gPestnHnf8Ho1EcMXlWg5nzNTG2rvgVvOtFDcd gdc9AKRN3b2u8utEmq9AZqdGt7016uG1PQueax0K/6zBfM1fSZS06+aI6KYO17oQVdCi X2TTj7KLm1s4vrfp2pebc4vYoH7rC/ovz/uRMQCVjqsdaVNz935uAu9HMBYKQ/h3nR48 M7PY7+PwVvWUAsts6kNYUyuNEFUjsNbKCk+un3wW0QTbbUoxuZtS5QVfRxRigXHSa4Ba a+4Q== Received: by 10.224.185.79 with SMTP id cn15mr14755836qab.14.1353984523036; Mon, 26 Nov 2012 18:48:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.39.197 with HTTP; Mon, 26 Nov 2012 18:48:12 -0800 (PST) In-Reply-To: References: From: Tim Bray Date: Mon, 26 Nov 2012 18:48:12 -0800 Message-ID: To: Brian Eaton Content-Type: multipart/alternative; boundary=20cf302ef99c86e7f404cf71168c X-Gm-Message-State: ALoCoQm+ug/PicckQ3QW45m6dy10k9EWnorB0LPst3eegSlji0bp0lyj/zCd0T5OSkjk1L/82cTFeljbaGDNXfUp3JkqPk8f9VtsmD5wp7ZLGU5i/GR9MWZKzVGyv5oZTPi127NN3o0GA15/yNZgp+Aqd664SEEboP/5Uy/k4tBzUQD8Oevfi4BdosfR/dLJe/Cfea7V7Tf6 Cc: OAuth WG , Bob Gregory Subject: Re: [OAUTH-WG] Token refresh and The Two Generals X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 02:48:44 -0000 --20cf302ef99c86e7f404cf71168c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As I read back through this one I=E2=80=99m not getting why you need a new = refresh token. What am I missing? -T On Mon, Nov 26, 2012 at 6:27 PM, Brian Eaton wrote: > On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory wrote= : > >> We've had OAuth2 running successfully for a while now, but we're finding >> that mobile applications have frequent problems with the refresh flow wh= ere >> a refresh request is made, but the network connection fails before the n= ew >> AT/RT pair is received, leading to a "lost grant". >> >> In server-logs we can see that the token has been refreshed, and a new R= T >> issued, but the client is stuck with the old invalidated RT. >> >> This problem has been reported by two separate client applications, both >> of whom are using a retry-mechanism for API requests since they expect a= n >> unreliable network connection. >> >> Does anybody have any guidance on this issue, or is there any work in an >> extension to address the issue of lost grants for token refreshes? >> > > Have you considered not revoking the old RT until the new RT has been > successfully used? > > You might also need to consider what happens with requests that are > in-flight at the time the old RT is revoked. For example: > > 1) client starts token exchange, hangs for some reason. > 2) client starts token exchange, succeeds, receives new refresh token > 3) client uses new refresh token > 4) request 1 completes > > That could all happen in the space of a second or two. So you might want > to think about not revoking the old token until you see the new refresh > token used and a bit of time has passed. > > Cheers, > Brian > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --20cf302ef99c86e7f404cf71168c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As I r= ead back through this one I=E2=80=99m not getting why you need a new refres= h token. =C2=A0What am I missing? =C2=A0-T

On Mon, Nov 26, 2012 at 6:27 PM, Brian Eaton <beaton@google.com><= /span> wrote:
On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory <= pathogenix@gmail.com> wrote:
We've had OAu= th2 running successfully for a while now, but we're finding that mobile= applications have frequent problems with the refresh flow where a refresh = request is made, but the network connection fails before the new AT/RT pair= is received, leading to a "lost grant".=C2=A0

In server-logs we can see that the token has been refreshed,= and a new RT issued, but the client is stuck with the old invalidated RT.<= br>

This problem has been reported by two separate = client applications, both of whom are using a retry-mechanism for API reque= sts since they expect an unreliable network connection.

Does anybody have any guidance on this issue, or is the= re any work in an extension to address the issue of lost grants for token r= efreshes?

Have you consid= ered not revoking the old RT until the new RT has been successfully used?

You might also need to consider what happens with reque= sts that are in-flight at the time the old RT is revoked. =C2=A0For example= :

1) client starts token exchange, hangs for some = reason.
2) client starts token exchange, succeeds, receives new refresh token<= /div>
3) client uses new refresh token
4) request 1 completes=

That could all happen in the space of a second or= two. =C2=A0So you might want to think about not revoking the old token unt= il you see the new refresh token used and a bit of time has passed.

Cheers,
Brian

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--20cf302ef99c86e7f404cf71168c-- From sweeden@au1.ibm.com Mon Nov 26 19:22:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E94921F8434 for ; Mon, 26 Nov 2012 19:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz-vapX7k+23 for ; Mon, 26 Nov 2012 19:22:55 -0800 (PST) Received: from e23smtp02.au.ibm.com (e23smtp02.au.ibm.com [202.81.31.144]) by ietfa.amsl.com (Postfix) with ESMTP id 4C00F21F8432 for ; Mon, 26 Nov 2012 19:22:54 -0800 (PST) Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 27 Nov 2012 13:19:10 +1000 Received: from d23relay05.au.ibm.com (202.81.31.247) by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 27 Nov 2012 13:19:08 +1000 Received: from d23av05.au.ibm.com (d23av05.au.ibm.com [9.190.234.119]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAR3C1iS64422010; Tue, 27 Nov 2012 14:12:02 +1100 Received: from d23av05.au.ibm.com (loopback [127.0.0.1]) by d23av05.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAR3MmFr007080; Tue, 27 Nov 2012 14:22:48 +1100 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av05.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qAR3MlQs007072; Tue, 27 Nov 2012 14:22:47 +1100 In-Reply-To: References: X-KeepSent: 98A12589:2296C7C7-4A257AC3:0011474D; type=4; name=$KeepSent To: Tim Bray X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Shane B Weeden Date: Tue, 27 Nov 2012 13:22:42 +1000 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.3FP2HF29 | July 24, 2012) at 27/11/2012 14:27:31 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 x-cbid: 12112703-5490-0000-0000-0000028C558E Cc: OAuth WG , Bob Gregory , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Token refresh and The Two Generals X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 03:22:56 -0000 X-List-Received-Date: Tue, 27 Nov 2012 03:22:56 -0000 TXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGl0IGlzIGNvbnNpZGVyZWQgYSBiZXN0IHByYWN0aWNl IHRvIHJvbGxvdmVyIGENCnJlZnJlc2ggdG9rZW4gb24gZWFjaCB1c2UgLSB0aGF0IGlzIHdoZW4g YSByZWZyZXNoIHRva2VuIGlzIHVzZWQsIGJvdGggYQ0KbmV3IGFjY2VzcyB0b2tlbiBhbmQgYSBu ZXcgcmVmcmVzaCB0b2tlbiBhcmUgaXNzdWVkLCBhbmQgdGhlIG9sZCByZWZyZXNoDQp0b2tlbiBp cyByZXZva2VkLg0KDQpUaGUgcHJpbWFyeSByZWFzb24gSSBoYXZlIHNlZW4gY2l0ZWQgZm9yIHRo aXMgaXMgaXQgd291bGQgYWxsb3cgZm9yIHRoZQ0KZGV0ZWN0aW9uIG9mIGEgY29tcHJvbWlzZWQg cmVmcmVzaCB0b2tlbiAoY2xvbmVkIGNsaWVudCBmb3IgZXhhbXBsZSkuIElmDQp0aGUgbGVnaXRp bWF0ZSBjbGllbnQgaXMgbm90IHRoZSBmaXJzdCB0byB1c2UgdGhlaXIgcmVmcmVzaCB0b2tlbiBp dCB3aWxsDQpmYWlsIHdoZW4gdGhleSBkbyBldmVudHVhbGx5IHRyeSB0byB1c2UgaXQuIFRoZSBs aWtlbGlob29kIG9mIHN1Y2ggYQ0Kc2NlbmFyaW8gb3Igb3RoZXIgaW1wbGljYXRpb25zIG9mIGEg bG9zdCByZWZyZXNoIHRva2VuIGlzIGEgZGlmZmVyZW50DQpkZWJhdGUuDQoNCklkZWFsbHkgdGhl IHRpbWVvdXRzIG9uIHRoZSBtZXNzYWdlcyBhbmQgdGhlIHRyYW5zcG9ydCB1c2VkIGZvciB0aGUg cmVmcmVzaA0KdG9rZW4gZXhjaGFuZ2Ugc2hvdWxkIGJlICJyZWxpYWJsZSIuIElmIHRoYXQgaXMg bm90IHRoZSBjYXNlIHRoZW4gYQ0KbWVjaGFuaXNtIHN1Y2ggYXMgc3VnZ2VzdGVkIGJ5IEJyaWFu IGlzIHBvc3NpYmxlLCBidXQgdWx0aW1hdGVseSBub3QgdmVyeQ0KY2xlYW4gYXMgaXQgbWVhbnMg eW91IHJlYWxseSBuZWVkIHRvIG1haW50YWluIGF0IGxlYXN0IHR3byB2YWxpZCByZWZyZXNoDQp0 b2tlbnMgY29uY3VycmVudGx5IHBlciBpbml0aWFsIGdyYW50IGFuZCBpdCBnZXRzIG1lc3N5LiBG b3IgZXhhbXBsZQ0KZXh0ZW5kaW5nIEJyaWFuJ3Mgc2NlbmFyaW8sIHdoYXQgd291bGQgeW91IGRv IGluIHJlc3BvbnNlIHRvICM0PyBSZXR1cm4gdGhlDQpzYW1lIHJlZnJlc2ggdG9rZW4gYXMgIzI/ IFJldHVybiBhIG5ldyBvbmUgYW5kIGludmFsaWRhdGUgdGhlIG9uZSByZXR1cm5lZA0KaW4gcmVz cG9uc2UgIzI/IEZyb20gYSBzZXJ2ZXItc2lkZSBwZXJzcGVjdGl2ZSB5b3UgZG9uJ3QgcmVhbGx5 IGtub3cgd2hhdA0KdGhlICJyaWdodCIgdGhpbmcgdG8gZG8gaXMgYXMgeW91IGRvbid0IGtub3cg dGhlIHRydWUgc3RhdGUgb2YgdGhlIGNsaWVudC4NCg0KSSB3b3VsZCBiZSBpbmNsaW5lZCB0byBv cHRvbWlzZSBmb3IgdGhlIG5vcm1hbCBjYXNlIGFuZCBwcm92aWRlZCB0aGUgZXJyb3INCnJhdGUg d2Fzbid0IHRvbyBoaWdoIHNpbXBseSByZXF1aXJlIGEgbmV3IGluaXRpYWwgZ3JhbnQgd2hlbiB0 aGUgYXBwJ3MNCnJlZnJlc2ggdG9rZW4gZ2V0cyBvdXQgb2Ygc3luYy4NCklmIHRoZSBlcnJvciBy YXRlIGlzIHZlcnkgaGlnaCB0aGVuIEkgd291bGQgY29uc2lkZXIgYQ0Kbm9uLU9BdXRoLXN0YW5k YXJkcy1iYXNlZCBtb3JlIHJlbGlhYmxlIHRyYW5zcG9ydCBtZWNoYW5pc20gZm9yIHJlZnJlc2gN CnRva2VuIGZsb3dzIGZyb20gdGhlIG1vYmlsZSwgcGVyaGFwcyB3aXRoIGEgdHJ1c3RlZCBwaWVj ZSBvZiBpbnRlcm1lZGlhcnkNCmluZnJhc3RydWN0dXJlIHRvIGludGVyZmFjZSB3aXRoIHRoZSBy ZWFsIGF1dGhvcml6YXRpb24gc2VydmVyIHVzaW5nIGENCnN0YW5kYXJkIGZsb3cuDQoNClJlZ2Fy ZHMsDQpTaGFuZS4NCg0KDQoNCkZyb206CVRpbSBCcmF5IDx0d2JyYXlAZ29vZ2xlLmNvbT4NClRv OglCcmlhbiBFYXRvbiA8YmVhdG9uQGdvb2dsZS5jb20+DQpDYzoJT0F1dGggV0cgPG9hdXRoQGll dGYub3JnPiwgQm9iIEdyZWdvcnkgPHBhdGhvZ2VuaXhAZ21haWwuY29tPg0KRGF0ZToJMjcvMTEv MjAxMiAxMjo1MyBQTQ0KU3ViamVjdDoJUmU6IFtPQVVUSC1XR10gVG9rZW4gcmVmcmVzaCBhbmQg VGhlIFR3byBHZW5lcmFscw0KU2VudCBieToJb2F1dGgtYm91bmNlc0BpZXRmLm9yZw0KDQoNCg0K QXMgSSByZWFkIGJhY2sgdGhyb3VnaCB0aGlzIG9uZSBJ4oCZbSBub3QgZ2V0dGluZyB3aHkgeW91 IG5lZWQgYSBuZXcgcmVmcmVzaA0KdG9rZW4uIMKgV2hhdCBhbSBJIG1pc3Npbmc/IMKgLVQNCg0K T24gTW9uLCBOb3YgMjYsIDIwMTIgYXQgNjoyNyBQTSwgQnJpYW4gRWF0b24gPGJlYXRvbkBnb29n bGUuY29tPiB3cm90ZToNCiAgT24gRnJpLCBOb3YgMjMsIDIwMTIgYXQgNDo0MyBBTSwgQm9iIEdy ZWdvcnkgPHBhdGhvZ2VuaXhAZ21haWwuY29tPg0KICB3cm90ZToNCiAgIFdlJ3ZlIGhhZCBPQXV0 aDIgcnVubmluZyBzdWNjZXNzZnVsbHkgZm9yIGEgd2hpbGUgbm93LCBidXQgd2UncmUgZmluZGlu Zw0KICAgdGhhdCBtb2JpbGUgYXBwbGljYXRpb25zIGhhdmUgZnJlcXVlbnQgcHJvYmxlbXMgd2l0 aCB0aGUgcmVmcmVzaCBmbG93DQogICB3aGVyZSBhIHJlZnJlc2ggcmVxdWVzdCBpcyBtYWRlLCBi dXQgdGhlIG5ldHdvcmsgY29ubmVjdGlvbiBmYWlscyBiZWZvcmUNCiAgIHRoZSBuZXcgQVQvUlQg cGFpciBpcyByZWNlaXZlZCwgbGVhZGluZyB0byBhICJsb3N0IGdyYW50Ii4NCg0KICAgSW4gc2Vy dmVyLWxvZ3Mgd2UgY2FuIHNlZSB0aGF0IHRoZSB0b2tlbiBoYXMgYmVlbiByZWZyZXNoZWQsIGFu ZCBhIG5ldw0KICAgUlQgaXNzdWVkLCBidXQgdGhlIGNsaWVudCBpcyBzdHVjayB3aXRoIHRoZSBv bGQgaW52YWxpZGF0ZWQgUlQuDQoNCiAgIFRoaXMgcHJvYmxlbSBoYXMgYmVlbiByZXBvcnRlZCBi eSB0d28gc2VwYXJhdGUgY2xpZW50IGFwcGxpY2F0aW9ucywgYm90aA0KICAgb2Ygd2hvbSBhcmUg dXNpbmcgYSByZXRyeS1tZWNoYW5pc20gZm9yIEFQSSByZXF1ZXN0cyBzaW5jZSB0aGV5IGV4cGVj dA0KICAgYW4gdW5yZWxpYWJsZSBuZXR3b3JrIGNvbm5lY3Rpb24uDQoNCiAgIERvZXMgYW55Ym9k eSBoYXZlIGFueSBndWlkYW5jZSBvbiB0aGlzIGlzc3VlLCBvciBpcyB0aGVyZSBhbnkgd29yayBp biBhbg0KICAgZXh0ZW5zaW9uIHRvIGFkZHJlc3MgdGhlIGlzc3VlIG9mIGxvc3QgZ3JhbnRzIGZv ciB0b2tlbiByZWZyZXNoZXM/DQoNCiAgSGF2ZSB5b3UgY29uc2lkZXJlZCBub3QgcmV2b2tpbmcg dGhlIG9sZCBSVCB1bnRpbCB0aGUgbmV3IFJUIGhhcyBiZWVuDQogIHN1Y2Nlc3NmdWxseSB1c2Vk Pw0KDQogIFlvdSBtaWdodCBhbHNvIG5lZWQgdG8gY29uc2lkZXIgd2hhdCBoYXBwZW5zIHdpdGgg cmVxdWVzdHMgdGhhdCBhcmUNCiAgaW4tZmxpZ2h0IGF0IHRoZSB0aW1lIHRoZSBvbGQgUlQgaXMg cmV2b2tlZC4gwqBGb3IgZXhhbXBsZToNCg0KICAxKSBjbGllbnQgc3RhcnRzIHRva2VuIGV4Y2hh bmdlLCBoYW5ncyBmb3Igc29tZSByZWFzb24uDQogIDIpIGNsaWVudCBzdGFydHMgdG9rZW4gZXhj aGFuZ2UsIHN1Y2NlZWRzLCByZWNlaXZlcyBuZXcgcmVmcmVzaCB0b2tlbg0KICAzKSBjbGllbnQg dXNlcyBuZXcgcmVmcmVzaCB0b2tlbg0KICA0KSByZXF1ZXN0IDEgY29tcGxldGVzDQoNCiAgVGhh dCBjb3VsZCBhbGwgaGFwcGVuIGluIHRoZSBzcGFjZSBvZiBhIHNlY29uZCBvciB0d28uIMKgU28g eW91IG1pZ2h0IHdhbnQNCiAgdG8gdGhpbmsgYWJvdXQgbm90IHJldm9raW5nIHRoZSBvbGQgdG9r ZW4gdW50aWwgeW91IHNlZSB0aGUgbmV3IHJlZnJlc2gNCiAgdG9rZW4gdXNlZCBhbmQgYSBiaXQg b2YgdGltZSBoYXMgcGFzc2VkLg0KDQogIENoZWVycywNCiAgQnJpYW4NCg0KICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICBPQXV0aCBtYWlsaW5nIGxp c3QNCiAgT0F1dGhAaWV0Zi5vcmcNCiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K From dgq2011@gmail.com Tue Nov 27 00:52:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB5F21F84E0 for ; Tue, 27 Nov 2012 00:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0Zv-iHBFPJR for ; Tue, 27 Nov 2012 00:52:24 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C970721F84DE for ; Tue, 27 Nov 2012 00:52:24 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so2546483dae.31 for ; Tue, 27 Nov 2012 00:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:references:x-priority:x-has-attach:x-mailer :mime-version:message-id:content-type; bh=JjxDS/GBxh0uWVoX3dCXg0V+KSQ5dFY3jhqIZkOYG24=; b=B+KolXIfkWDoicRoGr+vOTHELaKAR/SnzP3ELvuK0AIhrtCjb123XUiJS6NPDYQXu7 VHkvJgX1osXlJ2zbP7WeSWYJvkxA6gqjdSktdSFhkcU4x8hISI1u3eL9qfSX3k9LgvWX iiwtA63goWHdWFjzldiFM5V7jLbDuUQxzyH7nZO3gRT+r+j2nFniFhi9xd29xnYywI5Q eSSkpXANTBurwgFGm36qJZjg28fPYDOXYQA5CpB3LHdlatwUb6rCpARhQoNx4pkoZsL6 +qOl6fCaFQY50YLIU4dznAgJs6BCS+4ut8rdiBp+6iv7k4oqFGDEriX2+X7vC0BOw3uI IHmg== Received: by 10.66.87.33 with SMTP id u1mr40628294paz.73.1354006344542; Tue, 27 Nov 2012 00:52:24 -0800 (PST) Received: from user-THINK ([218.241.103.76]) by mx.google.com with ESMTPS id bd2sm10324238pab.36.2012.11.27.00.52.20 (version=SSLv3 cipher=OTHER); Tue, 27 Nov 2012 00:52:22 -0800 (PST) Date: Tue, 27 Nov 2012 16:52:19 +0800 From: "Guangqing Deng" To: "oauth@ietf.org" References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com>, <50ACFC53.5080103@gmail.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201211271652159646688@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart335855835141_=----" Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 08:52:25 -0000 This is a multi-part message in MIME format. ------=_001_NextPart335855835141_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SXQgc2VlbXMgdGhhdCB0aGUgY2xpZW50IGNhbm5vdCBrbm93IHdoZXRoZXIgdGhlIHJlZnJlc2gg dG9rZW4gc2hvdWxkIGJlIHVzZWQgdW50aWwgYSBIVFRQIDQwMSBlcnJvciBpcyByZXR1cm5lZCBm cm9tIHRoZSByZXNvdXJjZSBzZXJ2ZXIgZHVlIHRvIHRoZSBleHBpcmF0aW9uIG9mIGN1cnJlbnQg YWNjZXNzIHRva2VuIG9yIHNvbWUgb3RoZXIgcmVhc29ucy4gSG93ZXZlciwgYSBwZXJpb2Qgb2Yg dGltZSBjYW5ub3QgYmUgaWdub3JlZCB3aWxsIGJlIHNwZW50IG9uIG9idGFpbiBhIG5ldyBhY2Nl c3MgdG9rZW4gdXNpbmcgdGhlIHJlZnJlc2ggdG9rZW4gYWZ0ZXIgdGhlIHJlc291cmNlIHNlcnZl ciByZXR1cm5zIGEgSFRUUCA0MDEgZXJyb3IgdG8gdGhlIGNsaWVudCwgd2hpY2ggbWF5IGRlZ3Jh ZGUgdGhlIHVzZXIgZXhwZXJpZW5jZSBzaW5jZSB0aGUgcmVhbC10aW1lIG5hdHVyZSBvZiB0aGUg c2VydmljZSBjYW5ub3QgYmUgZ3VhcmFudGVlZC4gSXMgYSBtZWNoYW5pc20gYnkgd2hpY2ggdGhl IGNsaWVudCBjYW4gY2hlY2sgdGhlIHZhbGlkaXR5IG9mIHRoZSBhY2Nlc3MgdG9rZW4gKG9yIHRo ZSByZWZyZXNoIHRva2VuKSBpbiBhZHZhbmNlIG5lZWRlZCBieSBPYXV0aD8gDQoNCg0KDQpHdWFu Z3FpbmcgRGVuZw0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gKkZyb206KiBKdXN0aW4gUmljaGVyIDxq cmljaGVyQG1pdHJlLm9yZz4NCj4gKlRvOiogU2VyZ2V5IEJlcnlvemtpbiA8c2JlcnlvemtpbkBn bWFpbC5jb20+DQo+ICpDYzoqIG9hdXRoQGlldGYub3JnDQo+ICpTZW50OiogV2VkbmVzZGF5LCBO b3ZlbWJlciAyMSwgMjAxMiA2OjExIEFNDQo+ICpTdWJqZWN0OiogUmU6IFtPQVVUSC1XR10gSG93 IHRoZSBjbGllbnQgY2FuIGRlY2lkZSBpdCBpcyB0aW1lIHRvIHVzZQ0KPiB0aGUgcmVmcmVzaCB0 b2tlbg0KPg0KPiBUaGVyZSdzIG5vIHNpZ25hbGluZyByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9m IHRoZSByZWZyZXNoIHRva2VuIGZyb20NCj4gdGhlIHByb3RlY3RlZCByZXNvdXJjZS4gSW4gbW9y ZSBkaXN0cmlidXRlZCBzZXR1cHMsIHRoZSBwcm90ZWN0ZWQNCj4gcmVzb3VyY2VzIGtub3cgbm90 aGluZyBhYm91dCB0aGUgcmVmcmVzaCB0b2tlbnMgYmVjYXVzZSB0aGUgUFIgbmV2ZXINCj4gc2Vl cyB0aGVtLiBJbiBhbnkgY2FzZS4gdGhlIGNvZGUgcGF0aCBpcyBmYWlybHkgc3RyYWlnaHRmb3J3 YXJkLCBldmVuIGlmDQo+IGJvdGggdG9rZW5zIGFyZSBleHBpcmVkOg0KPg0KPiAtIGNsaWVudCBw cmVzZW50cyBBVCB0byByZXNvdXJjZQ0KPiAtIHJlc291cmNlIHJldHVybnMgZGF0YSwgQVQgd29y a2VkDQo+IC0gW29yXSByZXNvdXJjZSByZXR1cm5zIDQwMCBlcnJvciB0byBjbGllbnQsIEFUIGRp ZG4ndCB3b3JrDQo+IC0gY2xpZW50IHByZXNlbnRzIFJUIHRvIGF1dGggc2VydmVyDQo+IC0gYXV0 aCBzZXJ2ZXIgcmV0dXJucyBuZXcgQVQsIFJUIHdvcmtlZA0KPiAtIFtvcl0gYXV0aCBzZXJ2ZXIg cmV0dXJucyA0MDAgZXJyb3IgdG8gY2xpZW50LCBSVCBkaWRuJ3Qgd29yaw0KPiAtIGNsaWVudCBo YXMgdG8gZ28gZ2V0IGEgbmV3IGF1dGggZ3JhbnQgZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIsIHN0 YXJ0IG92ZXINCj4NCj4gLS0gSnVzdGluDQo+DQo+DQo+IE9uIDExLzIxLzIwMTIgMDY6NTAgQU0s IFNlcmdleSBCZXJ5b3praW4gd3JvdGU6DQo+ICA+IEhpDQo+ICA+DQo+ICA+IEknbSBsb29raW5n IGZvciBzb21lIGd1aWRhbmNlIG9uIGhvdyB0aGUgY2xpZW50IHdoaWNoIGFscmVhZHkgb3ducyBh bg0KPiBhY2Nlc3MgdG9rZW4gY2FuIGRlY2lkZSwgYWZ0ZXIgZ2V0dGluZyBIVFRQIDQwMCBiYWNr IGZyb20gdGhlIHJlc291cmNlDQo+IHNlcnZlciBpdCB0cmllcyB0byBhY2Nlc3Mgb24gYmVoYWxm IG9mIHRoZSBlbmQgdXNlci9yZXNvdXJjZSBvd25lciwgY2FuDQo+IGRlY2lkZSB0aGF0IHRoZSBy ZWZyZXNoIHRva2VuIGl0IGhhcyBjYW4gbm93IGJlIHVzZWQgdG8gZ2V0IGEgbmV3IGFjY2Vzcw0K PiB0b2tlbi4NCj4gID4NCj4gID4gWzFdIHJlZmVycyB0byB2YXJpb3VzIGVycm9yIGNvbmRpdGlv bnMgYnV0IGl0IGlzIG5vdCBvYnZpb3VzIHRvIG1lDQo+IHRoYXQgdGhlIHNhbWUgY29uZGl0aW9u cyAoc29tZSBvZiB0aGVtKSBzaG91bGQgb3IgY2FuIGJlIHJlcG9ydGVkIGR1cmluZw0KPiB0aGUg YWN0dWFsIGNsaWVudCBhY2Nlc3NpbmcgdGhlIHByb3RlY3RlZCByZXNvdXJjZS4NCj4gID4NCj4g ID4gTXkgcXVlc3Rpb24gaXMsIHdoYXQgZXJyb3IgY29uZGl0aW9uLCBpZiBhbnksIGZyb20gWzFd IHNob3VsZCBiZQ0KPiByZXBvcnRlZCBiYWNrIHRvIHRoZSBjbGllbnQgZmFpbGluZyB0byBhY2Nl c3MgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgZHVlDQo+IHRvIHRoZSBhY2Nlc3MgdG9rZW4gYmVpbmcg aW52YWxpZCBvciBleHBpcmVkLCBzbyB0aGF0IGl0IGNhbiBoZWxwIHRoZQ0KPiBjbGllbnQgd2hv IGFsc28gb3ducyB0aGUgcmVmcmVzaCB0b2tlbiB0byBkZWNpZGUgaXQgY2FuIHVzZSBpdCBub3cu Li4NCj4gID4NCj4gID4gVGhhbmtzLCBTZXJnZXkNCj4gID4NCj4gID4gWzFdIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi01LjINCj4gID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gID4gT0F1dGggbWFpbGluZyBsaXN0 DQo+ICA+IE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+ICA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0 DQo+IE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1 dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg= ------=_001_NextPart335855835141_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
It seems that the client cannot know&nb= sp;whether the refresh token should be used&= nbsp;until a HTTP 401 error is returned = ;from the resource server due to the ex= piration of current access token or some&nbs= p;other reasons. However, a period of time&n= bsp;cannot be ignored will be spent on = obtain a new access token using the ref= resh token after the resource server returns=  a HTTP 401 error to the client, w= hich may degrade the user experience since&n= bsp;the real-time nature of the service cann= ot be guaranteed. Is a mechanism by whi= ch the client can check the validity of=  the access token (or the refresh token= ) in advance needed by Oauth?=20
Guangqing Deng
> -----------------------------------------------------------= -------------
> *From:* Justin Richer <jricher@mitre.org&= gt;
> *To:* Sergey Beryozkin <sberyozkin@gmail.= com>
> *Cc:* oauth@ietf.org
> *Sent:* Wednesday, November 21, 2012&nb= sp;6:11 AM
> *Subject:* Re: [OAUTH-WG] How the = client can decide it is time to use
> the refresh token
>
> There's no signaling regarding the = ;validity of the refresh token from
> the protected resource. In more di= stributed setups, the protected
> resources know nothing about the r= efresh tokens because the PR never
> sees them. In any case. the c= ode path is fairly straightforward, even if<= /DIV>
> both tokens are expired:
>
> - client presents AT to resource
> - resource returns data, AT worked=
> - [or] resource returns 400 error&= nbsp;to client, AT didn't work
> - client presents RT to auth = server
> - auth server returns new AT, = ;RT worked
> - [or] auth server returns 400&nbs= p;error to client, RT didn't work
> - client has to go get a = ;new auth grant from the resource owner,&nbs= p;start over
>
> -- Justin
>
>
> On 11/21/2012 06:50 AM, Sergey Ber= yozkin wrote:
>  > Hi
>  >
>  > I'm looking for some gu= idance on how the client which already = owns an
> access token can decide, after get= ting HTTP 400 back from the resource
> server it tries to access on = behalf of the end user/resource owner, can
> decide that the refresh token it&n= bsp;has can now be used to get a n= ew access
> token.
>  >
>  > [1] refers to various e= rror conditions but it is not obvious t= o me
> that the same conditions (some of&= nbsp;them) should or can be reported during<= /DIV>
> the actual client accessing the pr= otected resource.
>  >
>  > My question is, what er= ror condition, if any, from [1] should = be
> reported back to the client failin= g to access a protected resource due
> to the access token being invalid&= nbsp;or expired, so that it can help th= e
> client who also owns the refresh&n= bsp;token to decide it can use it now..= .
>  >
>  > Thanks, Sergey
>  >
>  > [1] http://tools.ietf.org/html/rfc6749= #section-5.2
>  > ___________________________________________= ____
>  > OAuth mailing list
>  > OAuth@ietf.org <mailto:OAuth@ietf.o= rg>
>  > https://www.ietf.org/mailman/listinfo/oauth=
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------=_001_NextPart335855835141_=------ From sberyozkin@gmail.com Tue Nov 27 02:18:41 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F4821F84B6 for ; Tue, 27 Nov 2012 02:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlZzTGXKOJjP for ; Tue, 27 Nov 2012 02:18:40 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA90021F8477 for ; Tue, 27 Nov 2012 02:18:39 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so10155962lbk.31 for ; Tue, 27 Nov 2012 02:18:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Gi6yM7xDEkJoBAsj4Bgx+xzbBA45ZQVthyXauFqrz1o=; b=JYraCyiEMRv1IZgN9rzNTu69+4IqYhzC0x5idxo7WsXHU1IgOzhRbP9y1ef+xpZVMH 7IEXifxQSon1HkmXD6wGhlAMEQvYOLtAn+vZl+Xb4CpgyyGtmQdgz7PBBhx29r84k1yg 62hHeZKtTAM9vBv7VvEvgi1ckig1KDXdhomwxkUtyM7qCQ71eN3o7ICGg0wqgDVitFBT 46v60i1ljZgzWKxGar6aSPFijIjiE98kZrJB+rN37cI8KNI+QqP1y+RE6UDiEQdeiaxK oy7sJCnFUFSxyIWzI4/mWkP5dXKJqV6iaM3YA3eLC9Z08xW/5uyrieo+/4EIf//CKVbc /9lA== Received: by 10.112.83.100 with SMTP id p4mr4222821lby.96.1354011518825; Tue, 27 Nov 2012 02:18:38 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id ts2sm6536950lab.10.2012.11.27.02.18.36 (version=SSLv3 cipher=OTHER); Tue, 27 Nov 2012 02:18:37 -0800 (PST) Message-ID: <50B4937C.5030201@gmail.com> Date: Tue, 27 Nov 2012 10:18:36 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com>, <50ACFC53.5080103@gmail.com> <201211271652159646688@gmail.com> In-Reply-To: <201211271652159646688@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 10:18:41 -0000 On 27/11/12 08:52, Guangqing Deng wrote: > It seems that the client cannot know whether the refresh token should be > used until a HTTP 401 error is returned from the resource server due to > the expiration of current access token or some other reasons. However, a > period of time cannot be ignored will be spent on obtain a new access > token using the refresh token after the resource server returns a HTTP > 401 error to the client, which may degrade the user experience since the > real-time nature of the service cannot be guaranteed. Is a mechanism by > which the client can check the validity of the access token (or the > refresh token) in advance needed by Oauth? I believe an access token response may offer an expires_in parameter which can provide some hint. Actually this raises an interesting question. Suppose the client actually checks this parameter and decides to use a refresh token it also has to pro-actively refresh its current token. IMHO this should work even if the access token has not expired yet and effectively represents another form of a client-initiated revocation of the access token ? It will mean a client which works with the "expires_in" parameter can save a one round trip (the one which returns a failure in case of the access token being expired) ? Does it make sense ? If it does, can some relevant wording make it into the revocation token draft ? Cheers, Sergey > ------------------------------------------------------------------------ > Guangqing Deng > > ------------------------------------------------------------------------ > > *From:* Justin Richer > > *To:* Sergey Beryozkin > > *Cc:* oauth@ietf.org > > *Sent:* Wednesday, November 21, 2012 6:11 AM > > *Subject:* Re: [OAUTH-WG] How the client can decide it is time to use > > the refresh token > > > > There's no signaling regarding the validity of the refresh token from > > the protected resource. In more distributed setups, the protected > > resources know nothing about the refresh tokens because the PR never > > sees them. In any case. the code path is fairly straightforward, even if > > both tokens are expired: > > > > - client presents AT to resource > > - resource returns data, AT worked > > - [or] resource returns 400 error to client, AT didn't work > > - client presents RT to auth server > > - auth server returns new AT, RT worked > > - [or] auth server returns 400 error to client, RT didn't work > > - client has to go get a new auth grant from the resource owner, > start over > > > > -- Justin > > > > > > On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: > > > Hi > > > > > > I'm looking for some guidance on how the client which already owns an > > access token can decide, after getting HTTP 400 back from the resource > > server it tries to access on behalf of the end user/resource owner, can > > decide that the refresh token it has can now be used to get a new access > > token. > > > > > > [1] refers to various error conditions but it is not obvious to me > > that the same conditions (some of them) should or can be reported during > > the actual client accessing the protected resource. > > > > > > My question is, what error condition, if any, from [1] should be > > reported back to the client failing to access a protected resource due > > to the access token being invalid or expired, so that it can help the > > client who also owns the refresh token to decide it can use it now... > > > > > > Thanks, Sergey > > > > > > [1] http://tools.ietf.org/html/rfc6749#section-5.2 > > > _______________________________________________ > > > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sberyozkin@gmail.com Tue Nov 27 03:15:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E42A21F84DF for ; Tue, 27 Nov 2012 03:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2azvzuBmzCqK for ; Tue, 27 Nov 2012 03:15:53 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB2621F84DD for ; Tue, 27 Nov 2012 03:15:41 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so10208206lbk.31 for ; Tue, 27 Nov 2012 03:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hIw2ukagndfrcd+O6Pqv5xUiPwls+KDXK5TZdwbzcwo=; b=eBuqsvqP9im4AWkckFEvfaG/nlJk0yZsM073iDyTFpD29O3zkCYzq+g2MrfFo1QKtm 3IcHNXYX/LZokHRUf9LBkVSzQyC2jx4J5T4UhJoeRBRfozVeKPztcB1oZ3zJb+uCrDKd cL89p5PDTIfHOV8W3erN1w28H7nVbae1eKVPjlYCo1MWnjukxrDWkH3c1Vq/hkEO/QOl voiD8AuePKvAnoBNidtktBxyYAHo0taK8zEwQ2/7rEBJzKTTWBJRLMXotRAp8hhtzkXr 8BSKclNFD7gziuskIinchrSo4wbkmnSIptLFV4VXynMhCPEx5b3Hdw6VNSnK3b0BwyA0 ZryA== Received: by 10.112.40.129 with SMTP id x1mr2100505lbk.95.1354014939627; Tue, 27 Nov 2012 03:15:39 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id ps11sm6618102lab.12.2012.11.27.03.15.37 (version=SSLv3 cipher=OTHER); Tue, 27 Nov 2012 03:15:38 -0800 (PST) Message-ID: <50B4A0D8.4080408@gmail.com> Date: Tue, 27 Nov 2012 11:15:36 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Phil Hunt References: <50B3B1B3.50502@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 11:15:54 -0000 Hi On 26/11/12 18:28, Phil Hunt wrote: > If we want to get this done we have to get agreements on the requirements for HOK. Several meetings ago (quebec) the group indicated that mac wasn't appropriate to anyone's needs. > > Some would argue that OAuth1 users arguably have less security than the simpler bearer token /tls model in OAuth2. This just shows the real issue of demonstrated need has not been properly defined and understood. From my point of view, the issue is not about which model is considered to be more secure but about showing the OAuth1 users which have accepted and accustomed to having the clients signing their token & protected resource requests by following a well-understood signature algorithm that by working with MAC they can effectively get the same with OAuth 2.0 and with the lesser implementation (and roundtrip) cost, IMHO this further support for encouraging 1.0 users to migrate by having also MAC done (in addition to dropping a temporarily request token requirement) is not necessarily a high-priority issue for the major OAuth 2.0 providers who offer a support for large-scale 2.0 deployments and such. It is though more important for the frameworks like the one I'm working upon, which target a smaller scale, simpler OAuth2 applications. well we support OAuth 1.0 and we support the latest MAC draft, but the 'signature' effect is massive and hence I'm hoping MAC spec can be completed without having all the OAuth2.0 experts agreeing on its virtues... Thanks, Sergey > > More dialog on use cases is very helpful to moving HOK/MAC/etc forward. > > Phil > > On 2012-11-26, at 10:15, Sergey Beryozkin wrote: > >> Hi >> >> What needs to be done to complete the MAC token spec ? Without having it signed off it will be difficult to get people working with OAuth 1.0 convinced to move to 2.0. >> I'm seeing another user request for getting OAuth 1.0 support extended further because the user expects it is more secure, and I guess because it is proven to work for people, and I guess because many OAuth 1.0 users feel that should stay from OAuth 2.0 because of some bad press. >> >> Without MAC being completed the division will continue, with even more misleading anti-OAuth2 posts appearing (though I guess some of the better posts point to some level of complexity in 2.0). >> >> Is it a matter of a security expert validating the text, fixing few typos, and basically signing it off ? >> >> If someone is interested then I can provide the info offline on how it MAC supported in our framework to get things tested easily and such... >> >> Cheers, Sergey >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From sberyozkin@gmail.com Tue Nov 27 03:23:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2570E21F850A for ; Tue, 27 Nov 2012 03:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ng731fFZvE4 for ; Tue, 27 Nov 2012 03:23:34 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9904421F8438 for ; Tue, 27 Nov 2012 03:23:29 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so10215111lbk.31 for ; Tue, 27 Nov 2012 03:23:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OkePghcTRtz8jYfYf8n3ByAFxidOBLMIruyD5fyTXbk=; b=NnORXH2jMVwks8YKGmF1Pxa6DsE4ck9YvdFaZ7yNuXh2ZBQjSN/xLVgA51MR67Y8mK Q7XFKFhnnHUWU62eYM537Jt1hxyk+Ht9xiFyU8LNT5WBfvHqTJPw8PkidU0Q7+Bs2TeV +aRjAEALeAGhwbMv+H08i8XYzBw5H8ekGzVCHLGo0UtEjDnjTq0QxMw1TgV5/mU8cuPz fkvhvX4QzXlXc+lsoTC9vuntulBnMIshmUG0d6pq+uvBNjhkhts+2coT+iPcTGhUIMNh zzeKeC13arGC9TPbLzMc0ZCPfuOMT587Zlf6u2hSF6Gqik/gbJez+tf67b5QHZSqmjFc bsnQ== Received: by 10.112.14.9 with SMTP id l9mr6624254lbc.78.1354015408455; Tue, 27 Nov 2012 03:23:28 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id oz12sm6621395lab.17.2012.11.27.03.23.25 (version=SSLv3 cipher=OTHER); Tue, 27 Nov 2012 03:23:26 -0800 (PST) Message-ID: <50B4A2AC.6010904@gmail.com> Date: Tue, 27 Nov 2012 11:23:24 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <50B3B1B3.50502@gmail.com> <6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> In-Reply-To: <6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 11:23:35 -0000 Hi Hannes On 26/11/12 19:01, Hannes Tschofenig wrote: > Hi Sergey, > > as Phil said it would be helpful for us to receive reviews of this document: > http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 > > The document lists requirements and threats. Let me offer two possibly naive reasons why using MAC may help, one of them is related to the security, another to the ease of HOK support on the client 1. The most safe way to return MAC token to the client is to use a two-way TLS due to the mac key also returned to the client. Two-Way TLS offers a stronger support for getting the client authenticated along the way too 2. Assuming HOK confirmation matters at all (and I believe it does), IMHO it is much simpler for a basic client implementation to apply a MAC signature algo and thus work with the OAuth2 servers expecting HOK confirmations One more reason is more about facilitating the further migration to 2.0 which I tried to outline in my response to Phil Hunt Thanks, Sergey > > Ciao > Hannes > > On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote: > >> If we want to get this done we have to get agreements on the requirements for HOK. Several meetings ago (quebec) the group indicated that mac wasn't appropriate to anyone's needs. >> >> Some would argue that OAuth1 users arguably have less security than the simpler bearer token /tls model in OAuth2. This just shows the real issue of demonstrated need has not been properly defined and understood. >> >> More dialog on use cases is very helpful to moving HOK/MAC/etc forward. >> >> Phil >> >> On 2012-11-26, at 10:15, Sergey Beryozkin wrote: >> >>> Hi >>> >>> What needs to be done to complete the MAC token spec ? Without having it signed off it will be difficult to get people working with OAuth 1.0 convinced to move to 2.0. >>> I'm seeing another user request for getting OAuth 1.0 support extended further because the user expects it is more secure, and I guess because it is proven to work for people, and I guess because many OAuth 1.0 users feel that should stay from OAuth 2.0 because of some bad press. >>> >>> Without MAC being completed the division will continue, with even more misleading anti-OAuth2 posts appearing (though I guess some of the better posts point to some level of complexity in 2.0). >>> >>> Is it a matter of a security expert validating the text, fixing few typos, and basically signing it off ? >>> >>> If someone is interested then I can provide the info offline on how it MAC supported in our framework to get things tested easily and such... >>> >>> Cheers, Sergey >>> >>> _______________________________________________ >>> 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 > From pathogenix@gmail.com Tue Nov 27 04:28:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E667E21F84B9; Tue, 27 Nov 2012 04:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AadcSys-cAF0; Tue, 27 Nov 2012 04:28:36 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18BC121F8484; Tue, 27 Nov 2012 04:28:35 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so3674277wey.31 for ; Tue, 27 Nov 2012 04:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2BAoY417BbWzOfplJ5OeuprEVXl4ZQKw53OgHfK2TPw=; b=XDf7+eluL9ioljLHzXotIuAKIInYo5GyqZZsQjMADO/Z+/52GeNsal1Z92VJxlriwP tMjkFbA08xiKxVbFQ9bLSa2WJkIfkdjg+DsFBtg9AfAow/Ajx3hJw3mC9liDr+b/BE2J /2wIlgRcCnLrLvrQ1XeCDQbor4g5+0Dck6rMPb6W0zrx9vYqChQseC2J7hqA7pxDAVVY ixfKiSYCmsbWvnozGoxCEH1hZbntiRHxz1CL/WG25oLWJPRD1HgAe9oYnDVf7GjKYzUK KLI8sCAiJeBOBHtRO2pB6OZ0CiRnaUZew2K0lINW51D/EHmX3fEUhmNfqt6hM3Gu46t3 nu3A== MIME-Version: 1.0 Received: by 10.180.108.38 with SMTP id hh6mr27038565wib.0.1354019315203; Tue, 27 Nov 2012 04:28:35 -0800 (PST) Received: by 10.194.25.202 with HTTP; Tue, 27 Nov 2012 04:28:35 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Nov 2012 12:28:35 +0000 Message-ID: From: Bob Gregory To: Shane B Weeden Content-Type: multipart/alternative; boundary=e89a8f3ba5c14d3cc504cf7930ba Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Token refresh and The Two Generals X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 12:28:38 -0000 --e89a8f3ba5c14d3cc504cf7930ba Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We did consider holding on to two refresh tokens, but it rapidly gets messy and degrades to using a single refresh token: since the old token won't be invalidated until the new one is used, a client can continue to use the old token indefinitely. After hurried conversation, we've decided that we will allow mobile clients to use a long-lived refresh token that does not expire on each request. This isn't our preferred option, since we have no way of detecting a compromised RT, but in order to obtain the RT an attacker must either a) Intercept the token in-flight by a MITM attack over SSL, which is non-trivial, or b) Obtain physical access to the client device, in which case it's game over anyway. We'll probably revisit this decision when we come to do another round of work on authentication, but for now this solves a user-experience issue that we're seeing in the wild, without seriously affecting real-world security. Thanks for your comments, I'll let you know if we find a way to de-messify the two-token solution. Yours, -- Bob. On Tue, Nov 27, 2012 at 3:22 AM, Shane B Weeden wrote= : > My understanding is that it is considered a best practice to rollover a > refresh token on each use - that is when a refresh token is used, both a > new access token and a new refresh token are issued, and the old refresh > token is revoked. > > The primary reason I have seen cited for this is it would allow for the > detection of a compromised refresh token (cloned client for example). If > the legitimate client is not the first to use their refresh token it will > fail when they do eventually try to use it. The likelihood of such a > scenario or other implications of a lost refresh token is a different > debate. > > Ideally the timeouts on the messages and the transport used for the refre= sh > token exchange should be "reliable". If that is not the case then a > mechanism such as suggested by Brian is possible, but ultimately not very > clean as it means you really need to maintain at least two valid refresh > tokens concurrently per initial grant and it gets messy. For example > extending Brian's scenario, what would you do in response to #4? Return t= he > same refresh token as #2? Return a new one and invalidate the one returne= d > in response #2? From a server-side perspective you don't really know what > the "right" thing to do is as you don't know the true state of the client= . > > I would be inclined to optomise for the normal case and provided the erro= r > rate wasn't too high simply require a new initial grant when the app's > refresh token gets out of sync. > If the error rate is very high then I would consider a > non-OAuth-standards-based more reliable transport mechanism for refresh > token flows from the mobile, perhaps with a trusted piece of intermediary > infrastructure to interface with the real authorization server using a > standard flow. > > Regards, > Shane. > > > > From: Tim Bray > To: Brian Eaton > Cc: OAuth WG , Bob Gregory > Date: 27/11/2012 12:53 PM > Subject: Re: [OAUTH-WG] Token refresh and The Two Generals > Sent by: oauth-bounces@ietf.org > > > > As I read back through this one I=92m not getting why you need a new refr= esh > token. What am I missing? -T > > On Mon, Nov 26, 2012 at 6:27 PM, Brian Eaton wrote: > On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory > wrote: > We've had OAuth2 running successfully for a while now, but we're findi= ng > that mobile applications have frequent problems with the refresh flow > where a refresh request is made, but the network connection fails befo= re > the new AT/RT pair is received, leading to a "lost grant". > > In server-logs we can see that the token has been refreshed, and a new > RT issued, but the client is stuck with the old invalidated RT. > > This problem has been reported by two separate client applications, bo= th > of whom are using a retry-mechanism for API requests since they expect > an unreliable network connection. > > Does anybody have any guidance on this issue, or is there any work in = an > extension to address the issue of lost grants for token refreshes? > > Have you considered not revoking the old RT until the new RT has been > successfully used? > > You might also need to consider what happens with requests that are > in-flight at the time the old RT is revoked. For example: > > 1) client starts token exchange, hangs for some reason. > 2) client starts token exchange, succeeds, receives new refresh token > 3) client uses new refresh token > 4) request 1 completes > > That could all happen in the space of a second or two. So you might wa= nt > to think about not revoking the old token until you see the new refresh > token used and a bit of time has passed. > > Cheers, > Brian > > _______________________________________________ > 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 > --=20 Q. How many members of a demographic group does it take to perform a specified task? A. A finite number; one to perform the task, and the remainder to act in a manner stereotypical of the group in question. --e89a8f3ba5c14d3cc504cf7930ba Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We did consider holding on to two refresh tokens, but it rapidly gets messy= and degrades to using a single refresh token: since the old token won'= t be invalidated until the new one is used, a client can continue to use th= e old token indefinitely.

After hurried conversation, we've decided that we will a= llow mobile clients to use a long-lived refresh token that does not expire = on each request. This isn't our preferred option, since we have no way = of detecting a compromised RT, but in order to obtain the RT an attacker mu= st either

a) Intercept the token in-flight by a MITM attack over SSL, which = is non-trivial, or=A0
b) Obtain physical access to the client device, in= which case it's game over anyway.

We'll p= robably revisit this decision when we come to do another round of work on a= uthentication, but for now this solves a user-experience issue that we'= re seeing in the wild, without seriously affecting real-world security.

Thanks for your comments, I'll let you know if we f= ind a way to de-messify the two-token solution.

Yo= urs,


=A0-- Bob.


On Tue, Nov 27, 2012 at 3:22 AM, Shane B= Weeden <sweeden@au1.ibm.com> wrote:
My understanding is that it is considered a best practice to rollover a
refresh token on each use - that is when a refresh token is used, both a new access token and a new refresh token are issued, and the old refresh token is revoked.

The primary reason I have seen cited for this is it would allow for the
detection of a compromised refresh token (cloned client for example). If the legitimate client is not the first to use their refresh token it will fail when they do eventually try to use it. The likelihood of such a
scenario or other implications of a lost refresh token is a different
debate.

Ideally the timeouts on the messages and the transport used for the refresh=
token exchange should be "reliable". If that is not the case then= a
mechanism such as suggested by Brian is possible, but ultimately not very clean as it means you really need to maintain at least two valid refresh tokens concurrently per initial grant and it gets messy. For example
extending Brian's scenario, what would you do in response to #4? Return= the
same refresh token as #2? Return a new one and invalidate the one returned<= br> in response #2? From a server-side perspective you don't really know wh= at
the "right" thing to do is as you don't know the true state o= f the client.

I would be inclined to optomise for the normal case and provided the error<= br> rate wasn't too high simply require a new initial grant when the app= 9;s
refresh token gets out of sync.
If the error rate is very high then I would consider a
non-OAuth-standards-based more reliable transport mechanism for refresh
token flows from the mobile, perhaps with a trusted piece of intermediary infrastructure to interface with the real authorization server using a
standard flow.

Regards,
Shane.



From: =A0 Tim Bray <twbray@google.c= om>
To: =A0 =A0 Brian Eaton <beaton@goo= gle.com>
Cc: =A0 =A0 OAuth WG <oauth@ietf.org>, Bob Gregory <pathogenix@= gmail.com>
Date: =A0 27/11/2012 12:53 PM
Subject: =A0 =A0 =A0 =A0Re: [OAUTH-WG] Token refresh and The Two Generals Sent by: =A0 =A0 =A0 =A0oauth-bou= nces@ietf.org



As I read back through this one I=92m not getting why you need a new refres= h
token. =A0What am I missing? =A0-T

On Mon, Nov 26, 2012 at 6:27 PM, Brian Eaton <beaton@google.com> wrote:
=A0 On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory <pathogenix@gmail.com>
=A0 wrote:
=A0 =A0We've had OAuth2 running successfully for a while now, but we= 9;re finding
=A0 =A0that mobile applications have frequent problems with the refresh flo= w
=A0 =A0where a refresh request is made, but the network connection fails be= fore
=A0 =A0the new AT/RT pair is received, leading to a "lost grant".=

=A0 =A0In server-logs we can see that the token has been refreshed, and a n= ew
=A0 =A0RT issued, but the client is stuck with the old invalidated RT.

=A0 =A0This problem has been reported by two separate client applications, = both
=A0 =A0of whom are using a retry-mechanism for API requests since they expe= ct
=A0 =A0an unreliable network connection.

=A0 =A0Does anybody have any guidance on this issue, or is there any work i= n an
=A0 =A0extension to address the issue of lost grants for token refreshes?
=A0 Have you considered not revoking the old RT until the new RT has been =A0 successfully used?

=A0 You might also need to consider what happens with requests that are
=A0 in-flight at the time the old RT is revoked. =A0For example:

=A0 1) client starts token exchange, hangs for some reason.
=A0 2) client starts token exchange, succeeds, receives new refresh token =A0 3) client uses new refresh token
=A0 4) request 1 completes

=A0 That could all happen in the space of a second or two. =A0So you might = want
=A0 to think about not revoking the old token until you see the new refresh=
=A0 token used and a bit of time has passed.

=A0 Cheers,
=A0 Brian

=A0 _______________________________________________
=A0 OAuth mailing list
=A0 OAuth@ietf.org
=A0 https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
= Q. How many members of a demographic group does it take to perform a specif= ied task?

A. A finite number; one to perform the task, a= nd the remainder to act in a manner stereotypical of the group in question.=

--e89a8f3ba5c14d3cc504cf7930ba-- From hannes.tschofenig@nsn.com Tue Nov 27 04:31:04 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025B921F84BC for ; Tue, 27 Nov 2012 04:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sH3aIfb1hyxD for ; Tue, 27 Nov 2012 04:31:03 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 194C921F84B9 for ; Tue, 27 Nov 2012 04:31:02 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id qARCUpQx015649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 13:30:51 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id qARCUpeW003279; Tue, 27 Nov 2012 13:30:51 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Nov 2012 13:30:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Nov 2012 14:33:05 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D022492FA@FIESEXC035.nsn-intra.net> In-Reply-To: <50B4A2AC.6010904@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] What needs to be done to complete MAC Thread-Index: Ac3MkaupJJKG2KbOQjuiaijUvqkiWwACHnQw References: <50B3B1B3.50502@gmail.com><6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> <50B4A2AC.6010904@gmail.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Sergey Beryozkin" , "Hannes Tschofenig" X-OriginalArrivalTime: 27 Nov 2012 12:30:35.0291 (UTC) FILETIME=[FFD6CEB0:01CDCC9A] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4267 X-purgate-ID: 151667::1354019451-000010BC-2A00C774/0-0/0-0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 12:31:04 -0000 Hi Sergey,=20 I believe we would make faster progress on security topics if could focus on listing security requirements we have and what threats we want to mitigate. The reason why we have not finished this topic is simply because everyone was just talking about specific (but incomplete) solutions. You are unfortunately falling in the same trap as well.=20 If you really care about the topic then have a look at the mentioned document and tell us whether the requirements are complete.=20 Reading through the document you will notice that there a few more considerations to pay attention to than just the few listed below.=20 Ciao Hannes > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of ext Sergey Beryozkin > Sent: Tuesday, November 27, 2012 1:23 PM > To: Hannes Tschofenig > Cc: > Subject: Re: [OAUTH-WG] What needs to be done to complete MAC >=20 > Hi Hannes > On 26/11/12 19:01, Hannes Tschofenig wrote: > > Hi Sergey, > > > > as Phil said it would be helpful for us to receive reviews of this > document: > > http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 > > > > The document lists requirements and threats. >=20 >=20 > Let me offer two possibly naive reasons why using MAC may help, one of > them is related to the security, another to the ease of HOK support on > the client >=20 > 1. The most safe way to return MAC token to the client is to use a > two-way TLS due to the mac key also returned to the client. Two-Way TLS > offers a stronger support for getting the client authenticated along the > way too >=20 > 2. Assuming HOK confirmation matters at all (and I believe it does), > IMHO it is much simpler for a basic client implementation to apply a MAC > signature algo and thus work with the OAuth2 servers expecting HOK > confirmations >=20 > One more reason is more about facilitating the further migration to 2.0 > which I tried to outline in my response to Phil Hunt >=20 > Thanks, Sergey >=20 > > > > Ciao > > Hannes > > > > On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote: > > > >> If we want to get this done we have to get agreements on the > requirements for HOK. Several meetings ago (quebec) the group indicated > that mac wasn't appropriate to anyone's needs. > >> > >> Some would argue that OAuth1 users arguably have less security than > the simpler bearer token /tls model in OAuth2. This just shows the real > issue of demonstrated need has not been properly defined and understood. > >> > >> More dialog on use cases is very helpful to moving HOK/MAC/etc > forward. > >> > >> Phil > >> > >> On 2012-11-26, at 10:15, Sergey Beryozkin > wrote: > >> > >>> Hi > >>> > >>> What needs to be done to complete the MAC token spec ? Without > having it signed off it will be difficult to get people working with > OAuth 1.0 convinced to move to 2.0. > >>> I'm seeing another user request for getting OAuth 1.0 support > extended further because the user expects it is more secure, and I guess > because it is proven to work for people, and I guess because many OAuth > 1.0 users feel that should stay from OAuth 2.0 because of some bad press. > >>> > >>> Without MAC being completed the division will continue, with even > more misleading anti-OAuth2 posts appearing (though I guess some of the > better posts point to some level of complexity in 2.0). > >>> > >>> Is it a matter of a security expert validating the text, fixing few > typos, and basically signing it off ? > >>> > >>> If someone is interested then I can provide the info offline on how > it MAC supported in our framework to get things tested easily and such... > >>> > >>> Cheers, Sergey > >>> > >>> _______________________________________________ > >>> 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 > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sberyozkin@gmail.com Tue Nov 27 04:45:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAD421F8561 for ; Tue, 27 Nov 2012 04:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFjLLfsAjXgz for ; Tue, 27 Nov 2012 04:45:13 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99C7521F854A for ; Tue, 27 Nov 2012 04:45:12 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so10287114lbk.31 for ; Tue, 27 Nov 2012 04:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sPDw7EykqIdAYZRqZsAy6SU/qgC7ckg8mPi97XrmZlk=; b=HRzaNvlXI0iSBaDzOpuK3+69RY/l4a6nb4sHxnLNpz/nMWV3ezlPGtHcaZFFwpUNQo H1RLGKq3CyVAY6VSjqSSaK9n5frvq+sE0DSnwzDvevWHrfXq1NdpENP/5y3W2mEYY7c3 iI1RzQb+zq0ehb8EWJi1vGefJbQaTbRZ5/zvn61bZBTQThqSMnLIvuOLr0wZgg4jY0Vn fFlRcg0GzVHV7VQvJ9RTif7fDY6GIt0mZBoXtdx8i2VngziccKTTDQG4CIbqnFfFq5Gn o72oTeFW+1x1Ym/wIcQxSpaVOYA2jAe/KjdNhDCdwE6D8UkX6rAS3+OhWUWEdwti3njG C1kg== Received: by 10.152.111.166 with SMTP id ij6mr14530521lab.38.1354020311379; Tue, 27 Nov 2012 04:45:11 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id ps11sm6734710lab.12.2012.11.27.04.45.09 (version=SSLv3 cipher=OTHER); Tue, 27 Nov 2012 04:45:10 -0800 (PST) Message-ID: <50B4B5D4.4070805@gmail.com> Date: Tue, 27 Nov 2012 12:45:08 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <50B3B1B3.50502@gmail.com><6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> <50B4A2AC.6010904@gmail.com> <999913AB42CC9341B05A99BBF358718D022492FA@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D022492FA@FIESEXC035.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 12:45:20 -0000 Hi Hannes On 27/11/12 12:33, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Sergey, > > I believe we would make faster progress on security topics if could > focus on listing security requirements we have and what threats we want > to mitigate. The reason why we have not finished this topic is simply > because everyone was just talking about specific (but incomplete) > solutions. You are unfortunately falling in the same trap as well. Quite possible - I was hoping to give some perspective of someone who would like to see a wider acceptance of 2.0 at the grass root level if you wish where 'grass root' represents simple 2.0 applications. > > If you really care about the topic then have a look at the mentioned > document and tell us whether the requirements are complete. > Reading through the document you will notice that there a few more > considerations to pay attention to than just the few listed below. > Believe it or not I did read the document awhile back :-) and will definitely read it few times more - it is a must-read. I'm just concerned that it appears that the possible progress on MAC needs to be justified by linking it implicitly to the security threats doc. And I'm not sure it is the best way to follow. How about a slightly different approach. Do you agree that supporting HOK is important ? Assuming yes then I guess the threats doc must be talking about the relevant issues that HOK can help with addressing. If we can agree on this then IMHO MAC passes the acceptance criteria because it offers one way to provide a HOK support. Whether JWT or other token type may also help with HOK support is entirely different issue and it is down to specific OAuth2 implementers on which HOK-capable token to support Thanks, Sergey > Ciao > Hannes > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of ext Sergey Beryozkin >> Sent: Tuesday, November 27, 2012 1:23 PM >> To: Hannes Tschofenig >> Cc: >> Subject: Re: [OAUTH-WG] What needs to be done to complete MAC >> >> Hi Hannes >> On 26/11/12 19:01, Hannes Tschofenig wrote: >>> Hi Sergey, >>> >>> as Phil said it would be helpful for us to receive reviews of this >> document: >>> http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 >>> >>> The document lists requirements and threats. >> >> >> Let me offer two possibly naive reasons why using MAC may help, one of >> them is related to the security, another to the ease of HOK support on >> the client >> >> 1. The most safe way to return MAC token to the client is to use a >> two-way TLS due to the mac key also returned to the client. Two-Way > TLS >> offers a stronger support for getting the client authenticated along > the >> way too >> >> 2. Assuming HOK confirmation matters at all (and I believe it does), >> IMHO it is much simpler for a basic client implementation to apply a > MAC >> signature algo and thus work with the OAuth2 servers expecting HOK >> confirmations >> >> One more reason is more about facilitating the further migration to > 2.0 >> which I tried to outline in my response to Phil Hunt >> >> Thanks, Sergey >> >>> >>> Ciao >>> Hannes >>> >>> On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote: >>> >>>> If we want to get this done we have to get agreements on the >> requirements for HOK. Several meetings ago (quebec) the group > indicated >> that mac wasn't appropriate to anyone's needs. >>>> >>>> Some would argue that OAuth1 users arguably have less security than >> the simpler bearer token /tls model in OAuth2. This just shows the > real >> issue of demonstrated need has not been properly defined and > understood. >>>> >>>> More dialog on use cases is very helpful to moving HOK/MAC/etc >> forward. >>>> >>>> Phil >>>> >>>> On 2012-11-26, at 10:15, Sergey Beryozkin >> wrote: >>>> >>>>> Hi >>>>> >>>>> What needs to be done to complete the MAC token spec ? Without >> having it signed off it will be difficult to get people working with >> OAuth 1.0 convinced to move to 2.0. >>>>> I'm seeing another user request for getting OAuth 1.0 support >> extended further because the user expects it is more secure, and I > guess >> because it is proven to work for people, and I guess because many > OAuth >> 1.0 users feel that should stay from OAuth 2.0 because of some bad > press. >>>>> >>>>> Without MAC being completed the division will continue, with even >> more misleading anti-OAuth2 posts appearing (though I guess some of > the >> better posts point to some level of complexity in 2.0). >>>>> >>>>> Is it a matter of a security expert validating the text, fixing > few >> typos, and basically signing it off ? >>>>> >>>>> If someone is interested then I can provide the info offline on > how >> it MAC supported in our framework to get things tested easily and > such... >>>>> >>>>> Cheers, Sergey >>>>> >>>>> _______________________________________________ >>>>> 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 From jricher@mitre.org Tue Nov 27 07:29:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A7721F84BC for ; Tue, 27 Nov 2012 07:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCCVF4Du1YlR for ; Tue, 27 Nov 2012 07:29:30 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7806021F847D for ; Tue, 27 Nov 2012 07:29:30 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AB80E531015D; Tue, 27 Nov 2012 10:29:29 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9C6A253101B2; Tue, 27 Nov 2012 10:29:29 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.132]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Tue, 27 Nov 2012 10:29:29 -0500 From: "Richer, Justin P." To: Sergey Beryozkin Thread-Topic: [OAUTH-WG] How the client can decide it is time to use the refresh token Thread-Index: AQHNzIiVuYkhGwMiHUOgGgluHEInBJf+IpkA Date: Tue, 27 Nov 2012 15:29:28 +0000 Message-ID: References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com>, <50ACFC53.5080103@gmail.com> <201211271652159646688@gmail.com> <50B4937C.5030201@gmail.com> In-Reply-To: <50B4937C.5030201@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.43.53] Content-Type: text/plain; charset="us-ascii" Content-ID: <88AB65BCC1231D4088B6A8D4F4C24132@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:29:31 -0000 The client can indeed save a round trip by proactively refreshing the acces= s token. This does not necessarily revoke the existing access token. Many i= mplementations do that, so your mileage may vary. -- Justin On Nov 27, 2012, at 5:18 AM, Sergey Beryozkin wrote: > On 27/11/12 08:52, Guangqing Deng wrote: >> It seems that the client cannot know whether the refresh token should be >> used until a HTTP 401 error is returned from the resource server due to >> the expiration of current access token or some other reasons. However, a >> period of time cannot be ignored will be spent on obtain a new access >> token using the refresh token after the resource server returns a HTTP >> 401 error to the client, which may degrade the user experience since the >> real-time nature of the service cannot be guaranteed. Is a mechanism by >> which the client can check the validity of the access token (or the >> refresh token) in advance needed by Oauth? >=20 > I believe an access token response may offer an expires_in parameter whic= h can provide some hint. Actually this raises an interesting question. > Suppose the client actually checks this parameter and decides to use > a refresh token it also has to pro-actively refresh its current token. >=20 > IMHO this should work even if the access token has not expired yet and ef= fectively represents another form of a client-initiated revocation of the a= ccess token ? It will mean a client which works with the "expires_in" param= eter can save a one round trip (the one which returns a failure in case of = the access token being expired) ? >=20 > Does it make sense ? If it does, can some relevant wording make it into t= he revocation token draft ? >=20 > Cheers, Sergey >=20 >> ------------------------------------------------------------------------ >> Guangqing Deng >> > ----------------------------------------------------------------------= -- >> > *From:* Justin Richer >> > *To:* Sergey Beryozkin >> > *Cc:* oauth@ietf.org >> > *Sent:* Wednesday, November 21, 2012 6:11 AM >> > *Subject:* Re: [OAUTH-WG] How the client can decide it is time to use >> > the refresh token >> > >> > There's no signaling regarding the validity of the refresh token from >> > the protected resource. In more distributed setups, the protected >> > resources know nothing about the refresh tokens because the PR never >> > sees them. In any case. the code path is fairly straightforward, even = if >> > both tokens are expired: >> > >> > - client presents AT to resource >> > - resource returns data, AT worked >> > - [or] resource returns 400 error to client, AT didn't work >> > - client presents RT to auth server >> > - auth server returns new AT, RT worked >> > - [or] auth server returns 400 error to client, RT didn't work >> > - client has to go get a new auth grant from the resource owner, >> start over >> > >> > -- Justin >> > >> > >> > On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: >> > > Hi >> > > >> > > I'm looking for some guidance on how the client which already owns a= n >> > access token can decide, after getting HTTP 400 back from the resource >> > server it tries to access on behalf of the end user/resource owner, ca= n >> > decide that the refresh token it has can now be used to get a new acce= ss >> > token. >> > > >> > > [1] refers to various error conditions but it is not obvious to me >> > that the same conditions (some of them) should or can be reported duri= ng >> > the actual client accessing the protected resource. >> > > >> > > My question is, what error condition, if any, from [1] should be >> > reported back to the client failing to access a protected resource due >> > to the access token being invalid or expired, so that it can help the >> > client who also owns the refresh token to decide it can use it now... >> > > >> > > Thanks, Sergey >> > > >> > > [1] http://tools.ietf.org/html/rfc6749#section-5.2 >> > > _______________________________________________ >> > > 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 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sberyozkin@gmail.com Tue Nov 27 07:41:21 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D253621F8464 for ; Tue, 27 Nov 2012 07:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiGm4I7H6+nI for ; Tue, 27 Nov 2012 07:41:20 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 499AA21F845B for ; Tue, 27 Nov 2012 07:41:20 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so10321135lah.31 for ; Tue, 27 Nov 2012 07:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=A+qYiSDzz+qhDHvzeTqd9rArenf/K1Y8qwSCS4Jj4xc=; b=Vi0exwJnvsgdTEDs3KbzZSFzFUGzuXwpG69oUoiEiPZl+2weysR4tiqing2b5fz9vk Ka094VcuZU7QuQHDefjtySOIajSEJRjvP68ZdZSwoN+S+yM81RXBTaAXR42PpM1qwJkz rtLgi9pQnyqIpKOmpUNP1xbdzrJdTg5xEQciL6g/odkzdDPDJHpgVT4NHBgC9gd2gNS1 y+fLkk7KNJhVFb1cEmnfZXS3HnwoXtInMTuQNJc4oaSg3bqZsoiQY3nt4gmV6fiAbuSr JH9YCzAH1p33MqPOw036f+oj4ku1m1RIY3dU94Efx1qTNj6K91tF0C08y032vLPhO0w8 K3fQ== Received: by 10.152.104.77 with SMTP id gc13mr14850083lab.16.1354030878550; Tue, 27 Nov 2012 07:41:18 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id m3sm7202153lbb.13.2012.11.27.07.41.16 (version=SSLv3 cipher=OTHER); Tue, 27 Nov 2012 07:41:17 -0800 (PST) Message-ID: <50B4DF1B.4030700@gmail.com> Date: Tue, 27 Nov 2012 15:41:15 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Richer, Justin P." References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com>, <50ACFC53.5080103@gmail.com> <201211271652159646688@gmail.com> <50B4937C.5030201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:41:21 -0000 On 27/11/12 15:29, Richer, Justin P. wrote: > The client can indeed save a round trip by proactively refreshing the access token. This does not necessarily revoke the existing access token. Many implementations do that, so your mileage may vary. > I don't understand. So the client will still have the existing access token which may have not been revoked, and then also another access token which was just returned in response to the refresh grant request ? And if you mean that no actual revocation is actually done, why then have the client worry about doing the proactive refresh ? I can imagine that may be that it will only be the actual refresh token refreshed itself, but why keep the access token if the client has requested a refresh ? Sergey > -- Justin > > On Nov 27, 2012, at 5:18 AM, Sergey Beryozkin wrote: > >> On 27/11/12 08:52, Guangqing Deng wrote: >>> It seems that the client cannot know whether the refresh token should be >>> used until a HTTP 401 error is returned from the resource server due to >>> the expiration of current access token or some other reasons. However, a >>> period of time cannot be ignored will be spent on obtain a new access >>> token using the refresh token after the resource server returns a HTTP >>> 401 error to the client, which may degrade the user experience since the >>> real-time nature of the service cannot be guaranteed. Is a mechanism by >>> which the client can check the validity of the access token (or the >>> refresh token) in advance needed by Oauth? >> >> I believe an access token response may offer an expires_in parameter which can provide some hint. Actually this raises an interesting question. >> Suppose the client actually checks this parameter and decides to use >> a refresh token it also has to pro-actively refresh its current token. >> >> IMHO this should work even if the access token has not expired yet and effectively represents another form of a client-initiated revocation of the access token ? It will mean a client which works with the "expires_in" parameter can save a one round trip (the one which returns a failure in case of the access token being expired) ? >> >> Does it make sense ? If it does, can some relevant wording make it into the revocation token draft ? >> >> Cheers, Sergey >> >>> ------------------------------------------------------------------------ >>> Guangqing Deng >>>> ------------------------------------------------------------------------ >>>> *From:* Justin Richer >>>> *To:* Sergey Beryozkin >>>> *Cc:* oauth@ietf.org >>>> *Sent:* Wednesday, November 21, 2012 6:11 AM >>>> *Subject:* Re: [OAUTH-WG] How the client can decide it is time to use >>>> the refresh token >>>> >>>> There's no signaling regarding the validity of the refresh token from >>>> the protected resource. In more distributed setups, the protected >>>> resources know nothing about the refresh tokens because the PR never >>>> sees them. In any case. the code path is fairly straightforward, even if >>>> both tokens are expired: >>>> >>>> - client presents AT to resource >>>> - resource returns data, AT worked >>>> - [or] resource returns 400 error to client, AT didn't work >>>> - client presents RT to auth server >>>> - auth server returns new AT, RT worked >>>> - [or] auth server returns 400 error to client, RT didn't work >>>> - client has to go get a new auth grant from the resource owner, >>> start over >>>> >>>> -- Justin >>>> >>>> >>>> On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: >>>>> Hi >>>>> >>>>> I'm looking for some guidance on how the client which already owns an >>>> access token can decide, after getting HTTP 400 back from the resource >>>> server it tries to access on behalf of the end user/resource owner, can >>>> decide that the refresh token it has can now be used to get a new access >>>> token. >>>>> >>>>> [1] refers to various error conditions but it is not obvious to me >>>> that the same conditions (some of them) should or can be reported during >>>> the actual client accessing the protected resource. >>>>> >>>>> My question is, what error condition, if any, from [1] should be >>>> reported back to the client failing to access a protected resource due >>>> to the access token being invalid or expired, so that it can help the >>>> client who also owns the refresh token to decide it can use it now... >>>>> >>>>> Thanks, Sergey >>>>> >>>>> [1] http://tools.ietf.org/html/rfc6749#section-5.2 >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> _______________________________________________ >>> 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 > From jricher@mitre.org Tue Nov 27 07:48:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FE521F8477 for ; Tue, 27 Nov 2012 07:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jcTlEJ6dzwD for ; Tue, 27 Nov 2012 07:48:44 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 47AAC21F85B6 for ; Tue, 27 Nov 2012 07:48:44 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A7AB61F03C2; Tue, 27 Nov 2012 10:48:43 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 898E8531000A; Tue, 27 Nov 2012 10:48:43 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.132]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Tue, 27 Nov 2012 10:48:43 -0500 From: "Richer, Justin P." To: Sergey Beryozkin Thread-Topic: [OAUTH-WG] How the client can decide it is time to use the refresh token Thread-Index: AQHNzIiVuYkhGwMiHUOgGgluHEInBJf+IpkAgAADbICAAAIugA== Date: Tue, 27 Nov 2012 15:48:42 +0000 Message-ID: References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com>, <50ACFC53.5080103@gmail.com> <201211271652159646688@gmail.com> <50B4937C.5030201@gmail.com> <50B4DF1B.4030700@gmail.com> In-Reply-To: <50B4DF1B.4030700@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.43.53] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:48:45 -0000 Yes, the client can keep two tokens and try using both of them if it wants = to. I think that you're conflating revocation and expiration here, and miss= ing a key use case: downscoping. Let's say the client gets an access grant = for [A, B, C], and it gets RT and AT1 for those scopes. The client then wan= ts to call a service with *only* scope B, so it sends RT in with scope B in= the refresh request to get AT2 with that scope alone. AT1 is still valid, = assuming it hasn't expired or otherwise been revoked. The client can choose= which AT to present to the protected resources in different situations.=20 In all of these cases, it's completely up to the AS and the PRs whether or = not any of the tokens in the wild are still valid. Your AS might decide tha= t once a RT is used, it will simply throw away all existing AT's attached t= o that RT. That's totally a valid use case, and the client needs to be able= to handle that (in the same way that it handles any invalid token).=20 If you want the clients to explicitly throw out tokens, use the Token Revoc= ation spec. -- Justin On Nov 27, 2012, at 10:41 AM, Sergey Beryozkin wrote: > On 27/11/12 15:29, Richer, Justin P. wrote: >> The client can indeed save a round trip by proactively refreshing the ac= cess token. This does not necessarily revoke the existing access token. Man= y implementations do that, so your mileage may vary. >>=20 >=20 > I don't understand. >=20 > So the client will still have the existing access token which may have no= t been revoked, and then also another access token which was just returned = in response to the refresh grant request ? >=20 > And if you mean that no actual revocation is actually done, why then have= the client worry about doing the proactive refresh ? >=20 > I can imagine that may be that it will only be the actual refresh token r= efreshed itself, but why keep the access token if the client has requested = a refresh ? >=20 > Sergey >=20 >> -- Justin >>=20 >> On Nov 27, 2012, at 5:18 AM, Sergey Beryozkin wrote: >>=20 >>> On 27/11/12 08:52, Guangqing Deng wrote: >>>> It seems that the client cannot know whether the refresh token should = be >>>> used until a HTTP 401 error is returned from the resource server due t= o >>>> the expiration of current access token or some other reasons. However,= a >>>> period of time cannot be ignored will be spent on obtain a new access >>>> token using the refresh token after the resource server returns a HTTP >>>> 401 error to the client, which may degrade the user experience since t= he >>>> real-time nature of the service cannot be guaranteed. Is a mechanism b= y >>>> which the client can check the validity of the access token (or the >>>> refresh token) in advance needed by Oauth? >>>=20 >>> I believe an access token response may offer an expires_in parameter wh= ich can provide some hint. Actually this raises an interesting question. >>> Suppose the client actually checks this parameter and decides to use >>> a refresh token it also has to pro-actively refresh its current token. >>>=20 >>> IMHO this should work even if the access token has not expired yet and = effectively represents another form of a client-initiated revocation of the= access token ? It will mean a client which works with the "expires_in" par= ameter can save a one round trip (the one which returns a failure in case o= f the access token being expired) ? >>>=20 >>> Does it make sense ? If it does, can some relevant wording make it into= the revocation token draft ? >>>=20 >>> Cheers, Sergey >>>=20 >>>> ----------------------------------------------------------------------= -- >>>> Guangqing Deng >>>>> ---------------------------------------------------------------------= --- >>>>> *From:* Justin Richer >>>>> *To:* Sergey Beryozkin >>>>> *Cc:* oauth@ietf.org >>>>> *Sent:* Wednesday, November 21, 2012 6:11 AM >>>>> *Subject:* Re: [OAUTH-WG] How the client can decide it is time to use >>>>> the refresh token >>>>>=20 >>>>> There's no signaling regarding the validity of the refresh token from >>>>> the protected resource. In more distributed setups, the protected >>>>> resources know nothing about the refresh tokens because the PR never >>>>> sees them. In any case. the code path is fairly straightforward, even= if >>>>> both tokens are expired: >>>>>=20 >>>>> - client presents AT to resource >>>>> - resource returns data, AT worked >>>>> - [or] resource returns 400 error to client, AT didn't work >>>>> - client presents RT to auth server >>>>> - auth server returns new AT, RT worked >>>>> - [or] auth server returns 400 error to client, RT didn't work >>>>> - client has to go get a new auth grant from the resource owner, >>>> start over >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>>=20 >>>>> On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: >>>>>> Hi >>>>>>=20 >>>>>> I'm looking for some guidance on how the client which already owns a= n >>>>> access token can decide, after getting HTTP 400 back from the resourc= e >>>>> server it tries to access on behalf of the end user/resource owner, c= an >>>>> decide that the refresh token it has can now be used to get a new acc= ess >>>>> token. >>>>>>=20 >>>>>> [1] refers to various error conditions but it is not obvious to me >>>>> that the same conditions (some of them) should or can be reported dur= ing >>>>> the actual client accessing the protected resource. >>>>>>=20 >>>>>> My question is, what error condition, if any, from [1] should be >>>>> reported back to the client failing to access a protected resource du= e >>>>> to the access token being invalid or expired, so that it can help the >>>>> client who also owns the refresh token to decide it can use it now... >>>>>>=20 >>>>>> Thanks, Sergey >>>>>>=20 >>>>>> [1] http://tools.ietf.org/html/rfc6749#section-5.2 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From sberyozkin@gmail.com Tue Nov 27 08:26:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4890521F8449 for ; Tue, 27 Nov 2012 08:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0+Sn7UuJBM2 for ; Tue, 27 Nov 2012 08:26:26 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E508521F8482 for ; Tue, 27 Nov 2012 08:26:25 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so10368546lah.31 for ; Tue, 27 Nov 2012 08:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zInJEVLeGij4dNyLQQrRl49fSxd2qsmiVwQDUTPpVD8=; b=0UaeuTAm1MgQHBXnxz+EG2kQHBqndxI35f+5T0OlW0Vj74pLDprFDwsrlsNfW1E4Io wJj9GW5Hcui6O95MY7jdapmSppZV14qWAFqAPzEhpu3pOL78lUfwd3MkKeXEG2uTSJOK ZqelbBmvCd+hiRHAEl7aRQ9eT6c524XTVViyXU7LnJZfEH429L7JqzWamU3NVlNfp+JE E2dvvoTOke2xq45xVCXAO5Wy0IIsMOTGJXGiDrET+NNgXpYBYEBCb/HGkiscIk924L5l ptoLEffWJUiAyDHjPX0rm7dQtWAVqEqjmskXwbIa5A6LauGydwLMiypKzGw+E8Wl91NW n/9A== Received: by 10.112.100.195 with SMTP id fa3mr3050053lbb.38.1354033576348; Tue, 27 Nov 2012 08:26:16 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id l1sm7279409lbm.1.2012.11.27.08.26.13 (version=SSLv3 cipher=OTHER); Tue, 27 Nov 2012 08:26:14 -0800 (PST) Message-ID: <50B4E9A4.1030508@gmail.com> Date: Tue, 27 Nov 2012 16:26:12 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Richer, Justin P." References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com>, <50ACFC53.5080103@gmail.com> <201211271652159646688@gmail.com> <50B4937C.5030201@gmail.com> <50B4DF1B.4030700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 16:26:27 -0000 On 27/11/12 15:48, Richer, Justin P. wrote: > Yes, the client can keep two tokens and try using both of them if it wants to. I think that you're conflating revocation and expiration here, and missing a key use case: downscoping. Let's say the client gets an access grant for [A, B, C], and it gets RT and AT1 for those scopes. The client then wants to call a service with *only* scope B, so it sends RT in with scope B in the refresh request to get AT2 with that scope alone. AT1 is still valid, assuming it hasn't expired or otherwise been revoked. The client can choose which AT to present to the protected resources in different situations. > That is complex :-). Using a refresh token to downscope and keep a number of access tokens is definitely beyond my imagination at the moment, why would a client want to downscope its access token ? Is it basically described at: http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-03#section-3.10 ? I'm still not getting though why access token with the richer set of scopes needs to be explicitly downscoped by the client, is it because using a token with a richer set of scopes can lead to some authorization issues ? I was thinking that the down-scoping only makes sense during the authorization code flow where AS downscopes what the client has requested but obviously I'm only at the start of the learning curve :-). > In all of these cases, it's completely up to the AS and the PRs whether or not any of the tokens in the wild are still valid. Your AS might decide that once a RT is used, it will simply throw away all existing AT's attached to that RT. That's totally a valid use case, and the client needs to be able to handle that (in the same way that it handles any invalid token). > > If you want the clients to explicitly throw out tokens, use the Token Revocation spec. > OK, that makes sense now. Thanks, Sergey > -- Justin > > On Nov 27, 2012, at 10:41 AM, Sergey Beryozkin wrote: > >> On 27/11/12 15:29, Richer, Justin P. wrote: >>> The client can indeed save a round trip by proactively refreshing the access token. This does not necessarily revoke the existing access token. Many implementations do that, so your mileage may vary. >>> >> >> I don't understand. >> >> So the client will still have the existing access token which may have not been revoked, and then also another access token which was just returned in response to the refresh grant request ? >> >> And if you mean that no actual revocation is actually done, why then have the client worry about doing the proactive refresh ? >> >> I can imagine that may be that it will only be the actual refresh token refreshed itself, but why keep the access token if the client has requested a refresh ? >> >> Sergey >> >>> -- Justin >>> >>> On Nov 27, 2012, at 5:18 AM, Sergey Beryozkin wrote: >>> >>>> On 27/11/12 08:52, Guangqing Deng wrote: >>>>> It seems that the client cannot know whether the refresh token should be >>>>> used until a HTTP 401 error is returned from the resource server due to >>>>> the expiration of current access token or some other reasons. However, a >>>>> period of time cannot be ignored will be spent on obtain a new access >>>>> token using the refresh token after the resource server returns a HTTP >>>>> 401 error to the client, which may degrade the user experience since the >>>>> real-time nature of the service cannot be guaranteed. Is a mechanism by >>>>> which the client can check the validity of the access token (or the >>>>> refresh token) in advance needed by Oauth? >>>> >>>> I believe an access token response may offer an expires_in parameter which can provide some hint. Actually this raises an interesting question. >>>> Suppose the client actually checks this parameter and decides to use >>>> a refresh token it also has to pro-actively refresh its current token. >>>> >>>> IMHO this should work even if the access token has not expired yet and effectively represents another form of a client-initiated revocation of the access token ? It will mean a client which works with the "expires_in" parameter can save a one round trip (the one which returns a failure in case of the access token being expired) ? >>>> >>>> Does it make sense ? If it does, can some relevant wording make it into the revocation token draft ? >>>> >>>> Cheers, Sergey >>>> >>>>> ------------------------------------------------------------------------ >>>>> Guangqing Deng >>>>>> ------------------------------------------------------------------------ >>>>>> *From:* Justin Richer >>>>>> *To:* Sergey Beryozkin >>>>>> *Cc:* oauth@ietf.org >>>>>> *Sent:* Wednesday, November 21, 2012 6:11 AM >>>>>> *Subject:* Re: [OAUTH-WG] How the client can decide it is time to use >>>>>> the refresh token >>>>>> >>>>>> There's no signaling regarding the validity of the refresh token from >>>>>> the protected resource. In more distributed setups, the protected >>>>>> resources know nothing about the refresh tokens because the PR never >>>>>> sees them. In any case. the code path is fairly straightforward, even if >>>>>> both tokens are expired: >>>>>> >>>>>> - client presents AT to resource >>>>>> - resource returns data, AT worked >>>>>> - [or] resource returns 400 error to client, AT didn't work >>>>>> - client presents RT to auth server >>>>>> - auth server returns new AT, RT worked >>>>>> - [or] auth server returns 400 error to client, RT didn't work >>>>>> - client has to go get a new auth grant from the resource owner, >>>>> start over >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: >>>>>>> Hi >>>>>>> >>>>>>> I'm looking for some guidance on how the client which already owns an >>>>>> access token can decide, after getting HTTP 400 back from the resource >>>>>> server it tries to access on behalf of the end user/resource owner, can >>>>>> decide that the refresh token it has can now be used to get a new access >>>>>> token. >>>>>>> >>>>>>> [1] refers to various error conditions but it is not obvious to me >>>>>> that the same conditions (some of them) should or can be reported during >>>>>> the actual client accessing the protected resource. >>>>>>> >>>>>>> My question is, what error condition, if any, from [1] should be >>>>>> reported back to the client failing to access a protected resource due >>>>>> to the access token being invalid or expired, so that it can help the >>>>>> client who also owns the refresh token to decide it can use it now... >>>>>>> >>>>>>> Thanks, Sergey >>>>>>> >>>>>>> [1] http://tools.ietf.org/html/rfc6749#section-5.2 >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> > From Adam.Lewis@motorolasolutions.com Tue Nov 27 09:24:55 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189D221F84D0 for ; Tue, 27 Nov 2012 09:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZfNU0lZ79RF for ; Tue, 27 Nov 2012 09:24:54 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD9B21F8555 for ; Tue, 27 Nov 2012 09:24:53 -0800 (PST) Received: from mail201-co9-R.bigfish.com (10.236.132.229) by CO9EHSOBE028.bigfish.com (10.236.130.91) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Nov 2012 17:24:51 +0000 Received: from mail201-co9 (localhost [127.0.0.1]) by mail201-co9-R.bigfish.com (Postfix) with ESMTP id 0040D3C01D6 for ; Tue, 27 Nov 2012 17:24:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.160.210.14; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg02.am.mot-solutions.com; RD:ct11msg02.mot-solutions.com; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zzbb2dI98dI9371Id6eah542M1432I1418I4015I179cIzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h) Received-SPF: pass (mail201-co9: domain of motorolasolutions.com designates 192.160.210.14 as permitted sender) client-ip=192.160.210.14; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg02.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT001.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail201-co9 (localhost.localdomain [127.0.0.1]) by mail201-co9 (MessageSwitch) id 1354037089770137_16533; Tue, 27 Nov 2012 17:24:49 +0000 (UTC) Received: from CO9EHSMHS021.bigfish.com (unknown [10.236.132.229]) by mail201-co9.bigfish.com (Postfix) with ESMTP id B89938004A for ; Tue, 27 Nov 2012 17:24:49 +0000 (UTC) Received: from ct11msg02.am.mot-solutions.com (192.160.210.14) by CO9EHSMHS021.bigfish.com (10.236.130.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Nov 2012 17:24:34 +0000 Received: from ct11msg02.am.mot-solutions.com (ct11vts03.am.mot.com [10.177.16.162]) by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id qARHWMPh028765 for ; Tue, 27 Nov 2012 12:32:22 -0500 (EST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id qARHWLT7028762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 27 Nov 2012 12:32:22 -0500 (EST) Received: from mail85-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Nov 2012 17:24:31 +0000 Received: from mail85-am1 (localhost [127.0.0.1]) by mail85-am1-R.bigfish.com (Postfix) with ESMTP id 5372A60139 for ; Tue, 27 Nov 2012 17:24:31 +0000 (UTC) Received: from mail85-am1 (localhost.localdomain [127.0.0.1]) by mail85-am1 (MessageSwitch) id 1354037068487423_15359; Tue, 27 Nov 2012 17:24:28 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.252]) by mail85-am1.bigfish.com (Postfix) with ESMTP id 74774360088; Tue, 27 Nov 2012 17:24:28 +0000 (UTC) Received: from BY2PRD0411HT001.namprd04.prod.outlook.com (157.56.237.133) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Nov 2012 17:24:26 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.107]) by BY2PRD0411HT001.namprd04.prod.outlook.com ([10.255.128.36]) with mapi id 14.16.0239.002; Tue, 27 Nov 2012 17:24:25 +0000 From: Lewis Adam-CAL022 To: Sergey Beryozkin , "Richer, Justin P." Thread-Topic: [OAUTH-WG] How the client can decide it is time to use the refresh token Thread-Index: AQHNzLw130X2EOc15ES5HoRuSNXmxpf97Jpg Date: Tue, 27 Nov 2012 17:24:25 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A92F19E386@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com>, <50ACFC53.5080103@gmail.com> <201211271652159646688@gmail.com> <50B4937C.5030201@gmail.com> <50B4DF1B.4030700@gmail.com> <50B4E9A4.1030508@gmail.com> In-Reply-To: <50B4E9A4.1030508@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.163.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMAIL.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%MITRE.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 17:24:55 -0000 Hi Sergey, In my use cases the client actively monitors the expiration of the AT in or= der to request a new AT using the RT. We do this as you suggested, because= presenting an expired AT to the RS is a wasted round trip and adds latency= and degrades the user experience. Why send the AT if we know it's expired= ? As to your other question, one reason to down scope an AT ... in my use cas= es the AS issues access tokens for many different RS's. It is a security c= oncern to send an AT to RS1 that has the ability to also access protected r= esources at RS2 and RS3 and RSn, etc. So I make a first request to get a "= master" AT with a master RT, and then immediately destroy the master AT and= use the master RT to get a down-scoped AT - one for each RS. This is inef= ficient though, and I've been nagging the WG to consider a draft to allow a= client to request an array of access tokens of different scopes.=20 These are just my experience, and as Justin mentioned, your millage may var= y. Hope it helps either way :-) adam -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of S= ergey Beryozkin Sent: Tuesday, November 27, 2012 10:26 AM To: Richer, Justin P. Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] How the client can decide it is time to use the ref= resh token On 27/11/12 15:48, Richer, Justin P. wrote: > Yes, the client can keep two tokens and try using both of them if it want= s to. I think that you're conflating revocation and expiration here, and mi= ssing a key use case: downscoping. Let's say the client gets an access gran= t for [A, B, C], and it gets RT and AT1 for those scopes. The client then w= ants to call a service with *only* scope B, so it sends RT in with scope B = in the refresh request to get AT2 with that scope alone. AT1 is still valid= , assuming it hasn't expired or otherwise been revoked. The client can choo= se which AT to present to the protected resources in different situations. > That is complex :-). Using a refresh token to downscope and keep a=20 number of access tokens is definitely beyond my imagination at the=20 moment, why would a client want to downscope its access token ? Is it basically described at: http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-03#section-3.10 ? I'm still not getting though why access token with the richer set of=20 scopes needs to be explicitly downscoped by the client, is it because=20 using a token with a richer set of scopes can lead to some authorization=20 issues ? I was thinking that the down-scoping only makes sense during the=20 authorization code flow where AS downscopes what the client has=20 requested but obviously I'm only at the start of the learning curve :-). > In all of these cases, it's completely up to the AS and the PRs whether o= r not any of the tokens in the wild are still valid. Your AS might decide t= hat once a RT is used, it will simply throw away all existing AT's attached= to that RT. That's totally a valid use case, and the client needs to be ab= le to handle that (in the same way that it handles any invalid token). > > If you want the clients to explicitly throw out tokens, use the Token Rev= ocation spec. > OK, that makes sense now. Thanks, Sergey > -- Justin > > On Nov 27, 2012, at 10:41 AM, Sergey Beryozkin wrote: > >> On 27/11/12 15:29, Richer, Justin P. wrote: >>> The client can indeed save a round trip by proactively refreshing the a= ccess token. This does not necessarily revoke the existing access token. Ma= ny implementations do that, so your mileage may vary. >>> >> >> I don't understand. >> >> So the client will still have the existing access token which may have n= ot been revoked, and then also another access token which was just returned= in response to the refresh grant request ? >> >> And if you mean that no actual revocation is actually done, why then hav= e the client worry about doing the proactive refresh ? >> >> I can imagine that may be that it will only be the actual refresh token = refreshed itself, but why keep the access token if the client has requested= a refresh ? >> >> Sergey >> >>> -- Justin >>> >>> On Nov 27, 2012, at 5:18 AM, Sergey Beryozkin wrote: >>> >>>> On 27/11/12 08:52, Guangqing Deng wrote: >>>>> It seems that the client cannot know whether the refresh token should= be >>>>> used until a HTTP 401 error is returned from the resource server due = to >>>>> the expiration of current access token or some other reasons. However= , a >>>>> period of time cannot be ignored will be spent on obtain a new access >>>>> token using the refresh token after the resource server returns a HTT= P >>>>> 401 error to the client, which may degrade the user experience since = the >>>>> real-time nature of the service cannot be guaranteed. Is a mechanism = by >>>>> which the client can check the validity of the access token (or the >>>>> refresh token) in advance needed by Oauth? >>>> >>>> I believe an access token response may offer an expires_in parameter w= hich can provide some hint. Actually this raises an interesting question. >>>> Suppose the client actually checks this parameter and decides to use >>>> a refresh token it also has to pro-actively refresh its current token. >>>> >>>> IMHO this should work even if the access token has not expired yet and= effectively represents another form of a client-initiated revocation of th= e access token ? It will mean a client which works with the "expires_in" pa= rameter can save a one round trip (the one which returns a failure in case = of the access token being expired) ? >>>> >>>> Does it make sense ? If it does, can some relevant wording make it int= o the revocation token draft ? >>>> >>>> Cheers, Sergey >>>> >>>>> ---------------------------------------------------------------------= --- >>>>> Guangqing Deng >>>>>> --------------------------------------------------------------------= ---- >>>>>> *From:* Justin Richer >>>>>> *To:* Sergey Beryozkin >>>>>> *Cc:* oauth@ietf.org >>>>>> *Sent:* Wednesday, November 21, 2012 6:11 AM >>>>>> *Subject:* Re: [OAUTH-WG] How the client can decide it is time to us= e >>>>>> the refresh token >>>>>> >>>>>> There's no signaling regarding the validity of the refresh token fro= m >>>>>> the protected resource. In more distributed setups, the protected >>>>>> resources know nothing about the refresh tokens because the PR never >>>>>> sees them. In any case. the code path is fairly straightforward, eve= n if >>>>>> both tokens are expired: >>>>>> >>>>>> - client presents AT to resource >>>>>> - resource returns data, AT worked >>>>>> - [or] resource returns 400 error to client, AT didn't work >>>>>> - client presents RT to auth server >>>>>> - auth server returns new AT, RT worked >>>>>> - [or] auth server returns 400 error to client, RT didn't work >>>>>> - client has to go get a new auth grant from the resource owner, >>>>> start over >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: >>>>>>> Hi >>>>>>> >>>>>>> I'm looking for some guidance on how the client which already owns = an >>>>>> access token can decide, after getting HTTP 400 back from the resour= ce >>>>>> server it tries to access on behalf of the end user/resource owner, = can >>>>>> decide that the refresh token it has can now be used to get a new ac= cess >>>>>> token. >>>>>>> >>>>>>> [1] refers to various error conditions but it is not obvious to me >>>>>> that the same conditions (some of them) should or can be reported du= ring >>>>>> the actual client accessing the protected resource. >>>>>>> >>>>>>> My question is, what error condition, if any, from [1] should be >>>>>> reported back to the client failing to access a protected resource d= ue >>>>>> to the access token being invalid or expired, so that it can help th= e >>>>>> client who also owns the refresh token to decide it can use it now..= . >>>>>>> >>>>>>> Thanks, Sergey >>>>>>> >>>>>>> [1] http://tools.ietf.org/html/rfc6749#section-5.2 >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 From wmills_92105@yahoo.com Tue Nov 27 09:32:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815A621F85B4 for ; Tue, 27 Nov 2012 09:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFq38WCnPc2J for ; Tue, 27 Nov 2012 09:32:51 -0800 (PST) Received: from nm39-vm0.bullet.mail.bf1.yahoo.com (nm39-vm0.bullet.mail.bf1.yahoo.com [72.30.239.144]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1B921F8604 for ; Tue, 27 Nov 2012 09:32:51 -0800 (PST) Received: from [98.139.212.153] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 27 Nov 2012 17:32:50 -0000 Received: from [98.139.212.234] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 27 Nov 2012 17:32:50 -0000 Received: from [127.0.0.1] by omp1043.mail.bf1.yahoo.com with NNFMP; 27 Nov 2012 17:32:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 625797.20303.bm@omp1043.mail.bf1.yahoo.com Received: (qmail 40002 invoked by uid 60001); 27 Nov 2012 17:32:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354037569; bh=dZF9ezqZwe4kic9WTa9cb6MyIortBzjA4B3ZkErbbRg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=g9g0c6pSaJKok4/DLkUOP0PBWONSinUh2Jrjy0zxwUytjLs7WoMO07y+5khouy3h6xcHPAO+aX101DgX1SQqWNM95qKOneNru+o4YU/qT1kbW+ockZfDk8mRjoUUe68uwOHsVCtmMira+AiUTRe84Xllu+deQYB0NF2MlVs+I5I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VMh91YuTG/k7e346GLmjpTt2PSzXhnMNtEv2Qj0E9CuEiOjXGsWe/W9c+uOz6nyEaiEgp6AgcSDFnCwXoBJKCOrmvjbVSTUBu8BkKeqiMqv/PNQDlTV/7QDMeSGajDYsXYdPyoGfOjdH73AK5RM0XZ7ziM75WVeVRdA1i36eoPA=; X-YMail-OSG: CqsOomMVM1mNzkD7ayTmp86G5FOv4P8odByA2k5da7yr4uj 1lXfVfmPYF1ltWJfHL17pTkNNbmSnYvkgwfzS32CuNZ3GgfjFm7FCNWwle.I QYuMojvsaT5f2rX8UPU5D_LZdkVzvodnZM1SpIw_CVpRdzNHQ1d5JOWdvikK eKrGOCVcKu98ZWOrV49_IsMydrF.q41f66r.CJYqFtA1_l2ZVcIPXjjg0Uf3 KI6f23euMD0GQx9_0i_VlqvJHGNI6x7khrIoefFr_6gEO7Oi7XhIyiJmZstf sAZNNboZ_u9GWjdO6gvGTunQuEQcntQME8aoQKxXyEZGxnJNeOg_k7Y_sUGO 5gWzHM.xm89mXfibZHEvFJgA0RCBYaRSKubJ3OaxhubEC5j8raX6y38XG_mi o4ls23j74virzbDJNbjJnEqrvwj1ihxYYDDgI6XIYDAGOdHx9EThlMklWnQw 3ZSlYjO_jebxBNtP2eO9UGMRXOTF7kA0nw16PIE8R0O2Om047JcirqbfWE4q MK6wOPlnKRbXqvMdyWoMdjsw7K_5tFu3xo3_8qnrGZIA- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Tue, 27 Nov 2012 09:32:49 PST X-Rocket-MIMEInfo: 001.001, SSBkb24ndCBzZWUgaW4gdGhhdCBkb2N1bWVudCBhIHNpZ25pZmljYW50IHVzZSBjYXNlIGZvciBhIHNpZ25lZCB0b2tlbiwgd2hpY2ggaXMgdXNlIG92ZXIgY2xlYXIgdGV4dCBjaGFubmVscy4gwqBCZWFyZXIgdG9rZW5zIGhhdmUgc2ltaWxhciBzZWN1cml0eSBwcm9wZXJ0aWVzIHRvIEhUVFAgY29va2llcyAobWludXMgZm9yIHRoZSBtb21lbnQgdGhlIFhTUkYgcHJvYmxlbSkuIMKgU2lnbmVkIHRva2VuIHR5cGVzIGNhbiBiZSB1c2VkIG92ZXIgcGxhaW4gdGV4dCBjaGFubmVscyB3aXRob3V0IHRoZSBjb24BMAEBAQE- X-Mailer: YahooMailWebService/0.8.127.475 References: <50B3B1B3.50502@gmail.com><6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> <50B4A2AC.6010904@gmail.com> <999913AB42CC9341B05A99BBF358718D022492FA@FIESEXC035.nsn-intra.net> Message-ID: <1354037569.35121.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 27 Nov 2012 09:32:49 -0800 (PST) From: William Mills To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ext Sergey Beryozkin , Hannes Tschofenig In-Reply-To: <999913AB42CC9341B05A99BBF358718D022492FA@FIESEXC035.nsn-intra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-1923721861-1354037569=:35121" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 17:32:52 -0000 --767760015-1923721861-1354037569=:35121 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I don't see in that document a significant use case for a signed token, whi= ch is use over clear text channels. =A0Bearer tokens have similar security = properties to HTTP cookies (minus for the moment the XSRF problem). =A0Sign= ed token types can be used over plain text channels without the concern abo= ut re-use of the token by a 3rd party. =A0Replay protection is still needed= but that's not in scope for the token mechanism itself.=0A=0AIt's always b= een this simple use case that has been my focus for MAC.=0A=0AFlickr uses O= Auth 1.0a today over HTTP and will for many years to come, we won't be able= to go completely SSL due to the installed base of clients. =A0Given the dy= namic I see in the mobile development community I don't see us getting all = mobile apps into SSL only anytime soon. =A0MAC and OAuth 1.0 solve the toke= n security problem for the last hop to the phone/wi-fi device without SSL f= or the bulk of the application traffic.=0A=0A-bill=0A=0A=0A=0A_____________= ___________________=0A From: "Tschofenig, Hannes (NSN - FI/Espoo)" =0ATo: ext Sergey Beryozkin ; Hann= es Tschofenig =0ACc: oauth@ietf.org =0ASent: Tu= esday, November 27, 2012 4:33 AM=0ASubject: Re: [OAUTH-WG] What needs to be= done to complete MAC=0A =0AHi Sergey, =0A=0AI believe we would make faster= progress on security topics if could=0Afocus on listing security requireme= nts we have and what threats we want=0Ato mitigate. The reason why we have = not finished this topic is simply=0Abecause everyone was just talking about= specific (but incomplete)=0Asolutions. You are unfortunately falling in th= e same trap as well. =0A=0AIf you really care about the topic then have a l= ook at the mentioned=0Adocument and tell us whether the requirements are co= mplete. =0AReading through the document you will notice that there a few mo= re=0Aconsiderations to pay attention to than just the few listed below. =0A= =0ACiao=0AHannes=0A=0A=0A> -----Original Message-----=0A> From: oauth-bounc= es@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=0A> Of ext Sergey Ber= yozkin=0A> Sent: Tuesday, November 27, 2012 1:23 PM=0A> To: Hannes Tschofen= ig=0A> Cc: =0A> Subject: Re: [OAUTH-WG] What needs to be do= ne to complete MAC=0A> =0A> Hi Hannes=0A> On 26/11/12 19:01, Hannes Tschofe= nig wrote:=0A> > Hi Sergey,=0A> >=0A> > as Phil said it would be helpful fo= r us to receive reviews of this=0A> document:=0A> > http://tools.ietf.org/h= tml/draft-tschofenig-oauth-security-00=0A> >=0A> > The document lists requi= rements and threats.=0A> =0A> =0A> Let me offer two possibly naive reasons = why using MAC may help, one of=0A> them is related to the security, another= to the ease of HOK support on=0A> the client=0A> =0A> 1. The most safe way= to return MAC token to the client is to use a=0A> two-way TLS due to the m= ac key also returned to the client. Two-Way=0ATLS=0A> offers a stronger sup= port for getting the client authenticated along=0Athe=0A> way too=0A> =0A> = 2. Assuming HOK confirmation matters at all (and I believe it does),=0A> IM= HO it is much simpler for a basic client implementation to apply a=0AMAC=0A= > signature algo and thus work with the OAuth2 servers expecting HOK=0A> co= nfirmations=0A> =0A> One more reason is more about facilitating the further= migration to=0A2.0=0A> which I tried to outline in my response to Phil Hun= t=0A> =0A> Thanks, Sergey=0A> =0A> >=0A> > Ciao=0A> > Hannes=0A> >=0A> > On= Nov 26, 2012, at 8:28 PM, Phil Hunt wrote:=0A> >=0A> >> If we want to get = this done we have to get agreements on the=0A> requirements for HOK. Severa= l meetings ago (quebec) the group=0Aindicated=0A> that mac wasn't appropria= te to anyone's needs.=0A> >>=0A> >> Some would argue that OAuth1 users argu= ably have less security than=0A> the simpler bearer token /tls model in OAu= th2. This just shows the=0Areal=0A> issue of demonstrated need has not been= properly defined and=0Aunderstood.=0A> >>=0A> >> More dialog on use cases = is very helpful to moving HOK/MAC/etc=0A> forward.=0A> >>=0A> >> Phil=0A> >= >=0A> >> On 2012-11-26, at 10:15, Sergey Beryozkin=0A= > wrote:=0A> >>=0A> >>> Hi=0A> >>>=0A> >>> What needs to be done to complet= e the MAC token spec ? Without=0A> having it signed off it will be difficul= t to get people working with=0A> OAuth 1.0 convinced to move to 2.0.=0A> >>= > I'm seeing another user request for getting OAuth 1.0 support=0A> extende= d further because the user expects it is more secure, and I=0Aguess=0A> bec= ause it is proven to work for people, and I guess because many=0AOAuth=0A> = 1.0 users feel that should stay from OAuth 2.0 because of some bad=0Apress.= =0A> >>>=0A> >>> Without MAC being completed the division will continue, wi= th even=0A> more misleading anti-OAuth2 posts appearing (though I guess som= e of=0Athe=0A> better posts point to some level of complexity in 2.0).=0A> = >>>=0A> >>> Is it a matter of a security expert validating the text, fixing= =0Afew=0A> typos, and basically signing it off ?=0A> >>>=0A> >>> If someone= is interested then I can provide the info offline on=0Ahow=0A> it MAC supp= orted in our framework to get things tested easily and=0Asuch...=0A> >>>=0A= > >>> Cheers, Sergey=0A> >>>=0A> >>> ______________________________________= _________=0A> >>> OAuth mailing list=0A> >>> OAuth@ietf.org=0A> >>> https:/= /www.ietf.org/mailman/listinfo/oauth=0A> >> _______________________________= ________________=0A> >> OAuth mailing list=0A> >> OAuth@ietf.org=0A> >> htt= ps://www.ietf.org/mailman/listinfo/oauth=0A> >=0A> =0A> ___________________= ____________________________=0A> OAuth mailing list=0A> OAuth@ietf.org=0A> = https://www.ietf.org/mailman/listinfo/oauth=0A_____________________________= __________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf= .org/mailman/listinfo/oauth --767760015-1923721861-1354037569=:35121 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I don't see in that document a significant use case for a signed token, w= hich is use over clear text channels.  Bearer tokens have similar secu= rity properties to HTTP cookies (minus for the moment the XSRF problem). &n= bsp;Signed token types can be used over plain text channels without the con= cern about re-use of the token by a 3rd party.  Replay protection is s= till needed but that's not in scope for the token mechanism itself.<= /div>

It's always been this simple use case that has been my focu= s for MAC.

-bill


From: "Tschofenig, Hannes (NSN - FI/Espoo)" &l= t;hannes.tschofenig@nsn.com>
T= o: ext Sergey Beryozkin <sberyozkin@gmail.com>; Hannes Tsc= hofenig <hannes.tschofenig@gmx.net>
Cc: oauth@ietf.org
Sent: Tuesday, November 27, 2012 4:33 AM
Subject: Re: [OAUTH-WG] What needs to b= e done to complete MAC

=0AHi Sergey,

I belie= ve we would make faster progress on security topics if could
focus on li= sting security requirements we have and what threats we want
to mitigate= . The reason why we have not finished this topic is simply
because every= one was just talking about specific (but incomplete)
solutions. You are = unfortunately falling in the same trap as well.

If you really care = about the topic then have a look at the mentioned
document and tell us w= hether the requirements are complete.
Reading through the document you = will notice that there a few more
considerations to pay attention to tha= n just the few listed below.

Ciao
Hannes


> -----Or= iginal Message-----
> From: oauth-bounces@ietf.org [mail= to:oauth-bounces@ietf.org] On Behalf
> Of ext Sergey Beryozkin
> Sent: Tuesday, November 27,= 2012 1:23 PM
> To: Hannes Tschofenig
> Cc: <oauth@ietf.org>=
> Subject: Re: [OAUTH-WG] What needs to be done to complete MAC
&= gt;
> Hi Hannes
> On 26/11/12 19:01, Hannes Tschofenig wrote:<= br>> > Hi Sergey,
> >
> > as Phil said it would be = helpful for us to receive reviews of this
> document:
> > ht= tp://tools.ietf.org/html/draft-tschofenig-oauth-security-00
> >> > The document lists requirements and threats.
>
> > Let me offer two possibly naive reasons why using MAC may help, one = of
> them is related to the security, another to the ease of HOK supp= ort on
> the client
>
> 1. The most safe way to return M= AC token to the client is to use a
> two-way TLS due to the mac key also returned to the client. Two-Way
TLS
> offers a stronger = support for getting the client authenticated along
the
> way too>
> 2. Assuming HOK confirmation matters at all (and I believe = it does),
> IMHO it is much simpler for a basic client implementation= to apply a
MAC
> signature algo and thus work with the OAuth2 ser= vers expecting HOK
> confirmations
>
> One more reason i= s more about facilitating the further migration to
2.0
> which I t= ried to outline in my response to Phil Hunt
>
> Thanks, Sergey=
>
> >
> > Ciao
> > Hannes
> >> > On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote:
> >
&= gt; >> If we want to get this done we have to get agreements on the> requirements for HOK. Several meetings ago (quebec) the group
ind= icated
> that mac wasn't appropriate to anyone's needs.
> >>
> >> Some would argue that OAuth1 user= s arguably have less security than
> the simpler bearer token /tls mo= del in OAuth2. This just shows the
real
> issue of demonstrated ne= ed has not been properly defined and
understood.
> >>
>= ; >> More dialog on use cases is very helpful to moving HOK/MAC/etc> forward.
> >>
> >> Phil
> >>
= > >> On 2012-11-26, at 10:15, Sergey Beryozkin<sberyozkin@= gmail.com>
> wrote:
> >>
> >>> Hi> >>>
> >>> What needs to be done to complete = the MAC token spec ? Without
> having it signed off it will be diffic= ult to get people working with
> OAuth 1.0 convinced to move to 2.0.<= br>> >>> I'm seeing another user request for getting OAuth 1.0 support
> extended further because the user expects it is more s= ecure, and I
guess
> because it is proven to work for people, and = I guess because many
OAuth
> 1.0 users feel that should stay from = OAuth 2.0 because of some bad
press.
> >>>
> >&g= t;> Without MAC being completed the division will continue, with even> more misleading anti-OAuth2 posts appearing (though I guess some ofthe
> better posts point to some level of complexity in 2.0).
&g= t; >>>
> >>> Is it a matter of a security expert va= lidating the text, fixing
few
> typos, and basically signing it of= f ?
> >>>
> >>> If someone is interested then= I can provide the info offline on
how
> it MAC supported in our f= ramework to get things tested easily and
such...
> >>>> >>> Cheers, Sergey
> >>>
> >>> _______________________________________________
> >&= gt;> OAuth mailing list
> >>> OAuth@ietf.org
> >>= ;> https://www.ietf.org/mailman/listinfo/oauth
> >> _____= __________________________________________
> >> OAuth mailing l= ist
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailm= an/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


<= /div>
--767760015-1923721861-1354037569=:35121-- From jricher@mitre.org Tue Nov 27 09:51:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A660421F847F for ; Tue, 27 Nov 2012 09:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD7l1D0EzmDi for ; Tue, 27 Nov 2012 09:51:18 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1C57921F8668 for ; Tue, 27 Nov 2012 09:51:18 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 93AAF53102DD; Tue, 27 Nov 2012 12:51:17 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 775C153102E0; Tue, 27 Nov 2012 12:51:17 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.132]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Tue, 27 Nov 2012 12:51:16 -0500 From: "Richer, Justin P." To: William Mills Thread-Topic: [OAUTH-WG] What needs to be done to complete MAC Thread-Index: AQHNzMU+V03kKZmxukeglq50mf1jYZf+SfiA Date: Tue, 27 Nov 2012 17:51:17 +0000 Message-ID: References: <50B3B1B3.50502@gmail.com><6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> <50B4A2AC.6010904@gmail.com> <999913AB42CC9341B05A99BBF358718D022492FA@FIESEXC035.nsn-intra.net> <1354037569.35121.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1354037569.35121.YahooMailNeo@web31813.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.43.53] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E0684F230IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 17:51:19 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E0684F230IMCMBX01MITREOR_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An important point to note, that many OAuth1 implementations in the wild sc= rew up, is that you still need TLS between the client and the Authorization= Server to protect the token and secret in transit, even if you don't use T= LS during the client's calls to the protected resource. Since OAuth2 core m= andates TLS at the Token Endpoint explicitly for all token types, that's mu= ch more clear to understand (in my opinion) in implementation. In case the above is unclear, what I'm trying to say is this: putting a sig= ned token like MAC into the OAuth2 framework will give us the capability of= OAuth1 in a clearer, more secure (in the wild) structure. I think it's vit= ally important that we have this functionality, and while I understand the = need for clear use cases, I don't understand the feet-dragging. -- Justin On Nov 27, 2012, at 12:32 PM, William Mills wrote: I don't see in that document a significant use case for a signed token, whi= ch is use over clear text channels. Bearer tokens have similar security pr= operties to HTTP cookies (minus for the moment the XSRF problem). Signed t= oken types can be used over plain text channels without the concern about r= e-use of the token by a 3rd party. Replay protection is still needed but t= hat's not in scope for the token mechanism itself. It's always been this simple use case that has been my focus for MAC. Flickr uses OAuth 1.0a today over HTTP and will for many years to come, we = won't be able to go completely SSL due to the installed base of clients. G= iven the dynamic I see in the mobile development community I don't see us g= etting all mobile apps into SSL only anytime soon. MAC and OAuth 1.0 solve= the token security problem for the last hop to the phone/wi-fi device with= out SSL for the bulk of the application traffic. -bill ________________________________ From: "Tschofenig, Hannes (NSN - FI/Espoo)" > To: ext Sergey Beryozkin = >; Hannes Tschofenig > Cc: oauth@ietf.org Sent: Tuesday, November 27, 2012 4:33 AM Subject: Re: [OAUTH-WG] What needs to be done to complete MAC Hi Sergey, I believe we would make faster progress on security topics if could focus on listing security requirements we have and what threats we want to mitigate. The reason why we have not finished this topic is simply because everyone was just talking about specific (but incomplete) solutions. You are unfortunately falling in the same trap as well. If you really care about the topic then have a look at the mentioned document and tell us whether the requirements are complete. Reading through the document you will notice that there a few more considerations to pay attention to than just the few listed below. Ciao Hannes > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of ext Sergey Beryozkin > Sent: Tuesday, November 27, 2012 1:23 PM > To: Hannes Tschofenig > Cc: > > Subject: Re: [OAUTH-WG] What needs to be done to complete MAC > > Hi Hannes > On 26/11/12 19:01, Hannes Tschofenig wrote: > > Hi Sergey, > > > > as Phil said it would be helpful for us to receive reviews of this > document: > > http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 > > > > The document lists requirements and threats. > > > Let me offer two possibly naive reasons why using MAC may help, one of > them is related to the security, another to the ease of HOK support on > the client > > 1. The most safe way to return MAC token to the client is to use a > two-way TLS due to the mac key also returned to the client. Two-Way TLS > offers a stronger support for getting the client authenticated along the > way too > > 2. Assuming HOK confirmation matters at all (and I believe it does), > IMHO it is much simpler for a basic client implementation to apply a MAC > signature algo and thus work with the OAuth2 servers expecting HOK > confirmations > > One more reason is more about facilitating the further migration to 2.0 > which I tried to outline in my response to Phil Hunt > > Thanks, Sergey > > > > > Ciao > > Hannes > > > > On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote: > > > >> If we want to get this done we have to get agreements on the > requirements for HOK. Several meetings ago (quebec) the group indicated > that mac wasn't appropriate to anyone's needs. > >> > >> Some would argue that OAuth1 users arguably have less security than > the simpler bearer token /tls model in OAuth2. This just shows the real > issue of demonstrated need has not been properly defined and understood. > >> > >> More dialog on use cases is very helpful to moving HOK/MAC/etc > forward. > >> > >> Phil > >> > >> On 2012-11-26, at 10:15, Sergey Beryozkin> > wrote: > >> > >>> Hi > >>> > >>> What needs to be done to complete the MAC token spec ? Without > having it signed off it will be difficult to get people working with > OAuth 1.0 convinced to move to 2.0. > >>> I'm seeing another user request for getting OAuth 1.0 support > extended further because the user expects it is more secure, and I guess > because it is proven to work for people, and I guess because many OAuth > 1.0 users feel that should stay from OAuth 2.0 because of some bad press. > >>> > >>> Without MAC being completed the division will continue, with even > more misleading anti-OAuth2 posts appearing (though I guess some of the > better posts point to some level of complexity in 2.0). > >>> > >>> Is it a matter of a security expert validating the text, fixing few > typos, and basically signing it off ? > >>> > >>> If someone is interested then I can provide the info offline on how > it MAC supported in our framework to get things tested easily and such... > >>> > >>> Cheers, Sergey > >>> > >>> _______________________________________________ > >>> 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 _______________________________________________ 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 --_000_B33BFB58CCC8BE4998958016839DE27E0684F230IMCMBX01MITREOR_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable An important point to note, that many OAuth1 implementations in the wild sc= rew up, is that you still need TLS between the client and the Authorization= Server to protect the token and secret in transit, even if you don't use T= LS during the client's calls to the protected resource. Since OAuth2 core mandates TLS at the Token Endpoi= nt explicitly for all token types, that's much more clear to understand (in= my opinion) in implementation.

In case the above is unclear, what I'm trying to say is this: putting = a signed token like MAC into the OAuth2 framework will give us the capabili= ty of OAuth1 in a clearer, more secure (in the wild) structure. I think it'= s vitally important that we have this functionality, and while I understand the need for clear use cases, I= don't understand the feet-dragging.

 -- Justin

On Nov 27, 2012, at 12:32 PM, William Mills wrote:

I don't see in that document a significant use case for a signed= token, which is use over clear text channels.  Bearer tokens have sim= ilar security properties to HTTP cookies (minus for the moment the XSRF pro= blem).  Signed token types can be used over plain text channels without the concern about re-use of the token by = a 3rd party.  Replay protection is still needed but that's not in scop= e for the token mechanism itself.

It's always been this simple use case that has been my focus for MAC.=

Flickr uses OAuth 1.0a today over HTTP and will for many years to com= e, we won't be able to go completely SSL due to the installed base of clien= ts.  Given the dynamic I see in the mobile development community I don= 't see us getting all mobile apps into SSL only anytime soon.  MAC and OAuth 1.0 solve the token security pr= oblem for the last hop to the phone/wi-fi device without SSL for the bulk o= f the application traffic.

-bill


From: "Tschofenig, Han= nes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: ext Sergey Beryozkin &= lt;sberyozkin@gmail.com>; Ha= nnes Tschofenig <hannes.tsc= hofenig@gmx.net>
Cc: oauth@ietf.org
Sent: Tuesday, November 27= , 2012 4:33 AM
Subject: Re: [OAUTH-WG] Wh= at needs to be done to complete MAC

Hi Sergey,

I believe we would make faster progress on security topics if could
focus on listing security requirements we have and what threats we want
to mitigate. The reason why we have not finished this topic is simply
because everyone was just talking about specific (but incomplete)
solutions. You are unfortunately falling in the same trap as well.

If you really care about the topic then have a look at the mentioned
document and tell us whether the requirements are complete.
Reading through the document you will notice that there a few more
considerations to pay attention to than just the few listed below.

Ciao
Hannes


> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf
> Of ext Sergey Beryozkin
> Sent: Tuesday, November 27, 2012 1:23 PM
> To: Hannes Tschofenig
> Cc: <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] What needs to be done to complete MAC
>
> Hi Hannes
> On 26/11/12 19:01, Hannes Tschofenig wrote:
> > Hi Sergey,
> >
> > as Phil said it would be helpful for us to receive reviews of thi= s
> document:
> > http://tools.ietf.org/html/draft-tschofenig-oauth-security-00<= br> > >
> > The document lists requirements and threats.
>
>
> Let me offer two possibly naive reasons why using MAC may help, one of=
> them is related to the security, another to the ease of HOK support on=
> the client
>
> 1. The most safe way to return MAC token to the client is to use a
> two-way TLS due to the mac key also returned to the client. Two-Way TLS
> offers a stronger support for getting the client authenticated along the
> way too
>
> 2. Assuming HOK confirmation matters at all (and I believe it does), > IMHO it is much simpler for a basic client implementation to apply a MAC
> signature algo and thus work with the OAuth2 servers expecting HOK
> confirmations
>
> One more reason is more about facilitating the further migration to 2.0
> which I tried to outline in my response to Phil Hunt
>
> Thanks, Sergey
>
> >
> > Ciao
> > Hannes
> >
> > On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote:
> >
> >> If we want to get this done we have to get agreements on the<= br> > requirements for HOK. Several meetings ago (quebec) the group
indicated
> that mac wasn't appropriate to anyone's needs.
> >>
> >> Some would argue that OAuth1 users arguably have less securit= y than
> the simpler bearer token /tls model in OAuth2. This just shows the
real
> issue of demonstrated need has not been properly defined and
understood.
> >>
> >> More dialog on use cases is very helpful to moving HOK/MAC/et= c
> forward.
> >>
> >> Phil
> >>
> >> On 2012-11-26, at 10:15, Sergey Beryozkin<sberyozkin@= gmail.com>
> wrote:
> >>
> >>> Hi
> >>>
> >>> What needs to be done to complete the MAC token spec ? Wi= thout
> having it signed off it will be difficult to get people working with > OAuth 1.0 convinced to move to 2.0.
> >>> I'm seeing another user request for getting OAuth 1.0 sup= port
> extended further because the user expects it is more secure, and I
guess
> because it is proven to work for people, and I guess because many
OAuth
> 1.0 users feel that should stay from OAuth 2.0 because of some bad
press.
> >>>
> >>> Without MAC being completed the division will continue, w= ith even
> more misleading anti-OAuth2 posts appearing (though I guess some of the
> better posts point to some level of complexity in 2.0).
> >>>
> >>> Is it a matter of a security expert validating the text, = fixing
few
> typos, and basically signing it off ?
> >>>
> >>> If someone is interested then I can provide the info offl= ine on
how
> it MAC supported in our framework to get things tested easily and
such...
> >>>
> >>> Cheers, Sergey
> >>>
> >>> _______________________________________________
> >>> 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
> OA= uth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@i= etf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_B33BFB58CCC8BE4998958016839DE27E0684F230IMCMBX01MITREOR_-- From wmills_92105@yahoo.com Tue Nov 27 09:59:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D89A21F8671 for ; Tue, 27 Nov 2012 09:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HF09EPUtWxKx for ; Tue, 27 Nov 2012 09:59:26 -0800 (PST) Received: from nm38-vm4.bullet.mail.bf1.yahoo.com (nm38-vm4.bullet.mail.bf1.yahoo.com [72.30.239.20]) by ietfa.amsl.com (Postfix) with ESMTP id E74EC21F8563 for ; Tue, 27 Nov 2012 09:59:25 -0800 (PST) Received: from [98.139.212.153] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 27 Nov 2012 17:59:17 -0000 Received: from [98.139.212.246] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 27 Nov 2012 17:59:17 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 27 Nov 2012 17:59:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 615174.75997.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 3133 invoked by uid 60001); 27 Nov 2012 17:59:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354039157; bh=/JywEhq7MbfmvKf7zLxN8atssdFuVOnoZzgbLiZoJA4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HPB/tRiWo50IpuRCOSg4b1z036ZbJuoUhLaYDv/F++jgz4KE+EajUarp8vhPsydchMlgzg5yNYJMgbyB916fmS9cH9AHzyRvENDpgOZC5MdY1mCBAD5syVAnyyIVXQOZL+jXW5+Jb09FRlEZg96BpgMVtZxlgFN/lC0u10aoNCw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rbIiGeEYmqF87sGrfMYHs8VihaMYo7oEm9jkzCPX6ws7ZHGe9yCYzXnUUoSk+LvIdZWEPKTwxAhwUtseMZ3YeQiZpGuM/9Oso4VqhupT0Oov1NjZ7fZZTkhtcWigwf0SK5RkuauOS2hvPf9pxHL5T7PzKam3iLVImWtRgpOzyWM=; X-YMail-OSG: LvGGBeEVM1mS3LjI6HolUx_lI_URFFYU_Td0jRLR7RXNxUJ D5nSO7Rsq1GKCx_eMz2O4nhmqPUJ_tO4z1MOi69RwVXW2_Om71p4kRvzanIU n1vSXVJJMWAMgAbt2nXYJy5tzBcWfLN.qGie_J12tQ4SpJuDYlhsNo5yWOCK DtG5.dXDZtp3lpHn2bpOfdhTmHFobuBNImwcPbZC1h_AAAwoE9Fnei2AG3xF 7dHYiXF_ZiN5ZPZnJFKmBa.r9b_UG8s6a7G8QC_pfEo4STzuiMBvg6ZNYFk_ iSRID5r6VxdrsLFa3HxAU0u2ocuoQshY6vLl6TEsuec9CkxsljlIcM8ROyQ5 LJcaRZ0bDt9kb2tX__LhCOH_u0iSnhKg0KC9J3DgbbdwckDkIvIrYeAofuSI 7WhIm4m5C_7vX2pKGVhXQkuO8Z9xozvfH6iU4vYYG1BJn.idqXMCFMiUDRmw d5HOvrBVuuCz8WQNzpJhunu2c7d3k6UXxY2ZZX4RTEmvbzWExms43NeSkRCh sbTKmI.5EkYpruj76SVGrZRfgUrJfT9VI6SX2kgEw2UDDOmb5yXnXX_RQ7.p K Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Tue, 27 Nov 2012 09:59:16 PST X-Rocket-MIMEInfo: 001.001, WWVzIQoKVGhlIG90aGVyIHRoaW5nIHRoYXQgaXMgYmV0dGVyIGluIHRoZSBPQXV0aCAyIG1vZGVsIGlzIHRoZSByZWZyZXNoIGNhcGFiaWxpdHksIHdoaWNoIG1ha2VzIHBsYWluIHRleHQgY2hhbm5lbCB0b2tlbiB1c2FnZSBtb3JlIHBhbGF0YWJsZS4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogIlJpY2hlciwgSnVzdGluIFAuIiA8anJpY2hlckBtaXRyZS5vcmc.ClRvOiBXaWxsaWFtIE1pbGxzIDx3bWlsbHNfOTIxMDVAeWFob28uY29tPiAKQ2M6ICJUc2Nob2ZlbmlnLCBIYW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.127.475 References: <50B3B1B3.50502@gmail.com><6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> <50B4A2AC.6010904@gmail.com> <999913AB42CC9341B05A99BBF358718D022492FA@FIESEXC035.nsn-intra.net> <1354037569.35121.YahooMailNeo@web31813.mail.mud.yahoo.com> Message-ID: <1354039156.86802.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 27 Nov 2012 09:59:16 -0800 (PST) From: William Mills To: "Richer, Justin P." In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-782312965-1354039156=:86802" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 17:59:27 -0000 --258328648-782312965-1354039156=:86802 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yes!=0A=0AThe other thing that is better in the OAuth 2 model is the refres= h capability, which makes plain text channel token usage more palatable.=0A= =0A=0A________________________________=0A From: "Richer, Justin P." =0ATo: William Mills =0ACc: "Tschofeni= g, Hannes (NSN - FI/Espoo)" ; ext Sergey Beryozk= in ; Hannes Tschofenig ; "= oauth@ietf.org" =0ASent: Tuesday, November 27, 2012 9:51 A= M=0ASubject: Re: [OAUTH-WG] What needs to be done to complete MAC=0A =0A=0A= An important point to note, that many OAuth1 implementations in the wild sc= rew up, is that you still need TLS between the client and the Authorization= Server to protect the token and secret in transit, even if you don't use T= LS during the client's calls to the protected resource. Since OAuth2 core m= andates TLS at the Token Endpoint explicitly for all token types, that's mu= ch more clear to understand (in my opinion) in implementation. =0A=0AIn cas= e the above is unclear, what I'm trying to say is this: putting a signed to= ken like MAC into the OAuth2 framework will give us the capability of OAuth= 1 in a clearer, more secure (in the wild) structure. I think it's vitally i= mportant that we have this functionality, and while I understand the need f= or clear use cases, I don't understand the feet-dragging.=0A=0A=A0-- Justin= =0A=0A=0A=0AOn Nov 27, 2012, at 12:32 PM, William Mills wrote:=0A=0AI don't= see in that document a significant use case for a signed token, which is u= se over clear text channels. =A0Bearer tokens have similar security propert= ies to HTTP cookies (minus for the moment the XSRF problem). =A0Signed toke= n types can be used over plain text channels without the concern about re-u= se of the token by a 3rd party. =A0Replay protection is still needed but th= at's not in scope for the token mechanism itself.=0A>=0A>=0A>It's always be= en this simple use case that has been my focus for MAC.=0A>=0A>=0A>Flickr u= ses OAuth 1.0a today over HTTP and will for many years to come, we won't be= able to go completely SSL due to the installed base of clients. =A0Given t= he dynamic I see in the mobile development community I don't see us getting= all mobile apps into SSL only anytime soon. =A0MAC and OAuth 1.0 solve the= token security problem for the last hop to the phone/wi-fi device without = SSL for the bulk of the application traffic.=0A>=0A>=0A>-bill=0A>=0A>=0A>= =0A>=0A>=0A>________________________________=0A> From: "Tschofenig, Hannes = (NSN - FI/Espoo)" =0A>To: ext Sergey Beryozkin <= sberyozkin@gmail.com>; Hannes Tschofenig =0A>Cc= : oauth@ietf.org =0A>Sent: Tuesday, November 27, 2012 4:33 AM=0A>Subject: R= e: [OAUTH-WG] What needs to be done to complete MAC=0A>=0A>Hi Sergey, =0A>= =0A>I believe we would make faster progress on security topics if could=0A>= focus on listing security requirements we have and what threats we want=0A>= to mitigate. The reason why we have not finished this topic is simply=0A>be= cause everyone was just talking about specific (but incomplete)=0A>solution= s. You are unfortunately falling in the same trap as well. =0A>=0A>If you r= eally care about the topic then have a look at the mentioned=0A>document an= d tell us whether the requirements are complete. =0A>Reading through the do= cument you will notice that there a few more=0A>considerations to pay atten= tion to than just the few listed below. =0A>=0A>Ciao=0A>Hannes=0A>=0A>=0A>>= -----Original Message-----=0A>> From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf=0A>> Of ext Sergey Beryozkin=0A>> Sent: Tuesda= y, November 27, 2012 1:23 PM=0A>> To: Hannes Tschofenig=0A>> Cc: =0A>> Subject: Re: [OAUTH-WG] What needs to be done to complete MAC= =0A>> =0A>> Hi Hannes=0A>> On 26/11/12 19:01, Hannes Tschofenig wrote:=0A>>= > Hi Sergey,=0A>> >=0A>> > as Phil said it would be helpful for us to rece= ive reviews of this=0A>> document:=0A>> > http://tools.ietf.org/html/draft-= tschofenig-oauth-security-00=0A>> >=0A>> > The document lists requirements = and threats.=0A>> =0A>> =0A>> Let me offer two possibly naive reasons why u= sing MAC may help, one of=0A>> them is related to the security, another to = the ease of HOK support on=0A>> the client=0A>> =0A>> 1. The most safe way = to return MAC token to the client is to use a=0A>> two-way TLS due to the m= ac key also returned to the client. Two-Way=0A>TLS=0A>> offers a stronger s= upport for getting the client authenticated along=0A>the=0A>> way too=0A>> = =0A>> 2. Assuming HOK confirmation matters at all (and I believe it does),= =0A>> IMHO it is much simpler for a basic client implementation to apply a= =0A>MAC=0A>> signature algo and thus work with the OAuth2 servers expecting= HOK=0A>> confirmations=0A>> =0A>> One more reason is more about facilitati= ng the further migration to=0A>2.0=0A>> which I tried to outline in my resp= onse to Phil Hunt=0A>> =0A>> Thanks, Sergey=0A>> =0A>> >=0A>> > Ciao=0A>> >= Hannes=0A>> >=0A>> > On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote:=0A>> >= =0A>> >> If we want to get this done we have to get agreements on the=0A>> = requirements for HOK. Several meetings ago (quebec) the group=0A>indicated= =0A>> that mac wasn't appropriate to anyone's needs.=0A>> >>=0A>> >> Some w= ould argue that OAuth1 users arguably have less security than=0A>> the simp= ler bearer token /tls model in OAuth2. This just shows the=0A>real=0A>> iss= ue of demonstrated need has not been properly defined and=0A>understood.=0A= >> >>=0A>> >> More dialog on use cases is very helpful to moving HOK/MAC/et= c=0A>> forward.=0A>> >>=0A>> >> Phil=0A>> >>=0A>> >> On 2012-11-26, at 10:1= 5, Sergey Beryozkin=0A>> wrote:=0A>> >>=0A>> >>> Hi= =0A>> >>>=0A>> >>> What needs to be done to complete the MAC token spec ? W= ithout=0A>> having it signed off it will be difficult to get people working= with=0A>> OAuth 1.0 convinced to move to 2.0.=0A>> >>> I'm seeing another = user request for getting OAuth 1.0 support=0A>> extended further because th= e user expects it is more secure, and I=0A>guess=0A>> because it is proven = to work for people, and I guess because many=0A>OAuth=0A>> 1.0 users feel t= hat should stay from OAuth 2.0 because of some bad=0A>press.=0A>> >>>=0A>> = >>> Without MAC being completed the division will continue, with even=0A>> = more misleading anti-OAuth2 posts appearing (though I guess some of=0A>the= =0A>> better posts point to some level of complexity in 2.0).=0A>> >>>=0A>>= >>> Is it a matter of a security expert validating the text, fixing=0A>few= =0A>> typos, and basically signing it off ?=0A>> >>>=0A>> >>> If someone is= interested then I can provide the info offline on=0A>how=0A>> it MAC suppo= rted in our framework to get things tested easily and=0A>such...=0A>> >>>= =0A>> >>> Cheers, Sergey=0A>> >>>=0A>> >>> ________________________________= _______________=0A>> >>> OAuth mailing list=0A>> >>> OAuth@ietf.org=0A>> >>= > https://www.ietf.org/mailman/listinfo/oauth=0A>> >> _____________________= __________________________=0A>> >> OAuth mailing list=0A>> >> OAuth@ietf.or= g=0A>> >> https://www.ietf.org/mailman/listinfo/oauth=0A>> >=0A>> =0A>> ___= ____________________________________________=0A>> OAuth mailing list=0A>> O= Auth@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/oauth=0A>_________= ______________________________________=0A>OAuth mailing list=0A>OAuth@ietf.= org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A>=0A__________= _____________________________________=0A>OAuth mailing list=0A>OAuth@ietf.o= rg=0A>https://www.ietf.org/mailman/listinfo/oauth=0A> --258328648-782312965-1354039156=:86802 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yes!=

The other thing that is better i= n the OAuth 2 model is the refresh capability, which makes plain text chann= el token usage more palatable.

From: "Richer,= Justin P." <jricher@mitre.org>
To: William Mills <wmills_92105@yahoo.com>
Cc: "Tschofenig, Hannes (NSN - FI/= Espoo)" <hannes.tschofenig@nsn.com>; ext Sergey Beryozkin <sberyoz= kin@gmail.com>; Hannes Tschofenig <hannes.tschofenig@gmx.net>; "oa= uth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, November 27, 2012 9:51 AM
Subject: Re: [OAUTH-WG] What needs to be= done to complete MAC

=0A
= =0A=0A =0A=0A
=0AAn important point to note, that many OAuth1 implement= ations in the wild screw up, is that you still need TLS between the client = and the Authorization Server to protect the token and secret in transit, ev= en if you don't use TLS during the client's calls to=0A the protected resou= rce. Since OAuth2 core mandates TLS at the Token Endpoint explicitly for al= l token types, that's much more clear to understand (in my opinion) in impl= ementation.=0A

=0A
=0A
In case the above is unclear, what = I'm trying to say is this: putting a signed token like MAC into the OAuth2 = framework will give us the capability of OAuth1 in a clearer, more secure (= in the wild) structure. I think it's vitally important that we have=0A this= functionality, and while I understand the need for clear use cases, I don'= t understand the feet-dragging.
=0A

=0A
=0A
 -- = Justin
=0A

=0A
=0A
On Nov 27, 2012, at 12:32 PM, William= Mills wrote:
=0A
= =0A
=0A
=0A
=0A
I don't see = in that document a significant use case for a signed token, which is use ov= er clear text channels.  Bearer tokens have similar security propertie= s to HTTP cookies (minus for the moment the XSRF problem).  Signed tok= en types can be used=0A over plain text channels without the concern about = re-use of the token by a 3rd party.  Replay protection is still needed= but that's not in scope for the token mechanism itself.
=0A=0A
=0A
=0A
= =0AIt's always been this simple use case that has been my focus for M= AC.
=0A
=0A
=0A
=0A
=0AFlickr uses OAuth 1.0a today over HTTP and will for many ye= ars to come, we won't be able to go completely SSL due to the installed bas= e of clients.  Given the dynamic I see in the mobile development commu= nity I don't see us getting all mobile apps into=0A SSL only anytime soon. =  MAC and OAuth 1.0 solve the token security problem for the last hop t= o the phone/wi-fi device without SSL for the bulk of the application traffi= c.
=0A

=0A
=0A
=0A
-bill
=0A

=0A<= /div>=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0AFrom: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
=0ATo: ext Sergey Beryozkin <sberyozkin@gmail.com>; Hannes Tschofenig= <hannes.tschofenig@gm= x.net>=0A
=0ACc: =0Aoauth@ietf.org
=0ASent: Tuesday, November 27, 2012 4:33 AM<= br>=0ASubject: Re: [OAUTH-W= G] What needs to be done to complete MAC
=0A
=0A
=0AHi Se= rgey,
=0A
=0AI believe we would make faster progress on security top= ics if could
=0Afocus on listing security requirements we have and what = threats we want
=0Ato mitigate. The reason why we have not finished this= topic is simply
=0Abecause everyone was just talking about specific (bu= t incomplete)
=0Asolutions. You are unfortunately falling in the same tr= ap as well.
=0A
=0AIf you really care about the topic then have a lo= ok at the mentioned
=0Adocument and tell us whether the requirements are= complete.
=0AReading through the document you will notice that there a= few more
=0Aconsiderations to pay attention to than just the few listed= below.
=0A
=0ACiao
=0AHannes
=0A
=0A
=0A> -----Origi= nal Message-----
=0A> From: =0Aoauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
=0A> Of ext Sergey Be= ryozkin
=0A> Sent: Tuesday, November 27, 2012 1:23 PM
=0A> To: = Hannes Tschofenig
=0A> Cc: <oauth@ietf= .org>
=0A> Subject: Re: [OAUTH-WG] What needs to be done to co= mplete MAC
=0A>
=0A> Hi Hannes
=0A> On 26/11/12 19:01, H= annes Tschofenig wrote:
=0A> > Hi Sergey,
=0A> >
=0A&g= t; > as Phil said it would be helpful for us to receive reviews of this<= br>=0A> document:
=0A> > http://tools.ietf.org/html/draft-tscho= fenig-oauth-security-00
=0A> >
=0A> > The document lists = requirements and threats.
=0A>
=0A>
=0A> Let me offer t= wo possibly naive reasons why using MAC may help, one of
=0A> them is= related to the security, another to the ease of HOK support on
=0A> = the client
=0A>
=0A> 1. The most safe way to return MAC token = to the client is to use a
=0A> two-way TLS due to the mac key also re= turned to the client. Two-Way
=0ATLS
=0A> offers a stronger suppor= t for getting the client authenticated along
=0Athe
=0A> way too=0A>
=0A> 2. Assuming HOK confirmation matters at all (and I be= lieve it does),
=0A> IMHO it is much simpler for a basic client imple= mentation to apply a
=0AMAC
=0A> signature algo and thus work with= the OAuth2 servers expecting HOK
=0A> confirmations
=0A>
= =0A> One more reason is more about facilitating the further migration to=
=0A2.0
=0A> which I tried to outline in my response to Phil Hunt<= br>=0A>
=0A> Thanks, Sergey
=0A>
=0A> >
=0A>= ; > Ciao
=0A> > Hannes
=0A> >
=0A> > On Nov 2= 6, 2012, at 8:28 PM, Phil Hunt wrote:
=0A> >
=0A> >> I= f we want to get this done we have to get agreements on the
=0A> requ= irements for HOK. Several meetings ago (quebec) the group
=0Aindicated=0A> that mac wasn't appropriate to anyone's needs.
=0A> >>= ;
=0A> >> Some would argue that OAuth1 users arguably have less= security than
=0A> the simpler bearer token /tls model in OAuth2. Th= is just shows the
=0Areal
=0A> issue of demonstrated need has not = been properly defined and
=0Aunderstood.
=0A> >>
=0A> = >> More dialog on use cases is very helpful to moving HOK/MAC/etc
= =0A> forward.
=0A> >>
=0A> >> Phil
=0A> &g= t;>
=0A> >> On 2012-11-26, at 10:15, Sergey Beryozkin<sberyozkin@gmail.com>
=0A>= ; wrote:
=0A> >>
=0A> >>> Hi
=0A> >>= >
=0A> >>> What needs to be done to complete the MAC toke= n spec ? Without
=0A> having it signed off it will be difficult to ge= t people working with
=0A> OAuth 1.0 convinced to move to 2.0.
=0A= > >>> I'm seeing another user request for getting OAuth 1.0 sup= port
=0A> extended further because the user expects it is more secure= , and I
=0Aguess
=0A> because it is proven to work for people, and= I guess because many
=0AOAuth
=0A> 1.0 users feel that should sta= y from OAuth 2.0 because of some bad
=0Apress.
=0A> >>>=0A> >>> Without MAC being completed the division will contin= ue, with even
=0A> more misleading anti-OAuth2 posts appearing (thoug= h I guess some of
=0Athe
=0A> better posts point to some level of = complexity in 2.0).
=0A> >>>
=0A> >>> Is it a= matter of a security expert validating the text, fixing
=0Afew
=0A&g= t; typos, and basically signing it off ?
=0A> >>>
=0A>= >>> If someone is interested then I can provide the info offline = on
=0Ahow
=0A> it MAC supported in our framework to get things tes= ted easily and
=0Asuch...
=0A> >>>
=0A> >>>= ; Cheers, Sergey
=0A> >>>
=0A> >>> __________= _____________________________________
=0A> >>> OAuth mailing= list
=0A> >>> OAuth@ietf.org
=0A> >>> https://www.ietf.org/mailman/list= info/oauth
=0A> >> ________________________________________= _______
=0A> >> OAuth mailing list
=0A> >> OAuth@ietf.org
=0A> >> https://www.ietf.org/mailman/listinfo/oauth
=0A> >
=0A>= ;
=0A> _______________________________________________
=0A> OA= uth mailing list
=0A> OAuth@ietf.org<= br>=0A> https://www.ietf.org/mailman/listinfo/oauth<= br>=0A_______________________________________________
=0AOAuth mailing l= ist
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth
=0A
=0A
=0A=0A
=0A
=0A
=0A__________________________________________= _____
=0AOAuth mailing list
=0AOAuth@ietf= .org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth
=0A=0A
=0A
=0A
=0A
=0A
=0A=0A


<= /div>
--258328648-782312965-1354039156=:86802-- From sberyozkin@gmail.com Tue Nov 27 10:11:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B6221F85E6 for ; Tue, 27 Nov 2012 10:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLEwB99YQ7s4 for ; Tue, 27 Nov 2012 10:11:24 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 567EB21F85FF for ; Tue, 27 Nov 2012 10:11:11 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so6027352bku.31 for ; Tue, 27 Nov 2012 10:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=94ClnevmlAtHubLVqxrWg3IrLuClsy2e72A7Wm44z50=; b=OA55sZrRif+bEfx9KhxUpO35Oih5o5iQLYvEoxrDUzS+NFRlFaAhLsX3tBwwIrz8KE fX5EaKkTN4NCbtKJX6mUWKs6gkKcQBd6d/ikyl0g8l5gpL1KFiIn4KVnCbXZU2uwGdIQ JEBBui+SQ2lA5p8cLdGWX2/XtzrBfwmYW5RugCrsDeP2RXbaCaZcF8vLGKu7E874yNTn GgfeNIgk6yjZpeO9CeKZkJFsJIEbJOM+XPMnfG0Tdk+WzRMUjHTwSJDkJbW0rafC0Urq 6MPDu02wRAh+DCcXCB/pS4a6pQJYNBeImqcegN3n1TkrMSgigyl3Atxce8EhxFJte4mc Rpuw== Received: by 10.204.5.205 with SMTP id 13mr4974598bkw.111.1354039870429; Tue, 27 Nov 2012 10:11:10 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id gy18sm11023434bkc.4.2012.11.27.10.11.08 (version=SSLv3 cipher=OTHER); Tue, 27 Nov 2012 10:11:09 -0800 (PST) Message-ID: <50B5023B.3060208@gmail.com> Date: Tue, 27 Nov 2012 18:11:07 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Lewis Adam-CAL022 References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com>, <50ACFC53.5080103@gmail.com> <201211271652159646688@gmail.com> <50B4937C.5030201@gmail.com> <50B4DF1B.4030700@gmail.com> <50B4E9A4.1030508@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F19E386@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A92F19E386@BY2PRD0411MB441.namprd04.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 18:11:25 -0000 Hi Adam, thanks for sharing it, helpful, On 27/11/12 17:24, Lewis Adam-CAL022 wrote: > Hi Sergey, > > In my use cases the client actively monitors the expiration of the AT in order to request a new AT using the RT. We do this as you suggested, because presenting an expired AT to the RS is a wasted round trip and adds latency and degrades the user experience. Why send the AT if we know it's expired? > How do you know when the client is expecting a revocation and when a downscoping, I guess if the client includes and optional 'scope' parameter then it is down-scoping obviously, otherwise - revocation ? If that is the case then IMHO a refresh token grant request without a scope parameter might offer a shortcut for the client not to worry about one more endpoint (to do with the revocation) ? > As to your other question, one reason to down scope an AT ... in my use cases the AS issues access tokens for many different RS's. It is a security concern to send an AT to RS1 that has the ability to also access protected resources at RS2 and RS3 and RSn, etc. So I make a first request to get a "master" AT with a master RT, and then immediately destroy the master AT and use the master RT to get a down-scoped AT - one for each RS. This is inefficient though, and I've been nagging the WG to consider a draft to allow a client to request an array of access tokens of different scopes. > OK, that makes it clearer. What I'm concerned about though, does the client need to be concerned or is it the job of AS to protect in cases where a token with too many scopes is used to access a given RS which may delegate to a stricter RS ? I mean, is client expected to be well-behaved and know about the relationships between the master RS with the stricter RS1 & RS2 parthers ? Seems not easy to make it interoperable... Guess I'm missing the point still Thanks, Sergey > These are just my experience, and as Justin mentioned, your millage may vary. Hope it helps either way :-) > > adam > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Sergey Beryozkin > Sent: Tuesday, November 27, 2012 10:26 AM > To: Richer, Justin P. > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token > > On 27/11/12 15:48, Richer, Justin P. wrote: >> Yes, the client can keep two tokens and try using both of them if it wants to. I think that you're conflating revocation and expiration here, and missing a key use case: downscoping. Let's say the client gets an access grant for [A, B, C], and it gets RT and AT1 for those scopes. The client then wants to call a service with *only* scope B, so it sends RT in with scope B in the refresh request to get AT2 with that scope alone. AT1 is still valid, assuming it hasn't expired or otherwise been revoked. The client can choose which AT to present to the protected resources in different situations. >> > That is complex :-). Using a refresh token to downscope and keep a > number of access tokens is definitely beyond my imagination at the > moment, why would a client want to downscope its access token ? > > Is it basically described at: > http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-03#section-3.10 ? > > I'm still not getting though why access token with the richer set of > scopes needs to be explicitly downscoped by the client, is it because > using a token with a richer set of scopes can lead to some authorization > issues ? > > I was thinking that the down-scoping only makes sense during the > authorization code flow where AS downscopes what the client has > requested but obviously I'm only at the start of the learning curve :-). > > > >> In all of these cases, it's completely up to the AS and the PRs whether or not any of the tokens in the wild are still valid. Your AS might decide that once a RT is used, it will simply throw away all existing AT's attached to that RT. That's totally a valid use case, and the client needs to be able to handle that (in the same way that it handles any invalid token). >> >> If you want the clients to explicitly throw out tokens, use the Token Revocation spec. >> > OK, that makes sense now. > > Thanks, Sergey > >> -- Justin >> >> On Nov 27, 2012, at 10:41 AM, Sergey Beryozkin wrote: >> >>> On 27/11/12 15:29, Richer, Justin P. wrote: >>>> The client can indeed save a round trip by proactively refreshing the access token. This does not necessarily revoke the existing access token. Many implementations do that, so your mileage may vary. >>>> >>> >>> I don't understand. >>> >>> So the client will still have the existing access token which may have not been revoked, and then also another access token which was just returned in response to the refresh grant request ? >>> >>> And if you mean that no actual revocation is actually done, why then have the client worry about doing the proactive refresh ? >>> >>> I can imagine that may be that it will only be the actual refresh token refreshed itself, but why keep the access token if the client has requested a refresh ? >>> >>> Sergey >>> >>>> -- Justin >>>> >>>> On Nov 27, 2012, at 5:18 AM, Sergey Beryozkin wrote: >>>> >>>>> On 27/11/12 08:52, Guangqing Deng wrote: >>>>>> It seems that the client cannot know whether the refresh token should be >>>>>> used until a HTTP 401 error is returned from the resource server due to >>>>>> the expiration of current access token or some other reasons. However, a >>>>>> period of time cannot be ignored will be spent on obtain a new access >>>>>> token using the refresh token after the resource server returns a HTTP >>>>>> 401 error to the client, which may degrade the user experience since the >>>>>> real-time nature of the service cannot be guaranteed. Is a mechanism by >>>>>> which the client can check the validity of the access token (or the >>>>>> refresh token) in advance needed by Oauth? >>>>> >>>>> I believe an access token response may offer an expires_in parameter which can provide some hint. Actually this raises an interesting question. >>>>> Suppose the client actually checks this parameter and decides to use >>>>> a refresh token it also has to pro-actively refresh its current token. >>>>> >>>>> IMHO this should work even if the access token has not expired yet and effectively represents another form of a client-initiated revocation of the access token ? It will mean a client which works with the "expires_in" parameter can save a one round trip (the one which returns a failure in case of the access token being expired) ? >>>>> >>>>> Does it make sense ? If it does, can some relevant wording make it into the revocation token draft ? >>>>> >>>>> Cheers, Sergey >>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> Guangqing Deng >>>>>>> ------------------------------------------------------------------------ >>>>>>> *From:* Justin Richer >>>>>>> *To:* Sergey Beryozkin >>>>>>> *Cc:* oauth@ietf.org >>>>>>> *Sent:* Wednesday, November 21, 2012 6:11 AM >>>>>>> *Subject:* Re: [OAUTH-WG] How the client can decide it is time to use >>>>>>> the refresh token >>>>>>> >>>>>>> There's no signaling regarding the validity of the refresh token from >>>>>>> the protected resource. In more distributed setups, the protected >>>>>>> resources know nothing about the refresh tokens because the PR never >>>>>>> sees them. In any case. the code path is fairly straightforward, even if >>>>>>> both tokens are expired: >>>>>>> >>>>>>> - client presents AT to resource >>>>>>> - resource returns data, AT worked >>>>>>> - [or] resource returns 400 error to client, AT didn't work >>>>>>> - client presents RT to auth server >>>>>>> - auth server returns new AT, RT worked >>>>>>> - [or] auth server returns 400 error to client, RT didn't work >>>>>>> - client has to go get a new auth grant from the resource owner, >>>>>> start over >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> >>>>>>> On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> I'm looking for some guidance on how the client which already owns an >>>>>>> access token can decide, after getting HTTP 400 back from the resource >>>>>>> server it tries to access on behalf of the end user/resource owner, can >>>>>>> decide that the refresh token it has can now be used to get a new access >>>>>>> token. >>>>>>>> >>>>>>>> [1] refers to various error conditions but it is not obvious to me >>>>>>> that the same conditions (some of them) should or can be reported during >>>>>>> the actual client accessing the protected resource. >>>>>>>> >>>>>>>> My question is, what error condition, if any, from [1] should be >>>>>>> reported back to the client failing to access a protected resource due >>>>>>> to the access token being invalid or expired, so that it can help the >>>>>>> client who also owns the refresh token to decide it can use it now... >>>>>>>> >>>>>>>> Thanks, Sergey >>>>>>>> >>>>>>>> [1] http://tools.ietf.org/html/rfc6749#section-5.2 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 > > > > > From jricher@mitre.org Tue Nov 27 10:46:04 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623C921F8482 for ; Tue, 27 Nov 2012 10:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHmEn1NL2x4z for ; Tue, 27 Nov 2012 10:46:03 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B02AE21F847D for ; Tue, 27 Nov 2012 10:46:03 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 26CB54350245 for ; Tue, 27 Nov 2012 13:46:03 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 073FA1F0CD7 for ; Tue, 27 Nov 2012 13:46:03 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.132]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Tue, 27 Nov 2012 13:46:02 -0500 From: "Richer, Justin P." To: "oauth@ietf.org WG" Thread-Topic: New Version Notification for draft-richer-oauth-introspection-00.txt Thread-Index: AQHNzM8rmNsVi0Uwi0mDHLc7BRzb4A== Date: Tue, 27 Nov 2012 18:46:02 +0000 Message-ID: References: <20121127184401.20364.27482.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.43.53] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E0684F375IMCMBX01MITREOR_" MIME-Version: 1.0 Subject: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 18:46:04 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E0684F375IMCMBX01MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I took some time this morning to put together a draft of Token Introspectio= n. This is largely based on how we implemented it here a few years ago, and= I'm hoping that this and the Ping draft can help move the conversation abo= ut introspection forward. -- Justin Begin forwarded message: From: > Subject: New Version Notification for draft-richer-oauth-introspection-00.t= xt Date: November 27, 2012 1:44:01 PM EST To: > A new version of I-D, draft-richer-oauth-introspection-00.txt has been successfully submitted by Justin Richer and posted to the IETF repository. Filename: draft-richer-oauth-introspection Revision: 00 Title: OAuth Token Introspection Creation date: 2012-11-27 WG ID: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-richer-oauth-int= rospection-00.txt Status: http://datatracker.ietf.org/doc/draft-richer-oauth-introsp= ection Htmlized: http://tools.ietf.org/html/draft-richer-oauth-introspectio= n-00 Abstract: This specification defines a method for a client or protected resource to query an OAuth authorization server to determine meta- information about an OAuth token. The IETF Secretariat --_000_B33BFB58CCC8BE4998958016839DE27E0684F375IMCMBX01MITREOR_ Content-Type: text/html; charset="us-ascii" Content-ID: <57E026B0EA58204F99AEDAE97602873E@imc.mitre.org> Content-Transfer-Encoding: quoted-printable I took some time this morning to put together a draft of Token Introspectio= n. This is largely based on how we implemented it here a few years ago, and= I'm hoping that this and the Ping draft can help move the conversation abo= ut introspection forward.

 -- Justin

Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Subject: Ne= w Version Notification for draft-richer-oauth-introspection-00.txt
Date: Novem= ber 27, 2012 1:44:01 PM EST
To: <<= a href=3D"mailto:jricher@mitre.org">jricher@mitre.org>


A new version of I-D, draft-richer-oauth-introspection-00.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename: d= raft-richer-oauth-introspection
Revision: 0= 0
Title: OAuth Token Int= rospection
Creation date: 2012-11-27
WG ID: Individual Subm= ission
Number of pages: 6
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-richer-oauth-intro= spection-00.txt
Status:          http://data= tracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/h= tml/draft-richer-oauth-introspection-00


Abstract:
  This specification defines a method for a client or protected   resource to query an OAuth authorization server to determine me= ta-
  information about an OAuth token.





The IETF Secretariat


--_000_B33BFB58CCC8BE4998958016839DE27E0684F375IMCMBX01MITREOR_-- From hannes.tschofenig@gmx.net Tue Nov 27 10:50:41 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A96221F85D5 for ; Tue, 27 Nov 2012 10:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAb0NQXdh7RT for ; Tue, 27 Nov 2012 10:50:40 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E5CF921F842B for ; Tue, 27 Nov 2012 10:50:39 -0800 (PST) Received: (qmail invoked by alias); 27 Nov 2012 18:50:38 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp002) with SMTP; 27 Nov 2012 19:50:38 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/7D6MA9c/7RzBlJNoTkWDSB9gszpXd5U7w1tCyJI biSUbGV6VnWL84 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <50B4B5D4.4070805@gmail.com> Date: Tue, 27 Nov 2012 20:50:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3DB12DBE-267E-49BF-A398-B82B3265A706@gmx.net> References: <50B3B1B3.50502@gmail.com><6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> <50B4A2AC.6010904@gmail.com> <999913AB42CC9341B05A99BBF358718D022492FA@FIESEXC035.nsn-intra.net> <50B4B5D4.4070805@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 18:50:41 -0000 Hi Sergey,=20 On Nov 27, 2012, at 2:45 PM, Sergey Beryozkin wrote: > Hi Hannes >=20 > On 27/11/12 12:33, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi Sergey, >>=20 >> I believe we would make faster progress on security topics if could >> focus on listing security requirements we have and what threats we = want >> to mitigate. The reason why we have not finished this topic is simply >> because everyone was just talking about specific (but incomplete) >> solutions. You are unfortunately falling in the same trap as well. >=20 > Quite possible - I was hoping to give some perspective of someone who = would like to see a wider acceptance of 2.0 at the grass root level if = you wish where 'grass root' represents simple 2.0 applications. We are obviously interested in wide acceptance of our specifications.=20 >=20 >>=20 >> If you really care about the topic then have a look at the mentioned >> document and tell us whether the requirements are complete. >> Reading through the document you will notice that there a few more >> considerations to pay attention to than just the few listed below. >>=20 > Believe it or not I did read the document awhile back :-) Cool. Thanks.=20 > and will definitely read it few times more - it is a must-read. I'm = just concerned that it appears that the possible progress on MAC > needs to be justified by linking it implicitly to the security threats = doc. And I'm not sure it is the best way to follow. >=20 > How about a slightly different approach. > Do you agree that supporting HOK is important ? Assuming yes then I = guess the threats doc must be talking about the relevant issues that HOK = can help with addressing. >=20 > If we can agree on this then IMHO MAC passes the acceptance criteria = because it offers one way to provide a HOK support. Whether JWT or other = token type may also help with HOK support is entirely different issue = and it is down to specific OAuth2 implementers on which HOK-capable = token to support In Section 4 of = http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 we tried = to explain that there are three approaches to address very common = security threats that exist in these three party protocols. All three = approach, namely "confidentiality protection", "sender constraint", and = "key confirmation", address these common threats in their own way. The = details vary between the different solution categories. We published the = bearer token specification, which follows the approach described in = Section 4.1 ("confidentiality protection").=20 The group very early on said that they also wand an alternative, using = "key confirmation". This was actually the reason why we moved the bearer = and the MAC specification out of the main OAuth 2.0 and put them into = separate documents. Consequently, there is no need to convince us that = we should be working on a solution that is different than the bearer = token (even I keep explaining folks that bearer tokens are not cookies = and that they have similar properties than the other mechanisms).=20 We had also figured out that there isn't only a single solution that = will make everyone happy. But we also don't want to standardize = everything comes to our mind: you can see in other areas (e.g., EAP, = SASL, TLS ciphersuites, IKEv2 extension, etc.) that the creativity is = endless when it comes to authentication and key exchange protocols.=20 I am hoping that the conference calls (which I had asked folks to = indicate their preference for) will help us to come up with an answer of = what the essential requirements are (and hopefully within a very short = timeframe). You are, btw, welcome to join those calls.=20 Ciao Hannes PS: We should have probably never used the term HOK since it caused more = confusion than it helped.=20 >=20 > Thanks, Sergey >=20 >=20 >=20 >> Ciao >> Hannes >>=20 >>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >>> Of ext Sergey Beryozkin >>> Sent: Tuesday, November 27, 2012 1:23 PM >>> To: Hannes Tschofenig >>> Cc: >>> Subject: Re: [OAUTH-WG] What needs to be done to complete MAC >>>=20 >>> Hi Hannes >>> On 26/11/12 19:01, Hannes Tschofenig wrote: >>>> Hi Sergey, >>>>=20 >>>> as Phil said it would be helpful for us to receive reviews of this >>> document: >>>> http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 >>>>=20 >>>> The document lists requirements and threats. >>>=20 >>>=20 >>> Let me offer two possibly naive reasons why using MAC may help, one = of >>> them is related to the security, another to the ease of HOK support = on >>> the client >>>=20 >>> 1. The most safe way to return MAC token to the client is to use a >>> two-way TLS due to the mac key also returned to the client. Two-Way >> TLS >>> offers a stronger support for getting the client authenticated along >> the >>> way too >>>=20 >>> 2. Assuming HOK confirmation matters at all (and I believe it does), >>> IMHO it is much simpler for a basic client implementation to apply a >> MAC >>> signature algo and thus work with the OAuth2 servers expecting HOK >>> confirmations >>>=20 >>> One more reason is more about facilitating the further migration to >> 2.0 >>> which I tried to outline in my response to Phil Hunt >>>=20 >>> Thanks, Sergey >>>=20 >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>> On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote: >>>>=20 >>>>> If we want to get this done we have to get agreements on the >>> requirements for HOK. Several meetings ago (quebec) the group >> indicated >>> that mac wasn't appropriate to anyone's needs. >>>>>=20 >>>>> Some would argue that OAuth1 users arguably have less security = than >>> the simpler bearer token /tls model in OAuth2. This just shows the >> real >>> issue of demonstrated need has not been properly defined and >> understood. >>>>>=20 >>>>> More dialog on use cases is very helpful to moving HOK/MAC/etc >>> forward. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On 2012-11-26, at 10:15, Sergey Beryozkin >>> wrote: >>>>>=20 >>>>>> Hi >>>>>>=20 >>>>>> What needs to be done to complete the MAC token spec ? Without >>> having it signed off it will be difficult to get people working with >>> OAuth 1.0 convinced to move to 2.0. >>>>>> I'm seeing another user request for getting OAuth 1.0 support >>> extended further because the user expects it is more secure, and I >> guess >>> because it is proven to work for people, and I guess because many >> OAuth >>> 1.0 users feel that should stay from OAuth 2.0 because of some bad >> press. >>>>>>=20 >>>>>> Without MAC being completed the division will continue, with even >>> more misleading anti-OAuth2 posts appearing (though I guess some of >> the >>> better posts point to some level of complexity in 2.0). >>>>>>=20 >>>>>> Is it a matter of a security expert validating the text, fixing >> few >>> typos, and basically signing it off ? >>>>>>=20 >>>>>> If someone is interested then I can provide the info offline on >> how >>> it MAC supported in our framework to get things tested easily and >> such... >>>>>>=20 >>>>>> Cheers, Sergey >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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 >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Tue Nov 27 10:55:02 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5484421F872A for ; Tue, 27 Nov 2012 10:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvO7k027hWBx for ; Tue, 27 Nov 2012 10:55:01 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id DB3CC21F85E8 for ; Tue, 27 Nov 2012 10:55:00 -0800 (PST) Received: (qmail invoked by alias); 27 Nov 2012 18:54:51 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp004) with SMTP; 27 Nov 2012 19:54:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18/2F0Q1k4/RFVnI5Z3FwUzk1HFC1uLpVrVYOl04K tIdln5lMcEfJQV Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1354037569.35121.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 27 Nov 2012 20:54:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8D3D9321-EB03-4A00-B981-C197DAD0A408@gmx.net> References: <50B3B1B3.50502@gmail.com><6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> <50B4A2AC.6010904@gmail.com> <999913AB42CC9341B05A99BBF358718D022492FA@FIESEXC035.nsn-intra.net> <1354037569.35121.YahooMailNeo@web31813.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 18:55:02 -0000 Hi Bill,=20 On Nov 27, 2012, at 7:32 PM, William Mills wrote: > I don't see in that document a significant use case for a signed = token, which is use over clear text channels. With "that document" I guess you refer to = http://tools.ietf.org/html/draft-tschofenig-oauth-security-00?=20 With "signed token" do you mean an access token that is signed by the = party issuing it?=20 > Bearer tokens have similar security properties to HTTP cookies (minus = for the moment the XSRF problem). Please don't compare bearer tokens with cookies. They are very = different.=20 > Signed token types can be used over plain text channels without the = concern about re-use of the token by a 3rd party. Replay protection is = still needed but that's not in scope for the token mechanism itself. I guess signed token here means something like MAC where you actually do = not sign the token but compute a message digest over some headers of the = request.=20 >=20 > It's always been this simple use case that has been my focus for MAC. Could you describe your simple use case? For example, is it acceptable = for you to use TLS from the client to the authorization server to get = the MAC key (and algorithm)? What is your story regarding computing the = keyed message digest over the HTTP message: header fields only, body? = What about confidentiality protection? What about protecting the actual = data (not just the request that contains the access token)? >=20 > Flickr uses OAuth 1.0a today over HTTP and will for many years to = come, we won't be able to go completely SSL due to the installed base of = clients. If that's the case and they only use HTTP then they are in violation of = the OAuth 1.0a spec.=20 > Given the dynamic I see in the mobile development community I don't = see us getting all mobile apps into SSL only anytime soon. What makes you believe that guys who don't want to use an off-the-shelf = library for security will get a custom security solution right.=20 The performance of TLS is not an issue for mobile devices anymore. It = may have been an issue in 2005.=20 If they want to use OAuth 2.0 (as it is specified today; irrespectively = of the bearer token spec) they have to use TLS in their code base.=20 > MAC and OAuth 1.0 solve the token security problem for the last hop = to the phone/wi-fi device without SSL for the bulk of the application = traffic. The IETF OAuth 1.0a specification requires TLS to be used between the = client and the authorization server.=20 Ciao Hannes > -bill >=20 >=20 > From: "Tschofenig, Hannes (NSN - FI/Espoo)" = > To: ext Sergey Beryozkin ; Hannes Tschofenig = =20 > Cc: oauth@ietf.org=20 > Sent: Tuesday, November 27, 2012 4:33 AM > Subject: Re: [OAUTH-WG] What needs to be done to complete MAC >=20 > Hi Sergey,=20 >=20 > I believe we would make faster progress on security topics if could > focus on listing security requirements we have and what threats we = want > to mitigate. The reason why we have not finished this topic is simply > because everyone was just talking about specific (but incomplete) > solutions. You are unfortunately falling in the same trap as well.=20 >=20 > If you really care about the topic then have a look at the mentioned > document and tell us whether the requirements are complete.=20 > Reading through the document you will notice that there a few more > considerations to pay attention to than just the few listed below.=20 >=20 > Ciao > Hannes >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf > > Of ext Sergey Beryozkin > > Sent: Tuesday, November 27, 2012 1:23 PM > > To: Hannes Tschofenig > > Cc: > > Subject: Re: [OAUTH-WG] What needs to be done to complete MAC > >=20 > > Hi Hannes > > On 26/11/12 19:01, Hannes Tschofenig wrote: > > > Hi Sergey, > > > > > > as Phil said it would be helpful for us to receive reviews of this > > document: > > > http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 > > > > > > The document lists requirements and threats. > >=20 > >=20 > > Let me offer two possibly naive reasons why using MAC may help, one = of > > them is related to the security, another to the ease of HOK support = on > > the client > >=20 > > 1. The most safe way to return MAC token to the client is to use a > > two-way TLS due to the mac key also returned to the client. Two-Way > TLS > > offers a stronger support for getting the client authenticated along > the > > way too > >=20 > > 2. Assuming HOK confirmation matters at all (and I believe it does), > > IMHO it is much simpler for a basic client implementation to apply a > MAC > > signature algo and thus work with the OAuth2 servers expecting HOK > > confirmations > >=20 > > One more reason is more about facilitating the further migration to > 2.0 > > which I tried to outline in my response to Phil Hunt > >=20 > > Thanks, Sergey > >=20 > > > > > > Ciao > > > Hannes > > > > > > On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote: > > > > > >> If we want to get this done we have to get agreements on the > > requirements for HOK. Several meetings ago (quebec) the group > indicated > > that mac wasn't appropriate to anyone's needs. > > >> > > >> Some would argue that OAuth1 users arguably have less security = than > > the simpler bearer token /tls model in OAuth2. This just shows the > real > > issue of demonstrated need has not been properly defined and > understood. > > >> > > >> More dialog on use cases is very helpful to moving HOK/MAC/etc > > forward. > > >> > > >> Phil > > >> > > >> On 2012-11-26, at 10:15, Sergey Beryozkin > > wrote: > > >> > > >>> Hi > > >>> > > >>> What needs to be done to complete the MAC token spec ? Without > > having it signed off it will be difficult to get people working with > > OAuth 1.0 convinced to move to 2.0. > > >>> I'm seeing another user request for getting OAuth 1.0 support > > extended further because the user expects it is more secure, and I > guess > > because it is proven to work for people, and I guess because many > OAuth > > 1.0 users feel that should stay from OAuth 2.0 because of some bad > press. > > >>> > > >>> Without MAC being completed the division will continue, with = even > > more misleading anti-OAuth2 posts appearing (though I guess some of > the > > better posts point to some level of complexity in 2.0). > > >>> > > >>> Is it a matter of a security expert validating the text, fixing > few > > typos, and basically signing it off ? > > >>> > > >>> If someone is interested then I can provide the info offline on > how > > it MAC supported in our framework to get things tested easily and > such... > > >>> > > >>> Cheers, Sergey > > >>> > > >>> _______________________________________________ > > >>> 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 > > > > >=20 > > _______________________________________________ > > 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 >=20 >=20 From hannes.tschofenig@gmx.net Tue Nov 27 10:55:03 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E46521F871C for ; Tue, 27 Nov 2012 10:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJMPfTwN9g8w for ; Tue, 27 Nov 2012 10:55:02 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6471F21F8728 for ; Tue, 27 Nov 2012 10:55:01 -0800 (PST) Received: (qmail invoked by alias); 27 Nov 2012 18:54:57 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp004) with SMTP; 27 Nov 2012 19:54:57 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18xF706FLsxR5FezJGX2YTqqUIic2Apo/ZwzeSq8W lUt7boO/wpUZnt Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1354039156.86802.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 27 Nov 2012 20:54:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4AE3FDC6-2752-4BEE-8415-FDFDDD5DCEB8@gmx.net> References: <50B3B1B3.50502@gmail.com><6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> <50B4A2AC.6010904@gmail.com> <999913AB42CC9341B05A99BBF358718D022492FA@FIESEXC035.nsn-intra.net> <1354037569.35121.YahooMailNeo@web31813.mail.mud.yahoo.com> <1354039156.86802.YahooMailNeo@web31808.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 18:55:03 -0000 Good that you both raise this point. The refresh token mechanism allows = us to request new access tokens (and new keying material correspondingly = since the two are tight together) in a dynamic fashion. If you turn the = MAC key into a long term secret or use it with multiple resource servers = then you obviously loose the security benefits.=20 All this is documented in Section 5 of = http://tools.ietf.org/html/draft-tschofenig-oauth-security-00#section-5 On Nov 27, 2012, at 7:59 PM, William Mills wrote: > Yes! >=20 > The other thing that is better in the OAuth 2 model is the refresh = capability, which makes plain text channel token usage more palatable. >=20 > From: "Richer, Justin P." > To: William Mills =20 > Cc: "Tschofenig, Hannes (NSN - FI/Espoo)" ; = ext Sergey Beryozkin ; Hannes Tschofenig = ; "oauth@ietf.org" =20 > Sent: Tuesday, November 27, 2012 9:51 AM > Subject: Re: [OAUTH-WG] What needs to be done to complete MAC >=20 > An important point to note, that many OAuth1 implementations in the = wild screw up, is that you still need TLS between the client and the = Authorization Server to protect the token and secret in transit, even if = you don't use TLS during the client's calls to the protected resource. = Since OAuth2 core mandates TLS at the Token Endpoint explicitly for all = token types, that's much more clear to understand (in my opinion) in = implementation. >=20 > In case the above is unclear, what I'm trying to say is this: putting = a signed token like MAC into the OAuth2 framework will give us the = capability of OAuth1 in a clearer, more secure (in the wild) structure. = I think it's vitally important that we have this functionality, and = while I understand the need for clear use cases, I don't understand the = feet-dragging. >=20 > -- Justin >=20 > On Nov 27, 2012, at 12:32 PM, William Mills wrote: >=20 >> I don't see in that document a significant use case for a signed = token, which is use over clear text channels. Bearer tokens have = similar security properties to HTTP cookies (minus for the moment the = XSRF problem). Signed token types can be used over plain text channels = without the concern about re-use of the token by a 3rd party. Replay = protection is still needed but that's not in scope for the token = mechanism itself. >>=20 >> It's always been this simple use case that has been my focus for MAC. >>=20 >> Flickr uses OAuth 1.0a today over HTTP and will for many years to = come, we won't be able to go completely SSL due to the installed base of = clients. Given the dynamic I see in the mobile development community I = don't see us getting all mobile apps into SSL only anytime soon. MAC = and OAuth 1.0 solve the token security problem for the last hop to the = phone/wi-fi device without SSL for the bulk of the application traffic. >>=20 >> -bill >>=20 >>=20 >> From: "Tschofenig, Hannes (NSN - FI/Espoo)" = >> To: ext Sergey Beryozkin ; Hannes Tschofenig = =20 >> Cc: oauth@ietf.org=20 >> Sent: Tuesday, November 27, 2012 4:33 AM >> Subject: Re: [OAUTH-WG] What needs to be done to complete MAC >>=20 >> Hi Sergey,=20 >>=20 >> I believe we would make faster progress on security topics if could >> focus on listing security requirements we have and what threats we = want >> to mitigate. The reason why we have not finished this topic is simply >> because everyone was just talking about specific (but incomplete) >> solutions. You are unfortunately falling in the same trap as well.=20 >>=20 >> If you really care about the topic then have a look at the mentioned >> document and tell us whether the requirements are complete.=20 >> Reading through the document you will notice that there a few more >> considerations to pay attention to than just the few listed below.=20 >>=20 >> Ciao >> Hannes >>=20 >>=20 >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> > Of ext Sergey Beryozkin >> > Sent: Tuesday, November 27, 2012 1:23 PM >> > To: Hannes Tschofenig >> > Cc: >> > Subject: Re: [OAUTH-WG] What needs to be done to complete MAC >> >=20 >> > Hi Hannes >> > On 26/11/12 19:01, Hannes Tschofenig wrote: >> > > Hi Sergey, >> > > >> > > as Phil said it would be helpful for us to receive reviews of = this >> > document: >> > > http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 >> > > >> > > The document lists requirements and threats. >> >=20 >> >=20 >> > Let me offer two possibly naive reasons why using MAC may help, one = of >> > them is related to the security, another to the ease of HOK support = on >> > the client >> >=20 >> > 1. The most safe way to return MAC token to the client is to use a >> > two-way TLS due to the mac key also returned to the client. Two-Way >> TLS >> > offers a stronger support for getting the client authenticated = along >> the >> > way too >> >=20 >> > 2. Assuming HOK confirmation matters at all (and I believe it = does), >> > IMHO it is much simpler for a basic client implementation to apply = a >> MAC >> > signature algo and thus work with the OAuth2 servers expecting HOK >> > confirmations >> >=20 >> > One more reason is more about facilitating the further migration to >> 2.0 >> > which I tried to outline in my response to Phil Hunt >> >=20 >> > Thanks, Sergey >> >=20 >> > > >> > > Ciao >> > > Hannes >> > > >> > > On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote: >> > > >> > >> If we want to get this done we have to get agreements on the >> > requirements for HOK. Several meetings ago (quebec) the group >> indicated >> > that mac wasn't appropriate to anyone's needs. >> > >> >> > >> Some would argue that OAuth1 users arguably have less security = than >> > the simpler bearer token /tls model in OAuth2. This just shows the >> real >> > issue of demonstrated need has not been properly defined and >> understood. >> > >> >> > >> More dialog on use cases is very helpful to moving HOK/MAC/etc >> > forward. >> > >> >> > >> Phil >> > >> >> > >> On 2012-11-26, at 10:15, Sergey Beryozkin >> > wrote: >> > >> >> > >>> Hi >> > >>> >> > >>> What needs to be done to complete the MAC token spec ? Without >> > having it signed off it will be difficult to get people working = with >> > OAuth 1.0 convinced to move to 2.0. >> > >>> I'm seeing another user request for getting OAuth 1.0 support >> > extended further because the user expects it is more secure, and I >> guess >> > because it is proven to work for people, and I guess because many >> OAuth >> > 1.0 users feel that should stay from OAuth 2.0 because of some bad >> press. >> > >>> >> > >>> Without MAC being completed the division will continue, with = even >> > more misleading anti-OAuth2 posts appearing (though I guess some of >> the >> > better posts point to some level of complexity in 2.0). >> > >>> >> > >>> Is it a matter of a security expert validating the text, fixing >> few >> > typos, and basically signing it off ? >> > >>> >> > >>> If someone is interested then I can provide the info offline on >> how >> > it MAC supported in our framework to get things tested easily and >> such... >> > >>> >> > >>> Cheers, Sergey >> > >>> >> > >>> _______________________________________________ >> > >>> 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 >> > > >> >=20 >> > _______________________________________________ >> > 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 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 From beaton@google.com Tue Nov 27 12:10:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D2321F876E for ; Tue, 27 Nov 2012 12:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NDuM5jM9Jjr for ; Tue, 27 Nov 2012 12:10:23 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82F3E21F8764 for ; Tue, 27 Nov 2012 12:10:23 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so10557486lah.31 for ; Tue, 27 Nov 2012 12:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NC7rvbroRzB4TyUvwtfQMhFGNoNveIbo687aNgBzHpI=; b=igWyILvhS3fxbEbVlYmkzKj1aCSCtUleUA2+D73anG9K1ZS2peagAnzSaPjiEABnqU HKcZVBBlN4QFcqG0mv421vUE0ayubiYiDSO0GckW5KWKv3p/TuofcE6NZ36seay+nyfA 8F/NYw/Ylu0N1khlS4mJIdznXAffm4EdT7781dYSuCCIPdPt1aU5OaG+FzCTt8c3+MOj CLZE1L21Ggd3etpDDbfgvJwIgbn2OxluNfO15o5TLdIXFY34LND1ZH3fhgSvwzqOFguc +PYeW9yXbgX/QHFp+md+HeUm8UKD984xY4J3cmEq+VSLxkbYuDjEpr1us/7JYhNdN11k 5S2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=NC7rvbroRzB4TyUvwtfQMhFGNoNveIbo687aNgBzHpI=; b=TpF789hh9vKhVPAmL1Hnz/4u4xCPsMFJMAtyHOLrltHx+dC1MjnKLC5rMCwiNPSlSB Ycxz8Uz1byszo+zGXBpJz5BF80aohlukIJsoMLVNhw7RWcMUG1N5umkGzYG+8l1Tbgz/ Nm9GO6xt5/P3WfcTp1PdSeWM2pdwxGPErc6laCUD2hSZ4SHzu9Zu5lshRW9Nu3XOJyfc tf8v/GtcvlLL6bp+BfI8SweGnVguFYrSRxxr83UZ5mhosfrWfFbjWt2CQ66Ytf9Ie100 awSKY4sIeh59bmPvaba0u2a5ErSS6LNVMRTEFX/RIbvuyLNZ31NTJwNIxaldhE8c9YOK 5JaQ== MIME-Version: 1.0 Received: by 10.112.25.106 with SMTP id b10mr6880930lbg.68.1354047022425; Tue, 27 Nov 2012 12:10:22 -0800 (PST) Received: by 10.112.24.98 with HTTP; Tue, 27 Nov 2012 12:10:22 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Nov 2012 12:10:22 -0800 Message-ID: From: Brian Eaton To: Shane B Weeden Content-Type: multipart/alternative; boundary=f46d0401240bc7e7b904cf7fa397 X-Gm-Message-State: ALoCoQkAX7psZEs4GK+WhFymTYPrwG2ZcCdqyVE+jg5dVTLWClinKW2gvXUQBC9FexJtyn+yHNo9DerhE2ND2KBwKXjRkgFOF78ePUllDO7nTvblUOx3PtIqbeuHRkMlMXUVjSV3z+xg6cWp5a3FE/283wjWEZ5tgIy0I169+1bY6WcAwqhry8oZRCLd3HVdle/0PSXeT10z Cc: OAuth WG , Bob Gregory , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Token refresh and The Two Generals X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 20:10:24 -0000 --f46d0401240bc7e7b904cf7fa397 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 26, 2012 at 7:22 PM, Shane B Weeden wrote: > My understanding is that it is considered a best practice to rollover a > refresh token on each use - that is when a refresh token is used, both a > new access token and a new refresh token are issued, and the old refresh > token is revoked. > FWIW, I think rotating the refresh token every time it is used is a bit excessive, something time based (e.g. once every few weeks or few months) would be fine as well. The trade-off is that things that happen rarely are more likely to trigger bugs on the client side. =) --f46d0401240bc7e7b904cf7fa397 Content-Type: text/html; charset=ISO-8859-1
On Mon, Nov 26, 2012 at 7:22 PM, Shane B Weeden <sweeden@au1.ibm.com> wrote:
My understanding is that it is considered a best practice to rollover a
refresh token on each use - that is when a refresh token is used, both a
new access token and a new refresh token are issued, and the old refresh
token is revoked.

FWIW, I think rotating the refresh token every time it is used is a bit excessive, something time based (e.g. once every few weeks or few months) would be fine as well.

The trade-off is that things that happen rarely are more likely to trigger bugs on the client side. =)
--f46d0401240bc7e7b904cf7fa397-- From sweeden@au1.ibm.com Tue Nov 27 13:22:09 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2429C21F84C1 for ; Tue, 27 Nov 2012 13:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6kI7ujLvYWz for ; Tue, 27 Nov 2012 13:22:08 -0800 (PST) Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6F18021E8030 for ; Tue, 27 Nov 2012 13:22:07 -0800 (PST) Received: from /spool/local by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 28 Nov 2012 07:18:21 +1000 Received: from d23relay03.au.ibm.com (202.81.31.245) by e23smtp03.au.ibm.com (202.81.31.209) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 28 Nov 2012 07:18:20 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qARLLvR566650290; Wed, 28 Nov 2012 08:21:58 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qARLLv00030957; Wed, 28 Nov 2012 08:21:57 +1100 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qARLLuEe030951; Wed, 28 Nov 2012 08:21:56 +1100 In-Reply-To: References: X-KeepSent: 9EAFE6A8:631C15F4-4A257AC3:0074D7C3; type=4; name=$KeepSent To: Bob Gregory X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Shane B Weeden Date: Wed, 28 Nov 2012 07:16:47 +1000 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.3FP2HF29 | July 24, 2012) at 28/11/2012 08:26:40 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 x-cbid: 12112721-6102-0000-0000-000002A1D84B Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Token refresh and The Two Generals X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 21:22:09 -0000 U291bmRzIGxpa2UgYSBzZW5zaWJsZSBhcHByb2FjaCBCb2IgLSBhbmQgdGhhbmtzIGZvciB0aGUg ZGlzY3Vzc2lvbiBhcyBpdCdzDQpyZWFsLXdvcmxkIGlzc3VlcyBsaWtlIHRoaXMgd2hpY2ggdWx0 aW1hdGVseSByZWFsbHkgbWF0dGVyLg0KDQoNCg0KRnJvbToJQm9iIEdyZWdvcnkgPHBhdGhvZ2Vu aXhAZ21haWwuY29tPg0KVG86CVNoYW5lIEIgV2VlZGVuL0F1c3RyYWxpYS9JQk1ASUJNQVUNCkNj OglUaW0gQnJheSA8dHdicmF5QGdvb2dsZS5jb20+LCBCcmlhbiBFYXRvbiA8YmVhdG9uQGdvb2ds ZS5jb20+LA0KICAgICAgICAgICAgT0F1dGggV0cgPG9hdXRoQGlldGYub3JnPiwgb2F1dGgtYm91 bmNlc0BpZXRmLm9yZw0KRGF0ZToJMjcvMTEvMjAxMiAxMDozMyBQTQ0KU3ViamVjdDoJUmU6IFtP QVVUSC1XR10gVG9rZW4gcmVmcmVzaCBhbmQgVGhlIFR3byBHZW5lcmFscw0KDQoNCg0KV2UgZGlk IGNvbnNpZGVyIGhvbGRpbmcgb24gdG8gdHdvIHJlZnJlc2ggdG9rZW5zLCBidXQgaXQgcmFwaWRs eSBnZXRzIG1lc3N5DQphbmQgZGVncmFkZXMgdG8gdXNpbmcgYSBzaW5nbGUgcmVmcmVzaCB0b2tl bjogc2luY2UgdGhlIG9sZCB0b2tlbiB3b24ndCBiZQ0KaW52YWxpZGF0ZWQgdW50aWwgdGhlIG5l dyBvbmUgaXMgdXNlZCwgYSBjbGllbnQgY2FuIGNvbnRpbnVlIHRvIHVzZSB0aGUgb2xkDQp0b2tl biBpbmRlZmluaXRlbHkuDQoNCkFmdGVyIGh1cnJpZWQgY29udmVyc2F0aW9uLCB3ZSd2ZSBkZWNp ZGVkIHRoYXQgd2Ugd2lsbCBhbGxvdyBtb2JpbGUgY2xpZW50cw0KdG8gdXNlIGEgbG9uZy1saXZl ZCByZWZyZXNoIHRva2VuIHRoYXQgZG9lcyBub3QgZXhwaXJlIG9uIGVhY2ggcmVxdWVzdC4NClRo aXMgaXNuJ3Qgb3VyIHByZWZlcnJlZCBvcHRpb24sIHNpbmNlIHdlIGhhdmUgbm8gd2F5IG9mIGRl dGVjdGluZyBhDQpjb21wcm9taXNlZCBSVCwgYnV0IGluIG9yZGVyIHRvIG9idGFpbiB0aGUgUlQg YW4gYXR0YWNrZXIgbXVzdCBlaXRoZXINCg0KYSkgSW50ZXJjZXB0IHRoZSB0b2tlbiBpbi1mbGln aHQgYnkgYSBNSVRNIGF0dGFjayBvdmVyIFNTTCwgd2hpY2ggaXMNCm5vbi10cml2aWFsLCBvcg0K YikgT2J0YWluIHBoeXNpY2FsIGFjY2VzcyB0byB0aGUgY2xpZW50IGRldmljZSwgaW4gd2hpY2gg Y2FzZSBpdCdzIGdhbWUNCm92ZXIgYW55d2F5Lg0KDQpXZSdsbCBwcm9iYWJseSByZXZpc2l0IHRo aXMgZGVjaXNpb24gd2hlbiB3ZSBjb21lIHRvIGRvIGFub3RoZXIgcm91bmQgb2YNCndvcmsgb24g YXV0aGVudGljYXRpb24sIGJ1dCBmb3Igbm93IHRoaXMgc29sdmVzIGEgdXNlci1leHBlcmllbmNl IGlzc3VlDQp0aGF0IHdlJ3JlIHNlZWluZyBpbiB0aGUgd2lsZCwgd2l0aG91dCBzZXJpb3VzbHkg YWZmZWN0aW5nIHJlYWwtd29ybGQNCnNlY3VyaXR5Lg0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVu dHMsIEknbGwgbGV0IHlvdSBrbm93IGlmIHdlIGZpbmQgYSB3YXkgdG8gZGUtbWVzc2lmeQ0KdGhl IHR3by10b2tlbiBzb2x1dGlvbi4NCg0KWW91cnMsDQoNCg0KwqAtLSBCb2IuDQoNCg0KT24gVHVl LCBOb3YgMjcsIDIwMTIgYXQgMzoyMiBBTSwgU2hhbmUgQiBXZWVkZW4gPHN3ZWVkZW5AYXUxLmli bS5jb20+DQp3cm90ZToNCiAgTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGl0IGlzIGNvbnNpZGVy ZWQgYSBiZXN0IHByYWN0aWNlIHRvIHJvbGxvdmVyIGENCiAgcmVmcmVzaCB0b2tlbiBvbiBlYWNo IHVzZSAtIHRoYXQgaXMgd2hlbiBhIHJlZnJlc2ggdG9rZW4gaXMgdXNlZCwgYm90aCBhDQogIG5l dyBhY2Nlc3MgdG9rZW4gYW5kIGEgbmV3IHJlZnJlc2ggdG9rZW4gYXJlIGlzc3VlZCwgYW5kIHRo ZSBvbGQgcmVmcmVzaA0KICB0b2tlbiBpcyByZXZva2VkLg0KDQogIFRoZSBwcmltYXJ5IHJlYXNv biBJIGhhdmUgc2VlbiBjaXRlZCBmb3IgdGhpcyBpcyBpdCB3b3VsZCBhbGxvdyBmb3IgdGhlDQog IGRldGVjdGlvbiBvZiBhIGNvbXByb21pc2VkIHJlZnJlc2ggdG9rZW4gKGNsb25lZCBjbGllbnQg Zm9yIGV4YW1wbGUpLiBJZg0KICB0aGUgbGVnaXRpbWF0ZSBjbGllbnQgaXMgbm90IHRoZSBmaXJz dCB0byB1c2UgdGhlaXIgcmVmcmVzaCB0b2tlbiBpdCB3aWxsDQogIGZhaWwgd2hlbiB0aGV5IGRv IGV2ZW50dWFsbHkgdHJ5IHRvIHVzZSBpdC4gVGhlIGxpa2VsaWhvb2Qgb2Ygc3VjaCBhDQogIHNj ZW5hcmlvIG9yIG90aGVyIGltcGxpY2F0aW9ucyBvZiBhIGxvc3QgcmVmcmVzaCB0b2tlbiBpcyBh IGRpZmZlcmVudA0KICBkZWJhdGUuDQoNCiAgSWRlYWxseSB0aGUgdGltZW91dHMgb24gdGhlIG1l c3NhZ2VzIGFuZCB0aGUgdHJhbnNwb3J0IHVzZWQgZm9yIHRoZQ0KICByZWZyZXNoDQogIHRva2Vu IGV4Y2hhbmdlIHNob3VsZCBiZSAicmVsaWFibGUiLiBJZiB0aGF0IGlzIG5vdCB0aGUgY2FzZSB0 aGVuIGENCiAgbWVjaGFuaXNtIHN1Y2ggYXMgc3VnZ2VzdGVkIGJ5IEJyaWFuIGlzIHBvc3NpYmxl LCBidXQgdWx0aW1hdGVseSBub3QgdmVyeQ0KICBjbGVhbiBhcyBpdCBtZWFucyB5b3UgcmVhbGx5 IG5lZWQgdG8gbWFpbnRhaW4gYXQgbGVhc3QgdHdvIHZhbGlkIHJlZnJlc2gNCiAgdG9rZW5zIGNv bmN1cnJlbnRseSBwZXIgaW5pdGlhbCBncmFudCBhbmQgaXQgZ2V0cyBtZXNzeS4gRm9yIGV4YW1w bGUNCiAgZXh0ZW5kaW5nIEJyaWFuJ3Mgc2NlbmFyaW8sIHdoYXQgd291bGQgeW91IGRvIGluIHJl c3BvbnNlIHRvICM0PyBSZXR1cm4NCiAgdGhlDQogIHNhbWUgcmVmcmVzaCB0b2tlbiBhcyAjMj8g UmV0dXJuIGEgbmV3IG9uZSBhbmQgaW52YWxpZGF0ZSB0aGUgb25lDQogIHJldHVybmVkDQogIGlu IHJlc3BvbnNlICMyPyBGcm9tIGEgc2VydmVyLXNpZGUgcGVyc3BlY3RpdmUgeW91IGRvbid0IHJl YWxseSBrbm93IHdoYXQNCiAgdGhlICJyaWdodCIgdGhpbmcgdG8gZG8gaXMgYXMgeW91IGRvbid0 IGtub3cgdGhlIHRydWUgc3RhdGUgb2YgdGhlDQogIGNsaWVudC4NCg0KICBJIHdvdWxkIGJlIGlu Y2xpbmVkIHRvIG9wdG9taXNlIGZvciB0aGUgbm9ybWFsIGNhc2UgYW5kIHByb3ZpZGVkIHRoZQ0K ICBlcnJvcg0KICByYXRlIHdhc24ndCB0b28gaGlnaCBzaW1wbHkgcmVxdWlyZSBhIG5ldyBpbml0 aWFsIGdyYW50IHdoZW4gdGhlIGFwcCdzDQogIHJlZnJlc2ggdG9rZW4gZ2V0cyBvdXQgb2Ygc3lu Yy4NCiAgSWYgdGhlIGVycm9yIHJhdGUgaXMgdmVyeSBoaWdoIHRoZW4gSSB3b3VsZCBjb25zaWRl ciBhDQogIG5vbi1PQXV0aC1zdGFuZGFyZHMtYmFzZWQgbW9yZSByZWxpYWJsZSB0cmFuc3BvcnQg bWVjaGFuaXNtIGZvciByZWZyZXNoDQogIHRva2VuIGZsb3dzIGZyb20gdGhlIG1vYmlsZSwgcGVy aGFwcyB3aXRoIGEgdHJ1c3RlZCBwaWVjZSBvZiBpbnRlcm1lZGlhcnkNCiAgaW5mcmFzdHJ1Y3R1 cmUgdG8gaW50ZXJmYWNlIHdpdGggdGhlIHJlYWwgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdXNpbmcg YQ0KICBzdGFuZGFyZCBmbG93Lg0KDQogIFJlZ2FyZHMsDQogIFNoYW5lLg0KDQoNCg0KICBGcm9t OiDCoCBUaW0gQnJheSA8dHdicmF5QGdvb2dsZS5jb20+DQogIFRvOiDCoCDCoCBCcmlhbiBFYXRv biA8YmVhdG9uQGdvb2dsZS5jb20+DQogIENjOiDCoCDCoCBPQXV0aCBXRyA8b2F1dGhAaWV0Zi5v cmc+LCBCb2IgR3JlZ29yeSA8cGF0aG9nZW5peEBnbWFpbC5jb20+DQogIERhdGU6IMKgIDI3LzEx LzIwMTIgMTI6NTMgUE0NCiAgU3ViamVjdDogwqAgwqAgwqAgwqBSZTogW09BVVRILVdHXSBUb2tl biByZWZyZXNoIGFuZCBUaGUgVHdvIEdlbmVyYWxzDQogIFNlbnQgYnk6IMKgIMKgIMKgIMKgb2F1 dGgtYm91bmNlc0BpZXRmLm9yZw0KDQoNCg0KICBBcyBJIHJlYWQgYmFjayB0aHJvdWdoIHRoaXMg b25lIEnigJltIG5vdCBnZXR0aW5nIHdoeSB5b3UgbmVlZCBhIG5ldw0KICByZWZyZXNoDQogIHRv a2VuLiDCoFdoYXQgYW0gSSBtaXNzaW5nPyDCoC1UDQoNCiAgT24gTW9uLCBOb3YgMjYsIDIwMTIg YXQgNjoyNyBQTSwgQnJpYW4gRWF0b24gPGJlYXRvbkBnb29nbGUuY29tPiB3cm90ZToNCiAgwqAg T24gRnJpLCBOb3YgMjMsIDIwMTIgYXQgNDo0MyBBTSwgQm9iIEdyZWdvcnkgPHBhdGhvZ2VuaXhA Z21haWwuY29tPg0KICDCoCB3cm90ZToNCiAgwqAgwqBXZSd2ZSBoYWQgT0F1dGgyIHJ1bm5pbmcg c3VjY2Vzc2Z1bGx5IGZvciBhIHdoaWxlIG5vdywgYnV0IHdlJ3JlDQogIGZpbmRpbmcNCiAgwqAg wqB0aGF0IG1vYmlsZSBhcHBsaWNhdGlvbnMgaGF2ZSBmcmVxdWVudCBwcm9ibGVtcyB3aXRoIHRo ZSByZWZyZXNoIGZsb3cNCiAgwqAgwqB3aGVyZSBhIHJlZnJlc2ggcmVxdWVzdCBpcyBtYWRlLCBi dXQgdGhlIG5ldHdvcmsgY29ubmVjdGlvbiBmYWlscw0KICBiZWZvcmUNCiAgwqAgwqB0aGUgbmV3 IEFUL1JUIHBhaXIgaXMgcmVjZWl2ZWQsIGxlYWRpbmcgdG8gYSAibG9zdCBncmFudCIuDQoNCiAg wqAgwqBJbiBzZXJ2ZXItbG9ncyB3ZSBjYW4gc2VlIHRoYXQgdGhlIHRva2VuIGhhcyBiZWVuIHJl ZnJlc2hlZCwgYW5kIGEgbmV3DQogIMKgIMKgUlQgaXNzdWVkLCBidXQgdGhlIGNsaWVudCBpcyBz dHVjayB3aXRoIHRoZSBvbGQgaW52YWxpZGF0ZWQgUlQuDQoNCiAgwqAgwqBUaGlzIHByb2JsZW0g aGFzIGJlZW4gcmVwb3J0ZWQgYnkgdHdvIHNlcGFyYXRlIGNsaWVudCBhcHBsaWNhdGlvbnMsDQog IGJvdGgNCiAgwqAgwqBvZiB3aG9tIGFyZSB1c2luZyBhIHJldHJ5LW1lY2hhbmlzbSBmb3IgQVBJ IHJlcXVlc3RzIHNpbmNlIHRoZXkgZXhwZWN0DQogIMKgIMKgYW4gdW5yZWxpYWJsZSBuZXR3b3Jr IGNvbm5lY3Rpb24uDQoNCiAgwqAgwqBEb2VzIGFueWJvZHkgaGF2ZSBhbnkgZ3VpZGFuY2Ugb24g dGhpcyBpc3N1ZSwgb3IgaXMgdGhlcmUgYW55IHdvcmsgaW4NCiAgYW4NCiAgwqAgwqBleHRlbnNp b24gdG8gYWRkcmVzcyB0aGUgaXNzdWUgb2YgbG9zdCBncmFudHMgZm9yIHRva2VuIHJlZnJlc2hl cz8NCg0KICDCoCBIYXZlIHlvdSBjb25zaWRlcmVkIG5vdCByZXZva2luZyB0aGUgb2xkIFJUIHVu dGlsIHRoZSBuZXcgUlQgaGFzIGJlZW4NCiAgwqAgc3VjY2Vzc2Z1bGx5IHVzZWQ/DQoNCiAgwqAg WW91IG1pZ2h0IGFsc28gbmVlZCB0byBjb25zaWRlciB3aGF0IGhhcHBlbnMgd2l0aCByZXF1ZXN0 cyB0aGF0IGFyZQ0KICDCoCBpbi1mbGlnaHQgYXQgdGhlIHRpbWUgdGhlIG9sZCBSVCBpcyByZXZv a2VkLiDCoEZvciBleGFtcGxlOg0KDQogIMKgIDEpIGNsaWVudCBzdGFydHMgdG9rZW4gZXhjaGFu Z2UsIGhhbmdzIGZvciBzb21lIHJlYXNvbi4NCiAgwqAgMikgY2xpZW50IHN0YXJ0cyB0b2tlbiBl eGNoYW5nZSwgc3VjY2VlZHMsIHJlY2VpdmVzIG5ldyByZWZyZXNoIHRva2VuDQogIMKgIDMpIGNs aWVudCB1c2VzIG5ldyByZWZyZXNoIHRva2VuDQogIMKgIDQpIHJlcXVlc3QgMSBjb21wbGV0ZXMN Cg0KICDCoCBUaGF0IGNvdWxkIGFsbCBoYXBwZW4gaW4gdGhlIHNwYWNlIG9mIGEgc2Vjb25kIG9y IHR3by4gwqBTbyB5b3UgbWlnaHQNCiAgd2FudA0KICDCoCB0byB0aGluayBhYm91dCBub3QgcmV2 b2tpbmcgdGhlIG9sZCB0b2tlbiB1bnRpbCB5b3Ugc2VlIHRoZSBuZXcgcmVmcmVzaA0KICDCoCB0 b2tlbiB1c2VkIGFuZCBhIGJpdCBvZiB0aW1lIGhhcyBwYXNzZWQuDQoNCiAgwqAgQ2hlZXJzLA0K ICDCoCBCcmlhbg0KDQogIMKgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogIMKgIE9BdXRoIG1haWxpbmcgbGlzdA0KICDCoCBPQXV0aEBpZXRmLm9yZw0K ICDCoCBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCiAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgT0F1dGggbWFp bGluZyBsaXN0DQogIE9BdXRoQGlldGYub3JnDQogIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpRLiBIb3cgbWFueSBtZW1iZXJzIG9mIGEgZGVt b2dyYXBoaWMgZ3JvdXAgZG9lcyBpdCB0YWtlIHRvIHBlcmZvcm0gYQ0Kc3BlY2lmaWVkIHRhc2s/ DQoNCkEuIEEgZmluaXRlIG51bWJlcjsgb25lIHRvIHBlcmZvcm0gdGhlIHRhc2ssIGFuZCB0aGUg cmVtYWluZGVyIHRvIGFjdCBpbiBhDQptYW5uZXIgc3RlcmVvdHlwaWNhbCBvZiB0aGUgZ3JvdXAg aW4gcXVlc3Rpb24uDQo= From wmills_92105@yahoo.com Tue Nov 27 13:24:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D6921F8468 for ; Tue, 27 Nov 2012 13:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFbHnMxb+wZk for ; Tue, 27 Nov 2012 13:24:43 -0800 (PST) Received: from nm22-vm0.bullet.mail.bf1.yahoo.com (nm22-vm0.bullet.mail.bf1.yahoo.com [98.139.212.126]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA8021F889E for ; Tue, 27 Nov 2012 13:24:42 -0800 (PST) Received: from [98.139.212.146] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 27 Nov 2012 21:24:42 -0000 Received: from [98.139.212.195] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 27 Nov 2012 21:24:42 -0000 Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 27 Nov 2012 21:24:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 494145.18177.bm@omp1004.mail.bf1.yahoo.com Received: (qmail 1138 invoked by uid 60001); 27 Nov 2012 21:24:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354051481; bh=/jXzpuVEj0pY91Fqv8m993s0ZI+S2vJ2bweSkhlo/1c=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GTEPTFH16Ycw/YC9d1OEAjIBTePSfFTO8bSfJ50WAoc66Z9NayjQsMNWfQnAPWwrvfGRuSgObIhXuaVpgumwqaoO+qZVAlmF/jBYA3mSl5xGhUhF2pHg1otDYfVpYx95Dc2RUjCZ/M1xckh0xgh7bzVn2zG+RsgbGIi4xDCqDl8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OFUrk2N/9ndavPg6RVsldQ4bP4lCk9rXO3zBDqzCaIf1GIiAA+WrNbi38FH4MtMuAWGqwyzqQOSF3BoL9RznoM5KL5+vG2zunTakzxF2aSKIWSfiH6dAel5AteSQmjB+NgsVmxrGsAAyKYR36g4Q99+Rh0bgMdTn7URNjatWwac=; X-YMail-OSG: 3kBIqjUVM1ka9XUdEd_ksQtRZ78xThSVOaci7N8CaQCwXhm spbiRka32LCFH8J_RPbFKbGkbLSiPtKuzrDLz8wevehRKik1FskSJT7TK8Bm BZ7lOdzLG_aPACFDTVHpoOivwM33wwifbwuBr4bO5V1ZEK_zG5xn0nghd3ot o47lko2kCVxqmvq03pVUji43x2.weKuS43pSYk0qg3nvOaDoS5F4OolRxLG9 sU9pXDzkR7oshWBwAmY.K7gipC_C9HXGYcAB98obxAMDMLAEHrv467uZbsPP XgFtEITVh5R.ibbrYhNfiVplVrvrBdOTnxnyZKv6LoY3awv0Z1SRaDe3KcyQ RZKvVERINzZp1wJCUSYgY8axCvk8M8EUPRQi827GcL8Y2H_eHuOTbReKhbqr .rER4wc5Fyk70gZLdKYEPIJi60qxtg2M2MAxupATrzQRh2WhvECD2BW4BZ5R PgovxrotejSPFEffjHRS43k.qvhAqXuw3UmoQkMruzfnEOWggtJJ.uptqMLP htp2DbO2GXbRiasAAazdgdecaSonIUmJ1ryA.bLtq2PU- Received: from [209.131.62.113] by web31816.mail.mud.yahoo.com via HTTP; Tue, 27 Nov 2012 13:24:41 PST X-Rocket-MIMEInfo: 001.001, UmVzcG9uc2VzIGlubGluZS4KCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo.RnJvbTogSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ.Cj5UbzogV2lsbGlhbSBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4gCj5DYzogSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ.OyAiVHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykiIDxoYW5uZXMudHNjaG9mZW5pZ0Buc24uY29tPjsgZXh0IFNlcmdleSA.QmVyeW96a2kBMAEBAQE- X-Mailer: YahooMailWebService/0.8.127.475 References: <50B3B1B3.50502@gmail.com><6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> <50B4A2AC.6010904@gmail.com> <999913AB42CC9341B05A99BBF358718D022492FA@FIESEXC035.nsn-intra.net> <1354037569.35121.YahooMailNeo@web31813.mail.mud.yahoo.com> <8D3D9321-EB03-4A00-B981-C197DAD0A408@gmx.net> Message-ID: <1354051481.67764.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Tue, 27 Nov 2012 13:24:41 -0800 (PST) From: William Mills To: Hannes Tschofenig In-Reply-To: <8D3D9321-EB03-4A00-B981-C197DAD0A408@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-516886218-1354051481=:67764" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 21:24:45 -0000 ---1238014912-516886218-1354051481=:67764 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Responses inline.=0A=0A>________________________________=0A>From: Hannes Ts= chofenig =0A>To: William Mills =0A>Cc: Hannes Tschofenig ; "Tschofenig,= Hannes (NSN - FI/Espoo)" ; ext Sergey >Beryozki= n ; "oauth@ietf.org" =0A>Sent: Tuesd= ay, November 27, 2012 10:54 AM=0A>Subject: Re: [OAUTH-WG] What needs to be = done to complete MAC.=0A>=0A>Hi Bill, =0A>=0A>On Nov 27, 2012, at 7:32 PM, = William Mills wrote:=0A>=0A>> I don't see in that document a significant us= e case for a signed token, which is use over clear text channels.=0A>=0A>Wi= th "that document" I guess you refer to http://tools.ietf.org/html/draft-ts= chofenig-oauth-security-00?=A0=0A=0AYes.=0A=0A>=0A>With "signed token" do y= ou mean an access token that is signed by the party issuing it?=A0=0A=0ANo,= I meant a token which requires a signature in the transaction to be used.= =0A=0A>=0A>>=A0 Bearer tokens have similar security properties to HTTP cook= ies (minus for the moment the XSRF problem).=0A>=0A>Please don't compare be= arer tokens with cookies. They are very different.=A0=0A=0AFor the purposes= of this discussion I disagree strongly. =A0Both are a piece of data transm= itted by the client to the server. Cookies can be used for other things but= there are certainly authentication cookies in use which have all of the sa= me characteristics as Bearer tokens and in fact could be used interchangeab= ly.=0A=0A>=0A>> =A0Signed token types can be used over plain text channels = without the concern about re-use of the token=A0=0A>>by a 3rd party.=A0 Rep= lay protection is still needed but that's not in scope for the token mechan= ism itself.=0A>=0A>I guess signed token here means something like MAC where= you actually do not sign the token but compute a=A0=0A>message digest over= some headers of the request.=A0=0A=0AYes, I could have been clearer, signe= d per access like MAC and OAuth 1.0=0A=0A>> =0A>> It's always been this sim= ple use case that has been my focus for MAC.=0A>Could you describe your sim= ple use case? For example, is it acceptable for you to use TLS from the cli= ent=A0=0A>to the authorization server to get the MAC key (and algorithm)? W= hat is your story regarding computing the=A0=0A>keyed message digest over t= he HTTP message: header fields only, body? What about confidentiality prote= ction?=A0=0A>What about protecting the actual data (not just the request th= at contains the access token)?=0A>=0A=0AThe simple use case is TLS for the = authentication and token fetch flows and plain text for everything else. = =A0At the moment for the Flickr case there's no signature over the post bod= y. =A0The concerns about confidentiality and integrity protection of the po= st body in bulk traffic are valid. =A0=0A=0A>>=A0=0A>> Flickr uses OAuth 1.= 0a today over HTTP and will for many years to come, we won't be able to go = completely SSL due to the installed base of clients.=0A>=0A>If that's the c= ase and they only use HTTP then they are in violation of the OAuth 1.0a spe= c.=A0=0A=0AFlickr uses TLS to do the OAuth 1.0a flows as per the spec. =A0A= ll regular application traffic using the tokens for access is HTTP.=0A=0A>= =0A>>=A0 Given the dynamic I see in the mobile development community I don'= t see us getting all mobile apps into SSL only anytime soon.=0A>=0A>What ma= kes you believe that guys who don't want to use an off-the-shelf library fo= r security will get a=A0=0A>custom security solution right. =A0The performa= nce of TLS is not an issue for mobile devices anymore. It may=A0=0A>have be= en an issue in 2005.=A0=0A=0ABecause I get told this all the time by mobile= developers concerned about latency and battery usage because TLS is margin= ally more expensive than plain text. =A0Whether I agree with them or not, i= t's the feedback I get.=0A=0A>=0A>If they want to use OAuth 2.0 (as it is s= pecified today; irrespectively of the bearer token spec) they=A0=0A>have to= use TLS in their code base.=A0=0A=0AYes. =A0Authentication and token fetch= via SSL are not the issue, it's the bulk traffic.=0A=0A>=0A>> =A0MAC and O= Auth 1.0 solve the token security problem for the last hop to the phone/wi-= fi device without SSL for the bulk of the application traffic.=0A>The IETF = OAuth 1.0a specification requires TLS to be used between the client and the= authorization server.=A0=0A=0ASure. =A0Where did I say differently?=0A=0A>= =0A>Ciao=0A>Hannes=0A>=0A>> -bill=0A>>=A0=0A>>=0A=A0=0A> From: "Tschofenig,= Hannes (NSN - FI/Espoo)" =0A> To: ext Sergey Be= ryozkin ; Hannes Tschofenig =0A> Cc: oauth@ietf.org =0A> Sent: Tuesday, November 27, 2012 4:33 AM=0A= > Subject: Re: [OAUTH-WG] What needs to be done to complete MAC=0A> =0A> Hi= Sergey, =0A> =0A> I believe we would make faster progress on security topi= cs if could=0A> focus on listing security requirements we have and what thr= eats we want=0A> to mitigate. The reason why we have not finished this topi= c is simply=0A> because everyone was just talking about specific (but incom= plete)=0A> solutions. You are unfortunately falling in the same trap as wel= l. =0A> =0A> If you really care about the topic then have a look at the men= tioned=0A> document and tell us whether the requirements are complete. =0A>= Reading through the document you will notice that there a few more=0A> con= siderations to pay attention to than just the few listed below. =0A> =0A> C= iao=0A> Hannes=0A> =0A> =0A> > -----Original Message-----=0A> > From: oauth= -bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=0A> > Of ext Se= rgey Beryozkin=0A> > Sent: Tuesday, November 27, 2012 1:23 PM=0A> > To: Han= nes Tschofenig=0A> > Cc: =0A> > Subject: Re: [OAUTH-WG] Wha= t needs to be done to complete MAC=0A> > =0A> > Hi Hannes=0A> > On 26/11/12= 19:01, Hannes Tschofenig wrote:=0A> > > Hi Sergey,=0A> > >=0A> > > as Phil= said it would be helpful for us to receive reviews of this=0A> > document:= =0A> > > http://tools.ietf.org/html/draft-tschofenig-oauth-security-00=0A> = > >=0A> > > The document lists requirements and threats.=0A> > =0A> > =0A> = > Let me offer two possibly naive reasons why using MAC may help, one of=0A= > > them is related to the security, another to the ease of HOK support on= =0A> > the client=0A> > =0A> > 1. The most safe way to return MAC token to = the client is to use a=0A> > two-way TLS due to the mac key also returned t= o the client. Two-Way=0A> TLS=0A> > offers a stronger support for getting t= he client authenticated along=0A> the=0A> > way too=0A> > =0A> > 2. Assumin= g HOK confirmation matters at all (and I believe it does),=0A> > IMHO it is= much simpler for a basic client implementation to apply a=0A> MAC=0A> > si= gnature algo and thus work with the OAuth2 servers expecting HOK=0A> > conf= irmations=0A> > =0A> > One more reason is more about facilitating the furth= er migration to=0A> 2.0=0A> > which I tried to outline in my response to Ph= il Hunt=0A> > =0A> > Thanks, Sergey=0A> > =0A> > >=0A> > > Ciao=0A> > > Han= nes=0A> > >=0A> > > On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote:=0A> > >= =0A> > >> If we want to get this done we have to get agreements on the=0A> = > requirements for HOK. Several meetings ago (quebec) the group=0A> indicat= ed=0A> > that mac wasn't appropriate to anyone's needs.=0A> > >>=0A> > >> S= ome would argue that OAuth1 users arguably have less security than=0A> > th= e simpler bearer token /tls model in OAuth2. This just shows the=0A> real= =0A> > issue of demonstrated need has not been properly defined and=0A> und= erstood.=0A> > >>=0A> > >> More dialog on use cases is very helpful to movi= ng HOK/MAC/etc=0A> > forward.=0A> > >>=0A> > >> Phil=0A> > >>=0A> > >> On 2= 012-11-26, at 10:15, Sergey Beryozkin=0A> > wrote:=0A= > > >>=0A> > >>> Hi=0A> > >>>=0A> > >>> What needs to be done to complete t= he MAC token spec ? Without=0A> > having it signed off it will be difficult= to get people working with=0A> > OAuth 1.0 convinced to move to 2.0.=0A> >= >>> I'm seeing another user request for getting OAuth 1.0 support=0A> > ex= tended further because the user expects it is more secure, and I=0A> guess= =0A> > because it is proven to work for people, and I guess because many=0A= > OAuth=0A> > 1.0 users feel that should stay from OAuth 2.0 because of som= e bad=0A> press.=0A> > >>>=0A> > >>> Without MAC being completed the divisi= on will continue, with even=0A> > more misleading anti-OAuth2 posts appeari= ng (though I guess some of=0A> the=0A> > better posts point to some level o= f complexity in 2.0).=0A> > >>>=0A> > >>> Is it a matter of a security expe= rt validating the text, fixing=0A> few=0A> > typos, and basically signing i= t off ?=0A> > >>>=0A> > >>> If someone is interested then I can provide the= info offline on=0A> how=0A> > it MAC supported in our framework to get thi= ngs tested easily and=0A> such...=0A> > >>>=0A> > >>> Cheers, Sergey=0A> > = >>>=0A> > >>> _______________________________________________=0A> > >>> OAu= th mailing list=0A> > >>> OAuth@ietf.org=0A> > >>> https://www.ietf.org/mai= lman/listinfo/oauth=0A> > >> ______________________________________________= _=0A> > >> OAuth mailing list=0A> > >> OAuth@ietf.org=0A> > >> https://www.= ietf.org/mailman/listinfo/oauth=0A> > >=0A> > =0A> > ______________________= _________________________=0A> > OAuth mailing list=0A> > OAuth@ietf.org=0A>= > https://www.ietf.org/mailman/listinfo/oauth=0A> ________________________= _______________________=0A> OAuth mailing list=0A> OAuth@ietf.org=0A> https= ://www.ietf.org/mailman/listinfo/oauth=0A> =0A> ---1238014912-516886218-1354051481=:67764 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Responses inline.

>________________________________
>From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
&g= t;To: William Mills <wmills_92105@yahoo.com>
>Cc: Hannes Tscho= fenig <hannes.tschofenig@gmx.net>; "Tschofenig, Hannes (NSN - FI/Espo= o)" <hannes.tschofenig@nsn.com>; ext Sergey >Beryozkin <sberyozkin@gmail.com>; "oauth@ietf.org" <oauth@ietf.org>
= >Sent: Tuesday, November 27, 2012 10:54 AM
>Subject: Re: [OAUTH-WG= ] What needs to be done to complete MAC.
>
>Hi Bill,
>>On Nov 27, 2012, at 7:32 PM, William Mills wrote:
>
>>= I don't see in that document a significant use case for a signed token, wh= ich is use over clear text channels.
>
>With "that document" I = guess you refer to http://tools.ietf.org/html/draft-tschof= enig-oauth-security-00? 

Yes.

>
>With = "signed token" do you mean an access token that is signed by the party issu= ing it? 

No= , I meant a token which requires a signature in the transaction to be used.=

>
>>  Bearer tokens have similar security properties to HTTP cookies (minus for the moment the XSRF= problem).
>
>Please don't compare bearer tokens with cookies. = They are very different. 

For the purposes of this discussion I disagree strongly. &nb= sp;Both are a piece of data transmitted by the client to the server. Cookie= s can be used for other things but there are certainly authentication cooki= es in use which have all of the same characteristics as Bearer tokens and i= n fact could be used interchangeably.

>
>>  Signed token types can be used over plain text = channels without the concern about re-use of the token 
>>by a 3rd party.  Replay protection is still neede= d but that's not in scope for the token mechanism itself.
>
>I = guess signed token here means something like MAC where you actually do not = sign the token but compute a 
>message d= igest over some headers of the request. 

Yes, I could have been clearer, signed per= access like MAC and OAuth 1.0

>>
= >> It's always been this simple use case that has been my focus for M= AC.
>Could you describe your simple use case? For example, is it acce= ptable for you to use TLS from the client 
= >to the authorization server to get the MAC key (and algorithm)? What is your story regarding computing the 
>= ;keyed message digest over the HTTP message: header fields only, body? What= about confidentiality protection? 
>Wha= t about protecting the actual data (not just the request that contains the = access token)?
>

The simple use case is TLS for the authentication and token fetch= flows and plain text for everything else.  At the moment for the Flic= kr case there's no signature over the post body.  The concerns about c= onfidentiality and integrity protection of the post body in bulk traffic ar= e valid.  

>> 
>> F= lickr uses OAuth 1.0a today over HTTP and will for many years to come, we w= on't be able to go completely SSL due to the installed base of clients.
= >
>If that's the case and they only use HTTP then they are in viol= ation of the OAuth 1.0a spec. 

Flickr uses TLS to do the OAuth 1= .0a flows as per the spec.  All regular application traffic using the = tokens for access is HTTP.

>
>>  Given the dynamic I see in the mobile de= velopment community I don't see us getting all mobile apps into SSL only an= ytime soon.
>
>What makes you believe that guys who don't want = to use an off-the-shelf library for security will get a 
>custom security solution right.  The performance= of TLS is not an issue for mobile devices anymore. It may 
>have been an issue in 2005. 

Because I get told this all the time= by mobile developers concerned about latency and battery usage because TLS is marginally more expensive than plain text.  Whether I agree with t= hem or not, it's the feedback I get.

>>If they want to use OAuth 2.0 (as it is specified today; irrespectivel= y of the bearer token spec) they 
>have = to use TLS in their code base. 

<= div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: 'Courier Ne= w', courier, monaco, monospace, sans-serif; background-color: transparent; font-style: normal;">Yes.  Authentication and token fetch via SSL are= not the issue, it's the bulk traffic.

><= br>>>  MAC and OAuth 1.0 solve the token security problem for th= e last hop to the phone/wi-fi device without SSL for the bulk of the applic= ation traffic.
>The IETF OAuth 1.0a specification requires TLS to be = used between the client and the authorization server. 

Sure.  Where did I say differently?

>
>Ciao
>Hannes=
>
>> -bill
>> 
>>
 
> From: "Tschofenig, Hannes (NSN - FI/Espoo)" <han= nes.tschofenig@nsn.com>
> To: ext Sergey Beryozkin <sberyozkin@= gmail.com>; Hannes Tschofenig <hannes.tschofenig@gmx.net>
>= Cc: oauth@ietf.org
> Sent: Tuesday, November 27, 2012 4:33 AM
&g= t; Subject: Re: [OAUTH-WG] What needs to be done to complete MAC
> > Hi Sergey,
>
> I believe we would make faster progress= on security topics if could
> focus on listing security requirements we have and what threats we want
> to mitigate. The rea= son why we have not finished this topic is simply
> because everyone = was just talking about specific (but incomplete)
> solutions. You are= unfortunately falling in the same trap as well.
>
> If you r= eally care about the topic then have a look at the mentioned
> docume= nt and tell us whether the requirements are complete.
> Reading thro= ugh the document you will notice that there a few more
> consideratio= ns to pay attention to than just the few listed below.
>
> Ci= ao
> Hannes
>
>
> > -----Original Message-----=
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = On Behalf
> > Of ext Sergey Beryozkin
> > Sent: Tuesday, = November 27, 2012 1:23 PM
> > To: Hannes Tschofenig
> > C= c: <oauth@ietf.org>
> > Subject: Re: [OAUTH-WG] What needs to be done to complete MAC
> >
> > Hi Hannes
&= gt; > On 26/11/12 19:01, Hannes Tschofenig wrote:
> > > Hi S= ergey,
> > >
> > > as Phil said it would be helpful= for us to receive reviews of this
> > document:
> > >= http://tools.ietf.org/html/draft-tschofenig-oauth-securit= y-00
> > >
> > > The document lists requirement= s and threats.
> >
> >
> > Let me offer two po= ssibly naive reasons why using MAC may help, one of
> > them is re= lated to the security, another to the ease of HOK support on
> > t= he client
> >
> > 1. The most safe way to return MAC tok= en to the client is to use a
> > two-way TLS due to the mac key al= so returned to the client. Two-Way
> TLS
> > offers a stronger support for getting the client authenticated along
> the> > way too
> >
> > 2. Assuming HOK confirmation = matters at all (and I believe it does),
> > IMHO it is much simple= r for a basic client implementation to apply a
> MAC
> > sig= nature algo and thus work with the OAuth2 servers expecting HOK
> >= ; confirmations
> >
> > One more reason is more about fa= cilitating the further migration to
> 2.0
> > which I tried = to outline in my response to Phil Hunt
> >
> > Thanks, S= ergey
> >
> > >
> > > Ciao
> > &= gt; Hannes
> > >
> > > On Nov 26, 2012, at 8:28 PM,= Phil Hunt wrote:
> > >
> > >> If we want to get= this done we have to get agreements on the
> > requirements for H= OK. Several meetings ago (quebec) the group
> indicated
> > that mac wasn't appropriate to anyone's needs.
&= gt; > >>
> > >> Some would argue that OAuth1 users = arguably have less security than
> > the simpler bearer token /tls= model in OAuth2. This just shows the
> real
> > issue of de= monstrated need has not been properly defined and
> understood.
&g= t; > >>
> > >> More dialog on use cases is very hel= pful to moving HOK/MAC/etc
> > forward.
> > >>
&= gt; > >> Phil
> > >>
> > >> On 2012-= 11-26, at 10:15, Sergey Beryozkin<sberyozkin@gmail.com>
> > = wrote:
> > >>
> > >>> Hi
> > >= >>
> > >>> What needs to be done to complete the MA= C token spec ? Without
> > having it signed off it will be difficu= lt to get people working with
> > OAuth 1.0 convinced to move to 2.0.
> > >>> I'm seeing another user request for= getting OAuth 1.0 support
> > extended further because the user e= xpects it is more secure, and I
> guess
> > because it is pr= oven to work for people, and I guess because many
> OAuth
> >= ; 1.0 users feel that should stay from OAuth 2.0 because of some bad
>= ; press.
> > >>>
> > >>> Without MAC be= ing completed the division will continue, with even
> > more misle= ading anti-OAuth2 posts appearing (though I guess some of
> the
&g= t; > better posts point to some level of complexity in 2.0).
> >= ; >>>
> > >>> Is it a matter of a security exper= t validating the text, fixing
> few
> > typos, and basically= signing it off ?
> > >>>
> > >>> If so= meone is interested then I can provide the info offline on
> how
> > it MAC supported in our framework to get things tested ea= sily and
> such...
> > >>>
> > >>>= ; Cheers, Sergey
> > >>>
> > >>> ______= _________________________________________
> > >>> OAuth m= ailing list
> > >>> OAuth@ietf.org
> > >>&= gt; https://www.ietf.org/mailman/listinfo/oauth
> > >> __= _____________________________________________
> > >> OAuth m= ailing list
> > >> OAuth@ietf.org
> > >> https= ://www.ietf.org/mailman/listinfo/oauth
> > >
> > <= br>> > _______________________________________________
> > O= Auth mailing list
> > OAuth@ietf.org
> > htt= ps://www.ietf.org/mailman/listinfo/oauth
> ______________________= _________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>
---1238014912-516886218-1354051481=:67764-- From pathogenix@gmail.com Tue Nov 27 14:07:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858AD21F854A; Tue, 27 Nov 2012 14:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFw8hl4cPfcd; Tue, 27 Nov 2012 14:07:37 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 654AC21F849A; Tue, 27 Nov 2012 14:07:36 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so4275082wib.1 for ; Tue, 27 Nov 2012 14:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0AbBTIhimq/LU8Q3287mkwnxbhiLt6k/lp9mu3/HWFo=; b=zZ+QwDWazdq1W5wgtbFCgW/s1rIFsA42m0WGnxxQG8Xj7lg1ObaC96sPkeV5tgAfzg 5IKNZqpH8VmOkB0VOP2917SbDPK/vgO8yxZG4QEi399a2Rzy0XU+sSKbDddwK/CQnwET XhZ7gPG71M3YEnkbnfHVULCEQ3E9BwWK0Nqcc2xMyPJliA76P+87YM/4Wi3dY+/9nQgi LVViM1b/cR4RT2/yP22n2071Wmz9UVNn+lUoIbix3bcTpIBYMmPZaTqcqMYqutCNLTNQ rRdPBqFpVnQlfzYJuWTW36BnedogvC2k09wZyxGWLRhy0+uWX0SInXFW7qLHE1SN+AuW ZNmw== MIME-Version: 1.0 Received: by 10.180.93.69 with SMTP id cs5mr26008175wib.3.1354054055188; Tue, 27 Nov 2012 14:07:35 -0800 (PST) Received: by 10.194.25.202 with HTTP; Tue, 27 Nov 2012 14:07:35 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Nov 2012 22:07:35 +0000 Message-ID: From: Bob Gregory To: Brian Eaton Content-Type: multipart/alternative; boundary=f46d043892c7f75ae204cf81467d Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Token refresh and The Two Generals X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 22:07:37 -0000 --f46d043892c7f75ae204cf81467d Content-Type: text/plain; charset=ISO-8859-1 Actually, this is one of the approaches we've considered. This issue most commonly occurs when an end-user is moving from 3G to wi-fi, or from an active mobile connection to a zero-signal area. If we recycle refresh tokens less frequently (after, say, 24 hours) then the client application will be able to retry the refresh once their connection is reliable again, but we keep most of the advantage of refresh-token revocation. The trade-off is that it's more of a pain to build this way, and we're in an awful hurry :) -- Bob On Tue, Nov 27, 2012 at 8:10 PM, Brian Eaton wrote: > On Mon, Nov 26, 2012 at 7:22 PM, Shane B Weeden wrote: > >> My understanding is that it is considered a best practice to rollover a >> refresh token on each use - that is when a refresh token is used, both a >> new access token and a new refresh token are issued, and the old refresh >> token is revoked. >> > > FWIW, I think rotating the refresh token every time it is used is a bit > excessive, something time based (e.g. once every few weeks or few months) > would be fine as well. > > The trade-off is that things that happen rarely are more likely to trigger > bugs on the client side. =) > -- Q. How many members of a demographic group does it take to perform a specified task? A. A finite number; one to perform the task, and the remainder to act in a manner stereotypical of the group in question. --f46d043892c7f75ae204cf81467d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually, this is one of the approaches we've considered. This issue mo= st commonly occurs when an end-user is moving from 3G to wi-fi, or from an = active mobile connection to a zero-signal area.

If we re= cycle refresh tokens less frequently (after, say, 24 hours) then the client= application will be able to retry the refresh once their connection is rel= iable again, but we keep most of the advantage of refresh-token revocation.= The trade-off is that it's more of a pain to build this way, and we= 9;re in an awful hurry :)

-- Bob

<= br>
On Tue, Nov 27, 2012 at 8:10 PM, Brian Ea= ton <beaton@google.com> wrote:
On Mon, Nov 26, 2012 at 7:22 PM,= Shane B Weeden <sweeden@au1.ibm.com> wrote:
My understanding is that it is considered a best practice to rollove= r a
refresh token on each use - that is when a refresh token is used, both a new access token and a new refresh token are issued, and the old refresh token is revoked.

FWIW, I think r= otating the refresh token every time it is used is a bit excessive, somethi= ng time based (e.g. once every few weeks or few months) would be fine as we= ll.

The trade-off is that things that happen rarely are mor= e likely to trigger bugs on the client side. =3D)



--
Q. How many = members of a demographic group does it take to perform a specified task?
A. A finite number; one to perform the task, and the remai= nder to act in a manner stereotypical of the group in question.

--f46d043892c7f75ae204cf81467d-- From Jeff.Hodges@KingsMountain.com Tue Nov 27 14:23:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA5221F8758 for ; Tue, 27 Nov 2012 14:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypaZtz1kWJgs for ; Tue, 27 Nov 2012 14:23:19 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 56B3A21F8665 for ; Tue, 27 Nov 2012 14:23:19 -0800 (PST) Received: (qmail 32204 invoked by uid 0); 27 Nov 2012 22:22:55 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy11.bluehost.com with SMTP; 27 Nov 2012 22:22:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=b2f2C6VkcnWR7XzPPF01Jr3+7GpVjob0XMKOaswBoH8=; b=DrqYbWoKix6E7+UTRAqicixJbVotmj1xlJnrakbKH15WaCYCc+EwDbS3bDyIEaEcWoVQPcO5QYM6vaSwpf52alE439+q/8pZmb8LyYTAquXuStMngXb66o2m09T4fCVh; Received: from [24.4.122.173] (port=56712 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TdTYN-0004hJ-EJ for oauth@ietf.org; Tue, 27 Nov 2012 15:22:55 -0700 Message-ID: <50B53D3E.1000107@KingsMountain.com> Date: Tue, 27 Nov 2012 14:22:54 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: IETF oauth WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 22:23:20 -0000 Hi, at ietf-85 atlanta I agreed to do a review of draft-ietf-oauth-json-web-token-05, and so I have some thoughts below. Also, +1 to Hannes' comments. Overall the spec seems to get its idea across, but is pretty rough. Part of this is due to the language being convoluted, plus some concepts are only tacitly described (with clues scattered throughout the spec), and thus it is difficult to understand without multiple passes of this spec as well as [JWE] and [JWS]. For example, a JWT appears to be simply either a JWS or a JWE containing a JWT Claims Set, but this is not stated until right before section 3.1 (and it isn't stated that clearly). Immediately below are some overall comments, and then below that some detailed comments on various portions of the spec. I'm not addressing everything I noticed due to time constraints (apologies). HTH =JeffH ------ JWT terminology: Some issues seem to me to be caused by defining the JWT to be the base64url encoded JSON object itself and not having terminology to clearly refer to its unencoded form. For example, these two JSON objects together apparently comprise a (unencoded) JWT.. {"typ":"JWT", "alg":"HS256"} {"iss":"joe", "exp":1300819380, "http://example.com/is_root":true} ..but there's no defined way to refer to them given the spec's terminlogy. Consider terming the above a JWT and its encoded-string form an Encoded JWT, and define them separately. And then there'll be similar definitions for JWT Header and JWT Claims Set, e.g., Encoded JWT A JWT that has been encoded according to the process defined in Section X. Encoded JWT Header The encoded-string form of a JWT Header Encoded JWT Claims Set The encoded-string form of a JWT Claims Set encoded-string form The result of applying Base64url encoding to an input JSON text . JSON Web Token (JWT) A JWT comprises a JWT Header and a JWT Claims Set. ... JWT Header A JSON object that is a component of a JWT. It denotes the cryptographic operations applied to the JWT. ... JWT Claims Set A JSON object containing a set of claims. ... This also gets rid of the use of the "A string representing a JSON object..." which I find confusing and potentially misleading (because it is actually "a Base64url encoding of a JSON object"). UTF-8: UTF-8 is mentioned in lots of places. It could probably be stated once up near the beginning of the spec that all the JSON text is UTF-8 encoded, and all the JSON strings are UTF-8 encoded. Semantics, profiles and relationship to SAML: The spec does not define any overall JWT semantics (i.e., what any given JWT /means/). Semantics are only defined in context of each individual Reserved Claim Name. Thus any application of JWTs will need to profile the JWT spec: specifying the claim set(s) contents, and the overall semantics of the resultant JWT(s). This is not explicitly explained in the JWT spec. In terms of SAML, Appendix B should refer to SAML assertions rather than saml tokens. Also, I'm not sure SAML assertions inherently have more expressivity than JWTs. They do have more pre-defined structure and semantics. Syntactically, it seems one can encode pretty much anything in whatever amount in a JWT (one can do the same with SAML assertions), and thus theoretically JWTs could be used to accomplish the same things as SAML assertions. Semantically, SAML assertions are explicitly statements made by a system entity about a subject. But by default, a JWT is empty, and has no semantics (this isn't stated explicitly). All semantics defined in the JWT spec are particular to individual reserved claims, but all reserved claims are optional. Thus an application of JWTs to use cases also apropos for SAML assertions will require arguably more profiling than that needed to apply SAML assertions. The token size & complexity comparison seems nominally fine. Some detailed-but-rough comments and musings on portions of the spec as I was reading through it... > 2. Terminology terminology is not alphabetised! "claim", "claims", "token" should be defined in terminology suggestion: Claim: an assertion of something as a fact. Here, claims are name and value pairs, consisting of a Claim Name and a Claim Value. > JSON Web Token (JWT) is jwt always a "string" or is it string (only) when it's been serialized into one? > A string representing a set of claims as a JSON > object that is digitally signed or MACed and/or encrypted. is it more that it's a set of claims encoded as a JSON object that is string-serialized? is it /not/ a JWT by definition if it is not ((signed or unmac'd) and/or encrypted) ? No, because there are Plaintext JWTs, but they aren't in terminology (probably should be). "parts" in JWT definition is unclear are "parts" json objects or arrays unto themselves ? the definition assumes knowledge that's presented later. perhaps needs fwd reference(s), or perhaps better is to not present as much technical detail in the definitions. > JWT Claims Set similar comments as to JSON Web Token (JWT) the definition says how it is encoded and encrypted, but not how claims are mapped into a JSON object should probably be simply: JWT Claims Set: A set of claims expressed as a JSON object, where each claim is an object member (i.e., a name/value pair). A claim may have a JWT Claims Set as a value. > Claim Name The name of a member of the JSON object representing a > JWT Claims Set. should probably be simply: Claim Name The name portion of a claim, expressed as a JSON object member name. > Claim Value The value of a member of the JSON object representing a > JWT Claims Set. should probably be simply: Claim Value The value portion of a claim, expressed as a JSON object member value. > 3. JSON Web Token (JWT) Overview > The bytes of the UTF-8 representation of the JWT Claims Set are > digitally signed or MACed in the manner described in JSON Web > Signature (JWS) [JWS] and/or encrypted in the manner described in > JSON Web Encryption (JWE) [JWE]. s/ and/or encrypted / or encrypted and signed / > The contents of the JWT Header describe the cryptographic operations > applied to the JWT Claims Set. If the JWT Header is a JWS Header, the > claims are digitally signed or MACed. If the JWT Header is a JWE > Header, the claims are encrypted. What if a JWT is signed AND encrypted? Hm, from my looking at JWS and JWE specs, it seems that in that case one uses JWE because that encompasses both encrypt & sign. > A JWT is represented as a JWS or JWE. The number of parts is > dependent upon the representation of the resulting JWS or JWE. Does the above mean to say.. A JWT consists of a JWS or JWE object, which in turn conveys the JWT Claims Set. In the case of a JWS, the JWT Claims Set is the JWS Payload. In the case of a JWE, the JWT Claims Set is the input Plaintext. > 4. JWT Claims > > > The JWT Claims Set represents a JSON object whose members are the > claims conveyed by the JWT. The Claim Names within this object MUST > be unique; JWTs with duplicate Claim Names MUST be rejected. does the above mean to say claim names must be unique amongst the set of claim names within any given JWT Claims Set ? If so, that's only implied by the above but should be stated explicitly; as it is, the above is ambiguous. > 4.2. Public Claim Names > > > Claim names can be defined at will by those using JWTs. However, in s/Claim names/Public claim names/ > order to prevent collisions, any new claim name SHOULD either be > registered in the IANA JSON Web Token Claims registry Section 9.1 or > be a URI that contains a Collision Resistant Namespace. why should a claim name be a URI if I wish to make use of Collision Resistant Namespaces? For example, if I simply use say UUIDs as claim names.. {"iss":"joe", "3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"} ..it will be universally unique provided I minted it appropriately (no URI syntax is needed). > 4.3. Private Claim Names > > > A producer and consumer of a JWT may agree to any claim name that is > not a Reserved Name Section 4.1 or a Public Name Section 4.2. Unlike > Public Names, these private names are subject to collision and should > be used with caution. it seems private claim names are only subject to collision if the implementers don't make appropriate use of Collision Resistant Namespaces, i.e. they "can be" subject to collision. the above two sections use "public" and "private" as distinguishing factors, but it seems to me the distinguishing factor (given how the above is written) is more whether Collision Resistant Namespaces are employed or not. An implied aspect of public claim names seems to be that it is assumed that they are publicly listed/documented/leaked, thus the "public" moniker, and hence ought to be universally unique as a matter of course. and "private" ones seem to be assumed to be obfuscated to all but the agreeing parties? Or they are "private" in only the sense that they are created in the context of a private arrangement? > > 7. Rules for Creating and Validating a JWT > > > To create a JWT, one MUST perform these steps. The order of the > steps is not significant in cases where there are no dependencies > between the inputs and outputs of the steps. > > 1. Create a JWT Claims Set containing the desired claims. Note that > white space is explicitly allowed in the representation and no > canonicalization is performed before encoding. I presume the rationale for allowing white space is that JSON objects are unordered (and can contain arbitrary whitespace), thus simple buffer-to-buffer comparisons between serialized objects cannot be reliably performed. If so this should be explicitly stated. It seems that member/value-by-member/value comparisons must always be done, by parsing the JSON objects and extracting all members and values, this should be stated explicitly in the spec. I found meager jwt comparison instructions at the very end of Section 7. it should probably be its own subsection. It should probably explicitly say that JWTs need to be parsed into their constituent components, and the latter must be individually examined/compared. > Comparisons between JSON strings and other Unicode strings MUST be > performed as specified below: this comparison algorithm seems to be attempting to allow for comparison of UTF-8 encoded JSON strings with other unicode strings in any of the unicode encoding formats, but only implies that; it should be stated. > > 1. Remove any JSON applied escaping to produce an array of Unicode > code points. I don't think (1) is correct. A JSON string is by default encoded in UTF-8. A UTF-8 encoded string is not "an array of Unicode code points" (its a sequence of code units, which must be decoded into code points), i think a step is missing here.. 1. Remove any JSON escaping from the input JSON string. 1.a convert the string into a sequence of unicode code points. ..and then compare code point-by-code point. This overall algorithm /seems/ ok, but I'm not sure, it seems there's rationale that's not expressed, eg for excluding use of Unicode Normalization [USA15]. Also the alg is incomplete in that it doesn't stipulate converting the "other unicode string" into a sequence of code points. > 10. Security Considerations > > > All of the security issues faced by any cryptographic application > must be faced by a JWT/JWS/JWE/JWK agent. Among these issues are > protecting the user's private key, preventing various attacks, and > helping the user avoid mistakes such as inadvertently encrypting a > message for the wrong recipient. The entire list of security > considerations is beyond the scope of this document, but some > significant concerns are listed here. > > All the security considerations in the JWS specification also apply > to JWT, as do the JWE security considerations when encryption is > employed. In particular, the JWS JSON Security Considerations and > Unicode Comparison Security Considerations apply equally to the JWT > Claims Set in the same manner that they do to the JWS Header. > dunno if you can get away with sec cons wholly in other docs, and I'm not sure it's appropriate given that JWTs are a profile of JWE or JWS. above needs editorial polish -- there aren't any "significant concerns" actually listed here. --- end From internet-drafts@ietf.org Tue Nov 27 14:58:43 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B202521E8030; Tue, 27 Nov 2012 14:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z3RWd2xlk1l; Tue, 27 Nov 2012 14:58:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCD721E803C; Tue, 27 Nov 2012 14:58:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121127225843.31402.88773.idtracker@ietfa.amsl.com> Date: Tue, 27 Nov 2012 14:58:43 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 22:58:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : OAuth Dynamic Client Registration Protocol Author(s) : Justin Richer John Bradley Michael B. Jones Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-02.txt Pages : 19 Date : 2012-11-27 Abstract: This specification defines an endpoint and protocol for dynamic registration of OAuth Clients at an Authorizaiton Server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jricher@mitre.org Tue Nov 27 15:00:07 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9FC1F0C59 for ; Tue, 27 Nov 2012 15:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nIuCQkoy8Q8 for ; Tue, 27 Nov 2012 15:00:06 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BA3121F0425 for ; Tue, 27 Nov 2012 15:00:06 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1FDD553101D3 for ; Tue, 27 Nov 2012 18:00:06 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0DC3453101BA for ; Tue, 27 Nov 2012 18:00:06 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.132]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Tue, 27 Nov 2012 18:00:05 -0500 From: "Richer, Justin P." To: "oauth@ietf.org WG" Thread-Topic: New Version Notification for draft-ietf-oauth-dyn-reg-02.txt Thread-Index: AQHNzPLAKWhe06tAdkCNO6UBOa2Lxg== Date: Tue, 27 Nov 2012 23:00:05 +0000 Message-ID: References: <20121127225843.31402.11512.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.43.53] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E0684F820IMCMBX01MITREOR_" MIME-Version: 1.0 Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dyn-reg-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 23:00:07 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E0684F820IMCMBX01MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Updated dynamic registration draft, thanks to everyone for the comments so = far. Keep them coming, I think we've still got a little ways to go. -- Justin Begin forwarded message: From: > Subject: New Version Notification for draft-ietf-oauth-dyn-reg-02.txt Date: November 27, 2012 5:58:43 PM EST To: > Cc: >, >, > A new version of I-D, draft-ietf-oauth-dyn-reg-02.txt has been successfully submitted by Justin Richer and posted to the IETF repository. Filename: draft-ietf-oauth-dyn-reg Revision: 02 Title: OAuth Dynamic Client Registration Protocol Creation date: 2012-11-27 WG ID: oauth Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-ietf-oauth-dyn-r= eg-02.txt Status: http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg Htmlized: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-re= g-02 Abstract: This specification defines an endpoint and protocol for dynamic registration of OAuth Clients at an Authorizaiton Server. The IETF Secretariat --_000_B33BFB58CCC8BE4998958016839DE27E0684F820IMCMBX01MITREOR_ Content-Type: text/html; charset="us-ascii" Content-ID: <67A28774CF95B547B226C3D8BE4F7AD9@imc.mitre.org> Content-Transfer-Encoding: quoted-printable Updated dynamic registration draft, thanks to everyone for the comments so = far. Keep them coming, I think we've still got a little ways to go.

 -- Justin

Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Subject: Ne= w Version Notification for draft-ietf-oauth-dyn-reg-02.txt
Date: Novem= ber 27, 2012 5:58:43 PM EST
To: <<= a href=3D"mailto:jricher@mitre.org">jricher@mitre.org>
Cc: <<= a href=3D"mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com>, <mbj@microsoft.com>, <m.p.machulak@ncl.ac.uk>


A new version of I-D, draft-ietf-oauth-dyn-reg-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename: d= raft-ietf-oauth-dyn-reg
Revision: 0= 2
Title: OAuth Dynamic C= lient Registration Protocol
Creation date: 2012-11-27
WG ID: oauth
Number of pages: 19
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-ietf-oauth-dyn-reg-02.txt<= /a>
Status:          http://datatracker.= ietf.org/doc/draft-ietf-oauth-dyn-reg
Htmlized:        http://tools.ietf.org/html/draf= t-ietf-oauth-dyn-reg-02
Diff:            htt= p://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-02

Abstract:
  This specification defines an endpoint and protocol for dynamic=
  registration of OAuth Clients at an Authorizaiton Server.




The IETF Secretariat


--_000_B33BFB58CCC8BE4998958016839DE27E0684F820IMCMBX01MITREOR_-- From ve7jtb@ve7jtb.com Tue Nov 27 16:16:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A371F0C61 for ; Tue, 27 Nov 2012 16:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.829 X-Spam-Level: X-Spam-Status: No, score=-2.829 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03IrYrzJ9iFp for ; Tue, 27 Nov 2012 16:16:30 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C30921F0C5F for ; Tue, 27 Nov 2012 16:16:29 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so10141836qca.31 for ; Tue, 27 Nov 2012 16:16:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2hHcgVspGtAdOgS7Vk6m00NHx0E8yfKwUyPTVMripRw=; b=RyxX0QB/7C3hVrP7F3F/5jIucJaRXHAxWSrHxnEaKip3xfCll4G2MQfQhnPF9K7NDI F+VW3XLg6hyP8mVGbzdK6hWqiTAFGuGI77XYM+5SYe/DgsbqbHUKp7P8Dy4RtG2X6Zyf OE/AcsWAA9HPgjNHAeLPOa4nSIX/JXzHmvUgNQqR1eLWKHCF44tFQ8LowsSWNJ2hCNzM 11Abesd9TvjOCTF+dvFe4yDhaPAWCXTP1SEOO1lublCKwqIM33j982VSp4ZYvRK/5F4Z DKNLhQOnbht5X5jegVLLhxMUiBISs+OMdIT5deZyliY4mYjpYcUVRyYDcgLuOTA+9mVR qNLQ== Received: by 10.49.28.168 with SMTP id c8mr20339365qeh.62.1354061789196; Tue, 27 Nov 2012 16:16:29 -0800 (PST) Received: from [192.168.1.211] (190-20-43-7.baf.movistar.cl. [190.20.43.7]) by mx.google.com with ESMTPS id p11sm11578645qaz.16.2012.11.27.16.16.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 16:16:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <50B53D3E.1000107@KingsMountain.com> Date: Tue, 27 Nov 2012 21:16:17 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <29E8F56D-E929-4B62-BE59-7F9BBEC79D47@ve7jtb.com> References: <50B53D3E.1000107@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnNOB7tathAIm3VUnsxzHVbaAWXbN4eRAN0MZJikRDavESLi+ksA9+CHUtoslXXqJjec/A5 Cc: IETF oauth WG Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 00:16:31 -0000 Thanks for the close read and feedback. John B. On 2012-11-27, at 7:22 PM, =3DJeffH = wrote: > Hi, at ietf-85 atlanta I agreed to do a review of = draft-ietf-oauth-json-web-token-05, and so I have some thoughts below. = Also, +1 to Hannes' comments. >=20 > Overall the spec seems to get its idea across, but is pretty rough. = Part of this is due to the language being convoluted, plus some concepts = are only tacitly described (with clues scattered throughout the spec), = and thus it is difficult to understand without multiple passes of this = spec as well as [JWE] and [JWS]. >=20 > For example, a JWT appears to be simply either a JWS or a JWE = containing a JWT Claims Set, but this is not stated until right before = section 3.1 (and it isn't stated that clearly). >=20 > Immediately below are some overall comments, and then below that some = detailed comments on various portions of the spec. I'm not addressing = everything I noticed due to time constraints (apologies). >=20 > HTH >=20 > =3DJeffH > ------ >=20 >=20 > JWT terminology: >=20 > Some issues seem to me to be caused by defining the JWT to be the = base64url encoded JSON object itself and not having terminology to = clearly refer to its unencoded form. >=20 > For example, these two JSON objects together apparently comprise a = (unencoded) JWT.. >=20 > {"typ":"JWT", > "alg":"HS256"} >=20 > {"iss":"joe", > "exp":1300819380, > "http://example.com/is_root":true} >=20 > ..but there's no defined way to refer to them given the spec's = terminlogy. >=20 > Consider terming the above a JWT and its encoded-string form an = Encoded JWT, and define them separately. And then there'll be similar = definitions for JWT Header and JWT Claims Set, e.g., >=20 > Encoded JWT A JWT that has been encoded according to the > process defined in Section X. >=20 > Encoded JWT Header The encoded-string form of a JWT Header >=20 > Encoded JWT Claims Set The encoded-string form of a JWT Claims Set >=20 > encoded-string form The result of applying Base64url encoding to = an > input JSON text . >=20 > JSON Web Token (JWT) A JWT comprises a JWT Header and a JWT Claims = Set. ... >=20 > JWT Header A JSON object that is a component of a JWT. It denotes = the > cryptographic operations applied to the JWT. ... >=20 > JWT Claims Set A JSON object containing a set of claims. ... >=20 >=20 > This also gets rid of the use of the "A string representing a JSON = object..." which I find confusing and potentially misleading (because it = is actually "a Base64url encoding of a JSON object"). >=20 >=20 >=20 > UTF-8: >=20 > UTF-8 is mentioned in lots of places. It could probably be stated once = up near the beginning of the spec that all the JSON text is UTF-8 = encoded, and all the JSON strings are UTF-8 encoded. >=20 >=20 >=20 > Semantics, profiles and relationship to SAML: >=20 > The spec does not define any overall JWT semantics (i.e., what any = given JWT /means/). Semantics are only defined in context of each = individual Reserved Claim Name. >=20 > Thus any application of JWTs will need to profile the JWT spec: = specifying the claim set(s) contents, and the overall semantics of the = resultant JWT(s). This is not explicitly explained in the JWT spec. >=20 > In terms of SAML, Appendix B should refer to SAML assertions rather = than saml tokens. Also, I'm not sure SAML assertions inherently have = more expressivity than JWTs. They do have more pre-defined structure and = semantics. >=20 > Syntactically, it seems one can encode pretty much anything in = whatever amount in a JWT (one can do the same with SAML assertions), and = thus theoretically JWTs could be used to accomplish the same things as = SAML assertions. >=20 > Semantically, SAML assertions are explicitly statements made by a = system entity about a subject. But by default, a JWT is empty, and has = no semantics (this isn't stated explicitly). All semantics defined in = the JWT spec are particular to individual reserved claims, but all = reserved claims are optional. Thus an application of JWTs to use cases = also apropos for SAML assertions will require arguably more profiling = than that needed to apply SAML assertions. >=20 > The token size & complexity comparison seems nominally fine. >=20 >=20 >=20 > Some detailed-but-rough comments and musings on portions of the spec = as I was reading through it... >=20 >=20 >=20 > > 2. Terminology >=20 >=20 > terminology is not alphabetised! >=20 >=20 > "claim", "claims", "token" should be defined in terminology >=20 > suggestion: >=20 > Claim: an assertion of something as a fact. Here, claims are > name and value pairs, consisting of a Claim Name and a > Claim Value. >=20 >=20 > > JSON Web Token (JWT) >=20 > is jwt always a "string" or is it string (only) when it's been = serialized into one? >=20 > > A string representing a set of claims as a JSON > > object that is digitally signed or MACed and/or encrypted. >=20 > is it more that it's a set of claims encoded as a JSON object > that is string-serialized? >=20 > is it /not/ a JWT by definition if it is not ((signed or unmac'd) = and/or encrypted) ? No, because there are Plaintext JWTs, but they = aren't in terminology (probably should be). >=20 > "parts" in JWT definition is unclear > are "parts" json objects or arrays unto themselves ? >=20 > the definition assumes knowledge that's presented later. perhaps = needs fwd > reference(s), or perhaps better is to not present as much technical = detail > in the definitions. >=20 >=20 > > JWT Claims Set >=20 > similar comments as to JSON Web Token (JWT) >=20 > the definition says how it is encoded and encrypted, but not how = claims are mapped into a JSON object >=20 >=20 > should probably be simply: >=20 > JWT Claims Set: A set of claims expressed as a JSON object, where = each > claim is an object member (i.e., a name/value pair). A claim may = have > a JWT Claims Set as a value. >=20 >=20 > > Claim Name The name of a member of the JSON object representing = a > > JWT Claims Set. >=20 > should probably be simply: >=20 > Claim Name The name portion of a claim, expressed as a JSON object = member > name. >=20 >=20 > > Claim Value The value of a member of the JSON object = representing a > > JWT Claims Set. >=20 > should probably be simply: >=20 > Claim Value The value portion of a claim, expressed as a JSON = object member > value. >=20 >=20 >=20 > > 3. JSON Web Token (JWT) Overview >=20 > > The bytes of the UTF-8 representation of the JWT Claims Set are > > digitally signed or MACed in the manner described in JSON Web > > Signature (JWS) [JWS] and/or encrypted in the manner described in > > JSON Web Encryption (JWE) [JWE]. >=20 > s/ and/or encrypted / or encrypted and signed / >=20 >=20 > > The contents of the JWT Header describe the cryptographic = operations > > applied to the JWT Claims Set. If the JWT Header is a JWS Header, = the > > claims are digitally signed or MACed. If the JWT Header is a JWE > > Header, the claims are encrypted. >=20 > What if a JWT is signed AND encrypted? Hm, from my looking at JWS and = JWE specs, it seems that in that case one uses JWE because that = encompasses both encrypt & sign. >=20 >=20 >=20 > > A JWT is represented as a JWS or JWE. The number of parts is > > dependent upon the representation of the resulting JWS or JWE. >=20 > Does the above mean to say.. >=20 > A JWT consists of a JWS or JWE object, which in turn conveys the JWT > Claims Set. In the case of a JWS, the JWT Claims Set is the JWS > Payload. In the case of a JWE, the JWT Claims Set is the input > Plaintext. >=20 >=20 >=20 >=20 > > 4. JWT Claims > > > > > > The JWT Claims Set represents a JSON object whose members are the > > claims conveyed by the JWT. The Claim Names within this object = MUST > > be unique; JWTs with duplicate Claim Names MUST be rejected. >=20 > does the above mean to say claim names must be unique amongst the set = of claim names within any given JWT Claims Set ? If so, that's only = implied by the above but should be stated explicitly; as it is, the = above is ambiguous. >=20 >=20 > > 4.2. Public Claim Names > > > > > > Claim names can be defined at will by those using JWTs. However, = in >=20 > s/Claim names/Public claim names/ >=20 > > order to prevent collisions, any new claim name SHOULD either be > > registered in the IANA JSON Web Token Claims registry Section 9.1 = or > > be a URI that contains a Collision Resistant Namespace. >=20 >=20 > why should a claim name be a URI if I wish to make use of Collision = Resistant Namespaces? For example, if I simply use say UUIDs as claim = names.. >=20 > {"iss":"joe", > "3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"} >=20 > ..it will be universally unique provided I minted it appropriately (no = URI syntax is needed). >=20 >=20 >=20 > > 4.3. Private Claim Names > > > > > > A producer and consumer of a JWT may agree to any claim name that = is > > not a Reserved Name Section 4.1 or a Public Name Section 4.2. = Unlike > > Public Names, these private names are subject to collision and = should > > be used with caution. >=20 > it seems private claim names are only subject to collision if the = implementers don't make appropriate use of Collision Resistant = Namespaces, i.e. they "can be" subject to collision. >=20 >=20 > the above two sections use "public" and "private" as distinguishing = factors, but it seems to me the distinguishing factor (given how the = above is written) is more whether Collision Resistant Namespaces are = employed or not. >=20 > An implied aspect of public claim names seems to be that it is assumed = that they are publicly listed/documented/leaked, thus the "public" = moniker, and hence ought to be universally unique as a matter of course. >=20 > and "private" ones seem to be assumed to be obfuscated to all but the = agreeing parties? Or they are "private" in only the sense that they are = created in the context of a private arrangement? >=20 >=20 >=20 > > > > 7. Rules for Creating and Validating a JWT > > > > > > To create a JWT, one MUST perform these steps. The order of the > > steps is not significant in cases where there are no dependencies > > between the inputs and outputs of the steps. > > > > 1. Create a JWT Claims Set containing the desired claims. Note = that > > white space is explicitly allowed in the representation and = no > > canonicalization is performed before encoding. >=20 >=20 > I presume the rationale for allowing white space is that JSON objects = are unordered (and can contain arbitrary whitespace), thus simple = buffer-to-buffer comparisons between serialized objects cannot be = reliably performed. If so this should be explicitly stated. >=20 > It seems that member/value-by-member/value comparisons must always be = done, by parsing the JSON objects and extracting all members and values, = this should be stated explicitly in the spec. >=20 > I found meager jwt comparison instructions at the very end of Section = 7. it should probably be its own subsection. It should probably = explicitly say that JWTs need to be parsed into their constituent = components, and the latter must be individually examined/compared. >=20 >=20 > > Comparisons between JSON strings and other Unicode strings MUST = be > > performed as specified below: >=20 > this comparison algorithm seems to be attempting to allow for = comparison of UTF-8 encoded JSON strings with other unicode strings in = any of the unicode encoding formats, but only implies that; it should be = stated. >=20 > > > > 1. Remove any JSON applied escaping to produce an array of = Unicode > > code points. >=20 > I don't think (1) is correct. A JSON string is by default encoded in = UTF-8. A UTF-8 encoded string is not "an array of Unicode code points" = (its a sequence of code units, which must be decoded into code points), = i think a step is missing here.. >=20 > 1. Remove any JSON escaping from the input JSON string. >=20 > 1.a convert the string into a sequence of unicode code points. >=20 > ..and then compare code point-by-code point. This overall algorithm = /seems/ ok, but I'm not sure, it seems there's rationale that's not = expressed, eg for excluding use of Unicode Normalization [USA15]. Also = the alg is incomplete in that it doesn't stipulate converting the "other = unicode string" into a sequence of code points. >=20 >=20 >=20 >=20 > > 10. Security Considerations > > > > > > All of the security issues faced by any cryptographic application > > must be faced by a JWT/JWS/JWE/JWK agent. Among these issues are > > protecting the user's private key, preventing various attacks, = and > > helping the user avoid mistakes such as inadvertently encrypting = a > > message for the wrong recipient. The entire list of security > > considerations is beyond the scope of this document, but some > > significant concerns are listed here. > > > > All the security considerations in the JWS specification also = apply > > to JWT, as do the JWE security considerations when encryption is > > employed. In particular, the JWS JSON Security Considerations = and > > Unicode Comparison Security Considerations apply equally to the = JWT > > Claims Set in the same manner that they do to the JWS Header. > > >=20 > dunno if you can get away with sec cons wholly in other docs, and I'm = not sure it's appropriate given that JWTs are a profile of JWE or JWS. >=20 > above needs editorial polish -- there aren't any "significant = concerns" actually listed here. >=20 >=20 > --- > end >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Tue Nov 27 21:50:49 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1704721F8479 for ; Tue, 27 Nov 2012 21:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdZnJw1CTuKh for ; Tue, 27 Nov 2012 21:50:47 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 07A2121F8490 for ; Tue, 27 Nov 2012 21:50:46 -0800 (PST) Received: from mail6-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.23; Wed, 28 Nov 2012 05:50:39 +0000 Received: from mail6-co1 (localhost [127.0.0.1]) by mail6-co1-R.bigfish.com (Postfix) with ESMTP id A5606280257; Wed, 28 Nov 2012 05:50:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zz98dI9371Id6eah936eIc85fh1dbaI1447Izz1de0h1202h1d1ah1d2ahzz8275ch17326ah8275bh8275dh18c673hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h15d0l1155h) Received-SPF: pass (mail6-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail6-co1 (localhost.localdomain [127.0.0.1]) by mail6-co1 (MessageSwitch) id 1354081819888534_22419; Wed, 28 Nov 2012 05:50:19 +0000 (UTC) Received: from CO1EHSMHS011.bigfish.com (unknown [10.243.78.240]) by mail6-co1.bigfish.com (Postfix) with ESMTP id E4FCA7400BD; Wed, 28 Nov 2012 05:50:07 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS011.bigfish.com (10.243.66.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 28 Nov 2012 05:50:07 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Wed, 28 Nov 2012 05:50:07 +0000 From: Mike Jones To: John Bradley , Torsten Lodderstedt Thread-Topic: Comments on draft-ietf-oauth-json-web-token-05 Thread-Index: AQHNynQhmMLUJWTtZkCzCW1xF2zd4pf8Ly+AgABIs4CAAAEvgIAAAXKAgAACNgCAAkaHYA== Date: Wed, 28 Nov 2012 05:50:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366905CD9@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <50B1162A.8020506@lodderstedt.net> <5BB14099-C30A-4CB1-9B9A-39EB8D12863C@ve7jtb.com> <39488346-171f-4623-9d2b-a125c8444959@email.android.com> <5A0D91C3-4C97-44F3-81D8-5BF0E9FA4453@ve7jtb.com> <50B3BB4F.6050404@lodderstedt.net> <008C8EB5-9962-47B7-811C-2E0F0AF39654@ve7jtb.com> In-Reply-To: <008C8EB5-9962-47B7-811C-2E0F0AF39654@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366905CD9TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-json-web-token-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 05:50:49 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366905CD9TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll add it to my to-do list to define "prn" as being globally unique. -- Mike From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Monday, November 26, 2012 11:04 AM To: Torsten Lodderstedt Cc: OAuth WG; Mike Jones; Nat Sakimura Subject: Re: Comments on draft-ietf-oauth-json-web-token-05 I don't know that we need user_id in the JWT spec it may be enough to have = it as a OIDC extension if it is not globally useful. I agree that the definition of prn should be more specific. On 2012-11-26, at 3:56 PM, Torsten Lodderstedt > wrote: Hi John, does it make sense to change the spec as follows: - specify the prn claim as being globally unqiue - add user_id as scoped by iss claim What do you think? regards, Torsten. Am 26.11.2012 19:51, schrieb John Bradley: A user_id is scoped to a iss. There is some notion that a prn is globally unique, though the JWT spec is = not clear on that. I think people are thinking of it like a UPN in LDAP/A= D. John B. On 2012-11-26, at 3:46 PM, Torsten Lodderstedt > wrote: Hi John thanks for the explanatian. Just to make sure I got you right. A prn can be= a user_id. A prn is bound to the scope of an iss. Regards, Torsten. John Bradley > schrieb: JWT is more generic than OIDC. prn and user_id as used by OIDC are similar. user_id is already in wide u= se with Facebook's signed request. We were hoping that Facebook would be more likely to migrate from signed re= quest to JWT if the parameter names stayed the same for developers. In the generic case of a JWT the prn may not be a user. The other discussion that I recall around prn was a notion that they are fu= lly qualified and globally unique. We wanted to be clear with user_id that it is scoped to the iss and not glo= bally unique. So a prn was seen as a User Principal name and the user_id was seen as a pe= rsistent non reassignable identifier for the user in the context of the iss= . John B. On 2012-11-24, at 3:47 PM, Torsten Lodderstedt > wrote: Hi, I've got a few comments on your draft. I'm wondering why neither acr nor auth_time (which are used in OIDC) made t= heir way into this spec? What is the difference between prn and the user_id claim OIDC uses? regards, Torsten. --_000_4E1F6AAD24975D4BA5B168042967394366905CD9TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll add it to my t= o-do list to define “prn” as being globally unique.<= /span>

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: John Bra= dley [mailto:ve7jtb@ve7jtb.com]
Sent: Monday, November 26, 2012 11:04 AM
To: Torsten Lodderstedt
Cc: OAuth WG; Mike Jones; Nat Sakimura
Subject: Re: Comments on draft-ietf-oauth-json-web-token-05

 

I don't know that we need user_id in the JWT spec it= may be enough to have it as a OIDC extension if it is not globally useful.=

 

I agree that the definition of prn should be more sp= ecific.

On 2012-11-26, at 3:56 PM, Torsten Lodderstedt <<= a href=3D"mailto:torsten@lodderstedt.net">torsten@lodderstedt.net> w= rote:



Hi John,

does it make sense to change the spec as follows:

- specify the prn claim as being globally unqiue
- add user_id as scoped by iss claim

What do you think?

regards,
Torsten.

Am 26.11.2012 19:51, schrieb John Bradley:

A user_id is scoped to a iss.

 

There is some notion that a prn is globally unique, = though the JWT spec is not clear on that.   I think people are thinkin= g of it like a UPN in LDAP/AD.

 

John B.

On 2012-11-26, at 3:46 PM, Torsten Lodderstedt <<= a href=3D"mailto:torsten@lodderstedt.net">torsten@lodderstedt.net> w= rote:



Hi John

thanks for the explanatian. Just to make sure I got you right. A prn can be= a user_id. A prn is bound to the scope of an iss.

Regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com= > schrieb: 

JWT is more generic than=
 OIDC.
<=
o:p> 
p=
rn and user_id as used by OIDC are similar.   user_id is already =
in wide use with Facebook's signed request.  
W=
e were hoping that Facebook would be more likely to migrate from signed req=
uest to JWT if the parameter names stayed the same for developers.
<=
o:p> 
I=
n the generic case of a JWT the prn may not be a user.   
<=
o:p> 
T=
he other discussion that I recall around prn was a notion that they are ful=
ly qualified and globally unique.
<=
o:p> 
W=
e wanted to be clear with user_id that it is scoped to the iss and not glob=
ally unique.
<=
o:p> 
S=
o a prn was seen as a User Principal name and the user_id was seen as a per=
sistent non reassignable identifier for the user in the context of the iss.=

<=
o:p> 
J=
ohn B.
<=
o:p> 
<=
o:p> 
O=
n 2012-11-24, at 3:47 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:<=
/pre>

<=
o:p> 




H=
i,


<=
o:p> 


I=
've got a few comments on your draft.


<=
o:p> 


I=
’m wondering why neither acr nor auth_time (which are used in OIDC) m=
ade their way into this spec?


<=
o:p> 


W=
hat is the difference between prn and the user_id claim OIDC uses?


<=
o:p> 


r=
egards,


T=
orsten.




<=
o:p> 


<=
o:p> 

 

 

 

--_000_4E1F6AAD24975D4BA5B168042967394366905CD9TK5EX14MBXC283r_-- From hannes.tschofenig@gmx.net Wed Nov 28 05:28:51 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773AA21F8812 for ; Wed, 28 Nov 2012 05:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.639 X-Spam-Level: X-Spam-Status: No, score=-100.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJzLpj1Rklcj for ; Wed, 28 Nov 2012 05:28:50 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 58D1321F87FA for ; Wed, 28 Nov 2012 05:28:49 -0800 (PST) Received: (qmail invoked by alias); 28 Nov 2012 13:28:48 -0000 Received: from unknown (EHLO [10.255.129.88]) [194.251.119.201] by mail.gmx.net (mp002) with SMTP; 28 Nov 2012 14:28:48 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/05/hDr1L0/24PKBPtag5Fq9kufFQTO77TdsFY5j hVSrm7hq2QdjIP From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Nov 2012 15:28:46 +0200 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Reminder: Pending WG Draft Reviews X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 13:28:51 -0000 Hi all,=20 during the IETF meeting you had volunteered to do a review. PLEASE post = your review to the list ASAP.=20 Ciao Hannes ------------ 1. Token Revocation ACTION: Draft review review by=20 - Amanda=20 - Justin (DONE, = http://www.ietf.org/mail-archive/web/oauth/current/msg10088.html) - Tony 2. draft-ietf-oauth-jwt-bearer ACTION: Justin to review JWT Bearer Token Profiles 3. OAuth Use Cases=20 ACTION: Tony to work with Zachary on building out use cases and = clarifying the audience of the doc.=20 4. JWT ACTION: Draft review by - Jeff Hodges (DONE, = http://www.ietf.org/mail-archive/web/oauth/current/msg10156.html)=20 - Klaas - Leif 5. Security ACTION: working group to provide feedback on the requirements draft=20 http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 6. Dynamic Client Registration=20 ACTION: Hannes to ask UMA folks to review the doc. (DONE; Eve solicited = review comments; haven't gotten anything yet). ACTION: Draft review by=20 - Nat - John - Torsten (DONE, = http://www.ietf.org/mail-archive/web/oauth/current/msg10104.html)=20= From sberyozkin@gmail.com Wed Nov 28 07:00:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C819221F886C for ; Wed, 28 Nov 2012 07:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+IjKNhzwjPs for ; Wed, 28 Nov 2012 06:59:59 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD4821F886B for ; Wed, 28 Nov 2012 06:59:59 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so11282772lah.31 for ; Wed, 28 Nov 2012 06:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JjEaSJbZLaOKdmdxt5MwPEWDFqsQtVezt2q9WhDgUts=; b=lJUSEyme+eRgS0EmqMqmw6Zt/RdDVu/ZOw15DnyGvInIZ+8LirDTxYIO7ZDJ04q5Nz 5JN3yaY7WHyRPurzwri8rEnBvVyt8mVSD2oSJ7Rz8F4wiu4c+WaGM7aggDIPMc+H84Rg g4rs8h999eRIJetUQiT6+aOPd0y8fZ2PDCVm05oDIEg+2niGl95JdXPpUyb886UXr4+g D+I/OWuV6/bYE1iEJ8JGt/6ITJ0sdr0ayIk3lRHYXfPQVc8YCN//uSwVCN7CRHJQYreU aq9Ze60OoxQxS3RTzrVyCDfgG03kPWJjnIJxoXtjKAj9QaUKqc6gpccRqWQ1KjsDnnUW qi8w== Received: by 10.112.86.35 with SMTP id m3mr8268812lbz.7.1354114798265; Wed, 28 Nov 2012 06:59:58 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id u9sm5209763lbf.5.2012.11.28.06.59.56 (version=SSLv3 cipher=OTHER); Wed, 28 Nov 2012 06:59:57 -0800 (PST) Message-ID: <50B626EB.8010906@gmail.com> Date: Wed, 28 Nov 2012 14:59:55 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <50B3B1B3.50502@gmail.com><6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> <50B4A2AC.6010904@gmail.com> <999913AB42CC9341B05A99BBF358718D022492FA@FIESEXC035.nsn-intra.net> <1354037569.35121.YahooMailNeo@web31813.mail.mud.yahoo.com> <1354039156.86802.YahooMailNeo@web31808.mail.mud.yahoo.com> <4AE3FDC6-2752-4BEE-8415-FDFDDD5DCEB8@gmx.net> In-Reply-To: <4AE3FDC6-2752-4BEE-8415-FDFDDD5DCEB8@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:00:00 -0000 Hi Hannes On 27/11/12 18:54, Hannes Tschofenig wrote: > Good that you both raise this point. The refresh token mechanism allows us to request new access tokens (and new keying material correspondingly since the two are tight together) in a dynamic fashion. If you turn the MAC key into a long term secret or use it with multiple resource servers then you obviously loose the security benefits. IMHO, the MAC key is the property of the individual access token and thus does not have to be turned into a long term secret. Re using it multiple servers: recall my point about using a given token for the specific deployment/case - if the use of MAC tokens is not the right thing to do in the advanced deployments - lets have some advice on that. I'd even compare the use of MAC as compared to other more sophisticated tokens to the implicit vs authorization code flow. The former is assumed to be less secure than the latter - nonetheless both are supported by the spec - it is about using the right flow for the right deployment and being aware of the relevant security threats. Cheers, Sergey > > All this is documented in Section 5 of http://tools.ietf.org/html/draft-tschofenig-oauth-security-00#section-5 > > On Nov 27, 2012, at 7:59 PM, William Mills wrote: > >> Yes! >> >> The other thing that is better in the OAuth 2 model is the refresh capability, which makes plain text channel token usage more palatable. >> >> From: "Richer, Justin P." >> To: William Mills >> Cc: "Tschofenig, Hannes (NSN - FI/Espoo)"; ext Sergey Beryozkin; Hannes Tschofenig; "oauth@ietf.org" >> Sent: Tuesday, November 27, 2012 9:51 AM >> Subject: Re: [OAUTH-WG] What needs to be done to complete MAC >> >> An important point to note, that many OAuth1 implementations in the wild screw up, is that you still need TLS between the client and the Authorization Server to protect the token and secret in transit, even if you don't use TLS during the client's calls to the protected resource. Since OAuth2 core mandates TLS at the Token Endpoint explicitly for all token types, that's much more clear to understand (in my opinion) in implementation. >> >> In case the above is unclear, what I'm trying to say is this: putting a signed token like MAC into the OAuth2 framework will give us the capability of OAuth1 in a clearer, more secure (in the wild) structure. I think it's vitally important that we have this functionality, and while I understand the need for clear use cases, I don't understand the feet-dragging. >> >> -- Justin >> >> On Nov 27, 2012, at 12:32 PM, William Mills wrote: >> >>> I don't see in that document a significant use case for a signed token, which is use over clear text channels. Bearer tokens have similar security properties to HTTP cookies (minus for the moment the XSRF problem). Signed token types can be used over plain text channels without the concern about re-use of the token by a 3rd party. Replay protection is still needed but that's not in scope for the token mechanism itself. >>> >>> It's always been this simple use case that has been my focus for MAC. >>> >>> Flickr uses OAuth 1.0a today over HTTP and will for many years to come, we won't be able to go completely SSL due to the installed base of clients. Given the dynamic I see in the mobile development community I don't see us getting all mobile apps into SSL only anytime soon. MAC and OAuth 1.0 solve the token security problem for the last hop to the phone/wi-fi device without SSL for the bulk of the application traffic. >>> >>> -bill >>> >>> >>> From: "Tschofenig, Hannes (NSN - FI/Espoo)" >>> To: ext Sergey Beryozkin; Hannes Tschofenig >>> Cc: oauth@ietf.org >>> Sent: Tuesday, November 27, 2012 4:33 AM >>> Subject: Re: [OAUTH-WG] What needs to be done to complete MAC >>> >>> Hi Sergey, >>> >>> I believe we would make faster progress on security topics if could >>> focus on listing security requirements we have and what threats we want >>> to mitigate. The reason why we have not finished this topic is simply >>> because everyone was just talking about specific (but incomplete) >>> solutions. You are unfortunately falling in the same trap as well. >>> >>> If you really care about the topic then have a look at the mentioned >>> document and tell us whether the requirements are complete. >>> Reading through the document you will notice that there a few more >>> considerations to pay attention to than just the few listed below. >>> >>> Ciao >>> Hannes >>> >>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>>> Of ext Sergey Beryozkin >>>> Sent: Tuesday, November 27, 2012 1:23 PM >>>> To: Hannes Tschofenig >>>> Cc: >>>> Subject: Re: [OAUTH-WG] What needs to be done to complete MAC >>>> >>>> Hi Hannes >>>> On 26/11/12 19:01, Hannes Tschofenig wrote: >>>>> Hi Sergey, >>>>> >>>>> as Phil said it would be helpful for us to receive reviews of this >>>> document: >>>>> http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 >>>>> >>>>> The document lists requirements and threats. >>>> >>>> >>>> Let me offer two possibly naive reasons why using MAC may help, one of >>>> them is related to the security, another to the ease of HOK support on >>>> the client >>>> >>>> 1. The most safe way to return MAC token to the client is to use a >>>> two-way TLS due to the mac key also returned to the client. Two-Way >>> TLS >>>> offers a stronger support for getting the client authenticated along >>> the >>>> way too >>>> >>>> 2. Assuming HOK confirmation matters at all (and I believe it does), >>>> IMHO it is much simpler for a basic client implementation to apply a >>> MAC >>>> signature algo and thus work with the OAuth2 servers expecting HOK >>>> confirmations >>>> >>>> One more reason is more about facilitating the further migration to >>> 2.0 >>>> which I tried to outline in my response to Phil Hunt >>>> >>>> Thanks, Sergey >>>> >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote: >>>>> >>>>>> If we want to get this done we have to get agreements on the >>>> requirements for HOK. Several meetings ago (quebec) the group >>> indicated >>>> that mac wasn't appropriate to anyone's needs. >>>>>> >>>>>> Some would argue that OAuth1 users arguably have less security than >>>> the simpler bearer token /tls model in OAuth2. This just shows the >>> real >>>> issue of demonstrated need has not been properly defined and >>> understood. >>>>>> >>>>>> More dialog on use cases is very helpful to moving HOK/MAC/etc >>>> forward. >>>>>> >>>>>> Phil >>>>>> >>>>>> On 2012-11-26, at 10:15, Sergey Beryozkin >>>> wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> What needs to be done to complete the MAC token spec ? Without >>>> having it signed off it will be difficult to get people working with >>>> OAuth 1.0 convinced to move to 2.0. >>>>>>> I'm seeing another user request for getting OAuth 1.0 support >>>> extended further because the user expects it is more secure, and I >>> guess >>>> because it is proven to work for people, and I guess because many >>> OAuth >>>> 1.0 users feel that should stay from OAuth 2.0 because of some bad >>> press. >>>>>>> >>>>>>> Without MAC being completed the division will continue, with even >>>> more misleading anti-OAuth2 posts appearing (though I guess some of >>> the >>>> better posts point to some level of complexity in 2.0). >>>>>>> >>>>>>> Is it a matter of a security expert validating the text, fixing >>> few >>>> typos, and basically signing it off ? >>>>>>> >>>>>>> If someone is interested then I can provide the info offline on >>> how >>>> it MAC supported in our framework to get things tested easily and >>> such... >>>>>>> >>>>>>> Cheers, Sergey >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> _______________________________________________ >>> 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 >> >> >> > From sberyozkin@gmail.com Wed Nov 28 07:11:50 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD8621F8866 for ; Wed, 28 Nov 2012 07:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDH2ky6I4BrQ for ; Wed, 28 Nov 2012 07:11:49 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 106D421F885C for ; Wed, 28 Nov 2012 07:11:48 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so11459248lbk.31 for ; Wed, 28 Nov 2012 07:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lmukQjC571irjyBfE3et/dRRZ2s4uZpSXunbVuRJ2nk=; b=0cOcYz+e6c593fCRRLjwy49vmvRFf8xy95FQIY4ye0mFEX+M51jcjtoJgvGOuu8o7V YGMpu/n85PHGpf0yJDzLpxL2v2ShsV6DA2lZQYZ4qzmiGy9TrrWezfRlZBm7wSZUOY5b azK3TlFQsKUKRALhde32A9lXlAGpbsr5epjpDhyknoqQN+CIoPqJwAVQ104RPYXMCY51 vRDg9ckUNaxHtICoV1Hp+cjT+AQVhXm9CSPXNIpCRUf4E/JzrAY97FifY6u6Bpy1VeHP hsdE+vQw+mGosN+0ZCHBkU3mDKf2uQMxUCLZ9zeUCVE/cog1Mp2n5OQK8Qz0YtgmOG5c iABw== Received: by 10.112.82.166 with SMTP id j6mr17321lby.25.1354115507942; Wed, 28 Nov 2012 07:11:47 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id l1sm8474629lbm.1.2012.11.28.07.11.46 (version=SSLv3 cipher=OTHER); Wed, 28 Nov 2012 07:11:47 -0800 (PST) Message-ID: <50B629B1.60308@gmail.com> Date: Wed, 28 Nov 2012 15:11:45 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <50B3B1B3.50502@gmail.com><6BF18EF2-EBB4-47E6-A7EC-BFADD1C730D0@gmx.net> <50B4A2AC.6010904@gmail.com> <999913AB42CC9341B05A99BBF358718D022492FA@FIESEXC035.nsn-intra.net> <50B4B5D4.4070805@gmail.com> <3DB12DBE-267E-49BF-A398-B82B3265A706@gmx.net> In-Reply-To: <3DB12DBE-267E-49BF-A398-B82B3265A706@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] What needs to be done to complete MAC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:11:50 -0000 Hi Hannes On 27/11/12 18:50, Hannes Tschofenig wrote: > Hi Sergey, > > On Nov 27, 2012, at 2:45 PM, Sergey Beryozkin wrote: > >> Hi Hannes >> >> On 27/11/12 12:33, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>> Hi Sergey, >>> >>> I believe we would make faster progress on security topics if could >>> focus on listing security requirements we have and what threats we want >>> to mitigate. The reason why we have not finished this topic is simply >>> because everyone was just talking about specific (but incomplete) >>> solutions. You are unfortunately falling in the same trap as well. >> >> Quite possible - I was hoping to give some perspective of someone who would like to see a wider acceptance of 2.0 at the grass root level if you wish where 'grass root' represents simple 2.0 applications. > > We are obviously interested in wide acceptance of our specifications. > >> >>> >>> If you really care about the topic then have a look at the mentioned >>> document and tell us whether the requirements are complete. >>> Reading through the document you will notice that there a few more >>> considerations to pay attention to than just the few listed below. >>> >> Believe it or not I did read the document awhile back :-) > > Cool. Thanks. > >> and will definitely read it few times more - it is a must-read. I'm just concerned that it appears that the possible progress on MAC >> needs to be justified by linking it implicitly to the security threats doc. And I'm not sure it is the best way to follow. >> >> How about a slightly different approach. >> Do you agree that supporting HOK is important ? Assuming yes then I guess the threats doc must be talking about the relevant issues that HOK can help with addressing. >> >> If we can agree on this then IMHO MAC passes the acceptance criteria because it offers one way to provide a HOK support. Whether JWT or other token type may also help with HOK support is entirely different issue and it is down to specific OAuth2 implementers on which HOK-capable token to support > > In Section 4 of http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 we tried to explain that there are three approaches to address very common security threats that exist in these three party protocols. All three approach, namely "confidentiality protection", "sender constraint", and "key confirmation", address these common threats in their own way. The details vary between the different solution categories. We published the bearer token specification, which follows the approach described in Section 4.1 ("confidentiality protection"). > > The group very early on said that they also wand an alternative, using "key confirmation". This was actually the reason why we moved the bearer and the MAC specification out of the main OAuth 2.0 and put them into separate documents. Consequently, there is no need to convince us that we should be working on a solution that is different than the bearer token (even I keep explaining folks that bearer tokens are not cookies and that they have similar properties than the other mechanisms). > > We had also figured out that there isn't only a single solution that will make everyone happy. But we also don't want to standardize everything comes to our mind: you can see in other areas (e.g., EAP, SASL, TLS ciphersuites, IKEv2 extension, etc.) that the creativity is endless when it comes to authentication and key exchange protocols. > Major thanks for providing the background info and more thoughts on this topic... +1 to the fact it is not realistic to standardize every token type out there. To be honest, as I already indicated, I don't mind if MAC stays the draft, we will support it as it's already in the code and will fix the things locally at our framework level if the users who will start experimenting with it report some issues with the way the signature is calculated and such or will want a support for a body hash which I believe is optionally supported (?) at the MAC draft level, etc... I think, with my primitive understanding of the advanced security issues, that MAC has few useful properties which can help with the simpler cases. But again, from my point of view, it is more about having a token type which will be most 'familiar' to 1.0 developers. May be I'm just repeating myself, sorry :-) > I am hoping that the conference calls (which I had asked folks to indicate their preference for) will help us to come up with an answer of what the essential requirements are (and hopefully within a very short timeframe). You are, btw, welcome to join those calls. Thanks - will definitely consider once I get a better appreciation of OAuth2.0 Cheers, Sergey > > Ciao > Hannes > > PS: We should have probably never used the term HOK since it caused more confusion than it helped. > >> >> Thanks, Sergey >> >> >> >>> Ciao >>> Hannes >>> >>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>>> Of ext Sergey Beryozkin >>>> Sent: Tuesday, November 27, 2012 1:23 PM >>>> To: Hannes Tschofenig >>>> Cc: >>>> Subject: Re: [OAUTH-WG] What needs to be done to complete MAC >>>> >>>> Hi Hannes >>>> On 26/11/12 19:01, Hannes Tschofenig wrote: >>>>> Hi Sergey, >>>>> >>>>> as Phil said it would be helpful for us to receive reviews of this >>>> document: >>>>> http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 >>>>> >>>>> The document lists requirements and threats. >>>> >>>> >>>> Let me offer two possibly naive reasons why using MAC may help, one of >>>> them is related to the security, another to the ease of HOK support on >>>> the client >>>> >>>> 1. The most safe way to return MAC token to the client is to use a >>>> two-way TLS due to the mac key also returned to the client. Two-Way >>> TLS >>>> offers a stronger support for getting the client authenticated along >>> the >>>> way too >>>> >>>> 2. Assuming HOK confirmation matters at all (and I believe it does), >>>> IMHO it is much simpler for a basic client implementation to apply a >>> MAC >>>> signature algo and thus work with the OAuth2 servers expecting HOK >>>> confirmations >>>> >>>> One more reason is more about facilitating the further migration to >>> 2.0 >>>> which I tried to outline in my response to Phil Hunt >>>> >>>> Thanks, Sergey >>>> >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote: >>>>> >>>>>> If we want to get this done we have to get agreements on the >>>> requirements for HOK. Several meetings ago (quebec) the group >>> indicated >>>> that mac wasn't appropriate to anyone's needs. >>>>>> >>>>>> Some would argue that OAuth1 users arguably have less security than >>>> the simpler bearer token /tls model in OAuth2. This just shows the >>> real >>>> issue of demonstrated need has not been properly defined and >>> understood. >>>>>> >>>>>> More dialog on use cases is very helpful to moving HOK/MAC/etc >>>> forward. >>>>>> >>>>>> Phil >>>>>> >>>>>> On 2012-11-26, at 10:15, Sergey Beryozkin >>>> wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> What needs to be done to complete the MAC token spec ? Without >>>> having it signed off it will be difficult to get people working with >>>> OAuth 1.0 convinced to move to 2.0. >>>>>>> I'm seeing another user request for getting OAuth 1.0 support >>>> extended further because the user expects it is more secure, and I >>> guess >>>> because it is proven to work for people, and I guess because many >>> OAuth >>>> 1.0 users feel that should stay from OAuth 2.0 because of some bad >>> press. >>>>>>> >>>>>>> Without MAC being completed the division will continue, with even >>>> more misleading anti-OAuth2 posts appearing (though I guess some of >>> the >>>> better posts point to some level of complexity in 2.0). >>>>>>> >>>>>>> Is it a matter of a security expert validating the text, fixing >>> few >>>> typos, and basically signing it off ? >>>>>>> >>>>>>> If someone is interested then I can provide the info offline on >>> how >>>> it MAC supported in our framework to get things tested easily and >>> such... >>>>>>> >>>>>>> Cheers, Sergey >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 > From internet-drafts@ietf.org Wed Nov 28 14:03:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6872F21F8904; Wed, 28 Nov 2012 14:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+xw4C6OZp0f; Wed, 28 Nov 2012 14:03:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBF121F87D4; Wed, 28 Nov 2012 14:03:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121128220353.29761.65951.idtracker@ietfa.amsl.com> Date: Wed, 28 Nov 2012 14:03:53 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:03:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : OAuth 2.0 Message Authentication Code (MAC) Tokens Author(s) : Justin Richer William Mills Hannes Tschofenig Filename : draft-ietf-oauth-v2-http-mac-02.txt Pages : 19 Date : 2012-11-28 Abstract: This document specifies the HTTP MAC access authentication scheme, an HTTP authentication method using a message authentication code (MAC) algorithm to provide cryptographic verification of portions of HTTP requests. The document also defines an OAuth 2.0 binding for use as an access token type. NOTE: This document (and other OAuth 2.0 security documents, such as [I-D.tschofenig-oauth-hotk]) are still work in progress in the OAuth working group. As such, the content of this document may change. For a discussion about security requirements please consult [I-D .tschofenig-oauth-security]. Your input on the detailed security requirements is highly appreciated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Hannes.Tschofenig@gmx.net Wed Nov 28 14:09:32 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7AD21F8944 for ; Wed, 28 Nov 2012 14:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fh8GABpQilfk for ; Wed, 28 Nov 2012 14:09:31 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1F6E421F892F for ; Wed, 28 Nov 2012 14:09:30 -0800 (PST) Received: (qmail invoked by alias); 28 Nov 2012 22:09:29 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp034) with SMTP; 28 Nov 2012 23:09:29 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19OHI5ZDDdOcG7QUfjbQGI7Wk66tbnbBysVHK9Ewk m1C3ASVpcUISJK From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Nov 2012 00:09:27 +0200 Message-Id: <14EFB911-7364-40F6-BCE7-E41430BACE68@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] draft-ietf-oauth-v2-http-mac X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:09:32 -0000 Hi all,=20 I refreshed the MAC token specification as input to the security = discussion. Here is the resubmitted document:=20 http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02 Here is the requirements document:=20 http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 Please don't forget to indicate your preferences for the upcoming = conference call dates: http://www.doodle.com/smvh5pmcqc43dti3 The deadline for your input regarding the conference call is today.=20 Ciao Hannes PS: If you are interested to see an alternative solution approach have a = look here:=20 http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01 From phil.hunt@oracle.com Wed Nov 28 14:44:09 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD64821F8939 for ; Wed, 28 Nov 2012 14:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5SwJzrGf4pW for ; Wed, 28 Nov 2012 14:44:09 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 256F921F8960 for ; Wed, 28 Nov 2012 14:44:08 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qASMi77a015622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 28 Nov 2012 22:44:07 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qASMi6ie020553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Nov 2012 22:44:07 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qASMi5ho013437 for ; Wed, 28 Nov 2012 16:44:05 -0600 Received: from [192.168.1.131] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Nov 2012 14:44:05 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_A417D195-FC0D-455C-9202-B293A59DB40F" Date: Wed, 28 Nov 2012 14:44:04 -0800 Message-Id: To: oauth WG Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [OAUTH-WG] Refresh of chaining draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:44:10 -0000 --Apple-Mail=_A417D195-FC0D-455C-9202-B293A59DB40F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, After a request at IETF85 and a reminder from Hannes, I've posted a = refresh of my original chaining document. No changes have been made in = the refresh. My current position is that this type of chaining (as defined in my = earlier draft) is useful when you need to get a new token after crossing = an administrative boundary. It is less useful when you have servers = wanting to chain in essentially an act on behalf of case where a 1-leg = solution is more desirable and 2-legs are costly. My plan is to work with Justin and reconcile with his work on = http://tools.ietf.org/id/draft-richer-oauth-chain-00.txt > A new version of I-D, draft-hunt-oauth-chain-01.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Filename: draft-hunt-oauth-chain > Revision: 01 > Title: Chain Grant Type for OAuth2 > Creation date: 2012-11-28 > WG ID: Individual Submission > Number of pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-hunt-oauth-chain-01.txt > Status: = http://datatracker.ietf.org/doc/draft-hunt-oauth-chain > Htmlized: http://tools.ietf.org/html/draft-hunt-oauth-chain-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-oauth-chain-01 >=20 > Abstract: > This specification defines a method by which an OAuth protected > service, can use a received oauth token from its client, to in turn, > act as a client and access another OAuth protected service in a > 'chained' profile. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_A417D195-FC0D-455C-9202-B293A59DB40F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://t= ools.ietf.org/id/draft-richer-oauth-chain-00.txt

<= div>
A new version of I-D, = draft-hunt-oauth-chain-01.txt
has been successfully submitted by Phil = Hunt and posted to the
IETF repository.

Filename: =  draft-hunt-oauth-chain
Revision: =  01
Title:  Chain Grant Type for = OAuth2
Creation date:  2012-11-28
WG ID: =  Individual Submission
Number of pages: 10
URL: =             http://www.ietf.org/internet-drafts/draft-hunt-oauth-chain-01.txt
= Status:          http://dat= atracker.ietf.org/doc/draft-hunt-oauth-chain
Htmlized: =        http://tools= .ietf.org/html/draft-hunt-oauth-chain-01
Diff: =            http= ://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-oauth-chain-01

Abstra= ct:
  This specification defines a method by which an OAuth = protected
  service, can use a received oauth token from = its client, to in turn,
  act as a client and access = another OAuth protected service in a
  'chained' = profile.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





= --Apple-Mail=_A417D195-FC0D-455C-9202-B293A59DB40F-- From hannes.tschofenig@gmx.net Thu Nov 29 01:16:02 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8B421F843A for ; Thu, 29 Nov 2012 01:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.639 X-Spam-Level: X-Spam-Status: No, score=-100.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AS7HZs9NN7g for ; Thu, 29 Nov 2012 01:16:01 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 03ECD21F841A for ; Thu, 29 Nov 2012 01:16:00 -0800 (PST) Received: (qmail invoked by alias); 29 Nov 2012 09:15:59 -0000 Received: from unknown (EHLO [10.255.135.157]) [194.251.119.201] by mail.gmx.net (mp039) with SMTP; 29 Nov 2012 10:15:59 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/SrX9TOlHSKbSmBQBe+TUJh9/ruUQ+E3ScGuBWZj tKME0lSRdBE1h5 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Nov 2012 11:15:56 +0200 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Conference Call Announcement: Security Requirements / Security Use Cases X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 09:16:02 -0000 Hi all,=20 thank you for your response to the poll. We are going to schedule three = conference calls based on your input: * 14th December 2012, 1pm EST * 11th January 2013, 1pm EST * 21st January 2013, 1pm EST I will distribute the conference bridge info soon.=20 Ciao Hannes & Derek From abarrei@gmail.com Thu Nov 29 09:53:51 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A5821F8B0C for ; Thu, 29 Nov 2012 09:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKmACFp8t1hs for ; Thu, 29 Nov 2012 09:53:50 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB97C21F8B9D for ; Thu, 29 Nov 2012 09:53:50 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id m14so2392489yen.31 for ; Thu, 29 Nov 2012 09:53:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=UNmBrhuYMyrH77dPf43spM6dyGuk3rvwP/p82NPXk9U=; b=vk9tdiLDbFNvg0DBlmYJLwL+BmuK+2J4f+Eg5KxuYKVP4gUqJx+/vjw95fjtENoSK/ 2pQWbVXrljQ9HNaz9usYy70bvAurMMTl+Ah10HzPjj9fs4r3xy9WLM8IglznQycmiIqe Yy7DU1hdBpMvAp+XLhFwsn1VOvjwSeIYrH/Kkg4Yp+rw1Rv++s5lTIi/whIAh/llztOd 28x4OfcTMmtBKSg0C1dMGWYLQXeFSLBSQHR0ismwbaLTxXguMgrdNNUM/FFYYKt48Z8z bTng8n+1LQ3mthfOK4w0pQMs/AfDVfuLE8jAwbQtALm7T8DPWAuIUL6CXERlIZdKiYBN Ilmw== Received: by 10.59.6.39 with SMTP id cr7mr33831769ved.17.1354211630221; Thu, 29 Nov 2012 09:53:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.169.209 with HTTP; Thu, 29 Nov 2012 09:53:30 -0800 (PST) From: Ariel Barreiro Date: Thu, 29 Nov 2012 14:53:30 -0300 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=047d7bf0e95c2b87d004cfa5f7a3 Subject: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 17:57:45 -0000 --047d7bf0e95c2b87d004cfa5f7a3 Content-Type: text/plain; charset=ISO-8859-1 I am struggling a bit to understand this attack and the advice in to how to prevent. I understand that if I, as an attacker, can change the redirection uri when authorizing, can not it as well change the redirect uri when requesting an access token? Any explanation examples on how this attack might work and how sending the redirect_uri when requesting the access toekn prevents it are welcomed. Thanks, Ariel.= --047d7bf0e95c2b87d004cfa5f7a3 Content-Type: text/html; charset=ISO-8859-1 I am struggling a bit to understand this attack and the advice in to how to prevent. I understand that if I, as an attacker, can change the redirection uri when authorizing, can not it as well change the redirect uri when requesting an access token?

Any explanation examples on how this attack might work and how sending the redirect_uri when requesting the access toekn prevents it are welcomed.

Thanks,
Ariel.=
--047d7bf0e95c2b87d004cfa5f7a3-- From phil.hunt@oracle.com Thu Nov 29 10:01:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490D621F8B4E for ; Thu, 29 Nov 2012 10:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdpFixSyH4Xu for ; Thu, 29 Nov 2012 10:01:47 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id CAC2E21F8B23 for ; Thu, 29 Nov 2012 10:01:46 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qATI1ji5029645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Nov 2012 18:01:45 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qATI1i1u018545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2012 18:01:44 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qATI1iQx019113; Thu, 29 Nov 2012 12:01:44 -0600 Received: from [192.168.1.131] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Nov 2012 10:01:43 -0800 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Phil Hunt In-Reply-To: Date: Thu, 29 Nov 2012 10:01:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> References: To: Ariel Barreiro X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 18:01:48 -0000 There is no redirection when requesting an access token. Token requests = are typically out-of-band from the user. The attack only happens during = an authorization redirect flow in the browser. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: > I am struggling a bit to understand this attack and the advice in to = how to prevent. I understand that if I, as an attacker, can change the = redirection uri when authorizing, can not it as well change the redirect = uri when requesting an access token? >=20 > Any explanation examples on how this attack might work and how sending = the redirect_uri when requesting the access toekn prevents it are = welcomed. >=20 > Thanks, > Ariel.=3D > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From abarrei@gmail.com Thu Nov 29 10:05:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EED21F8B54 for ; Thu, 29 Nov 2012 10:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovg5EDkEpDSu for ; Thu, 29 Nov 2012 10:05:28 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8409021F8B5D for ; Thu, 29 Nov 2012 10:05:28 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so14475897vcb.31 for ; Thu, 29 Nov 2012 10:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YW0t3ElSWtcT0fc3Lm6QbbYqBYs+oZWCC2/ZO6+8fw4=; b=LIoTu+1TIwoKg2RsoVh6do8d+3+qNmj9bFtPrSPHk0W7AwxkaoF+QUyUmveA5VkrQh 91Ve3nS/NaVw5mb1qoqJoTnXwjcFb9rYHS2CTGIHP0zsXGA6ixeGs9tbi7az6aEFo3em 49wkIj9usL5C8yAaoZFX5q5LmuBVRuM7hosMYk1Tx0pxgA9i6EJFEeg7waY6n0LmZJ9M 0/6PWiurHTd+4j5/oGkpVghaEujl0k05GqhPS129ONIDdBtCVSAVxSVERw5T7DxgFKV/ tXGCegr0QDD4T+JGA+JGEqLcvP2wJ6gDRdoUy+3zvTY82IK6lk5OnMHJET48NP9HH2l2 w6lA== Received: by 10.220.115.20 with SMTP id g20mr15955660vcq.31.1354212327831; Thu, 29 Nov 2012 10:05:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.169.209 with HTTP; Thu, 29 Nov 2012 10:05:07 -0800 (PST) In-Reply-To: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> References: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> From: Ariel Barreiro Date: Thu, 29 Nov 2012 15:05:07 -0300 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=f46d0434c2ecc039b304cfa6200e Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 18:05:29 -0000 --f46d0434c2ecc039b304cfa6200e Content-Type: text/plain; charset=ISO-8859-1 Still I can't see how to prevent the attack. I understand that there is no redirection when requesting an access token, however, the protocol requests the client to send the redirect_uri to the token end point to validate it was the same used in the authorization. If the authorization was compromised, couldn't the access token request be forged as well? On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt wrote: > There is no redirection when requesting an access token. Token requests > are typically out-of-band from the user. The attack only happens during an > authorization redirect flow in the browser. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: > > > I am struggling a bit to understand this attack and the advice in to how > to prevent. I understand that if I, as an attacker, can change the > redirection uri when authorizing, can not it as well change the redirect > uri when requesting an access token? > > > > Any explanation examples on how this attack might work and how sending > the redirect_uri when requesting the access toekn prevents it are welcomed. > > > > Thanks, > > Ariel.= > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --f46d0434c2ecc039b304cfa6200e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Still =A0I can't see how to prevent the attack. I understand that there= is no redirection when requesting an access token, however, the protocol r= equests the client to send the redirect_uri to the token end point to valid= ate it was the same used in the authorization. If the authorization was com= promised, couldn't the access token request be forged as well?


On Thu, Nov 2= 9, 2012 at 4:01 PM, Phil Hunt <phil.hunt@oracle.com> wrot= e:
There is no redirection when requesting an a= ccess token. =A0Token requests are typically out-of-band from the user. =A0= The attack only happens during an authorization redirect flow in the browse= r.

Phil

@independentid
www.independenti= d.com
phil.hunt@oracle.= com





On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote:

> I am struggling a bit to understand this attack and the advice in to h= ow to prevent. I understand that if I, as an attacker, can change the redir= ection uri when authorizing, can not it as well change the redirect uri whe= n requesting an access token?
>
> Any explanation examples on how this attack might work and how sending= the redirect_uri when requesting the access toekn prevents it are welcomed= .
>
> Thanks,
> Ariel.=3D
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth


--f46d0434c2ecc039b304cfa6200e-- From jricher@mitre.org Thu Nov 29 10:31:17 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D823121F89D3 for ; Thu, 29 Nov 2012 10:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRil+UOrGEjS for ; Thu, 29 Nov 2012 10:31:10 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C9EEF21F8931 for ; Thu, 29 Nov 2012 10:31:09 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0CC8F1F0736; Thu, 29 Nov 2012 13:31:09 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DA9ED1F0712; Thu, 29 Nov 2012 13:31:08 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 29 Nov 2012 13:31:08 -0500 Message-ID: <50B7A990.8020605@mitre.org> Date: Thu, 29 Nov 2012 13:29:36 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ariel Barreiro References: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050908040900020000030603" X-Originating-IP: [129.83.31.58] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 18:31:17 -0000 --------------050908040900020000030603 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit This is why OAuth strongly suggests that Clients pre-register a set of valid redirect_uris, so that the URI being presented to the Auth Endpoint MUST match one that's been registered ahead of time. -- Justin On 11/29/2012 01:05 PM, Ariel Barreiro wrote: > Still I can't see how to prevent the attack. I understand that there > is no redirection when requesting an access token, however, the > protocol requests the client to send the redirect_uri to the token end > point to validate it was the same used in the authorization. If the > authorization was compromised, couldn't the access token request be > forged as well? > > > On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt > wrote: > > There is no redirection when requesting an access token. Token > requests are typically out-of-band from the user. The attack only > happens during an authorization redirect flow in the browser. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: > > > I am struggling a bit to understand this attack and the advice > in to how to prevent. I understand that if I, as an attacker, can > change the redirection uri when authorizing, can not it as well > change the redirect uri when requesting an access token? > > > > Any explanation examples on how this attack might work and how > sending the redirect_uri when requesting the access toekn prevents > it are welcomed. > > > > Thanks, > > Ariel.= > > _______________________________________________ > > 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 --------------050908040900020000030603 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
This is why OAuth strongly suggests that Clients pre-register a set of valid redirect_uris, so that the URI being presented to the Auth Endpoint MUST match one that's been registered ahead of time.

 -- Justin

On 11/29/2012 01:05 PM, Ariel Barreiro wrote:
Still  I can't see how to prevent the attack. I understand that there is no redirection when requesting an access token, however, the protocol requests the client to send the redirect_uri to the token end point to validate it was the same used in the authorization. If the authorization was compromised, couldn't the access token request be forged as well?


On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
There is no redirection when requesting an access token.  Token requests are typically out-of-band from the user.  The attack only happens during an authorization redirect flow in the browser.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote:

> I am struggling a bit to understand this attack and the advice in to how to prevent. I understand that if I, as an attacker, can change the redirection uri when authorizing, can not it as well change the redirect uri when requesting an access token?
>
> Any explanation examples on how this attack might work and how sending the redirect_uri when requesting the access toekn prevents it are welcomed.
>
> Thanks,
> Ariel.=
> _______________________________________________
> 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

--------------050908040900020000030603-- From ve7jtb@ve7jtb.com Thu Nov 29 12:50:23 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564E321F8C28 for ; Thu, 29 Nov 2012 12:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.154 X-Spam-Level: X-Spam-Status: No, score=-3.154 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6nlzsUCkzc8 for ; Thu, 29 Nov 2012 12:50:22 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55D0521F8C27 for ; Thu, 29 Nov 2012 12:50:22 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so3185742obq.31 for ; Thu, 29 Nov 2012 12:50:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=ZHEaMNJEfMw1Kt3dhI8ImE0DsU24uVScxehILN8483E=; b=CMVA+co4+7hYpERhTTu06jEuy77eijC2KOjrQSMVYI+0L3jRbb+um0LKU79jbdK4/Q MGXnNqOFdwjqEZfvdKn0591IhCsNUGmR9SR0jYF0emAAGFnN7hvOLTuYFFBfJZu7xnIN /O9U4pJTVyqN3vAgPl/DWqhra5jNu6XpKU13mpZI8GTIAehSXGbboK0qOWQlRsYDxhfA MWKBYkESz88dtGbEycXF4HBHiHW03R2RWG4ujTxLHw1raDSZcHfqaAQ6woEMYK7ekY6W 5yBng+q4XJczy95TIimTM2XO9WItulM1buaGycJdk9Jf+Fgl5msWg89eOheQKY9BVjwE 8Yrg== Received: by 10.60.10.227 with SMTP id l3mr2781736oeb.119.1354222221698; Thu, 29 Nov 2012 12:50:21 -0800 (PST) Received: from [192.168.1.211] (190-20-53-20.baf.movistar.cl. [190.20.53.20]) by mx.google.com with ESMTPS id k3sm2271964oea.7.2012.11.29.12.50.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Nov 2012 12:50:20 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_15740EA3-E0B2-4616-9F37-99E72FC27BC9" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Thu, 29 Nov 2012 17:25:32 -0300 Message-Id: References: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> To: Ariel Barreiro X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmIoRD0almjOoTICiTvvq5+Vo9XzZMD4W5CTTRgIB9EfcN7XnDiCcfv8SvajjosUODUCuYc Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 20:50:23 -0000 --Apple-Mail=_15740EA3-E0B2-4616-9F37-99E72FC27BC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 A confidential client authenticates to the token endpoint preventing an = attacker from getting the token. In the case of a public client if you get the code and redirect URI then = you can get the token. (Why confidential clients are better than public = ones) Sending the redirect URI to the token endpoint protects the client from = the case where client A gets a code for user B because the user logged = into A and A is using the client ID of client Z because it wants to = impersonate user B at client A. Client A pretending to be client Z = can easily get the code. However the redirect URI that the real client = Z sends will be different than the one the fake client Z used to get = code and the real client A won't be able to exchange the code for a = access token and be tricked into thinking that the resource owner is the = one presenting it the code. That is the long explanation. The short one is unregistered redirect = URI are bad. Sending the redirect URI to the token endpoint protects = clients from becoming confused about the presenter of the code. Nothing is going to help a public client if someone intercepts code. John B. On 2012-11-29, at 3:05 PM, Ariel Barreiro wrote: > Still I can't see how to prevent the attack. I understand that there = is no redirection when requesting an access token, however, the protocol = requests the client to send the redirect_uri to the token end point to = validate it was the same used in the authorization. If the authorization = was compromised, couldn't the access token request be forged as well? >=20 >=20 > On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt = wrote: > There is no redirection when requesting an access token. Token = requests are typically out-of-band from the user. The attack only = happens during an authorization redirect flow in the browser. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: >=20 > > I am struggling a bit to understand this attack and the advice in to = how to prevent. I understand that if I, as an attacker, can change the = redirection uri when authorizing, can not it as well change the redirect = uri when requesting an access token? > > > > Any explanation examples on how this attack might work and how = sending the redirect_uri when requesting the access toekn prevents it = are welcomed. > > > > Thanks, > > Ariel.=3D > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_15740EA3-E0B2-4616-9F37-99E72FC27BC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 A = confidential client authenticates to the token endpoint preventing an = attacker from getting the token.

In the case of a = public client if you get the code and redirect URI then you can get the = token.  (Why confidential clients are better than public = ones)

Sending the redirect URI to the token = endpoint protects the client from the case where client A gets a code = for user B because the user logged into A and A is using the client ID = of client Z because it wants to impersonate user B at client A.   = Client A pretending to be client Z  can easily get the code. =  However the redirect URI that the real client Z sends will be = different than the one the fake client Z used to get code and the real = client A won't be able to exchange the code for a access token and be = tricked into thinking that the resource owner is the one presenting it = the code.

That is the long explanation. =  The short one is unregistered redirect URI are bad.   Sending = the redirect URI to the token endpoint protects clients from becoming = confused about the presenter of the code.
Nothing is going to = help a public client if someone intercepts = code.

John B.

On = 2012-11-29, at 3:05 PM, Ariel Barreiro <abarrei@gmail.com> = wrote:

Still  I can't see how to prevent the attack. I = understand that there is no redirection when requesting an access token, = however, the protocol requests the client to send the redirect_uri to = the token end point to validate it was the same used in the = authorization. If the authorization was compromised, couldn't the access = token request be forged as well?


On Thu, = Nov 29, 2012 at 4:01 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
There is no = redirection when requesting an access token.  Token requests are = typically out-of-band from the user.  The attack only happens = during an authorization redirect flow in the browser.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote:

> I am struggling a bit to understand this attack and the advice in = to how to prevent. I understand that if I, as an attacker, can change = the redirection uri when authorizing, can not it as well change the = redirect uri when requesting an access token?
>
> Any explanation examples on how this attack might work and how = sending the redirect_uri when requesting the access toekn prevents it = are welcomed.
>
> Thanks,
> Ariel.=3D
> _______________________________________________
> 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

= --Apple-Mail=_15740EA3-E0B2-4616-9F37-99E72FC27BC9-- From sberyozkin@gmail.com Thu Nov 29 13:16:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F80F21F8C3F for ; Thu, 29 Nov 2012 13:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0DzIIRLhyOv for ; Thu, 29 Nov 2012 13:16:52 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 967DF21F8C3D for ; Thu, 29 Nov 2012 13:16:51 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so9495650eek.31 for ; Thu, 29 Nov 2012 13:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gwA5UBhvxc/HwJ23Pjok5kZ1hQMBP/CUi0cc5rfZAB0=; b=I+87n/NQ0UTAIoHW/bQIFt/S3wIUYdsqJjanEVDearrIAuVYLFdDlL3GUBO+fY8zAt 3mIWfkv/D7CPA8GWuwUqd0w/CG27tlDt8SxP9zLzyc0ANQdpMmYnPMf61gka30RKm7t/ DFiPn9plMXt3oxte7RqcqnVu9AGjcUaqQWSjTkm4IMiUfmNa8IkNS13iF9bSa6FpnIjZ JYi/ZiSNHzVH0rYQdLQJtHiCKIT/8hcU1acSBRTrqH8CWUzhPoJKi/z+YNclnzSALzBx 7BF6fk3T1Sp7cT6oifqu+jsxe+FhN37dg3DXnuJ0P2aAiVM6on5XZDhWfFjtUqQ75NAh KPZg== Received: by 10.14.218.69 with SMTP id j45mr86064099eep.35.1354223810577; Thu, 29 Nov 2012 13:16:50 -0800 (PST) Received: from [192.168.2.5] ([89.100.140.144]) by mx.google.com with ESMTPS id a44sm6111664eeo.7.2012.11.29.13.16.48 (version=SSLv3 cipher=OTHER); Thu, 29 Nov 2012 13:16:49 -0800 (PST) Message-ID: <50B7D0BE.5000808@gmail.com> Date: Thu, 29 Nov 2012 21:16:46 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "oauth@ietf.org" References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com>, <50ACFC53.5080103@gmail.com> <201211271652159646688@gmail.com> <50B4937C.5030201@gmail.com> <50B4DF1B.4030700@gmail.com> <50B4E9A4.1030508@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F19E386@BY2PRD0411MB441.namprd04.prod.outlook.com> <50B5023B.3060208@gmail.com> In-Reply-To: <50B5023B.3060208@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 21:16:53 -0000 I'd like to return to this thread. After learning about the refresh grant supporting a client-driven down-scoping, the same question which I asked in the first place seems relevant again. If the clients gets 401 back while trying to access PR, how will it know how to react to it (use refresh grant with or without its optional scope parameter), is it because the access token has expired or is it because it has an invalid scope ? Thanks, Sergey On 27/11/12 18:11, Sergey Beryozkin wrote: > Hi Adam, > > thanks for sharing it, helpful, > On 27/11/12 17:24, Lewis Adam-CAL022 wrote: >> Hi Sergey, >> >> In my use cases the client actively monitors the expiration of the AT >> in order to request a new AT using the RT. We do this as you >> suggested, because presenting an expired AT to the RS is a wasted >> round trip and adds latency and degrades the user experience. Why send >> the AT if we know it's expired? >> > > How do you know when the client is expecting a revocation and when a > downscoping, I guess if the client includes and optional 'scope' > parameter then it is down-scoping obviously, otherwise - revocation ? > > If that is the case then IMHO a refresh token grant request without a > scope parameter might offer a shortcut for the client not to worry about > one more endpoint (to do with the revocation) ? > >> As to your other question, one reason to down scope an AT ... in my >> use cases the AS issues access tokens for many different RS's. It is a >> security concern to send an AT to RS1 that has the ability to also >> access protected resources at RS2 and RS3 and RSn, etc. So I make a >> first request to get a "master" AT with a master RT, and then >> immediately destroy the master AT and use the master RT to get a >> down-scoped AT - one for each RS. This is inefficient though, and I've >> been nagging the WG to consider a draft to allow a client to request >> an array of access tokens of different scopes. >> > OK, that makes it clearer. What I'm concerned about though, does the > client need to be concerned or is it the job of AS to protect in cases > where a token with too many scopes is used to access a given RS which > may delegate to a stricter RS ? > > I mean, is client expected to be well-behaved and know about the > relationships between the master RS with the stricter RS1 & RS2 parthers > ? Seems not easy to make it interoperable... > > Guess I'm missing the point still > > Thanks, Sergey > >> These are just my experience, and as Justin mentioned, your millage >> may vary. Hope it helps either way :-) >> >> adam >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Sergey Beryozkin >> Sent: Tuesday, November 27, 2012 10:26 AM >> To: Richer, Justin P. >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] How the client can decide it is time to use >> the refresh token >> >> On 27/11/12 15:48, Richer, Justin P. wrote: >>> Yes, the client can keep two tokens and try using both of them if it >>> wants to. I think that you're conflating revocation and expiration >>> here, and missing a key use case: downscoping. Let's say the client >>> gets an access grant for [A, B, C], and it gets RT and AT1 for those >>> scopes. The client then wants to call a service with *only* scope B, >>> so it sends RT in with scope B in the refresh request to get AT2 with >>> that scope alone. AT1 is still valid, assuming it hasn't expired or >>> otherwise been revoked. The client can choose which AT to present to >>> the protected resources in different situations. >>> >> That is complex :-). Using a refresh token to downscope and keep a >> number of access tokens is definitely beyond my imagination at the >> moment, why would a client want to downscope its access token ? >> >> Is it basically described at: >> http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-03#section-3.10 >> ? >> >> I'm still not getting though why access token with the richer set of >> scopes needs to be explicitly downscoped by the client, is it because >> using a token with a richer set of scopes can lead to some authorization >> issues ? >> >> I was thinking that the down-scoping only makes sense during the >> authorization code flow where AS downscopes what the client has >> requested but obviously I'm only at the start of the learning curve :-). >> >> >> >>> In all of these cases, it's completely up to the AS and the PRs >>> whether or not any of the tokens in the wild are still valid. Your AS >>> might decide that once a RT is used, it will simply throw away all >>> existing AT's attached to that RT. That's totally a valid use case, >>> and the client needs to be able to handle that (in the same way that >>> it handles any invalid token). >>> >>> If you want the clients to explicitly throw out tokens, use the Token >>> Revocation spec. >>> >> OK, that makes sense now. >> >> Thanks, Sergey >> >>> -- Justin >>> >>> On Nov 27, 2012, at 10:41 AM, Sergey Beryozkin wrote: >>> >>>> On 27/11/12 15:29, Richer, Justin P. wrote: >>>>> The client can indeed save a round trip by proactively refreshing >>>>> the access token. This does not necessarily revoke the existing >>>>> access token. Many implementations do that, so your mileage may vary. >>>>> >>>> >>>> I don't understand. >>>> >>>> So the client will still have the existing access token which may >>>> have not been revoked, and then also another access token which was >>>> just returned in response to the refresh grant request ? >>>> >>>> And if you mean that no actual revocation is actually done, why then >>>> have the client worry about doing the proactive refresh ? >>>> >>>> I can imagine that may be that it will only be the actual refresh >>>> token refreshed itself, but why keep the access token if the client >>>> has requested a refresh ? >>>> >>>> Sergey >>>> >>>>> -- Justin >>>>> >>>>> On Nov 27, 2012, at 5:18 AM, Sergey Beryozkin wrote: >>>>> >>>>>> On 27/11/12 08:52, Guangqing Deng wrote: >>>>>>> It seems that the client cannot know whether the refresh token >>>>>>> should be >>>>>>> used until a HTTP 401 error is returned from the resource server >>>>>>> due to >>>>>>> the expiration of current access token or some other reasons. >>>>>>> However, a >>>>>>> period of time cannot be ignored will be spent on obtain a new >>>>>>> access >>>>>>> token using the refresh token after the resource server returns a >>>>>>> HTTP >>>>>>> 401 error to the client, which may degrade the user experience >>>>>>> since the >>>>>>> real-time nature of the service cannot be guaranteed. Is a >>>>>>> mechanism by >>>>>>> which the client can check the validity of the access token (or the >>>>>>> refresh token) in advance needed by Oauth? >>>>>> >>>>>> I believe an access token response may offer an expires_in >>>>>> parameter which can provide some hint. Actually this raises an >>>>>> interesting question. >>>>>> Suppose the client actually checks this parameter and decides to use >>>>>> a refresh token it also has to pro-actively refresh its current >>>>>> token. >>>>>> >>>>>> IMHO this should work even if the access token has not expired yet >>>>>> and effectively represents another form of a client-initiated >>>>>> revocation of the access token ? It will mean a client which works >>>>>> with the "expires_in" parameter can save a one round trip (the one >>>>>> which returns a failure in case of the access token being expired) ? >>>>>> >>>>>> Does it make sense ? If it does, can some relevant wording make it >>>>>> into the revocation token draft ? >>>>>> >>>>>> Cheers, Sergey >>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> Guangqing Deng >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> *From:* Justin Richer >>>>>>>> *To:* Sergey Beryozkin >>>>>>>> *Cc:* oauth@ietf.org >>>>>>>> *Sent:* Wednesday, November 21, 2012 6:11 AM >>>>>>>> *Subject:* Re: [OAUTH-WG] How the client can decide it is time >>>>>>>> to use >>>>>>>> the refresh token >>>>>>>> >>>>>>>> There's no signaling regarding the validity of the refresh token >>>>>>>> from >>>>>>>> the protected resource. In more distributed setups, the protected >>>>>>>> resources know nothing about the refresh tokens because the PR >>>>>>>> never >>>>>>>> sees them. In any case. the code path is fairly straightforward, >>>>>>>> even if >>>>>>>> both tokens are expired: >>>>>>>> >>>>>>>> - client presents AT to resource >>>>>>>> - resource returns data, AT worked >>>>>>>> - [or] resource returns 400 error to client, AT didn't work >>>>>>>> - client presents RT to auth server >>>>>>>> - auth server returns new AT, RT worked >>>>>>>> - [or] auth server returns 400 error to client, RT didn't work >>>>>>>> - client has to go get a new auth grant from the resource owner, >>>>>>> start over >>>>>>>> >>>>>>>> -- Justin >>>>>>>> >>>>>>>> >>>>>>>> On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> I'm looking for some guidance on how the client which already >>>>>>>>> owns an >>>>>>>> access token can decide, after getting HTTP 400 back from the >>>>>>>> resource >>>>>>>> server it tries to access on behalf of the end user/resource >>>>>>>> owner, can >>>>>>>> decide that the refresh token it has can now be used to get a >>>>>>>> new access >>>>>>>> token. >>>>>>>>> >>>>>>>>> [1] refers to various error conditions but it is not obvious to me >>>>>>>> that the same conditions (some of them) should or can be >>>>>>>> reported during >>>>>>>> the actual client accessing the protected resource. >>>>>>>>> >>>>>>>>> My question is, what error condition, if any, from [1] should be >>>>>>>> reported back to the client failing to access a protected >>>>>>>> resource due >>>>>>>> to the access token being invalid or expired, so that it can >>>>>>>> help the >>>>>>>> client who also owns the refresh token to decide it can use it >>>>>>>> now... >>>>>>>>> >>>>>>>>> Thanks, Sergey >>>>>>>>> >>>>>>>>> [1] http://tools.ietf.org/html/rfc6749#section-5.2 >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >> >> >> >> >> > From abarrei@gmail.com Thu Nov 29 13:25:26 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5E021F84F2 for ; Thu, 29 Nov 2012 13:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2297SCWq4AO for ; Thu, 29 Nov 2012 13:25:25 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1455221F85C3 for ; Thu, 29 Nov 2012 13:25:18 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so12223085iaf.31 for ; Thu, 29 Nov 2012 13:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UeljDCYkrJzcVtKh7NFZ6vidcnLRgkjPAU/1uTuQqrQ=; b=r50txI1BLdo++YMGSDqzX2oH/FKCOnD2Fg8gTPagaT9yyhlDIJ0ADng49HhRhpNozx fGmKm/MzS551PQOYHX+IRoOGQAiNV9jDnOMN3O4iRlPNWv8H/dtX76S49ItmR37XGssI 07SEylfmP3L6oJFpVtlcaV4Ipakq63UWArn1m9wi/ftMNsiyUXZk8wngLu69heCg5KNQ BCXtYTPdrrm4zJX4tA4uJGEFLPwrVpzajginx9gQJVn8EToZqcQuC9i+itlSDnIT/9m1 a/DxoKIailzfzKg1GnhcfQsWVLtjqQOAS579l9KSp0WHxudDniwChiVw/AbODKJ+DAkE OciQ== Received: by 10.50.7.232 with SMTP id m8mr24044152iga.48.1354224316594; Thu, 29 Nov 2012 13:25:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.76.167 with HTTP; Thu, 29 Nov 2012 13:24:56 -0800 (PST) In-Reply-To: References: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> From: Ariel Barreiro Date: Thu, 29 Nov 2012 18:24:56 -0300 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=f46d04462dd2563a5b04cfa8eba5 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 21:25:26 -0000 --f46d04462dd2563a5b04cfa8eba5 Content-Type: text/plain; charset=ISO-8859-1 But isn't having a registered redirect URI on the authorization end point enought to prevent this, why is it required to send the redirect URI to the token end point if the previous method prevents it? I appreciate a lot your response but I am still finding it hard to picture it, and, was in your explanation a modification to the request URI? On Thu, Nov 29, 2012 at 6:25 PM, John Bradley wrote: > A confidential client authenticates to the token endpoint preventing an > attacker from getting the token. > > In the case of a public client if you get the code and redirect URI then > you can get the token. (Why confidential clients are better than public > ones) > > Sending the redirect URI to the token endpoint protects the client from > the case where client A gets a code for user B because the user logged into > A and A is using the client ID of client Z because it wants to impersonate > user B at client A. Client A pretending to be client Z can easily get > the code. However the redirect URI that the real client Z sends will be > different than the one the fake client Z used to get code and the real > client A won't be able to exchange the code for a access token and be > tricked into thinking that the resource owner is the one presenting it the > code. > > That is the long explanation. The short one is unregistered redirect URI > are bad. Sending the redirect URI to the token endpoint protects clients > from becoming confused about the presenter of the code. > Nothing is going to help a public client if someone intercepts code. > > John B. > > On 2012-11-29, at 3:05 PM, Ariel Barreiro wrote: > > Still I can't see how to prevent the attack. I understand that there is > no redirection when requesting an access token, however, the protocol > requests the client to send the redirect_uri to the token end point to > validate it was the same used in the authorization. If the authorization > was compromised, couldn't the access token request be forged as well? > > > On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt wrote: > >> There is no redirection when requesting an access token. Token requests >> are typically out-of-band from the user. The attack only happens during an >> authorization redirect flow in the browser. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: >> >> > I am struggling a bit to understand this attack and the advice in to >> how to prevent. I understand that if I, as an attacker, can change the >> redirection uri when authorizing, can not it as well change the redirect >> uri when requesting an access token? >> > >> > Any explanation examples on how this attack might work and how sending >> the redirect_uri when requesting the access toekn prevents it are welcomed. >> > >> > Thanks, >> > Ariel.= >> > _______________________________________________ >> > 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 > > > --f46d04462dd2563a5b04cfa8eba5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable But isn't having a registered redirect URI on the authorization end poi= nt enought to prevent this, why is it required to send the redirect URI to = the token end point if the previous method prevents it?

I appreciate a lot your response but I am still finding it hard to picture = it, and, was in your explanation a modification to the request URI?


On Thu, Nov 29,= 2012 at 6:25 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
A confid= ential client authenticates to the token endpoint preventing an attacker fr= om getting the token.

In the case of a public client if you get the code and redir= ect URI then you can get the token. =A0(Why confidential clients are better= than public ones)

Sending the redirect URI to the= token endpoint protects the client from the case where client A gets a cod= e for user B because the user logged into A and A is using the client ID of= client Z because it wants to impersonate user B at client A. =A0 Client A = pretending to be client Z =A0can easily get the code. =A0However the redire= ct URI that the real client Z sends will be different than the one the fake= client Z used to get code and the real client A won't be able to excha= nge the code for a access token and be tricked into thinking that the resou= rce owner is the one presenting it the code.

That is the long explanation. =A0The short one is unreg= istered redirect URI are bad. =A0 Sending the redirect URI to the token end= point protects clients from becoming confused about the presenter of the co= de.
Nothing is going to help a public client if someone intercepts code.

John B.

<= div>On 2012-11-29, at 3:05 PM, Ariel Barreiro <abarrei@gmail.com> wrote:

Still =A0I can't see how to prevent the a= ttack. I understand that there is no redirection when requesting an access = token, however, the protocol requests the client to send the redirect_uri t= o the token end point to validate it was the same used in the authorization= . If the authorization was compromised, couldn't the access token reque= st be forged as well?


On Thu, Nov 2= 9, 2012 at 4:01 PM, Phil Hunt <phil.hunt@oracle.com> wrot= e:
There is no redirection when requesting an a= ccess token. =A0Token requests are typically out-of-band from the user. =A0= The attack only happens during an authorization redirect flow in the browse= r.

Phil

@independentid
www.independent= id.com
phil.hunt@oracle.= com





On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote:

> I am struggling a bit to understand this attack and the advice in to h= ow to prevent. I understand that if I, as an attacker, can change the redir= ection uri when authorizing, can not it as well change the redirect uri whe= n requesting an access token?
>
> Any explanation examples on how this attack might work and how sending= the redirect_uri when requesting the access toekn prevents it are welcomed= .
>
> Thanks,
> Ariel.=3D
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth


--f46d04462dd2563a5b04cfa8eba5-- From jricher@mitre.org Thu Nov 29 13:37:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8170C21F8C57 for ; Thu, 29 Nov 2012 13:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYyDm7RaCD1N for ; Thu, 29 Nov 2012 13:37:28 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id CD29A21F8C5A for ; Thu, 29 Nov 2012 13:37:21 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 492A11F066B; Thu, 29 Nov 2012 16:37:18 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DC0A71F0643; Thu, 29 Nov 2012 16:37:17 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 29 Nov 2012 16:37:17 -0500 Message-ID: <50B7D531.4040005@mitre.org> Date: Thu, 29 Nov 2012 16:35:45 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ariel Barreiro References: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020607060109050003060100" X-Originating-IP: [129.83.31.58] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 21:37:29 -0000 --------------020607060109050003060100 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit So here's the breakdown of how the redirect uri works: - If the client sends a redirect URI to the auth endpoint, and the client has registered one or more redirect URIs, it MUST match one of the redirect URIs it had registered. (for a soft definition of "match" -- it can be prefix, or pattern, or exact string, so long as the AS knows how to do it, IIRC) - If the client does not send a redirect URI to the auth endpoint, and the client has either only registered one or the AS has some notion of a "default" redirect URI, the AS will just use that one. Now the part that seems to trip people up: - If the client had sent a redirect URI to the auth endpoint, then it MUST send the EXACT SAME redirect URI to the token endpoint. This request is back-channel and protected with the client's credentials. - If the client did not send a redirect URI to the auth endpoint, then it does NOT send a redirect URI to the token endpoint. So here's where the protection comes in. If the attacker modifies the request to the auth endpoint so that it has a different redirect URI, then that redirect URI MUST match one that's attached to the client_id in the request. Furthermore, the call to the token endpoint to get the token MUST also contain that modified redirect URI as well as any client credentials needed to make the call. A "good" client will send a "good" redirect URI, even if the code has been sent someplace else in the mean time. Hope this clears things up, -- Justin On 11/29/2012 04:24 PM, Ariel Barreiro wrote: > But isn't having a registered redirect URI on the authorization end > point enought to prevent this, why is it required to send the redirect > URI to the token end point if the previous method prevents it? > > I appreciate a lot your response but I am still finding it hard to > picture it, and, was in your explanation a modification to the request > URI? > > > On Thu, Nov 29, 2012 at 6:25 PM, John Bradley > wrote: > > A confidential client authenticates to the token endpoint > preventing an attacker from getting the token. > > In the case of a public client if you get the code and redirect > URI then you can get the token. (Why confidential clients are > better than public ones) > > Sending the redirect URI to the token endpoint protects the client > from the case where client A gets a code for user B because the > user logged into A and A is using the client ID of client Z > because it wants to impersonate user B at client A. Client A > pretending to be client Z can easily get the code. However the > redirect URI that the real client Z sends will be different than > the one the fake client Z used to get code and the real client A > won't be able to exchange the code for a access token and be > tricked into thinking that the resource owner is the one > presenting it the code. > > That is the long explanation. The short one is unregistered > redirect URI are bad. Sending the redirect URI to the token > endpoint protects clients from becoming confused about the > presenter of the code. > Nothing is going to help a public client if someone intercepts code. > > John B. > > On 2012-11-29, at 3:05 PM, Ariel Barreiro > wrote: > >> Still I can't see how to prevent the attack. I understand that >> there is no redirection when requesting an access token, however, >> the protocol requests the client to send the redirect_uri to the >> token end point to validate it was the same used in the >> authorization. If the authorization was compromised, couldn't the >> access token request be forged as well? >> >> >> On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt > > wrote: >> >> There is no redirection when requesting an access token. >> Token requests are typically out-of-band from the user. The >> attack only happens during an authorization redirect flow in >> the browser. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: >> >> > I am struggling a bit to understand this attack and the >> advice in to how to prevent. I understand that if I, as an >> attacker, can change the redirection uri when authorizing, >> can not it as well change the redirect uri when requesting an >> access token? >> > >> > Any explanation examples on how this attack might work and >> how sending the redirect_uri when requesting the access toekn >> prevents it are welcomed. >> > >> > Thanks, >> > Ariel.= >> > _______________________________________________ >> > 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 --------------020607060109050003060100 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
So here's the breakdown of how the redirect uri works:



- If the client sends a redirect URI to the auth endpoint, and the client has registered one or more redirect URIs, it MUST match one of the redirect URIs it had registered. (for a soft definition of "match" -- it can be prefix, or pattern, or exact string, so long as the AS knows how to do it, IIRC)
- If the client does not send a redirect URI to the auth endpoint, and the client has either only registered one or the AS has some notion of a "default" redirect URI, the AS will just use that one.

Now the part that seems to trip people up:

- If the client had sent a redirect URI to the auth endpoint, then it MUST send the EXACT SAME redirect URI to the token endpoint. This request is back-channel and protected with the client's credentials.
- If the client did not send a redirect URI to the auth endpoint, then it does NOT send a redirect URI to the token endpoint.


So here's where the protection comes in. If the attacker modifies the request to the auth endpoint so that it has a different redirect URI, then that redirect URI MUST match one that's attached to the client_id in the request. Furthermore, the call to the token endpoint to get the token MUST also contain that modified redirect URI as well as any client credentials needed to make the call. A "good" client will send a "good" redirect URI, even if the code has been sent someplace else in the mean time.

Hope this clears things up,

 -- Justin

On 11/29/2012 04:24 PM, Ariel Barreiro wrote:
But isn't having a registered redirect URI on the authorization end point enought to prevent this, why is it required to send the redirect URI to the token end point if the previous method prevents it?

I appreciate a lot your response but I am still finding it hard to picture it, and, was in your explanation a modification to the request URI?


On Thu, Nov 29, 2012 at 6:25 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
A confidential client authenticates to the token endpoint preventing an attacker from getting the token.

In the case of a public client if you get the code and redirect URI then you can get the token.  (Why confidential clients are better than public ones)

Sending the redirect URI to the token endpoint protects the client from the case where client A gets a code for user B because the user logged into A and A is using the client ID of client Z because it wants to impersonate user B at client A.   Client A pretending to be client Z  can easily get the code.  However the redirect URI that the real client Z sends will be different than the one the fake client Z used to get code and the real client A won't be able to exchange the code for a access token and be tricked into thinking that the resource owner is the one presenting it the code.

That is the long explanation.  The short one is unregistered redirect URI are bad.   Sending the redirect URI to the token endpoint protects clients from becoming confused about the presenter of the code.
Nothing is going to help a public client if someone intercepts code.

John B.

On 2012-11-29, at 3:05 PM, Ariel Barreiro <abarrei@gmail.com> wrote:

Still  I can't see how to prevent the attack. I understand that there is no redirection when requesting an access token, however, the protocol requests the client to send the redirect_uri to the token end point to validate it was the same used in the authorization. If the authorization was compromised, couldn't the access token request be forged as well?


On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
There is no redirection when requesting an access token.  Token requests are typically out-of-band from the user.  The attack only happens during an authorization redirect flow in the browser.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote:

> I am struggling a bit to understand this attack and the advice in to how to prevent. I understand that if I, as an attacker, can change the redirection uri when authorizing, can not it as well change the redirect uri when requesting an access token?
>
> Any explanation examples on how this attack might work and how sending the redirect_uri when requesting the access toekn prevents it are welcomed.
>
> Thanks,
> Ariel.=
> _______________________________________________
> 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

--------------020607060109050003060100-- From sberyozkin@gmail.com Thu Nov 29 13:38:08 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C461521F8C65 for ; Thu, 29 Nov 2012 13:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eedtAG0U-qRX for ; Thu, 29 Nov 2012 13:38:08 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0B34621F8C57 for ; Thu, 29 Nov 2012 13:38:07 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so4952141wey.31 for ; Thu, 29 Nov 2012 13:38:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=dOXYNCHqhnvdSIHXnU2RkUZiOnL4OxzBh/aPh6WWYuc=; b=0F4F8TpYvbunVO5BVTjN697TzRuYOq0UmfoqqE+8GVdzjf5fY0i/FSbtczmDfB2UEQ qRyi/1kvn23dGpeRi6lf8XmaRsnUulGahHmVYSUq8O+sy6OhQCPMa4UbGa50xs0elaLG X1xdIXH7CY4Vm7oepQYE5UIyAXSI1H4XEInkopIQv+wZK1zsB5O/qcz7XXRmY7I3mXSu 2r27D77YVy+t+HfJh9IZSraUTqCSpvUjPiwc+yuWf3ngB87m9zCF2ULcat/Kh+88ZTI0 I2J8bUUagsdyQTWOKg9w5MyQJ9zURGn+eIwP8NCOYskhCg2SNQsKip6L5OI97bH/34Dl 3xKg== Received: by 10.180.103.106 with SMTP id fv10mr37341752wib.19.1354225087195; Thu, 29 Nov 2012 13:38:07 -0800 (PST) Received: from [192.168.2.5] ([89.100.140.144]) by mx.google.com with ESMTPS id e6sm12818614wiy.4.2012.11.29.13.38.05 (version=SSLv3 cipher=OTHER); Thu, 29 Nov 2012 13:38:06 -0800 (PST) Message-ID: <50B7D5BC.3090805@gmail.com> Date: Thu, 29 Nov 2012 21:38:04 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Refresh grant and token revocation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 21:38:08 -0000 Apologies for a noise on it, however I'd like to get some more clarifications on it. What I thought first about the refresh grant was that a client would use it for getting a new access token back after it gets a 401 back from PR. Next after seeing the comments from others it became obvious the refresh grant can be used to pro-actively refresh the existing token when the client realizes - this is what I'm really going to ask about. I also learned about the fact a refresh grant can effectively be used to clone the existing token - I'd like to avoid talking about this case in this thread, even I got it wrong with the term 'clone' :-) So, as far as the refresh token grant is concerned, the grant which is 'supported' by the core spec, what are the expectations of the client which request to refresh a still valid access token ? I got a bit confused by the feedback that it may be per-AS specific. If it were the expectation then I'd not see the difference between the core spec "refresh_token" grant and "a.b.c" custom grant. It seems reasonable that if the client does decide to be proactive and use a refresh grant without using any optional scopes, and specifically with the main and only purpose to refresh the access token which may get expired shortly, it should predictably get a new access token with a new time lease... And which means the old token must've gone by now and effectively revoked. This exactly what the client means, get me a new refreshed token... I've checked the token revocation grant. It's obviously a good idea to let the client directly interact with the endpoint and remove whatever token it want to remove. However, a refresh token request (without a scope parameter) should have the same side-effect Does it make any sense at all ? Thanks, Sergey From ve7jtb@ve7jtb.com Thu Nov 29 13:41:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D9521F8C5B for ; Thu, 29 Nov 2012 13:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.176 X-Spam-Level: X-Spam-Status: No, score=-3.176 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBPGFrvggSiT for ; Thu, 29 Nov 2012 13:40:59 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC3B21F8C5A for ; Thu, 29 Nov 2012 13:40:59 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so3237371obq.31 for ; Thu, 29 Nov 2012 13:40:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Mi3yV98yzkhxYcoE8YHBiL6h1/eSwBmEnmC8PuYXZoQ=; b=CZRr0VXYuc+imetdhybueju7hGQGQKUr0kS7djHtM0W4n8Gd4idK91gBiP6/v8d8qY H4WFEt0HR/y7zqH+ZX4XpqNlpFXS1dBhOZloB8NWF1JYqHrR8hS5pEed8kcsmkdNztPK I4z/vqKzmbJ7DHwZqVlksq+kWvpw93kxuw4pccImYVU4tI0VAjlA1Rs1XbU4+0bsbQxk 97GeMuYos+eNTP5CWuM0b73B8XBoZ1XSg2Sd6Ip/CvSEZ+EHf+QJyF+hrhDm4kSh0Uvw ZzscKqwE92Hq3Zd3UJfP+3jVkk9xhTSNmQbtubD/BZf+D2gQYpkhM5juh/wd0erMVyPZ 7aPA== Received: by 10.60.171.141 with SMTP id au13mr2903512oec.124.1354225258778; Thu, 29 Nov 2012 13:40:58 -0800 (PST) Received: from [192.168.1.211] (190-20-53-20.baf.movistar.cl. [190.20.53.20]) by mx.google.com with ESMTPS id b6sm2400531oee.3.2012.11.29.13.40.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Nov 2012 13:40:57 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_661181D5-B44E-4058-8D80-B0574C0316A0" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Thu, 29 Nov 2012 18:39:58 -0300 Message-Id: <91017C0A-1E8E-47AB-9EA2-2DB91ABD4785@ve7jtb.com> References: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> To: Ariel Barreiro X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkVbEzkPBOkW1Sd0z1/1v+0SX85eH6D2TOiltLzP6udM/jzvnYywjWkjfj8o54xRhjljHtN Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 21:41:00 -0000 --Apple-Mail=_661181D5-B44E-4058-8D80-B0574C0316A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Sending it to the token endpoint is only supposed to be required when = you are not using a registered redirect URI. Some authorization servers always require it, that is allowed by the = spec but not required.=20 Unregistered redirect URI were intended to allow deep linking or = embedding other arbitrary query parameters in the redirect URI.=20 Those things should be in state but some people wanted this alternative. John B. On 2012-11-29, at 6:24 PM, Ariel Barreiro wrote: > But isn't having a registered redirect URI on the authorization end = point enought to prevent this, why is it required to send the redirect = URI to the token end point if the previous method prevents it? >=20 > I appreciate a lot your response but I am still finding it hard to = picture it, and, was in your explanation a modification to the request = URI? >=20 >=20 > On Thu, Nov 29, 2012 at 6:25 PM, John Bradley = wrote: > A confidential client authenticates to the token endpoint preventing = an attacker from getting the token. >=20 > In the case of a public client if you get the code and redirect URI = then you can get the token. (Why confidential clients are better than = public ones) >=20 > Sending the redirect URI to the token endpoint protects the client = from the case where client A gets a code for user B because the user = logged into A and A is using the client ID of client Z because it wants = to impersonate user B at client A. Client A pretending to be client Z = can easily get the code. However the redirect URI that the real client = Z sends will be different than the one the fake client Z used to get = code and the real client A won't be able to exchange the code for a = access token and be tricked into thinking that the resource owner is the = one presenting it the code. >=20 > That is the long explanation. The short one is unregistered redirect = URI are bad. Sending the redirect URI to the token endpoint protects = clients from becoming confused about the presenter of the code. > Nothing is going to help a public client if someone intercepts code. >=20 > John B. >=20 > On 2012-11-29, at 3:05 PM, Ariel Barreiro wrote: >=20 >> Still I can't see how to prevent the attack. I understand that there = is no redirection when requesting an access token, however, the protocol = requests the client to send the redirect_uri to the token end point to = validate it was the same used in the authorization. If the authorization = was compromised, couldn't the access token request be forged as well? >>=20 >>=20 >> On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt = wrote: >> There is no redirection when requesting an access token. Token = requests are typically out-of-band from the user. The attack only = happens during an authorization redirect flow in the browser. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: >>=20 >> > I am struggling a bit to understand this attack and the advice in = to how to prevent. I understand that if I, as an attacker, can change = the redirection uri when authorizing, can not it as well change the = redirect uri when requesting an access token? >> > >> > Any explanation examples on how this attack might work and how = sending the redirect_uri when requesting the access toekn prevents it = are welcomed. >> > >> > Thanks, >> > Ariel.=3D >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail=_661181D5-B44E-4058-8D80-B0574C0316A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 abarrei@gmail.com> = wrote:

But isn't having a registered redirect URI on the = authorization end point enought to prevent this, why is it required to = send the redirect URI to the token end point if the previous method = prevents it?

I appreciate a lot your response but I am still finding it hard to = picture it, and, was in your explanation a modification to the request = URI?


On= Thu, Nov 29, 2012 at 6:25 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
A confidential client authenticates to = the token endpoint preventing an attacker from getting the token.

In the case of a public client if you get the code and = redirect URI then you can get the token.  (Why confidential clients = are better than public ones)

Sending the = redirect URI to the token endpoint protects the client from the case = where client A gets a code for user B because the user logged into A and = A is using the client ID of client Z because it wants to impersonate = user B at client A.   Client A pretending to be client Z  can = easily get the code.  However the redirect URI that the real client = Z sends will be different than the one the fake client Z used to get = code and the real client A won't be able to exchange the code for a = access token and be tricked into thinking that the resource owner is the = one presenting it the code.

That is the long explanation.  The short one is = unregistered redirect URI are bad.   Sending the redirect URI to = the token endpoint protects clients from becoming confused about the = presenter of the code.
Nothing is going to help a public client if someone intercepts = code.

John B.

On 2012-11-29, at 3:05 PM, Ariel Barreiro = <abarrei@gmail.com> wrote:

Still  I can't see how to prevent the = attack. I understand that there is no redirection when requesting an = access token, however, the protocol requests the client to send the = redirect_uri to the token end point to validate it was the same used in = the authorization. If the authorization was compromised, couldn't the = access token request be forged as well?


On Thu, = Nov 29, 2012 at 4:01 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
There is no = redirection when requesting an access token.  Token requests are = typically out-of-band from the user.  The attack only happens = during an authorization redirect flow in the browser.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote:

> I am struggling a bit to understand this attack and the advice in = to how to prevent. I understand that if I, as an attacker, can change = the redirection uri when authorizing, can not it as well change the = redirect uri when requesting an access token?
>
> Any explanation examples on how this attack might work and how = sending the redirect_uri when requesting the access toekn prevents it = are welcomed.
>
> Thanks,
> Ariel.=3D
> _______________________________________________
> 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



= --Apple-Mail=_661181D5-B44E-4058-8D80-B0574C0316A0-- From abarrei@gmail.com Thu Nov 29 13:44:09 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576C721F8C66 for ; Thu, 29 Nov 2012 13:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I+hiTWvw5So for ; Thu, 29 Nov 2012 13:44:08 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBC821F8C61 for ; Thu, 29 Nov 2012 13:44:08 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so16690261ieb.31 for ; Thu, 29 Nov 2012 13:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=S6U+yf/6ZkijcdloAsemRh9rdS70Yf+zUARHtrvjhUY=; b=GV04Oquim/JhCGv9a+K9Td1qk7eaE/BzzfASKHvjY3gh/yiU+1RrPr/bCG4cZubNZI PAzTqkaaAzFxxdEP2PjmSWjWZQB0F7kAoEczKhIvHpM23PgQ/IxM01FRF/fc/OPAfbFQ Q1Fs3YMppGoS0wi6oxYliHubNwMdVahRHQkCPvwKU+K9LIou/+vFXduuxTHAaWS37suj PNd+LS+lx/bjLkYhQw+6Q3bl+9CeEAniGN43WmHcnALSnSPcf3/28RW7Il+HnufNCsPL w4kaSD6dNzsoqPw3PBqEJKcqOMNp1tRoDXoRLuYCIggfe1ze/wCGKxiDcx35zSPXcGMX VSyA== Received: by 10.50.5.177 with SMTP id t17mr24142246igt.48.1354225444932; Thu, 29 Nov 2012 13:44:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.76.167 with HTTP; Thu, 29 Nov 2012 13:43:44 -0800 (PST) In-Reply-To: <50B7D531.4040005@mitre.org> References: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> <50B7D531.4040005@mitre.org> From: Ariel Barreiro Date: Thu, 29 Nov 2012 18:43:44 -0300 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=e89a8f646e41974d2204cfa92e83 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 21:44:09 -0000 --e89a8f646e41974d2204cfa92e83 Content-Type: text/plain; charset=ISO-8859-1 But so the protection of sending the SAME redirect_uri in both the auth end point and token end point makes not much of a sense when there is a registered URI, and if there's not, an attacker, as far as I understood, can compromise both the request to the auth end point as well as the token end point, so I would assume that it doesn't make much sense either. On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer wrote: > So here's the breakdown of how the redirect uri works: > > > > - If the client sends a redirect URI to the auth endpoint, and the client > has registered one or more redirect URIs, it MUST match one of the redirect > URIs it had registered. (for a soft definition of "match" -- it can be > prefix, or pattern, or exact string, so long as the AS knows how to do it, > IIRC) > - If the client does not send a redirect URI to the auth endpoint, and the > client has either only registered one or the AS has some notion of a > "default" redirect URI, the AS will just use that one. > > Now the part that seems to trip people up: > > - If the client had sent a redirect URI to the auth endpoint, then it MUST > send the EXACT SAME redirect URI to the token endpoint. This request is > back-channel and protected with the client's credentials. > - If the client did not send a redirect URI to the auth endpoint, then it > does NOT send a redirect URI to the token endpoint. > > > So here's where the protection comes in. If the attacker modifies the > request to the auth endpoint so that it has a different redirect URI, then > that redirect URI MUST match one that's attached to the client_id in the > request. Furthermore, the call to the token endpoint to get the token MUST > also contain that modified redirect URI as well as any client credentials > needed to make the call. A "good" client will send a "good" redirect URI, > even if the code has been sent someplace else in the mean time. > > Hope this clears things up, > > -- Justin > > > On 11/29/2012 04:24 PM, Ariel Barreiro wrote: > > But isn't having a registered redirect URI on the authorization end point > enought to prevent this, why is it required to send the redirect URI to the > token end point if the previous method prevents it? > > I appreciate a lot your response but I am still finding it hard to > picture it, and, was in your explanation a modification to the request URI? > > > On Thu, Nov 29, 2012 at 6:25 PM, John Bradley wrote: > >> A confidential client authenticates to the token endpoint preventing an >> attacker from getting the token. >> >> In the case of a public client if you get the code and redirect URI >> then you can get the token. (Why confidential clients are better than >> public ones) >> >> Sending the redirect URI to the token endpoint protects the client from >> the case where client A gets a code for user B because the user logged into >> A and A is using the client ID of client Z because it wants to impersonate >> user B at client A. Client A pretending to be client Z can easily get >> the code. However the redirect URI that the real client Z sends will be >> different than the one the fake client Z used to get code and the real >> client A won't be able to exchange the code for a access token and be >> tricked into thinking that the resource owner is the one presenting it the >> code. >> >> That is the long explanation. The short one is unregistered redirect >> URI are bad. Sending the redirect URI to the token endpoint protects >> clients from becoming confused about the presenter of the code. >> Nothing is going to help a public client if someone intercepts code. >> >> John B. >> >> On 2012-11-29, at 3:05 PM, Ariel Barreiro wrote: >> >> Still I can't see how to prevent the attack. I understand that there is >> no redirection when requesting an access token, however, the protocol >> requests the client to send the redirect_uri to the token end point to >> validate it was the same used in the authorization. If the authorization >> was compromised, couldn't the access token request be forged as well? >> >> >> On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt wrote: >> >>> There is no redirection when requesting an access token. Token requests >>> are typically out-of-band from the user. The attack only happens during an >>> authorization redirect flow in the browser. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: >>> >>> > I am struggling a bit to understand this attack and the advice in to >>> how to prevent. I understand that if I, as an attacker, can change the >>> redirection uri when authorizing, can not it as well change the redirect >>> uri when requesting an access token? >>> > >>> > Any explanation examples on how this attack might work and how sending >>> the redirect_uri when requesting the access toekn prevents it are welcomed. >>> > >>> > Thanks, >>> > Ariel.= >>> > _______________________________________________ >>> > 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > --e89a8f646e41974d2204cfa92e83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable But so the protection of sending the SAME redirect_uri in both the auth end= point and token end point makes not much of a sense when there is a regist= ered URI, and if there's not, an attacker, as far as I understood, can = compromise both the request to the auth end point as well as the token end = point, so I would assume that it doesn't make much sense either.


On Thu, Nov 29, 2012 at 7:35 PM, Justin = Richer <jricher@mitre.org> wrote:
=20 =20 =20
So here's the breakdown of how the redirect uri works:



- If the client sends a redirect URI to the auth endpoint, and the client has registered one or more redirect URIs, it MUST match one of the redirect URIs it had registered. (for a soft definition of "match" -- it can be prefix, or pattern, or exact string, s= o long as the AS knows how to do it, IIRC)
- If the client does not send a redirect URI to the auth endpoint, and the client has either only registered one or the AS has some notion of a "default" redirect URI, the AS will just use th= at one.

Now the part that seems to trip people up:

- If the client had sent a redirect URI to the auth endpoint, then it MUST send the EXACT SAME redirect URI to the token endpoint. This request is back-channel and protected with the client's credentials.
- If the client did not send a redirect URI to the auth endpoint, then it does NOT send a redirect URI to the token endpoint.


So here's where the protection comes in. If the attacker modifies the request to the auth endpoint so that it has a different redirect URI, then that redirect URI MUST match one that's attached to the client_id in the request. Furthermore, the call to the token endpoint to get the token MUST also contain that modified redirect URI as well as any client credentials needed to make the call. A "good" client will send a "good"= redirect URI, even if the code has been sent someplace else in the mean time.

Hope this clears things up,

=A0-- Justin


On 11/29/2012 04:24 PM, Ariel Barreiro wrote:
=20 But isn't having a registered redirect URI on the authorization end point enought to prevent this, why is it required to send the redirect URI to the token end point if the previous method prevents it?

I appreciate a lot your response but I am still finding it hard to picture it, and, was in your explanation a modification to the request URI?


On Thu, Nov 29, 2012 at 6:25 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
A confidential client authenticates to the token endpoint preventing an attacker from getting the token.

In the case of a public client if you get the code and redirect URI then you can get the token. =A0(Why confidential clients are better than public ones)

Sending the redirect URI to the token endpoint protects the client from the case where client A gets a code for user B because the user logged into A and A is using the client ID of client Z because it wants to impersonate user B at client A. =A0 Client A pretending to be client Z =A0can easily get the code. =A0However the redirect URI that the real client Z sends will be different than the one the fake client Z used to get code and the real client A won't be able to exchange th= e code for a access token and be tricked into thinking that the resource owner is the one presenting it the code.

That is the long explanation. =A0The short one is unregistered redirect URI are bad. =A0 Sending the redirect URI to the token endpoint protects clients from becoming confused about the presenter of the code.
Nothing is going to help a public client if someone intercepts code.

John B.

On 2012-11-29, at 3:05 PM, Ariel Barreiro <abarrei@gmail.com> wrote:

Still =A0I can't see ho= w to prevent the attack. I understand that there is no redirection when requesting an access token, however, the protocol requests the client to send the redirect_uri to the token end point to validate it was the same used in the authorization. If the authorization was compromised, couldn't the access token request be forged as well?


On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt = <phil.hunt@ora= cle.com> wrote:
There is no redirection when requesting an access token. =A0Token requests are typically out-of-band from the user. =A0The attack only happens during an authorization redirect flow in the browser.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote:

> I am struggling a bit to understand this attack and the advice in to how to prevent. I understand that if I, as an attacker, can change the redirection uri when authorizing, can not it as well change the redirect uri when requesting an access token?
>
> Any explanation examples on how this attack might work and how sending the redirect_uri when requesting the access toekn prevents it are welcomed. >
> Thanks,
> Ariel.=3D
> ___________________________________________= ____
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/o= auth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth


--e89a8f646e41974d2204cfa92e83-- From jricher@mitre.org Thu Nov 29 13:46:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB2A21F887F for ; Thu, 29 Nov 2012 13:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hanr07BcK8tS for ; Thu, 29 Nov 2012 13:46:18 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4080421F87F6 for ; Thu, 29 Nov 2012 13:46:18 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B65121F0630; Thu, 29 Nov 2012 16:46:17 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9CD231F067C; Thu, 29 Nov 2012 16:46:17 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 29 Nov 2012 16:46:17 -0500 Message-ID: <50B7D74D.6090401@mitre.org> Date: Thu, 29 Nov 2012 16:44:45 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ariel Barreiro References: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> <50B7D531.4040005@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080305020402040604030306" X-Originating-IP: [129.83.31.58] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 21:46:20 -0000 --------------080305020402040604030306 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit The request to the auth endpoint is front channel, through a browser. The request to the token endpoint is back channel, server-to-server. These are very, very different attack surfaces. If an attacker has access to and control of both channels, you're pretty hosed anyway and OAuth (nor TLS, nor basically anything else I can think of) will help you. The security model in OAuth comes from limiting the knowledge at each part of the transaction and spreading the risk appropriately. -- Justin On 11/29/2012 04:43 PM, Ariel Barreiro wrote: > But so the protection of sending the SAME redirect_uri in both the > auth end point and token end point makes not much of a sense when > there is a registered URI, and if there's not, an attacker, as far as > I understood, can compromise both the request to the auth end point as > well as the token end point, so I would assume that it doesn't make > much sense either. > > > On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer > wrote: > > So here's the breakdown of how the redirect uri works: > > > > - If the client sends a redirect URI to the auth endpoint, and the > client has registered one or more redirect URIs, it MUST match one > of the redirect URIs it had registered. (for a soft definition of > "match" -- it can be prefix, or pattern, or exact string, so long > as the AS knows how to do it, IIRC) > - If the client does not send a redirect URI to the auth endpoint, > and the client has either only registered one or the AS has some > notion of a "default" redirect URI, the AS will just use that one. > > Now the part that seems to trip people up: > > - If the client had sent a redirect URI to the auth endpoint, then > it MUST send the EXACT SAME redirect URI to the token endpoint. > This request is back-channel and protected with the client's > credentials. > - If the client did not send a redirect URI to the auth endpoint, > then it does NOT send a redirect URI to the token endpoint. > > > So here's where the protection comes in. If the attacker modifies > the request to the auth endpoint so that it has a different > redirect URI, then that redirect URI MUST match one that's > attached to the client_id in the request. Furthermore, the call to > the token endpoint to get the token MUST also contain that > modified redirect URI as well as any client credentials needed to > make the call. A "good" client will send a "good" redirect URI, > even if the code has been sent someplace else in the mean time. > > Hope this clears things up, > > -- Justin > > > On 11/29/2012 04:24 PM, Ariel Barreiro wrote: >> But isn't having a registered redirect URI on the authorization >> end point enought to prevent this, why is it required to send the >> redirect URI to the token end point if the previous method >> prevents it? >> >> I appreciate a lot your response but I am still finding it hard >> to picture it, and, was in your explanation a modification to the >> request URI? >> >> >> On Thu, Nov 29, 2012 at 6:25 PM, John Bradley > > wrote: >> >> A confidential client authenticates to the token endpoint >> preventing an attacker from getting the token. >> >> In the case of a public client if you get the code and >> redirect URI then you can get the token. (Why confidential >> clients are better than public ones) >> >> Sending the redirect URI to the token endpoint protects the >> client from the case where client A gets a code for user B >> because the user logged into A and A is using the client ID >> of client Z because it wants to impersonate user B at client >> A. Client A pretending to be client Z can easily get the >> code. However the redirect URI that the real client Z sends >> will be different than the one the fake client Z used to get >> code and the real client A won't be able to exchange the code >> for a access token and be tricked into thinking that the >> resource owner is the one presenting it the code. >> >> That is the long explanation. The short one is unregistered >> redirect URI are bad. Sending the redirect URI to the token >> endpoint protects clients from becoming confused about the >> presenter of the code. >> Nothing is going to help a public client if someone >> intercepts code. >> >> John B. >> >> On 2012-11-29, at 3:05 PM, Ariel Barreiro > > wrote: >> >>> Still I can't see how to prevent the attack. I understand >>> that there is no redirection when requesting an access >>> token, however, the protocol requests the client to send the >>> redirect_uri to the token end point to validate it was the >>> same used in the authorization. If the authorization was >>> compromised, couldn't the access token request be forged as >>> well? >>> >>> >>> On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt >>> > wrote: >>> >>> There is no redirection when requesting an access token. >>> Token requests are typically out-of-band from the user. >>> The attack only happens during an authorization >>> redirect flow in the browser. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: >>> >>> > I am struggling a bit to understand this attack and >>> the advice in to how to prevent. I understand that if I, >>> as an attacker, can change the redirection uri when >>> authorizing, can not it as well change the redirect uri >>> when requesting an access token? >>> > >>> > Any explanation examples on how this attack might work >>> and how sending the redirect_uri when requesting the >>> access toekn prevents it are welcomed. >>> > >>> > Thanks, >>> > Ariel.= >>> > _______________________________________________ >>> > 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 > > --------------080305020402040604030306 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
The request to the auth endpoint is front channel, through a browser. The request to the token endpoint is back channel, server-to-server. These are very, very different attack surfaces. If an attacker has access to and control of both channels, you're pretty hosed anyway and OAuth (nor TLS, nor basically anything else I can think of) will help you.

The security model in OAuth comes from limiting the knowledge at each part of the transaction and spreading the risk appropriately.

 -- Justin

On 11/29/2012 04:43 PM, Ariel Barreiro wrote:
But so the protection of sending the SAME redirect_uri in both the auth end point and token end point makes not much of a sense when there is a registered URI, and if there's not, an attacker, as far as I understood, can compromise both the request to the auth end point as well as the token end point, so I would assume that it doesn't make much sense either.


On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer <jricher@mitre.org> wrote:
So here's the breakdown of how the redirect uri works:



- If the client sends a redirect URI to the auth endpoint, and the client has registered one or more redirect URIs, it MUST match one of the redirect URIs it had registered. (for a soft definition of "match" -- it can be prefix, or pattern, or exact string, so long as the AS knows how to do it, IIRC)
- If the client does not send a redirect URI to the auth endpoint, and the client has either only registered one or the AS has some notion of a "default" redirect URI, the AS will just use that one.

Now the part that seems to trip people up:

- If the client had sent a redirect URI to the auth endpoint, then it MUST send the EXACT SAME redirect URI to the token endpoint. This request is back-channel and protected with the client's credentials.
- If the client did not send a redirect URI to the auth endpoint, then it does NOT send a redirect URI to the token endpoint.


So here's where the protection comes in. If the attacker modifies the request to the auth endpoint so that it has a different redirect URI, then that redirect URI MUST match one that's attached to the client_id in the request. Furthermore, the call to the token endpoint to get the token MUST also contain that modified redirect URI as well as any client credentials needed to make the call. A "good" client will send a "good" redirect URI, even if the code has been sent someplace else in the mean time.

Hope this clears things up,

 -- Justin


On 11/29/2012 04:24 PM, Ariel Barreiro wrote:
But isn't having a registered redirect URI on the authorization end point enought to prevent this, why is it required to send the redirect URI to the token end point if the previous method prevents it?

I appreciate a lot your response but I am still finding it hard to picture it, and, was in your explanation a modification to the request URI?


On Thu, Nov 29, 2012 at 6:25 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
A confidential client authenticates to the token endpoint preventing an attacker from getting the token.

In the case of a public client if you get the code and redirect URI then you can get the token.  (Why confidential clients are better than public ones)

Sending the redirect URI to the token endpoint protects the client from the case where client A gets a code for user B because the user logged into A and A is using the client ID of client Z because it wants to impersonate user B at client A.   Client A pretending to be client Z  can easily get the code.  However the redirect URI that the real client Z sends will be different than the one the fake client Z used to get code and the real client A won't be able to exchange the code for a access token and be tricked into thinking that the resource owner is the one presenting it the code.

That is the long explanation.  The short one is unregistered redirect URI are bad.   Sending the redirect URI to the token endpoint protects clients from becoming confused about the presenter of the code.
Nothing is going to help a public client if someone intercepts code.

John B.

On 2012-11-29, at 3:05 PM, Ariel Barreiro <abarrei@gmail.com> wrote:

Still  I can't see how to prevent the attack. I understand that there is no redirection when requesting an access token, however, the protocol requests the client to send the redirect_uri to the token end point to validate it was the same used in the authorization. If the authorization was compromised, couldn't the access token request be forged as well?


On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
There is no redirection when requesting an access token.  Token requests are typically out-of-band from the user.  The attack only happens during an authorization redirect flow in the browser.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote:

> I am struggling a bit to understand this attack and the advice in to how to prevent. I understand that if I, as an attacker, can change the redirection uri when authorizing, can not it as well change the redirect uri when requesting an access token?
>
> Any explanation examples on how this attack might work and how sending the redirect_uri when requesting the access toekn prevents it are welcomed.
>
> Thanks,
> Ariel.=
> _______________________________________________
> 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



--------------080305020402040604030306-- From abarrei@gmail.com Thu Nov 29 14:02:26 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF93421F8C11 for ; Thu, 29 Nov 2012 14:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVXjsJfSrttr for ; Thu, 29 Nov 2012 14:02:24 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A19F121F8C0C for ; Thu, 29 Nov 2012 14:02:19 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so16716633ieb.31 for ; Thu, 29 Nov 2012 14:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=m2RaueMt/LFcc/9crvPD6TCUOSNC8mvOaH5rd1wuyUA=; b=gYsJ0VOiWlb06Dv4hlDXGVvO66zBmipbqPj7C+FPwzuzSclvl3XAMjiqCoZ1pNit8x ugoF5KvTDSvoqH4J9OW/YETA0+RMqixwpuJ9MqoV7LjOMzEbJ2Sdhvh5EHKEqWtPlhnZ zEH2ZOw9iydDLx7e/+Q/AthROE1XyWN5DKOa4FFpts3tapW/YiIWEyAt+PaXy7dLpzPB ezb/RX1Wd3hAHfyiekXIiGUg5bQ3OsAHj6WLbrBwLm2zXxd/3f90zAKaB7To5vGV1fsf J4aMHnOX0xoubYmbgNBj69lNOjQIYR1DW3iubRf3MhPKD7sG3BFn1bVCfpaMLPoHouNL YepQ== Received: by 10.50.196.193 with SMTP id io1mr15407495igc.10.1354226539202; Thu, 29 Nov 2012 14:02:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.76.167 with HTTP; Thu, 29 Nov 2012 14:01:58 -0800 (PST) In-Reply-To: <50B7D74D.6090401@mitre.org> References: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> <50B7D531.4040005@mitre.org> <50B7D74D.6090401@mitre.org> From: Ariel Barreiro Date: Thu, 29 Nov 2012 19:01:58 -0300 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=14dae93411f5d087fa04cfa96f48 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 22:02:26 -0000 --14dae93411f5d087fa04cfa96f48 Content-Type: text/plain; charset=ISO-8859-1 Aha, maybe that's the bit that I didn't understand that good then... front channel and back channel, although I can see difference I am not quite sure of how is it different on the implementation Client request to the auth end point is through a browser... fine, you send the redirect uri. After authenticating you get back to the redirect_uri with the auth code. Isn't it the client, again, with the auth code, the one that initiates the request to the token end point? I see no different channel on the requests. On Thu, Nov 29, 2012 at 7:44 PM, Justin Richer wrote: > The request to the auth endpoint is front channel, through a browser. > The request to the token endpoint is back channel, server-to-server. These > are very, very different attack surfaces. If an attacker has access to and > control of both channels, you're pretty hosed anyway and OAuth (nor TLS, > nor basically anything else I can think of) will help you. > > The security model in OAuth comes from limiting the knowledge at each part > of the transaction and spreading the risk appropriately. > > -- Justin > > > On 11/29/2012 04:43 PM, Ariel Barreiro wrote: > > But so the protection of sending the SAME redirect_uri in both the auth > end point and token end point makes not much of a sense when there is a > registered URI, and if there's not, an attacker, as far as I understood, > can compromise both the request to the auth end point as well as the token > end point, so I would assume that it doesn't make much sense either. > > > On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer wrote: > >> So here's the breakdown of how the redirect uri works: >> >> >> >> - If the client sends a redirect URI to the auth endpoint, and the client >> has registered one or more redirect URIs, it MUST match one of the redirect >> URIs it had registered. (for a soft definition of "match" -- it can be >> prefix, or pattern, or exact string, so long as the AS knows how to do it, >> IIRC) >> - If the client does not send a redirect URI to the auth endpoint, and >> the client has either only registered one or the AS has some notion of a >> "default" redirect URI, the AS will just use that one. >> >> Now the part that seems to trip people up: >> >> - If the client had sent a redirect URI to the auth endpoint, then it >> MUST send the EXACT SAME redirect URI to the token endpoint. This request >> is back-channel and protected with the client's credentials. >> - If the client did not send a redirect URI to the auth endpoint, then it >> does NOT send a redirect URI to the token endpoint. >> >> >> So here's where the protection comes in. If the attacker modifies the >> request to the auth endpoint so that it has a different redirect URI, then >> that redirect URI MUST match one that's attached to the client_id in the >> request. Furthermore, the call to the token endpoint to get the token MUST >> also contain that modified redirect URI as well as any client credentials >> needed to make the call. A "good" client will send a "good" redirect URI, >> even if the code has been sent someplace else in the mean time. >> >> Hope this clears things up, >> >> -- Justin >> >> >> On 11/29/2012 04:24 PM, Ariel Barreiro wrote: >> >> But isn't having a registered redirect URI on the authorization end point >> enought to prevent this, why is it required to send the redirect URI to the >> token end point if the previous method prevents it? >> >> I appreciate a lot your response but I am still finding it hard to >> picture it, and, was in your explanation a modification to the request URI? >> >> >> On Thu, Nov 29, 2012 at 6:25 PM, John Bradley wrote: >> >>> A confidential client authenticates to the token endpoint preventing an >>> attacker from getting the token. >>> >>> In the case of a public client if you get the code and redirect URI >>> then you can get the token. (Why confidential clients are better than >>> public ones) >>> >>> Sending the redirect URI to the token endpoint protects the client >>> from the case where client A gets a code for user B because the user logged >>> into A and A is using the client ID of client Z because it wants to >>> impersonate user B at client A. Client A pretending to be client Z can >>> easily get the code. However the redirect URI that the real client Z sends >>> will be different than the one the fake client Z used to get code and the >>> real client A won't be able to exchange the code for a access token and be >>> tricked into thinking that the resource owner is the one presenting it the >>> code. >>> >>> That is the long explanation. The short one is unregistered redirect >>> URI are bad. Sending the redirect URI to the token endpoint protects >>> clients from becoming confused about the presenter of the code. >>> Nothing is going to help a public client if someone intercepts code. >>> >>> John B. >>> >>> On 2012-11-29, at 3:05 PM, Ariel Barreiro wrote: >>> >>> Still I can't see how to prevent the attack. I understand that there is >>> no redirection when requesting an access token, however, the protocol >>> requests the client to send the redirect_uri to the token end point to >>> validate it was the same used in the authorization. If the authorization >>> was compromised, couldn't the access token request be forged as well? >>> >>> >>> On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt wrote: >>> >>>> There is no redirection when requesting an access token. Token >>>> requests are typically out-of-band from the user. The attack only happens >>>> during an authorization redirect flow in the browser. >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> >>>> >>>> >>>> >>>> On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: >>>> >>>> > I am struggling a bit to understand this attack and the advice in to >>>> how to prevent. I understand that if I, as an attacker, can change the >>>> redirection uri when authorizing, can not it as well change the redirect >>>> uri when requesting an access token? >>>> > >>>> > Any explanation examples on how this attack might work and how >>>> sending the redirect_uri when requesting the access toekn prevents it are >>>> welcomed. >>>> > >>>> > Thanks, >>>> > Ariel.= >>>> > _______________________________________________ >>>> > 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> >> >> > > --14dae93411f5d087fa04cfa96f48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aha, maybe that's the bit that I didn't understand that good then..= . front channel and back channel, although I can see difference I am not qu= ite sure of how is it different on the implementation

Client request to the auth end point is through a browser... fine, you send= the redirect uri. After authenticating you get back to the redirect_uri wi= th the auth code.

Isn't it the client, aga= in, with the auth code, the one that initiates the request to the token end= point? I see no different channel on the requests.


On Thu, Nov 2= 9, 2012 at 7:44 PM, Justin Richer <jricher@mitre.org> wrote:=
=20 =20 =20
The request to the auth endpoint is front channel, through a browser. The request to the token endpoint is back channel, server-to-server. These are very, very different attack surfaces. If an attacker has access to and control of both channels, you're pretty hosed anyway and OAuth (nor TLS, nor basically anything else I can think of) will help you.

The security model in OAuth comes from limiting the knowledge at each part of the transaction and spreading the risk appropriately.

=A0-- Justin


On 11/29/2012 04:43 PM, Ariel Barreiro wrote:
=20 But so the protection of sending the SAME redirect_uri in both the auth end point and token end point makes not much of a sense when there is a registered URI, and if there's not, an attacker, as fa= r as I understood, can compromise both the request to the auth end point as well as the token end point, so I would assume that it doesn't make much sense either.


On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer <jricher@mitre.org> wrote:
So here's the breakdown of how the redirect uri works:



- If the client sends a redirect URI to the auth endpoint, and the client has registered one or more redirect URIs, it MUST match one of the redirect URIs it had registered. (for a soft definition of "match"= -- it can be prefix, or pattern, or exact string, so long as the AS knows how to do it, IIRC)
- If the client does not send a redirect URI to the auth endpoint, and the client has either only registered one or the AS has some notion of a "default" redirect= URI, the AS will just use that one.

Now the part that seems to trip people up:

- If the client had sent a redirect URI to the auth endpoint, then it MUST send the EXACT SAME redirect URI to the token endpoint. This request is back-channel and protected with the client's credentials.
- If the client did not send a redirect URI to the auth endpoint, then it does NOT send a redirect URI to the token endpoint.


So here's where the protection comes in. If the attacke= r modifies the request to the auth endpoint so that it has a different redirect URI, then that redirect URI MUST match one that's attached to the client_id in the request. Furthermore, the call to the token endpoint to get the token MUST also contain that modified redirect URI as well as any client credentials needed to make the call. A "good" client will send a "good"= ; redirect URI, even if the code has been sent someplace else in the mean time.

Hope this clears things up,

=A0-- Justin


On 11/29/2012 04:24 PM, Ariel Barreiro wrote:
But isn't having a registe= red redirect URI on the authorization end point enought to prevent this, why is it required to send the redirect URI to the token end point if the previous method prevents it?

I appreciate a lot your response but I am still finding it hard to picture it, and, was in your explanation a modification to the request URI?


On Thu, Nov 29, 2012 at 6:25 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
A confidential client authenticates to the token endpoint preventing an attacker from getting the token.

In the case of a public client if you get the code and redirect URI then you can get the token. =A0(Why confidential clients are better than public ones)

Sending the redirect URI to the token endpoint protects the client from the case where client A gets a code for user B because the user logged into A and A is using the client ID of client Z because it wants to impersonate user B at client A. =A0 Client A pretending to be client Z =A0can easily get the code. =A0However the redirect URI that the real client Z sends will be different than the one the fake client Z used to get code and the real client A won't be able to exchange the code for a access token and be tricked into thinking that the resource owner is the one presenting it the code.

That is the long explanation. =A0The short one is unregistered redirect URI are bad. =A0 Sending the redirect URI to the token endpoint protects clients from becoming confused about the presenter of the code.
Nothing is going to help a public client if someone intercepts code.

John B.

On 2012-11-29, at 3:05 PM, Ariel Barreiro <abarrei@gmail.com> wrote:

Still =A0I can't see how to prevent the attack. I understand that there is no redirection when requesting an access token, however, the protocol requests the client to send the redirect_uri to the token end point to validate it was the same used in the authorization. If the authorization was compromised, couldn't the access token request be forged as well?


On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt <phil.hunt@or= acle.com> wrote:
= There is no redirection when requesting an access token. =A0Token requests are typically out-of-band from the user. =A0The attack only happens during an authorization redirect flow in the browser.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote:

> I am struggling a bit to understand this attack and the advice in to how to prevent. I understand that if I, as an attacker, can change the redirection uri when authorizing, can not it as well change the redirect uri when requesting an access token?
>
> Any explanation examples on how this attack might work and how sending the redirect_uri when requesting the access toekn prevents it are welcomed.
>
> Thanks,
> Ariel.=3D
> _____________________________= __________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mail= man/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/= oauth




_______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth




--14dae93411f5d087fa04cfa96f48-- From torsten@lodderstedt.net Thu Nov 29 22:36:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF78921F89B5 for ; Thu, 29 Nov 2012 22:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.914 X-Spam-Level: X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMfYX7hGCZH5 for ; Thu, 29 Nov 2012 22:36:54 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by ietfa.amsl.com (Postfix) with ESMTP id E8F6C21F89A9 for ; Thu, 29 Nov 2012 22:36:53 -0800 (PST) Received: from [80.187.111.142] (helo=[100.100.98.14]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1TeKDS-00020e-RE; Fri, 30 Nov 2012 07:36:51 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <50B7D5BC.3090805@gmail.com> References: <50B7D5BC.3090805@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----VHCCOT5N5UFADQMB6CLDPF6BGLHR6Q" From: Torsten Lodderstedt Date: Fri, 30 Nov 2012 07:36:34 +0100 To: Sergey Beryozkin , "" Message-ID: <8fafd60e-3718-42db-adf3-a7eed1d4822c@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] Refresh grant and token revocation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 06:36:55 -0000 ------VHCCOT5N5UFADQMB6CLDPF6BGLHR6Q Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, I would assume the clients knows the scope required for a certain request (from documentation) and acquires the access token using the respective scope from the authz server. Given this assumption, 401 may only occur when the access token has expired. regards, Torsten. Sergey Beryozkin schrieb: >Apologies for a noise on it, however I'd like to get some more >clarifications on it. > >What I thought first about the refresh grant was that a client would >use >it for getting a new access token back after it gets a 401 back from >PR. > >Next after seeing the comments from others it became obvious the >refresh >grant can be used to pro-actively refresh the existing token when the >client realizes - this is what I'm really going to ask about. > >I also learned about the fact a refresh grant can effectively be used >to >clone the existing token - I'd like to avoid talking about this case in > >this thread, even I got it wrong with the term 'clone' :-) > >So, as far as the refresh token grant is concerned, the grant which is >'supported' by the core spec, what are the expectations of the client >which request to refresh a still valid access token ? > >I got a bit confused by the feedback that it may be per-AS specific. >If it were the expectation then I'd not see the difference between the >core spec "refresh_token" grant and "a.b.c" custom grant. > >It seems reasonable that if the client does decide to be proactive and >use a refresh grant without using any optional scopes, and specifically > >with the main and only purpose to refresh the access token which may >get >expired shortly, it should predictably get a new access token with a >new >time lease... > >And which means the old token must've gone by now and effectively >revoked. This exactly what the client means, get me a new refreshed >token... > >I've checked the token revocation grant. It's obviously a good idea to >let the client directly interact with the endpoint and remove whatever >token it want to remove. However, a refresh token request (without a >scope parameter) should have the same side-effect > >Does it make any sense at all ? > >Thanks, Sergey > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth ------VHCCOT5N5UFADQMB6CLDPF6BGLHR6Q Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

I would assume the clients knows the scope required for a certain request (from documentation) and acquires the access token using the respective scope from the authz server. Given this assumption, 401 may only occur when the access token has expired.

regards,
Torsten.



Sergey Beryozkin <sberyozkin@gmail.com> schrieb:
Apologies for a noise on it, however I'd like to get some more 
clarifications on it.

What I thought first about the refresh grant was that a client would use 
it for getting a new access token back after it gets a 401 back from PR.

Next after seeing the comments from others it became obvious the refresh 
grant can be used to pro-actively refresh the existing token when the 
client realizes - this is what I'm really going to ask about.

I also learned about the fact a refresh grant can effectively be used to 
clone the existing token - I'd like to avoid talking about this case in 
this thread, even I got it wrong with the term 'clone' :-)

So, as far as the refresh token grant is concerned, the grant which is 
'supported' by the core spec, what are the expectations of the client
which request to re
 fresh a
still valid access token ?

I got a bit confused by the feedback that it may be per-AS specific.
If it were the expectation then I'd not see the difference between the 
core spec "refresh_token" grant and "a.b.c" custom grant.

It seems reasonable that if the client does decide to be proactive and 
use a refresh grant without using any optional scopes, and specifically 
with the main and only purpose to refresh the access token which may get 
expired shortly, it should predictably get a new access token with a new 
time lease...

And which means the old token must've gone by now and effectively 
revoked. This exactly what the client means, get me a new refreshed 
token...

I've checked the token revocation grant. It's obviously a good idea to 
let the client directly interact with the endpoint and remove whatever 
token it want to remove. However, a refresh token request (without a 
scope
parameter) should have the same side-effect

Does it make any sense at all ?

Thanks, Sergey


OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------VHCCOT5N5UFADQMB6CLDPF6BGLHR6Q-- From torsten@lodderstedt.net Thu Nov 29 22:39:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A93C21F89D2 for ; Thu, 29 Nov 2012 22:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.914 X-Spam-Level: X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kET6eP5H2odc for ; Thu, 29 Nov 2012 22:39:03 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by ietfa.amsl.com (Postfix) with ESMTP id 22A8021F89B5 for ; Thu, 29 Nov 2012 22:39:02 -0800 (PST) Received: from [80.187.111.142] (helo=[100.100.98.14]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1TeKFV-0005lp-9C; Fri, 30 Nov 2012 07:39:01 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <50B7D0BE.5000808@gmail.com> References: <20121118163709.2491.46077.idtracker@ietfa.amsl.com> <50A90F8B.5080100@lodderstedt.net> <50ABA88F.4030500@mitre.org> <50ACBFEE.7020606@gmail.com> <50ACE0FF.4060807@mitre.org> <1353509632.36061.YahooMailNeo@web31801.mail.mud.yahoo.com>, <50ACFC53.5080103@gmail.com> <201211271652159646688@gmail.com> <50B4937C.5030201@gmail.com> <50B4DF1B.4030700@gmail.com> <50B4E9A4.1030508@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F19E386@BY2PRD0411MB441.namprd04.prod.outlook.com> <50B5023B.3060208@gmail.com> <50B7D0BE.5000808@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----O2FU77HXJS7OQ6GOGO912K540TBZ2Y" From: Torsten Lodderstedt Date: Fri, 30 Nov 2012 07:38:47 +0100 To: Sergey Beryozkin ,"oauth@ietf.org" Message-ID: <43d5f617-8191-484c-9339-b57216e71735@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 06:39:05 -0000 ------O2FU77HXJS7OQ6GOGO912K540TBZ2Y Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, I would assume the clients knows the scope required for a certain request (from documentation) and acquires the access token using the respective scope from the authz server. Given this assumption, 401 may only occur when the access token has expired. regards, Torsten. Sergey Beryozkin schrieb: >I'd like to return to this thread. After learning about the refresh >grant supporting a client-driven down-scoping, the same question which >I >asked in the first place seems relevant again. > >If the clients gets 401 back while trying to access PR, how will it >know >how to react to it (use refresh grant with or without its optional >scope >parameter), is it because the access token has expired or is it because > >it has an invalid scope ? > >Thanks, Sergey > > >On 27/11/12 18:11, Sergey Beryozkin wrote: >> Hi Adam, >> >> thanks for sharing it, helpful, >> On 27/11/12 17:24, Lewis Adam-CAL022 wrote: >>> Hi Sergey, >>> >>> In my use cases the client actively monitors the expiration of the >AT >>> in order to request a new AT using the RT. We do this as you >>> suggested, because presenting an expired AT to the RS is a wasted >>> round trip and adds latency and degrades the user experience. Why >send >>> the AT if we know it's expired? >>> >> >> How do you know when the client is expecting a revocation and when a >> downscoping, I guess if the client includes and optional 'scope' >> parameter then it is down-scoping obviously, otherwise - revocation ? >> >> If that is the case then IMHO a refresh token grant request without a >> scope parameter might offer a shortcut for the client not to worry >about >> one more endpoint (to do with the revocation) ? >> >>> As to your other question, one reason to down scope an AT ... in my >>> use cases the AS issues access tokens for many different RS's. It is >a >>> security concern to send an AT to RS1 that has the ability to also >>> access protected resources at RS2 and RS3 and RSn, etc. So I make a >>> first request to get a "master" AT with a master RT, and then >>> immediately destroy the master AT and use the master RT to get a >>> down-scoped AT - one for each RS. This is inefficient though, and >I've >>> been nagging the WG to consider a draft to allow a client to request >>> an array of access tokens of different scopes. >>> >> OK, that makes it clearer. What I'm concerned about though, does the >> client need to be concerned or is it the job of AS to protect in >cases >> where a token with too many scopes is used to access a given RS which >> may delegate to a stricter RS ? >> >> I mean, is client expected to be well-behaved and know about the >> relationships between the master RS with the stricter RS1 & RS2 >parthers >> ? Seems not easy to make it interoperable... >> >> Guess I'm missing the point still >> >> Thanks, Sergey >> >>> These are just my experience, and as Justin mentioned, your millage >>> may vary. Hope it helps either way :-) >>> >>> adam >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >Behalf >>> Of Sergey Beryozkin >>> Sent: Tuesday, November 27, 2012 10:26 AM >>> To: Richer, Justin P. >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] How the client can decide it is time to use >>> the refresh token >>> >>> On 27/11/12 15:48, Richer, Justin P. wrote: >>>> Yes, the client can keep two tokens and try using both of them if >it >>>> wants to. I think that you're conflating revocation and expiration >>>> here, and missing a key use case: downscoping. Let's say the client >>>> gets an access grant for [A, B, C], and it gets RT and AT1 for >those >>>> scopes. The client then wants to call a service with *only* scope >B, >>>> so it sends RT in with scope B in the refresh request to get AT2 >with >>>> that scope alone. AT1 is still valid, assuming it hasn't expired or >>>> otherwise been revoked. The client can choose which AT to present >to >>>> the protected resources in different situations. >>>> >>> That is complex :-). Using a refresh token to downscope and keep a >>> number of access tokens is definitely beyond my imagination at the >>> moment, why would a client want to downscope its access token ? >>> >>> Is it basically described at: >>> >http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-03#section-3.10 >>> ? >>> >>> I'm still not getting though why access token with the richer set of >>> scopes needs to be explicitly downscoped by the client, is it >because >>> using a token with a richer set of scopes can lead to some >authorization >>> issues ? >>> >>> I was thinking that the down-scoping only makes sense during the >>> authorization code flow where AS downscopes what the client has >>> requested but obviously I'm only at the start of the learning curve >:-). >>> >>> >>> >>>> In all of these cases, it's completely up to the AS and the PRs >>>> whether or not any of the tokens in the wild are still valid. Your >AS >>>> might decide that once a RT is used, it will simply throw away all >>>> existing AT's attached to that RT. That's totally a valid use case, >>>> and the client needs to be able to handle that (in the same way >that >>>> it handles any invalid token). >>>> >>>> If you want the clients to explicitly throw out tokens, use the >Token >>>> Revocation spec. >>>> >>> OK, that makes sense now. >>> >>> Thanks, Sergey >>> >>>> -- Justin >>>> >>>> On Nov 27, 2012, at 10:41 AM, Sergey Beryozkin wrote: >>>> >>>>> On 27/11/12 15:29, Richer, Justin P. wrote: >>>>>> The client can indeed save a round trip by proactively refreshing >>>>>> the access token. This does not necessarily revoke the existing >>>>>> access token. Many implementations do that, so your mileage may >vary. >>>>>> >>>>> >>>>> I don't understand. >>>>> >>>>> So the client will still have the existing access token which may >>>>> have not been revoked, and then also another access token which >was >>>>> just returned in response to the refresh grant request ? >>>>> >>>>> And if you mean that no actual revocation is actually done, why >then >>>>> have the client worry about doing the proactive refresh ? >>>>> >>>>> I can imagine that may be that it will only be the actual refresh >>>>> token refreshed itself, but why keep the access token if the >client >>>>> has requested a refresh ? >>>>> >>>>> Sergey >>>>> >>>>>> -- Justin >>>>>> >>>>>> On Nov 27, 2012, at 5:18 AM, Sergey Beryozkin wrote: >>>>>> >>>>>>> On 27/11/12 08:52, Guangqing Deng wrote: >>>>>>>> It seems that the client cannot know whether the refresh token >>>>>>>> should be >>>>>>>> used until a HTTP 401 error is returned from the resource >server >>>>>>>> due to >>>>>>>> the expiration of current access token or some other reasons. >>>>>>>> However, a >>>>>>>> period of time cannot be ignored will be spent on obtain a new >>>>>>>> access >>>>>>>> token using the refresh token after the resource server returns >a >>>>>>>> HTTP >>>>>>>> 401 error to the client, which may degrade the user experience >>>>>>>> since the >>>>>>>> real-time nature of the service cannot be guaranteed. Is a >>>>>>>> mechanism by >>>>>>>> which the client can check the validity of the access token (or >the >>>>>>>> refresh token) in advance needed by Oauth? >>>>>>> >>>>>>> I believe an access token response may offer an expires_in >>>>>>> parameter which can provide some hint. Actually this raises an >>>>>>> interesting question. >>>>>>> Suppose the client actually checks this parameter and decides to >use >>>>>>> a refresh token it also has to pro-actively refresh its current >>>>>>> token. >>>>>>> >>>>>>> IMHO this should work even if the access token has not expired >yet >>>>>>> and effectively represents another form of a client-initiated >>>>>>> revocation of the access token ? It will mean a client which >works >>>>>>> with the "expires_in" parameter can save a one round trip (the >one >>>>>>> which returns a failure in case of the access token being >expired) ? >>>>>>> >>>>>>> Does it make sense ? If it does, can some relevant wording make >it >>>>>>> into the revocation token draft ? >>>>>>> >>>>>>> Cheers, Sergey >>>>>>> >>>>>>>> >------------------------------------------------------------------------ >>>>>>>> >>>>>>>> Guangqing Deng >>>>>>>>> >------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> *From:* Justin Richer >>>>>>>>> *To:* Sergey Beryozkin >>>>>>>>> *Cc:* oauth@ietf.org >>>>>>>>> *Sent:* Wednesday, November 21, 2012 6:11 AM >>>>>>>>> *Subject:* Re: [OAUTH-WG] How the client can decide it is time >>>>>>>>> to use >>>>>>>>> the refresh token >>>>>>>>> >>>>>>>>> There's no signaling regarding the validity of the refresh >token >>>>>>>>> from >>>>>>>>> the protected resource. In more distributed setups, the >protected >>>>>>>>> resources know nothing about the refresh tokens because the PR >>>>>>>>> never >>>>>>>>> sees them. In any case. the code path is fairly >straightforward, >>>>>>>>> even if >>>>>>>>> both tokens are expired: >>>>>>>>> >>>>>>>>> - client presents AT to resource >>>>>>>>> - resource returns data, AT worked >>>>>>>>> - [or] resource returns 400 error to client, AT didn't work >>>>>>>>> - client presents RT to auth server >>>>>>>>> - auth server returns new AT, RT worked >>>>>>>>> - [or] auth server returns 400 error to client, RT didn't work >>>>>>>>> - client has to go get a new auth grant from the resource >owner, >>>>>>>> start over >>>>>>>>> >>>>>>>>> -- Justin >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> I'm looking for some guidance on how the client which already >>>>>>>>>> owns an >>>>>>>>> access token can decide, after getting HTTP 400 back from the >>>>>>>>> resource >>>>>>>>> server it tries to access on behalf of the end user/resource >>>>>>>>> owner, can >>>>>>>>> decide that the refresh token it has can now be used to get a >>>>>>>>> new access >>>>>>>>> token. >>>>>>>>>> >>>>>>>>>> [1] refers to various error conditions but it is not obvious >to me >>>>>>>>> that the same conditions (some of them) should or can be >>>>>>>>> reported during >>>>>>>>> the actual client accessing the protected resource. >>>>>>>>>> >>>>>>>>>> My question is, what error condition, if any, from [1] should >be >>>>>>>>> reported back to the client failing to access a protected >>>>>>>>> resource due >>>>>>>>> to the access token being invalid or expired, so that it can >>>>>>>>> help the >>>>>>>>> client who also owns the refresh token to decide it can use it >>>>>>>>> now... >>>>>>>>>> >>>>>>>>>> Thanks, Sergey >>>>>>>>>> >>>>>>>>>> [1] http://tools.ietf.org/html/rfc6749#section-5.2 >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>> >>> >>> >>> >>> >> >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth ------O2FU77HXJS7OQ6GOGO912K540TBZ2Y Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

I would assume the clients knows the scope required for a certain request (from documentation) and acquires the access token using the respective scope from the authz server. Given this assumption, 401 may only occur when the access token has expired.

regards, Torsten.



Sergey Beryozkin <sberyozkin@gmail.com> schrieb:
I'd like to return to this thread. After learning about the refresh 
grant supporting a client-driven down-scoping, the same question which I 
asked in the first place seems relevant again.

If the clients gets 401 back while trying to access PR, how will it know 
how to react to it (use refresh grant with or without its optional scope 
parameter), is it because the access token has expired or is it because 
it has an invalid scope ?

Thanks, Sergey


On 27/11/12 18:11, Sergey Beryozkin wrote:
Hi Adam,

thanks for sharing it, helpful,
On 27/11/12 17:24, Lewis Adam-CAL022 wrote:
Hi Sergey,

In my use cases the client actively monitors the expiration of the AT
in order to request a new AT using the RT. We do this as you
suggested, because presenting an expired AT to the RS is a wasted
round trip and adds latency and degrades the user experience. Why send
the AT if we know it's expired?


How do you know when the client is expecting a revocation and when a
downscoping, I guess if the client includes and optional 'scope'
parameter then it is down-scoping obviously, otherwise - revocation ?

If that is the case then IMHO a refresh token grant request without a
scope parameter might offer a shortcut for the client not to worry about
one more endpoint (to do with the revocation) ?

As to your other question, one reason to down sco
 pe an
AT ... in my
use cases the AS issues access tokens for many different RS's. It is a
security concern to send an AT to RS1 that has the ability to also
access protected resources at RS2 and RS3 and RSn, etc. So I make a
first request to get a "master" AT with a master RT, and then
immediately destroy the master AT and use the master RT to get a
down-scoped AT - one for each RS. This is inefficient though, and I've
been nagging the WG to consider a draft to allow a client to request
an array of access tokens of different scopes.

OK, that makes it clearer. What I'm concerned about though, does the
client need to be concerned or is it the job of AS to protect in cases
where a token with too many scopes is used to access a given RS which
may delegate to a stricter RS ?

I mean, is client expected to be well-behaved and know about the
relationships between the master RS with the stricter RS1 &am
 p; RS2
parthers
? Seems not easy to make it interoperable...

Guess I'm missing the point still

Thanks, Sergey

These are just my experience, and as Justin mentioned, your millage
may vary. Hope it helps either way :-)

adam

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of Sergey Beryozkin
Sent: Tuesday, November 27, 2012 10:26 AM
To: Richer, Justin P.
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] How the client can decide it is time to use
the refresh token

On 27/11/12 15:48, Richer, Justin P. wrote:
Yes, the client can keep two tokens and try using both of them if it
wants to. I think 
 that
you're conflating revocation and expiration
here, and missing a key use case: downscoping. Let's say the client
gets an access grant for [A, B, C], and it gets RT and AT1 for those
scopes. The client then wants to call a service with *only* scope B,
so it sends RT in with scope B in the refresh request to get AT2 with
that scope alone. AT1 is still valid, assuming it hasn't expired or
otherwise been revoked. The client can choose which AT to present to
the protected resources in different situations.

That is complex :-). Using a refresh token to downscope and keep a
number of access tokens is definitely beyond my imagination at the
moment, why would a client want to downscope its access token ?

Is it basically described at:
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-03#section-3.10
?

I'm
still not getting though why access token with the richer set of
scopes needs to be explicitly downscoped by the client, is it because
using a token with a richer set of scopes can lead to some authorization
issues ?

I was thinking that the down-scoping only makes sense during the
authorization code flow where AS downscopes what the client has
requested but obviously I'm only at the start of the learning curve :-).



In all of these cases, it's completely up to the AS and the PRs
whether or not any of the tokens in the wild are still valid. Your AS
might decide that once a RT is used, it will simply throw away all
existing AT's attached to that RT. That's totally a valid use case,
and the client needs to be able to handle that (in the same way that
it handles any invalid token).<
 br
/>
If you want the clients to explicitly throw out tokens, use the Token
Revocation spec.

OK, that makes sense now.

Thanks, Sergey

-- Justin

On Nov 27, 2012, at 10:41 AM, Sergey Beryozkin wrote:

On 27/11/12 15:29, Richer, Justin P. wrote:
The client can indeed save a round trip by proactively refreshing
the access token. This does not necessarily revoke the existing
access token. Many implementations do that, so your mileage may vary.


I don't understand.

So the client will still have the existing access token
  which
may
have not been revoked, and then also another access token which was
just returned in response to the refresh grant request ?

And if you mean that no actual revocation is actually done, why then
have the client worry about doing the proactive refresh ?

I can imagine that may be that it will only be the actual refresh
token refreshed itself, but why keep the access token if the client
has requested a refresh ?

Sergey

-- Justin

On Nov 27, 2012, at 5:18 AM, Sergey Beryozkin wrote:

On 27/11/12 08:52, Guangqing Deng wrote:
It seems that the c
 lient
cannot know whether the refresh token
should be
used until a HTTP 401 error is returned from the resource server
due to
the expiration of current access token or some other reasons.
However, a
period of time cannot be ignored will be spent on obtain a new
access
token using the refresh token after the resource server returns a
HTTP
401 error to the client, which may degrade the user experience
since the
real-time nature of the service cannot be guaranteed. Is a
mechanism by
which the client can check the validity of the access token (or the
refresh token) in advance needed by Oauth?

I believe an access token response may offer an expires_in
parameter which can provide some hint. Actually this raises an
interesting question.
Suppose the client actually checks this parameter and decides to use
a refresh token it also has to pro-actively refresh its current
token
 .

IMHO this should work even if the access token has not expired yet
and effectively represents another form of a client-initiated
revocation of the access token ? It will mean a client which works
with the "expires_in" parameter can save a one round trip (the one
which returns a failure in case of the access token being expired) ?

Does it make sense ? If it does, can some relevant wording make it
into the revocation token draft ?

Cheers, Sergey



Guangqing Deng


*From:* Justin Richer<jricher@mitre.org>
*To:* Sergey Beryozkin<sberyozkin@gmail.com>
*Cc:* oauth@ietf.org
*Sent:* Wednesday, November 21, 2012 6:11 AM
*Subje
 ct:*
Re: [OAUTH-WG] How the client can decide it is time
to use
the refresh token

There's no signaling regarding the validity of the refresh token
from
the protected resource. In more distributed setups, the protected
resources know nothing about the refresh tokens because the PR
never
sees them. In any case. the code path is fairly straightforward,
even if
both tokens are expired:

- client presents AT to resource
- resource returns data, AT worked
- [or] resource returns 400 error to client, AT didn't work
- client presents RT to auth server
- auth server returns new AT, RT worked
- [or] auth server returns 400 error to client, RT didn't work
- client has to go get a new auth grant from the resource owner,
start over

-- Justin


On
11/21/2012 06:50 AM, Sergey Beryozkin wrote:
Hi

I'm looking for some guidance on how the client which already
owns an
access token can decide, after getting HTTP 400 back from the
resource
server it tries to access on behalf of the end user/resource
owner, can
decide that the refresh token it has can now be used to get a
new access
token.

[1] refers to various error conditions but it is not obvious to me
that the same conditions (some of them) should or can be
reported during
the actual client accessing the protected resource.

My question is, what error condition, if any, from [1] should be
reported back to the client failing to access a protected
resource due
to the access token being invalid or expired, so that it can
help the
client who also owns the refresh token to decide it can use it
now...

Thanks, Sergey

[1] http://tools.ietf.org/html/rfc6749#section-5.2

OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


OAuth mailing list
OAuth@ietf.org<mailto: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



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
------O2FU77HXJS7OQ6GOGO912K540TBZ2Y-- From torsten@lodderstedt.net Thu Nov 29 22:48:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D586721F89BE for ; Thu, 29 Nov 2012 22:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.914 X-Spam-Level: X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpY4K5hkSQpi for ; Thu, 29 Nov 2012 22:48:38 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.95]) by ietfa.amsl.com (Postfix) with ESMTP id 9680B21F89BA for ; Thu, 29 Nov 2012 22:48:37 -0800 (PST) Received: from [80.187.111.14] (helo=[100.70.123.14]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1TeKOm-0001af-1u; Fri, 30 Nov 2012 07:48:32 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <8fafd60e-3718-42db-adf3-a7eed1d4822c@email.android.com> References: <50B7D5BC.3090805@gmail.com> <8fafd60e-3718-42db-adf3-a7eed1d4822c@email.android.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----TE51KXO14PODZ12NUYKMS09B6YVLRP" From: Torsten Lodderstedt Date: Fri, 30 Nov 2012 07:42:18 +0100 To: Sergey Beryozkin , "" Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] Refresh grant and token revocation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 06:48:39 -0000 ------TE51KXO14PODZ12NUYKMS09B6YVLRP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, I posted to the wrong thread, I just re-sent the correct one. Regards, Torsten. Torsten Lodderstedt schrieb: >Hi, > >I would assume the clients knows the scope required for a certain >request (from documentation) and acquires the access token using the >respective scope from the authz server. Given this assumption, 401 may >only occur when the access token has expired. > >regards, >Torsten. > > > >Sergey Beryozkin schrieb: > >>Apologies for a noise on it, however I'd like to get some more >>clarifications on it. >> >>What I thought first about the refresh grant was that a client would >>use >>it for getting a new access token back after it gets a 401 back from >>PR. >> >>Next after seeing the comments from others it became obvious the >>refresh >>grant can be used to pro-actively refresh the existing token when the >>client realizes - this is what I'm really going to ask about. >> >>I also learned about the fact a refresh grant can effectively be used >>to >>clone the existing token - I'd like to avoid talking about this case >in >> >>this thread, even I got it wrong with the term 'clone' :-) >> >>So, as far as the refresh token grant is concerned, the grant which is > >>'supported' by the core spec, what are the expectations of the client >>which request to refresh a still valid access token ? >> >>I got a bit confused by the feedback that it may be per-AS specific. >>If it were the expectation then I'd not see the difference between the > >>core spec "refresh_token" grant and "a.b.c" custom grant. >> >>It seems reasonable that if the client does decide to be proactive and > >>use a refresh grant without using any optional scopes, and >specifically >> >>with the main and only purpose to refresh the access token which may >>get >>expired shortly, it should predictably get a new access token with a >>new >>time lease... >> >>And which means the old token must've gone by now and effectively >>revoked. This exactly what the client means, get me a new refreshed >>token... >> >>I've checked the token revocation grant. It's obviously a good idea to > >>let the client directly interact with the endpoint and remove whatever > >>token it want to remove. However, a refresh token request (without a >>scope parameter) should have the same side-effect >> >>Does it make any sense at all ? >> >>Thanks, Sergey >> >>_______________________________________________ >>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 ------TE51KXO14PODZ12NUYKMS09B6YVLRP Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

I posted to the wrong thread, I just re-sent the correct one.

Regards,
Torsten.



Torsten Lodderstedt <torsten@lodderstedt.net> schrieb:
Hi,

I would assume the clients knows the scope required for a certain request (from documentation) and acquires the access token using the respective scope from the authz server. Given this assumption, 401 may only occur when the access token has expired.

regards,
Torsten.



Sergey Beryozkin <sberyozkin@gmail.com> schrieb:
Apologies for a noise on it, however I'd like to get some more 
clarifications on it.

What I thought first about the refresh grant was that a client would use 
it for getting a new access token back after it gets a 401 back from PR.

Next after seeing the comments from others it became obvious the refresh 
grant can be used to pro-actively refresh the existing token when the 
client realizes - this is what I'm really going to ask about.

I also learned about the fact a refresh grant can effectively be used to 
clone the existing token - I'd like to avoid talking about this case in 
this thread, even I got it wrong with the term 'clone' :-)

So, as far as the refresh token grant is concerned, the grant which is 
'supported' by the core spec, what are the expectations of the client
which request to re
 fresh a
still valid access token ?

I got a bit confused by the feedback that it may be per-AS specific.
If it were the expectation then I'd not see the difference between the 
core spec "refresh_token" grant and "a.b.c" custom grant.

It seems reasonable that if the client does decide to be proactive and 
use a refresh grant without using any optional scopes, and specifically 
with the main and only purpose to refresh the access token which may get 
expired shortly, it should predictably get a new access token with a new 
time lease...

And which means the old token must've gone by now and effectively 
revoked. This exactly what the client means, get me a new refreshed 
token...

I've checked the token revocation grant. It's obviously a good idea to 
let the client directly interact with the endpoint and remove whatever 
token it want to remove. However, a refresh token request (without a 
scope
parameter) should have the same side-effect

Does it make any sense at all ?

Thanks, Sergey


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
------TE51KXO14PODZ12NUYKMS09B6YVLRP-- From torsten@lodderstedt.net Thu Nov 29 22:48:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAD421F89BA for ; Thu, 29 Nov 2012 22:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.914 X-Spam-Level: X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBQIHdDZhqEt for ; Thu, 29 Nov 2012 22:48:38 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0794221F895F for ; Thu, 29 Nov 2012 22:48:37 -0800 (PST) Received: from [80.187.111.14] (helo=[100.70.123.14]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1TeKOj-0004YQ-7d; Fri, 30 Nov 2012 07:48:29 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <50B7D5BC.3090805@gmail.com> References: <50B7D5BC.3090805@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----M4BU91O38RB6VLDR7H7KJW3IBZUHUO" From: Torsten Lodderstedt Date: Fri, 30 Nov 2012 07:48:21 +0100 To: Sergey Beryozkin , "" Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] Refresh grant and token revocation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 06:48:39 -0000 ------M4BU91O38RB6VLDR7H7KJW3IBZUHUO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, it might be reasonable in some cases to revoke the old access token (if the AS actually supports access token revocation). However, I can imagine situations in clustered systems where access tokens are acquired from from the same refresh token and used independently by different nodes or modules. In this case, revocation on refresh would not be desired. Note: In this case one would probably not use refresh token rotation. regards, Torsten. Sergey Beryozkin schrieb: >Apologies for a noise on it, however I'd like to get some more >clarifications on it. > >What I thought first about the refresh grant was that a client would >use >it for getting a new access token back after it gets a 401 back from >PR. > >Next after seeing the comments from others it became obvious the >refresh >grant can be used to pro-actively refresh the existing token when the >client realizes - this is what I'm really going to ask about. > >I also learned about the fact a refresh grant can effectively be used >to >clone the existing token - I'd like to avoid talking about this case in > >this thread, even I got it wrong with the term 'clone' :-) > >So, as far as the refresh token grant is concerned, the grant which is >'supported' by the core spec, what are the expectations of the client >which request to refresh a still valid access token ? > >I got a bit confused by the feedback that it may be per-AS specific. >If it were the expectation then I'd not see the difference between the >core spec "refresh_token" grant and "a.b.c" custom grant. > >It seems reasonable that if the client does decide to be proactive and >use a refresh grant without using any optional scopes, and specifically > >with the main and only purpose to refresh the access token which may >get >expired shortly, it should predictably get a new access token with a >new >time lease... > >And which means the old token must've gone by now and effectively >revoked. This exactly what the client means, get me a new refreshed >token... > >I've checked the token revocation grant. It's obviously a good idea to >let the client directly interact with the endpoint and remove whatever >token it want to remove. However, a refresh token request (without a >scope parameter) should have the same side-effect > >Does it make any sense at all ? > >Thanks, Sergey > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth ------M4BU91O38RB6VLDR7H7KJW3IBZUHUO Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

it might be reasonable in some cases to revoke the old access token (if the AS actually supports access token revocation). However, I can imagine situations in clustered systems where access tokens are acquired from from the same refresh token and used independently by different nodes or modules. In this case, revocation on refresh would not be desired.

Note: In this case one would probably not use refresh token rotation.

regards,
Torsten.



Sergey Beryozkin <sberyozkin@gmail.com> schrieb:
Apologies for a noise on it, however I'd like to get some more 
clarifications on it.

What I thought first about the refresh grant was that a client would use 
it for getting a new access token back after it gets a 401 back from PR.

Next after seeing the comments from others it became obvious the refresh 
grant can be used to pro-actively refresh the existing token when the 
client realizes - this is what I'm really going to ask about.

I also learned about the fact a refresh grant can effectively be used to 
clone the existing token - I'd like to avoid talking about this case in 
this thread, even I got it wrong with the term 'clone' :-)

So, as far as the refresh token grant is concerned, the grant which is 
'supported' by the core spec, what are the expectations of the client
which request to re
 fresh a
still valid access token ?

I got a bit confused by the feedback that it may be per-AS specific.
If it were the expectation then I'd not see the difference between the 
core spec "refresh_token" grant and "a.b.c" custom grant.

It seems reasonable that if the client does decide to be proactive and 
use a refresh grant without using any optional scopes, and specifically 
with the main and only purpose to refresh the access token which may get 
expired shortly, it should predictably get a new access token with a new 
time lease...

And which means the old token must've gone by now and effectively 
revoked. This exactly what the client means, get me a new refreshed 
token...

I've checked the token revocation grant. It's obviously a good idea to 
let the client directly interact with the endpoint and remove whatever 
token it want to remove. However, a refresh token request (without a 
scope
parameter) should have the same side-effect

Does it make any sense at all ?

Thanks, Sergey


OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------M4BU91O38RB6VLDR7H7KJW3IBZUHUO-- From s.ebling@telekom.de Fri Nov 30 02:26:02 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5AD21F86BE for ; Fri, 30 Nov 2012 02:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDgdl3atg+6P for ; Fri, 30 Nov 2012 02:26:02 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id A2F4121F84F8 for ; Fri, 30 Nov 2012 02:26:01 -0800 (PST) Received: from g8dbse01.krf01.telekom.de ([164.23.31.9]) by tcmail91.telekom.de with ESMTP; 30 Nov 2012 11:25:59 +0100 Received: from s4de8nsazdfe010.bmbg.telekom.de (s4de8nsazdfe010.bmbg.telekom.de [10.175.246.202]) by G8DBSE01.krf01.telekom.de with ESMTP for oauth@ietf.org; Fri, 30 Nov 2012 11:25:59 +0100 X-IronPort-AV: E=Sophos;i="4.84,191,1355094000"; d="scan'208";a="135387855" Received: from unknown (HELO QEO40065.de.t-online.corp) ([10.224.209.65]) by s4de8nsazdfe010.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 30 Nov 2012 11:25:59 +0100 Received: from QEO40072.de.t-online.corp ([169.254.1.29]) by QEO40065.de.t-online.corp ([10.224.209.65]) with mapi; Fri, 30 Nov 2012 11:25:58 +0100 From: "Ebling, Sebastian" To: "oauth@ietf.org WG" Date: Fri, 30 Nov 2012 11:25:58 +0100 Thread-Topic: [OAUTH-WG] review: draft-richer-oauth-chain-00.txt Thread-Index: Ac3Nuefe3oVBbCDIREenC0PgeBQAKQBGroxw Message-Id: <1AA88EE7AC2F2644989D65F506C031AE5A3887EE2B@QEO40072.de.t-online.corp> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] review: draft-richer-oauth-chain-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 10:26:02 -0000 Hi Phil, Some comments on draft-richer-oauth-chain-00.txt: Section 3.1. - I dislike the name of the grant type. "redelegate" is the use case but no= t the grant presented to the AS from RS1. I suggest to use "access_token" a= ccording to other grant types like authorization_code, password, refresh_to= ken. Section 3.2 "As this access token is bound to an existing access token, the authorizati= on server MUST NOT issue a refresh token." >From our operating experience [1] it may be useful to issue a refresh token= in some cases.=20 Example: RS1 may be a batch processing system that must be able to access RS2 some h= ours later to fulfill the originary request from the Client. The access tok= ens (AS to C and AS to RS1) may have expired when the job starts from the q= ueue. Issuing a refresh token enables RS1 to obtain a fresh access token (A= S to RS1). AS may limit the duration of the refresh token for such clients (RS1). Regards Sebastian [1] I'm a colleague of Torsten Lodderstedt at Deutsche Telekom, responsible= for the system life cycle of our Secure Token Service. We have already imp= lemented a very similar custom grant type for service chaining at Deutsche = Telekom. From sberyozkin@gmail.com Fri Nov 30 02:26:40 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5686221F84EB for ; Fri, 30 Nov 2012 02:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx1df8ZnXliX for ; Fri, 30 Nov 2012 02:26:39 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C77621F84E0 for ; Fri, 30 Nov 2012 02:26:39 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so372032lbk.31 for ; Fri, 30 Nov 2012 02:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2xa6n9abwFZzeF8UNHTdCfOoSOnqjrezmjta7gzwbiw=; b=z7snXj/X69Uo81nv+GTfjmTvSV+Fpu7O4qgXeFryjCoZfppgPNoeNRX3d6lUjpaD1U TVBgEERlHmPMKufj0N9D5Ys4jc1LHcuLC9Q5t8bROOWHdBJ+XwlkvI4PNmhxzgQOpuFb FFDSSCWx2vM39TSlS/G1oR52rRr9beCsb8NYf7i5pa5Jd8dtfOujjNOQRK/GLdRn7Msw ujbs3q/SIhc61jYmPI060uiULVfMyJotiJtJfWWoZ5IXMOGdz16Lj5PTjWAfadEhpS+p zifR0Ak6tuLctWNpWsliKTolGHZqeBCWQr5SA2/Sdp9J3PaGE/UVhN2Cx9Sc8iw2peao pGQg== Received: by 10.112.13.173 with SMTP id i13mr632743lbc.108.1354271197255; Fri, 30 Nov 2012 02:26:37 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id v6sm1908170lbf.11.2012.11.30.02.26.35 (version=SSLv3 cipher=OTHER); Fri, 30 Nov 2012 02:26:36 -0800 (PST) Message-ID: <50B889D9.5010202@gmail.com> Date: Fri, 30 Nov 2012 10:26:33 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Torsten Lodderstedt References: <50B7D5BC.3090805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [OAUTH-WG] Refresh grant and token revocation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 10:26:40 -0000 Hi, On 30/11/12 06:48, Torsten Lodderstedt wrote: > Hi, > > it might be reasonable in some cases to revoke the old access token (if > the AS actually supports access token revocation). However, I can > imagine situations in clustered systems where access tokens are acquired > from from the same refresh token and used independently by different > nodes or modules. In this case, revocation on refresh would not be desired. > > Note: In this case one would probably not use refresh token rotation. What I'm understanding is that there are many subtleties with the way refresh grant can be used in different scenarios. I hope in time there will be more specific recommendations about the refresh grants and specifically about the expectations of the clients with respect to using such grants. For the moment "use it when AT has expired" is the most straightforward case with the predictable outcome and thus the code which use the grant for these purposes is portable. The other uses of the grant (with or without the optional scope) have the application-specific outcome - so hopefully in time more of these application specific uses will make it into the spec level text - IMHO it will help users or developers like myself :-) Thanks Sergey > > regards, > Torsten. > > > > Sergey Beryozkin schrieb: > > Apologies for a noise on it, however I'd like to get some more > clarifications on it. > > What I thought first about the refresh grant was that a client would use > it for getting a new access token back after it gets a 401 back from PR. > > Next after seeing the comments from others it became obvious the refresh > grant can be used to pro-actively refresh the existing token when the > client realizes - this is what I'm really going to ask about. > > I also learned about the fact a refresh grant can effectively be used to > clone the existing token - I'd like to avoid talking about this case in > this thread, even I got it wrong with the term 'clone' :-) > > So, as far as the refresh token grant is concerned, the grant which is > 'supported' by the core spec, what are the expectations of the client > which request to refresh a > still valid access token ? > > I got a bit confused by the feedback that it may be per-AS specific. > If it were the expectation then I'd not see the difference between the > core spec "refresh_token" grant and "a.b.c" custom grant. > > It seems reasonable that if the client does decide to be proactive and > use a refresh grant without using any optional scopes, and specifically > with the main and only purpose to refresh the access token which may get > expired shortly, it should predictably get a new access token with a new > time lease... > > And which means the old token must've gone by now and effectively > revoked. This exactly what the client means, get me a new refreshed > token... > > I've checked the token revocation grant. It's obviously a good idea to > let the client directly interact with the endpoint and remove whatever > token it want to remove. However, a refresh token request (without a > scope > parameter) should have the same side-effect > > Does it make any sense at all ? > > Thanks, Sergey > > ------------------------------------------------------------------------ > > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sberyozkin@gmail.com Fri Nov 30 02:31:07 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981B021F86AC for ; Fri, 30 Nov 2012 02:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxeVEXBqWFzt for ; Fri, 30 Nov 2012 02:31:06 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 90BC021F84E0 for ; Fri, 30 Nov 2012 02:31:06 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so270064lah.31 for ; Fri, 30 Nov 2012 02:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=548YV/pbpgW7N1/SUNjreolDzQRYoOtynNlisltt3sk=; b=DuaJDCD0s4VpZKc2Q516qQ2y8gW7Eke4BoQeIEkD+VGbfOKt1MsojkucuehUWNnAOI a6SLlVJldioaTJfWA0doCYZQuj9g+lUatYMTLvXoYudx3n4kfSbJIA9e4ZF2DaBX5VzR f63v3+4QWoI2FfyduX4GzDpC+zJ4C9kXdb0UtSnlhfGvzpSqb1BO/owfDCsMoAmJaqmQ OEHmWUWkRQX72YM0gxr0xFBOnkHJ8RMORvdiEsu71Wf4Bz90M6JPdiCTzT07FOLfbl6N tJzwL1azgb2Sh+3SugcwuRdhe92BNbg8Lfb4Fw+GNlldsN+icDyTuUnozGftfq/9vr5D mDgQ== Received: by 10.152.46.161 with SMTP id w1mr819939lam.27.1354271465366; Fri, 30 Nov 2012 02:31:05 -0800 (PST) Received: from [10.36.224.148] ([217.173.99.61]) by mx.google.com with ESMTPS id ti4sm1819566lab.1.2012.11.30.02.31.03 (version=SSLv3 cipher=OTHER); Fri, 30 Nov 2012 02:31:04 -0800 (PST) Message-ID: <50B88AE5.3070809@gmail.com> Date: Fri, 30 Nov 2012 10:31:01 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <1AA88EE7AC2F2644989D65F506C031AE5A3887EE2B@QEO40072.de.t-online.corp> In-Reply-To: <1AA88EE7AC2F2644989D65F506C031AE5A3887EE2B@QEO40072.de.t-online.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] review: draft-richer-oauth-chain-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 10:31:07 -0000 On 30/11/12 10:25, Ebling, Sebastian wrote: > Hi Phil, > > Some comments on draft-richer-oauth-chain-00.txt: > > Section 3.1. > - I dislike the name of the grant type. "redelegate" is the use case but not the grant presented to the AS from RS1. I suggest to use "access_token" according to other grant types like authorization_code, password, refresh_token. > Interesting. What about adding one more optional parameter to "refresh_grant" ? thanks, Sergey > Section 3.2 > "As this access token is bound to an existing access token, the authorization server MUST NOT issue a refresh token." > From our operating experience [1] it may be useful to issue a refresh token in some cases. > > Example: > RS1 may be a batch processing system that must be able to access RS2 some hours later to fulfill the originary request from the Client. The access tokens (AS to C and AS to RS1) may have expired when the job starts from the queue. Issuing a refresh token enables RS1 to obtain a fresh access token (AS to RS1). > AS may limit the duration of the refresh token for such clients (RS1). > > Regards > > Sebastian > > [1] I'm a colleague of Torsten Lodderstedt at Deutsche Telekom, responsible for the system life cycle of our Secure Token Service. We have already implemented a very similar custom grant type for service chaining at Deutsche Telekom. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Fri Nov 30 06:07:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9AC21F849B for ; Fri, 30 Nov 2012 06:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7tSkkTbpJQQ for ; Fri, 30 Nov 2012 06:07:15 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D32EB21F84CE for ; Fri, 30 Nov 2012 06:07:14 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id r1so60192ggn.31 for ; Fri, 30 Nov 2012 06:07:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=1UVio1pV+99iSUSt5Gkomeblx8Ghf/bhCdTeZMREF3I=; b=QXt8uoXzJFZPulVMFN3vgO9JEV9Do2l8rpU7JAt3GjgxHGksDAZGhR0S65V/48k6jB X4s7bUqPfXuuCPn0rIawEGG4s6N8RG65M503LK+8JfI8roGc8fbu1nk27CIdbTVgyYiu d1DoQoF/612fxvnfuGzfI+CpvVPg2kOB8KyIzWO15H7gMF88g5n+p83fWB8Ty6z5YsnV todh7OKaxJUPh9KNL/Lzttqy5FcILQVjUbpIFIx5mtSPTjPBtKvzKODBYlkKNZKx4Zpt 4Y2nLpGetGSAbRGwqn+znKuovYXKglpspbvBXg6BOr6dmKBS/TL0p2xYry9Q2x7J4dCo 8qYg== Received: by 10.236.92.6 with SMTP id i6mr1153938yhf.40.1354284434332; Fri, 30 Nov 2012 06:07:14 -0800 (PST) Received: from [192.168.1.211] (190-20-13-133.baf.movistar.cl. [190.20.13.133]) by mx.google.com with ESMTPS id x9sm4889412yhl.17.2012.11.30.06.07.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Nov 2012 06:07:13 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_103D3F2B-A8B9-43F0-A44D-33EE5F547233" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Fri, 30 Nov 2012 11:07:04 -0300 Message-Id: <7433A429-C2F0-43E0-ABFA-332F49DDC39B@ve7jtb.com> References: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> <50B7D531.4040005@mitre.org> <50B7D74D.6090401@mitre.org> To: Ariel Barreiro X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlRKzEh7XIA0F8L7e5m7chwBM5uoFGrHlfDXRD8vCeO0UEfDXOfYDYo1kZl9RvuS6RqAkZv Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 14:07:20 -0000 --Apple-Mail=_103D3F2B-A8B9-43F0-A44D-33EE5F547233 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The client in the is case is a server. The front channel involves = making indirect connection through the user agent. The back channel is a direct TLS protected server to server = communication without the users browser in the path. John B. On 2012-11-29, at 7:01 PM, Ariel Barreiro wrote: > Aha, maybe that's the bit that I didn't understand that good then... = front channel and back channel, although I can see difference I am not = quite sure of how is it different on the implementation >=20 > Client request to the auth end point is through a browser... fine, you = send the redirect uri. After authenticating you get back to the = redirect_uri with the auth code. >=20 > Isn't it the client, again, with the auth code, the one that initiates = the request to the token end point? I see no different channel on the = requests. >=20 >=20 > On Thu, Nov 29, 2012 at 7:44 PM, Justin Richer = wrote: > The request to the auth endpoint is front channel, through a browser. = The request to the token endpoint is back channel, server-to-server. = These are very, very different attack surfaces. If an attacker has = access to and control of both channels, you're pretty hosed anyway = and OAuth (nor TLS, nor basically anything else I can think of) will = help you. >=20 > The security model in OAuth comes from limiting the knowledge at each = part of the transaction and spreading the risk appropriately. >=20 > -- Justin >=20 >=20 > On 11/29/2012 04:43 PM, Ariel Barreiro wrote: >> But so the protection of sending the SAME redirect_uri in both the = auth end point and token end point makes not much of a sense when there = is a registered URI, and if there's not, an attacker, as far as I = understood, can compromise both the request to the auth end point as = well as the token end point, so I would assume that it doesn't make much = sense either. >>=20 >>=20 >> On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer = wrote: >> So here's the breakdown of how the redirect uri works: >>=20 >>=20 >>=20 >> - If the client sends a redirect URI to the auth endpoint, and the = client has registered one or more redirect URIs, it MUST match one of = the redirect URIs it had registered. (for a soft definition of "match" = -- it can be prefix, or pattern, or exact string, so long as the AS = knows how to do it, IIRC)=20 >> - If the client does not send a redirect URI to the auth endpoint, = and the client has either only registered one or the AS has some notion = of a "default" redirect URI, the AS will just use that one. >>=20 >> Now the part that seems to trip people up: >>=20 >> - If the client had sent a redirect URI to the auth endpoint, then it = MUST send the EXACT SAME redirect URI to the token endpoint. This = request is back-channel and protected with the client's credentials. >> - If the client did not send a redirect URI to the auth endpoint, = then it does NOT send a redirect URI to the token endpoint. >>=20 >>=20 >> So here's where the protection comes in. If the attacker modifies the = request to the auth endpoint so that it has a different redirect URI, = then that redirect URI MUST match one that's attached to the client_id = in the request. Furthermore, the call to the token endpoint to get the = token MUST also contain that modified redirect URI as well as any client = credentials needed to make the call. A "good" client will send a "good" = redirect URI, even if the code has been sent someplace else in the mean = time. >>=20 >> Hope this clears things up, >>=20 >> -- Justin >>=20 >>=20 >> On 11/29/2012 04:24 PM, Ariel Barreiro wrote: >>> But isn't having a registered redirect URI on the authorization end = point enought to prevent this, why is it required to send the redirect = URI to the token end point if the previous method prevents it? >>>=20 >>> I appreciate a lot your response but I am still finding it hard to = picture it, and, was in your explanation a modification to the request = URI? >>>=20 >>>=20 >>> On Thu, Nov 29, 2012 at 6:25 PM, John Bradley = wrote: >>> A confidential client authenticates to the token endpoint preventing = an attacker from getting the token. >>>=20 >>> In the case of a public client if you get the code and redirect URI = then you can get the token. (Why confidential clients are better than = public ones) >>>=20 >>> Sending the redirect URI to the token endpoint protects the client = from the case where client A gets a code for user B because the user = logged into A and A is using the client ID of client Z because it wants = to impersonate user B at client A. Client A pretending to be client Z = can easily get the code. However the redirect URI that the real client = Z sends will be different than the one the fake client Z used to get = code and the real client A won't be able to exchange the code for a = access token and be tricked into thinking that the resource owner is the = one presenting it the code. >>>=20 >>> That is the long explanation. The short one is unregistered = redirect URI are bad. Sending the redirect URI to the token endpoint = protects clients from becoming confused about the presenter of the code. >>> Nothing is going to help a public client if someone intercepts code. >>>=20 >>> John B. >>>=20 >>> On 2012-11-29, at 3:05 PM, Ariel Barreiro wrote: >>>=20 >>>> Still I can't see how to prevent the attack. I understand that = there is no redirection when requesting an access token, however, the = protocol requests the client to send the redirect_uri to the token end = point to validate it was the same used in the authorization. If the = authorization was compromised, couldn't the access token request be = forged as well? >>>>=20 >>>>=20 >>>> On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt = wrote: >>>> There is no redirection when requesting an access token. Token = requests are typically out-of-band from the user. The attack only = happens during an authorization redirect flow in the browser. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: >>>>=20 >>>> > I am struggling a bit to understand this attack and the advice in = to how to prevent. I understand that if I, as an attacker, can change = the redirection uri when authorizing, can not it as well change the = redirect uri when requesting an access token? >>>> > >>>> > Any explanation examples on how this attack might work and how = sending the redirect_uri when requesting the access toekn prevents it = are welcomed. >>>> > >>>> > Thanks, >>>> > Ariel.=3D >>>> > _______________________________________________ >>>> > OAuth mailing list >>>> > OAuth@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >=20 >=20 --Apple-Mail=_103D3F2B-A8B9-43F0-A44D-33EE5F547233 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 The client in the is case is a server.  The front channel involves making indirect connection through the user agent.

The back channel is a direct TLS protected server to server communication without the users browser in the path.

John B.
On 2012-11-29, at 7:01 PM, Ariel Barreiro <abarrei@gmail.com> wrote:

Aha, maybe that's the bit that I didn't understand that good then... front channel and back channel, although I can see difference I am not quite sure of how is it different on the implementation

Client request to the auth end point is through a browser... fine, you send the redirect uri. After authenticating you get back to the redirect_uri with the auth code.

Isn't it the client, again, with the auth code, the one that initiates the request to the token end point? I see no different channel on the requests.


On Thu, Nov 29, 2012 at 7:44 PM, Justin Richer <jricher@mitre.org> wrote:
The request to the auth endpoint is front channel, through a browser. The request to the token endpoint is back channel, server-to-server. These are very, very different attack surfaces. If an attacker has access to and control of both channels, you're pretty hosed anyway and OAuth (nor TLS, nor basically anything else I can think of) will help you.

The security model in OAuth comes from limiting the knowledge at each part of the transaction and spreading the risk appropriately.

 -- Justin


On 11/29/2012 04:43 PM, Ariel Barreiro wrote:
But so the protection of sending the SAME redirect_uri in both the auth end point and token end point makes not much of a sense when there is a registered URI, and if there's not, an attacker, as far as I understood, can compromise both the request to the auth end point as well as the token end point, so I would assume that it doesn't make much sense either.


On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer <jricher@mitre.org> wrote:
So here's the breakdown of how the redirect uri works:



- If the client sends a redirect URI to the auth endpoint, and the client has registered one or more redirect URIs, it MUST match one of the redirect URIs it had registered. (for a soft definition of "match" -- it can be prefix, or pattern, or exact string, so long as the AS knows how to do it, IIRC)
- If the client does not send a redirect URI to the auth endpoint, and the client has either only registered one or the AS has some notion of a "default" redirect URI, the AS will just use that one.

Now the part that seems to trip people up:

- If the client had sent a redirect URI to the auth endpoint, then it MUST send the EXACT SAME redirect URI to the token endpoint. This request is back-channel and protected with the client's credentials.
- If the client did not send a redirect URI to the auth endpoint, then it does NOT send a redirect URI to the token endpoint.


So here's where the protection comes in. If the attacker modifies the request to the auth endpoint so that it has a different redirect URI, then that redirect URI MUST match one that's attached to the client_id in the request. Furthermore, the call to the token endpoint to get the token MUST also contain that modified redirect URI as well as any client credentials needed to make the call. A "good" client will send a "good" redirect URI, even if the code has been sent someplace else in the mean time.

Hope this clears things up,

 -- Justin


On 11/29/2012 04:24 PM, Ariel Barreiro wrote:
But isn't having a registered redirect URI on the authorization end point enought to prevent this, why is it required to send the redirect URI to the token end point if the previous method prevents it?

I appreciate a lot your response but I am still finding it hard to picture it, and, was in your explanation a modification to the request URI?


On Thu, Nov 29, 2012 at 6:25 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
A confidential client authenticates to the token endpoint preventing an attacker from getting the token.

In the case of a public client if you get the code and redirect URI then you can get the token.  (Why confidential clients are better than public ones)

Sending the redirect URI to the token endpoint protects the client from the case where client A gets a code for user B because the user logged into A and A is using the client ID of client Z because it wants to impersonate user B at client A.   Client A pretending to be client Z  can easily get the code.  However the redirect URI that the real client Z sends will be different than the one the fake client Z used to get code and the real client A won't be able to exchange the code for a access token and be tricked into thinking that the resource owner is the one presenting it the code.

That is the long explanation.  The short one is unregistered redirect URI are bad.   Sending the redirect URI to the token endpoint protects clients from becoming confused about the presenter of the code.
Nothing is going to help a public client if someone intercepts code.

John B.

On 2012-11-29, at 3:05 PM, Ariel Barreiro <abarrei@gmail.com> wrote:

Still  I can't see how to prevent the attack. I understand that there is no redirection when requesting an access token, however, the protocol requests the client to send the redirect_uri to the token end point to validate it was the same used in the authorization. If the authorization was compromised, couldn't the access token request be forged as well?


On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
There is no redirection when requesting an access token.  Token requests are typically out-of-band from the user.  The attack only happens during an authorization redirect flow in the browser.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote:

> I am struggling a bit to understand this attack and the advice in to how to prevent. I understand that if I, as an attacker, can change the redirection uri when authorizing, can not it as well change the redirect uri when requesting an access token?
>
> Any explanation examples on how this attack might work and how sending the redirect_uri when requesting the access toekn prevents it are welcomed.
>
> Thanks,
> Ariel.=
> _______________________________________________
> 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





--Apple-Mail=_103D3F2B-A8B9-43F0-A44D-33EE5F547233-- From abarrei@gmail.com Fri Nov 30 06:20:06 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60BE21F8AE2 for ; Fri, 30 Nov 2012 06:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7QgFuDuids9 for ; Fri, 30 Nov 2012 06:20:05 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C55AD21F8A6C for ; Fri, 30 Nov 2012 06:20:04 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so795136ieb.31 for ; Fri, 30 Nov 2012 06:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dEadNA3b7WKi7lBnFZUxVNZbADMv0Is6MWxfTXuxgRM=; b=IvgpCK+xUgiCGHDFja+awbR/p8E46agWAbSLT7lJEJxgxqEOCeM5IAkDNXiOTw4IIv pw6KtNQDormLURFNQXKZgPUEpZpVtDh6Pm9vON/QDrp+ohhrnVJTNSPePqvwS3RE2vXm tQZ3VyJBGRZnCf8rz/+cjJco3/GghlAvkPfmQjhkrOeMc6rx7468njIg+lNd77WdbxkK l7hQm/ymEzlRp02wJ0xEIhin5fnoCwq4a2o4mzLIDVCIfZzSALEyrauwwN4aFS6TLQuT 6T2LBSvykX53fxQONDRpoD86KOqKrWVgH/qZOE3I+ugQXdqaLUa0fcVn5RbIhcCk3jre bXCw== Received: by 10.42.63.4 with SMTP id a4mr978754ici.40.1354285204441; Fri, 30 Nov 2012 06:20:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.76.167 with HTTP; Fri, 30 Nov 2012 06:19:44 -0800 (PST) In-Reply-To: <7433A429-C2F0-43E0-ABFA-332F49DDC39B@ve7jtb.com> References: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> <50B7D531.4040005@mitre.org> <50B7D74D.6090401@mitre.org> <7433A429-C2F0-43E0-ABFA-332F49DDC39B@ve7jtb.com> From: Ariel Barreiro Date: Fri, 30 Nov 2012 11:19:44 -0300 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=90e6ba614c30890aee04cfb718e3 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 14:20:06 -0000 --90e6ba614c30890aee04cfb718e3 Content-Type: text/plain; charset=ISO-8859-1 But when we are talking of redirection URI manipulation, are we talking of compromising the server or some place in the networking route in which the request_uri can be changed or we are talking of a compromise in the user browser? When I think of redirection URI manipulation, I would think that I would chnge the redirect_uri, so that the authorization code is sent somwhere else. If that's the case, then wherever the authorization code is received, it can be used to request a token from that place and that seems perfectly possible, always talking with unregistered redirect_uris On Fri, Nov 30, 2012 at 12:07 PM, John Bradley wrote: > The client in the is case is a server. The front channel involves making > indirect connection through the user agent. > > The back channel is a direct TLS protected server to server communication > without the users browser in the path. > > John B. > > On 2012-11-29, at 7:01 PM, Ariel Barreiro wrote: > > Aha, maybe that's the bit that I didn't understand that good then... front > channel and back channel, although I can see difference I am not quite sure > of how is it different on the implementation > > Client request to the auth end point is through a browser... fine, you > send the redirect uri. After authenticating you get back to the > redirect_uri with the auth code. > > Isn't it the client, again, with the auth code, the one that initiates the > request to the token end point? I see no different channel on the requests. > > > On Thu, Nov 29, 2012 at 7:44 PM, Justin Richer wrote: > >> The request to the auth endpoint is front channel, through a browser. >> The request to the token endpoint is back channel, server-to-server. These >> are very, very different attack surfaces. If an attacker has access to and >> control of both channels, you're pretty hosed anyway and OAuth (nor TLS, >> nor basically anything else I can think of) will help you. >> >> The security model in OAuth comes from limiting the knowledge at each >> part of the transaction and spreading the risk appropriately. >> >> -- Justin >> >> >> On 11/29/2012 04:43 PM, Ariel Barreiro wrote: >> >> But so the protection of sending the SAME redirect_uri in both the auth >> end point and token end point makes not much of a sense when there is a >> registered URI, and if there's not, an attacker, as far as I understood, >> can compromise both the request to the auth end point as well as the token >> end point, so I would assume that it doesn't make much sense either. >> >> >> On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer wrote: >> >>> So here's the breakdown of how the redirect uri works: >>> >>> >>> >>> - If the client sends a redirect URI to the auth endpoint, and the >>> client has registered one or more redirect URIs, it MUST match one of the >>> redirect URIs it had registered. (for a soft definition of "match" -- it >>> can be prefix, or pattern, or exact string, so long as the AS knows how to >>> do it, IIRC) >>> - If the client does not send a redirect URI to the auth endpoint, and >>> the client has either only registered one or the AS has some notion of a >>> "default" redirect URI, the AS will just use that one. >>> >>> Now the part that seems to trip people up: >>> >>> - If the client had sent a redirect URI to the auth endpoint, then it >>> MUST send the EXACT SAME redirect URI to the token endpoint. This request >>> is back-channel and protected with the client's credentials. >>> - If the client did not send a redirect URI to the auth endpoint, then >>> it does NOT send a redirect URI to the token endpoint. >>> >>> >>> So here's where the protection comes in. If the attacker modifies the >>> request to the auth endpoint so that it has a different redirect URI, then >>> that redirect URI MUST match one that's attached to the client_id in the >>> request. Furthermore, the call to the token endpoint to get the token MUST >>> also contain that modified redirect URI as well as any client credentials >>> needed to make the call. A "good" client will send a "good" redirect URI, >>> even if the code has been sent someplace else in the mean time. >>> >>> Hope this clears things up, >>> >>> -- Justin >>> >>> >>> On 11/29/2012 04:24 PM, Ariel Barreiro wrote: >>> >>> But isn't having a registered redirect URI on the authorization end >>> point enought to prevent this, why is it required to send the redirect URI >>> to the token end point if the previous method prevents it? >>> >>> I appreciate a lot your response but I am still finding it hard to >>> picture it, and, was in your explanation a modification to the request URI? >>> >>> >>> On Thu, Nov 29, 2012 at 6:25 PM, John Bradley wrote: >>> >>>> A confidential client authenticates to the token endpoint preventing an >>>> attacker from getting the token. >>>> >>>> In the case of a public client if you get the code and redirect URI >>>> then you can get the token. (Why confidential clients are better than >>>> public ones) >>>> >>>> Sending the redirect URI to the token endpoint protects the client >>>> from the case where client A gets a code for user B because the user logged >>>> into A and A is using the client ID of client Z because it wants to >>>> impersonate user B at client A. Client A pretending to be client Z can >>>> easily get the code. However the redirect URI that the real client Z sends >>>> will be different than the one the fake client Z used to get code and the >>>> real client A won't be able to exchange the code for a access token and be >>>> tricked into thinking that the resource owner is the one presenting it the >>>> code. >>>> >>>> That is the long explanation. The short one is unregistered redirect >>>> URI are bad. Sending the redirect URI to the token endpoint protects >>>> clients from becoming confused about the presenter of the code. >>>> Nothing is going to help a public client if someone intercepts code. >>>> >>>> John B. >>>> >>>> On 2012-11-29, at 3:05 PM, Ariel Barreiro wrote: >>>> >>>> Still I can't see how to prevent the attack. I understand that there >>>> is no redirection when requesting an access token, however, the protocol >>>> requests the client to send the redirect_uri to the token end point to >>>> validate it was the same used in the authorization. If the authorization >>>> was compromised, couldn't the access token request be forged as well? >>>> >>>> >>>> On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt wrote: >>>> >>>>> There is no redirection when requesting an access token. Token >>>>> requests are typically out-of-band from the user. The attack only happens >>>>> during an authorization redirect flow in the browser. >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: >>>>> >>>>> > I am struggling a bit to understand this attack and the advice in to >>>>> how to prevent. I understand that if I, as an attacker, can change the >>>>> redirection uri when authorizing, can not it as well change the redirect >>>>> uri when requesting an access token? >>>>> > >>>>> > Any explanation examples on how this attack might work and how >>>>> sending the redirect_uri when requesting the access toekn prevents it are >>>>> welcomed. >>>>> > >>>>> > Thanks, >>>>> > Ariel.= >>>>> > _______________________________________________ >>>>> > 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> >> > > --90e6ba614c30890aee04cfb718e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable But when we are talking of redirection URI manipulation, are we talking of = compromising the server or some place in the networking route in which the = request_uri can be changed or we are talking of a compromise in the user br= owser?

When I think of redirection URI manipulation, I would think = that I would chnge the redirect_uri, so that the=A0authorization=A0code is = sent somwhere else. If that's the case, then wherever the authorization= code is received, it can be used to request a token from that place and th= at seems perfectly possible, always talking with unregistered redirect_uris=


On Fri, Nov 3= 0, 2012 at 12:07 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:=
The client in the is case is a server. = =A0The front channel involves making indirect connection through the user a= gent.

The back channel is a direct TLS protected server = to server communication without the users browser in the path.

John B.

On 2012-11-= 29, at 7:01 PM, Ariel Barreiro <abarrei@gmail.com> wrote:

Aha, maybe that's the bit that I didn't understand that good then..= . front channel and back channel, although I can see difference I am not qu= ite sure of how is it different on the implementation

Client request to the auth end point is through a browser... fine, you send= the redirect uri. After authenticating you get back to the redirect_uri wi= th the auth code.

Isn't it the client, aga= in, with the auth code, the one that initiates the request to the token end= point? I see no different channel on the requests.


On Thu, Nov 2= 9, 2012 at 7:44 PM, Justin Richer <jricher@mitre.org> wrote:=
=20 =20 =20
The request to the auth endpoint is front channel, through a browser. The request to the token endpoint is back channel, server-to-server. These are very, very different attack surfaces. If an attacker has access to and control of both channels, you're pretty hosed anyway and OAuth (nor TLS, nor basically anything else I can think of) will help you.

The security model in OAuth comes from limiting the knowledge at each part of the transaction and spreading the risk appropriately.

=A0-- Justin


On 11/29/2012 04:43 PM, Ariel Barreiro wrote:
=20 But so the protection of sending the SAME redirect_uri in both the auth end point and token end point makes not much of a sense when there is a registered URI, and if there's not, an attacker, as fa= r as I understood, can compromise both the request to the auth end point as well as the token end point, so I would assume that it doesn't make much sense either.


On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer <jricher@mitre.org> wrote:
So here's the breakdown of how the redirect uri works:



- If the client sends a redirect URI to the auth endpoint, and the client has registered one or more redirect URIs, it MUST match one of the redirect URIs it had registered. (for a soft definition of "match"= -- it can be prefix, or pattern, or exact string, so long as the AS knows how to do it, IIRC)
- If the client does not send a redirect URI to the auth endpoint, and the client has either only registered one or the AS has some notion of a "default" redirect= URI, the AS will just use that one.

Now the part that seems to trip people up:

- If the client had sent a redirect URI to the auth endpoint, then it MUST send the EXACT SAME redirect URI to the token endpoint. This request is back-channel and protected with the client's credentials.
- If the client did not send a redirect URI to the auth endpoint, then it does NOT send a redirect URI to the token endpoint.


So here's where the protection comes in. If the attacke= r modifies the request to the auth endpoint so that it has a different redirect URI, then that redirect URI MUST match one that's attached to the client_id in the request. Furthermore, the call to the token endpoint to get the token MUST also contain that modified redirect URI as well as any client credentials needed to make the call. A "good" client will send a "good"= ; redirect URI, even if the code has been sent someplace else in the mean time.

Hope this clears things up,

=A0-- Justin


On 11/29/2012 04:24 PM, Ariel Barreiro wrote:
But isn't having a registe= red redirect URI on the authorization end point enought to prevent this, why is it required to send the redirect URI to the token end point if the previous method prevents it?

I appreciate a lot your response but I am still finding it hard to picture it, and, was in your explanation a modification to the request URI?


On Thu, Nov 29, 2012 at 6:25 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
A confidential client authenticates to the token endpoint preventing an attacker from getting the token.

In the case of a public client if you get the code and redirect URI then you can get the token. =A0(Why confidential clients are better than public ones)

Sending the redirect URI to the token endpoint protects the client from the case where client A gets a code for user B because the user logged into A and A is using the client ID of client Z because it wants to impersonate user B at client A. =A0 Client A pretending to be client Z =A0can easily get the code. =A0However the redirect URI that the real client Z sends will be different than the one the fake client Z used to get code and the real client A won't be able to exchange the code for a access token and be tricked into thinking that the resource owner is the one presenting it the code.

That is the long explanation. =A0The short one is unregistered redirect URI are bad. =A0 Sending the redirect URI to the token endpoint protects clients from becoming confused about the presenter of the code.
Nothing is going to help a public client if someone intercepts code.

John B.

On 2012-11-29, at 3:05 PM, Ariel Barreiro <abarrei@gmail.com> wrote:

Still =A0I can't see how to prevent the attack. I understand that there is no redirection when requesting an access token, however, the protocol requests the client to send the redirect_uri to the token end point to validate it was the same used in the authorization. If the authorization was compromised, couldn't the access token request be forged as well?


On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt <phil.hunt@or= acle.com> wrote:
= There is no redirection when requesting an access token. =A0Token requests are typically out-of-band from the user. =A0The attack only happens during an authorization redirect flow in the browser.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote:

> I am struggling a bit to understand this attack and the advice in to how to prevent. I understand that if I, as an attacker, can change the redirection uri when authorizing, can not it as well change the redirect uri when requesting an access token?
>
> Any explanation examples on how this attack might work and how sending the redirect_uri when requesting the access toekn prevents it are welcomed.
>
> Thanks,
> Ariel.=3D
> _____________________________= __________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mail= man/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/= oauth




_______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth






--90e6ba614c30890aee04cfb718e3-- From sakimura@gmail.com Fri Nov 30 06:36:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384FF21F84F1 for ; Fri, 30 Nov 2012 06:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pu8QrvM8XysO for ; Fri, 30 Nov 2012 06:36:27 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02B0521F849B for ; Fri, 30 Nov 2012 06:36:26 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so260157eaa.31 for ; Fri, 30 Nov 2012 06:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type; bh=tnxG9QEyF4tEcUVeh27LZ+RbaU8YdAGCjUHvl1F5Nmc=; b=Lbj7TRGs4Ch1P/DHY7uhXxez9/FXFYEPlUSt4FA6f1ftyuTkDrWTRSPj0EU6uBW5Gb 6texJq+9T2bNwkk9ItIyu0j5LBsKe29JB/5pTV1VT1VQfGICCeKs4TaAYhCHdHHK4mqo ibP6VylextGphWY8V2bQlYa2gapF9QjaDxJ23GJTKyNvm3in6F04zECJbPPH1AfJFFLc gEbRBdDavFlJtPiW1b2A8FJcnKN6PhJCGZP7SN6teMoOiAPG787VTJ6/572zP1hAZFZw LLDOnmxxLhYosRr6DwxnUBVpBZ8gl/o1/TON2GfpEOoZDIqp0tbC4m3xigNqLPZbOYcF 75qQ== Received: by 10.14.220.71 with SMTP id n47mr5035229eep.39.1354286185860; Fri, 30 Nov 2012 06:36:25 -0800 (PST) References: From: Nat Sakimura Mime-Version: 1.0 (1.0) In-Reply-To: Date: Fri, 30 Nov 2012 23:35:35 +0900 Message-ID: <-14027699925830419@unknownmsgid> To: Phil Hunt Content-Type: multipart/alternative; boundary=047d7b621ef0084d4004cfb7535d Cc: oauth WG Subject: Re: [OAUTH-WG] Refresh of chaining draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 14:36:28 -0000 --047d7b621ef0084d4004cfb7535d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just to add more support for the usefulness of the chaining, OpenID Connect's aggregated claims model indeed falls under this category. Sent from iPad 2012/11/29 7:44=E3=80=81Phil Hunt wrote: All, After a request at IETF85 and a reminder from Hannes, I've posted a refresh of my original chaining document. No changes have been made in the refresh. My current position is that this type of chaining (as defined in my earlier draft) is useful when you need to get a new token after crossing an administrative boundary. It is less useful when you have servers wanting to chain in essentially an act on behalf of case where a 1-leg solution is more desirable and 2-legs are costly. My plan is to work with Justin and reconcile with his work on http://tools.ietf.org/id/draft-richer-oauth-chain-00.txt A new version of I-D, draft-hunt-oauth-chain-01.txt has been successfully submitted by Phil Hunt and posted to the IETF repository. Filename: draft-hunt-oauth-chain Revision: 01 Title: Chain Grant Type for OAuth2 Creation date: 2012-11-28 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-hunt-oauth-chain-01.txt Status: http://datatracker.ietf.org/doc/draft-hunt-oauth-chain Htmlized: http://tools.ietf.org/html/draft-hunt-oauth-chain-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-oauth-chain-= 01 Abstract: This specification defines a method by which an OAuth protected service, can use a received oauth token from its client, to in turn, act as a client and access another OAuth protected service in a 'chained' profile. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --047d7b621ef0084d4004cfb7535d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to add more support for the u= sefulness of the chaining, OpenID Connect's aggregated claims model ind= eed falls under this category.=C2=A0

Sent from iPad

2012/11/29 7:44=E3=80=81Phil Hunt <phil.hunt@oracle.com> wrote:=C2= =A0

All,

Aft= er a request at IETF85 and a reminder from Hannes, I've posted a refres= h of my original chaining document. No changes have been made in the refres= h.

My current position is that this type of chaining (as d= efined in my earlier draft) is useful when you need to get a new token afte= r crossing an administrative boundary. =C2=A0It is less useful when you hav= e servers wanting to chain in essentially an act on behalf of case where a = 1-leg solution is more desirable and 2-legs are costly.

My plan is to work with Justin and reconcile with his w= ork on=C2=A0http://tools.ietf.org/id/draft-richer-oauth-chain-00.txt

A new version of I-D, draft-hunt-oauth= -chain-01.txt
has been successfully submitted by Phil Hunt and posted to= the
IETF repository.

Filename: =C2=A0draft-hunt-oauth-chain
Revision: = =C2=A001
Title:= = =C2=A0Chain Grant Type for OAuth2
Creation date: =C2=A02012-11-28
WG ID: =C2=A0Individual Submission
Number of pages: 10
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/internet-drafts/draft-hun= t-oauth-chain-01.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0http://datatracker.ietf.org/doc/draft-hunt-oauth-chain
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://tools.ietf.org/html/draft-= hunt-oauth-chain-01
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-oauth-c= hain-01

Abstract:
=C2=A0=C2=A0This specification defines a method by which a= n OAuth protected
=C2=A0=C2=A0service, can use a received oauth token fr= om its client, to in turn,
=C2=A0=C2=A0act as a client and access anothe= r OAuth protected service in a
=C2=A0=C2=A0'chained' profile.
_________= ______________________________________
OAuth mailing list
OAuth@ietf.org<= br> https://www.i= etf.org/mailman/listinfo/oauth
--047d7b621ef0084d4004cfb7535d-- From jricher@mitre.org Fri Nov 30 07:57:49 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC36321F85FA for ; Fri, 30 Nov 2012 07:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9y-erAKA62h for ; Fri, 30 Nov 2012 07:57:48 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4743321F841F for ; Fri, 30 Nov 2012 07:57:48 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8ADD45310769; Fri, 30 Nov 2012 10:57:47 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 74CD25310752; Fri, 30 Nov 2012 10:57:47 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 30 Nov 2012 10:57:46 -0500 Message-ID: <50B8D71E.3010908@mitre.org> Date: Fri, 30 Nov 2012 10:56:14 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eve Maler References: <20121127184401.20364.27482.idtracker@ietfa.amsl.com> <947EEF6D-12E5-4D6E-A92E-16184AE7119B@xmlgrrl.com> In-Reply-To: <947EEF6D-12E5-4D6E-A92E-16184AE7119B@xmlgrrl.com> Content-Type: multipart/alternative; boundary="------------040708060906030407090107" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 15:57:49 -0000 --------------040708060906030407090107 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi Eve, Yes, you've got the right idea. In a lot of cases that we're dealing with, the relationship between the RS and AS is set up ahead of time. So the RS knows which AS to ask, and the AS knows how to deal with the different RS's it cares about. UMA gives you a nice dynamic way to introduce the two, but I think that the introduction should be a separate step from the query, since both parts are reusable independently. Correct me if I'm wrong, but UMA also has the whole API for returning permissions associated with a token, beyond just the simple current-status message, right? Even so, I think it makes sense to decide on what the core set of info that would come back from such a token introspection would be, and what it means. Different types of tokens (Bearer, MAC, HOK) are going to have different types of metadata associated with them, probably, but there are a few core pieces (expiration, scopes) that would be common and useful. -- Justin On 11/29/2012 05:59 PM, Eve Maler wrote: > Hi Justin-- Glad to see this moving forward. This draft seems pretty > straightforward, and I imagine the UMA core spec > could > probably incorporate a reference out to this rather than continuing to > use our custom-specified method for what we'd called "token status". I > wanted to highlight a couple of things we've defined beyond what you > have here, in case they're of interest to the wider community. > > This spec defines what I'd call "shallow AS/RS communication", in that > it assumes a trust relationship and context that's set up between them > completely out of band. UMA needed "deep AS/RS communication", which > allows for them to live in separate domains, potentially run by > disparate parties. (This is akin to the separation in OpenID Connect > of IdPs and third-party claim providers, and I've heard of a number of > use cases now for the same separation in plain OAuth.) Thus, we > defined a means by which the AS and RS could be introduced -- it's > actually just an embedded OAuth flow -- so that your mention of a > "separate OAuth2 Access Token" option in Section 2.1 is dictated in > UMA to be an OAuth token, with a particular scope covering the use of > the token introspection endpoint. > > The API exposed by the AS (in UMA, an "authorization manager" or AM) > that includes usage of the token introspection endpoint is called a > "protection API", and it includes registration of information about > protected resources so that the AS can manage the issuance of tokens > that it will later be asked to introspect. > > Finally, UMA has a simple extension point, called "UMA token profile", > defined in its (JSON-encoded) AM config data that allows the content > associated with the token to be standardized. Actually it dictates > more than the content; there are protocol aspects to it too, perhaps > akin to OAuth's token profiles. > > If there's interest in sedimenting some of these pieces into the OAuth > layer, we'd certainly be interested to carve out modules (where > possible) and submit them for consideration. Note that all of these > features are present in our > http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05 submission. > > Thanks, > > Eve > > On 27 Nov 2012, at 10:46 AM, "Richer, Justin P." > wrote: > >> I took some time this morning to put together a draft of Token >> Introspection. This is largely based on how we implemented it here a >> few years ago, and I'm hoping that this and the Ping draft can help >> move the conversation about introspection forward. >> >> -- Justin >> >> Begin forwarded message: >> >>> *From: *> >>> *Subject: **New Version Notification for >>> draft-richer-oauth-introspection-00.txt* >>> *Date: *November 27, 2012 1:44:01 PM EST >>> *To: *> >>> >>> >>> A new version of I-D, draft-richer-oauth-introspection-00.txt >>> has been successfully submitted by Justin Richer and posted to the >>> IETF repository. >>> >>> Filename:draft-richer-oauth-introspection >>> Revision:00 >>> Title:OAuth Token Introspection >>> Creation date:2012-11-27 >>> WG ID:Individual Submission >>> Number of pages: 6 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>> Htmlized: http://tools.ietf.org/html/draft-richer-oauth-introspection-00 >>> >>> >>> Abstract: >>> This specification defines a method for a client or protected >>> resource to query an OAuth authorization server to determine meta- >>> information about an OAuth token. >>> >>> >>> >>> >>> >>> The IETF Secretariat >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > > --------------040708060906030407090107 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Hi Eve,

Yes, you've got the right idea. In a lot of cases that we're dealing with, the relationship between the RS and AS is set up ahead of time. So the RS knows which AS to ask, and the AS knows how to deal with the different RS's it cares about. UMA gives you a nice dynamic way to introduce the two, but I think that the introduction should be a separate step from the query, since both parts are reusable independently.

Correct me if I'm wrong, but UMA also has the whole API for returning permissions associated with a token, beyond just the simple current-status message, right? Even so, I think it makes sense to decide on what the core set of info that would come back from such a token introspection would be, and what it means. Different types of tokens (Bearer, MAC, HOK) are going to have different types of metadata associated with them, probably, but there are a few core pieces (expiration, scopes) that would be common and useful.

 -- Justin

On 11/29/2012 05:59 PM, Eve Maler wrote:
Hi Justin-- Glad to see this moving forward. This draft seems pretty straightforward, and I imagine the UMA core spec could probably incorporate a reference out to this rather than continuing to use our custom-specified method for what we'd called "token status". I wanted to highlight a couple of things we've defined beyond what you have here, in case they're of interest to the wider community.

This spec defines what I'd call "shallow AS/RS communication", in that it assumes a trust relationship and context that's set up between them completely out of band. UMA needed "deep AS/RS communication", which allows for them to live in separate domains, potentially run by disparate parties. (This is akin to the separation in OpenID Connect of IdPs and third-party claim providers, and I've heard of a number of use cases now for the same separation in plain OAuth.) Thus, we defined a means by which the AS and RS could be introduced -- it's actually just an embedded OAuth flow -- so that your mention of a "separate OAuth2 Access Token" option in Section 2.1 is dictated in UMA to be an OAuth token, with a particular scope covering the use of the token introspection endpoint.

The API exposed by the AS (in UMA, an "authorization manager" or AM) that includes usage of the token introspection endpoint is called a "protection API", and it includes registration of information about protected resources so that the AS can manage the issuance of tokens that it will later be asked to introspect.

Finally, UMA has a simple extension point, called "UMA token profile", defined in its (JSON-encoded) AM config data that allows the content associated with the token to be standardized. Actually it dictates more than the content; there are protocol aspects to it too, perhaps akin to OAuth's token profiles.

If there's interest in sedimenting some of these pieces into the OAuth layer, we'd certainly be interested to carve out modules (where possible) and submit them for consideration. Note that all of these features are present in our http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05 submission.

Thanks,

Eve

On 27 Nov 2012, at 10:46 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

I took some time this morning to put together a draft of Token Introspection. This is largely based on how we implemented it here a few years ago, and I'm hoping that this and the Ping draft can help move the conversation about introspection forward.

 -- Justin

Begin forwarded message:

Subject: New Version Notification for draft-richer-oauth-introspection-00.txt
Date: November 27, 2012 1:44:01 PM EST


A new version of I-D, draft-richer-oauth-introspection-00.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename: draft-richer-oauth-introspection
Revision: 00
Title: OAuth Token Introspection
Creation date: 2012-11-27
WG ID: Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-00.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-00


Abstract:
  This specification defines a method for a client or protected
  resource to query an OAuth authorization server to determine meta-
  information about an OAuth token.





The IETF Secretariat


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl


--------------040708060906030407090107-- From jricher@mitre.org Fri Nov 30 08:04:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4DF21F8B50 for ; Fri, 30 Nov 2012 08:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ysu7SNcQG79e for ; Fri, 30 Nov 2012 08:04:28 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BAAA821F89DA for ; Fri, 30 Nov 2012 08:04:27 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D16FB53105C2; Fri, 30 Nov 2012 11:04:26 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C295F53105CB; Fri, 30 Nov 2012 11:04:26 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 30 Nov 2012 11:04:26 -0500 Message-ID: <50B8D8AD.60508@mitre.org> Date: Fri, 30 Nov 2012 11:02:53 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ariel Barreiro References: <11CFEA79-1FB5-4854-ABA9-C05FDDC56894@oracle.com> <50B7D531.4040005@mitre.org> <50B7D74D.6090401@mitre.org> <7433A429-C2F0-43E0-ABFA-332F49DDC39B@ve7jtb.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060603020503010401080000" X-Originating-IP: [129.83.31.58] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Explanation of "Authorization Code Redirection URI Manipulation" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 16:04:30 -0000 --------------060603020503010401080000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Your attack only works if the bad client can make a request to the token endpoint with that code, which is only true if it's either a public client with no secret or the bad client has stolen the secret from the good client. In the latter case, you need to revoke and re-register your 'good' client at the server. And the network paths are very different. One uses HTTP 302's through a browser, which is outside the control of the client. The other uses direct HTTP calls to the auth server, no browser. The latter is a much harder target to crack, especially with client credentials on the line. -- Justin On 11/30/2012 09:19 AM, Ariel Barreiro wrote: > But when we are talking of redirection URI manipulation, are we > talking of compromising the server or some place in the networking > route in which the request_uri can be changed or we are talking of a > compromise in the user browser? > > When I think of redirection URI manipulation, I would think that I > would chnge the redirect_uri, so that the authorization code is sent > somwhere else. If that's the case, then wherever the authorization > code is received, it can be used to request a token from that place > and that seems perfectly possible, always talking with unregistered > redirect_uris > > > On Fri, Nov 30, 2012 at 12:07 PM, John Bradley > wrote: > > The client in the is case is a server. The front channel involves > making indirect connection through the user agent. > > The back channel is a direct TLS protected server to server > communication without the users browser in the path. > > John B. > > On 2012-11-29, at 7:01 PM, Ariel Barreiro > wrote: > >> Aha, maybe that's the bit that I didn't understand that good >> then... front channel and back channel, although I can see >> difference I am not quite sure of how is it different on the >> implementation >> >> Client request to the auth end point is through a browser... >> fine, you send the redirect uri. After authenticating you get >> back to the redirect_uri with the auth code. >> >> Isn't it the client, again, with the auth code, the one that >> initiates the request to the token end point? I see no different >> channel on the requests. >> >> >> On Thu, Nov 29, 2012 at 7:44 PM, Justin Richer > > wrote: >> >> The request to the auth endpoint is front channel, through a >> browser. The request to the token endpoint is back channel, >> server-to-server. These are very, very different attack >> surfaces. If an attacker has access to and control of both >> channels, you're pretty hosed anyway and OAuth (nor TLS, nor >> basically anything else I can think of) will help you. >> >> The security model in OAuth comes from limiting the knowledge >> at each part of the transaction and spreading the risk >> appropriately. >> >> -- Justin >> >> >> On 11/29/2012 04:43 PM, Ariel Barreiro wrote: >>> But so the protection of sending the SAME redirect_uri in >>> both the auth end point and token end point makes not much >>> of a sense when there is a registered URI, and if there's >>> not, an attacker, as far as I understood, can compromise >>> both the request to the auth end point as well as the token >>> end point, so I would assume that it doesn't make much sense >>> either. >>> >>> >>> On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer >>> > wrote: >>> >>> So here's the breakdown of how the redirect uri works: >>> >>> >>> >>> - If the client sends a redirect URI to the auth >>> endpoint, and the client has registered one or more >>> redirect URIs, it MUST match one of the redirect URIs it >>> had registered. (for a soft definition of "match" -- it >>> can be prefix, or pattern, or exact string, so long as >>> the AS knows how to do it, IIRC) >>> - If the client does not send a redirect URI to the auth >>> endpoint, and the client has either only registered one >>> or the AS has some notion of a "default" redirect URI, >>> the AS will just use that one. >>> >>> Now the part that seems to trip people up: >>> >>> - If the client had sent a redirect URI to the auth >>> endpoint, then it MUST send the EXACT SAME redirect URI >>> to the token endpoint. This request is back-channel and >>> protected with the client's credentials. >>> - If the client did not send a redirect URI to the auth >>> endpoint, then it does NOT send a redirect URI to the >>> token endpoint. >>> >>> >>> So here's where the protection comes in. If the attacker >>> modifies the request to the auth endpoint so that it has >>> a different redirect URI, then that redirect URI MUST >>> match one that's attached to the client_id in the >>> request. Furthermore, the call to the token endpoint to >>> get the token MUST also contain that modified redirect >>> URI as well as any client credentials needed to make the >>> call. A "good" client will send a "good" redirect URI, >>> even if the code has been sent someplace else in the >>> mean time. >>> >>> Hope this clears things up, >>> >>> -- Justin >>> >>> >>> On 11/29/2012 04:24 PM, Ariel Barreiro wrote: >>>> But isn't having a registered redirect URI on the >>>> authorization end point enought to prevent this, why is >>>> it required to send the redirect URI to the token end >>>> point if the previous method prevents it? >>>> >>>> I appreciate a lot your response but I am still finding >>>> it hard to picture it, and, was in your explanation a >>>> modification to the request URI? >>>> >>>> >>>> On Thu, Nov 29, 2012 at 6:25 PM, John Bradley >>>> > wrote: >>>> >>>> A confidential client authenticates to the token >>>> endpoint preventing an attacker from getting the >>>> token. >>>> >>>> In the case of a public client if you get the code >>>> and redirect URI then you can get the token. (Why >>>> confidential clients are better than public ones) >>>> >>>> Sending the redirect URI to the token endpoint >>>> protects the client from the case where client A >>>> gets a code for user B because the user logged into >>>> A and A is using the client ID of client Z because >>>> it wants to impersonate user B at client A. Client >>>> A pretending to be client Z can easily get the >>>> code. However the redirect URI that the real >>>> client Z sends will be different than the one the >>>> fake client Z used to get code and the real client >>>> A won't be able to exchange the code for a access >>>> token and be tricked into thinking that the >>>> resource owner is the one presenting it the code. >>>> >>>> That is the long explanation. The short one is >>>> unregistered redirect URI are bad. Sending the >>>> redirect URI to the token endpoint protects clients >>>> from becoming confused about the presenter of the code. >>>> Nothing is going to help a public client if someone >>>> intercepts code. >>>> >>>> John B. >>>> >>>> On 2012-11-29, at 3:05 PM, Ariel Barreiro >>>> > wrote: >>>> >>>>> Still I can't see how to prevent the attack. I >>>>> understand that there is no redirection when >>>>> requesting an access token, however, the protocol >>>>> requests the client to send the redirect_uri to >>>>> the token end point to validate it was the same >>>>> used in the authorization. If the authorization >>>>> was compromised, couldn't the access token request >>>>> be forged as well? >>>>> >>>>> >>>>> On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt >>>>> >>>> > wrote: >>>>> >>>>> There is no redirection when requesting an >>>>> access token. Token requests are typically >>>>> out-of-band from the user. The attack only >>>>> happens during an authorization redirect flow >>>>> in the browser. >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote: >>>>> >>>>> > I am struggling a bit to understand this >>>>> attack and the advice in to how to prevent. I >>>>> understand that if I, as an attacker, can >>>>> change the redirection uri when authorizing, >>>>> can not it as well change the redirect uri >>>>> when requesting an access token? >>>>> > >>>>> > Any explanation examples on how this attack >>>>> might work and how sending the redirect_uri >>>>> when requesting the access toekn prevents it >>>>> are welcomed. >>>>> > >>>>> > Thanks, >>>>> > Ariel.= >>>>> > _______________________________________________ >>>>> > 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 >>> >>> >> >> > > --------------060603020503010401080000 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Your attack only works if the bad client can make a request to the token endpoint with that code, which is only true if it's either a public client with no secret or the bad client has stolen the secret from the good client. In the latter case, you need to revoke and re-register your 'good' client at the server.

And the network paths are very different. One uses HTTP 302's through a browser, which is outside the control of the client. The other uses direct HTTP calls to the auth server, no browser. The latter is a much harder target to crack, especially with client credentials on the line.

 -- Justin

On 11/30/2012 09:19 AM, Ariel Barreiro wrote:
But when we are talking of redirection URI manipulation, are we talking of compromising the server or some place in the networking route in which the request_uri can be changed or we are talking of a compromise in the user browser?

When I think of redirection URI manipulation, I would think that I would chnge the redirect_uri, so that the authorization code is sent somwhere else. If that's the case, then wherever the authorization code is received, it can be used to request a token from that place and that seems perfectly possible, always talking with unregistered redirect_uris


On Fri, Nov 30, 2012 at 12:07 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
The client in the is case is a server.  The front channel involves making indirect connection through the user agent.

The back channel is a direct TLS protected server to server communication without the users browser in the path.

John B.

On 2012-11-29, at 7:01 PM, Ariel Barreiro <abarrei@gmail.com> wrote:

Aha, maybe that's the bit that I didn't understand that good then... front channel and back channel, although I can see difference I am not quite sure of how is it different on the implementation

Client request to the auth end point is through a browser... fine, you send the redirect uri. After authenticating you get back to the redirect_uri with the auth code.

Isn't it the client, again, with the auth code, the one that initiates the request to the token end point? I see no different channel on the requests.


On Thu, Nov 29, 2012 at 7:44 PM, Justin Richer <jricher@mitre.org> wrote:
The request to the auth endpoint is front channel, through a browser. The request to the token endpoint is back channel, server-to-server. These are very, very different attack surfaces. If an attacker has access to and control of both channels, you're pretty hosed anyway and OAuth (nor TLS, nor basically anything else I can think of) will help you.

The security model in OAuth comes from limiting the knowledge at each part of the transaction and spreading the risk appropriately.

 -- Justin


On 11/29/2012 04:43 PM, Ariel Barreiro wrote:
But so the protection of sending the SAME redirect_uri in both the auth end point and token end point makes not much of a sense when there is a registered URI, and if there's not, an attacker, as far as I understood, can compromise both the request to the auth end point as well as the token end point, so I would assume that it doesn't make much sense either.


On Thu, Nov 29, 2012 at 7:35 PM, Justin Richer <jricher@mitre.org> wrote:
So here's the breakdown of how the redirect uri works:



- If the client sends a redirect URI to the auth endpoint, and the client has registered one or more redirect URIs, it MUST match one of the redirect URIs it had registered. (for a soft definition of "match" -- it can be prefix, or pattern, or exact string, so long as the AS knows how to do it, IIRC)
- If the client does not send a redirect URI to the auth endpoint, and the client has either only registered one or the AS has some notion of a "default" redirect URI, the AS will just use that one.

Now the part that seems to trip people up:

- If the client had sent a redirect URI to the auth endpoint, then it MUST send the EXACT SAME redirect URI to the token endpoint. This request is back-channel and protected with the client's credentials.
- If the client did not send a redirect URI to the auth endpoint, then it does NOT send a redirect URI to the token endpoint.


So here's where the protection comes in. If the attacker modifies the request to the auth endpoint so that it has a different redirect URI, then that redirect URI MUST match one that's attached to the client_id in the request. Furthermore, the call to the token endpoint to get the token MUST also contain that modified redirect URI as well as any client credentials needed to make the call. A "good" client will send a "good" redirect URI, even if the code has been sent someplace else in the mean time.

Hope this clears things up,

 -- Justin


On 11/29/2012 04:24 PM, Ariel Barreiro wrote:
But isn't having a registered redirect URI on the authorization end point enought to prevent this, why is it required to send the redirect URI to the token end point if the previous method prevents it?

I appreciate a lot your response but I am still finding it hard to picture it, and, was in your explanation a modification to the request URI?


On Thu, Nov 29, 2012 at 6:25 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
A confidential client authenticates to the token endpoint preventing an attacker from getting the token.

In the case of a public client if you get the code and redirect URI then you can get the token.  (Why confidential clients are better than public ones)

Sending the redirect URI to the token endpoint protects the client from the case where client A gets a code for user B because the user logged into A and A is using the client ID of client Z because it wants to impersonate user B at client A.   Client A pretending to be client Z  can easily get the code.  However the redirect URI that the real client Z sends will be different than the one the fake client Z used to get code and the real client A won't be able to exchange the code for a access token and be tricked into thinking that the resource owner is the one presenting it the code.

That is the long explanation.  The short one is unregistered redirect URI are bad.   Sending the redirect URI to the token endpoint protects clients from becoming confused about the presenter of the code.
Nothing is going to help a public client if someone intercepts code.

John B.

On 2012-11-29, at 3:05 PM, Ariel Barreiro <abarrei@gmail.com> wrote:

Still  I can't see how to prevent the attack. I understand that there is no redirection when requesting an access token, however, the protocol requests the client to send the redirect_uri to the token end point to validate it was the same used in the authorization. If the authorization was compromised, couldn't the access token request be forged as well?


On Thu, Nov 29, 2012 at 4:01 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
There is no redirection when requesting an access token.  Token requests are typically out-of-band from the user.  The attack only happens during an authorization redirect flow in the browser.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-11-29, at 9:53 AM, Ariel Barreiro wrote:

> I am struggling a bit to understand this attack and the advice in to how to prevent. I understand that if I, as an attacker, can change the redirection uri when authorizing, can not it as well change the redirect uri when requesting an access token?
>
> Any explanation examples on how this attack might work and how sending the redirect_uri when requesting the access toekn prevents it are welcomed.
>
> Thanks,
> Ariel.=
> _______________________________________________
> 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







--------------060603020503010401080000-- From phil.hunt@oracle.com Fri Nov 30 08:37:07 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B4321F8B4F for ; Fri, 30 Nov 2012 08:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.668 X-Spam-Level: X-Spam-Status: No, score=-5.668 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmpaj7PgNrYY for ; Fri, 30 Nov 2012 08:37:07 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0F36021F8A43 for ; Fri, 30 Nov 2012 08:37:03 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAUGb14j013339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Nov 2012 16:37:01 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAUGaxBJ027906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2012 16:36:59 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAUGax4d009445; Fri, 30 Nov 2012 10:36:59 -0600 Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Nov 2012 08:36:58 -0800 References: <1AA88EE7AC2F2644989D65F506C031AE5A3887EE2B@QEO40072.de.t-online.corp> <50B88AE5.3070809@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <50B88AE5.3070809@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A523) From: Phil Hunt Date: Fri, 30 Nov 2012 08:36:57 -0800 To: Sergey Beryozkin X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] review: draft-richer-oauth-chain-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 16:37:07 -0000 Two things. 1. I think access_token would be a bit confusing in some contexts even thoug= h thats what it is. However it is likely a foreign access token. "chain" is a= lso shorter.=20 2. Regarding refresh, any idea on the use case? My impression is that if any= thing lifetime should be shorter than the current access token. All cases i h= ave been looking at tend to be closer to single use --> which has led o feed= back that a single leg solution would be better for same domain cases.=20 Phil Sent from my phone. On 2012-11-30, at 2:31, Sergey Beryozkin wrote: > On 30/11/12 10:25, Ebling, Sebastian wrote: >> Hi Phil, >>=20 >> Some comments on draft-richer-oauth-chain-00.txt: >>=20 >> Section 3.1. >> - I dislike the name of the grant type. "redelegate" is the use case but n= ot the grant presented to the AS from RS1. I suggest to use "access_token" a= ccording to other grant types like authorization_code, password, refresh_tok= en. > Interesting. What about adding one more optional parameter to "refresh_gra= nt" ? >=20 > thanks, Sergey >=20 >> Section 3.2 >> "As this access token is bound to an existing access token, the authoriza= tion server MUST NOT issue a refresh token." >> =46rom our operating experience [1] it may be useful to issue a refresh t= oken in some cases. >>=20 >> Example: >> RS1 may be a batch processing system that must be able to access RS2 some= hours later to fulfill the originary request from the Client. The access to= kens (AS to C and AS to RS1) may have expired when the job starts from the q= ueue. Issuing a refresh token enables RS1 to obtain a fresh access token (AS= to RS1). >> AS may limit the duration of the refresh token for such clients (RS1). >>=20 >> Regards >>=20 >> Sebastian >>=20 >> [1] I'm a colleague of Torsten Lodderstedt at Deutsche Telekom, responsib= le for the system life cycle of our Secure Token Service. We have already im= plemented a very similar custom grant type for service chaining at Deutsche T= elekom. >> _______________________________________________ >> 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 From jricher@mitre.org Fri Nov 30 11:50:26 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A312D21F8E54 for ; Fri, 30 Nov 2012 11:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[AWL=-0.926, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCnwnQ8Ewn-5 for ; Fri, 30 Nov 2012 11:50:24 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9745621F8D23 for ; Fri, 30 Nov 2012 11:50:23 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CA8491F0CFE; Fri, 30 Nov 2012 14:50:20 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B2CCB1F0CFB; Fri, 30 Nov 2012 14:50:20 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 30 Nov 2012 14:50:20 -0500 Message-ID: <50B90D9E.5070108@mitre.org> Date: Fri, 30 Nov 2012 14:48:46 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eve Maler References: <20121127184401.20364.27482.idtracker@ietfa.amsl.com> <947EEF6D-12E5-4D6E-A92E-16184AE7119B@xmlgrrl.com> <50B8D71E.3010908@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090800060203020807010002" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 19:50:26 -0000 --------------090800060203020807010002 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I think this approach makes sense and it gels with the basic concept that I'd had about the response from the introspection endpoint being extensible and, at some level, service specific. An interesting question then is do we want to have some kind of signaling from the client as to what they want or need back? In other words, make it into a full query API as opposed to a single callback. UMA starts to do this, with fields for the resource_set_id and host_id as part of the request. The pattern that I had written would have implicitly tied the "resource set id" to whatever client credentials were being used to make the request, but we already have potential use cases here (not implemented yet) of the RS wanting to provide more context to the authorization server. One of these would be passing along the user's OIDC id_token in addition to their access_token to help make auth decisions. All of that's very quickly going down the road to complexity that might crowd out the simple case, though, so my gut instinct is to avoid it in the core spec. Still, it's something to consider, especially if UMA wants to be wrapped using generic introspection, and the right level of complexity in the core could make the future much simpler. But even so, I think the simple case of "I have a token and want to know about it" needs to be supported without extra scaffolding. -- Justin On 11/30/2012 02:06 PM, Eve Maler wrote: > You're right that UMA bundles several things in the protection API > (covered by the protection scope, whose keyword is actually the > resolvable URI > "http://docs.kantarainitiative.org/uma/scopes/prot.json"). One of > those things is the use of the token status endpoint; the rest is the > whole mechanism for outsourcing protection. Maybe it makes sense for > us to define "protection" as a superset scope that includes a smaller > scope of "introspection", which would map to using the introspection > endpoint being defined in your spec. What do you think? > > The permissions that get returned as the result of UMA-style > introspection are actually part of the definition of the "bearer" UMA > token profile. Other token contents could be profiled specifically for > use with UMA, or we could perhaps also reuse OAuth token profiles. The > wrapper being defined in your spec for totally generic token metadata > seems like a good idea; the innards could be any number of things > (with their own unique metadata), such as policy yes/no decisions, the > claims gathered, etc. This topic is discussed in the latter part of > this slide deck: > http://kantarainitiative.org/confluence/download/attachments/17760302/UMA+and+XACML+2012-10-18.pdf > > Thanks! > > Eve > > On 30 Nov 2012, at 7:56 AM, Justin Richer > wrote: > >> Hi Eve, >> >> Yes, you've got the right idea. In a lot of cases that we're dealing >> with, the relationship between the RS and AS is set up ahead of time. >> So the RS knows which AS to ask, and the AS knows how to deal with >> the different RS's it cares about. UMA gives you a nice dynamic way >> to introduce the two, but I think that the introduction should be a >> separate step from the query, since both parts are reusable >> independently. >> >> Correct me if I'm wrong, but UMA also has the whole API for returning >> permissions associated with a token, beyond just the simple >> current-status message, right? Even so, I think it makes sense to >> decide on what the core set of info that would come back from such a >> token introspection would be, and what it means. Different types of >> tokens (Bearer, MAC, HOK) are going to have different types of >> metadata associated with them, probably, but there are a few core >> pieces (expiration, scopes) that would be common and useful. >> >> -- Justin >> >> On 11/29/2012 05:59 PM, Eve Maler wrote: >>> Hi Justin-- Glad to see this moving forward. This draft seems pretty >>> straightforward, and I imagine the UMA core spec >>> could >>> probably incorporate a reference out to this rather than continuing >>> to use our custom-specified method for what we'd called "token >>> status". I wanted to highlight a couple of things we've defined >>> beyond what you have here, in case they're of interest to the wider >>> community. >>> >>> This spec defines what I'd call "shallow AS/RS communication", in >>> that it assumes a trust relationship and context that's set up >>> between them completely out of band. UMA needed "deep AS/RS >>> communication", which allows for them to live in separate domains, >>> potentially run by disparate parties. (This is akin to the >>> separation in OpenID Connect of IdPs and third-party claim >>> providers, and I've heard of a number of use cases now for the same >>> separation in plain OAuth.) Thus, we defined a means by which the AS >>> and RS could be introduced -- it's actually just an embedded OAuth >>> flow -- so that your mention of a "separate OAuth2 Access Token" >>> option in Section 2.1 is dictated in UMA to be an OAuth token, with >>> a particular scope covering the use of the token introspection endpoint. >>> >>> The API exposed by the AS (in UMA, an "authorization manager" or AM) >>> that includes usage of the token introspection endpoint is called a >>> "protection API", and it includes registration of information about >>> protected resources so that the AS can manage the issuance of tokens >>> that it will later be asked to introspect. >>> >>> Finally, UMA has a simple extension point, called "UMA token >>> profile", defined in its (JSON-encoded) AM config data that allows >>> the content associated with the token to be standardized. Actually >>> it dictates more than the content; there are protocol aspects to it >>> too, perhaps akin to OAuth's token profiles. >>> >>> If there's interest in sedimenting some of these pieces into the >>> OAuth layer, we'd certainly be interested to carve out modules >>> (where possible) and submit them for consideration. Note that all of >>> these features are present in our >>> http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05 submission. >>> >>> Thanks, >>> >>> Eve >>> >>> On 27 Nov 2012, at 10:46 AM, "Richer, Justin P." >> > wrote: >>> >>>> I took some time this morning to put together a draft of Token >>>> Introspection. This is largely based on how we implemented it here >>>> a few years ago, and I'm hoping that this and the Ping draft can >>>> help move the conversation about introspection forward. >>>> >>>> -- Justin >>>> >>>> Begin forwarded message: >>>> >>>>> *From: *> >>>>> *Subject: **New Version Notification for >>>>> draft-richer-oauth-introspection-00.txt* >>>>> *Date: *November 27, 2012 1:44:01 PM EST >>>>> *To: *> >>>>> >>>>> >>>>> A new version of I-D, draft-richer-oauth-introspection-00.txt >>>>> has been successfully submitted by Justin Richer and posted to the >>>>> IETF repository. >>>>> >>>>> Filename:draft-richer-oauth-introspection >>>>> Revision:00 >>>>> Title:OAuth Token Introspection >>>>> Creation date:2012-11-27 >>>>> WG ID:Individual Submission >>>>> Number of pages: 6 >>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-00.txt >>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-richer-oauth-introspection-00 >>>>> >>>>> >>>>> Abstract: >>>>> This specification defines a method for a client or protected >>>>> resource to query an OAuth authorization server to determine meta- >>>>> information about an OAuth token. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> Eve Maler http://www.xmlgrrl.com/blog >>> +1 425 345 6756 http://www.twitter.com/xmlgrrl >>> >>> >> > > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > > --------------090800060203020807010002 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
I think this approach makes sense and it gels with the basic concept that I'd had about the response from the introspection endpoint being extensible and, at some level, service specific. An interesting question then is do we want to have some kind of signaling from the client as to what they want or need back? In other words, make it into a full query API as opposed to a single callback. UMA starts to do this, with fields for the resource_set_id and host_id as part of the request. The pattern that I had written would have implicitly tied the "resource set id" to whatever client credentials were being used to make the request, but we already have potential use cases here (not implemented yet) of the RS wanting to provide more context to the authorization server. One of these would be passing along the user's OIDC id_token in addition to their access_token to help make auth decisions.

All of that's very quickly going down the road to complexity that might crowd out the simple case, though, so my gut instinct is to avoid it in the core spec. Still, it's something to consider, especially if UMA wants to be wrapped using generic introspection, and the right level of complexity in the core could make the future much simpler.

But even so, I think the simple case of "I have a token and want to know about it" needs to be supported without extra scaffolding.

 -- Justin



On 11/30/2012 02:06 PM, Eve Maler wrote:
You're right that UMA bundles several things in the protection API (covered by the protection scope, whose keyword is actually the resolvable URI "http://docs.kantarainitiative.org/uma/scopes/prot.json"). One of those things is the use of the token status endpoint; the rest is the whole mechanism for outsourcing protection.  Maybe it makes sense for us to define "protection" as a superset scope that includes a smaller scope of "introspection", which would map to using the introspection endpoint being defined in your spec.  What do you think?

The permissions that get returned as the result of UMA-style introspection are actually part of the definition of the "bearer" UMA token profile. Other token contents could be profiled specifically for use with UMA, or we could perhaps also reuse OAuth token profiles. The wrapper being defined in your spec for totally generic token metadata seems like a good idea; the innards could be any number of things (with their own unique metadata), such as policy yes/no decisions, the claims gathered, etc. This topic is discussed in the latter part of this slide deck: http://kantarainitiative.org/confluence/download/attachments/17760302/UMA+and+XACML+2012-10-18.pdf

Thanks!

Eve

On 30 Nov 2012, at 7:56 AM, Justin Richer <jricher@mitre.org> wrote:

Hi Eve,

Yes, you've got the right idea. In a lot of cases that we're dealing with, the relationship between the RS and AS is set up ahead of time. So the RS knows which AS to ask, and the AS knows how to deal with the different RS's it cares about. UMA gives you a nice dynamic way to introduce the two, but I think that the introduction should be a separate step from the query, since both parts are reusable independently.

Correct me if I'm wrong, but UMA also has the whole API for returning permissions associated with a token, beyond just the simple current-status message, right? Even so, I think it makes sense to decide on what the core set of info that would come back from such a token introspection would be, and what it means. Different types of tokens (Bearer, MAC, HOK) are going to have different types of metadata associated with them, probably, but there are a few core pieces (expiration, scopes) that would be common and useful.

 -- Justin

On 11/29/2012 05:59 PM, Eve Maler wrote:
Hi Justin-- Glad to see this moving forward. This draft seems pretty straightforward, and I imagine the UMA core spec could probably incorporate a reference out to this rather than continuing to use our custom-specified method for what we'd called "token status". I wanted to highlight a couple of things we've defined beyond what you have here, in case they're of interest to the wider community.

This spec defines what I'd call "shallow AS/RS communication", in that it assumes a trust relationship and context that's set up between them completely out of band. UMA needed "deep AS/RS communication", which allows for them to live in separate domains, potentially run by disparate parties. (This is akin to the separation in OpenID Connect of IdPs and third-party claim providers, and I've heard of a number of use cases now for the same separation in plain OAuth.) Thus, we defined a means by which the AS and RS could be introduced -- it's actually just an embedded OAuth flow -- so that your mention of a "separate OAuth2 Access Token" option in Section 2.1 is dictated in UMA to be an OAuth token, with a particular scope covering the use of the token introspection endpoint.

The API exposed by the AS (in UMA, an "authorization manager" or AM) that includes usage of the token introspection endpoint is called a "protection API", and it includes registration of information about protected resources so that the AS can manage the issuance of tokens that it will later be asked to introspect.

Finally, UMA has a simple extension point, called "UMA token profile", defined in its (JSON-encoded) AM config data that allows the content associated with the token to be standardized. Actually it dictates more than the content; there are protocol aspects to it too, perhaps akin to OAuth's token profiles.

If there's interest in sedimenting some of these pieces into the OAuth layer, we'd certainly be interested to carve out modules (where possible) and submit them for consideration. Note that all of these features are present in our http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05 submission.

Thanks,

Eve

On 27 Nov 2012, at 10:46 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

I took some time this morning to put together a draft of Token Introspection. This is largely based on how we implemented it here a few years ago, and I'm hoping that this and the Ping draft can help move the conversation about introspection forward.

 -- Justin

Begin forwarded message:

Subject: New Version Notification for draft-richer-oauth-introspection-00.txt
Date: November 27, 2012 1:44:01 PM EST


A new version of I-D, draft-richer-oauth-introspection-00.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename: draft-richer-oauth-introspection
Revision: 00
Title: OAuth Token Introspection
Creation date: 2012-11-27
WG ID: Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-00.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-00


Abstract:
  This specification defines a method for a client or protected
  resource to query an OAuth authorization server to determine meta-
  information about an OAuth token.





The IETF Secretariat


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl




Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl


--------------090800060203020807010002-- From aanganes@mitre.org Fri Nov 30 13:28:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D38221F8AA0 for ; Fri, 30 Nov 2012 13:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Dzc1HBAtYb6 for ; Fri, 30 Nov 2012 13:28:51 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1219221F842E for ; Fri, 30 Nov 2012 13:28:50 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6AD991F0918 for ; Fri, 30 Nov 2012 16:28:50 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 49F921F0915 for ; Fri, 30 Nov 2012 16:28:50 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.141]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Fri, 30 Nov 2012 16:28:50 -0500 From: "Anganes, Amanda L" To: "oauth@ietf.org" Thread-Topic: Review of Token Revocation draft Thread-Index: AQHNz0GvNA1BGrsfwk6N9uhhSC2F+w== Date: Fri, 30 Nov 2012 21:28:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [172.31.44.82] Content-Type: multipart/alternative; boundary="_000_B61A05DAABADEA4EA2F19424825286FA1E649700IMCMBX04MITREOR_" MIME-Version: 1.0 Subject: [OAUTH-WG] Review of Token Revocation draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 21:28:53 -0000 --_000_B61A05DAABADEA4EA2F19424825286FA1E649700IMCMBX04MITREOR_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Here is my review of the Toke Revocation draft (http://datatracker.ietf.org= /doc/draft-ietf-oauth-revocation/): Section 1. Introduction First paragraph has the following definition in it: "A token is the externa= l representation of an access grant issued by a resource owner to a particu= lar client." This seems a bit odd to me. The OAuth2 spec [1] defines "acces= s token" as "An access token is a string representing an authorization issu= ed to the client." (section 1.4) and "refresh token" as "credentials used t= o obtain access tokens (section 1.5). Should this spec borrow similar langu= age to be more consistent? Paragraph 2 "From an end-user's perception" should be "From an end-user's p= erspective". Section 2. Token Revocation What is the reason for requiring the service provider to detect the token t= ype automatically? For our implementation, Access Tokens, Refresh Tokens, a= nd ID Tokens are all structured tokens (with unique structures across the t= hree types), and as such are stored in 3 separate database tables. In order= to "detect" the token type, we would need to run a get-by-value query acro= ss all three tables, check if any of those queries returned anything, and t= hen proceed to revoke the token (if one was found). This does not seem idea= l to me. The spec says that "The authorization server first validates the client cre= dentials (in case of a confidential client) and verifies whether the client= is authorized to revoke the particular token." What does this verification= entail? Does it just mean that 1) the client credentials must validate and= 2) the token must belong to the client requesting the revocation? If so I = think the text should be clarified to reflect that. Or are you thinking of = a case where a client might not be allowed to revoke its own tokens, via so= me kind of scoping? 2.1 Cross Origin Support Formatting looks a little off here, otherwise this section looks fine. 5. Security Considerations Paragraph 3 (Malicious clients=85): "Appropriate countermeasures, which sho= uld be in place for the token endpoint as well, MUST be applied to the revo= cation endpoint." These countermeasures should be referenced to the proper = section(s) of the OAuth core spec or Threat Model document. Paragraph 4 reads a bit oddly. Suggest following rewording: "A malicious client may attempt to guess valid tokens on this endpoint by m= aking revocation requests against potential token strings. According to thi= s specification, a client's request must contain a valid client_id, in the = case of a public client, or valid client credentials, in the case of a conf= idential client. The token being revoked must also belong to the requesting= client. If an attacker is able to successfully guess a public client's cli= ent_id and one of their tokens, or a private client's credentials and one o= f their tokens, they could do much worse damage by using the token elsewher= e than by revoking it. If they chose to revoke the token, the legitimate cl= ient will lose its authorization and will need to prompt the user again. No= further damage is done and the guessed token is now worthless." References: [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31 -- Amanda Anganes Info Sys Engineer, G061 The MITRE Corporation 781-271-3103 aanganes@mitre.org --_000_B61A05DAABADEA4EA2F19424825286FA1E649700IMCMBX04MITREOR_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Here is my review of the Toke Revocation draft (http://datatracker.ietf.org/d= oc/draft-ietf-oauth-revocation/):

Section 1. Introduction
First par= agraph has the following definition in it: "A token is the external re= presentation of an access grant issued by a resource owner to a particular client." This seems a bit odd to me. The OAuth2 spec [1] defines &qu= ot;access token" as "An access token is a string representing an authorization issued to= the client." (section 1.4) and "refresh token" as "credentials used to obtain access token= s (section 1.5). Should this spec borrow similar language to be more consis= tent?

Paragraph 2 "From an end-user's perception" should be &q= uot;From an end-user's perspective".

Section 2. Token Revocation
What is the reason for requiring the service provider to detect th= e token type automatically? For our implementation, Access Tokens, Refresh = Tokens, and ID Tokens are all structured tokens (with unique structures across the three types), and as such are st= ored in 3 separate database tables. In order to "detect" the toke= n type, we would need to run a get-by-value query across all three tables, = check if any of those queries returned anything, and then proceed to revoke the token (if one was found). This does not see= m ideal to me.

The spec= says that "The authorization server first validates the client creden= tials (in case of a confidential client) and verifies whether the client is= authorized to revoke the particular token." What does this verification entail? Does it just mean that 1) the client c= redentials must validate and 2) the token must belong to the client request= ing the revocation? If so I think the text should be clarified to reflect t= hat. Or are you thinking of a case where a client might not be allowed to revoke its own tokens, via some kin= d of scoping?

2.1 Cross Origin Support
Formatting looks a little off here, otherwise this section looks fine.

5. Security Considerations
Paragraph 3 (Malicious clients=85): "Appropriate countermeasures, whic= h should be in place for the token endpoint as well, MUST be applied to the= revocation endpoint." These countermeasures should be referenced to t= he proper section(s) of the OAuth core spec or Threat Model document. 

Paragraph 4 reads a bit oddly. Suggest following rewording:
"A mal= icious client may attempt to guess valid tokens on this endpoint by making = revocation requests against potential token strings. According to this spec= ification, a client's request must contain a valid client_id, in the case of a public client, or valid client credent= ials, in the case of a confidential client. The token being revoked must al= so belong to the requesting client. If an attacker is able to successfully = guess a public client's client_id and one of their tokens, or a private client's credentials and one of thei= r tokens, they could do much worse damage by using the token elsewhere than= by revoking it. If they chose to revoke the token, the legitimate client w= ill lose its authorization and will need to prompt the user again. No further damage is done and the guessed t= oken is now worthless." 

References:

-- 
Amanda Anganes
Info Sys Engineer, G061
The MITRE Corporation
781-271-3103
aanganes@mitre.org
--_000_B61A05DAABADEA4EA2F19424825286FA1E649700IMCMBX04MITREOR_--