From nobody Thu Jun 5 00:44:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0939A1A00E9 for ; Thu, 5 Jun 2014 00:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZrOKr8zAJKB for ; Thu, 5 Jun 2014 00:44:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8671A009E for ; Thu, 5 Jun 2014 00:44:24 -0700 (PDT) Received: from [192.168.131.136] ([80.92.116.46]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MY7dI-1XEXZY161Y-00UrUd for ; Thu, 05 Jun 2014 09:44:16 +0200 Message-ID: <53901F49.1010608@gmx.net> Date: Thu, 05 Jun 2014 09:42:01 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IkwIKbFHdPwvTpAfPWGQPAd4UwNvgevsk" X-Provags-ID: V03:K0:LKaGfKR1jwlwvT6xBtCFLCc9Zm0vCYb6v6MwbypS25e+HIVx5Y6 LB6b3hRSEfPUoi8sUIpGsC4pcYA/0uDQVC/9KKvrg73QqGDPnay8v7+bs7yeEltD5hCMghK ougTklXACupOuBTZB+2cBenXnLQUP2Fn8K1b5Bu+I0D9n+R3KbVhIH3O5SFEglT9vQBBAnU 7Fk45TfPon86hoqEvlevg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fcEg1tTA9NZn7iIpj12ceYNLyGs Subject: [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 07:44:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IkwIKbFHdPwvTpAfPWGQPAd4UwNvgevsk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Justin, Hi Mike, thanks for updating the document so quickly. I have re-read the new version and I have a few minor comments. You write: "The following client metadata fields are defined by this specification. All client metadata fields are OPTIONAL." I guess you mean "Optional to implement and optional to use.". Maybe it would be good to state that. In the terminology section you briefly introduce a number of actors and concepts. The description for the initial access token and the software statement is somewhat short. I am particularly interested to learn who issues the initial access token and the software statement? What is the purpose? What does it authorize? I still don't fully get the idea of having both tokens (the initial access token and the software assertion). Stating who issues those might clarify it. If different parties provide different statements or grant different authorization rights based on these two "tokens" then I am happy but with the current write-up I feel that there is something missin= g. Redirect URIs: The text says: "It is RECOMMENDED that clients using these flows register this parameter, and an authorization server SHOULD require registration of valid redirect URIs for all clients that use these grant types to protect against token and credential theft attacks." The security consideration section is equally weak: "For clients that use redirect-based grant types such as authorization_code and implicit, authorization servers SHOULD require clients to register their redirect_uris in full." Shouldn't the recommendation be a bit stronger particularly in light of the recently discussed covered redirect attack? What happens if the client does not provide any redirect uris? I recommend to avoid the SHOULD because it is nothing a protocol specification can fulfill. It seems to be rather a policy issue. I think there should also be a description about "full" means here as well. For example, would the AS be expected to understand something like https://*.example.com? MUST, MAY, SHOULDs: I think that the document still uses RFC 2119 language too excessively at places where it does not provide any guidance for protocol implementers. I would recommend to carefully re-read each MUST/MAY/SHOULD and judge whether it imposes any implementation specific requirements and if it doesn't to replace it with deployment recommendations instead. Also, if there is a SHOULD then it should be clear to the reader under what circumstances what action should be taken. policy_uri: In my previous review I argued that the right terminology here is privacy notice and you can even re-use the IAPP terminology. Unless the policy URI has nothing to do with privacy I would prefer this terminology change. If you disagree I would prefer to have a description about what policy means in this context. jwks: my problem with the fuzzy description is that it is not indicated how the client (or any other party) would reference the listed keys and what these would be used for. Maybe this document is not the right place to define these JWKs if the semantic cannot be defined properly. Regarding the =91software_id' definition. You write that the software_id is asserted by the client software but wouldn't it be more reasonable that some human (in an organization) asserts something rather than software. The software just acts on behalf of the human. Would it be reasonable to say that a client developer makes these assertions. Regarding Section 4.2 client registration error response: Does a response message always contain two members, namely error and error_description? I would argue that the error member must be there but the error_description is optional. Regarding the error values I am missing a value that allows the authorization server that a specific field has to be provided and is currently absent. Ciao Hannes --IkwIKbFHdPwvTpAfPWGQPAd4UwNvgevsk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTkB9JAAoJEGhJURNOOiAtPgAH/iui+GJKah43bIl5MWHP3Tzd qS//YmB7Mr9wWybZ/7onckJnb6B8GgHGGGMqtslcE61xWssvDa/pjoIEQRRKoSjs mzXsT1SjL4PIiC9f67HbXAMpS1J1TPdlOcCpwiHogVDmXYfCJE0cePZJKH70xdr+ GuhJDQXLtkTK6laCqeHY6UcLfiAdwmthKV9XKS8EirQSNO+Cy4WTyveZB1hNS8Ku aoY4G6CdAl1G3/x05Zxyuo8SVOklwsrzP5eo5zb4hwNTqppetTnqOAAgDBOhfVMB yjHItvpye9AM9oEsLQD6TTous0bqHBlVjvb463RKpRBe9Bt8Cobu2Q6quPxnjM4= =eTjo -----END PGP SIGNATURE----- --IkwIKbFHdPwvTpAfPWGQPAd4UwNvgevsk-- From nobody Thu Jun 5 00:47:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3181A00AA for ; Thu, 5 Jun 2014 00:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bV_103-uZYzX for ; Thu, 5 Jun 2014 00:47:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCDA1A009E for ; Thu, 5 Jun 2014 00:47:00 -0700 (PDT) Received: from [192.168.131.136] ([80.92.116.46]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MMjgF-1WsDP23WJT-008Zwc; Thu, 05 Jun 2014 09:46:51 +0200 Message-ID: <53901FE3.7020709@gmx.net> Date: Thu, 05 Jun 2014 09:44:35 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "oauth@ietf.org" , Phil Hunt X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eFJkIexQIbF88MK438cIEU43rUNh45hkn" X-Provags-ID: V03:K0:eyn5jcczqGtTK0zMdqNEf3QaC7t/SpMmMnc5WyMNulo08IE/7lM ETYrmkkXXhzRezrMVsrKJq/CQ+6xLUR4dITBjaq6YUL+FhWk0vAU3/B29KfhHwnDv94jLK0 RXPHWYBH/gdUBFa2BG0ypaVyKJU9Nj7B3W9dIunIElIP44+dPxxLd7qLnUIGumFQtLOjxyM 1N4eh2VGBtVxU9qz4jVMQ== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DNgRNKIpgYoKn54vn_KP9KASRy0 Subject: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 07:47:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eFJkIexQIbF88MK438cIEU43rUNh45hkn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Phil, thanks for producing this document write-up. I have a somewhat basic question regarding the document. The id token contains the following mandatory information: - sis: issuer - sub: subject - aud: audience - iat: issued at - exp: expiry - auth_time: time when the end user was authenticated An access token (when encoded as a JWT) may contain all these fields except the auth_time (since auth_time is not defined in the JWT spec). Given that your proposal actually does not define the authentication protocol to be used between the resource owner/end user and the authorisation server I am wondering whether it would be possible to just add the auth_time parameter (and maybe some of the optional parameters) to the access token. Then, you can skip the id token. How do I come up with that question? In Kerberos, for example, the above-listed information is carried within a single container (within the ticket) and so I am curious to hear why we have to send the information twice in OAuth (once in the access token, when the info is passed per value, and again via the id token). Maybe I missing something important here. Ciao Hannes --eFJkIexQIbF88MK438cIEU43rUNh45hkn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTkB/jAAoJEGhJURNOOiAtuLwH/Rkh4sT5ewlFi38jF6tuM2z+ DTw1Nxb+hg9D6VPn/C1T+rquUFE6lx6BpZc15Mi678NXcchIysOepngd8ijhJ4Jg C7KCcOdOF08nJ/JGY6s+qs8bQYU+cuN/mV9HHIZxx7mLJTlulvUZvXSTY1b6mNMY tHKP44JzDAmT9zNICgVF9nvelBBo//jsblITlP/jVHQ1Us7L8C4p3C8IUkVJJ5Gi UcPM3RCXjAw9kfbccFK+rnDGT6+uTcnG4StSkXjvbErWdHU3hHivJt4WntA/9OYX FAnIFE3OvJScKS7qUcvluPMPyyEcrLROIchDYtxVQuvnMvLEVsOW6j/G/iAvFNw= =7AaS -----END PGP SIGNATURE----- --eFJkIexQIbF88MK438cIEU43rUNh45hkn-- From nobody Thu Jun 5 08:54:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D4D1A028F for ; Thu, 5 Jun 2014 08:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLMQiB3J1wXA for ; Thu, 5 Jun 2014 08:54:16 -0700 (PDT) Received: from nm12-vm2.bullet.mail.ne1.yahoo.com (nm12-vm2.bullet.mail.ne1.yahoo.com [98.138.91.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDAD1A0246 for ; Thu, 5 Jun 2014 08:54:15 -0700 (PDT) Received: from [98.138.100.102] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jun 2014 15:54:08 -0000 Received: from [98.138.226.30] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jun 2014 15:54:08 -0000 Received: from [127.0.0.1] by smtp201.mail.ne1.yahoo.com with NNFMP; 05 Jun 2014 15:54:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401983648; bh=wTMho6eD0439H1QOR/j5HIAEn9GnuCZvWfwBsD3PuRQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=m4RT0Qixt7Ms5QcGO7aNcmhxuJmZA6AxVxkYf98onMMQ86gfGmUf2zHgUFvVTucXPs9PSWrdzvu34lPG/YSdVv3RY2Omjvepp3jtP3XdeTyVEqi9HghTE9dp94P5lm7Jxonlpaa6BSDeqFG1rgiocyyCWOzr0XR1D5aifX7ygUk= X-Yahoo-Newman-Id: 920548.22035.bm@smtp201.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: KpStLAIVM1ktOfxTFzJm224qQIABqu3TVon_3di5no4quTy ZxWaZViK2cKERDtV_dbAMiE9aAG1tF5LVjdDWDCd01A.kVyq5Uvx0NkTBZQH BKwuSvYA9Spjbe19kAaGgNeOTAeQkV46YOXZlox1M8TIWiln2OczQHrSj4tI mbNQ0zs18GUVb.MWGjVW4nDYd5Yc0OgCXCHaXOHDJPp0tX4V0XVlLMpntDUL 3XeTVl9qm1c_qR0Crf1MdPjBKXjxnQGTqB1n6j.zIr1A0WbuqcMMXxJSqCl4 iwj9jsZ7Mc2ibbSo5km8x0GhHBtZEf3OKeDJXO6x90xBVjnWCxyGho5BJjLY USDMnbSzbHcK4giYmtFd4660rPCXpwUwGsw39oMdA3Yo79qy4jJywI7y3rHh zeUytDrFSVcNLJOV1FxbtBv4RrN5EPjkB5QBprYnxhCjbqlM9g8.6IHkFeW4 TL1_XDEihb3ujgk870bdYPCpIBFXQraArIsLU7MkbKEJiWNiJ6i9l1SS.8nQ NWObPniYEkG46IAICTRgq6VEb1A-- X-Yahoo-SMTP: 5ZG1WouswBA_I3TiUVQ.pojpE5jY8w-- X-Rocket-Received: from [192.168.1.125] (phil.hunt@24.86.29.34 with xymcookie [66.196.81.168]) by smtp201.mail.ne1.yahoo.com with SMTP; 05 Jun 2014 08:54:08 -0700 PDT References: <53901FE3.7020709@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: <53901FE3.7020709@gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> X-Mailer: iPhone Mail (11D167) From: Phil Hunt Date: Thu, 5 Jun 2014 08:54:08 -0700 To: Hannes Tschofenig Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LyNfh9YaJ7FwT5jr8HAdUnmDFWk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:54:17 -0000 You are correct. Just adding to access token would make a lot of devs happy a= nd that certainly should be discussed.=20 Two requirements issues: 1. A key use case is passing auth ctx only. An access token means asking for= consent to access something. This causes many sites to loose new users. Aut= hen only can be implicit consent.=20 2. Compatibility with OpenId ID Token and flows.=20 3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site w= ould like to obtain a higher level of assurance for a higher risk action.=20= The non-tech requirement is the soln must be received by client and service p= rovider developers as easy to implement in addition to 6749 or even OAuth 1.= 1a. I mention it because devs feel this should be trivial. Your suggestion o= f adding to access token certainly fits this.=20 Phil > On Jun 5, 2014, at 0:44, Hannes Tschofenig wro= te: >=20 > Hi Phil, >=20 > thanks for producing this document write-up. I have a somewhat basic > question regarding the document. >=20 > The id token contains the following mandatory information: > - sis: issuer > - sub: subject > - aud: audience > - iat: issued at > - exp: expiry > - auth_time: time when the end user was authenticated >=20 > An access token (when encoded as a JWT) may contain all these fields > except the auth_time (since auth_time is not defined in the JWT spec). >=20 > Given that your proposal actually does not define the authentication > protocol to be used between the resource owner/end user and the > authorisation server I am wondering whether it would be possible to just > add the auth_time parameter (and maybe some of the optional parameters) > to the access token. Then, you can skip the id token. >=20 > How do I come up with that question? In Kerberos, for example, the > above-listed information is carried within a single container (within > the ticket) and so I am curious to hear why we have to send the > information twice in OAuth (once in the access token, when the info is > passed per value, and again via the id token). >=20 > Maybe I missing something important here. >=20 > Ciao > Hannes >=20 >=20 From nobody Thu Jun 5 09:29:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D664B1A023E for ; Thu, 5 Jun 2014 09:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eHO33fIoss1 for ; Thu, 5 Jun 2014 09:29:44 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CECA1A0220 for ; Thu, 5 Jun 2014 09:29:44 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s55GTXmd031558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jun 2014 16:29:34 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s55GTWRB014826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2014 16:29:33 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s55GTW8P021534; Thu, 5 Jun 2014 16:29:32 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 05 Jun 2014 09:29:32 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: <53901F49.1010608@gmx.net> Date: Thu, 5 Jun 2014 09:29:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53901F49.1010608@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lxVx5g42RPgpqcFagxOs4qTmLDI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 16:29:53 -0000 Hannes, I=92ll clarify the software statement and let Mike/Justin respond for = the rest. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 5, 2014, at 12:42 AM, Hannes Tschofenig = wrote: > Hi Justin, Hi Mike, >=20 > thanks for updating the document so quickly. >=20 > I have re-read the new version and I have a few minor comments. >=20 > You write: "The following client metadata fields are defined by this > specification. All client metadata fields are OPTIONAL." >=20 > I guess you mean "Optional to implement and optional to use.". Maybe = it > would be good to state that. >=20 > In the terminology section you briefly introduce a number of actors = and > concepts. The description for the initial access token and the = software > statement is somewhat short. >=20 > I am particularly interested to learn who issues the initial access > token and the software statement? What is the purpose? What does it > authorize? These tokens have very different characteristics. The Software Statement = is not a security token. It is a statement that locks the registration = profile for client software and provides AS endpoints with a way to = recognize client software since they do not have a client_id yet. In = practical terms, AS endpoints can set policy to automatically approve = reject based on specific statement, or content rules (software_id, = version etc) or even approve based on the signer of the statements (e.g. = allow registration for any client software statement signed by Cisco). =20= Typically, the statement would be generated once (for all copies = distributed) by the developer, publisher, or a collective organization. = This is particularly useful when the publisher of an API is not the = same organization as the deployers of the actual API endpoints following = a common open API specification. For example, OpenID Connect would be = one such example. =20 In the early OAuth1 and 2 days, most use cases had the API publisher and = the deployer as the same organization. A client_id could be issued in = advance and could be used as both credential id and software identifier. = In the evolving world, we have lots of cases (e.g. OpenID Connect) = where the organization that defines the API specification is not the = same as the one operating implementations of the API specification. = Client_id can=92t serve both purposes. Software statement fills the gap = allowing client software to use a client statement =93claim=94 that can = be =93exchange=94 for a deployment assigned client_id. Initial access token is a security token that allows the client to = register in a closed/restricted registration endpoint where anonymous = registration may not be allowed. Useful in some environments where an = IT organization might re-package a client for distribution on an = internal or private system.=20 Where the software statement is issued by either the developer or the = API specification organization, the initial access token is typically = issued by the =93domain=94 (or an organization affiliated with it) where = the client intends to register. =97> have I got that correctly justin? >=20 > I still don't fully get the idea of having both tokens (the initial > access token and the software assertion). Stating who issues those = might > clarify it. If different parties provide different statements or grant > different authorization rights based on these two "tokens" then I am > happy but with the current write-up I feel that there is something = missing. >=20 > Redirect URIs: The text says: > "It is RECOMMENDED that clients using these flows register this > parameter, and an authorization server SHOULD require registration of > valid redirect URIs for all clients that use these grant types to > protect against token and credential theft attacks." >=20 > The security consideration section is equally weak: > "For clients that use redirect-based grant types such as > authorization_code and implicit, authorization servers SHOULD require > clients to register their redirect_uris in full." >=20 > Shouldn't the recommendation be a bit stronger particularly in light = of > the recently discussed covered redirect attack? >=20 > What happens if the client does not provide any redirect uris? I > recommend to avoid the SHOULD because it is nothing a protocol > specification can fulfill. It seems to be rather a policy issue. I = think > there should also be a description about "full" means here as well. = For > example, would the AS be expected to understand something like > https://*.example.com? >=20 > MUST, MAY, SHOULDs: I think that the document still uses RFC 2119 > language too excessively at places where it does not provide any > guidance for protocol implementers. I would recommend to carefully > re-read each MUST/MAY/SHOULD and judge whether it imposes any > implementation specific requirements and if it doesn't to replace it > with deployment recommendations instead. Also, if there is a SHOULD = then > it should be clear to the reader under what circumstances what action > should be taken. >=20 > policy_uri: In my previous review I argued that the right terminology > here is privacy notice and you can even re-use the IAPP terminology. > Unless the policy URI has nothing to do with privacy I would prefer = this > terminology change. If you disagree I would prefer to have a > description about what policy means in this context. >=20 > jwks: my problem with the fuzzy description is that it is not = indicated > how the client (or any other party) would reference the listed keys = and > what these would be used for. Maybe this document is not the right = place > to define these JWKs if the semantic cannot be defined properly. >=20 > Regarding the =91software_id' definition. You write that the = software_id > is asserted by the client software but wouldn't it be more reasonable > that some human (in an organization) asserts something rather than > software. The software just acts on behalf of the human. Would it be > reasonable to say that a client developer makes these assertions. >=20 > Regarding Section 4.2 client registration error response: Does a > response message always contain two members, namely error and > error_description? I would argue that the error member must be there = but > the error_description is optional. >=20 > Regarding the error values I am missing a value that allows the > authorization server that a specific field has to be provided and is > currently absent. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Jun 5 10:47:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE8E1A0144 for ; Thu, 5 Jun 2014 10:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TppoBI0xmYw5 for ; Thu, 5 Jun 2014 10:47:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116211A0123 for ; Thu, 5 Jun 2014 10:47:31 -0700 (PDT) Received: from BY2PR03CA037.namprd03.prod.outlook.com (10.242.234.158) by BLUPR03MB165.namprd03.prod.outlook.com (10.255.212.139) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 5 Jun 2014 17:47:24 +0000 Received: from BY2FFO11FD057.protection.gbl (2a01:111:f400:7c0c::190) by BY2PR03CA037.outlook.office365.com (2a01:111:e400:2c2c::30) with Microsoft SMTP Server (TLS) id 15.0.949.11 via Frontend Transport; Thu, 5 Jun 2014 17:47:24 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD057.mail.protection.outlook.com (10.1.15.185) with Microsoft SMTP Server (TLS) id 15.0.949.9 via Frontend Transport; Thu, 5 Jun 2014 17:47:23 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.134]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0195.002; Thu, 5 Jun 2014 17:46:43 +0000 From: Mike Jones To: Hannes Tschofenig , Phil Hunt Thread-Topic: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c Thread-Index: AQHPgJJX++40qT3NTkqX94iwQ4eIlptiq6AAgAActfA= Date: Thu, 5 Jun 2014 17:46:43 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> In-Reply-To: <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438001)(13464003)(377454003)(24454002)(51704005)(52604005)(199002)(189002)(104016001)(46102001)(33656002)(64706001)(47776003)(20776003)(83322001)(97756001)(19580405001)(97736001)(26826002)(76482001)(80022001)(92566001)(15975445006)(19580395003)(66066001)(4396001)(68736004)(69596002)(6806004)(85852003)(99396002)(54356999)(83072002)(46406003)(92726001)(79102001)(44976005)(86362001)(76176999)(50986999)(561944003)(74502001)(81542001)(2656002)(84676001)(21056001)(50466002)(31966008)(77982001)(74662001)(55846006)(86612001)(81342001)(23726002)(87936001)(81156002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB165; H:mail.microsoft.com; FPR:; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0233768B38 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/dpk1TrvTGYgE_AQbfmF3gVJGIcM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:47:35 -0000 Hannes, the Access Token and ID Token do quite different things and have di= fferent structures and properties. The Access Token is an opaque value tha= t grants access to resources. An ID Token is a non-opaque JWT security tok= en that makes claims about the authentication that occurred. You can have = one without the other or you can have both, depending upon the use case. T= hus, trying to move information between them would be problematic in severa= l regards. Also, trying to overload the Access Token to convey authentication informat= ion has been demonstrated in practice to be fraught with peril, and has res= ulted in some of the most prominent security breaches related to the misuse= of OAuth. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, June 05, 2014 8:54 AM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c You are correct. Just adding to access token would make a lot of devs happy= and that certainly should be discussed.=20 Two requirements issues: 1. A key use case is passing auth ctx only. An access token means asking fo= r consent to access something. This causes many sites to loose new users. A= uthen only can be implicit consent.=20 2. Compatibility with OpenId ID Token and flows.=20 3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site = would like to obtain a higher level of assurance for a higher risk action.= =20 The non-tech requirement is the soln must be received by client and service= provider developers as easy to implement in addition to 6749 or even OAuth= 1.1a. I mention it because devs feel this should be trivial. Your suggest= ion of adding to access token certainly fits this.=20 Phil > On Jun 5, 2014, at 0:44, Hannes Tschofenig wr= ote: >=20 > Hi Phil, >=20 > thanks for producing this document write-up. I have a somewhat basic=20 > question regarding the document. >=20 > The id token contains the following mandatory information: > - sis: issuer > - sub: subject > - aud: audience > - iat: issued at > - exp: expiry > - auth_time: time when the end user was authenticated >=20 > An access token (when encoded as a JWT) may contain all these fields=20 > except the auth_time (since auth_time is not defined in the JWT spec). >=20 > Given that your proposal actually does not define the authentication=20 > protocol to be used between the resource owner/end user and the=20 > authorisation server I am wondering whether it would be possible to=20 > just add the auth_time parameter (and maybe some of the optional=20 > parameters) to the access token. Then, you can skip the id token. >=20 > How do I come up with that question? In Kerberos, for example, the=20 > above-listed information is carried within a single container (within=20 > the ticket) and so I am curious to hear why we have to send the=20 > information twice in OAuth (once in the access token, when the info is=20 > passed per value, and again via the id token). >=20 > Maybe I missing something important here. >=20 > Ciao > Hannes >=20 >=20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Jun 5 12:19:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C861A02EF for ; Thu, 5 Jun 2014 12:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkrZ6RfqBolM for ; Thu, 5 Jun 2014 12:19:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656EE1A02CE for ; Thu, 5 Jun 2014 12:19:21 -0700 (PDT) Received: from BY2PR03CA028.namprd03.prod.outlook.com (10.242.234.149) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 5 Jun 2014 19:19:12 +0000 Received: from BY2FFO11FD002.protection.gbl (2a01:111:f400:7c0c::148) by BY2PR03CA028.outlook.office365.com (2a01:111:e400:2c2c::21) with Microsoft SMTP Server (TLS) id 15.0.954.9 via Frontend Transport; Thu, 5 Jun 2014 19:19:13 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD002.mail.protection.outlook.com (10.1.14.124) with Microsoft SMTP Server (TLS) id 15.0.959.15 via Frontend Transport; Thu, 5 Jun 2014 19:19:12 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.134]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Thu, 5 Jun 2014 19:18:33 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review Thread-Index: AQHPgJH7bLJEQtsxJkOKJ8yxtUim8Jti4txw Date: Thu, 5 Jun 2014 19:18:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD53187@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53901F49.1010608@gmx.net> In-Reply-To: <53901F49.1010608@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438001)(13464003)(52604005)(199002)(189002)(377454003)(51444003)(54356999)(46102001)(85852003)(83072002)(76176999)(86612001)(50986999)(81156002)(87936001)(86362001)(33656002)(99396002)(50466002)(26826002)(97756001)(97736001)(15975445006)(6806004)(104016001)(69596002)(20776003)(46406003)(47776003)(19580395003)(19580405001)(44976005)(83322001)(4396001)(92726001)(76482001)(55846006)(31966008)(92566001)(74502001)(74662001)(66066001)(80022001)(84676001)(79102001)(77982001)(23726002)(81542001)(81342001)(2656002)(21056001)(64706001)(68736004); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB042; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0233768B38 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zqjpbxbMeXYNiVRiUuG72VzhZJE Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:19:25 -0000 The answer to your question about the Initial Access Token and Software Sta= tement is highly parallel to the answer to your question in the other threa= d about the Access Token and ID Token. :-) The Initial Access Token and th= e Software Statement do quite different things and have different structure= s and properties. The Initial Access Token is an opaque value that grants = access to the registration resource. A Software Statement is a non-opaque = JWT security token that makes claims about the software being registered. = You can have one without the other or you can have both, depending upon the= use case. The parties that issue the two are also different. The Initial Access Toke= n is issued by and is about access to the Authorization Server. The Softwa= re Statement is issued by the author of the Client, or a party cooperating = with the author, and is about the Client. Both their authorship and subjec= t matter of the two data structures are different. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, June 05, 2014 12:42 AM To: oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review Hi Justin, Hi Mike, thanks for updating the document so quickly. I have re-read the new version and I have a few minor comments. You write: "The following client metadata fields are defined by this specif= ication. All client metadata fields are OPTIONAL." I guess you mean "Optional to implement and optional to use.". Maybe it wou= ld be good to state that. In the terminology section you briefly introduce a number of actors and con= cepts. The description for the initial access token and the software statem= ent is somewhat short. I am particularly interested to learn who issues the initial access token a= nd the software statement? What is the purpose? What does it authorize? I still don't fully get the idea of having both tokens (the initial access = token and the software assertion). Stating who issues those might clarify i= t. If different parties provide different statements or grant different aut= horization rights based on these two "tokens" then I am happy but with the = current write-up I feel that there is something missing. Redirect URIs: The text says: "It is RECOMMENDED that clients using these flows register this parameter, = and an authorization server SHOULD require registration of valid redirect U= RIs for all clients that use these grant types to protect against token and= credential theft attacks." The security consideration section is equally weak: "For clients that use redirect-based grant types such as authorization_code= and implicit, authorization servers SHOULD require clients to register the= ir redirect_uris in full." Shouldn't the recommendation be a bit stronger particularly in light of the= recently discussed covered redirect attack? What happens if the client does not provide any redirect uris? I recommend = to avoid the SHOULD because it is nothing a protocol specification can fulf= ill. It seems to be rather a policy issue. I think there should also be a d= escription about "full" means here as well. For example, would the AS be ex= pected to understand something like https://*.example.com? MUST, MAY, SHOULDs: I think that the document still uses RFC 2119 language = too excessively at places where it does not provide any guidance for protoc= ol implementers. I would recommend to carefully re-read each MUST/MAY/SHOUL= D and judge whether it imposes any implementation specific requirements and= if it doesn't to replace it with deployment recommendations instead. Also,= if there is a SHOULD then it should be clear to the reader under what circ= umstances what action should be taken. policy_uri: In my previous review I argued that the right terminology here = is privacy notice and you can even re-use the IAPP terminology. Unless the policy URI has nothing to do with privacy I would prefer this te= rminology change. If you disagree I would prefer to have a description abou= t what policy means in this context. jwks: my problem with the fuzzy description is that it is not indicated how= the client (or any other party) would reference the listed keys and what t= hese would be used for. Maybe this document is not the right place to defin= e these JWKs if the semantic cannot be defined properly. Regarding the 'software_id' definition. You write that the software_id is a= sserted by the client software but wouldn't it be more reasonable that some= human (in an organization) asserts something rather than software. The sof= tware just acts on behalf of the human. Would it be reasonable to say that = a client developer makes these assertions. Regarding Section 4.2 client registration error response: Does a response m= essage always contain two members, namely error and error_description? I wo= uld argue that the error member must be there but the error_description is = optional. Regarding the error values I am missing a value that allows the authorizati= on server that a specific field has to be provided and is currently absent. Ciao Hannes From nobody Thu Jun 5 12:20:51 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3CE1A02F9 for ; Thu, 5 Jun 2014 12:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_6Tf0eb8AGW for ; Thu, 5 Jun 2014 12:20:48 -0700 (PDT) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628671A02CE for ; Thu, 5 Jun 2014 12:20:48 -0700 (PDT) Received: from [98.139.212.150] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jun 2014 19:20:41 -0000 Received: from [98.139.212.248] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jun 2014 19:20:41 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 05 Jun 2014 19:20:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 384128.64841.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 63151 invoked by uid 60001); 5 Jun 2014 19:20:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401996041; bh=rq4wpCcb5nMzL7vCckC8qGYiywc8/PzhlXgdIeACt0E=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jnif1BC2Zij9HmHjB3/TH/COyh974g+VuvAIcXwAgaA0cr/nLmol7M3ppiXx1xlPR6PrFttFHFRw2nzh+75jXX2UkoWjwENJcSqX5dl8uxZ3DpoJ/E+oUgeRfwpjnEsF0gQQ9mNsDmVFOyblZspJEw/zL7uMmTbURxkBSCuYZUY= X-YMail-OSG: p6jU.aoVM1kGrTU7PXo3sBkOvooQXFNK3dfuUFQNzTQI1UI U.8ZPNl9pTXj24UHWE5ndp.vLZxeKbwktUJA2n1S8ZFicEgCptEeKXz2GEP1 6IFN3werjU_j9RgwJzd4dmTocsCU8WXMq1D8RcB6h4VUU44sxcfn3mjPTySH kDztv4DLeqmYXhQHhq74JDYD5HQ.1T4HwC7jTn1PlEp9cCO8woEHzrn8N77B wsEdh1se3iBu9PcXu8NMgtX7uYwnvI5l4B7uBHW17opzl3NGY3J0qMMqYpO0 QT8nOgkXwj0zL.zz06JlIWK69nmqP6S26v9KP9XdXVdaWJcNcF0BTGZmyh5C pyePhcv7pzzUbaysGbdAMrrr5sfIaZdiIGEVZZBbnEGcAwb0UdQifytdz3Ak TcMbK1iRpfdebS.as4vibXd90N.QiZWv6.L71_rVp0M56_M0fu1cim.yrWlT B1ml3wSf8nPnqLp8zeBrhAP6hxxZrWxfd5pPkRjBsxCeeyDolf0z4Zy.Us0Z kJrz4K7jCQWfzO2E519zATqz73e6shpPQc3sVKav7WNW5nzxBLPqTm._ejeT vipaCqA-- Received: from [209.131.62.113] by web142802.mail.bf1.yahoo.com via HTTP; Thu, 05 Jun 2014 12:20:41 PDT X-Rocket-MIMEInfo: 002.001, Q2FuJ3QgYWdyZWUgbW9yZSB3aXRoIHRoZSBwZXJpbCBvZiBvdmVybG9hZGluZyBhdXRoIGluZm9ybWF0aW9uIGludG8gYW4gYWNjZXNzIHRva2VuLgoKCk9uIFRodXJzZGF5LCBKdW5lIDUsIDIwMTQgMTE6MDUgQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gd3JvdGU6CiAKCgpIYW5uZXMsIHRoZSBBY2Nlc3MgVG9rZW4gYW5kIElEIFRva2VuIGRvIHF1aXRlIGRpZmZlcmVudCB0aGluZ3MgYW5kIGhhdmUgZGlmZmVyZW50IHN0cnVjdHVyZXMgYW5kIHByb3BlcnRpZXMuwqAgVGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.190.668 References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> Message-ID: <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Thu, 5 Jun 2014 12:20:41 -0700 (PDT) From: Bill Mills To: Mike Jones , Hannes Tschofenig , Phil Hunt In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-1565016056-1401996041=:13164" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/G7KxJv4jqHVvtWxj1Jx_BRoSkGc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:20:50 -0000 --1397251415-1565016056-1401996041=:13164 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Can't agree more with the peril of overloading auth information into an acc= ess token.=0A=0A=0AOn Thursday, June 5, 2014 11:05 AM, Mike Jones wrote:=0A =0A=0A=0AHannes, the Access Token and ID Tok= en do quite different things and have different structures and properties.= =A0 The Access Token is an opaque value that grants access to resources.=A0= An ID Token is a non-opaque JWT security token that makes claims about the= authentication that occurred.=A0 You can have one without the other or you= can have both, depending upon the use case.=A0 Thus, trying to move inform= ation between them would be problematic in several regards.=0A=0AAlso, tryi= ng to overload the Access Token to convey authentication information has be= en demonstrated in practice to be fraught with peril, and has resulted in s= ome of the most prominent security breaches related to the misuse of OAuth.= =0A=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike=0A=0A-----Original Me= ssage-----=0AFrom: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil = Hunt=0ASent: Thursday, June 05, 2014 8:54 AM=0ATo: Hannes Tschofenig=0ACc: = oauth@ietf.org=0ASubject: Re: [OAUTH-WG] Question regarding draft-hunt-oaut= h-v2-user-a4c=0A=0AYou are correct. Just adding to access token would make = a lot of devs happy and that certainly should be discussed. =0A=0ATwo requi= rements issues:=0A=0A1. A key use case is passing auth ctx only. An access = token means asking for consent to access something. This causes many sites = to loose new users. Authen only can be implicit consent. =0A=0A2.=A0 Compat= ibility with OpenId ID Token and flows. =0A=0A3. There is a need to support= re-auth and MFA/LOA negotiation. Eg web site would like to obtain a higher= level of assurance for a higher risk action. =0A=0AThe non-tech requiremen= t is the soln must be received by client and service provider developers as= easy to implement in addition to 6749 or even OAuth 1.1a. I mention it bec= ause devs feel this should be trivial.=A0 Your suggestion of adding to acce= ss token certainly fits this. =0A=0APhil=0A=0A> On Jun 5, 2014, at 0:44, Ha= nnes Tschofenig wrote:=0A> =0A> Hi Phil,=0A> = =0A> thanks for producing this document write-up. I have a somewhat basic = =0A> question regarding the document.=0A> =0A> The id token contains the fo= llowing mandatory information:=0A> - sis: issuer=0A> - sub: subject=0A> - a= ud: audience=0A> - iat: issued at=0A> - exp: expiry=0A> - auth_time: time w= hen the end user was authenticated=0A> =0A> An access token (when encoded a= s a JWT) may contain all these fields =0A> except the auth_time (since auth= _time is not defined in the JWT spec).=0A> =0A> Given that your proposal ac= tually does not define the authentication =0A> protocol to be used between = the resource owner/end user and the =0A> authorisation server I am wonderin= g whether it would be possible to =0A> just add the auth_time parameter (an= d maybe some of the optional =0A> parameters) to the access token. Then, yo= u can skip the id token.=0A> =0A> How do I come up with that question? In K= erberos, for example, the =0A> above-listed information is carried within a= single container (within =0A> the ticket) and so I am curious to hear why = we have to send the =0A> information twice in OAuth (once in the access tok= en, when the info is =0A> passed per value, and again via the id token).=0A= > =0A> Maybe I missing something important here.=0A> =0A> Ciao=0A> Hannes= =0A> =0A> =0A=0A_______________________________________________=0AOAuth mai= ling list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A= =0A=0A_______________________________________________=0AOAuth mailing list= =0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --1397251415-1565016056-1401996041=:13164 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Can't agree more with the peril of overloading aut= h information into an access token.


= On Thursday, June 5, 2014 11:05 AM, Mike Jones <Michael.Jones@microsoft.= com> wrote:


= Hannes, the Access Token and ID Token do quite different things and have di= fferent structures and properties.  The Access Token is an opaque valu= e that grants access to resources.  An ID Token is a non-opaque JWT security token = that makes claims about the authentication that occurred.  You can hav= e one without the other or you can have both, depending upon the use case.&= nbsp; Thus, trying to move information between them would be problematic in= several regards.

Also, trying to over= load the Access Token to convey authentication information has been demonst= rated in practice to be fraught with peril, and has resulted in some of the= most prominent security breaches related to the misuse of OAuth.

         &n= bsp;      -- Mike

= -----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes TschofenigCc: oauth@ietf.org
Subject: R= e: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

You are correct. Just adding to access token would = make a lot of devs happy and that certainly should be discussed.

Two requirements issues:
1. A key use case is passing auth ctx only. An access token= means asking for consent to access something. This causes many sites to lo= ose new users. Authen only can be implicit consent.

2.  Compatibility with OpenId ID Token and flows.

3. There is a need to support re-auth and = MFA/LOA negotiation. Eg web site would like to obtain a higher level of ass= urance for a higher risk action.

The non-tech requirement is = the soln must be received by client and service provider developers as easy= to implement in addition to 6749 or even OAuth 1.1a. I mention it because = devs feel this should be trivial.  Your suggestion of adding to access= token certainly fits this.

Phil

> On Jun 5, 2014, at 0:44, Hannes Tscho= fenig <hannes.tschofenig@gmx.net> w= rote:
>
> Hi Phil,
>
> thanks for producing this document write-= up. I have a somewhat basic
> question regarding the = document.
>
> The id token conta= ins the following mandatory information:
> - sis: issu= er
> - sub: subject
> - aud: audience
>= - iat: issued at
> - exp: expiry
&g= t; - auth_time: time when the end user was authenticated
= >
> An access token (when encoded as a JWT) may co= ntain all these fields
> except the auth_time (since = auth_time is not defined in the JWT spec).
>
> Given that your proposal actually does not define the authen= tication
> protocol to be used between the resource o= wner/end user and the
> authorisation server I am won= dering whether it would be possible to
> just add the= auth_time parameter (and maybe some of the optional
>= ; parameters) to the access token. Then, you can skip the id token.
>
> How do I come up with that question= ? In Kerberos, for example, the
> above-listed information is carried w= ithin a single container (within
> the ticket) and so= I am curious to hear why we have to send the
> infor= mation twice in OAuth (once in the access token, when the info is
> passed per value, and again via the id token).
>
> Maybe I missing something important here.=
>
> Ciao
>= Hannes
>
>
<= br clear=3D"none">_______________________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth<= /a>

<= /div>
--1397251415-1565016056-1401996041=:13164-- From nobody Thu Jun 5 12:29:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4A31A0363 for ; Thu, 5 Jun 2014 12:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bapDMP81vHHB for ; Thu, 5 Jun 2014 12:29:10 -0700 (PDT) Received: from n1plsmtpa01-01.prod.ams1.secureserver.net (n1plsmtpa01-01.prod.ams1.secureserver.net [188.121.53.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4915F1A0337 for ; Thu, 5 Jun 2014 12:29:03 -0700 (PDT) Received: from [192.168.1.3] ([79.100.244.64]) by n1plsmtpa01-01.prod.ams1.secureserver.net with id AjUm1o00F1Q5Ae701jUmve; Thu, 05 Jun 2014 12:28:53 -0700 Message-ID: <1401996525.22850.362.camel@shakespeare> From: Vladimir Dzhuvinov Cc: "oauth@ietf.org" Date: Thu, 05 Jun 2014 22:28:45 +0300 In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD53187@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53901F49.1010608@gmx.net> <4E1F6AAD24975D4BA5B16804296739439AD53187@TK5EX14MBXC294.redmond.corp.microsoft.com> Organization: Connect2id Ltd. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/rKh_sukfVHEosa6ddxA1IFjT3Ts Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:29:12 -0000 BTW, I just spotted a problem with the example response at the bottom of section 4.1, the HTTP status code should be 201 Created: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-17#section-4.1 Vladimir From nobody Thu Jun 5 12:39:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C841A0306 for ; Thu, 5 Jun 2014 12:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUWCf4tRZdN7 for ; Thu, 5 Jun 2014 12:39:44 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5D31A02CE for ; Thu, 5 Jun 2014 12:39:43 -0700 (PDT) Received: from [79.253.29.4] (helo=[192.168.71.82]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1WsdVf-0002ON-9f; Thu, 05 Jun 2014 21:39:35 +0200 References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> Content-Type: multipart/alternative; boundary=Apple-Mail-06897BDF-E673-4614-9D99-42F177C1FE95 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (11D201) From: Torsten Lodderstedt Date: Thu, 5 Jun 2014 21:39:34 +0200 To: Bill Mills X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2Tz4mVTC8Wl60UUpinfAuq34OEw Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:39:47 -0000 --Apple-Mail-06897BDF-E673-4614-9D99-42F177C1FE95 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 the access token is opaque to the client. That's great! Let's keep it that w= ay. > Am 05.06.2014 um 21:20 schrieb Bill Mills : >=20 > Can't agree more with the peril of overloading auth information into an ac= cess token. >=20 >=20 > On Thursday, June 5, 2014 11:05 AM, Mike Jones wrote: >=20 >=20 > Hannes, the Access Token and ID Token do quite different things and have d= ifferent structures and properties. The Access Token is an opaque value tha= t grants access to resources. An ID Token is a non-opaque JWT security toke= n that makes claims about the authentication that occurred. You can have on= e without the other or you can have both, depending upon the use case. Thus= , trying to move information between them would be problematic in several re= gards. >=20 > Also, trying to overload the Access Token to convey authentication informa= tion has been demonstrated in practice to be fraught with peril, and has res= ulted in some of the most prominent security breaches related to the misuse o= f OAuth. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Thursday, June 05, 2014 8:54 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c >=20 > You are correct. Just adding to access token would make a lot of devs happ= y and that certainly should be discussed.=20 >=20 > Two requirements issues: >=20 > 1. A key use case is passing auth ctx only. An access token means asking f= or consent to access something. This causes many sites to loose new users. A= uthen only can be implicit consent.=20 >=20 > 2. Compatibility with OpenId ID Token and flows.=20 >=20 > 3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site= would like to obtain a higher level of assurance for a higher risk action.=20= >=20 > The non-tech requirement is the soln must be received by client and servic= e provider developers as easy to implement in addition to 6749 or even OAuth= 1.1a. I mention it because devs feel this should be trivial. Your suggesti= on of adding to access token certainly fits this.=20 >=20 > Phil >=20 > > On Jun 5, 2014, at 0:44, Hannes Tschofenig w= rote: > >=20 > > Hi Phil, > >=20 > > thanks for producing this document write-up. I have a somewhat basic=20 > > question regarding the document. > >=20 > > The id token contains the following mandatory information: > > - sis: issuer > > - sub: subject > > - aud: audience > > - iat: issued at > > - exp: expiry > > - auth_time: time when the end user was authenticated > >=20 > > An access token (when encoded as a JWT) may contain all these fields=20 > > except the auth_time (since auth_time is not defined in the JWT spec). > >=20 > > Given that your proposal actually does not define the authentication=20 > > protocol to be used between the resource owner/end user and the=20 > > authorisation server I am wondering whether it would be possible to=20 > > just add the auth_time parameter (and maybe some of the optional=20 > > parameters) to the access token. Then, you can skip the id token. > >=20 > > How do I come up with that question? In Kerberos, for example, the=20 > > above-listed information is carried within a single container (within=20= > > the ticket) and so I am curious to hear why we have to send the=20 > > information twice in OAuth (once in the access token, when the info is=20= > > passed per value, and again via the id token). > >=20 > > Maybe I missing something important here. > >=20 > > Ciao > > Hannes > >=20 > >=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 --Apple-Mail-06897BDF-E673-4614-9D99-42F177C1FE95 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

the access= token is opaque to the client. That's great! Let's keep it that way.
<= div>
Am 05.06.2014 um 21:20 schrieb Bill Mills <wmills_92105@yahoo.com>:

Can't agree more with the peril of overloadin= g auth information into an access token.


<= div style=3D"font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial,= 'Lucida Grande', sans-serif; font-size: 12pt;">
On T= hursday, June 5, 2014 11:05 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Hannes, the Access Token and ID= Token do quite different things and have different structures and propertie= s.  The Access Token is an opaque value that grants access to resources.  An ID Token is a non-opaque JWT security token t= hat makes claims about the authentication that occurred.  You can have o= ne without the other or you can have both, depending upon the use case. = ; Thus, trying to move information between them would be problematic in seve= ral regards.

Also, trying to overload t= he Access Token to convey authentication information has been demonstrated i= n practice to be fraught with peril, and has resulted in some of the most pr= ominent security breaches related to the misuse of OAuth.
=
            &= nbsp;   -- Mike

-----Original= Message-----
From: OAuth [mailto:o= auth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [O= AUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
<= br clear=3D"none">You are correct. Just adding to access token would make a l= ot of devs happy and that certainly should be discussed.
=
Two requirements issues:

1. A key use case is passing auth ctx only. An access token means askin= g for consent to access something. This causes many sites to loose new users= . Authen only can be implicit consent.

2.  Compatibility with OpenId ID Token and flows.
<= br clear=3D"none">3. There is a need to support re-auth and MFA/LOA negotiat= ion. Eg web site would like to obtain a higher level of assurance for a high= er risk action.

The non-tech requirement is t= he soln must be received by client and service provider developers as easy t= o implement in addition to 6749 or even OAuth 1.1a. I mention it because dev= s feel this should be trivial.  Your suggestion of adding to access tok= en certainly fits this.

Phil

> On Jun 5, 2014, at 0:44, Hannes Tschofenig &l= t;hannes.tschofenig@gmx.net> wrote:
>
> Hi Phil,
> <= br clear=3D"none">> thanks for producing this document write-up. I have a= somewhat basic
> question regarding the document.
>
> The id token contains the followi= ng mandatory information:
> - sis: issuer
> - sub: subject
> - aud: audience
> -= iat: issued at
> - exp: expiry
> -= auth_time: time when the end user was authenticated
> <= br clear=3D"none">> An access token (when encoded as a JWT) may contain a= ll these fields
> except the auth_time (since auth_tim= e is not defined in the JWT spec).
>
> Given that your proposal actually does not define the authentication <= br clear=3D"none">> protocol to be used between the resource owner/end us= er and the
> authorisation server I am wondering wheth= er it would be possible to
> just add the auth_time pa= rameter (and maybe some of the optional
> parameters) t= o the access token. Then, you can skip the id token.
> <= br clear=3D"none">> How do I come up with that question? In Kerberos, for= example, the
> above-listed information is carried wi= thin a single container (within
> the ticket) and so I= am curious to hear why we have to send the
> informat= ion twice in OAuth (once in the access token, when the info is
> passed per value, and again via the id token).
= >
> Maybe I missing something important here.
>
> Ciao
> Hannes=
>
>

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


____= ___________________________________________
OAuth mailing l= ist
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-06897BDF-E673-4614-9D99-42F177C1FE95-- From nobody Thu Jun 5 12:42:32 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1267C1A035E for ; Thu, 5 Jun 2014 12:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_1F3xX9wz7c for ; Thu, 5 Jun 2014 12:42:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8CD91A0341 for ; Thu, 5 Jun 2014 12:42:20 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB312.namprd03.prod.outlook.com (10.141.48.28) with Microsoft SMTP Server (TLS) id 15.0.959.15; Thu, 5 Jun 2014 19:42:13 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0959.000; Thu, 5 Jun 2014 19:42:13 +0000 From: Anthony Nadalin To: Torsten Lodderstedt , Bill Mills Thread-Topic: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c Thread-Index: AQHPgJJXl+S5jRd6AUqb8tCOpHWSlJtiq6AAgAAfdICAABpBgIAABUcAgAAAVtA= Date: Thu, 5 Jun 2014 19:42:12 +0000 Message-ID: <482eb1c40dbb4da08dfb0d64879fac70@BLUPR03MB309.namprd03.prod.outlook.com> References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(189002)(199002)(24454002)(51704005)(52604005)(13464003)(377454003)(19609705001)(15975445006)(76176999)(15202345003)(81342001)(81542001)(54356999)(19300405004)(19625215002)(19580405001)(83322001)(19580395003)(86362001)(92566001)(77096999)(50986999)(16236675004)(561944003)(101416001)(4396001)(76482001)(74316001)(93886002)(79102001)(21056001)(99286001)(99396002)(31966008)(86612001)(74502001)(74662001)(46102001)(76576001)(87936001)(77982001)(85852003)(83072002)(33646001)(2656002)(80022001)(20776003)(64706001)(42262001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB312; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; Content-Type: multipart/alternative; boundary="_000_482eb1c40dbb4da08dfb0d64879fac70BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/RHRQdvcIhgE5qGh-KSNe1vCtnOI Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:42:29 -0000 --_000_482eb1c40dbb4da08dfb0d64879fac70BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXTigJlzIGdyZWF0IGJ1dCBzb21lIHdheXMgYnV0IGFsc28gdmVyeSBsaW1pdGluZyBpZiB5b3Ug YXJlIGNvdW50aW5nIG9uIGNlcnRhaW4gcmVxdWlyZW1lbnRzIHRvIGJlIHJlcHJlc2VudGVkIGlu IHRoZSBhY2Nlc3MgdG9rZW4NCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgVG9yc3RlbiBMb2RkZXJzdGVkdA0KU2VudDogVGh1cnNkYXks IEp1bmUgNSwgMjAxNCAxMjo0MCBQTQ0KVG86IEJpbGwgTWlsbHMNCkNjOiBQaGlsIEh1bnQ7IG9h dXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBRdWVzdGlvbiByZWdhcmRpbmcg ZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yw0KDQorMQ0KDQp0aGUgYWNjZXNzIHRva2VuIGlz IG9wYXF1ZSB0byB0aGUgY2xpZW50LiBUaGF0J3MgZ3JlYXQhIExldCdzIGtlZXAgaXQgdGhhdCB3 YXkuDQoNCkFtIDA1LjA2LjIwMTQgdW0gMjE6MjAgc2NocmllYiBCaWxsIE1pbGxzIDx3bWlsbHNf OTIxMDVAeWFob28uY29tPG1haWx0bzp3bWlsbHNfOTIxMDVAeWFob28uY29tPj46DQpDYW4ndCBh Z3JlZSBtb3JlIHdpdGggdGhlIHBlcmlsIG9mIG92ZXJsb2FkaW5nIGF1dGggaW5mb3JtYXRpb24g aW50byBhbiBhY2Nlc3MgdG9rZW4uDQoNCk9uIFRodXJzZGF5LCBKdW5lIDUsIDIwMTQgMTE6MDUg QU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoNCkhhbm5lcywgdGhlIEFjY2VzcyBUb2tl biBhbmQgSUQgVG9rZW4gZG8gcXVpdGUgZGlmZmVyZW50IHRoaW5ncyBhbmQgaGF2ZSBkaWZmZXJl bnQgc3RydWN0dXJlcyBhbmQgcHJvcGVydGllcy4gIFRoZSBBY2Nlc3MgVG9rZW4gaXMgYW4gb3Bh cXVlIHZhbHVlIHRoYXQgZ3JhbnRzIGFjY2VzcyB0byByZXNvdXJjZXMuICBBbiBJRCBUb2tlbiBp cyBhIG5vbi1vcGFxdWUgSldUIHNlY3VyaXR5IHRva2VuIHRoYXQgbWFrZXMgY2xhaW1zIGFib3V0 IHRoZSBhdXRoZW50aWNhdGlvbiB0aGF0IG9jY3VycmVkLiAgWW91IGNhbiBoYXZlIG9uZSB3aXRo b3V0IHRoZSBvdGhlciBvciB5b3UgY2FuIGhhdmUgYm90aCwgZGVwZW5kaW5nIHVwb24gdGhlIHVz ZSBjYXNlLiAgVGh1cywgdHJ5aW5nIHRvIG1vdmUgaW5mb3JtYXRpb24gYmV0d2VlbiB0aGVtIHdv dWxkIGJlIHByb2JsZW1hdGljIGluIHNldmVyYWwgcmVnYXJkcy4NCg0KQWxzbywgdHJ5aW5nIHRv IG92ZXJsb2FkIHRoZSBBY2Nlc3MgVG9rZW4gdG8gY29udmV5IGF1dGhlbnRpY2F0aW9uIGluZm9y bWF0aW9uIGhhcyBiZWVuIGRlbW9uc3RyYXRlZCBpbiBwcmFjdGljZSB0byBiZSBmcmF1Z2h0IHdp dGggcGVyaWwsIGFuZCBoYXMgcmVzdWx0ZWQgaW4gc29tZSBvZiB0aGUgbW9zdCBwcm9taW5lbnQg c2VjdXJpdHkgYnJlYWNoZXMgcmVsYXRlZCB0byB0aGUgbWlzdXNlIG9mIE9BdXRoLg0KDQogICAg ICAgICAgICAgICAgLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog T0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogVGh1cnNkYXksIEp1bmUg MDUsIDIwMTQgODo1NCBBTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzogb2F1dGhAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUXVlc3Rp b24gcmVnYXJkaW5nIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMNCg0KWW91IGFyZSBjb3Jy ZWN0LiBKdXN0IGFkZGluZyB0byBhY2Nlc3MgdG9rZW4gd291bGQgbWFrZSBhIGxvdCBvZiBkZXZz IGhhcHB5IGFuZCB0aGF0IGNlcnRhaW5seSBzaG91bGQgYmUgZGlzY3Vzc2VkLg0KDQpUd28gcmVx dWlyZW1lbnRzIGlzc3VlczoNCg0KMS4gQSBrZXkgdXNlIGNhc2UgaXMgcGFzc2luZyBhdXRoIGN0 eCBvbmx5LiBBbiBhY2Nlc3MgdG9rZW4gbWVhbnMgYXNraW5nIGZvciBjb25zZW50IHRvIGFjY2Vz cyBzb21ldGhpbmcuIFRoaXMgY2F1c2VzIG1hbnkgc2l0ZXMgdG8gbG9vc2UgbmV3IHVzZXJzLiBB dXRoZW4gb25seSBjYW4gYmUgaW1wbGljaXQgY29uc2VudC4NCg0KMi4gIENvbXBhdGliaWxpdHkg d2l0aCBPcGVuSWQgSUQgVG9rZW4gYW5kIGZsb3dzLg0KDQozLiBUaGVyZSBpcyBhIG5lZWQgdG8g c3VwcG9ydCByZS1hdXRoIGFuZCBNRkEvTE9BIG5lZ290aWF0aW9uLiBFZyB3ZWIgc2l0ZSB3b3Vs ZCBsaWtlIHRvIG9idGFpbiBhIGhpZ2hlciBsZXZlbCBvZiBhc3N1cmFuY2UgZm9yIGEgaGlnaGVy IHJpc2sgYWN0aW9uLg0KDQpUaGUgbm9uLXRlY2ggcmVxdWlyZW1lbnQgaXMgdGhlIHNvbG4gbXVz dCBiZSByZWNlaXZlZCBieSBjbGllbnQgYW5kIHNlcnZpY2UgcHJvdmlkZXIgZGV2ZWxvcGVycyBh cyBlYXN5IHRvIGltcGxlbWVudCBpbiBhZGRpdGlvbiB0byA2NzQ5IG9yIGV2ZW4gT0F1dGggMS4x YS4gSSBtZW50aW9uIGl0IGJlY2F1c2UgZGV2cyBmZWVsIHRoaXMgc2hvdWxkIGJlIHRyaXZpYWwu ICBZb3VyIHN1Z2dlc3Rpb24gb2YgYWRkaW5nIHRvIGFjY2VzcyB0b2tlbiBjZXJ0YWlubHkgZml0 cyB0aGlzLg0KDQpQaGlsDQoNCj4gT24gSnVuIDUsIDIwMTQsIGF0IDA6NDQsIEhhbm5lcyBUc2No b2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNjaG9mZW5p Z0BnbXgubmV0Pj4gd3JvdGU6DQo+DQo+IEhpIFBoaWwsDQo+DQo+IHRoYW5rcyBmb3IgcHJvZHVj aW5nIHRoaXMgZG9jdW1lbnQgd3JpdGUtdXAuIEkgaGF2ZSBhIHNvbWV3aGF0IGJhc2ljDQo+IHF1 ZXN0aW9uIHJlZ2FyZGluZyB0aGUgZG9jdW1lbnQuDQo+DQo+IFRoZSBpZCB0b2tlbiBjb250YWlu cyB0aGUgZm9sbG93aW5nIG1hbmRhdG9yeSBpbmZvcm1hdGlvbjoNCj4gLSBzaXM6IGlzc3Vlcg0K PiAtIHN1Yjogc3ViamVjdA0KPiAtIGF1ZDogYXVkaWVuY2UNCj4gLSBpYXQ6IGlzc3VlZCBhdA0K PiAtIGV4cDogZXhwaXJ5DQo+IC0gYXV0aF90aW1lOiB0aW1lIHdoZW4gdGhlIGVuZCB1c2VyIHdh cyBhdXRoZW50aWNhdGVkDQo+DQo+IEFuIGFjY2VzcyB0b2tlbiAod2hlbiBlbmNvZGVkIGFzIGEg SldUKSBtYXkgY29udGFpbiBhbGwgdGhlc2UgZmllbGRzDQo+IGV4Y2VwdCB0aGUgYXV0aF90aW1l IChzaW5jZSBhdXRoX3RpbWUgaXMgbm90IGRlZmluZWQgaW4gdGhlIEpXVCBzcGVjKS4NCj4NCj4g R2l2ZW4gdGhhdCB5b3VyIHByb3Bvc2FsIGFjdHVhbGx5IGRvZXMgbm90IGRlZmluZSB0aGUgYXV0 aGVudGljYXRpb24NCj4gcHJvdG9jb2wgdG8gYmUgdXNlZCBiZXR3ZWVuIHRoZSByZXNvdXJjZSBv d25lci9lbmQgdXNlciBhbmQgdGhlDQo+IGF1dGhvcmlzYXRpb24gc2VydmVyIEkgYW0gd29uZGVy aW5nIHdoZXRoZXIgaXQgd291bGQgYmUgcG9zc2libGUgdG8NCj4ganVzdCBhZGQgdGhlIGF1dGhf dGltZSBwYXJhbWV0ZXIgKGFuZCBtYXliZSBzb21lIG9mIHRoZSBvcHRpb25hbA0KPiBwYXJhbWV0 ZXJzKSB0byB0aGUgYWNjZXNzIHRva2VuLiBUaGVuLCB5b3UgY2FuIHNraXAgdGhlIGlkIHRva2Vu Lg0KPg0KPiBIb3cgZG8gSSBjb21lIHVwIHdpdGggdGhhdCBxdWVzdGlvbj8gSW4gS2VyYmVyb3Ms IGZvciBleGFtcGxlLCB0aGUNCj4gYWJvdmUtbGlzdGVkIGluZm9ybWF0aW9uIGlzIGNhcnJpZWQg d2l0aGluIGEgc2luZ2xlIGNvbnRhaW5lciAod2l0aGluDQo+IHRoZSB0aWNrZXQpIGFuZCBzbyBJ IGFtIGN1cmlvdXMgdG8gaGVhciB3aHkgd2UgaGF2ZSB0byBzZW5kIHRoZQ0KPiBpbmZvcm1hdGlv biB0d2ljZSBpbiBPQXV0aCAob25jZSBpbiB0aGUgYWNjZXNzIHRva2VuLCB3aGVuIHRoZSBpbmZv IGlzDQo+IHBhc3NlZCBwZXIgdmFsdWUsIGFuZCBhZ2FpbiB2aWEgdGhlIGlkIHRva2VuKS4NCj4N Cj4gTWF5YmUgSSBtaXNzaW5nIHNvbWV0aGluZyBpbXBvcnRhbnQgaGVyZS4NCj4NCj4gQ2lhbw0K PiBIYW5uZXMNCj4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_482eb1c40dbb4da08dfb0d64879fac70BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl04oCZcyBncmVh dCBidXQgc29tZSB3YXlzIGJ1dCBhbHNvIHZlcnkgbGltaXRpbmcgaWYgeW91IGFyZSBjb3VudGlu ZyBvbiBjZXJ0YWluIHJlcXVpcmVtZW50cyB0byBiZSByZXByZXNlbnRlZCBpbiB0aGUgYWNjZXNz IHRva2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFt ZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPlRvcnN0ZW4gTG9kZGVyc3RlZHQ8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bmUg NSwgMjAxNCAxMjo0MCBQTTxicj4NCjxiPlRvOjwvYj4gQmlsbCBNaWxsczxicj4NCjxiPkNjOjwv Yj4gUGhpbCBIdW50OyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBRdWVzdGlvbiByZWdhcmRpbmcgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQz OzE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ dGhlIGFjY2VzcyB0b2tlbiBpcyBvcGFxdWUgdG8gdGhlIGNsaWVudC4gVGhhdCdzIGdyZWF0ISBM ZXQncyBrZWVwIGl0IHRoYXQgd2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpBbSAw NS4wNi4yMDE0IHVtIDIxOjIwIHNjaHJpZWIgQmlsbCBNaWxscyAmbHQ7PGEgaHJlZj0ibWFpbHRv OndtaWxsc185MjEwNUB5YWhvby5jb20iPndtaWxsc185MjEwNUB5YWhvby5jb208L2E+Jmd0Ozo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5DYW4ndCBhZ3JlZSBtb3JlIHdpdGggdGhlIHBlcmlsIG9mIG92ZXJsb2FkaW5nIGF1dGgg aW5mb3JtYXRpb24gaW50byBhbiBhY2Nlc3MgdG9rZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk9uIFRodXJzZGF5LCBKdW5lIDUsIDIwMTQg MTE6MDUgQU0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2Jh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkhhbm5lcywgdGhlIEFjY2VzcyBU b2tlbiBhbmQgSUQgVG9rZW4gZG8gcXVpdGUgZGlmZmVyZW50IHRoaW5ncyBhbmQgaGF2ZSBkaWZm ZXJlbnQgc3RydWN0dXJlcyBhbmQgcHJvcGVydGllcy4mbmJzcDsgVGhlIEFjY2VzcyBUb2tlbiBp cyBhbiBvcGFxdWUgdmFsdWUgdGhhdA0KIGdyYW50cyBhY2Nlc3MgdG8gcmVzb3VyY2VzLiZuYnNw OyBBbiBJRCBUb2tlbiBpcyBhIG5vbi1vcGFxdWUgSldUIHNlY3VyaXR5IHRva2VuIHRoYXQgbWFr ZXMgY2xhaW1zIGFib3V0IHRoZSBhdXRoZW50aWNhdGlvbiB0aGF0IG9jY3VycmVkLiZuYnNwOyBZ b3UgY2FuIGhhdmUgb25lIHdpdGhvdXQgdGhlIG90aGVyIG9yIHlvdSBjYW4gaGF2ZSBib3RoLCBk ZXBlbmRpbmcgdXBvbiB0aGUgdXNlIGNhc2UuJm5ic3A7IFRodXMsIHRyeWluZyB0byBtb3ZlIGlu Zm9ybWF0aW9uIGJldHdlZW4NCiB0aGVtIHdvdWxkIGJlIHByb2JsZW1hdGljIGluIHNldmVyYWwg cmVnYXJkcy48YnI+DQo8YnI+DQpBbHNvLCB0cnlpbmcgdG8gb3ZlcmxvYWQgdGhlIEFjY2VzcyBU b2tlbiB0byBjb252ZXkgYXV0aGVudGljYXRpb24gaW5mb3JtYXRpb24gaGFzIGJlZW4gZGVtb25z dHJhdGVkIGluIHByYWN0aWNlIHRvIGJlIGZyYXVnaHQgd2l0aCBwZXJpbCwgYW5kIGhhcyByZXN1 bHRlZCBpbiBzb21lIG9mIHRoZSBtb3N0IHByb21pbmVudCBzZWN1cml0eSBicmVhY2hlcyByZWxh dGVkIHRvIHRoZSBtaXN1c2Ugb2YgT0F1dGguPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 IC0tIE1pa2U8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IE9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgUGhpbCBIdW50PGJyPg0KU2Vu dDogVGh1cnNkYXksIEp1bmUgMDUsIDIwMTQgODo1NCBBTTxicj4NClRvOiBIYW5uZXMgVHNjaG9m ZW5pZzxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYu b3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFF1ZXN0aW9uIHJlZ2FyZGluZyBk cmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjPGJyPg0KPGJyPg0KWW91IGFyZSBjb3JyZWN0LiBK dXN0IGFkZGluZyB0byBhY2Nlc3MgdG9rZW4gd291bGQgbWFrZSBhIGxvdCBvZiBkZXZzIGhhcHB5 IGFuZCB0aGF0IGNlcnRhaW5seSBzaG91bGQgYmUgZGlzY3Vzc2VkLg0KPGJyPg0KPGJyPg0KVHdv IHJlcXVpcmVtZW50cyBpc3N1ZXM6PGJyPg0KPGJyPg0KMS4gQSBrZXkgdXNlIGNhc2UgaXMgcGFz c2luZyBhdXRoIGN0eCBvbmx5LiBBbiBhY2Nlc3MgdG9rZW4gbWVhbnMgYXNraW5nIGZvciBjb25z ZW50IHRvIGFjY2VzcyBzb21ldGhpbmcuIFRoaXMgY2F1c2VzIG1hbnkgc2l0ZXMgdG8gbG9vc2Ug bmV3IHVzZXJzLiBBdXRoZW4gb25seSBjYW4gYmUgaW1wbGljaXQgY29uc2VudC4NCjxicj4NCjxi cj4NCjIuJm5ic3A7IENvbXBhdGliaWxpdHkgd2l0aCBPcGVuSWQgSUQgVG9rZW4gYW5kIGZsb3dz LiA8YnI+DQo8YnI+DQozLiBUaGVyZSBpcyBhIG5lZWQgdG8gc3VwcG9ydCByZS1hdXRoIGFuZCBN RkEvTE9BIG5lZ290aWF0aW9uLiBFZyB3ZWIgc2l0ZSB3b3VsZCBsaWtlIHRvIG9idGFpbiBhIGhp Z2hlciBsZXZlbCBvZiBhc3N1cmFuY2UgZm9yIGEgaGlnaGVyIHJpc2sgYWN0aW9uLg0KPGJyPg0K PGJyPg0KVGhlIG5vbi10ZWNoIHJlcXVpcmVtZW50IGlzIHRoZSBzb2xuIG11c3QgYmUgcmVjZWl2 ZWQgYnkgY2xpZW50IGFuZCBzZXJ2aWNlIHByb3ZpZGVyIGRldmVsb3BlcnMgYXMgZWFzeSB0byBp bXBsZW1lbnQgaW4gYWRkaXRpb24gdG8gNjc0OSBvciBldmVuIE9BdXRoIDEuMWEuIEkgbWVudGlv biBpdCBiZWNhdXNlIGRldnMgZmVlbCB0aGlzIHNob3VsZCBiZSB0cml2aWFsLiZuYnNwOyBZb3Vy IHN1Z2dlc3Rpb24gb2YgYWRkaW5nIHRvIGFjY2VzcyB0b2tlbiBjZXJ0YWlubHkNCiBmaXRzIHRo aXMuIDxicj4NCjxicj4NClBoaWw8YnI+DQo8YnI+DQomZ3Q7IE9uIEp1biA1LCAyMDE0LCBhdCAw OjQ0LCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2Zl bmlnQGdteC5uZXQiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7IDxicj4NCiZndDsgSGkgUGhpbCw8YnI+DQomZ3Q7IDxicj4NCiZndDsgdGhhbmtzIGZv ciBwcm9kdWNpbmcgdGhpcyBkb2N1bWVudCB3cml0ZS11cC4gSSBoYXZlIGEgc29tZXdoYXQgYmFz aWMgPGJyPg0KJmd0OyBxdWVzdGlvbiByZWdhcmRpbmcgdGhlIGRvY3VtZW50Ljxicj4NCiZndDsg PGJyPg0KJmd0OyBUaGUgaWQgdG9rZW4gY29udGFpbnMgdGhlIGZvbGxvd2luZyBtYW5kYXRvcnkg aW5mb3JtYXRpb246PGJyPg0KJmd0OyAtIHNpczogaXNzdWVyPGJyPg0KJmd0OyAtIHN1Yjogc3Vi amVjdDxicj4NCiZndDsgLSBhdWQ6IGF1ZGllbmNlPGJyPg0KJmd0OyAtIGlhdDogaXNzdWVkIGF0 PGJyPg0KJmd0OyAtIGV4cDogZXhwaXJ5PGJyPg0KJmd0OyAtIGF1dGhfdGltZTogdGltZSB3aGVu IHRoZSBlbmQgdXNlciB3YXMgYXV0aGVudGljYXRlZDxicj4NCiZndDsgPGJyPg0KJmd0OyBBbiBh Y2Nlc3MgdG9rZW4gKHdoZW4gZW5jb2RlZCBhcyBhIEpXVCkgbWF5IGNvbnRhaW4gYWxsIHRoZXNl IGZpZWxkcyA8YnI+DQomZ3Q7IGV4Y2VwdCB0aGUgYXV0aF90aW1lIChzaW5jZSBhdXRoX3RpbWUg aXMgbm90IGRlZmluZWQgaW4gdGhlIEpXVCBzcGVjKS48YnI+DQomZ3Q7IDxicj4NCiZndDsgR2l2 ZW4gdGhhdCB5b3VyIHByb3Bvc2FsIGFjdHVhbGx5IGRvZXMgbm90IGRlZmluZSB0aGUgYXV0aGVu dGljYXRpb24gPGJyPg0KJmd0OyBwcm90b2NvbCB0byBiZSB1c2VkIGJldHdlZW4gdGhlIHJlc291 cmNlIG93bmVyL2VuZCB1c2VyIGFuZCB0aGUgPGJyPg0KJmd0OyBhdXRob3Jpc2F0aW9uIHNlcnZl ciBJIGFtIHdvbmRlcmluZyB3aGV0aGVyIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIDxicj4NCiZn dDsganVzdCBhZGQgdGhlIGF1dGhfdGltZSBwYXJhbWV0ZXIgKGFuZCBtYXliZSBzb21lIG9mIHRo ZSBvcHRpb25hbCA8YnI+DQomZ3Q7IHBhcmFtZXRlcnMpIHRvIHRoZSBhY2Nlc3MgdG9rZW4uIFRo ZW4sIHlvdSBjYW4gc2tpcCB0aGUgaWQgdG9rZW4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhvdyBk byBJIGNvbWUgdXAgd2l0aCB0aGF0IHF1ZXN0aW9uPyBJbiBLZXJiZXJvcywgZm9yIGV4YW1wbGUs IHRoZSA8YnI+DQomZ3Q7IGFib3ZlLWxpc3RlZCBpbmZvcm1hdGlvbiBpcyBjYXJyaWVkIHdpdGhp biBhIHNpbmdsZSBjb250YWluZXIgKHdpdGhpbiA8YnI+DQomZ3Q7IHRoZSB0aWNrZXQpIGFuZCBz byBJIGFtIGN1cmlvdXMgdG8gaGVhciB3aHkgd2UgaGF2ZSB0byBzZW5kIHRoZSA8YnI+DQomZ3Q7 IGluZm9ybWF0aW9uIHR3aWNlIGluIE9BdXRoIChvbmNlIGluIHRoZSBhY2Nlc3MgdG9rZW4sIHdo ZW4gdGhlIGluZm8gaXMgPGJyPg0KJmd0OyBwYXNzZWQgcGVyIHZhbHVlLCBhbmQgYWdhaW4gdmlh IHRoZSBpZCB0b2tlbikuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE1heWJlIEkgbWlzc2luZyBzb21l dGhpbmcgaW1wb3J0YW50IGhlcmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENpYW88YnI+DQomZ3Q7 IEhhbm5lczxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBpZD0ieXF0ZmQxMTk4MCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_482eb1c40dbb4da08dfb0d64879fac70BLUPR03MB309namprd03pro_-- From nobody Thu Jun 5 12:45:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F362B1A031D for ; Thu, 5 Jun 2014 12:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQaHYkjB9uqK for ; Thu, 5 Jun 2014 12:45:24 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BBB1A034D for ; Thu, 5 Jun 2014 12:45:23 -0700 (PDT) Received: from [79.253.29.4] (helo=[192.168.71.82]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Wsdb9-0006bc-6y; Thu, 05 Jun 2014 21:45:15 +0200 References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> <482eb1c40dbb4da08dfb0d64879fac70@BLUPR03MB309.namprd03.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <482eb1c40dbb4da08dfb0d64879fac70@BLUPR03MB309.namprd03.prod.outlook.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1DB0044F-09C3-4B71-9003-EDCAB5EA4065 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (11D201) From: Torsten Lodderstedt Date: Thu, 5 Jun 2014 21:45:15 +0200 To: Anthony Nadalin X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fqehK9hiWQkENG91PgUZi0jeX80 Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:45:26 -0000 --Apple-Mail-1DB0044F-09C3-4B71-9003-EDCAB5EA4065 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Examples? > Am 05.06.2014 um 21:42 schrieb Anthony Nadalin : >=20 > It=E2=80=99s great but some ways but also very limiting if you are countin= g on certain requirements to be represented in the access token > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderste= dt > Sent: Thursday, June 5, 2014 12:40 PM > To: Bill Mills > Cc: Phil Hunt; oauth@ietf.org > Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c > =20 > +1 > =20 > the access token is opaque to the client. That's great! Let's keep it that= way. >=20 > Am 05.06.2014 um 21:20 schrieb Bill Mills : >=20 > Can't agree more with the peril of overloading auth information into an ac= cess token. > =20 >=20 > On Thursday, June 5, 2014 11:05 AM, Mike Jones wrote: > =20 >=20 > Hannes, the Access Token and ID Token do quite different things and have d= ifferent structures and properties. The Access Token is an opaque value tha= t grants access to resources. An ID Token is a non-opaque JWT security toke= n that makes claims about the authentication that occurred. You can have on= e without the other or you can have both, depending upon the use case. Thus= , trying to move information between them would be problematic in several re= gards. >=20 > Also, trying to overload the Access Token to convey authentication informa= tion has been demonstrated in practice to be fraught with peril, and has res= ulted in some of the most prominent security breaches related to the misuse o= f OAuth. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Thursday, June 05, 2014 8:54 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c >=20 > You are correct. Just adding to access token would make a lot of devs happ= y and that certainly should be discussed.=20 >=20 > Two requirements issues: >=20 > 1. A key use case is passing auth ctx only. An access token means asking f= or consent to access something. This causes many sites to loose new users. A= uthen only can be implicit consent.=20 >=20 > 2. Compatibility with OpenId ID Token and flows.=20 >=20 > 3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site= would like to obtain a higher level of assurance for a higher risk action.=20= >=20 > The non-tech requirement is the soln must be received by client and servic= e provider developers as easy to implement in addition to 6749 or even OAuth= 1.1a. I mention it because devs feel this should be trivial. Your suggesti= on of adding to access token certainly fits this.=20 >=20 > Phil >=20 > > On Jun 5, 2014, at 0:44, Hannes Tschofenig w= rote: > >=20 > > Hi Phil, > >=20 > > thanks for producing this document write-up. I have a somewhat basic=20 > > question regarding the document. > >=20 > > The id token contains the following mandatory information: > > - sis: issuer > > - sub: subject > > - aud: audience > > - iat: issued at > > - exp: expiry > > - auth_time: time when the end user was authenticated > >=20 > > An access token (when encoded as a JWT) may contain all these fields=20 > > except the auth_time (since auth_time is not defined in the JWT spec). > >=20 > > Given that your proposal actually does not define the authentication=20 > > protocol to be used between the resource owner/end user and the=20 > > authorisation server I am wondering whether it would be possible to=20 > > just add the auth_time parameter (and maybe some of the optional=20 > > parameters) to the access token. Then, you can skip the id token. > >=20 > > How do I come up with that question? In Kerberos, for example, the=20 > > above-listed information is carried within a single container (within=20= > > the ticket) and so I am curious to hear why we have to send the=20 > > information twice in OAuth (once in the access token, when the info is=20= > > passed per value, and again via the id token). > >=20 > > Maybe I missing something important here. > >=20 > > Ciao > > Hannes > >=20 > >=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 --Apple-Mail-1DB0044F-09C3-4B71-9003-EDCAB5EA4065 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Examples?

Am 05.06.2014 u= m 21:42 schrieb Anthony Nadalin <tonynad@microsoft.com>:

=

It=E2=80=99s great but some= ways but also very limiting if you are counting on certain requirements to b= e represented in the access token

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Thursday, June 5, 2014 12:40 PM
To: Bill Mills
Cc: Phil Hunt; oauth@ietf.org Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a= 4c

 

+1

 

the access token is opaque to the client. That's grea= t! Let's keep it that way.


Am 05.06.2014 um 21:20 schrieb Bill Mills <wmills_92105@yahoo.com>:

Can't agree more w= ith the peril of overloading auth information into an access token.

 

On T= hursday, June 5, 2014 11:05 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:=

 

Hannes, the Acces= s Token and ID Token do quite different things and have different structures= and properties.  The Access Token is an opaque value that grants access to resources.  An ID Token is a non-opaque JWT security t= oken that makes claims about the authentication that occurred.  You can= have one without the other or you can have both, depending upon the use cas= e.  Thus, trying to move information between them would be problematic in several regards.

Also, trying to overload the Access Token to convey authentication informati= on has been demonstrated in practice to be fraught with peril, and has resul= ted in some of the most prominent security breaches related to the misuse of= OAuth.

                -= - Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@= ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

You are correct. Just adding to access token would make a lot of devs happy a= nd that certainly should be discussed.

Two requirements issues:

1. A key use case is passing auth ctx only. An access token means asking for= consent to access something. This causes many sites to loose new users. Aut= hen only can be implicit consent.

2.  Compatibility with OpenId ID Token and flows.

3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site w= ould like to obtain a higher level of assurance for a higher risk action.

The non-tech requirement is the soln must be received by client and service p= rovider developers as easy to implement in addition to 6749 or even OAuth 1.= 1a. I mention it because devs feel this should be trivial.  Your sugges= tion of adding to access token certainly fits this.

Phil

> On Jun 5, 2014, at 0:44, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
> Hi Phil,
>
> thanks for producing this document write-up. I have a somewhat basic > question regarding the document.
>
> The id token contains the following mandatory information:
> - sis: issuer
> - sub: subject
> - aud: audience
> - iat: issued at
> - exp: expiry
> - auth_time: time when the end user was authenticated
>
> An access token (when encoded as a JWT) may contain all these fields > except the auth_time (since auth_time is not defined in the JWT spec).<= br> >
> Given that your proposal actually does not define the authentication > protocol to be used between the resource owner/end user and the
> authorisation server I am wondering whether it would be possible to > just add the auth_time parameter (and maybe some of the optional
> parameters) to the access token. Then, you can skip the id token.
>
> How do I come up with that question? In Kerberos, for example, the
= > above-listed information is carried within a single container (within <= br> > the ticket) and so I am curious to hear why we have to send the
> information twice in OAuth (once in the access token, when the info is <= br> > passed per value, and again via the id token).
>
> Maybe I missing something important here.
>
> Ciao
> Hannes
>
>

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



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

 

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

= --Apple-Mail-1DB0044F-09C3-4B71-9003-EDCAB5EA4065-- From nobody Thu Jun 5 12:46:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0451A0347 for ; Thu, 5 Jun 2014 12:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzaGICTraF9M for ; Thu, 5 Jun 2014 12:46:32 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC7D1A0357 for ; Thu, 5 Jun 2014 12:46:31 -0700 (PDT) X-AuditID: 1209190e-f79946d000000c39-99-5390c910ba97 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 62.2F.03129.019C0935; Thu, 5 Jun 2014 15:46:24 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s55JkL84026229; Thu, 5 Jun 2014 15:46:22 -0400 Received: from [25.152.51.2] ([172.56.22.77]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s55JkH8X001271 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Jun 2014 15:46:19 -0400 Date: Thu, 05 Jun 2014 15:46:14 -0400 Message-ID: <9993lnsc95f3nn0lccwnbppw.1401997574714@email.android.com> From: Justin Richer To: Anthony Nadalin MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_3714897886440111" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IR4hTV1hU4OSHY4P83YYuTb1+xWbxZeJzV YtPcbYwWr449ZbH41nWd2YHVY8mSn0wex3r6WT1ad/xl95g16zBTAEsUl01Kak5mWWqRvl0C V8aJVVOZCw4kVjyac5S9gfFNXBcjJ4eEgInE7lWLmSFsMYkL99azdTFycQgJzGaS2DF9AwuE s4FR4vTxTUwQzjwmiavT2xhBWlgEVCVurtnFBGILC7hL7O29CmbzCrhJvLq2ig3EZgOqmb/y FlhcREBb4sT7lcwgg5gF5jBKfP+1kxWiQVDi5MwnLCA2s0CoxN41vSwTGHlnIUnNQpKCsNUl /sy7xAxhK0pM6X7IPouRA8hWk1jWqoQsvICRbRWjbEpulW5uYmZOcWqybnFyYl5eapGusV5u ZoleakrpJkZwcEvy7WD8elDpEKMAB6MSD29A/4RgIdbEsuLK3EOMkhxMSqK8eluBQnxJ+SmV GYnFGfFFpTmpxYcYJTiYlUR4ObYA5XhTEiurUovyYVLSHCxK4rxvra2ChQTSE0tSs1NTC1KL YLIyHBxKErzRJ4AaBYtS01Mr0jJzShDSTBycIMN5gIbXg9TwFhck5hZnpkPkTzEqSonz1h0H SgiAJDJK8+B6YcnnFaM40CvCvN4g7TzAxAXX/QpoMBPQ4M1FvSCDSxIRUlINjPOPTjh0LEp+ gqV72MeL+1+q+G14FTC30FDo/Ay35fp3v+q7GK6o3Xf8Hmc8V3/c5qwdypYu9iuMDsy4+q0m sGvbIUbtG3aResKpDWs/HSrSr/ou+tg25Tuf04GVgVPm+0dlOOUaXihLZ7r3u6jKw1Xy2tbl 3N9tcvL4snQmJzIcE73BkMXkqcRSnJFoqMVcVJwIANZB3UcZAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/37YKQbCtF41_eZsYGS4FrWqV7sI Cc: Phil Hunt , oauth@ietf.org Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:46:34 -0000 ----_com.android.email_3714897886440111 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Tm8sIGl0J3MgZ3JlYXQgZXhhY3RseSAqYmVjYXVzZSogeW91IGNhbiByZXByZXNlbnQgdGhpbmdz IGluIHRoZSBhY2Nlc3MgdG9rZW4gdGhhdCBtYWtlIHNlbnNlIGZvciB5b3VyIGFwcC9kb21haW4g YW5kIGl0IHN0YXlzIG9wYXF1ZSB0byB0aGUgcGFydGllcyB3aG8gc2hvdWxkbid0IGNhcmU6IHRo ZSBjbGllbnRzLiBBY2Nlc3MgdG9rZW5zIGFyZW4ndCBvcGFxdWUgdG8gdGhlIEFTIChvciBQUiks IGJlY2F1c2Ugb2YgT0F1dGgncyBmbGV4aWJpbGl0eSBvZiB0b2tlbiBmb3JtYXRzIHlvdSBjYW4g dXNlIHdoYXQgd29ya3MuCgotLUp1c3Rpbgovc2VudCBmcm9tIG15IHBob25lLwoKQW50aG9ueSBO YWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb20+IHdyb3RlOgoKPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj5PQXV0aCBtYWlsaW5nIGxpc3QKPk9BdXRo QGlldGYub3JnCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCg== ----_com.android.email_3714897886440111 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Tm8sIGl0JiMzOTtzIGdyZWF0IGV4YWN0bHkgKmJlY2F1c2UqIHlvdSBjYW4gcmVwcmVzZW50IHRo aW5ncyBpbiB0aGUgYWNjZXNzIHRva2VuIHRoYXQgbWFrZSBzZW5zZSBmb3IgeW91ciBhcHAvZG9t YWluIGFuZCBpdCBzdGF5cyBvcGFxdWUgdG8gdGhlIHBhcnRpZXMgd2hvIHNob3VsZG4mIzM5O3Qg Y2FyZTogdGhlIGNsaWVudHMuIEFjY2VzcyB0b2tlbnMgYXJlbiYjMzk7dCBvcGFxdWUgdG8gdGhl IEFTIChvciBQUiksIGJlY2F1c2Ugb2YgT0F1dGgmIzM5O3MgZmxleGliaWxpdHkgb2YgdG9rZW4g Zm9ybWF0cyB5b3UgY2FuIHVzZSB3aGF0IHdvcmtzLjxicj48YnI+LS1KdXN0aW48YnI+L3NlbnQg ZnJvbSBteSBwaG9uZS88YnI+PGJyPkFudGhvbnkgTmFkYWxpbiAmbHQ7dG9ueW5hZEBtaWNyb3Nv ZnQuY29tJmd0OyB3cm90ZTo8YnI+PGJyPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JdOKAmXMgZ3JlYXQgYnV0IHNvbWUgd2F5cyBidXQgYWxzbyB2ZXJ5IGxpbWl0aW5nIGlm IHlvdSBhcmUgY291bnRpbmcgb24gY2VydGFpbiByZXF1aXJlbWVudHMgdG8gYmUgcmVwcmVzZW50 ZWQgaW4gdGhlIGFjY2VzcyB0b2tlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5Ub3JzdGVuIExvZGRlcnN0ZWR0PGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBKdW5lIDUsIDIwMTQgMTI6NDAgUE08YnI+DQo8Yj5Ubzo8L2I+IEJpbGwgTWls bHM8YnI+DQo8Yj5DYzo8L2I+IFBoaWwgSHVudDsgb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUXVlc3Rpb24gcmVnYXJkaW5nIGRyYWZ0LWh1bnQtb2F1 dGgtdjItdXNlci1hNGM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+JiM0MzsxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnRoZSBhY2Nlc3MgdG9rZW4gaXMgb3BhcXVlIHRvIHRoZSBjbGllbnQu IFRoYXQncyBncmVhdCEgTGV0J3Mga2VlcCBpdCB0aGF0IHdheS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KQW0gMDUuMDYuMjAxNCB1bSAyMToyMCBzY2hyaWViIEJpbGwgTWlsbHMgJmx0 OzxhIGhyZWY9Im1haWx0bzp3bWlsbHNfOTIxMDVAeWFob28uY29tIj53bWlsbHNfOTIxMDVAeWFo b28uY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Q2FuJ3QgYWdyZWUgbW9yZSB3aXRoIHRoZSBwZXJpbCBvZiBv dmVybG9hZGluZyBhdXRoIGluZm9ybWF0aW9uIGludG8gYW4gYWNjZXNzIHRva2VuLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5PbiBUaHVyc2Rh eSwgSnVuZSA1LCAyMDE0IDExOjA1IEFNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IYW5u ZXMsIHRoZSBBY2Nlc3MgVG9rZW4gYW5kIElEIFRva2VuIGRvIHF1aXRlIGRpZmZlcmVudCB0aGlu Z3MgYW5kIGhhdmUgZGlmZmVyZW50IHN0cnVjdHVyZXMgYW5kIHByb3BlcnRpZXMuJm5ic3A7IFRo ZSBBY2Nlc3MgVG9rZW4gaXMgYW4gb3BhcXVlIHZhbHVlIHRoYXQNCiBncmFudHMgYWNjZXNzIHRv IHJlc291cmNlcy4mbmJzcDsgQW4gSUQgVG9rZW4gaXMgYSBub24tb3BhcXVlIEpXVCBzZWN1cml0 eSB0b2tlbiB0aGF0IG1ha2VzIGNsYWltcyBhYm91dCB0aGUgYXV0aGVudGljYXRpb24gdGhhdCBv Y2N1cnJlZC4mbmJzcDsgWW91IGNhbiBoYXZlIG9uZSB3aXRob3V0IHRoZSBvdGhlciBvciB5b3Ug Y2FuIGhhdmUgYm90aCwgZGVwZW5kaW5nIHVwb24gdGhlIHVzZSBjYXNlLiZuYnNwOyBUaHVzLCB0 cnlpbmcgdG8gbW92ZSBpbmZvcm1hdGlvbiBiZXR3ZWVuDQogdGhlbSB3b3VsZCBiZSBwcm9ibGVt YXRpYyBpbiBzZXZlcmFsIHJlZ2FyZHMuPGJyPg0KPGJyPg0KQWxzbywgdHJ5aW5nIHRvIG92ZXJs b2FkIHRoZSBBY2Nlc3MgVG9rZW4gdG8gY29udmV5IGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9u IGhhcyBiZWVuIGRlbW9uc3RyYXRlZCBpbiBwcmFjdGljZSB0byBiZSBmcmF1Z2h0IHdpdGggcGVy aWwsIGFuZCBoYXMgcmVzdWx0ZWQgaW4gc29tZSBvZiB0aGUgbW9zdCBwcm9taW5lbnQgc2VjdXJp dHkgYnJlYWNoZXMgcmVsYXRlZCB0byB0aGUgbWlzdXNlIG9mIE9BdXRoLjxicj4NCjxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQpGcm9tOiBPQXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFBo aWwgSHVudDxicj4NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDA1LCAyMDE0IDg6NTQgQU08YnI+DQpU bzogSGFubmVzIFRzY2hvZmVuaWc8YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu b3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBRdWVz dGlvbiByZWdhcmRpbmcgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yzxicj4NCjxicj4NCllv dSBhcmUgY29ycmVjdC4gSnVzdCBhZGRpbmcgdG8gYWNjZXNzIHRva2VuIHdvdWxkIG1ha2UgYSBs b3Qgb2YgZGV2cyBoYXBweSBhbmQgdGhhdCBjZXJ0YWlubHkgc2hvdWxkIGJlIGRpc2N1c3NlZC4N Cjxicj4NCjxicj4NClR3byByZXF1aXJlbWVudHMgaXNzdWVzOjxicj4NCjxicj4NCjEuIEEga2V5 IHVzZSBjYXNlIGlzIHBhc3NpbmcgYXV0aCBjdHggb25seS4gQW4gYWNjZXNzIHRva2VuIG1lYW5z IGFza2luZyBmb3IgY29uc2VudCB0byBhY2Nlc3Mgc29tZXRoaW5nLiBUaGlzIGNhdXNlcyBtYW55 IHNpdGVzIHRvIGxvb3NlIG5ldyB1c2Vycy4gQXV0aGVuIG9ubHkgY2FuIGJlIGltcGxpY2l0IGNv bnNlbnQuDQo8YnI+DQo8YnI+DQoyLiZuYnNwOyBDb21wYXRpYmlsaXR5IHdpdGggT3BlbklkIElE IFRva2VuIGFuZCBmbG93cy4gPGJyPg0KPGJyPg0KMy4gVGhlcmUgaXMgYSBuZWVkIHRvIHN1cHBv cnQgcmUtYXV0aCBhbmQgTUZBL0xPQSBuZWdvdGlhdGlvbi4gRWcgd2ViIHNpdGUgd291bGQgbGlr ZSB0byBvYnRhaW4gYSBoaWdoZXIgbGV2ZWwgb2YgYXNzdXJhbmNlIGZvciBhIGhpZ2hlciByaXNr IGFjdGlvbi4NCjxicj4NCjxicj4NClRoZSBub24tdGVjaCByZXF1aXJlbWVudCBpcyB0aGUgc29s biBtdXN0IGJlIHJlY2VpdmVkIGJ5IGNsaWVudCBhbmQgc2VydmljZSBwcm92aWRlciBkZXZlbG9w ZXJzIGFzIGVhc3kgdG8gaW1wbGVtZW50IGluIGFkZGl0aW9uIHRvIDY3NDkgb3IgZXZlbiBPQXV0 aCAxLjFhLiBJIG1lbnRpb24gaXQgYmVjYXVzZSBkZXZzIGZlZWwgdGhpcyBzaG91bGQgYmUgdHJp dmlhbC4mbmJzcDsgWW91ciBzdWdnZXN0aW9uIG9mIGFkZGluZyB0byBhY2Nlc3MgdG9rZW4gY2Vy dGFpbmx5DQogZml0cyB0aGlzLiA8YnI+DQo8YnI+DQpQaGlsPGJyPg0KPGJyPg0KJmd0OyBPbiBK dW4gNSwgMjAxNCwgYXQgMDo0NCwgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0 bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Ij5oYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9h PiZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIFBoaWwsPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IHRoYW5rcyBmb3IgcHJvZHVjaW5nIHRoaXMgZG9jdW1lbnQgd3JpdGUtdXAuIEkgaGF2 ZSBhIHNvbWV3aGF0IGJhc2ljIDxicj4NCiZndDsgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSBkb2N1 bWVudC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGlkIHRva2VuIGNvbnRhaW5zIHRoZSBmb2xs b3dpbmcgbWFuZGF0b3J5IGluZm9ybWF0aW9uOjxicj4NCiZndDsgLSBzaXM6IGlzc3Vlcjxicj4N CiZndDsgLSBzdWI6IHN1YmplY3Q8YnI+DQomZ3Q7IC0gYXVkOiBhdWRpZW5jZTxicj4NCiZndDsg LSBpYXQ6IGlzc3VlZCBhdDxicj4NCiZndDsgLSBleHA6IGV4cGlyeTxicj4NCiZndDsgLSBhdXRo X3RpbWU6IHRpbWUgd2hlbiB0aGUgZW5kIHVzZXIgd2FzIGF1dGhlbnRpY2F0ZWQ8YnI+DQomZ3Q7 IDxicj4NCiZndDsgQW4gYWNjZXNzIHRva2VuICh3aGVuIGVuY29kZWQgYXMgYSBKV1QpIG1heSBj b250YWluIGFsbCB0aGVzZSBmaWVsZHMgPGJyPg0KJmd0OyBleGNlcHQgdGhlIGF1dGhfdGltZSAo c2luY2UgYXV0aF90aW1lIGlzIG5vdCBkZWZpbmVkIGluIHRoZSBKV1Qgc3BlYykuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEdpdmVuIHRoYXQgeW91ciBwcm9wb3NhbCBhY3R1YWxseSBkb2VzIG5vdCBk ZWZpbmUgdGhlIGF1dGhlbnRpY2F0aW9uIDxicj4NCiZndDsgcHJvdG9jb2wgdG8gYmUgdXNlZCBi ZXR3ZWVuIHRoZSByZXNvdXJjZSBvd25lci9lbmQgdXNlciBhbmQgdGhlIDxicj4NCiZndDsgYXV0 aG9yaXNhdGlvbiBzZXJ2ZXIgSSBhbSB3b25kZXJpbmcgd2hldGhlciBpdCB3b3VsZCBiZSBwb3Nz aWJsZSB0byA8YnI+DQomZ3Q7IGp1c3QgYWRkIHRoZSBhdXRoX3RpbWUgcGFyYW1ldGVyIChhbmQg bWF5YmUgc29tZSBvZiB0aGUgb3B0aW9uYWwgPGJyPg0KJmd0OyBwYXJhbWV0ZXJzKSB0byB0aGUg YWNjZXNzIHRva2VuLiBUaGVuLCB5b3UgY2FuIHNraXAgdGhlIGlkIHRva2VuLjxicj4NCiZndDsg PGJyPg0KJmd0OyBIb3cgZG8gSSBjb21lIHVwIHdpdGggdGhhdCBxdWVzdGlvbj8gSW4gS2VyYmVy b3MsIGZvciBleGFtcGxlLCB0aGUgPGJyPg0KJmd0OyBhYm92ZS1saXN0ZWQgaW5mb3JtYXRpb24g aXMgY2FycmllZCB3aXRoaW4gYSBzaW5nbGUgY29udGFpbmVyICh3aXRoaW4gPGJyPg0KJmd0OyB0 aGUgdGlja2V0KSBhbmQgc28gSSBhbSBjdXJpb3VzIHRvIGhlYXIgd2h5IHdlIGhhdmUgdG8gc2Vu ZCB0aGUgPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiB0d2ljZSBpbiBPQXV0aCAob25jZSBpbiB0aGUg YWNjZXNzIHRva2VuLCB3aGVuIHRoZSBpbmZvIGlzIDxicj4NCiZndDsgcGFzc2VkIHBlciB2YWx1 ZSwgYW5kIGFnYWluIHZpYSB0aGUgaWQgdG9rZW4pLjxicj4NCiZndDsgPGJyPg0KJmd0OyBNYXli ZSBJIG1pc3Npbmcgc29tZXRoaW5nIGltcG9ydGFudCBoZXJlLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBDaWFvPGJyPg0KJmd0OyBIYW5uZXM8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRo QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9Inlx dGZkMTE5ODAiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0K ----_com.android.email_3714897886440111-- From nobody Thu Jun 5 12:47:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3736B1A036B for ; Thu, 5 Jun 2014 12:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWsf05oyZeJc for ; Thu, 5 Jun 2014 12:47:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905D91A036D for ; Thu, 5 Jun 2014 12:47:13 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB311.namprd03.prod.outlook.com (10.141.48.26) with Microsoft SMTP Server (TLS) id 15.0.959.15; Thu, 5 Jun 2014 19:47:05 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0959.000; Thu, 5 Jun 2014 19:47:05 +0000 From: Anthony Nadalin To: Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c Thread-Index: AQHPgJJXl+S5jRd6AUqb8tCOpHWSlJtiq6AAgAAfdICAABpBgIAABUcAgAAAVtCAAAFAgIAAAG5Q Date: Thu, 5 Jun 2014 19:47:04 +0000 Message-ID: <16ef7d8f45ff463fa6d60b913a5a4053@BLUPR03MB309.namprd03.prod.outlook.com> References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> <482eb1c40dbb4da08dfb0d64879fac70@BLUPR03MB309.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(24454002)(13464003)(51704005)(52604005)(377454003)(189002)(199002)(21056001)(64706001)(4396001)(81342001)(81542001)(561944003)(76482001)(19300405004)(31966008)(2656002)(83322001)(80022001)(19580395003)(87936001)(19580405001)(46102001)(93886002)(74662001)(74502001)(86362001)(86612001)(15202345003)(92566001)(77982001)(19625215002)(20776003)(79102001)(99396002)(16236675004)(83072002)(85852003)(19609705001)(99286001)(101416001)(33646001)(74316001)(76576001)(50986999)(54356999)(76176999)(15975445006)(77096999)(42262001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB311; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; Content-Type: multipart/alternative; boundary="_000_16ef7d8f45ff463fa6d60b913a5a4053BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/xKsG50Mfe0ibsoIExloU6if5l3I Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:47:16 -0000 --_000_16ef7d8f45ff463fa6d60b913a5a4053BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVsZWdhdGlvbg0KDQpGcm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBs b2RkZXJzdGVkdC5uZXRdDQpTZW50OiBUaHVyc2RheSwgSnVuZSA1LCAyMDE0IDEyOjQ1IFBNDQpU bzogQW50aG9ueSBOYWRhbGluDQpDYzogQmlsbCBNaWxsczsgUGhpbCBIdW50OyBvYXV0aEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUXVlc3Rpb24gcmVnYXJkaW5nIGRyYWZ0LWh1 bnQtb2F1dGgtdjItdXNlci1hNGMNCg0KRXhhbXBsZXM/DQoNCkFtIDA1LjA2LjIwMTQgdW0gMjE6 NDIgc2NocmllYiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86 dG9ueW5hZEBtaWNyb3NvZnQuY29tPj46DQpJdOKAmXMgZ3JlYXQgYnV0IHNvbWUgd2F5cyBidXQg YWxzbyB2ZXJ5IGxpbWl0aW5nIGlmIHlvdSBhcmUgY291bnRpbmcgb24gY2VydGFpbiByZXF1aXJl bWVudHMgdG8gYmUgcmVwcmVzZW50ZWQgaW4gdGhlIGFjY2VzcyB0b2tlbg0KDQpGcm9tOiBPQXV0 aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUb3JzdGVuIExv ZGRlcnN0ZWR0DQpTZW50OiBUaHVyc2RheSwgSnVuZSA1LCAyMDE0IDEyOjQwIFBNDQpUbzogQmls bCBNaWxscw0KQ2M6IFBoaWwgSHVudDsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUXVlc3Rpb24gcmVnYXJkaW5nIGRyYWZ0LWh1 bnQtb2F1dGgtdjItdXNlci1hNGMNCg0KKzENCg0KdGhlIGFjY2VzcyB0b2tlbiBpcyBvcGFxdWUg dG8gdGhlIGNsaWVudC4gVGhhdCdzIGdyZWF0ISBMZXQncyBrZWVwIGl0IHRoYXQgd2F5Lg0KDQpB bSAwNS4wNi4yMDE0IHVtIDIxOjIwIHNjaHJpZWIgQmlsbCBNaWxscyA8d21pbGxzXzkyMTA1QHlh aG9vLmNvbTxtYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4+Og0KQ2FuJ3QgYWdyZWUgbW9y ZSB3aXRoIHRoZSBwZXJpbCBvZiBvdmVybG9hZGluZyBhdXRoIGluZm9ybWF0aW9uIGludG8gYW4g YWNjZXNzIHRva2VuLg0KDQpPbiBUaHVyc2RheSwgSnVuZSA1LCAyMDE0IDExOjA1IEFNLCBNaWtl IEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpIYW5uZXMsIHRoZSBBY2Nlc3MgVG9rZW4gYW5kIElE IFRva2VuIGRvIHF1aXRlIGRpZmZlcmVudCB0aGluZ3MgYW5kIGhhdmUgZGlmZmVyZW50IHN0cnVj dHVyZXMgYW5kIHByb3BlcnRpZXMuICBUaGUgQWNjZXNzIFRva2VuIGlzIGFuIG9wYXF1ZSB2YWx1 ZSB0aGF0IGdyYW50cyBhY2Nlc3MgdG8gcmVzb3VyY2VzLiAgQW4gSUQgVG9rZW4gaXMgYSBub24t b3BhcXVlIEpXVCBzZWN1cml0eSB0b2tlbiB0aGF0IG1ha2VzIGNsYWltcyBhYm91dCB0aGUgYXV0 aGVudGljYXRpb24gdGhhdCBvY2N1cnJlZC4gIFlvdSBjYW4gaGF2ZSBvbmUgd2l0aG91dCB0aGUg b3RoZXIgb3IgeW91IGNhbiBoYXZlIGJvdGgsIGRlcGVuZGluZyB1cG9uIHRoZSB1c2UgY2FzZS4g IFRodXMsIHRyeWluZyB0byBtb3ZlIGluZm9ybWF0aW9uIGJldHdlZW4gdGhlbSB3b3VsZCBiZSBw cm9ibGVtYXRpYyBpbiBzZXZlcmFsIHJlZ2FyZHMuDQoNCkFsc28sIHRyeWluZyB0byBvdmVybG9h ZCB0aGUgQWNjZXNzIFRva2VuIHRvIGNvbnZleSBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlvbiBo YXMgYmVlbiBkZW1vbnN0cmF0ZWQgaW4gcHJhY3RpY2UgdG8gYmUgZnJhdWdodCB3aXRoIHBlcmls LCBhbmQgaGFzIHJlc3VsdGVkIGluIHNvbWUgb2YgdGhlIG1vc3QgcHJvbWluZW50IHNlY3VyaXR5 IGJyZWFjaGVzIHJlbGF0ZWQgdG8gdGhlIG1pc3VzZSBvZiBPQXV0aC4NCg0KICAgICAgICAgICAg ICAgIC0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE9BdXRoIFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Zz5dIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IFRodXJzZGF5LCBKdW5lIDA1LCAyMDE0 IDg6NTQgQU0NClRvOiBIYW5uZXMgVHNjaG9mZW5pZw0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0 bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFF1ZXN0aW9uIHJlZ2Fy ZGluZyBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjDQoNCllvdSBhcmUgY29ycmVjdC4gSnVz dCBhZGRpbmcgdG8gYWNjZXNzIHRva2VuIHdvdWxkIG1ha2UgYSBsb3Qgb2YgZGV2cyBoYXBweSBh bmQgdGhhdCBjZXJ0YWlubHkgc2hvdWxkIGJlIGRpc2N1c3NlZC4NCg0KVHdvIHJlcXVpcmVtZW50 cyBpc3N1ZXM6DQoNCjEuIEEga2V5IHVzZSBjYXNlIGlzIHBhc3NpbmcgYXV0aCBjdHggb25seS4g QW4gYWNjZXNzIHRva2VuIG1lYW5zIGFza2luZyBmb3IgY29uc2VudCB0byBhY2Nlc3Mgc29tZXRo aW5nLiBUaGlzIGNhdXNlcyBtYW55IHNpdGVzIHRvIGxvb3NlIG5ldyB1c2Vycy4gQXV0aGVuIG9u bHkgY2FuIGJlIGltcGxpY2l0IGNvbnNlbnQuDQoNCjIuICBDb21wYXRpYmlsaXR5IHdpdGggT3Bl bklkIElEIFRva2VuIGFuZCBmbG93cy4NCg0KMy4gVGhlcmUgaXMgYSBuZWVkIHRvIHN1cHBvcnQg cmUtYXV0aCBhbmQgTUZBL0xPQSBuZWdvdGlhdGlvbi4gRWcgd2ViIHNpdGUgd291bGQgbGlrZSB0 byBvYnRhaW4gYSBoaWdoZXIgbGV2ZWwgb2YgYXNzdXJhbmNlIGZvciBhIGhpZ2hlciByaXNrIGFj dGlvbi4NCg0KVGhlIG5vbi10ZWNoIHJlcXVpcmVtZW50IGlzIHRoZSBzb2xuIG11c3QgYmUgcmVj ZWl2ZWQgYnkgY2xpZW50IGFuZCBzZXJ2aWNlIHByb3ZpZGVyIGRldmVsb3BlcnMgYXMgZWFzeSB0 byBpbXBsZW1lbnQgaW4gYWRkaXRpb24gdG8gNjc0OSBvciBldmVuIE9BdXRoIDEuMWEuIEkgbWVu dGlvbiBpdCBiZWNhdXNlIGRldnMgZmVlbCB0aGlzIHNob3VsZCBiZSB0cml2aWFsLiAgWW91ciBz dWdnZXN0aW9uIG9mIGFkZGluZyB0byBhY2Nlc3MgdG9rZW4gY2VydGFpbmx5IGZpdHMgdGhpcy4N Cg0KUGhpbA0KDQo+IE9uIEp1biA1LCAyMDE0LCBhdCAwOjQ0LCBIYW5uZXMgVHNjaG9mZW5pZyA8 aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5l dD4+IHdyb3RlOg0KPg0KPiBIaSBQaGlsLA0KPg0KPiB0aGFua3MgZm9yIHByb2R1Y2luZyB0aGlz IGRvY3VtZW50IHdyaXRlLXVwLiBJIGhhdmUgYSBzb21ld2hhdCBiYXNpYw0KPiBxdWVzdGlvbiBy ZWdhcmRpbmcgdGhlIGRvY3VtZW50Lg0KPg0KPiBUaGUgaWQgdG9rZW4gY29udGFpbnMgdGhlIGZv bGxvd2luZyBtYW5kYXRvcnkgaW5mb3JtYXRpb246DQo+IC0gc2lzOiBpc3N1ZXINCj4gLSBzdWI6 IHN1YmplY3QNCj4gLSBhdWQ6IGF1ZGllbmNlDQo+IC0gaWF0OiBpc3N1ZWQgYXQNCj4gLSBleHA6 IGV4cGlyeQ0KPiAtIGF1dGhfdGltZTogdGltZSB3aGVuIHRoZSBlbmQgdXNlciB3YXMgYXV0aGVu dGljYXRlZA0KPg0KPiBBbiBhY2Nlc3MgdG9rZW4gKHdoZW4gZW5jb2RlZCBhcyBhIEpXVCkgbWF5 IGNvbnRhaW4gYWxsIHRoZXNlIGZpZWxkcw0KPiBleGNlcHQgdGhlIGF1dGhfdGltZSAoc2luY2Ug YXV0aF90aW1lIGlzIG5vdCBkZWZpbmVkIGluIHRoZSBKV1Qgc3BlYykuDQo+DQo+IEdpdmVuIHRo YXQgeW91ciBwcm9wb3NhbCBhY3R1YWxseSBkb2VzIG5vdCBkZWZpbmUgdGhlIGF1dGhlbnRpY2F0 aW9uDQo+IHByb3RvY29sIHRvIGJlIHVzZWQgYmV0d2VlbiB0aGUgcmVzb3VyY2Ugb3duZXIvZW5k IHVzZXIgYW5kIHRoZQ0KPiBhdXRob3Jpc2F0aW9uIHNlcnZlciBJIGFtIHdvbmRlcmluZyB3aGV0 aGVyIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvDQo+IGp1c3QgYWRkIHRoZSBhdXRoX3RpbWUgcGFy YW1ldGVyIChhbmQgbWF5YmUgc29tZSBvZiB0aGUgb3B0aW9uYWwNCj4gcGFyYW1ldGVycykgdG8g dGhlIGFjY2VzcyB0b2tlbi4gVGhlbiwgeW91IGNhbiBza2lwIHRoZSBpZCB0b2tlbi4NCj4NCj4g SG93IGRvIEkgY29tZSB1cCB3aXRoIHRoYXQgcXVlc3Rpb24/IEluIEtlcmJlcm9zLCBmb3IgZXhh bXBsZSwgdGhlDQo+IGFib3ZlLWxpc3RlZCBpbmZvcm1hdGlvbiBpcyBjYXJyaWVkIHdpdGhpbiBh IHNpbmdsZSBjb250YWluZXIgKHdpdGhpbg0KPiB0aGUgdGlja2V0KSBhbmQgc28gSSBhbSBjdXJp b3VzIHRvIGhlYXIgd2h5IHdlIGhhdmUgdG8gc2VuZCB0aGUNCj4gaW5mb3JtYXRpb24gdHdpY2Ug aW4gT0F1dGggKG9uY2UgaW4gdGhlIGFjY2VzcyB0b2tlbiwgd2hlbiB0aGUgaW5mbyBpcw0KPiBw YXNzZWQgcGVyIHZhbHVlLCBhbmQgYWdhaW4gdmlhIHRoZSBpZCB0b2tlbikuDQo+DQo+IE1heWJl IEkgbWlzc2luZyBzb21ldGhpbmcgaW1wb3J0YW50IGhlcmUuDQo+DQo+IENpYW8NCj4gSGFubmVz DQo+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg== --_000_16ef7d8f45ff463fa6d60b913a5a4053BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EZWxlZ2F0aW9uDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBv c2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRvcnN0ZW4gTG9kZGVy c3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgSnVuZSA1LCAyMDE0IDEyOjQ1IFBNPGJyPg0KPGI+VG86PC9iPiBBbnRob255 IE5hZGFsaW48YnI+DQo8Yj5DYzo8L2I+IEJpbGwgTWlsbHM7IFBoaWwgSHVudDsgb2F1dGhAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUXVlc3Rpb24gcmVnYXJk aW5nIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXhhbXBsZXM/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCkFtIDA1LjA2LjIwMTQgdW0gMjE6NDIgc2NocmllYiBBbnRob255IE5hZGFs aW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWlj cm9zb2Z0LmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SXTigJlzIGdyZWF0IGJ1dCBzb21lIHdheXMgYnV0IGFsc28gdmVyeSBsaW1pdGluZyBpZiB5 b3UgYXJlIGNvdW50aW5nIG9uIGNlcnRhaW4gcmVxdWlyZW1lbnRzIHRvIGJlIHJlcHJlc2VudGVk IGluIHRoZSBhY2Nlc3MgdG9rZW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFs8YSBocmVm PSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Ub3JzdGVuIExvZGRlcnN0ZWR0PGJyPg0K PGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDUsIDIwMTQgMTI6NDAgUE08YnI+DQo8Yj5Ubzo8 L2I+IEJpbGwgTWlsbHM8YnI+DQo8Yj5DYzo8L2I+IFBoaWwgSHVudDsgPGEgaHJlZj0ibWFpbHRv Om9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtPQVVUSC1XR10gUXVlc3Rpb24gcmVnYXJkaW5nIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNl ci1hNGM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+JiM0MzsxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnRoZSBhY2Nlc3MgdG9rZW4gaXMgb3BhcXVlIHRvIHRoZSBjbGllbnQuIFRoYXQncyBn cmVhdCEgTGV0J3Mga2VlcCBpdCB0aGF0IHdheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KQW0gMDUuMDYuMjAxNCB1bSAyMToyMCBzY2hyaWViIEJpbGwgTWlsbHMgJmx0OzxhIGhyZWY9 Im1haWx0bzp3bWlsbHNfOTIxMDVAeWFob28uY29tIj53bWlsbHNfOTIxMDVAeWFob28uY29tPC9h PiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Q2FuJ3QgYWdyZWUgbW9yZSB3aXRoIHRoZSBwZXJpbCBvZiBvdmVybG9hZGlu ZyBhdXRoIGluZm9ybWF0aW9uIGludG8gYW4gYWNjZXNzIHRva2VuLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5PbiBUaHVyc2RheSwgSnVuZSA1 LCAyMDE0IDExOjA1IEFNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3 cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5IYW5uZXMsIHRoZSBBY2Nlc3MgVG9rZW4gYW5kIElEIFRva2VuIGRvIHF1aXRl IGRpZmZlcmVudCB0aGluZ3MgYW5kIGhhdmUgZGlmZmVyZW50IHN0cnVjdHVyZXMgYW5kIHByb3Bl cnRpZXMuJm5ic3A7IFRoZSBBY2Nlc3MgVG9rZW4gaXMgYW4gb3BhcXVlIHZhbHVlIHRoYXQNCiBn cmFudHMgYWNjZXNzIHRvIHJlc291cmNlcy4mbmJzcDsgQW4gSUQgVG9rZW4gaXMgYSBub24tb3Bh cXVlIEpXVCBzZWN1cml0eSB0b2tlbiB0aGF0IG1ha2VzIGNsYWltcyBhYm91dCB0aGUgYXV0aGVu dGljYXRpb24gdGhhdCBvY2N1cnJlZC4mbmJzcDsgWW91IGNhbiBoYXZlIG9uZSB3aXRob3V0IHRo ZSBvdGhlciBvciB5b3UgY2FuIGhhdmUgYm90aCwgZGVwZW5kaW5nIHVwb24gdGhlIHVzZSBjYXNl LiZuYnNwOyBUaHVzLCB0cnlpbmcgdG8gbW92ZSBpbmZvcm1hdGlvbiBiZXR3ZWVuDQogdGhlbSB3 b3VsZCBiZSBwcm9ibGVtYXRpYyBpbiBzZXZlcmFsIHJlZ2FyZHMuPGJyPg0KPGJyPg0KQWxzbywg dHJ5aW5nIHRvIG92ZXJsb2FkIHRoZSBBY2Nlc3MgVG9rZW4gdG8gY29udmV5IGF1dGhlbnRpY2F0 aW9uIGluZm9ybWF0aW9uIGhhcyBiZWVuIGRlbW9uc3RyYXRlZCBpbiBwcmFjdGljZSB0byBiZSBm cmF1Z2h0IHdpdGggcGVyaWwsIGFuZCBoYXMgcmVzdWx0ZWQgaW4gc29tZSBvZiB0aGUgbW9zdCBw cm9taW5lbnQgc2VjdXJpdHkgYnJlYWNoZXMgcmVsYXRlZCB0byB0aGUgbWlzdXNlIG9mIE9BdXRo Ljxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPGJyPg0KPGJyPg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBPQXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0g T24gQmVoYWxmIE9mIFBoaWwgSHVudDxicj4NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDA1LCAyMDE0 IDg6NTQgQU08YnI+DQpUbzogSGFubmVzIFRzY2hvZmVuaWc8YnI+DQpDYzogPGEgaHJlZj0ibWFp bHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBRdWVzdGlvbiByZWdhcmRpbmcgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0 Yzxicj4NCjxicj4NCllvdSBhcmUgY29ycmVjdC4gSnVzdCBhZGRpbmcgdG8gYWNjZXNzIHRva2Vu IHdvdWxkIG1ha2UgYSBsb3Qgb2YgZGV2cyBoYXBweSBhbmQgdGhhdCBjZXJ0YWlubHkgc2hvdWxk IGJlIGRpc2N1c3NlZC4NCjxicj4NCjxicj4NClR3byByZXF1aXJlbWVudHMgaXNzdWVzOjxicj4N Cjxicj4NCjEuIEEga2V5IHVzZSBjYXNlIGlzIHBhc3NpbmcgYXV0aCBjdHggb25seS4gQW4gYWNj ZXNzIHRva2VuIG1lYW5zIGFza2luZyBmb3IgY29uc2VudCB0byBhY2Nlc3Mgc29tZXRoaW5nLiBU aGlzIGNhdXNlcyBtYW55IHNpdGVzIHRvIGxvb3NlIG5ldyB1c2Vycy4gQXV0aGVuIG9ubHkgY2Fu IGJlIGltcGxpY2l0IGNvbnNlbnQuDQo8YnI+DQo8YnI+DQoyLiZuYnNwOyBDb21wYXRpYmlsaXR5 IHdpdGggT3BlbklkIElEIFRva2VuIGFuZCBmbG93cy4gPGJyPg0KPGJyPg0KMy4gVGhlcmUgaXMg YSBuZWVkIHRvIHN1cHBvcnQgcmUtYXV0aCBhbmQgTUZBL0xPQSBuZWdvdGlhdGlvbi4gRWcgd2Vi IHNpdGUgd291bGQgbGlrZSB0byBvYnRhaW4gYSBoaWdoZXIgbGV2ZWwgb2YgYXNzdXJhbmNlIGZv ciBhIGhpZ2hlciByaXNrIGFjdGlvbi4NCjxicj4NCjxicj4NClRoZSBub24tdGVjaCByZXF1aXJl bWVudCBpcyB0aGUgc29sbiBtdXN0IGJlIHJlY2VpdmVkIGJ5IGNsaWVudCBhbmQgc2VydmljZSBw cm92aWRlciBkZXZlbG9wZXJzIGFzIGVhc3kgdG8gaW1wbGVtZW50IGluIGFkZGl0aW9uIHRvIDY3 NDkgb3IgZXZlbiBPQXV0aCAxLjFhLiBJIG1lbnRpb24gaXQgYmVjYXVzZSBkZXZzIGZlZWwgdGhp cyBzaG91bGQgYmUgdHJpdmlhbC4mbmJzcDsgWW91ciBzdWdnZXN0aW9uIG9mIGFkZGluZyB0byBh Y2Nlc3MgdG9rZW4gY2VydGFpbmx5DQogZml0cyB0aGlzLiA8YnI+DQo8YnI+DQpQaGlsPGJyPg0K PGJyPg0KJmd0OyBPbiBKdW4gNSwgMjAxNCwgYXQgMDo0NCwgSGFubmVzIFRzY2hvZmVuaWcgJmx0 OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Ij5oYW5uZXMudHNjaG9m ZW5pZ0BnbXgubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIFBoaWws PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHRoYW5rcyBmb3IgcHJvZHVjaW5nIHRoaXMgZG9jdW1lbnQg d3JpdGUtdXAuIEkgaGF2ZSBhIHNvbWV3aGF0IGJhc2ljIDxicj4NCiZndDsgcXVlc3Rpb24gcmVn YXJkaW5nIHRoZSBkb2N1bWVudC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGlkIHRva2VuIGNv bnRhaW5zIHRoZSBmb2xsb3dpbmcgbWFuZGF0b3J5IGluZm9ybWF0aW9uOjxicj4NCiZndDsgLSBz aXM6IGlzc3Vlcjxicj4NCiZndDsgLSBzdWI6IHN1YmplY3Q8YnI+DQomZ3Q7IC0gYXVkOiBhdWRp ZW5jZTxicj4NCiZndDsgLSBpYXQ6IGlzc3VlZCBhdDxicj4NCiZndDsgLSBleHA6IGV4cGlyeTxi cj4NCiZndDsgLSBhdXRoX3RpbWU6IHRpbWUgd2hlbiB0aGUgZW5kIHVzZXIgd2FzIGF1dGhlbnRp Y2F0ZWQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgQW4gYWNjZXNzIHRva2VuICh3aGVuIGVuY29kZWQg YXMgYSBKV1QpIG1heSBjb250YWluIGFsbCB0aGVzZSBmaWVsZHMgPGJyPg0KJmd0OyBleGNlcHQg dGhlIGF1dGhfdGltZSAoc2luY2UgYXV0aF90aW1lIGlzIG5vdCBkZWZpbmVkIGluIHRoZSBKV1Qg c3BlYykuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEdpdmVuIHRoYXQgeW91ciBwcm9wb3NhbCBhY3R1 YWxseSBkb2VzIG5vdCBkZWZpbmUgdGhlIGF1dGhlbnRpY2F0aW9uIDxicj4NCiZndDsgcHJvdG9j b2wgdG8gYmUgdXNlZCBiZXR3ZWVuIHRoZSByZXNvdXJjZSBvd25lci9lbmQgdXNlciBhbmQgdGhl IDxicj4NCiZndDsgYXV0aG9yaXNhdGlvbiBzZXJ2ZXIgSSBhbSB3b25kZXJpbmcgd2hldGhlciBp dCB3b3VsZCBiZSBwb3NzaWJsZSB0byA8YnI+DQomZ3Q7IGp1c3QgYWRkIHRoZSBhdXRoX3RpbWUg cGFyYW1ldGVyIChhbmQgbWF5YmUgc29tZSBvZiB0aGUgb3B0aW9uYWwgPGJyPg0KJmd0OyBwYXJh bWV0ZXJzKSB0byB0aGUgYWNjZXNzIHRva2VuLiBUaGVuLCB5b3UgY2FuIHNraXAgdGhlIGlkIHRv a2VuLjxicj4NCiZndDsgPGJyPg0KJmd0OyBIb3cgZG8gSSBjb21lIHVwIHdpdGggdGhhdCBxdWVz dGlvbj8gSW4gS2VyYmVyb3MsIGZvciBleGFtcGxlLCB0aGUgPGJyPg0KJmd0OyBhYm92ZS1saXN0 ZWQgaW5mb3JtYXRpb24gaXMgY2FycmllZCB3aXRoaW4gYSBzaW5nbGUgY29udGFpbmVyICh3aXRo aW4gPGJyPg0KJmd0OyB0aGUgdGlja2V0KSBhbmQgc28gSSBhbSBjdXJpb3VzIHRvIGhlYXIgd2h5 IHdlIGhhdmUgdG8gc2VuZCB0aGUgPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiB0d2ljZSBpbiBPQXV0 aCAob25jZSBpbiB0aGUgYWNjZXNzIHRva2VuLCB3aGVuIHRoZSBpbmZvIGlzIDxicj4NCiZndDsg cGFzc2VkIHBlciB2YWx1ZSwgYW5kIGFnYWluIHZpYSB0aGUgaWQgdG9rZW4pLjxicj4NCiZndDsg PGJyPg0KJmd0OyBNYXliZSBJIG1pc3Npbmcgc29tZXRoaW5nIGltcG9ydGFudCBoZXJlLjxicj4N CiZndDsgPGJyPg0KJmd0OyBDaWFvPGJyPg0KJmd0OyBIYW5uZXM8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXYgaWQ9InlxdGZkMTE5ODAiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_16ef7d8f45ff463fa6d60b913a5a4053BLUPR03MB309namprd03pro_-- From nobody Thu Jun 5 12:52:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBBF1A02F9 for ; Thu, 5 Jun 2014 12:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rts_8oQi0pTv for ; Thu, 5 Jun 2014 12:52:48 -0700 (PDT) Received: from nm27-vm1.bullet.mail.bf1.yahoo.com (nm27-vm1.bullet.mail.bf1.yahoo.com [98.139.213.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF1B1A0341 for ; Thu, 5 Jun 2014 12:52:46 -0700 (PDT) Received: from [98.139.215.142] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jun 2014 19:52:39 -0000 Received: from [98.139.212.218] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jun 2014 19:52:39 -0000 Received: from [127.0.0.1] by omp1027.mail.bf1.yahoo.com with NNFMP; 05 Jun 2014 19:52:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 442671.1176.bm@omp1027.mail.bf1.yahoo.com Received: (qmail 53797 invoked by uid 60001); 5 Jun 2014 19:52:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401997959; bh=ud9IGminkcKyICLKHdbyDfNNze6AgOuBempM3Rr5uJU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=3FNpNrrg9o6uNpLlXwFe4BoheJb2RZwJOeZPf7ASK11nmJQqIL79Qa5of2G0fxEKzn1KosvkDFlFC1zdVkzS8dpuvz4aRDVjPuyunYzB3Ug79NZyR1hmOs5qOfrHSbQ5H56VH1l9fD0yuysSl5hOa3i1dq0OxBARoR72i8bB21E= X-YMail-OSG: IllTFmMVM1lzKdh0gA_rq7o6Ngq0wqTScMFb5Ep42.JUTPN bCcsCqSfWaOB55Kw1jYXUkdTRDLEqwSi0kA51UAPv.tmoWpOHOzPg7w3IcL_ _CYyDJuDVS4v4SAukkgOZ7z6W4bLkxb2fq2nT4sC7Wz4BxUlFUdoMLWGRj5Y iV5NX5rxmYOGLu.MBnse9DPGuLimQIbEAltFWqxX6BenTF2iPzo5K4RINBAB iePdD8QgyWxmABhAyQDcBOS6c53nsTDIvmfEFvL_cTdtVuXGSecBPkzY7YuR c2khMNqOuA6EwgDSeVYgA8SVvabL5vOYPlHdsfnFVUqxofMqM73RgDFWyLWF ws59Wh3VrrR4wCQw.uwptvJvNv1dDDGuWGqQ1IBbgT7f3Io72CumTCnmV82l a9z3yFDY483z9rWTgN0CANanhf2DC97jfZcVtSDl5RF4usYmwy2qIOuKgUUN qCRAgkeU1z2iOi6vV3mVBMopnpycT0w8BFU7i7fiXn5Ikt5oG6Z.Y4F0jHlD AROZuPgft2Rjc57OOZ0e.QuaYaz1tWFFSFYKL1g3StEDyA_mYxxgUMV84Sg- - Received: from [209.131.62.113] by web142801.mail.bf1.yahoo.com via HTTP; Thu, 05 Jun 2014 12:52:39 PDT X-Rocket-MIMEInfo: 002.001, SWYgeW91IG5lZWQgdXNlciBpbmZvIGJhc2VkIG9uIGFuIGFjY2VzcyB0b2tlbiB0aGUgaW50cm9zcGVjdGlvbiBlbmRwb2ludCBpcyB0aGUgcmlnaHQgd2F5IHRvIGdvLiDCoEV2ZW4gc28sIHRoZXJlJ3MgaXNzdWVzIHdpdGggdXNpbmcgYW4gYWNjZXNzIHRva2VuIGFzIGFuIGF1dGhlbnRpY2F0b3IgYW5kIHRoaXMgaXMgYSBtYWpvciByZWFzb24gd2h5IE9wZW5JRCBpcyB0aGUgcmlnaHQgd2F5IHRvIGdvIGZvciBhdXRobi4KCgpPbiBUaHVyc2RheSwgSnVuZSA1LCAyMDE0IDEyOjQyIFBNLCBBbnRob255IE4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.190.668 References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> <482eb1c40dbb4da08dfb0d64879fac70@BLUPR03MB309.namprd03.prod.outlook.com> Message-ID: <1401997959.33382.YahooMailNeo@web142801.mail.bf1.yahoo.com> Date: Thu, 5 Jun 2014 12:52:39 -0700 (PDT) From: Bill Mills To: Anthony Nadalin , Torsten Lodderstedt In-Reply-To: <482eb1c40dbb4da08dfb0d64879fac70@BLUPR03MB309.namprd03.prod.outlook.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="469468616-228986169-1401997959=:33382" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/59uyRWWAO12LDyjPjmyxuEBvpb8 Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:52:51 -0000 --469468616-228986169-1401997959=:33382 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If you need user info based on an access token the introspection endpoint i= s the right way to go. =C2=A0Even so, there's issues with using an access t= oken as an authenticator and this is a major reason why OpenID is the right= way to go for authn.=0A=0A=0AOn Thursday, June 5, 2014 12:42 PM, Anthony N= adalin wrote:=0A =0A=0A=0AIt=E2=80=99s great but so= me ways but also very limiting if you are counting on certain requirements = to be represented in the access token=0A=C2=A0=0AFrom:OAuth [mailto:oauth-b= ounces@ietf.org] On Behalf Of Torsten Lodderstedt=0ASent: Thursday, June 5,= 2014 12:40 PM=0ATo: Bill Mills=0ACc: Phil Hunt; oauth@ietf.org=0ASubject: = Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c=0A=C2=A0=0A+= 1=0A=C2=A0=0Athe access token is opaque to the client. That's great! Let's = keep it that way.=0A=0AAm 05.06.2014 um 21:20 schrieb Bill Mills :=0ACan't agree more with the peril of overloading auth infor= mation into an access token.=0A>=C2=A0=0A>On Thursday, June 5, 2014 11:05 A= M, Mike Jones wrote:=0A>=C2=A0=0A>Hannes, the= Access Token and ID Token do quite different things and have different str= uctures and properties.=C2=A0 The Access Token is an opaque value that gran= ts access to resources.=C2=A0 An ID Token is a non-opaque JWT security toke= n that makes claims about the authentication that occurred.=C2=A0 You can h= ave one without the other or you can have both, depending upon the use case= .=C2=A0 Thus, trying to move information between them would be problematic = in several regards.=0A>=0A>Also, trying to overload the Access Token to con= vey authentication information has been demonstrated in practice to be frau= ght with peril, and has resulted in some of the most prominent security bre= aches related to the misuse of OAuth.=0A>=0A>=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 -- Mike=0A>=0A>-----Origina= l Message-----=0A>From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of = Phil Hunt=0A>Sent: Thursday, June 05, 2014 8:54 AM=0A>To: Hannes Tschofenig= =0A>Cc: oauth@ietf.org=0A>Subject: Re: [OAUTH-WG] Question regarding draft-= hunt-oauth-v2-user-a4c=0A>=0A>You are correct. Just adding to access token = would make a lot of devs happy and that certainly should be discussed. =0A>= =0A>Two requirements issues:=0A>=0A>1. A key use case is passing auth ctx o= nly. An access token means asking for consent to access something. This cau= ses many sites to loose new users. Authen only can be implicit consent. =0A= >=0A>2.=C2=A0 Compatibility with OpenId ID Token and flows. =0A>=0A>3. Ther= e is a need to support re-auth and MFA/LOA negotiation. Eg web site would l= ike to obtain a higher level of assurance for a higher risk action. =0A>=0A= >The non-tech requirement is the soln must be received by client and servic= e provider developers as easy to implement in addition to 6749 or even OAut= h 1.1a. I mention it because devs feel this should be trivial.=C2=A0 Your s= uggestion of adding to access token certainly=0A fits this. =0A>=0A>Phil=0A= >=0A>> On Jun 5, 2014, at 0:44, Hannes Tschofenig wrote:=0A>> =0A>> Hi Phil,=0A>> =0A>> thanks for producing this document= write-up. I have a somewhat basic =0A>> question regarding the document.= =0A>> =0A>> The id token contains the following mandatory information:=0A>>= - sis: issuer=0A>> - sub: subject=0A>> - aud: audience=0A>> - iat: issued = at=0A>> - exp: expiry=0A>> - auth_time: time when the end user was authenti= cated=0A>> =0A>> An access token (when encoded as a JWT) may contain all th= ese fields =0A>> except the auth_time (since auth_time is not defined in th= e JWT spec).=0A>> =0A>> Given that your proposal actually does not define t= he authentication =0A>> protocol to be used between the resource owner/end = user and the =0A>> authorisation server I am wondering whether it would be = possible to =0A>> just add the auth_time parameter (and maybe some of the o= ptional =0A>> parameters) to the access token. Then, you can skip the id to= ken.=0A>> =0A>> How do I come up with that question? In Kerberos, for examp= le, the =0A>> above-listed information is carried within a single container= (within =0A>> the ticket) and so I am curious to hear why we have to send = the =0A>> information twice in OAuth (once in the access token, when the in= fo is =0A>> passed per value, and again via the id token).=0A>> =0A>> Maybe= I missing something important here.=0A>> =0A>> Ciao=0A>> Hannes=0A>> =0A>>= =0A>=0A>_______________________________________________=0A>OAuth mailing l= ist=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>=C2=A0= =0A_______________________________________________=0A>OAuth mailing list=0A= >OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth --469468616-228986169-1401997959=:33382 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If you need user info based on an access token the= introspection endpoint is the right way to go.  Even so, there's issu= es with using an access token as an authenticator and this is a major reaso= n why OpenID is the right way to go for authn.


On Thursday, June 5, 2014 12:42 PM, Anthony Nadalin <tonynad= @microsoft.com> wrote:


It=92s great but some ways but also very = limiting if you are counting on certain requirements to be represented = in the access token
=20
=  
=20
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Thursday, June 5, 2014 12:40 PM
To: Bill Mills
Cc: Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding = draft-hunt-oauth-v2-user-a4c
=20
 
=20
+1
=20
 
=20
the access token is opaque to the = client. That's great! Let's keep it that way.
=20

Am 05.06.2014 um 21:20 schrieb Bill Mills <wmills_92105@yahoo.com>:=20
Can't agree more with the peril of overloading auth = information into an access token.
=20
=  
=20
On Thursday, June 5, 2014 11:05 AM, Mike = Jones <Michael.Jones@microsoft.com> wrote:
=20
=  
=20
Hannes, the Access Token and ID Token do quite different = things and have different structures and properties.  The Access = Token is an opaque value that grants access to resources.  An ID Token is a non-opaque JWT = security token that makes claims about the authentication that = occurred.  You can have one without the other or you can have both, = depending upon the use case.  Thus, trying to move information = between them would be problematic in several regards.

Also, trying to overload the Access Token to convey authentication = information has been demonstrated in practice to be fraught with peril, = and has resulted in some of the most prominent security breaches related = to the misuse of OAuth.

            =     -- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On = Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding = draft-hunt-oauth-v2-user-a4c

You are correct. Just adding to access token would make a lot of devs = happy and that certainly should be discussed.

Two requirements issues:

1. A key use case is passing auth ctx only. An access token means asking = for consent to access something. This causes many sites to loose new = users. Authen only can be implicit consent.

2.  Compatibility with OpenId ID Token and flows.
=
3. There is a need to support re-auth and MFA/LOA negotiation. Eg web = site would like to obtain a higher level of assurance for a higher risk = action.

The non-tech requirement is the soln must be received by client and = service provider developers as easy to implement in addition to 6749 or = even OAuth 1.1a. I mention it because devs feel this should be = trivial.  Your suggestion of adding to access token certainly fits this.

Phil

> On Jun 5, 2014, at 0:44, Hannes Tschofenig <hannes.tschofenig@gmx.net>= ; wrote:
>
> Hi Phil,
>
> thanks for producing this document write-up. I have a somewhat = basic
> question regarding the document.
>
> The id token contains the following mandatory information:
> - sis: issuer
> - sub: subject
> - aud: audience
> - iat: issued at
> - exp: expiry
> - auth_time: time when the end user was authenticated
>
> An access token (when encoded as a JWT) may contain all these = fields
> except the auth_time (since auth_time is not defined in the JWT = spec).
>
> Given that your proposal actually does not define the = authentication
> protocol to be used between the resource owner/end user and the
> authorisation server I am wondering whether it would be possible to =
> just add the auth_time parameter (and maybe some of the optional =
> parameters) to the access token. Then, you can skip the id = token.
>
> How do I come up with that question? In Kerberos, for example, the =
> above-listed information is carried within a single container = (within
> the ticket) and so I am curious to hear why we have to send the
> information twice in OAuth (once in the access token, when the info = is
> passed per value, and again via the id token).
>
> Maybe I missing something important here.
>
> Ciao
> Hannes
>
>

_______________________________________________
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


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

= --Apple-Mail=_B52BDCEC-684B-4ABA-8B1C-379F053AEEF0-- From nobody Thu Jun 5 13:12:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F6B1A0305 for ; Thu, 5 Jun 2014 13:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH5yaw-bwOkR for ; Thu, 5 Jun 2014 13:12:43 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5F31A0361 for ; Thu, 5 Jun 2014 13:12:01 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id i50so2468648qgf.17 for ; Thu, 05 Jun 2014 13:11:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=yvGVdwHcIK+E7Jxbn8A3Pv3KLYAUAKD3/an2rrFGPws=; b=Pn7je795kMeob1daK+ysl/wOxa9h1y8GMVIw72J/BcgQI2J92bUNqfELHbvmHE20/8 kO2GhEzsnPMQtPsxr0TG1mfipjdDpFIrlpYvbyqt1URkt04oyAE2ipRx1sjfz2ujjjYC aK3SWBlXsk6TFzNL3kNmMpeCg0m10QmxJtnOSihLtibPiCX/c/gCAYb3rkjzpGf6Owb5 Ems4avNfNDrSMWotIbqPWcLpwRxlIVPK0U5IPy0UbqYLh8Nf4i3iC3NFiIn62jwEs2Kh ZSu+sXvjZ3wP6WlKHb5olhcmxuzhmpCUN5VL7EgXWw54GQnBVll7yUd2DJlcysBEV1xX ZluQ== X-Gm-Message-State: ALoCoQnMLafxbHAen7ThgOB4YOk2wfqOa3bv/izfSNn22Z5O8dUHww+pDo2hhoreI/DKYQdTImu0 X-Received: by 10.229.220.197 with SMTP id hz5mr85767691qcb.9.1401999114564; Thu, 05 Jun 2014 13:11:54 -0700 (PDT) Received: from [192.168.0.200] ([201.188.62.227]) by mx.google.com with ESMTPSA id w105sm4368739qgd.22.2014.06.05.13.11.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 13:11:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Thu, 5 Jun 2014 16:11:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <82451287-4FF0-456C-AC2B-84CB6823E46E@ve7jtb.com> References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> To: Michael Jones X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/BR6mVI8a2gnyWuxbdURAHMCWJTg Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:12:45 -0000 Looking at the latest draft = http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-03 it is better. As far as I can see he deltas from Connect Basic profile are: 1 A new response_type "code_id_token" (I think the similarity to the = "code id_token" response_type may cause some confusion but that can be = sorted out.)=20 2 a new request parameter "min_alv" (I think min_alv=3D"2" is = isomorphic to acr_values=3D"4 3 2" so having 2 ways to make the same = request may not be ideal, but that can be debated.) In Connect we probably would have added a way to get id_token only from = the token endpoint but RFC6849 requires a access token be issued for a = grant_type of authorization_code. I think to be consistent with RFC6849 a new grant type needs to be = defined. In previous discussions returning a access token with no scopes was = considered easier than trying to explain a OAuth flow with no access = token.=20 This needs discussion. Other than that Mike has done a good job of reconciling a4c with Connect = Basic profile. This spec on it's own would not allow you to do any sort of scalable = SSO, as the trust model is unspecified other than trusting the JWT based = on the TLS cert of the token endpoint. I think there needs to be some validation of issuer if there is more = than one the client is dealing with.=20 It is Shorter than Connect basic because it leaves out interoperating = with multiple IdP and user attributes. I don't hate it, but don't know that it adds much, other than possible = confusion and future extensions that are incompatible with Connect. It is however better than it was. John B. On Jun 5, 2014, at 1:46 PM, Mike Jones = wrote: > Hannes, the Access Token and ID Token do quite different things and = have different structures and properties. The Access Token is an opaque = value that grants access to resources. An ID Token is a non-opaque JWT = security token that makes claims about the authentication that occurred. = You can have one without the other or you can have both, depending upon = the use case. Thus, trying to move information between them would be = problematic in several regards. >=20 > Also, trying to overload the Access Token to convey authentication = information has been demonstrated in practice to be fraught with peril, = and has resulted in some of the most prominent security breaches related = to the misuse of OAuth. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Thursday, June 05, 2014 8:54 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Question regarding = draft-hunt-oauth-v2-user-a4c >=20 > You are correct. Just adding to access token would make a lot of devs = happy and that certainly should be discussed.=20 >=20 > Two requirements issues: >=20 > 1. A key use case is passing auth ctx only. An access token means = asking for consent to access something. This causes many sites to loose = new users. Authen only can be implicit consent.=20 >=20 > 2. Compatibility with OpenId ID Token and flows.=20 >=20 > 3. There is a need to support re-auth and MFA/LOA negotiation. Eg web = site would like to obtain a higher level of assurance for a higher risk = action.=20 >=20 > The non-tech requirement is the soln must be received by client and = service provider developers as easy to implement in addition to 6749 or = even OAuth 1.1a. I mention it because devs feel this should be trivial. = Your suggestion of adding to access token certainly fits this.=20 >=20 > Phil >=20 >> On Jun 5, 2014, at 0:44, Hannes Tschofenig = wrote: >>=20 >> Hi Phil, >>=20 >> thanks for producing this document write-up. I have a somewhat basic=20= >> question regarding the document. >>=20 >> The id token contains the following mandatory information: >> - sis: issuer >> - sub: subject >> - aud: audience >> - iat: issued at >> - exp: expiry >> - auth_time: time when the end user was authenticated >>=20 >> An access token (when encoded as a JWT) may contain all these fields=20= >> except the auth_time (since auth_time is not defined in the JWT = spec). >>=20 >> Given that your proposal actually does not define the authentication=20= >> protocol to be used between the resource owner/end user and the=20 >> authorisation server I am wondering whether it would be possible to=20= >> just add the auth_time parameter (and maybe some of the optional=20 >> parameters) to the access token. Then, you can skip the id token. >>=20 >> How do I come up with that question? In Kerberos, for example, the=20 >> above-listed information is carried within a single container (within=20= >> the ticket) and so I am curious to hear why we have to send the=20 >> information twice in OAuth (once in the access token, when the info = is=20 >> passed per value, and again via the id token). >>=20 >> Maybe I missing something important here. >>=20 >> Ciao >> Hannes >>=20 >>=20 >=20 > _______________________________________________ > 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 nobody Thu Jun 5 13:19:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8363F1A02CE for ; Thu, 5 Jun 2014 13:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G06-DFL4jfHF for ; Thu, 5 Jun 2014 13:19:22 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E8F1A018E for ; Thu, 5 Jun 2014 13:19:21 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q108so2535126qgd.13 for ; Thu, 05 Jun 2014 13:19:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=iNCKOGEScYaa7M+iYI1GYftvD2FVkGFKGyv03KqtbpY=; b=IOyMP9WPrRKBL4kDauBOn/v9mzGPHShczCrZs2dZpy0QkdPZ5CTXqHy/aDmHVIREnj 26HEjyu951LElL3LMH0FKPMmX1+NmyPigKww0jxxDb0idYFlCJqBjUthPLCilsjMfQHZ wVAL+t28XBcW+DN7Tee/kArrUzpU0CqOvgeH/Mai8SMgtQoKKDKyyUTlZpc49/Vw2p96 7rsVA/xh9ZbH0bVNBdcuadjS5H+Xro1hzk/V8rB3+R3ZWfkZVnF8W7wr4k1p9IrfEIdC xgb6rEeNUbzhmCY9dVB3VAv+SUsnAGfpgcM6gOo0JKT8eiNP7e2mSAYiXzhG+ULJvApZ Ba+A== X-Gm-Message-State: ALoCoQkhfX8d/B8Qls/p+keG0X7lf1Wu4RffQ64kYi0X6CGY0bq8MAlwaAIXweVbBIXtn8qrKqsb X-Received: by 10.224.165.148 with SMTP id i20mr21362778qay.41.1401999554859; Thu, 05 Jun 2014 13:19:14 -0700 (PDT) Received: from [192.168.0.200] ([201.188.62.227]) by mx.google.com with ESMTPSA id a41sm4385953qgf.3.2014.06.05.13.19.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 13:19:14 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D3C67CF-0251-435E-9A7C-5277398708B1" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Bradley In-Reply-To: <16ef7d8f45ff463fa6d60b913a5a4053@BLUPR03MB309.namprd03.prod.outlook.com> Date: Thu, 5 Jun 2014 16:19:09 -0400 Message-Id: <7C84F640-ABC2-4838-9A01-91167167C84F@ve7jtb.com> References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> <482eb1c40dbb4da08dfb0d64879fac70@BLUPR03MB309.namprd03.prod.outlook.com> <16ef7d8f45ff463fa6d60b913a5a4053@BLUPR03MB309.namprd03.prod.outlook.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/s7vby5xBzS2gI7bTdBzQ5PhYwLY Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:19:24 -0000 --Apple-Mail=_1D3C67CF-0251-435E-9A7C-5277398708B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Using structured access tokens to do delegation or convey other claims = to the RS can and should be separate from the assertions delivered to = the client. The tokens will have different audiences and if using Proof of = Possession different presenter key material. Using one token for both things may work in the simplest use case but = breaks a lot of things in OAuth. John B. On Jun 5, 2014, at 3:47 PM, Anthony Nadalin = wrote: > Delegation > =20 > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 > Sent: Thursday, June 5, 2014 12:45 PM > To: Anthony Nadalin > Cc: Bill Mills; Phil Hunt; oauth@ietf.org > Subject: Re: [OAUTH-WG] Question regarding = draft-hunt-oauth-v2-user-a4c > =20 > Examples? >=20 > Am 05.06.2014 um 21:42 schrieb Anthony Nadalin = : >=20 > It=92s great but some ways but also very limiting if you are counting = on certain requirements to be represented in the access token > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten = Lodderstedt > Sent: Thursday, June 5, 2014 12:40 PM > To: Bill Mills > Cc: Phil Hunt; oauth@ietf.org > Subject: Re: [OAUTH-WG] Question regarding = draft-hunt-oauth-v2-user-a4c > =20 > +1 > =20 > the access token is opaque to the client. That's great! Let's keep it = that way. >=20 > Am 05.06.2014 um 21:20 schrieb Bill Mills : >=20 > Can't agree more with the peril of overloading auth information into = an access token. > =20 >=20 > On Thursday, June 5, 2014 11:05 AM, Mike Jones = wrote: > =20 >=20 > Hannes, the Access Token and ID Token do quite different things and = have different structures and properties. The Access Token is an opaque = value that grants access to resources. An ID Token is a non-opaque JWT = security token that makes claims about the authentication that occurred. = You can have one without the other or you can have both, depending upon = the use case. Thus, trying to move information between them would be = problematic in several regards. >=20 > Also, trying to overload the Access Token to convey authentication = information has been demonstrated in practice to be fraught with peril, = and has resulted in some of the most prominent security breaches related = to the misuse of OAuth. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Thursday, June 05, 2014 8:54 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Question regarding = draft-hunt-oauth-v2-user-a4c >=20 > You are correct. Just adding to access token would make a lot of devs = happy and that certainly should be discussed.=20 >=20 > Two requirements issues: >=20 > 1. A key use case is passing auth ctx only. An access token means = asking for consent to access something. This causes many sites to loose = new users. Authen only can be implicit consent.=20 >=20 > 2. Compatibility with OpenId ID Token and flows.=20 >=20 > 3. There is a need to support re-auth and MFA/LOA negotiation. Eg web = site would like to obtain a higher level of assurance for a higher risk = action.=20 >=20 > The non-tech requirement is the soln must be received by client and = service provider developers as easy to implement in addition to 6749 or = even OAuth 1.1a. I mention it because devs feel this should be trivial. = Your suggestion of adding to access token certainly fits this.=20 >=20 > Phil >=20 > > On Jun 5, 2014, at 0:44, Hannes Tschofenig = wrote: > >=20 > > Hi Phil, > >=20 > > thanks for producing this document write-up. I have a somewhat basic=20= > > question regarding the document. > >=20 > > The id token contains the following mandatory information: > > - sis: issuer > > - sub: subject > > - aud: audience > > - iat: issued at > > - exp: expiry > > - auth_time: time when the end user was authenticated > >=20 > > An access token (when encoded as a JWT) may contain all these fields=20= > > except the auth_time (since auth_time is not defined in the JWT = spec). > >=20 > > Given that your proposal actually does not define the authentication=20= > > protocol to be used between the resource owner/end user and the=20 > > authorisation server I am wondering whether it would be possible to=20= > > just add the auth_time parameter (and maybe some of the optional=20 > > parameters) to the access token. Then, you can skip the id token. > >=20 > > How do I come up with that question? In Kerberos, for example, the=20= > > above-listed information is carried within a single container = (within=20 > > the ticket) and so I am curious to hear why we have to send the=20 > > information twice in OAuth (once in the access token, when the info = is=20 > > passed per value, and again via the id token). > >=20 > > Maybe I missing something important here. > >=20 > > Ciao > > Hannes > >=20 > >=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_1D3C67CF-0251-435E-9A7C-5277398708B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Using = structured access tokens to do delegation or convey other claims to the = RS can and should be separate from the assertions delivered to the = client.

The tokens will have different audiences and = if using Proof of Possession different presenter key = material.

Using one token for both things may = work in the simplest use case but breaks a lot of things in = OAuth.

John B.

On Jun = 5, 2014, at 3:47 PM, Anthony Nadalin <tonynad@microsoft.com> = wrote:

Delegation
From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net= ] 
Sent: Thursday, June 5, 2014 = 12:45 PM
To: Anthony = Nadalin
Cc: Bill Mills; Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Question = regarding = draft-hunt-oauth-v2-user-a4c
 
Examples?


Am 05.06.2014 um 21:42 schrieb Anthony Nadalin = <tonynad@microsoft.com>:

It=92s great but some ways but = also very limiting if you are counting on certain requirements to be = represented in the access token
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten = Lodderstedt
Sent: Thursday, June 5, 2014 = 12:40 PM
To: Bill = Mills
Cc: Phil= Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Question = regarding = draft-hunt-oauth-v2-user-a4c
 
+1
 
the = access token is opaque to the client. That's great! Let's keep it that = way.


Am 05.06.2014 um 21:20 schrieb Bill Mills <wmills_92105@yahoo.com>:

Can't agree more with the peril of overloading = auth information into an access = token.

 

On Thursday, June 5, 2014 11:05 = AM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

 

Hannes, the Access Token and ID Token do quite = different things and have different structures and properties.  The = Access Token is an opaque value that grants access to resources.  = An ID Token is a non-opaque JWT security token that makes claims about = the authentication that occurred.  You can have one without the = other or you can have both, depending upon the use case.  Thus, = trying to move information between them would be problematic in several = regards.

Also, trying to overload the Access Token to convey = authentication information has been demonstrated in practice to be = fraught with peril, and has resulted in some of the most prominent = security breaches related to the misuse of = OAuth.

            =     -- Mike

-----Original Message-----
From: = OAuth [mailto:oauth-bounces@ietf.org] On = Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: = Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question = regarding draft-hunt-oauth-v2-user-a4c

You are correct. Just = adding to access token would make a lot of devs happy and that certainly = should be discussed. 

Two requirements = issues:

1. A key use case is passing auth ctx only. An access = token means asking for consent to access something. This causes many = sites to loose new users. Authen only can be implicit consent. 

2.  = Compatibility with OpenId ID Token and flows. 

3. There is a need = to support re-auth and MFA/LOA negotiation. Eg web site would like to = obtain a higher level of assurance for a higher risk action. 

The non-tech = requirement is the soln must be received by client and service provider = developers as easy to implement in addition to 6749 or even OAuth 1.1a. = I mention it because devs feel this should be trivial.  Your = suggestion of adding to access token certainly fits this. 

Phil

> On = Jun 5, 2014, at 0:44, Hannes Tschofenig <hannes.tschofenig@gmx.net> = wrote:
> 
> = Hi Phil,
> 
> thanks for = producing this document write-up. I have a somewhat basic 
> question regarding = the document.
> 
> The id token = contains the following mandatory information:
> - sis: = issuer
> - sub: subject
> - aud: audience
> - iat: = issued at
> - exp: expiry
> - auth_time: time when the end = user was authenticated
> 
> An access token = (when encoded as a JWT) may contain all these fields 
> except the = auth_time (since auth_time is not defined in the JWT spec).
> 
> Given that your = proposal actually does not define the authentication 
> protocol to be = used between the resource owner/end user and the 
> authorisation = server I am wondering whether it would be possible to 
> just add the = auth_time parameter (and maybe some of the optional 
> parameters) to the = access token. Then, you can skip the id token.
> 
> How do I come up = with that question? In Kerberos, for example, the 
> above-listed = information is carried within a single container (within 
> the ticket) and so = I am curious to hear why we have to send the 
> information twice = in OAuth (once in the access token, when the info is 
> passed per value, = and again via the id token).
> 
> Maybe I missing = something important here.
> 
> Ciao
> = Hannes
> 
> 

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


_______________________________________________
OA= uth 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=_1D3C67CF-0251-435E-9A7C-5277398708B1-- From nobody Mon Jun 9 09:17:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F741A01D0 for ; Mon, 9 Jun 2014 09:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKaPlStIn4uz for ; Mon, 9 Jun 2014 09:17:44 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F05A1A00DE for ; Mon, 9 Jun 2014 09:17:43 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so3194053lab.2 for ; Mon, 09 Jun 2014 09:17:42 -0700 (PDT) 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=acKGxyfROSEJ8hCCXttMCr0wrNe/AL1ImBs2tUWzf40=; b=xioQBx61xhlrnULO6NF1r16PtlVNDkgnh3GO7WRRPYGwwlljo/DbzHko1chSwQabf/ bQ5qfDBooYIeSZi1AFyJ2idQXX9pM6WcwlMVCwtYAMa3iGKzNAon81TzhGd93wQ9/Emy qdQIA1zlUJTP1btGzc56/Ohrbq/VlEMoFsjH/RKabDyADCE+ru/MaahIGp1Gj+WmW3MK O5tg/IKzT0AfBUTkTaFRBvE/6ue7agU5x3tqqamHKGbS6m9UGzKffX3DajBnjo1ac0jF eeRhImF+z0o3f5jqk3WEdmwTa/8WYFMNqkryCfjhyxEK+48DWtdmhhepAPKHFDaRmSmW Pb7Q== MIME-Version: 1.0 X-Received: by 10.152.246.11 with SMTP id xs11mr2002108lac.73.1402330662492; Mon, 09 Jun 2014 09:17:42 -0700 (PDT) Received: by 10.112.33.36 with HTTP; Mon, 9 Jun 2014 09:17:42 -0700 (PDT) Date: Mon, 9 Jun 2014 12:17:42 -0400 Message-ID: From: Kathleen Moriarty To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11341e16fee01d04fb698c89 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Rx1R74R0oREhDg-M1TzgN1A22rI Subject: [OAUTH-WG] JWT review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:17:46 -0000 --001a11341e16fee01d04fb698c89 Content-Type: text/plain; charset=UTF-8 Hello, I am in process of working through the JOSE drafts and also read the Oauth JWT draft last week. There is some overlap in text that may require some joint work to correct. 1. For JWT, the Security Considerations section starts off with the same text that is in several of the JOSE drafts. In my review of the JWA draft, I asked for some fixes that will need to be made to this draft as well. Here is a link to that review and it may be easier to help with this work in one spot where text will be reused. Mike has asked the JOSE WG to assist, but it make make sense for Oauth folks to help as well. If it makes sense, a pointer to existing text is also fine. http://www.ietf.org/mail-archive/web/jose/current/msg04064.html 2. Sections 5.1 and 5.2 are a little confusing. However, the use of "typ" and "cty" appear in 3 drafts (at least), so this should get addressed with an approach that considers the joint text to reduce confusion for developers. The initial descriptions are in the JOSE JWS draft, so that may need most of the work, but it also appears in this draft and the JOSE JWK draft. In my writeup for the JWK review, I listed out some questions and would like to see improvements across these drafts. This will likely require some joint work and may be best in response to the JWK review to keep it in one place. http://www.ietf.org/mail-archive/web/jose/current/msg04172.html Thank you! -- Best regards, Kathleen --001a11341e16fee01d04fb698c89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I am in process of working throu= gh the JOSE drafts and also read the Oauth JWT draft last week. =C2=A0There= is some overlap in text that may require some joint work to correct.
=

1. For JWT, the Security Considerations section starts off w= ith the same text that is in several of the JOSE drafts. =C2=A0In my review= of the JWA draft, I asked for some fixes that will need to be made to this= draft as well. =C2=A0Here is a link to that review and it may be easier to= help with this work in one spot where text will be reused. =C2=A0Mike has = asked the JOSE WG to assist, but it make make sense for Oauth folks to help= as well. =C2=A0If it makes sense, a pointer to existing text is also fine.=


2. Sections 5.1 and 5.2 are a little= confusing. =C2=A0However, the use of "typ" and "cty" a= ppear in 3 drafts (at least), so this should get addressed with an approach= that considers the joint text to reduce confusion for developers. =C2=A0Th= e initial descriptions are in the JOSE JWS draft, so that may need most of = the work, but it also appears in this draft and the JOSE JWK draft. =C2=A0I= n my writeup for the JWK review, I listed out some questions and would like= to see improvements across these drafts. =C2=A0This will likely require so= me joint work and may be best in response to the JWK review to keep it in o= ne place.


Thank you!
--

Best regards,
Kathleen
--001a11341e16fee01d04fb698c89-- From nobody Mon Jun 9 17:34:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB7F1A02BB for ; Mon, 9 Jun 2014 17:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFwQne6ocP2j for ; Mon, 9 Jun 2014 17:34:47 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DEFA1A0277 for ; Mon, 9 Jun 2014 17:34:47 -0700 (PDT) Received: from BLUPR03CA033.namprd03.prod.outlook.com (10.141.30.26) by BLUPR03MB051.namprd03.prod.outlook.com (10.255.209.151) with Microsoft SMTP Server (TLS) id 15.0.959.15; Tue, 10 Jun 2014 00:34:45 +0000 Received: from BL2FFO11FD041.protection.gbl (2a01:111:f400:7c09::193) by BLUPR03CA033.outlook.office365.com (2a01:111:e400:879::26) with Microsoft SMTP Server (TLS) id 15.0.959.15 via Frontend Transport; Tue, 10 Jun 2014 00:34:46 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD041.mail.protection.outlook.com (10.173.161.137) with Microsoft SMTP Server (TLS) id 15.0.959.15 via Frontend Transport; Tue, 10 Jun 2014 00:34:45 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.173]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0195.002; Tue, 10 Jun 2014 00:34:20 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Proposed Security Considerations sections changes Thread-Index: Ac+EQ2lM0VqSCjLmSCeGa5cl2iPWvwAABMDg Date: Tue, 10 Jun 2014 00:34:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD6435E@TK5EX14MBXC292.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD6435ETK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438001)(199002)(189002)(377454003)(104016001)(2656002)(31966008)(74502001)(512954002)(15202345003)(99396002)(46102001)(86612001)(33656002)(4396001)(81156002)(71186001)(74662001)(87936001)(21056001)(79102001)(64706001)(20776003)(76482001)(16236675004)(55846006)(15843345004)(83322001)(19580405001)(44976005)(68736004)(69596002)(54356999)(50986999)(6806004)(97736001)(85806002)(84326002)(19625215002)(81342001)(92566001)(15975445006)(86362001)(84676001)(92726001)(85852003)(83072002)(19580395003)(81542001)(80022001)(26826002)(66066001)(77982001)(19300405004); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB051; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0238AEEDB0 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/NQ7T7wYSxYUwsvjvSRD0Prk4YJA Subject: [OAUTH-WG] FW: Proposed Security Considerations sections changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 00:34:50 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD6435ETK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Also forwarding this to the OAuth WG, given Kathleen's comments on the JWT = security considerations section. (However, please conduct discussions abou= t the JOSE text on the jose@ietf.org list and only re= ply here if you are proposing a change to the JWT security considerations s= ection.) -- Mike From: Mike Jones Sent: Monday, June 09, 2014 5:32 PM To: jose@ietf.org Cc: Kathleen Moriarty Subject: Proposed Security Considerations sections changes In response to Kathleen's requests to beef up the security considerations s= ections, I propose the following 9 actions: 1. In the JWE spec, add the heading "11.1. Adaptive Chosen-Ciphertext Atta= cks" before the Security Considerations text beginning: When decrypting, particular care must be taken not to allow the JWE recipient to be used as an oracle for decrypting messages. 2. At the end of the JWE Security Considerations, add the text: 11.2. Timing Attacks To mitigate the timing attacks described in RFC 3218 [RFC3218], the recipient MUST NOT distinguish between format, padding, and length errors of encrypted keys. It is strongly recommended, in the event of receiving an improperly formatted key, that the receiver substitute a randomly generated CEK and proceed to the next step, to mitigate timing attacks. 3. Remove the text from step 2 above from the place it occurs earlier (in = JWE Section 5.2, step 10), and instead reference the security consideration= s text there. 4. Add JWA Security Considerations subsections on "Adaptive Chosen-Ciphert= ext Attacks" and "Timing Attacks", which reference the JWE subsections (rat= her duplicating the text in JWA). 5. In the JWK spec, add the heading "8.1. Key Provenance and Trust" before= the security considerations text beginning: One should place no more trust in the data associated with a key than in than the method by which it was obtained and in the trustworthiness of the entity asserting an association with the key. 6. In the JWK spec, add the heading "8.2. Preventing Disclosure of Non-Pub= lic Key Information" before the security considerations text beginning: Private and symmetric keys MUST be protected from disclosure to unintended parties. 7. In the JWK spec, replace the current text citing XML DSIG 2.0 with the = following and move it into the Key Provenance and Trust section: The security considerations in Section 12.3 of XML DSIG 2.0 [W3C.NOTE-xmldsig-core2-20130411], about the streng= th of a signature depending upon all links in the security chain also apply to this specification. 8. In the JWK spec, add the new security considerations text: 11.2. RSA Private Key Representations and Blinding The RSA Key blinding operation [Kocher], which is a defense against some timing attacks, requires all of the RSA key values "n", "e", and "d". However, some RSA private key representations do not include the public exponent "e", but only include the modulus "n" and the private exponent "d". This is true, for instance, of the Java RSAPrivateKeySpec API, which does not include the public exponent "e" as a parameter. So as to enable RSA key blinding, such representations should be avoided. For Java, the RSAPrivateCrtKeySpec API can be used instead. Section 8.2.2(i) of The Handbook of Applied Cryptography [citation] discusses how to compute the remaining private key parameters, if needed, using only "n", "e", and "e". 9. In the JWA spec, add a security considerations subsection "RSA Private = Key Representations and Blinding" which references this JWK subsection (rat= her duplicating the text in JWA). Does the working group agree with these changes? Are there other changes t= hat working group members believe are also needed? (If so, please propose = the desired specific wording.) Kathleen, do these changes accomplish your goal? If not, can you please pr= opose specific additional text changes that you'd also like to see? -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439AD6435ETK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Also forwarding this t= o the OAuth WG, given Kathleen’s comments on the JWT security conside= rations section.  (However, please conduct discussions about the JOSE = text on the jose@ietf.org list and only reply here= if you are proposing a change to the JWT security considerations section.)=

 

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

 

From: Mike Jon= es
Sent: Monday, June 09, 2014 5:32 PM
To: jose@ietf.org
Cc: Kathleen Moriarty
Subject: Proposed Security Considerations sections changes

 

In response to Kathleen’s requests to beef up = the security considerations sections, I propose the following 9 actions:

 

1.  In the JWE spec, add the heading “= 11.1. Adaptive Chosen-Ciphertext Attacks” before the= Security Considerations text beginning:

  = ; When decrypting, particular care must be taken not to allow the JWE<= /o:p>

  = ; recipient to be used as an oracle for decrypting messages.

 

2.  At the end of the JWE Security Consideratio= ns, add the text:

 

   11.2. Timing Attacks

   To m=
itigate the timing attacks described in RFC 3218 [RFC3218], the
   reci=
pient MUST NOT distinguish between format, padding, and

   leng=
th errors of encrypted keys.  It is strongly recommended, in


   the =
event of receiving an improperly formatted key, that the<=
/pre>

   rece=
iver substitute a randomly generated CEK and proceed to the


   next=
 step, to mitigate timing attacks.


 


3.  Remove the text from step 2 above from the =
place it occurs earlier (in JWE Section 5.2, step 10), and instead referenc=
e the security considerations text there.


 


4.  Add JWA Security Considerations subsections=
 on “Adaptive Chosen-Ciphertext Attacks” an=
d “Timing
 Attacks”, which reference the JWE subsections (rather dup=
licating the text in JWA).


 


5.  In the JWK spec, add the heading “=
8.1. Key Provenance and Trust” before the security c=
onsiderations text beginning:


   One =
should place no more trust in the data associated with a key than


   in t=
han the method by which it was obtained and in the


   trus=
tworthiness of the entity asserting an association with the key.=



 


6.  In the JWK spec, add the heading “=
8.2. Preventing Disclosure of Non-Public Key Information&#=
8221; before the security considerations text beginning:

  Private and symmetric keys MUST be protected from disclosure t=
o


  unintended=
 parties.


 


7.  In the JWK spec, replace the current text c=
iting 
XML DSIG 2.0 with the following and move it into the Key Provenance and Tru=
st section:


   The =
security considerations in Section 12.3 of XML DSIG 2.0

   [W3C.NOTE-xmldsig-core2-20130411], about th=
e strength of a signature


   depe=
nding upon all links in the security chain also apply

   to t=
his specification.


 


8.  In the JWK spec, add the new security consi=
derations text:


   11.2. RSA Private Key Represen=
tations and Blinding


   The =
RSA Key blinding operation [Kocher], which is a defense

   agai=
nst some timing attacks, requires all of the


   RSA =
key values “n”, “e”, and “d”.  How=
ever,


   some=
 RSA private key representations do not include the


   publ=
ic exponent “e”, but only include the modulus “n”


   and =
the private exponent “d”.  This is true, for instance,


   of t=
he Java RSAPrivateKeySpec API, which does not include

   the =
public exponent “e” as a parameter.  So as to enable<=
/o:p>


   RSA =
key blinding, such representations should be avoided.

   For =
Java, the RSAPrivateCrtKeySpec API can be used instead.

   Sect=
ion 8.2.2(i) of The Handbook of Applied Cry=
ptography 


   [citation] discus=
ses how to compute the remaining private key


   parameters, if needed,=
 using only “n”, “e”, and “e”.


 


9.  In the JWA spec, add a security considerati=
ons subsection “RSA Private Key Representations and Blinding=
” which references this JWK subsection (rather duplicating
 the text in JWA).


 


Does the working group agree with these changes?&nbs=
p; Are there other changes that working group members believe are also need=
ed?  (If so, please propose the desired specific wording.)<=
/p>

 


Kathleen, do these changes accomplish your goal?&nbs=
p; If not, can you please propose specific additional text changes that you=
’d also like to see?


 


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


 
--_000_4E1F6AAD24975D4BA5B16804296739439AD6435ETK5EX14MBXC292r_-- From nobody Tue Jun 10 23:32:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A141A854B; Tue, 10 Jun 2014 23:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng5X3H2KQ84b; Tue, 10 Jun 2014 23:32:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DE91B27DC; Tue, 10 Jun 2014 23:32:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611063225.18444.24283.idtracker@ietfa.amsl.com> Date: Tue, 10 Jun 2014 23:32:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FoB_TaVAUrZdLVwuKCiVLdFpuBQ Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-21.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 06:32:27 -0000 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 : JSON Web Token (JWT) Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-21.txt Pages : 32 Date : 2014-06-10 Abstract: JSON Web Token (JWT) is a compact URL-safe 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 used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. 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-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 10 23:59:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00071B27E6 for ; Tue, 10 Jun 2014 23:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TD_KKsK5XDi for ; Tue, 10 Jun 2014 23:58:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FBA1A0657 for ; Tue, 10 Jun 2014 23:58:58 -0700 (PDT) Received: from DM2PR03CA005.namprd03.prod.outlook.com (10.141.52.153) by DM2PR03MB496.namprd03.prod.outlook.com (10.141.85.152) with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 11 Jun 2014 06:58:57 +0000 Received: from BL2FFO11FD008.protection.gbl (2a01:111:f400:7c09::133) by DM2PR03CA005.outlook.office365.com (2a01:111:e400:2414::25) with Microsoft SMTP Server (TLS) id 15.0.959.24 via Frontend Transport; Wed, 11 Jun 2014 06:58:57 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.959.15 via Frontend Transport; Wed, 11 Jun 2014 06:58:56 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.173]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0195.002; Wed, 11 Jun 2014 06:58:20 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JOSE -27 and JWT -21 drafts incorporating area director feedback Thread-Index: Ac+FQoaVRDWtAgHRQ8O2PLW+fvC+mg== Date: Wed, 11 Jun 2014 06:58:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD66EF3@TK5EX14MBXC292.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD66EF3TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438001)(189002)(199002)(51914003)(54356999)(19300405004)(6806004)(66066001)(86362001)(97736001)(26826002)(33656002)(77982001)(19625215002)(16236675004)(4396001)(44976005)(85852003)(104016001)(81156002)(2656002)(84676001)(68736004)(50986999)(92566001)(85806002)(92726001)(87936001)(15975445006)(55846006)(83072002)(83322001)(81542001)(16297215004)(76482001)(46102001)(74662001)(21056001)(512954002)(15202345003)(80022001)(20776003)(86612001)(69596002)(31966008)(84326002)(74502001)(71186001)(19580395003)(79102001)(99396002)(81342001)(64706001)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR03MB496; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0239D46DB6 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/1tZjkJc61Ra3ve4JQiYISeSWwRQ Subject: [OAUTH-WG] JOSE -27 and JWT -21 drafts incorporating area director feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 06:59:06 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD66EF3TK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The -27 drafts of the JOSE specs (JWS, JWE, JWK, & JWA) and the -21 draft o= f the JWT spec have been posted that incorporate feedback received from our= security area director, Kathleen Moriarty. The one normative change was t= o add certificate thumbprint parameters using SHA-256 as the hash function.= There were no breaking changes. A number of additional security consider= ations were added across the drafts. An example JWK was added early in the= JWK draft (paralleling the early examples in the JWS, JWE, and JWT drafts)= . Several algorithm cross-reference entries were updated in the JWA draft.= A number of other editorial improvements were also applied. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-27 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-27 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-27 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-27 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-21 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-27= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-2= 7.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-27.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-2= 7.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-21.ht= ml Thanks for the detailed feedback, Kathleen. -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1236 and = as @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439AD66EF3TK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The -27 drafts of the JOSE specs (JWS, JWE, JWK, &am= p; JWA) and the -21 draft of the JWT spec have been posted that incorporate= feedback received from our security area director, Kathleen Moriarty. = ; The one normative change was to add certificate thumbprint parameters using SHA-256 as the hash function.  There were= no breaking changes.  A number of additional security considerations = were added across the drafts.  An example JWK was added early in the J= WK draft (paralleling the early examples in the JWS, JWE, and JWT drafts).  Several algorithm cross-reference entries= were updated in the JWA draft.  A number of other editorial improveme= nts were also applied.

 

The specifications are available at:

·        http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-27

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-27

·        http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-27

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-27

·        http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-21

 

HTML formatted versions are available at:=

·        http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-27.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-27.html

·        http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-27.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-27.html

·        http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-21.html

 

Thanks for the detailed feedback, Kathleen.

 

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

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1236 and as @selfissued.

 

 

--_000_4E1F6AAD24975D4BA5B16804296739439AD66EF3TK5EX14MBXC292r_-- From nobody Wed Jun 11 00:40:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256551A0408 for ; Wed, 11 Jun 2014 00:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e1TlEjSQgiO for ; Wed, 11 Jun 2014 00:40:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E9B1A0061 for ; Wed, 11 Jun 2014 00:40:30 -0700 (PDT) Received: from BY2PR03CA034.namprd03.prod.outlook.com (10.242.234.155) by BY2PR03MB332.namprd03.prod.outlook.com (10.141.139.23) with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 11 Jun 2014 07:40:29 +0000 Received: from BY2FFO11FD002.protection.gbl (2a01:111:f400:7c0c::175) by BY2PR03CA034.outlook.office365.com (2a01:111:e400:2c2c::27) with Microsoft SMTP Server (TLS) id 15.0.954.9 via Frontend Transport; Wed, 11 Jun 2014 07:40:29 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD002.mail.protection.outlook.com (10.1.14.124) with Microsoft SMTP Server (TLS) id 15.0.959.15 via Frontend Transport; Wed, 11 Jun 2014 07:40:29 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.173]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0195.002; Wed, 11 Jun 2014 07:40:01 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [OAUTH-WG] JWT review Thread-Index: AQHPg/5gzu/A4NjdfECJ7UyyP64X2JtrhyGQ Date: Wed, 11 Jun 2014 07:40:00 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD671F3@TK5EX14MBXC292.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD671F3TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438001)(199002)(189002)(43784003)(377454003)(60444003)(71186001)(76176999)(512874002)(66066001)(81542001)(68736004)(69596002)(92566001)(2656002)(15202345003)(54356999)(20776003)(85806002)(64706001)(85852003)(86362001)(84326002)(19300405004)(83072002)(84676001)(4396001)(19580395003)(15975445006)(74502001)(50986999)(74662001)(79102001)(104016001)(97736001)(46102001)(99396002)(21056001)(83322001)(86612001)(19625215002)(81156002)(80022001)(44976005)(6806004)(26826002)(55846006)(81342001)(33656002)(16236675004)(92726001)(87936001)(76482001)(19580405001)(31966008)(77982001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB332; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0239D46DB6 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/e7n6AywqPv23-c515n-FrZvdPAE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 07:40:33 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD671F3TK5EX14MBXC292r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVwbGllcyBpbmxpbmUgbWFya2VkIOKAnE1pa2U+4oCd4oCmDQoNCg0KRnJvbTogT0F1dGggW21h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2F0aGxlZW4gTW9yaWFy dHkNClNlbnQ6IE1vbmRheSwgSnVuZSAwOSwgMjAxNCA5OjE4IEFNDQpUbzogb2F1dGhAaWV0Zi5v cmcNClN1YmplY3Q6IFtPQVVUSC1XR10gSldUIHJldmlldw0KDQpIZWxsbywNCg0KSSBhbSBpbiBw cm9jZXNzIG9mIHdvcmtpbmcgdGhyb3VnaCB0aGUgSk9TRSBkcmFmdHMgYW5kIGFsc28gcmVhZCB0 aGUgT2F1dGggSldUIGRyYWZ0IGxhc3Qgd2Vlay4gIFRoZXJlIGlzIHNvbWUgb3ZlcmxhcCBpbiB0 ZXh0IHRoYXQgbWF5IHJlcXVpcmUgc29tZSBqb2ludCB3b3JrIHRvIGNvcnJlY3QuDQoNCjEuIEZv ciBKV1QsIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHN0YXJ0cyBvZmYgd2l0 aCB0aGUgc2FtZSB0ZXh0IHRoYXQgaXMgaW4gc2V2ZXJhbCBvZiB0aGUgSk9TRSBkcmFmdHMuICBJ biBteSByZXZpZXcgb2YgdGhlIEpXQSBkcmFmdCwgSSBhc2tlZCBmb3Igc29tZSBmaXhlcyB0aGF0 IHdpbGwgbmVlZCB0byBiZSBtYWRlIHRvIHRoaXMgZHJhZnQgYXMgd2VsbC4gIEhlcmUgaXMgYSBs aW5rIHRvIHRoYXQgcmV2aWV3IGFuZCBpdCBtYXkgYmUgZWFzaWVyIHRvIGhlbHAgd2l0aCB0aGlz IHdvcmsgaW4gb25lIHNwb3Qgd2hlcmUgdGV4dCB3aWxsIGJlIHJldXNlZC4gIE1pa2UgaGFzIGFz a2VkIHRoZSBKT1NFIFdHIHRvIGFzc2lzdCwgYnV0IGl0IG1ha2UgbWFrZSBzZW5zZSBmb3IgT2F1 dGggZm9sa3MgdG8gaGVscCBhcyB3ZWxsLiAgSWYgaXQgbWFrZXMgc2Vuc2UsIGEgcG9pbnRlciB0 byBleGlzdGluZyB0ZXh0IGlzIGFsc28gZmluZS4NCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwNDA2NC5odG1sDQoNCkkgYmVsaWV2ZSB0aGF0 IHRoZSBKT1NFIC0yNyBkcmFmdHMgYWRkcmVzcyB5b3VyIGZpcnN0IGNvbW1lbnQgYWJvdXQgYmVl ZmluZyB1cCB0aGUgSk9TRSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9ucy4gIElmIHlv deKAmWQgbGlrZSB0byBzZWUgYW55IG1vcmUgc3BlY2lmaWMgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgZGlzY3Vzc2VkLCBwbGVhc2UgbGV0IG1lIGtub3cgd2hhdCB0aGV5IGFyZS4NCg0KMi4gU2Vj dGlvbnMgNS4xIGFuZCA1LjIgYXJlIGEgbGl0dGxlIGNvbmZ1c2luZy4gIEhvd2V2ZXIsIHRoZSB1 c2Ugb2YgInR5cCIgYW5kICJjdHkiIGFwcGVhciBpbiAzIGRyYWZ0cyAoYXQgbGVhc3QpLCBzbyB0 aGlzIHNob3VsZCBnZXQgYWRkcmVzc2VkIHdpdGggYW4gYXBwcm9hY2ggdGhhdCBjb25zaWRlcnMg dGhlIGpvaW50IHRleHQgdG8gcmVkdWNlIGNvbmZ1c2lvbiBmb3IgZGV2ZWxvcGVycy4gIFRoZSBp bml0aWFsIGRlc2NyaXB0aW9ucyBhcmUgaW4gdGhlIEpPU0UgSldTIGRyYWZ0LCBzbyB0aGF0IG1h eSBuZWVkIG1vc3Qgb2YgdGhlIHdvcmssIGJ1dCBpdCBhbHNvIGFwcGVhcnMgaW4gdGhpcyBkcmFm dCBhbmQgdGhlIEpPU0UgSldLIGRyYWZ0LiAgSW4gbXkgd3JpdGV1cCBmb3IgdGhlIEpXSyByZXZp ZXcsIEkgbGlzdGVkIG91dCBzb21lIHF1ZXN0aW9ucyBhbmQgd291bGQgbGlrZSB0byBzZWUgaW1w cm92ZW1lbnRzIGFjcm9zcyB0aGVzZSBkcmFmdHMuICBUaGlzIHdpbGwgbGlrZWx5IHJlcXVpcmUg c29tZSBqb2ludCB3b3JrIGFuZCBtYXkgYmUgYmVzdCBpbiByZXNwb25zZSB0byB0aGUgSldLIHJl dmlldyB0byBrZWVwIGl0IGluIG9uZSBwbGFjZS4NCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwNDE3Mi5odG1sDQoNClBsZWFzZSBzZWUgbXkg cmVzcG9uc2UgdG8gdGhpcyBpc3N1ZSBzZW50IG9uIFNhdHVyZGF5IGluIHRoZSB0aHJlYWQg4oCc W2pvc2VdIEFEIHJldmlldyBvZiBKV0sgZHJhZnTigJ0uICBJbiBzaG9ydCwgaWYgYSBjaGFuZ2Ug aXMgdG8gYmUgbWFkZSB0byB0aGlzIGFscmVhZHkgdmVyeSBoZWF2aWx5IGRpc2N1c3NlZCBhbmQg d29yZHNtaXRoZWQgd29yZGluZywgSeKAmWQgbGlrZSB0byBzZWUgc3BlY2lmaWMgcHJvcG9zZWQg YWx0ZXJuYXRlIHdvcmRpbmcgdGhhdCBtZWFucyB0aGUgc2FtZSB0aGluZyBidXQgaXMgZXZlbiBj bGVhcmVyLg0KDQpUaGFuayB5b3UhDQoNCi0tDQoNCkJlc3QgcmVnYXJkcywNCkthdGhsZWVuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2Fp biwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UN Cg0K --_000_4E1F6AAD24975D4BA5B16804296739439AD671F3TK5EX14MBXC292r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcw QzAiPlJlcGxpZXMgaW5saW5lIG1hcmtlZCDigJxNaWtlJmd0O+KAneKApjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+S2F0aGxlZW4gTW9yaWFydHk8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBK dW5lIDA5LCAyMDE0IDk6MTggQU08YnI+DQo8Yj5Ubzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gSldUIHJldmlldzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBhbSBpbiBwcm9jZXNzIG9mIHdvcmtpbmcgdGhyb3VnaCB0aGUgSk9T RSBkcmFmdHMgYW5kIGFsc28gcmVhZCB0aGUgT2F1dGggSldUIGRyYWZ0IGxhc3Qgd2Vlay4gJm5i c3A7VGhlcmUgaXMgc29tZSBvdmVybGFwIGluIHRleHQgdGhhdCBtYXkgcmVxdWlyZSBzb21lIGpv aW50IHdvcmsgdG8gY29ycmVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+MS4gRm9yIEpXVCwgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z IHNlY3Rpb24gc3RhcnRzIG9mZiB3aXRoIHRoZSBzYW1lIHRleHQgdGhhdCBpcyBpbiBzZXZlcmFs IG9mIHRoZSBKT1NFIGRyYWZ0cy4gJm5ic3A7SW4gbXkgcmV2aWV3IG9mIHRoZSBKV0EgZHJhZnQs IEkgYXNrZWQgZm9yIHNvbWUgZml4ZXMgdGhhdCB3aWxsIG5lZWQgdG8gYmUgbWFkZSB0byB0aGlz IGRyYWZ0IGFzIHdlbGwuICZuYnNwO0hlcmUgaXMgYSBsaW5rDQogdG8gdGhhdCByZXZpZXcgYW5k IGl0IG1heSBiZSBlYXNpZXIgdG8gaGVscCB3aXRoIHRoaXMgd29yayBpbiBvbmUgc3BvdCB3aGVy ZSB0ZXh0IHdpbGwgYmUgcmV1c2VkLiAmbmJzcDtNaWtlIGhhcyBhc2tlZCB0aGUgSk9TRSBXRyB0 byBhc3Npc3QsIGJ1dCBpdCBtYWtlIG1ha2Ugc2Vuc2UgZm9yIE9hdXRoIGZvbGtzIHRvIGhlbHAg YXMgd2VsbC4gJm5ic3A7SWYgaXQgbWFrZXMgc2Vuc2UsIGEgcG9pbnRlciB0byBleGlzdGluZyB0 ZXh0IGlzIGFsc28gZmluZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2pvc2UvY3VycmVudC9tc2cwNDA2NC5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzA0MDY0Lmh0bWw8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcw QzAiPkkgYmVsaWV2ZSB0aGF0IHRoZSBKT1NFIC0yNyBkcmFmdHMgYWRkcmVzcyB5b3VyIGZpcnN0 IGNvbW1lbnQgYWJvdXQgYmVlZmluZyB1cCB0aGUgSk9TRSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBzZWN0aW9ucy4mbmJzcDsgSWYgeW914oCZZCBsaWtlIHRvIHNlZSBhbnkgbW9yZSBzcGVjaWZp Yw0KIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRpc2N1c3NlZCwgcGxlYXNlIGxldCBtZSBrbm93 IHdoYXQgdGhleSBhcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4yLiBTZWN0aW9ucyA1LjEgYW5kIDUuMiBhcmUgYSBsaXR0bGUgY29uZnVzaW5nLiAmbmJz cDtIb3dldmVyLCB0aGUgdXNlIG9mICZxdW90O3R5cCZxdW90OyBhbmQgJnF1b3Q7Y3R5JnF1b3Q7 IGFwcGVhciBpbiAzIGRyYWZ0cyAoYXQgbGVhc3QpLCBzbyB0aGlzIHNob3VsZCBnZXQgYWRkcmVz c2VkIHdpdGggYW4gYXBwcm9hY2ggdGhhdCBjb25zaWRlcnMgdGhlIGpvaW50IHRleHQgdG8gcmVk dWNlIGNvbmZ1c2lvbiBmb3IgZGV2ZWxvcGVycy4gJm5ic3A7VGhlIGluaXRpYWwNCiBkZXNjcmlw dGlvbnMgYXJlIGluIHRoZSBKT1NFIEpXUyBkcmFmdCwgc28gdGhhdCBtYXkgbmVlZCBtb3N0IG9m IHRoZSB3b3JrLCBidXQgaXQgYWxzbyBhcHBlYXJzIGluIHRoaXMgZHJhZnQgYW5kIHRoZSBKT1NF IEpXSyBkcmFmdC4gJm5ic3A7SW4gbXkgd3JpdGV1cCBmb3IgdGhlIEpXSyByZXZpZXcsIEkgbGlz dGVkIG91dCBzb21lIHF1ZXN0aW9ucyBhbmQgd291bGQgbGlrZSB0byBzZWUgaW1wcm92ZW1lbnRz IGFjcm9zcyB0aGVzZSBkcmFmdHMuICZuYnNwO1RoaXMNCiB3aWxsIGxpa2VseSByZXF1aXJlIHNv bWUgam9pbnQgd29yayBhbmQgbWF5IGJlIGJlc3QgaW4gcmVzcG9uc2UgdG8gdGhlIEpXSyByZXZp ZXcgdG8ga2VlcCBpdCBpbiBvbmUgcGxhY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQxNzIuaHRtbCI+aHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwNDE3Mi5odG1sPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5Q bGVhc2Ugc2VlIG15IHJlc3BvbnNlIHRvIHRoaXMgaXNzdWUgc2VudCBvbiBTYXR1cmRheSBpbiB0 aGUgdGhyZWFkIOKAnFtqb3NlXSBBRCByZXZpZXcgb2YgSldLIGRyYWZ04oCdLiZuYnNwOyBJbiBz aG9ydCwgaWYgYSBjaGFuZ2UgaXMgdG8gYmUgbWFkZSB0byB0aGlzIGFscmVhZHkgdmVyeQ0KIGhl YXZpbHkgZGlzY3Vzc2VkIGFuZCB3b3Jkc21pdGhlZCB3b3JkaW5nLCBJ4oCZZCBsaWtlIHRvIHNl ZSBzcGVjaWZpYyBwcm9wb3NlZCBhbHRlcm5hdGUgd29yZGluZyB0aGF0IG1lYW5zIHRoZSBzYW1l IHRoaW5nIGJ1dCBpcyBldmVuIGNsZWFyZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rIHlvdSE8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+S2F0aGxlZW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFRoYW5rcyBhZ2Fpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439AD671F3TK5EX14MBXC292r_-- From nobody Wed Jun 11 09:06:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4131B27C1 for ; Wed, 11 Jun 2014 09:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFwXFb_gvDNf for ; Wed, 11 Jun 2014 09:06:24 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F13E1B27FC for ; Wed, 11 Jun 2014 09:06:07 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id db11so6084331veb.32 for ; Wed, 11 Jun 2014 09:06:06 -0700 (PDT) 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=pcXtSlWmHziUCMNX+Ag4Y+50DMF/BlDgvl0ery4tjEc=; b=H0ooD7ourrLz5CxI5/77alIQOHHo/RGu/8hAsE1kNs59TfJZCB0usDNMq5KVjPdBsi wmrHnoHldZnOTevAbGvHUxuoeW4cDMjoq8cG72LJ+jj9XqNGzI9r6oKsTrQplRmFTwsl ySiNWXm3LlX7qdpuD/4qLmTRaob4Hs1ESx6IyiEZqL3xshkkfldEfIMSpw2r3yqalCE5 u5tAzK5N0oSIGYjJs+TXZ3xa3mL2v/U2qZjf9lz7noHn8BSpHhChQKyyL56PcyeziqaM YOa9PkJctOZsyGHGb0JV47BVVH70AhyBJ8wQ9at+5D/P55LsvCmgNi7SZQEMCFHy8cZk sPSQ== MIME-Version: 1.0 X-Received: by 10.52.130.18 with SMTP id oa18mr842556vdb.78.1402502766631; Wed, 11 Jun 2014 09:06:06 -0700 (PDT) Received: by 10.220.118.12 with HTTP; Wed, 11 Jun 2014 09:06:06 -0700 (PDT) Date: Wed, 11 Jun 2014 17:06:06 +0100 Message-ID: From: Pedro Felix To: oauth list Content-Type: multipart/alternative; boundary=bcaec520f00533a38004fb919f77 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/NNELReQuL-uRWmyVAeG7w2aQpEE Subject: [OAUTH-WG] Token revocation - response status for valid token but incorrect client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:06:31 -0000 --bcaec520f00533a38004fb919f77 Content-Type: text/plain; charset=UTF-8 Hi, In the context of RFC 7009, what should be the response status code if the request contains a *valid* token but associated with a different client? Should we consider this token to be "invalid" and return a 200? However, the token can still remain valid (for a different client). The RFC states "...and then verifies whether the token was issued to the client making the revocation request. If this validation fails, the request is refused and the client is informed of the error by the authorization server as described below" However, it is not clear where is the "described below". With a 200 status code, an implementation does not have to check if the revocation failed due to a client mismatch or due to another reason (e.g. token does not exist). This may allow for a more efficient revocation procedure. Thanks Pedro --bcaec520f00533a38004fb919f77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

In the context of RFC 7009, what sh= ould be the response status code if the request contains a *valid* token bu= t associated with a different client?

Should we co= nsider this token to be "invalid" and return a 200? However, the = token can still remain valid (for a different client).

The RFC states

"...and th= en verifies whether the token
=C2=A0 =C2=A0was issued to the clie= nt making the revocation request. =C2=A0If this
=C2=A0 =C2=A0vali= dation fails, the request is refused and the client is informed
=C2=A0 =C2=A0of the error by the authorization server as described bel= ow"

However, it is not clear where is the &qu= ot;described below".

With a 200 status code, = an implementation does not have to check if the revocation failed due to a = client mismatch or due to another reason (e.g. token does not exist). This = may allow for a more efficient revocation procedure.

Thanks
Pedro
--bcaec520f00533a38004fb919f77-- From nobody Wed Jun 11 09:20:32 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDC71A01AB for ; Wed, 11 Jun 2014 09:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmVHvAaHP2cr for ; Wed, 11 Jun 2014 09:20:24 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F00B1ACAD6 for ; Wed, 11 Jun 2014 09:20:07 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jw12so8599892veb.11 for ; Wed, 11 Jun 2014 09:20:06 -0700 (PDT) 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=frFg/84xHejAMqKyYlnZiDaospoiTAIwz3CZrbqj5wM=; b=iekmmVllcLGRHaX7oD599BSKveTk9nZc5xC3BG3c05IjRQLJ/Cos8txFDutXDMOKXF BQJGvP+SILdID9Vkmi55KmcXfqWeqzsLkEnw2YoCDAkYwDOmk4H3Y2W4vU2V08da7x1P PRzSB9UBPxIvnK4BP2ataqJdmeYHNcAI/+VRydxOYeopl4YxQ7WecRJxI+LzdA0wu8Zl rFLlITVg2eh9FEMx2UV1fn43Lt+voNVqSxz8fc5A9tGYiWs1PF51gRnxPDhJIhmHEFZq fbcV+tFmsCvtFc+/CmRG6V1hk3wTY/dq0t6ZwRTr9snb7GcDc7cJ40eZZS7qBJuNkwom zG1w== MIME-Version: 1.0 X-Received: by 10.52.6.227 with SMTP id e3mr3971275vda.10.1402503606566; Wed, 11 Jun 2014 09:20:06 -0700 (PDT) Received: by 10.220.118.12 with HTTP; Wed, 11 Jun 2014 09:20:06 -0700 (PDT) Date: Wed, 11 Jun 2014 17:20:06 +0100 Message-ID: From: Pedro Felix To: oauth list Content-Type: multipart/alternative; boundary=20cf3030c3474407ee04fb91d1dd Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/l_8T4p_DFsTn5vZP2umdvpPdslM Subject: [OAUTH-WG] Token revocation endpoint - revoking access token vs. revoking the grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:20:27 -0000 --20cf3030c3474407ee04fb91d1dd Content-Type: text/plain; charset=UTF-8 Hi, In the context of RFC 7009, I've a question regarding revocation of access tokens. I've a scenario where the revocation of an access token may have different behaviors 1) Option 1 - just revoke the access token and not the refresh token. An example is when OAuth 2.0 is being used for authentication (using OpenID Connect) and we want to revoke the access token after a logout but keep the refresh token for offline access 2) Option 2 - revoke both the access token *and* the refresh token. Both behaviors are allowed by RFC 7009, however there isn't a way for both to be simultaneously available. My first thought was to add a custom parameter to the token revocation request to differentiate between these two cases. Does this make sense? Is there a better solution? I know that adding custom parameters breaks compatibility and should only be used as a last resort. Regards Pedro --20cf3030c3474407ee04fb91d1dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

In the context of RFC 7009, I'v= e a question regarding revocation of access tokens.

I've a scenario where the revocation of an access token may have diff= erent behaviors

1) Option 1 - just revoke the access token and not the = refresh token. An example is when OAuth 2.0 is being used for authenticatio= n (using OpenID Connect) and we want to revoke the access token after a log= out but keep the refresh token for offline access

2) Option 2 - revoke both the access token *and* the re= fresh token.=C2=A0

Both behaviors are allowed by R= FC 7009, however there isn't a way for both to be simultaneously availa= ble.

My first thought was to add a custom parameter to the t= oken revocation request to differentiate between these two cases. Does this= make sense? Is there a better solution?
I know that adding custo= m parameters breaks compatibility and should only be used as a last resort.=


Regards
Pedro
--20cf3030c3474407ee04fb91d1dd-- From nobody Wed Jun 11 10:10:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAA01A01FA for ; Wed, 11 Jun 2014 10:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULVFVFlmnwiB for ; Wed, 11 Jun 2014 10:10:15 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFFEE1A01A7 for ; Wed, 11 Jun 2014 10:10:14 -0700 (PDT) Received: from mail-ig0-f169.google.com ([209.85.213.169]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKU5iNdgWdLJtiLcos7fjHQpsPhDfo2nsU@postini.com; Wed, 11 Jun 2014 10:10:14 PDT Received: by mail-ig0-f169.google.com with SMTP id a13so6520816igq.0 for ; Wed, 11 Jun 2014 10:10:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EWRAjxsi9FBY9Pd/SAZxtJFomubI2YfDJxS1YW11udw=; b=ONQSTQiLoduP/WjIbL7zbF4yeVjCxGMKawWp/SbQcMI8e9QsAo9WyXeBEWDwFYm2EX kz7RFpHsF9xxflqbUUnhFExLjf9/vrjZVBZXKYNr7ZcUxith31pfeUzAHSI228gDDkLv 2GZba8brftGqSgZyn/uDeQb6C+vvpub4/0jZGiMTRIE/ufN3bY1Wsko+pBfUqx9iSnyT UV0SdzqiVBLBWoD7oPVeplmS+qSe075UGriL4op+qMFNmdQcAvPuCSrKS1fDK5Jvctau TxEnZYade9EJj9/z9fEZOXNoXeG8mggPk/9izWJIr5q2ithANcttJJbFKsw/hu/wXPDA 01xw== X-Gm-Message-State: ALoCoQn1opynqZBVqF1e5bSYFuhYqXDUpnLmRY8zulnQj9STubhV4ItrzMGmrj6r2QZdUM4L8XMlXAK95pCyDfK4CbkwCwb/Ymm8UNPN82cwZwip6xAxc826sJw8oehVAyzSSkezqfxs X-Received: by 10.43.62.204 with SMTP id xb12mr46636408icb.51.1402506614030; Wed, 11 Jun 2014 10:10:14 -0700 (PDT) X-Received: by 10.43.62.204 with SMTP id xb12mr46636382icb.51.1402506613916; Wed, 11 Jun 2014 10:10:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.193 with HTTP; Wed, 11 Jun 2014 10:09:43 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 11 Jun 2014 11:09:43 -0600 Message-ID: To: Pedro Felix Content-Type: multipart/alternative; boundary=bcaec51a8b1a84a01104fb928418 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Mg2D7rJwaSnmp6WtBU57GCMruZ0 Cc: oauth list Subject: Re: [OAUTH-WG] Token revocation - response status for valid token but incorrect client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 17:10:16 -0000 --bcaec51a8b1a84a01104fb928418 Content-Type: text/plain; charset=UTF-8 Hi Pedro, I'm not sure it will exactly answer everything for you but there was a thread awhile back that started with a very similar question: http://www.ietf.org/mail-archive/web/oauth/current/msg12430.html On Wed, Jun 11, 2014 at 10:06 AM, Pedro Felix wrote: > Hi, > > In the context of RFC 7009, what should be the response status code if the > request contains a *valid* token but associated with a different client? > > Should we consider this token to be "invalid" and return a 200? However, > the token can still remain valid (for a different client). > > The RFC states > > "...and then verifies whether the token > was issued to the client making the revocation request. If this > validation fails, the request is refused and the client is informed > of the error by the authorization server as described below" > > However, it is not clear where is the "described below". > > With a 200 status code, an implementation does not have to check if the > revocation failed due to a client mismatch or due to another reason (e.g. > token does not exist). This may allow for a more efficient revocation > procedure. > > Thanks > Pedro > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --bcaec51a8b1a84a01104fb928418 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Pedro, I'm not sure it will exactly answer everythi= ng for you but there was a thread awhile back that started with a very simi= lar question: http://www.ietf.org/mail-archive/web/oauth/current/msg12430= .html


On Wed,= Jun 11, 2014 at 10:06 AM, Pedro Felix <pmhsfelix@gmail.com> wrote:
Hi,

In t= he context of RFC 7009, what should be the response status code if the requ= est contains a *valid* token but associated with a different client?

Should we consider this token to be "invalid"= and return a 200? However, the token can still remain valid (for a differe= nt client).

The RFC states

"...and th= en verifies whether the token
=C2=A0 =C2=A0was issued to the clie= nt making the revocation request. =C2=A0If this
=C2=A0 =C2=A0vali= dation fails, the request is refused and the client is informed
=C2=A0 =C2=A0of the error by the authorization server as described bel= ow"

However, it is not clear where is the &qu= ot;described below".

With a 200 status code, = an implementation does not have to check if the revocation failed due to a = client mismatch or due to another reason (e.g. token does not exist). This = may allow for a more efficient revocation procedure.

Thanks
Pedro

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


--bcaec51a8b1a84a01104fb928418-- From nobody Wed Jun 11 10:35:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CBA1A0236 for ; Wed, 11 Jun 2014 10:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPEcNRkijaH3 for ; Wed, 11 Jun 2014 10:35:28 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B771C1A0207 for ; Wed, 11 Jun 2014 10:35:27 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id db12so137739veb.35 for ; Wed, 11 Jun 2014 10:35:26 -0700 (PDT) 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=oK1IX8E/zsNLEnNAuZdgiTgW5DqGo1F2MBLXbsayRvs=; b=sE1RToZOZ2FNLEA0jX5Vrra74FRf+9v5U/4KIcMUnuo35KcQLqbfnpEkYzyk7NK+Wi 1ER8Ri9nqnweZqjZ8Cmk5nfbMGrbkMmNa/daWVRzAPlSJuACjbAgsFr9PzIl5DVsyhg0 QRiHrjPB8SYYYz9y4594jY5eTWdd2lkz6QWCLEPU8oLwk0b9N1ck1RRv9PQ54V+O1bTv +QyNeZTATIYjbItl2NCYfuVzp5jA67tZS909VcsgfKNtfmaHlF63cqPy9qhfmAVGDsNA jqGOGBVIDEAXx8BxfjEe8ikRF+Qfe1ZszZZOsdTcwuwhc0U51V9ddTXyfw/y4GD56eTi WRRA== MIME-Version: 1.0 X-Received: by 10.58.152.194 with SMTP id va2mr1771872veb.54.1402508126715; Wed, 11 Jun 2014 10:35:26 -0700 (PDT) Received: by 10.220.118.12 with HTTP; Wed, 11 Jun 2014 10:35:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Jun 2014 18:35:26 +0100 Message-ID: From: Pedro Felix To: oauth list Content-Type: multipart/alternative; boundary=089e013cbcd2b0080a04fb92deb2 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Ti6V3EosYrhWQhICfYgbpK2pMLc Subject: Re: [OAUTH-WG] Token revocation - response status for valid token but incorrect client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 17:35:30 -0000 --089e013cbcd2b0080a04fb92deb2 Content-Type: text/plain; charset=UTF-8 Yes, that is exactly my question. However, apparently there isn't a clear answer. I'm not sure 200 is a valid status code, since the token may remain valid. Regards Pedro On Wed, Jun 11, 2014 at 6:09 PM, Brian Campbell wrote: > Hi Pedro, I'm not sure it will exactly answer everything for you but there > was a thread awhile back that started with a very similar question: > http://www.ietf.org/mail-archive/web/oauth/current/msg12430.html > > > On Wed, Jun 11, 2014 at 10:06 AM, Pedro Felix wrote: > >> Hi, >> >> In the context of RFC 7009, what should be the response status code if >> the request contains a *valid* token but associated with a different client? >> >> Should we consider this token to be "invalid" and return a 200? However, >> the token can still remain valid (for a different client). >> >> The RFC states >> >> "...and then verifies whether the token >> was issued to the client making the revocation request. If this >> validation fails, the request is refused and the client is informed >> of the error by the authorization server as described below" >> >> However, it is not clear where is the "described below". >> >> With a 200 status code, an implementation does not have to check if the >> revocation failed due to a client mismatch or due to another reason (e.g. >> token does not exist). This may allow for a more efficient revocation >> procedure. >> >> Thanks >> Pedro >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --089e013cbcd2b0080a04fb92deb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, that is exactly my question. However, apparently ther= e isn't a clear answer.=C2=A0
I'm not sure 200 is a valid statu= s code, since the token may remain valid.

Rega= rds
Pedro


On Wed, Jun 11, 2014 at 6:09 PM, Brian Campbell = <bcampbe= ll@pingidentity.com> wrote:
Hi Pedro, I'm not sure = it will exactly answer everything for you but there was a thread awhile bac= k that started with a very similar question: http://www= .ietf.org/mail-archive/web/oauth/current/msg12430.html


On Wed, Jun 11, 2014 at 10:06 AM, Pedro Felix <pmhsfelix= @gmail.com> wrote:
Hi,

In the context of RFC 7009, what should be = the response status code if the request contains a *valid* token but associ= ated with a different client?

Should we consider this token to be "invalid"= and return a 200? However, the token can still remain valid (for a differe= nt client).

The RFC states

"...and th= en verifies whether the token
=C2=A0 =C2=A0was issued to the clie= nt making the revocation request. =C2=A0If this
=C2=A0 =C2=A0vali= dation fails, the request is refused and the client is informed
=C2=A0 =C2=A0of the error by the authorization server as described bel= ow"

However, it is not clear where is the &qu= ot;described below".

With a 200 status code, = an implementation does not have to check if the revocation failed due to a = client mismatch or due to another reason (e.g. token does not exist). This = may allow for a more efficient revocation procedure.

Thanks
Pedro

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



--089e013cbcd2b0080a04fb92deb2-- From nobody Wed Jun 11 10:38:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F061B2793 for ; Wed, 11 Jun 2014 10:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIBfHJfzRk1C for ; Wed, 11 Jun 2014 10:38:18 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3C43B1A0227 for ; Wed, 11 Jun 2014 10:38:18 -0700 (PDT) X-AuditID: 12074422-f79376d000000c58-3c-539894081053 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id EB.70.03160.80498935; Wed, 11 Jun 2014 13:38:16 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s5BHcGHD003711; Wed, 11 Jun 2014 13:38:16 -0400 Received: from [18.189.3.85] ([18.189.3.85]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s5BHcDMn000750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Jun 2014 13:38:15 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_7300D7EA-A588-4DFC-97AE-6202BBBC89DA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Justin Richer In-Reply-To: Date: Wed, 11 Jun 2014 13:38:12 -0400 Message-Id: References: To: Pedro Felix X-Mailer: Apple Mail (2.1878.2) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBKsWRmVeSWpSXmKPExsUixCmqrMsxZUawwc4PZhYn375is9iycTmz A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx9t0nxoKZ9hXN/06yNjBuNeti5OSQEDCR eHDnDiOELSZx4d56ti5GLg4hgdlMEtN397GCJIQENjJKdF8ygkgsZJK4cvc9K4jDLDCJUeL0 sYNgVbwCBhLX+tcDjeLgEBaIlzj0TQskzCagKjF/5S0mEJtTIFDiyvQl7CA2C1D87aldTCDl zALyEmtPGkJMsZJ4cu8JO8TeW4wSTeu8QGwRoPKzq++yQBwqLzGj/QT7BEaBWciumIXkChCb WSBJYtX5e+wQtrbEsoWvmSFsA4mnna9YMcX1Jd68m8MEYctLbH87BypuKbF45g0WCNtW4lbf AqgaO4lH0xaxLmDkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRrqpebWaKXmlK6iREUaewuSjsY fx5UOsQowMGoxMPLUDsjWIg1say4MvcQoyQHk5Io78V+oBBfUn5KZUZicUZ8UWlOavEhRhWg XY82rL7AKMWSl5+XqiTCG9EMVMebklhZlVqUD1MmzcGiJM771toqWEggPbEkNTs1tSC1CCYr w8GhJMGrMRmoUbAoNT21Ii0zpwQhzcTBeYhRgoMHaLgnSA1vcUFibnFmOkT+FKOilDhv0CSg hABIIqM0D64XliBfMYoDvSXMawLSzgNMrnDdr4AGMwENfu05HWRwSSJCSqqBsXASh8/n1fNy 45WfLZtxJUig8vT1QCdOzUVCxfsepUyZLbCe88sny++rOAT+hnyesErTUlZiZi/zb7Z7r1a9 OtSQz9u+Z7ZIsUlHf/gTq5j+V31dKx/pXl5TKe1safFVUcs8oa1b13D1xSShYid7D04buVrf LZ++3ZyY3eDcVh5w0XWdw6FuJZbijERDLeai4kQABq4H9WsDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/29yjtyP6VuOmB-SXr3kcIuTiwtg Cc: oauth list Subject: Re: [OAUTH-WG] Token revocation - response status for valid token but incorrect client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 17:38:21 -0000 --Apple-Mail=_7300D7EA-A588-4DFC-97AE-6202BBBC89DA Content-Type: multipart/alternative; boundary="Apple-Mail=_30C1978E-5E39-484D-88D9-4F41866113E6" --Apple-Mail=_30C1978E-5E39-484D-88D9-4F41866113E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 In this case, if the client can=92t revoke the token for some reason, = then there=92s nothing it can do if the token wasn=92t actually revoked. = It needs to treat the response from the server as if the token is no = longer valid, regardless of what actually happened on the server. It = could ask to revoke it again, or the correct client could ask to revoke = it, and in both cases the server says =93sure=94 and the client throws = away the token never to use it again. That, at least, is my = interpretation of the intent here. =97 Justin On Jun 11, 2014, at 1:35 PM, Pedro Felix wrote: > Yes, that is exactly my question. However, apparently there isn't a = clear answer.=20 > I'm not sure 200 is a valid status code, since the token may remain = valid. >=20 > Regards > Pedro >=20 >=20 > On Wed, Jun 11, 2014 at 6:09 PM, Brian Campbell = wrote: > Hi Pedro, I'm not sure it will exactly answer everything for you but = there was a thread awhile back that started with a very similar = question: = http://www.ietf.org/mail-archive/web/oauth/current/msg12430.html >=20 >=20 > On Wed, Jun 11, 2014 at 10:06 AM, Pedro Felix = wrote: > Hi, >=20 > In the context of RFC 7009, what should be the response status code if = the request contains a *valid* token but associated with a different = client? >=20 > Should we consider this token to be "invalid" and return a 200? = However, the token can still remain valid (for a different client). >=20 > The RFC states >=20 > "...and then verifies whether the token > was issued to the client making the revocation request. If this > validation fails, the request is refused and the client is informed > of the error by the authorization server as described below" >=20 > However, it is not clear where is the "described below". >=20 > With a 200 status code, an implementation does not have to check if = the revocation failed due to a client mismatch or due to another reason = (e.g. token does not exist). This may allow for a more efficient = revocation procedure. >=20 > Thanks > Pedro >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_30C1978E-5E39-484D-88D9-4F41866113E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 In = this case, if the client can=92t revoke the token for some reason, then = there=92s nothing it can do if the token wasn=92t actually revoked. It = needs to treat the response from the server as if the token is no longer = valid, regardless of what actually happened on the server. It could ask = to revoke it again, or the correct client could ask to revoke it, and in = both cases the server says =93sure=94 and the client throws away the = token never to use it again. That, at least, is my interpretation of the = intent here.

 =97 = Justin

On Jun 11, 2014, at 1:35 PM, Pedro Felix = <pmhsfelix@gmail.com> = wrote:

Yes, that is exactly my question. = However, apparently there isn't a clear answer. 
I'm not sure = 200 is a valid status code, since the token may remain = valid.

Regards
Pedro


On Wed, Jun 11, 2014 at 6:09 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:
Hi = Pedro, I'm not sure it will exactly answer everything for you but there = was a thread awhile back that started with a very similar question: http://www.ietf.org/mail-archive/web/oauth/current/msg12= 430.html


On Wed, Jun 11, 2014 at = 10:06 AM, Pedro Felix <pmhsfelix@gmail.com> wrote:
Hi,

In the context of = RFC 7009, what should be the response status code if the request = contains a *valid* token but associated with a different client?

Should we consider this token to be "invalid" and = return a 200? However, the token can still remain valid (for a different = client).

The RFC states

"...and then = verifies whether the token
   was issued to the = client making the revocation request.  If this
  =  validation fails, the request is refused and the client is = informed
   of the error by the authorization server as described = below"

However, it is not clear where is the = "described below".

With a 200 status code, an = implementation does not have to check if the revocation failed due to a = client mismatch or due to another reason (e.g. token does not exist). = This may allow for a more efficient revocation procedure.

Thanks
Pedro

_______________________________________________
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=_30C1978E-5E39-484D-88D9-4F41866113E6-- --Apple-Mail=_7300D7EA-A588-4DFC-97AE-6202BBBC89DA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTmJQFAAoJEDPAngkbd+w9XN4H/Az8HN8ih05cMvh9iiJbLRTR dmzoQLJtaMKa5uOahVRk+BhYt67007KPI7U9eavGOAOSj+3mh8t2Q7bL9spkOijn TaXXfS6babbXaCLywJ7OFaHipkLJOqvsePFc5L7mbULZgaOLTwp/ajrgyonToEg9 liQIFSM+0DVWcprXvoz2Ldv4Bdg/m83S1oTby9y6e9oQVhyWD8WRYbZLx9OTRbXO bTEpyGT1k/G8Cb2154jPMa30+S3wAcbj/nM5M+oPnpZXWGCXMR3STXVYwM1ziRbb BYc1xqoVmvXyut2ZpLWzgQAtwRvJIBn57Ff13C2z7jHYhV4rA98vGpXnviBOz/I= =hI4K -----END PGP SIGNATURE----- --Apple-Mail=_7300D7EA-A588-4DFC-97AE-6202BBBC89DA-- From nobody Thu Jun 12 00:53:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68901A039B for ; Thu, 12 Jun 2014 00:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9ZjPezz6SBU for ; Thu, 12 Jun 2014 00:53:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C211A035B for ; Thu, 12 Jun 2014 00:53:21 -0700 (PDT) Received: from [192.168.131.139] ([80.92.115.174]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LqQTl-1WHFIE27AP-00e6Hf; Thu, 12 Jun 2014 09:53:19 +0200 Message-ID: <53995BC3.1030802@gmx.net> Date: Thu, 12 Jun 2014 09:50:27 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Phil Hunt References: <53901F49.1010608@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KixseG5bMHBGxP9hcn9FLpsGdpBxDH5Pr" X-Provags-ID: V03:K0:XKGITE1d1B2W+VmGLgCHgDZ+c9vpQt63vv/RpfOQe9XrN1Uzacb 3VXNNxrebbNiyISqHj7+xJJLEFJ8vJZt0Td/SUwNduYaTKJvNCqjYgt1Pn7VhWwYsOG2COv 9yqKKEV3CcZphmTdvhiL1RAK1k9EUMZlLip4/nOJPDNGq++fIK9ZwY4bXgYVGJPJZqOU3RV oPQx0cPlr2Af3cGuwau3A== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/J-NiHhYQbYleKQaZZ4WBRBjTLa8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 07:53:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KixseG5bMHBGxP9hcn9FLpsGdpBxDH5Pr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Phil, thanks for your response. A few remarks below. >> I am particularly interested to learn who issues the initial >> access token and the software statement? What is the purpose? What >> does it authorize? >=20 > These tokens have very different characteristics. The Software > Statement is not a security token. It is a statement that locks the > registration profile for client software and provides AS endpoints > with a way to recognize client software since they do not have a > client_id yet. In practical terms, AS endpoints can set policy to > automatically approve reject based on specific statement, or content > rules (software_id, version etc) or even approve based on the signer > of the statements (e.g. allow registration for any client software > statement signed by Cisco). The software statement is hopefully signed and you are going to make some security relevant decisions based on it. Whether you call it a security token or not does not really matter that much. >=20 > Typically, the statement would be generated once (for all copies > distributed) by the developer, publisher, or a collective > organization. I think it would be useful to add information about who creates it, particularly since the document introduces these parties (at least the client developer, and the software API publisher). You might also expand a bit on what you mean by "generated once" to give guidance on when a new software assertion needs to be generated vs. when a previous one can be re-used. > This is particularly useful when the publisher of an > API is not the same organization as the deployers of the actual API > endpoints following a common open API specification. For example, > OpenID Connect would be one such example. OpenID Connect would not have come to my mind here since OpenID connect is neither a client developer nor a software API publisher (at least in my understanding of the terminology defined in the dynamic client registration document). >=20 > In the early OAuth1 and 2 days, most use cases had the API publisher > and the deployer as the same organization. A client_id could be > issued in advance and could be used as both credential id and > software identifier. In the evolving world, we have lots of cases > (e.g. OpenID Connect) where the organization that defines the API > specification is not the same as the one operating implementations of > the API specification. Client_id can=92t serve both purposes. > Software statement fills the gap allowing client software to use a > client statement =93claim=94 that can be =93exchange=94 for a deploymen= t > assigned client_id. I think that this would be useful background motivation for the draft; I disagree with the mentioning of OpenID Connect based on my previous comment. >=20 > Initial access token is a security token that allows the client to > register in a closed/restricted registration endpoint where anonymous > registration may not be allowed. Useful in some environments where > an IT organization might re-package a client for distribution on an > internal or private system. >=20 > Where the software statement is issued by either the developer or the > API specification organization, the initial access token is typically > issued by the =93domain=94 (or an organization affiliated with it) wher= e > the client intends to register. Using the terminology from the dynamic client registration draft the initial access token is issued by the "Deployment Organization". This would be important information to add to the document! Ciao Hannes --KixseG5bMHBGxP9hcn9FLpsGdpBxDH5Pr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTmVvEAAoJEGhJURNOOiAtGTAH/Rj6U9QxkhiBhp/34A6KRN1L UzbLx6OR7Y/84OxWGRZ4lgB9AJTxI4gM1NEAQ+x6Vp2EFV5xxvda05j7JRfd/9+/ C3C+zZkdEz779spYt4Jz5X6OnAbRmHjS54FgXpmcr1jITo5TqRTecNxj4pk1dSza 0Jcw96HjXoHUYAiDzOqd/yWsfPK33vibzVeK0jxfPZHEsaqPT+tyr8O+FZXuTDnj 8t6eQ67KCk5Lkszw1LSvZyiz+V0uHmYWew9pW0AZ+KUQyTgCkqGhjj4CKr0VUK9S LMRdX8wvx2mGebe/q/vE+y7Q5YvjgBFgiPkOdpjedUb4bWPmGPLIFFZ5NH4LFVs= =8P0L -----END PGP SIGNATURE----- --KixseG5bMHBGxP9hcn9FLpsGdpBxDH5Pr-- From nobody Thu Jun 12 00:55:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9817F1B2792 for ; Thu, 12 Jun 2014 00:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnugpZIhUkmU for ; Thu, 12 Jun 2014 00:55:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42851A035B for ; Thu, 12 Jun 2014 00:55:13 -0700 (PDT) Received: from [192.168.131.139] ([80.92.115.174]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LtmK9-1Wn7aF39O9-011DO5; Thu, 12 Jun 2014 09:55:10 +0200 Message-ID: <53995C50.2040900@gmx.net> Date: Thu, 12 Jun 2014 09:52:48 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Phil Hunt References: <53901F49.1010608@gmx.net> <53995BC3.1030802@gmx.net> In-Reply-To: <53995BC3.1030802@gmx.net> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4VqEbwb3w6CQ7vdc3oc9anqJLChGLCuvR" X-Provags-ID: V03:K0:ZtIrQvbTk4N8Khjc/FqK2wMdW4TLyIO1ygAKIsh+1FOy+2E0QpG eZsBlLWzNBIiljpyKgUUkadaLWkpdvXhJb0Tn9G/w9kTxlTGH/abJIV2k7Kr/ZlNwdjoO2G 0k1O6cVAfYLFat1O9xJJQRAeUs+uP7rP9h76Q0tBjKvd7RoJ+v/63Z8948Kf0XcIKjF9vEs Xcw9eyzpfDqmdfDNWXoJw== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/KKY94upoUA9rb7gfKBcs_rMpm3k Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 07:55:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4VqEbwb3w6CQ7vdc3oc9anqJLChGLCuvR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One other small remark: I assume that a single software statement is distributed to many OAuth clients whereas the initial access token is only distributed to a single OAuth client. Is that correct? Is that the envisioned relationship? On 06/12/2014 09:50 AM, Hannes Tschofenig wrote: > Hi Phil, >=20 > thanks for your response. A few remarks below. >=20 >>> I am particularly interested to learn who issues the initial >>> access token and the software statement? What is the purpose? What >>> does it authorize? >> >> These tokens have very different characteristics. The Software >> Statement is not a security token. It is a statement that locks the >> registration profile for client software and provides AS endpoints >> with a way to recognize client software since they do not have a >> client_id yet. In practical terms, AS endpoints can set policy to >> automatically approve reject based on specific statement, or content >> rules (software_id, version etc) or even approve based on the signer >> of the statements (e.g. allow registration for any client software >> statement signed by Cisco). >=20 > The software statement is hopefully signed and you are going to make > some security relevant decisions based on it. Whether you call it a > security token or not does not really matter that much. >=20 >> >> Typically, the statement would be generated once (for all copies >> distributed) by the developer, publisher, or a collective >> organization. >=20 > I think it would be useful to add information about who creates it, > particularly since the document introduces these parties (at least the > client developer, and the software API publisher). >=20 > You might also expand a bit on what you mean by "generated once" to giv= e > guidance on when a new software assertion needs to be generated vs. whe= n > a previous one can be re-used. >=20 >> This is particularly useful when the publisher of an >> API is not the same organization as the deployers of the actual API >> endpoints following a common open API specification. For example, >> OpenID Connect would be one such example. >=20 > OpenID Connect would not have come to my mind here since OpenID connect= > is neither a client developer nor a software API publisher (at least in= > my understanding of the terminology defined in the dynamic client > registration document). >=20 >> >> In the early OAuth1 and 2 days, most use cases had the API publisher >> and the deployer as the same organization. A client_id could be >> issued in advance and could be used as both credential id and >> software identifier. In the evolving world, we have lots of cases >> (e.g. OpenID Connect) where the organization that defines the API >> specification is not the same as the one operating implementations of >> the API specification. Client_id can=92t serve both purposes. >> Software statement fills the gap allowing client software to use a >> client statement =93claim=94 that can be =93exchange=94 for a deployme= nt >> assigned client_id. >=20 > I think that this would be useful background motivation for the draft; = I > disagree with the mentioning of OpenID Connect based on my previous > comment. >=20 >> >> Initial access token is a security token that allows the client to >> register in a closed/restricted registration endpoint where anonymous >> registration may not be allowed. Useful in some environments where >> an IT organization might re-package a client for distribution on an >> internal or private system. >> >> Where the software statement is issued by either the developer or the >> API specification organization, the initial access token is typically >> issued by the =93domain=94 (or an organization affiliated with it) whe= re >> the client intends to register. >=20 > Using the terminology from the dynamic client registration draft the > initial access token is issued by the "Deployment Organization". This > would be important information to add to the document! >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --4VqEbwb3w6CQ7vdc3oc9anqJLChGLCuvR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTmVxQAAoJEGhJURNOOiAt5C0H/jvYipoxIkyugQKsFV0XSE/a 43ryZm2NVRiZ2mScPYP8jJ5yCRwe1weoqywyFLuUCfJ/KHRGw1Iuq5C90lb8XFFp wAfFNzqMSSGjsh3HZHpkaKSxyOCi4TWYe/GbmVlXV2oJT0a0AHYRnxrySyPDp65h OIVZhTsUMCXF34H+WBVLMmLF+bHVIFh+SEoCWhjPwJIbRPPlUK1PL5pYbDfbY2kX y0SyJILAvYio1ZdntSx/9ubhvgBYwQQ2CCzS8j2ZJsXFSq0ASMV1+j8llHqzmJQm 2ejkim92Q0yLg1ehFvUaKvtXSjlY92gTlQZKuKnAMTmhu3bidAQWqENaxQ5ZAzA= =Y3Ot -----END PGP SIGNATURE----- --4VqEbwb3w6CQ7vdc3oc9anqJLChGLCuvR-- From nobody Thu Jun 12 01:00:10 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC491A02B3 for ; Thu, 12 Jun 2014 01:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbQYQtIPhWfB for ; Thu, 12 Jun 2014 01:00:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E781A0199 for ; Thu, 12 Jun 2014 01:00:05 -0700 (PDT) Received: from [192.168.131.139] ([80.92.115.174]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MSq5p-1XMBHI3mBJ-00RskZ; Thu, 12 Jun 2014 09:59:54 +0200 Message-ID: <53995D56.7040709@gmx.net> Date: Thu, 12 Jun 2014 09:57:10 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Mike Jones , Phil Hunt References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ptxCV4DD3IjL81oJniEbNqW4hQd6QSnpc" X-Provags-ID: V03:K0:+MHvhZ/7AB1a02w1uQkzZjEMmgtPL3fifvIi+SKn/NypnIBxtot pUFUmgRqGDqiMOcusMdUgeLjVAfoaKGjqnqJh4tWP55tKAKOV6QPx+Z0JQGwgG3POjhF06Y MwY0oum974H/VSRQuMeoXzyxybVGaGr/fIQe2XfgYjxTaC7Hh+Tv5/IUpfzWOwN1517Rj+p Wwvfa/PMxuFu9jCu0pE4A== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/s1TZgmPUkYZxyYmmBJwUziyff8M Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 08:00:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ptxCV4DD3IjL81oJniEbNqW4hQd6QSnpc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mike, thanks for your quick response. On 06/05/2014 07:46 PM, Mike Jones wrote: > Hannes, the Access Token and ID Token do quite different things and > have different structures and properties. The Access Token is an > opaque value that grants access to resources. An ID Token is a > non-opaque JWT security token that makes claims about the > authentication that occurred. You can have one without the other or > you can have both, depending upon the use case. Thus, trying to move > information between them would be problematic in several regards. Regarding the different structure between the access token and the ID token: As I tried to explain with my example they two may carry almost the same information (if the access token carries the information per value and uses the JWT encoding). Regarding the opaque nature: I think it is important to also add for whom the tokens are opaque. From the text in the document the access token and the ID token seem to be opaque for the client but they are not opaque for the party generating them (=3Dauthorization server) and also not opaque for the party consuming them (=3Dresource server). >=20 > Also, trying to overload the Access Token to convey authentication > information has been demonstrated in practice to be fraught with > peril, and has resulted in some of the most prominent security > breaches related to the misuse of OAuth. The problems with the security breaches had nothing to do with the encoding of the information in the token itself, which is what I am referring to. Ciao Hannes >=20 > -- Mike >=20 > -----Original Message----- From: OAuth > [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt Sent: > Thursday, June 05, 2014 8:54 AM To: Hannes Tschofenig Cc: > oauth@ietf.org Subject: Re: [OAUTH-WG] Question regarding > draft-hunt-oauth-v2-user-a4c >=20 > You are correct. Just adding to access token would make a lot of devs > happy and that certainly should be discussed. >=20 > Two requirements issues: >=20 > 1. A key use case is passing auth ctx only. An access token means > asking for consent to access something. This causes many sites to > loose new users. Authen only can be implicit consent. >=20 > 2. Compatibility with OpenId ID Token and flows. >=20 > 3. There is a need to support re-auth and MFA/LOA negotiation. Eg web > site would like to obtain a higher level of assurance for a higher > risk action. >=20 > The non-tech requirement is the soln must be received by client and > service provider developers as easy to implement in addition to 6749 > or even OAuth 1.1a. I mention it because devs feel this should be > trivial. Your suggestion of adding to access token certainly fits > this. >=20 > Phil >=20 >> On Jun 5, 2014, at 0:44, Hannes Tschofenig >> wrote: >>=20 >> Hi Phil, >>=20 >> thanks for producing this document write-up. I have a somewhat >> basic question regarding the document. >>=20 >> The id token contains the following mandatory information: - sis: >> issuer - sub: subject - aud: audience - iat: issued at - exp: >> expiry - auth_time: time when the end user was authenticated >>=20 >> An access token (when encoded as a JWT) may contain all these >> fields except the auth_time (since auth_time is not defined in the >> JWT spec). >>=20 >> Given that your proposal actually does not define the >> authentication protocol to be used between the resource owner/end >> user and the authorisation server I am wondering whether it would >> be possible to just add the auth_time parameter (and maybe some of >> the optional parameters) to the access token. Then, you can skip >> the id token. >>=20 >> How do I come up with that question? In Kerberos, for example, the >> above-listed information is carried within a single container >> (within the ticket) and so I am curious to hear why we have to send >> the information twice in OAuth (once in the access token, when the >> info is passed per value, and again via the id token). >>=20 >> Maybe I missing something important here. >>=20 >> Ciao Hannes >>=20 >>=20 >=20 > _______________________________________________ OAuth mailing list=20 > OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >=20 --ptxCV4DD3IjL81oJniEbNqW4hQd6QSnpc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTmV1WAAoJEGhJURNOOiAt2Z4H/j3CbutIv/hS2O/I80aVRgRX gHt+DhsNJW5k9+dFeVbbCyZlQ2JGi+bCwVBbW8f2Jmqvuj88Gv/rXVxXqug3JPVk 0ewOdxdVtC1ZWvCb3eFkokaXDs+ERUxehUInqCdqan1xQTuvSzYJLhma7w12ROlX xvG42XsW6WNZmZzAaT/cNtdvn/ZZ0zv1fV5j3N/N2fm+thcOHcdV5ZNmPxkmtqI4 UAcvZ/yLDaBSbx9HhdRrNLkZTzNqQJbNkifpNhAPuMJzK9x93EexB3O9eTWpeVp2 TXYcrCQvl/yRjraUMeR7z7MNnyCaccLOKk8dnFwEwcmBIxk3usMxO7s5bWVJVhE= =teju -----END PGP SIGNATURE----- --ptxCV4DD3IjL81oJniEbNqW4hQd6QSnpc-- From nobody Thu Jun 12 01:03:59 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625EE1A039B for ; Thu, 12 Jun 2014 01:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3GvG8gJxPTz for ; Thu, 12 Jun 2014 01:03:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433FC1A0199 for ; Thu, 12 Jun 2014 01:03:51 -0700 (PDT) Received: from [192.168.131.139] ([80.92.115.174]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0McR00-1XCWpu0UJk-00Hfa3; Thu, 12 Jun 2014 10:03:46 +0200 Message-ID: <53995E4E.6000404@gmx.net> Date: Thu, 12 Jun 2014 10:01:18 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Mike Jones , "oauth@ietf.org" References: <53901F49.1010608@gmx.net> <4E1F6AAD24975D4BA5B16804296739439AD53187@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD53187@TK5EX14MBXC294.redmond.corp.microsoft.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VFrLJreFRep6isFjMUUS2M26a3P9FeQ2f" X-Provags-ID: V03:K0:WqfRHyZs/W2goLbNXCr+AdaGfYLdWdqutbfMgEGwsn8mYr/2/cF QlVl9MfVufZHHV+c571bMZNIoD9LoqJ2smum+/nDXVuO0Y0nSsTc0UNHJNFH4S9zJ+vrrpV 5o6qidILaiq95qTgsWLx4FlHyfw+zbjsKhSoqmfPsDlhsFQ9dN96w6iUZTqrPx+wJ7y+GuZ ukKrHZfsp7We5eyoB6iJg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/mgmP0S_j6G6ruXy37BaeRRF4rnA Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 08:03:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VFrLJreFRep6isFjMUUS2M26a3P9FeQ2f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mike, thanks for responding also to the question about dynamic client registration. I also believe it would be useful to add information in the draft about the opaqueness nature of the different tokens, i.e., who is supposed to read them. =46rom the current wording of the document my understanding was that the OAuth client does not need to parse the initial access token nor the software statement. It just relays it. If the client indeed has to parse the software statement then it would be good to know why this is done and what the client uses the information for. As mentioned in my review comments I think it would be helpful for the reader to state who creates and distributes these tokens (as you and Phil) have explained in the email. Put those thoughts into the document. Ciao Hannes On 06/05/2014 09:18 PM, Mike Jones wrote: > The answer to your question about the Initial Access Token and > Software Statement is highly parallel to the answer to your question > in the other thread about the Access Token and ID Token. :-) The > Initial Access Token and the Software Statement do quite different > things and have different structures and properties. The Initial > Access Token is an opaque value that grants access to the > registration resource. A Software Statement is a non-opaque JWT > security token that makes claims about the software being registered. > You can have one without the other or you can have both, depending > upon the use case. >=20 > The parties that issue the two are also different. The Initial > Access Token is issued by and is about access to the Authorization > Server. The Software Statement is issued by the author of the > Client, or a party cooperating with the author, and is about the > Client. Both their authorship and subject matter of the two data > structures are different. >=20 > -- Mike >=20 > -----Original Message----- From: OAuth > [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: > Thursday, June 05, 2014 12:42 AM To: oauth@ietf.org Subject: > [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review >=20 > Hi Justin, Hi Mike, >=20 > thanks for updating the document so quickly. >=20 > I have re-read the new version and I have a few minor comments. >=20 > You write: "The following client metadata fields are defined by this > specification. All client metadata fields are OPTIONAL." >=20 > I guess you mean "Optional to implement and optional to use.". Maybe > it would be good to state that. >=20 > In the terminology section you briefly introduce a number of actors > and concepts. The description for the initial access token and the > software statement is somewhat short. >=20 > I am particularly interested to learn who issues the initial access > token and the software statement? What is the purpose? What does it > authorize? >=20 > I still don't fully get the idea of having both tokens (the initial > access token and the software assertion). Stating who issues those > might clarify it. If different parties provide different statements > or grant different authorization rights based on these two "tokens" > then I am happy but with the current write-up I feel that there is > something missing. >=20 > Redirect URIs: The text says: "It is RECOMMENDED that clients using > these flows register this parameter, and an authorization server > SHOULD require registration of valid redirect URIs for all clients > that use these grant types to protect against token and credential > theft attacks." >=20 > The security consideration section is equally weak: "For clients that > use redirect-based grant types such as authorization_code and > implicit, authorization servers SHOULD require clients to register > their redirect_uris in full." >=20 > Shouldn't the recommendation be a bit stronger particularly in light > of the recently discussed covered redirect attack? >=20 > What happens if the client does not provide any redirect uris? I > recommend to avoid the SHOULD because it is nothing a protocol > specification can fulfill. It seems to be rather a policy issue. I > think there should also be a description about "full" means here as > well. For example, would the AS be expected to understand something > like https://*.example.com? >=20 > MUST, MAY, SHOULDs: I think that the document still uses RFC 2119 > language too excessively at places where it does not provide any > guidance for protocol implementers. I would recommend to carefully > re-read each MUST/MAY/SHOULD and judge whether it imposes any > implementation specific requirements and if it doesn't to replace it > with deployment recommendations instead. Also, if there is a SHOULD > then it should be clear to the reader under what circumstances what > action should be taken. >=20 > policy_uri: In my previous review I argued that the right terminology > here is privacy notice and you can even re-use the IAPP terminology.=20 > Unless the policy URI has nothing to do with privacy I would prefer > this terminology change. If you disagree I would prefer to have a > description about what policy means in this context. >=20 > jwks: my problem with the fuzzy description is that it is not > indicated how the client (or any other party) would reference the > listed keys and what these would be used for. Maybe this document is > not the right place to define these JWKs if the semantic cannot be > defined properly. >=20 > Regarding the 'software_id' definition. You write that the > software_id is asserted by the client software but wouldn't it be > more reasonable that some human (in an organization) asserts > something rather than software. The software just acts on behalf of > the human. Would it be reasonable to say that a client developer > makes these assertions. >=20 > Regarding Section 4.2 client registration error response: Does a > response message always contain two members, namely error and > error_description? I would argue that the error member must be there > but the error_description is optional. >=20 > Regarding the error values I am missing a value that allows the > authorization server that a specific field has to be provided and is > currently absent. >=20 > Ciao Hannes >=20 >=20 --VFrLJreFRep6isFjMUUS2M26a3P9FeQ2f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTmV5OAAoJEGhJURNOOiAt3ukH/0nkB8ecLjkA2VJa9kKZTEo8 zDNPp99G283QqpvA/ED8x3qXBC2ScdljQvvbP9yi/BMcfOSK4chT5+TKzw3Iuk7l jPMyx7wu5g0nvqZ9YlHKmdrpfNLJt5dp6VjtdklapCc69Z/BDGUMpDas0G3OC+VC tZ3eCd9KaflgR3QmkP6vYDR/H2LTnf3YC2s9+xPMOIboKN6BJ9codK8dsOCXl7i4 x4T2pxRlsgSg+7WDriQX9QZxZpLATCvDZTjREvLLA4UeA1QIwbrNNp1FuOmKiS5k Ws33lpbuoV61uItzh+2poanGxl1eb1dqy5GAST44S3qtQrEHhYMyq4gcBMBHLbE= =aEhJ -----END PGP SIGNATURE----- --VFrLJreFRep6isFjMUUS2M26a3P9FeQ2f-- From nobody Thu Jun 12 01:07:06 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34161ABB90 for ; Thu, 12 Jun 2014 01:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2i-WnxsSg94 for ; Thu, 12 Jun 2014 01:06:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08BFB1A854B for ; Thu, 12 Jun 2014 01:06:55 -0700 (PDT) Received: from [192.168.131.139] ([80.92.115.174]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Mbx62-1XEAoO0mAQ-00JGMC; Thu, 12 Jun 2014 10:06:50 +0200 Message-ID: <53995ECB.1010305@gmx.net> Date: Thu, 12 Jun 2014 10:03:23 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bill Mills , Mike Jones , Phil Hunt References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> In-Reply-To: <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cQFtXkWexS2HSaC3DXtT89ANG8dkDSE8h" X-Provags-ID: V03:K0:kwb4kI6o8oy3ceyP+P+4rfpy0gTJONkQZ9n7g558wwp/FVzflj+ tjcBBME5oWM7RMlf/e2MqttlSCb6EmBrYouRsO2ym4cPNXk3jsYtVh2DGUO1lw4SHO2esGj y7Ty7GrR1P5Rjh7CM7Ui5pU80P6Bs+4B69O8fYGisW/on50Lk2lCF8rMJmK1SBXVsjFkULA cWEb/uD5evOFTARsvKr1w== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SEmYV6F9lNa4u0T2Yv-7i1f24qw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 08:07:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cQFtXkWexS2HSaC3DXtT89ANG8dkDSE8h Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 06/05/2014 09:20 PM, Bill Mills wrote: > Can't agree more with the peril of overloading auth information into an= > access token. Explain that a bit more, Bill. I think we should to provide a design rational so that a reader who has not participated in the standardization process understands the spec. Ciao Hannes --cQFtXkWexS2HSaC3DXtT89ANG8dkDSE8h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTmV7MAAoJEGhJURNOOiAt+BIH/jaQxqDPBFHAxy1CgTRVj2qj 8W7UPtHGR9ZixlByS1KXBrH+U1EdARrPwTndbqWhKKlmD0NELmD5pT5tp9R9C3Jj pcipWV3oHml7I5rjJ6W9y3KB8A7XdXlfCDnM1MIuYZFCzD1YFMOwb59C2ZuPv1Uy DtSwkSkZGj6dDjFyUTYWYBrY1IFnWncwNIVSQ7EiEy79Pz62ov13EEOq58hkN1rB 2GBcaQ+q7PBYYMpjUDQnjFZEYZE8r0u2gwyC+uElmwB//Bro+lXiL4hy8FL/+vIr to8IhJJEUzi8cYR6AM8Mk+J6gvdz7RixMm2UZikvbym9TFJRUHeHqSXuARs02Yw= =OnEz -----END PGP SIGNATURE----- --cQFtXkWexS2HSaC3DXtT89ANG8dkDSE8h-- From nobody Thu Jun 12 01:07:34 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EC01A02B3 for ; Thu, 12 Jun 2014 01:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8GO9SD_6sXm for ; Thu, 12 Jun 2014 01:07:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350321A0034 for ; Thu, 12 Jun 2014 01:07:28 -0700 (PDT) Received: from [192.168.131.139] ([80.92.115.174]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MVedf-1XG6cA2d83-00Yyzr; Thu, 12 Jun 2014 10:07:21 +0200 Message-ID: <53995F27.7090903@gmx.net> Date: Thu, 12 Jun 2014 10:04:55 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Torsten Lodderstedt , Bill Mills References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sUuTlSX1nqMo0MIow4He2JcUM9PT88G82" X-Provags-ID: V03:K0:csTdZGN3PYFCvk47QuNr1/OFoyxLqfCrxmlhuhpBKp9a8tduNv7 jInBrGG7gbuy9k3NOKk3Il26qqu3/K+r7W42dhDRbsl/KAlyFQPaxgotDGXJ4dna7oZ4rvt 2cmOylowTLC82FYjbjyQ3ZXUTdsax7+2bnZqedhZaW+bZoCSrXj97D0gwqhCxw9FjY62A9J 0Kd4eid0fftLIfDN9GhjA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/IkonogyQDqVyqF-tXQGpXRRDhLo Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 08:07:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sUuTlSX1nqMo0MIow4He2JcUM9PT88G82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Torsten, nobody suggested that the access token would suddenly not be opaque to the client. The question therefore is whether the id token is not opaque to the client. Is that the assumption? On 06/05/2014 09:39 PM, Torsten Lodderstedt wrote: >=20 > the access token is opaque to the client. That's great! Let's keep it > that way. Ciao Hannes --sUuTlSX1nqMo0MIow4He2JcUM9PT88G82 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTmV8nAAoJEGhJURNOOiAtWfIH/0RekV6Q9JW4ab6xQnJyq9FK pUkDpt5j64LxKxZfUIWOLKqik/h/xtzb6RF8eZNxa14TjmICMN9JfIJh5a0L7Dbd c70DMid7B56LT3o2aDrh4x2i2QgcqDu8w8Qxh2qHsHol9HpG7unOVQVRdcOBVXka J8WXNXtkd1IWiq4bCoNLUmRQXmYJx/bCc9tkodi90JB2M3K4RXOIxyjC9KOdlssr xuCPYnIE3l3GYtYMFJ9dKoquQrt/U43J01Wru1gxIBY4DLfbLOatIwZN5D+TTlIz 7zuhrFpXEfTsb7Y3lcZ2rPfH3Osd0ABdnibDg5h16xBMy+yP/FRK9UxIVdjT074= =KRCv -----END PGP SIGNATURE----- --sUuTlSX1nqMo0MIow4He2JcUM9PT88G82-- From nobody Thu Jun 12 01:13:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325FF1A02B3 for ; Thu, 12 Jun 2014 01:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w--bB-ChgRFm for ; Thu, 12 Jun 2014 01:13:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1771A0034 for ; Thu, 12 Jun 2014 01:13:18 -0700 (PDT) Received: from [192.168.131.139] ([80.92.115.174]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MSHax-1XJNiZ1Qvz-00TXgb; Thu, 12 Jun 2014 10:13:08 +0200 Message-ID: <5399607E.4060009@gmx.net> Date: Thu, 12 Jun 2014 10:10:38 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bill Mills , Anthony Nadalin , Torsten Lodderstedt References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> <482eb1c40dbb4da08dfb0d64879fac70@BLUPR03MB309.namprd03.prod.outlook.com> <1401997959.33382.YahooMailNeo@web142801.mail.bf1.yahoo.com> In-Reply-To: <1401997959.33382.YahooMailNeo@web142801.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0wjLqNMGoVe5lHV7RoNWfqP8H1us59ArU" X-Provags-ID: V03:K0:kEpMCGixRHf9vvZpczKJ1XlcdAQilNAxzaBB9gzbpqd6+J67nec vzwnxrB1zFjzLMBQYnEDgAdUga84dTEMGCzekmVkJ+ieGEDzMQGNZH0ILShRGprVBRXqqr7 MjFLZsTLEPBykFl933QU6PrD46bijgmOlay6eivc1Ki0ntTjU6xklRKsleuVdMN8SWSkofG M13kB5jJpdnqsfSbkWADw== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8kypz_LYar8bJHBU45tYIA-LwTM Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 08:13:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0wjLqNMGoVe5lHV7RoNWfqP8H1us59ArU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The token introspection is useful when you use an access token that is just a reference (instead of passing the values around using a JWT). Using token introspection on the access token to get the content of the access token in addition to the ID token will still get you the same data twice (at least in the way it is currently defined). On 06/05/2014 09:52 PM, Bill Mills wrote: > If you need user info based on an access token the introspection > endpoint is the right way to go. Even so, there's issues with using an= > access token as an authenticator and this is a major reason why OpenID > is the right way to go for authn. --0wjLqNMGoVe5lHV7RoNWfqP8H1us59ArU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTmWB+AAoJEGhJURNOOiAt5kAIAKX9MUirDo2M1LnT+SD0fRLG 8dMKagrV2/elG2ltFiKRT5ba7BBQnasE4Vl0vo2hVBjbWQ1rjLuniO8Z2kktYbBm plOI3H9JduraUBkP6TFaaQWa9sCWNzgDtoAgU44rvOWffbibQVfPNoB8Hi12aSRL 3/nOQmxghAX5CYEp/9D9MFpwEW3kzPsVnkJQeLiZUkpI7rmdT6WPxOzKJYzgPbEp aC43w0Z+FH4mlasDE6JEODO3rwSxzgP59V4E7kGVTOxlxJUAsJ00UNMGlgvurMK2 tQGxzw6o3lhD4JMNwmSuQR4meD8RyodEqQskBbSk53ptyYkYmru1PjAROg9SdEU= =puHn -----END PGP SIGNATURE----- --0wjLqNMGoVe5lHV7RoNWfqP8H1us59ArU-- From nobody Thu Jun 12 01:16:49 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65441A03F8 for ; Thu, 12 Jun 2014 01:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIR3uqpT64MC for ; Thu, 12 Jun 2014 01:16:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F0E1A039B for ; Thu, 12 Jun 2014 01:16:46 -0700 (PDT) Received: from [192.168.131.139] ([80.92.115.174]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LeSOH-1WOxcN3tKX-00qAx1; Thu, 12 Jun 2014 10:16:43 +0200 Message-ID: <53996151.7040908@gmx.net> Date: Thu, 12 Jun 2014 10:14:09 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Bradley , Anthony Nadalin References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> <482eb1c40dbb4da08dfb0d64879fac70@BLUPR03MB309.namprd03.prod.outlook.com> <16ef7d8f45ff463fa6d60b913a5a4053@BLUPR03MB309.namprd03.prod.outlook.com> <7C84F640-ABC2-4838-9A01-91167167C84F@ve7jtb.com> In-Reply-To: <7C84F640-ABC2-4838-9A01-91167167C84F@ve7jtb.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BWKGGCWslSI6D3ol1curaxa55rtAImw0o" X-Provags-ID: V03:K0:MtzCBUyRBZWjOXYEuSyqRPCkETZSh6jWBdnlz3Qu9oeis54y5QC q+TurVuNGmTfTzFpHPAXrcPx7XQqLpFb+zkslHM+Z8MDdu7SOF80wm9G3IDG/UevNqvT4h0 MUG0RBcGDIQLTp35fDjoYJV1lAnAM+wfbhBlYvJUsT1GexTlBOPZj1th66C8wtpHIfkiAJO tRzCfDzRVFywiuGkzSJWQ== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zjWYFUuiPAcUQIaDCnshH8ezG70 Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 08:16:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BWKGGCWslSI6D3ol1curaxa55rtAImw0o Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Only a short note: We haven't standardized a delegation mechanism yet and the proposals we had discussed in the past did not require the client to understand the content of the access token even for delegation.= Having said that I would like to note that it still required the AS to send additional information to the client. Other protocols that support delegation, like Kerberos, have included the information in the same ticket (just in the unencrypted part of the payload). Ciao Hannes On 06/05/2014 10:19 PM, John Bradley wrote: > Using structured access tokens to do delegation or convey other claims > to the RS can and should be separate from the assertions delivered to > the client. >=20 > The tokens will have different audiences and if using Proof of > Possession different presenter key material. >=20 > Using one token for both things may work in the simplest use case but > breaks a lot of things in OAuth. >=20 > John B. --BWKGGCWslSI6D3ol1curaxa55rtAImw0o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTmWFRAAoJEGhJURNOOiAt0OkH/0grGzNSuhby8C+x7bEcYEFt ZYsxSI2vEdXhK5LrzXpMkZ7fN2QOgrpI7UcvcAVA+6TPTvvhleP9AeLeFo5EayBC x4CNlwBqKG4rC8HHjBFqNFIYGfOEg7IOXjz7yI1DJTxuXfj1s7N+zYdGhGIsRwar MpMQWHmTkOsp00oaFcvZAookShTfVMmO09c5Q/ycWElp0l9IbxhMdFfD4xXyg/8u q04HFFHu39ed+1zyyo04pFPqORArcWfQYShk9lWnbsPnLCcV4yrSJSGE67a3NJjM WO7ZAtpDTAdKd0HEfGEEdje/At+Q2dgIwY4aqIGkA5bKWxIBd3LKCzOKWNmIBlo= =dY4Q -----END PGP SIGNATURE----- --BWKGGCWslSI6D3ol1curaxa55rtAImw0o-- From nobody Thu Jun 12 01:18:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9958A1A03F8 for ; Thu, 12 Jun 2014 01:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93lvqqJg2CFr for ; Thu, 12 Jun 2014 01:18:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA3E1A0199 for ; Thu, 12 Jun 2014 01:18:44 -0700 (PDT) Received: from [192.168.131.139] ([80.92.115.174]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Mhej1-1X8QKV0XFj-00Muss; Thu, 12 Jun 2014 10:18:36 +0200 Message-ID: <539961C1.5090900@gmx.net> Date: Thu, 12 Jun 2014 10:16:01 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Bradley , Michael Jones References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <82451287-4FF0-456C-AC2B-84CB6823E46E@ve7jtb.com> In-Reply-To: <82451287-4FF0-456C-AC2B-84CB6823E46E@ve7jtb.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Lv8JGXUVwg2o7T4Ac99IFlCmsGpr5BW5r" X-Provags-ID: V03:K0:biO2HOBMYFu/upljL5rsWWgvjDrEVjhe8CzpzuFCrnnST49lWAI cy5GoofBFAfnNGmFBrg7IFgUJP5FHV4ZlLepc8f/f8mcCfCtIiC28sm8aUhWttPXEILQOYv k97w2DjeUd/9XLcd6Rg7sI2m4x3a/5HKFjpSzQ87TeWr8myCLMdpJORo9dH+rtRn4e9PLsi ig0mnpJS+P6+FmUN4S+wA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/dRg0M9rN9wLXQ6AN5yIiRIhFTqA Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 08:18:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Lv8JGXUVwg2o7T4Ac99IFlCmsGpr5BW5r Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The argument about confusing draft-hunt-oauth-v2-user-a4c-03 with the OpenID Connect work is indeed something to be careful about. Maybe this could be addressed by more precisely capturing the differences in a section of the document. Ciao Hannes On 06/05/2014 10:11 PM, John Bradley wrote: > Looking at the latest draft http://tools.ietf.org/html/draft-hunt-oaut= h-v2-user-a4c-03 it is better. >=20 > As far as I can see he deltas from Connect Basic profile are: > 1 A new response_type "code_id_token" (I think the similarity to the "= code id_token" response_type may cause some confusion but that can be sor= ted out.)=20 > 2 a new request parameter "min_alv" (I think min_alv=3D"2" is isomorph= ic to acr_values=3D"4 3 2" so having 2 ways to make the same request may = not be ideal, but that can be debated.) >=20 > In Connect we probably would have added a way to get id_token only from= the token endpoint but RFC6849 requires a access token be issued for a g= rant_type of authorization_code. >=20 > I think to be consistent with RFC6849 a new grant type needs to be defi= ned. >=20 > In previous discussions returning a access token with no scopes was con= sidered easier than trying to explain a OAuth flow with no access token. = > This needs discussion. >=20 > Other than that Mike has done a good job of reconciling a4c with Connec= t Basic profile. >=20 > This spec on it's own would not allow you to do any sort of scalable SS= O, as the trust model is unspecified other than trusting the JWT based on= the TLS cert of the token endpoint. > I think there needs to be some validation of issuer if there is more th= an one the client is dealing with.=20 >=20 > It is Shorter than Connect basic because it leaves out interoperating w= ith multiple IdP and user attributes. >=20 > I don't hate it, but don't know that it adds much, other than possible = confusion and future extensions that are incompatible with Connect. >=20 > It is however better than it was. >=20 > John B. >=20 > On Jun 5, 2014, at 1:46 PM, Mike Jones wr= ote: >=20 >> Hannes, the Access Token and ID Token do quite different things and ha= ve different structures and properties. The Access Token is an opaque va= lue that grants access to resources. An ID Token is a non-opaque JWT sec= urity token that makes claims about the authentication that occurred. Yo= u can have one without the other or you can have both, depending upon the= use case. Thus, trying to move information between them would be proble= matic in several regards. >> >> Also, trying to overload the Access Token to convey authentication inf= ormation has been demonstrated in practice to be fraught with peril, and = has resulted in some of the most prominent security breaches related to t= he misuse of OAuth. >> >> -- Mike >> >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt >> Sent: Thursday, June 05, 2014 8:54 AM >> To: Hannes Tschofenig >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4= c >> >> You are correct. Just adding to access token would make a lot of devs = happy and that certainly should be discussed.=20 >> >> Two requirements issues: >> >> 1. A key use case is passing auth ctx only. An access token means aski= ng for consent to access something. This causes many sites to loose new u= sers. Authen only can be implicit consent.=20 >> >> 2. Compatibility with OpenId ID Token and flows.=20 >> >> 3. There is a need to support re-auth and MFA/LOA negotiation. Eg web = site would like to obtain a higher level of assurance for a higher risk a= ction.=20 >> >> The non-tech requirement is the soln must be received by client and se= rvice provider developers as easy to implement in addition to 6749 or eve= n OAuth 1.1a. I mention it because devs feel this should be trivial. You= r suggestion of adding to access token certainly fits this.=20 >> >> Phil >> >>> On Jun 5, 2014, at 0:44, Hannes Tschofenig wrote: >>> >>> Hi Phil, >>> >>> thanks for producing this document write-up. I have a somewhat basic = >>> question regarding the document. >>> >>> The id token contains the following mandatory information: >>> - sis: issuer >>> - sub: subject >>> - aud: audience >>> - iat: issued at >>> - exp: expiry >>> - auth_time: time when the end user was authenticated >>> >>> An access token (when encoded as a JWT) may contain all these fields = >>> except the auth_time (since auth_time is not defined in the JWT spec)= =2E >>> >>> Given that your proposal actually does not define the authentication = >>> protocol to be used between the resource owner/end user and the=20 >>> authorisation server I am wondering whether it would be possible to=20 >>> just add the auth_time parameter (and maybe some of the optional=20 >>> parameters) to the access token. Then, you can skip the id token. >>> >>> How do I come up with that question? In Kerberos, for example, the=20 >>> above-listed information is carried within a single container (within= =20 >>> the ticket) and so I am curious to hear why we have to send the=20 >>> information twice in OAuth (once in the access token, when the info i= s=20 >>> passed per value, and again via the id token). >>> >>> Maybe I missing something important here. >>> >>> Ciao >>> Hannes >>> >>> >> >> _______________________________________________ >> 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 --Lv8JGXUVwg2o7T4Ac99IFlCmsGpr5BW5r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTmWHCAAoJEGhJURNOOiAt2QEH/1GbFC9ZueAtXBC1fPG7Q7qW 7BXvdC/cZA83kpyeU4dyakHb+RB9gz1HXtRXIup4mrid9N3PC/n1+oeudD3RfesJ wa3p1FXPq6Lv/ZwI7JeBG4tZ6/+HA049hOu1eYX4ADdijhsIJEzMtXscbjVxHMsf 21iaKlL7s6P9r3cVAa0spnDfIKSPBlPtfgnba7ig//jylsPSs5T/QubGosjkbW/z pb9Zs323yydC34sRY3YglgbxpUSSfXTDG5Z0IyG344ruLxmgvne9A7R7TB+G+/o4 awhuDvuQID8fLKwwq2HeKKvnLUoLB8Vwp4rMzADxaWaoQeyh1mQ5fO3lnRDlxrY= =W2g7 -----END PGP SIGNATURE----- --Lv8JGXUVwg2o7T4Ac99IFlCmsGpr5BW5r-- From nobody Thu Jun 12 01:30:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EAB1A0415 for ; Thu, 12 Jun 2014 01:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juizLI5SclUe for ; Thu, 12 Jun 2014 01:30:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8521A02B3 for ; Thu, 12 Jun 2014 01:30:01 -0700 (PDT) Received: from [192.168.131.139] ([80.92.115.174]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M0tr1-1WcelN3i99-00v6vh; Thu, 12 Jun 2014 10:29:59 +0200 Message-ID: <53996461.7080507@gmx.net> Date: Thu, 12 Jun 2014 10:27:13 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Kathleen Moriarty , oauth@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SjDtbpWQtPRUQkSJjoasednoBFGGUaVel" X-Provags-ID: V03:K0:HjsSvfz59PhTpfZSc8/8MrlxruHmIVNaGc0HPkxuedp6jWYOpR7 dHKxV84hQZ4UDdVWOR2T+Rj3zSflTIYFpT6WMr9aH9qtvAUjmj0Llch7gXlfMskPb3Y+VFW S+//UuY0c9adfwCmAquwA4pAZ6i5RWJl+WM7L0BLpWVJKuym8j3q//Cgw/mdxtvcCAoumSD 6kCaN6SolwMaGeYBxJEKw== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JIZwXQU3z--XdDGz16pJa763ens Subject: Re: [OAUTH-WG] JWT review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 08:30:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SjDtbpWQtPRUQkSJjoasednoBFGGUaVel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Kathleen, on the first item I have a few minor remarks: You wrote: " As I read through the Algorithms (JWA) draft there are some changes that will need to be made to avoid problems during the IESG review. This is a pretty big change for the draft, but will help make the review and approval faster. Typically, the lists of algorithms are handled through a draft update as opposed to creating an IANA registry. A good example is a recent update of a draft in the IPSECME working group so you can see the structure and the precedence for this model. " The IANA registry for the algorithm serves a different purpose than a document recommending the specific algorithms. The reference to the IPSECME document only provides the latter. It is also important to note that the JWA not only defines the algorithm tags for the IANA registry but also explains how they actually work with the JOSE defined JSON structures (which is again a difference to the mentioned IPSECME document= ). Of course, the JWA document does both via the IANA registry and there is the question about how these recommendations would then get updated and what the consensus process is. In an mail to the JOSE mailing list I argued against any MTI recommendations since JOSE is a baseline technology that will be used in a variety of different contexts and it is super likely that the algorithm requirements will hugely vary. I am just thinking about what algorithms I would recommend when using the JOSE work in an IoT environment. My recommendations would deviate from the currently given recommendations, which are largely impacted by the Web community. Here is the mail I sent to the JOSE list: http://www.ietf.org/mail-archive/web/jose/current/msg04032.html So, my recommendation is to 1) have no MTI requirements in the JWA spec 2) remove the 'JOSE Implementation Requirements' column from the IANA registry. Ciao Hannes On 06/09/2014 06:17 PM, Kathleen Moriarty wrote: > Hello, >=20 > I am in process of working through the JOSE drafts and also read the > Oauth JWT draft last week. There is some overlap in text that may > require some joint work to correct. >=20 > 1. For JWT, the Security Considerations section starts off with the sam= e > text that is in several of the JOSE drafts. In my review of the JWA > draft, I asked for some fixes that will need to be made to this draft a= s > well. Here is a link to that review and it may be easier to help with > this work in one spot where text will be reused. Mike has asked the > JOSE WG to assist, but it make make sense for Oauth folks to help as > well. If it makes sense, a pointer to existing text is also fine. >=20 > http://www.ietf.org/mail-archive/web/jose/current/msg04064.html >=20 > 2. Sections 5.1 and 5.2 are a little confusing. However, the use of > "typ" and "cty" appear in 3 drafts (at least), so this should get > addressed with an approach that considers the joint text to reduce > confusion for developers. The initial descriptions are in the JOSE JWS= > draft, so that may need most of the work, but it also appears in this > draft and the JOSE JWK draft. In my writeup for the JWK review, I > listed out some questions and would like to see improvements across > these drafts. This will likely require some joint work and may be best= > in response to the JWK review to keep it in one place. >=20 > http://www.ietf.org/mail-archive/web/jose/current/msg04172.html >=20 > Thank you! >=20 > --=20 >=20 > Best regards, > Kathleen >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --SjDtbpWQtPRUQkSJjoasednoBFGGUaVel Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTmWRiAAoJEGhJURNOOiAtkpYH/i23Ipf9yg3mhfBpGLTUM6Im hTYRkqolY25Fs/oK46+g2Mqbqdz/llxlcfQOGbtGt5X/wcUSvFvBoIOqc9ncVsPX 7+RZKFrwfmaoIgSNLDDaOSE4I0QBWlbMyVGSV724mm/D/FhVikV8gNo1n2Z1DRX1 6D8qrf0gX1grdPeGjkOtE5hGK0Yqt/JoaaRhvrDVMClga90CyhjgNxrj0wDBGpCW wssn/mTfHB6EzEqNl0I5kImYWnDfY5VzN8AS3aYYtW1S40qLUbOIW0gt6tPyzhzq zcIWV7XIQPH4bfmn7cvXK/X1DqAX0EtI37Q/O+rWxdOiaLp623Gdv50cMYiXL5E= =leqq -----END PGP SIGNATURE----- --SjDtbpWQtPRUQkSJjoasednoBFGGUaVel-- From nobody Thu Jun 12 06:26:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF7E1B2A17 for ; Thu, 12 Jun 2014 06:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZyKlfiW-ipw for ; Thu, 12 Jun 2014 06:26:09 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE2C71B2A18 for ; Thu, 12 Jun 2014 06:26:08 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id k15so1641065qaq.30 for ; Thu, 12 Jun 2014 06:26:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=AjyNydJiTRlbJg0nJd2uhUYobXHQxde1gEqdQe9YkXI=; b=e2ia473fcig04eowVPJhYMjtESBvebB7a7PD4YpsRYpVB1ZlrW5ke7Mo5jCr+XnDFh G4mqgrLC1MsXSOeuRvFOvb9Wh3JP3CY6up8lLMxEw6szkOIJ+a4V9TGiqRxRwYkuTdJ5 0Z8Ttqr79emMIXdEzNX14y8LH1qPdrS5xkVeVic9nKwgUjQiLKXM4iD1fncR5pFMw+tD lHHQcuy96KCMbfTwnlH+brFUVszeD2BQeh75e2O+XwOrGVb+GHsj51PDQzd+N4IlzCu+ L3eO7Zm+k1ykfpDf29DDqc8CkhebLTWaF1z+DinzlU/iApRWgf1Hl5ZW/lTF1EDia2MZ tViw== X-Gm-Message-State: ALoCoQnSDiZVtInjQ7IVm1FZzWIwl2jR2oEP0WiaUxqQ5DSZhfO87vHYyJkNDWz3w+QLa95c7OE8 X-Received: by 10.140.44.34 with SMTP id f31mr57454867qga.73.1402579567753; Thu, 12 Jun 2014 06:26:07 -0700 (PDT) Received: from [192.168.1.41] ([190.22.105.161]) by mx.google.com with ESMTPSA id 8sm1474387qak.16.2014.06.12.06.25.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 06:26:06 -0700 (PDT) References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53995F27.7090903@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: <53995F27.7090903@gmx.net> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-97C2D825-A16D-4224-A6B5-B3199B31FD33; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D201) From: John Bradley Date: Thu, 12 Jun 2014 09:25:00 -0400 To: Hannes Tschofenig Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/1JfIcYqCiIfLO5X3Fu35gDhjQms Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:26:10 -0000 --Apple-Mail-97C2D825-A16D-4224-A6B5-B3199B31FD33 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The Id_token is audienced to the client. It is not sent to a resource serve= r. In a4c there may be no access token or resource server.=20 The id_token is not opaque to the client.=20 John B.=20 Sent from my iPhone > On Jun 12, 2014, at 4:04 AM, Hannes Tschofenig = wrote: >=20 > Torsten, >=20 > nobody suggested that the access token would suddenly not be opaque to > the client. >=20 > The question therefore is whether the id token is not opaque to the > client. Is that the assumption? >=20 >> On 06/05/2014 09:39 PM, Torsten Lodderstedt wrote: >>=20 >> the access token is opaque to the client. That's great! Let's keep it >> that way. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-97C2D825-A16D-4224-A6B5-B3199B31FD33 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNjEyMTMyNTAwWjAjBgkqhkiG9w0BCQQxFgQUsEP0YcgIckVe8YgV tr+cCgmVYcQwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEABuqSm6u1LP7Tpe+ARr6TBTmsVWT2CJZAO0sbbWqKbA0au0z7 6MGJ2AeZoVw8QgrQpbSlC3EIFs0HJ4N0LmHS3kNHUnnqkwO6Zbzzk+cKs8p89YeJxxm6OKADggF8 L/c/jEq4AMp7DbFNJVm1kx97BLtuahuLFJdR5gxISXRsCeyXWPgcAMkN3v4rU/HQgzyr9JpLgsON P/gtR84tbmjtw6L2RgrLYHMwi9CR/TpO/6JhJGfiYyVmRdhxVDKTTjfsewpFaNQ0pjgu5pu07oGJ jedmUP73fYiuBhr6vx3bgNGd5kOSrU6xNLr1gtjqSZob+NSfFxbD/S/Mr8euQ5t8sAAAAAAAAA== --Apple-Mail-97C2D825-A16D-4224-A6B5-B3199B31FD33-- From nobody Thu Jun 12 06:30:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE001B2A1B for ; Thu, 12 Jun 2014 06:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdXXCj--KPG6 for ; Thu, 12 Jun 2014 06:30:42 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9F11B2A20 for ; Thu, 12 Jun 2014 06:30:42 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id w7so1882609qcr.16 for ; Thu, 12 Jun 2014 06:30:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=48M68+6Fe+lGrClKwsag10hUSzohpBu80uYi0GiaThw=; b=Id9hyk8meDOl7qnKDpnYWm37J6PHxYca2CslC8thCZ5dc/DpOdppXpFQ5M7rbpLk09 m7v5+oAgkzXibnQqsGnGsHL24e5ZbW3TKEIGhya9hExfXY3Zt3Y0R30aqtLs7J/i9wUa wQbqdTjOUMtgEPUu8T8QjnU9cKJGTjwbC4qy5lpnLjC5ImBSrMsUiiO25vouEUDlZa61 WFtzxP53MYUNzqRHJnfBTg5wyw+xpZVR2Ed39iC8rW/VLLUXGy/eZ1z7aQtOj4dH84Tn Ll4O3NxaxeNmFEAfQ8CR9zS6pnuzjTie6oEUxoKxYEATSzE6K2f31+JeHGgeCx2Ni7KC xTjg== X-Gm-Message-State: ALoCoQkF6u0wiaoMI7P9gtJJqPkCrcHQpOGd0GW5RkeQ3B7OLNWWijyaTTosI2sHKAJ6gVRgSf3J X-Received: by 10.224.151.82 with SMTP id b18mr61246371qaw.27.1402579841460; Thu, 12 Jun 2014 06:30:41 -0700 (PDT) Received: from [192.168.1.41] ([190.22.105.161]) by mx.google.com with ESMTPSA id c35sm4620656qgd.47.2014.06.12.06.30.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 06:30:40 -0700 (PDT) References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> <482eb1c40dbb4da08dfb0d64879fac70@BLUPR03MB309.namprd03.prod.outlook.com> <16ef7d8f45ff463fa6d60b913a5a4053@BLUPR03MB309.namprd03.prod.outlook.com> <7C84F640-ABC2-4838-9A01-91167167C84F@ve7jtb.com> <53996151.7040908@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: <53996151.7040908@gmx.net> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-AA33B3CD-0551-4DF1-A1AA-29EF70E2A7A4; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D201) From: John Bradley Date: Thu, 12 Jun 2014 09:30:32 -0400 To: Hannes Tschofenig Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/q5A1G8iD1bBmkKNTkv_DNGubMts Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:30:44 -0000 --Apple-Mail-AA33B3CD-0551-4DF1-A1AA-29EF70E2A7A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The response from the token endpoint has multiple parameters. =20 There is no reason to put information the client needs in the access token.=20= That creates more problems than it solves.=20 John B.=20 Sent from my iPhone > On Jun 12, 2014, at 4:14 AM, Hannes Tschofenig = wrote: >=20 > Only a short note: We haven't standardized a delegation mechanism yet > and the proposals we had discussed in the past did not require the > client to understand the content of the access token even for delegation. >=20 > Having said that I would like to note that it still required the AS to > send additional information to the client. Other protocols that support > delegation, like Kerberos, have included the information in the same > ticket (just in the unencrypted part of the payload). >=20 > Ciao > Hannes >=20 >> On 06/05/2014 10:19 PM, John Bradley wrote: >> Using structured access tokens to do delegation or convey other claims >> to the RS can and should be separate from the assertions delivered to >> the client. >>=20 >> The tokens will have different audiences and if using Proof of >> Possession different presenter key material. >>=20 >> Using one token for both things may work in the simplest use case but >> breaks a lot of things in OAuth. >>=20 >> John B. >=20 --Apple-Mail-AA33B3CD-0551-4DF1-A1AA-29EF70E2A7A4 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNjEyMTMzMDMzWjAjBgkqhkiG9w0BCQQxFgQUqRV9d3Ne10k5m1kA IqnIyhXjzlQwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAtGlx+cAFlMnuG+7ZtntnWQvvxRQ0XE0bKtCCaD7zZW1h+rAm 8iB/WXG1EUhbSwGORl6F+7BZh27z+x8X4e0GkDaGOSfpBXEv8ybtXhgsM0CGhDaM6KRk+UI/sOks nOA3JhEe8TAtqtaT6dOUz0JNxvDS5LZ0VJZBXBZzpNyYreMTO0vTmQa3p6LWkr4es4M2A/HiGvHx Uzqy8T7LWyYJeGhm9UQWGVCs4G6ZfxulAkzcWQXLB+gN9k5iOVgUm6Zn4mFhTGTQR3OXK92gvLJ7 UYqSRMseiikWeXFrjHzgCFfLN1AYKXQh3NnX6A55ACIeI3QEqPylp+g6Fr8QZA/WDwAAAAAAAA== --Apple-Mail-AA33B3CD-0551-4DF1-A1AA-29EF70E2A7A4-- From nobody Thu Jun 12 06:30:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F63E1B2A2F for ; Thu, 12 Jun 2014 06:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJlSvwLrtsg1 for ; Thu, 12 Jun 2014 06:30:48 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C28D1B2A1B for ; Thu, 12 Jun 2014 06:30:48 -0700 (PDT) X-AuditID: 12074425-f79746d000000ecc-4c-5399ab87114b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 3B.FF.03788.78BA9935; Thu, 12 Jun 2014 09:30:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s5CDUjVF007233; Thu, 12 Jun 2014 09:30:46 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s5CDUhfV030295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 12 Jun 2014 09:30:44 -0400 Message-ID: <5399AB7C.5060508@mit.edu> Date: Thu, 12 Jun 2014 09:30:36 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Bradley , Hannes Tschofenig References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53995F27.7090903@gmx.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090502080003020207090204" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixCmqrNu+emawQeMzYYulO++xWpx8+4rN 4s3C46wWq+/+ZXNg8Vi8aT+bx5IlP5k8bt/eyOIxa9ZhpgCWKC6blNSczLLUIn27BK6MGye3 Mha8U6+49fkwSwPjffkuRk4OCQETidM3+1ghbDGJC/fWs3UxcnEICcxmkni7YhIbSEJIYCOj xMLnRRCJ20wSR56vYQJJ8AqoSbzePQeoiIODRUBV4nwvB0iYDcicv/IWWImoQJTErr5f7BDl ghInZz5hAbFFBGIklt6fARZnFnCTaOpZArZLWMBdYm/vVSaIXW+ZJHqf3AVr4BSwk+hadZAV oiFM4vDG56wTGAVmIZk7C0lqFtBJzALWEt92F0GE5SW2v53DDGFrS6zqPcuELL6AkW0Vo2xK bpVubmJmTnFqsm5xcmJeXmqRroVebmaJXmpK6SZGUFywu6juYJxwSOkQowAHoxIPL0PtjGAh 1sSy4srcQ4ySHExKorw1HTODhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwmkwDyvGmJFZWpRbl w6SkOViUxHnfWlsFCwmkJ5akZqemFqQWwWRlODiUJHh/rgRqFCxKTU+tSMvMKUFIM3Fwggzn ARq+E6SGt7ggMbc4Mx0if4pRUUqc9wNIQgAkkVGaB9cLS1uvGMWBXhHmLV0FVMUDTHlw3a+A BjMBDX7tOR1kcEkiQkqqgVHY/dGi17Vf9IxdZul1FXMFdZ7Oe/Fb6v5hHsbmqm0OvQZ2jj1T yitne71a8fdz+8/ZiwIef60M3PDp1PcbZ1VTpkpsnukrpXzut2TA7P8T74mdnHli4tXV59Rs djLUfdc2e/t3gd8PbuHoj48NxWJ7ll4M3FPu8Sb8Gqd7c1e424ug+x3321SVWIozEg21mIuK EwFykp+7NgMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8hK_PSdya3_ivWioeREFRVHLSGc Cc: Phil Hunt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:30:55 -0000 This is a multi-part message in MIME format. --------------090502080003020207090204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Right, and the original question in this part of the thread was "why bother with an ID token, why not just re-use the access token for both purposes?" Torsten's response below was in answer to that -- merging these two would make the access token non-opaque to the client. This is undesirable for many reasons. We had this discussion years ago in the OIDC working group (several times) and came to the same conclusion there (several times). Which goes to further the point that the A4C draft is simply re-hashing work that's already been covered by OIDC, often incompletely and missing key functionality required for interoperability and security, and adding nothing new or valuable to the conversation. -- Justin On 6/12/2014 9:25 AM, John Bradley wrote: > The Id_token is audienced to the client. It is not sent to a resource server. In a4c there may be no access token or resource server. > > The id_token is not opaque to the client. > > John B. > > Sent from my iPhone > >> On Jun 12, 2014, at 4:04 AM, Hannes Tschofenig wrote: >> >> Torsten, >> >> nobody suggested that the access token would suddenly not be opaque to >> the client. >> >> The question therefore is whether the id token is not opaque to the >> client. Is that the assumption? >> >>> On 06/05/2014 09:39 PM, Torsten Lodderstedt wrote: >>> >>> the access token is opaque to the client. That's great! Let's keep it >>> that way. >> Ciao >> Hannes >> >> >> _______________________________________________ >> 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 --------------090502080003020207090204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Right, and the original question in this part of the thread was "why bother with an ID token, why not just re-use the access token for both purposes?"

Torsten's response below was in answer to that -- merging these two would make the access token non-opaque to the client. This is undesirable for many reasons. We had this discussion years ago in the OIDC working group (several times) and came to the same conclusion there (several times).

Which goes to further the point that the A4C draft is simply re-hashing work that's already been covered by OIDC, often incompletely and missing key functionality required for interoperability and security, and adding nothing new or valuable to the conversation.

 -- Justin

On 6/12/2014 9:25 AM, John Bradley wrote:
The Id_token is audienced to the client.  It is not sent to a resource server.  In a4c there may be no access token or resource server. 

The id_token is not opaque to the client. 

John B. 

Sent from my iPhone


On Jun 12, 2014, at 4:04 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Torsten,

nobody suggested that the access token would suddenly not be opaque to
the client.

The question therefore is whether the id token is not opaque to the
client. Is that the assumption?


On 06/05/2014 09:39 PM, Torsten Lodderstedt wrote:

the access token is opaque to the client. That's great! Let's keep it
that way.

Ciao
Hannes


_______________________________________________
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

--------------090502080003020207090204-- From nobody Thu Jun 12 09:40:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8D31B27AA for ; Thu, 12 Jun 2014 09:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZlE_gDGsbW9 for ; Thu, 12 Jun 2014 09:39:56 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0CB1B27BC for ; Thu, 12 Jun 2014 09:39:55 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5CGdq37032697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2014 16:39:52 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5CGdpa2013125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 16:39:51 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5CGdoRr013055; Thu, 12 Jun 2014 16:39:51 GMT Received: from [192.168.10.74] (/74.7.240.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Jun 2014 09:39:50 -0700 Message-ID: <5399D7D0.4050807@oracle.com> Date: Thu, 12 Jun 2014 09:39:44 -0700 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , Mike Jones , Phil Hunt References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <53995D56.7040709@gmx.net> In-Reply-To: <53995D56.7040709@gmx.net> Content-Type: multipart/alternative; boundary="------------080109070009070509060305" X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Dcax4CpAHC-1mn7kFRT7nGH3Bbw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:39:58 -0000 This is a multi-part message in MIME format. --------------080109070009070509060305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 to Hannes comments. > Hi Mike, > > thanks for your quick response. > > On 06/05/2014 07:46 PM, Mike Jones wrote: >> Hannes, the Access Token and ID Token do quite different things and >> have different structures and properties. The Access Token is an >> opaque value that grants access to resources. An ID Token is a >> non-opaque JWT security token that makes claims about the >> authentication that occurred. You can have one without the other or >> you can have both, depending upon the use case. Thus, trying to move >> information between them would be problematic in several regards. > Regarding the different structure between the access token and the ID > token: As I tried to explain with my example they two may carry almost > the same information (if the access token carries the information per > value and uses the JWT encoding). > > Regarding the opaque nature: I think it is important to also add for > whom the tokens are opaque. From the text in the document the access > token and the ID token seem to be opaque for the client but they are not > opaque for the party generating them (=authorization server) and also > not opaque for the party consuming them (=resource server). > >> Also, trying to overload the Access Token to convey authentication >> information has been demonstrated in practice to be fraught with >> peril, and has resulted in some of the most prominent security >> breaches related to the misuse of OAuth. > The problems with the security breaches had nothing to do with the > encoding of the information in the token itself, which is what I am > referring to. > > Ciao > Hannes > >> -- Mike >> >> -----Original Message----- From: OAuth >> [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt Sent: >> Thursday, June 05, 2014 8:54 AM To: Hannes Tschofenig Cc: >> oauth@ietf.org Subject: Re: [OAUTH-WG] Question regarding >> draft-hunt-oauth-v2-user-a4c >> >> You are correct. Just adding to access token would make a lot of devs >> happy and that certainly should be discussed. >> >> Two requirements issues: >> >> 1. A key use case is passing auth ctx only. An access token means >> asking for consent to access something. This causes many sites to >> loose new users. Authen only can be implicit consent. >> >> 2. Compatibility with OpenId ID Token and flows. >> >> 3. There is a need to support re-auth and MFA/LOA negotiation. Eg web >> site would like to obtain a higher level of assurance for a higher >> risk action. >> >> The non-tech requirement is the soln must be received by client and >> service provider developers as easy to implement in addition to 6749 >> or even OAuth 1.1a. I mention it because devs feel this should be >> trivial. Your suggestion of adding to access token certainly fits >> this. >> >> Phil >> >>> On Jun 5, 2014, at 0:44, Hannes Tschofenig >>> wrote: >>> >>> Hi Phil, >>> >>> thanks for producing this document write-up. I have a somewhat >>> basic question regarding the document. >>> >>> The id token contains the following mandatory information: - sis: >>> issuer - sub: subject - aud: audience - iat: issued at - exp: >>> expiry - auth_time: time when the end user was authenticated >>> >>> An access token (when encoded as a JWT) may contain all these >>> fields except the auth_time (since auth_time is not defined in the >>> JWT spec). >>> >>> Given that your proposal actually does not define the >>> authentication protocol to be used between the resource owner/end >>> user and the authorisation server I am wondering whether it would >>> be possible to just add the auth_time parameter (and maybe some of >>> the optional parameters) to the access token. Then, you can skip >>> the id token. >>> >>> How do I come up with that question? In Kerberos, for example, the >>> above-listed information is carried within a single container >>> (within the ticket) and so I am curious to hear why we have to send >>> the information twice in OAuth (once in the access token, when the >>> info is passed per value, and again via the id token). >>> >>> Maybe I missing something important here. >>> >>> Ciao Hannes >>> >>> >> _______________________________________________ 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 --------------080109070009070509060305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1 to Hannes comments. 

Hi Mike,

thanks for your quick response.

On 06/05/2014 07:46 PM, Mike Jones wrote:

Hannes, the Access Token and ID Token do quite different things and
have different structures and properties.  The Access Token is an
opaque value that grants access to resources.  An ID Token is a
non-opaque JWT security token that makes claims about the
authentication that occurred.  You can have one without the other or
you can have both, depending upon the use case.  Thus, trying to move
information between them would be problematic in several regards.

Regarding the different structure between the access token and the ID
token: As I tried to explain with my example they two may carry almost
the same information (if the access token carries the information per
value and uses the JWT encoding).

Regarding the opaque nature: I think it is important to also add for
whom the tokens are opaque. From the text in the document the access
token and the ID token seem to be opaque for the client but they are not
opaque for the party generating them (=authorization server) and also
not opaque for the party consuming them (=resource server).


Also, trying to overload the Access Token to convey authentication
information has been demonstrated in practice to be fraught with
peril, and has resulted in some of the most prominent security
breaches related to the misuse of OAuth.

The problems with the security breaches had nothing to do with the
encoding of the information in the token itself, which is what I am
referring to.

Ciao
Hannes


-- Mike

-----Original Message----- From: OAuth
[mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt Sent:
Thursday, June 05, 2014 8:54 AM To: Hannes Tschofenig Cc:
oauth@ietf.org Subject: Re: [OAUTH-WG] Question regarding
draft-hunt-oauth-v2-user-a4c

You are correct. Just adding to access token would make a lot of devs
happy and that certainly should be discussed.

Two requirements issues:

1. A key use case is passing auth ctx only. An access token means
asking for consent to access something. This causes many sites to
loose new users. Authen only can be implicit consent.

2.  Compatibility with OpenId ID Token and flows.

3. There is a need to support re-auth and MFA/LOA negotiation. Eg web
site would like to obtain a higher level of assurance for a higher
risk action.

The non-tech requirement is the soln must be received by client and
service provider developers as easy to implement in addition to 6749
or even OAuth 1.1a. I mention it because devs feel this should be
trivial.  Your suggestion of adding to access token certainly fits
this.

Phil


On Jun 5, 2014, at 0:44, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:

Hi Phil,

thanks for producing this document write-up. I have a somewhat
basic question regarding the document.

The id token contains the following mandatory information: - sis:
issuer - sub: subject - aud: audience - iat: issued at - exp:
expiry - auth_time: time when the end user was authenticated

An access token (when encoded as a JWT) may contain all these
fields except the auth_time (since auth_time is not defined in the
JWT spec).

Given that your proposal actually does not define the
authentication protocol to be used between the resource owner/end
user and the authorisation server I am wondering whether it would
be possible to just add the auth_time parameter (and maybe some of
the optional parameters) to the access token. Then, you can skip
the id token.

How do I come up with that question? In Kerberos, for example, the
 above-listed information is carried within a single container
(within the ticket) and so I am curious to hear why we have to send
the information twice in OAuth (once in the access token, when the
info is passed per value, and again via the id token).

Maybe I missing something important here.

Ciao Hannes



_______________________________________________ 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


    

    

  


--------------080109070009070509060305--


From nobody Thu Jun 12 09:46:56 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3D61B27BA for ; Thu, 12 Jun 2014 09:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level: 
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyPqNnFCkpjR for ; Thu, 12 Jun 2014 09:46:51 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653131A01BF for ; Thu, 12 Jun 2014 09:46:51 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5CGkloX012271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2014 16:46:48 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5CGklEc019930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 16:46:47 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5CGkkXs019922; Thu, 12 Jun 2014 16:46:46 GMT
Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Jun 2014 09:46:46 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_84D697F0-8D1C-48FC-94C1-E402755EBC31"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Phil Hunt 
In-Reply-To: <53995BC3.1030802@gmx.net>
Date: Thu, 12 Jun 2014 09:46:43 -0700
Message-Id: <4401DD70-9082-4D38-B28A-1343F5CBF27D@oracle.com>
References: <53901F49.1010608@gmx.net>  <53995BC3.1030802@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1878.2)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wiP1y-OiFYdYy3Qy-6AsGQlXb9k
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 16:46:54 -0000

--Apple-Mail=_84D697F0-8D1C-48FC-94C1-E402755EBC31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hannes,

What I was attempting to describe regarding OpenID is an independent =
organization that controls an API. I think the problem with =93publisher=94=
 may be that there is confusion between publishing the software vs. =
publishing the API specification.  Either is appropriate.

OpenID seemed like a good use case as an SDO working with OAuth. =
However, I don=92t want to imply that OIDF needs to start issuing =
assertions. I did want to underline how this is beneficial to AS =
deployments of the Connect specs.  The main idea being that =
administrators can configure policy that says we can now accept any =
registration signed by OIDF that claims to be a client for Connect.  =
This means that AS end-points now have prior state to recognize any OIDF =
Connect client that knocks at the door.  In this sense, it replaces the =
client_id manual registration model of the past=85..

See if this line of thought makes better sense of an explanation. I can =
work up some text for the draft if people agree.

One important aspect is that the use of software statements reverse the =
issuing pattern of client_id but initially serve a similar function in =
recognizing clients.  In 6749, Section 2.2 describes the client =
identifier:=20
   The authorization server issues the registered client a client
   identifier - a unique string representing the registration
   information provided by the client.  The client identifier is not a
   secret; it is exposed to the resource owner, and MUST NOT be used
   alone for client authentication.  The client identifier is unique to
   the authorization server.

The software_statement replaces the client_id during the initial =
interaction (the registration flow) so that it may be exchanged for an =
individualized client_id assigned by the AS. By being signed, it enables =
a federated model where policy decisions can be made about the =
third-party statement. E.g. Is the software, the organization, the =
signer approved for use at this AS? Remember also, during the =
registration flow, we are not authenticating clients we are =
=93registering=94 them.  There=92s no infinite proof of existence =
claimed here.  8-)

Developers can also self-sign, but the functional characteristic is much =
more like what people do with (and the term escapes me), self-generated =
ssl tokens where public keys are exchanged on a pair-wise basis to do =
mutual-TLS.

On a security considerations front, statements hold the same =
characteristics/risks of the original =93public" client_id, except they =
are issued externally to the AS. Because they are more than a simple =
identifier, they have some advantage from a policy management =
perspective because they do not always require a prior registration =
record within the AS.  It is the act of =93registering=94 the software =
and generating a client_id that creates the confidential client in this =
case.

Is something along these lines a better way to explain this? I can take =
a shot and try to address the concerns.=20

I=92m worried, I=92m going in circles on this. Maybe there is a better =
approach?

Phil

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



On Jun 12, 2014, at 12:50 AM, Hannes Tschofenig =
 wrote:

> Hi Phil,
>=20
> thanks for your response. A few remarks below.
>=20
>>> I am particularly interested to learn who issues the initial
>>> access token and the software statement? What is the purpose? What
>>> does it authorize?
>>=20
>> These tokens have very different characteristics. The Software
>> Statement is not a security token. It is a statement that locks the
>> registration profile for client software and provides AS endpoints
>> with a way to recognize client software since they do not have a
>> client_id yet. In practical terms, AS endpoints can set policy to
>> automatically approve reject based on specific statement, or content
>> rules (software_id, version etc) or even approve based on the signer
>> of the statements (e.g. allow registration for any client software
>> statement signed by Cisco).
>=20
> The software statement is hopefully signed and you are going to make
> some security relevant decisions based on it. Whether you call it a
> security token or not does not really matter that much.
>=20
>>=20
>> Typically, the statement would be generated once (for all copies
>> distributed) by the developer, publisher, or a collective
>> organization.
>=20
> I think it would be useful to add information about who creates it,
> particularly since the document introduces these parties (at least the
> client developer, and the software API publisher).
>=20
> You might also expand a bit on what you mean by "generated once" to =
give
> guidance on when a new software assertion needs to be generated vs. =
when
> a previous one can be re-used.
>=20
>> This is particularly useful when the publisher of an
>> API  is not the same organization as the deployers of the actual API
>> endpoints following a common open API specification. For example,
>> OpenID Connect would be one such example.
>=20
> OpenID Connect would not have come to my mind here since OpenID =
connect
> is neither a client developer nor a software API publisher (at least =
in
> my understanding of the terminology defined in the dynamic client
> registration document).
>=20
>>=20
>> In the early OAuth1 and 2 days, most use cases had the API publisher
>> and the deployer as the same organization. A client_id could be
>> issued in advance and could be used as both credential id and
>> software identifier.  In the evolving world, we have lots of cases
>> (e.g. OpenID Connect) where the organization that defines the API
>> specification is not the same as the one operating implementations of
>> the API specification.  Client_id can=92t serve both purposes.
>> Software statement fills the gap allowing client software to use a
>> client statement =93claim=94 that can be =93exchange=94 for a =
deployment
>> assigned client_id.
>=20
> I think that this would be useful background motivation for the draft; =
I
> disagree with the mentioning of OpenID Connect based on my previous
> comment.
>=20
>>=20
>> Initial access token is a security token that allows the client to
>> register in a closed/restricted registration endpoint where anonymous
>> registration may not be allowed.  Useful in some environments where
>> an IT organization might re-package a client for distribution on an
>> internal or private system.
>>=20
>> Where the software statement is issued by either the developer or the
>> API specification organization, the initial access token is typically
>> issued by the =93domain=94 (or an organization affiliated with it) =
where
>> the client intends to register.
>=20
> Using the terminology from the dynamic client registration draft the
> initial access token is issued by the "Deployment Organization". This
> would be important information to add to the document!
>=20
> Ciao
> Hannes
>=20


--Apple-Mail=_84D697F0-8D1C-48FC-94C1-E402755EBC31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Hannes,

What =
I was attempting to describe regarding OpenID is an independent =
organization that controls an API. I think the problem with =93publisher=94=
 may be that there is confusion between publishing the software vs. =
publishing the API specification.  Either is =
appropriate.

OpenID seemed like a good use case =
as an SDO working with OAuth. However, I don=92t want to imply that OIDF =
needs to start issuing assertions. I did want to underline how this is =
beneficial to AS deployments of the Connect specs.  The main idea =
being that administrators can configure policy that says we can now =
accept any registration signed by OIDF that claims to be a client for =
Connect.  This means that AS end-points now have prior state to =
recognize any OIDF Connect client that knocks at the door.  In this =
sense, it replaces the client_id manual registration model of the =
past=85..

See if this line of thought makes =
better sense of an explanation. I can work up some text for the draft if =
people agree.

One important aspect is that the =
use of software statements reverse the issuing pattern of client_id but =
initially serve a similar function in recognizing clients.  In =
6749, Section 2.2 describes the client identifier: 
  =
 The
authorization server issues the registered client a =
client
   identifier - a unique string representing
the registration
   information =
provided by the client.  The
client identifier is not a
   secret; it is exposed =
to the resource owner,
and MUST NOT be used
   alone for client =
authentication.  The client identifier is unique to
  =
 the =
authorization server.

The =
software_statement replaces the client_id during the initial interaction =
(the registration flow) so that it may be exchanged for an =
individualized client_id assigned by the AS. By being signed, it enables =
a federated model where policy decisions can be made about the =
third-party statement. E.g. Is the software, the organization, the =
signer approved for use at this AS? Remember also, during the =
registration flow, we are not authenticating clients we are =
=93registering=94 them.  There=92s no infinite proof of existence =
claimed here.  8-)

Developers can also =
self-sign, but the functional characteristic is much more like what =
people do with (and the term escapes me), self-generated ssl tokens =
where public keys are exchanged on a pair-wise basis to do =
mutual-TLS.

On a security considerations front, =
statements hold the same characteristics/risks of the original =93public" =
client_id, except they are issued externally to the AS. Because they are =
more than a simple identifier, they have some advantage from a policy =
management perspective because they do not always require a prior =
registration record within the AS.  It is the act of =93registering=94=
 the software and generating a client_id that creates the confidential =
client in this case.

Is something along these =
lines a better way to explain this? I can take a shot and try to address =
the concerns. 

I=92m worried, I=92m going =
in circles on this. Maybe there is a better =
approach?

Phil

@independentid
www.independentid.com
phil.hu=
nt@oracle.com



On Jun 12, 2014, at 12:50 AM, Hannes =
Tschofenig <hannes.tschofenig@gmx.net>=
; wrote:

Hi Phil,

thanks for =
your response. A few remarks below.

I am particularly interested to =
learn who issues the initial
access token and the software statement? =
What is the purpose? What
does it =
authorize?

These tokens have very different =
characteristics. The Software
Statement is not a security token. It =
is a statement that locks the
registration profile for client =
software and provides AS endpoints
with a way to recognize client =
software since they do not have a
client_id yet. In practical terms, =
AS endpoints can set policy to
automatically approve reject based on =
specific statement, or content
rules (software_id, version etc) or =
even approve based on the signer
of the statements (e.g. allow =
registration for any client software
statement signed by =
Cisco).

The software statement is hopefully signed =
and you are going to make
some security relevant decisions based on =
it. Whether you call it a
security token or not does not really =
matter that much.


Typically, the =
statement would be generated once (for all copies
distributed) by the =
developer, publisher, or a =
collective
organization.

I think it would be =
useful to add information about who creates it,
particularly since =
the document introduces these parties (at least the
client developer, =
and the software API publisher).

You might also expand a bit on =
what you mean by "generated once" to give
guidance on when a new =
software assertion needs to be generated vs. when
a previous one can =
be re-used.

This is particularly useful =
when the publisher of an
API  is not the same organization as =
the deployers of the actual API
endpoints following a common open API =
specification. For example,
OpenID Connect would be one such =
example.

OpenID Connect would not have come to my =
mind here since OpenID connect
is neither a client developer nor a =
software API publisher (at least in
my understanding of the =
terminology defined in the dynamic client
registration =
document).


In the early OAuth1 and =
2 days, most use cases had the API publisher
and the deployer as the =
same organization. A client_id could be
issued in advance and could =
be used as both credential id and
software identifier.  In the =
evolving world, we have lots of cases
(e.g. OpenID Connect) where the =
organization that defines the API
specification is not the same as =
the one operating implementations of
the API specification. =
 Client_id can=92t serve both purposes.
Software statement fills =
the gap allowing client software to use a
client statement =93claim=94 =
that can be =93exchange=94 for a deployment
assigned =
client_id.

I think that this would be useful =
background motivation for the draft; I
disagree with the mentioning =
of OpenID Connect based on my previous
comment.


Initial access token is a security token that allows =
the client to
register in a closed/restricted registration endpoint =
where anonymous
registration may not be allowed.  Useful in some =
environments where
an IT organization might re-package a client for =
distribution on an
internal or private system.

Where the =
software statement is issued by either the developer or the
API =
specification organization, the initial access token is =
typically
issued by the =93domain=94 (or an organization affiliated =
with it) where
the client intends to =
register.

Using the terminology from the dynamic =
client registration draft the
initial access token is issued by the =
"Deployment Organization". This
would be important information to add =
to the =
document!

Ciao
Hannes


=

--Apple-Mail=_84D697F0-8D1C-48FC-94C1-E402755EBC31--


From nobody Thu Jun 12 09:49:48 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4981A01AA for ; Thu, 12 Jun 2014 09:49:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level: 
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY48TWpq0Fl3 for ; Thu, 12 Jun 2014 09:49:43 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6164C1A01AE for ; Thu, 12 Jun 2014 09:49:43 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5CGnd2Q015500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2014 16:49:40 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5CGnctr008729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 16:49:38 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5CGnbAI008699; Thu, 12 Jun 2014 16:49:37 GMT
Received: from [192.168.10.74] (/74.7.240.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Jun 2014 09:49:36 -0700
Message-ID: <5399DA1C.4090409@oracle.com>
Date: Thu, 12 Jun 2014 09:49:32 -0700
From: Prateek Mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Justin Richer , John Bradley , Hannes Tschofenig 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu>
In-Reply-To: <5399AB7C.5060508@mit.edu>
Content-Type: multipart/alternative; boundary="------------060604070809080606040304"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/B5vBkgBThhS5Qv_fAr5WFBSVCbI
Cc: Phil Hunt , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 16:49:45 -0000

This is a multi-part message in MIME format.
--------------060604070809080606040304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The OpenID Connect 2.0 COre specification alone is 86 pages. It has 
received review from maybe a dozen engineers within the OpenID community.

The a4c draft proposal is 15 pages and will receive review from 100s of 
engineers within the world's most advanced standards body the IETF.

It's a no brainer which specification is likely to have more bugs, 
complexity and security holes.

> Right, and the original question in this part of the thread was "why 
> bother with an ID token, why not just re-use the access token for both 
> purposes?"
>
> Torsten's response below was in answer to that -- merging these two 
> would make the access token non-opaque to the client. This is 
> undesirable for many reasons. We had this discussion years ago in the 
> OIDC working group (several times) and came to the same conclusion 
> there (several times).
>
> Which goes to further the point that the A4C draft is simply 
> re-hashing work that's already been covered by OIDC, often 
> incompletely and missing key functionality required for 
> interoperability and security, and adding nothing new or valuable to 
> the conversation.
>
>  -- Justin
>
> On 6/12/2014 9:25 AM, John Bradley wrote:
>> The Id_token is audienced to the client.  It is not sent to a resource server.  In a4c there may be no access token or resource server.
>>
>> The id_token is not opaque to the client.
>>
>> John B.
>>
>> Sent from my iPhone
>>
>>> On Jun 12, 2014, at 4:04 AM, Hannes Tschofenig  wrote:
>>>
>>> Torsten,
>>>
>>> nobody suggested that the access token would suddenly not be opaque to
>>> the client.
>>>
>>> The question therefore is whether the id token is not opaque to the
>>> client. Is that the assumption?
>>>
>>>> On 06/05/2014 09:39 PM, Torsten Lodderstedt wrote:
>>>>
>>>> the access token is opaque to the client. That's great! Let's keep it
>>>> that way.
>>> Ciao
>>> Hannes
>>>
>>>
>>> _______________________________________________
>>> 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


--------------060604070809080606040304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    The OpenID Connect 2.0 COre specification alone is 86 pages. It has
    received review from maybe a dozen engineers within the OpenID
    community.

    

    The a4c draft proposal is 15 pages and will receive review from 100s
    of engineers within the world's most advanced standards body the
    IETF.

    

    It's a no brainer which specification is likely to have more bugs,
    complexity and security holes.

    


    

    

      
      
Right, and the original question in
        this part of the thread was "why bother with an ID token, why
        not just re-use the access token for both purposes?"

        

        Torsten's response below was in answer to that -- merging these
        two would make the access token non-opaque to the client. This
        is undesirable for many reasons. We had this discussion years
        ago in the OIDC working group (several times) and came to the
        same conclusion there (several times).

        

        Which goes to further the point that the A4C draft is simply
        re-hashing work that's already been covered by OIDC, often
        incompletely and missing key functionality required for
        interoperability and security, and adding nothing new or
        valuable to the conversation.

        

         -- Justin

        

        On 6/12/2014 9:25 AM, John Bradley wrote:

      

      

        
The Id_token is audienced to the client.  It is not sent to a resource server.  In a4c there may be no access token or resource server. 

The id_token is not opaque to the client. 

John B. 

Sent from my iPhone



        

          
On Jun 12, 2014, at 4:04 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Torsten,

nobody suggested that the access token would suddenly not be opaque to
the client.

The question therefore is whether the id token is not opaque to the
client. Is that the assumption?



          

            
On 06/05/2014 09:39 PM, Torsten Lodderstedt wrote:

the access token is opaque to the client. That's great! Let's keep it
that way.


          

          
Ciao
Hannes


_______________________________________________
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


    

    

  


--------------060604070809080606040304--


From nobody Thu Jun 12 09:52:15 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356AC1A01AA for ; Thu, 12 Jun 2014 09:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GudLXZ8GNdlm for ; Thu, 12 Jun 2014 09:52:07 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5FB1A01AE for ; Thu, 12 Jun 2014 09:52:07 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5CGq3Q6018629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2014 16:52:04 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5CGq10P000632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 16:52:03 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5CGq0HS014438; Thu, 12 Jun 2014 16:52:00 GMT
Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Jun 2014 09:52:00 -0700
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Phil Hunt 
In-Reply-To: <53995C50.2040900@gmx.net>
Date: Thu, 12 Jun 2014 09:51:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <213D9818-9BB3-4E33-B347-29A1BE4DE8F3@oracle.com>
References: <53901F49.1010608@gmx.net>  <53995BC3.1030802@gmx.net> <53995C50.2040900@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1878.2)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wONVjgJEG11y87e9U6zcskd6N7s
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 16:52:09 -0000

I don=92t think so. All copies of a client may carry the same statement.

Special distributions of a client intended for use in a specific domain =
may be packaged with an initial access token.  So a subset of every =
client may have the token.

All clients registering within a secure domain would have both statement =
and initial access token.

Other clients registering in other domains may or may not have initial =
access tokens.

A good example of this, many IT orgs take software from people like =
Cisco and embed special keys etc in a private distribution.  When the =
software installs it is pre-configured with keys and config to work only =
within the IT orgs domain.  I think this is the model Justin was looking =
for.

If a single client instance could have a unique initial access token =
already issued, we probably wouldn=92t need dynamic registration.  8-)

Phil

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



On Jun 12, 2014, at 12:52 AM, Hannes Tschofenig =
 wrote:

> One other small remark: I assume that a single software statement is
> distributed to many OAuth clients whereas the initial access token is
> only distributed to a single OAuth client. Is that correct? Is that =
the
> envisioned relationship?
>=20
> On 06/12/2014 09:50 AM, Hannes Tschofenig wrote:
>> Hi Phil,
>>=20
>> thanks for your response. A few remarks below.
>>=20
>>>> I am particularly interested to learn who issues the initial
>>>> access token and the software statement? What is the purpose? What
>>>> does it authorize?
>>>=20
>>> These tokens have very different characteristics. The Software
>>> Statement is not a security token. It is a statement that locks the
>>> registration profile for client software and provides AS endpoints
>>> with a way to recognize client software since they do not have a
>>> client_id yet. In practical terms, AS endpoints can set policy to
>>> automatically approve reject based on specific statement, or content
>>> rules (software_id, version etc) or even approve based on the signer
>>> of the statements (e.g. allow registration for any client software
>>> statement signed by Cisco).
>>=20
>> The software statement is hopefully signed and you are going to make
>> some security relevant decisions based on it. Whether you call it a
>> security token or not does not really matter that much.
>>=20
>>>=20
>>> Typically, the statement would be generated once (for all copies
>>> distributed) by the developer, publisher, or a collective
>>> organization.
>>=20
>> I think it would be useful to add information about who creates it,
>> particularly since the document introduces these parties (at least =
the
>> client developer, and the software API publisher).
>>=20
>> You might also expand a bit on what you mean by "generated once" to =
give
>> guidance on when a new software assertion needs to be generated vs. =
when
>> a previous one can be re-used.
>>=20
>>> This is particularly useful when the publisher of an
>>> API  is not the same organization as the deployers of the actual API
>>> endpoints following a common open API specification. For example,
>>> OpenID Connect would be one such example.
>>=20
>> OpenID Connect would not have come to my mind here since OpenID =
connect
>> is neither a client developer nor a software API publisher (at least =
in
>> my understanding of the terminology defined in the dynamic client
>> registration document).
>>=20
>>>=20
>>> In the early OAuth1 and 2 days, most use cases had the API publisher
>>> and the deployer as the same organization. A client_id could be
>>> issued in advance and could be used as both credential id and
>>> software identifier.  In the evolving world, we have lots of cases
>>> (e.g. OpenID Connect) where the organization that defines the API
>>> specification is not the same as the one operating implementations =
of
>>> the API specification.  Client_id can=92t serve both purposes.
>>> Software statement fills the gap allowing client software to use a
>>> client statement =93claim=94 that can be =93exchange=94 for a =
deployment
>>> assigned client_id.
>>=20
>> I think that this would be useful background motivation for the =
draft; I
>> disagree with the mentioning of OpenID Connect based on my previous
>> comment.
>>=20
>>>=20
>>> Initial access token is a security token that allows the client to
>>> register in a closed/restricted registration endpoint where =
anonymous
>>> registration may not be allowed.  Useful in some environments where
>>> an IT organization might re-package a client for distribution on an
>>> internal or private system.
>>>=20
>>> Where the software statement is issued by either the developer or =
the
>>> API specification organization, the initial access token is =
typically
>>> issued by the =93domain=94 (or an organization affiliated with it) =
where
>>> the client intends to register.
>>=20
>> Using the terminology from the dynamic client registration draft the
>> initial access token is issued by the "Deployment Organization". This
>> would be important information to add to the document!
>>=20
>> Ciao
>> Hannes
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20


From nobody Thu Jun 12 10:07:01 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEFD1A018A for ; Thu, 12 Jun 2014 10:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84fLdg3ay7XI for ; Thu, 12 Jun 2014 10:06:56 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C200A1A0601 for ; Thu, 12 Jun 2014 10:06:56 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5CH6qjK005507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2014 17:06:53 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5CH6p5i015425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 17:06:52 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5CH6pXm027463; Thu, 12 Jun 2014 17:06:51 GMT
Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Jun 2014 10:06:51 -0700
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Phil Hunt 
In-Reply-To: <213D9818-9BB3-4E33-B347-29A1BE4DE8F3@oracle.com>
Date: Thu, 12 Jun 2014 10:06:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <782DB91B-DB5A-4710-9116-D02B167D560A@oracle.com>
References: <53901F49.1010608@gmx.net>  <53995BC3.1030802@gmx.net> <53995C50.2040900@gmx.net> <213D9818-9BB3-4E33-B347-29A1BE4DE8F3@oracle.com>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1878.2)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/C3Hy8xxKXJg-egcPUmpiB8RIDS0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 17:06:59 -0000

Hannes,

I should also add one security consideration.

If a server believes it is receiving a registration request from a =
client sharing the same software_id and software_version as another =
client that uses an assertion, the server should find the registration =
suspect. It is likely the client is attempting to change things like =
redirect_uri=92s. =20

The point of a software statement is to lock all copies of a client to =
behave the same way under the same registration profile.

Phil

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



On Jun 12, 2014, at 9:51 AM, Phil Hunt  wrote:

> I don=92t think so. All copies of a client may carry the same =
statement.
>=20
> Special distributions of a client intended for use in a specific =
domain may be packaged with an initial access token.  So a subset of =
every client may have the token.
>=20
> All clients registering within a secure domain would have both =
statement and initial access token.
>=20
> Other clients registering in other domains may or may not have initial =
access tokens.
>=20
> A good example of this, many IT orgs take software from people like =
Cisco and embed special keys etc in a private distribution.  When the =
software installs it is pre-configured with keys and config to work only =
within the IT orgs domain.  I think this is the model Justin was looking =
for.
>=20
> If a single client instance could have a unique initial access token =
already issued, we probably wouldn=92t need dynamic registration.  8-)
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
> On Jun 12, 2014, at 12:52 AM, Hannes Tschofenig =
 wrote:
>=20
>> One other small remark: I assume that a single software statement is
>> distributed to many OAuth clients whereas the initial access token is
>> only distributed to a single OAuth client. Is that correct? Is that =
the
>> envisioned relationship?
>>=20
>> On 06/12/2014 09:50 AM, Hannes Tschofenig wrote:
>>> Hi Phil,
>>>=20
>>> thanks for your response. A few remarks below.
>>>=20
>>>>> I am particularly interested to learn who issues the initial
>>>>> access token and the software statement? What is the purpose? What
>>>>> does it authorize?
>>>>=20
>>>> These tokens have very different characteristics. The Software
>>>> Statement is not a security token. It is a statement that locks the
>>>> registration profile for client software and provides AS endpoints
>>>> with a way to recognize client software since they do not have a
>>>> client_id yet. In practical terms, AS endpoints can set policy to
>>>> automatically approve reject based on specific statement, or =
content
>>>> rules (software_id, version etc) or even approve based on the =
signer
>>>> of the statements (e.g. allow registration for any client software
>>>> statement signed by Cisco).
>>>=20
>>> The software statement is hopefully signed and you are going to make
>>> some security relevant decisions based on it. Whether you call it a
>>> security token or not does not really matter that much.
>>>=20
>>>>=20
>>>> Typically, the statement would be generated once (for all copies
>>>> distributed) by the developer, publisher, or a collective
>>>> organization.
>>>=20
>>> I think it would be useful to add information about who creates it,
>>> particularly since the document introduces these parties (at least =
the
>>> client developer, and the software API publisher).
>>>=20
>>> You might also expand a bit on what you mean by "generated once" to =
give
>>> guidance on when a new software assertion needs to be generated vs. =
when
>>> a previous one can be re-used.
>>>=20
>>>> This is particularly useful when the publisher of an
>>>> API  is not the same organization as the deployers of the actual =
API
>>>> endpoints following a common open API specification. For example,
>>>> OpenID Connect would be one such example.
>>>=20
>>> OpenID Connect would not have come to my mind here since OpenID =
connect
>>> is neither a client developer nor a software API publisher (at least =
in
>>> my understanding of the terminology defined in the dynamic client
>>> registration document).
>>>=20
>>>>=20
>>>> In the early OAuth1 and 2 days, most use cases had the API =
publisher
>>>> and the deployer as the same organization. A client_id could be
>>>> issued in advance and could be used as both credential id and
>>>> software identifier.  In the evolving world, we have lots of cases
>>>> (e.g. OpenID Connect) where the organization that defines the API
>>>> specification is not the same as the one operating implementations =
of
>>>> the API specification.  Client_id can=92t serve both purposes.
>>>> Software statement fills the gap allowing client software to use a
>>>> client statement =93claim=94 that can be =93exchange=94 for a =
deployment
>>>> assigned client_id.
>>>=20
>>> I think that this would be useful background motivation for the =
draft; I
>>> disagree with the mentioning of OpenID Connect based on my previous
>>> comment.
>>>=20
>>>>=20
>>>> Initial access token is a security token that allows the client to
>>>> register in a closed/restricted registration endpoint where =
anonymous
>>>> registration may not be allowed.  Useful in some environments where
>>>> an IT organization might re-package a client for distribution on an
>>>> internal or private system.
>>>>=20
>>>> Where the software statement is issued by either the developer or =
the
>>>> API specification organization, the initial access token is =
typically
>>>> issued by the =93domain=94 (or an organization affiliated with it) =
where
>>>> the client intends to register.
>>>=20
>>> Using the terminology from the dynamic client registration draft the
>>> initial access token is issued by the "Deployment Organization". =
This
>>> would be important information to add to the document!
>>>=20
>>> Ciao
>>> Hannes
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jun 12 10:22:25 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F581A01E1 for ; Thu, 12 Jun 2014 10:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPu-XhkW0tWW for ; Thu, 12 Jun 2014 10:22:20 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760D11A01CB for ; Thu, 12 Jun 2014 10:22:20 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5CHMFqB025358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2014 17:22:16 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5CHME8B025145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 17:22:15 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5CHMD9m016426; Thu, 12 Jun 2014 17:22:14 GMT
Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Jun 2014 10:22:13 -0700
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Phil Hunt 
In-Reply-To: <53995F27.7090903@gmx.net>
Date: Thu, 12 Jun 2014 10:22:09 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1878.2)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6m7s_WGQMBI5Ua4W7XEAo385-dQ
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 17:22:22 -0000

One of the use cases is to return only a token that is NOT an access =
token and is only an authentication assertion that is not opaque to the =
client.

A key concern is clients do not always want to ask users for consent to =
access their profiles or any other resource.  They just want =
authentication.

How many times do we see things like login with Yahoo, Twitter, Facebook =
and they apparently want access to too much information?  I=92ve got =
lots of web site developers who don=92t want that because it looses =
registrations as a significant percentage of users always refuse.  These =
developers  just want an authn ctx and the easy-sign-on benefits.

=46rom this standpoint, having separate tokens makes sense.  One remains =
opaque to the client targeted for the resource server. The other is for =
the client.

You could have a new token type that can be dual-purpose and parseable =
to everyone, but I think that may end up being more confusing.  It would =
also mean impacts to resource servers to support a new non-opaque token =
type.

Phil

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



On Jun 12, 2014, at 1:04 AM, Hannes Tschofenig =
 wrote:

> Torsten,
>=20
> nobody suggested that the access token would suddenly not be opaque to
> the client.
>=20
> The question therefore is whether the id token is not opaque to the
> client. Is that the assumption?
>=20
> On 06/05/2014 09:39 PM, Torsten Lodderstedt wrote:
>>=20
>> the access token is opaque to the client. That's great! Let's keep it
>> that way.
>=20
> Ciao
> Hannes
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jun 12 12:50:52 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E501A025A for ; Thu, 12 Jun 2014 12:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dux_WB_UaE2o for ; Thu, 12 Jun 2014 12:50:49 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5F51A0249 for ; Thu, 12 Jun 2014 12:50:49 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5CJon9G015347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 12 Jun 2014 15:50:49 -0400
Received: from [10.10.50.141] (vpn-50-141.rdu2.redhat.com [10.10.50.141]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5CJomJR027254 for ; Thu, 12 Jun 2014 15:50:48 -0400
Message-ID: <539A0497.7070906@redhat.com>
Date: Thu, 12 Jun 2014 15:50:47 -0400
From: Bill Burke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com>
In-Reply-To: <5399DA1C.4090409@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ea4mNmyMHRoaDN-P6yPxcFi8BYE
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 19:50:51 -0000

On 6/12/2014 12:49 PM, Prateek Mishra wrote:
> The OpenID Connect 2.0 COre specification alone is 86 pages. It has
> received review from maybe a dozen engineers within the OpenID community.
>

The OpenID Connect spec is 86 pages because it pretty much rehashes the 
OAuth2 spec walking through each flow and how Open ID Connect expands on 
that flow.  A4c looks like a subset of this work minus some additional 
claims and, IMO, is incomplete compared to OIDC.

FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We 
originally were creating our own oauth2 extension using JWT, but found 
that any feature we wanted to define already existed in OpenID Connect. 
  These guys have done great work.   Aren't many of you here authors of 
this spec and/or the same companies?!?  I think your energies are better 
focused on lobbying OIDC to join the IETF and this WG.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From nobody Thu Jun 12 13:19:05 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6CE1A0275 for ; Thu, 12 Jun 2014 13:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R28ihCxkXl7k for ; Thu, 12 Jun 2014 13:19:02 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FA51A0260 for ; Thu, 12 Jun 2014 13:19:01 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5CKJ0gl030510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2014 20:19:01 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5CKIxbi001458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 20:18:59 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5CKIwLa005790; Thu, 12 Jun 2014 20:18:59 GMT
Received: from [10.98.22.175] (/24.244.23.211) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Jun 2014 13:18:58 -0700
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <539A0497.7070906@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com>
X-Mailer: iPhone Mail (11D201)
From: Phil Hunt 
Date: Thu, 12 Jun 2014 13:18:49 -0700
To: Bill Burke 
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Q7UvC56w_nksidB7mFc4BEJqPlo
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 20:19:03 -0000

Phil

> On Jun 12, 2014, at 12:50, Bill Burke  wrote:
>=20
>=20
>=20
>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has
>> received review from maybe a dozen engineers within the OpenID community.=

>=20
> The OpenID Connect spec is 86 pages because it pretty much rehashes the OA=
uth2 spec walking through each flow and how Open ID Connect expands on that f=
low.  A4c looks like a subset of this work minus some additional claims and,=
 IMO, is incomplete compared to OIDC.
In what regards?

Much of oidc is out of scope for this requirement.=20

It is a bit like saying an 18 wheeler is suitable for driving the kids to sc=
hool. :-)
>=20
> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We originally w=
ere creating our own oauth2 extension using JWT, but found that any feature w=
e wanted to define already existed in OpenID Connect.  These guys have done g=
reat work.   Aren't many of you here authors of this spec and/or the same co=
mpanies?!?  I think your energies are better focused on lobbying OIDC to joi=
n the IETF and this WG.

>=20
>=20
> --=20
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jun 12 13:38:36 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B18C1A0273 for ; Thu, 12 Jun 2014 13:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD1FjSeUCwbB for ; Thu, 12 Jun 2014 13:38:30 -0700 (PDT)
Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E48C1A025E for ; Thu, 12 Jun 2014 13:38:29 -0700 (PDT)
Received: from mail-wg0-f45.google.com ([74.125.82.45]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKU5oPv7c45B34pvPAnSXyx7v1smK7O/Ui@postini.com; Thu, 12 Jun 2014 13:38:29 PDT
Received: by mail-wg0-f45.google.com with SMTP id l18so1849084wgh.16 for ; Thu, 12 Jun 2014 13:38:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l7Ce8W6DJNR4lpiCYMw7rqPE3vE4/TemrouhmgavSKM=; b=isOSIQau2FVO3fs95R677vAKbI34kjdr3HTNB3jCji+YSyVnfpSFh7JVGDyGdnl+wu v8jyrNzL4WVITjTxBRCDdeyukPG/m24sL/R/6sMfHV9u090ePB/XG457GEfadhwqj8QA UTz+c1lym+KP1hLNCfEZxjuAGTLu/zXYAOg1N3PnpWP4Yq6ympsZbbtvxFxwGSCTwGRC VwR3MNqDbbsGelnI2xHEIAcoIkaEUv0IzO3EU3l322zFRVSVdAOnESgLHDABwaXCoKgU 1JtXjEUjYk2sL78dIvECLzrGwp0Jg7W1LTPSfav/qjgkYbcRgkQsoXBTJplV8z0NWa+x 37xw==
X-Gm-Message-State: ALoCoQnfTJjTmn0SpVs0MEuFineROBjgXzvH5ai2uRuHnV609/gHBumsNo+vqioh/Eos3CUTu9nO+3wReVj10WCbjSqSi2hrNcDNXvC2c0ZaI8Id7Q+a6djon2IQCVYIz2/1+n2GGHQH
X-Received: by 10.180.149.240 with SMTP id ud16mr9740412wib.3.1402605492192; Thu, 12 Jun 2014 13:38:12 -0700 (PDT)
X-Received: by 10.180.149.240 with SMTP id ud16mr9740403wib.3.1402605492052; Thu, 12 Jun 2014 13:38:12 -0700 (PDT)
Received: from [192.168.10.222] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by mx.google.com with ESMTPSA id w2sm4609061een.41.2014.06.12.13.38.10 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 13:38:11 -0700 (PDT)
Message-ID: <539A0FB1.1020106@pingidentity.com>
Date: Thu, 12 Jun 2014 22:38:09 +0200
From: Hans Zandbelt 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Bill Burke , oauth@ietf.org
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com>
In-Reply-To: <539A0497.7070906@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LIU8ZD91P2xkf3pldze9Mf4q9V4
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 20:38:31 -0000

+1, after implementing OIDC I will support the claim that any SSO 
protocol with a minimal set of required features smaller than OIDC is 
insecure and any protocol with similar features but with different 
parameter names is just creating confusion and will increase chances of 
non-interoperable and insecure implementations

Hans.

On 6/12/14, 9:50 PM, Bill Burke wrote:
>
>
> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has
>> received review from maybe a dozen engineers within the OpenID community.
>>
>
> The OpenID Connect spec is 86 pages because it pretty much rehashes the
> OAuth2 spec walking through each flow and how Open ID Connect expands on
> that flow.  A4c looks like a subset of this work minus some additional
> claims and, IMO, is incomplete compared to OIDC.
>
> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We
> originally were creating our own oauth2 extension using JWT, but found
> that any feature we wanted to define already existed in OpenID Connect.
>   These guys have done great work.   Aren't many of you here authors of
> this spec and/or the same companies?!?  I think your energies are better
> focused on lobbying OIDC to join the IETF and this WG.
>
>

-- 
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


From nobody Thu Jun 12 13:50:39 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557561A0273 for ; Thu, 12 Jun 2014 13:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.151
X-Spam-Level: 
X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sLJwqA1Own2 for ; Thu, 12 Jun 2014 13:50:35 -0700 (PDT)
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2982A1A0276 for ; Thu, 12 Jun 2014 13:50:35 -0700 (PDT)
Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Thu, 12 Jun 2014 16:50:34 -0400
Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Thu, 12 Jun 2014 16:50:33 -0400
Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 67010C90040 for ; Thu, 12 Jun 2014 16:50:26 -0400 (EDT)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by b01cxnp22033.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s5CKoWYE9830698 for ; Thu, 12 Jun 2014 20:50:32 GMT
Received: from d01av04.pok.ibm.com (localhost [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s5CKoVYL029273 for ; Thu, 12 Jun 2014 16:50:31 -0400
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s5CKoVrE029247; Thu, 12 Jun 2014 16:50:31 -0400
In-Reply-To: <537E0D6B.6070304@mit.edu>
References:  <537E0D6B.6070304@mit.edu>
To: Justin Richer 
MIME-Version: 1.0
X-KeepSent: 0E4C815E:D38A427A-85257CF5:0070A9EC; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP5SHF238 December 19, 2013
Message-ID: 
From: Todd W Lainhart 
Date: Thu, 12 Jun 2014 16:50:29 -0400
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 9.0.1IF1|November 26, 2013) at 06/12/2014 16:50:31, Serialize complete at 06/12/2014 16:50:31
Content-Type: multipart/alternative; boundary="=_alternative 00727C7B85257CF5_="
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 14061220-0320-0000-0000-0000038824B3
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/qyx2KAhxFl3mDL2yj1ADkvrOKDU
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] For a client credentials grant, what are you returning as the value of the "sub" element in an introspection response?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 20:50:37 -0000

This is a multipart message in MIME format.
--=_alternative 00727C7B85257CF5_=
Content-Type: text/plain; charset="US-ASCII"

One problem we've discovered when returning the client_id value as "sub" 
is client impersonation.  That is, in a system where a user can 
self-register, it's possible that the user could register an id/sub value 
that is the same as the client_id value, and thus be granted the same 
privileges as the application principal based on the introspection 
response.

We're leaning towards returning the grant_type in the introspection 
response to disambiguate this case.  i.e. if grant_type == 
"client_credentials" then you know that the bearer represents the app 
principal.

http://tools.ietf.org/html/draft-richer-oauth-introspection-04 expired 
last Nov.  Were you thinking of picking it up?  I'm recalling that Nat 
Sakimura expressed an interest a while back.





Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com




From:   Justin Richer 
To:     Todd W Lainhart/Lexington/IBM@IBMUS, IETF oauth WG 
, 
Date:   05/22/2014 10:45 AM
Subject:        Re: [OAUTH-WG] For a client credentials grant, what are 
you returning as the value of the "sub" element in an introspection 
response?



We return the client_id of the client that the token was issued to.

 -- Justin

On 5/22/2014 10:08 AM, Todd W Lainhart wrote:
For folks who have implemented the client credentials grant and 
introspection, I'm interested to know what you're returning for the value 
of "sub" in the token introspection response (
http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2.2
).  The "client_id" value requesting the grant, or some other client 
registration metadata value? 



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com



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



--=_alternative 00727C7B85257CF5_=
Content-Type: text/html; charset="US-ASCII"

One problem we've discovered when returning
the client_id value as "sub" is client impersonation.  That
is, in a system where a user can self-register, it's possible that the
user could register an id/sub value that is the same as the client_id value,
and thus be granted the same privileges as the application principal based
on the introspection response.



We're leaning towards returning the
grant_type in the introspection response to disambiguate this case.  i.e.
if grant_type == "client_credentials" then you know that the
bearer represents the app principal.



http://tools.ietf.org/html/draft-richer-oauth-introspection-04
expired last Nov.  Were you thinking of picking it up?  I'm recalling
that Nat Sakimura expressed an interest a while back.














Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.com










From:      
 Justin Richer <jricher@mit.edu>

To:      
 Todd W Lainhart/Lexington/IBM@IBMUS,
IETF oauth WG <oauth@ietf.org>, 

Date:      
 05/22/2014 10:45 AM

Subject:    
   Re: [OAUTH-WG]
For a client credentials grant, what are you returning as the value of
the "sub" element in an introspection response?









We return the client_id of the client that the token was
issued to.



 -- Justin



On 5/22/2014 10:08 AM, Todd W Lainhart wrote:

For folks who have implemented the client
credentials grant and introspection, I'm interested to know what you're
returning for the value of "sub" in the token introspection response
(http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2.2).
 The "client_id" value requesting the grant, or some other
client registration metadata value? 










Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.com








_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






--=_alternative 00727C7B85257CF5_=--


From nobody Thu Jun 12 14:18:24 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4751A0300 for ; Thu, 12 Jun 2014 14:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQCUgbW8VC4b for ; Thu, 12 Jun 2014 14:18:17 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398AA1A028B for ; Thu, 12 Jun 2014 14:18:17 -0700 (PDT)
Received: by mail-qa0-f44.google.com with SMTP id hw13so1140794qab.17 for ; Thu, 12 Jun 2014 14:18:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=tASR150Du+IJMXkQ6N+KrFeCM5OzFeT0dOQg+35iMbM=; b=kkMJwjGw7njY2Ci70Ejm5zMEbJjD+RyRguMANga2M3y3F7n11RUAzJq3QU1OCpe8qv lbAt9oXQ4K0EdGOz/QFSNlyNDEdN49PSotuJ/4LWWzJy69/IApKlli0HkFs5vCvvHdQd j7wbjWPShEKZB9si/RVW25PSc8iQTlYtOaynL9IteUPFVeOIzed5KadZ9OErAbocSvCZ U/DlHkfQEUTW2EuMZrm08ICqm4c7WYRHRYocLjaJozaFr2M4aDGUHKfIduiB3lzSiiLQ g/ZAS4McGmD8WBLVi8+cRfbIgS6wAAZxM9M2iS5V2eKdmaUMMMszR91XGrVrVRiY3Pqv jctg==
X-Gm-Message-State: ALoCoQmCyqG30Vazhmt2v+iUVkIj5P93TB/RqJ0RfgFCPMGS3s/Y+atUwGQYnrYbNgp2qwVlmHju
X-Received: by 10.229.57.129 with SMTP id c1mr64476026qch.7.1402607896270; Thu, 12 Jun 2014 14:18:16 -0700 (PDT)
Received: from [192.168.0.200] ([201.188.17.250]) by mx.google.com with ESMTPSA id e12sm3241820qaq.13.2014.06.12.14.18.14 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 14:18:15 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: John Bradley 
In-Reply-To: <539A0FB1.1020106@pingidentity.com>
Date: Thu, 12 Jun 2014 17:18:40 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <13F2E738-49BB-4EDB-9070-5A49448A6249@ve7jtb.com>
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <539A0FB1.1020106@pingidentity.com>
To: Hans Zandbelt 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HWkJd8LoxCoqkeMsDkcdfglr7T4
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 21:18:19 -0000

All but a handful of OAuth WG participants participated in developing =
OpenID Connect. =20

Yes some companies chose not to participate for whatever reasons and =
have not committed to the mutual non assert IPR agreement, and that is =
unfortunate, but not a reason to start again from scratch.

Changing the OIDF IPR policy of totally open specifications based on non =
asserts is also not a option.

I have made comments on the current draft of a4c.

I think a profile of Connect introducing a grant_type returning only an =
id_token would be simpler than trying to do this as a separate spec.
I do note that you can do effectively the same thing now by using a code =
response_type and a scope of openID.   This doesn't result in any extra =
user consent other than consenting to login to the RP the first time =
(though that consent can be given in advance out of band in a enterprise =
scenario.

When developing Connect we debated having a token endpoint response with =
only a id_token but decided that it was not in the spirit of being a =
OAuth 2 profile.   So we decided to return a access token even if the =
user info endpoint contains no claims other then sub.   People almost =
always want more claims as they roll out a real deployment.  It is easy =
to add them if you have designed to be able to talk to a RS.
OAuth without a RS is a touch not OAuth.

a4c also completely ignores modern development environments like node.js =
where the client is in the user agent, that OAuth 2 and Connect support.

By the time the OAuth WG is done with a4c it will likely be a similar =
size as Connect if it addresses the same use cases. =20

I still don't see the problem with having a deployment profile of =
Connect that can meet 100% of the current stated use case for a4c.=20

I expect that the people here involved in Connect will form there own =
opinions on comments regarding the number of participants and the =
quantity of the work and review.

Regards
John B.




On Jun 12, 2014, at 4:38 PM, Hans Zandbelt  =
wrote:

> +1, after implementing OIDC I will support the claim that any SSO =
protocol with a minimal set of required features smaller than OIDC is =
insecure and any protocol with similar features but with different =
parameter names is just creating confusion and will increase chances of =
non-interoperable and insecure implementations
>=20
> Hans.
>=20
> On 6/12/14, 9:50 PM, Bill Burke wrote:
>>=20
>>=20
>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has
>>> received review from maybe a dozen engineers within the OpenID =
community.
>>>=20
>>=20
>> The OpenID Connect spec is 86 pages because it pretty much rehashes =
the
>> OAuth2 spec walking through each flow and how Open ID Connect expands =
on
>> that flow.  A4c looks like a subset of this work minus some =
additional
>> claims and, IMO, is incomplete compared to OIDC.
>>=20
>> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We
>> originally were creating our own oauth2 extension using JWT, but =
found
>> that any feature we wanted to define already existed in OpenID =
Connect.
>>  These guys have done great work.   Aren't many of you here authors =
of
>> this spec and/or the same companies?!?  I think your energies are =
better
>> focused on lobbying OIDC to join the IETF and this WG.
>>=20
>>=20
>=20
> --=20
> Hans Zandbelt              | Sr. Technical Architect
> hzandbelt@pingidentity.com | Ping Identity
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jun 12 14:18:53 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AEF1B2850 for ; Thu, 12 Jun 2014 14:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level: 
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3a0MwA4xwafc for ; Thu, 12 Jun 2014 14:18:29 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127611A028B for ; Thu, 12 Jun 2014 14:18:29 -0700 (PDT)
X-AuditID: 12074424-f79546d000000c5e-ea-539a192354da
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 29.C2.03166.3291A935; Thu, 12 Jun 2014 17:18:27 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s5CLIQdG012826; Thu, 12 Jun 2014 17:18:26 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s5CLINJL002392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 12 Jun 2014 17:18:25 -0400
Content-Type: multipart/signed; boundary="Apple-Mail=_F84269F7-FB39-4677-A2FB-467C54691999"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Justin Richer 
In-Reply-To: 
Date: Thu, 12 Jun 2014 17:18:21 -0400
Message-Id: <47EB3682-0964-43B2-AD9A-9EA2D65132BC@mit.edu>
References:  <537E0D6B.6070304@mit.edu> 
To: Todd W Lainhart 
X-Mailer: Apple Mail (2.1878.2)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDKsWRmVeSWpSXmKPExsUixG6nrqssOSvY4NYFQYu1vTPZLE6+fcXm wOSxZMlPJo9z1/qYA5iiuGxSUnMyy1KL9O0SuDIOPVrLWnAlpGJr90PWBsZmzy5GTg4JAROJ SXcuskLYYhIX7q1n62Lk4hASmM0k8eLMZmYIZyOjxJudd9khnJtMEh9Of2ICcZgFJjFK7NrS CdbPK2Agca1/PSOILSzQxyix7rIFiM0moCoxf+UtJhCbUyBY4vC5R8wgNgtQfPfmjWC9zAJK Ejcv/4KaYyXx5hXITSDbtjBKNL3pBWsQEdCU6Oj+wg5xrLzEjPYT7BMYBWYhO2QWkkNmgQ1O kmjraGGCsLUlli18zQxhG0g87XzFiimuL/Hm3RyoenmJ7W/nQMUtJRbPvMECYdtK3OpbAFVj J/Fo2iLWBYzcqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9XIzS/RSU0o3MYIjzkVlB2PzIaVD jAIcjEo8vCs+zgwWYk0sK67MPcQoycGkJMobLzwrWIgvKT+lMiOxOCO+qDQntfgQowrQrkcb Vl9glGLJy89LVRLhlXgG1MqbklhZlVqUD1MmzcGiJM771toqWEggPbEkNTs1tSC1CCYrw8Gh JME7SRxogWBRanpqRVpmTglCmomD8xCjBAcP0PBNIDW8xQWJucWZ6RD5U4yKUuK8a0ASAiCJ jNI8uF5YonzFKA70ljBvHUgVDzDJwnW/AhrMBDT4ted0kMEliQgpqQbG+cfeF1y+6HpkWsXC wv5PrpfOp99frze/ovNCRAWXb9kheYej3U9qFxlNj5Vc8fSTZ5FbU9Qzpdc3Zh8UeSn3M+Uw i2la6s1KtikX1vLx6cqnzf9mzrLbvPA918s/1Q5myZ836h696p45qerFGfEjZive1XxfWxX2 w6Clp0z2wC0lgwfsz8p7lFiKMxINtZiLihMBmCKwQ28DAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/IsWBxvHimgt_UMqquGbaYgr6pLI
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] For a client credentials grant, what are you returning as the value of the "sub" element in an introspection response?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 21:18:38 -0000

--Apple-Mail=_F84269F7-FB39-4677-A2FB-467C54691999
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6462A64B-30C7-48E8-BB62-44F692CE1587"


--Apple-Mail=_6462A64B-30C7-48E8-BB62-44F692CE1587
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I haven=92t touched the draft for a while because the basics have fit =
most of our use cases and there hasn=92t been a clamor from the working =
group to standardize it. I=92d be happy to pick it back up if the =
working group wanted to make it an official document.

Having run this in production for a little while, there are a handful of =
things that would make sense to include in the standard response set. =
Things like returning the grant type, response type, as it=92s all a =
part of the request that made the token. We=92ve also had questions =
recently about returning both the =91sub=92 of a user as defined by =
OpenID Connect in addition to a more traditional user_id/username field =
(our deployment does both, and they=92re different =97 the former is =
stable but the latter is used to cross-index into other systems).=20

 =97 Justin


On Jun 12, 2014, at 4:50 PM, Todd W Lainhart  =
wrote:

> One problem we've discovered when returning the client_id value as =
"sub" is client impersonation.  That is, in a system where a user can =
self-register, it's possible that the user could register an id/sub =
value that is the same as the client_id value, and thus be granted the =
same privileges as the application principal based on the introspection =
response.=20
>=20
> We're leaning towards returning the grant_type in the introspection =
response to disambiguate this case.  i.e. if grant_type =3D=3D =
"client_credentials" then you know that the bearer represents the app =
principal.=20
>=20
> http://tools.ietf.org/html/draft-richer-oauth-introspection-04 expired =
last Nov.  Were you thinking of picking it up?  I'm recalling that Nat =
Sakimura expressed an interest a while back.
>=20
>=20
>=20
>=20
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250
> 1-978-899-4705
> 2-276-4705 (T/L)
> lainhart@us.ibm.com
>=20
>=20
>=20
>=20
>=20
> From:        Justin Richer =20
> To:        Todd W Lainhart/Lexington/IBM@IBMUS, IETF oauth WG =
,=20
> Date:        05/22/2014 10:45 AM=20
> Subject:        Re: [OAUTH-WG] For a client credentials grant, what =
are you returning as the value of the "sub" element in an introspection =
response?=20
>=20
>=20
>=20
> We return the client_id of the client that the token was issued to.
>=20
> -- Justin
>=20
> On 5/22/2014 10:08 AM, Todd W Lainhart wrote:=20
> For folks who have implemented the client credentials grant and =
introspection, I'm interested to know what you're returning for the =
value of "sub" in the token introspection response =
(http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2.=
2).  The "client_id" value requesting the grant, or some other client =
registration metadata value?
>=20
>=20
>=20
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250
> 1-978-899-4705
> 2-276-4705 (T/L)
> lainhart@us.ibm.com
>=20
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20


--Apple-Mail=_6462A64B-30C7-48E8-BB62-44F692CE1587
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


I =
haven=92t touched the draft for a while because the basics have fit most =
of our use cases and there hasn=92t been a clamor from the working group =
to standardize it. I=92d be happy to pick it back up if the working =
group wanted to make it an official =
document.

Having run this in production for a =
little while, there are a handful of things that would make sense to =
include in the standard response set. Things like returning the grant =
type, response type, as it=92s all a part of the request that made the =
token. We=92ve also had questions recently about returning both the =
=91sub=92 of a user as defined by OpenID Connect in addition to a more =
traditional user_id/username field (our deployment does both, and =
they=92re different =97 the former is stable but the latter is used to =
cross-index into other systems). 

 =97 =
Justin


On Jun 12, 2014, at 4:50 PM, =
Todd W Lainhart <lainhart@us.ibm.com> =
wrote:

One problem =
we've discovered when returning
the client_id value as "sub" is client impersonation.  That
is, in a system where a user can self-register, it's possible that the
user could register an id/sub value that is the same as the client_id =
value,
and thus be granted the same privileges as the application principal =
based
on the introspection response.



We're leaning towards returning =
the
grant_type in the introspection response to disambiguate this case. =
 i.e.
if grant_type =3D=3D "client_credentials" then you know that the
bearer represents the app principal.



http://tools.ietf.org/html/draft-richer-oauth-introspe=
ction-04
expired last Nov.  Were you thinking of picking it up?  I'm =
recalling
that Nat Sakimura expressed an interest a while back.














Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.com










From:   =
   
 Justin Richer <jricher@mit.edu>

To:   =
   
 Todd W =
Lainhart/Lexington/IBM@IBMUS,
IETF oauth WG <oauth@ietf.org>, 

Date:   =
   
 05/22/2014 10:45 =
AM

Subject: =
   
   Re: [OAUTH-WG]
For a client credentials grant, what are you returning as the value of
the "sub" element in an introspection response?









We return the client_id of the client that the =
token was
issued to.



 -- Justin



On 5/22/2014 10:08 AM, Todd W Lainhart wrote:

For folks who have implemented =
the client
credentials grant and introspection, I'm interested to know what you're
returning for the value of "sub" in the token introspection response
(http://tools.ietf.org/html/draft-richer-oauth-intro=
spection-04#section-2.2).
 The "client_id" value requesting the grant, or some other
client registration metadata value? 










Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.com








_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






=

--Apple-Mail=_6462A64B-30C7-48E8-BB62-44F692CE1587--

--Apple-Mail=_F84269F7-FB39-4677-A2FB-467C54691999
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJTmhkdAAoJEDPAngkbd+w9HbYH/2DM+W2Le2uw+jdS78JBxfY2
H2k6xRB8OwAd4rYGOumrCCQeJuwRIsu89WNTQJTlzZXMz/LF/lpZbK2NOqAqW+d/
k/H9eLf9Jfmi+BcDHZ84XfQO2TbLHeyXh6dKu9apd5AQxrVRZuxHNmscfdgF/wHY
Mxo6HKAohZ/KdGG9v+Qg2SbYmFED9W2KopLuf+JmaU9iBxdqoQD9ZJrK6t6DsvGn
yJOwcqmq/O9L4O4nSF+9Ylm9k/6IqFFMC5JwGl6lWyKL4qcYnvrAIIKuoHTbjymZ
BrCi5jzpX0h7+qfDmXspXfAFVlbmveqWTYzIILWWFPphTHF+h6jklbOX05QS1e0=
=aC78
-----END PGP SIGNATURE-----

--Apple-Mail=_F84269F7-FB39-4677-A2FB-467C54691999--


From nobody Thu Jun 12 14:39:43 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD661A025E for ; Thu, 12 Jun 2014 14:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.551
X-Spam-Level: 
X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjUHjaC3Zwtp for ; Thu, 12 Jun 2014 14:39:38 -0700 (PDT)
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3C61A01CE for ; Thu, 12 Jun 2014 14:39:37 -0700 (PDT)
Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Thu, 12 Jun 2014 17:39:36 -0400
Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Thu, 12 Jun 2014 17:39:35 -0400
Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id A5AD7C90026 for ; Thu, 12 Jun 2014 17:39:28 -0400 (EDT)
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by b01cxnp23034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s5CLdYL53539214 for ; Thu, 12 Jun 2014 21:39:34 GMT
Received: from d01av03.pok.ibm.com (localhost [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s5CLdY40009689 for ; Thu, 12 Jun 2014 17:39:34 -0400
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av03.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s5CLdYq3009686; Thu, 12 Jun 2014 17:39:34 -0400
In-Reply-To: <47EB3682-0964-43B2-AD9A-9EA2D65132BC@mit.edu>
References:  <537E0D6B.6070304@mit.edu>  <47EB3682-0964-43B2-AD9A-9EA2D65132BC@mit.edu>
To: Justin Richer 
MIME-Version: 1.0
X-KeepSent: 1FEABCFF:2312C751-85257CF5:0076EFB0; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP5SHF238 December 19, 2013
Message-ID: 
From: Todd W Lainhart 
Date: Thu, 12 Jun 2014 17:39:32 -0400
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 9.0.1IF1|November 26, 2013) at 06/12/2014 17:39:33, Serialize complete at 06/12/2014 17:39:33
Content-Type: multipart/alternative; boundary="=_alternative 0076F9F785257CF5_="
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 14061221-0320-0000-0000-00000388370D
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TFGLCRQgP2nWgeiyefPLekxnKJo
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] For a client credentials grant, what are you returning as the value of the "sub" element in an introspection response?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 21:39:40 -0000

This is a multipart message in MIME format.
--=_alternative 0076F9F785257CF5_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

PiBJ4oCZZCBiZSBoYXBweSB0byBwaWNrIGl0IGJhY2sgdXAgaWYgdGhlIHdvcmtpbmcgZ3JvdXAg
d2FudGVkIHRvIG1ha2UgaXQgDQphbiBvZmZpY2lhbCBkb2N1bWVudC4NCg0KKzENCg0KDQoNCg0K
DQpUb2RkIExhaW5oYXJ0DQpSYXRpb25hbCBzb2Z0d2FyZQ0KSUJNIENvcnBvcmF0aW9uDQo1NTAg
S2luZyBTdHJlZXQsIExpdHRsZXRvbiwgTUEgMDE0NjAtMTI1MA0KMS05NzgtODk5LTQ3MDUNCjIt
Mjc2LTQ3MDUgKFQvTCkNCmxhaW5oYXJ0QHVzLmlibS5jb20NCg0KDQoNCg0KRnJvbTogICBKdXN0
aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+DQpUbzogICAgIFRvZGQgVyBMYWluaGFydC9MZXhp
bmd0b24vSUJNQElCTVVTLCANCkNjOiAgICAgSUVURiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+
DQpEYXRlOiAgIDA2LzEyLzIwMTQgMDU6MTggUE0NClN1YmplY3Q6ICAgICAgICBSZTogW09BVVRI
LVdHXSBGb3IgYSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQsIHdoYXQgYXJlIA0KeW91IHJldHVy
bmluZyBhcyB0aGUgdmFsdWUgb2YgdGhlICJzdWIiIGVsZW1lbnQgaW4gYW4gaW50cm9zcGVjdGlv
biANCnJlc3BvbnNlPw0KDQoNCg0KSSBoYXZlbuKAmXQgdG91Y2hlZCB0aGUgZHJhZnQgZm9yIGEg
d2hpbGUgYmVjYXVzZSB0aGUgYmFzaWNzIGhhdmUgZml0IG1vc3QgDQpvZiBvdXIgdXNlIGNhc2Vz
IGFuZCB0aGVyZSBoYXNu4oCZdCBiZWVuIGEgY2xhbW9yIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAg
dG8gDQpzdGFuZGFyZGl6ZSBpdC4gSeKAmWQgYmUgaGFwcHkgdG8gcGljayBpdCBiYWNrIHVwIGlm
IHRoZSB3b3JraW5nIGdyb3VwIA0Kd2FudGVkIHRvIG1ha2UgaXQgYW4gb2ZmaWNpYWwgZG9jdW1l
bnQuDQoNCkhhdmluZyBydW4gdGhpcyBpbiBwcm9kdWN0aW9uIGZvciBhIGxpdHRsZSB3aGlsZSwg
dGhlcmUgYXJlIGEgaGFuZGZ1bCBvZiANCnRoaW5ncyB0aGF0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8g
aW5jbHVkZSBpbiB0aGUgc3RhbmRhcmQgcmVzcG9uc2Ugc2V0LiANClRoaW5ncyBsaWtlIHJldHVy
bmluZyB0aGUgZ3JhbnQgdHlwZSwgcmVzcG9uc2UgdHlwZSwgYXMgaXTigJlzIGFsbCBhIHBhcnQg
b2YgDQp0aGUgcmVxdWVzdCB0aGF0IG1hZGUgdGhlIHRva2VuLiBXZeKAmXZlIGFsc28gaGFkIHF1
ZXN0aW9ucyByZWNlbnRseSBhYm91dCANCnJldHVybmluZyBib3RoIHRoZSDigJhzdWLigJkgb2Yg
YSB1c2VyIGFzIGRlZmluZWQgYnkgT3BlbklEIENvbm5lY3QgaW4gDQphZGRpdGlvbiB0byBhIG1v
cmUgdHJhZGl0aW9uYWwgdXNlcl9pZC91c2VybmFtZSBmaWVsZCAob3VyIGRlcGxveW1lbnQgZG9l
cyANCmJvdGgsIGFuZCB0aGV54oCZcmUgZGlmZmVyZW50IOKAlCB0aGUgZm9ybWVyIGlzIHN0YWJs
ZSBidXQgdGhlIGxhdHRlciBpcyB1c2VkIA0KdG8gY3Jvc3MtaW5kZXggaW50byBvdGhlciBzeXN0
ZW1zKS4gDQoNCiDigJQgSnVzdGluDQoNCg0KT24gSnVuIDEyLCAyMDE0LCBhdCA0OjUwIFBNLCBU
b2RkIFcgTGFpbmhhcnQgPGxhaW5oYXJ0QHVzLmlibS5jb20+IHdyb3RlOg0KDQpPbmUgcHJvYmxl
bSB3ZSd2ZSBkaXNjb3ZlcmVkIHdoZW4gcmV0dXJuaW5nIHRoZSBjbGllbnRfaWQgdmFsdWUgYXMg
InN1YiIgDQppcyBjbGllbnQgaW1wZXJzb25hdGlvbi4gIFRoYXQgaXMsIGluIGEgc3lzdGVtIHdo
ZXJlIGEgdXNlciBjYW4gDQpzZWxmLXJlZ2lzdGVyLCBpdCdzIHBvc3NpYmxlIHRoYXQgdGhlIHVz
ZXIgY291bGQgcmVnaXN0ZXIgYW4gaWQvc3ViIHZhbHVlIA0KdGhhdCBpcyB0aGUgc2FtZSBhcyB0
aGUgY2xpZW50X2lkIHZhbHVlLCBhbmQgdGh1cyBiZSBncmFudGVkIHRoZSBzYW1lIA0KcHJpdmls
ZWdlcyBhcyB0aGUgYXBwbGljYXRpb24gcHJpbmNpcGFsIGJhc2VkIG9uIHRoZSBpbnRyb3NwZWN0
aW9uIA0KcmVzcG9uc2UuIA0KDQpXZSdyZSBsZWFuaW5nIHRvd2FyZHMgcmV0dXJuaW5nIHRoZSBn
cmFudF90eXBlIGluIHRoZSBpbnRyb3NwZWN0aW9uIA0KcmVzcG9uc2UgdG8gZGlzYW1iaWd1YXRl
IHRoaXMgY2FzZS4gIGkuZS4gaWYgZ3JhbnRfdHlwZSA9PSANCiJjbGllbnRfY3JlZGVudGlhbHMi
IHRoZW4geW91IGtub3cgdGhhdCB0aGUgYmVhcmVyIHJlcHJlc2VudHMgdGhlIGFwcCANCnByaW5j
aXBhbC4gDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci1vYXV0aC1p
bnRyb3NwZWN0aW9uLTA0IGV4cGlyZWQgDQpsYXN0IE5vdi4gIFdlcmUgeW91IHRoaW5raW5nIG9m
IHBpY2tpbmcgaXQgdXA/ICBJJ20gcmVjYWxsaW5nIHRoYXQgTmF0IA0KU2FraW11cmEgZXhwcmVz
c2VkIGFuIGludGVyZXN0IGEgd2hpbGUgYmFjay4NCg0KDQoNCg0KVG9kZCBMYWluaGFydA0KUmF0
aW9uYWwgc29mdHdhcmUNCklCTSBDb3Jwb3JhdGlvbg0KNTUwIEtpbmcgU3RyZWV0LCBMaXR0bGV0
b24sIE1BIDAxNDYwLTEyNTANCjEtOTc4LTg5OS00NzA1DQoyLTI3Ni00NzA1IChUL0wpDQpsYWlu
aGFydEB1cy5pYm0uY29tDQoNCg0KDQoNCg0KRnJvbTogICAgICAgIEp1c3RpbiBSaWNoZXIgPGpy
aWNoZXJAbWl0LmVkdT4gDQpUbzogICAgICAgIFRvZGQgVyBMYWluaGFydC9MZXhpbmd0b24vSUJN
QElCTVVTLCBJRVRGIG9hdXRoIFdHIDwNCm9hdXRoQGlldGYub3JnPiwgDQpEYXRlOiAgICAgICAg
MDUvMjIvMjAxNCAxMDo0NSBBTSANClN1YmplY3Q6ICAgICAgICBSZTogW09BVVRILVdHXSBGb3Ig
YSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQsIHdoYXQgYXJlIA0KeW91IHJldHVybmluZyBhcyB0
aGUgdmFsdWUgb2YgdGhlICJzdWIiIGVsZW1lbnQgaW4gYW4gaW50cm9zcGVjdGlvbiANCnJlc3Bv
bnNlPyANCg0KDQoNCldlIHJldHVybiB0aGUgY2xpZW50X2lkIG9mIHRoZSBjbGllbnQgdGhhdCB0
aGUgdG9rZW4gd2FzIGlzc3VlZCB0by4NCg0KLS0gSnVzdGluDQoNCk9uIDUvMjIvMjAxNCAxMDow
OCBBTSwgVG9kZCBXIExhaW5oYXJ0IHdyb3RlOiANCkZvciBmb2xrcyB3aG8gaGF2ZSBpbXBsZW1l
bnRlZCB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGdyYW50IGFuZCANCmludHJvc3BlY3Rpb24sIEkn
bSBpbnRlcmVzdGVkIHRvIGtub3cgd2hhdCB5b3UncmUgcmV0dXJuaW5nIGZvciB0aGUgdmFsdWUg
DQpvZiAic3ViIiBpbiB0aGUgdG9rZW4gaW50cm9zcGVjdGlvbiByZXNwb25zZSAoDQpodHRwOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVjdGlvbi0wNCNz
ZWN0aW9uLTIuMg0KKS4gIFRoZSAiY2xpZW50X2lkIiB2YWx1ZSByZXF1ZXN0aW5nIHRoZSBncmFu
dCwgb3Igc29tZSBvdGhlciBjbGllbnQgDQpyZWdpc3RyYXRpb24gbWV0YWRhdGEgdmFsdWU/IA0K
DQoNCg0KVG9kZCBMYWluaGFydA0KUmF0aW9uYWwgc29mdHdhcmUNCklCTSBDb3Jwb3JhdGlvbg0K
NTUwIEtpbmcgU3RyZWV0LCBMaXR0bGV0b24sIE1BIDAxNDYwLTEyNTANCjEtOTc4LTg5OS00NzA1
DQoyLTI3Ni00NzA1IChUL0wpDQpsYWluaGFydEB1cy5pYm0uY29tDQoNCg0KDQoNCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp
c3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoDQoNCg0KW2F0dGFjaG1lbnQgInNpZ25hdHVyZS5hc2MiIGRlbGV0ZWQgYnkgVG9kZCBX
IExhaW5oYXJ0L0xleGluZ3Rvbi9JQk1dIA0KDQo=
--=_alternative 0076F9F785257CF5_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgPC9mb250Pjxmb250IHNpemU9Mz5J
4oCZZCBiZSBoYXBweQ0KdG8gcGljayBpdCBiYWNrIHVwIGlmIHRoZSB3b3JraW5nIGdyb3VwIHdh
bnRlZCB0byBtYWtlIGl0IGFuIG9mZmljaWFsIGRvY3VtZW50LjwvZm9udD4NCjxicj4NCjxicj48
Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KzE8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8dGFi
bGUgd2lkdGg9MjIzIHN0eWxlPSJib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7Ij4NCjx0ciBoZWln
aHQ9OD4NCjx0ZCB3aWR0aD0yMjMgYmdjb2xvcj13aGl0ZSBzdHlsZT0iYm9yZGVyLXN0eWxlOnNv
bGlkO2JvcmRlci1jb2xvcjojMDAwMDAwO2JvcmRlci13aWR0aDowcHggMHB4IDBweCAwcHg7cGFk
ZGluZzowcHggMHB4OyI+PGZvbnQgc2l6ZT0xIGZhY2U9IlZlcmRhbmEiPjxiPjxicj4NCjxicj4N
Cjxicj4NClRvZGQgTGFpbmhhcnQ8YnI+DQpSYXRpb25hbCBzb2Z0d2FyZTxicj4NCklCTSBDb3Jw
b3JhdGlvbjxicj4NCjU1MCBLaW5nIFN0cmVldCwgTGl0dGxldG9uLCBNQSAwMTQ2MC0xMjUwPC9i
PjwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPjxicj4NCjEtOTc4LTg5OS00NzA1
PGJyPg0KMi0yNzYtNDcwNSAoVC9MKTxicj4NCmxhaW5oYXJ0QHVzLmlibS5jb208L2I+PC9mb250
PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9y
PSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RnJvbTogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu
YnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+SnVzdGluIFJpY2hlciAm
bHQ7anJpY2hlckBtaXQuZWR1Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVm
NWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5UbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwv
Zm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+VG9kZCBXIExhaW5oYXJ0L0xleGlu
Z3Rvbi9JQk1ASUJNVVMsDQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYg
ZmFjZT0ic2Fucy1zZXJpZiI+Q2M6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+
PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPklFVEYgb2F1dGggV0cgJmx0O29hdXRoQGll
dGYub3JnJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJz
YW5zLXNlcmlmIj5EYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250
IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4wNi8xMi8yMDE0IDA1OjE4IFBNPC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPlN1YmplY3Q6ICZu
YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt
c2VyaWYiPlJlOiBbT0FVVEgtV0ddDQpGb3IgYSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQsIHdo
YXQgYXJlIHlvdSByZXR1cm5pbmcgYXMgdGhlIHZhbHVlIG9mDQp0aGUgJnF1b3Q7c3ViJnF1b3Q7
IGVsZW1lbnQgaW4gYW4gaW50cm9zcGVjdGlvbiByZXNwb25zZT88L2ZvbnQ+DQo8YnI+DQo8aHIg
bm9zaGFkZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+SSBoYXZlbuKAmXQgdG91Y2hl
ZCB0aGUgZHJhZnQgZm9yIGEgd2hpbGUgYmVjYXVzZSB0aGUgYmFzaWNzDQpoYXZlIGZpdCBtb3N0
IG9mIG91ciB1c2UgY2FzZXMgYW5kIHRoZXJlIGhhc27igJl0IGJlZW4gYSBjbGFtb3IgZnJvbSB0
aGUNCndvcmtpbmcgZ3JvdXAgdG8gc3RhbmRhcmRpemUgaXQuIEnigJlkIGJlIGhhcHB5IHRvIHBp
Y2sgaXQgYmFjayB1cCBpZiB0aGUNCndvcmtpbmcgZ3JvdXAgd2FudGVkIHRvIG1ha2UgaXQgYW4g
b2ZmaWNpYWwgZG9jdW1lbnQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5IYXZpbmcg
cnVuIHRoaXMgaW4gcHJvZHVjdGlvbiBmb3IgYSBsaXR0bGUgd2hpbGUsIHRoZXJlDQphcmUgYSBo
YW5kZnVsIG9mIHRoaW5ncyB0aGF0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gaW5jbHVkZSBpbiB0aGUg
c3RhbmRhcmQNCnJlc3BvbnNlIHNldC4gVGhpbmdzIGxpa2UgcmV0dXJuaW5nIHRoZSBncmFudCB0
eXBlLCByZXNwb25zZSB0eXBlLCBhcyBpdOKAmXMNCmFsbCBhIHBhcnQgb2YgdGhlIHJlcXVlc3Qg
dGhhdCBtYWRlIHRoZSB0b2tlbi4gV2XigJl2ZSBhbHNvIGhhZCBxdWVzdGlvbnMNCnJlY2VudGx5
IGFib3V0IHJldHVybmluZyBib3RoIHRoZSDigJhzdWLigJkgb2YgYSB1c2VyIGFzIGRlZmluZWQg
YnkgT3BlbklEDQpDb25uZWN0IGluIGFkZGl0aW9uIHRvIGEgbW9yZSB0cmFkaXRpb25hbCB1c2Vy
X2lkL3VzZXJuYW1lIGZpZWxkIChvdXIgZGVwbG95bWVudA0KZG9lcyBib3RoLCBhbmQgdGhleeKA
mXJlIGRpZmZlcmVudCDigJQgdGhlIGZvcm1lciBpcyBzdGFibGUgYnV0IHRoZSBsYXR0ZXINCmlz
IHVzZWQgdG8gY3Jvc3MtaW5kZXggaW50byBvdGhlciBzeXN0ZW1zKS4gPC9mb250Pg0KPGJyPg0K
PGJyPjxmb250IHNpemU9Mz4mbmJzcDvigJQgSnVzdGluPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJy
Pjxmb250IHNpemU9Mz5PbiBKdW4gMTIsIDIwMTQsIGF0IDQ6NTAgUE0sIFRvZGQgVyBMYWluaGFy
dCAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmxhaW5oYXJ0QHVzLmlibS5jb20+PGZvbnQgc2l6
ZT0zIGNvbG9yPWJsdWU+PHU+bGFpbmhhcnRAdXMuaWJtLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250
IHNpemU9Mz4mZ3Q7DQp3cm90ZTo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9
InNhbnMtc2VyaWYiPk9uZSBwcm9ibGVtIHdlJ3ZlIGRpc2NvdmVyZWQgd2hlbiByZXR1cm5pbmcN
CnRoZSBjbGllbnRfaWQgdmFsdWUgYXMgJnF1b3Q7c3ViJnF1b3Q7IGlzIGNsaWVudCBpbXBlcnNv
bmF0aW9uLiAmbmJzcDtUaGF0DQppcywgaW4gYSBzeXN0ZW0gd2hlcmUgYSB1c2VyIGNhbiBzZWxm
LXJlZ2lzdGVyLCBpdCdzIHBvc3NpYmxlIHRoYXQgdGhlDQp1c2VyIGNvdWxkIHJlZ2lzdGVyIGFu
IGlkL3N1YiB2YWx1ZSB0aGF0IGlzIHRoZSBzYW1lIGFzIHRoZSBjbGllbnRfaWQgdmFsdWUsDQph
bmQgdGh1cyBiZSBncmFudGVkIHRoZSBzYW1lIHByaXZpbGVnZXMgYXMgdGhlIGFwcGxpY2F0aW9u
IHByaW5jaXBhbCBiYXNlZA0Kb24gdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2UuPC9mb250Pjxm
b250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48
YnI+DQpXZSdyZSBsZWFuaW5nIHRvd2FyZHMgcmV0dXJuaW5nIHRoZSBncmFudF90eXBlIGluIHRo
ZSBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlDQp0byBkaXNhbWJpZ3VhdGUgdGhpcyBjYXNlLiAmbmJz
cDtpLmUuIGlmIGdyYW50X3R5cGUgPT0gJnF1b3Q7Y2xpZW50X2NyZWRlbnRpYWxzJnF1b3Q7DQp0
aGVuIHlvdSBrbm93IHRoYXQgdGhlIGJlYXJlciByZXByZXNlbnRzIHRoZSBhcHAgcHJpbmNpcGFs
LjwvZm9udD48Zm9udCBzaXplPTM+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJs
dWU+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVjdGlvbi0wNCI+PGZvbnQgc2l6ZT0yIGNvbG9y
PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDQ8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl
PTIgZmFjZT0ic2Fucy1zZXJpZiI+DQpleHBpcmVkIGxhc3QgTm92LiAmbmJzcDtXZXJlIHlvdSB0
aGlua2luZyBvZiBwaWNraW5nIGl0IHVwPyAmbmJzcDtJJ20gcmVjYWxsaW5nDQp0aGF0IE5hdCBT
YWtpbXVyYSBleHByZXNzZWQgYW4gaW50ZXJlc3QgYSB3aGlsZSBiYWNrLjwvZm9udD48Zm9udCBz
aXplPTM+PGJyPg0KPC9mb250Pg0KPHRhYmxlIHdpZHRoPTIyMyBzdHlsZT0iYm9yZGVyLWNvbGxh
cHNlOmNvbGxhcHNlOyI+DQo8dHIgaGVpZ2h0PTg+DQo8dGQgd2lkdGg9MjIxIGJnY29sb3I9d2hp
dGUgc3R5bGU9ImJvcmRlci1zdHlsZTpzb2xpZDtib3JkZXItY29sb3I6IzAwMDAwMDtib3JkZXIt
d2lkdGg6MHB4IDBweCAwcHggMHB4O3BhZGRpbmc6MXB4IDFweDsiPjxmb250IHNpemU9MSBmYWNl
PSJWZXJkYW5hIj48Yj48YnI+DQo8YnI+DQo8YnI+DQpUb2RkIExhaW5oYXJ0PGJyPg0KUmF0aW9u
YWwgc29mdHdhcmU8YnI+DQpJQk0gQ29ycG9yYXRpb248YnI+DQo1NTAgS2luZyBTdHJlZXQsIExp
dHRsZXRvbiwgTUEgMDE0NjAtMTI1MDwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFs
Ij48Yj48YnI+DQoxLTk3OC04OTktNDcwNTxicj4NCjItMjc2LTQ3MDUgKFQvTCk8L2I+PC9mb250
Pjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48Yj48dT48YnI+DQo8L3U+PC9i
PjwvZm9udD48YSBocmVmPW1haWx0bzpsYWluaGFydEB1cy5pYm0uY29tPjxmb250IHNpemU9MSBj
b2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48Yj48dT5sYWluaGFydEB1cy5pYm0uY29tPC91PjwvYj48
L2ZvbnQ+PC9hPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NCjxicj4NCjxi
cj4NCjwvZm9udD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj48
YnI+DQpGcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0x
IGZhY2U9InNhbnMtc2VyaWYiPkp1c3Rpbg0KUmljaGVyICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWls
dG86anJpY2hlckBtaXQuZWR1Pjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy
aWYiPjx1PmpyaWNoZXJAbWl0LmVkdTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJz
YW5zLXNlcmlmIj4mZ3Q7PC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTEg
Y29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUbzogJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5Ub2RkDQpX
IExhaW5oYXJ0L0xleGluZ3Rvbi9JQk1ASUJNVVMsIElFVEYgb2F1dGggV0cgJmx0OzwvZm9udD48
YSBocmVmPW1haWx0bzpvYXV0aEBpZXRmLm9yZz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNl
PSJzYW5zLXNlcmlmIj48dT5vYXV0aEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9
MSBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7LA0KPC9mb250Pjxmb250IHNpemU9MSBjb2xvcj0jNWY1
ZjVmIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MDUvMjIvMjAxNA0KMTA6
NDUgQU08L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVm
NWYgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KU3ViamVjdDogJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZToNCltPQVVUSC1X
R10gRm9yIGEgY2xpZW50IGNyZWRlbnRpYWxzIGdyYW50LCB3aGF0IGFyZSB5b3UgcmV0dXJuaW5n
IGFzIHRoZQ0KdmFsdWUgb2YgdGhlICZxdW90O3N1YiZxdW90OyBlbGVtZW50IGluIGFuIGludHJv
c3BlY3Rpb24gcmVzcG9uc2U/PC9mb250Pjxmb250IHNpemU9Mz4NCjxicj4NCjwvZm9udD4NCjxo
ciBub3NoYWRlPjxmb250IHNpemU9Mz48YnI+DQo8YnI+DQo8YnI+DQpXZSByZXR1cm4gdGhlIGNs
aWVudF9pZCBvZiB0aGUgY2xpZW50IHRoYXQgdGhlIHRva2VuIHdhcyBpc3N1ZWQgdG8uPGJyPg0K
PGJyPg0KLS0gSnVzdGluPGJyPg0KPGJyPg0KT24gNS8yMi8yMDE0IDEwOjA4IEFNLCBUb2RkIFcg
TGFpbmhhcnQgd3JvdGU6IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJy
Pg0KRm9yIGZvbGtzIHdobyBoYXZlIGltcGxlbWVudGVkIHRoZSBjbGllbnQgY3JlZGVudGlhbHMg
Z3JhbnQgYW5kIGludHJvc3BlY3Rpb24sDQpJJ20gaW50ZXJlc3RlZCB0byBrbm93IHdoYXQgeW91
J3JlIHJldHVybmluZyBmb3IgdGhlIHZhbHVlIG9mICZxdW90O3N1YiZxdW90Ow0KaW4gdGhlIHRv
a2VuIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgKDwvZm9udD48YSBocmVmPSJodHRwOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVjdGlvbi0wNCNzZWN0aW9u
LTIuMiI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cDov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDQj
c2VjdGlvbi0yLjI8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+
KS4NCiZuYnNwO1RoZSAmcXVvdDtjbGllbnRfaWQmcXVvdDsgdmFsdWUgcmVxdWVzdGluZyB0aGUg
Z3JhbnQsIG9yIHNvbWUgb3RoZXINCmNsaWVudCByZWdpc3RyYXRpb24gbWV0YWRhdGEgdmFsdWU/
PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pg0KPHRhYmxlIHdpZHRoPTIyMyBzdHlsZT0iYm9y
ZGVyLWNvbGxhcHNlOmNvbGxhcHNlOyI+DQo8dHIgaGVpZ2h0PTg+DQo8dGQgd2lkdGg9MjIxIGJn
Y29sb3I9d2hpdGUgc3R5bGU9ImJvcmRlci1zdHlsZTpzb2xpZDtib3JkZXItY29sb3I6IzAwMDAw
MDtib3JkZXItd2lkdGg6MHB4IDBweCAwcHggMHB4O3BhZGRpbmc6MXB4IDFweDsiPjxmb250IHNp
emU9MSBmYWNlPSJWZXJkYW5hIj48Yj48YnI+DQo8YnI+DQo8YnI+DQpUb2RkIExhaW5oYXJ0PGJy
Pg0KUmF0aW9uYWwgc29mdHdhcmU8YnI+DQpJQk0gQ29ycG9yYXRpb248YnI+DQo1NTAgS2luZyBT
dHJlZXQsIExpdHRsZXRvbiwgTUEgMDE0NjAtMTI1MDwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZh
Y2U9IkFyaWFsIj48Yj48YnI+DQoxLTk3OC04OTktNDcwNTxicj4NCjItMjc2LTQ3MDUgKFQvTCk8
L2I+PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEg
aHJlZj1tYWlsdG86bGFpbmhhcnRAdXMuaWJtLmNvbT48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBm
YWNlPSJBcmlhbCI+PGI+PHU+bGFpbmhhcnRAdXMuaWJtLmNvbTwvdT48L2I+PC9mb250PjwvYT48
L3RhYmxlPg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+PHR0Pjxm
b250IHNpemU9Mz48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDwvZm9udD48L3R0Pjxmb250IHNpemU9MyBj
b2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86T0F1dGhAaWV0Zi5v
cmc+PHR0Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pk9BdXRoQGlldGYub3JnPC91PjwvZm9u
dD48L3R0PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT48YnI+DQo8L3U+PC9mb250Pjxh
IGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD48dHQ+PGZv
bnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aDwvdT48L2ZvbnQ+PC90dD48L2E+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NCjwv
Zm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W2F0dGFjaG1lbnQgJnF1
b3Q7c2lnbmF0dXJlLmFzYyZxdW90Ow0KZGVsZXRlZCBieSBUb2RkIFcgTGFpbmhhcnQvTGV4aW5n
dG9uL0lCTV0gPC9mb250Pg0KPGJyPg0K
--=_alternative 0076F9F785257CF5_=--


From nobody Fri Jun 13 07:21:26 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACB51B2937 for ; Fri, 13 Jun 2014 07:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGid8pZhp-mE for ; Fri, 13 Jun 2014 07:21:23 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 46E7D1A00D1 for ; Fri, 13 Jun 2014 07:21:23 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5DELM5p016827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 13 Jun 2014 10:21:22 -0400
Received: from localhost.localdomain (vpn-53-247.rdu2.redhat.com [10.10.53.247]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5DELLSn025475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 13 Jun 2014 10:21:22 -0400
Message-ID: <539B08E1.2070204@redhat.com>
Date: Fri, 13 Jun 2014 09:21:21 -0500
From: Anil Saldhana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Sh7uFrp-KV7Z3T05TWPzbCnHn_8
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 14:21:25 -0000

On 06/12/2014 12:22 PM, Phil Hunt wrote:
> One of the use cases is to return only a token that is NOT an access token and is only an authentication assertion that is not opaque to the client.
>
> A key concern is clients do not always want to ask users for consent to access their profiles or any other resource.  They just want authentication.
>
> How many times do we see things like login with Yahoo, Twitter, Facebook and they apparently want access to too much information?  I’ve got lots of web site developers who don’t want that because it looses registrations as a significant percentage of users always refuse.  These developers  just want an authn ctx and the easy-sign-on benefits.
If the developers want just the authentication context and not the 
entire details about the user from providers such as Facebook, can we 
just not ask with an appropriate scope for the provider? Something like 
scope=username or scope=useremail. When the provider gives the data, 
then it is understood that there was authentication and some user consent.


>  From this standpoint, having separate tokens makes sense.  One remains opaque to the client targeted for the resource server. The other is for the client.
>
> You could have a new token type that can be dual-purpose and parseable to everyone, but I think that may end up being more confusing.  It would also mean impacts to resource servers to support a new non-opaque token type.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
> On Jun 12, 2014, at 1:04 AM, Hannes Tschofenig  wrote:
>
>> Torsten,
>>
>> nobody suggested that the access token would suddenly not be opaque to
>> the client.
>>
>> The question therefore is whether the id token is not opaque to the
>> client. Is that the assumption?
>>
>> On 06/05/2014 09:39 PM, Torsten Lodderstedt wrote:
>>> the access token is opaque to the client. That's great! Let's keep it
>>> that way.
>> Ciao
>> Hannes
>>


From nobody Fri Jun 13 07:25:03 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7521B2935 for ; Fri, 13 Jun 2014 07:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lWPUwVAZhLU for ; Fri, 13 Jun 2014 07:25:00 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id DF47E1B2919 for ; Fri, 13 Jun 2014 07:25:00 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5DEP0Yo026194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 13 Jun 2014 10:25:00 -0400
Received: from [10.10.50.141] (vpn-50-141.rdu2.redhat.com [10.10.50.141]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5DEOxwA003893 for ; Fri, 13 Jun 2014 10:25:00 -0400
Message-ID: <539B09BB.7090304@redhat.com>
Date: Fri, 13 Jun 2014 10:24:59 -0400
From: Bill Burke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <539B08E1.2070204@redhat.com>
In-Reply-To: <539B08E1.2070204@redhat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CLP1vM1EevQkRsgHN3IH9YxdF7E
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 14:25:02 -0000

On 6/13/2014 10:21 AM, Anil Saldhana wrote:
> On 06/12/2014 12:22 PM, Phil Hunt wrote:
>> One of the use cases is to return only a token that is NOT an access
>> token and is only an authentication assertion that is not opaque to
>> the client.
>>
>> A key concern is clients do not always want to ask users for consent
>> to access their profiles or any other resource.  They just want
>> authentication.
>>
>> How many times do we see things like login with Yahoo, Twitter,
>> Facebook and they apparently want access to too much information?
>> I’ve got lots of web site developers who don’t want that because it
>> looses registrations as a significant percentage of users always
>> refuse.  These developers  just want an authn ctx and the easy-sign-on
>> benefits.
> If the developers want just the authentication context and not the
> entire details about the user from providers such as Facebook, can we
> just not ask with an appropriate scope for the provider? Something like
> scope=username or scope=useremail. When the provider gives the data,
> then it is understood that there was authentication and some user consent.

OpenID Connect already has this defined:

http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From nobody Fri Jun 13 08:23:43 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34BE1B2812 for ; Fri, 13 Jun 2014 08:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YroUqOh-vYk5 for ; Fri, 13 Jun 2014 08:23:37 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id C13001A0108 for ; Fri, 13 Jun 2014 08:23:37 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5DFNa3e002419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 13 Jun 2014 11:23:36 -0400
Received: from localhost.localdomain (vpn-53-247.rdu2.redhat.com [10.10.53.247]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5DFNYuO014452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 13 Jun 2014 11:23:35 -0400
Message-ID: <539B1776.8040808@redhat.com>
Date: Fri, 13 Jun 2014 10:23:34 -0500
From: Anil Saldhana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <539B08E1.2070204@redhat.com> <539B09BB.7090304@redhat.com>
In-Reply-To: <539B09BB.7090304@redhat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6fjEMllJoEbzrh5SENG_F-1NnkU
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 15:23:39 -0000

On 06/13/2014 09:24 AM, Bill Burke wrote:
>
>
> On 6/13/2014 10:21 AM, Anil Saldhana wrote:
>> On 06/12/2014 12:22 PM, Phil Hunt wrote:
>>> One of the use cases is to return only a token that is NOT an access
>>> token and is only an authentication assertion that is not opaque to
>>> the client.
>>>
>>> A key concern is clients do not always want to ask users for consent
>>> to access their profiles or any other resource.  They just want
>>> authentication.
>>>
>>> How many times do we see things like login with Yahoo, Twitter,
>>> Facebook and they apparently want access to too much information?
>>> I’ve got lots of web site developers who don’t want that because it
>>> looses registrations as a significant percentage of users always
>>> refuse.  These developers  just want an authn ctx and the easy-sign-on
>>> benefits.
>> If the developers want just the authentication context and not the
>> entire details about the user from providers such as Facebook, can we
>> just not ask with an appropriate scope for the provider? Something like
>> scope=username or scope=useremail. When the provider gives the data,
>> then it is understood that there was authentication and some user 
>> consent.
>
> OpenID Connect already has this defined:
>
> http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>
Bill - thanks - I forgot about those. :-) Most of them come from the 
Open 1.0 world.


From nobody Fri Jun 13 08:46:57 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947831B2969 for ; Fri, 13 Jun 2014 08:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY86W80wX5-U for ; Fri, 13 Jun 2014 08:46:55 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B16BF1B2966 for ; Fri, 13 Jun 2014 08:46:55 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5DFksx6019234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jun 2014 15:46:55 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5DFkrZm025365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2014 15:46:54 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5DFkrUN006440; Fri, 13 Jun 2014 15:46:53 GMT
Received: from [192.168.2.5] (/50.148.174.222) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Jun 2014 08:46:53 -0700
Message-ID: <539B1CED.9050404@oracle.com>
Date: Fri, 13 Jun 2014 08:46:53 -0700
From: Prateek Mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Bill Burke , IETF oauth WG 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com>
In-Reply-To: <539A0497.7070906@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5w4uBXrJDqiFpqMye9zHlwnkbt4
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 15:46:56 -0000

Thanks, Bill - I certainly appreciate the comment from an implementor 
who wasnt involved in the OIDC protocol design.

My understanding of the discussion around a4c is one of a minimalist 
extension to OAuth, not a full-featured one like OIDC.
One concern I have heard expressed is that OIDC is so large and full 
featured that most people just implement some
subset of their own choice. I believe this is the case with all the 
large consumer web sites.

I would welcome the publication of a minimalist draft from OIDC to the 
OAuth IETF. We have spent a lot of time lobbying for
this outcome! There is no question in my mind that the review within 
IETF would be more comprehensive and expose the work
to a larger community.

- prateek

>
>
> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has
>> received review from maybe a dozen engineers within the OpenID 
>> community.
>>
>
> The OpenID Connect spec is 86 pages because it pretty much rehashes 
> the OAuth2 spec walking through each flow and how Open ID Connect 
> expands on that flow.  A4c looks like a subset of this work minus some 
> additional claims and, IMO, is incomplete compared to OIDC.
>
> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We 
> originally were creating our own oauth2 extension using JWT, but found 
> that any feature we wanted to define already existed in OpenID 
> Connect.  These guys have done great work.   Aren't many of you here 
> authors of this spec and/or the same companies?!?  I think your 
> energies are better focused on lobbying OIDC to join the IETF and this 
> WG.
>
>


From nobody Fri Jun 13 09:03:52 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF261B2993 for ; Fri, 13 Jun 2014 09:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFH9vF30qoPV for ; Fri, 13 Jun 2014 09:03:41 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3911B2990 for ; Fri, 13 Jun 2014 09:03:41 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5DG3eHk009297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Jun 2014 12:03:40 -0400
Received: from [10.10.50.141] (vpn-50-141.rdu2.redhat.com [10.10.50.141]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5DG3duB008164; Fri, 13 Jun 2014 12:03:39 -0400
Message-ID: <539B20DA.5010409@redhat.com>
Date: Fri, 13 Jun 2014 12:03:38 -0400
From: Bill Burke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Phil Hunt 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com>
In-Reply-To: <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_nA2FJ_fOzzpRYaRoTDlfKWWNuE
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 16:03:46 -0000

On 6/12/2014 4:18 PM, Phil Hunt wrote:
>
>
> Phil
>
>> On Jun 12, 2014, at 12:50, Bill Burke  wrote:
>>
>>
>>
>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has
>>> received review from maybe a dozen engineers within the OpenID community.
>>
>> The OpenID Connect spec is 86 pages because it pretty much rehashes the OAuth2 spec walking through each flow and how Open ID Connect expands on that flow.  A4c looks like a subset of this work minus some additional claims and, IMO, is incomplete compared to OIDC.
> In what regards?
>
> Much of oidc is out of scope for this requirement.
>

What is in a4c that isn't already in OIDC?

> It is a bit like saying an 18 wheeler is suitable for driving the kids to school. :-)

I don't think this is true.  Most oidc oauth extensions are optional 
with the sole requirement that providers don't barf if you send them.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From nobody Fri Jun 13 09:21:48 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC781B29A5 for ; Fri, 13 Jun 2014 09:21:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGrZYfH2rRoA for ; Fri, 13 Jun 2014 09:21:43 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3A31A1B29A9 for ; Fri, 13 Jun 2014 09:21:43 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5DGLgMB012231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Jun 2014 12:21:42 -0400
Received: from [10.10.50.141] (vpn-50-141.rdu2.redhat.com [10.10.50.141]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5DGLfuM018106; Fri, 13 Jun 2014 12:21:42 -0400
Message-ID: <539B2515.90005@redhat.com>
Date: Fri, 13 Jun 2014 12:21:41 -0400
From: Bill Burke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Prateek Mishra , IETF oauth WG 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <539B1CED.9050404@oracle.com>
In-Reply-To: <539B1CED.9050404@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Sj4sR0gRHTsQHdzd01qw12OUvb8
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 16:21:45 -0000

On 6/13/2014 11:46 AM, Prateek Mishra wrote:
> Thanks, Bill - I certainly appreciate the comment from an implementor
> who wasnt involved in the OIDC protocol design.
>
> My understanding of the discussion around a4c is one of a minimalist
> extension to OAuth, not a full-featured one like OIDC.
> One concern I have heard expressed is that OIDC is so large and full
> featured that most people just implement some
> subset of their own choice. I believe this is the case with all the
> large consumer web sites.
>
> I would welcome the publication of a minimalist draft from OIDC to the
> OAuth IETF. We have spent a lot of time lobbying for
> this outcome! There is no question in my mind that the review within
> IETF would be more comprehensive and expose the work
> to a larger community.
>

I don't think a minimalist draft of OIDC is needed as many of the 
extensions are optional.   Our implementation was already Oauth2/JWT 
based and it was really easy to meet the minimal requirements of OIDC core.

To create competing standards at IETF just because OIDC is not part of 
IETF, IMO, is a disservice to the community.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From nobody Fri Jun 13 09:24:16 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696391B2974 for ; Fri, 13 Jun 2014 09:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXCKsQnlhZtp for ; Fri, 13 Jun 2014 09:24:12 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0CD1A00D2 for ; Fri, 13 Jun 2014 09:24:12 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5DGOA4i029376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jun 2014 16:24:11 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5DGO9N2018766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2014 16:24:10 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5DGO9od018773; Fri, 13 Jun 2014 16:24:09 GMT
Received: from [192.168.2.5] (/50.148.174.222) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Jun 2014 09:24:09 -0700
Message-ID: <539B25A8.4050404@oracle.com>
Date: Fri, 13 Jun 2014 09:24:08 -0700
From: Prateek Mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Bill Burke , Phil Hunt 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com> <539B20DA.5010409@redhat.com>
In-Reply-To: <539B20DA.5010409@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kqLRwBNoOAR1rCdx3DscKQlOdRI
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 16:24:13 -0000

Excellent, now you have put your finger on the precise issue with OIDC - 
lots of optional extensions and shiny trinkets and lack of a clear 
definition of a core subset
for servers.

I realize its exciting for consultants, software and toolkit vendors to 
have that sort of optionality, but in practice, its NOT A GOOD THING in 
a protocol.

[quote]
>
>> It is a bit like saying an 18 wheeler is suitable for driving the 
>> kids to school. :-)
>
> I don't think this is true.  Most oidc oauth extensions are optional 
> with the sole requirement that providers don't barf if you send them.
>
[\quote]


From nobody Fri Jun 13 09:27:16 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C66A1B2974 for ; Fri, 13 Jun 2014 09:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPIY0iU0FkFX for ; Fri, 13 Jun 2014 09:27:12 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 30E081B29A9 for ; Fri, 13 Jun 2014 09:27:12 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5DGRAJ9028272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 13 Jun 2014 12:27:11 -0400
Received: from localhost.localdomain (vpn-53-247.rdu2.redhat.com [10.10.53.247]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5DGR9Sn018318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 13 Jun 2014 12:27:10 -0400
Message-ID: <539B265D.3020505@redhat.com>
Date: Fri, 13 Jun 2014 11:27:09 -0500
From: Anil Saldhana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com> <539B20DA.5010409@redhat.com> <539B25A8.4050404@oracle.com>
In-Reply-To: <539B25A8.4050404@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fk4iwXAXj_rbwXIkDoh7kdjvzjc
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 16:27:14 -0000

For me it boils down to this:
OAuth deals with Authorization.

Authentication needs to be outside its realm - whether it is OIDC, SAML 
or other protocols, it is fine.

The security community has just muddled up things for end users, 
implementors and adopters.

We need to start having clear cut separation in the standards.

On 06/13/2014 11:24 AM, Prateek Mishra wrote:
> Excellent, now you have put your finger on the precise issue with OIDC 
> - lots of optional extensions and shiny trinkets and lack of a clear 
> definition of a core subset
> for servers.
>
> I realize its exciting for consultants, software and toolkit vendors 
> to have that sort of optionality, but in practice, its NOT A GOOD 
> THING in a protocol.
>
> [quote]
>>
>>> It is a bit like saying an 18 wheeler is suitable for driving the 
>>> kids to school. :-)
>>
>> I don't think this is true.  Most oidc oauth extensions are optional 
>> with the sole requirement that providers don't barf if you send them.
>>
> [\quote]
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Fri Jun 13 09:28:00 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC6D1A0151 for ; Fri, 13 Jun 2014 09:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPNaGB_UH2mH for ; Fri, 13 Jun 2014 09:27:56 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79AE51A00D2 for ; Fri, 13 Jun 2014 09:27:56 -0700 (PDT)
Received: from BY2PR03CA030.namprd03.prod.outlook.com (10.242.234.151) by BN1PR0301MB0627.namprd03.prod.outlook.com (25.160.171.12) with Microsoft SMTP Server (TLS) id 15.0.949.11; Fri, 13 Jun 2014 16:27:54 +0000
Received: from BN1AFFO11FD035.protection.gbl (2a01:111:f400:7c10::104) by BY2PR03CA030.outlook.office365.com (2a01:111:e400:2c2c::23) with Microsoft SMTP Server (TLS) id 15.0.959.24 via Frontend Transport; Fri, 13 Jun 2014 16:27:53 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD035.mail.protection.outlook.com (10.58.52.159) with Microsoft SMTP Server (TLS) id 15.0.959.15 via Frontend Transport; Fri, 13 Jun 2014 16:27:52 +0000
Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.173]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0195.002; Fri, 13 Jun 2014 16:27:22 +0000
From: Mike Jones 
To: Prateek Mishra , Bill Burke , Phil Hunt 
Thread-Topic: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
Thread-Index: AQHPgJJX++40qT3NTkqX94iwQ4eIlptiq6AAgAActfCAAB0AgIAABUcAgAo+PICAAFlvAIAAAZAAgAA3lQCAADKkgIAAB9WAgAFLCQCAAAW6AIAAAEtg
Date: Fri, 13 Jun 2014 16:27:21 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD6CA36@TK5EX14MBXC292.redmond.corp.microsoft.com>
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com> <539B20DA.5010409@redhat.com> <539B25A8.4050404@oracle.com>
In-Reply-To: <539B25A8.4050404@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD6CA36TK5EX14MBXC292r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438001)(51704005)(377454003)(189002)(199002)(13464003)(85806002)(19580405001)(83322001)(512954002)(81156002)(86362001)(2656002)(6806004)(44976005)(104016001)(4396001)(15202345003)(19300405004)(92566001)(19625215002)(86612001)(87936001)(92726001)(26826002)(19580395003)(21056001)(69596002)(71186001)(84326002)(15975445006)(68736004)(93886003)(33656002)(81342001)(76482001)(55846006)(46102001)(84676001)(99396002)(81542001)(15395725005)(97736001)(83072002)(66066001)(80022001)(20776003)(64706001)(85852003)(31966008)(74662001)(74502001)(54356999)(76176999)(50986999)(79102001)(77982001)(16236675004); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR0301MB0627; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0241D5F98C
Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; 
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/aqG48UdVqn0rTQBehumYOOKAeqY
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 16:27:59 -0000

--_000_4E1F6AAD24975D4BA5B16804296739439AD6CA36TK5EX14MBXC292r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Actually, there is a very clear definition of what the minimal Mandatory To=
 Implement (MTI) in OpenID Connect is - it's right in the spec.  See the (q=
uite short) sections:

    15.1.  =
Mandatory to Implement Features for All OpenID Providers
    15.2. =
 Mandatory to Implement Features for Dynamic OpenID Providers



                                                            -- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Prateek Mishra
Sent: Friday, June 13, 2014 9:24 AM
To: Bill Burke; Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c



Excellent, now you have put your finger on the precise issue with OIDC - lo=
ts of optional extensions and shiny trinkets and lack of a clear definition=
 of a core subset for servers.



I realize its exciting for consultants, software and toolkit vendors to hav=
e that sort of optionality, but in practice, its NOT A GOOD THING in a prot=
ocol.



[quote]

>

>> It is a bit like saying an 18 wheeler is suitable for driving the

>> kids to school. :-)

>

> I don't think this is true.  Most oidc oauth extensions are optional

> with the sole requirement that providers don't barf if you send them.

>

[\quote]



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

--_000_4E1F6AAD24975D4BA5B16804296739439AD6CA36TK5EX14MBXC292r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Actually, there is a very clear definition of wha=
t the minimal Mandatory To Implement (MTI) in OpenID Connect is - it's righ=
t in the spec.  See the (quite short) sections:


    15=
.1.  Mandatory to Implement Features for All OpenID Providers<=
br>
    15.2.  Mandatory to Implement Feat=
ures for Dynamic OpenID Providers


 


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


-----Original Message-----

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Prateek Mishra

Sent: Friday, June 13, 2014 9:24 AM

To: Bill Burke; Phil Hunt

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c


 


Excellent, now you have put your finger on the pr=
ecise issue with OIDC - lots of optional extensions and shiny trinkets and =
lack of a clear definition of a core subset for servers.


 


I realize its exciting for consultants, software =
and toolkit vendors to have that sort of optionality, but in practice, its =
NOT A GOOD THING in a protocol.


 


[quote]


> 


>> It is a bit like saying an 18 wheeler is=
 suitable for driving the



>> kids to school. :-)


> 


> I don't think this is true.  Most oidc =
oauth extensions are optional



> with the sole requirement that providers don=
't barf if you send them.


> 


[\quote]


 


_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ie=
tf.org/mailman/listinfo/oauth






--_000_4E1F6AAD24975D4BA5B16804296739439AD6CA36TK5EX14MBXC292r_--


From nobody Fri Jun 13 09:54:51 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11731B2938 for ; Fri, 13 Jun 2014 09:54:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level: 
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI4jftJd1q0A for ; Fri, 13 Jun 2014 09:54:46 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98D91B291C for ; Fri, 13 Jun 2014 09:54:45 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5DGsiMo002616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jun 2014 16:54:45 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5DGsi1W028827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2014 16:54:44 GMT
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5DGshqi007922; Fri, 13 Jun 2014 16:54:43 GMT
Received: from [192.168.2.5] (/50.148.174.222) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Jun 2014 09:54:43 -0700
Message-ID: <539B2CD3.8090903@oracle.com>
Date: Fri, 13 Jun 2014 09:54:43 -0700
From: Prateek Mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Mike Jones , Bill Burke ,  Phil Hunt 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com> <539B20DA.5010409@redhat.com> <539B25A8.4050404@oracle.com> <4E1F6AAD24975D4BA5B16804296739439AD6CA36@TK5EX14MBXC292.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD6CA36@TK5EX14MBXC292.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------070300060401080208080901"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lDL-5cQ0q6vQgkbvQ2gR1I_hPFU
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 16:54:47 -0000

This is a multi-part message in MIME format.
--------------070300060401080208080901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mike -  when i see language like

[quote]
This list augments the set of features that are already listed elsewhere 
as being "REQUIRED" or are described with a "MUST", and so is not, by 
itself, a comprehensive set of implementation requirements for OPs.
[\quote]

in Section 15.1, I have to say this isn't a clear definition of what is 
MTI.

I guess someone could through comprehensive research determine exactly 
what might be meant by this section, but that doesn't meet the criteria 
of "very clear definition of MTI".

- prateek

- prateek

> Actually, there is a very clear definition of what the minimal 
> Mandatory To Implement (MTI) in OpenID Connect is - it's right in the 
> spec.  See the (quite short) sections:
>
> *15.1.* 
>  
> Mandatory to Implement Features for All OpenID Providers
> *15.2.* 
>  
> Mandatory to Implement Features for Dynamic OpenID Providers
>
> -- Mike
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Prateek Mishra
> Sent: Friday, June 13, 2014 9:24 AM
> To: Bill Burke; Phil Hunt
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
>
> Excellent, now you have put your finger on the precise issue with OIDC 
> - lots of optional extensions and shiny trinkets and lack of a clear 
> definition of a core subset for servers.
>
> I realize its exciting for consultants, software and toolkit vendors 
> to have that sort of optionality, but in practice, its NOT A GOOD 
> THING in a protocol.
>
> [quote]
>
> >
>
> >> It is a bit like saying an 18 wheeler is suitable for driving the
>
> >> kids to school. :-)
>
> >
>
> > I don't think this is true.  Most oidc oauth extensions are optional
>
> > with the sole requirement that providers don't barf if you send them.
>
> >
>
> [\quote]
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org 
>
> https://www.ietf.org/mailman/listinfo/oauth
>


--------------070300060401080208080901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Mike -  when i see language like 

    

    [quote]

    This list augments the set of features that are already listed
    elsewhere as being "REQUIRED" or are described with a "MUST", and so
    is not, by itself, a comprehensive set of implementation
    requirements for OPs. 

    [\quote]

    

    in Section 15.1, I have to say this isn't a clear definition of what
    is MTI. 

    

    I guess someone could through comprehensive research determine
    exactly what might be meant by this section, but that doesn't meet
    the criteria of "very clear definition of MTI".

    

    - prateek

    

    - prateek

    

    

      
      
      
      

        
Actually, there is a very clear
          definition of what the minimal Mandatory To Implement (MTI) in
          OpenID Connect is - it's right in the spec.  See the (quite
          short) sections:

        
    15.1. 
            Mandatory to Implement Features for All OpenID Providers

                15.2. 
            Mandatory to Implement Features for Dynamic OpenID Providers

        
 

        
                                                           
          -- Mike

        
-----Original Message-----

          From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of
          Prateek Mishra

          Sent: Friday, June 13, 2014 9:24 AM

          To: Bill Burke; Phil Hunt

          Cc: oauth@ietf.org

          Subject: Re: [OAUTH-WG] Question regarding
          draft-hunt-oauth-v2-user-a4c

        
 

        
Excellent, now you have put your finger
          on the precise issue with OIDC - lots of optional extensions
          and shiny trinkets and lack of a clear definition of a core
          subset for servers.

        
 

        
I realize its exciting for consultants,
          software and toolkit vendors to have that sort of optionality,
          but in practice, its NOT A GOOD THING in a protocol.

        
 

        
[quote]

        
> 

        
>> It is a bit like saying an 18
          wheeler is suitable for driving the
          

        
>> kids to school. :-)

        
> 

        
> I don't think this is true.  Most
          oidc oauth extensions are optional
          

        
> with the sole requirement that
          providers don't barf if you send them.

        
> 

        
[\quote]

        
 

        
_______________________________________________

        
OAuth mailing list

        
OAuth@ietf.org

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

      

    

    

  


--------------070300060401080208080901--


From nobody Fri Jun 13 10:10:31 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE08D1B297B for ; Fri, 13 Jun 2014 10:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcICWDzjF9js for ; Fri, 13 Jun 2014 10:10:28 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 331831A0190 for ; Fri, 13 Jun 2014 10:10:28 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5DHARBr002009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Jun 2014 13:10:27 -0400
Received: from [10.10.50.141] (vpn-50-141.rdu2.redhat.com [10.10.50.141]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5DHAQC9014708; Fri, 13 Jun 2014 13:10:27 -0400
Message-ID: <539B3081.6010600@redhat.com>
Date: Fri, 13 Jun 2014 13:10:25 -0400
From: Bill Burke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Prateek Mishra , Phil Hunt 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com> <539B20DA.5010409@redhat.com> <539B25A8.4050404@oracle.com>
In-Reply-To: <539B25A8.4050404@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/i7ATtsPqwIPaeSOrphdWoNJaG8M
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 17:10:30 -0000

On 6/13/2014 12:24 PM, Prateek Mishra wrote:
> Excellent, now you have put your finger on the precise issue with OIDC -
> lots of optional extensions and shiny trinkets and lack of a clear
> definition of a core subset
> for servers.
>

OIDC is a very clear specification.  Your phrase "shiny trinkets" hints 
that there are a lot of silly features in OIDC.  I disagree with your 
assessment.  I just see features that I want to implement and are on our 
roadmap.  At the same time, I'm relieved that I can call myself an OIDC 
compliant implementation and put off implementing these features for a 
later date.

Also, you make it sound like OIDC is this big bloated specification.  I 
completely disagree with your assessment.  Personally I see OIDC as a 
specification driven by real-world requirements and experience.


> I realize its exciting for consultants, software and toolkit vendors to
> have that sort of optionality, but in practice, its NOT A GOOD THING in
> a protocol.
>

I disagree.  If OIDC core was instead broken up into a set of smaller 
optional specifications, you would run the risk of having zero 
interoperability.  Maybe that is your end-goal, but it certainly isn't 
mine.  Most of the language around optional features states that "if you 
don't implement this, your implementation needs to handle it 
gracefully".  All *GOOD* things for a protocol.

But, IMO, there is no difference in having a complete, robust 
specification like OIDC that has a lot of optional parts from re-hashing 
OIDC at the IETF with a lot of optional specifications.  Other than 
causing confusion in the community, of course.

Let me further say that my experience as an OAuth 2.0 implementor was 
difficult as it was hard to put a finger on what exact OAuth 2 
extensions people were gravitating towards.  OIDC, for me at least, gave 
a much more complete direction for my project.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From nobody Fri Jun 13 10:11:00 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221261B29A9 for ; Fri, 13 Jun 2014 10:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aj_f0mrRVV60 for ; Fri, 13 Jun 2014 10:10:53 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7801B29B4 for ; Fri, 13 Jun 2014 10:10:53 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5DHApaI021141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jun 2014 17:10:52 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5DHApZn007965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2014 17:10:51 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5DHAoSt028244; Fri, 13 Jun 2014 17:10:50 GMT
Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Jun 2014 10:10:50 -0700
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Phil Hunt 
In-Reply-To: <539B20DA.5010409@redhat.com>
Date: Fri, 13 Jun 2014 10:10:48 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <748D0DD4-F6FB-4EB8-94F4-86E79A448881@oracle.com>
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com> <539B20DA.5010409@redhat.com>
To: Bill Burke 
X-Mailer: Apple Mail (2.1878.2)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Y6DS1WkAXUXTmXL2hW4WaE4_wlw
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 17:10:56 -0000

I am going to address a few comments all together here:

1. John Bradley confirmed again yesterday, OIDC does not allow for =
authentication only as part of the normal code flow and decided =
intentionally not to address it.  So to say OIDC has a solution is =
confusing.

OIDC has the solution if you want to propagate profile information and =
authen information.  This means service providers have to implement much =
more code, and clients have to as well. For many there are customer =
abandonment and legal issues around sharing of too much PII information. =
They DO NOT want to have to ask for this information.

2. Regarding speculative future size: I  point out that the A4C draft is =
modelled exactly on the authorizaiton flow and has exactly the same =
security model. Therefore I would not expect any large increase in size, =
but rather the opposite. The number 1 challenge with this spec is not =
figuring out how to do this, but how to avoid scope creep into OIDC=92s =
coverage.  I do NOT support scope creep into OIDC. =20

We need a specific draft that addresses the issues of developers =
thinking 6749 is sufficient on its own.  I do NOT want to see stuff like =
browser based apps and node.js as in scope. OIDC has this covered.

3. My point with the 18 wheeler analogy is that yes, it is a vehicle =
that can take passengers, but it=92s role is much more multi-purpose and =
heavy duty. For the developer that wants to securely take the kids to =
school, maybe just a Tesla Model S will do? This is less of a technical =
issue and more of a =93market=94 issue. I know that=92s hard for people =
like us to address, but it is a comment I keep hearing over and over =
(and not interestingly from Oracle itself).

4. As for confusion between OAuth=92s intended authorization and a so =
called new authen function. This is the issue I=92m trying to get on our =
agenda. This isn=92t my idea, I am only the messenger. The fact is, =
developers and service providers who are not OAuth experts assume OAuth =
is about authentication and implement as such.  To some extent, this is  =
a market problem. Still, OIDC has not addressed the scenario. As John =
stated, OIDC choose not to do authen only. =20

5. As for whether we =93tack-on=94 authen to OAuth as OIDC does or =
whether we create a brand new endpoint or flow. I think that is open for =
discussion once the charter is adopted.  A4C is just an input draft - =
not the way the group needs to solve it.  A4C is intended to show the =
problem is solvable in a reasonably implementable manner.

Phil

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



On Jun 13, 2014, at 9:03 AM, Bill Burke  wrote:

>=20
>=20
> On 6/12/2014 4:18 PM, Phil Hunt wrote:
>>=20
>>=20
>> Phil
>>=20
>>> On Jun 12, 2014, at 12:50, Bill Burke  wrote:
>>>=20
>>>=20
>>>=20
>>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>>>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has
>>>> received review from maybe a dozen engineers within the OpenID =
community.
>>>=20
>>> The OpenID Connect spec is 86 pages because it pretty much rehashes =
the OAuth2 spec walking through each flow and how Open ID Connect =
expands on that flow.  A4c looks like a subset of this work minus some =
additional claims and, IMO, is incomplete compared to OIDC.
>> In what regards?
>>=20
>> Much of oidc is out of scope for this requirement.
>>=20
>=20
> What is in a4c that isn't already in OIDC?
>=20
>> It is a bit like saying an 18 wheeler is suitable for driving the =
kids to school. :-)
>=20
> I don't think this is true.  Most oidc oauth extensions are optional =
with the sole requirement that providers don't barf if you send them.
>=20
> --=20
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com


From nobody Fri Jun 13 10:16:02 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568741A0190 for ; Fri, 13 Jun 2014 10:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5clVkoXVr0KG for ; Fri, 13 Jun 2014 10:16:00 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 08C9B1A0178 for ; Fri, 13 Jun 2014 10:16:00 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5DHFxMb013001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 13 Jun 2014 13:15:59 -0400
Received: from localhost.localdomain (vpn-53-247.rdu2.redhat.com [10.10.53.247]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5DHFwdT008237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 13 Jun 2014 13:15:59 -0400
Message-ID: <539B31CE.3090803@redhat.com>
Date: Fri, 13 Jun 2014 12:15:58 -0500
From: Anil Saldhana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com> <539B20DA.5010409@redhat.com> <748D0DD4-F6FB-4EB8-94F4-86E79A448881@oracle.com>
In-Reply-To: <748D0DD4-F6FB-4EB8-94F4-86E79A448881@oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5lIWkFwSGK8-Jb3hHhyUUyxxIl4
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 17:16:01 -0000

Phil - I want to hear who are those developers supporting a4c. You keep 
saying developers developers. I am not one of them.

This mailing list has clearly shown total disregard for the a4c 
proposal.  Please try to accept the community sentiment and 
unnecessarily don't extend this discussion into a lengthy email 
discussion when there is no clear acceptance for a4c.

On 06/13/2014 12:10 PM, Phil Hunt wrote:
> I am going to address a few comments all together here:
>
> 1. John Bradley confirmed again yesterday, OIDC does not allow for authentication only as part of the normal code flow and decided intentionally not to address it.  So to say OIDC has a solution is confusing.
>
> OIDC has the solution if you want to propagate profile information and authen information.  This means service providers have to implement much more code, and clients have to as well. For many there are customer abandonment and legal issues around sharing of too much PII information. They DO NOT want to have to ask for this information.
>
> 2. Regarding speculative future size: I  point out that the A4C draft is modelled exactly on the authorizaiton flow and has exactly the same security model. Therefore I would not expect any large increase in size, but rather the opposite. The number 1 challenge with this spec is not figuring out how to do this, but how to avoid scope creep into OIDC’s coverage.  I do NOT support scope creep into OIDC.
>
> We need a specific draft that addresses the issues of developers thinking 6749 is sufficient on its own.  I do NOT want to see stuff like browser based apps and node.js as in scope. OIDC has this covered.
>
> 3. My point with the 18 wheeler analogy is that yes, it is a vehicle that can take passengers, but it’s role is much more multi-purpose and heavy duty. For the developer that wants to securely take the kids to school, maybe just a Tesla Model S will do? This is less of a technical issue and more of a “market” issue. I know that’s hard for people like us to address, but it is a comment I keep hearing over and over (and not interestingly from Oracle itself).
>
> 4. As for confusion between OAuth’s intended authorization and a so called new authen function. This is the issue I’m trying to get on our agenda. This isn’t my idea, I am only the messenger. The fact is, developers and service providers who are not OAuth experts assume OAuth is about authentication and implement as such.  To some extent, this is  a market problem. Still, OIDC has not addressed the scenario. As John stated, OIDC choose not to do authen only.
>
> 5. As for whether we “tack-on” authen to OAuth as OIDC does or whether we create a brand new endpoint or flow. I think that is open for discussion once the charter is adopted.  A4C is just an input draft - not the way the group needs to solve it.  A4C is intended to show the problem is solvable in a reasonably implementable manner.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
> On Jun 13, 2014, at 9:03 AM, Bill Burke  wrote:
>
>>
>> On 6/12/2014 4:18 PM, Phil Hunt wrote:
>>>
>>> Phil
>>>
>>>> On Jun 12, 2014, at 12:50, Bill Burke  wrote:
>>>>
>>>>
>>>>
>>>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>>>>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has
>>>>> received review from maybe a dozen engineers within the OpenID community.
>>>> The OpenID Connect spec is 86 pages because it pretty much rehashes the OAuth2 spec walking through each flow and how Open ID Connect expands on that flow.  A4c looks like a subset of this work minus some additional claims and, IMO, is incomplete compared to OIDC.
>>> In what regards?
>>>
>>> Much of oidc is out of scope for this requirement.
>>>
>> What is in a4c that isn't already in OIDC?
>>
>>> It is a bit like saying an 18 wheeler is suitable for driving the kids to school. :-)
>> I don't think this is true.  Most oidc oauth extensions are optional with the sole requirement that providers don't barf if you send them.
>>


From nobody Fri Jun 13 10:26:59 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519FF1A0880 for ; Fri, 13 Jun 2014 10:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljdUxF4sxT3k for ; Fri, 13 Jun 2014 10:26:52 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED1E1A0190 for ; Fri, 13 Jun 2014 10:26:52 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5DHQpGv007862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 13 Jun 2014 13:26:51 -0400
Received: from localhost.localdomain (vpn-53-247.rdu2.redhat.com [10.10.53.247]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5DHQo0G019692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 13 Jun 2014 13:26:51 -0400
Message-ID: <539B345A.7060808@redhat.com>
Date: Fri, 13 Jun 2014 12:26:50 -0500
From: Anil Saldhana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <539A0FB1.1020106@pingidentity.com> <13F2E738-49BB-4EDB-9070-5A49448A6249@ve7jtb.com>
In-Reply-To: <13F2E738-49BB-4EDB-9070-5A49448A6249@ve7jtb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6YSS_B0_axVrJV9vku-GpheesF4
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 17:26:57 -0000

On 06/12/2014 04:18 PM, John Bradley wrote:
> All but a handful of OAuth WG participants participated in developing OpenID Connect.
>
> Yes some companies chose not to participate for whatever reasons and have not committed to the mutual non assert IPR agreement, and that is unfortunate, but not a reason to start again from scratch.
>
> Changing the OIDF IPR policy of totally open specifications based on non asserts is also not a option.
>
> I have made comments on the current draft of a4c.
>
> I think a profile of Connect introducing a grant_type returning only an id_token would be simpler than trying to do this as a separate spec.
> I do note that you can do effectively the same thing now by using a code response_type and a scope of openID.   This doesn't result in any extra user consent other than consenting to login to the RP the first time (though that consent can be given in advance out of band in a enterprise scenario.
>
> When developing Connect we debated having a token endpoint response with only a id_token but decided that it was not in the spirit of being a OAuth 2 profile.   So we decided to return a access token even if the user info endpoint contains no claims other then sub.   People almost always want more claims as they roll out a real deployment.  It is easy to add them if you have designed to be able to talk to a RS.
> OAuth without a RS is a touch not OAuth.
>
> a4c also completely ignores modern development environments like node.js where the client is in the user agent, that OAuth 2 and Connect support.
>
> By the time the OAuth WG is done with a4c it will likely be a similar size as Connect if it addresses the same use cases.
>
> I still don't see the problem with having a deployment profile of Connect that can meet 100% of the current stated use case for a4c.
John - I am not fully familiar with the processes of OIDC.  How much of 
an effort is it to get the deployment profile of OIDC connect rolling?

>
> I expect that the people here involved in Connect will form there own opinions on comments regarding the number of participants and the quantity of the work and review.
>
> Regards
> John B.
>
>
>
>
> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt  wrote:
>
>> +1, after implementing OIDC I will support the claim that any SSO protocol with a minimal set of required features smaller than OIDC is insecure and any protocol with similar features but with different parameter names is just creating confusion and will increase chances of non-interoperable and insecure implementations
>>
>> Hans.
>>
>> On 6/12/14, 9:50 PM, Bill Burke wrote:
>>>
>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>>>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has
>>>> received review from maybe a dozen engineers within the OpenID community.
>>>>
>>> The OpenID Connect spec is 86 pages because it pretty much rehashes the
>>> OAuth2 spec walking through each flow and how Open ID Connect expands on
>>> that flow.  A4c looks like a subset of this work minus some additional
>>> claims and, IMO, is incomplete compared to OIDC.
>>>
>>> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We
>>> originally were creating our own oauth2 extension using JWT, but found
>>> that any feature we wanted to define already existed in OpenID Connect.
>>>   These guys have done great work.   Aren't many of you here authors of
>>> this spec and/or the same companies?!?  I think your energies are better
>>> focused on lobbying OIDC to join the IETF and this WG.
>>>
>>>
>>>


From nobody Fri Jun 13 10:32:38 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58F31A0645 for ; Fri, 13 Jun 2014 10:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ic9-g3MSenP1 for ; Fri, 13 Jun 2014 10:32:29 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B8FC1A0178 for ; Fri, 13 Jun 2014 10:32:29 -0700 (PDT)
Received: from BLUPR03CA030.namprd03.prod.outlook.com (10.141.30.23) by BLUPR03MB325.namprd03.prod.outlook.com (10.141.48.14) with Microsoft SMTP Server (TLS) id 15.0.969.15; Fri, 13 Jun 2014 17:32:20 +0000
Received: from BY2FFO11FD009.protection.gbl (2a01:111:f400:7c0c::158) by BLUPR03CA030.outlook.office365.com (2a01:111:e400:879::23) with Microsoft SMTP Server (TLS) id 15.0.959.15 via Frontend Transport; Fri, 13 Jun 2014 17:32:20 +0000
Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD009.mail.protection.outlook.com (10.1.14.73) with Microsoft SMTP Server (TLS) id 15.0.959.15 via Frontend Transport; Fri, 13 Jun 2014 17:32:19 +0000
Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.173]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Fri, 13 Jun 2014 17:31:43 +0000
From: Mike Jones 
To: Prateek Mishra , Bill Burke , Phil Hunt 
Thread-Topic: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
Thread-Index: AQHPgJJX++40qT3NTkqX94iwQ4eIlptiq6AAgAActfCAAB0AgIAABUcAgAo+PICAAFlvAIAAAZAAgAA3lQCAADKkgIAAB9WAgAFLCQCAAAW6AIAAAEtggAAIQYCAAAHk0A==
Date: Fri, 13 Jun 2014 17:31:42 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD6CBF3@TK5EX14MBXC292.redmond.corp.microsoft.com>
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com> <539B20DA.5010409@redhat.com> <539B25A8.4050404@oracle.com> <4E1F6AAD24975D4BA5B16804296739439AD6CA36@TK5EX14MBXC292.redmond.corp.microsoft.com> <539B2CD3.8090903@oracle.com>
In-Reply-To: <539B2CD3.8090903@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD6CBF3TK5EX14MBXC292r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438001)(377454003)(13464003)(51704005)(199002)(189002)(71186001)(50986999)(33656002)(46102001)(81542001)(55846006)(76176999)(104016001)(64706001)(54356999)(26826002)(81342001)(76482001)(20776003)(86612001)(69596002)(66066001)(15395725005)(16236675004)(86362001)(99396002)(79102001)(21056001)(74502001)(85852003)(6806004)(512954002)(83072002)(4396001)(92726001)(92566001)(44976005)(85806002)(19580395003)(83322001)(19580405001)(84326002)(84676001)(74662001)(77982001)(15975445006)(93886003)(80022001)(68736004)(19300405004)(2656002)(31966008)(87936001)(81156002)(15202345003)(19625215002)(97736001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB325; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0241D5F98C
Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; 
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/MVquBfFFpmxlY6EsqmZcxDCo8h8
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 17:32:34 -0000

--_000_4E1F6AAD24975D4BA5B16804296739439AD6CBF3TK5EX14MBXC292r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I just looked all the uses of REQUIRED and MUST in the OpenID Connect Core =
spec.  They do things like say which claims are REQUIRED in the ID Token ("=
iss", "sub", etc.), which OAuth parameters and features are REQUIRED, place=
 restrictions on certain values (such as "iss" MUST use the "https" scheme,=
 "sub" must not be longer than 255 characters, the redirect_uri MUST exactl=
y match a registered value, etc.), say that fields that are not understood =
MUST be ignored, and say when ID Tokens MUST be signed, and say that user i=
nteraction MUST NOT occur with prompt=3Dnone, and specify validation rules =
for some data structures (checking signatures, redirect_uris, etc.).

The key point is that none of the uses of REQUIRED or MUST require implemen=
tation of additional features, either by OPs or RPs.  They just place restr=
ictions on *how* they are to be implemented.  So, in fact, the lists in 15.=
1 and 15.2 *are* comprehensive sets of required features for the two classe=
s of identity providers.

I should have added in my earlier note that there's also a section on MTI f=
eatures for RPs:
    15.4.  Mand=
atory to Implement Features for Relying Parties
Essentially, it says that RPs only need to implement the features that they=
 actually plan to use.

Developers have shown in practice to have no problem understanding the Open=
ID Connect specs or building interoperable implementations.  20 implementat=
ions (see http://osis.idcommons.net/wiki/Category:OC5_Solution) are partici=
pating in the current (5th) round of interop testing and a number of others=
 also are privately.  The specs are clear to developers in part because we =
kept iterating, taking feedback, refining them, and doing new rounds of int=
erop testing until they were clear and easy to build.  There's four years o=
f implementation and deployment experience incorporated into the final spec=
ifications.

No, everyone won't build every optional feature.  That's a good thing - and=
 by design.  The specs are designed to let you build only the parts that yo=
u need for your use cases, while still being interoperable for the features=
 implemented.

Yes, the a4c spec adds a few things that OpenID Connect didn't - primarily =
the ability to authenticate over the back channel without issuing an ID Tok=
en by adding a new response_type, plus definitions of some claim values for=
 the "amr" claim.  There's nothing wrong with these additions.

However, arguments that "OpenID Connect is too complicated" fall short in f=
ace of the actual implementation and deployment experience and I don't thin=
k are helpful to the current discussions.  We should be positively discussi=
ng what features OAuth specs should have, rather than trying to criticize o=
ther valuable work that's already widely deployed.

                                                            Best wishes,
                                                            -- Mike

From: Prateek Mishra [mailto:prateek.mishra@oracle.com]
Sent: Friday, June 13, 2014 9:55 AM
To: Mike Jones; Bill Burke; Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

Mike -  when i see language like

[quote]
This list augments the set of features that are already listed elsewhere as=
 being "REQUIRED" or are described with a "MUST", and so is not, by itself,=
 a comprehensive set of implementation requirements for OPs.
[\quote]

in Section 15.1, I have to say this isn't a clear definition of what is MTI=
.

I guess someone could through comprehensive research determine exactly what=
 might be meant by this section, but that doesn't meet the criteria of "ver=
y clear definition of MTI".

- prateek

- prateek



Actually, there is a very clear definition of what the minimal Mandatory To=
 Implement (MTI) in OpenID Connect is - it's right in the spec.  See the (q=
uite short) sections:

    15.1.  =
Mandatory to Implement Features for All OpenID Providers
    15.2. =
 Mandatory to Implement Features for Dynamic OpenID Providers



                                                            -- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Prateek Mishra
Sent: Friday, June 13, 2014 9:24 AM
To: Bill Burke; Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c



Excellent, now you have put your finger on the precise issue with OIDC - lo=
ts of optional extensions and shiny trinkets and lack of a clear definition=
 of a core subset for servers.



I realize its exciting for consultants, software and toolkit vendors to hav=
e that sort of optionality, but in practice, its NOT A GOOD THING in a prot=
ocol.



[quote]

>

>> It is a bit like saying an 18 wheeler is suitable for driving the

>> kids to school. :-)

>

> I don't think this is true.  Most oidc oauth extensions are optional

> with the sole requirement that providers don't barf if you send them.

>

[\quote]



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


--_000_4E1F6AAD24975D4BA5B16804296739439AD6CBF3TK5EX14MBXC292r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I just looked all the =
uses of REQUIRED and MUST in the OpenID Connect Core spec.  They do th=
ings like say which claims are REQUIRED in the ID Token (“iss”,=
 “sub”, etc.), which OAuth parameters and features are
 REQUIRED, place restrictions on certain values (such as “iss” =
MUST use the “https” scheme, “sub” must not be long=
er than 255 characters, the redirect_uri MUST exactly match a registered va=
lue, etc.), say that fields that are not understood MUST be ignored,
 and say when ID Tokens MUST be signed, and say that user interaction MUST =
NOT occur with prompt=3Dnone, and specify validation rules for some data st=
ructures (checking signatures, redirect_uris, etc.).


 


The key point is that =
none of the uses of REQUIRED or MUST require implementation of additional f=
eatures, either by OPs or RPs.  They just place restrictions on *ho=
w* they are to be implemented.  So, in
 fact, the lists in 15.1 and 15.2 *are* comprehensive sets of requir=
ed features for the two classes of identity providers.

 


I should have added in=
 my earlier note that there’s also a section on MTI features for RPs:=



    15.4.  M=
andatory to Implement Features for Relying Parties


Essentially, it says t=
hat RPs only need to implement the features that they actually plan to use.=



 


Developers have shown =
in practice to have no problem understanding the OpenID Connect specs or bu=
ilding interoperable implementations.  20 implementations (see
http://osi=
s.idcommons.net/wiki/Category:OC5_Solution) are participating in the cu=
rrent (5th) round of interop testing and a number of others also=
 are privately.  The specs are clear
 to developers in part because we kept iterating, taking feedback, refining=
 them, and doing new rounds of interop testing until they were clear and ea=
sy to build.  There’s four years of implementation and deploymen=
t experience incorporated into the final specifications.<=
/p>

 


No, everyone won’=
;t build every optional feature.  That’s a good thing – an=
d by design.  The specs are designed to let you build only the parts t=
hat you need for your use cases, while still being interoperable
 for the features implemented.


 


Yes, the a4c spec adds=
 a few things that OpenID Connect didn’t – primarily the abilit=
y to authenticate over the back channel without issuing an ID Token by addi=
ng a new response_type, plus definitions of some
 claim values for the “amr” claim.  There’s nothing =
wrong with these additions.


 


However, arguments tha=
t “OpenID Connect is too complicated” fall short in face of the=
 actual implementation and deployment experience and I don’t think ar=
e helpful to the current discussions.  We should be positively
 discussing what features OAuth specs should have, rather than trying to cr=
iticize other valuable work that’s already widely deployed.


 


   &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;      Best wishes,


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


 






From: Prateek Mishra [mailto:prateek.mishra@oracle.com]


Sent: Friday, June 13, 2014 9:55 AM

To: Mike Jones; Bill Burke; Phil Hunt

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-=
a4c






 


Mike -  when i see language like 



[quote]

This list augments the set of features that are already listed elsewhere as=
 being "REQUIRED" or are described with a "MUST", and s=
o is not, by itself, a comprehensive set of implementation requirements for=
 OPs.


[\quote]



in Section 15.1, I have to say this isn't a clear definition of what is MTI=
. 



I guess someone could through comprehensive research determine exactly what=
 might be meant by this section, but that doesn't meet the criteria of &quo=
t;very clear definition of MTI".



- prateek



- prateek








Actually, there is a very clear definition of wha=
t the minimal Mandatory To Implement (MTI) in OpenID Connect is - it's righ=
t in the spec.  See the (quite short) sections:


    15.1.&=
nbsp; Mandatory to Implement Features for All OpenID Providers

    15.2.  Mandatory to Implement Feat=
ures for Dynamic OpenID Providers


 


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


-----Original Message-----

From: OAuth [mailto:oauth-bounces=
@ietf.org] On Behalf Of Prateek Mishra

Sent: Friday, June 13, 2014 9:24 AM

To: Bill Burke; Phil Hunt

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c


 


Excellent, now you have put your finger on the pr=
ecise issue with OIDC - lots of optional extensions and shiny trinkets and =
lack of a clear definition of a core subset for servers.


 


I realize its exciting for consultants, software =
and toolkit vendors to have that sort of optionality, but in practice, its =
NOT A GOOD THING in a protocol.


 


[quote]


> 


>> It is a bit like saying an 18 wheeler is=
 suitable for driving the



>> kids to school. :-)


> 


> I don't think this is true.  Most oidc =
oauth extensions are optional



> with the sole requirement that providers don=
't barf if you send them.


> 


[\quote]


 


_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ie=
tf.org/mailman/listinfo/oauth


 






--_000_4E1F6AAD24975D4BA5B16804296739439AD6CBF3TK5EX14MBXC292r_--


From nobody Fri Jun 13 11:49:14 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788E81B29E8 for ; Fri, 13 Jun 2014 11:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Igb0GB94jpED for ; Fri, 13 Jun 2014 11:49:12 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 463971A01FF for ; Fri, 13 Jun 2014 11:49:12 -0700 (PDT)
Received: (qmail 1799 invoked by uid 0); 14 Jun 2014 00:49:10 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 14 Jun 2014 00:49:10 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw3 with  id Dup31o00E2is6CS01up6wQ; Fri, 13 Jun 2014 12:49:10 -0600
X-Authority-Analysis: v=2.1 cv=XPOjF2RE c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=Qc7rbY0ofnkA:10 a=8dE94GJacnkA:10 a=kj9zAlcOel0A:10 a=UGkfVyPCAAAA:8 a=rE68L1KyjUoA:10 a=9qTtQ-wxW7wA:10 a=20KFwNOVAAAA:8 a=SfDgIUwNAAAA:8 a=2TOoWl9Jmp4QqR_2MkUA:9 a=CjuIK1q_8ugA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=0qEjrYlnuRwA:10 a=jEp0ucaQiEUA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=cAyPP2HpmDk2CYAJHcTBLukK1+9AY191Li7yIznKBxI=;  b=pLX0RUOzl4RyGsbPFchEdV8Pc8n+r8YQC7MASE0X5H3xDMUFquGNJkjYQfUZrDUEySwqon20aCvzs0r1e4HLF5tTP2C6DROvWxPsIYrXF/PoEQX8RKb80ElxoCm88N78;
Received: from [68.5.51.152] (port=49797 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WvWX9-0002pa-0A; Fri, 13 Jun 2014 12:49:03 -0600
From: "Donald F. Coffin" 
To: "'Bill Burke'" , "'Prateek Mishra'" , "'IETF oauth WG'" 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <539B1CED.9050404@oracle.com> <539B2515.90005@redhat.com>
In-Reply-To: <539B2515.90005@redhat.com>
Date: Fri, 13 Jun 2014 11:47:14 -0700
Organization: REMI Networks
Message-ID: <004701cf8737$e5d709e0$b1851da0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHfOakcWWHwPVPkubHt7r9DDnZmiACFqDe5AVq3u2wBHWwKUQJzc2WdAY3ekRYCu8iswQIWuIOKAc1U9U8CKkww5QJ3V6HOATF8pBCatGvJkA==
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.5.51.152 authed with donald.coffin@reminetworks.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/nkPbg8JggBtRgVhqUhBkuG1ve90
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 18:49:13 -0000

+1

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571
Email:       donald.coffin@reminetworks.com

-----Original Message-----
From: Bill Burke [mailto:bburke@redhat.com] 
Sent: Friday, June 13, 2014 9:22 AM
To: Prateek Mishra; IETF oauth WG
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c



On 6/13/2014 11:46 AM, Prateek Mishra wrote:
> Thanks, Bill - I certainly appreciate the comment from an implementor 
> who wasnt involved in the OIDC protocol design.
>
> My understanding of the discussion around a4c is one of a minimalist 
> extension to OAuth, not a full-featured one like OIDC.
> One concern I have heard expressed is that OIDC is so large and full 
> featured that most people just implement some subset of their own 
> choice. I believe this is the case with all the large consumer web 
> sites.
>
> I would welcome the publication of a minimalist draft from OIDC to the 
> OAuth IETF. We have spent a lot of time lobbying for this outcome! 
> There is no question in my mind that the review within IETF would be 
> more comprehensive and expose the work to a larger community.
>

I don't think a minimalist draft of OIDC is needed as many of the 
extensions are optional.   Our implementation was already Oauth2/JWT 
based and it was really easy to meet the minimal requirements of OIDC core.

To create competing standards at IETF just because OIDC is not part of IETF,
IMO, is a disservice to the community.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com




From nobody Fri Jun 13 11:50:05 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3C41B29ED for ; Fri, 13 Jun 2014 11:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nn8Oj0OdkBnR for ; Fri, 13 Jun 2014 11:50:02 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id C23E81A01FF for ; Fri, 13 Jun 2014 11:50:02 -0700 (PDT)
Received: (qmail 2488 invoked by uid 0); 13 Jun 2014 18:50:02 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy2.mail.unifiedlayer.com with SMTP; 13 Jun 2014 18:50:02 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw3 with  id Dupz1o00J2is6CS01uq2ty; Fri, 13 Jun 2014 12:50:02 -0600
X-Authority-Analysis: v=2.1 cv=XPOjF2RE c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=Qc7rbY0ofnkA:10 a=8dE94GJacnkA:10 a=kj9zAlcOel0A:10 a=UGkfVyPCAAAA:8 a=rE68L1KyjUoA:10 a=9qTtQ-wxW7wA:10 a=20KFwNOVAAAA:8 a=48vgC7mUAAAA:8 a=2TOoWl9Jmp4QqR_2MkUA:9 a=yYunwBTxqUhbYmrK:21 a=H2_HyqajTwDUjv4F:21 a=CjuIK1q_8ugA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=0qEjrYlnuRwA:10 a=jEp0ucaQiEUA:10 a=lZB815dzVvQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=SXnHv+oo0XJdYb2HicHxt6hxX4TEK9a7g37gvGVffC0=;  b=g3sZvdTMh6+K1hqDciWZsfPpd2f4lTcygLUZ8cus1Sl2Sw5KaRcHfppqMhtaGUdimVmR99jlhrGdPlZTg2hcO0lVc4QSZFKiaJ9l0EAS/GnNNE4MNZCsthEhQ8biRX5U;
Received: from [68.5.51.152] (port=49801 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WvWY3-0003Jv-AY; Fri, 13 Jun 2014 12:49:59 -0600
From: "Donald F. Coffin" 
To: "'Anil Saldhana'" , 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com> <539B20DA.5010409@redhat.com> <539B25A8.4050404@oracle.com> <539B265D.3020505@redhat.com>
In-Reply-To: <539B265D.3020505@redhat.com>
Date: Fri, 13 Jun 2014 11:48:10 -0700
Organization: REMI Networks
Message-ID: <004801cf8738$0768c9e0$163a5da0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHfOakcWWHwPVPkubHt7r9DDnZmiACFqDe5AVq3u2wBHWwKUQJzc2WdAY3ekRYCu8iswQIWuIOKAc1U9U8CKkww5QJIyqLvAkhefvYBMPrrhAIac+4cmpLN8fA=
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.5.51.152 authed with donald.coffin@reminetworks.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/xTPSRqRVssv1G9z5T7opAxhesp8
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 18:50:03 -0000

+1

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571
Email:       donald.coffin@reminetworks.com

-----Original Message-----
From: Anil Saldhana [mailto:Anil.Saldhana@redhat.com] 
Sent: Friday, June 13, 2014 9:27 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

For me it boils down to this:
OAuth deals with Authorization.

Authentication needs to be outside its realm - whether it is OIDC, SAML or
other protocols, it is fine.

The security community has just muddled up things for end users,
implementors and adopters.

We need to start having clear cut separation in the standards.

On 06/13/2014 11:24 AM, Prateek Mishra wrote:
> Excellent, now you have put your finger on the precise issue with OIDC
> - lots of optional extensions and shiny trinkets and lack of a clear 
> definition of a core subset for servers.
>
> I realize its exciting for consultants, software and toolkit vendors 
> to have that sort of optionality, but in practice, its NOT A GOOD 
> THING in a protocol.
>
> [quote]
>>
>>> It is a bit like saying an 18 wheeler is suitable for driving the 
>>> kids to school. :-)
>>
>> I don't think this is true.  Most oidc oauth extensions are optional 
>> with the sole requirement that providers don't barf if you send them.
>>
> [\quote]
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth




From nobody Fri Jun 13 12:10:26 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6601B2A07 for ; Fri, 13 Jun 2014 12:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmllKAjbmumT for ; Fri, 13 Jun 2014 12:10:22 -0700 (PDT)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DA71B27EF for ; Fri, 13 Jun 2014 12:10:21 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id j15so4283720qaq.12 for ; Fri, 13 Jun 2014 12:10:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=LEGvIpM4JZ462n/UYwE8VIaIN0mMv5OzQNNKPXvIozE=; b=R1iOpATIR8qRxB58TnTH2yCeAij59c1rjryPNqpZ5+05eGYKpQfxXGfIr2rj6wwAGM sC+wqwbepP+UMiHQKi4ME2lRugsaTkHToOgGAmjb7CTMVmoyij5caOY/YdUJ6q2MfIbd YMU9REXHAI1iBgNoDMz1jznBg0QXf94jwBlMS/n1HQQOt6qRUef/4p4IUy5m4pxPu3Od 3u+X1aBlpXkqEUziwJO9VVPfkaYMTPixVJGJT6Ma4M854SJqP0xvsYcIhpdj6p2OLzwY GDPxZa3Xm/uHJ0GxoOv61RMY6CJP3Yv728O8uf/ZTNpQexdY/OBD7vqogWsRU8YNTKg5 Kqbg==
X-Gm-Message-State: ALoCoQmGu0NP8wVD24out1wkZCDyo2a5/bNzrhQM1i1eAWPzh5h7NBzAWegp1qN09+AhrbvTz04a
X-Received: by 10.140.47.245 with SMTP id m108mr6403456qga.9.1402686620855; Fri, 13 Jun 2014 12:10:20 -0700 (PDT)
Received: from [192.168.0.200] ([201.189.40.105]) by mx.google.com with ESMTPSA id p95sm1597623qgd.23.2014.06.13.12.10.19 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 12:10:20 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: John Bradley 
In-Reply-To: <748D0DD4-F6FB-4EB8-94F4-86E79A448881@oracle.com>
Date: Fri, 13 Jun 2014 15:11:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com> <539B20DA.5010409@redhat.com> <748D0DD4-F6FB-4EB8-94F4-86E79A448881@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/APN-Nxf-gaopwB0xkhgUXwQSitk
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 19:10:25 -0000

Subsequent to this email Phil and I have talked.

There are two things that are deltas to connect in the spec.

One is the ability to issue only a id_token from the token endpoint.

The code grant_type requires a access token in the response.   If the WG =
wants to define a new grant type that doesn't return a access or refresh =
token that would be fine and it could be used with Connect as other =
grant types are.    The current use of a response_type in a4c to signal =
only returning a id_token and reusing the "code" grant type is a =
problem.
I think Mike J.  will be able to do an update with that shortly.

Phil is correct that Connect doesn't currently support that OAuth grant =
type because it has not been defined yet.  Not because you must provide =
claims at the token endpoint.

Connect supports the "id_token" and "none" response types nether of =
which provide access tokens.

For example a authn request with a scope of "openid" and a response_type =
of code will return a id_token and a access token for a user_info =
endpoint.   However the user_info endpoint will only only contain a =
claim for the "sub" that matches the "sub" in the id_token and not any =
photos of relatives, unless the IdP is horribly broken.

We need to balance returning a access token that may be discarded by the =
client that gives access to no PII vs adding a new grant_type.  =20
I think that would be a useful discussion that could feed back to =
Connect or a4c.

The other difference has to do with the use of authentication context =
and wanting to send a single value on a predefined scale vs an ordered =
list by preference.
This has been debated many times and many places.   The Connect approach =
recognizes that authentication contexts are not necessarily scalar. =20
In SAML we do have the constructs of better than etc.  I think these are =
implemented and used almost nowhere.  =20
The Liberty/Kantara conformance testing only ever tested exact match.    =
So Connect did something similar to the option that is used in SAML.
I don't know that adding another way to ask for authentication context =
is helping the world.

This is perhaps a useful discussion, also independent of the specs =
though it may want informing from people at OASIS/Kantara who are not =
normally part of OAuth discussions.

I remain concerned that if we do a small core authentication spec in the =
OAuth WG that may start being compatible with Connect that opens the =
door to extensions down the road that may not be as people inevitably =
discover that there is more to life than the code flow.

I prefer to profile down Connect and support a new response type if that =
is desired rather than adding eventual confusion and incompatibility.

The main question for the work group at this point is if we want to =
change our charter to include authentication.  =20
If we do then a4c and other authentication related drafts can come into =
the WG.

At this point a4c is a independent draft. =20

I am in favour of having a concise draft for basic identity providers, =
doing simple SSO.=20
Connect has a Basic Client profile for people developing clients/RP/SP =
as there tend to be more of them than IdP.
The same thing can be done in the Connect WG as a Basic IdP profile. =20

Going to far into debating the finer points of a4c is probably =
premature, until after a charter decision is reached.

Regards
John B.

On Jun 13, 2014, at 1:10 PM, Phil Hunt  wrote:

> I am going to address a few comments all together here:
>=20
> 1. John Bradley confirmed again yesterday, OIDC does not allow for =
authentication only as part of the normal code flow and decided =
intentionally not to address it.  So to say OIDC has a solution is =
confusing.
>=20
> OIDC has the solution if you want to propagate profile information and =
authen information.  This means service providers have to implement much =
more code, and clients have to as well. For many there are customer =
abandonment and legal issues around sharing of too much PII information. =
They DO NOT want to have to ask for this information.
>=20
> 2. Regarding speculative future size: I  point out that the A4C draft =
is modelled exactly on the authorizaiton flow and has exactly the same =
security model. Therefore I would not expect any large increase in size, =
but rather the opposite. The number 1 challenge with this spec is not =
figuring out how to do this, but how to avoid scope creep into OIDC=92s =
coverage.  I do NOT support scope creep into OIDC. =20
>=20
> We need a specific draft that addresses the issues of developers =
thinking 6749 is sufficient on its own.  I do NOT want to see stuff like =
browser based apps and node.js as in scope. OIDC has this covered.
>=20
> 3. My point with the 18 wheeler analogy is that yes, it is a vehicle =
that can take passengers, but it=92s role is much more multi-purpose and =
heavy duty. For the developer that wants to securely take the kids to =
school, maybe just a Tesla Model S will do? This is less of a technical =
issue and more of a =93market=94 issue. I know that=92s hard for people =
like us to address, but it is a comment I keep hearing over and over =
(and not interestingly from Oracle itself).
>=20
> 4. As for confusion between OAuth=92s intended authorization and a so =
called new authen function. This is the issue I=92m trying to get on our =
agenda. This isn=92t my idea, I am only the messenger. The fact is, =
developers and service providers who are not OAuth experts assume OAuth =
is about authentication and implement as such.  To some extent, this is  =
a market problem. Still, OIDC has not addressed the scenario. As John =
stated, OIDC choose not to do authen only. =20
>=20
> 5. As for whether we =93tack-on=94 authen to OAuth as OIDC does or =
whether we create a brand new endpoint or flow. I think that is open for =
discussion once the charter is adopted.  A4C is just an input draft - =
not the way the group needs to solve it.  A4C is intended to show the =
problem is solvable in a reasonably implementable manner.
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
> On Jun 13, 2014, at 9:03 AM, Bill Burke  wrote:
>=20
>>=20
>>=20
>> On 6/12/2014 4:18 PM, Phil Hunt wrote:
>>>=20
>>>=20
>>> Phil
>>>=20
>>>> On Jun 12, 2014, at 12:50, Bill Burke  wrote:
>>>>=20
>>>>=20
>>>>=20
>>>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>>>>> The OpenID Connect 2.0 COre specification alone is 86 pages. It =
has
>>>>> received review from maybe a dozen engineers within the OpenID =
community.
>>>>=20
>>>> The OpenID Connect spec is 86 pages because it pretty much rehashes =
the OAuth2 spec walking through each flow and how Open ID Connect =
expands on that flow.  A4c looks like a subset of this work minus some =
additional claims and, IMO, is incomplete compared to OIDC.
>>> In what regards?
>>>=20
>>> Much of oidc is out of scope for this requirement.
>>>=20
>>=20
>> What is in a4c that isn't already in OIDC?
>>=20
>>> It is a bit like saying an 18 wheeler is suitable for driving the =
kids to school. :-)
>>=20
>> I don't think this is true.  Most oidc oauth extensions are optional =
with the sole requirement that providers don't barf if you send them.
>>=20
>> --=20
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Fri Jun 13 12:14:02 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA0C1B29E8 for ; Fri, 13 Jun 2014 12:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMwrZON_n3A3 for ; Fri, 13 Jun 2014 12:13:56 -0700 (PDT)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127461A01FF for ; Fri, 13 Jun 2014 12:13:55 -0700 (PDT)
Received: by mail-lb0-f178.google.com with SMTP id 10so656195lbg.23 for ; Fri, 13 Jun 2014 12:13:54 -0700 (PDT)
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=tsxN34KBMj3tcJQFTRTgiKpKlVu6MjB1wLaM+ebo9tc=; b=VDHo8pnukppw377FOulnn8hrkLThnxTtCijQ8Cem5tJHdWDlZSxLP8fJFuUBjRnjea 4d7rTaSLhs7hmjLkBtbToSyDCrzKdmpeOHB4+Ldx9RryGseqycZP/zHr9vGViuMXeRHM FSRGTNB334IgySwfdGz/VvPF6YvmN0PQa7OyReSqKuemF5e3d3KOJb2zH630B8EyV369 R6pBqVi1dLf0idvXdUFTY/ocQ1zVz262uoZL8th52e+N6TIxstNOuo5KIeKpagmtL/A6 jGx6wSE2eZWW+iHALxg/mfXof9QlcupZXko9whut8cC8OVRTrqqpor4VQ+/3dDFaY0nJ dYwQ==
MIME-Version: 1.0
X-Received: by 10.152.242.164 with SMTP id wr4mr2837585lac.38.1402686834400; Fri, 13 Jun 2014 12:13:54 -0700 (PDT)
Received: by 10.112.33.36 with HTTP; Fri, 13 Jun 2014 12:13:54 -0700 (PDT)
In-Reply-To: <53996461.7080507@gmx.net>
References:  <53996461.7080507@gmx.net>
Date: Fri, 13 Jun 2014 15:13:54 -0400
Message-ID: 
From: Kathleen Moriarty 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a113409507ee3c904fbbc7a4f
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_yFYIgMc2BsGprbxYH5UVC6Nul0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 19:14:00 -0000

--001a113409507ee3c904fbbc7a4f
Content-Type: text/plain; charset=UTF-8

Hi Hannes,

Thank you for going through the various reviews, since the JOSE ones should
be of interest to Oauth.  I'll respond in-line.


On Thu, Jun 12, 2014 at 4:27 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Hi Kathleen,
>
> on the first item I have a few minor remarks: You wrote:
>
> "
> As I read through the Algorithms (JWA) draft there are some changes that
> will need to be made to avoid problems during the IESG review.  This is
> a pretty big change for the draft, but will help make the review and
> approval faster.  Typically, the lists of algorithms are handled through
> a draft update as opposed to creating an IANA registry.  A good example
> is a recent update of a draft in the IPSECME working group so you can
> see the structure and the precedence for this model.
> "
>
FYI - this is from the start of a long thread that has been worked out
already.  I had included a link to the JWA review only for the section on
the security consideratiosn section as many of the drafts in JOSE, and at
least one in OAuth start out with the same paragraph that could use some
updating and correcting.  I wanted to make sure this working group was
aware since JWT shares that same paragraph.  Mike is working through new
text and has solicited help from the WG (please respond on the JOSE list).

>
> The IANA registry for the algorithm serves a different purpose than a
> document recommending the specific algorithms. The reference to the
> IPSECME document only provides the latter. It is also important to note
> that the JWA not only defines the algorithm tags for the IANA registry
> but also explains how they actually work with the JOSE defined JSON
> structures (which is again a difference to the mentioned IPSECME document).
>
The discussion on having a registry versus a draft has been settled.  The
possibility of an issue came to me through an AD and after discussion, it
is fine as it is.  There were some considerations that needed to get
surfaced, so the document can remain as-is.  Sorry for the confusion.  I'll
file this away for the future reference.

>
> Of course, the JWA document does both via the IANA registry and there is
> the question about how these recommendations would then get updated and
> what the consensus process is.
>
> In an mail to the JOSE mailing list I argued against any MTI
> recommendations since JOSE is a baseline technology that will be used in
> a variety of different contexts and it is super likely that the
> algorithm requirements will hugely vary.
>
> I am just thinking about what algorithms I would recommend when using
> the JOSE work in an IoT environment. My recommendations would deviate
> from the currently given recommendations, which are largely impacted by
> the Web community.
>
> Here is the mail I sent to the JOSE list:
> http://www.ietf.org/mail-archive/web/jose/current/msg04032.html
>
> So, my recommendation is to
>
> 1) have no MTI requirements in the JWA spec
> 2) remove the 'JOSE Implementation Requirements' column from the IANA
> registry.
>

Interesting.   I do remember having these discussions with Sean and Richard
(see http://www.ietf.org/mail-archive/web/jose/current/msg04060.html).  In
Jim's opinion, (from:
http://www.ietf.org/mail-archive/web/jose/current/msg04062.html), his view
is that even the MTI in JWA can be overridden in the spec.  I wonder why
you would have an MTI then?

This closed out the discussion and it would be better to see it on the JOSE
list than here.  If the point is to get Oauth people who are encountering
conflicts as a user of JOSE drafts to chime in, that should happen on the
JOSE list.  I suspect this will be an issue for XMPP as well.  They are
phasing out SHA-1, so if that's MTI for fingerprints, they may still feel
like they have to support SHA-1 for that purpose even though their work
specifies that SHA-2 should be used everywhere.

Since JWA is getting closer to IESG review, I'll ask other ADs their
thoughts on how they like to see this sort of thing handled.  Both Richard
and Jim raised valid points.

Thank you,
Kathleen

>
> Ciao
> Hannes
>
>
> On 06/09/2014 06:17 PM, Kathleen Moriarty wrote:
> > Hello,
> >
> > I am in process of working through the JOSE drafts and also read the
> > Oauth JWT draft last week.  There is some overlap in text that may
> > require some joint work to correct.
> >
> > 1. For JWT, the Security Considerations section starts off with the same
> > text that is in several of the JOSE drafts.  In my review of the JWA
> > draft, I asked for some fixes that will need to be made to this draft as
> > well.  Here is a link to that review and it may be easier to help with
> > this work in one spot where text will be reused.  Mike has asked the
> > JOSE WG to assist, but it make make sense for Oauth folks to help as
> > well.  If it makes sense, a pointer to existing text is also fine.
> >
> > http://www.ietf.org/mail-archive/web/jose/current/msg04064.html
> >
> > 2. Sections 5.1 and 5.2 are a little confusing.  However, the use of
> > "typ" and "cty" appear in 3 drafts (at least), so this should get
> > addressed with an approach that considers the joint text to reduce
> > confusion for developers.  The initial descriptions are in the JOSE JWS
> > draft, so that may need most of the work, but it also appears in this
> > draft and the JOSE JWK draft.  In my writeup for the JWK review, I
> > listed out some questions and would like to see improvements across
> > these drafts.  This will likely require some joint work and may be best
> > in response to the JWK review to keep it in one place.
> >
> > http://www.ietf.org/mail-archive/web/jose/current/msg04172.html
> >
> > Thank you!
> >
> > --
> >
> > Best regards,
> > Kathleen
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>


-- 

Best regards,
Kathleen

--001a113409507ee3c904fbbc7a4f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Hannes,

Thank you for going through =
the various reviews, since the JOSE ones should be of interest to Oauth. =
=C2=A0I'll respond in-line.



On Thu, Jun 12, 2014 at 4:27 AM, Hannes Tschofenig <hannes.tschofe=
nig@gmx.net> wrote:

Hi Kathleen,



on the first item I have a few minor remarks: You wrote:



"

As I read through the Algorithms (JWA) draft there are some changes that
will need to be made to avoid problems during the IESG review. =C2=A0This i=
s

a pretty big change for the draft, but will help make the review and

approval faster. =C2=A0Typically, the lists of algorithms are handled throu=
gh

a draft update as opposed to creating an IANA registry. =C2=A0A good exampl=
e

is a recent update of a draft in the IPSECME working group so you can

see the structure and the precedence for this model.

"
FYI - this is from the start of a long thread t=
hat has been worked out already. =C2=A0I had included a link to the JWA rev=
iew only for the section on the security consideratiosn section as many of =
the drafts in JOSE, and at least one in OAuth start out with the same parag=
raph that could use some updating and correcting. =C2=A0I wanted to make su=
re this working group was aware since JWT shares that same paragraph. =C2=
=A0Mike is working through new text and has solicited help from the WG (ple=
ase respond on the JOSE list).=C2=A0





The IANA registry for the algorithm serves a different purpose than a

document recommending the specific algorithms. The reference to the

IPSECME document only provides the latter. It is also important to note

that the JWA not only defines the algorithm tags for the IANA registry

but also explains how they actually work with the JOSE defined JSON

structures (which is again a difference to the mentioned IPSECME document).=

The discussion on having a registry versus a draft ha=
s been settled. =C2=A0The possibility of an issue came to me through an AD =
and after discussion, it is fine as it is. =C2=A0There were some considerat=
ions that needed to get surfaced, so the document can remain as-is. =C2=A0S=
orry for the confusion. =C2=A0I'll file this away for the future refere=
nce.=C2=A0





Of course, the JWA document does both via the IANA registry and there is
the question about how these recommendations would then get updated and

what the consensus process is.



In an mail to the JOSE mailing list I argued against any MTI

recommendations since JOSE is a baseline technology that will be used in
a variety of different contexts and it is super likely that the

algorithm requirements will hugely vary.



I am just thinking about what algorithms I would recommend when using

the JOSE work in an IoT environment. My recommendations would deviate

from the currently given recommendations, which are largely impacted by

the Web community.



Here is the mail I sent to the JOSE list:

http://www.ietf.org/mail-archive/web/jose/current/msg040=
32.html



So, my recommendation is to



1) have no MTI requirements in the JWA spec

2) remove the 'JOSE Implementation Requirements' column from the IA=
NA

registry.
=C2=A0
Interesting. =C2=A0 I do re=
member having these discussions with Sean and Richard (see=C2=A0http://www=
.ietf.org/mail-archive/web/jose/current/msg04060.html). =C2=A0In Jim=
9;s opinion, (from: http://www.ietf.org/mail-archive/web/jose/current/msg0=
4062.html), his view is that even the MTI in JWA can be overridden in t=
he spec. =C2=A0I wonder why you would have an MTI then?



This closed out the discussion and it would be better t=
o see it on the JOSE list than here. =C2=A0If the point is to get Oauth peo=
ple who are encountering conflicts as a user of JOSE drafts to chime in, th=
at should happen on the JOSE list. =C2=A0I suspect this will be an issue fo=
r XMPP as well. =C2=A0They are phasing out SHA-1, so if that's MTI for =
fingerprints, they may still feel like they have to support SHA-1 for that =
purpose even though their work specifies that SHA-2 should be used everywhe=
re.



Since JWA is getting closer to IESG review, I'll as=
k other ADs their thoughts on how they like to see this sort of thing handl=
ed. =C2=A0Both Richard and Jim raised valid points.


Thank you,
Kathleen =C2=A0



Ciao

Hannes






On 06/09/2014 06:17 PM, Kathleen Moriarty wrote:

> Hello,

>

> I am in process of working through the JOSE drafts and also read the
> Oauth JWT draft last week. =C2=A0There is some overlap in text that ma=
y

> require some joint work to correct.

>

> 1. For JWT, the Security Considerations section starts off with the sa=
me

> text that is in several of the JOSE drafts. =C2=A0In my review of the =
JWA

> draft, I asked for some fixes that will need to be made to this draft =
as

> well. =C2=A0Here is a link to that review and it may be easier to help=
 with

> this work in one spot where text will be reused. =C2=A0Mike has asked =
the

> JOSE WG to assist, but it make make sense for Oauth folks to help as
> well. =C2=A0If it makes sense, a pointer to existing text is also fine=
.

>

> http://www.ietf.org/mail-archive/web/jose/current/m=
sg04064.html

>

> 2. Sections 5.1 and 5.2 are a little confusing. =C2=A0However, the use=
 of

> "typ" and "cty" appear in 3 drafts (at least), so =
this should get

> addressed with an approach that considers the joint text to reduce

> confusion for developers. =C2=A0The initial descriptions are in the JO=
SE JWS

> draft, so that may need most of the work, but it also appears in this<=
br>
> draft and the JOSE JWK draft. =C2=A0In my writeup for the JWK review, =
I

> listed out some questions and would like to see improvements across
> these drafts. =C2=A0This will likely require some joint work and may b=
e best

> in response to the JWK review to keep it in one place.

>

> http://www.ietf.org/mail-archive/web/jose/current/m=
sg04172.html

>

> Thank you!

>

> --

>

> Best regards,

> Kathleen

>

>


> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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

>







-- 

Best regards,
Kathleen




--001a113409507ee3c904fbbc7a4f--


From nobody Fri Jun 13 12:27:41 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B461B29F9 for ; Fri, 13 Jun 2014 12:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phIPTQHaWx_N for ; Fri, 13 Jun 2014 12:27:33 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237311B2855 for ; Fri, 13 Jun 2014 12:27:33 -0700 (PDT)
Received: from BY2PR03CA028.namprd03.prod.outlook.com (10.242.234.149) by CY1PR0301MB0634.namprd03.prod.outlook.com (25.160.158.140) with Microsoft SMTP Server (TLS) id 15.0.959.24; Fri, 13 Jun 2014 19:27:30 +0000
Received: from BN1AFFO11FD026.protection.gbl (2a01:111:f400:7c10::107) by BY2PR03CA028.outlook.office365.com (2a01:111:e400:2c2c::21) with Microsoft SMTP Server (TLS) id 15.0.959.24 via Frontend Transport; Fri, 13 Jun 2014 19:27:30 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD026.mail.protection.outlook.com (10.58.52.86) with Microsoft SMTP Server (TLS) id 15.0.959.15 via Frontend Transport; Fri, 13 Jun 2014 19:27:29 +0000
Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.173]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0195.002; Fri, 13 Jun 2014 19:26:49 +0000
From: Mike Jones 
To: Kathleen Moriarty , Hannes Tschofenig 
Thread-Topic: [OAUTH-WG] JWT review
Thread-Index: AQHPg/5gzu/A4NjdfECJ7UyyP64X2JttKDuAgAJHBACAAACncA==
Date: Fri, 13 Jun 2014 19:26:49 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD6D0D8@TK5EX14MBXC292.redmond.corp.microsoft.com>
References:  <53996461.7080507@gmx.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD6D0D8TK5EX14MBXC292r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438001)(24454002)(60444003)(479174003)(189002)(199002)(377454003)(69234005)(51704005)(55846006)(86612001)(19300405004)(92566001)(76482001)(86362001)(15202345003)(4396001)(64706001)(44976005)(74662001)(99396002)(74502001)(33656002)(19580395003)(6806004)(19580405001)(20776003)(83322001)(68736004)(69596002)(16236675004)(66066001)(104016001)(92726001)(80022001)(77982001)(79102001)(76176999)(15975445006)(54356999)(97736001)(87936001)(81156002)(31966008)(46102001)(71186001)(16297215004)(85806002)(512874002)(2656002)(26826002)(21056001)(85852003)(83072002)(84676001)(81542001)(81342001)(19625215002)(50986999)(84326002); DIR:OUT; SFP:; SCL:1; SRVR:CY1PR0301MB0634; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0241D5F98C
Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; 
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ZSSm-s8bZiOya9rKi_THb8OuD5U
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] JWT review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 19:27:38 -0000

--_000_4E1F6AAD24975D4BA5B16804296739439AD6D0D8TK5EX14MBXC292r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SW4gbm8gcGxhY2UgaXMgU0hBLTEgb3IgYWxnb3JpdGhtcyB1c2luZyBpdCBNVEkuICBZb3UgY2Fu
IHNlZSB0aGUgc2V0IG9mIE1USSBhbGdvcml0aG1zIGJ5IGxvb2tpbmcgYXQgdGhvc2UgbWFya2Vk
IOKAnFJlcXVpcmVk4oCdIGluIHRoZSByZWdpc3RyaWVzLg0KDQpBIHNtYWxsIHNldCBvZiByZXF1
aXJlZCBhbGdvcml0aG1zIGlzIHByZXNlbnQsIHdpdGggdGhlIGNob2ljZXMgYmFzZWQgb24gYSBk
ZXRhaWxlZCBzdXJ2ZXkgb2Ygd2hhdCBhbGdvcml0aG1zIGFyZSB3aWRlbHkgZGVwbG95ZWQsIHRv
IHByb3ZpZGUgYSBiYXNpcyBmb3IgaW1wbGVtZW50YXRpb25zIHRvIGludGVyb3BlcmF0ZS4gIFJl
Y29nbml6aW5nIHRoYXQgdGhlIHNldCBvZiBhbGdvcml0aG1zIHRoYXQgd2lsbCBiZSBhcHByb3By
aWF0ZSB0byBoYXZlIGFzIHJlcXVpcmVkIHdpbGwgY2hhbmdlIG92ZXIgdGltZSwgU2VhbiBUdXJu
ZXIgc3VnZ2VzdGVkIHRoYXQgd2UgZW5hYmxlIGZ1dHVyZSBkcmFmdHMgdG8gdXBkYXRlIHRoZSBJ
bXBsZW1lbnRhdGlvbiBSZXF1aXJlbWVudHMgaW4gdGhlIHJlZ2lzdHJpZXMsIHdpdGggZXhwZXJ0
IHJldmlldy4gIChTbyBmb3IgaW5zdGFuY2UsIGFuIGFsZ29yaXRobSB0aGF0IG1pZ2h0IGJlIOKA
nFJlcXVpcmVk4oCdIHRvZGF5IGNvdWxkIGJlIG1hcmtlZCDigJxEZXByZWNhdGVk4oCdIGluIHRo
ZSBmdXR1cmUuKSAgV2UgYWRvcHRlZCBTZWFu4oCZcyBzdWdnZXN0aW9uIGEgZ29vZCB3aGlsZSBh
Z28uDQoNClRoaXMgaXMgYW5vdGhlciBhcmVhIHRoYXQgd2FzIHdpZGVseSBkaXNjdXNzZWQgd2l0
aGluIHRoZSBKT1NFIHdvcmtpbmcgZ3JvdXAsIGFuZCB0aGVyZSB3YXMgbmV2ZXIgY29uc2Vuc3Vz
IHRvIHJlbW92ZSB0aGUgaW1wbGVtZW50YXRpb24gcmVxdWlyZW1lbnRzLCB3aGljaCBoYXZlIGFs
d2F5cyBiZWVuIHByZXNlbnQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpv
YXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2F0aGxlZW4gTW9yaWFydHkNClNl
bnQ6IEZyaWRheSwgSnVuZSAxMywgMjAxNCAxMjoxNCBQTQ0KVG86IEhhbm5lcyBUc2Nob2Zlbmln
DQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEpXVCByZXZpZXcN
Cg0KSGkgSGFubmVzLA0KDQpUaGFuayB5b3UgZm9yIGdvaW5nIHRocm91Z2ggdGhlIHZhcmlvdXMg
cmV2aWV3cywgc2luY2UgdGhlIEpPU0Ugb25lcyBzaG91bGQgYmUgb2YgaW50ZXJlc3QgdG8gT2F1
dGguICBJJ2xsIHJlc3BvbmQgaW4tbGluZS4NCg0KT24gVGh1LCBKdW4gMTIsIDIwMTQgYXQgNDoy
NyBBTSwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRv
Omhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+PiB3cm90ZToNCkhpIEthdGhsZWVuLA0KDQpvbiB0
aGUgZmlyc3QgaXRlbSBJIGhhdmUgYSBmZXcgbWlub3IgcmVtYXJrczogWW91IHdyb3RlOg0KDQoi
DQpBcyBJIHJlYWQgdGhyb3VnaCB0aGUgQWxnb3JpdGhtcyAoSldBKSBkcmFmdCB0aGVyZSBhcmUg
c29tZSBjaGFuZ2VzIHRoYXQNCndpbGwgbmVlZCB0byBiZSBtYWRlIHRvIGF2b2lkIHByb2JsZW1z
IGR1cmluZyB0aGUgSUVTRyByZXZpZXcuICBUaGlzIGlzDQphIHByZXR0eSBiaWcgY2hhbmdlIGZv
ciB0aGUgZHJhZnQsIGJ1dCB3aWxsIGhlbHAgbWFrZSB0aGUgcmV2aWV3IGFuZA0KYXBwcm92YWwg
ZmFzdGVyLiAgVHlwaWNhbGx5LCB0aGUgbGlzdHMgb2YgYWxnb3JpdGhtcyBhcmUgaGFuZGxlZCB0
aHJvdWdoDQphIGRyYWZ0IHVwZGF0ZSBhcyBvcHBvc2VkIHRvIGNyZWF0aW5nIGFuIElBTkEgcmVn
aXN0cnkuICBBIGdvb2QgZXhhbXBsZQ0KaXMgYSByZWNlbnQgdXBkYXRlIG9mIGEgZHJhZnQgaW4g
dGhlIElQU0VDTUUgd29ya2luZyBncm91cCBzbyB5b3UgY2FuDQpzZWUgdGhlIHN0cnVjdHVyZSBh
bmQgdGhlIHByZWNlZGVuY2UgZm9yIHRoaXMgbW9kZWwuDQoiDQpGWUkgLSB0aGlzIGlzIGZyb20g
dGhlIHN0YXJ0IG9mIGEgbG9uZyB0aHJlYWQgdGhhdCBoYXMgYmVlbiB3b3JrZWQgb3V0IGFscmVh
ZHkuICBJIGhhZCBpbmNsdWRlZCBhIGxpbmsgdG8gdGhlIEpXQSByZXZpZXcgb25seSBmb3IgdGhl
IHNlY3Rpb24gb24gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb3NuIHNlY3Rpb24gYXMgbWFueSBv
ZiB0aGUgZHJhZnRzIGluIEpPU0UsIGFuZCBhdCBsZWFzdCBvbmUgaW4gT0F1dGggc3RhcnQgb3V0
IHdpdGggdGhlIHNhbWUgcGFyYWdyYXBoIHRoYXQgY291bGQgdXNlIHNvbWUgdXBkYXRpbmcgYW5k
IGNvcnJlY3RpbmcuICBJIHdhbnRlZCB0byBtYWtlIHN1cmUgdGhpcyB3b3JraW5nIGdyb3VwIHdh
cyBhd2FyZSBzaW5jZSBKV1Qgc2hhcmVzIHRoYXQgc2FtZSBwYXJhZ3JhcGguICBNaWtlIGlzIHdv
cmtpbmcgdGhyb3VnaCBuZXcgdGV4dCBhbmQgaGFzIHNvbGljaXRlZCBoZWxwIGZyb20gdGhlIFdH
IChwbGVhc2UgcmVzcG9uZCBvbiB0aGUgSk9TRSBsaXN0KS4NCg0KVGhlIElBTkEgcmVnaXN0cnkg
Zm9yIHRoZSBhbGdvcml0aG0gc2VydmVzIGEgZGlmZmVyZW50IHB1cnBvc2UgdGhhbiBhDQpkb2N1
bWVudCByZWNvbW1lbmRpbmcgdGhlIHNwZWNpZmljIGFsZ29yaXRobXMuIFRoZSByZWZlcmVuY2Ug
dG8gdGhlDQpJUFNFQ01FIGRvY3VtZW50IG9ubHkgcHJvdmlkZXMgdGhlIGxhdHRlci4gSXQgaXMg
YWxzbyBpbXBvcnRhbnQgdG8gbm90ZQ0KdGhhdCB0aGUgSldBIG5vdCBvbmx5IGRlZmluZXMgdGhl
IGFsZ29yaXRobSB0YWdzIGZvciB0aGUgSUFOQSByZWdpc3RyeQ0KYnV0IGFsc28gZXhwbGFpbnMg
aG93IHRoZXkgYWN0dWFsbHkgd29yayB3aXRoIHRoZSBKT1NFIGRlZmluZWQgSlNPTg0Kc3RydWN0
dXJlcyAod2hpY2ggaXMgYWdhaW4gYSBkaWZmZXJlbmNlIHRvIHRoZSBtZW50aW9uZWQgSVBTRUNN
RSBkb2N1bWVudCkuDQpUaGUgZGlzY3Vzc2lvbiBvbiBoYXZpbmcgYSByZWdpc3RyeSB2ZXJzdXMg
YSBkcmFmdCBoYXMgYmVlbiBzZXR0bGVkLiAgVGhlIHBvc3NpYmlsaXR5IG9mIGFuIGlzc3VlIGNh
bWUgdG8gbWUgdGhyb3VnaCBhbiBBRCBhbmQgYWZ0ZXIgZGlzY3Vzc2lvbiwgaXQgaXMgZmluZSBh
cyBpdCBpcy4gIFRoZXJlIHdlcmUgc29tZSBjb25zaWRlcmF0aW9ucyB0aGF0IG5lZWRlZCB0byBn
ZXQgc3VyZmFjZWQsIHNvIHRoZSBkb2N1bWVudCBjYW4gcmVtYWluIGFzLWlzLiAgU29ycnkgZm9y
IHRoZSBjb25mdXNpb24uICBJJ2xsIGZpbGUgdGhpcyBhd2F5IGZvciB0aGUgZnV0dXJlIHJlZmVy
ZW5jZS4NCg0KT2YgY291cnNlLCB0aGUgSldBIGRvY3VtZW50IGRvZXMgYm90aCB2aWEgdGhlIElB
TkEgcmVnaXN0cnkgYW5kIHRoZXJlIGlzDQp0aGUgcXVlc3Rpb24gYWJvdXQgaG93IHRoZXNlIHJl
Y29tbWVuZGF0aW9ucyB3b3VsZCB0aGVuIGdldCB1cGRhdGVkIGFuZA0Kd2hhdCB0aGUgY29uc2Vu
c3VzIHByb2Nlc3MgaXMuDQoNCkluIGFuIG1haWwgdG8gdGhlIEpPU0UgbWFpbGluZyBsaXN0IEkg
YXJndWVkIGFnYWluc3QgYW55IE1USQ0KcmVjb21tZW5kYXRpb25zIHNpbmNlIEpPU0UgaXMgYSBi
YXNlbGluZSB0ZWNobm9sb2d5IHRoYXQgd2lsbCBiZSB1c2VkIGluDQphIHZhcmlldHkgb2YgZGlm
ZmVyZW50IGNvbnRleHRzIGFuZCBpdCBpcyBzdXBlciBsaWtlbHkgdGhhdCB0aGUNCmFsZ29yaXRo
bSByZXF1aXJlbWVudHMgd2lsbCBodWdlbHkgdmFyeS4NCg0KSSBhbSBqdXN0IHRoaW5raW5nIGFi
b3V0IHdoYXQgYWxnb3JpdGhtcyBJIHdvdWxkIHJlY29tbWVuZCB3aGVuIHVzaW5nDQp0aGUgSk9T
RSB3b3JrIGluIGFuIElvVCBlbnZpcm9ubWVudC4gTXkgcmVjb21tZW5kYXRpb25zIHdvdWxkIGRl
dmlhdGUNCmZyb20gdGhlIGN1cnJlbnRseSBnaXZlbiByZWNvbW1lbmRhdGlvbnMsIHdoaWNoIGFy
ZSBsYXJnZWx5IGltcGFjdGVkIGJ5DQp0aGUgV2ViIGNvbW11bml0eS4NCg0KSGVyZSBpcyB0aGUg
bWFpbCBJIHNlbnQgdG8gdGhlIEpPU0UgbGlzdDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h
cmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQwMzIuaHRtbA0KDQpTbywgbXkgcmVjb21tZW5k
YXRpb24gaXMgdG8NCg0KMSkgaGF2ZSBubyBNVEkgcmVxdWlyZW1lbnRzIGluIHRoZSBKV0Egc3Bl
Yw0KMikgcmVtb3ZlIHRoZSAnSk9TRSBJbXBsZW1lbnRhdGlvbiBSZXF1aXJlbWVudHMnIGNvbHVt
biBmcm9tIHRoZSBJQU5BDQpyZWdpc3RyeS4NCg0KSW50ZXJlc3RpbmcuICAgSSBkbyByZW1lbWJl
ciBoYXZpbmcgdGhlc2UgZGlzY3Vzc2lvbnMgd2l0aCBTZWFuIGFuZCBSaWNoYXJkIChzZWUgaHR0
cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwNDA2MC5o
dG1sKS4gIEluIEppbSdzIG9waW5pb24sIChmcm9tOiBodHRwOi8vd3d3LmlldGYub3JnL21haWwt
YXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzA0MDYyLmh0bWwpLCBoaXMgdmlldyBpcyB0aGF0
IGV2ZW4gdGhlIE1USSBpbiBKV0EgY2FuIGJlIG92ZXJyaWRkZW4gaW4gdGhlIHNwZWMuICBJIHdv
bmRlciB3aHkgeW91IHdvdWxkIGhhdmUgYW4gTVRJIHRoZW4/DQoNClRoaXMgY2xvc2VkIG91dCB0
aGUgZGlzY3Vzc2lvbiBhbmQgaXQgd291bGQgYmUgYmV0dGVyIHRvIHNlZSBpdCBvbiB0aGUgSk9T
RSBsaXN0IHRoYW4gaGVyZS4gIElmIHRoZSBwb2ludCBpcyB0byBnZXQgT2F1dGggcGVvcGxlIHdo
byBhcmUgZW5jb3VudGVyaW5nIGNvbmZsaWN0cyBhcyBhIHVzZXIgb2YgSk9TRSBkcmFmdHMgdG8g
Y2hpbWUgaW4sIHRoYXQgc2hvdWxkIGhhcHBlbiBvbiB0aGUgSk9TRSBsaXN0LiAgSSBzdXNwZWN0
IHRoaXMgd2lsbCBiZSBhbiBpc3N1ZSBmb3IgWE1QUCBhcyB3ZWxsLiAgVGhleSBhcmUgcGhhc2lu
ZyBvdXQgU0hBLTEsIHNvIGlmIHRoYXQncyBNVEkgZm9yIGZpbmdlcnByaW50cywgdGhleSBtYXkg
c3RpbGwgZmVlbCBsaWtlIHRoZXkgaGF2ZSB0byBzdXBwb3J0IFNIQS0xIGZvciB0aGF0IHB1cnBv
c2UgZXZlbiB0aG91Z2ggdGhlaXIgd29yayBzcGVjaWZpZXMgdGhhdCBTSEEtMiBzaG91bGQgYmUg
dXNlZCBldmVyeXdoZXJlLg0KDQpTaW5jZSBKV0EgaXMgZ2V0dGluZyBjbG9zZXIgdG8gSUVTRyBy
ZXZpZXcsIEknbGwgYXNrIG90aGVyIEFEcyB0aGVpciB0aG91Z2h0cyBvbiBob3cgdGhleSBsaWtl
IHRvIHNlZSB0aGlzIHNvcnQgb2YgdGhpbmcgaGFuZGxlZC4gIEJvdGggUmljaGFyZCBhbmQgSmlt
IHJhaXNlZCB2YWxpZCBwb2ludHMuDQoNClRoYW5rIHlvdSwNCkthdGhsZWVuDQoNCkNpYW8NCkhh
bm5lcw0KDQoNCk9uIDA2LzA5LzIwMTQgMDY6MTcgUE0sIEthdGhsZWVuIE1vcmlhcnR5IHdyb3Rl
Og0KPiBIZWxsbywNCj4NCj4gSSBhbSBpbiBwcm9jZXNzIG9mIHdvcmtpbmcgdGhyb3VnaCB0aGUg
Sk9TRSBkcmFmdHMgYW5kIGFsc28gcmVhZCB0aGUNCj4gT2F1dGggSldUIGRyYWZ0IGxhc3Qgd2Vl
ay4gIFRoZXJlIGlzIHNvbWUgb3ZlcmxhcCBpbiB0ZXh0IHRoYXQgbWF5DQo+IHJlcXVpcmUgc29t
ZSBqb2ludCB3b3JrIHRvIGNvcnJlY3QuDQo+DQo+IDEuIEZvciBKV1QsIHRoZSBTZWN1cml0eSBD
b25zaWRlcmF0aW9ucyBzZWN0aW9uIHN0YXJ0cyBvZmYgd2l0aCB0aGUgc2FtZQ0KPiB0ZXh0IHRo
YXQgaXMgaW4gc2V2ZXJhbCBvZiB0aGUgSk9TRSBkcmFmdHMuICBJbiBteSByZXZpZXcgb2YgdGhl
IEpXQQ0KPiBkcmFmdCwgSSBhc2tlZCBmb3Igc29tZSBmaXhlcyB0aGF0IHdpbGwgbmVlZCB0byBi
ZSBtYWRlIHRvIHRoaXMgZHJhZnQgYXMNCj4gd2VsbC4gIEhlcmUgaXMgYSBsaW5rIHRvIHRoYXQg
cmV2aWV3IGFuZCBpdCBtYXkgYmUgZWFzaWVyIHRvIGhlbHAgd2l0aA0KPiB0aGlzIHdvcmsgaW4g
b25lIHNwb3Qgd2hlcmUgdGV4dCB3aWxsIGJlIHJldXNlZC4gIE1pa2UgaGFzIGFza2VkIHRoZQ0K
PiBKT1NFIFdHIHRvIGFzc2lzdCwgYnV0IGl0IG1ha2UgbWFrZSBzZW5zZSBmb3IgT2F1dGggZm9s
a3MgdG8gaGVscCBhcw0KPiB3ZWxsLiAgSWYgaXQgbWFrZXMgc2Vuc2UsIGEgcG9pbnRlciB0byBl
eGlzdGluZyB0ZXh0IGlzIGFsc28gZmluZS4NCj4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls
LWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwNDA2NC5odG1sDQo+DQo+IDIuIFNlY3Rpb25z
IDUuMSBhbmQgNS4yIGFyZSBhIGxpdHRsZSBjb25mdXNpbmcuICBIb3dldmVyLCB0aGUgdXNlIG9m
DQo+ICJ0eXAiIGFuZCAiY3R5IiBhcHBlYXIgaW4gMyBkcmFmdHMgKGF0IGxlYXN0KSwgc28gdGhp
cyBzaG91bGQgZ2V0DQo+IGFkZHJlc3NlZCB3aXRoIGFuIGFwcHJvYWNoIHRoYXQgY29uc2lkZXJz
IHRoZSBqb2ludCB0ZXh0IHRvIHJlZHVjZQ0KPiBjb25mdXNpb24gZm9yIGRldmVsb3BlcnMuICBU
aGUgaW5pdGlhbCBkZXNjcmlwdGlvbnMgYXJlIGluIHRoZSBKT1NFIEpXUw0KPiBkcmFmdCwgc28g
dGhhdCBtYXkgbmVlZCBtb3N0IG9mIHRoZSB3b3JrLCBidXQgaXQgYWxzbyBhcHBlYXJzIGluIHRo
aXMNCj4gZHJhZnQgYW5kIHRoZSBKT1NFIEpXSyBkcmFmdC4gIEluIG15IHdyaXRldXAgZm9yIHRo
ZSBKV0sgcmV2aWV3LCBJDQo+IGxpc3RlZCBvdXQgc29tZSBxdWVzdGlvbnMgYW5kIHdvdWxkIGxp
a2UgdG8gc2VlIGltcHJvdmVtZW50cyBhY3Jvc3MNCj4gdGhlc2UgZHJhZnRzLiAgVGhpcyB3aWxs
IGxpa2VseSByZXF1aXJlIHNvbWUgam9pbnQgd29yayBhbmQgbWF5IGJlIGJlc3QNCj4gaW4gcmVz
cG9uc2UgdG8gdGhlIEpXSyByZXZpZXcgdG8ga2VlcCBpdCBpbiBvbmUgcGxhY2UuDQo+DQo+IGh0
dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQxNzIu
aHRtbA0KPg0KPiBUaGFuayB5b3UhDQo+DQo+IC0tDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gS2F0
aGxlZW4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0
aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aA0KPg0KDQoNCg0KLS0NCg0KQmVzdCByZWdhcmRzLA0KS2F0aGxlZW4NCg==

--_000_4E1F6AAD24975D4BA5B16804296739439AD6D0D8TK5EX14MBXC292r_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gbm8gcGxhY2UgaXMg
U0hBLTEgb3IgYWxnb3JpdGhtcyB1c2luZyBpdCBNVEkuJm5ic3A7IFlvdSBjYW4gc2VlIHRoZSBz
ZXQgb2YgTVRJIGFsZ29yaXRobXMgYnkgbG9va2luZyBhdCB0aG9zZSBtYXJrZWQg4oCcUmVxdWly
ZWTigJ0gaW4gdGhlIHJlZ2lzdHJpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BIHNtYWxsIHNldCBvZiByZXF1aXJl
ZCBhbGdvcml0aG1zIGlzIHByZXNlbnQsIHdpdGggdGhlIGNob2ljZXMgYmFzZWQgb24gYSBkZXRh
aWxlZCBzdXJ2ZXkgb2Ygd2hhdCBhbGdvcml0aG1zIGFyZSB3aWRlbHkgZGVwbG95ZWQsIHRvIHBy
b3ZpZGUgYSBiYXNpcyBmb3IgaW1wbGVtZW50YXRpb25zDQogdG8gaW50ZXJvcGVyYXRlLiZuYnNw
OyBSZWNvZ25pemluZyB0aGF0IHRoZSBzZXQgb2YgYWxnb3JpdGhtcyB0aGF0IHdpbGwgYmUgYXBw
cm9wcmlhdGUgdG8gaGF2ZSBhcyByZXF1aXJlZCB3aWxsIGNoYW5nZSBvdmVyIHRpbWUsIFNlYW4g
VHVybmVyIHN1Z2dlc3RlZCB0aGF0IHdlIGVuYWJsZSBmdXR1cmUgZHJhZnRzIHRvIHVwZGF0ZSB0
aGUgSW1wbGVtZW50YXRpb24gUmVxdWlyZW1lbnRzIGluIHRoZSByZWdpc3RyaWVzLCB3aXRoIGV4
cGVydCByZXZpZXcuJm5ic3A7DQogKFNvIGZvciBpbnN0YW5jZSwgYW4gYWxnb3JpdGhtIHRoYXQg
bWlnaHQgYmUg4oCcUmVxdWlyZWTigJ0gdG9kYXkgY291bGQgYmUgbWFya2VkIOKAnERlcHJlY2F0
ZWTigJ0gaW4gdGhlIGZ1dHVyZS4pJm5ic3A7IFdlIGFkb3B0ZWQgU2VhbuKAmXMgc3VnZ2VzdGlv
biBhIGdvb2Qgd2hpbGUgYWdvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBhbm90aGVyIGFyZWEgdGhhdCB3
YXMgd2lkZWx5IGRpc2N1c3NlZCB3aXRoaW4gdGhlIEpPU0Ugd29ya2luZyBncm91cCwgYW5kIHRo
ZXJlIHdhcyBuZXZlciBjb25zZW5zdXMgdG8gcmVtb3ZlIHRoZSBpbXBsZW1lbnRhdGlvbiByZXF1
aXJlbWVudHMsIHdoaWNoDQogaGF2ZSBhbHdheXMgYmVlbiBwcmVzZW50LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP
ZiA8L2I+S2F0aGxlZW4gTW9yaWFydHk8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdW5lIDEz
LCAyMDE0IDEyOjE0IFBNPGJyPg0KPGI+VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZzxicj4NCjxi
PkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X
R10gSldUIHJldmlldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEhh
bm5lcyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r
IHlvdSBmb3IgZ29pbmcgdGhyb3VnaCB0aGUgdmFyaW91cyByZXZpZXdzLCBzaW5jZSB0aGUgSk9T
RSBvbmVzIHNob3VsZCBiZSBvZiBpbnRlcmVzdCB0byBPYXV0aC4gJm5ic3A7SSdsbCByZXNwb25k
IGluLWxpbmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1biAxMiwgMjAxNCBhdCA0OjI3IEFNLCBIYW5u
ZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5u
ZXQiIHRhcmdldD0iX2JsYW5rIj5oYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBLYXRobGVlbiw8YnI+
DQo8YnI+DQpvbiB0aGUgZmlyc3QgaXRlbSBJIGhhdmUgYSBmZXcgbWlub3IgcmVtYXJrczogWW91
IHdyb3RlOjxicj4NCjxicj4NCiZxdW90Ozxicj4NCkFzIEkgcmVhZCB0aHJvdWdoIHRoZSBBbGdv
cml0aG1zIChKV0EpIGRyYWZ0IHRoZXJlIGFyZSBzb21lIGNoYW5nZXMgdGhhdDxicj4NCndpbGwg
bmVlZCB0byBiZSBtYWRlIHRvIGF2b2lkIHByb2JsZW1zIGR1cmluZyB0aGUgSUVTRyByZXZpZXcu
ICZuYnNwO1RoaXMgaXM8YnI+DQphIHByZXR0eSBiaWcgY2hhbmdlIGZvciB0aGUgZHJhZnQsIGJ1
dCB3aWxsIGhlbHAgbWFrZSB0aGUgcmV2aWV3IGFuZDxicj4NCmFwcHJvdmFsIGZhc3Rlci4gJm5i
c3A7VHlwaWNhbGx5LCB0aGUgbGlzdHMgb2YgYWxnb3JpdGhtcyBhcmUgaGFuZGxlZCB0aHJvdWdo
PGJyPg0KYSBkcmFmdCB1cGRhdGUgYXMgb3Bwb3NlZCB0byBjcmVhdGluZyBhbiBJQU5BIHJlZ2lz
dHJ5LiAmbmJzcDtBIGdvb2QgZXhhbXBsZTxicj4NCmlzIGEgcmVjZW50IHVwZGF0ZSBvZiBhIGRy
YWZ0IGluIHRoZSBJUFNFQ01FIHdvcmtpbmcgZ3JvdXAgc28geW91IGNhbjxicj4NCnNlZSB0aGUg
c3RydWN0dXJlIGFuZCB0aGUgcHJlY2VkZW5jZSBmb3IgdGhpcyBtb2RlbC48YnI+DQomcXVvdDs8
bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GWUkgLSB0aGlzIGlz
IGZyb20gdGhlIHN0YXJ0IG9mIGEgbG9uZyB0aHJlYWQgdGhhdCBoYXMgYmVlbiB3b3JrZWQgb3V0
IGFscmVhZHkuICZuYnNwO0kgaGFkIGluY2x1ZGVkIGEgbGluayB0byB0aGUgSldBIHJldmlldyBv
bmx5IGZvciB0aGUgc2VjdGlvbiBvbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvc24gc2VjdGlv
biBhcyBtYW55IG9mIHRoZSBkcmFmdHMgaW4gSk9TRSwgYW5kIGF0IGxlYXN0IG9uZSBpbiBPQXV0
aA0KIHN0YXJ0IG91dCB3aXRoIHRoZSBzYW1lIHBhcmFncmFwaCB0aGF0IGNvdWxkIHVzZSBzb21l
IHVwZGF0aW5nIGFuZCBjb3JyZWN0aW5nLiAmbmJzcDtJIHdhbnRlZCB0byBtYWtlIHN1cmUgdGhp
cyB3b3JraW5nIGdyb3VwIHdhcyBhd2FyZSBzaW5jZSBKV1Qgc2hhcmVzIHRoYXQgc2FtZSBwYXJh
Z3JhcGguICZuYnNwO01pa2UgaXMgd29ya2luZyB0aHJvdWdoIG5ldyB0ZXh0IGFuZCBoYXMgc29s
aWNpdGVkIGhlbHAgZnJvbSB0aGUgV0cgKHBsZWFzZSByZXNwb25kIG9uDQogdGhlIEpPU0UgbGlz
dCkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YnI+DQpUaGUgSUFOQSByZWdpc3RyeSBmb3IgdGhlIGFsZ29yaXRobSBzZXJ2
ZXMgYSBkaWZmZXJlbnQgcHVycG9zZSB0aGFuIGE8YnI+DQpkb2N1bWVudCByZWNvbW1lbmRpbmcg
dGhlIHNwZWNpZmljIGFsZ29yaXRobXMuIFRoZSByZWZlcmVuY2UgdG8gdGhlPGJyPg0KSVBTRUNN
RSBkb2N1bWVudCBvbmx5IHByb3ZpZGVzIHRoZSBsYXR0ZXIuIEl0IGlzIGFsc28gaW1wb3J0YW50
IHRvIG5vdGU8YnI+DQp0aGF0IHRoZSBKV0Egbm90IG9ubHkgZGVmaW5lcyB0aGUgYWxnb3JpdGht
IHRhZ3MgZm9yIHRoZSBJQU5BIHJlZ2lzdHJ5PGJyPg0KYnV0IGFsc28gZXhwbGFpbnMgaG93IHRo
ZXkgYWN0dWFsbHkgd29yayB3aXRoIHRoZSBKT1NFIGRlZmluZWQgSlNPTjxicj4NCnN0cnVjdHVy
ZXMgKHdoaWNoIGlzIGFnYWluIGEgZGlmZmVyZW5jZSB0byB0aGUgbWVudGlvbmVkIElQU0VDTUUg
ZG9jdW1lbnQpLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlRoZSBkaXNjdXNzaW9uIG9uIGhhdmluZyBhIHJlZ2lzdHJ5IHZlcnN1cyBh
IGRyYWZ0IGhhcyBiZWVuIHNldHRsZWQuICZuYnNwO1RoZSBwb3NzaWJpbGl0eSBvZiBhbiBpc3N1
ZSBjYW1lIHRvIG1lIHRocm91Z2ggYW4gQUQgYW5kIGFmdGVyIGRpc2N1c3Npb24sIGl0IGlzIGZp
bmUgYXMgaXQgaXMuICZuYnNwO1RoZXJlIHdlcmUgc29tZSBjb25zaWRlcmF0aW9ucyB0aGF0IG5l
ZWRlZCB0byBnZXQgc3VyZmFjZWQsIHNvIHRoZSBkb2N1bWVudA0KIGNhbiByZW1haW4gYXMtaXMu
ICZuYnNwO1NvcnJ5IGZvciB0aGUgY29uZnVzaW9uLiAmbmJzcDtJJ2xsIGZpbGUgdGhpcyBhd2F5
IGZvciB0aGUgZnV0dXJlIHJlZmVyZW5jZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg
MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t
cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9mIGNvdXJzZSwgdGhlIEpX
QSBkb2N1bWVudCBkb2VzIGJvdGggdmlhIHRoZSBJQU5BIHJlZ2lzdHJ5IGFuZCB0aGVyZSBpczxi
cj4NCnRoZSBxdWVzdGlvbiBhYm91dCBob3cgdGhlc2UgcmVjb21tZW5kYXRpb25zIHdvdWxkIHRo
ZW4gZ2V0IHVwZGF0ZWQgYW5kPGJyPg0Kd2hhdCB0aGUgY29uc2Vuc3VzIHByb2Nlc3MgaXMuPGJy
Pg0KPGJyPg0KSW4gYW4gbWFpbCB0byB0aGUgSk9TRSBtYWlsaW5nIGxpc3QgSSBhcmd1ZWQgYWdh
aW5zdCBhbnkgTVRJPGJyPg0KcmVjb21tZW5kYXRpb25zIHNpbmNlIEpPU0UgaXMgYSBiYXNlbGlu
ZSB0ZWNobm9sb2d5IHRoYXQgd2lsbCBiZSB1c2VkIGluPGJyPg0KYSB2YXJpZXR5IG9mIGRpZmZl
cmVudCBjb250ZXh0cyBhbmQgaXQgaXMgc3VwZXIgbGlrZWx5IHRoYXQgdGhlPGJyPg0KYWxnb3Jp
dGhtIHJlcXVpcmVtZW50cyB3aWxsIGh1Z2VseSB2YXJ5Ljxicj4NCjxicj4NCkkgYW0ganVzdCB0
aGlua2luZyBhYm91dCB3aGF0IGFsZ29yaXRobXMgSSB3b3VsZCByZWNvbW1lbmQgd2hlbiB1c2lu
Zzxicj4NCnRoZSBKT1NFIHdvcmsgaW4gYW4gSW9UIGVudmlyb25tZW50LiBNeSByZWNvbW1lbmRh
dGlvbnMgd291bGQgZGV2aWF0ZTxicj4NCmZyb20gdGhlIGN1cnJlbnRseSBnaXZlbiByZWNvbW1l
bmRhdGlvbnMsIHdoaWNoIGFyZSBsYXJnZWx5IGltcGFjdGVkIGJ5PGJyPg0KdGhlIFdlYiBjb21t
dW5pdHkuPGJyPg0KPGJyPg0KSGVyZSBpcyB0aGUgbWFpbCBJIHNlbnQgdG8gdGhlIEpPU0UgbGlz
dDo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvam9z
ZS9jdXJyZW50L21zZzA0MDMyLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYu
b3JnL21haWwtYXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzA0MDMyLmh0bWw8L2E+PGJyPg0K
PGJyPg0KU28sIG15IHJlY29tbWVuZGF0aW9uIGlzIHRvPGJyPg0KPGJyPg0KMSkgaGF2ZSBubyBN
VEkgcmVxdWlyZW1lbnRzIGluIHRoZSBKV0Egc3BlYzxicj4NCjIpIHJlbW92ZSB0aGUgJ0pPU0Ug
SW1wbGVtZW50YXRpb24gUmVxdWlyZW1lbnRzJyBjb2x1bW4gZnJvbSB0aGUgSUFOQTxicj4NCnJl
Z2lzdHJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SW50ZXJlc3RpbmcuICZuYnNwOyBJIGRvIHJlbWVtYmVyIGhhdmluZyB0aGVz
ZSBkaXNjdXNzaW9ucyB3aXRoIFNlYW4gYW5kIFJpY2hhcmQgKHNlZSZuYnNwOzxhIGhyZWY9Imh0
dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQwNjAu
aHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9t
c2cwNDA2MC5odG1sPC9hPikuICZuYnNwO0luIEppbSdzIG9waW5pb24sDQogKGZyb206IDxhIGhy
ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNn
MDQwNjIuaHRtbCI+DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvam9zZS9j
dXJyZW50L21zZzA0MDYyLmh0bWw8L2E+KSwgaGlzIHZpZXcgaXMgdGhhdCBldmVuIHRoZSBNVEkg
aW4gSldBIGNhbiBiZSBvdmVycmlkZGVuIGluIHRoZSBzcGVjLiAmbmJzcDtJIHdvbmRlciB3aHkg
eW91IHdvdWxkIGhhdmUgYW4gTVRJIHRoZW4/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgY2xvc2VkIG91dCB0aGUgZGlzY3Vzc2lvbiBh
bmQgaXQgd291bGQgYmUgYmV0dGVyIHRvIHNlZSBpdCBvbiB0aGUgSk9TRSBsaXN0IHRoYW4gaGVy
ZS4gJm5ic3A7SWYgdGhlIHBvaW50IGlzIHRvIGdldCBPYXV0aCBwZW9wbGUgd2hvIGFyZSBlbmNv
dW50ZXJpbmcgY29uZmxpY3RzIGFzIGEgdXNlciBvZiBKT1NFIGRyYWZ0cyB0byBjaGltZSBpbiwg
dGhhdCBzaG91bGQgaGFwcGVuIG9uIHRoZSBKT1NFIGxpc3QuICZuYnNwO0kNCiBzdXNwZWN0IHRo
aXMgd2lsbCBiZSBhbiBpc3N1ZSBmb3IgWE1QUCBhcyB3ZWxsLiAmbmJzcDtUaGV5IGFyZSBwaGFz
aW5nIG91dCBTSEEtMSwgc28gaWYgdGhhdCdzIE1USSBmb3IgZmluZ2VycHJpbnRzLCB0aGV5IG1h
eSBzdGlsbCBmZWVsIGxpa2UgdGhleSBoYXZlIHRvIHN1cHBvcnQgU0hBLTEgZm9yIHRoYXQgcHVy
cG9zZSBldmVuIHRob3VnaCB0aGVpciB3b3JrIHNwZWNpZmllcyB0aGF0IFNIQS0yIHNob3VsZCBi
ZSB1c2VkIGV2ZXJ5d2hlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlNpbmNlIEpXQSBpcyBnZXR0aW5nIGNsb3NlciB0byBJRVNHIHJldmll
dywgSSdsbCBhc2sgb3RoZXIgQURzIHRoZWlyIHRob3VnaHRzIG9uIGhvdyB0aGV5IGxpa2UgdG8g
c2VlIHRoaXMgc29ydCBvZiB0aGluZyBoYW5kbGVkLiAmbmJzcDtCb3RoIFJpY2hhcmQgYW5kIEpp
bSByYWlzZWQgdmFsaWQgcG9pbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LYXRobGVlbiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw
dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkNpYW88YnI+
DQpIYW5uZXM8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGJyPg0KPGJyPg0KT24gMDYvMDkvMjAxNCAwNjoxNyBQTSwgS2F0aGxlZW4gTW9yaWFydHkg
d3JvdGU6PGJyPg0KJmd0OyBIZWxsbyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGFtIGluIHByb2Nl
c3Mgb2Ygd29ya2luZyB0aHJvdWdoIHRoZSBKT1NFIGRyYWZ0cyBhbmQgYWxzbyByZWFkIHRoZTxi
cj4NCiZndDsgT2F1dGggSldUIGRyYWZ0IGxhc3Qgd2Vlay4gJm5ic3A7VGhlcmUgaXMgc29tZSBv
dmVybGFwIGluIHRleHQgdGhhdCBtYXk8YnI+DQomZ3Q7IHJlcXVpcmUgc29tZSBqb2ludCB3b3Jr
IHRvIGNvcnJlY3QuPGJyPg0KJmd0Ozxicj4NCiZndDsgMS4gRm9yIEpXVCwgdGhlIFNlY3VyaXR5
IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gc3RhcnRzIG9mZiB3aXRoIHRoZSBzYW1lPGJyPg0KJmd0
OyB0ZXh0IHRoYXQgaXMgaW4gc2V2ZXJhbCBvZiB0aGUgSk9TRSBkcmFmdHMuICZuYnNwO0luIG15
IHJldmlldyBvZiB0aGUgSldBPGJyPg0KJmd0OyBkcmFmdCwgSSBhc2tlZCBmb3Igc29tZSBmaXhl
cyB0aGF0IHdpbGwgbmVlZCB0byBiZSBtYWRlIHRvIHRoaXMgZHJhZnQgYXM8YnI+DQomZ3Q7IHdl
bGwuICZuYnNwO0hlcmUgaXMgYSBsaW5rIHRvIHRoYXQgcmV2aWV3IGFuZCBpdCBtYXkgYmUgZWFz
aWVyIHRvIGhlbHAgd2l0aDxicj4NCiZndDsgdGhpcyB3b3JrIGluIG9uZSBzcG90IHdoZXJlIHRl
eHQgd2lsbCBiZSByZXVzZWQuICZuYnNwO01pa2UgaGFzIGFza2VkIHRoZTxicj4NCiZndDsgSk9T
RSBXRyB0byBhc3Npc3QsIGJ1dCBpdCBtYWtlIG1ha2Ugc2Vuc2UgZm9yIE9hdXRoIGZvbGtzIHRv
IGhlbHAgYXM8YnI+DQomZ3Q7IHdlbGwuICZuYnNwO0lmIGl0IG1ha2VzIHNlbnNlLCBhIHBvaW50
ZXIgdG8gZXhpc3RpbmcgdGV4dCBpcyBhbHNvIGZpbmUuPGJyPg0KJmd0Ozxicj4NCiZndDsgPGEg
aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9t
c2cwNDA2NC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwt
YXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzA0MDY0Lmh0bWw8L2E+PGJyPg0KJmd0Ozxicj4N
CiZndDsgMi4gU2VjdGlvbnMgNS4xIGFuZCA1LjIgYXJlIGEgbGl0dGxlIGNvbmZ1c2luZy4gJm5i
c3A7SG93ZXZlciwgdGhlIHVzZSBvZjxicj4NCiZndDsgJnF1b3Q7dHlwJnF1b3Q7IGFuZCAmcXVv
dDtjdHkmcXVvdDsgYXBwZWFyIGluIDMgZHJhZnRzIChhdCBsZWFzdCksIHNvIHRoaXMgc2hvdWxk
IGdldDxicj4NCiZndDsgYWRkcmVzc2VkIHdpdGggYW4gYXBwcm9hY2ggdGhhdCBjb25zaWRlcnMg
dGhlIGpvaW50IHRleHQgdG8gcmVkdWNlPGJyPg0KJmd0OyBjb25mdXNpb24gZm9yIGRldmVsb3Bl
cnMuICZuYnNwO1RoZSBpbml0aWFsIGRlc2NyaXB0aW9ucyBhcmUgaW4gdGhlIEpPU0UgSldTPGJy
Pg0KJmd0OyBkcmFmdCwgc28gdGhhdCBtYXkgbmVlZCBtb3N0IG9mIHRoZSB3b3JrLCBidXQgaXQg
YWxzbyBhcHBlYXJzIGluIHRoaXM8YnI+DQomZ3Q7IGRyYWZ0IGFuZCB0aGUgSk9TRSBKV0sgZHJh
ZnQuICZuYnNwO0luIG15IHdyaXRldXAgZm9yIHRoZSBKV0sgcmV2aWV3LCBJPGJyPg0KJmd0OyBs
aXN0ZWQgb3V0IHNvbWUgcXVlc3Rpb25zIGFuZCB3b3VsZCBsaWtlIHRvIHNlZSBpbXByb3ZlbWVu
dHMgYWNyb3NzPGJyPg0KJmd0OyB0aGVzZSBkcmFmdHMuICZuYnNwO1RoaXMgd2lsbCBsaWtlbHkg
cmVxdWlyZSBzb21lIGpvaW50IHdvcmsgYW5kIG1heSBiZSBiZXN0PGJyPg0KJmd0OyBpbiByZXNw
b25zZSB0byB0aGUgSldLIHJldmlldyB0byBrZWVwIGl0IGluIG9uZSBwbGFjZS48YnI+DQomZ3Q7
PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv
am9zZS9jdXJyZW50L21zZzA0MTcyLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cu
aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQxNzIuaHRtbDwvYT48
YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFuayB5b3UhPGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+
DQomZ3Q7PGJyPg0KJmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyBLYXRobGVlbjxicj4NCiZn
dDs8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5n
IGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0
Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxs
Ij4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LYXRobGVlbjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
b2R5Pg0KPC9odG1sPg0K

--_000_4E1F6AAD24975D4BA5B16804296739439AD6D0D8TK5EX14MBXC292r_--


From nobody Fri Jun 13 12:33:25 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE06E1B2A08 for ; Fri, 13 Jun 2014 12:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icKi7kLVbCor for ; Fri, 13 Jun 2014 12:33:21 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFC21B29EC for ; Fri, 13 Jun 2014 12:33:20 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id n15so1798383lbi.19 for ; Fri, 13 Jun 2014 12:33:19 -0700 (PDT)
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=SQ6KZ9EGWYlxD9KL251TttCg9IqX7kvlTpnm4H4Q2jw=; b=bRd9x3HL42eaG+LeWUyh3+WKvcGJiMwg58AIrEVZwRZ9YSUIdqOToL34xtgB3JxDeZ J14DhqO4MG2slgQPpsey77f9BD0V/xe2emws4BzCPcbU9NNeywRHrxQOqCd6ztY48RZO z2UgEfZE3SkXPmvJasR5PH3m+NwuOvvifGWx5kzMUnP5XF2EPLN+++z5oD4wh8dtDkcw g4qIicH4195UGa0cph4/37go1ycqFtcT7B8L9lJti9K5E3tsIFGoIN3RB2JbfQ9Qt/Zr YOFmQSLgxL5qyqVx+BFn9Z2HmoAWSo8vHMNuvOBjor5/m/qDrFJqASDz1HiojAi2qurs 9cHw==
MIME-Version: 1.0
X-Received: by 10.112.13.137 with SMTP id h9mr2752529lbc.33.1402687998816; Fri, 13 Jun 2014 12:33:18 -0700 (PDT)
Received: by 10.112.33.36 with HTTP; Fri, 13 Jun 2014 12:33:18 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD6D0D8@TK5EX14MBXC292.redmond.corp.microsoft.com>
References:  <53996461.7080507@gmx.net>  <4E1F6AAD24975D4BA5B16804296739439AD6D0D8@TK5EX14MBXC292.redmond.corp.microsoft.com>
Date: Fri, 13 Jun 2014 15:33:18 -0400
Message-ID: 
From: Kathleen Moriarty 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=001a11c3d10ae6763c04fbbcbf69
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uZEv9XkjfFlzeNGRf7yY_OZ-MVg
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] JWT review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 19:33:24 -0000

--001a11c3d10ae6763c04fbbcbf69
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks, Mike.

Okay, SHA-1 was a bad example.  Hannes asked in response to my earlier
review as he felt this was not resolved.  I read back through the most
recent thread and do see the responses you and Jim provided, also
referenced in my response as valid considerations.  If possible, it would
be great to get this settled sooner rather than later as well as for me to
figure out if either approach will cause heartburn in the IESG review
process.  I'll proactively dig into that so we can avoid issues later.
 They may or may not care either way.  It would be good for me to know this
for this particular issue as well as possible future issues that are
similar so I can help catch them earlier.

Is there a ticket on this from previous discussions to the ones started in
April?

Thanks!


On Fri, Jun 13, 2014 at 3:26 PM, Mike Jones 
wrote:

>  In no place is SHA-1 or algorithms using it MTI.  You can see the set of
> MTI algorithms by looking at those marked =E2=80=9CRequired=E2=80=9D in t=
he registries.
>
>
>
> A small set of required algorithms is present, with the choices based on =
a
> detailed survey of what algorithms are widely deployed, to provide a basi=
s
> for implementations to interoperate.  Recognizing that the set of
> algorithms that will be appropriate to have as required will change over
> time, Sean Turner suggested that we enable future drafts to update the
> Implementation Requirements in the registries, with expert review.  (So f=
or
> instance, an algorithm that might be =E2=80=9CRequired=E2=80=9D today cou=
ld be marked
> =E2=80=9CDeprecated=E2=80=9D in the future.)  We adopted Sean=E2=80=99s s=
uggestion a good while ago.
>
>
>
> This is another area that was widely discussed within the JOSE working
> group, and there was never consensus to remove the implementation
> requirements, which have always been present.
>
>
>
>                                                             -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Kathleen
> Moriarty
> *Sent:* Friday, June 13, 2014 12:14 PM
> *To:* Hannes Tschofenig
> *Cc:* oauth@ietf.org
>
> *Subject:* Re: [OAUTH-WG] JWT review
>
>
>
> Hi Hannes,
>
>
>
> Thank you for going through the various reviews, since the JOSE ones
> should be of interest to Oauth.  I'll respond in-line.
>
>
>
> On Thu, Jun 12, 2014 at 4:27 AM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
>
> Hi Kathleen,
>
> on the first item I have a few minor remarks: You wrote:
>
> "
> As I read through the Algorithms (JWA) draft there are some changes that
> will need to be made to avoid problems during the IESG review.  This is
> a pretty big change for the draft, but will help make the review and
> approval faster.  Typically, the lists of algorithms are handled through
> a draft update as opposed to creating an IANA registry.  A good example
> is a recent update of a draft in the IPSECME working group so you can
> see the structure and the precedence for this model.
> "
>
> FYI - this is from the start of a long thread that has been worked out
> already.  I had included a link to the JWA review only for the section on
> the security consideratiosn section as many of the drafts in JOSE, and at
> least one in OAuth start out with the same paragraph that could use some
> updating and correcting.  I wanted to make sure this working group was
> aware since JWT shares that same paragraph.  Mike is working through new
> text and has solicited help from the WG (please respond on the JOSE list)=
.
>
>
> The IANA registry for the algorithm serves a different purpose than a
> document recommending the specific algorithms. The reference to the
> IPSECME document only provides the latter. It is also important to note
> that the JWA not only defines the algorithm tags for the IANA registry
> but also explains how they actually work with the JOSE defined JSON
> structures (which is again a difference to the mentioned IPSECME document=
).
>
>  The discussion on having a registry versus a draft has been settled.
>  The possibility of an issue came to me through an AD and after discussio=
n,
> it is fine as it is.  There were some considerations that needed to get
> surfaced, so the document can remain as-is.  Sorry for the confusion.  I'=
ll
> file this away for the future reference.
>
>
> Of course, the JWA document does both via the IANA registry and there is
> the question about how these recommendations would then get updated and
> what the consensus process is.
>
> In an mail to the JOSE mailing list I argued against any MTI
> recommendations since JOSE is a baseline technology that will be used in
> a variety of different contexts and it is super likely that the
> algorithm requirements will hugely vary.
>
> I am just thinking about what algorithms I would recommend when using
> the JOSE work in an IoT environment. My recommendations would deviate
> from the currently given recommendations, which are largely impacted by
> the Web community.
>
> Here is the mail I sent to the JOSE list:
> http://www.ietf.org/mail-archive/web/jose/current/msg04032.html
>
> So, my recommendation is to
>
> 1) have no MTI requirements in the JWA spec
> 2) remove the 'JOSE Implementation Requirements' column from the IANA
> registry.
>
>
>
> Interesting.   I do remember having these discussions with Sean and
> Richard (see
> http://www.ietf.org/mail-archive/web/jose/current/msg04060.html).  In
> Jim's opinion, (from:
> http://www.ietf.org/mail-archive/web/jose/current/msg04062.html), his
> view is that even the MTI in JWA can be overridden in the spec.  I wonder
> why you would have an MTI then?
>
>
>
> This closed out the discussion and it would be better to see it on the
> JOSE list than here.  If the point is to get Oauth people who are
> encountering conflicts as a user of JOSE drafts to chime in, that should
> happen on the JOSE list.  I suspect this will be an issue for XMPP as wel=
l.
>  They are phasing out SHA-1, so if that's MTI for fingerprints, they may
> still feel like they have to support SHA-1 for that purpose even though
> their work specifies that SHA-2 should be used everywhere.
>
>
>
> Since JWA is getting closer to IESG review, I'll ask other ADs their
> thoughts on how they like to see this sort of thing handled.  Both Richar=
d
> and Jim raised valid points.
>
>
>
> Thank you,
>
> Kathleen
>
>
> Ciao
> Hannes
>
>
>
> On 06/09/2014 06:17 PM, Kathleen Moriarty wrote:
> > Hello,
> >
> > I am in process of working through the JOSE drafts and also read the
> > Oauth JWT draft last week.  There is some overlap in text that may
> > require some joint work to correct.
> >
> > 1. For JWT, the Security Considerations section starts off with the sam=
e
> > text that is in several of the JOSE drafts.  In my review of the JWA
> > draft, I asked for some fixes that will need to be made to this draft a=
s
> > well.  Here is a link to that review and it may be easier to help with
> > this work in one spot where text will be reused.  Mike has asked the
> > JOSE WG to assist, but it make make sense for Oauth folks to help as
> > well.  If it makes sense, a pointer to existing text is also fine.
> >
> > http://www.ietf.org/mail-archive/web/jose/current/msg04064.html
> >
> > 2. Sections 5.1 and 5.2 are a little confusing.  However, the use of
> > "typ" and "cty" appear in 3 drafts (at least), so this should get
> > addressed with an approach that considers the joint text to reduce
> > confusion for developers.  The initial descriptions are in the JOSE JWS
> > draft, so that may need most of the work, but it also appears in this
> > draft and the JOSE JWK draft.  In my writeup for the JWK review, I
> > listed out some questions and would like to see improvements across
> > these drafts.  This will likely require some joint work and may be best
> > in response to the JWK review to keep it in one place.
> >
> > http://www.ietf.org/mail-archive/web/jose/current/msg04172.html
> >
> > Thank you!
> >
> > --
> >
> > Best regards,
> > Kathleen
> >
> >
>
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>



--=20

Best regards,
Kathleen

--001a11c3d10ae6763c04fbbcbf69
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks, Mike.

Okay, SHA-1 was a bad exa=
mple. =C2=A0Hannes asked in response to my earlier review as he felt this w=
as not resolved. =C2=A0I read back through the most recent thread and do se=
e the responses you and Jim provided, also referenced in my response as val=
id considerations. =C2=A0If possible, it would be great to get this settled=
 sooner rather than later as well as for me to figure out if either approac=
h will cause heartburn in the IESG review process. =C2=A0I'll proactive=
ly dig into that so we can avoid issues later. =C2=A0They may or may not ca=
re either way. =C2=A0It would be good for me to know this for this particul=
ar issue as well as possible future issues that are similar so I can help c=
atch them earlier.



Is there a ticket on this from previous discussions to =
the ones started in April?

Thanks!


On Fri, Jun 13, 2=
014 at 3:26 PM, Mike Jones <Michael.Jones@microsoft.com><=
/span> wrote:













In no place is SHA-1 or a=
lgorithms using it MTI.=C2=A0 You can see the set of MTI algorithms by look=
ing at those marked =E2=80=9CRequired=E2=80=9D in the registries.=




=C2=A0


A small set of required a=
lgorithms is present, with the choices based on a detailed survey of what a=
lgorithms are widely deployed, to provide a basis for implementations
 to interoperate.=C2=A0 Recognizing that the set of algorithms that will be=
 appropriate to have as required will change over time, Sean Turner suggest=
ed that we enable future drafts to update the Implementation Requirements i=
n the registries, with expert review.=C2=A0
 (So for instance, an algorithm that might be =E2=80=9CRequired=E2=80=9D to=
day could be marked =E2=80=9CDeprecated=E2=80=9D in the future.)=C2=A0 We a=
dopted Sean=E2=80=99s suggestion a good while ago.


=C2=A0


This is another area that=
 was widely discussed within the JOSE working group, and there was never co=
nsensus to remove the implementation requirements, which
 have always been present.


=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=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=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=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=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike


=C2=A0


From: OAuth [m=
ailto:oauth-bou=
nces@ietf.org]
On Behalf Of Kathleen Moriarty

Sent: Friday, June 13, 2014 12:14 PM

To: Hannes Tschofenig

Cc: oauth@ietf.o=
rg


Subject: Re: [OAUTH-WG] JWT review


=C2=A0




Hi Hannes,




=C2=A0






Thank you for going through the various reviews, sin=
ce the JOSE ones should be of interest to Oauth. =C2=A0I'll respond in-=
line.




=C2=A0<=
/p>



On Thu, Jun 12, 2014 at 4:27 AM, Hannes Tschofenig &=
lt;hannes.ts=
chofenig@gmx.net> wrote:


Hi Kathleen,



on the first item I have a few minor remarks: You wrote:



"

As I read through the Algorithms (JWA) draft there are some changes that
will need to be made to avoid problems during the IESG review. =C2=A0This i=
s

a pretty big change for the draft, but will help make the review and

approval faster. =C2=A0Typically, the lists of algorithms are handled throu=
gh

a draft update as opposed to creating an IANA registry. =C2=A0A good exampl=
e

is a recent update of a draft in the IPSECME working group so you can

see the structure and the precedence for this model.

"




FYI - this is from the start of a long thread that h=
as been worked out already. =C2=A0I had included a link to the JWA review o=
nly for the section on the security consideratiosn section as many of the d=
rafts in JOSE, and at least one in OAuth
 start out with the same paragraph that could use some updating and correct=
ing. =C2=A0I wanted to make sure this working group was aware since JWT sha=
res that same paragraph. =C2=A0Mike is working through new text and has sol=
icited help from the WG (please respond on
 the JOSE list).=C2=A0








The IANA registry for the algorithm serves a different purpose than a

document recommending the specific algorithms. The reference to the

IPSECME document only provides the latter. It is also important to note

that the JWA not only defines the algorithm tags for the IANA registry

but also explains how they actually work with the JOSE defined JSON

structures (which is again a difference to the mentioned IPSECME document).=







The discussion on having a registry versus a draft h=
as been settled. =C2=A0The possibility of an issue came to me through an AD=
 and after discussion, it is fine as it is. =C2=A0There were some considera=
tions that needed to get surfaced, so the document
 can remain as-is. =C2=A0Sorry for the confusion. =C2=A0I'll file this =
away for the future reference.=C2=A0








Of course, the JWA document does both via the IANA registry and there is
the question about how these recommendations would then get updated and

what the consensus process is.



In an mail to the JOSE mailing list I argued against any MTI

recommendations since JOSE is a baseline technology that will be used in
a variety of different contexts and it is super likely that the

algorithm requirements will hugely vary.



I am just thinking about what algorithms I would recommend when using

the JOSE work in an IoT environment. My recommendations would deviate

from the currently given recommendations, which are largely impacted by

the Web community.



Here is the mail I sent to the JOSE list:

http://www.ietf.org/mail-archive/web/jose/current/msg040=
32.html



So, my recommendation is to



1) have no MTI requirements in the JWA spec

2) remove the 'JOSE Implementation Requirements' column from the IA=
NA

registry.






=C2=A0






Interesting. =C2=A0 I do remember having these discu=
ssions with Sean and Richard (see=C2=A0http://www.ietf.o=
rg/mail-archive/web/jose/current/msg04060.html). =C2=A0In Jim's opi=
nion,
 (from: 
http://www.ietf.org/mail-archive/web/jose/current/msg04062.html), his v=
iew is that even the MTI in JWA can be overridden in the spec. =C2=A0I wond=
er why you would have an MTI then?






=C2=A0






This closed out the discussion and it would be bette=
r to see it on the JOSE list than here. =C2=A0If the point is to get Oauth =
people who are encountering conflicts as a user of JOSE drafts to chime in,=
 that should happen on the JOSE list. =C2=A0I
 suspect this will be an issue for XMPP as well. =C2=A0They are phasing out=
 SHA-1, so if that's MTI for fingerprints, they may still feel like the=
y have to support SHA-1 for that purpose even though their work specifies t=
hat SHA-2 should be used everywhere.







=C2=A0






Since JWA is getting closer to IESG review, I'll=
 ask other ADs their thoughts on how they like to see this sort of thing ha=
ndled. =C2=A0Both Richard and Jim raised valid points.






=C2=A0






Thank you,






Kathleen =C2=A0








Ciao

Hannes










On 06/09/2014 06:17 PM, Kathleen Moriarty wrote:

> Hello,

>

> I am in process of working through the JOSE drafts and also read the
> Oauth JWT draft last week. =C2=A0There is some overlap in text that ma=
y

> require some joint work to correct.

>

> 1. For JWT, the Security Considerations section starts off with the sa=
me

> text that is in several of the JOSE drafts. =C2=A0In my review of the =
JWA

> draft, I asked for some fixes that will need to be made to this draft =
as

> well. =C2=A0Here is a link to that review and it may be easier to help=
 with

> this work in one spot where text will be reused. =C2=A0Mike has asked =
the

> JOSE WG to assist, but it make make sense for Oauth folks to help as
> well. =C2=A0If it makes sense, a pointer to existing text is also fine=
.

>

> 
http://www.ietf.org/mail-archive/web/jose/current/msg04064.html

>

> 2. Sections 5.1 and 5.2 are a little confusing. =C2=A0However, the use=
 of

> "typ" and "cty" appear in 3 drafts (at least), so =
this should get

> addressed with an approach that considers the joint text to reduce

> confusion for developers. =C2=A0The initial descriptions are in the JO=
SE JWS

> draft, so that may need most of the work, but it also appears in this<=
br>
> draft and the JOSE JWK draft. =C2=A0In my writeup for the JWK review, =
I

> listed out some questions and would like to see improvements across
> these drafts. =C2=A0This will likely require some joint work and may b=
e best

> in response to the JWK review to keep it in one place.

>

> 
http://www.ietf.org/mail-archive/web/jose/current/msg04172.html

>

> Thank you!

>

> --

>

> Best regards,

> Kathleen

>

>






> ________________=
_______________________________

> OAuth mailing list

> OAuth@ietf.org=


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

>















=C2=A0




-- 




=C2=A0




Best regards,






Kathleen




















-- 

Best regards,
Kathleen



--001a11c3d10ae6763c04fbbcbf69--


From nobody Fri Jun 13 12:41:35 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D8B1B2A27 for ; Fri, 13 Jun 2014 12:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrBJYSuEVXRZ for ; Fri, 13 Jun 2014 12:41:23 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE7F1B27FE for ; Fri, 13 Jun 2014 12:41:23 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5DJfLQH023114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jun 2014 19:41:22 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5DJfLLg019213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2014 19:41:21 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5DJfLaB019209; Fri, 13 Jun 2014 19:41:21 GMT
Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Jun 2014 12:41:21 -0700
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <5A6171E5-0902-4F75-AC1E-1C988353BF3F@oracle.com> <539B20DA.5010409@redhat.com> <748D0DD4-F6FB-4EB8-94F4-86E79A448881@oracle.com> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPhone Mail (11D201)
From: Phil Hunt 
Date: Fri, 13 Jun 2014 12:41:18 -0700
To: John Bradley 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/BN-HamKjwSZFwT__8wxWKNNTdKc
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 19:41:29 -0000

+1

Thanks John.=20

Phil

> On Jun 13, 2014, at 12:11, John Bradley  wrote:
>=20
> Subsequent to this email Phil and I have talked.
>=20
> There are two things that are deltas to connect in the spec.
>=20
> One is the ability to issue only a id_token from the token endpoint.
>=20
> The code grant_type requires a access token in the response.   If the WG w=
ants to define a new grant type that doesn't return a access or refresh toke=
n that would be fine and it could be used with Connect as other grant types a=
re.    The current use of a response_type in a4c to signal only returning a i=
d_token and reusing the "code" grant type is a problem.
> I think Mike J.  will be able to do an update with that shortly.
>=20
> Phil is correct that Connect doesn't currently support that OAuth grant ty=
pe because it has not been defined yet.  Not because you must provide claims=
 at the token endpoint.
>=20
> Connect supports the "id_token" and "none" response types nether of which p=
rovide access tokens.
>=20
> For example a authn request with a scope of "openid" and a response_type o=
f code will return a id_token and a access token for a user_info endpoint.  =
 However the user_info endpoint will only only contain a claim for the "sub"=
 that matches the "sub" in the id_token and not any photos of relatives, unl=
ess the IdP is horribly broken.
>=20
> We need to balance returning a access token that may be discarded by the c=
lient that gives access to no PII vs adding a new grant_type.  =20
> I think that would be a useful discussion that could feed back to Connect o=
r a4c.
>=20
> The other difference has to do with the use of authentication context and w=
anting to send a single value on a predefined scale vs an ordered list by pr=
eference.
> This has been debated many times and many places.   The Connect approach r=
ecognizes that authentication contexts are not necessarily scalar. =20
> In SAML we do have the constructs of better than etc.  I think these are i=
mplemented and used almost nowhere.  =20
> The Liberty/Kantara conformance testing only ever tested exact match.    S=
o Connect did something similar to the option that is used in SAML.
> I don't know that adding another way to ask for authentication context is h=
elping the world.
>=20
> This is perhaps a useful discussion, also independent of the specs though i=
t may want informing from people at OASIS/Kantara who are not normally part o=
f OAuth discussions.
>=20
> I remain concerned that if we do a small core authentication spec in the O=
Auth WG that may start being compatible with Connect that opens the door to e=
xtensions down the road that may not be as people inevitably discover that t=
here is more to life than the code flow.
>=20
> I prefer to profile down Connect and support a new response type if that i=
s desired rather than adding eventual confusion and incompatibility.
>=20
> The main question for the work group at this point is if we want to change=
 our charter to include authentication.  =20
> If we do then a4c and other authentication related drafts can come into th=
e WG.
>=20
> At this point a4c is a independent draft. =20
>=20
> I am in favour of having a concise draft for basic identity providers, doi=
ng simple SSO.=20
> Connect has a Basic Client profile for people developing clients/RP/SP as t=
here tend to be more of them than IdP.
> The same thing can be done in the Connect WG as a Basic IdP profile. =20
>=20
> Going to far into debating the finer points of a4c is probably premature, u=
ntil after a charter decision is reached.
>=20
> Regards
> John B.
>=20
>> On Jun 13, 2014, at 1:10 PM, Phil Hunt  wrote:
>>=20
>> I am going to address a few comments all together here:
>>=20
>> 1. John Bradley confirmed again yesterday, OIDC does not allow for authen=
tication only as part of the normal code flow and decided intentionally not t=
o address it.  So to say OIDC has a solution is confusing.
>>=20
>> OIDC has the solution if you want to propagate profile information and au=
then information.  This means service providers have to implement much more c=
ode, and clients have to as well. For many there are customer abandonment an=
d legal issues around sharing of too much PII information. They DO NOT want t=
o have to ask for this information.
>>=20
>> 2. Regarding speculative future size: I  point out that the A4C draft is m=
odelled exactly on the authorizaiton flow and has exactly the same security m=
odel. Therefore I would not expect any large increase in size, but rather th=
e opposite. The number 1 challenge with this spec is not figuring out how to=
 do this, but how to avoid scope creep into OIDC=E2=80=99s coverage.  I do N=
OT support scope creep into OIDC. =20
>>=20
>> We need a specific draft that addresses the issues of developers thinking=
 6749 is sufficient on its own.  I do NOT want to see stuff like browser bas=
ed apps and node.js as in scope. OIDC has this covered.
>>=20
>> 3. My point with the 18 wheeler analogy is that yes, it is a vehicle that=
 can take passengers, but it=E2=80=99s role is much more multi-purpose and h=
eavy duty. For the developer that wants to securely take the kids to school,=
 maybe just a Tesla Model S will do? This is less of a technical issue and m=
ore of a =E2=80=9Cmarket=E2=80=9D issue. I know that=E2=80=99s hard for peop=
le like us to address, but it is a comment I keep hearing over and over (and=
 not interestingly from Oracle itself).
>>=20
>> 4. As for confusion between OAuth=E2=80=99s intended authorization and a s=
o called new authen function. This is the issue I=E2=80=99m trying to get on=
 our agenda. This isn=E2=80=99t my idea, I am only the messenger. The fact i=
s, developers and service providers who are not OAuth experts assume OAuth i=
s about authentication and implement as such.  To some extent, this is  a ma=
rket problem. Still, OIDC has not addressed the scenario. As John stated, OI=
DC choose not to do authen only. =20
>>=20
>> 5. As for whether we =E2=80=9Ctack-on=E2=80=9D authen to OAuth as OIDC do=
es or whether we create a brand new endpoint or flow. I think that is open f=
or discussion once the charter is adopted.  A4C is just an input draft - not=
 the way the group needs to solve it.  A4C is intended to show the problem i=
s solvable in a reasonably implementable manner.
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>> On Jun 13, 2014, at 9:03 AM, Bill Burke  wrote:
>>>=20
>>>=20
>>>=20
>>>> On 6/12/2014 4:18 PM, Phil Hunt wrote:
>>>>=20
>>>>=20
>>>> Phil
>>>>=20
>>>>> On Jun 12, 2014, at 12:50, Bill Burke  wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>>>>>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has
>>>>>> received review from maybe a dozen engineers within the OpenID commun=
ity.
>>>>>=20
>>>>> The OpenID Connect spec is 86 pages because it pretty much rehashes th=
e OAuth2 spec walking through each flow and how Open ID Connect expands on t=
hat flow.  A4c looks like a subset of this work minus some additional claims=
 and, IMO, is incomplete compared to OIDC.
>>>> In what regards?
>>>>=20
>>>> Much of oidc is out of scope for this requirement.
>>>=20
>>> What is in a4c that isn't already in OIDC?
>>>=20
>>>> It is a bit like saying an 18 wheeler is suitable for driving the kids t=
o school. :-)
>>>=20
>>> I don't think this is true.  Most oidc oauth extensions are optional wit=
h the sole requirement that providers don't barf if you send them.
>>>=20
>>> --=20
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


From nobody Fri Jun 13 12:43:02 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F2B1B29D0 for ; Fri, 13 Jun 2014 12:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S15c4peSzEkK for ; Fri, 13 Jun 2014 12:42:56 -0700 (PDT)
Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0511B27FE for ; Fri, 13 Jun 2014 12:42:56 -0700 (PDT)
Received: by mail-qc0-f170.google.com with SMTP id l6so4796272qcy.1 for ; Fri, 13 Jun 2014 12:42:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=JLOpkV8QY4xl5iE1Eoh7gUbCSUrTAF/D1oKgIsR9ViY=; b=KwvQ87MDvIsMKlCyamY0xouT+1cLBxxdplbgf7+sOrfDTOVu2ZwBEiXRui2pohFTiT PAvfsr3pXX8RhDJcTOl5EHFVv9dtGLnunGZlPsAtClVCVZyDOruau//t+vdaozf8HtFZ +LhRiPk2bxpzRGY3Ul54I8nDFNYW8dl9/OpxDs6bUgqjs/TIeZDYnH8P1wMGhC2LA0ww 0C3Ff+r25f/HVktOGNUR47yqeJ09CnxcLRyah0KpuzXquE12BKHzfuGK4toakYKA0Gvv ApsJxw5aXb67Q6daUEkJq3uN6zuv1WTpJF/H1rcMVwIHkma2k0nsm2EP5DUr3hthYFZu L9lw==
X-Gm-Message-State: ALoCoQme8tchaHgk04Kpi9fZZFtgwSifOH7DCutWnL9/yoMdFILso/pLAorW98WSpAnst5iHU9Bu
X-Received: by 10.224.66.193 with SMTP id o1mr6960837qai.43.1402688575684; Fri, 13 Jun 2014 12:42:55 -0700 (PDT)
Received: from [192.168.0.200] ([201.189.40.105]) by mx.google.com with ESMTPSA id s13sm7935544qay.39.2014.06.13.12.42.52 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 12:42:53 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: John Bradley 
In-Reply-To: <539B345A.7060808@redhat.com>
Date: Fri, 13 Jun 2014 15:43:48 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7082F35E-422C-441F-BBE8-158E4A9BA085@ve7jtb.com>
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <539A0FB1.1020106@pingidentity.com> <13F2E738-49BB-4EDB-9070-5A49448A6249@ve7jtb.com> <539B345A.7060808@redhat.com>
To: Anil Saldhana 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YP9vNrePc7_j-AW99TSc8AEPaTI
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 19:42:59 -0000

Hi Anil,

There are a number of profile efforts being looked at in the OIDF.   The =
Mobile Network operators lead by the GSMA are starting profile work on a =
standard profile that will be supported by mobile operators globally, =
that includes looking at how a Client/RP/SP can register there client =
once for use across multiple IdP AS, as well as standardized LoA and =
user-info schema extensions.

Torsten Lodderstedt is the chair of that effort and can chime in.

I suspect that a Basic IdP for SSO profile is significantly less =
ambitious than that and could be done in the current Connect WG.

If there is interest from the members to start it.   The main time =
blocking factor might be getting a new grant_type spec approved in the =
the OAuth WG if we wanted to support that.

The IdP profile is simple they can publish a discovery document saying =
they only support that that limited feature set, that way they would =
also be compatible with existing connect clients.

{
"scopes_supported": ["openid"],
"response_types_supported":["code"],
"response_modes_supported":["query"],
"grant_types_supported":["authorization_code", "code_id_token_only"],
"acr_values_supported":["2","3"]
}

They don't need to publish one if they don't intend to be discoverable =
to clients but knowing what the path forward to supporting generic =
client is helpful I think.

Everything exists now other than the new grant_type exists now.

The work would mostly be putting together the examples based on =
supporting a minimal flow.

Now I should point out that there are people who believe that the =
default flow should be implicit with the "id_token" response_type and =
intend to support that.
Phil's draft concentrates on only one use case.   Having a IdP =
deployment profile for it is not a problem, but it will not be for every =
IdP.   That is one of the reasons why discovery and registration are =
important features of Connect.

John B.


On Jun 13, 2014, at 1:26 PM, Anil Saldhana  =
wrote:

> On 06/12/2014 04:18 PM, John Bradley wrote:
>> All but a handful of OAuth WG participants participated in developing =
OpenID Connect.
>>=20
>> Yes some companies chose not to participate for whatever reasons and =
have not committed to the mutual non assert IPR agreement, and that is =
unfortunate, but not a reason to start again from scratch.
>>=20
>> Changing the OIDF IPR policy of totally open specifications based on =
non asserts is also not a option.
>>=20
>> I have made comments on the current draft of a4c.
>>=20
>> I think a profile of Connect introducing a grant_type returning only =
an id_token would be simpler than trying to do this as a separate spec.
>> I do note that you can do effectively the same thing now by using a =
code response_type and a scope of openID.   This doesn't result in any =
extra user consent other than consenting to login to the RP the first =
time (though that consent can be given in advance out of band in a =
enterprise scenario.
>>=20
>> When developing Connect we debated having a token endpoint response =
with only a id_token but decided that it was not in the spirit of being =
a OAuth 2 profile.   So we decided to return a access token even if the =
user info endpoint contains no claims other then sub.   People almost =
always want more claims as they roll out a real deployment.  It is easy =
to add them if you have designed to be able to talk to a RS.
>> OAuth without a RS is a touch not OAuth.
>>=20
>> a4c also completely ignores modern development environments like =
node.js where the client is in the user agent, that OAuth 2 and Connect =
support.
>>=20
>> By the time the OAuth WG is done with a4c it will likely be a similar =
size as Connect if it addresses the same use cases.
>>=20
>> I still don't see the problem with having a deployment profile of =
Connect that can meet 100% of the current stated use case for a4c.
> John - I am not fully familiar with the processes of OIDC.  How much =
of an effort is it to get the deployment profile of OIDC connect =
rolling?
>=20
>>=20
>> I expect that the people here involved in Connect will form there own =
opinions on comments regarding the number of participants and the =
quantity of the work and review.
>>=20
>> Regards
>> John B.
>>=20
>>=20
>>=20
>>=20
>> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt =
 wrote:
>>=20
>>> +1, after implementing OIDC I will support the claim that any SSO =
protocol with a minimal set of required features smaller than OIDC is =
insecure and any protocol with similar features but with different =
parameter names is just creating confusion and will increase chances of =
non-interoperable and insecure implementations
>>>=20
>>> Hans.
>>>=20
>>> On 6/12/14, 9:50 PM, Bill Burke wrote:
>>>>=20
>>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>>>>> The OpenID Connect 2.0 COre specification alone is 86 pages. It =
has
>>>>> received review from maybe a dozen engineers within the OpenID =
community.
>>>>>=20
>>>> The OpenID Connect spec is 86 pages because it pretty much rehashes =
the
>>>> OAuth2 spec walking through each flow and how Open ID Connect =
expands on
>>>> that flow.  A4c looks like a subset of this work minus some =
additional
>>>> claims and, IMO, is incomplete compared to OIDC.
>>>>=20
>>>> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We
>>>> originally were creating our own oauth2 extension using JWT, but =
found
>>>> that any feature we wanted to define already existed in OpenID =
Connect.
>>>>  These guys have done great work.   Aren't many of you here authors =
of
>>>> this spec and/or the same companies?!?  I think your energies are =
better
>>>> focused on lobbying OIDC to join the IETF and this WG.
>>>>=20
>>>>=20
>>>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Fri Jun 13 13:04:46 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348F71B29B7 for ; Fri, 13 Jun 2014 13:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81njn6Q3-fDB for ; Fri, 13 Jun 2014 13:04:42 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968D81A023A for ; Fri, 13 Jun 2014 13:04:41 -0700 (PDT)
Received: from CH1PR03CA006.namprd03.prod.outlook.com (10.255.156.151) by BN1PR0301MB0594.namprd03.prod.outlook.com (25.160.170.21) with Microsoft SMTP Server (TLS) id 15.0.959.24; Fri, 13 Jun 2014 20:04:38 +0000
Received: from BL2FFO11FD031.protection.gbl (10.255.156.132) by CH1PR03CA006.outlook.office365.com (10.255.156.151) with Microsoft SMTP Server (TLS) id 15.0.959.24 via Frontend Transport; Fri, 13 Jun 2014 20:04:38 +0000
Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD031.mail.protection.outlook.com (10.173.160.71) with Microsoft SMTP Server (TLS) id 15.0.959.15 via Frontend Transport; Fri, 13 Jun 2014 20:04:38 +0000
Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.173]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0195.002; Fri, 13 Jun 2014 20:04:31 +0000
From: Mike Jones 
To: Kathleen Moriarty , Hannes Tschofenig 
Thread-Topic: [OAUTH-WG] JWT review
Thread-Index: AQHPg/5gzu/A4NjdfECJ7UyyP64X2JttKDuAgAJHBACAAACncIAABkLw
Date: Fri, 13 Jun 2014 20:04:30 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD6D431@TK5EX14MBXC292.redmond.corp.microsoft.com>
References:  <53996461.7080507@gmx.net>  <4E1F6AAD24975D4BA5B16804296739439AD6D0D8@TK5EX14MBXC292.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD6D0D8@TK5EX14MBXC292.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD6D431TK5EX14MBXC292r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438001)(189002)(199002)(24454002)(60444003)(69234005)(51704005)(377454003)(479174003)(26826002)(69596002)(74662001)(85806002)(54356999)(15202345003)(50986999)(2656002)(16297215004)(99396002)(76176999)(74502001)(19625215002)(512874002)(83322001)(97736001)(19300405004)(68736004)(84326002)(93886003)(86612001)(15975445006)(87936001)(19580395003)(46102001)(55846006)(80022001)(71186001)(104016001)(81342001)(76482001)(21056001)(33656002)(77982001)(66066001)(86362001)(85852003)(4396001)(81156002)(44976005)(92566001)(19580405001)(20776003)(83072002)(31966008)(6806004)(84676001)(16236675004)(79102001)(81542001)(64706001)(92726001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR0301MB0594; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0241D5F98C
Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; 
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3gI5hZ-RWXFLNWz4eHgNbhmYoDY
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] JWT review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 20:04:45 -0000

--_000_4E1F6AAD24975D4BA5B16804296739439AD6D431TK5EX14MBXC292r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhpcyB3YXMgY29uc2lkZXJlZCBieSB0aGUgV0cgYXMgaXNzdWUgIzEwIC0gaHR0cDovL3RyYWMu
dG9vbHMuaWV0Zi5vcmcvd2cvam9zZS90cmFjL3RpY2tldC8xMC4NCg0KSW4gdGhlIE9BdXRoIGNv
bnRleHQsIEkga25vdyB0aGF0IGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucyBhbmQgZHJhZnQt
aWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXIgd2VyZSBzZW50IHRvIHRoZSBJRVNHIGZvciByZXZpZXcg
aW4gMjAxMiBhbmQgdGhlbiBzZW50IGJhY2sgdG8gdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgYnkg
dGhlIElFU0cgYmVjYXVzZSB0aGV5IGZlbHQgdGhhdCBhZGRpdGlvbmFsIHdvcmsgbmVlZGVkIHRv
IGJlIGRvbmUgb24gdGhlIGRyYWZ0cyBzbyB0aGF0IHRoZXkgd291bGQgYWN0dWFsbHkgYmUgaW50
ZXJvcGVyYWJsZSDigJMgbm90IGp1c3QgdGhhdCBpdCB3YXMgcG9zc2libGUgZm9yIGltcGxlbWVu
dGF0aW9ucyB0byBpbnRlcm9wZXJhdGUuICBTdGVwaGVuIEZhcnJlbGwgY291bGQgcGVyaGFwcyBz
cGVhayBtb3JlIHRvIHRoYXQuDQoNClRoYXQgY2xlYXIgc2VudGltZW50IGZyb20gdGhlIElFU0cg
dG8gdGhlIE9BdXRoIFdHIGhhcyBhbHNvIGluZm9ybWVkIHRoZSBkZWNpc2lvbnMgZm9yIHRoZSBK
V1QgYW5kIEpPU0Ugc3BlY3MgdG8ga2VlcCBhIHNtYWxsIHNldCBvZiBNVEkgYWxnb3JpdGhtcyBz
byB0aGF0IGltcGxlbWVudGF0aW9ucyB3b3VsZCBhY3R1YWxseSBoYXZlIGEgY29tbW9uIGJhc2lz
IHRvIGludGVyb3BlcmF0ZS4NCg0KSUVTRyBmZWVkYmFjayBvbiByZXF1aXJpbmcgaW50ZXJvcGVy
YWJpbGl0eSB3YXMgcmVmZXJlbmNlZCBieSBKaW0gU2NoYWFkIGluIGhpcyB0ZXh0IGNsb3Npbmcg
dGhlIGlzc3VlOg0KVGhlIElFU0cgaGFzIGhhZCBhIGRpc2N1c3Npb24gb24gdGhpcyBpc3N1ZSBh
cyBwYXJ0IG9mIHRoZSByZWNlbnQgY2hhcnRlciBkaXNjdXNzaW9ucy4gVGhlIGNoYWlycyBiZWxp
ZXZlIHRoYXQgaXMgaXMgY2xlYXIgZnJvbSB0aGF0IGRpc2N1c3Npb25zIHRoYXQgTVRJIGFsZ29y
aXRobXMgYXJlIGdvaW5nIHRvIGJlIHJlcXVpcmVkIGluIG9yZGVyIGZvciB0aGUgZG9jdW1lbnRz
IHRvIHByb2dyZXNzLiBGb3IgdGhhdCByZWFzb24gd2UgYXJlIGNsb3NpbmcgdGhpcyB0aWNrZXQu
DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu
b3JnXSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2VudDogRnJpZGF5LCBKdW5lIDEzLCAyMDE0
IDEyOjI3IFBNDQpUbzogS2F0aGxlZW4gTW9yaWFydHk7IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzog
b2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEpXVCByZXZpZXcNCg0KSW4g
bm8gcGxhY2UgaXMgU0hBLTEgb3IgYWxnb3JpdGhtcyB1c2luZyBpdCBNVEkuICBZb3UgY2FuIHNl
ZSB0aGUgc2V0IG9mIE1USSBhbGdvcml0aG1zIGJ5IGxvb2tpbmcgYXQgdGhvc2UgbWFya2VkIOKA
nFJlcXVpcmVk4oCdIGluIHRoZSByZWdpc3RyaWVzLg0KDQpBIHNtYWxsIHNldCBvZiByZXF1aXJl
ZCBhbGdvcml0aG1zIGlzIHByZXNlbnQsIHdpdGggdGhlIGNob2ljZXMgYmFzZWQgb24gYSBkZXRh
aWxlZCBzdXJ2ZXkgb2Ygd2hhdCBhbGdvcml0aG1zIGFyZSB3aWRlbHkgZGVwbG95ZWQsIHRvIHBy
b3ZpZGUgYSBiYXNpcyBmb3IgaW1wbGVtZW50YXRpb25zIHRvIGludGVyb3BlcmF0ZS4gIFJlY29n
bml6aW5nIHRoYXQgdGhlIHNldCBvZiBhbGdvcml0aG1zIHRoYXQgd2lsbCBiZSBhcHByb3ByaWF0
ZSB0byBoYXZlIGFzIHJlcXVpcmVkIHdpbGwgY2hhbmdlIG92ZXIgdGltZSwgU2VhbiBUdXJuZXIg
c3VnZ2VzdGVkIHRoYXQgd2UgZW5hYmxlIGZ1dHVyZSBkcmFmdHMgdG8gdXBkYXRlIHRoZSBJbXBs
ZW1lbnRhdGlvbiBSZXF1aXJlbWVudHMgaW4gdGhlIHJlZ2lzdHJpZXMsIHdpdGggZXhwZXJ0IHJl
dmlldy4gIChTbyBmb3IgaW5zdGFuY2UsIGFuIGFsZ29yaXRobSB0aGF0IG1pZ2h0IGJlIOKAnFJl
cXVpcmVk4oCdIHRvZGF5IGNvdWxkIGJlIG1hcmtlZCDigJxEZXByZWNhdGVk4oCdIGluIHRoZSBm
dXR1cmUuKSAgV2UgYWRvcHRlZCBTZWFu4oCZcyBzdWdnZXN0aW9uIGEgZ29vZCB3aGlsZSBhZ28u
DQoNClRoaXMgaXMgYW5vdGhlciBhcmVhIHRoYXQgd2FzIHdpZGVseSBkaXNjdXNzZWQgd2l0aGlu
IHRoZSBKT1NFIHdvcmtpbmcgZ3JvdXAsIGFuZCB0aGVyZSB3YXMgbmV2ZXIgY29uc2Vuc3VzIHRv
IHJlbW92ZSB0aGUgaW1wbGVtZW50YXRpb24gcmVxdWlyZW1lbnRzLCB3aGljaCBoYXZlIGFsd2F5
cyBiZWVuIHByZXNlbnQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0
aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2F0aGxlZW4gTW9yaWFydHkNClNlbnQ6
IEZyaWRheSwgSnVuZSAxMywgMjAxNCAxMjoxNCBQTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQpD
Yzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtP
QVVUSC1XR10gSldUIHJldmlldw0KDQpIaSBIYW5uZXMsDQoNClRoYW5rIHlvdSBmb3IgZ29pbmcg
dGhyb3VnaCB0aGUgdmFyaW91cyByZXZpZXdzLCBzaW5jZSB0aGUgSk9TRSBvbmVzIHNob3VsZCBi
ZSBvZiBpbnRlcmVzdCB0byBPYXV0aC4gIEknbGwgcmVzcG9uZCBpbi1saW5lLg0KDQpPbiBUaHUs
IEp1biAxMiwgMjAxNCBhdCA0OjI3IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hv
ZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdyb3RlOg0K
SGkgS2F0aGxlZW4sDQoNCm9uIHRoZSBmaXJzdCBpdGVtIEkgaGF2ZSBhIGZldyBtaW5vciByZW1h
cmtzOiBZb3Ugd3JvdGU6DQoNCiINCkFzIEkgcmVhZCB0aHJvdWdoIHRoZSBBbGdvcml0aG1zIChK
V0EpIGRyYWZ0IHRoZXJlIGFyZSBzb21lIGNoYW5nZXMgdGhhdA0Kd2lsbCBuZWVkIHRvIGJlIG1h
ZGUgdG8gYXZvaWQgcHJvYmxlbXMgZHVyaW5nIHRoZSBJRVNHIHJldmlldy4gIFRoaXMgaXMNCmEg
cHJldHR5IGJpZyBjaGFuZ2UgZm9yIHRoZSBkcmFmdCwgYnV0IHdpbGwgaGVscCBtYWtlIHRoZSBy
ZXZpZXcgYW5kDQphcHByb3ZhbCBmYXN0ZXIuICBUeXBpY2FsbHksIHRoZSBsaXN0cyBvZiBhbGdv
cml0aG1zIGFyZSBoYW5kbGVkIHRocm91Z2gNCmEgZHJhZnQgdXBkYXRlIGFzIG9wcG9zZWQgdG8g
Y3JlYXRpbmcgYW4gSUFOQSByZWdpc3RyeS4gIEEgZ29vZCBleGFtcGxlDQppcyBhIHJlY2VudCB1
cGRhdGUgb2YgYSBkcmFmdCBpbiB0aGUgSVBTRUNNRSB3b3JraW5nIGdyb3VwIHNvIHlvdSBjYW4N
CnNlZSB0aGUgc3RydWN0dXJlIGFuZCB0aGUgcHJlY2VkZW5jZSBmb3IgdGhpcyBtb2RlbC4NCiIN
CkZZSSAtIHRoaXMgaXMgZnJvbSB0aGUgc3RhcnQgb2YgYSBsb25nIHRocmVhZCB0aGF0IGhhcyBi
ZWVuIHdvcmtlZCBvdXQgYWxyZWFkeS4gIEkgaGFkIGluY2x1ZGVkIGEgbGluayB0byB0aGUgSldB
IHJldmlldyBvbmx5IGZvciB0aGUgc2VjdGlvbiBvbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv
c24gc2VjdGlvbiBhcyBtYW55IG9mIHRoZSBkcmFmdHMgaW4gSk9TRSwgYW5kIGF0IGxlYXN0IG9u
ZSBpbiBPQXV0aCBzdGFydCBvdXQgd2l0aCB0aGUgc2FtZSBwYXJhZ3JhcGggdGhhdCBjb3VsZCB1
c2Ugc29tZSB1cGRhdGluZyBhbmQgY29ycmVjdGluZy4gIEkgd2FudGVkIHRvIG1ha2Ugc3VyZSB0
aGlzIHdvcmtpbmcgZ3JvdXAgd2FzIGF3YXJlIHNpbmNlIEpXVCBzaGFyZXMgdGhhdCBzYW1lIHBh
cmFncmFwaC4gIE1pa2UgaXMgd29ya2luZyB0aHJvdWdoIG5ldyB0ZXh0IGFuZCBoYXMgc29saWNp
dGVkIGhlbHAgZnJvbSB0aGUgV0cgKHBsZWFzZSByZXNwb25kIG9uIHRoZSBKT1NFIGxpc3QpLg0K
DQpUaGUgSUFOQSByZWdpc3RyeSBmb3IgdGhlIGFsZ29yaXRobSBzZXJ2ZXMgYSBkaWZmZXJlbnQg
cHVycG9zZSB0aGFuIGENCmRvY3VtZW50IHJlY29tbWVuZGluZyB0aGUgc3BlY2lmaWMgYWxnb3Jp
dGhtcy4gVGhlIHJlZmVyZW5jZSB0byB0aGUNCklQU0VDTUUgZG9jdW1lbnQgb25seSBwcm92aWRl
cyB0aGUgbGF0dGVyLiBJdCBpcyBhbHNvIGltcG9ydGFudCB0byBub3RlDQp0aGF0IHRoZSBKV0Eg
bm90IG9ubHkgZGVmaW5lcyB0aGUgYWxnb3JpdGhtIHRhZ3MgZm9yIHRoZSBJQU5BIHJlZ2lzdHJ5
DQpidXQgYWxzbyBleHBsYWlucyBob3cgdGhleSBhY3R1YWxseSB3b3JrIHdpdGggdGhlIEpPU0Ug
ZGVmaW5lZCBKU09ODQpzdHJ1Y3R1cmVzICh3aGljaCBpcyBhZ2FpbiBhIGRpZmZlcmVuY2UgdG8g
dGhlIG1lbnRpb25lZCBJUFNFQ01FIGRvY3VtZW50KS4NClRoZSBkaXNjdXNzaW9uIG9uIGhhdmlu
ZyBhIHJlZ2lzdHJ5IHZlcnN1cyBhIGRyYWZ0IGhhcyBiZWVuIHNldHRsZWQuICBUaGUgcG9zc2li
aWxpdHkgb2YgYW4gaXNzdWUgY2FtZSB0byBtZSB0aHJvdWdoIGFuIEFEIGFuZCBhZnRlciBkaXNj
dXNzaW9uLCBpdCBpcyBmaW5lIGFzIGl0IGlzLiAgVGhlcmUgd2VyZSBzb21lIGNvbnNpZGVyYXRp
b25zIHRoYXQgbmVlZGVkIHRvIGdldCBzdXJmYWNlZCwgc28gdGhlIGRvY3VtZW50IGNhbiByZW1h
aW4gYXMtaXMuICBTb3JyeSBmb3IgdGhlIGNvbmZ1c2lvbi4gIEknbGwgZmlsZSB0aGlzIGF3YXkg
Zm9yIHRoZSBmdXR1cmUgcmVmZXJlbmNlLg0KDQpPZiBjb3Vyc2UsIHRoZSBKV0EgZG9jdW1lbnQg
ZG9lcyBib3RoIHZpYSB0aGUgSUFOQSByZWdpc3RyeSBhbmQgdGhlcmUgaXMNCnRoZSBxdWVzdGlv
biBhYm91dCBob3cgdGhlc2UgcmVjb21tZW5kYXRpb25zIHdvdWxkIHRoZW4gZ2V0IHVwZGF0ZWQg
YW5kDQp3aGF0IHRoZSBjb25zZW5zdXMgcHJvY2VzcyBpcy4NCg0KSW4gYW4gbWFpbCB0byB0aGUg
Sk9TRSBtYWlsaW5nIGxpc3QgSSBhcmd1ZWQgYWdhaW5zdCBhbnkgTVRJDQpyZWNvbW1lbmRhdGlv
bnMgc2luY2UgSk9TRSBpcyBhIGJhc2VsaW5lIHRlY2hub2xvZ3kgdGhhdCB3aWxsIGJlIHVzZWQg
aW4NCmEgdmFyaWV0eSBvZiBkaWZmZXJlbnQgY29udGV4dHMgYW5kIGl0IGlzIHN1cGVyIGxpa2Vs
eSB0aGF0IHRoZQ0KYWxnb3JpdGhtIHJlcXVpcmVtZW50cyB3aWxsIGh1Z2VseSB2YXJ5Lg0KDQpJ
IGFtIGp1c3QgdGhpbmtpbmcgYWJvdXQgd2hhdCBhbGdvcml0aG1zIEkgd291bGQgcmVjb21tZW5k
IHdoZW4gdXNpbmcNCnRoZSBKT1NFIHdvcmsgaW4gYW4gSW9UIGVudmlyb25tZW50LiBNeSByZWNv
bW1lbmRhdGlvbnMgd291bGQgZGV2aWF0ZQ0KZnJvbSB0aGUgY3VycmVudGx5IGdpdmVuIHJlY29t
bWVuZGF0aW9ucywgd2hpY2ggYXJlIGxhcmdlbHkgaW1wYWN0ZWQgYnkNCnRoZSBXZWIgY29tbXVu
aXR5Lg0KDQpIZXJlIGlzIHRoZSBtYWlsIEkgc2VudCB0byB0aGUgSk9TRSBsaXN0Og0KaHR0cDov
L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwNDAzMi5odG1s
DQoNClNvLCBteSByZWNvbW1lbmRhdGlvbiBpcyB0bw0KDQoxKSBoYXZlIG5vIE1USSByZXF1aXJl
bWVudHMgaW4gdGhlIEpXQSBzcGVjDQoyKSByZW1vdmUgdGhlICdKT1NFIEltcGxlbWVudGF0aW9u
IFJlcXVpcmVtZW50cycgY29sdW1uIGZyb20gdGhlIElBTkENCnJlZ2lzdHJ5Lg0KDQpJbnRlcmVz
dGluZy4gICBJIGRvIHJlbWVtYmVyIGhhdmluZyB0aGVzZSBkaXNjdXNzaW9ucyB3aXRoIFNlYW4g
YW5kIFJpY2hhcmQgKHNlZSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvam9z
ZS9jdXJyZW50L21zZzA0MDYwLmh0bWwpLiAgSW4gSmltJ3Mgb3BpbmlvbiwgKGZyb206IGh0dHA6
Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQwNjIuaHRt
bCksIGhpcyB2aWV3IGlzIHRoYXQgZXZlbiB0aGUgTVRJIGluIEpXQSBjYW4gYmUgb3ZlcnJpZGRl
biBpbiB0aGUgc3BlYy4gIEkgd29uZGVyIHdoeSB5b3Ugd291bGQgaGF2ZSBhbiBNVEkgdGhlbj8N
Cg0KVGhpcyBjbG9zZWQgb3V0IHRoZSBkaXNjdXNzaW9uIGFuZCBpdCB3b3VsZCBiZSBiZXR0ZXIg
dG8gc2VlIGl0IG9uIHRoZSBKT1NFIGxpc3QgdGhhbiBoZXJlLiAgSWYgdGhlIHBvaW50IGlzIHRv
IGdldCBPYXV0aCBwZW9wbGUgd2hvIGFyZSBlbmNvdW50ZXJpbmcgY29uZmxpY3RzIGFzIGEgdXNl
ciBvZiBKT1NFIGRyYWZ0cyB0byBjaGltZSBpbiwgdGhhdCBzaG91bGQgaGFwcGVuIG9uIHRoZSBK
T1NFIGxpc3QuICBJIHN1c3BlY3QgdGhpcyB3aWxsIGJlIGFuIGlzc3VlIGZvciBYTVBQIGFzIHdl
bGwuICBUaGV5IGFyZSBwaGFzaW5nIG91dCBTSEEtMSwgc28gaWYgdGhhdCdzIE1USSBmb3IgZmlu
Z2VycHJpbnRzLCB0aGV5IG1heSBzdGlsbCBmZWVsIGxpa2UgdGhleSBoYXZlIHRvIHN1cHBvcnQg
U0hBLTEgZm9yIHRoYXQgcHVycG9zZSBldmVuIHRob3VnaCB0aGVpciB3b3JrIHNwZWNpZmllcyB0
aGF0IFNIQS0yIHNob3VsZCBiZSB1c2VkIGV2ZXJ5d2hlcmUuDQoNClNpbmNlIEpXQSBpcyBnZXR0
aW5nIGNsb3NlciB0byBJRVNHIHJldmlldywgSSdsbCBhc2sgb3RoZXIgQURzIHRoZWlyIHRob3Vn
aHRzIG9uIGhvdyB0aGV5IGxpa2UgdG8gc2VlIHRoaXMgc29ydCBvZiB0aGluZyBoYW5kbGVkLiAg
Qm90aCBSaWNoYXJkIGFuZCBKaW0gcmFpc2VkIHZhbGlkIHBvaW50cy4NCg0KVGhhbmsgeW91LA0K
S2F0aGxlZW4NCg0KQ2lhbw0KSGFubmVzDQoNCg0KT24gMDYvMDkvMjAxNCAwNjoxNyBQTSwgS2F0
aGxlZW4gTW9yaWFydHkgd3JvdGU6DQo+IEhlbGxvLA0KPg0KPiBJIGFtIGluIHByb2Nlc3Mgb2Yg
d29ya2luZyB0aHJvdWdoIHRoZSBKT1NFIGRyYWZ0cyBhbmQgYWxzbyByZWFkIHRoZQ0KPiBPYXV0
aCBKV1QgZHJhZnQgbGFzdCB3ZWVrLiAgVGhlcmUgaXMgc29tZSBvdmVybGFwIGluIHRleHQgdGhh
dCBtYXkNCj4gcmVxdWlyZSBzb21lIGpvaW50IHdvcmsgdG8gY29ycmVjdC4NCj4NCj4gMS4gRm9y
IEpXVCwgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gc3RhcnRzIG9mZiB3aXRo
IHRoZSBzYW1lDQo+IHRleHQgdGhhdCBpcyBpbiBzZXZlcmFsIG9mIHRoZSBKT1NFIGRyYWZ0cy4g
IEluIG15IHJldmlldyBvZiB0aGUgSldBDQo+IGRyYWZ0LCBJIGFza2VkIGZvciBzb21lIGZpeGVz
IHRoYXQgd2lsbCBuZWVkIHRvIGJlIG1hZGUgdG8gdGhpcyBkcmFmdCBhcw0KPiB3ZWxsLiAgSGVy
ZSBpcyBhIGxpbmsgdG8gdGhhdCByZXZpZXcgYW5kIGl0IG1heSBiZSBlYXNpZXIgdG8gaGVscCB3
aXRoDQo+IHRoaXMgd29yayBpbiBvbmUgc3BvdCB3aGVyZSB0ZXh0IHdpbGwgYmUgcmV1c2VkLiAg
TWlrZSBoYXMgYXNrZWQgdGhlDQo+IEpPU0UgV0cgdG8gYXNzaXN0LCBidXQgaXQgbWFrZSBtYWtl
IHNlbnNlIGZvciBPYXV0aCBmb2xrcyB0byBoZWxwIGFzDQo+IHdlbGwuICBJZiBpdCBtYWtlcyBz
ZW5zZSwgYSBwb2ludGVyIHRvIGV4aXN0aW5nIHRleHQgaXMgYWxzbyBmaW5lLg0KPg0KPiBodHRw
Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzA0MDY0Lmh0
bWwNCj4NCj4gMi4gU2VjdGlvbnMgNS4xIGFuZCA1LjIgYXJlIGEgbGl0dGxlIGNvbmZ1c2luZy4g
IEhvd2V2ZXIsIHRoZSB1c2Ugb2YNCj4gInR5cCIgYW5kICJjdHkiIGFwcGVhciBpbiAzIGRyYWZ0
cyAoYXQgbGVhc3QpLCBzbyB0aGlzIHNob3VsZCBnZXQNCj4gYWRkcmVzc2VkIHdpdGggYW4gYXBw
cm9hY2ggdGhhdCBjb25zaWRlcnMgdGhlIGpvaW50IHRleHQgdG8gcmVkdWNlDQo+IGNvbmZ1c2lv
biBmb3IgZGV2ZWxvcGVycy4gIFRoZSBpbml0aWFsIGRlc2NyaXB0aW9ucyBhcmUgaW4gdGhlIEpP
U0UgSldTDQo+IGRyYWZ0LCBzbyB0aGF0IG1heSBuZWVkIG1vc3Qgb2YgdGhlIHdvcmssIGJ1dCBp
dCBhbHNvIGFwcGVhcnMgaW4gdGhpcw0KPiBkcmFmdCBhbmQgdGhlIEpPU0UgSldLIGRyYWZ0LiAg
SW4gbXkgd3JpdGV1cCBmb3IgdGhlIEpXSyByZXZpZXcsIEkNCj4gbGlzdGVkIG91dCBzb21lIHF1
ZXN0aW9ucyBhbmQgd291bGQgbGlrZSB0byBzZWUgaW1wcm92ZW1lbnRzIGFjcm9zcw0KPiB0aGVz
ZSBkcmFmdHMuICBUaGlzIHdpbGwgbGlrZWx5IHJlcXVpcmUgc29tZSBqb2ludCB3b3JrIGFuZCBt
YXkgYmUgYmVzdA0KPiBpbiByZXNwb25zZSB0byB0aGUgSldLIHJldmlldyB0byBrZWVwIGl0IGlu
IG9uZSBwbGFjZS4NCj4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pv
c2UvY3VycmVudC9tc2cwNDE3Mi5odG1sDQo+DQo+IFRoYW5rIHlvdSENCj4NCj4gLS0NCj4NCj4g
QmVzdCByZWdhcmRzLA0KPiBLYXRobGVlbg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhA
aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+DQoNCg0KDQotLQ0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRo
bGVlbg0K

--_000_4E1F6AAD24975D4BA5B16804296739439AD6D431TK5EX14MBXC292r_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0
YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz
cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5C
YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ
Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp
biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv
c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl
ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i
ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv
aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk
aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyB3YXMgY29uc2lkZXJlZCBieSB0
aGUgV0cgYXMgaXNzdWUgIzEwIC0NCjxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn
L3dnL2pvc2UvdHJhYy90aWNrZXQvMTAiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pv
c2UvdHJhYy90aWNrZXQvMTA8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gdGhlIE9BdXRoIGNvbnRleHQsIEkg
a25vdyB0aGF0IGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucyBhbmQgZHJhZnQtaWV0Zi1vYXV0
aC1zYW1sMi1iZWFyZXIgd2VyZSBzZW50IHRvIHRoZSBJRVNHIGZvciByZXZpZXcgaW4gMjAxMiBh
bmQgdGhlbiBzZW50IGJhY2sNCiB0byB0aGUgT0F1dGggd29ya2luZyBncm91cCBieSB0aGUgSUVT
RyBiZWNhdXNlIHRoZXkgZmVsdCB0aGF0IGFkZGl0aW9uYWwgd29yayBuZWVkZWQgdG8gYmUgZG9u
ZSBvbiB0aGUgZHJhZnRzIHNvIHRoYXQgdGhleSB3b3VsZA0KPGI+PGk+YWN0dWFsbHk8L2k+PC9i
PiBiZSBpbnRlcm9wZXJhYmxlIOKAkyBub3QganVzdCB0aGF0IGl0IHdhcyBwb3NzaWJsZSBmb3Ig
aW1wbGVtZW50YXRpb25zIHRvIGludGVyb3BlcmF0ZS4mbmJzcDsgU3RlcGhlbiBGYXJyZWxsIGNv
dWxkIHBlcmhhcHMgc3BlYWsgbW9yZSB0byB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhdCBjbGVhciBzZW50
aW1lbnQgZnJvbSB0aGUgSUVTRyB0byB0aGUgT0F1dGggV0cgaGFzIGFsc28gaW5mb3JtZWQgdGhl
IGRlY2lzaW9ucyBmb3IgdGhlIEpXVCBhbmQgSk9TRSBzcGVjcyB0byBrZWVwIGEgc21hbGwgc2V0
IG9mIE1USSBhbGdvcml0aG1zIHNvIHRoYXQNCiBpbXBsZW1lbnRhdGlvbnMgd291bGQgYWN0dWFs
bHkgaGF2ZSBhIGNvbW1vbiBiYXNpcyB0byBpbnRlcm9wZXJhdGUuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JRVNHIGZl
ZWRiYWNrIG9uIHJlcXVpcmluZyBpbnRlcm9wZXJhYmlsaXR5IHdhcyByZWZlcmVuY2VkIGJ5IEpp
bSBTY2hhYWQgaW4gaGlzIHRleHQgY2xvc2luZyB0aGUgaXNzdWU6PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5UaGUgSUVTRyBoYXMgaGFkIGEg
ZGlzY3Vzc2lvbiBvbiB0aGlzIGlzc3VlIGFzIHBhcnQgb2YgdGhlIHJlY2VudCBjaGFydGVyIGRp
c2N1c3Npb25zLiBUaGUgY2hhaXJzIGJlbGlldmUgdGhhdCBpcyBpcyBjbGVhciBmcm9tIHRoYXQg
ZGlzY3Vzc2lvbnMgdGhhdCBNVEkgYWxnb3JpdGhtcyBhcmUNCiBnb2luZyB0byBiZSByZXF1aXJl
ZCBpbiBvcmRlciBmb3IgdGhlIGRvY3VtZW50cyB0byBwcm9ncmVzcy4gRm9yIHRoYXQgcmVhc29u
IHdlIGFyZSBjbG9zaW5nIHRoaXMgdGlja2V0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu
MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxi
Pk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1
bmUgMTMsIDIwMTQgMTI6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+IEthdGhsZWVuIE1vcmlhcnR5OyBI
YW5uZXMgVHNjaG9mZW5pZzxicj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gSldUIHJldmlldzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5JbiBubyBwbGFjZSBpcyBTSEEtMSBvciBhbGdvcml0aG1zIHVzaW5nIGl0
IE1USS4mbmJzcDsgWW91IGNhbiBzZWUgdGhlIHNldCBvZiBNVEkgYWxnb3JpdGhtcyBieSBsb29r
aW5nIGF0IHRob3NlIG1hcmtlZCDigJxSZXF1aXJlZOKAnSBpbiB0aGUgcmVnaXN0cmllcy48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPkEgc21hbGwgc2V0IG9mIHJlcXVpcmVkIGFsZ29yaXRobXMgaXMgcHJlc2VudCwgd2l0
aCB0aGUgY2hvaWNlcyBiYXNlZCBvbiBhIGRldGFpbGVkIHN1cnZleSBvZiB3aGF0IGFsZ29yaXRo
bXMgYXJlIHdpZGVseSBkZXBsb3llZCwgdG8gcHJvdmlkZSBhIGJhc2lzIGZvciBpbXBsZW1lbnRh
dGlvbnMNCiB0byBpbnRlcm9wZXJhdGUuJm5ic3A7IFJlY29nbml6aW5nIHRoYXQgdGhlIHNldCBv
ZiBhbGdvcml0aG1zIHRoYXQgd2lsbCBiZSBhcHByb3ByaWF0ZSB0byBoYXZlIGFzIHJlcXVpcmVk
IHdpbGwgY2hhbmdlIG92ZXIgdGltZSwgU2VhbiBUdXJuZXIgc3VnZ2VzdGVkIHRoYXQgd2UgZW5h
YmxlIGZ1dHVyZSBkcmFmdHMgdG8gdXBkYXRlIHRoZSBJbXBsZW1lbnRhdGlvbiBSZXF1aXJlbWVu
dHMgaW4gdGhlIHJlZ2lzdHJpZXMsIHdpdGggZXhwZXJ0IHJldmlldy4mbmJzcDsNCiAoU28gZm9y
IGluc3RhbmNlLCBhbiBhbGdvcml0aG0gdGhhdCBtaWdodCBiZSDigJxSZXF1aXJlZOKAnSB0b2Rh
eSBjb3VsZCBiZSBtYXJrZWQg4oCcRGVwcmVjYXRlZOKAnSBpbiB0aGUgZnV0dXJlLikmbmJzcDsg
V2UgYWRvcHRlZCBTZWFu4oCZcyBzdWdnZXN0aW9uIGEgZ29vZCB3aGlsZSBhZ28uPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5UaGlzIGlzIGFub3RoZXIgYXJlYSB0aGF0IHdhcyB3aWRlbHkgZGlzY3Vzc2VkIHdpdGhpbiB0
aGUgSk9TRSB3b3JraW5nIGdyb3VwLCBhbmQgdGhlcmUgd2FzIG5ldmVyIGNvbnNlbnN1cyB0byBy
ZW1vdmUgdGhlIGltcGxlbWVudGF0aW9uIHJlcXVpcmVtZW50cywgd2hpY2gNCiBoYXZlIGFsd2F5
cyBiZWVuIHByZXNlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggWzxhIGhyZWY9Im1haWx0bzpv
YXV0aC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5d
DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkthdGhsZWVuIE1vcmlhcnR5PGJyPg0KPGI+U2VudDo8L2I+
IEZyaWRheSwgSnVuZSAxMywgMjAxNCAxMjoxNCBQTTxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRz
Y2hvZmVuaWc8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+
b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEpX
VCByZXZpZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBIYW5uZXMs
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3Ug
Zm9yIGdvaW5nIHRocm91Z2ggdGhlIHZhcmlvdXMgcmV2aWV3cywgc2luY2UgdGhlIEpPU0Ugb25l
cyBzaG91bGQgYmUgb2YgaW50ZXJlc3QgdG8gT2F1dGguICZuYnNwO0knbGwgcmVzcG9uZCBpbi1s
aW5lLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdW4gMTIsIDIwMTQgYXQgNDoyNyBBTSwgSGFubmVzIFRz
Y2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0IiB0
YXJnZXQ9Il9ibGFuayI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgS2F0aGxlZW4sPGJyPg0KPGJy
Pg0Kb24gdGhlIGZpcnN0IGl0ZW0gSSBoYXZlIGEgZmV3IG1pbm9yIHJlbWFya3M6IFlvdSB3cm90
ZTo8YnI+DQo8YnI+DQomcXVvdDs8YnI+DQpBcyBJIHJlYWQgdGhyb3VnaCB0aGUgQWxnb3JpdGht
cyAoSldBKSBkcmFmdCB0aGVyZSBhcmUgc29tZSBjaGFuZ2VzIHRoYXQ8YnI+DQp3aWxsIG5lZWQg
dG8gYmUgbWFkZSB0byBhdm9pZCBwcm9ibGVtcyBkdXJpbmcgdGhlIElFU0cgcmV2aWV3LiAmbmJz
cDtUaGlzIGlzPGJyPg0KYSBwcmV0dHkgYmlnIGNoYW5nZSBmb3IgdGhlIGRyYWZ0LCBidXQgd2ls
bCBoZWxwIG1ha2UgdGhlIHJldmlldyBhbmQ8YnI+DQphcHByb3ZhbCBmYXN0ZXIuICZuYnNwO1R5
cGljYWxseSwgdGhlIGxpc3RzIG9mIGFsZ29yaXRobXMgYXJlIGhhbmRsZWQgdGhyb3VnaDxicj4N
CmEgZHJhZnQgdXBkYXRlIGFzIG9wcG9zZWQgdG8gY3JlYXRpbmcgYW4gSUFOQSByZWdpc3RyeS4g
Jm5ic3A7QSBnb29kIGV4YW1wbGU8YnI+DQppcyBhIHJlY2VudCB1cGRhdGUgb2YgYSBkcmFmdCBp
biB0aGUgSVBTRUNNRSB3b3JraW5nIGdyb3VwIHNvIHlvdSBjYW48YnI+DQpzZWUgdGhlIHN0cnVj
dHVyZSBhbmQgdGhlIHByZWNlZGVuY2UgZm9yIHRoaXMgbW9kZWwuPGJyPg0KJnF1b3Q7PG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RllJIC0gdGhpcyBpcyBmcm9t
IHRoZSBzdGFydCBvZiBhIGxvbmcgdGhyZWFkIHRoYXQgaGFzIGJlZW4gd29ya2VkIG91dCBhbHJl
YWR5LiAmbmJzcDtJIGhhZCBpbmNsdWRlZCBhIGxpbmsgdG8gdGhlIEpXQSByZXZpZXcgb25seSBm
b3IgdGhlIHNlY3Rpb24gb24gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb3NuIHNlY3Rpb24gYXMg
bWFueSBvZiB0aGUgZHJhZnRzIGluIEpPU0UsIGFuZCBhdCBsZWFzdCBvbmUgaW4gT0F1dGgNCiBz
dGFydCBvdXQgd2l0aCB0aGUgc2FtZSBwYXJhZ3JhcGggdGhhdCBjb3VsZCB1c2Ugc29tZSB1cGRh
dGluZyBhbmQgY29ycmVjdGluZy4gJm5ic3A7SSB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoaXMgd29y
a2luZyBncm91cCB3YXMgYXdhcmUgc2luY2UgSldUIHNoYXJlcyB0aGF0IHNhbWUgcGFyYWdyYXBo
LiAmbmJzcDtNaWtlIGlzIHdvcmtpbmcgdGhyb3VnaCBuZXcgdGV4dCBhbmQgaGFzIHNvbGljaXRl
ZCBoZWxwIGZyb20gdGhlIFdHIChwbGVhc2UgcmVzcG9uZCBvbg0KIHRoZSBKT1NFIGxpc3QpLiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu
MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZSBJQU5B
IHJlZ2lzdHJ5IGZvciB0aGUgYWxnb3JpdGhtIHNlcnZlcyBhIGRpZmZlcmVudCBwdXJwb3NlIHRo
YW4gYTxicj4NCmRvY3VtZW50IHJlY29tbWVuZGluZyB0aGUgc3BlY2lmaWMgYWxnb3JpdGhtcy4g
VGhlIHJlZmVyZW5jZSB0byB0aGU8YnI+DQpJUFNFQ01FIGRvY3VtZW50IG9ubHkgcHJvdmlkZXMg
dGhlIGxhdHRlci4gSXQgaXMgYWxzbyBpbXBvcnRhbnQgdG8gbm90ZTxicj4NCnRoYXQgdGhlIEpX
QSBub3Qgb25seSBkZWZpbmVzIHRoZSBhbGdvcml0aG0gdGFncyBmb3IgdGhlIElBTkEgcmVnaXN0
cnk8YnI+DQpidXQgYWxzbyBleHBsYWlucyBob3cgdGhleSBhY3R1YWxseSB3b3JrIHdpdGggdGhl
IEpPU0UgZGVmaW5lZCBKU09OPGJyPg0Kc3RydWN0dXJlcyAod2hpY2ggaXMgYWdhaW4gYSBkaWZm
ZXJlbmNlIHRvIHRoZSBtZW50aW9uZWQgSVBTRUNNRSBkb2N1bWVudCkuPG86cD48L286cD48L3A+
DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRpc2N1c3Np
b24gb24gaGF2aW5nIGEgcmVnaXN0cnkgdmVyc3VzIGEgZHJhZnQgaGFzIGJlZW4gc2V0dGxlZC4g
Jm5ic3A7VGhlIHBvc3NpYmlsaXR5IG9mIGFuIGlzc3VlIGNhbWUgdG8gbWUgdGhyb3VnaCBhbiBB
RCBhbmQgYWZ0ZXIgZGlzY3Vzc2lvbiwgaXQgaXMgZmluZSBhcyBpdCBpcy4gJm5ic3A7VGhlcmUg
d2VyZSBzb21lIGNvbnNpZGVyYXRpb25zIHRoYXQgbmVlZGVkIHRvIGdldCBzdXJmYWNlZCwgc28g
dGhlIGRvY3VtZW50DQogY2FuIHJlbWFpbiBhcy1pcy4gJm5ic3A7U29ycnkgZm9yIHRoZSBjb25m
dXNpb24uICZuYnNwO0knbGwgZmlsZSB0aGlzIGF3YXkgZm9yIHRoZSBmdXR1cmUgcmVmZXJlbmNl
LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu
IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp
bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9mIGNv
dXJzZSwgdGhlIEpXQSBkb2N1bWVudCBkb2VzIGJvdGggdmlhIHRoZSBJQU5BIHJlZ2lzdHJ5IGFu
ZCB0aGVyZSBpczxicj4NCnRoZSBxdWVzdGlvbiBhYm91dCBob3cgdGhlc2UgcmVjb21tZW5kYXRp
b25zIHdvdWxkIHRoZW4gZ2V0IHVwZGF0ZWQgYW5kPGJyPg0Kd2hhdCB0aGUgY29uc2Vuc3VzIHBy
b2Nlc3MgaXMuPGJyPg0KPGJyPg0KSW4gYW4gbWFpbCB0byB0aGUgSk9TRSBtYWlsaW5nIGxpc3Qg
SSBhcmd1ZWQgYWdhaW5zdCBhbnkgTVRJPGJyPg0KcmVjb21tZW5kYXRpb25zIHNpbmNlIEpPU0Ug
aXMgYSBiYXNlbGluZSB0ZWNobm9sb2d5IHRoYXQgd2lsbCBiZSB1c2VkIGluPGJyPg0KYSB2YXJp
ZXR5IG9mIGRpZmZlcmVudCBjb250ZXh0cyBhbmQgaXQgaXMgc3VwZXIgbGlrZWx5IHRoYXQgdGhl
PGJyPg0KYWxnb3JpdGhtIHJlcXVpcmVtZW50cyB3aWxsIGh1Z2VseSB2YXJ5Ljxicj4NCjxicj4N
CkkgYW0ganVzdCB0aGlua2luZyBhYm91dCB3aGF0IGFsZ29yaXRobXMgSSB3b3VsZCByZWNvbW1l
bmQgd2hlbiB1c2luZzxicj4NCnRoZSBKT1NFIHdvcmsgaW4gYW4gSW9UIGVudmlyb25tZW50LiBN
eSByZWNvbW1lbmRhdGlvbnMgd291bGQgZGV2aWF0ZTxicj4NCmZyb20gdGhlIGN1cnJlbnRseSBn
aXZlbiByZWNvbW1lbmRhdGlvbnMsIHdoaWNoIGFyZSBsYXJnZWx5IGltcGFjdGVkIGJ5PGJyPg0K
dGhlIFdlYiBjb21tdW5pdHkuPGJyPg0KPGJyPg0KSGVyZSBpcyB0aGUgbWFpbCBJIHNlbnQgdG8g
dGhlIEpPU0UgbGlzdDo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj
aGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzA0MDMyLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRw
Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzA0MDMyLmh0
bWw8L2E+PGJyPg0KPGJyPg0KU28sIG15IHJlY29tbWVuZGF0aW9uIGlzIHRvPGJyPg0KPGJyPg0K
MSkgaGF2ZSBubyBNVEkgcmVxdWlyZW1lbnRzIGluIHRoZSBKV0Egc3BlYzxicj4NCjIpIHJlbW92
ZSB0aGUgJ0pPU0UgSW1wbGVtZW50YXRpb24gUmVxdWlyZW1lbnRzJyBjb2x1bW4gZnJvbSB0aGUg
SUFOQTxicj4NCnJlZ2lzdHJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW50ZXJlc3RpbmcuICZuYnNwOyBJIGRvIHJlbWVtYmVy
IGhhdmluZyB0aGVzZSBkaXNjdXNzaW9ucyB3aXRoIFNlYW4gYW5kIFJpY2hhcmQgKHNlZSZuYnNw
OzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJl
bnQvbXNnMDQwNjAuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pv
c2UvY3VycmVudC9tc2cwNDA2MC5odG1sPC9hPikuICZuYnNwO0luIEppbSdzIG9waW5pb24sDQog
KGZyb206IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3Nl
L2N1cnJlbnQvbXNnMDQwNjIuaHRtbCI+DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2
ZS93ZWIvam9zZS9jdXJyZW50L21zZzA0MDYyLmh0bWw8L2E+KSwgaGlzIHZpZXcgaXMgdGhhdCBl
dmVuIHRoZSBNVEkgaW4gSldBIGNhbiBiZSBvdmVycmlkZGVuIGluIHRoZSBzcGVjLiAmbmJzcDtJ
IHdvbmRlciB3aHkgeW91IHdvdWxkIGhhdmUgYW4gTVRJIHRoZW4/PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgY2xvc2VkIG91dCB0aGUg
ZGlzY3Vzc2lvbiBhbmQgaXQgd291bGQgYmUgYmV0dGVyIHRvIHNlZSBpdCBvbiB0aGUgSk9TRSBs
aXN0IHRoYW4gaGVyZS4gJm5ic3A7SWYgdGhlIHBvaW50IGlzIHRvIGdldCBPYXV0aCBwZW9wbGUg
d2hvIGFyZSBlbmNvdW50ZXJpbmcgY29uZmxpY3RzIGFzIGEgdXNlciBvZiBKT1NFIGRyYWZ0cyB0
byBjaGltZSBpbiwgdGhhdCBzaG91bGQgaGFwcGVuIG9uIHRoZSBKT1NFIGxpc3QuICZuYnNwO0kN
CiBzdXNwZWN0IHRoaXMgd2lsbCBiZSBhbiBpc3N1ZSBmb3IgWE1QUCBhcyB3ZWxsLiAmbmJzcDtU
aGV5IGFyZSBwaGFzaW5nIG91dCBTSEEtMSwgc28gaWYgdGhhdCdzIE1USSBmb3IgZmluZ2VycHJp
bnRzLCB0aGV5IG1heSBzdGlsbCBmZWVsIGxpa2UgdGhleSBoYXZlIHRvIHN1cHBvcnQgU0hBLTEg
Zm9yIHRoYXQgcHVycG9zZSBldmVuIHRob3VnaCB0aGVpciB3b3JrIHNwZWNpZmllcyB0aGF0IFNI
QS0yIHNob3VsZCBiZSB1c2VkIGV2ZXJ5d2hlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbmNlIEpXQSBpcyBnZXR0aW5nIGNsb3NlciB0
byBJRVNHIHJldmlldywgSSdsbCBhc2sgb3RoZXIgQURzIHRoZWlyIHRob3VnaHRzIG9uIGhvdyB0
aGV5IGxpa2UgdG8gc2VlIHRoaXMgc29ydCBvZiB0aGluZyBoYW5kbGVkLiAmbmJzcDtCb3RoIFJp
Y2hhcmQgYW5kIEppbSByYWlzZWQgdmFsaWQgcG9pbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UsPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LYXRobGVlbiAmbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn
aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpDaWFvPGJyPg0KSGFubmVz
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N
Cjxicj4NCk9uIDA2LzA5LzIwMTQgMDY6MTcgUE0sIEthdGhsZWVuIE1vcmlhcnR5IHdyb3RlOjxi
cj4NCiZndDsgSGVsbG8sPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBhbSBpbiBwcm9jZXNzIG9mIHdv
cmtpbmcgdGhyb3VnaCB0aGUgSk9TRSBkcmFmdHMgYW5kIGFsc28gcmVhZCB0aGU8YnI+DQomZ3Q7
IE9hdXRoIEpXVCBkcmFmdCBsYXN0IHdlZWsuICZuYnNwO1RoZXJlIGlzIHNvbWUgb3ZlcmxhcCBp
biB0ZXh0IHRoYXQgbWF5PGJyPg0KJmd0OyByZXF1aXJlIHNvbWUgam9pbnQgd29yayB0byBjb3Jy
ZWN0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IDEuIEZvciBKV1QsIHRoZSBTZWN1cml0eSBDb25zaWRl
cmF0aW9ucyBzZWN0aW9uIHN0YXJ0cyBvZmYgd2l0aCB0aGUgc2FtZTxicj4NCiZndDsgdGV4dCB0
aGF0IGlzIGluIHNldmVyYWwgb2YgdGhlIEpPU0UgZHJhZnRzLiAmbmJzcDtJbiBteSByZXZpZXcg
b2YgdGhlIEpXQTxicj4NCiZndDsgZHJhZnQsIEkgYXNrZWQgZm9yIHNvbWUgZml4ZXMgdGhhdCB3
aWxsIG5lZWQgdG8gYmUgbWFkZSB0byB0aGlzIGRyYWZ0IGFzPGJyPg0KJmd0OyB3ZWxsLiAmbmJz
cDtIZXJlIGlzIGEgbGluayB0byB0aGF0IHJldmlldyBhbmQgaXQgbWF5IGJlIGVhc2llciB0byBo
ZWxwIHdpdGg8YnI+DQomZ3Q7IHRoaXMgd29yayBpbiBvbmUgc3BvdCB3aGVyZSB0ZXh0IHdpbGwg
YmUgcmV1c2VkLiAmbmJzcDtNaWtlIGhhcyBhc2tlZCB0aGU8YnI+DQomZ3Q7IEpPU0UgV0cgdG8g
YXNzaXN0LCBidXQgaXQgbWFrZSBtYWtlIHNlbnNlIGZvciBPYXV0aCBmb2xrcyB0byBoZWxwIGFz
PGJyPg0KJmd0OyB3ZWxsLiAmbmJzcDtJZiBpdCBtYWtlcyBzZW5zZSwgYSBwb2ludGVyIHRvIGV4
aXN0aW5nIHRleHQgaXMgYWxzbyBmaW5lLjxicj4NCiZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0
dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQwNjQu
aHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv
d2ViL2pvc2UvY3VycmVudC9tc2cwNDA2NC5odG1sPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IDIu
IFNlY3Rpb25zIDUuMSBhbmQgNS4yIGFyZSBhIGxpdHRsZSBjb25mdXNpbmcuICZuYnNwO0hvd2V2
ZXIsIHRoZSB1c2Ugb2Y8YnI+DQomZ3Q7ICZxdW90O3R5cCZxdW90OyBhbmQgJnF1b3Q7Y3R5JnF1
b3Q7IGFwcGVhciBpbiAzIGRyYWZ0cyAoYXQgbGVhc3QpLCBzbyB0aGlzIHNob3VsZCBnZXQ8YnI+
DQomZ3Q7IGFkZHJlc3NlZCB3aXRoIGFuIGFwcHJvYWNoIHRoYXQgY29uc2lkZXJzIHRoZSBqb2lu
dCB0ZXh0IHRvIHJlZHVjZTxicj4NCiZndDsgY29uZnVzaW9uIGZvciBkZXZlbG9wZXJzLiAmbmJz
cDtUaGUgaW5pdGlhbCBkZXNjcmlwdGlvbnMgYXJlIGluIHRoZSBKT1NFIEpXUzxicj4NCiZndDsg
ZHJhZnQsIHNvIHRoYXQgbWF5IG5lZWQgbW9zdCBvZiB0aGUgd29yaywgYnV0IGl0IGFsc28gYXBw
ZWFycyBpbiB0aGlzPGJyPg0KJmd0OyBkcmFmdCBhbmQgdGhlIEpPU0UgSldLIGRyYWZ0LiAmbmJz
cDtJbiBteSB3cml0ZXVwIGZvciB0aGUgSldLIHJldmlldywgSTxicj4NCiZndDsgbGlzdGVkIG91
dCBzb21lIHF1ZXN0aW9ucyBhbmQgd291bGQgbGlrZSB0byBzZWUgaW1wcm92ZW1lbnRzIGFjcm9z
czxicj4NCiZndDsgdGhlc2UgZHJhZnRzLiAmbmJzcDtUaGlzIHdpbGwgbGlrZWx5IHJlcXVpcmUg
c29tZSBqb2ludCB3b3JrIGFuZCBtYXkgYmUgYmVzdDxicj4NCiZndDsgaW4gcmVzcG9uc2UgdG8g
dGhlIEpXSyByZXZpZXcgdG8ga2VlcCBpdCBpbiBvbmUgcGxhY2UuPGJyPg0KJmd0Ozxicj4NCiZn
dDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3Vy
cmVudC9tc2cwNDE3Mi5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3Jn
L21haWwtYXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzA0MTcyLmh0bWw8L2E+PGJyPg0KJmd0
Ozxicj4NCiZndDsgVGhhbmsgeW91ITxicj4NCiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0Ozxi
cj4NCiZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsgS2F0aGxlZW48YnI+DQomZ3Q7PGJyPg0K
Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJy
Pg0KJmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9h
Pjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2F0aGxlZW48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_4E1F6AAD24975D4BA5B16804296739439AD6D431TK5EX14MBXC292r_--


From nobody Fri Jun 13 13:07:38 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20111B2A2B for ; Fri, 13 Jun 2014 13:07:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6wTezDLZSig for ; Fri, 13 Jun 2014 13:07:33 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416221A023A for ; Fri, 13 Jun 2014 13:07:32 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id p9so1778213lbv.7 for ; Fri, 13 Jun 2014 13:07:31 -0700 (PDT)
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=FxdfcfYIqV1o7uXEDga1BdO5SUsT1eqAEokSHloUeFc=; b=Yk9zj/42ltE4Dt2+YuF5xmN8UNMx/2gfWvBs3+cY1nvJZMuWBldqgNLswws0Y/bwkU KbbR4Y2PbLrTPbzV/2hQ55nZKPHVPjF5xsiUCpuhQbdEkSEr2Zy3EQ7aLpmVTV4vBj7o HQbFdRYBTJzljQNxtk6HvtT+YBSK+DsW61cRgdLzzRtTPdarG5HC8P5Z+YJSLdF9BwIL 8CWkE9xFnsJbSggGswyoENgzDOxnPjxTx85EgTXtLMeF6F539R7mZFeO5gARS1qghH9c nJzruh38UIQcH45Oe0ImwBoi8XWo5dhjsCjgXTKebWNhbpGObXiF8j72maIQN9fevqvM yrfg==
MIME-Version: 1.0
X-Received: by 10.152.36.99 with SMTP id p3mr2800001laj.61.1402690051283; Fri, 13 Jun 2014 13:07:31 -0700 (PDT)
Received: by 10.112.33.36 with HTTP; Fri, 13 Jun 2014 13:07:31 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD6D431@TK5EX14MBXC292.redmond.corp.microsoft.com>
References:  <53996461.7080507@gmx.net>  <4E1F6AAD24975D4BA5B16804296739439AD6D0D8@TK5EX14MBXC292.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AD6D431@TK5EX14MBXC292.redmond.corp.microsoft.com>
Date: Fri, 13 Jun 2014 16:07:31 -0400
Message-ID: 
From: Kathleen Moriarty 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=089e0158b7903c9ff304fbbd3a59
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/pgZfcJtQtmjV1kg3tP4y2IdZkQk
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] JWT review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 20:07:36 -0000

--089e0158b7903c9ff304fbbd3a59
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks, Mike.  I've sent out a question to get the viewpoint of the current
IESG members in hopes to prevent issues as we move forward.  I'll post back
to the discussion once I get enough input on current preferences in case
anything has changed from experience, etc.


On Fri, Jun 13, 2014 at 4:04 PM, Mike Jones 
wrote:

>  This was considered by the WG as issue #10 -
> http://trac.tools.ietf.org/wg/jose/trac/ticket/10.
>
>
>
> In the OAuth context, I know that draft-ietf-oauth-assertions and
> draft-ietf-oauth-saml2-bearer were sent to the IESG for review in 2012 an=
d
> then sent back to the OAuth working group by the IESG because they felt
> that additional work needed to be done on the drafts so that they would
> *actually* be interoperable =E2=80=93 not just that it was possible for
> implementations to interoperate.  Stephen Farrell could perhaps speak mor=
e
> to that.
>
>
>
> That clear sentiment from the IESG to the OAuth WG has also informed the
> decisions for the JWT and JOSE specs to keep a small set of MTI algorithm=
s
> so that implementations would actually have a common basis to interoperat=
e.
>
>
>
> IESG feedback on requiring interoperability was referenced by Jim Schaad
> in his text closing the issue:
>
> The IESG has had a discussion on this issue as part of the recent charter
> discussions. The chairs believe that is is clear from that discussions th=
at
> MTI algorithms are going to be required in order for the documents to
> progress. For that reason we are closing this ticket.
>
>
>
>                                                             -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Mike Jones
> *Sent:* Friday, June 13, 2014 12:27 PM
> *To:* Kathleen Moriarty; Hannes Tschofenig
>
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] JWT review
>
>
>
> In no place is SHA-1 or algorithms using it MTI.  You can see the set of
> MTI algorithms by looking at those marked =E2=80=9CRequired=E2=80=9D in t=
he registries.
>
>
>
> A small set of required algorithms is present, with the choices based on =
a
> detailed survey of what algorithms are widely deployed, to provide a basi=
s
> for implementations to interoperate.  Recognizing that the set of
> algorithms that will be appropriate to have as required will change over
> time, Sean Turner suggested that we enable future drafts to update the
> Implementation Requirements in the registries, with expert review.  (So f=
or
> instance, an algorithm that might be =E2=80=9CRequired=E2=80=9D today cou=
ld be marked
> =E2=80=9CDeprecated=E2=80=9D in the future.)  We adopted Sean=E2=80=99s s=
uggestion a good while ago.
>
>
>
> This is another area that was widely discussed within the JOSE working
> group, and there was never consensus to remove the implementation
> requirements, which have always been present.
>
>
>
>                                                             -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O=
n
> Behalf Of *Kathleen Moriarty
> *Sent:* Friday, June 13, 2014 12:14 PM
> *To:* Hannes Tschofenig
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] JWT review
>
>
>
> Hi Hannes,
>
>
>
> Thank you for going through the various reviews, since the JOSE ones
> should be of interest to Oauth.  I'll respond in-line.
>
>
>
> On Thu, Jun 12, 2014 at 4:27 AM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
>
> Hi Kathleen,
>
> on the first item I have a few minor remarks: You wrote:
>
> "
> As I read through the Algorithms (JWA) draft there are some changes that
> will need to be made to avoid problems during the IESG review.  This is
> a pretty big change for the draft, but will help make the review and
> approval faster.  Typically, the lists of algorithms are handled through
> a draft update as opposed to creating an IANA registry.  A good example
> is a recent update of a draft in the IPSECME working group so you can
> see the structure and the precedence for this model.
> "
>
> FYI - this is from the start of a long thread that has been worked out
> already.  I had included a link to the JWA review only for the section on
> the security consideratiosn section as many of the drafts in JOSE, and at
> least one in OAuth start out with the same paragraph that could use some
> updating and correcting.  I wanted to make sure this working group was
> aware since JWT shares that same paragraph.  Mike is working through new
> text and has solicited help from the WG (please respond on the JOSE list)=
.
>
>
> The IANA registry for the algorithm serves a different purpose than a
> document recommending the specific algorithms. The reference to the
> IPSECME document only provides the latter. It is also important to note
> that the JWA not only defines the algorithm tags for the IANA registry
> but also explains how they actually work with the JOSE defined JSON
> structures (which is again a difference to the mentioned IPSECME document=
).
>
>  The discussion on having a registry versus a draft has been settled.
>  The possibility of an issue came to me through an AD and after discussio=
n,
> it is fine as it is.  There were some considerations that needed to get
> surfaced, so the document can remain as-is.  Sorry for the confusion.  I'=
ll
> file this away for the future reference.
>
>
> Of course, the JWA document does both via the IANA registry and there is
> the question about how these recommendations would then get updated and
> what the consensus process is.
>
> In an mail to the JOSE mailing list I argued against any MTI
> recommendations since JOSE is a baseline technology that will be used in
> a variety of different contexts and it is super likely that the
> algorithm requirements will hugely vary.
>
> I am just thinking about what algorithms I would recommend when using
> the JOSE work in an IoT environment. My recommendations would deviate
> from the currently given recommendations, which are largely impacted by
> the Web community.
>
> Here is the mail I sent to the JOSE list:
> http://www.ietf.org/mail-archive/web/jose/current/msg04032.html
>
> So, my recommendation is to
>
> 1) have no MTI requirements in the JWA spec
> 2) remove the 'JOSE Implementation Requirements' column from the IANA
> registry.
>
>
>
> Interesting.   I do remember having these discussions with Sean and
> Richard (see
> http://www.ietf.org/mail-archive/web/jose/current/msg04060.html).  In
> Jim's opinion, (from:
> http://www.ietf.org/mail-archive/web/jose/current/msg04062.html), his
> view is that even the MTI in JWA can be overridden in the spec.  I wonder
> why you would have an MTI then?
>
>
>
> This closed out the discussion and it would be better to see it on the
> JOSE list than here.  If the point is to get Oauth people who are
> encountering conflicts as a user of JOSE drafts to chime in, that should
> happen on the JOSE list.  I suspect this will be an issue for XMPP as wel=
l.
>  They are phasing out SHA-1, so if that's MTI for fingerprints, they may
> still feel like they have to support SHA-1 for that purpose even though
> their work specifies that SHA-2 should be used everywhere.
>
>
>
> Since JWA is getting closer to IESG review, I'll ask other ADs their
> thoughts on how they like to see this sort of thing handled.  Both Richar=
d
> and Jim raised valid points.
>
>
>
> Thank you,
>
> Kathleen
>
>
> Ciao
> Hannes
>
>
>
> On 06/09/2014 06:17 PM, Kathleen Moriarty wrote:
> > Hello,
> >
> > I am in process of working through the JOSE drafts and also read the
> > Oauth JWT draft last week.  There is some overlap in text that may
> > require some joint work to correct.
> >
> > 1. For JWT, the Security Considerations section starts off with the sam=
e
> > text that is in several of the JOSE drafts.  In my review of the JWA
> > draft, I asked for some fixes that will need to be made to this draft a=
s
> > well.  Here is a link to that review and it may be easier to help with
> > this work in one spot where text will be reused.  Mike has asked the
> > JOSE WG to assist, but it make make sense for Oauth folks to help as
> > well.  If it makes sense, a pointer to existing text is also fine.
> >
> > http://www.ietf.org/mail-archive/web/jose/current/msg04064.html
> >
> > 2. Sections 5.1 and 5.2 are a little confusing.  However, the use of
> > "typ" and "cty" appear in 3 drafts (at least), so this should get
> > addressed with an approach that considers the joint text to reduce
> > confusion for developers.  The initial descriptions are in the JOSE JWS
> > draft, so that may need most of the work, but it also appears in this
> > draft and the JOSE JWK draft.  In my writeup for the JWK review, I
> > listed out some questions and would like to see improvements across
> > these drafts.  This will likely require some joint work and may be best
> > in response to the JWK review to keep it in one place.
> >
> > http://www.ietf.org/mail-archive/web/jose/current/msg04172.html
> >
> > Thank you!
> >
> > --
> >
> > Best regards,
> > Kathleen
> >
> >
>
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>



--=20

Best regards,
Kathleen

--089e0158b7903c9ff304fbbd3a59
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks, Mike. =C2=A0I've sent out a question to get th=
e viewpoint of the current IESG members in hopes to prevent issues as we mo=
ve forward. =C2=A0I'll post back to the discussion once I get enough in=
put on current preferences in case anything has changed from experience, et=
c.




On Fri, Jun 1=
3, 2014 at 4:04 PM, Mike Jones <Michael.Jones@microsoft.com&=
gt; wrote:













This was considered by th=
e WG as issue #10 -
http://trac.tools.ietf.org/wg/jose/trac/ticket/10.


=C2=A0


In the OAuth context, I k=
now that draft-ietf-oauth-assertions and draft-ietf-oauth-saml2-bearer were=
 sent to the IESG for review in 2012 and then sent back
 to the OAuth working group by the IESG because they felt that additional w=
ork needed to be done on the drafts so that they would
actually be interoperable =E2=80=93 not just that it was poss=
ible for implementations to interoperate.=C2=A0 Stephen Farrell could perha=
ps speak more to that.


=C2=A0


That clear sentiment from=
 the IESG to the OAuth WG has also informed the decisions for the JWT and J=
OSE specs to keep a small set of MTI algorithms so that
 implementations would actually have a common basis to interoperate.=



=C2=A0


IESG feedback on requirin=
g interoperability was referenced by Jim Schaad in his text closing the iss=
ue:



The IESG has had a discussion on this issue as part of =
the recent charter discussions. The chairs believe that is is clear from th=
at discussions that MTI algorithms are
 going to be required in order for the documents to progress. For that reas=
on we are closing this ticket.<=
/u>



=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=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=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=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=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike


=C2=A0






From: OAuth [m=
ailto:oauth-bou=
nces@ietf.org]
On Behalf Of Mike Jones

Sent: Friday, June 13, 2014 12:27 PM

To: Kathleen Moriarty; Hannes Tschofenig


Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] JWT review






=C2=A0


In no place is SHA-1 or a=
lgorithms using it MTI.=C2=A0 You can see the set of MTI algorithms by look=
ing at those marked =E2=80=9CRequired=E2=80=9D in the registries.=




=C2=A0


A small set of required a=
lgorithms is present, with the choices based on a detailed survey of what a=
lgorithms are widely deployed, to provide a basis for implementations
 to interoperate.=C2=A0 Recognizing that the set of algorithms that will be=
 appropriate to have as required will change over time, Sean Turner suggest=
ed that we enable future drafts to update the Implementation Requirements i=
n the registries, with expert review.=C2=A0
 (So for instance, an algorithm that might be =E2=80=9CRequired=E2=80=9D to=
day could be marked =E2=80=9CDeprecated=E2=80=9D in the future.)=C2=A0 We a=
dopted Sean=E2=80=99s suggestion a good while ago.


=C2=A0


This is another area that=
 was widely discussed within the JOSE working group, and there was never co=
nsensus to remove the implementation requirements, which
 have always been present.


=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=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=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=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=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike


=C2=A0


From: OAuth [<=
a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">mailto:oauth-bou=
nces@ietf.org]
On Behalf Of Kathleen Moriarty

Sent: Friday, June 13, 2014 12:14 PM

To: Hannes Tschofenig

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] JWT review


=C2=A0




Hi Hannes,




=C2=A0






Thank you for going through the various reviews, sin=
ce the JOSE ones should be of interest to Oauth. =C2=A0I'll respond in-=
line.




=C2=A0<=
/p>



On Thu, Jun 12, 2014 at 4:27 AM, Hannes Tschofenig &=
lt;hannes.ts=
chofenig@gmx.net> wrote:


Hi Kathleen,



on the first item I have a few minor remarks: You wrote:



"

As I read through the Algorithms (JWA) draft there are some changes that
will need to be made to avoid problems during the IESG review. =C2=A0This i=
s

a pretty big change for the draft, but will help make the review and

approval faster. =C2=A0Typically, the lists of algorithms are handled throu=
gh

a draft update as opposed to creating an IANA registry. =C2=A0A good exampl=
e

is a recent update of a draft in the IPSECME working group so you can

see the structure and the precedence for this model.

"




FYI - this is from the start of a long thread that h=
as been worked out already. =C2=A0I had included a link to the JWA review o=
nly for the section on the security consideratiosn section as many of the d=
rafts in JOSE, and at least one in OAuth
 start out with the same paragraph that could use some updating and correct=
ing. =C2=A0I wanted to make sure this working group was aware since JWT sha=
res that same paragraph. =C2=A0Mike is working through new text and has sol=
icited help from the WG (please respond on
 the JOSE list).=C2=A0








The IANA registry for the algorithm serves a different purpose than a

document recommending the specific algorithms. The reference to the

IPSECME document only provides the latter. It is also important to note

that the JWA not only defines the algorithm tags for the IANA registry

but also explains how they actually work with the JOSE defined JSON

structures (which is again a difference to the mentioned IPSECME document).=







The discussion on having a registry versus a draft h=
as been settled. =C2=A0The possibility of an issue came to me through an AD=
 and after discussion, it is fine as it is. =C2=A0There were some considera=
tions that needed to get surfaced, so the document
 can remain as-is. =C2=A0Sorry for the confusion. =C2=A0I'll file this =
away for the future reference.=C2=A0








Of course, the JWA document does both via the IANA registry and there is
the question about how these recommendations would then get updated and

what the consensus process is.



In an mail to the JOSE mailing list I argued against any MTI

recommendations since JOSE is a baseline technology that will be used in
a variety of different contexts and it is super likely that the

algorithm requirements will hugely vary.



I am just thinking about what algorithms I would recommend when using

the JOSE work in an IoT environment. My recommendations would deviate

from the currently given recommendations, which are largely impacted by

the Web community.



Here is the mail I sent to the JOSE list:

http://www.ietf.org/mail-archive/web/jose/current/msg040=
32.html



So, my recommendation is to



1) have no MTI requirements in the JWA spec

2) remove the 'JOSE Implementation Requirements' column from the IA=
NA

registry.






=C2=A0






Interesting. =C2=A0 I do remember having these discu=
ssions with Sean and Richard (see=C2=A0http://www.ietf.o=
rg/mail-archive/web/jose/current/msg04060.html). =C2=A0In Jim's opi=
nion,
 (from: 
http://www.ietf.org/mail-archive/web/jose/current/msg04062.html), his v=
iew is that even the MTI in JWA can be overridden in the spec. =C2=A0I wond=
er why you would have an MTI then?






=C2=A0






This closed out the discussion and it would be bette=
r to see it on the JOSE list than here. =C2=A0If the point is to get Oauth =
people who are encountering conflicts as a user of JOSE drafts to chime in,=
 that should happen on the JOSE list. =C2=A0I
 suspect this will be an issue for XMPP as well. =C2=A0They are phasing out=
 SHA-1, so if that's MTI for fingerprints, they may still feel like the=
y have to support SHA-1 for that purpose even though their work specifies t=
hat SHA-2 should be used everywhere.







=C2=A0






Since JWA is getting closer to IESG review, I'll=
 ask other ADs their thoughts on how they like to see this sort of thing ha=
ndled. =C2=A0Both Richard and Jim raised valid points.






=C2=A0






Thank you,






Kathleen =C2=A0








Ciao

Hannes










On 06/09/2014 06:17 PM, Kathleen Moriarty wrote:

> Hello,

>

> I am in process of working through the JOSE drafts and also read the
> Oauth JWT draft last week. =C2=A0There is some overlap in text that ma=
y

> require some joint work to correct.

>

> 1. For JWT, the Security Considerations section starts off with the sa=
me

> text that is in several of the JOSE drafts. =C2=A0In my review of the =
JWA

> draft, I asked for some fixes that will need to be made to this draft =
as

> well. =C2=A0Here is a link to that review and it may be easier to help=
 with

> this work in one spot where text will be reused. =C2=A0Mike has asked =
the

> JOSE WG to assist, but it make make sense for Oauth folks to help as
> well. =C2=A0If it makes sense, a pointer to existing text is also fine=
.

>

> 
http://www.ietf.org/mail-archive/web/jose/current/msg04064.html

>

> 2. Sections 5.1 and 5.2 are a little confusing. =C2=A0However, the use=
 of

> "typ" and "cty" appear in 3 drafts (at least), so =
this should get

> addressed with an approach that considers the joint text to reduce

> confusion for developers. =C2=A0The initial descriptions are in the JO=
SE JWS

> draft, so that may need most of the work, but it also appears in this<=
br>
> draft and the JOSE JWK draft. =C2=A0In my writeup for the JWK review, =
I

> listed out some questions and would like to see improvements across
> these drafts. =C2=A0This will likely require some joint work and may b=
e best

> in response to the JWK review to keep it in one place.

>

> 
http://www.ietf.org/mail-archive/web/jose/current/msg04172.html

>

> Thank you!

>

> --

>

> Best regards,

> Kathleen

>

>






> ________________=
_______________________________

> OAuth mailing list

> OAuth@ietf.org=


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

>















=C2=A0




-- 




=C2=A0




Best regards,






Kathleen




















-- 

Best regards,
Kathleen




--089e0158b7903c9ff304fbbd3a59--


From nobody Fri Jun 13 14:24:11 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1CF1B2A58 for ; Fri, 13 Jun 2014 14:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level: 
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtHz3kMC3EVJ for ; Fri, 13 Jun 2014 14:24:07 -0700 (PDT)
Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949141B2A59 for ; Fri, 13 Jun 2014 14:24:07 -0700 (PDT)
Received: from mail-ig0-f177.google.com ([209.85.213.177]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKU5tr98sXdG37Dtd32JLwBb5nNKJyKkuw@postini.com; Fri, 13 Jun 2014 14:24:07 PDT
Received: by mail-ig0-f177.google.com with SMTP id l13so1009223iga.10 for ; Fri, 13 Jun 2014 14:24:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rogl6LkRI717bt02U02dpGPe/B1jv/U7fochpiT+i2E=; b=E+6CqdJ+HLDOgnAJmioSgf7UZu/WY5plYEksiiQoX7ERNcpVfiQr4gt1W7U/vh+bjH 7m5KPHvU0p7fCwabkOw4PsxUBEZlavtaX/Ayxb2/PkSezZvPj1BZK8fhInK2GsAP2RQS u9VSqjRRic2f/83fLIQhXaL+r31v4E5l2vy5doOefl3tKp4khy3Px1XFUgjRgjikgNFC KH5qx64VDw8WXk7pHClZhvRg4g30FIVe2g9NE8sBtgRAshC/kgJDuM5xJO5wB/y58OA2 iRknzOtskR3NyltIjNKboRR6op/26yJZTpUz5I7q6zK7UosnS79fzjG7wkzV6LuIx/RM DXEg==
X-Gm-Message-State: ALoCoQk0a1w6SI6cjU+vWQ9KwWh/w5loONmb7mL2p2TLiNGxiy4qasmIZ34DWtIe9NNGQdWYwF8DDhYCan0Wyxk2DpZPeqdyZRxaHcsFASuLqw4fy+CuB/Ca3itnVmbesV1LpChcjH6p
X-Received: by 10.50.80.50 with SMTP id o18mr8133990igx.40.1402694646880; Fri, 13 Jun 2014 14:24:06 -0700 (PDT)
X-Received: by 10.50.80.50 with SMTP id o18mr8133982igx.40.1402694646784; Fri, 13 Jun 2014 14:24:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.240.193 with HTTP; Fri, 13 Jun 2014 14:23:36 -0700 (PDT)
In-Reply-To: <7082F35E-422C-441F-BBE8-158E4A9BA085@ve7jtb.com>
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <539A0FB1.1020106@pingidentity.com> <13F2E738-49BB-4EDB-9070-5A49448A6249@ve7jtb.com> <539B345A.7060808@redhat.com> <7082F35E-422C-441F-BBE8-158E4A9BA085@ve7jtb.com>
From: Brian Campbell 
Date: Fri, 13 Jun 2014 15:23:36 -0600
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=089e0149cef62675b604fbbe4cb4
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/iy0c5sa4Cm9U4Gx7yRM_kZ0L54E
Cc: oauth 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 21:24:10 -0000

--089e0149cef62675b604fbbe4cb4
Content-Type: text/plain; charset=UTF-8

I agree that, at this point, debating the details of a4c is premature.
SSO/authentication are not part of the WG charter and, as I've said before,
I'd object to changing the charter to include it. Other than a small but
vocal minority, I think it's fair to say that that's also been the
prevailing sentiment of this group.


On Fri, Jun 13, 2014 at 1:43 PM, John Bradley  wrote:

> Hi Anil,
>
> There are a number of profile efforts being looked at in the OIDF.   The
> Mobile Network operators lead by the GSMA are starting profile work on a
> standard profile that will be supported by mobile operators globally, that
> includes looking at how a Client/RP/SP can register there client once for
> use across multiple IdP AS, as well as standardized LoA and user-info
> schema extensions.
>
> Torsten Lodderstedt is the chair of that effort and can chime in.
>
> I suspect that a Basic IdP for SSO profile is significantly less ambitious
> than that and could be done in the current Connect WG.
>
> If there is interest from the members to start it.   The main time
> blocking factor might be getting a new grant_type spec approved in the the
> OAuth WG if we wanted to support that.
>
> The IdP profile is simple they can publish a discovery document saying
> they only support that that limited feature set, that way they would also
> be compatible with existing connect clients.
>
> {
> "scopes_supported": ["openid"],
> "response_types_supported":["code"],
> "response_modes_supported":["query"],
> "grant_types_supported":["authorization_code", "code_id_token_only"],
> "acr_values_supported":["2","3"]
> }
>
> They don't need to publish one if they don't intend to be discoverable to
> clients but knowing what the path forward to supporting generic client is
> helpful I think.
>
> Everything exists now other than the new grant_type exists now.
>
> The work would mostly be putting together the examples based on supporting
> a minimal flow.
>
> Now I should point out that there are people who believe that the default
> flow should be implicit with the "id_token" response_type and intend to
> support that.
> Phil's draft concentrates on only one use case.   Having a IdP deployment
> profile for it is not a problem, but it will not be for every IdP.   That
> is one of the reasons why discovery and registration are important features
> of Connect.
>
> John B.
>
>
> On Jun 13, 2014, at 1:26 PM, Anil Saldhana 
> wrote:
>
> > On 06/12/2014 04:18 PM, John Bradley wrote:
> >> All but a handful of OAuth WG participants participated in developing
> OpenID Connect.
> >>
> >> Yes some companies chose not to participate for whatever reasons and
> have not committed to the mutual non assert IPR agreement, and that is
> unfortunate, but not a reason to start again from scratch.
> >>
> >> Changing the OIDF IPR policy of totally open specifications based on
> non asserts is also not a option.
> >>
> >> I have made comments on the current draft of a4c.
> >>
> >> I think a profile of Connect introducing a grant_type returning only an
> id_token would be simpler than trying to do this as a separate spec.
> >> I do note that you can do effectively the same thing now by using a
> code response_type and a scope of openID.   This doesn't result in any
> extra user consent other than consenting to login to the RP the first time
> (though that consent can be given in advance out of band in a enterprise
> scenario.
> >>
> >> When developing Connect we debated having a token endpoint response
> with only a id_token but decided that it was not in the spirit of being a
> OAuth 2 profile.   So we decided to return a access token even if the user
> info endpoint contains no claims other then sub.   People almost always
> want more claims as they roll out a real deployment.  It is easy to add
> them if you have designed to be able to talk to a RS.
> >> OAuth without a RS is a touch not OAuth.
> >>
> >> a4c also completely ignores modern development environments like
> node.js where the client is in the user agent, that OAuth 2 and Connect
> support.
> >>
> >> By the time the OAuth WG is done with a4c it will likely be a similar
> size as Connect if it addresses the same use cases.
> >>
> >> I still don't see the problem with having a deployment profile of
> Connect that can meet 100% of the current stated use case for a4c.
> > John - I am not fully familiar with the processes of OIDC.  How much of
> an effort is it to get the deployment profile of OIDC connect rolling?
> >
> >>
> >> I expect that the people here involved in Connect will form there own
> opinions on comments regarding the number of participants and the quantity
> of the work and review.
> >>
> >> Regards
> >> John B.
> >>
> >>
> >>
> >>
> >> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt 
> wrote:
> >>
> >>> +1, after implementing OIDC I will support the claim that any SSO
> protocol with a minimal set of required features smaller than OIDC is
> insecure and any protocol with similar features but with different
> parameter names is just creating confusion and will increase chances of
> non-interoperable and insecure implementations
> >>>
> >>> Hans.
> >>>
> >>> On 6/12/14, 9:50 PM, Bill Burke wrote:
> >>>>
> >>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
> >>>>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has
> >>>>> received review from maybe a dozen engineers within the OpenID
> community.
> >>>>>
> >>>> The OpenID Connect spec is 86 pages because it pretty much rehashes
> the
> >>>> OAuth2 spec walking through each flow and how Open ID Connect expands
> on
> >>>> that flow.  A4c looks like a subset of this work minus some additional
> >>>> claims and, IMO, is incomplete compared to OIDC.
> >>>>
> >>>> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We
> >>>> originally were creating our own oauth2 extension using JWT, but found
> >>>> that any feature we wanted to define already existed in OpenID
> Connect.
> >>>>  These guys have done great work.   Aren't many of you here authors of
> >>>> this spec and/or the same companies?!?  I think your energies are
> better
> >>>> focused on lobbying OIDC to join the IETF and this WG.
> >>>>
> >>>>
> >>>>
> >
> > _______________________________________________
> > 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
>

--089e0149cef62675b604fbbe4cb4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I agree that, at this point, debating the details of a4c i=
s premature. SSO/authentication are not part of the WG charter and, as I=
9;ve said before, I'd object to changing the charter to include it. Oth=
er than a small but vocal minority, I think it's fair to say that that&=
#39;s also been the prevailing sentiment of this group.=C2=A0 






On Fri, Jun 1=
3, 2014 at 1:43 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:<=
br>

Hi Anil,



There are a number of profile efforts being looked at in the OIDF. =C2=A0 T=
he Mobile Network operators lead by the GSMA are starting profile work on a=
 standard profile that will be supported by mobile operators globally, that=
 includes looking at how a Client/RP/SP can register there client once for =
use across multiple IdP AS, as well as standardized LoA and user-info schem=
a extensions.






Torsten Lodderstedt is the chair of that effort and can chime in.



I suspect that a Basic IdP for SSO profile is significantly less ambitious =
than that and could be done in the current Connect WG.



If there is interest from the members to start it. =C2=A0 The main time blo=
cking factor might be getting a new grant_type spec approved in the the OAu=
th WG if we wanted to support that.



The IdP profile is simple they can publish a discovery document saying they=
 only support that that limited feature set, that way they would also be co=
mpatible with existing connect clients.



{

"scopes_supported": ["openid"],

"response_types_supported":["code"],

"response_modes_supported":["query"],

"grant_types_supported":["authorization_code", "co=
de_id_token_only"],

"acr_values_supported":["2","3"]

}



They don't need to publish one if they don't intend to be discovera=
ble to clients but knowing what the path forward to supporting generic clie=
nt is helpful I think.



Everything exists now other than the new grant_type exists now.



The work would mostly be putting together the examples based on supporting =
a minimal flow.



Now I should point out that there are people who believe that the default f=
low should be implicit with the "id_token" response_type and inte=
nd to support that.

Phil's draft concentrates on only one use case. =C2=A0 Having a IdP dep=
loyment profile for it is not a problem, but it will not be for every IdP. =
=C2=A0 That is one of the reasons why discovery and registration are import=
ant features of Connect.






John B.






On Jun 13, 2014, at 1:26 PM, Anil Saldhana <Anil.Saldhana@redhat.com> wrote:


> On 06/12/2014 04:18 PM, John Bradley wrote:

>> All but a handful of OAuth WG participants participated in develop=
ing OpenID Connect.

>>

>> Yes some companies chose not to participate for whatever reasons a=
nd have not committed to the mutual non assert IPR agreement, and that is u=
nfortunate, but not a reason to start again from scratch.

>>

>> Changing the OIDF IPR policy of totally open specifications based =
on non asserts is also not a option.

>>

>> I have made comments on the current draft of a4c.

>>

>> I think a profile of Connect introducing a grant_type returning on=
ly an id_token would be simpler than trying to do this as a separate spec.<=
br>
>> I do note that you can do effectively the same thing now by using =
a code response_type and a scope of openID. =C2=A0 This doesn't result =
in any extra user consent other than consenting to login to the RP the firs=
t time (though that consent can be given in advance out of band in a enterp=
rise scenario.




>>

>> When developing Connect we debated having a token endpoint respons=
e with only a id_token but decided that it was not in the spirit of being a=
 OAuth 2 profile. =C2=A0 So we decided to return a access token even if the=
 user info endpoint contains no claims other then sub. =C2=A0 People almost=
 always want more claims as they roll out a real deployment. =C2=A0It is ea=
sy to add them if you have designed to be able to talk to a RS.




>> OAuth without a RS is a touch not OAuth.

>>

>> a4c also completely ignores modern development environments like n=
ode.js where the client is in the user agent, that OAuth 2 and Connect supp=
ort.

>>

>> By the time the OAuth WG is done with a4c it will likely be a simi=
lar size as Connect if it addresses the same use cases.

>>

>> I still don't see the problem with having a deployment profile=
 of Connect that can meet 100% of the current stated use case for a4c.

> John - I am not fully familiar with the processes of OIDC. =C2=A0How m=
uch of an effort is it to get the deployment profile of OIDC connect rollin=
g?

>

>>

>> I expect that the people here involved in Connect will form there =
own opinions on comments regarding the number of participants and the quant=
ity of the work and review.

>>

>> Regards

>> John B.

>>

>>

>>

>>

>> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt <hzandbelt@pingidentity.com=
> wrote:

>>

>>> +1, after implementing OIDC I will support the claim that any =
SSO protocol with a minimal set of required features smaller than OIDC is i=
nsecure and any protocol with similar features but with different parameter=
 names is just creating confusion and will increase chances of non-interope=
rable and insecure implementations




>>>

>>> Hans.

>>>

>>> On 6/12/14, 9:50 PM, Bill Burke wrote:

>>>>

>>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:

>>>>> The OpenID Connect 2.0 COre specification alone is 86 =
pages. It has

>>>>> received review from maybe a dozen engineers within th=
e OpenID community.

>>>>>

>>>> The OpenID Connect spec is 86 pages because it pretty much=
 rehashes the

>>>> OAuth2 spec walking through each flow and how Open ID Conn=
ect expands on

>>>> that flow. =C2=A0A4c looks like a subset of this work minu=
s some additional

>>>> claims and, IMO, is incomplete compared to OIDC.

>>>>

>>>> FWIW, add 5 Red Hat engineers to the "dozen" of =
reviewers. =C2=A0We

>>>> originally were creating our own oauth2 extension using JW=
T, but found

>>>> that any feature we wanted to define already existed in Op=
enID Connect.

>>>> =C2=A0These guys have done great work. =C2=A0 Aren't m=
any of you here authors of

>>>> this spec and/or the same companies?!? =C2=A0I think your =
energies are better

>>>> focused on lobbying OIDC to join the IETF and this WG.

>>>>

>>>>

>>>>

>

> _______________________________________________

> 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





--089e0149cef62675b604fbbe4cb4--


From nobody Fri Jun 13 14:35:01 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFD41B2A62 for ; Fri, 13 Jun 2014 14:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.552
X-Spam-Level: 
X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgs_OzxkaoBN for ; Fri, 13 Jun 2014 14:34:57 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 965841B2A59 for ; Fri, 13 Jun 2014 14:34:57 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5DLYu62028336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Jun 2014 17:34:56 -0400
Received: from localhost.localdomain (vpn-53-247.rdu2.redhat.com [10.10.53.247]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5DLYqIn008822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 13 Jun 2014 17:34:55 -0400
Message-ID: <539B6E7C.4030309@redhat.com>
Date: Fri, 13 Jun 2014 16:34:52 -0500
From: Anil Saldhana 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Brian Campbell , John Bradley 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <539A0FB1.1020106@pingidentity.com> <13F2E738-49BB-4EDB-9070-5A49448A6249@ve7jtb.com> <539B345A.7060808@redhat.com> <7082F35E-422C-441F-BBE8-158E4A9BA085@ve7jtb.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020202070001080600060809"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-Wj01EaD1W2pESSYBNTxqCoLBGE
Cc: oauth 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 21:35:00 -0000

This is a multi-part message in MIME format.
--------------020202070001080600060809
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Brian - I agree. We should neither overload nor extend the WG charter to 
include any aspect of SSO or authentication.

I am hoping Prateek/Phil's feedback on OIDC can be addressed by OIDC.

 From John's email, it seemed like a path forward is a Deployment 
Profile at OIDC. Hopefully everybody will be happy with that.


On 06/13/2014 04:23 PM, Brian Campbell wrote:
> I agree that, at this point, debating the details of a4c is premature. 
> SSO/authentication are not part of the WG charter and, as I've said 
> before, I'd object to changing the charter to include it. Other than a 
> small but vocal minority, I think it's fair to say that that's also 
> been the prevailing sentiment of this group.
>
>
> On Fri, Jun 13, 2014 at 1:43 PM, John Bradley  > wrote:
>
>     Hi Anil,
>
>     There are a number of profile efforts being looked at in the OIDF.
>       The Mobile Network operators lead by the GSMA are starting
>     profile work on a standard profile that will be supported by
>     mobile operators globally, that includes looking at how a
>     Client/RP/SP can register there client once for use across
>     multiple IdP AS, as well as standardized LoA and user-info schema
>     extensions.
>
>     Torsten Lodderstedt is the chair of that effort and can chime in.
>
>     I suspect that a Basic IdP for SSO profile is significantly less
>     ambitious than that and could be done in the current Connect WG.
>
>     If there is interest from the members to start it.   The main time
>     blocking factor might be getting a new grant_type spec approved in
>     the the OAuth WG if we wanted to support that.
>
>     The IdP profile is simple they can publish a discovery document
>     saying they only support that that limited feature set, that way
>     they would also be compatible with existing connect clients.
>
>     {
>     "scopes_supported": ["openid"],
>     "response_types_supported":["code"],
>     "response_modes_supported":["query"],
>     "grant_types_supported":["authorization_code", "code_id_token_only"],
>     "acr_values_supported":["2","3"]
>     }
>
>     They don't need to publish one if they don't intend to be
>     discoverable to clients but knowing what the path forward to
>     supporting generic client is helpful I think.
>
>     Everything exists now other than the new grant_type exists now.
>
>     The work would mostly be putting together the examples based on
>     supporting a minimal flow.
>
>     Now I should point out that there are people who believe that the
>     default flow should be implicit with the "id_token" response_type
>     and intend to support that.
>     Phil's draft concentrates on only one use case.   Having a IdP
>     deployment profile for it is not a problem, but it will not be for
>     every IdP.   That is one of the reasons why discovery and
>     registration are important features of Connect.
>
>     John B.
>
>
>     On Jun 13, 2014, at 1:26 PM, Anil Saldhana
>     > wrote:
>
>     > On 06/12/2014 04:18 PM, John Bradley wrote:
>     >> All but a handful of OAuth WG participants participated in
>     developing OpenID Connect.
>     >>
>     >> Yes some companies chose not to participate for whatever
>     reasons and have not committed to the mutual non assert IPR
>     agreement, and that is unfortunate, but not a reason to start
>     again from scratch.
>     >>
>     >> Changing the OIDF IPR policy of totally open specifications
>     based on non asserts is also not a option.
>     >>
>     >> I have made comments on the current draft of a4c.
>     >>
>     >> I think a profile of Connect introducing a grant_type returning
>     only an id_token would be simpler than trying to do this as a
>     separate spec.
>     >> I do note that you can do effectively the same thing now by
>     using a code response_type and a scope of openID.   This doesn't
>     result in any extra user consent other than consenting to login to
>     the RP the first time (though that consent can be given in advance
>     out of band in a enterprise scenario.
>     >>
>     >> When developing Connect we debated having a token endpoint
>     response with only a id_token but decided that it was not in the
>     spirit of being a OAuth 2 profile.   So we decided to return a
>     access token even if the user info endpoint contains no claims
>     other then sub.   People almost always want more claims as they
>     roll out a real deployment.  It is easy to add them if you have
>     designed to be able to talk to a RS.
>     >> OAuth without a RS is a touch not OAuth.
>     >>
>     >> a4c also completely ignores modern development environments
>     like node.js where the client is in the user agent, that OAuth 2
>     and Connect support.
>     >>
>     >> By the time the OAuth WG is done with a4c it will likely be a
>     similar size as Connect if it addresses the same use cases.
>     >>
>     >> I still don't see the problem with having a deployment profile
>     of Connect that can meet 100% of the current stated use case for a4c.
>     > John - I am not fully familiar with the processes of OIDC.  How
>     much of an effort is it to get the deployment profile of OIDC
>     connect rolling?
>     >
>     >>
>     >> I expect that the people here involved in Connect will form
>     there own opinions on comments regarding the number of
>     participants and the quantity of the work and review.
>     >>
>     >> Regards
>     >> John B.
>     >>
>     >>
>     >>
>     >>
>     >> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt
>     >
>     wrote:
>     >>
>     >>> +1, after implementing OIDC I will support the claim that any
>     SSO protocol with a minimal set of required features smaller than
>     OIDC is insecure and any protocol with similar features but with
>     different parameter names is just creating confusion and will
>     increase chances of non-interoperable and insecure implementations
>     >>>
>     >>> Hans.
>     >>>
>     >>> On 6/12/14, 9:50 PM, Bill Burke wrote:
>     >>>>
>     >>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>     >>>>> The OpenID Connect 2.0 COre specification alone is 86 pages.
>     It has
>     >>>>> received review from maybe a dozen engineers within the
>     OpenID community.
>     >>>>>
>     >>>> The OpenID Connect spec is 86 pages because it pretty much
>     rehashes the
>     >>>> OAuth2 spec walking through each flow and how Open ID Connect
>     expands on
>     >>>> that flow.  A4c looks like a subset of this work minus some
>     additional
>     >>>> claims and, IMO, is incomplete compared to OIDC.
>     >>>>
>     >>>> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We
>     >>>> originally were creating our own oauth2 extension using JWT,
>     but found
>     >>>> that any feature we wanted to define already existed in
>     OpenID Connect.
>     >>>>  These guys have done great work. Aren't many of you here
>     authors of
>     >>>> this spec and/or the same companies?!?  I think your energies
>     are better
>     >>>> focused on lobbying OIDC to join the IETF and this WG.
>     >>>>
>     >>>>
>     >>>>
>     >
>

--------------020202070001080600060809
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Brian - I agree. We should neither
      overload nor extend the WG charter to include any aspect of SSO or
      authentication.

      

      I am hoping Prateek/Phil's feedback on OIDC can be addressed by
      OIDC.  

      

      From John's email, it seemed like a path forward is a Deployment
      Profile at OIDC. Hopefully everybody will be happy with that.

      

      

      On 06/13/2014 04:23 PM, Brian Campbell wrote:

    

    

      
I agree that, at this point, debating the details
        of a4c is premature. SSO/authentication are not part of the WG
        charter and, as I've said before, I'd object to changing the
        charter to include it. Other than a small but vocal minority, I
        think it's fair to say that that's also been the prevailing
        sentiment of this group.  

        


          

          
On Fri, Jun 13, 2014 at 1:43 PM, John
            Bradley <ve7jtb@ve7jtb.com>
            wrote:

            
Hi Anil,

              

              There are a number of profile efforts being looked at in
              the OIDF.   The Mobile Network operators lead by the GSMA
              are starting profile work on a standard profile that will
              be supported by mobile operators globally, that includes
              looking at how a Client/RP/SP can register there client
              once for use across multiple IdP AS, as well as
              standardized LoA and user-info schema extensions.

              

              Torsten Lodderstedt is the chair of that effort and can
              chime in.

              

              I suspect that a Basic IdP for SSO profile is
              significantly less ambitious than that and could be done
              in the current Connect WG.

              

              If there is interest from the members to start it.   The
              main time blocking factor might be getting a new
              grant_type spec approved in the the OAuth WG if we wanted
              to support that.

              

              The IdP profile is simple they can publish a discovery
              document saying they only support that that limited
              feature set, that way they would also be compatible with
              existing connect clients.

              

              {

              "scopes_supported": ["openid"],

              "response_types_supported":["code"],

              "response_modes_supported":["query"],

              "grant_types_supported":["authorization_code",
              "code_id_token_only"],

              "acr_values_supported":["2","3"]

              }

              

              They don't need to publish one if they don't intend to be
              discoverable to clients but knowing what the path forward
              to supporting generic client is helpful I think.

              

              Everything exists now other than the new grant_type exists
              now.

              

              The work would mostly be putting together the examples
              based on supporting a minimal flow.

              

              Now I should point out that there are people who believe
              that the default flow should be implicit with the
              "id_token" response_type and intend to support that.

              Phil's draft concentrates on only one use case.   Having a
              IdP deployment profile for it is not a problem, but it
              will not be for every IdP.   That is one of the reasons
              why discovery and registration are important features of
              Connect.

              

              John B.

              

                


                  

                  On Jun 13, 2014, at 1:26 PM, Anil Saldhana <Anil.Saldhana@redhat.com>
                  wrote:

                  

                  > On 06/12/2014 04:18 PM, John Bradley wrote:

                  >> All but a handful of OAuth WG participants
                  participated in developing OpenID Connect.

                  >>

                  >> Yes some companies chose not to participate
                  for whatever reasons and have not committed to the
                  mutual non assert IPR agreement, and that is
                  unfortunate, but not a reason to start again from
                  scratch.

                  >>

                  >> Changing the OIDF IPR policy of totally open
                  specifications based on non asserts is also not a
                  option.

                  >>

                  >> I have made comments on the current draft of
                  a4c.

                  >>

                  >> I think a profile of Connect introducing a
                  grant_type returning only an id_token would be simpler
                  than trying to do this as a separate spec.

                  >> I do note that you can do effectively the
                  same thing now by using a code response_type and a
                  scope of openID.   This doesn't result in any extra
                  user consent other than consenting to login to the RP
                  the first time (though that consent can be given in
                  advance out of band in a enterprise scenario.

                  >>

                  >> When developing Connect we debated having a
                  token endpoint response with only a id_token but
                  decided that it was not in the spirit of being a OAuth
                  2 profile.   So we decided to return a access token
                  even if the user info endpoint contains no claims
                  other then sub.   People almost always want more
                  claims as they roll out a real deployment.  It is easy
                  to add them if you have designed to be able to talk to
                  a RS.

                  >> OAuth without a RS is a touch not OAuth.

                  >>

                  >> a4c also completely ignores modern
                  development environments like node.js where the client
                  is in the user agent, that OAuth 2 and Connect
                  support.

                  >>

                  >> By the time the OAuth WG is done with a4c it
                  will likely be a similar size as Connect if it
                  addresses the same use cases.

                  >>

                  >> I still don't see the problem with having a
                  deployment profile of Connect that can meet 100% of
                  the current stated use case for a4c.

                  > John - I am not fully familiar with the processes
                  of OIDC.  How much of an effort is it to get the
                  deployment profile of OIDC connect rolling?

                  >

                  >>

                  >> I expect that the people here involved in
                  Connect will form there own opinions on comments
                  regarding the number of participants and the quantity
                  of the work and review.

                  >>

                  >> Regards

                  >> John B.

                  >>

                  >>

                  >>

                  >>

                  >> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt
                  <hzandbelt@pingidentity.com>
                  wrote:

                  >>

                  >>> +1, after implementing OIDC I will
                  support the claim that any SSO protocol with a minimal
                  set of required features smaller than OIDC is insecure
                  and any protocol with similar features but with
                  different parameter names is just creating confusion
                  and will increase chances of non-interoperable and
                  insecure implementations

                  >>>

                  >>> Hans.

                  >>>

                  >>> On 6/12/14, 9:50 PM, Bill Burke wrote:

                  >>>>

                  >>>> On 6/12/2014 12:49 PM, Prateek Mishra
                  wrote:

                  >>>>> The OpenID Connect 2.0 COre
                  specification alone is 86 pages. It has

                  >>>>> received review from maybe a
                  dozen engineers within the OpenID community.

                  >>>>>

                  >>>> The OpenID Connect spec is 86 pages
                  because it pretty much rehashes the

                  >>>> OAuth2 spec walking through each flow
                  and how Open ID Connect expands on

                  >>>> that flow.  A4c looks like a subset
                  of this work minus some additional

                  >>>> claims and, IMO, is incomplete
                  compared to OIDC.

                  >>>>

                  >>>> FWIW, add 5 Red Hat engineers to the
                  "dozen" of reviewers.  We

                  >>>> originally were creating our own
                  oauth2 extension using JWT, but found

                  >>>> that any feature we wanted to define
                  already existed in OpenID Connect.

                  >>>>  These guys have done great work.  
                  Aren't many of you here authors of

                  >>>> this spec and/or the same
                  companies?!?  I think your energies are better

                  >>>> focused on lobbying OIDC to join the
                  IETF and this WG.

                  >>>>

                  >>>>

                  >>>>

                  >

                

              

            

          

        

      

    

     
  


--------------020202070001080600060809--


From nobody Fri Jun 13 16:15:38 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0891B29C0 for ; Fri, 13 Jun 2014 16:15:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level: 
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W23bi0SopwRT for ; Fri, 13 Jun 2014 16:15:34 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773C51A0467 for ; Fri, 13 Jun 2014 16:15:34 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5DNFXsD029416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jun 2014 23:15:33 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5DNFVT5019370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2014 23:15:32 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5DNFVb7004231; Fri, 13 Jun 2014 23:15:31 GMT
Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Jun 2014 16:15:31 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_ADBC6FED-5227-4D33-8436-6D43BA3D918E"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Phil Hunt 
In-Reply-To: <539B6E7C.4030309@redhat.com>
Date: Fri, 13 Jun 2014 16:15:29 -0700
Message-Id: <998C2BA7-E47F-4A2D-BB5F-A21F47F41EB9@oracle.com>
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <539A0FB1.1020106@pingidentity.com> <13F2E738-49BB-4EDB-9070-5A49448A6249@ve7jtb.com> <539B345A.7060808@redhat.com> <7082F35E-422C-441F-BBE8-158E4A9BA085@ve7jtb.com>  <539B6E7C.4030309@redhat.com>
To: Anil Saldhana 
X-Mailer: Apple Mail (2.1878.2)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/BfLOVtMWsKdMrU6CJGOSkHa_Cg4
Cc: oauth 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 23:15:37 -0000

--Apple-Mail=_ADBC6FED-5227-4D33-8436-6D43BA3D918E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I think this is a false argument. What we desire to do or not do is not =
always the WG's choice.

It=92s not me asking an authentication enhancement. The issue is whether =
to address improper authentication in the wild. Several of us all =
blogged about this a while a go and the problem with improper use of =
6749 for authentication continues to grow.

Would it be better if we thought about this as the authentication =93bug=94=
?

I=92m not sure everyone is on the same page regarding the term =
=93authentication". In none of the scenarios discussed are we talking =
about =93performing=94 authentication. We are talking about passing the =
authentication context from the AS in a non-opaque form to the client =
where the client is the audience of that information.

The authentication term is especially confusing because what developers =
*think* they are doing is authentication. It is not.

Phil

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



On Jun 13, 2014, at 2:34 PM, Anil Saldhana  =
wrote:

> Brian - I agree. We should neither overload nor extend the WG charter =
to include any aspect of SSO or authentication.
>=20
> I am hoping Prateek/Phil's feedback on OIDC can be addressed by OIDC. =20=

>=20
> =46rom John's email, it seemed like a path forward is a Deployment =
Profile at OIDC. Hopefully everybody will be happy with that.
>=20
>=20
> On 06/13/2014 04:23 PM, Brian Campbell wrote:
>> I agree that, at this point, debating the details of a4c is =
premature. SSO/authentication are not part of the WG charter and, as =
I've said before, I'd object to changing the charter to include it. =
Other than a small but vocal minority, I think it's fair to say that =
that's also been the prevailing sentiment of this group. =20
>>=20
>>=20
>> On Fri, Jun 13, 2014 at 1:43 PM, John Bradley  =
wrote:
>> Hi Anil,
>>=20
>> There are a number of profile efforts being looked at in the OIDF.   =
The Mobile Network operators lead by the GSMA are starting profile work =
on a standard profile that will be supported by mobile operators =
globally, that includes looking at how a Client/RP/SP can register there =
client once for use across multiple IdP AS, as well as standardized LoA =
and user-info schema extensions.
>>=20
>> Torsten Lodderstedt is the chair of that effort and can chime in.
>>=20
>> I suspect that a Basic IdP for SSO profile is significantly less =
ambitious than that and could be done in the current Connect WG.
>>=20
>> If there is interest from the members to start it.   The main time =
blocking factor might be getting a new grant_type spec approved in the =
the OAuth WG if we wanted to support that.
>>=20
>> The IdP profile is simple they can publish a discovery document =
saying they only support that that limited feature set, that way they =
would also be compatible with existing connect clients.
>>=20
>> {
>> "scopes_supported": ["openid"],
>> "response_types_supported":["code"],
>> "response_modes_supported":["query"],
>> "grant_types_supported":["authorization_code", "code_id_token_only"],
>> "acr_values_supported":["2","3"]
>> }
>>=20
>> They don't need to publish one if they don't intend to be =
discoverable to clients but knowing what the path forward to supporting =
generic client is helpful I think.
>>=20
>> Everything exists now other than the new grant_type exists now.
>>=20
>> The work would mostly be putting together the examples based on =
supporting a minimal flow.
>>=20
>> Now I should point out that there are people who believe that the =
default flow should be implicit with the "id_token" response_type and =
intend to support that.
>> Phil's draft concentrates on only one use case.   Having a IdP =
deployment profile for it is not a problem, but it will not be for every =
IdP.   That is one of the reasons why discovery and registration are =
important features of Connect.
>>=20
>> John B.
>>=20
>>=20
>> On Jun 13, 2014, at 1:26 PM, Anil Saldhana  =
wrote:
>>=20
>> > On 06/12/2014 04:18 PM, John Bradley wrote:
>> >> All but a handful of OAuth WG participants participated in =
developing OpenID Connect.
>> >>
>> >> Yes some companies chose not to participate for whatever reasons =
and have not committed to the mutual non assert IPR agreement, and that =
is unfortunate, but not a reason to start again from scratch.
>> >>
>> >> Changing the OIDF IPR policy of totally open specifications based =
on non asserts is also not a option.
>> >>
>> >> I have made comments on the current draft of a4c.
>> >>
>> >> I think a profile of Connect introducing a grant_type returning =
only an id_token would be simpler than trying to do this as a separate =
spec.
>> >> I do note that you can do effectively the same thing now by using =
a code response_type and a scope of openID.   This doesn't result in any =
extra user consent other than consenting to login to the RP the first =
time (though that consent can be given in advance out of band in a =
enterprise scenario.
>> >>
>> >> When developing Connect we debated having a token endpoint =
response with only a id_token but decided that it was not in the spirit =
of being a OAuth 2 profile.   So we decided to return a access token =
even if the user info endpoint contains no claims other then sub.   =
People almost always want more claims as they roll out a real =
deployment.  It is easy to add them if you have designed to be able to =
talk to a RS.
>> >> OAuth without a RS is a touch not OAuth.
>> >>
>> >> a4c also completely ignores modern development environments like =
node.js where the client is in the user agent, that OAuth 2 and Connect =
support.
>> >>
>> >> By the time the OAuth WG is done with a4c it will likely be a =
similar size as Connect if it addresses the same use cases.
>> >>
>> >> I still don't see the problem with having a deployment profile of =
Connect that can meet 100% of the current stated use case for a4c.
>> > John - I am not fully familiar with the processes of OIDC.  How =
much of an effort is it to get the deployment profile of OIDC connect =
rolling?
>> >
>> >>
>> >> I expect that the people here involved in Connect will form there =
own opinions on comments regarding the number of participants and the =
quantity of the work and review.
>> >>
>> >> Regards
>> >> John B.
>> >>
>> >>
>> >>
>> >>
>> >> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt =
 wrote:
>> >>
>> >>> +1, after implementing OIDC I will support the claim that any SSO =
protocol with a minimal set of required features smaller than OIDC is =
insecure and any protocol with similar features but with different =
parameter names is just creating confusion and will increase chances of =
non-interoperable and insecure implementations
>> >>>
>> >>> Hans.
>> >>>
>> >>> On 6/12/14, 9:50 PM, Bill Burke wrote:
>> >>>>
>> >>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>> >>>>> The OpenID Connect 2.0 COre specification alone is 86 pages. It =
has
>> >>>>> received review from maybe a dozen engineers within the OpenID =
community.
>> >>>>>
>> >>>> The OpenID Connect spec is 86 pages because it pretty much =
rehashes the
>> >>>> OAuth2 spec walking through each flow and how Open ID Connect =
expands on
>> >>>> that flow.  A4c looks like a subset of this work minus some =
additional
>> >>>> claims and, IMO, is incomplete compared to OIDC.
>> >>>>
>> >>>> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We
>> >>>> originally were creating our own oauth2 extension using JWT, but =
found
>> >>>> that any feature we wanted to define already existed in OpenID =
Connect.
>> >>>>  These guys have done great work.   Aren't many of you here =
authors of
>> >>>> this spec and/or the same companies?!?  I think your energies =
are better
>> >>>> focused on lobbying OIDC to join the IETF and this WG.
>> >>>>
>> >>>>
>> >>>>
>> >
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_ADBC6FED-5227-4D33-8436-6D43BA3D918E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


I =
think this is a false argument. What we desire to do or not do is not =
always the WG's choice.

It=92s not me asking an =
authentication enhancement. The issue is whether to address improper =
authentication in the wild. Several of us all blogged about this a =
while a go and the problem with improper use of 6749 for authentication =
continues to grow.

Would it be better if we =
thought about this as the authentication =
=93bug=94?

I=92m not sure everyone is on the =
same page regarding the term =93authentication". In none of the =
scenarios discussed are we talking about =93performing=94 =
authentication. We are talking about passing the authentication context =
from the AS in a non-opaque form to the client where the client is the =
audience of that information.

The =
authentication term is especially confusing because what developers =
*think* they are doing is authentication. It is =
not.





On Jun 13, 2014, at 2:34 PM, Anil Saldhana <Anil.Saldhana@redhat.com> =
wrote:


 =20
    
 =20
  

    
Brian - I agree. We should neither
      overload nor extend the WG charter to include any aspect of SSO or
      authentication.

      

      I am hoping Prateek/Phil's feedback on OIDC can be addressed by
      OIDC.  

      

      =46rom John's email, it seemed like a path forward is a Deployment
      Profile at OIDC. Hopefully everybody will be happy with that.

      

      

      On 06/13/2014 04:23 PM, Brian Campbell wrote:

    

    

      
I agree that, at this point, debating the details
        of a4c is premature. SSO/authentication are not part of the WG
        charter and, as I've said before, I'd object to changing the
        charter to include it. Other than a small but vocal minority, I
        think it's fair to say that that's also been the prevailing
        sentiment of this group.  

        


          

          
On Fri, Jun 13, 2014 at 1:43 PM, =
John
            Bradley <ve7jtb@ve7jtb.com>
            wrote:

            
Hi =
Anil,

              

              There are a number of profile efforts being looked at in
              the OIDF.   The Mobile Network operators lead by the =
GSMA
              are starting profile work on a standard profile that will
              be supported by mobile operators globally, that includes
              looking at how a Client/RP/SP can register there client
              once for use across multiple IdP AS, as well as
              standardized LoA and user-info schema extensions.

              

              Torsten Lodderstedt is the chair of that effort and can
              chime in.

              

              I suspect that a Basic IdP for SSO profile is
              significantly less ambitious than that and could be done
              in the current Connect WG.

              

              If there is interest from the members to start it.   =
The
              main time blocking factor might be getting a new
              grant_type spec approved in the the OAuth WG if we wanted
              to support that.

              

              The IdP profile is simple they can publish a discovery
              document saying they only support that that limited
              feature set, that way they would also be compatible with
              existing connect clients.

              

              {

              "scopes_supported": ["openid"],

              "response_types_supported":["code"],

              "response_modes_supported":["query"],

              "grant_types_supported":["authorization_code",
              "code_id_token_only"],

              "acr_values_supported":["2","3"]

              }

              

              They don't need to publish one if they don't intend to be
              discoverable to clients but knowing what the path forward
              to supporting generic client is helpful I think.

              

              Everything exists now other than the new grant_type exists
              now.

              

              The work would mostly be putting together the examples
              based on supporting a minimal flow.

              

              Now I should point out that there are people who believe
              that the default flow should be implicit with the
              "id_token" response_type and intend to support that.

              Phil's draft concentrates on only one use case.   =
Having a
              IdP deployment profile for it is not a problem, but it
              will not be for every IdP.   That is one of the =
reasons
              why discovery and registration are important features of
              Connect.

              

              John B.

              

                


                  

                  On Jun 13, 2014, at 1:26 PM, Anil Saldhana <Anil.Saldhana@redhat.com>
                  wrote:

                  

                  > On 06/12/2014 04:18 PM, John Bradley wrote:

                  >> All but a handful of OAuth WG participants
                  participated in developing OpenID Connect.

                  >>

                  >> Yes some companies chose not to participate
                  for whatever reasons and have not committed to the
                  mutual non assert IPR agreement, and that is
                  unfortunate, but not a reason to start again from
                  scratch.

                  >>

                  >> Changing the OIDF IPR policy of totally open
                  specifications based on non asserts is also not a
                  option.

                  >>

                  >> I have made comments on the current draft of
                  a4c.

                  >>

                  >> I think a profile of Connect introducing a
                  grant_type returning only an id_token would be simpler
                  than trying to do this as a separate spec.

                  >> I do note that you can do effectively the
                  same thing now by using a code response_type and a
                  scope of openID.   This doesn't result in any =
extra
                  user consent other than consenting to login to the RP
                  the first time (though that consent can be given in
                  advance out of band in a enterprise scenario.

                  >>

                  >> When developing Connect we debated having a
                  token endpoint response with only a id_token but
                  decided that it was not in the spirit of being a OAuth
                  2 profile.   So we decided to return a access =
token
                  even if the user info endpoint contains no claims
                  other then sub.   People almost always want more
                  claims as they roll out a real deployment.  It is =
easy
                  to add them if you have designed to be able to talk to
                  a RS.

                  >> OAuth without a RS is a touch not OAuth.

                  >>

                  >> a4c also completely ignores modern
                  development environments like node.js where the client
                  is in the user agent, that OAuth 2 and Connect
                  support.

                  >>

                  >> By the time the OAuth WG is done with a4c it
                  will likely be a similar size as Connect if it
                  addresses the same use cases.

                  >>

                  >> I still don't see the problem with having a
                  deployment profile of Connect that can meet 100% of
                  the current stated use case for a4c.

                  > John - I am not fully familiar with the processes
                  of OIDC.  How much of an effort is it to get the
                  deployment profile of OIDC connect rolling?

                  >

                  >>

                  >> I expect that the people here involved in
                  Connect will form there own opinions on comments
                  regarding the number of participants and the quantity
                  of the work and review.

                  >>

                  >> Regards

                  >> John B.

                  >>

                  >>

                  >>

                  >>

                  >> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt
                  <hzandbelt@pingidentity.com>
                  wrote:

                  >>

                  >>> +1, after implementing OIDC I will
                  support the claim that any SSO protocol with a minimal
                  set of required features smaller than OIDC is insecure
                  and any protocol with similar features but with
                  different parameter names is just creating confusion
                  and will increase chances of non-interoperable and
                  insecure implementations

                  >>>

                  >>> Hans.

                  >>>

                  >>> On 6/12/14, 9:50 PM, Bill Burke =
wrote:

                  >>>>

                  >>>> On 6/12/2014 12:49 PM, Prateek Mishra
                  wrote:

                  >>>>> The OpenID Connect 2.0 COre
                  specification alone is 86 pages. It has

                  >>>>> received review from maybe a
                  dozen engineers within the OpenID community.

                  >>>>>

                  >>>> The OpenID Connect spec is 86 pages
                  because it pretty much rehashes the

                  >>>> OAuth2 spec walking through each flow
                  and how Open ID Connect expands on

                  >>>> that flow.  A4c looks like a =
subset
                  of this work minus some additional

                  >>>> claims and, IMO, is incomplete
                  compared to OIDC.

                  >>>>

                  >>>> FWIW, add 5 Red Hat engineers to the
                  "dozen" of reviewers.  We

                  >>>> originally were creating our own
                  oauth2 extension using JWT, but found

                  >>>> that any feature we wanted to define
                  already existed in OpenID Connect.

                  >>>>  These guys have done great =
work.  
                  Aren't many of you here authors of

                  >>>> this spec and/or the same
                  companies?!?  I think your energies are =
better

                  >>>> focused on lobbying OIDC to join the
                  IETF and this WG.

                  >>>>

                  >>>>

                  >>>>

                  >

                

              

            

          

        

      

    

     
  


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

=

--Apple-Mail=_ADBC6FED-5227-4D33-8436-6D43BA3D918E--


From nobody Fri Jun 13 16:49:30 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65D81B2A9F for ; Fri, 13 Jun 2014 16:49:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmCpImpWX7jh for ; Fri, 13 Jun 2014 16:49:26 -0700 (PDT)
Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18601B2A71 for ; Fri, 13 Jun 2014 16:49:25 -0700 (PDT)
Received: by mail-qc0-f178.google.com with SMTP id c9so4900177qcz.37 for ; Fri, 13 Jun 2014 16:49:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hJzFdPRZUVuAqKlkM8Ey9AHuUGF3SUF78glpIafUeM8=; b=Tr2fJvmvJuI/8arFT1+xMADk7lJubT+ytlDt6XGKxhvQQ7Iqx6yzfXzJzK0pFw5PpI KvormCGSjf0uWlLxyS8GXEYB0HS0TtRPTEcF7009TVLBzs1EXVDCWJWqDqtbV+wv7kuE wW1+gCzVSjKjqjlToV9Sbc2IgxR8d2xtjNCfiZraZnpbD1ApLx6WG+vu1J5L4pwb+mRx Jf5c9r/g1zcN/rqVcMgiRqnxYpauQA3yNkYrEhNBqK9CiGXzzb/Z/XHuluxuGTKypiSb ZbUDIdJbzjQcB1xGNucHMaP+uzgBjDmw2y8pztJWOxV1fiM2pN4bd6YKYcW+LgomvgRQ c9ag==
X-Gm-Message-State: ALoCoQld9+3mheQfQaxvnzY/OqXYZpFENRMTUL4mVLZyX5zSg2jgfGeWKn7mOZC1ra0l8m2B7e7F
X-Received: by 10.224.162.212 with SMTP id w20mr8174194qax.50.1402703364708; Fri, 13 Jun 2014 16:49:24 -0700 (PDT)
Received: from [192.168.0.200] ([201.188.51.91]) by mx.google.com with ESMTPSA id r60sm567477qgd.26.2014.06.13.16.49.22 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 16:49:23 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_01E8CCC1-1622-4418-9916-00E1A18500CC"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: John Bradley 
In-Reply-To: <998C2BA7-E47F-4A2D-BB5F-A21F47F41EB9@oracle.com>
Date: Fri, 13 Jun 2014 19:50:23 -0400
Message-Id: <461892C0-D54E-49C6-83C4-59446A577B49@ve7jtb.com>
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <539A0FB1.1020106@pingidentity.com> <13F2E738-49BB-4EDB-9070-5A49448A6249@ve7jtb.com> <539B345A.7060808@redhat.com> <7082F35E-422C-441F-BBE8-158E4A9BA085@ve7jtb.com>  <539B6E7C.4030309@redhat.com> <998C2BA7-E47F-4A2D-BB5F-A21F47F41EB9@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_LzocBkkijRhMyquWDDL6wcxpeA
Cc: oauth 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 23:49:29 -0000

--Apple-Mail=_01E8CCC1-1622-4418-9916-00E1A18500CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

To be precise SAML, Connect, and a4c provide Assertion-based =
authentication of a claimant,  by a Verifier (IdP) to a relying party =
(RP) when the RP and the Verifier are not collocated ( i.e., they are =
connected across a shared network)   SP-800-63 sec 9

Typically we call this authentication (authn) though that may just be a =
bad habit picked form SAML and other protocols use of the term.

It is true that people make horrible mistakes by ignoring the OAuth =
security considerations and inappropriately use OAuth directly for =
inferring that the presenter of the code or access token is the resource =
owner identified by the resource.

I had sort of hoped that broad support and adoption of OpenID Connect =
would help guide people in the correct direction.

If there is a need for a simpler IdP profile that is not interoperable =
across IdP (Not Dynamic) the question is if developers will be more =
motivated to use a profile of a larger standard as a starting point, or =
something presented as a limited authentication extension to OAuth 2.

Clearly nothing will stop some people from rolling there own =
authentication.  The question is what solution will get the best =
traction.

My fear is that if developers see this as two competing standards they =
will use that as justification to do there own thing rather than choose =
one.

At the end of the day what the profile looks like will likely be the =
same based on the use case.   The question is where will it be done and =
what do the politics look like to developers.

That is the short term question.

John B.

On Jun 13, 2014, at 7:15 PM, Phil Hunt  wrote:

> I think this is a false argument. What we desire to do or not do is =
not always the WG's choice.
>=20
> It=92s not me asking an authentication enhancement. The issue is =
whether to address improper authentication in the wild. Several of us =
all blogged about this a while a go and the problem with improper use of =
6749 for authentication continues to grow.
>=20
> Would it be better if we thought about this as the authentication =
=93bug=94?
>=20
> I=92m not sure everyone is on the same page regarding the term =
=93authentication". In none of the scenarios discussed are we talking =
about =93performing=94 authentication. We are talking about passing the =
authentication context from the AS in a non-opaque form to the client =
where the client is the audience of that information.
>=20
> The authentication term is especially confusing because what =
developers *think* they are doing is authentication. It is not.
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
> On Jun 13, 2014, at 2:34 PM, Anil Saldhana  =
wrote:
>=20
>> Brian - I agree. We should neither overload nor extend the WG charter =
to include any aspect of SSO or authentication.
>>=20
>> I am hoping Prateek/Phil's feedback on OIDC can be addressed by OIDC. =
=20
>>=20
>> =46rom John's email, it seemed like a path forward is a Deployment =
Profile at OIDC. Hopefully everybody will be happy with that.
>>=20
>>=20
>> On 06/13/2014 04:23 PM, Brian Campbell wrote:
>>> I agree that, at this point, debating the details of a4c is =
premature. SSO/authentication are not part of the WG charter and, as =
I've said before, I'd object to changing the charter to include it. =
Other than a small but vocal minority, I think it's fair to say that =
that's also been the prevailing sentiment of this group. =20
>>>=20
>>>=20
>>> On Fri, Jun 13, 2014 at 1:43 PM, John Bradley  =
wrote:
>>> Hi Anil,
>>>=20
>>> There are a number of profile efforts being looked at in the OIDF.   =
The Mobile Network operators lead by the GSMA are starting profile work =
on a standard profile that will be supported by mobile operators =
globally, that includes looking at how a Client/RP/SP can register there =
client once for use across multiple IdP AS, as well as standardized LoA =
and user-info schema extensions.
>>>=20
>>> Torsten Lodderstedt is the chair of that effort and can chime in.
>>>=20
>>> I suspect that a Basic IdP for SSO profile is significantly less =
ambitious than that and could be done in the current Connect WG.
>>>=20
>>> If there is interest from the members to start it.   The main time =
blocking factor might be getting a new grant_type spec approved in the =
the OAuth WG if we wanted to support that.
>>>=20
>>> The IdP profile is simple they can publish a discovery document =
saying they only support that that limited feature set, that way they =
would also be compatible with existing connect clients.
>>>=20
>>> {
>>> "scopes_supported": ["openid"],
>>> "response_types_supported":["code"],
>>> "response_modes_supported":["query"],
>>> "grant_types_supported":["authorization_code", =
"code_id_token_only"],
>>> "acr_values_supported":["2","3"]
>>> }
>>>=20
>>> They don't need to publish one if they don't intend to be =
discoverable to clients but knowing what the path forward to supporting =
generic client is helpful I think.
>>>=20
>>> Everything exists now other than the new grant_type exists now.
>>>=20
>>> The work would mostly be putting together the examples based on =
supporting a minimal flow.
>>>=20
>>> Now I should point out that there are people who believe that the =
default flow should be implicit with the "id_token" response_type and =
intend to support that.
>>> Phil's draft concentrates on only one use case.   Having a IdP =
deployment profile for it is not a problem, but it will not be for every =
IdP.   That is one of the reasons why discovery and registration are =
important features of Connect.
>>>=20
>>> John B.
>>>=20
>>>=20
>>> On Jun 13, 2014, at 1:26 PM, Anil Saldhana =
 wrote:
>>>=20
>>> > On 06/12/2014 04:18 PM, John Bradley wrote:
>>> >> All but a handful of OAuth WG participants participated in =
developing OpenID Connect.
>>> >>
>>> >> Yes some companies chose not to participate for whatever reasons =
and have not committed to the mutual non assert IPR agreement, and that =
is unfortunate, but not a reason to start again from scratch.
>>> >>
>>> >> Changing the OIDF IPR policy of totally open specifications based =
on non asserts is also not a option.
>>> >>
>>> >> I have made comments on the current draft of a4c.
>>> >>
>>> >> I think a profile of Connect introducing a grant_type returning =
only an id_token would be simpler than trying to do this as a separate =
spec.
>>> >> I do note that you can do effectively the same thing now by using =
a code response_type and a scope of openID.   This doesn't result in any =
extra user consent other than consenting to login to the RP the first =
time (though that consent can be given in advance out of band in a =
enterprise scenario.
>>> >>
>>> >> When developing Connect we debated having a token endpoint =
response with only a id_token but decided that it was not in the spirit =
of being a OAuth 2 profile.   So we decided to return a access token =
even if the user info endpoint contains no claims other then sub.   =
People almost always want more claims as they roll out a real =
deployment.  It is easy to add them if you have designed to be able to =
talk to a RS.
>>> >> OAuth without a RS is a touch not OAuth.
>>> >>
>>> >> a4c also completely ignores modern development environments like =
node.js where the client is in the user agent, that OAuth 2 and Connect =
support.
>>> >>
>>> >> By the time the OAuth WG is done with a4c it will likely be a =
similar size as Connect if it addresses the same use cases.
>>> >>
>>> >> I still don't see the problem with having a deployment profile of =
Connect that can meet 100% of the current stated use case for a4c.
>>> > John - I am not fully familiar with the processes of OIDC.  How =
much of an effort is it to get the deployment profile of OIDC connect =
rolling?
>>> >
>>> >>
>>> >> I expect that the people here involved in Connect will form there =
own opinions on comments regarding the number of participants and the =
quantity of the work and review.
>>> >>
>>> >> Regards
>>> >> John B.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt =
 wrote:
>>> >>
>>> >>> +1, after implementing OIDC I will support the claim that any =
SSO protocol with a minimal set of required features smaller than OIDC =
is insecure and any protocol with similar features but with different =
parameter names is just creating confusion and will increase chances of =
non-interoperable and insecure implementations
>>> >>>
>>> >>> Hans.
>>> >>>
>>> >>> On 6/12/14, 9:50 PM, Bill Burke wrote:
>>> >>>>
>>> >>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>>> >>>>> The OpenID Connect 2.0 COre specification alone is 86 pages. =
It has
>>> >>>>> received review from maybe a dozen engineers within the OpenID =
community.
>>> >>>>>
>>> >>>> The OpenID Connect spec is 86 pages because it pretty much =
rehashes the
>>> >>>> OAuth2 spec walking through each flow and how Open ID Connect =
expands on
>>> >>>> that flow.  A4c looks like a subset of this work minus some =
additional
>>> >>>> claims and, IMO, is incomplete compared to OIDC.
>>> >>>>
>>> >>>> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We
>>> >>>> originally were creating our own oauth2 extension using JWT, =
but found
>>> >>>> that any feature we wanted to define already existed in OpenID =
Connect.
>>> >>>>  These guys have done great work.   Aren't many of you here =
authors of
>>> >>>> this spec and/or the same companies?!?  I think your energies =
are better
>>> >>>> focused on lobbying OIDC to join the IETF and this WG.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >
>> =20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


--Apple-Mail=_01E8CCC1-1622-4418-9916-00E1A18500CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

To be =
precise SAML, Connect, and a4c provide Assertion-based authentication of =
a claimant,  by a Verifier (IdP) to a relying party (RP) =
when the RP and the Verifier are not collocated ( i.e., they are =
connected across a shared network)   SP-800-63 sec =
9

Typically we call this authentication (authn) =
though that may just be a bad habit picked form SAML and other protocols =
use of the term.

It is true that people make =
horrible mistakes by ignoring the OAuth security considerations and =
inappropriately use OAuth directly for inferring that the presenter of =
the code or access token is the resource owner identified by the =
resource.

I had sort of hoped that broad =
support and adoption of OpenID Connect would help guide people in the =
correct direction.

If there is a need for a =
simpler IdP profile that is not interoperable across IdP (Not Dynamic) =
the question is if developers will be more motivated to use a profile of =
a larger standard as a starting point, or something presented as a =
limited authentication extension to OAuth =
2.

Clearly nothing will stop some people from =
rolling there own authentication.  The question is what solution =
will get the best traction.

My fear is that if =
developers see this as two competing standards they will use that as =
justification to do there own thing rather than choose =
one.

At the end of the day what the profile =
looks like will likely be the same based on the use case.   The =
question is where will it be done and what do the politics look like to =
developers.

That is the short term =
question.

John =
B.

On Jun 13, 2014, at 7:15 PM, Phil =
Hunt <phil.hunt@oracle.com> =
wrote:

I =
think this is a false argument. What we desire to do or not do is not =
always the WG's choice.

It=92s not me asking an =
authentication enhancement. The issue is whether to address improper =
authentication in the wild. Several of us all blogged about this a =
while a go and the problem with improper use of 6749 for authentication =
continues to grow.

Would it be better if we =
thought about this as the authentication =
=93bug=94?

I=92m not sure everyone is on the =
same page regarding the term =93authentication". In none of the =
scenarios discussed are we talking about =93performing=94 =
authentication. We are talking about passing the authentication context =
from the AS in a non-opaque form to the client where the client is the =
audience of that information.

The =
authentication term is especially confusing because what developers =
*think* they are doing is authentication. It is =
not.





On Jun 13, 2014, at 2:34 PM, Anil Saldhana <Anil.Saldhana@redhat.com> =
wrote:


 =20
    
 =20
  

    
Brian - I agree. We should neither
      overload nor extend the WG charter to include any aspect of SSO or
      authentication.

      

      I am hoping Prateek/Phil's feedback on OIDC can be addressed by
      OIDC.  

      

      =46rom John's email, it seemed like a path forward is a Deployment
      Profile at OIDC. Hopefully everybody will be happy with that.

      

      

      On 06/13/2014 04:23 PM, Brian Campbell wrote:

    

    

      
I agree that, at this point, debating the details
        of a4c is premature. SSO/authentication are not part of the WG
        charter and, as I've said before, I'd object to changing the
        charter to include it. Other than a small but vocal minority, I
        think it's fair to say that that's also been the prevailing
        sentiment of this group.  

        


          

          
On Fri, Jun 13, 2014 at 1:43 PM, =
John
            Bradley <ve7jtb@ve7jtb.com>
            wrote:

            
Hi =
Anil,

              

              There are a number of profile efforts being looked at in
              the OIDF.   The Mobile Network operators lead by the =
GSMA
              are starting profile work on a standard profile that will
              be supported by mobile operators globally, that includes
              looking at how a Client/RP/SP can register there client
              once for use across multiple IdP AS, as well as
              standardized LoA and user-info schema extensions.

              

              Torsten Lodderstedt is the chair of that effort and can
              chime in.

              

              I suspect that a Basic IdP for SSO profile is
              significantly less ambitious than that and could be done
              in the current Connect WG.

              

              If there is interest from the members to start it.   =
The
              main time blocking factor might be getting a new
              grant_type spec approved in the the OAuth WG if we wanted
              to support that.

              

              The IdP profile is simple they can publish a discovery
              document saying they only support that that limited
              feature set, that way they would also be compatible with
              existing connect clients.

              

              {

              "scopes_supported": ["openid"],

              "response_types_supported":["code"],

              "response_modes_supported":["query"],

              "grant_types_supported":["authorization_code",
              "code_id_token_only"],

              "acr_values_supported":["2","3"]

              }

              

              They don't need to publish one if they don't intend to be
              discoverable to clients but knowing what the path forward
              to supporting generic client is helpful I think.

              

              Everything exists now other than the new grant_type exists
              now.

              

              The work would mostly be putting together the examples
              based on supporting a minimal flow.

              

              Now I should point out that there are people who believe
              that the default flow should be implicit with the
              "id_token" response_type and intend to support that.

              Phil's draft concentrates on only one use case.   =
Having a
              IdP deployment profile for it is not a problem, but it
              will not be for every IdP.   That is one of the =
reasons
              why discovery and registration are important features of
              Connect.

              

              John B.

              

                


                  

                  On Jun 13, 2014, at 1:26 PM, Anil Saldhana <Anil.Saldhana@redhat.com>
                  wrote:

                  

                  > On 06/12/2014 04:18 PM, John Bradley wrote:

                  >> All but a handful of OAuth WG participants
                  participated in developing OpenID Connect.

                  >>

                  >> Yes some companies chose not to participate
                  for whatever reasons and have not committed to the
                  mutual non assert IPR agreement, and that is
                  unfortunate, but not a reason to start again from
                  scratch.

                  >>

                  >> Changing the OIDF IPR policy of totally open
                  specifications based on non asserts is also not a
                  option.

                  >>

                  >> I have made comments on the current draft of
                  a4c.

                  >>

                  >> I think a profile of Connect introducing a
                  grant_type returning only an id_token would be simpler
                  than trying to do this as a separate spec.

                  >> I do note that you can do effectively the
                  same thing now by using a code response_type and a
                  scope of openID.   This doesn't result in any =
extra
                  user consent other than consenting to login to the RP
                  the first time (though that consent can be given in
                  advance out of band in a enterprise scenario.

                  >>

                  >> When developing Connect we debated having a
                  token endpoint response with only a id_token but
                  decided that it was not in the spirit of being a OAuth
                  2 profile.   So we decided to return a access =
token
                  even if the user info endpoint contains no claims
                  other then sub.   People almost always want more
                  claims as they roll out a real deployment.  It is =
easy
                  to add them if you have designed to be able to talk to
                  a RS.

                  >> OAuth without a RS is a touch not OAuth.

                  >>

                  >> a4c also completely ignores modern
                  development environments like node.js where the client
                  is in the user agent, that OAuth 2 and Connect
                  support.

                  >>

                  >> By the time the OAuth WG is done with a4c it
                  will likely be a similar size as Connect if it
                  addresses the same use cases.

                  >>

                  >> I still don't see the problem with having a
                  deployment profile of Connect that can meet 100% of
                  the current stated use case for a4c.

                  > John - I am not fully familiar with the processes
                  of OIDC.  How much of an effort is it to get the
                  deployment profile of OIDC connect rolling?

                  >

                  >>

                  >> I expect that the people here involved in
                  Connect will form there own opinions on comments
                  regarding the number of participants and the quantity
                  of the work and review.

                  >>

                  >> Regards

                  >> John B.

                  >>

                  >>

                  >>

                  >>

                  >> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt
                  <hzandbelt@pingidentity.com>
                  wrote:

                  >>

                  >>> +1, after implementing OIDC I will
                  support the claim that any SSO protocol with a minimal
                  set of required features smaller than OIDC is insecure
                  and any protocol with similar features but with
                  different parameter names is just creating confusion
                  and will increase chances of non-interoperable and
                  insecure implementations

                  >>>

                  >>> Hans.

                  >>>

                  >>> On 6/12/14, 9:50 PM, Bill Burke =
wrote:

                  >>>>

                  >>>> On 6/12/2014 12:49 PM, Prateek Mishra
                  wrote:

                  >>>>> The OpenID Connect 2.0 COre
                  specification alone is 86 pages. It has

                  >>>>> received review from maybe a
                  dozen engineers within the OpenID community.

                  >>>>>

                  >>>> The OpenID Connect spec is 86 pages
                  because it pretty much rehashes the

                  >>>> OAuth2 spec walking through each flow
                  and how Open ID Connect expands on

                  >>>> that flow.  A4c looks like a =
subset
                  of this work minus some additional

                  >>>> claims and, IMO, is incomplete
                  compared to OIDC.

                  >>>>

                  >>>> FWIW, add 5 Red Hat engineers to the
                  "dozen" of reviewers.  We

                  >>>> originally were creating our own
                  oauth2 extension using JWT, but found

                  >>>> that any feature we wanted to define
                  already existed in OpenID Connect.

                  >>>>  These guys have done great =
work.  
                  Aren't many of you here authors of

                  >>>> this spec and/or the same
                  companies?!?  I think your energies are =
better

                  >>>> focused on lobbying OIDC to join the
                  IETF and this WG.

                  >>>>

                  >>>>

                  >>>>

                  >

                

              

            

          

        

      

    

     
  


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


=

--Apple-Mail=_01E8CCC1-1622-4418-9916-00E1A18500CC--


From nobody Fri Jun 13 16:56:54 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939801B2A5B for ; Fri, 13 Jun 2014 16:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRJCr5AeAoT3 for ; Fri, 13 Jun 2014 16:56:51 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5A11B2993 for ; Fri, 13 Jun 2014 16:56:51 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5DNuotk032363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 13 Jun 2014 19:56:51 -0400
Received: from [10.10.50.141] (vpn-50-141.rdu2.redhat.com [10.10.50.141]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5DNuoNs002659 for ; Fri, 13 Jun 2014 19:56:50 -0400
Message-ID: <539B8FC1.1050801@redhat.com>
Date: Fri, 13 Jun 2014 19:56:49 -0400
From: Bill Burke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <539A0FB1.1020106@pingidentity.com> <13F2E738-49BB-4EDB-9070-5A49448A6249@ve7jtb.com> <539B345A.7060808@redhat.com> <7082F35E-422C-441F-BBE8-158E4A9BA085@ve7jtb.com>  <539B6E7C.4030309@redhat.com> <998C2BA7-E47F-4A2D-BB5F-A21F47F41EB9@oracle.com>
In-Reply-To: <998C2BA7-E47F-4A2D-BB5F-A21F47F41EB9@oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/RqnrCWfOlkpFka6EZYzqwty61JE
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 23:56:52 -0000

On 6/13/2014 7:15 PM, Phil Hunt wrote:
>
> Would it be better if we thought about this as the authentication “bug”?
>

How can there be an authentication "bug" when OIDC has addressed it 
backed by multiple implementations by different parties?  Why don't you 
see if OIDC addresses the minor optimizations you are proposing in a4c 
before creating competing specifications which will only confuse and 
fragment the community?


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From nobody Fri Jun 13 17:10:49 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4B81A0418 for ; Fri, 13 Jun 2014 17:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShdyQEGj3D_T for ; Fri, 13 Jun 2014 17:10:42 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5701B2A5B for ; Fri, 13 Jun 2014 17:10:42 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id at1so3129840iec.0 for ; Fri, 13 Jun 2014 17:10:42 -0700 (PDT)
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; bh=XEoF8oHCxeV+ngvp8ruHuxdzLzpGO/7/34Qaf3+k9Fo=; b=pm34qPyyNeWnrOqEYbCPdWoncKPJDE5K1BQ3HE4Zy07H+zUsP5haIH1/rPXJniec/u rr4xJkW9mimRH6MfWV0i0NZLp2bcK1309r+PqV9+HQDShIpGGK9uyHuT5+Y9mvZqClGw XTqouJGc86VkUq8YcKGRlL+RWb2Kd+86na1hEcljaS3Qm+6qjcjoOCUZ3JOKfT9J/f1D 3DDCkLFa8mObOoICoxo75F2nFvWiL3rvD/yz2UJ9FjOJ3zlg6K3F6Fc9ZIaflkXg9gG2 j0Np/Y5+fOO7RdrCuZ2iuglTiksRbFedxjigCy+BPT+Z73zQFMD6zs4EMVb8GrVdnpbo 9aAA==
X-Received: by 10.42.88.135 with SMTP id c7mr6865413icm.46.1402704641888; Fri, 13 Jun 2014 17:10:41 -0700 (PDT)
Received: from [192.168.0.102] ([199.167.110.10]) by mx.google.com with ESMTPSA id j3sm6962233igx.8.2014.06.13.17.10.38 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 17:10:41 -0700 (PDT)
Message-ID: <539B92FC.8060709@gmail.com>
Date: Fri, 13 Jun 2014 20:10:36 -0400
From: Paul Madsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: John Bradley , Phil Hunt 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <539A0FB1.1020106@pingidentity.com> <13F2E738-49BB-4EDB-9070-5A49448A6249@ve7jtb.com> <539B345A.7060808@redhat.com> <7082F35E-422C-441F-BBE8-158E4A9BA085@ve7jtb.com>  <539B6E7C.4030309@redhat.com> <998C2BA7-E47F-4A2D-BB5F-A21F47F41EB9@oracle.com> <461892C0-D54E-49C6-83C4-59446A577B49@ve7jtb.com>
In-Reply-To: <461892C0-D54E-49C6-83C4-59446A577B49@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------080803070701030509020600"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/bTFJWfi0RaXgARV2j9F6DriPjTI
Cc: oauth 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Jun 2014 00:10:46 -0000

This is a multi-part message in MIME format.
--------------080803070701030509020600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

let's not this disagreement over the need & relevance of a4c be 
conflated with the age-old blurriness between authz & authn - in no way 
are the two related

paul


On 6/13/14, 7:50 PM, John Bradley wrote:
> To be precise SAML, Connect, and a4c provide Assertion-based 
> authentication of a claimant,  by a Verifier (IdP) to a relying party 
> (RP) when the RP and the Verifier are not collocated ( i.e., they are 
> connected across a shared network)   SP-800-63 sec 9
>
> Typically we call this authentication (authn) though that may just be 
> a bad habit picked form SAML and other protocols use of the term.
>
> It is true that people make horrible mistakes by ignoring the OAuth 
> security considerations and inappropriately use OAuth directly for 
> inferring that the presenter of the code or access token is the 
> resource owner identified by the resource.
>
> I had sort of hoped that broad support and adoption of OpenID Connect 
> would help guide people in the correct direction.
>
> If there is a need for a simpler IdP profile that is not interoperable 
> across IdP (Not Dynamic) the question is if developers will be more 
> motivated to use a profile of a larger standard as a starting point, 
> or something presented as a limited authentication extension to OAuth 2.
>
> Clearly nothing will stop some people from rolling there own 
> authentication.  The question is what solution will get the best traction.
>
> My fear is that if developers see this as two competing standards they 
> will use that as justification to do there own thing rather than 
> choose one.
>
> At the end of the day what the profile looks like will likely be the 
> same based on the use case.   The question is where will it be done 
> and what do the politics look like to developers.
>
> That is the short term question.
>
> John B.
>
> On Jun 13, 2014, at 7:15 PM, Phil Hunt  > wrote:
>
>> I think this is a false argument. What we desire to do or not do is 
>> not always the WG's choice.
>>
>> It's not me asking an authentication enhancement. The issue is 
>> whether to address improper authentication in the wild. Several of us 
>> all blogged about this a while a go and the problem with improper use 
>> of 6749 for authentication continues to grow.
>>
>> Would it be better if we thought about this as the authentication "bug"?
>>
>> I'm not sure everyone is on the same page regarding the term 
>> "authentication". In none of the scenarios discussed are we talking 
>> about "performing" authentication. We are talking about passing the 
>> authentication context from the AS in a non-opaque form to the client 
>> where the client is the audience of that information.
>>
>> The authentication term is especially confusing because what 
>> developers *think* they are doing is authentication. It is not.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com 
>> phil.hunt@oracle.com 
>>
>>
>>
>> On Jun 13, 2014, at 2:34 PM, Anil Saldhana > > wrote:
>>
>>> Brian - I agree. We should neither overload nor extend the WG 
>>> charter to include any aspect of SSO or authentication.
>>>
>>> I am hoping Prateek/Phil's feedback on OIDC can be addressed by OIDC.
>>>
>>> From John's email, it seemed like a path forward is a Deployment 
>>> Profile at OIDC. Hopefully everybody will be happy with that.
>>>
>>>
>>> On 06/13/2014 04:23 PM, Brian Campbell wrote:
>>>> I agree that, at this point, debating the details of a4c is 
>>>> premature. SSO/authentication are not part of the WG charter and, 
>>>> as I've said before, I'd object to changing the charter to include 
>>>> it. Other than a small but vocal minority, I think it's fair to say 
>>>> that that's also been the prevailing sentiment of this group.
>>>>
>>>>
>>>> On Fri, Jun 13, 2014 at 1:43 PM, John Bradley >>> > wrote:
>>>>
>>>>     Hi Anil,
>>>>
>>>>     There are a number of profile efforts being looked at in the
>>>>     OIDF.   The Mobile Network operators lead by the GSMA are
>>>>     starting profile work on a standard profile that will be
>>>>     supported by mobile operators globally, that includes looking
>>>>     at how a Client/RP/SP can register there client once for use
>>>>     across multiple IdP AS, as well as standardized LoA and
>>>>     user-info schema extensions.
>>>>
>>>>     Torsten Lodderstedt is the chair of that effort and can chime in.
>>>>
>>>>     I suspect that a Basic IdP for SSO profile is significantly
>>>>     less ambitious than that and could be done in the current
>>>>     Connect WG.
>>>>
>>>>     If there is interest from the members to start it.   The main
>>>>     time blocking factor might be getting a new grant_type spec
>>>>     approved in the the OAuth WG if we wanted to support that.
>>>>
>>>>     The IdP profile is simple they can publish a discovery document
>>>>     saying they only support that that limited feature set, that
>>>>     way they would also be compatible with existing connect clients.
>>>>
>>>>     {
>>>>     "scopes_supported": ["openid"],
>>>>     "response_types_supported":["code"],
>>>>     "response_modes_supported":["query"],
>>>>     "grant_types_supported":["authorization_code",
>>>>     "code_id_token_only"],
>>>>     "acr_values_supported":["2","3"]
>>>>     }
>>>>
>>>>     They don't need to publish one if they don't intend to be
>>>>     discoverable to clients but knowing what the path forward to
>>>>     supporting generic client is helpful I think.
>>>>
>>>>     Everything exists now other than the new grant_type exists now.
>>>>
>>>>     The work would mostly be putting together the examples based on
>>>>     supporting a minimal flow.
>>>>
>>>>     Now I should point out that there are people who believe that
>>>>     the default flow should be implicit with the "id_token"
>>>>     response_type and intend to support that.
>>>>     Phil's draft concentrates on only one use case.   Having a IdP
>>>>     deployment profile for it is not a problem, but it will not be
>>>>     for every IdP.   That is one of the reasons why discovery and
>>>>     registration are important features of Connect.
>>>>
>>>>     John B.
>>>>
>>>>
>>>>     On Jun 13, 2014, at 1:26 PM, Anil Saldhana
>>>>     > wrote:
>>>>
>>>>     > On 06/12/2014 04:18 PM, John Bradley wrote:
>>>>     >> All but a handful of OAuth WG participants participated in
>>>>     developing OpenID Connect.
>>>>     >>
>>>>     >> Yes some companies chose not to participate for whatever
>>>>     reasons and have not committed to the mutual non assert IPR
>>>>     agreement, and that is unfortunate, but not a reason to start
>>>>     again from scratch.
>>>>     >>
>>>>     >> Changing the OIDF IPR policy of totally open specifications
>>>>     based on non asserts is also not a option.
>>>>     >>
>>>>     >> I have made comments on the current draft of a4c.
>>>>     >>
>>>>     >> I think a profile of Connect introducing a grant_type
>>>>     returning only an id_token would be simpler than trying to do
>>>>     this as a separate spec.
>>>>     >> I do note that you can do effectively the same thing now by
>>>>     using a code response_type and a scope of openID.   This
>>>>     doesn't result in any extra user consent other than consenting
>>>>     to login to the RP the first time (though that consent can be
>>>>     given in advance out of band in a enterprise scenario.
>>>>     >>
>>>>     >> When developing Connect we debated having a token endpoint
>>>>     response with only a id_token but decided that it was not in
>>>>     the spirit of being a OAuth 2 profile. So we decided to return
>>>>     a access token even if the user info endpoint contains no
>>>>     claims other then sub. People almost always want more claims as
>>>>     they roll out a real deployment.  It is easy to add them if you
>>>>     have designed to be able to talk to a RS.
>>>>     >> OAuth without a RS is a touch not OAuth.
>>>>     >>
>>>>     >> a4c also completely ignores modern development environments
>>>>     like node.js where the client is in the user agent, that OAuth
>>>>     2 and Connect support.
>>>>     >>
>>>>     >> By the time the OAuth WG is done with a4c it will likely be
>>>>     a similar size as Connect if it addresses the same use cases.
>>>>     >>
>>>>     >> I still don't see the problem with having a deployment
>>>>     profile of Connect that can meet 100% of the current stated use
>>>>     case for a4c.
>>>>     > John - I am not fully familiar with the processes of OIDC.
>>>>      How much of an effort is it to get the deployment profile of
>>>>     OIDC connect rolling?
>>>>     >
>>>>     >>
>>>>     >> I expect that the people here involved in Connect will form
>>>>     there own opinions on comments regarding the number of
>>>>     participants and the quantity of the work and review.
>>>>     >>
>>>>     >> Regards
>>>>     >> John B.
>>>>     >>
>>>>     >>
>>>>     >>
>>>>     >>
>>>>     >> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt
>>>>     >>>     > wrote:
>>>>     >>
>>>>     >>> +1, after implementing OIDC I will support the claim that
>>>>     any SSO protocol with a minimal set of required features
>>>>     smaller than OIDC is insecure and any protocol with similar
>>>>     features but with different parameter names is just creating
>>>>     confusion and will increase chances of non-interoperable and
>>>>     insecure implementations
>>>>     >>>
>>>>     >>> Hans.
>>>>     >>>
>>>>     >>> On 6/12/14, 9:50 PM, Bill Burke wrote:
>>>>     >>>>
>>>>     >>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>>>>     >>>>> The OpenID Connect 2.0 COre specification alone is 86
>>>>     pages. It has
>>>>     >>>>> received review from maybe a dozen engineers within the
>>>>     OpenID community.
>>>>     >>>>>
>>>>     >>>> The OpenID Connect spec is 86 pages because it pretty much
>>>>     rehashes the
>>>>     >>>> OAuth2 spec walking through each flow and how Open ID
>>>>     Connect expands on
>>>>     >>>> that flow.  A4c looks like a subset of this work minus
>>>>     some additional
>>>>     >>>> claims and, IMO, is incomplete compared to OIDC.
>>>>     >>>>
>>>>     >>>> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We
>>>>     >>>> originally were creating our own oauth2 extension using
>>>>     JWT, but found
>>>>     >>>> that any feature we wanted to define already existed in
>>>>     OpenID Connect.
>>>>     >>>>  These guys have done great work.   Aren't many of you
>>>>     here authors of
>>>>     >>>> this spec and/or the same companies?!?  I think your
>>>>     energies are better
>>>>     >>>> focused on lobbying OIDC to join the IETF and this WG.
>>>>     >>>>
>>>>     >>>>
>>>>     >>>>
>>>>     >
>>>>
>>> _______________________________________________
>>> 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


--------------080803070701030509020600
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    let's not this disagreement over
        the need & relevance of a4c be conflated with
    the age-old blurriness between authz & authn - in no way are the
    two related

    

    paul 

    

    

    
On 6/13/14, 7:50 PM, John Bradley
      wrote:

    

    

      
      To be precise SAML, Connect, and a4c provide Assertion-based
      authentication of a claimant,  by a Verifier (IdP) to a relying
      party (RP) when the RP and the Verifier are not collocated ( i.e.,
      they are connected across a shared network)   SP-800-63 sec 9
      


      

      
Typically we call this authentication (authn) though that may
        just be a bad habit picked form SAML and other protocols use of
        the term.

      


      

      
It is true that people make horrible mistakes by ignoring the
        OAuth security considerations and inappropriately use OAuth
        directly for inferring that the presenter of the code or access
        token is the resource owner identified by the resource.

      


      

      
I had sort of hoped that broad support and adoption of OpenID
        Connect would help guide people in the correct direction.

      


      

      
If there is a need for a simpler IdP profile that is not
        interoperable across IdP (Not Dynamic) the question is if
        developers will be more motivated to use a profile of a larger
        standard as a starting point, or something presented as a
        limited authentication extension to OAuth 2.

      


      

      
Clearly nothing will stop some people from rolling there own
        authentication.  The question is what solution will get the best
        traction.

      


      

      
My fear is that if developers see this as two competing
        standards they will use that as justification to do there own
        thing rather than choose one.

      


      

      
At the end of the day what the profile looks like will likely
        be the same based on the use case.   The question is where will
        it be done and what do the politics look like to developers.

      


      

      
That is the short term question.

      


      

      
John B.

      


      

      

        

          
On Jun 13, 2014, at 7:15 PM, Phil Hunt <phil.hunt@oracle.com>
            wrote:

          

          

            

              
I think this is a false argument. What we desire to
                do or not do is not always the WG's choice.

              


              

              
It’s not me asking an authentication enhancement. The
                issue is whether to address improper authentication in
                the wild. Several of us all blogged about this a while a
                go and the problem with improper use of 6749 for
                authentication continues to grow.

              


              

              
Would it be better if we thought about this as the
                authentication “bug”?

              


              

              
I’m not sure everyone is on the same page regarding
                the term “authentication". In none of the scenarios
                discussed are we talking about “performing”
                authentication. We are talking about passing the
                authentication context from the AS in a non-opaque form
                to the client where the client is the audience of that
                information.

              


              

              
The authentication term is especially confusing
                because what developers *think* they are doing is
                authentication. It is not.

              


              

              

                
                

                

                  
On Jun 13, 2014, at 2:34 PM, Anil Saldhana <Anil.Saldhana@redhat.com>
                    wrote:

                  

                  

                    

                      
Brian - I agree. We
                        should neither overload nor extend the WG
                        charter to include any aspect of SSO or
                        authentication.

                        

                        I am hoping Prateek/Phil's feedback on OIDC can
                        be addressed by OIDC.  

                        

                        From John's email, it seemed like a path forward
                        is a Deployment Profile at OIDC. Hopefully
                        everybody will be happy with that.

                        

                        

                        On 06/13/2014 04:23 PM, Brian Campbell wrote:

                      

                      

                        
I agree that, at this point,
                          debating the details of a4c is premature.
                          SSO/authentication are not part of the WG
                          charter and, as I've said before, I'd object
                          to changing the charter to include it. Other
                          than a small but vocal minority, I think it's
                          fair to say that that's also been the
                          prevailing sentiment of this group.  

                          


                            

                            
On Fri, Jun 13,
                              2014 at 1:43 PM, John Bradley <ve7jtb@ve7jtb.com>
                              wrote:

                              
Hi Anil,

                                

                                There are a number of profile efforts
                                being looked at in the OIDF.   The
                                Mobile Network operators lead by the
                                GSMA are starting profile work on a
                                standard profile that will be supported
                                by mobile operators globally, that
                                includes looking at how a Client/RP/SP
                                can register there client once for use
                                across multiple IdP AS, as well as
                                standardized LoA and user-info schema
                                extensions.

                                

                                Torsten Lodderstedt is the chair of that
                                effort and can chime in.

                                

                                I suspect that a Basic IdP for SSO
                                profile is significantly less ambitious
                                than that and could be done in the
                                current Connect WG.

                                

                                If there is interest from the members to
                                start it.   The main time blocking
                                factor might be getting a new grant_type
                                spec approved in the the OAuth WG if we
                                wanted to support that.

                                

                                The IdP profile is simple they can
                                publish a discovery document saying they
                                only support that that limited feature
                                set, that way they would also be
                                compatible with existing connect
                                clients.

                                

                                {

                                "scopes_supported": ["openid"],

                                "response_types_supported":["code"],

                                "response_modes_supported":["query"],

                                "grant_types_supported":["authorization_code",

                                "code_id_token_only"],

                                "acr_values_supported":["2","3"]

                                }

                                

                                They don't need to publish one if they
                                don't intend to be discoverable to
                                clients but knowing what the path
                                forward to supporting generic client is
                                helpful I think.

                                

                                Everything exists now other than the new
                                grant_type exists now.

                                

                                The work would mostly be putting
                                together the examples based on
                                supporting a minimal flow.

                                

                                Now I should point out that there are
                                people who believe that the default flow
                                should be implicit with the "id_token"
                                response_type and intend to support
                                that.

                                Phil's draft concentrates on only one
                                use case.   Having a IdP deployment
                                profile for it is not a problem, but it
                                will not be for every IdP.   That is one
                                of the reasons why discovery and
                                registration are important features of
                                Connect.

                                

                                John B.

                                

                                  


                                    

                                    On Jun 13, 2014, at 1:26 PM, Anil
                                    Saldhana <Anil.Saldhana@redhat.com>

                                    wrote:

                                    

                                    > On 06/12/2014 04:18 PM, John
                                    Bradley wrote:

                                    >> All but a handful of OAuth
                                    WG participants participated in
                                    developing OpenID Connect.

                                    >>

                                    >> Yes some companies chose
                                    not to participate for whatever
                                    reasons and have not committed to
                                    the mutual non assert IPR agreement,
                                    and that is unfortunate, but not a
                                    reason to start again from scratch.

                                    >>

                                    >> Changing the OIDF IPR
                                    policy of totally open
                                    specifications based on non asserts
                                    is also not a option.

                                    >>

                                    >> I have made comments on the
                                    current draft of a4c.

                                    >>

                                    >> I think a profile of
                                    Connect introducing a grant_type
                                    returning only an id_token would be
                                    simpler than trying to do this as a
                                    separate spec.

                                    >> I do note that you can do
                                    effectively the same thing now by
                                    using a code response_type and a
                                    scope of openID.   This doesn't
                                    result in any extra user consent
                                    other than consenting to login to
                                    the RP the first time (though that
                                    consent can be given in advance out
                                    of band in a enterprise scenario.

                                    >>

                                    >> When developing Connect we
                                    debated having a token endpoint
                                    response with only a id_token but
                                    decided that it was not in the
                                    spirit of being a OAuth 2 profile.  
                                    So we decided to return a access
                                    token even if the user info endpoint
                                    contains no claims other then sub.  
                                    People almost always want more
                                    claims as they roll out a real
                                    deployment.  It is easy to add them
                                    if you have designed to be able to
                                    talk to a RS.

                                    >> OAuth without a RS is a
                                    touch not OAuth.

                                    >>

                                    >> a4c also completely ignores
                                    modern development environments like
                                    node.js where the client is in the
                                    user agent, that OAuth 2 and Connect
                                    support.

                                    >>

                                    >> By the time the OAuth WG is
                                    done with a4c it will likely be a
                                    similar size as Connect if it
                                    addresses the same use cases.

                                    >>

                                    >> I still don't see the
                                    problem with having a deployment
                                    profile of Connect that can meet
                                    100% of the current stated use case
                                    for a4c.

                                    > John - I am not fully familiar
                                    with the processes of OIDC.  How
                                    much of an effort is it to get the
                                    deployment profile of OIDC connect
                                    rolling?

                                    >

                                    >>

                                    >> I expect that the people
                                    here involved in Connect will form
                                    there own opinions on comments
                                    regarding the number of participants
                                    and the quantity of the work and
                                    review.

                                    >>

                                    >> Regards

                                    >> John B.

                                    >>

                                    >>

                                    >>

                                    >>

                                    >> On Jun 12, 2014, at 4:38
                                    PM, Hans Zandbelt <hzandbelt@pingidentity.com>

                                    wrote:

                                    >>

                                    >>> +1, after implementing
                                    OIDC I will support the claim that
                                    any SSO protocol with a minimal set
                                    of required features smaller than
                                    OIDC is insecure and any protocol
                                    with similar features but with
                                    different parameter names is just
                                    creating confusion and will increase
                                    chances of non-interoperable and
                                    insecure implementations

                                    >>>

                                    >>> Hans.

                                    >>>

                                    >>> On 6/12/14, 9:50 PM,
                                    Bill Burke wrote:

                                    >>>>

                                    >>>> On 6/12/2014 12:49
                                    PM, Prateek Mishra wrote:

                                    >>>>> The OpenID
                                    Connect 2.0 COre specification alone
                                    is 86 pages. It has

                                    >>>>> received review
                                    from maybe a dozen engineers within
                                    the OpenID community.

                                    >>>>>

                                    >>>> The OpenID Connect
                                    spec is 86 pages because it pretty
                                    much rehashes the

                                    >>>> OAuth2 spec walking
                                    through each flow and how Open ID
                                    Connect expands on

                                    >>>> that flow.  A4c
                                    looks like a subset of this work
                                    minus some additional

                                    >>>> claims and, IMO, is
                                    incomplete compared to OIDC.

                                    >>>>

                                    >>>> FWIW, add 5 Red Hat
                                    engineers to the "dozen" of
                                    reviewers.  We

                                    >>>> originally were
                                    creating our own oauth2 extension
                                    using JWT, but found

                                    >>>> that any feature we
                                    wanted to define already existed in
                                    OpenID Connect.

                                    >>>>  These guys have
                                    done great work.   Aren't many of
                                    you here authors of

                                    >>>> this spec and/or
                                    the same companies?!?  I think your
                                    energies are better

                                    >>>> focused on lobbying
                                    OIDC to join the IETF and this WG.

                                    >>>>

                                    >>>>

                                    >>>>

                                    >

                                  

                                

                              

                            

                          

                        

                      

                        

                    _______________________________________________

                    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


    

    

  


--------------080803070701030509020600--


From nobody Fri Jun 13 19:25:24 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDF41B2B1F for ; Fri, 13 Jun 2014 19:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.15
X-Spam-Level: 
X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvQE_S7wk25m for ; Fri, 13 Jun 2014 19:25:16 -0700 (PDT)
Received: from nm36-vm8.bullet.mail.bf1.yahoo.com (nm36-vm8.bullet.mail.bf1.yahoo.com [72.30.239.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD821B2B12 for ; Fri, 13 Jun 2014 19:25:16 -0700 (PDT)
Received: from [98.139.212.151] by nm36.bullet.mail.bf1.yahoo.com with NNFMP;  14 Jun 2014 02:25:15 -0000
Received: from [98.139.212.192] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jun 2014 02:25:15 -0000
Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 14 Jun 2014 02:25:15 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 354569.45648.bm@omp1001.mail.bf1.yahoo.com
Received: (qmail 43025 invoked by uid 60001); 14 Jun 2014 02:25:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402712715; bh=UprHrbrKeuQg3Jir2/XFlKuTCv5GlWVm+Phsjmhbipk=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KkzaLUlOikZuT1qc44fLkWqJ+mVVsXfFU+00un22OD909IBycqBjZlUHPYDTjYrilgrhY9Gdg+vMz9+KhEvgHYDktDtemNTwuoGC20/IgTgivaNBOgqIMMpLkp63CXOFPNDjb5sSR/gb33QcchEkXHoYpDzMXUw8PBVD+d7hGNU=
X-YMail-OSG: R6XoKagVM1n0OJxohrvjVt05dMSWcPzj1EKbbWyfiEyzVzE JTEi1xK6U3Ss2LzhKac.nPUhuY1IDmo0Pv84wDfLlImO8czev0oAIA8ru1_o KWUNlRg7yx27BkO5yESNsahQ2WFBZurLz_TnjdD.hvuHam6WErLezdGCKCbz 6V9cNvEK9Bjz5yspCfMobr_osO.aZIAntBRhmWPujmA7rh.LAX0jT99rzWMZ OitNDlfravmA0WxZTG7R4MegI9RRkAriA_SKvE8rpZrJnmyqIe9Gi2b51aVm fcwRnb2H4giSTJYxXdfyKr9G2CRBlKHsHeuHusAZr3g540pIdwKnrrYi8r1v h.xnBtUZbwHPNFADY04L39ZtYsWTCB5q93MFaSclQt_YL5GKI2wJt4fRb_ag AlaOegBgO_PqqfYRnwOz6HyFzCyJXdjHtldbQ1UknBICAf7wO1XzERtyeHSY 1v3ByoJq3N.dWyABPVUTkiFtqZj9GBvT5ntITGTZdOpArlLJa6horFTLb2Bk cs8msJ2xO7t1nRzDtaqKl8Za9pmgWALAR1znMohymmv8AcQGA19IvTbKKjOd XTYpDC5jKtjcA4NZKzo8cSF7DF.97PCQHV9MfgGkExSN40IVNLOStFQEqf3P 3jUd1952SLR3vLVZoBOa.xvLozQTDy8qn7ssI6k3fGw--
Received: from [99.31.212.42] by web142802.mail.bf1.yahoo.com via HTTP; Fri, 13 Jun 2014 19:25:15 PDT
X-Rocket-MIMEInfo: 002.001, TGV0J3MgY29tZSBiYWNrIHRvIHRoZSBwcm9ibGVtIHN0YXRlbWVudC4gwqBJdCBzb3VuZHMgbGlrZcKgT2F1dGggaXMgYmVpbmcgKG1pcyl1c2VkIGZvciBwbGFpbiBhdXRoZW50aWNhdGlvbiAsIHdlIHdhbnQgdG8gZGVhbCB3aXRoIHRoYXQsIGFuZCBPcGVuSUQgaXNuJ3QgYXBwYWVudGx5IHNhdGlzZnlpbmcgdGhlIG5lZWQgb2YgdGhlIGZvbGtzIGRvaW5nIHRoaXMuIMKgSXMgdGhhdCBlc3NlbnRpYWxseSBjb3JyZWN0PwoKV2hhdCBpcyB0aGUgdXNlIGNhc2UgdGhhdCB0aGUgbWluaW1hbCBPSURDIGltcGwBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.190.668
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <539A0FB1.1020106@pingidentity.com> <13F2E738-49BB-4EDB-9070-5A49448A6249@ve7jtb.com> <539B345A.7060808@redhat.com> <7082F35E-422C-441F-BBE8-158E4A9BA085@ve7jtb.com>  <539B6E7C.4030309@redhat.com> <998C2BA7-E47F-4A2D-BB5F-A21F47F41EB9@oracle.com> 
Message-ID: <1402712715.48771.YahooMailNeo@web142802.mail.bf1.yahoo.com>
Date: Fri, 13 Jun 2014 19:25:15 -0700
From: Bill Mills 
To: Phil Hunt , Anil Saldhana 
In-Reply-To: <998C2BA7-E47F-4A2D-BB5F-A21F47F41EB9@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1397251415-374426214-1402712715=:48771"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/vn0XkTQgHvI52ZayRmJtAAx21JM
Cc: oauth 
Subject: [OAUTH-WG] The underlying question Re: Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Jun 2014 02:25:19 -0000

--1397251415-374426214-1402712715=:48771
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Let's come back to the problem statement. =C2=A0It sounds like=C2=A0Oauth i=
s being (mis)used for plain authentication , we want to deal with that, and=
 OpenID isn't appaently satisfying the need of the folks doing this. =C2=A0=
Is that essentially correct?=0A=0AWhat is the use case that the minimal OID=
C implementation doesn't solve?=0A=0AIs the problem that people want to use=
 existing OAuth implementations and they would rather use/extend them than =
go to OIDC?=0A=0A=0A=0AOn Friday, June 13, 2014 4:15 PM, Phil Hunt  wrote:=0A =0A=0A=0AI think this is a false argument. What we=
 desire to do or not do is not always the WG's choice.=0A=0AIt=E2=80=99s no=
t me asking an authentication enhancement. The issue is whether to address =
improper authentication in the wild.=C2=A0Several of us all blogged about t=
his a while a go and the problem with improper use of 6749 for authenticati=
on continues to grow.=0A=0AWould it be better if we thought about this as t=
he authentication =E2=80=9Cbug=E2=80=9D?=0A=0AI=E2=80=99m not sure everyone=
 is on the same page regarding the term =E2=80=9Cauthentication". In none o=
f the scenarios discussed are we talking about =E2=80=9Cperforming=E2=80=9D=
 authentication. We are talking about passing the authentication context fr=
om the AS in a non-opaque form to the client where the client is the audien=
ce of that information.=0A=0AThe authentication term is especially confusin=
g because what developers *think* they are doing is authentication. It is n=
ot.=0A=0APhil=0A=0A@independentid=0Awww.independentid.comphil.hunt@oracle.c=
om=0A=0A=0A=0AOn Jun 13, 2014, at 2:34 PM, Anil Saldhana  wrote:=0A=0ABrian - I agree. We should neither overload nor extend=
 the WG charter to include any aspect of SSO or authentication.=0A>=0A>I am=
 hoping Prateek/Phil's feedback on OIDC can be addressed by=0A      OIDC.=
=C2=A0 =0A>=0A>From John's email, it seemed like a path forward is a Deploy=
ment=0A      Profile at OIDC. Hopefully everybody will be happy with that.=
=0A>=0A>=0A>On 06/13/2014 04:23 PM, Brian Campbell wrote:=0A>=0A>I agree th=
at, at this point, debating the details of a4c is premature. SSO/authentica=
tion are not part of the WG charter and, as I've said before, I'd object to=
 changing the charter to include it. Other than a small but vocal minority,=
 I think it's fair to say that that's also been the prevailing sentiment of=
 this group.=C2=A0 =0A>>=0A>>=0A>>=0A>>=0A>>On Fri, Jun 13, 2014 at 1:43 PM=
, John Bradley  wrote:=0A>>=0A>>Hi Anil,=0A>>>=0A>>>Ther=
e are a number of profile efforts being looked at in=0A              the OI=
DF. =C2=A0 The Mobile Network operators lead by the GSMA=0A              ar=
e starting profile work on a standard profile that will=0A              be =
supported by mobile operators globally, that includes=0A              looki=
ng at how a Client/RP/SP can register there client=0A              once for=
 use across multiple IdP AS, as well as=0A              standardized LoA an=
d user-info schema extensions.=0A>>>=0A>>>Torsten Lodderstedt is the chair =
of that effort and can=0A              chime in.=0A>>>=0A>>>I suspect that =
a Basic IdP for SSO profile is=0A              significantly less ambitious=
 than that and could be done=0A              in the current Connect WG.=0A>=
>>=0A>>>If there is interest from the members to start it. =C2=A0 The=0A   =
           main time blocking factor might be getting a new=0A             =
 grant_type spec approved in the the OAuth WG if we wanted=0A              =
to support that.=0A>>>=0A>>>The IdP profile is simple they can publish a di=
scovery=0A              document saying they only support that that limited=
=0A              feature set, that way they would also be compatible with=
=0A              existing connect clients.=0A>>>=0A>>>{=0A>>>"scopes_suppor=
ted": ["openid"],=0A>>>"response_types_supported":["code"],=0A>>>"response_=
modes_supported":["query"],=0A>>>"grant_types_supported":["authorization_co=
de",=0A              "code_id_token_only"],=0A>>>"acr_values_supported":["2=
","3"]=0A>>>}=0A>>>=0A>>>They don't need to publish one if they don't inten=
d to be=0A              discoverable to clients but knowing what the path f=
orward=0A              to supporting generic client is helpful I think.=0A>=
>>=0A>>>Everything exists now other than the new grant_type exists=0A      =
        now.=0A>>>=0A>>>The work would mostly be putting together the examp=
les=0A              based on supporting a minimal flow.=0A>>>=0A>>>Now I sh=
ould point out that there are people who believe=0A              that the d=
efault flow should be implicit with the=0A              "id_token" response=
_type and intend to support that.=0A>>>Phil's draft concentrates on only on=
e use case. =C2=A0 Having a=0A              IdP deployment profile for it i=
s not a problem, but it=0A              will not be for every IdP. =C2=A0 T=
hat is one of the reasons=0A              why discovery and registration ar=
e important features of=0A              Connect.=0A>>>=0A>>>John B.=0A>>>=
=0A>>>=0A>>>=0A>>>On Jun 13, 2014, at 1:26 PM, Anil Saldhana  wrote:=0A>>>=0A>>>> On 06/12/2014 04:18 PM, John Bradley wrote=
:=0A>>>>> All but a handful of OAuth WG participants=0A                  pa=
rticipated in developing OpenID Connect.=0A>>>>>=0A>>>>> Yes some companies=
 chose not to participate=0A                  for whatever reasons and have=
 not committed to the=0A                  mutual non assert IPR agreement, =
and that is=0A                  unfortunate, but not a reason to start agai=
n from=0A                  scratch.=0A>>>>>=0A>>>>> Changing the OIDF IPR p=
olicy of totally open=0A                  specifications based on non asser=
ts is also not a=0A                  option.=0A>>>>>=0A>>>>> I have made co=
mments on the current draft of=0A                  a4c.=0A>>>>>=0A>>>>> I t=
hink a profile of Connect introducing a=0A                  grant_type retu=
rning only an id_token would be simpler=0A                  than trying to =
do this as a separate spec.=0A>>>>> I do note that you can do effectively t=
he=0A                  same thing now by using a code response_type and a=
=0A                  scope of openID. =C2=A0 This doesn't result in any ext=
ra=0A                  user consent other than consenting to login to the R=
P=0A                  the first time (though that consent can be given in=
=0A                  advance out of band in a enterprise scenario.=0A>>>>>=
=0A>>>>> When developing Connect we debated having a=0A                  to=
ken endpoint response with only a id_token but=0A                  decided =
that it was not in the spirit of being a OAuth=0A                  2 profil=
e. =C2=A0 So we decided to return a access token=0A                  even i=
f the user info endpoint contains no claims=0A                  other then =
sub. =C2=A0 People almost always want more=0A                  claims as th=
ey roll out a real deployment. =C2=A0It is easy=0A                  to add =
them if you have designed to be able to talk to=0A                  a RS.=
=0A>>>>> OAuth without a RS is a touch not OAuth.=0A>>>>>=0A>>>>> a4c also =
completely ignores modern=0A                  development environments like=
 node.js where the client=0A                  is in the user agent, that OA=
uth 2 and Connect=0A                  support.=0A>>>>>=0A>>>>> By the time =
the OAuth WG is done with a4c it=0A                  will likely be a simil=
ar size as Connect if it=0A                  addresses the same use cases.=
=0A>>>>>=0A>>>>> I still don't see the problem with having a=0A            =
      deployment profile of Connect that can meet 100% of=0A               =
   the current stated use case for a4c.=0A>>>> John - I am not fully famili=
ar with the processes=0A                  of OIDC. =C2=A0How much of an eff=
ort is it to get the=0A                  deployment profile of OIDC connect=
 rolling?=0A>>>>=0A>>>>>=0A>>>>> I expect that the people here involved in=
=0A                  Connect will form there own opinions on comments=0A   =
               regarding the number of participants and the quantity=0A    =
              of the work and review.=0A>>>>>=0A>>>>> Regards=0A>>>>> John =
B.=0A>>>>>=0A>>>>>=0A>>>>>=0A>>>>>=0A>>>>> On Jun 12, 2014, at 4:38 PM, Han=
s Zandbelt=0A                   wrote:=0A>>>>>=
=0A>>>>>> +1, after implementing OIDC I will=0A                  support th=
e claim that any SSO protocol with a minimal=0A                  set of req=
uired features smaller than OIDC is insecure=0A                  and any pr=
otocol with similar features but with=0A                  different paramet=
er names is just creating confusion=0A                  and will increase c=
hances of non-interoperable and=0A                  insecure implementation=
s=0A>>>>>>=0A>>>>>> Hans.=0A>>>>>>=0A>>>>>> On 6/12/14, 9:50 PM, Bill Burke=
 wrote:=0A>>>>>>>=0A>>>>>>> On 6/12/2014 12:49 PM, Prateek Mishra=0A       =
           wrote:=0A>>>>>>>> The OpenID Connect 2.0 COre=0A                =
  specification alone is 86 pages. It has=0A>>>>>>>> received review from m=
aybe a=0A                  dozen engineers within the OpenID community.=0A>=
>>>>>>>=0A>>>>>>> The OpenID Connect spec is 86 pages=0A                  b=
ecause it pretty much rehashes the=0A>>>>>>> OAuth2 spec walking through ea=
ch flow=0A                  and how Open ID Connect expands on=0A>>>>>>> th=
at flow. =C2=A0A4c looks like a subset=0A                  of this work min=
us some additional=0A>>>>>>> claims and, IMO, is incomplete=0A             =
     compared to OIDC.=0A>>>>>>>=0A>>>>>>> FWIW, add 5 Red Hat engineers to=
 the=0A                  "dozen" of reviewers. =C2=A0We=0A>>>>>>> originall=
y were creating our own=0A                  oauth2 extension using JWT, but=
 found=0A>>>>>>> that any feature we wanted to define=0A                  a=
lready existed in OpenID Connect.=0A>>>>>>> =C2=A0These guys have done grea=
t work. =C2=A0=0A                  Aren't many of you here authors of=0A>>>=
>>>> this spec and/or the same=0A                  companies?!? =C2=A0I thi=
nk your energies are better=0A>>>>>>> focused on lobbying OIDC to join the=
=0A                  IETF and this WG.=0A>>>>>>>=0A>>>>>>>=0A>>>>>>>=0A>>>>=
=0A>>>=0A=C2=A0 =0A_______________________________________________=0A>OAuth=
 mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oa=
uth=0A>=0A=0A_______________________________________________=0AOAuth mailin=
g list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth
--1397251415-374426214-1402712715=:48771
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Let's come back =
to the problem statement.  It sounds like Oauth is being (mis)used for plain authentication , we want to de=
al with that, and OpenID isn't appaently satisfying the need of the folks d=
oing this.  Is that essentially correct?

=

What is the use case that the minimal OIDC implem=
entation
 doesn't solve?

Is t=
he problem that people want to use existing OAuth implementations and they =
would rather use/extend them than go to OIDC?
 
 
 
 


 =
 On Friday, June 13, 2014 4:15 PM, Phil Hunt <phil.hunt@=
oracle.com> wrote:
  
  

 
I think this is a false argument. What we desire =
to do or not do is not always the WG's choice.

It=E2=80=99s=0A not me asking an authentication enhancement. Th=
e issue is whether to address improper authentication in the wild. Sev=
eral of us all blogged about this a while a go and the problem with imprope=
r use of 6749 for authentication continues to grow.

Would it be better if we thought about this as the authent=
ication =E2=80=9Cbug=E2=80=9D?

I=E2=
=80=99m not sure everyone is on the same page regarding the term =E2=80=9Ca=
uthentication". In none of the scenarios discussed are we talking about =E2=
=80=9Cperforming=E2=80=9D authentication. We are talking about passing the =
authentication context from the AS in a non-opaque form to the client where=
 the client is the audience of that information.

The authentication term is especially confusing because what =
developers *think* they are doing is authentication. It is not.
<=
br clear=3D"none">
=0A
<=
span class=3D"yiv1602813760Apple-style-span" style=3D"border-collapse:separ=
ate;border-spacing:0px;">

=0A
=0A
On Jun 13, 2014, at 2:34 PM=
, Anil Saldhana <Anil.Saldhana@redhat.com> wrote:

=0A=
  =0A    =0A  =0A  
=0A    
=
Brian - I agree. We should neither=0A      overload nor extend the WG chart=
er to include any aspect of SSO or=0A      authentication.
=0A      
=0A      I am hoping Prateek/Phil's feedback =
on OIDC can be addressed by=0A      OIDC.  
=0A     =
 
=0A      From John's email, it seemed like a path forwa=
rd is a Deployment=0A      Profile at OIDC. Hopefully everybody will be hap=
py with that.
=0A      
=0A      
=0A      On 06/13/2014 04:23 PM, Brian Campbell wrote:
=0A    
=0A    
=0A      
I agree that, at this point, debating the details=0A        of a4c=
 is premature. SSO/authentication are not part of the WG=0A        charter =
and, as I've said before, I'd object to changing the=0A        charter to i=
nclude it. Other than a small but vocal minority, I=0A        think it's fa=
ir to say that that's also been the prevailing=0A        sentiment of this =
group.  
=0A        

=0A          
=0A          On Fri, Jun 13, 2014 at 1:43 PM, John=
=0A            Bradley <ve7jtb@ve7jtb.com>=0A            wrote:=0A            
Hi Anil,
=0A              
=0A        =
      There are a number of profile efforts being looked at in=0A          =
    the OIDF.   The Mobile Network operators lead by the GSMA=0A      =
        are starting profile work on a standard profile that will=0A       =
       be supported by mobile operators globally, that includes=0A         =
     looking at how a Client/RP/SP can register there client=0A            =
  once for use across multiple IdP AS, as well as=0A              standardi=
zed LoA and user-info schema extensions.
=0A             =
 
=0A              Torsten Lodderstedt is the chair of th=
at effort and can=0A              chime in.
=0A          =
    
=0A              I suspect that a Basic IdP for SSO =
profile is=0A              significantly less ambitious than that and could=
 be done=0A              in the current Connect WG.
=0A  =
            
=0A              If there is interest from t=
he members to start it.   The=0A              main time blocking facto=
r might be getting a new=0A              grant_type spec approved in the th=
e OAuth WG if we wanted=0A              to support that.
=
=0A              
=0A              The IdP profile is sim=
ple they can publish a discovery=0A              document saying they only =
support that that limited=0A              feature set, that way they would =
also be compatible with=0A              existing connect clients.
=0A              
=0A              {
=0A              "scopes_supported": ["openid"],
=0A              "response_types_supported":["code"],
=
=0A              "response_modes_supported":["query"],
=
=0A              "grant_types_supported":["authorization_code",=0A         =
     "code_id_token_only"],
=0A              "acr_values_=
supported":["2","3"]
=0A              }
=0A              
=0A              They don't need to pu=
blish one if they don't intend to be=0A              discoverable to client=
s but knowing what the path forward=0A              to supporting generic c=
lient is helpful I think.
=0A              
=0A              Everything exists now other than the new grant_type e=
xists=0A              now.
=0A              
=0A              The work would mostly be putting together the exampl=
es=0A              based on supporting a minimal flow.
=
=0A              
=0A              Now I should point out=
 that there are people who believe=0A              that the default flow sh=
ould be implicit with the=0A              "id_token" response_type and inte=
nd to support that.
=0A              Phil's draft concent=
rates on only one use case.   Having a=0A              IdP deployment =
profile for it is not a problem, but it=0A              will not be for eve=
ry IdP.   That is one of the reasons=0A              why discovery and=
 registration are important features of=0A              Connect.
=0A              
=0A              John B.
=0A              
=0A                

=0A                  
=0A                  On Jun 13,=
 2014, at 1:26 PM, Anil Saldhana <Anil.Saldhana@redhat.com>=0A               =
   wrote:
=0A                  
=0A    =
              > On 06/12/2014 04:18 PM, John Bradley wrote:
=0A                  >> All but a handful of OAuth WG participa=
nts=0A                  participated in developing OpenID Connect.
=0A                  >>
=0A              =
    >> Yes some companies chose not to participate=0A                =
  for whatever reasons and have not committed to the=0A                  mu=
tual non assert IPR agreement, and that is=0A                  unfortunate,=
 but not a reason to start again from=0A                  scratch.
=0A                  >>
=0A              =
    >> Changing the OIDF IPR policy of totally open=0A               =
   specifications based on non asserts is also not a=0A                  op=
tion.
=0A                  >>
=0A=
                  >> I have made comments on the current draft of=0A =
                 a4c.
=0A                  >>
=0A                  >> I think a profile of Connect int=
roducing a=0A                  grant_type returning only an id_token would =
be simpler=0A                  than trying to do this as a separate spec.=0A                  >> I do note that you can do ef=
fectively the=0A                  same thing now by using a code response_t=
ype and a=0A                  scope of openID.   This doesn't result i=
n any extra=0A                  user consent other than consenting to login=
 to the RP=0A                  the first time (though that consent can be g=
iven in=0A                  advance out of band in a enterprise scenario.=0A                  >>
=0A       =
           >> When developing Connect we debated having a=0A         =
         token endpoint response with only a id_token but=0A               =
   decided that it was not in the spirit of being a OAuth=0A               =
   2 profile.   So we decided to return a access token=0A             =
     even if the user info endpoint contains no claims=0A                  =
other then sub.   People almost always want more=0A                  c=
laims as they roll out a real deployment.  It is easy=0A              =
    to add them if you have designed to be able to talk to=0A              =
    a RS.
=0A                  >> OAuth without a R=
S is a touch not OAuth.
=0A                  >>
=0A                  >> a4c also completely ignores mo=
dern=0A                  development environments like node.js where the cl=
ient=0A                  is in the user agent, that OAuth 2 and Connect=0A =
                 support.
=0A                  >>=0A                  >> By the time the OAuth WG is =
done with a4c it=0A                  will likely be a similar size as Conne=
ct if it=0A                  addresses the same use cases.
=0A                  >>
=0A                  >=
> I still don't see the problem with having a=0A                  deploy=
ment profile of Connect that can meet 100% of=0A                  the curre=
nt stated use case for a4c.
=0A                  > Joh=
n - I am not fully familiar with the processes=0A                  of OIDC.=
  How much of an effort is it to get the=0A                  deploymen=
t profile of OIDC connect rolling?
=0A                  &=
gt;
=0A                  >>
=0A  =
                >> I expect that the people here involved in=0A      =
            Connect will form there own opinions on comments=0A            =
      regarding the number of participants and the quantity=0A             =
     of the work and review.
=0A                  >>=
;
=0A                  >> Regards
=0A                  >> John B.
=0A               =
   >>
=0A                  >>
=0A                  >>
=0A                  >=
;>
=0A                  >> On Jun 12, 2014, at 4=
:38 PM, Hans Zandbelt=0A                  <hzandbelt@pingidentity.com>=
=0A                  wrote:
=0A                  >>=

=0A                  >>> +1, after implementing=
 OIDC I will=0A                  support the claim that any SSO protocol wi=
th a minimal=0A                  set of required features smaller than OIDC=
 is insecure=0A                  and any protocol with similar features but=
 with=0A                  different parameter names is just creating confus=
ion=0A                  and will increase chances of non-interoperable and=
=0A                  insecure implementations
=0A        =
          >>>
=0A                  >>> =
Hans.
=0A                  >>>
=0A                  >>> On 6/12/14, 9:50 PM, Bill Burke wrote:=0A                  >>>>
=
=0A                  >>>> On 6/12/2014 12:49 PM, Prateek Mishra=
=0A                  wrote:
=0A                  >>=
>>> The OpenID Connect 2.0 COre=0A                  specification =
alone is 86 pages. It has
=0A                  >>&g=
t;>> received review from maybe a=0A                  dozen engineers=
 within the OpenID community.
=0A                  >&g=
t;>>>
=0A                  >>>> The =
OpenID Connect spec is 86 pages=0A                  because it pretty much =
rehashes the
=0A                  >>>> OAuth2=
 spec walking through each flow=0A                  and how Open ID Connect=
 expands on
=0A                  >>>> that fl=
ow.  A4c looks like a subset=0A                  of this work minus so=
me additional
=0A                  >>>> claim=
s and, IMO, is incomplete=0A                  compared to OIDC.
=0A                  >>>>
=0A         =
         >>>> FWIW, add 5 Red Hat engineers to the=0A          =
        "dozen" of reviewers.  We
=0A               =
   >>>> originally were creating our own=0A                  oa=
uth2 extension using JWT, but found
=0A                  =
>>>> that any feature we wanted to define=0A                  a=
lready existed in OpenID Connect.
=0A                  &g=
t;>>>  These guys have done great work.  =0A            =
      Aren't many of you here authors of
=0A             =
     >>>> this spec and/or the same=0A                  compani=
es?!?  I think your energies are better
=0A         =
         >>>> focused on lobbying OIDC to join the=0A          =
        IETF and this WG.
=0A                  >>&g=
t;>
=0A                  >>>>
=0A                  >>>>
=0A          =
        >
=0A                
=0A              =0A            
=0A          
=0A        
=0A    =
  
=0A    
=0A     =0A  
=0A=0A_________________=
______________________________
OAuth mailing list
OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth


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


      
--1397251415-374426214-1402712715=:48771--


From nobody Sat Jun 14 04:42:30 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9980F1B2822 for ; Sat, 14 Jun 2014 04:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level: 
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZ73QARn1TTw for ; Sat, 14 Jun 2014 04:42:26 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEBB1B27F0 for ; Sat, 14 Jun 2014 04:42:25 -0700 (PDT)
X-AuditID: 1209190f-f79576d00000578b-ea-539c352005ce
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id FF.91.22411.0253C935; Sat, 14 Jun 2014 07:42:24 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s5EBgMNr000302; Sat, 14 Jun 2014 07:42:23 -0400
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s5EBgJbP020857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 14 Jun 2014 07:42:21 -0400
Message-ID: <539C350D.3030808@mit.edu>
Date: Sat, 14 Jun 2014 07:42:05 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Anil Saldhana , Brian Campbell , John Bradley 
References: <53901FE3.7020709@gmx.net> <8AB7F237-D90E-46D7-B926-8B74A1AE5EFC@yahoo.com> <4E1F6AAD24975D4BA5B16804296739439AD52DCC@TK5EX14MBXC294.redmond.corp.microsoft.com> <1401996041.13164.YahooMailNeo@web142802.mail.bf1.yahoo.com>  <53995F27.7090903@gmx.net>  <5399AB7C.5060508@mit.edu> <5399DA1C.4090409@oracle.com> <539A0497.7070906@redhat.com> <539A0FB1.1020106@pingidentity.com> <13F2E738-49BB-4EDB-9070-5A49448A6249@ve7jtb.com> <539B345A.7060808@redhat.com> <7082F35E-422C-441F-BBE8-158E4A9BA085@ve7jtb.com>  <539B6E7C.4030309@redhat.com>
In-Reply-To: <539B6E7C.4030309@redhat.com>
Content-Type: multipart/alternative; boundary="------------010801000307080805090700"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsUixCmqratgOifYoP0Dr8WLxS8ZLVb/v8lo cfLtKzaL1Xf/sjmweCxZ8pPJ4+7Riywe7/ddZfO4fXsjSwBLFJdNSmpOZllqkb5dAlfG99dr WAoer2CsOL72JEsD44ncLkYODgkBE4m9jwy7GDmBTDGJC/fWs3UxcnEICcxmkrg+6xwzhLOR UWLGvrVMEM5tJomOA8dYQFp4BdQkjn+8A2azCKhKfH60hw3EZgOy56+8xQRiiwpESdy51M8K US8ocXLmExaQQSICvYwSEx4vYAdJMAtISTxqOQU2SFjAXWJv71WobWdZJR782s0CciungJbE p+UZEPVhEj/btrBMYBSYhWTuLCSpWUAdzALWEt92F0GE5SW2v53DDGFrS6zqPcuELL6AkW0V o2xKbpVubmJmTnFqsm5xcmJeXmqRrolebmaJXmpK6SZGcGxI8u9g/HZQ6RCjAAejEg/vCtnZ wUKsiWXFlbmHGCU5mJREede9AArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4T1jMCdYiDclsbIq tSgfJiXNwaIkzvvW2ipYSCA9sSQ1OzW1ILUIJivDwaEkwVtjAtQoWJSanlqRlplTgpBm4uAE Gc4DNHwKSA1vcUFibnFmOkT+FKOilDhvsDFQQgAkkVGaB9cLS12vGMWBXhHmnQ7SzgNMe3Dd r4AGMwENvrl4FsjgkkSElFQDY31B4lv2mUsfW/E8ea3q5GCvMnlH9hnRSfunFO9Zv/anefX3 aXVu2Z7LBf8lbeUJLWaq4OjNrruwf37t8fnNP95+NLg5NebbJ8ON8tfaD3+6vzLNQkjQ8F68 5X8dnY4b39YV/H6fdzSt66r/vbV/NwtIN5pfXfynLa69oYdRIveT7c/MR09n31diKc5INNRi LipOBAAsh352OAMAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/cuMdgHNOLato5K0DPDIcy3eaZiQ
Cc: oauth 
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Jun 2014 11:42:28 -0000

This is a multi-part message in MIME format.
--------------010801000307080805090700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

+1

This is clearly an extension to OIDC and should be handled in the OIDF 
so that it doesn't needlessly compete with OIDC. I see no reason for the 
IETF to take on this work.

  -- Justin

On 6/13/2014 5:34 PM, Anil Saldhana wrote:
> Brian - I agree. We should neither overload nor extend the WG charter 
> to include any aspect of SSO or authentication.
>
> I am hoping Prateek/Phil's feedback on OIDC can be addressed by OIDC.
>
> From John's email, it seemed like a path forward is a Deployment 
> Profile at OIDC. Hopefully everybody will be happy with that.
>
>
> On 06/13/2014 04:23 PM, Brian Campbell wrote:
>> I agree that, at this point, debating the details of a4c is 
>> premature. SSO/authentication are not part of the WG charter and, as 
>> I've said before, I'd object to changing the charter to include it. 
>> Other than a small but vocal minority, I think it's fair to say that 
>> that's also been the prevailing sentiment of this group.
>>
>>
>> On Fri, Jun 13, 2014 at 1:43 PM, John Bradley > > wrote:
>>
>>     Hi Anil,
>>
>>     There are a number of profile efforts being looked at in the
>>     OIDF.   The Mobile Network operators lead by the GSMA are
>>     starting profile work on a standard profile that will be
>>     supported by mobile operators globally, that includes looking at
>>     how a Client/RP/SP can register there client once for use across
>>     multiple IdP AS, as well as standardized LoA and user-info schema
>>     extensions.
>>
>>     Torsten Lodderstedt is the chair of that effort and can chime in.
>>
>>     I suspect that a Basic IdP for SSO profile is significantly less
>>     ambitious than that and could be done in the current Connect WG.
>>
>>     If there is interest from the members to start it.   The main
>>     time blocking factor might be getting a new grant_type spec
>>     approved in the the OAuth WG if we wanted to support that.
>>
>>     The IdP profile is simple they can publish a discovery document
>>     saying they only support that that limited feature set, that way
>>     they would also be compatible with existing connect clients.
>>
>>     {
>>     "scopes_supported": ["openid"],
>>     "response_types_supported":["code"],
>>     "response_modes_supported":["query"],
>>     "grant_types_supported":["authorization_code", "code_id_token_only"],
>>     "acr_values_supported":["2","3"]
>>     }
>>
>>     They don't need to publish one if they don't intend to be
>>     discoverable to clients but knowing what the path forward to
>>     supporting generic client is helpful I think.
>>
>>     Everything exists now other than the new grant_type exists now.
>>
>>     The work would mostly be putting together the examples based on
>>     supporting a minimal flow.
>>
>>     Now I should point out that there are people who believe that the
>>     default flow should be implicit with the "id_token" response_type
>>     and intend to support that.
>>     Phil's draft concentrates on only one use case.   Having a IdP
>>     deployment profile for it is not a problem, but it will not be
>>     for every IdP.   That is one of the reasons why discovery and
>>     registration are important features of Connect.
>>
>>     John B.
>>
>>
>>     On Jun 13, 2014, at 1:26 PM, Anil Saldhana
>>     > wrote:
>>
>>     > On 06/12/2014 04:18 PM, John Bradley wrote:
>>     >> All but a handful of OAuth WG participants participated in
>>     developing OpenID Connect.
>>     >>
>>     >> Yes some companies chose not to participate for whatever
>>     reasons and have not committed to the mutual non assert IPR
>>     agreement, and that is unfortunate, but not a reason to start
>>     again from scratch.
>>     >>
>>     >> Changing the OIDF IPR policy of totally open specifications
>>     based on non asserts is also not a option.
>>     >>
>>     >> I have made comments on the current draft of a4c.
>>     >>
>>     >> I think a profile of Connect introducing a grant_type
>>     returning only an id_token would be simpler than trying to do
>>     this as a separate spec.
>>     >> I do note that you can do effectively the same thing now by
>>     using a code response_type and a scope of openID.   This doesn't
>>     result in any extra user consent other than consenting to login
>>     to the RP the first time (though that consent can be given in
>>     advance out of band in a enterprise scenario.
>>     >>
>>     >> When developing Connect we debated having a token endpoint
>>     response with only a id_token but decided that it was not in the
>>     spirit of being a OAuth 2 profile.   So we decided to return a
>>     access token even if the user info endpoint contains no claims
>>     other then sub.   People almost always want more claims as they
>>     roll out a real deployment.  It is easy to add them if you have
>>     designed to be able to talk to a RS.
>>     >> OAuth without a RS is a touch not OAuth.
>>     >>
>>     >> a4c also completely ignores modern development environments
>>     like node.js where the client is in the user agent, that OAuth 2
>>     and Connect support.
>>     >>
>>     >> By the time the OAuth WG is done with a4c it will likely be a
>>     similar size as Connect if it addresses the same use cases.
>>     >>
>>     >> I still don't see the problem with having a deployment profile
>>     of Connect that can meet 100% of the current stated use case for a4c.
>>     > John - I am not fully familiar with the processes of OIDC.  How
>>     much of an effort is it to get the deployment profile of OIDC
>>     connect rolling?
>>     >
>>     >>
>>     >> I expect that the people here involved in Connect will form
>>     there own opinions on comments regarding the number of
>>     participants and the quantity of the work and review.
>>     >>
>>     >> Regards
>>     >> John B.
>>     >>
>>     >>
>>     >>
>>     >>
>>     >> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt
>>     >
>>     wrote:
>>     >>
>>     >>> +1, after implementing OIDC I will support the claim that any
>>     SSO protocol with a minimal set of required features smaller than
>>     OIDC is insecure and any protocol with similar features but with
>>     different parameter names is just creating confusion and will
>>     increase chances of non-interoperable and insecure implementations
>>     >>>
>>     >>> Hans.
>>     >>>
>>     >>> On 6/12/14, 9:50 PM, Bill Burke wrote:
>>     >>>>
>>     >>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote:
>>     >>>>> The OpenID Connect 2.0 COre specification alone is 86
>>     pages. It has
>>     >>>>> received review from maybe a dozen engineers within the
>>     OpenID community.
>>     >>>>>
>>     >>>> The OpenID Connect spec is 86 pages because it pretty much
>>     rehashes the
>>     >>>> OAuth2 spec walking through each flow and how Open ID
>>     Connect expands on
>>     >>>> that flow.  A4c looks like a subset of this work minus some
>>     additional
>>     >>>> claims and, IMO, is incomplete compared to OIDC.
>>     >>>>
>>     >>>> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We
>>     >>>> originally were creating our own oauth2 extension using JWT,
>>     but found
>>     >>>> that any feature we wanted to define already existed in
>>     OpenID Connect.
>>     >>>>  These guys have done great work. Aren't many of you here
>>     authors of
>>     >>>> this spec and/or the same companies?!?  I think your
>>     energies are better
>>     >>>> focused on lobbying OIDC to join the IETF and this WG.
>>     >>>>
>>     >>>>
>>     >>>>
>>     >
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------010801000307080805090700
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
+1

      

      This is clearly an extension to OIDC and should be handled in the
      OIDF so that it doesn't needlessly compete with OIDC. I see no
      reason for the IETF to take on this work.

      

       -- Justin

      

      On 6/13/2014 5:34 PM, Anil Saldhana wrote:

    

    

      
      
Brian - I agree. We should neither
        overload nor extend the WG charter to include any aspect of SSO
        or authentication.

        

        I am hoping Prateek/Phil's feedback on OIDC can be addressed by
        OIDC.  

        

        From John's email, it seemed like a path forward is a Deployment
        Profile at OIDC. Hopefully everybody will be happy with that.

        

        

        On 06/13/2014 04:23 PM, Brian Campbell wrote:

      

      

        
I agree that, at this point, debating the details
          of a4c is premature. SSO/authentication are not part of the WG
          charter and, as I've said before, I'd object to changing the
          charter to include it. Other than a small but vocal minority,
          I think it's fair to say that that's also been the prevailing
          sentiment of this group.  

          


            

            
On Fri, Jun 13, 2014 at 1:43 PM,
              John Bradley <ve7jtb@ve7jtb.com>
              wrote:

              
Hi
                Anil,

                

                There are a number of profile efforts being looked at in
                the OIDF.   The Mobile Network operators lead by the
                GSMA are starting profile work on a standard profile
                that will be supported by mobile operators globally,
                that includes looking at how a Client/RP/SP can register
                there client once for use across multiple IdP AS, as
                well as standardized LoA and user-info schema
                extensions.

                

                Torsten Lodderstedt is the chair of that effort and can
                chime in.

                

                I suspect that a Basic IdP for SSO profile is
                significantly less ambitious than that and could be done
                in the current Connect WG.

                

                If there is interest from the members to start it.   The
                main time blocking factor might be getting a new
                grant_type spec approved in the the OAuth WG if we
                wanted to support that.

                

                The IdP profile is simple they can publish a discovery
                document saying they only support that that limited
                feature set, that way they would also be compatible with
                existing connect clients.

                

                {

                "scopes_supported": ["openid"],

                "response_types_supported":["code"],

                "response_modes_supported":["query"],

                "grant_types_supported":["authorization_code",
                "code_id_token_only"],

                "acr_values_supported":["2","3"]

                }

                

                They don't need to publish one if they don't intend to
                be discoverable to clients but knowing what the path
                forward to supporting generic client is helpful I think.

                

                Everything exists now other than the new grant_type
                exists now.

                

                The work would mostly be putting together the examples
                based on supporting a minimal flow.

                

                Now I should point out that there are people who believe
                that the default flow should be implicit with the
                "id_token" response_type and intend to support that.

                Phil's draft concentrates on only one use case.   Having
                a IdP deployment profile for it is not a problem, but it
                will not be for every IdP.   That is one of the reasons
                why discovery and registration are important features of
                Connect.

                

                John B.

                

                  


                    

                    On Jun 13, 2014, at 1:26 PM, Anil Saldhana <Anil.Saldhana@redhat.com>
                    wrote:

                    

                    > On 06/12/2014 04:18 PM, John Bradley wrote:

                    >> All but a handful of OAuth WG participants
                    participated in developing OpenID Connect.

                    >>

                    >> Yes some companies chose not to participate
                    for whatever reasons and have not committed to the
                    mutual non assert IPR agreement, and that is
                    unfortunate, but not a reason to start again from
                    scratch.

                    >>

                    >> Changing the OIDF IPR policy of totally
                    open specifications based on non asserts is also not
                    a option.

                    >>

                    >> I have made comments on the current draft
                    of a4c.

                    >>

                    >> I think a profile of Connect introducing a
                    grant_type returning only an id_token would be
                    simpler than trying to do this as a separate spec.

                    >> I do note that you can do effectively the
                    same thing now by using a code response_type and a
                    scope of openID.   This doesn't result in any extra
                    user consent other than consenting to login to the
                    RP the first time (though that consent can be given
                    in advance out of band in a enterprise scenario.

                    >>

                    >> When developing Connect we debated having a
                    token endpoint response with only a id_token but
                    decided that it was not in the spirit of being a
                    OAuth 2 profile.   So we decided to return a access
                    token even if the user info endpoint contains no
                    claims other then sub.   People almost always want
                    more claims as they roll out a real deployment.  It
                    is easy to add them if you have designed to be able
                    to talk to a RS.

                    >> OAuth without a RS is a touch not OAuth.

                    >>

                    >> a4c also completely ignores modern
                    development environments like node.js where the
                    client is in the user agent, that OAuth 2 and
                    Connect support.

                    >>

                    >> By the time the OAuth WG is done with a4c
                    it will likely be a similar size as Connect if it
                    addresses the same use cases.

                    >>

                    >> I still don't see the problem with having a
                    deployment profile of Connect that can meet 100% of
                    the current stated use case for a4c.

                    > John - I am not fully familiar with the
                    processes of OIDC.  How much of an effort is it to
                    get the deployment profile of OIDC connect rolling?

                    >

                    >>

                    >> I expect that the people here involved in
                    Connect will form there own opinions on comments
                    regarding the number of participants and the
                    quantity of the work and review.

                    >>

                    >> Regards

                    >> John B.

                    >>

                    >>

                    >>

                    >>

                    >> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt
                    <hzandbelt@pingidentity.com>
                    wrote:

                    >>

                    >>> +1, after implementing OIDC I will
                    support the claim that any SSO protocol with a
                    minimal set of required features smaller than OIDC
                    is insecure and any protocol with similar features
                    but with different parameter names is just creating
                    confusion and will increase chances of
                    non-interoperable and insecure implementations

                    >>>

                    >>> Hans.

                    >>>

                    >>> On 6/12/14, 9:50 PM, Bill Burke wrote:

                    >>>>

                    >>>> On 6/12/2014 12:49 PM, Prateek
                    Mishra wrote:

                    >>>>> The OpenID Connect 2.0 COre
                    specification alone is 86 pages. It has

                    >>>>> received review from maybe a
                    dozen engineers within the OpenID community.

                    >>>>>

                    >>>> The OpenID Connect spec is 86 pages
                    because it pretty much rehashes the

                    >>>> OAuth2 spec walking through each
                    flow and how Open ID Connect expands on

                    >>>> that flow.  A4c looks like a subset
                    of this work minus some additional

                    >>>> claims and, IMO, is incomplete
                    compared to OIDC.

                    >>>>

                    >>>> FWIW, add 5 Red Hat engineers to
                    the "dozen" of reviewers.  We

                    >>>> originally were creating our own
                    oauth2 extension using JWT, but found

                    >>>> that any feature we wanted to
                    define already existed in OpenID Connect.

                    >>>>  These guys have done great work.  
                    Aren't many of you here authors of

                    >>>> this spec and/or the same
                    companies?!?  I think your energies are better

                    >>>> focused on lobbying OIDC to join
                    the IETF and this WG.

                    >>>>

                    >>>>

                    >>>>

                    >

                  

                

              

            

          

        

      

        

      

      

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


    

    

  


--------------010801000307080805090700--


From nobody Wed Jun 18 18:23:01 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52D51A01F6 for ; Wed, 18 Jun 2014 18:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdLX-_QzQoot for ; Wed, 18 Jun 2014 18:22:34 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CD81A01BF for ; Wed, 18 Jun 2014 18:22:33 -0700 (PDT)
Received: from DM2PR03CA007.namprd03.prod.outlook.com (10.141.52.155) by DM2PR03MB461.namprd03.prod.outlook.com (10.141.85.12) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 19 Jun 2014 01:22:24 +0000
Received: from BN1AFFO11FD006.protection.gbl (2a01:111:f400:7c10::103) by DM2PR03CA007.outlook.office365.com (2a01:111:e400:2414::27) with Microsoft SMTP Server (TLS) id 15.0.959.24 via Frontend Transport; Thu, 19 Jun 2014 01:22:25 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD006.mail.protection.outlook.com (10.58.52.66) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Thu, 19 Jun 2014 01:22:24 +0000
Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.173]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0195.002; Thu, 19 Jun 2014 01:21:50 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: [jose] Coalescing additional duplicative terminology definitions
Thread-Index: Ac+LXNf3MoWq+CEXTXCJuQ/c1OZN2g==
Date: Thu, 19 Jun 2014 01:21:49 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD76373@TK5EX14MBXC292.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.78]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD76373TK5EX14MBXC292r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438001)(377454003)(189002)(199002)(97736001)(46102001)(83072002)(66066001)(92566001)(86362001)(92726001)(86612001)(85852003)(99396002)(71186001)(76482001)(20776003)(64706001)(79102001)(80022001)(55846006)(77982001)(87936001)(2656002)(21056001)(85806002)(84326002)(6806004)(19580405001)(19580395003)(44976005)(81342001)(83322001)(15975445006)(512954002)(81542001)(19300405004)(84676001)(15202345003)(26826002)(81156003)(104016002)(85306003)(77096002)(95666004)(4396001)(16236675004)(33656002)(19625215002)(31966008)(50986999)(74662001)(68736004)(69596002)(74502001)(54356999); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR03MB461; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 02475B2A01
Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; 
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/cz9I1ebO4w9LJjEvyd6-sEXzlcc
Subject: [OAUTH-WG] FW: [jose] Coalescing additional duplicative terminology definitions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jun 2014 01:22:45 -0000

--_000_4E1F6AAD24975D4BA5B16804296739439AD76373TK5EX14MBXC292r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I wanted to make OAuth working group members aware of this possibility, sin=
ce it would have editorial effects upon the JWT draft.  Please discuss this=
 on the JOSE mailing list.

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, June 18, 2014 6:19 PM
To: Kathleen Moriarty; jose@ietf.org
Subject: [jose] Coalescing additional duplicative terminology definitions

Dear Kathleen and JOSE working group,

The current drafts already addressed JOSE issue #58 (Remove repeated, ephem=
eral, or obvious terminology) to a sufficient degree that Jim closed the is=
sue in November.  However, looking at this again with possibly fresher eyes=
, there's one remaining area of duplication that we may want to address.  S=
pecifically, these related term definitions are all present:

In JWS: JWS Header, Header Parameter
In JWE: JWE Header, Header Parameter
In JWA: Header Parameter
In JWT: JWT Header, Header Parameter

It would be possible editorially to coalesce the terms JWS Header, JWE Head=
er, and JWT header to a single JOSE Header term defined in one place.  And =
having done that, it would then also be possible to also replace the multip=
le Header Parameter definitions with a single one.

Some had expressed an interest in doing this in the past, especially when o=
bserving how having the multiple related definitions adds text to the JWT d=
raft, and how it could similarly add such text to other specs that use both=
 signed and encrypted JOSE objects.  Having thought about it for a while, a=
nd taking a fresh look at it, I now agree that this would be feasible, non-=
invasive, non-breaking, and result in improved editorial clarity.  But give=
n how far along we are with the drafts, I didn't want to presume that I sho=
uld make this change without explicitly asking if people agree with it.

Are people OK with this proposed editorial simplification, or would people =
prefer to leave the terminology as-is?

                                                            -- Mike


--_000_4E1F6AAD24975D4BA5B16804296739439AD76373TK5EX14MBXC292r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I wanted to make OAuth=
 working group members aware of this possibility, since it would have edito=
rial effects upon the JWT draft.  Please discuss this on the JOSE mail=
ing list.


 






From: jose [ma=
ilto:jose-bounces@ietf.org]
On Behalf Of Mike Jones

Sent: Wednesday, June 18, 2014 6:19 PM

To: Kathleen Moriarty; jose@ietf.org

Subject: [jose] Coalescing additional duplicative terminology defini=
tions






 


Dear Kathleen and JOSE working group,


 


The current drafts already addressed JOSE issue #58 =
(Remove repeated, ephemeral, or obvious terminology) to a sufficient degree=
 that Jim closed the issue in November.  However, looking at this agai=
n with possibly fresher eyes, there’s one
 remaining area of duplication that we may want to address.  Specifica=
lly, these related term definitions are all present:


 


In JWS: JWS Header, Header Parameter


In JWE: JWE Header, Header Parameter


In JWA: Header Parameter


In JWT: JWT Header, Header Parameter


 


It would be possible editorially to coalesce the ter=
ms JWS Header, JWE Header, and JWT header to a single JOSE Header term defi=
ned in one place.  And having done that, it would then also be possibl=
e to also replace the multiple Header Parameter
 definitions with a single one.


 


Some had expressed an interest in doing this in the =
past, especially when observing how having the multiple related definitions=
 adds text to the JWT draft, and how it could similarly add such text to ot=
her specs that use both signed and
 encrypted JOSE objects.  Having thought about it for a while, and tak=
ing a fresh look at it, I now agree that this would be feasible, non-invasi=
ve, non-breaking, and result in improved editorial clarity.  But given=
 how far along we are with the drafts, I didn’t
 want to presume that I should make this change without explicitly asking i=
f people agree with it.


 


Are people OK with this proposed editorial simplific=
ation, or would people prefer to leave the terminology as-is?

 


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


 






--_000_4E1F6AAD24975D4BA5B16804296739439AD76373TK5EX14MBXC292r_--


From nobody Fri Jun 20 16:47:46 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45571A0303; Fri, 20 Jun 2014 16:47:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VywMM2vu7vM0; Fri, 20 Jun 2014 16:47:42 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 995B91A0329; Fri, 20 Jun 2014 16:47:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.5.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140620234741.10471.94545.idtracker@ietfa.amsl.com>
Date: Fri, 20 Jun 2014 16:47:41 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YDPnnBh42b2712ke6UpMaNrI8cc
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-22.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jun 2014 23:47:44 -0000

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           : JSON Web Token (JWT)
        Authors         : Michael B. Jones
                          John Bradley
                          Nat Sakimura
	Filename        : draft-ietf-oauth-json-web-token-22.txt
	Pages           : 32
	Date            : 2014-06-20

Abstract:
   JSON Web Token (JWT) is a compact URL-safe 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
   used as the payload of a JSON Web Signature (JWS) structure or as the
   plaintext of a JSON Web Encryption (JWE) structure, enabling the
   claims to be digitally signed or MACed and/or encrypted.

   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-22

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-22


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Fri Jun 20 16:52:53 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B561A031C for ; Fri, 20 Jun 2014 16:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61E3gLTe8Bx9 for ; Fri, 20 Jun 2014 16:52:50 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711AF1A0319 for ; Fri, 20 Jun 2014 16:52:50 -0700 (PDT)
Received: from DM2PR03CA004.namprd03.prod.outlook.com (10.141.52.152) by DM2PR0301MB0701.namprd03.prod.outlook.com (25.160.96.27) with Microsoft SMTP Server (TLS) id 15.0.969.15; Fri, 20 Jun 2014 23:52:49 +0000
Received: from BY2FFO11FD046.protection.gbl (2a01:111:f400:7c0c::117) by DM2PR03CA004.outlook.office365.com (2a01:111:e400:2414::24) with Microsoft SMTP Server (TLS) id 15.0.959.24 via Frontend Transport; Fri, 20 Jun 2014 23:52:48 +0000
Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD046.mail.protection.outlook.com (10.1.15.170) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Fri, 20 Jun 2014 23:52:48 +0000
Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0195.002; Fri, 20 Jun 2014 23:52:17 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: JOSE -28 and JWT -22 drafts incorporating additional AD feedback
Thread-Index: Ac+M4oyywZzVkymtQ/K0Cy4DpMbPGwAABa2w
Date: Fri, 20 Jun 2014 23:52:16 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD86D4D@TK5EX14MBXC294.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.71]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD86D4DTK5EX14MBXC294r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438001)(377454003)(199002)(189002)(86612001)(97736001)(50986999)(76482001)(54356999)(15202345003)(19625215002)(85852003)(44976005)(87936001)(16297215004)(83072002)(33656002)(512954002)(106466001)(81156004)(79102001)(81342001)(19580405001)(31966008)(81542001)(46102001)(74662001)(80022001)(74502001)(77096002)(66066001)(19300405004)(71186001)(69596002)(85306003)(64706001)(21056001)(84676001)(92726001)(104016002)(6806004)(19580395003)(4396001)(83322001)(26826002)(99396002)(2656002)(77982001)(16236675004)(20776003)(55846006)(68736004)(86362001)(84326002)(92566001)(15975445006)(95666004)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR0301MB0701; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 024847EE92
Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; 
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_Nyt0Rv69cCUFZLn9ombAWQrbGA
Subject: [OAUTH-WG] FW: JOSE -28 and JWT -22 drafts incorporating additional AD feedback
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jun 2014 23:52:53 -0000

--_000_4E1F6AAD24975D4BA5B16804296739439AD86D4DTK5EX14MBXC294r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



From: Mike Jones
Sent: Friday, June 20, 2014 4:52 PM
To: jose@ietf.org
Subject: JOSE -28 and JWT -22 drafts incorporating additional AD feedback

Updated JOSE and JWT drafts have been released that incorporate additional =
wording improvements in places suggested by Kathleen Moriarty.  Most of the=
 changes were rewording and reorganization of the Security Considerations s=
ections.  An explanation of when applications typically would and would not=
 use the typ and cty header parameters was added.  The one normative change=
 was to specify the use of PKCS #7 padding with AES CBC, rather than PKCS #=
5 - a correction pointed out by Shaun Cooley. (PKCS #7 is a superset of PKC=
S #5, and is appropriate for the 16 octet blocks used by AES CBC.)  No brea=
king changes were made.

The specifications are available at:

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-28

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-28

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-key-28

*         http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-28

*         http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-22

HTML formatted versions are available at:

*         http://self-issued.info/docs/draft-ietf-jose-json-web-signature-2=
8.html

*         http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-=
28.html

*         http://self-issued.info/docs/draft-ietf-jose-json-web-key-28.html

*         http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-=
28.html

*         http://self-issued.info/docs/draft-ietf-oauth-json-web-token-22.h=
tml

                                                            -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=3D1240 and =
as @selfissued.


--_000_4E1F6AAD24975D4BA5B16804296739439AD86D4DTK5EX14MBXC294r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 


 






From: Mike Jon=
es


Sent: Friday, June 20, 2014 4:52 PM

To: jose@ietf.org

Subject: JOSE -28 and JWT -22 drafts incorporating additional AD fee=
dback






 


Updated JOSE and JWT drafts have been released that =
incorporate additional wording improvements in places suggested by Kathleen=
 Moriarty.  Most of the changes were rewording and reorganization of t=
he Security Considerations sections.  An
 explanation of when applications typically would and would not use the 
typ and cty header parameters was added.  The one normative change was to speci=
fy the use of PKCS #7 padding with AES CBC, rather than PKCS #5 – a c=
orrection pointed out by Shaun Cooley. (PKCS #7 is a superset
 of PKCS #5, and is appropriate for the 16 octet blocks used by AES CBC.)&n=
bsp; No breaking changes were made.


 


The specifications are available at:


·        
http://tools.ietf.org/html/draft-ietf-jose=
-json-web-signature-28


·        
http://tools.ietf.org/html/draft-ietf-jos=
e-json-web-encryption-28


·        
http://tools.ietf.org/html/draft-ietf-jose-json-=
web-key-28


·        
http://tools.ietf.org/html/draft-ietf-jos=
e-json-web-algorithms-28


·        
http://tools.ietf.org/html/draft-ietf-oauth-j=
son-web-token-22


 


HTML formatted versions are available at:=



·        
http://self-issued.info/docs/draft-=
ietf-jose-json-web-signature-28.html


·        
http://self-issued.info/docs/draft=
-ietf-jose-json-web-encryption-28.html


·        
http://self-issued.info/docs/draft-ietf-j=
ose-json-web-key-28.html


·        
http://self-issued.info/docs/draft=
-ietf-jose-json-web-algorithms-28.html


·        
http://self-issued.info/docs/draft-iet=
f-oauth-json-web-token-22.html


 


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


 


P.S.  This notice was also posted at 
http://self-issued.info/?p=3D1240 and as @selfissued.


 






--_000_4E1F6AAD24975D4BA5B16804296739439AD86D4DTK5EX14MBXC294r_--


From nobody Fri Jun 20 22:37:52 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED3C1A01C5; Fri, 20 Jun 2014 22:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urz2atf0rh3Y; Fri, 20 Jun 2014 22:37:46 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1D01A0538; Fri, 20 Jun 2014 22:37:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.5.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140621053745.1469.91634.idtracker@ietfa.amsl.com>
Date: Fri, 20 Jun 2014 22:37:45 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Ao1lNWrX5VBtWX1RwPp9L2vHSJs
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-23.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jun 2014 05:37:48 -0000

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           : JSON Web Token (JWT)
        Authors         : Michael B. Jones
                          John Bradley
                          Nat Sakimura
	Filename        : draft-ietf-oauth-json-web-token-23.txt
	Pages           : 32
	Date            : 2014-06-20

Abstract:
   JSON Web Token (JWT) is a compact URL-safe 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
   used as the payload of a JSON Web Signature (JWS) structure or as the
   plaintext of a JSON Web Encryption (JWE) structure, enabling the
   claims to be digitally signed or MACed and/or encrypted.

   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-23

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-23


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Fri Jun 20 22:42:29 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F031A0538 for ; Fri, 20 Jun 2014 22:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVN6aX6LYT2D for ; Fri, 20 Jun 2014 22:42:24 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E84C1B292C for ; Fri, 20 Jun 2014 22:42:24 -0700 (PDT)
Received: from BY2PR03CA033.namprd03.prod.outlook.com (10.242.234.154) by BY2PR03MB157.namprd03.prod.outlook.com (10.242.36.12) with Microsoft SMTP Server (TLS) id 15.0.954.9; Sat, 21 Jun 2014 05:42:21 +0000
Received: from BN1BFFO11FD019.protection.gbl (2a01:111:f400:7c10::1:133) by BY2PR03CA033.outlook.office365.com (2a01:111:e400:2c2c::26) with Microsoft SMTP Server (TLS) id 15.0.969.15 via Frontend Transport; Sat, 21 Jun 2014 05:42:21 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD019.mail.protection.outlook.com (10.58.144.82) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Sat, 21 Jun 2014 05:42:21 +0000
Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0195.002; Sat, 21 Jun 2014 05:42:12 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: JOSE -29 and JWT -23 drafts coalescing duplicative terminology definitions
Thread-Index: Ac+NE31PNwFgo7xVTbahcCnrJnPuOQAAAT1A
Date: Sat, 21 Jun 2014 05:42:11 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD87D8D@TK5EX14MBXC294.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD87D8DTK5EX14MBXC294r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(448001)(189002)(199002)(377454003)(85306003)(84326002)(77096002)(104016002)(95666004)(512954002)(19580395003)(83322001)(99396002)(26826002)(19580405001)(68736004)(86612001)(31966008)(6806004)(74662001)(16297215004)(33656002)(16236675004)(54356999)(79102001)(85326001)(15202345003)(80022001)(77982001)(19300405004)(83072002)(81156004)(106466001)(97736001)(81342001)(64706001)(87936001)(81542001)(84676001)(20776003)(92726001)(55846006)(15975445006)(85852003)(66066001)(50986999)(46102001)(74502001)(69596002)(71186001)(44976005)(76482001)(92566001)(21056001)(4396001)(2656002)(86362001)(19625215002)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB157; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0249EFCB0B
Received-SPF: PermError (: domain of microsoft.com used an invalid SPF mechanism)
Authentication-Results: spf=permerror (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; 
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/u5JG-ThJoHX0QWb1QHI7GRTdGHM
Subject: [OAUTH-WG] FW: JOSE -29 and JWT -23 drafts coalescing duplicative terminology definitions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jun 2014 05:42:27 -0000

--_000_4E1F6AAD24975D4BA5B16804296739439AD87D8DTK5EX14MBXC294r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



From: Mike Jones
Sent: Friday, June 20, 2014 10:42 PM
To: jose@ietf.org
Subject: JOSE -29 and JWT -23 drafts coalescing duplicative terminology def=
initions

Surprise!  For the first time ever, I've released two sets of JOSE and JWT =
drafts in one day!  I wanted to separate the changes addressing recent AD c=
omments from this set of changes that re=
duces duplication in the drafts.

These drafts replaced the terms JWS Header, JWE Header, and JWT Header with=
 a single JOSE Header term defined in the JWS specification.  This also ena=
bled a single Header Parameter definition to be used and reduced other area=
s of duplication between the specifications.  No normative changes were mad=
e.

The specifications are available at:

*        http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-29

*        http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-29

*        http://tools.ietf.org/html/draft-ietf-jose-json-web-key-29

*        http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-29

*        http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-23

HTML formatted versions are available at:

*        http://self-issued.info/docs/draft-ietf-jose-json-web-signature-29=
.html

*        http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-2=
9.html

*        http://self-issued.info/docs/draft-ietf-jose-json-web-key-29.html

*        http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-2=
9.html

*        http://self-issued.info/docs/draft-ietf-oauth-json-web-token-23.ht=
ml

                                                            -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=3D1242 and =
as @selfissued.


--_000_4E1F6AAD24975D4BA5B16804296739439AD87D8DTK5EX14MBXC294r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 


 






From: Mike Jon=
es


Sent: Friday, June 20, 2014 10:42 PM

To: jose@ietf.org

Subject: JOSE -29 and JWT -23 drafts coalescing duplicative terminol=
ogy definitions






 


Surprise!  For the first time ever, I’ve =
released two sets of JOSE and JWT drafts in one day!  I wanted to sepa=
rate the
changes addressing recent AD =
comments from this set of changes that reduces duplication in the draft=
s.


 


These drafts replaced the terms JWS Header, JWE Head=
er, and JWT Header with a single JOSE Header term defined in the JWS specif=
ication.  This also enabled a single Header Parameter definition to be=
 used and reduced other areas of duplication
 between the specifications.  No normative changes were made.


 


The specifications are available at:


·       
http://tools.ietf.org/html/draft-ietf-jose=
-json-web-signature-29


·       
http://tools.ietf.org/html/draft-ietf-jos=
e-json-web-encryption-29


·       
http://tools.ietf.org/html/draft-ietf-jose-json-=
web-key-29


·       
http://tools.ietf.org/html/draft-ietf-jos=
e-json-web-algorithms-29


·       
http://tools.ietf.org/html/draft-ietf-oauth-j=
son-web-token-23


 


HTML formatted versions are available at:=



·       
http://self-issued.info/docs/draft-=
ietf-jose-json-web-signature-29.html


·       
http://self-issued.info/docs/draft=
-ietf-jose-json-web-encryption-29.html


·       
http://self-issued.info/docs/draft-ietf-j=
ose-json-web-key-29.html


·       
http://self-issued.info/docs/draft=
-ietf-jose-json-web-algorithms-29.html


·       
http://self-issued.info/docs/draft-iet=
f-oauth-json-web-token-23.html


 


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


 


P.S.  This notice was also posted at 
http://self-issued.info/?p=3D1242 and as @selfissued.


 






--_000_4E1F6AAD24975D4BA5B16804296739439AD87D8DTK5EX14MBXC294r_--


From nobody Mon Jun 23 12:27:58 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92D91B2ABD for ; Mon, 23 Jun 2014 12:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsYEDWVyMK3L for ; Mon, 23 Jun 2014 12:27:55 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB851A03A1 for ; Mon, 23 Jun 2014 12:27:54 -0700 (PDT)
Received: from [192.168.131.142] ([80.92.115.50]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MHX0m-1Wy2uT1LiO-003KYO for ; Mon, 23 Jun 2014 21:27:53 +0200
Message-ID: <53A88011.3030407@gmx.net>
Date: Mon, 23 Jun 2014 21:29:21 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "oauth@ietf.org" 
References: <20140623183731.7457.3186.idtracker@ietfa.amsl.com>
In-Reply-To: <20140623183731.7457.3186.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.5.2
OpenPGP: id=4D776BC9
X-Forwarded-Message-Id: <20140623183731.7457.3186.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7bWI9swF5u9wes17cQRENUCaIvVs1Ba0b"
X-Provags-ID: V03:K0:1uAQ/+qrYjV5IP3bTrPJIxYc9eLhO2fhi5ArELHUnn5XBcoHkT5 8PadrCCosrjlnKUSEvekf7m5jfkkdzHoiy7bKL/6fhDZrVhpXaYl7gaSNWa1bLkhSsIGGKU CLVSsjRgUm+dXsZhV90KqS/ILe2BmirgicScYZtTkdvpQNuIM61SMUnlnGC9bBW5QqQfEcw gYN+fx4QX2uR3GpSR7J6w==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/1Q0Vbgu_mtcZSdO7bCzceLQa7Os
Subject: [OAUTH-WG] Fwd: IETF 90 Preliminary Agenda
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 19:27:57 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--7bWI9swF5u9wes17cQRENUCaIvVs1Ba0b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

FYI: OAuth is scheduled for Thursday, afternoon session II 1520-1720


-------- Original Message --------
Subject: IETF 90 Preliminary Agenda
Date: Mon, 23 Jun 2014 11:37:31 -0700
From: IETF Agenda 
Reply-To: IETF Agenda 
To: Working Group Chairs 
CC: irsg@irtf.org


The IETF 90 preliminary agenda has been posted.  The final agenda will
be published on Friday, June 27th, 2014.  Currently Registration and
Breaks are not displaying on the preliminary agenda, but this will be
remedied when the final agenda is released.

If you would like to request a change to the preliminary agenda, please
send a message to agenda@ietf.org and copy all relevant Area Directors.

Please note the cut-off date for requests to reschedule Working Group
sessions and BOFs is Thursday, June 26, 2014 at UTC 23:59.

https://datatracker.ietf.org/meeting/90/agenda.html
https://datatracker.ietf.org/meeting/90/agenda.txt

Thank you!

IETF Secretariat





--7bWI9swF5u9wes17cQRENUCaIvVs1Ba0b
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTqIARAAoJEGhJURNOOiAtd3QH/Rd1Yaf2+IBfiwlNry75O0TX
G8jxRGaT9uPd7TOWBnyPSmwMWToyBDxEyU3dNy/cNaeKtZns6qsgSNEcwiUGRIDx
yTEqZaWFb3vKrBVTzOg560gDhUPwZL+2Yf+u/bCz/6AKEZxa1J4OhdtBb8vxKs+X
hl+05sf8WiM0Qwhj5YIvBZ7gWrSD2xOmR5Xdap/kIu5VOKziUnOtGVDudV5eWGh/
innr1Has0HNnxMipsG8SaU5RK4x9EsgNvdZhSA+0WPT/pUkXe6MpvOAhv06k9B7k
GZYlOdBVx2HQ+pCBsJ+JA9rDVfZ8D2PFL2TDqkmA3ROgcYbZoKSAmCJTWtcBjP8=
=8l0E
-----END PGP SIGNATURE-----

--7bWI9swF5u9wes17cQRENUCaIvVs1Ba0b--


From nobody Tue Jun 24 11:58:08 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7141B2B46 for ; Tue, 24 Jun 2014 11:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.853
X-Spam-Level: 
X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNPB0hP1OxDP for ; Tue, 24 Jun 2014 11:58:06 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEE11B2B18 for ; Tue, 24 Jun 2014 11:58:06 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id B83A818B5AC; Tue, 24 Jun 2014 11:56:30 -0700 (PDT)
To: dick.hardt@gmail.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com
X-PHP-Originating-Script: 6000:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20140624185630.B83A818B5AC@rfc-editor.org>
Date: Tue, 24 Jun 2014 11:56:30 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/d-Nc3n-Jw7aV_GnKDq36q3mgLh4
Cc: el3rahim@yahoo.com, oauth@ietf.org, rfc-editor@rfc-editor.org
Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4024)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 18:58:07 -0000

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4024

--------------------------------------
Type: Editorial
Reported by: Ebrahim Jodeiri dallalan 

Section: s

Original Text
-------------
s

Corrected Text
--------------
s

Notes
-----
s

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6749 (draft-ietf-oauth-v2-31)
--------------------------------------
Title               : The OAuth 2.0 Authorization Framework
Publication Date    : October 2012
Author(s)           : D. Hardt, Ed.
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Tue Jun 24 13:12:42 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00341B27A0 for ; Tue, 24 Jun 2014 13:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.853
X-Spam-Level: 
X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA4L1ZR2hkma for ; Tue, 24 Jun 2014 13:12:35 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6C03C1A0100 for ; Tue, 24 Jun 2014 13:12:35 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id F2B39180203; Tue, 24 Jun 2014 13:11:00 -0700 (PDT)
To: rfc-editor@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org 
Message-Id: <20140624201100.F2B39180203@rfc-editor.org>
Date: Tue, 24 Jun 2014 13:11:00 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/w8u11jTf7QHTHQAXu7mB4zO506I
Cc: Derek Atkins , oauth@ietf.org
Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4024)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 20:12:40 -0000

FYI, this report has been removed because it was junk.

RFC Editor/ar

On Jun 24, 2014, at 2:56 PM, RFC Errata System wrote:

> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4024
> 
> --------------------------------------
> Type: Editorial
> Reported by: Ebrahim Jodeiri dallalan 
> 
> Section: s
> 
> Original Text
> -------------
> s
> 
> Corrected Text
> --------------
> s
> 
> Notes
> -----
> s
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC6749 (draft-ietf-oauth-v2-31)
> --------------------------------------
> Title               : The OAuth 2.0 Authorization Framework
> Publication Date    : October 2012
> Author(s)           : D. Hardt, Ed.
> Category            : PROPOSED STANDARD
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG


From m.nakhjiri@samsung.com  Wed Jun 25 17:06:35 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A8B1B291F for ; Wed, 25 Jun 2014 17:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.651
X-Spam-Level: 
X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnxSP608rIYy for ; Wed, 25 Jun 2014 17:06:32 -0700 (PDT)
Received: from usmailout2.samsung.com (mailout2.w2.samsung.com [211.189.100.12]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD4A1B291C for ; Wed, 25 Jun 2014 17:06:31 -0700 (PDT)
Received: from uscpsbgm1.samsung.com (u114.gpu85.samsung.co.kr [203.254.195.114]) by mailout2.w2.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N7R00B7Y1MU1G00@mailout2.w2.samsung.com> for oauth@ietf.org; Wed, 25 Jun 2014 20:06:30 -0400 (EDT)
X-AuditID: cbfec372-b7fe76d00000687e-0c-53ab6406fe71
Received: from ussync1.samsung.com ( [203.254.195.81]) by uscpsbgm1.samsung.com (USCPMTA) with SMTP id 69.15.26750.6046BA35; Wed, 25 Jun 2014 20:06:30 -0400 (EDT)
Received: from sdsamadjidPC ([105.66.230.137]) by ussync1.samsung.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0N7R00D6S1MTW720@ussync1.samsung.com> for oauth@ietf.org; Wed, 25 Jun 2014 20:06:30 -0400 (EDT)
From: Madjid Nakhjiri 
To: oauth@ietf.org
Date: Wed, 25 Jun 2014 17:06:30 -0700
Message-id: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="----=_NextPart_000_007B_01CF9097.CF7ED150"
X-Mailer: Microsoft Office Outlook 12.0
Thread-index: Ac+Q0ntU67hRb6BKQlCxmGlJaJ5kFg==
Content-language: en-us
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsVy+t/hQF22lNXBBmeuSVucfPuKzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGaeu3GQvmGpY0f3vBXsD4zStLkZODgkBE4mnZ7tYIWwxiQv3 1rN1MXJxCAksYZR4duQ4E4QznUli+tMz7CBVbAJ6EvvnzWAGsUUEhCSe7+wDKuLgYAaKL/2r DxIWFtCRONzwhgnEZhFQlXi/+SQjiM0r4CSxcOdpVghbUOLH5HssIDazQLTEpGWfWEDGSAio Szz6qwsxXU/i5otOJogScYlJDx6yT2Dkn4WkexaS7llIymZBHdS2kREiLC+x/e0cZghbV+L/ cxhbW2LZwtfMCxjZVzGKlhYnFxQnpeca6hUn5haX5qXrJefnbmKEhHHRDsZnG6wOMQpwMCrx 8Fp+XxksxJpYVlyZe4hRgoNZSYT3/d9VwUK8KYmVValF+fFFpTmpxYcYmTg4pRoYg7kenmdM mps47emsmvxvSq5p/wu//fXPnfO7ZENEAtccWa7V/Ru1Y2+mbdbfz1LpyMgueD6u/4dtJnvb wSdz/jDzrGjg+bz1yJS06Ioo85Vx/r1edhfPrOW+dfSvCMukCvFdq0TVjbf9EeE1XzxXxOv1 rINnJVnvznN8c2Tn83v7jZg+rhdRUmIpzkg01GIuKk4EACLbDdpBAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/u_-9NIhgyejAbeU7UC-cmE6Q8zQ
Subject: [OAUTH-WG] refresh tokens and client instances
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 00:08:55 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_007B_01CF9097.CF7ED150
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi all,

 

I am new to OAUTH list and OAUTH, so apologies if this is very off-topic. 

 

I am evaluating an OAUTH 2.0 implementation that is done based on bare bone
base OAUTH2.0 RFC. From what I understand, many (or some) client
implementations use a "global ID/secret" pair for all instances of the
client.  Looking at RFC 6819 and there seem to be a whole page on this
topic, if I understand it correctly. So questions:

 

1)      Section 3.7 talks about deployment-independent versus deployment
specific client IDs. I am guessing "deployment-independent" refers to what I
called "global", meaning if I have the same client with the same client ID
installed in many end devices, that is a deployment independent case,
correct?

2)      Section 3.3 on refresh token mentions that the token is secret bound
to the client ID and client instance. Could somebody please point me to
where the token generation and binding is described? Also how is the client
instance is identified?   

 

Thanks a lot in advance,

Madjid Nakhjiri

 


------=_NextPart_000_007B_01CF9097.CF7ED150
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi =
all,
 
I am new to OAUTH list and OAUTH, so apologies if this =
is very off-topic. 
 
I am =
evaluating an OAUTH 2.0 implementation that is done based on bare bone =
base OAUTH2.0 RFC. From what I understand, many (or some) client =
implementations use a “global ID/secret” pair for all =
instances of the client.  Looking at RFC 6819 and there seem to be =
a whole page on this topic, if I understand it correctly. So =
questions:
 
1)      =
Section 3.7 talks about deployment-independent =
versus deployment specific client IDs. I am guessing =
“deployment-independent” refers to what I called =
“global”, meaning if I have the same client with the same =
client ID installed in many end devices, that is a deployment =
independent case, correct?
2)      =
Section 3.3 on refresh token mentions that the =
token is secret bound to the client ID and client instance. Could =
somebody please point me to where the token generation and binding is =
described? Also how is the client instance is identified? =
  
 
Thanks a lot in advance,
Madjid Nakhjiri
 

------=_NextPart_000_007B_01CF9097.CF7ED150--


From nobody Wed Jun 25 17:54:39 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694B61B2E7D for ; Wed, 25 Jun 2014 17:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bheM7oTqKXjf for ; Wed, 25 Jun 2014 17:54:35 -0700 (PDT)
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083F41B2E73 for ; Wed, 25 Jun 2014 17:54:34 -0700 (PDT)
Received: by mail-qg0-f49.google.com with SMTP id f51so2388557qge.8 for ; Wed, 25 Jun 2014 17:54:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=7me3KtBldL12BEMQbeOinHXbJwgJBeiEPT8UT279m40=; b=WKJL0JJp8cPRYoXfrdxiX4e0yVRCG0VtnL/SRmXMe+d1aqtRtxsa2Yca/Sg/7dZr0g 6Kz2Akcm2dEQLvxzrDWUBklI6jbDCvowcQ7RlDK73bUJ5r+hBdzhEKAoZgrbTFZTLDH9 V/wtKhZozxsI7iIwXB0VPpea6uBTREPqOLK6+19KVVXkvkjsc+F9C1k56Qvh37l5Ypc8 OGEC+VIU24/19WqFy81PGzJipq1Ryo2bgb+fnUbmk18SlvB1AcumAOprTBlN9c2KSk2R y7Ax1pbwI7hEqLNOKqjmnE8lL+vPo/fwgQ0X9RVdm9Fg4jhJb9rv2daLZaLWnLHC3wSk NV3g==
X-Gm-Message-State: ALoCoQmI4Z7JiSf42ahRaSQw9VWaHM+rMumLPzXMIHYWNzetjXeA3VwRf018HraST+NAvwUCcfiy
X-Received: by 10.140.22.134 with SMTP id 6mr16073771qgn.4.1403744074058; Wed, 25 Jun 2014 17:54:34 -0700 (PDT)
Received: from [192.168.1.216] (186-79-202-60.baf.movistar.cl. [186.79.202.60]) by mx.google.com with ESMTPSA id a43sm3261634qge.8.2014.06.25.17.54.32 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 17:54:33 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8024B357-6600-43BC-9D93-88C3BED6D507"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: John Bradley 
In-Reply-To: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com>
Date: Wed, 25 Jun 2014 20:55:35 -0400
Message-Id: <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com>
References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com>
To: Madjid Nakhjiri 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/iL1WBicbnDZKKc8ujOWKkZbcgC8
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and client instances
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 00:54:37 -0000

--Apple-Mail=_8024B357-6600-43BC-9D93-88C3BED6D507
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

In 3.3 It is saying that the refresh token is a secret that the =
Authorization server has bound to the client_id, that the Authorization =
server effectively uses to differentiate between instances of that =
client_id.

When the refresh token is generated, it can be stored in a table with =
the client_id and the information about the grant.   You could also do =
it statelesly by creating a signed object as the refresh token.=20
The spec is silent on the exact programming method that the =
Authorization server uses.

In 3.7 Deployment independent describes using the same client_id across =
multiple instances of a native client, or multiple instances of a Java =
Script client running in a browsers with the same callback uri.

Since the publishing of this RFC we have also developed a spec for =
dynamic client registration so it is possible to give every native =
client it's own client_id and secret making them confidential clients.

There is also a middle ground some people take by doing a proof of =
possession for code in native applications to prevent the interception =
of responses to the client by malicious applications on the device.
https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/

John B.

On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri  =
wrote:

> Hi all,
> =20
> I am new to OAUTH list and OAUTH, so apologies if this is very =
off-topic.
> =20
> I am evaluating an OAUTH 2.0 implementation that is done based on bare =
bone base OAUTH2.0 RFC. =46rom what I understand, many (or some) client =
implementations use a =93global ID/secret=94 pair for all instances of =
the client.  Looking at RFC 6819 and there seem to be a whole page on =
this topic, if I understand it correctly. So questions:
> =20
> 1)      Section 3.7 talks about deployment-independent versus =
deployment specific client IDs. I am guessing =93deployment-independent=94=
 refers to what I called =93global=94, meaning if I have the same client =
with the same client ID installed in many end devices, that is a =
deployment independent case, correct?
> 2)      Section 3.3 on refresh token mentions that the token is secret =
bound to the client ID and client instance. Could somebody please point =
me to where the token generation and binding is described? Also how is =
the client instance is identified?  =20
> =20
> Thanks a lot in advance,
> Madjid Nakhjiri
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_8024B357-6600-43BC-9D93-88C3BED6D507
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

In 3.3 =
It is saying that the refresh token is a secret that the Authorization =
server has bound to the client_id, that the Authorization server =
effectively uses to differentiate between instances of that =
client_id.

When the refresh token is generated, it =
can be stored in a table with the client_id and the information about =
the grant.   You could also do it statelesly by creating a signed =
object as the refresh token. 
The spec is silent on the =
exact programming method that the Authorization server =
uses.

In 3.7 Deployment independent describes =
using the same client_id across multiple instances of a native client, =
or multiple instances of a Java Script client running in a browsers with =
the same callback uri.

Since the publishing of =
this RFC we have also developed a spec for dynamic client registration =
so it is possible to give every native client it's own client_id and =
secret making them confidential clients.

There =
is also a middle ground some people take by doing a proof of possession =
for code in native applications to prevent the interception of responses =
to the client by malicious applications on the device.

<=
/div>
John B.

On Jun 25, 2014, at =
8:06 PM, Madjid Nakhjiri <m.nakhjiri@samsung.com> =
wrote:

Hi =
all,
 
I am new to OAUTH list and OAUTH, so apologies if =
this is very off-topic.
 
I am =
evaluating an OAUTH 2.0 implementation that is done based on bare bone =
base OAUTH2.0 RFC. =46rom what I understand, many (or some) client =
implementations use a =93global ID/secret=94 pair for all instances of =
the client.  Looking at RFC 6819 and there seem to be a whole page =
on this topic, if I understand it correctly. So =
questions:
 
1)      Section 3.7 =
talks about deployment-independent versus deployment specific client =
IDs. I am guessing =93deployment-independent=94 refers to what I called =
=93global=94, meaning if I have the same client with the same client ID =
installed in many end devices, that is a deployment independent case, =
correct?
2)      Section 3.3 =
on refresh token mentions that the token is secret bound to the client =
ID and client instance. Could somebody please point me to where the =
token generation and binding is described? Also how is the client =
instance is identified?   
 
Thanks a =
lot in advance,
Madjid =
Nakhjiri
 
________________________________=
_______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_8024B357-6600-43BC-9D93-88C3BED6D507--


From nobody Thu Jun 26 05:41:59 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDA71B2BB8 for ; Thu, 26 Jun 2014 05:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zHzgMkzYUz8 for ; Thu, 26 Jun 2014 05:41:54 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B451B2BB3 for ; Thu, 26 Jun 2014 05:41:54 -0700 (PDT)
Received: from [192.168.131.143] ([80.92.115.50]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M6874-1WlUnC3Nhi-00yAos for ; Thu, 26 Jun 2014 14:41:53 +0200
Message-ID: <53AC1528.9080709@gmx.net>
Date: Thu, 26 Jun 2014 14:42:16 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "oauth@ietf.org" 
X-Enigmail-Version: 1.5.2
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EUcQmmDl0fwduwvpLNWKPWjoheCdcfo4P"
X-Provags-ID: V03:K0:Ng7meDbSF0/0XLOuv/P0Nm86RNKp+N0+8f3qLaq/+FnGO8GjGIB hTFFF82wZjQfwk47eZRY7xXpKUPeAZCwqVmBz9GIrVyatzisWVrmvI7BEvAP0/2rtF8HJ7Y s0NrZwkDGm1JIa457+R4q0j9NXh1BVm6ni/IFGiRduUgNLEEc0k0/wVcV4GESDHYTNayU2W z53ane5vj1DPJQboOoW/A==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fAedjMKjCRfoXLpBpLrAVTv3jCk
Subject: [OAUTH-WG] Updated OAuth PoP documents
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 12:41:57 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EUcQmmDl0fwduwvpLNWKPWjoheCdcfo4P
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,

I read through three of the OAuth proof-of-possession documents and made
a few minor changes here and there (mostly editorial & updated references=
).

Here are the three docs:
http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02
http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01
http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01

While there are a few open issues I believe that these three documents
are in fairly good shape.

Is someone willing to do a review?

Ciao
Hannes


--EUcQmmDl0fwduwvpLNWKPWjoheCdcfo4P
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTrBUoAAoJEGhJURNOOiAtVfwH/RwsypQ3OPxLx6/ZeCXWCu9w
q80h0geQLpUq0V0wMmKlGetKiH7e1xyGtMeQv231dXGed/ZuxwtiF5qhhMN3PCS5
uHmnCp7dJuKe7nSbdtaHEfRaKiNZeI1GrRFDm8+/0yMsqvMzMA9OSJi2dX2C5NHm
jHqBdN/ID0DhLMegDLaccjDZguX6U+/9Pex1XyDaWJUWEbzyB/KfdfMDNYWmgRhg
6lkBi9BJX8CqThhTdeZ/YDbgu7rGZ2kSmmz0uYUx7woZbaF4J5I58gJGE3l1ewoX
PIVYQu6ldhDhOMyVlLxYsuakWzAKhNu3SHG/d2y87jyjLiyjTGNDUY7eAK1a/j4=
=0NjI
-----END PGP SIGNATURE-----

--EUcQmmDl0fwduwvpLNWKPWjoheCdcfo4P--


From nobody Fri Jun 27 05:07:39 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028C61B3188 for ; Fri, 27 Jun 2014 05:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jV0V1lCw_RoE for ; Fri, 27 Jun 2014 05:07:21 -0700 (PDT)
Received: from n1plsmtpa01-03.prod.ams1.secureserver.net (n1plsmtpa01-03.prod.ams1.secureserver.net [188.121.53.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9A61B2B1A for ; Fri, 27 Jun 2014 05:07:20 -0700 (PDT)
Received: from [192.168.1.3] ([77.85.185.56]) by n1plsmtpa01-03.prod.ams1.secureserver.net with  id KQ7H1o0071DRsoD01Q7JPF; Fri, 27 Jun 2014 05:07:19 -0700
Message-ID: <1403870837.2440.124.camel@shakespeare>
From: Vladimir Dzhuvinov 
To: "oauth@ietf.org" 
Date: Fri, 27 Jun 2014 15:07:17 +0300
Organization: Connect2id Ltd.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.2.3-0ubuntu6 
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/luOP1VNGTKE1MOiuXgwh4zlGgyI
Subject: [OAUTH-WG] draft-jones-oauth-token-exchange-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 12:07:28 -0000

Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00

Thanks,

Vladimir
-- 
Vladimir Dzhuvinov 
Connect2id Ltd.


From nobody Fri Jun 27 10:24:24 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AE51A037D for ; Fri, 27 Jun 2014 10:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.651
X-Spam-Level: 
X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sefApOJImyMS for ; Fri, 27 Jun 2014 10:24:16 -0700 (PDT)
Received: from usmailout1.samsung.com (mailout1.w2.samsung.com [211.189.100.11]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602481B28DB for ; Fri, 27 Jun 2014 10:24:15 -0700 (PDT)
Received: from uscpsbgm2.samsung.com (u115.gpu85.samsung.co.kr [203.254.195.115]) by mailout1.w2.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N7U00CGI8CEOZ80@mailout1.w2.samsung.com> for oauth@ietf.org; Fri, 27 Jun 2014 13:24:14 -0400 (EDT)
X-AuditID: cbfec373-b7fd56d0000060dc-6b-53ada8be14c8
Received: from ussync4.samsung.com ( [203.254.195.84]) by uscpsbgm2.samsung.com (USCPMTA) with SMTP id 77.5B.24796.EB8ADA35; Fri, 27 Jun 2014 13:24:14 -0400 (EDT)
Received: from sdsamadjidPC ([105.66.230.137]) by ussync4.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0N7U008LR8CDJL10@ussync4.samsung.com>; Fri, 27 Jun 2014 13:24:14 -0400 (EDT)
From: Madjid Nakhjiri 
To: 'John Bradley' 
References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com>
In-reply-to: <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com>
Date: Fri, 27 Jun 2014 10:24:14 -0700
Message-id: <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="----=_NextPart_000_0023_01CF91F1.F2678490"
X-Mailer: Microsoft Office Outlook 12.0
Thread-index: Ac+Q2UIzBLNZgFI1Qt+pSRGhpSl84wBUG7Rw
Content-language: en-us
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsVy+t/hEN19K9YGG/S+FbM4+fYVm8Xqu3/Z HJg8liz5yeRx+/ZGlgCmKC6blNSczLLUIn27BK6Ma0e2MxWsrau4sqWRrYFxRl4XIyeHhICJ ROvSmawQtpjEhXvr2boYuTiEBJYwSnSevc4I4bQwSTT+uMcCUsUmoCexf94MZhBbREBNYvn2 TnYQm1lASOLDpSawGiGBMolFP5+B1XAK2Emc2HSbCcQWFrCWeLPuOFicRUBVYt2RM2C9vAJO EoteNLBC2IISPyZD7GIWiJa4/mUZ0BEcQNepSzz6qwux1kji6u45zBAl4hKTHjxkn8AoOAtJ 9ywk3bOQlM0CmsQM9EHbRqiwvMT2t3OYIWxdif/PYWxtiWULXzMvYGRfxShaWpxcUJyUnmuk V5yYW1yal66XnJ+7iRESDcU7GF9ssDrEKMDBqMTDK7B4bbAQa2JZcWXuIUYJDmYlEd5H84FC vCmJlVWpRfnxRaU5qcWHGJk4OKUaGN25SvNDLbI+GHSxdHJPSlDWb2Up2XXebvUz812CbJIc G/i63mu2R9sfzXtaePSUasSdxBaDi7enn00z5l22g/0H10M5o1CNyJ0NnK+mhr0UKJq2k+HM NxZ3VWPVooMzXKVFmewepBo/8RW/mSMU2/nqYtX967unxLbL8wVnO1hs8Dzbu8tViaU4I9FQ i7moOBEA2qZR+2QCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zZ5T-U6H1SKTAJVx3GBEX1hpPug
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and client instances
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 17:24:21 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01CF91F1.F2678490
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi John,

 

Thank you for your reply. Would appreciate if you consider my inline
comments below and respond again!

 

R,

Madjid

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, June 25, 2014 5:56 PM
To: Madjid Nakhjiri
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and client instances

 

In 3.3 It is saying that the refresh token is a secret that the
Authorization server has bound to the client_id, that the Authorization
server effectively uses to differentiate between instances of that
client_id.

 

Madjid>>If I have 10,000s of devices, each with an instance of the OAUTH
client, but they are all using the same client ID, how would the server know
which token to use for what client? unless when I am creating a token, I
also include something that uniquely identifies each instance? Don't I have
to use SOMETHING that is unique to that instance (user grant/ID?)?

 

When the refresh token is generated, it can be stored in a table with the
client_id and the information about the grant.   You could also do it
statelesly by creating a signed object as the refresh token. 

Madjid>>agreed, but for the signed object to be self-sustained, again would
I not need something beyond a "population" client_ID? Are we prescriptive
what "information about the grant" is?

 

The spec is silent on the exact programming method that the Authorization
server uses.

 

Madjid>>Are there any other specs in IETF or elsewhere (OASIS, etc?) that
prescribe token calculation (e.g. hash function, parameters, etc)?

 

In 3.7 Deployment independent describes using the same client_id across
multiple instances of a native client, or multiple instances of a Java
Script client running in a browsers with the same callback uri.

 

Since the publishing of this RFC we have also developed a spec for dynamic
client registration so it is possible to give every native client it's own
client_id and secret making them confidential clients.

 

Madjid>>I would need to look at those specs, however, I thought that the
"confidential client" designation has to do with the client ability to hold
secrets and perform a-by-server-acceptable authentication. Does dynamic
client registration affect client's ability in that aspect?

 

There is also a middle ground some people take by doing a proof of
possession for code in native applications to prevent the interception of
responses to the client by malicious applications on the device.

https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/

 

John B.

 

On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri  wrote:





Hi all,

 

I am new to OAUTH list and OAUTH, so apologies if this is very off-topic.

 

I am evaluating an OAUTH 2.0 implementation that is done based on bare bone
base OAUTH2.0 RFC. From what I understand, many (or some) client
implementations use a "global ID/secret" pair for all instances of the
client.  Looking at RFC 6819 and there seem to be a whole page on this
topic, if I understand it correctly. So questions:

 

1)      Section 3.7 talks about deployment-independent versus deployment
specific client IDs. I am guessing "deployment-independent" refers to what I
called "global", meaning if I have the same client with the same client ID
installed in many end devices, that is a deployment independent case,
correct?

2)      Section 3.3 on refresh token mentions that the token is secret bound
to the client ID and client instance. Could somebody please point me to
where the token generation and binding is described? Also how is the client
instance is identified?   

 

Thanks a lot in advance,

Madjid Nakhjiri

 

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

 


------=_NextPart_000_0023_01CF91F1.F2678490
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi John,
 
Thank you for your reply. Would appreciate if you consider my inline =
comments below and respond again!
 
R,
Madjid
 
From:=
 =
John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, June =
25, 2014 5:56 PM
To: Madjid Nakhjiri
Cc: =
oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and =
client instances
 
In 3.3 It is =
saying that the refresh token is a secret that the Authorization server =
has bound to the client_id, that the Authorization server effectively =
uses to differentiate between instances of that =
client_id.
 
Madjid>>If I have 10,000s of devices, each with an instance of =
the OAUTH client, but they are all using the same client ID, how would =
the server know which token to use for what client? unless when I am =
creating a token, I also include something that uniquely identifies each =
instance? Don’t I have to use SOMETHING that is unique to that =
instance (user grant/ID?)?
 
When the refresh token is generated, it can be stored =
in a table with the client_id and the information about the grant. =
  You could also do it statelesly by creating a signed object as =
the refresh token. 
Madjid>>agreed, but for the signed object to be self-sustained, =
again would I not need something beyond a “population” =
client_ID? Are we prescriptive what “information about the =
grant” is?
 
The spec =
is silent on the exact programming method that the Authorization server =
uses.
 
Madjid>>Are there any other specs in IETF or elsewhere (OASIS, =
etc?) that prescribe token calculation (e.g. hash function, parameters, =
etc)?
 
In 3.7 Deployment independent describes using the same =
client_id across multiple instances of a native client, or multiple =
instances of a Java Script client running in a browsers with the same =
callback uri.
 
Since the publishing of this RFC we have also =
developed a spec for dynamic client registration so it is possible to =
give every native client it's own client_id and secret making them =
confidential clients.
 
Madjid>>I would need to look at those specs, however, I thought =
that the “confidential client” designation has to do with =
the client ability to hold secrets and perform a-by-server-acceptable =
authentication. Does dynamic client registration affect client’s =
ability in that aspect?
 
There is =
also a middle ground some people take by doing a proof of possession for =
code in native applications to prevent the interception of responses to =
the client by malicious applications on the =
device.
 
John B.
 
On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri <m.nakhjiri@samsung.com> =
wrote:


Hi =
all,
 =

I am new =
to OAUTH list and OAUTH, so apologies if this is very =
off-topic.
 =

I am =
evaluating an OAUTH 2.0 implementation that is done based on bare bone =
base OAUTH2.0 RFC. From what I understand, many (or some) client =
implementations use a “global ID/secret” pair for all =
instances of the client.  Looking at RFC 6819 and there seem to be =
a whole page on this topic, if I understand it correctly. So =
questions:
 =

1)      Section =
3.7 talks about deployment-independent versus deployment specific client =
IDs. I am guessing “deployment-independent” refers to what I =
called “global”, meaning if I have the same client with the =
same client ID installed in many end devices, that is a deployment =
independent case, correct?
2)      Section =
3.3 on refresh token mentions that the token is secret bound to the =
client ID and client instance. Could somebody please point me to where =
the token generation and binding is described? Also how is the client =
instance is identified?   
 =

Thanks a =
lot in advance,
Madjid =
Nakhjiri
 =

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

 

------=_NextPart_000_0023_01CF91F1.F2678490--


From nobody Fri Jun 27 11:19:51 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DBE1B28C7 for ; Fri, 27 Jun 2014 11:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTbPmHeWtJth for ; Fri, 27 Jun 2014 11:19:42 -0700 (PDT)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408F61B28AC for ; Fri, 27 Jun 2014 11:19:41 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id j15so4300270qaq.40 for ; Fri, 27 Jun 2014 11:19:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=J9X9WgYHApffwbE96PXgBE3ymAvrcIbGarRMqfDcFHU=; b=Qd8l0wATPcXatIiSVP3+4tWHqIn+NEW1FWH4KrHR+2W8vhx29C3sA0J+b/WgxDO7nY jflXElQo396w6eJ1LS9lniwBr4ZGbIw8GHNoBoOT25PjugC4unpsGoT/76MHrXYecSck ge4tIjeEFPJIYPbaLx1X7mvrDbuuv960PWqDL856FF8/PZ859DVRNxwPGX1hdWi1CjmA 55mN84NiMd5w2yCtnfOSYhyUnDa3Jx1vdc+MUanilod+z8+Jb1h1crSjcrpFx2jA7LPc lMUwuK3Lrm871Fvxxqb/UmqsoQFrFycH5l8NEUZcKH0V3KvIOxbec7HoSccOzmODACWU GdGA==
X-Gm-Message-State: ALoCoQkafnMhuNersAmSUGkRX3/k4Thfv+/UiZ3K1EPKViYD0aQL3qI4ZTKKRuZoN2a4f6Jkj0Mv
X-Received: by 10.140.94.225 with SMTP id g88mr33073176qge.101.1403893181065;  Fri, 27 Jun 2014 11:19:41 -0700 (PDT)
Received: from [192.168.0.200] ([201.188.25.163]) by mx.google.com with ESMTPSA id t3sm17564175qai.28.2014.06.27.11.19.37 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 11:19:40 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_59FD00FE-D0D5-458C-9915-253A77D9162E"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: John Bradley 
In-Reply-To: <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com>
Date: Fri, 27 Jun 2014 14:21:35 -0400
Message-Id: 
References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com>
To: Madjid Nakhjiri 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/WR9RsGbGpA5rrP4BEzRgTgkrvA8
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and client instances
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 18:19:46 -0000

--Apple-Mail=_59FD00FE-D0D5-458C-9915-253A77D9162E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Inline

On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri  =
wrote:

> Hi John,
> =20
> Thank you for your reply. Would appreciate if you consider my inline =
comments below and respond again!
> =20
> R,
> Madjid
> =20
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Wednesday, June 25, 2014 5:56 PM
> To: Madjid Nakhjiri
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] refresh tokens and client instances
> =20
> In 3.3 It is saying that the refresh token is a secret that the =
Authorization server has bound to the client_id, that the Authorization =
server effectively uses to differentiate between instances of that =
client_id.
> =20
> Madjid>>If I have 10,000s of devices, each with an instance of the =
OAUTH client, but they are all using the same client ID, how would the =
server know which token to use for what client? unless when I am =
creating a token, I also include something that uniquely identifies each =
instance? Don=92t I have to use SOMETHING that is unique to that =
instance (user grant/ID?)?
> =20
When the grant is issued you create and store a refresh token which is =
effectively the identifier for that instance/grant combination.=20
When it comes back on a request to the token endpoint you look up the =
grants associated with it.   You also hack that the client_id sent in =
the request matches to detect errors mostly)

> When the refresh token is generated, it can be stored in a table with =
the client_id and the information about the grant.   You could also do =
it statelesly by creating a signed object as the refresh token.=20
> Madjid>>agreed, but for the signed object to be self-sustained, again =
would I not need something beyond a =93population=94 client_ID? Are we =
prescriptive what =93information about the grant=94 is?
> =20
You would be creating a bearer token as long as the AS signs it you can =
put whatever grant grant info you like in it, that is implementation =
specific.  It  could be a list of the scopes granted and the subject.
> The spec is silent on the exact programming method that the =
Authorization server uses.
> =20
> Madjid>>Are there any other specs in IETF or elsewhere (OASIS, etc?) =
that prescribe token calculation (e.g. hash function, parameters, etc)?

You can look at JOSE and JWT for a way to create tokens =
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token
> =20
> In 3.7 Deployment independent describes using the same client_id =
across multiple instances of a native client, or multiple instances of a =
Java Script client running in a browsers with the same callback uri.
> =20
> Since the publishing of this RFC we have also developed a spec for =
dynamic client registration so it is possible to give every native =
client it's own client_id and secret making them confidential clients.
> =20
> Madjid>>I would need to look at those specs, however, I thought that =
the =93confidential client=94 designation has to do with the client =
ability to hold secrets and perform a-by-server-acceptable =
authentication. Does dynamic client registration affect client=92s =
ability in that aspect?

Yes it doesn't require the secret to be in the downloaded instance of =
the native app.  It can be populated at first run, changing it from =
public to confidential.
Confidential is not just for web servers any more.
> =20
> There is also a middle ground some people take by doing a proof of =
possession for code in native applications to prevent the interception =
of responses to the client by malicious applications on the device.
> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
> =20
> John B.
> =20
> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri  =
wrote:
>=20
>=20
> Hi all,
> =20
> I am new to OAUTH list and OAUTH, so apologies if this is very =
off-topic.
> =20
> I am evaluating an OAUTH 2.0 implementation that is done based on bare =
bone base OAUTH2.0 RFC. =46rom what I understand, many (or some) client =
implementations use a =93global ID/secret=94 pair for all instances of =
the client.  Looking at RFC 6819 and there seem to be a whole page on =
this topic, if I understand it correctly. So questions:
> =20
> 1)      Section 3.7 talks about deployment-independent versus =
deployment specific client IDs. I am guessing =93deployment-independent=94=
 refers to what I called =93global=94, meaning if I have the same client =
with the same client ID installed in many end devices, that is a =
deployment independent case, correct?
> 2)      Section 3.3 on refresh token mentions that the token is secret =
bound to the client ID and client instance. Could somebody please point =
me to where the token generation and binding is described? Also how is =
the client instance is identified?  =20
> =20
> Thanks a lot in advance,
> Madjid Nakhjiri
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_59FD00FE-D0D5-458C-9915-253A77D9162E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Inline

On Jun 27, 2014, at 1:24 =
PM, Madjid Nakhjiri <m.nakhjiri@samsung.com> =
wrote:

Hi John,
 
Thank you for your reply. =
Would appreciate if you consider my inline comments below and respond =
again!
 
R,
Madjid
 
From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, June 25, 2014 =
5:56 PM
To: Madjid =
Nakhjiri
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh =
tokens and client instances
 
In =
3.3 It is saying that the refresh token is a secret that the =
Authorization server has bound to the client_id, that the Authorization =
server effectively uses to differentiate between instances of that =
client_id.
 
Madjid>>If I have 10,000s of devices, each with =
an instance of the OAUTH client, but they are all using the same client =
ID, how would the server know which token to use for what client? unless =
when I am creating a token, I also include something that uniquely =
identifies each instance? Don=92t I have to use SOMETHING that is unique =
to that instance (user grant/ID?)?
 
When the =
grant is issued you create and store a refresh token which is =
effectively the identifier for that instance/grant =
combination. 
When it comes back on a request to the =
token endpoint you look up the grants associated with it.   You =
also hack that the client_id sent in the request matches to detect =
errors mostly)

When the refresh token is =
generated, it can be stored in a table with the client_id and the =
information about the grant.   You could also do it statelesly by =
creating a signed object as the refresh =
token. 
Madjid>>agreed, but for the signed object to be =
self-sustained, again would I not need something beyond a =93population=94=
 client_ID? Are we prescriptive what =93information about the grant=94 =
is?
 
You =
would be creating a bearer token as long as the AS signs it you can put =
whatever grant grant info you like in it, that is implementation =
specific.  It  could be a list of the scopes granted and the =
subject.
The spec is silent on the exact programming method =
that the Authorization server uses.
 
Madjid>>Are there =
any other specs in IETF or elsewhere (OASIS, etc?) that prescribe token =
calculation (e.g. hash function, parameters, =
etc)?

You can =
look at JOSE and JWT for a way to create tokens http:/=
/tools.ietf.org/html/draft-ietf-oauth-json-web-token
 
In 3.7 Deployment independent describes using the =
same client_id across multiple instances of a native client, or multiple =
instances of a Java Script client running in a browsers with the same =
callback uri.
 
Since =
the publishing of this RFC we have also developed a spec for dynamic =
client registration so it is possible to give every native client it's =
own client_id and secret making them confidential =
clients.
 
Madjid>>I would =
need to look at those specs, however, I thought that the =93confidential =
client=94 designation has to do with the client ability to hold secrets =
and perform a-by-server-acceptable authentication. Does dynamic client =
registration affect client=92s ability in that =
aspect?

Yes it =
doesn't require the secret to be in the downloaded instance of the =
native app.  It can be populated at first run, changing it from =
public to confidential.
Confidential is not just for web =
servers any more.
 
There is also a middle ground some people take by doing a proof =
of possession for code in native applications to prevent the =
interception of responses to the client by malicious applications on the =
device.


Hi =
all,
 
I am new to OAUTH list and OAUTH, so apologies if =
this is very off-topic.
 
I am evaluating an OAUTH 2.0 implementation that =
is done based on bare bone base OAUTH2.0 RFC. =46rom what I understand, =
many (or some) client implementations use a =93global ID/secret=94 pair =
for all instances of the client.  Looking at RFC 6819 and there =
seem to be a whole page on this topic, if I understand it correctly. So =
questions:
 
1)      Section 3.7 =
talks about deployment-independent versus deployment specific client =
IDs. I am guessing =93deployment-independent=94 refers to what I called =
=93global=94, meaning if I have the same client with the same client ID =
installed in many end devices, that is a deployment independent case, =
correct?
2)      Section 3.3 =
on refresh token mentions that the token is secret bound to the client =
ID and client instance. Could somebody please point me to where the =
token generation and binding is described? Also how is the client =
instance is identified? =
  
 
Thanks a lot in =
advance,
Madjid =
Nakhjiri
 
_______________________________________________
OAuth =
mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_59FD00FE-D0D5-458C-9915-253A77D9162E--


From nobody Fri Jun 27 17:50:45 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABF81A024F for ; Fri, 27 Jun 2014 17:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.55
X-Spam-Level: 
X-Spam-Status: No, score=-7.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiy_TA6WkAS0 for ; Fri, 27 Jun 2014 17:50:38 -0700 (PDT)
Received: from usmailout1.samsung.com (mailout1.w2.samsung.com [211.189.100.11]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842BC1A024B for ; Fri, 27 Jun 2014 17:50:38 -0700 (PDT)
Received: from uscpsbgm1.samsung.com (u114.gpu85.samsung.co.kr [203.254.195.114]) by mailout1.w2.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N7U00G7NT0CTV50@mailout1.w2.samsung.com> for oauth@ietf.org; Fri, 27 Jun 2014 20:50:36 -0400 (EDT)
X-AuditID: cbfec372-b7fe76d00000687e-a7-53ae115ccf28
Received: from ussync3.samsung.com ( [203.254.195.83]) by uscpsbgm1.samsung.com (USCPMTA) with SMTP id 97.08.26750.C511EA35; Fri, 27 Jun 2014 20:50:36 -0400 (EDT)
Received: from sdsamadjidPC ([105.66.230.137]) by ussync3.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0N7U00CKCT0BRW30@ussync3.samsung.com>; Fri, 27 Jun 2014 20:50:36 -0400 (EDT)
From: Madjid Nakhjiri 
To: 'John Bradley' 
References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> 
In-reply-to: 
Date: Fri, 27 Jun 2014 17:50:37 -0700
Message-id: <005401cf926a$fab3a6a0$f01af3e0$%nakhjiri@samsung.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="----=_NextPart_000_0055_01CF9230.4E54CEA0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-index: Ac+SNGu01z+Kdj7CSS+uZ5xEc16qmQANmWVA
Content-language: en-us
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsVy+t/hYN0YwXXBBjNXGVucfPuKzWL13b9s DkweS5b8ZPK4fXsjSwBTFJdNSmpOZllqkb5dAldGz+4LbAU3NjBWTJi9hqmBcf0sxi5GDg4J AROJ85uDuhg5gUwxiQv31rN1MXJxCAksYZRo+f6KBcJpYZK4sPYeM0gVm4CexP55M8BsEQE1 ieXbO9lBbGYBIYkPl5qgGh4zSjS+7WADSXAK2El8ej0XzBYWsJZ4s+44WDOLgKrEvXermUBs XgEniekv2tggbEGJH5PvsUAMjZY4um4ZK8Sl6hKP/upC7DWSONDzhBGiRFxi0oOH7BMYBWch 6Z6FpHsWkrJZQJOYgV5o28gIEZaX2P52DjOErSvx/zmMrS2xbOFr5gWM7KsYRUuLkwuKk9Jz DfWKE3OLS/PS9ZLzczcxQiKiaAfjsw1WhxgFOBiVeHgbd60NFmJNLCuuzD3EKMHBrCTCq/wa KMSbklhZlVqUH19UmpNafIiRiYNTqoHRnf3CtQ28zAxywqemcvZ2WYfo3LHe+0RTp3vOkZqy 3XO2rWOPr33QMrPMLa3HMLFp09m5Vm+03wo2fS76wGUy+fK5R3tSJxTarLvU+qnzn/BGjset dzrFtZbsiBS8Y1b7aLe5zuH611MeCJ+0VDHSXqipL7Vx9++14meKm9dNvR9reT+ponCCEktx RqKhFnNRcSIAVucxLmYCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/S2LV6l9-FhYBq7fXN4SmomYrbbc
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and client instances
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jun 2014 00:50:43 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0055_01CF9230.4E54CEA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thank you for the response. I guess I am still not clear on the
token-instance-grant binding. Let me look at the specs to see what the grant
looks like to see if I understand. Any pointer is appreciated.

 

R,

Madjid

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Friday, June 27, 2014 11:22 AM
To: Madjid Nakhjiri
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and client instances

 

Inline

 

On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri  wrote:





Hi John,

 

Thank you for your reply. Would appreciate if you consider my inline
comments below and respond again!

 

R,

Madjid

 

From: John Bradley [  mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, June 25, 2014 5:56 PM
To: Madjid Nakhjiri
Cc:   oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and client instances

 

In 3.3 It is saying that the refresh token is a secret that the
Authorization server has bound to the client_id, that the Authorization
server effectively uses to differentiate between instances of that
client_id.

 

Madjid>>If I have 10,000s of devices, each with an instance of the OAUTH
client, but they are all using the same client ID, how would the server know
which token to use for what client? unless when I am creating a token, I
also include something that uniquely identifies each instance? Don't I have
to use SOMETHING that is unique to that instance (user grant/ID?)?

 

When the grant is issued you create and store a refresh token which is
effectively the identifier for that instance/grant combination. 

When it comes back on a request to the token endpoint you look up the grants
associated with it.   You also hack that the client_id sent in the request
matches to detect errors mostly)





When the refresh token is generated, it can be stored in a table with the
client_id and the information about the grant.   You could also do it
statelesly by creating a signed object as the refresh token. 

Madjid>>agreed, but for the signed object to be self-sustained, again would
I not need something beyond a "population" client_ID? Are we prescriptive
what "information about the grant" is?

 

You would be creating a bearer token as long as the AS signs it you can put
whatever grant grant info you like in it, that is implementation specific.
It  could be a list of the scopes granted and the subject.



The spec is silent on the exact programming method that the Authorization
server uses.

 

Madjid>>Are there any other specs in IETF or elsewhere (OASIS, etc?) that
prescribe token calculation (e.g. hash function, parameters, etc)?

 

You can look at JOSE and JWT for a way to create tokens
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token



 

In 3.7 Deployment independent describes using the same client_id across
multiple instances of a native client, or multiple instances of a Java
Script client running in a browsers with the same callback uri.

 

Since the publishing of this RFC we have also developed a spec for dynamic
client registration so it is possible to give every native client it's own
client_id and secret making them confidential clients.

 

Madjid>>I would need to look at those specs, however, I thought that the
"confidential client" designation has to do with the client ability to hold
secrets and perform a-by-server-acceptable authentication. Does dynamic
client registration affect client's ability in that aspect?

 

Yes it doesn't require the secret to be in the downloaded instance of the
native app.  It can be populated at first run, changing it from public to
confidential.

Confidential is not just for web servers any more.



 

There is also a middle ground some people take by doing a proof of
possession for code in native applications to prevent the interception of
responses to the client by malicious applications on the device.

 
https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/

 

John B.

 

On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri <
 m.nakhjiri@samsung.com> wrote:






Hi all,

 

I am new to OAUTH list and OAUTH, so apologies if this is very off-topic.

 

I am evaluating an OAUTH 2.0 implementation that is done based on bare bone
base OAUTH2.0 RFC. From what I understand, many (or some) client
implementations use a "global ID/secret" pair for all instances of the
client.  Looking at RFC 6819 and there seem to be a whole page on this
topic, if I understand it correctly. So questions:

 

1)      Section 3.7 talks about deployment-independent versus deployment
specific client IDs. I am guessing "deployment-independent" refers to what I
called "global", meaning if I have the same client with the same client ID
installed in many end devices, that is a deployment independent case,
correct?

2)      Section 3.3 on refresh token mentions that the token is secret bound
to the client ID and client instance. Could somebody please point me to
where the token generation and binding is described? Also how is the client
instance is identified?   

 

Thanks a lot in advance,

Madjid Nakhjiri

 

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

 


------=_NextPart_000_0055_01CF9230.4E54CEA0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Thank you for the response. I guess I am still not clear on the =
token-instance-grant binding. Let me look at the specs to see what the =
grant looks like to see if I understand. Any pointer is =
appreciated.
 
R,
Madjid
 
From:=
 =
John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Friday, June =
27, 2014 11:22 AM
To: Madjid Nakhjiri
Cc: =
oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and =
client instances
 
Inline
 
On =
Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri <m.nakhjiri@samsung.com> =
wrote:


Hi John,
 
Thank you for your reply. Would appreciate if you consider my inline =
comments below and respond again!
 
R,
Madjid
 
From:=
 John =
Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, June 25, 2014 5:56 =
PM
To: Madjid =
Nakhjiri
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens =
and client instances
 
In 3.3 It is saying that the refresh token is a secret =
that the Authorization server has bound to the client_id, that the =
Authorization server effectively uses to differentiate between instances =
of that client_id.
 
Madjid>>If I have 10,000s of devices, each with an instance of =
the OAUTH client, but they are all using the same client ID, how would =
the server know which token to use for what client? unless when I am =
creating a token, I also include something that uniquely identifies each =
instance? Don’t I have to use SOMETHING that is unique to that =
instance (user grant/ID?)?
 
When the grant is issued you create and store a =
refresh token which is effectively the identifier for that =
instance/grant combination. 
When it comes back on a request to the token endpoint =
you look up the grants associated with it.   You also hack that the =
client_id sent in the request matches to detect errors =
mostly)


When the refresh token is generated, it can be stored =
in a table with the client_id and the information about the grant. =
  You could also do it statelesly by creating a signed object as =
the refresh token. 
Madjid>>agreed, but for the signed object to be self-sustained, =
again would I not need something beyond a “population” =
client_ID? Are we prescriptive what “information about the =
grant” is?
 
You would be creating a bearer token as long as the AS =
signs it you can put whatever grant grant info you like in it, that is =
implementation specific.  It  could be a list of the scopes =
granted and the subject.

The spec is silent on the exact programming method =
that the Authorization server uses.
 
Madjid>>Are there any other specs in IETF or elsewhere (OASIS, =
etc?) that prescribe token calculation (e.g. hash function, parameters, =
etc)?
 
You =
can look at JOSE and JWT for a way to create tokens http:=
//tools.ietf.org/html/draft-ietf-oauth-json-web-token

 
In 3.7 Deployment independent describes using the same =
client_id across multiple instances of a native client, or multiple =
instances of a Java Script client running in a browsers with the same =
callback uri.
 
Since the publishing of this RFC we have also =
developed a spec for dynamic client registration so it is possible to =
give every native client it's own client_id and secret making them =
confidential clients.
 
Madjid>>I would need to look at those specs, however, I thought =
that the “confidential client” designation has to do with =
the client ability to hold secrets and perform a-by-server-acceptable =
authentication. Does dynamic client registration affect client’s =
ability in that aspect?
 
Yes it =
doesn't require the secret to be in the downloaded instance of the =
native app.  It can be populated at first run, changing it from =
public to confidential.
Confidential is not just for web servers any =
more.

 
There is also a middle ground some people take by =
doing a proof of possession for code in native applications to prevent =
the interception of responses to the client by malicious applications on =
the device.
 
John B.
 
On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri <m.nakhjiri@samsung.com> =
wrote:



Hi =
all,
 
I am new =
to OAUTH list and OAUTH, so apologies if this is very =
off-topic.
 
I am =
evaluating an OAUTH 2.0 implementation that is done based on bare bone =
base OAUTH2.0 RFC. From what I understand, many (or some) client =
implementations use a “global ID/secret” pair for all =
instances of the client.  Looking at RFC 6819 and there seem to be =
a whole page on this topic, if I understand it correctly. So =
questions:
 
1)      Section =
3.7 talks about deployment-independent versus deployment specific client =
IDs. I am guessing “deployment-independent” refers to what I =
called “global”, meaning if I have the same client with the =
same client ID installed in many end devices, that is a deployment =
independent case, correct?
2)      Section =
3.3 on refresh token mentions that the token is secret bound to the =
client ID and client instance. Could somebody please point me to where =
the token generation and binding is described? Also how is the client =
instance is identified? =
  
 
Thanks a =
lot in advance,
Madjid =
Nakhjiri
 
__________=
_____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=

 

------=_NextPart_000_0055_01CF9230.4E54CEA0--