From nobody Thu Oct 1 00:25:06 2015 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 104AB1B2B4C for ; Thu, 1 Oct 2015 00:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tCol81ej-NQs for ; Thu, 1 Oct 2015 00:24:57 -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 5B29A1B2B28 for ; Thu, 1 Oct 2015 00:24:57 -0700 (PDT) Received: from [192.168.131.140] ([80.92.119.87]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Leux5-1aRKvP3isJ-00qhZF; Thu, 01 Oct 2015 09:24:49 +0200 To: Kepeng Li , mbj@microsoft.com, ve7jtb@ve7jtb.com References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <560CDFAD.3040400@gmx.net> Date: Thu, 1 Oct 2015 09:24:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kcqSoxDrcoNWTNAhXr00t6eogVm1N87va" X-Provags-ID: V03:K0:wTGVfxjV2bq1Z/N8HeNnJkfUQMX7tEs2VgVH7/aIOkr42IjQdUl 5Enn+p53+RRsHB7/ZUOfjY1pbJJm4q/tPFHXLnPFDzqD/7txoK5tgxjBtAmxnR8ZQSiRnba Ea38rhCh/AnjlVeC0y7LPyrop+yT8+UXRu5LBGmhlBcxR9xza0rgdV0uLquZ5Q6OP/VXWGK 4JEuCEycz55KZl+gEDNNg== X-UI-Out-Filterresults: notjunk:1;V01:K0:7k3o2quMHOE=:pr68+KHGseVCzBQKPui0eI SgYXN/E/UKyNIScBvwonUC+AgBDmRf34D/zVvK1gHoerYJPEu88Q3R/lX7LTjrcrRFWn3+Rm9 MSzLXNTATIjkTOiX1jLH7M+wSrDQBggAG4U6zOiY2EztdUStsEP1HsFInuQ8TizIArUdkXj2Y IwKhqidy3jsOCUGjMYkCv8SyZDVI9bt3mrLLZ2KaVPQd7irhysUxRs3oZ8UBdhtbdk1+Btqzl mddofauqgkWIOfOaupGX6HJyGqFjGlTLMAWNh5SdHvWoET3RBLHjQ0vDCRd7ZSE2qKx/z6QFU u7jDmwCSU0fU5+gJW7byDzTH/zT8uCslvWT9152vCSJQg/jjAJYFVXSKRqFwLZ9hGbgCJH+rE xpL0IfrQXfocVGxr3WMAd3TNtILJedn54LmwKYRMgDlmVF3cTpIH0+UH+kl9F2MmInYnMgeuv yGzZjkm+FJqq3gYFoEbJ9lnn+gucNns9/F2e2dWnFTsg6wRpTn+euyPR8vGH4sPhFacM3KG9h ijL55xFagpVLd3gpBbFIXJr186+U1jHQjX0a54hAhMJr0G6z/59nheuhZO+r7dVwyNUecCCNZ m9Vpr917+As594G6Bfk7DixwUi6vIQtuS56z118ZY+8pqoVIEkLNh5vhnyypzyO1C+o9ZytBL LG0MZyltF4pR/HzNBBMmVSE1T4bzYTQ4JMGSPZrlrD9zqeIet4uT924KoNUwM+jQ6OFcAsdNE PP5yQCv8H0UQaBseqVkEHkoUyxP9pLZx4l4CFSKd1c/V6P2G6SAFgX7xoQk= Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] PoP document: IPR Confirmation 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, 01 Oct 2015 07:24:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kcqSoxDrcoNWTNAhXr00t6eogVm1N87va Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am not aware of any IPRs on the 'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' specification (draft-ietf-oauth-proof-of-possession-04). Ciao Hannes On 09/30/2015 12:03 PM, Kepeng Li wrote: > Hi Mike, John and Hannes, >=20 > I am working on the shepherd writeup for the PoP document: >=20 > http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04 > >=20 > One item in the template requires me to indicate whether each document > author has confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 > have already been filed. Could you please confirm? Kind Regards >=20 > Kepeng >=20 >=20 --kcqSoxDrcoNWTNAhXr00t6eogVm1N87va Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWDN+uAAoJEGhJURNOOiAtRtMH/j+6+CyNVbvV3glu/Nnxupmy mVLmIHQlwPRJyc9IyLfA2xX1LbHxW0+bungSxcAby7oruNK0eRpGHvO8jO7IA6U/ WuiOxrsR9cq+xdASmp71PkM3GxHEiWfJlS/utcD4XlMrooOPqVVqPk8onPd3BcPS x45IPt26d578NKiZEvHCY09JS+v5IkTeRKShrii8poje8syGdlmMG6SzgFK+oiGG MmpwcAOAVjDw45eKSMVUk1ZOFlnokhq714fRy2e3Y87R4QFAb6LSdun55S+EYeze m3KlbDDPLWEYizH+OlW//Jnnjip47LAWzJPLl1FFAkUsCz3pwtsR14MrovzO1lI= =BxE0 -----END PGP SIGNATURE----- --kcqSoxDrcoNWTNAhXr00t6eogVm1N87va-- From nobody Fri Oct 2 12:46:19 2015 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 2072E1A87BD for ; Fri, 2 Oct 2015 12:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 kEkiDTS7hCY3 for ; Fri, 2 Oct 2015 12:46:17 -0700 (PDT) Received: from mx0a-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD661A87BF for ; Fri, 2 Oct 2015 12:46:17 -0700 (PDT) Received: from pps.filterd (m0074412.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t92Jfs8g027967 for ; Fri, 2 Oct 2015 14:46:16 -0500 Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) by mx0a-0019e102.pphosted.com with ESMTP id 1x9yvx021u-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 02 Oct 2015 14:46:16 -0500 Received: by ykdz138 with SMTP id z138so120528727ykd.2 for ; Fri, 02 Oct 2015 12:46:15 -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:from:date:message-id:subject:to :content-type; bh=KeHGwVUMO6lOJj6VSbfia8+tp6noJYYrLFVw5QxhoKU=; b=k5WAoONhOuNpWPkW07/35LiuKLS4G/tvd1Jhs6Zl5LD7b/DSPwFyKPaUN9eFvbyizq utOjv8dKLjZTrt1aMDLSDHuR+wmVIgziZX9zkwezLJYpTgNcA17mczlvaww6Lap/x63s WAqaNBZDzwlwjSetsC35spYrGtybjo3Fwvkbepug3NwArwBVv5ep8IDeT6ZC+c9GeLdp 5aNG2feQIUWpkOytVoOqgfIfSfPW6CX+MaEWRUVQzk63KFBivy1qBP3Ayb5mDNe6Iz44 d9f6h7k2BjLWhLtrjAyYc+wgQHQg93tZTvShrBE8csKg6uBGwikl5l52R0h8en3DJpuC 2LgQ== X-Gm-Message-State: ALoCoQlMa1SE8YpDFjMerEttA3UVjrFQK19Y6j8ifiD85ePua10Hk7EMBkTPuPdz1/1hD2Zjkp/CphbJZBxnjopLlphraHUmUxSreGpXh3qUHB0jHXEIKltHLpEvoZZbADDMIYBgynfU X-Received: by 10.170.197.211 with SMTP id o202mr14515829yke.27.1443815175703; Fri, 02 Oct 2015 12:46:15 -0700 (PDT) X-Received: by 10.170.197.211 with SMTP id o202mr14515820yke.27.1443815175565; Fri, 02 Oct 2015 12:46:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.195.194 with HTTP; Fri, 2 Oct 2015 12:45:56 -0700 (PDT) From: Adam Lewis Date: Fri, 2 Oct 2015 14:45:56 -0500 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary=001a1139d01ea96c190521246a61 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=1 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510020247 Archived-At: Subject: [OAUTH-WG] OAuth and IoT 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, 02 Oct 2015 19:46:18 -0000 --001a1139d01ea96c190521246a61 Content-Type: text/plain; charset=UTF-8 Hi all, Looking to find some pointers to effort around usage of OAuth and IoT. Will embedded devices / appliances use the client credential grant type? This would seem to be a natural choice, now does every device have a unique client id? I am looking at use cases where we will have a large set of devices without a UI acting on their own behalf (not the users) and will need to obtain access tokens. What are the best practices around this? It seems impractical to add every one of these devices as a unique client to the OAuth server, but I'm unclear what the other options are given the current set of drafts. tx! adam --001a1139d01ea96c190521246a61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Looking to find some pointers t= o effort around usage of OAuth and IoT.=C2=A0 Will embedded devices / appli= ances use the client credential grant type?=C2=A0 This would seem to be a n= atural choice, now does every device have a unique client id?=C2=A0 I am lo= oking at use cases where we will have a large set of devices without a UI a= cting on their own behalf (not the users) and will need to obtain access to= kens.=C2=A0 What are the best practices around this?=C2=A0 It seems impract= ical to add every one of these devices as a unique client to the OAuth serv= er, but I'm unclear what the other options are given the current set of= drafts.=C2=A0



tx!
adam
--001a1139d01ea96c190521246a61-- From nobody Fri Oct 2 13:19:33 2015 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 1EC9A1B2D40 for ; Fri, 2 Oct 2015 13:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 1XLcvVcm_viu for ; Fri, 2 Oct 2015 13:19:31 -0700 (PDT) Received: from mx0b-0019e102.pphosted.com (mx0b-0019e102.pphosted.com [67.231.157.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B05D1B2D3E for ; Fri, 2 Oct 2015 13:19:30 -0700 (PDT) Received: from pps.filterd (m0074414.ppops.net [127.0.0.1]) by mx0b-0019e102.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t92KBxrk030928 for ; Fri, 2 Oct 2015 15:19:29 -0500 Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) by mx0b-0019e102.pphosted.com with ESMTP id 1x9ymq03f8-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 02 Oct 2015 15:19:29 -0500 Received: by ykft14 with SMTP id t14so121654579ykf.0 for ; Fri, 02 Oct 2015 13:19:29 -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:content-type; bh=HEtHgCdeCMq7bUecNu++9dmIMnUlDIAD977rNK2l0Do=; b=NsO2c2dV/KESHvPlbv5KrXlFtAymLFxGQtLpeen6WPbCZZ3gkUL4RhT9Mo7UVWDzh0 gL0G0BLjpw5vtlaMBOF+gnIPp993WpEdRoJCz0v+UqKf/xzr8s/mCNe/gxWYAslXNBN9 9KKGCcOFABYk0LE8B+/JCUIDpyusLQivE9VgjzLSsZxLkWJHIMhLh+mQMwGuplXjVTXm kS0kngMFNVp8rZ1hIFipbumRPa9ZfNP+OpRloFz5KcU4V5osMO4MdyOOrLApUjdLnxaJ I/UF7YnLjS7GXstld7/E6FgtkGOXUjr+wx6Ygme+tKf+i8uc9ygkq5fgO3jFEc/fTd0T QRng== X-Gm-Message-State: ALoCoQk9DvAzRaxl4lTEWeQAXYDQbofv2cmSb+xgaW2QaJB0OxSI98lVyC6IJezesmjxfhuT7SkT5CvMm0IQEWPfcDl53Z0Du62JmA7eI0SjHzokvdbN8SCR9i7JDmatklw4PbjcORvm X-Received: by 10.170.52.7 with SMTP id 7mr14861497yku.74.1443817169465; Fri, 02 Oct 2015 13:19:29 -0700 (PDT) X-Received: by 10.170.52.7 with SMTP id 7mr14861487yku.74.1443817169312; Fri, 02 Oct 2015 13:19:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.195.194 with HTTP; Fri, 2 Oct 2015 13:19:09 -0700 (PDT) In-Reply-To: References: From: Adam Lewis Date: Fri, 2 Oct 2015 15:19:09 -0500 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary=001a1139377a7f6f8c052124e1b4 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=1 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510020253 Archived-At: Subject: Re: [OAUTH-WG] OAuth and IoT 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, 02 Oct 2015 20:19:32 -0000 --001a1139377a7f6f8c052124e1b4 Content-Type: text/plain; charset=UTF-8 And on that similar note, has their been any work done around having a singe client id, and registering that client id with the AS, but tying the client id to a trust anchor instead of a single public key certificate, such that any client issued a certificate by the trusted CA could obtain an access token? This would enable a single entry in the AS for each type of client. On Fri, Oct 2, 2015 at 2:45 PM, Adam Lewis wrote: > Hi all, > > Looking to find some pointers to effort around usage of OAuth and IoT. > Will embedded devices / appliances use the client credential grant type? > This would seem to be a natural choice, now does every device have a unique > client id? I am looking at use cases where we will have a large set of > devices without a UI acting on their own behalf (not the users) and will > need to obtain access tokens. What are the best practices around this? It > seems impractical to add every one of these devices as a unique client to > the OAuth server, but I'm unclear what the other options are given the > current set of drafts. > > > > tx! > adam > --001a1139377a7f6f8c052124e1b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And on that similar note, has their been any work done aro= und having a singe client id, and registering that client id with the AS, b= ut tying the client id to a trust anchor instead of a single public key cer= tificate, such that any client issued a certificate by the trusted CA could= obtain an access token?=C2=A0 This would enable a single entry in the AS f= or each type of client. =C2=A0

On Fri, Oct 2, 2015 at 2:45 PM, Adam Lewis <adam.lewis@motorolasolutions.com> wrote:
Hi all,

Looking to fi= nd some pointers to effort around usage of OAuth and IoT.=C2=A0 Will embedd= ed devices / appliances use the client credential grant type?=C2=A0 This wo= uld seem to be a natural choice, now does every device have a unique client= id?=C2=A0 I am looking at use cases where we will have a large set of devi= ces without a UI acting on their own behalf (not the users) and will need t= o obtain access tokens.=C2=A0 What are the best practices around this?=C2= =A0 It seems impractical to add every one of these devices as a unique clie= nt to the OAuth server, but I'm unclear what the other options are give= n the current set of drafts.=C2=A0


=
tx!
adam

--001a1139377a7f6f8c052124e1b4-- From nobody Fri Oct 2 13:35:21 2015 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 84C3C1B2D8B for ; Fri, 2 Oct 2015 13:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 3x49e_yQpYcm for ; Fri, 2 Oct 2015 13:35:18 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE8A1B2D92 for ; Fri, 2 Oct 2015 13:35:18 -0700 (PDT) Received: by qgev79 with SMTP id v79so104856782qge.0 for ; Fri, 02 Oct 2015 13:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=17zS21Oh7FAEdG4c4bP+2a2HJvfaaG+vh7oire/9TVA=; b=0UQmxNJ5DTiGBOdhxmrenQ0ZhHp5Hr8IAfvSA2QeKHBTyuD2m90psbvvQu/0votmXx 32DQThumTgvtNlCAwa/vk1vYz6avFiEgNzbQOjw6YpSn2oqd699gviA0Sp2uWIew0uUx yv/LImDUUt8vd3BLBfh1DL1MV0t1w0A10hbHXf4hmNmcV8WW3oPeHLDh9dw5aOW32P7I Z+jz77O6lnXN7cyWxU/4j7kMcV/R7VgSo7dAmVBsTpCqHAFIdTNXxKwDBemNnrqmtnPM y3xwFWoUAS/P4fuVCW744Ws5YGGSO1IjmQBqRTwdyhsEEmkcD7Q6G0+c+OJsGNBCZZLH bAFQ== X-Received: by 10.140.43.164 with SMTP id e33mr22550074qga.62.1443818117331; Fri, 02 Oct 2015 13:35:17 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id c188sm5372647qka.37.2015.10.02.13.35.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Oct 2015 13:35:16 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-F9B4F4E1-DE76-41C3-8E7B-04A0E981AD6A Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Fri, 2 Oct 2015 16:35:15 -0400 Content-Transfer-Encoding: 7bit Message-Id: <06859C0C-22CC-4CE8-8A42-593EF2EFDCE1@gmail.com> References: To: Adam Lewis Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth and IoT 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, 02 Oct 2015 20:35:20 -0000 --Apple-Mail-F9B4F4E1-DE76-41C3-8E7B-04A0E981AD6A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Adam, Are you following the ACE working group? They are wrapping up their use cas= e document and IETF last call should start next week. OAuth is being consid= ered and they will be busy with suction work soon for Authentication and aut= horization in Constrained Environments. I'd suggest start with a read of the use case draft. The actors draft will f= ollow through soon with a WGLC (I hope). They should be discussing solution= s in Yokohama. Kathleen=20 Sent from my iPhone > On Oct 2, 2015, at 4:19 PM, Adam Lewis w= rote: >=20 > And on that similar note, has their been any work done around having a sin= ge client id, and registering that client id with the AS, but tying the clie= nt id to a trust anchor instead of a single public key certificate, such tha= t any client issued a certificate by the trusted CA could obtain an access t= oken? This would enable a single entry in the AS for each type of client. =20= >=20 >> On Fri, Oct 2, 2015 at 2:45 PM, Adam Lewis wrote: >> Hi all, >>=20 >> Looking to find some pointers to effort around usage of OAuth and IoT. W= ill embedded devices / appliances use the client credential grant type? Thi= s would seem to be a natural choice, now does every device have a unique cli= ent id? I am looking at use cases where we will have a large set of devices= without a UI acting on their own behalf (not the users) and will need to ob= tain access tokens. What are the best practices around this? It seems impr= actical to add every one of these devices as a unique client to the OAuth se= rver, but I'm unclear what the other options are given the current set of dr= afts.=20 >>=20 >>=20 >>=20 >> tx! >> adam >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-F9B4F4E1-DE76-41C3-8E7B-04A0E981AD6A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Adam,

Are you= following the ACE working group?  They are wrapping up their use case d= ocument and IETF last call should start next week.  OAuth is being cons= idered and they will be busy with suction work soon for Authentication and a= uthorization in Constrained Environments.

I'd sugge= st start with a read of the use case draft.  The actors draft will foll= ow through soon with a WGLC (I hope).  They should be discussing soluti= ons in Yokohama.

Kathleen 

Sent from my= iPhone

On Oct 2, 2015, at 4:19 PM, Adam Lewis <adam.lewis@motorolasolutions.com> wrote:


On Fri,= Oct 2, 2015 at 2:45 PM, Adam Lewis <adam.lewis@motorolasolut= ions.com> wrote:
Hi all,

Looking to find some pointers to effort arou= nd usage of OAuth and IoT.  Will embedded devices / appliances use the c= lient credential grant type?  This would seem to be a natural choice, n= ow does every device have a unique client id?  I am looking at use case= s where we will have a large set of devices without a UI acting on their own= behalf (not the users) and will need to obtain access tokens.  What ar= e the best practices around this?  It seems impractical to add every on= e of these devices as a unique client to the OAuth server, but I'm unclear w= hat the other options are given the current set of drafts. 
<= br>


tx!
=
adam

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-F9B4F4E1-DE76-41C3-8E7B-04A0E981AD6A-- From nobody Fri Oct 2 13:36:51 2015 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 A34B61B2DA0 for ; Fri, 2 Oct 2015 13:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.346 X-Spam-Level: X-Spam-Status: No, score=0.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] 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 pikkI1rOaZVM for ; Fri, 2 Oct 2015 13:36:48 -0700 (PDT) Received: from mx0a-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342A81B2D8B for ; Fri, 2 Oct 2015 13:36:48 -0700 (PDT) Received: from pps.filterd (m0074409.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t92KW3lP010537 for ; Fri, 2 Oct 2015 15:36:47 -0500 Received: from mail-yk0-f181.google.com (mail-yk0-f181.google.com [209.85.160.181]) by mx0a-0019e102.pphosted.com with ESMTP id 1x9wrr0e8a-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 02 Oct 2015 15:36:47 -0500 Received: by ykft14 with SMTP id t14so122065724ykf.0 for ; Fri, 02 Oct 2015 13:36:46 -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=f9vIibgXU/IGBo17jaMyNh1wGUv9nAAq0I95kED8c1s=; b=WfSBbvMg1GwbVBl+xDEMrmGsUu14enXT54w9TxAhbzmsKasBRMKKbJyzsmBAhZpRdP CwyAdyOIqiIxOf78REdc9v2F244h/DH7t4ckNR2N/D0fXWw3zJ2InMC+u+o+idzJ/kEQ lJPdbF5Taz3rI9HRRKVY7rKtK7kuS+XBzjjjnWaMy9n+ECpap+ym6IqP3CjXFSsbMPas ovuqXOCrlptwbI+tw7DwVBmUP5zJs8IAUCMzkcHwsKEb8rxOM++vtqCxSpH4N/QScNqc W71IbhUz8nEVqtfAA9G/K7n4+DPUw0B6nJbn143JRIs/WFfBSHPuSR/3OLEpzJUt5+bd 7f2g== X-Gm-Message-State: ALoCoQlIUt5JHXknDvVpAiXsHi5rX6ZeyOOGoITtE8G0QJysXWZRqSeU7+f1LWt34AjNjaZnI4a/qXWPXfxYcbKqpdTWhv4Uqdkp/fzWoIVTORgfUIMBD18gtzBtsEV9iH3n/54/8ecx X-Received: by 10.170.97.66 with SMTP id o63mr15132269yka.55.1443818206270; Fri, 02 Oct 2015 13:36:46 -0700 (PDT) X-Received: by 10.170.97.66 with SMTP id o63mr15132263yka.55.1443818206119; Fri, 02 Oct 2015 13:36:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.195.194 with HTTP; Fri, 2 Oct 2015 13:36:26 -0700 (PDT) In-Reply-To: <06859C0C-22CC-4CE8-8A42-593EF2EFDCE1@gmail.com> References: <06859C0C-22CC-4CE8-8A42-593EF2EFDCE1@gmail.com> From: Adam Lewis Date: Fri, 2 Oct 2015 15:36:26 -0500 Message-ID: To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a113b4f404c00a20521251f7b X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=1 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510020257 Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth and IoT 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, 02 Oct 2015 20:36:49 -0000 --001a113b4f404c00a20521251f7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you Kathleen, exactly the type of pointers I was looking for. Will head over their now :-) On Fri, Oct 2, 2015 at 3:35 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Adam, > > Are you following the ACE working group? They are wrapping up their use > case document and IETF last call should start next week. OAuth is being > considered and they will be busy with suction work soon for Authenticatio= n > and authorization in Constrained Environments. > > I'd suggest start with a read of the use case draft. The actors draft > will follow through soon with a WGLC (I hope). They should be discussing > solutions in Yokohama. > > Kathleen > > Sent from my iPhone > > On Oct 2, 2015, at 4:19 PM, Adam Lewis > wrote: > > And on that similar note, has their been any work done around having a > singe client id, and registering that client id with the AS, but tying th= e > client id to a trust anchor instead of a single public key certificate, > such that any client issued a certificate by the trusted CA could obtain = an > access token? This would enable a single entry in the AS for each type o= f > client. > > On Fri, Oct 2, 2015 at 2:45 PM, Adam Lewis < > adam.lewis@motorolasolutions.com> wrote: > >> Hi all, >> >> Looking to find some pointers to effort around usage of OAuth and IoT. >> Will embedded devices / appliances use the client credential grant type? >> This would seem to be a natural choice, now does every device have a uni= que >> client id? I am looking at use cases where we will have a large set of >> devices without a UI acting on their own behalf (not the users) and will >> need to obtain access tokens. What are the best practices around this? = It >> seems impractical to add every one of these devices as a unique client t= o >> the OAuth server, but I'm unclear what the other options are given the >> current set of drafts. >> >> >> >> tx! >> adam >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a113b4f404c00a20521251f7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you=C2=A0Kathleen, exactly the type of pointers I was looking for.=C2=A0 Will= head over their now :-)

On Fri, Oct 2, 2015 at 3:35 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Adam,

=
Are you following the ACE working group?=C2=A0 They are wrapping up th= eir use case document and IETF last call should start next week.=C2=A0 OAut= h is being considered and they will be busy with suction work soon for Auth= entication and authorization in Constrained Environments.

I'd suggest start with a read of the use case draft.=C2=A0 The = actors draft will follow through soon with a WGLC (I hope).=C2=A0 They shou= ld be discussing solutions in Yokohama.

Kathleen= =C2=A0

Sent from my iPhone

On O= ct 2, 2015, at 4:19 PM, Adam Lewis <adam.lewis@motorolasolutions.com> = wrote:

And on = that similar note, has their been any work done around having a singe clien= t id, and registering that client id with the AS, but tying the client id t= o a trust anchor instead of a single public key certificate, such that any = client issued a certificate by the trusted CA could obtain an access token?= =C2=A0 This would enable a single entry in the AS for each type of client. = =C2=A0

On Fr= i, Oct 2, 2015 at 2:45 PM, Adam Lewis <adam.lewis@motorolas= olutions.com> wrote:
Hi all,

Looking to find some pointers to effo= rt around usage of OAuth and IoT.=C2=A0 Will embedded devices / appliances = use the client credential grant type?=C2=A0 This would seem to be a natural= choice, now does every device have a unique client id?=C2=A0 I am looking = at use cases where we will have a large set of devices without a UI acting = on their own behalf (not the users) and will need to obtain access tokens.= =C2=A0 What are the best practices around this?=C2=A0 It seems impractical = to add every one of these devices as a unique client to the OAuth server, b= ut I'm unclear what the other options are given the current set of draf= ts.=C2=A0



tx!
<= span>
adam

_______= ________________________________________
OAuth mailing list=
OAuth@= ietf.org
https://www.ie= tf.org/mailman/listinfo/oauth

--001a113b4f404c00a20521251f7b-- From nobody Fri Oct 2 13:42:20 2015 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 EB5C71B2DD4 for ; Fri, 2 Oct 2015 13:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=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 lKYgpiP8M2YS for ; Fri, 2 Oct 2015 13:42:17 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA461B2DD2 for ; Fri, 2 Oct 2015 13:42:16 -0700 (PDT) Received: by qgez77 with SMTP id z77so105287312qge.1 for ; Fri, 02 Oct 2015 13:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9n3ncMw9vFNjMPKkrjiNvjt0YDNsOlU2A5qJqQd6Lj4=; b=g8dPBLWrGqBrFVIOVD+mGm+7wcVLueYTRPSW+WN4s9VtLNVWbOchwl1y0EUe61gkPy UFCA7uCpHzb5WTn3LAPoT89SdmJrZA9CkIZw186yosJKl9DItZVWoVRuB2IfUNdcbt20 VVPXI2Enk3LmlT9K5PxacvdTZFr4GGQEaBYYQchnYKNE01PQ6FP/ie+vgtculRQIBOpJ 63iteLWWKb3gBSDKzW6LDrr/J1fC5KcD5Yi1zBoDq3G4s30C76Fys67IvAH+AUDai/Vr 2flf0GLZaqYhGujMzUsAhZdMCS3uRD552lOEBr9pMSoPqdRjXUO+ZG0BurT3iRUTIznN p9Ag== X-Received: by 10.140.218.133 with SMTP id o127mr24508479qhb.4.1443818535934; Fri, 02 Oct 2015 13:42:15 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id d62sm5356079qhc.19.2015.10.02.13.42.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Oct 2015 13:42:14 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-2718A347-DD0F-4E1B-B0A8-95FBB0F3B25F Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Fri, 2 Oct 2015 16:42:14 -0400 Content-Transfer-Encoding: 7bit Message-Id: <051ED10B-F4A0-47C4-9455-C7C3E69F4396@gmail.com> References: <06859C0C-22CC-4CE8-8A42-593EF2EFDCE1@gmail.com> To: Adam Lewis Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth and IoT 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, 02 Oct 2015 20:42:19 -0000 --Apple-Mail-2718A347-DD0F-4E1B-B0A8-95FBB0F3B25F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable No problem and I guess autocorrect had ideas of its own in my message. s/suction/solution/ Sent from my iPhone > On Oct 2, 2015, at 4:36 PM, Adam Lewis w= rote: >=20 > Thank you Kathleen, exactly the type of pointers I was looking for. Will h= ead over their now :-) >=20 >> On Fri, Oct 2, 2015 at 3:35 PM, Kathleen Moriarty wrote: >> Adam, >>=20 >> Are you following the ACE working group? They are wrapping up their use c= ase document and IETF last call should start next week. OAuth is being cons= idered and they will be busy with suction work soon for Authentication and a= uthorization in Constrained Environments. >>=20 >> I'd suggest start with a read of the use case draft. The actors draft wi= ll follow through soon with a WGLC (I hope). They should be discussing solu= tions in Yokohama. >>=20 >> Kathleen=20 >>=20 >> Sent from my iPhone >>=20 >>> On Oct 2, 2015, at 4:19 PM, Adam Lewis wrote: >>>=20 >>> And on that similar note, has their been any work done around having a s= inge client id, and registering that client id with the AS, but tying the cl= ient id to a trust anchor instead of a single public key certificate, such t= hat any client issued a certificate by the trusted CA could obtain an access= token? This would enable a single entry in the AS for each type of client.= =20 >>>=20 >>>> On Fri, Oct 2, 2015 at 2:45 PM, Adam Lewis wrote: >>>> Hi all, >>>>=20 >>>> Looking to find some pointers to effort around usage of OAuth and IoT. = Will embedded devices / appliances use the client credential grant type? T= his would seem to be a natural choice, now does every device have a unique c= lient id? I am looking at use cases where we will have a large set of devic= es without a UI acting on their own behalf (not the users) and will need to o= btain access tokens. What are the best practices around this? It seems imp= ractical to add every one of these devices as a unique client to the OAuth s= erver, but I'm unclear what the other options are given the current set of d= rafts.=20 >>>>=20 >>>>=20 >>>>=20 >>>> tx! >>>> adam >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-2718A347-DD0F-4E1B-B0A8-95FBB0F3B25F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
No problem and I guess autocorrect had= ideas of its own in my message.

s/suction/solution= /

Sent from my iPhone

On Oct 2, 2015, at 4:36 PM, Adam L= ewis <adam.lewis@moto= rolasolutions.com> wrote:

Thank you Kathleen, exactly the type of pointers I was looking for.  Will h= ead over their now :-)

On Fri, Oct 2, 2015 at 3:35 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Adam,

Are= you following the ACE working group?  They are wrapping up their use c= ase document and IETF last call should start next week.  OAuth is being= considered and they will be busy with suction work soon for Authentication a= nd authorization in Constrained Environments.

I'd s= uggest start with a read of the use case draft.  The actors draft will f= ollow through soon with a WGLC (I hope).  They should be discussing sol= utions in Yokohama.

Kathleen 

Sent from= my iPhone

On Oct 2, 2015, at 4:19 PM, A= dam Lewis <adam.lewis@motorolasolutions.com> wrote:

And on that similar note, has their= been any work done around having a singe client id, and registering that cl= ient id with the AS, but tying the client id to a trust anchor instead of a s= ingle public key certificate, such that any client issued a certificate by t= he trusted CA could obtain an access token?  This would enable a single= entry in the AS for each type of client.  

On Fri, Oct 2, 2015 at 2:45 PM, Adam Lew= is <adam.lewis@motorolasolutions.com> wrote:
Hi all,

L= ooking to find some pointers to effort around usage of OAuth and IoT.  W= ill embedded devices / appliances use the client credential grant type? = ; This would seem to be a natural choice, now does every device have a uniqu= e client id?  I am looking at use cases where we will have a large set o= f devices without a UI acting on their own behalf (not the users) and will n= eed to obtain access tokens.  What are the best practices around this?&= nbsp; It seems impractical to add every one of these devices as a unique cli= ent to the OAuth server, but I'm unclear what the other options are given th= e current set of drafts. 



<= /div>
tx!
adam

________= _______________________________________
OAuth mailing list
OAuth@iet= f.org
https://www.ietf.org/m= ailman/listinfo/oauth

= --Apple-Mail-2718A347-DD0F-4E1B-B0A8-95FBB0F3B25F-- From nobody Wed Oct 7 07:30:25 2015 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 577C21A92E1 for ; Wed, 7 Oct 2015 07:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 2mk1e_K_ewWj for ; Wed, 7 Oct 2015 07:30:07 -0700 (PDT) Received: from out4133-82.mail.aliyun.com (out4133-82.mail.aliyun.com [42.120.133.82]) by ietfa.amsl.com (Postfix) with ESMTP id 050A91A9142 for ; Wed, 7 Oct 2015 07:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1444228203; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=4cHcmHejYwgfm0L8frkFfSPQswOoYiIcGHeB6ljfTOw=; b=llhYiZMto6/MqQEqiqfIdZaroMXdyLNzBtNUPidHMNVq0+edagjvpYwOu910A3mqR9KNWEf3e1geudO4TkjI2CjEUIGJYn05bFe8EjavwdPpE05PXGPGECWB5pc7t5pEB5bqgurBzXbNjD3u8jWB7w9vmqQRTGL0PPHTd9V8g/M= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R121e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03289; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=1; SR=0; Received: from 10.22.32.178(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Wed, 07 Oct 2015 22:29:57 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 07 Oct 2015 22:29:54 +0800 From: "Kepeng Li" To: Message-ID: Thread-Topic: Review comments to PoP document Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3527101798_1352027" Archived-At: Subject: [OAUTH-WG] Review comments to PoP document 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, 07 Oct 2015 14:30:10 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3527101798_1352027 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hello all, Please find my review comments to PoP document: http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04 =20 1=E3=80=81 Title: Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) [Kepeng] Should we add OAuth 2.0 in the title? Also, in the whole document, we use JWT, but in the title, we use =E2=80=9CJWTs=E2=80=9D. Is there a reason for this= ? =20 2=E3=80=81 Abstract=EF=BC=9A 1) This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter. [Kepeng] Add reference to JWT. =20 2) This property is also sometimes described as the presenter being a holder-of-key. [Kepeng] I am not sure what is =E2=80=9Cthis property=E2=80=9D. Do you mean =E2=80=9Cthe key=E2= =80=9D? If yes, just use the key. And change the sentence to something like: This key is also sometimes described as a holder-of-key by the presenter. =20 3. Introduction 1) The first paragraph is the same as the abstract. I suggest to reword it = a little bit or remove it, to avoid the redundancy. =20 2) See [I-D.ietf-oauth-pop-architecture] for a further discussion of key confirmation. [Kepeng] I suggest to mention a little bit more about the relationship between PoP architecture document and this document. In my understanding, i= n PoP architecture document, it mentions several mechanisms: confidentiality protection, key confirmation and sender constraint. This document introduce= s the key semantics for the key confirmation mechanism. =20 3) About the two use cases, it will be useful to use two diagrams or flows to indicate how it works. Maybe put these two flows in a separate section. Also it will be useful to mention which step is in scope, and which is out of scope, e.g. how to convey symmetric key from the issuer to the presenter= . =20 4. Section 3: 1) It will be useful to put a reference to "sub" (subject) claim, and "iss" (issuer) claim. =20 2) Note that if an application needs to represent multiple proof-of- possession keys in the same JWT, one way for it to achieve this is to use other claim names, in addition to "cnf", to hold the additional proof-of-possession key information. [Kepeng] It is not clear, what are the other claim names? Kind Regards Kepeng --B_3527101798_1352027 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hello all,

Please= find my review comments to PoP document:
 
<= div>

<= span lang=3D"EN-US">1=E3=80=81         Title:

=

Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)

[Kepeng] Should we add OAuth 2.0 in the title? Also, in the whole document, we use J= WT, but in the title, we use “JWTs”. Is there a reason for this?

 

<= span lang=3D"EN-US">2=E3=80=81         Abstract=EF=BC=9A<= /span>

1) This = specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possess= es a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter.

[Kepeng]= Add reference to JWT.

 

2) This property is also sometimes described as the presenter being a holder-of-key.

[Kepeng] I am not sure what is “this property”. Do you mean “the key= ”? If yes, just use the key. And change the sentence to something like: This key is also someti= mes described as a holder-of-key by the presenter.

 

3. Introduction

1) The first paragraph is the same as the abstract. I suggest to reword it a littl= e bit or remove it, to avoid the redundancy.

 

2) See [= I-D.ietf-oauth-pop-architecture] for a further discussion of key confirmation.

[Kepeng]= I suggest to mention a little bit more about the relationship between PoP architecture document and this document.= In my understanding, in PoP architecture document, it mentions several mechani= sms: confidentiality protection, key confirmation and sender constraint. This document introduces the key semantics for the key confirmation mechanism.

 

3) About= the two use cases, it will be useful to use two diagrams or flows to indicate how it works. Maybe put these two = flows in a separate section. Also it will be useful to mention which step is in scope, and which is out of scope, e.g. how to convey symmetric key from the issuer to the presenter.

 

4. Secti= on 3:

1) It wi= ll be useful to put a reference to "sub" (subject) claim, and "iss" (issuer) claim.

 

2) Note = that if an application needs to represent multiple proof-of-

 &n= bsp; possession keys in the same JWT, one way for it to achieve this is to<= /o:p>

 &n= bsp; use other claim names, in addition to "cnf", to hold the additional<= /span>

 &n= bsp; proof-of-possession key information.

[Kepeng]= It is not clear, what are the other claim names?


Kind Reg= ards

Kepeng

--B_3527101798_1352027-- From nobody Thu Oct 8 11:00:32 2015 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 B71811B2CF8 for ; Thu, 8 Oct 2015 11:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 nlADXsC8Ow3W for ; Thu, 8 Oct 2015 11:00:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0763.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::763]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFDC1B2CFA for ; Thu, 8 Oct 2015 11:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=264nTcFZHdUEi1/MWMpNN2cs3jNcB+PUguD5+oNzH+A=; b=KgsZ+Bf2+ZwuRtqRTv2z44nzKVvjXNOjF1slequxjtB+QUehDt75TfS8g1FEai87+2QV9Gonc2+rUJ9eoHBpdGW8h1GvoCuDTyXFx0fs15eEJv+tUHm1r4QNJ3hQVHre9izsNuSRnBXNjUrHObmXMC9YKVYcDcb6H2qF7FMYzfA= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.293.16; Thu, 8 Oct 2015 17:59:58 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0293.007; Thu, 8 Oct 2015 17:58:34 +0000 From: Mike Jones To: Kepeng Li , "oauth@ietf.org" Thread-Topic: Review comments to PoP document Thread-Index: AQHRAQy64oow7N4z4U6J9u6BZvdoP55hw/IQ Date: Thu, 8 Oct 2015 17:58:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [100.44.230.73] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:OTSHZ8rv2ad0PpRSs5BVA21XuLzlbA7YqP2ONQVlLtyXShl48zqz+BdvnDwK4iZcVcQoOoA3Pu1MWGBERIe+rixpGA6yp0hn3JoLFmuwSirqDetAUxhdkZu60f0Ax3UMR6avlUalMbXRsgL6TjSH+w==; 24:zIcXrLhsLL25x9/FQPZhWex6hOcT/dV6XC0xJ0wiEJmymzgTfARYi960DqxHXbfzjB7jNwu/X6qnP/761/IZS2iaTl2pISyCfoCUtwspphk=; 20:c/c2YQPHeXUUP/LXVA9/JRxpv9TPGIXQJ7PQ5ne1xHaELXjrJY3EjVTUiBAEH9obxUNF9iVyRYizR1jJfRzZQw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0723A02764 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(71364002)(43784003)(53754006)(189002)(199003)(377454003)(8990500004)(5005710100001)(40100003)(19617315012)(10290500002)(66066001)(76176999)(122556002)(10400500002)(54356999)(5003600100002)(19609705001)(101416001)(5007970100001)(19580395003)(74316001)(10090500001)(19625215002)(92566002)(107886002)(5001960100002)(64706001)(5001770100001)(5004730100002)(106116001)(86612001)(105586002)(99286002)(33656002)(81156007)(19580405001)(76576001)(77096005)(106356001)(15975445007)(102836002)(2950100001)(87936001)(97736004)(16236675004)(19300405004)(50986999)(2900100001)(46102003)(2501003)(86362001)(189998001)(5008740100001)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442210DD6E914261F978382F5350BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2015 17:58:34.1996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [OAUTH-WG] Review comments to PoP document 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, 08 Oct 2015 18:00:31 -0000 --_000_BY2PR03MB442210DD6E914261F978382F5350BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgdXNlZnVsIHJldmlldywgS2VwZW5nLiAgUmVzcG9uc2VzIGlubGluZeKA pg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBLZXBlbmcgTGkNClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwNywgMjAxNSA3OjMwIEFN DQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFtPQVVUSC1XR10gUmV2aWV3IGNvbW1lbnRz IHRvIFBvUCBkb2N1bWVudA0KDQpIZWxsbyBhbGwsDQoNClBsZWFzZSBmaW5kIG15IHJldmlldyBj b21tZW50cyB0byBQb1AgZG9jdW1lbnQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24tMDQ8aHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZnRvb2xzLmlldGYub3Jn JTJmaHRtbCUyZmRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wNCZkYXRhPTAx JTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzM5ZmMzNjdiZmMwNDRmZTky NDNjMDhkMmNmMjNkOTViJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNk YXRhPVhOWDg5bDIxR3pDb0tEemtRdWZkTjF2RjlWc0dxT3BOcFdwOU02eXlxQVElM2Q+DQoNCg0K MeOAgSAgICAgICAgICBUaXRsZToNClByb29mLW9mLVBvc3Nlc3Npb24gS2V5IFNlbWFudGljcyBm b3IgSlNPTiBXZWIgVG9rZW5zIChKV1RzKQ0KW0tlcGVuZ10gU2hvdWxkIHdlIGFkZCBPQXV0aCAy LjAgaW4gdGhlIHRpdGxlPyBBbHNvLCBpbiB0aGUgd2hvbGUgZG9jdW1lbnQsIHdlIHVzZSBKV1Qs IGJ1dCBpbiB0aGUgdGl0bGUsIHdlIHVzZSDigJxKV1Rz4oCdLiBJcyB0aGVyZSBhIHJlYXNvbiBm b3IgdGhpcz8NCg0KSSB3b3VsZG7igJl0IHN1Z2dlc3QgYWRkaW5nIOKAnE9BdXRoIDIuMOKAnSB0 byB0aGUgdGl0bGUsIGluIHBhcnQsIGJlY2F1c2UgSldUcyBhcmUgdXNlZCBpbiBjb250ZXh0cyBv dXRzaWRlIG9mIE9BdXRoLiAgQXMgZm9yIHdoeSBKV1RzIGlzIHBsdXJhbCBoZXJlLCB0aGUgdGl0 bGUgaXMgc2F5aW5nIHRoYXQgUG9QIGtleXMgY2FuIGJlIGNvbW11bmljYXRlZCBpbiBKU09OIFdl YiBUb2tlbnMuICBJZiBpdCB3ZXJlIHNpbmd1bGFyLCBpdCB3b3VsZCBzb3VuZCBsaWtlIHlvdSBj b3VsZCBvbmx5IHVzZSBQb1Aga2V5cyBpbiBhIHNpbmdsZSBKV1QsIHdoaWNoIGlzbuKAmXQgcmln aHQuDQoNCg0KMuOAgSAgICAgICAgICBBYnN0cmFjdO+8mg0KMSkgVGhpcyBzcGVjaWZpY2F0aW9u IGRlZmluZXMgaG93IHRvIGV4cHJlc3MgYSBkZWNsYXJhdGlvbiBpbiBhIEpTT04gV2ViIFRva2Vu IChKV1QpIHRoYXQgdGhlIHByZXNlbnRlciBvZiB0aGUgSldUIHBvc3Nlc3NlcyBhIHBhcnRpY3Vs YXIga2V5IGFuZCB0aGF0IHRoZSByZWNpcGllbnQgY2FuIGNyeXB0b2dyYXBoaWNhbGx5IGNvbmZp cm0gcHJvb2Ytb2YtcG9zc2Vzc2lvbiBvZiB0aGUga2V5IGJ5IHRoZSBwcmVzZW50ZXIuDQpbS2Vw ZW5nXSBBZGQgcmVmZXJlbmNlIHRvIEpXVC4NCg0KSeKAmXZlIGJlZW4gdG9sZCB3aGVuIGVkaXRp bmcgb3RoZXIgZHJhZnRzIHRvIHJlbW92ZSByZWZlcmVuY2VzIHRoYXQgSeKAmWQgcGxhY2VkIGlu IGFic3RyYWN0cywgc2luY2UgSUVURiBhYnN0cmFjdHMgZG9u4oCZdCBpbmNsdWRlIHJlZmVyZW5j ZXMuDQoNCjIpIFRoaXMgcHJvcGVydHkgaXMgYWxzbyBzb21ldGltZXMgZGVzY3JpYmVkIGFzIHRo ZSBwcmVzZW50ZXIgYmVpbmcgYSBob2xkZXItb2Yta2V5Lg0KW0tlcGVuZ10gSSBhbSBub3Qgc3Vy ZSB3aGF0IGlzIOKAnHRoaXMgcHJvcGVydHnigJ0uIERvIHlvdSBtZWFuIOKAnHRoZSBrZXnigJ0/ IElmIHllcywganVzdCB1c2UgdGhlIGtleS4gQW5kIGNoYW5nZSB0aGUgc2VudGVuY2UgdG8gc29t ZXRoaW5nIGxpa2U6IFRoaXMga2V5IGlzIGFsc28gc29tZXRpbWVzIGRlc2NyaWJlZCBhcyBhIGhv bGRlci1vZi1rZXkgYnkgdGhlIHByZXNlbnRlci4NCg0KSSBjYW4gY2hhbmdlIOKAnFRoaXMgcHJv cGVydHnigJ0gdG8g4oCcQmVpbmcgYWJsZSB0byBwcm92ZSBwb3NzZXNzaW9uIG9mIGEga2V54oCd Lg0KDQozLiBJbnRyb2R1Y3Rpb24NCjEpIFRoZSBmaXJzdCBwYXJhZ3JhcGggaXMgdGhlIHNhbWUg YXMgdGhlIGFic3RyYWN0LiBJIHN1Z2dlc3QgdG8gcmV3b3JkIGl0IGEgbGl0dGxlIGJpdCBvciBy ZW1vdmUgaXQsIHRvIGF2b2lkIHRoZSByZWR1bmRhbmN5Lg0KDQpUaGUgcmVzdCBvZiB0aGUgaW50 cm9kdWN0aW9uIGJ1aWxkcyBvbiB0aGUgaWRlYXMgaW50cm9kdWNlZCBpbiB0aGUgZmlyc3QgdHdv IHNlbnRlbmNlcyAodGhlIGNvbnRlbnQgb2YgdGhlIGFic3RyYWN0KS4gSWYgdGhleSB3ZXJlIHRv IGJlIHJlbW92ZWQsIGl0IHdvdWxkIG1ha2UgdGhlIGludHJvZHVjdGlvbiBjb25mdXNpbmcsIGFz IG1hbnkgcGVvcGxlIHdvbuKAmXQgc3RhcnQgYnkgcmVhZGluZyB0aGUgYWJzdHJhY3QsIGJ1dCB3 aWxsIHJlYWQgdGhlIGludHJvZHVjdGlvbiBpbmRlcGVuZGVudGx5LiAgKFRoZSBpbnRyb2R1Y3Rp b24gZG9lcyBhZGQgcmVmZXJlbmNlcywgd2hpY2ggY2Fubm90IGJlIHByZXNlbnQgaW4gdGhlIGFi c3RyYWN0LikgIEnigJlsbCB3b3JrIHdpdGggdGhlIG90aGVyIGVkaXRvcnMgdG8gc2VlIGlmIHRo ZXkgd2FudCB0byByZXdvcmQgdGhlIGZpcnN0IHR3byBzZW50ZW5jZXMgb2YgdGhlIGludHJvZHVj dGlvbiBhbmQvb3IgYWJzdHJhY3QgdG8gbWFrZSB0aGVtIGRpZmZlcmVudCBmcm9tIG9uZSBhbm90 aGVyLg0KDQoyKSBTZWUgW0ktRC5pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmVdIGZvciBhIGZ1 cnRoZXIgZGlzY3Vzc2lvbiBvZiBrZXkgY29uZmlybWF0aW9uLg0KW0tlcGVuZ10gSSBzdWdnZXN0 IHRvIG1lbnRpb24gYSBsaXR0bGUgYml0IG1vcmUgYWJvdXQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIFBvUCBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgYW5kIHRoaXMgZG9jdW1lbnQuIEluIG15IHVu ZGVyc3RhbmRpbmcsIGluIFBvUCBhcmNoaXRlY3R1cmUgZG9jdW1lbnQsIGl0IG1lbnRpb25zIHNl dmVyYWwgbWVjaGFuaXNtczogY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24sIGtleSBjb25maXJt YXRpb24gYW5kIHNlbmRlciBjb25zdHJhaW50LiBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgdGhl IGtleSBzZW1hbnRpY3MgZm9yIHRoZSBrZXkgY29uZmlybWF0aW9uIG1lY2hhbmlzbS4NCg0KT0sg 4oCTIHdlIGNhbiBzYXkgdGhhdCBbSS1ELmlldGYtb2F1dGgtcG9wLWFyY2hpdGVjdHVyZV0gZGVz Y3JpYmVzIGtleSBjb25maXJtYXRpb24sIGFtb25nIG90aGVyIGNvbmZvcm1hdGlvbiBtZWNoYW5p c21zLCBhbmQgdGhhdCB0aGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBob3cgdG8gY29tbXVuaWNh dGUga2V5IGNvbmZpcm1hdGlvbiBrZXkgaW5mb3JtYXRpb24gaW4gSldUcy4NCg0KMykgQWJvdXQg dGhlIHR3byB1c2UgY2FzZXMsIGl0IHdpbGwgYmUgdXNlZnVsIHRvIHVzZSB0d28gZGlhZ3JhbXMg b3IgZmxvd3MgdG8gaW5kaWNhdGUgaG93IGl0IHdvcmtzLiBNYXliZSBwdXQgdGhlc2UgdHdvIGZs b3dzIGluIGEgc2VwYXJhdGUgc2VjdGlvbi4gQWxzbyBpdCB3aWxsIGJlIHVzZWZ1bCB0byBtZW50 aW9uIHdoaWNoIHN0ZXAgaXMgaW4gc2NvcGUsIGFuZCB3aGljaCBpcyBvdXQgb2Ygc2NvcGUsIGUu Zy4gaG93IHRvIGNvbnZleSBzeW1tZXRyaWMga2V5IGZyb20gdGhlIGlzc3VlciB0byB0aGUgcHJl c2VudGVyLg0KDQpCb3RoIGFyZSBpbiBzY29wZSwgd2hpY2ggaXMgd2h5IHRoZXnigJlyZSBib3Ro IGRlc2NyaWJlZCBpbiB0aGUgaW50cm9kdWN0aW9uLiAgSeKAmWxsIHdvcmsgd2l0aCB0aGUgb3Ro ZXIgZWRpdG9ycyBvbiB0cnlpbmcgdG8gY3JlYXRlIGFwcHJvcHJpYXRlIGRpYWdyYW1zLg0KDQo0 LiBTZWN0aW9uIDM6DQoxKSBJdCB3aWxsIGJlIHVzZWZ1bCB0byBwdXQgYSByZWZlcmVuY2UgdG8g InN1YiIgKHN1YmplY3QpIGNsYWltLCBhbmQgImlzcyIgKGlzc3VlcikgY2xhaW0uDQoNCk9LDQoN CjIpIE5vdGUgdGhhdCBpZiBhbiBhcHBsaWNhdGlvbiBuZWVkcyB0byByZXByZXNlbnQgbXVsdGlw bGUgcHJvb2Ytb2YtDQogICBwb3NzZXNzaW9uIGtleXMgaW4gdGhlIHNhbWUgSldULCBvbmUgd2F5 IGZvciBpdCB0byBhY2hpZXZlIHRoaXMgaXMgdG8NCiAgIHVzZSBvdGhlciBjbGFpbSBuYW1lcywg aW4gYWRkaXRpb24gdG8gImNuZiIsIHRvIGhvbGQgdGhlIGFkZGl0aW9uYWwNCiAgIHByb29mLW9m LXBvc3Nlc3Npb24ga2V5IGluZm9ybWF0aW9uLg0KW0tlcGVuZ10gSXQgaXMgbm90IGNsZWFyLCB3 aGF0IGFyZSB0aGUgb3RoZXIgY2xhaW0gbmFtZXM/DQoNCkZhaXIgcG9pbnQuICBXZSBjYW4gc2F5 IHRoYXQgdGhvc2UgY2xhaW0gbmFtZXMgd291bGQgYmUgZGVmaW5lZCBieSBhcHBsaWNhdGlvbnMg YW5kIGNvdWxkIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIEpXVCBDbGFpbXMgUmVnaXN0cnkuDQoNCktp bmQgUmVnYXJkcw0KS2VwZW5nDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiENCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg== --_000_BY2PR03MB442210DD6E914261F978382F5350BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMg MSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYW1icmlh Ow0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hv IjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGln bjpqdXN0aWZ5Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bWJyaWEiLCJzZXJpZiI7fQ0KLyogUGFnZSBEZWZpbml0aW9ucyAqLw0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1OTczMjQxMjQ7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjM2NTA0MTMxMCAtNTYxODQ5 MTAwIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDol MeOAgTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS41aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlMlwpIjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6NDguMHB0Ow0KCXRleHQtaW5kZW50Oi0yNC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ bWFyZ2luLWxlZnQ6MS4waW47DQoJdGV4dC1pbmRlbnQ6LTI0LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Ojk2LjBwdDsNCgl0ZXh0LWluZGVudDotMjQuMHB0O30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGV4dDoiJTVcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEyMC4wcHQ7DQoJdGV4dC1p bmRlbnQ6LTI0LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDoyLjBpbjsNCgl0ZXh0LWluZGVudDot MjQuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTY4LjBwdDsNCgl0 ZXh0LWluZGVudDotMjQuMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJThcKSI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdp bi1sZWZ0OjE5Mi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTI0LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVm dDozLjBpbjsNCgl0ZXh0LWluZGVudDotMjQuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMDAyMDYwIj5UaGFua3MgZm9yIHRoZSB1c2VmdWwgcmV2aWV3LCBLZXBlbmcuJm5ic3A7 IFJlc3BvbnNlcyBpbmxpbmXigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxl ZnQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPktlcGVuZyBMaTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRu ZXNkYXksIE9jdG9iZXIgMDcsIDIwMTUgNzozMCBBTTxicj4NCjxiPlRvOjwvYj4gb2F1dGhAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBSZXZpZXcgY29tbWVudHMgdG8g UG9QIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVm dCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj5IZWxsbyBhbGwsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi IHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxl PSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OlNpbVN1bjtjb2xvcjpibGFjayI+UGxlYXNlIGZpbmQgbXkgcmV2aWV3IGNvbW1lbnRzIHRv IFBvUCBkb2N1bWVudDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNr Ij48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtaWV0Zi1vYXV0 aC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA0JmFtcDtkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVz JTQwbWljcm9zb2Z0LmNvbSU3YzM5ZmMzNjdiZmMwNDRmZTkyNDNjMDhkMmNmMjNkOTViJTdjNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1YTlg4OWwyMUd6Q29L RHprUXVmZE4xdkY5VnNHcU9wTnBXcDlNNnl5cUFRJTNkIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24tMDQ8L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYW1icmlhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6 LS41aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4x44CB PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRpdGxl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+UHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciBKU09O IFdlYiBUb2tlbnMgKEpXVHMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5bS2VwZW5nXSBTaG91bGQgd2UgYWRkIE9B dXRoIDIuMCBpbiB0aGUgdGl0bGU/IEFsc28sIGluIHRoZSB3aG9sZSBkb2N1bWVudCwgd2UgdXNl IEpXVCwgYnV0IGluIHRoZSB0aXRsZSwgd2UgdXNlIOKAnEpXVHPigJ0uIElzIHRoZXJlIGEgcmVh c29uIGZvciB0aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzAwMjA2MCI+SSB3b3VsZG7igJl0IHN1Z2dlc3QgYWRkaW5nIOKAnE9BdXRoIDIuMOKAnSB0byB0 aGUgdGl0bGUsIGluIHBhcnQsIGJlY2F1c2UgSldUcyBhcmUgdXNlZCBpbiBjb250ZXh0cyBvdXRz aWRlIG9mIE9BdXRoLiZuYnNwOyBBcyBmb3Igd2h5IEpXVHMgaXMgcGx1cmFsIGhlcmUsIHRoZSB0 aXRsZSBpcyBzYXlpbmcgdGhhdCBQb1Aga2V5cyBjYW4gYmUgY29tbXVuaWNhdGVkDQogaW4gSlNP TiBXZWIgVG9rZW5zLiZuYnNwOyBJZiBpdCB3ZXJlIHNpbmd1bGFyLCBpdCB3b3VsZCBzb3VuZCBs aWtlIHlvdSBjb3VsZCBvbmx5IHVzZSBQb1Aga2V5cyBpbiBhIHNpbmdsZSBKV1QsIHdoaWNoIGlz buKAmXQgcmlnaHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+MuOAgTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5BYnN0cmFjdDwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90Oztjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+77yaPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi IHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4xKSBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBob3cgdG8gZXhwcmVz cyBhIGRlY2xhcmF0aW9uIGluIGEgSlNPTiBXZWIgVG9rZW4gKEpXVCkgdGhhdCB0aGUgcHJlc2Vu dGVyIG9mIHRoZSBKV1QgcG9zc2Vzc2VzIGEgcGFydGljdWxhciBrZXkgYW5kIHRoYXQgdGhlDQog cmVjaXBpZW50IGNhbiBjcnlwdG9ncmFwaGljYWxseSBjb25maXJtIHByb29mLW9mLXBvc3Nlc3Np b24gb2YgdGhlIGtleSBieSB0aGUgcHJlc2VudGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3Rl eHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W0tlcGVuZ10gQWRk IHJlZmVyZW5jZSB0byBKV1QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6 bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFj ZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj5J4oCZ dmUgYmVlbiB0b2xkIHdoZW4gZWRpdGluZyBvdGhlciBkcmFmdHMgdG8gcmVtb3ZlIHJlZmVyZW5j ZXMgdGhhdCBJ4oCZZCBwbGFjZWQgaW4gYWJzdHJhY3RzLCBzaW5jZSBJRVRGIGFic3RyYWN0cyBk b27igJl0IGluY2x1ZGUgcmVmZXJlbmNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1 dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjIpIFRoaXMgcHJvcGVydHkgaXMgYWxzbyBzb21ldGltZXMg ZGVzY3JpYmVkIGFzIHRoZSBwcmVzZW50ZXIgYmVpbmcgYSBob2xkZXItb2Yta2V5LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+W0tlcGVuZ10gSSBhbSBub3Qgc3VyZSB3aGF0IGlzIOKAnHRoaXMgcHJvcGVydHnigJ0u IERvIHlvdSBtZWFuIOKAnHRoZSBrZXnigJ0/IElmIHllcywganVzdCB1c2UgdGhlIGtleS4gQW5k IGNoYW5nZSB0aGUgc2VudGVuY2UgdG8gc29tZXRoaW5nIGxpa2U6IFRoaXMga2V5IGlzIGFsc28g c29tZXRpbWVzIGRlc2NyaWJlZCBhcyBhIGhvbGRlci1vZi1rZXkgYnkgdGhlIHByZXNlbnRlci48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPkkgY2Fu IGNoYW5nZSDigJxUaGlzIHByb3BlcnR54oCdIHRvIOKAnEJlaW5nIGFibGUgdG8gcHJvdmUgcG9z c2Vzc2lvbiBvZiBhIGtleeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjMuIEludHJvZHVjdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MSkgVGhlIGZpcnN0 IHBhcmFncmFwaCBpcyB0aGUgc2FtZSBhcyB0aGUgYWJzdHJhY3QuIEkgc3VnZ2VzdCB0byByZXdv cmQgaXQgYSBsaXR0bGUgYml0IG9yIHJlbW92ZSBpdCwgdG8gYXZvaWQgdGhlIHJlZHVuZGFuY3ku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPlRo ZSByZXN0IG9mIHRoZSBpbnRyb2R1Y3Rpb24gYnVpbGRzIG9uIHRoZSBpZGVhcyBpbnRyb2R1Y2Vk IGluIHRoZSBmaXJzdCB0d28gc2VudGVuY2VzICh0aGUgY29udGVudCBvZiB0aGUgYWJzdHJhY3Qp LiBJZiB0aGV5IHdlcmUgdG8gYmUgcmVtb3ZlZCwgaXQgd291bGQgbWFrZSB0aGUgaW50cm9kdWN0 aW9uIGNvbmZ1c2luZywgYXMNCiBtYW55IHBlb3BsZSB3b27igJl0IHN0YXJ0IGJ5IHJlYWRpbmcg dGhlIGFic3RyYWN0LCBidXQgd2lsbCByZWFkIHRoZSBpbnRyb2R1Y3Rpb24gaW5kZXBlbmRlbnRs eS4mbmJzcDsgKFRoZSBpbnRyb2R1Y3Rpb24gZG9lcyBhZGQgcmVmZXJlbmNlcywgd2hpY2ggY2Fu bm90IGJlIHByZXNlbnQgaW4gdGhlIGFic3RyYWN0LikmbmJzcDsgSeKAmWxsIHdvcmsgd2l0aCB0 aGUgb3RoZXIgZWRpdG9ycyB0byBzZWUgaWYgdGhleSB3YW50IHRvIHJld29yZCB0aGUgZmlyc3Qg dHdvIHNlbnRlbmNlcw0KIG9mIHRoZSBpbnRyb2R1Y3Rpb24gYW5kL29yIGFic3RyYWN0IHRvIG1h a2UgdGhlbSBkaWZmZXJlbnQgZnJvbSBvbmUgYW5vdGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpu b25lIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjIpIFNlZSBbSS1ELmlldGYtb2F1dGgtcG9w LWFyY2hpdGVjdHVyZV0gZm9yIGEgZnVydGhlciBkaXNjdXNzaW9uIG9mIGtleSBjb25maXJtYXRp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249Imxl ZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5bS2VwZW5nXSBJIHN1Z2dlc3QgdG8gbWVudGlvbiBhIGxpdHRsZSBi aXQgbW9yZSBhYm91dCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gUG9QIGFyY2hpdGVjdHVyZSBk b2N1bWVudCBhbmQgdGhpcyBkb2N1bWVudC4gSW4gbXkgdW5kZXJzdGFuZGluZywgaW4gUG9QIGFy Y2hpdGVjdHVyZQ0KIGRvY3VtZW50LCBpdCBtZW50aW9ucyBzZXZlcmFsIG1lY2hhbmlzbXM6IGNv bmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uLCBrZXkgY29uZmlybWF0aW9uIGFuZCBzZW5kZXIgY29u c3RyYWludC4gVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIHRoZSBrZXkgc2VtYW50aWNzIGZvciB0 aGUga2V5IGNvbmZpcm1hdGlvbiBtZWNoYW5pc20uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4 dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9 InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj5PSyDigJMgd2UgY2FuIHNheSB0aGF0IFtJLUQuaWV0 Zi1vYXV0aC1wb3AtYXJjaGl0ZWN0dXJlXSBkZXNjcmliZXMga2V5IGNvbmZpcm1hdGlvbiwgYW1v bmcgb3RoZXIgY29uZm9ybWF0aW9uIG1lY2hhbmlzbXMsIGFuZCB0aGF0IHRoaXMNCiBzcGVjaWZp Y2F0aW9uIGRlZmluZXMgaG93IHRvIGNvbW11bmljYXRlIGtleSBjb25maXJtYXRpb24ga2V5IGlu Zm9ybWF0aW9uIGluIEpXVHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6 bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi IHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4zKSBBYm91dCB0aGUgdHdvIHVzZSBjYXNlcywgaXQgd2lsbCBiZSB1c2Vm dWwgdG8gdXNlIHR3byBkaWFncmFtcyBvciBmbG93cyB0byBpbmRpY2F0ZSBob3cgaXQgd29ya3Mu IE1heWJlIHB1dCB0aGVzZSB0d28gZmxvd3MgaW4gYSBzZXBhcmF0ZSBzZWN0aW9uLiBBbHNvDQog aXQgd2lsbCBiZSB1c2VmdWwgdG8gbWVudGlvbiB3aGljaCBzdGVwIGlzIGluIHNjb3BlLCBhbmQg d2hpY2ggaXMgb3V0IG9mIHNjb3BlLCBlLmcuIGhvdyB0byBjb252ZXkgc3ltbWV0cmljIGtleSBm cm9tIHRoZSBpc3N1ZXIgdG8gdGhlIHByZXNlbnRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0 ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25l Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj5Cb3RoIGFyZSBp biBzY29wZSwgd2hpY2ggaXMgd2h5IHRoZXnigJlyZSBib3RoIGRlc2NyaWJlZCBpbiB0aGUgaW50 cm9kdWN0aW9uLiZuYnNwOyBJ4oCZbGwgd29yayB3aXRoIHRoZSBvdGhlciBlZGl0b3JzIG9uIHRy eWluZyB0byBjcmVhdGUgYXBwcm9wcmlhdGUNCiBkaWFncmFtcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246 bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0 IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+NC4gU2VjdGlvbiAzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQt YXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MSkgSXQgd2lsbCBiZSB1 c2VmdWwgdG8gcHV0IGEgcmVmZXJlbmNlIHRvICZxdW90O3N1YiZxdW90OyAoc3ViamVjdCkgY2xh aW0sIGFuZCAmcXVvdDtpc3MmcXVvdDsgKGlzc3VlcikgY2xhaW0uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWdu OmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJs ZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPk9LPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWdu OmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3Bh Y2U6bm9uZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4yKSBOb3RlIHRoYXQgaWYgYW4gYXBw bGljYXRpb24gbmVlZHMgdG8gcmVwcmVzZW50IG11bHRpcGxlIHByb29mLW9mLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4 dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IHBvc3Nlc3Npb24ga2V5cyBpbiB0aGUgc2FtZSBKV1QsIG9uZSB3YXkg Zm9yIGl0IHRvIGFjaGlldmUgdGhpcyBpcyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQt YXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHVz ZSBvdGhlciBjbGFpbSBuYW1lcywgaW4gYWRkaXRpb24gdG8gJnF1b3Q7Y25mJnF1b3Q7LCB0byBo b2xkIHRoZSBhZGRpdGlvbmFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6 bm9uZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcHJvb2Ytb2YtcG9z c2Vzc2lvbiBrZXkgaW5mb3JtYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRv c3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5bS2VwZW5nXSBJdCBpcyBub3Qg Y2xlYXIsIHdoYXQgYXJlIHRoZSBvdGhlciBjbGFpbSBuYW1lcz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246 bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249Imxl ZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+RmFpciBwb2ludC4mbmJzcDsgV2Ug Y2FuIHNheSB0aGF0IHRob3NlIGNsYWltIG5hbWVzIHdvdWxkIGJlIGRlZmluZWQgYnkgYXBwbGlj YXRpb25zIGFuZCBjb3VsZCBiZSByZWdpc3RlcmVkIGluIHRoZSBKV1QgQ2xhaW1zIFJlZ2lzdHJ5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0 IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGln bjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+S2lu ZCBSZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5LZXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0 LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAy MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VGhhbmtzIGFnYWluITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_BY2PR03MB442210DD6E914261F978382F5350BY2PR03MB442namprd_-- From nobody Thu Oct 8 18:04:18 2015 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 E78161B2ECC for ; Thu, 8 Oct 2015 18:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 y7LIm8zzhU1d for ; Thu, 8 Oct 2015 18:04:11 -0700 (PDT) Received: from out4133-66.mail.aliyun.com (out4133-66.mail.aliyun.com [42.120.133.66]) by ietfa.amsl.com (Postfix) with ESMTP id 20EE21B2ACD for ; Thu, 8 Oct 2015 18:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1444352650; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=JSHSiasXT4TEZvjzL5YhV1Hi3hJWFAt6IQisY4qdaIQ=; b=bgn3KY7LmUQGaUeP33AXMynNkIUdXAMWOtFWrfSb2RDzGWmhYIzV7e2QQIkLzANcdlVje6sb77wo9u3YN6oL7RHj+D6CrUZ4nMmqXJQLjxZoA8KTIHNqmZsLAV+E3y+Xh3IMLmwvfRkVOEe/7dQy0nId4gFLgFBSyJm+FOO5WHc= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R201e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03284; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; Received: from 10.1.153.174(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.161) by smtp.aliyun-inc.com(127.0.0.1); Fri, 09 Oct 2015 09:04:05 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Fri, 09 Oct 2015 09:04:00 +0800 From: "Kepeng Li" To: Mike Jones , "oauth@ietf.org" Message-ID: Thread-Topic: Review comments to PoP document References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3527226246_3853144" Archived-At: Subject: Re: [OAUTH-WG] Review comments to PoP document 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, 09 Oct 2015 01:04:17 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3527226246_3853144 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Mike, Thanks for your responses. About the first paragraph in the introduction, I would prefer to make it different from the same one in the abstract. I am fine with others. Kind Regards Kepeng =E5=8F=91=E4=BB=B6=E4=BA=BA: Mike Jones =E6=97=A5=E6=9C=9F: Friday, 9 October, 2015 1:58 am =E8=87=B3: Li Kepeng , "oauth@ietf.org" =E4=B8=BB=E9=A2=98: RE: Review comments to PoP document Thanks for the useful review, Kepeng. Responses inline=E2=80=A6 =20 From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kepeng Li Sent: Wednesday, October 07, 2015 7:30 AM To: oauth@ietf.org Subject: [OAUTH-WG] Review comments to PoP document =20 Hello all, =20 Please find my review comments to PoP document: http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04 =20 1=E3=80=81 Title: Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) [Kepeng] Should we add OAuth 2.0 in the title? Also, in the whole document, we use JWT, but in the title, we use =E2=80=9CJWTs=E2=80=9D. Is there a reason for this= ? =20 I wouldn=E2=80=99t suggest adding =E2=80=9COAuth 2.0=E2=80=9D to the title, in part, because = JWTs are used in contexts outside of OAuth. As for why JWTs is plural here, the title is saying that PoP keys can be communicated in JSON Web Tokens. If i= t were singular, it would sound like you could only use PoP keys in a single JWT, which isn=E2=80=99t right. =20 2=E3=80=81 Abstract=EF=BC=9A 1) This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter. [Kepeng] Add reference to JWT. =20 I=E2=80=99ve been told when editing other drafts to remove references that I=E2=80=99d placed in abstracts, since IETF abstracts don=E2=80=99t include references. =20 2) This property is also sometimes described as the presenter being a holder-of-key. [Kepeng] I am not sure what is =E2=80=9Cthis property=E2=80=9D. Do you mean =E2=80=9Cthe key=E2= =80=9D? If yes, just use the key. And change the sentence to something like: This key is also sometimes described as a holder-of-key by the presenter. =20 I can change =E2=80=9CThis property=E2=80=9D to =E2=80=9CBeing able to prove possession of a = key=E2=80=9D. =20 3. Introduction 1) The first paragraph is the same as the abstract. I suggest to reword it = a little bit or remove it, to avoid the redundancy. =20 The rest of the introduction builds on the ideas introduced in the first tw= o sentences (the content of the abstract). If they were to be removed, it would make the introduction confusing, as many people won=E2=80=99t start by read= ing the abstract, but will read the introduction independently. (The introduction does add references, which cannot be present in the abstract.) I=E2=80=99ll work with the other editors to see if they want to reword the first = two sentences of the introduction and/or abstract to make them different from one another. =20 2) See [I-D.ietf-oauth-pop-architecture] for a further discussion of key confirmation. [Kepeng] I suggest to mention a little bit more about the relationship between PoP architecture document and this document. In my understanding, i= n PoP architecture document, it mentions several mechanisms: confidentiality protection, key confirmation and sender constraint. This document introduce= s the key semantics for the key confirmation mechanism. =20 OK =E2=80=93 we can say that [I-D.ietf-oauth-pop-architecture] describes key confirmation, among other conformation mechanisms, and that this specification defines how to communicate key confirmation key information i= n JWTs. =20 3) About the two use cases, it will be useful to use two diagrams or flows to indicate how it works. Maybe put these two flows in a separate section. Also it will be useful to mention which step is in scope, and which is out of scope, e.g. how to convey symmetric key from the issuer to the presenter= . =20 Both are in scope, which is why they=E2=80=99re both described in the introductio= n. I=E2=80=99ll work with the other editors on trying to create appropriate diagrams= . =20 4. Section 3: 1) It will be useful to put a reference to "sub" (subject) claim, and "iss" (issuer) claim. =20 OK =20 2) Note that if an application needs to represent multiple proof-of- possession keys in the same JWT, one way for it to achieve this is to use other claim names, in addition to "cnf", to hold the additional proof-of-possession key information. [Kepeng] It is not clear, what are the other claim names? =20 Fair point. We can say that those claim names would be defined by applications and could be registered in the JWT Claims Registry. =20 Kind Regards Kepeng =20 Thanks again! -- Mike --B_3527226246_3853144 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hi Mike,

<= div>Thanks for your responses.

About the first para= graph in the introduction, I would prefer to make it different from the same= one in the abstract. 

I am fine with others.<= /div>

Kind Regards
Kepeng

<= span id=3D"OLK_SRC_BODY_SECTION">
=E5=8F=91=E4=BB=B6=E4=BA=BA: Mike Jones <Michael.Jones@microsoft.com>
=E6=97=A5=E6=9C=9F: Friday, 9 October, 2015 1:58 am
<= span style=3D"font-weight:bold">=E8=87=B3: Li Kepeng <kepeng.lkp@alibaba-inc.com>, "oauth@ietf.org" <oa= uth@ietf.org>
=E4=B8=BB=E9=A2=98: RE: R= eview comments to PoP document

Thanks for the useful review, Kepeng.  Responses in= line…

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kepeng Li
Sent: Wednesday, October 07, 2015 7= :30 AM
To: oauth@ietf.org
<= b>Subject: [OAUTH-WG] Review comments to PoP document<= /p>

 

Hello all= ,

 

Please find my review comments to PoP document:

 

1=E3=80=81      &= nbsp;   Title:

Proof-of-Posses= sion Key Semantics for JSON Web Tokens (JWTs)

[Kepeng] Should we add OAuth 2.0 in th= e title? Also, in the whole document, we use JWT, but in the title, we use &= #8220;JWTs”. Is there a reason for this?

 

I wouldn’t su= ggest adding “OAuth 2.0” to the title, in part, because JWTs are= used in contexts outside of OAuth.  As for why JWTs is plural here, th= e title is saying that PoP keys can be communicated in JSON Web Tokens.  If it were singular, it would sound like you cou= ld only use PoP keys in a single JWT, which isn’t right.

 

2=E3=80=81    &nbs= p;     Abstract=EF=BC=9A

1) This specification defines how to express a declaratio= n in a JSON Web Token (JWT) that the presenter of the JWT possesses a partic= ular key and that the recipient can cryptographically confirm proof-of-possession of the key by = the presenter.

[Kepeng] Add= reference to JWT.

 

I’ve been told when editing other drafts= to remove references that I’d placed in abstracts, since IETF abstrac= ts don’t include references.

 

= 2) This property is also sometimes described as th= e presenter being a holder-of-key.

[Kepeng] I am not sure what is “this proper= ty”. Do you mean “the key”? If yes, just use the key. And = change the sentence to something like: This key is also sometimes described = as a holder-of-key by the presenter.

 

I can change “This prop= erty” to “Being able to prove possession of a key”.

 

3. Introduction

1) The first paragraph is the same as the abstract. I suggest to= reword it a little bit or remove it, to avoid the redundancy.

 

T= he rest of the introduction builds on the ideas introduced in the first two = sentences (the content of the abstract). If they were to be removed, it woul= d make the introduction confusing, as many people won’t start by reading the abstract, but will read the i= ntroduction independently.  (The introduction does add references, whic= h cannot be present in the abstract.)  I’ll work with the other e= ditors to see if they want to reword the first two sentences of the introduction and/or abstract to make them different from one anothe= r.

 

2) See= [I-D.ietf-oauth-pop-architecture] for a further discussion of key confirmat= ion.

[Kepeng] I suggest to = mention a little bit more about the relationship between PoP architecture do= cument and this document. In my understanding, in PoP architecture document, it mentions several mechanisms: confidentiality protection, key = confirmation and sender constraint. This document introduces the key semanti= cs for the key confirmation mechanism.

 

OK – we can say that [I-D.ietf-oauth-pop-architecture] desc= ribes key confirmation, among other conformation mechanisms, and that this specification defines how to communicate key confirmation key information = in JWTs.

 

3) About the two us= e cases, it will be useful to use two diagrams or flows to indicate how it w= orks. Maybe put these two flows in a separate section. Also it will be useful to mention which step is in scope, and which is out of s= cope, e.g. how to convey symmetric key from the issuer to the presenter.

 =

Both are in = scope, which is why they’re both described in the introduction.  = I’ll work with the other editors on trying to create appropriate diagrams.

 

4. Section 3:

=

1) It will be useful to put a reference to "sub"= (subject) claim, and "iss" (issuer) claim.

 

OK

 

2) Note= that if an application needs to represent multiple proof-of-

   possession keys in the same = JWT, one way for it to achieve this is to

   use other claim names, in addition to "cnf", to = hold the additional

 &= nbsp; proof-of-possession key information.

[Kepeng] It is not clear, what are the other claim names?

 

Fair point.  We can say= that those claim names would be defined by applications and could be regist= ered in the JWT Claims Registry.

 

Kind Regards

Kepeng

 = ;

  = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;       Thanks again!

<= p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospace:none"= >     =             &nbs= p;            &n= bsp;            =             &nbs= p;    -- Mike

--B_3527226246_3853144-- From nobody Thu Oct 8 18:43:22 2015 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 312B51B302A for ; Thu, 8 Oct 2015 18:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.609 X-Spam-Level: ** X-Spam-Status: No, score=2.609 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 5bbrilbdiwEx for ; Thu, 8 Oct 2015 18:43:18 -0700 (PDT) Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2021B3024 for ; Thu, 8 Oct 2015 18:43:17 -0700 (PDT) Received: from nriea05.index.or.jp (unknown [172.19.246.40]) by nrifs02.index.or.jp (Postfix) with SMTP id 0BE651968A5 for ; Fri, 9 Oct 2015 10:43:17 +0900 (JST) Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea05.index.or.jp (unknown) with ESMTP id t991hGSu013905 for ; Fri, 9 Oct 2015 10:43:16 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t991hGFZ006788; Fri, 9 Oct 2015 10:43:16 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id t991hGcc006787; Fri, 9 Oct 2015 10:43:16 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf12.index.or.jp ([172.100.25.21]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t991hGIk006784 for ; Fri, 9 Oct 2015 10:43:16 +0900 From: "Nat Sakimura" To: "'oauth'" Date: Fri, 9 Oct 2015 10:43:17 +0900 Message-ID: <00c001d10233$debc8720$9c359560$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C1_01D1027F.4EA5B5C0" X-Mailer: Microsoft Outlook 15.0 thread-index: AdECM7x7AzuBoRigTh+o3OQfhMlNVg== Content-Language: ja X-MailAdviser: 20150401 Archived-At: Subject: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request 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, 09 Oct 2015 01:43:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C1_01D1027F.4EA5B5C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi OAuthers: One of the to do for https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05 is to come up with a better title. The current title "OAuth 2.0 JWT Authorization Request (JAR)", is somewhat better than what it used to be, but if you can suggest a better name, I am all for it. Please let me know if you have an idea. Best, -- Nat Sakimura < n-sakimura@nri.co.jp> Nomura Research Institute, Ltd. PLEASE READ: The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system. ------=_NextPart_000_00C1_01D1027F.4EA5B5C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = OAuthers:

 

One of = the to do for https://t= ools.ietf.org/html/draft-ietf-oauth-jwsreq-05 is to come up with a = better title.

The current title “OAuth 2.0 JWT Authorization Request (JAR)”, is somewhat better than = what it used to be, but if you can suggest a better name, I am all for = it.

Please let me know if you have = an idea.

Best,

-- =

Nat Sakimura <n-sakimura@nri.co.jp>

Nomura Research = Institute, Ltd.

 

PLEASE = READ:

The information = contained in this e-mail is confidential and intended for the named = recipient(s) only.

If you are not an = intended recipient of this e-mail, you are hereby notified that any = review, dissemination, distribution or duplication of this message is = strictly prohibited. If you have received this message in error, please = notify the sender immediately and delete your copy from your = system.

 

------=_NextPart_000_00C1_01D1027F.4EA5B5C0-- From nobody Thu Oct 8 18:47:22 2015 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 95B9B1B3044 for ; Thu, 8 Oct 2015 18:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 XVH9Rq3tNOmD for ; Thu, 8 Oct 2015 18:47:19 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227E81B3043 for ; Thu, 8 Oct 2015 18:47:19 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so47869305wic.1 for ; Thu, 08 Oct 2015 18:47:17 -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=53cyH1vWL1xQI+M+jjpTn2YVMxpGO7J3XK2V/CIF8Xk=; b=ZGuCTM41CnJ8WUJiYNKma6LpV2c5pOTutT8RZEV0WtV/k89aINuH/5xlL5LBc2lifx LGtF+PRgSDylSYa7gxzBVd0vLGTqrPAr+rjbFEDulbFx25B70BVwHMVgDEd0Nm3qAw2/ WwM4oY5vviPdbDUcHjFWjkvpWaVb2YNlGEHg+S3SVHc+ZQ89aRRLp37c7HmRVyawMsIb yWmyDlw7hSNkEplUsHAPx6CSP+IWMDp7bZDXggXoF9ZxMl665L0GfUlyUf8RLqbfEoCF 6G0yjvU2HlMwkrWr6aH6wye+/eGw2+szqsKcVgiwRLs7nxeMs7m7tF2O4C9hiq8GXqtP OpnA== X-Gm-Message-State: ALoCoQmRHWfvxqvwgWi3e6lEQ2l5RQt+Pl6fdjozcQbLR7TmpIm4lg465trYDb0E3Gd2tBfTSNMH X-Received: by 10.194.48.102 with SMTP id k6mr12673397wjn.124.1444355237709; Thu, 08 Oct 2015 18:47:17 -0700 (PDT) Received: from [192.168.0.46] (catv-178-48-242-220.catv.broadband.hu. [178.48.242.220]) by smtp.gmail.com with ESMTPSA id p2sm41201301wjb.21.2015.10.08.18.47.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Oct 2015 18:47:16 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-36E8ADC5-6CFD-49DF-AABF-ABAF239C2D0E Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (13A452) In-Reply-To: <00c001d10233$debc8720$9c359560$@nri.co.jp> Date: Fri, 9 Oct 2015 03:47:16 +0200 Content-Transfer-Encoding: 7bit Message-Id: <8BA8D241-67FF-4DD2-AA01-DF007D8916B0@manicode.com> References: <00c001d10233$debc8720$9c359560$@nri.co.jp> To: Nat Sakimura Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request 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, 09 Oct 2015 01:47:21 -0000 --Apple-Mail-36E8ADC5-6CFD-49DF-AABF-ABAF239C2D0E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The word authorization is implied by OAuth, consider "OAuth 2.0 JWT Request"= . -- Jim Manico @Manicode (808) 652-3805 > On Oct 9, 2015, at 3:43 AM, Nat Sakimura wrote: >=20 > Hi OAuthers: > =20 > One of the to do for https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-0= 5 is to come up with a better title. > The current title =E2=80=9COAuth 2.0 JWT Authorization Request (JAR)=E2=80= =9D, is somewhat better than what it used to be, but if you can suggest a be= tter name, I am all for it. >=20 > Please let me know if you have an idea. >=20 > Best, > -- > Nat Sakimura > Nomura Research Institute, Ltd. > =20 > PLEASE READ: > The information contained in this e-mail is confidential and intended for t= he named recipient(s) only. > If you are not an intended recipient of this e-mail, you are hereby notifi= ed that any review, dissemination, distribution or duplication of this messa= ge is strictly prohibited. If you have received this message in error, pleas= e notify the sender immediately and delete your copy from your system. > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-36E8ADC5-6CFD-49DF-AABF-ABAF239C2D0E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The word authorization is implied by O= Auth, consider "OAuth 2.0 JWT Request".

--
Jim Manico<= /div>
@Manicode
(808) 652-3805

On Oct 9, 2= 015, at 3:43 AM, Nat Sakimura <n-= sakimura@nri.co.jp> wrote:

<= style>

Hi OAuthers: <= /o:p>

 

One of the to do for https://tools.ietf.org/html/dr= aft-ietf-oauth-jwsreq-05 is to come up with a better title. <= /span>

The current title =E2=80=9COAu= th 2.0 JWT Authorization Request (JAR)=E2=80=9D, is somewhat better than what it used to be, but i= f you can suggest a better name, I am all for it.

Please let me know if you have an idea.

Best,

--

Nat Sakimura <n-sakimu= ra@nri.co.jp>

Nomura Research Institute, Ltd. <= o:p>

 

PLEASE READ:

The informati= on contained in this e-mail is confidential and intended for the named recip= ient(s) only.

If you are not an intended recipient of this e-m= ail, you are hereby notified that any review, dissemination, distribution or= duplication of this message is strictly prohibited. If you have received th= is message in error, please notify the sender immediately and delete your co= py from your system.

 

_______________________________________________=
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=
= --Apple-Mail-36E8ADC5-6CFD-49DF-AABF-ABAF239C2D0E-- From nobody Thu Oct 8 23:30:54 2015 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 895381B35AD for ; Thu, 8 Oct 2015 23:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 To4MkwsFShfV for ; Thu, 8 Oct 2015 23:30:50 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF65B1B35AC for ; Thu, 8 Oct 2015 23:30:48 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 09 Oct 2015 08:30:46 +0200 X-IronPort-AV: E=Sophos;i="5.17,657,1437429600"; d="scan'208,217";a="339224025" Received: from he113598.emea1.cds.t-internal.com ([10.125.65.117]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 09 Oct 2015 08:30:46 +0200 Received: from HE101454.emea1.cds.t-internal.com ([10.125.92.150]) by HE113598.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 9 Oct 2015 08:30:46 +0200 From: To: , Date: Fri, 9 Oct 2015 08:30:44 +0200 Thread-Topic: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request Thread-Index: AdECM7x7AzuBoRigTh+o3OQfhMlNVgAKChbw Message-ID: <7B1E2B3A05FF2341B03CE0320754230724FFB421D8@HE101454.emea1.cds.t-internal.com> References: <00c001d10233$debc8720$9c359560$@nri.co.jp> In-Reply-To: <00c001d10233$debc8720$9c359560$@nri.co.jp> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_7B1E2B3A05FF2341B03CE0320754230724FFB421D8HE101454emea1_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request 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, 09 Oct 2015 06:30:53 -0000 --_000_7B1E2B3A05FF2341B03CE0320754230724FFB421D8HE101454emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "OAuth 2.0 OpenId-ification" From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura Sent: Freitag, 9. Oktober 2015 03:43 To: 'oauth' Subject: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request Hi OAuthers: One of the to do for https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05= is to come up with a better title. The current title "OAuth 2.0 JWT Authorization Request (JAR)", is somewhat = better than what it used to be, but if you can suggest a better name, I am = all for it. Please let me know if you have an idea. Best, -- Nat Sakimura > Nomura Research Institute, Ltd. PLEASE READ: The information contained in this e-mail is confidential and intended for t= he named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby notifie= d that any review, dissemination, distribution or duplication of this messa= ge is strictly prohibited. If you have received this message in error, plea= se notify the sender immediately and delete your copy from your system. --_000_7B1E2B3A05FF2341B03CE0320754230724FFB421D8HE101454emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&#= 8222;OAuth 2.0 OpenId-ification“

 

From:<= /b> OAut= h [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Se= nt: Freitag, 9. Oktober 2015 03:43
To: 'oauth'
Subject:= [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request

 

Hi OAuthers:

<= o:p> 

One of the to do for https://tools.ietf.org/html/draf= t-ietf-oauth-jwsreq-05 is to come up with a better title.

The current title “OAuth 2.0 JWT Authorization Request (JAR)”= ;, is somew= hat better than what it used to be, but if you can suggest a better name, I= am all for it.

Please let me kn= ow if you have an idea.

<= p class=3DMsoNormal>Best,

--

Nat Sakimura <n-sakimura@nri.co.jp>

Nomura Research= Institute, Ltd.

 

PLEASE READ:

The= information contained in this e-mail is confidential and intended for the = named recipient(s) only.

If you are not an intended recipient of= this e-mail, you are hereby notified that any review, dissemination, distr= ibution or duplication of this message is strictly prohibited. If you have = received this message in error, please notify the sender immediately and de= lete your copy from your system.

=  

<= /body>= --_000_7B1E2B3A05FF2341B03CE0320754230724FFB421D8HE101454emea1_-- From nobody Fri Oct 9 00:19:56 2015 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 01D3F1A6F12 for ; Fri, 9 Oct 2015 00:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 9o4FN3Wq3Xcm for ; Fri, 9 Oct 2015 00:19:53 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F3A1A6F10 for ; Fri, 9 Oct 2015 00:19:52 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 09 Oct 2015 09:18:46 +0200 X-IronPort-AV: E=Sophos;i="5.17,657,1437429600"; d="scan'208,217";a="754290646" Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 09 Oct 2015 09:15:24 +0200 Received: from HE101454.emea1.cds.t-internal.com ([10.125.92.150]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%14]) with mapi; Fri, 9 Oct 2015 09:15:24 +0200 From: To: , Date: Fri, 9 Oct 2015 09:15:23 +0200 Thread-Topic: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request Thread-Index: AdECNHXEkBX0n3Y7QQWydRj9jtYlaAAK/cBw Message-ID: <7B1E2B3A05FF2341B03CE0320754230724FFB42209@HE101454.emea1.cds.t-internal.com> References: <00c001d10233$debc8720$9c359560$@nri.co.jp> <8BA8D241-67FF-4DD2-AA01-DF007D8916B0@manicode.com> In-Reply-To: <8BA8D241-67FF-4DD2-AA01-DF007D8916B0@manicode.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_7B1E2B3A05FF2341B03CE0320754230724FFB42209HE101454emea1_" MIME-Version: 1.0 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request 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, 09 Oct 2015 07:19:56 -0000 --_000_7B1E2B3A05FF2341B03CE0320754230724FFB42209HE101454emea1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi00LjEuMSBBdXRob3Jp emF0aW9uIFJlcXVlc3QgaXMgZXhwbGljaXQgdG9vLg0KDQpOYW1pbmcgY291bGQgYmUgYWJvdXQg dGhlIHdoeSBvciB0aGUgd2hhdC4gSkFSIGlzIGluIHRoZSB3aGF0LWlzLWlzIGNhdGVnb3J5Lg0K 4oCcU2lnbmVkIGFuZCBFbmNyeXB0ZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN04oCdIHdvdWxkIGJl IG1vcmUgaW4gdGhlIHdoeSBjYXRlZ29yeS4NCg0KSSB0aGluayBKQVIgaXMgbm90IGJhZC4NCg0K LUENCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSmltIE1hbmljbw0KU2VudDogRnJlaXRhZywgOS4gT2t0b2JlciAyMDE1IDAzOjQ3DQpU bzogTmF0IFNha2ltdXJhDQpDYzogb2F1dGgNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEJldHRl ciB0aXRsZSBmb3IgT0F1dGggMi4wIEpXVCBBdXRob3JpemF0aW9uIFJlcXVlc3QNCg0KVGhlIHdv cmQgYXV0aG9yaXphdGlvbiBpcyBpbXBsaWVkIGJ5IE9BdXRoLCBjb25zaWRlciAiT0F1dGggMi4w IEpXVCBSZXF1ZXN0Ii4NCi0tDQpKaW0gTWFuaWNvDQpATWFuaWNvZGUNCig4MDgpIDY1Mi0zODA1 DQoNCk9uIE9jdCA5LCAyMDE1LCBhdCAzOjQzIEFNLCBOYXQgU2FraW11cmEgPG4tc2FraW11cmFA bnJpLmNvLmpwPG1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcD4+IHdyb3RlOg0KSGkgT0F1dGhl cnM6DQoNCk9uZSBvZiB0aGUgdG8gZG8gZm9yIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0wNSBpcyB0byBjb21lIHVwIHdpdGggYSBiZXR0ZXIgdGl0 bGUuDQpUaGUgY3VycmVudCB0aXRsZSDigJxPQXV0aCAyLjAgSldUIEF1dGhvcml6YXRpb24gUmVx dWVzdCAoSkFSKeKAnSwgaXMgc29tZXdoYXQgYmV0dGVyIHRoYW4gd2hhdCBpdCB1c2VkIHRvIGJl LCBidXQgaWYgeW91IGNhbiBzdWdnZXN0IGEgYmV0dGVyIG5hbWUsIEkgYW0gYWxsIGZvciBpdC4N ClBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbiBpZGVhLg0KQmVzdCwNCi0tDQpOYXQg U2FraW11cmEgPG4tc2FraW11cmFAbnJpLmNvLmpwPG1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5q cD4+DQpOb211cmEgUmVzZWFyY2ggSW5zdGl0dXRlLCBMdGQuDQoNClBMRUFTRSBSRUFEOg0KVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBpcyBjb25maWRlbnRpYWwgYW5k IGludGVuZGVkIGZvciB0aGUgbmFtZWQgcmVjaXBpZW50KHMpIG9ubHkuDQpJZiB5b3UgYXJlIG5v dCBhbiBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBlLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IHJldmlldywgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGR1 cGxpY2F0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIHlvdXIgY29weSBmcm9tIHlvdXIgc3lzdGVtLg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_7B1E2B3A05FF2341B03CE0320754230724FFB42209HE101454emea1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7 DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgUEdvdGhp YyI7DQoJcGFub3NlLTE6MiAxMSA2IDAgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBQR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4IDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJ Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0KaDENCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSBDaGFyIjsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MjQuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJNUyBQR290aGljIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uSGVhZGluZzFDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5n IDEgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRp bmcgMSI7DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzM2NUY5MTsN Cglmb250LXdlaWdodDpib2xkO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KcC4xLCBsaS4xLCBkaXYuMQ0KCXttc28tc3R5bGUtbmFtZToi6KaL5Ye644GX IDEiOw0KCW1zby1zdHlsZS1saW5rOiLopovlh7rjgZcgMSBcKOaWh+Wtl1wpIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJZm9u dC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LjEwDQoJe21zby1zdHlsZS1uYW1lOiLopovlh7rjgZcgMSBcKOaWh+Wtl1wpIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoi6KaL5Ye644GXIDEiOw0KCWZvbnQtZmFt aWx5OiJNUyBQR290aGljIiwic2Fucy1zZXJpZiI7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpzcGFu LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjk5 LjI1cHQgMy4wY20gMy4wY20gMy4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbCBhbGln bj1sZWZ0IHN0eWxlPSd0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj Njc0OSNzZWN0aW9uLTQuMS4xIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNz ZWN0aW9uLTQuMS4xPC9hPiBBdXRob3JpemF0aW9uIFJlcXVlc3QgaXMgZXhwbGljaXQgdG9vLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249bGVmdCBzdHlsZT0n dGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1s ZWZ0IHN0eWxlPSd0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5OYW1pbmcgY291bGQgYmUgYWJvdXQgdGhlIHdoeSBvciB0aGUgd2hhdC4g SkFSIGlzIGluIHRoZSB3aGF0LWlzLWlzIGNhdGVnb3J5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249bGVmdCBzdHlsZT0ndGV4dC1hbGlnbjpsZWZ0O3RleHQt YXV0b3NwYWNlOm5vbmUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+4oCcU2lnbmVkIGFuZCBFbmNy eXB0ZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN04oCdIHdvdWxkIGJlIG1vcmUgaW4gdGhlIHdoeSBj YXRlZ29yeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWxl ZnQgc3R5bGU9J3RleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgYWxpZ249bGVmdCBzdHlsZT0ndGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSB0aGluayBKQVIgaXMgbm90IGJhZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWxlZnQgc3R5bGU9J3RleHQtYWxp Z246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249bGVmdCBzdHls ZT0ndGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+LUE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1sZWZ0IHN0eWxlPSd0ZXh0 LWFsaWduOmxlZnQnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE9BdXRoIFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5KaW0gTWFu aWNvPGJyPjxiPlNlbnQ6PC9iPiBGcmVpdGFnLCA5LiBPa3RvYmVyIDIwMTUgMDM6NDc8YnI+PGI+ VG86PC9iPiBOYXQgU2FraW11cmE8YnI+PGI+Q2M6PC9iPiBvYXV0aDxicj48Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtPQVVUSC1XR10gQmV0dGVyIHRpdGxlIGZvciBPQXV0aCAyLjAgSldUIEF1dGhvcml6 YXRpb24gUmVxdWVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWwgYWxpZ249bGVmdCBzdHlsZT0ndGV4dC1hbGlnbjpsZWZ0Jz48bzpwPiZuYnNwOzwv bzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4w cHQnPlRoZSB3b3JkIGF1dGhvcml6YXRpb24gaXMgaW1wbGllZCBieSBPQXV0aCwgY29uc2lkZXIg JnF1b3Q7T0F1dGggMi4wIEpXVCBSZXF1ZXN0JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPi0tPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+SmltIE1hbmljbzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPkBNYW5pY29kZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs Pig4MDgpIDY1Mi0zODA1PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+T24gT2N0IDksIDIwMTUs IGF0IDM6NDMgQU0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm4tc2FraW11cmFA bnJpLmNvLmpwIj5uLXNha2ltdXJhQG5yaS5jby5qcDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Jz5IaSBPQXV0aGVyczogPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ T25lIG9mIHRoZSB0byBkbyBmb3IgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTA1Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMDU8L2E+IGlzIHRvIGNvbWUgdXAgd2l0aCBhIGJldHRl ciB0aXRsZS4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxoMSBzdHlsZT0nbXNvLWxpbmUtaGVpZ2h0 LWFsdDowcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5UaGUgY3VycmVudCB0aXRs ZSDigJw8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+T0F1dGggMi4wIEpXVCBBdXRob3JpemF0aW9uIFJlcXVl c3QgKEpBUik8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPuKAnSwgaXMgc29t ZXdoYXQgYmV0dGVyIHRoYW4gd2hhdCBpdCB1c2VkIHRvIGJlLCBidXQgaWYgeW91IGNhbiBzdWdn ZXN0IGEgYmV0dGVyIG5hbWUsIEkgYW0gYWxsIGZvciBpdC4gPC9zcGFuPjxvOnA+PC9vOnA+PC9o MT48aDEgc3R5bGU9J21zby1saW5lLWhlaWdodC1hbHQ6MHB0Jz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+UGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGFuIGlkZWEuIDwvc3Bh bj48bzpwPjwvbzpwPjwvaDE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Jz5CZXN0LCA8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IGFsaWduPWxlZnQgc3R5bGU9J3RleHQtYWxpZ246bGVmdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPi0tIDwvc3Bhbj48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249bGVmdCBzdHlsZT0ndGV4dC1hbGlnbjpsZWZ0Jz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiTVMgR290aGljIic+TmF0 IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanAiPm4tc2Fr aW11cmFAbnJpLmNvLmpwPC9hPiZndDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIGFsaWduPWxlZnQgc3R5bGU9J3RleHQtYWxpZ246bGVmdCc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPk5vbXVyYSBSZXNlYXJjaCBJ bnN0aXR1dGUsIEx0ZC4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBh bGlnbj1sZWZ0IHN0eWxlPSd0ZXh0LWFsaWduOmxlZnQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWxlZnQgc3R5bGU9J3RleHQtYWxpZ246bGVmdCc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiTVMgR290aGljIic+UExF QVNFIFJFQUQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1s ZWZ0IHN0eWxlPSd0ZXh0LWFsaWduOmxlZnQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPlRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBlLW1haWwgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIG5hbWVkIHJlY2lw aWVudChzKSBvbmx5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgYWxp Z249bGVmdCBzdHlsZT0ndGV4dC1hbGlnbjpsZWZ0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz5JZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCBy ZWNpcGllbnQgb2YgdGhpcyBlLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 IHJldmlldywgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGR1cGxpY2F0aW9uIG9mIHRo aXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZGVsZXRlIHlvdXIgY29weSBmcm9tIHlvdXIgc3lzdGVtLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWxlZnQgc3R5bGU9J3RleHQtYWxp Z246bGVmdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIic+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+T0F1dGggbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2tx dW90ZT48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_7B1E2B3A05FF2341B03CE0320754230724FFB42209HE101454emea1_-- From nobody Fri Oct 9 00:27:44 2015 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 C1DB01A6F1F for ; Fri, 9 Oct 2015 00:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 rKDcKt8PEu93 for ; Fri, 9 Oct 2015 00:27:41 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F158D1A6F52 for ; Fri, 9 Oct 2015 00:27:40 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 09 Oct 2015 09:27:39 +0200 X-IronPort-AV: E=Sophos;i="5.17,657,1437429600"; d="scan'208";a="754302409" Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 09 Oct 2015 09:27:15 +0200 Received: from HE101454.emea1.cds.t-internal.com ([10.125.92.150]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%14]) with mapi; Fri, 9 Oct 2015 09:27:13 +0200 From: To: Date: Fri, 9 Oct 2015 09:27:13 +0200 Thread-Topic: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05 Thread-Index: AdECY+q3WS2umIO5S+aowqzzg/qAJQ== Message-ID: <7B1E2B3A05FF2341B03CE0320754230724FFB42215@HE101454.emea1.cds.t-internal.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05 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, 09 Oct 2015 07:27:42 -0000 TmF0LA0KDQpDb3VsZCB5b3UgcGxlYXNlIGFkZCByZWFzb25zIG9uIHdoeSB0aGUgNTEyIGluIHRo aXMgc2VudGVuY2UNCgkiVGhlIGVudGlyZSBSZXF1ZXN0IFVSSSBNVVNUIE5PVCBleGNlZWQgNTEy IEFTQ0lJIGNoYXJhY3RlcnMiPw0KSXQgaXMgaW4gdGhpcyBzZWN0aW9uIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0wNSNzZWN0aW9uLTQuMiANCg0K SSBhc3N1bWUgaXQgaXMgaGFyZCB0byBqdXN0aWZ5IGV4YWN0bHkgdGhpcyBudW1iZXIgYW5kIGdp dmVuIHRoYXQsIEkgdGhpbmsgdGhpcyByZXN0cmljdGlvbiBzaG91bGQgYmUgcmVtb3ZlZC4NCg0K S2luZCByZWdhcmRzDQotQXhlbA0K From nobody Fri Oct 9 08:19:25 2015 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 600781B43BD for ; Fri, 9 Oct 2015 08:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 T-dODZ6x0DrP for ; Fri, 9 Oct 2015 08:19:23 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2821C1B4360 for ; Fri, 9 Oct 2015 08:19:22 -0700 (PDT) Received: by oigi138 with SMTP id i138so23548825oig.2 for ; Fri, 09 Oct 2015 08:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pAQ/Ggg09Tfb/96hkZC0ktfRss9ivWAElk78NQGCGnI=; b=Gp1NI+a09sqkK9RLwJaFXQF9Tkrb1LMPoO07vwazB/zx6I7irNHiF4djoZV0kbxCIf CcczDJEdLbmsJ2FGM2luETgOuctN5blD4gAofyzWrHjwd6GF/kqx6ut2LLLAlhg2EiVy Ej8SFyiT665pJk9rdYpWG4zC5awIveQ291mKfR2KVRA4UMGYKWC0FR8KvWVbVjdkpg6o pxLu/rl7aqnaAol71pxQsri8xpkJBPu0sSeP3pOVD2wrwRqEFlcwB9f3XMakrt+2WD9Q rlQicniT8Gzp02pJM2c1N/ROVAojm3At+Wzmqk6rzbqBgfwTkstscfaGkiA5HwVWO3ah r0qQ== MIME-Version: 1.0 X-Received: by 10.202.64.68 with SMTP id n65mr8052416oia.53.1444403962180; Fri, 09 Oct 2015 08:19:22 -0700 (PDT) Sender: sakimura@gmail.com Received: by 10.182.236.196 with HTTP; Fri, 9 Oct 2015 08:19:21 -0700 (PDT) In-Reply-To: <7B1E2B3A05FF2341B03CE0320754230724FFB42215@HE101454.emea1.cds.t-internal.com> References: <7B1E2B3A05FF2341B03CE0320754230724FFB42215@HE101454.emea1.cds.t-internal.com> Date: Sat, 10 Oct 2015 00:19:21 +0900 X-Google-Sender-Auth: MV_bmgIclRrdmXzk-tk6luqe2XU Message-ID: From: Nat Sakimura To: "Axel.Nennker@telekom.de" Content-Type: multipart/alternative; boundary=001a113dd1b413ff380521ad81e6 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05 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, 09 Oct 2015 15:19:24 -0000 --001a113dd1b413ff380521ad81e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Actually, I believe that came from the restrictions on some of the wap browsers. Now they are practically gone, it should be ok to remove the restriction. Remember that the draft actually started back in 2007 :-) 2015=E5=B9=B410=E6=9C=889=E6=97=A5=E9=87=91=E6=9B=9C=E6=97=A5=E3=80=81=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE= =E3=81=97=E3=81=9F: > Nat, > > Could you please add reasons on why the 512 in this sentence > "The entire Request URI MUST NOT exceed 512 ASCII characters"? > It is in this section > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05#section-4.2 > > I assume it is hard to justify exactly this number and given that, I thin= k > this restriction should be removed. > > Kind regards > -Axel > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --001a113dd1b413ff380521ad81e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Actually, I believe that came from the restrictions on some of the wap brow= sers. Now they are practically gone, it should be ok to remove the restrict= ion. Remember that the draft actually started back in 2007 :-)=

2015=E5=B9=B410=E6=9C=889=E6=97=A5=E9=87=91=E6=9B=9C=E6=97=A5=E3=80= =81<Axel.Nennker@telekom.de>=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=97=E3=81= =9F:
Nat,

Could you please add reasons on why the 512 in this sentence
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "The entire Request URI MUST NOT exceed 51= 2 ASCII characters"?
It is in this section https://tools.ietf.org/html/dra= ft-ietf-oauth-jwsreq-05#section-4.2

I assume it is hard to justify exactly this number and given that, I think = this restriction should be removed.

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


--
Nat Sakimura (=3Dnat)
http://www.sakimura.org/en/
http://twitter.com/_na= t_en
--001a113dd1b413ff380521ad81e6-- From nobody Fri Oct 9 08:23:32 2015 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 48B141A8A81 for ; Fri, 9 Oct 2015 08:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 15jmG1u61OB1 for ; Fri, 9 Oct 2015 08:23:30 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C211B1A8A3B for ; Fri, 9 Oct 2015 08:23:29 -0700 (PDT) Received: by obbbh8 with SMTP id bh8so64995619obb.0 for ; Fri, 09 Oct 2015 08:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=N017aDCZ17KWFoioNAEVsVjHryfYs4D1uz6fCLJcShc=; b=k2y9E9DrY0A78kD35ZC2jLpbudHwV+6Ae8tu4N/oiG+9h5tGoY9qP+9QTP2x3rNPAC UkinhxMxzswKjWGx8T1y1XQ0Vz0avYAGI37hVlVqu5ml+R5SfYuy67hbDc9up7WPBUjf BJKHA6ePsi18P1CXzXAtopQT7PqTXaF1yrbV0xKm0YBmjs1PJ6gJ/xAj3S0LaCgeEQeO jUdJpXcZx+qSVRGtDFN4LNqIUlpD6fNqBqrCPul1+RXCFSIzooIvmeojPpj2FD6WvoHi 4RFLA9/aXCfV6t45oQ7qQn8FXG9iJbgNznRQRSMGc0WKH4QKOhh9j943NGBcQ9pNRFMJ Z1lQ== MIME-Version: 1.0 X-Received: by 10.60.125.131 with SMTP id mq3mr8261613oeb.8.1444404209225; Fri, 09 Oct 2015 08:23:29 -0700 (PDT) Sender: sakimura@gmail.com Received: by 10.182.236.196 with HTTP; Fri, 9 Oct 2015 08:23:29 -0700 (PDT) In-Reply-To: <8BA8D241-67FF-4DD2-AA01-DF007D8916B0@manicode.com> References: <00c001d10233$debc8720$9c359560$@nri.co.jp> <8BA8D241-67FF-4DD2-AA01-DF007D8916B0@manicode.com> Date: Sat, 10 Oct 2015 00:23:29 +0900 X-Google-Sender-Auth: 4sLJ4KLH-rQlYaYvqA-gtkDTrh8 Message-ID: From: Nat Sakimura To: Jim Manico Content-Type: multipart/alternative; boundary=047d7b33c6a6cda0e20521ad8f8a Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request 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, 09 Oct 2015 15:23:31 -0000 --047d7b33c6a6cda0e20521ad8f8a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The reason for saying authorization request is that there are two types of requests in RFC6749; authorization request and token request. This draft deals with the former and thus named JAR. Nat 2015=E5=B9=B410=E6=9C=889=E6=97=A5=E9=87=91=E6=9B=9C=E6=97=A5=E3=80=81Jim M= anico=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81= =BE=E3=81=97=E3=81=9F: > The word authorization is implied by OAuth, consider "OAuth 2.0 JWT > Request". > > -- > Jim Manico > @Manicode > (808) 652-3805 > > On Oct 9, 2015, at 3:43 AM, Nat Sakimura > wrote: > > Hi OAuthers: > > > > One of the to do for > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05 is to come up with > a better title. > The current title =E2=80=9COAuth 2.0 JWT Authorization Request (JAR)=E2= =80=9D, is > somewhat better than what it used to be, but if you can suggest a better > name, I am all for it. Please let me know if you have an idea. > > Best, > > -- > > Nat Sakimura > > > Nomura Research Institute, Ltd. > > > > PLEASE READ: > > The information contained in this e-mail is confidential and intended for > the named recipient(s) only. > > If you are not an intended recipient of this e-mail, you are hereby > notified that any review, dissemination, distribution or duplication of > this message is strictly prohibited. If you have received this message in > error, please notify the sender immediately and delete your copy from you= r > system. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --047d7b33c6a6cda0e20521ad8f8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The reason for saying authorization request is that there are two types of = requests in RFC6749; authorization request and token request. This draft de= als with the former and thus named=C2=A0JAR. =C2=A0

Nat<= span>

2015=E5=B9=B410=E6=9C=889=E6=97=A5=E9=87=91=E6=9B= =9C=E6=97=A5=E3=80=81Jim Manico<jim@= manicode.com>=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE= =E3=81=97=E3=81=9F:
The word authorization is implied by OAuth, consider "OAuth 2.0 JWT = Request".

--
Jim Manico
@Manicode
(808) 652-3805

On Oct 9, 2015, at 3:43 AM, Nat Sa= kimura <n-sakimura@nri.co.jp> wrote:
<= br>

Hi OAuthers: =

= =C2=A0

One of the to do for https://tools.iet= f.org/html/draft-ietf-oauth-jwsreq-05 is to come up with a better title= .

The current title =E2=80=9COAuth 2.0 JWT Au= thorization Request (JAR)=E2=80=9D, is somewhat better than what it used to be, but if you can = suggest a better name, I am all for it.

Please let me know if you have a= n idea.

Best, <= /u>

--

Nat Sakimura <= n-sakimura@nri.co.jp>=

Nomura Research Institute, Ltd.

=C2= =A0

PLEASE READ:

The information contained i= n this e-mail is confidential and intended for the named recipient(s) only.=

If you are not an intended recipient of this e-mail, yo= u are hereby notified that any review, dissemination, distribution or dupli= cation of this message is strictly prohibited. If you have received this me= ssage in error, please notify the sender immediately and delete your copy f= rom your system.

=C2=A0

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


-- <= br>Nat Sakimura (=3Dnat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
--047d7b33c6a6cda0e20521ad8f8a-- From nobody Fri Oct 9 08:28:20 2015 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 C6B051B43C1 for ; Fri, 9 Oct 2015 08:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 cXy5bLzlfY5P for ; Fri, 9 Oct 2015 08:28:17 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB791A8821 for ; Fri, 9 Oct 2015 08:28:16 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so72202006wic.1 for ; Fri, 09 Oct 2015 08:28:15 -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=frocPjhj1Sin6MiQcwlt/CUl71n9TMGs6ndd5bv6KfI=; b=DZJoIJMBzxUe63IplFAfGX1/5IObelVgiuM7a696qnnfuUTAAUjBu6SJMc91MDg3/d QOz3m02ao6SUFwRnBY1XK+wjHNh6xkx6CMDEsPoD69q0B7MB6r/BL8FOZP3khUONh4VH Nc1Wz98au/QmXj8FGGYdMqFrMJtd+Qd91BKhijJzYKV1v/147Q9k8TyubEfBxiCqKiL1 X6N5KvMKCyzPGSg9K+z3j6Eh81woNhHQHhETSTRa1ebamt/idC3V3iQKEGpbHy5JuPJe 2sKHtBMBpfnL8+/77OHOY4ghU2Fnq+XQoGlHntytgPDc9fW/FGDX1aosprCafIKQC1yh GpMQ== X-Gm-Message-State: ALoCoQnRvcXyq6KTwPmQMMf0NWMfASOAL9neL2IDdnBo/8w4lcwq70n0gbPUa5p3PD5yMep2a00n X-Received: by 10.180.103.2 with SMTP id fs2mr11746200wib.9.1444404495144; Fri, 09 Oct 2015 08:28:15 -0700 (PDT) Received: from [192.168.0.46] (catv-178-48-242-220.catv.broadband.hu. [178.48.242.220]) by smtp.gmail.com with ESMTPSA id ht5sm3183071wib.10.2015.10.09.08.28.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Oct 2015 08:28:13 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E344AB47-FF78-4AD6-93E5-2C31FF56F61C Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (13A452) In-Reply-To: Date: Fri, 9 Oct 2015 17:28:12 +0200 Content-Transfer-Encoding: 7bit Message-Id: <190D3129-645A-4267-A3FC-215AFE71DE38@manicode.com> References: <00c001d10233$debc8720$9c359560$@nri.co.jp> <8BA8D241-67FF-4DD2-AA01-DF007D8916B0@manicode.com> To: Nat Sakimura Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request 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, 09 Oct 2015 15:28:18 -0000 --Apple-Mail-E344AB47-FF78-4AD6-93E5-2C31FF56F61C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable But its all authorization, even the token request.... -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On Oct 9, 2015, at 5:23 PM, Nat Sakimura wrote: >=20 > The reason for saying authorization request is that there are two types of= requests in RFC6749; authorization request and token request. This draft de= als with the former and thus named JAR. =20 >=20 > Nat >=20 > 2015=E5=B9=B410=E6=9C=889=E6=97=A5=E9=87=91=E6=9B=9C=E6=97=A5=E3=80=81Jim M= anico=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE= =E3=81=97=E3=81=9F: >> The word authorization is implied by OAuth, consider "OAuth 2.0 JWT Reque= st". >>=20 >> -- >> Jim Manico >> @Manicode >> (808) 652-3805 >>=20 >>> On Oct 9, 2015, at 3:43 AM, Nat Sakimura wrote: >>>=20 >>> Hi OAuthers: >>>=20 >>> =20 >>>=20 >>> One of the to do for https://tools.ietf.org/html/draft-ietf-oauth-jwsreq= -05 is to come up with a better title. >>>=20 >>> The current title =E2=80=9COAuth 2.0 JWT Authorization Request (JAR)=E2=80= =9D, is somewhat better than what it used to be, but if you can suggest a be= tter name, I am all for it.=20 >>>=20 >>> Please let me know if you have an idea. >>>=20 >>> Best, >>>=20 >>> -- >>>=20 >>> Nat Sakimura >>>=20 >>> Nomura Research Institute, Ltd. >>>=20 >>> =20 >>>=20 >>> PLEASE READ: >>>=20 >>> The information contained in this e-mail is confidential and intended fo= r the named recipient(s) only. >>>=20 >>> If you are not an intended recipient of this e-mail, you are hereby noti= fied that any review, dissemination, distribution or duplication of this mes= sage is strictly prohibited. If you have received this message in error, ple= ase notify the sender immediately and delete your copy from your system. >>>=20 >>> =20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en --Apple-Mail-E344AB47-FF78-4AD6-93E5-2C31FF56F61C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
But its all authorization, even the to= ken request....

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
On Oct 9, 2015, at 5:23 PM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:

The reason for saying authorization request is that there are= two types of requests in RFC6749; authorization request and token request. T= his draft deals with the former and thus named JAR.  

Nat

2015=E5=B9=B410=E6=9C=889=E6=97=A5=E9=87= =91=E6=9B=9C=E6=97=A5=E3=80=81Jim Manico<jim@manicode.com>=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3= =81=BE=E3=81=97=E3=81=9F:
The word authorization is implied by OAuth, consider "OAuth 2.0 JWT Re= quest".

--
Jim Manico
@Manicode
(8= 08) 652-3805

On Oct 9, 2015, at 3:43 AM, Nat Sakimura &l= t;n-sakimura@nri.co.jp> wrote:

Hi OAuthers:

 

=

One o= f the to do for https://tools.ietf.org/html/draft-ietf-oauth-jwsreq= -05 is to come up with a better title.

The current title =E2=80=9COAuth 2.0 JWT Authorization Request (JAR)=E2=80=9D, is somewhat better than w= hat it used to be, but if you can suggest a better name, I am all for it.

= Please let me know if you have an idea.

Best,

--

Nat Sakimura <= n-sakimura@nri.co.jp><= /u>

Nomura Research Institute, Ltd.

&nb= sp;

PLEASE READ:

The information contained in this= e-mail is confidential and intended for the named recipient(s) only.=

If you are not an intended recipient of this e-mail, you are here= by notified that any review, dissemination, distribution or duplication of t= his message is strictly prohibited. If you have received this message in err= or, please notify the sender immediately and delete your copy from your syst= em.

<= /u> 

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


--
Nat Sakimura (=3Dnat)
http://www.sakimura.org/en/<= /a>
http://twitt= er.com/_nat_en
= --Apple-Mail-E344AB47-FF78-4AD6-93E5-2C31FF56F61C-- From nobody Fri Oct 9 08:39:25 2015 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 3ECFE1A8AC0 for ; Fri, 9 Oct 2015 08:39:24 -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 aTqV9TPMauAR for ; Fri, 9 Oct 2015 08:39:22 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6201A9060 for ; Fri, 9 Oct 2015 08:39:21 -0700 (PDT) Received: by qgez77 with SMTP id z77so72070908qge.1 for ; Fri, 09 Oct 2015 08:39:20 -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=/R+4cf94kJJe40OwRwNFiB4sR6Rb+MRuu6JUn2JG91I=; b=c//X9K8kbalgM1XogS+f1XEPhhmW+S812V8gnFtEIueIHj8N1ugJT8Y25PN7P4LLTy ibCYCLowwf7TFevvJOFlNsx0d4kRWo0I4XLR4cRcVn6cmxmbA+TbmjGVgaJ3f/215/lZ ReJ3998q6p+ZM5n3pJQ1xH8sIZsH7QdZv27N3KcJzXVQOlNJh5mnBB4t7nfXnxZwHIrB WLNNUCnNbJm/D0m9QRq44D/9EJR3silcbhlsQakBalHZcSYF0q/ToErmlpwu09Uz5MzY wULdkCEvOehkRzmEbN8wicaDdpdMoyHy1ALvXDajL8t7/z2SJ5sM/89pcfyNdNUWmY9D MObg== X-Gm-Message-State: ALoCoQmsW5SbuOLgi6CpnajWcs7FAEI/f9vcAFdKRg02NXLWcu/yAk1QsrBx09ARTss3Si6cLYFc X-Received: by 10.140.233.213 with SMTP id e204mr17298856qhc.43.1444405160735; Fri, 09 Oct 2015 08:39:20 -0700 (PDT) Received: from [192.168.8.101] ([181.202.138.57]) by smtp.gmail.com with ESMTPSA id 206sm851804qhq.39.2015.10.09.08.39.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Oct 2015 08:39:19 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_7D11C4E3-4EEB-407D-9675-3D63025ECBB4"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Fri, 9 Oct 2015 12:39:15 -0300 Message-Id: References: <00c001d10233$debc8720$9c359560$@nri.co.jp> <8BA8D241-67FF-4DD2-AA01-DF007D8916B0@manicode.com> To: Nat Sakimura X-Mailer: Apple Mail (2.2104) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request 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, 09 Oct 2015 15:39:24 -0000 --Apple-Mail=_7D11C4E3-4EEB-407D-9675-3D63025ECBB4 Content-Type: multipart/alternative; boundary="Apple-Mail=_DC7B38A1-BE56-496A-9CB0-69E8D4A17577" --Apple-Mail=_DC7B38A1-BE56-496A-9CB0-69E8D4A17577 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We could switch the order to say =E2=80=9CJWT request to the = Authorization Endpoint=E2=80=9D, but that is a bit long. John B. > On Oct 9, 2015, at 12:23 PM, Nat Sakimura = wrote: >=20 > The reason for saying authorization request is that there are two = types of requests in RFC6749; authorization request and token request. = This draft deals with the former and thus named JAR. =20 >=20 > Nat >=20 > 2015=E5=B9=B410=E6=9C=889=E6=97=A5=E9=87=91=E6=9B=9C=E6=97=A5=E3=80=81Ji= m Manico>=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3= =81=BE=E3=81=97=E3=81=9F: > The word authorization is implied by OAuth, consider "OAuth 2.0 JWT = Request". >=20 > -- > Jim Manico > @Manicode > (808) 652-3805 >=20 > On Oct 9, 2015, at 3:43 AM, Nat Sakimura > wrote: >=20 >> Hi OAuthers: >>=20 >> =20 >>=20 >> One of the to do for = https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05 = is to come up = with a better title. >>=20 >> The current title =E2=80=9COAuth 2.0 JWT Authorization Request = (JAR)=E2=80=9D, is somewhat better than what it used to be, but if you = can suggest a better name, I am all for it. >>=20 >> Please let me know if you have an idea. >>=20 >> Best, >>=20 >> -- >>=20 >> Nat Sakimura > >>=20 >> Nomura Research Institute, Ltd. >>=20 >> =20 >>=20 >> PLEASE READ: >>=20 >> The information contained in this e-mail is confidential and intended = for the named recipient(s) only. >>=20 >> If you are not an intended recipient of this e-mail, you are hereby = notified that any review, dissemination, distribution or duplication of = this message is strictly prohibited. If you have received this message = in error, please notify the sender immediately and delete your copy from = your system. >>=20 >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_DC7B38A1-BE56-496A-9CB0-69E8D4A17577 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We could switch the order to say =E2=80=9CJWT request to the = Authorization Endpoint=E2=80=9D, but that is a bit long.

John B.


On Oct 9, 2015, at 12:23 PM, = Nat Sakimura <n-sakimura@nri.co.jp> wrote:

The reason for = saying authorization request is that there are two types of requests in = RFC6749; authorization request and token request. This draft deals with = the former and thus named JAR.  

Nat

2015=E5=B9=B410=E6=9C=889=E6=97=A5= =E9=87=91=E6=9B=9C=E6=97=A5=E3=80=81Jim Manico<jim@manicode.com>=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3= =81=8D=E3=81=BE=E3=81=97=E3=81=9F:
The = word authorization is implied by OAuth, consider "OAuth 2.0 JWT = Request".

--
Jim Manico
@Manicode
(808) 652-3805

On = Oct 9, 2015, at 3:43 AM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:

Hi OAuthers:

 

One of the to do for https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05 is = to come up with a better title.

The current title =E2=80=9COAuth 2.0 JWT Authorization Request (JAR)=E2=80=9D, is = somewhat better than what it used to be, but if you can suggest a better = name, I am all for it.

Please let me know if you have an idea.

Best,

--

Nat Sakimura <n-sakimura@nri.co.jp>

Nomura Research Institute, Ltd.

 

PLEASE READ:

The information contained in this e-mail is = confidential and intended for the named recipient(s) only.

If = you are not an intended recipient of this e-mail, you are hereby = notified that any review, dissemination, distribution or duplication of = this message is strictly prohibited. If you have received this message = in error, please notify the sender immediately and delete your copy from = your system.

 

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


--
Nat Sakimura (=3Dnat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_DC7B38A1-BE56-496A-9CB0-69E8D4A17577-- --Apple-Mail=_7D11C4E3-4EEB-407D-9675-3D63025ECBB4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTEwMDkxNTM5MTVaMCMGCSqGSIb3DQEJBDEWBBSY2Q2m4ew5d83bfkT63A8D WAIFmTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBGLvZq458+2AnUlzu3amJa7ethvZmCDxjwW7BLOVZitXoBlETypVSE YhRdwq0OxjzveIvh7UDYqs2mqVsGUi5IC+qIxEixDaC+DeTi3+rTqMQed5QJ0LzZFxtHN1mUmOSJ 0S31/luEyJ4V5NLfLCtWv7ifujdZBAyXKFUvOTXNaUEMnrvHjZ/cpizJJoPU362DDDLCYgtpbh0y 3iy3QKeeh3k7Sm0smyjhNbhQH7iwr1hW7Vz+82o8d/IbRWI4Ip4TcRSDW4nEwQhjOw/b6SHAD/6E tDzWVWRtUmrsMMWtIpA/8rkBZHG4uSvjjUibg2L9EGIpmGE1EfxrD9N6NNcjAAAAAAAA --Apple-Mail=_7D11C4E3-4EEB-407D-9675-3D63025ECBB4-- From nobody Mon Oct 12 21:14:00 2015 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 AB0DD1B3727 for ; Mon, 12 Oct 2015 21: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 MEyeF1eYssic for ; Mon, 12 Oct 2015 21:13:58 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373321B32C3 for ; Mon, 12 Oct 2015 21:13:58 -0700 (PDT) Received: by wieq12 with SMTP id q12so11624900wie.1 for ; Mon, 12 Oct 2015 21:13:56 -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=RFfXncTRmUOKMS6DJOC4GFh9LFmaK0Ic28siTqpbomE=; b=G5ruW4EZar5EWzgAm6sBlPqtlg5NJxetzkKUomhN/VJ0T2DNmd77XU0hgidjucYQVt 4qv9tDUgrK641x7AkNmLAvYDn4HdBpkTI+rV1OV15h9JBhM1FFSx99tPnr9hUWWenhkJ v0L1A9bKKuHliZOuWNTWm6LQGdEBwqp1zuhYLq5CdZFLI0rTg/hckYPu7l9k7VFdyriZ TnamqAkcvLiHsrRPy76acVo/3fPJvF2E0SRJvmFvrtE9ifEUt3VVrgmFi/gxfwWB3+NE EqxbarriJfZleTOg7565Mm/k23nFP8iIYNJ2V0H6u1A+OA8bumkzltAKeNS4Fj4Lt0sD Rj5w== MIME-Version: 1.0 X-Received: by 10.194.133.105 with SMTP id pb9mr25612366wjb.158.1444709636686; Mon, 12 Oct 2015 21:13:56 -0700 (PDT) Received: by 10.27.125.70 with HTTP; Mon, 12 Oct 2015 21:13:56 -0700 (PDT) Date: Tue, 13 Oct 2015 00:13:56 -0400 Message-ID: From: Ofer Nave To: oauth@ietf.org Content-Type: multipart/alternative; boundary=089e01227ee8b2cdd00521f4ac27 Archived-At: Subject: [OAUTH-WG] Auth Server / Resource Server Coordination 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, 13 Oct 2015 04:13:59 -0000 --089e01227ee8b2cdd00521f4ac27 Content-Type: text/plain; charset=UTF-8 I know the OAuth 2.0 RFC doesn't specify any standards for coordination between the Authorization Server and the Resource Server, as it's generally assumed that both will be owned or operated by the same entity. However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a feature to make it easy for other API developers to delegate to me the responsibility of handling the auth grant process and issuing access tokens. It seems to me that a simple version of this could be easily done by: 1) Defining an Access Token format that contains within it everything a Resource Server will need to validate it and determine the level of access granted (list of scopes, expiration datetime, HMAC signature using a shared secret). 2) Providing a means (basic web UI) for Resource Server owners to register a set of scopes for their service, along with user-understandable descriptions of each to display when they arrive at my Authorization Endpoint. While I've read the relevant RFCs, I'm new to the OAuth domain, and would appreciate any feedback. Is this a stupid idea? Is this a good idea, but redundant with another standard I'm not aware of? -ofer --089e01227ee8b2cdd00521f4ac27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I know the OAuth 2.0 RFC doe= sn't specify any standards for coordination between the Authorization S= erver and the Resource Server, as it's generally assumed that both will= be owned or operated by the same entity.

However, I'm bui= lding an OAuth 2.0 Auth Server, and I'd like to add a feature to make i= t easy for other API developers to delegate to me the responsibility of han= dling the auth grant process and issuing access tokens.

It see= ms to me that a simple version of this could be easily done by:

1) Defining an Access Token format that contains within it everything a R= esource Server will need to validate it and determine the level of access g= ranted (list of scopes, expiration datetime, HMAC signature using a shared = secret).

2) Providing a means (basic web UI) for Resource Serv= er owners to register a set of scopes for their service, along with user-un= derstandable descriptions of each to display when they arrive at my Authori= zation Endpoint.

While I've read the relevant RFCs, I'= m new to the OAuth domain, and would appreciate any feedback. Is this a stu= pid idea?=C2=A0 Is this a good idea, but redundant with another standard I&= #39;m not aware of?

-ofer
--089e01227ee8b2cdd00521f4ac27-- From nobody Mon Oct 12 21:20:57 2015 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 0E9071B3051 for ; Mon, 12 Oct 2015 21:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 eJaG4crGk0Rm for ; Mon, 12 Oct 2015 21:20:54 -0700 (PDT) Received: from nm47-vm6.bullet.mail.bf1.yahoo.com (nm47-vm6.bullet.mail.bf1.yahoo.com [216.109.115.141]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4791B3743 for ; Mon, 12 Oct 2015 21:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1444710053; bh=/MO9LzXiZ+HZyUgLKWIjA2Sj2m88GwkENRVpz0Fu23Y=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=rRRpnV+X6/xsnkDsqP9qMlHgefh00rQIW/BgsKosLoAFPGpy+dUW7uvW3AvNAuRdudg/P/j4vBzlrMGONzMLNLvyoL2c9rjhK8rNnWiqYnR66+CbYgzjHc9I9FPfjUDPxtbeYKD0MqpUY5qBhgWkH3xqVvUhcefr4+jFq+joVnunZKnkIV0Ik8cjSbaYDke9BOL4bc2MZf8m+RhA6uqI8ixsgtCbK1ybCq2x9i0XboJsNC7w087mB6CtBVD0xQ660Ho5c6enFZBD/52rB4VqIk5kQPnXhpr7Nptwp0Dof2a2KqTIRL96E+/hTwV1l0LznY7+7oyBDnFU31NMee+9lA== Received: from [98.139.215.141] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 13 Oct 2015 04:20:53 -0000 Received: from [98.139.212.236] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 13 Oct 2015 04:20:53 -0000 Received: from [127.0.0.1] by omp1045.mail.bf1.yahoo.com with NNFMP; 13 Oct 2015 04:20:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 239045.7578.bm@omp1045.mail.bf1.yahoo.com X-YMail-OSG: Dj2lW.AVM1l3N_4fgw7p9xFhKiUDPslX4e2CD_XTmFc9kcm4AJou8wakGCquCq3 2z6zwOem0BTb5WiFEfer5v8ReWLoMANalwwNBVx70AfU.KBLbeIPzOKcsnabZy_WG2Xa.uWM3DQV iJ6O6v2MKFXf_d3pK6gLQ81RgDzhrjvbisj9MqwU.pgUT9GnwLR4YUfm.EQs8YzjqZAA_FNPoY7d vvc96j83acLVg1LQkiuIrBc2ND7xdI.2iChfuMSF0UGgFpCR6Squm9eeFuMn9W4z6ffqK4KsHB2s _nBii.kOz02NryycVhJHlwALIwk9tiqIHfYPl4NSVkvovDfM8O4UGGtfEXhDDHAZ_bZBzZmcjIuz oA9ZnQn5btnW3tNw1HwYj5_xhvwrZapzuGQ4jHggOinhtPm2JmtrmltK6lkw4k2eWFCnjQyyKRGP 8smWCjnXNkQ2s8Bh6rAbvafNSppfoNthXzZoOxK4rKN.ztaRrhu5digygoyIY7tPrxyOj5s.nfkz SS8IF7cJ28Gw- Received: by 76.13.27.55; Tue, 13 Oct 2015 04:20:51 +0000 Date: Tue, 13 Oct 2015 04:20:48 +0000 (UTC) From: Bill Mills To: Ofer Nave , "oauth@ietf.org" Message-ID: <2064190583.2714607.1444710048221.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2714606_1358678175.1444710048217" Archived-At: Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination 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: Tue, 13 Oct 2015 04:20:56 -0000 ------=_Part_2714606_1358678175.1444710048217 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You're generally right on track. =C2=A0The RS needs to understand the token= format and needs to trust the AS. =C2=A0You bring in all the "hwo do 2 ent= ities maintain a trust relationship in computing thing" here, because the R= S needs to trust the AS. =C2=A0You can use a JWT (a common choice) as your = token format which makes that part fairly easy. =C2=A0You do have decisions= to make on whether you use symmetric crypto or PK there.=20 On Monday, October 12, 2015 9:14 PM, Ofer Nave wro= te: =20 I know the OAuth 2.0 RFC doesn't specify any standards for coordination be= tween the Authorization Server and the Resource Server, as it's generally a= ssumed that both will be owned or operated by the same entity. However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a featu= re to make it easy for other API developers to delegate to me the responsib= ility of handling the auth grant process and issuing access tokens. It seems to me that a simple version of this could be easily done by: 1) Defining an Access Token format that contains within it everything a Res= ource Server will need to validate it and determine the level of access gra= nted (list of scopes, expiration datetime, HMAC signature using a shared se= cret). 2) Providing a means (basic web UI) for Resource Server owners to register = a set of scopes for their service, along with user-understandable descripti= ons of each to display when they arrive at my Authorization Endpoint. While I've read the relevant RFCs, I'm new to the OAuth domain, and would a= ppreciate any feedback. Is this a stupid idea?=C2=A0 Is this a good idea, b= ut redundant with another standard I'm not aware of? -ofer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_2714606_1358678175.1444710048217 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You're generally rig= ht on track.  The RS needs to understand the token format and needs to= trust the AS.  You bring in all the "hwo do 2 entities maintain a tru= st relationship in computing thing" here, because the RS needs to trust the= AS.  You can use a JWT (a common choice) as your token format which m= akes that part fairly easy.  You do have decisions to make on whether = you use symmetric crypto or PK there.



O= n Monday, October 12, 2015 9:14 PM, Ofer Nave <odigity@gmail.com> wro= te:


I know the OA= uth 2.0 RFC doesn't specify any standards for coordination between the Auth= orization Server and the Resource Server, as it's generally assumed that bo= th will be owned or operated by the same entity.

However, I'm = building an OAuth 2.0 Auth Server, and I'd like to add a feature to make it= easy for other API developers to delegate to me the responsibility of hand= ling the auth grant process and issuing access tokens.

It seem= s to me that a simple version of this could be easily done by:

1) Defining an Access Token format that contains within it everything a Re= source Server will need to validate it and determine the level of access gr= anted (list of scopes, expiration datetime, HMAC signature using a shared s= ecret).

2) Providing a means (basic web UI) for Resource Serve= r owners to register a set of scopes for their service, along with user-und= erstandable descriptions of each to display when they arrive at my Authoriz= ation Endpoint.

While I've read the relevant RFCs, I'm new to = the OAuth domain, and would appreciate any feedback. Is this a stupid idea?=   Is this a good idea, but redundant with another standard I'm not awa= re of?

-ofer

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


------=_Part_2714606_1358678175.1444710048217-- From nobody Mon Oct 12 21:36:26 2015 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 0E7861B3749 for ; Mon, 12 Oct 2015 21:36:25 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 Oo-SZMLstxtc for ; Mon, 12 Oct 2015 21:36:23 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D29D1AD324 for ; Mon, 12 Oct 2015 21:36:23 -0700 (PDT) Received: by wicge5 with SMTP id ge5so40253091wic.0 for ; Mon, 12 Oct 2015 21:36: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=S+567zt0EWfhHj3Lu4u7Gw4BDNIOsGbi1A4wf4rUoeo=; b=L8EXvHUvbVHW9bkNAO4YXIso1wkll//9KMfLu+i3outzETPZl5hkoGADpUIKHDm7q2 gQWq9QEz+0/Sr2vIEj5bnTvxVTM9Mfkdq/dJEsE6TRzCrPeCwjVSvddvpV5tdsZbxC25 JDZf4dS9TQyKvL2mkDEjqh5XqS7giDl2vdTICzA3OgDIlEw00/6HvdHzhEBbqUHdsYb9 d1SXe/aEIdVKpbLZG2AvDA40saM7ejqJm8wzW4HPatdfcHEPW0ziQ4jO/GcgtHJby6Vl aCdZcL/w7YtEB/RqbgXBXQTLbs3P8rq8ijIw5UNskCgVYpkR8cUsVtOJUBiPl48ynQ0H eJmw== X-Gm-Message-State: ALoCoQnbxeXd5RdWafrLvhQpR0Zo73vPpTf77pCQ7bQoGIaWiMTYNpLQVJB81k+LGQWYNK22B7gG X-Received: by 10.180.189.102 with SMTP id gh6mr16642942wic.95.1444710981727; Mon, 12 Oct 2015 21:36:21 -0700 (PDT) Received: from [192.168.2.17] (ip5456cfcc.speed.planet.nl. [84.86.207.204]) by smtp.gmail.com with ESMTPSA id qh12sm6841704wic.20.2015.10.12.21.36.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Oct 2015 21:36:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (13A452) In-Reply-To: Date: Tue, 13 Oct 2015 06:36:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <751A2989-38CD-4360-A691-980AA8DE58A8@manicode.com> References: To: Ofer Nave Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination 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, 13 Oct 2015 04:36:25 -0000 This seems like a reasonable approach. Isn't the whole idea of the auth serv= er/resource server separation in OAuth 2.0 so that one auth server can gover= n multiple resource servers? -- Jim Manico @Manicode > On Oct 13, 2015, at 6:13 AM, Ofer Nave wrote: >=20 > I know the OAuth 2.0 RFC doesn't specify any standards for coordination be= tween the Authorization Server and the Resource Server, as it's generally as= sumed that both will be owned or operated by the same entity. >=20 > However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a feat= ure to make it easy for other API developers to delegate to me the responsib= ility of handling the auth grant process and issuing access tokens. >=20 > It seems to me that a simple version of this could be easily done by: >=20 > 1) Defining an Access Token format that contains within it everything a Re= source Server will need to validate it and determine the level of access gra= nted (list of scopes, expiration datetime, HMAC signature using a shared sec= ret). >=20 > 2) Providing a means (basic web UI) for Resource Server owners to register= a set of scopes for their service, along with user-understandable descripti= ons of each to display when they arrive at my Authorization Endpoint. >=20 > While I've read the relevant RFCs, I'm new to the OAuth domain, and would a= ppreciate any feedback. Is this a stupid idea? Is this a good idea, but red= undant with another standard I'm not aware of? >=20 > -ofer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Oct 12 21:37:49 2015 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 C73681AD324 for ; Mon, 12 Oct 2015 21:37:47 -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 UajJG3nD7Mbs for ; Mon, 12 Oct 2015 21:37:45 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C55E1B30BD for ; Mon, 12 Oct 2015 21:37:45 -0700 (PDT) Received: by wicge5 with SMTP id ge5so40274912wic.0 for ; Mon, 12 Oct 2015 21:37:43 -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=nQDSdapiWN2Y04UjTJl0+CQLqOnHfbGOChgvT04GaAo=; b=R8F6yTjsluoUhBBXAulr6WhOPVJqQdA1uPPH2oHZo8AVf2MrZwSQUpXBte4q1eCVgQ mAqL6VOTXXBeq6QivPIHl9vxOsP1AqRhCR/CWFxlmIiXl0mwieMsvKp1Fckhykun3YLF Nd60iFfUf4IS+yyfx8zoOIwr76cFKkphQdFlcn3QHR93/6jwBnmyhF+4SYyLb/vgZVjg JtED/2WpjmZU3A7B0hMRvDtV92HieXc1t+nrB0jlrSbLwzKNYYdlX+0lSnTn+d8GBAcp EVAauR6FN5MK5vrZO9czPzYC1DxqOuxn79LooCsX0doXSca8hdu9+SRH4wHmohLzEZKP 4SVA== MIME-Version: 1.0 X-Received: by 10.180.106.4 with SMTP id gq4mr19459727wib.53.1444711063673; Mon, 12 Oct 2015 21:37:43 -0700 (PDT) Received: by 10.27.125.70 with HTTP; Mon, 12 Oct 2015 21:37:43 -0700 (PDT) In-Reply-To: <2064190583.2714607.1444710048221.JavaMail.yahoo@mail.yahoo.com> References: <2064190583.2714607.1444710048221.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 13 Oct 2015 00:37:43 -0400 Message-ID: From: Ofer Nave To: Bill Mills Content-Type: multipart/alternative; boundary=f46d0443069cc0e6da0521f5011e Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination 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, 13 Oct 2015 04:37:47 -0000 --f46d0443069cc0e6da0521f5011e Content-Type: text/plain; charset=UTF-8 > The RS needs to understand the token format and needs to trust the AS. I'm not too concerned about that because the people who would be using my service to handle auth for their API are mostly going to know me personally. (It's a community-specific service.) And my code will be open to them for review. > You can use a JWT (a common choice) as your token format which makes that part fairly easy. I was wondering about that, actually, as I've never had to design a token format. I wasn't too worried, because it seems to me that even a simple, obvious structure would be sufficient for the task (pick an object notation like JSON or just a separator like pipe, put the fixed fields like signature and expiration first, and then the rest are scope strings). However, I agree it's generally wise to reuse existing, proven standards. I learned about JWTs while studying OAuth2, and they do seem both interesting an appropriate. But they're also generalized, right? As in, not specific to OAuth 2. Even this RFC about using JWT with OAuth2 doesn't actually discuss, for example, how to encode a list of scopes within the JWT: https://tools.ietf.org/html/rfc7523 So, is there any kind of standard for an OAuth2 Access Token specifically that addresses this need? If not, I'll probably just build on top of JWT since it's the closest. > You do have decisions to make on whether you use symmetric crypto or PK there. That's another thing I was pondering -- simple shared secret, or require generated a private/public key pair. The asymetric form is a little more complicated in terms of the user experience. Is there a practical reason to prefer it? -ofer On Tue, Oct 13, 2015 at 12:20 AM, Bill Mills wrote: > You're generally right on track. The RS needs to understand the token > format and needs to trust the AS. You bring in all the "hwo do 2 entities > maintain a trust relationship in computing thing" here, because the RS > needs to trust the AS. You can use a JWT (a common choice) as your token > format which makes that part fairly easy. You do have decisions to make on > whether you use symmetric crypto or PK there. > > > > On Monday, October 12, 2015 9:14 PM, Ofer Nave wrote: > > > I know the OAuth 2.0 RFC doesn't specify any standards for coordination > between the Authorization Server and the Resource Server, as it's generally > assumed that both will be owned or operated by the same entity. > > However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a > feature to make it easy for other API developers to delegate to me the > responsibility of handling the auth grant process and issuing access tokens. > > It seems to me that a simple version of this could be easily done by: > > 1) Defining an Access Token format that contains within it everything a > Resource Server will need to validate it and determine the level of access > granted (list of scopes, expiration datetime, HMAC signature using a shared > secret). > > 2) Providing a means (basic web UI) for Resource Server owners to register > a set of scopes for their service, along with user-understandable > descriptions of each to display when they arrive at my Authorization > Endpoint. > > While I've read the relevant RFCs, I'm new to the OAuth domain, and would > appreciate any feedback. Is this a stupid idea? Is this a good idea, but > redundant with another standard I'm not aware of? > > -ofer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --f46d0443069cc0e6da0521f5011e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> The RS needs to unders= tand the token format and needs to trust the AS.

= I'm not too concerned about that because the people who would be using = my service to handle auth for their API are mostly going to know me persona= lly.=C2=A0 (It's a community-specific service.)=C2=A0 And my code will = be open to them for review.

> You can use a JWT (a c= ommon choice) as your token format which makes that part fairly easy.
I was wondering about that, actually, as I've neve= r had to design a token format.=C2=A0 I wasn't too worried, because it = seems to me that even a simple, obvious structure would be sufficient for t= he task (pick an object notation like JSON or just a separator like pipe, p= ut the fixed fields like signature and expiration first, and then the rest = are scope strings).=C2=A0 However, I agree it's generally wise to reuse= existing, proven standards.

I learned about JWTs= while studying OAuth2, and they do seem both interesting an appropriate.= =C2=A0 But they're also generalized, right?=C2=A0 As in, not specific t= o OAuth 2.=C2=A0 Even this RFC about using JWT with OAuth2 doesn't actu= ally discuss, for example, how to encode a list of scopes within the JWT:= =C2=A0 https://tools.ietf.o= rg/html/rfc7523

So, is there any kind of stan= dard for an OAuth2 Access Token specifically that addresses this need?=C2= =A0 If not, I'll probably just build on top of JWT since it's the c= losest.

> You do have decisions to make on whe= ther you use symmetric crypto or PK there.

= That's another thing I was pondering -- simple shared secret, or = require generated a private/public key pair.

The asymetric form is a little more complicated in terms of the user exper= ience.=C2=A0 Is there a practical reason to prefer it?

=
-ofer

On Tue, Oct 13, 2015 at 12:20 AM, Bill M= ills <wmills_92105@yahoo.com> wrote:
You're generally right on track.= =C2=A0 The RS needs to understand the token format and needs to trust the A= S.=C2=A0 You bring in all the "hwo do 2 entities maintain a trust rela= tionship in computing thing" here, because the RS needs to trust the A= S.=C2=A0 You can use a JWT (a common choice) as your token format which mak= es that part fairly easy.=C2=A0 You do have decisions to make on whether yo= u use symmetric crypto or PK there.



On Monday, October 12, 2015 9:14 PM, Ofer Nave = <odigity@gmail.co= m> wrote:


I know the O= Auth 2.0 RFC doesn't specify any standards for coordination between the= Authorization Server and the Resource Server, as it's generally assume= d that both will be owned or operated by the same entity.

Howe= ver, I'm building an OAuth 2.0 Auth Server, and I'd like to add a f= eature to make it easy for other API developers to delegate to me the respo= nsibility of handling the auth grant process and issuing access tokens.
=
It seems to me that a simple version of this could be easily done= by:

1) Defining an Access Token format that contains within i= t everything a Resource Server will need to validate it and determine the l= evel of access granted (list of scopes, expiration datetime, HMAC signature= using a shared secret).

2) Providing a means (basic web UI) f= or Resource Server owners to register a set of scopes for their service, al= ong with user-understandable descriptions of each to display when they arri= ve at my Authorization Endpoint.

While I've read the relev= ant RFCs, I'm new to the OAuth domain, and would appreciate any feedbac= k. Is this a stupid idea?=C2=A0 Is this a good idea, but redundant with ano= ther standard I'm not aware of?

-ofer

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


<= /div>

--f46d0443069cc0e6da0521f5011e-- From nobody Mon Oct 12 21:42:32 2015 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 7D0561B3764 for ; Mon, 12 Oct 2015 21:42: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 ggUHmYJHN3dL for ; Mon, 12 Oct 2015 21:42:29 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01721B3763 for ; Mon, 12 Oct 2015 21:42:28 -0700 (PDT) Received: by wicge5 with SMTP id ge5so40355427wic.0 for ; Mon, 12 Oct 2015 21:42:27 -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=cQS3NcKo+sNH51VjFR+IURe1xSkGYf8lykwKb6+M9iw=; b=P8OpBNO0zqRReKGAsG2OzDVz+1zzVCXxs7Lh/yMOSZrYQkxoNNq+Rn9UGlMRjOph5v TylwPNOB80qb3y8T/08YM9cgez8EgdP0YISSMEjJnPxgAxXtz1nmphPbRsylrjCe8u9y ZOByxSls39r+HKsENt66fLk3MzVfEL+2HeZlP5C4TN2awQNCfrd2pNy8mn5Rk2qUWTNp HySWx516W+6PFqd2Ngj7c5hcSJR/TE2U2GuKJFG6oKjvatM7nEoH9y+0uUuLNB09aJve t4O/iLTi3pipM554BpWlpYGht1z+OusxgJZtCdD68hlIrlkJH96pGg6yyKPim7SiniKk CLQw== MIME-Version: 1.0 X-Received: by 10.180.184.138 with SMTP id eu10mr19260707wic.25.1444711347556; Mon, 12 Oct 2015 21:42:27 -0700 (PDT) Received: by 10.27.125.70 with HTTP; Mon, 12 Oct 2015 21:42:27 -0700 (PDT) In-Reply-To: <751A2989-38CD-4360-A691-980AA8DE58A8@manicode.com> References: <751A2989-38CD-4360-A691-980AA8DE58A8@manicode.com> Date: Tue, 13 Oct 2015 00:42:27 -0400 Message-ID: From: Ofer Nave To: Jim Manico Content-Type: multipart/alternative; boundary=001a11c33608ac99b40521f5125b Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination 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, 13 Oct 2015 04:42:31 -0000 --001a11c33608ac99b40521f5125b Content-Type: text/plain; charset=UTF-8 > Isn't the whole idea of the auth server/resource server separation in OAuth 2.0 so that one auth server can govern multiple resource servers? The spec certainly allows for that, but it stops short of: 1) Defining an Access Token structure that both parties can understand. 2) Any standards whatsoever about any other communication or coordination between the AS and RS. It's outside the scope of the spec, and so it falls to the implementer to make those decisions. This is my first attempt to do so. The design I propose is very simple and yet seems to accomplish the goal sufficiently. The way OAuth2 is designed, authorization comes down to a simple set of scope booleans, and that's very easy to model and delegate. There's really no reason everyone should have to be reinventing this. The protocol for AS/RS coordination almost seems to write itself. I'm surprised an extension doesn't exist yet for this -- which is why I'm asking for a sanity check, just in case I've missed something. -ofer On Tue, Oct 13, 2015 at 12:36 AM, Jim Manico wrote: > This seems like a reasonable approach. Isn't the whole idea of the auth > server/resource server separation in OAuth 2.0 so that one auth server can > govern multiple resource servers? > > -- > Jim Manico > @Manicode > > > On Oct 13, 2015, at 6:13 AM, Ofer Nave wrote: > > > > I know the OAuth 2.0 RFC doesn't specify any standards for coordination > between the Authorization Server and the Resource Server, as it's generally > assumed that both will be owned or operated by the same entity. > > > > However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a > feature to make it easy for other API developers to delegate to me the > responsibility of handling the auth grant process and issuing access tokens. > > > > It seems to me that a simple version of this could be easily done by: > > > > 1) Defining an Access Token format that contains within it everything a > Resource Server will need to validate it and determine the level of access > granted (list of scopes, expiration datetime, HMAC signature using a shared > secret). > > > > 2) Providing a means (basic web UI) for Resource Server owners to > register a set of scopes for their service, along with user-understandable > descriptions of each to display when they arrive at my Authorization > Endpoint. > > > > While I've read the relevant RFCs, I'm new to the OAuth domain, and > would appreciate any feedback. Is this a stupid idea? Is this a good idea, > but redundant with another standard I'm not aware of? > > > > -ofer > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --001a11c33608ac99b40521f5125b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Isn't the whol= e idea of the auth=20 server/resource server separation in OAuth 2.0 so that one auth server=20 can govern multiple resource servers?

The spec certainly allow= s for that, but it stops short of:

1) Defining an Access Token= structure that both parties can understand.
2) Any standards what= soever about any other communication or coordination between the AS and RS.=

It's outside the scope of the spec, and so it falls to th= e implementer to make those decisions.=C2=A0 This is my first attempt to do= so.

The design I propose is very simple and yet seems to acco= mplish the goal sufficiently.=C2=A0 The way OAuth2 is designed, authorizati= on comes down to a simple set of scope booleans, and that's very easy t= o model and delegate.=C2=A0 There's really no reason everyone should ha= ve to be reinventing this.=C2=A0 The protocol for AS/RS coordination almost= seems to write itself.=C2=A0 I'm surprised an extension doesn't ex= ist yet for this -- which is why I'm asking for a sanity check, just in= case I've missed something.

-ofer

On Tue, Oct 13, 2015 at 1= 2:36 AM, Jim Manico <jim@manicode.com> wrote:
This seems like a reasonable approach. Isn't the who= le idea of the auth server/resource server separation in OAuth 2.0 so that = one auth server can govern multiple resource servers?

--
Jim Manico
@Manicode

> On Oct 13, 2015, at 6:13 AM, Ofer Nave <odigity@gmail.com> wrote:
>
> I know the OAuth 2.0 RFC doesn't specify any standards for coordin= ation between the Authorization Server and the Resource Server, as it's= generally assumed that both will be owned or operated by the same entity.<= br> >
> However, I'm building an OAuth 2.0 Auth Server, and I'd like t= o add a feature to make it easy for other API developers to delegate to me = the responsibility of handling the auth grant process and issuing access to= kens.
>
> It seems to me that a simple version of this could be easily done by:<= br> >
> 1) Defining an Access Token format that contains within it everything = a Resource Server will need to validate it and determine the level of acces= s granted (list of scopes, expiration datetime, HMAC signature using a shar= ed secret).
>
> 2) Providing a means (basic web UI) for Resource Server owners to regi= ster a set of scopes for their service, along with user-understandable desc= riptions of each to display when they arrive at my Authorization Endpoint.<= br> >
> While I've read the relevant RFCs, I'm new to the OAuth domain= , and would appreciate any feedback. Is this a stupid idea?=C2=A0 Is this a= good idea, but redundant with another standard I'm not aware of?
>
> -ofer
> __________________= _____________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--001a11c33608ac99b40521f5125b-- From nobody Tue Oct 13 01:36:20 2015 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 4A6BE1A1A69 for ; Tue, 13 Oct 2015 01:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7G-GE1MTN-Em for ; Tue, 13 Oct 2015 01:36:17 -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 C1DF01A011B for ; Tue, 13 Oct 2015 01:36:16 -0700 (PDT) X-AuditID: 12074422-f79976d0000078ca-15-561cc27f9741 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 46.C0.30922.F72CC165; Tue, 13 Oct 2015 04:36:15 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t9D8aF9Y028982; Tue, 13 Oct 2015 04:36:15 -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 t9D8aDWY019065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Oct 2015 04:36:14 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Tue, 13 Oct 2015 04:36:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ofer Nave X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixG6nolt/SCbMYOcbc4uTb1+xWexec5PF gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MrYNa2TqaBLqmLu3G62BsYFol2MnBwSAiYS U/9dY4WwxSQu3FvPBmILCSxmkvh50q6LkQvI3sgocWrWQ1aIxEMmia33ckFsZgF1iT/zLjGD 2LwCehKvbl0GqxEWcJKY93w/O4jNJqAqMX1NC1MXIwcHp0CgROtsWZAwC1C47+F/FpAwyJj2 ky4QE7Ulli18DTXRSuJA11UmiK0BEu2HZ4HZIgKKEoc3zWSEOFlWYvfvR0wTGAVnITloFpKD ZiEZu4CReRWjbEpulW5uYmZOcWqybnFyYl5eapGuqV5uZoleakrpJkZw6Loo7WD8eVDpEKMA B6MSD++LSJkwIdbEsuLK3EOMkhxMSqK8mruBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4k1qA crwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKEryvDgA1ChalpqdWpGXm lCCkmTg4QYbzAA2PPggyvLggMbc4Mx0if4pRUUqc9zVIswBIIqM0D64XlFoS3h42fcUoDvSK MK8zSDsPMC3Bdb8CGswENNiIXQpkcEkiQkqqgVHUwm5Bypv0Pv4DfT9eqAfHbqkrf8PAVlGc ZPeniaP2rI99BccLa6/pbltlC1Rkj5k4WE0rzM+xvrf079J1ugySBfkB+2YWpvwJ9u38/PDw G09JOXWWEnaZN41u0duDLJ15c+8LTO7IKVc5PE+iffaFJWeC5obyOJyPmPYiuWXDMZ92M1Y9 JZbijERDLeai4kQADY9JIQgDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination 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, 13 Oct 2015 08:36:19 -0000 I think what you=E2=80=99re talking about is reasonable, but I also = think that you don=E2=80=99t need to invent anything. You=E2=80=99re = right that these things aren=E2=80=99t defined in OAuth core itself, but = instead they=E2=80=99re defined in companion specs. Most notably you = have: - JWT (RFC7519): a structured token based on JSON and JOSE that lets = you carry information inside the token itself. This can be signed and/or = encrypted. The RS needs to understand the token format, but the client = can still be oblivious to it and still function just fine. = https://tools.ietf.org/html/rfc7519 - Introspection (soon to be RFC7662, it=E2=80=99s in the final stage of = editing as we speak): a simple protocol that allows an RS to query the = AS with a token to see if it=E2=80=99s any good and what it=E2=80=99s = good for. This returns a JSON document describing the token. = https://tools.ietf.org/html/draft-ietf-oauth-introspection - UMA=E2=80=99s resource set registration (from Kantara, version 1.0.1 = in final review right now): This is part of the User Managed Access = (UMA) protocol and it lets an RS register a set of resources at the AS. = This is very similar to what you=E2=80=99re describing below in terms of = registering scopes for each resource server. = https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-v1_0_1.htm= l Combining these specs together you=E2=80=99ve got pretty much what = you=E2=80=99re after, as best as I can tell. There are a number of = implementations of all of these, including the project that I help run, = MITREid Connect. https://github.com/mitreid-connect/ Our server issues = signed JWTs, provides token introspection, and lets resource server = owners register their scopes to expose to users through a simple web UI.=20= =E2=80=94 Justin > On Oct 13, 2015, at 12:13 AM, Ofer Nave wrote: >=20 > I know the OAuth 2.0 RFC doesn't specify any standards for = coordination between the Authorization Server and the Resource Server, = as it's generally assumed that both will be owned or operated by the = same entity. >=20 > However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a = feature to make it easy for other API developers to delegate to me the = responsibility of handling the auth grant process and issuing access = tokens. >=20 > It seems to me that a simple version of this could be easily done by: >=20 > 1) Defining an Access Token format that contains within it everything = a Resource Server will need to validate it and determine the level of = access granted (list of scopes, expiration datetime, HMAC signature = using a shared secret). >=20 > 2) Providing a means (basic web UI) for Resource Server owners to = register a set of scopes for their service, along with = user-understandable descriptions of each to display when they arrive at = my Authorization Endpoint. >=20 > While I've read the relevant RFCs, I'm new to the OAuth domain, and = would appreciate any feedback. Is this a stupid idea? Is this a good = idea, but redundant with another standard I'm not aware of? >=20 > -ofer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Oct 13 01:40:09 2015 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 BC7A11A1A7C for ; Tue, 13 Oct 2015 01:40:08 -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, 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 MdaP4a--P3Vw for ; Tue, 13 Oct 2015 01:40:07 -0700 (PDT) Received: from p3plsmtpa11-02.prod.phx3.secureserver.net (p3plsmtpa11-02.prod.phx3.secureserver.net [68.178.252.103]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874971A1A72 for ; Tue, 13 Oct 2015 01:40:07 -0700 (PDT) Received: from [192.168.0.106] ([77.77.164.50]) by p3plsmtpa11-02.prod.phx3.secureserver.net with id UYg51r00A15ZTut01Yg6DZ; Tue, 13 Oct 2015 01:40:07 -0700 To: oauth@ietf.org References: <2064190583.2714607.1444710048221.JavaMail.yahoo@mail.yahoo.com> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <561CC364.1090206@connect2id.com> Date: Tue, 13 Oct 2015 11:40:04 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination 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, 13 Oct 2015 08:40:08 -0000 On 13.10.2015 07:37, Ofer Nave wrote: >> You do have decisions to make on whether you use symmetric crypto or P= K > there. > > That's another thing I was pondering -- simple shared secret, or requir= e > generated a private/public key pair. > > The asymetric form is a little more complicated in terms of the user > experience. Is there a practical reason to prefer it? If the AS and the Resource Servers (RS) share a secret, there is a risk of an RS impersonating authorised clients by creating valid tokens to access other RSs. You may prevent this by making sure every RS gets its own secret, but in that case you cannot issue tokens with multiple RS audiences. With asymmetric keys you won't have these problems. The RS would only need to have a copy of the public AS key to verify the tokens. Vladimir --=20 Vladimir Dzhuvinov From nobody Tue Oct 13 02:10:44 2015 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 BC8121A212A for ; Tue, 13 Oct 2015 02:10:42 -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 XU-3OGt3yBxT for ; Tue, 13 Oct 2015 02:10:41 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E821A21A6 for ; Tue, 13 Oct 2015 02:10:40 -0700 (PDT) Received: by lbbck17 with SMTP id ck17so12122691lbb.1 for ; Tue, 13 Oct 2015 02:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=0V6A4HD5I+psn7mcGfxcTIF+PNbZb+OVYqtI5fxTsXQ=; b=fi1ialQLdpJBovQzDyReTRwE68NRL2UYMajluFsSXeu+7Vd8rNEQb0YssRMknuxz4h P3xfCygR4SLFW6SYWNkVCAQHG5Of1WTpuRMzPW8w5SKNRpYZf0PWot1d0wt1Mbj6YIVN fQNhJPpCb4Et//oyhfaOfFQUpgLMetqJN9ftPab3hNYbYRSVyIrDT/bvgTBLm/vXfde2 vCMYF4//JjVgHjfGWBIjWPgZiztoBO6mj5+O3ok/VSLr5DPgZFUW8As6XBYEVuMzib0J W7dwRe/WWvKGc2iEzg03rVJk4Gnk/5D+EZ+qZqB5qSdJgJtaBjWYGHwpJ9+v59BmdpJs ou7A== X-Received: by 10.25.16.195 with SMTP id 64mr1873100lfq.62.1444727438778; Tue, 13 Oct 2015 02:10:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Thomas Broyer Date: Tue, 13 Oct 2015 09:10:28 +0000 Message-ID: To: Ofer Nave , oauth@ietf.org Content-Type: multipart/alternative; boundary=001a113fb984c925f10521f8d195 Archived-At: Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination 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, 13 Oct 2015 09:10:42 -0000 --001a113fb984c925f10521f8d195 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 13, 2015 at 6:14 AM Ofer Nave wrote: > I know the OAuth 2.0 RFC doesn't specify any standards for coordination > between the Authorization Server and the Resource Server, as it's generally > assumed that both will be owned or operated by the same entity. > > However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a > feature to make it easy for other API developers to delegate to me the > responsibility of handling the auth grant process and issuing access tokens. > > It seems to me that a simple version of this could be easily done by: > > 1) Defining an Access Token format that contains within it everything a > Resource Server will need to validate it and determine the level of access > granted (list of scopes, expiration datetime, HMAC signature using a shared > secret). > Either that (and I'd use JWT then, as already proposed) or have resource servers introspect tokens < https://tools.ietf.org/html/draft-ietf-oauth-introspection-11> (the latter doesn't preclude the former, but the format of the token is then just an implementation detail of the AS that the RS doesn't need to know). One advantage of requiring introspection is the easy support of revocation without having to create a specific API to check whether a token is revoked: you just introspect the token and directly know whether the token is valid or not, and if it's valid you get its details (and have the RS cache the response for a few seconds/minutes to avoid overloading the introspection endpoint). That being said, RS knowing the tokens are JWTs allows them to reject invalid tokens (expired, invalid signature, unexpected issuer, etc.) without the need to check for revocation at the AS. > 2) Providing a means (basic web UI) for Resource Server owners to register > a set of scopes for their service, along with user-understandable > descriptions of each to display when they arrive at my Authorization > Endpoint. > Either a Web UI, or an API < https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06> (I'm not a fan of this draft, and it incidentally violates IETF's BCP190 https://tools.ietf.org/html/bcp190, but I think it's a good source of inspiration) --001a113fb984c925f10521f8d195 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue= , Oct 13, 2015 at 6:14 AM Ofer Nave <odigity@gmail.com> wrote:
=
I know the OAuth 2.0 RFC doe= sn't specify any standards for coordination between the Authorization S= erver and the Resource Server, as it's generally assumed that both will= be owned or operated by the same entity.

However, I'm bui= lding an OAuth 2.0 Auth Server, and I'd like to add a feature to make i= t easy for other API developers to delegate to me the responsibility of han= dling the auth grant process and issuing access tokens.

It see= ms to me that a simple version of this could be easily done by:

1) Defining an Access Token format that contains within it everything a R= esource Server will need to validate it and determine the level of access g= ranted (list of scopes, expiration datetime, HMAC signature using a shared = secret).

Either= that (and I'd use JWT then, as already proposed) or have resource serv= ers introspect tokens <https://tools.ietf.org/html/draft-ietf-oauth-intro= spection-11> (the latter doesn't preclude the former, but the fo= rmat of the token is then just an implementation detail of the AS that the = RS doesn't need to know).
One advantage of requiring introspe= ction is the easy support of revocation without having to create a specific= API to check whether a token is revoked: you just introspect the token and= directly know whether the token is valid or not, and if it's valid you= get its details (and have the RS cache the response for a few seconds/minu= tes to avoid overloading the introspection endpoint). That being said, RS k= nowing the tokens are JWTs allows them to reject invalid tokens (expired, i= nvalid signature, unexpected issuer, etc.) without the need to check for re= vocation at the AS.
=C2=A0
2) Providing a means (basic web UI) for= Resource Server owners to register a set of scopes for their service, alon= g with user-understandable descriptions of each to display when they arrive= at my Authorization Endpoint.

<= /div>
Either a Web UI, or an API <https://tools.ietf.org/html/draf= t-hardjono-oauth-resource-reg-06> (I'm not a fan of this draft, = and it incidentally violates IETF's BCP190=C2=A0https://tools.ietf.org/html/bcp190, but I think= it's a good source of inspiration)
--001a113fb984c925f10521f8d195-- From nobody Tue Oct 13 06:40:31 2015 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 02F351B3D5E for ; Tue, 13 Oct 2015 06:40: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 pT8lODTomXaH for ; Tue, 13 Oct 2015 06:40:27 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BC51B3D5C for ; Tue, 13 Oct 2015 06:40:27 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so89957732wic.1 for ; Tue, 13 Oct 2015 06:40:25 -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=Xwy3FBJQKyw5IR48Pc03RLJGB+jRivEI59nuUMZXXzA=; b=dB9OV8jwq0NoVSdqCcAhN6V8NQ7+7XeTvDX61JHOEXCXfpxf6ZmudGBOnqYSIQqhwq UUCEXJduviTlW2Ox+kbFKhIb5PUmJ4/FKtluQUw6vOwM1TOzIDmZNOFnXrYxYjCZdvUa o6iesv5iP+erK50dJ9Br7QRhAL76hPALm+44f2Q03q5DrWxERsEPL3gbJVUD6avta+oQ SbIKJ4VaoPgI8ZwcSjL3Y9Q3EqsefaEqCBm/IgQ0Sx4n1AE3N1cghvto7E58C4acP4sP wT46dGNZTwQdxN9+OHlLqfwa358mQZl0VfgFTVPoVCY6MimYpq4GLKqglEQg3l6JkwgT DjYw== MIME-Version: 1.0 X-Received: by 10.194.2.243 with SMTP id 19mr35782845wjx.140.1444743608171; Tue, 13 Oct 2015 06:40:08 -0700 (PDT) Received: by 10.27.125.70 with HTTP; Tue, 13 Oct 2015 06:40:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Oct 2015 09:40:08 -0400 Message-ID: From: Ofer Nave To: Justin Richer Content-Type: multipart/alternative; boundary=047d7b3a86bc8e8c450521fc959a Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination 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, 13 Oct 2015 13:40:30 -0000 --047d7b3a86bc8e8c450521fc959a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > You=E2=80=99re right that these things aren=E2=80=99t defined in OAuth co= re itself, but instead they=E2=80=99re defined in companion specs. Awesome! That's what I was hoping. FYI - Up till now, I had only encountered the following relevant specs: https://tools.ietf.org/html/rfc6749 =E2=80=94 The OAuth 2.0 Authorization F= ramework https://tools.ietf.org/html/rfc6750 =E2=80=94 The OAuth 2.0 Authorization Framework: Bearer Token Usage https://tools.ietf.org/html/rfc6819 =E2=80=94 OAuth 2.0 Threat Model and Se= curity Considerations https://tools.ietf.org/html/rfc7009 =E2=80=94 OAuth 2.0 Token Revocation http://openid.net/specs/openid-connect-core-1_0.html http://openid.net/specs/openid-connect-registration-1_0.html http://openid.net/specs/openid-connect-discovery-1_0.html https://tools.ietf.org/html/rfc7515 =E2=80=94 JSON Web Signature (JWS) https://tools.ietf.org/html/rfc7516 =E2=80=94 JSON Web Encryption (JWE) https://tools.ietf.org/html/rfc7519 =E2=80=94 JSON Web Token (JWT) https://tools.ietf.org/html/rfc7523 =E2=80=94 JSON Web Token (JWT) Profile = for OAuth 2.0 Client Authentication and Authorization Grants https://tools.ietf.org/html/rfc7033 =E2=80=94 WebFinger https://tools.ietf.org/html/rfc2617 =E2=80=94 HTTP Authentication: Basic an= d Digest Access Authentication I'll add the two you mentioned to the list. Any more useful specs I'm missing? :) -ofer On Tue, Oct 13, 2015 at 4:36 AM, Justin Richer wrote: > I think what you=E2=80=99re talking about is reasonable, but I also think= that you > don=E2=80=99t need to invent anything. You=E2=80=99re right that these th= ings aren=E2=80=99t > defined in OAuth core itself, but instead they=E2=80=99re defined in comp= anion > specs. Most notably you have: > > > - JWT (RFC7519): a structured token based on JSON and JOSE that lets you > carry information inside the token itself. This can be signed and/or > encrypted. The RS needs to understand the token format, but the client ca= n > still be oblivious to it and still function just fine. > https://tools.ietf.org/html/rfc7519 > - Introspection (soon to be RFC7662, it=E2=80=99s in the final stage of = editing > as we speak): a simple protocol that allows an RS to query the AS with a > token to see if it=E2=80=99s any good and what it=E2=80=99s good for. Thi= s returns a JSON > document describing the token. > https://tools.ietf.org/html/draft-ietf-oauth-introspection > - UMA=E2=80=99s resource set registration (from Kantara, version 1.0.1 i= n final > review right now): This is part of the User Managed Access (UMA) protocol > and it lets an RS register a set of resources at the AS. This is very > similar to what you=E2=80=99re describing below in terms of registering s= copes for > each resource server. > https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-v1_0_1.ht= ml > > > Combining these specs together you=E2=80=99ve got pretty much what you=E2= =80=99re after, > as best as I can tell. There are a number of implementations of all of > these, including the project that I help run, MITREid Connect. > https://github.com/mitreid-connect/ Our server issues signed JWTs, > provides token introspection, and lets resource server owners register > their scopes to expose to users through a simple web UI. > > > =E2=80=94 Justin > > > > On Oct 13, 2015, at 12:13 AM, Ofer Nave wrote: > > > > I know the OAuth 2.0 RFC doesn't specify any standards for coordination > between the Authorization Server and the Resource Server, as it's general= ly > assumed that both will be owned or operated by the same entity. > > > > However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a > feature to make it easy for other API developers to delegate to me the > responsibility of handling the auth grant process and issuing access toke= ns. > > > > It seems to me that a simple version of this could be easily done by: > > > > 1) Defining an Access Token format that contains within it everything a > Resource Server will need to validate it and determine the level of acces= s > granted (list of scopes, expiration datetime, HMAC signature using a shar= ed > secret). > > > > 2) Providing a means (basic web UI) for Resource Server owners to > register a set of scopes for their service, along with user-understandabl= e > descriptions of each to display when they arrive at my Authorization > Endpoint. > > > > While I've read the relevant RFCs, I'm new to the OAuth domain, and > would appreciate any feedback. Is this a stupid idea? Is this a good ide= a, > but redundant with another standard I'm not aware of? > > > > -ofer > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --047d7b3a86bc8e8c450521fc959a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> You=E2=80=99re right that th= ese things aren=E2=80=99t defined in OAuth core itself, but instead they=E2= =80=99re defined in companion specs.

Awesome!=C2=A0 That's= what I was hoping.

FYI - Up till now, I had only encountered = the following relevant specs:

https://tools.ietf.org/html/rfc6749 =E2=80=94 The OAuth 2.0 A= uthorization Framework
h= ttps://tools.ietf.org/html/rfc6750 =E2=80=94 The OAuth 2.0 Authorizatio= n Framework: Bearer Token Usage
https://tools.ietf.org/html/rfc6819 =E2=80=94 OAuth 2.0 Threat = Model and Security Considerations
https://tools.ietf.org/html/rfc7009 =E2=80=94 OAuth 2.0 Token= Revocation
http://openid.net/specs/openid-connect-core-1_0.html
http://openi= d.net/specs/openid-connect-registration-1_0.html
http://openid.net/specs/= openid-connect-discovery-1_0.html
https://tools.ietf.org/html/rfc7515 =E2=80=94 JSON Web Si= gnature (JWS)
https://to= ols.ietf.org/html/rfc7516 =E2=80=94 JSON Web Encryption (JWE)
https://tools.ietf.org/html/rfc75= 19 =E2=80=94 JSON Web Token (JWT)
https://tools.ietf.org/html/rfc7523 =E2=80=94 JSON Web To= ken (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Gra= nts
https://tools.ietf.o= rg/html/rfc7033 =E2=80=94 WebFinger
https://tools.ietf.org/html/rfc2617 =E2=80=94 HTTP Auth= entication: Basic and Digest Access Authentication

I'll ad= d the two you mentioned to the list.

Any more useful specs I&#= 39;m missing?=C2=A0 :)

-ofer


On T= ue, Oct 13, 2015 at 4:36 AM, Justin Richer <jricher@mit.edu> w= rote:
I think what you=E2=80=99re talking= about is reasonable, but I also think that you don=E2=80=99t need to inven= t anything. You=E2=80=99re right that these things aren=E2=80=99t defined i= n OAuth core itself, but instead they=E2=80=99re defined in companion specs= . Most notably you have:


=C2=A0- JWT (RFC7519): a structured token based on JSON and JOSE that lets = you carry information inside the token itself. This can be signed and/or en= crypted. The RS needs to understand the token format, but the client can st= ill be oblivious to it and still function just fine. https://tool= s.ietf.org/html/rfc7519
=C2=A0- Introspection (soon to be RFC7662, it=E2=80=99s in the final stage = of editing as we speak): a simple protocol that allows an RS to query the A= S with a token to see if it=E2=80=99s any good and what it=E2=80=99s good f= or. This returns a JSON document describing the token. https://tools.ietf.org/html/draft-ietf-oauth-introspection=
=C2=A0- UMA=E2=80=99s resource set registration (from Kantara, version 1.0.= 1 in final review right now): This is part of the User Managed Access (UMA)= protocol and it lets an RS register a set of resources at the AS. This is = very similar to what you=E2=80=99re describing below in terms of registerin= g scopes for each resource server. https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg= -v1_0_1.html


Combining these specs together you=E2=80=99ve got pretty much what you=E2= =80=99re after, as best as I can tell. There are a number of implementation= s of all of these, including the project that I help run, MITREid Connect. = https://github.com/mitreid-connect/ Our server issues signe= d JWTs, provides token introspection, and lets resource server owners regis= ter their scopes to expose to users through a simple web UI.


=C2=A0=E2=80=94 Justin


> On Oct 13, 2015, at 12:13 AM, Ofer Nave <odigity@gmail.com> wrote:
>
> I know the OAuth 2.0 RFC doesn't specify any standards for coordin= ation between the Authorization Server and the Resource Server, as it's= generally assumed that both will be owned or operated by the same entity.<= br> >
> However, I'm building an OAuth 2.0 Auth Server, and I'd like t= o add a feature to make it easy for other API developers to delegate to me = the responsibility of handling the auth grant process and issuing access to= kens.
>
> It seems to me that a simple version of this could be easily done by:<= br> >
> 1) Defining an Access Token format that contains within it everything = a Resource Server will need to validate it and determine the level of acces= s granted (list of scopes, expiration datetime, HMAC signature using a shar= ed secret).
>
> 2) Providing a means (basic web UI) for Resource Server owners to regi= ster a set of scopes for their service, along with user-understandable desc= riptions of each to display when they arrive at my Authorization Endpoint.<= br> >
> While I've read the relevant RFCs, I'm new to the OAuth domain= , and would appreciate any feedback. Is this a stupid idea?=C2=A0 Is this a= good idea, but redundant with another standard I'm not aware of?
>
> -ofer
> __________________= _____________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--047d7b3a86bc8e8c450521fc959a-- From nobody Tue Oct 13 06:43:07 2015 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 C38281B3DC5 for ; Tue, 13 Oct 2015 06:43:04 -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 p1dSyPQ8v9S3 for ; Tue, 13 Oct 2015 06:43:03 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC70D1B3DBF for ; Tue, 13 Oct 2015 06:43:02 -0700 (PDT) Received: by wijq8 with SMTP id q8so33029619wij.0 for ; Tue, 13 Oct 2015 06:43:01 -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=WQV2lofQj20qqWRn2yM9lctMDArHNbwXMbe+GUuW8vE=; b=InstGTHexHcPlAueqJAktzvgbrSJqWY4j7DZ5o7tCLmhi/MVbcAUeFc/oH9sMX/9V7 FVhVEByzoVnwJblraOK7O7HxY67p4+/V03gQ7QXpY9Yp7Y3+ft6NmcBKbvRc3+OPdiKj sev7yOj44valYmSJPhVtPEIIlpb9ydJIdgPjUpfWUiO/HWr+kRQM0Bs162ig8YwMjrR0 Nb0Lwpx18gYMUXvgBky0A+F8O75szHY6zDi46jaRD3sYhxP29z5j7rg6tCPG5tIUUOH+ RlZpdKsgOLBIfvfQ/HykzXQc/4AGUzmmYhQG4P/BfB5a06A7VSKn45b2tyD8tTqjhIrh 61PA== MIME-Version: 1.0 X-Received: by 10.180.93.168 with SMTP id cv8mr22248916wib.54.1444743750186; Tue, 13 Oct 2015 06:42:30 -0700 (PDT) Received: by 10.27.125.70 with HTTP; Tue, 13 Oct 2015 06:42:30 -0700 (PDT) In-Reply-To: <561CC364.1090206@connect2id.com> References: <2064190583.2714607.1444710048221.JavaMail.yahoo@mail.yahoo.com> <561CC364.1090206@connect2id.com> Date: Tue, 13 Oct 2015 09:42:30 -0400 Message-ID: From: Ofer Nave To: Vladimir Dzhuvinov Content-Type: multipart/alternative; boundary=f46d043c7fba0596b70521fc9ecb Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination 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, 13 Oct 2015 13:43:04 -0000 --f46d043c7fba0596b70521fc9ecb Content-Type: text/plain; charset=UTF-8 > With asymmetric keys you won't have these problems. The RS would only need to have a copy of the public AS key to verify the tokens. That's an excellent point I had considered. -ofer On Tue, Oct 13, 2015 at 4:40 AM, Vladimir Dzhuvinov wrote: > > > On 13.10.2015 07:37, Ofer Nave wrote: > >> You do have decisions to make on whether you use symmetric crypto or PK > > there. > > > > That's another thing I was pondering -- simple shared secret, or require > > generated a private/public key pair. > > > > The asymetric form is a little more complicated in terms of the user > > experience. Is there a practical reason to prefer it? > > If the AS and the Resource Servers (RS) share a secret, there is a risk > of an RS impersonating authorised clients by creating valid tokens to > access other RSs. > > You may prevent this by making sure every RS gets its own secret, but in > that case you cannot issue tokens with multiple RS audiences. > > With asymmetric keys you won't have these problems. The RS would only > need to have a copy of the public AS key to verify the tokens. > > > Vladimir > > -- > Vladimir Dzhuvinov > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --f46d043c7fba0596b70521fc9ecb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> With asymmetric keys you won't have the= se problems. The RS would only need to have a copy of the public AS key to = verify the tokens.

That's an excellent point I had conside= red.

-ofer

On Tue, Oct 13, 2015 at 4:40 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:


On 13.10.2015 07:37, Ofe= r Nave wrote:
>> You do have decisions to make on whether you use symmetric crypto = or PK
> there.
>
> That's another thing I was pondering -- simple shared secret, or r= equire
> generated a private/public key pair.
>
> The asymetric form is a little more complicated in terms of the user > experience.=C2=A0 Is there a practical reason to prefer it?

If the AS and the Resource Servers (RS) share a secret, there is a r= isk
of an RS impersonating authorised clients by creating valid tokens to
access other RSs.

You may prevent this by making sure every RS gets its own secret, but in that case you cannot issue tokens with multiple RS audiences.

With asymmetric keys you won't have these problems. The RS would only need to have a copy of the public AS key to verify the tokens.


Vladimir

--
Vladimir Dzhuvinov


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

--f46d043c7fba0596b70521fc9ecb-- From nobody Tue Oct 13 06:49:19 2015 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 058161B3F24 for ; Tue, 13 Oct 2015 06:49:17 -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 mUJlDVmCHuhE for ; Tue, 13 Oct 2015 06:49:14 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9DC1B3F20 for ; Tue, 13 Oct 2015 06:49:14 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so189883825wic.1 for ; Tue, 13 Oct 2015 06:49:12 -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=DleInM4GFw95MaWqa3yLkvI+ktdRBUUxv5guZqlPyco=; b=hhYYT/ZxxgS/NAQLm4nLHarupgtCzoB/4fFK97VhlAy7kj5/3bbYdULR3LFYp15HJq uWvS805Yiq34LYfWOK4qDdzmwKmZ8eDFERCMBD/PRM35fs7tXNwsl1dclmo9SqiO436I IbzuQEwF2gvnKJM/yZD9nLh01WSCfGt0FCBlIaRelIma0Ah3Czb9o6MUz1TE6pqH65wv 8FXk9LAY/aS0zJG6oPL6GFNeY8MvMA8U9/tCYsZGrh2Hh2naUNeBujgtPZCqOwPBpp5P bO2u3JlNJ/6Klj2XSkZqifKjlLcWS5B144NRmMvJANDO34nvN6GqtAb98xRNHVtxDCZa VlZw== MIME-Version: 1.0 X-Received: by 10.194.2.243 with SMTP id 19mr35835361wjx.140.1444744126555; Tue, 13 Oct 2015 06:48:46 -0700 (PDT) Received: by 10.27.125.70 with HTTP; Tue, 13 Oct 2015 06:48:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Oct 2015 09:48:46 -0400 Message-ID: From: Ofer Nave To: Thomas Broyer Content-Type: multipart/alternative; boundary=047d7b3a86bc7475260521fcb462 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination 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, 13 Oct 2015 13:49:17 -0000 --047d7b3a86bc7475260521fcb462 Content-Type: text/plain; charset=UTF-8 > One advantage of requiring introspection is the easy support of revocation without having to create a specific API to check whether a token is revoked: you just introspect the token and directly know whether the token is valid or not, and if it's valid you get its details (and have the RS cache the response for a few seconds/minutes to avoid overloading the introspection endpoint). That being said, RS knowing the tokens are JWTs allows them to reject invalid tokens (expired, invalid signature, unexpected issuer, etc.) without the need to check for revocation at the AS. It did occur to me that if I make the AT self-contained, then RO-initiated scope revocation wouldn't take affect until the next time a new AT is requested using the RT (when the old AT expires), which I was going to set to 30m to prevent swamping the token endpoint (which would happen if RS's had to call me to validate the AT every time). Now that I know about these extra specs, I'm tempted to implement both (self-contained ATs *and* an introspection endpoint), and see what the adopters decide to do. > Either a Web UI, or an API < https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06> (I'm not a fan of this draft, and it incidentally violates IETF's BCP190 https://tools.ietf.org/html/bcp190, but I think it's a good source of inspiration) What don't you like about it? And can I mitigate the factors you're concerned about in my decision-making process without violating the draft spec? -ofer On Tue, Oct 13, 2015 at 5:10 AM, Thomas Broyer wrote: > > > On Tue, Oct 13, 2015 at 6:14 AM Ofer Nave wrote: > >> I know the OAuth 2.0 RFC doesn't specify any standards for coordination >> between the Authorization Server and the Resource Server, as it's generally >> assumed that both will be owned or operated by the same entity. >> >> However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a >> feature to make it easy for other API developers to delegate to me the >> responsibility of handling the auth grant process and issuing access tokens. >> >> It seems to me that a simple version of this could be easily done by: >> >> 1) Defining an Access Token format that contains within it everything a >> Resource Server will need to validate it and determine the level of access >> granted (list of scopes, expiration datetime, HMAC signature using a shared >> secret). >> > > Either that (and I'd use JWT then, as already proposed) or have resource > servers introspect tokens < > https://tools.ietf.org/html/draft-ietf-oauth-introspection-11> (the > latter doesn't preclude the former, but the format of the token is then > just an implementation detail of the AS that the RS doesn't need to know). > One advantage of requiring introspection is the easy support of revocation > without having to create a specific API to check whether a token is > revoked: you just introspect the token and directly know whether the token > is valid or not, and if it's valid you get its details (and have the RS > cache the response for a few seconds/minutes to avoid overloading the > introspection endpoint). That being said, RS knowing the tokens are JWTs > allows them to reject invalid tokens (expired, invalid signature, > unexpected issuer, etc.) without the need to check for revocation at the AS. > > >> 2) Providing a means (basic web UI) for Resource Server owners to >> register a set of scopes for their service, along with user-understandable >> descriptions of each to display when they arrive at my Authorization >> Endpoint. >> > > Either a Web UI, or an API < > https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06> (I'm > not a fan of this draft, and it incidentally violates IETF's BCP190 > https://tools.ietf.org/html/bcp190, but I think it's a good source of > inspiration) > --047d7b3a86bc7475260521fcb462 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> One advantage of requiring introspecti= on is the easy support of=20 revocation without having to create a specific API to check whether a=20 token is revoked: you just introspect the token and directly know=20 whether the token is valid or not, and if it's valid you get its detail= s (and have the RS cache the response for a few seconds/minutes to avoid=20 overloading the introspection endpoint). That being said, RS knowing the tokens are JWTs allows them to reject invalid tokens (expired, invalid=20 signature, unexpected issuer, etc.) without the need to check for=20 revocation at the AS.

It did occur to me that if I make the AT= self-contained, then RO-initiated scope revocation wouldn't take affec= t until the next time a new AT is requested using the RT (when the old AT e= xpires), which I was going to set to 30m to prevent swamping the token endp= oint (which would happen if RS's had to call me to validate the AT ever= y time).

Now that I know about these extra specs, I'm temp= ted to implement both (self-contained ATs *and* an introspection endpoint),= and see what the adopters decide to do.

> Either a Web UI, or an= API <https://tools.ietf.org/html/draft-hardjono-oau= th-resource-reg-06> (I'm not a fan of this draft, and it inciden= tally violates IETF's BCP190=C2=A0https://tools.ietf.org/html/bcp190, but I t= hink it's a good source of inspiration)

What don'= t you like about it?=C2=A0 And can I mitigate the factors you're concer= ned about in my decision-making process without violating the draft spec?

-ofer

On Tue, Oct 13, 2015 at 5:10 AM, Thomas Broyer <t.br= oyer@gmail.com> wrote:


On Tue, Oct 13, 2015 at 6:14 AM Ofer Nave <odigity@gmail.com> wrote:
=
I know the OAuth 2.0 RFC doesn't specify any standards for coordin= ation between the Authorization Server and the Resource Server, as it's= generally assumed that both will be owned or operated by the same entity.<= br>
However, I'm building an OAuth 2.0 Auth Server, and I'= d like to add a feature to make it easy for other API developers to delegat= e to me the responsibility of handling the auth grant process and issuing a= ccess tokens.

It seems to me that a simple version of this cou= ld be easily done by:

1) Defining an Access Token format that = contains within it everything a Resource Server will need to validate it an= d determine the level of access granted (list of scopes, expiration datetim= e, HMAC signature using a shared secret).

=C2=A0
2) Providing a means (basic web UI)= for Resource Server owners to register a set of scopes for their service, = along with user-understandable descriptions of each to display when they ar= rive at my Authorization Endpoint.
Either a Web UI, or an API <htt= ps://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06> (I= 9;m not a fan of this draft, and it incidentally violates IETF's BCP190= =C2=A0http= s://tools.ietf.org/html/bcp190, but I think it's a good source of i= nspiration)

--047d7b3a86bc7475260521fcb462-- From nobody Tue Oct 13 06:50:49 2015 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 8FE621B3F8C for ; Tue, 13 Oct 2015 06:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=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 tn2rgFK0FFEA for ; Tue, 13 Oct 2015 06:50:44 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705261B3F76 for ; Tue, 13 Oct 2015 06:50:44 -0700 (PDT) Received: by ykfs79 with SMTP id s79so4482913ykf.2 for ; Tue, 13 Oct 2015 06:50:43 -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=f1FP8v7E/csZbtGwCOHgBOh/62kCc8MSQbrsBTdmZRU=; b=UwJfScn6UjZlEEt3ZJUvYjIfKFz+46/iAUurDlIIZa408NpfwKBi/zc+Etxtbohh7R 8Muvf83zs418M7EIiR+bthGpxaX0dLqpYqOVuxYvc8ZUipG6GSdKrDAtMSp8rJISe3rJ hOBu6akXgXhGPO/kLb146bnQjG7Gilx9g6djm+bqFoEkpzIDNgGCmE1nZA1vzAdb8uF2 XEJgStaPCZeC3IcR69WnJ4lWMH+Ac8LJ5iF1K60UNKR7NrE57vprWz37evX0yeV4an/Z 6B6Zv5RXMwsF53JU5OT65CJFQR1uKrAxXa29qCPJqsCCwmkNDvYPLsTG2/gP+R5O2oLJ J18Q== MIME-Version: 1.0 X-Received: by 10.129.86.132 with SMTP id k126mr23929937ywb.144.1444744243760; Tue, 13 Oct 2015 06:50:43 -0700 (PDT) Received: by 10.37.217.130 with HTTP; Tue, 13 Oct 2015 06:50:43 -0700 (PDT) Received: by 10.37.217.130 with HTTP; Tue, 13 Oct 2015 06:50:43 -0700 (PDT) Date: Tue, 13 Oct 2015 06:50:43 -0700 Message-ID: From: ronald comaling To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a1143616470d6a00521fcbb05 Archived-At: Subject: [OAUTH-WG] (no subject) 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, 13 Oct 2015 13:50:47 -0000 --001a1143616470d6a00521fcbb05 Content-Type: text/plain; charset=UTF-8 Reply http://about.me/ronaldo_comaling --001a1143616470d6a00521fcbb05 Content-Type: text/html; charset=UTF-8

Reply

http://about.me/ronaldo_comaling

--001a1143616470d6a00521fcbb05-- From nobody Tue Oct 13 06:51:27 2015 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 D13531B3F88 for ; Tue, 13 Oct 2015 06:51:25 -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 b5Xd-c-xB-le for ; Tue, 13 Oct 2015 06:51:24 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA3C1B3FA2 for ; Tue, 13 Oct 2015 06:51:18 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so90355836wic.1 for ; Tue, 13 Oct 2015 06:51:17 -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 :content-type; bh=bkytyrOqrHPe6uRE8P3iMpbHvl+4U9ocXtg2sHgAc9s=; b=sqCvUNgDvcO0UIztWeseoAkvwkfmx5pqVuvj4UzMDX0vIg1rlcxT533mW9YtuEbV4N 3rFaSnuoTVdLBTZ2G0XO58RmQzbgN4zUkfcCyBJEavZmAvRKi8zLdc+wzvWGwI6+MUq4 HSvxDbs8q8lekl3M+knxXoh/vXIXMP2aZi/sxVHKgEVk41bflUzViiTh9V7VBtn82PYJ H0Tq2GnTzpU7HQIfmCq9QZVZb9n4r/nvuSHo5zWUargWH901YrR1C30mDMHI2yWlYslR AtXvYEfWLfhJ0QdOfbiVu4YrpTNBFLDraCC9m3L1jcn/YwUco+z/rjmmdpAnfukmNwSB t9BA== MIME-Version: 1.0 X-Received: by 10.180.106.4 with SMTP id gq4mr22619550wib.53.1444744240318; Tue, 13 Oct 2015 06:50:40 -0700 (PDT) Received: by 10.27.125.70 with HTTP; Tue, 13 Oct 2015 06:50:40 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Oct 2015 09:50:40 -0400 Message-ID: From: Ofer Nave To: "" Content-Type: multipart/alternative; boundary=f46d0443069c3c5d930521fcbbde Archived-At: Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination 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, 13 Oct 2015 13:51:26 -0000 --f46d0443069c3c5d930521fcbbde Content-Type: text/plain; charset=UTF-8 BTW -- I'd like to say I'm very pleasantly surprised by the quantity, quality, and speediness of all your responses. I assumed this list was low-attention based on glancing at the archives, but maybe that's just because ya'll already know everything you need to know and noobs are rare. :) -ofer On Tue, Oct 13, 2015 at 12:13 AM, Ofer Nave wrote: > I know the OAuth 2.0 RFC doesn't specify any standards for coordination > between the Authorization Server and the Resource Server, as it's generally > assumed that both will be owned or operated by the same entity. > > However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a > feature to make it easy for other API developers to delegate to me the > responsibility of handling the auth grant process and issuing access tokens. > > It seems to me that a simple version of this could be easily done by: > > 1) Defining an Access Token format that contains within it everything a > Resource Server will need to validate it and determine the level of access > granted (list of scopes, expiration datetime, HMAC signature using a shared > secret). > > 2) Providing a means (basic web UI) for Resource Server owners to register > a set of scopes for their service, along with user-understandable > descriptions of each to display when they arrive at my Authorization > Endpoint. > > While I've read the relevant RFCs, I'm new to the OAuth domain, and would > appreciate any feedback. Is this a stupid idea? Is this a good idea, but > redundant with another standard I'm not aware of? > > -ofer > --f46d0443069c3c5d930521fcbbde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
BTW -- I'd like to say I'm very pleasantly su= rprised by the quantity, quality, and speediness of all your responses.=C2= =A0 I assumed this list was low-attention based on glancing at the archives= , but maybe that's just because ya'll already know everything you n= eed to know and noobs are rare.=C2=A0 :)

-ofer

On Tue, Oct 13, 2015 at= 12:13 AM, Ofer Nave <odigity@gmail.com> wrote:
I know= the OAuth 2.0 RFC doesn't specify any standards for coordination betwe= en the Authorization Server and the Resource Server, as it's generally = assumed that both will be owned or operated by the same entity.

However, I'm building an OAuth 2.0 Auth Server, and I'd like to a= dd a feature to make it easy for other API developers to delegate to me the= responsibility of handling the auth grant process and issuing access token= s.

It seems to me that a simple version of this could be easil= y done by:

1) Defining an Access Token format that contains wi= thin it everything a Resource Server will need to validate it and determine= the level of access granted (list of scopes, expiration datetime, HMAC sig= nature using a shared secret).

2) Providing a means (basic web= UI) for Resource Server owners to register a set of scopes for their servi= ce, along with user-understandable descriptions of each to display when the= y arrive at my Authorization Endpoint.

While I've read the= relevant RFCs, I'm new to the OAuth domain, and would appreciate any f= eedback. Is this a stupid idea?=C2=A0 Is this a good idea, but redundant wi= th another standard I'm not aware of?

-ofer

--f46d0443069c3c5d930521fcbbde-- From nobody Tue Oct 13 07:43:54 2015 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 DBE4F1B44DD for ; Tue, 13 Oct 2015 07:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vY3rEYBCZDDJ for ; Tue, 13 Oct 2015 07:43:51 -0700 (PDT) Received: from nm33-vm7.bullet.mail.bf1.yahoo.com (nm33-vm7.bullet.mail.bf1.yahoo.com [72.30.239.207]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BEF71B44E1 for ; Tue, 13 Oct 2015 07:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1444747429; bh=Frnoh9xHVsfUGt3DwvFGeRYrAhraZOlrju3Qv+PFqmw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=jX/i20gKlFz2q8wOX6WV8bBZz1GXpzXcF27x5BpD4dBImZlisZmUmCFRoVgMU4jQeeLG1GMi8bE9NVCWzJ/SRH7jsMkPKAQ/dBg/AGC5aHl1YAFla5/SFbSI+8jlCvEvlaBsOXAQruePhdmEZUyPh/kitbhb+Cc/vT/wkUu7Jef6XpgFe7pZjA7WGTBWvmOQmay3BQJ9fVsz21Y81SOFWbbH/I+AcAwzU2iGS+hV6+55SIIW7ADXMOSWAscAAWWzB8AHKT0yjnCZeNIuzbGuaRWwpA5LeMOVLh5AyTRrxjBu2Qb4NXq+O+QDoMwO2uSkBTPW1+NHDdK63kQqE6crAQ== Received: from [98.139.170.178] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 13 Oct 2015 14:43:49 -0000 Received: from [98.139.212.247] by tm21.bullet.mail.bf1.yahoo.com with NNFMP; 13 Oct 2015 14:43:49 -0000 Received: from [127.0.0.1] by omp1056.mail.bf1.yahoo.com with NNFMP; 13 Oct 2015 14:43:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 989294.1962.bm@omp1056.mail.bf1.yahoo.com X-YMail-OSG: DEZhbJcVM1l2y0hnUdogXuxPXxL7IRrDcDokjxuBDDH1sINfcs03htzZRHqcGs. TuJHuNh3Gm3BPObuBHrJC6DgDaYAzzJvtu6BwZrodAYdS122qf_fw2KhfU_A7JuBTn6vKNsd_bKh HtUHZgoB07ES_eYC7IyEAZMHqphLag8FQQoEG3WjVVuPIQLHq5Dz8Uk9Ik1_V4RmFkLngYBfS2Mi FOICcN_C_4HZ.7mhevcGcrtnnvLYBXc2yrjlQGQ_82i8vNeWHRJDxbBU4LZcPGjKPqhABe_JfB3J KjmkWtEeA0HeVFXc1e4s4o6nt7LFn4TZy6Emnh6TjZR_zBaVzmKLCCHOgSgi0DrFEBZazYUr3Fgv vmqvQW3j2lGPxNY0xi6G15AjKdBtce9rE7_gHCnnep2dBUcCPc89u_A7hdjXuWfkW1TNUgxo7KgL SC_5kjLoqjqU716VH.2hv5pwKc1ZjS0ycfMRG4lTXwMD.rsCbE8lr5FDa6mXS5eyv0lNhQ1_NDUH HyDMOwtTfzDVv4PUoS_Hw1oXWf0g0.F_N3KztosTF8AvhspsG0DfV9sN.vI0uS40- Received: by 76.13.26.66; Tue, 13 Oct 2015 14:43:48 +0000 Date: Tue, 13 Oct 2015 14:43:48 +0000 (UTC) From: Bill Mills To: Jim Manico , Ofer Nave Message-ID: <1486213736.2998244.1444747428107.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <751A2989-38CD-4360-A691-980AA8DE58A8@manicode.com> References: <751A2989-38CD-4360-A691-980AA8DE58A8@manicode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2998243_1006340133.1444747428103" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination 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: Tue, 13 Oct 2015 14:43:54 -0000 ------=_Part_2998243_1006340133.1444747428103 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Centralizing the user auth yes, it doesn't even have to be multiple types o= f RS for this to win. =C2=A0It reduces your attack surface and allows your = auth stack to be separate from your app stack are two of the good things. = =C2=A0Auth is a specialized thing and hard to do right, and pulling it down= to a much smaller pool of machines than your main application servers lets= you more easily see and deal with abuse.=20 On Monday, October 12, 2015 9:36 PM, Jim Manico wro= te: =20 This seems like a reasonable approach. Isn't the whole idea of the auth se= rver/resource server separation in OAuth 2.0 so that one auth server can go= vern multiple resource servers? -- Jim Manico @Manicode > On Oct 13, 2015, at 6:13 AM, Ofer Nave wrote: >=20 > I know the OAuth 2.0 RFC doesn't specify any standards for coordination b= etween the Authorization Server and the Resource Server, as it's generally = assumed that both will be owned or operated by the same entity. >=20 > However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a fea= ture to make it easy for other API developers to delegate to me the respons= ibility of handling the auth grant process and issuing access tokens. >=20 > It seems to me that a simple version of this could be easily done by: >=20 > 1) Defining an Access Token format that contains within it everything a R= esource Server will need to validate it and determine the level of access g= ranted (list of scopes, expiration datetime, HMAC signature using a shared = secret). >=20 > 2) Providing a means (basic web UI) for Resource Server owners to registe= r a set of scopes for their service, along with user-understandable descrip= tions of each to display when they arrive at my Authorization Endpoint. >=20 > While I've read the relevant RFCs, I'm new to the OAuth domain, and would= appreciate any feedback. Is this a stupid idea?=C2=A0 Is this a good idea,= but redundant with another standard I'm not aware of? >=20 > -ofer > _______________________________________________ > 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 ------=_Part_2998243_1006340133.1444747428103 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Centralizing the user auth yes, = it doesn't even have to be multiple types of RS for this to win.  It r= educes your attack surface and allows your auth stack to be separate from y= our app stack are two of the good things.  Auth is a specialized thing= and hard to do right, and pulling it down to a much smaller pool of machin= es than your main application servers lets you more easily see and deal wit= h abuse.



On Monday, October 1= 2, 2015 9:36 PM, Jim Manico <jim@manicode.com> wrote:

This seems like a reasonable approach. Isn't the whole idea of th= e auth server/resource server separation in OAuth 2.0 so that one auth serv= er can govern multiple resource servers?

--
Jim Manico
@Manicode

> On Oct 13, 2015, at 6:13 AM, Ofer Nave <odigity@gmail.com> wrote:
>
> I know the OAuth 2.0 RFC doesn't specify any standards for= coordination between the Authorization Server and the Resource Server, as = it's generally assumed that both will be owned or operated by the same enti= ty.
>
> However, I'm building an= OAuth 2.0 Auth Server, and I'd like to add a feature to make it easy for o= ther API developers to delegate to me the responsibility of handling the au= th grant process and issuing access tokens.
>
> It seems to me that a simple version of this could be easil= y done by:
>
> 1) Defining an Ac= cess Token format that contains within it everything a Resource Server will= need to validate it and determine the level of access granted (list of sco= pes, expiration datetime, HMAC signature using a shared secret).
>
> 2) Providing a means (basic web UI) = for Resource Server owners to register a set of scopes for their service, a= long with user-understandable descriptions of each to display when they arr= ive at my Authorization Endpoint.
>
> While I've read the relevant RFCs, I'm new to the OAuth domain, and w= ould appreciate any feedback. Is this a stupid idea?  Is this a good i= dea, but redundant with another standard I'm not aware of?
>
> -ofer
> _______________= ________________________________
> OAuth mailing list<= br clear=3D"none">> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


______= _________________________________________
OAuth mailing l= ist
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


------=_Part_2998243_1006340133.1444747428103-- From nobody Tue Oct 13 09:04:33 2015 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 E874D1B47EB for ; Tue, 13 Oct 2015 09:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=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 7aXlUgeXOnTA for ; Tue, 13 Oct 2015 09:04:29 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6681B47E6 for ; Tue, 13 Oct 2015 09:04:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id E90C39655754; Tue, 13 Oct 2015 09:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_2GHDbC451V; Tue, 13 Oct 2015 09:04:27 -0700 (PDT) Received: from [192.168.168.101] (unknown [192.168.168.101]) by mail.promanage-inc.com (Postfix) with ESMTPS id D4EE99655737; Tue, 13 Oct 2015 09:04:27 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_EBD40FB5-A4BF-43B4-8315-09C54D25845F" From: Eve Maler In-Reply-To: Date: Tue, 13 Oct 2015 09:04:27 -0700 Message-Id: <41395617-E5A9-4294-9F8B-DFE9E27F74F8@xmlgrrl.com> References: To: Thomas Broyer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination 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, 13 Oct 2015 16:04:32 -0000 --Apple-Mail=_EBD40FB5-A4BF-43B4-8315-09C54D25845F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Thomas=E2=80=94 The UMA Work Group that produced the =E2=80=9CRSR=E2=80= =9D (OAuth Resource Set Registration) spec has an outstanding issue to = fix the BCP190 issue that you point out. Since it=E2=80=99s a = backwards-incompatible change, and we are taking a semantic versioning = approach, we need to plot it out appropriately. We certainly welcome = other comments. The V1.0.1 draft spec is currently in a public review = period , = closing Nov 2. (Small tweak to Justin=E2=80=99s note: This spec is meant not to be = specific to UMA, but rather to be potentially usable for =E2=80=9Cvanilla=E2= =80=9D OAuth and OpenID Connect as well.) Eve > On 13 Oct 2015, at 2:10 AM, Thomas Broyer wrote: >=20 >=20 >=20 > On Tue, Oct 13, 2015 at 6:14 AM Ofer Nave > wrote: > I know the OAuth 2.0 RFC doesn't specify any standards for = coordination between the Authorization Server and the Resource Server, = as it's generally assumed that both will be owned or operated by the = same entity. >=20 > However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a = feature to make it easy for other API developers to delegate to me the = responsibility of handling the auth grant process and issuing access = tokens. >=20 > It seems to me that a simple version of this could be easily done by: >=20 > 1) Defining an Access Token format that contains within it everything = a Resource Server will need to validate it and determine the level of = access granted (list of scopes, expiration datetime, HMAC signature = using a shared secret). >=20 > Either that (and I'd use JWT then, as already proposed) or have = resource servers introspect tokens = > (the = latter doesn't preclude the former, but the format of the token is then = just an implementation detail of the AS that the RS doesn't need to = know). > One advantage of requiring introspection is the easy support of = revocation without having to create a specific API to check whether a = token is revoked: you just introspect the token and directly know = whether the token is valid or not, and if it's valid you get its details = (and have the RS cache the response for a few seconds/minutes to avoid = overloading the introspection endpoint). That being said, RS knowing the = tokens are JWTs allows them to reject invalid tokens (expired, invalid = signature, unexpected issuer, etc.) without the need to check for = revocation at the AS. > =20 > 2) Providing a means (basic web UI) for Resource Server owners to = register a set of scopes for their service, along with = user-understandable descriptions of each to display when they arrive at = my Authorization Endpoint. >=20 > Either a Web UI, or an API = > (I'm = not a fan of this draft, and it incidentally violates IETF's BCP190 = https://tools.ietf.org/html/bcp190 , = but I think it's a good source of inspiration) > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | = Calendar: xmlgrrl@gmail.com --Apple-Mail=_EBD40FB5-A4BF-43B4-8315-09C54D25845F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Thomas=E2=80=94 The UMA Work Group that = produced the =E2=80=9CRSR=E2=80=9D (OAuth Resource Set Registration) = spec has an outstanding issue to fix the BCP190 issue that you point = out. Since it=E2=80=99s a backwards-incompatible change, and we are = taking a semantic versioning approach, we need to plot it out = appropriately. We certainly welcome other comments. The V1.0.1 draft = spec is currently in a public review period, closing Nov 2.

(Small tweak to = Justin=E2=80=99s note: This spec is meant not to be specific to UMA, but = rather to be potentially usable for =E2=80=9Cvanilla=E2=80=9D OAuth and = OpenID Connect as well.)

= Eve

On 13 Oct 2015, at 2:10 AM, Thomas Broyer = <t.broyer@gmail.com> wrote:



On Tue, Oct 13, 2015 at 6:14 AM Ofer Nave <odigity@gmail.com> = wrote:
I know the OAuth 2.0 RFC doesn't specify any standards for = coordination between the Authorization Server and the Resource Server, = as it's generally assumed that both will be owned or operated by the = same entity.

However, I'm building an = OAuth 2.0 Auth Server, and I'd like to add a feature to make it easy for = other API developers to delegate to me the responsibility of handling = the auth grant process and issuing access tokens.

It seems to me that a simple version of this could be = easily done by:

1) Defining an Access = Token format that contains within it everything a Resource Server will = need to validate it and determine the level of access granted (list of = scopes, expiration datetime, HMAC signature using a shared secret).

Either that (and I'd use JWT then, as = already proposed) or have resource servers introspect tokens <https://tools.ietf.org/html/draft-ietf-oauth-introspection-11> (the latter doesn't preclude the former, but the format of the = token is then just an implementation detail of the AS that the RS = doesn't need to know).
One advantage of requiring = introspection is the easy support of revocation without having to create = a specific API to check whether a token is revoked: you just introspect = the token and directly know whether the token is valid or not, and if = it's valid you get its details (and have the RS cache the response for a = few seconds/minutes to avoid overloading the introspection endpoint). = That being said, RS knowing the tokens are JWTs allows them to reject = invalid tokens (expired, invalid signature, unexpected issuer, etc.) = without the need to check for revocation at the AS.
 
2) = Providing a means (basic web UI) for Resource Server owners to register = a set of scopes for their service, along with user-understandable = descriptions of each to display when they arrive at my Authorization = Endpoint.
Either a Web UI, or an API <https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-0= 6> (I'm not a fan of this draft, and it incidentally violates = IETF's BCP190 https://tools.ietf.org/html/bcp190, but I think it's a = good source of inspiration)
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Eve Maler | cell +1 425.345.6756 = | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

= --Apple-Mail=_EBD40FB5-A4BF-43B4-8315-09C54D25845F-- From nobody Tue Oct 13 10:42:53 2015 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 784101A0107 for ; Tue, 13 Oct 2015 10:42:52 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 nRu1HMR6PLzD for ; Tue, 13 Oct 2015 10:42:51 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064DD1A0105 for ; Tue, 13 Oct 2015 10:42:50 -0700 (PDT) Received: from speedyM.local ([86.81.21.110]) by smtp-cloud2.xs4all.net with ESMTP id Uhik1r00Q2NWRDy01himpR; Tue, 13 Oct 2015 19:42:49 +0200 To: oauth@ietf.org From: Mark Dobrinic X-Enigmail-Draft-Status: N1110 Message-ID: <561D4294.8070708@cozmanova.com> Date: Tue, 13 Oct 2015 19:42:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] client_id format: whitespaces allowed? 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, 13 Oct 2015 17:42:52 -0000 Hey OAuth group, While I though I knew this, I was looking closely at the OAuth 2.0 spec and read that valid values of the client_id are specified as: VSCHAR = %x20-7E client-id = *VSCHAR This means that the client-id may also contain whitespace characters. Do I get that right? Thanks for your insights, Mark From nobody Tue Oct 13 11:07:43 2015 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 97E551A0398 for ; Tue, 13 Oct 2015 11:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 DtQJ5yp2P9xk for ; Tue, 13 Oct 2015 11:07:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F49F1A0379 for ; Tue, 13 Oct 2015 11:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L9lxQmUWruCT8I4GjsFAwLW22K4kYb5QISxKBnijq9U=; b=Hzk3ISPIKiKbuzdeFhjNNEqxfPUeo1tHrWjYlG+VsTk1gfjwTREiSGRGOsbZxJCagv6ovz7z+mjvExMMb1R8ZID4QN2sOwZYTrXwohfERoVN+JHHBtaWP3M4+uOV0Tb6cnenzF1Ix/5nkKQpzgRmBkw9xN4IuKdE2EyKHApCSAY= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.293.16; Tue, 13 Oct 2015 18:07:35 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0293.007; Tue, 13 Oct 2015 18:07:35 +0000 From: Mike Jones To: Mark Dobrinic , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] client_id format: whitespaces allowed? Thread-Index: AQHRBd6a05eCCdbcZkSaEh8/+Un7zJ5pt8WQ Date: Tue, 13 Oct 2015 18:07:35 +0000 Message-ID: References: <561D4294.8070708@cozmanova.com> In-Reply-To: <561D4294.8070708@cozmanova.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:7::4af] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:KVtWyCp73lIS9DEkTXz6U9gK1YEBjprjMATUDpfHrVF8x/gh3Yk7/fLT1Hr1RfnMnf3mGBIUca8kwbxib+ws7hCrzn/9+hxSK3C0Nve0cociQ1VFJr2e6w7sUtPz7xYpaDbsUq0Z0q8phbdYNJlxFQ==; 24:vCYN701dQ0ogkjVMQ1WlaV8di3dvJrztsOz98tb1lZP9vD4z6V5zVPngk2EFaRbg3D8EMf69loyuyJ20JkWXrJ40B15n5Eo3tftHTWEJiIY=; 20:udK5WTkgYPrdH8G0+1d8nTAAYePXTAIMbLMmh2+gkSFx230quCSzsLhtsHaq8l45krkr1SKZgEZ/Ylk476fg5g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(61426024)(61427024); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 07283408BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(377454003)(199003)(106356001)(101416001)(189998001)(5002640100001)(107886002)(5001960100002)(122556002)(5005710100001)(10090500001)(87936001)(5008740100001)(10400500002)(86362001)(86612001)(106116001)(40100003)(33656002)(2501003)(10290500002)(99286002)(76176999)(97736004)(105586002)(81156007)(5007970100001)(74316001)(2900100001)(5001770100001)(50986999)(2950100001)(54356999)(102836002)(5001920100001)(92566002)(77096005)(5003600100002)(15975445007)(5004730100002)(46102003)(19580395003)(64706001)(76576001)(8990500004)(19580405001)(11100500001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2015 18:07:35.3059 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: Re: [OAUTH-WG] client_id format: whitespaces allowed? 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, 13 Oct 2015 18:07:41 -0000 It can contain space (%x20) but not tab, carriage return, linefeed, form fe= ed, vertical tab, backspace, delete (or any other control characters). -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mark Dobrinic Sent: Tuesday, October 13, 2015 10:43 AM To: oauth@ietf.org Subject: [OAUTH-WG] client_id format: whitespaces allowed? Hey OAuth group, While I though I knew this, I was looking closely at the OAuth 2.0 spec and= read that valid values of the client_id are specified as: VSCHAR =3D %x20-7E client-id =3D *VSCHAR This means that the client-id may also contain whitespace characters. Do I get that right? Thanks for your insights, Mark _______________________________________________ OAuth mailing list OAuth@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7cMichael.Jones%40microsof= t.com%7c459786d9bc6849cb85e908d2d3f5bafd%7c72f988bf86f141af91ab2d7cd011db47= %7c1&sdata=3D2PQxSCLiBAtkCozNPfz8tW26FS4XE80nsj5nnvc9mFU%3d From nobody Wed Oct 14 21:52:57 2015 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 0B1C61B305D for ; Wed, 14 Oct 2015 21:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.609 X-Spam-Level: ** X-Spam-Status: No, score=2.609 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 szW_IJGhRVmW for ; Wed, 14 Oct 2015 21:52:47 -0700 (PDT) Received: from nrifs01.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2611B3052 for ; Wed, 14 Oct 2015 21:52:46 -0700 (PDT) Received: from nriea02.index.or.jp (unknown [172.19.246.37]) by nrifs01.index.or.jp (Postfix) with SMTP id C2DBD77EE9; Thu, 15 Oct 2015 13:52:45 +0900 (JST) Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea02.index.or.jp (unknown) with ESMTP id t9F4qj0W024494; Thu, 15 Oct 2015 13:52:45 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t9F4qjq5062708; Thu, 15 Oct 2015 13:52:45 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id t9F4qjHo062707; Thu, 15 Oct 2015 13:52:45 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf14.index.or.jp ([172.100.25.23]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t9F4qjE2062704; Thu, 15 Oct 2015 13:52:45 +0900 From: "Nat Sakimura" To: "'Jim Manico'" References: <00c001d10233$debc8720$9c359560$@nri.co.jp> <8BA8D241-67FF-4DD2-AA01-DF007D8916B0@manicode.com> <190D3129-645A-4267-A3FC-215AFE71DE38@manicode.com> In-Reply-To: <190D3129-645A-4267-A3FC-215AFE71DE38@manicode.com> Date: Thu, 15 Oct 2015 13:52:46 +0900 Message-ID: <01a701d10705$55aa9a90$00ffcfb0$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A8_01D10750.C595EC10" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIXN1KCYSLJRI30MmS0aTS8lpF7xwGnHHEzAU3gH3QB+2z5CZ24GAkQ Content-Language: ja x-mailadviser: 20150401 Archived-At: Cc: 'oauth' Subject: Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request 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, 15 Oct 2015 04:52:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A8_01D10750.C595EC10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That=E2=80=99s true, but RFC6749 uses the term Authorization request to = mean the request sent to the authorization endpoint.=20 =20 See 4.1.1, 4.2.1, 4.3.1, 4.4.1 of RFC6749.=20 =20 Best,=20 =20 --=20 Nat Sakimura < n-sakimura@nri.co.jp> Nomura Research Institute, Ltd.=20 =20 PLEASE READ: The information contained in this e-mail is confidential and intended = for the named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby = notified that any review, dissemination, distribution or duplication of = this message is strictly prohibited. If you have received this message = in error, please notify the sender immediately and delete your copy from = your system. =20 From: Jim Manico [mailto:jim@manicode.com]=20 Sent: Saturday, October 10, 2015 12:28 AM To: Nat Sakimura Cc: oauth Subject: Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization = Request =20 But its all authorization, even the token request.... -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 On Oct 9, 2015, at 5:23 PM, Nat Sakimura > wrote: The reason for saying authorization request is that there are two types = of requests in RFC6749; authorization request and token request. This = draft deals with the former and thus named JAR. =20 =20 Nat 2015=E5=B9=B410=E6=9C=889=E6=97=A5=E9=87=91=E6=9B=9C=E6=97=A5=E3=80=81Jim= Manico = >=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=97=E3=81=9F= : The word authorization is implied by OAuth, consider "OAuth 2.0 JWT = Request". -- Jim Manico @Manicode (808) 652-3805 On Oct 9, 2015, at 3:43 AM, Nat Sakimura > wrote: Hi OAuthers:=20 =20 One of the to do for = https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05 is to come up = with a better title.=20 The current title =E2=80=9COAuth 2.0 JWT Authorization Request = (JAR)=E2=80=9D, is somewhat better than what it used to be, but if you = can suggest a better name, I am all for it.=20 Please let me know if you have an idea.=20 Best,=20 --=20 Nat Sakimura < = n-sakimura@nri.co.jp> Nomura Research Institute, Ltd.=20 =20 PLEASE READ: The information contained in this e-mail is confidential and intended = for the named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby = notified that any review, dissemination, distribution or duplication of = this message is strictly prohibited. If you have received this message = in error, please notify the sender immediately and delete your copy from = your system. =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en ------=_NextPart_000_01A8_01D10750.C595EC10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

T= hat=E2=80=99s true, but RFC6749 uses the term Authorization request to = mean the request sent to the authorization endpoint. =

<= o:p> 

S= ee 4.1.1, 4.2.1, 4.3.1, 4.4.1 of RFC6749.

<= o:p> 

B= est,

<= o:p> 

-- =

Nat Sakimura = <n-sakimura@nri.co.jp= >

Nomura Research = Institute, Ltd.

 

PLEASE = READ:

The information = contained in this e-mail is confidential and intended for the named = recipient(s) only.

If you are not an = intended recipient of this e-mail, you are hereby notified that any = review, dissemination, distribution or duplication of this message is = strictly prohibited. If you have received this message in error, please = notify the sender immediately and delete your copy from your = system.

<= o:p> 

From:<= /b> Jim Manico = [mailto:jim@manicode.com]
Sent: Saturday, October 10, 2015 = 12:28 AM
To: Nat Sakimura = <n-sakimura@nri.co.jp>
Cc: oauth = <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Better title = for OAuth 2.0 JWT Authorization = Request

 

But its all = authorization, even the token request....

--

Jim = Manico

@Manicode

Secure Coding = Education

+1 (808) 652-3805


On Oct 9, 2015, at 5:23 PM, Nat Sakimura <n-sakimura@nri.co.jp> = wrote:

The reason for saying authorization = request is that there are two types of requests in RFC6749; = authorization request and token request. This draft deals with the = former and thus named JAR.  

 

Nat


2015=E5=B9=B410=E6=9C=889=E6=97=A5=E9=87=91=E6=9B=9C=E6=97=A5=E3=80=81Jim Manico<jim@manicode.com>=E3=81=95= =E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=97=E3=81=9F:

The word authorization = is implied by OAuth, consider "OAuth 2.0 JWT = Request".

--

Jim = Manico

@Manicode

(808) = 652-3805


On Oct 9, 2015, at = 3:43 AM, Nat Sakimura <n-sakimura@nri.co.jp> = wrote:

Hi OAuthers:

 

One of the to do for https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05<= /a> is to come up with a better title.

The current title =E2=80=9COAuth 2.0 JWT Authorization Request (JAR)=E2=80=9D, is somewhat better = than what it used to be, but if you can suggest a better name, I am all = for it.

Please let me know if you have = an idea.

Best,

--

Nat Sakimura <n-sakimura@nri.co.jp>

Nomura Research Institute, Ltd. =

 

PLEASE READ:

The information contained in this = e-mail is confidential and intended for the named recipient(s) = only.

If you are not an intended = recipient of this e-mail, you are hereby notified that any review, = dissemination, distribution or duplication of this message is strictly = prohibited. If you have received this message in error, please notify = the sender immediately and delete your copy from your = system.

 

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



--
Nat Sakimura = (=3Dnat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en

------=_NextPart_000_01A8_01D10750.C595EC10-- From nobody Wed Oct 14 22:37:32 2015 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 F123E1B307B for ; Wed, 14 Oct 2015 22:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 rBfSCAk4bIMT for ; Wed, 14 Oct 2015 22:37:29 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBCF1B2B59 for ; Wed, 14 Oct 2015 22:37:29 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so256646399wic.1 for ; Wed, 14 Oct 2015 22:37:27 -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=aOyQjcGcYTfJFKPgPb/Ece5+nOqyHvABCOO8IWaMK2s=; b=AyJEuFDG2PYsf0nVZV0SodiIje3TD3yd2XbYhMm6aE/3i2v06HbhK9kzxIUorQ1nPZ 9ctVC6TJViA9YsdyOcCCrKKk+cvmUhrwYIBC/X24UgxkRIXQwTjK83PUEF2PXIT0atXR xvWzBlfgvWbIdRDT4Y840h5YawaTNM89D28sDcKFMeoQHFFQLnd/ev/9u0zK6siMsng3 5PdaRfGSXKuvwdazdOUERp9IwCMdH0SZAEUz8rkmEKon5OTdMFFbCkK/L1WxQsTMcbhi VBUXi0JOZ/oenqyl9Zti2nsxIZEKBre56M5a11lXoNGe0A4PjYhNF37Yx+M0hROsD0D3 JBLw== X-Gm-Message-State: ALoCoQk9dPujfnDTWlk/wExpxMjnJh1GnQtJOqjDDyDy+JL4c7bfCA6UBe1+A+1qJNH1XXSp1inE X-Received: by 10.194.83.103 with SMTP id p7mr9615364wjy.73.1444887447658; Wed, 14 Oct 2015 22:37:27 -0700 (PDT) Received: from [192.168.2.17] (ip5456cfcc.speed.planet.nl. [84.86.207.204]) by smtp.gmail.com with ESMTPSA id vh4sm7082319wjc.10.2015.10.14.22.37.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Oct 2015 22:37:26 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A5D861A5-1A4B-42A2-A303-39B872CCF751 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (13A452) In-Reply-To: <01a701d10705$55aa9a90$00ffcfb0$@nri.co.jp> Date: Thu, 15 Oct 2015 07:37:26 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <00c001d10233$debc8720$9c359560$@nri.co.jp> <8BA8D241-67FF-4DD2-AA01-DF007D8916B0@manicode.com> <190D3129-645A-4267-A3FC-215AFE71DE38@manicode.com> <01a701d10705$55aa9a90$00ffcfb0$@nri.co.jp> To: Nat Sakimura Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request 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, 15 Oct 2015 05:37:32 -0000 --Apple-Mail-A5D861A5-1A4B-42A2-A303-39B872CCF751 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok then it looks like the name is good as is. :) -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On Oct 15, 2015, at 6:52 AM, Nat Sakimura wrote: >=20 > That=E2=80=99s true, but RFC6749 uses the term Authorization request to me= an the request sent to the authorization endpoint. > =20 > See 4.1.1, 4.2.1, 4.3.1, 4.4.1 of RFC6749. > =20 > Best, > =20 > -- > Nat Sakimura > Nomura Research Institute, Ltd. > =20 > PLEASE READ: > The information contained in this e-mail is confidential and intended for t= he named recipient(s) only. > If you are not an intended recipient of this e-mail, you are hereby notifi= ed that any review, dissemination, distribution or duplication of this messa= ge is strictly prohibited. If you have received this message in error, pleas= e notify the sender immediately and delete your copy from your system. > =20 > From: Jim Manico [mailto:jim@manicode.com]=20 > Sent: Saturday, October 10, 2015 12:28 AM > To: Nat Sakimura > Cc: oauth > Subject: Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Reque= st > =20 > But its all authorization, even the token request.... >=20 > -- > Jim Manico > @Manicode > Secure Coding Education > +1 (808) 652-3805 >=20 > On Oct 9, 2015, at 5:23 PM, Nat Sakimura wrote: >=20 > The reason for saying authorization request is that there are two types of= requests in RFC6749; authorization request and token request. This draft de= als with the former and thus named JAR. =20 > =20 > Nat >=20 > 2015=E5=B9=B410=E6=9C=889=E6=97=A5=E9=87=91=E6=9B=9C=E6=97=A5=E3=80=81Jim M= anico=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE= =E3=81=97=E3=81=9F: > The word authorization is implied by OAuth, consider "OAuth 2.0 JWT Reques= t". >=20 > -- > Jim Manico > @Manicode > (808) 652-3805 >=20 > On Oct 9, 2015, at 3:43 AM, Nat Sakimura wrote: >=20 > Hi OAuthers: > =20 > One of the to do for https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-0= 5 is to come up with a better title. > The current title =E2=80=9COAuth 2.0 JWT Authorization Request (JAR)=E2=80= =9D, is somewhat better than what it used to be, but if you can suggest a be= tter name, I am all for it. >=20 > Please let me know if you have an idea. >=20 > Best, > -- > Nat Sakimura > Nomura Research Institute, Ltd. > =20 > PLEASE READ: > The information contained in this e-mail is confidential and intended for t= he named recipient(s) only. > If you are not an intended recipient of this e-mail, you are hereby notifi= ed that any review, dissemination, distribution or duplication of this messa= ge is strictly prohibited. If you have received this message in error, pleas= e notify the sender immediately and delete your copy from your system. > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en --Apple-Mail-A5D861A5-1A4B-42A2-A303-39B872CCF751 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ok then it looks like the name is good= as is. :)

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

On O= ct 15, 2015, at 6:52 AM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:

That=E2=80=99= s true, but RFC6749 uses the term Authorization request to mean the request s= ent to the authorization endpoint.

 

See 4.1.1, 4.2.1, 4.3.1, 4.4.1 of RFC67= 49.

 

Be= st,

 

--

Nat Sakimura <n-sakimura@nri.co= .jp>

Nomura Research Institute, Ltd. <= o:p>

 

PL= EASE READ:

The information contained in this= e-mail is confidential and intended for the named recipient(s) only.

If you are not an intended recipient of this e-mail= , you are hereby notified that any review, dissemination, distribution or du= plication of this message is strictly prohibited. If you have received this m= essage in error, please notify the sender immediately and delete your copy f= rom your system.

 

From: Jim Manico [mailto:jim@manicode.com]
Sent:<= /b> Saturday, October 10, 2015 12:28 AM
To: Nat Sakimura <n-sakimura@nri.co.jp>
Cc: oauth <oauth@ietf.org>
S= ubject: Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Requ= est

 

But its all authorization, even the tok= en request....

--

Jim Manico

@Manicode

Secure Coding Education

+1 (808) 652-3805


On Oct 9, 2015, at 5:23 PM, Nat Sakim= ura <n-sakimura@nri.co.jp>= wrote:

The reaso= n for saying authorization request is that there are two types of requests i= n RFC6749; authorization request and token request. This draft deals with th= e former and thus named JAR.  

 

Nat


2015=E5=B9=B410=E6=9C=889=E6=97=A5=E9=87=91=E6=9B= =9C=E6=97=A5=E3=80=81Jim Manico<jim@manicode.com>=E3=81=95=E3=82=93=E3=81=AF=E6= =9B=B8=E3=81=8D=E3=81=BE=E3=81=97=E3=81=9F:<= /span>

The wo= rd authorization is implied by OAuth, consider "OAuth 2.0 JWT Request".=

--

Jim Man= ico

@Manicode

(808) 652-3805


On Oct 9= , 2015, at 3:43 AM, Nat Sakimura <n-sakimura@nri.co.jp> wro= te:

Hi OAuthers:

 

One of the to do for https://tools.ietf.org/html/draft-ietf-oa= uth-jwsreq-05 is to come up with a better title.

The current title =E2=80=9COAuth 2.0 JWT Autho= rization Request (JAR)=E2=80=9D, is somewhat better than what it used to be, but if you can sugge= st a better name, I am all for it.

Please let me k= now if you have an idea.

=

Best,

--

Nat Sakimura <n-sakimura@nri.co.jp>

Nomura Research Institute, Ltd.

 

PLEASE READ:

The information contained in this e-mail is confidential an= d intended for the named recipient(s) only.=

= If you are not an intended recipient of this e-mail, you are hereby notified= that any review, dissemination, distribution or duplication of this message= is strictly prohibited. If you have received this message in error, please n= otify the sender immediately and delete your copy from your system.

 =

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



--
Nat Sakimura (=3Dnat)
http://www.sakimura.or= g/en/
http:/= /twitter.com/_nat_en

= --Apple-Mail-A5D861A5-1A4B-42A2-A303-39B872CCF751-- From nobody Thu Oct 15 20:24:42 2015 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 1B7FF1B2DD7; Thu, 15 Oct 2015 20:24:39 -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 teQ9f2oXHHkb; Thu, 15 Oct 2015 20:24:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8781B2DDC; Thu, 15 Oct 2015 20:24:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151016032437.9268.17443.idtracker@ietfa.amsl.com> Date: Thu, 15 Oct 2015 20:24:37 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-06.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, 16 Oct 2015 03:24:39 -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 : OAuth 2.0 JWT Authorization Request Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-06.txt Pages : 16 Date : 2015-10-15 Abstract: The authorization request in RFC6749 utilizes query parameter serialization. This specification defines the authorization request using JWT serialization. The request is sent by value through "request" parameter or by reference through "request_uri" parameter that points to the JWT, allowing the request to be optionally signed and encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-06 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 Mon Oct 19 12:44:23 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 781ED1B2C5C; Mon, 19 Oct 2015 12:44:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019194405.8874.8793.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 12:44:05 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-04.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: Mon, 19 Oct 2015 19:44:05 -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 : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture Authors : Phil Hunt Justin Richer William Mills Prateek Mishra Hannes Tschofenig Filename : draft-ietf-oauth-pop-architecture-04.txt Pages : 22 Date : 2015-10-19 Abstract: The OAuth 2.0 bearer token specification, as defined in RFC 6750, allows any party in possession of a bearer token (a "bearer") to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens must to be protected from disclosure in transit and at rest. Some scenarios demand additional security protection whereby a client needs to demonstrate possession of cryptographic keying material when accessing a protected resource. This document motivates the development of the OAuth 2.0 proof-of-possession security mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-04 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 Mon Oct 19 12:46:51 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B43361A8A82; Mon, 19 Oct 2015 12:46:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019194620.19372.79982.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 12:46:20 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-02.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: Mon, 19 Oct 2015 19:46:20 -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 : OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution Authors : John Bradley Phil Hunt Michael B. Jones Hannes Tschofenig Filename : draft-ietf-oauth-pop-key-distribution-02.txt Pages : 18 Date : 2015-10-19 Abstract: RFC 6750 specified the bearer token concept for securing access to protected resources. Bearer tokens need to be protected in transit as well as at rest. When a client requests access to a protected resource it hands-over the bearer token to the resource server. The OAuth 2.0 Proof-of-Possession security concept extends bearer token security and requires the client to demonstrate possession of a key when accessing a protected resource. This document describes how the client obtains this keying material from the authorization server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-02 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 Mon Oct 19 12:47:48 2015 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 1E7541A8F3B for ; Mon, 19 Oct 2015 12:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 o-bMyjoly65F for ; Mon, 19 Oct 2015 12:47:25 -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 C1EC61A8F34 for ; Mon, 19 Oct 2015 12:47:20 -0700 (PDT) Received: from [192.168.131.140] ([80.92.122.73]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LpbfG-1aRTIu3d8Y-00fQbs for ; Mon, 19 Oct 2015 21:47:19 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <562548C5.4070705@gmx.net> Date: Mon, 19 Oct 2015 21:47:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gBccDUfbSo38rRdVDu34qucx7ugLT1P29" X-Provags-ID: V03:K0:raWbZn8PqCyJn7js4HMiJRKiqpFfs/AyCBn3PuKkA1t5C3MRPqc QS3wryO/bLT2fKYGFWKHnn2OhBIUGXfC/YKDq67ANHw4wMDtsuJzyDujaRlZAoHCX3LXELx BQrQ8364wla7TeceYvRU7svjfMHAkBhFQggROGF0dRicPyUgEnEz3q8EmjNa5l83vad+ONC 2VjzM4xLWlhqU/b/ysWHQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:J4mnWku2LTk=:uU6hgh2HDvaCQjfHdJMBw8 s6r9PARFN2hT32OPyMCh+/hYTAi5p/3ARI1b1dGnSIvk7OIRI90b97/ECcYvS1ZXXU0/qSnQN 9/v21OWSVSla5suiKt3WmndTaCXVwFqzZOba4mQppUl8BNkKat2o9r7e98KrQ+0wzjKZIxVf9 SkfPR5wRdU4XcW1UydT9TaBGQsps3moAw1NSCV/kvxgGpcZ1s+nYpgf7OBbZK9GueHCfIzeMe bP8RgvnUfQ+BKULqi/fuZxDugsz2ZFOobcz1S5oF1jlG7IxNSivjmKYXar878ZT0g0aY7OoTr LE+bfkRI3ZsqtrtvM8PwvEkxLhHYu/UD7uCxSZtu1NQtMeNbz8wjJDOMsWxC5bWOsFoJGMZo6 GqSxQko9m4i700DPNgX+Sp8ZiKvPvN6vATXphtAz21m+12GsFt8ZSVXlxiM9aw6MSVDfnBzVR AzBS7TOfLwwaT35vfOgsJMziFRhEb7+2jLB4SGV4trGyBH47MMrN5LxBSHe3YBoJe5ZSPzr+c CIFZvtXDDlAqv3yjjWuDBHrpJP2LWcGqayYUUGqRMH88txvvKCxKQjcDZ4txLZ9FVql4NSgcg 4YNA4f0fANZhsa/ONYA2IyrAKKc9boW5hkL2uV+w4V3Vpg6ika+FGezmcCiIo1b67w9CSjJKU kIimOhz+L5SkpR6022DMHarGIEM/r4qbtxwfHt24t4zeK6f/EEVLmD4dWlVSOkFYtqAz57IBp Bz/AhhubtEYPEcLnG3xlD9MhQH9BkKnWX39jyUeriQlBmMP5/taPd/bz5do= Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-02 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, 19 Oct 2015 19:47:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gBccDUfbSo38rRdVDu34qucx7ugLT1P29 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI: Refreshed the draft (since it expired last month); updated reference= s. --gBccDUfbSo38rRdVDu34qucx7ugLT1P29 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWJUjFAAoJEGhJURNOOiAtE+oIAKOFQaNqacBnNrIWfGmCMLuh VRlIWa6ynC1+CoB19PsRc0mepW/PVrgUl7YkdW0reeyZKuEYh62ph87kl9yJb9hD r9CH9z6LDAYF9/P6KdBPW24mojC2THC0yyEFlz86Reg5Hag6i5e3X/AjCfkOc1RR PgcRuVykiTTFD2TucKv9RQ7qSOC3PpOpDy14ZtRvDYCT/3aNKwQHOv2KhRFJuRD/ UjWRxafvevseAzih3VT01ZKrN21POEjdvMZU+osknhQdK0LqtFF2pmZz1mioNcne 1J7R6rHaBLK1v5lZyr7RyzxK2eQDpl2ticZNGSwLosFOFdxyChWpXoNdYv1LgB0= =UAo7 -----END PGP SIGNATURE----- --gBccDUfbSo38rRdVDu34qucx7ugLT1P29-- From nobody Mon Oct 19 12:50:14 2015 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 BB7571A8AB5 for ; Mon, 19 Oct 2015 12:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 27lmbzANUe4r for ; Mon, 19 Oct 2015 12:49:58 -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 E3A861A8AFD for ; Mon, 19 Oct 2015 12:49:57 -0700 (PDT) Received: from [192.168.131.140] ([80.92.122.73]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MXqV1-1a0ct90bOJ-00WmRg for ; Mon, 19 Oct 2015 21:49:56 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56254962.3010908@gmx.net> Date: Mon, 19 Oct 2015 21:49:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kM77aUIu4T35u8TskrumWwlW7MHmSdSjn" X-Provags-ID: V03:K0:bD1fzDEoBO/MEtzDlf1lww95Z95J1nkG2eTJsIEXFQISTvR+WFi I6GRbAPuz0c0Zwu9BehG1MkygyexFM9PFqFJG977vy9inNcgeGiP4465Vwfh+ePABczhTvm CKaLsbNWBuTpSuXClok7VnoS06Wn8W8gYwwPw9XfBj4gbBIpt48jPeeJOA11vNZSN1LyDAE TdfA7U4HrTnH4ri6mTs2A== X-UI-Out-Filterresults: notjunk:1;V01:K0:omij5VouS9o=:wN9au575WY2TsnKlODLil+ f0thFTbPQ79wcK5lGcrzBtAnekPwK7Eeg9dLCbqzBGwd0dcfQjYGljS3ztLLRl/m7R2rVaHRc bHXrlBYXJfwyzFNc1FCaSZPgxCQuj7Ibzz6CNpsi55wkkQNX+nZ5G7xhKl4GuXSc1aMeKMqz3 wELman3UQX+pV5AbTpwINe5/y337EHYVqWEw7xH2S1g7vr5wHrBecQ1/zYLXX38TGsoxMd0Fq 2ezGNqlssqn6vIjXsLlGsG+U3FVv+okde/GhhcBXQ79SoNm5NnXCtDt/c4N5dDf/slH1lGb6B 9UQZP/NG4zMEZMw9eIcfauBl1DOOLPjpC4Lj7VdVGbBRjfWpE/cAs+8CiPVjTEY7PdvG+0F2q CByfbK5bnFKoVJi4k4PjnX3+znqA5SqDbicZQmAMmPe9rYuoO+gL9G6mb7DyO6Wwmf3IWGJTv fgnLBxSpqDzDdzkprKH+veFcZkeMG0BblTu6xxAaU8ilp+lsnW72tjpKuHMSFSViTx9DrJQM7 GHbf49do9u6zQikPz0TmEIYRh1aBhSA6F0N0+cfjwIil9hiZdMcozFmsYFfHtkhaQ81Dfyq8k pkBI8qteBQiQF4622JXQwbvYs7Wsu6qaoxZ8HFE5dE5LVja9ZtlhDFPLJxgT2QS+g4OiiaCh6 6eXy94QdEyvd0OI5e0H8fIwGzL88EKYfSqYk0/aBz9HDruxUtsRLV4/SAMvPr7esYW5jMXETB bTJ7bc8HVR03KqTOYA3MqgQAiRORNSmxA7swiknLnpRfxWSRYTh92dxckJA= Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-pop-architecture-04 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, 19 Oct 2015 19:49:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kM77aUIu4T35u8TskrumWwlW7MHmSdSjn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI: Refreshed the draft (since it expired last month). The document is being shepherded by Kepeng and he has already uploaded the shepherd writeup. --kM77aUIu4T35u8TskrumWwlW7MHmSdSjn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWJUliAAoJEGhJURNOOiAtmKQIAJrcqeT6FyEbt20ob0CpVnIU rMVspGXb1iDn7bTPGtWxiAOiNp5Sgn2znpLF9+b8XjZgSAO2IxIeDokRke6FRUsi uEMg5Uji+jItAOSOWxJdyoP/+Weip6TM/rCJT66LdoDRgmPjI9gFjU9ufZp9ClIi PDHCQ2PcEpxOE7XNLiJrYQiWYtBDUuyEAB+Shja0ojnLeYHvZnk9KEv0w+1887aE CMmvufCScPOygnbWaXBOKkRloQ/Gujpa8r+zyvOwCDeMBSAG7K4jD2C3nWEJCTPG zGXyDl/a4+ojtWIJ0koBmKXu12oQ6eLO2B64rc5AG3HfHsNDxYfg/fvxlklM/7Q= =XM6g -----END PGP SIGNATURE----- --kM77aUIu4T35u8TskrumWwlW7MHmSdSjn-- From nobody Mon Oct 19 12:54:40 2015 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 50B331A902F for ; Mon, 19 Oct 2015 12:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Eaqv-TQr_ecW for ; Mon, 19 Oct 2015 12:54:16 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B182E1A9009 for ; Mon, 19 Oct 2015 12:54:16 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t9JJsDTw028230 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Oct 2015 19:54:14 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t9JJsDLS026381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2015 19:54:13 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t9JJsCnP011375; Mon, 19 Oct 2015 19:54:12 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Oct 2015 12:54:12 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Phil Hunt In-Reply-To: <56254962.3010908@gmx.net> Date: Mon, 19 Oct 2015 12:54:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56254962.3010908@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-architecture-04 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, 19 Oct 2015 19:54:18 -0000 Hannes, I see *substantial* changes have been made. It appears you have = refreshed draft 02 rather than 03. The changes in 03 reflected Kepeng=E2=80=99s write up. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Oct 19, 2015, at 12:49 PM, Hannes Tschofenig = wrote: >=20 > FYI: Refreshed the draft (since it expired last month). > The document is being shepherded by Kepeng and he has already uploaded > the shepherd writeup. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Oct 19 13:01:10 2015 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 634351A9040 for ; Mon, 19 Oct 2015 13:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 S-ivTv3cjz8p for ; Mon, 19 Oct 2015 13:00:57 -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 C8F111A9034 for ; Mon, 19 Oct 2015 13:00:56 -0700 (PDT) Received: from [192.168.131.140] ([80.92.122.73]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lh7PL-1aIQgT3Htv-00oWP7; Mon, 19 Oct 2015 22:00:55 +0200 To: Phil Hunt References: <56254962.3010908@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56254BF6.7070203@gmx.net> Date: Mon, 19 Oct 2015 22:00:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MnDA58avxc4lhvOGAfjmXHePF8JtEfnMG" X-Provags-ID: V03:K0:DNO6xtbi75Vsbt+gz+SMTR5hFTtEPTnNfW1orOryA9lC794L3gn Wx3JP6rR+ECt2YfYTLruWz2s6S17sJepIIlxzXrOZZqvjHVuPT0pKEsisx8yPRPxH+eXp7z Usv3GU02QbJ5odEfwzRdE7z4s1XW6QkqtnSBXr3GYMNsKUVMslGtY3bjiuxWrzmo2uJDBcj 1kZJ3EtBHbcLXi+5D8nQQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:R9tgKAWlY+E=:78YUTaSR0kRBGYpTT863+N SsBc8EamwLmx5+THpReTzTaIOfg+CzQZCOT7g6OrPvt7bqwRuR0WnIo9Zu6eQtFR5Am3o6s6r qrV+V/8GxB+fgX2sEAzpDbwWhY8RJBpYci1UBCPXo4Ophn18kRf77N7VduV+uMCH/EJQcSzK4 Osjo6Ul4MmnX4YDqtzhCxLI7hws3zruXmxwYQJh/Mrd2lIJjDaXBVQVgj0qr2/yWDDsBLVkg8 gJsIWjCSaN+xWqY3ZzjMoDit9Rg4Za4izTsKKGK2B7DxNE4ISMfeo3aCGgx0nEN6NswbHP/kz zx2YJVeunI3uui4+HEfdHaiBGs7Wa7V7ubYlHYGOpQsFeRqv/MfHsdQSKveNBPwoPj+imFaN0 tyA6JV/2uOruOyLnoVNTSEFVbi/k70rZ9dwUzuo4iWUI+tO47ZgCnrtJfAA/36gUS4/gPVS9/ 6JijziigRXZa0cHaXibggv22/qU3aK8MUAsLMeSKFmTv25FihVwqwc9tqj6NvF0knJDb5OfbW R2fjeCrpgdCnPr3Qh7v8lqla8hVSI0hRPdC8lzpgBX6AIUl1r2cCNS9UYx8LLt+9jag2LBN4P OujpJ4ags/cF0WLDjvEJ+igaCGGW/OhXzLRHJ8hnWUW+Y00rKZmCygoSGDV5kRW7kRGHt4w0B opDaWdZ8xlilA4ocCOqPo/iFF2SI+hPPgjVZW24vJXnzZoW7ervfKUZrsT19seXI4LYRuk7Lv GMkG92lhP7LvyoR8LGVNjzytMXrhbWj0hoBJ6896G6LBobjMeUr+p29rGzQ= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-architecture-04 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, 19 Oct 2015 20:00:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MnDA58avxc4lhvOGAfjmXHePF8JtEfnMG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Oops. Let me fix that. On 10/19/2015 09:54 PM, Phil Hunt wrote: > Hannes, >=20 > I see *substantial* changes have been made. It appears you have refresh= ed draft 02 rather than 03. >=20 > The changes in 03 reflected Kepeng=E2=80=99s write up. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >> On Oct 19, 2015, at 12:49 PM, Hannes Tschofenig wrote: >> >> FYI: Refreshed the draft (since it expired last month). >> The document is being shepherded by Kepeng and he has already uploaded= >> the shepherd writeup. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --MnDA58avxc4lhvOGAfjmXHePF8JtEfnMG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWJUv2AAoJEGhJURNOOiAtPUkH/Ary3okBBwpKEbb/yO0Cw43+ FMkmvgK1Lg1pO1ck6MdwE0SXeiq5CTy/bGhWUuawuxnq/WxPkRgwtCryKH2RnPyu 4l7BqkXuds0JyQbP3yVnVAOZmbHJNz42wA54Lu+3Ewki4P+rWA+yaejD2OAFkh8s fBbTK3QEsXXvmqoDiihB+Ty8U2yy5BCZDEybBMzbHLdvadBIrgjlh6rbNBXl5u4q rfjELVtSmto3QmYX0aGq4tU6NIt7rVk+x1jISmOZGvoCfPoETCXclW5HWD/LZnJm cucklzabNnCu+ZRdnmf22yZhubZUBDI26ora2tNDg1Lno/Tgcnnmj8pDUgoVXfc= =TPrr -----END PGP SIGNATURE----- --MnDA58avxc4lhvOGAfjmXHePF8JtEfnMG-- From nobody Mon Oct 19 13:09:07 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B36B21A90B1; Mon, 19 Oct 2015 13:08:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019200850.14957.95824.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 13:08:50 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-05.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: Mon, 19 Oct 2015 20:08:50 -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 : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture Authors : Phil Hunt Justin Richer William Mills Prateek Mishra Hannes Tschofenig Filename : draft-ietf-oauth-pop-architecture-05.txt Pages : 22 Date : 2015-10-19 Abstract: The OAuth 2.0 bearer token specification, as defined in RFC 6750, allows any party in possession of a bearer token (a "bearer") to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens must to be protected from disclosure in transit and at rest. Some scenarios demand additional security protection whereby a client needs to demonstrate possession of cryptographic keying material when accessing a protected resource. This document motivates the development of the OAuth 2.0 proof-of-possession security mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-05 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 Mon Oct 19 13:11:29 2015 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 8D7941A90D4 for ; Mon, 19 Oct 2015 13:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 x38EG5tY1NP6 for ; Mon, 19 Oct 2015 13:11:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1217A1A90D5 for ; Mon, 19 Oct 2015 13:11:12 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t9JKB935005408 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Oct 2015 20:11:10 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t9JKB9Da000354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2015 20:11:09 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t9JKB98D020402; Mon, 19 Oct 2015 20:11:09 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Oct 2015 13:11:09 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Phil Hunt In-Reply-To: Date: Mon, 19 Oct 2015 13:10:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56254962.3010908@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-architecture-04 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, 19 Oct 2015 20:11:14 -0000 Hannes et al, I=E2=80=99ve restored the draft 03 version (including feedback from = kepeng) and changed it today=E2=80=99s date (now draft 05) - replacing = the 04 draft. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Oct 19, 2015, at 12:54 PM, Phil Hunt wrote: >=20 > Hannes, >=20 > I see *substantial* changes have been made. It appears you have = refreshed draft 02 rather than 03. >=20 > The changes in 03 reflected Kepeng=E2=80=99s write up. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >> On Oct 19, 2015, at 12:49 PM, Hannes Tschofenig = wrote: >>=20 >> FYI: Refreshed the draft (since it expired last month). >> The document is being shepherded by Kepeng and he has already = uploaded >> the shepherd writeup. >>=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 Mon Oct 19 15:57:44 2015 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 05FE51AC3E4; Mon, 19 Oct 2015 15:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 HhDdwmnMAy3E; Mon, 19 Oct 2015 15:57:39 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9641B2E5A; Mon, 19 Oct 2015 15:57:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 76476182534; Mon, 19 Oct 2015 15:56:59 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20151019225659.76476182534@rfc-editor.org> Date: Mon, 19 Oct 2015 15:56:59 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 7662 on OAuth 2.0 Token Introspection 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, 19 Oct 2015 22:57:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7662 Title: OAuth 2.0 Token Introspection Author: J. Richer, Ed. Status: Standards Track Stream: IETF Date: October 2015 Mailbox: ietf@justin.richer.org Pages: 17 Characters: 36591 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-introspection-11.txt URL: https://www.rfc-editor.org/info/rfc7662 DOI: http://dx.doi.org/10.17487/RFC7662 This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Oct 19 15:59:43 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 284991B2E19; Mon, 19 Oct 2015 15:59:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019225940.362.97138.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 15:59:40 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-05.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: Mon, 19 Oct 2015 22:59:40 -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 : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jones John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-proof-of-possession-05.txt Pages : 16 Date : 2015-10-19 Abstract: This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-proof-of-possession-05 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 Mon Oct 19 16:02:43 2015 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 5E2891B2D4C for ; Mon, 19 Oct 2015 16:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 cKYjXEki0w_c for ; Mon, 19 Oct 2015 16:02:38 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0134.outbound.protection.outlook.com [207.46.100.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7761AC429 for ; Mon, 19 Oct 2015 16:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PeF38BPrwBzK/sBlv9aPDjoS83QnEij4PM8r5MeVZtM=; b=c+Umo0sece+BuvYGVo6jO1HVUCBzMZ0jZk/Hd8ljky6mk+lwOWhtJGx8wH8x7uLfcsy4912lAlpOMZqR+2uGDwKwaQbLsDgzZLQb1T7dKgTW25ez1UrxMhZLQb0oVQYcaQKQVTJLH8A43QMr44JbXXDheXkzariBFhz7lQkjzwk= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 23:02:23 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 23:02:24 +0000 From: Mike Jones To: Kepeng Li , "oauth@ietf.org" Thread-Topic: Review comments to PoP document Thread-Index: AQHRAQy64oow7N4z4U6J9u6BZvdoP55hw/IQgACWtwCAEScXQA== Date: Mon, 19 Oct 2015 23:02:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [12.130.117.154] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:CsltWEMX0CKiRJCZqZQGcpRN8ARKIw0RFCvojQsKXOUACyu1i06lwC2y787ms+2NnbbM3pdqxeP2l2s0etRNxYCjyarPs8jjVUYGi3AfTTYecobesuYaXyb/QomVmnK8D6yyepNBaICbHCorDUxskA==; 24:q6g4+0zrryQolIa1mkS7o5mFDVJs9BiViGqg8qz41abiYcQd4Ij7lJNrFzgtsrNYGHD8ARg0d1Sb0sciCzVcuLSRp7DdC+ttIz9WoBDmK28=; 20:M2ryVD1e+bCk7tLonelefIVaZFVL3Joc2uutCnPFTnYWQmV9FwpQfutzuOIyYdH1mLaH8bSBvvWt3n+jaeEbMw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(61426024)(61427024); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 07349BFAD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(199003)(51914003)(53754006)(43784003)(71364002)(77096005)(10090500001)(15975445007)(97736004)(19625215002)(33656002)(10290500002)(81156007)(76576001)(5005710100001)(10400500002)(19609705001)(74316001)(66066001)(189998001)(5002640100001)(2900100001)(5004730100002)(2950100001)(86362001)(86612001)(102836002)(107886002)(5001770100001)(122556002)(101416001)(5001960100002)(5007970100001)(64706001)(87936001)(92566002)(5003600100002)(106356001)(40100003)(19580395003)(76176999)(19617315012)(16236675004)(46102003)(19580405001)(106116001)(50986999)(99286002)(19300405004)(5008740100001)(8990500004)(105586002)(54356999)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442D7E4BE8EA1C29A9EAA5BF53A0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 23:02:23.9537 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: Re: [OAUTH-WG] Review comments to PoP document 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, 19 Oct 2015 23:02:41 -0000 --_000_BY2PR03MB442D7E4BE8EA1C29A9EAA5BF53A0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VwZW5nLA0KDQpEcmFmdCAtMDUgYWRkcmVzc2VzIGFsbCB5b3VyIHJldmlldyBjb21tZW50 cyBhcyBhZ3JlZWQgYmVsb3csIG90aGVyIHRoYW4gYWRkaW5nIHRoZSBkaWFncmFtcyB0aGF0IHlv dSByZXF1ZXN0ZWQuICBJ4oCZbGwgcGxhbiBvbiB3b3JraW5nIG9uIHRob3NlIGJldHdlZW4gbm93 IGFuZCBZb2tvaGFtYSBhbmQgc3VibWl0dGluZyBhbiB1cGRhdGVkIGRyYWZ0IHdpdGggdGhlIGRp YWdyYW1zIHdoZW4gdGhlIHN1Ym1pc3Npb24gcGVyaW9kIG9wZW5zLg0KDQpUaGFua3MgYWdhaW4g Zm9yIHlvdXIgdXNlZnVsIHJldmlldyBvZiB0aGlzIGRyYWZ0LiAgSSBhZGRlZCB5b3UgdG8gdGhl IGFja25vd2xlZGdlbWVudHMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEJlc3Qgd2lzaGVzLA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9t OiBLZXBlbmcgTGkgW21haWx0bzprZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbV0NClNlbnQ6IFRo dXJzZGF5LCBPY3RvYmVyIDA4LCAyMDE1IDY6MDQgUE0NClRvOiBNaWtlIEpvbmVzOyBvYXV0aEBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFJldmlldyBjb21tZW50cyB0byBQb1AgZG9jdW1lbnQNCg0K SGkgTWlrZSwNCg0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlcy4NCg0KQWJvdXQgdGhlIGZpcnN0 IHBhcmFncmFwaCBpbiB0aGUgaW50cm9kdWN0aW9uLCBJIHdvdWxkIHByZWZlciB0byBtYWtlIGl0 IGRpZmZlcmVudCBmcm9tIHRoZSBzYW1lIG9uZSBpbiB0aGUgYWJzdHJhY3QuDQoNCkkgYW0gZmlu ZSB3aXRoIG90aGVycy4NCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCg0K5Y+R5Lu25Lq6OiBNaWtl IEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbT4+DQrml6XmnJ86IEZyaWRheSwgOSBPY3RvYmVyLCAyMDE1IDE6NTggYW0N CuiHszogTGkgS2VwZW5nIDxrZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbTxtYWlsdG86a2VwZW5n LmxrcEBhbGliYWJhLWluYy5jb20+PiwgIm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRm Lm9yZz4iIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0K5Li76aKYOiBS RTogUmV2aWV3IGNvbW1lbnRzIHRvIFBvUCBkb2N1bWVudA0KDQpUaGFua3MgZm9yIHRoZSB1c2Vm dWwgcmV2aWV3LCBLZXBlbmcuICBSZXNwb25zZXMgaW5saW5l4oCmDQoNCkZyb206IE9BdXRoIFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtlcGVuZyBMaQ0KU2Vu dDogV2VkbmVzZGF5LCBPY3RvYmVyIDA3LCAyMDE1IDc6MzAgQU0NClRvOiBvYXV0aEBpZXRmLm9y ZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbT0FVVEgtV0ddIFJldmlldyBjb21t ZW50cyB0byBQb1AgZG9jdW1lbnQNCg0KSGVsbG8gYWxsLA0KDQpQbGVhc2UgZmluZCBteSByZXZp ZXcgY29tbWVudHMgdG8gUG9QIGRvY3VtZW50Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA0PGh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZ0b29scy5pZXRm Lm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24tMDQmZGF0 YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2MzOWZjMzY3YmZjMDQ0 ZmU5MjQzYzA4ZDJjZjIzZDk1YiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdj MSZzZGF0YT1YTlg4OWwyMUd6Q29LRHprUXVmZE4xdkY5VnNHcU9wTnBXcDlNNnl5cUFRJTNkPg0K DQoNCjHjgIEgICAgICAgICAgVGl0bGU6DQpQcm9vZi1vZi1Qb3NzZXNzaW9uIEtleSBTZW1hbnRp Y3MgZm9yIEpTT04gV2ViIFRva2VucyAoSldUcykNCltLZXBlbmddIFNob3VsZCB3ZSBhZGQgT0F1 dGggMi4wIGluIHRoZSB0aXRsZT8gQWxzbywgaW4gdGhlIHdob2xlIGRvY3VtZW50LCB3ZSB1c2Ug SldULCBidXQgaW4gdGhlIHRpdGxlLCB3ZSB1c2Ug4oCcSldUc+KAnS4gSXMgdGhlcmUgYSByZWFz b24gZm9yIHRoaXM/DQoNCkkgd291bGRu4oCZdCBzdWdnZXN0IGFkZGluZyDigJxPQXV0aCAyLjDi gJ0gdG8gdGhlIHRpdGxlLCBpbiBwYXJ0LCBiZWNhdXNlIEpXVHMgYXJlIHVzZWQgaW4gY29udGV4 dHMgb3V0c2lkZSBvZiBPQXV0aC4gIEFzIGZvciB3aHkgSldUcyBpcyBwbHVyYWwgaGVyZSwgdGhl IHRpdGxlIGlzIHNheWluZyB0aGF0IFBvUCBrZXlzIGNhbiBiZSBjb21tdW5pY2F0ZWQgaW4gSlNP TiBXZWIgVG9rZW5zLiAgSWYgaXQgd2VyZSBzaW5ndWxhciwgaXQgd291bGQgc291bmQgbGlrZSB5 b3UgY291bGQgb25seSB1c2UgUG9QIGtleXMgaW4gYSBzaW5nbGUgSldULCB3aGljaCBpc27igJl0 IHJpZ2h0Lg0KDQoNCjLjgIEgICAgICAgICAgQWJzdHJhY3TvvJoNCjEpIFRoaXMgc3BlY2lmaWNh dGlvbiBkZWZpbmVzIGhvdyB0byBleHByZXNzIGEgZGVjbGFyYXRpb24gaW4gYSBKU09OIFdlYiBU b2tlbiAoSldUKSB0aGF0IHRoZSBwcmVzZW50ZXIgb2YgdGhlIEpXVCBwb3NzZXNzZXMgYSBwYXJ0 aWN1bGFyIGtleSBhbmQgdGhhdCB0aGUgcmVjaXBpZW50IGNhbiBjcnlwdG9ncmFwaGljYWxseSBj b25maXJtIHByb29mLW9mLXBvc3Nlc3Npb24gb2YgdGhlIGtleSBieSB0aGUgcHJlc2VudGVyLg0K W0tlcGVuZ10gQWRkIHJlZmVyZW5jZSB0byBKV1QuDQoNCknigJl2ZSBiZWVuIHRvbGQgd2hlbiBl ZGl0aW5nIG90aGVyIGRyYWZ0cyB0byByZW1vdmUgcmVmZXJlbmNlcyB0aGF0IEnigJlkIHBsYWNl ZCBpbiBhYnN0cmFjdHMsIHNpbmNlIElFVEYgYWJzdHJhY3RzIGRvbuKAmXQgaW5jbHVkZSByZWZl cmVuY2VzLg0KDQoyKSBUaGlzIHByb3BlcnR5IGlzIGFsc28gc29tZXRpbWVzIGRlc2NyaWJlZCBh cyB0aGUgcHJlc2VudGVyIGJlaW5nIGEgaG9sZGVyLW9mLWtleS4NCltLZXBlbmddIEkgYW0gbm90 IHN1cmUgd2hhdCBpcyDigJx0aGlzIHByb3BlcnR54oCdLiBEbyB5b3UgbWVhbiDigJx0aGUga2V5 4oCdPyBJZiB5ZXMsIGp1c3QgdXNlIHRoZSBrZXkuIEFuZCBjaGFuZ2UgdGhlIHNlbnRlbmNlIHRv IHNvbWV0aGluZyBsaWtlOiBUaGlzIGtleSBpcyBhbHNvIHNvbWV0aW1lcyBkZXNjcmliZWQgYXMg YSBob2xkZXItb2Yta2V5IGJ5IHRoZSBwcmVzZW50ZXIuDQoNCkkgY2FuIGNoYW5nZSDigJxUaGlz IHByb3BlcnR54oCdIHRvIOKAnEJlaW5nIGFibGUgdG8gcHJvdmUgcG9zc2Vzc2lvbiBvZiBhIGtl eeKAnS4NCg0KMy4gSW50cm9kdWN0aW9uDQoxKSBUaGUgZmlyc3QgcGFyYWdyYXBoIGlzIHRoZSBz YW1lIGFzIHRoZSBhYnN0cmFjdC4gSSBzdWdnZXN0IHRvIHJld29yZCBpdCBhIGxpdHRsZSBiaXQg b3IgcmVtb3ZlIGl0LCB0byBhdm9pZCB0aGUgcmVkdW5kYW5jeS4NCg0KVGhlIHJlc3Qgb2YgdGhl IGludHJvZHVjdGlvbiBidWlsZHMgb24gdGhlIGlkZWFzIGludHJvZHVjZWQgaW4gdGhlIGZpcnN0 IHR3byBzZW50ZW5jZXMgKHRoZSBjb250ZW50IG9mIHRoZSBhYnN0cmFjdCkuIElmIHRoZXkgd2Vy ZSB0byBiZSByZW1vdmVkLCBpdCB3b3VsZCBtYWtlIHRoZSBpbnRyb2R1Y3Rpb24gY29uZnVzaW5n LCBhcyBtYW55IHBlb3BsZSB3b27igJl0IHN0YXJ0IGJ5IHJlYWRpbmcgdGhlIGFic3RyYWN0LCBi dXQgd2lsbCByZWFkIHRoZSBpbnRyb2R1Y3Rpb24gaW5kZXBlbmRlbnRseS4gIChUaGUgaW50cm9k dWN0aW9uIGRvZXMgYWRkIHJlZmVyZW5jZXMsIHdoaWNoIGNhbm5vdCBiZSBwcmVzZW50IGluIHRo ZSBhYnN0cmFjdC4pICBJ4oCZbGwgd29yayB3aXRoIHRoZSBvdGhlciBlZGl0b3JzIHRvIHNlZSBp ZiB0aGV5IHdhbnQgdG8gcmV3b3JkIHRoZSBmaXJzdCB0d28gc2VudGVuY2VzIG9mIHRoZSBpbnRy b2R1Y3Rpb24gYW5kL29yIGFic3RyYWN0IHRvIG1ha2UgdGhlbSBkaWZmZXJlbnQgZnJvbSBvbmUg YW5vdGhlci4NCg0KMikgU2VlIFtJLUQuaWV0Zi1vYXV0aC1wb3AtYXJjaGl0ZWN0dXJlXSBmb3Ig YSBmdXJ0aGVyIGRpc2N1c3Npb24gb2Yga2V5IGNvbmZpcm1hdGlvbi4NCltLZXBlbmddIEkgc3Vn Z2VzdCB0byBtZW50aW9uIGEgbGl0dGxlIGJpdCBtb3JlIGFib3V0IHRoZSByZWxhdGlvbnNoaXAg YmV0d2VlbiBQb1AgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGFuZCB0aGlzIGRvY3VtZW50LiBJbiBt eSB1bmRlcnN0YW5kaW5nLCBpbiBQb1AgYXJjaGl0ZWN0dXJlIGRvY3VtZW50LCBpdCBtZW50aW9u cyBzZXZlcmFsIG1lY2hhbmlzbXM6IGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uLCBrZXkgY29u ZmlybWF0aW9uIGFuZCBzZW5kZXIgY29uc3RyYWludC4gVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2Vz IHRoZSBrZXkgc2VtYW50aWNzIGZvciB0aGUga2V5IGNvbmZpcm1hdGlvbiBtZWNoYW5pc20uDQoN Ck9LIOKAkyB3ZSBjYW4gc2F5IHRoYXQgW0ktRC5pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmVd IGRlc2NyaWJlcyBrZXkgY29uZmlybWF0aW9uLCBhbW9uZyBvdGhlciBjb25mb3JtYXRpb24gbWVj aGFuaXNtcywgYW5kIHRoYXQgdGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgaG93IHRvIGNvbW11 bmljYXRlIGtleSBjb25maXJtYXRpb24ga2V5IGluZm9ybWF0aW9uIGluIEpXVHMuDQoNCjMpIEFi b3V0IHRoZSB0d28gdXNlIGNhc2VzLCBpdCB3aWxsIGJlIHVzZWZ1bCB0byB1c2UgdHdvIGRpYWdy YW1zIG9yIGZsb3dzIHRvIGluZGljYXRlIGhvdyBpdCB3b3Jrcy4gTWF5YmUgcHV0IHRoZXNlIHR3 byBmbG93cyBpbiBhIHNlcGFyYXRlIHNlY3Rpb24uIEFsc28gaXQgd2lsbCBiZSB1c2VmdWwgdG8g bWVudGlvbiB3aGljaCBzdGVwIGlzIGluIHNjb3BlLCBhbmQgd2hpY2ggaXMgb3V0IG9mIHNjb3Bl LCBlLmcuIGhvdyB0byBjb252ZXkgc3ltbWV0cmljIGtleSBmcm9tIHRoZSBpc3N1ZXIgdG8gdGhl IHByZXNlbnRlci4NCg0KQm90aCBhcmUgaW4gc2NvcGUsIHdoaWNoIGlzIHdoeSB0aGV54oCZcmUg Ym90aCBkZXNjcmliZWQgaW4gdGhlIGludHJvZHVjdGlvbi4gIEnigJlsbCB3b3JrIHdpdGggdGhl IG90aGVyIGVkaXRvcnMgb24gdHJ5aW5nIHRvIGNyZWF0ZSBhcHByb3ByaWF0ZSBkaWFncmFtcy4N Cg0KNC4gU2VjdGlvbiAzOg0KMSkgSXQgd2lsbCBiZSB1c2VmdWwgdG8gcHV0IGEgcmVmZXJlbmNl IHRvICJzdWIiIChzdWJqZWN0KSBjbGFpbSwgYW5kICJpc3MiIChpc3N1ZXIpIGNsYWltLg0KDQpP Sw0KDQoyKSBOb3RlIHRoYXQgaWYgYW4gYXBwbGljYXRpb24gbmVlZHMgdG8gcmVwcmVzZW50IG11 bHRpcGxlIHByb29mLW9mLQ0KICAgcG9zc2Vzc2lvbiBrZXlzIGluIHRoZSBzYW1lIEpXVCwgb25l IHdheSBmb3IgaXQgdG8gYWNoaWV2ZSB0aGlzIGlzIHRvDQogICB1c2Ugb3RoZXIgY2xhaW0gbmFt ZXMsIGluIGFkZGl0aW9uIHRvICJjbmYiLCB0byBob2xkIHRoZSBhZGRpdGlvbmFsDQogICBwcm9v Zi1vZi1wb3NzZXNzaW9uIGtleSBpbmZvcm1hdGlvbi4NCltLZXBlbmddIEl0IGlzIG5vdCBjbGVh ciwgd2hhdCBhcmUgdGhlIG90aGVyIGNsYWltIG5hbWVzPw0KDQpGYWlyIHBvaW50LiAgV2UgY2Fu IHNheSB0aGF0IHRob3NlIGNsYWltIG5hbWVzIHdvdWxkIGJlIGRlZmluZWQgYnkgYXBwbGljYXRp b25zIGFuZCBjb3VsZCBiZSByZWdpc3RlcmVkIGluIHRoZSBKV1QgQ2xhaW1zIFJlZ2lzdHJ5Lg0K DQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MgYWdhaW4hDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo= --_000_BY2PR03MB442D7E4BE8EA1C29A9EAA5BF53A0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMg MSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYW1icmlh Ow0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToy IDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3Vu IjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWdu Omp1c3RpZnk7DQoJdGV4dC1pbmRlbnQ6MjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMwMDIwNjA7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzAwMjA2 MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDoxNTk3MzI0MTI0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczozNjUwNDEzMTAgLTU2MTg0OTEwMCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6JTHjgIE7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u NWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTJcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQ4LjBwdDsN Cgl0ZXh0LWluZGVudDotMjQuMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjEuMGluOw0KCXRleHQt aW5kZW50Oi0yNC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo5Ni4w cHQ7DQoJdGV4dC1pbmRlbnQ6LTI0LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiU1XCkiOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDoxMjAuMHB0Ow0KCXRleHQtaW5kZW50Oi0yNC4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFy Z2luLWxlZnQ6Mi4waW47DQoJdGV4dC1pbmRlbnQ6LTI0LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE2OC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTI0LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRleHQ6IiU4XCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxOTIuMHB0Ow0KCXRleHQtaW5k ZW50Oi0yNC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6My4waW47DQoJdGV4dC1pbmRlbnQ6LTI0 LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+SGkgS2VwZW5nLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOiMwMDIwNjAiPkRyYWZ0IC0wNSBhZGRyZXNzZXMgYWxsIHlvdXIgcmV2aWV3IGNvbW1lbnRz IGFzIGFncmVlZCBiZWxvdywgb3RoZXIgdGhhbiBhZGRpbmcgdGhlIGRpYWdyYW1zIHRoYXQgeW91 IHJlcXVlc3RlZC4mbmJzcDsgSeKAmWxsIHBsYW4gb24gd29ya2luZyBvbiB0aG9zZSBiZXR3ZWVu IG5vdyBhbmQgWW9rb2hhbWEgYW5kIHN1Ym1pdHRpbmcgYW4gdXBkYXRlZA0KIGRyYWZ0IHdpdGgg dGhlIGRpYWdyYW1zIHdoZW4gdGhlIHN1Ym1pc3Npb24gcGVyaW9kIG9wZW5zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIw NjAiPlRoYW5rcyBhZ2FpbiBmb3IgeW91ciB1c2VmdWwgcmV2aWV3IG9mIHRoaXMgZHJhZnQuJm5i c3A7IEkgYWRkZWQgeW91IHRvIHRoZSBhY2tub3dsZWRnZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBCZXN0IHdpc2hlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVm dCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEtlcGVuZyBMaSBbbWFpbHRvOmtlcGVuZy5sa3BAYWxpYmFi YS1pbmMuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBPY3RvYmVyIDA4LCAyMDE1 IDY6MDQgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM7IG9hdXRoQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBSZXZpZXcgY29tbWVudHMgdG8gUG9QIGRvY3VtZW50PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPkhpIE1pa2UsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6 YmxhY2siPlRoYW5rcyBmb3IgeW91ciByZXNwb25zZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPkFi b3V0IHRoZSBmaXJzdCBwYXJhZ3JhcGggaW4gdGhlIGludHJvZHVjdGlvbiwgSSB3b3VsZCBwcmVm ZXIgdG8gbWFrZSBpdCBkaWZmZXJlbnQgZnJvbSB0aGUgc2FtZSBvbmUgaW4gdGhlIGFic3RyYWN0 LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1 bjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj5JIGFtIGZpbmUgd2l0aCBvdGhlcnMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1T dW47Y29sb3I6YmxhY2siPktpbmQgUmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+S2VwZW5nPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Og0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+TWlrZSBKb25lcyAmbHQ7PGEg aHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7ml6XmnJ88L3NwYW4+PC9i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj46DQo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5GcmlkYXksIDkg T2N0b2JlciwgMjAxNSAxOjU4IGFtPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+6IezPC9zcGFuPjwvYj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Og0KPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+TGkgS2VwZW5nICZs dDs8YSBocmVmPSJtYWlsdG86a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb20iPmtlcGVuZy5sa3BA YWxpYmFiYS1pbmMuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm Lm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhA aWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7kuLvp opg8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNr Ij46DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNr Ij5SRTogUmV2aWV3IGNvbW1lbnRzIHRvIFBvUCBkb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPlRoYW5rcyBm b3IgdGhlIHVzZWZ1bCByZXZpZXcsIEtlcGVuZy4mbmJzcDsgUmVzcG9uc2VzIGlubGluZeKApjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMw MDIwNjAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IE9BdXRoIFs8YSBocmVmPSJtYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5LZXBlbmcgTGk8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVz ZGF5LCBPY3RvYmVyIDA3LCAyMDE1IDc6MzAgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1h aWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFtPQVVUSC1XR10gUmV2aWV3IGNvbW1lbnRzIHRvIFBvUCBkb2N1bWVudDwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246 bGVmdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0 LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNp bVN1bjtjb2xvcjpibGFjayI+SGVsbG8gYWxsLDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4 dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpT aW1TdW47Y29sb3I6YmxhY2siPlBsZWFzZSBmaW5kIG15IHJldmlldyBjb21tZW50cyB0byBQb1Ag ZG9jdW1lbnQ6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi IHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZnRvb2xzLmlldGYu b3JnJTJmaHRtbCUyZmRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wNCZhbXA7 ZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2MzOWZjMzY3YmZj MDQ0ZmU5MjQzYzA4ZDJjZjIzZDk1YiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3 JTdjMSZhbXA7c2RhdGE9WE5YODlsMjFHekNvS0R6a1F1ZmROMXZGOVZzR3FPcE5wV3A5TTZ5eXFB USUzZCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1v Zi1wb3NzZXNzaW9uLTA0PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FtYnJpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+MeOAgTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5UaXRsZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlByb29mLW9mLVBvc3Nlc3Np b24gS2V5IFNlbWFudGljcyBmb3IgSlNPTiBXZWIgVG9rZW5zIChKV1RzKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ W0tlcGVuZ10gU2hvdWxkIHdlIGFkZCBPQXV0aCAyLjAgaW4gdGhlIHRpdGxlPyBBbHNvLCBpbiB0 aGUgd2hvbGUgZG9jdW1lbnQsIHdlIHVzZSBKV1QsIGJ1dCBpbiB0aGUgdGl0bGUsIHdlIHVzZSDi gJxKV1Rz4oCdLiBJcyB0aGVyZSBhIHJlYXNvbiBmb3IgdGhpcz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPkkgd291bGRu4oCZdCBzdWdnZXN0IGFk ZGluZyDigJxPQXV0aCAyLjDigJ0gdG8gdGhlIHRpdGxlLCBpbiBwYXJ0LCBiZWNhdXNlIEpXVHMg YXJlIHVzZWQgaW4gY29udGV4dHMgb3V0c2lkZSBvZiBPQXV0aC4mbmJzcDsgQXMgZm9yIHdoeSBK V1RzIGlzIHBsdXJhbCBoZXJlLCB0aGUgdGl0bGUgaXMgc2F5aW5nIHRoYXQgUG9QIGtleXMgY2Fu IGJlIGNvbW11bmljYXRlZA0KIGluIEpTT04gV2ViIFRva2Vucy4mbmJzcDsgSWYgaXQgd2VyZSBz aW5ndWxhciwgaXQgd291bGQgc291bmQgbGlrZSB5b3UgY291bGQgb25seSB1c2UgUG9QIGtleXMg aW4gYSBzaW5nbGUgSldULCB3aGljaCBpc27igJl0IHJpZ2h0Ljwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVu dDotLjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjLj gIE8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QWJz dHJhY3Q8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtN UyBNaW5jaG8mcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPu+8 mjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0 O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MSkgVGhpcyBz cGVjaWZpY2F0aW9uIGRlZmluZXMgaG93IHRvIGV4cHJlc3MgYSBkZWNsYXJhdGlvbiBpbiBhIEpT T04gV2ViIFRva2VuIChKV1QpIHRoYXQgdGhlIHByZXNlbnRlciBvZiB0aGUgSldUIHBvc3Nlc3Nl cyBhIHBhcnRpY3VsYXIga2V5IGFuZCB0aGF0IHRoZQ0KIHJlY2lwaWVudCBjYW4gY3J5cHRvZ3Jh cGhpY2FsbHkgY29uZmlybSBwcm9vZi1vZi1wb3NzZXNzaW9uIG9mIHRoZSBrZXkgYnkgdGhlIHBy ZXNlbnRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPltLZXBlbmddIEFkZCByZWZlcmVuY2UgdG8gSldULjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHls ZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTMuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4 dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAw MjA2MCI+SeKAmXZlIGJlZW4gdG9sZCB3aGVuIGVkaXRpbmcgb3RoZXIgZHJhZnRzIHRvIHJlbW92 ZSByZWZlcmVuY2VzIHRoYXQgSeKAmWQgcGxhY2VkIGluIGFic3RyYWN0cywgc2luY2UgSUVURiBh YnN0cmFjdHMgZG9u4oCZdCBpbmNsdWRlIHJlZmVyZW5jZXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4yKSBUaGlzIHByb3BlcnR5 IGlzIGFsc28gc29tZXRpbWVzIGRlc2NyaWJlZCBhcyB0aGUgcHJlc2VudGVyIGJlaW5nIGEgaG9s ZGVyLW9mLWtleS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPltLZXBlbmddIEkgYW0gbm90IHN1cmUgd2hhdCBpcyDi gJx0aGlzIHByb3BlcnR54oCdLiBEbyB5b3UgbWVhbiDigJx0aGUga2V54oCdPyBJZiB5ZXMsIGp1 c3QgdXNlIHRoZSBrZXkuIEFuZCBjaGFuZ2UgdGhlIHNlbnRlbmNlIHRvIHNvbWV0aGluZyBsaWtl OiBUaGlzIGtleSBpcyBhbHNvIHNvbWV0aW1lcyBkZXNjcmliZWQgYXMgYSBob2xkZXItb2Yta2V5 IGJ5IHRoZSBwcmVzZW50ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMDAyMDYwIj5JIGNhbiBjaGFuZ2Ug4oCcVGhpcyBwcm9wZXJ0eeKAnSB0byDigJxCZWlu ZyBhYmxlIHRvIHByb3ZlIHBvc3Nlc3Npb24gb2YgYSBrZXnigJ0uPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4zLiBJbnRyb2R1Y3Rp b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjEpIFRoZSBmaXJzdCBwYXJhZ3JhcGggaXMgdGhlIHNhbWUgYXMgdGhl IGFic3RyYWN0LiBJIHN1Z2dlc3QgdG8gcmV3b3JkIGl0IGEgbGl0dGxlIGJpdCBvciByZW1vdmUg aXQsIHRvIGF2b2lkIHRoZSByZWR1bmRhbmN5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYw Ij5UaGUgcmVzdCBvZiB0aGUgaW50cm9kdWN0aW9uIGJ1aWxkcyBvbiB0aGUgaWRlYXMgaW50cm9k dWNlZCBpbiB0aGUgZmlyc3QgdHdvIHNlbnRlbmNlcyAodGhlIGNvbnRlbnQgb2YgdGhlIGFic3Ry YWN0KS4gSWYgdGhleSB3ZXJlIHRvIGJlIHJlbW92ZWQsIGl0IHdvdWxkIG1ha2UgdGhlIGludHJv ZHVjdGlvbiBjb25mdXNpbmcsIGFzDQogbWFueSBwZW9wbGUgd29u4oCZdCBzdGFydCBieSByZWFk aW5nIHRoZSBhYnN0cmFjdCwgYnV0IHdpbGwgcmVhZCB0aGUgaW50cm9kdWN0aW9uIGluZGVwZW5k ZW50bHkuJm5ic3A7IChUaGUgaW50cm9kdWN0aW9uIGRvZXMgYWRkIHJlZmVyZW5jZXMsIHdoaWNo IGNhbm5vdCBiZSBwcmVzZW50IGluIHRoZSBhYnN0cmFjdC4pJm5ic3A7IEnigJlsbCB3b3JrIHdp dGggdGhlIG90aGVyIGVkaXRvcnMgdG8gc2VlIGlmIHRoZXkgd2FudCB0byByZXdvcmQgdGhlIGZp cnN0IHR3byBzZW50ZW5jZXMNCiBvZiB0aGUgaW50cm9kdWN0aW9uIGFuZC9vciBhYnN0cmFjdCB0 byBtYWtlIHRoZW0gZGlmZmVyZW50IGZyb20gb25lIGFub3RoZXIuPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4 dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4yKSBTZWUgW0ktRC5p ZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmVdIGZvciBhIGZ1cnRoZXIgZGlzY3Vzc2lvbiBvZiBr ZXkgY29uZmlybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5v bmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W0tlcGVuZ10gSSBzdWdnZXN0IHRvIG1lbnRp b24gYSBsaXR0bGUgYml0IG1vcmUgYWJvdXQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIFBvUCBh cmNoaXRlY3R1cmUgZG9jdW1lbnQgYW5kIHRoaXMgZG9jdW1lbnQuIEluIG15IHVuZGVyc3RhbmRp bmcsIGluIFBvUCBhcmNoaXRlY3R1cmUNCiBkb2N1bWVudCwgaXQgbWVudGlvbnMgc2V2ZXJhbCBt ZWNoYW5pc21zOiBjb25maWRlbnRpYWxpdHkgcHJvdGVjdGlvbiwga2V5IGNvbmZpcm1hdGlvbiBh bmQgc2VuZGVyIGNvbnN0cmFpbnQuIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUga2V5IHNl bWFudGljcyBmb3IgdGhlIGtleSBjb25maXJtYXRpb24gbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1h bGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+T0sg4oCTIHdlIGNhbiBzYXkg dGhhdCBbSS1ELmlldGYtb2F1dGgtcG9wLWFyY2hpdGVjdHVyZV0gZGVzY3JpYmVzIGtleSBjb25m aXJtYXRpb24sIGFtb25nIG90aGVyIGNvbmZvcm1hdGlvbiBtZWNoYW5pc21zLCBhbmQgdGhhdCB0 aGlzDQogc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGhvdyB0byBjb21tdW5pY2F0ZSBrZXkgY29uZmly bWF0aW9uIGtleSBpbmZvcm1hdGlvbiBpbiBKV1RzLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3Nw YWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MykgQWJvdXQgdGhlIHR3byB1c2Ug Y2FzZXMsIGl0IHdpbGwgYmUgdXNlZnVsIHRvIHVzZSB0d28gZGlhZ3JhbXMgb3IgZmxvd3MgdG8g aW5kaWNhdGUgaG93IGl0IHdvcmtzLiBNYXliZSBwdXQgdGhlc2UgdHdvIGZsb3dzIGluIGEgc2Vw YXJhdGUgc2VjdGlvbi4gQWxzbw0KIGl0IHdpbGwgYmUgdXNlZnVsIHRvIG1lbnRpb24gd2hpY2gg c3RlcCBpcyBpbiBzY29wZSwgYW5kIHdoaWNoIGlzIG91dCBvZiBzY29wZSwgZS5nLiBob3cgdG8g Y29udmV5IHN5bW1ldHJpYyBrZXkgZnJvbSB0aGUgaXNzdWVyIHRvIHRoZSBwcmVzZW50ZXIuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0 eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+Qm90aCBhcmUgaW4g c2NvcGUsIHdoaWNoIGlzIHdoeSB0aGV54oCZcmUgYm90aCBkZXNjcmliZWQgaW4gdGhlIGludHJv ZHVjdGlvbi4mbmJzcDsgSeKAmWxsIHdvcmsgd2l0aCB0aGUgb3RoZXIgZWRpdG9ycyBvbiB0cnlp bmcgdG8gY3JlYXRlIGFwcHJvcHJpYXRlDQogZGlhZ3JhbXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0 ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjQuIFNlY3Rpb24g Mzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVm dCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjEpIEl0IHdpbGwgYmUgdXNlZnVsIHRvIHB1dCBhIHJlZmVyZW5jZSB0 byAmcXVvdDtzdWImcXVvdDsgKHN1YmplY3QpIGNsYWltLCBhbmQgJnF1b3Q7aXNzJnF1b3Q7IChp c3N1ZXIpIGNsYWltLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj5PSzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3Nw YWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjps ZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MikgTm90 ZSB0aGF0IGlmIGFuIGFwcGxpY2F0aW9uIG5lZWRzIHRvIHJlcHJlc2VudCBtdWx0aXBsZSBwcm9v Zi1vZi08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i bGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwb3NzZXNzaW9uIGtleXMgaW4gdGhlIHNh bWUgSldULCBvbmUgd2F5IGZvciBpdCB0byBhY2hpZXZlIHRoaXMgaXMgdG88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQt YWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyB1c2Ugb3RoZXIgY2xhaW0gbmFtZXMsIGluIGFkZGl0aW9uIHRvICZxdW90 O2NuZiZxdW90OywgdG8gaG9sZCB0aGUgYWRkaXRpb25hbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0 O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IHByb29mLW9mLXBvc3Nlc3Npb24ga2V5IGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGln bjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W0tl cGVuZ10gSXQgaXMgbm90IGNsZWFyLCB3aGF0IGFyZSB0aGUgb3RoZXIgY2xhaW0gbmFtZXM/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0 eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHls ZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPkZhaXIgcG9pbnQuJm5ic3A7IFdlIGNhbiBzYXkg dGhhdCB0aG9zZSBjbGFpbSBuYW1lcyB3b3VsZCBiZSBkZWZpbmVkIGJ5IGFwcGxpY2F0aW9ucyBh bmQgY291bGQgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgSldUIENsYWltcyBSZWdpc3RyeS48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1 dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYw Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxp Z246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPktp bmQgUmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+S2VwZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4 dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAw MjA2MCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0 LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBhZ2FpbiE8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9z cGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_BY2PR03MB442D7E4BE8EA1C29A9EAA5BF53A0BY2PR03MB442namprd_-- From nobody Mon Oct 19 16:29:23 2015 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 E63901B2E78 for ; Mon, 19 Oct 2015 16:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 0mLYS8u4NsqF for ; Mon, 19 Oct 2015 16:29:14 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0109.outbound.protection.outlook.com [207.46.100.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD001B2EA6 for ; Mon, 19 Oct 2015 16:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iK7J5qo8poNu1be43MpWzkrOQkKaDzCbDWs5lza0CDM=; b=JmZOFM1OGKDXfVqMjr1G9h7+2Oar7abE9jBVgAmeaE2S04H0eP1Wj09MMl5VjpM/Mmtv6tKDtFT4//Jx2sS0sHVNltwm39xgxT7tA2uuLkcv+ZnKmkv5r+42NRg7Mftci6nHKDBeyykELMaicEC7yrjsgG22MLi5tEvjvfF7WHg= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 23:29:11 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 23:29:12 +0000 From: Mike Jones To: Kepeng Li , "oauth@ietf.org" Thread-Topic: Review comments to PoP document Thread-Index: AQHRAQy64oow7N4z4U6J9u6BZvdoP55hw/IQgACWtwCAEScXQIAAB8Ag Date: Mon, 19 Oct 2015 23:29:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [12.130.117.154] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:EblSq8hPDoTJIMAZjPly6pNJYyUeOSdE1FEAVFBMr/EShPWpV2UbDFDpcWf7rBa9T45EYkKNGU9o64kkLkkEGUH+EnE9ZIMr747+6YVzUg4fd96qmwLAwOf4frgjiMDlDqeAnps1BXdxLMYU22JUcw==; 24:Zf1BAF+KSeslqVJL9waieOvEzAAcgySh9KNOHKyyKudkEld2VmmBvA9nK1bkyopc8SSlAg10u7FLRph611OEnXl+nsFyHal2/vAPpkt6Cak=; 20:SGAehJJEhGyj8PQYCMP+UeyGWlfqD8Av9ngynPQLdo96eBTuvnoKKRnTjLiVTsY3egM05X2sLE/zE8GsNfvWOQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(61426024)(61427024); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 07349BFAD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(377454003)(189002)(53754006)(69234005)(71364002)(43784003)(51914003)(199003)(77096005)(5001770100001)(102836002)(86612001)(93886004)(19617315012)(50986999)(5002640100001)(33656002)(8990500004)(10290500002)(74316001)(76576001)(16236675004)(107886002)(5001960100002)(46102003)(86362001)(19300405004)(5005710100001)(105586002)(15975445007)(92566002)(19609705001)(189998001)(10090500001)(64706001)(66066001)(2950100001)(2501003)(97736004)(5007970100001)(106116001)(10400500002)(106356001)(40100003)(5003600100002)(122556002)(19580405001)(76176999)(19580395003)(5004730100002)(54356999)(81156007)(99286002)(19625215002)(5008740100001)(101416001)(87936001)(2900100001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442A8B1F9A79AA027C224E1F53A0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 23:29:11.9011 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: Re: [OAUTH-WG] Review comments to PoP document 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, 19 Oct 2015 23:29:22 -0000 --_000_BY2PR03MB442A8B1F9A79AA027C224E1F53A0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJLCBJIHBvc3RlZCBhYm91dCB0aGUgYXZhaWxhYmlsaXR5IG9mIHRoZSBuZXcgZHJhZnQgYXQg aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTQ2OCBhbmQgYXMgQHNlbGZpc3N1ZWQ8aHR0cHM6 Ly90d2l0dGVyLmNvbS9zZWxmaXNzdWVkPi4NCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2VudDogTW9uZGF5LCBP Y3RvYmVyIDE5LCAyMDE1IDQ6MDIgUE0NClRvOiBLZXBlbmcgTGk7IG9hdXRoQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW09BVVRILVdHXSBSZXZpZXcgY29tbWVudHMgdG8gUG9QIGRvY3VtZW50DQoN CkhpIEtlcGVuZywNCg0KRHJhZnQgLTA1IGFkZHJlc3NlcyBhbGwgeW91ciByZXZpZXcgY29tbWVu dHMgYXMgYWdyZWVkIGJlbG93LCBvdGhlciB0aGFuIGFkZGluZyB0aGUgZGlhZ3JhbXMgdGhhdCB5 b3UgcmVxdWVzdGVkLiAgSeKAmWxsIHBsYW4gb24gd29ya2luZyBvbiB0aG9zZSBiZXR3ZWVuIG5v dyBhbmQgWW9rb2hhbWEgYW5kIHN1Ym1pdHRpbmcgYW4gdXBkYXRlZCBkcmFmdCB3aXRoIHRoZSBk aWFncmFtcyB3aGVuIHRoZSBzdWJtaXNzaW9uIHBlcmlvZCBvcGVucy4NCg0KVGhhbmtzIGFnYWlu IGZvciB5b3VyIHVzZWZ1bCByZXZpZXcgb2YgdGhpcyBkcmFmdC4gIEkgYWRkZWQgeW91IHRvIHRo ZSBhY2tub3dsZWRnZW1lbnRzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBCZXN0IHdpc2hlcywNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJv bTogS2VwZW5nIExpIFttYWlsdG86a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb21dDQpTZW50OiBU aHVyc2RheSwgT2N0b2JlciAwOCwgMjAxNSA2OjA0IFBNDQpUbzogTWlrZSBKb25lczsgb2F1dGhA aWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFJldmlldyBjb21t ZW50cyB0byBQb1AgZG9jdW1lbnQNCg0KSGkgTWlrZSwNCg0KVGhhbmtzIGZvciB5b3VyIHJlc3Bv bnNlcy4NCg0KQWJvdXQgdGhlIGZpcnN0IHBhcmFncmFwaCBpbiB0aGUgaW50cm9kdWN0aW9uLCBJ IHdvdWxkIHByZWZlciB0byBtYWtlIGl0IGRpZmZlcmVudCBmcm9tIHRoZSBzYW1lIG9uZSBpbiB0 aGUgYWJzdHJhY3QuDQoNCkkgYW0gZmluZSB3aXRoIG90aGVycy4NCg0KS2luZCBSZWdhcmRzDQpL ZXBlbmcNCg0K5Y+R5Lu25Lq6OiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQrml6XmnJ86IEZyaWRheSwg OSBPY3RvYmVyLCAyMDE1IDE6NTggYW0NCuiHszogTGkgS2VwZW5nIDxrZXBlbmcubGtwQGFsaWJh YmEtaW5jLmNvbTxtYWlsdG86a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb20+PiwgIm9hdXRoQGll dGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4iIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1 dGhAaWV0Zi5vcmc+Pg0K5Li76aKYOiBSRTogUmV2aWV3IGNvbW1lbnRzIHRvIFBvUCBkb2N1bWVu dA0KDQpUaGFua3MgZm9yIHRoZSB1c2VmdWwgcmV2aWV3LCBLZXBlbmcuICBSZXNwb25zZXMgaW5s aW5l4oCmDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEtlcGVuZyBMaQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDA3LCAyMDE1IDc6 MzAgQU0NClRvOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBbT0FVVEgtV0ddIFJldmlldyBjb21tZW50cyB0byBQb1AgZG9jdW1lbnQNCg0KSGVsbG8gYWxs LA0KDQpQbGVhc2UgZmluZCBteSByZXZpZXcgY29tbWVudHMgdG8gUG9QIGRvY3VtZW50Og0KaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNz aW9uLTA0PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHAlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLW9hdXRoLXBy b29mLW9mLXBvc3Nlc3Npb24tMDQmZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jv c29mdC5jb20lN2MzOWZjMzY3YmZjMDQ0ZmU5MjQzYzA4ZDJjZjIzZDk1YiU3YzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1YTlg4OWwyMUd6Q29LRHprUXVmZE4xdkY5 VnNHcU9wTnBXcDlNNnl5cUFRJTNkPg0KDQoNCjHjgIEgICAgICAgICAgVGl0bGU6DQpQcm9vZi1v Zi1Qb3NzZXNzaW9uIEtleSBTZW1hbnRpY3MgZm9yIEpTT04gV2ViIFRva2VucyAoSldUcykNCltL ZXBlbmddIFNob3VsZCB3ZSBhZGQgT0F1dGggMi4wIGluIHRoZSB0aXRsZT8gQWxzbywgaW4gdGhl IHdob2xlIGRvY3VtZW50LCB3ZSB1c2UgSldULCBidXQgaW4gdGhlIHRpdGxlLCB3ZSB1c2Ug4oCc SldUc+KAnS4gSXMgdGhlcmUgYSByZWFzb24gZm9yIHRoaXM/DQoNCkkgd291bGRu4oCZdCBzdWdn ZXN0IGFkZGluZyDigJxPQXV0aCAyLjDigJ0gdG8gdGhlIHRpdGxlLCBpbiBwYXJ0LCBiZWNhdXNl IEpXVHMgYXJlIHVzZWQgaW4gY29udGV4dHMgb3V0c2lkZSBvZiBPQXV0aC4gIEFzIGZvciB3aHkg SldUcyBpcyBwbHVyYWwgaGVyZSwgdGhlIHRpdGxlIGlzIHNheWluZyB0aGF0IFBvUCBrZXlzIGNh biBiZSBjb21tdW5pY2F0ZWQgaW4gSlNPTiBXZWIgVG9rZW5zLiAgSWYgaXQgd2VyZSBzaW5ndWxh ciwgaXQgd291bGQgc291bmQgbGlrZSB5b3UgY291bGQgb25seSB1c2UgUG9QIGtleXMgaW4gYSBz aW5nbGUgSldULCB3aGljaCBpc27igJl0IHJpZ2h0Lg0KDQoNCjLjgIEgICAgICAgICAgQWJzdHJh Y3TvvJoNCjEpIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGhvdyB0byBleHByZXNzIGEgZGVj bGFyYXRpb24gaW4gYSBKU09OIFdlYiBUb2tlbiAoSldUKSB0aGF0IHRoZSBwcmVzZW50ZXIgb2Yg dGhlIEpXVCBwb3NzZXNzZXMgYSBwYXJ0aWN1bGFyIGtleSBhbmQgdGhhdCB0aGUgcmVjaXBpZW50 IGNhbiBjcnlwdG9ncmFwaGljYWxseSBjb25maXJtIHByb29mLW9mLXBvc3Nlc3Npb24gb2YgdGhl IGtleSBieSB0aGUgcHJlc2VudGVyLg0KW0tlcGVuZ10gQWRkIHJlZmVyZW5jZSB0byBKV1QuDQoN CknigJl2ZSBiZWVuIHRvbGQgd2hlbiBlZGl0aW5nIG90aGVyIGRyYWZ0cyB0byByZW1vdmUgcmVm ZXJlbmNlcyB0aGF0IEnigJlkIHBsYWNlZCBpbiBhYnN0cmFjdHMsIHNpbmNlIElFVEYgYWJzdHJh Y3RzIGRvbuKAmXQgaW5jbHVkZSByZWZlcmVuY2VzLg0KDQoyKSBUaGlzIHByb3BlcnR5IGlzIGFs c28gc29tZXRpbWVzIGRlc2NyaWJlZCBhcyB0aGUgcHJlc2VudGVyIGJlaW5nIGEgaG9sZGVyLW9m LWtleS4NCltLZXBlbmddIEkgYW0gbm90IHN1cmUgd2hhdCBpcyDigJx0aGlzIHByb3BlcnR54oCd LiBEbyB5b3UgbWVhbiDigJx0aGUga2V54oCdPyBJZiB5ZXMsIGp1c3QgdXNlIHRoZSBrZXkuIEFu ZCBjaGFuZ2UgdGhlIHNlbnRlbmNlIHRvIHNvbWV0aGluZyBsaWtlOiBUaGlzIGtleSBpcyBhbHNv IHNvbWV0aW1lcyBkZXNjcmliZWQgYXMgYSBob2xkZXItb2Yta2V5IGJ5IHRoZSBwcmVzZW50ZXIu DQoNCkkgY2FuIGNoYW5nZSDigJxUaGlzIHByb3BlcnR54oCdIHRvIOKAnEJlaW5nIGFibGUgdG8g cHJvdmUgcG9zc2Vzc2lvbiBvZiBhIGtleeKAnS4NCg0KMy4gSW50cm9kdWN0aW9uDQoxKSBUaGUg Zmlyc3QgcGFyYWdyYXBoIGlzIHRoZSBzYW1lIGFzIHRoZSBhYnN0cmFjdC4gSSBzdWdnZXN0IHRv IHJld29yZCBpdCBhIGxpdHRsZSBiaXQgb3IgcmVtb3ZlIGl0LCB0byBhdm9pZCB0aGUgcmVkdW5k YW5jeS4NCg0KVGhlIHJlc3Qgb2YgdGhlIGludHJvZHVjdGlvbiBidWlsZHMgb24gdGhlIGlkZWFz IGludHJvZHVjZWQgaW4gdGhlIGZpcnN0IHR3byBzZW50ZW5jZXMgKHRoZSBjb250ZW50IG9mIHRo ZSBhYnN0cmFjdCkuIElmIHRoZXkgd2VyZSB0byBiZSByZW1vdmVkLCBpdCB3b3VsZCBtYWtlIHRo ZSBpbnRyb2R1Y3Rpb24gY29uZnVzaW5nLCBhcyBtYW55IHBlb3BsZSB3b27igJl0IHN0YXJ0IGJ5 IHJlYWRpbmcgdGhlIGFic3RyYWN0LCBidXQgd2lsbCByZWFkIHRoZSBpbnRyb2R1Y3Rpb24gaW5k ZXBlbmRlbnRseS4gIChUaGUgaW50cm9kdWN0aW9uIGRvZXMgYWRkIHJlZmVyZW5jZXMsIHdoaWNo IGNhbm5vdCBiZSBwcmVzZW50IGluIHRoZSBhYnN0cmFjdC4pICBJ4oCZbGwgd29yayB3aXRoIHRo ZSBvdGhlciBlZGl0b3JzIHRvIHNlZSBpZiB0aGV5IHdhbnQgdG8gcmV3b3JkIHRoZSBmaXJzdCB0 d28gc2VudGVuY2VzIG9mIHRoZSBpbnRyb2R1Y3Rpb24gYW5kL29yIGFic3RyYWN0IHRvIG1ha2Ug dGhlbSBkaWZmZXJlbnQgZnJvbSBvbmUgYW5vdGhlci4NCg0KMikgU2VlIFtJLUQuaWV0Zi1vYXV0 aC1wb3AtYXJjaGl0ZWN0dXJlXSBmb3IgYSBmdXJ0aGVyIGRpc2N1c3Npb24gb2Yga2V5IGNvbmZp cm1hdGlvbi4NCltLZXBlbmddIEkgc3VnZ2VzdCB0byBtZW50aW9uIGEgbGl0dGxlIGJpdCBtb3Jl IGFib3V0IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBQb1AgYXJjaGl0ZWN0dXJlIGRvY3VtZW50 IGFuZCB0aGlzIGRvY3VtZW50LiBJbiBteSB1bmRlcnN0YW5kaW5nLCBpbiBQb1AgYXJjaGl0ZWN0 dXJlIGRvY3VtZW50LCBpdCBtZW50aW9ucyBzZXZlcmFsIG1lY2hhbmlzbXM6IGNvbmZpZGVudGlh bGl0eSBwcm90ZWN0aW9uLCBrZXkgY29uZmlybWF0aW9uIGFuZCBzZW5kZXIgY29uc3RyYWludC4g VGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIHRoZSBrZXkgc2VtYW50aWNzIGZvciB0aGUga2V5IGNv bmZpcm1hdGlvbiBtZWNoYW5pc20uDQoNCk9LIOKAkyB3ZSBjYW4gc2F5IHRoYXQgW0ktRC5pZXRm LW9hdXRoLXBvcC1hcmNoaXRlY3R1cmVdIGRlc2NyaWJlcyBrZXkgY29uZmlybWF0aW9uLCBhbW9u ZyBvdGhlciBjb25mb3JtYXRpb24gbWVjaGFuaXNtcywgYW5kIHRoYXQgdGhpcyBzcGVjaWZpY2F0 aW9uIGRlZmluZXMgaG93IHRvIGNvbW11bmljYXRlIGtleSBjb25maXJtYXRpb24ga2V5IGluZm9y bWF0aW9uIGluIEpXVHMuDQoNCjMpIEFib3V0IHRoZSB0d28gdXNlIGNhc2VzLCBpdCB3aWxsIGJl IHVzZWZ1bCB0byB1c2UgdHdvIGRpYWdyYW1zIG9yIGZsb3dzIHRvIGluZGljYXRlIGhvdyBpdCB3 b3Jrcy4gTWF5YmUgcHV0IHRoZXNlIHR3byBmbG93cyBpbiBhIHNlcGFyYXRlIHNlY3Rpb24uIEFs c28gaXQgd2lsbCBiZSB1c2VmdWwgdG8gbWVudGlvbiB3aGljaCBzdGVwIGlzIGluIHNjb3BlLCBh bmQgd2hpY2ggaXMgb3V0IG9mIHNjb3BlLCBlLmcuIGhvdyB0byBjb252ZXkgc3ltbWV0cmljIGtl eSBmcm9tIHRoZSBpc3N1ZXIgdG8gdGhlIHByZXNlbnRlci4NCg0KQm90aCBhcmUgaW4gc2NvcGUs IHdoaWNoIGlzIHdoeSB0aGV54oCZcmUgYm90aCBkZXNjcmliZWQgaW4gdGhlIGludHJvZHVjdGlv bi4gIEnigJlsbCB3b3JrIHdpdGggdGhlIG90aGVyIGVkaXRvcnMgb24gdHJ5aW5nIHRvIGNyZWF0 ZSBhcHByb3ByaWF0ZSBkaWFncmFtcy4NCg0KNC4gU2VjdGlvbiAzOg0KMSkgSXQgd2lsbCBiZSB1 c2VmdWwgdG8gcHV0IGEgcmVmZXJlbmNlIHRvICJzdWIiIChzdWJqZWN0KSBjbGFpbSwgYW5kICJp c3MiIChpc3N1ZXIpIGNsYWltLg0KDQpPSw0KDQoyKSBOb3RlIHRoYXQgaWYgYW4gYXBwbGljYXRp b24gbmVlZHMgdG8gcmVwcmVzZW50IG11bHRpcGxlIHByb29mLW9mLQ0KICAgcG9zc2Vzc2lvbiBr ZXlzIGluIHRoZSBzYW1lIEpXVCwgb25lIHdheSBmb3IgaXQgdG8gYWNoaWV2ZSB0aGlzIGlzIHRv DQogICB1c2Ugb3RoZXIgY2xhaW0gbmFtZXMsIGluIGFkZGl0aW9uIHRvICJjbmYiLCB0byBob2xk IHRoZSBhZGRpdGlvbmFsDQogICBwcm9vZi1vZi1wb3NzZXNzaW9uIGtleSBpbmZvcm1hdGlvbi4N CltLZXBlbmddIEl0IGlzIG5vdCBjbGVhciwgd2hhdCBhcmUgdGhlIG90aGVyIGNsYWltIG5hbWVz Pw0KDQpGYWlyIHBvaW50LiAgV2UgY2FuIHNheSB0aGF0IHRob3NlIGNsYWltIG5hbWVzIHdvdWxk IGJlIGRlZmluZWQgYnkgYXBwbGljYXRpb25zIGFuZCBjb3VsZCBiZSByZWdpc3RlcmVkIGluIHRo ZSBKV1QgQ2xhaW1zIFJlZ2lzdHJ5Lg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFu a3MgYWdhaW4hDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLSBNaWtlDQo= --_000_BY2PR03MB442A8B1F9A79AA027C224E1F53A0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMg MSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYW1icmlh Ow0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToy IDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3Vu IjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWdu Omp1c3RpZnk7DQoJdGV4dC1pbmRlbnQ6MjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MDAyMDYwO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzAwMjA2MDt9DQpz cGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6 MTU5NzMyNDEyNDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MzY1MDQxMzEwIC01NjE4NDkxMDAgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC10ZXh0OiUx44CBOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjVpbjt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRleHQ6IiUyXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo0OC4wcHQ7DQoJdGV4dC1pbmRl bnQ6LTI0LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDoxLjBpbjsNCgl0ZXh0LWluZGVudDotMjQu MHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6OTYuMHB0Ow0KCXRleHQt aW5kZW50Oi0yNC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlNVwpIjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6MTIwLjBwdDsNCgl0ZXh0LWluZGVudDotMjQuMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjIu MGluOw0KCXRleHQtaW5kZW50Oi0yNC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDoxNjguMHB0Ow0KCXRleHQtaW5kZW50Oi0yNC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0 OiIlOFwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTkyLjBwdDsNCgl0ZXh0LWluZGVudDotMjQuMHB0 O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjMuMGluOw0KCXRleHQtaW5kZW50Oi0yNC4wcHQ7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPkZZSSwgSSBwb3N0ZWQgYWJvdXQgdGhl IGF2YWlsYWJpbGl0eSBvZiB0aGUgbmV3IGRyYWZ0IGF0DQo8YSBocmVmPSJodHRwOi8vc2VsZi1p c3N1ZWQuaW5mby8/cD0xNDY4Ij5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNDY4PC9hPiBh bmQgYXMNCjxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vc2VsZmlzc3VlZCI+QHNlbGZpc3N1 ZWQ8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIg MTksIDIwMTUgNDowMiBQTTxicj4NCjxiPlRvOjwvYj4gS2VwZW5nIExpOyBvYXV0aEBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZXZpZXcgY29tbWVudHMgdG8g UG9QIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPkhpIEtlcGVuZyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj5EcmFm dCAtMDUgYWRkcmVzc2VzIGFsbCB5b3VyIHJldmlldyBjb21tZW50cyBhcyBhZ3JlZWQgYmVsb3cs IG90aGVyIHRoYW4gYWRkaW5nIHRoZSBkaWFncmFtcyB0aGF0IHlvdSByZXF1ZXN0ZWQuJm5ic3A7 IEnigJlsbCBwbGFuIG9uIHdvcmtpbmcgb24gdGhvc2UgYmV0d2VlbiBub3cgYW5kIFlva29oYW1h IGFuZCBzdWJtaXR0aW5nIGFuIHVwZGF0ZWQNCiBkcmFmdCB3aXRoIHRoZSBkaWFncmFtcyB3aGVu IHRoZSBzdWJtaXNzaW9uIHBlcmlvZCBvcGVucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAy MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj5UaGFua3MgYWdhaW4g Zm9yIHlvdXIgdXNlZnVsIHJldmlldyBvZiB0aGlzIGRyYWZ0LiZuYnNwOyBJIGFkZGVkIHlvdSB0 byB0aGUgYWNrbm93bGVkZ2VtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQmVzdCB3 aXNoZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p a2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBLZXBlbmcgTGkgWzxhIGhyZWY9Im1haWx0bzprZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNv bSI+bWFpbHRvOmtlcGVuZy5sa3BAYWxpYmFiYS1pbmMuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgT2N0b2JlciAwOCwgMjAxNSA2OjA0IFBNPGJyPg0KPGI+VG86PC9iPiBN aWtlIEpvbmVzOyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3Jn PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUmV2aWV3IGNvbW1lbnRzIHRvIFBvUCBkb2N1 bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj5IaSBNaWtlLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2lt U3VuO2NvbG9yOmJsYWNrIj5UaGFua3MgZm9yIHlvdXIgcmVzcG9uc2VzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9y OmJsYWNrIj5BYm91dCB0aGUgZmlyc3QgcGFyYWdyYXBoIGluIHRoZSBpbnRyb2R1Y3Rpb24sIEkg d291bGQgcHJlZmVyIHRvIG1ha2UgaXQgZGlmZmVyZW50IGZyb20gdGhlIHNhbWUgb25lIGluIHRo ZSBhYnN0cmFjdC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTpTaW1TdW47Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+SSBhbSBmaW5lIHdpdGggb3Ro ZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj5LaW5kIFJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPktlcGVuZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuWPkeS7tuS6ujwvc3Bhbj48 L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPjoNCjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPk1pa2UgSm9u ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5pel5pyf PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+ Og0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+ RnJpZGF5LCA5IE9jdG9iZXIsIDIwMTUgMTo1OCBhbTxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuiHszwv c3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPjoN Cjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkxp IEtlcGVuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlcGVuZy5sa3BAYWxpYmFiYS1pbmMuY29tIj5r ZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86 b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpi bGFjayI+5Li76aKYPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjpibGFjayI+Og0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjpibGFjayI+UkU6IFJldmlldyBjb21tZW50cyB0byBQb1AgZG9jdW1lbnQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYw Ij5UaGFua3MgZm9yIHRoZSB1c2VmdWwgcmV2aWV3LCBLZXBlbmcuJm5ic3A7IFJlc3BvbnNlcyBp bmxpbmXigKY8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiBPQXV0aCBbPGEgaHJl Zj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+S2VwZW5nIExpPGJyPg0KPGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgT2N0b2JlciAwNywgMjAxNSA3OjMwIEFNPGJyPg0KPGI+VG86PC9iPiA8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIFJldmlldyBjb21tZW50cyB0byBQb1AgZG9jdW1lbnQ8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0 ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBz dHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPkhlbGxvIGFsbCw8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIg c3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj5QbGVhc2UgZmluZCBteSByZXZpZXcgY29tbWVu dHMgdG8gUG9QIGRvY3VtZW50Ojwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8v bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZ0 b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Np b24tMDQmYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdj MzlmYzM2N2JmYzA0NGZlOTI0M2MwOGQyY2YyM2Q5NWIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPVhOWDg5bDIxR3pDb0tEemtRdWZkTjF2RjlWc0dxT3BO cFdwOU02eXlxQVElM2QiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1 dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wNDwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjHjgIE8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGl0bGU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Qcm9vZi1v Zi1Qb3NzZXNzaW9uIEtleSBTZW1hbnRpY3MgZm9yIEpTT04gV2ViIFRva2VucyAoSldUcyk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPltLZXBlbmddIFNob3VsZCB3ZSBhZGQgT0F1dGggMi4wIGluIHRoZSB0aXRsZT8g QWxzbywgaW4gdGhlIHdob2xlIGRvY3VtZW50LCB3ZSB1c2UgSldULCBidXQgaW4gdGhlIHRpdGxl LCB3ZSB1c2Ug4oCcSldUc+KAnS4gSXMgdGhlcmUgYSByZWFzb24gZm9yIHRoaXM/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj5JIHdvdWxkbuKAmXQg c3VnZ2VzdCBhZGRpbmcg4oCcT0F1dGggMi4w4oCdIHRvIHRoZSB0aXRsZSwgaW4gcGFydCwgYmVj YXVzZSBKV1RzIGFyZSB1c2VkIGluIGNvbnRleHRzIG91dHNpZGUgb2YgT0F1dGguJm5ic3A7IEFz IGZvciB3aHkgSldUcyBpcyBwbHVyYWwgaGVyZSwgdGhlIHRpdGxlIGlzIHNheWluZyB0aGF0IFBv UCBrZXlzIGNhbiBiZSBjb21tdW5pY2F0ZWQNCiBpbiBKU09OIFdlYiBUb2tlbnMuJm5ic3A7IElm IGl0IHdlcmUgc2luZ3VsYXIsIGl0IHdvdWxkIHNvdW5kIGxpa2UgeW91IGNvdWxkIG9ubHkgdXNl IFBvUCBrZXlzIGluIGEgc2luZ2xlIEpXVCwgd2hpY2ggaXNu4oCZdCByaWdodC48L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47 dGV4dC1pbmRlbnQ6LS41aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4y44CBPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPkFic3RyYWN0PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj7vvJo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQt YWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjEpIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGhvdyB0byBleHByZXNzIGEgZGVjbGFyYXRp b24gaW4gYSBKU09OIFdlYiBUb2tlbiAoSldUKSB0aGF0IHRoZSBwcmVzZW50ZXIgb2YgdGhlIEpX VCBwb3NzZXNzZXMgYSBwYXJ0aWN1bGFyIGtleSBhbmQgdGhhdCB0aGUNCiByZWNpcGllbnQgY2Fu IGNyeXB0b2dyYXBoaWNhbGx5IGNvbmZpcm0gcHJvb2Ytb2YtcG9zc2Vzc2lvbiBvZiB0aGUga2V5 IGJ5IHRoZSBwcmVzZW50ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6 bm9uZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5bS2VwZW5nXSBBZGQgcmVmZXJlbmNlIHRv IEpXVC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i bGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEzLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOiMwMDIwNjAi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGln bjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMwMDIwNjAiPknigJl2ZSBiZWVuIHRvbGQgd2hlbiBlZGl0aW5nIG90aGVyIGRyYWZ0 cyB0byByZW1vdmUgcmVmZXJlbmNlcyB0aGF0IEnigJlkIHBsYWNlZCBpbiBhYnN0cmFjdHMsIHNp bmNlIElFVEYgYWJzdHJhY3RzIGRvbuKAmXQgaW5jbHVkZSByZWZlcmVuY2VzLjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3Nw YWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MikgVGhp cyBwcm9wZXJ0eSBpcyBhbHNvIHNvbWV0aW1lcyBkZXNjcmliZWQgYXMgdGhlIHByZXNlbnRlciBi ZWluZyBhIGhvbGRlci1vZi1rZXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5bS2VwZW5nXSBJIGFtIG5vdCBzdXJl IHdoYXQgaXMg4oCcdGhpcyBwcm9wZXJ0eeKAnS4gRG8geW91IG1lYW4g4oCcdGhlIGtleeKAnT8g SWYgeWVzLCBqdXN0IHVzZSB0aGUga2V5LiBBbmQgY2hhbmdlIHRoZSBzZW50ZW5jZSB0byBzb21l dGhpbmcgbGlrZTogVGhpcyBrZXkgaXMgYWxzbyBzb21ldGltZXMgZGVzY3JpYmVkIGFzIGEgaG9s ZGVyLW9mLWtleSBieSB0aGUgcHJlc2VudGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+SSBjYW4gY2hhbmdlIOKAnFRoaXMgcHJvcGVydHnigJ0g dG8g4oCcQmVpbmcgYWJsZSB0byBwcm92ZSBwb3NzZXNzaW9uIG9mIGEga2V54oCdLjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+My4g SW50cm9kdWN0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xKSBUaGUgZmlyc3QgcGFyYWdyYXBoIGlzIHRoZSBz YW1lIGFzIHRoZSBhYnN0cmFjdC4gSSBzdWdnZXN0IHRvIHJld29yZCBpdCBhIGxpdHRsZSBiaXQg b3IgcmVtb3ZlIGl0LCB0byBhdm9pZCB0aGUgcmVkdW5kYW5jeS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzAwMjA2MCI+VGhlIHJlc3Qgb2YgdGhlIGludHJvZHVjdGlvbiBidWlsZHMgb24gdGhlIGlk ZWFzIGludHJvZHVjZWQgaW4gdGhlIGZpcnN0IHR3byBzZW50ZW5jZXMgKHRoZSBjb250ZW50IG9m IHRoZSBhYnN0cmFjdCkuIElmIHRoZXkgd2VyZSB0byBiZSByZW1vdmVkLCBpdCB3b3VsZCBtYWtl IHRoZSBpbnRyb2R1Y3Rpb24gY29uZnVzaW5nLCBhcw0KIG1hbnkgcGVvcGxlIHdvbuKAmXQgc3Rh cnQgYnkgcmVhZGluZyB0aGUgYWJzdHJhY3QsIGJ1dCB3aWxsIHJlYWQgdGhlIGludHJvZHVjdGlv biBpbmRlcGVuZGVudGx5LiZuYnNwOyAoVGhlIGludHJvZHVjdGlvbiBkb2VzIGFkZCByZWZlcmVu Y2VzLCB3aGljaCBjYW5ub3QgYmUgcHJlc2VudCBpbiB0aGUgYWJzdHJhY3QuKSZuYnNwOyBJ4oCZ bGwgd29yayB3aXRoIHRoZSBvdGhlciBlZGl0b3JzIHRvIHNlZSBpZiB0aGV5IHdhbnQgdG8gcmV3 b3JkIHRoZSBmaXJzdCB0d28gc2VudGVuY2VzDQogb2YgdGhlIGludHJvZHVjdGlvbiBhbmQvb3Ig YWJzdHJhY3QgdG8gbWFrZSB0aGVtIGRpZmZlcmVudCBmcm9tIG9uZSBhbm90aGVyLjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGln bjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Mikg U2VlIFtJLUQuaWV0Zi1vYXV0aC1wb3AtYXJjaGl0ZWN0dXJlXSBmb3IgYSBmdXJ0aGVyIGRpc2N1 c3Npb24gb2Yga2V5IGNvbmZpcm1hdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1 dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPltLZXBlbmddIEkgc3VnZ2Vz dCB0byBtZW50aW9uIGEgbGl0dGxlIGJpdCBtb3JlIGFib3V0IHRoZSByZWxhdGlvbnNoaXAgYmV0 d2VlbiBQb1AgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGFuZCB0aGlzIGRvY3VtZW50LiBJbiBteSB1 bmRlcnN0YW5kaW5nLCBpbiBQb1AgYXJjaGl0ZWN0dXJlDQogZG9jdW1lbnQsIGl0IG1lbnRpb25z IHNldmVyYWwgbWVjaGFuaXNtczogY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24sIGtleSBjb25m aXJtYXRpb24gYW5kIHNlbmRlciBjb25zdHJhaW50LiBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMg dGhlIGtleSBzZW1hbnRpY3MgZm9yIHRoZSBrZXkgY29uZmlybWF0aW9uIG1lY2hhbmlzbS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5 bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5v bmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPk9LIOKAkyB3 ZSBjYW4gc2F5IHRoYXQgW0ktRC5pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmVdIGRlc2NyaWJl cyBrZXkgY29uZmlybWF0aW9uLCBhbW9uZyBvdGhlciBjb25mb3JtYXRpb24gbWVjaGFuaXNtcywg YW5kIHRoYXQgdGhpcw0KIHNwZWNpZmljYXRpb24gZGVmaW5lcyBob3cgdG8gY29tbXVuaWNhdGUg a2V5IGNvbmZpcm1hdGlvbiBrZXkgaW5mb3JtYXRpb24gaW4gSldUcy48L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpu b25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0 ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjMpIEFib3V0IHRo ZSB0d28gdXNlIGNhc2VzLCBpdCB3aWxsIGJlIHVzZWZ1bCB0byB1c2UgdHdvIGRpYWdyYW1zIG9y IGZsb3dzIHRvIGluZGljYXRlIGhvdyBpdCB3b3Jrcy4gTWF5YmUgcHV0IHRoZXNlIHR3byBmbG93 cyBpbiBhIHNlcGFyYXRlIHNlY3Rpb24uIEFsc28NCiBpdCB3aWxsIGJlIHVzZWZ1bCB0byBtZW50 aW9uIHdoaWNoIHN0ZXAgaXMgaW4gc2NvcGUsIGFuZCB3aGljaCBpcyBvdXQgb2Ygc2NvcGUsIGUu Zy4gaG93IHRvIGNvbnZleSBzeW1tZXRyaWMga2V5IGZyb20gdGhlIGlzc3VlciB0byB0aGUgcHJl c2VudGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3Nw YWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPkJv dGggYXJlIGluIHNjb3BlLCB3aGljaCBpcyB3aHkgdGhleeKAmXJlIGJvdGggZGVzY3JpYmVkIGlu IHRoZSBpbnRyb2R1Y3Rpb24uJm5ic3A7IEnigJlsbCB3b3JrIHdpdGggdGhlIG90aGVyIGVkaXRv cnMgb24gdHJ5aW5nIHRvIGNyZWF0ZSBhcHByb3ByaWF0ZQ0KIGRpYWdyYW1zLjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3Nw YWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFs aWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj40 LiBTZWN0aW9uIDM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xKSBJdCB3aWxsIGJlIHVzZWZ1bCB0byBwdXQgYSBy ZWZlcmVuY2UgdG8gJnF1b3Q7c3ViJnF1b3Q7IChzdWJqZWN0KSBjbGFpbSwgYW5kICZxdW90O2lz cyZxdW90OyAoaXNzdWVyKSBjbGFpbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9z cGFjZTpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3Bh Y2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+T0s8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0 ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MDAyMDYwIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRl eHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjIpIE5vdGUgdGhhdCBpZiBhbiBhcHBsaWNhdGlvbiBuZWVkcyB0byByZXByZXNlbnQgbXVs dGlwbGUgcHJvb2Ytb2YtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9u ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcG9zc2Vzc2lvbiBrZXlz IGluIHRoZSBzYW1lIEpXVCwgb25lIHdheSBmb3IgaXQgdG8gYWNoaWV2ZSB0aGlzIGlzIHRvPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0 eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdXNlIG90aGVyIGNsYWltIG5hbWVzLCBpbiBhZGRpdGlv biB0byAmcXVvdDtjbmYmcXVvdDssIHRvIGhvbGQgdGhlIGFkZGl0aW9uYWw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQt YWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBwcm9vZi1vZi1wb3NzZXNzaW9uIGtleSBpbmZvcm1hdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9 InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPltLZXBlbmddIEl0IGlzIG5vdCBjbGVhciwgd2hhdCBhcmUgdGhlIG90aGVyIGNsYWlt IG5hbWVzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i bGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj5GYWlyIHBvaW50LiZuYnNwOyBX ZSBjYW4gc2F5IHRoYXQgdGhvc2UgY2xhaW0gbmFtZXMgd291bGQgYmUgZGVmaW5lZCBieSBhcHBs aWNhdGlvbnMgYW5kIGNvdWxkIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIEpXVCBDbGFpbXMgUmVnaXN0 cnkuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxl ZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxl PSJ0ZXh0LWFsaWduOmxlZnQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5LaW5kIFJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdDt0ZXh0LWF1dG9zcGFj ZTpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPktlcGVuZzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGln bjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBz dHlsZT0idGV4dC1hbGlnbjpsZWZ0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgYWdhaW4h PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7 dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB442A8B1F9A79AA027C224E1F53A0BY2PR03MB442namprd_-- From nobody Tue Oct 20 00:37:42 2015 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 B292F1B2A62 for ; Tue, 20 Oct 2015 00:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2yIDHyqbcLBY for ; Tue, 20 Oct 2015 00:37:38 -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 4BB011B29B1 for ; Tue, 20 Oct 2015 00:37:38 -0700 (PDT) Received: from [192.168.131.140] ([80.92.122.73]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MOw4N-1Zs1iZ12s3-006O3D; Tue, 20 Oct 2015 09:37:28 +0200 To: Bill Mills References: <56170ECA.1050107@gmx.net> <1406710217.1116396.1444352146959.JavaMail.yahoo@mail.yahoo.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <5625EEFD.1000109@gmx.net> Date: Tue, 20 Oct 2015 09:36:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1406710217.1116396.1444352146959.JavaMail.yahoo@mail.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q1qglQn9JKT55cHhAtrGTCRAdRMsqmuVF" X-Provags-ID: V03:K0:tSg17DVcPVVywQtkHcAEm8VADsPxZ4URzaRIp6+UnOTxA0oHl9x Eu0GDMu98I6yzUB8yDDciUA9MxynkAZN4LOGL6Q+B5yFA+z0EVlc1egMTNSbXMKNCwzULlK idm/CBavwSLnUq/iE6ZbNQBK8maXrzzz90J+43mxI8NDzdw02Zcpr23+WVw4q0xePNBUG3T G+FpyX425uP7wFW2Ly4Pw== X-UI-Out-Filterresults: notjunk:1;V01:K0:GVaiHKYRScU=:sBJ/zbsAxkoXLN0R2+1LOy Of6wl+hXXD9le55mnKAdiFOS2gQr2o8XdDrvij9vFTi7YRxvvye+psSTs5nDjYKjfBOq6mwkW ctH+4eykFgFJYrcx5sA5Fd+nPwcm1TKInzdQhBKB4Ji53lFKtflgSDc++WIUXrTWvbWBwFoAU 7f9gCQqHcuYPqEPzEBNCwOAr+X5FJVvPRfujPgiFZKAnzyaFJ7jRYjJ6mb+bNzMgKQuUomI6I KxfbVpUCJvG6vlIGMrBnLQ1tfMgHEkWV+1MzqiaoZjqwKSBX2mKxPR5rxsNcXvnu0hIrAJU1j A4CL4Xsy75n/6suLVwI33lLf5CqSNUAU9ud1lPV8mmcoUwHqDVUIc+UlNk3EpZbfjo59nsk6m /ZiPhBoEcnubhgHaIDIN3yXt2lFDxwePm/6KSdgrIQxkJhe8XonW89SAvHNXzJcd+C2SS2mP8 W+vGXNY6P0yLKeVjNm2waEFrhzoPxrRHFSMX/PVtxovDH4H+MA11hdKE47EOrE7cPNReqHHUL Z1NvO6ra/rtLUeTBE/44PPei3nJ9bevpnyrK6bzARD2YbXt2wS+cIAYlt1YHf4eBNRGfLeZ4C gAqIF+Owrj2eipgfDsumWdiNkRLwjU/ul5qxDasxZoSsm2bcJphM/YTTtdSAC+cJRoYOTnPGH 5x8Qdb0TCG++JyB3OSajsdzDeiPoBUXgJOEFWL+w/nNcfsCmdlL6QTaQHpQkBupB8giY53VYv 9Gsb3lL6Svqbq9xQdtsOANZweAUJa0iFPPRiS4wQszgulfNQROhrbu7Ef1U= Archived-At: Cc: "oauth@ietf.org" Subject: [OAUTH-WG] PoP Architecture - IPR Confirmation 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, 20 Oct 2015 07:37:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q1qglQn9JKT55cHhAtrGTCRAdRMsqmuVF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bill, sorry to bother you again regarding this IPR issue but when I search through the OAuth mailing list archive then I cannot find a response from you to this mail from Kepeng: http://www.ietf.org/mail-archive/web/oauth/current/msg14980.html Ciao Hannes PS: I only see a single response from you on the list http://www.ietf.org/mail-archive/web/oauth/current/maillist.html, namely this email: http://www.ietf.org/mail-archive/web/oauth/current/msg15002.html Unfortunately, that mail was a call for IPR confirmation to the 'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' specificat= ion (draft-ietf-oauth-proof-of-possession-04) and not to the architecture draft. On 10/09/2015 02:55 AM, Bill Mills wrote: > I responded correctly Thursday. >=20 >=20 >=20 > On Thursday, October 8, 2015 5:48 PM, Hannes Tschofenig > wrote: >=20 >=20 > Hi Bill, >=20 > you have unfortunately responded to the wrong mail ;-) >=20 > Please respond to this one: > http://www.ietf.org/mail-archive/web/oauth/current/msg14980.html > (which is about the PoP architecture > ). >=20 > Sorry to bother you with these issues. >=20 > Ciao > Hannes >=20 > On 09/30/2015 04:10 PM, Bill Mills wrote: >> I am aware of no IPR issues for this document. >> >> Regards, >> >> -bill >> >> >> >> On Wednesday, September 30, 2015 3:53 AM, John Bradley >> > wrote: >> >> >> I confirm that I know of no IPR that reads on this specification. >> >> John Bradley=E2=80=99 >> >>> On Sep 30, 2015, at 7:03 AM, Kepeng Li >>> >> wrote: >>> >>> Hi Mike, John and Hannes, >>> I am working on the shepherd writeup for the PoP document: >>> http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04 >>> >>> One item in the template requires me to indicate whether each documen= t >>> author has confirmed that any and all appropriate IPR disclosures >>> required for full conformance with the provisions of BCP 78 and BCP 7= 9 >>> have already been filed. Could you please confirm? Kind Regards >>> Kepeng >>> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org > >=20 >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >=20 >=20 --Q1qglQn9JKT55cHhAtrGTCRAdRMsqmuVF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWJe79AAoJEGhJURNOOiAtHRMIAIhi59Qguws+oHNCAOViBjPh DF45CcVqyR036ECYkWfKUnfELp69fV09JQh6cQ61YQsE7vmOnKuEIt7B6j2DknxP h6y9uPyQ1WSVaudlKGlOAbf/N0VlQAwTMmnQKA9LHBgwkt1S1+75auRdXF2kuwvM zSOHDT2lWCv6eU9Z/EJk73A9LSFBuzuOu+W1rmd+ysdI1MRk1/ePKvp4lWnj8IPH OKNvlWe4gT/oS+mE1xW4gI3Ff2VbMNLVrJ8Nr8ZFFRMfOkXQxyERnMZJZhpXonzS hX+z9s8r+/eHjVMrYcJBCqfyVhkoiuP1oTGTRQiBYe+8FE1O+SsmiytlZu0CZVw= =ikN4 -----END PGP SIGNATURE----- --Q1qglQn9JKT55cHhAtrGTCRAdRMsqmuVF-- From nobody Tue Oct 20 02:03:29 2015 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 9C18E1A7025 for ; Tue, 20 Oct 2015 02:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0X-bsanAd-n6 for ; Tue, 20 Oct 2015 02:03:26 -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 03E2D1A7022 for ; Tue, 20 Oct 2015 02:03:26 -0700 (PDT) Received: from [192.168.131.140] ([80.92.122.73]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LskKv-1aZBUz0sTB-012Kdn for ; Tue, 20 Oct 2015 11:03:24 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5626032F.7070700@gmx.net> Date: Tue, 20 Oct 2015 11:02:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KAPr52WTMffh9Fv0jKa54aT8b5n4DaoSt" X-Provags-ID: V03:K0:nGNJTtkFAmmuvej8+i3zNbSDRdj4Tpr8Lp9rxlOwdEZ0Tg+B+xM dtnGYobmLgPPANLEc6QzPEjAPbNCyMz5RlgPe6UR3W3drEWKO4gFKvqV2Wo0xo2F1Eq32j/ GNzSIAPRCNV89dTmgNqcnyrku2GcGQTEuc6smdN/c+YWQJ/DbvGkwpO3Ss1Fi14/2TWvTuX gY9tBrB/WlljRnJob77CQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Xwt54GshQoM=:hu+WzYIGe6Z44dr23+4Z2F w0Ncmw0IQo4njPYN/WFckXTSSX8qMAFcGcEje9q79y7Pd2KKCXDxRItkR8J7ij02VQKtYZVLZ XQzOIiHV6Rr2W+9+2CgpSYgyuNupiVHpsC9vv9GMAM0MnlH+5NOE05rqfyZb6jiJzUZCz8Kux qAdSNiTX0gc/5mu8ltlbo2wDo8FtRjZ6Yw9Z9qAqRg+7e3Jug9hnAQeLDsEEeyWK1GhotwvLH WrFz5OytQGXSXlH5ttkNAD6ZQskBCuRbaquJxkxvTXYdQuqBBxl2pgiR9CWYXj8HDo5MC4P4M hYn+tSi8TzvnTxTzJVmW3mRjmMWfSE6eIhPPlfS4V3mIKlcWlM3lOkWPiqO9E2FgJ6gt+BUUk yh6EeXvnKcAqXy+MO0G4LuXdER4Jy9NdZCEjzomdBpmrMAPK7DLaXCU8ihnrsirfFDXnShAUO KjMBxZXSndf366I15Gmeb3WR5A456X3U4uccdD68exOFjqLMdIrzrn8LP/xlfAwygFM5b980o ELmLgI/JZUgr3mptFLFtyc9cd4OBJkiG8Ncf37HlzeCz7HTlwqy6/CSYpiIc11cV7rzvUAfo9 QKB4pxftsfiLFMU3FvHYd1HDUk1q/o/5xO+uAfg7M2UF0za56WivOiWFe8Fj/Vx1l2Z93hp8s 5hzLqhv/+2u+REvmqWsvFPpjDRrIby5KRxGGxAdPR7MwP91zMfQwujshW5x+tYhzKw1Ptjvks g05YQJNOf3BGK9WX5hMMZfbaD029pP1z9qLZuIA1QjcKqekrohB+FCbbZ48= Archived-At: Subject: [OAUTH-WG] WGLC for draft-ietf-oauth-jwsreq-06 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, 20 Oct 2015 09:03:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KAPr52WTMffh9Fv0jKa54aT8b5n4DaoSt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, we would like to start a WGLC on draft-ietf-oauth-jwsreq-06: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06 This will be a 2-week last call, so it will end on November 3rd. The WGLC timing is good since our OAuth meeting in Yokohama is on the Thursday, November 5th and you might want to prepare for the WG session anyway. Please send comments to the list. Ciao Hannes --KAPr52WTMffh9Fv0jKa54aT8b5n4DaoSt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWJgMwAAoJEGhJURNOOiAtv8QH/1QBz39tOggqmbUjbtcNtEzo QUPuXo5JF8hZ7lBuGdHG9dFl8jYKqX3D41nN7pswUm3xWTM6Nxy2i9Iyf+ZCbmWN SbSgcCJFS5AG2QP8bROMFEnMhaVm6URvJXTxYEqf1k9q//b3ZXQd1Du9SfMxneUR 03ljp0Un5KcIkgxv9x3bPjC5LWzLi4xBknE3t2HzEW17B58fayflE9QCqPfskfK5 bwWdW57xuv00FvMKr/NSdbyczlmlQlB2rlM2YhxYvWeHNM6A6iJ3RU8R1c8/qXc7 MBkKLmnq9NUzY3yzF4wyZzET+MABRfmlNl4WpQpZ8dxX5e+ZQ5Euo4hbVDcg93E= =J3Uo -----END PGP SIGNATURE----- --KAPr52WTMffh9Fv0jKa54aT8b5n4DaoSt-- From nobody Tue Oct 20 08:31:01 2015 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 34FEE1B3412 for ; Tue, 20 Oct 2015 08:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Zhstai3FB_-4 for ; Tue, 20 Oct 2015 08:30:56 -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 6243D1B341B for ; Tue, 20 Oct 2015 08:28:39 -0700 (PDT) Received: from [192.168.131.140] ([80.92.122.73]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lcjdr-1aDkhe0oK7-00k5RG for ; Tue, 20 Oct 2015 17:28:37 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56265D7F.4010007@gmx.net> Date: Tue, 20 Oct 2015 17:27:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="caX3VhKOFrHgmxH0NeBdUhToDW5PmM35K" X-Provags-ID: V03:K0:8oWuDKrij5K4t9rTAfviR/Hh5HVaw3PRtx2PYttcCEyyaEg1vjc g9Xril9ojJprs4a8dkdXW1NuBtvypbw5b1HbqdN/RM0y7mX/IGaJ2KgzfOxSK4c5q7laOkB PghSiz41lH6BCy+L2BxhmJhWfB9sV5RLBeGJ0fY0Jeqz02e41nE4S5PNHfJTnieMgNf+4DS AAJ+SKoegnPa9HnFhwSfw== X-UI-Out-Filterresults: notjunk:1;V01:K0:hwhlsoDxcUA=:mn6uhlyrX5ME0GfR4miEER gqlPGz8CNwi0BAkT7psvA4y3AatJ/RzOwFNwT6j253TPIqiTsAtq/yYK6MoBrrowuf6+najxJ oY1f3tQSnkmev34n/z0Apw9GfaG/NmbUEnXpB9zaEUvrqICplZ6aFpTuEr+n1vYKtH+yKkTdc dMTAcEECiaPvd5m575cvkHfj28m/pXuaOo8Kfyv8Rx3GzUS7I5DJcmIxkljbaL/6oCVlmL3sB 1OKsx8QEItmxfnFjFGZ+YqRCcklxBBJjqC5JafE8cUmguiwa9pAAWwLenwdUPAbH3/V2WLIVE 3O2PrJqiGENdjQ9BfFN2qEW7GMI8k1hDoDRmxyKuujGjPCWxxBQfvjdBAPf1JgWvcM8oXWx0O /Of8PbXzXgEsChN6jdXpsAPvZlXOxC/6J9mWz3/PUZNk9KaaSjBsSpzxCkO/uWgVLzPfEDnrv EBXDx6LZDSsOAT4JIFdY5Dq4Ui0LAORgZTc5Qd/Pck+WSIgotCgVY5B1sC3xZchVQareQpqS/ SrtZWp2awyIZW8OgqoC2bTTIiEFXZGFVPiXkc8s9E6PcbAEnCt0ETx2wjzxBkw2DnkE70hImc 00qDbwRfIfi0u5JeC35FlcxRgGIVxY3K/RQbPN0e1gOJtJvGV3tmK1pG6ukr+dWyhVoTmjkZi dY7Gs4UkxiEwGwJI7VDv97P5cRYvmfc718tUz+CHzoOjY14q3jdeGlZn4j+UtjHhoNlHtlTYf 91NvhOBBmEq1ShSm8kjaf8y1RGiiwzugVK1EjlG9tSa6OCY3RcZbQEJol6g= Archived-At: Subject: [OAUTH-WG] OAuth for IoT 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, 20 Oct 2015 15:31:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --caX3VhKOFrHgmxH0NeBdUhToDW5PmM35K Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI: For those who are not following the ACE working group here is a pointer to a document about the use of OAuth for IoT: https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00 This document builds the basis for incorporating more sophisticated functionality like UMA for IoT (which we submitted earlier this year). Ciao Hannes --caX3VhKOFrHgmxH0NeBdUhToDW5PmM35K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWJl1/AAoJEGhJURNOOiAtx2MH/ijevIy2xJ4r24OYkV2yxbzL BOQOBGlMdnaXvxtOdb2emdqHoc+m0Qhu5Ds/afgDx90SyuHguLLkJGJ0j0ytYQeq 6OcaKK3k+sxTYKC7FVt1FYV2OVxY1lMv8d1P9hlQdTbCs3ySYR6/lqlyrefUtiMf 7ZR0oV0C5Xww83UsVeQKmW52E5muttsJDHp9M6pPJfeOda5V9udkAZsSKGIv1xtL v3OMi5dZe6JwU6uQDrtTS2UAqj3o987mRIULpop10w6G4ASvf5dSvue93MxZyvZJ JeqF7PFdoigpzMWKtFQkkWxwZgsfH71J/FHZ9+nr6fB1laPdBoZPYdmwshWxf4E= =03bw -----END PGP SIGNATURE----- --caX3VhKOFrHgmxH0NeBdUhToDW5PmM35K-- From nobody Tue Oct 20 09:33:01 2015 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 600B51A8752 for ; Tue, 20 Oct 2015 09:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 UocRWP0cnulG for ; Tue, 20 Oct 2015 09:32:56 -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 A83691A87A4 for ; Tue, 20 Oct 2015 09:32:54 -0700 (PDT) X-AuditID: 12074424-f79106d000007367-82-56266cb47e0c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 56.E9.29543.4BC66265; Tue, 20 Oct 2015 12:32:52 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t9KGWq7M007434 for ; Tue, 20 Oct 2015 12:32:52 -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 t9KGWoK0023069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 20 Oct 2015 12:32:51 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <20151019225659.76476182534@rfc-editor.org> Date: Tue, 20 Oct 2015 12:32:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6B17AE6C-D494-46EE-9018-5C922EE370B6@mit.edu> References: <20151019225659.76476182534@rfc-editor.org> To: "" X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixG6norslRy3M4Pc1XYuTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr49KjuewFx0QqGq4+ZG5g7BfoYuTkkBAwkdh1rJcRwhaTuHBv PVsXIxeHkMBiJom1Py+wgiSEBI4xSmzsU4NIfGOSmH1hNjtIgllAXeLPvEvMIDavgJ7Eq1uX wRqEBRwlLnS9BpvKJqAqMX1NCxOIzSlgIfGmYzaYzQIU//B5EdQcbYllC18DzeEAmmMl8fQv H8Rec4ntzcdYQGwRoFVrzv9kgjhUVmL370dMExgFZiG5YhaSK2YhmbqAkXkVo2xKbpVubmJm TnFqsm5xcmJeXmqRrrlebmaJXmpK6SZGcEi6qOxgbD6kdIhRgINRiYdXI0Y1TIg1say4MvcQ oyQHk5Iob2G6WpgQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd42AaAcb0piZVVqUT5MSpqDRUmc d9MPvhAhgfTEktTs1NSC1CKYrAwHh5IEb102UKNgUWp6akVaZk4JQpqJgxNkOA/IcJAa3uKC xNzizHSI/ClGRSlx3hyQhABIIqM0D64XlDIS3h42fcUoDvSKMK84MIEI8QDTDVz3K6DBTECD Fz5SBRlckoiQkmpgzJCTOd2buDVBS2D2ufSJL8Szig54xOxZZsy/P6D6wN5M5vi/JVqXdXaf O2zF82q1+SPRO89PB0856sXToSiqYSPT/uDZ3rf9Cqdc9C8uKbF753In0UY1xDCzYHuA6If0 f+fMS7S7Xxo+eMow7ev2lfGbAr/JnnXPzVho3RF3cbNS78fWt5OnKbEUZyQaajEXFScCAO2z b4T0AgAA Archived-At: Subject: Re: [OAUTH-WG] RFC 7662 on OAuth 2.0 Token Introspection 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, 20 Oct 2015 16:32:59 -0000 Thank you to everyone who helped make token introspection into a real = standard! =E2=80=94 Justin > On Oct 19, 2015, at 6:56 PM, rfc-editor@rfc-editor.org wrote: >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7662 >=20 > Title: OAuth 2.0 Token Introspection=20 > Author: J. Richer, Ed. > Status: Standards Track > Stream: IETF > Date: October 2015 > Mailbox: ietf@justin.richer.org > Pages: 17 > Characters: 36591 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-oauth-introspection-11.txt >=20 > URL: https://www.rfc-editor.org/info/rfc7662 >=20 > DOI: http://dx.doi.org/10.17487/RFC7662 >=20 > This specification defines a method for a protected resource to query > an OAuth 2.0 authorization server to determine the active state of an > OAuth 2.0 token and to determine meta-information about this token. > OAuth 2.0 deployments can use this method to convey information about > the authorization context of the token from the authorization server > to the protected resource. >=20 > This document is a product of the Web Authorization Protocol Working = Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for = the=20 > standardization state and status of this protocol. Distribution of = this=20 > memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Oct 20 10:01:37 2015 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 B3CDA1A88B2 for ; Tue, 20 Oct 2015 10:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 eIznyPsMZSFy for ; Tue, 20 Oct 2015 10:01:31 -0700 (PDT) Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F241A92F5 for ; Tue, 20 Oct 2015 10:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1445360474; bh=hktuvKnJh48MOCPspGrqaAWaycxlfK4Gnt7J4ozqQfk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=LucQGm3PJQS89FLhCMPQbeVyyCqGBka94BsmAQY09bd3kFgF48gEcOBJz7yh0q1EJpU99q858OW30jFvTItEkg1gt6JVppU5/0VF1Hry/EoJTf3Y6hfpZZC7iBmc9zQChujYSxifZgjkelz+i/txuMdk/YlekFyLDWkvlYlAbHXYUPm0KiAoXhHQkfrlOl1OTihR0P2N2+8WJJhCYKTbh2eEWF43fxFeyjiNTiVUw8Viccmus/cIBsYyNQmO73tSSZ1tQqQ/sJw2FePprFJt4THBqPrk8kaRyOgLulFxuKK1HqT1fbxaBTez2yEHoaWosNrs0092JpjlLbIqmSE7Ww== Received: from [66.196.81.173] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 20 Oct 2015 17:01:14 -0000 Received: from [98.139.215.249] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 20 Oct 2015 17:01:14 -0000 Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 20 Oct 2015 17:01:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 571290.3220.bm@omp1062.mail.bf1.yahoo.com X-YMail-OSG: dKvetewVM1nlhYQTW6RpOdyTONzfM2lHckEhaIocHCOSl9GT7kTU9jYq6tI1bLl VMz9cWt2TNje.Iuvkn0QLxET6qd4cjPBk8GM54Ne_NP_VPPadlJI2O1Y1ejtnvFTPxXo.048HcGK S6BFNxlT7MOvwI9JtD8hUM_uF37Nizoo_3IG.KjyT1HAI7dJ_882GaxlK_4jGNBVvml_frRlV75L TTtmKHGdSfRKn9ceU0C_V8r_Yn7tEJwDTC.89TBtTLWV3ndj7oZSY1y4pdprr5J7H_ltbl7Tgkg1 qkTlQNQ5s1BeU9IRcpf2PRCoQVq9Y4zv5ILmwnAoLtTWrp6txuI6FPItUMUxlJtO3AUW3on8TUvn nXJ3.4HwG1bGm7ql7FiRXfZmhxAEQ4gAZA32qU9IBBAkuZcuw6n4jwBeuBlLaxrGkY2yWv5zB_Il egw7vtvhNPfnYl36Ytxv1Oil1.GnU1H80wz5EVTMVNUMnsfWANRtkDglUYWbjYndzwIQ9sDzH1Hx 7W4ZE0VuWm_cOLhSjknQQU9ivD9ZLtnRovJCzocaSEg0dudqTnP8- Received: by 66.196.81.116; Tue, 20 Oct 2015 17:01:14 +0000 Date: Tue, 20 Oct 2015 17:01:13 +0000 (UTC) From: Bill Mills To: Hannes Tschofenig Message-ID: <1347108524.394636.1445360473788.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <5625EEFD.1000109@gmx.net> References: <5625EEFD.1000109@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_394635_996499596.1445360473783" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] PoP Architecture - IPR Confirmation 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: Tue, 20 Oct 2015 17:01:35 -0000 ------=_Part_394635_996499596.1445360473783 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am still aware of no IPR related to=C2=A0https://www.ietf.org/id/draft-ie= tf-oauth-pop-architecture-02.txt=20 On Tuesday, October 20, 2015 12:37 AM, Hannes Tschofenig wrote: =20 Hi Bill, sorry to bother you again regarding this IPR issue but when I search through the OAuth mailing list archive then I cannot find a response from you to this mail from Kepeng: http://www.ietf.org/mail-archive/web/oauth/current/msg14980.html Ciao Hannes PS: I only see a single response from you on the list http://www.ietf.org/mail-archive/web/oauth/current/maillist.html, namely this email: http://www.ietf.org/mail-archive/web/oauth/current/msg15002.html Unfortunately, that mail was a call for IPR confirmation to the 'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' specificatio= n (draft-ietf-oauth-proof-of-possession-04) and not to the architecture draft. On 10/09/2015 02:55 AM, Bill Mills wrote: > I responded correctly Thursday. >=20 >=20 >=20 > On Thursday, October 8, 2015 5:48 PM, Hannes Tschofenig > wrote: >=20 >=20 > Hi Bill, >=20 > you have unfortunately responded to the wrong mail ;-) >=20 > Please respond to this one: > http://www.ietf.org/mail-archive/web/oauth/current/msg14980.html > (which is about the PoP architecture > ). >=20 > Sorry to bother you with these issues. >=20 > Ciao > Hannes >=20 > On 09/30/2015 04:10 PM, Bill Mills wrote: >> I am aware of no IPR issues for this document. >> >> Regards, >> >> -bill >> >> >> >> On Wednesday, September 30, 2015 3:53 AM, John Bradley >> > wrote: >> >> >> I confirm that I know of no IPR that reads on this specification. >> >> John Bradley=E2=80=99 >> >>> On Sep 30, 2015, at 7:03 AM, Kepeng Li >>> >> wrote: >>> >>> Hi Mike, John and Hannes, >>> I am working on the shepherd writeup for the PoP document: >>> http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04 >>> >>> One item in the template requires me to indicate whether each document >>> author has confirmed that any and all appropriate IPR disclosures >>> required for full conformance with the provisions of BCP 78 and BCP 79 >>> have already been filed. Could you please confirm? Kind Regards >>> Kepeng >>> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org > >=20 >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >=20 >=20 ------=_Part_394635_996499596.1445360473783 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tues= day, October 20, 2015 12:37 AM, Hannes Tschofenig <hannes.tschofenig@gmx= .net> wrote:


Hi Bill,

sorry to bother you again re= garding this IPR issue but when I search
through the OAut= h mailing list archive then I cannot find a response
from= you to this mail from Kepeng:
http://www.ietf.org/mail-archive/web/oauth/current/msg14980.html

Ciao
Hannes

PS: I only see a single response from you o= n the list
http://www= .ietf.org/mail-archive/web/oauth/current/maillist.html, namely
this email:
= http://www.ietf.org/mail-archive/web/oauth/current/msg15002.html

Unfortunately, that mail was a call for IPR = confirmation to the
'Proof-of-Possession Key Semantics fo= r JSON Web Tokens (JWTs)' specification
(draft-ietf-oauth= -proof-of-possession-04) and not to the architecture
draf= t.

On 10/09/2015 02:55 AM, Bill Mills = wrote:
> I responded correctly Thursday.
>
>
>
> On Thursday, October 8, 2015 5:48 PM, Hannes Tschofenig
> <hannes.tschofenig@gmx.net&= gt; wrote:
>
>
> Hi Bill,
>
> you have unf= ortunately responded to the wrong mail ;-)
>
> Please respond to this one:
> http://www.ietf.org/mail-archive/web/oauth/curre= nt/msg14980.html
> (which is about the PoP archite= cture
> <draft-ietf-oauth-pop-architecture-02.txt&g= t;).
>
> Sorry to bother you wit= h these issues.
>
> Ciao
> Hannes
>
> On 09= /30/2015 04:10 PM, Bill Mills wrote:
>> I am aware = of no IPR issues for this document.
>>
>> Regards,
>>
>&g= t; -bill
>>
>>
>>
>> On Wednesday, September 30, 2015 = 3:53 AM, John Bradley
>> <ve7jtb@v= e7jtb.com <mailto:ve7jtb@ve7jtb.com>> wrote:=
>>
>>
&g= t;> I confirm that I know of no IPR that reads on this specification.>>
>> John Bradley=E2=80=99>>
>>> On Sep 30, 2015, a= t 7:03 AM, Kepeng Li <kepeng.lkp@alibaba= -inc.com
> <mailto:kepeng.lkp@alibaba-inc.com>
>>> <m= ailto:kepeng.lkp@alibaba-inc.com
> <mailto:kepeng.lkp@ali= baba-inc.com>>> wrote:
>>>
>>> Hi Mike, John and Hannes,
>>= > I am working on the shepherd writeup for the PoP document:
>>> http://tools.ietf.= org/html/draft-ietf-oauth-proof-of-possession-04
>= >> <https://www.ietf.org/id/dra= ft-ietf-oauth-pop-architecture-02.txt>
>>>= ; One item in the template requires me to indicate whether each document>>> author has confirmed that any and all appropri= ate IPR disclosures
>>> required for full confor= mance with the provisions of BCP 78 and BCP 79
>>&g= t; have already been filed. Could you please confirm? Kind Regards
>>> Kepeng
>>>
>>
>>
>> ________= _______________________________________
>> OAuth ma= iling list
>> OAuth@ietf.org <mailto= :OAuth@ietf.org> <mailto:OAuth@ietf.org
> <mailto:OAuth@ietf.org>>
>
>> https://www.ietf.org/= mailman/listinfo/oauth
>>
>>
>= >
>>
>> ________________= _______________________________
>> OAuth mailing li= st
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://= www.ietf.org/mailman/listinfo/oauth
>>
>
>


------=_Part_394635_996499596.1445360473783-- From nobody Tue Oct 20 10:13:14 2015 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 38D681A8A16 for ; Tue, 20 Oct 2015 10:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.571 X-Spam-Level: X-Spam-Status: No, score=0.571 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, EMPTY_MESSAGE=2.32, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 OMc0nCShmThq for ; Tue, 20 Oct 2015 10:13:12 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F401A8A0B for ; Tue, 20 Oct 2015 10:13:00 -0700 (PDT) Received: by yknn9 with SMTP id n9so23325334ykn.0 for ; Tue, 20 Oct 2015 10:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=YPW1a+v38AKk4d2SZy6pOfqajoQPh/R8Lm1wKSl9edI=; b=Xy1uK+JATklE1TzMC5pHzLoBBtKnxbtacfhKN5ZhMNwQWfKYMiUXBUokPHhxZ79XLI WuZvLDCzrsqHHutQsqksYfuxJ1/ujmuHVE6Jg4D/3oWdveluQjfsqSo4PqCjXGECFk43 0Xegmx6DZZPItqi/wdoDz4LIas11frr1BNLDwGgGsA4QCRr7nhmWkHmdkEGI9oOz2vtC LvMd9OwgiXMg8rctF4KnYe8AgxPFguLqI+xi6txuGFJo9Zc3oMdDADKkvRh7b66Q/aQ+ hHx/PBJQwzC0SoOcH+gOpQwXSHk+CBp0iTpuveM/GLcE75pSWyl0+rrlaNUMAmVyRZYV 340A== X-Received: by 10.129.130.7 with SMTP id s7mr3106094ywf.29.1445361180095; Tue, 20 Oct 2015 10:13:00 -0700 (PDT) MIME-Version: 1.0 From: ronald comaling Date: Tue, 20 Oct 2015 17:12:50 +0000 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07c914b6398b05228c5f3c Archived-At: Subject: [OAUTH-WG] (no subject) 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, 20 Oct 2015 17:13:13 -0000 --94eb2c07c914b6398b05228c5f3c Content-Type: text/plain; charset=UTF-8 --94eb2c07c914b6398b05228c5f3c Content-Type: text/html; charset=UTF-8
--94eb2c07c914b6398b05228c5f3c-- From nobody Tue Oct 20 11:52:36 2015 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 A23951ACE1A for ; Tue, 20 Oct 2015 11:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ehVQ4wuTai-9 for ; Tue, 20 Oct 2015 11:52:32 -0700 (PDT) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B920E1ACE18 for ; Tue, 20 Oct 2015 11:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1445367096; bh=P3+iC1hHh5Lv3IuIsWwEJcRIh8i8xPFLnK0aorvWJdQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=gsyEObRWKcGxuFDuIoJPjMBox1Ovgn4LhSpOKH8ocRUg3GlJNYYxUJEXYjcF8ZaTUXYmtNyel3yEL2j8iFYP2YQCyxn1ZldmzCoDko1m69poXVK7zrSsYd971tULB5BtxLK9CoJvkMmxzojRcER++yJ+wtZznYUPAWuFpVDsEOwvEGLbb3TlVhXv5OIIp4HXRAdoCp7wHzNeG7xqpbNC7S8paf0ujIFHx3btbibgkjSDebKtwfrd/2hUsCjst+7lymEtTngeXG21tjm3L623KcqjsJeNnrzuSwoNKz4+Ig3UpQmgrKirO7/VauIEZdUxGQtuZ6IZgsQKauHyoiI1Fw== Received: from [66.196.81.173] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 20 Oct 2015 18:51:36 -0000 Received: from [98.139.212.234] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 20 Oct 2015 18:51:36 -0000 Received: from [127.0.0.1] by omp1043.mail.bf1.yahoo.com with NNFMP; 20 Oct 2015 18:51:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 768108.97349.bm@omp1043.mail.bf1.yahoo.com X-YMail-OSG: OuNr8SIVM1koUmDcuArM4i31tTO1Ss55ZWnpdEQ1EKbMZqsC6evGyLY.idcZ96N 47KaTMdByJCi1vFzUIQdDi1ew6VsBv3Ns.ySc7jLQDgBUgfxAFFWFjjQ9.6CubE1lM0CCIFviFY8 V6SqbqKaD2a8usC1OugmF_V_vfi1W_TKHFrXEvvF5r2Z9nvQCPURIk74v7uTj1.aRJFoRbRJqdxd nxjfxSaKMtQoZ430B7CNDlXT8kfaVrSL0sF.BtFPan.YKJGbe5a7sT65G2SjHG4SdkIQmawmsryw ezPjP5kfuL6m5.XAm8nQdcJWAHj3YHx01pSCfTq0gimiEuXUDf7FCyg3pZlwsaworhKokrqKffs9 V9SwVKMWOwT2wR5IBMZGdy4c.bkBv3s.pO6sXduvrahp8HcQCVWLpYv.B3RZG5f9r0EWvO.JdFqe DvXIdHWCbV1gISxKy6WZy0dciVRHsOCLbjTG4Eqb02K_uy.oyjxihaI.cu7ntNvue9zy1IzTyAHo GuFqFp9u6RPVrY22f Received: by 76.13.26.156; Tue, 20 Oct 2015 18:51:36 +0000 Date: Tue, 20 Oct 2015 18:51:35 +0000 (UTC) From: Bill Mills To: Hannes Tschofenig Message-ID: <2011847962.494723.1445367095787.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1347108524.394636.1445360473788.JavaMail.yahoo@mail.yahoo.com> References: <5625EEFD.1000109@gmx.net> <1347108524.394636.1445360473788.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_494721_610390556.1445367095763" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] PoP Architecture - IPR Confirmation 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: Tue, 20 Oct 2015 18:52:34 -0000 ------=_Part_494721_610390556.1445367095763 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Further, not version specific. =C2=A0I am aware of now IPR related to this = document in any version.=20 On Tuesday, October 20, 2015 10:01 AM, Bill Mills wrote: =20 I am still aware of no IPR related to=C2=A0https://www.ietf.org/id/draft-i= etf-oauth-pop-architecture-02.txt=20 On Tuesday, October 20, 2015 12:37 AM, Hannes Tschofenig wrote: =20 Hi Bill, sorry to bother you again regarding this IPR issue but when I search through the OAuth mailing list archive then I cannot find a response from you to this mail from Kepeng: http://www.ietf.org/mail-archive/web/oauth/current/msg14980.html Ciao Hannes PS: I only see a single response from you on the list http://www.ietf.org/mail-archive/web/oauth/current/maillist.html, namely this email: http://www.ietf.org/mail-archive/web/oauth/current/msg15002.html Unfortunately, that mail was a call for IPR confirmation to the 'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' specificatio= n (draft-ietf-oauth-proof-of-possession-04) and not to the architecture draft. On 10/09/2015 02:55 AM, Bill Mills wrote: > I responded correctly Thursday. >=20 >=20 >=20 > On Thursday, October 8, 2015 5:48 PM, Hannes Tschofenig > wrote: >=20 >=20 > Hi Bill, >=20 > you have unfortunately responded to the wrong mail ;-) >=20 > Please respond to this one: > http://www.ietf.org/mail-archive/web/oauth/current/msg14980.html > (which is about the PoP architecture > ). >=20 > Sorry to bother you with these issues. >=20 > Ciao > Hannes >=20 > On 09/30/2015 04:10 PM, Bill Mills wrote: >> I am aware of no IPR issues for this document. >> >> Regards, >> >> -bill >> >> >> >> On Wednesday, September 30, 2015 3:53 AM, John Bradley >> > wrote: >> >> >> I confirm that I know of no IPR that reads on this specification. >> >> John Bradley=E2=80=99 >> >>> On Sep 30, 2015, at 7:03 AM, Kepeng Li >>> >> wrote: >>> >>> Hi Mike, John and Hannes, >>> I am working on the shepherd writeup for the PoP document: >>> http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04 >>> >>> One item in the template requires me to indicate whether each document >>> author has confirmed that any and all appropriate IPR disclosures >>> required for full conformance with the provisions of BCP 78 and BCP 79 >>> have already been filed. Could you please confirm? Kind Regards >>> Kepeng >>> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org > >=20 >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >=20 >=20 =20 ------=_Part_494721_610390556.1445367095763 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Further, not version specific.  I am aware of now IPR related to t= his document in any version.



On Tuesday= , October 20, 2015 10:01 AM, Bill Mills <wmills_92105@yahoo.com> wrot= e:





On Tuesday, October 20, 2015 12:37 AM, Hannes Tsch= ofenig <hannes.tschofenig@gmx.net> wrote:
 =


Hi Bill,

sorry to both= er you again regarding this IPR issue but when I search
t= hrough the OAuth mailing list archive then I cannot find a response
from you to this mail from Kepeng:
http://www.ietf.org/mail-archive/w= eb/oauth/current/msg14980.html

Cia= o
Hannes

PS: I only = see a single response from you on the list
http://www.ietf.org/mail-archive/web= /oauth/current/maillist.html, namely
this email:
http://ww= w.ietf.org/mail-archive/web/oauth/current/msg15002.html

Unfortunately, that mail was a call for IPR confirmat= ion to the
'Proof-of-Possession Key Semantics for JSON We= b Tokens (JWTs)' specification
(draft-ietf-oauth-proof-of= -possession-04) and not to the architecture
draft.

On 10/09/2015 02:55 AM, Bill Mills wrote:> I responded correctly Thursday.
>=
>
>
> On= Thursday, October 8, 2015 5:48 PM, Hannes Tschofenig
>= ; <hann= es.tschofenig@gmx.net> wrote:
>
>
> Hi Bill,
>
> you have unfortunately responded to the wrong mail ;-)
>
> Please respond to this one:
> http:= //www.ietf.org/mail-archive/web/oauth/current/msg14980.html
> (which is about the PoP architecture
> <= ;draft-ietf-oauth-pop-architecture-02.txt>).
>
> Sorry to bother you with these issues.
>
> Ciao
> Hannes
>
> On 09/30/2015 04:10 PM, Bill Mills w= rote:
>> I am aware of no IPR issues for this docum= ent.
>>
>> Regards,
>>
>> -bill
>= >
>>
>>
>> On Wednesday, September 30, 2015 3:53 AM, John Bradley
>> <ve7= jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>> wrote:
>>
>>
>> I confirm that I know of no = IPR that reads on this specification.
>>
>> John Bradley=E2=80=99
>>
>>> On Sep 30, 2015, at 7:03 AM, Kepeng Li <kepeng.lkp@ali= baba-inc.com
> <mailto:kepeng.lkp@alibaba-inc.com&g= t;
>>> <mailto:kepeng.lkp@alibaba-inc.com
> <mailto:kepeng.lkp@alibaba-inc.com>>> wrote:
>>>
>>> Hi Mike, John and= Hannes,
>>> I am working on the shepherd writeu= p for the PoP document:
>>> http://tools.ietf.org/html/draft-ietf-oau= th-proof-of-possession-04
>>> <https://www.ietf.org/id/draft-iet= f-oauth-pop-architecture-02.txt>
>>> One = item in the template requires me to indicate whether each document
>>> author has confirmed that any and all appropriate IP= R disclosures
>>> required for full conformance = with the provisions of BCP 78 and BCP 79
>>> hav= e already been filed. Could you please confirm? Kind Regards
>>> Kepeng
>>>
&g= t;>
>>
>> ______________= _________________________________
>> OAuth mailing = list
>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
> <mailto:OAuth@ietf.org>>
> <= br clear=3D"none">>> https://www.ietf.= org/mailman/listinfo/oauth

>>
= >>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>= ; https://www.ietf.org/mailman/listinfo/oaut= h
>>
>
= >


=


=
------=_Part_494721_610390556.1445367095763-- From nobody Tue Oct 20 20:53:17 2015 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 9B0461B2E18 for ; Tue, 20 Oct 2015 20:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 5yTC7Afa2M1A for ; Tue, 20 Oct 2015 20:53:09 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id F329F1B2E14 for ; Tue, 20 Oct 2015 20:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1445399587; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=wse2Q0nH6V/GfiywVVwo54+QBXevmsIaxM9w+iZxmjY=; b=SgnkV5IKOmup/U0DzlVQ97PC6wHJA4dspaIyZh9wwvXam2HdZGytoJ/uozmq1ZfblPmtJDveIdOETi5RUghjQWWWD/Lh1zObAGmrec+nLSORP8TllWwBqPckGivpGdpP0CqKC4T5v3tTDr2ERibU/G2Izr5vjt11FmVZJZhB6k8= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03299; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=3; SR=0; Received: from 10.1.152.166(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.185) by smtp.aliyun-inc.com(127.0.0.1); Wed, 21 Oct 2015 11:52:59 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 21 Oct 2015 11:52:54 +0800 From: "Kepeng Li" To: Mike Jones Message-ID: Thread-Topic: New Version Notification for draft-sakimura-oauth-rjwtprof-06.txt References: <20151019150331.1746.43411.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3528273179_5529654" Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] FW: New Version Notification for draft-sakimura-oauth-rjwtprof-06.txt 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, 21 Oct 2015 03:53:15 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3528273179_5529654 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Mike, Thanks for your review. It is very helpful, and I also forward it to the whole list. We will make a update when the submission window opens. Kind Regards Kepeng =E5=8F=91=E4=BB=B6=E4=BA=BA: Mike Jones =E6=97=A5=E6=9C=9F: Wednesday, 21 October, 2015 1:07 am =E8=87=B3: Li Kepeng =E6=8A=84=E9=80=81: Nat Sakimura =E4=B8=BB=E9=A2=98: RE: New Version Notification for draft-sakimura-oauth-rjwtprof-06.= txt Hi Kepeng, =20 Thanks for the pointer to the current version of the document. Review comments follow=E2=80=A6 =20 Abstract =E2=80=93 Remove the reference, since they aren=E2=80=99t allowed in IETF abstracts. =20 Introduction. I would replace this text: While Proof-Of-Possession Semantics for JSON Web Tokens (JWTs) [POPS=20 ] touches briefly on the Sender Constraint, it is only one paragraph within a introductory text and does not discuss it in detail. Instead, it devotes much of the discussion to the Key Confirmation method. It also is making the usage of such token against the resource server out of scope. with something closer to this: While Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) [POPS] specifies how to use key confirmation with JWTs, it does not specify how to use a sender constraint. And then maybe merge this paragraph with the following one, which starts =E2=80=9CThis discussion draft=E2=80=9D=E2=80=A6 =20 I have no idea what the last sentence above was referring to. I=E2=80=99d just delete it. =20 Everyplace you say =E2=80=9CProof-Of-Possession Semantics for JSON Web Tokens (JWTs)=E2=80=9D you should change this to the current title =E2=80=9CProof-of-Possessio= n Key Semantics for JSON Web Tokens (JWTs)=E2=80=9D. =20 I would delete the term =E2=80=9CAuthorized Presenter=E2=80=9D and instead refer to the =E2=80=9CPresenter=E2=80=9D term in [POPS] by reference. The term =E2=80=9CAuthorized Presen= ter=E2=80=9D has a bad history and tends to cause more confusion than clarity when it appears. When you want to talk about the legitimate presenter, I would jus= t use a phrase such as =E2=80=9Cintended presenter=E2=80=9D or =E2=80=9Clegitimate presenter=E2=80=9D= . (I would refer to an unauthorized presenter in your discussion as =E2=80=9Cthe attacker=E2=80=9D.) =20 s/use-case/use case/ =20 Delete this sentence, since Sender Constraint isn=E2=80=99t in scope for POPS, an= d the sentence makes it sound like it is: Key Confirmation mechanism is described in OAuth 2.0 Proof-Of-Possession Semantics for JSON Web Tokens (JWTs) [POPS ] specification in detail, but Sender Constraint mechanism is not explained in detail. =20 Justification =E2=80=93 Some places in the draft you talk about =E2=80=9C.well-known/jw= ks=E2=80=9D (plural) and other places you talk about =E2=80=9C.well-known/jwk=E2=80=9D (singular). = I suspect that multiple keys have to be published in the general case in orde= r to enable key rotation, with the right key selected by the =E2=80=9Ckid=E2=80=9D. See http://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys for a description of how keys are rotated in OpenID Connect. This spec should do the same or something similar. =20 Sender Constraint Representation =E2=80=93 I would not overload the =E2=80=9Cazp=E2=80=9D cla= im specified in http://openid.net/specs/openid-connect-core-1_0.html#IDToken with a different meaning. There=E2=80=99s a widespread agreement in the OpenID Connect working group that =E2=80=9Cazp=E2=80=9D is confusing =E2=80=93 see https://bitbucket.org/openid/connect/issues/973/core-2-3137-azp-claim-under= s pecified-and. John Bradley has also stated that the use you=E2=80=99re making of= it is different than Google=E2=80=99s usage (which is the only party using =E2=80=9Cazp=E2=80=9D= that I=E2=80=99m aware of), and should use a different claim name. Rather, I=E2=80=99d sugg= est adding a new parameter name under the =E2=80=9Ccnf=E2=80=9D claim defined by POPS to ex= press the presenter =E2=80=93 possible =E2=80=9Cprsnt=E2=80=9D. So the syntax would be: =20 =E2=80=9Ccnf=E2=80=9D: {=E2=80=9Cprsnt=E2=80=9D: =E2=80=9Cpresenter identifier=E2=80=9D} =20 and when a Key ID is needed to select from among multiple keys, the syntax would be: =20 =E2=80=9Ccnf=E2=80=9D: {=E2=80=9Cprsnt=E2=80=9D: =E2=80=9Cpresenter identifier=E2=80=9D, =E2=80=9Ckid=E2=80=9D: =E2=80=9Ckey = identifier=E2=80=9D} =20 This syntax would be more harmonized with POPS, and is the kind of extensio= n to =E2=80=9Ccnf=E2=80=9D that were anticipated and enabled by the JWT Confirmation Meth= ods Registry in Section 6.2 of POPS. =20 Client Authentication =E2=80=93 In (1), why is a =E2=80=9CHEAD=E2=80=9D request listed as a possibility? Why not just =E2=80=9CGET=E2=80=9D? =20 In (2), where is the =E2=80=9Cnamed=E2=80=9D Authorization header value defined? Pleas= e provide a reference where you first use it. (Oh =E2=80=93 I just realized when I got to 7.1 that you are defining the scheme in this specification. I couldn=E2=80=99t tell for sure until then. I would have a separate section that=E2= =80=99s just about defining =E2=80=9Cnamed=E2=80=9D and how it works before you use it.) =20 In (3), do you mean that the nonce is signed using the JWS Compact Serialization, with the nonce being the JWS Payload value? What key is use= d for signing? =20 In (4), I=E2=80=99d rename =E2=80=9Cat=E2=80=9D to =E2=80=9Caccess_token=E2=80=9D for consistency with ot= her specs and rename =E2=80=9Cs=E2=80=9D to =E2=80=9Csignature=E2=80=9D. =20 In (5), I=E2=80=99d cite RFC 7591 when you refer to Dynamic Client Registration. Also, people won=E2=80=99t like the =E2=80=9Cmay have been=E2=80=9D. You should probably def= ine one or a few preferred ways of doing this. =20 In (7), you need to say how the resource server verifies the access token. What steps does it take to do this, for instance? =20 6.1 URI Client ID =E2=80=93 As I wrote earlier, this has to be a JWK Set, with th= e key being selected by =E2=80=9Ckid=E2=80=9D, to enable key rotation. =20 6.3 Metadata about the authorization server is its discovery information. For instance, OpenID Connect publishes this information as described at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata and the following sections. I would describe this as =E2=80=9Cauthorization serv= er discovery information=E2=80=9D and probably add an informative reference to OpenI= D Connect Discovery. =20 10.2 Informative References =E2=80=93 PKCE and Introspection is now both RFCs. Please add URLs to all of the references like those in the Normative References. If you use references like these, you get them automatically: Or you can include an explicit target=3D value in the element, such as in this reference: JSON Web Token Claims IANA =20 I hope you find these review comments to be useful. =20 Best wishes= , -- Mike =20 =20 --B_3528273179_5529654 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hi Mike,

<= div>Thanks for your review. It is very helpful, and I also forward it to the= whole list.

We will make a update when the submiss= ion window opens.

Kind Regards
Kepeng

=E5=8F=91=E4=BB=B6=E4=BA=BA: Mike Jones &= lt;Michael.Jones@microsoft.com<= /a>>
=E6=97=A5=E6=9C=9F: Wednesday, 21 Octo= ber, 2015 1:07 am
=E8=87=B3: Li Kepeng &= lt;kepeng.lkp@alibaba-inc.com>
=E6=8A=84=E9=80=81: Nat Sakimura <sakimura@gmail.com>
=E4=B8=BB=E9=A2=98: RE: New Version Notification for draft-sak= imura-oauth-rjwtprof-06.txt

Hi Kepeng,

 

= Thanks for the pointer to the current version of the document.  Review = comments follow…

 

Abstract – Remove the reference, since t= hey aren’t allowed in IETF abstracts.

 

Introduction.  I wou= ld replace this text:

   While Proof-Of-Possession Semantics for JSON Web =
Tokens
   (JWTs) [POPS] touches briefly on the Sende=
r Constraint, it is only
   one paragraph within a introductory t=
ext and does not discuss it in
   detail.  Instead, it devot=
es much of the discussion to the Key
   Confirmation method. =
; It also is making the usage of such token
   against the resour=
ce server out of scope.

with something closer to this:

While Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) [POPS] specif= ies how to use key confirmation with JWTs, it does not specify how to use a = sender constraint.

And then maybe merge this paragraph with the following one, which starts= “This discussion draft”…

 

I have no idea what the last sentence above was referri= ng to.  I’d just delete it.

 

= Everyplace you say “Proof-Of-Possession Semantics for = JSON Web Tokens (JWTs)” you should change this to the current title &#= 8220;Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)”.

 =

I would delete the term &= #8220;Authorized Presenter” and instead refer to the “Presenter&= #8221; term in [POPS] by reference.  The term “Authorized Present= er” has a bad history and tends to cause more confusion than clarity w= hen it appears.  When you want to talk about the legitimate presenter, I wou= ld just use a phrase such as “intended presenter” or “legi= timate presenter”.  (I would refer to an unauthorized presenter i= n your discussion as “the attacker”.)

 

s/use-case/use case/

 

Delete this sentence, since Sender Constraint isn&#= 8217;t in scope for POPS, and the sentence makes it sound like it is:

 &=
nbsp; Key Confirmation mechanism is
   described in OAuth 2.0 Pro=
of-Of-Possession Semantics for JSON Web
   Tokens (JWTs) [   mec=
hanism is not explained in detail.

 

Justification – Some places in the draft you talk about = “.well-known/jwks” (plural) and other places you talk about R= 20;.well-known/jwk” (singular).  I suspect that multiple keys hav= e to be published in the general case in order to enable key rotation, with the right key selected by the “= ;kid”.  See http://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys for = a description of how keys are rotated in OpenID Connect.  This spec sho= uld do the same or something similar.

 

<= span lang=3D"EN">Sender Constraint Representation – I would not overload= the “azp” claim specified in http= ://openid.net/specs/openid-connect-core-1_0.html#IDToken with a differen= t meaning.  There’s a widespread agreement in the OpenID Connect = working group that “azp” is confusing – see https://bitbucket.org/openid/connect/issues/973/core-2-3137-azp-claim-under= specified-and.  John Bradley has also stated that the use you’= ;re making of it is different than Google’s usage (which is the only p= arty using “azp” that I’m aware of), and should use a different claim name.  Rather, I’d suggest adding a new p= arameter name under the “cnf” claim defined by POPS to express t= he presenter – possible “prsnt”.  So the syntax would= be:

 = ;

   = “cnf”: {“prsnt”: “presenter identifier”= }

 

and when a Key ID is = needed to select from among multiple keys, the syntax would be:

 

    “cnf”= ;: {“prsnt”: “presenter identifier”, “kid̶= 1;: “key identifier”}

 

This syntax would be more harmonized with POPS, and is the kind of e= xtension to “cnf” that were anticipated and enabled by the JWT Confirmation Methods Registry in Section 6.2 of = POPS.

&nbs= p;

Client Authentica= tion – In (1), why is a “HEAD” request listed as a possibi= lity?  Why not just “GET”?

 

In (2), where is the “named” Authorization = header value defined?  Please provide a reference where you first use i= t.  (Oh – I just realized when I got to 7.1 that you are defining= the scheme in this specification.  I couldn’t tell for sure until then.  I would have a separate sec= tion that’s just about defining “named” and how it works b= efore you use it.)

 

In (= 3), do you mean that the nonce is signed using the JWS Compact Serialization= , with the nonce being the JWS Payload value?  What key is used for sig= ning?

&nbs= p;

In (4), I’d= rename “at” to “access_token” for consistency with = other specs and rename “s” to “signature”.

 =

In (5), I’d cite RFC 7591 = when you refer to Dynamic Client Registration.  Also, people won’= t like the “may have been”.  You should probably define one= or a few preferred ways of doing this.

 

In (7), you need to say how the resource server verifies th= e access token.  What steps does it take to do this, for instance?=

 

6.1 URI Client ID – A= s I wrote earlier, this has to be a JWK Set, with the key being selected by = “kid”, to enable key rotation.

 

6.3 Metadata about the authorization server is its disco= very information.  For instance, OpenID Connect publishes this informat= ion as described at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata<= /a> and the following sections.  I would describe this as “author= ization server discovery information” and probably add an informative = reference to OpenID Connect Discovery.

 

= 10.2 Informative References – PKCE and Introspection i= s now both RFCs.  Please add URLs to all of the references like those i= n the Normative References.  If you use references like these, you get = them automatically:

      <?rfc include=3D"http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I= -D.draft-ietf-oauth-pop-architecture-03.xml" ?>

=

Or you can include an explicit targe= t=3D value in the <reference> element, such as in this reference:

   &nb= sp;  <reference anchor=3D"IANA.JWT.Claims" target=3D"http://www.iana.org/assignments/jwt">= ;

  &= nbsp;     <front>

        = ;  <title>JSON Web Token Claims</title>

     &nbs= p;    <author>

         &= nbsp;  <organization>IANA</organization><= /p>

     &nb= sp;    </author>

         = ; <date/>

        </front>=

      &= lt;/reference>

 

I hop= e you find these review comments to be useful.

 

        &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;    Best wishes,

         &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;    -- Mike

 


 

 --B_3528273179_5529654-- From nobody Wed Oct 21 01:21:00 2015 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 403F81B36D9 for ; Wed, 21 Oct 2015 01:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 h8kcMX6r4ABf for ; Wed, 21 Oct 2015 01:20:57 -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 225531B36D7 for ; Wed, 21 Oct 2015 01:20:57 -0700 (PDT) Received: from [192.168.131.140] ([80.92.122.73]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M8mCe-1Zh97x21gC-00CDPf; Wed, 21 Oct 2015 10:20:53 +0200 To: Justin Richer , "" References: <20151019225659.76476182534@rfc-editor.org> <6B17AE6C-D494-46EE-9018-5C922EE370B6@mit.edu> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56274ACB.1040800@gmx.net> Date: Wed, 21 Oct 2015 10:20:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <6B17AE6C-D494-46EE-9018-5C922EE370B6@mit.edu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="deFJPMWJ4Ck7aomHq769eGeBaEJujXE8b" X-Provags-ID: V03:K0:y0uUH9hnVyXwoObyx25KmBa3CaMyn2kmyTeAbAHGj818mvbk9qv sVLddBTa7XPxxD7jnEkkRbahFnGXz6bd5BT+Pnq9tUjmT9pFMoAuxdxD+RhExgZeQQYrZDG x2C9GMdHoaxrbhkYTK22u0GFrbVks2NYKgS3NewdLfES9DMzQiuI6C9nyxi4HOaLKS8R5Ih nrtxYILX5QdFt5UNu4nQQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:MJD1Z5HzNUE=:+bqBrN1k6sqOetw4siexZ3 D6KdzbApDg6I6i7M+dHRX492pvizWmniyMyXO8ZTdYfgAtUaq+ktQj6BTndmOB42AVbhswfjy 1+wV4Fj9GET8u24LChFq937lYRzC8uWcUCq63uEikonDJ57L97xIz7Uak37LKtbadEeD1HvLp Li5V/y0jU5G47ai4UufeAXJjnDRXc50Lbbuaacxuk19D/QOk0x2YDIodN9Qr1OuUjscFbNhkM ry9ybwGsigAgJhbtodYENDUwKMjoXHJA8WxlP6T+WnRUQruOP9n+Vzi0l1Q3m3VysLdgbXJ4Y eAc64e2rakpIQmPtR/pkTVtNEkxWWr3rPMFbIyiFLbI4YJry+WV6OQxqVlblrKXfabjQE8b3f gsvCerS/fLCm+fNdayTfgwZbFHrOp32SpsIL9uPjM3MFq0ohpyUGQOiVtIVV4E54hCAKi1VZK 4djVQQif5GCzUMm1WvQr0Zph9khV7r36TdRbe43DeuM0axK2+ZGpea687CNcePI6GLZJ7ouyU 9iJwzV2wdzjJ/YYFxoG+21oH/QrR6KvYqRphr9DOcYoIslQdJf2fbLNKdXoT2x45K2zCBodo9 PQc+JTyE7sdzVhqAU6T88bcJ1u0WXk4OucvrIoj8h0dOMX329HfgsBiY7f1CZlk724RWncecX PKjJ17Z8LhRCVkxZKyxQ5+d3Ow/fKsJK2QCPO/9YEWY87/ZJnMmFVyaqgL+XXcXwrw4ynurfP lJMbttJfjoemL4aVi7tgioC5ekvl8yTLP2p5O7SS+WgvaNBVAD59j9pdJ8o= Archived-At: Subject: Re: [OAUTH-WG] RFC 7662 on OAuth 2.0 Token Introspection 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, 21 Oct 2015 08:20:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --deFJPMWJ4Ck7aomHq769eGeBaEJujXE8b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you Justin for the hard work! On 10/20/2015 06:32 PM, Justin Richer wrote: > Thank you to everyone who helped make token introspection into a real s= tandard! >=20 > =E2=80=94 Justin >=20 >> On Oct 19, 2015, at 6:56 PM, rfc-editor@rfc-editor.org wrote: >> >> A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 7662 >> >> Title: OAuth 2.0 Token Introspection=20 >> Author: J. Richer, Ed. >> Status: Standards Track >> Stream: IETF >> Date: October 2015 >> Mailbox: ietf@justin.richer.org >> Pages: 17 >> Characters: 36591 >> Updates/Obsoletes/SeeAlso: None >> >> I-D Tag: draft-ietf-oauth-introspection-11.txt >> >> URL: https://www.rfc-editor.org/info/rfc7662 >> >> DOI: http://dx.doi.org/10.17487/RFC7662 >> >> This specification defines a method for a protected resource to query >> an OAuth 2.0 authorization server to determine the active state of an >> OAuth 2.0 token and to determine meta-information about this token. >> OAuth 2.0 deployments can use this method to convey information about >> the authorization context of the token from the authorization server >> to the protected resource. >> >> This document is a product of the Web Authorization Protocol Working G= roup of the IETF. >> >> This is now a Proposed Standard. >> >> STANDARDS TRACK: This document specifies an Internet Standards Track >> protocol for the Internet community, and requests discussion and sugge= stions >> for improvements. Please refer to the current edition of the Official= >> Internet Protocol Standards (https://www.rfc-editor.org/standards) for= the=20 >> standardization state and status of this protocol. Distribution of th= is=20 >> memo is unlimited. >> >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> https://www.ietf.org/mailman/listinfo/ietf-announce >> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >> >> For searching the RFC series, see https://www.rfc-editor.org/search >> For downloading RFCs, see https://www.rfc-editor.org/rfc.html >> >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to rfc-editor@rfc-editor.org. Unles= s >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >> >> >> The RFC Editor Team >> Association Management Solutions, LLC >> >> >> _______________________________________________ >> 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 --deFJPMWJ4Ck7aomHq769eGeBaEJujXE8b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWJ0rLAAoJEGhJURNOOiAtFcQH/iOM7HSKBoPSp8OZ0t8ns5FR 6TC32Hgsf4j5Hc4Ky9fxiMOfdF7cB0KSt3Q8w2g31iUf6360ZtHlII06hNdmLDP2 8DDEMpMOLapbmWAvBBETwMfqeplgI4oRlHeBdg91FUc7rybQ7kO+k1ag/iKRljff 8hv68YJ7SKyHDM8VlMKiIFgZWnxk+AlqxebYFzv6FVkzy1SgBrFYpsvfIv7hRC7Q qshQLnsKDMRVuPs0DwxXhsBbzL/zDYV485QhQhmwfz207k4yFxJJgP+ON9a1M19h tn1gMiZKUqr5UJoD/KKa9JIV0pzu9b8IZawAo+wAGUC18YZXfl3daXAjmwR2x20= =0RYY -----END PGP SIGNATURE----- --deFJPMWJ4Ck7aomHq769eGeBaEJujXE8b-- From nobody Wed Oct 21 04:47:26 2015 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 91E3B1A9117 for ; Wed, 21 Oct 2015 04:47:24 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 loXgf2OvbxOE for ; Wed, 21 Oct 2015 04:47:23 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E551A8924 for ; Wed, 21 Oct 2015 04:47:22 -0700 (PDT) Received: by qkfm62 with SMTP id m62so29881401qkf.1 for ; Wed, 21 Oct 2015 04:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T3nz1OXigJt48DMRCMm3EaXGH7WVfIJTNJPMkmfCfk4=; b=Q0lLSD2eLMhiV+boa2ksrUDnCOSC6wAw4peiFrBoxRpzf3btRCVHUTxtsj/EL7MbGK GkbLOIFYQ236Jg1BdS+iU/zb0bRnEq3QM/n7GuH7OmZhizUNqJAQBnG3HGsEgspoN1Cb WrhU3fQAudsA7dF4js+Kf8gGx+D1MayLmYgJsC7U+CCtpW6kTGHKBWfyT+Qq5e7vAiIh H3/BC6tSA69GOqUJhz4Vy8aKSUPNcfLaV0VsHWBym3lynMhRDUKz22b/zG+pjFdppSce 9NbXjlLOdZfdl6o6bxBTaDXVQUl+l45GsTBGDolwrko1bGvJk25zzVSe9oYbc2deHaWu bG9w== X-Received: by 10.140.100.240 with SMTP id s103mr10003980qge.25.1445428042003; Wed, 21 Oct 2015 04:47:22 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id 52sm3104872qgz.17.2015.10.21.04.47.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Oct 2015 04:47:20 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <56274ACB.1040800@gmx.net> Date: Wed, 21 Oct 2015 07:47:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151019225659.76476182534@rfc-editor.org> <6B17AE6C-D494-46EE-9018-5C922EE370B6@mit.edu> <56274ACB.1040800@gmx.net> To: Hannes Tschofenig Archived-At: Cc: "" Subject: Re: [OAUTH-WG] RFC 7662 on OAuth 2.0 Token Introspection 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, 21 Oct 2015 11:47:24 -0000 Yes, nice job! Sent from my iPhone > On Oct 21, 2015, at 4:20 AM, Hannes Tschofenig = wrote: >=20 > Thank you Justin for the hard work! >=20 >> On 10/20/2015 06:32 PM, Justin Richer wrote: >> Thank you to everyone who helped make token introspection into a real sta= ndard! >>=20 >> =E2=80=94 Justin >>=20 >>> On Oct 19, 2015, at 6:56 PM, rfc-editor@rfc-editor.org wrote: >>>=20 >>> A new Request for Comments is now available in online RFC libraries. >>>=20 >>>=20 >>> RFC 7662 >>>=20 >>> Title: OAuth 2.0 Token Introspection=20 >>> Author: J. Richer, Ed. >>> Status: Standards Track >>> Stream: IETF >>> Date: October 2015 >>> Mailbox: ietf@justin.richer.org >>> Pages: 17 >>> Characters: 36591 >>> Updates/Obsoletes/SeeAlso: None >>>=20 >>> I-D Tag: draft-ietf-oauth-introspection-11.txt >>>=20 >>> URL: https://www.rfc-editor.org/info/rfc7662 >>>=20 >>> DOI: http://dx.doi.org/10.17487/RFC7662 >>>=20 >>> This specification defines a method for a protected resource to query >>> an OAuth 2.0 authorization server to determine the active state of an >>> OAuth 2.0 token and to determine meta-information about this token. >>> OAuth 2.0 deployments can use this method to convey information about >>> the authorization context of the token from the authorization server >>> to the protected resource. >>>=20 >>> This document is a product of the Web Authorization Protocol Working Gro= up of the IETF. >>>=20 >>> This is now a Proposed Standard. >>>=20 >>> STANDARDS TRACK: This document specifies an Internet Standards Track >>> protocol for the Internet community, and requests discussion and suggest= ions >>> for improvements. Please refer to the current edition of the Official >>> Internet Protocol Standards (https://www.rfc-editor.org/standards) for t= he=20 >>> standardization state and status of this protocol. Distribution of this= =20 >>> memo is unlimited. >>>=20 >>> This announcement is sent to the IETF-Announce and rfc-dist lists. >>> To subscribe or unsubscribe, see >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >>>=20 >>> For searching the RFC series, see https://www.rfc-editor.org/search >>> For downloading RFCs, see https://www.rfc-editor.org/rfc.html >>>=20 >>> Requests for special distribution should be addressed to either the >>> author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >>> specifically noted otherwise on the RFC itself, all RFCs are for >>> unlimited distribution. >>>=20 >>>=20 >>> The RFC Editor Team >>> Association Management Solutions, LLC >>>=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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Oct 21 06:06:19 2015 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 5E9771A6FCD for ; Wed, 21 Oct 2015 06:06:18 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 oZI3BEPMwJyr for ; Wed, 21 Oct 2015 06:06:16 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5681A6FCF for ; Wed, 21 Oct 2015 06:06:15 -0700 (PDT) Received: by wijp11 with SMTP id p11so94098308wij.0 for ; Wed, 21 Oct 2015 06:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=8voMXGJXrmvuZl7O4BT8Wqn0P34dfwJimbUav3MDhQQ=; b=ViDgdFcvr2ZtFvArqOVuvyTWl82gWhbeohqHkVNv31Rhm4wYyEPhhHHJuxY2aBzwgX sOS3ynBp/Td+Zfl+2V7q/0yMCiji4mZkVop4UbdwkfGWgDWH0kkSmpvD9ZiPtoqHy0Tx Kqh82yDfFfGlVDP5wSmh7J6ctNbYIdckTe67xr6NroNKhCNQJfKKSOMdPNUcZ6/PMRf1 Raw98PtZSTeir34LssSTSgEfMeCCW9eutCLD1gsIECw8QHOPqg2dBd+4bW354dcXVJ8J sBthI12aDGcmCmYxkpIJW2Ur+YMANZHmjTEg1sCL/EZjGzRgQAS3z+fe6XSKDSzALwTB CRxA== X-Received: by 10.194.118.234 with SMTP id kp10mr10893076wjb.59.1445432773985; Wed, 21 Oct 2015 06:06:13 -0700 (PDT) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id jh4sm5866620wjb.33.2015.10.21.06.06.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2015 06:06:13 -0700 (PDT) To: oauth@ietf.org References: <41395617-E5A9-4294-9F8B-DFE9E27F74F8@xmlgrrl.com> From: Sergey Beryozkin Message-ID: <56278DC4.3060600@gmail.com> Date: Wed, 21 Oct 2015 14:06:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <41395617-E5A9-4294-9F8B-DFE9E27F74F8@xmlgrrl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] Is authorization challenge always needed in OIDC OAuth2 servers ? 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, 21 Oct 2015 13:06:18 -0000 Hi I can not subscribe to an OIDC spec list, had some earlier questions not flowing to the list and given I'm not sure this question is irrelevant for this group (OIDC IDP is an OAuth2 server), I'm posting it here. If you'd like me to re-post to the OIDC list then let me know please...Sorry for a noise, just in case :-) So, all the flows in OIDC Core have this section: http://openid.net/specs/openid-connect-core-1_0.html#Consent http://openid.net/specs/openid-connect-core-1_0.html#ImplicitConsent http://openid.net/specs/openid-connect-core-1_0.html#HybridConsent This is pure OAuth2 still. What I do not understand, if the response_type is 'id_token' and the requested scope is 'openid' only, http://openid.net/specs/openid-connect-core-1_0.html#Authentication then what is a consent screen really about ? If the response_code is 'id_token' then a user has already given the implicit authorization after visiting a client application web page and clicking "Sign In With Google"/etc, and signing in into OIDC IDP. I thought this is what "openid" alone is all about. Can someone clarify please if it is reasonable to skip challenging a user with a consent screen in this case. Thanks, Sergey From nobody Wed Oct 21 06:37:58 2015 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 604A41A8722 for ; Wed, 21 Oct 2015 06:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4j7IBt7E1Psj for ; Wed, 21 Oct 2015 06:37:55 -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 4486C1A7D83 for ; Wed, 21 Oct 2015 06:37:54 -0700 (PDT) X-AuditID: 12074424-f79106d000007367-9d-562795308f55 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 46.6E.29543.13597265; Wed, 21 Oct 2015 09:37:53 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t9LDbqNp013074; Wed, 21 Oct 2015 09:37:52 -0400 Received: from [192.168.128.56] (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 t9LDbo3V030467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 21 Oct 2015 09:37:51 -0400 To: Sergey Beryozkin , oauth@ietf.org References: <41395617-E5A9-4294-9F8B-DFE9E27F74F8@xmlgrrl.com> <56278DC4.3060600@gmail.com> From: Justin Richer Message-ID: <5627952C.8060509@mit.edu> Date: Wed, 21 Oct 2015 09:37:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56278DC4.3060600@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6noms4VT3MYPoaTouTb1+xWfxbau/A 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZTQvjS24KFJx7PwhtgbGqwJdjJwcEgImEv0P +5kgbDGJC/fWs3UxcnEICSxmkuj58xnK2cgoMfnEQSYI5zaTxNmF59hAWoQFoiU6J+4Bs0UE rCVuPJ7OCFH0mlFi29L/YHPZBFQlpq9pAbN5BdQkFq5dC2azAMW/9m8Es0UFYiTeb1rFCFEj KHFy5hMWEJtTQFNi+bv/7CA2s4CtxJ25u5khbHmJ7W/nME9gFJiFpGUWkrJZSMoWMDKvYpRN ya3SzU3MzClOTdYtTk7My0st0jXXy80s0UtNKd3ECA5UF5UdjM2HlA4xCnAwKvHwflioFibE mlhWXJl7iFGSg0lJlDekRz1MiC8pP6UyI7E4I76oNCe1+BCjBAezkghvdTdQjjclsbIqtSgf JiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgvfNZKBGwaLU9NSKtMycEoQ0EwcnyHAe oOEBU0CGFxck5hZnpkPkTzEqSonzWoAkBEASGaV5cL2gRJLw9rDpK0ZxoFeEeXVBqniASQiu +xXQYCagwQsfqYIMLklESEk1MKbtdlOr+3VY6oTK6t9zVY6ciLB/9/ZAZ5OBs5rkqlW/TCYq RbWXb6htnC0Yw7D4RprMxIMm3/WvqvAyC+3l6eVYW7Jijk+KtRCT3KHfV2TT/9QeKBBU3LNk fkucUSt7uKVRY8mlzZEHEv/LXPi9c6bVD4+sljiWymcOhzOumvHfnHxzV8nSYCWW4oxEQy3m ouJEAHH7IAX/AgAA Archived-At: Subject: Re: [OAUTH-WG] Is authorization challenge always needed in OIDC OAuth2 servers ? 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, 21 Oct 2015 13:37:57 -0000 You're assuming that the user actually took an action to get to that page. It's trivial for a website, any website, to craft a URL and redirect a user to the IdP. I could give you a link here in this email hidden behind a URL shortener or some other redirector. It would be very bad practice to release identity information to any site that was capable of doing this, and it would be likewise bad to assume authorization just because the user showed up at a URL. The ID token contains information like a unique identifier and potentially other claims (google puts in email addresses, for instance). The common practice, codified in both OAuth2 and OIDC, is "Trust On First Use", or TOFU. If it's a new situation (new client/RP, new scopes, something else you're not sure about), you ask the user. Then you (optionally) save that for next time, so if the same situation arises, you already have the user's decision and you don't need to prompt them. This can be further augmented by whitelisting trusted sites, where the IdP/AS is making the authorization decision and not the user. Hope this helps, -- Justin On 10/21/2015 9:06 AM, Sergey Beryozkin wrote: > Hi > > I can not subscribe to an OIDC spec list, had some earlier questions > not flowing to the list and given I'm not sure this question is > irrelevant for this group (OIDC IDP is an OAuth2 server), I'm posting > it here. If you'd like me to re-post to the OIDC list then let me know > please...Sorry for a noise, just in case :-) > > So, all the flows in OIDC Core have this section: > > http://openid.net/specs/openid-connect-core-1_0.html#Consent > http://openid.net/specs/openid-connect-core-1_0.html#ImplicitConsent > http://openid.net/specs/openid-connect-core-1_0.html#HybridConsent > > This is pure OAuth2 still. > > What I do not understand, if the response_type is 'id_token' and the > requested scope is 'openid' only, > > http://openid.net/specs/openid-connect-core-1_0.html#Authentication > > then what is a consent screen really about ? > > If the response_code is 'id_token' then a user has already given the > implicit authorization after visiting a client application web page > and clicking "Sign In With Google"/etc, and signing in into OIDC IDP. > I thought this is what "openid" alone is all about. > > Can someone clarify please if it is reasonable to skip challenging a > user with a consent screen in this case. > > Thanks, Sergey > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Oct 21 07:01:48 2015 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 F0B701A8860 for ; Wed, 21 Oct 2015 07:01:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 UbCcT5qvYXoI for ; Wed, 21 Oct 2015 07:01:45 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EECE21A8870 for ; Wed, 21 Oct 2015 07:01:44 -0700 (PDT) Received: by wijp11 with SMTP id p11so96647483wij.0 for ; Wed, 21 Oct 2015 07:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=EzDqEma1fBt1G96EHXZH5CURFA+EzJD3XYcmFR2eeLY=; b=y2RdqlRU/cRtGRlrFjKlH94A423Nx0F+sKzw6r4sdkmB/Vxrikk3naPjQacU1AiH6R iWTV6f9oEci8j8RJgZe2qqt/Y0Y5UHznPVd/nyBmOfp+52wcSyjwIZluK3y3ZqSFDjNE nfjWhAfEHXY021Py0yUvWsgzhV1C0lg6XuXRbdpCep7dVTbilpK1QfGIkQB8BhafxE9t 5RRRZSPp0vht6KenEicQ0l0XLpkKJVVmEtipCNq5jwh1CCYfk2JJY9+bl4hr8fRXnm/T XEGVrEtft7p7EooiScV6dtbgmkW6LTcgNT4Sq3XheiIsH5SDr3cZuRszymf8nZPMwbmD mMjw== X-Received: by 10.181.13.48 with SMTP id ev16mr33356504wid.40.1445436103517; Wed, 21 Oct 2015 07:01:43 -0700 (PDT) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id cc8sm10603222wjc.46.2015.10.21.07.01.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2015 07:01:42 -0700 (PDT) To: Justin Richer , oauth@ietf.org References: <41395617-E5A9-4294-9F8B-DFE9E27F74F8@xmlgrrl.com> <56278DC4.3060600@gmail.com> <5627952C.8060509@mit.edu> From: Sergey Beryozkin Message-ID: <56279AC5.5040605@gmail.com> Date: Wed, 21 Oct 2015 15:01:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5627952C.8060509@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Is authorization challenge always needed in OIDC OAuth2 servers ? 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, 21 Oct 2015 14:01:47 -0000 Hi Justin It helps, many thanks. I understand why 'MUST' is there now... Cheers, Sergey On 21/10/15 14:37, Justin Richer wrote: > You're assuming that the user actually took an action to get to that > page. It's trivial for a website, any website, to craft a URL and > redirect a user to the IdP. I could give you a link here in this email > hidden behind a URL shortener or some other redirector. It would be very > bad practice to release identity information to any site that was > capable of doing this, and it would be likewise bad to assume > authorization just because the user showed up at a URL. The ID token > contains information like a unique identifier and potentially other > claims (google puts in email addresses, for instance). > > The common practice, codified in both OAuth2 and OIDC, is "Trust On > First Use", or TOFU. If it's a new situation (new client/RP, new scopes, > something else you're not sure about), you ask the user. Then you > (optionally) save that for next time, so if the same situation arises, > you already have the user's decision and you don't need to prompt them. > This can be further augmented by whitelisting trusted sites, where the > IdP/AS is making the authorization decision and not the user. > > Hope this helps, > -- Justin > > On 10/21/2015 9:06 AM, Sergey Beryozkin wrote: >> Hi >> >> I can not subscribe to an OIDC spec list, had some earlier questions >> not flowing to the list and given I'm not sure this question is >> irrelevant for this group (OIDC IDP is an OAuth2 server), I'm posting >> it here. If you'd like me to re-post to the OIDC list then let me know >> please...Sorry for a noise, just in case :-) >> >> So, all the flows in OIDC Core have this section: >> >> http://openid.net/specs/openid-connect-core-1_0.html#Consent >> http://openid.net/specs/openid-connect-core-1_0.html#ImplicitConsent >> http://openid.net/specs/openid-connect-core-1_0.html#HybridConsent >> >> This is pure OAuth2 still. >> >> What I do not understand, if the response_type is 'id_token' and the >> requested scope is 'openid' only, >> >> http://openid.net/specs/openid-connect-core-1_0.html#Authentication >> >> then what is a consent screen really about ? >> >> If the response_code is 'id_token' then a user has already given the >> implicit authorization after visiting a client application web page >> and clicking "Sign In With Google"/etc, and signing in into OIDC IDP. >> I thought this is what "openid" alone is all about. >> >> Can someone clarify please if it is reasonable to skip challenging a >> user with a consent screen in this case. >> >> Thanks, Sergey >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ From nobody Wed Oct 21 13:27:53 2015 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 A960A1B2EAB for ; Wed, 21 Oct 2015 13:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 y19DviBoPDyW for ; Wed, 21 Oct 2015 13:27:49 -0700 (PDT) Received: from nm8-vm3.bullet.mail.ne1.yahoo.com (nm8-vm3.bullet.mail.ne1.yahoo.com [98.138.91.138]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463381B2EA3 for ; Wed, 21 Oct 2015 13:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1445459267; bh=T2NEHEk8GH2Ad/BH5TIe4VereordYqtXaB22La5yqUw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=R/Qlf05ysdbW6u4PfYByOpupMSvcWOHlQVkvAu7rjfLVFqzG9N9MHcp+sz3jnVvmHDG42WlXEScGfAd9bsh3zbOFAPhpjpg2jluJSg6rSBlvWu7ZTwezS8NO0fN8hYo/uaViwvkvsPnAvpwsHZztIfWnx/+P2eeJo6ECHD+H9aUlTcmgMErPt/e9DXb4zZdJGibZEWo/+E/fovWWBlDTF0OpWrsm38c3kUKsV9Mk22OV5EvceAlJfvu/SGTDYRcsbAYcQG9VaWHaiQ1pw+KYUemMioAm34Or3hFBWnfWf4WDWEH/KTRIbq5RSZq/F4zO4QRFRq1kCwL+ba40r6z+8w== Received: from [98.138.100.118] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 21 Oct 2015 20:27:47 -0000 Received: from [98.138.89.166] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 21 Oct 2015 20:27:47 -0000 Received: from [127.0.0.1] by omp1022.mail.ne1.yahoo.com with NNFMP; 21 Oct 2015 20:27:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 583925.47843.bm@omp1022.mail.ne1.yahoo.com X-YMail-OSG: duTgFEkVM1m2K7CpQyrLJsNKmVhEmF7PG2MwxS2IlA61WsRoPy_VPnA54WpEKxI MjE_VSGNdXpThLiar_OReSgqr1uELVV0nLHoHaCxg8omdpVhrL5OYM0KCtEztB4r8xuw84IbQVvo Xft0ggbVids2_KlmF9sKfNnKRWjY6PwwHSkNXq0alyzJ61ekoIxm5oruosClzRUDhYMGHPU9vQ_m UW_oH0Z.Ygf.nTa.xS6F4YLaQtXGemG.DLsU9HhnFjwrb8canEmM2vlrwkkNgvFmaWU44A_D7Igr 2mwn4ke6lCD9Y7w4CcT0e.X1babF0yauYtiRXODmkz_naGuQ9EM5ZRWNoOMsvTjqNbg_Nutaow4m VZ_tuMqz5oTYKEi3_Lapxyg4N9qyWVVKSPNFLrWz8CGXZtri_ef._2y6qKcoJjbVU3BBeIdgjjMt u7oO4aLcyLEpi6H5V1y27eAb_x3R0NbR5XM972TU9emyNLHiUFpBKuthpRRPwQyf5aJxh3shLu8p Mbdnoquxs6S_7AbZjZg-- Received: by 98.138.101.163; Wed, 21 Oct 2015 20:27:47 +0000 Date: Wed, 21 Oct 2015 20:27:46 +0000 (UTC) From: Vivek Biswas To: Kathleen Moriarty , Hannes Tschofenig Message-ID: <1629428037.1277959.1445459266645.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1277958_975821870.1445459266638" Archived-At: Cc: "" Subject: Re: [OAUTH-WG] RFC 7662 on OAuth 2.0 Token Introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vivek Biswas List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 20:27:51 -0000 ------=_Part_1277958_975821870.1445459266638 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes indeed a nice job =C2=A0!!!!. I have one question on the RFC. Not sure where I can submit request for comments. Hence, adding to this ema= il thread In the use-case mentioned belowThe following is a non-normative example res= ponse for a token that has been revoked or is otherwise invalid: HTTP/1.1 200 OK Content-Type: application/json { "active": false } Where the token is revoked or invalid, why not send a HTTP response code of= 400 There are 2 benefits for the same.A. Just looking at the header, we know th= at token validation didn't went through. No need to look in the payload. Th= is is especially very helpful in gateway design implementation. B. You are further hiding from the user why the request failed and not lett= ing him know if the token was processed by the server. CheersVivek =20 From: Kathleen Moriarty To: Hannes Tschofenig =20 Cc: "" =20 Sent: Wednesday, October 21, 2015 4:47 AM Subject: Re: [OAUTH-WG] RFC 7662 on OAuth 2.0 Token Introspection =20 Yes, nice job! Sent from my iPhone > On Oct 21, 2015, at 4:20 AM, Hannes Tschofenig wrote: >=20 > Thank you Justin for the hard work! >=20 >> On 10/20/2015 06:32 PM, Justin Richer wrote: >> Thank you to everyone who helped make token introspection into a real st= andard! >>=20 >> =E2=80=94 Justin >>=20 >>> On Oct 19, 2015, at 6:56 PM, rfc-editor@rfc-editor.org wrote: >>>=20 >>> A new Request for Comments is now available in online RFC libraries. >>>=20 >>>=20 >>>=C2=A0 =C2=A0 =C2=A0 RFC 7662 >>>=20 >>>=C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 OAuth 2.0 Token Introspe= ction=20 >>>=C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 J. Richer, Ed. >>>=C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 Standards Track >>>=C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 IETF >>>=C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 October 2015 >>>=C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 ietf@justin.richer.org >>>=C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 17 >>>=C2=A0 =C2=A0 =C2=A0 Characters: 36591 >>>=C2=A0 =C2=A0 =C2=A0 Updates/Obsoletes/SeeAlso:=C2=A0 None >>>=20 >>>=C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-ietf-oauth-introspectio= n-11.txt >>>=20 >>>=C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.rfc-edi= tor.org/info/rfc7662 >>>=20 >>>=C2=A0 =C2=A0 =C2=A0 DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://dx.doi.org/1= 0.17487/RFC7662 >>>=20 >>> This specification defines a method for a protected resource to query >>> an OAuth 2.0 authorization server to determine the active state of an >>> OAuth 2.0 token and to determine meta-information about this token. >>> OAuth 2.0 deployments can use this method to convey information about >>> the authorization context of the token from the authorization server >>> to the protected resource. >>>=20 >>> This document is a product of the Web Authorization Protocol Working Gr= oup of the IETF. >>>=20 >>> This is now a Proposed Standard. >>>=20 >>> STANDARDS TRACK: This document specifies an Internet Standards Track >>> protocol for the Internet community, and requests discussion and sugges= tions >>> for improvements.=C2=A0 Please refer to the current edition of the Offi= cial >>> Internet Protocol Standards (https://www.rfc-editor.org/standards) for = the=20 >>> standardization state and status of this protocol.=C2=A0 Distribution o= f this=20 >>> memo is unlimited. >>>=20 >>> This announcement is sent to the IETF-Announce and rfc-dist lists. >>> To subscribe or unsubscribe, see >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >>>=20 >>> For searching the RFC series, see https://www.rfc-editor.org/search >>> For downloading RFCs, see https://www.rfc-editor.org/rfc.html >>>=20 >>> Requests for special distribution should be addressed to either the >>> author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 U= nless >>> specifically noted otherwise on the RFC itself, all RFCs are for >>> unlimited distribution. >>>=20 >>>=20 >>> The RFC Editor Team >>> Association Management Solutions, LLC >>>=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 >=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 ------=_Part_1277958_975821870.1445459266638 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Y= es indeed a nice job  !!!!.

I have one question o= n the RFC.
<= br>
Not sure where I can submit request for com= ments. Hence, adding to this email thread


In the use-case men= tioned below
The following is a non-normative exa=
mple response for a token that
   has been revoked or is otherwise invalid:

     HTTP/1.1 200 OK
     Content-Type: application/json

     {
      "active": false
     }
<= br id=3D"yui_3_16_0_1_1445454768787_13842" class=3D"">


Where the tok= en is revoked or invalid, why not send a HTTP response code of 400

There are 2 benefits for the same= .
A. Just looking at the = header, we know that token validation didn't went through. No need to look = in the payload. This is especially very helpful in gateway design implement= ation.

B. You are further hiding from the us= er why the request failed and not letting him know if the token was process= ed by the server.

Cheers
Vivek

From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.co= m>
To: Hannes Tscho= fenig <hannes.tschofenig@gmx.net>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
= Sent: Wednesday, Octo= ber 21, 2015 4:47 AM
Subject: Re: [OAUTH-WG] RFC 7662 on OAuth 2.0 Token Introspection

Yes, nice job!

Sent from my i= Phone

> On Oct 21, 2015, at 4:20 AM= , Hannes Tschofenig <hannes.tschofenig@gmx= .net> wrote:
>
> Thank yo= u Justin for the hard work!
>
>&= gt; On 10/20/2015 06:32 PM, Justin Richer wrote:
>>= Thank you to everyone who helped make token introspection into a real stan= dard!
>>
>> =E2=80=94 Just= in
>>
>>> On Oct 19, 20= 15, at 6:56 PM, rfc-editor@rfc-editor.org= wrote:
>>>
>>> A ne= w Request for Comments is now available in online RFC libraries.
>>>
>>>
&= gt;>>      RFC 7662
>>> >>>      Title:    &nbs= p; OAuth 2.0 Token Introspection
>>>  &nbs= p;   Author:    J. Richer, Ed.
>>&= gt;      Status:    Standards Track
>>>      Stream:    IETF
>>>      Date:      Octo= ber 2015
>>>      Mailbox: =   ietf@justin.richer.org
>>>      Pages:      17
>>>      Characters: 36591
>>>      Updates/Obsoletes/SeeAlso:  No= ne
>>>
>>>  &nb= sp;   I-D Tag:    draft-ietf-oauth-introspection-11.txt
>>>
>>>    &n= bsp; URL:        https://www.rfc-editor.org/= info/rfc7662
>>>
>>= >      DOI:        http://dx.do= i.org/10.17487/RFC7662
>>>
>>> This specification defines a method for a protected resource= to query
>>> an OAuth 2.0 authorization server = to determine the active state of an
>>> OAuth 2.= 0 token and to determine meta-information about this token.
>>> OAuth 2.0 deployments can use this method to convey informa= tion about
>>> the authorization context of the = token from the authorization server
>>> to the p= rotected resource.
>>>
>&g= t;> This document is a product of the Web Authorization Protocol Working= Group of the IETF.
>>>
>&= gt;> This is now a Proposed Standard.
>>> >>> STANDARDS TRACK: This document specifies an In= ternet Standards Track
>>> protocol for the Inte= rnet community, and requests discussion and suggestions
&= gt;>> for improvements.  Please refer to the current edition of = the Official
>>> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
&= gt;>> standardization state and status of this protocol.  Distri= bution of this
>>> memo is unlimited.
>>>
>>> This announcement is= sent to the IETF-Announce and rfc-dist lists.
>>&g= t; To subscribe or unsubscribe, see
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>> https://mailman.rfc-ed= itor.org/mailman/listinfo/rfc-dist
>>>
>>> For searching the RFC series, see https://ww= w.rfc-editor.org/search
>>> For downloading = RFCs, see https://www.rfc-editor.org/rfc.html
&= gt;>>
>>> Requests for special distributi= on should be addressed to either the
>>> author = of the RFC in question, or to rfc-editor@rf= c-editor.org.  Unless
>>> specifically = noted otherwise on the RFC itself, all RFCs are for
>&= gt;> unlimited distribution.
>>>
>>>
>>> The RFC Editor Team
>>> Association Management Solutions, LLC
>>>
>>>
&= gt;>> _______________________________________________
>>> OAuth mailing list
>>> = OAuth@ietf.org
>>> https://www= .ietf.org/mailman/listinfo/oauth



>&= gt;
>> ___________________________________________= ____
>> OAuth mailing list
>&g= t; OAuth@ietf.org
>> http= s://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.or= g
> https://www.ietf.org/mailman/lis= tinfo/oauth

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


------=_Part_1277958_975821870.1445459266638-- From nobody Wed Oct 21 14:01:46 2015 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 0E57F1B307B for ; Wed, 21 Oct 2015 14:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iZsDb9GV5FC3 for ; Wed, 21 Oct 2015 14:01:39 -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 3763A1B3078 for ; Wed, 21 Oct 2015 14:01:39 -0700 (PDT) X-AuditID: 12074424-f79106d000007367-b1-5627fd31c8ef Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id F0.F7.29543.13DF7265; Wed, 21 Oct 2015 17:01:37 -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 t9LL1aaU023216; Wed, 21 Oct 2015 17:01:36 -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 t9LL1Yjl002522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Oct 2015 17:01:35 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_C83AD921-28C9-4370-B54C-A9E8754756DC" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <1629428037.1277959.1445459266645.JavaMail.yahoo@mail.yahoo.com> Date: Wed, 21 Oct 2015 17:01:33 -0400 Message-Id: <1CCDDFCE-AB08-4539-9746-F21E24E039B0@mit.edu> References: <1629428037.1277959.1445459266645.JavaMail.yahoo@mail.yahoo.com> To: Vivek Biswas X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUixG6nrmv4Vz3MoP2CuMXSnfdYLRp25luc fPuKzWLSketMDiweO2fdZfdYvGk/m8eSJT+ZPGbNOswUwBLFZZOSmpNZllqkb5fAlfGnr4u9 4NN+xooDB08wNjDeWsbYxcjJISFgIrF93ixmCFtM4sK99WwgtpDAYiaJvf3GXYxcQPZGRokJ +w6yQzgPmSSO9F9kAaliFkiQ+P53DzuIzSugJ/Hq1mVWEFtYwFHiQtdrsA1sAqoS09e0MIHY nAK+Ej37poPVswDFO57/ZwMZyiwwj1Gi8eUkVohBVhJ7/z1jhzijVuLIrN9gcREBTYkn11+w QJwqK7H79yOmCYwCs5DcMQvJHRBxbYllC18zQ9iaEvu7l7NgimtIdH6byLqAkW0Vo2xKbpVu bmJmTnFqsm5xcmJeXmqRrrlebmaJXmpK6SZGcHS4qOxgbD6kdIhRgINRiYf3wh/1MCHWxLLi ytxDjJIcTEqivA8+A4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8Ea9B8rxpiRWVqUW5cOkpDlY lMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwFv4GahQsSk1PrUjLzClBSDNxcIIM5wEavhuk hre4IDG3ODMdIn+KUVFKnPcZSEIAJJFRmgfXC0peCW8Pm75iFAd6RZh3M0gVDzDxwXW/AhrM BDR44SNVkMEliQgpqQZGuZexDB+nzytR698QeUGVoW/vV/dfFzNX/zqpXJZb+Uzw4CxRib8B Xp13lriECiv/zxAwaLDxvnbr+VxvPeVPXx7/TDY448EWe2Avm3LI/IfT3UR3HRF6urD9u1Vz 1zmjnxEuYQsOqrxhffra0LzzwIPA6gPHmjsc9IyYb8dqlpjvvvgqLSBOiaU4I9FQi7moOBEA BE+1QzkDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] RFC 7662 on OAuth 2.0 Token Introspection 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, 21 Oct 2015 21:01:43 -0000 --Apple-Mail=_C83AD921-28C9-4370-B54C-A9E8754756DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This was discussed extensively and is covered in the text of the RFC, = but the summary is simple: the request isn=E2=80=99t a bad request = (which is what 400 means). It=E2=80=99s a perfectly valid request, = it=E2=80=99s just that the token you=E2=80=99re asking about might not = be valid for some reason, or it might not be valid *for you*. Either = way, you don=E2=80=99t actually want to divulge too much information = about why the token is bad in a production environment or else you let = attackers poke around and learn more about the system than they really = need to know to function. As far as a protected resource is concerned, = it likely doesn=E2=80=99t matter anyway. And an OAuth client isn=E2=80=99t= going to be propagated that information, it=E2=80=99s just going to = have to go get a new token. Since an OAuth client needs to be able to = get a new token at a moment=E2=80=99s notice anyway, there=E2=80=99s not = really anything useful in communicating it. This is a similar approach to the Revocation spec (RFC 7009) which = always returns 200 whether or not the token existed or was successfully = revoked. In any event, the client needs to assume that the token was = revoked and stop using it, and it=E2=80=99s up to the server to deal = with the consequences of error conditions.=20 Hope this helps, =E2=80=94 Justin > On Oct 21, 2015, at 4:27 PM, Vivek Biswas = wrote: >=20 > Yes indeed a nice job !!!!. >=20 > I have one question on the RFC. >=20 > Not sure where I can submit request for comments. Hence, adding to = this email thread >=20 >=20 > In the use-case mentioned below > The following is a non-normative example response for a token that > has been revoked or is otherwise invalid: >=20 > HTTP/1.1 200 OK > Content-Type: application/json >=20 > { > "active": false > } >=20 >=20 >=20 > Where the token is revoked or invalid, why not send a HTTP response = code of 400 >=20 > There are 2 benefits for the same. > A. Just looking at the header, we know that token validation didn't = went through. No need to look in the payload. This is especially very = helpful in gateway design implementation. >=20 > B. You are further hiding from the user why the request failed and not = letting him know if the token was processed by the server. >=20 > Cheers > Vivek >=20 > =20 >=20 > From: Kathleen Moriarty > To: Hannes Tschofenig =20 > Cc: "" =20 > Sent: Wednesday, October 21, 2015 4:47 AM > Subject: Re: [OAUTH-WG] RFC 7662 on OAuth 2.0 Token Introspection >=20 > Yes, nice job! >=20 > Sent from my iPhone >=20 > > On Oct 21, 2015, at 4:20 AM, Hannes Tschofenig = > wrote: > >=20 > > Thank you Justin for the hard work! > >=20 > >> On 10/20/2015 06:32 PM, Justin Richer wrote: > >> Thank you to everyone who helped make token introspection into a = real standard! > >>=20 > >> =E2=80=94 Justin > >>=20 > >>> On Oct 19, 2015, at 6:56 PM, rfc-editor@rfc-editor.org = wrote: > >>>=20 > >>> A new Request for Comments is now available in online RFC = libraries. > >>>=20 > >>>=20 > >>> RFC 7662 > >>>=20 > >>> Title: OAuth 2.0 Token Introspection=20 > >>> Author: J. Richer, Ed. > >>> Status: Standards Track > >>> Stream: IETF > >>> Date: October 2015 > >>> Mailbox: ietf@justin.richer.org = > >>> Pages: 17 > >>> Characters: 36591 > >>> Updates/Obsoletes/SeeAlso: None > >>>=20 > >>> I-D Tag: draft-ietf-oauth-introspection-11.txt > >>>=20 > >>> URL: https://www.rfc-editor.org/info/rfc7662 = > >>>=20 > >>> DOI: http://dx.doi.org/10.17487/RFC7662 = > >>>=20 > >>> This specification defines a method for a protected resource to = query > >>> an OAuth 2.0 authorization server to determine the active state of = an > >>> OAuth 2.0 token and to determine meta-information about this = token. > >>> OAuth 2.0 deployments can use this method to convey information = about > >>> the authorization context of the token from the authorization = server > >>> to the protected resource. > >>>=20 > >>> This document is a product of the Web Authorization Protocol = Working Group of the IETF. > >>>=20 > >>> This is now a Proposed Standard. > >>>=20 > >>> STANDARDS TRACK: This document specifies an Internet Standards = Track > >>> protocol for the Internet community, and requests discussion and = suggestions > >>> for improvements. Please refer to the current edition of the = Official > >>> Internet Protocol Standards (https://www.rfc-editor.org/standards = ) for the=20 > >>> standardization state and status of this protocol. Distribution = of this=20 > >>> memo is unlimited. > >>>=20 > >>> This announcement is sent to the IETF-Announce and rfc-dist lists. > >>> To subscribe or unsubscribe, see > >>> https://www.ietf.org/mailman/listinfo/ietf-announce = > >>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist = > >>>=20 > >>> For searching the RFC series, see = https://www.rfc-editor.org/search > >>> For downloading RFCs, see https://www.rfc-editor.org/rfc.html = > >>>=20 > >>> Requests for special distribution should be addressed to either = the > >>> author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > >>> specifically noted otherwise on the RFC itself, all RFCs are for > >>> unlimited distribution. > >>>=20 > >>>=20 > >>> The RFC Editor Team > >>> Association Management Solutions, LLC > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 > >>=20 > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth = > >=20 > > _______________________________________________ > > 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 --Apple-Mail=_C83AD921-28C9-4370-B54C-A9E8754756DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This was discussed extensively and is covered in the text of = the RFC, but the summary is simple: the request isn=E2=80=99t a bad = request (which is what 400 means). It=E2=80=99s a perfectly valid = request, it=E2=80=99s just that the token you=E2=80=99re asking about = might not be valid for some reason, or it might not be valid *for you*. = Either way, you don=E2=80=99t actually want to divulge too much = information about why the token is bad in a production environment or = else you let attackers poke around and learn more about the system than = they really need to know to function. As far as a protected resource is = concerned, it likely doesn=E2=80=99t matter anyway. And an OAuth client = isn=E2=80=99t going to be propagated that information, it=E2=80=99s just = going to have to go get a new token. Since an OAuth client needs to be = able to get a new token at a moment=E2=80=99s notice anyway, there=E2=80=99= s not really anything useful in communicating it.

This is a similar approach to the = Revocation spec (RFC 7009) which always returns 200 whether or not the = token existed or was successfully revoked. In any event, the client = needs to assume that the token was revoked and stop using it, and it=E2=80= =99s up to the server to deal with the consequences of error = conditions. 

Hope= this helps,
 =E2=80=94 Justin

On Oct 21, 2015, at 4:27 PM, Vivek Biswas <vivek_biswas@yahoo.com> wrote:

Yes indeed a nice job =  !!!!.

I have one question = on the RFC.

Not sure where I can = submit request for comments. Hence, adding to this email = thread


In = the use-case mentioned below
The following is a non-normative example response for a =
token that
   has been revoked or is otherwise invalid:

     HTTP/1.1 200 OK
     Content-Type: application/json

     {
      "active": false
     }



Where = the token is revoked or invalid, why not send a HTTP response code of = 400

There are 2 benefits = for the same.
A. Just looking at the header, we know that token validation = didn't went through. No need to look in the payload. This is especially = very helpful in gateway design implementation.

B. You are further hiding from the user why the request = failed and not letting him know if the token was processed by the = server.

Cheers
Vivek

From: Kathleen = Moriarty <kathleen.moriarty.ietf@gmail.com>
To: = Hannes Tschofenig <hannes.tschofenig@gmx.net>
Cc: = "<oauth@ietf.org>" = <oauth@ietf.org> =
Sent: = Wednesday, October 21, 2015 4:47 AM
Subject: Re: = [OAUTH-WG] RFC 7662 on OAuth 2.0 Token Introspection
=

Yes, nice job!

Sent from my = iPhone

> = On Oct 21, 2015, at 4:20 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
> Thank you Justin for = the hard work!
>
>> On 10/20/2015 06:32 PM, Justin Richer wrote:
>> Thank you to everyone who helped make = token introspection into a real standard!
>>
>> =E2=80=94 = Justin
>>
>>> On Oct 19, 2015, at 6:56 PM, rfc-editor@rfc-editor.org wrote:
>>>
>>> A new = Request for Comments is now available in online RFC libraries.
>>>
>>>
>>>  =     RFC 7662
>>>
>>>      Title:  =     OAuth 2.0 Token Introspection
>>>      Author:    J. = Richer, Ed.
>>>    =   Status:    Standards Track
>>>      Stream:    = IETF
>>>      = Date:      October 2015
>>>      Mailbox:    ietf@justin.richer.org
>>>      Pages:      = 17
>>>      = Characters: 36591
>>>    =   Updates/Obsoletes/SeeAlso:  None
>>>
>>>  =     I-D Tag:    = draft-ietf-oauth-introspection-11.txt
>>>
>>>  =     URL:        https://www.rfc-editor.org/info/rfc7662
>>>
>>>  =     DOI:        http://dx.doi.org/10.17487/RFC7662
>>>
>>> This = specification defines a method for a protected resource to query
>>> an OAuth 2.0 authorization server = to determine the active state of an
>>> OAuth 2.0 token and to determine = meta-information about this token.
>>> OAuth 2.0 deployments can use this method to = convey information about
>>> the = authorization context of the token from the authorization server
>>> to the protected resource.
>>>
>>> This document is a product of the Web = Authorization Protocol Working Group of the IETF.
>>>
>>> This = is now a Proposed Standard.
>>> =
>>> STANDARDS TRACK: This = document specifies an Internet Standards Track
>>> protocol for the Internet community, and = requests discussion and suggestions
>>> for improvements.  Please refer to the = current edition of the Official
>>> = Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
>>> standardization state and status = of this protocol.  Distribution of this
>>> memo is unlimited.
>>>
>>> This = announcement is sent to the IETF-Announce and rfc-dist lists.
>>> To subscribe or unsubscribe, = see
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist>>>
>>> For searching the RFC series, see https://www.rfc-editor.org/search
>>> For downloading RFCs, see https://www.rfc-editor.org/rfc.html
>>>
>>> Requests for special distribution should be = addressed to either the
>>> author = of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
>>> specifically noted otherwise on the RFC itself, = all RFCs are for
>>> unlimited = distribution.
>>>
>>>
>>> The = RFC Editor Team
>>> Association = Management Solutions, LLC
>>>
>>>
>>> = _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> = https://www.ietf.org/mailman/listinfo/oauth



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

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


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

= --Apple-Mail=_C83AD921-28C9-4370-B54C-A9E8754756DC-- From nobody Wed Oct 21 15:59:44 2015 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 A19DC1B3384 for ; Wed, 21 Oct 2015 15:59: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, 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 OoxpmdHLXLoe for ; Wed, 21 Oct 2015 15:59:14 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2F41B3387 for ; Wed, 21 Oct 2015 15:59:14 -0700 (PDT) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 54CDD38EF0 for ; Wed, 21 Oct 2015 15:59:14 -0700 (PDT) From: "Jim Schaad" To: References: <068401d10c42$95cb0460$c1610d20$@augustcellars.com> In-Reply-To: Date: Wed, 21 Oct 2015 15:56:32 -0700 Message-ID: <06d001d10c53$bae677a0$30b366e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQH7dnCLiLg4OThFW1QrdyT94ohFGp4htAfggAAGfMA= Archived-At: Subject: [OAUTH-WG] FW: [jose] Cross group Working Group Last Call - draft-ietf-jose-jws-sigining-input-otpions 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, 21 Oct 2015 22:59:43 -0000 > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Wednesday, October 21, 2015 3:33 PM > To: 'oath@ietf.org' > Cc: 'jose@ietf.org' > Subject: RE: [jose] Cross group Working Group Last Call - draft-ietf-jose-jws- > sigining-input-otpions > > > > > -----Original Message----- > > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad > > Sent: Wednesday, October 21, 2015 1:54 PM > > To: oauth@augustcellars.com > > Cc: jose@ietf.org > > Subject: [jose] Cross group Working Group Last Call - > > draft-ietf-jose-jws- sigining-input-otpions > > > > In the process of starting the Chair Writeup on this document, I noted > > and remembered that there is an update to a document that is a product > > of the OAuth working group. For this reason I am asking for comments > > on the draft from the OAuth working group before it progresses. > > > > Please send any comments that you might have on this document before > > November 1st. > > > > Thanks > > > > Jim > > JOSE Working Group Co-Chair > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose From nobody Fri Oct 23 19:23:44 2015 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 954831B2EFE for ; Fri, 23 Oct 2015 19:23:43 -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 gaceC2HwVc-j for ; Fri, 23 Oct 2015 19:23:42 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B7BE1B2EFB for ; Fri, 23 Oct 2015 19:23:42 -0700 (PDT) Received: by wicll6 with SMTP id ll6so52381509wic.1 for ; Fri, 23 Oct 2015 19:23:40 -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=FRkOVbu9dJnsRArTeVoPCNyjHPEtT+r/+CS9DjTZOp8=; b=sKVIPtLQ/DFJaENvI+s3GX4eGf9/Tvlh7dtd6EprWQgoxEerqcob+tjpbW5LkVp3IQ Wyiw0yYvFaaw1A2Kh1c/I1Nfp6v7OErJX0e5LtS/HCVWxj8JEngDZUCaKaxZUeTap+I9 Md/rhdBMbotkR711wQLzZFbaB7vGJq2zpPTnB0agCIKksgt2BmMRVfPmci4Nu5IyFGVo 5EzrIXk4/9u0Ajhoex6isAIRjl817Q3OVCTURofHWYJuqCxOC/h2nCui3Zd1DsKsoa+Y uYI+0NyhlX1Ap7yGn8/JM1WBESO+BNKq5Fo+8SgKoDAJnt0kjVsuQz33HtX/RVxwUhxi ilXA== MIME-Version: 1.0 X-Received: by 10.194.123.132 with SMTP id ma4mr7326485wjb.140.1445653420859; Fri, 23 Oct 2015 19:23:40 -0700 (PDT) Received: by 10.27.125.70 with HTTP; Fri, 23 Oct 2015 19:23:40 -0700 (PDT) Date: Fri, 23 Oct 2015 22:23:40 -0400 Message-ID: From: Ofer Nave To: "" Content-Type: multipart/alternative; boundary=089e0118310e9e69fa0522d06adc Archived-At: Subject: [OAUTH-WG] token endpoint: 400 or 401? 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, 24 Oct 2015 02:23:43 -0000 --089e0118310e9e69fa0522d06adc Content-Type: text/plain; charset=UTF-8 I'm using the auth code flow, and supporting basic auth for client auth on the token endpoint. In the OAuth spec it says to respond with 400 and a json body with error: invalid_client if client auth fails. However, doesn't RFC 2617 say to respond with 401 and a WWW-Authenticate header? Does the OAuth spec supercede 2617 in this case? -ofer --089e0118310e9e69fa0522d06adc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm using the auth code flow, and supporting= basic auth for client auth on the token endpoint.

In the OAut= h spec it says to respond with 400 and a json body with error: invalid_clie= nt if client auth fails.=C2=A0 However, doesn't RFC 2617 say to respond= with 401 and a WWW-Authenticate header?=C2=A0 Does the OAuth spec superced= e 2617 in this case?

-ofer
--089e0118310e9e69fa0522d06adc-- From nobody Tue Oct 27 15:42:29 2015 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 1A6051A1A70 for ; Tue, 27 Oct 2015 15:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.478 X-Spam-Level: X-Spam-Status: No, score=-0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, 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 u3WNtWtkPvPT for ; Tue, 27 Oct 2015 15:42:24 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB6F1A1A68 for ; Tue, 27 Oct 2015 15:42:24 -0700 (PDT) Received: by iody8 with SMTP id y8so82402633iod.1 for ; Tue, 27 Oct 2015 15:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:content-type; bh=mRBvh50fkLarKmwf+I+f/hZsOaN7efuHCTRZC4TAD5o=; b=BM3dBgrap2Zwj4HMUcGC64D6e98dUgs7VtkewUQ+xTzwZK2mqq8e+WgqBe+6l22p6s KbGv1y6PI94FcfyjZ9d4zTFasTsyzaoelwtNwtTzHRsD6xafDo3yES1XoEc2XIvrh4Dn rujC8Jf97Tehw3WRd8JlGT76F76ydNhz436IM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=mRBvh50fkLarKmwf+I+f/hZsOaN7efuHCTRZC4TAD5o=; b=HU6inR8sq6RMyst+Y5EFJPZZ6ib9GJ1z9tlRP10p6jBVbwOgXzsWmZeg7fd3hZTa6X j2WTHIvq8woMXgixzzfZdya8yhyxyjiiXXSFGlVm777Z632jjksxD8n70bubdIRSze8k fkHGnC8UUciji6Ij5xgAgky1YqfxjKXGtIoX3N/6mq2ic4N0zukZdOuQvSPW+4rfkuiU QeGJz+9BJa9hZBK6PbZUWpy6jkchU+Wee9c7rU0NE3oGGgmpFiats7OpkL+bKU9FHau7 Y+o+LK1PoSLfhCzIxuQn/yK3UV1+xxfkEF0dib38B1nFqveYB/42pnJw92X07KLp+h0t OQOg== X-Gm-Message-State: ALoCoQko1KKrhZgTSWlOoFG+LkMUa1HniMFlMh2jBu8rZ8VinxjOuVILsLE/VSdhlCQtjFJjUHP5 X-Received: by 10.107.7.86 with SMTP id 83mr48613036ioh.48.1445985743711; Tue, 27 Oct 2015 15:42:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.117.132 with HTTP; Tue, 27 Oct 2015 15:41:54 -0700 (PDT) From: Brian Campbell Date: Tue, 27 Oct 2015 16:41:54 -0600 Message-ID: To: =?UTF-8?B?5bSO5p2R5aSP5b2m?= , John Bradley , oauth Content-Type: multipart/alternative; boundary=001a113ed3e09aec4705231dcac1 Archived-At: Subject: [OAUTH-WG] some WGLC comments on draft-ietf-oauth-jwsreq-06 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, 27 Oct 2015 22:42:27 -0000 --001a113ed3e09aec4705231dcac1 Content-Type: text/plain; charset=UTF-8 Sakimura-san, Senior Bradley, and distinguished members of the OAUTH WG, I re-read draft-ietf-oauth-jwsreq (-06 anyway, it'd been a while) for WGLC and, while I feel it's in pretty good shape, I did have a few comments on the draft. Those are listed below in roughly the order I came across things while reading the document. To my eye, "oauth-jar" looks a bit awkward. I'd suggest changing the abbrev to something like "OAuth JAR". >From the wording in Section 3 , it is unclear whether the Request Object can be a JWE only or if a JWS is always used (with alg:none for unsigned) and is nested within a JWE when encryption but not singing is needed. To my reading there is text that suggest both cases. Which is it? I think some clarification is needed around this. Section 5.1 doesn't help me as I'm unsure if "unsigned (plaintext) Request Object" is an out-of-date usage of the old way to refer to the "none" JWS alg or is intended to mean the straight up JSON of the request object parameters. Also in Section 3 , the sentence 'The Authorization Request Object MAY alternatively be sent by reference using the "request_uri" parameter.' reads a little awkward because the other alternative isn't explicit discussed anywhere nearby. Perhaps something like "The Authorization Request Object may be sent by value as described in section 4.1 or by reference as described in section 4.2."? Also in Section 3 , the sentence "If a required parameter is not present in neither the query parameter nor the Request Object, it forms a malformed request." made my brain hurt. Maybe reword to something like, "If a required parameter is missing from both the query parameters and the Request Object, the request is considered malformed."? Also in Section 3 , '... the Authorization Request Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience) as members ...', however, that will produce a parameter name conflict with the "aud" parameter from OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution. Seems like draft-ietf-oauth-pop-key-distribution will need to change its parameter name (aud in JWT is pretty well established). And shouldn't draft-ietf-oauth-jwsreq register some of the JWT's Registered Claim Names (at least iss and aud but maybe exp and others) as authorization request OAuth parameters ? Also in Section 3 , I personally feel like the "extension variables" detract from the example being able to easily convey the concept. I would suggest using only 'vanilla' OAuth parameters. Or, at the very least, removing the "claims" stuff, which doubles the space used by the example and is a very OpenID Connect specific thing. This applies to the examples throughout the draft including those that have the encoded JWT Request Object. In Section 4 , the whole "The client constructs the authorization request URI by ..." followed by the list of parameters is somewhat awkward to me - especially with the "REQUIRED"s. Why list "state" here and none of the others here? I think I know why (you expect state to vary on each request but not others) but a lot of inferring needs to happen from the reader. For the extension defined in this document, one uses either request_uri or request (but not both, right? I'm not sure it's explicitly stated anywhere) and whatever other parameters are needed in the given situation. Maybe just some text towards that end rather than the list format? Also in Section 4 , the request_uri in the example is a lot like the URI that's used for redirect_uri in a lot of places (the /cb path, I think, was intended to short for callback). I mean, it *could* happen but the example is more confusing than needs to be. It's also too long/wide for the page - add some line breaks, which are for display purposes only. Perhaps move this example to 4.2(.1) somewhere and match the value with the value shown there? Also in Section 4 , the sentence that starts with 'When the "request" parameter is used...' suggests that the text about JWT parameters superseding others is only applicable to the pass by value method but it applies to both. Perhaps change '"request" parameter' to 'Request Object'? The second paragraph of Section 4.2.1 talks about "requested values for Claims" which is an OpenID Connect thing that isn't really applicable to this draft. Can this paragraph be dropped or made more general to be about any potentially sensitive or PII data? Also in Section 4.2.1 , is "... at a URL the Server can access... " - assume the "Authorization Sever"? Isn't it a bit odd in Section 5.2 to talk about the "request_object_signing_alg" which is defined in OpenID Connect Dynamic Client Registration (which is not referenced) and kinda mentioned in OpenID Connect Core (informative referenced)? I don't know that it belongs here? Or if it does, what about request_object_encryption_alg and request_object_encryption_enc? I suppose related to that is the question of if/how to use the client_secret for HMAC and symmetric encryption algorithms and if that needs to be discussed here? Indicating public key(s) too for that matter. Seems like all the metadata/registration stuff should be in here. Or it should all be out of scope. But just the request_object_signing_alg seems odd to me. Section 6 says that "... this document defines additional error values ..." but those were previously defined in 3.1.2.6 of OpenID Connect Core . Maybe just change the wording to reflect the real state of things? Section 7 says that "The request_object_signing_alg OAuth Dynamic Client Registration Metadata is pending registration by OpenID Connect Dynamic Registration specification." But is that true? The registry doesn't have it and Connect's Registration "makes no requests of IANA". As I'm sure reading this has been a ton of fun for the editors, I'm sure you will be happy to please add me to the Acknowledgements Section ;) --001a113ed3e09aec4705231dcac1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sakimura-san, Senior Bradley, and distinguished = members of the OAUTH WG,

I re-read draft-ietf-oauth-jwsre= q (-06 anyway, it'd been a while) for WGLC and, while I feel it's i= n pretty good shape, I did have a few comments on the draft. Those are list= ed below in roughly the order I came across things while reading the docume= nt.

To my eye, "oauth-jar" looks a bit awkward= . I'd suggest changing the abbrev to something like
"OAuth JAR= ".

From the wording in Section 3,= it is unclear whether the Request Object can be a JWE only or if a JWS is = always used (with alg:none for unsigned) and is nested within a JWE when en= cryption but not singing is needed. To my reading there is text that sugges= t both cases. Which is it? I think some clarification is needed around this= . Section 5.1 doesn't help me as I'm unsu= re if "unsigned (plaintext) Request Object" is an out-of-date usa= ge of the old way to refer to the "none" JWS alg or is intended t= o mean the straight up JSON of the request object parameters.

Also in Section 3, the sentence 'The Authoriza= tion Request Object MAY alternatively be sent by reference using the "= request_uri" parameter.' reads a little awkward because the other = alternative isn't explicit discussed anywhere nearby. Perhaps something= like "The Authorization Request Object may be sent by value as descri= bed in section 4.1 or by reference as described in section 4.2."?
<= br>Also in Section 3, the sentence "If a requi= red parameter is not present in neither the query parameter nor the Request= Object, it forms a malformed request." made my brain hurt. Maybe rewo= rd to something like, "If a required parameter is missing from both th= e query parameters and the Request Object, the request is considered malfor= med."?

Also in Section 3, = 9;... the Authorization Request Object SHOULD contain the Claims "iss&= quot; (issuer) and "aud" (audience) as members ...', however,= that will produce a parameter name conflict with the "aud" param= eter from OAuth 2.0 Proof-of-Possession: Authorizat= ion Server to Client Key Distribution. Seems like draft-ietf-oauth-pop-= key-distribution will need to change its parameter name (aud in JWT is pret= ty well established). And shouldn't draft-ietf-oauth-jwsreq register so= me of the JWT's Registered Claim Names (at least iss and aud but = maybe exp and others) as authorization request OAuth parameters?

Also in Sectio= n 3, I personally feel like the "extension variables" detract= from the example being able to easily convey the concept. I would suggest = using only 'vanilla' OAuth parameters. Or, at the very least, remov= ing the "claims" stuff, which doubles the space used by the examp= le and is a very OpenID Connect specific thing. This applies to the example= s throughout the draft including those that have the encoded JWT Request Ob= ject.

In Section 4, the whole &q= uot;The client constructs the authorization request URI by ..." follow= ed by the list of parameters is somewhat awkward to me - especially with th= e "REQUIRED"s. Why list "state" here and none of the ot= hers here? I think I know why (you expect state to vary on each request but= not others) but a lot of inferring needs to happen from the reader.=C2=A0 = For the extension defined in this document, one uses either request_uri or = request (but not both, right? I'm not sure it's explicitly stated a= nywhere) and whatever other parameters are needed in the given situation. M= aybe just some text towards that end rather than the list format?

Also in Section 4, the request_uri in the = example is a lot like the URI that's used for redirect_uri in a lot of = places (the /cb path, I think, was intended to short for callback). I mean,= it *could* happen but the example is more confusing than needs to be. It&#= 39;s also too long/wide for the page - add some line breaks, which are for = display purposes only. Perhaps move this example to 4.2(.1) somewhere and m= atch the value with the value shown there?

Also in Section 4, the sentence that starts with 'When the "reques= t" parameter is used...' suggests that the text about JWT paramete= rs superseding others is only applicable to the pass by value method but it= applies to both. Perhaps change '"request" parameter' to= 'Request Object'?

The second paragraph of Section 4.2.1 talks about "requested values for = Claims" which is an OpenID Connect thing that isn't really applica= ble to this draft. Can this paragraph be dropped or made more general to be= about any potentially sensitive or PII data?

Also in Section 4.2.1, is "... at a URL the Server ca= n access... " - assume the "Authorization Sever"?

Isn't it a bit odd in Section 5.2 to= talk about the "request_object_signing_alg" which is defined in = OpenID Connect Dynamic Client Registration (which is no= t referenced) and kinda mentioned in OpenID Connect Core (infor= mative referenced)? I don't know that it belongs here? Or if it does, w= hat about request_object_encryption_alg and request_object_encryption_enc? = I suppose related to that is the question of if/how to use the client_secre= t for HMAC and symmetric encryption algorithms and if that needs to be disc= ussed here? Indicating public key(s) too for that matter. Seems like all th= e metadata/registration stuff should be in here. Or it should all be out of= scope. But just the request_object_signing_alg seems odd to me.

Section 6 says that "... this document= defines additional error values ..." but those were previously define= d in 3.1.2.6 of OpenID Connect Core. Maybe just chang= e the wording to reflect the real state of things? =C2=A0
Section 7 says that "The request_= object_signing_alg OAuth Dynamic Client Registration Metadata is pending re= gistration by OpenID Connect Dynamic Registration specification." But = is that true? The registry = doesn't have it and Connect's Registration= "makes no requests of IANA".

As I'm sure = reading this has been a ton of fun for the editors, I'm sure you will b= e happy to please add me to the Acknowledgements Sectio= n ;)




=
--001a113ed3e09aec4705231dcac1-- From nobody Wed Oct 28 15:16:39 2015 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 99F2B1AD272 for ; Wed, 28 Oct 2015 15:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TkByfJ8B9_O3 for ; Wed, 28 Oct 2015 15:16:35 -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 BEE4C1AD291 for ; Wed, 28 Oct 2015 15:16:34 -0700 (PDT) X-AuditID: 12074422-f79976d0000078ca-97-56314941d837 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id CF.ED.30922.14941365; Wed, 28 Oct 2015 18:16:33 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t9SMGWYC013423; Wed, 28 Oct 2015 18:16:32 -0400 Received: from [10.255.233.129] (sjspeed.wiline.com [64.71.18.60]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t9SMGSkX005877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2015 18:16:30 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_7781E788-D0BD-461B-8A30-96571FF7D2BD" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Wed, 28 Oct 2015 15:16:27 -0700 Message-Id: <152AD4F1-84EF-47DC-9A41-C7413DE5464B@mit.edu> References: To: Brian Campbell X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsUixG6nouvoaRhmsGaLlMXq/zcZLXbdPsJo cfLtKzaL1Xf/sjmweCxZ8pPJY8mv84wed49eZPG4fXsjSwBLFJdNSmpOZllqkb5dAlfGg9+/ 2Av+zWKs6H/8mL2BcW8LYxcjJ4eEgInEjysbmCFsMYkL99azdTFycQgJLGaS2LShkRUkISSw kVHi8iMZiMR+Jol3q+axgCSYBRIk7m9uBbN5BfQkXt26DNYgLOAh8eP1P7A4m4CqxPQ1LUwg NqdAoMSJJzvZQWwWoPjSZ9tZIeaUSizq2MoMMcdK4kX/daBeDqBlARJT+0JAwiIC+hK3n85h hzhUVmL370dMExgFZiG5YhaSKyDi2hLLFr5mhrA1JfZ3L2fBFNeQ6Pw2kXUBI9sqRtmU3Crd 3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2M4NhwUdrB+POg0iFGAQ5GJR5eDwPDMCHWxLLi ytxDjJIcTEqivAXuQCG+pPyUyozE4oz4otKc1OJDjBIczEoivNIsQDnelMTKqtSifJiUNAeL kjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQne+SBDBYtS01Mr0jJzShDSTBycIMN5gIZ7eYAM Ly5IzC3OTIfIn2JUlBLnfQTSLACSyCjNg+sFpS4HdyGbV4ziQK8I8x4AqeIBpj247ldAg5mA Brtf0QUZXJKIkJJqYKy9LPjGJZdz2fQW6ekKGV0H+pNt/MyuHiyb5bd6hUL02U4xU5sSdYVG 4bBTO0+ZiZRMmHpv36q4mmzn4xOvc6w4dPDd0eIt9p7G6a9NykOW7mNbnCyZKPZR8Z2OfnPV NZE/D+tUTC5eb//gvM6CIV4v+6PGYgNRzUf/l6xUZi+d8u/elCkV7kosxRmJhlrMRcWJAAYy Lt44AwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] some WGLC comments on draft-ietf-oauth-jwsreq-06 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, 28 Oct 2015 22:16:38 -0000 --Apple-Mail=_7781E788-D0BD-461B-8A30-96571FF7D2BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The errata/update version of Connect=E2=80=99s registration spec need to = register a bunch of stuff in the Dyn-Reg IANA registry, but I don=E2=80=99= t think that=E2=80=99s been done yet. =E2=80=94 Justin > On Oct 27, 2015, at 3:41 PM, Brian Campbell = wrote: >=20 > Sakimura-san, Senior Bradley, and distinguished members of the OAUTH = WG, >=20 > I re-read draft-ietf-oauth-jwsreq (-06 anyway, it'd been a while) for = WGLC and, while I feel it's in pretty good shape, I did have a few = comments on the draft. Those are listed below in roughly the order I = came across things while reading the document.=20 >=20 > To my eye, "oauth-jar" looks a bit awkward. I'd suggest changing the = abbrev to something like=20 > "OAuth JAR". >=20 > =46rom the wording in Section 3 = , it = is unclear whether the Request Object can be a JWE only or if a JWS is = always used (with alg:none for unsigned) and is nested within a JWE when = encryption but not singing is needed. To my reading there is text that = suggest both cases. Which is it? I think some clarification is needed = around this. Section 5.1 = = doesn't help me as I'm unsure if "unsigned (plaintext) Request Object" = is an out-of-date usage of the old way to refer to the "none" JWS alg or = is intended to mean the straight up JSON of the request object = parameters.=20 >=20 > Also in Section 3 = , the = sentence 'The Authorization Request Object MAY alternatively be sent by = reference using the "request_uri" parameter.' reads a little awkward = because the other alternative isn't explicit discussed anywhere nearby. = Perhaps something like "The Authorization Request Object may be sent by = value as described in section 4.1 or by reference as described in = section 4.2."? >=20 > Also in Section 3 = , the = sentence "If a required parameter is not present in neither the query = parameter nor the Request Object, it forms a malformed request." made my = brain hurt. Maybe reword to something like, "If a required parameter is = missing from both the query parameters and the Request Object, the = request is considered malformed."? >=20 > Also in Section 3 = , '... = the Authorization Request Object SHOULD contain the Claims "iss" = (issuer) and "aud" (audience) as members ...', however, that will = produce a parameter name conflict with the "aud" parameter from OAuth = 2.0 Proof-of-Possession: Authorization Server to Client Key = Distribution. = = Seems like draft-ietf-oauth-pop-key-distribution will need to change its = parameter name (aud in JWT is pretty well established). And shouldn't = draft-ietf-oauth-jwsreq register some of the JWT's Registered Claim = Names (at least iss and = aud but maybe exp and others) as authorization request OAuth parameters = ? >=20 > Also in Section 3 = , I = personally feel like the "extension variables" detract from the example = being able to easily convey the concept. I would suggest using only = 'vanilla' OAuth parameters. Or, at the very least, removing the "claims" = stuff, which doubles the space used by the example and is a very OpenID = Connect specific thing. This applies to the examples throughout the = draft including those that have the encoded JWT Request Object.=20 >=20 > In Section 4 = , the = whole "The client constructs the authorization request URI by ..." = followed by the list of parameters is somewhat awkward to me - = especially with the "REQUIRED"s. Why list "state" here and none of the = others here? I think I know why (you expect state to vary on each = request but not others) but a lot of inferring needs to happen from the = reader. For the extension defined in this document, one uses either = request_uri or request (but not both, right? I'm not sure it's = explicitly stated anywhere) and whatever other parameters are needed in = the given situation. Maybe just some text towards that end rather than = the list format? >=20 > Also in Section 4 = , the = request_uri in the example is a lot like the URI that's used for = redirect_uri in a lot of places (the /cb path, I think, was intended to = short for callback). I mean, it *could* happen but the example is more = confusing than needs to be. It's also too long/wide for the page - add = some line breaks, which are for display purposes only. Perhaps move this = example to 4.2(.1) somewhere and match the value with the value shown = there?=20 >=20 > Also in Section 4 = , the = sentence that starts with 'When the "request" parameter is used...' = suggests that the text about JWT parameters superseding others is only = applicable to the pass by value method but it applies to both. Perhaps = change '"request" parameter' to 'Request Object'? >=20 > The second paragraph of Section 4.2.1 = = talks about "requested values for Claims" which is an OpenID Connect = thing that isn't really applicable to this draft. Can this paragraph be = dropped or made more general to be about any potentially sensitive or = PII data? >=20 > Also in Section 4.2.1 = , = is "... at a URL the Server can access... " - assume the "Authorization = Sever"?=20 >=20 > Isn't it a bit odd in Section 5.2 = to = talk about the "request_object_signing_alg" which is defined in OpenID = Connect Dynamic Client Registration = (which is = not referenced) and kinda mentioned in OpenID Connect Core = (informative = referenced)? I don't know that it belongs here? Or if it does, what = about request_object_encryption_alg and request_object_encryption_enc? I = suppose related to that is the question of if/how to use the = client_secret for HMAC and symmetric encryption algorithms and if that = needs to be discussed here? Indicating public key(s) too for that = matter. Seems like all the metadata/registration stuff should be in = here. Or it should all be out of scope. But just the = request_object_signing_alg seems odd to me. >=20 > Section 6 = says = that "... this document defines additional error values ..." but those = were previously defined in 3.1.2.6 of OpenID Connect Core = . Maybe = just change the wording to reflect the real state of things? =20 >=20 > Section 7 = says = that "The request_object_signing_alg OAuth Dynamic Client Registration = Metadata is pending registration by OpenID Connect Dynamic Registration = specification." But is that true? The registry = doesn't have it and Connect's Registration = = "makes no requests of IANA".=20 >=20 > As I'm sure reading this has been a ton of fun for the editors, I'm = sure you will be happy to please add me to the Acknowledgements Section = ;)=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7781E788-D0BD-461B-8A30-96571FF7D2BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The errata/update version of Connect=E2=80=99s registration = spec need to register a bunch of stuff in the Dyn-Reg IANA registry, but = I don=E2=80=99t think that=E2=80=99s been done yet.

 =E2=80=94 Justin

On Oct 27, 2015, at 3:41 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Sakimura-san, Senior Bradley, and distinguished members of = the OAUTH WG,

I = re-read draft-ietf-oauth-jwsreq (-06 anyway, it'd been a while) for WGLC = and, while I feel it's in pretty good shape, I did have a few comments = on the draft. Those are listed below in roughly the order I came across = things while reading the document.

To my eye, "oauth-jar" looks a bit awkward. = I'd suggest changing the abbrev to something like
"OAuth = JAR".

=46rom the wording in Section 3, it is unclear whether the = Request Object can be a JWE only or if a JWS is always used (with = alg:none for unsigned) and is nested within a JWE when encryption but = not singing is needed. To my reading there is text that suggest both = cases. Which is it? I think some clarification is needed around this. Section 5.1 doesn't help me as I'm = unsure if "unsigned (plaintext) Request Object" is an out-of-date usage = of the old way to refer to the "none" JWS alg or is intended to mean the = straight up JSON of the request object parameters.

Also in Section 3, the sentence 'The = Authorization Request Object MAY alternatively be sent by reference = using the "request_uri" parameter.' reads a little awkward because the = other alternative isn't explicit discussed anywhere nearby. Perhaps = something like "The Authorization Request Object may be sent by value as = described in section 4.1 or by reference as described in section = 4.2."?

Also in Section 3, the sentence "If a required = parameter is not present in neither the query parameter nor the Request = Object, it forms a malformed request." made my brain hurt. Maybe reword = to something like, "If a required parameter is missing from both the = query parameters and the Request Object, the request is considered = malformed."?

Also in Section 3, '... the Authorization = Request Object SHOULD contain the Claims "iss" (issuer) and "aud" = (audience) as members ...', however, that will produce a parameter name = conflict with the "aud" parameter from OAuth 2.0 Proof-of-Possession: = Authorization Server to Client Key Distribution. Seems like = draft-ietf-oauth-pop-key-distribution will need to change its parameter = name (aud in JWT is pretty well established). And shouldn't = draft-ietf-oauth-jwsreq register some of the JWT's Registered Claim Names (at least iss and aud but = maybe exp and others) as authorization request OAuth parameters?

Also in Section 3, I personally feel like the = "extension variables" detract from the example being able to easily = convey the concept. I would suggest using only 'vanilla' OAuth = parameters. Or, at the very least, removing the "claims" stuff, which = doubles the space used by the example and is a very OpenID Connect = specific thing. This applies to the examples throughout the draft = including those that have the encoded JWT Request Object.

In Section 4, the whole "The client = constructs the authorization request URI by ..." followed by the list of = parameters is somewhat awkward to me - especially with the "REQUIRED"s. = Why list "state" here and none of the others here? I think I know why = (you expect state to vary on each request but not others) but a lot of = inferring needs to happen from the reader.  For the extension = defined in this document, one uses either request_uri or request (but = not both, right? I'm not sure it's explicitly stated anywhere) and = whatever other parameters are needed in the given situation. Maybe just = some text towards that end rather than the list format?

Also in Section 4, the request_uri in the = example is a lot like the URI that's used for redirect_uri in a lot of = places (the /cb path, I think, was intended to short for callback). I = mean, it *could* happen but the example is more confusing than needs to = be. It's also too long/wide for the page - add some line breaks, which = are for display purposes only. Perhaps move this example to 4.2(.1) = somewhere and match the value with the value shown there?

Also in Section 4, the sentence that starts = with 'When the "request" parameter is used...' suggests that the text = about JWT parameters superseding others is only applicable to the pass = by value method but it applies to both. Perhaps change '"request" = parameter' to 'Request Object'?

The second paragraph of Section 4.2.1 talks about = "requested values for Claims" which is an OpenID Connect thing that = isn't really applicable to this draft. Can this paragraph be dropped or = made more general to be about any potentially sensitive or PII data?

Also in Section 4.2.1, is "... at a URL the = Server can access... " - assume the "Authorization Sever"?

Isn't it a bit odd in Section 5.2 to talk about the = "request_object_signing_alg" which is defined in OpenID Connect Dynamic Client = Registration (which is not referenced) and kinda mentioned in OpenID Connect Core (informative = referenced)? I don't know that it belongs here? Or if it does, what = about request_object_encryption_alg and request_object_encryption_enc? I = suppose related to that is the question of if/how to use the = client_secret for HMAC and symmetric encryption algorithms and if that = needs to be discussed here? Indicating public key(s) too for that = matter. Seems like all the metadata/registration stuff should be in = here. Or it should all be out of scope. But just the = request_object_signing_alg seems odd to me.

Section 6 says that "... this document = defines additional error values ..." but those were previously defined = in 3.1.2.6 of OpenID Connect Core. Maybe = just change the wording to reflect the real state of things?  

Section 7 says that "The = request_object_signing_alg OAuth Dynamic Client Registration Metadata is = pending registration by OpenID Connect Dynamic Registration = specification." But is that true? The registry = doesn't have it and Connect's Registration "makes no = requests of IANA".

As = I'm sure reading this has been a ton of fun for the editors, I'm sure = you will be happy to please add me to the Acknowledgements Section ;)




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

= --Apple-Mail=_7781E788-D0BD-461B-8A30-96571FF7D2BD-- From nobody Wed Oct 28 16:07:48 2015 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 A77131B5EBF for ; Wed, 28 Oct 2015 16:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 ayBJ_D5Zr5vS for ; Wed, 28 Oct 2015 16:07:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216361B5EBC for ; Wed, 28 Oct 2015 16:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lLR/9Hg5KyijyXVW2d2p/xNhTmAdGu69SwMXA9ozTVQ=; b=nqsGyaSp3jH2u1dofrh4b4kLd8dnZr2Vn3ftXCoL6Ct/73XhyXFdJWINsfNKIc1Y8vxWbAHl5tRTP+BW/lkpYZulG4R5BtSyQVuTJyibw4UCFDZqiG3gouls1tBAsGv7g1kwzA4r48YENRtuC6ESMCj0qI8CCgSMvCwfvjlp7Kk= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.306.13; Wed, 28 Oct 2015 23:07:34 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0306.003; Wed, 28 Oct 2015 23:07:34 +0000 From: Mike Jones To: Justin Richer , Brian Campbell Thread-Topic: [OAUTH-WG] some WGLC comments on draft-ietf-oauth-jwsreq-06 Thread-Index: AQHREQjG0uX/1xc0fEa1sZeB4X3UpZ6BeoKAgAAM+RA= Date: Wed, 28 Oct 2015 23:07:33 +0000 Message-ID: References: <152AD4F1-84EF-47DC-9A41-C7413DE5464B@mit.edu> In-Reply-To: <152AD4F1-84EF-47DC-9A41-C7413DE5464B@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [64.71.18.60] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:lfP7nRsaEMVEPNCfw21RXzBVhpo2jvevzuB0IdG3i/E2dbFf4eXS8HrvbpM407i/IqAUdB7FJvaT2MMFwtb3qLsetFfK2Ib9TZTyY6Qc2lQtn9T87ZbgtA2SlxVBVfRWwd5y6cxuy9bkS7NSfZ6eAw==; 24:ZLNT4I/LN7Z5TgsL939W9HhrCxd19mKb8jM7hGxJyH/S+8kJV/P4wZJAkf4DBbmZQHQQcUwg61I8rxxbQvHhS+Oe4c/xM5hOjyy9Kw0nyUE=; 20:/tzF1+6ePQESFXD13kt7HYIPGGjA8zKHLUkr2vIVeTCKQmUYufDoRTxSEqvAa7Jm2Wt/2cof5fn4MAuzwOqrzw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(102215026)(61426024)(61427024); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0743E8D0A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(52314003)(24454002)(189002)(16236675004)(54356999)(76176999)(15395725005)(189998001)(74316001)(33656002)(19617315012)(106356001)(76576001)(66066001)(230783001)(92566002)(5001770100001)(81156007)(5005710100001)(10290500002)(10400500002)(101416001)(8990500004)(102836002)(5003600100002)(97736004)(50986999)(86612001)(40100003)(87936001)(5008740100001)(122556002)(2171001)(10090500001)(105586002)(19609705001)(86362001)(2900100001)(19580395003)(2950100001)(19580405001)(5001960100002)(99286002)(5004730100002)(15975445007)(5007970100001)(106116001)(19300405004)(77096005)(5002640100001)(11100500001)(19625215002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4422A5C4671F0DB1F312919F5210BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2015 23:07:33.9135 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] some WGLC comments on draft-ietf-oauth-jwsreq-06 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, 28 Oct 2015 23:07:46 -0000 --_000_BY2PR03MB4422A5C4671F0DB1F312919F5210BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyB3b3JraW5nIGRyYWZ0IGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0 LXJlZ2lzdHJhdGlvbi0xXzAtMjkuaHRtbCBjb250YWluaW5nIHRoZSBPcGVuSUQgQ29ubmVjdCBE eW5hbWljIFJlZ2lzdHJhdGlvbiBlcnJhdGEgMiBlZGl0cyB0byBkYXRlIGNvbnRhaW5zIHRoZSBy ZWdpc3RyYXRpb24gcmVxdWVzdHMgdGhhdCB5b3XigJlyZSByZWZlcnJpbmcgdG8uICBTZWUgaHR0 cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtcmVnaXN0cmF0aW9uLTFfMC0yOS5o dG1sI0R5blJlZ0NvbnRlbnRzIGFuZCBodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29u bmVjdC1yZWdpc3RyYXRpb24tMV8wLTI5Lmh0bWwjVEVBTUNvbnRlbnRzLg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEp1c3RpbiBSaWNoZXINClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyOCwgMjAxNSAzOjE2 IFBNDQpUbzogQnJpYW4gQ2FtcGJlbGwNCkNjOiA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW09BVVRILVdHXSBzb21lIFdHTEMgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1vYXV0aC1qd3Ny ZXEtMDYNCg0KVGhlIGVycmF0YS91cGRhdGUgdmVyc2lvbiBvZiBDb25uZWN04oCZcyByZWdpc3Ry YXRpb24gc3BlYyBuZWVkIHRvIHJlZ2lzdGVyIGEgYnVuY2ggb2Ygc3R1ZmYgaW4gdGhlIER5bi1S ZWcgSUFOQSByZWdpc3RyeSwgYnV0IEkgZG9u4oCZdCB0aGluayB0aGF04oCZcyBiZWVuIGRvbmUg eWV0Lg0KDQog4oCUIEp1c3Rpbg0KDQpPbiBPY3QgMjcsIDIwMTUsIGF0IDM6NDEgUE0sIEJyaWFu IENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBp bmdpZGVudGl0eS5jb20+PiB3cm90ZToNCg0KU2FraW11cmEtc2FuLCBTZW5pb3IgQnJhZGxleSwg YW5kIGRpc3Rpbmd1aXNoZWQgbWVtYmVycyBvZiB0aGUgT0FVVEggV0csDQpJIHJlLXJlYWQgZHJh ZnQtaWV0Zi1vYXV0aC1qd3NyZXEgKC0wNiBhbnl3YXksIGl0J2QgYmVlbiBhIHdoaWxlKSBmb3Ig V0dMQyBhbmQsIHdoaWxlIEkgZmVlbCBpdCdzIGluIHByZXR0eSBnb29kIHNoYXBlLCBJIGRpZCBo YXZlIGEgZmV3IGNvbW1lbnRzIG9uIHRoZSBkcmFmdC4gVGhvc2UgYXJlIGxpc3RlZCBiZWxvdyBp biByb3VnaGx5IHRoZSBvcmRlciBJIGNhbWUgYWNyb3NzIHRoaW5ncyB3aGlsZSByZWFkaW5nIHRo ZSBkb2N1bWVudC4NCg0KVG8gbXkgZXllLCAib2F1dGgtamFyIiBsb29rcyBhIGJpdCBhd2t3YXJk LiBJJ2Qgc3VnZ2VzdCBjaGFuZ2luZyB0aGUgYWJicmV2IHRvIHNvbWV0aGluZyBsaWtlDQoiT0F1 dGggSkFSIi4NCkZyb20gdGhlIHdvcmRpbmcgaW4gU2VjdGlvbiAzPGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0wNiNzZWN0aW9uLTM+LCBpdCBpcyB1 bmNsZWFyIHdoZXRoZXIgdGhlIFJlcXVlc3QgT2JqZWN0IGNhbiBiZSBhIEpXRSBvbmx5IG9yIGlm IGEgSldTIGlzIGFsd2F5cyB1c2VkICh3aXRoIGFsZzpub25lIGZvciB1bnNpZ25lZCkgYW5kIGlz IG5lc3RlZCB3aXRoaW4gYSBKV0Ugd2hlbiBlbmNyeXB0aW9uIGJ1dCBub3Qgc2luZ2luZyBpcyBu ZWVkZWQuIFRvIG15IHJlYWRpbmcgdGhlcmUgaXMgdGV4dCB0aGF0IHN1Z2dlc3QgYm90aCBjYXNl cy4gV2hpY2ggaXMgaXQ/IEkgdGhpbmsgc29tZSBjbGFyaWZpY2F0aW9uIGlzIG5lZWRlZCBhcm91 bmQgdGhpcy4gU2VjdGlvbiA1LjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtb2F1dGgtandzcmVxLTA2I3NlY3Rpb24tNS4xPiBkb2Vzbid0IGhlbHAgbWUgYXMgSSdtIHVu c3VyZSBpZiAidW5zaWduZWQgKHBsYWludGV4dCkgUmVxdWVzdCBPYmplY3QiIGlzIGFuIG91dC1v Zi1kYXRlIHVzYWdlIG9mIHRoZSBvbGQgd2F5IHRvIHJlZmVyIHRvIHRoZSAibm9uZSIgSldTIGFs ZyBvciBpcyBpbnRlbmRlZCB0byBtZWFuIHRoZSBzdHJhaWdodCB1cCBKU09OIG9mIHRoZSByZXF1 ZXN0IG9iamVjdCBwYXJhbWV0ZXJzLg0KQWxzbyBpbiBTZWN0aW9uIDM8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTA2I3NlY3Rpb24tMz4sIHRoZSBz ZW50ZW5jZSAnVGhlIEF1dGhvcml6YXRpb24gUmVxdWVzdCBPYmplY3QgTUFZIGFsdGVybmF0aXZl bHkgYmUgc2VudCBieSByZWZlcmVuY2UgdXNpbmcgdGhlICJyZXF1ZXN0X3VyaSIgcGFyYW1ldGVy LicgcmVhZHMgYSBsaXR0bGUgYXdrd2FyZCBiZWNhdXNlIHRoZSBvdGhlciBhbHRlcm5hdGl2ZSBp c24ndCBleHBsaWNpdCBkaXNjdXNzZWQgYW55d2hlcmUgbmVhcmJ5LiBQZXJoYXBzIHNvbWV0aGlu ZyBsaWtlICJUaGUgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IE9iamVjdCBtYXkgYmUgc2VudCBieSB2 YWx1ZSBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA0LjEgb3IgYnkgcmVmZXJlbmNlIGFzIGRlc2Ny aWJlZCBpbiBzZWN0aW9uIDQuMi4iPw0KDQpBbHNvIGluIFNlY3Rpb24gMzxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMDYjc2VjdGlvbi0zPiwgdGhl IHNlbnRlbmNlICJJZiBhIHJlcXVpcmVkIHBhcmFtZXRlciBpcyBub3QgcHJlc2VudCBpbiBuZWl0 aGVyIHRoZSBxdWVyeSBwYXJhbWV0ZXIgbm9yIHRoZSBSZXF1ZXN0IE9iamVjdCwgaXQgZm9ybXMg YSBtYWxmb3JtZWQgcmVxdWVzdC4iIG1hZGUgbXkgYnJhaW4gaHVydC4gTWF5YmUgcmV3b3JkIHRv IHNvbWV0aGluZyBsaWtlLCAiSWYgYSByZXF1aXJlZCBwYXJhbWV0ZXIgaXMgbWlzc2luZyBmcm9t IGJvdGggdGhlIHF1ZXJ5IHBhcmFtZXRlcnMgYW5kIHRoZSBSZXF1ZXN0IE9iamVjdCwgdGhlIHJl cXVlc3QgaXMgY29uc2lkZXJlZCBtYWxmb3JtZWQuIj8NCg0KQWxzbyBpbiBTZWN0aW9uIDM8aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTA2I3NlY3Rp b24tMz4sICcuLi4gdGhlIEF1dGhvcml6YXRpb24gUmVxdWVzdCBPYmplY3QgU0hPVUxEIGNvbnRh aW4gdGhlIENsYWltcyAiaXNzIiAoaXNzdWVyKSBhbmQgImF1ZCIgKGF1ZGllbmNlKSBhcyBtZW1i ZXJzIC4uLicsIGhvd2V2ZXIsIHRoYXQgd2lsbCBwcm9kdWNlIGEgcGFyYW1ldGVyIG5hbWUgY29u ZmxpY3Qgd2l0aCB0aGUgImF1ZCIgcGFyYW1ldGVyIGZyb20gT0F1dGggMi4wIFByb29mLW9mLVBv c3Nlc3Npb246IEF1dGhvcml6YXRpb24gU2VydmVyIHRvIENsaWVudCBLZXkgRGlzdHJpYnV0aW9u LjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1wb3Ata2V5LWRp c3RyaWJ1dGlvbi0wMj4gU2VlbXMgbGlrZSBkcmFmdC1pZXRmLW9hdXRoLXBvcC1rZXktZGlzdHJp YnV0aW9uIHdpbGwgbmVlZCB0byBjaGFuZ2UgaXRzIHBhcmFtZXRlciBuYW1lIChhdWQgaW4gSldU IGlzIHByZXR0eSB3ZWxsIGVzdGFibGlzaGVkKS4gQW5kIHNob3VsZG4ndCBkcmFmdC1pZXRmLW9h dXRoLWp3c3JlcSByZWdpc3RlciBzb21lIG9mIHRoZSBKV1QncyBSZWdpc3RlcmVkIENsYWltIE5h bWVzPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi00LjE+IChhdCBs ZWFzdCBpc3MgYW5kIGF1ZCBidXQgbWF5YmUgZXhwIGFuZCBvdGhlcnMpIGFzIGF1dGhvcml6YXRp b24gcmVxdWVzdCBPQXV0aCBwYXJhbWV0ZXJzPGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1l bnRzL29hdXRoLXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54aHRtbCNwYXJhbWV0ZXJzPj8N Cg0KQWxzbyBpbiBTZWN0aW9uIDM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtb2F1dGgtandzcmVxLTA2I3NlY3Rpb24tMz4sIEkgcGVyc29uYWxseSBmZWVsIGxpa2UgdGhl ICJleHRlbnNpb24gdmFyaWFibGVzIiBkZXRyYWN0IGZyb20gdGhlIGV4YW1wbGUgYmVpbmcgYWJs ZSB0byBlYXNpbHkgY29udmV5IHRoZSBjb25jZXB0LiBJIHdvdWxkIHN1Z2dlc3QgdXNpbmcgb25s eSAndmFuaWxsYScgT0F1dGggcGFyYW1ldGVycy4gT3IsIGF0IHRoZSB2ZXJ5IGxlYXN0LCByZW1v dmluZyB0aGUgImNsYWltcyIgc3R1ZmYsIHdoaWNoIGRvdWJsZXMgdGhlIHNwYWNlIHVzZWQgYnkg dGhlIGV4YW1wbGUgYW5kIGlzIGEgdmVyeSBPcGVuSUQgQ29ubmVjdCBzcGVjaWZpYyB0aGluZy4g VGhpcyBhcHBsaWVzIHRvIHRoZSBleGFtcGxlcyB0aHJvdWdob3V0IHRoZSBkcmFmdCBpbmNsdWRp bmcgdGhvc2UgdGhhdCBoYXZlIHRoZSBlbmNvZGVkIEpXVCBSZXF1ZXN0IE9iamVjdC4NCkluIFNl Y3Rpb24gNDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3Ny ZXEtMDYjc2VjdGlvbi00PiwgdGhlIHdob2xlICJUaGUgY2xpZW50IGNvbnN0cnVjdHMgdGhlIGF1 dGhvcml6YXRpb24gcmVxdWVzdCBVUkkgYnkgLi4uIiBmb2xsb3dlZCBieSB0aGUgbGlzdCBvZiBw YXJhbWV0ZXJzIGlzIHNvbWV3aGF0IGF3a3dhcmQgdG8gbWUgLSBlc3BlY2lhbGx5IHdpdGggdGhl ICJSRVFVSVJFRCJzLiBXaHkgbGlzdCAic3RhdGUiIGhlcmUgYW5kIG5vbmUgb2YgdGhlIG90aGVy cyBoZXJlPyBJIHRoaW5rIEkga25vdyB3aHkgKHlvdSBleHBlY3Qgc3RhdGUgdG8gdmFyeSBvbiBl YWNoIHJlcXVlc3QgYnV0IG5vdCBvdGhlcnMpIGJ1dCBhIGxvdCBvZiBpbmZlcnJpbmcgbmVlZHMg dG8gaGFwcGVuIGZyb20gdGhlIHJlYWRlci4gIEZvciB0aGUgZXh0ZW5zaW9uIGRlZmluZWQgaW4g dGhpcyBkb2N1bWVudCwgb25lIHVzZXMgZWl0aGVyIHJlcXVlc3RfdXJpIG9yIHJlcXVlc3QgKGJ1 dCBub3QgYm90aCwgcmlnaHQ/IEknbSBub3Qgc3VyZSBpdCdzIGV4cGxpY2l0bHkgc3RhdGVkIGFu eXdoZXJlKSBhbmQgd2hhdGV2ZXIgb3RoZXIgcGFyYW1ldGVycyBhcmUgbmVlZGVkIGluIHRoZSBn aXZlbiBzaXR1YXRpb24uIE1heWJlIGp1c3Qgc29tZSB0ZXh0IHRvd2FyZHMgdGhhdCBlbmQgcmF0 aGVyIHRoYW4gdGhlIGxpc3QgZm9ybWF0Pw0KQWxzbyBpbiBTZWN0aW9uIDQ8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTA2I3NlY3Rpb24tND4sIHRo ZSByZXF1ZXN0X3VyaSBpbiB0aGUgZXhhbXBsZSBpcyBhIGxvdCBsaWtlIHRoZSBVUkkgdGhhdCdz IHVzZWQgZm9yIHJlZGlyZWN0X3VyaSBpbiBhIGxvdCBvZiBwbGFjZXMgKHRoZSAvY2IgcGF0aCwg SSB0aGluaywgd2FzIGludGVuZGVkIHRvIHNob3J0IGZvciBjYWxsYmFjaykuIEkgbWVhbiwgaXQg KmNvdWxkKiBoYXBwZW4gYnV0IHRoZSBleGFtcGxlIGlzIG1vcmUgY29uZnVzaW5nIHRoYW4gbmVl ZHMgdG8gYmUuIEl0J3MgYWxzbyB0b28gbG9uZy93aWRlIGZvciB0aGUgcGFnZSAtIGFkZCBzb21l IGxpbmUgYnJlYWtzLCB3aGljaCBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seS4gUGVyaGFw cyBtb3ZlIHRoaXMgZXhhbXBsZSB0byA0LjIoLjEpIHNvbWV3aGVyZSBhbmQgbWF0Y2ggdGhlIHZh bHVlIHdpdGggdGhlIHZhbHVlIHNob3duIHRoZXJlPw0KDQpBbHNvIGluIFNlY3Rpb24gNDxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMDYjc2VjdGlv bi00PiwgdGhlIHNlbnRlbmNlIHRoYXQgc3RhcnRzIHdpdGggJ1doZW4gdGhlICJyZXF1ZXN0IiBw YXJhbWV0ZXIgaXMgdXNlZC4uLicgc3VnZ2VzdHMgdGhhdCB0aGUgdGV4dCBhYm91dCBKV1QgcGFy YW1ldGVycyBzdXBlcnNlZGluZyBvdGhlcnMgaXMgb25seSBhcHBsaWNhYmxlIHRvIHRoZSBwYXNz IGJ5IHZhbHVlIG1ldGhvZCBidXQgaXQgYXBwbGllcyB0byBib3RoLiBQZXJoYXBzIGNoYW5nZSAn InJlcXVlc3QiIHBhcmFtZXRlcicgdG8gJ1JlcXVlc3QgT2JqZWN0Jz8NClRoZSBzZWNvbmQgcGFy YWdyYXBoIG9mIFNlY3Rpb24gNC4yLjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtb2F1dGgtandzcmVxLTA2I3NlY3Rpb24tNC4yLjE+IHRhbGtzIGFib3V0ICJyZXF1ZXN0 ZWQgdmFsdWVzIGZvciBDbGFpbXMiIHdoaWNoIGlzIGFuIE9wZW5JRCBDb25uZWN0IHRoaW5nIHRo YXQgaXNuJ3QgcmVhbGx5IGFwcGxpY2FibGUgdG8gdGhpcyBkcmFmdC4gQ2FuIHRoaXMgcGFyYWdy YXBoIGJlIGRyb3BwZWQgb3IgbWFkZSBtb3JlIGdlbmVyYWwgdG8gYmUgYWJvdXQgYW55IHBvdGVu dGlhbGx5IHNlbnNpdGl2ZSBvciBQSUkgZGF0YT8NCkFsc28gaW4gU2VjdGlvbiA0LjIuMTxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMDYjc2VjdGlv bi00LjIuMT4sIGlzICIuLi4gYXQgYSBVUkwgdGhlIFNlcnZlciBjYW4gYWNjZXNzLi4uICIgLSBh c3N1bWUgdGhlICJBdXRob3JpemF0aW9uIFNldmVyIj8NCklzbid0IGl0IGEgYml0IG9kZCBpbiBT ZWN0aW9uIDUuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1q d3NyZXEtMDYjc2VjdGlvbi01LjI+IHRvIHRhbGsgYWJvdXQgdGhlICJyZXF1ZXN0X29iamVjdF9z aWduaW5nX2FsZyIgd2hpY2ggaXMgZGVmaW5lZCBpbiBPcGVuSUQgQ29ubmVjdCBEeW5hbWljIENs aWVudCBSZWdpc3RyYXRpb248aHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3Qt cmVnaXN0cmF0aW9uLTFfMC5odG1sPiAod2hpY2ggaXMgbm90IHJlZmVyZW5jZWQpIGFuZCBraW5k YSBtZW50aW9uZWQgaW4gT3BlbklEIENvbm5lY3QgQ29yZTxodHRwOi8vb3BlbmlkLm5ldC9zcGVj cy9vcGVuaWQtY29ubmVjdC1jb3JlLTFfMC5odG1sPiAoaW5mb3JtYXRpdmUgcmVmZXJlbmNlZCk/ IEkgZG9uJ3Qga25vdyB0aGF0IGl0IGJlbG9uZ3MgaGVyZT8gT3IgaWYgaXQgZG9lcywgd2hhdCBh Ym91dCByZXF1ZXN0X29iamVjdF9lbmNyeXB0aW9uX2FsZyBhbmQgcmVxdWVzdF9vYmplY3RfZW5j cnlwdGlvbl9lbmM/IEkgc3VwcG9zZSByZWxhdGVkIHRvIHRoYXQgaXMgdGhlIHF1ZXN0aW9uIG9m IGlmL2hvdyB0byB1c2UgdGhlIGNsaWVudF9zZWNyZXQgZm9yIEhNQUMgYW5kIHN5bW1ldHJpYyBl bmNyeXB0aW9uIGFsZ29yaXRobXMgYW5kIGlmIHRoYXQgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkIGhl cmU/IEluZGljYXRpbmcgcHVibGljIGtleShzKSB0b28gZm9yIHRoYXQgbWF0dGVyLiBTZWVtcyBs aWtlIGFsbCB0aGUgbWV0YWRhdGEvcmVnaXN0cmF0aW9uIHN0dWZmIHNob3VsZCBiZSBpbiBoZXJl LiBPciBpdCBzaG91bGQgYWxsIGJlIG91dCBvZiBzY29wZS4gQnV0IGp1c3QgdGhlIHJlcXVlc3Rf b2JqZWN0X3NpZ25pbmdfYWxnIHNlZW1zIG9kZCB0byBtZS4NClNlY3Rpb24gNjxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMDYjc2VjdGlvbi02PiBz YXlzIHRoYXQgIi4uLiB0aGlzIGRvY3VtZW50IGRlZmluZXMgYWRkaXRpb25hbCBlcnJvciB2YWx1 ZXMgLi4uIiBidXQgdGhvc2Ugd2VyZSBwcmV2aW91c2x5IGRlZmluZWQgaW4gMy4xLjIuNiBvZiBP cGVuSUQgQ29ubmVjdCBDb3JlPGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0 LWNvcmUtMV8wLmh0bWwjQXV0aEVycm9yPi4gTWF5YmUganVzdCBjaGFuZ2UgdGhlIHdvcmRpbmcg dG8gcmVmbGVjdCB0aGUgcmVhbCBzdGF0ZSBvZiB0aGluZ3M/DQoNClNlY3Rpb24gNzxodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMDYjc2VjdGlvbi03 PiBzYXlzIHRoYXQgIlRoZSByZXF1ZXN0X29iamVjdF9zaWduaW5nX2FsZyBPQXV0aCBEeW5hbWlj IENsaWVudCBSZWdpc3RyYXRpb24gTWV0YWRhdGEgaXMgcGVuZGluZyByZWdpc3RyYXRpb24gYnkg T3BlbklEIENvbm5lY3QgRHluYW1pYyBSZWdpc3RyYXRpb24gc3BlY2lmaWNhdGlvbi4iIEJ1dCBp cyB0aGF0IHRydWU/IFRoZSByZWdpc3RyeTxodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50 cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueGh0bWwjY2xpZW50LW1ldGFkYXRh PiBkb2Vzbid0IGhhdmUgaXQgYW5kIENvbm5lY3QncyBSZWdpc3RyYXRpb248aHR0cDovL29wZW5p ZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtcmVnaXN0cmF0aW9uLTFfMC5odG1sI0lBTkE+ICJt YWtlcyBubyByZXF1ZXN0cyBvZiBJQU5BIi4NCkFzIEknbSBzdXJlIHJlYWRpbmcgdGhpcyBoYXMg YmVlbiBhIHRvbiBvZiBmdW4gZm9yIHRoZSBlZGl0b3JzLCBJJ20gc3VyZSB5b3Ugd2lsbCBiZSBo YXBweSB0byBwbGVhc2UgYWRkIG1lIHRvIHRoZSBBY2tub3dsZWRnZW1lbnRzIFNlY3Rpb248aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTA2I3NlY3Rp b24tOT4gOykNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_BY2PR03MB4422A5C4671F0DB1F312919F5210BY2PR03MB442namprd_ 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 LXNlcmlmIjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+VGhpcyB3b3JraW5nIGRyYWZ0DQo8YSBocmVmPSJodHRw Oi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLTI5Lmh0 bWwiPmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LXJlZ2lzdHJhdGlvbi0x XzAtMjkuaHRtbDwvYT4gY29udGFpbmluZyB0aGUgT3BlbklEIENvbm5lY3QgRHluYW1pYyBSZWdp c3RyYXRpb24gZXJyYXRhIDIgZWRpdHMgdG8gZGF0ZSBjb250YWlucyB0aGUgcmVnaXN0cmF0aW9u IHJlcXVlc3RzIHRoYXQgeW914oCZcmUNCiByZWZlcnJpbmcgdG8uJm5ic3A7IFNlZSA8YSBocmVm PSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1yZWdpc3RyYXRpb24tMV8w LTI5Lmh0bWwjRHluUmVnQ29udGVudHMiPg0KaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3Blbmlk LWNvbm5lY3QtcmVnaXN0cmF0aW9uLTFfMC0yOS5odG1sI0R5blJlZ0NvbnRlbnRzPC9hPiBhbmQN CjxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LXJlZ2lzdHJh dGlvbi0xXzAtMjkuaHRtbCNURUFNQ29udGVudHMiPg0KaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mv b3BlbmlkLWNvbm5lY3QtcmVnaXN0cmF0aW9uLTFfMC0yOS5odG1sI1RFQU1Db250ZW50czwvYT4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAy MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRo IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVz dGluIFJpY2hlcjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9jdG9iZXIgMjgsIDIwMTUg MzoxNiBQTTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5DYzo8L2I+ICZs dDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10g c29tZSBXR0xDIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTA2PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGVycmF0YS91cGRhdGUg dmVyc2lvbiBvZiBDb25uZWN04oCZcyByZWdpc3RyYXRpb24gc3BlYyBuZWVkIHRvIHJlZ2lzdGVy IGEgYnVuY2ggb2Ygc3R1ZmYgaW4gdGhlIER5bi1SZWcgSUFOQSByZWdpc3RyeSwgYnV0IEkgZG9u 4oCZdCB0aGluayB0aGF04oCZcyBiZWVuIGRvbmUgeWV0LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gT2N0IDI3LCAyMDE1LCBh dCAzOjQxIFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlNha2ltdXJhLXNhbiwgU2VuaW9yIEJy YWRsZXksIGFuZCBkaXN0aW5ndWlzaGVkIG1lbWJlcnMgb2YgdGhlIE9BVVRIIFdHLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSByZS1yZWFkIGRy YWZ0LWlldGYtb2F1dGgtandzcmVxICgtMDYgYW55d2F5LCBpdCdkIGJlZW4gYSB3aGlsZSkgZm9y IFdHTEMgYW5kLCB3aGlsZSBJIGZlZWwgaXQncyBpbiBwcmV0dHkgZ29vZCBzaGFwZSwgSSBkaWQg aGF2ZSBhIGZldyBjb21tZW50cyBvbiB0aGUgZHJhZnQuIFRob3NlIGFyZSBsaXN0ZWQgYmVsb3cg aW4gcm91Z2hseSB0aGUgb3JkZXIgSSBjYW1lIGFjcm9zcyB0aGluZ3Mgd2hpbGUgcmVhZGluZw0K IHRoZSBkb2N1bWVudC4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NClRvIG15IGV5ZSwg JnF1b3Q7b2F1dGgtamFyJnF1b3Q7IGxvb2tzIGEgYml0IGF3a3dhcmQuIEknZCBzdWdnZXN0IGNo YW5naW5nIHRoZSBhYmJyZXYgdG8gc29tZXRoaW5nIGxpa2UNCjxicj4NCiZxdW90O09BdXRoIEpB UiZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Gcm9tIHRoZSB3b3JkaW5nIGluIDxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0wNiNzZWN0 aW9uLTMiIHRhcmdldD0iX2JsYW5rIj4NClNlY3Rpb24gMzwvYT4sIGl0IGlzIHVuY2xlYXIgd2hl dGhlciB0aGUgUmVxdWVzdCBPYmplY3QgY2FuIGJlIGEgSldFIG9ubHkgb3IgaWYgYSBKV1MgaXMg YWx3YXlzIHVzZWQgKHdpdGggYWxnOm5vbmUgZm9yIHVuc2lnbmVkKSBhbmQgaXMgbmVzdGVkIHdp dGhpbiBhIEpXRSB3aGVuIGVuY3J5cHRpb24gYnV0IG5vdCBzaW5naW5nIGlzIG5lZWRlZC4gVG8g bXkgcmVhZGluZyB0aGVyZSBpcyB0ZXh0IHRoYXQgc3VnZ2VzdCBib3RoIGNhc2VzLiBXaGljaA0K IGlzIGl0PyBJIHRoaW5rIHNvbWUgY2xhcmlmaWNhdGlvbiBpcyBuZWVkZWQgYXJvdW5kIHRoaXMu IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3 c3JlcS0wNiNzZWN0aW9uLTUuMSIgdGFyZ2V0PSJfYmxhbmsiPg0KU2VjdGlvbiA1LjE8L2E+IGRv ZXNuJ3QgaGVscCBtZSBhcyBJJ20gdW5zdXJlIGlmICZxdW90O3Vuc2lnbmVkIChwbGFpbnRleHQp IFJlcXVlc3QgT2JqZWN0JnF1b3Q7IGlzIGFuIG91dC1vZi1kYXRlIHVzYWdlIG9mIHRoZSBvbGQg d2F5IHRvIHJlZmVyIHRvIHRoZSAmcXVvdDtub25lJnF1b3Q7IEpXUyBhbGcgb3IgaXMgaW50ZW5k ZWQgdG8gbWVhbiB0aGUgc3RyYWlnaHQgdXAgSlNPTiBvZiB0aGUgcmVxdWVzdCBvYmplY3QgcGFy YW1ldGVycy4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bHNvIGluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9h dXRoLWp3c3JlcS0wNiNzZWN0aW9uLTMiIHRhcmdldD0iX2JsYW5rIj4NClNlY3Rpb24gMzwvYT4s IHRoZSBzZW50ZW5jZSAnVGhlIEF1dGhvcml6YXRpb24gUmVxdWVzdCBPYmplY3QgTUFZIGFsdGVy bmF0aXZlbHkgYmUgc2VudCBieSByZWZlcmVuY2UgdXNpbmcgdGhlICZxdW90O3JlcXVlc3RfdXJp JnF1b3Q7IHBhcmFtZXRlci4nIHJlYWRzIGEgbGl0dGxlIGF3a3dhcmQgYmVjYXVzZSB0aGUgb3Ro ZXIgYWx0ZXJuYXRpdmUgaXNuJ3QgZXhwbGljaXQgZGlzY3Vzc2VkIGFueXdoZXJlIG5lYXJieS4g UGVyaGFwcyBzb21ldGhpbmcgbGlrZSAmcXVvdDtUaGUNCiBBdXRob3JpemF0aW9uIFJlcXVlc3Qg T2JqZWN0IG1heSBiZSBzZW50IGJ5IHZhbHVlIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDQuMSBv ciBieSByZWZlcmVuY2UgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gNC4yLiZxdW90Oz88YnI+DQo8 YnI+DQpBbHNvIGluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW9hdXRoLWp3c3JlcS0wNiNzZWN0aW9uLTMiIHRhcmdldD0iX2JsYW5rIj4NClNlY3Rpb24g MzwvYT4sIHRoZSBzZW50ZW5jZSAmcXVvdDtJZiBhIHJlcXVpcmVkIHBhcmFtZXRlciBpcyBub3Qg cHJlc2VudCBpbiBuZWl0aGVyIHRoZSBxdWVyeSBwYXJhbWV0ZXIgbm9yIHRoZSBSZXF1ZXN0IE9i amVjdCwgaXQgZm9ybXMgYSBtYWxmb3JtZWQgcmVxdWVzdC4mcXVvdDsgbWFkZSBteSBicmFpbiBo dXJ0LiBNYXliZSByZXdvcmQgdG8gc29tZXRoaW5nIGxpa2UsICZxdW90O0lmIGEgcmVxdWlyZWQg cGFyYW1ldGVyIGlzIG1pc3NpbmcgZnJvbSBib3RoIHRoZSBxdWVyeQ0KIHBhcmFtZXRlcnMgYW5k IHRoZSBSZXF1ZXN0IE9iamVjdCwgdGhlIHJlcXVlc3QgaXMgY29uc2lkZXJlZCBtYWxmb3JtZWQu JnF1b3Q7PzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkFsc28gaW4gPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTA2I3NlY3Rp b24tMyIgdGFyZ2V0PSJfYmxhbmsiPg0KU2VjdGlvbiAzPC9hPiwgJy4uLiB0aGUgQXV0aG9yaXph dGlvbiBSZXF1ZXN0IE9iamVjdCBTSE9VTEQgY29udGFpbiB0aGUgQ2xhaW1zICZxdW90O2lzcyZx dW90OyAoaXNzdWVyKSBhbmQgJnF1b3Q7YXVkJnF1b3Q7IChhdWRpZW5jZSkgYXMgbWVtYmVycyAu Li4nLCBob3dldmVyLCB0aGF0IHdpbGwgcHJvZHVjZSBhIHBhcmFtZXRlciBuYW1lIGNvbmZsaWN0 IHdpdGggdGhlICZxdW90O2F1ZCZxdW90OyBwYXJhbWV0ZXIgZnJvbQ0KPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcG9wLWtleS1kaXN0cmlidXRp b24tMDIiIHRhcmdldD0iX2JsYW5rIj4NCk9BdXRoIDIuMCBQcm9vZi1vZi1Qb3NzZXNzaW9uOiBB dXRob3JpemF0aW9uIFNlcnZlciB0byBDbGllbnQgS2V5IERpc3RyaWJ1dGlvbi48L2E+IFNlZW1z IGxpa2UgZHJhZnQtaWV0Zi1vYXV0aC1wb3Ata2V5LWRpc3RyaWJ1dGlvbiB3aWxsIG5lZWQgdG8g Y2hhbmdlIGl0cyBwYXJhbWV0ZXIgbmFtZSAoYXVkIGluIEpXVCBpcyBwcmV0dHkgd2VsbCBlc3Rh Ymxpc2hlZCkuIEFuZCBzaG91bGRuJ3QgZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEgcmVnaXN0ZXIN CiBzb21lIG9mIHRoZSA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5 I3NlY3Rpb24tNC4xIiB0YXJnZXQ9Il9ibGFuayI+DQpKV1QncyBSZWdpc3RlcmVkIENsYWltIE5h bWVzPC9hPiAoYXQgbGVhc3QgaXNzIGFuZCBhdWQgYnV0IG1heWJlIGV4cCBhbmQgb3RoZXJzKSBh cyBhdXRob3JpemF0aW9uIHJlcXVlc3QNCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlhbmEub3JnL2Fz c2lnbm1lbnRzL29hdXRoLXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54aHRtbCNwYXJhbWV0 ZXJzIiB0YXJnZXQ9Il9ibGFuayI+DQpPQXV0aCBwYXJhbWV0ZXJzPC9hPj88YnI+DQo8YnI+DQpB bHNvIGluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9h dXRoLWp3c3JlcS0wNiNzZWN0aW9uLTMiIHRhcmdldD0iX2JsYW5rIj4NClNlY3Rpb24gMzwvYT4s IEkgcGVyc29uYWxseSBmZWVsIGxpa2UgdGhlICZxdW90O2V4dGVuc2lvbiB2YXJpYWJsZXMmcXVv dDsgZGV0cmFjdCBmcm9tIHRoZSBleGFtcGxlIGJlaW5nIGFibGUgdG8gZWFzaWx5IGNvbnZleSB0 aGUgY29uY2VwdC4gSSB3b3VsZCBzdWdnZXN0IHVzaW5nIG9ubHkgJ3ZhbmlsbGEnIE9BdXRoIHBh cmFtZXRlcnMuIE9yLCBhdCB0aGUgdmVyeSBsZWFzdCwgcmVtb3ZpbmcgdGhlICZxdW90O2NsYWlt cyZxdW90OyBzdHVmZiwgd2hpY2ggZG91YmxlcyB0aGUgc3BhY2UNCiB1c2VkIGJ5IHRoZSBleGFt cGxlIGFuZCBpcyBhIHZlcnkgT3BlbklEIENvbm5lY3Qgc3BlY2lmaWMgdGhpbmcuIFRoaXMgYXBw bGllcyB0byB0aGUgZXhhbXBsZXMgdGhyb3VnaG91dCB0aGUgZHJhZnQgaW5jbHVkaW5nIHRob3Nl IHRoYXQgaGF2ZSB0aGUgZW5jb2RlZCBKV1QgUmVxdWVzdCBPYmplY3QuDQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+SW4gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtb2F1dGgtandzcmVxLTA2I3NlY3Rpb24tNCIgdGFyZ2V0PSJfYmxhbmsiPg0KU2VjdGlv biA0PC9hPiwgdGhlIHdob2xlICZxdW90O1RoZSBjbGllbnQgY29uc3RydWN0cyB0aGUgYXV0aG9y aXphdGlvbiByZXF1ZXN0IFVSSSBieSAuLi4mcXVvdDsgZm9sbG93ZWQgYnkgdGhlIGxpc3Qgb2Yg cGFyYW1ldGVycyBpcyBzb21ld2hhdCBhd2t3YXJkIHRvIG1lIC0gZXNwZWNpYWxseSB3aXRoIHRo ZSAmcXVvdDtSRVFVSVJFRCZxdW90O3MuIFdoeSBsaXN0ICZxdW90O3N0YXRlJnF1b3Q7IGhlcmUg YW5kIG5vbmUgb2YgdGhlIG90aGVycyBoZXJlPyBJIHRoaW5rIEkga25vdyB3aHkgKHlvdQ0KIGV4 cGVjdCBzdGF0ZSB0byB2YXJ5IG9uIGVhY2ggcmVxdWVzdCBidXQgbm90IG90aGVycykgYnV0IGEg bG90IG9mIGluZmVycmluZyBuZWVkcyB0byBoYXBwZW4gZnJvbSB0aGUgcmVhZGVyLiZuYnNwOyBG b3IgdGhlIGV4dGVuc2lvbiBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQsIG9uZSB1c2VzIGVpdGhl ciByZXF1ZXN0X3VyaSBvciByZXF1ZXN0IChidXQgbm90IGJvdGgsIHJpZ2h0PyBJJ20gbm90IHN1 cmUgaXQncyBleHBsaWNpdGx5IHN0YXRlZCBhbnl3aGVyZSkNCiBhbmQgd2hhdGV2ZXIgb3RoZXIg cGFyYW1ldGVycyBhcmUgbmVlZGVkIGluIHRoZSBnaXZlbiBzaXR1YXRpb24uIE1heWJlIGp1c3Qg c29tZSB0ZXh0IHRvd2FyZHMgdGhhdCBlbmQgcmF0aGVyIHRoYW4gdGhlIGxpc3QgZm9ybWF0Pzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BbHNvIGluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0wNiNzZWN0aW9uLTQiIHRhcmdldD0i X2JsYW5rIj4NClNlY3Rpb24gNDwvYT4sIHRoZSByZXF1ZXN0X3VyaSBpbiB0aGUgZXhhbXBsZSBp cyBhIGxvdCBsaWtlIHRoZSBVUkkgdGhhdCdzIHVzZWQgZm9yIHJlZGlyZWN0X3VyaSBpbiBhIGxv dCBvZiBwbGFjZXMgKHRoZSAvY2IgcGF0aCwgSSB0aGluaywgd2FzIGludGVuZGVkIHRvIHNob3J0 IGZvciBjYWxsYmFjaykuIEkgbWVhbiwgaXQgKmNvdWxkKiBoYXBwZW4gYnV0IHRoZSBleGFtcGxl IGlzIG1vcmUgY29uZnVzaW5nIHRoYW4gbmVlZHMgdG8gYmUuIEl0J3MNCiBhbHNvIHRvbyBsb25n L3dpZGUgZm9yIHRoZSBwYWdlIC0gYWRkIHNvbWUgbGluZSBicmVha3MsIHdoaWNoIGFyZSBmb3Ig ZGlzcGxheSBwdXJwb3NlcyBvbmx5LiBQZXJoYXBzIG1vdmUgdGhpcyBleGFtcGxlIHRvIDQuMigu MSkgc29tZXdoZXJlIGFuZCBtYXRjaCB0aGUgdmFsdWUgd2l0aCB0aGUgdmFsdWUgc2hvd24gdGhl cmU/DQo8YnI+DQo8YnI+DQpBbHNvIGluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0wNiNzZWN0aW9uLTQiIHRhcmdldD0iX2JsYW5r Ij4NClNlY3Rpb24gNDwvYT4sIHRoZSBzZW50ZW5jZSB0aGF0IHN0YXJ0cyB3aXRoICdXaGVuIHRo ZSAmcXVvdDtyZXF1ZXN0JnF1b3Q7IHBhcmFtZXRlciBpcyB1c2VkLi4uJyBzdWdnZXN0cyB0aGF0 IHRoZSB0ZXh0IGFib3V0IEpXVCBwYXJhbWV0ZXJzIHN1cGVyc2VkaW5nIG90aGVycyBpcyBvbmx5 IGFwcGxpY2FibGUgdG8gdGhlIHBhc3MgYnkgdmFsdWUgbWV0aG9kIGJ1dCBpdCBhcHBsaWVzIHRv IGJvdGguIFBlcmhhcHMgY2hhbmdlICcmcXVvdDtyZXF1ZXN0JnF1b3Q7IHBhcmFtZXRlcicNCiB0 byAnUmVxdWVzdCBPYmplY3QnPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGUgc2Vjb25kIHBh cmFncmFwaCBvZiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vYXV0aC1qd3NyZXEtMDYjc2VjdGlvbi00LjIuMSIgdGFyZ2V0PSJfYmxhbmsiPg0KU2VjdGlv biA0LjIuMTwvYT4gdGFsa3MgYWJvdXQgJnF1b3Q7cmVxdWVzdGVkIHZhbHVlcyBmb3IgQ2xhaW1z JnF1b3Q7IHdoaWNoIGlzIGFuIE9wZW5JRCBDb25uZWN0IHRoaW5nIHRoYXQgaXNuJ3QgcmVhbGx5 IGFwcGxpY2FibGUgdG8gdGhpcyBkcmFmdC4gQ2FuIHRoaXMgcGFyYWdyYXBoIGJlIGRyb3BwZWQg b3IgbWFkZSBtb3JlIGdlbmVyYWwgdG8gYmUgYWJvdXQgYW55IHBvdGVudGlhbGx5IHNlbnNpdGl2 ZSBvciBQSUkgZGF0YT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QWxzbyBpbiA8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMDYjc2Vj dGlvbi00LjIuMSIgdGFyZ2V0PSJfYmxhbmsiPg0KU2VjdGlvbiA0LjIuMTwvYT4sIGlzICZxdW90 Oy4uLiBhdCBhIFVSTCB0aGUgU2VydmVyIGNhbiBhY2Nlc3MuLi4gJnF1b3Q7IC0gYXNzdW1lIHRo ZSAmcXVvdDtBdXRob3JpemF0aW9uIFNldmVyJnF1b3Q7Pw0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPklzbid0IGl0IGEgYml0IG9kZCBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMDYjc2VjdGlvbi01LjIiIHRhcmdldD0iX2Js YW5rIj4NClNlY3Rpb24gNS4yPC9hPiB0byB0YWxrIGFib3V0IHRoZSAmcXVvdDtyZXF1ZXN0X29i amVjdF9zaWduaW5nX2FsZyZxdW90OyB3aGljaCBpcyBkZWZpbmVkIGluDQo8YSBocmVmPSJodHRw Oi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLmh0bWwi IHRhcmdldD0iX2JsYW5rIj4NCk9wZW5JRCBDb25uZWN0IER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJh dGlvbjwvYT4gKHdoaWNoIGlzIG5vdCByZWZlcmVuY2VkKSBhbmQga2luZGEgbWVudGlvbmVkIGlu DQo8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1jb3JlLTFf MC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+T3BlbklEIENvbm5lY3QgQ29yZTwvYT4gKGluZm9ybWF0 aXZlIHJlZmVyZW5jZWQpPyBJIGRvbid0IGtub3cgdGhhdCBpdCBiZWxvbmdzIGhlcmU/IE9yIGlm IGl0IGRvZXMsIHdoYXQgYWJvdXQgcmVxdWVzdF9vYmplY3RfZW5jcnlwdGlvbl9hbGcgYW5kIHJl cXVlc3Rfb2JqZWN0X2VuY3J5cHRpb25fZW5jPyBJDQogc3VwcG9zZSByZWxhdGVkIHRvIHRoYXQg aXMgdGhlIHF1ZXN0aW9uIG9mIGlmL2hvdyB0byB1c2UgdGhlIGNsaWVudF9zZWNyZXQgZm9yIEhN QUMgYW5kIHN5bW1ldHJpYyBlbmNyeXB0aW9uIGFsZ29yaXRobXMgYW5kIGlmIHRoYXQgbmVlZHMg dG8gYmUgZGlzY3Vzc2VkIGhlcmU/IEluZGljYXRpbmcgcHVibGljIGtleShzKSB0b28gZm9yIHRo YXQgbWF0dGVyLiBTZWVtcyBsaWtlIGFsbCB0aGUgbWV0YWRhdGEvcmVnaXN0cmF0aW9uIHN0dWZm IHNob3VsZA0KIGJlIGluIGhlcmUuIE9yIGl0IHNob3VsZCBhbGwgYmUgb3V0IG9mIHNjb3BlLiBC dXQganVzdCB0aGUgcmVxdWVzdF9vYmplY3Rfc2lnbmluZ19hbGcgc2VlbXMgb2RkIHRvIG1lLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTA2 I3NlY3Rpb24tNiIgdGFyZ2V0PSJfYmxhbmsiPlNlY3Rpb24gNjwvYT4gc2F5cyB0aGF0ICZxdW90 Oy4uLiB0aGlzIGRvY3VtZW50IGRlZmluZXMgYWRkaXRpb25hbCBlcnJvciB2YWx1ZXMgLi4uJnF1 b3Q7IGJ1dCB0aG9zZSB3ZXJlIHByZXZpb3VzbHkgZGVmaW5lZCBpbg0KPGEgaHJlZj0iaHR0cDov L29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRtbCNBdXRoRXJyb3Ii IHRhcmdldD0iX2JsYW5rIj4NCjMuMS4yLjYgb2YgT3BlbklEIENvbm5lY3QgQ29yZTwvYT4uIE1h eWJlIGp1c3QgY2hhbmdlIHRoZSB3b3JkaW5nIHRvIHJlZmxlY3QgdGhlIHJlYWwgc3RhdGUgb2Yg dGhpbmdzPyAmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0wNiNzZWN0aW9u LTciIHRhcmdldD0iX2JsYW5rIj5TZWN0aW9uIDc8L2E+IHNheXMgdGhhdCAmcXVvdDtUaGUgcmVx dWVzdF9vYmplY3Rfc2lnbmluZ19hbGcgT0F1dGggRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9u IE1ldGFkYXRhIGlzIHBlbmRpbmcgcmVnaXN0cmF0aW9uDQogYnkgT3BlbklEIENvbm5lY3QgRHlu YW1pYyBSZWdpc3RyYXRpb24gc3BlY2lmaWNhdGlvbi4mcXVvdDsgQnV0IGlzIHRoYXQgdHJ1ZT8g VGhlIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29hdXRoLXBhcmFt ZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54aHRtbCNjbGllbnQtbWV0YWRhdGEiIHRhcmdldD0iX2Js YW5rIj4NCnJlZ2lzdHJ5PC9hPiBkb2Vzbid0IGhhdmUgaXQgYW5kIDxhIGhyZWY9Imh0dHA6Ly9v cGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LXJlZ2lzdHJhdGlvbi0xXzAuaHRtbCNJQU5B IiB0YXJnZXQ9Il9ibGFuayI+DQpDb25uZWN0J3MgUmVnaXN0cmF0aW9uPC9hPiAmcXVvdDttYWtl cyBubyByZXF1ZXN0cyBvZiBJQU5BJnF1b3Q7LiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIEknbSBzdXJlIHJlYWRpbmcgdGhpcyBoYXMgYmVl biBhIHRvbiBvZiBmdW4gZm9yIHRoZSBlZGl0b3JzLCBJJ20gc3VyZSB5b3Ugd2lsbCBiZSBoYXBw eSB0byBwbGVhc2UgYWRkIG1lIHRvIHRoZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTA2I3NlY3Rpb24tOSIgdGFyZ2V0PSJfYmxh bmsiPg0KQWNrbm93bGVkZ2VtZW50cyBTZWN0aW9uPC9hPiA7KSA8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB4422A5C4671F0DB1F312919F5210BY2PR03MB442namprd_-- From nobody Fri Oct 30 02:16:57 2015 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 795F51A88AD for ; Fri, 30 Oct 2015 02:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 2RkTdcMLOaJd for ; Fri, 30 Oct 2015 02:16:55 -0700 (PDT) Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82B81A88D1 for ; Fri, 30 Oct 2015 02:16:50 -0700 (PDT) Received: from [192.168.0.106] ([77.77.164.50]) by p3plsmtpa06-02.prod.phx3.secureserver.net with id bMGp1r00515ZTut01MGqzm; Fri, 30 Oct 2015 02:16:50 -0700 To: oauth@ietf.org References: From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <56333580.30809@connect2id.com> Date: Fri, 30 Oct 2015 11:16:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000705030703040400020003" Archived-At: Subject: Re: [OAUTH-WG] token endpoint: 400 or 401? 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, 30 Oct 2015 09:16:56 -0000 This is a multi-part message in MIME format. --------------000705030703040400020003 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi Ofer, If the client has authenticated RFC 2617 style then the 401 status code is mandatory. So there's no conflict with the RFC 2617 spec. http://tools.ietf.org/html/rfc6749#section-5.2 invalid_client Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the "Authorization" request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code and include the "WWW-Authenticate" response header field matching the authentication scheme used by the client. On 24.10.2015 05:23, Ofer Nave wrote: > I'm using the auth code flow, and supporting basic auth for client auth on > the token endpoint. > > In the OAuth spec it says to respond with 400 and a json body with error: > invalid_client if client auth fails. However, doesn't RFC 2617 say to > respond with 401 and a WWW-Authenticate header? Does the OAuth spec > supercede 2617 in this case? > > -ofer > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000705030703040400020003 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi Ofer,

If the client has authenticated RFC 2617 style then the 401 status code is mandatory. So there's no conflict with the RFC 2617 spec.

http://tools.ietf.org/html/rfc6749#section-5.2

invalid_client
               Client authentication failed (e.g., unknown client, no
               client authentication included, or unsupported
               authentication method).  The authorization server MAY
               return an HTTP 401 (Unauthorized) status code to indicate
               which HTTP authentication schemes are supported.  If the
               client attempted to authenticate via the "Authorization"
               request header field, the authorization server MUST
               respond with an HTTP 401 (Unauthorized) status code and
               include the "WWW-Authenticate" response header field
               matching the authentication scheme used by the client.


On 24.10.2015 05:23, Ofer Nave wrote:
I'm using the auth code flow, and supporting basic auth for client auth on
the token endpoint.

In the OAuth spec it says to respond with 400 and a json body with error:
invalid_client if client auth fails.  However, doesn't RFC 2617 say to
respond with 401 and a WWW-Authenticate header?  Does the OAuth spec
supercede 2617 in this case?

-ofer




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

--------------000705030703040400020003-- From nobody Sat Oct 31 03:14:14 2015 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 147EE1B3699 for ; Sat, 31 Oct 2015 03:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FpLI-HQ10eM3 for ; Sat, 31 Oct 2015 03:14:11 -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 78B4D1B3698 for ; Sat, 31 Oct 2015 03:14:11 -0700 (PDT) Received: from [192.168.10.226] ([118.243.125.63]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MDyFr-1ZhDgt1pMd-00HNnO for ; Sat, 31 Oct 2015 11:14:09 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5634946A.4020607@gmx.net> Date: Sat, 31 Oct 2015 11:14:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="n2wQPdFcx6BrotsP1rJWlouvvPlfdqkHc" X-Provags-ID: V03:K0:9v8oXG+LESqNrFsGyIvB6VI6PyNFG8zTUgb/GE+NDlDXm3mmxfQ JjfknClgf5QJZntzPpeUujacpJio79AeZVDqC/oc40Qby0fz4WNXHaK8hRvOOvfIRk1kQAG nnnl9bLGYSnbWzB5XpRsvGuAvNwa4tk5Z68mrpagHfY+vYDWN1vxSE7Xu9w030sze1cvZHX hpcXGI5qKdcBWJhWHmHBw== X-UI-Out-Filterresults: notjunk:1;V01:K0:HPm4mpYK5tk=:Dp/6wv7HDGfufxWIQdjC3+ QPsOxJAVP+eGVfSQFbbCaUwKM+uB1MCU40kyQ9cl2pNPDsHOvyMlNvDh4r+D5WvTF49SEeX+4 srSG49bg3XbZeKjl1AbZ858Gqd8vJuLdO+Jxyc24RPaMGfAUUwaFVPM5PyHhZ22MxXBnc83Nx Skhm1OUGouv+xc6pk0oTxnAwTVtBLEnFjnfcF4g+Xq4wthGnSxHLUOaVKne6G1W32Jr64n7x0 JYQaJRM5U/CVBz/5vH1KTzeusGo7rTKVInh8o1nP1xVkZIdASp+pfS7fJDaufcidJ8Wpn9aST t0CPmWrRnAPgJ9p1sLn2UCeBXkm5EutEmPxDj/d6HtQTTt6XoRtxUOKuvVROKROva0hKc/lhd exVVkgH5PAt7mAg5jCzwhpwK64O74ZF5GRw+9Uo1zqvGa7XM7u9gJrcq4gQ/XbwZP9ZjUVT9Y Ka+3GWEuF6GM4IILWITk1JsrMT+VSFkrzoIUPqufYoQ/Mb3Z1RCDeT3HNhi6cvevvNSJxh78Z qkbLfWHK/5de1I+KyvX7nkqcl2CIsFkZ26y8EOMiYNg932zY6lYp9ppCAH+9tfCLDdD8zBWuC ukFFEa4Ga4y4IV9A7k6M0PUZSeVhQf6DVeoTRJ17MD0Tw7yu0bv9rD02PEJHJEo1kxOjYPlTY MYk0aNRv1wCOQgmDqJAeyhzI1aSSwaYo4Si1bZh8whzbmCIp+BE2V+JF7M8LiUEHupyyrZjOO 2WaURSeqUnGZnxpjPf/uyUY812GNjDfU37ExBYllW2+im2OcM94PBaemskA= Archived-At: Subject: [OAUTH-WG] Meeting 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: Sat, 31 Oct 2015 10:14:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --n2wQPdFcx6BrotsP1rJWlouvvPlfdqkHc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Please have a look at the meeting agenda for our OAuth meeting: https://www.ietf.org/proceedings/94/agenda/agenda-94-oauth ----- IETF 93 OAuth WG Meeting Agenda Thursday, November 5, 2015 (JST) Room 301 15:20-17:20 Thursday Afternoon session II - Status Update (Hannes) - OAuth 2.0 JWT Authorization Request (Nat) http://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ Document is currently in WGLC. - Proof-of-Possession (TBD) http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ - Token Exchange (Mike) http://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ - OAuth 2.0 for Native Apps http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ ------ Let us know if you would like to make some additions or changes. Ciao Hannes & Derek --n2wQPdFcx6BrotsP1rJWlouvvPlfdqkHc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWNJRsAAoJEGhJURNOOiAtxXUH/iUGgKkjbuVwLSIPgaLLXl2J eqfV+SjIGu+S6X+155CYFmOIwgTyRqEb6HzdJhaJjOF6M9CRGq52YH2HlVTMFUg8 PasJ5pqUiALrplcgIuPJVQ/CjpktwEInEDyk6qPuruiy5zFDCN8BnZrMI/levdoW DhUBEmpMsERdtgwY+gfsnjQevmO5V8ev711P99zIvbMpLUKbIpfVhqnqii3Rhjp5 sL3Pk580L3lYi/StNL9xBzoBqb8HyGt0pkM+FmSc/P6++UiraxcpuKrcVGDb8wN8 s769CF8uo4xalUpY/fZ6LAGLbgOU6Nuetj+aCa/YnclpFWMW7hih4qwp74F3s7c= =OU9J -----END PGP SIGNATURE----- --n2wQPdFcx6BrotsP1rJWlouvvPlfdqkHc--