From nobody Tue Jul 1 14:40:30 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7471A0648 for ; Tue, 1 Jul 2014 14:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIBlE87Zqcu4 for ; Tue, 1 Jul 2014 14:40:23 -0700 (PDT) Received: from usmailout3.samsung.com (mailout3.w2.samsung.com [211.189.100.13]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916621A02E9 for ; Tue, 1 Jul 2014 14:40:23 -0700 (PDT) Received: from uscpsbgm2.samsung.com (u115.gpu85.samsung.co.kr [203.254.195.115]) by usmailout3.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N81004W0YV92210@usmailout3.samsung.com> for oauth@ietf.org; Tue, 01 Jul 2014 17:40:21 -0400 (EDT) X-AuditID: cbfec373-b7fd56d0000060dc-f6-53b32ac5b109 Received: from ussync3.samsung.com ( [203.254.195.83]) by uscpsbgm2.samsung.com (USCPMTA) with SMTP id 49.2E.24796.5CA23B35; Tue, 01 Jul 2014 17:40:21 -0400 (EDT) Received: from sdsamadjidPC ([105.66.230.137]) by ussync3.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0N81002B0YV8NH40@ussync3.samsung.com>; Tue, 01 Jul 2014 17:40:21 -0400 (EDT) From: Madjid Nakhjiri To: oauth@ietf.org, 'John Bradley' Date: Tue, 01 Jul 2014 14:40:20 -0700 Message-id: <004601cf9575$0f23f240$2d6bd6c0$%nakhjiri@samsung.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_0047_01CF953A.62C51A40" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Ac+VdQ5LQnGm4WWESYK/3wDu/AASKA== Content-language: en-us X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsVy+t/hYN2jWpuDDe7NUbE4+fYVm8Xqu3/Z HJg8liz5yeRx+/ZGlgCmKC6blNSczLLUIn27BK6M+6uvsBdMS6noaj/P0sD4LrSLkZNDQsBE Ysv1HcwQtpjEhXvr2boYuTiEBJYwSuw79I4dwmlhknj0fTFYFZuAnsT+eTOAbA4OEQEziU/P a0FMZqDw0r/6IBXCAsoSr+YeYQIJswioSvReLQQJ8wo4SRy51sIMYQtK/Jh8jwXEZhaIlvh8 eRE7SLmEgLrEo7+6IGERoIETp65ghCgRl5j04CH7BEb+WUi6ZyHpnoWkbBbUPW0bGSHC8hLb 385hhrB1Jf4/h7G1JZYtfM28gJF9FaNoaXFyQXFSeq6RXnFibnFpXrpecn7uJkZIWBfvYHyx weoQowAHoxIPL8e2jcFCrIllxZW5hxglOJiVRHjjeTYHC/GmJFZWpRblxxeV5qQWH2Jk4uCU amAs+xPV+afBXSUu8Jp8P+/WoDvpsdLHGTeqdfix1ffe+LHhrVRGuF7X5PKPjzL4uNgV3vjo v1qcGRqjKjsr52/Z3geS4kvtmyrnVKbe/P+hoLfIeNXlhrdrugVP3Zd6eGXdzuqtascYV7Il XY09NoUvNXviu3jlu+KndpV6d5vq7+BmPyCgOVWJpTgj0VCLuag4EQD/X5FZSQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/QMe2fWi_osjCnxt162GRN6hLnoM Subject: [OAUTH-WG] Dynamic registration draft 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, 01 Jul 2014 21:40:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0047_01CF953A.62C51A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, John, So I reviewed the oauth-dyn-reg-17 with the goal of finding more info on the following statement in your previous email "Since the publishing of this RFC we have also developed a spec for dynamic client registration so it is possible to give every native client it's own client_id and secret making them confidential clients." If I understand the draft correctly, you can turn a native client from public to confidential only if the following is true: 1) The client must be able to dynamically register with the registration endpoint and download an instance-specific client ID and a temporary ("expirable") client secret on the fly. 2) Although the client cannot maintain the secrecy of any secrets packaged within client software, it needs to be able to maintain the secrecy of a per-instance client secret. So here are my questions: I am not quite sure what provides the trust in this scenario. The client is using a secret that it was just given by the registration end point (essentially hosted by authorization server?) to authenticate to the same authorization server? Unless an out of band trust relationship was used (initial access token??), we don't have any additional trust in client or its ability to hold secrets. The only added benefit by dynamic registration in the way of above is that (as I see it), because the ID and secret are instance specific, their compromise only leads to the compromise of just that client and just that user's data, rather than the entire populations. Or the point is that we are saying there are clients/scenarios that can be trusted with short term secrets but not long term secrets? Am I missing something? I could see that if we had required an out of band trust relationship, for instance requirement of a protected dynamic registration (use of initial access token that is client instance specific), not sure how the two above helps an individual user? My other comment regarding the drafts are as follows: 1) The draft is somewhat asymmetric with respect to the use of software statement versus initial access token. Although, the specs says that they are both choices of methods of attestations, only Initial access token is required for protected registration, while software statement is declared orthogonal to open versus protected registration. Since spec is silent on creation of initial access token generation, it is hard to see what qualifies the initial access token but not software statement. 2) Software statement is a signed/ MACed statement of a subset (or none, since they are all optional) of client meta data but not the client software itself. So question is do I have any protection if the client software itself is modified maliciously (even though the metadata is still the same)? Thanks in advance, Madjid _________________________________________________ Madjid Nakhjiri | Technical Director, Security Architect Samsung SDS Research America ------=_NextPart_000_0047_01CF953A.62C51A40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all, = John,

 

So I reviewed the oauth-dyn-reg-17 with the goal of = finding more info on the following statement in your previous = email

 

“Since the publishing of this RFC we have also = developed a spec for dynamic client registration so it is possible to = give every native client it's own client_id and secret making them = confidential clients.”

 

If I = understand the draft correctly, you can turn a native client from public = to confidential only if the following is true:

 

1)      = The client must be able to dynamically register = with the registration endpoint and download an instance-specific client = ID and a temporary (“expirable”) client secret on the = fly.

2)      = Although the client cannot maintain the secrecy = of any secrets packaged within client software, it needs to be able to = maintain the secrecy of a per-instance client secret.

 

So here are = my questions: I am not quite sure what provides the trust in this = scenario. The client is using a secret that it was just given by the = registration end point (essentially hosted by authorization server?) to = authenticate to the same authorization server? Unless an out of band = trust relationship was used (initial access token??), we don’t = have any additional trust in client or its ability to hold secrets. The = only added benefit by dynamic registration in the way of above is that = (as I see it), because the ID and secret are instance specific, their = compromise only leads to the compromise of just that client and just = that user’s data, rather than the entire populations. Or the point = is that we are saying there are clients/scenarios that can be trusted = with short term secrets but not long term secrets?

 

Am I missing = something?

 

I could see that if we had required an out of band = trust relationship, for instance requirement of a protected dynamic = registration (use of initial access token that is client instance = specific), not sure how the two above helps an individual = user?

 

 

My other = comment regarding the drafts are as follows:

1)      = The draft is somewhat asymmetric with respect to = the use of software statement versus initial access token. Although, the = specs says that they are both choices of methods of attestations, only = Initial access token is required for protected registration, while = software statement is declared orthogonal to open versus protected = registration. Since spec is silent on creation of initial access token = generation, it is hard to see what qualifies the initial access token = but not software statement.

2)      = Software statement is a signed/ MACed statement = of a subset (or none, since they are all optional) of client meta data = but not the client software itself. So question is do I have any = protection if the client software itself is modified maliciously (even = though the metadata is still the same)?  

 

Thanks in = advance,

Madjid

 

_________________________________________________

Madjid Nakhjiri | Technical Director, Security Architect

Samsung SDS Research America



<= /o:p>

 

------=_NextPart_000_0047_01CF953A.62C51A40-- From nobody Tue Jul 1 15:05:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEF61A0A9F for ; Tue, 1 Jul 2014 15:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVPgSRhFhwgI for ; Tue, 1 Jul 2014 15:05:14 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCA71A0A9E for ; Tue, 1 Jul 2014 15:05:13 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id z60so3900308qgd.24 for ; Tue, 01 Jul 2014 15:05:13 -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=R8iKpywvmNYfJpeCDhp6Kwjc8uAmeLSQ4oVNdgDaeQM=; b=K1rJhdDxqj929e0r8bK6oIQPjonWXPKjC+6S7uBErdaGEhOG5e97/J6k8Ta7mLNVSr Jc6fvy4qYqjJwU5MCluRkHKw8pTm+67ssSVd5NU6TfizS7xcVfDSiD3ONa93e8zjNEB3 SY4DlCwU9/NHSVtDjaDpFZeqhhLRF5hb/GrfUpJl31hLASyjSYNpP8IiqesLhdxNlHYV IocK/mtfmYwPUPcU3acVrPoQZDnje4q6hg/nUWX7mLQWOKJEzXgqwFd2SyMLMBK2+aVV PuqBIA96SOFdA3b6tJTCxkZs3EYauKobWGDA4bgTCCtN4isxWFHtEIP0oAI9CUDT+Rvy oP1A== X-Gm-Message-State: ALoCoQl32X1goszFEjJPUV6r17aSO9HES6U+vhi8M1gn++7tSXmeHWQxfCWTxPYQ1oAaaTUZE/Mj X-Received: by 10.140.37.232 with SMTP id r95mr36783942qgr.59.1404252313138; Tue, 01 Jul 2014 15:05:13 -0700 (PDT) Received: from [192.168.0.199] ([201.189.68.162]) by mx.google.com with ESMTPSA id p67sm9549210qgd.34.2014.07.01.15.05.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Jul 2014 15:05:12 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B0AEA618-AAA4-4E6F-9179-8E17607F707F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Bradley In-Reply-To: <004601cf9575$0f23f240$2d6bd6c0$%nakhjiri@samsung.com> Date: Tue, 1 Jul 2014 18:06:07 -0400 Message-Id: <901D7016-9135-4B11-8D1F-8D204313F8F2@ve7jtb.com> References: <004601cf9575$0f23f240$2d6bd6c0$%nakhjiri@samsung.com> To: Madjid Nakhjiri X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/a5yhpXvLxpxnwa462k_BJ29PboA Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic registration draft 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, 01 Jul 2014 22:05:17 -0000 --Apple-Mail=_B0AEA618-AAA4-4E6F-9179-8E17607F707F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 With native applications the response from the Authorization server can = be intercepted by other applications on the device. =20 This is a known attack. If the intercepting application knows the = client_id and client_secret of the legitimate application it can = exchange the code for access and or refresh tokens. Dynamic registration prevents other applications on the device from = knowing the client secret. This protects against some attacks. No you have no way to know if it is the legitimate application that is = registering. The only way to do that is with some OS or MDM resident = code that validates the applications signature. The software statement allows a software publisher to bundle a set of = configuration options together, and be known by the AS as coming from = that publisher, however it is still self asserted and doesn't=20 guarantee the software registering is legitimate. The initial access token enables the out of band trust relationship. = It works well with web clients that may register out of band proving who = they are and agreeing to terms of service, and then receving a access = token to do the automated registration. For a native application on a device this might be possible if there is = device management software that could push a bootstrap access token to = the application to do the registration. John B. On Jul 1, 2014, at 5:40 PM, Madjid Nakhjiri = wrote: > Hi all, John, > =20 > So I reviewed the oauth-dyn-reg-17 with the goal of finding more info = on the following statement in your previous email > =20 > =93Since the publishing of this RFC we have also developed a spec for = dynamic client registration so it is possible to give every native = client it's own client_id and secret making them confidential clients.=94 > =20 > If I understand the draft correctly, you can turn a native client from = public to confidential only if the following is true: > =20 > 1) The client must be able to dynamically register with the = registration endpoint and download an instance-specific client ID and a = temporary (=93expirable=94) client secret on the fly. > 2) Although the client cannot maintain the secrecy of any secrets = packaged within client software, it needs to be able to maintain the = secrecy of a per-instance client secret. > =20 > So here are my questions: I am not quite sure what provides the trust = in this scenario. The client is using a secret that it was just given by = the registration end point (essentially hosted by authorization server?) = to authenticate to the same authorization server? Unless an out of band = trust relationship was used (initial access token??), we don=92t have = any additional trust in client or its ability to hold secrets. The only = added benefit by dynamic registration in the way of above is that (as I = see it), because the ID and secret are instance specific, their = compromise only leads to the compromise of just that client and just = that user=92s data, rather than the entire populations. Or the point is = that we are saying there are clients/scenarios that can be trusted with = short term secrets but not long term secrets? > =20 > Am I missing something? > =20 > I could see that if we had required an out of band trust relationship, = for instance requirement of a protected dynamic registration (use of = initial access token that is client instance specific), not sure how the = two above helps an individual user? > =20 > =20 > My other comment regarding the drafts are as follows: > 1) The draft is somewhat asymmetric with respect to the use of = software statement versus initial access token. Although, the specs says = that they are both choices of methods of attestations, only Initial = access token is required for protected registration, while software = statement is declared orthogonal to open versus protected registration. = Since spec is silent on creation of initial access token generation, it = is hard to see what qualifies the initial access token but not software = statement. > 2) Software statement is a signed/ MACed statement of a subset = (or none, since they are all optional) of client meta data but not the = client software itself. So question is do I have any protection if the = client software itself is modified maliciously (even though the metadata = is still the same)? =20 > =20 > Thanks in advance, > Madjid > =20 > _________________________________________________ > Madjid Nakhjiri | Technical Director, Security Architect > Samsung SDS Research America --Apple-Mail=_B0AEA618-AAA4-4E6F-9179-8E17607F707F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 With = native applications the response from the Authorization server can be = intercepted by other applications on the device.  
This is a = known attack.   If the intercepting application knows the client_id = and client_secret of the legitimate application it can exchange the code = for access and or refresh tokens.

Dynamic = registration prevents other applications on the device from knowing the = client secret.  This protects against some = attacks.

No you have no way to know if it is = the legitimate application that is registering.   The only way to = do that is with some OS or MDM resident code that validates the = applications signature.

The software statement = allows a software publisher to bundle a set of configuration options = together,  and be known by the AS as coming from that publisher, = however it is still self asserted and doesn't 
guarantee = the software registering is legitimate.

The = initial access token enables the out of band trust relationship.   = It works well with web clients that may register out of band proving who = they are and agreeing to terms of service, and then receving a access = token to do the automated registration.

For a = native application on a device this might be possible if there is device = management software that could push a bootstrap access token to the = application to do the registration.

John = B.

On Jul 1, 2014, at 5:40 PM, Madjid Nakhjiri = <m.nakhjiri@samsung.com> = wrote:

Hi all, = John,
 
So I reviewed the oauth-dyn-reg-17 with the goal = of finding more info on the following statement in your previous = email
 
=93Since the publishing of this RFC we have also = developed a spec for dynamic client registration so it is possible to = give every native client it's own client_id and secret making them = confidential clients.=94
 
If I = understand the draft correctly, you can turn a native client from public = to confidential only if the following is true:
 
1)      The client = must be able to dynamically register with the registration endpoint and = download an instance-specific client ID and a temporary (=93expirable=94) = client secret on the fly.
2)      Although the = client cannot maintain the secrecy of any secrets packaged within client = software, it needs to be able to maintain the secrecy of a per-instance = client secret.
 
So here = are my questions: I am not quite sure what provides the trust in this = scenario. The client is using a secret that it was just given by the = registration end point (essentially hosted by authorization server?) to = authenticate to the same authorization server? Unless an out of band = trust relationship was used (initial access token??), we don=92t have = any additional trust in client or its ability to hold secrets. The only = added benefit by dynamic registration in the way of above is that (as I = see it), because the ID and secret are instance specific, their = compromise only leads to the compromise of just that client and just = that user=92s data, rather than the entire populations. Or the point is = that we are saying there are clients/scenarios that can be trusted with = short term secrets but not long term secrets?
 
Am I = missing something?
 
I could = see that if we had required an out of band trust relationship, for = instance requirement of a protected dynamic registration (use of initial = access token that is client instance specific), not sure how the two = above helps an individual user?
 
 
My other = comment regarding the drafts are as follows:
1)      The draft is = somewhat asymmetric with respect to the use of software statement versus = initial access token. Although, the specs says that they are both = choices of methods of attestations, only Initial access token is = required for protected registration, while software statement is = declared orthogonal to open versus protected registration. Since spec is = silent on creation of initial access token generation, it is hard to see = what qualifies the initial access token but not software = statement.
2)      Software = statement is a signed/ MACed statement of a subset (or none, since they = are all optional) of client meta data but not the client software = itself. So question is do I have any protection if the client software = itself is modified maliciously (even though the metadata is still the = same)?  
 
Thanks in = advance,
Madjid
 
_________________________________________________
Madjid Nakhjiri | Technical = Director, Security Architect
Samsung SDS = Research = America

= --Apple-Mail=_B0AEA618-AAA4-4E6F-9179-8E17607F707F-- From nobody Tue Jul 1 16:26:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0F01A0AF4 for ; Tue, 1 Jul 2014 16:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.55 X-Spam-Level: X-Spam-Status: No, score=-7.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGJOev09FmeY for ; Tue, 1 Jul 2014 16:26:24 -0700 (PDT) Received: from usmailout2.samsung.com (mailout2.w2.samsung.com [211.189.100.12]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068051A0AF3 for ; Tue, 1 Jul 2014 16:26:23 -0700 (PDT) Received: from uscpsbgm2.samsung.com (u115.gpu85.samsung.co.kr [203.254.195.115]) by mailout2.w2.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N8200JIZ3RY2F40@mailout2.w2.samsung.com> for oauth@ietf.org; Tue, 01 Jul 2014 19:26:22 -0400 (EDT) X-AuditID: cbfec373-b7fd56d0000060dc-0d-53b3439ed313 Received: from ussync1.samsung.com ( [203.254.195.81]) by uscpsbgm2.samsung.com (USCPMTA) with SMTP id C0.C4.24796.E9343B35; Tue, 01 Jul 2014 19:26:22 -0400 (EDT) Received: from sdsamadjidPC ([105.66.230.137]) by ussync1.samsung.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0N8200F0Z3RXOS90@ussync1.samsung.com>; Tue, 01 Jul 2014 19:26:22 -0400 (EDT) From: Madjid Nakhjiri To: 'John Bradley' References: <004601cf9575$0f23f240$2d6bd6c0$%nakhjiri@samsung.com> <901D7016-9135-4B11-8D1F-8D204313F8F2@ve7jtb.com> In-reply-to: <901D7016-9135-4B11-8D1F-8D204313F8F2@ve7jtb.com> Date: Tue, 01 Jul 2014 16:26:20 -0700 Message-id: <009701cf9583$de2d9f60$9a88de20$%nakhjiri@samsung.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_0098_01CF9549.31CEC760" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Ac+VeJcPigaio51LQOOx6LVEdSKLQQACf8RA Content-language: en-us X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsVy+t/hQN15zpuDDc4fULY4+fYVm8Xqu3/Z HJg8liz5yeRx+/ZGlgCmKC6blNSczLLUIn27BK6MjiaWgt2rGCtmrn7I3sB4czJjFyMHh4SA icS5Yx5djJxAppjEhXvr2boYuTiEBJYwSjw5sIwdwmlhkph5bA8jSBWbgJ7E/nkzmEFsEQE1 ieXbO9lBbGYBIYkPl5pYQGwhgTKJZYv3gNVwCthJHP+1ggnEFhZQl/g/6SBYPYuAqsTJE2vB bF4BJ4n5x/qYIGxBiR+T77GAHMcsEC3x7m4IxJ3qEo/+6kJsNZLonrGXCWKruMSkBw/ZJzAK zkLSPAuheRaSKoiwnkTbRkaIsLzE9rdzmCFsXYn/z2FsbYllC18zL2BkX8UoWlqcXFCclJ5r pFecmFtcmpeul5yfu4kREgnFOxhfbLA6xCjAwajEw8uxbWOwEGtiWXFl7iFGCQ5mJRHeeJ7N wUK8KYmVValF+fFFpTmpxYcYmTg4pRoYudU+xOz/funLi6MK3z0FK1dsT1oj80stelu61GPu F5Y/PUX13ROOlOzKjb72kHHHxAVhBdLlcv1uHqq+3Oo7Dc7OOGa+6GvGhDP37s7fEqfZLNnx xvZuanXTZwuDl1ev3W8J9Nn1LuL9hId/2lVfMPmv/fBzzf7U49la3Yd+KZyM+5dmV/hnhxJL cUaioRZzUXEiAOQfn8JiAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/e6DuGY4oGYmYpFhumODUEgcoLZw Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic registration draft 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, 01 Jul 2014 23:26:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0098_01CF9549.31CEC760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi John, Thanks again for your answer. Ok, so we agree that the "eve" app can take the secret out of the "bob" app. This is a matter of security robustness on the device and whether different applications running on the same OS on the same device have access to each other's data, even if you use unique ID and secrets. So, I still don't understand how dynamic registration prevents other apps on the device from knowing the client secret? (i.e. qualifying the client as confidential?) On the software verification, I agree with you on the need for OS or MDM verification, unless signature verification can be done remotely, which is also hard. On initial access token, are you saying that is for server side clients, mostly? On the device side clients (native apps) I see your point about the need for trusted "proxy" on the device to provide the out of band element. Madjid From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Tuesday, July 01, 2014 3:06 PM To: Madjid Nakhjiri Cc: oauth@ietf.org Subject: Re: Dynamic registration draft With native applications the response from the Authorization server can be intercepted by other applications on the device. This is a known attack. If the intercepting application knows the client_id and client_secret of the legitimate application it can exchange the code for access and or refresh tokens. Dynamic registration prevents other applications on the device from knowing the client secret. This protects against some attacks. No you have no way to know if it is the legitimate application that is registering. The only way to do that is with some OS or MDM resident code that validates the applications signature. The software statement allows a software publisher to bundle a set of configuration options together, and be known by the AS as coming from that publisher, however it is still self asserted and doesn't guarantee the software registering is legitimate. The initial access token enables the out of band trust relationship. It works well with web clients that may register out of band proving who they are and agreeing to terms of service, and then receving a access token to do the automated registration. For a native application on a device this might be possible if there is device management software that could push a bootstrap access token to the application to do the registration. John B. On Jul 1, 2014, at 5:40 PM, Madjid Nakhjiri wrote: Hi all, John, So I reviewed the oauth-dyn-reg-17 with the goal of finding more info on the following statement in your previous email "Since the publishing of this RFC we have also developed a spec for dynamic client registration so it is possible to give every native client it's own client_id and secret making them confidential clients." If I understand the draft correctly, you can turn a native client from public to confidential only if the following is true: 1) The client must be able to dynamically register with the registration endpoint and download an instance-specific client ID and a temporary ("expirable") client secret on the fly. 2) Although the client cannot maintain the secrecy of any secrets packaged within client software, it needs to be able to maintain the secrecy of a per-instance client secret. So here are my questions: I am not quite sure what provides the trust in this scenario. The client is using a secret that it was just given by the registration end point (essentially hosted by authorization server?) to authenticate to the same authorization server? Unless an out of band trust relationship was used (initial access token??), we don't have any additional trust in client or its ability to hold secrets. The only added benefit by dynamic registration in the way of above is that (as I see it), because the ID and secret are instance specific, their compromise only leads to the compromise of just that client and just that user's data, rather than the entire populations. Or the point is that we are saying there are clients/scenarios that can be trusted with short term secrets but not long term secrets? Am I missing something? I could see that if we had required an out of band trust relationship, for instance requirement of a protected dynamic registration (use of initial access token that is client instance specific), not sure how the two above helps an individual user? My other comment regarding the drafts are as follows: 1) The draft is somewhat asymmetric with respect to the use of software statement versus initial access token. Although, the specs says that they are both choices of methods of attestations, only Initial access token is required for protected registration, while software statement is declared orthogonal to open versus protected registration. Since spec is silent on creation of initial access token generation, it is hard to see what qualifies the initial access token but not software statement. 2) Software statement is a signed/ MACed statement of a subset (or none, since they are all optional) of client meta data but not the client software itself. So question is do I have any protection if the client software itself is modified maliciously (even though the metadata is still the same)? Thanks in advance, Madjid _________________________________________________ Madjid Nakhjiri | Technical Director, Security Architect Samsung SDS Research America ------=_NextPart_000_0098_01CF9549.31CEC760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John,

 

Thanks again for your answer. Ok, so we agree that the = “eve” app can take the secret out of the “bob” = app. This is a matter of security robustness on the device and whether = different applications running on the same OS on the same device have = access to each other’s data, even if you use unique ID and = secrets. So, I still don’t understand how dynamic registration = prevents other apps on the device from knowing the client secret? (i.e. = qualifying the client as confidential?)

 

On the software verification, I agree with you on the need for OS or = MDM verification, unless signature verification can be done remotely, = which is also hard.

 

On initial access token, are you saying that is for server side = clients, mostly?

On the device side clients (native apps) I see your point about the = need for trusted “proxy” on the device to provide the out of = band element.

 

Madjid

From:= = John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Tuesday, July = 01, 2014 3:06 PM
To: Madjid Nakhjiri
Cc: = oauth@ietf.org
Subject: Re: Dynamic registration = draft

 

With native = applications the response from the Authorization server can be = intercepted by other applications on the device. =  

This is a known attack. =   If the intercepting application knows the client_id and = client_secret of the legitimate application it can exchange the code for = access and or refresh tokens.

 

Dynamic registration prevents other applications on = the device from knowing the client secret.  This protects against = some attacks.

 

No you have no way to know if it is the legitimate = application that is registering.   The only way to do that is with = some OS or MDM resident code that validates the applications = signature.

 

The software statement allows a software publisher to = bundle a set of configuration options together,  and be known by = the AS as coming from that publisher, however it is still self asserted = and doesn't 

guarantee the software registering is = legitimate.

 

The initial access token enables the out of band trust = relationship.   It works well with web clients that may register = out of band proving who they are and agreeing to terms of service, and = then receving a access token to do the automated = registration.

 

For a native application on a device this might be = possible if there is device management software that could push a = bootstrap access token to the application to do the = registration.

 

John B.

 

On = Jul 1, 2014, at 5:40 PM, Madjid Nakhjiri <m.nakhjiri@samsung.com> = wrote:



Hi all, = John,

 =

So I = reviewed the oauth-dyn-reg-17 with the goal of finding more info on the = following statement in your previous = email

 =

“Sinc= e the publishing of this RFC we have also developed a spec for dynamic = client registration so it is possible to give every native client it's = own client_id and secret making them confidential = clients.”

 =

If I = understand the draft correctly, you can turn a native client from public = to confidential only if the following is = true:

 =

1)      The client = must be able to dynamically register with the registration endpoint and = download an instance-specific client ID and a temporary = (“expirable”) client secret on the = fly.

2)      Although = the client cannot maintain the secrecy of any secrets packaged within = client software, it needs to be able to maintain the secrecy of a = per-instance client secret.

 =

So here = are my questions: I am not quite sure what provides the trust in this = scenario. The client is using a secret that it was just given by the = registration end point (essentially hosted by authorization server?) to = authenticate to the same authorization server? Unless an out of band = trust relationship was used (initial access token??), we don’t = have any additional trust in client or its ability to hold secrets. The = only added benefit by dynamic registration in the way of above is that = (as I see it), because the ID and secret are instance specific, their = compromise only leads to the compromise of just that client and just = that user’s data, rather than the entire populations. Or the point = is that we are saying there are clients/scenarios that can be trusted = with short term secrets but not long term = secrets?

 =

Am I = missing something?

 =

I could = see that if we had required an out of band trust relationship, for = instance requirement of a protected dynamic registration (use of initial = access token that is client instance specific), not sure how the two = above helps an individual user?

 =

 =

My other = comment regarding the drafts are as = follows:

1)      The draft = is somewhat asymmetric with respect to the use of software statement = versus initial access token. Although, the specs says that they are both = choices of methods of attestations, only Initial access token is = required for protected registration, while software statement is = declared orthogonal to open versus protected registration. Since spec is = silent on creation of initial access token generation, it is hard to see = what qualifies the initial access token but not software = statement.

2)      Software = statement is a signed/ MACed statement of a subset (or none, since they = are all optional) of client meta data but not the client software = itself. So question is do I have any protection if the client software = itself is modified maliciously (even though the metadata is still the = same)?  

 =

Thanks in = advance,

Madjid=

 =

_________________________________________________=

Madjid = Nakhjiri | Technical = Director, Security Architect=

Samsung SDS Research America=

 

------=_NextPart_000_0098_01CF9549.31CEC760-- From nobody Tue Jul 1 17:53:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E981B2791 for ; Tue, 1 Jul 2014 17:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZT-If2vUWij for ; Tue, 1 Jul 2014 17:53:01 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3B31B2794 for ; Tue, 1 Jul 2014 17:52:44 -0700 (PDT) X-AuditID: 1209190d-f79c06d000002f07-04-53b357dbbd4f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id C3.52.12039.BD753B35; Tue, 1 Jul 2014 20:52:43 -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 s620qgPp026630; Tue, 1 Jul 2014 20:52:42 -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 s620qYhH013382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 Jul 2014 20:52:40 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_AE8BF98F-1136-4DAA-8BE1-A7327E7B66C1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Justin Richer In-Reply-To: <009701cf9583$de2d9f60$9a88de20$%nakhjiri@samsung.com> Date: Tue, 1 Jul 2014 20:52:32 -0400 Message-Id: References: <004601cf9575$0f23f240$2d6bd6c0$%nakhjiri@samsung.com> <901D7016-9135-4B11-8D1F-8D204313F8F2@ve7jtb.com> <009701cf9583$de2d9f60$9a88de20$%nakhjiri@samsung.com> To: Madjid Nakhjiri X-Mailer: Apple Mail (2.1878.2) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGKsWRmVeSWpSXmKPExsUixG6nrns7fHOwwaGH4ha9DUsYLU6+fcVm sfruXzYHZo8lS34yefRtWcXocfv2RpYA5igum5TUnMyy1CJ9uwSujIVTJ7AUPLzKWNF05R5r A+OfnYxdjJwcEgImEmcnz2eFsMUkLtxbz9bFyMUhJDCbSeLO7dcsIAkhgQ2MEvdblCESN5gk FhxuZQRxmAUmMUo0z+xlAqniFTCQuNa/HmyssICRREN/PzOIzSagKjF/5S2wGk4BZ4knG6aw g9gsAioSLWuXgtnMQGfsWtTNDjHHSqLnx0Z2iG2rGSVmrr4LNJSDQ0RAR6J9RxrEqfISM9pP sE9gFJiF7I5ZSO6YBTY3SeL5hUZ2CFtbYtnC18wQtoHE085XrJji+hJv3s1hgrDlJba/nQMV t5RYPPMGC4RtK3GrbwFUjZ3Eo2mLWBcwcq9ilE3JrdLNTczMKU5N1i1OTszLSy3SNdLLzSzR S00p3cQIikJOSd4djO8OKh1iFOBgVOLhZbi9KViINbGsuDL3EKMkB5OSKG+S6+ZgIb6k/JTK jMTijPii0pzU4kOMKkC7Hm1YfYFRiiUvPy9VSYQ3ngeojjclsbIqtSgfpkyag0VJnPettVWw kEB6YklqdmpqQWoRTFaGg0NJgpcRmISEBItS01Mr0jJzShDSTBychxglOHiAhv8OAxleXJCY W5yZDpE/xagoJc77ASQhAJLIKM2D64Ulz1eM4kBvCfM6g6zgASZeuO5XQIOZgAZ/XbUBZHBJ IkJKqoFxPX9qnwMH+4HzeS+ntaw7LBtofSc6rthY0e/LzU+R3c95P1+PtJRQW9fy5l//jcjw ObzRXdJ6rNsbBY8bu0zplU+y+iE436RrY67Rip9qpyZbez6Y+HLy6cOcMv4PoxZGPlrw6pqo eV6vQfcSvs+c5cmxFc/36aw67nxRZatw8daTTnMjN4orsRRnJBpqMRcVJwIA48Y/Z3kDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/C2Xq2cPhfQcB8eOxtO9uZl5cnyA Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic registration draft 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, 02 Jul 2014 00:53:08 -0000 --Apple-Mail=_AE8BF98F-1136-4DAA-8BE1-A7327E7B66C1 Content-Type: multipart/alternative; boundary="Apple-Mail=_71053476-08C6-4FDE-96DC-DBE1B9C84F09" --Apple-Mail=_71053476-08C6-4FDE-96DC-DBE1B9C84F09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 That=92s correct: if other apps on the device can steal the client=92s = secrets, then they can impersonate the client even if it=92s dynamically = registered. However, in that case, other apps can probably just steal = the client=92s tokens directly, or its private keys, or just the data = after the client=92s done all the hard work. All of these would be bad, = too, and all of them require some form of protected storage or trust on = the device itself. The difference is that different copies of an app get = different secret keys, so you can at least limit impersonation to a = given environment. I=92ll also note that even possession of a signed software statement = doesn=92t authenticate a client to be a particular piece of software. = However, if used correctly, it could allow a client publisher to lock = down a large set of client information (redirect URIs, display name, = auth type, etc) so that any impersonating client is going to have to be = able to act just like the real client.=20 Also, keep in mind that ability to register with an auth server does not = constitute access to data: a user still has to authorize the client = application and it has to fetch and later present a valid token. =97 Justin On Jul 1, 2014, at 7:26 PM, Madjid Nakhjiri = wrote: > Hi John, > =20 > Thanks again for your answer. Ok, so we agree that the =93eve=94 app = can take the secret out of the =93bob=94 app. This is a matter of = security robustness on the device and whether different applications = running on the same OS on the same device have access to each other=92s = data, even if you use unique ID and secrets. So, I still don=92t = understand how dynamic registration prevents other apps on the device = from knowing the client secret? (i.e. qualifying the client as = confidential?) > =20 > On the software verification, I agree with you on the need for OS or = MDM verification, unless signature verification can be done remotely, = which is also hard. > =20 > On initial access token, are you saying that is for server side = clients, mostly? > On the device side clients (native apps) I see your point about the = need for trusted =93proxy=94 on the device to provide the out of band = element. > =20 > Madjid > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Tuesday, July 01, 2014 3:06 PM > To: Madjid Nakhjiri > Cc: oauth@ietf.org > Subject: Re: Dynamic registration draft > =20 > With native applications the response from the Authorization server = can be intercepted by other applications on the device. =20 > This is a known attack. If the intercepting application knows the = client_id and client_secret of the legitimate application it can = exchange the code for access and or refresh tokens. > =20 > Dynamic registration prevents other applications on the device from = knowing the client secret. This protects against some attacks. > =20 > No you have no way to know if it is the legitimate application that is = registering. The only way to do that is with some OS or MDM resident = code that validates the applications signature. > =20 > The software statement allows a software publisher to bundle a set of = configuration options together, and be known by the AS as coming from = that publisher, however it is still self asserted and doesn't=20 > guarantee the software registering is legitimate. > =20 > The initial access token enables the out of band trust relationship. = It works well with web clients that may register out of band proving who = they are and agreeing to terms of service, and then receving a access = token to do the automated registration. > =20 > For a native application on a device this might be possible if there = is device management software that could push a bootstrap access token = to the application to do the registration. > =20 > John B. > =20 > On Jul 1, 2014, at 5:40 PM, Madjid Nakhjiri = wrote: >=20 >=20 > Hi all, John, > =20 > So I reviewed the oauth-dyn-reg-17 with the goal of finding more info = on the following statement in your previous email > =20 > =93Since the publishing of this RFC we have also developed a spec for = dynamic client registration so it is possible to give every native = client it's own client_id and secret making them confidential clients.=94 > =20 > If I understand the draft correctly, you can turn a native client from = public to confidential only if the following is true: > =20 > 1) The client must be able to dynamically register with the = registration endpoint and download an instance-specific client ID and a = temporary (=93expirable=94) client secret on the fly. > 2) Although the client cannot maintain the secrecy of any secrets = packaged within client software, it needs to be able to maintain the = secrecy of a per-instance client secret. > =20 > So here are my questions: I am not quite sure what provides the trust = in this scenario. The client is using a secret that it was just given by = the registration end point (essentially hosted by authorization server?) = to authenticate to the same authorization server? Unless an out of band = trust relationship was used (initial access token??), we don=92t have = any additional trust in client or its ability to hold secrets. The only = added benefit by dynamic registration in the way of above is that (as I = see it), because the ID and secret are instance specific, their = compromise only leads to the compromise of just that client and just = that user=92s data, rather than the entire populations. Or the point is = that we are saying there are clients/scenarios that can be trusted with = short term secrets but not long term secrets? > =20 > Am I missing something? > =20 > I could see that if we had required an out of band trust relationship, = for instance requirement of a protected dynamic registration (use of = initial access token that is client instance specific), not sure how the = two above helps an individual user? > =20 > =20 > My other comment regarding the drafts are as follows: > 1) The draft is somewhat asymmetric with respect to the use of = software statement versus initial access token. Although, the specs says = that they are both choices of methods of attestations, only Initial = access token is required for protected registration, while software = statement is declared orthogonal to open versus protected registration. = Since spec is silent on creation of initial access token generation, it = is hard to see what qualifies the initial access token but not software = statement. > 2) Software statement is a signed/ MACed statement of a subset = (or none, since they are all optional) of client meta data but not the = client software itself. So question is do I have any protection if the = client software itself is modified maliciously (even though the metadata = is still the same)? =20 > =20 > Thanks in advance, > Madjid > =20 > _________________________________________________ > Madjid Nakhjiri | Technical Director, Security Architect > Samsung SDS Research America > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_71053476-08C6-4FDE-96DC-DBE1B9C84F09 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 That=92s= correct: if other apps on the device can steal the client=92s secrets, = then they can impersonate the client even if it=92s dynamically = registered. However, in that case, other apps can probably just steal = the client=92s tokens directly, or its private keys, or just the data = after the client=92s done all the hard work. All of these would be bad, = too, and all of them require some form of protected storage or trust on = the device itself. The difference is that different copies of an app get = different secret keys, so you can at least limit impersonation to a = given environment.

I=92ll also note that even = possession of a signed software statement doesn=92t authenticate a = client to be a particular piece of software. However, if used correctly, = it could allow a client publisher to lock down a large set of client = information (redirect URIs, display name, auth type, etc) so that any = impersonating client is going to have to be able to act just like the = real client. 

Also, keep in mind that = ability to register with an auth server does not constitute access to = data: a user still has to authorize the client application and it has to = fetch and later present a valid token.

 =97 = Justin


On Jul 1, 2014, at 7:26 = PM, Madjid Nakhjiri <m.nakhjiri@samsung.com> = wrote:

Hi John,

 

Thanks again for your answer. Ok, so we agree that = the =93eve=94 app can take the secret out of the =93bob=94 app. This is = a matter of security robustness on the device and whether different = applications running on the same OS on the same device have access to = each other=92s data, even if you use unique ID and secrets. So, I still = don=92t understand how dynamic registration prevents other apps on the = device from knowing the client secret? (i.e. qualifying the client as = confidential?)

 

On the software verification, I agree with you on = the need for OS or MDM verification, unless signature verification can = be done remotely, which is also hard.

 

On initial access token, are you saying that is = for server side clients, mostly?

On the device side clients (native apps) I see = your point about the need for trusted =93proxy=94 on the device to = provide the out of band element.

 

Madjid

From: John Bradley [mailto:ve7jtb@ve7jtb.com] =
Sent: Tuesday, July 01, 2014 3:06 PM
To: Madjid = Nakhjiri
Cc: oauth@ietf.org
Subject: Re: = Dynamic registration draft

 

With = native applications the response from the Authorization server can be = intercepted by other applications on the device. =  

This is a known attack. =   If the intercepting application knows the client_id and = client_secret of the legitimate application it can exchange the code for = access and or refresh tokens.

 

Dynamic registration prevents other applications on = the device from knowing the client secret.  This protects against = some attacks.

 

No you have no way to know if it is the legitimate = application that is registering.   The only way to do that is with = some OS or MDM resident code that validates the applications = signature.

 

The software statement allows a software publisher = to bundle a set of configuration options together,  and be known by = the AS as coming from that publisher, however it is still self asserted = and doesn't 

guarantee the software registering is = legitimate.

 

The initial access token enables the out of band = trust relationship.   It works well with web clients that may = register out of band proving who they are and agreeing to terms of = service, and then receving a access token to do the automated = registration.

 

For a native application on a device this might be = possible if there is device management software that could push a = bootstrap access token to the application to do the = registration.

 

John B.

 

On Jul 1, 2014, at 5:40 PM, Madjid Nakhjiri <m.nakhjiri@samsung.com> = wrote:



Hi all, John,

 

So I reviewed the oauth-dyn-reg-17 with the goal of finding more = info on the following statement in your previous = email

 

=93Since the publishing of this RFC we have also developed a = spec for dynamic client registration so it is possible to give every = native client it's own client_id and secret making them confidential = clients.=94

 

If I understand the draft correctly, you can turn a native = client from public to confidential only if the following is = true:

 

1)      The client must be able to dynamically register with the = registration endpoint and download an instance-specific client ID and a = temporary (=93expirable=94) client secret on the = fly.

2)      Although the client cannot maintain the secrecy of any secrets = packaged within client software, it needs to be able to maintain the = secrecy of a per-instance client = secret.

 

So here are my questions: I am not quite sure what provides the = trust in this scenario. The client is using a secret that it was just = given by the registration end point (essentially hosted by authorization = server?) to authenticate to the same authorization server? Unless an out = of band trust relationship was used (initial access token??), we don=92t = have any additional trust in client or its ability to hold secrets. The = only added benefit by dynamic registration in the way of above is that = (as I see it), because the ID and secret are instance specific, their = compromise only leads to the compromise of just that client and just = that user=92s data, rather than the entire populations. Or the point is = that we are saying there are clients/scenarios that can be trusted with = short term secrets but not long term = secrets?

 

Am I missing something?

 

I could see that if we had required an out of band trust = relationship, for instance requirement of a protected dynamic = registration (use of initial access token that is client instance = specific), not sure how the two above helps an individual = user?

 

 

My other comment regarding the drafts are as = follows:

1)      The draft is somewhat asymmetric with respect to the use of = software statement versus initial access token. Although, the specs says = that they are both choices of methods of attestations, only Initial = access token is required for protected registration, while software = statement is declared orthogonal to open versus protected registration. = Since spec is silent on creation of initial access token generation, it = is hard to see what qualifies the initial access token but not software = statement.

2)      Software statement is a signed/ MACed statement of a subset (or = none, since they are all optional) of client meta data but not the = client software itself. So question is do I have any protection if the = client software itself is modified maliciously (even though the metadata = is still the same)?  

 

Thanks in advance,

Madjid

 

_________________________________________________

Madjid Nakhjiri | Technical Director, Security Architect

Samsung SDS Research America

 

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

= --Apple-Mail=_71053476-08C6-4FDE-96DC-DBE1B9C84F09-- --Apple-Mail=_AE8BF98F-1136-4DAA-8BE1-A7327E7B66C1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTs1fQAAoJEDPAngkbd+w908QH/j0NTIlScDdzjqdEmYXFKG73 jDiHJklvNmmtHiv26dygPe6sNTQl/CH41zjFbBooTu5sOWjpzBTtsSXdqsH/ZSmc P9FxEdm6xxRU7rtsg3Us4yYQeXxYyw2pyNNf5wLH4Og3Lgwut8RMe42DaC94j+aC kWbjngS4bxkDcI2iJpzj/eIFMSCSZawqYStwcAy80akzjPiFn8nvrBGApUx1MRCD AKhG9gtJ4dtNnbdDSW1Fj2bkE5TqTPYBQHxQQwLYJeC4BAagmg0ngaWKJJovlLMQ /b856a4QhxpbeGhUrt7CFzsKeG2NG2m+5s/t59L23ErjyNrQDn+0m7OotUKyJu8= =SXlK -----END PGP SIGNATURE----- --Apple-Mail=_AE8BF98F-1136-4DAA-8BE1-A7327E7B66C1-- From nobody Tue Jul 1 17:57:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1455B1A0444; Tue, 1 Jul 2014 17:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fh_Rk5t7Xr_s; Tue, 1 Jul 2014 17:57:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D8E1B2797; Tue, 1 Jul 2014 17:57:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140702005740.13595.12883.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 17:57:40 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Qh0GS5FZNPvK2zFM5G8f2ZkA3wM Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-24.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 00:57:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : JSON Web Token (JWT) Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-24.txt Pages : 32 Date : 2014-07-01 Abstract: JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. The suggested pronunciation of JWT is the same as the English word "jot". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-24 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-24 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 1 18:07:32 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B001B2794 for ; Tue, 1 Jul 2014 18:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.55 X-Spam-Level: X-Spam-Status: No, score=-7.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIdoeSmS-qXy for ; Tue, 1 Jul 2014 18:07:24 -0700 (PDT) Received: from usmailout2.samsung.com (mailout2.w2.samsung.com [211.189.100.12]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C081A006C for ; Tue, 1 Jul 2014 18:07:23 -0700 (PDT) Received: from uscpsbgm1.samsung.com (u114.gpu85.samsung.co.kr [203.254.195.114]) by mailout2.w2.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N8200JSF8GALE50@mailout2.w2.samsung.com> for oauth@ietf.org; Tue, 01 Jul 2014 21:07:22 -0400 (EDT) X-AuditID: cbfec372-b7fe76d00000687e-5c-53b35b4a5515 Received: from ussync1.samsung.com ( [203.254.195.81]) by uscpsbgm1.samsung.com (USCPMTA) with SMTP id EC.63.26750.A4B53B35; Tue, 01 Jul 2014 21:07:22 -0400 (EDT) Received: from sdsamadjidPC ([105.66.230.137]) by ussync1.samsung.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0N82006DO8G8JA20@ussync1.samsung.com>; Tue, 01 Jul 2014 21:07:22 -0400 (EDT) From: Madjid Nakhjiri To: 'Justin Richer' References: <004601cf9575$0f23f240$2d6bd6c0$%nakhjiri@samsung.com> <901D7016-9135-4B11-8D1F-8D204313F8F2@ve7jtb.com> <009701cf9583$de2d9f60$9a88de20$%nakhjiri@samsung.com> In-reply-to: Date: Tue, 01 Jul 2014 18:07:20 -0700 Message-id: <00d601cf9591$fa47a6b0$eed6f410$%nakhjiri@samsung.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_00D7_01CF9557.4DE8CEB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Ac+Vj/3sBjn1ArYGRdSLsqQfHCb6rAAATHcA Content-language: en-us X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsVy+t/hQF2v6M3BBv2f2Sw2XHvJanHy7Ss2 i9V3/7I5MHssWfKTyaPpzFFmj9u3N7IEMEdx2aSk5mSWpRbp2yVwZRx/38xU0P+EsaLx4mOW BsZbRxi7GDk5JARMJD40z2WFsMUkLtxbz9bFyMUhJLCEUWLzx8VMIAkhgRYmiZm/zEFsNgE9 if3zZjB3MXJwiAioSvz9yw1iMgukSDSvcoJofcAocfjwYzaQOKeAtcTbg6IgncICRhIdJ3+C rWUB6nzZvI0dxOYVcJL4uH4KC4QtKPFj8j0wm1kgWuLB/6tgmyQE1CUe/dUFCYsAjTmzv5Ud okRcYtKDh+wTGAVnIemehaR7FpKyWWCH6km0bWSECMtLbH87B6pEV+L/cxhbW2LZwtfMCxjZ VzGKlhYnFxQnpeca6hUn5haX5qXrJefnbmKExEfRDsZnG6wOMQpwMCrx8Do83xgsxJpYVlyZ e4hRgoNZSYQ3nmdzsBBvSmJlVWpRfnxRaU5q8SFGJg5OqQZGpS7v/ReVTJ39tgX0ahxgqD31 JtCG8cyeYgHf6tLVfp8/1ibl/eW64BRq2fvJaypDv+3exXfE+aR4jH8IGAmcfvFS0VTKMXde 69kcn6DbDw6+5myzzFI+qyherfeYo/TQ558HLq7STt546s+2uAOTVn34Ylt5h3uNVWdwwesD /avXCuaZpJ5TYinOSDTUYi4qTgQAoHO6iW0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/tBu3X5S4ic4GkKg3sVHMhMmjo4Y Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic registration draft 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, 02 Jul 2014 01:07:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D7_01CF9557.4DE8CEB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Justin for confirming. I was trying to figure out if I could turn the public client into confidential client through this magic, but it does not seem to be possible. If I have critical regulated data for a user exposed as a result of token high jacking, then I am still in trouble whether it is one copy of app or 10,000. As to your last comment below, not sure how the user authorization change the situation: the access token is provided to client AFTER the user provides grant. So another app can grab the token and present it to auth server instead of the legitimate app. Final question is does the OAUTH token or its scope in anyway has anything to do with HTTPS that would protect the data with the resource server? Thanks, Madjid From: Justin Richer [mailto:jricher@MIT.EDU] Sent: Tuesday, July 01, 2014 5:53 PM To: Madjid Nakhjiri Cc: John Bradley; oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic registration draft That's correct: if other apps on the device can steal the client's secrets, then they can impersonate the client even if it's dynamically registered. However, in that case, other apps can probably just steal the client's tokens directly, or its private keys, or just the data after the client's done all the hard work. All of these would be bad, too, and all of them require some form of protected storage or trust on the device itself. The difference is that different copies of an app get different secret keys, so you can at least limit impersonation to a given environment. I'll also note that even possession of a signed software statement doesn't authenticate a client to be a particular piece of software. However, if used correctly, it could allow a client publisher to lock down a large set of client information (redirect URIs, display name, auth type, etc) so that any impersonating client is going to have to be able to act just like the real client. Also, keep in mind that ability to register with an auth server does not constitute access to data: a user still has to authorize the client application and it has to fetch and later present a valid token. - Justin On Jul 1, 2014, at 7:26 PM, Madjid Nakhjiri wrote: Hi John, Thanks again for your answer. Ok, so we agree that the "eve" app can take the secret out of the "bob" app. This is a matter of security robustness on the device and whether different applications running on the same OS on the same device have access to each other's data, even if you use unique ID and secrets. So, I still don't understand how dynamic registration prevents other apps on the device from knowing the client secret? (i.e. qualifying the client as confidential?) On the software verification, I agree with you on the need for OS or MDM verification, unless signature verification can be done remotely, which is also hard. On initial access token, are you saying that is for server side clients, mostly? On the device side clients (native apps) I see your point about the need for trusted "proxy" on the device to provide the out of band element. Madjid From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Tuesday, July 01, 2014 3:06 PM To: Madjid Nakhjiri Cc: oauth@ietf.org Subject: Re: Dynamic registration draft With native applications the response from the Authorization server can be intercepted by other applications on the device. This is a known attack. If the intercepting application knows the client_id and client_secret of the legitimate application it can exchange the code for access and or refresh tokens. Dynamic registration prevents other applications on the device from knowing the client secret. This protects against some attacks. No you have no way to know if it is the legitimate application that is registering. The only way to do that is with some OS or MDM resident code that validates the applications signature. The software statement allows a software publisher to bundle a set of configuration options together, and be known by the AS as coming from that publisher, however it is still self asserted and doesn't guarantee the software registering is legitimate. The initial access token enables the out of band trust relationship. It works well with web clients that may register out of band proving who they are and agreeing to terms of service, and then receving a access token to do the automated registration. For a native application on a device this might be possible if there is device management software that could push a bootstrap access token to the application to do the registration. John B. On Jul 1, 2014, at 5:40 PM, Madjid Nakhjiri wrote: Hi all, John, So I reviewed the oauth-dyn-reg-17 with the goal of finding more info on the following statement in your previous email "Since the publishing of this RFC we have also developed a spec for dynamic client registration so it is possible to give every native client it's own client_id and secret making them confidential clients." If I understand the draft correctly, you can turn a native client from public to confidential only if the following is true: 1) The client must be able to dynamically register with the registration endpoint and download an instance-specific client ID and a temporary ("expirable") client secret on the fly. 2) Although the client cannot maintain the secrecy of any secrets packaged within client software, it needs to be able to maintain the secrecy of a per-instance client secret. So here are my questions: I am not quite sure what provides the trust in this scenario. The client is using a secret that it was just given by the registration end point (essentially hosted by authorization server?) to authenticate to the same authorization server? Unless an out of band trust relationship was used (initial access token??), we don't have any additional trust in client or its ability to hold secrets. The only added benefit by dynamic registration in the way of above is that (as I see it), because the ID and secret are instance specific, their compromise only leads to the compromise of just that client and just that user's data, rather than the entire populations. Or the point is that we are saying there are clients/scenarios that can be trusted with short term secrets but not long term secrets? Am I missing something? I could see that if we had required an out of band trust relationship, for instance requirement of a protected dynamic registration (use of initial access token that is client instance specific), not sure how the two above helps an individual user? My other comment regarding the drafts are as follows: 1) The draft is somewhat asymmetric with respect to the use of software statement versus initial access token. Although, the specs says that they are both choices of methods of attestations, only Initial access token is required for protected registration, while software statement is declared orthogonal to open versus protected registration. Since spec is silent on creation of initial access token generation, it is hard to see what qualifies the initial access token but not software statement. 2) Software statement is a signed/ MACed statement of a subset (or none, since they are all optional) of client meta data but not the client software itself. So question is do I have any protection if the client software itself is modified maliciously (even though the metadata is still the same)? Thanks in advance, Madjid _________________________________________________ Madjid Nakhjiri | Technical Director, Security Architect Samsung SDS Research America _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_NextPart_000_00D7_01CF9557.4DE8CEB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Justin for confirming. I was trying to figure out if I could = turn the public client into confidential client through this magic, but = it does not seem to be possible. If I have critical regulated data for a = user exposed as a result of token high jacking, then I am still in = trouble whether it is one copy of app or 10,000. As to your last comment = below, not sure how the user authorization change the situation: the = access token is provided to client AFTER the user provides grant. So = another app can grab the token and present it to auth server instead of = the legitimate app.

 

Final question is does the OAUTH token or its scope in anyway has = anything to do with HTTPS that would protect the data with the resource = server?

 

Thanks,

Madjid

 

From:= = Justin Richer [mailto:jricher@MIT.EDU]
Sent: Tuesday, July = 01, 2014 5:53 PM
To: Madjid Nakhjiri
Cc: John = Bradley; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic = registration draft

 

That’s = correct: if other apps on the device can steal the client’s = secrets, then they can impersonate the client even if it’s = dynamically registered. However, in that case, other apps can probably = just steal the client’s tokens directly, or its private keys, or = just the data after the client’s done all the hard work. All of = these would be bad, too, and all of them require some form of protected = storage or trust on the device itself. The difference is that different = copies of an app get different secret keys, so you can at least limit = impersonation to a given environment.

 

I’ll also note that even possession of a signed = software statement doesn’t authenticate a client to be a = particular piece of software. However, if used correctly, it could allow = a client publisher to lock down a large set of client information = (redirect URIs, display name, auth type, etc) so that any impersonating = client is going to have to be able to act just like the real = client. 

 

Also, keep in mind that ability to register with an = auth server does not constitute access to data: a user still has to = authorize the client application and it has to fetch and later present a = valid token.

 

 — Justin

 

 

On = Jul 1, 2014, at 7:26 PM, Madjid Nakhjiri <m.nakhjiri@samsung.com> = wrote:



Hi John,

 

Thanks again for your answer. Ok, so we agree that the = “eve” app can take the secret out of the “bob” = app. This is a matter of security robustness on the device and whether = different applications running on the same OS on the same device have = access to each other’s data, even if you use unique ID and = secrets. So, I still don’t understand how dynamic registration = prevents other apps on the device from knowing the client secret? (i.e. = qualifying the client as confidential?)

 

On the software verification, I agree with you on the need for OS or = MDM verification, unless signature verification can be done remotely, = which is also hard.

 

On initial access token, are you saying that is for server side = clients, mostly?

On the device side clients (native apps) I see your point about the = need for trusted “proxy” on the device to provide the out of = band element.

 

Madjid

From:= = John Bradley [mailto:ve7jtb@ve7jtb.com] =
Sent: Tuesday, July 01, 2014 3:06 PM
To: Madjid = Nakhjiri
Cc: oauth@ietf.org
Subject: Re: = Dynamic registration draft

 

With native = applications the response from the Authorization server can be = intercepted by other applications on the device. =  

This is a known attack. =   If the intercepting application knows the client_id and = client_secret of the legitimate application it can exchange the code for = access and or refresh tokens.

 

Dynamic registration prevents other applications on = the device from knowing the client secret.  This protects against = some attacks.

 

No you have no way to know if it is the legitimate = application that is registering.   The only way to do that is with = some OS or MDM resident code that validates the applications = signature.

 

The software statement allows a software publisher to = bundle a set of configuration options together,  and be known by = the AS as coming from that publisher, however it is still self asserted = and doesn't 

guarantee the software registering is = legitimate.

 

The initial access token enables the out of band trust = relationship.   It works well with web clients that may register = out of band proving who they are and agreeing to terms of service, and = then receving a access token to do the automated = registration.

 

For a native application on a device this might be = possible if there is device management software that could push a = bootstrap access token to the application to do the = registration.

 

John B.

 

On = Jul 1, 2014, at 5:40 PM, Madjid Nakhjiri <m.nakhjiri@samsung.com> = wrote:




Hi all, = John,

 

So I = reviewed the oauth-dyn-reg-17 with the goal of finding more info on the = following statement in your previous = email

 

“Sinc= e the publishing of this RFC we have also developed a spec for dynamic = client registration so it is possible to give every native client it's = own client_id and secret making them confidential = clients.”

 

If I = understand the draft correctly, you can turn a native client from public = to confidential only if the following is = true:

 

1)      The client = must be able to dynamically register with the registration endpoint and = download an instance-specific client ID and a temporary = (“expirable”) client secret on the = fly.

2)      Although = the client cannot maintain the secrecy of any secrets packaged within = client software, it needs to be able to maintain the secrecy of a = per-instance client secret.

 

So here = are my questions: I am not quite sure what provides the trust in this = scenario. The client is using a secret that it was just given by the = registration end point (essentially hosted by authorization server?) to = authenticate to the same authorization server? Unless an out of band = trust relationship was used (initial access token??), we don’t = have any additional trust in client or its ability to hold secrets. The = only added benefit by dynamic registration in the way of above is that = (as I see it), because the ID and secret are instance specific, their = compromise only leads to the compromise of just that client and just = that user’s data, rather than the entire populations. Or the point = is that we are saying there are clients/scenarios that can be trusted = with short term secrets but not long term = secrets?

 

Am I = missing something?

 

I could = see that if we had required an out of band trust relationship, for = instance requirement of a protected dynamic registration (use of initial = access token that is client instance specific), not sure how the two = above helps an individual user?

 

 

My other = comment regarding the drafts are as = follows:

1)      The draft = is somewhat asymmetric with respect to the use of software statement = versus initial access token. Although, the specs says that they are both = choices of methods of attestations, only Initial access token is = required for protected registration, while software statement is = declared orthogonal to open versus protected registration. Since spec is = silent on creation of initial access token generation, it is hard to see = what qualifies the initial access token but not software = statement.

2)      Software = statement is a signed/ MACed statement of a subset (or none, since they = are all optional) of client meta data but not the client software = itself. So question is do I have any protection if the client software = itself is modified maliciously (even though the metadata is still the = same)?  

 

Thanks in = advance,

Madjid

 

_________________________________________________

Madjid = Nakhjiri | Technical = Director, Security Architect

Samsung SDS Research = America

 

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

 

------=_NextPart_000_00D7_01CF9557.4DE8CEB0-- From nobody Tue Jul 1 18:12:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245E51A006C for ; Tue, 1 Jul 2014 18:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhqmL8u5SNKa for ; Tue, 1 Jul 2014 18:12:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A051B2799 for ; Tue, 1 Jul 2014 18:12:09 -0700 (PDT) Received: from DM2PR03CA001.namprd03.prod.outlook.com (10.141.52.149) by BLUPR03MB133.namprd03.prod.outlook.com (10.255.212.11) with Microsoft SMTP Server (TLS) id 15.0.974.11; Wed, 2 Jul 2014 01:12:07 +0000 Received: from BN1AFFO11FD018.protection.gbl (2a01:111:f400:7c10::100) by DM2PR03CA001.outlook.office365.com (2a01:111:e400:2414::21) with Microsoft SMTP Server (TLS) id 15.0.980.8 via Frontend Transport; Wed, 2 Jul 2014 01:12:07 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD018.mail.protection.outlook.com (10.58.52.78) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Wed, 2 Jul 2014 01:12:06 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0195.002; Wed, 2 Jul 2014 01:11:30 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five Thread-Index: Ac+Vkn9Qxw7nsFWXQgqBEB8Y2w/8RgAAAcxw Date: Wed, 2 Jul 2014 01:11:30 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD95D0F@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD95D0FTK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(377454003)(189002)(199002)(86612001)(84326002)(85852003)(15202345003)(79102001)(16297215004)(19625215002)(83072002)(16236675004)(2656002)(85306003)(74502001)(76482001)(84676001)(86362001)(19300405004)(92726001)(92566001)(77982001)(77096002)(81542001)(80022001)(66066001)(46102001)(95666004)(81342001)(26826002)(54356999)(50986999)(87936001)(83322001)(19580395003)(20776003)(64706001)(55846006)(19580405001)(68736004)(44976005)(97736001)(104016002)(2351001)(107046002)(107886001)(21056001)(106466001)(33656002)(512954002)(71186001)(99396002)(6806004)(15975445006)(69596002)(31966008)(74662001)(81156004)(4396001)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB133; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0260457E99 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TCtmigA1YxiLUJ9BFlYaW1qkKzc Subject: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five 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, 02 Jul 2014 01:12:12 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD95D0FTK5EX14MBXC294r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Mike Jones Sent: Tuesday, July 01, 2014 6:11 PM To: jose@ietf.org Subject: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spe= c of five JOSE -30 and JWT -24 drafts have been posted incorporating improvements res= ulting from Kathleen Moriarty's JWE review. At this point, actions request= ed in her reviews of the JWS, JWE, JWK, JWA, and JWT specifications have al= l been incorporated. All changes in this release were strictly editorial i= n nature. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-30 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-30 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-30 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-30 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-24 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-3= 0.html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-= 30.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-30.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-= 30.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-24.h= tml -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1245 and = as @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439AD95D0FTK5EX14MBXC294r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Mike Jon= es
Sent: Tuesday, July 01, 2014 6:11 PM
To: jose@ietf.org
Subject: JOSE -30 and JWT -24 drafts incorporating AD feedback on fi= fth spec of five

 

JOSE -30 and JWT -24 drafts have been posted incorpo= rating improvements resulting from Kathleen Moriarty’s JWE review.&nb= sp; At this point, actions requested in her reviews of the JWS, JWE, JWK, J= WA, and JWT specifications have all been incorporated.  All changes in this release were strictly editorial in nature.<= /p>

 

The specifications are available at:

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

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

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

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

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

 

HTML formatted versions are available at:=

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

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

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

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

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

 

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

 

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

--_000_4E1F6AAD24975D4BA5B16804296739439AD95D0FTK5EX14MBXC294r_-- From nobody Wed Jul 2 07:07:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1588F1A00E8 for ; Wed, 2 Jul 2014 07:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRCGfc4f-UXU for ; Wed, 2 Jul 2014 07:07:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0C91A0102 for ; Wed, 2 Jul 2014 07:07:02 -0700 (PDT) Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MWPOI-1X9aDW0qyY-00Xg2l for ; Wed, 02 Jul 2014 16:07:00 +0200 Message-ID: <53B41202.8080008@gmx.net> Date: Wed, 02 Jul 2014 16:06:58 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mjQcbDuUIPhErPqqX7Usw8oQiksWJGrd4" X-Provags-ID: V03:K0:BWkTVbUPy0TGIZxg1tsacqhFtzaYxPwpWIYxpJ/M6Q0GKm5726P mxI7lOKg3evU4DtO8rgvpAHtZmOF9Fe+bP93HkpDp5ODwO1553LSr/zJXatqfNLM+4BswwJ b7I9pRtcntWmR/Hltx1TA1/futrnf/oQxpzC1SKjQiZf2ZY4cdyMEepfHgHX0U+qgHf8LCD zzrItt9G+KT79ZYwB7R8w== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/OCB4RFZfIXHsfgjoZkDxmqnqMRA Subject: [OAUTH-WG] Agenda requests, please 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, 02 Jul 2014 14:07:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mjQcbDuUIPhErPqqX7Usw8oQiksWJGrd4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, by next Monday we have to post a draft agenda for the upcoming IETF meeting. If you would like to talk about a specific topic, please let us know. My impression regarding the status of our work is the following: -------- Current WG items ------- * Dynamic Client Registration We are waiting for an update but the document could be completed by the IETF meeting. =3D=3D> no presentation time. * JWT Currently in IESG processing and a new draft update has just been submitted. =3D=3D> no presentation time (#) * Assertion Bundle Currently in IESG processing. =3D=3D> no presentation time (#) * Dynamic Client Registration Management Protocol We had a discussion about this work at the last IETF meeting and the path forward looked somewhat difficult. Nothing has happened since that time and I am inclined to remove it from the list of WG items. * Proof-of-Possession Security We have several new documents and I hope we can turn into working group items already before the meeting. We would then use the meeting time to discuss open issues. #: No presentation time unless some challenging comments from the IESG surface. -------- Proposed New WG items ------- I would also like to put the following items on the agenda. * Token Introspection * draft-sakimura-oauth-tcse-03=09 -------- Other items ------- Phil might want to bring up this item since it was discussed on the list: draft-hunt-oauth-v2-user-a4c Other ideas/suggestions? Ciao Hannes --mjQcbDuUIPhErPqqX7Usw8oQiksWJGrd4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTtBICAAoJEGhJURNOOiAtBrgH/1+6Z4TjNilC4aQVAlU9VZLb IqNeths9OW7N5RiYl0bjEg/qD3LcB8zoCXOFwvVLC273GCc38LPH61YtMsAzN+Em i603TlwUKcisVJaka5cRJr+sWMQ12hDw/FQSNykPYWGelZQOlMD2MH8xQXpEbZrx Rn8/mepB33fUEfAvQ+YtOM6Udm8D5QNMz/17jiZ+DTVk4gW09h0OWfhjHIEkb2Hk VkpOH59X7rXKAWdDzYP7njh7HEV3q7/My1vvqO1lDlbmAXjzWL4Vd0pmNNtzmw1+ gJe0VbRkSD3x1v5J5K2FBlKRnI9jE2yOVWv17BQHh+6aF3HDIuhgsNPzhwOoYBY= =bL18 -----END PGP SIGNATURE----- --mjQcbDuUIPhErPqqX7Usw8oQiksWJGrd4-- From nobody Wed Jul 2 07:10:49 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346111A0143 for ; Wed, 2 Jul 2014 07:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtzkb39MKrYe for ; Wed, 2 Jul 2014 07:10:44 -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 3B6681A0065 for ; Wed, 2 Jul 2014 07:10:44 -0700 (PDT) Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MY4Ls-1X6pKk0pdo-00UvlL for ; Wed, 02 Jul 2014 16:10:42 +0200 Message-ID: <53B412E0.1010400@gmx.net> Date: Wed, 02 Jul 2014 16:10:40 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4qhChtINamIa6q85p9kXs94Osw1aIPSCe" X-Provags-ID: V03:K0:JDTmaKkCq0yNRWL/Qg7qumXIexq2vEOkdR6Ok1yE2PaHWsofR3o 07kFLELXit03vVHjtLLb/SDEDjzUDItXY6jAVbYy3S45EjzfPavwnJmGfUpV5hgmCFF4kJX drschNo53C0fJkbnJdzlmo4/vjYBBC60ah7YVcHl8Oh4/eeOgVb+Ypafqr2QFzybjH4rzRP 8/VWNzAuWJu9AIpuxr2Fg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/QjLt5tc_eKMsooPjA2TI0yrfaqQ Subject: [OAUTH-WG] Draft Submission Deadline Approaching! 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, 02 Jul 2014 14:10:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4qhChtINamIa6q85p9kXs94Osw1aIPSCe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, please also consider the draft submission deadline, which is this Friday by UTC 23:59. Ciao Hannes --4qhChtINamIa6q85p9kXs94Osw1aIPSCe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTtBLgAAoJEGhJURNOOiAt9csIAJKTltxlD3QAlMyp7yK3WS2x XI+YLNdTAX8tKZQnEdvSseNwVoE6m0HpRxtLRhIRBzX/bi1RIVJN57+m4eLFfw1/ GlLGDS2zcTxpAfZrDt5OCTPN/Ggb+7yXjxsl5CX6YgNwHraMttIYW5lAU3G1ZS7h nev4nANQ/MPTBkM1QEPdNIPtBg1ZF2iihKNb7FV+w2AQq8RsfwIASk03AFNhdrGL Kks75w6SlK7aZluUUalkrFnlUScl1xedGAty3hQB/MJiBYlS222NS0R5+yUuhxIi bApMYpvAOqhQ2jy0FKqXKgurDnCjOW6E9EBS0iFr1cmakX5DlYRHDeV7GNuPp/k= =dqiR -----END PGP SIGNATURE----- --4qhChtINamIa6q85p9kXs94Osw1aIPSCe-- From nobody Wed Jul 2 07:23:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5D51A0177 for ; Wed, 2 Jul 2014 07:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxMh345dWs_C for ; Wed, 2 Jul 2014 07:23:39 -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 0DC921A016F for ; Wed, 2 Jul 2014 07:23:39 -0700 (PDT) Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MMkgl-1WzrHC0Gr9-008eao for ; Wed, 02 Jul 2014 16:23:37 +0200 Message-ID: <53B415E7.5060109@gmx.net> Date: Wed, 02 Jul 2014 16:23:35 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" References: <53B41202.8080008@gmx.net> In-Reply-To: <53B41202.8080008@gmx.net> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="a7FTWutHwkQmtdc85KcPEpNFsQNocE3dp" X-Provags-ID: V03:K0:FwdI0gr5Tta2d8LzX0yYHFv4p9Zy2AphVRvAJep5ZayR3CB9WIi BQtZVz5zm41j8OrC2XBnYwmDyhS7R9sa0+D+ae04ZaAIeut2XFxkjPDzU4vjuF72iIdo7D5 3A6odtP3jZgShEpOU2TzRMlJS9KAnCpQl0PYFPBwswim475fntR71fFh9kEra9mS1Ufzggi 1b9UmKqTAm0ZCCImhCXtg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CKe3QjVjfh76Hg4KLbzAzrcHcXQ Subject: Re: [OAUTH-WG] Agenda requests, please 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, 02 Jul 2014 14:23:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a7FTWutHwkQmtdc85KcPEpNFsQNocE3dp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Minor addition: In my charter update proposal I had suggested to add - "User Authentication" (for example based on draft-hunt-oauth-v2-user-a4c), and - "Delegation" (for example based on draft-jones-oauth-token-exchange). Hence, it would be good to discuss these items as well. Ciao Hannes On 07/02/2014 04:06 PM, Hannes Tschofenig wrote: > Hi all, >=20 > by next Monday we have to post a draft agenda for the upcoming IETF > meeting. >=20 > If you would like to talk about a specific topic, please let us know. >=20 > My impression regarding the status of our work is the following: >=20 >=20 > -------- Current WG items ------- >=20 > * Dynamic Client Registration >=20 > We are waiting for an update but the document could be completed by the= > IETF meeting. =3D=3D> no presentation time. >=20 > * JWT >=20 > Currently in IESG processing and a new draft update has just been > submitted. =3D=3D> no presentation time (#) >=20 > * Assertion Bundle >=20 > Currently in IESG processing. =3D=3D> no presentation time (#) >=20 > * Dynamic Client Registration Management Protocol >=20 > We had a discussion about this work at the last IETF meeting and the > path forward looked somewhat difficult. Nothing has happened since that= > time and I am inclined to remove it from the list of WG items. >=20 > * Proof-of-Possession Security >=20 > We have several new documents and I hope we can turn into working group= > items already before the meeting. We would then use the meeting time to= > discuss open issues. >=20 > #: No presentation time unless some challenging comments from the IESG > surface. >=20 > -------- Proposed New WG items ------- >=20 > I would also like to put the following items on the agenda. >=20 > * Token Introspection >=20 > * draft-sakimura-oauth-tcse-03=09 >=20 > -------- Other items ------- >=20 > Phil might want to bring up this item since it was discussed on the > list: draft-hunt-oauth-v2-user-a4c >=20 > Other ideas/suggestions? >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --a7FTWutHwkQmtdc85KcPEpNFsQNocE3dp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTtBXnAAoJEGhJURNOOiAtwdQIAJLqDY4GeStnFgZ+0cZEe/85 VQDnpeD55dBb2UOVufb2d6eyI40FOZDIE15RB4GeHfqjS9sSKZxaC1pOU1flsYwg WGzV8L8Em2LM7r4JS6r5NoP57gAAAsWca7LppYm9qfLl7XuhVCX45Wm4sUwvKYiZ 11vPtAoKwOYCoR1fsTwD5/xQ18I6lAI/gCj+hYDnW236CE4/k/PUQG7N30aEUdlz +BrhtLQKItPV6CnHeyNHdkadBesPrY1pkkBw8Uhi+H3XSTbfmuXSejp8f98hoYuS zDVhkFGO54qotImLsSMLNhqk5QlbWaGBRu9rjj40n7wLbgvE50OA61JwUoIGyn4= =GRlG -----END PGP SIGNATURE----- --a7FTWutHwkQmtdc85KcPEpNFsQNocE3dp-- From nobody Wed Jul 2 19:59:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461B31A0545 for ; Wed, 2 Jul 2014 19:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fixxcJAvTn4Q for ; Wed, 2 Jul 2014 19:59:21 -0700 (PDT) Received: from na3sys009aog132.obsmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330881A007B for ; Wed, 2 Jul 2014 19:59:20 -0700 (PDT) Received: from mail-ie0-f170.google.com ([209.85.223.170]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKU7THCOpT7r7u4gNTRmhUvSgOLKLMxYf6@postini.com; Wed, 02 Jul 2014 19:59:21 PDT Received: by mail-ie0-f170.google.com with SMTP id tr6so10317285ieb.29 for ; Wed, 02 Jul 2014 19:59: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:mime-version:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=6px5XgYAHti6oZJBEG3L0zsp/BIwvxrjuB3kupEOuZ8=; b=TUfKy9x8xVeraa9+l/KUsSUp++mYEBYYoh1MLgh7AYpAZBozV7tkNppL89hm1qyUOk A8eK6E+lexaUCUXgzzQMZWOV9oCBGCOK2SY28UrTQwVPaXq8brdDc7z82sb5wAjdbFRj 65IhXkDd4EcKZNjtA2TfpOuX5QjCdbLWidmA+d5QcJ2HgXwP5aN1kgbLA/X6LDJfgSi/ WhW93z9rnpHZsezlpHmZdVRhNsEPmMxUJv+wtFG5BmnTUOP8oxHGp2p9K4gt8EiCSbkh +w7ftYa13xNktYobsEiKQLKonz7rLXSGjCPrfSMk1wHi4biTLwE9n33ayoCnkJ7NEbKm 5KHw== X-Gm-Message-State: ALoCoQlbXa7LveZcTN9s4U7qd9F93PhcbEnR04TwSMOd0ogdZ5Sd57w8G6ODesNYqmHW4UNJ7+et2fs+7eIGxFrOHvzRyD4jBE9F7GLCfj1vUGWc0oAf6tjCySqvVdmbGV1GJOhJQWe6 X-Received: by 10.50.98.100 with SMTP id eh4mr8787848igb.9.1404356360232; Wed, 02 Jul 2014 19:59:20 -0700 (PDT) X-Received: by 10.50.98.100 with SMTP id eh4mr8787839igb.9.1404356360149; Wed, 02 Jul 2014 19:59:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Wed, 2 Jul 2014 19:58:47 -0700 (PDT) From: Brian Campbell Date: Wed, 2 Jul 2014 20:58:47 -0600 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Zlybjv9yeeHXn2xOm8PmAJX6Y10 Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol (was Re: Agenda requests, please) 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, 03 Jul 2014 02:59:27 -0000 Having difficulty finding consensus around a solution isn=E2=80=99t the sam= e thing as lack of interest in a solution. I think it would be very premature to remove the Dynamic Client Registration Management Protocol from the list of WG items. On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig wrote: > > * Dynamic Client Registration Management Protocol > > We had a discussion about this work at the last IETF meeting and the > path forward looked somewhat difficult. Nothing has happened since that > time and I am inclined to remove it from the list of WG items. From nobody Wed Jul 2 20:14:45 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4430A1A0277 for ; Wed, 2 Jul 2014 20:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoGK3A4fW_0O for ; Wed, 2 Jul 2014 20:14:39 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1E11AD6B0 for ; Wed, 2 Jul 2014 20:14:39 -0700 (PDT) X-AuditID: 12074423-f79bf6d000007580-37-53b4ca9e5fe7 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 86.79.30080.E9AC4B35; Wed, 2 Jul 2014 23:14:38 -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 s633EbeC028320 for ; Wed, 2 Jul 2014 23:14:37 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s633Eafu031371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 2 Jul 2014 23:14:37 -0400 Message-ID: <53B4CA95.3020702@mit.edu> Date: Wed, 02 Jul 2014 23:14:29 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: oauth@ietf.org References: <53B41202.8080008@gmx.net> In-Reply-To: <53B41202.8080008@gmx.net> Content-Type: multipart/alternative; boundary="------------090008070704010405010709" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nojvv1JZgg0lr2C1Ovn3F5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujE2LD7MVTNWraG78yd7AuEuli5GTQ0LARGLVvAXsELaYxIV7 69m6GLk4hARmM0lcn7eJEcI5yijx9PACVgjnPZPEhMMXgDIcHLwCahIzF4uBdLMIqEpM2HmF CcRmA7Lnr7wFZosKREncudTPCmLzCghKnJz5hAXEFhEQkni+sw+sRlhAX2LO50tgVwgBjTy1 /zdYPaeAukTHtpNgcWaBMIllT1ayT2Dkn4Vk1CwkqVlAFzELWEt8210EEZaX2P52DjOErS2x qvcsE7L4Aka2VYyyKblVurmJmTnFqcm6xcmJeXmpRbpmermZJXqpKaWbGMEh7KK8g/HPQaVD jAIcjEo8vC9stgQLsSaWFVfmHmKU5GBSEuVN2QAU4kvKT6nMSCzOiC8qzUktPsQowcGsJMI7 fTNQjjclsbIqtSgfJiXNwaIkzvvW2ipYSCA9sSQ1OzW1ILUIJivDwaEkwRt9EqhRsCg1PbUi LTOnBCHNxMEJMpwHaLgjSA1vcUFibnFmOkT+FKOilDjvjxNACQGQREZpHlwvLMW8YhQHekWY 1wGknQeYnuC6XwENZgIa/HXVBpDBJYkIKakGRtOJ6gWy7mf4T20/qX1NrZXZ2Zbrx3Jd54Dl 6/W11kTsEvXaau/5/+wcRda5a08t+V7GsDu3z6VMougf4+x+bWeeXTmdPz7XJfoUmDCt035b v7NC2WRZtWAdwxy2rjjrj29uhhWuPbj37MXDPCskNG2rPeesXvRvNnekXqPvlIJIG769v5S3 KbEUZyQaajEXFScCAMKhq8wMAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SVkm9tqdfoFdOWlD9-sYxcOp-qA Subject: Re: [OAUTH-WG] Agenda requests, please 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, 03 Jul 2014 03:14:42 -0000 This is a multi-part message in MIME format. --------------090008070704010405010709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike is working on editorial updates to the Dynamic Registration core draft, and I and the other editors plan to review the changes soon and we'll get an updated draft published before the deadline this week. I will publish a refreshed Token Introspection individual submission ID for input into the WG discussion before the deadline, and I would like to see this become a WG item. It's already been in deployment with a number of implementations for some time now, and I'm seeing only increasing demand for it. I do not agree that we should drop the Dynamic Registration Management draft from the WG items list. -- Justin On 7/2/2014 10:06 AM, Hannes Tschofenig wrote: > Hi all, > > by next Monday we have to post a draft agenda for the upcoming IETF > meeting. > > If you would like to talk about a specific topic, please let us know. > > My impression regarding the status of our work is the following: > > > -------- Current WG items ------- > > * Dynamic Client Registration > > We are waiting for an update but the document could be completed by the > IETF meeting. ==> no presentation time. > > * JWT > > Currently in IESG processing and a new draft update has just been > submitted. ==> no presentation time (#) > > * Assertion Bundle > > Currently in IESG processing. ==> no presentation time (#) > > * Dynamic Client Registration Management Protocol > > We had a discussion about this work at the last IETF meeting and the > path forward looked somewhat difficult. Nothing has happened since that > time and I am inclined to remove it from the list of WG items. > > * Proof-of-Possession Security > > We have several new documents and I hope we can turn into working group > items already before the meeting. We would then use the meeting time to > discuss open issues. > > #: No presentation time unless some challenging comments from the IESG > surface. > > -------- Proposed New WG items ------- > > I would also like to put the following items on the agenda. > > * Token Introspection > > * draft-sakimura-oauth-tcse-03 > > -------- Other items ------- > > Phil might want to bring up this item since it was discussed on the > list: draft-hunt-oauth-v2-user-a4c > > Other ideas/suggestions? > > Ciao > Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------090008070704010405010709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Mike is working on editorial updates to the Dynamic Registration core draft, and I and the other editors plan to review the changes soon and we'll get an updated draft published before the deadline this week.

I will publish a refreshed Token Introspection individual submission ID for input into the WG discussion before the deadline, and I would like to see this become a WG item. It's already been in deployment with a number of implementations for some time now, and I'm seeing only increasing demand for it.

I do not agree that we should drop the Dynamic Registration Management draft from the WG items list.

 -- Justin

On 7/2/2014 10:06 AM, Hannes Tschofenig wrote:
Hi all,

by next Monday we have to post a draft agenda for the upcoming IETF
meeting.

If you would like to talk about a specific topic, please let us know.

My impression regarding the status of our work is the following:


-------- Current WG items -------

* Dynamic Client Registration

We are waiting for an update but the document could be completed by the
IETF meeting. ==> no presentation time.

* JWT

Currently in IESG processing and a new draft update has just been
submitted. ==> no presentation time (#)

* Assertion Bundle

Currently in IESG processing. ==> no presentation time (#)

* Dynamic Client Registration Management Protocol

We had a discussion about this work at the last IETF meeting and the
path forward looked somewhat difficult. Nothing has happened since that
time and I am inclined to remove it from the list of WG items.

* Proof-of-Possession Security

We have several new documents and I hope we can turn into working group
items already before the meeting. We would then use the meeting time to
discuss open issues.

#: No presentation time unless some challenging comments from the IESG
surface.

-------- Proposed New WG items -------

I would also like to put the following items on the agenda.

* Token Introspection

* draft-sakimura-oauth-tcse-03	

-------- Other items -------

Phil might want to bring up this item since it was discussed on the
list: draft-hunt-oauth-v2-user-a4c

Other ideas/suggestions?

Ciao
Hannes




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

--------------090008070704010405010709-- From nobody Thu Jul 3 02:46:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0ACC1A0368 for ; Thu, 3 Jul 2014 02:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK51ZbDcMGQX for ; Thu, 3 Jul 2014 02:46:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331091A0196 for ; Thu, 3 Jul 2014 02:46:14 -0700 (PDT) Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M4Gyx-1WlWFO2zOF-00rml5; Thu, 03 Jul 2014 11:46:09 +0200 Message-ID: <53B5265F.2070008@gmx.net> Date: Thu, 03 Jul 2014 11:46:07 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Campbell , Justin Richer References: In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rgTGIu7vjUFSWHMEQEidc147TqvgScOeQ" X-Provags-ID: V03:K0:RsOlGjGOCjknyZ+Z0DZLqVzRYYFJYE+VHZHzMrU1kI/YFgoa/N+ FOduswLUohILWA4GXMGj6QlieKGQUPgfXeRdDN88JWjEHGuSBtjCUmzBp1NH+dzPRYGspfz 9sGdsj6fCJsKur17joCSfod26Tn2qrXuWiH19S/nqA8zn5LMNiYL2hEskC0IEzLRhqAkz+5 zDtk6g/mDCXc7L3f9fYgw== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6hIT5WqZsdLJFDKHRzZecNtAb2A Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol (was Re: Agenda requests, please) 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, 03 Jul 2014 09:46:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rgTGIu7vjUFSWHMEQEidc147TqvgScOeQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, Hi Justin, thanks for the quick feedback. Here is the status from the last meeting: http://www.ietf.org/mail-archive/web/oauth/current/msg12514.html I tried to put a date to the milestone on the charter page. When would this work be finished? Ciao Hannes On 07/03/2014 04:58 AM, Brian Campbell wrote: > Having difficulty finding consensus around a solution isn=E2=80=99t the= same > thing as lack of interest in a solution. I think it would be very > premature to remove the Dynamic Client Registration Management > Protocol from the list of WG items. >=20 > On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig > wrote: >> >> * Dynamic Client Registration Management Protocol >> >> We had a discussion about this work at the last IETF meeting and the >> path forward looked somewhat difficult. Nothing has happened since tha= t >> time and I am inclined to remove it from the list of WG items. --rgTGIu7vjUFSWHMEQEidc147TqvgScOeQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTtSZfAAoJEGhJURNOOiAt2WkIAJ/W6mU0JThbc2FYVBeTTpEa SiL53N6ggejgYFEgaULFusQaUPtslNzXsi44PM75uGA/BHgRVPciuTl4XhhDA8nq axwH6UWxsZwonPP9YooYhbK7fEFfZxi3zQQrux+FwIywrJhcCbczaEY84gIGg4Ru dCTfaH4NRLFKo92VoKb7Ar8gsfCxeBBmht5Q0lbcvHFVx9n8fIqd2nkzdyS7hB74 pQxiJ0BTrCXgU4LkykEyiPlUWEC+xIbQgyKCgEEnyRy567yMxsLwltrB8Idn/NBh 9U3rSwLdAp1TqF4G6fapbhrhtn7t/Eqc2aQDLEYZyDbZrM9hBmi+NpjWDzqQK4s= =4euB -----END PGP SIGNATURE----- --rgTGIu7vjUFSWHMEQEidc147TqvgScOeQ-- From nobody Thu Jul 3 04:33:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBCA1B28A4 for ; Thu, 3 Jul 2014 04:33:26 -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 w63vjttMBDXm for ; Thu, 3 Jul 2014 04:33:23 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41EE1B27E3 for ; Thu, 3 Jul 2014 04:33:22 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so10384629wib.0 for ; Thu, 03 Jul 2014 04:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=HpqEpsMSeuGyupp3Ap+N3xhNPGNCNSEtKz1CyJkyrrg=; b=kS2Fsqa1FTQk5Ob818Ns/UcSYSp7fx0SC+88w2+6nZAc40K7ZnBxsSRzEopIXufEQg HxBZcaqpMCsg6OBa8I6Ml1jQLZQfqj573Gr8oejNMXVr5djHaXNRWZ5D//eR/GBg8BIQ 8ydSKMHho3HT9ZI4DUQxpc9z52ib1ImeOH4Jwx3DxTAyaAIcwvJ91Tax6b7OpWNuAC5S XqtNVXMf8fN5vEr11fMh7zltL4UoqDqNeh/Kub6P5BjbLBIjNcjAQWbS1Lmfbl5S7jy7 he6yRWikKQSjGwQlorQ8C1IJnNEFpbDZmk7HDECZVr8K119MGrMZfJdkDJ3HDdsWYnxO Sz9g== X-Received: by 10.194.22.201 with SMTP id g9mr4341006wjf.98.1404387197777; Thu, 03 Jul 2014 04:33:17 -0700 (PDT) Received: from [192.168.2.7] ([109.255.82.12]) by mx.google.com with ESMTPSA id h3sm61448923wjz.48.2014.07.03.04.33.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 04:33:17 -0700 (PDT) Message-ID: <53B53F7C.506@gmail.com> Date: Thu, 03 Jul 2014 12:33:16 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: oauth@ietf.org References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/xpsMLz6XO0EeDz93LemzylH3kEw Subject: Re: [OAUTH-WG] refresh tokens and client instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 11:33:26 -0000 Hi I'm finding the answers from John interesting but I'm failing to understand why refresh tokens are mentioned in scope of identifying the specific client instances. AFAIK refresh tokens would only go on the wire, assuming they are supported, when a client exchanges a grant for a new access token. And when the client uses a refresh token grant. Was it really about a refresh token grant where the incoming client id and refresh token pair can uniquely identify the actual client instance ? That would make sense. Something else I'd like to clarify. John mentions a refresh token is created at the authorization grant initialization time. Would it make any difference, as far as the security properties of a grant are concerned, if refresh token was only created at a grant to access token exchange point of time ? Thanks, Sergey On 27/06/14 19:21, John Bradley wrote: > Inline > > On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri > wrote: > >> Hi John, >> Thank you for your reply. Would appreciate if you consider my inline >> comments below and respond again! >> R, >> Madjid >> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com] >> *Sent:*Wednesday, June 25, 2014 5:56 PM >> *To:*Madjid Nakhjiri >> *Cc:*oauth@ietf.org >> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances >> In 3.3 It is saying that the refresh token is a secret that the >> Authorization server has bound to the client_id, that the >> Authorization server effectively uses to differentiate between >> instances of that client_id. >> Madjid>>If I have 10,000s of devices, each with an instance of the >> OAUTH client, but they are all using the same client ID, how would the >> server know which token to use for what client? unless when I am >> creating a token, I also include something that uniquely identifies >> each instance? Don’t I have to use SOMETHING that is unique to that >> instance (user grant/ID?)? > When the grant is issued you create and store a refresh token which is > effectively the identifier for that instance/grant combination. > When it comes back on a request to the token endpoint you look up the > grants associated with it. You also hack that the client_id sent in > the request matches to detect errors mostly) > >> When the refresh token is generated, it can be stored in a table with >> the client_id and the information about the grant. You could also do >> it statelesly by creating a signed object as the refresh token. >> Madjid>>agreed, but for the signed object to be self-sustained, again >> would I not need something beyond a “population” client_ID? Are we >> prescriptive what “information about the grant” is? > You would be creating a bearer token as long as the AS signs it you can > put whatever grant grant info you like in it, that is implementation > specific. It could be a list of the scopes granted and the subject. >> The spec is silent on the exact programming method that the >> Authorization server uses. >> Madjid>>Are there any other specs in IETF or elsewhere (OASIS, etc?) >> that prescribe token calculation (e.g. hash function, parameters, etc)? > > You can look at JOSE and JWT for a way to create tokens > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token >> In 3.7 Deployment independent describes using the same client_id >> across multiple instances of a native client, or multiple instances of >> a Java Script client running in a browsers with the same callback uri. >> Since the publishing of this RFC we have also developed a spec for >> dynamic client registration so it is possible to give every native >> client it's own client_id and secret making them confidential clients. >> Madjid>>I would need to look at those specs, however, I thought that >> the “confidential client” designation has to do with the client >> ability to hold secrets and perform a-by-server-acceptable >> authentication. Does dynamic client registration affect client’s >> ability in that aspect? > > Yes it doesn't require the secret to be in the downloaded instance of > the native app. It can be populated at first run, changing it from > public to confidential. > Confidential is not just for web servers any more. >> There is also a middle ground some people take by doing a proof of >> possession for code in native applications to prevent the interception >> of responses to the client by malicious applications on the device. >> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ >> John B. >> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri > > wrote: >> >> >> Hi all, >> I am new to OAUTH list and OAUTH, so apologies if this is very off-topic. >> I am evaluating an OAUTH 2.0 implementation that is done based on bare >> bone base OAUTH2.0 RFC. From what I understand, many (or some) client >> implementations use a “global ID/secret” pair for all instances of the >> client. Looking at RFC 6819 and there seem to be a whole page on this >> topic, if I understand it correctly. So questions: >> 1)Section 3.7 talks about deployment-independent versus deployment >> specific client IDs. I am guessing “deployment-independent” refers to >> what I called “global”, meaning if I have the same client with the >> same client ID installed in many end devices, that is a deployment >> independent case, correct? >> 2)Section 3.3 on refresh token mentions that the token is secret bound >> to the client ID and client instance. Could somebody please point me >> to where the token generation and binding is described? Also how is >> the client instance is identified? >> Thanks a lot in advance, >> Madjid Nakhjiri >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Thu Jul 3 08:41:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729741A019A for ; Thu, 3 Jul 2014 08:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yY5mATOcSTx for ; Thu, 3 Jul 2014 08:40:58 -0700 (PDT) Received: from nm31-vm2.bullet.mail.bf1.yahoo.com (nm31-vm2.bullet.mail.bf1.yahoo.com [72.30.239.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9733E1A0177 for ; Thu, 3 Jul 2014 08:40:58 -0700 (PDT) Received: from [98.139.212.151] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2014 15:40:57 -0000 Received: from [98.139.212.227] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2014 15:40:57 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 03 Jul 2014 15:40:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 665382.75499.bm@omp1036.mail.bf1.yahoo.com Received: (qmail 20887 invoked by uid 60001); 3 Jul 2014 15:40:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1404402057; bh=3G+clWjVwAaScx7WUBHUzymx5P7bgNUakXmdMnGkKrU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=hKeY9QBaaqtANI/Zqv8Y1mAMM4tZsm3HHB+0Rlrs93WVwQbtQOGcCZVR2j8nvaAinIftxcGiCjDzGuoemar4zU606icYeA7Qc7HWRvLolIyPOVdb8csMu4A1k3kjttqnBaMXXHza+M1eXBY9+GIz7NLEgrSEDAsVEUyNXQVB+ik= X-YMail-OSG: mh.uitQVM1nOcMKh_Qeg0qj8PX5NVyaX0xKZVqFO.wGrJw9 wWzZFgTlaE9sMnktdYp3kTldm2ab.CQBGnj1e9Bh8J3XFODaFS2Bsf.VCkn8 6tY6.DTKyyK4nSh8ZvJNA3DHHo6qQztj8oazDFYnpDABn9OZlhcdUCVSbv9Z Wh1jv5qfzmIHTfUjZF3oM4dJfJLowzxgpBRi4lDN5xmWZWhEau6EZFlHLuBU FgwCiZoTUSZcqTDaoOiKoShOIBSW8NHV7.Sc2oQnflGRbB2kZhq5RK8Xye6X W3c55ceB3eXBZbjtmPCvkCR1odIHV0OXY.YSu901IYl2yPXSdN697ooIxGim rRMQdd7Wrvx5CCfobzzJ7FKVIqJeX4zhwdKsJ1vKdxjiyEmhkrAQyW.ps0hO J.7nsNsfLG6bGj3.YKkrzzqLsYDKvScJN3Gvw9hRKy_G5g_eycWEcYmxyDSC F7.NyZkpRPfkTMnJZMXQKxDSWqUwECj57DyFRw.CCvHycjUpIOZyHXtDSl7t JSZRSZ3UGQo.4w.g7sL2ljzk8v9LMxlQsVxzJp0s1YOFffEzWJMChOzo- Received: from [167.220.24.160] by web142801.mail.bf1.yahoo.com via HTTP; Thu, 03 Jul 2014 08:40:57 PDT X-Rocket-MIMEInfo: 002.001, SW1wbGVtZW50YXRpb25zIG1heS9TSE9VTEQgYmluZCByZWZyZXNoIHRva2VucyB0byBzcGVjaWZpYyBjbGllbnQgaW5zdGFuY2VzLiDCoFllcywgaXQncyBwb3NzaWJsZSB0aGF0IHRoZSBjbGllbnQgSUQgd2l0aCBkeW5hbWljIHJlZ2lzdHJhdGlvbiBpcyB1bmlxdWUgdG8gZWFjaCBjbGllbnQsIGJ1dCBtYW55IG9mIHRoZSB0b2tlbiB0aGVmdCB1c2UgY2FzZXMgaW5jbHVkZSB0aGUgcG9zc2liaWxpdHkgb2Ygc3RlYWxpbmcgdGhlIGNsaWVudCBJRCB0b28gaWYgeW91IGtub3cgeW91IG5lZWQgdG8uCgotYmkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.191.1 References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> <53B53F7C.506@gmail.com> Message-ID: <1404402057.15252.YahooMailNeo@web142801.mail.bf1.yahoo.com> Date: Thu, 3 Jul 2014 08:40:57 -0700 From: Bill Mills To: Sergey Beryozkin , "oauth@ietf.org" In-Reply-To: <53B53F7C.506@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="469468616-413960366-1404402057=:15252" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/q9BOJB1v2AeLbvoS0z1Ldmp2xss Subject: Re: [OAUTH-WG] refresh tokens and client instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 15:41:01 -0000 --469468616-413960366-1404402057=:15252 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Implementations may/SHOULD bind refresh tokens to specific client instances= . =C2=A0Yes, it's possible that the client ID with dynamic registration is = unique to each client, but many of the token theft use cases include the po= ssibility of stealing the client ID too if you know you need to.=0A=0A-bill= =0A=0A=0AOn Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin wrote:=0A =0A=0A=0AHi=0A=0AI'm finding the answers from John inter= esting but I'm failing to =0Aunderstand why refresh tokens are mentioned in= scope of identifying the =0Aspecific client instances.=0A=0AAFAIK refresh = tokens would only go on the wire, assuming they are =0Asupported, when a cl= ient exchanges a grant for a new access token.=0AAnd when the client uses a= refresh token grant.=0A=0AWas it really about a refresh token grant where = the incoming client id =0Aand refresh token pair can uniquely identify the = actual client instance =0A? That would make sense.=0A=0ASomething else I'd = like to clarify.=0AJohn mentions a refresh token is created at the authoriz= ation grant =0Ainitialization time. Would it make any difference, as far as= the =0Asecurity properties of a grant are concerned, if refresh token was = only =0Acreated at a grant to access token exchange point of time ?=0A=0ATh= anks, Sergey=0A=0AOn 27/06/14 19:21, John Bradley wrote:=0A> Inline=0A>=0A>= On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri <= mailto:m.nakhjiri@samsung.com>> wrote:=0A>=0A>> Hi John,=0A>> Thank you for= your reply. Would appreciate if you consider my inline=0A>> comments below= and respond again!=0A>> R,=0A>> Madjid=0A>> *From:*John Bradley [mailto:ve= 7jtb@ve7jtb.com]=0A>> *Sent:*Wednesday, June 25, 2014 5:56 PM=0A>> *To:*Mad= jid Nakhjiri=0A>> *Cc:*oauth@ietf.org =0A>> *Subject= :*Re: [OAUTH-WG] refresh tokens and client instances=0A>> In 3.3 It is sayi= ng that the refresh token is a secret that the=0A>> Authorization server ha= s bound to the client_id, that the=0A>> Authorization server effectively us= es to differentiate between=0A>> instances of that client_id.=0A>> Madjid>>= If I have 10,000s of devices, each with an instance of the=0A>> OAUTH clien= t, but they are all using the same client ID, how would the=0A>> server kno= w which token to use for what client? unless when I am=0A>> creating a toke= n, I also include something that uniquely identifies=0A>> each instance? Do= n=E2=80=99t I have to use SOMETHING that is unique to that=0A>> instance (u= ser grant/ID?)?=0A> When the grant is issued you create and store a refresh= token which is=0A> effectively the identifier for that instance/grant comb= ination.=0A> When it comes back on a request to the token endpoint you look= up the=0A> grants associated with it.=C2=A0 You also hack that the client= _id sent in=0A> the request matches to detect errors mostly)=0A>=0A>> When = the refresh token is generated, it can be stored in a table with=0A>> the c= lient_id and the information about the grant.=C2=A0 You could also do=0A>>= it statelesly by creating a signed object as the refresh token.=0A>> Madji= d>>agreed, but for the signed object to be self-sustained, again=0A>> would= I not need something beyond a =E2=80=9Cpopulation=E2=80=9D client_ID? Are = we=0A>> prescriptive what =E2=80=9Cinformation about the grant=E2=80=9D is?= =0A> You would be creating a bearer token as long as the AS signs it you ca= n=0A> put whatever grant grant info you like in it, that is implementation= =0A> specific.=C2=A0 It=C2=A0 could be a list of the scopes granted and the= subject.=0A>> The spec is silent on the exact programming method that the= =0A>> Authorization server uses.=0A>> Madjid>>Are there any other specs in = IETF or elsewhere (OASIS, etc?)=0A>> that prescribe token calculation (e.g.= hash function, parameters, etc)?=0A>=0A> You can look at JOSE and JWT for = a way to create tokens=0A> http://tools.ietf.org/html/draft-ietf-oauth-json= -web-token=0A>> In 3.7 Deployment independent describes using the same clie= nt_id=0A>> across multiple instances of a native client, or multiple instan= ces of=0A>> a Java Script client running in a browsers with the same callba= ck uri.=0A>> Since the publishing of this RFC we have also developed a spec= for=0A>> dynamic client registration so it is possible to give every nativ= e=0A>> client it's own client_id and secret making them confidential client= s.=0A>> Madjid>>I would need to look at those specs, however, I thought tha= t=0A>> the =E2=80=9Cconfidential client=E2=80=9D designation has to do with= the client=0A>> ability to hold secrets and perform a-by-server-acceptable= =0A>> authentication. Does dynamic client registration affect client=E2=80= =99s=0A>> ability in that aspect?=0A>=0A> Yes it doesn't require the secret= to be in the downloaded instance of=0A> the native app.=C2=A0 It can be po= pulated at first run, changing it from=0A> public to confidential.=0A> Conf= idential is not just for web servers any more.=0A>> There is also a middle = ground some people take by doing a proof of=0A>> possession for code in nat= ive applications to prevent the interception=0A>> of responses to the clien= t by malicious applications on the device.=0A>> https://datatracker.ietf.or= g/doc/draft-sakimura-oauth-tcse/=0A>> John B.=0A>> On Jun 25, 2014, at 8:06= PM, Madjid Nakhjiri > > wrote:=0A>>=0A>>=0A>> Hi all,=0A>> I am new to OAUTH list and OAUTH= , so apologies if this is very off-topic.=0A>> I am evaluating an OAUTH 2.0= implementation that is done based on bare=0A>> bone base OAUTH2.0 RFC. Fro= m what I understand, many (or some) client=0A>> implementations use a =E2= =80=9Cglobal ID/secret=E2=80=9D pair for all instances of the=0A>> client.= =C2=A0 Looking at RFC 6819 and there seem to be a whole page on this=0A>> t= opic, if I understand it correctly. So questions:=0A>> 1)Section 3.7 talks = about deployment-independent versus deployment=0A>> specific client IDs. I = am guessing =E2=80=9Cdeployment-independent=E2=80=9D refers to=0A>> what I = called =E2=80=9Cglobal=E2=80=9D, meaning if I have the same client with the= =0A>> same client ID installed in many end devices, that is a deployment=0A= >> independent case, correct?=0A>> 2)Section 3.3 on refresh token mentions = that the token is secret bound=0A>> to the client ID and client instance. C= ould somebody please point me=0A>> to where the token generation and bindin= g is described? Also how is=0A>> the client instance is identified?=0A>> Th= anks a lot in advance,=0A>> Madjid Nakhjiri=0A>> __________________________= _____________________=0A>> OAuth mailing list=0A>> OAuth@ietf.org =0A>> https://www.ietf.org/mailman/listinfo/oauth=0A=0A>=0A>= =0A>=0A> _______________________________________________=0A> OAuth mailing = list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth=0A>= =0A=0A_______________________________________________=0AOAuth mailing list= =0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --469468616-413960366-1404402057=:15252 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Implementations may/SHOULD bind refresh tokens to = specific client instances.  Yes, it's possible that the client ID with= dynamic registration is unique to each client, but many of the token theft= use cases include the possibility of stealing the client ID too if you kno= w you need to.
<= span>
= -bill


On Thursday, July 3, = 2014 4:33 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:


Hi
I'm finding the answers from John interesting but I'm fail= ing to
understand why refresh tokens are mentioned in sc= ope of identifying the
specific client instances.

AFAIK refresh tokens would only go on the wi= re, assuming they are
supported, when a client exchanges= a grant for a new access token.
And when the client uses= a refresh token grant.

Was it really about a refresh = token grant where the incoming client id
and refresh tok= en pair can uniquely identify the actual client instance
? That would make sense.

Something el= se I'd like to clarify.
John mentions a refresh token is = created at the authorization grant
initialization time. = Would it make any difference, as far as the
security pro= perties of a grant are concerned, if refresh token was only
created at a grant to access token exchange point of time ?

Thanks, Sergey

On 27/06/14 19:21, John Bradley wrote:
> Inline
>
> On Jun 27, 2014, at 1:24 PM, Mad= jid Nakhjiri <m.nakhjiri@samsung.com
> <mailto:m.nakhjiri@samsung.com>> wrote:
>
>> Hi John,=
>> Thank you for your reply. Would appreciate if y= ou consider my inline
>> comments below and respond= again!
>> R,
>> Madjid
>> *From:*John Bradley [mailto:ve7jtb@ve= 7jtb.com]
>> *Sent:*Wednesday, June 25, 2014 5:= 56 PM
>> *To:*Madjid Nakhjiri
>= ;> *Cc:*oauth@ietf.org <mailto:oauth@ietf.org>
&g= t;> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
>> In 3.3 It is saying that the refresh token is a secret = that the
>> Authorization server has bound to the c= lient_id, that the
>> Authorization server effectiv= ely uses to differentiate between
>> instances of t= hat client_id.
>> Madjid>>If I have 10,000s o= f devices, each with an instance of the
>> OAUTH cl= ient, but they are all using the same client ID, how would the
>> server know which token to use for what client? unless when = I am
>> creating a token, I also include something = that uniquely identifies
>> each instance? Don=E2= =80=99t I have to use SOMETHING that is unique to that
&g= t;> instance (user grant/ID?)?
> When the grant is issued you create and= store a refresh token which is
> effectively the iden= tifier for that instance/grant combination.
> When it = comes back on a request to the token endpoint you look up the
> grants associated with it.  You also hack that the client_i= d sent in
> the request matches to detect errors mostl= y)
>
>> When the refresh token= is generated, it can be stored in a table with
>> = the client_id and the information about the grant.  You could also do=
>> it statelesly by creating a signed object as th= e refresh token.
>> Madjid>>agreed, but for t= he signed object to be self-sustained, again
>> wou= ld I not need something beyond a =E2=80=9Cpopulation=E2=80=9D client_ID? Ar= e we
>> prescriptive what =E2=80=9Cinformation about the g= rant=E2=80=9D is?
> You would be creating a bearer tok= en as long as the AS signs it you can
> put whatever g= rant grant info you like in it, that is implementation
&g= t; specific.  It  could be a list of the scopes granted and the s= ubject.
>> The spec is silent on the exact programm= ing method that the
>> Authorization server uses.>> Madjid>>Are there any other specs in IETF o= r elsewhere (OASIS, etc?)
>> that prescribe token c= alculation (e.g. hash function, parameters, etc)?
>> You can look at JOSE and JWT for a way to create token= s
> http://tools.ietf.org/html/draft-ietf-oauth-json-web-tok= en
>> In 3.7 Deployment independent describes u= sing the same client_id
>> across multiple instance= s of a native client, or multiple instances of
>> a= Java Script client running in a browsers with the same callback uri.
>> Since the publishing of this RFC we have also develop= ed a spec for
>> dynamic client registration so it = is possible to give every native
>> client it's own= client_id and secret making them confidential clients.
&= gt;> Madjid>>I would need to look at those specs, however, I thoug= ht that
>> the =E2=80=9Cconfidential client=E2=80= =9D designation has to do with the client
>> abilit= y to hold secrets and perform a-by-server-acceptable
>= > authentication. Does dynamic client registration affect client=E2=80=99s
>= > ability in that aspect?
>
> = Yes it doesn't require the secret to be in the downloaded instance of
> the native app.  It can be populated at first run, c= hanging it from
> public to confidential.
> Confidential is not just for web servers any more.
>> There is also a middle ground some people take by doing a pro= of of
>> possession for code in native applications= to prevent the interception
>> of responses to the= client by malicious applications on the device.
>>= https://datatracker.ietf.org/doc/draft-sakim= ura-oauth-tcse/
>> John B.
&g= t;> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri <m.nakhjiri@samsung.co= m
>> <mailto:m.nakhj= iri@samsung.com>> wrote:
>>
>>
>> Hi all,
>>= I am new to OAUTH list and OAUTH, so apologies if this is very off-topic.<= br clear=3D"none">>> I am evaluating an OAUTH 2.0 implementation that= is done based on bare
>> bone base OAUTH2.0 RFC. F= rom what I understand, many (or some) client
>> imp= lementations use a =E2=80=9Cglobal ID/secret=E2=80=9D pair for all instance= s of the
>> client.  Looking at RFC 6819 and t= here seem to be a whole page on this
>> topic, if I= understand it correctly. So questions:
>> 1)Section 3.7 talks about deployment= -independent versus deployment
>> specific client I= Ds. I am guessing =E2=80=9Cdeployment-independent=E2=80=9D refers to
>> what I called =E2=80=9Cglobal=E2=80=9D, meaning if I h= ave the same client with the
>> same client ID inst= alled in many end devices, that is a deployment
>> = independent case, correct?
>> 2)Section 3.3 on refr= esh token mentions that the token is secret bound
>>= ; to the client ID and client instance. Could somebody please point me
>> to where the token generation and binding is describ= ed? Also how is
>> the client instance is identifie= d?
>> Thanks a lot in advance,
&g= t;> Madjid Nakhjiri
>> _________________________= ______________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oaut= h

>=
>
>
> _____= __________________________________________
> OAuth mai= ling list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


--469468616-413960366-1404402057=:15252-- From nobody Thu Jul 3 09:01:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B8E1B2AEF for ; Thu, 3 Jul 2014 09:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3JAmxV6nwBJ for ; Thu, 3 Jul 2014 09:01:20 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21DA41B29E6 for ; Thu, 3 Jul 2014 09:01:17 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s63G1ERI022511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Jul 2014 16:01:15 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s63G1Dmh010496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2014 16:01:13 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s63G1AvI010241; Thu, 3 Jul 2014 16:01:12 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Jul 2014 09:01:10 -0700 References: <53B5265F.2070008@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: <53B5265F.2070008@gmx.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <70318025-F757-4063-8A0C-4F758EBC4498@oracle.com> X-Mailer: iPhone Mail (11D201) From: Phil Hunt Date: Thu, 3 Jul 2014 09:01:09 -0700 To: Hannes Tschofenig X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TeTRCYs4d0b_oSdf1MRvkXwVaIE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol (was Re: Agenda requests, please) 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, 03 Jul 2014 16:01:22 -0000 Part if the lack of consensus is lack of agreement on what mgmt is for. Unti= l that is resolved its hard to see what the timeline would be. Mgmt might be= the right call. Who knows.=20 For example i see credential rotation and client software update, and deprov= isioning as being events. I am not sure all of these are RESTful crud operat= ions. They feel process/rpc oriented.=20 It just seems to me the use case/requirements need work first.=20 Phil > On Jul 3, 2014, at 2:46, Hannes Tschofenig wro= te: >=20 > Hi Brian, Hi Justin, >=20 > thanks for the quick feedback. >=20 > Here is the status from the last meeting: > http://www.ietf.org/mail-archive/web/oauth/current/msg12514.html >=20 > I tried to put a date to the milestone on the charter page. > When would this work be finished? >=20 > Ciao > Hannes >=20 >=20 >> On 07/03/2014 04:58 AM, Brian Campbell wrote: >> Having difficulty finding consensus around a solution isn=E2=80=99t the s= ame >> thing as lack of interest in a solution. I think it would be very >> premature to remove the Dynamic Client Registration Management >> Protocol from the list of WG items. >>=20 >> On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig >> wrote: >>>=20 >>> * Dynamic Client Registration Management Protocol >>>=20 >>> We had a discussion about this work at the last IETF meeting and the >>> path forward looked somewhat difficult. Nothing has happened since that >>> time and I am inclined to remove it from the list of WG items. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Jul 3 09:28:59 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C071B2B17 for ; Thu, 3 Jul 2014 09:28:56 -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 wcLG3HJqZHYw for ; Thu, 3 Jul 2014 09:28:51 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191441B2945 for ; Thu, 3 Jul 2014 09:28:50 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id bs8so11677388wib.7 for ; Thu, 03 Jul 2014 09:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=pc26YRikyqfRCRqK4wSFmsIh3+g2HxM9AkPHUdVQnIc=; b=D9KEv+Qlt1pjP1My7TvyM0oB7QZJBjCaKxoKZvsCcLJZ7Z+ZWNN7ln1gKdw3nbBVKt zXYWKFkw2577xFfs8r6E72Gf1pCXPu5ZwZuRrtiCW/PvEinVEGP3+gzvnKb1oL/Zpyaq SuNuDgi57V6pGSX3KMmhAMABsVEYTvELMd32tSFLHoo9X06CTLNSpzlNqSmFNJd6RI+a Oq3XdsUDiEhUs3d/03H3TZvziwUXZRedbejXPsdi7r4GBNnHkrKBb5U18/AyGeYiWzOy 7sth2q/OHJTOGl9RStHcfqLSTbcykpjRpKMji9U7dxq2OfriNILF0+leaMedCtFC31dz HDvQ== X-Received: by 10.194.79.135 with SMTP id j7mr6264957wjx.56.1404404927424; Thu, 03 Jul 2014 09:28:47 -0700 (PDT) Received: from [192.168.2.7] ([109.255.82.12]) by mx.google.com with ESMTPSA id o9sm21993313wib.22.2014.07.03.09.28.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 09:28:46 -0700 (PDT) Message-ID: <53B584BA.6090901@gmail.com> Date: Thu, 03 Jul 2014 17:28:42 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bill Mills , "oauth@ietf.org" References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> <53B53F7C.506@gmail.com> <1404402057.15252.YahooMailNeo@web142801.mail.bf1.yahoo.com> In-Reply-To: <1404402057.15252.YahooMailNeo@web142801.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/QpJNV8UIg_kCYtSNu3l3dd0HfS8 Subject: Re: [OAUTH-WG] refresh tokens and client instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 16:28:56 -0000 Hi On 03/07/14 16:40, Bill Mills wrote: > Implementations may/SHOULD bind refresh tokens to specific client > instances. Yes, it's possible that the client ID with dynamic > registration is unique to each client, but many of the token theft use > cases include the possibility of stealing the client ID too if you know > you need to. > What exactly is a 'client instance' when we talk about having a single client id registration, with the id shared between multiple devices (which is what I believe this thread started from). What I understood, as far as the authorization service is concerned, a 'client instance' for AS is a combination of a client id + code grant. + (optional) refresh token (as was mentioned earlier). But it appears to me a client instance can be uniquely identified by two values only without a refresh token. When a user authorizes a given device and gets a grant code and enters it into the device securely we have a 'client instance' ready to get the tokens, with that device (client instance) using a client id and the grant code to get an access token and a refresh token. Lets say it sends a "client_id=1&code=2" sequence to get the tokens. A client id + a code value constitutes a client instance, because a code would be unique per every authorization, right ? So the service will return an access token + refresh token to the device. Refresh Token could've been associated with a record containing a client id + grant code info earlier or at the moment the code is exchanged for an access token. During the subsequent refresh token grant request we have "client id + refresh token" as a client instance. I'm not sure what exactly I'd like to ask here :-), but I wonder if the above sounds right, then I guess I'd like to conclude that when we talk about the authorization code grant then a refresh token is not the only key that uniquely identifies a client instance: Initially it is a client id + code grant, a refresh token does not offer an extra uniqueness at the point of the client device requesting an access token with a code. Refresh token only starts acting as the key client instance identifier at a refresh token grant time. Sorry for a long email, I'm very likely missing something, so any clarifications will be welcome Thanks, Sergey > -bill > > > On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin > wrote: > > > Hi > > I'm finding the answers from John interesting but I'm failing to > understand why refresh tokens are mentioned in scope of identifying the > specific client instances. > > AFAIK refresh tokens would only go on the wire, assuming they are > supported, when a client exchanges a grant for a new access token. > And when the client uses a refresh token grant. > > Was it really about a refresh token grant where the incoming client id > and refresh token pair can uniquely identify the actual client instance > ? That would make sense. > > Something else I'd like to clarify. > John mentions a refresh token is created at the authorization grant > initialization time. Would it make any difference, as far as the > security properties of a grant are concerned, if refresh token was only > created at a grant to access token exchange point of time ? > > Thanks, Sergey > > On 27/06/14 19:21, John Bradley wrote: > > Inline > > > > On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri > > >> wrote: > > > >> Hi John, > >> Thank you for your reply. Would appreciate if you consider my inline > >> comments below and respond again! > >> R, > >> Madjid > >> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com > ] > >> *Sent:*Wednesday, June 25, 2014 5:56 PM > >> *To:*Madjid Nakhjiri > >> *Cc:*oauth@ietf.org > > >> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances > >> In 3.3 It is saying that the refresh token is a secret that the > >> Authorization server has bound to the client_id, that the > >> Authorization server effectively uses to differentiate between > >> instances of that client_id. > >> Madjid>>If I have 10,000s of devices, each with an instance of the > >> OAUTH client, but they are all using the same client ID, how would the > >> server know which token to use for what client? unless when I am > >> creating a token, I also include something that uniquely identifies > >> each instance? Don’t I have to use SOMETHING that is unique to that > >> instance (user grant/ID?)? > > When the grant is issued you create and store a refresh token which is > > effectively the identifier for that instance/grant combination. > > When it comes back on a request to the token endpoint you look up the > > grants associated with it. You also hack that the client_id sent in > > the request matches to detect errors mostly) > > > >> When the refresh token is generated, it can be stored in a table with > >> the client_id and the information about the grant. You could also do > >> it statelesly by creating a signed object as the refresh token. > >> Madjid>>agreed, but for the signed object to be self-sustained, again > >> would I not need something beyond a “population†client_ID? Are we > >> prescriptive what “information about the grant†is? > > You would be creating a bearer token as long as the AS signs it you can > > put whatever grant grant info you like in it, that is implementation > > specific. It could be a list of the scopes granted and the subject. > >> The spec is silent on the exact programming method that the > >> Authorization server uses. > >> Madjid>>Are there any other specs in IETF or elsewhere (OASIS, etc?) > >> that prescribe token calculation (e.g. hash function, parameters, etc)? > > > > You can look at JOSE and JWT for a way to create tokens > > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token > >> In 3.7 Deployment independent describes using the same client_id > >> across multiple instances of a native client, or multiple instances of > >> a Java Script client running in a browsers with the same callback uri. > >> Since the publishing of this RFC we have also developed a spec for > >> dynamic client registration so it is possible to give every native > >> client it's own client_id and secret making them confidential clients. > >> Madjid>>I would need to look at those specs, however, I thought that > >> the “confidential client†designation has to do with the client > >> ability to hold secrets and perform a-by-server-acceptable > >> authentication. Does dynamic client registration affect client’s > >> ability in that aspect? > > > > Yes it doesn't require the secret to be in the downloaded instance of > > the native app. It can be populated at first run, changing it from > > public to confidential. > > Confidential is not just for web servers any more. > >> There is also a middle ground some people take by doing a proof of > >> possession for code in native applications to prevent the interception > >> of responses to the client by malicious applications on the device. > >> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ > >> John B. > >> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri > >> >> wrote: > >> > >> > >> Hi all, > >> I am new to OAUTH list and OAUTH, so apologies if this is very > off-topic. > >> I am evaluating an OAUTH 2.0 implementation that is done based on bare > >> bone base OAUTH2.0 RFC. From what I understand, many (or some) client > >> implementations use a “global ID/secret†pair for all instances of the > >> client. Looking at RFC 6819 and there seem to be a whole page on this > >> topic, if I understand it correctly. So questions: > >> 1)Section 3.7 talks about deployment-independent versus deployment > >> specific client IDs. I am guessing “deployment-independent†refers to > >> what I called “globalâ€, meaning if I have the same client with the > >> same client ID installed in many end devices, that is a deployment > >> independent case, correct? > >> 2)Section 3.3 on refresh token mentions that the token is secret bound > >> to the client ID and client instance. Could somebody please point me > >> to where the token generation and binding is described? Also how is > >> the client instance is identified? > >> Thanks a lot in advance, > >> Madjid Nakhjiri > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From nobody Thu Jul 3 10:14:43 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E161B28E2 for ; Thu, 3 Jul 2014 10:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SBLiQde2567 for ; Thu, 3 Jul 2014 10:14:38 -0700 (PDT) Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250AC1B2B2F for ; Thu, 3 Jul 2014 10:14:38 -0700 (PDT) Received: from [66.196.81.170] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2014 17:14:37 -0000 Received: from [98.139.212.221] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2014 17:14:37 -0000 Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 03 Jul 2014 17:14:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 81962.10824.bm@omp1030.mail.bf1.yahoo.com Received: (qmail 87876 invoked by uid 60001); 3 Jul 2014 17:14:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1404407677; bh=LslckByGjllUQ5xYHaEpBBvBCOrbKuZD8qw9OBRoK1w=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=wUEjGVitk93tVKw2ryzSWVFmfeJVaYQ/+/mXNzdMXct4c4N+enH7mRsnyhjQ8EkisjTToeqkPx0weJYcJNgzVxF08hYhAee6gbR918GjNRmqfWwLJRWfCzs9a3cFfjF1tAKyhNv8r3kYr/9gknw5VpbWXuvXnUmlWiqhCC+4aZY= X-YMail-OSG: HRa9Th0VM1k9nZ0zIxlL352QValAEvRs.nHjuCTIgawCE12 Tq5GwCR6ki.jfO2Zuyi.xuqPJe2vDaHRsVTToQHwF6O1bQvDMjjWTMOWIjJh DxhnpdnOOOBEZTkpD3GlvcHwNEbpQzsOiW3F7ru2C8bPvpvLOevhT7Yc6O8i JlG7ogCXjugVhLS8UDFZLQ3fQCugIFUKRH1qdzGDzR.PQaWljs98qnBkwWXy 6p5.VfVUKg.nm6V1FQRdk1YXMRPMhlZPSEuen.RIsQDxMzBv5gLbXcpLIzKx _ap_dT4HbdI0ACxvj_Rlzzbz4Sy5Q1vq9zGr4tVgBVt4EDnCZolV5Qf85BOO sai7N8qACFWxV1lj9cFmnbXp6te8LhIASJUXskhw8cJ.F6ocjywLXmDQjD8C .CVLuiH46m_rSlEn8kc0lVevqSf.yTwNa_ghFh4plCRIptKDe4fcj4KHA8RB y2jt32e3p.70iAQNsIi7iTaMTJxxsP6DwMGUAF7AXT4zLQGgLJr2FJCsvREp XDVQeBoJiJT8h4Dzjk1vlLin5AS3ckrjrM0pYSzes5rjwXUFg3ipKpaU- Received: from [131.107.0.71] by web142801.mail.bf1.yahoo.com via HTTP; Thu, 03 Jul 2014 10:14:36 PDT X-Rocket-MIMEInfo: 002.001, WW91IG1pZ2h0IGhhdmUgYSBwdWJsaWMgY2xpZW50LCB0aGUgRmxpY2tyIGNsaWVudCBmb3IgZXhhbXBsZSAod2hpY2ggdXNlcyBPQXV0aCAxIHJpZ2h0IG5vdyBidXQgaXQncyBhIHVzZWZ1bCBleGFtcGxlKSB3aGVyZSB0aGUgY2xpZW50IElEIGlzIGJha2VkIGludG8gdGhlIGluc3RhbGwuIMKgSW4gdGhpcyBjYXNlIGJpbmRpbmcgdGhlIHRva2VuIHRvIHRoZSBjbGllbnQgSUQgbWVhbnMgb25seSB0aGF0IHNvbWVvbmUgd2hvIHN0ZWFscyB0aGUgdG9rZW4gYW5kIHRyaWVzIHRvIHVzZSBpdCB3aXRoIGEgZGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.191.1 References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> <53B53F7C.506@gmail.com> <1404402057.15252.YahooMailNeo@web142801.mail.bf1.yahoo.com> <53B584BA.6090901@gmail.com> Message-ID: <1404407676.52412.YahooMailNeo@web142801.mail.bf1.yahoo.com> Date: Thu, 3 Jul 2014 10:14:36 -0700 From: Bill Mills To: Sergey Beryozkin , "oauth@ietf.org" In-Reply-To: <53B584BA.6090901@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="469468616-1639230998-1404407676=:52412" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/g116tApH8Oa-QWORRBc42SnEzrg Subject: Re: [OAUTH-WG] refresh tokens and client instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 17:14:42 -0000 --469468616-1639230998-1404407676=:52412 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable You might have a public client, the Flickr client for example (which uses O= Auth 1 right now but it's a useful example) where the client ID is baked in= to the install. =C2=A0In this case binding the token to the client ID means= only that someone who steals the token and tries to use it with a differen= t client ID would fail.=0A=0AWith DynReg that client could generate a nonce= and include it in a dynamically registered client ID and then the credenti= al could be bound to that specific software instance.=0A=0AA 3rd possibilit= y is multiple clients on a device sharing the same auth context, in which c= ase they all use the same library perhaps and so several installed apps all= would share the same "client id" from the servers perspective (the one for= the auth API) but they might each get different scopes.=0A=0A=0AOn Thursda= y, July 3, 2014 9:28 AM, Sergey Beryozkin wrote:=0A = =0A=0A=0AHi=0AOn 03/07/14 16:40, Bill Mills wrote:=0A> Implementations may/= SHOULD bind refresh tokens to specific client=0A> instances.=C2=A0 Yes, it'= s possible that the client ID with dynamic=0A> registration is unique to ea= ch client, but many of the token theft use=0A> cases include the possibilit= y of stealing the client ID too if you know=0A> you need to.=0A>=0AWhat exa= ctly is a 'client instance' when we talk about having a single =0Aclient id= registration, with the id shared between multiple devices =0A(which is wha= t I believe this thread started from).=0A=0AWhat I understood, as far as th= e authorization service is concerned, a =0A'client instance' for AS is a co= mbination of a client id + code grant.=0A=0A+ (optional) refresh token (as = was mentioned earlier). But it appears to =0Ame a client instance can be un= iquely identified by two values only =0Awithout a refresh token.=0A=0AWhen = a user authorizes a given device and gets a grant code and enters =0Ait int= o the device securely we have a 'client instance' ready to get the =0Atoken= s, with that device (client instance) using a client id and the =0Agrant co= de to get an access token and a refresh token.=0A=0ALets say it sends a "cl= ient_id=3D1&code=3D2" sequence to get the tokens.=0AA client id + a code va= lue constitutes a client instance, because a code =0Awould be unique per ev= ery authorization, right ?=0A=0ASo the service will return an access token = + refresh token to the =0Adevice. Refresh Token could've been associated wi= th a record containing =0Aa client id + grant code info earlier or at the m= oment the code is =0Aexchanged for an access token.=0A=0ADuring the subsequ= ent refresh token grant request we have "client id + =0Arefresh token" as a= client instance.=0A=0AI'm not sure what exactly I'd like to ask here :-), = but I wonder if the =0Aabove sounds right, then I guess I'd like to conclud= e that when we talk =0Aabout the authorization code grant then a refresh to= ken is not the only =0Akey that uniquely identifies a client instance:=0A= =0AInitially it is a client id + code grant, a refresh token does not offer= =0Aan extra uniqueness at the point of the client device requesting an =0A= access token with a code. Refresh token only starts acting as the key =0Acl= ient instance identifier at a refresh token grant time.=0A=0ASorry for a lo= ng email, I'm very likely missing something, so any =0Aclarifications will = be welcome=0A=0AThanks, Sergey=0A=0A=0A=0A=0A=0A=0A=0A> -bill=0A>=0A>=0A> O= n Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin=0A> wrote:=0A>=0A>=0A> Hi=0A>=0A> I'm finding the answers from John interest= ing but I'm failing to=0A> understand why refresh tokens are mentioned in s= cope of identifying the=0A> specific client instances.=0A>=0A> AFAIK refres= h tokens would only go on the wire, assuming they are=0A> supported, when a= client exchanges a grant for a new access token.=0A> And when the client u= ses a refresh token grant.=0A>=0A> Was it really about a refresh token gran= t where the incoming client id=0A> and refresh token pair can uniquely iden= tify the actual client instance=0A> ? That would make sense.=0A>=0A> Someth= ing else I'd like to clarify.=0A> John mentions a refresh token is created = at the authorization grant=0A> initialization time. Would it make any diffe= rence, as far as the=0A> security properties of a grant are concerned, if r= efresh token was only=0A> created at a grant to access token exchange point= of time ?=0A>=0A> Thanks, Sergey=0A>=0A> On 27/06/14 19:21, John Bradley w= rote:=0A>=C2=A0 > Inline=0A>=C2=A0 >=0A>=C2=A0 > On Jun 27, 2014, at 1:24 P= M, Madjid Nakhjiri =0A>=C2=A0 > >> wrote:=0A>=C2=A0 >=0A>=C2=A0 >> Hi John,=0A>=C2=A0 >> Thank you for y= our reply. Would appreciate if you consider my inline=0A>=C2=A0 >> comments= below and respond again!=0A>=C2=A0 >> R,=0A>=C2=A0 >> Madjid=0A>=C2=A0 >> = *From:*John Bradley [mailto:ve7jtb@ve7jtb.com=0A> ]=0A>=C2=A0 >> *Sent:*Wednesday, June 25, 2014 5:56 PM=0A>=C2=A0 >> *To:*M= adjid Nakhjiri=0A>=C2=A0 >> *Cc:*oauth@ietf.org >=0A>=C2=A0 >> *Subject:*Re:= [OAUTH-WG] refresh tokens and client instances=0A>=C2=A0 >> In 3.3 It is s= aying that the refresh token is a secret that the=0A>=C2=A0 >> Authorizatio= n server has bound to the client_id, that the=0A>=C2=A0 >> Authorization se= rver effectively uses to differentiate between=0A>=C2=A0 >> instances of th= at client_id.=0A>=C2=A0 >> Madjid>>If I have 10,000s of devices, each with = an instance of the=0A>=C2=A0 >> OAUTH client, but they are all using the sa= me client ID, how would the=0A>=C2=A0 >> server know which token to use for= what client? unless when I am=0A>=C2=A0 >> creating a token, I also includ= e something that uniquely identifies=0A>=C2=A0 >> each instance? Don=E2=80= =99t I have to use SOMETHING that is unique to that=0A>=C2=A0 >> instance (= user grant/ID?)?=0A>=C2=A0 > When the grant is issued you create and store = a refresh token which is=0A>=C2=A0 > effectively the identifier for that in= stance/grant combination.=0A>=C2=A0 > When it comes back on a request to th= e token endpoint you look up the=0A>=C2=A0 > grants associated with it.=C2= =A0 You also hack that the client_id sent in=0A>=C2=A0 > the request matche= s to detect errors mostly)=0A>=C2=A0 >=0A>=C2=A0 >> When the refresh token = is generated, it can be stored in a table with=0A>=C2=A0 >> the client_id a= nd the information about the grant.=C2=A0 You could also do=0A>=C2=A0 >> it= statelesly by creating a signed object as the refresh token.=0A>=C2=A0 >> = Madjid>>agreed, but for the signed object to be self-sustained, again=0A>= =C2=A0 >> would I not need something beyond a =E2=80=9Cpopulation=E2=80=9D = client_ID? Are we=0A>=C2=A0 >> prescriptive what =E2=80=9Cinformation about= the grant=E2=80=9D is?=0A>=C2=A0 > You would be creating a bearer token as= long as the AS signs it you can=0A>=C2=A0 > put whatever grant grant info = you like in it, that is implementation=0A>=C2=A0 > specific.=C2=A0 It=C2=A0= could be a list of the scopes granted and the subject.=0A>=C2=A0 >> The sp= ec is silent on the exact programming method that the=0A>=C2=A0 >> Authoriz= ation server uses.=0A>=C2=A0 >> Madjid>>Are there any other specs in IETF o= r elsewhere (OASIS, etc?)=0A>=C2=A0 >> that prescribe token calculation (e.= g. hash function, parameters, etc)?=0A>=C2=A0 >=0A>=C2=A0 > You can look at= JOSE and JWT for a way to create tokens=0A>=C2=A0 > http://tools.ietf.org/= html/draft-ietf-oauth-json-web-token=0A>=C2=A0 >> In 3.7 Deployment indepen= dent describes using the same client_id=0A>=C2=A0 >> across multiple instan= ces of a native client, or multiple instances of=0A>=C2=A0 >> a Java Script= client running in a browsers with the same callback uri.=0A>=C2=A0 >> Sinc= e the publishing of this RFC we have also developed a spec for=0A>=C2=A0 >>= dynamic client registration so it is possible to give every native=0A>=C2= =A0 >> client it's own client_id and secret making them confidential client= s.=0A>=C2=A0 >> Madjid>>I would need to look at those specs, however, I tho= ught that=0A>=C2=A0 >> the =E2=80=9Cconfidential client=E2=80=9D designatio= n has to do with the client=0A>=C2=A0 >> ability to hold secrets and perfor= m a-by-server-acceptable=0A>=C2=A0 >> authentication. Does dynamic client r= egistration affect client=E2=80=99s=0A>=C2=A0 >> ability in that aspect?=0A= >=C2=A0 >=0A>=C2=A0 > Yes it doesn't require the secret to be in the downlo= aded instance of=0A>=C2=A0 > the native app.=C2=A0 It can be populated at f= irst run, changing it from=0A>=C2=A0 > public to confidential.=0A>=C2=A0 > = Confidential is not just for web servers any more.=0A>=C2=A0 >> There is al= so a middle ground some people take by doing a proof of=0A>=C2=A0 >> posses= sion for code in native applications to prevent the interception=0A>=C2=A0 = >> of responses to the client by malicious applications on the device.=0A>= =C2=A0 >> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/=0A>= =C2=A0 >> John B.=0A>=C2=A0 >> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri= =0A>=C2=A0 >> <= mailto:m.nakhjiri@samsung.com >> wrote:=0A>= =C2=A0 >>=0A>=C2=A0 >>=0A>=C2=A0 >> Hi all,=0A>=C2=A0 >> I am new to OAUTH = list and OAUTH, so apologies if this is very=0A> off-topic.=0A>=C2=A0 >> I = am evaluating an OAUTH 2.0 implementation that is done based on bare=0A>=C2= =A0 >> bone base OAUTH2.0 RFC. From what I understand, many (or some) clien= t=0A>=C2=A0 >> implementations use a =E2=80=9Cglobal ID/secret=E2=80=9D pai= r for all instances of the=0A>=C2=A0 >> client.=C2=A0 Looking at RFC 6819 a= nd there seem to be a whole page on this=0A>=C2=A0 >> topic, if I understan= d it correctly. So questions:=0A>=C2=A0 >> 1)Section 3.7 talks about deploy= ment-independent versus deployment=0A>=C2=A0 >> specific client IDs. I am g= uessing =E2=80=9Cdeployment-independent=E2=80=9D refers to=0A>=C2=A0 >> wha= t I called =E2=80=9Cglobal=E2=80=9D, meaning if I have the same client with= the=0A>=C2=A0 >> same client ID installed in many end devices, that is a d= eployment=0A>=C2=A0 >> independent case, correct?=0A>=C2=A0 >> 2)Section 3.= 3 on refresh token mentions that the token is secret bound=0A>=C2=A0 >> to = the client ID and client instance. Could somebody please point me=0A>=C2=A0= >> to where the token generation and binding is described? Also how is=0A>= =C2=A0 >> the client instance is identified?=0A>=C2=A0 >> Thanks a lot in a= dvance,=0A>=C2=A0 >> Madjid Nakhjiri=0A>=C2=A0 >> _________________________= ______________________=0A>=C2=A0 >> OAuth mailing list=0A>=C2=A0 >> OAuth@i= etf.org >=0A>=C2=A0 >> https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>= =C2=A0 >=0A>=C2=A0 >=0A>=C2=A0 >=0A>=C2=A0 > ______________________________= _________________=0A>=C2=A0 > OAuth mailing list=0A>=C2=A0 > OAuth@ietf.org= =0A>=C2=A0 > https://www.ietf.org/mailman/listinfo/= oauth=0A=0A>=C2=A0 >=0A>=0A> ______________________________________________= _=0A> OAuth mailing list=0A> OAuth@ietf.org =0A> htt= ps://www.ietf.org/mailman/listinfo/oauth=0A>=0A> --469468616-1639230998-1404407676=:52412 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You might have a public client, the Flickr client = for example (which uses OAuth 1 right now but it's a useful example) where = the client ID is baked into the install.  In this case binding the tok= en to the client ID means only that someone who steals the token and tries = to use it with a different client ID would fail.

With DynReg that client could generate a nonce and include it in a dynamically registered client ID and then the credenti= al could be bound to that specific software instance.

A 3rd possibility is multiple clients on a device sharing the = same auth context, in which case they all use the same library perhaps and = so several installed apps all would share the same "client id" from the ser= vers perspective (the one for the auth API) but they might each get differe= nt scopes.


=
On Thursday, July 3, 20= 14 9:28 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:


Hi
On 0= 3/07/14 16:40, Bill Mills wrote:
> Implementations may= /SHOULD bind refresh tokens to specific client
> insta= nces.  Yes, it's possible that the client ID with dynamic
> registration is unique to each client, but many of the token the= ft use
> cases include the possibility of stealing the= client ID too if you know
> you need to.
>
What exactly is a 'client instance' when we ta= lk about having a single
client id registration, with the id shared betwe= en multiple devices
(which is what I believe this thread= started from).

What I understood, as = far as the authorization service is concerned, a
'client= instance' for AS is a combination of a client id + code grant.

+ (optional) refresh token (as was mentioned earl= ier). But it appears to
me a client instance can be uniq= uely identified by two values only
without a refresh tok= en.

When a user authorizes a given dev= ice and gets a grant code and enters
it into the device = securely we have a 'client instance' ready to get the
to= kens, with that device (client instance) using a client id and the
grant code to get an access token and a refresh token.

Lets say it sends a "client_id=3D1&code=3D2" sequence t= o get the tokens.
A client id + a code value constitutes = a client instance, because a code
would be unique per ev= ery authorization, right ?

So the serv= ice will return an access token + refresh token to the
d= evice. Refresh Token could've been associated with a record containing
a client id + grant code info earlier or at the moment the c= ode is
exchanged for an access token.
=
During the subsequent refresh token grant request we hav= e "client id +
refresh token" as a client instance.

I'm not sure what exactly I'd like to ask = here :-), but I wonder if the
above sounds right, then I= guess I'd like to conclude that when we talk
about the = authorization code grant then a refresh token is not the only
key that uniquely = identifies a client instance:

Initiall= y it is a client id + code grant, a refresh token does not offer
an extra uniqueness at the point of the client device requesting = an
access token with a code. Refresh token only starts a= cting as the key
client instance identifier at a refresh= token grant time.

Sorry for a long em= ail, I'm very likely missing something, so any
clarifica= tions will be welcome

Thanks, Sergey


<= br clear=3D"none">


= > -bill
>
>
= > On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin
= > <sberyozkin@gmail.com> wrote:
>
>
> Hi
>
> I'm finding the answers from John interesting but I'm failing to
> understand why refresh tokens are mentioned in scope of= identifying the
> specific client instances.
>
> AFAIK refresh tokens would only go on= the wire, assuming they are
> supported, when a clien= t exchanges a grant for a new access token.
> And when= the client uses a refresh token grant.
>
> Was it really about a refresh token grant where the incoming cli= ent id
> and refresh token pair can uniquely identify = the actual client instance
> ? That would make sense.<= br clear=3D"none">>
> Something else I'd like to clarify.
= > John mentions a refresh token is created at the authorization grant> initialization time. Would it make any difference, as = far as the
> security properties of a grant are concer= ned, if refresh token was only
> created at a grant to= access token exchange point of time ?
>
> Thanks, Sergey
>
> On 2= 7/06/14 19:21, John Bradley wrote:
>  > Inline=
>  >
>  > On Jun= 27, 2014, at 1:24 PM, Madjid Nakhjiri <m.nakhji= ri@samsung.com
> <mailto:m.nakhjiri@samsung.com>
>  > <mailto:m.nakhjiri= @samsung.com <mailto:m.nakhjiri@samsung.com<= /a>>>> wrote:
>  >
= >  >> Hi John,
>  >> Thank yo= u for your reply. Would appreciate if you consider my inline
>  >> comments below and respond again!
>  >> R,
>  >> Madjid
>  >> *From:*John Bradley [mailto:v= e7jtb@ve7jtb.com
> <mailto:ve7jtb@ve7jtb.com>]
>  >> *Sent:*Wednesday, June 25, 2014 5:56 PM
>  >> *To:*Madjid Nakhjiri
>&n= bsp; >> *Cc:*oauth@ietf.org <mailto:oauth@ietf= .org> <mailto:oauth@ietf.org
> &= lt;mailto:oauth@ietf.org>>
>  &= gt;> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
>  >> In 3.3 It is saying that the refresh token = is a secret that the
>  >> Authorization se= rver has bound to the client_id, that the
>  >> Authorization server effect= ively uses to differentiate between
>  >> i= nstances of that client_id.
>  >> Madjid>= ;>If I have 10,000s of devices, each with an instance of the
>  >> OAUTH client, but they are all using the same cl= ient ID, how would the
>  >> server know wh= ich token to use for what client? unless when I am
>&n= bsp; >> creating a token, I also include something that uniquely iden= tifies
>  >> each instance? Don=E2=80=99t I= have to use SOMETHING that is unique to that
>  = >> instance (user grant/ID?)?
>  > When = the grant is issued you create and store a refresh token which is
>  > effectively the identifier for that instance/gran= t combination.
>  > When it comes back on a request to the toke= n endpoint you look up the
>  > grants associa= ted with it.  You also hack that the client_id sent in
>  > the request matches to detect errors mostly)
>  >
>  >> When the refre= sh token is generated, it can be stored in a table with
&= gt;  >> the client_id and the information about the grant. = You could also do
>  >> it statelesly by c= reating a signed object as the refresh token.
>  = >> Madjid>>agreed, but for the signed object to be self-sustain= ed, again
>  >> would I not need something = beyond a =E2=80=9Cpopulation=E2=80=9D client_ID? Are we
&= gt;  >> prescriptive what =E2=80=9Cinformation about the grant= =E2=80=9D is?
>  > You would be creating a bearer token as lon= g as the AS signs it you can
>  > put whatever= grant grant info you like in it, that is implementation
= >  > specific.  It  could be a list of the scopes gran= ted and the subject.
>  >> The spec is sile= nt on the exact programming method that the
>  &g= t;> Authorization server uses.
>  >> Mad= jid>>Are there any other specs in IETF or elsewhere (OASIS, etc?)
>  >> that prescribe token calculation (e.g. h= ash function, parameters, etc)?
>  >
>  > You can look at JOSE and JWT for a way to create = tokens
>  > http://tools.ietf.org/html/draft-ietf-oauth-json-web-tok= en
>  >> In 3.7 Deployment independent = describes using the same client_id
>  >> ac= ross multiple instances of a native client, or multiple instances of
>  >> a Java Script client running in a browsers = with the same callback uri.
>  >> Since the= publishing of this RFC we have also developed a spec for
>  >> dynamic client registration so it is possible to give = every native
>  >> client it's own client_i= d and secret making them confidential clients.
> = >> Madjid>>I would need to look at those specs, however, I tho= ught that
>  >> the =E2=80=9Cconfidential c= lient=E2=80=9D designation has to do with the client
>=   >> ability to hold secrets and perform a-by-server-acceptable
>&= nbsp; >> authentication. Does dynamic client registration affect clie= nt=E2=80=99s
>  >> ability in that aspect?<= br clear=3D"none">>  >
>  > Yes it = doesn't require the secret to be in the downloaded instance of
>  > the native app.  It can be populated at first ru= n, changing it from
>  > public to confidentia= l.
>  > Confidential is not just for web serve= rs any more.
>  >> There is also a middle g= round some people take by doing a proof of
>  >= ;> possession for code in native applications to prevent the interceptio= n
>  >> of responses to the client by malic= ious applications on the device.
>  >> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
>  >> John B.
> = ; >> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri <m.nakhjiri@samsung.com
> <mailto:m.nakhjiri@samsung.com>
>&nb= sp; >> <mailto:m.nakhjiri@samsung.com = <mailto:m.nakhjiri@samsung.com>>> w= rote:
>  >>
>  &g= t;>
>  >> Hi all,
>  >> I am new to OAUTH l= ist and OAUTH, so apologies if this is very
> off-topi= c.
>  >> I am evaluating an OAUTH 2.0 imple= mentation that is done based on bare
>  >> = bone base OAUTH2.0 RFC. From what I understand, many (or some) client
>  >> implementations use a =E2=80=9Cglobal ID/s= ecret=E2=80=9D pair for all instances of the
>  &= gt;> client.  Looking at RFC 6819 and there seem to be a whole page= on this
>  >> topic, if I understand it co= rrectly. So questions:
>  >> 1)Section 3.7 = talks about deployment-independent versus deployment
>=   >> specific client IDs. I am guessing =E2=80=9Cdeployment-inde= pendent=E2=80=9D refers to
>  >> what I cal= led =E2=80=9Cglobal=E2=80=9D, meaning if I have the same client with the
>  >> same client= ID installed in many end devices, that is a deployment
&= gt;  >> independent case, correct?
>  = >> 2)Section 3.3 on refresh token mentions that the token is secret b= ound
>  >> to the client ID and client inst= ance. Could somebody please point me
>  >> = to where the token generation and binding is described? Also how is
>  >> the client instance is identified?
>  >> Thanks a lot in advance,
&g= t;  >> Madjid Nakhjiri
>  >> ___= ____________________________________________
>  &= gt;> OAuth mailing list
>  >> = OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.or= g
> <mailto:OAuth@ietf.org>><= br clear=3D"none">>  >> https://www.ietf.org/ma= ilman/listinfo/oauth
>
> = ; >
>  >
>  ><= br clear=3D"none">>  > _________________________________________= ______
>  > OAuth mailing list
>  > OAuth@ietf.org <mailto:OAuth@ietf.org>
&g= t;  > https://www.ietf.org/mailman/listinfo/oauth=

> = ; >
>
> ______________________= _________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.or= g>
> https://www.ietf.org/mailman= /listinfo/oauth
>
>



--469468616-1639230998-1404407676=:52412-- From nobody Thu Jul 3 10:31:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D81B1B2A0B for ; Thu, 3 Jul 2014 10:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0jhi6dpZK7W for ; Thu, 3 Jul 2014 10:31:09 -0700 (PDT) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394FB1B2996 for ; Thu, 3 Jul 2014 10:31:09 -0700 (PDT) Received: from mail-ie0-f171.google.com ([209.85.223.171]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKU7WTXKb9DJdy1QML7a0cPDPCS9fVhdyI@postini.com; Thu, 03 Jul 2014 10:31:09 PDT Received: by mail-ie0-f171.google.com with SMTP id x19so545479ier.30 for ; Thu, 03 Jul 2014 10:31:08 -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=opjPehS4/+qYXkq3DHlAy8N6TVTN6Ig4Kn7DVkR7aO4=; b=SJ9bt9iAMsBYZhmT76QGWQ8mTKrXISFm1Gf6MsgaxnsAK66fHu9CKXobeTaWBX+ZYs wIuLHLtxy6xjOWmRLEWkHhGTVKfkVAl3wghUpRjNDUbANAK6G/Ejz1dK0PqfYmoN+YUs Ud97yVSXGJz3pB/EGvms55R3mb7VZxKUvIMCW1LIkOJP/QI1aPQ9wO144DxrRsz881WU kxGCp4vm4dsBR0CTaNOKdj3Jx0cMRXBhCuj8qHDSSI23dN9s+8lpHq0njqKX3DJTa/jK zYQeJj6dvoc5r5YqsGpoQQB0ZkJPqhW0U8NT2rRcItEwNDilrQxcoSfBPIccoGip7rpD KhJw== X-Gm-Message-State: ALoCoQnBceLxiyuo6lrAMNDkpUHEIGtBnOcCyV53A9E9f/zMXA3JTpf8/7L8T4O0WluNIwO2rbnxr4aQIQE1NiX8/wkF3Tzsn2Ufu0WmOxmA7gM0KDYllvmpUO8/HwbXMyOs7GyB9rUF X-Received: by 10.50.36.106 with SMTP id p10mr58172782igj.9.1404408668586; Thu, 03 Jul 2014 10:31:08 -0700 (PDT) X-Received: by 10.50.36.106 with SMTP id p10mr58172771igj.9.1404408668484; Thu, 03 Jul 2014 10:31:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Thu, 3 Jul 2014 10:30:38 -0700 (PDT) In-Reply-To: <53B41202.8080008@gmx.net> References: <53B41202.8080008@gmx.net> From: Brian Campbell Date: Thu, 3 Jul 2014 11:30:38 -0600 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e0115ebd0ce94c404fd4d5f08 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/b2JknXUFjde8fc06tab77aGm7kM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Agenda requests, please 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, 03 Jul 2014 17:31:11 -0000 --089e0115ebd0ce94c404fd4d5f08 Content-Type: text/plain; charset=UTF-8 Unfortunately I won't be in Toronto for #90 due to a conflict that week with the Cloud Identity Summit . Hopefully nothing will come up from the IESG on the assertion bundle but I trust Mike can handle it, if something requiring agenda time does surface between now and then. On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig wrote: > Hi all, > > by next Monday we have to post a draft agenda for the upcoming IETF > meeting. > > If you would like to talk about a specific topic, please let us know. > > My impression regarding the status of our work is the following: > > > -------- Current WG items ------- > > * Dynamic Client Registration > > We are waiting for an update but the document could be completed by the > IETF meeting. ==> no presentation time. > > * JWT > > Currently in IESG processing and a new draft update has just been > submitted. ==> no presentation time (#) > > * Assertion Bundle > > Currently in IESG processing. ==> no presentation time (#) > > * Dynamic Client Registration Management Protocol > > We had a discussion about this work at the last IETF meeting and the > path forward looked somewhat difficult. Nothing has happened since that > time and I am inclined to remove it from the list of WG items. > > * Proof-of-Possession Security > > We have several new documents and I hope we can turn into working group > items already before the meeting. We would then use the meeting time to > discuss open issues. > > #: No presentation time unless some challenging comments from the IESG > surface. > > -------- Proposed New WG items ------- > > I would also like to put the following items on the agenda. > > * Token Introspection > > * draft-sakimura-oauth-tcse-03 > > -------- Other items ------- > > Phil might want to bring up this item since it was discussed on the > list: draft-hunt-oauth-v2-user-a4c > > Other ideas/suggestions? > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e0115ebd0ce94c404fd4d5f08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Unfortunately I won't be in Toronto for #90 due t= o a conflict that week with the Cloud Identity Summit.

Hopefully nothing will come up from the IESG on the assertion bu= ndle but I trust Mike can handle it, if something requiring agenda time doe= s surface between now and then.


On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofeni= g <hannes.tschofenig@gmx.net> wrote:
Hi all,

by next Monday we have to post a draft agenda for the upcoming IETF
meeting.

If you would like to talk about a specific topic, please let us know.

My impression regarding the status of our work is the following:


-------- Current WG items -------

* Dynamic Client Registration

We are waiting for an update but the document could be completed by the
IETF meeting. =3D=3D> no presentation time.

* JWT

Currently in IESG processing and a new draft update has just been
submitted. =3D=3D> no presentation time (#)

* Assertion Bundle

Currently in IESG processing. =3D=3D> no presentation time (#)

* Dynamic Client Registration Management Protocol

We had a discussion about this work at the last IETF meeting and the
path forward looked somewhat difficult. Nothing has happened since that
time and I am inclined to remove it from the list of WG items.

* Proof-of-Possession Security

We have several new documents and I hope we can turn into working group
items already before the meeting. We would then use the meeting time to
discuss open issues.

#: No presentation time unless some challenging comments from the IESG
surface.

-------- Proposed New WG items -------

I would also like to put the following items on the agenda.

* Token Introspection

* draft-sakimura-oauth-tcse-03

-------- Other items -------

Phil might want to bring up this item since it was discussed on the
list: draft-hunt-oauth-v2-user-a4c

Other ideas/suggestions?

Ciao
Hannes


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


--089e0115ebd0ce94c404fd4d5f08-- From nobody Thu Jul 3 10:54:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDA81B2869 for ; Thu, 3 Jul 2014 10:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4uAU3EXddsx for ; Thu, 3 Jul 2014 10:54:36 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CFB1A0339 for ; Thu, 3 Jul 2014 10:54:36 -0700 (PDT) X-AuditID: 12074425-f79766d000006da8-9b-53b598da6e50 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 9F.48.28072.AD895B35; Thu, 3 Jul 2014 13:54:34 -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 s63HsXBA005652; Thu, 3 Jul 2014 13:54:34 -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 s63HsLav009609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 3 Jul 2014 13:54:25 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_BE9EAFB2-3947-41E6-9C64-75B081B4450D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Justin Richer In-Reply-To: Date: Thu, 3 Jul 2014 13:54:19 -0400 Message-Id: References: <53B41202.8080008@gmx.net> To: Brian Campbell X-Mailer: Apple Mail (2.1878.2) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEKsWRmVeSWpSXmKPExsUixG6nontrxtZggxc7zCxW/7/JaLF05z1W i5NvX7E5MHss3rSfzWPJkp9MHnePXmQJYI7isklJzcksSy3St0vgyvj+gbVgsn3FgVf72RsY j5h2MXJwSAiYSPx/WdjFyAlkiklcuLeerYuRi0NIYDaTxI19D5ghnA2MEr1HdrJCODeYJGZO 38cC4jALTGKU2L79NCtIP6+AgcS1/vWMILawgL7EnM+X2EFsNgFVifkrbzGB2JwCgRJt+1Yz g9gsAioS0/d0gdUzC8RKrF14mAXkJF4BK4nlu+NAwkIC2RIH50GUiwCNvP10DjvEqfISM9pP sE9gFJiF7IxZSM6YBTY2SeLk13msELa2xLKFr5khbAOJp52vsIjrS7x5N4cJwpaX2P52DlTc UmLxzBssELatxK2+BVA1dhKPpi1iXcDIvYpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXQi83s0Qv NaV0EyM4+lxUdzBOOKR0iFGAg1GJh9ejaGuwEGtiWXFl7iFGSQ4mJVHeI9OAQnxJ+SmVGYnF GfFFpTmpxYcYVYB2Pdqw+gKjFEtefl6qkgivUztQHW9KYmVValE+TJk0B4uSOO9ba6tgIYH0 xJLU7NTUgtQimKwMB4eSBO+R6UCNgkWp6akVaZk5JQhpJg7OQ4wSHDxAw1+C1PAWFyTmFmem Q+RPMSpKifPuB0kIgCQySvPgemFJ8xWjONBbwrynQKp4gAkXrvsV0GAmoMFsTGCDSxIRUlIN jP4Lc6bdE9ufcqtIQ/9A9pynE6/NnZ2RPa32jNyxlw/sXps5mgj55qyc/uAFM2/xx2fCAcsL tD1kDlz6FHYnoWPSj2lCJz+Uv9+t+l2VSf/1v77a8mcTBbsSa9J2TlO/dUl6fYPpzBcLPvS8 EDgc49FyjNlVmyHeyLvq9PlFkq5/9tnbXa/1r1BiKc5INNRiLipOBAARDq70dQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fxu5Kc6Mue9YRX2JvIhF7XElci0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Agenda requests, please 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, 03 Jul 2014 17:54:40 -0000 --Apple-Mail=_BE9EAFB2-3947-41E6-9C64-75B081B4450D Content-Type: multipart/alternative; boundary="Apple-Mail=_BE54CCA6-B384-4453-B2FD-2B4A219974E1" --Apple-Mail=_BE54CCA6-B384-4453-B2FD-2B4A219974E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 By the way, I will also not likely be in Toronto for most of the week = due to the same conflict (thanks a lot, Ping), but I might be able to = make it in time for the Thursday meeting depending on how travel = arrangements get sorted out. =97 Justin On Jul 3, 2014, at 1:30 PM, Brian Campbell = wrote: > Unfortunately I won't be in Toronto for #90 due to a conflict that = week with the Cloud Identity Summit. >=20 > Hopefully nothing will come up from the IESG on the assertion bundle = but I trust Mike can handle it, if something requiring agenda time does = surface between now and then. >=20 >=20 > On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig = wrote: > Hi all, >=20 > by next Monday we have to post a draft agenda for the upcoming IETF > meeting. >=20 > If you would like to talk about a specific topic, please let us know. >=20 > My impression regarding the status of our work is the following: >=20 >=20 > -------- Current WG items ------- >=20 > * Dynamic Client Registration >=20 > We are waiting for an update but the document could be completed by = the > IETF meeting. =3D=3D> no presentation time. >=20 > * JWT >=20 > Currently in IESG processing and a new draft update has just been > submitted. =3D=3D> no presentation time (#) >=20 > * Assertion Bundle >=20 > Currently in IESG processing. =3D=3D> no presentation time (#) >=20 > * Dynamic Client Registration Management Protocol >=20 > We had a discussion about this work at the last IETF meeting and the > path forward looked somewhat difficult. Nothing has happened since = that > time and I am inclined to remove it from the list of WG items. >=20 > * Proof-of-Possession Security >=20 > We have several new documents and I hope we can turn into working = group > items already before the meeting. We would then use the meeting time = to > discuss open issues. >=20 > #: No presentation time unless some challenging comments from the IESG > surface. >=20 > -------- Proposed New WG items ------- >=20 > I would also like to put the following items on the agenda. >=20 > * Token Introspection >=20 > * draft-sakimura-oauth-tcse-03 >=20 > -------- Other items ------- >=20 > Phil might want to bring up this item since it was discussed on the > list: draft-hunt-oauth-v2-user-a4c >=20 > Other ideas/suggestions? >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_BE54CCA6-B384-4453-B2FD-2B4A219974E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 By the = way, I will also not likely be in Toronto for most of the week due to = the same conflict (thanks a lot, Ping), but I might be able to make it = in time for the Thursday meeting depending on how travel arrangements = get sorted out.

 =97 = Justin

On Jul 3, 2014, at 1:30 PM, Brian = Campbell <bcampbell@pingidentity.com&= gt; wrote:

Unfortunately I won't be in = Toronto for #90 due to a conflict that week with the Cloud Identity = Summit.

Hopefully nothing will come up from the IESG on the assertion = bundle but I trust Mike can handle it, if something requiring agenda = time does surface between now and then.


On Wed, Jul 2, 2014 at 8:06 AM, Hannes = Tschofenig <hannes.tschofenig@gmx.net> = wrote:
Hi all,

by next Monday we have to post a draft agenda for the upcoming IETF
meeting.

If you would like to talk about a specific topic, please let us = know.

My impression regarding the status of our work is the following:


-------- Current WG items -------

* Dynamic Client Registration

We are waiting for an update but the document could be completed by = the
IETF meeting. =3D=3D> no presentation time.

* JWT

Currently in IESG processing and a new draft update has just been
submitted. =3D=3D> no presentation time (#)

* Assertion Bundle

Currently in IESG processing. =3D=3D> no presentation time (#)

* Dynamic Client Registration Management Protocol

We had a discussion about this work at the last IETF meeting and the
path forward looked somewhat difficult. Nothing has happened since = that
time and I am inclined to remove it from the list of WG items.

* Proof-of-Possession Security

We have several new documents and I hope we can turn into working = group
items already before the meeting. We would then use the meeting time = to
discuss open issues.

#: No presentation time unless some challenging comments from the = IESG
surface.

-------- Proposed New WG items -------

I would also like to put the following items on the agenda.

* Token Introspection

* draft-sakimura-oauth-tcse-03

-------- Other items -------

Phil might want to bring up this item since it was discussed on the
list: draft-hunt-oauth-v2-user-a4c

Other ideas/suggestions?

Ciao
Hannes


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


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

= --Apple-Mail=_BE54CCA6-B384-4453-B2FD-2B4A219974E1-- --Apple-Mail=_BE9EAFB2-3947-41E6-9C64-75B081B4450D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTtZjLAAoJEDPAngkbd+w9PH4H/2ckVh5hvLjorF0/pX3ssTCd 6Ysb8fZgCB7hFYMCdFf2/ROJ0hIGKkHD6Og33LLGqjCBfxjmNn6dKGawrsPwY333 ++US8PKtHWUxVvOGAZvAoHsJ7gZOsTwXckxnwVbRWQUFZX9lwGAA7Z5ROcC2nN2G c9uszS8tOOYjsJlVJCWUySbKdHFb1/kcH47VGNpxEMSI9/98sMP2+9BQJM/2Tip0 ox1uRKsSBk6rA/qgO7q/o7Xwb5+CmVGIzH0WsadNS03kanUueBVdT/UgfBfRMm16 kq76mQL6yFEp8U1ppOyDY5JrOKaLFOFhLHIP5mSFs2oDfGKcTZ8H/u0mXbBoiCs= =RuRK -----END PGP SIGNATURE----- --Apple-Mail=_BE9EAFB2-3947-41E6-9C64-75B081B4450D-- From nobody Thu Jul 3 10:57:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451131A0339 for ; Thu, 3 Jul 2014 10:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqPJ_FpSuuxd for ; Thu, 3 Jul 2014 10:57:33 -0700 (PDT) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520F81A024F for ; Thu, 3 Jul 2014 10:57:33 -0700 (PDT) Received: from [98.139.215.141] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2014 17:57:32 -0000 Received: from [98.139.212.212] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2014 17:57:32 -0000 Received: from [127.0.0.1] by omp1021.mail.bf1.yahoo.com with NNFMP; 03 Jul 2014 17:57:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 316218.14199.bm@omp1021.mail.bf1.yahoo.com Received: (qmail 21999 invoked by uid 60001); 3 Jul 2014 17:57:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1404410252; bh=ZBoSQ+/OT0kmWpDzzwun/VqGxcrvEv9DojFYAimd/fw=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IUFi0Ul1KmCkpulTRpwCtMKausnlfnt8AvC9SssdAeWX4PSB/it6zPZnEMMIg9tbC/9car12beJzSzzNyTenzQZsJIdeAGIPOQPGm3LLT7+vmcJEzQIVAsRJii5AYNFusFzND84YkwU8aNTcAM6ahCJ5BxDrs6VZLlDEB9uFI7A= X-YMail-OSG: ixitXesVM1kSZrjADoAAXmd4I8RP.NTYwWBP8CBqDeuv9Je nRFq6bqWkamJ2acTejJB51p1MRvaiIBzydNeOPBkw8sNmUyGMNCzKbAx.mBR IokYLK0ZGPFrspqCM9OkigDEi97nH6RR8MlFkL_M8RxcGCkxM9SReAsJYInt aUqWjVStNIBLIkvOeZh29RaFDZv9MGPNoOfguI7152RUxRiXsG0.GpOUQ0Bg 8SiDUkxy61LT.ghOc5HvssxC2RGiM87mAkzEz3zm_ua1h4fXJTyC0e8a3QpT hlx8OOXAqGnhB69ev1pQVmSNoqHIsVDoDCqrGrO_9bAOZAzwXHTCrX5suNKZ RGe9NrpuEozyeKCWbEzuVvhhs7api4lU6u9DjN5BxW_3VhdJLC3l0EMQvcGf 0NfiFQhLhxBgsAbB_Aw1giWAibBjXiP1qO1JprU4qoETfG2DEzACxTBwLKgs hLfJN8OKA9PB0ZcZEVukTSCx5Fv4jYF2XIfTXdE7cK3i06PLG.NcTaG0zpf0 nQH0EGFi51JSmDHYl4WW416bX7HeHkpUWcyYeISdBHswesri67LcPn8m7J_l 2UATf4kmGigZeUCYzHECGE.QQ4ejt9rntWGsihwy5n3tDKILb_e9yk1m8Cr6 5RFtyDvFbJVyemgP8V.g0w6pjFA-- Received: from [131.107.0.71] by web142802.mail.bf1.yahoo.com via HTTP; Thu, 03 Jul 2014 10:57:32 PDT X-Rocket-MIMEInfo: 002.001, SSBqdXN0IHN0YXJ0ZWQgYSBuZXcgam9iIGFuZCB3b24ndCBiZSB0aGVyZSwgcHJvYmFibHkgbm90IGxpc3RlbmluZyBpbiBvbiB0aGUgY2hhdCBlaXRoZXIuLi4uCgoKT24gVGh1cnNkYXksIEp1bHkgMywgMjAxNCAxMDozOSBBTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPiB3cm90ZToKIAoKClVuZm9ydHVuYXRlbHkgSSB3b24ndCBiZSBpbiBUb3JvbnRvIGZvciAjOTAgZHVlIHRvIGEgY29uZmxpY3QgdGhhdCB3ZWVrIHdpdGggdGhlIENsb3VkIElkZW50aXR5IFN1bW1pdC4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.191.1 References: <53B41202.8080008@gmx.net> Message-ID: <1404410252.6507.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Thu, 3 Jul 2014 10:57:32 -0700 From: Bill Mills To: Brian Campbell , Hannes Tschofenig In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-402735121-1404410252=:6507" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/pJjzSK_QbWJ8tWPrdg22r2U5uBg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Agenda requests, please X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 17:57:35 -0000 --1397251415-402735121-1404410252=:6507 Content-Type: text/plain; charset=us-ascii I just started a new job and won't be there, probably not listening in on the chat either.... On Thursday, July 3, 2014 10:39 AM, Brian Campbell wrote: Unfortunately I won't be in Toronto for #90 due to a conflict that week with the Cloud Identity Summit. Hopefully nothing will come up from the IESG on the assertion bundle but I trust Mike can handle it, if something requiring agenda time does surface between now and then. On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig wrote: Hi all, > >by next Monday we have to post a draft agenda for the upcoming IETF >meeting. > >If you would like to talk about a specific topic, please let us know. > >My impression regarding the status of our work is the following: > > >-------- Current WG items ------- > >* Dynamic Client Registration > >We are waiting for an update but the document could be completed by the >IETF meeting. ==> no presentation time. > >* JWT > >Currently in IESG processing and a new draft update has just been >submitted. ==> no presentation time (#) > >* Assertion Bundle > >Currently in IESG processing. ==> no presentation time (#) > >* Dynamic Client Registration Management Protocol > >We had a discussion about this work at the last IETF meeting and the >path forward looked somewhat difficult. Nothing has happened since that >time and I am inclined to remove it from the list of WG items. > >* Proof-of-Possession Security > >We have several new documents and I hope we can turn into working group >items already before the meeting. We would then use the meeting time to >discuss open issues. > >#: No presentation time unless some challenging comments from the IESG >surface. > >-------- Proposed New WG items ------- > >I would also like to put the following items on the agenda. > >* Token Introspection > >* draft-sakimura-oauth-tcse-03 > >-------- Other items ------- > >Phil might want to bring up this item since it was discussed on the >list: draft-hunt-oauth-v2-user-a4c > >Other ideas/suggestions? > >Ciao >Hannes > > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --1397251415-402735121-1404410252=:6507 Content-Type: text/html; charset=us-ascii
I just started a new job and won't be there, probably not listening in on the chat either....


On Thursday, July 3, 2014 10:39 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:


Unfortunately I won't be in Toronto for #90 due to a conflict that week with the Cloud Identity Summit.

Hopefully nothing will come up from the IESG on the assertion bundle but I trust Mike can handle it, if something requiring agenda time does surface between now and then.


On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

by next Monday we have to post a draft agenda for the upcoming IETF
meeting.

If you would like to talk about a specific topic, please let us know.

My impression regarding the status of our work is the following:


-------- Current WG items -------

* Dynamic Client Registration

We are waiting for an update but the document could be completed by the
IETF meeting. ==> no presentation time.

* JWT

Currently in IESG processing and a new draft update has just been
submitted. ==> no presentation time (#)

* Assertion Bundle

Currently in IESG processing. ==> no presentation time (#)

* Dynamic Client Registration Management Protocol

We had a discussion about this work at the last IETF meeting and the
path forward looked somewhat difficult. Nothing has happened since that
time and I am inclined to remove it from the list of WG items.

* Proof-of-Possession Security

We have several new documents and I hope we can turn into working group
items already before the meeting. We would then use the meeting time to
discuss open issues.

#: No presentation time unless some challenging comments from the IESG
surface.

-------- Proposed New WG items -------

I would also like to put the following items on the agenda.

* Token Introspection

* draft-sakimura-oauth-tcse-03

-------- Other items -------

Phil might want to bring up this item since it was discussed on the
list: draft-hunt-oauth-v2-user-a4c

Other ideas/suggestions?

Ciao
Hannes


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



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


--1397251415-402735121-1404410252=:6507-- From nobody Thu Jul 3 11:02:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022671B2964 for ; Thu, 3 Jul 2014 11:02:34 -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 vtEY6oxBq-11 for ; Thu, 3 Jul 2014 11:02:25 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95DCA1B2870 for ; Thu, 3 Jul 2014 11:02:24 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id ty20so446089lab.17 for ; Thu, 03 Jul 2014 11:02:22 -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=OXPq1PGYvKMyaieMUxrvAxUApOCcI6hUXucm7QhrE9M=; b=WAULWwRiRcWBsKqPTUEbJensM55D6z4q5j3HiKsk6PQ2Vyx9tSgcIAKW+xgOacFESg esvO8NW38VapE6ZyzY5OmSV001QvChEPlA8l8QqtpdcZ5LfAwCpxt3WXvjc5tENksN6+ 4OVNoXsk6ko1IciG8tc1PlDf7XFDJKzh8q5Dgm3+t8j3fPH50gW4uVwS/pdYLxZHDMf+ 1uyH1s7TYQe9pABslx+T6yULeT8O37u22Nty5xyZoDxQ/E7+iCGqh3tjxjN0WtEoIsKt 15ofjuYAHitJx8ISwiHpyh5u7p7+MHVk3FmWTRTZiFEXK7AFpC6GbkrfRvr5TiMeFxh0 k5AQ== MIME-Version: 1.0 X-Received: by 10.152.185.104 with SMTP id fb8mr2516102lac.64.1404410542829; Thu, 03 Jul 2014 11:02:22 -0700 (PDT) Received: by 10.112.253.198 with HTTP; Thu, 3 Jul 2014 11:02:22 -0700 (PDT) In-Reply-To: References: <53B41202.8080008@gmx.net> Date: Thu, 3 Jul 2014 14:02:22 -0400 Message-ID: From: Kathleen Moriarty To: Brian Campbell Content-Type: multipart/alternative; boundary=001a1136936c86379d04fd4dcf40 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ISFpaL9dCvujhAV89O3XpHDyCbA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Agenda requests, please 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, 03 Jul 2014 18:02:34 -0000 --001a1136936c86379d04fd4dcf40 Content-Type: text/plain; charset=UTF-8 I think you'll be okay time-wise. Since the JOSE + JWT drafts have been requested to go as a bundle, I'll have to make sure I get it on a telechat a little further out because of the amount of reading so the drafts get a fair review. We still have to start the IETF last call on those drafts as well. We should know more n the timing soon. I do plan to get the AD reviews out soon for the Oauth drafts that were to follow the first set. On Thu, Jul 3, 2014 at 1:30 PM, Brian Campbell wrote: > Unfortunately I won't be in Toronto for #90 due to a conflict that week > with the Cloud Identity Summit . > > Hopefully nothing will come up from the IESG on the assertion bundle but I > trust Mike can handle it, if something requiring agenda time does surface > between now and then. > > > On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> Hi all, >> >> by next Monday we have to post a draft agenda for the upcoming IETF >> meeting. >> >> If you would like to talk about a specific topic, please let us know. >> >> My impression regarding the status of our work is the following: >> >> >> -------- Current WG items ------- >> >> * Dynamic Client Registration >> >> We are waiting for an update but the document could be completed by the >> IETF meeting. ==> no presentation time. >> >> * JWT >> >> Currently in IESG processing and a new draft update has just been >> submitted. ==> no presentation time (#) >> >> * Assertion Bundle >> >> Currently in IESG processing. ==> no presentation time (#) >> >> * Dynamic Client Registration Management Protocol >> >> We had a discussion about this work at the last IETF meeting and the >> path forward looked somewhat difficult. Nothing has happened since that >> time and I am inclined to remove it from the list of WG items. >> >> * Proof-of-Possession Security >> >> We have several new documents and I hope we can turn into working group >> items already before the meeting. We would then use the meeting time to >> discuss open issues. >> >> #: No presentation time unless some challenging comments from the IESG >> surface. >> >> -------- Proposed New WG items ------- >> >> I would also like to put the following items on the agenda. >> >> * Token Introspection >> >> * draft-sakimura-oauth-tcse-03 >> >> -------- Other items ------- >> >> Phil might want to bring up this item since it was discussed on the >> list: draft-hunt-oauth-v2-user-a4c >> >> Other ideas/suggestions? >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Best regards, Kathleen --001a1136936c86379d04fd4dcf40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think you'll be okay time-wise. =C2=A0Since the JOSE= + JWT drafts have been requested to go as a bundle, I'll have to make = sure I get it on a telechat a little further out because of the amount of r= eading so the drafts get a fair review. =C2=A0We still have to start the IE= TF last call on those drafts as well. =C2=A0We should know more n the timin= g soon.

I do plan to get the AD reviews out soon for the Oauth draft= s that were to follow the first set.
=

On Thu, Jul 3, 2014 at 1:30 PM, Brian Ca= mpbell <bcampbell@pingidentity.com> wrote:


Hi all,

by next Monday we have to post a draft agenda for the upcoming IETF
meeting.

If you would like to talk about a specific topic, please let us know.

My impression regarding the status of our work is the following:


-------- Current WG items -------

* Dynamic Client Registration

We are waiting for an update but the document could be completed by the
IETF meeting. =3D=3D> no presentation time.

* JWT

Currently in IESG processing and a new draft update has just been
submitted. =3D=3D> no presentation time (#)

* Assertion Bundle

Currently in IESG processing. =3D=3D> no presentation time (#)

* Dynamic Client Registration Management Protocol

We had a discussion about this work at the last IETF meeting and the
path forward looked somewhat difficult. Nothing has happened since that
time and I am inclined to remove it from the list of WG items.

* Proof-of-Possession Security

We have several new documents and I hope we can turn into working group
items already before the meeting. We would then use the meeting time to
discuss open issues.

#: No presentation time unless some challenging comments from the IESG
surface.

-------- Proposed New WG items -------

I would also like to put the following items on the agenda.

* Token Introspection

* draft-sakimura-oauth-tcse-03

-------- Other items -------

Phil might want to bring up this item since it was discussed on the
list: draft-hunt-oauth-v2-user-a4c

Other ideas/suggestions?

Ciao
Hannes


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



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




--

Best regards,
Kathleen
--001a1136936c86379d04fd4dcf40-- From nobody Thu Jul 3 11:32:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6B91B298B for ; Thu, 3 Jul 2014 11:32:02 -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 qjafUhpVjL1O for ; Thu, 3 Jul 2014 11:32:00 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BB31B284A for ; Thu, 3 Jul 2014 11:31:59 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id u10so462355lbd.33 for ; Thu, 03 Jul 2014 11:31:58 -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=2jyeuQRH8W2q5r3d7ojrbVQV515le5cNWjaofQenCQs=; b=sk7oiSmoF/tWZhwkHdK4fgMuk0Wf1P/EDMi8UpyMxJRU578T7/vr3IsAurA4hDqMHg Rz1kijY5VDK7a+SVsB3OIUhVbxLdphVwrA+j9sv8U75nwWjoOkijh5aDm8+TpsL1Ld71 ekfXRywVgMQ1KN4Ri1fP4Z3f2QDcGlHKnXr+66+okY0XviCSb+GGW8Qw4phawfSrFNFY 5NP76bByRlygLCRP2mAQV4jMKwbEndfL7ire+uw4P5ZjBARW4HWnWs3T6c34mGF2otMP sxnja5TmDvyl8h9FarFjBOa1Wy8dy1CBmtpN1zXIPSReO1S+YR/l6Cl4tJMrVloVE/wX X0mg== MIME-Version: 1.0 X-Received: by 10.112.35.136 with SMTP id h8mr4405919lbj.8.1404412318220; Thu, 03 Jul 2014 11:31:58 -0700 (PDT) Received: by 10.112.253.198 with HTTP; Thu, 3 Jul 2014 11:31:58 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD95D0F@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AD95D0F@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Thu, 3 Jul 2014 14:31:58 -0400 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c378965887fe04fd4e39c2 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/G41dlGEJ4KlBGwgArT-nQOevKBQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five 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, 03 Jul 2014 18:32:02 -0000 --001a11c378965887fe04fd4e39c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mike, Thanks for the updated JWT draft. I just read through it again and the changes look good. I noticed that privacy considerations were not mentioned. Should there be any discussed for claims, claim sets, etc.? This is bound to come up in the IESG review if it is not addressed. Sorry I didn't catch that on the first review. On Tue, Jul 1, 2014 at 9:11 PM, Mike Jones wrote: > > > > > *From:* Mike Jones > *Sent:* Tuesday, July 01, 2014 6:11 PM > *To:* jose@ietf.org > *Subject:* JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth > spec of five > > > > JOSE -30 and JWT -24 drafts have been posted incorporating improvements > resulting from Kathleen Moriarty=E2=80=99s JWE review. At this point, ac= tions > requested in her reviews of the JWS, JWE, JWK, JWA, and JWT specification= s > have all been incorporated. All changes in this release were strictly > editorial in nature. > > > > The specifications are available at: > > =C2=B7 http://tools.ietf.org/html/draft-ietf-jose-json-web-signat= ure-30 > > =C2=B7 > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-30 > > =C2=B7 http://tools.ietf.org/html/draft-ietf-jose-json-web-key-30 > > =C2=B7 > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-30 > > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-json-web-token= -24 > > > > HTML formatted versions are available at: > > =C2=B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-signature-30.html > > =C2=B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-30.html > > =C2=B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-key-30.html > > =C2=B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-30.html > > =C2=B7 > http://self-issued.info/docs/draft-ietf-oauth-json-web-token-24.html > > > > -- Mike > > > > P.S. This notice was also posted at http://self-issued.info/?p=3D1245 an= d > as @selfissued. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Best regards, Kathleen --001a11c378965887fe04fd4e39c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mike,

Thanks for the updated JWT draft.= =C2=A0I just read through it again and the changes look good. =C2=A0
=

I noticed that privacy considerations were not mentione= d. =C2=A0Should there be any discussed for claims, claim sets, etc.? =C2=A0= This is bound to come up in the IESG review if it is not addressed. =C2=A0S= orry I didn't catch that on the first review.


On Tue,= Jul 1, 2014 at 9:11 PM, Mike Jones <Michael.Jones@microsoft.com= > wrote:

=C2=A0

=C2=A0

From: Mike Jon= es
Sent: Tuesday, July 01, 2014 6:11 PM
To: jose@ietf.org=
Subject: JOSE -30 and JWT -24 drafts incorporating AD feedback on fi= fth spec of five

=C2=A0

JOSE -30 and JWT -24 drafts have been posted incorpo= rating improvements resulting from Kathleen Moriarty=E2=80=99s JWE review.= =C2=A0 At this point, actions requested in her reviews of the JWS, JWE, JWK= , JWA, and JWT specifications have all been incorporated.=C2=A0 All changes in this release were strictly editorial in nature.

=C2=A0

The specifications are available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://tools.ietf.org/html/= draft-ietf-jose-json-web-signature-30

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://tools.ietf.org/html= /draft-ietf-jose-json-web-encryption-30

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

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://tools.ietf.org/html= /draft-ietf-jose-json-web-algorithms-30

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://tools.ietf.org/html/dra= ft-ietf-oauth-json-web-token-24

=C2=A0

HTML formatted versions are available at:<= /u>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://self-issued.i= nfo/docs/draft-ietf-jose-json-web-signature-30.html

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

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://self-issued.info/do= cs/draft-ietf-jose-json-web-key-30.html

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

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

=C2=A0

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

=C2=A0

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


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




--

Best regards,
Kathleen
--001a11c378965887fe04fd4e39c2-- From nobody Thu Jul 3 11:44:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6BB1B28F9 for ; Thu, 3 Jul 2014 11:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTqPfjxt3Mdx for ; Thu, 3 Jul 2014 11:44:13 -0700 (PDT) Received: from na3sys009aog119.obsmtp.com (na3sys009aog119.obsmtp.com [74.125.149.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF9B1A0359 for ; Thu, 3 Jul 2014 11:44:13 -0700 (PDT) Received: from mail-ie0-f175.google.com ([209.85.223.175]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKU7Wkd3weVuwxnHZLevWjpFQbC37if0L7@postini.com; Thu, 03 Jul 2014 11:44:13 PDT Received: by mail-ie0-f175.google.com with SMTP id tp5so685027ieb.20 for ; Thu, 03 Jul 2014 11:44:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Vx7+Cmc4uzrxX8Gz+oYfBsTQmnVJiuH5GUGl8U6DjbA=; b=jZlszs+I4S3AA0oTz/wNMIp7sIj+fJl1tIcx0ZjzlJTxmu/MrrW+LyVAvUAIgUq3G/ OinECUIIIktWzSXX/bBp7x5vehHyQwXMv2Ml1jg+MoPhbWb8O9kL2ReRk5melwQ7I4hU jjLb4tUwh0CWnltm/QyIp0G+vWT/R8l1/diAFTkIVNRUe5dipHn1olS/3LSsbTFoFmzi 8KmCR0cSwfVf1bWmndEjAknBh9daf6oG8BSS3HgiWHOR7V8zjmW7yc9olF4a+bLEXn7P FEZXYe4/Xkft/pfVU6UFrQjatIck9WUeyPpiIPWtffuknSLVVU99mlo9aO6ambLvCPJ0 Kqag== X-Gm-Message-State: ALoCoQkoGOWDtNdpAG1OvpG9ZO6HXXbiOErYkD5nLjxY2b+JtTLVk5r+o2p52WQqTdCO0ev/nvIOg9/bgNFLBVz/nLQd99QSrUI+her6LaQvdoGOZG1sMXBXj3iessnL0qA8pc4IwtS8 X-Received: by 10.43.160.68 with SMTP id mb4mr11648035icc.4.1404413047395; Thu, 03 Jul 2014 11:44:07 -0700 (PDT) X-Received: by 10.43.160.68 with SMTP id mb4mr11648024icc.4.1404413047299; Thu, 03 Jul 2014 11:44:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Thu, 3 Jul 2014 11:43:37 -0700 (PDT) In-Reply-To: <1403870837.2440.124.camel@shakespeare> References: <1403870837.2440.124.camel@shakespeare> From: Brian Campbell Date: Thu, 3 Jul 2014 12:43:37 -0600 Message-ID: To: Vladimir Dzhuvinov Content-Type: multipart/alternative; boundary=001a11c303e8cd763f04fd4e6495 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/bZ5tr4yea-RUTvxf0yR3gIAjJKg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 18:44:16 -0000 --001a11c303e8cd763f04fd4e6495 Content-Type: text/plain; charset=UTF-8 FWIW, I am very interested in the general concept of a lightweight or OAuth based token exchange mechanism. However, despite some distaste for the protocol, our existing WS-Trust functionality has proven to be "good enough" for most use-cases, which seems to prevent work on token exchange from getting any real priority. I have a few thoughts on http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've been meaning to write down but haven't yet, so this seems like as good a time as any. I would really like to see a simpler request model that doesn't require the request to be JWT encoded. The draft mentions the potential confusion around On-Behalf-Of vs. Impersonation Semantics. And it is confusing (to me anyway). In fact, the use of Act-As and On-Behalf-Of seem to be reversed from how they are defined in WS-Trust (this MS FAQ has less confusing wording). They should probably be aligned with that prior work to avoid further confusion. Or maybe making a clean break and introducing new terms would be better. I don't think the security_token_request grant type value is strictly legal per RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but according to http://tools.ietf.org/html/rfc6749#section-4.5 extension grants need an absolute URI as the grant type value (there's no grant type registry so the URI is the only means of preventing collision). On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov wrote: > Has anyone implemented the OAuth 2.0 Token exchange draft, in particular > the on-behalf-of semantics? We've got a use case for that and I'm > curious if someone has used it in practice. > > http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 > > Thanks, > > Vladimir > -- > Vladimir Dzhuvinov > Connect2id Ltd. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c303e8cd763f04fd4e6495 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWIW, I am very interested in the gene= ral concept of a lightweight or OAuth based token exchange mechanism. Howev= er, despite some distaste for the protocol, our existing WS-Trust functiona= lity has proven to be "good enough" for most use-cases, which see= ms to prevent work on token exchange from getting any real priority.

I have a few thoughts on http://tools.ietf.org/= html/draft-jones-oauth-token-exchange-00 which I've been meaning to= write down but haven't yet, so this seems like as good a time as any. =

I would really like to see a simpler request model that doesn'= ;t require the request to be JWT encoded.

The draft mentions t= he potential confusion around On-Behalf-Of vs. Impersonation Semantics. And= it is confusing (to me anyway). In fact, the use of Act-As and On-Behalf-O= f seem to be reversed from how they are defined in WS-Trust (this MS FAQ has l= ess confusing wording). They should probably be aligned with that prior wor= k to avoid further confusion. Or maybe making a clean break and introducing= new terms would be better.

I don't think the security_token_request grant type value is = strictly legal per RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10= would allow it but according to http://tools.ietf.org/html/rfc6749#section-4.5 ext= ension grants need an absolute URI as the grant type value (there's no = grant type registry so the URI is the only means of preventing collision). =

=C2=A0








On Fri, Jun 27, 2014 at= 6:07 AM, Vladimir Dzhuvinov <vladimir@connect2id.com>= wrote:
Has anyone implemented th= e OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchan= ge-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov <vladimir@= connect2id.com>
Connect2id Ltd.

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

--001a11c303e8cd763f04fd4e6495-- From nobody Thu Jul 3 11:55:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B069C1B2983 for ; Thu, 3 Jul 2014 11:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuMb-mKuZgiU for ; Thu, 3 Jul 2014 11:55:10 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CDA51A0359 for ; Thu, 3 Jul 2014 11:55:10 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB310.namprd03.prod.outlook.com (10.141.48.25) with Microsoft SMTP Server (TLS) id 15.0.974.11; Thu, 3 Jul 2014 18:55:02 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0974.002; Thu, 3 Jul 2014 18:55:02 +0000 From: Anthony Nadalin To: Brian Campbell , Vladimir Dzhuvinov Thread-Topic: [OAUTH-WG] draft-jones-oauth-token-exchange-00 Thread-Index: AQHPkgBkTbUosZvlOkC0TtYXoBOysZuOuWWAgAACqfA= Date: Thu, 3 Jul 2014 18:55:02 +0000 Message-ID: <930f1bd03c9e4cbaae1e5c321b0ee5ec@BLUPR03MB309.namprd03.prod.outlook.com> References: <1403870837.2440.124.camel@shakespeare> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(24454002)(164054003)(377454003)(81342001)(19609705001)(85306003)(81542001)(46102001)(76576001)(15975445006)(74662001)(33646001)(19300405004)(20776003)(16236675004)(76482001)(105586002)(64706001)(74502001)(107046002)(83322001)(92566001)(19580405001)(19580395003)(2656002)(15202345003)(95666004)(76176999)(77982001)(83072002)(99286002)(80022001)(19625215002)(86362001)(74316001)(106356001)(31966008)(21056001)(101416001)(86612001)(106116001)(87936001)(79102001)(54356999)(50986999)(85852003)(99396002)(108616002)(42262001)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB310; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_930f1bd03c9e4cbaae1e5c321b0ee5ecBLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/w2yhix-CqdYK0n_PyidbtaWCXrk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 18:55:13 -0000 --_000_930f1bd03c9e4cbaae1e5c321b0ee5ecBLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGV4cGxhbmF0aW9uIG9mIG9uLWJlaGFsZi1PZiBhbmQgQWN0QXMgYXJlIGNvcnJlY3QgaW4g dGhlIGRvY3VtZW50IGFzIGRlZmluZWQgYnkgV1MtVHJ1c3QsIHRoaXMgbWF5IG5vdCBiZSB5b3Vy IGRlc2lyZSBvciB1bmRlcnN0YW5kaW5nIGJ1dCB0aGF0IGlzIGhvdyBXUy1UcnVzdCBpbXBsZW1l bnRhdGlvbnMgc2hvdWxkIHdvcmsNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IFRodXJzZGF5LCBK dWx5IDMsIDIwMTQgMTE6NDQgQU0NClRvOiBWbGFkaW1pciBEemh1dmlub3YNCkNjOiBvYXV0aEBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gZHJhZnQtam9uZXMtb2F1dGgtdG9rZW4t ZXhjaGFuZ2UtMDANCg0KRldJVywgSSBhbSB2ZXJ5IGludGVyZXN0ZWQgaW4gdGhlIGdlbmVyYWwg Y29uY2VwdCBvZiBhIGxpZ2h0d2VpZ2h0IG9yIE9BdXRoIGJhc2VkIHRva2VuIGV4Y2hhbmdlIG1l Y2hhbmlzbS4gSG93ZXZlciwgZGVzcGl0ZSBzb21lIGRpc3Rhc3RlIGZvciB0aGUgcHJvdG9jb2ws IG91ciBleGlzdGluZyBXUy1UcnVzdCBmdW5jdGlvbmFsaXR5IGhhcyBwcm92ZW4gdG8gYmUgImdv b2QgZW5vdWdoIiBmb3IgbW9zdCB1c2UtY2FzZXMsIHdoaWNoIHNlZW1zIHRvIHByZXZlbnQgd29y ayBvbiB0b2tlbiBleGNoYW5nZSBmcm9tIGdldHRpbmcgYW55IHJlYWwgcHJpb3JpdHkuDQpJIGhh dmUgYSBmZXcgdGhvdWdodHMgb24gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9u ZXMtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDAgd2hpY2ggSSd2ZSBiZWVuIG1lYW5pbmcgdG8gd3Jp dGUgZG93biBidXQgaGF2ZW4ndCB5ZXQsIHNvIHRoaXMgc2VlbXMgbGlrZSBhcyBnb29kIGEgdGlt ZSBhcyBhbnkuDQpJIHdvdWxkIHJlYWxseSBsaWtlIHRvIHNlZSBhIHNpbXBsZXIgcmVxdWVzdCBt b2RlbCB0aGF0IGRvZXNuJ3QgcmVxdWlyZSB0aGUgcmVxdWVzdCB0byBiZSBKV1QgZW5jb2RlZC4N ClRoZSBkcmFmdCBtZW50aW9ucyB0aGUgcG90ZW50aWFsIGNvbmZ1c2lvbiBhcm91bmQgT24tQmVo YWxmLU9mIHZzLiBJbXBlcnNvbmF0aW9uIFNlbWFudGljcy4gQW5kIGl0IGlzIGNvbmZ1c2luZyAo dG8gbWUgYW55d2F5KS4gSW4gZmFjdCwgdGhlIHVzZSBvZiBBY3QtQXMgYW5kIE9uLUJlaGFsZi1P ZiBzZWVtIHRvIGJlIHJldmVyc2VkIGZyb20gaG93IHRoZXkgYXJlIGRlZmluZWQgaW4gV1MtVHJ1 c3Q8aHR0cDovL2RvY3Mub2FzaXMtb3Blbi5vcmcvd3Mtc3gvd3MtdHJ1c3QvdjEuNC93cy10cnVz dC5odG1sPiAodGhpcyBNUyBGQVE8aHR0cDovL21zZG4ubWljcm9zb2Z0LmNvbS9lbi11cy9saWJy YXJ5L2VlNzQ4NDg3LmFzcHg+IGhhcyBsZXNzIGNvbmZ1c2luZyB3b3JkaW5nKS4gVGhleSBzaG91 bGQgcHJvYmFibHkgYmUgYWxpZ25lZCB3aXRoIHRoYXQgcHJpb3Igd29yayB0byBhdm9pZCBmdXJ0 aGVyIGNvbmZ1c2lvbi4gT3IgbWF5YmUgbWFraW5nIGEgY2xlYW4gYnJlYWsgYW5kIGludHJvZHVj aW5nIG5ldyB0ZXJtcyB3b3VsZCBiZSBiZXR0ZXIuDQpJIGRvbid0IHRoaW5rIHRoZSBzZWN1cml0 eV90b2tlbl9yZXF1ZXN0IGdyYW50IHR5cGUgdmFsdWUgaXMgc3RyaWN0bHkgbGVnYWwgcGVyIFJG QyA2NzQ5LiBUaGUgQUJORiBhdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I2Fw cGVuZGl4LUEuMTAgd291bGQgYWxsb3cgaXQgYnV0IGFjY29yZGluZyB0byBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tNC41IGV4dGVuc2lvbiBncmFudHMgbmVlZCBh biBhYnNvbHV0ZSBVUkkgYXMgdGhlIGdyYW50IHR5cGUgdmFsdWUgKHRoZXJlJ3Mgbm8gZ3JhbnQg dHlwZSByZWdpc3RyeSBzbyB0aGUgVVJJIGlzIHRoZSBvbmx5IG1lYW5zIG9mIHByZXZlbnRpbmcg Y29sbGlzaW9uKS4NCg0KDQoNCg0KDQoNCk9uIEZyaSwgSnVuIDI3LCAyMDE0IGF0IDY6MDcgQU0s IFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb208bWFpbHRvOnZsYWRp bWlyQGNvbm5lY3QyaWQuY29tPj4gd3JvdGU6DQpIYXMgYW55b25lIGltcGxlbWVudGVkIHRoZSBP QXV0aCAyLjAgVG9rZW4gZXhjaGFuZ2UgZHJhZnQsIGluIHBhcnRpY3VsYXINCnRoZSBvbi1iZWhh bGYtb2Ygc2VtYW50aWNzPyBXZSd2ZSBnb3QgYSB1c2UgY2FzZSBmb3IgdGhhdCBhbmQgSSdtDQpj dXJpb3VzIGlmIHNvbWVvbmUgaGFzIHVzZWQgaXQgaW4gcHJhY3RpY2UuDQoNCmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAwDQoNClRo YW5rcywNCg0KVmxhZGltaXINCi0tDQpWbGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNvbm5l Y3QyaWQuY29tPG1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4+DQpDb25uZWN0MmlkIEx0 ZC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_930f1bd03c9e4cbaae1e5c321b0ee5ecBLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBleHBs YW5hdGlvbiBvZiBvbi1iZWhhbGYtT2YgYW5kIEFjdEFzIGFyZSBjb3JyZWN0IGluIHRoZSBkb2N1 bWVudCBhcyBkZWZpbmVkIGJ5IFdTLVRydXN0LCB0aGlzIG1heSBub3QgYmUgeW91ciBkZXNpcmUg b3IgdW5kZXJzdGFuZGluZyBidXQgdGhhdCBpcyBob3cgV1MtVHJ1c3QNCiBpbXBsZW1lbnRhdGlv bnMgc2hvdWxkIHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAzLCAyMDE0IDExOjQ0IEFNPGJyPg0KPGI+VG86PC9i PiBWbGFkaW1pciBEemh1dmlub3Y8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIGRyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWV4 Y2hhbmdlLTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+RldJVywgSSBh bSB2ZXJ5IGludGVyZXN0ZWQgaW4gdGhlIGdlbmVyYWwgY29uY2VwdCBvZiBhIGxpZ2h0d2VpZ2h0 IG9yIE9BdXRoIGJhc2VkIHRva2VuIGV4Y2hhbmdlIG1lY2hhbmlzbS4gSG93ZXZlciwgZGVzcGl0 ZSBzb21lIGRpc3Rhc3RlIGZvciB0aGUgcHJvdG9jb2wsIG91ciBleGlzdGluZyBXUy1UcnVzdCBm dW5jdGlvbmFsaXR5IGhhcyBwcm92ZW4gdG8NCiBiZSAmcXVvdDtnb29kIGVub3VnaCZxdW90OyBm b3IgbW9zdCB1c2UtY2FzZXMsIHdoaWNoIHNlZW1zIHRvIHByZXZlbnQgd29yayBvbiB0b2tlbiBl eGNoYW5nZSBmcm9tIGdldHRpbmcgYW55IHJlYWwgcHJpb3JpdHkuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ SSBoYXZlIGEgZmV3IHRob3VnaHRzIG9uIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAwIiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC10b2tlbi1leGNo YW5nZS0wMDwvYT4gd2hpY2ggSSd2ZSBiZWVuIG1lYW5pbmcgdG8gd3JpdGUgZG93biBidXQgaGF2 ZW4ndCB5ZXQsIHNvIHRoaXMgc2VlbXMgbGlrZSBhcyBnb29kIGEgdGltZSBhcyBhbnkuDQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5JIHdvdWxkIHJlYWxseSBsaWtlIHRvIHNlZSBhIHNpbXBsZXIgcmVxdWVz dCBtb2RlbCB0aGF0IGRvZXNuJ3QgcmVxdWlyZSB0aGUgcmVxdWVzdCB0byBiZSBKV1QgZW5jb2Rl ZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5UaGUgZHJhZnQgbWVudGlvbnMgdGhlIHBvdGVudGlhbCBjb25m dXNpb24gYXJvdW5kIE9uLUJlaGFsZi1PZiB2cy4gSW1wZXJzb25hdGlvbiBTZW1hbnRpY3MuIEFu ZCBpdCBpcyBjb25mdXNpbmcgKHRvIG1lIGFueXdheSkuIEluIGZhY3QsIHRoZSB1c2Ugb2YgQWN0 LUFzIGFuZCBPbi1CZWhhbGYtT2Ygc2VlbSB0byBiZSByZXZlcnNlZCBmcm9tIGhvdyB0aGV5IGFy ZQ0KIGRlZmluZWQgaW4gPGEgaHJlZj0iaHR0cDovL2RvY3Mub2FzaXMtb3Blbi5vcmcvd3Mtc3gv d3MtdHJ1c3QvdjEuNC93cy10cnVzdC5odG1sIj4NCldTLVRydXN0PC9hPiAoPGEgaHJlZj0iaHR0 cDovL21zZG4ubWljcm9zb2Z0LmNvbS9lbi11cy9saWJyYXJ5L2VlNzQ4NDg3LmFzcHgiPnRoaXMg TVMgRkFRPC9hPiBoYXMgbGVzcyBjb25mdXNpbmcgd29yZGluZykuIFRoZXkgc2hvdWxkIHByb2Jh Ymx5IGJlIGFsaWduZWQgd2l0aCB0aGF0IHByaW9yIHdvcmsgdG8gYXZvaWQgZnVydGhlciBjb25m dXNpb24uIE9yIG1heWJlIG1ha2luZyBhIGNsZWFuIGJyZWFrIGFuZCBpbnRyb2R1Y2luZyBuZXcg dGVybXMNCiB3b3VsZCBiZSBiZXR0ZXIuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGRvbid0IHRoaW5rIHRoZSBzZWN1cml0eV90b2tlbl9yZXF1ZXN0IGdy YW50IHR5cGUgdmFsdWUgaXMgc3RyaWN0bHkgbGVnYWwgcGVyIFJGQyA2NzQ5LiBUaGUgQUJORiBh dA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNhcHBlbmRpeC1B LjEwIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I2FwcGVuZGl4LUEuMTA8L2E+ IHdvdWxkIGFsbG93IGl0IGJ1dCBhY2NvcmRpbmcgdG8NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi00LjUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzY3NDkjc2VjdGlvbi00LjU8L2E+IGV4dGVuc2lvbiBncmFudHMgbmVlZCBhbiBhYnNv bHV0ZSBVUkkgYXMgdGhlIGdyYW50IHR5cGUgdmFsdWUgKHRoZXJlJ3Mgbm8gZ3JhbnQgdHlwZSBy ZWdpc3RyeSBzbyB0aGUgVVJJIGlzIHRoZSBvbmx5IG1lYW5zIG9mIHByZXZlbnRpbmcgY29sbGlz aW9uKS4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KJm5ic3A7PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gRnJpLCBKdW4gMjcsIDIwMTQgYXQgNjowNyBBTSwgVmxhZGltaXIgRHpodXZpbm92 ICZsdDs8YSBocmVmPSJtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20iIHRhcmdldD0iX2Js YW5rIj52bGFkaW1pckBjb25uZWN0MmlkLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhcyBhbnlvbmUgaW1wbGVtZW50 ZWQgdGhlIE9BdXRoIDIuMCBUb2tlbiBleGNoYW5nZSBkcmFmdCwgaW4gcGFydGljdWxhcjxicj4N CnRoZSBvbi1iZWhhbGYtb2Ygc2VtYW50aWNzPyBXZSd2ZSBnb3QgYSB1c2UgY2FzZSBmb3IgdGhh dCBhbmQgSSdtPGJyPg0KY3VyaW91cyBpZiBzb21lb25lIGhhcyB1c2VkIGl0IGluIHByYWN0aWNl Ljxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpv bmVzLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDA8L2E+PGJy Pg0KPGJyPg0KVGhhbmtzLDxicj4NCjxicj4NClZsYWRpbWlyPGJyPg0KPHNwYW4gc3R5bGU9ImNv bG9yOiM4ODg4ODgiPi0tPGJyPg0KVmxhZGltaXIgRHpodXZpbm92ICZsdDs8YSBocmVmPSJtYWls dG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20iPnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPC9hPiZn dDs8YnI+DQpDb25uZWN0MmlkIEx0ZC48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_930f1bd03c9e4cbaae1e5c321b0ee5ecBLUPR03MB309namprd03pro_-- From nobody Thu Jul 3 11:56:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791AE1B2B21 for ; Thu, 3 Jul 2014 11:55: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 m-iyImBgZUhJ for ; Thu, 3 Jul 2014 11:55:54 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4E91B2B1A for ; Thu, 3 Jul 2014 11:55:53 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id s18so482200lam.20 for ; Thu, 03 Jul 2014 11:55:52 -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=DR7MgVccOum+J3vfj1ll/gnoLAjLP6FMz3sQRca9KYw=; b=CvEJK/mMPKH4uQxXE9jOcX7KVSmYCKKNGlcvVyGNmpDgX+sM4X+WLZCDgtIiWMadNy duHheYBu/DKeoBJ9cNTb05mWq0aEZgXcw5v1RfwpExB3fMlfLr5iDjEAYBgFOLuDPCS3 sjqEKi46sI0zYRqcukOHCXd3SdtCg6FKMNXlsJY2Ni6Na12nyb6N4siAWXonHIr5fkrn MUoCJvbPfxVNOmY3WkagNOJiaLORM/+o22CKkKbi5ulA0tuBsX5CEvHBLSTu33W/+q1A SomgveViBvrLqdZ8Xw8/+2AucV0HrX6C9+6EIAbS7KFV7+FMAPfbmswITFOvnuzJ5ZmK 9n/g== MIME-Version: 1.0 X-Received: by 10.152.185.104 with SMTP id fb8mr2701399lac.64.1404413752297; Thu, 03 Jul 2014 11:55:52 -0700 (PDT) Received: by 10.112.253.198 with HTTP; Thu, 3 Jul 2014 11:55:52 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739439AD95D0F@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Thu, 3 Jul 2014 14:55:52 -0400 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: multipart/alternative; boundary=001a1136936cd2d90004fd4e8e80 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9pUg0cXBmeJL08SHC1mlkqoMY7E Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five 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, 03 Jul 2014 18:55:59 -0000 --001a1136936cd2d90004fd4e8e80 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello! Thank you for all of the updates to the JOSE drafts in the current bundle in review. I appreciate all of the effort that went into the revisions! As I understand it, there are a few general issues we need to work through, then a few nits/requests are included on specific drafts. Knowing how we move forward on the following items will be necessary as well as the shepherd/chair okay to progress the drafts to IETF last call. As an FYI, since it was requested that the drafts progress as a set, I may need to delay on which telechat the drafts get placed. Essentially, the set requires a lot of reading and I'd like to give the IESG enough time to do reviews. 1. McGrew draft (applies to JWA) We are waiting on an updated version so that the JWA draft can refer to it as opposed to duplicating text from it. 2. Alternate on text that applies to several of the drafts for the following: Discussion on wording =E2=80=9Cor use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]=E2=80=9D. Jim or others may have text suggestions. This was discussed on list, but has not been resolved yet. 3. Use cases not met by current set of drafts Documents do not meet all of the use cases laid out in the Use Cases document Specifically section 5.8 since there is no key management for MACs (5.8.1. =E2=80=93 MAC based on ECDH-derived key) I'm not sure how this gets handled. If it will be addressed in other drafts, let me know. 4. I don't recall seeing any internationalization considerations, is that something we need to worry about? Nits/Comments for specific drafts: JWA: Security considerations section 8.2 Key Lifetimes Should there be a reference to NIST 800-57 to provide guidance on this topic. If there is a better reference, that's fine too. This is something that may get picked up on in other reviews. Thanks for reducing text by referring to other drafts for a good portion of the security considerations section. JWS: For typ and cty, the text could be more clear in the first paragraph sentence 2 and 4. They read as if they are in conflict. The specific usage is different in these sentences, but that is not made clear in the text. It should just be a text adjustment. Section 8: TLS requirements, second paragraph: For the second sentence, could you either include examples or a reference to where the reader can ascertain appropriate appropriate cipher suites? This may be tough to address, but the way the sentence is written, it sounds like a reference or a recommendation is needed. Any ideas? JWK: Updates look good, thanks! JWE: Updates look good, thank you! Oauth JWT: Sent to Oauth list On Thu, Jul 3, 2014 at 2:31 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Mike, > > Thanks for the updated JWT draft. I just read through it again and the > changes look good. > > I noticed that privacy considerations were not mentioned. Should there b= e > any discussed for claims, claim sets, etc.? This is bound to come up in > the IESG review if it is not addressed. Sorry I didn't catch that on the > first review. > > > On Tue, Jul 1, 2014 at 9:11 PM, Mike Jones > wrote: > >> >> >> >> >> *From:* Mike Jones >> *Sent:* Tuesday, July 01, 2014 6:11 PM >> *To:* jose@ietf.org >> *Subject:* JOSE -30 and JWT -24 drafts incorporating AD feedback on >> fifth spec of five >> >> >> >> JOSE -30 and JWT -24 drafts have been posted incorporating improvements >> resulting from Kathleen Moriarty=E2=80=99s JWE review. At this point, a= ctions >> requested in her reviews of the JWS, JWE, JWK, JWA, and JWT specificatio= ns >> have all been incorporated. All changes in this release were strictly >> editorial in nature. >> >> >> >> The specifications are available at: >> >> =C2=B7 >> http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-30 >> >> =C2=B7 >> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-30 >> >> =C2=B7 http://tools.ietf.org/html/draft-ietf-jose-json-web-key-3= 0 >> >> =C2=B7 >> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-30 >> >> =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-json-web-toke= n-24 >> >> >> >> HTML formatted versions are available at: >> >> =C2=B7 >> http://self-issued.info/docs/draft-ietf-jose-json-web-signature-30.html >> >> =C2=B7 >> http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-30.html >> >> =C2=B7 >> http://self-issued.info/docs/draft-ietf-jose-json-web-key-30.html >> >> =C2=B7 >> http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-30.html >> >> =C2=B7 >> http://self-issued.info/docs/draft-ietf-oauth-json-web-token-24.html >> >> >> >> -- Mike >> >> >> >> P.S. This notice was also posted at http://self-issued.info/?p=3D1245 a= nd >> as @selfissued. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > > Best regards, > Kathleen > --=20 Best regards, Kathleen --001a1136936cd2d90004fd4e8e80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello!

Thank you for all of = the updates to the JOSE drafts in the current bundle in review. =C2=A0I app= reciate all of the effort that went into the revisions! =C2=A0As I understa= nd it, there are a few general issues we need to work through, then a few n= its/requests are included on specific drafts.

Knowing how we move forward on the following items will= be necessary as well as the shepherd/chair okay to progress the drafts to = IETF last call. =C2=A0As an FYI, since it was requested that the drafts pro= gress as a set, I may need to delay on which telechat the drafts get placed= . =C2=A0Essentially, the set requires a lot of reading and I'd like to = give the IESG enough time to do reviews.

1. McGrew draft (applies to JWA)
=C2=A0 =C2= =A0We are waiting on an updated version so that the JWA draft can refer to = it as opposed to duplicating text from it.

2. Alte= rnate on text that applies to several of the drafts for the following:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Discussion on wording =E2=80=9Cor us= e a JSON parser that returns
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on= ly the lexically last duplicate member name, as specified
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0in Section 15.12 (The JSON Object) of ECMAScript= 5.1 [ECMAScript]=E2=80=9D.=C2=A0

Jim or others may have text suggestions. =C2=A0This was= discussed on list, but has not been resolved yet.

=
3. Use cases not met by current set of drafts
=C2=A0 =C2=A0 = =C2=A0Documents do not meet all of the use cases laid out in the Use Cases = document
=C2=A0 =C2=A0 =C2=A0Specifically section 5.8 since there is no key man= agement for=C2=A0
=C2=A0 =C2=A0 =C2=A0MACs (5.8.1. =E2=80=93 MAC = based on ECDH-derived key)
I'm not sure how this gets handled= . =C2=A0If it will be addressed in other drafts, let me know.

4. =C2=A0I don't recall seeing any internationaliza= tion considerations, is that something we need to worry about?

Nits/Comments for specific drafts:
JWA:=C2=A0
Security considerations section 8.2 Key Lif= etimes
Should there be a reference to NIST 800-57 to provide guid= ance on this topic. =C2=A0If there is a better reference, that's fine t= oo. =C2=A0This is something that may get picked up on in other reviews.

Thanks for reducing text by referring to other drafts f= or a good portion of the security considerations section.

JWS:
For typ and cty, the text could be more clear in the= first paragraph sentence 2 and 4. =C2=A0They read as if they are in confli= ct. =C2=A0 The specific usage is different in these sentences, but that is = not made clear in the text. =C2=A0It should just be a text adjustment.

Section 8: TLS requirements, second paragraph:
For the second sentence, could you either include examples or a reference= to where the reader can ascertain appropriate appropriate cipher suites? = =C2=A0This may be tough to address, but the way the sentence is written, it= sounds like a reference or a recommendation is needed. =C2=A0Any ideas?

JWK:
Updates look good, thanks!
JWE:
Updates look good, thank you!

Oauth JWT: Sent to Oauth list



On Thu, Jul 3, 2014 at 2:31 PM, Kathleen= Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:
Mike,

Th= anks for the updated JWT draft. =C2=A0I just read through it again and the = changes look good. =C2=A0

I noticed that privacy considerations were not mentione= d. =C2=A0Should there be any discussed for claims, claim sets, etc.? =C2=A0= This is bound to come up in the IESG review if it is not addressed. =C2=A0S= orry I didn't catch that on the first review.


On Tue, Jul 1, 2014 at 9:11 PM, Mike Jones <Mich= ael.Jones@microsoft.com> wrote:

=C2=A0

=C2=A0

From: Mike Jon= es
Sent: Tuesday, July 01, 2014 6:11 PM
To: jose@ietf.org=
Subject: JOSE -30 and JWT -24 drafts incorporating AD feedback on fi= fth spec of five

=C2=A0

JOSE -30 and JWT -24 drafts have been posted incorpo= rating improvements resulting from Kathleen Moriarty=E2=80=99s JWE review.= =C2=A0 At this point, actions requested in her reviews of the JWS, JWE, JWK= , JWA, and JWT specifications have all been incorporated.=C2=A0 All changes in this release were strictly editorial in nature.

=C2=A0

The specifications are available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://tools.ietf.org/html/= draft-ietf-jose-json-web-signature-30

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://tools.ietf.org/html= /draft-ietf-jose-json-web-encryption-30

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

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://tools.ietf.org/html= /draft-ietf-jose-json-web-algorithms-30

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://tools.ietf.org/html/dra= ft-ietf-oauth-json-web-token-24

=C2=A0

HTML formatted versions are available at:<= /u>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://self-issued.i= nfo/docs/draft-ietf-jose-json-web-signature-30.html

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

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://self-issued.info/do= cs/draft-ietf-jose-json-web-key-30.html

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

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

=C2=A0

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

=C2=A0

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


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


<= br clear=3D"all">

--

Best regar= ds,
Kathleen



--

Best regards,
Kathleen
--001a1136936cd2d90004fd4e8e80-- From nobody Thu Jul 3 12:02:20 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C8F1B29C4 for ; Thu, 3 Jul 2014 12:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ShdcO4M6bSI for ; Thu, 3 Jul 2014 12:02:04 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192031B29FE for ; Thu, 3 Jul 2014 12:02:02 -0700 (PDT) Received: from mail-ie0-f169.google.com ([209.85.223.169]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKU7WoqeAbXg9qHmKhMq9tehda/Jfrf54k@postini.com; Thu, 03 Jul 2014 12:02:02 PDT Received: by mail-ie0-f169.google.com with SMTP id rl12so720027iec.14 for ; Thu, 03 Jul 2014 12:02:01 -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=XTFPz2VWBOhkjM+0pGHcMoLfHwUFt0M5JsvLFi8E/WI=; b=IR7/DQ1OGU2atlfGhJXjUQduCVVjzdWeTX0s3BW7m1w0hDu13ozK3EmcBiAkpvmd2B Hd+c8lMWVig+66WZQOmFSIYQJ4ok8hSUBCzWbJ9qm36CqQprxo+/lVzwa1qkmKCzGC5g tMx4t5U78dPnbyy85FFkXfcqQG73knTTpx7wZ+YWz2XtCjLjSoGDZl7ijDBrq+M/L9oG 5gRTZ8wR+fZ3G72uTpe69MS84If/KmGQfg4WzW4AgJRU3ooXoKWvOEZZtF/iLPw5x3K7 D2J48pZWet7rNtHExwhOIlgKvq9fQy8b19po2EOmnO2XPHe+LXdDRPI0oorB1MHh/jGQ h2Dg== X-Gm-Message-State: ALoCoQl4874zdgkqr6xSCzz4KTTE64UXbmnXq18Cwab5BWm1MUdSX1JXLfTCGa1WiY48q1S3P+ffKeBO9DmxjtcL+/mYrC1mVOqhABY0/Slj0wM7p6PdwShGbJ/3N66AQNPk1BZzno8o X-Received: by 10.50.154.103 with SMTP id vn7mr45615788igb.40.1404414121345; Thu, 03 Jul 2014 12:02:01 -0700 (PDT) X-Received: by 10.50.154.103 with SMTP id vn7mr45615755igb.40.1404414121065; Thu, 03 Jul 2014 12:02:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Thu, 3 Jul 2014 12:01:30 -0700 (PDT) In-Reply-To: <930f1bd03c9e4cbaae1e5c321b0ee5ec@BLUPR03MB309.namprd03.prod.outlook.com> References: <1403870837.2440.124.camel@shakespeare> <930f1bd03c9e4cbaae1e5c321b0ee5ec@BLUPR03MB309.namprd03.prod.outlook.com> From: Brian Campbell Date: Thu, 3 Jul 2014 13:01:30 -0600 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=047d7bd7531ccde73304fd4ea41f Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/hZcR67sBIaGZp8LXuTaVrpNP15I Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 19:02:08 -0000 --047d7bd7531ccde73304fd4ea41f Content-Type: text/plain; charset=UTF-8 And I was suggesting that OAuth token exchange align with the WS-Trust definitions or maybe even define totally new terms. But not use the same terms to mean different things. On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin wrote: > The explanation of on-behalf-Of and ActAs are correct in the document as > defined by WS-Trust, this may not be your desire or understanding but that > is how WS-Trust implementations should work > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Thursday, July 3, 2014 11:44 AM > *To:* Vladimir Dzhuvinov > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > > > > FWIW, I am very interested in the general concept of a lightweight or > OAuth based token exchange mechanism. However, despite some distaste for > the protocol, our existing WS-Trust functionality has proven to be "good > enough" for most use-cases, which seems to prevent work on token exchange > from getting any real priority. > > I have a few thoughts on > http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've > been meaning to write down but haven't yet, so this seems like as good a > time as any. > > I would really like to see a simpler request model that doesn't require > the request to be JWT encoded. > > The draft mentions the potential confusion around On-Behalf-Of vs. > Impersonation Semantics. And it is confusing (to me anyway). In fact, the > use of Act-As and On-Behalf-Of seem to be reversed from how they are > defined in WS-Trust > (this MS > FAQ has less > confusing wording). They should probably be aligned with that prior work to > avoid further confusion. Or maybe making a clean break and introducing new > terms would be better. > > I don't think the security_token_request grant type value is strictly > legal per RFC 6749. The ABNF at > http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but > according to http://tools.ietf.org/html/rfc6749#section-4.5 extension > grants need an absolute URI as the grant type value (there's no grant type > registry so the URI is the only means of preventing collision). > > > > > > > > > > > On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov < > vladimir@connect2id.com> wrote: > > Has anyone implemented the OAuth 2.0 Token exchange draft, in particular > the on-behalf-of semantics? We've got a use case for that and I'm > curious if someone has used it in practice. > > http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 > > Thanks, > > Vladimir > -- > Vladimir Dzhuvinov > Connect2id Ltd. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --047d7bd7531ccde73304fd4ea41f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And I was suggesting that OAuth token exchange align with = the WS-Trust definitions or maybe even define totally new terms. But not us= e the same terms to mean different things.


On Thu, Jul 3, 2014 at 12:55 PM, Anthony= Nadalin <tonynad@microsoft.com> wrote:

The explanation of on-beh= alf-Of and ActAs are correct in the document as defined by WS-Trust, this m= ay not be your desire or understanding but that is how WS-Trust implementations should work

=C2=A0

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 3, 2014 11:44 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

=C2=A0

FWIW, I am very inter= ested in the general concept of a lightweight or OAuth based token exchange= mechanism. However, despite some distaste for the protocol, our existing W= S-Trust functionality has proven to be "good enough" for most use-cases, which seems to prevent work= on token exchange from getting any real priority.

I have a few thoughts= on http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I&= #39;ve been meaning to write down but haven't yet, so this seems like a= s good a time as any.

I would really like t= o see a simpler request model that doesn't require the request to be JW= T encoded.

The draft mentions th= e potential confusion around On-Behalf-Of vs. Impersonation Semantics. And = it is confusing (to me anyway). In fact, the use of Act-As and On-Behalf-Of= seem to be reversed from how they are defined in WS-Trust (this MS FAQ has less confusing wording). They sh= ould probably be aligned with that prior work to avoid further confusion. O= r maybe making a clean break and introducing new terms would be better.

I don't think the security_token_request grant t= ype value is strictly legal per RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but= according to http://tools.ietf.org/html/rfc6749#section-4.5 extension grants need = an absolute URI as the grant type value (there's no grant type registry= so the URI is the only means of preventing collision).


=C2=A0

=C2=A0<= /p>

=C2=A0<= /p>

=C2=A0<= /p>

On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov = <vladimir@c= onnect2id.com> wrote:

Has anyone implemented the OAuth 2.0 Token exchange = draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchan= ge-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov <vladimir@connect2id.com>
Connect2id Ltd.

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

=C2=A0


--047d7bd7531ccde73304fd4ea41f-- From nobody Thu Jul 3 12:04:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E081B29DE for ; Thu, 3 Jul 2014 12:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qzDaMrXN0po for ; Thu, 3 Jul 2014 12:04:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCAA91B2B41 for ; Thu, 3 Jul 2014 12:04:07 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB310.namprd03.prod.outlook.com (10.141.48.25) with Microsoft SMTP Server (TLS) id 15.0.974.11; Thu, 3 Jul 2014 19:04:00 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0974.002; Thu, 3 Jul 2014 19:04:00 +0000 From: Anthony Nadalin To: Brian Campbell Thread-Topic: [OAUTH-WG] draft-jones-oauth-token-exchange-00 Thread-Index: AQHPkgBkTbUosZvlOkC0TtYXoBOysZuOuWWAgAACqfCAAAJWAIAAAFQQ Date: Thu, 3 Jul 2014 19:04:00 +0000 Message-ID: <25c76f47a47e4c9faac9995cc1d89364@BLUPR03MB309.namprd03.prod.outlook.com> References: <1403870837.2440.124.camel@shakespeare> <930f1bd03c9e4cbaae1e5c321b0ee5ec@BLUPR03MB309.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(24454002)(164054003)(199002)(189002)(83072002)(80022001)(99286002)(77982001)(76176999)(95666004)(74316001)(106356001)(19625215002)(86362001)(2656002)(19580395003)(92566001)(19580405001)(15202345003)(54356999)(79102001)(99396002)(50986999)(85852003)(31966008)(86612001)(106116001)(87936001)(21056001)(101416001)(74662001)(33646001)(81542001)(85306003)(93886003)(19609705001)(81342001)(15975445006)(76576001)(46102001)(105586002)(76482001)(107046002)(83322001)(74502001)(64706001)(20776003)(19300405004)(16236675004)(108616002)(42262001)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB310; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_25c76f47a47e4c9faac9995cc1d89364BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/P7kw7ZLFn4BVKTfuKa-W5iLgSsg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 19:04:18 -0000 --_000_25c76f47a47e4c9faac9995cc1d89364BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbG9zdCwgdGhlIHRlcm1zIGRlZmluZWQgaW4gdGhlIG9hdXRoIHRva2VuLWV4Y2hhbmdl IGRyYWZ0IGFyZSB0aGUgc2FtZSB0ZXJtcyBkZWZpbmVkIGluIHdzLXRydXN0IGFuZCBoYXZlIHRo ZSBzYW1lIGRlZmluaXRpb25zDQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBi ZWxsQHBpbmdpZGVudGl0eS5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVseSAzLCAyMDE0IDEyOjAy IFBNDQpUbzogQW50aG9ueSBOYWRhbGluDQpDYzogVmxhZGltaXIgRHpodXZpbm92OyBvYXV0aEBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gZHJhZnQtam9uZXMtb2F1dGgtdG9rZW4t ZXhjaGFuZ2UtMDANCg0KQW5kIEkgd2FzIHN1Z2dlc3RpbmcgdGhhdCBPQXV0aCB0b2tlbiBleGNo YW5nZSBhbGlnbiB3aXRoIHRoZSBXUy1UcnVzdCBkZWZpbml0aW9ucyBvciBtYXliZSBldmVuIGRl ZmluZSB0b3RhbGx5IG5ldyB0ZXJtcy4gQnV0IG5vdCB1c2UgdGhlIHNhbWUgdGVybXMgdG8gbWVh biBkaWZmZXJlbnQgdGhpbmdzLg0KDQpPbiBUaHUsIEp1bCAzLCAyMDE0IGF0IDEyOjU1IFBNLCBB bnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNy b3NvZnQuY29tPj4gd3JvdGU6DQpUaGUgZXhwbGFuYXRpb24gb2Ygb24tYmVoYWxmLU9mIGFuZCBB Y3RBcyBhcmUgY29ycmVjdCBpbiB0aGUgZG9jdW1lbnQgYXMgZGVmaW5lZCBieSBXUy1UcnVzdCwg dGhpcyBtYXkgbm90IGJlIHlvdXIgZGVzaXJlIG9yIHVuZGVyc3RhbmRpbmcgYnV0IHRoYXQgaXMg aG93IFdTLVRydXN0IGltcGxlbWVudGF0aW9ucyBzaG91bGQgd29yaw0KDQpGcm9tOiBPQXV0aCBb bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc+XSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IFRodXJzZGF5LCBKdWx5IDMs IDIwMTQgMTE6NDQgQU0NClRvOiBWbGFkaW1pciBEemh1dmlub3YNCkNjOiBvYXV0aEBpZXRmLm9y ZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBkcmFmdC1q b25lcy1vYXV0aC10b2tlbi1leGNoYW5nZS0wMA0KDQpGV0lXLCBJIGFtIHZlcnkgaW50ZXJlc3Rl ZCBpbiB0aGUgZ2VuZXJhbCBjb25jZXB0IG9mIGEgbGlnaHR3ZWlnaHQgb3IgT0F1dGggYmFzZWQg dG9rZW4gZXhjaGFuZ2UgbWVjaGFuaXNtLiBIb3dldmVyLCBkZXNwaXRlIHNvbWUgZGlzdGFzdGUg Zm9yIHRoZSBwcm90b2NvbCwgb3VyIGV4aXN0aW5nIFdTLVRydXN0IGZ1bmN0aW9uYWxpdHkgaGFz IHByb3ZlbiB0byBiZSAiZ29vZCBlbm91Z2giIGZvciBtb3N0IHVzZS1jYXNlcywgd2hpY2ggc2Vl bXMgdG8gcHJldmVudCB3b3JrIG9uIHRva2VuIGV4Y2hhbmdlIGZyb20gZ2V0dGluZyBhbnkgcmVh bCBwcmlvcml0eS4NCkkgaGF2ZSBhIGZldyB0aG91Z2h0cyBvbiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC10b2tlbi1leGNoYW5nZS0wMCB3aGljaCBJJ3ZlIGJl ZW4gbWVhbmluZyB0byB3cml0ZSBkb3duIGJ1dCBoYXZlbid0IHlldCwgc28gdGhpcyBzZWVtcyBs aWtlIGFzIGdvb2QgYSB0aW1lIGFzIGFueS4NCkkgd291bGQgcmVhbGx5IGxpa2UgdG8gc2VlIGEg c2ltcGxlciByZXF1ZXN0IG1vZGVsIHRoYXQgZG9lc24ndCByZXF1aXJlIHRoZSByZXF1ZXN0IHRv IGJlIEpXVCBlbmNvZGVkLg0KVGhlIGRyYWZ0IG1lbnRpb25zIHRoZSBwb3RlbnRpYWwgY29uZnVz aW9uIGFyb3VuZCBPbi1CZWhhbGYtT2YgdnMuIEltcGVyc29uYXRpb24gU2VtYW50aWNzLiBBbmQg aXQgaXMgY29uZnVzaW5nICh0byBtZSBhbnl3YXkpLiBJbiBmYWN0LCB0aGUgdXNlIG9mIEFjdC1B cyBhbmQgT24tQmVoYWxmLU9mIHNlZW0gdG8gYmUgcmV2ZXJzZWQgZnJvbSBob3cgdGhleSBhcmUg ZGVmaW5lZCBpbiBXUy1UcnVzdDxodHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9yZy93cy1zeC93cy10 cnVzdC92MS40L3dzLXRydXN0Lmh0bWw+ICh0aGlzIE1TIEZBUTxodHRwOi8vbXNkbi5taWNyb3Nv ZnQuY29tL2VuLXVzL2xpYnJhcnkvZWU3NDg0ODcuYXNweD4gaGFzIGxlc3MgY29uZnVzaW5nIHdv cmRpbmcpLiBUaGV5IHNob3VsZCBwcm9iYWJseSBiZSBhbGlnbmVkIHdpdGggdGhhdCBwcmlvciB3 b3JrIHRvIGF2b2lkIGZ1cnRoZXIgY29uZnVzaW9uLiBPciBtYXliZSBtYWtpbmcgYSBjbGVhbiBi cmVhayBhbmQgaW50cm9kdWNpbmcgbmV3IHRlcm1zIHdvdWxkIGJlIGJldHRlci4NCkkgZG9uJ3Qg dGhpbmsgdGhlIHNlY3VyaXR5X3Rva2VuX3JlcXVlc3QgZ3JhbnQgdHlwZSB2YWx1ZSBpcyBzdHJp Y3RseSBsZWdhbCBwZXIgUkZDIDY3NDkuIFRoZSBBQk5GIGF0IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzY3NDkjYXBwZW5kaXgtQS4xMCB3b3VsZCBhbGxvdyBpdCBidXQgYWNjb3JkaW5n IHRvIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi00LjUgZXh0ZW5z aW9uIGdyYW50cyBuZWVkIGFuIGFic29sdXRlIFVSSSBhcyB0aGUgZ3JhbnQgdHlwZSB2YWx1ZSAo dGhlcmUncyBubyBncmFudCB0eXBlIHJlZ2lzdHJ5IHNvIHRoZSBVUkkgaXMgdGhlIG9ubHkgbWVh bnMgb2YgcHJldmVudGluZyBjb2xsaXNpb24pLg0KDQoNCg0KDQoNCk9uIEZyaSwgSnVuIDI3LCAy MDE0IGF0IDY6MDcgQU0sIFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5j b208bWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPj4gd3JvdGU6DQpIYXMgYW55b25lIGlt cGxlbWVudGVkIHRoZSBPQXV0aCAyLjAgVG9rZW4gZXhjaGFuZ2UgZHJhZnQsIGluIHBhcnRpY3Vs YXINCnRoZSBvbi1iZWhhbGYtb2Ygc2VtYW50aWNzPyBXZSd2ZSBnb3QgYSB1c2UgY2FzZSBmb3Ig dGhhdCBhbmQgSSdtDQpjdXJpb3VzIGlmIHNvbWVvbmUgaGFzIHVzZWQgaXQgaW4gcHJhY3RpY2Uu DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWV4 Y2hhbmdlLTAwDQoNClRoYW5rcywNCg0KVmxhZGltaXINCi0tDQpWbGFkaW1pciBEemh1dmlub3Yg PHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPG1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4+ DQpDb25uZWN0MmlkIEx0ZC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0KDQoNCg== --_000_25c76f47a47e4c9faac9995cc1d89364BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJltIGxv c3QsIHRoZSB0ZXJtcyBkZWZpbmVkIGluIHRoZSBvYXV0aCB0b2tlbi1leGNoYW5nZSBkcmFmdCBh cmUgdGhlIHNhbWUgdGVybXMgZGVmaW5lZCBpbiB3cy10cnVzdCBhbmQgaGF2ZSB0aGUgc2FtZSBk ZWZpbml0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5 IDMsIDIwMTQgMTI6MDIgUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbjxicj4NCjxi PkNjOjwvYj4gVmxhZGltaXIgRHpodXZpbm92OyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW09BVVRILVdHXSBkcmFmdC1qb25lcy1vYXV0aC10b2tlbi1leGNoYW5nZS0w MDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBJIHdhcyBzdWdnZXN0 aW5nIHRoYXQgT0F1dGggdG9rZW4gZXhjaGFuZ2UgYWxpZ24gd2l0aCB0aGUgV1MtVHJ1c3QgZGVm aW5pdGlvbnMgb3IgbWF5YmUgZXZlbiBkZWZpbmUgdG90YWxseSBuZXcgdGVybXMuIEJ1dCBub3Qg dXNlIHRoZSBzYW1lIHRlcm1zIHRvIG1lYW4gZGlmZmVyZW50IHRoaW5ncy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVGh1LCBKdWwgMywgMjAxNCBhdCAxMjo1NSBQTSwgQW50aG9ueSBOYWRhbGluICZs dDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgZXhwbGFuYXRpb24gb2Ygb24tYmVo YWxmLU9mIGFuZCBBY3RBcyBhcmUgY29ycmVjdCBpbiB0aGUgZG9jdW1lbnQgYXMgZGVmaW5lZCBi eSBXUy1UcnVzdCwgdGhpcw0KIG1heSBub3QgYmUgeW91ciBkZXNpcmUgb3IgdW5kZXJzdGFuZGlu ZyBidXQgdGhhdCBpcyBob3cgV1MtVHJ1c3QgaW1wbGVtZW50YXRpb25zIHNob3VsZCB3b3JrPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSIxNDZm ZDk0ZjI4OGY4OTI2X19NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJpYW4gQ2FtcGJlbGw8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMywgMjAxNCAxMTo0NCBBTTxicj4NCjxi PlRvOjwvYj4gVmxhZGltaXIgRHpodXZpbm92PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gZHJhZnQtam9uZXMtb2F1dGgtdG9rZW4t ZXhjaGFuZ2UtMDA8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+RldJVywgSSBhbSB2ZXJ5IGludGVyZXN0 ZWQgaW4gdGhlIGdlbmVyYWwgY29uY2VwdCBvZiBhIGxpZ2h0d2VpZ2h0IG9yIE9BdXRoIGJhc2Vk IHRva2VuIGV4Y2hhbmdlIG1lY2hhbmlzbS4gSG93ZXZlciwgZGVzcGl0ZSBzb21lIGRpc3Rhc3Rl IGZvciB0aGUgcHJvdG9jb2wsIG91ciBleGlzdGluZyBXUy1UcnVzdCBmdW5jdGlvbmFsaXR5DQog aGFzIHByb3ZlbiB0byBiZSAmcXVvdDtnb29kIGVub3VnaCZxdW90OyBmb3IgbW9zdCB1c2UtY2Fz ZXMsIHdoaWNoIHNlZW1zIHRvIHByZXZlbnQgd29yayBvbiB0b2tlbiBleGNoYW5nZSBmcm9tIGdl dHRpbmcgYW55IHJlYWwgcHJpb3JpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+SSBoYXZlIGEgZmV3IHRob3VnaHRzIG9uDQo8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC10b2tlbi1leGNoYW5nZS0wMCIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgt dG9rZW4tZXhjaGFuZ2UtMDA8L2E+IHdoaWNoIEkndmUgYmVlbiBtZWFuaW5nIHRvIHdyaXRlIGRv d24gYnV0IGhhdmVuJ3QgeWV0LCBzbyB0aGlzIHNlZW1zIGxpa2UgYXMgZ29vZCBhIHRpbWUgYXMg YW55Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SSB3b3VsZCBy ZWFsbHkgbGlrZSB0byBzZWUgYSBzaW1wbGVyIHJlcXVlc3QgbW9kZWwgdGhhdCBkb2Vzbid0IHJl cXVpcmUgdGhlIHJlcXVlc3QgdG8gYmUgSldUIGVuY29kZWQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlIGRyYWZ0IG1lbnRpb25zIHRoZSBwb3RlbnRpYWwgY29u ZnVzaW9uIGFyb3VuZCBPbi1CZWhhbGYtT2YgdnMuIEltcGVyc29uYXRpb24gU2VtYW50aWNzLiBB bmQgaXQgaXMgY29uZnVzaW5nICh0byBtZSBhbnl3YXkpLiBJbiBmYWN0LCB0aGUgdXNlIG9mIEFj dC1BcyBhbmQgT24tQmVoYWxmLU9mIHNlZW0gdG8gYmUNCiByZXZlcnNlZCBmcm9tIGhvdyB0aGV5 IGFyZSBkZWZpbmVkIGluIDxhIGhyZWY9Imh0dHA6Ly9kb2NzLm9hc2lzLW9wZW4ub3JnL3dzLXN4 L3dzLXRydXN0L3YxLjQvd3MtdHJ1c3QuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KV1MtVHJ1c3Q8 L2E+ICg8YSBocmVmPSJodHRwOi8vbXNkbi5taWNyb3NvZnQuY29tL2VuLXVzL2xpYnJhcnkvZWU3 NDg0ODcuYXNweCIgdGFyZ2V0PSJfYmxhbmsiPnRoaXMgTVMgRkFRPC9hPiBoYXMgbGVzcyBjb25m dXNpbmcgd29yZGluZykuIFRoZXkgc2hvdWxkIHByb2JhYmx5IGJlIGFsaWduZWQgd2l0aCB0aGF0 IHByaW9yIHdvcmsgdG8gYXZvaWQgZnVydGhlciBjb25mdXNpb24uIE9yIG1heWJlIG1ha2luZyBh IGNsZWFuIGJyZWFrIGFuZCBpbnRyb2R1Y2luZw0KIG5ldyB0ZXJtcyB3b3VsZCBiZSBiZXR0ZXIu IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG9uJ3Qg dGhpbmsgdGhlIHNlY3VyaXR5X3Rva2VuX3JlcXVlc3QgZ3JhbnQgdHlwZSB2YWx1ZSBpcyBzdHJp Y3RseSBsZWdhbCBwZXIgUkZDIDY3NDkuIFRoZSBBQk5GIGF0DQo8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I2FwcGVuZGl4LUEuMTAiIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I2FwcGVuZGl4LUEuMTA8L2E+IHdvdWxk IGFsbG93IGl0IGJ1dCBhY2NvcmRpbmcgdG8NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzY3NDkjc2VjdGlvbi00LjUiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tNC41PC9hPiBleHRlbnNpb24gZ3JhbnRzIG5l ZWQgYW4gYWJzb2x1dGUgVVJJIGFzIHRoZSBncmFudCB0eXBlIHZhbHVlICh0aGVyZSdzIG5vIGdy YW50IHR5cGUgcmVnaXN0cnkgc28gdGhlIFVSSSBpcyB0aGUgb25seSBtZWFucyBvZiBwcmV2ZW50 aW5nDQogY29sbGlzaW9uKS4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgSnVu IDI3LCAyMDE0IGF0IDY6MDcgQU0sIFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7PGEgaHJlZj0ibWFp bHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmxhZGltaXJAY29u bmVjdDJpZC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5IYXMgYW55b25lIGltcGxlbWVudGVkIHRoZSBPQXV0aCAyLjAgVG9rZW4gZXhjaGFuZ2UgZHJh ZnQsIGluIHBhcnRpY3VsYXI8YnI+DQp0aGUgb24tYmVoYWxmLW9mIHNlbWFudGljcz8gV2UndmUg Z290IGEgdXNlIGNhc2UgZm9yIHRoYXQgYW5kIEknbTxicj4NCmN1cmlvdXMgaWYgc29tZW9uZSBo YXMgdXNlZCBpdCBpbiBwcmFjdGljZS48YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC10b2tlbi1leGNoYW5nZS0wMCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLXRv a2VuLWV4Y2hhbmdlLTAwPC9hPjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQo8YnI+DQpWbGFkaW1p cjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLTxicj4NClZsYWRpbWlyIER6aHV2 aW5vdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+dmxhZGltaXJAY29ubmVjdDJpZC5jb208L2E+Jmd0Ozxicj4NCkNvbm5lY3QyaWQg THRkLjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_25c76f47a47e4c9faac9995cc1d89364BLUPR03MB309namprd03pro_-- From nobody Thu Jul 3 12:21:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762C91B2B21 for ; Thu, 3 Jul 2014 12:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZY6LPvBQeGa for ; Thu, 3 Jul 2014 12:21:29 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDC61B2A05 for ; Thu, 3 Jul 2014 12:21:28 -0700 (PDT) Received: from BY2PR03CA035.namprd03.prod.outlook.com (10.242.234.156) by BY2PR03MB144.namprd03.prod.outlook.com (10.242.35.150) with Microsoft SMTP Server (TLS) id 15.0.969.15; Thu, 3 Jul 2014 19:21:19 +0000 Received: from BY2FFO11FD048.protection.gbl (2a01:111:f400:7c0c::125) by BY2PR03CA035.outlook.office365.com (2a01:111:e400:2c2c::28) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Thu, 3 Jul 2014 19:21:19 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD048.mail.protection.outlook.com (10.1.15.176) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Thu, 3 Jul 2014 19:21:19 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0195.002; Thu, 3 Jul 2014 19:20:29 +0000 From: Mike Jones To: Anthony Nadalin , Brian Campbell Thread-Topic: [OAUTH-WG] draft-jones-oauth-token-exchange-00 Thread-Index: AQHPkgBl906E2Asb1Em2UCSL1JxOxJuOuWWAgAADMQCAAAHOAIAAALMAgAAETrA= Date: Thu, 3 Jul 2014 19:20:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD990D2@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <1403870837.2440.124.camel@shakespeare> <930f1bd03c9e4cbaae1e5c321b0ee5ec@BLUPR03MB309.namprd03.prod.outlook.com> <25c76f47a47e4c9faac9995cc1d89364@BLUPR03MB309.namprd03.prod.outlook.com> In-Reply-To: <25c76f47a47e4c9faac9995cc1d89364@BLUPR03MB309.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD990D2TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(199002)(189002)(164054003)(377454003)(24454002)(69234005)(512874002)(19625215002)(93886003)(84676001)(20776003)(81342001)(81542001)(76176999)(50986999)(99396002)(85306003)(54356999)(77096002)(80022001)(71186001)(64706001)(66066001)(95666004)(15202345003)(86362001)(16297215004)(81156004)(106466001)(106116001)(31966008)(107046002)(76482001)(19300405004)(16236675004)(15975445006)(26826002)(21056001)(46102001)(92566001)(92726001)(33656002)(86612001)(74502001)(74662001)(4396001)(2656002)(97736001)(87936001)(104016002)(84326002)(1511001)(79102001)(55846006)(44976005)(6806004)(77982001)(69596002)(85852003)(68736004)(83072002)(19580405001)(83322001)(19580395003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB144; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0261CCEEDF Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/veQwQowPOp71_5k0opoY7rabi7Q Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 19:21:31 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD990D2TK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbG9zdCB0b28sIGFzIHdoZW4gSSB3cm90ZSB0aGlzLCBJIGV4cGxpY2l0bHkgbW9kZWxs ZWQgaXQgYWZ0ZXIgV1MtVHJ1c3QuICBJZiB0aGVyZeKAmXMgYSBjb25jcmV0ZSBkaXNjcmVwYW5j eSB5b3UgY2FuIHBvaW50IG91dCwgdGhhdCB3b3VsZCBiZSBncmVhdC4NCg0KRllJLCBJIGRvIHBs YW4gdG8gcmVmcmVzaCB0aGlzIGRyYWZ0IHRvbyBhbGxvdyBmb3IgYSBtb3JlIGZsZXhpYmxlIHRy dXN0IG1vZGVsIHNob3J0bHkuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFudGhvbnkgTmFkYWxpbg0K U2VudDogVGh1cnNkYXksIEp1bHkgMDMsIDIwMTQgMTI6MDQgUE0NClRvOiBCcmlhbiBDYW1wYmVs bA0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBkcmFmdC1qb25l cy1vYXV0aC10b2tlbi1leGNoYW5nZS0wMA0KDQpJ4oCZbSBsb3N0LCB0aGUgdGVybXMgZGVmaW5l ZCBpbiB0aGUgb2F1dGggdG9rZW4tZXhjaGFuZ2UgZHJhZnQgYXJlIHRoZSBzYW1lIHRlcm1zIGRl ZmluZWQgaW4gd3MtdHJ1c3QgYW5kIGhhdmUgdGhlIHNhbWUgZGVmaW5pdGlvbnMNCg0KRnJvbTog QnJpYW4gQ2FtcGJlbGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NClNlbnQ6 IFRodXJzZGF5LCBKdWx5IDMsIDIwMTQgMTI6MDIgUE0NClRvOiBBbnRob255IE5hZGFsaW4NCkNj OiBWbGFkaW1pciBEemh1dmlub3Y7IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIGRyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWV4Y2hh bmdlLTAwDQoNCkFuZCBJIHdhcyBzdWdnZXN0aW5nIHRoYXQgT0F1dGggdG9rZW4gZXhjaGFuZ2Ug YWxpZ24gd2l0aCB0aGUgV1MtVHJ1c3QgZGVmaW5pdGlvbnMgb3IgbWF5YmUgZXZlbiBkZWZpbmUg dG90YWxseSBuZXcgdGVybXMuIEJ1dCBub3QgdXNlIHRoZSBzYW1lIHRlcm1zIHRvIG1lYW4gZGlm ZmVyZW50IHRoaW5ncy4NCg0KT24gVGh1LCBKdWwgMywgMjAxNCBhdCAxMjo1NSBQTSwgQW50aG9u eSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0 LmNvbT4+IHdyb3RlOg0KVGhlIGV4cGxhbmF0aW9uIG9mIG9uLWJlaGFsZi1PZiBhbmQgQWN0QXMg YXJlIGNvcnJlY3QgaW4gdGhlIGRvY3VtZW50IGFzIGRlZmluZWQgYnkgV1MtVHJ1c3QsIHRoaXMg bWF5IG5vdCBiZSB5b3VyIGRlc2lyZSBvciB1bmRlcnN0YW5kaW5nIGJ1dCB0aGF0IGlzIGhvdyBX Uy1UcnVzdCBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIHdvcmsNCg0KRnJvbTogT0F1dGggW21haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0g T24gQmVoYWxmIE9mIEJyaWFuIENhbXBiZWxsDQpTZW50OiBUaHVyc2RheSwgSnVseSAzLCAyMDE0 IDExOjQ0IEFNDQpUbzogVmxhZGltaXIgRHpodXZpbm92DQpDYzogb2F1dGhAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gZHJhZnQtam9uZXMt b2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDANCg0KRldJVywgSSBhbSB2ZXJ5IGludGVyZXN0ZWQgaW4g dGhlIGdlbmVyYWwgY29uY2VwdCBvZiBhIGxpZ2h0d2VpZ2h0IG9yIE9BdXRoIGJhc2VkIHRva2Vu IGV4Y2hhbmdlIG1lY2hhbmlzbS4gSG93ZXZlciwgZGVzcGl0ZSBzb21lIGRpc3Rhc3RlIGZvciB0 aGUgcHJvdG9jb2wsIG91ciBleGlzdGluZyBXUy1UcnVzdCBmdW5jdGlvbmFsaXR5IGhhcyBwcm92 ZW4gdG8gYmUgImdvb2QgZW5vdWdoIiBmb3IgbW9zdCB1c2UtY2FzZXMsIHdoaWNoIHNlZW1zIHRv IHByZXZlbnQgd29yayBvbiB0b2tlbiBleGNoYW5nZSBmcm9tIGdldHRpbmcgYW55IHJlYWwgcHJp b3JpdHkuDQpJIGhhdmUgYSBmZXcgdGhvdWdodHMgb24gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtam9uZXMtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDAgd2hpY2ggSSd2ZSBiZWVuIG1l YW5pbmcgdG8gd3JpdGUgZG93biBidXQgaGF2ZW4ndCB5ZXQsIHNvIHRoaXMgc2VlbXMgbGlrZSBh cyBnb29kIGEgdGltZSBhcyBhbnkuDQpJIHdvdWxkIHJlYWxseSBsaWtlIHRvIHNlZSBhIHNpbXBs ZXIgcmVxdWVzdCBtb2RlbCB0aGF0IGRvZXNuJ3QgcmVxdWlyZSB0aGUgcmVxdWVzdCB0byBiZSBK V1QgZW5jb2RlZC4NClRoZSBkcmFmdCBtZW50aW9ucyB0aGUgcG90ZW50aWFsIGNvbmZ1c2lvbiBh cm91bmQgT24tQmVoYWxmLU9mIHZzLiBJbXBlcnNvbmF0aW9uIFNlbWFudGljcy4gQW5kIGl0IGlz IGNvbmZ1c2luZyAodG8gbWUgYW55d2F5KS4gSW4gZmFjdCwgdGhlIHVzZSBvZiBBY3QtQXMgYW5k IE9uLUJlaGFsZi1PZiBzZWVtIHRvIGJlIHJldmVyc2VkIGZyb20gaG93IHRoZXkgYXJlIGRlZmlu ZWQgaW4gV1MtVHJ1c3Q8aHR0cDovL2RvY3Mub2FzaXMtb3Blbi5vcmcvd3Mtc3gvd3MtdHJ1c3Qv djEuNC93cy10cnVzdC5odG1sPiAodGhpcyBNUyBGQVE8aHR0cDovL21zZG4ubWljcm9zb2Z0LmNv bS9lbi11cy9saWJyYXJ5L2VlNzQ4NDg3LmFzcHg+IGhhcyBsZXNzIGNvbmZ1c2luZyB3b3JkaW5n KS4gVGhleSBzaG91bGQgcHJvYmFibHkgYmUgYWxpZ25lZCB3aXRoIHRoYXQgcHJpb3Igd29yayB0 byBhdm9pZCBmdXJ0aGVyIGNvbmZ1c2lvbi4gT3IgbWF5YmUgbWFraW5nIGEgY2xlYW4gYnJlYWsg YW5kIGludHJvZHVjaW5nIG5ldyB0ZXJtcyB3b3VsZCBiZSBiZXR0ZXIuDQpJIGRvbid0IHRoaW5r IHRoZSBzZWN1cml0eV90b2tlbl9yZXF1ZXN0IGdyYW50IHR5cGUgdmFsdWUgaXMgc3RyaWN0bHkg bGVnYWwgcGVyIFJGQyA2NzQ5LiBUaGUgQUJORiBhdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM2NzQ5I2FwcGVuZGl4LUEuMTAgd291bGQgYWxsb3cgaXQgYnV0IGFjY29yZGluZyB0byBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tNC41IGV4dGVuc2lvbiBn cmFudHMgbmVlZCBhbiBhYnNvbHV0ZSBVUkkgYXMgdGhlIGdyYW50IHR5cGUgdmFsdWUgKHRoZXJl J3Mgbm8gZ3JhbnQgdHlwZSByZWdpc3RyeSBzbyB0aGUgVVJJIGlzIHRoZSBvbmx5IG1lYW5zIG9m IHByZXZlbnRpbmcgY29sbGlzaW9uKS4NCg0KDQoNCg0KDQpPbiBGcmksIEp1biAyNywgMjAxNCBh dCA2OjA3IEFNLCBWbGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPG1h aWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4+IHdyb3RlOg0KSGFzIGFueW9uZSBpbXBsZW1l bnRlZCB0aGUgT0F1dGggMi4wIFRva2VuIGV4Y2hhbmdlIGRyYWZ0LCBpbiBwYXJ0aWN1bGFyDQp0 aGUgb24tYmVoYWxmLW9mIHNlbWFudGljcz8gV2UndmUgZ290IGEgdXNlIGNhc2UgZm9yIHRoYXQg YW5kIEknbQ0KY3VyaW91cyBpZiBzb21lb25lIGhhcyB1c2VkIGl0IGluIHByYWN0aWNlLg0KDQpo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC10b2tlbi1leGNoYW5n ZS0wMA0KDQpUaGFua3MsDQoNClZsYWRpbWlyDQotLQ0KVmxhZGltaXIgRHpodXZpbm92IDx2bGFk aW1pckBjb25uZWN0MmlkLmNvbTxtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20+Pg0KQ29u bmVjdDJpZCBMdGQuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K DQo= --_000_4E1F6AAD24975D4BA5B16804296739439AD990D2TK5EX14MBXC294r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmW0gbG9zdCB0b28sIGFzIHdoZW4g SSB3cm90ZSB0aGlzLCBJIGV4cGxpY2l0bHkgbW9kZWxsZWQgaXQgYWZ0ZXIgV1MtVHJ1c3QuJm5i c3A7IElmIHRoZXJl4oCZcyBhIGNvbmNyZXRlIGRpc2NyZXBhbmN5IHlvdSBjYW4gcG9pbnQgb3V0 LCB0aGF0IHdvdWxkIGJlIGdyZWF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RllJLCBJIGRvIHBsYW4gdG8gcmVmcmVz aCB0aGlzIGRyYWZ0IHRvbyBhbGxvdyBmb3IgYSBtb3JlIGZsZXhpYmxlIHRydXN0IG1vZGVsIHNo b3J0bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0g TWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW50aG9ueSBOYWRhbGluPGJyPg0KPGI+U2VudDo8 L2I+IFRodXJzZGF5LCBKdWx5IDAzLCAyMDE0IDEyOjA0IFBNPGJyPg0KPGI+VG86PC9iPiBCcmlh biBDYW1wYmVsbDxicj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtPQVVUSC1XR10gZHJhZnQtam9uZXMtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmW0gbG9zdCwgdGhlIHRlcm1zIGRl ZmluZWQgaW4gdGhlIG9hdXRoIHRva2VuLWV4Y2hhbmdlIGRyYWZ0IGFyZSB0aGUgc2FtZSB0ZXJt cyBkZWZpbmVkIGluIHdzLXRydXN0IGFuZCBoYXZlIHRoZSBzYW1lIGRlZmluaXRpb25zPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IEJyaWFuIENhbXBiZWxsIFs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBp bmdpZGVudGl0eS5jb20iPm1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMywgMjAxNCAxMjowMiBQTTxicj4NCjxi PlRvOjwvYj4gQW50aG9ueSBOYWRhbGluPGJyPg0KPGI+Q2M6PC9iPiBWbGFkaW1pciBEemh1dmlu b3Y7IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIGRyYWZ0LWpvbmVzLW9hdXRoLXRva2Vu LWV4Y2hhbmdlLTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIEkg d2FzIHN1Z2dlc3RpbmcgdGhhdCBPQXV0aCB0b2tlbiBleGNoYW5nZSBhbGlnbiB3aXRoIHRoZSBX Uy1UcnVzdCBkZWZpbml0aW9ucyBvciBtYXliZSBldmVuIGRlZmluZSB0b3RhbGx5IG5ldyB0ZXJt cy4gQnV0IG5vdCB1c2UgdGhlIHNhbWUgdGVybXMgdG8gbWVhbiBkaWZmZXJlbnQgdGhpbmdzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAzLCAyMDE0IGF0IDEyOjU1IFBNLCBBbnRob255 IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iIHRhcmdl dD0iX2JsYW5rIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgZXhwbGFuYXRpb24gb2Ygb24tYmVoYWxmLU9mIGFu ZCBBY3RBcyBhcmUgY29ycmVjdCBpbiB0aGUgZG9jdW1lbnQgYXMgZGVmaW5lZCBieSBXUy1UcnVz dCwgdGhpcw0KIG1heSBub3QgYmUgeW91ciBkZXNpcmUgb3IgdW5kZXJzdGFuZGluZyBidXQgdGhh dCBpcyBob3cgV1MtVHJ1c3QgaW1wbGVtZW50YXRpb25zIHNob3VsZCB3b3JrPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSIxNDZmZDk0ZjI4OGY4 OTI2X19NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5T ZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMywgMjAxNCAxMTo0NCBBTTxicj4NCjxiPlRvOjwvYj4g VmxhZGltaXIgRHpodXZpbm92PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86b2F1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gZHJhZnQtam9uZXMtb2F1dGgtdG9rZW4tZXhjaGFuZ2Ut MDA8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+RldJVywgSSBhbSB2ZXJ5IGludGVyZXN0ZWQgaW4gdGhl IGdlbmVyYWwgY29uY2VwdCBvZiBhIGxpZ2h0d2VpZ2h0IG9yIE9BdXRoIGJhc2VkIHRva2VuIGV4 Y2hhbmdlIG1lY2hhbmlzbS4gSG93ZXZlciwgZGVzcGl0ZSBzb21lIGRpc3Rhc3RlIGZvciB0aGUg cHJvdG9jb2wsIG91ciBleGlzdGluZyBXUy1UcnVzdCBmdW5jdGlvbmFsaXR5DQogaGFzIHByb3Zl biB0byBiZSAmcXVvdDtnb29kIGVub3VnaCZxdW90OyBmb3IgbW9zdCB1c2UtY2FzZXMsIHdoaWNo IHNlZW1zIHRvIHByZXZlbnQgd29yayBvbiB0b2tlbiBleGNoYW5nZSBmcm9tIGdldHRpbmcgYW55 IHJlYWwgcHJpb3JpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ SSBoYXZlIGEgZmV3IHRob3VnaHRzIG9uDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1qb25lcy1vYXV0aC10b2tlbi1leGNoYW5nZS0wMCIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtdG9rZW4tZXhj aGFuZ2UtMDA8L2E+IHdoaWNoIEkndmUgYmVlbiBtZWFuaW5nIHRvIHdyaXRlIGRvd24gYnV0IGhh dmVuJ3QgeWV0LCBzbyB0aGlzIHNlZW1zIGxpa2UgYXMgZ29vZCBhIHRpbWUgYXMgYW55Lg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SSB3b3VsZCByZWFsbHkgbGlr ZSB0byBzZWUgYSBzaW1wbGVyIHJlcXVlc3QgbW9kZWwgdGhhdCBkb2Vzbid0IHJlcXVpcmUgdGhl IHJlcXVlc3QgdG8gYmUgSldUIGVuY29kZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+VGhlIGRyYWZ0IG1lbnRpb25zIHRoZSBwb3RlbnRpYWwgY29uZnVzaW9uIGFy b3VuZCBPbi1CZWhhbGYtT2YgdnMuIEltcGVyc29uYXRpb24gU2VtYW50aWNzLiBBbmQgaXQgaXMg Y29uZnVzaW5nICh0byBtZSBhbnl3YXkpLiBJbiBmYWN0LCB0aGUgdXNlIG9mIEFjdC1BcyBhbmQg T24tQmVoYWxmLU9mIHNlZW0gdG8gYmUNCiByZXZlcnNlZCBmcm9tIGhvdyB0aGV5IGFyZSBkZWZp bmVkIGluIDxhIGhyZWY9Imh0dHA6Ly9kb2NzLm9hc2lzLW9wZW4ub3JnL3dzLXN4L3dzLXRydXN0 L3YxLjQvd3MtdHJ1c3QuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KV1MtVHJ1c3Q8L2E+ICg8YSBo cmVmPSJodHRwOi8vbXNkbi5taWNyb3NvZnQuY29tL2VuLXVzL2xpYnJhcnkvZWU3NDg0ODcuYXNw eCIgdGFyZ2V0PSJfYmxhbmsiPnRoaXMgTVMgRkFRPC9hPiBoYXMgbGVzcyBjb25mdXNpbmcgd29y ZGluZykuIFRoZXkgc2hvdWxkIHByb2JhYmx5IGJlIGFsaWduZWQgd2l0aCB0aGF0IHByaW9yIHdv cmsgdG8gYXZvaWQgZnVydGhlciBjb25mdXNpb24uIE9yIG1heWJlIG1ha2luZyBhIGNsZWFuIGJy ZWFrIGFuZCBpbnRyb2R1Y2luZw0KIG5ldyB0ZXJtcyB3b3VsZCBiZSBiZXR0ZXIuIDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG9uJ3QgdGhpbmsgdGhl IHNlY3VyaXR5X3Rva2VuX3JlcXVlc3QgZ3JhbnQgdHlwZSB2YWx1ZSBpcyBzdHJpY3RseSBsZWdh bCBwZXIgUkZDIDY3NDkuIFRoZSBBQk5GIGF0DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2NzQ5I2FwcGVuZGl4LUEuMTAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I2FwcGVuZGl4LUEuMTA8L2E+IHdvdWxkIGFsbG93IGl0 IGJ1dCBhY2NvcmRpbmcgdG8NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzY3NDkjc2VjdGlvbi00LjUiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM2NzQ5I3NlY3Rpb24tNC41PC9hPiBleHRlbnNpb24gZ3JhbnRzIG5lZWQgYW4gYWJz b2x1dGUgVVJJIGFzIHRoZSBncmFudCB0eXBlIHZhbHVlICh0aGVyZSdzIG5vIGdyYW50IHR5cGUg cmVnaXN0cnkgc28gdGhlIFVSSSBpcyB0aGUgb25seSBtZWFucyBvZiBwcmV2ZW50aW5nDQogY29s bGlzaW9uKS4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQom bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgSnVuIDI3LCAyMDE0 IGF0IDY6MDcgQU0sIFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZsYWRp bWlyQGNvbm5lY3QyaWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmxhZGltaXJAY29ubmVjdDJpZC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IYXMgYW55 b25lIGltcGxlbWVudGVkIHRoZSBPQXV0aCAyLjAgVG9rZW4gZXhjaGFuZ2UgZHJhZnQsIGluIHBh cnRpY3VsYXI8YnI+DQp0aGUgb24tYmVoYWxmLW9mIHNlbWFudGljcz8gV2UndmUgZ290IGEgdXNl IGNhc2UgZm9yIHRoYXQgYW5kIEknbTxicj4NCmN1cmlvdXMgaWYgc29tZW9uZSBoYXMgdXNlZCBp dCBpbiBwcmFjdGljZS48YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1qb25lcy1vYXV0aC10b2tlbi1leGNoYW5nZS0wMCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWV4Y2hh bmdlLTAwPC9hPjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQo8YnI+DQpWbGFkaW1pcjxicj4NCjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLTxicj4NClZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ dmxhZGltaXJAY29ubmVjdDJpZC5jb208L2E+Jmd0Ozxicj4NCkNvbm5lY3QyaWQgTHRkLjxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439AD990D2TK5EX14MBXC294r_-- From nobody Thu Jul 3 12:38:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6621B2861 for ; Thu, 3 Jul 2014 12:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sJzSJSrdZlv for ; Thu, 3 Jul 2014 12:38:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643611B2A10 for ; Thu, 3 Jul 2014 12:38:31 -0700 (PDT) Received: from DM2PR03CA006.namprd03.prod.outlook.com (10.141.52.154) by BN1PR0301MB0691.namprd03.prod.outlook.com (25.160.171.28) with Microsoft SMTP Server (TLS) id 15.0.974.11; Thu, 3 Jul 2014 19:38:29 +0000 Received: from BN1AFFO11FD006.protection.gbl (2a01:111:f400:7c10::124) by DM2PR03CA006.outlook.office365.com (2a01:111:e400:2414::26) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Thu, 3 Jul 2014 19:38:28 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD006.mail.protection.outlook.com (10.58.52.66) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Thu, 3 Jul 2014 19:38:27 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0195.002; Thu, 3 Jul 2014 19:38:16 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five Thread-Index: Ac+Vkn9Qxw7nsFWXQgqBEB8Y2w/8RgAAAcxwAFajBAAAAhPGkA== Date: Thu, 3 Jul 2014 19:38:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD991B6@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AD95D0F@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD991B6TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(377454003)(24454002)(199002)(189002)(51914003)(81156004)(106466001)(79102001)(21056001)(97736001)(95666004)(46102001)(4396001)(19300405004)(92726001)(92566001)(84676001)(19580395003)(69596002)(19580405001)(83322001)(84326002)(104016002)(107046002)(16236675004)(74502001)(33656002)(80022001)(26826002)(68736004)(74662001)(50986999)(85306003)(64706001)(6806004)(83072002)(20776003)(19625215002)(512874002)(76176999)(99396002)(55846006)(85852003)(86612001)(71186001)(54356999)(15975445006)(31966008)(77982001)(2656002)(86362001)(66066001)(77096002)(81342001)(81542001)(44976005)(87936001)(76482001)(15202345003)(110136001)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR0301MB0691; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0261CCEEDF Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/j3YWaOuiuCvr5v_920zFaCYZvC4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five 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, 03 Jul 2014 19:38:34 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD991B6TK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjYW4gYWRkIHNvbWV0aGluZyBhbG9uZyB0aGVzZSBsaW5lcy4gIERvZXMgdGhhdCB3b3JrIGZv ciB5b3U/DQoNClByaXZhY3kgQ29uc2lkZXJhdGlvbnMNCkEgSldUIG1heSBjb250YWluIHByaXZh Y3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uLiAgV2hlbiB0aGlzIGlzIHRoZSBjYXNlLCBtZWFzdXJl cyBtdXN0IGJlIHRha2VuIHRvIHByZXZlbnQgZGlzY2xvc3VyZSBvZiB0aGlzIGluZm9ybWF0aW9u IHRvIHVuaW50ZW5kZWQgcGFydGllcy4gIE9uZSB3YXkgdG8gYWNoaWV2ZSB0aGlzIGlzIHRvIHVz ZSBhbiBlbmNyeXB0ZWQgSldULiAgQW5vdGhlciB3YXkgaXMgdG8gZW5zdXJlIHRoYXQgSldUcyBj b250YWluaW5nIHVuZW5jcnlwdGVkIHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGFyZSBv bmx5IHRyYW5zbWl0dGVkIG92ZXIgZW5jcnlwdGVkIGNoYW5uZWxzIG9yIHByb3RvY29scywgc3Vj aCBhcyBUTFMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEthdGhsZWVuIE1vcmlhcnR5IFtt YWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwg SnVseSAwMywgMjAxNCAxMTozMiBBTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBvYXV0aEBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gRlc6IEpPU0UgLTMwIGFuZCBKV1QgLTI0IGRyYWZ0 cyBpbmNvcnBvcmF0aW5nIEFEIGZlZWRiYWNrIG9uIGZpZnRoIHNwZWMgb2YgZml2ZQ0KDQpNaWtl LA0KDQpUaGFua3MgZm9yIHRoZSB1cGRhdGVkIEpXVCBkcmFmdC4gIEkganVzdCByZWFkIHRocm91 Z2ggaXQgYWdhaW4gYW5kIHRoZSBjaGFuZ2VzIGxvb2sgZ29vZC4NCg0KSSBub3RpY2VkIHRoYXQg cHJpdmFjeSBjb25zaWRlcmF0aW9ucyB3ZXJlIG5vdCBtZW50aW9uZWQuICBTaG91bGQgdGhlcmUg YmUgYW55IGRpc2N1c3NlZCBmb3IgY2xhaW1zLCBjbGFpbSBzZXRzLCBldGMuPyAgVGhpcyBpcyBi b3VuZCB0byBjb21lIHVwIGluIHRoZSBJRVNHIHJldmlldyBpZiBpdCBpcyBub3QgYWRkcmVzc2Vk LiAgU29ycnkgSSBkaWRuJ3QgY2F0Y2ggdGhhdCBvbiB0aGUgZmlyc3QgcmV2aWV3Lg0KDQpPbiBU dWUsIEp1bCAxLCAyMDE0IGF0IDk6MTEgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoN Cg0KRnJvbTogTWlrZSBKb25lcw0KU2VudDogVHVlc2RheSwgSnVseSAwMSwgMjAxNCA2OjExIFBN DQpUbzogam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NClN1YmplY3Q6IEpPU0Ug LTMwIGFuZCBKV1QgLTI0IGRyYWZ0cyBpbmNvcnBvcmF0aW5nIEFEIGZlZWRiYWNrIG9uIGZpZnRo IHNwZWMgb2YgZml2ZQ0KDQpKT1NFIC0zMCBhbmQgSldUIC0yNCBkcmFmdHMgaGF2ZSBiZWVuIHBv c3RlZCBpbmNvcnBvcmF0aW5nIGltcHJvdmVtZW50cyByZXN1bHRpbmcgZnJvbSBLYXRobGVlbiBN b3JpYXJ0eeKAmXMgSldFIHJldmlldy4gIEF0IHRoaXMgcG9pbnQsIGFjdGlvbnMgcmVxdWVzdGVk IGluIGhlciByZXZpZXdzIG9mIHRoZSBKV1MsIEpXRSwgSldLLCBKV0EsIGFuZCBKV1Qgc3BlY2lm aWNhdGlvbnMgaGF2ZSBhbGwgYmVlbiBpbmNvcnBvcmF0ZWQuICBBbGwgY2hhbmdlcyBpbiB0aGlz IHJlbGVhc2Ugd2VyZSBzdHJpY3RseSBlZGl0b3JpYWwgaW4gbmF0dXJlLg0KDQpUaGUgc3BlY2lm aWNhdGlvbnMgYXJlIGF2YWlsYWJsZSBhdDoNCg0K4oCiICAgICAgICAgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0zMA0KDQrigKIg ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13 ZWItZW5jcnlwdGlvbi0zMA0KDQrigKIgICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTMwDQoNCuKAoiAgICAgICAgIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTMw DQoNCuKAoiAgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1 dGgtanNvbi13ZWItdG9rZW4tMjQNCg0KSFRNTCBmb3JtYXR0ZWQgdmVyc2lvbnMgYXJlIGF2YWls YWJsZSBhdDoNCg0K4oCiICAgICAgICAgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFm dC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTMwLmh0bWwNCg0K4oCiICAgICAgICAgaHR0 cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlw dGlvbi0zMC5odG1sDQoNCuKAoiAgICAgICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3Mv ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0zMC5odG1sDQoNCuKAoiAgICAgICAgIGh0dHA6 Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRo bXMtMzAuaHRtbA0KDQrigKIgICAgICAgICBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2Ry YWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjQuaHRtbA0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNClAu Uy4gIFRoaXMgbm90aWNlIHdhcyBhbHNvIHBvc3RlZCBhdCBodHRwOi8vc2VsZi1pc3N1ZWQuaW5m by8/cD0xMjQ1IGFuZCBhcyBAc2VsZmlzc3VlZC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQoNCg0KLS0NCg0KQmVzdCByZWdhcmRzLA0KS2F0aGxlZW4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439AD991B6TK5EX14MBXC294r_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBjYW4gYWRkIHNvbWV0aGluZyBhbG9uZyB0aGVzZSBsaW5l cy4mbmJzcDsgRG9lcyB0aGF0IHdvcmsgZm9yIHlvdT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Qcml2YWN5IENvbnNpZGVyYXRpb25zPG86cD48L286cD48L3NwYW4+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QSBKV1QgbWF5IGNvbnRhaW4g cHJpdmFjeS1zZW5zaXRpdmUgaW5mb3JtYXRpb24uJm5ic3A7IFdoZW4gdGhpcyBpcyB0aGUgY2Fz ZSwgbWVhc3VyZXMgbXVzdCBiZSB0YWtlbiB0byBwcmV2ZW50IGRpc2Nsb3N1cmUgb2YgdGhpcyBp bmZvcm1hdGlvbg0KIHRvIHVuaW50ZW5kZWQgcGFydGllcy4mbmJzcDsgT25lIHdheSB0byBhY2hp ZXZlIHRoaXMgaXMgdG8gdXNlIGFuIGVuY3J5cHRlZCBKV1QuJm5ic3A7IEFub3RoZXIgd2F5IGlz IHRvIGVuc3VyZSB0aGF0IEpXVHMgY29udGFpbmluZyB1bmVuY3J5cHRlZCBwcml2YWN5LXNlbnNp dGl2ZSBpbmZvcm1hdGlvbiBhcmUgb25seSB0cmFuc21pdHRlZCBvdmVyIGVuY3J5cHRlZCBjaGFu bmVscyBvciBwcm90b2NvbHMsIHN1Y2ggYXMgVExTLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IEthdGhsZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFy dHkuaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMDMs IDIwMTQgMTE6MzIgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+ IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEZXOiBK T1NFIC0zMCBhbmQgSldUIC0yNCBkcmFmdHMgaW5jb3Jwb3JhdGluZyBBRCBmZWVkYmFjayBvbiBm aWZ0aCBzcGVjIG9mIGZpdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N aWtlLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz IGZvciB0aGUgdXBkYXRlZCBKV1QgZHJhZnQuICZuYnNwO0kganVzdCByZWFkIHRocm91Z2ggaXQg YWdhaW4gYW5kIHRoZSBjaGFuZ2VzIGxvb2sgZ29vZC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgbm90aWNlZCB0aGF0IHByaXZh Y3kgY29uc2lkZXJhdGlvbnMgd2VyZSBub3QgbWVudGlvbmVkLiAmbmJzcDtTaG91bGQgdGhlcmUg YmUgYW55IGRpc2N1c3NlZCBmb3IgY2xhaW1zLCBjbGFpbSBzZXRzLCBldGMuPyAmbmJzcDtUaGlz IGlzIGJvdW5kIHRvIGNvbWUgdXAgaW4gdGhlIElFU0cgcmV2aWV3IGlmIGl0IGlzIG5vdCBhZGRy ZXNzZWQuICZuYnNwO1NvcnJ5IEkgZGlkbid0IGNhdGNoIHRoYXQgb24gdGhlIGZpcnN0IHJldmll dy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1bCAxLCAyMDE0IGF0IDk6MTEg UE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1pa2UgSm9u ZXMNCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDAxLCAyMDE0IDY6MTEgUE08YnI+ DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+am9zZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSk9TRSAtMzAgYW5kIEpX VCAtMjQgZHJhZnRzIGluY29ycG9yYXRpbmcgQUQgZmVlZGJhY2sgb24gZmlmdGggc3BlYyBvZiBm aXZlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Sk9TRSAtMzAgYW5kIEpXVCAtMjQgZHJhZnRzIGhhdmUgYmVlbiBwb3N0ZWQg aW5jb3Jwb3JhdGluZyBpbXByb3ZlbWVudHMgcmVzdWx0aW5nIGZyb20gS2F0aGxlZW4gTW9yaWFy dHnigJlzIEpXRSByZXZpZXcuJm5ic3A7IEF0IHRoaXMgcG9pbnQsIGFjdGlvbnMgcmVxdWVzdGVk IGluIGhlciByZXZpZXdzIG9mIHRoZSBKV1MsDQogSldFLCBKV0ssIEpXQSwgYW5kIEpXVCBzcGVj aWZpY2F0aW9ucyBoYXZlIGFsbCBiZWVuIGluY29ycG9yYXRlZC4mbmJzcDsgQWxsIGNoYW5nZXMg aW4gdGhpcyByZWxlYXNlIHdlcmUgc3RyaWN0bHkgZWRpdG9yaWFsIGluIG5hdHVyZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBzcGVjaWZpY2F0aW9ucyBhcmUgYXZhaWxhYmxlIGF0 OjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0zMCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1q c29uLXdlYi1zaWduYXR1cmUtMzA8L2E+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItZW5jcnlwdGlvbi0zMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTMwPC9hPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0zMCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMzA8 L2E+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7C tzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0zMCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9z ZS1qc29uLXdlYi1hbGdvcml0aG1zLTMwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0 aC1qc29uLXdlYi10b2tlbi0yNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjQ8L2E+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5IVE1MIGZvcm1hdHRlZCB2ZXJzaW9ucyBhcmUgYXZhaWxhYmxlIGF0 OjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3NlbGYt aXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTMwLmh0 bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWll dGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtMzAuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJh ZnQtaWV0Zi1qb3NlLWpzb24td2ViLWVuY3J5cHRpb24tMzAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWVu Y3J5cHRpb24tMzAuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxh IGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1qb3NlLWpzb24t d2ViLWtleS0zMC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8v ZG9jcy9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTMwLmh0bWw8L2E+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9k b2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTMwLmh0bWwiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29u LXdlYi1hbGdvcml0aG1zLTMwLmh0bWw8L2E+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1 dGgtanNvbi13ZWItdG9rZW4tMjQuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zZWxmLWlz c3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNC5odG1sPC9h PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlAuUy4mbmJzcDsgVGhpcyBub3RpY2Ugd2FzIGFsc28gcG9z dGVkIGF0DQo8YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xMjQ1IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTI0NTwvYT4gYW5kIGFzIEBzZWxm aXNzdWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkthdGhsZWVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439AD991B6TK5EX14MBXC294r_-- From nobody Thu Jul 3 12:51:54 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8200C1B287B for ; Thu, 3 Jul 2014 12:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUM43zlhl3K9 for ; Thu, 3 Jul 2014 12:51:51 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084D81B2863 for ; Thu, 3 Jul 2014 12:51:47 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s63Jpjjk010050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Jul 2014 19:51:46 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s63Jpi42004849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Jul 2014 19:51:45 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s63JpiUq004814; Thu, 3 Jul 2014 19:51:44 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Jul 2014 12:51:43 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_920E84AF-A3C7-4359-AD61-E3AA043C34B0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD990D2@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Thu, 3 Jul 2014 12:51:42 -0700 Message-Id: <2196A1F4-51D1-45FF-8F9B-2BD3BF0F7F66@oracle.com> References: <1403870837.2440.124.camel@shakespeare> <930f1bd03c9e4cbaae1e5c321b0ee5ec@BLUPR03MB309.namprd03.prod.outlook.com> <25c76f47a47e4c9faac9995cc1d89364@BLUPR03MB309.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B16804296739439AD990D2@TK5EX14MBXC294.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/c4hubkkn_WxsICbLjvZWlfyqX00 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 19:51:53 -0000 --Apple-Mail=_920E84AF-A3C7-4359-AD61-E3AA043C34B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I suspect it lines up. But Brian=92s point may still be relevant. There = is *long* standing confusion of the terms (because many of have = different english interpretation than WS-Trust). Might be time for new = terms? Impersonate (or even personate) vs. delegate ? Those terms differentiate between impersonating a whole person vs. = having delegate or scoped authority to act for someone. Sorry if this is an old discussion. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 3, 2014, at 12:20 PM, Mike Jones = wrote: > I=92m lost too, as when I wrote this, I explicitly modelled it after = WS-Trust. If there=92s a concrete discrepancy you can point out, that = would be great. > =20 > FYI, I do plan to refresh this draft too allow for a more flexible = trust model shortly. > =20 > -- = Mike > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony = Nadalin > Sent: Thursday, July 03, 2014 12:04 PM > To: Brian Campbell > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > =20 > I=92m lost, the terms defined in the oauth token-exchange draft are = the same terms defined in ws-trust and have the same definitions > =20 > From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 > Sent: Thursday, July 3, 2014 12:02 PM > To: Anthony Nadalin > Cc: Vladimir Dzhuvinov; oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > =20 > And I was suggesting that OAuth token exchange align with the WS-Trust = definitions or maybe even define totally new terms. But not use the same = terms to mean different things. > =20 >=20 > On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin = wrote: > The explanation of on-behalf-Of and ActAs are correct in the document = as defined by WS-Trust, this may not be your desire or understanding but = that is how WS-Trust implementations should work > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian = Campbell > Sent: Thursday, July 3, 2014 11:44 AM > To: Vladimir Dzhuvinov > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > =20 > FWIW, I am very interested in the general concept of a lightweight or = OAuth based token exchange mechanism. However, despite some distaste for = the protocol, our existing WS-Trust functionality has proven to be "good = enough" for most use-cases, which seems to prevent work on token = exchange from getting any real priority. >=20 > I have a few thoughts on = http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which = I've been meaning to write down but haven't yet, so this seems like as = good a time as any. >=20 > I would really like to see a simpler request model that doesn't = require the request to be JWT encoded. >=20 > The draft mentions the potential confusion around On-Behalf-Of vs. = Impersonation Semantics. And it is confusing (to me anyway). In fact, = the use of Act-As and On-Behalf-Of seem to be reversed from how they are = defined in WS-Trust (this MS FAQ has less confusing wording). They = should probably be aligned with that prior work to avoid further = confusion. Or maybe making a clean break and introducing new terms would = be better. >=20 > I don't think the security_token_request grant type value is strictly = legal per RFC 6749. The ABNF at = http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but = according to http://tools.ietf.org/html/rfc6749#section-4.5 extension = grants need an absolute URI as the grant type value (there's no grant = type registry so the URI is the only means of preventing collision). >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov = wrote: > Has anyone implemented the OAuth 2.0 Token exchange draft, in = particular > the on-behalf-of semantics? We've got a use case for that and I'm > curious if someone has used it in practice. >=20 > http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 >=20 > Thanks, >=20 > Vladimir > -- > Vladimir Dzhuvinov > Connect2id Ltd. >=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=_920E84AF-A3C7-4359-AD61-E3AA043C34B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = suspect it lines up. But Brian=92s point may still be relevant. There is = *long* standing confusion of the terms (because many of have different = english interpretation than WS-Trust). Might be time for new = terms?

Impersonate (or even personate) vs. delegate = ?

Those terms differentiate between = impersonating a whole person vs. having delegate or scoped authority to = act for someone.

Sorry if this is an old = discussion.


On Jul 3, 2014, at 12:20 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=92m lost too, as when I wrote this, I explicitly = modelled it after WS-Trust.  If there=92s a concrete discrepancy = you can point out, that would be great.

 

FYI, I do plan to refresh this draft too allow for = a more flexible trust model shortly.

 

        &nbs= p;            =             &n= bsp;           &nbs= p;            =       -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, July 03, 2014 12:04 PM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = draft-jones-oauth-token-exchange-00

 

I=92m lost, the terms defined in the oauth = token-exchange draft are the same terms defined in ws-trust and have the = same definitions

 

From: Brian Campbell [mailto:bcampbell@pingidentity.c= om]
Sent: Thursday, July 3, 2014 12:02 PM
To: Anthony Nadalin
Cc: Vladimir Dzhuvinov; oauth@ietf.org
Subject: Re: [OAUTH-WG] = draft-jones-oauth-token-exchange-00

 

And I was suggesting that OAuth token = exchange align with the WS-Trust definitions or maybe even define = totally new terms. But not use the same terms to mean different = things.

 

On Thu, Jul 3, 2014 at 12:55 PM, Anthony = Nadalin <tonynad@microsoft.com> wrote:

The explanation of on-behalf-Of and ActAs are = correct in the document as defined by WS-Trust, this may not be your desire or understanding but that is how WS-Trust = implementations should work

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 3, 2014 11:44 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = draft-jones-oauth-token-exchange-00

 

FWIW, I am very = interested in the general concept of a lightweight or OAuth based token = exchange mechanism. However, despite some distaste for the protocol, our = existing WS-Trust functionality has proven to be "good enough" for most use-cases, which seems to = prevent work on token exchange from getting any real = priority.

I have a few = thoughts on http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which = I've been meaning to write down but haven't yet, so this seems like as = good a time as any.

I would really = like to see a simpler request model that doesn't require the request to = be JWT encoded.

The draft = mentions the potential confusion around On-Behalf-Of vs. Impersonation = Semantics. And it is confusing (to me anyway). In fact, the use of = Act-As and On-Behalf-Of seem to be reversed from how they are defined in WS-Trust (this MS FAQ has less confusing wording). They = should probably be aligned with that prior work to avoid further = confusion. Or maybe making a clean break and introducing new terms would be better.

I don't = think the security_token_request grant type value is strictly legal per = RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 = would allow it but according to http://tools.ietf.org/html/rfc6749#section-4.5 = extension grants need an absolute URI as the grant type value (there's = no grant type registry so the URI is the only means of preventing collision).


 

 

 

 

On Fri, Jun = 27, 2014 at 6:07 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

Has anyone = implemented the OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-excha= nge-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov <vladimir@connect2id.com>
Connect2id Ltd.

_______________________________________________
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=_920E84AF-A3C7-4359-AD61-E3AA043C34B0-- From nobody Thu Jul 3 12:58:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91CD1B29F5 for ; Thu, 3 Jul 2014 12:58:37 -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 iEOqpAMh5ShL for ; Thu, 3 Jul 2014 12:58:35 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146901B287B for ; Thu, 3 Jul 2014 12:58:34 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id ty20so539061lab.31 for ; Thu, 03 Jul 2014 12:58:33 -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=U/jb8YEs8fmwyG2sSzcp9lTFfhI/vK3Q0u95m8XyUwc=; b=uhI6wsLy3Ej3pslOzIX3k2GDNYbbGF1uNHpeAPY8Bl0mb/pblsz9dDvKvH6+9mP+gr xh98BssS9UmXOx9nY1lJy+3wDdgRXnj1ioSYPe/h9KGnRYHrGo7fQnBLqiArc46czIQB WECT2IVw5dJh3SjjnmuJJEc2K/Q+AdfokF1Xqd3EmAJMyv33waH47nNO+roF/AiQrxh8 kY/0vxtwtZpJbddFwdfIJu9eJLCMfUkCOqCKq0C+qkqYqyaLlY1409eRfLJOvsIkW61u 8xZ1v486wGaMirf4VdspKjOuJJgGg3ZC7EcVP2inu8O8SStQ0OQ8ooA9lIDXZnafDx83 sbsQ== MIME-Version: 1.0 X-Received: by 10.112.56.233 with SMTP id d9mr3189008lbq.55.1404417513332; Thu, 03 Jul 2014 12:58:33 -0700 (PDT) Received: by 10.112.253.198 with HTTP; Thu, 3 Jul 2014 12:58:33 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD991B6@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AD95D0F@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AD991B6@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Thu, 3 Jul 2014 15:58:33 -0400 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: multipart/alternative; boundary=001a1133aa1cffa3db04fd4f6e22 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_Gf6rHTBaRR_FSM8p8001oa30Fs Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five 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, 03 Jul 2014 19:58:37 -0000 --001a1133aa1cffa3db04fd4f6e22 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 3, 2014 at 3:38 PM, Mike Jones wrote: > I can add something along these lines. Does that work for you? > > > > *Privacy Considerations* > > A JWT may contain privacy-sensitive information. When this is the case, > measures must be taken to prevent disclosure of this information to > unintended parties. One way to achieve this is to use an encrypted JWT. > Another way is to ensure that JWTs containing unencrypted privacy-sensiti= ve > information are only transmitted over encrypted channels or protocols, su= ch > as TLS. > Great, thanks! > > > -- Mike > > > > *From:* Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > *Sent:* Thursday, July 03, 2014 11:32 AM > *To:* Mike Jones > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating > AD feedback on fifth spec of five > > > > Mike, > > > > Thanks for the updated JWT draft. I just read through it again and the > changes look good. > > > > I noticed that privacy considerations were not mentioned. Should there b= e > any discussed for claims, claim sets, etc.? This is bound to come up in > the IESG review if it is not addressed. Sorry I didn't catch that on the > first review. > > > > On Tue, Jul 1, 2014 at 9:11 PM, Mike Jones > wrote: > > > > > > *From:* Mike Jones > *Sent:* Tuesday, July 01, 2014 6:11 PM > *To:* jose@ietf.org > *Subject:* JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth > spec of five > > > > JOSE -30 and JWT -24 drafts have been posted incorporating improvements > resulting from Kathleen Moriarty=E2=80=99s JWE review. At this point, ac= tions > requested in her reviews of the JWS, JWE, JWK, JWA, and JWT specification= s > have all been incorporated. All changes in this release were strictly > editorial in nature. > > > > The specifications are available at: > > =C2=B7 http://tools.ietf.org/html/draft-ietf-jose-json-web-signat= ure-30 > > =C2=B7 > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-30 > > =C2=B7 http://tools.ietf.org/html/draft-ietf-jose-json-web-key-30 > > =C2=B7 > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-30 > > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-json-web-token= -24 > > > > HTML formatted versions are available at: > > =C2=B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-signature-30.html > > =C2=B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-30.html > > =C2=B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-key-30.html > > =C2=B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-30.html > > =C2=B7 > http://self-issued.info/docs/draft-ietf-oauth-json-web-token-24.html > > > > -- Mike > > > > P.S. This notice was also posted at http://self-issued.info/?p=3D1245 an= d > as @selfissued. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > > > Best regards, > > Kathleen > --=20 Best regards, Kathleen --001a1133aa1cffa3db04fd4f6e22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jul 3, 2014 at 3:38 PM, Mike Jones <Michael.Jone= s@microsoft.com> wrote:

I can add something along= these lines.=C2=A0 Does that work for you?

=C2=A0

Privacy Considerations

=C2=A0

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

=C2=A0

From: Kathleen= Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
Sent: Thursday, July 03, 2014 11:32 AM
To: Mike Jones
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporatin= g AD feedback on fifth spec of five

=C2=A0

Mike,

=C2=A0

Thanks for the updated JWT draft. =C2=A0I just read = through it again and the changes look good. =C2=A0

=C2=A0

I noticed that privacy considerations were not menti= oned. =C2=A0Should there be any discussed for claims, claim sets, etc.? =C2= =A0This is bound to come up in the IESG review if it is not addressed. =C2= =A0Sorry I didn't catch that on the first review.

=C2=A0<= /p>

On Tue, Jul 1, 2014 at 9:11 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

=C2=A0

=C2=A0

From: Mike Jon= es
Sent: Tuesday, July 01, 2014 6:11 PM
To: jose@ietf.org=
Subject: JOSE -30 and JWT -24 drafts incorporating AD feedback on fi= fth spec of five

=C2=A0

JOSE -30 and JWT -24 drafts have been posted incorpo= rating improvements resulting from Kathleen Moriarty=E2=80=99s JWE review.= =C2=A0 At this point, actions requested in her reviews of the JWS, JWE, JWK, JWA, and JWT specifications have all been incorporated.=C2=A0 Al= l changes in this release were strictly editorial in nature.<= /p>

=C2=A0

The specifications are available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-ietf-jose-json-= web-signature-30

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-ietf-jose-json= -web-encryption-30

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-ietf-jose-json-web-ke= y-30

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-ietf-jose-json= -web-algorithms-30

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-ietf-oauth-json-we= b-token-24

=C2=A0

HTML formatted versions are available at:<= /u>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-issued.info/docs/draft-ietf-j= ose-json-web-signature-30.html

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

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-issued.info/docs/draft-ietf-jose-js= on-web-key-30.html

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

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-issued.info/docs/draft-ietf-oaut= h-json-web-token-24.html

=C2=A0

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

=C2=A0

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


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



=C2=A0

--

=C2=A0

Best regards,

Kathleen




--

Best regards,
Kathleen
--001a1133aa1cffa3db04fd4f6e22-- From nobody Thu Jul 3 13:03:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E231B2B49 for ; Thu, 3 Jul 2014 13:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY6YBMVqxfyX for ; Thu, 3 Jul 2014 13:03:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD85C1B2B48 for ; Thu, 3 Jul 2014 13:03:21 -0700 (PDT) Received: from BN3PR0301CA0075.namprd03.prod.outlook.com (25.160.152.171) by BY1PR0301MB1173.namprd03.prod.outlook.com (25.160.195.144) with Microsoft SMTP Server (TLS) id 15.0.969.15; Thu, 3 Jul 2014 20:03:20 +0000 Received: from BL2FFO11FD011.protection.gbl (2a01:111:f400:7c09::130) by BN3PR0301CA0075.outlook.office365.com (2a01:111:e400:401e::43) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Thu, 3 Jul 2014 20:03:19 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Thu, 3 Jul 2014 20:03:19 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0195.002; Thu, 3 Jul 2014 20:03:09 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five Thread-Index: Ac+Vkn9Qxw7nsFWXQgqBEB8Y2w/8RgAAAcxwAFajBAAAANWvAAABhbNA Date: Thu, 3 Jul 2014 20:03:08 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD992F8@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AD95D0F@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD992F8TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(43784003)(51914003)(41574002)(377454003)(199002)(189002)(24454002)(52604005)(69234005)(21056001)(83072002)(87936001)(85852003)(84326002)(106466001)(19625215002)(26826002)(107046002)(76176999)(54356999)(81156004)(4396001)(86362001)(15975445006)(81342001)(15202345003)(77096002)(84676001)(95666004)(85306003)(512874002)(19300405004)(104016002)(69596002)(97736001)(66066001)(31966008)(80022001)(33656002)(83322001)(68736004)(71186001)(74662001)(50986999)(16236675004)(46102001)(19580405001)(44976005)(19580395003)(20776003)(2656002)(6806004)(55846006)(99396002)(76482001)(77982001)(64706001)(79102001)(86612001)(92726001)(74502001)(81542001)(110136001)(92566001)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BY1PR0301MB1173; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0261CCEEDF Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ucnjGB1UGZpioyBakcRIQzJ1VoI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five 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, 03 Jul 2014 20:03:25 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD992F8TK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVwbGllcyBpbmxpbmXigKYNCg0KRnJvbTogS2F0aGxlZW4gTW9yaWFydHkgW21haWx0bzprYXRo bGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDAzLCAy MDE0IDExOjU2IEFNDQpUbzogTWlrZSBKb25lcw0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBGVzogSk9TRSAtMzAgYW5kIEpXVCAtMjQgZHJhZnRzIGluY29ycG9y YXRpbmcgQUQgZmVlZGJhY2sgb24gZmlmdGggc3BlYyBvZiBmaXZlDQoNCkhlbGxvIQ0KDQpUaGFu ayB5b3UgZm9yIGFsbCBvZiB0aGUgdXBkYXRlcyB0byB0aGUgSk9TRSBkcmFmdHMgaW4gdGhlIGN1 cnJlbnQgYnVuZGxlIGluIHJldmlldy4gIEkgYXBwcmVjaWF0ZSBhbGwgb2YgdGhlIGVmZm9ydCB0 aGF0IHdlbnQgaW50byB0aGUgcmV2aXNpb25zISAgQXMgSSB1bmRlcnN0YW5kIGl0LCB0aGVyZSBh cmUgYSBmZXcgZ2VuZXJhbCBpc3N1ZXMgd2UgbmVlZCB0byB3b3JrIHRocm91Z2gsIHRoZW4gYSBm ZXcgbml0cy9yZXF1ZXN0cyBhcmUgaW5jbHVkZWQgb24gc3BlY2lmaWMgZHJhZnRzLg0KDQpLbm93 aW5nIGhvdyB3ZSBtb3ZlIGZvcndhcmQgb24gdGhlIGZvbGxvd2luZyBpdGVtcyB3aWxsIGJlIG5l Y2Vzc2FyeSBhcyB3ZWxsIGFzIHRoZSBzaGVwaGVyZC9jaGFpciBva2F5IHRvIHByb2dyZXNzIHRo ZSBkcmFmdHMgdG8gSUVURiBsYXN0IGNhbGwuICBBcyBhbiBGWUksIHNpbmNlIGl0IHdhcyByZXF1 ZXN0ZWQgdGhhdCB0aGUgZHJhZnRzIHByb2dyZXNzIGFzIGEgc2V0LCBJIG1heSBuZWVkIHRvIGRl bGF5IG9uIHdoaWNoIHRlbGVjaGF0IHRoZSBkcmFmdHMgZ2V0IHBsYWNlZC4gIEVzc2VudGlhbGx5 LCB0aGUgc2V0IHJlcXVpcmVzIGEgbG90IG9mIHJlYWRpbmcgYW5kIEknZCBsaWtlIHRvIGdpdmUg dGhlIElFU0cgZW5vdWdoIHRpbWUgdG8gZG8gcmV2aWV3cy4NCg0KMS4gTWNHcmV3IGRyYWZ0IChh cHBsaWVzIHRvIEpXQSkNCiAgIFdlIGFyZSB3YWl0aW5nIG9uIGFuIHVwZGF0ZWQgdmVyc2lvbiBz byB0aGF0IHRoZSBKV0EgZHJhZnQgY2FuIHJlZmVyIHRvIGl0IGFzIG9wcG9zZWQgdG8gZHVwbGlj YXRpbmcgdGV4dCBmcm9tIGl0Lg0KDQpNaWtlPiAgSeKAmWQgcHJvcG9zZWQgc3BlY2lmaWMgY2hh bmdlcyB0byB0aGUgYXV0aG9ycyBpbiBNYXkgYW5kIERhdmlkIE1jR3JldyBoYWQgdGVudGF0aXZl bHkgYWdyZWVkIHdpdGggdGhlbSBhbmQgc2FpZCB0aGF0IGhl4oCZZCBwcm9kdWNlIGFuIHVwZGF0 ZWQgZHJhZnQgYSBmZXcgd2Vla3MgYWdvLiAgVGhpcyBoYXNu4oCZdCBoYXBwZW5lZCB5ZXQuICBJ IHBsYW4gdG8gc3RheSBlbmdhZ2VkIHdpdGggdGhpcywgaW5jbHVkaW5nIHBvc3NpYmx5IHByb2R1 Y2luZyBhIGNhbmRpZGF0ZSBkcmFmdCB0byBwcm9wb3NlIHRvIHRoZSBhdXRob3JzLCBpZiBuZWNl c3NhcnkuICAoVGhpcyB3b27igJl0IGhhcHBlbiB1bnRpbCBzb21ldGltZSBiZXR3ZWVuIHRoZSA0 dGggYW5kIFRvcm9udG8uKQ0KDQoyLiBBbHRlcm5hdGUgb24gdGV4dCB0aGF0IGFwcGxpZXMgdG8g c2V2ZXJhbCBvZiB0aGUgZHJhZnRzIGZvciB0aGUgZm9sbG93aW5nOg0KICAgICAgICAgRGlzY3Vz c2lvbiBvbiB3b3JkaW5nIOKAnG9yIHVzZSBhIEpTT04gcGFyc2VyIHRoYXQgcmV0dXJucw0KICAg ICAgICAgb25seSB0aGUgbGV4aWNhbGx5IGxhc3QgZHVwbGljYXRlIG1lbWJlciBuYW1lLCBhcyBz cGVjaWZpZWQNCiAgICAgICAgIGluIFNlY3Rpb24gMTUuMTIgKFRoZSBKU09OIE9iamVjdCkgb2Yg RUNNQVNjcmlwdCA1LjEgW0VDTUFTY3JpcHRd4oCdLg0KDQpKaW0gb3Igb3RoZXJzIG1heSBoYXZl IHRleHQgc3VnZ2VzdGlvbnMuICBUaGlzIHdhcyBkaXNjdXNzZWQgb24gbGlzdCwgYnV0IGhhcyBu b3QgYmVlbiByZXNvbHZlZCB5ZXQuDQoNCk1pa2U+IEkgYmVsaWV2ZSB0aGF0IGl04oCZcyBhbHJl YWR5IHVuYW1iaWd1b3VzIGFzIHdvcmRlZCwgYnV0IHdvdWxkIGJlIG9wZW4gdG8gZXZlbiBjbGVh cmVyIHdvcmRpbmcsIGlmIHNvbWVvbmUgc3VwcGxpZXMgaXQuDQoNCjMuIFVzZSBjYXNlcyBub3Qg bWV0IGJ5IGN1cnJlbnQgc2V0IG9mIGRyYWZ0cw0KICAgICBEb2N1bWVudHMgZG8gbm90IG1lZXQg YWxsIG9mIHRoZSB1c2UgY2FzZXMgbGFpZCBvdXQgaW4gdGhlIFVzZSBDYXNlcyBkb2N1bWVudA0K ICAgICBTcGVjaWZpY2FsbHkgc2VjdGlvbiA1Ljggc2luY2UgdGhlcmUgaXMgbm8ga2V5IG1hbmFn ZW1lbnQgZm9yDQogICAgIE1BQ3MgKDUuOC4xLiDigJMgTUFDIGJhc2VkIG9uIEVDREgtZGVyaXZl ZCBrZXkpDQpJJ20gbm90IHN1cmUgaG93IHRoaXMgZ2V0cyBoYW5kbGVkLiAgSWYgaXQgd2lsbCBi ZSBhZGRyZXNzZWQgaW4gb3RoZXIgZHJhZnRzLCBsZXQgbWUga25vdy4NCg0KTWlrZT4gVGhpcyB3 YXMgaXNzdWUgIzIgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvam9zZS90cmFjL3RpY2tl dC8yIGFuZCB3YXMgZXh0ZW5zaXZlbHkgZGlzY3Vzc2VkLiAgQSBmb3JtYWwgY29uc2Vuc3VzIGNh bGwgb24gdGhpcyB3YXMgY29uZHVjdGVkIGJ5IHRoZSBjaGFpcnMgZXZlbiBwcmlvciB0byB0aGUg YXR0ZW1wdCB0byByZS1vcGVuIHRoZSBpc3N1ZSBieSBmaWxpbmcgaXNzdWUgIzIuICBKaW3igJlz IHJlc29sdXRpb24gY2xvc2luZyB0aGlzIHdhcyB3b250Zml4IHdhcyDigJxUaGUgd29ya2luZyBn cm91cCBoYXMgYWxyZWFkeSBjb25zaWRlcmVkIHRoaXMgYW5kIGhhcyBkZXRlcm1pbmVkIHRoYXQg aXQgd2lsbCBub3QgYmUgYWRkcmVzc2VkLiBVbnRpbCBhIHJlcXVlc3QgZm9yIHRoZSBmZWF0dXJl IGNvbWVzIGluIGZyb20gYSBncm91cCBzdWNoIGFzIHRoZSBXZWJDcnlwdG8/IGdyb3VwIGl0IHdp bGwgbm90IGJlIHJlLWNvbnNpZGVyZWQu4oCdLg0KDQpUaGF0IHNhaWQsIGl04oCZcyB3ZWxsIHVu ZGVyc3Rvb2QgaG93IHRoaXMgY291bGQgYmUgY2xlYW5seSBhZGRlZCBpbiBhIGJhY2t3YXJkcyBj b21wYXRpYmxlIHdheS4gIElmIGEgY29uY3JldGUgbmVlZCBmb3IgdGhpcyBhcmlzZXMsIEnigJlk IGJlIGdsYWQgdG8gd3JpdGUgdXAgYSBxdWljayBkcmFmdCwgYnV0IHNpbmNlIHRoaXMgaXMgc2Vw YXJhYmxlLCBJIGRvbuKAmXQgYmVsaWV2ZSB0aGF0IHRoZSBwb3NzaWJpbGl0eSBvZiBkb2luZyB0 aGlzIHdvcmsgaW4gdGhlIGZ1dHVyZSBuZWVkcyB0byBoYXZlIGFueSBpbXBhY3Qgb24gY29tcGxl dGluZyB0aGUgZHJhZnRzIHdlIGFscmVhZHkgaGF2ZSwgd2hpY2ggaW50ZW50aW9uYWxseSBhZGRy ZXNzIHRoZSBtb3N0IGNvbW1vbmx5IG9jY3VycmluZyB1c2UgY2FzZXMuDQoNCjQuICBJIGRvbid0 IHJlY2FsbCBzZWVpbmcgYW55IGludGVybmF0aW9uYWxpemF0aW9uIGNvbnNpZGVyYXRpb25zLCBp cyB0aGF0IHNvbWV0aGluZyB3ZSBuZWVkIHRvIHdvcnJ5IGFib3V0Pw0KDQpNaWtlPiAgTm9uZSBv ZiB0aGUgNSBkcmFmdHMgZGVmaW5lIGFueSBzdHJpbmdzIGludGVuZGVkIGZvciBjb25zdW1wdGlv biBieSBlbmQtdXNlcnMsIHNvIEkgZG9u4oCZdCB0aGluayBzby4gIE9yIGlmIHlvdSBwcmVmZXIs IEkgY291bGQgZXhwbGljaXRseSBzYXkgdGhhdCwgcGVyaGFwcyBqdXN0IGluIHRoZSBKV1QgZHJh ZnQ/ICBZb3VyIGNhbGzigKYNCg0KTml0cy9Db21tZW50cyBmb3Igc3BlY2lmaWMgZHJhZnRzOg0K DQpKV0E6DQpTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIDguMiBLZXkgTGlmZXRpbWVz DQpTaG91bGQgdGhlcmUgYmUgYSByZWZlcmVuY2UgdG8gTklTVCA4MDAtNTcgdG8gcHJvdmlkZSBn dWlkYW5jZSBvbiB0aGlzIHRvcGljLiAgSWYgdGhlcmUgaXMgYSBiZXR0ZXIgcmVmZXJlbmNlLCB0 aGF0J3MgZmluZSB0b28uICBUaGlzIGlzIHNvbWV0aGluZyB0aGF0IG1heSBnZXQgcGlja2VkIHVw IG9uIGluIG90aGVyIHJldmlld3MuDQoNCk1pa2U+IFdpbGwgZG8NCg0KVGhhbmtzIGZvciByZWR1 Y2luZyB0ZXh0IGJ5IHJlZmVycmluZyB0byBvdGhlciBkcmFmdHMgZm9yIGEgZ29vZCBwb3J0aW9u IG9mIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0KDQpKV1M6DQpGb3IgdHlw IGFuZCBjdHksIHRoZSB0ZXh0IGNvdWxkIGJlIG1vcmUgY2xlYXIgaW4gdGhlIGZpcnN0IHBhcmFn cmFwaCBzZW50ZW5jZSAyIGFuZCA0LiAgVGhleSByZWFkIGFzIGlmIHRoZXkgYXJlIGluIGNvbmZs aWN0LiAgIFRoZSBzcGVjaWZpYyB1c2FnZSBpcyBkaWZmZXJlbnQgaW4gdGhlc2Ugc2VudGVuY2Vz LCBidXQgdGhhdCBpcyBub3QgbWFkZSBjbGVhciBpbiB0aGUgdGV4dC4gIEl0IHNob3VsZCBqdXN0 IGJlIGEgdGV4dCBhZGp1c3RtZW50Lg0KDQpNaWtlPiAgV2lsbCBkbw0KDQpTZWN0aW9uIDg6IFRM UyByZXF1aXJlbWVudHMsIHNlY29uZCBwYXJhZ3JhcGg6DQpGb3IgdGhlIHNlY29uZCBzZW50ZW5j ZSwgY291bGQgeW91IGVpdGhlciBpbmNsdWRlIGV4YW1wbGVzIG9yIGEgcmVmZXJlbmNlIHRvIHdo ZXJlIHRoZSByZWFkZXIgY2FuIGFzY2VydGFpbiBhcHByb3ByaWF0ZSBhcHByb3ByaWF0ZSBjaXBo ZXIgc3VpdGVzPyAgVGhpcyBtYXkgYmUgdG91Z2ggdG8gYWRkcmVzcywgYnV0IHRoZSB3YXkgdGhl IHNlbnRlbmNlIGlzIHdyaXR0ZW4sIGl0IHNvdW5kcyBsaWtlIGEgcmVmZXJlbmNlIG9yIGEgcmVj b21tZW5kYXRpb24gaXMgbmVlZGVkLiAgQW55IGlkZWFzPw0KDQpNaWtlPiAgSeKAmWQgYXBwcmVj aWF0ZSBhIHNwZWNpZmljIHJlZmVyZW5jZS4gIEkgYXNrZWQgdGhlIFRMUyBjaGFpcnMgZm9yIG9u ZSB5ZXN0ZXJkYXksIGJ1dCBoYXZlbuKAmXQgaGVhcmQgYmFjayBmcm9tIHRoZW0geWV0Lg0KDQpK V0s6DQpVcGRhdGVzIGxvb2sgZ29vZCwgdGhhbmtzIQ0KDQpKV0U6DQpVcGRhdGVzIGxvb2sgZ29v ZCwgdGhhbmsgeW91IQ0KDQpPYXV0aCBKV1Q6IFNlbnQgdG8gT2F1dGggbGlzdA0KDQpNaWtlPiBU aGFua3MgYWdhaW4gZm9yIHRoZSB0aG9yb3VnaCBhbmQgdXNlZnVsIHJldmlld3MsIEthdGhsZWVu 4oCmDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLSBNaWtlDQoNCk9uIFRodSwgSnVsIDMsIDIwMTQgYXQgMjozMSBQTSwg S2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPG1haWx0 bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KTWlrZSwNCg0KVGhh bmtzIGZvciB0aGUgdXBkYXRlZCBKV1QgZHJhZnQuICBJIGp1c3QgcmVhZCB0aHJvdWdoIGl0IGFn YWluIGFuZCB0aGUgY2hhbmdlcyBsb29rIGdvb2QuDQoNCkkgbm90aWNlZCB0aGF0IHByaXZhY3kg Y29uc2lkZXJhdGlvbnMgd2VyZSBub3QgbWVudGlvbmVkLiAgU2hvdWxkIHRoZXJlIGJlIGFueSBk aXNjdXNzZWQgZm9yIGNsYWltcywgY2xhaW0gc2V0cywgZXRjLj8gIFRoaXMgaXMgYm91bmQgdG8g Y29tZSB1cCBpbiB0aGUgSUVTRyByZXZpZXcgaWYgaXQgaXMgbm90IGFkZHJlc3NlZC4gIFNvcnJ5 IEkgZGlkbid0IGNhdGNoIHRoYXQgb24gdGhlIGZpcnN0IHJldmlldy4NCg0KT24gVHVlLCBKdWwg MSwgMjAxNCBhdCA5OjExIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQoNCkZyb206 IE1pa2UgSm9uZXMNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDEsIDIwMTQgNjoxMSBQTQ0KVG86IGpv c2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBKT1NFIC0zMCBhbmQg SldUIC0yNCBkcmFmdHMgaW5jb3Jwb3JhdGluZyBBRCBmZWVkYmFjayBvbiBmaWZ0aCBzcGVjIG9m IGZpdmUNCg0KSk9TRSAtMzAgYW5kIEpXVCAtMjQgZHJhZnRzIGhhdmUgYmVlbiBwb3N0ZWQgaW5j b3Jwb3JhdGluZyBpbXByb3ZlbWVudHMgcmVzdWx0aW5nIGZyb20gS2F0aGxlZW4gTW9yaWFydHni gJlzIEpXRSByZXZpZXcuICBBdCB0aGlzIHBvaW50LCBhY3Rpb25zIHJlcXVlc3RlZCBpbiBoZXIg cmV2aWV3cyBvZiB0aGUgSldTLCBKV0UsIEpXSywgSldBLCBhbmQgSldUIHNwZWNpZmljYXRpb25z IGhhdmUgYWxsIGJlZW4gaW5jb3Jwb3JhdGVkLiAgQWxsIGNoYW5nZXMgaW4gdGhpcyByZWxlYXNl IHdlcmUgc3RyaWN0bHkgZWRpdG9yaWFsIGluIG5hdHVyZS4NCg0KVGhlIHNwZWNpZmljYXRpb25z IGFyZSBhdmFpbGFibGUgYXQ6DQoNCuKAoiAgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtMzANCg0K4oCiICAgICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWVuY3J5 cHRpb24tMzANCg0K4oCiICAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1qb3NlLWpzb24td2ViLWtleS0zMA0KDQrigKIgICAgICAgICBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0zMA0KDQrigKIg ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWpzb24t d2ViLXRva2VuLTI0DQoNCkhUTUwgZm9ybWF0dGVkIHZlcnNpb25zIGFyZSBhdmFpbGFibGUgYXQ6 DQoNCuKAoiAgICAgICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1q b3NlLWpzb24td2ViLXNpZ25hdHVyZS0zMC5odG1sDQoNCuKAoiAgICAgICAgIGh0dHA6Ly9zZWxm LWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWVuY3J5cHRpb24tMzAu aHRtbA0KDQrigKIgICAgICAgICBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWll dGYtam9zZS1qc29uLXdlYi1rZXktMzAuaHRtbA0KDQrigKIgICAgICAgICBodHRwOi8vc2VsZi1p c3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTMwLmh0 bWwNCg0K4oCiICAgICAgICAgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRm LW9hdXRoLWpzb24td2ViLXRva2VuLTI0Lmh0bWwNCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpQLlMuICBUaGlz IG5vdGljZSB3YXMgYWxzbyBwb3N0ZWQgYXQgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTI0 NSBhbmQgYXMgQHNlbGZpc3N1ZWQuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg0KDQoNCi0tDQoNCkJlc3QgcmVnYXJkcywNCkthdGhsZWVuDQoNCg0KDQotLQ0KDQpC ZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0K --_000_4E1F6AAD24975D4BA5B16804296739439AD992F8TK5EX14MBXC294r_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpo b2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcw QzAiPlJlcGxpZXMgaW5saW5l4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZA Z21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDAzLCAyMDE0IDEx OjU2IEFNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBGVzogSk9TRSAtMzAg YW5kIEpXVCAtMjQgZHJhZnRzIGluY29ycG9yYXRpbmcgQUQgZmVlZGJhY2sgb24gZmlmdGggc3Bl YyBvZiBmaXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhl bGxvITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFuayB5b3UgZm9yIGFsbCBvZiB0aGUgdXBkYXRlcyB0byB0aGUgSk9TRSBkcmFmdHMgaW4g dGhlIGN1cnJlbnQgYnVuZGxlIGluIHJldmlldy4gJm5ic3A7SSBhcHByZWNpYXRlIGFsbCBvZiB0 aGUgZWZmb3J0IHRoYXQgd2VudCBpbnRvIHRoZSByZXZpc2lvbnMhICZuYnNwO0FzIEkgdW5kZXJz dGFuZCBpdCwgdGhlcmUgYXJlIGEgZmV3IGdlbmVyYWwgaXNzdWVzIHdlIG5lZWQgdG8gd29yayB0 aHJvdWdoLCB0aGVuIGEgZmV3IG5pdHMvcmVxdWVzdHMNCiBhcmUgaW5jbHVkZWQgb24gc3BlY2lm aWMgZHJhZnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Lbm93aW5nIGhvdyB3ZSBtb3ZlIGZvcndhcmQgb24gdGhlIGZvbGxvd2luZyBpdGVt cyB3aWxsIGJlIG5lY2Vzc2FyeSBhcyB3ZWxsIGFzIHRoZSBzaGVwaGVyZC9jaGFpciBva2F5IHRv IHByb2dyZXNzIHRoZSBkcmFmdHMgdG8gSUVURiBsYXN0IGNhbGwuICZuYnNwO0FzIGFuIEZZSSwg c2luY2UgaXQgd2FzIHJlcXVlc3RlZCB0aGF0IHRoZSBkcmFmdHMgcHJvZ3Jlc3MgYXMgYSBzZXQs IEkgbWF5IG5lZWQgdG8gZGVsYXkNCiBvbiB3aGljaCB0ZWxlY2hhdCB0aGUgZHJhZnRzIGdldCBw bGFjZWQuICZuYnNwO0Vzc2VudGlhbGx5LCB0aGUgc2V0IHJlcXVpcmVzIGEgbG90IG9mIHJlYWRp bmcgYW5kIEknZCBsaWtlIHRvIGdpdmUgdGhlIElFU0cgZW5vdWdoIHRpbWUgdG8gZG8gcmV2aWV3 cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ MS4gTWNHcmV3IGRyYWZ0IChhcHBsaWVzIHRvIEpXQSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtXZSBhcmUgd2FpdGluZyBv biBhbiB1cGRhdGVkIHZlcnNpb24gc28gdGhhdCB0aGUgSldBIGRyYWZ0IGNhbiByZWZlciB0byBp dCBhcyBvcHBvc2VkIHRvIGR1cGxpY2F0aW5nIHRleHQgZnJvbSBpdC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+TWlrZSZndDsmbmJz cDsgSeKAmWQgcHJvcG9zZWQgc3BlY2lmaWMgY2hhbmdlcyB0byB0aGUgYXV0aG9ycyBpbiBNYXkg YW5kIERhdmlkIE1jR3JldyBoYWQgdGVudGF0aXZlbHkgYWdyZWVkIHdpdGggdGhlbSBhbmQgc2Fp ZCB0aGF0IGhl4oCZZCBwcm9kdWNlIGFuIHVwZGF0ZWQgZHJhZnQgYSBmZXcNCiB3ZWVrcyBhZ28u Jm5ic3A7IFRoaXMgaGFzbuKAmXQgaGFwcGVuZWQgeWV0LiZuYnNwOyBJIHBsYW4gdG8gc3RheSBl bmdhZ2VkIHdpdGggdGhpcywgaW5jbHVkaW5nIHBvc3NpYmx5IHByb2R1Y2luZyBhIGNhbmRpZGF0 ZSBkcmFmdCB0byBwcm9wb3NlIHRvIHRoZSBhdXRob3JzLCBpZiBuZWNlc3NhcnkuJm5ic3A7IChU aGlzIHdvbuKAmXQgaGFwcGVuIHVudGlsIHNvbWV0aW1lIGJldHdlZW4gdGhlIDQ8c3VwPnRoPC9z dXA+IGFuZCBUb3JvbnRvLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Mi4gQWx0ZXJuYXRlIG9uIHRleHQgdGhhdCBhcHBsaWVzIHRvIHNldmVyYWwgb2YgdGhlIGRyYWZ0 cyBmb3IgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtEaXNjdXNz aW9uIG9uIHdvcmRpbmcg4oCcb3IgdXNlIGEgSlNPTiBwYXJzZXIgdGhhdCByZXR1cm5zPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b25seSB0aGUgbGV4aWNhbGx5IGxhc3QgZHVwbGljYXRl IG1lbWJlciBuYW1lLCBhcyBzcGVjaWZpZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtp biBTZWN0aW9uIDE1LjEyIChUaGUgSlNPTiBPYmplY3QpIG9mIEVDTUFTY3JpcHQgNS4xIFtFQ01B U2NyaXB0XeKAnS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SmltIG9yIG90aGVycyBtYXkgaGF2ZSB0ZXh0IHN1Z2dlc3Rpb25zLiAm bmJzcDtUaGlzIHdhcyBkaXNjdXNzZWQgb24gbGlzdCwgYnV0IGhhcyBub3QgYmVlbiByZXNvbHZl ZCB5ZXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMDcwQzAiPk1pa2UmZ3Q7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMDcwQzAiPkkgYmVsaWV2ZSB0aGF0IGl04oCZcyBhbHJlYWR5IHVuYW1iaWd1b3VzIGFz IHdvcmRlZCwgYnV0IHdvdWxkIGJlIG9wZW4gdG8gZXZlbiBjbGVhcmVyIHdvcmRpbmcsIGlmIHNv bWVvbmUgc3VwcGxpZXMgaXQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMDA3MEMwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gVXNl IGNhc2VzIG5vdCBtZXQgYnkgY3VycmVudCBzZXQgb2YgZHJhZnRzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO0Rv Y3VtZW50cyBkbyBub3QgbWVldCBhbGwgb2YgdGhlIHVzZSBjYXNlcyBsYWlkIG91dCBpbiB0aGUg VXNlIENhc2VzIGRvY3VtZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO1NwZWNpZmljYWxseSBzZWN0aW9uIDUu OCBzaW5jZSB0aGVyZSBpcyBubyBrZXkgbWFuYWdlbWVudCBmb3ImbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5i c3A7TUFDcyAoNS44LjEuIOKAkyBNQUMgYmFzZWQgb24gRUNESC1kZXJpdmVkIGtleSk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3Qgc3Vy ZSBob3cgdGhpcyBnZXRzIGhhbmRsZWQuICZuYnNwO0lmIGl0IHdpbGwgYmUgYWRkcmVzc2VkIGlu IG90aGVyIGRyYWZ0cywgbGV0IG1lIGtub3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPk1pa2UmZ3Q7IFRoaXMgd2FzIGlzc3VlICMy DQo8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9qb3NlL3RyYWMvdGlja2V0 LzIiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNrZXQvMjwvYT4g YW5kIHdhcyBleHRlbnNpdmVseSBkaXNjdXNzZWQuJm5ic3A7IEEgZm9ybWFsIGNvbnNlbnN1cyBj YWxsIG9uIHRoaXMgd2FzIGNvbmR1Y3RlZCBieSB0aGUgY2hhaXJzIGV2ZW4gcHJpb3IgdG8gdGhl IGF0dGVtcHQgdG8gcmUtb3BlbiB0aGUgaXNzdWUgYnkgZmlsaW5nDQogaXNzdWUgIzIuJm5ic3A7 IEppbeKAmXMgcmVzb2x1dGlvbiBjbG9zaW5nIHRoaXMgd2FzIHdvbnRmaXggd2FzIOKAnDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+VGhlIHdvcmtpbmcg Z3JvdXAgaGFzIGFscmVhZHkgY29uc2lkZXJlZCB0aGlzIGFuZCBoYXMgZGV0ZXJtaW5lZCB0aGF0 IGl0IHdpbGwgbm90IGJlIGFkZHJlc3NlZC4gVW50aWwgYSByZXF1ZXN0IGZvciB0aGUgZmVhdHVy ZSBjb21lcyBpbiBmcm9tIGEgZ3JvdXANCiBzdWNoIGFzIHRoZSBXZWJDcnlwdG8/IGdyb3VwIGl0 IHdpbGwgbm90IGJlIHJlLWNvbnNpZGVyZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDA3MEMwIj7igJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5UaGF0IHNhaWQsIGl04oCZcyB3ZWxs IHVuZGVyc3Rvb2QgaG93IHRoaXMgY291bGQgYmUgY2xlYW5seSBhZGRlZCBpbiBhIGJhY2t3YXJk cyBjb21wYXRpYmxlIHdheS4mbmJzcDsgSWYgYSBjb25jcmV0ZSBuZWVkIGZvciB0aGlzIGFyaXNl cywgSeKAmWQgYmUgZ2xhZCB0byB3cml0ZSB1cA0KIGEgcXVpY2sgZHJhZnQsIGJ1dCBzaW5jZSB0 aGlzIGlzIHNlcGFyYWJsZSwgSSBkb27igJl0IGJlbGlldmUgdGhhdCB0aGUgcG9zc2liaWxpdHkg b2YgZG9pbmcgdGhpcyB3b3JrIGluIHRoZSBmdXR1cmUgbmVlZHMgdG8gaGF2ZSBhbnkgaW1wYWN0 IG9uIGNvbXBsZXRpbmcgdGhlIGRyYWZ0cyB3ZSBhbHJlYWR5IGhhdmUsIHdoaWNoIGludGVudGlv bmFsbHkgYWRkcmVzcyB0aGUgbW9zdCBjb21tb25seSBvY2N1cnJpbmcgdXNlIGNhc2VzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LiAmbmJzcDtJIGRvbid0IHJlY2Fs bCBzZWVpbmcgYW55IGludGVybmF0aW9uYWxpemF0aW9uIGNvbnNpZGVyYXRpb25zLCBpcyB0aGF0 IHNvbWV0aGluZyB3ZSBuZWVkIHRvIHdvcnJ5IGFib3V0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzAwNzBDMCI+TWlrZSZndDsmbmJzcDsgTm9uZSBvZiB0aGUgNSBkcmFmdHMgZGVm aW5lIGFueSBzdHJpbmdzIGludGVuZGVkIGZvciBjb25zdW1wdGlvbiBieSBlbmQtdXNlcnMsIHNv IEkgZG9u4oCZdCB0aGluayBzby4mbmJzcDsgT3IgaWYgeW91IHByZWZlciwgSSBjb3VsZCBleHBs aWNpdGx5IHNheSB0aGF0LCBwZXJoYXBzDQoganVzdCBpbiB0aGUgSldUIGRyYWZ0PyZuYnNwOyBZ b3VyIGNhbGzigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tml0cy9D b21tZW50cyBmb3Igc3BlY2lmaWMgZHJhZnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KV0E6Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN1cml0eSBjb25zaWRlcmF0aW9ucyBz ZWN0aW9uIDguMiBLZXkgTGlmZXRpbWVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG91bGQgdGhlcmUgYmUgYSByZWZlcmVuY2UgdG8gTklTVCA4 MDAtNTcgdG8gcHJvdmlkZSBndWlkYW5jZSBvbiB0aGlzIHRvcGljLiAmbmJzcDtJZiB0aGVyZSBp cyBhIGJldHRlciByZWZlcmVuY2UsIHRoYXQncyBmaW5lIHRvby4gJm5ic3A7VGhpcyBpcyBzb21l dGhpbmcgdGhhdCBtYXkgZ2V0IHBpY2tlZCB1cCBvbiBpbiBvdGhlciByZXZpZXdzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5NaWtl Jmd0OyBXaWxsIGRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r cyBmb3IgcmVkdWNpbmcgdGV4dCBieSByZWZlcnJpbmcgdG8gb3RoZXIgZHJhZnRzIGZvciBhIGdv b2QgcG9ydGlvbiBvZiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SldTOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHR5cCBh bmQgY3R5LCB0aGUgdGV4dCBjb3VsZCBiZSBtb3JlIGNsZWFyIGluIHRoZSBmaXJzdCBwYXJhZ3Jh cGggc2VudGVuY2UgMiBhbmQgNC4gJm5ic3A7VGhleSByZWFkIGFzIGlmIHRoZXkgYXJlIGluIGNv bmZsaWN0LiAmbmJzcDsgVGhlIHNwZWNpZmljIHVzYWdlIGlzIGRpZmZlcmVudCBpbiB0aGVzZSBz ZW50ZW5jZXMsIGJ1dCB0aGF0IGlzIG5vdCBtYWRlIGNsZWFyIGluIHRoZSB0ZXh0LiAmbmJzcDtJ dCBzaG91bGQganVzdA0KIGJlIGEgdGV4dCBhZGp1c3RtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5NaWtlJmd0OyZuYnNwOyBX aWxsIGRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gODog VExTIHJlcXVpcmVtZW50cywgc2Vjb25kIHBhcmFncmFwaDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciB0aGUgc2Vjb25kIHNlbnRlbmNlLCBj b3VsZCB5b3UgZWl0aGVyIGluY2x1ZGUgZXhhbXBsZXMgb3IgYSByZWZlcmVuY2UgdG8gd2hlcmUg dGhlIHJlYWRlciBjYW4gYXNjZXJ0YWluIGFwcHJvcHJpYXRlIGFwcHJvcHJpYXRlIGNpcGhlciBz dWl0ZXM/ICZuYnNwO1RoaXMgbWF5IGJlIHRvdWdoIHRvIGFkZHJlc3MsIGJ1dCB0aGUgd2F5IHRo ZSBzZW50ZW5jZSBpcyB3cml0dGVuLCBpdCBzb3VuZHMgbGlrZSBhIHJlZmVyZW5jZQ0KIG9yIGEg cmVjb21tZW5kYXRpb24gaXMgbmVlZGVkLiAmbmJzcDtBbnkgaWRlYXM/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPk1pa2UmZ3Q7Jm5i c3A7IEnigJlkIGFwcHJlY2lhdGUgYSBzcGVjaWZpYyByZWZlcmVuY2UuJm5ic3A7IEkgYXNrZWQg dGhlIFRMUyBjaGFpcnMgZm9yIG9uZSB5ZXN0ZXJkYXksIGJ1dCBoYXZlbuKAmXQgaGVhcmQgYmFj ayBmcm9tIHRoZW0geWV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5K V0s6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5V cGRhdGVzIGxvb2sgZ29vZCwgdGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KV0U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VcGRhdGVzIGxvb2sgZ29vZCwgdGhhbmsgeW91ITxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PYXV0aCBK V1Q6IFNlbnQgdG8gT2F1dGggbGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5NaWtlJmd0OyBUaGFua3MgYWdhaW4gZm9yIHRoZSB0 aG9yb3VnaCBhbmQgdXNlZnVsIHJldmlld3MsIEthdGhsZWVu4oCmPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwg SnVsIDMsIDIwMTQgYXQgMjozMSBQTSwgS2F0aGxlZW4gTW9yaWFydHkgJmx0OzxhIGhyZWY9Im1h aWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmth dGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlrZSw8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIHVwZGF0ZWQgSldUIGRy YWZ0LiAmbmJzcDtJIGp1c3QgcmVhZCB0aHJvdWdoIGl0IGFnYWluIGFuZCB0aGUgY2hhbmdlcyBs b29rIGdvb2QuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIG5vdGljZWQgdGhhdCBwcml2YWN5IGNvbnNpZGVyYXRpb25zIHdlcmUg bm90IG1lbnRpb25lZC4gJm5ic3A7U2hvdWxkIHRoZXJlIGJlIGFueSBkaXNjdXNzZWQgZm9yIGNs YWltcywgY2xhaW0gc2V0cywgZXRjLj8gJm5ic3A7VGhpcyBpcyBib3VuZCB0byBjb21lIHVwIGlu IHRoZSBJRVNHIHJldmlldyBpZiBpdCBpcyBub3QgYWRkcmVzc2VkLiAmbmJzcDtTb3JyeSBJIGRp ZG4ndCBjYXRjaCB0aGF0IG9uIHRoZSBmaXJzdCByZXZpZXcuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1bCAxLCAyMDE0IGF0IDk6MTEgUE0sIE1pa2Ug Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRh cmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNaWtlIEpvbmVzDQo8YnI+DQo8Yj5TZW50OjwvYj4g VHVlc2RheSwgSnVseSAwMSwgMjAxNCA2OjExIFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJt YWlsdG86am9zZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpvc2VAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IEpPU0UgLTMwIGFuZCBKV1QgLTI0IGRyYWZ0cyBpbmNvcnBvcmF0 aW5nIEFEIGZlZWRiYWNrIG9uIGZpZnRoIHNwZWMgb2YgZml2ZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkpPU0UgLTMwIGFu ZCBKV1QgLTI0IGRyYWZ0cyBoYXZlIGJlZW4gcG9zdGVkIGluY29ycG9yYXRpbmcgaW1wcm92ZW1l bnRzIHJlc3VsdGluZyBmcm9tIEthdGhsZWVuIE1vcmlhcnR54oCZcyBKV0UgcmV2aWV3LiZuYnNw OyBBdCB0aGlzIHBvaW50LCBhY3Rpb25zIHJlcXVlc3RlZCBpbiBoZXIgcmV2aWV3cyBvZiB0aGUg SldTLA0KIEpXRSwgSldLLCBKV0EsIGFuZCBKV1Qgc3BlY2lmaWNhdGlvbnMgaGF2ZSBhbGwgYmVl biBpbmNvcnBvcmF0ZWQuJm5ic3A7IEFsbCBjaGFuZ2VzIGluIHRoaXMgcmVsZWFzZSB3ZXJlIHN0 cmljdGx5IGVkaXRvcmlhbCBpbiBuYXR1cmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGUgc3BlY2lmaWNhdGlvbnMgYXJlIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtMzAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTMwPC9h PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWVuY3J5cHRpb24tMzAiIHRh cmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2Ut anNvbi13ZWItZW5jcnlwdGlvbi0zMDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1q c29uLXdlYi1rZXktMzAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTMwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtMzAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0z MDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wi PsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjQiIHRh cmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo LWpzb24td2ViLXRva2VuLTI0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SFRNTCBm b3JtYXR0ZWQgdmVyc2lvbnMgYXJlIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQt aWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0zMC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0 dXJlLTMwLmh0bWw8L2E+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVm PSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1l bmNyeXB0aW9uLTMwLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5m by9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTMwLmh0bWw8L2E+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1 ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMzAuaHRtbCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1qb3NlLWpz b24td2ViLWtleS0zMC5odG1sPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItYWxnb3JpdGhtcy0zMC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NlbGYtaXNz dWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0zMC5odG1s PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+ wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Nl bGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI0Lmh0 bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWll dGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjQuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Q LlMuJm5ic3A7IFRoaXMgbm90aWNlIHdhcyBhbHNvIHBvc3RlZCBhdA0KPGEgaHJlZj0iaHR0cDov L3NlbGYtaXNzdWVkLmluZm8vP3A9MTI0NSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zZWxmLWlz c3VlZC5pbmZvLz9wPTEyNDU8L2E+IGFuZCBhcyBAc2VsZmlzc3VlZC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyIGNsZWFy PSJhbGwiPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImhvZW56YiI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPi0tIDwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPkJlc3QgcmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+S2F0aGxlZW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0 IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5LYXRobGVlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439AD992F8TK5EX14MBXC294r_-- From nobody Thu Jul 3 13:15:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D4A1B2A4B for ; Thu, 3 Jul 2014 13:15:20 -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 9jOvZZCr56RY for ; Thu, 3 Jul 2014 13:15:17 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6A21B2832 for ; Thu, 3 Jul 2014 13:15:16 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so547175lbj.31 for ; Thu, 03 Jul 2014 13:15:15 -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=zFRSauPaZxA4sbARvlTYE/Ax+5unxVhcrsw+kzvEMWw=; b=kjDhw66raVtJpnOGRe/f+1A1Sgm+IRiVJIbXnbv8qqcvRKcIEeQ2EVCHreJsoGjzVv KxOTAhedeTcvN1umCRbfTrboE8bhAv41bXZz7l2SkcFJbEdIVn6wlPpcX7/2k1JFen0l LDR5Jp7eCdp+rC7FZCeyCr9UiZKh8I4kVQh6E0elbThUVgEcMavMnrBFrebVT9qzKbdi Bjyi0Cmr2VfIqU0PasvGgLj8aTf3JXMV/8EXxJo4WlFDmxHixns2UR/zmZBEWx98GdfR f875lJCseiYnqc1QuVKIydSjm5NT06SP02SMMKItMdN8btneT+kia3CDuyqhWg5WAjui P+Vw== MIME-Version: 1.0 X-Received: by 10.152.28.136 with SMTP id b8mr4992628lah.22.1404418515272; Thu, 03 Jul 2014 13:15:15 -0700 (PDT) Received: by 10.112.253.198 with HTTP; Thu, 3 Jul 2014 13:15:15 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AD992F8@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AD95D0F@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AD992F8@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Thu, 3 Jul 2014 16:15:15 -0400 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: multipart/alternative; boundary=089e0160b7d2b8084904fd4faac7 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ApejE_yH5pH7OuDwduMr8tOpqxA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five 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, 03 Jul 2014 20:15:21 -0000 --089e0160b7d2b8084904fd4faac7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Mike! In-line... On Thu, Jul 3, 2014 at 4:03 PM, Mike Jones wrote: > Replies inline=E2=80=A6 > > > > *From:* Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > *Sent:* Thursday, July 03, 2014 11:56 AM > > *To:* Mike Jones > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating > AD feedback on fifth spec of five > > > > Hello! > > > > Thank you for all of the updates to the JOSE drafts in the current bundle > in review. I appreciate all of the effort that went into the revisions! > As I understand it, there are a few general issues we need to work > through, then a few nits/requests are included on specific drafts. > > > > Knowing how we move forward on the following items will be necessary as > well as the shepherd/chair okay to progress the drafts to IETF last call. > As an FYI, since it was requested that the drafts progress as a set, I m= ay > need to delay on which telechat the drafts get placed. Essentially, the > set requires a lot of reading and I'd like to give the IESG enough time t= o > do reviews. > > > > 1. McGrew draft (applies to JWA) > > We are waiting on an updated version so that the JWA draft can refer t= o > it as opposed to duplicating text from it. > > > > Mike> I=E2=80=99d proposed specific changes to the authors in May and Da= vid > McGrew had tentatively agreed with them and said that he=E2=80=99d produc= e an > updated draft a few weeks ago. This hasn=E2=80=99t happened yet. I plan= to stay > engaged with this, including possibly producing a candidate draft to > propose to the authors, if necessary. (This won=E2=80=99t happen until s= ometime > between the 4th and Toronto.) > OK, thanks for the status. > > > 2. Alternate on text that applies to several of the drafts for the > following: > > Discussion on wording =E2=80=9Cor use a JSON parser that returns > > only the lexically last duplicate member name, as specified > > in Section 15.12 (The JSON Object) of ECMAScript 5.1 > [ECMAScript]=E2=80=9D. > > > > Jim or others may have text suggestions. This was discussed on list, but > has not been resolved yet. > > > > Mike> I believe that it=E2=80=99s already unambiguous as worded, but woul= d be > open to even clearer wording, if someone supplies it. > OK, let's see if there are proposals or if Jim has a suggestion. > > > 3. Use cases not met by current set of drafts > > Documents do not meet all of the use cases laid out in the Use Cases > document > > Specifically section 5.8 since there is no key management for > > MACs (5.8.1. =E2=80=93 MAC based on ECDH-derived key) > > I'm not sure how this gets handled. If it will be addressed in other > drafts, let me know. > > > > Mike> This was issue #2 http://trac.tools.ietf.org/wg/jose/trac/ticket/2 > and was extensively discussed. A formal consensus call on this was > conducted by the chairs even prior to the attempt to re-open the issue by > filing issue #2. Jim=E2=80=99s resolution closing this was wontfix was = =E2=80=9CThe > working group has already considered this and has determined that it will > not be addressed. Until a request for the feature comes in from a group > such as the WebCrypto? group it will not be re-considered.=E2=80=9D. > > > > That said, it=E2=80=99s well understood how this could be cleanly added i= n a > backwards compatible way. If a concrete need for this arises, I=E2=80=99= d be glad > to write up a quick draft, but since this is separable, I don=E2=80=99t b= elieve > that the possibility of doing this work in the future needs to have any > impact on completing the drafts we already have, which intentionally > address the most commonly occurring use cases. > OK, thank you. > > > 4. I don't recall seeing any internationalization considerations, is tha= t > something we need to worry about? > > > > Mike> None of the 5 drafts define any strings intended for consumption b= y > end-users, so I don=E2=80=99t think so. Or if you prefer, I could explic= itly say > that, perhaps just in the JWT draft? Your call=E2=80=A6 > No need then, if it comes up, I have an answer and that should be all I need on this one. Thanks. > > > Nits/Comments for specific drafts: > > > > JWA: > > Security considerations section 8.2 Key Lifetimes > > Should there be a reference to NIST 800-57 to provide guidance on this > topic. If there is a better reference, that's fine too. This is somethi= ng > that may get picked up on in other reviews. > > > > Mike> Will do > Thank you > > > Thanks for reducing text by referring to other drafts for a good portion > of the security considerations section. > > > > JWS: > > For typ and cty, the text could be more clear in the first paragraph > sentence 2 and 4. They read as if they are in conflict. The specific > usage is different in these sentences, but that is not made clear in the > text. It should just be a text adjustment. > > > > Mike> Will do > Thank you > > > Section 8: TLS requirements, second paragraph: > > For the second sentence, could you either include examples or a reference > to where the reader can ascertain appropriate appropriate cipher suites? > This may be tough to address, but the way the sentence is written, it > sounds like a reference or a recommendation is needed. Any ideas? > > > > Mike> I=E2=80=99d appreciate a specific reference. I asked the TLS chai= rs for > one yesterday, but haven=E2=80=99t heard back from them yet. > OK, thanks. > > > JWK: > > Updates look good, thanks! > > > > JWE: > > Updates look good, thank you! > > > > Oauth JWT: Sent to Oauth list > > > > Mike> Thanks again for the thorough and useful reviews, Kathleen=E2=80=A6 > > > You're welcome and thanks for the quick responses! Kathleen > -- Mike > > > > On Thu, Jul 3, 2014 at 2:31 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > Mike, > > > > Thanks for the updated JWT draft. I just read through it again and the > changes look good. > > > > I noticed that privacy considerations were not mentioned. Should there b= e > any discussed for claims, claim sets, etc.? This is bound to come up in > the IESG review if it is not addressed. Sorry I didn't catch that on the > first review. > > > > On Tue, Jul 1, 2014 at 9:11 PM, Mike Jones > wrote: > > > > > > *From:* Mike Jones > *Sent:* Tuesday, July 01, 2014 6:11 PM > *To:* jose@ietf.org > *Subject:* JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth > spec of five > > > > JOSE -30 and JWT -24 drafts have been posted incorporating improvements > resulting from Kathleen Moriarty=E2=80=99s JWE review. At this point, ac= tions > requested in her reviews of the JWS, JWE, JWK, JWA, and JWT specification= s > have all been incorporated. All changes in this release were strictly > editorial in nature. > > > > The specifications are available at: > > =C2=B7 http://tools.ietf.org/html/draft-ietf-jose-json-web-signat= ure-30 > > =C2=B7 > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-30 > > =C2=B7 http://tools.ietf.org/html/draft-ietf-jose-json-web-key-30 > > =C2=B7 > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-30 > > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-json-web-token= -24 > > > > HTML formatted versions are available at: > > =C2=B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-signature-30.html > > =C2=B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-30.html > > =C2=B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-key-30.html > > =C2=B7 > http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-30.html > > =C2=B7 > http://self-issued.info/docs/draft-ietf-oauth-json-web-token-24.html > > > > -- Mike > > > > P.S. This notice was also posted at http://self-issued.info/?p=3D1245 an= d > as @selfissued. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > > > Best regards, > > Kathleen > > > > > > -- > > > > Best regards, > > Kathleen > --=20 Best regards, Kathleen --089e0160b7d2b8084904fd4faac7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Mike! =C2=A0In-line...


On Thu, Jul 3, 2014 at 4:03 PM, Mike = Jones <Michael.Jones@microsoft.com> wrote:

Replies inline=E2=80=A6

=C2=A0

From: Kathleen= Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
Sent: Thursday, July 03, 2014 11:56 AM

To: Mike Jones
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorp= orating AD feedback on fifth spec of five

=C2=A0

Hello!

=C2=A0

Thank you for all of the updates to the JOSE drafts = in the current bundle in review. =C2=A0I appreciate all of the effort that = went into the revisions! =C2=A0As I understand it, there are a few general = issues we need to work through, then a few nits/requests are included on specific drafts.

=C2=A0

Knowing how we move forward on the following items w= ill be necessary as well as the shepherd/chair okay to progress the drafts = to IETF last call. =C2=A0As an FYI, since it was requested that the drafts = progress as a set, I may need to delay on which telechat the drafts get placed. =C2=A0Essentially, the set requir= es a lot of reading and I'd like to give the IESG enough time to do rev= iews.

=C2=A0

1. McGrew draft (applies to JWA)

=C2=A0 =C2=A0We are waiting on an updated version so= that the JWA draft can refer to it as opposed to duplicating text from it.=

=C2=A0

Mike>=C2=A0 I=E2=80=99= d proposed specific changes to the authors in May and David McGrew had tent= atively agreed with them and said that he=E2=80=99d produce an updated draf= t a few weeks ago.=C2=A0 This hasn=E2=80=99t happened yet.=C2=A0 I plan to stay en= gaged with this, including possibly producing a candidate draft to propose = to the authors, if necessary.=C2=A0 (This won=E2=80=99t happen until someti= me between the 4th and Toronto.)


OK, thanks for the= status.=C2=A0

=

=C2=A0

2. Alternate on text that applies to several of the = drafts for the following:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Discussion on word= ing =E2=80=9Cor use a JSON parser that returns

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only the lexically= last duplicate member name, as specified

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in Section 15.12 (= The JSON Object) of ECMAScript 5.1 [ECMAScript]=E2=80=9D.=C2=A0

=C2=A0

Jim or others may have text suggestions. =C2=A0This = was discussed on list, but has not been resolved yet.

=C2=A0

Mike> I believe that it=E2=80=99s already unamb= iguous as worded, but would be open to even clearer wording, if someone sup= plies it.


OK, let's see = if there are proposals or if Jim has a suggestion.=C2=A0

=C2=A0

3. Use cases not met by current set of drafts=

=C2=A0 =C2=A0 =C2=A0Documents do not meet all of the= use cases laid out in the Use Cases document

=C2=A0 =C2=A0 =C2=A0Specifically section 5.8 since t= here is no key management for=C2=A0

=C2=A0 =C2=A0 =C2=A0MACs (5.8.1. =E2=80=93 MAC based= on ECDH-derived key)

I'm not sure how this gets handled. =C2=A0If it = will be addressed in other drafts, let me know.

=C2=A0

Mike> This was issue #= 2 http://trac.tools.ietf.org/wg/jose/trac/ticket/2 and was extensivel= y discussed.=C2=A0 A formal consensus call on this was conducted by the cha= irs even prior to the attempt to re-open the issue by filing issue #2.=C2=A0 Jim=E2=80=99s resolution closing this was wontfix was =E2= =80=9CThe working group= has already considered this and has determined that it will not be address= ed. Until a request for the feature comes in from a group such as the WebCrypto? group it will not be re-considered.=E2=80=9D.

=C2=A0

That said, it=E2=80=99s w= ell understood how this could be cleanly added in a backwards compatible wa= y.=C2=A0 If a concrete need for this arises, I=E2=80=99d be glad to write u= p a quick draft, but since this is separable, I don=E2=80=99t believe that t= he possibility of doing this work in the future needs to have any impact on= completing the drafts we already have, which intentionally address the mos= t commonly occurring use cases.


OK, thank you.=C2= =A0

=

=C2=A0

4. =C2=A0I don't recall seeing any international= ization considerations, is that something we need to worry about?=

=C2=A0

Mike>=C2=A0 None of th= e 5 drafts define any strings intended for consumption by end-users, so I d= on=E2=80=99t think so.=C2=A0 Or if you prefer, I could explicitly say that,= perhaps just in the JWT draft?=C2=A0 Your call=E2=80=A6

No need then, if it comes up, I have an answer an= d that should be all I need on this one. =C2=A0Thanks.=C2=A0

=C2=A0

Nits/Comments for specific drafts:

=C2=A0

JWA:=C2=A0

Security considerations section 8.2 Key Lifetimes=

Should there be a reference to NIST 800-57 to provid= e guidance on this topic. =C2=A0If there is a better reference, that's = fine too. =C2=A0This is something that may get picked up on in other review= s.

=C2=A0

Mike> Will do

Thank you=C2=A0

=C2=A0

Thanks for reducing text by referring to other draft= s for a good portion of the security considerations section.<= /p>

=C2=A0

JWS:

For typ and cty, the text could be more clear in the= first paragraph sentence 2 and 4. =C2=A0They read as if they are in confli= ct. =C2=A0 The specific usage is different in these sentences, but that is = not made clear in the text. =C2=A0It should just be a text adjustment.

=C2=A0

Mike>=C2=A0 Will do

Thank you=C2=A0

=C2=A0

Section 8: TLS requirements, second paragraph:

For the second sentence, could you either include ex= amples or a reference to where the reader can ascertain appropriate appropr= iate cipher suites? =C2=A0This may be tough to address, but the way the sen= tence is written, it sounds like a reference or a recommendation is needed. =C2=A0Any ideas?

=C2=A0

Mike>=C2=A0 I=E2=80=99= d appreciate a specific reference.=C2=A0 I asked the TLS chairs for one yes= terday, but haven=E2=80=99t heard back from them yet.

OK, thanks.=C2=A0

=C2=A0

JWK:

Updates look good, thanks!

=C2=A0

JWE:

Updates look good, thank you!

=C2=A0

Oauth JWT: Sent to Oauth list

=C2=A0

Mike> Thanks again for= the thorough and useful reviews, Kathleen=E2=80=A6<= font color=3D"#888888">

=C2=A0

<= /font>
You're welcome a= nd thanks for the quick responses!

Kathleen=C2=A0

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

=C2=A0

On Thu, Jul 3, 2014 at 2:31 PM, Kathleen Moriarty &l= t;kat= hleen.moriarty.ietf@gmail.com> wrote:

Mike,

=C2=A0

Thanks for the updated JWT draft. =C2=A0I just read = through it again and the changes look good. =C2=A0

=C2=A0

I noticed that privacy considerations were not menti= oned. =C2=A0Should there be any discussed for claims, claim sets, etc.? =C2= =A0This is bound to come up in the IESG review if it is not addressed. =C2= =A0Sorry I didn't catch that on the first review.

=C2=A0<= /p>

On Tue, Jul 1, 2014 at 9:11 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

=C2=A0

=C2=A0

From: Mike Jon= es
Sent: Tuesday, July 01, 2014 6:11 PM
To: jose@ietf.org=
Subject: JOSE -30 and JWT -24 drafts incorporating AD feedback on fi= fth spec of five

=C2=A0

JOSE -30 and JWT -24 drafts have been posted incorpo= rating improvements resulting from Kathleen Moriarty=E2=80=99s JWE review.= =C2=A0 At this point, actions requested in her reviews of the JWS, JWE, JWK, JWA, and JWT specifications have all been incorporated.=C2=A0 Al= l changes in this release were strictly editorial in nature.<= /p>

=C2=A0

The specifications are available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-ietf-jose-json-= web-signature-30

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-ietf-jose-json= -web-encryption-30

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-ietf-jose-json-web-ke= y-30

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-ietf-jose-json= -web-algorithms-30

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-ietf-oauth-json-we= b-token-24

=C2=A0

HTML formatted versions are available at:<= /u>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-issued.info/docs/draft-ietf-j= ose-json-web-signature-30.html

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

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-issued.info/docs/draft-ietf-jose-js= on-web-key-30.html

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

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-issued.info/docs/draft-ietf-oaut= h-json-web-token-24.html

=C2=A0

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

=C2=A0

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

=C2=A0

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



=C2=A0

--

=C2=A0

Best regards,

Kathleen=



=C2=A0

--

=C2=A0

Best regards,

Kathleen




--

Best regards,
Kathleen
--089e0160b7d2b8084904fd4faac7-- From nobody Thu Jul 3 13:28:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17DE1B289A for ; Thu, 3 Jul 2014 13:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaSuAV8Asc4R for ; Thu, 3 Jul 2014 13:28:42 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32491B2895 for ; Thu, 3 Jul 2014 13:28:41 -0700 (PDT) Received: from mail-ie0-f178.google.com ([209.85.223.178]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKU7W88+rZA52CFcrCMy7dhWcOXdsh6gv2@postini.com; Thu, 03 Jul 2014 13:28:41 PDT Received: by mail-ie0-f178.google.com with SMTP id rl12so847868iec.37 for ; Thu, 03 Jul 2014 13:28:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IZRficaQTUsmF8a2cYQTr2Mwog7oh0pzqnxZ0wbZgzM=; b=dvu2TVW5FJ/ZL6dQNONIdAaOr/s86MeNpI/wT2cVK/BqDnICnv660jq3HNBs1DD0Uu M05WR0yFnzMrHwyNUmb6LOznKTSVz2zNuwnKu7YFQWslia7HMV/O4yqKfxCqKO+YM+tN lI15FDoOFEQ4edGYRvBb6zvHABy9tOdgtuOwtxDKW0Ug8f8iRKpbM+DpDx+T37JP7WKL BFuaOyxPDKG9bFyzsNmGwiFBVVVGIoO171MrofWdqsZ+YNhq32i0phvEaJdkjZuR3oFa Fk7aREdkEzQw4SgzHQGAVYolRrB15QdpZLKB5ieWw8Zj0q5estsGT1NiY8T7z+pq6wzB Au4g== X-Gm-Message-State: ALoCoQlIISlT8w5kuNHDfzGPNPTxHCbcQxoBdXOEv22UY4U1zQZLbB7YAEtyTsil7mZnLUPRXje65SB9LuMmKwvqJqAoB/aT0zANXdcH6Yy4LdLju8y64WwBs2dKT7UZkbgwuc2PqXFk X-Received: by 10.42.214.207 with SMTP id hb15mr12209788icb.30.1404419314072; Thu, 03 Jul 2014 13:28:34 -0700 (PDT) X-Received: by 10.42.214.207 with SMTP id hb15mr12209780icb.30.1404419313909; Thu, 03 Jul 2014 13:28:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Thu, 3 Jul 2014 13:28:02 -0700 (PDT) In-Reply-To: <2196A1F4-51D1-45FF-8F9B-2BD3BF0F7F66@oracle.com> References: <1403870837.2440.124.camel@shakespeare> <930f1bd03c9e4cbaae1e5c321b0ee5ec@BLUPR03MB309.namprd03.prod.outlook.com> <25c76f47a47e4c9faac9995cc1d89364@BLUPR03MB309.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B16804296739439AD990D2@TK5EX14MBXC294.redmond.corp.microsoft.com> <2196A1F4-51D1-45FF-8F9B-2BD3BF0F7F66@oracle.com> From: Brian Campbell Date: Thu, 3 Jul 2014 14:28:02 -0600 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=20cf301cbea25254b704fd4fdad8 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TNZaAO4N6RXn4t1GmNYruDeaJzA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 20:28:44 -0000 --20cf301cbea25254b704fd4fdad8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't think they do line up, at least not they way I read text from http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html and http://msdn.microsoft.com/en-us/library and /ee748487.aspx and *http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 * Indecently, Bradely was the guy that suggested to me that the definitions are reversed so I'm guessing he reads it the same way. But Tony and Mike are authors of the two specs respectively in question so, if they say that the definitions are aligned, they must be right. As Phil said, there is a lot of historical confusion about the terms and I think this conversation only underscores that confusion. A clean break with new terms might be the way to go. On Thu, Jul 3, 2014 at 1:51 PM, Phil Hunt wrote: > I suspect it lines up. But Brian=E2=80=99s point may still be relevant. T= here is > *long* standing confusion of the terms (because many of have different > english interpretation than WS-Trust). Might be time for new terms? > > Impersonate (or even personate) vs. delegate ? > > Those terms differentiate between impersonating a whole person vs. having > delegate or scoped authority to act for someone. > > Sorry if this is an old discussion. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jul 3, 2014, at 12:20 PM, Mike Jones > wrote: > > I=E2=80=99m lost too, as when I wrote this, I explicitly modelled it aft= er > WS-Trust. If there=E2=80=99s a concrete discrepancy you can point out, t= hat would > be great. > > > > FYI, I do plan to refresh this draft too allow for a more flexible trust > model shortly. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O= n > Behalf Of *Anthony Nadalin > *Sent:* Thursday, July 03, 2014 12:04 PM > *To:* Brian Campbell > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > > > > I=E2=80=99m lost, the terms defined in the oauth token-exchange draft are= the same > terms defined in ws-trust and have the same definitions > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com > ] > *Sent:* Thursday, July 3, 2014 12:02 PM > *To:* Anthony Nadalin > *Cc:* Vladimir Dzhuvinov; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > > > > And I was suggesting that OAuth token exchange align with the WS-Trust > definitions or maybe even define totally new terms. But not use the same > terms to mean different things. > > > > On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin > wrote: > > The explanation of on-behalf-Of and ActAs are correct in the document as > defined by WS-Trust, this may not be your desire or understanding but tha= t > is how WS-Trust implementations should work > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Thursday, July 3, 2014 11:44 AM > *To:* Vladimir Dzhuvinov > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > > > > FWIW, I am very interested in the general concept of a lightweight or > OAuth based token exchange mechanism. However, despite some distaste for > the protocol, our existing WS-Trust functionality has proven to be "good > enough" for most use-cases, which seems to prevent work on token exchange > from getting any real priority. > > I have a few thoughts on > http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've > been meaning to write down but haven't yet, so this seems like as good a > time as any. > > I would really like to see a simpler request model that doesn't require > the request to be JWT encoded. > > The draft mentions the potential confusion around On-Behalf-Of vs. > Impersonation Semantics. And it is confusing (to me anyway). In fact, the > use of Act-As and On-Behalf-Of seem to be reversed from how they are > defined in WS-Trust > (this MS > FAQ has less > confusing wording). They should probably be aligned with that prior work = to > avoid further confusion. Or maybe making a clean break and introducing ne= w > terms would be better. > > I don't think the security_token_request grant type value is strictly > legal per RFC 6749. The ABNF at > http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but > according to http://tools.ietf.org/html/rfc6749#section-4.5 extension > grants need an absolute URI as the grant type value (there's no grant typ= e > registry so the URI is the only means of preventing collision). > > > > > > > > > > > On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov < > vladimir@connect2id.com> wrote: > > Has anyone implemented the OAuth 2.0 Token exchange draft, in particular > the on-behalf-of semantics? We've got a use case for that and I'm > curious if someone has used it in practice. > > http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 > > Thanks, > > Vladimir > -- > Vladimir Dzhuvinov > Connect2id Ltd. > > _______________________________________________ > 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 > > > --20cf301cbea25254b704fd4fdad8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Indecently, Bradely was the guy that suggested to me that the= definitions are reversed so I'm guessing he reads it the same way.
But Tony and Mike are authors of the two specs respectively in q= uestion so, if they say that the definitions are aligned, they must be righ= t.

As Phil said, there is a lot of historical confusi= on about the terms and I think this conversation only underscores that conf= usion. A clean break with new terms might be the way to go.



On Thu, Jul 3, 2014 at 1:51 PM, Phil Hunt <phil.hunt@oracle.co= m> wrote:
I suspec= t it lines up. But Brian=E2=80=99s point may still be relevant. There is *l= ong* standing confusion of the terms (because many of have different englis= h interpretation than WS-Trust). Might be time for new terms?

Impersonate (or even personate) vs. delegate ?
Those terms differentiate between impersonating a whole person = vs. having delegate or scoped authority to act for someone.

Sorry if this is an old discussion.


On Jul 3, 2014, at 12:20 PM, Mike Jones <Michael.Jones@microsoft.com= > wrote:

I=E2=80=99m lost too= , as when I wrote this, I explicitly modelled it after WS-Trust.=C2=A0 If t= here=E2=80=99s a concrete discrepancy you can point out, that would be grea= t.

=C2=A0

FYI, I do plan to refresh this dr= aft too allow for a more flexible trust model shortly.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<= /p>

=C2=A0

From: OAuth [mailto= :oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, July 03, 2014 12:04 PM
To: Brian Campbell
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

=C2=A0

I=E2=80=99m lost, the terms defined in the oaut= h token-exchange draft are the same terms defined in ws-trust and have the = same definitions

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Thursday, July 3, 2014 12:02 PM
To: Anthony Nadalin
Cc: Vladimir Dzhuvinov; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

=C2=A0

And I was suggesting that OAuth token exchange = align with the WS-Trust definitions or maybe even define totally new terms.= But not use the same terms to mean different things.

=C2=A0=

On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadali= n <tonynad@mi= crosoft.com> wrote:

The explanation of o= n-behalf-Of and ActAs are correct in the document as defined by WS-Trust, t= his may not be your desire or understanding but that is how WS-Trust implement= ations should work

=C2=A0

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 3, 2014 11:44 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

=C2=A0

FWIW, I am very = interested in the general concept of a lightweight or OAuth based token exc= hange mechanism. However, despite some distaste for the protocol, our exist= ing WS-Trust functionality has proven to be "good enough" for most use-cases, which seems t= o prevent work on token exchange from getting any real priority.<= /u>

I have a few th= oughts on http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I&= #39;ve been meaning to write down but haven't yet, so this seems like a= s good a time as any.

I would really = like to see a simpler request model that doesn't require the request to= be JWT encoded.

The draft menti= ons the potential confusion around On-Behalf-Of vs. Impersonation Semantics= . And it is confusing (to me anyway). In fact, the use of Act-As and On-Beh= alf-Of seem to be reversed from how they are defined in WS-Trust (this MS FAQ has less confusing wording). They sh= ould probably be aligned with that prior work to avoid further confusion. O= r maybe making a clean break and introducing new terms would be better.

I don't think the security_token_request g= rant type value is strictly legal per RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but= according to http://tools.ietf.org/html/rfc6749#section-4.5 extension grants need = an absolute URI as the grant type value (there's no grant type registry= so the URI is the only means of preventing collision).


=C2=A0

=C2=A0=

=C2=A0=

=C2=A0=

On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuv= inov <vladi= mir@connect2id.com> wrote:

Has anyone implemented the OAuth 2.0 T= oken exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchan= ge-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov <vladimir@connect2id.com>
Connect2id Ltd.

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

=C2=A0

=C2=A0

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


--20cf301cbea25254b704fd4fdad8-- From nobody Thu Jul 3 14:26:25 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620F41B289E for ; Thu, 3 Jul 2014 14:26:23 -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 kDvu7nssxe6u for ; Thu, 3 Jul 2014 14:26:22 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E751B2898 for ; Thu, 3 Jul 2014 14:26:21 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id ty20so605589lab.3 for ; Thu, 03 Jul 2014 14:26:20 -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=bP8c1WWe1s+hXSSjLt43yyzlgrPzpoVd3nPoiNvZOQU=; b=ABEqZTijQzmvam0BT2s3VGvPT1gCjBMB46nXyToLl8oBXIszjLIbVk2+ZXxT+WMBBq Xxjya5xx9gdowXBNgVKuNrM80QcvOZpRPIjmX2crVh1kkNFGWgf/2D9ifJiyJD7ptn96 R1EtASQSGQzU6EOaz0Klzg8Z1aDYXe7kL3xNe5pya8LMX+LKxEnLZJDTRNlUhHkGWfZg xL5vK5bBD5f5MtzBDjYt7OEWN+Op5eclGjRxFCAlzulJKtp3ipLwasMBjO4slDKrH8eC /YkPwggL33bkJl62BHvlNJUjCfC3tV7+Hdm4tWExt4PoEEG/S6v86XO6p2b0FeUgpYVd spwQ== MIME-Version: 1.0 X-Received: by 10.112.17.102 with SMTP id n6mr4866452lbd.39.1404422780374; Thu, 03 Jul 2014 14:26:20 -0700 (PDT) Received: by 10.112.253.198 with HTTP; Thu, 3 Jul 2014 14:26:20 -0700 (PDT) Date: Thu, 3 Jul 2014 17:26:20 -0400 Message-ID: From: Kathleen Moriarty To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3d6f6f054cb04fd50a85c Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LE7UjKdlwbGDWilQsLxz0ytSL4g Subject: [OAUTH-WG] Review of draft-ietf-oauth-jwt-bearer-09 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, 03 Jul 2014 21:26:23 -0000 --001a11c3d6f6f054cb04fd50a85c Content-Type: text/plain; charset=UTF-8 Hello, I just read through draft-ietf-oauth-jwt-bearer-09 and it looks good. The only question/comment I have is that I don't see any mention of privacy considerations in the referenced security sections. COuld you add something? It is easily addressed by section 10.8 of RFC6749, but there is no mention of privacy considerations. I'm sure folks could generate great stories about who accessing what causing privacy considerations to be important. Thanks & have a nice weekend! -- Best regards, Kathleen --001a11c3d6f6f054cb04fd50a85c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

I just read through draft-ietf-oauth-jwt-bearer-09 and it looks good. =C2= =A0The only question/comment I have is that I don't see any mention of = privacy considerations in the referenced security sections. =C2=A0COuld you= add something? =C2=A0It is easily addressed by section 10.8 of RFC6749, bu= t there is no mention of privacy considerations. =C2=A0I'm sure folks c= ould generate great stories about who accessing what causing privacy consid= erations to be important.

Thanks & have a nice weekend!

<= /div>--

Best regards,
Kathleen
--001a11c3d6f6f054cb04fd50a85c-- From nobody Thu Jul 3 14:33:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A1F1A04FA; Thu, 3 Jul 2014 14:33:38 -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 srcOCF60kf_E; Thu, 3 Jul 2014 14:33:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8447D1B28AD; Thu, 3 Jul 2014 14:33:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703213336.27705.1246.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 14:33:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fph3JkWMDbbACWZfNGr_kRfDqnA Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-18.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: Thu, 03 Jul 2014 21:33:38 -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 Dynamic Client Registration Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Phil Hunt Filename : draft-ietf-oauth-dyn-reg-18.txt Pages : 39 Date : 2014-07-03 Abstract: This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server and the resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-18 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 Thu Jul 3 14:35:06 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE4E1A0428; Thu, 3 Jul 2014 14:35:03 -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 Mi-xI6IuiNtV; Thu, 3 Jul 2014 14:35:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7EB1A061D; Thu, 3 Jul 2014 14:34:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703213457.28973.87996.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 14:34:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/O77dpyasZ1J7hK4-OLyfrr6OENQ Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-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: Thu, 03 Jul 2014 21:35:03 -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 Dynamic Client Registration Management Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Phil Hunt Filename : draft-ietf-oauth-dyn-reg-management-02.txt Pages : 16 Date : 2014-07-03 Abstract: This specification defines methods for management of dynamic OAuth 2.0 client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Only some authorization servers supporting dynamic client registration will support these management methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-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 Thu Jul 3 14:40:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682811A04A2 for ; Thu, 3 Jul 2014 14:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoH9ZLrJIOKV for ; Thu, 3 Jul 2014 14:40:01 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67041A03F4 for ; Thu, 3 Jul 2014 14:40:00 -0700 (PDT) Received: from DM2PR03CA009.namprd03.prod.outlook.com (10.141.52.157) by DM2PR0301MB0623.namprd03.prod.outlook.com (25.160.95.27) with Microsoft SMTP Server (TLS) id 15.0.974.11; Thu, 3 Jul 2014 21:39:59 +0000 Received: from BY2FFO11FD006.protection.gbl (2a01:111:f400:7c0c::104) by DM2PR03CA009.outlook.office365.com (2a01:111:e400:2414::29) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Thu, 3 Jul 2014 21:39:59 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Thu, 3 Jul 2014 21:39:58 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0195.002; Thu, 3 Jul 2014 21:39:18 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Dynamic Client Registration specs clarifying usage of registration parameters Thread-Index: Ac+XBz5QA6FTwjL6RZCtkTqFiqOznQ== Date: Thu, 3 Jul 2014 21:39:18 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD9975B@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD9975BTK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(199002)(189002)(81342001)(19300405004)(92726001)(84676001)(92566001)(46102001)(80022001)(84326002)(74502001)(50986999)(85852003)(86612001)(16297215004)(83072002)(15202345003)(95666004)(54356999)(66066001)(86362001)(26826002)(99396002)(55846006)(20776003)(81542001)(77982001)(97736001)(19580395003)(76482001)(83322001)(104016002)(87936001)(68736004)(64706001)(69596002)(107046002)(106466001)(21056001)(33656002)(4396001)(229853001)(81156004)(15975445006)(512954002)(31966008)(77096002)(79102001)(44976005)(2656002)(2351001)(16236675004)(6806004)(85306003)(107886001)(19625215002)(71186001)(74662001)(110136001)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR0301MB0623; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0261CCEEDF Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/tUmRZkDd9Cs0KL4kTJVHLcFnpF0 Subject: [OAUTH-WG] OAuth Dynamic Client Registration specs clarifying usage of registration parameters 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, 03 Jul 2014 21:40:03 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD9975BTK5EX14MBXC294r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An updated OAuth Dynamic Client Registration spec has been published that c= larifies the usage of the Initial Access Token and Software Statement const= ructs and addresses other review feedback received since the last version. = See the History section for more details on the changes made. The OAuth Dynamic Client Registration Management has also been updated in t= he manner discussed at IETF 89 in London to be clear that not every server = implementing Dynamic Client Registration will also implement this set of re= lated management functions. The updated specifications are available at: * http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18 * http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-02 HTML formatted versions are also available at: * https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-18.html * https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-management= -02.html -- Mike P.S. I also posted this notice at http://self-issued.info/?p=3D1248 and as= @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439AD9975BTK5EX14MBXC294r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An updated OAuth Dynamic Client Registration spec ha= s been published that clarifies the usage of the Initial Access Token and S= oftware Statement constructs and addresses other review feedback received s= ince the last version.  See the History section for more details on the changes made.

 

The OAuth Dynamic Client Registration Management has= also been updated in the manner discussed at IETF 89 in London to be clear= that not every server implementing Dynamic Client Registration will also i= mplement this set of related management functions.

 

The updated specifications are available at:

·         http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-= 18

·         http://tools.ietf.org/html/draft-ietf-oau= th-dyn-reg-management-02

 

HTML formatted versions are also available at:<= /o:p>

·         https://self-issued.info/docs/draft-ietf-oau= th-dyn-reg-18.html

·         https://self-issued.info/docs/dra= ft-ietf-oauth-dyn-reg-management-02.html

 

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

 

P.S.  I also posted this notice at http://self-issued.info/?p=3D1248 and as @selfissued.

 

--_000_4E1F6AAD24975D4BA5B16804296739439AD9975BTK5EX14MBXC294r_-- From nobody Thu Jul 3 14:43:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC5D1A03F4 for ; Thu, 3 Jul 2014 14:43:11 -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 cqvx01gGeahA for ; Thu, 3 Jul 2014 14:43:08 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BE81B2A24 for ; Thu, 3 Jul 2014 14:43:08 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id hw13so696780qab.17 for ; Thu, 03 Jul 2014 14:43:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1+J6ts62/+/p1OO4PpiJWcKsGUQDCH633MNvBxeMM3E=; b=WnDoYvJdpyJ1gVctfEmLH02/UbBXjd0sCs+NofXUu+vjGMkOuGmbGF0cICNht4frjh 6Jn3LedhuSY8wB40XCArlMyn3yjfE5SzOLxWQaxrbNNQ0ujsWbU/Zk84w63kuu8C4Thr Wj91g0gWYT5cDKmthQm5bF+27V2s+X2KxOED6cBFPLfK564yfCvgQ13WZP0OIGx5OFF2 4k1QNtDlKEWNBkkGoRBjmzU1ijZ4r48YX/NkkarbWVVWmA0Mup6zmQ17qj2L4bCP+j05 EQGaKr8XJWC6yoXOBxtepFrsqvH7KY4bHshpOdAHrPqbSjg4JMMVHVv62nOck7ItUKp8 hl8g== X-Gm-Message-State: ALoCoQmHWop2jhkfbzs4NkVHwx1Sx/BnHawEkr4W6C5rJsSkV/na/j73qSeAdhOeHqfPn2DCe4O7 X-Received: by 10.229.234.3 with SMTP id ka3mr11934711qcb.16.1404423787338; Thu, 03 Jul 2014 14:43:07 -0700 (PDT) Received: from [192.168.0.199] ([201.188.19.158]) by mx.google.com with ESMTPSA id p12sm1161684qga.0.2014.07.03.14.43.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 14:43:06 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CBBBB24D-2100-4944-8105-ACC965CBEB4A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <2196A1F4-51D1-45FF-8F9B-2BD3BF0F7F66@oracle.com> Date: Thu, 3 Jul 2014 17:43:35 -0400 Message-Id: References: <1403870837.2440.124.camel@shakespeare> <930f1bd03c9e4cbaae1e5c321b0ee5ec@BLUPR03MB309.namprd03.prod.outlook.com> <25c76f47a47e4c9faac9995cc1d89364@BLUPR03MB309.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B16804296739439AD990D2@TK5EX14MBXC294.redmond.corp.microsoft.com> <2196A1F4-51D1-45FF-8F9B-2BD3BF0F7F66@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/XLZUrFZejnUwK8yvW3oI6aRfsYM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 21:43:11 -0000 --Apple-Mail=_CBBBB24D-2100-4944-8105-ACC965CBEB4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I pointed out a problem with the non normative text in sec 1.3 to Mike = off list quite a while go. 1.3. On-Behalf-Of vs. Impersonation Semantics When principal A acts on behalf of principal B, A is given all the rights that B has within some defined rights context. Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and = =20 not B. In a sense, A is an agent for B. On-behalf-of semantics are therefore different than impersonation semantics, with which it is sometimes confused. When principal A impersonates principal B, then in so far as any entity receiving Claims is concerned, they are actually dealing with B. It is true that some members of the identity system might have awareness that impersonation is going on but it is not a requirement. For all intents and purposes, when A is acting for B, A is B. OnBehalfOf "indicates that the requestor is making the request on = behalf of another." and returns a security token to the requestor that = contains a single set of claims. ActAs provides a security token/ assertion about subject A in a request = from Requester B and the response is a composite token that has = Requester B as the subject but also includes claims about subject A. See MS FAQ to clarify this popular question = http://msdn.microsoft.com/en-us/library/ee748487.aspx I think this is what Brian was trying to get at.=20 If we can't all agree on the semantics of OnBehalfOf (It has been around = for a long time) then we have a problem and should pick different terms. The normative text is correct, however sec 2.2 adds an optional "actor" = claim to the initial JWT that is to be presented as the value of = on_behalf_of in the request. That is an addition to the WS-Trust text = and took me several reads to understand that it is not a element in the = JWT response.=20 I offered to help with the spec as I think it is useful. The semantics = are tricky for people to understand so I was not all that concerned that = the first draft was not perfect. =20 I suspect some concrete examples will help. John B. On Jul 3, 2014, at 3:51 PM, Phil Hunt wrote: > I suspect it lines up. But Brian=92s point may still be relevant. = There is *long* standing confusion of the terms (because many of have = different english interpretation than WS-Trust). Might be time for new = terms? >=20 > Impersonate (or even personate) vs. delegate ? >=20 > Those terms differentiate between impersonating a whole person vs. = having delegate or scoped authority to act for someone. >=20 > Sorry if this is an old discussion. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Jul 3, 2014, at 12:20 PM, Mike Jones = wrote: >=20 >> I=92m lost too, as when I wrote this, I explicitly modelled it after = WS-Trust. If there=92s a concrete discrepancy you can point out, that = would be great. >> =20 >> FYI, I do plan to refresh this draft too allow for a more flexible = trust model shortly. >> =20 >> -- = Mike >> =20 >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony = Nadalin >> Sent: Thursday, July 03, 2014 12:04 PM >> To: Brian Campbell >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 >> =20 >> I=92m lost, the terms defined in the oauth token-exchange draft are = the same terms defined in ws-trust and have the same definitions >> =20 >> From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 >> Sent: Thursday, July 3, 2014 12:02 PM >> To: Anthony Nadalin >> Cc: Vladimir Dzhuvinov; oauth@ietf.org >> Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 >> =20 >> And I was suggesting that OAuth token exchange align with the = WS-Trust definitions or maybe even define totally new terms. But not use = the same terms to mean different things. >> =20 >>=20 >> On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin = wrote: >> The explanation of on-behalf-Of and ActAs are correct in the document = as defined by WS-Trust, this may not be your desire or understanding but = that is how WS-Trust implementations should work >> =20 >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian = Campbell >> Sent: Thursday, July 3, 2014 11:44 AM >> To: Vladimir Dzhuvinov >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 >> =20 >> FWIW, I am very interested in the general concept of a lightweight or = OAuth based token exchange mechanism. However, despite some distaste for = the protocol, our existing WS-Trust functionality has proven to be "good = enough" for most use-cases, which seems to prevent work on token = exchange from getting any real priority. >>=20 >> I have a few thoughts on = http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which = I've been meaning to write down but haven't yet, so this seems like as = good a time as any. >>=20 >> I would really like to see a simpler request model that doesn't = require the request to be JWT encoded. >>=20 >> The draft mentions the potential confusion around On-Behalf-Of vs. = Impersonation Semantics. And it is confusing (to me anyway). In fact, = the use of Act-As and On-Behalf-Of seem to be reversed from how they are = defined in WS-Trust (this MS FAQ has less confusing wording). They = should probably be aligned with that prior work to avoid further = confusion. Or maybe making a clean break and introducing new terms would = be better. >>=20 >> I don't think the security_token_request grant type value is strictly = legal per RFC 6749. The ABNF at = http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but = according to http://tools.ietf.org/html/rfc6749#section-4.5 extension = grants need an absolute URI as the grant type value (there's no grant = type registry so the URI is the only means of preventing collision). >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov = wrote: >> Has anyone implemented the OAuth 2.0 Token exchange draft, in = particular >> the on-behalf-of semantics? We've got a use case for that and I'm >> curious if someone has used it in practice. >>=20 >> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 >>=20 >> Thanks, >>=20 >> Vladimir >> -- >> Vladimir Dzhuvinov >> Connect2id Ltd. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_CBBBB24D-2100-4944-8105-ACC965CBEB4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I = pointed out a problem with the non normative text in sec 1.3 to Mike off = list quite a while go.

1.3.  =
On-Behalf-Of vs. Impersonation Semantics


   When principal A acts on behalf of principal B, A is given all the
   rights that B has within some defined rights context.  Whereas, with
   on-behalf-of semantics, principal A still has its own identity
   separate from B and it is explicitly understood that while B may have
   delegated its rights to A, any actions taken are being taken by A =
and   
   not B. In a sense, A is an agent for B.

   On-behalf-of =
semantics are therefore different than impersonation
   semantics, with which it is sometimes confused.  When principal A
   impersonates principal B, then in so far as any entity receiving
   Claims is concerned, they are actually dealing with B. It is true
   that some members of the identity system might have awareness that
   impersonation is going on but it is not a requirement.  For all
   intents and purposes, when A is acting for B, A is =
B.

OnBehalfOf  "indicates = that the requestor is making the request on behalf of another." and = returns a security token to the requestor that contains a single set of = claims.

ActAs provides a security token/ assertion about subject A in = a request from Requester B and the response is a composite token that = has Requester B as the subject but also includes claims about subject = A.

See MS FAQ to clarify this  popular = question http://msdn= .microsoft.com/en-us/library/ee748487.aspx

I think this is what Brian was = trying to get at. 

If we can't all agree on = the semantics of OnBehalfOf (It has been around for a long = time) then we have a problem and should = pick different terms.

The normative text is = correct, however sec 2.2 adds an optional "actor" claim to the initial = JWT that is to be presented as the value of  on_behalf_of in the request.  That is an = addition to the WS-Trust text and took me several reads to understand = that it is not a element in the JWT = response. 

I offered to help with = the spec as I think it is useful.  The semantics are tricky for = people to understand so I was not all that concerned that the first = draft was not perfect.  

I suspect some = concrete examples will help.

John = B.

On Jul 3, 2014, at 3:51 PM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

I suspect it lines up. But Brian=92s point may still = be relevant. There is *long* standing confusion of the terms (because = many of have different english interpretation than WS-Trust). Might be = time for new terms?

Impersonate (or even personate) = vs. delegate ?

Those terms differentiate = between impersonating a whole person vs. having delegate or scoped = authority to act for someone.

Sorry if this is = an old discussion.


On Jul 3, 2014, = at 12:20 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=92m lost too, as when I wrote this, I explicitly = modelled it after WS-Trust.  If there=92s a concrete discrepancy = you can point out, that would be great.

 

FYI, I do plan to refresh this draft too allow for a = more flexible trust model shortly.

 

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony = Nadalin
Sent: Thursday, July 03, 2014 = 12:04 PM
To: Brian = Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = draft-jones-oauth-token-exchange-00
 
I=92m lost, the terms defined in = the oauth token-exchange draft are the same terms defined in ws-trust = and have the same definitions
 
From: Brian Campbell [mailto:bcampbell@pingidentity.com] 
Sent: Thursday, July 3, 2014 = 12:02 PM
To: Anthony = Nadalin
Cc: Vladimir Dzhuvinov; oauth@ietf.org
Subject: Re: [OAUTH-WG] = draft-jones-oauth-token-exchange-00
 
And I was suggesting that OAuth token exchange align with the = WS-Trust definitions or maybe even define totally new terms. But not use = the same terms to mean different things.

 

On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin = <tonynad@microsoft.com> = wrote:
The = explanation of on-behalf-Of and ActAs are correct in the document as = defined by WS-Trust, this may not be your desire or understanding but = that is how WS-Trust implementations should = work
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian = Campbell
Sent: Thursday, July 3, 2014 = 11:44 AM
To: Vladimir = Dzhuvinov
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = draft-jones-oauth-token-exchange-00
 

FWIW, I am very interested in = the general concept of a lightweight or OAuth based token exchange = mechanism. However, despite some distaste for the protocol, our existing = WS-Trust functionality has proven to be "good enough" for most = use-cases, which seems to prevent work on token exchange from getting = any real priority.

I have a few thoughts on http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00=  which I've been = meaning to write down but haven't yet, so this seems like as good a time = as any.

I = would really like to see a simpler request model that doesn't require = the request to be JWT encoded.

The draft mentions the potential confusion around = On-Behalf-Of vs. Impersonation Semantics. And it is confusing (to me = anyway). In fact, the use of Act-As and On-Behalf-Of seem to be reversed = from how they are defined in WS-Trust (this MS FAQ has less confusing = wording). They should probably be aligned with that prior work to avoid = further confusion. Or maybe making a clean break and introducing new = terms would be better.

I = don't think the security_token_request grant type value is strictly = legal per RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but = according to http://tools.ietf.org/html/rfc6749#section-4.5 extension grants need an = absolute URI as the grant type value (there's no grant type registry so = the URI is the only means of preventing = collision).


 

 

 

 

On = Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> = wrote:
Has anyone implemented the OAuth 2.0 Token exchange = draft, in particular
the on-behalf-of semantics? We've got a use case = for that and I'm
curious if someone has used it in = practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00=

Thanks,

Vladimir
--
Vladimir Dzhuvinov <vladimir@connect2id.com>
Connect2id = Ltd.

_______________________________________________
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=_CBBBB24D-2100-4944-8105-ACC965CBEB4A-- From nobody Thu Jul 3 14:55:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEA31B2A3A for ; Thu, 3 Jul 2014 14:55: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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XREi3N2NwS2v for ; Thu, 3 Jul 2014 14:55:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3211B2A34 for ; Thu, 3 Jul 2014 14:55:19 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB310.namprd03.prod.outlook.com (10.141.48.25) with Microsoft SMTP Server (TLS) id 15.0.974.11; Thu, 3 Jul 2014 21:55:16 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0974.002; Thu, 3 Jul 2014 21:55:16 +0000 From: Anthony Nadalin To: John Bradley , Phil Hunt Thread-Topic: [OAUTH-WG] draft-jones-oauth-token-exchange-00 Thread-Index: AQHPkgBkTbUosZvlOkC0TtYXoBOysZuOuWWAgAACqfCAAAJWAIAAAFQQgAAE+QCAAAi6AIAAH0KAgAAA+uA= Date: Thu, 3 Jul 2014 21:55:15 +0000 Message-ID: <78548d3d22c84ea19ee58a3336f93adf@BLUPR03MB309.namprd03.prod.outlook.com> References: <1403870837.2440.124.camel@shakespeare> <930f1bd03c9e4cbaae1e5c321b0ee5ec@BLUPR03MB309.namprd03.prod.outlook.com> <25c76f47a47e4c9faac9995cc1d89364@BLUPR03MB309.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B16804296739439AD990D2@TK5EX14MBXC294.redmond.corp.microsoft.com> <2196A1F4-51D1-45FF-8F9B-2BD3BF0F7F66@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(24454002)(164054003)(69234005)(377454003)(93886003)(19609705001)(81342001)(81542001)(85306003)(46102001)(76576001)(15975445006)(74662001)(33646001)(20776003)(19300405004)(16236675004)(76482001)(105586002)(64706001)(107046002)(74502001)(83322001)(92566001)(19580405001)(19580395003)(2656002)(15202345003)(95666004)(76176999)(77982001)(83072002)(99286002)(80022001)(19625215002)(86362001)(74316001)(106356001)(31966008)(21056001)(101416001)(86612001)(106116001)(87936001)(79102001)(54356999)(50986999)(85852003)(99396002)(108616002)(42262001)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB310; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_78548d3d22c84ea19ee58a3336f93adfBLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wL2brYbXmxyX5Kglq-_D_qnXVS4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 21:55:25 -0000 --_000_78548d3d22c84ea19ee58a3336f93adfBLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ActAs the returned token is expected to be represented by the identity desc= ribed by this parameter OnBehalfOf the request is being made by the identity described by this para= meter These terms have been pretty clearly defined in the WS specifications, I do= n't understand the confusion. If section 1.3 is confusing, I'm OK with drop= ping this From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley Sent: Thursday, July 3, 2014 2:44 PM To: Phil Hunt Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 I pointed out a problem with the non normative text in sec 1.3 to Mike off = list quite a while go. 1.3. On-Behalf-Of vs. Impersonation Semantics When principal A acts on behalf of principal B, A is given all the rights that B has within some defined rights context. Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B. On-behalf-of semantics are therefore different than impersonation semantics, with which it is sometimes confused. When principal A impersonates principal B, then in so far as any entity receiving Claims is concerned, they are actually dealing with B. It is true that some members of the identity system might have awareness that impersonation is going on but it is not a requirement. For all intents and purposes, when A is acting for B, A is B. OnBehalfOf "indicates that the requestor is making the request on behalf o= f another." and returns a security token to the requestor that contains a s= ingle set of claims. ActAs provides a security token/ assertion about subject A in a request fro= m Requester B and the response is a composite token that has Requester B as= the subject but also includes claims about subject A. See MS FAQ to clarify this popular question http://msdn.microsoft.com/en-u= s/library/ee748487.aspx I think this is what Brian was trying to get at. If we can't all agree on the semantics of OnBehalfOf (It has been around fo= r a long time) then we have a problem and should pick different terms. The normative text is correct, however sec 2.2 adds an optional "actor" cla= im to the initial JWT that is to be presented as the value of on_behalf_of= in the request. That is an addition to the WS-Trust text and took me seve= ral reads to understand that it is not a element in the JWT response. I offered to help with the spec as I think it is useful. The semantics are= tricky for people to understand so I was not all that concerned that the f= irst draft was not perfect. I suspect some concrete examples will help. John B. On Jul 3, 2014, at 3:51 PM, Phil Hunt > wrote: I suspect it lines up. But Brian's point may still be relevant. There is *l= ong* standing confusion of the terms (because many of have different englis= h interpretation than WS-Trust). Might be time for new terms? Impersonate (or even personate) vs. delegate ? Those terms differentiate between impersonating a whole person vs. having d= elegate or scoped authority to act for someone. Sorry if this is an old discussion. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 3, 2014, at 12:20 PM, Mike Jones > wrote: I'm lost too, as when I wrote this, I explicitly modelled it after WS-Trust= . If there's a concrete discrepancy you can point out, that would be great= . FYI, I do plan to refresh this draft too allow for a more flexible trust mo= del shortly. -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin Sent: Thursday, July 03, 2014 12:04 PM To: Brian Campbell Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 I'm lost, the terms defined in the oauth token-exchange draft are the same = terms defined in ws-trust and have the same definitions From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Thursday, July 3, 2014 12:02 PM To: Anthony Nadalin Cc: Vladimir Dzhuvinov; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 And I was suggesting that OAuth token exchange align with the WS-Trust defi= nitions or maybe even define totally new terms. But not use the same terms = to mean different things. On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin > wrote: The explanation of on-behalf-Of and ActAs are correct in the document as de= fined by WS-Trust, this may not be your desire or understanding but that is= how WS-Trust implementations should work From: OAuth [mailto:oauth-bounces@ietf.org] = On Behalf Of Brian Campbell Sent: Thursday, July 3, 2014 11:44 AM To: Vladimir Dzhuvinov Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 FWIW, I am very interested in the general concept of a lightweight or OAuth= based token exchange mechanism. However, despite some distaste for the pro= tocol, our existing WS-Trust functionality has proven to be "good enough" f= or most use-cases, which seems to prevent work on token exchange from getti= ng any real priority. I have a few thoughts on http://tools.ietf.org/html/draft-jones-oauth-token= -exchange-00 which I've been meaning to write down but haven't yet, so this= seems like as good a time as any. I would really like to see a simpler request model that doesn't require the= request to be JWT encoded. The draft mentions the potential confusion around On-Behalf-Of vs. Imperson= ation Semantics. And it is confusing (to me anyway). In fact, the use of Ac= t-As and On-Behalf-Of seem to be reversed from how they are defined in WS-T= rust (this MS= FAQ has less confus= ing wording). They should probably be aligned with that prior work to avoid= further confusion. Or maybe making a clean break and introducing new terms= would be better. I don't think the security_token_request grant type value is strictly legal= per RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10= would allow it but according to http://tools.ietf.org/html/rfc6749#section= -4.5 extension grants need an absolute URI as the grant type value (there's= no grant type registry so the URI is the only means of preventing collisio= n). On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov > wrote: Has anyone implemented the OAuth 2.0 Token exchange draft, in particular the on-behalf-of semantics? We've got a use case for that and I'm curious if someone has used it in practice. http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 Thanks, Vladimir -- Vladimir Dzhuvinov = > Connect2id Ltd. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_78548d3d22c84ea19ee58a3336f93adfBLUPR03MB309namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ActAs the returned token = is expected to be represented by the identity described by this parameter

OnBehalfOf the request is= being made by the identity described by this parameter

 

These terms have been pre= tty clearly defined in the WS specifications, I don’t understand the = confusion. If section 1.3 is confusing, I’m OK with dropping this

 <= /p>

From: OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Thursday, July 3, 2014 2:44 PM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

 

I pointed out a problem with the non normative text = in sec 1.3 to Mike off list quite a while go.

 

1.3.  On-Behalf-Of vs. Impersonation Semantics

 
 
&n=
bsp;  When principal A acts on behalf of principal B, A is given all t=
he
&n=
bsp;  rights that B has within some defined rights context.  Wher=
eas, with
&n=
bsp;  on-behalf-of semantics, principal A still has its own identity
&n=
bsp;  separate from B and it is explicitly understood that while B may=
 have
&n=
bsp;  delegated its rights to A, any actions taken are being taken by =
A and   
&n=
bsp;  not B. In a sense, A is an agent for B.
&n=
bsp;  On-behalf-of semantics are therefore different than impersonatio=
n
&n=
bsp;  semantics, with which it is sometimes confused.  When princ=
ipal A
&n=
bsp;  impersonates principal B, then in so far as any entity receiving=

&n=
bsp;  Claims is concerned, they are actually dealing with B. It is tru=
e
&n=
bsp;  that some members of the identity system might have awareness th=
at
&n=
bsp;  impersonation is going on but it is not a requirement.  For=
 all
&n=
bsp;  intents and purposes, when A is acting for B, A is B.=

 

OnBehalfOf  "indicates that the= requestor is making the request on behalf of another." and returns a = security token to the requestor that contains a single set of claims.

 

ActAs provides a security token/ assertio= n about subject A in a request from Requester B and the response is a compo= site token that has Requester B as the subject but also includes claims about subject A.

 

See MS FAQ to clarify this  popular = question http://msdn.microsoft.com/en-us/library/ee748487.aspx<= /o:p>

 

I think this is what Brian was trying to = get at. 

 

If we can't all agree on the semanti= cs of OnBehalfOf (It has been around for a long time) then we have a p= roblem and should pick different terms.

 

The normative text is correct, however sec 2.2 adds = an optional "actor" claim to the initial JWT that is to be presen= ted as the value of  on_behalf_of in the request.  That is an add= ition to the WS-Trust text and took me several reads to understand that it is not a element in the JWT response. <= /p>

 

I offered to help with the spec as I think it is use= ful.  The semantics are tricky for people to understand so I was not a= ll that concerned that the first draft was not perfect.  

 

I suspect some concrete examples will help.

 

John B.

 

On Jul 3, 2014, at 3:51 PM, Phil Hunt <phil.hunt@oracle.com> wrote:



I suspect it lines up. But Brian’= ;s point may still be relevant. There is *long* standing confusion of the t= erms (because many of have different english interpretation than WS-Trust). Might be time for new terms?

 

Impersonate (or even personate) vs. de= legate ?

 

Those terms differentiate between impe= rsonating a whole person vs. having delegate or scoped authority to act for= someone.

 

Sorry if this is an old discussion.

 

 

 

 

On Jul 3, 2014, at 12:20 PM, Mike Jone= s <Michael.Jones@microsoft.com> wrote:<= /p>



I’m lost too, as wh= en I wrote this, I explicitly modelled it after WS-Trust.  If there= 217;s a concrete discrepancy you can point out, that would be great.=

 <= /p>

FYI, I do plan to refresh= this draft too allow for a more flexible trust model shortly.<= /o:p>

 <= /p>

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

 <= /p>

From: OAuth [ma= ilto:oauth-bounces@ietf.org] On Behalf Of <= /span>Anthony Nadalin
Sent: Thursday, Ju= ly 03, 2014 12:04 PM
To: Brian Campbell=
Cc: oauth@ietf.org<= br> Subject: Re: [OAUT= H-WG] draft-jones-oauth-token-exchange-00

 

I’m lost, the terms= defined in the oauth token-exchange draft are the same terms defined in ws= -trust and have the same definitions

 <= /p>

From: Brian Campbell [mailto:bcampbell@pingidentity.com] 
Sent: Thursday, Ju= ly 3, 2014 12:02 PM
To: Anthony Nadali= n
Cc: Vladimir Dzhuv= inov; oauth@ietf.org
Subject: Re: [OAUT= H-WG] draft-jones-oauth-token-exchange-00

 

And I was suggesting that OAuth token exchange align= with the WS-Trust definitions or maybe even define totally new terms. But = not use the same terms to mean different things.

 

On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin <= ;tonynad@microsoft.com> wrote:

The explanation of on-beh= alf-Of and ActAs are correct in the document as defined by WS-Trust, this m= ay not be your desire or understanding but that is how WS-Trust implementations should work

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, Ju= ly 3, 2014 11:44 AM
To: Vladimir Dzhuv= inov
Cc: oauth@ie= tf.org
Subject: Re: [OAUT= H-WG] draft-jones-oauth-token-exchange-00

 

FWIW, I am very inter= ested in the general concept of a lightweight or OAuth based token exchange= mechanism. However, despite some distaste for the protocol, our existing W= S-Trust functionality has proven to be "good enough" for most use-cases, which seems to prevent work= on token exchange from getting any real priority.

I have a few thoughts= on http://tools.ietf.org/html/draft-jones-oauth-toke= n-exchange-00 = which I've been meaning to write down but haven't yet, so this seems like as goo= d a time as any.

I would really like t= o see a simpler request model that doesn't require the request to be JWT en= coded.

The draft mentions th= e potential confusion around On-Behalf-Of vs. Impersonation Semantics. And = it is confusing (to me anyway). In fact, the use of Act-As and On-Behalf-Of= seem to be reversed from how they are defined in WS-Trust (this MS FAQ has le= ss confusing wording). They should probably be aligned with that prior work= to avoid further confusion. Or maybe making a clean break and introducing = new terms would be better.

I don't think the security_token_request grant type = value is strictly legal per RFC 6749. The ABNF at http://tools.ietf= .org/html/rfc6749#appendix-A.10 would allow it but according to http://tools.ietf.org/html/rfc6749#section= -4.5 extension grants need an absolute URI as the grant type value (there's no grant type= registry so the URI is the only means of preventing collision).=


 

 

 

 

On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov = <vladimir@connect2id.com> wrote:=

Has anyone implemented the OAuth 2.0 Token exchange = draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/d= raft-jones-oauth-token-exchange-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov <vladimir@connect2id.com>= ;
Connect2id Ltd.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
<= span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth

 

 

______________________________________= _________
OAuth mailing list
OAuth@ietf.o= rg
https://www.ietf.or= g/mailman/listinfo/oauth

 

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

 

--_000_78548d3d22c84ea19ee58a3336f93adfBLUPR03MB309namprd03pro_-- From nobody Thu Jul 3 15:02:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2421B2A61 for ; Thu, 3 Jul 2014 15:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M9tr3TA0gjJ for ; Thu, 3 Jul 2014 15:02:29 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C621E1A064C for ; Thu, 3 Jul 2014 15:02:28 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id x13so826065qcv.12 for ; Thu, 03 Jul 2014 15:02:28 -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=tCgTMVrgjLa4hXL2jaHh2+HNSoNzNH7DPhI1TBR3WlE=; b=K+KlPvqOCRjPgmcgnNMEOWISOFBpi+aMmksMogMqu6vTpYJrqsyz9/xBpRMUj881zm pTR4R/UzwFZzaJ9/LHJIa4wSM+Ux4Z5xmXdbVIwQ+5/wZDj324ehAU58e84Xcvm+ioLT PBnjlsBCDwoTUp1wHLThaciFQaYW6JAxfkIII8CtB1T+VPqqVk/fJ4Y1LXidAC1bx9FR GmIJUUL3U0Qf95jo74Jd7gEPTaZDnkgbtrkGgFyL/ZWKi52s/Tb2G/N2/tLS5gb7gGZC 5Tk5O0tAQAQ4e6YpiL2RyleMECnfGeHx8wXJETtRjma6J9WmPY68DJNuemFae8LVP5OF TfaQ== X-Gm-Message-State: ALoCoQkQF6wr4YG0OME13S/qEx2388bLNYVdgO9nd9+oWjabChag73jNlbJtTDOY/fdDWnWIU+L5 X-Received: by 10.140.98.195 with SMTP id o61mr3432601qge.41.1404424947941; Thu, 03 Jul 2014 15:02:27 -0700 (PDT) Received: from [192.168.0.199] ([201.188.19.158]) by mx.google.com with ESMTPSA id g4sm51792404qay.6.2014.07.03.15.02.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 15:02:27 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <53B584BA.6090901@gmail.com> Date: Thu, 3 Jul 2014 18:02:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <38EB3E9D-BA98-4A48-89A7-48C57F501238@ve7jtb.com> References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> <53B53F7C.506@gmail.com> <1404402057.15252.YahooMailNeo@web142801.mail.bf1.yahoo.com> <53B584BA.6090901@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/McZuEbC5lkO9Pjnlm5eIyNq5cbQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] refresh tokens and client instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 22:02:32 -0000 Yes, The the undifferentiated is initially differentiated by the user during = Authorization by having a code returned and then by exchanging the code = for a refresh token. It however returns to being undifferentiated on subsequent authorization = requests. =20 This makes having sticky grants (only asking for permission for = incremental scopes) a potential security problem, as the AS has no way = to know if the client is the one that the pervious authorization was = intended for.=20 Some AS just assume that you want the same permissions across all = instances of a client, however if this is a public client then someone = could impersonate the client app and basically do privilege escalation. What dynamic client registration gives us for native apps is a way to = identify specific instances of clients at the authorization endpoint by = having different client_id and validating that with instance specific = client credentials. This also prevents the use of code if it is = intercepted in the reply from the authorization endpoint. John B. On Jul 3, 2014, at 12:28 PM, Sergey Beryozkin = wrote: > Hi > On 03/07/14 16:40, Bill Mills wrote: >> Implementations may/SHOULD bind refresh tokens to specific client >> instances. Yes, it's possible that the client ID with dynamic >> registration is unique to each client, but many of the token theft = use >> cases include the possibility of stealing the client ID too if you = know >> you need to. >>=20 > What exactly is a 'client instance' when we talk about having a single = client id registration, with the id shared between multiple devices = (which is what I believe this thread started from). >=20 > What I understood, as far as the authorization service is concerned, a = 'client instance' for AS is a combination of a client id + code grant. >=20 > + (optional) refresh token (as was mentioned earlier). But it appears = to me a client instance can be uniquely identified by two values only = without a refresh token. >=20 > When a user authorizes a given device and gets a grant code and enters = it into the device securely we have a 'client instance' ready to get the = tokens, with that device (client instance) using a client id and the = grant code to get an access token and a refresh token. >=20 > Lets say it sends a "client_id=3D1&code=3D2" sequence to get the = tokens. > A client id + a code value constitutes a client instance, because a = code would be unique per every authorization, right ? >=20 > So the service will return an access token + refresh token to the = device. Refresh Token could've been associated with a record containing = a client id + grant code info earlier or at the moment the code is = exchanged for an access token. >=20 > During the subsequent refresh token grant request we have "client id + = refresh token" as a client instance. >=20 > I'm not sure what exactly I'd like to ask here :-), but I wonder if = the above sounds right, then I guess I'd like to conclude that when we = talk about the authorization code grant then a refresh token is not the = only key that uniquely identifies a client instance: >=20 > Initially it is a client id + code grant, a refresh token does not = offer an extra uniqueness at the point of the client device requesting = an access token with a code. Refresh token only starts acting as the key = client instance identifier at a refresh token grant time. >=20 > Sorry for a long email, I'm very likely missing something, so any = clarifications will be welcome >=20 > Thanks, Sergey >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> -bill >>=20 >>=20 >> On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin >> wrote: >>=20 >>=20 >> Hi >>=20 >> I'm finding the answers from John interesting but I'm failing to >> understand why refresh tokens are mentioned in scope of identifying = the >> specific client instances. >>=20 >> AFAIK refresh tokens would only go on the wire, assuming they are >> supported, when a client exchanges a grant for a new access token. >> And when the client uses a refresh token grant. >>=20 >> Was it really about a refresh token grant where the incoming client = id >> and refresh token pair can uniquely identify the actual client = instance >> ? That would make sense. >>=20 >> Something else I'd like to clarify. >> John mentions a refresh token is created at the authorization grant >> initialization time. Would it make any difference, as far as the >> security properties of a grant are concerned, if refresh token was = only >> created at a grant to access token exchange point of time ? >>=20 >> Thanks, Sergey >>=20 >> On 27/06/14 19:21, John Bradley wrote: >> > Inline >> > >> > On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri = > >> > >> = wrote: >> > >> >> Hi John, >> >> Thank you for your reply. Would appreciate if you consider my = inline >> >> comments below and respond again! >> >> R, >> >> Madjid >> >> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com >> ] >> >> *Sent:*Wednesday, June 25, 2014 5:56 PM >> >> *To:*Madjid Nakhjiri >> >> *Cc:*oauth@ietf.org > > >> >> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances >> >> In 3.3 It is saying that the refresh token is a secret that the >> >> Authorization server has bound to the client_id, that the >> >> Authorization server effectively uses to differentiate between >> >> instances of that client_id. >> >> Madjid>>If I have 10,000s of devices, each with an instance of the >> >> OAUTH client, but they are all using the same client ID, how would = the >> >> server know which token to use for what client? unless when I am >> >> creating a token, I also include something that uniquely = identifies >> >> each instance? Don=92t I have to use SOMETHING that is unique to = that >> >> instance (user grant/ID?)? >> > When the grant is issued you create and store a refresh token which = is >> > effectively the identifier for that instance/grant combination. >> > When it comes back on a request to the token endpoint you look up = the >> > grants associated with it. You also hack that the client_id sent = in >> > the request matches to detect errors mostly) >> > >> >> When the refresh token is generated, it can be stored in a table = with >> >> the client_id and the information about the grant. You could also = do >> >> it statelesly by creating a signed object as the refresh token. >> >> Madjid>>agreed, but for the signed object to be self-sustained, = again >> >> would I not need something beyond a =93population=94 client_ID? = Are we >> >> prescriptive what =93information about the grant=94 is? >> > You would be creating a bearer token as long as the AS signs it you = can >> > put whatever grant grant info you like in it, that is = implementation >> > specific. It could be a list of the scopes granted and the = subject. >> >> The spec is silent on the exact programming method that the >> >> Authorization server uses. >> >> Madjid>>Are there any other specs in IETF or elsewhere (OASIS, = etc?) >> >> that prescribe token calculation (e.g. hash function, parameters, = etc)? >> > >> > You can look at JOSE and JWT for a way to create tokens >> > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token >> >> In 3.7 Deployment independent describes using the same client_id >> >> across multiple instances of a native client, or multiple = instances of >> >> a Java Script client running in a browsers with the same callback = uri. >> >> Since the publishing of this RFC we have also developed a spec for >> >> dynamic client registration so it is possible to give every native >> >> client it's own client_id and secret making them confidential = clients. >> >> Madjid>>I would need to look at those specs, however, I thought = that >> >> the =93confidential client=94 designation has to do with the = client >> >> ability to hold secrets and perform a-by-server-acceptable >> >> authentication. Does dynamic client registration affect client=92s >> >> ability in that aspect? >> > >> > Yes it doesn't require the secret to be in the downloaded instance = of >> > the native app. It can be populated at first run, changing it from >> > public to confidential. >> > Confidential is not just for web servers any more. >> >> There is also a middle ground some people take by doing a proof of >> >> possession for code in native applications to prevent the = interception >> >> of responses to the client by malicious applications on the = device. >> >> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ >> >> John B. >> >> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri = > >> >> >> = wrote: >> >> >> >> >> >> Hi all, >> >> I am new to OAUTH list and OAUTH, so apologies if this is very >> off-topic. >> >> I am evaluating an OAUTH 2.0 implementation that is done based on = bare >> >> bone base OAUTH2.0 RFC. =46rom what I understand, many (or some) = client >> >> implementations use a =93global ID/secret=94 pair for all = instances of the >> >> client. Looking at RFC 6819 and there seem to be a whole page on = this >> >> topic, if I understand it correctly. So questions: >> >> 1)Section 3.7 talks about deployment-independent versus deployment >> >> specific client IDs. I am guessing =93deployment-independent=94 = refers to >> >> what I called =93global=94, meaning if I have the same client with = the >> >> same client ID installed in many end devices, that is a deployment >> >> independent case, correct? >> >> 2)Section 3.3 on refresh token mentions that the token is secret = bound >> >> to the client ID and client instance. Could somebody please point = me >> >> to where the token generation and binding is described? Also how = is >> >> the client instance is identified? >> >> Thanks a lot in advance, >> >> Madjid Nakhjiri >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/oauth >>=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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Jul 3 15:16:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF9E1B2AB6 for ; Thu, 3 Jul 2014 15:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wn3xajuksJ_e for ; Thu, 3 Jul 2014 15:15:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66BA91B2AB4 for ; Thu, 3 Jul 2014 15:15:56 -0700 (PDT) Received: from BN3PR0301CA0084.namprd03.prod.outlook.com (25.160.152.180) by BLUPR03MB341.namprd03.prod.outlook.com (10.141.48.12) with Microsoft SMTP Server (TLS) id 15.0.980.8; Thu, 3 Jul 2014 22:15:54 +0000 Received: from BY2FFO11FD011.protection.gbl (2a01:111:f400:7c0c::197) by BN3PR0301CA0084.outlook.office365.com (2a01:111:e400:401e::52) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Thu, 3 Jul 2014 22:15:54 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD011.mail.protection.outlook.com (10.1.14.129) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Thu, 3 Jul 2014 22:15:54 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0195.002; Thu, 3 Jul 2014 22:15:01 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: New Version Notification for draft-hunt-oauth-v2-user-a4c-04.txt Thread-Index: AQHPlwu/Jm89uED4/UmkZPLOKi5/uJuO6Yug Date: Thu, 3 Jul 2014 22:15:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD99A9A@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <20140703221122.8795.29152.idtracker@ietfa.amsl.com> In-Reply-To: <20140703221122.8795.29152.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD99A9ATK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(979002)(438002)(189002)(199002)(13464003)(377454003)(377424004)(2656002)(106116001)(74662001)(20776003)(55846006)(87936001)(26826002)(19625215002)(85852003)(4396001)(95666004)(83072002)(512874002)(104016002)(19300405004)(66066001)(71186001)(31966008)(15202345003)(21056001)(80022001)(107886001)(107046002)(2351001)(46102001)(64706001)(33656002)(77982001)(16236675004)(86362001)(92726001)(92566001)(81342001)(79102001)(81156004)(86612001)(106466001)(81542001)(84326002)(69596002)(19580405001)(6806004)(44976005)(83322001)(97736001)(68736004)(19580395003)(85306003)(76176999)(54356999)(50986999)(74502001)(99396002)(77096002)(76482001)(15975445006)(84676001)(110136001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB341; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0261CCEEDF Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jd8uH_HJxpfrfgxlEJmutM5U638 Subject: [OAUTH-WG] FW: New Version Notification for draft-hunt-oauth-v2-user-a4c-04.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: Thu, 03 Jul 2014 22:15:59 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD99A9ATK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyB2ZXJzaW9uIG9mIHRoZSBzcGVjIGNvbnRhaW5zIHRoZXNlIGNoYW5nZXM6DQoNCsK3ICAg ICAgICAgQWRkZWQgYSBudW1iZXIgb2YgYW1yIHZhbHVlcy4NCg0KwrcgICAgICAgICBSZW5hbWVk IHRoZSBjb2RlX2lkX3Rva2VuIHJlc3BvbnNlIHR5cGUgdG8gY29kZV9mb3JfaWRfdG9rZW4uDQoN CsK3ICAgICAgICAgRGVmaW5lZCB0aGUgY29kZV9mb3JfaWRfdG9rZW4gZ3JhbnRfdHlwZS4NCg0K wrcgICAgICAgICBSZW1vdmVkIHRoZSBtaW5fYWx2IHJlcXVlc3QgcGFyYW1ldGVyLCBzaW5jZSBp dCdzIGFjdHVhbGx5IGp1c3QgYSBzcGVjaWFsIGNhc2Ugb2YgYWNyX3ZhbHVlcy4gKEZvciBpbnN0 YW5jZSwgIm1pbl9hbHY9MyIgbWVhbnQgdGhlIHNhbWUgdGhpbmcgYXMgImFjcl92YWx1ZXM9MyA0 Ii4pDQoNCsK3ICAgICAgICAgQWRkZWQgYW4gYXBwZW5kaXggZGVzY3JpYmluZyB0aGUgZGVsdGFz IGZyb20gT3BlbklEIENvbm5lY3QuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KU2VudDogVGh1cnNkYXksIEp1bHkgMDMsIDIwMTQg MzoxMSBQTQ0KVG86IFBoaWwgSHVudDsgQW50aG9ueSBOYWRhbGluOyBQaGlsIEh1bnQ7IE1pa2Ug Sm9uZXM7IEFudGhvbnkgTmFkYWxpbjsgTWlrZSBKb25lcw0KU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA0LnR4dA0KDQoN Cg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRj LTA0LnR4dA0KDQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1pY2hhZWwgQi4g Sm9uZXMgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQoNCg0KTmFtZTogICAg ICAgICAgICAgICAgICBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjDQoNClJldmlzaW9uOiAg ICAgICAgICAgICAgMDQNCg0KVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgIFByb3ZpZGluZyBV c2VyIEF1dGhlbnRpY2F0aW9uIEluZm9ybWF0aW9uIHRvIE9BdXRoIDIuMCBDbGllbnRzDQoNCkRv Y3VtZW50IGRhdGU6ICAgICAgICAgICAgICAgMjAxNC0wNy0wMw0KDQpHcm91cDogICAgICAgICAg ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCg0KUGFnZXM6ICAgICAgICAgICAgICAgICAg IDE1DQoNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA0LnR4dA0KDQpTdGF0dXM6ICAgICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHVudC1vYXV0aC12Mi11c2Vy LWE0Yy8NCg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDQNCg0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDQNCg0K DQoNCkFic3RyYWN0Og0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIHdheSBmb3Ig T0F1dGggMi4wIGNsaWVudHMgdG8gdmVyaWZ5IHRoZQ0KDQogICBpZGVudGl0eSBvZiB0aGUgRW5k LVVzZXIgYW5kIG9idGFpbiBjb25zZW50IGJhc2VkIHVwb24gdGhlDQoNCiAgIGF1dGhlbnRpY2F0 aW9uIHBlcmZvcm1lZCBieSBhbiBBdXRob3JpemF0aW9uIFNlcnZlci4gIFRoZQ0KDQogICBpbnRl cmFjdGlvbnMgZGVmaW5lZCBieSB0aGlzIHNwZWNpZmljYXRpb24gYXJlIGludGVudGlvbmFsbHkN Cg0KICAgY29tcGF0aWJsZSB3aXRoIHRoZSBPcGVuSUQgQ29ubmVjdCBwcm90b2NvbC4NCg0KDQoN Cg0KDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg0K --_000_4E1F6AAD24975D4BA5B16804296739439AD99A9ATK5EX14MBXC294r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjI0 LjBwdDsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDoyNC4wcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnR0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCWNvbG9yOiMwMDMzNjY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBp bjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5Q bGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1 Njg5OTk3MDk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0OTA0MTc0MDt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LTg0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6LTg0LjBwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDotNDguMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDotNDguMHB0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi0xMi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Oi0xMi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI0LjBwdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjYwLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NjAuMHB0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 OTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo5 Ni4wcHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxMzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDoxMzIuMHB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MTY4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6MTY4LjBwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIwNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIwNC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjgxMTg2OTY4NzsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTg3MTg3OTA2NCA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoaXMgdmVyc2lvbiBvZiB0aGUgc3BlYyBjb250YWlucyB0 aGVzZSBjaGFuZ2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLXJpZ2h0OjQ4LjBw dDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4iIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxh bmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFkZGVkIGEgbnVtYmVy IG9mDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMwMDMzNjYiPmFtcjwvc3Bhbj48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gdmFsdWVz Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tcmlnaHQ6NDguMHB0O21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEg bGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4iIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmVuYW1lZCB0aGUNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwMzM2NiI+Y29kZV9pZF90b2tlbjwvc3Bhbj48c3BhbiBs YW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gcmVzcG9uc2UgdHlw ZSB0bw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMDAzMzY2Ij5jb2RlX2Zvcl9p ZF90b2tlbjwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1yaWdodDo0OC4wcHQ7 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omwx IGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EZWZpbmVkIHRoZQ0KPC9z cGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMDAzMzY2Ij5jb2RlX2Zvcl9pZF90b2tlbjwv c3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4N Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwMzM2NiI+Z3JhbnRfdHlwZTwvc3Bh bj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4uDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1yaWdodDo0OC4wcHQ7bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8y Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SZW1vdmVkIHRoZQ0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMDAzMzY2Ij5taW5fYWx2PC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiByZXF1ZXN0IHBhcmFtZXRlciwgc2lu Y2UgaXQncyBhY3R1YWxseSBqdXN0IGEgc3BlY2lhbCBjYXNlIG9mDQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMwMDMzNjYiPmFjcl92YWx1ZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LiAoRm9yIGluc3RhbmNlLCAmcXVv dDttaW5fYWx2PTMmcXVvdDsgbWVhbnQgdGhlIHNhbWUgdGhpbmcgYXMgJnF1b3Q7YWNyX3ZhbHVl cz0zDQogNCZxdW90Oy4pIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLXJpZ2h0OjQ4 LjBwdDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFkZGVkIGFuIGFw cGVuZGl4IGRlc2NyaWJpbmcgdGhlIGRlbHRhcyBmcm9tIE9wZW5JRCBDb25uZWN0Lg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSA8 YnI+DQpTZW50OiBUaHVyc2RheSwgSnVseSAwMywgMjAxNCAzOjExIFBNPGJyPg0KVG86IFBoaWwg SHVudDsgQW50aG9ueSBOYWRhbGluOyBQaGlsIEh1bnQ7IE1pa2UgSm9uZXM7IEFudGhvbnkgTmFk YWxpbjsgTWlrZSBKb25lczxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNC50eHQ8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDQudHh0PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IE1pY2hhZWwgQi4gSm9uZXMgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0 b3J5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5OYW1lOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRj PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZXZpc2lvbjombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMDQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBQcm92aWRpbmcgVXNlciBBdXRoZW50aWNhdGlvbiBJbmZvcm1h dGlvbiB0byBPQXV0aCAyLjAgQ2xpZW50czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+RG9jdW1lbnQgZGF0ZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAxNC0w Ny0wMzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+R3JvdXA6Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlz c2lvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGFnZXM6Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE1PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1bnQtb2F1dGgtdjItdXNl ci1hNGMtMDQudHh0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odW50 LW9hdXRoLXYyLXVzZXItYTRjLTA0LnR4dDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5TdGF0dXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMvIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLzwvc3Bhbj48L2E+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IdG1saXplZDombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5EaWZmOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA0Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA0 PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWJzdHJhY3Q6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVGhpcyBzcGVj aWZpY2F0aW9uIGRlZmluZXMgYSB3YXkgZm9yIE9BdXRoIDIuMCBjbGllbnRzIHRvIHZlcmlmeSB0 aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBp ZGVudGl0eSBvZiB0aGUgRW5kLVVzZXIgYW5kIG9idGFpbiBjb25zZW50IGJhc2VkIHVwb24gdGhl PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYXV0 aGVudGljYXRpb24gcGVyZm9ybWVkIGJ5IGFuIEF1dGhvcml6YXRpb24gU2VydmVyLiZuYnNwOyBU aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBp bnRlcmFjdGlvbnMgZGVmaW5lZCBieSB0aGlzIHNwZWNpZmljYXRpb24gYXJlIGludGVudGlvbmFs bHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBj b21wYXRpYmxlIHdpdGggdGhlIE9wZW5JRCBDb25uZWN0IHByb3RvY29sLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+VGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439AD99A9ATK5EX14MBXC294r_-- From nobody Thu Jul 3 16:09:10 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE851B2ABB for ; Thu, 3 Jul 2014 16:08:56 -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 WGNkNz8L2i6h for ; Thu, 3 Jul 2014 16:08:51 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758DA1B29C2 for ; Thu, 3 Jul 2014 16:08:51 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id i8so863645qcq.20 for ; Thu, 03 Jul 2014 16:08:50 -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=MrfG5S7gBLb5AjcWZ+8vS2FJ16UpNqO3KsN7BNdOIOg=; b=j5f52xQWHrMnUe29IM4NZb7JlZQFJ1+1E+f0+ZxeHJW0rFlLaYxQwVO3KOTKxs4Eax LiRGxKkRsXMUmyElZU0MdPP3O17cbW1NzWWdWsHur18hbOI75rYHnsQlvA1NotnlaczR NTwrzjLttrhDU2E9VpFFI7Yl2hKli4dMWGANyUh8iPJHPI1oINk+TWJFsJZNHclWSvRG VIn1o8YRl4Qc6BDtIF8AamesZrxSf54Gl9Ki5ZxdNg/FNhdEoHXo9FgaoTPXoGwCWi5S N8ixuI3uu7I5m8vAnN5C/pBDx2OEy9u1J8npR6Sfx0DLGVgbymyZFpoYZiqM6r6C47D1 GbOg== X-Gm-Message-State: ALoCoQluOLuH9mV1i46dqamhlS+8ygb2YZzVF8mcBVmo+VEg/qNmc00yvqTZGWKlVLfYymqTm2Be X-Received: by 10.224.162.212 with SMTP id w20mr12691830qax.50.1404428930463; Thu, 03 Jul 2014 16:08:50 -0700 (PDT) Received: from [192.168.0.199] ([201.188.19.158]) by mx.google.com with ESMTPSA id b9sm52089470qae.4.2014.07.03.16.08.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 16:08:49 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_666C73D8-6820-4038-97C6-2B1DF45D0FB9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <78548d3d22c84ea19ee58a3336f93adf@BLUPR03MB309.namprd03.prod.outlook.com> Date: Thu, 3 Jul 2014 19:09:18 -0400 Message-Id: <3E62D8C3-FAF2-4D9F-89C9-EBBEF4261550@ve7jtb.com> References: <1403870837.2440.124.camel@shakespeare> <930f1bd03c9e4cbaae1e5c321b0ee5ec@BLUPR03MB309.namprd03.prod.outlook.com> <25c76f47a47e4c9faac9995cc1d89364@BLUPR03MB309.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B16804296739439AD990D2@TK5EX14MBXC294.redmond.corp.microsoft.com> <2196A1F4-51D1-45FF-8F9B-2BD3BF0F7F66@oracle.com> <78548d3d22c84ea19ee58a3336f93adf@BLUPR03MB309.namprd03.prod.outlook.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-aXmhipGb3j1NkaqK4C9X2kj4rE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 23:08:56 -0000 --Apple-Mail=_666C73D8-6820-4038-97C6-2B1DF45D0FB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is the first time this draft has come up on the list so people = coming up to speed is to be expected. In WS-Trust the security tokens are not tied to a single representation. = =20 /wst:RequestSecurityToken/wst14:ActAs This OTPIONAL element indicates that the requested token is expected to = contain information about the identity represented by the content of = this element and the token requestor intends to use the returned token = to act as this identity. The identity that the requestor wants to act-as = is specified by placing a security token or = element within the element. Is clear that the resulting token contains information about the = identity represented by the security token passed as the content of the = ActAs element and that the requester wants to act-as is that identity. Depending on the resulting security token that may be represented = differently. Nothing explicitly states that the identity of the = requester is in the resulting token, however when SAML tokens are used = it typically is represented along with the identity to act-as. =20 OnBehalfOf being older was treated as a proxy type request On-Behalf-Of = the initial subject resulting in a token for the Original subject that = may have been used by another party such as the requester. So Sec 1.3 may be trying to describe composite tokens vs single subject = tokens that may be beyond the scope of those token independent = parameters in WS-Trust. It is probably fair to say that from the way those parameters are = implemented for SAML tokens in many if not all STS the description seems = backwards. Having something that describes how the output token varies based on = input for typical token types might help make it more concrete for = people. John B. On Jul 3, 2014, at 5:55 PM, Anthony Nadalin = wrote: > ActAs the returned token is expected to be represented by the identity = described by this parameter > OnBehalfOf the request is being made by the identity described by this = parameter > =20 > These terms have been pretty clearly defined in the WS specifications, = I don=92t understand the confusion. If section 1.3 is confusing, I=92m = OK with dropping this > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Thursday, July 3, 2014 2:44 PM > To: Phil Hunt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > =20 > I pointed out a problem with the non normative text in sec 1.3 to Mike = off list quite a while go. > =20 > 1.3. On-Behalf-Of vs. Impersonation Semantics >=20 > =20 > =20 > When principal A acts on behalf of principal B, A is given all the > rights that B has within some defined rights context. Whereas, = with > on-behalf-of semantics, principal A still has its own identity > separate from B and it is explicitly understood that while B may = have > delegated its rights to A, any actions taken are being taken by A = and =20 > not B. In a sense, A is an agent for B. > On-behalf-of semantics are therefore different than impersonation > semantics, with which it is sometimes confused. When principal A > impersonates principal B, then in so far as any entity receiving > Claims is concerned, they are actually dealing with B. It is true > that some members of the identity system might have awareness that > impersonation is going on but it is not a requirement. For all > intents and purposes, when A is acting for B, A is B. > =20 > OnBehalfOf "indicates that the requestor is making the request on = behalf of another." and returns a security token to the requestor that = contains a single set of claims. > =20 > ActAs provides a security token/ assertion about subject A in a = request from Requester B and the response is a composite token that has = Requester B as the subject but also includes claims about subject A. > =20 > See MS FAQ to clarify this popular question = http://msdn.microsoft.com/en-us/library/ee748487.aspx > =20 > I think this is what Brian was trying to get at.=20 > =20 > If we can't all agree on the semantics of OnBehalfOf (It has been = around for a long time) then we have a problem and should pick different = terms. > =20 > The normative text is correct, however sec 2.2 adds an optional = "actor" claim to the initial JWT that is to be presented as the value of = on_behalf_of in the request. That is an addition to the WS-Trust text = and took me several reads to understand that it is not a element in the = JWT response.=20 > =20 > I offered to help with the spec as I think it is useful. The = semantics are tricky for people to understand so I was not all that = concerned that the first draft was not perfect. =20 > =20 > I suspect some concrete examples will help. > =20 > John B. > =20 > On Jul 3, 2014, at 3:51 PM, Phil Hunt wrote: >=20 >=20 > I suspect it lines up. But Brian=92s point may still be relevant. = There is *long* standing confusion of the terms (because many of have = different english interpretation than WS-Trust). Might be time for new = terms? > =20 > Impersonate (or even personate) vs. delegate ? > =20 > Those terms differentiate between impersonating a whole person vs. = having delegate or scoped authority to act for someone. > =20 > Sorry if this is an old discussion. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On Jul 3, 2014, at 12:20 PM, Mike Jones = wrote: >=20 >=20 > I=92m lost too, as when I wrote this, I explicitly modelled it after = WS-Trust. If there=92s a concrete discrepancy you can point out, that = would be great. > =20 > FYI, I do plan to refresh this draft too allow for a more flexible = trust model shortly. > =20 > -- = Mike > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony = Nadalin > Sent: Thursday, July 03, 2014 12:04 PM > To: Brian Campbell > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > =20 > I=92m lost, the terms defined in the oauth token-exchange draft are = the same terms defined in ws-trust and have the same definitions > =20 > From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 > Sent: Thursday, July 3, 2014 12:02 PM > To: Anthony Nadalin > Cc: Vladimir Dzhuvinov; oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > =20 > And I was suggesting that OAuth token exchange align with the WS-Trust = definitions or maybe even define totally new terms. But not use the same = terms to mean different things. > =20 >=20 > On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin = wrote: > The explanation of on-behalf-Of and ActAs are correct in the document = as defined by WS-Trust, this may not be your desire or understanding but = that is how WS-Trust implementations should work > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian = Campbell > Sent: Thursday, July 3, 2014 11:44 AM > To: Vladimir Dzhuvinov > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > =20 > FWIW, I am very interested in the general concept of a lightweight or = OAuth based token exchange mechanism. However, despite some distaste for = the protocol, our existing WS-Trust functionality has proven to be "good = enough" for most use-cases, which seems to prevent work on token = exchange from getting any real priority. >=20 > I have a few thoughts on = http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which = I've been meaning to write down but haven't yet, so this seems like as = good a time as any. >=20 > I would really like to see a simpler request model that doesn't = require the request to be JWT encoded. >=20 > The draft mentions the potential confusion around On-Behalf-Of vs. = Impersonation Semantics. And it is confusing (to me anyway). In fact, = the use of Act-As and On-Behalf-Of seem to be reversed from how they are = defined in WS-Trust (this MS FAQ has less confusing wording). They = should probably be aligned with that prior work to avoid further = confusion. Or maybe making a clean break and introducing new terms would = be better. >=20 > I don't think the security_token_request grant type value is strictly = legal per RFC 6749. The ABNF at = http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but = according to http://tools.ietf.org/html/rfc6749#section-4.5 extension = grants need an absolute URI as the grant type value (there's no grant = type registry so the URI is the only means of preventing collision). >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov = wrote: > Has anyone implemented the OAuth 2.0 Token exchange draft, in = particular > the on-behalf-of semantics? We've got a use case for that and I'm > curious if someone has used it in practice. >=20 > http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 >=20 > Thanks, >=20 > Vladimir > -- > Vladimir Dzhuvinov > Connect2id Ltd. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_666C73D8-6820-4038-97C6-2B1DF45D0FB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 This = is the first time this draft has come up on the list so people coming up = to speed is to be expected.

In WS-Trust the security = tokens are not tied to a single representation.  

/wst:RequestSecurityToken/wst14:ActAs

This OTPIONAL element indicates = that the requested token is expected to contain information about the = identity represented by the content of this element and the token = requestor intends to use the returned token to act as this identity. The = identity that the requestor wants to act-as is specified by placing a = security token or <wsse:SecurityTokenReference> element within the = <wst14:ActAs> element.


Is clear that = the resulting token contains information about the identity represented = by the security token passed as the content of the ActAs element and = that the requester wants to act-as is that = identity.

Depending on the resulting security = token that may be represented differently.   Nothing explicitly = states that the identity of the requester is in the resulting token, = however when SAML tokens are used it typically is represented along with = the identity to act-as.   

OnBehalfOf = being older was treated as a proxy type request On-Behalf-Of the initial = subject resulting in a token for the Original subject that may have been = used by another party such as the requester.

So = Sec 1.3 may be trying to describe composite tokens vs single subject = tokens that may be beyond the scope of those token independent = parameters in WS-Trust.

It is probably fair to = say that from the way those parameters are implemented for SAML tokens = in many if not all STS the description seems = backwards.

Having something that describes how = the output token varies based on input for typical token types might = help make it more concrete for people.

John = B.

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

ActAs the returned token is expected to be = represented by the identity described by this = parameter
OnBehalfOf the request is being made by the identity = described by this parameter
These terms have been pretty clearly defined in the = WS specifications, I don=92t understand the confusion. If section 1.3 is = confusing, I=92m OK with dropping this
 
From: OAuth [mailto:oauth-bounces@ietf.org]<= span class=3D"Apple-converted-space"> On Behalf Of John = Bradley
Sent: Thursday, July 3, 2014 2:44 = PM
To: Phil = Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = draft-jones-oauth-token-exchange-00
 
I pointed out a problem with the non normative text = in sec 1.3 to Mike off list quite a while = go.
 

1.3.  On-Behalf-Of vs. Impersonation = Semantics

 
 
   When principal A =
acts on behalf of principal B, A is given all =
the
   rights that B has =
within some defined rights context.  Whereas, =
with
   on-behalf-of =
semantics, principal A still has its own =
identity
   separate from B =
and it is explicitly understood that while B may =
have
   delegated its =
rights to A, any actions taken are being taken by A and  =
 
   not B. In a =
sense, A is an agent for B.
   On-behalf-of semantics are therefore different than =
impersonation
   semantics, with which it is sometimes =
confused.  When principal A
   impersonates principal B, then in so far as any =
entity receiving
   Claims is concerned, they are actually dealing with =
B. It is true
   that some members of the identity system might have =
awareness that
   impersonation is going on but it is not a =
requirement.  For all
   intents and purposes, when A is acting for B, A is =
B.
 
OnBehalfOf  "indicates that the requestor is making the request = on behalf of another." and returns a security token to the requestor = that contains a single set of = claims.
 
ActAs = provides a security token/ assertion about subject A in a request from = Requester B and the response is a composite token that has Requester B = as the subject but also includes claims about subject = A.
 
See MS FAQ to = clarify this  popular question http://msdn.microsoft.com/en-us/library/ee748487.aspx=
 
I think this = is what Brian was trying to get = at. 
 
If we can't = all agree on the semantics of OnBehalfOf (It has been around = for a long time) then we have a problem and should = pick different terms.
 
The normative text is correct, however sec 2.2 adds = an optional "actor" claim to the initial JWT that is to be presented as = the value of  on_behalf_of in the request.  That is an = addition to the WS-Trust text and took me several reads to understand = that it is not a element in the JWT = response. 
 
I = offered to help with the spec as I think it is useful.  The = semantics are tricky for people to understand so I was not all that = concerned that the first draft was not perfect. =  
 
I = suspect some concrete examples will = help.
 
John = B.
 
On Jul 3, 2014, at 3:51 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:


I suspect it lines up. But = Brian=92s point may still be relevant. There is *long* standing = confusion of the terms (because many of have different english = interpretation than WS-Trust). Might be time for new = terms?
 
Impersonate (or even personate) vs. delegate = ?
 
Those = terms differentiate between impersonating a whole person vs. having = delegate or scoped authority to act for = someone.
 
Sorry if = this is an old discussion.
 
 
On Jul 3, = 2014, at 12:20 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:


I=92m lost too, as when I = wrote this, I explicitly modelled it after WS-Trust.  If there=92s = a concrete discrepancy you can point out, that would be = great.
 
FYI, I do plan to refresh = this draft too allow for a more flexible trust model = shortly.
 
           &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp;   -- Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony = Nadalin
Sent: Thursday, July 03, 2014 = 12:04 PM
To: Brian = Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = draft-jones-oauth-token-exchange-00
 
I=92m lost, the terms = defined in the oauth token-exchange draft are the same terms defined in = ws-trust and have the same = definitions
 
From: Brian Campbell [mailto:bcampbell@pingidentity.com] 
Sent: Thursday, July 3, 2014 = 12:02 PM
To: Anthony = Nadalin
Cc: Vladimir Dzhuvinov; oauth@ietf.org
Subject: Re: [OAUTH-WG] = draft-jones-oauth-token-exchange-00
 
And I was suggesting that OAuth token exchange align = with the WS-Trust definitions or maybe even define totally new terms. = But not use the same terms to mean different = things.

 

On = Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin <tonynad@microsoft.com> = wrote:
The explanation of on-behalf-Of and ActAs are correct = in the document as defined by WS-Trust, this may not be your desire or = understanding but that is how WS-Trust implementations should = work
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian = Campbell
Sent: Thursday, July 3, 2014 = 11:44 AM
To: Vladimir = Dzhuvinov
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = draft-jones-oauth-token-exchange-00
 

FWIW, I am very interested in = the general concept of a lightweight or OAuth based token exchange = mechanism. However, despite some distaste for the protocol, our existing = WS-Trust functionality has proven to be "good enough" for most = use-cases, which seems to prevent work on token exchange from getting = any real priority.

I have a few thoughts on http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've = been meaning to write down but haven't yet, so this seems like as good a = time as any.

I = would really like to see a simpler request model that doesn't require = the request to be JWT encoded.

The draft mentions the potential confusion around = On-Behalf-Of vs. Impersonation Semantics. And it is confusing (to me = anyway). In fact, the use of Act-As and On-Behalf-Of seem to be reversed = from how they are defined in WS-Trust (this MS FAQ has less confusing = wording). They should probably be aligned with that prior work to avoid = further confusion. Or maybe making a clean break and introducing new = terms would be better.

I don't think the security_token_request grant type value is = strictly legal per RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but = according to http://tools.ietf.org/html/rfc6749#section-4.5 extension grants need an = absolute URI as the grant type value (there's no grant type registry so = the URI is the only means of preventing = collision).


 

 

 

 

On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> = wrote:
Has anyone implemented the OAuth = 2.0 Token exchange draft, in particular
the on-behalf-of semantics? = We've got a use case for that and I'm
curious if someone has used it = in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov <vladimir@connect2id.com>
Connect2id = Ltd.

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
<= /blockquote>
 
_______________________________________________
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=_666C73D8-6820-4038-97C6-2B1DF45D0FB9-- From nobody Thu Jul 3 17:10:20 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA45C1B2AA8 for ; Thu, 3 Jul 2014 17:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtEwNNlVgsOg for ; Thu, 3 Jul 2014 17:10:17 -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 15E131B2B3D for ; Thu, 3 Jul 2014 17:10:16 -0700 (PDT) X-AuditID: 12074424-f79146d00000067c-d3-53b5f0e783fb Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id CA.66.01660.7E0F5B35; Thu, 3 Jul 2014 20:10:15 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s640AEhE016430 for ; Thu, 3 Jul 2014 20:10:14 -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 s640ACOP022754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 3 Jul 2014 20:10:13 -0400 From: Justin Richer Content-Type: multipart/signed; boundary="Apple-Mail=_10431DB6-63C0-4DF4-9FAF-6FB3C6858992"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <62234E5D-2924-4CF4-BA23-42460C585FD9@mit.edu> Date: Thu, 3 Jul 2014 20:10:10 -0400 To: IETF oauth WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IR4hRV1n3+YWuwwZZXbBYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRuvLjYwFU7grln99x9LA+I2zi5GTQ0LARKKvcRcLhC0mceHe erYuRi4OIYHZTBIfTy1ghXCOMko83rUNKvOWSeLxjAPsIC1sAqoS81feYgJJMAtMYpRYv6EX LCEsoCZxo6uVFcTmFbCS+DHjHlA3BweLgIrE13eiIGERASWJP6sms0OUGEhc61/PCHGGvMSM 9hPsExh5ZyEbOwtJHYjNLKAtsWzha2YI20DiaecrVghbXmL72zlQcUuJxTNvsEDYthK3+hYw Qdh2Eo+mLWJdwMixilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdcLzezRC81pXQTIyiQ2V1UdjA2 H1I6xCjAwajEw+tRtDVYiDWxrLgy9xCjJAeTkijvs2tAIb6k/JTKjMTijPii0pzU4kOMKkC7 Hm1YfYFRiiUvPy9VSYR3xQOgOt6UxMqq1KJ8mDJpDhYlcd631lbBQgLpiSWp2ampBalFMFkZ Dg4lCd7i90CNgkWp6akVaZk5JQhpJg7OQ4wSHDxAw5tAaniLCxJzizPTIfKnGBWlxHlFQBIC IImM0jy4XlgCesUoDvSWMK8xSBUPMHnBdb8CGswENJiNCWxwSSJCSqqBUe+m46Pvl8J9X362 EalV8r+9r2ldmmbThKOFOj3XS+T/aPzkydN9W3TGYsHyP1I3GzhSL+5g+1d7Zobptq2h2s80 ZJ2711zI3yx22rRVu9wm+pH7ixWPL4Xd/n7aQWGfsG6M2Mdty+okFhsf67FhPNO6SGpqR0py g69Z/mRJe/VDT+cE133arMRSnJFoqMVcVJwIACp9SCEbAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ujmaNlOXDiylZkwsTfFlgUGPxm4 Subject: [OAUTH-WG] New Token Introspection Draft 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, 04 Jul 2014 00:10:18 -0000 --Apple-Mail=_10431DB6-63C0-4DF4-9FAF-6FB3C6858992 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92ve updated the token introspection draft with the intention that = this document become input for a new working group item. http://tools.ietf.org/html/draft-richer-oauth-introspection-05 The changes are mostly minimal edits to the text and a few reference = fixes. One bigger change is the addition of the =93user_id=94 field in = addition to the =93sub=94 field, as I=92ve been asked by some users to = add that feature to our own implementation here. =97 Justin --Apple-Mail=_10431DB6-63C0-4DF4-9FAF-6FB3C6858992 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTtfDjAAoJEDPAngkbd+w9FrQIAK0VGh2Smuzts/CnWenQwg3M sLs2uwwcNfGaFISRItNir+7mN54xPafANsVRSMkq8oTZNYBj7Okz/lI0oPiuMLoV HNpoOM2EaUqwxLQCnJbJVRVogX/JWoZc5qv47ZuY7oij9T3HNl6S0BqIkfqRR0Y3 gaQsKjuk97gNFsR5ndnl5fGSNO1T9B0+OEbSAxQ9DwO+YdqnBE+xacLhSrUultyk LxnJBJxMa7luac84J5+uy9UdpjTl+1Owmn3tZPI84eSSZKGi86mjsgP7fcNFBUnx J6VOZR7pP8QOzCeQLvfNNshePtw6qenRJONfKhzTa3EmdPjqDPLzrADjWMmEtBg= =yxuN -----END PGP SIGNATURE----- --Apple-Mail=_10431DB6-63C0-4DF4-9FAF-6FB3C6858992-- From nobody Thu Jul 3 22:42:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C931B2BE8 for ; Thu, 3 Jul 2014 22:42:33 -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 v--b_0y8Z1zY for ; Thu, 3 Jul 2014 22:42:31 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3689F1B2BE1 for ; Thu, 3 Jul 2014 22:42:31 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id b8so838742lan.12 for ; Thu, 03 Jul 2014 22:42:29 -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=qDtavqJruFinry5OYbvjdYxU6qhc6E+a8RnidGcyHJI=; b=TOCISG9LZ8LQHqs2F0bqK07SUXt3MDYkKSJTBg+tPUDLr/bhfdmFKGjb+4Z7jo4Npt udg98ZoB2+1FcaaYrT/zDbV9EPE8o589PnIGicXkXRfLvVvNZZjd1nrtY7Z3wLqAt6yG I6uMeTVXQHW0xRtITS/mNZALqSdFi9GewX/VrRxyWQ2BkNjxuEH1S+XVUQU1lx1GUdy6 DmQPN/F690WAlVqZgoH4kdaVtudmMyeM0Zwmktm/ylj0Mqa5iwe9H4uO5dKcgiZXX9qG YWOg/w70plBuUE3kpju/nCyc4Oll+D7p7q2U4WBl8H9ugsP10Qw5Az6TkUrNyD+0SskU sBNg== MIME-Version: 1.0 X-Received: by 10.112.134.97 with SMTP id pj1mr6497946lbb.9.1404452549354; Thu, 03 Jul 2014 22:42:29 -0700 (PDT) Received: by 10.152.178.165 with HTTP; Thu, 3 Jul 2014 22:42:28 -0700 (PDT) Received: by 10.152.178.165 with HTTP; Thu, 3 Jul 2014 22:42:28 -0700 (PDT) In-Reply-To: <62234E5D-2924-4CF4-BA23-42460C585FD9@mit.edu> References: <62234E5D-2924-4CF4-BA23-42460C585FD9@mit.edu> Date: Fri, 4 Jul 2014 07:42:28 +0200 Message-ID: From: Thomas Broyer To: Justin Richer Content-Type: multipart/alternative; boundary=047d7b3a8ace4eecbb04fd5797b4 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/mKSNl0PlxGChkR1KEjxs66FUp3s Cc: "" Subject: Re: [OAUTH-WG] New Token Introspection Draft 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, 04 Jul 2014 05:42:33 -0000 --047d7b3a8ace4eecbb04fd5797b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I thought someone mentioned it already: in the example you might want to send the request to /introspect instead of /register. It would be good to see user_id returned in the example too to get a better sense of what it really means (as I understand it, it's the username the user uses to sign in along with his password) Le 4 juil. 2014 02:10, "Justin Richer" a =C3=A9crit : > I=E2=80=99ve updated the token introspection draft with the intention tha= t this > document become input for a new working group item. > > http://tools.ietf.org/html/draft-richer-oauth-introspection-05 > > The changes are mostly minimal edits to the text and a few reference > fixes. One bigger change is the addition of the =E2=80=9Cuser_id=E2=80=9D= field in addition > to the =E2=80=9Csub=E2=80=9D field, as I=E2=80=99ve been asked by some us= ers to add that feature to > our own implementation here. > > =E2=80=94 Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --047d7b3a8ace4eecbb04fd5797b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I thought someone mentioned it already: in the example you m= ight want to send the request to /introspect instead of /register. It would= be good to see user_id returned in the example too to get a better sense o= f what it really means (as I understand it, it's the username the user = uses to sign in along with his password)

Le 4 juil. 2014 02:10, "Justin Richer"= <jricher@mit.edu> a =C3=A9cri= t :
I=E2=80=99ve updated the token introspection draft with the intention that = this document become input for a new working group item.

http://tools.ietf.org/html/draft-richer-oauth-introspecti= on-05

The changes are mostly minimal edits to the text and a few reference fixes.= One bigger change is the addition of the =E2=80=9Cuser_id=E2=80=9D field i= n addition to the =E2=80=9Csub=E2=80=9D field, as I=E2=80=99ve been asked b= y some users to add that feature to our own implementation here.

=C2=A0=E2=80=94 Justin

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

--047d7b3a8ace4eecbb04fd5797b4-- From nobody Fri Jul 4 03:15:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AEA1A0ABF for ; Fri, 4 Jul 2014 03:15:26 -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 dciiZQwH9dO3 for ; Fri, 4 Jul 2014 03:15:25 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9BF1B2CDA for ; Fri, 4 Jul 2014 03:15:24 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y10so1762824pdj.5 for ; Fri, 04 Jul 2014 03:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J2gwxycuq1joHLGyIo7iSd24MnGAuY9wYtfz154Sf8c=; b=cH5oW/l31OhhPvuaWbbu2yObZrWNwH+zzaRPGI7KTbhgg/wv9mbG3/rQNXC0VJuU5P 23tbY4L6LpuvotymKV5q5wLWbQOjl85hvuqYuy+jdp7Zay/8ZHZr2Wzc4+7rxohXWJds Ju/VbHUGlHauuCA6bnkSiL9dnNmkHsHRTDKaLN+aAmrd0YEMdtuWgX/x4gh3HEx1gzba uOoCvR8eAV36dcHEfCmTKLWz3yCJDl/m+2BzDtCVV6vvAhaXC+eoIqiN397c4mz/IBRP qGM4PtyWd+V7DAIm0mEOkK3D8mLkUJz2L7WkE2Vmq6QghiuH7/gcz5ukiMnix5hoWH/3 mbQg== X-Received: by 10.70.130.227 with SMTP id oh3mr9485640pdb.55.1404468923717; Fri, 04 Jul 2014 03:15:23 -0700 (PDT) Received: from [10.3.38.43] (pw126205012152.3.panda-world.ne.jp. [126.205.12.152]) by mx.google.com with ESMTPSA id xs2sm153588276pab.0.2014.07.04.03.15.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Jul 2014 03:15:21 -0700 (PDT) Content-Type: text/plain; charset=shift_jis Mime-Version: 1.0 (1.0) From: Nat Sakimura X-Mailer: iPhone Mail (11D201) In-Reply-To: <62234E5D-2924-4CF4-BA23-42460C585FD9@mit.edu> Date: Fri, 4 Jul 2014 19:15:23 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7830235A-F2B8-4D47-B58B-6FF351A3E421@gmail.com> References: <62234E5D-2924-4CF4-BA23-42460C585FD9@mit.edu> To: Justin Richer Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DnqDqWulfAJKZ7p7m6dEePGGKYE Cc: IETF oauth WG Subject: Re: [OAUTH-WG] New Token Introspection Draft 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, 04 Jul 2014 10:15:26 -0000 Thanks Justin.=20 Is there any reason that there is no iss claim returned?=20 =3Dnat via iPhone > On Jul 4, 2014, at 9:10, Justin Richer wrote: >=20 > I=81fve updated the token introspection draft with the intention that this= document become input for a new working group item. >=20 > http://tools.ietf.org/html/draft-richer-oauth-introspection-05 >=20 > The changes are mostly minimal edits to the text and a few reference fixes= . One bigger change is the addition of the =81guser_id=81h field in addition= to the =81gsub=81h field, as I=81fve been asked by some users to add that f= eature to our own implementation here. >=20 > =81\ Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Jul 4 04:46:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755071B2844 for ; Fri, 4 Jul 2014 04:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhZ3Av6VzuMa for ; Fri, 4 Jul 2014 04:46:14 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45E31B283B for ; Fri, 4 Jul 2014 04:46:13 -0700 (PDT) X-AuditID: 12074425-f79766d000006da8-2e-53b694045ced Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 4D.A1.28072.40496B35; Fri, 4 Jul 2014 07:46:12 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s64BkBLs025796; Fri, 4 Jul 2014 07:46:12 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s64Bk9wn011806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Jul 2014 07:46:11 -0400 Message-ID: <53B693F3.5090001@mit.edu> Date: Fri, 04 Jul 2014 07:45:55 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Thomas Broyer References: <62234E5D-2924-4CF4-BA23-42460C585FD9@mit.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020508080507030601010603" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixCmqrMsyZVuwwc+l8hYn375iszj+7yKz A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJUxbdZf5oL9ShXLprcwNzB2SnUxcnJICJhI vDn0lRHCFpO4cG89WxcjF4eQwGwmie0nF0I5Gxgl/m7dwgLh3GKS2Hn/ADNIC6+AmsTsBXvY QWwWAVWJa69/M4HYbED2/JW3wGxRgSiJO5f6WSHqBSVOznzCAmKLAPXefLcRbDWzgLpE7++V YDXCAqYSKw43A9kcQMvqJVp+2IOEOQUCJf5+PMwKUR4m0fPzHfsERoFZSKbOQpKCsM0kurZ2 MULY8hLNW2czQ9hqEre3XWVHFl/AyLaKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10IvN7NELzWl dBMjKODZXVR3ME44pHSIUYCDUYmH16Noa7AQa2JZcWXuIUZJDiYlUd64nm3BQnxJ+SmVGYnF GfFFpTmpxYcYJTiYlUR4D/QB5XhTEiurUovyYVLSHCxK4rxvra2ChQTSE0tSs1NTC1KLYLIy HBxKErzuk4EaBYtS01Mr0jJzShDSTBycIMN5gIbXg9TwFhck5hZnpkPkTzEqSonzHpkElBAA SWSU5sH1whLSK0ZxoFeEeT1B2nmAyQyu+xXQYCagwWxMW0EGlyQipKQaGAvWtz9xuMNw7FOF nbaXyO6r81p/9+1e0fcs83CU8KL2EnZ5tzvHTaWiJjXuqv72S+349T9r7/3Viv29uar0ft6G 03YrPn5sbFn5zm7nZ/8lb+SutclOVL217n7ohDmPPXm3zarezLezUNmgQOjovEcTO90qa2dP vMrOu8KJXWfi95kfkrtvnFynxFKckWioxVxUnAgA5kdCZyMDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ztudXz0ELkIAc7tMTpsKBTr69OQ Cc: "" Subject: Re: [OAUTH-WG] New Token Introspection Draft 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, 04 Jul 2014 11:46:15 -0000 This is a multi-part message in MIME format. --------------020508080507030601010603 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Argh, good catch. Not sure how I missed that one again. At least it's not telling you to revoke tokens anymore. :) Also, good call on the user_id in the example. Thanks, -- Justin On 7/4/2014 1:42 AM, Thomas Broyer wrote: > > I thought someone mentioned it already: in the example you might want > to send the request to /introspect instead of /register. It would be > good to see user_id returned in the example too to get a better sense > of what it really means (as I understand it, it's the username the > user uses to sign in along with his password) > > Le 4 juil. 2014 02:10, "Justin Richer" > a écrit : > > I’ve updated the token introspection draft with the intention that > this document become input for a new working group item. > > http://tools.ietf.org/html/draft-richer-oauth-introspection-05 > > The changes are mostly minimal edits to the text and a few > reference fixes. One bigger change is the addition of the > “user_id†field in addition to the “sub†field, as I’ve been asked > by some users to add that feature to our own implementation here. > > — Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------020508080507030601010603 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Argh, good catch. Not sure how I missed that one again. At least it's not telling you to revoke tokens anymore. :)

Also, good call on the user_id in the example.

Thanks,
 -- Justin

On 7/4/2014 1:42 AM, Thomas Broyer wrote:

I thought someone mentioned it already: in the example you might want to send the request to /introspect instead of /register. It would be good to see user_id returned in the example too to get a better sense of what it really means (as I understand it, it's the username the user uses to sign in along with his password)

Le 4 juil. 2014 02:10, "Justin Richer" <jricher@mit.edu> a écrit :
I’ve updated the token introspection draft with the intention that this document become input for a new working group item.

http://tools.ietf.org/html/draft-richer-oauth-introspection-05

The changes are mostly minimal edits to the text and a few reference fixes. One bigger change is the addition of the “user_id†field in addition to the “sub†field, as I’ve been asked by some users to add that feature to our own implementation here.

 — Justin

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


--------------020508080507030601010603-- From nobody Fri Jul 4 04:51:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3661B2864 for ; Fri, 4 Jul 2014 04:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR9vFefP3Qav for ; Fri, 4 Jul 2014 04:51:11 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C717E1B2846 for ; Fri, 4 Jul 2014 04:51:10 -0700 (PDT) X-AuditID: 12074425-f79766d000006da8-33-53b6952d95d9 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 45.C1.28072.D2596B35; Fri, 4 Jul 2014 07:51:09 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s64Bp92M026067 for ; Fri, 4 Jul 2014 07:51:09 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s64Bp7BO012884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 4 Jul 2014 07:51:09 -0400 Message-ID: <53B6951D.6090608@mit.edu> Date: Fri, 04 Jul 2014 07:50:53 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: OAuth WG References: <53B694FA.6040407@mit.edu> In-Reply-To: <53B694FA.6040407@mit.edu> X-Forwarded-Message-Id: <53B694FA.6040407@mit.edu> Content-Type: multipart/alternative; boundary="------------000605020105080407070707" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IR4hRV1tWdui3YYP4PY4uTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEro/3QR5aCXp2Ke+8+MTUwLlDuYuTkkBAwkWg4/pIFwhaTuHBv PVsXIxeHkMBsJon5G39DOUcZJTralzFDOO+ZJM63vGYCaeEVUJM41X2UHcRmEVCVuHnkOiuI zQZkz195C6xGVCBK4s6lflaIekGJkzOfgK0TEZCVmH9pK5gtLGAl8XrlZ8YuRg6gBWoSS2+A lXMKqEvsb/3GDnGdkcTCVY8YQWxmgTCJqZfXMU9gFJiFZOosJCkIW1vi3JYzUHF5ieats6Hi WhJ7f69jRxZfwMi2ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdCLzezRC81pXQTIyi42V1UdzBO OKR0iFGAg1GJh9ejaGuwEGtiWXFl7iFGSQ4mJVHeuJ5twUJ8SfkplRmJxRnxRaU5qcWHGCU4 mJVEeA/0AeV4UxIrq1KL8mFS0hwsSuK8b62tgoUE0hNLUrNTUwtSi2CyMhwcShK8OVOAGgWL UtNTK9Iyc0oQ0kwcnCDDeYCGm4DU8BYXJOYWZ6ZD5E8xKkqJ84qBJARAEhmleXC9sOTzilEc 6BVh3nKQKh5g4oLrfgU0mAloMBvTVpDBJYkIKakGRuVHu5952wiyPnkoHbD6t8EJnvLfFt5m Mk+mqxsoe77+NlvcPey9EOulD6kzV6x4GJ7WGcKnemVi1QSR/uWHVL56J143sLW+XxAucOEx w6X3lQLRXSaTX5vN3fnyqYziLK4NRsenq+W+L5hkx54lvaNtgazrwgD+IiaBCUFBDzo7znaI fj/4QomlOCPRUIu5qDgRAC1eK0QZAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wRsAJ_rRiv5CMez8SWgEVnjbfOM Subject: [OAUTH-WG] Fwd: Re: New Token Introspection Draft 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, 04 Jul 2014 11:51:12 -0000 This is a multi-part message in MIME format. --------------000605020105080407070707 Content-Type: text/plain; charset=Shift_JIS Content-Transfer-Encoding: 8bit And now with the list copied... -------- Original Message -------- Subject: Re: [OAUTH-WG] New Token Introspection Draft Date: Fri, 04 Jul 2014 07:50:18 -0400 From: Justin Richer To: Nat Sakimura Interesting question. In my mental model of how this works, you're asking the same AS that issued the token, so the "iss" is kindof a given if the token is valid. Would there be a use for the server echoing that back explicitly? Would people be using an introspection server that can handle multiple issuers? I'm not against adding it, I simply didn't see a use for it. Another data point: In our deployments of this, we're actually sending out JWT formatted tokens that contain "iss" and a couple other fields. The clients who care to do so check the "iss" field and the signature themselves, but use introspection to find out which user this token was issued to, what scopes it has, and all that detailed info. Some RS's need it, some don't care. -- Justin On 7/4/2014 6:15 AM, Nat Sakimura wrote: > Thanks Justin. > > Is there any reason that there is no iss claim returned? > > =nat via iPhone > >> On Jul 4, 2014, at 9:10, Justin Richer wrote: >> >> Ifve updated the token introspection draft with the intention that this document become input for a new working group item. >> >> http://tools.ietf.org/html/draft-richer-oauth-introspection-05 >> >> The changes are mostly minimal edits to the text and a few reference fixes. One bigger change is the addition of the guser_idh field in addition to the gsubh field, as Ifve been asked by some users to add that feature to our own implementation here. >> >> \ Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --------------000605020105080407070707 Content-Type: text/html; charset=Shift_JIS Content-Transfer-Encoding: 8bit And now with the list copied...


-------- Original Message --------
Subject: Re: [OAUTH-WG] New Token Introspection Draft
Date: Fri, 04 Jul 2014 07:50:18 -0400
From: Justin Richer <jricher@mit.edu>
To: Nat Sakimura <sakimura@gmail.com> 


Interesting question. In my mental model of how this works, you're
asking the same AS that issued the token, so the "iss" is kindof a given
if the token is valid. Would there be a use for the server echoing that
back explicitly? Would people be using an introspection server that can
handle multiple issuers? I'm not against adding it, I simply didn't see
a use for it.

Another data point: In our deployments of this, we're actually sending
out JWT formatted tokens that contain "iss" and a couple other fields.
The clients who care to do so check the "iss" field and the signature
themselves, but use introspection to find out which user this token was
issued to, what scopes it has, and all that detailed info. Some RS's
need it, some don't care.

-- Justin

On 7/4/2014 6:15 AM, Nat Sakimura wrote:
> Thanks Justin. 
>
> Is there any reason that there is no iss claim returned? 
>
> =nat via iPhone
>
>> On Jul 4, 2014, at 9:10, Justin Richer <jricher@MIT.EDU> wrote:
>>
>> Ifve updated the token introspection draft with the intention that this document become input for a new working group item.
>>
>> http://tools.ietf.org/html/draft-richer-oauth-introspection-05
>>
>> The changes are mostly minimal edits to the text and a few reference fixes. One bigger change is the addition of the guser_idh field in addition to the gsubh field, as Ifve been asked by some users to add that feature to our own implementation here.
>>
>> \ Justin
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


--------------000605020105080407070707-- From nobody Fri Jul 4 08:28:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6013B1B2850 for ; Fri, 4 Jul 2014 08:28:05 -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 J0t_YYQ_vMQm for ; Fri, 4 Jul 2014 08:28:02 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7AD1B29EC for ; Fri, 4 Jul 2014 08:28:02 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y10so2113160pdj.33 for ; Fri, 04 Jul 2014 08:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+rhD2Qkx2led/yqFzU0cjl2U4Mxs4vDX/7+R5ywmPNE=; b=ZZiusSpZ4dCHQJeUAGki84/JsxeZwB/whSv9uJALTnhnAQXxfyr4f31q0OahrTUu4c 26zt0ua6VDnH3d95JwYG8ld8YcDMEu0LFAPY+Os0QCd62CztVGUEYM+F6rs4o5Fcmh5O SwiCOipLjc1dLuGvGirKpAJ5iCvHO7caGikceO7o5YSA92nlZ8ANYm4rKAXU3ApimwLb XMEBSFHj4+R/8PZ8NSnpUFNNpLwv3J8O5w6t3uIf+23GnESd67Hr8tDTkQ0FvXzzpjfs ESs7LV9+0AI8DjaNZjTjE9Osyqv4BxnBJfvzkB5LvnV+b2PlbAWN7YPGqS78w7Skntqa HZBQ== X-Received: by 10.70.46.129 with SMTP id v1mr2140114pdm.150.1404487682577; Fri, 04 Jul 2014 08:28:02 -0700 (PDT) Received: from [192.168.1.9] (v036103.dynamic.ppp.asahi-net.or.jp. [124.155.36.103]) by mx.google.com with ESMTPSA id nf5sm42274085pbc.77.2014.07.04.08.28.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Jul 2014 08:28:00 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-6627296E-39E6-4A7E-B61F-7A8613B43CE2 Mime-Version: 1.0 (1.0) From: Nat Sakimura X-Mailer: iPhone Mail (11D201) In-Reply-To: <53B4CA95.3020702@mit.edu> Date: Sat, 5 Jul 2014 00:27:56 +0900 Content-Transfer-Encoding: 7bit Message-Id: <80DA6959-8A9A-4290-B66C-FC1CAAF1A4FB@gmail.com> References: <53B41202.8080008@gmx.net> <53B4CA95.3020702@mit.edu> To: Justin Richer Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/iD__wgO9T8XVcqQ7TkvSuow-i6k Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Agenda requests, please 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, 04 Jul 2014 15:28:05 -0000 --Apple-Mail-6627296E-39E6-4A7E-B61F-7A8613B43CE2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I would like to bring up the request by JWS draft http://tools.ietf.org/html= /draft-sakimura-oauth-requrl-05 and Symmetric PoP draft http://tools.ietf.or= g/html/draft-sakimura-oauth-tcse-03.=20 =3Dnat via iPhone > On Jul 3, 2014, at 12:14, Justin Richer wrote: >=20 > Mike is working on editorial updates to the Dynamic Registration core draf= t, and I and the other editors plan to review the changes soon and we'll get= an updated draft published before the deadline this week. >=20 > I will publish a refreshed Token Introspection individual submission ID fo= r input into the WG discussion before the deadline, and I would like to see t= his become a WG item. It's already been in deployment with a number of imple= mentations for some time now, and I'm seeing only increasing demand for it. >=20 > I do not agree that we should drop the Dynamic Registration Management dra= ft from the WG items list.=20 >=20 > -- Justin >=20 >> On 7/2/2014 10:06 AM, Hannes Tschofenig wrote: >> Hi all, >>=20 >> by next Monday we have to post a draft agenda for the upcoming IETF >> meeting. >>=20 >> If you would like to talk about a specific topic, please let us know. >>=20 >> My impression regarding the status of our work is the following: >>=20 >>=20 >> -------- Current WG items ------- >>=20 >> * Dynamic Client Registration >>=20 >> We are waiting for an update but the document could be completed by the >> IETF meeting. =3D=3D> no presentation time. >>=20 >> * JWT >>=20 >> Currently in IESG processing and a new draft update has just been >> submitted. =3D=3D> no presentation time (#) >>=20 >> * Assertion Bundle >>=20 >> Currently in IESG processing. =3D=3D> no presentation time (#) >>=20 >> * Dynamic Client Registration Management Protocol >>=20 >> We had a discussion about this work at the last IETF meeting and the >> path forward looked somewhat difficult. Nothing has happened since that >> time and I am inclined to remove it from the list of WG items. >>=20 >> * Proof-of-Possession Security >>=20 >> We have several new documents and I hope we can turn into working group >> items already before the meeting. We would then use the meeting time to >> discuss open issues. >>=20 >> #: No presentation time unless some challenging comments from the IESG >> surface. >>=20 >> -------- Proposed New WG items ------- >>=20 >> I would also like to put the following items on the agenda. >>=20 >> * Token Introspection >>=20 >> * draft-sakimura-oauth-tcse-03=09 >>=20 >> -------- Other items ------- >>=20 >> Phil might want to bring up this item since it was discussed on the >> list: draft-hunt-oauth-v2-user-a4c >>=20 >> Other ideas/suggestions? >>=20 >> Ciao >> Hannes >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-6627296E-39E6-4A7E-B61F-7A8613B43CE2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I would like to bring up the request by JWS draft http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05 and Symmetric PoP draft http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03. 

=nat via iPhone

On Jul 3, 2014, at 12:14, Justin Richer <jricher@MIT.EDU> wrote:

Mike is working on editorial updates to the Dynamic Registration core draft, and I and the other editors plan to review the changes soon and we'll get an updated draft published before the deadline this week.

I will publish a refreshed Token Introspection individual submission ID for input into the WG discussion before the deadline, and I would like to see this become a WG item. It's already been in deployment with a number of implementations for some time now, and I'm seeing only increasing demand for it.

I do not agree that we should drop the Dynamic Registration Management draft from the WG items list.

 -- Justin

On 7/2/2014 10:06 AM, Hannes Tschofenig wrote:
Hi all,

by next Monday we have to post a draft agenda for the upcoming IETF
meeting.

If you would like to talk about a specific topic, please let us know.

My impression regarding the status of our work is the following:


-------- Current WG items -------

* Dynamic Client Registration

We are waiting for an update but the document could be completed by the
IETF meeting. ==> no presentation time.

* JWT

Currently in IESG processing and a new draft update has just been
submitted. ==> no presentation time (#)

* Assertion Bundle

Currently in IESG processing. ==> no presentation time (#)

* Dynamic Client Registration Management Protocol

We had a discussion about this work at the last IETF meeting and the
path forward looked somewhat difficult. Nothing has happened since that
time and I am inclined to remove it from the list of WG items.

* Proof-of-Possession Security

We have several new documents and I hope we can turn into working group
items already before the meeting. We would then use the meeting time to
discuss open issues.

#: No presentation time unless some challenging comments from the IESG
surface.

-------- Proposed New WG items -------

I would also like to put the following items on the agenda.

* Token Introspection

* draft-sakimura-oauth-tcse-03	

-------- Other items -------

Phil might want to bring up this item since it was discussed on the
list: draft-hunt-oauth-v2-user-a4c

Other ideas/suggestions?

Ciao
Hannes




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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--Apple-Mail-6627296E-39E6-4A7E-B61F-7A8613B43CE2-- From nobody Fri Jul 4 09:13:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D1E1B2B05 for ; Fri, 4 Jul 2014 09:13:16 -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 iNJC8J1IdfKj for ; Fri, 4 Jul 2014 09:13:13 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1051A004B for ; Fri, 4 Jul 2014 09:13:12 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id ty20so1321530lab.3 for ; Fri, 04 Jul 2014 09:13:10 -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=7AHVHYJmw6yhkeceYUAxNqrk4qPiUsAN51SImz7+lIU=; b=yQYrvL0aq3iaGc1r3LhkRFeXyJRfBvnWcylk+IzezNALQxb8y0DNzeYhe4HA6SSYT5 GGal7RE9tImmdImYO6fuSY3icfVZN+DpJ9g1s11aDaSVw93w0HWmsk/nLkfRt2wU5+we aPGYc9Yl29fh5y9uTBkIGbFb7OCKfS+JJop/+TN8BX+CeS9pvmpw9LTE/UmHPLVlF8JS Wi/M45d5/vRBwpj16Lg2bJ1XC+1S0kvH53PXLC6J72eXRCsJgy0UpN4PHiRJfS4nl2uv XT7xSv7Q5jMVRBIUVFKe0m2LYptuKjQ2eInJm5kU8LrL9N2+LF6KI2ZK6r0XZbQci6TP XuyA== MIME-Version: 1.0 X-Received: by 10.112.56.233 with SMTP id d9mr2982105lbq.55.1404490390856; Fri, 04 Jul 2014 09:13:10 -0700 (PDT) Received: by 10.112.23.33 with HTTP; Fri, 4 Jul 2014 09:13:10 -0700 (PDT) In-Reply-To: <20140704160244.27486.67585.idtracker@ietfa.amsl.com> References: <20140704160244.27486.67585.idtracker@ietfa.amsl.com> Date: Sat, 5 Jul 2014 01:13:10 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=001a1133aa1cd66cd504fd6066fe Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3HEsgtUUZstNcFARHluBSlzXJIQ Subject: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-rjwtprof-02.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: Fri, 04 Jul 2014 16:13:16 -0000 --001a1133aa1cd66cd504fd6066fe Content-Type: text/plain; charset=UTF-8 FYI. An extremely simplistic approach to provide somewhat better protection than Bearer. I came up with the draft during IETF 88 at the Starback in the lobby with Tony. As such, it actually predates http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-00. Since I would like to discuss if all the functional requirements in this draft has been incorporated into http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01, I have refreshed the draft. Best, Nat ---------- Forwarded message ---------- From: Date: 2014-07-05 1:02 GMT+09:00 Subject: New Version Notification for draft-sakimura-oauth-rjwtprof-02.txt To: Nat Sakimura A new version of I-D, draft-sakimura-oauth-rjwtprof-02.txt has been successfully submitted by Nat Sakimura and posted to the IETF repository. Name: draft-sakimura-oauth-rjwtprof Revision: 02 Title: OAuth 2.0 Registered JWT Profile 1.0 Document date: 2014-07-04 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-sakimura-oauth-rjwtprof-02.txt Status: https://datatracker.ietf.org/doc/draft-sakimura-oauth-rjwtprof/ Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-rjwtprof-02 Abstract: This specification defines a profile of OAuth 2.0 framework that provides the holder of key facility for the compliant client. It achieves this without channel binding but solely based on the application protocol to make it easy for the client developers to develop such client. 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. The IETF Secretariat -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a1133aa1cd66cd504fd6066fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI. An extremely simplistic approach to provide somewhat = better protection than Bearer.=C2=A0
I came up with the draft during IE= TF 88 at the Starback in the lobby with Tony.=C2=A0
Since I would like to discuss if all the functional requirements in th= is draft has been incorporated into=C2=A0http://tools.ietf.org/html/dr= aft-jones-oauth-proof-of-possession-01, I have refreshed the draft.=C2= =A0

Best,=C2=A0

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2014-07-05 1:02 GMT+09:00
Subject: New Version Notification for dr= aft-sakimura-oauth-rjwtprof-02.txt
To: Nat Sakimura <sakimura@gmail.com>



A new version of I-D, draft-sakimura-oauth-rjwtprof-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-sakimura-oauth-rjwtprof
Revision: =C2=A0 =C2=A0 =C2=A0 02
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth 2.0 Registered JWT Profile 1= .0
Document date: =C2=A02014-07-04
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A08
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttp://www.ietf.org/internet-drafts/draft-sakimura-oauth-rjwtprof-02.txt=
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.= ietf.org/doc/draft-sakimura-oauth-rjwtprof/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/dr= aft-sakimura-oauth-rjwtprof-02
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.= ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-rjwtprof-02

Abstract:
=C2=A0 =C2=A0This specification defines a profile of OAuth 2.0 framework th= at
=C2=A0 =C2=A0provides the holder of key facility for the compliant client. = It
=C2=A0 =C2=A0achieves this without channel binding but solely based on the<= br> =C2=A0 =C2=A0application protocol to make it easy for the client developers= to
=C2=A0 =C2=A0develop such client.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a1133aa1cd66cd504fd6066fe-- From nobody Fri Jul 4 09:32:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E901B2DCD for ; Fri, 4 Jul 2014 09:32:10 -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 COaxkktyq1dF for ; Fri, 4 Jul 2014 09:32:09 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8DC31B2D8A for ; Fri, 4 Jul 2014 09:32:08 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id b8so1291815lan.26 for ; Fri, 04 Jul 2014 09:32:07 -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=onG/BkvLbMY9p9jr7/nlspdetDQDtLGXF8nMIMGwSoE=; b=FaQGR/EHFA5YqeDXYJFjRJvKwBqM2TJgoFo7Ff3yxur0NPJRfKqem6H0ZxMtAaJgv9 UmumiLdDFhWxkg/nT1Bq7yURKPkhX5TuuGFCzi4WUIF/JEftslYKNzjKnWaIpchKTCso 8nzq4Gfne8lLVM6L9C++SmkosBp6Mqhfl8wbUWTyQ0ldo3yajy9x9GY1PkHaVIvB0nhK G3i3+w0ogW2IuhqD15YYTWNqg14suAOm3fXrJ6oLoz14LJdip3a5qHEmOH4mWNGHGNqJ bvQaqyYfTdDnw8Rh/2+lmlBIeeUgbTCKaxsAxqdchOcT2Gl9El9KJZwkKT6kTgENJK19 TqMg== MIME-Version: 1.0 X-Received: by 10.152.20.2 with SMTP id j2mr1784420lae.78.1404491526913; Fri, 04 Jul 2014 09:32:06 -0700 (PDT) Received: by 10.112.23.33 with HTTP; Fri, 4 Jul 2014 09:32:06 -0700 (PDT) Date: Sat, 5 Jul 2014 01:32:06 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=089e013d17b88d449604fd60aaf1 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/hWUsD58QlGw6BScC3SuI5-b4rok Subject: [OAUTH-WG] New Version Notification for draft-sakimura-oauth-requrl-05.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: Fri, 04 Jul 2014 16:32:10 -0000 --089e013d17b88d449604fd60aaf1 Content-Type: text/plain; charset=UTF-8 A new version of I-D, draft-sakimura-oauth-requrl-05.txt has been successfully submitted by Nat Sakimura and posted to the IETF repository. Name: draft-sakimura-oauth-requrl Revision: 05 Title: Request by JWS ver.1.0 for OAuth 2.0 Document date: 2014-07-04 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-sakimura-oauth-requrl-05.txt Status: https://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-requrl-05 Abstract: The authorization request in OAuth 2.0 utilizes query parameter serizalization. This specification defines the authorization request using JWT serialization. The request is sent thorugh "request" parameter or by reference through "request_uri" parameter that points to the JWT, allowing the request to be optionally signed and encrypted. 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. -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e013d17b88d449604fd60aaf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A new version of I-D, draft-sakimura-o= auth-requrl-05.txt
has been successfully submitted by Nat Sakimur= a and posted to the
IETF repository.

Nam= e: draft-sakimura-oauth-= requrl
Revision: 05
Title: Request by JWS= ver.1.0 for OAuth 2.0
Document date: 2014-07-04
Group: Indivi= dual Submission
Pages:= 9
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/internet-drafts/draft-sakimura-oauth-requrl-05.txt=

Abstra= ct:
=C2=A0 =C2=A0The authorization request in OAuth 2.0 utilizes = query parameter
=C2=A0 =C2=A0serizalization. =C2=A0This specification defines the auth= orization request
=C2=A0 =C2=A0using JWT serialization. =C2=A0The= request is sent thorugh "request"
=C2=A0 =C2=A0paramet= er or by reference through "request_uri" parameter that points
=C2=A0 =C2=A0to the JWT, allowing the request to be optionally signed = and
=C2=A0 =C2=A0encrypted.

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

Please note that it may take a couple of minutes from t= he time of submission
until the htmlized version and diff are ava= ilable at tools.ietf.org.


--
Nat Sakimura (=3Dnat)
Chairman, OpenID = Foundation
http:/= /nat.sakimura.org/
@_nat_en
--089e013d17b88d449604fd60aaf1-- From nobody Fri Jul 4 15:38:45 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20941A016B; Fri, 4 Jul 2014 15:38:40 -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 6Wk6Y0R9VIzp; Fri, 4 Jul 2014 15:38:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0B71A017F; Fri, 4 Jul 2014 15:38:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704223838.27871.23006.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 15:38:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/dltg6xdBg1m_BJofUVm8AkS6i6A Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-25.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, 04 Jul 2014 22:38:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : JSON Web Token (JWT) Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-25.txt Pages : 32 Date : 2014-07-04 Abstract: JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. The suggested pronunciation of JWT is the same as the English word "jot". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-25 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 16:32:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AC51A01CB for ; Fri, 4 Jul 2014 16:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrWR_hLoiKBq for ; Fri, 4 Jul 2014 16:32:06 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10AEC1A0218 for ; Fri, 4 Jul 2014 16:32:06 -0700 (PDT) Received: from BLUPR03CA037.namprd03.prod.outlook.com (10.141.30.30) by DM2PR0301MB1183.namprd03.prod.outlook.com (25.160.217.145) with Microsoft SMTP Server (TLS) id 15.0.969.15; Fri, 4 Jul 2014 23:32:03 +0000 Received: from BY2FFO11FD030.protection.gbl (2a01:111:f400:7c0c::146) by BLUPR03CA037.outlook.office365.com (2a01:111:e400:879::30) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Fri, 4 Jul 2014 23:32:03 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD030.mail.protection.outlook.com (10.1.14.211) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Fri, 4 Jul 2014 23:32:02 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0195.002; Fri, 4 Jul 2014 23:31:29 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JOSE -31 and JWT -25 drafts addressing additional AD comments Thread-Index: Ac+X4APlsSLCTGQVQaK4bK/eG6MmMAAAAXPw Date: Fri, 4 Jul 2014 23:31:29 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD9B4E5@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD9B4E5TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(199002)(189002)(377454003)(31966008)(84676001)(99396002)(16297215004)(64706001)(86612001)(20776003)(74662001)(85852003)(83072002)(87936001)(84326002)(107046002)(107886001)(4396001)(80022001)(46102001)(92726001)(2351001)(92566001)(15975445006)(74502001)(66066001)(79102001)(33656002)(86362001)(77982001)(71186001)(76482001)(81342001)(26826002)(81156004)(106466001)(55846006)(50986999)(81542001)(77096002)(85306003)(16236675004)(54356999)(19580405001)(69596002)(21056001)(15202345003)(6806004)(19625215002)(2656002)(19580395003)(19300405004)(97736001)(512954002)(95666004)(83322001)(110136001)(44976005)(104016002)(68736004)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR0301MB1183; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02622CEF0A Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/NtEBNJVux2EhILwlmF1l6NMXG3Y Subject: [OAUTH-WG] FW: JOSE -31 and JWT -25 drafts addressing additional AD comments 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, 04 Jul 2014 23:32:16 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD9B4E5TK5EX14MBXC294r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Mike Jones Sent: Friday, July 04, 2014 4:31 PM To: jose@ietf.org Subject: JOSE -31 and JWT -25 drafts addressing additional AD comments In preparation for IETF 90 in Toronto, I'v= e published yet another round of small deltas to the JOSE and JWT specifica= tions motivated by additional comments from our area director, Kathleen Mor= iarty. These drafts add some references to Security Considerations section= s, adds a Privacy Considerations section to JWT, and clarifies wording in a= few places. Once again, no normative changes were made. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-31 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-31 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-31 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-31= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-3= 1.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-31.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-3= 1.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-25.ht= ml -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1250 and = as @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439AD9B4E5TK5EX14MBXC294r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Mike Jon= es
Sent: Friday, July 04, 2014 4:31 PM
To: jose@ietf.org
Subject: JOSE -31 and JWT -25 drafts addressing additional AD commen= ts

 

In preparation for IETF 90 in Toronto, I’ve published yet another round of small del= tas to the JOSE and JWT specifications motivated by additional comments fro= m our area director, Kathleen Moriarty.  These drafts add some referen= ces to Security Considerations sections, adds a Privacy Considerations section to JWT, and clarifies wording in a few pl= aces.  Once again, no normative changes were made.

 

The specifications are available at:

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

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

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

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

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

 

HTML formatted versions are available at:=

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

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

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

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

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

 

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

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739439AD9B4E5TK5EX14MBXC294r_-- From nobody Fri Jul 4 16:46:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EE71A0290 for ; Fri, 4 Jul 2014 16:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUHcM6nQFWER for ; Fri, 4 Jul 2014 16:46:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169FE1A0276 for ; Fri, 4 Jul 2014 16:46:18 -0700 (PDT) Received: from BN3PR0301CA0066.namprd03.prod.outlook.com (25.160.152.162) by BN3PR0301MB1169.namprd03.prod.outlook.com (25.160.156.143) with Microsoft SMTP Server (TLS) id 15.0.969.15; Fri, 4 Jul 2014 23:46:16 +0000 Received: from BY2FFO11FD019.protection.gbl (2a01:111:f400:7c0c::186) by BN3PR0301CA0066.outlook.office365.com (2a01:111:e400:401e::34) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Fri, 4 Jul 2014 23:46:16 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD019.mail.protection.outlook.com (10.1.14.107) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Fri, 4 Jul 2014 23:46:15 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0195.002; Fri, 4 Jul 2014 23:45:57 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five Thread-Index: Ac+Vkn9Qxw7nsFWXQgqBEB8Y2w/8RgAAAcxwAFajBAAAANWvAAABhbNAAAFAC4AAOTT8MA== Date: Fri, 4 Jul 2014 23:45:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD9B57C@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AD95D0F@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AD992F8@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD9B57CTK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(41574002)(377454003)(51914003)(189002)(199002)(24454002)(43784003)(69234005)(164054003)(52604005)(83322001)(84326002)(97736001)(92726001)(85852003)(15202345003)(54356999)(50986999)(84676001)(99396002)(81542001)(64706001)(66066001)(2656002)(80022001)(87936001)(71186001)(4396001)(74662001)(44976005)(86612001)(20776003)(69596002)(110136001)(76176999)(31966008)(15975445006)(19580395003)(68736004)(19580405001)(92566001)(81342001)(6806004)(79102001)(76482001)(55846006)(86362001)(74502001)(19625215002)(26826002)(81156004)(77982001)(106466001)(104016002)(95666004)(33656002)(85306003)(93886003)(107046002)(19300405004)(16236675004)(77096002)(46102001)(83072002)(512874002)(21056001)(579004)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BN3PR0301MB1169; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02622CEF0A Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/hoz70VeCHVVlPs1_ELLmPkBWSTc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five 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, 04 Jul 2014 23:46:23 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD9B57CTK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsIGl0ZW1zIHRoYXQgSeKAmWQgaW5kaWNhdGVkIHdvdWxkIGJlIGRvbmUgYXJlIGluIHRoZSAt MzEgYW5kIC0yNSBkcmFmdHMuICBJIHVzZWQgUkZDIDYxNzYgYXMgdGhlIHJlcXVlc3RlZCByZWZl cmVuY2UgaW4gdGhlIFRMUyBSZXF1aXJlbWVudHMgc2VjdGlvbi4NCg0KSSBiZWxpZXZlIHRoYXQg bGVhdmVzIHVzIHdpdGggb25seSB0d28gaXNzdWVzIHRoYXQgd2XigJl2ZSBiZWVuIGRpc2N1c3Np bmc6DQoNCg0KMS4gICAgICBEYXZpZCBNY0dyZXcgZGlkIHB1Ymxpc2ggZHJhZnQtbWNncmV3LWFl YWQtYWVzLWNiYy1obWFjLXNoYTItMDUgdG9kYXksIGJ1dCBhZGRpdGlvbmFsIG5vcm1hdGl2ZSBj b3JyZWN0aW9ucyBzdGlsbCBuZWVkIHRvIG9jY3VyLCBzbyBJIGRpZG7igJl0IGNoYW5nZSBob3cg SldBIHVzZXMgaXQgeWV0LiAgSeKAmWxsIHJldmlldyBpdCBpbiBkZXRhaWwgYmV0d2VlbiBub3cg YW5kIFRvcm9udG8gYW5kIHN1Z2dlc3Qgc3BlY2lmaWMgZWRpdHMgdGhhdCB3b3VsZCBlbmFibGUg dXMgdG8gdXNlIGl0LiAgKEkgaGlnaGx5IGVuY291cmFnZSBvdGhlciB3b3JraW5nIGdyb3VwIG1l bWJlcnMgdG8gYWxzbyByZXZpZXcgaXQhKQ0KDQoNCjIuICAgICAgTm8gY2hhbmdlcyB3ZXJlIG1h ZGUgZm9yIHRoZSDigJxsZXhpY2FsbHkgbGFzdCBkdXBsaWNhdGUgbWVtYmVyIG5hbWXigJ0gd29y ZGluZyBpc3N1ZSwgc2luY2Ugbm8gYWx0ZXJuYXRpdmUgd29yZGluZyB3YXMgc3VwcGxpZWQuDQoN CkhhcHB5IDR0aCBvZiBKdWx5IQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEthdGhsZWVuIE1vcmlh cnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBUaHVy c2RheSwgSnVseSAwMywgMjAxNCAxOjE1IFBNDQpUbzogTWlrZSBKb25lcw0KQ2M6IG9hdXRoQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBGVzogSk9TRSAtMzAgYW5kIEpXVCAtMjQg ZHJhZnRzIGluY29ycG9yYXRpbmcgQUQgZmVlZGJhY2sgb24gZmlmdGggc3BlYyBvZiBmaXZlDQoN ClRoYW5rcywgTWlrZSEgIEluLWxpbmUuLi4NCg0KT24gVGh1LCBKdWwgMywgMjAxNCBhdCA0OjAz IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KUmVwbGllcyBpbmxpbmXigKYNCg0KRnJv bTogS2F0aGxlZW4gTW9yaWFydHkgW21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWls LmNvbTxtYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+XQ0KU2VudDogVGh1 cnNkYXksIEp1bHkgMDMsIDIwMTQgMTE6NTYgQU0NCg0KVG86IE1pa2UgSm9uZXMNCkNjOiBvYXV0 aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBGVzogSk9TRSAtMzAgYW5kIEpXVCAtMjQgZHJhZnRzIGluY29ycG9yYXRpbmcgQUQgZmVlZGJh Y2sgb24gZmlmdGggc3BlYyBvZiBmaXZlDQoNCkhlbGxvIQ0KDQpUaGFuayB5b3UgZm9yIGFsbCBv ZiB0aGUgdXBkYXRlcyB0byB0aGUgSk9TRSBkcmFmdHMgaW4gdGhlIGN1cnJlbnQgYnVuZGxlIGlu IHJldmlldy4gIEkgYXBwcmVjaWF0ZSBhbGwgb2YgdGhlIGVmZm9ydCB0aGF0IHdlbnQgaW50byB0 aGUgcmV2aXNpb25zISAgQXMgSSB1bmRlcnN0YW5kIGl0LCB0aGVyZSBhcmUgYSBmZXcgZ2VuZXJh bCBpc3N1ZXMgd2UgbmVlZCB0byB3b3JrIHRocm91Z2gsIHRoZW4gYSBmZXcgbml0cy9yZXF1ZXN0 cyBhcmUgaW5jbHVkZWQgb24gc3BlY2lmaWMgZHJhZnRzLg0KDQpLbm93aW5nIGhvdyB3ZSBtb3Zl IGZvcndhcmQgb24gdGhlIGZvbGxvd2luZyBpdGVtcyB3aWxsIGJlIG5lY2Vzc2FyeSBhcyB3ZWxs IGFzIHRoZSBzaGVwaGVyZC9jaGFpciBva2F5IHRvIHByb2dyZXNzIHRoZSBkcmFmdHMgdG8gSUVU RiBsYXN0IGNhbGwuICBBcyBhbiBGWUksIHNpbmNlIGl0IHdhcyByZXF1ZXN0ZWQgdGhhdCB0aGUg ZHJhZnRzIHByb2dyZXNzIGFzIGEgc2V0LCBJIG1heSBuZWVkIHRvIGRlbGF5IG9uIHdoaWNoIHRl bGVjaGF0IHRoZSBkcmFmdHMgZ2V0IHBsYWNlZC4gIEVzc2VudGlhbGx5LCB0aGUgc2V0IHJlcXVp cmVzIGEgbG90IG9mIHJlYWRpbmcgYW5kIEknZCBsaWtlIHRvIGdpdmUgdGhlIElFU0cgZW5vdWdo IHRpbWUgdG8gZG8gcmV2aWV3cy4NCg0KMS4gTWNHcmV3IGRyYWZ0IChhcHBsaWVzIHRvIEpXQSkN CiAgIFdlIGFyZSB3YWl0aW5nIG9uIGFuIHVwZGF0ZWQgdmVyc2lvbiBzbyB0aGF0IHRoZSBKV0Eg ZHJhZnQgY2FuIHJlZmVyIHRvIGl0IGFzIG9wcG9zZWQgdG8gZHVwbGljYXRpbmcgdGV4dCBmcm9t IGl0Lg0KDQpNaWtlPiAgSeKAmWQgcHJvcG9zZWQgc3BlY2lmaWMgY2hhbmdlcyB0byB0aGUgYXV0 aG9ycyBpbiBNYXkgYW5kIERhdmlkIE1jR3JldyBoYWQgdGVudGF0aXZlbHkgYWdyZWVkIHdpdGgg dGhlbSBhbmQgc2FpZCB0aGF0IGhl4oCZZCBwcm9kdWNlIGFuIHVwZGF0ZWQgZHJhZnQgYSBmZXcg d2Vla3MgYWdvLiAgVGhpcyBoYXNu4oCZdCBoYXBwZW5lZCB5ZXQuICBJIHBsYW4gdG8gc3RheSBl bmdhZ2VkIHdpdGggdGhpcywgaW5jbHVkaW5nIHBvc3NpYmx5IHByb2R1Y2luZyBhIGNhbmRpZGF0 ZSBkcmFmdCB0byBwcm9wb3NlIHRvIHRoZSBhdXRob3JzLCBpZiBuZWNlc3NhcnkuICAoVGhpcyB3 b27igJl0IGhhcHBlbiB1bnRpbCBzb21ldGltZSBiZXR3ZWVuIHRoZSA0dGggYW5kIFRvcm9udG8u KQ0KDQpPSywgdGhhbmtzIGZvciB0aGUgc3RhdHVzLg0KDQoyLiBBbHRlcm5hdGUgb24gdGV4dCB0 aGF0IGFwcGxpZXMgdG8gc2V2ZXJhbCBvZiB0aGUgZHJhZnRzIGZvciB0aGUgZm9sbG93aW5nOg0K ICAgICAgICAgRGlzY3Vzc2lvbiBvbiB3b3JkaW5nIOKAnG9yIHVzZSBhIEpTT04gcGFyc2VyIHRo YXQgcmV0dXJucw0KICAgICAgICAgb25seSB0aGUgbGV4aWNhbGx5IGxhc3QgZHVwbGljYXRlIG1l bWJlciBuYW1lLCBhcyBzcGVjaWZpZWQNCiAgICAgICAgIGluIFNlY3Rpb24gMTUuMTIgKFRoZSBK U09OIE9iamVjdCkgb2YgRUNNQVNjcmlwdCA1LjEgW0VDTUFTY3JpcHRd4oCdLg0KDQpKaW0gb3Ig b3RoZXJzIG1heSBoYXZlIHRleHQgc3VnZ2VzdGlvbnMuICBUaGlzIHdhcyBkaXNjdXNzZWQgb24g bGlzdCwgYnV0IGhhcyBub3QgYmVlbiByZXNvbHZlZCB5ZXQuDQoNCk1pa2U+IEkgYmVsaWV2ZSB0 aGF0IGl04oCZcyBhbHJlYWR5IHVuYW1iaWd1b3VzIGFzIHdvcmRlZCwgYnV0IHdvdWxkIGJlIG9w ZW4gdG8gZXZlbiBjbGVhcmVyIHdvcmRpbmcsIGlmIHNvbWVvbmUgc3VwcGxpZXMgaXQuDQoNCk9L LCBsZXQncyBzZWUgaWYgdGhlcmUgYXJlIHByb3Bvc2FscyBvciBpZiBKaW0gaGFzIGEgc3VnZ2Vz dGlvbi4NCg0KMy4gVXNlIGNhc2VzIG5vdCBtZXQgYnkgY3VycmVudCBzZXQgb2YgZHJhZnRzDQog ICAgIERvY3VtZW50cyBkbyBub3QgbWVldCBhbGwgb2YgdGhlIHVzZSBjYXNlcyBsYWlkIG91dCBp biB0aGUgVXNlIENhc2VzIGRvY3VtZW50DQogICAgIFNwZWNpZmljYWxseSBzZWN0aW9uIDUuOCBz aW5jZSB0aGVyZSBpcyBubyBrZXkgbWFuYWdlbWVudCBmb3INCiAgICAgTUFDcyAoNS44LjEuIOKA kyBNQUMgYmFzZWQgb24gRUNESC1kZXJpdmVkIGtleSkNCkknbSBub3Qgc3VyZSBob3cgdGhpcyBn ZXRzIGhhbmRsZWQuICBJZiBpdCB3aWxsIGJlIGFkZHJlc3NlZCBpbiBvdGhlciBkcmFmdHMsIGxl dCBtZSBrbm93Lg0KDQpNaWtlPiBUaGlzIHdhcyBpc3N1ZSAjMiBodHRwOi8vdHJhYy50b29scy5p ZXRmLm9yZy93Zy9qb3NlL3RyYWMvdGlja2V0LzIgYW5kIHdhcyBleHRlbnNpdmVseSBkaXNjdXNz ZWQuICBBIGZvcm1hbCBjb25zZW5zdXMgY2FsbCBvbiB0aGlzIHdhcyBjb25kdWN0ZWQgYnkgdGhl IGNoYWlycyBldmVuIHByaW9yIHRvIHRoZSBhdHRlbXB0IHRvIHJlLW9wZW4gdGhlIGlzc3VlIGJ5 IGZpbGluZyBpc3N1ZSAjMi4gIEppbeKAmXMgcmVzb2x1dGlvbiBjbG9zaW5nIHRoaXMgd2FzIHdv bnRmaXggd2FzIOKAnFRoZSB3b3JraW5nIGdyb3VwIGhhcyBhbHJlYWR5IGNvbnNpZGVyZWQgdGhp cyBhbmQgaGFzIGRldGVybWluZWQgdGhhdCBpdCB3aWxsIG5vdCBiZSBhZGRyZXNzZWQuIFVudGls IGEgcmVxdWVzdCBmb3IgdGhlIGZlYXR1cmUgY29tZXMgaW4gZnJvbSBhIGdyb3VwIHN1Y2ggYXMg dGhlIFdlYkNyeXB0bz8gZ3JvdXAgaXQgd2lsbCBub3QgYmUgcmUtY29uc2lkZXJlZC7igJ0uDQoN ClRoYXQgc2FpZCwgaXTigJlzIHdlbGwgdW5kZXJzdG9vZCBob3cgdGhpcyBjb3VsZCBiZSBjbGVh bmx5IGFkZGVkIGluIGEgYmFja3dhcmRzIGNvbXBhdGlibGUgd2F5LiAgSWYgYSBjb25jcmV0ZSBu ZWVkIGZvciB0aGlzIGFyaXNlcywgSeKAmWQgYmUgZ2xhZCB0byB3cml0ZSB1cCBhIHF1aWNrIGRy YWZ0LCBidXQgc2luY2UgdGhpcyBpcyBzZXBhcmFibGUsIEkgZG9u4oCZdCBiZWxpZXZlIHRoYXQg dGhlIHBvc3NpYmlsaXR5IG9mIGRvaW5nIHRoaXMgd29yayBpbiB0aGUgZnV0dXJlIG5lZWRzIHRv IGhhdmUgYW55IGltcGFjdCBvbiBjb21wbGV0aW5nIHRoZSBkcmFmdHMgd2UgYWxyZWFkeSBoYXZl LCB3aGljaCBpbnRlbnRpb25hbGx5IGFkZHJlc3MgdGhlIG1vc3QgY29tbW9ubHkgb2NjdXJyaW5n IHVzZSBjYXNlcy4NCg0KT0ssIHRoYW5rIHlvdS4NCg0KNC4gIEkgZG9uJ3QgcmVjYWxsIHNlZWlu ZyBhbnkgaW50ZXJuYXRpb25hbGl6YXRpb24gY29uc2lkZXJhdGlvbnMsIGlzIHRoYXQgc29tZXRo aW5nIHdlIG5lZWQgdG8gd29ycnkgYWJvdXQ/DQoNCk1pa2U+ICBOb25lIG9mIHRoZSA1IGRyYWZ0 cyBkZWZpbmUgYW55IHN0cmluZ3MgaW50ZW5kZWQgZm9yIGNvbnN1bXB0aW9uIGJ5IGVuZC11c2Vy cywgc28gSSBkb27igJl0IHRoaW5rIHNvLiAgT3IgaWYgeW91IHByZWZlciwgSSBjb3VsZCBleHBs aWNpdGx5IHNheSB0aGF0LCBwZXJoYXBzIGp1c3QgaW4gdGhlIEpXVCBkcmFmdD8gIFlvdXIgY2Fs bOKApg0KTm8gbmVlZCB0aGVuLCBpZiBpdCBjb21lcyB1cCwgSSBoYXZlIGFuIGFuc3dlciBhbmQg dGhhdCBzaG91bGQgYmUgYWxsIEkgbmVlZCBvbiB0aGlzIG9uZS4gIFRoYW5rcy4NCg0KTml0cy9D b21tZW50cyBmb3Igc3BlY2lmaWMgZHJhZnRzOg0KDQpKV0E6DQpTZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBzZWN0aW9uIDguMiBLZXkgTGlmZXRpbWVzDQpTaG91bGQgdGhlcmUgYmUgYSByZWZlcmVu Y2UgdG8gTklTVCA4MDAtNTcgdG8gcHJvdmlkZSBndWlkYW5jZSBvbiB0aGlzIHRvcGljLiAgSWYg dGhlcmUgaXMgYSBiZXR0ZXIgcmVmZXJlbmNlLCB0aGF0J3MgZmluZSB0b28uICBUaGlzIGlzIHNv bWV0aGluZyB0aGF0IG1heSBnZXQgcGlja2VkIHVwIG9uIGluIG90aGVyIHJldmlld3MuDQoNCk1p a2U+IFdpbGwgZG8NClRoYW5rIHlvdQ0KDQpUaGFua3MgZm9yIHJlZHVjaW5nIHRleHQgYnkgcmVm ZXJyaW5nIHRvIG90aGVyIGRyYWZ0cyBmb3IgYSBnb29kIHBvcnRpb24gb2YgdGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNCkpXUzoNCkZvciB0eXAgYW5kIGN0eSwgdGhlIHRl eHQgY291bGQgYmUgbW9yZSBjbGVhciBpbiB0aGUgZmlyc3QgcGFyYWdyYXBoIHNlbnRlbmNlIDIg YW5kIDQuICBUaGV5IHJlYWQgYXMgaWYgdGhleSBhcmUgaW4gY29uZmxpY3QuICAgVGhlIHNwZWNp ZmljIHVzYWdlIGlzIGRpZmZlcmVudCBpbiB0aGVzZSBzZW50ZW5jZXMsIGJ1dCB0aGF0IGlzIG5v dCBtYWRlIGNsZWFyIGluIHRoZSB0ZXh0LiAgSXQgc2hvdWxkIGp1c3QgYmUgYSB0ZXh0IGFkanVz dG1lbnQuDQoNCk1pa2U+ICBXaWxsIGRvDQpUaGFuayB5b3UNCg0KU2VjdGlvbiA4OiBUTFMgcmVx dWlyZW1lbnRzLCBzZWNvbmQgcGFyYWdyYXBoOg0KRm9yIHRoZSBzZWNvbmQgc2VudGVuY2UsIGNv dWxkIHlvdSBlaXRoZXIgaW5jbHVkZSBleGFtcGxlcyBvciBhIHJlZmVyZW5jZSB0byB3aGVyZSB0 aGUgcmVhZGVyIGNhbiBhc2NlcnRhaW4gYXBwcm9wcmlhdGUgYXBwcm9wcmlhdGUgY2lwaGVyIHN1 aXRlcz8gIFRoaXMgbWF5IGJlIHRvdWdoIHRvIGFkZHJlc3MsIGJ1dCB0aGUgd2F5IHRoZSBzZW50 ZW5jZSBpcyB3cml0dGVuLCBpdCBzb3VuZHMgbGlrZSBhIHJlZmVyZW5jZSBvciBhIHJlY29tbWVu ZGF0aW9uIGlzIG5lZWRlZC4gIEFueSBpZGVhcz8NCg0KTWlrZT4gIEnigJlkIGFwcHJlY2lhdGUg YSBzcGVjaWZpYyByZWZlcmVuY2UuICBJIGFza2VkIHRoZSBUTFMgY2hhaXJzIGZvciBvbmUgeWVz dGVyZGF5LCBidXQgaGF2ZW7igJl0IGhlYXJkIGJhY2sgZnJvbSB0aGVtIHlldC4NCk9LLCB0aGFu a3MuDQoNCkpXSzoNClVwZGF0ZXMgbG9vayBnb29kLCB0aGFua3MhDQoNCkpXRToNClVwZGF0ZXMg bG9vayBnb29kLCB0aGFuayB5b3UhDQoNCk9hdXRoIEpXVDogU2VudCB0byBPYXV0aCBsaXN0DQoN Ck1pa2U+IFRoYW5rcyBhZ2FpbiBmb3IgdGhlIHRob3JvdWdoIGFuZCB1c2VmdWwgcmV2aWV3cywg S2F0aGxlZW7igKYNCg0KWW91J3JlIHdlbGNvbWUgYW5kIHRoYW5rcyBmb3IgdGhlIHF1aWNrIHJl c3BvbnNlcyENCg0KS2F0aGxlZW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCk9uIFRodSwgSnVsIDMsIDIw MTQgYXQgMjozMSBQTSwgS2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZA Z21haWwuY29tPG1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4+IHdyb3Rl Og0KTWlrZSwNCg0KVGhhbmtzIGZvciB0aGUgdXBkYXRlZCBKV1QgZHJhZnQuICBJIGp1c3QgcmVh ZCB0aHJvdWdoIGl0IGFnYWluIGFuZCB0aGUgY2hhbmdlcyBsb29rIGdvb2QuDQoNCkkgbm90aWNl ZCB0aGF0IHByaXZhY3kgY29uc2lkZXJhdGlvbnMgd2VyZSBub3QgbWVudGlvbmVkLiAgU2hvdWxk IHRoZXJlIGJlIGFueSBkaXNjdXNzZWQgZm9yIGNsYWltcywgY2xhaW0gc2V0cywgZXRjLj8gIFRo aXMgaXMgYm91bmQgdG8gY29tZSB1cCBpbiB0aGUgSUVTRyByZXZpZXcgaWYgaXQgaXMgbm90IGFk ZHJlc3NlZC4gIFNvcnJ5IEkgZGlkbid0IGNhdGNoIHRoYXQgb24gdGhlIGZpcnN0IHJldmlldy4N Cg0KT24gVHVlLCBKdWwgMSwgMjAxNCBhdCA5OjExIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdy b3RlOg0KDQoNCkZyb206IE1pa2UgSm9uZXMNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDEsIDIwMTQg NjoxMSBQTQ0KVG86IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBKT1NFIC0zMCBhbmQgSldUIC0yNCBkcmFmdHMgaW5jb3Jwb3JhdGluZyBBRCBmZWVkYmFjayBv biBmaWZ0aCBzcGVjIG9mIGZpdmUNCg0KSk9TRSAtMzAgYW5kIEpXVCAtMjQgZHJhZnRzIGhhdmUg YmVlbiBwb3N0ZWQgaW5jb3Jwb3JhdGluZyBpbXByb3ZlbWVudHMgcmVzdWx0aW5nIGZyb20gS2F0 aGxlZW4gTW9yaWFydHnigJlzIEpXRSByZXZpZXcuICBBdCB0aGlzIHBvaW50LCBhY3Rpb25zIHJl cXVlc3RlZCBpbiBoZXIgcmV2aWV3cyBvZiB0aGUgSldTLCBKV0UsIEpXSywgSldBLCBhbmQgSldU IHNwZWNpZmljYXRpb25zIGhhdmUgYWxsIGJlZW4gaW5jb3Jwb3JhdGVkLiAgQWxsIGNoYW5nZXMg aW4gdGhpcyByZWxlYXNlIHdlcmUgc3RyaWN0bHkgZWRpdG9yaWFsIGluIG5hdHVyZS4NCg0KVGhl IHNwZWNpZmljYXRpb25zIGFyZSBhdmFpbGFibGUgYXQ6DQoNCuKAoiAgICAgICAgIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtMzAN Cg0K4oCiICAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3Nl LWpzb24td2ViLWVuY3J5cHRpb24tMzANCg0K4oCiICAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0zMA0KDQrigKIgICAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3Jp dGhtcy0zMA0KDQrigKIgICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI0DQoNCkhUTUwgZm9ybWF0dGVkIHZlcnNpb25zIGFy ZSBhdmFpbGFibGUgYXQ6DQoNCuKAoiAgICAgICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2Rv Y3MvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0zMC5odG1sDQoNCuKAoiAgICAg ICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2Vi LWVuY3J5cHRpb24tMzAuaHRtbA0KDQrigKIgICAgICAgICBodHRwOi8vc2VsZi1pc3N1ZWQuaW5m by9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMzAuaHRtbA0KDQrigKIgICAgICAg ICBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1h bGdvcml0aG1zLTMwLmh0bWwNCg0K4oCiICAgICAgICAgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8v ZG9jcy9kcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI0Lmh0bWwNCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlr ZQ0KDQpQLlMuICBUaGlzIG5vdGljZSB3YXMgYWxzbyBwb3N0ZWQgYXQgaHR0cDovL3NlbGYtaXNz dWVkLmluZm8vP3A9MTI0NSBhbmQgYXMgQHNlbGZpc3N1ZWQuDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQoNCkJlc3QgcmVnYXJkcywNCkthdGhsZWVu DQoNCg0KDQotLQ0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0KDQoNCg0KLS0NCg0KQmVzdCBy ZWdhcmRzLA0KS2F0aGxlZW4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439AD9B57CTK5EX14MBXC294r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9l bnpiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY4Njc1Mjg2ODsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODI5MDQ1ODM2IDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE5MzM1MTQ4OTA7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjI5MTY0MjI2OCA2NzY5ODcwMyA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkFsbCBpdGVtcyB0aGF0IEnigJlkIGluZGljYXRlZCB3b3VsZCBiZSBk b25lIGFyZSBpbiB0aGUgLTMxIGFuZCAtMjUgZHJhZnRzLiZuYnNwOyBJIHVzZWQgUkZDIDYxNzYg YXMgdGhlIHJlcXVlc3RlZCByZWZlcmVuY2UgaW4gdGhlIFRMUyBSZXF1aXJlbWVudHMgc2VjdGlv bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgYmVsaWV2ZSB0aGF0IGxlYXZlcyB1cyB3aXRoIG9ubHkgdHdvIGlzc3Vl cyB0aGF0IHdl4oCZdmUgYmVlbiBkaXNjdXNzaW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGF2aWQgTWNHcmV3IGRpZCBwdWJsaXNoIGRyYWZ0 LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyLTA1IHRvZGF5LCBidXQgYWRkaXRpb25hbCBu b3JtYXRpdmUgY29ycmVjdGlvbnMgc3RpbGwgbmVlZCB0byBvY2N1ciwgc28gSSBkaWRu4oCZdCBj aGFuZ2UNCiBob3cgSldBIHVzZXMgaXQgeWV0LiZuYnNwOyBJ4oCZbGwgcmV2aWV3IGl0IGluIGRl dGFpbCBiZXR3ZWVuIG5vdyBhbmQgVG9yb250byBhbmQgc3VnZ2VzdCBzcGVjaWZpYyBlZGl0cyB0 aGF0IHdvdWxkIGVuYWJsZSB1cyB0byB1c2UgaXQuJm5ic3A7IChJIGhpZ2hseSBlbmNvdXJhZ2Ug b3RoZXIgd29ya2luZyBncm91cCBtZW1iZXJzIHRvIGFsc28gcmV2aWV3IGl0ISk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vIGNoYW5nZXMgd2Vy ZSBtYWRlIGZvciB0aGUg4oCcPC9zcGFuPmxleGljYWxseSBsYXN0IGR1cGxpY2F0ZSBtZW1iZXIg bmFtZTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0NCiB3b3Jk aW5nIGlzc3VlLCBzaW5jZSBubyBhbHRlcm5hdGl2ZSB3b3JkaW5nIHdhcyBzdXBwbGllZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhhcHB5IDQ8c3VwPnRoPC9zdXA+IG9mIEp1bHkhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gS2F0 aGxlZW4gTW9yaWFydHkgW21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAwMywgMjAxNCAxOjE1IFBNPGJyPg0K PGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBGVzogSk9TRSAtMzAgYW5kIEpXVCAtMjQg ZHJhZnRzIGluY29ycG9yYXRpbmcgQUQgZmVlZGJhY2sgb24gZmlmdGggc3BlYyBvZiBmaXZlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLCBNaWtlISAmbmJzcDtJ bi1saW5lLi4uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAzLCAyMDE0IGF0IDQ6MDMgUE0sIE1pa2Ug Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRh cmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+UmVwbGllcyBpbmxpbmXigKY8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBLYXRobGVlbiBN b3JpYXJ0eSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAwMywgMjAxNCAxMTo1NiBB TTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5TdWJqZWN0OjwvYj4gUmU6 IFtPQVVUSC1XR10gRlc6IEpPU0UgLTMwIGFuZCBKV1QgLTI0IGRyYWZ0cyBpbmNvcnBvcmF0aW5n IEFEIGZlZWRiYWNrIG9uIGZpZnRoIHNwZWMgb2YgZml2ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGVsbG8hPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFuayB5b3UgZm9yIGFsbCBvZiB0 aGUgdXBkYXRlcyB0byB0aGUgSk9TRSBkcmFmdHMgaW4gdGhlIGN1cnJlbnQgYnVuZGxlIGluIHJl dmlldy4gJm5ic3A7SSBhcHByZWNpYXRlIGFsbCBvZiB0aGUgZWZmb3J0IHRoYXQgd2VudCBpbnRv IHRoZSByZXZpc2lvbnMhICZuYnNwO0FzIEkgdW5kZXJzdGFuZCBpdCwgdGhlcmUgYXJlDQogYSBm ZXcgZ2VuZXJhbCBpc3N1ZXMgd2UgbmVlZCB0byB3b3JrIHRocm91Z2gsIHRoZW4gYSBmZXcgbml0 cy9yZXF1ZXN0cyBhcmUgaW5jbHVkZWQgb24gc3BlY2lmaWMgZHJhZnRzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+S25vd2luZyBob3cg d2UgbW92ZSBmb3J3YXJkIG9uIHRoZSBmb2xsb3dpbmcgaXRlbXMgd2lsbCBiZSBuZWNlc3Nhcnkg YXMgd2VsbCBhcyB0aGUgc2hlcGhlcmQvY2hhaXIgb2theSB0byBwcm9ncmVzcyB0aGUgZHJhZnRz IHRvIElFVEYgbGFzdCBjYWxsLiAmbmJzcDtBcyBhbiBGWUksIHNpbmNlIGl0IHdhcyByZXF1ZXN0 ZWQNCiB0aGF0IHRoZSBkcmFmdHMgcHJvZ3Jlc3MgYXMgYSBzZXQsIEkgbWF5IG5lZWQgdG8gZGVs YXkgb24gd2hpY2ggdGVsZWNoYXQgdGhlIGRyYWZ0cyBnZXQgcGxhY2VkLiAmbmJzcDtFc3NlbnRp YWxseSwgdGhlIHNldCByZXF1aXJlcyBhIGxvdCBvZiByZWFkaW5nIGFuZCBJJ2QgbGlrZSB0byBn aXZlIHRoZSBJRVNHIGVub3VnaCB0aW1lIHRvIGRvIHJldmlld3MuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xLiBNY0dyZXcgZHJhZnQg KGFwcGxpZXMgdG8gSldBKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7V2UgYXJlIHdhaXRpbmcgb24gYW4gdXBkYXRlZCB2 ZXJzaW9uIHNvIHRoYXQgdGhlIEpXQSBkcmFmdCBjYW4gcmVmZXIgdG8gaXQgYXMgb3Bwb3NlZCB0 byBkdXBsaWNhdGluZyB0ZXh0IGZyb20gaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPk1pa2UmZ3Q7Jm5ic3A7 IEnigJlkIHByb3Bvc2VkIHNwZWNpZmljIGNoYW5nZXMgdG8gdGhlIGF1dGhvcnMgaW4gTWF5IGFu ZCBEYXZpZCBNY0dyZXcgaGFkIHRlbnRhdGl2ZWx5IGFncmVlZA0KIHdpdGggdGhlbSBhbmQgc2Fp ZCB0aGF0IGhl4oCZZCBwcm9kdWNlIGFuIHVwZGF0ZWQgZHJhZnQgYSBmZXcgd2Vla3MgYWdvLiZu YnNwOyBUaGlzIGhhc27igJl0IGhhcHBlbmVkIHlldC4mbmJzcDsgSSBwbGFuIHRvIHN0YXkgZW5n YWdlZCB3aXRoIHRoaXMsIGluY2x1ZGluZyBwb3NzaWJseSBwcm9kdWNpbmcgYSBjYW5kaWRhdGUg ZHJhZnQgdG8gcHJvcG9zZSB0byB0aGUgYXV0aG9ycywgaWYgbmVjZXNzYXJ5LiZuYnNwOyAoVGhp cyB3b27igJl0IGhhcHBlbiB1bnRpbCBzb21ldGltZQ0KIGJldHdlZW4gdGhlIDQ8c3VwPnRoPC9z dXA+IGFuZCBUb3JvbnRvLik8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9LLCB0aGFua3Mg Zm9yIHRoZSBzdGF0dXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Mi4gQWx0ZXJuYXRlIG9uIHRleHQgdGhhdCBhcHBsaWVzIHRvIHNldmVyYWwgb2YgdGhlIGRyYWZ0 cyBmb3IgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Rpc2N1 c3Npb24gb24gd29yZGluZyDigJxvciB1c2UgYSBKU09OIHBhcnNlciB0aGF0IHJldHVybnM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29ubHkgdGhlIGxleGljYWxseSBsYXN0IGR1cGxp Y2F0ZSBtZW1iZXIgbmFtZSwgYXMgc3BlY2lmaWVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtpbiBTZWN0aW9uIDE1LjEyIChUaGUgSlNPTiBPYmplY3QpIG9mIEVDTUFTY3JpcHQgNS4x IFtFQ01BU2NyaXB0XeKAnS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkppbSBvciBvdGhlcnMgbWF5IGhhdmUgdGV4dCBzdWdn ZXN0aW9ucy4gJm5ic3A7VGhpcyB3YXMgZGlzY3Vzc2VkIG9uIGxpc3QsIGJ1dCBoYXMgbm90IGJl ZW4gcmVzb2x2ZWQgeWV0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5NaWtlJmd0OyBJIGJlbGlldmUgdGhhdCBp dOKAmXMgYWxyZWFkeSB1bmFtYmlndW91cyBhcyB3b3JkZWQsIGJ1dCB3b3VsZCBiZSBvcGVuIHRv IGV2ZW4gY2xlYXJlciB3b3JkaW5nLA0KIGlmIHNvbWVvbmUgc3VwcGxpZXMgaXQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PSywgbGV0J3Mgc2VlIGlmIHRoZXJl IGFyZSBwcm9wb3NhbHMgb3IgaWYgSmltIGhhcyBhIHN1Z2dlc3Rpb24uJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+My4gVXNlIGNhc2VzIG5vdCBtZXQgYnkgY3VycmVu dCBzZXQgb2YgZHJhZnRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7RG9jdW1lbnRzIGRvIG5vdCBtZWV0IGFs bCBvZiB0aGUgdXNlIGNhc2VzIGxhaWQgb3V0IGluIHRoZSBVc2UgQ2FzZXMgZG9jdW1lbnQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDtTcGVjaWZpY2FsbHkgc2VjdGlvbiA1Ljggc2luY2UgdGhlcmUgaXMgbm8g a2V5IG1hbmFnZW1lbnQgZm9yJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7TUFDcyAoNS44LjEuIOKA kyBNQUMgYmFzZWQgb24gRUNESC1kZXJpdmVkIGtleSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdtIG5vdCBzdXJlIGhvdyB0aGlzIGdldHMg aGFuZGxlZC4gJm5ic3A7SWYgaXQgd2lsbCBiZSBhZGRyZXNzZWQgaW4gb3RoZXIgZHJhZnRzLCBs ZXQgbWUga25vdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+TWlrZSZndDsgVGhpcyB3YXMgaXNzdWUgIzINCjxh IGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNrZXQvMiIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90 aWNrZXQvMjwvYT4gYW5kIHdhcyBleHRlbnNpdmVseSBkaXNjdXNzZWQuJm5ic3A7IEEgZm9ybWFs IGNvbnNlbnN1cyBjYWxsIG9uIHRoaXMgd2FzIGNvbmR1Y3RlZCBieSB0aGUgY2hhaXJzIGV2ZW4g cHJpb3IgdG8gdGhlIGF0dGVtcHQgdG8gcmUtb3Blbg0KIHRoZSBpc3N1ZSBieSBmaWxpbmcgaXNz dWUgIzIuJm5ic3A7IEppbeKAmXMgcmVzb2x1dGlvbiBjbG9zaW5nIHRoaXMgd2FzIHdvbnRmaXgg d2FzIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+ VGhlIHdvcmtpbmcgZ3JvdXAgaGFzIGFscmVhZHkgY29uc2lkZXJlZCB0aGlzIGFuZCBoYXMgZGV0 ZXJtaW5lZCB0aGF0IGl0IHdpbGwgbm90IGJlIGFkZHJlc3NlZC4gVW50aWwgYSByZXF1ZXN0IGZv ciB0aGUgZmVhdHVyZQ0KIGNvbWVzIGluIGZyb20gYSBncm91cCBzdWNoIGFzIHRoZSBXZWJDcnlw dG8/IGdyb3VwIGl0IHdpbGwgbm90IGJlIHJlLWNvbnNpZGVyZWQuPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj7igJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+VGhhdCBz YWlkLCBpdOKAmXMgd2VsbCB1bmRlcnN0b29kIGhvdyB0aGlzIGNvdWxkIGJlIGNsZWFubHkgYWRk ZWQgaW4gYSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3YXkuJm5ic3A7IElmDQogYSBjb25jcmV0ZSBu ZWVkIGZvciB0aGlzIGFyaXNlcywgSeKAmWQgYmUgZ2xhZCB0byB3cml0ZSB1cCBhIHF1aWNrIGRy YWZ0LCBidXQgc2luY2UgdGhpcyBpcyBzZXBhcmFibGUsIEkgZG9u4oCZdCBiZWxpZXZlIHRoYXQg dGhlIHBvc3NpYmlsaXR5IG9mIGRvaW5nIHRoaXMgd29yayBpbiB0aGUgZnV0dXJlIG5lZWRzIHRv IGhhdmUgYW55IGltcGFjdCBvbiBjb21wbGV0aW5nIHRoZSBkcmFmdHMgd2UgYWxyZWFkeSBoYXZl LCB3aGljaCBpbnRlbnRpb25hbGx5DQogYWRkcmVzcyB0aGUgbW9zdCBjb21tb25seSBvY2N1cnJp bmcgdXNlIGNhc2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T0ssIHRoYW5rIHlvdS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj40 LiAmbmJzcDtJIGRvbid0IHJlY2FsbCBzZWVpbmcgYW55IGludGVybmF0aW9uYWxpemF0aW9uIGNv bnNpZGVyYXRpb25zLCBpcyB0aGF0IHNvbWV0aGluZyB3ZSBuZWVkIHRvIHdvcnJ5IGFib3V0Pzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+TWlrZSZn dDsmbmJzcDsgTm9uZSBvZiB0aGUgNSBkcmFmdHMgZGVmaW5lIGFueSBzdHJpbmdzIGludGVuZGVk IGZvciBjb25zdW1wdGlvbiBieSBlbmQtdXNlcnMsIHNvIEkgZG9u4oCZdA0KIHRoaW5rIHNvLiZu YnNwOyBPciBpZiB5b3UgcHJlZmVyLCBJIGNvdWxkIGV4cGxpY2l0bHkgc2F5IHRoYXQsIHBlcmhh cHMganVzdCBpbiB0aGUgSldUIGRyYWZ0PyZuYnNwOyBZb3VyIGNhbGzigKY8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBuZWVkIHRoZW4sIGlmIGl0IGNvbWVzIHVw LCBJIGhhdmUgYW4gYW5zd2VyIGFuZCB0aGF0IHNob3VsZCBiZSBhbGwgSSBuZWVkIG9uIHRoaXMg b25lLiAmbmJzcDtUaGFua3MuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Tml0cy9Db21tZW50cyBmb3Igc3BlY2lmaWMgZHJhZnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SldBOiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TZWN1cml0eSBj b25zaWRlcmF0aW9ucyBzZWN0aW9uIDguMiBLZXkgTGlmZXRpbWVzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNob3VsZCB0aGVyZSBiZSBhIHJl ZmVyZW5jZSB0byBOSVNUIDgwMC01NyB0byBwcm92aWRlIGd1aWRhbmNlIG9uIHRoaXMgdG9waWMu ICZuYnNwO0lmIHRoZXJlIGlzIGEgYmV0dGVyIHJlZmVyZW5jZSwgdGhhdCdzIGZpbmUgdG9vLiAm bmJzcDtUaGlzIGlzIHNvbWV0aGluZyB0aGF0IG1heSBnZXQgcGlja2VkIHVwIG9uIGluIG90aGVy DQogcmV2aWV3cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+TWlrZSZndDsgV2lsbCBkbzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcw QzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBmb3IgcmVkdWNpbmcgdGV4dCBieSByZWZlcnJp bmcgdG8gb3RoZXIgZHJhZnRzIGZvciBhIGdvb2QgcG9ydGlvbiBvZiB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgc2VjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkpXUzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9yIHR5cCBhbmQgY3R5LCB0aGUgdGV4dCBjb3VsZCBi ZSBtb3JlIGNsZWFyIGluIHRoZSBmaXJzdCBwYXJhZ3JhcGggc2VudGVuY2UgMiBhbmQgNC4gJm5i c3A7VGhleSByZWFkIGFzIGlmIHRoZXkgYXJlIGluIGNvbmZsaWN0LiAmbmJzcDsgVGhlIHNwZWNp ZmljIHVzYWdlIGlzIGRpZmZlcmVudCBpbiB0aGVzZSBzZW50ZW5jZXMsDQogYnV0IHRoYXQgaXMg bm90IG1hZGUgY2xlYXIgaW4gdGhlIHRleHQuICZuYnNwO0l0IHNob3VsZCBqdXN0IGJlIGEgdGV4 dCBhZGp1c3RtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5NaWtlJmd0OyZuYnNwOyBXaWxsIGRvPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2VjdGlvbiA4OiBUTFMgcmVxdWlyZW1lbnRz LCBzZWNvbmQgcGFyYWdyYXBoOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5Gb3IgdGhlIHNlY29uZCBzZW50ZW5jZSwgY291bGQgeW91IGVpdGhl ciBpbmNsdWRlIGV4YW1wbGVzIG9yIGEgcmVmZXJlbmNlIHRvIHdoZXJlIHRoZSByZWFkZXIgY2Fu IGFzY2VydGFpbiBhcHByb3ByaWF0ZSBhcHByb3ByaWF0ZSBjaXBoZXIgc3VpdGVzPyAmbmJzcDtU aGlzIG1heSBiZSB0b3VnaCB0byBhZGRyZXNzLA0KIGJ1dCB0aGUgd2F5IHRoZSBzZW50ZW5jZSBp cyB3cml0dGVuLCBpdCBzb3VuZHMgbGlrZSBhIHJlZmVyZW5jZSBvciBhIHJlY29tbWVuZGF0aW9u IGlzIG5lZWRlZC4gJm5ic3A7QW55IGlkZWFzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3 MEMwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5NaWtlJmd0OyZuYnNw OyBJ4oCZZCBhcHByZWNpYXRlIGEgc3BlY2lmaWMgcmVmZXJlbmNlLiZuYnNwOyBJIGFza2VkIHRo ZSBUTFMgY2hhaXJzIGZvciBvbmUgeWVzdGVyZGF5LCBidXQgaGF2ZW7igJl0DQogaGVhcmQgYmFj ayBmcm9tIHRoZW0geWV0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9LLCB0aGFua3MuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SldL OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5V cGRhdGVzIGxvb2sgZ29vZCwgdGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SldFOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5VcGRhdGVzIGxvb2sgZ29vZCwgdGhhbmsgeW91 ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+T2F1dGggSldUOiBTZW50IHRvIE9hdXRoIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+TWlrZSZndDsg VGhhbmtzIGFnYWluIGZvciB0aGUgdGhvcm91Z2ggYW5kIHVzZWZ1bCByZXZpZXdzLCBLYXRobGVl buKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+WW91J3JlIHdlbGNvbWUgYW5kIHRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlcyE8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2F0 aGxlZW4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgSnVs IDMsIDIwMTQgYXQgMjozMSBQTSwgS2F0aGxlZW4gTW9yaWFydHkgJmx0OzxhIGhyZWY9Im1haWx0 bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthdGhs ZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NaWtlLDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBmb3IgdGhlIHVwZGF0ZWQgSldU IGRyYWZ0LiAmbmJzcDtJIGp1c3QgcmVhZCB0aHJvdWdoIGl0IGFnYWluIGFuZCB0aGUgY2hhbmdl cyBsb29rIGdvb2QuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSBub3RpY2VkIHRoYXQgcHJpdmFjeSBjb25zaWRlcmF0aW9u cyB3ZXJlIG5vdCBtZW50aW9uZWQuICZuYnNwO1Nob3VsZCB0aGVyZSBiZSBhbnkgZGlzY3Vzc2Vk IGZvciBjbGFpbXMsIGNsYWltIHNldHMsIGV0Yy4/ICZuYnNwO1RoaXMgaXMgYm91bmQgdG8gY29t ZSB1cCBpbiB0aGUgSUVTRyByZXZpZXcgaWYgaXQgaXMgbm90DQogYWRkcmVzc2VkLiAmbmJzcDtT b3JyeSBJIGRpZG4ndCBjYXRjaCB0aGF0IG9uIHRoZSBmaXJzdCByZXZpZXcuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u IFR1ZSwgSnVsIDEsIDIwMTQgYXQgOToxMSBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNaWtlIEpvbmVzDQo8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAwMSwgMjAxNCA2OjExIFBNPGJyPg0KPGI+VG86 PC9iPiA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpvc2VA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IEpPU0UgLTMwIGFuZCBKV1QgLTI0IGRy YWZ0cyBpbmNvcnBvcmF0aW5nIEFEIGZlZWRiYWNrIG9uIGZpZnRoIHNwZWMgb2YgZml2ZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkpPU0UgLTMwIGFuZCBKV1QgLTI0IGRyYWZ0cyBoYXZlIGJlZW4gcG9zdGVkIGluY29ycG9y YXRpbmcgaW1wcm92ZW1lbnRzIHJlc3VsdGluZyBmcm9tIEthdGhsZWVuIE1vcmlhcnR54oCZcyBK V0UgcmV2aWV3LiZuYnNwOyBBdCB0aGlzIHBvaW50LCBhY3Rpb25zIHJlcXVlc3RlZCBpbiBoZXIg cmV2aWV3cyBvZiB0aGUgSldTLA0KIEpXRSwgSldLLCBKV0EsIGFuZCBKV1Qgc3BlY2lmaWNhdGlv bnMgaGF2ZSBhbGwgYmVlbiBpbmNvcnBvcmF0ZWQuJm5ic3A7IEFsbCBjaGFuZ2VzIGluIHRoaXMg cmVsZWFzZSB3ZXJlIHN0cmljdGx5IGVkaXRvcmlhbCBpbiBuYXR1cmUuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UaGUgc3BlY2lmaWNhdGlvbnMgYXJlIGF2YWlsYWJsZSBhdDo8bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtMzAiIHRhcmdldD0iX2Js YW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIt c2lnbmF0dXJlLTMwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWVu Y3J5cHRpb24tMzAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlwdGlvbi0zMDwvYT48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMzAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTMwPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtMzAiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13 ZWItYWxnb3JpdGhtcy0zMDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13 ZWItdG9rZW4tMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SFRNTCBmb3JtYXR0ZWQgdmVyc2lvbnMgYXJlIGF2YWlsYWJsZSBhdDo8bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5p bmZvL2RvY3MvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0zMC5odG1sIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLWpvc2Ut anNvbi13ZWItc2lnbmF0dXJlLTMwLmh0bWw8L2E+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYt am9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTMwLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v c2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9u LTMwLmh0bWw8L2E+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJo dHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXkt MzAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJh ZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0zMC5odG1sPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFm dC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0zMC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxn b3JpdGhtcy0zMC5odG1sPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEg aHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLW9hdXRoLWpzb24t d2ViLXRva2VuLTI0Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5m by9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjQuaHRtbDwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5QLlMuJm5ic3A7IFRoaXMgbm90aWNlIHdhcyBhbHNvIHBvc3RlZCBhdA0K PGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTI0NSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTEyNDU8L2E+IGFuZCBhcyBAc2VsZmlzc3VlZC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojODg4ODg4Ij4tLQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+QmVzdCByZWdhcmRzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPkthdGhsZWVuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+LS0NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkthdGhsZWVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkthdGhsZWVuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739439AD9B57CTK5EX14MBXC294r_-- From nobody Fri Jul 4 16:47:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5872B1A02CB for ; Fri, 4 Jul 2014 16:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StjUEJLFJoVn for ; Fri, 4 Jul 2014 16:46:58 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853721A02A0 for ; Fri, 4 Jul 2014 16:46:49 -0700 (PDT) Received: from BN3PR0301CA0057.namprd03.prod.outlook.com (25.160.152.153) by DM2PR0301MB1183.namprd03.prod.outlook.com (25.160.217.145) with Microsoft SMTP Server (TLS) id 15.0.969.15; Fri, 4 Jul 2014 23:46:41 +0000 Received: from BN1BFFO11FD045.protection.gbl (2a01:111:f400:7c10::1:170) by BN3PR0301CA0057.outlook.office365.com (2a01:111:e400:401e::25) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Fri, 4 Jul 2014 23:46:41 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD045.mail.protection.outlook.com (10.58.145.0) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Fri, 4 Jul 2014 23:46:40 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Fri, 4 Jul 2014 23:46:19 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five Thread-Index: Ac+Vkn9Qxw7nsFWXQgqBEB8Y2w/8RgAAAcxwAFajBAAAAhPGkAAA8leAADo+HzA= Date: Fri, 4 Jul 2014 23:46:18 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD9B58F@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AD95D0F@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AD991B6@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD9B58FTK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(377454003)(24454002)(51914003)(41574002)(189002)(199002)(85306003)(16236675004)(77096002)(54356999)(19580405001)(26826002)(81156004)(81342001)(71186001)(86362001)(77982001)(76482001)(50986999)(81542001)(106466001)(55846006)(95666004)(83322001)(110136001)(76176999)(93886003)(104016002)(68736004)(44976005)(2656002)(19625215002)(6806004)(19580395003)(19300405004)(512874002)(69596002)(15202345003)(21056001)(97736001)(20776003)(86612001)(74662001)(87936001)(83072002)(85852003)(84676001)(99396002)(31966008)(64706001)(92726001)(80022001)(46102001)(33656002)(74502001)(66066001)(92566001)(15975445006)(79102001)(107046002)(84326002)(4396001)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR0301MB1183; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02622CEF0A Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/U7LSjmYwymDEzNKvMJIiE2p1gws Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five 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, 04 Jul 2014 23:47:00 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD9B58FTK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9uZQ0KDQpGcm9tOiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5 LmlldGZAZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIEp1bHkgMDMsIDIwMTQgMTI6NTkgUE0N ClRvOiBNaWtlIEpvbmVzDQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgt V0ddIEZXOiBKT1NFIC0zMCBhbmQgSldUIC0yNCBkcmFmdHMgaW5jb3Jwb3JhdGluZyBBRCBmZWVk YmFjayBvbiBmaWZ0aCBzcGVjIG9mIGZpdmUNCg0KDQoNCk9uIFRodSwgSnVsIDMsIDIwMTQgYXQg MzozOCBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkkgY2FuIGFkZCBzb21ldGhpbmcg YWxvbmcgdGhlc2UgbGluZXMuICBEb2VzIHRoYXQgd29yayBmb3IgeW91Pw0KDQpQcml2YWN5IENv bnNpZGVyYXRpb25zDQpBIEpXVCBtYXkgY29udGFpbiBwcml2YWN5LXNlbnNpdGl2ZSBpbmZvcm1h dGlvbi4gIFdoZW4gdGhpcyBpcyB0aGUgY2FzZSwgbWVhc3VyZXMgbXVzdCBiZSB0YWtlbiB0byBw cmV2ZW50IGRpc2Nsb3N1cmUgb2YgdGhpcyBpbmZvcm1hdGlvbiB0byB1bmludGVuZGVkIHBhcnRp ZXMuICBPbmUgd2F5IHRvIGFjaGlldmUgdGhpcyBpcyB0byB1c2UgYW4gZW5jcnlwdGVkIEpXVC4g IEFub3RoZXIgd2F5IGlzIHRvIGVuc3VyZSB0aGF0IEpXVHMgY29udGFpbmluZyB1bmVuY3J5cHRl ZCBwcml2YWN5LXNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBhcmUgb25seSB0cmFuc21pdHRlZCBvdmVy IGVuY3J5cHRlZCBjaGFubmVscyBvciBwcm90b2NvbHMsIHN1Y2ggYXMgVExTLg0KDQpHcmVhdCwg dGhhbmtzIQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFp bHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPG1haWx0bzprYXRobGVlbi5tb3Jp YXJ0eS5pZXRmQGdtYWlsLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgSnVseSAwMywgMjAxNCAxMToz MiBBTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBGVzogSk9TRSAtMzAgYW5kIEpXVCAtMjQg ZHJhZnRzIGluY29ycG9yYXRpbmcgQUQgZmVlZGJhY2sgb24gZmlmdGggc3BlYyBvZiBmaXZlDQoN Ck1pa2UsDQoNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZWQgSldUIGRyYWZ0LiAgSSBqdXN0IHJlYWQg dGhyb3VnaCBpdCBhZ2FpbiBhbmQgdGhlIGNoYW5nZXMgbG9vayBnb29kLg0KDQpJIG5vdGljZWQg dGhhdCBwcml2YWN5IGNvbnNpZGVyYXRpb25zIHdlcmUgbm90IG1lbnRpb25lZC4gIFNob3VsZCB0 aGVyZSBiZSBhbnkgZGlzY3Vzc2VkIGZvciBjbGFpbXMsIGNsYWltIHNldHMsIGV0Yy4/ICBUaGlz IGlzIGJvdW5kIHRvIGNvbWUgdXAgaW4gdGhlIElFU0cgcmV2aWV3IGlmIGl0IGlzIG5vdCBhZGRy ZXNzZWQuICBTb3JyeSBJIGRpZG4ndCBjYXRjaCB0aGF0IG9uIHRoZSBmaXJzdCByZXZpZXcuDQoN Ck9uIFR1ZSwgSnVsIDEsIDIwMTQgYXQgOToxMSBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90 ZToNCg0KDQpGcm9tOiBNaWtlIEpvbmVzDQpTZW50OiBUdWVzZGF5LCBKdWx5IDAxLCAyMDE0IDY6 MTEgUE0NClRvOiBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KU3ViamVjdDog Sk9TRSAtMzAgYW5kIEpXVCAtMjQgZHJhZnRzIGluY29ycG9yYXRpbmcgQUQgZmVlZGJhY2sgb24g ZmlmdGggc3BlYyBvZiBmaXZlDQoNCkpPU0UgLTMwIGFuZCBKV1QgLTI0IGRyYWZ0cyBoYXZlIGJl ZW4gcG9zdGVkIGluY29ycG9yYXRpbmcgaW1wcm92ZW1lbnRzIHJlc3VsdGluZyBmcm9tIEthdGhs ZWVuIE1vcmlhcnR54oCZcyBKV0UgcmV2aWV3LiAgQXQgdGhpcyBwb2ludCwgYWN0aW9ucyByZXF1 ZXN0ZWQgaW4gaGVyIHJldmlld3Mgb2YgdGhlIEpXUywgSldFLCBKV0ssIEpXQSwgYW5kIEpXVCBz cGVjaWZpY2F0aW9ucyBoYXZlIGFsbCBiZWVuIGluY29ycG9yYXRlZC4gIEFsbCBjaGFuZ2VzIGlu IHRoaXMgcmVsZWFzZSB3ZXJlIHN0cmljdGx5IGVkaXRvcmlhbCBpbiBuYXR1cmUuDQoNClRoZSBz cGVjaWZpY2F0aW9ucyBhcmUgYXZhaWxhYmxlIGF0Og0KDQrigKIgICAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTMwDQoN CuKAoiAgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1q c29uLXdlYi1lbmNyeXB0aW9uLTMwDQoNCuKAoiAgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMzANCg0K4oCiICAgICAgICAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRo bXMtMzANCg0K4oCiICAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNA0KDQpIVE1MIGZvcm1hdHRlZCB2ZXJzaW9ucyBhcmUg YXZhaWxhYmxlIGF0Og0KDQrigKIgICAgICAgICBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2Nz L2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtMzAuaHRtbA0KDQrigKIgICAgICAg ICBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1l bmNyeXB0aW9uLTMwLmh0bWwNCg0K4oCiICAgICAgICAgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8v ZG9jcy9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTMwLmh0bWwNCg0K4oCiICAgICAgICAg aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxn b3JpdGhtcy0zMC5odG1sDQoNCuKAoiAgICAgICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2Rv Y3MvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNC5odG1sDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UN Cg0KUC5TLiAgVGhpcyBub3RpY2Ugd2FzIGFsc28gcG9zdGVkIGF0IGh0dHA6Ly9zZWxmLWlzc3Vl ZC5pbmZvLz9wPTEyNDUgYW5kIGFzIEBzZWxmaXNzdWVkLg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBp ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0K DQoNCg0KLS0NCg0KQmVzdCByZWdhcmRzLA0KS2F0aGxlZW4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439AD9B58FTK5EX14MBXC294r_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+RG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gS2F0aGxlZW4gTW9yaWFydHkgW21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5p ZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAwMywgMjAx NCAxMjo1OSBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gb2F1 dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gRlc6IEpPU0Ug LTMwIGFuZCBKV1QgLTI0IGRyYWZ0cyBpbmNvcnBvcmF0aW5nIEFEIGZlZWRiYWNrIG9uIGZpZnRo IHNwZWMgb2YgZml2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVGh1LCBKdWwgMywgMjAxNCBhdCAzOjM4IFBNLCBNaWtlIEpvbmVzICZs dDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9i bGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgY2FuIGFkZCBzb21ldGhpbmcgYWxvbmcg dGhlc2UgbGluZXMuJm5ic3A7IERvZXMgdGhhdCB3b3JrIGZvciB5b3U/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlByaXZhY3kgQ29uc2lkZXJhdGlvbnM8L3NwYW4+PC9iPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkEgSldUIG1heSBjb250 YWluIHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uLiZuYnNwOyBXaGVuIHRoaXMgaXMgdGhl IGNhc2UsIG1lYXN1cmVzIG11c3QgYmUgdGFrZW4gdG8gcHJldmVudCBkaXNjbG9zdXJlIG9mIHRo aXMgaW5mb3JtYXRpb24gdG8gdW5pbnRlbmRlZCBwYXJ0aWVzLiZuYnNwOyBPbmUgd2F5IHRvIGFj aGlldmUNCiB0aGlzIGlzIHRvIHVzZSBhbiBlbmNyeXB0ZWQgSldULiZuYnNwOyBBbm90aGVyIHdh eSBpcyB0byBlbnN1cmUgdGhhdCBKV1RzIGNvbnRhaW5pbmcgdW5lbmNyeXB0ZWQgcHJpdmFjeS1z ZW5zaXRpdmUgaW5mb3JtYXRpb24gYXJlIG9ubHkgdHJhbnNtaXR0ZWQgb3ZlciBlbmNyeXB0ZWQg Y2hhbm5lbHMgb3IgcHJvdG9jb2xzLCBzdWNoIGFzIFRMUy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3JlYXQsIHRo YW5rcyEmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAwMywgMjAxNCAxMTozMiBBTTxicj4NCjxiPlRvOjwv Yj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbT0FVVEgtV0ddIEZXOiBKT1NFIC0zMCBhbmQgSldUIC0yNCBkcmFmdHMgaW5jb3Jw b3JhdGluZyBBRCBmZWVkYmFjayBvbiBmaWZ0aCBzcGVjIG9mIGZpdmU8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NaWtlLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBmb3IgdGhlIHVw ZGF0ZWQgSldUIGRyYWZ0LiAmbmJzcDtJIGp1c3QgcmVhZCB0aHJvdWdoIGl0IGFnYWluIGFuZCB0 aGUgY2hhbmdlcyBsb29rIGdvb2QuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBub3RpY2VkIHRoYXQgcHJpdmFjeSBjb25z aWRlcmF0aW9ucyB3ZXJlIG5vdCBtZW50aW9uZWQuICZuYnNwO1Nob3VsZCB0aGVyZSBiZSBhbnkg ZGlzY3Vzc2VkIGZvciBjbGFpbXMsIGNsYWltIHNldHMsIGV0Yy4/ICZuYnNwO1RoaXMgaXMgYm91 bmQgdG8gY29tZSB1cCBpbiB0aGUgSUVTRyByZXZpZXcgaWYgaXQgaXMgbm90DQogYWRkcmVzc2Vk LiAmbmJzcDtTb3JyeSBJIGRpZG4ndCBjYXRjaCB0aGF0IG9uIHRoZSBmaXJzdCByZXZpZXcuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUs IEp1bCAxLCAyMDE0IGF0IDk6MTEgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IE1pa2UgSm9uZXMNCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5 IDAxLCAyMDE0IDY6MTEgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqb3NlQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+am9zZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gSk9TRSAtMzAgYW5kIEpXVCAtMjQgZHJhZnRzIGluY29ycG9yYXRpbmcgQUQgZmVlZGJh Y2sgb24gZmlmdGggc3BlYyBvZiBmaXZlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Sk9TRSAtMzAgYW5kIEpXVCAtMjQgZHJh ZnRzIGhhdmUgYmVlbiBwb3N0ZWQgaW5jb3Jwb3JhdGluZyBpbXByb3ZlbWVudHMgcmVzdWx0aW5n IGZyb20gS2F0aGxlZW4gTW9yaWFydHnigJlzIEpXRSByZXZpZXcuJm5ic3A7IEF0IHRoaXMgcG9p bnQsIGFjdGlvbnMgcmVxdWVzdGVkIGluIGhlciByZXZpZXdzIG9mIHRoZSBKV1MsDQogSldFLCBK V0ssIEpXQSwgYW5kIEpXVCBzcGVjaWZpY2F0aW9ucyBoYXZlIGFsbCBiZWVuIGluY29ycG9yYXRl ZC4mbmJzcDsgQWxsIGNoYW5nZXMgaW4gdGhpcyByZWxlYXNlIHdlcmUgc3RyaWN0bHkgZWRpdG9y aWFsIGluIG5hdHVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBzcGVjaWZpY2F0 aW9ucyBhcmUgYXZhaWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24t d2ViLXNpZ25hdHVyZS0zMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtMzA8L2E+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlwdGlvbi0zMCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNy eXB0aW9uLTMwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0z MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt am9zZS1qc29uLXdlYi1rZXktMzA8L2E+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItYWxnb3JpdGhtcy0zMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTMwPC9hPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9r ZW4tMjQ8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IVE1MIGZvcm1hdHRlZCB2ZXJz aW9ucyBhcmUgYXZhaWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItc2lnbmF0dXJlLTMwLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2VsZi1pc3N1 ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtMzAuaHRtbDwv YT48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9zZWxm LWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWVuY3J5cHRpb24tMzAu aHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQt aWV0Zi1qb3NlLWpzb24td2ViLWVuY3J5cHRpb24tMzAuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3Mv ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0zMC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTMw Lmh0bWw8L2E+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3lt Ym9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJodHRw Oi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0 aG1zLTMwLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2Nz L2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTMwLmh0bWw8L2E+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5m by9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjQuaHRtbCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC1qc29u LXdlYi10b2tlbi0yNC5odG1sPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlAuUy4mbmJzcDsgVGhp cyBub3RpY2Ugd2FzIGFsc28gcG9zdGVkIGF0DQo8YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQu aW5mby8/cD0xMjQ1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9 MTI0NTwvYT4gYW5kIGFzIEBzZWxmaXNzdWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLQ0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+S2F0aGxlZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFs bCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2F0aGxlZW48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439AD9B58FTK5EX14MBXC294r_-- From nobody Fri Jul 4 17:09:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760441A0145 for ; Fri, 4 Jul 2014 17:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3HqBQzGlFJ32 for ; Fri, 4 Jul 2014 17:09:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32701A0092 for ; Fri, 4 Jul 2014 17:09:42 -0700 (PDT) Received: from BN3PR0301CA0066.namprd03.prod.outlook.com (25.160.152.162) by BY1PR0301MB1176.namprd03.prod.outlook.com (25.160.195.147) with Microsoft SMTP Server (TLS) id 15.0.969.15; Sat, 5 Jul 2014 00:09:40 +0000 Received: from BY2FFO11FD027.protection.gbl (2a01:111:f400:7c0c::151) by BN3PR0301CA0066.outlook.office365.com (2a01:111:e400:401e::34) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Sat, 5 Jul 2014 00:09:39 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD027.mail.protection.outlook.com (10.1.15.216) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Sat, 5 Jul 2014 00:09:39 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Sat, 5 Jul 2014 00:09:09 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Act-As and On-Behalf-Of for OAuth 2.0 Thread-Index: Ac+X5VZ/yuQFHnECRz+7sVgLJIXiQw== Date: Sat, 5 Jul 2014 00:09:08 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD9B66F@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD9B66FTK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(199002)(189002)(74662001)(15202345003)(99396002)(31966008)(77096002)(16297215004)(16236675004)(71186001)(92566001)(512954002)(86362001)(92726001)(74502001)(97736001)(19300405004)(81542001)(110136001)(64706001)(54356999)(21056001)(20776003)(66066001)(33656002)(104016002)(19625215002)(95666004)(84676001)(26826002)(69596002)(44976005)(107046002)(77982001)(76482001)(83072002)(81156004)(229853001)(50986999)(80022001)(106466001)(85306003)(2351001)(79102001)(55846006)(81342001)(4396001)(107886001)(19580395003)(86612001)(84326002)(85852003)(87936001)(2656002)(6806004)(83322001)(68736004)(46102001)(15975445006)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BY1PR0301MB1176; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02638D901B Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/AiLlvSMbjug-8OTBLoLV6d5ATwM Subject: [OAUTH-WG] Act-As and On-Behalf-Of for OAuth 2.0 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, 05 Jul 2014 00:09:45 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD9B66FTK5EX14MBXC294r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In preparation for IETF 90 in Toronto, I'v= e updated the OAuth Token Exchange draft to allow JWTs to be unsigned in ca= ses where the trust model permits it. This draft also incorporates some of= the review feedback received on the -00 draft. (Because I believe it dese= rves more working group discussion to determine the right resolutions, John= Bradley's terminology feedback was not yet addressed. This would be a goo= d topic to discuss in Toronto.) This specification is available at: * http://tools.ietf.org/html/draft-jones-oauth-token-exchange-01 An HTML formatted version is also available at: * http://self-issued.info/docs/draft-jones-oauth-token-exchange-01.h= tml -- Mike P.S. I also posted this note at http://self-issued.info/?p=3D1252 and as @= selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439AD9B66FTK5EX14MBXC294r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In preparation for IETF 90 in Toronto, I’ve updated the OAuth Token Exchange draft t= o allow JWTs to be unsigned in cases where the trust model permits it. = ; This draft also incorporates some of the review feedback received on the = -00 draft.  (Because I believe it deserves more working group discussion to determine the right resolutions, John Bra= dley’s terminology feedback was not yet addressed.  This would b= e a good topic to discuss in Toronto.)

 

This specification is available at:

·        http://tools.ietf.org/html/draft-jones-oauth= -token-exchange-01

 

An HTML formatted version is also available at:=

·        http://self-issued.info/docs/draft-jo= nes-oauth-token-exchange-01.html

 

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

 

P.S.  I also posted this note at http://self-issued.info/?p=3D1252 and as @selfissued.

 

--_000_4E1F6AAD24975D4BA5B16804296739439AD9B66FTK5EX14MBXC294r_-- From nobody Fri Jul 4 17:29:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA161A01C6 for ; Fri, 4 Jul 2014 17:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AO011p811X5 for ; Fri, 4 Jul 2014 17:28:58 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26EE51A019A for ; Fri, 4 Jul 2014 17:28:58 -0700 (PDT) Received: from BN3PR0301CA0070.namprd03.prod.outlook.com (25.160.152.166) by CY1PR0301MB1178.namprd03.prod.outlook.com (25.160.165.21) with Microsoft SMTP Server (TLS) id 15.0.969.15; Sat, 5 Jul 2014 00:28:50 +0000 Received: from BY2FFO11FD017.protection.gbl (2a01:111:f400:7c0c::193) by BN3PR0301CA0070.outlook.office365.com (2a01:111:e400:401e::38) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Sat, 5 Jul 2014 00:28:50 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD017.mail.protection.outlook.com (10.1.14.105) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Sat, 5 Jul 2014 00:28:49 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Sat, 5 Jul 2014 00:28:13 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JWT Proof-of-Possession draft updated for IETF 90 Thread-Index: Ac+X6ACzX+Hy16s+RX+S+I4f0Y4eEA== Date: Sat, 5 Jul 2014 00:28:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD9B70E@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD9B70ETK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(189002)(199002)(80022001)(19625215002)(20776003)(64706001)(4396001)(33656002)(81542001)(71186001)(81342001)(66066001)(19300405004)(74662001)(74502001)(16297215004)(86362001)(31966008)(84326002)(15202345003)(26826002)(54356999)(50986999)(512954002)(106466001)(99396002)(87936001)(92566001)(92726001)(85852003)(83072002)(86612001)(107886001)(55846006)(95666004)(107046002)(229853001)(83322001)(84676001)(81156004)(16236675004)(85306003)(69596002)(2351001)(2656002)(77096002)(76482001)(79102001)(77982001)(15975445006)(21056001)(6806004)(46102001)(44976005)(68736004)(19580395003)(97736001)(110136001)(104016002)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:CY1PR0301MB1178; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02638D901B Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/pU54dgpjspySEriTxGixnpup-dg Subject: [OAUTH-WG] JWT Proof-of-Possession draft updated for IETF 90 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, 05 Jul 2014 00:29:00 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD9B70ETK5EX14MBXC294r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In preparation for IETF 90 in Toronto, I'v= e update the JWT Proof-of-Possession specification. The changes are mostly= editorial in nature, plus a few changes that hadn't received adequate revi= ew prior to inclusion in the -01 draft were reverted. This specification is available at: * http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-0= 2 An HTML formatted version is also available at: * http://self-issued.info/docs/draft-jones-oauth-proof-of-possession= -02.html -- Mike P.S. I also posted this note at http://self-issued.info/?p=3D1254 and as @= selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439AD9B70ETK5EX14MBXC294r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In preparation for IETF 90 in Toronto, I’ve update the JWT Proof-of-Possession speci= fication.  The changes are mostly editorial in nature, plus a few chan= ges that hadn’t received adequate review prior to inclusion in the -0= 1 draft were reverted.

 

This specification is available at:

·        http://tools.ietf.org/html/draft-jones-= oauth-proof-of-possession-02

 

An HTML formatted version is also available at:=

·        http://self-issued.info/docs/dra= ft-jones-oauth-proof-of-possession-02.html

 

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

 

P.S.  I also posted this note at http://self-issued.info/?p=3D1254 and as @selfissued.

 

--_000_4E1F6AAD24975D4BA5B16804296739439AD9B70ETK5EX14MBXC294r_-- From nobody Sat Jul 5 18:27:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8CB1A0107 for ; Sat, 5 Jul 2014 18:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCuNZ9MaFHxv for ; Sat, 5 Jul 2014 18:27:14 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22ED01A0103 for ; Sat, 5 Jul 2014 18:27:14 -0700 (PDT) Received: from BN3PR0301CA0076.namprd03.prod.outlook.com (25.160.152.172) by BN1PR03MB138.namprd03.prod.outlook.com (10.255.201.13) with Microsoft SMTP Server (TLS) id 15.0.974.11; Sun, 6 Jul 2014 01:27:12 +0000 Received: from BL2FFO11FD020.protection.gbl (2a01:111:f400:7c09::168) by BN3PR0301CA0076.outlook.office365.com (2a01:111:e400:401e::44) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Sun, 6 Jul 2014 01:27:12 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD020.mail.protection.outlook.com (10.173.161.38) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Sun, 6 Jul 2014 01:27:12 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Sun, 6 Jul 2014 01:26:39 +0000 From: Mike Jones To: Nat Sakimura , Justin Richer Thread-Topic: [OAUTH-WG] Agenda requests, please Thread-Index: AQHPlf7xFuaqPZX8TEagH3uKzIdNdJuNrc+AgAJfQQCAAjdhAA== Date: Sun, 6 Jul 2014 01:26:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AD9C46A@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53B41202.8080008@gmx.net> <53B4CA95.3020702@mit.edu> <80DA6959-8A9A-4290-B66C-FC1CAAF1A4FB@gmail.com> In-Reply-To: <80DA6959-8A9A-4290-B66C-FC1CAAF1A4FB@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AD9C46ATK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(189002)(199002)(53754006)(377454003)(479174003)(24454002)(19300405004)(2656002)(92726001)(2171001)(54356999)(20776003)(87936001)(92566001)(44976005)(19580405001)(97736001)(86362001)(86612001)(83072002)(99396002)(106116001)(76176999)(81342001)(26826002)(71186001)(19625215002)(107046002)(110136001)(106466001)(81156004)(50986999)(84326002)(85306003)(77096002)(95666004)(85852003)(104016002)(19580395003)(83322001)(6806004)(512874002)(77982001)(46102001)(15975445006)(84676001)(69596002)(68736004)(76482001)(33656002)(31966008)(74502001)(74662001)(21056001)(4396001)(81542001)(80022001)(16236675004)(66066001)(64706001)(79102001)(15202345003)(55846006); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB138; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0264FEA5C3 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Kd5Pr3VmfTEPCvdVxyfOQoc0D7Q Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Agenda requests, please 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: Sun, 06 Jul 2014 01:27:17 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AD9C46ATK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWQgbGlrZSAxMC0xNSBtaW51dGVzIG9mIGFnZW5kYSB0aW1lIHRvIGRpc2N1c3MgdGhpcyBk cmFmdDoNCg0KwrcgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVz LW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxDQoNCkkgc3VwcG9ydCBOYXQgcHJlc2VudGluZyB0aGUg dHdvIGRyYWZ0cyBiZWxvdyBhbmQgdGhlIHJlc3Qgb2YgdGhlIGFnZW5kYSBzdWdnZXN0aW9ucyB0 aGF0IGhhdmUgYmVlbiBtYWRlLg0KDQpJIGJlbGlldmUgd2Ugc2hvdWxkIGhhdmUgYW4gYWxsLXVw IGRpc2N1c3Npb24gb24gdGhlIG5leHQgc3RlcHMgZm9yIHRoZSBwcm9vZi1vZi1wb3NzZXNzaW9u IGRyYWZ0cywgYW5kIHdpbGwgY29udHJpYnV0ZSwgYnV0IGRvbuKAmXQgZmVlbCBjb21wZWxsZWQg dG8gcHJlc2VudC4NCg0KVGhlIG9uZSBkcmFmdCB0aGF04oCZcyBwZXJ0aW5lbnQgdG8gdGhlIHBy b29mLW9mLXBvc3Nlc3Npb24gd29yayB0aGF0IEkgZG9u4oCZdCBiZWxpZXZlIGhhcyBjb21lIHVw IGluIHRoZSBhZ2VuZGEtc2V0dGluZyBpcyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1yaWNoZXItb2F1dGgtc2lnbmVkLWh0dHAtcmVxdWVzdC0wMS4gIEkgcmVhbGl6ZSB0aGF0IHRo aXMgbWlnaHQgYmUgcHJvYmxlbWF0aWMgdG8gZGlzY3Vzcywgc2luY2UgSnVzdGluIG1heSBub3Qg YmUgYWJsZSB0byBhdHRlbmQsIGJ1dCBJIHdhbnRlZCB1cyB0byBhdCBsZWFzdCBjb25zaWRlciB3 aGV0aGVyIHRvIGluY2x1ZGUgdGhpcyBpbiB0aGUgZGlzY3Vzc2lvbnMuDQoNCkxvb2tpbmcgZm9y d2FyZCB0byBzZWVpbmcgbWFueSBvZiB5b3UgaW4gVG9yb250byENCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpG cm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBO YXQgU2FraW11cmENClNlbnQ6IEZyaWRheSwgSnVseSAwNCwgMjAxNCA4OjI4IEFNDQpUbzogSnVz dGluIFJpY2hlcg0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBB Z2VuZGEgcmVxdWVzdHMsIHBsZWFzZQ0KDQpJIHdvdWxkIGxpa2UgdG8gYnJpbmcgdXAgdGhlIHJl cXVlc3QgYnkgSldTIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2lt dXJhLW9hdXRoLXJlcXVybC0wNSBhbmQgU3ltbWV0cmljIFBvUCBkcmFmdCBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC10Y3NlLTAzLg0KDQo9bmF0IHZpYSBp UGhvbmUNCg0KT24gSnVsIDMsIDIwMTQsIGF0IDEyOjE0LCBKdXN0aW4gUmljaGVyIDxqcmljaGVy QE1JVC5FRFU8bWFpbHRvOmpyaWNoZXJATUlULkVEVT4+IHdyb3RlOg0KTWlrZSBpcyB3b3JraW5n IG9uIGVkaXRvcmlhbCB1cGRhdGVzIHRvIHRoZSBEeW5hbWljIFJlZ2lzdHJhdGlvbiBjb3JlIGRy YWZ0LCBhbmQgSSBhbmQgdGhlIG90aGVyIGVkaXRvcnMgcGxhbiB0byByZXZpZXcgdGhlIGNoYW5n ZXMgc29vbiBhbmQgd2UnbGwgZ2V0IGFuIHVwZGF0ZWQgZHJhZnQgcHVibGlzaGVkIGJlZm9yZSB0 aGUgZGVhZGxpbmUgdGhpcyB3ZWVrLg0KDQpJIHdpbGwgcHVibGlzaCBhIHJlZnJlc2hlZCBUb2tl biBJbnRyb3NwZWN0aW9uIGluZGl2aWR1YWwgc3VibWlzc2lvbiBJRCBmb3IgaW5wdXQgaW50byB0 aGUgV0cgZGlzY3Vzc2lvbiBiZWZvcmUgdGhlIGRlYWRsaW5lLCBhbmQgSSB3b3VsZCBsaWtlIHRv IHNlZSB0aGlzIGJlY29tZSBhIFdHIGl0ZW0uIEl0J3MgYWxyZWFkeSBiZWVuIGluIGRlcGxveW1l bnQgd2l0aCBhIG51bWJlciBvZiBpbXBsZW1lbnRhdGlvbnMgZm9yIHNvbWUgdGltZSBub3csIGFu ZCBJJ20gc2VlaW5nIG9ubHkgaW5jcmVhc2luZyBkZW1hbmQgZm9yIGl0Lg0KDQpJIGRvIG5vdCBh Z3JlZSB0aGF0IHdlIHNob3VsZCBkcm9wIHRoZSBEeW5hbWljIFJlZ2lzdHJhdGlvbiBNYW5hZ2Vt ZW50IGRyYWZ0IGZyb20gdGhlIFdHIGl0ZW1zIGxpc3QuDQoNCiAtLSBKdXN0aW4NCg0KT24gNy8y LzIwMTQgMTA6MDYgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOg0KDQpIaSBhbGwsDQoNCg0K DQpieSBuZXh0IE1vbmRheSB3ZSBoYXZlIHRvIHBvc3QgYSBkcmFmdCBhZ2VuZGEgZm9yIHRoZSB1 cGNvbWluZyBJRVRGDQoNCm1lZXRpbmcuDQoNCg0KDQpJZiB5b3Ugd291bGQgbGlrZSB0byB0YWxr IGFib3V0IGEgc3BlY2lmaWMgdG9waWMsIHBsZWFzZSBsZXQgdXMga25vdy4NCg0KDQoNCk15IGlt cHJlc3Npb24gcmVnYXJkaW5nIHRoZSBzdGF0dXMgb2Ygb3VyIHdvcmsgaXMgdGhlIGZvbGxvd2lu ZzoNCg0KDQoNCg0KDQotLS0tLS0tLSBDdXJyZW50IFdHIGl0ZW1zIC0tLS0tLS0NCg0KDQoNCiog RHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uDQoNCg0KDQpXZSBhcmUgd2FpdGluZyBmb3IgYW4g dXBkYXRlIGJ1dCB0aGUgZG9jdW1lbnQgY291bGQgYmUgY29tcGxldGVkIGJ5IHRoZQ0KDQpJRVRG IG1lZXRpbmcuID09PiBubyBwcmVzZW50YXRpb24gdGltZS4NCg0KDQoNCiogSldUDQoNCg0KDQpD dXJyZW50bHkgaW4gSUVTRyBwcm9jZXNzaW5nIGFuZCBhIG5ldyBkcmFmdCB1cGRhdGUgaGFzIGp1 c3QgYmVlbg0KDQpzdWJtaXR0ZWQuID09PiBubyBwcmVzZW50YXRpb24gdGltZSAoIykNCg0KDQoN CiogQXNzZXJ0aW9uIEJ1bmRsZQ0KDQoNCg0KQ3VycmVudGx5IGluIElFU0cgcHJvY2Vzc2luZy4g PT0+IG5vIHByZXNlbnRhdGlvbiB0aW1lICgjKQ0KDQoNCg0KKiBEeW5hbWljIENsaWVudCBSZWdp c3RyYXRpb24gTWFuYWdlbWVudCBQcm90b2NvbA0KDQoNCg0KV2UgaGFkIGEgZGlzY3Vzc2lvbiBh Ym91dCB0aGlzIHdvcmsgYXQgdGhlIGxhc3QgSUVURiBtZWV0aW5nIGFuZCB0aGUNCg0KcGF0aCBm b3J3YXJkIGxvb2tlZCBzb21ld2hhdCBkaWZmaWN1bHQuIE5vdGhpbmcgaGFzIGhhcHBlbmVkIHNp bmNlIHRoYXQNCg0KdGltZSBhbmQgSSBhbSBpbmNsaW5lZCB0byByZW1vdmUgaXQgZnJvbSB0aGUg bGlzdCBvZiBXRyBpdGVtcy4NCg0KDQoNCiogUHJvb2Ytb2YtUG9zc2Vzc2lvbiBTZWN1cml0eQ0K DQoNCg0KV2UgaGF2ZSBzZXZlcmFsIG5ldyBkb2N1bWVudHMgYW5kIEkgaG9wZSB3ZSBjYW4gdHVy biBpbnRvIHdvcmtpbmcgZ3JvdXANCg0KaXRlbXMgYWxyZWFkeSBiZWZvcmUgdGhlIG1lZXRpbmcu IFdlIHdvdWxkIHRoZW4gdXNlIHRoZSBtZWV0aW5nIHRpbWUgdG8NCg0KZGlzY3VzcyBvcGVuIGlz c3Vlcy4NCg0KDQoNCiM6IE5vIHByZXNlbnRhdGlvbiB0aW1lIHVubGVzcyBzb21lIGNoYWxsZW5n aW5nIGNvbW1lbnRzIGZyb20gdGhlIElFU0cNCg0Kc3VyZmFjZS4NCg0KDQoNCi0tLS0tLS0tIFBy b3Bvc2VkIE5ldyBXRyBpdGVtcyAtLS0tLS0tDQoNCg0KDQpJIHdvdWxkIGFsc28gbGlrZSB0byBw dXQgdGhlIGZvbGxvd2luZyBpdGVtcyBvbiB0aGUgYWdlbmRhLg0KDQoNCg0KKiBUb2tlbiBJbnRy b3NwZWN0aW9uDQoNCg0KDQoqIGRyYWZ0LXNha2ltdXJhLW9hdXRoLXRjc2UtMDMNCg0KDQoNCi0t LS0tLS0tIE90aGVyIGl0ZW1zIC0tLS0tLS0NCg0KDQoNClBoaWwgbWlnaHQgd2FudCB0byBicmlu ZyB1cCB0aGlzIGl0ZW0gc2luY2UgaXQgd2FzIGRpc2N1c3NlZCBvbiB0aGUNCg0KbGlzdDogZHJh ZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yw0KDQoNCg0KT3RoZXIgaWRlYXMvc3VnZ2VzdGlvbnM/ DQoNCg0KDQpDaWFvDQoNCkhhbm5lcw0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQo= --_000_4E1F6AAD24975D4BA5B16804296739439AD9C46ATK5EX14MBXC294r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRl ZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K CWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0NjAyNjU1MDQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2MjI5NjMyMjYgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZZCBsaWtlIDEwLTE1IG1pbnV0 ZXMgb2YgYWdlbmRhIHRpbWUgdG8gZGlzY3VzcyB0aGlzIGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC10b2tlbi1leGNoYW5nZS0wMSI+aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDE8L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JIHN1cHBvcnQgTmF0IHByZXNlbnRpbmcgdGhlIHR3byBkcmFmdHMgYmVsb3cg YW5kIHRoZSByZXN0IG9mIHRoZSBhZ2VuZGEgc3VnZ2VzdGlvbnMgdGhhdCBoYXZlIGJlZW4gbWFk ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgYmVsaWV2ZSB3ZSBzaG91bGQgaGF2ZSBhbiBhbGwtdXAgZGlzY3Vzc2lv biBvbiB0aGUgbmV4dCBzdGVwcyBmb3IgdGhlIHByb29mLW9mLXBvc3Nlc3Npb24gZHJhZnRzLCBh bmQgd2lsbCBjb250cmlidXRlLCBidXQgZG9u4oCZdCBmZWVsIGNvbXBlbGxlZCB0byBwcmVzZW50 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlIG9uZSBkcmFmdCB0aGF04oCZcyBwZXJ0aW5lbnQgdG8gdGhlIHByb29m LW9mLXBvc3Nlc3Npb24gd29yayB0aGF0IEkgZG9u4oCZdCBiZWxpZXZlIGhhcyBjb21lIHVwIGlu IHRoZSBhZ2VuZGEtc2V0dGluZyBpcw0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtcmljaGVyLW9hdXRoLXNpZ25lZC1odHRwLXJlcXVlc3QtMDEiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci1vYXV0aC1zaWduZWQtaHR0cC1yZXF1ZXN0LTAx PC9hPi4mbmJzcDsgSSByZWFsaXplIHRoYXQgdGhpcyBtaWdodCBiZSBwcm9ibGVtYXRpYyB0byBk aXNjdXNzLCBzaW5jZSBKdXN0aW4gbWF5IG5vdCBiZSBhYmxlIHRvIGF0dGVuZCwgYnV0IEkgd2Fu dGVkDQogdXMgdG8gYXQgbGVhc3QgY29uc2lkZXIgd2hldGhlciB0byBpbmNsdWRlIHRoaXMgaW4g dGhlIGRpc2N1c3Npb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TG9va2luZyBmb3J3YXJkIHRvIHNlZWluZyBtYW55 IG9mIHlvdSBpbiBUb3JvbnRvITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5P biBCZWhhbGYgT2YgPC9iPk5hdCBTYWtpbXVyYTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1 bHkgMDQsIDIwMTQgODoyOCBBTTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFJpY2hlcjxicj4NCjxi PkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gQWdlbmRhIHJlcXVlc3RzLCBwbGVhc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBsaWtlIHRvIGJyaW5nIHVwIHRoZSByZXF1 ZXN0IGJ5IEpXUyBkcmFmdCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXNha2ltdXJhLW9hdXRoLXJlcXVybC0wNSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtcmVxdXJsLTA1PC9hPiBhbmQgU3ltbWV0cmljIFBvUCBk cmFmdA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEt b2F1dGgtdGNzZS0wMyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEt b2F1dGgtdGNzZS0wMzwvYT4uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo9bmF0IHZpYSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KT24gSnVsIDMsIDIwMTQsIGF0IDEyOjE0LCBKdXN0aW4gUmljaGVyICZs dDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBNSVQuRURVIj5qcmljaGVyQE1JVC5FRFU8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk1pa2UgaXMgd29ya2luZyBvbiBlZGl0b3JpYWwgdXBkYXRlcyB0byB0aGUg RHluYW1pYyBSZWdpc3RyYXRpb24gY29yZSBkcmFmdCwgYW5kIEkgYW5kIHRoZSBvdGhlciBlZGl0 b3JzIHBsYW4gdG8gcmV2aWV3IHRoZSBjaGFuZ2VzIHNvb24gYW5kIHdlJ2xsIGdldCBhbiB1cGRh dGVkIGRyYWZ0IHB1Ymxpc2hlZCBiZWZvcmUgdGhlIGRlYWRsaW5lIHRoaXMgd2Vlay48YnI+DQo8 YnI+DQpJIHdpbGwgcHVibGlzaCBhIHJlZnJlc2hlZCBUb2tlbiBJbnRyb3NwZWN0aW9uIGluZGl2 aWR1YWwgc3VibWlzc2lvbiBJRCBmb3IgaW5wdXQgaW50byB0aGUgV0cgZGlzY3Vzc2lvbiBiZWZv cmUgdGhlIGRlYWRsaW5lLCBhbmQgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGlzIGJlY29tZSBhIFdH IGl0ZW0uIEl0J3MgYWxyZWFkeSBiZWVuIGluIGRlcGxveW1lbnQgd2l0aCBhIG51bWJlciBvZiBp bXBsZW1lbnRhdGlvbnMgZm9yIHNvbWUgdGltZSBub3csDQogYW5kIEknbSBzZWVpbmcgb25seSBp bmNyZWFzaW5nIGRlbWFuZCBmb3IgaXQuPGJyPg0KPGJyPg0KSSBkbyBub3QgYWdyZWUgdGhhdCB3 ZSBzaG91bGQgZHJvcCB0aGUgRHluYW1pYyBSZWdpc3RyYXRpb24gTWFuYWdlbWVudCBkcmFmdCBm cm9tIHRoZSBXRyBpdGVtcyBsaXN0Lg0KPGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGluPGJyPg0K PGJyPg0KT24gNy8yLzIwMTQgMTA6MDYgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SGkgYWxsLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPmJ5IG5leHQgTW9uZGF5IHdlIGhhdmUgdG8g cG9zdCBhIGRyYWZ0IGFnZW5kYSBmb3IgdGhlIHVwY29taW5nIElFVEY8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5tZWV0aW5nLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPklmIHlvdSB3b3VsZCBsaWtlIHRvIHRhbGsgYWJvdXQgYSBzcGVjaWZpYyB0 b3BpYywgcGxlYXNlIGxldCB1cyBrbm93LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlPk15IGltcHJlc3Npb24gcmVnYXJkaW5nIHRoZSBzdGF0dXMg b2Ygb3VyIHdvcmsgaXMgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4t LS0tLS0tLSBDdXJyZW50IFdHIGl0ZW1zIC0tLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4qIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlv bjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPldl IGFyZSB3YWl0aW5nIGZvciBhbiB1cGRhdGUgYnV0IHRoZSBkb2N1bWVudCBjb3VsZCBiZSBjb21w bGV0ZWQgYnkgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+SUVURiBtZWV0aW5nLiA9PSZndDsg bm8gcHJlc2VudGF0aW9uIHRpbWUuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+KiBKV1Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT5DdXJyZW50bHkgaW4gSUVTRyBwcm9jZXNzaW5nIGFuZCBhIG5l dyBkcmFmdCB1cGRhdGUgaGFzIGp1c3QgYmVlbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnN1Ym1p dHRlZC4gPT0mZ3Q7IG5vIHByZXNlbnRhdGlvbiB0aW1lICgjKTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiogQXNzZXJ0aW9uIEJ1bmRsZTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkN1cnJlbnRs eSBpbiBJRVNHIHByb2Nlc3NpbmcuID09Jmd0OyBubyBwcmVzZW50YXRpb24gdGltZSAoIyk8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4qIER5bmFt aWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBNYW5hZ2VtZW50IFByb3RvY29sPG86cD48L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+V2UgaGFkIGEgZGlzY3Vzc2lv biBhYm91dCB0aGlzIHdvcmsgYXQgdGhlIGxhc3QgSUVURiBtZWV0aW5nIGFuZCB0aGU8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5wYXRoIGZvcndhcmQgbG9va2VkIHNvbWV3aGF0IGRpZmZpY3VsdC4g Tm90aGluZyBoYXMgaGFwcGVuZWQgc2luY2UgdGhhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRp bWUgYW5kIEkgYW0gaW5jbGluZWQgdG8gcmVtb3ZlIGl0IGZyb20gdGhlIGxpc3Qgb2YgV0cgaXRl bXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ KiBQcm9vZi1vZi1Qb3NzZXNzaW9uIFNlY3VyaXR5PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+V2UgaGF2ZSBzZXZlcmFsIG5ldyBkb2N1bWVudHMg YW5kIEkgaG9wZSB3ZSBjYW4gdHVybiBpbnRvIHdvcmtpbmcgZ3JvdXA8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5pdGVtcyBhbHJlYWR5IGJlZm9yZSB0aGUgbWVldGluZy4gV2Ugd291bGQgdGhlbiB1 c2UgdGhlIG1lZXRpbmcgdGltZSB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRpc2N1c3Mgb3Bl biBpc3N1ZXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmU+IzogTm8gcHJlc2VudGF0aW9uIHRpbWUgdW5sZXNzIHNvbWUgY2hhbGxlbmdpbmcgY29t bWVudHMgZnJvbSB0aGUgSUVTRzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnN1cmZhY2UuPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+LS0tLS0tLS0g UHJvcG9zZWQgTmV3IFdHIGl0ZW1zIC0tLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JIHdvdWxkIGFsc28gbGlrZSB0byBwdXQgdGhlIGZv bGxvd2luZyBpdGVtcyBvbiB0aGUgYWdlbmRhLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiogVG9rZW4gSW50cm9zcGVjdGlvbjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiogZHJhZnQtc2FraW11 cmEtb2F1dGgtdGNzZS0wMyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLS0tLSBPdGhlciBpdGVtcyAtLS0t LS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ UGhpbCBtaWdodCB3YW50IHRvIGJyaW5nIHVwIHRoaXMgaXRlbSBzaW5jZSBpdCB3YXMgZGlzY3Vz c2VkIG9uIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmxpc3Q6IGRyYWZ0LWh1bnQtb2F1dGgt djItdXNlci1hNGM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5PdGhlciBpZGVhcy9zdWdnZXN0aW9ucz88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5DaWFvPG86cD48L286cD48L3ByZT4NCjxwcmU+ SGFubmVzPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHBy ZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439AD9C46ATK5EX14MBXC294r_-- From nobody Mon Jul 7 00:07:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C741A0B01 for ; Mon, 7 Jul 2014 00:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAXCtKd97yrE for ; Mon, 7 Jul 2014 00:07:23 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C451A0AE5 for ; Mon, 7 Jul 2014 00:07:22 -0700 (PDT) Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MX1hk-1X9Wg83E1M-00W14C for ; Mon, 07 Jul 2014 09:07:20 +0200 Message-ID: <53BA4727.20904@gmx.net> Date: Mon, 07 Jul 2014 09:07:19 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uLMf1mHjLoiFEa8U26m7Rr1A0OuQ9P7JL" X-Provags-ID: V03:K0:pKGdkvkp2JHtY/Ps4XS5itJFSEQGX9CxEWGDxZzforaIlvraLL3 eaXtCuPgFcbwjjFFRonY+yH/mtiW17W5fkMuUomKFg4pgc3+doDFsFBf2eRFrEC5XkwoxLw PoUzLGGxT4PSQYLBquB3l6k19s9Xsm0pkERirmlR9wkh6nNp8euAt8x3MnjphMhSC0ZLaRC 7x4P3uyTLdvSLPxdY/ztg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/aUOjufzUVcMY2_0P8oh5sIuiNIM Subject: [OAUTH-WG] Agenda Proposal 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, 07 Jul 2014 07:07:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uLMf1mHjLoiFEa8U26m7Rr1A0OuQ9P7JL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Based on your feedback we have prepared an agenda for the upcoming meeting. Let us know what you think. ------------ Web Authorization Protocol (OAuth) THURSDAY, July 24, 2014 1520-1720 EDT Manitoba (MM) - Welcome & Agenda Bashing (Chairs, 15min) (includes status update of the current WG documents in IESG processing)= - Proof-of-Possession Security (Hannes, 15min) http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01 http://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution/= http://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/ http://datatracker.ietf.org/doc/draft-jones-oauth-proof-of-possession/ - Token Introspection (Justin, 15min) http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ - OAuth Symmetric Proof of Posession for Code Extension (Nat, 15min) http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - Providing User Authentication Information to OAuth 2.0 Clients (Phil, 15min) http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c/ - OAuth 2.0 Token Exchange (Mike Jones, 15min) http://tools.ietf.org/html/draft-jones-oauth-token-exchange-01 - Request by JWS ver.1.0 for OAuth 2.0 (Nat, 15min) http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05 - Summary & Next Steps (Chairs, 15min) ------------ Ciao Hannes & Derek --uLMf1mHjLoiFEa8U26m7Rr1A0OuQ9P7JL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTukcnAAoJEGhJURNOOiAtqcAIAKAa3PhyrKlVNAB3qVh3yMwV puwST3ED6b/AMyaaaEIYUmRHOJl+kVO1CicUQW0AVkrgfcfktuyTyyuhdqKc+AbN +3TlmX51W752kfk/iKDWd3c6DxsCxOuQyxlOCkehc5JbyH6qPBtG6k40Y5sEWOcg 8Y3/Le7UA7TIjjf105kdPW9ezmqsun9uEIQ6N6++lpZZlHHu94DpmlQu3z5Wr0+O j4FAyi1eTIcxeUPPo9W1YpG1P/tPmj0kNVfPySRzGZdjocaT3fqgDIC5JvVOPrT/ EIzpk4QKJK9LE8IlucYEuBEcIS38T0J89x0wOLBqheNUlHny6J510PJ8gkWKACk= =eC1p -----END PGP SIGNATURE----- --uLMf1mHjLoiFEa8U26m7Rr1A0OuQ9P7JL-- From nobody Mon Jul 7 13:14:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48741B28AB for ; Mon, 7 Jul 2014 13:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 9pwm7TRgOr5m for ; Mon, 7 Jul 2014 13:14:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C7B041B28B4 for ; Mon, 7 Jul 2014 13:14:32 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 40B7D1F027E; Mon, 7 Jul 2014 16:14:32 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 31A641F08AE; Mon, 7 Jul 2014 16:14:32 -0400 (EDT) Received: from [10.146.15.61] (10.140.19.249) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 7 Jul 2014 16:14:31 -0400 Message-ID: <53BAFF8E.2020201@mitre.org> Date: Mon, 7 Jul 2014 16:14:06 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , "oauth@ietf.org" References: <53BA4727.20904@gmx.net> In-Reply-To: <53BA4727.20904@gmx.net> Content-Type: multipart/alternative; boundary="------------070607010705020105020305" X-Originating-IP: [10.140.19.249] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/sGvBo33pcaBo9X5mInFyyi23Qh0 Subject: Re: [OAUTH-WG] Agenda Proposal 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, 07 Jul 2014 20:14:40 -0000 --------------070607010705020105020305 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Looks like I have managed to work things out such that I will be in town for the OAuth meeting after all, so I'll see you all there. Additionally, we were just able to post a new draft of the Introspection document fixing the handful of comments that came out last Friday, Draft 06 is here: http://tools.ietf.org/html/draft-richer-oauth-introspection-06 -- Justin On 07/07/2014 03:07 AM, Hannes Tschofenig wrote: > Based on your feedback we have prepared an agenda for the upcoming > meeting. Let us know what you think. > > ------------ > > > Web Authorization Protocol (OAuth) > > THURSDAY, July 24, 2014 > > 1520-1720 EDT > Manitoba (MM) > > - Welcome & Agenda Bashing (Chairs, 15min) > (includes status update of the current WG documents in IESG processing) > > - Proof-of-Possession Security (Hannes, 15min) > http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01 > http://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution/ > http://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/ > http://datatracker.ietf.org/doc/draft-jones-oauth-proof-of-possession/ > > - Token Introspection (Justin, 15min) > http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ > > - OAuth Symmetric Proof of Posession for Code Extension (Nat, 15min) > http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 > > - Providing User Authentication Information to OAuth 2.0 Clients (Phil, > 15min) > http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c/ > > - OAuth 2.0 Token Exchange (Mike Jones, 15min) > http://tools.ietf.org/html/draft-jones-oauth-token-exchange-01 > > - Request by JWS ver.1.0 for OAuth 2.0 (Nat, 15min) > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05 > > - Summary & Next Steps (Chairs, 15min) > > ------------ > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------070607010705020105020305 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Looks like I have managed to work things out such that I will be in town for the OAuth meeting after all, so I'll see you all there.

Additionally, we were just able to post a new draft of the Introspection document fixing the handful of comments that came out last Friday, Draft 06 is here:

http://tools.ietf.org/html/draft-richer-oauth-introspection-06

 -- Justin

On 07/07/2014 03:07 AM, Hannes Tschofenig wrote:
Based on your feedback we have prepared an agenda for the upcoming
meeting. Let us know what you think.

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


Web Authorization Protocol (OAuth)

THURSDAY, July 24, 2014

1520-1720 EDT
Manitoba (MM)

- Welcome & Agenda Bashing (Chairs, 15min)
  (includes status update of the current WG documents in IESG processing)

- Proof-of-Possession Security (Hannes, 15min)
http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01
http://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution/
http://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/
http://datatracker.ietf.org/doc/draft-jones-oauth-proof-of-possession/

- Token Introspection (Justin, 15min)
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

- OAuth Symmetric Proof of Posession for Code Extension (Nat, 15min)
http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03

- Providing User Authentication Information to OAuth 2.0 Clients (Phil,
15min)
http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c/

- OAuth 2.0 Token Exchange (Mike Jones, 15min)
http://tools.ietf.org/html/draft-jones-oauth-token-exchange-01

- Request by JWS ver.1.0 for OAuth 2.0 (Nat, 15min)
http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05

- Summary & Next Steps (Chairs, 15min)

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

Ciao
Hannes & Derek




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

--------------070607010705020105020305-- From nobody Mon Jul 7 13:59:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85101B28D3 for ; Mon, 7 Jul 2014 13:59:19 -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 veuJHAJgDJ9i for ; Mon, 7 Jul 2014 13:59:17 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6341A0A88 for ; Mon, 7 Jul 2014 13:59:16 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u57so4916985wes.3 for ; Mon, 07 Jul 2014 13:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/Fn3NV52JRPgkD9uK7GBg26cC0GUm2hT/EGBAYEpzw0=; b=C2bvsrYOmZ5G3X1jNPYOqjll13kNQYM9mkv3A6MAqSxx2jSJm6tHcIPU7gl/ETQvha J6jTufRj+iP8y340aJf3bYsuTKlAko5EV3Xk3bqpdXwZWU5X7sTzteyIjoaOmZ8ep62m fxuy6NGl/F0SF9ZnxraTll/7xZnzUBaBQuaoFW2BM2ZlJ9rxnS2bHSTgCZqbA04DzoNG emo1UqCqFAnwZEPkH8B0Qz5qBLROAYdNMe7Hsx5k2S+b/dO8NJiYvgAA4POM5X/eMgDq exqWz4LOECOSnc7ynAL46Uy1222uVzZ7HUUGXvp1Fu2ravFSTDfKTjJI5JYDVFWgVar5 EwKg== X-Received: by 10.180.183.167 with SMTP id en7mr79885456wic.6.1404766754830; Mon, 07 Jul 2014 13:59:14 -0700 (PDT) Received: from [192.168.2.7] ([109.255.82.12]) by mx.google.com with ESMTPSA id 10sm54705498wjr.22.2014.07.07.13.59.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 13:59:13 -0700 (PDT) Message-ID: <53BB0A20.6020009@gmail.com> Date: Mon, 07 Jul 2014 21:59:12 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Bradley References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> <53B53F7C.506@gmail.com> <1404402057.15252.YahooMailNeo@web142801.mail.bf1.yahoo.com> <53B584BA.6090901@gmail.com> <38EB3E9D-BA98-4A48-89A7-48C57F501238@ve7jtb.com> In-Reply-To: <38EB3E9D-BA98-4A48-89A7-48C57F501238@ve7jtb.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/rfZnXwTsIAfdcazOSdKgOP00MXY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] refresh tokens and client instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 20:59:19 -0000 Hi John, All, On 03/07/14 23:02, John Bradley wrote: > Yes, > > The the undifferentiated is initially differentiated by the user during Authorization by having a code returned and then by exchanging the code for a refresh token. > It however returns to being undifferentiated on subsequent authorization requests. > This makes having sticky grants (only asking for permission for incremental scopes) a potential security problem, as the AS has no way to know if the client is the one that the pervious authorization was intended for. > > Some AS just assume that you want the same permissions across all instances of a client, however if this is a public client then someone could impersonate the client app and basically do privilege escalation. > Why would a public client holding a refresh token securely entered into it by a user request a new authorization without actually requesting the new scopes ? The client can just get a new access/refresh token from now on ? > What dynamic client registration gives us for native apps is a way to identify specific instances of clients at the authorization endpoint by having different client_id and validating that with instance specific client credentials. This also prevents the use of code if it is intercepted in the reply from the authorization endpoint. > Would it be fair to say that a dynamic client registration is a preferred method of registering *public* clients from now on, *unless* no sticky grants are used in which case a typical/default registration mode is OK ? Thanks, Sergey > John B. > > On Jul 3, 2014, at 12:28 PM, Sergey Beryozkin wrote: > >> Hi >> On 03/07/14 16:40, Bill Mills wrote: >>> Implementations may/SHOULD bind refresh tokens to specific client >>> instances. Yes, it's possible that the client ID with dynamic >>> registration is unique to each client, but many of the token theft use >>> cases include the possibility of stealing the client ID too if you know >>> you need to. >>> >> What exactly is a 'client instance' when we talk about having a single client id registration, with the id shared between multiple devices (which is what I believe this thread started from). >> >> What I understood, as far as the authorization service is concerned, a 'client instance' for AS is a combination of a client id + code grant. >> >> + (optional) refresh token (as was mentioned earlier). But it appears to me a client instance can be uniquely identified by two values only without a refresh token. >> >> When a user authorizes a given device and gets a grant code and enters it into the device securely we have a 'client instance' ready to get the tokens, with that device (client instance) using a client id and the grant code to get an access token and a refresh token. >> >> Lets say it sends a "client_id=1&code=2" sequence to get the tokens. >> A client id + a code value constitutes a client instance, because a code would be unique per every authorization, right ? >> >> So the service will return an access token + refresh token to the device. Refresh Token could've been associated with a record containing a client id + grant code info earlier or at the moment the code is exchanged for an access token. >> >> During the subsequent refresh token grant request we have "client id + refresh token" as a client instance. >> >> I'm not sure what exactly I'd like to ask here :-), but I wonder if the above sounds right, then I guess I'd like to conclude that when we talk about the authorization code grant then a refresh token is not the only key that uniquely identifies a client instance: >> >> Initially it is a client id + code grant, a refresh token does not offer an extra uniqueness at the point of the client device requesting an access token with a code. Refresh token only starts acting as the key client instance identifier at a refresh token grant time. >> >> Sorry for a long email, I'm very likely missing something, so any clarifications will be welcome >> >> Thanks, Sergey >> >> >> >> >> >> >> >>> -bill >>> >>> >>> On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin >>> wrote: >>> >>> >>> Hi >>> >>> I'm finding the answers from John interesting but I'm failing to >>> understand why refresh tokens are mentioned in scope of identifying the >>> specific client instances. >>> >>> AFAIK refresh tokens would only go on the wire, assuming they are >>> supported, when a client exchanges a grant for a new access token. >>> And when the client uses a refresh token grant. >>> >>> Was it really about a refresh token grant where the incoming client id >>> and refresh token pair can uniquely identify the actual client instance >>> ? That would make sense. >>> >>> Something else I'd like to clarify. >>> John mentions a refresh token is created at the authorization grant >>> initialization time. Would it make any difference, as far as the >>> security properties of a grant are concerned, if refresh token was only >>> created at a grant to access token exchange point of time ? >>> >>> Thanks, Sergey >>> >>> On 27/06/14 19:21, John Bradley wrote: >>>> Inline >>>> >>>> On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri >> >>>> >> wrote: >>>> >>>>> Hi John, >>>>> Thank you for your reply. Would appreciate if you consider my inline >>>>> comments below and respond again! >>>>> R, >>>>> Madjid >>>>> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com >>> ] >>>>> *Sent:*Wednesday, June 25, 2014 5:56 PM >>>>> *To:*Madjid Nakhjiri >>>>> *Cc:*oauth@ietf.org >> > >>>>> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances >>>>> In 3.3 It is saying that the refresh token is a secret that the >>>>> Authorization server has bound to the client_id, that the >>>>> Authorization server effectively uses to differentiate between >>>>> instances of that client_id. >>>>> Madjid>>If I have 10,000s of devices, each with an instance of the >>>>> OAUTH client, but they are all using the same client ID, how would the >>>>> server know which token to use for what client? unless when I am >>>>> creating a token, I also include something that uniquely identifies >>>>> each instance? Don’t I have to use SOMETHING that is unique to that >>>>> instance (user grant/ID?)? >>>> When the grant is issued you create and store a refresh token which is >>>> effectively the identifier for that instance/grant combination. >>>> When it comes back on a request to the token endpoint you look up the >>>> grants associated with it. You also hack that the client_id sent in >>>> the request matches to detect errors mostly) >>>> >>>>> When the refresh token is generated, it can be stored in a table with >>>>> the client_id and the information about the grant. You could also do >>>>> it statelesly by creating a signed object as the refresh token. >>>>> Madjid>>agreed, but for the signed object to be self-sustained, again >>>>> would I not need something beyond a “population” client_ID? Are we >>>>> prescriptive what “information about the grant” is? >>>> You would be creating a bearer token as long as the AS signs it you can >>>> put whatever grant grant info you like in it, that is implementation >>>> specific. It could be a list of the scopes granted and the subject. >>>>> The spec is silent on the exact programming method that the >>>>> Authorization server uses. >>>>> Madjid>>Are there any other specs in IETF or elsewhere (OASIS, etc?) >>>>> that prescribe token calculation (e.g. hash function, parameters, etc)? >>>> >>>> You can look at JOSE and JWT for a way to create tokens >>>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token >>>>> In 3.7 Deployment independent describes using the same client_id >>>>> across multiple instances of a native client, or multiple instances of >>>>> a Java Script client running in a browsers with the same callback uri. >>>>> Since the publishing of this RFC we have also developed a spec for >>>>> dynamic client registration so it is possible to give every native >>>>> client it's own client_id and secret making them confidential clients. >>>>> Madjid>>I would need to look at those specs, however, I thought that >>>>> the “confidential client” designation has to do with the client >>>>> ability to hold secrets and perform a-by-server-acceptable >>>>> authentication. Does dynamic client registration affect client’s >>>>> ability in that aspect? >>>> >>>> Yes it doesn't require the secret to be in the downloaded instance of >>>> the native app. It can be populated at first run, changing it from >>>> public to confidential. >>>> Confidential is not just for web servers any more. >>>>> There is also a middle ground some people take by doing a proof of >>>>> possession for code in native applications to prevent the interception >>>>> of responses to the client by malicious applications on the device. >>>>> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ >>>>> John B. >>>>> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri >> >>>>> >> wrote: >>>>> >>>>> >>>>> Hi all, >>>>> I am new to OAUTH list and OAUTH, so apologies if this is very >>> off-topic. >>>>> I am evaluating an OAUTH 2.0 implementation that is done based on bare >>>>> bone base OAUTH2.0 RFC. From what I understand, many (or some) client >>>>> implementations use a “global ID/secret” pair for all instances of the >>>>> client. Looking at RFC 6819 and there seem to be a whole page on this >>>>> topic, if I understand it correctly. So questions: >>>>> 1)Section 3.7 talks about deployment-independent versus deployment >>>>> specific client IDs. I am guessing “deployment-independent” refers to >>>>> what I called “global”, meaning if I have the same client with the >>>>> same client ID installed in many end devices, that is a deployment >>>>> independent case, correct? >>>>> 2)Section 3.3 on refresh token mentions that the token is secret bound >>>>> to the client ID and client instance. Could somebody please point me >>>>> to where the token generation and binding is described? Also how is >>>>> the client instance is identified? >>>>> Thanks a lot in advance, >>>>> Madjid Nakhjiri >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >> > >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From nobody Mon Jul 7 14:09:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766AB1B28E6 for ; Mon, 7 Jul 2014 14:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0Qa7OmjwOo0 for ; Mon, 7 Jul 2014 14:09:33 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3812A1B28E1 for ; Mon, 7 Jul 2014 14:09:33 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l6so4341838qcy.4 for ; Mon, 07 Jul 2014 14:09:32 -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=s8UHPNbUlSU/vTbgCEDiuXDYDJghrgN1RXiSaq+Tmuw=; b=ev2uRZY6znFsl5PZao68cAuYxEOfHjkadNctLPyyJLvFd5rvJZ8UhEsqR2eLzUk7zs Mq0axKG2fAvoktu/kFXw4Z0Dag6KJ/pw0htT/kA23dLX6TMv+Goy8+y1Nk0TklaQODqT m7keqLr6Aa55m4FtrznVazbwPYL1s8GMNBRVvXgIHj8ZAbZYCsyBd2xBk6r2NXcbADom QNtSkxwKbXjkst9hmvMH1wJR6I+30KKp/RTQuM3dEHte6PCO6zqp0ZrEOf04X0nkMLBX QGsEr/5kgMgOr10b1jIY68AnV8x9n/+qrQlQzL+qgY8Qp44dGDZCgihKNr5l9TdnLuJO PUGg== X-Gm-Message-State: ALoCoQlGA33WBdUNpelZUL0tkull4w/EHaFg2vARuOZW6yi4j9ATWpWfv1QFtoXljWZuI46BFeSt X-Received: by 10.140.93.35 with SMTP id c32mr40246803qge.53.1404767372216; Mon, 07 Jul 2014 14:09:32 -0700 (PDT) Received: from [192.168.0.200] ([201.188.84.221]) by mx.google.com with ESMTPSA id q10sm76481509qah.9.2014.07.07.14.09.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 14:09:31 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <53BB0A20.6020009@gmail.com> Date: Mon, 7 Jul 2014 17:09:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> <53B53F7C.506@gmail.com> <1404402057.15252.YahooMailNeo@web142801.mail.bf1.yahoo.com> <53B584BA.6090901@gmail.com> <38EB3E9D-BA98-4A48-89A7-48C57F501238@ve7jtb.com> <53BB0A20.6020009@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Hk_758M4QboqstFbJjcVrO06Lso Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] refresh tokens and client instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:09:36 -0000 Inline On Jul 7, 2014, at 4:59 PM, Sergey Beryozkin = wrote: > Hi John, All, > On 03/07/14 23:02, John Bradley wrote: >> Yes, >>=20 >> The the undifferentiated is initially differentiated by the user = during Authorization by having a code returned and then by exchanging = the code for a refresh token. >> It however returns to being undifferentiated on subsequent = authorization requests. >> This makes having sticky grants (only asking for permission for = incremental scopes) a potential security problem, as the AS has no way = to know if the client is the one that the pervious authorization was = intended for. >>=20 >> Some AS just assume that you want the same permissions across all = instances of a client, however if this is a public client then someone = could impersonate the client app and basically do privilege escalation. >>=20 > Why would a public client holding a refresh token securely entered = into it by a user request a new authorization without actually = requesting the new scopes ? The client can just get a new access/refresh = token from now on ? A client holding a refresh token may want to add additional scopes, = perhaps it only initially asked for permission to get a email address = and now it wants a phone number. If it is a public client the AS needs to ask for permission to grant = both scopes, it can't treat the email permission as sticky. >=20 >> What dynamic client registration gives us for native apps is a way to = identify specific instances of clients at the authorization endpoint by = having different client_id and validating that with instance specific = client credentials. This also prevents the use of code if it is = intercepted in the reply from the authorization endpoint. >>=20 > Would it be fair to say that a dynamic client registration is a = preferred method of registering *public* clients from now on, *unless* > no sticky grants are used in which case a typical/default registration = mode is OK ? It is up to the AS and how it wants to manage clients. Some will not = want to manage thousands of client_id, others won't mind. =20 If you don't have sticky grants and can mitigate code being intercepted = in the response by using = http://tools.ietf.org/html/draft-sakimura-oauth-tcse , then having a public client works. >=20 > Thanks, Sergey >=20 >> John B. >>=20 >> On Jul 3, 2014, at 12:28 PM, Sergey Beryozkin = wrote: >>=20 >>> Hi >>> On 03/07/14 16:40, Bill Mills wrote: >>>> Implementations may/SHOULD bind refresh tokens to specific client >>>> instances. Yes, it's possible that the client ID with dynamic >>>> registration is unique to each client, but many of the token theft = use >>>> cases include the possibility of stealing the client ID too if you = know >>>> you need to. >>>>=20 >>> What exactly is a 'client instance' when we talk about having a = single client id registration, with the id shared between multiple = devices (which is what I believe this thread started from). >>>=20 >>> What I understood, as far as the authorization service is concerned, = a 'client instance' for AS is a combination of a client id + code grant. >>>=20 >>> + (optional) refresh token (as was mentioned earlier). But it = appears to me a client instance can be uniquely identified by two values = only without a refresh token. >>>=20 >>> When a user authorizes a given device and gets a grant code and = enters it into the device securely we have a 'client instance' ready to = get the tokens, with that device (client instance) using a client id and = the grant code to get an access token and a refresh token. >>>=20 >>> Lets say it sends a "client_id=3D1&code=3D2" sequence to get the = tokens. >>> A client id + a code value constitutes a client instance, because a = code would be unique per every authorization, right ? >>>=20 >>> So the service will return an access token + refresh token to the = device. Refresh Token could've been associated with a record containing = a client id + grant code info earlier or at the moment the code is = exchanged for an access token. >>>=20 >>> During the subsequent refresh token grant request we have "client id = + refresh token" as a client instance. >>>=20 >>> I'm not sure what exactly I'd like to ask here :-), but I wonder if = the above sounds right, then I guess I'd like to conclude that when we = talk about the authorization code grant then a refresh token is not the = only key that uniquely identifies a client instance: >>>=20 >>> Initially it is a client id + code grant, a refresh token does not = offer an extra uniqueness at the point of the client device requesting = an access token with a code. Refresh token only starts acting as the key = client instance identifier at a refresh token grant time. >>>=20 >>> Sorry for a long email, I'm very likely missing something, so any = clarifications will be welcome >>>=20 >>> Thanks, Sergey >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> -bill >>>>=20 >>>>=20 >>>> On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin >>>> wrote: >>>>=20 >>>>=20 >>>> Hi >>>>=20 >>>> I'm finding the answers from John interesting but I'm failing to >>>> understand why refresh tokens are mentioned in scope of identifying = the >>>> specific client instances. >>>>=20 >>>> AFAIK refresh tokens would only go on the wire, assuming they are >>>> supported, when a client exchanges a grant for a new access token. >>>> And when the client uses a refresh token grant. >>>>=20 >>>> Was it really about a refresh token grant where the incoming client = id >>>> and refresh token pair can uniquely identify the actual client = instance >>>> ? That would make sense. >>>>=20 >>>> Something else I'd like to clarify. >>>> John mentions a refresh token is created at the authorization grant >>>> initialization time. Would it make any difference, as far as the >>>> security properties of a grant are concerned, if refresh token was = only >>>> created at a grant to access token exchange point of time ? >>>>=20 >>>> Thanks, Sergey >>>>=20 >>>> On 27/06/14 19:21, John Bradley wrote: >>>>> Inline >>>>>=20 >>>>> On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri = >>> >>>>> >> = wrote: >>>>>=20 >>>>>> Hi John, >>>>>> Thank you for your reply. Would appreciate if you consider my = inline >>>>>> comments below and respond again! >>>>>> R, >>>>>> Madjid >>>>>> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com >>>> ] >>>>>> *Sent:*Wednesday, June 25, 2014 5:56 PM >>>>>> *To:*Madjid Nakhjiri >>>>>> *Cc:*oauth@ietf.org = >>> > >>>>>> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances >>>>>> In 3.3 It is saying that the refresh token is a secret that the >>>>>> Authorization server has bound to the client_id, that the >>>>>> Authorization server effectively uses to differentiate between >>>>>> instances of that client_id. >>>>>> Madjid>>If I have 10,000s of devices, each with an instance of = the >>>>>> OAUTH client, but they are all using the same client ID, how = would the >>>>>> server know which token to use for what client? unless when I am >>>>>> creating a token, I also include something that uniquely = identifies >>>>>> each instance? Don=92t I have to use SOMETHING that is unique to = that >>>>>> instance (user grant/ID?)? >>>>> When the grant is issued you create and store a refresh token = which is >>>>> effectively the identifier for that instance/grant combination. >>>>> When it comes back on a request to the token endpoint you look up = the >>>>> grants associated with it. You also hack that the client_id sent = in >>>>> the request matches to detect errors mostly) >>>>>=20 >>>>>> When the refresh token is generated, it can be stored in a table = with >>>>>> the client_id and the information about the grant. You could = also do >>>>>> it statelesly by creating a signed object as the refresh token. >>>>>> Madjid>>agreed, but for the signed object to be self-sustained, = again >>>>>> would I not need something beyond a =93population=94 client_ID? = Are we >>>>>> prescriptive what =93information about the grant=94 is? >>>>> You would be creating a bearer token as long as the AS signs it = you can >>>>> put whatever grant grant info you like in it, that is = implementation >>>>> specific. It could be a list of the scopes granted and the = subject. >>>>>> The spec is silent on the exact programming method that the >>>>>> Authorization server uses. >>>>>> Madjid>>Are there any other specs in IETF or elsewhere (OASIS, = etc?) >>>>>> that prescribe token calculation (e.g. hash function, parameters, = etc)? >>>>>=20 >>>>> You can look at JOSE and JWT for a way to create tokens >>>>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token >>>>>> In 3.7 Deployment independent describes using the same client_id >>>>>> across multiple instances of a native client, or multiple = instances of >>>>>> a Java Script client running in a browsers with the same callback = uri. >>>>>> Since the publishing of this RFC we have also developed a spec = for >>>>>> dynamic client registration so it is possible to give every = native >>>>>> client it's own client_id and secret making them confidential = clients. >>>>>> Madjid>>I would need to look at those specs, however, I thought = that >>>>>> the =93confidential client=94 designation has to do with the = client >>>>>> ability to hold secrets and perform a-by-server-acceptable >>>>>> authentication. Does dynamic client registration affect client=92s >>>>>> ability in that aspect? >>>>>=20 >>>>> Yes it doesn't require the secret to be in the downloaded instance = of >>>>> the native app. It can be populated at first run, changing it = from >>>>> public to confidential. >>>>> Confidential is not just for web servers any more. >>>>>> There is also a middle ground some people take by doing a proof = of >>>>>> possession for code in native applications to prevent the = interception >>>>>> of responses to the client by malicious applications on the = device. >>>>>> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ >>>>>> John B. >>>>>> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri = >>> >>>>>> >> = wrote: >>>>>>=20 >>>>>>=20 >>>>>> Hi all, >>>>>> I am new to OAUTH list and OAUTH, so apologies if this is very >>>> off-topic. >>>>>> I am evaluating an OAUTH 2.0 implementation that is done based on = bare >>>>>> bone base OAUTH2.0 RFC. =46rom what I understand, many (or some) = client >>>>>> implementations use a =93global ID/secret=94 pair for all = instances of the >>>>>> client. Looking at RFC 6819 and there seem to be a whole page on = this >>>>>> topic, if I understand it correctly. So questions: >>>>>> 1)Section 3.7 talks about deployment-independent versus = deployment >>>>>> specific client IDs. I am guessing =93deployment-independent=94 = refers to >>>>>> what I called =93global=94, meaning if I have the same client = with the >>>>>> same client ID installed in many end devices, that is a = deployment >>>>>> independent case, correct? >>>>>> 2)Section 3.3 on refresh token mentions that the token is secret = bound >>>>>> to the client ID and client instance. Could somebody please point = me >>>>>> to where the token generation and binding is described? Also how = is >>>>>> the client instance is identified? >>>>>> Thanks a lot in advance, >>>>>> Madjid Nakhjiri >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>> > >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From nobody Mon Jul 7 14:17:45 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7D41B28E6 for ; Mon, 7 Jul 2014 14:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwbMDxcMUqH7 for ; Mon, 7 Jul 2014 14:17:41 -0700 (PDT) Received: from usmailout2.samsung.com (mailout2.w2.samsung.com [211.189.100.12]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90CA81B28B5 for ; Mon, 7 Jul 2014 14:17:41 -0700 (PDT) Received: from uscpsbgm1.samsung.com (u114.gpu85.samsung.co.kr [203.254.195.114]) by mailout2.w2.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N8D00BTL1TFKF40@mailout2.w2.samsung.com> for oauth@ietf.org; Mon, 07 Jul 2014 17:17:39 -0400 (EDT) X-AuditID: cbfec372-b7fe76d00000687e-b1-53bb0e73925d Received: from ussync4.samsung.com ( [203.254.195.84]) by uscpsbgm1.samsung.com (USCPMTA) with SMTP id AA.1E.26750.37E0BB35; Mon, 07 Jul 2014 17:17:39 -0400 (EDT) Received: from sdsamadjidPC ([105.66.230.137]) by ussync4.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0N8D00DK21TE7J80@ussync4.samsung.com>; Mon, 07 Jul 2014 17:17:39 -0400 (EDT) From: Madjid Nakhjiri To: 'Sergey Beryozkin' , 'Bill Mills' , oauth@ietf.org References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> <53B53F7C.506@gmail.com> <1404402057.15252.YahooMailNeo@web142801.mail.bf1.yahoo.com> <53B584BA.6090901@gmail.com> In-reply-to: <53B584BA.6090901@gmail.com> Date: Mon, 07 Jul 2014 14:17:38 -0700 Message-id: <014901cf9a28$e232c0a0$a69841e0$%nakhjiri@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Ac+W2/PXSWANGjH0QHejK5/KPkhRUQDS3Fzg Content-language: en-us X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsVy+t/hEN1ivt3BBvM+KVj0NixhtDj59hWb xb+l9hbfuq4zO7B47Jx1l91jyZKfTB59W1YxesyadZgpgCWKyyYlNSezLLVI3y6BK+Pfh5fM BdfCKw48v8PWwNjv1sXIySEhYCLx/Ol2RghbTOLCvfVsXYxcHEICSxgltr/5yQzhtDBJnJzz jgWkik1AT2L/vBnMILaIQJrE146vTF2MHBzMQPGlf/Uh6m8xScxZvA5sKqeApsTjp2dYQWxh AWuJN+uOg/WyCKhKTDn1HszmFXCS2DF5IhuELSjxY/I9FoiZ6hJTpuSChJkFtCWevLvAChKW AAo/+qsLcYGRxNnFHxghSsQlJj14yD6BUWgWkkGzEAbNQjJoFpKOBYwsqxhFS4uTC4qT0nMN 9YoTc4tL89L1kvNzNzFCIqBoB+OzDVaHGAU4GJV4eDV27wwWYk0sK67MPcQowcGsJMK7Yvmu YCHelMTKqtSi/Pii0pzU4kOMTBycUg2MOcy2/7vXxb5xXfZx+yVh9c0HpthsvV9luMzo2obf RhEH3n30v6ARlSVqNonx6X37Tr8/3oocRgFfF/uX8kw7Fjp1sVb3lqYND14K312b2CkRdCbz r1T82e3TJyk6FdhwMSmxTHAtEHqr5PpumdGCC8uUL9zccrypZM8Sjjcfv228sNqD49ISbSWW 4oxEQy3mouJEAAeiAdVeAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lGmVu5zWgNHfsk0YHC8Qx-s71x0 Subject: Re: [OAUTH-WG] refresh tokens and client instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:17:44 -0000 Hi Sergey, Thanks for capturing the question. Yes, the issue was how we distinguish = between different instances of client, all using the same client ID. = >From answers I have gotten so far, it seems that the uniqueness of the = instance may be provided through the uniqueness of a code grant. = However, I have not figure out what the spec says on how to create the = grant and how the grant code is unique to authorization server. If = anybody could point me to that part of spec, I would appreciate it (I = did not find it).=20 Your description of "a user authorizes a given device and gets a grant = code and enters it into device securely we have a client instance..." = would require a device identifier, otherwise how does the fact that the = client is on a different device identifies that instance as a unique = instance? I need to look at the spec for refresh versus access tokens. Do you need = different grant code types for each type of token? Thanks, Madjid -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Sergey = Beryozkin Sent: Thursday, July 03, 2014 9:29 AM To: Bill Mills; oauth@ietf.org Subject: Re: [OAUTH-WG] refresh tokens and client instances Hi On 03/07/14 16:40, Bill Mills wrote: > Implementations may/SHOULD bind refresh tokens to specific client=20 > instances. Yes, it's possible that the client ID with dynamic=20 > registration is unique to each client, but many of the token theft use = > cases include the possibility of stealing the client ID too if you=20 > know you need to. > What exactly is a 'client instance' when we talk about having a single = client id registration, with the id shared between multiple devices = (which is what I believe this thread started from). What I understood, as far as the authorization service is concerned, a = 'client instance' for AS is a combination of a client id + code grant. + (optional) refresh token (as was mentioned earlier). But it appears to me a client instance can be uniquely identified by two values only = without a refresh token. When a user authorizes a given device and gets a grant code and enters = it into the device securely we have a 'client instance' ready to get the = tokens, with that device (client instance) using a client id and the = grant code to get an access token and a refresh token. Lets say it sends a "client_id=3D1&code=3D2" sequence to get the tokens. A client id + a code value constitutes a client instance, because a code = would be unique per every authorization, right ? So the service will return an access token + refresh token to the = device. Refresh Token could've been associated with a record containing = a client id + grant code info earlier or at the moment the code is = exchanged for an access token. During the subsequent refresh token grant request we have "client id + = refresh token" as a client instance. I'm not sure what exactly I'd like to ask here :-), but I wonder if the = above sounds right, then I guess I'd like to conclude that when we talk = about the authorization code grant then a refresh token is not the only = key that uniquely identifies a client instance: Initially it is a client id + code grant, a refresh token does not offer = an extra uniqueness at the point of the client device requesting an = access token with a code. Refresh token only starts acting as the key = client instance identifier at a refresh token grant time. Sorry for a long email, I'm very likely missing something, so any = clarifications will be welcome Thanks, Sergey > -bill > > > On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin=20 > wrote: > > > Hi > > I'm finding the answers from John interesting but I'm failing to=20 > understand why refresh tokens are mentioned in scope of identifying=20 > the specific client instances. > > AFAIK refresh tokens would only go on the wire, assuming they are=20 > supported, when a client exchanges a grant for a new access token. > And when the client uses a refresh token grant. > > Was it really about a refresh token grant where the incoming client id = > and refresh token pair can uniquely identify the actual client=20 > instance ? That would make sense. > > Something else I'd like to clarify. > John mentions a refresh token is created at the authorization grant=20 > initialization time. Would it make any difference, as far as the=20 > security properties of a grant are concerned, if refresh token was=20 > only created at a grant to access token exchange point of time ? > > Thanks, Sergey > > On 27/06/14 19:21, John Bradley wrote: > > Inline > > > > On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri=20 > >=20 > >> = wrote: > > > >> Hi John, > >> Thank you for your reply. Would appreciate if you consider my=20 > inline >> comments below and respond again! > >> R, > >> Madjid > >> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com=20 > ] >> *Sent:*Wednesday, June 25, 2014 5:56=20 > PM >> *To:*Madjid Nakhjiri >> *Cc:*oauth@ietf.org=20 > > >> *Subject:*Re: [OAUTH-WG] refresh tokens=20 > and client instances >> In 3.3 It is saying that the refresh token is = > a secret that the >> Authorization server has bound to the client_id, = > that the >> Authorization server effectively uses to differentiate=20 > between >> instances of that client_id. > >> Madjid>>If I have 10,000s of devices, each with an instance of the = =20 > >> OAUTH client, but they are all using the same client ID, how would=20 > the >> server know which token to use for what client? unless when I=20 > am >> creating a token, I also include something that uniquely=20 > identifies >> each instance? Don=E2=80=99t I have to use SOMETHING = that is=20 > unique to that >> instance (user grant/ID?)? > > When the grant is issued you create and store a refresh token which = > is > effectively the identifier for that instance/grant combination. > > When it comes back on a request to the token endpoint you look up=20 > the > grants associated with it. You also hack that the client_id=20 > sent in > the request matches to detect errors mostly) > >> When=20 > the refresh token is generated, it can be stored in a table with >>=20 > the client_id and the information about the grant. You could also do = > >> it statelesly by creating a signed object as the refresh token. > >> Madjid>>agreed, but for the signed object to be self-sustained,=20 > again >> would I not need something beyond a = =E2=80=9Cpopulation=E2=80=9D client_ID?=20 > Are we >> prescriptive what =E2=80=9Cinformation about the = grant=E2=80=9D is? > > You would be creating a bearer token as long as the AS signs it you = > can > put whatever grant grant info you like in it, that is=20 > implementation > specific. It could be a list of the scopes granted = and the subject. > >> The spec is silent on the exact programming method that the >>=20 > Authorization server uses. > >> Madjid>>Are there any other specs in IETF or elsewhere (OASIS,=20 > etc?) >> that prescribe token calculation (e.g. hash function, = parameters, etc)? > > > > You can look at JOSE and JWT for a way to create tokens >=20 > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token > >> In 3.7 Deployment independent describes using the same client_id =20 > >> across multiple instances of a native client, or multiple instances = > of >> a Java Script client running in a browsers with the same = callback uri. > >> Since the publishing of this RFC we have also developed a spec for = =20 > >> dynamic client registration so it is possible to give every native = > >> client it's own client_id and secret making them confidential = clients. > >> Madjid>>I would need to look at those specs, however, I thought=20 > that >> the =E2=80=9Cconfidential client=E2=80=9D designation has to = do with the=20 > client >> ability to hold secrets and perform a-by-server-acceptable = > >> authentication. Does dynamic client registration affect = client=E2=80=99s =20 > >> ability in that aspect? > > > > Yes it doesn't require the secret to be in the downloaded instance=20 > of > the native app. It can be populated at first run, changing it=20 > from > public to confidential. > > Confidential is not just for web servers any more. > >> There is also a middle ground some people take by doing a proof of = =20 > >> possession for code in native applications to prevent the=20 > interception >> of responses to the client by malicious applications = on the device. > >> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ > >> John B. > >> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri=20 > >>=20 > >> = wrote: > >> > >> > >> Hi all, > >> I am new to OAUTH list and OAUTH, so apologies if this is very=20 > off-topic. > >> I am evaluating an OAUTH 2.0 implementation that is done based on=20 > bare >> bone base OAUTH2.0 RFC. From what I understand, many (or=20 > some) client >> implementations use a =E2=80=9Cglobal = ID/secret=E2=80=9D pair for all=20 > instances of the >> client. Looking at RFC 6819 and there seem to be = > a whole page on this >> topic, if I understand it correctly. So = questions: > >> 1)Section 3.7 talks about deployment-independent versus deployment = =20 > >> specific client IDs. I am guessing = =E2=80=9Cdeployment-independent=E2=80=9D refers=20 > to >> what I called =E2=80=9Cglobal=E2=80=9D, meaning if I have the = same client with=20 > the >> same client ID installed in many end devices, that is a=20 > deployment >> independent case, correct? > >> 2)Section 3.3 on refresh token mentions that the token is secret=20 > bound >> to the client ID and client instance. Could somebody please=20 > point me >> to where the token generation and binding is described?=20 > Also how is >> the client instance is identified? > >> Thanks a lot in advance, > >> Madjid Nakhjiri > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >>=20 > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > 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 From nobody Mon Jul 7 14:17:59 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0111B290F for ; Mon, 7 Jul 2014 14:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KD7TP6WDxyAY for ; Mon, 7 Jul 2014 14:17:45 -0700 (PDT) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C705B1B28B5 for ; Mon, 7 Jul 2014 14:17:44 -0700 (PDT) Received: from [98.139.215.140] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jul 2014 21:17:43 -0000 Received: from [98.139.212.210] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jul 2014 21:17:43 -0000 Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 07 Jul 2014 21:17:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 900957.3398.bm@omp1019.mail.bf1.yahoo.com Received: (qmail 70050 invoked by uid 60001); 7 Jul 2014 21:17:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1404767863; bh=I/FjZwVYvHMkofNpMpGENmpWEl2M0LqktMoizH7w9vQ=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Apr11hT69dpekyrZ8lDXqFaDpBxjoiJyBFHllDeKDSFw5LaFMFHuGIKmFZLekK3QZ1AOVwYRcyX4E/ap0aTOd+qD7gm17hU4aZoRaB7DS756NHa0lN9Ex07xq0rpgjP1rIYsd87EY6w0uO828BdFsKxyCVroDbYS/RKUWedwM9c= X-YMail-OSG: hclQb3EVM1l.E1JudDPANEO473CXTlRiDMK2_LHTqORk6Z_ VlL5g85pqQSA0obixpbb_W9iDEWmXYanaYPAIhDDwvcOG8HNlEbdt8rduouS fXMy6s6V2CH8Y2ZKZDtDmBl0J_sBMJ64waG9PhtMccdnjQqSQPikH7Vug2FW Z.UEwVF82wLMl0qgbZYTOR9rCpIWFeBNZaqI.OuqS.XPCe4peqkkDPfX7prh bN9_SNlK9V21lnWdG09Mmnat1RTO80v8QcSdsS4nDnuXaitatqk.Ji3yRE9N yzTbiQ_bxkRrP_j8caYD0WlmpHcEoBPXjDLmrgIB4Xv2cqxxbkZyHJ5J2vRv 3_ImnOMhDi.nx5X7WCFP7n27oVQy1aQteNFlbLw7mX._lI3D3tZQoUA5qbUd kAgkuxQLHmtt5kLwgwcxZmI3NSuEcQ7PjfQXJe.h4uSFEJeLFYfBPqFYMCag KVLyH00q0Y3wkQ_Dd0bzAc6Ey9h_rem.433IXtRfZKx9TS7jJoZOmRdn6JYO X5NRnjzgCyduluqc.N1wOjqX5Z2or5sap2P_scOSJyeEF4HCrXg-- Received: from [167.220.24.190] by web142806.mail.bf1.yahoo.com via HTTP; Mon, 07 Jul 2014 14:17:43 PDT X-Rocket-MIMEInfo: 002.001, SSB3b3VsZCBhcmd1ZSB0aGF0IGlmIHRoZSB1c2VyIGFwcHJvdmVkIGEgc3BlY2lmaWMgYWNjZXNzIHByb2ZpbGUgdGhhdCB0aGUgdG9rZW4gc2hvdWxkIGJlIGxpbWl0ZWQgdG8gdGhhdC4gwqBJZiBpdCB3YW50cyBtb3JlIHJpZ2h0cy9zY29wZSB0aGF0IHNob3VsZCB0cmlnZ2VyIGFuIGFwcHJvdmFsIGZyb20gdGhlIHVzZXIgYmFzZWQgb24gYSBmdWxsIGF1dGhlbnRpY2F0aW9uLiDCoEl0J3MgYWxsIGEgYml0IG11ZHkgdGhvdWdoIGJlY2F1c2UgeW91IGNvdWxkIGltYWdpbmUgaW1wbGVtZW50aW5nIGEgbW8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.191.1 References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> <53B53F7C.506@gmail.com> <1404402057.15252.YahooMailNeo@web142801.mail.bf1.yahoo.com> <53B584BA.6090901@gmail.com> <38EB3E9D-BA98-4A48-89A7-48C57F501238@ve7jtb.com> <53BB0A20.6020009@gmail.com> Message-ID: <1404767863.61837.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Mon, 7 Jul 2014 14:17:43 -0700 From: Bill Mills To: John Bradley , Sergey Beryozkin In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="515012262-783076836-1404767863=:61837" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3nZdJKt0me-nLJdtE03i5Q_4soo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] refresh tokens and client instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:17:54 -0000 --515012262-783076836-1404767863=:61837 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would argue that if the user approved a specific access profile that the = token should be limited to that. =C2=A0If it wants more rights/scope that s= hould trigger an approval from the user based on a full authentication. =C2= =A0It's all a bit mudy though because you could imagine implementing a more= limited scope the user would not have to approve.=0A=0A=0AOn Monday, July = 7, 2014 2:09 PM, John Bradley wrote:=0A =0A=0A=0AInline= =0AOn Jul 7, 2014, at 4:59 PM, Sergey Beryozkin wrot= e:=0A=0A> Hi John, All,=0A> On 03/07/14 23:02, John Bradley wrote:=0A>> Yes= ,=0A>> =0A>> The the undifferentiated is initially differentiated by the us= er during Authorization by having a code returned and then by exchanging th= e code for a refresh token.=0A>> It however returns to being undifferentiat= ed on subsequent authorization requests.=0A>> This makes having sticky gran= ts (only asking for permission for incremental scopes) a potential security= problem, as the AS has no way to know if the client is the one that the pe= rvious authorization was intended for.=0A>> =0A>> Some AS just assume that = you want the same permissions across all instances of a client,=C2=A0 howev= er if this is a public client then someone could impersonate the client app= and basically do privilege escalation.=0A>> =0A> Why would a public client= holding a refresh token securely entered into it by a user request a new a= uthorization without actually requesting the new scopes ? The client can ju= st get a new access/refresh token from now on ?=0A=0AA client holding a ref= resh token may want to add additional scopes, perhaps it only initially ask= ed for permission to get a email address and now it wants a phone number.= =0A=0AIf it is a public client the AS needs to ask for permission to grant = both scopes,=C2=A0 it can't treat the email permission as sticky.=0A> =0A>>= What dynamic client registration gives us for native apps is a way to iden= tify specific instances of clients at the authorization endpoint by having = different client_id and validating that with instance specific client crede= ntials.=C2=A0 This also prevents the use of code if it is intercepted in th= e reply from the authorization endpoint.=0A>> =0A> Would it be fair to say = that a dynamic client registration is a preferred method of registering *pu= blic* clients from now on, *unless*=0A> no sticky grants are used in which = case a typical/default registration mode is OK ?=0A=0AIt is up to the AS an= d how it wants to manage clients.=C2=A0 Some will not want to manage thousa= nds of client_id, others won't mind.=C2=A0 =0A=0AIf you don't have sticky g= rants and can mitigate code being intercepted in the response by using http= ://tools.ietf.org/html/draft-sakimura-oauth-tcse ,=0Athen having a public c= lient works.=0A=0A=0A> =0A> Thanks, Sergey=0A> =0A>> John B.=0A>> =0A>> On = Jul 3, 2014, at 12:28 PM, Sergey Beryozkin wrote:=0A= >> =0A>>> Hi=0A>>> On 03/07/14 16:40, Bill Mills wrote:=0A>>>> Implementati= ons may/SHOULD bind refresh tokens to specific client=0A>>>> instances.=C2= =A0 Yes, it's possible that the client ID with dynamic=0A>>>> registration = is unique to each client, but many of the token theft use=0A>>>> cases incl= ude the possibility of stealing the client ID too if you know=0A>>>> you ne= ed to.=0A>>>> =0A>>> What exactly is a 'client instance' when we talk about= having a single client id registration, with the id shared between multipl= e devices (which is what I believe this thread started from).=0A>>> =0A>>> = What I understood, as far as the authorization service is concerned, a 'cli= ent instance' for AS is a combination of a client id + code grant.=0A>>> = =0A>>> + (optional) refresh token (as was mentioned earlier). But it appear= s to me a client instance can be uniquely identified by two values only wit= hout a refresh token.=0A>>> =0A>>> When a user authorizes a given device an= d gets a grant code and enters it into the device securely we have a 'clien= t instance' ready to get the tokens, with that device (client instance) usi= ng a client id and the grant code to get an access token and a refresh toke= n.=0A>>> =0A>>> Lets say it sends a "client_id=3D1&code=3D2" sequence to ge= t the tokens.=0A>>> A client id + a code value constitutes a client instanc= e, because a code would be unique per every authorization, right ?=0A>>> = =0A>>> So the service will return an access token + refresh token to the de= vice. Refresh Token could've been associated with a record containing a cli= ent id + grant code info earlier or at the moment the code is exchanged for= an access token.=0A>>> =0A>>> During the subsequent refresh token grant re= quest we have "client id + refresh token" as a client instance.=0A>>> =0A>>= > I'm not sure what exactly I'd like to ask here :-), but I wonder if the a= bove sounds right, then I guess I'd like to conclude that when we talk abou= t the authorization code grant then a refresh token is not the only key tha= t uniquely identifies a client instance:=0A>>> =0A>>> Initially it is a cli= ent id + code grant, a refresh token does not offer an extra uniqueness at = the point of the client device requesting an access token with a code. Refr= esh token only starts acting as the key client instance identifier at a ref= resh token grant time.=0A>>> =0A>>> Sorry for a long email, I'm very likely= missing something, so any clarifications will be welcome=0A>>> =0A>>> Than= ks, Sergey=0A>>> =0A>>> =0A>>> =0A>>> =0A>>> =0A>>> =0A>>> =0A>>>> -bill=0A= >>>> =0A>>>> =0A>>>> On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin=0A= >>>> wrote:=0A>>>> =0A>>>> =0A>>>> Hi=0A>>>> =0A>>>>= I'm finding the answers from John interesting but I'm failing to=0A>>>> un= derstand why refresh tokens are mentioned in scope of identifying the=0A>>>= > specific client instances.=0A>>>> =0A>>>> AFAIK refresh tokens would only= go on the wire, assuming they are=0A>>>> supported, when a client exchange= s a grant for a new access token.=0A>>>> And when the client uses a refresh= token grant.=0A>>>> =0A>>>> Was it really about a refresh token grant wher= e the incoming client id=0A>>>> and refresh token pair can uniquely identif= y the actual client instance=0A>>>> ? That would make sense.=0A>>>> =0A>>>>= Something else I'd like to clarify.=0A>>>> John mentions a refresh token i= s created at the authorization grant=0A>>>> initialization time. Would it m= ake any difference, as far as the=0A>>>> security properties of a grant are= concerned, if refresh token was only=0A>>>> created at a grant to access t= oken exchange point of time ?=0A>>>> =0A>>>> Thanks, Sergey=0A>>>> =0A>>>> = On 27/06/14 19:21, John Bradley wrote:=0A>>>>> Inline=0A>>>>> =0A>>>>> On J= un 27, 2014, at 1:24 PM, Madjid Nakhjiri >>> =0A>>>>> >> wrote:=0A>>>>> =0A>>>>>> Hi John,=0A>>>>>> Thank= you for your reply. Would appreciate if you consider my inline=0A>>>>>> co= mments below and respond again!=0A>>>>>> R,=0A>>>>>> Madjid=0A>>>>>> *From:= *John Bradley [mailto:ve7jtb@ve7jtb.com=0A>>>> ]= =0A>>>>>> *Sent:*Wednesday, June 25, 2014 5:56 PM=0A>>>>>> *To:*Madjid Nakh= jiri=0A>>>>>> *Cc:*oauth@ietf.org >>> >=0A>>>>>> *Subject:*Re: [OAUTH-WG] ref= resh tokens and client instances=0A>>>>>> In 3.3 It is saying that the refr= esh token is a secret that the=0A>>>>>> Authorization server has bound to t= he client_id, that the=0A>>>>>> Authorization server effectively uses to di= fferentiate between=0A>>>>>> instances of that client_id.=0A>>>>>> Madjid>>= If I have 10,000s of devices, each with an instance of the=0A>>>>>> OAUTH c= lient, but they are all using the same client ID, how would the=0A>>>>>> se= rver know which token to use for what client? unless when I am=0A>>>>>> cre= ating a token, I also include something that uniquely identifies=0A>>>>>> e= ach instance? Don=E2=80=99t I have to use SOMETHING that is unique to that= =0A>>>>>> instance (user grant/ID?)?=0A>>>>> When the grant is issued you c= reate and store a refresh token which is=0A>>>>> effectively the identifier= for that instance/grant combination.=0A>>>>> When it comes back on a reque= st to the token endpoint you look up the=0A>>>>> grants associated with it.= =C2=A0 You also hack that the client_id sent in=0A>>>>> the request matches= to detect errors mostly)=0A>>>>> =0A>>>>>> When the refresh token is gener= ated, it can be stored in a table with=0A>>>>>> the client_id and the infor= mation about the grant.=C2=A0 You could also do=0A>>>>>> it statelesly by c= reating a signed object as the refresh token.=0A>>>>>> Madjid>>agreed, but = for the signed object to be self-sustained, again=0A>>>>>> would I not need= something beyond a =E2=80=9Cpopulation=E2=80=9D client_ID? Are we=0A>>>>>>= prescriptive what =E2=80=9Cinformation about the grant=E2=80=9D is?=0A>>>>= > You would be creating a bearer token as long as the AS signs it you can= =0A>>>>> put whatever grant grant info you like in it, that is implementati= on=0A>>>>> specific.=C2=A0 It=C2=A0 could be a list of the scopes granted a= nd the subject.=0A>>>>>> The spec is silent on the exact programming method= that the=0A>>>>>> Authorization server uses.=0A>>>>>> Madjid>>Are there an= y other specs in IETF or elsewhere (OASIS, etc?)=0A>>>>>> that prescribe to= ken calculation (e.g. hash function, parameters, etc)?=0A>>>>> =0A>>>>> You= can look at JOSE and JWT for a way to create tokens=0A>>>>> http://tools.i= etf.org/html/draft-ietf-oauth-json-web-token=0A>>>>>> In 3.7 Deployment ind= ependent describes using the same client_id=0A>>>>>> across multiple instan= ces of a native client, or multiple instances of=0A>>>>>> a Java Script cli= ent running in a browsers with the same callback uri.=0A>>>>>> Since the pu= blishing of this RFC we have also developed a spec for=0A>>>>>> dynamic cli= ent registration so it is possible to give every native=0A>>>>>> client it'= s own client_id and secret making them confidential clients.=0A>>>>>> Madji= d>>I would need to look at those specs, however, I thought that=0A>>>>>> th= e =E2=80=9Cconfidential client=E2=80=9D designation has to do with the clie= nt=0A>>>>>> ability to hold secrets and perform a-by-server-acceptable=0A>>= >>>> authentication. Does dynamic client registration affect client=E2=80= =99s=0A>>>>>> ability in that aspect?=0A>>>>> =0A>>>>> Yes it doesn't requi= re the secret to be in the downloaded instance of=0A>>>>> the native app.= =C2=A0 It can be populated at first run, changing it from=0A>>>>> public to= confidential.=0A>>>>> Confidential is not just for web servers any more.= =0A>>>>>> There is also a middle ground some people take by doing a proof o= f=0A>>>>>> possession for code in native applications to prevent the interc= eption=0A>>>>>> of responses to the client by malicious applications on the= device.=0A>>>>>> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcs= e/=0A>>>>>> John B.=0A>>>>>> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri <= m.nakhjiri@samsung.com=0A>>>> =0A>>>>>> >> wrote:=0A>>>>>= > =0A>>>>>> =0A>>>>>> Hi all,=0A>>>>>> I am new to OAUTH list and OAUTH, so= apologies if this is very=0A>>>> off-topic.=0A>>>>>> I am evaluating an OA= UTH 2.0 implementation that is done based on bare=0A>>>>>> bone base OAUTH2= .0 RFC. From what I understand, many (or some) client=0A>>>>>> implementati= ons use a =E2=80=9Cglobal ID/secret=E2=80=9D pair for all instances of the= =0A>>>>>> client.=C2=A0 Looking at RFC 6819 and there seem to be a whole pa= ge on this=0A>>>>>> topic, if I understand it correctly. So questions:=0A>>= >>>> 1)Section 3.7 talks about deployment-independent versus deployment=0A>= >>>>> specific client IDs. I am guessing =E2=80=9Cdeployment-independent=E2= =80=9D refers to=0A>>>>>> what I called =E2=80=9Cglobal=E2=80=9D, meaning i= f I have the same client with the=0A>>>>>> same client ID installed in many= end devices, that is a deployment=0A>>>>>> independent case, correct?=0A>>= >>>> 2)Section 3.3 on refresh token mentions that the token is secret bound= =0A>>>>>> to the client ID and client instance. Could somebody please point= me=0A>>>>>> to where the token generation and binding is described? Also h= ow is=0A>>>>>> the client instance is identified?=0A>>>>>> Thanks a lot in = advance,=0A>>>>>> Madjid Nakhjiri=0A>>>>>> ________________________________= _______________=0A>>>>>> OAuth mailing list=0A>>>>>> OAuth@ietf.org >>> >=0A>= >>>>> https://www.ietf.org/mailman/listinfo/oauth=0A>>>> =0A>>>>> =0A>>>>> = =0A>>>>> =0A>>>>> _______________________________________________=0A>>>>> O= Auth mailing list=0A>>>>> OAuth@ietf.org =0A>>>>> ht= tps://www.ietf.org/mailman/listinfo/oauth=0A>>>>> =0A>>>> =0A>>>> _________= ______________________________________=0A>>>> OAuth mailing list=0A>>>> OAu= th@ietf.org =0A>>>> https://www.ietf.org/mailman/lis= tinfo/oauth=0A>>>> =0A>>>> =0A>>> =0A>>> __________________________________= _____________=0A>>> OAuth mailing list=0A>>> OAuth@ietf.org=0A>>> https://w= ww.ietf.org/mailman/listinfo/oauth=0A>> =0A> --515012262-783076836-1404767863=:61837 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I would argue that if the user approved a specific= access profile that the token should be limited to that.  If it wants= more rights/scope that should trigger an approval from the user based on a= full authentication.  It's all a bit mudy though because you could im= agine implementing a more limited scope the user would not have to approve.=


On Monday, July 7, 2014 2:09 PM, Jo= hn Bradley <ve7jtb@ve7jtb.com> wrote:


Inline
On Jul 7, 2014, at 4:59 PM, S= ergey Beryozkin <sberyozkin@gmail.com> wrote:=

> Hi John, All,
= > On 03/07/14 23:02, John Bradley wrote:
>> Yes,=
>>
>> The the undifferent= iated is initially differentiated by the user during Authorization by havin= g a code returned and then by exchanging the code for a refresh token.
>> It however returns to being undifferentiated on subs= equent authorization requests.
>> This makes having= sticky grants (only asking for permission for incremental scopes) a potent= ial security problem, as the AS has no way to know if the client is the one= that the pervious authorization was intended for.
>>
>> Some AS just assume that you want the same permissions across = all instances of a client,  however if this is a public client then so= meone could impersonate the client app and basically do privilege escalatio= n.
>>
> Why would a public cl= ient holding a refresh token securely entered into it by a user request a n= ew authorization without actually requesting the new scopes ? The client ca= n just get a new access/refresh token from now on ?

A client holding a refresh token may want to add additional s= copes, perhaps it only initially asked for permission to get a email addres= s and now it wants a phone number.

If = it is a public client the AS needs to ask for permission to grant both scop= es,  it can't treat the email permission as sticky.
= >
>> What dynamic client registration gives us for nati= ve apps is a way to identify specific instances of clients at the authoriza= tion endpoint by having different client_id and validating that with instan= ce specific client credentials.  This also prevents the use of code if= it is intercepted in the reply from the authorization endpoint.
>>
> Would it be fair to say that a d= ynamic client registration is a preferred method of registering *public* cl= ients from now on, *unless*
> no sticky grants are use= d in which case a typical/default registration mode is OK ?

It is up to the AS and how it wants to manage clients= .  Some will not want to manage thousands of client_id, others won't m= ind. 

If you don't have sticky g= rants and can mitigate code being intercepted in the response by using http://tools.ietf.org/html/draft-sakimura-oauth-tcse ,
then having a public client works.


>
> Thanks, Sergey
>
>> J= ohn B.
>>
>> On Jul 3, 201= 4, at 12:28 PM, Sergey Beryozkin <sberyozkin@gmail.c= om> wrote:
>>
>>>= ; Hi
>>> On 03/07/14 16:40, Bill Mills wrote:>>>> Implementations may/SHOULD bind refresh to= kens to specific client
>>>> instances. = Yes, it's possible that the client ID with dynamic
>&= gt;>> registration is unique to each client, but many of the token theft use
>>>= ;> cases include the possibility of stealing the client ID too if you kn= ow
>>>> you need to.
>&g= t;>>
>>> What exactly is a 'client instan= ce' when we talk about having a single client id registration, with the id = shared between multiple devices (which is what I believe this thread starte= d from).
>>>
>>> Wha= t I understood, as far as the authorization service is concerned, a 'client= instance' for AS is a combination of a client id + code grant.
>>>
>>> + (optional) refresh to= ken (as was mentioned earlier). But it appears to me a client instance can = be uniquely identified by two values only without a refresh token.
>>>
>>> When a user authoriz= es a given device and gets a grant code and enters it into the device securely we hav= e a 'client instance' ready to get the tokens, with that device (client ins= tance) using a client id and the grant code to get an access token and a re= fresh token.
>>>
>>>= Lets say it sends a "client_id=3D1&code=3D2" sequence to get the token= s.
>>> A client id + a code value constitutes a = client instance, because a code would be unique per every authorization, ri= ght ?
>>>
>>> So the= service will return an access token + refresh token to the device. Refresh= Token could've been associated with a record containing a client id + gran= t code info earlier or at the moment the code is exchanged for an access to= ken.
>>>
>>> During = the subsequent refresh token grant request we have "client id + refresh tok= en" as a client instance.
>>>
>>= ;> I'm not sure what exactly I'd like to ask here :-), but I wonder if t= he above sounds right, then I guess I'd like to conclude that when we talk = about the authorization code grant then a refresh token is not the only key= that uniquely identifies a client instance:
>>>=
>>> Initially it is a client id + code grant, = a refresh token does not offer an extra uniqueness at the point of the clie= nt device requesting an access token with a code. Refresh token only starts= acting as the key client instance identifier at a refresh token grant time= .
>>>
>>> Sorry for = a long email, I'm very likely missing something, so any clarifications will= be welcome
>>>
>>> = Thanks, Sergey
>>>
>>&g= t;
>>>
>>>
>>>
>>>
>&g= t;>
>>>> -bill
>>= >>
>>>>
>>>= ;> On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin
>>>> <sberyozkin@gmail.com> wrot= e:
>>>>
>>>> <= br clear=3D"none">>>>> Hi
>>>> >>>> I'm finding the answers from John interes= ting but I'm failing to
>>>> understand why r= efresh tokens are mentioned in scope of identifying the
&= gt;>>> specific client instances.
>>>&g= t;
>>>> AFAIK refresh tokens would only go on the = wire, assuming they are
>>>> supported, when = a client exchanges a grant for a new access token.
>&g= t;>> And when the client uses a refresh token grant.
>>>>
>>>> Was it really about = a refresh token grant where the incoming client id
>&g= t;>> and refresh token pair can uniquely identify the actual client i= nstance
>>>> ? That would make sense.
>>>>
>>>> Something e= lse I'd like to clarify.
>>>> John mentions a= refresh token is created at the authorization grant
>= >>> initialization time. Would it make any difference, as far as t= he
>>>> security properties of a grant are co= ncerned, if refresh token was only
>>>> created at a gra= nt to access token exchange point of time ?
>>>&= gt;
>>>> Thanks, Sergey
&g= t;>>>
>>>> On 27/06/14 19:21, John = Bradley wrote:
>>>>> Inline
>>>>>
>>>>> On Jun 27,= 2014, at 1:24 PM, Madjid Nakhjiri <m.nakhjiri@s= amsung.com
>>>> <mailto:m.nakhjiri@samsung.com>
>>>>= > <mailto:m.nakhjiri@samsung.com <mail= to:m.nakhjiri@samsung.com>>> wrote:
>= >>>>
>>>>>> Hi John,
>>>>>> Thank you for your reply. Would appre= ciate if you consider my inline
>>>>>> = comments below and respond again!
>>>>>>= ; R,
>>>>>> Madjid
&g= t;>>>>> *From:*John Bradley [mailto:ve7jtb@ve7= jtb.com
>>>> <mailto:ve7= jtb@ve7jtb.com>]
>>>>>> *Sent:*W= ednesday, June 25, 2014 5:56 PM
>>>>>> = *To:*Madjid Nakhjiri
>>>>>> *Cc:*oauth@ietf.org &l= t;mailto:oauth@ietf.org> <mailto:oauth@ietf.org
>>>> <mailto:oauth@ietf.org>>
>>>>>> *Subject:*Re: [OAUTH-W= G] refresh tokens and client instances
>>>>&g= t;> In 3.3 It is saying that the refresh token is a secret that the
>>>>>> Authorization server has bound to th= e client_id, that the
>>>>>> Authorizat= ion server effectively uses to differentiate between
>= >>>>> instances of that client_id.
>>>>>> Madjid>&g= t;If I have 10,000s of devices, each with an instance of the
>>>>>> OAUTH client, but they are all using the same = client ID, how would the
>>>>>> server = know which token to use for what client? unless when I am
>>>>>> creating a token, I also include something that u= niquely identifies
>>>>>> each instance= ? Don=E2=80=99t I have to use SOMETHING that is unique to that
>>>>>> instance (user grant/ID?)?
>>>>> When the grant is issued you create and store a refre= sh token which is
>>>>> effectively the id= entifier for that instance/grant combination.
>>>= ;>> When it comes back on a request to the token endpoint you look up= the
>>>>> grants associated with it.  You a= lso hack that the client_id sent in
>>>>> = the request matches to detect errors mostly)
>>>= >>
>>>>>> When the refresh token= is generated, it can be stored in a table with
>>&= gt;>>> the client_id and the information about the grant.  Yo= u could also do
>>>>>> it statelesly by= creating a signed object as the refresh token.
>>&= gt;>>> Madjid>>agreed, but for the signed object to be self-= sustained, again
>>>>>> would I not nee= d something beyond a =E2=80=9Cpopulation=E2=80=9D client_ID? Are we
>>>>>> prescriptive what =E2=80=9Cinformation = about the grant=E2=80=9D is?
>>>>> You wou= ld be creating a bearer token as long as the AS signs it you can
>>>>> put what= ever grant grant info you like in it, that is implementation
>>>>> specific.  It  could be a list of the sc= opes granted and the subject.
>>>>>> Th= e spec is silent on the exact programming method that the
>>>>>> Authorization server uses.
>= >>>>> Madjid>>Are there any other specs in IETF or els= ewhere (OASIS, etc?)
>>>>>> that prescr= ibe token calculation (e.g. hash function, parameters, etc)?
>>>>>
>>>>> You can lo= ok at JOSE and JWT for a way to create tokens
>>>= ;>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-tok= en
>>>>>> In 3.7 Deployment indepen= dent describes using the same client_id
>>>>&= gt;> across multiple instances of a native client, or multiple instances= of
>>>>>> a Java Script client running= in a browsers with the same callback uri.
>>>&g= t;>> Since the publishing of this RFC we have also developed a spec f= or
>>>>>> dynamic client registration s= o it is possible to give every native
>>>>>= ;> client it's own client_id and secret making them confidential clients= .
>>>>>> Madjid>>I would need to = look at those specs, however, I thought that
>>>= >>> the =E2=80=9Cconfidential client=E2=80=9D designation has to d= o with the client
>>>>>> ability to hold secrets and perfor= m a-by-server-acceptable
>>>>>> authent= ication. Does dynamic client registration affect client=E2=80=99s
>>>>>> ability in that aspect?
>>>>>
>>>>> Yes it doesn= 't require the secret to be in the downloaded instance of
>>>>> the native app.  It can be populated at first ru= n, changing it from
>>>>> public to confid= ential.
>>>>> Confidential is not just for= web servers any more.
>>>>>> There is = also a middle ground some people take by doing a proof of
>>>>>> possession for code in native applications to pre= vent the interception
>>>>>> of respons= es to the client by malicious applications on the device.
>>>>&g= t;> https://datatracker.ietf.org/doc/draft= -sakimura-oauth-tcse/
>>>>>> John B= .
>>>>>> On Jun 25, 2014, at 8:06 PM, M= adjid Nakhjiri <m.nakhjiri@samsung.com
>>>> <mailto:m.nakhjiri= @samsung.com>
>>>>>> <mailto:= m.nakhjiri@samsung.com <mailto:m.nakhjiri@samsung.com>>&= gt; wrote:
>>>>>>
&g= t;>>>>>
>>>>>> Hi all,<= br clear=3D"none">>>>>>> I am new to OAUTH list and OAUTH= , so apologies if this is very
>>>> off-topic= .
>>>>>> I am evaluating an OAUTH 2.0 i= mplementation that is done based on bare
>>>>= >> bone base OAUTH2.0 RFC. From what I understand, many (or some) cli= ent
>>>>>> implementations use a =E2=80= =9Cglobal ID/secret=E2=80=9D pair for all instances of the
>>>>>> client.  Looking at RFC 6819 and there seem= to be a whole page on this
>>>>>> topi= c, if I understand it correctly. So questions:
>>&g= t;>>> 1)Section 3.7 talks about deployment-independent versus deployment
>= ;>>>>> specific client IDs. I am guessing =E2=80=9Cdeploymen= t-independent=E2=80=9D refers to
>>>>>>= what I called =E2=80=9Cglobal=E2=80=9D, meaning if I have the same client = with the
>>>>>> same client ID installe= d in many end devices, that is a deployment
>>>&= gt;>> independent case, correct?
>>>>&g= t;> 2)Section 3.3 on refresh token mentions that the token is secret bou= nd
>>>>>> to the client ID and client i= nstance. Could somebody please point me
>>>>&= gt;> to where the token generation and binding is described? Also how is=
>>>>>> the client instance is identifi= ed?
>>>>>> Thanks a lot in advance,
>>>>>> Madjid Nakhjiri
= >>>>>> _______________________________________________>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org <mailto:= OAuth@ietf.org> <mailto:OAuth@ietf.org
>>>> <mailto:OAuth@ietf.org>>
>>>>>> https://www.ietf.org/mailm= an/listinfo/oauth
>>>>
>>>>>
>>>>>
>>>>>= ;
>>>>> _________________________________= ______________
>>>>> OAuth mailing list>>>>> OAuth@ietf.org <mailto:= OAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
= >>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>= ;> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>&g= t; https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>
>>> _______________________= ________________________
>>> OAuth mailing list<= br clear=3D"none">>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>


--515012262-783076836-1404767863=:61837-- From nobody Mon Jul 7 14:28:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF181B2940 for ; Mon, 7 Jul 2014 14:28:25 -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 mNDCMf1v4eeb for ; Mon, 7 Jul 2014 14:28:21 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273191B293D for ; Mon, 7 Jul 2014 14:28:21 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so86663wib.4 for ; Mon, 07 Jul 2014 14:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=iQYwheloLz3jlcrk3m5FWfjP0PTlDuCBX2SavGejhdQ=; b=AfKq3DTBHqV8IZrjNGO0dh4h41JId0WPnUxdMy1fBunGkmqbKvaRIYxFig6A+sFViT VJwiWZqaZeaKhwg8Uq+ljgCm3XkL/jVMk1WrVgwdMMq+/G2Le6GPzQNO86aF6+Ldxatd Aayal2Uu/U9xAFjLXyEegWVjftTbV7EVQmS3V7h0xuRcLF9Jyn8WSvfJhnTcjACZLLy+ 1KMziTTIY/lbkdyRyF3xhSNVVKB+Iqw9g9Gn3/cBWnAc3oUr8JJdzUk1pro8Q4xIqoob 9HxWVdd9H3E3uCQogxaaT2wSi6qnAov/U2R7yMizKTbdFW3ILdxrShSmRgLZ4Ok3pLp3 8Emg== X-Received: by 10.194.222.230 with SMTP id qp6mr35269588wjc.23.1404768499731; Mon, 07 Jul 2014 14:28:19 -0700 (PDT) Received: from [192.168.2.7] ([109.255.82.12]) by mx.google.com with ESMTPSA id do5sm119395548wib.16.2014.07.07.14.28.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 14:28:19 -0700 (PDT) Message-ID: <53BB10F1.4020201@gmail.com> Date: Mon, 07 Jul 2014 22:28:17 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Bradley References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> <53B53F7C.506@gmail.com> <1404402057.15252.YahooMailNeo@web142801.mail.bf1.yahoo.com> <53B584BA.6090901@gmail.com> <38EB3E9D-BA98-4A48-89A7-48C57F501238@ve7jtb.com> <53BB0A20.6020009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/BunKLDxiB3MvHvb9_1Odpi6BOU4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] refresh tokens and client instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:28:25 -0000 Hi John Thanks, see inline On 07/07/14 22:09, John Bradley wrote: > Inline > On Jul 7, 2014, at 4:59 PM, Sergey Beryozkin wrote: > >> Hi John, All, >> On 03/07/14 23:02, John Bradley wrote: >>> Yes, >>> >>> The the undifferentiated is initially differentiated by the user during Authorization by having a code returned and then by exchanging the code for a refresh token. >>> It however returns to being undifferentiated on subsequent authorization requests. >>> This makes having sticky grants (only asking for permission for incremental scopes) a potential security problem, as the AS has no way to know if the client is the one that the pervious authorization was intended for. >>> >>> Some AS just assume that you want the same permissions across all instances of a client, however if this is a public client then someone could impersonate the client app and basically do privilege escalation. >>> >> Why would a public client holding a refresh token securely entered into it by a user request a new authorization without actually requesting the new scopes ? The client can just get a new access/refresh token from now on ? > > A client holding a refresh token may want to add additional scopes, perhaps it only initially asked for permission to get a email address and now it wants a phone number. > > If it is a public client the AS needs to ask for permission to grant both scopes, it can't treat the email permission as sticky. >> Sure I understand, I asked why would a client request the authorization without requesting new scopes. So basically, I'm trying to figure out where the value of the dynamic registration is - so it appears the 'stickier' the grant the more valuable the dynamic registration becomes. >>> What dynamic client registration gives us for native apps is a way to identify specific instances of clients at the authorization endpoint by having different client_id and validating that with instance specific client credentials. This also prevents the use of code if it is intercepted in the reply from the authorization endpoint. >>> >> Would it be fair to say that a dynamic client registration is a preferred method of registering *public* clients from now on, *unless* >> no sticky grants are used in which case a typical/default registration mode is OK ? > > It is up to the AS and how it wants to manage clients. Some will not want to manage thousands of client_id, others won't mind. > > If you don't have sticky grants and can mitigate code being intercepted in the response by using http://tools.ietf.org/html/draft-sakimura-oauth-tcse , > then having a public client works. OK. Thanks for the comments, Sergey > >> >> Thanks, Sergey >> >>> John B. >>> >>> On Jul 3, 2014, at 12:28 PM, Sergey Beryozkin wrote: >>> >>>> Hi >>>> On 03/07/14 16:40, Bill Mills wrote: >>>>> Implementations may/SHOULD bind refresh tokens to specific client >>>>> instances. Yes, it's possible that the client ID with dynamic >>>>> registration is unique to each client, but many of the token theft use >>>>> cases include the possibility of stealing the client ID too if you know >>>>> you need to. >>>>> >>>> What exactly is a 'client instance' when we talk about having a single client id registration, with the id shared between multiple devices (which is what I believe this thread started from). >>>> >>>> What I understood, as far as the authorization service is concerned, a 'client instance' for AS is a combination of a client id + code grant. >>>> >>>> + (optional) refresh token (as was mentioned earlier). But it appears to me a client instance can be uniquely identified by two values only without a refresh token. >>>> >>>> When a user authorizes a given device and gets a grant code and enters it into the device securely we have a 'client instance' ready to get the tokens, with that device (client instance) using a client id and the grant code to get an access token and a refresh token. >>>> >>>> Lets say it sends a "client_id=1&code=2" sequence to get the tokens. >>>> A client id + a code value constitutes a client instance, because a code would be unique per every authorization, right ? >>>> >>>> So the service will return an access token + refresh token to the device. Refresh Token could've been associated with a record containing a client id + grant code info earlier or at the moment the code is exchanged for an access token. >>>> >>>> During the subsequent refresh token grant request we have "client id + refresh token" as a client instance. >>>> >>>> I'm not sure what exactly I'd like to ask here :-), but I wonder if the above sounds right, then I guess I'd like to conclude that when we talk about the authorization code grant then a refresh token is not the only key that uniquely identifies a client instance: >>>> >>>> Initially it is a client id + code grant, a refresh token does not offer an extra uniqueness at the point of the client device requesting an access token with a code. Refresh token only starts acting as the key client instance identifier at a refresh token grant time. >>>> >>>> Sorry for a long email, I'm very likely missing something, so any clarifications will be welcome >>>> >>>> Thanks, Sergey >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -bill >>>>> >>>>> >>>>> On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin >>>>> wrote: >>>>> >>>>> >>>>> Hi >>>>> >>>>> I'm finding the answers from John interesting but I'm failing to >>>>> understand why refresh tokens are mentioned in scope of identifying the >>>>> specific client instances. >>>>> >>>>> AFAIK refresh tokens would only go on the wire, assuming they are >>>>> supported, when a client exchanges a grant for a new access token. >>>>> And when the client uses a refresh token grant. >>>>> >>>>> Was it really about a refresh token grant where the incoming client id >>>>> and refresh token pair can uniquely identify the actual client instance >>>>> ? That would make sense. >>>>> >>>>> Something else I'd like to clarify. >>>>> John mentions a refresh token is created at the authorization grant >>>>> initialization time. Would it make any difference, as far as the >>>>> security properties of a grant are concerned, if refresh token was only >>>>> created at a grant to access token exchange point of time ? >>>>> >>>>> Thanks, Sergey >>>>> >>>>> On 27/06/14 19:21, John Bradley wrote: >>>>>> Inline >>>>>> >>>>>> On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri >>>> >>>>>> >> wrote: >>>>>> >>>>>>> Hi John, >>>>>>> Thank you for your reply. Would appreciate if you consider my inline >>>>>>> comments below and respond again! >>>>>>> R, >>>>>>> Madjid >>>>>>> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com >>>>> ] >>>>>>> *Sent:*Wednesday, June 25, 2014 5:56 PM >>>>>>> *To:*Madjid Nakhjiri >>>>>>> *Cc:*oauth@ietf.org >>>> > >>>>>>> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances >>>>>>> In 3.3 It is saying that the refresh token is a secret that the >>>>>>> Authorization server has bound to the client_id, that the >>>>>>> Authorization server effectively uses to differentiate between >>>>>>> instances of that client_id. >>>>>>> Madjid>>If I have 10,000s of devices, each with an instance of the >>>>>>> OAUTH client, but they are all using the same client ID, how would the >>>>>>> server know which token to use for what client? unless when I am >>>>>>> creating a token, I also include something that uniquely identifies >>>>>>> each instance? Don’t I have to use SOMETHING that is unique to that >>>>>>> instance (user grant/ID?)? >>>>>> When the grant is issued you create and store a refresh token which is >>>>>> effectively the identifier for that instance/grant combination. >>>>>> When it comes back on a request to the token endpoint you look up the >>>>>> grants associated with it. You also hack that the client_id sent in >>>>>> the request matches to detect errors mostly) >>>>>> >>>>>>> When the refresh token is generated, it can be stored in a table with >>>>>>> the client_id and the information about the grant. You could also do >>>>>>> it statelesly by creating a signed object as the refresh token. >>>>>>> Madjid>>agreed, but for the signed object to be self-sustained, again >>>>>>> would I not need something beyond a “population” client_ID? Are we >>>>>>> prescriptive what “information about the grant” is? >>>>>> You would be creating a bearer token as long as the AS signs it you can >>>>>> put whatever grant grant info you like in it, that is implementation >>>>>> specific. It could be a list of the scopes granted and the subject. >>>>>>> The spec is silent on the exact programming method that the >>>>>>> Authorization server uses. >>>>>>> Madjid>>Are there any other specs in IETF or elsewhere (OASIS, etc?) >>>>>>> that prescribe token calculation (e.g. hash function, parameters, etc)? >>>>>> >>>>>> You can look at JOSE and JWT for a way to create tokens >>>>>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token >>>>>>> In 3.7 Deployment independent describes using the same client_id >>>>>>> across multiple instances of a native client, or multiple instances of >>>>>>> a Java Script client running in a browsers with the same callback uri. >>>>>>> Since the publishing of this RFC we have also developed a spec for >>>>>>> dynamic client registration so it is possible to give every native >>>>>>> client it's own client_id and secret making them confidential clients. >>>>>>> Madjid>>I would need to look at those specs, however, I thought that >>>>>>> the “confidential client” designation has to do with the client >>>>>>> ability to hold secrets and perform a-by-server-acceptable >>>>>>> authentication. Does dynamic client registration affect client’s >>>>>>> ability in that aspect? >>>>>> >>>>>> Yes it doesn't require the secret to be in the downloaded instance of >>>>>> the native app. It can be populated at first run, changing it from >>>>>> public to confidential. >>>>>> Confidential is not just for web servers any more. >>>>>>> There is also a middle ground some people take by doing a proof of >>>>>>> possession for code in native applications to prevent the interception >>>>>>> of responses to the client by malicious applications on the device. >>>>>>> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ >>>>>>> John B. >>>>>>> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri >>>> >>>>>>> >> wrote: >>>>>>> >>>>>>> >>>>>>> Hi all, >>>>>>> I am new to OAUTH list and OAUTH, so apologies if this is very >>>>> off-topic. >>>>>>> I am evaluating an OAUTH 2.0 implementation that is done based on bare >>>>>>> bone base OAUTH2.0 RFC. From what I understand, many (or some) client >>>>>>> implementations use a “global ID/secret” pair for all instances of the >>>>>>> client. Looking at RFC 6819 and there seem to be a whole page on this >>>>>>> topic, if I understand it correctly. So questions: >>>>>>> 1)Section 3.7 talks about deployment-independent versus deployment >>>>>>> specific client IDs. I am guessing “deployment-independent” refers to >>>>>>> what I called “global”, meaning if I have the same client with the >>>>>>> same client ID installed in many end devices, that is a deployment >>>>>>> independent case, correct? >>>>>>> 2)Section 3.3 on refresh token mentions that the token is secret bound >>>>>>> to the client ID and client instance. Could somebody please point me >>>>>>> to where the token generation and binding is described? Also how is >>>>>>> the client instance is identified? >>>>>>> Thanks a lot in advance, >>>>>>> Madjid Nakhjiri >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>> > >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > From nobody Mon Jul 7 14:37:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C53C1B292C for ; Mon, 7 Jul 2014 14:37:12 -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 cd7CBZN3dK_b for ; Mon, 7 Jul 2014 14:37:07 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B711D1B2942 for ; Mon, 7 Jul 2014 14:37:04 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j7so4128965qaq.10 for ; Mon, 07 Jul 2014 14:37:04 -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=vAu6YzekIDPIlIGr13zsObmgZksJ4w0r5KnoBb+ONK8=; b=lBdYT0QltVQSA/BA1g3J4EtmHvBYB9j9Ip/SF1JpD4lyZa+eRp8FSOz4VwsX3sz85Q /dkpeLVqXYpq0q87BbZoQByheyEnPEbZg+c+FcLItPFJW8IQGYAQ//EUbxDjMmYwqHOL PyT5nckB8ITEeAzStZse3nkEtJMGiGM3VlU8bF0wlGbICxdpzJptb5biQTY28ZJn1CBu PCEf4H0hBhqFAclVgftxemil60QgRmDjav+krR+BjgAQ1GlKjzFE3V/4XB2auwjEXMbU VporMfPa2TSMokkeWAd3vphk9HKcsROLiPZfCuSNCJR1yzkgoCWJZfiwOiTZ13v129fH nfOA== X-Gm-Message-State: ALoCoQnkC5ohVaS7ZID6n8rQxmbyzVUxI5RNDLhG/u77zB7FZun+OpDS4KH6V5A9T8E5pP0MWuzd X-Received: by 10.140.88.230 with SMTP id t93mr39595476qgd.47.1404769023873; Mon, 07 Jul 2014 14:37:03 -0700 (PDT) Received: from [192.168.0.200] ([201.188.84.221]) by mx.google.com with ESMTPSA id v11sm22807441qah.31.2014.07.07.14.37.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 14:37:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C4406CA8-F3D4-445A-ACEA-E0576DD8514B" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <1404767863.61837.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Mon, 7 Jul 2014 17:36:32 -0400 Message-Id: <8503D1C5-9C0C-48E9-982B-AC7CBDEECE93@ve7jtb.com> References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> <53B53F7C.506@gmail.com> <1404402057.15252.YahooMailNeo@web142801.mail.bf1.yahoo.com> <53B584BA.6090901@gmail.com> <38EB3E9D-BA98-4A48-89A7-48C57F501238@ve7jtb.com> <53BB0A20.6020009@gmail.com> <1404767863.61837.YahooMailNeo@web142806.mail.bf1.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/v-YJNCQkDvzUd0fXSVTJn0b7d80 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] refresh tokens and client instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:37:12 -0000 --Apple-Mail=_C4406CA8-F3D4-445A-ACEA-E0576DD8514B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I was assuming re-authenticating the user. The thing is that with a = public client you can't assume that it is the same instance of that = client that requested the first grant for email, so you really should = re-prompt for both scopes. I have seen instances (mostly OAuth 1) where a AS is sloppy and = remembers persistent grants( sometimes including default ones for the = venders own app). =20 An attacker gets the client_id and app_secret and impersonates the app. = If a user has pre-consented to scopes the attacker can by impersonating = the legitimate app get scopes that the user has not consented to. In OAuth 2 attack can take advantage of AS that don't require = registering redirect URI for the code flow, because they mistakenly = confuse code with confidential. In my opinion you should not use sticky grants with clients that are not = confidential, and dynamic registration lets you make a native app = confidential. (no you can't guarantee the app is legitimate without some sort of out = of band verification, but it is confidential) John B. On Jul 7, 2014, at 5:17 PM, Bill Mills wrote: > I would argue that if the user approved a specific access profile that = the token should be limited to that. If it wants more rights/scope that = should trigger an approval from the user based on a full authentication. = It's all a bit mudy though because you could imagine implementing a = more limited scope the user would not have to approve. >=20 >=20 > On Monday, July 7, 2014 2:09 PM, John Bradley = wrote: >=20 >=20 > Inline > On Jul 7, 2014, at 4:59 PM, Sergey Beryozkin = wrote: >=20 > > Hi John, All, > > On 03/07/14 23:02, John Bradley wrote: > >> Yes, > >>=20 > >> The the undifferentiated is initially differentiated by the user = during Authorization by having a code returned and then by exchanging = the code for a refresh token. > >> It however returns to being undifferentiated on subsequent = authorization requests. > >> This makes having sticky grants (only asking for permission for = incremental scopes) a potential security problem, as the AS has no way = to know if the client is the one that the pervious authorization was = intended for. > >>=20 > >> Some AS just assume that you want the same permissions across all = instances of a client, however if this is a public client then someone = could impersonate the client app and basically do privilege escalation. > >>=20 > > Why would a public client holding a refresh token securely entered = into it by a user request a new authorization without actually = requesting the new scopes ? The client can just get a new access/refresh = token from now on ? >=20 > A client holding a refresh token may want to add additional scopes, = perhaps it only initially asked for permission to get a email address = and now it wants a phone number. >=20 > If it is a public client the AS needs to ask for permission to grant = both scopes, it can't treat the email permission as sticky. > >=20 > >> What dynamic client registration gives us for native apps is a way = to identify specific instances of clients at the authorization endpoint = by having different client_id and validating that with instance specific = client credentials. This also prevents the use of code if it is = intercepted in the reply from the authorization endpoint. > >>=20 > > Would it be fair to say that a dynamic client registration is a = preferred method of registering *public* clients from now on, *unless* > > no sticky grants are used in which case a typical/default = registration mode is OK ? >=20 > It is up to the AS and how it wants to manage clients. Some will not = want to manage thousands of client_id, others won't mind. =20 >=20 > If you don't have sticky grants and can mitigate code being = intercepted in the response by using = http://tools.ietf.org/html/draft-sakimura-oauth-tcse , > then having a public client works. >=20 >=20 > >=20 > > Thanks, Sergey > >=20 > >> John B. > >>=20 > >> On Jul 3, 2014, at 12:28 PM, Sergey Beryozkin = wrote: > >>=20 > >>> Hi > >>> On 03/07/14 16:40, Bill Mills wrote: > >>>> Implementations may/SHOULD bind refresh tokens to specific client > >>>> instances. Yes, it's possible that the client ID with dynamic > >>>> registration is unique to each client, but many of the token = theft use > >>>> cases include the possibility of stealing the client ID too if = you know > >>>> you need to. > >>>>=20 > >>> What exactly is a 'client instance' when we talk about having a = single client id registration, with the id shared between multiple = devices (which is what I believe this thread started from). > >>>=20 > >>> What I understood, as far as the authorization service is = concerned, a 'client instance' for AS is a combination of a client id + = code grant. > >>>=20 > >>> + (optional) refresh token (as was mentioned earlier). But it = appears to me a client instance can be uniquely identified by two values = only without a refresh token. > >>>=20 > >>> When a user authorizes a given device and gets a grant code and = enters it into the device securely we have a 'client instance' ready to = get the tokens, with that device (client instance) using a client id and = the grant code to get an access token and a refresh token. > >>>=20 > >>> Lets say it sends a "client_id=3D1&code=3D2" sequence to get the = tokens. > >>> A client id + a code value constitutes a client instance, because = a code would be unique per every authorization, right ? > >>>=20 > >>> So the service will return an access token + refresh token to the = device. Refresh Token could've been associated with a record containing = a client id + grant code info earlier or at the moment the code is = exchanged for an access token. > >>>=20 > >>> During the subsequent refresh token grant request we have "client = id + refresh token" as a client instance. > >>>=20 > >>> I'm not sure what exactly I'd like to ask here :-), but I wonder = if the above sounds right, then I guess I'd like to conclude that when = we talk about the authorization code grant then a refresh token is not = the only key that uniquely identifies a client instance: > >>>=20 > >>> Initially it is a client id + code grant, a refresh token does not = offer an extra uniqueness at the point of the client device requesting = an access token with a code. Refresh token only starts acting as the key = client instance identifier at a refresh token grant time. > >>>=20 > >>> Sorry for a long email, I'm very likely missing something, so any = clarifications will be welcome > >>>=20 > >>> Thanks, Sergey > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>> -bill > >>>>=20 > >>>>=20 > >>>> On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin > >>>> wrote: > >>>>=20 > >>>>=20 > >>>> Hi > >>>>=20 > >>>> I'm finding the answers from John interesting but I'm failing to > >>>> understand why refresh tokens are mentioned in scope of = identifying the > >>>> specific client instances. > >>>>=20 > >>>> AFAIK refresh tokens would only go on the wire, assuming they are > >>>> supported, when a client exchanges a grant for a new access = token. > >>>> And when the client uses a refresh token grant. > >>>>=20 > >>>> Was it really about a refresh token grant where the incoming = client id > >>>> and refresh token pair can uniquely identify the actual client = instance > >>>> ? That would make sense. > >>>>=20 > >>>> Something else I'd like to clarify. > >>>> John mentions a refresh token is created at the authorization = grant > >>>> initialization time. Would it make any difference, as far as the > >>>> security properties of a grant are concerned, if refresh token = was only > >>>> created at a grant to access token exchange point of time ? > >>>>=20 > >>>> Thanks, Sergey > >>>>=20 > >>>> On 27/06/14 19:21, John Bradley wrote: > >>>>> Inline > >>>>>=20 > >>>>> On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri = >>>> > >>>>> >> = wrote: > >>>>>=20 > >>>>>> Hi John, > >>>>>> Thank you for your reply. Would appreciate if you consider my = inline > >>>>>> comments below and respond again! > >>>>>> R, > >>>>>> Madjid > >>>>>> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com > >>>> ] > >>>>>> *Sent:*Wednesday, June 25, 2014 5:56 PM > >>>>>> *To:*Madjid Nakhjiri > >>>>>> *Cc:*oauth@ietf.org = >>>> > > >>>>>> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances > >>>>>> In 3.3 It is saying that the refresh token is a secret that the > >>>>>> Authorization server has bound to the client_id, that the > >>>>>> Authorization server effectively uses to differentiate between > >>>>>> instances of that client_id. > >>>>>> Madjid>>If I have 10,000s of devices, each with an instance of = the > >>>>>> OAUTH client, but they are all using the same client ID, how = would the > >>>>>> server know which token to use for what client? unless when I = am > >>>>>> creating a token, I also include something that uniquely = identifies > >>>>>> each instance? Don=92t I have to use SOMETHING that is unique = to that > >>>>>> instance (user grant/ID?)? > >>>>> When the grant is issued you create and store a refresh token = which is > >>>>> effectively the identifier for that instance/grant combination. > >>>>> When it comes back on a request to the token endpoint you look = up the > >>>>> grants associated with it. You also hack that the client_id = sent in > >>>>> the request matches to detect errors mostly) > >>>>>=20 > >>>>>> When the refresh token is generated, it can be stored in a = table with > >>>>>> the client_id and the information about the grant. You could = also do > >>>>>> it statelesly by creating a signed object as the refresh token. > >>>>>> Madjid>>agreed, but for the signed object to be self-sustained, = again > >>>>>> would I not need something beyond a =93population=94 client_ID? = Are we > >>>>>> prescriptive what =93information about the grant=94 is? > >>>>> You would be creating a bearer token as long as the AS signs it = you can > >>>>> put whatever grant grant info you like in it, that is = implementation > >>>>> specific. It could be a list of the scopes granted and the = subject. > >>>>>> The spec is silent on the exact programming method that the > >>>>>> Authorization server uses. > >>>>>> Madjid>>Are there any other specs in IETF or elsewhere (OASIS, = etc?) > >>>>>> that prescribe token calculation (e.g. hash function, = parameters, etc)? > >>>>>=20 > >>>>> You can look at JOSE and JWT for a way to create tokens > >>>>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token > >>>>>> In 3.7 Deployment independent describes using the same = client_id > >>>>>> across multiple instances of a native client, or multiple = instances of > >>>>>> a Java Script client running in a browsers with the same = callback uri. > >>>>>> Since the publishing of this RFC we have also developed a spec = for > >>>>>> dynamic client registration so it is possible to give every = native > >>>>>> client it's own client_id and secret making them confidential = clients. > >>>>>> Madjid>>I would need to look at those specs, however, I thought = that > >>>>>> the =93confidential client=94 designation has to do with the = client > >>>>>> ability to hold secrets and perform a-by-server-acceptable > >>>>>> authentication. Does dynamic client registration affect = client=92s > >>>>>> ability in that aspect? > >>>>>=20 > >>>>> Yes it doesn't require the secret to be in the downloaded = instance of > >>>>> the native app. It can be populated at first run, changing it = from > >>>>> public to confidential. > >>>>> Confidential is not just for web servers any more. > >>>>>> There is also a middle ground some people take by doing a proof = of > >>>>>> possession for code in native applications to prevent the = interception > >>>>>> of responses to the client by malicious applications on the = device. > >>>>>> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ > >>>>>> John B. > >>>>>> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri = >>>> > >>>>>> >> wrote: > >>>>>>=20 > >>>>>>=20 > >>>>>> Hi all, > >>>>>> I am new to OAUTH list and OAUTH, so apologies if this is very > >>>> off-topic. > >>>>>> I am evaluating an OAUTH 2.0 implementation that is done based = on bare > >>>>>> bone base OAUTH2.0 RFC. =46rom what I understand, many (or = some) client > >>>>>> implementations use a =93global ID/secret=94 pair for all = instances of the > >>>>>> client. Looking at RFC 6819 and there seem to be a whole page = on this > >>>>>> topic, if I understand it correctly. So questions: > >>>>>> 1)Section 3.7 talks about deployment-independent versus = deployment > >>>>>> specific client IDs. I am guessing =93deployment-independent=94 = refers to > >>>>>> what I called =93global=94, meaning if I have the same client = with the > >>>>>> same client ID installed in many end devices, that is a = deployment > >>>>>> independent case, correct? > >>>>>> 2)Section 3.3 on refresh token mentions that the token is = secret bound > >>>>>> to the client ID and client instance. Could somebody please = point me > >>>>>> to where the token generation and binding is described? Also = how is > >>>>>> the client instance is identified? > >>>>>> Thanks a lot in advance, > >>>>>> Madjid Nakhjiri > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org >>>> > > >>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>=20 > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>=20 > >>>>=20 > >>>=20 > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>=20 > >=20 >=20 >=20 --Apple-Mail=_C4406CA8-F3D4-445A-ACEA-E0576DD8514B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I was = assuming re-authenticating the user.   The thing is that with a = public client you can't assume that it is the same instance of that = client that requested the first grant for email, so you really should = re-prompt for both scopes.

I have seen instances = (mostly OAuth 1) where a AS is sloppy and remembers persistent grants( = sometimes including default ones for the venders own app). =  
An attacker gets the client_id and app_secret and = impersonates the app.  If a user has pre-consented to scopes the = attacker can by impersonating the legitimate app get scopes that the = user has not consented to.

In OAuth 2 attack = can take advantage of AS that don't require registering redirect URI for = the code flow,  because they mistakenly confuse code with = confidential.

In my opinion you should not use = sticky grants with clients that are not confidential, and dynamic = registration lets you make a native app confidential.
(no you = can't guarantee the app is legitimate without some sort of out of band = verification, but it is confidential)

John = B.

On Jul 7, 2014, at 5:17 PM, Bill Mills <wmills_92105@yahoo.com> = wrote:

I would argue that if = the user approved a specific access profile that the token should be = limited to that.  If it wants more rights/scope that should trigger = an approval from the user based on a full authentication.  It's all = a bit mudy though because you could imagine implementing a more limited = scope the user would not have to approve.


=
On Monday, July 7, = 2014 2:09 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:


Inline
On Jul 7, 2014, at = 4:59 PM, Sergey Beryozkin <sberyozkin@gmail.com> = wrote:

> Hi John, All,
> On 03/07/14 23:02, John Bradley wrote:
>> Yes,
>>
>> The the undifferentiated is initially = differentiated by the user during Authorization by having a code = returned and then by exchanging the code for a refresh token.
>> It however returns to being undifferentiated on = subsequent authorization requests.
>> This makes = having sticky grants (only asking for permission for incremental scopes) = a potential security problem, as the AS has no way to know if the client = is the one that the pervious authorization was intended for.
>>
>> Some AS just assume that you want the same = permissions across all instances of a client,  however if this is a = public client then someone could impersonate the client app and = basically do privilege escalation.
>>
> Why would a public client holding a refresh token = securely entered into it by a user request a new authorization without = actually requesting the new scopes ? The client can just get a new = access/refresh token from now on ?

A = client holding a refresh token may want to add additional scopes, = perhaps it only initially asked for permission to get a email address = and now it wants a phone number.

If = it is a public client the AS needs to ask for permission to grant both = scopes,  it can't treat the email permission as sticky.
>
>> What dynamic client = registration gives us for native apps is a way to identify specific = instances of clients at the authorization endpoint by having different = client_id and validating that with instance specific client = credentials.  This also prevents the use of code if it is = intercepted in the reply from the authorization endpoint.
>>
> Would it be fair to say = that a dynamic client registration is a preferred method of registering = *public* clients from now on, *unless*
> no sticky = grants are used in which case a typical/default registration mode is OK = ?

It is up to the AS and how it = wants to manage clients.  Some will not want to manage thousands of = client_id, others won't mind. 

If you don't have sticky grants and can mitigate code = being intercepted in the response by using http://tools.ietf.org/html/draft-sakimura-oauth-tcse = ,
then having a public client works.


>
> Thanks, Sergey
>
>> John B.
>>
>> On Jul 3, 2014, at = 12:28 PM, Sergey Beryozkin <sberyozkin@gmail.com> = wrote:
>>
>>> Hi
>>> On 03/07/14 16:40, Bill Mills wrote:
>>>> Implementations may/SHOULD bind refresh = tokens to specific client
>>>> = instances.  Yes, it's possible that the client ID with dynamic
>>>> registration is unique to each client, but many of the token theft use
>>>> cases include the possibility of = stealing the client ID too if you know
>>>> = you need to.
>>>>
>>> What exactly is a 'client instance' when we = talk about having a single client id registration, with the id shared = between multiple devices (which is what I believe this thread started = from).
>>>
>>> = What I understood, as far as the authorization service is concerned, a = 'client instance' for AS is a combination of a client id + code = grant.
>>>
>>> + = (optional) refresh token (as was mentioned earlier). But it appears to = me a client instance can be uniquely identified by two values only = without a refresh token.
>>>
>>> When a user authorizes a given device and gets a grant code and enters it into the device securely we = have a 'client instance' ready to get the tokens, with that device = (client instance) using a client id and the grant code to get an access = token and a refresh token.
>>>
>>> Lets say it sends a "client_id=3D1&code=3D= 2" sequence to get the tokens.
>>> A client = id + a code value constitutes a client instance, because a code would be = unique per every authorization, right ?
>>> =
>>> So the service will return an access = token + refresh token to the device. Refresh Token could've been = associated with a record containing a client id + grant code info = earlier or at the moment the code is exchanged for an access token.
>>>
>>> During the = subsequent refresh token grant request we have "client id + refresh = token" as a client instance.
>>>
>>> I'm not sure what exactly I'd like to ask = here :-), but I wonder if the above sounds right, then I guess I'd like = to conclude that when we talk about the authorization code grant then a = refresh token is not the only key that uniquely identifies a client = instance:
>>>
>>> = Initially it is a client id + code grant, a refresh token does not offer = an extra uniqueness at the point of the client device requesting an = access token with a code. Refresh token only starts acting as the key = client instance identifier at a refresh token grant time.
>>>
>>> Sorry for a = long email, I'm very likely missing something, so any clarifications = will be welcome
>>>
>>> Thanks, Sergey
>>> =
>>>
>>>
>>>
>>>
>>>
>>>
>>>> -bill
>>>> =
>>>>
>>>> = On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin
>>>> <sberyozkin@gmail.com> = wrote:
>>>>
>>>>
>>>> = Hi
>>>>
>>>> = I'm finding the answers from John interesting but I'm failing to
>>>> understand why refresh tokens are = mentioned in scope of identifying the
>>>> = specific client instances.
>>>>
>>>> AFAIK refresh tokens would only go on = the wire, assuming they are
>>>> = supported, when a client exchanges a grant for a new access token.
>>>> And when the client uses a refresh token = grant.
>>>>
>>>> Was it really about a refresh token = grant where the incoming client id
>>>> = and refresh token pair can uniquely identify the actual client = instance
>>>> ? That would make sense.
>>>>
>>>> = Something else I'd like to clarify.
>>>> = John mentions a refresh token is created at the authorization grant
>>>> initialization time. Would it make any = difference, as far as the
>>>> security = properties of a grant are concerned, if refresh token was only
>>>> created at a = grant to access token exchange point of time ?
>>>>
>>>> = Thanks, Sergey
>>>>
>>>> On 27/06/14 19:21, John Bradley = wrote:
>>>>> Inline
>>>>>
>>>>> On Jun 27, 2014, at 1:24 PM, Madjid = Nakhjiri <m.nakhjiri@samsung.com
>>>> <mailto:m.nakhjiri@samsung.com>
>>>>> <mailto:m.nakhjiri@samsung.com = <mailto:m.nakhjiri@samsung.com>>&= gt; wrote:
>>>>>
>>>>>> Hi John,
>>>>>> Thank you for your reply. Would = appreciate if you consider my inline
>>>>>> comments below and respond = again!
>>>>>> R,
>>>>>> Madjid
>>>>>> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com
>>>> <mailto:ve7jtb@ve7jtb.com>]
>>>>>> *Sent:*Wednesday, June 25, 2014 = 5:56 PM
>>>>>> *To:*Madjid = Nakhjiri
>>>>>> *Cc:*oauth@ietf.org <mailto:oauth@ietf.org> <mailto:oauth@ietf.org
>>>> <mailto:oauth@ietf.org>>
>>>>>> *Subject:*Re: [OAUTH-WG] refresh = tokens and client instances
>>>>>> = In 3.3 It is saying that the refresh token is a secret that the
>>>>>> Authorization server has bound = to the client_id, that the
>>>>>> = Authorization server effectively uses to differentiate between
>>>>>> instances of that client_id.
>>>>>> = Madjid>>If I have 10,000s of devices, each with an instance of = the
>>>>>> OAUTH client, but they = are all using the same client ID, how would the
>>>>>> server know which token to use = for what client? unless when I am
>>>>>> creating a token, I also include = something that uniquely identifies
>>>>>> each instance? Don=92t I have to = use SOMETHING that is unique to that
>>>>>> instance (user grant/ID?)?
>>>>> When the grant is issued you create = and store a refresh token which is
>>>>> = effectively the identifier for that instance/grant combination.
>>>>> When it comes back on a request to = the token endpoint you look up the
>>>>> = grants associated with it.  You also hack that the client_id sent = in
>>>>> the request matches to detect = errors mostly)
>>>>>
>>>>>> When the refresh token is = generated, it can be stored in a table with
>>>>>> the client_id and the = information about the grant.  You could also do
>>>>>> it statelesly by creating a = signed object as the refresh token.
>>>>>> Madjid>>agreed, but for = the signed object to be self-sustained, again
>>>>>> would I not need something = beyond a =93population=94 client_ID? Are we
>>>>>> prescriptive what =93information = about the grant=94 is?
>>>>> You would = be creating a bearer token as long as the AS signs it you can
>>>>> put = whatever grant grant info you like in it, that is implementation
>>>>> specific.  It  could be a = list of the scopes granted and the subject.
>>>>>> The spec is silent on the exact = programming method that the
>>>>>> = Authorization server uses.
>>>>>> = Madjid>>Are there any other specs in IETF or elsewhere (OASIS, = etc?)
>>>>>> that prescribe token = calculation (e.g. hash function, parameters, etc)?
>>>>>
>>>>> You can look at JOSE and JWT for a = way to create tokens
>>>>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-tok= en
>>>>>> In 3.7 Deployment = independent describes using the same client_id
>>>>>> across multiple instances of a = native client, or multiple instances of
>>>>>> a Java Script client running in = a browsers with the same callback uri.
>>>>>> Since the publishing of this RFC = we have also developed a spec for
>>>>>> dynamic client registration so = it is possible to give every native
>>>>>> client it's own client_id and = secret making them confidential clients.
>>>>>> Madjid>>I would need to = look at those specs, however, I thought that
>>>>>> the =93confidential client=94 = designation has to do with the client
>>>>>> ability to hold secrets and = perform a-by-server-acceptable
>>>>>> = authentication. Does dynamic client registration affect client=92s
>>>>>> ability in that aspect?
>>>>>
>>>>> Yes it doesn't require the secret to = be in the downloaded instance of
>>>>> = the native app.  It can be populated at first run, changing it = from
>>>>> public to confidential.
>>>>> Confidential is not just for web = servers any more.
>>>>>> There is = also a middle ground some people take by doing a proof of
>>>>>> possession for code in native = applications to prevent the interception
>>>>>> of responses to the client by malicious applications on the device.
>>>>>> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tc= se/
>>>>>> John B.
>>>>>> On Jun 25, 2014, at 8:06 PM, = Madjid Nakhjiri <m.nakhjiri@samsung.com
>>>> <mailto:m.nakhjiri@samsung.com>
>>>>>> <mailto:m.nakhjiri@samsung.com = <mailto:m.nakhjiri@samsung.com>>&= gt; wrote:
>>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>> I am new to OAUTH list and = OAUTH, so apologies if this is very
>>>> = off-topic.
>>>>>> I am evaluating an = OAUTH 2.0 implementation that is done based on bare
>>>>>> bone base OAUTH2.0 RFC. =46rom = what I understand, many (or some) client
>>>>>> implementations use a =93global = ID/secret=94 pair for all instances of the
>>>>>> client.  Looking at RFC = 6819 and there seem to be a whole page on this
>>>>>> topic, if I understand it = correctly. So questions:
>>>>>> = 1)Section 3.7 talks about deployment-independent versus deployment
>>>>>> specific client IDs. I am = guessing =93deployment-independent=94 refers to
>>>>>> what I called =93global=94, = meaning if I have the same client with the
>>>>>> same client ID installed in many = end devices, that is a deployment
>>>>>> independent case, correct?
>>>>>> 2)Section 3.3 on refresh token = mentions that the token is secret bound
>>>>>> to the client ID and client = instance. Could somebody please point me
>>>>>> to where the token generation = and binding is described? Also how is
>>>>>> the client instance is = identified?
>>>>>> Thanks a lot in = advance,
>>>>>> Madjid Nakhjiri
>>>>>> = _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
>>>> <mailto:OAuth@ietf.org>>
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>> =
>>>>>
>>>>>
>>>>> = _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>> =
>>>> = _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org <mailto: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=_C4406CA8-F3D4-445A-ACEA-E0576DD8514B-- From nobody Mon Jul 7 14:46:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32EF1B2962 for ; Mon, 7 Jul 2014 14:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tak8u6p-GZmW for ; Mon, 7 Jul 2014 14:46:39 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198361B2955 for ; Mon, 7 Jul 2014 14:46:39 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id x13so4319853qcv.5 for ; Mon, 07 Jul 2014 14:46:38 -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=+XofD0VPWCvnDPaoaPtCnMlB9yCP/NovKElMaiYwQz4=; b=ZlJMqy9yl8nCNWUVbROIjR17iB36DdPTmmHwguQR73pXk/g3/v1s4FG7oJ6QlgHd7u vgEx4cInGw6WtKQRwC7JUXxLcAt8jP6SlfA9IACNhsW3NN57lEdNzzBs4bHsAFcxKbC3 b0vembbfvl9docAUdsNEIjvZe0zmvO0luaRobQYH0cxRLK1tWHRR7aKX+jnrDkK0O3zZ zUDlnLYtGQT8NJ9B3bB5lCvK9x3OlZ2rAiWLyCSIyhCSfQQjZAZ1Orzyc5GYw0q7v1bv OQIzcknvNCh7Ivj2JwmxVmdxgMcXNPj/i3F4Tr/aHnlNmgAVjNr0v+EVVI9gf51TpCv0 8pyw== X-Gm-Message-State: ALoCoQllyaNYSAQ4LNYaaggU6U5W6BJTzWkm+Np4EtN7G1io9GqLX2NbeXAh/2X0ld78fPdnYOnV X-Received: by 10.140.107.3 with SMTP id g3mr50309698qgf.100.1404769598286; Mon, 07 Jul 2014 14:46:38 -0700 (PDT) Received: from [192.168.0.200] ([201.188.84.221]) by mx.google.com with ESMTPSA id i10sm75759811qaq.22.2014.07.07.14.46.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 14:46:37 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <014901cf9a28$e232c0a0$a69841e0$%nakhjiri@samsung.com> Date: Mon, 7 Jul 2014 17:46:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <005C1FD3-2F7E-45C0-BD99-9CC439E81211@ve7jtb.com> References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> <53B53F7C.506@gmail.com> <1404402057.15252.YahooMailNeo@web142801.mail.bf1.yahoo.com> <53B584BA.6090901@gmail.com> <014901cf9a28$e232c0a0$a69841e0$%nakhjiri@samsung.com> To: Madjid Nakhjiri X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lW45apynuUrV_rEbVs0dtWbVlBo Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] refresh tokens and client instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:46:42 -0000 The client always needs a client_id. =20 After the user authorizes the client the AS creates a code (there are = lots of ways to do it, a database entry works for most people), and = returns it to the client. The client instance by possession of that code is differentiated from = other instances of that client in it's requests to the token endpoint by = having a unique code or refresh_token. That code and refresh token have grants associated with them for the = user. The user doesn't enter the code it is returned to the client in a query = parameter appended to the redirect_uri. The code is exchanged for a access token and optionally a refresh token, = after the access token expires the client can use the refresh token to = get another access token.=20 If the client doesn't have a refresh token it needs to go through = authorization again. John B. On Jul 7, 2014, at 5:17 PM, Madjid Nakhjiri = wrote: > Hi Sergey, >=20 > Thanks for capturing the question. Yes, the issue was how we = distinguish between different instances of client, all using the same = client ID. >=46rom answers I have gotten so far, it seems that the = uniqueness of the instance may be provided through the uniqueness of a = code grant. However, I have not figure out what the spec says on how to = create the grant and how the grant code is unique to authorization = server. If anybody could point me to that part of spec, I would = appreciate it (I did not find it).=20 >=20 > Your description of "a user authorizes a given device and gets a grant = code and enters it into device securely we have a client instance..." = would require a device identifier, otherwise how does the fact that the = client is on a different device identifies that instance as a unique = instance? >=20 > I need to look at the spec for refresh versus access tokens. Do you = need different grant code types for each type of token? >=20 > Thanks, > Madjid > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Sergey = Beryozkin > Sent: Thursday, July 03, 2014 9:29 AM > To: Bill Mills; oauth@ietf.org > Subject: Re: [OAUTH-WG] refresh tokens and client instances >=20 > Hi > On 03/07/14 16:40, Bill Mills wrote: >> Implementations may/SHOULD bind refresh tokens to specific client=20 >> instances. Yes, it's possible that the client ID with dynamic=20 >> registration is unique to each client, but many of the token theft = use=20 >> cases include the possibility of stealing the client ID too if you=20 >> know you need to. >>=20 > What exactly is a 'client instance' when we talk about having a single = client id registration, with the id shared between multiple devices = (which is what I believe this thread started from). >=20 > What I understood, as far as the authorization service is concerned, a = 'client instance' for AS is a combination of a client id + code grant. >=20 > + (optional) refresh token (as was mentioned earlier). But it appears = to > me a client instance can be uniquely identified by two values only = without a refresh token. >=20 > When a user authorizes a given device and gets a grant code and enters = it into the device securely we have a 'client instance' ready to get the = tokens, with that device (client instance) using a client id and the = grant code to get an access token and a refresh token. >=20 > Lets say it sends a "client_id=3D1&code=3D2" sequence to get the = tokens. > A client id + a code value constitutes a client instance, because a = code would be unique per every authorization, right ? >=20 > So the service will return an access token + refresh token to the = device. Refresh Token could've been associated with a record containing = a client id + grant code info earlier or at the moment the code is = exchanged for an access token. >=20 > During the subsequent refresh token grant request we have "client id + = refresh token" as a client instance. >=20 > I'm not sure what exactly I'd like to ask here :-), but I wonder if = the above sounds right, then I guess I'd like to conclude that when we = talk about the authorization code grant then a refresh token is not the = only key that uniquely identifies a client instance: >=20 > Initially it is a client id + code grant, a refresh token does not = offer an extra uniqueness at the point of the client device requesting = an access token with a code. Refresh token only starts acting as the key = client instance identifier at a refresh token grant time. >=20 > Sorry for a long email, I'm very likely missing something, so any = clarifications will be welcome >=20 > Thanks, Sergey >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> -bill >>=20 >>=20 >> On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin=20 >> wrote: >>=20 >>=20 >> Hi >>=20 >> I'm finding the answers from John interesting but I'm failing to=20 >> understand why refresh tokens are mentioned in scope of identifying=20= >> the specific client instances. >>=20 >> AFAIK refresh tokens would only go on the wire, assuming they are=20 >> supported, when a client exchanges a grant for a new access token. >> And when the client uses a refresh token grant. >>=20 >> Was it really about a refresh token grant where the incoming client = id=20 >> and refresh token pair can uniquely identify the actual client=20 >> instance ? That would make sense. >>=20 >> Something else I'd like to clarify. >> John mentions a refresh token is created at the authorization grant=20= >> initialization time. Would it make any difference, as far as the=20 >> security properties of a grant are concerned, if refresh token was=20 >> only created at a grant to access token exchange point of time ? >>=20 >> Thanks, Sergey >>=20 >> On 27/06/14 19:21, John Bradley wrote: >>> Inline >>>=20 >>> On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri=20 >> >=20 >> >> = wrote: >>>=20 >>>> Hi John, >>>> Thank you for your reply. Would appreciate if you consider my=20 >> inline >> comments below and respond again! >>>> R, >>>> Madjid >>>> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com=20 >> ] >> *Sent:*Wednesday, June 25, 2014 5:56=20= >> PM >> *To:*Madjid Nakhjiri >> *Cc:*oauth@ietf.org=20 >> > > >> *Subject:*Re: [OAUTH-WG] refresh tokens=20= >> and client instances >> In 3.3 It is saying that the refresh token = is=20 >> a secret that the >> Authorization server has bound to the = client_id,=20 >> that the >> Authorization server effectively uses to differentiate=20= >> between >> instances of that client_id. >>>> Madjid>>If I have 10,000s of devices, each with an instance of the =20= >>>> OAUTH client, but they are all using the same client ID, how would=20= >> the >> server know which token to use for what client? unless when I=20= >> am >> creating a token, I also include something that uniquely=20 >> identifies >> each instance? Don=92t I have to use SOMETHING that is=20= >> unique to that >> instance (user grant/ID?)? >>> When the grant is issued you create and store a refresh token which=20= >> is > effectively the identifier for that instance/grant combination. >>> When it comes back on a request to the token endpoint you look up=20 >> the > grants associated with it. You also hack that the client_id=20= >> sent in > the request matches to detect errors mostly) > >> When=20= >> the refresh token is generated, it can be stored in a table with >>=20= >> the client_id and the information about the grant. You could also do = =20 >>>> it statelesly by creating a signed object as the refresh token. >>>> Madjid>>agreed, but for the signed object to be self-sustained,=20 >> again >> would I not need something beyond a =93population=94 = client_ID?=20 >> Are we >> prescriptive what =93information about the grant=94 is? >>> You would be creating a bearer token as long as the AS signs it you=20= >> can > put whatever grant grant info you like in it, that is=20 >> implementation > specific. It could be a list of the scopes = granted and the subject. >>>> The spec is silent on the exact programming method that the >>=20 >> Authorization server uses. >>>> Madjid>>Are there any other specs in IETF or elsewhere (OASIS,=20 >> etc?) >> that prescribe token calculation (e.g. hash function, = parameters, etc)? >>>=20 >>> You can look at JOSE and JWT for a way to create tokens >=20 >> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token >>>> In 3.7 Deployment independent describes using the same client_id =20= >>>> across multiple instances of a native client, or multiple instances=20= >> of >> a Java Script client running in a browsers with the same = callback uri. >>>> Since the publishing of this RFC we have also developed a spec for =20= >>>> dynamic client registration so it is possible to give every native =20= >>>> client it's own client_id and secret making them confidential = clients. >>>> Madjid>>I would need to look at those specs, however, I thought=20 >> that >> the =93confidential client=94 designation has to do with the=20= >> client >> ability to hold secrets and perform a-by-server-acceptable = =20 >>>> authentication. Does dynamic client registration affect client=92s =20= >>>> ability in that aspect? >>>=20 >>> Yes it doesn't require the secret to be in the downloaded instance=20= >> of > the native app. It can be populated at first run, changing it=20= >> from > public to confidential. >>> Confidential is not just for web servers any more. >>>> There is also a middle ground some people take by doing a proof of =20= >>>> possession for code in native applications to prevent the=20 >> interception >> of responses to the client by malicious applications = on the device. >>>> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ >>>> John B. >>>> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri=20 >> >>=20 >> >> = wrote: >>>>=20 >>>>=20 >>>> Hi all, >>>> I am new to OAUTH list and OAUTH, so apologies if this is very=20 >> off-topic. >>>> I am evaluating an OAUTH 2.0 implementation that is done based on=20= >> bare >> bone base OAUTH2.0 RFC. =46rom what I understand, many (or=20= >> some) client >> implementations use a =93global ID/secret=94 pair = for all=20 >> instances of the >> client. Looking at RFC 6819 and there seem to = be=20 >> a whole page on this >> topic, if I understand it correctly. So = questions: >>>> 1)Section 3.7 talks about deployment-independent versus deployment =20= >>>> specific client IDs. I am guessing =93deployment-independent=94 = refers=20 >> to >> what I called =93global=94, meaning if I have the same client = with=20 >> the >> same client ID installed in many end devices, that is a=20 >> deployment >> independent case, correct? >>>> 2)Section 3.3 on refresh token mentions that the token is secret=20 >> bound >> to the client ID and client instance. Could somebody please=20= >> point me >> to where the token generation and binding is described?=20= >> Also how is >> the client instance is identified? >>>> Thanks a lot in advance, >>>> Madjid Nakhjiri >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org > > >>=20 >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >=20 >> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jul 7 15:20:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC6D1B2976 for ; Mon, 7 Jul 2014 15:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hHkIilIttm7 for ; Mon, 7 Jul 2014 15:20:00 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC7E1B281C for ; Mon, 7 Jul 2014 15:20:00 -0700 (PDT) X-AuditID: 12074425-f79766d000006da8-7a-53bb1d0f23f0 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 1F.1F.28072.F0D1BB35; Mon, 7 Jul 2014 18:19:59 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s67MJwQD009801 for ; Mon, 7 Jul 2014 18:19:59 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s67MJwSC006037 for ; Mon, 7 Jul 2014 18:19:58 -0400 From: Tom Yu To: References: <20140704223838.27871.23006.idtracker@ietfa.amsl.com> Date: Mon, 07 Jul 2014 18:19:57 -0400 In-Reply-To: <20140704223838.27871.23006.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Fri, 4 Jul 2014 15:38:38 -0700") Message-ID: Lines: 46 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixCmqrMsvuzvY4MUGRYuTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+mP10wF14QqNv7ZxN7A+IKvi5GDQ0LARGL7h/IuRk4gU0zi wr31bF2MXBxCArOZJI58PsAK4RxllNj7ZTULhNPAJLHt32UmkG42AWmJo4vLQLpFBEQkdi6Y zwJiCwskSiz4uo0RxBYScJQ4ePQNK4jNIqAq8eXOYrANnAL9jBInPyxhBknwCuhKPFj7kA3E 5hHglLjx/g0LRFxQ4uTMJ2A2s4CWxI1/L5kmMPLPQpKahSS1gJFpFaNsSm6Vbm5iZk5xarJu cXJiXl5qka6FXm5miV5qSukmRlCQsbuo7mCccEjpEKMAB6MSD++Kg7uChVgTy4orcw8xSnIw KYnyrpbaHSzEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhHfFcqBy3pTEyqrUonyYlDQHi5I471tr q2AhgfTEktTs1NSC1CKYrAwHh5IEr6UM0FDBotT01Iq0zJwShDQTByfIcB6g4eXSQDW8xQWJ ucWZ6RD5U4yKUuK8KiAJAZBERmkeXC8sCbxiFAd6RZiXG2QFDzCBwHW/AhrMBDT48/sdIINL EhFSUg2MHRMupcmn+avtKGRjtN0p5y+w10CSebtpe/JCldO9U5W5f9/rXv112qqIa9NOOPzK 66o3sfI5a3d4rdZ5ubj1cySuH37qFisoLrRn5lqJsNzFc60bNyxJrzTYu1B1DktvRenx8ELx Losl+QKNlwv25fSt+xN38MuEWV9X3kyqPn9Bre/e/jU+SizFGYmGWsxFxYkAk2UgF90CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/q3cIjOx2jLFxA3g93NpyHYAePH8 Subject: [OAUTH-WG] Leap second ambiguity in JWT-25 (Re: I-D Action: draft-ietf-oauth-json-web-token-25.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: Mon, 07 Jul 2014 22:20:04 -0000 Sorry for bringing this up so late in the process, but I recently had reasons to read the JWT draft and saw the following definition: IntDate A JSON numeric value representing the number of seconds from 1970- 01-01T0:0:0Z UTC until the specified UTC date/time. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular. This definition is ambiguous with respect to the treatment of leap seconds. It would probably be best to specify that this is a notional count of seconds from 1970-01-01T00:00:00Z, similar to the POSIX definition of "Seconds Since the Epoch", which assumes that every calendar day contains exactly 86400 seconds. I believe RFC 3339 gives no guidance in this area. It would also useful to specify whether it's expected to be an integer; I might guess yes, because the authors could intend "Int" to be an abbreviation for "Integer". I have seen evidence that some system administrators see operational problems with some protocols when they configure their systems to keep a non-conforming variant of POSIX time that includes leap seconds. (Interestingly enough, these involve a set of tzdata zone names that have a prefix of "right/".) If programs running on such systems transmit their non-conforming time_t values by encoding them directly in IntDate fields, recipients may see illusory time offsets representing the accumulated number of leap seconds (about 25 currently), even though the sending and receiving systems will likely agree on encoded RFC 3339 UTC time stamps except in the immediate vicinity of a leap second. It may seem like a small offset now, but I believe that it is expected to grow significantly larger in the future, unless leap seconds are abolished. Minor issue: the hour, minute, and second fields for the Epoch should be two digits in RFC 3339 format. Recommended new text: IntDate A JSON numeric value representing the notional number of integer seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. This is equivalent to the POSIX [POSIX ref here] definition of "Seconds Since the Epoch", where each calendar day contains exactly 86400 seconds. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular. From nobody Tue Jul 8 04:51:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9863F1B2A74 for ; Tue, 8 Jul 2014 04:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FILL_THIS_FORM=0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_FILL_THIS_FORM_LONG=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 VLcicWE0HDOS for ; Tue, 8 Jul 2014 04:51:11 -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 D62A91B2A58 for ; Tue, 8 Jul 2014 04:51:10 -0700 (PDT) Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MQ2Wx-1WzEje13nn-005GYo for ; Tue, 08 Jul 2014 13:51:09 +0200 Message-ID: <53BBDB2B.2050207@gmx.net> Date: Tue, 08 Jul 2014 13:51:07 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ugb551NbDksX8KunCKEJKSQ6aucnuJLar" X-Provags-ID: V03:K0:G6dqF6wz0lsn/X1yXsP6zFWMf9/h3Ofvu6WrXr65UePjFc4NvSe bq7G4zsn4fc1A4nrL+YaWpKInuWBkVPaHQXEK92QGVFzwlzdVkDrgg8pM38+IIQa58ND8Ii sPv3gJzptKvpCSzBONQOEiVCN+SxqZejarAm/cjyvM8RBVXHAAb6DwudXoIhPNcea1LkKEq aN4Ny8qlCE5MdqhGKWx0Q== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/rPrxNCeEe6-XL2xMfD3uYJB2Cn8 Subject: [OAUTH-WG] OAuth 2.0 Dynamic Registration: IANA Consideration Section 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, 08 Jul 2014 11:51:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ugb551NbDksX8KunCKEJKSQ6aucnuJLar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I just noticed a minor nit. The registration template for the meta-data attributes says: " Change controller: For Standards Track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. " In the actual registrations that are listed the term "IESG" is used rather than "IETF". Ciao Hannes --Ugb551NbDksX8KunCKEJKSQ6aucnuJLar Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTu9srAAoJEGhJURNOOiAtUH0H/2QbFI4ie+TbllpfcSXd+nCg H0VLtJxnZB1fd+uuuuenJOGSbfeC/zJAcagfiWO6fjLDlpwFugT52BdwKnpx5Na3 NKPC9HvZ2wQFj7hp24/9BWxlcWo1+O5s5UJOsZa9H6OfGD1ubcPEeDA8POYYLFDJ 7bz4vcGY9WIO6Az38jKYKS9+N9cu7w0zc/cThND8g+Zo3jUjbPWDel3f4UJQDuq/ hvoBzhMgHYJrMewJk7VS7+ns4dkQvr4fPXedFiC9AJpcUGEh7fl8BJcLo0zuRvoO pJmyglqzHDSbocQyM1sK831doLBsjGMe8FEpYJh4Ln0hV8oF+caE5gXfmlsbKD0= =Umtn -----END PGP SIGNATURE----- --Ugb551NbDksX8KunCKEJKSQ6aucnuJLar-- From nobody Tue Jul 8 04:54:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A851B280E for ; Tue, 8 Jul 2014 04:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9_jkGCDybFr for ; Tue, 8 Jul 2014 04:54:43 -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 2C0801B278B for ; Tue, 8 Jul 2014 04:54:43 -0700 (PDT) Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LsCdj-1WbylL48Sd-013z6C; Tue, 08 Jul 2014 13:54:25 +0200 Message-ID: <53BBDBEE.703@gmx.net> Date: Tue, 08 Jul 2014 13:54:22 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mike Jones , Phil Hunt , John Bradley , Justin Richer , Maciej Machulak X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wh4OlxuTvnrvXFBwo6IUGqAguA3BgU4ue" X-Provags-ID: V03:K0:rtjpEbZ4BopoQHarch9mmiJOhiIfiaWglHtxzcoY3NEN1pjXN7u C71x57x9TBOumFbRbC/aFGarQH5CShqxUNhenoVncf97WJ+Mkbw2PLJqD8kINRYTh+R6pHA S9DOBBj3kCQgglAUk1ne1XSlMhNMXk+HrmfjRs9+6bTxwZBwI8X/in8O8abNe1P+/RBIb1A O8aA9RAVT/SLq4///Bxrw== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/R2HsNyVMQ8_MlxTmXprpzezktmU Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Dynamic Client Registration: 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, 08 Jul 2014 11:54:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wh4OlxuTvnrvXFBwo6IUGqAguA3BgU4ue Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Phil, John, Maciej, Justin, Mike, I am working on the shepherd writeup for the dynamic client registration document and 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? Ciao Hannes --wh4OlxuTvnrvXFBwo6IUGqAguA3BgU4ue Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTu9vuAAoJEGhJURNOOiAtW9oH/2SV0tT+TuE7J8NU8mQqpKzx WjYClvY7em8BYCDDpyHWhUzM1k0PQGCm5tAbEc3SIHJDmFrDA/DdtvPNg3FuqMsY nprSYGZP8GPjeewMtqgW6bi1uyA6p2tG19yU2kdoa3BzOyqSCBx8CAhcdQT2PzbZ IjNgrrzTi7KarBnutCSUpbUQ7uJ7zZjL2AGqvDu8UJDk3a2zXyqOwtmyTCJYGK5G Xqrz2H5/GTCWSjnTgGcakOvfEfLGekwOws1yGyJwxAYsFY6a3+HHcrzXiCf+iAst Zea7WoreB23NFUZnMfp8mvkIzEA6VDqBDtiXtzcDxwmir849UjGaqmGyWidCFy8= =30qK -----END PGP SIGNATURE----- --wh4OlxuTvnrvXFBwo6IUGqAguA3BgU4ue-- From nobody Tue Jul 8 05:01:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541051B2A29 for ; Tue, 8 Jul 2014 05:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8VmPNE8eEws for ; Tue, 8 Jul 2014 05:01:37 -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 547091B2822 for ; Tue, 8 Jul 2014 05:01:37 -0700 (PDT) X-AuditID: 12074422-f79be6d000007518-7d-53bbdda0adce Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 8B.D4.29976.0ADDBB35; Tue, 8 Jul 2014 08:01:36 -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 s68C1ZM0012461; Tue, 8 Jul 2014 08:01:35 -0400 Received: from [33.142.78.45] ([172.56.22.28]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s68C1SuK014793 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Jul 2014 08:01:32 -0400 Message-Id: <201407081201.s68C1SuK014793@outgoing.mit.edu> Date: Tue, 08 Jul 2014 08:01:23 -0400 From: Justin Richer To: Hannes Tschofenig MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42IRYrdT0V1wd3ewwc8HZhZLd95jtdhw4wSr xbx759ks9k77xGJx8u0rNosF8xvZLVbf/cvmwO6xeNN+No8lS34yebTu+Mvu8bbhKrvHwuk7 WD0+Pr3F4nH79kaWAPYoLpuU1JzMstQifbsEroxrD6ayF0ziqLi86ANjA+MX9i5GTg4JAROJ 898b2SBsMYkL99aD2UICs5kkFs9X6GLkArI3MEo86e1mhXDmM0k8O/KRFaSKV8BK4viFjSwg NouAqsShx7PBpgoLuEr8nr4DbBIbUHz+yltMILaIgKHE9ZnTwQYxC7QySczvn8gOMUhQ4uTM J2CDmAXUJf7Mu8QMYStKTOl+yD6BkW8WkrJZSMpmISlbwMi8ilE2JbdKNzcxM6c4NVm3ODkx Ly+1SNdULzezRC81pXQTIzi8XZR2MP48qHSIUYCDUYmHd8XBXcFCrIllxZW5hxglOZiURHmP Ht8dLMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE98spoBxvSmJlVWpRPkxKmoNFSZz3rbVVsJBA emJJanZqakFqEUxWhoNDSYK39w5Qo2BRanpqRVpmTglCmomDE2Q4D9DwKSA1vMUFibnFmekQ +VOMilLivEtvAyUEQBIZpXlwvbD084pRHOgVYd75IO08wNQF1/0KaDAT0ODP73eADC5JREhJ NTCy1/7b33BZ5Z7ptLNv7h3mPOtVM+8Zx+qm36sW8LzYbDclsLhhxkNWsVZra7uLkWV/lt+t +7nR5MhuyblnjTMfdq5Ytmjnsr7QFC1P3nuy+kz5nf/NRZLiVc+4MJ1gnL9CZeXfc4Ypv7Rv WK9ueOcfO+9xx8OGZKXoOYKOi71czzh33dzB8VpbiaU4I9FQi7moOBEA3xid1BoDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9pxvx47_A_5oIyhLr87-0Q3QHcA Cc: Maciej Machulak , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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, 08 Jul 2014 12:01:42 -0000 SSBjYW4gY29uZmlybSB0aGF0IEkgaGF2ZSBubyBJUFIgZGlzY2xvc3VyZXMgdG8gbWFrZSByZWdh cmRpbmcgdGhlc2UgZG9jdW1lbnRzLgoKLS1KdXN0aW4KCi9zZW50IGZyb20gbXkgcGhvbmUvCgpP biBKdWwgOCwgMjAxNCA3OjU0IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVu aWdAZ214Lm5ldD4gd3JvdGU6Cj4KPiBIaSBQaGlsLCBKb2huLCBNYWNpZWosIEp1c3RpbiwgTWlr ZSwgCj4KPiBJIGFtIHdvcmtpbmcgb24gdGhlIHNoZXBoZXJkIHdyaXRldXAgZm9yIHRoZSBkeW5h bWljIGNsaWVudCByZWdpc3RyYXRpb24gCj4gZG9jdW1lbnQgYW5kIG9uZSBpdGVtIGluIHRoZSB0 ZW1wbGF0ZSByZXF1aXJlcyBtZSB0byBpbmRpY2F0ZSB3aGV0aGVyIAo+IGVhY2ggZG9jdW1lbnQg YXV0aG9yIGhhcyBjb25maXJtZWQgdGhhdCBhbnkgYW5kIGFsbCBhcHByb3ByaWF0ZSBJUFIgCj4g ZGlzY2xvc3VyZXMgcmVxdWlyZWQgZm9yIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUgcHJvdmlz aW9ucyBvZiBCQ1AgNzggCj4gYW5kIEJDUCA3OSBoYXZlIGFscmVhZHkgYmVlbiBmaWxlZC4gCj4K PiBDb3VsZCB5b3UgcGxlYXNlIGNvbmZpcm0/IAo+Cj4gQ2lhbyAKPiBIYW5uZXMgCj4KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyAKPiBPQXV0aCBtYWls aW5nIGxpc3QgCj4gT0F1dGhAaWV0Zi5vcmcgCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCAK From nobody Tue Jul 8 05:09:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B701A03AD for ; Tue, 8 Jul 2014 05:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9HQeNutkr5c for ; Tue, 8 Jul 2014 05:09:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC621B27FD for ; Tue, 8 Jul 2014 05:09:02 -0700 (PDT) Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LiTF6-1WU2SG11R6-00cjCb for ; Tue, 08 Jul 2014 14:09:00 +0200 Message-ID: <53BBDF5B.3020904@gmx.net> Date: Tue, 08 Jul 2014 14:08:59 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GOX2JPVWKJ6eCO2b1St6fPBk6GLrtBtuE" X-Provags-ID: V03:K0:XVKwghuBq8sV+pQhCJAOkKmGpWav8v3wgc43912ElBtsNcBh7GA iZ1Pl6MT+3uDIMdLgy4470IUFnpJM4JoCdUnHCRl0a0hXaMlqA6EAi5KsI1oMUJSG/JTbv4 k3LzyZi7tlDNpir4ZePyFkyIzZ6ne7hBghZsespOXU13PGgW2gxMVQbPMKlwyxQ/YXKfWHA 0PrIZeSoOyniypTebU4OQ== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/4eUdGTk3eqWMweVGrN_lhE-x88w Subject: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri 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, 08 Jul 2014 12:09:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GOX2JPVWKJ6eCO2b1St6fPBk6GLrtBtuE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, in my earlier review I had noted that the semantic of the fields is underspecified, i.e., it is not clear what these fields are used for. In private conversations I was told that an informal reference to a potential use case will be added. I don't see such reference with version -18. Ciao Hannes --GOX2JPVWKJ6eCO2b1St6fPBk6GLrtBtuE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTu99bAAoJEGhJURNOOiAt8NUIAJf8cjlNZU+mO+XqRmu1CfFA pZ7taJBuJ8wtww3W9+f9s7HtPjzRtQzQxwJHnMLnbscc3fg2BS64BGiBK3kFgVVf yf8huCa2QCs2hwu/mO6OyTtVzBjghLS9s+nU98v12KNdJBJN9FQuxzcXWc48lpOW 54lEaaoc4FWZj+OuRlGjR4PP9/XB/lH/Z3k4F3MfglkUxY8lEG5qBu/YdngEhQe2 tTNfPOqe+LG0RGf4VwNCMO4fniJT4HhWHAVOSu6wMIFkhncRg833adwph5r43/l1 Av+yH6npjMW7koKD3AKe38+2T5r2asV0ANo0/EKpchLUCcGayQ9XdTEjOkldyRY= =Rkz0 -----END PGP SIGNATURE----- --GOX2JPVWKJ6eCO2b1St6fPBk6GLrtBtuE-- From nobody Tue Jul 8 05:10:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD601B27FD for ; Tue, 8 Jul 2014 05:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DORg65Jt3lXb for ; Tue, 8 Jul 2014 05:10:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899C81A03B0 for ; Tue, 8 Jul 2014 05:10:12 -0700 (PDT) Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M3iU5-1WmPAp34S1-00rKZD for ; Tue, 08 Jul 2014 14:10:10 +0200 Message-ID: <53BBDFA0.8010306@gmx.net> Date: Tue, 08 Jul 2014 14:10:08 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lJEKq7KnACqet7b2plwhtUr55jdl8cUkg" X-Provags-ID: V03:K0:5W3vrqe872IxUKFgXk/Bnie7c55wInIQnXQ6UruihQvQsszVmxk Ey/E4EjC1uuWqjxIWbuW3PrQRNhVFgLBcbxxyjfgMIJ1khWyfyq6NjXrqx98aFod7tqwCB2 D4jGOqjI67IWhZwoKMvOHy4d1VSC6jgqR6uODOohl08T9jfAkSFQZkQg2v4RbyWvx+UsnPx RFjQ4BpfyALSzpFv7iG7Q== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lWy5jr0u4LEgwrruan5kGG2asNU Subject: [OAUTH-WG] Dynamic Client Registration: policy_uri 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, 08 Jul 2014 12:10:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lJEKq7KnACqet7b2plwhtUr55jdl8cUkg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, two earlier reviews I have noticed that the policy_uri meta-data attribute is not correctly specified. I offered a suggestion and in both cases my request was ignored. Maybe there is a reason to reject my request but I am uncertain about the relationship with another meta-data attribute, the terms-of-service attribute. Here is what I said in my last review: http://www.ietf.org/mail-archive/web/oauth/current/msg12879.html " policy_uri: In my previous review I argued that the right terminology here is privacy notice and you can even re-use the IAPP terminology. Unless the policy URI has nothing to do with privacy I would prefer this terminology change. If you disagree I would prefer to have a description about what policy means in this context. " Could you guys explain? Ciao Hannes --lJEKq7KnACqet7b2plwhtUr55jdl8cUkg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTu9+gAAoJEGhJURNOOiAtthoH/3Qbjhnn9PY4xbIpD/LGVXah HUQHBc8wyXRfkHrCOyg4BKkXXBmOfyIwDlunK0Bk97hhbrsHQLW99b6IaHGXDXme QCxP/qXwHTNZIRFkZxIq7ISsDoerEyNtUHY3c5oV1uhi8vJt+RV/l0cJTraI1o3p FxwqQDPGXpuupHX+WMHi5qocF107uPcYAGQxIvSRdoeiWGNAqdlqyt0MCYwzAkJW +Gei5wZ1zKWJSn9SUajGBMI2iKPDLLx1fFvBemEJVjayucICwGEeMHzJHPWb+x2A eD/Tv7UqBhDw21NhDf5ZBOB1yfkVmYsmTm8rgvxL0BVjG7cL9IefKwO8HBBHb1s= =HDFi -----END PGP SIGNATURE----- --lJEKq7KnACqet7b2plwhtUr55jdl8cUkg-- From nobody Tue Jul 8 05:17:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465A01B2828 for ; Tue, 8 Jul 2014 05:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uq0yqN25fnFu for ; Tue, 8 Jul 2014 05:17:12 -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 5222B1B280E for ; Tue, 8 Jul 2014 05:17:12 -0700 (PDT) Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M6ilI-1WjPBC2TA4-00wXKl for ; Tue, 08 Jul 2014 14:17:10 +0200 Message-ID: <53BBE144.90307@gmx.net> Date: Tue, 08 Jul 2014 14:17:08 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NBE12HcKloRWohwRH1aLPm6gcEN148OMT" X-Provags-ID: V03:K0:vtmcDVV82nOaX2NETF+hlJoCXPVY+w7GbC3HuN1Wy9Ia/Iag9Hd fAfMrYviYdsRw12oresIL3vDrA/hlWoTSbByKqHDTqoOxO7MeNCnoN1iTnBZR5R8BM0EV8T 3oPzIxDzfD7zvUTng16vur28SQ/k5OWxaRV7ujHlSWpwdRVgVqxrrnDhpyTAAb8edqccJAV zPPEfb+UFjj8wHKzL0QXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ubaTR-22PmMvXaO_cpvXpwtonIk Subject: [OAUTH-WG] Dynamic Client Registration: application_type 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, 08 Jul 2014 12:17:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NBE12HcKloRWohwRH1aLPm6gcEN148OMT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, with version -18 you guys have added a new meta-data attribute, namely application_type. First, this new attribute is not listed in the IANA consideration section= =2E Second, could you provide a bit of motivation why you need it? What would the authorization server do with that type of information? The description is rather short. IMHO there is also no clear boundary between a "native" and "web" app. Just think about smart phone apps that are developed using JavaScript. Would this be a web app or a native app? Here is the definition from the draft: application_type OPTIONAL. Kind of the application. The default, if omitted, is "web". The defined values are "native" or "web". Ciao Hannes --NBE12HcKloRWohwRH1aLPm6gcEN148OMT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTu+FEAAoJEGhJURNOOiAtpNAH/02foxZpcKrrYWR+VjRL5KQy s7xYkecVst+wP3UzBNC0w7e6Q/uehLN1dSqBgPuFBDVE7T4I0SKexawAHxH96HiQ p/LGNKEsNW9/+DM2ia+CoRTpwJ2EMABoTMThxOQgvcht3RxTAK0+3wXg2vw3BsBL 3gZ2pHVH+OUm/u2zpEDH23VJMckGS8wvV+JHCyUyw1JPZkFIhuMPak8/gYrC7Sla kKbEzgJls2vla1zkGGgU41s5r6y21cTEosHAJ4D/sAN/7+pqn8lGvZbHgVFn54Hj /hzYIRPx7mTOZJn6WTIQ+QTNDw3wmwxrCg2o9UOkOnwDy1cQyjOqUXOz7ZYiS/s= =hs2c -----END PGP SIGNATURE----- --NBE12HcKloRWohwRH1aLPm6gcEN148OMT-- From nobody Tue Jul 8 05:44:05 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AAD1B2827 for ; Tue, 8 Jul 2014 05:44:02 -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 wtOrcaOyxKE1 for ; Tue, 8 Jul 2014 05:44:00 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29031A03B8 for ; Tue, 8 Jul 2014 05:43:59 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id b8so3875809lan.40 for ; Tue, 08 Jul 2014 05:43:57 -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=H08RdraNfgkblB56qAru58xOe5/zn3Xgw3b9VZ8k7/E=; b=jKqiKZMuK/QsNzf0bvqnjfnpa8l3AAJ+AhzfVm21sph4TXj4ObybM5wHVOhVuKENDP om3pvWBjhRRdBtTpyWKHERhAJWaF9wL2xCmoBJGjyUIPQUknAbStRrkKUStLYgKxYJ1y rjKQkSQCnA0n8MyggDvLlQg5x9trWwMqlN7O6X8DXAQ3pDd1GuSBciOBrb0O7IkgeWPm 9KV6G4iPYHq0+mDW9inzs3eBSuAinZpukKMEFxwl6Z5AADaoJ+FcWYwDDbkJMlFlm3sQ sPhDVGyuX9wA9MsUwC4gDUzSjhGPbcw0dzS8D6WsCVIiGyQvgEEodoT6tdCM9g0LpXUc xTFQ== MIME-Version: 1.0 X-Received: by 10.152.5.105 with SMTP id r9mr27433232lar.37.1404823437730; Tue, 08 Jul 2014 05:43:57 -0700 (PDT) Received: by 10.112.23.33 with HTTP; Tue, 8 Jul 2014 05:43:57 -0700 (PDT) In-Reply-To: <53BBDFA0.8010306@gmx.net> References: <53BBDFA0.8010306@gmx.net> Date: Tue, 8 Jul 2014 21:43:57 +0900 Message-ID: From: Nat Sakimura To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e013d161efa6b4a04fdadf1b2 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TwHw1EaHLIc566ydYUpWa44u3oA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri 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, 08 Jul 2014 12:44:02 -0000 --089e013d161efa6b4a04fdadf1b2 Content-Type: text/plain; charset=UTF-8 policy_uri came down from OpenID Connect Dynamic Client Registraiton 1.0 [1]. It goes: policy_uriOPTIONAL. URL that the Relying Party Client provides to the End-User to read about the how the profile data will be used. The value of this field MUST point to a valid web page. The OpenID Provider SHOULD display this URL to the End-User if it is given. If desired, representation of this Claim in different languages and scripts is represented as described in Section 2.1 . It is clearly privacy related. In fact, it used to be a part of OpenID Connect Core in which the RP had to send it to obtain the permission. It is optional only because in certain enterprise type setting, it is unnecessary. In the consumer case, I regard it as essential. In any case, this is something a trust framework should set as its rule, and not the protocol itself. The draft -18 text goes: policy_uri URL that points to a human-readable Policy document for the client. The authorization server SHOULD display this URL to the end-user if it is given. The policy usually describes how an end- user's data will be used by the client. The value of this field MUST point to a valid web page. The value of this field MAY be internationalized, as described in Section 2.2 . It has been converted to be a bit vague. I would +1 to tighten it up. Note that there is tos_uri to describe the Terms of Service by the client and poicy_uri is not intended for this purpose but only for the service/client's privacy policy. BTW, I just found that a lot of text are more or less the duplicate or re-statement of [1]. IMHO, it should try to refer the original document where possible as it is a referable standard, and put [1] in the Reference section as well. Best, Nat [1] http://openid.net/specs/openid-connect-registration-1_0.html 2014-07-08 21:10 GMT+09:00 Hannes Tschofenig : > Hi all, > > two earlier reviews I have noticed that the policy_uri meta-data > attribute is not correctly specified. I offered a suggestion and in both > cases my request was ignored. > > Maybe there is a reason to reject my request but I am uncertain about > the relationship with another meta-data attribute, the terms-of-service > attribute. > > Here is what I said in my last review: > http://www.ietf.org/mail-archive/web/oauth/current/msg12879.html > > " > policy_uri: In my previous review I argued that the right terminology > here is privacy notice and you can even re-use the IAPP terminology. > Unless the policy URI has nothing to do with privacy I would prefer this > terminology change. If you disagree I would prefer to have a > description about what policy means in this context. > " > > Could you guys explain? > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e013d161efa6b4a04fdadf1b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
policy_uri came down from OpenID Connect Dynamic Client Re= gistraiton 1.0 [1].=C2=A0

It goes:=C2=A0

<= /div>
policy_uri
OPTIONAL. URL that the Relying Party Client prov= ides to the End-User to read about the how the profile data will be used. T= he value of this field MUST point to a valid web page. The OpenID Provider = SHOULD display this URL to the End-User if it is given. If desired, represe= ntation of this Claim in different languages and scripts is represented as = described in=C2=A0S= ection=C2=A02.1.

It is clearly privacy related. In fact, it used t= o be a part of OpenID Connect Core in which the RP had to send it to obtain= the permission. It is optional only because in certain enterprise type set= ting, it is unnecessary. In the consumer case, I regard it as essential. In= any case, this is something a trust framework should set as its rule, and = not the protocol itself.=C2=A0

The draft -18 text goes:=C2=A0

policy_uri
      URL that points to a human-readable Policy document for the
      client.  The authorization server SHOULD display this URL to the
      end-user if it is given.  The policy usually describes how an end-
      user's data will be used by the client.  The value of this field
      MUST point to a valid web page.  The value of this field MAY be
      internationalized, as described in Section 2.2.

It has been converted to be a bit vague. I would +1 to ti= ghten it up. Note that there is tos_uri to describe the Terms of Service by= the client and poicy_uri is not intended for this purpose but only for the= service/client's privacy policy.=C2=A0

BTW, I just found that a lot of text are more or less t= he duplicate or re-statement of [1]. IMHO, it should try to refer the origi= nal document where possible as it is a referable standard, and put [1] in t= he Reference section as well.=C2=A0

Best,=C2=A0

Nat

=


2014-07= -08 21:10 GMT+09:00 Hannes Tschofenig <hannes.tschofenig@gmx.net>:
Hi all,

two earlier reviews I have noticed that the policy_uri meta-data
attribute is not correctly specified. I offered a suggestion and in both cases my request was ignored.

Maybe there is a reason to reject my request but I am uncertain about
the relationship with another meta-data attribute, the terms-of-service
attribute.

Here is what I said in my last review:
http://www.ietf.org/mail-archive/web/oauth/current/msg1= 2879.html

"
policy_uri: In my previous review I argued that the right terminology
here is privacy notice and you can even re-use the IAPP terminology.
Unless the policy URI has nothing to do with privacy I would prefer this terminology change. If you disagree I would prefer to have a
description about what policy means in this context.
"

Could you guys explain?

Ciao
Hannes


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--089e013d161efa6b4a04fdadf1b2-- From nobody Tue Jul 8 05:46:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590521B27CE for ; Tue, 8 Jul 2014 05:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_zVECFAlm3i for ; Tue, 8 Jul 2014 05:46:16 -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 A3A071B2827 for ; Tue, 8 Jul 2014 05:46:15 -0700 (PDT) Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MVui8-1X6bL32Ofw-00X6VZ for ; Tue, 08 Jul 2014 14:46:13 +0200 Message-ID: <53BBE813.3000006@gmx.net> Date: Tue, 08 Jul 2014 14:46:11 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CibfbbqRNj3JPo8ppCGjxlAdLXMMElTpa" X-Provags-ID: V03:K0:Tc44uqk6ASQMB6grSX8biATCXRLwX8RujyyQvWKTGWV1YM4gU4J vU2knsPcY6EjwJtymSLupTqz/DHZtUANBcgivkCcETbScTiVzScuNqPU8nM56sNVO4tnBK0 FWKPqgie2dX0nQ7KVdRc0G9njUtLeZeueuQFisjXIoTrE5XNomoevCtHeu55r6403aupL2d xlSkpPEZNF8U1c/Fdr4hA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/PF7WsS-ROxj2BZTHzxxISFI3pTw Subject: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft 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, 08 Jul 2014 12:46:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CibfbbqRNj3JPo8ppCGjxlAdLXMMElTpa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I am working on the shepherd writeup for the dynamic client registration draft. You can find the latest draft here: https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-w= riteups/Writeup_OAuth_DynamicClientRegistration.txt As you can see it is still incomplete. I would need information about the implementation status. Ciao Hannes --CibfbbqRNj3JPo8ppCGjxlAdLXMMElTpa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEbBAEBCgAGBQJTu+gTAAoJEGhJURNOOiAtOMwH+Lr3jBpRA7/Xvnm/OXEF1fNs Tw6P2wZJZJM8Zc/3DpXWBkluV9jj01Suy2q8vZOp6R507jXL1Ri6pbr3BRL+jhKF /sEmbuKT/FfWcS8gxEtkFGVurnTTyx4y4PJ5xVx2z73oP8Qx6y4cCM4dMRBeRP7n LlB4NJcbRqkT2SIFzZHnNXUzhzVDGNnaX8yDNMoGH36fPVZPPiJHOgnCcViR/BBV 17gqAWtngFjBgBtz+c/k0l2XlMh4f1uPrRPPhKQW7zh3FuK8bznsGrkwDX7eWoEh p33QFE0y0Vl1VySpK91U5NYAtjLwwhIsnh+r2LQ29PWFVhgVRbe0/nrDM2N8Fw== =UrH3 -----END PGP SIGNATURE----- --CibfbbqRNj3JPo8ppCGjxlAdLXMMElTpa-- From nobody Tue Jul 8 05:49:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056FA1B2823 for ; Tue, 8 Jul 2014 05:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, 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 Hgw9I4ukdxxk for ; Tue, 8 Jul 2014 05:49:07 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CAC1B27CE for ; Tue, 8 Jul 2014 05:49:07 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id gf5so3837817lab.8 for ; Tue, 08 Jul 2014 05:49:05 -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=7V/VZKBFiyzfm5cXLZesL2kBmNqFDdSaw6EytT04f9g=; b=Oiq4n7j91pQONqvAkegIPbM/ZxS0I6O9EDfpI2utMQduAq/wSGaM4Kefm/c7V5n/zS 9Wbt+fCwalDQps/L1UxizBOWYwTW39cOn5hAGRMduQ362Emi0N0J3AGaJBryY7M5oaB4 InQZXkLJbhog86qTF+Kp8U9GSEioQor9ogXdHIElFnLlVjHlrdURSKQ3y+0uS3Wb33zB 0leHSwrEQUa9dGWtlW1/hUiyDP17s9L0xdvAWc2aa51PwSq0u1SB3WYCULMQxEp57Er6 YEoUFhkt9d2BiQOG52s8nRhmJbrKpNyjEkAF4Tct1Ftt/cSxrCQ7vWa6j7Qf5Dwep/jz yuvg== MIME-Version: 1.0 X-Received: by 10.112.172.199 with SMTP id be7mr1330656lbc.80.1404823745129; Tue, 08 Jul 2014 05:49:05 -0700 (PDT) Received: by 10.112.23.33 with HTTP; Tue, 8 Jul 2014 05:49:05 -0700 (PDT) In-Reply-To: <53BBE144.90307@gmx.net> References: <53BBE144.90307@gmx.net> Date: Tue, 8 Jul 2014 21:49:05 +0900 Message-ID: From: Nat Sakimura To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c3866c4cf64604fdae0458 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/WsYMvKDTKtkmVyR0L9r6cLPIekg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 08 Jul 2014 12:49:13 -0000 --001a11c3866c4cf64604fdae0458 Content-Type: text/plain; charset=UTF-8 I suppose authors has imported one of the security feature of OpenID Connect here as well. In the Dynamic Client Registration standard, which is a bit longer than IETF version. You can see the reason from it: application_typeOPTIONAL. Kind of the application. The default, if omitted, is web. The defined values are native or web. Web Clients using the OAuth Implicit Grant Type MUST only register URLs using the https scheme as redirect_uris; they MUST NOT use localhost as the hostname. Native Clients MUST only register redirect_uris using custom URI schemes or URLs using the http: scheme with localhost as the hostname. Authorization Servers MAY place additional constraints on Native Clients. Authorization Servers MAY reject Redirection URI values using the http scheme, other than the localhost case for Native Clients. The Authorization Server MUST verify that all the registered redirect_uris conform to these constraints. This prevents sharing a Client ID across different types of Clients. Regards, Nat 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig : > Hi all, > > with version -18 you guys have added a new meta-data attribute, namely > application_type. > > First, this new attribute is not listed in the IANA consideration section. > > Second, could you provide a bit of motivation why you need it? What > would the authorization server do with that type of information? The > description is rather short. > > IMHO there is also no clear boundary between a "native" and "web" app. > Just think about smart phone apps that are developed using JavaScript. > Would this be a web app or a native app? > > Here is the definition from the draft: > > application_type > OPTIONAL. Kind of the application. The default, if omitted, is > "web". The defined values are "native" or "web". > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c3866c4cf64604fdae0458 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I suppose authors has imported one of the security feature= of OpenID Connect here as well. In the Dynamic Client Registration standar= d, which is a bit longer than IETF version. You can see the reason from it:= =C2=A0

application_type
OPTIONAL. Kind = of the application. The default, if omitted, is=C2=A0web. T= he defined values are=C2=A0native=C2=A0or=C2=A0w= eb. Web Clients using the OAuth Implicit Grant Type MUST only register= URLs using the=C2=A0https=C2=A0scheme as=C2=A0r= edirect_uris; they MUST NOT use=C2=A0localhost=C2=A0as= the hostname. Native Clients MUST only register=C2=A0redirect_u= ris=C2=A0using custom URI schemes or URLs using the=C2=A0ht= tp:=C2=A0scheme with=C2=A0localhost=C2=A0as the hostna= me. Authorization Servers MAY place additional constraints on Native Client= s. Authorization Servers MAY reject Redirection URI values using the=C2=A0<= tt style=3D"color:rgb(0,51,102);font-family:'Courier New',Courier,m= onospace">http=C2=A0scheme, other than the=C2=A0localhost=C2=A0case for Native Clients. The Authorization Server MUST verify that= all the registered=C2=A0redirect_uris=C2=A0conform to thes= e constraints. This prevents sharing a Client ID across different types of = Clients.

Regards,=C2=A0

Nat
=


2014-07= -08 21:17 GMT+09:00 Hannes Tschofenig <hannes.tschofenig@gmx.net>:
Hi all,

with version -18 you guys have added a new meta-data attribute, namely
application_type.

First, this new attribute is not listed in the IANA consideration section.<= br>
Second, could you provide a bit of motivation why you need it? What
would the authorization server do with that type of information? The
description is rather short.

IMHO there is also no clear boundary between a "native" and "= ;web" app.
Just think about smart phone apps that are developed using JavaScript.
Would this be a web app or a native app?

Here is the definition from the draft:

application_type
=C2=A0 =C2=A0 =C2=A0 OPTIONAL. =C2=A0Kind of the application. =C2=A0The def= ault, if omitted, is
=C2=A0 =C2=A0 =C2=A0 "web". =C2=A0The defined values are "na= tive" or "web".

Ciao
Hannes


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c3866c4cf64604fdae0458-- From nobody Tue Jul 8 05:51:06 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD001B283B for ; Tue, 8 Jul 2014 05:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cv69opWTSy2T for ; Tue, 8 Jul 2014 05:51:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0B91B2837 for ; Tue, 8 Jul 2014 05:51:02 -0700 (PDT) Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LlDb4-1WViba1vVe-00b2bF; Tue, 08 Jul 2014 14:51:00 +0200 Message-ID: <53BBE932.6000808@gmx.net> Date: Tue, 08 Jul 2014 14:50:58 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nat Sakimura References: <53BBDFA0.8010306@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WS2tb9TbQoNaNRa6PEPI5GIBOEnl6RhFK" X-Provags-ID: V03:K0:s5Fw78q4HhgxXz2XFK2fVfpeOX3FKwox8OaphhPp1Y0m7OCDxBv s5E4QO7G+bbBfQzvKk954GR18r6GFQHf/5FzTd0Q2ooAANsXMIcuiNM2morY33cR5IMYXuy ousNH0df9yrNKNBD2CDTfivk/8iuKrpKzo5U2/4ABoJTUrTJYDebuWrdKnNevu/JosvRGmK b/shjGR13cHSJ/ApiArdA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DJuYzk7CEarD9e1vKxMs8mx4Vts Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri 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, 08 Jul 2014 12:51:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WS2tb9TbQoNaNRa6PEPI5GIBOEnl6RhFK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For example, even Facebook calls this stuff "Privacy Policy URL". On 07/08/2014 02:43 PM, Nat Sakimura wrote: > policy_uri came down from OpenID Connect Dynamic Client Registraiton 1.= 0 > [1].=20 >=20 > It goes:=20 >=20 > policy_uri > OPTIONAL. URL that the Relying Party Client provides to the End-Use= r > to read about the how the profile data will be used. The value of > this field MUST point to a valid web page. The OpenID Provider > SHOULD display this URL to the End-User if it is given. If desired,= > representation of this Claim in different languages and scripts is > represented as described in Section 2.1 > . >=20 > It is clearly privacy related. In fact, it used to be a part of OpenID > Connect Core in which the RP had to send it to obtain the permission. I= t > is optional only because in certain enterprise type setting, it is > unnecessary. In the consumer case, I regard it as essential. In any > case, this is something a trust framework should set as its rule, and > not the protocol itself.=20 >=20 > The draft -18 text goes:=20 >=20 > policy_uri > URL that points to a human-readable Policy document for the > client. The authorization server SHOULD display this URL to the > end-user if it is given. The policy usually describes how an end= - > user's data will be used by the client. The value of this field > MUST point to a valid web page. The value of this field MAY be > internationalized, as described in Section 2.2 . >=20 >=20 > It has been converted to be a bit vague. I would +1 to tighten it up. > Note that there is tos_uri to describe the Terms of Service by the > client and poicy_uri is not intended for this purpose but only for the > service/client's privacy policy.=20 >=20 > BTW, I just found that a lot of text are more or less the duplicate or > re-statement of [1]. IMHO, it should try to refer the original document= > where possible as it is a referable standard, and put [1] in the > Reference section as well.=20 >=20 > Best,=20 >=20 > Nat >=20 > [1] http://openid.net/specs/openid-connect-registration-1_0.html >=20 >=20 > 2014-07-08 21:10 GMT+09:00 Hannes Tschofenig >: >=20 > Hi all, >=20 > two earlier reviews I have noticed that the policy_uri meta-data > attribute is not correctly specified. I offered a suggestion and in= both > cases my request was ignored. >=20 > Maybe there is a reason to reject my request but I am uncertain abo= ut > the relationship with another meta-data attribute, the terms-of-ser= vice > attribute. >=20 > Here is what I said in my last review: > http://www.ietf.org/mail-archive/web/oauth/current/msg12879.html >=20 > " > policy_uri: In my previous review I argued that the right terminolo= gy > here is privacy notice and you can even re-use the IAPP terminology= =2E > Unless the policy URI has nothing to do with privacy I would prefer= this > terminology change. If you disagree I would prefer to have a > description about what policy means in this context. > " >=20 > Could you guys explain? >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --WS2tb9TbQoNaNRa6PEPI5GIBOEnl6RhFK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEbBAEBCgAGBQJTu+kyAAoJEGhJURNOOiAtaUMH9R8LySRJnfgWpXd3p3cJQIo5 H5b5glYXb16FsWpupJbu8T+/LUrzrLr9Z0iGkZmblKamrF2UTDP6R1LbbR1N5Taj lBZi4piKSslTIuZ2EVV+e4U7DF14QgSzhdIuwPD1sxndUHWZlbC8VRm6l0kVOMlW jHpwBC9knXR/x2NzAMVAsktwzRjFlbGcrpIl0YuvHB8KPcB3iEHudyUn1QiipMdN X1WNjBo10hCg5TT0KhztZc9+7Hmap1fWS04T34e6eaWY6boyp5RsQbcjH+KzDHzT UhHhfYgDQJfXh5ZzJesEKbwlKxEP0hKGs7hkbhY4ponmw/0/viQIP30xvZEy3A== =grPk -----END PGP SIGNATURE----- --WS2tb9TbQoNaNRa6PEPI5GIBOEnl6RhFK-- From nobody Tue Jul 8 06:22:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44CE1B2A7A for ; Tue, 8 Jul 2014 06:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKAFh1yQxZFp for ; Tue, 8 Jul 2014 06:22:50 -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 895751B283E for ; Tue, 8 Jul 2014 06:22:50 -0700 (PDT) Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Me86g-1XFz2E2PCY-00PqzV; Tue, 08 Jul 2014 15:22:48 +0200 Message-ID: <53BBF0A6.3000801@gmx.net> Date: Tue, 08 Jul 2014 15:22:46 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nat Sakimura References: <53BBE144.90307@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6rjGsQsGueKADAGuSrdL7tlD4CRNlLlfC" X-Provags-ID: V03:K0:QMGyvdW+U0Ql2YgT27DrdJgalLz1IVoi1GYLylJj+u3ZJL0+qz5 y1biN90FYjcXhrUcBXIuJen1sfqsjqBt2KohRLeO0C5nGpcRMqX4nJwtIfDydJwVhguN4VN Hetur6c4PPJLwD9axihkhDpA/dG5jmefmbwMQmvoTLm0//50NBdxF2SUFNMsUO87HCGloBs xNOG0bogZp2+1qDK0M9fg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CPiNJFzzS97S-ny6CwrmZkgXtlY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 08 Jul 2014 13:22:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6rjGsQsGueKADAGuSrdL7tlD4CRNlLlfC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This additional information makes a lot of sense. As you said in an earlier mail, the attempt to copy text from the OpenID Connect spec failed a bit... On 07/08/2014 02:49 PM, Nat Sakimura wrote: > I suppose authors has imported one of the security feature of OpenID > Connect here as well. In the Dynamic Client Registration standard, whic= h > is a bit longer than IETF version. You can see the reason from it:=20 >=20 > application_type > OPTIONAL. Kind of the application. The default, if omitted, is web.= > The defined values are native or web. Web Clients using the OAuth > Implicit Grant Type MUST only register URLs using the https scheme > as redirect_uris; they MUST NOT use localhost as the hostname. > Native Clients MUST only register redirect_uris using custom URI > schemes or URLs using the http: scheme with localhost as the > hostname. Authorization Servers MAY place additional constraints on= > Native Clients. Authorization Servers MAY reject Redirection URI > values using the http scheme, other than the localhost case for > Native Clients. The Authorization Server MUST verify that all the > registered redirect_uris conform to these constraints. This prevent= s > sharing a Client ID across different types of Clients. >=20 > Regards,=20 >=20 > Nat >=20 >=20 > 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig >: >=20 > Hi all, >=20 > with version -18 you guys have added a new meta-data attribute, nam= ely > application_type. >=20 > First, this new attribute is not listed in the IANA consideration > section. >=20 > Second, could you provide a bit of motivation why you need it? What= > would the authorization server do with that type of information? Th= e > description is rather short. >=20 > IMHO there is also no clear boundary between a "native" and "web" a= pp. > Just think about smart phone apps that are developed using JavaScri= pt. > Would this be a web app or a native app? >=20 > Here is the definition from the draft: >=20 > application_type > OPTIONAL. Kind of the application. The default, if omitted,= is > "web". The defined values are "native" or "web". >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --6rjGsQsGueKADAGuSrdL7tlD4CRNlLlfC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTu/CmAAoJEGhJURNOOiAt4TgIAKW6g6+QrV9S0Yfh5MPZLXCY WS72B/iYEpA72Uvff0x7p8fp08lxVlwZjc5zPyO4yR5svv5twoppUdysxnG1yWLM Kh1rHuv5LCmu/5/uBUJZ7rwS9qxuuNlqATVvk8j9EbWHuzarJp+2kdXom07CF/B/ 4tjF+xGZh782G05KgPl7eF84OVdd0ZZ1Gw8WaPbbe30/IBG8quJ5N7JmiTKrKon+ xvF1SwBWCRtL48sOTAubcwppMYIPhuWhN/T/E2WN5781ahtON5AQ7dfj00QvfldX w3QHzd7ryxxNQKBp812zesASpy9S3MCUCqM7Ckmkx/uHKHAw60UMSX3dUcjsU1A= =Rf0X -----END PGP SIGNATURE----- --6rjGsQsGueKADAGuSrdL7tlD4CRNlLlfC-- From nobody Tue Jul 8 06:25:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F352B1A0016 for ; Tue, 8 Jul 2014 06:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 2-kF7O6p18AI for ; Tue, 8 Jul 2014 06:25:37 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4EF1B283B for ; Tue, 8 Jul 2014 06:25:36 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id mc6so3993778lab.10 for ; Tue, 08 Jul 2014 06:25:35 -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=xHML0OQd2s0hOxotcYfneErWgVx6x+8AcOsn2QBSQsw=; b=UGRkgFppaNKKIw9kvIrEblf5mRwI5v8ALmB4vH5licRchdLdJV1no/DiN8dvmME0N2 F4r0eqin6dTKtV1Lip6mq9vpiv2oO/QNg7VmmhRSpS9B1s747t91cWw8afMsDkJi3ONu 3+aZIsp0N460MZGUQQFmpc4J3WIe9icvA64eZfb43ZriwMYdPY7S45LjgGW34N41KuIR wpdhIBSf0AWthnK0zsxFa+7Hg/JWhA5UZgDSys7odLjwhX1jTziqjc3229IAFO9V5RdP 9sMoIxtnU14aRkGyxHG/2iDixrVCk0iFcrM614UmFjIXt1UaWjEZrEkUDCvKpsASqZ0Z KBBQ== MIME-Version: 1.0 X-Received: by 10.152.8.104 with SMTP id q8mr27844111laa.13.1404825935212; Tue, 08 Jul 2014 06:25:35 -0700 (PDT) Received: by 10.112.23.33 with HTTP; Tue, 8 Jul 2014 06:25:35 -0700 (PDT) In-Reply-To: <53BBE932.6000808@gmx.net> References: <53BBDFA0.8010306@gmx.net> <53BBE932.6000808@gmx.net> Date: Tue, 8 Jul 2014 22:25:35 +0900 Message-ID: From: Nat Sakimura To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c31198d6f8e604fdae865d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ZzfbYQZe45RK9QnphZxlKAThf7A Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri 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, 08 Jul 2014 13:25:39 -0000 --001a11c31198d6f8e604fdae865d Content-Type: text/plain; charset=UTF-8 I am not against using the term "Privacy Policy" in the description. Depending on the jurisdiction and language, direct translation of such can be "Data Protection Policy", "Personal Data Protection Policy", etc., instead so just dodging it by avoiding the label would be more politically neutral, but it could be fine after all. I am not fine with changing the parameter name though. Slight variation in the parameter between the specs generally do not help the developers. Nat 2014-07-08 21:50 GMT+09:00 Hannes Tschofenig : > For example, even Facebook calls this stuff "Privacy Policy URL". > > On 07/08/2014 02:43 PM, Nat Sakimura wrote: > > policy_uri came down from OpenID Connect Dynamic Client Registraiton 1.0 > > [1]. > > > > It goes: > > > > policy_uri > > OPTIONAL. URL that the Relying Party Client provides to the End-User > > to read about the how the profile data will be used. The value of > > this field MUST point to a valid web page. The OpenID Provider > > SHOULD display this URL to the End-User if it is given. If desired, > > representation of this Claim in different languages and scripts is > > represented as described in Section 2.1 > > < > http://openid.bitbucket.org/openid-connect-registration-1_0.html#LanguagesAndScripts > >. > > > > It is clearly privacy related. In fact, it used to be a part of OpenID > > Connect Core in which the RP had to send it to obtain the permission. It > > is optional only because in certain enterprise type setting, it is > > unnecessary. In the consumer case, I regard it as essential. In any > > case, this is something a trust framework should set as its rule, and > > not the protocol itself. > > > > The draft -18 text goes: > > > > policy_uri > > URL that points to a human-readable Policy document for the > > client. The authorization server SHOULD display this URL to the > > end-user if it is given. The policy usually describes how an end- > > user's data will be used by the client. The value of this field > > MUST point to a valid web page. The value of this field MAY be > > internationalized, as described in Section 2.2 < > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18#section-2.2>. > > > > > > It has been converted to be a bit vague. I would +1 to tighten it up. > > Note that there is tos_uri to describe the Terms of Service by the > > client and poicy_uri is not intended for this purpose but only for the > > service/client's privacy policy. > > > > BTW, I just found that a lot of text are more or less the duplicate or > > re-statement of [1]. IMHO, it should try to refer the original document > > where possible as it is a referable standard, and put [1] in the > > Reference section as well. > > > > Best, > > > > Nat > > > > [1] http://openid.net/specs/openid-connect-registration-1_0.html > > > > > > 2014-07-08 21:10 GMT+09:00 Hannes Tschofenig > >: > > > > Hi all, > > > > two earlier reviews I have noticed that the policy_uri meta-data > > attribute is not correctly specified. I offered a suggestion and in > both > > cases my request was ignored. > > > > Maybe there is a reason to reject my request but I am uncertain about > > the relationship with another meta-data attribute, the > terms-of-service > > attribute. > > > > Here is what I said in my last review: > > http://www.ietf.org/mail-archive/web/oauth/current/msg12879.html > > > > " > > policy_uri: In my previous review I argued that the right terminology > > here is privacy notice and you can even re-use the IAPP terminology. > > Unless the policy URI has nothing to do with privacy I would prefer > this > > terminology change. If you disagree I would prefer to have a > > description about what policy means in this context. > > " > > > > Could you guys explain? > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c31198d6f8e604fdae865d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not against using the term "Privacy Policy"= in the description.=C2=A0
Depending on the jurisdiction and language, = direct translation of such=C2=A0
can be "Data Protection Pol= icy", "Personal Data Protection Policy", etc.,=C2=A0
instead so just dodging it by avoiding the label would be more politic= ally neutral,=C2=A0
but it could be fine after all. =C2=A0
<= div>
I am not fine with changing the parameter name though.= =C2=A0
Slight variation in the parameter between the specs generally do not help t= he developers.=C2=A0

Nat


2014-07-08 21:50 GMT+09:00 = Hannes Tschofenig <hannes.tschofenig@gmx.net>:
For example, even Facebook calls this stuff = "Privacy Policy URL".

On 07/08/2014 02:43 PM, Nat Sakimura wrote:
> policy_uri came down from OpenID Connect Dynamic Client Registraiton 1= .0
> [1].
>
> It goes:
>
> policy_uri
> =C2=A0 =C2=A0 OPTIONAL. URL that the Relying Party Client provides to = the End-User
> =C2=A0 =C2=A0 to read about the how the profile data will be used. The= value of
> =C2=A0 =C2=A0 this field MUST point to a valid web page. The OpenID Pr= ovider
> =C2=A0 =C2=A0 SHOULD display this URL to the End-User if it is given. = If desired,
> =C2=A0 =C2=A0 representation of this Claim in different languages and = scripts is
> =C2=A0 =C2=A0 represented as described in Section 2.1
> =C2=A0 =C2=A0 <http:/= /openid.bitbucket.org/openid-connect-registration-1_0.html#LanguagesAndScri= pts>.
>
> It is clearly privacy related. In fact, it used to be a part of OpenID=
> Connect Core in which the RP had to send it to obtain the permission. = It
> is optional only because in certain enterprise type setting, it is
> unnecessary. In the consumer case, I regard it as essential. In any > case, this is something a trust framework should set as its rule, and<= br> > not the protocol itself.
>
> The draft -18 text goes:
>
> policy_uri
> =C2=A0 =C2=A0 =C2=A0 URL that points to a human-readable Policy docume= nt for the
> =C2=A0 =C2=A0 =C2=A0 client. =C2=A0The authorization server SHOULD dis= play this URL to the
> =C2=A0 =C2=A0 =C2=A0 end-user if it is given. =C2=A0The policy usually= describes how an end-
> =C2=A0 =C2=A0 =C2=A0 user's data will be used by the client. =C2= =A0The value of this field
> =C2=A0 =C2=A0 =C2=A0 MUST point to a valid web page. =C2=A0The value o= f this field MAY be
> =C2=A0 =C2=A0 =C2=A0 internationalized, as described in Section = 2.2 <http://tools.ietf.org/html/draft-ietf-oauth-d= yn-reg-18#section-2.2>.
>
>
> It has been converted to be a bit vague. I would +1 to tighten it up.<= br> > Note that there is tos_uri to describe the Terms of Service by the
> client and poicy_uri is not intended for this purpose but only for the=
> service/client's privacy policy.
>
> BTW, I just found that a lot of text are more or less the duplicate or=
> re-statement of [1]. IMHO, it should try to refer the original documen= t
> where possible as it is a referable standard, and put [1] in the
> Reference section as well.
>
> Best,
>
> Nat
>
> [1] http://openid.net/specs/openid-connect-registratio= n-1_0.html
>
>
> 2014-07-08 21:10 GMT+09:00 Hannes Tschofenig <hannes.tschofenig@gmx.net
> <mailto:hannes.t= schofenig@gmx.net>>:
>
> =C2=A0 =C2=A0 Hi all,
>
> =C2=A0 =C2=A0 two earlier reviews I have noticed that the policy_uri m= eta-data
> =C2=A0 =C2=A0 attribute is not correctly specified. I offered a sugges= tion and in both
> =C2=A0 =C2=A0 cases my request was ignored.
>
> =C2=A0 =C2=A0 Maybe there is a reason to reject my request but I am un= certain about
> =C2=A0 =C2=A0 the relationship with another meta-data attribute, the t= erms-of-service
> =C2=A0 =C2=A0 attribute.
>
> =C2=A0 =C2=A0 Here is what I said in my last review:
> =C2=A0 =C2=A0 http://www.ietf.org/mail-archive/web= /oauth/current/msg12879.html
>
> =C2=A0 =C2=A0 "
> =C2=A0 =C2=A0 policy_uri: In my previous review I argued that the righ= t terminology
> =C2=A0 =C2=A0 here is privacy notice and you can even re-use the IAPP = terminology.
> =C2=A0 =C2=A0 Unless the policy URI has nothing to do with privacy I w= ould prefer this
> =C2=A0 =C2=A0 terminology change. If you disagree I would prefer to ha= ve a
> =C2=A0 =C2=A0 description about what policy means in this context.
> =C2=A0 =C2=A0 "
>
> =C2=A0 =C2=A0 Could you guys explain?
>
> =C2=A0 =C2=A0 Ciao
> =C2=A0 =C2=A0 Hannes
>
>
> =C2=A0 =C2=A0 _______________________________________________
> =C2=A0 =C2=A0 OAuth mailing list
> =C2=A0 =C2=A0 OAuth@ietf.org <mailto:OAuth@ietf.org>
> =C2=A0 =C2=A0 https://www.ietf.= org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en




--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en
--001a11c31198d6f8e604fdae865d-- From nobody Tue Jul 8 06:42:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88441B2AC7 for ; Tue, 8 Jul 2014 06:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL4Hva4KqHqf for ; Tue, 8 Jul 2014 06:42:34 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D9C1B2ACE for ; Tue, 8 Jul 2014 06:42:33 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so5246877qcw.17 for ; Tue, 08 Jul 2014 06:42:33 -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=JkPZYkz8TN9P/G3gJiT05Bm9vyiIFlSvOJh6LQhRVmY=; b=VFAoJxpO/hqNQViAJQTbTzkqB01l6KgXBzhKEUZv8hyBrPhtvC0X3eaKcU071k3tBq O5GTGuGgCM8VQXU9ePoCDX4DM9oEBNPG2A25+StmDfKNuGTKk9fbMDk3Tx8i0bpfcl+C ApBhkKNfozocaMoiv2Xhm165GkuzX90zTu4z8qPGBeoxOTvFsqg0MVhb9XG2m7ZDZtDJ lpF3TZ+of9Q5Utp8EOOc0iJlu0CSxx4ziCYSMrZvaMbes04odFQ2Rg6OTPJoeKPn1cG6 WX7FXbOxV5JlZ3kvpL/9o9HnoSH1wkdYb2DbJC8PxlfzA+E6Vavqa5PH5ST9CrA3b4io EzXQ== X-Gm-Message-State: ALoCoQkxbL66O51EoymK/DhuuiXWFhlpsnbS2Vrz0dUYVIgmhoT/5sB42QsLH8j+OUM8Nn0NUV6J X-Received: by 10.140.51.175 with SMTP id u44mr55595033qga.69.1404826953187; Tue, 08 Jul 2014 06:42:33 -0700 (PDT) Received: from [192.168.0.200] ([201.188.64.60]) by mx.google.com with ESMTPSA id u89sm18772351qge.47.2014.07.08.06.42.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 06:42:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <201407081201.s68C1SuK014793@outgoing.mit.edu> Date: Tue, 8 Jul 2014 09:42:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2786B1AB-C8FA-44C1-8774-87B2C57D0A84@ve7jtb.com> References: <201407081201.s68C1SuK014793@outgoing.mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DwUQDGpN0NcBF7ZiOp4E5rE7qdU Cc: Maciej Machulak , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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, 08 Jul 2014 13:42:36 -0000 I can confirm that I have no IPR disclosures to make on these documents. On Jul 8, 2014, at 8:01 AM, Justin Richer wrote: > I can confirm that I have no IPR disclosures to make regarding these = documents. >=20 > --Justin >=20 > /sent from my phone/ >=20 > On Jul 8, 2014 7:54 AM, Hannes Tschofenig = wrote: >>=20 >> Hi Phil, John, Maciej, Justin, Mike,=20 >>=20 >> I am working on the shepherd writeup for the dynamic client = registration=20 >> document and one item in the template requires me to indicate whether=20= >> each document author has confirmed that any and all appropriate IPR=20= >> disclosures required for full conformance with the provisions of BCP = 78=20 >> and BCP 79 have already been filed.=20 >>=20 >> Could you please confirm?=20 >>=20 >> Ciao=20 >> Hannes=20 >>=20 >> _______________________________________________=20 >> OAuth mailing list=20 >> OAuth@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/oauth=20 From nobody Tue Jul 8 08:33:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137F61B2B25 for ; Tue, 8 Jul 2014 08:33:14 -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 WEkAccXEpq4e for ; Tue, 8 Jul 2014 08:33:12 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883961B2B24 for ; Tue, 8 Jul 2014 08:33:11 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id p9so4023516lbv.26 for ; Tue, 08 Jul 2014 08:33:09 -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=CWsJn20G2GQSyNXR0Dj4AstM/3fzcRujyZ7t99z+H1k=; b=E0BVKmBgMZjkjsFw2ziBa7D5W5Zpo5JkLxOEtGeQReqqnVJE/viYcc8qqde6mMfrOl hW8lqS0xhof2XwnlAap80k/ZBSwUPnkeKH4YzrqbPfjryPXj8MBeUHs8d7+Lfeams3ar 2v3WRBONcc6P5zkHC+rB/94eva0lfmIetXCcmeCSmVdPL6yP5Qk3Y3mAB2U4Ju95tIsI 5Q4CYQ6Nwh63Q/QIacj0I0trIiI1p/ORvNUg6u9fdsBlBNouvkChXLJfwT8JbbLroOx8 07ZhENamPs3kEGoTekGNkFL4DMVJG95zPxGmIqQR+AV27Uo1YQH4jXzr+XkAdIiWo9QD PJ8Q== MIME-Version: 1.0 X-Received: by 10.112.181.74 with SMTP id du10mr27370684lbc.40.1404833589601; Tue, 08 Jul 2014 08:33:09 -0700 (PDT) Received: by 10.112.23.33 with HTTP; Tue, 8 Jul 2014 08:33:09 -0700 (PDT) In-Reply-To: <53B6951D.6090608@mit.edu> References: <53B694FA.6040407@mit.edu> <53B6951D.6090608@mit.edu> Date: Wed, 9 Jul 2014 00:33:09 +0900 Message-ID: From: Nat Sakimura To: Justin Richer Content-Type: multipart/alternative; boundary=001a11c36fe413ac0604fdb04f67 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/83CyW9w8RejfGHPty6uKXvKGlgI Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: Re: New Token Introspection Draft 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, 08 Jul 2014 15:33:14 -0000 --001a11c36fe413ac0604fdb04f67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry for a tardy reply. I was very much under the water till today. While your mental model works and is kind of stated in the introduction, it does not seem to be codified in the draft in a normative language. Perhaps doing so would be a good idea. Even if the introspection endpoint is to be strongly bound to the AS, I am not sure if that is sufficient to establish an one-to-one relationship between the Introspection EP and the AS. Stating it normatively might be needed after all. If it is not the case, and one-to-many is allowed, then we probably should think a bit about the consequence of token swap attack etc. In the one-to-many scenario, "iss" gets more important, as the unique user_id will become indeterminate. I was actually thinking of one-to-many model when I wrote the first email since I was thinking of the "generic token decryption" service etc. If this spec is just for one-to-one case, then another spec probably is needed to achieve such. However, IMHO, it would be easier just to add "iss" so that this draft becomes more generic. Nat 2014-07-04 20:50 GMT+09:00 Justin Richer : > And now with the list copied... > > > > -------- Original Message -------- Subject: Re: [OAUTH-WG] New Token > Introspection Draft Date: Fri, 04 Jul 2014 07:50:18 -0400 From: Justin > Richer To: Nat Sakimura > > > Interesting question. In my mental model of how this works, you're > asking the same AS that issued the token, so the "iss" is kindof a given > if the token is valid. Would there be a use for the server echoing that > back explicitly? Would people be using an introspection server that can > handle multiple issuers? I'm not against adding it, I simply didn't see > a use for it. > > Another data point: In our deployments of this, we're actually sending > out JWT formatted tokens that contain "iss" and a couple other fields. > The clients who care to do so check the "iss" field and the signature > themselves, but use introspection to find out which user this token was > issued to, what scopes it has, and all that detailed info. Some RS's > need it, some don't care. > > -- Justin > > On 7/4/2014 6:15 AM, Nat Sakimura wrote: > > Thanks Justin. > > > > Is there any reason that there is no iss claim returned? > > > > =3Dnat via iPhone > > > >> On Jul 4, 2014, at 9:10, Justin Richer wrote: > >> > >> I=E2=80=99ve updated the token introspection draft with the intention = that this document become input for a new working group item. > >> > >> http://tools.ietf.org/html/draft-richer-oauth-introspection-05 > >> > >> The changes are mostly minimal edits to the text and a few reference f= ixes. One bigger change is the addition of the =E2=80=9Cuser_id=E2=80=9D fi= eld in addition to the =E2=80=9Csub=E2=80=9D field, as I=E2=80=99ve been as= ked by some users to add that feature to our own implementation here. > >> > >> =E2=80=95 Justin > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c36fe413ac0604fdb04f67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for a tardy reply. I was very much under the water t= ill today.=C2=A0

While your mental model works and is ki= nd of stated in the introduction, it does not seem to be codified in the dr= aft in a normative language. Perhaps doing so would be a good idea.=C2=A0

Even if the introspection endpoint is to be strongly bo= und to the AS, I am not sure if that is sufficient to establish an one-to-o= ne relationship between the Introspection EP and the AS. Stating it normati= vely might be needed after all.=C2=A0

If it is not the case, and one-to-many is allowed, then= we probably should think a bit about the consequence of token swap attack = etc.=C2=A0

In the one-to-many scenario, "iss&= quot; gets more important, as the unique user_id will become indeterminate.= =C2=A0

I was actually thinking of one-to-many model when I wro= te the first email since I was thinking of the "generic token decrypti= on" service etc. If this spec is just for one-to-one case, then anothe= r spec probably is needed to achieve such. However, IMHO, it would be easie= r just to add "iss" so that this draft becomes more generic.=C2= =A0

Nat



<= div>




2014-07-04 20:50 GMT+09:00 Justin Rich= er <jricher@mit.edu>:
=20 =20 =20
And now with the list copied...



-------- Original Message --------
Subject: Re: [OAUTH-WG] New Token Introspection Draft
Date: Fri, 04 Jul 2014 07:50:18 -0400
From: Justin Richer <jricher@mit.edu>
To: Nat Sakimura <sakimura@gmail.com> 


Interesting question. In my mental model of how this works, you&=
#39;re
asking the same AS that issued the token, so the "iss" is kindof =
a given
if the token is valid. Would there be a use for the server echoing that
back explicitly? Would people be using an introspection server that can
handle multiple issuers? I'm not against adding it, I simply didn't=
 see
a use for it.

Another data point: In our deployments of this, we're actually sending
out JWT formatted tokens that contain "iss" and a couple other fi=
elds.
The clients who care to do so check the "iss" field and the signa=
ture
themselves, but use introspection to find out which user this token was
issued to, what scopes it has, and all that detailed info. Some RS's
need it, some don't care.

-- Justin

On 7/4/2014 6:15 AM, Nat Sakimura wrote:
> Thanks Justin.=20
>
> Is there any reason that there is no iss claim returned?=20
>
> =3Dnat via iPhone
>
>> On Jul 4, 2014, at 9:10, Justin Richer <jricher@MIT.EDU> wrote:
>>
>> I=E2=80=99ve updated the token introspection draft with the intent=
ion that this document become input for a new working group item.
>>
>> http://tools.ietf.org/html/draft-richer-oauth-in=
trospection-05
>>
>> The changes are mostly minimal edits to the text and a few referen=
ce fixes. One bigger change is the addition of the =E2=80=9Cuser_id=E2=80=
=9D field in addition to the =E2=80=9Csub=E2=80=9D field, as I=E2=80=99ve b=
een asked by some users to add that feature to our own implementation here.
>>
>> =E2=80=95 Justin
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=

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



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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c36fe413ac0604fdb04f67-- From nobody Tue Jul 8 09:11:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76D31B2B85 for ; Tue, 8 Jul 2014 09:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T024io_Coas0 for ; Tue, 8 Jul 2014 09:11:32 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489F11B2B62 for ; Tue, 8 Jul 2014 09:11:31 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s68GBQtO014172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jul 2014 16:11:27 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s68GBP6h023973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2014 16:11:26 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s68GBNis012410; Tue, 8 Jul 2014 16:11:24 GMT Received: from [10.98.24.77] (/24.244.23.132) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jul 2014 09:11:23 -0700 References: <53BBDBEE.703@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: <53BBDBEE.703@gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Tue, 8 Jul 2014 09:11:19 -0700 To: Hannes Tschofenig X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/IWVNnnr8K6Y1OZnhiyXXqzeyFw8 Cc: Maciej Machulak , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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, 08 Jul 2014 16:11:40 -0000 I confirm I have no IPR disclosures on this document.=20 Phil > On Jul 8, 2014, at 4:54, Hannes Tschofenig wro= te: >=20 > Hi Phil, John, Maciej, Justin, Mike, >=20 > I am working on the shepherd writeup for the dynamic client registration > document and 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. >=20 > Could you please confirm? >=20 > Ciao > Hannes >=20 >=20 From nobody Tue Jul 8 10:01:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528FE1B2B94 for ; Tue, 8 Jul 2014 10:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYbj31aaZK9i for ; Tue, 8 Jul 2014 10:01:04 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB941A0343 for ; Tue, 8 Jul 2014 10:00:58 -0700 (PDT) Received: from mail-ig0-f178.google.com ([209.85.213.178]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKU7wjyej5KDTbcxpkVLDOrkpE2tAupft/@postini.com; Tue, 08 Jul 2014 10:00:58 PDT Received: by mail-ig0-f178.google.com with SMTP id hn18so904241igb.5 for ; Tue, 08 Jul 2014 10:00:57 -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:content-transfer-encoding; bh=0QtM5jAGPZNIPJA1HRShERyjItju8sIPYjQgrGfvpx8=; b=I5RTVmJ9ilk/b04hEPKfLXZR9wXzcALEahdsciCqGp9rNsY0Tqia8S6OJyaBJ0ee/7 v2o0xO+HMu6I4O3nLGI/8JTNX1hqZMCFXcZezqKo7/6tWYGfnpKei6YyixqTytxkFqqB 5pz4tOMMKpIoOwc7E3aCEYMyJkgd3X3d/rRBOQO1Ck5s8MNpgwuy4seyaWJRH3BkQ4GM oyub5kh4k4F2/Bx+UnvLLDc9E4Cvj/G36EbkTj63mjxV4P1YpRNFLVI5fCZMtlcQUMWB XEj2DGVOnTPBTwZziW8s+DtZo59p5+UjpDk1S4c/RENVvs3+zreIqCQm6zJs+zD8cBBD 0Bsg== X-Gm-Message-State: ALoCoQnWEJIAuCREmlhJIIWb7YVr06yvo9YtO7eHH/ghFYj1ABTJQm2tc8R/ac5DRGFe2C6VLApjULnQQvx3YXsFRYO+v11JBmzGLoRWVOx8tC82YoLyoNu7orQ/Hvp2YytvmTwGQ8dF X-Received: by 10.50.41.6 with SMTP id b6mr5548915igl.40.1404838857481; Tue, 08 Jul 2014 10:00:57 -0700 (PDT) X-Received: by 10.50.41.6 with SMTP id b6mr5548896igl.40.1404838857346; Tue, 08 Jul 2014 10:00:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Tue, 8 Jul 2014 10:00:26 -0700 (PDT) In-Reply-To: <3E62D8C3-FAF2-4D9F-89C9-EBBEF4261550@ve7jtb.com> References: <1403870837.2440.124.camel@shakespeare> <930f1bd03c9e4cbaae1e5c321b0ee5ec@BLUPR03MB309.namprd03.prod.outlook.com> <25c76f47a47e4c9faac9995cc1d89364@BLUPR03MB309.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B16804296739439AD990D2@TK5EX14MBXC294.redmond.corp.microsoft.com> <2196A1F4-51D1-45FF-8F9B-2BD3BF0F7F66@oracle.com> <78548d3d22c84ea19ee58a3336f93adf@BLUPR03MB309.namprd03.prod.outlook.com> <3E62D8C3-FAF2-4D9F-89C9-EBBEF4261550@ve7jtb.com> From: Brian Campbell Date: Tue, 8 Jul 2014 10:00:26 -0700 Message-ID: To: John Bradley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/bWtHxrJjTRoyI5ybm_ZIPWHPPgM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:01:14 -0000 Perhaps I=E2=80=99m just in a minority that lacks the intellectual prowess = to really understand the WS* specifications but, to me anyway, saying that it=E2=80=99s clearly defined there is standing on very shaky ground. When I read =C2=A71.3 of draft-jones-oauth-token-exchange-00[0], it sure sounded to me like it was describing the result of an On-Behalf-Of request as retuning a composite token with claims about both principal A and B saying, "with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B.=E2=80=9D Whereas the MS FAQ[1] suggests that su= ch a composite token is requested using ActAs, =E2=80=9Can ActAs RST element indicates that the requestor wants a token that contains claims about two distinct entities: the requestor, and an external entity represented by the token in the ActAs element.=E2=80=9D And an OnBehalfOf request is for a token with claims about only one thing, =E2=80=9Can OnBehalfOf RST element indicates that the requestor wants a token that contains claims only about one entity: the external entity represented by the token in the OnBehalfOf element." John mentioned to me some time ago that he thought the use of the terms was reversed in draft-jones-oauth-token-exchange-00 vs WS-Trust. I didn=E2=80=99t believe him (as usual) so I went internet searching to try and find something to prove him wrong. However, I quickly found what I described in the previous paragraph, which was enough to suggest he was at least partially correct. That=E2=80=99s what I was referring to in m= y ordinal message on this thread and I apologize if this has been a unnecessary distraction. I understand it was just a -00 version of an individual draft. I was only trying to point out an area that I thought was confusing with the hoped that it could be clarified. I do think there=E2=80=99s potentially a lot of utility in a token exchange protocol and I=E2=80=99d be interested in contributing in some way. But, to= me anyway, this draft feels a lot like WS-Trust getting a makeover with JWT/JSON and kind of being bolted onto the Token Endpoint. When I think about OAuth Token Exchange I envision something more aligned with, and utilizing the constructs provided by, OAuth 2.0 while also being something that is similarly friendly to developers on the client side. [0] http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00#section-= 1.3 [1] http://msdn.microsoft.com/en-us/library/ee748487.aspx On Thu, Jul 3, 2014 at 4:09 PM, John Bradley wrote: > This is the first time this draft has come up on the list so people comin= g > up to speed is to be expected. > > In WS-Trust the security tokens are not tied to a single representation. > > /wst:RequestSecurityToken/wst14:ActAs > > This OTPIONAL element indicates that the requested token is expected to > contain information about the identity represented by the content of this > element and the token requestor intends to use the returned token to act = as > this identity. The identity that the requestor wants to act-as is specifi= ed > by placing a security token or element with= in > the element. > > > Is clear that the resulting token contains information about the identity > represented by the security token passed as the content of the ActAs elem= ent > and that the requester wants to act-as is that identity. > > Depending on the resulting security token that may be represented > differently. Nothing explicitly states that the identity of the request= er > is in the resulting token, however when SAML tokens are used it typically= is > represented along with the identity to act-as. > > OnBehalfOf being older was treated as a proxy type request On-Behalf-Of t= he > initial subject resulting in a token for the Original subject that may ha= ve > been used by another party such as the requester. > > So Sec 1.3 may be trying to describe composite tokens vs single subject > tokens that may be beyond the scope of those token independent parameters= in > WS-Trust. > > It is probably fair to say that from the way those parameters are > implemented for SAML tokens in many if not all STS the description seems > backwards. > > Having something that describes how the output token varies based on inpu= t > for typical token types might help make it more concrete for people. > > John B. > > On Jul 3, 2014, at 5:55 PM, Anthony Nadalin wrote= : > > ActAs the returned token is expected to be represented by the identity > described by this parameter > OnBehalfOf the request is being made by the identity described by this > parameter > > These terms have been pretty clearly defined in the WS specifications, I > don=E2=80=99t understand the confusion. If section 1.3 is confusing, I=E2= =80=99m OK with > dropping this > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Thursday, July 3, 2014 2:44 PM > To: Phil Hunt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > > I pointed out a problem with the non normative text in sec 1.3 to Mike of= f > list quite a while go. > > > 1.3. On-Behalf-Of vs. Impersonation Semantics > > > > > > When principal A acts on behalf of principal B, A is given all the > > rights that B has within some defined rights context. Whereas, with > > on-behalf-of semantics, principal A still has its own identity > > separate from B and it is explicitly understood that while B may have > > delegated its rights to A, any actions taken are being taken by A and > > not B. In a sense, A is an agent for B. > > On-behalf-of semantics are therefore different than impersonation > > semantics, with which it is sometimes confused. When principal A > > impersonates principal B, then in so far as any entity receiving > > Claims is concerned, they are actually dealing with B. It is true > > that some members of the identity system might have awareness that > > impersonation is going on but it is not a requirement. For all > > intents and purposes, when A is acting for B, A is B. > > > OnBehalfOf "indicates that the requestor is making the request on behalf= of > another." and returns a security token to the requestor that contains a > single set of claims. > > ActAs provides a security token/ assertion about subject A in a request f= rom > Requester B and the response is a composite token that has Requester B as > the subject but also includes claims about subject A. > > See MS FAQ to clarify this popular question > http://msdn.microsoft.com/en-us/library/ee748487.aspx > > I think this is what Brian was trying to get at. > > If we can't all agree on the semantics of OnBehalfOf (It has been around = for > a long time) then we have a problem and should pick different terms. > > The normative text is correct, however sec 2.2 adds an optional "actor" > claim to the initial JWT that is to be presented as the value of > on_behalf_of in the request. That is an addition to the WS-Trust text an= d > took me several reads to understand that it is not a element in the JWT > response. > > I offered to help with the spec as I think it is useful. The semantics a= re > tricky for people to understand so I was not all that concerned that the > first draft was not perfect. > > I suspect some concrete examples will help. > > John B. > > On Jul 3, 2014, at 3:51 PM, Phil Hunt wrote: > > > I suspect it lines up. But Brian=E2=80=99s point may still be relevant. T= here is > *long* standing confusion of the terms (because many of have different > english interpretation than WS-Trust). Might be time for new terms? > > Impersonate (or even personate) vs. delegate ? > > Those terms differentiate between impersonating a whole person vs. having > delegate or scoped authority to act for someone. > > Sorry if this is an old discussion. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jul 3, 2014, at 12:20 PM, Mike Jones wro= te: > > > I=E2=80=99m lost too, as when I wrote this, I explicitly modelled it afte= r WS-Trust. > If there=E2=80=99s a concrete discrepancy you can point out, that would b= e great. > > FYI, I do plan to refresh this draft too allow for a more flexible trust > model shortly. > > -- Mike > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin > Sent: Thursday, July 03, 2014 12:04 PM > To: Brian Campbell > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > > I=E2=80=99m lost, the terms defined in the oauth token-exchange draft are= the same > terms defined in ws-trust and have the same definitions > > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Thursday, July 3, 2014 12:02 PM > To: Anthony Nadalin > Cc: Vladimir Dzhuvinov; oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > > And I was suggesting that OAuth token exchange align with the WS-Trust > definitions or maybe even define totally new terms. But not use the same > terms to mean different things. > > > > On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin > wrote: > > The explanation of on-behalf-Of and ActAs are correct in the document as > defined by WS-Trust, this may not be your desire or understanding but tha= t > is how WS-Trust implementations should work > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell > Sent: Thursday, July 3, 2014 11:44 AM > To: Vladimir Dzhuvinov > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > > > FWIW, I am very interested in the general concept of a lightweight or OAu= th > based token exchange mechanism. However, despite some distaste for the > protocol, our existing WS-Trust functionality has proven to be "good enou= gh" > for most use-cases, which seems to prevent work on token exchange from > getting any real priority. > > I have a few thoughts on > http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've > been meaning to write down but haven't yet, so this seems like as good a > time as any. > > I would really like to see a simpler request model that doesn't require t= he > request to be JWT encoded. > > The draft mentions the potential confusion around On-Behalf-Of vs. > Impersonation Semantics. And it is confusing (to me anyway). In fact, the > use of Act-As and On-Behalf-Of seem to be reversed from how they are defi= ned > in WS-Trust (this MS FAQ has less confusing wording). They should probabl= y > be aligned with that prior work to avoid further confusion. Or maybe maki= ng > a clean break and introducing new terms would be better. > > I don't think the security_token_request grant type value is strictly leg= al > per RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.1= 0 > would allow it but according to > http://tools.ietf.org/html/rfc6749#section-4.5 extension grants need an > absolute URI as the grant type value (there's no grant type registry so t= he > URI is the only means of preventing collision). > > > > > > > > > > > On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov > wrote: > > Has anyone implemented the OAuth 2.0 Token exchange draft, in particular > the on-behalf-of semantics? We've got a use case for that and I'm > curious if someone has used it in practice. > > http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 > > Thanks, > > Vladimir > -- > Vladimir Dzhuvinov > Connect2id Ltd. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Tue Jul 8 10:06:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EED71B2B7E for ; Tue, 8 Jul 2014 10:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6psldjv_duT for ; Tue, 8 Jul 2014 10:06:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933971B2B4A for ; Tue, 8 Jul 2014 10:06:52 -0700 (PDT) Received: from CY1PR0301MB1177.namprd03.prod.outlook.com (25.160.165.20) by CY1PR0301MB0842.namprd03.prod.outlook.com (25.160.163.148) with Microsoft SMTP Server (TLS) id 15.0.974.11; Tue, 8 Jul 2014 17:06:51 +0000 Received: from BN3PR0301CA0059.namprd03.prod.outlook.com (25.160.152.155) by CY1PR0301MB1177.namprd03.prod.outlook.com (25.160.165.20) with Microsoft SMTP Server (TLS) id 15.0.969.15; Tue, 8 Jul 2014 17:06:49 +0000 Received: from BN1AFFO11FD057.protection.gbl (2a01:111:f400:7c10::142) by BN3PR0301CA0059.outlook.office365.com (2a01:111:e400:401e::27) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Tue, 8 Jul 2014 17:06:48 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD057.mail.protection.outlook.com (10.58.53.72) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Tue, 8 Jul 2014 17:06:48 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0195.002; Tue, 8 Jul 2014 17:06:12 +0000 From: Mike Jones To: Phil Hunt , Hannes Tschofenig Thread-Topic: Dynamic Client Registration: IPR Confirmation Thread-Index: AQHPmqNjTLUtygPATEaoV9K+QkTus5uWWTqAgAAPVUY= Date: Tue, 8 Jul 2014 17:06:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53BBDBEE.703@gmx.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADA02B7TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(189002)(377454003)(55885003)(51704005)(24454002)(199002)(54356999)(16236675004)(86612001)(76176999)(86362001)(46102001)(81542001)(106116001)(74662001)(92566001)(85852003)(2656002)(87936001)(97736001)(20776003)(26826002)(85306003)(83072002)(84326002)(74502001)(64706001)(71186001)(92726001)(21056001)(80022001)(50986999)(81342001)(19625215002)(107046002)(99396002)(77096002)(69596002)(81156004)(55846006)(6806004)(4396001)(19580405001)(79102001)(84676001)(19580395003)(106466001)(33656002)(104016002)(95666004)(77982001)(76482001)(44976005)(83322001)(68736004)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:CY1PR0301MB1177; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0266491E90 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Rik6BxLJR_4vUjvrfOPsoQDuI7I Cc: Maciej Machulak , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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, 08 Jul 2014 17:06:55 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADA02B7TK5EX14MBXC294r_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable I likewise do not hold any IPR on these specs. ________________________________ From: Phil Hunt Sent: =FD7/=FD8/=FD2014 9:11 AM To: Hannes Tschofenig Cc: Mike Jones; John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org Subject: Re: Dynamic Client Registration: IPR Confirmation I confirm I have no IPR disclosures on this document. Phil > On Jul 8, 2014, at 4:54, Hannes Tschofenig wr= ote: > > Hi Phil, John, Maciej, Justin, Mike, > > I am working on the shepherd writeup for the dynamic client registration > document and 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? > > Ciao > Hannes > > --_000_4E1F6AAD24975D4BA5B16804296739439ADA02B7TK5EX14MBXC294r_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
I likewise do= not hold any IPR on these specs.
From: Phil Hunt
Sent: =FD7/= =FD8/=FD2014 9:11 AM
To: Hannes Tschofenig
Cc: Mike Jones; John Bradley; Justin Richer; Maciej Machula= k; oauth@ietf.org
Subject: Re: D= ynamic Client Registration: IPR Confirmation

I confirm I have no IPR disclosures on this docume= nt.

Phil

> On Jul 8, 2014, at 4:54, Hannes Tschofenig <hannes.tschofenig@gmx.n= et> wrote:
>
> Hi Phil, John, Maciej, Justin, Mike,
>
> I am working on the shepherd writeup for the dynamic client registrati= on
> document and one item in the template requires me to indicate whether<= br> > each document author has confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 7= 8
> and BCP 79 have already been filed.
>
> Could you please confirm?
>
> Ciao
> Hannes
>
>
--_000_4E1F6AAD24975D4BA5B16804296739439ADA02B7TK5EX14MBXC294r_-- From nobody Tue Jul 8 11:56:10 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEB61A04B8 for ; Tue, 8 Jul 2014 11:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yplViyi82Jl for ; Tue, 8 Jul 2014 11:56:05 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B70A1A04B0 for ; Tue, 8 Jul 2014 11:56:03 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id r5so5561624qcx.22 for ; Tue, 08 Jul 2014 11:56:02 -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=4aj1vf35N5tvNPN4IkACF8OUoRBe8Gvz4K13MfQTKwc=; b=F8ybUoWx2Je9MF5yipq0bQVBWeAgVtYoI43Wzj5TRiSChX4yX2KD/NGRTmQ8EWaQfU TK6moptsvsRxQ/DgIq7g7LnQKySEI9CX2p46BOQ1HTSfkZ0D72cS4VcHbWc2VDWFyFjo LKxYcq2NJMU/kD2N14wWcghljNGaGVfinIhku4vTjMJO/vza9MOCJ3bfBUFoSR5DESe4 FJ0bR2roaN7ZYr0VEqJgeBwGf6YF4JRDOM9B4+PdXK9UnlOyoowm8/2gzu8BRjSc8S3T Uhk6Nm0M1SZObvjxewoGOL12HqJXVCUr6G+yvs6EXzw6hvMNzq9sllMLNaOEHx7zYwjg WtyQ== X-Gm-Message-State: ALoCoQm+V45gkHeZDY/rg/6wMHqNyjjf6pxBzInzcjb1wBBFv0zdpFgGcmbwpbvyLfjBjXfByHHw X-Received: by 10.229.127.199 with SMTP id h7mr59862336qcs.21.1404845762540; Tue, 08 Jul 2014 11:56:02 -0700 (PDT) Received: from [192.168.0.200] ([201.189.83.252]) by mx.google.com with ESMTPSA id g47sm18384992qge.48.2014.07.08.11.55.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 11:56:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <53BBF0A6.3000801@gmx.net> Date: Tue, 8 Jul 2014 14:56:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53BBE144.90307@gmx.net> <53BBF0A6.3000801@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SJ2FrxJKC25RLhtbL3-h7TOQZ1Q Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 08 Jul 2014 18:56:08 -0000 The application_type is collected as part of current registration by = Google and some other OAuth providers as part of registering redirect = uri. The text was cut down to allow more flexibility in OAuth. Connect = requires registration of redirect_uri and is more ridged about it than = OAuth 2. Do you think the Connect wording would be appropriate for OAuth? John B. On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig = wrote: > This additional information makes a lot of sense. >=20 > As you said in an earlier mail, the attempt to copy text from the = OpenID > Connect spec failed a bit... >=20 > On 07/08/2014 02:49 PM, Nat Sakimura wrote: >> I suppose authors has imported one of the security feature of OpenID >> Connect here as well. In the Dynamic Client Registration standard, = which >> is a bit longer than IETF version. You can see the reason from it:=20 >>=20 >> application_type >> OPTIONAL. Kind of the application. The default, if omitted, is = web. >> The defined values are native or web. Web Clients using the OAuth >> Implicit Grant Type MUST only register URLs using the https scheme >> as redirect_uris; they MUST NOT use localhost as the hostname. >> Native Clients MUST only register redirect_uris using custom URI >> schemes or URLs using the http: scheme with localhost as the >> hostname. Authorization Servers MAY place additional constraints = on >> Native Clients. Authorization Servers MAY reject Redirection URI >> values using the http scheme, other than the localhost case for >> Native Clients. The Authorization Server MUST verify that all the >> registered redirect_uris conform to these constraints. This = prevents >> sharing a Client ID across different types of Clients. >>=20 >> Regards,=20 >>=20 >> Nat >>=20 >>=20 >> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig = > >: >>=20 >> Hi all, >>=20 >> with version -18 you guys have added a new meta-data attribute, = namely >> application_type. >>=20 >> First, this new attribute is not listed in the IANA consideration >> section. >>=20 >> Second, could you provide a bit of motivation why you need it? = What >> would the authorization server do with that type of information? = The >> description is rather short. >>=20 >> IMHO there is also no clear boundary between a "native" and "web" = app. >> Just think about smart phone apps that are developed using = JavaScript. >> Would this be a web app or a native app? >>=20 >> Here is the definition from the draft: >>=20 >> application_type >> OPTIONAL. Kind of the application. The default, if = omitted, is >> "web". The defined values are "native" or "web". >>=20 >> Ciao >> Hannes >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jul 8 12:00:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971CC1A049C for ; Tue, 8 Jul 2014 12:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Dve058CKmeO for ; Tue, 8 Jul 2014 12:00:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00051A02D8 for ; Tue, 8 Jul 2014 11:59:58 -0700 (PDT) Received: from BN3PR0301CA0070.namprd03.prod.outlook.com (25.160.152.166) by BY2PR03MB143.namprd03.prod.outlook.com (10.242.35.149) with Microsoft SMTP Server (TLS) id 15.0.969.15; Tue, 8 Jul 2014 18:59:55 +0000 Received: from BN1AFFO11FD017.protection.gbl (2a01:111:f400:7c10::182) by BN3PR0301CA0070.outlook.office365.com (2a01:111:e400:401e::38) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Tue, 8 Jul 2014 18:59:56 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD017.mail.protection.outlook.com (10.58.52.77) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Tue, 8 Jul 2014 18:59:55 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Tue, 8 Jul 2014 18:59:16 +0000 From: Mike Jones To: Nat Sakimura , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Dynamic Client Registration: policy_uri Thread-Index: AQHPmqWY5AtEKQRGw0O3kUVR/CP4H5uWH0WAgAAB9gCAAAmsgIAAXNkA Date: Tue, 8 Jul 2014 18:59:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA07A1@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53BBDFA0.8010306@gmx.net> <53BBE932.6000808@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADA07A1TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(199002)(189002)(53754006)(377424004)(479174003)(15454003)(55885003)(51704005)(24454002)(377454003)(66066001)(99396002)(26826002)(85306003)(74662001)(77096002)(86362001)(81156004)(6806004)(80022001)(92566001)(2656002)(83322001)(19300405004)(84676001)(84326002)(74502001)(31966008)(19580405001)(44976005)(92726001)(19580395003)(69596002)(512874002)(106116001)(20776003)(4396001)(106466001)(71186001)(64706001)(81342001)(15975445006)(68736004)(15202345003)(81542001)(16297215004)(16236675004)(107046002)(15395725005)(50986999)(76482001)(93886003)(19625215002)(76176999)(21056001)(46102001)(83072002)(55846006)(87936001)(79102001)(307094003)(97736001)(86612001)(104016002)(95666004)(85852003)(33656002)(54356999)(77982001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB143; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0266491E90 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/whE7YE4DqfOx0NGQ9mts2oHgI1w Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri 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, 08 Jul 2014 19:00:04 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADA07A1TK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIE5hdOKAmXMgYXNzZXNzbWVudC4gIEnigJltIGZpbmUgdXBkYXRpbmcgdGhl IHRleHR1YWwgZGVzY3JpcHRpb24gb2YgdGhlIHBhcmFtZXRlciwgYnV0IHdlIHNob3VsZCBub3Qg Y29uc2lkZXIgYnJlYWtpbmcgY2hhbmdlcyB0byB0aGUgcGFyYW1ldGVyIG5hbWVzIGF0IHRoaXMg cG9pbnQuDQoNCkRvIHlvdSBoYXZlIHNwZWNpZmljIHdvcmRpbmcgaW4gbWluZCwgSGFubmVzPw0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIE5hdCBTYWtpbXVyYQ0KU2VudDogVHVlc2RheSwgSnVseSAwOCwgMjAx NCA2OjI2IEFNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcNCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uOiBwb2xpY3lf dXJpDQoNCkkgYW0gbm90IGFnYWluc3QgdXNpbmcgdGhlIHRlcm0gIlByaXZhY3kgUG9saWN5IiBp biB0aGUgZGVzY3JpcHRpb24uDQpEZXBlbmRpbmcgb24gdGhlIGp1cmlzZGljdGlvbiBhbmQgbGFu Z3VhZ2UsIGRpcmVjdCB0cmFuc2xhdGlvbiBvZiBzdWNoDQpjYW4gYmUgIkRhdGEgUHJvdGVjdGlv biBQb2xpY3kiLCAiUGVyc29uYWwgRGF0YSBQcm90ZWN0aW9uIFBvbGljeSIsIGV0Yy4sDQppbnN0 ZWFkIHNvIGp1c3QgZG9kZ2luZyBpdCBieSBhdm9pZGluZyB0aGUgbGFiZWwgd291bGQgYmUgbW9y ZSBwb2xpdGljYWxseSBuZXV0cmFsLA0KYnV0IGl0IGNvdWxkIGJlIGZpbmUgYWZ0ZXIgYWxsLg0K DQpJIGFtIG5vdCBmaW5lIHdpdGggY2hhbmdpbmcgdGhlIHBhcmFtZXRlciBuYW1lIHRob3VnaC4N ClNsaWdodCB2YXJpYXRpb24gaW4gdGhlIHBhcmFtZXRlciBiZXR3ZWVuIHRoZSBzcGVjcyBnZW5l cmFsbHkgZG8gbm90IGhlbHAgdGhlIGRldmVsb3BlcnMuDQoNCk5hdA0KDQoyMDE0LTA3LTA4IDIx OjUwIEdNVCswOTowMCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5l dDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+Og0KRm9yIGV4YW1wbGUsIGV2ZW4g RmFjZWJvb2sgY2FsbHMgdGhpcyBzdHVmZiAiUHJpdmFjeSBQb2xpY3kgVVJMIi4NCg0KT24gMDcv MDgvMjAxNCAwMjo0MyBQTSwgTmF0IFNha2ltdXJhIHdyb3RlOg0KPiBwb2xpY3lfdXJpIGNhbWUg ZG93biBmcm9tIE9wZW5JRCBDb25uZWN0IER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhaXRvbiAxLjAN Cj4gWzFdLg0KPg0KPiBJdCBnb2VzOg0KPg0KPiBwb2xpY3lfdXJpDQo+ICAgICBPUFRJT05BTC4g VVJMIHRoYXQgdGhlIFJlbHlpbmcgUGFydHkgQ2xpZW50IHByb3ZpZGVzIHRvIHRoZSBFbmQtVXNl cg0KPiAgICAgdG8gcmVhZCBhYm91dCB0aGUgaG93IHRoZSBwcm9maWxlIGRhdGEgd2lsbCBiZSB1 c2VkLiBUaGUgdmFsdWUgb2YNCj4gICAgIHRoaXMgZmllbGQgTVVTVCBwb2ludCB0byBhIHZhbGlk IHdlYiBwYWdlLiBUaGUgT3BlbklEIFByb3ZpZGVyDQo+ICAgICBTSE9VTEQgZGlzcGxheSB0aGlz IFVSTCB0byB0aGUgRW5kLVVzZXIgaWYgaXQgaXMgZ2l2ZW4uIElmIGRlc2lyZWQsDQo+ICAgICBy ZXByZXNlbnRhdGlvbiBvZiB0aGlzIENsYWltIGluIGRpZmZlcmVudCBsYW5ndWFnZXMgYW5kIHNj cmlwdHMgaXMNCj4gICAgIHJlcHJlc2VudGVkIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMQ0K PiAgICAgPGh0dHA6Ly9vcGVuaWQuYml0YnVja2V0Lm9yZy9vcGVuaWQtY29ubmVjdC1yZWdpc3Ry YXRpb24tMV8wLmh0bWwjTGFuZ3VhZ2VzQW5kU2NyaXB0cz4uDQo+DQo+IEl0IGlzIGNsZWFybHkg cHJpdmFjeSByZWxhdGVkLiBJbiBmYWN0LCBpdCB1c2VkIHRvIGJlIGEgcGFydCBvZiBPcGVuSUQN Cj4gQ29ubmVjdCBDb3JlIGluIHdoaWNoIHRoZSBSUCBoYWQgdG8gc2VuZCBpdCB0byBvYnRhaW4g dGhlIHBlcm1pc3Npb24uIEl0DQo+IGlzIG9wdGlvbmFsIG9ubHkgYmVjYXVzZSBpbiBjZXJ0YWlu IGVudGVycHJpc2UgdHlwZSBzZXR0aW5nLCBpdCBpcw0KPiB1bm5lY2Vzc2FyeS4gSW4gdGhlIGNv bnN1bWVyIGNhc2UsIEkgcmVnYXJkIGl0IGFzIGVzc2VudGlhbC4gSW4gYW55DQo+IGNhc2UsIHRo aXMgaXMgc29tZXRoaW5nIGEgdHJ1c3QgZnJhbWV3b3JrIHNob3VsZCBzZXQgYXMgaXRzIHJ1bGUs IGFuZA0KPiBub3QgdGhlIHByb3RvY29sIGl0c2VsZi4NCj4NCj4gVGhlIGRyYWZ0IC0xOCB0ZXh0 IGdvZXM6DQo+DQo+IHBvbGljeV91cmkNCj4gICAgICAgVVJMIHRoYXQgcG9pbnRzIHRvIGEgaHVt YW4tcmVhZGFibGUgUG9saWN5IGRvY3VtZW50IGZvciB0aGUNCj4gICAgICAgY2xpZW50LiAgVGhl IGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBkaXNwbGF5IHRoaXMgVVJMIHRvIHRoZQ0KPiAg ICAgICBlbmQtdXNlciBpZiBpdCBpcyBnaXZlbi4gIFRoZSBwb2xpY3kgdXN1YWxseSBkZXNjcmli ZXMgaG93IGFuIGVuZC0NCj4gICAgICAgdXNlcidzIGRhdGEgd2lsbCBiZSB1c2VkIGJ5IHRoZSBj bGllbnQuICBUaGUgdmFsdWUgb2YgdGhpcyBmaWVsZA0KPiAgICAgICBNVVNUIHBvaW50IHRvIGEg dmFsaWQgd2ViIHBhZ2UuICBUaGUgdmFsdWUgb2YgdGhpcyBmaWVsZCBNQVkgYmUNCj4gICAgICAg aW50ZXJuYXRpb25hbGl6ZWQsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMiA8aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVnLTE4I3NlY3Rpb24tMi4y Pi4NCj4NCj4NCj4gSXQgaGFzIGJlZW4gY29udmVydGVkIHRvIGJlIGEgYml0IHZhZ3VlLiBJIHdv dWxkICsxIHRvIHRpZ2h0ZW4gaXQgdXAuDQo+IE5vdGUgdGhhdCB0aGVyZSBpcyB0b3NfdXJpIHRv IGRlc2NyaWJlIHRoZSBUZXJtcyBvZiBTZXJ2aWNlIGJ5IHRoZQ0KPiBjbGllbnQgYW5kIHBvaWN5 X3VyaSBpcyBub3QgaW50ZW5kZWQgZm9yIHRoaXMgcHVycG9zZSBidXQgb25seSBmb3IgdGhlDQo+ IHNlcnZpY2UvY2xpZW50J3MgcHJpdmFjeSBwb2xpY3kuDQo+DQo+IEJUVywgSSBqdXN0IGZvdW5k IHRoYXQgYSBsb3Qgb2YgdGV4dCBhcmUgbW9yZSBvciBsZXNzIHRoZSBkdXBsaWNhdGUgb3INCj4g cmUtc3RhdGVtZW50IG9mIFsxXS4gSU1ITywgaXQgc2hvdWxkIHRyeSB0byByZWZlciB0aGUgb3Jp Z2luYWwgZG9jdW1lbnQNCj4gd2hlcmUgcG9zc2libGUgYXMgaXQgaXMgYSByZWZlcmFibGUgc3Rh bmRhcmQsIGFuZCBwdXQgWzFdIGluIHRoZQ0KPiBSZWZlcmVuY2Ugc2VjdGlvbiBhcyB3ZWxsLg0K Pg0KPiBCZXN0LA0KPg0KPiBOYXQNCj4NCj4gWzFdIGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29w ZW5pZC1jb25uZWN0LXJlZ2lzdHJhdGlvbi0xXzAuaHRtbA0KPg0KPg0KPiAyMDE0LTA3LTA4IDIx OjEwIEdNVCswOTowMCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5l dDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4NCj4gPG1haWx0bzpoYW5uZXMudHNj aG9mZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4+Og0KPg0K PiAgICAgSGkgYWxsLA0KPg0KPiAgICAgdHdvIGVhcmxpZXIgcmV2aWV3cyBJIGhhdmUgbm90aWNl ZCB0aGF0IHRoZSBwb2xpY3lfdXJpIG1ldGEtZGF0YQ0KPiAgICAgYXR0cmlidXRlIGlzIG5vdCBj b3JyZWN0bHkgc3BlY2lmaWVkLiBJIG9mZmVyZWQgYSBzdWdnZXN0aW9uIGFuZCBpbiBib3RoDQo+ ICAgICBjYXNlcyBteSByZXF1ZXN0IHdhcyBpZ25vcmVkLg0KPg0KPiAgICAgTWF5YmUgdGhlcmUg aXMgYSByZWFzb24gdG8gcmVqZWN0IG15IHJlcXVlc3QgYnV0IEkgYW0gdW5jZXJ0YWluIGFib3V0 DQo+ICAgICB0aGUgcmVsYXRpb25zaGlwIHdpdGggYW5vdGhlciBtZXRhLWRhdGEgYXR0cmlidXRl LCB0aGUgdGVybXMtb2Ytc2VydmljZQ0KPiAgICAgYXR0cmlidXRlLg0KPg0KPiAgICAgSGVyZSBp cyB3aGF0IEkgc2FpZCBpbiBteSBsYXN0IHJldmlldzoNCj4gICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzEyODc5Lmh0bWwNCj4NCj4gICAg ICINCj4gICAgIHBvbGljeV91cmk6IEluIG15IHByZXZpb3VzIHJldmlldyBJIGFyZ3VlZCB0aGF0 IHRoZSByaWdodCB0ZXJtaW5vbG9neQ0KPiAgICAgaGVyZSBpcyBwcml2YWN5IG5vdGljZSBhbmQg eW91IGNhbiBldmVuIHJlLXVzZSB0aGUgSUFQUCB0ZXJtaW5vbG9neS4NCj4gICAgIFVubGVzcyB0 aGUgcG9saWN5IFVSSSBoYXMgbm90aGluZyB0byBkbyB3aXRoIHByaXZhY3kgSSB3b3VsZCBwcmVm ZXIgdGhpcw0KPiAgICAgdGVybWlub2xvZ3kgY2hhbmdlLiBJZiB5b3UgZGlzYWdyZWUgSSB3b3Vs ZCBwcmVmZXIgdG8gaGF2ZSBhDQo+ICAgICBkZXNjcmlwdGlvbiBhYm91dCB3aGF0IHBvbGljeSBt ZWFucyBpbiB0aGlzIGNvbnRleHQuDQo+ICAgICAiDQo+DQo+ICAgICBDb3VsZCB5b3UgZ3V5cyBl eHBsYWluPw0KPg0KPiAgICAgQ2lhbw0KPiAgICAgSGFubmVzDQo+DQo+DQo+ICAgICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgT0F1dGggbWFp bGluZyBsaXN0DQo+ICAgICBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+IDxt YWlsdG86T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPj4NCj4gICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4NCj4NCj4NCj4gLS0N Cj4gTmF0IFNha2ltdXJhICg9bmF0KQ0KPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCj4g aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQo+IEBfbmF0X2VuDQoNCg0KDQotLQ0KTmF0IFNha2lt dXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2lt dXJhLm9yZy8NCkBfbmF0X2VuDQo= --_000_4E1F6AAD24975D4BA5B16804296739439ADA07A1TK5EX14MBXC294r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIE5h dOKAmXMgYXNzZXNzbWVudC4mbmJzcDsgSeKAmW0gZmluZSB1cGRhdGluZyB0aGUgdGV4dHVhbCBk ZXNjcmlwdGlvbiBvZiB0aGUgcGFyYW1ldGVyLCBidXQgd2Ugc2hvdWxkIG5vdCBjb25zaWRlciBi cmVha2luZyBjaGFuZ2VzIHRvIHRoZSBwYXJhbWV0ZXIgbmFtZXMNCiBhdCB0aGlzIHBvaW50Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+RG8geW91IGhhdmUgc3BlY2lmaWMgd29yZGluZyBpbiBtaW5kLCBIYW5uZXM/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5OYXQgU2FraW11cmE8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg SnVseSAwOCwgMjAxNCA2OjI2IEFNPGJyPg0KPGI+VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZzxi cj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtP QVVUSC1XR10gRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uOiBwb2xpY3lfdXJpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3QgYWdhaW5zdCB1c2luZyB0aGUg dGVybSAmcXVvdDtQcml2YWN5IFBvbGljeSZxdW90OyBpbiB0aGUgZGVzY3JpcHRpb24uJm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVwZW5kaW5nIG9u IHRoZSBqdXJpc2RpY3Rpb24gYW5kIGxhbmd1YWdlLCBkaXJlY3QgdHJhbnNsYXRpb24gb2Ygc3Vj aCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Y2FuIGJlICZxdW90O0RhdGEgUHJvdGVjdGlvbiBQb2xpY3kmcXVvdDssICZxdW90O1BlcnNv bmFsIERhdGEgUHJvdGVjdGlvbiBQb2xpY3kmcXVvdDssIGV0Yy4sJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbnN0ZWFkIHNvIGp1c3Qg ZG9kZ2luZyBpdCBieSBhdm9pZGluZyB0aGUgbGFiZWwgd291bGQgYmUgbW9yZSBwb2xpdGljYWxs eSBuZXV0cmFsLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+YnV0IGl0IGNvdWxkIGJlIGZpbmUgYWZ0ZXIgYWxsLiAmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3Qg ZmluZSB3aXRoIGNoYW5naW5nIHRoZSBwYXJhbWV0ZXIgbmFtZSB0aG91Z2guJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbGlnaHQgdmFy aWF0aW9uIGluIHRoZSBwYXJhbWV0ZXIgYmV0d2VlbiB0aGUgc3BlY3MgZ2VuZXJhbGx5IGRvIG5v dCBoZWxwIHRoZSBkZXZlbG9wZXJzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4y MDE0LTA3LTA4IDIxOjUwIEdNVCYjNDM7MDk6MDAgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhy ZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+aGFu bmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Rm9yIGV4YW1wbGUsIGV2ZW4gRmFjZWJvb2sgY2FsbHMgdGhpcyBzdHVmZiAm cXVvdDtQcml2YWN5IFBvbGljeSBVUkwmcXVvdDsuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT24gMDcvMDgvMjAxNCAwMjo0MyBQTSwgTmF0IFNha2lt dXJhIHdyb3RlOjxicj4NCiZndDsgcG9saWN5X3VyaSBjYW1lIGRvd24gZnJvbSBPcGVuSUQgQ29u bmVjdCBEeW5hbWljIENsaWVudCBSZWdpc3RyYWl0b24gMS4wPGJyPg0KJmd0OyBbMV0uPGJyPg0K Jmd0Ozxicj4NCiZndDsgSXQgZ29lczo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBwb2xpY3lfdXJpPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IE9QVElPTkFMLiBVUkwgdGhhdCB0aGUgUmVseWluZyBQYXJ0 eSBDbGllbnQgcHJvdmlkZXMgdG8gdGhlIEVuZC1Vc2VyPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 IHRvIHJlYWQgYWJvdXQgdGhlIGhvdyB0aGUgcHJvZmlsZSBkYXRhIHdpbGwgYmUgdXNlZC4gVGhl IHZhbHVlIG9mPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHRoaXMgZmllbGQgTVVTVCBwb2ludCB0 byBhIHZhbGlkIHdlYiBwYWdlLiBUaGUgT3BlbklEIFByb3ZpZGVyPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IFNIT1VMRCBkaXNwbGF5IHRoaXMgVVJMIHRvIHRoZSBFbmQtVXNlciBpZiBpdCBpcyBn aXZlbi4gSWYgZGVzaXJlZCw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgcmVwcmVzZW50YXRpb24g b2YgdGhpcyBDbGFpbSBpbiBkaWZmZXJlbnQgbGFuZ3VhZ2VzIGFuZCBzY3JpcHRzIGlzPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7IHJlcHJlc2VudGVkIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIu MTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7ICZuYnNw OyAmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQuYml0YnVja2V0Lm9yZy9vcGVuaWQt Y29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLmh0bWwjTGFuZ3VhZ2VzQW5kU2NyaXB0cyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly9vcGVuaWQuYml0YnVja2V0Lm9yZy9vcGVuaWQtY29ubmVjdC1yZWdp c3RyYXRpb24tMV8wLmh0bWwjTGFuZ3VhZ2VzQW5kU2NyaXB0czwvYT4mZ3Q7LjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8YnI+DQomZ3Q7IEl0IGlzIGNs ZWFybHkgcHJpdmFjeSByZWxhdGVkLiBJbiBmYWN0LCBpdCB1c2VkIHRvIGJlIGEgcGFydCBvZiBP cGVuSUQ8YnI+DQomZ3Q7IENvbm5lY3QgQ29yZSBpbiB3aGljaCB0aGUgUlAgaGFkIHRvIHNlbmQg aXQgdG8gb2J0YWluIHRoZSBwZXJtaXNzaW9uLiBJdDxicj4NCiZndDsgaXMgb3B0aW9uYWwgb25s eSBiZWNhdXNlIGluIGNlcnRhaW4gZW50ZXJwcmlzZSB0eXBlIHNldHRpbmcsIGl0IGlzPGJyPg0K Jmd0OyB1bm5lY2Vzc2FyeS4gSW4gdGhlIGNvbnN1bWVyIGNhc2UsIEkgcmVnYXJkIGl0IGFzIGVz c2VudGlhbC4gSW4gYW55PGJyPg0KJmd0OyBjYXNlLCB0aGlzIGlzIHNvbWV0aGluZyBhIHRydXN0 IGZyYW1ld29yayBzaG91bGQgc2V0IGFzIGl0cyBydWxlLCBhbmQ8YnI+DQomZ3Q7IG5vdCB0aGUg cHJvdG9jb2wgaXRzZWxmLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBkcmFmdCAtMTggdGV4dCBn b2VzOjxicj4NCiZndDs8YnI+DQomZ3Q7IHBvbGljeV91cmk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFVSTCB0aGF0IHBvaW50cyB0byBhIGh1bWFuLXJlYWRhYmxlIFBvbGljeSBkb2N1 bWVudCBmb3IgdGhlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjbGllbnQuICZuYnNw O1RoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgZGlzcGxheSB0aGlzIFVSTCB0byB0aGU8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVuZC11c2VyIGlmIGl0IGlzIGdpdmVuLiAm bmJzcDtUaGUgcG9saWN5IHVzdWFsbHkgZGVzY3JpYmVzIGhvdyBhbiBlbmQtPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB1c2VyJ3MgZGF0YSB3aWxsIGJlIHVzZWQgYnkgdGhlIGNsaWVu dC4gJm5ic3A7VGhlIHZhbHVlIG9mIHRoaXMgZmllbGQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IE1VU1QgcG9pbnQgdG8gYSB2YWxpZCB3ZWIgcGFnZS4gJm5ic3A7VGhlIHZhbHVlIG9m IHRoaXMgZmllbGQgTUFZIGJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW50ZXJuYXRpb25hbGl6ZWQsIGFzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDIuMiAmbHQ7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVnLTE4I3NlY3Rpb24tMi4yIiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVn LTE4I3NlY3Rpb24tMi4yPC9hPiZndDsuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEl0IGhhcyBiZWVuIGNvbnZlcnRl ZCB0byBiZSBhIGJpdCB2YWd1ZS4gSSB3b3VsZCAmIzQzOzEgdG8gdGlnaHRlbiBpdCB1cC48YnI+ DQomZ3Q7IE5vdGUgdGhhdCB0aGVyZSBpcyB0b3NfdXJpIHRvIGRlc2NyaWJlIHRoZSBUZXJtcyBv ZiBTZXJ2aWNlIGJ5IHRoZTxicj4NCiZndDsgY2xpZW50IGFuZCBwb2ljeV91cmkgaXMgbm90IGlu dGVuZGVkIGZvciB0aGlzIHB1cnBvc2UgYnV0IG9ubHkgZm9yIHRoZTxicj4NCiZndDsgc2Vydmlj ZS9jbGllbnQncyBwcml2YWN5IHBvbGljeS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBCVFcsIEkganVz dCBmb3VuZCB0aGF0IGEgbG90IG9mIHRleHQgYXJlIG1vcmUgb3IgbGVzcyB0aGUgZHVwbGljYXRl IG9yPGJyPg0KJmd0OyByZS1zdGF0ZW1lbnQgb2YgWzFdLiBJTUhPLCBpdCBzaG91bGQgdHJ5IHRv IHJlZmVyIHRoZSBvcmlnaW5hbCBkb2N1bWVudDxicj4NCiZndDsgd2hlcmUgcG9zc2libGUgYXMg aXQgaXMgYSByZWZlcmFibGUgc3RhbmRhcmQsIGFuZCBwdXQgWzFdIGluIHRoZTxicj4NCiZndDsg UmVmZXJlbmNlIHNlY3Rpb24gYXMgd2VsbC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBCZXN0LDxicj4N CiZndDs8YnI+DQomZ3Q7IE5hdDxicj4NCiZndDs8YnI+DQomZ3Q7IFsxXSA8YSBocmVmPSJodHRw Oi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLmh0bWwi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0 LXJlZ2lzdHJhdGlvbi0xXzAuaHRtbDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg MjAxNC0wNy0wOCAyMToxMCBHTVQmIzQzOzA5OjAwIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBo cmVmPSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCI+aGFubmVzLnRzY2hvZmVuaWdA Z214Lm5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0 Ij5oYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDsmZ3Q7OjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg SGkgYWxsLDxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgdHdvIGVhcmxpZXIgcmV2 aWV3cyBJIGhhdmUgbm90aWNlZCB0aGF0IHRoZSBwb2xpY3lfdXJpIG1ldGEtZGF0YTxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyBhdHRyaWJ1dGUgaXMgbm90IGNvcnJlY3RseSBzcGVjaWZpZWQuIEkg b2ZmZXJlZCBhIHN1Z2dlc3Rpb24gYW5kIGluIGJvdGg8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg Y2FzZXMgbXkgcmVxdWVzdCB3YXMgaWdub3JlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IE1heWJlIHRoZXJlIGlzIGEgcmVhc29uIHRvIHJlamVjdCBteSByZXF1ZXN0IGJ1dCBJ IGFtIHVuY2VydGFpbiBhYm91dDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB0aGUgcmVsYXRpb25z aGlwIHdpdGggYW5vdGhlciBtZXRhLWRhdGEgYXR0cmlidXRlLCB0aGUgdGVybXMtb2Ytc2Vydmlj ZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBhdHRyaWJ1dGUuPGJyPg0KJmd0Ozxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyBIZXJlIGlzIHdoYXQgSSBzYWlkIGluIG15IGxhc3QgcmV2aWV3Ojxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxMjg3OS5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxMjg3 OS5odG1sPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7PGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7IHBvbGljeV91cmk6IEluIG15IHByZXZpb3VzIHJldmlldyBJIGFy Z3VlZCB0aGF0IHRoZSByaWdodCB0ZXJtaW5vbG9neTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBo ZXJlIGlzIHByaXZhY3kgbm90aWNlIGFuZCB5b3UgY2FuIGV2ZW4gcmUtdXNlIHRoZSBJQVBQIHRl cm1pbm9sb2d5Ljxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBVbmxlc3MgdGhlIHBvbGljeSBVUkkg aGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBwcml2YWN5IEkgd291bGQgcHJlZmVyIHRoaXM8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgdGVybWlub2xvZ3kgY2hhbmdlLiBJZiB5b3UgZGlzYWdyZWUgSSB3 b3VsZCBwcmVmZXIgdG8gaGF2ZSBhPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGRlc2NyaXB0aW9u IGFib3V0IHdoYXQgcG9saWN5IG1lYW5zIGluIHRoaXMgY29udGV4dC48YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBDb3VsZCB5 b3UgZ3V5cyBleHBsYWluPzxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgQ2lhbzxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyBIYW5uZXM8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBPQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAmbmJzcDsgJm5ic3A7 IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4m Z3Q7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0OyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7 IE5hdCBTYWtpbXVyYSAoPW5hdCk8YnI+DQomZ3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlv bjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCiZndDsgQF9uYXRfZW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLSA8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0K PGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov L25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439ADA07A1TK5EX14MBXC294r_-- From nobody Tue Jul 8 12:05:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12841A0250 for ; Tue, 8 Jul 2014 12:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFhHdVIUyLNp for ; Tue, 8 Jul 2014 12:05:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D2E1A0400 for ; Tue, 8 Jul 2014 12:05:09 -0700 (PDT) Received: from BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) by BY2PR03MB620.namprd03.prod.outlook.com (10.255.93.42) with Microsoft SMTP Server (TLS) id 15.0.974.11; Tue, 8 Jul 2014 19:05:00 +0000 Received: from BY2PR03CA048.namprd03.prod.outlook.com (10.141.249.21) by BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) with Microsoft SMTP Server (TLS) id 15.0.969.15; Tue, 8 Jul 2014 19:04:46 +0000 Received: from BY2FFO11FD020.protection.gbl (2a01:111:f400:7c0c::103) by BY2PR03CA048.outlook.office365.com (2a01:111:e400:2c5d::21) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Tue, 8 Jul 2014 19:04:46 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD020.mail.protection.outlook.com (10.1.14.137) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Tue, 8 Jul 2014 19:04:46 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0195.002; Tue, 8 Jul 2014 19:04:37 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri Thread-Index: AQHPmqVztwmu7slI2ES6e+cx7tPPAZuWiUVw Date: Tue, 8 Jul 2014 19:04:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA0841@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53BBDF5B.3020904@gmx.net> In-Reply-To: <53BBDF5B.3020904@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(53754006)(189002)(199002)(377454003)(55885003)(13464003)(164054003)(44976005)(55846006)(77982001)(76482001)(21056001)(85852003)(23726002)(81342001)(46406003)(97736001)(104016002)(54356999)(76176999)(107046002)(50986999)(83072002)(95666004)(79102001)(86612001)(6806004)(87936001)(46102001)(97756001)(33656002)(19580395003)(83322001)(19580405001)(74662001)(69596002)(74502001)(68736004)(31966008)(84676001)(77096002)(92726001)(85306003)(2656002)(92566001)(80022001)(107886001)(26826002)(50466002)(47776003)(106466001)(66066001)(106116001)(81542001)(4396001)(20776003)(99396002)(64706001)(86362001)(81156004); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB272; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0266491E90 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_49n4MKW6UXFT1ohvqJLs8ImOqs Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri 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, 08 Jul 2014 19:05:12 -0000 Was there specific language that had been discussed to be added for this? = If not, could someone please create some? Thanks, -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, July 08, 2014 5:09 AM To: oauth@ietf.org Subject: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri Hi all, in my earlier review I had noted that the semantic of the fields is undersp= ecified, i.e., it is not clear what these fields are used for. In private conversations I was told that an informal reference to a potenti= al use case will be added. I don't see such reference with version -18. Ciao Hannes From nobody Tue Jul 8 12:05:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128551A0538 for ; Tue, 8 Jul 2014 12:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viPGFYuaV4s8 for ; Tue, 8 Jul 2014 12:05:15 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603CC1A052E for ; Tue, 8 Jul 2014 12:05:15 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q107so5430802qgd.41 for ; Tue, 08 Jul 2014 12:05:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=5q7Z7QbceLZc+QM0JQJ+f1llu7YyLJ5UXmPWMcEErk8=; b=aLu42Ya7lDWSwEClkvkdsQVsGHAVeh9wfaOSPJPYSe2AOV2J3zLPMcSOVPcJ/8bXl9 CmhicnCDglEKlUZ+nsOd605rgbN5vQMg98d9BJTi5EHKbqZzo8VFeQf1vPOZKIhI5uZG HKdNFaxq2/lJiv72U6z338QBB8SKRThrkr+pYdQvniw9e42R0udXtOk8QSeh38V4t2NW Ue+nkND/+tw9v6B5laddokWdy7L4Un5ceMUwAcotQxzidcIj40emw61BakR8LfFFrmRt 3hdBICYhZ2S43XhSwIboY+VmXlfjKVFk3PahdvzwuSb2DuTNePPOuHtSzMRYnOa4kyvK zUqQ== X-Gm-Message-State: ALoCoQlgtRsrM+XbctLq98pGL+89S15DjnazJyrI0Um5jOPi2FtxSss3hCewVItbw589oFQXRmwj X-Received: by 10.140.108.99 with SMTP id i90mr60179464qgf.56.1404846314411; Tue, 08 Jul 2014 12:05:14 -0700 (PDT) Received: from [192.168.0.200] ([201.189.83.252]) by mx.google.com with ESMTPSA id d4sm30856855qag.5.2014.07.08.12.05.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 12:05:13 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9174A129-A939-4596-A07A-03EA92ECF607" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA07A1@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Tue, 8 Jul 2014 15:05:32 -0400 Message-Id: <2681D9B8-FE2F-4182-BA27-6C06A427F0AD@ve7jtb.com> References: <53BBDFA0.8010306@gmx.net> <53BBE932.6000808@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA07A1@TK5EX14MBXC294.redmond.corp.microsoft.com> To: Michael Jones X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8O5fgavoT2uP8h3UVAm_GtpVpug Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri 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, 08 Jul 2014 19:05:21 -0000 --Apple-Mail=_9174A129-A939-4596-A07A-03EA92ECF607 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am OK with clarifying the description as privacy/data protection = policy. I don't think it needs privacy in the parameter name. On Jul 8, 2014, at 2:59 PM, Mike Jones = wrote: > I agree with Nat=92s assessment. I=92m fine updating the textual = description of the parameter, but we should not consider breaking = changes to the parameter names at this point. > =20 > Do you have specific wording in mind, Hannes? > =20 > -- Mike > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura > Sent: Tuesday, July 08, 2014 6:26 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri > =20 > I am not against using the term "Privacy Policy" in the description.=20= > Depending on the jurisdiction and language, direct translation of such=20= > can be "Data Protection Policy", "Personal Data Protection Policy", = etc.,=20 > instead so just dodging it by avoiding the label would be more = politically neutral,=20 > but it could be fine after all. =20 > =20 > I am not fine with changing the parameter name though.=20 > Slight variation in the parameter between the specs generally do not = help the developers.=20 > =20 > Nat > =20 >=20 > 2014-07-08 21:50 GMT+09:00 Hannes Tschofenig = : > For example, even Facebook calls this stuff "Privacy Policy URL". >=20 > On 07/08/2014 02:43 PM, Nat Sakimura wrote: > > policy_uri came down from OpenID Connect Dynamic Client Registraiton = 1.0 > > [1]. > > > > It goes: > > > > policy_uri > > OPTIONAL. URL that the Relying Party Client provides to the = End-User > > to read about the how the profile data will be used. The value = of > > this field MUST point to a valid web page. The OpenID Provider > > SHOULD display this URL to the End-User if it is given. If = desired, > > representation of this Claim in different languages and scripts = is > > represented as described in Section 2.1 > > = . > > > > It is clearly privacy related. In fact, it used to be a part of = OpenID > > Connect Core in which the RP had to send it to obtain the = permission. It > > is optional only because in certain enterprise type setting, it is > > unnecessary. In the consumer case, I regard it as essential. In any > > case, this is something a trust framework should set as its rule, = and > > not the protocol itself. > > > > The draft -18 text goes: > > > > policy_uri > > URL that points to a human-readable Policy document for the > > client. The authorization server SHOULD display this URL to = the > > end-user if it is given. The policy usually describes how an = end- > > user's data will be used by the client. The value of this = field > > MUST point to a valid web page. The value of this field MAY = be > > internationalized, as described in Section 2.2 = . > > > > > > It has been converted to be a bit vague. I would +1 to tighten it = up. > > Note that there is tos_uri to describe the Terms of Service by the > > client and poicy_uri is not intended for this purpose but only for = the > > service/client's privacy policy. > > > > BTW, I just found that a lot of text are more or less the duplicate = or > > re-statement of [1]. IMHO, it should try to refer the original = document > > where possible as it is a referable standard, and put [1] in the > > Reference section as well. > > > > Best, > > > > Nat > > > > [1] http://openid.net/specs/openid-connect-registration-1_0.html > > > > > > 2014-07-08 21:10 GMT+09:00 Hannes Tschofenig = > >: > > > > Hi all, > > > > two earlier reviews I have noticed that the policy_uri meta-data > > attribute is not correctly specified. I offered a suggestion and = in both > > cases my request was ignored. > > > > Maybe there is a reason to reject my request but I am uncertain = about > > the relationship with another meta-data attribute, the = terms-of-service > > attribute. > > > > Here is what I said in my last review: > > http://www.ietf.org/mail-archive/web/oauth/current/msg12879.html > > > > " > > policy_uri: In my previous review I argued that the right = terminology > > here is privacy notice and you can even re-use the IAPP = terminology. > > Unless the policy URI has nothing to do with privacy I would = prefer this > > terminology change. If you disagree I would prefer to have a > > description about what policy means in this context. > > " > > > > Could you guys explain? > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en >=20 >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_9174A129-A939-4596-A07A-03EA92ECF607 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I am = OK with clarifying the description as privacy/data protection policy. =   I don't think it needs privacy in the parameter = name.
On Jul 8, 2014, at 2:59 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I agree with Nat=92s assessment.  I=92m fine = updating the textual description of the parameter, but we should not = consider breaking changes to the parameter names at this = point.
 
Do you have specific wording in mind, = Hannes?
 
           &= nbsp;           &nb= sp;            = ;            &= nbsp;           -- = Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org]<= span class=3D"Apple-converted-space"> On Behalf Of Nat = Sakimura
Sent: Tuesday, July 08, 2014 6:26 = AM
To: Hannes = Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic = Client Registration: policy_uri
 
I am not against using the term "Privacy Policy" in the = description. 
Depending on the jurisdiction and language, direct translation = of such 
can = be "Data Protection Policy", "Personal Data Protection Policy", = etc., 
instead so just dodging it by avoiding the label would be more = politically neutral, 
but it could be fine after all. =  
 
I am = not fine with changing the parameter name = though. 
Slight variation in the parameter between the specs generally do = not help the developers. 
 
Nat

 

2014-07-08 21:50 GMT+09:00 Hannes Tschofenig <hannes.tschofenig@gmx.net>:
For example, even Facebook calls this stuff "Privacy = Policy URL".

On 07/08/2014 02:43 PM, Nat Sakimura wrote:
> = policy_uri came down from OpenID Connect Dynamic Client Registraiton = 1.0
> [1].
>
> It goes:
>
> = policy_uri
>     OPTIONAL. URL that the Relying Party = Client provides to the End-User
>     to read about the = how the profile data will be used. The value of
>     = this field MUST point to a valid web page. The OpenID Provider
> =     SHOULD display this URL to the End-User if it is given. If = desired,
>     representation of this Claim in different = languages and scripts is
>     represented as described = in Section 2.1
>
> It is clearly privacy related. In fact, it used to = be a part of OpenID
> Connect Core in which the RP had to send it = to obtain the permission. It
> is optional only because in certain = enterprise type setting, it is
> unnecessary. In the consumer = case, I regard it as essential. In any
> case, this is something a = trust framework should set as its rule, and
> not the protocol = itself.
>
> The draft -18 text goes:
>
> = policy_uri
>       URL that points to a = human-readable Policy document for the
>       = client.  The authorization server SHOULD display this URL to = the
>       end-user if it is given.  The = policy usually describes how an end-
>       user's = data will be used by the client.  The value of this field
> =       MUST point to a valid web page.  The value of = this field MAY be
> =       internationalized, as described in Section 2.2 = <http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18#section= -2.2>.
>
>
> It has been converted to be a bit vague. I = would +1 to tighten it up.
> Note that there is tos_uri to = describe the Terms of Service by the
> client and poicy_uri is not = intended for this purpose but only for the
> service/client's = privacy policy.
>
> BTW, I just found that a lot of text are = more or less the duplicate or
> re-statement of [1]. IMHO, it = should try to refer the original document
> where possible as it = is a referable standard, and put [1] in the
> Reference section as = well.
>
> Best,
>
> Nat
>
> [1] http://openid.net/specs/openid-connect-registration-1_0.html
>
>
> 2014-07-08 21:10 GMT+09:00 Hannes Tschofenig = <hannes.tschofenig@gmx.net
>
>     Hi = all,
>
>     two earlier reviews I have noticed = that the policy_uri meta-data
>     attribute is not = correctly specified. I offered a suggestion and in both
>   =   cases my request was ignored.
>
>     Maybe = there is a reason to reject my request but I am uncertain about
> =     the relationship with another meta-data attribute, the = terms-of-service
>     attribute.
>
>   =   Here is what I said in my last review:
>     http://www.ietf.org/mail-archive/web/oauth/current/msg12879.ht= ml
>
>     "
>     policy_uri: = In my previous review I argued that the right terminology
>   =   here is privacy notice and you can even re-use the IAPP = terminology.
>     Unless the policy URI has nothing to = do with privacy I would prefer this
>     terminology = change. If you disagree I would prefer to have a
>     = description about what policy means in this context.
>   =   "
>
>     Could you guys = explain?
>
>     Ciao
>     = Hannes
>
>
>     = _______________________________________________
>     = OAuth mailing list
> =     OAuth@ietf.org <mailto:OAuth@ietf.org>

>     https://www.ietf.org/mailman/listinfo/oauth
>
>= ;
>
>
> --
> Nat Sakimura (=3Dnat)
> = Chairman, OpenID Foundation
> http://nat.sakimura.org/
> = @_nat_en



 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_9174A129-A939-4596-A07A-03EA92ECF607-- From nobody Tue Jul 8 12:16:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98D91A0400 for ; Tue, 8 Jul 2014 12:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzbHE4Xw56gy for ; Tue, 8 Jul 2014 12:16:28 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03401A0251 for ; Tue, 8 Jul 2014 12:16:27 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s68JGOjS021675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jul 2014 19:16:25 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s68JGNtI015212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2014 19:16:24 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s68JGN6R024747; Tue, 8 Jul 2014 19:16:23 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jul 2014 12:16:23 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: Date: Tue, 8 Jul 2014 12:16:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <453DCBD9-89C5-4BCB-B73B-94CEF842204C@oracle.com> References: <53BBE144.90307@gmx.net> <53BBF0A6.3000801@gmx.net> To: John Bradley X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/QH8Wel0IIZVkhhILq4rLfoWcxi4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 08 Jul 2014 19:16:29 -0000 Does this need to be in the spec? I believe we=92ve already said that = others can add attributes as they need. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 8, 2014, at 11:56 AM, John Bradley wrote: > The application_type is collected as part of current registration by = Google and some other OAuth providers as part of registering redirect = uri. >=20 > The text was cut down to allow more flexibility in OAuth. Connect = requires registration of redirect_uri and is more ridged about it than = OAuth 2. >=20 > Do you think the Connect wording would be appropriate for OAuth? >=20 > John B. >=20 > On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig = wrote: >=20 >> This additional information makes a lot of sense. >>=20 >> As you said in an earlier mail, the attempt to copy text from the = OpenID >> Connect spec failed a bit... >>=20 >> On 07/08/2014 02:49 PM, Nat Sakimura wrote: >>> I suppose authors has imported one of the security feature of OpenID >>> Connect here as well. In the Dynamic Client Registration standard, = which >>> is a bit longer than IETF version. You can see the reason from it:=20= >>>=20 >>> application_type >>> OPTIONAL. Kind of the application. The default, if omitted, is = web. >>> The defined values are native or web. Web Clients using the OAuth >>> Implicit Grant Type MUST only register URLs using the https scheme >>> as redirect_uris; they MUST NOT use localhost as the hostname. >>> Native Clients MUST only register redirect_uris using custom URI >>> schemes or URLs using the http: scheme with localhost as the >>> hostname. Authorization Servers MAY place additional constraints = on >>> Native Clients. Authorization Servers MAY reject Redirection URI >>> values using the http scheme, other than the localhost case for >>> Native Clients. The Authorization Server MUST verify that all the >>> registered redirect_uris conform to these constraints. This = prevents >>> sharing a Client ID across different types of Clients. >>>=20 >>> Regards,=20 >>>=20 >>> Nat >>>=20 >>>=20 >>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig = >> >: >>>=20 >>> Hi all, >>>=20 >>> with version -18 you guys have added a new meta-data attribute, = namely >>> application_type. >>>=20 >>> First, this new attribute is not listed in the IANA consideration >>> section. >>>=20 >>> Second, could you provide a bit of motivation why you need it? = What >>> would the authorization server do with that type of information? = The >>> description is rather short. >>>=20 >>> IMHO there is also no clear boundary between a "native" and "web" = app. >>> Just think about smart phone apps that are developed using = JavaScript. >>> Would this be a web app or a native app? >>>=20 >>> Here is the definition from the draft: >>>=20 >>> application_type >>> OPTIONAL. Kind of the application. The default, if = omitted, is >>> "web". The defined values are "native" or "web". >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>=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 Tue Jul 8 12:33:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481DF1A0305 for ; Tue, 8 Jul 2014 12:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m86RBxo-8AP for ; Tue, 8 Jul 2014 12:33:10 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DFD41A0255 for ; Tue, 8 Jul 2014 12:33:10 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id i50so5556746qgf.40 for ; Tue, 08 Jul 2014 12:33:09 -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=ahQROjdHBStmZ8qvS+oVg+3HCdTJbUYlueZg+D2hHjE=; b=JyUK/vwmCmovk6YtpF1i12eHfuh/nr8Zymlg0pD+9lBFLJ6jhsbZihGe5P9wZmR8TN u09p6u5cLVrzdconrHuYMZ1QK3WRRx2w1LfVAg8x5zib1vtMYFwx+D+WJum8i2Db1SMe 8FRSRWLHXKEy64UwOu5QrVKSde0Jt2e5792zrfoa8JRBZv+YmuvDiUSJGg8r4Veg7pY3 eFT1CRtGs1SoF6dBT26CZvm+7/YuXjyRLtHIo01cTswXBnFr8lDqEBuZFG+V0f4aNWPA jRqoL1AiveAqfDJLJ54gXEjMIePAKtRxCPVI2LJSB2HBsVPbjZYGdyXGp/C1ZKksWMCe ENJQ== X-Gm-Message-State: ALoCoQmte9Z4/Zno737+IPAmitDOq9zshJhwhLS7Pq7Et/XdTYtkghuPtryw+Ct16WMe4W0T8zGE X-Received: by 10.140.108.70 with SMTP id i64mr50206790qgf.113.1404847989293; Tue, 08 Jul 2014 12:33:09 -0700 (PDT) Received: from [192.168.0.200] ([201.189.83.252]) by mx.google.com with ESMTPSA id i8sm21388154qge.12.2014.07.08.12.33.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 12:33:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA0841@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Tue, 8 Jul 2014 15:33:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2CAA155D-E87E-4465-9110-C142D7085A56@ve7jtb.com> References: <53BBDF5B.3020904@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA0841@TK5EX14MBXC294.redmond.corp.microsoft.com> To: Michael Jones X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/xpE1UFPDoBlQh2vVOc_mZt5Yiy8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri 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, 08 Jul 2014 19:33:13 -0000 In Connect these public keys are used to: 1 verify the signature of request objects (Signed Requests), something = not in OAuth yet, and part of what the description calls higher level = protocols. 2 encrypt the responses from the user_info endpoint or id_token (also = not part of OAuth directly at this point) 3 validate requests to the token endpoint authenticated by the JWT = assertion profile I think this is legitimate OAuth use. Whew for the PoP specs: 4 used to encrypt the symmetric proof key in a JWK sent to the client = http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01#pag= e-7=20 5 used to provide a PoP key for the client to the AS as part of = registration rather than passing the JWK on each request to the token = endpoint. So the keys in the JWK can be used a number of ways by the AS. I think we could reference 3 and 4 as examples to be safe. John B. On Jul 8, 2014, at 3:04 PM, Mike Jones = wrote: > Was there specific language that had been discussed to be added for = this? If not, could someone please create some? >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Tuesday, July 08, 2014 5:09 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri >=20 > Hi all, >=20 > in my earlier review I had noted that the semantic of the fields is = underspecified, i.e., it is not clear what these fields are used for. >=20 > In private conversations I was told that an informal reference to a = potential use case will be added. I don't see such reference with = version -18. >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jul 8 12:36:43 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201971A05CB for ; Tue, 8 Jul 2014 12:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDjTGZtUZQPn for ; Tue, 8 Jul 2014 12:36:40 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9A81A0305 for ; Tue, 8 Jul 2014 12:36:40 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so5747429qcw.17 for ; Tue, 08 Jul 2014 12:36:39 -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=ZsPTK/XznbvcYX2mTGheSK0EjOZLe9rzLdFMIJN0RSk=; b=S++xZrWmKZYk+/rn6S+VZLro6OW9AvzOOu4K4/+wxPzjIrb2VMDo+YFEMJNez13FqD quzlgBCrdZWrZXXRkeIxYnMIxfMT4LJqr45y7iFMyD6sSq1MbfhzYeu09veh9CGg8tFp KubM4vDqrRY3ylRJAMtbGNZ8dhJeC4Swi9JzIKCC2ysUWVG/OcBEJge/phYPOIz/WTX7 RIj/9jnq+jML/2ED2hCJdGniOwxsyzFTxK01spw4Bsa0wTlOGvxD+otslJHK3sae00VU t6kyzjzDjcv+JBSQ5GNP90D0R2dCPDKe/hWs076dvHPuxWARaqAhTN2kFSKYVyhfhNTg Z7Ng== X-Gm-Message-State: ALoCoQnojq7qZAVg1JY+IWR1AZXNA7iiKOkETMOM+hta9wf88GLwexdYDPgHsmw/95x3rFzScHnO X-Received: by 10.140.24.243 with SMTP id 106mr2784808qgr.11.1404848199752; Tue, 08 Jul 2014 12:36:39 -0700 (PDT) Received: from [192.168.0.200] ([201.189.83.252]) by mx.google.com with ESMTPSA id s96sm15228232qgs.26.2014.07.08.12.36.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 12:36:37 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <453DCBD9-89C5-4BCB-B73B-94CEF842204C@oracle.com> Date: Tue, 8 Jul 2014 15:37:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <53F6DF2E-5F56-420D-B94B-70D05C4ED0FC@ve7jtb.com> References: <53BBE144.90307@gmx.net> <53BBF0A6.3000801@gmx.net> <453DCBD9-89C5-4BCB-B73B-94CEF842204C@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/INt3k1c3zMfFBEmIS4DY39LhceA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 08 Jul 2014 19:36:42 -0000 It was taken out and then put back in as it is a common parameter used = by a number of AS. We have it in Connect, the best reason for keeping it is to stop people = from coming up with a new parameter for the same thing because they = haven't looked at the Connect version. John B. On Jul 8, 2014, at 3:16 PM, Phil Hunt wrote: > Does this need to be in the spec? I believe we=92ve already said that = others can add attributes as they need. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Jul 8, 2014, at 11:56 AM, John Bradley wrote: >=20 >> The application_type is collected as part of current registration by = Google and some other OAuth providers as part of registering redirect = uri. >>=20 >> The text was cut down to allow more flexibility in OAuth. Connect = requires registration of redirect_uri and is more ridged about it than = OAuth 2. >>=20 >> Do you think the Connect wording would be appropriate for OAuth? >>=20 >> John B. >>=20 >> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig = wrote: >>=20 >>> This additional information makes a lot of sense. >>>=20 >>> As you said in an earlier mail, the attempt to copy text from the = OpenID >>> Connect spec failed a bit... >>>=20 >>> On 07/08/2014 02:49 PM, Nat Sakimura wrote: >>>> I suppose authors has imported one of the security feature of = OpenID >>>> Connect here as well. In the Dynamic Client Registration standard, = which >>>> is a bit longer than IETF version. You can see the reason from it:=20= >>>>=20 >>>> application_type >>>> OPTIONAL. Kind of the application. The default, if omitted, is = web. >>>> The defined values are native or web. Web Clients using the OAuth >>>> Implicit Grant Type MUST only register URLs using the https scheme >>>> as redirect_uris; they MUST NOT use localhost as the hostname. >>>> Native Clients MUST only register redirect_uris using custom URI >>>> schemes or URLs using the http: scheme with localhost as the >>>> hostname. Authorization Servers MAY place additional constraints = on >>>> Native Clients. Authorization Servers MAY reject Redirection URI >>>> values using the http scheme, other than the localhost case for >>>> Native Clients. The Authorization Server MUST verify that all the >>>> registered redirect_uris conform to these constraints. This = prevents >>>> sharing a Client ID across different types of Clients. >>>>=20 >>>> Regards,=20 >>>>=20 >>>> Nat >>>>=20 >>>>=20 >>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig = >>> >: >>>>=20 >>>> Hi all, >>>>=20 >>>> with version -18 you guys have added a new meta-data attribute, = namely >>>> application_type. >>>>=20 >>>> First, this new attribute is not listed in the IANA consideration >>>> section. >>>>=20 >>>> Second, could you provide a bit of motivation why you need it? = What >>>> would the authorization server do with that type of information? = The >>>> description is rather short. >>>>=20 >>>> IMHO there is also no clear boundary between a "native" and "web" = app. >>>> Just think about smart phone apps that are developed using = JavaScript. >>>> Would this be a web app or a native app? >>>>=20 >>>> Here is the definition from the draft: >>>>=20 >>>> application_type >>>> OPTIONAL. Kind of the application. The default, if = omitted, is >>>> "web". The defined values are "native" or "web". >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>=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 From nobody Tue Jul 8 12:44:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502CC1A02F5 for ; Tue, 8 Jul 2014 12:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iqvOiMaqodB for ; Tue, 8 Jul 2014 12:43:58 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C5F1A0255 for ; Tue, 8 Jul 2014 12:43:58 -0700 (PDT) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKU7xJ/gR3tVJMRUwYIjtEoWThgnHzOlJ6@postini.com; Tue, 08 Jul 2014 12:43:58 PDT Received: by mail-ie0-f172.google.com with SMTP id rd18so5385143iec.31 for ; Tue, 08 Jul 2014 12:43:57 -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=N7ry7kenbRQXgqVnVRRAjipWO/StUmayPkB2qY1JYL0=; b=D6U3vkGtKBQsNz/ORHOO+TxD1nDll2PLivDuDxEcKd8r5eyFkZf+LRrDgcJMvjJhC8 ADbOsap4q1QLfKzYNzdpdcaxtJU/y8ONQTl3Ha3+kl1pMc4AebPn0md/5IjX+8ZZFJ+y pc2BpwvaM0ZIfENw9PnPBvulTSR58/gU+J7Q8aia1p5ORRcixVXfYSHsqNx/DPJcTJkQ KgezXvvCLHJMxJYhe1cO8JMhWR81gObYyuGKRsOxP/XSOz/6F1Vwfmqo0cyfjYZhbRXG U8mYHvUz7zdRc1+CYzF87NvtuwQrwD8M+nv8l+8sI1noMdKjX98osXeW1gcRyajdhkPy ojRA== X-Gm-Message-State: ALoCoQlDnacSEBJjNQDclamEyShSDCOJx1gokLxWD0+5dtCQAd5ggbnJz3Oi012DyWq4SkBI28QYIvOI8RTrCOn6KLsonE+bxdrHtcv+yGE5TTCziCe+WGI8Uuya3ZBmGvdzO1hbe3e8 X-Received: by 10.42.154.132 with SMTP id q4mr17301372icw.4.1404848637783; Tue, 08 Jul 2014 12:43:57 -0700 (PDT) X-Received: by 10.42.154.132 with SMTP id q4mr17301359icw.4.1404848637658; Tue, 08 Jul 2014 12:43:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Tue, 8 Jul 2014 12:43:27 -0700 (PDT) In-Reply-To: <2CAA155D-E87E-4465-9110-C142D7085A56@ve7jtb.com> References: <53BBDF5B.3020904@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA0841@TK5EX14MBXC294.redmond.corp.microsoft.com> <2CAA155D-E87E-4465-9110-C142D7085A56@ve7jtb.com> From: Brian Campbell Date: Tue, 8 Jul 2014 12:43:27 -0700 Message-ID: To: John Bradley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/P6QMWsyGNL4DK06RkwOGwt0bvE0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri 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, 08 Jul 2014 19:44:00 -0000 +1 to John's #3. The others could maybe be described in somewhat abstract terms as examples of those "higher level protocols that use signing or encryption." On Tue, Jul 8, 2014 at 12:33 PM, John Bradley wrote: > In Connect these public keys are used to: > 1 verify the signature of request objects (Signed Requests), something not in OAuth yet, and part of what the description calls higher level protocols. > 2 encrypt the responses from the user_info endpoint or id_token (also not part of OAuth directly at this point) > > 3 validate requests to the token endpoint authenticated by the JWT assertion profile I think this is legitimate OAuth use. > > Whew for the PoP specs: > 4 used to encrypt the symmetric proof key in a JWK sent to the client http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01#page-7 > 5 used to provide a PoP key for the client to the AS as part of registration rather than passing the JWK on each request to the token endpoint. > > So the keys in the JWK can be used a number of ways by the AS. > > I think we could reference 3 and 4 as examples to be safe. > > John B. > > > On Jul 8, 2014, at 3:04 PM, Mike Jones wrote: > >> Was there specific language that had been discussed to be added for this? If not, could someone please create some? >> >> Thanks, >> -- Mike >> >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig >> Sent: Tuesday, July 08, 2014 5:09 AM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri >> >> Hi all, >> >> in my earlier review I had noted that the semantic of the fields is underspecified, i.e., it is not clear what these fields are used for. >> >> In private conversations I was told that an informal reference to a potential use case will be added. I don't see such reference with version -18. >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jul 8 13:39:05 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66B71A000F for ; Tue, 8 Jul 2014 13:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_17N3JMGucK for ; Tue, 8 Jul 2014 13:38:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773101A0002 for ; Tue, 8 Jul 2014 13:38:57 -0700 (PDT) Received: from BY2PR03CA030.namprd03.prod.outlook.com (10.242.234.151) by BL2PR03MB337.namprd03.prod.outlook.com (10.141.68.16) with Microsoft SMTP Server (TLS) id 15.0.990.7; Tue, 8 Jul 2014 20:38:55 +0000 Received: from BL2FFO11FD035.protection.gbl (2a01:111:f400:7c09::193) by BY2PR03CA030.outlook.office365.com (2a01:111:e400:2c2c::23) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Tue, 8 Jul 2014 20:38:54 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD035.mail.protection.outlook.com (10.173.161.131) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Tue, 8 Jul 2014 20:38:53 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0195.002; Tue, 8 Jul 2014 20:38:12 +0000 From: Mike Jones To: John Bradley , Phil Hunt Thread-Topic: [OAUTH-WG] Dynamic Client Registration: application_type Thread-Index: AQHPmqsLnQrYoKDhtEOe+Pyl9jU/+puWKhMAgABdNICAAAWXAIAABckAgAAQbkA= Date: Tue, 8 Jul 2014 20:38:11 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA0BA8@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53BBE144.90307@gmx.net> <53BBF0A6.3000801@gmx.net> <453DCBD9-89C5-4BCB-B73B-94CEF842204C@oracle.com> <53F6DF2E-5F56-420D-B94B-70D05C4ED0FC@ve7jtb.com> In-Reply-To: <53F6DF2E-5F56-420D-B94B-70D05C4ED0FC@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADA0BA8TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(189002)(199002)(24454002)(55885003)(53754006)(13464003)(377454003)(479174003)(51704005)(377424004)(83072002)(95666004)(85852003)(19625215002)(80022001)(26826002)(92566001)(81156004)(85306003)(15202345003)(20776003)(106116001)(104016002)(15974865002)(66066001)(2656002)(71186001)(87936001)(106466001)(31966008)(76176999)(54356999)(107046002)(77096002)(21056001)(92726001)(74662001)(74502001)(99396002)(50986999)(16601075003)(19580405001)(77982001)(86362001)(76482001)(84676001)(69596002)(4396001)(46102001)(97736001)(6806004)(79102001)(44976005)(15975445006)(68736004)(84326002)(83322001)(19580395003)(81342001)(86612001)(33656002)(64706001)(16236675004)(512954002)(55846006)(19300405004)(81542001)(93886003); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB337; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0266491E90 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/VCH5hwCsUgSIFiT0V0uEbAeKVxA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 08 Jul 2014 20:39:02 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADA0BA8TK5EX14MBXC294r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I put it back because otherwise, we wouldn't be meeting one of the requirem= ents of the RFC 6749. If you look at the client registration section http:= //tools.ietf.org/html/rfc6749#section-2, you'll see that registering redire= ct_uri values is required, as is registering the client type. Without this= , there wasn't a way to register the client type. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley Sent: Tuesday, July 08, 2014 12:37 PM To: Phil Hunt Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type It was taken out and then put back in as it is a common parameter used by a= number of AS. We have it in Connect, the best reason for keeping it is to stop people fro= m coming up with a new parameter for the same thing because they haven't lo= oked at the Connect version. John B. On Jul 8, 2014, at 3:16 PM, Phil Hunt > wrote: > Does this need to be in the spec? I believe we've already said that othe= rs can add attributes as they need. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jul 8, 2014, at 11:56 AM, John Bradley > wrote: > >> The application_type is collected as part of current registration by Goo= gle and some other OAuth providers as part of registering redirect uri. >> >> The text was cut down to allow more flexibility in OAuth. Connect requi= res registration of redirect_uri and is more ridged about it than OAuth 2. >> >> Do you think the Connect wording would be appropriate for OAuth? >> >> John B. >> >> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig > wrote: >> >>> This additional information makes a lot of sense. >>> >>> As you said in an earlier mail, the attempt to copy text from the >>> OpenID Connect spec failed a bit... >>> >>> On 07/08/2014 02:49 PM, Nat Sakimura wrote: >>>> I suppose authors has imported one of the security feature of >>>> OpenID Connect here as well. In the Dynamic Client Registration >>>> standard, which is a bit longer than IETF version. You can see the rea= son from it: >>>> >>>> application_type >>>> OPTIONAL. Kind of the application. The default, if omitted, is web. >>>> The defined values are native or web. Web Clients using the OAuth >>>> Implicit Grant Type MUST only register URLs using the https scheme >>>> as redirect_uris; they MUST NOT use localhost as the hostname. >>>> Native Clients MUST only register redirect_uris using custom URI >>>> schemes or URLs using the http: scheme with localhost as the >>>> hostname. Authorization Servers MAY place additional constraints on >>>> Native Clients. Authorization Servers MAY reject Redirection URI >>>> values using the http scheme, other than the localhost case for >>>> Native Clients. The Authorization Server MUST verify that all the >>>> registered redirect_uris conform to these constraints. This >>>> prevents sharing a Client ID across different types of Clients. >>>> >>>> Regards, >>>> >>>> Nat >>>> >>>> >>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig >>>> >>> >: >>>> >>>> Hi all, >>>> >>>> with version -18 you guys have added a new meta-data attribute, >>>> namely application_type. >>>> >>>> First, this new attribute is not listed in the IANA consideration >>>> section. >>>> >>>> Second, could you provide a bit of motivation why you need it? >>>> What would the authorization server do with that type of >>>> information? The description is rather short. >>>> >>>> IMHO there is also no clear boundary between a "native" and "web" app= . >>>> Just think about smart phone apps that are developed using JavaScript= . >>>> Would this be a web app or a native app? >>>> >>>> Here is the definition from the draft: >>>> >>>> application_type >>>> OPTIONAL. Kind of the application. The default, if omitted, i= s >>>> "web". The defined values are "native" or "web". >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739439ADA0BA8TK5EX14MBXC294r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I put it back becau= se otherwise, we wouldn't be meeting one of the requirements of the RFC 674= 9.  If you look at the client registration section http://tools.ietf.= org/html/rfc6749#section-2, you’ll see that registering redirect_= uri values is required, as is registering the client type.  Without th= is, there wasn’t a way to register the client type.

 

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

 

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, July 08, 2014 12:37 PM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type

 

It was taken out and then put back in as it is a = common parameter used by a number of AS.

 

We have it in Connect, the best reason for keepin= g it is to stop people from coming up with a new parameter for the same thi= ng because they haven't looked at the Connect version.

 

John B.

On Jul 8, 2014, at 3:16 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

> Does this need to be in the spec?  I be= lieve we’ve already said that others can add attributes as they need.=

>

> Phil

>

> @independentid

> www.independentid.com

> phil.hunt@oracle.com

>

>

>

> On Jul 8, 2014, at 11:56 AM, John Bradley &l= t;ve7jtb@ve7jtb.com> wrote:

>

>> The application_type is collected as par= t of current registration by Google and some other OAuth providers as part = of registering redirect uri.

>>

>> The text was cut down to allow more flex= ibility in OAuth.  Connect requires registration of redirect_uri and i= s more ridged about it than OAuth 2.

>>

>> Do you think the Connect wording would b= e appropriate for OAuth?

>>

>> John B.

>>

>> On Jul 8, 2014, at 9:22 AM, Hannes Tscho= fenig <hannes.tschofenig@gmx.net> = wrote:

>>

>>> This additional information makes a = lot of sense.

>>>

>>> As you said in an earlier mail, the = attempt to copy text from the

>>> OpenID Connect spec failed a bit...<= o:p>

>>>

>>> On 07/08/2014 02:49 PM, Nat Sakimura= wrote:

>>>> I suppose authors has imported o= ne of the security feature of

>>>> OpenID Connect here as well. In = the Dynamic Client Registration

>>>> standard, which is a bit longer = than IETF version. You can see the reason from it:

>>>>

>>>> application_type

>>>>  OPTIONAL. Kind of the appl= ication. The default, if omitted, is web.

>>>>  The defined values are nat= ive or web. Web Clients using the OAuth 

>>>> Implicit Grant Type MUST only re= gister URLs using the https scheme 

>>>> as redirect_uris; they MUST NOT = use localhost as the hostname.

>>>>  Native Clients MUST only r= egister redirect_uris using custom URI 

>>>> schemes or URLs using the http: = scheme with localhost as the 

>>>> hostname. Authorization Servers = MAY place additional constraints on 

>>>> Native Clients. Authorization Se= rvers MAY reject Redirection URI 

>>>> values using the http scheme, ot= her than the localhost case for 

>>>> Native Clients. The Authorizatio= n Server MUST verify that all the 

>>>> registered redirect_uris conform= to these constraints. This

>>>> prevents  sharing a Client = ID across different types of Clients.

>>>>

>>>> Regards,

>>>>

>>>> Nat

>>>>

>>>>

>>>> 2014-07-08 21:17 GMT+09:00 H= annes Tschofenig

>>>> <hannes.tschofenig@gmx.net

>>>> <mail= to:hannes.tschofenig@gmx.net>>:

>>>>

>>>>  Hi all,

>>>>

>>>>  with version -18 you guys = have added a new meta-data attribute,

>>>> namely  application_type.

>>>>

>>>>  First, this new attribute = is not listed in the IANA consideration 

>>>> section.

>>>>

>>>>  Second, could you provide = a bit of motivation why you need it?

>>>> What  would the authorizati= on server do with that type of

>>>> information? The  descripti= on is rather short.

>>>>

>>>>  IMHO there is also no clea= r boundary between a "native" and "web" app.=

>>>>  Just think about smart pho= ne apps that are developed using JavaScript.

>>>>  Would this be a web app or= a native app?

>>>>

>>>>  Here is the definition fro= m the draft:

>>>>

>>>>  application_type

>>>>     &nb= sp;  OPTIONAL.  Kind of the application.  The default, if om= itted, is

>>>>     &nb= sp;  "web".  The defined values are "native" = or "web".

>>>>

>>>>  Ciao

>>>>  Hannes

>>>>

>>>>

>>>>  __________________________= _____________________

>>>>  OAuth mailing list

>>>>  OAuth@ietf.or= g <mailto:OAuth@ietf.org> 

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

>>>>

>>>>

>>>>

>>>>

>>>> --

>>>> Nat Sakimura (=3Dnat)=

>>>> Chairman, OpenID Foundation=

>>>> http://nat.sakim= ura.org/

>>>> @_nat_en

>>>

>>> ____________________________________= ___________

>>> 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.ie= tf.org/mailman/listinfo/oauth

--_000_4E1F6AAD24975D4BA5B16804296739439ADA0BA8TK5EX14MBXC294r_-- From nobody Tue Jul 8 13:44:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320881A000F for ; Tue, 8 Jul 2014 13:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtEk48niih0f for ; Tue, 8 Jul 2014 13:44:05 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14F41A0002 for ; Tue, 8 Jul 2014 13:44:04 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s68Ki3N6026263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jul 2014 20:44:04 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s68Ki2Hf010536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Jul 2014 20:44:02 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s68Ki1f0010491; Tue, 8 Jul 2014 20:44:02 GMT Received: from [25.70.79.150] (/24.114.42.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jul 2014 13:44:01 -0700 References: <53BBE144.90307@gmx.net> <53BBF0A6.3000801@gmx.net> <453DCBD9-89C5-4BCB-B73B-94CEF842204C@oracle.com> <53F6DF2E-5F56-420D-B94B-70D05C4ED0FC@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADA0BA8@TK5EX14MBXC294.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA0BA8@TK5EX14MBXC294.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary=Apple-Mail-365EC87E-F3DF-45D9-81B1-15B183E120A5 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Tue, 8 Jul 2014 13:43:55 -0700 To: Mike Jones X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/diLdRmAh9jfNgYMPBfpqYyj2O6A Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 08 Jul 2014 20:44:08 -0000 --Apple-Mail-365EC87E-F3DF-45D9-81B1-15B183E120A5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok.=20 Phil > On Jul 8, 2014, at 13:38, Mike Jones wrote: >=20 > I put it back because otherwise, we wouldn't be meeting one of the require= ments of the RFC 6749. If you look at the client registration section http:= //tools.ietf.org/html/rfc6749#section-2, you=E2=80=99ll see that registering= redirect_uri values is required, as is registering the client type. Withou= t this, there wasn=E2=80=99t a way to register the client type. > =20 > -- Mike > =20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Tuesday, July 08, 2014 12:37 PM > To: Phil Hunt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type > =20 > It was taken out and then put back in as it is a common parameter used by a= number of AS. > =20 > We have it in Connect, the best reason for keeping it is to stop people fr= om coming up with a new parameter for the same thing because they haven't lo= oked at the Connect version. > =20 > John B. > On Jul 8, 2014, at 3:16 PM, Phil Hunt wrote: > =20 > > Does this need to be in the spec? I believe we=E2=80=99ve already said t= hat others can add attributes as they need. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > On Jul 8, 2014, at 11:56 AM, John Bradley wrote: > > > >> The application_type is collected as part of current registration by Go= ogle and some other OAuth providers as part of registering redirect uri. > >> > >> The text was cut down to allow more flexibility in OAuth. Connect requ= ires registration of redirect_uri and is more ridged about it than OAuth 2. > >> > >> Do you think the Connect wording would be appropriate for OAuth? > >> > >> John B. > >> > >> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig wrote: > >> > >>> This additional information makes a lot of sense. > >>> > >>> As you said in an earlier mail, the attempt to copy text from the > >>> OpenID Connect spec failed a bit... > >>> > >>> On 07/08/2014 02:49 PM, Nat Sakimura wrote: > >>>> I suppose authors has imported one of the security feature of > >>>> OpenID Connect here as well. In the Dynamic Client Registration > >>>> standard, which is a bit longer than IETF version. You can see the re= ason from it: > >>>> > >>>> application_type > >>>> OPTIONAL. Kind of the application. The default, if omitted, is web. > >>>> The defined values are native or web. Web Clients using the OAuth=20= > >>>> Implicit Grant Type MUST only register URLs using the https scheme=20= > >>>> as redirect_uris; they MUST NOT use localhost as the hostname. > >>>> Native Clients MUST only register redirect_uris using custom URI=20 > >>>> schemes or URLs using the http: scheme with localhost as the=20 > >>>> hostname. Authorization Servers MAY place additional constraints on=20= > >>>> Native Clients. Authorization Servers MAY reject Redirection URI=20 > >>>> values using the http scheme, other than the localhost case for=20 > >>>> Native Clients. The Authorization Server MUST verify that all the=20 > >>>> registered redirect_uris conform to these constraints. This > >>>> prevents sharing a Client ID across different types of Clients. > >>>> > >>>> Regards, > >>>> > >>>> Nat > >>>> > >>>> > >>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig > >>>> >>>> >: > >>>> > >>>> Hi all, > >>>> > >>>> with version -18 you guys have added a new meta-data attribute, > >>>> namely application_type. > >>>> > >>>> First, this new attribute is not listed in the IANA consideration=20= > >>>> section. > >>>> > >>>> Second, could you provide a bit of motivation why you need it? > >>>> What would the authorization server do with that type of > >>>> information? The description is rather short. > >>>> > >>>> IMHO there is also no clear boundary between a "native" and "web" ap= p. > >>>> Just think about smart phone apps that are developed using JavaScrip= t. > >>>> Would this be a web app or a native app? > >>>> > >>>> Here is the definition from the draft: > >>>> > >>>> application_type > >>>> OPTIONAL. Kind of the application. The default, if omitted, i= s > >>>> "web". The defined values are "native" or "web". > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org =20 > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Nat Sakimura (=3Dnat) > >>>> Chairman, OpenID Foundation > >>>> http://nat.sakimura.org/ > >>>> @_nat_en > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-365EC87E-F3DF-45D9-81B1-15B183E120A5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ok. 

Phil

On= Jul 8, 2014, at 13:38, Mike Jones <Michael.Jones@microsoft.com> wrote:

=

I put it back becaus= e otherwise, we wouldn't be meeting one of the requirements of the RFC 6749.=   If you look at the client registration section http://tools.ietf.o= rg/html/rfc6749#section-2, you=E2=80=99ll see that registering redirect_= uri values is required, as is registering the client type.  Without thi= s, there wasn=E2=80=99t a way to register the client type.

 

   &n= bsp;            =             &nbs= p;            &n= bsp;            =       -- Mike

 

-----Original Message-----
From: OAuth [mailto:oauth-bounces@= ietf.org] On Behalf Of John Bradley
Sent: Tuesday, July 08, 2014 12:37 PM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type

 

It was taken out and then put back in as it is a c= ommon parameter used by a number of AS.

 

We have it in Connect, the best reason for keeping= it is to stop people from coming up with a new parameter for the same thing= because they haven't looked at the Connect version.

 

John B.

On Jul 8, 2014, at 3:16 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

> Does this need to be in the spec?  I bel= ieve we=E2=80=99ve already said that others can add attributes as they need.=

>

> Phil

>

> @independentid

> www.independentid.com

> phil.hunt@oracle.com=

>

>

>

> On Jul 8, 2014, at 11:56 AM, John Bradley <= ;ve7jtb@ve7jtb.com> wrote:

>

>> The application_type is collected as part= of current registration by Google and some other OAuth providers as part of= registering redirect uri.

>>

>> The text was cut down to allow more flexi= bility in OAuth.  Connect requires registration of redirect_uri and is m= ore ridged about it than OAuth 2.

>>

>> Do you think the Connect wording would be= appropriate for OAuth?

>>

>> John B.

>>

>> On Jul 8, 2014, at 9:22 AM, Hannes Tschof= enig <hannes.tschofenig@gmx.net> wro= te:

>>

>>> This additional information makes a l= ot of sense.

>>>

>>> As you said in an earlier mail, the a= ttempt to copy text from the

>>> OpenID Connect spec failed a bit...

>>>

>>> On 07/08/2014 02:49 PM, Nat Sakimura w= rote:

>>>> I suppose authors has imported on= e of the security feature of

>>>> OpenID Connect here as well. In t= he Dynamic Client Registration

>>>> standard, which is a bit longer t= han IETF version. You can see the reason from it:

>>>>

>>>> application_type

>>>>  OPTIONAL. Kind of the appli= cation. The default, if omitted, is web.

>>>>  The defined values are nati= ve or web. Web Clients using the OAuth 

>>>> Implicit Grant Type MUST only reg= ister URLs using the https scheme 

>>>> as redirect_uris; they MUST NOT u= se localhost as the hostname.

>>>>  Native Clients MUST only re= gister redirect_uris using custom URI 

>>>> schemes or URLs using the http: s= cheme with localhost as the 

>>>> hostname. Authorization Servers M= AY place additional constraints on 

>>>> Native Clients. Authorization Ser= vers MAY reject Redirection URI 

>>>> values using the http scheme, oth= er than the localhost case for 

>>>> Native Clients. The Authorization= Server MUST verify that all the 

>>>> registered redirect_uris conform t= o these constraints. This

>>>> prevents  sharing a Client I= D across different types of Clients.

>>>>

>>>> Regards,

>>>>

>>>> Nat

>>>>

>>>>

>>>> 2014-07-08 21:17 GMT+09:00 Hannes= Tschofenig

>>>> <hannes.tschofenig@gmx.net

>>>> <mailto= :hannes.tschofenig@gmx.net>>:

>>>>

>>>>  Hi all,

>>>>

>>>>  with version -18 you guys h= ave added a new meta-data attribute,

>>>> namely  application_type.

>>>>

>>>>  First, this new attribute i= s not listed in the IANA consideration 

>>>> section.

>>>>

>>>>  Second, could you provide a= bit of motivation why you need it?

>>>> What  would the authorizatio= n server do with that type of

>>>> information? The  descriptio= n is rather short.

>>>>

>>>>  IMHO there is also no clear= boundary between a "native" and "web" app.

>>>>  Just think about smart phon= e apps that are developed using JavaScript.

>>>>  Would this be a web app or a= native app?

>>>>

>>>>  Here is the definition from= the draft:

>>>>

>>>>  application_type=

>>>>     &nbs= p;  OPTIONAL.  Kind of the application.  The default, if omit= ted, is

>>>>     &nbs= p;  "web".  The defined values are "native" or "web".

>>>>

>>>>  Ciao

>>>>  Hannes

>>>>

>>>>

>>>>  ___________________________= ____________________

>>>>  OAuth mailing list

>>>>  OAuth@ietf.org<= /span> <mailto:OAuth@ietf.org> 

>>>> https://www.ietf.org/m= ailman/listinfo/oauth

>>>>

>>>>

>>>>

>>>>

>>>> --

>>>> Nat Sakimura (=3Dnat)<= /p>

>>>> Chairman, OpenID Foundation<= /o:p>

>>>> http://nat.sakimur= a.org/

>>>> @_nat_en

>>>

>>> _____________________________________= __________

>>> OAuth mailing list

>>> OAuth@ietf.org=

>>> https://www.ietf.org/m= ailman/listinfo/oauth

>>

>> _________________________________________= ______

>> OAuth mailing list

>> OAuth@ietf.org

>> https://www.ietf.org/m= ailman/listinfo/oauth

>

 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

= --Apple-Mail-365EC87E-F3DF-45D9-81B1-15B183E120A5-- From nobody Tue Jul 8 15:54:10 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3517A1A016F for ; Tue, 8 Jul 2014 15:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 No1P0cr2fNkF for ; Tue, 8 Jul 2014 15:54:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB091A0176 for ; Tue, 8 Jul 2014 15:54:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 806351F042B; Tue, 8 Jul 2014 18:54:03 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5FEFB1F03BB; Tue, 8 Jul 2014 18:54:03 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.118]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Tue, 8 Jul 2014 18:54:03 -0400 From: "Richer, Justin P." To: Mike Jones Thread-Topic: [OAUTH-WG] Dynamic Client Registration: application_type Thread-Index: AQHPmqsISlJhoAzG1kOzzUWGRyN2OpuWbSEAgABdNICAAAWYAIAABcgAgAARFICAACXzgA== Date: Tue, 8 Jul 2014 22:54:02 +0000 Message-ID: <09F7FAD7-5EEC-4A22-84C8-2823D3AC0D2F@mitre.org> References: <53BBE144.90307@gmx.net> <53BBF0A6.3000801@gmx.net> <453DCBD9-89C5-4BCB-B73B-94CEF842204C@oracle.com> <53F6DF2E-5F56-420D-B94B-70D05C4ED0FC@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADA0BA8@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA0BA8@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.34.95] Content-Type: multipart/alternative; boundary="_000_09F7FAD75EEC4A2284C82823D3AC0D2Fmitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/x4ev3BuQ2p5I_dy0TPNV0ial-nQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 08 Jul 2014 22:54:08 -0000 --_000_09F7FAD75EEC4A2284C82823D3AC0D2Fmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This value was introduced in -18, and it's a direct port from OpenID Connec= t. It was never in the OAuth Dynamic Registration spec, and though it has b= een in the OpenID Connect Dynamic Registration spec for a very long time, I= think it was a mistake to add it in for several reasons: First, the semantics around its values and use are not clearly defined, for= the reasons . I don't see any particular harm in keeping it, but I don't r= eally see what value it adds for clients or server developers. We are in a = world where there are OAuth clients that are much more than just "native" o= r "web". Second, RFC6749 defines "Client Type" in =A7 2.1 which defines two values: = "confidential" and "public", neither of which maps very cleanly to "native"= or "web" as stated in -18. This is especially true when you've got dynamic= registration that can make native clients confidential with relative ease.= We actually take care of registering the "client type" through the use of = the "token_endpoint_auth_method" parameter, which is what =A7 2.1 is really= talking about: secure client authentication (to the token endpoint). With this in mind, my preference and suggestion would be to remove this fie= ld. If other protocols need it, they can register and define it (like Conne= ct has done). -- Justin On Jul 8, 2014, at 4:38 PM, Mike Jones > wrote: I put it back because otherwise, we wouldn't be meeting one of the requirem= ents of the RFC 6749. If you look at the client registration section http:= //tools.ietf.org/html/rfc6749#section-2, you=92ll see that registering redi= rect_uri values is required, as is registering the client type. Without th= is, there wasn=92t a way to register the client type. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley Sent: Tuesday, July 08, 2014 12:37 PM To: Phil Hunt Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type It was taken out and then put back in as it is a common parameter used by a= number of AS. We have it in Connect, the best reason for keeping it is to stop people fro= m coming up with a new parameter for the same thing because they haven't lo= oked at the Connect version. John B. On Jul 8, 2014, at 3:16 PM, Phil Hunt > wrote: > Does this need to be in the spec? I believe we=92ve already said that ot= hers can add attributes as they need. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jul 8, 2014, at 11:56 AM, John Bradley > wrote: > >> The application_type is collected as part of current registration by Goo= gle and some other OAuth providers as part of registering redirect uri. >> >> The text was cut down to allow more flexibility in OAuth. Connect requi= res registration of redirect_uri and is more ridged about it than OAuth 2. >> >> Do you think the Connect wording would be appropriate for OAuth? >> >> John B. >> >> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig > wrote: >> >>> This additional information makes a lot of sense. >>> >>> As you said in an earlier mail, the attempt to copy text from the >>> OpenID Connect spec failed a bit... >>> >>> On 07/08/2014 02:49 PM, Nat Sakimura wrote: >>>> I suppose authors has imported one of the security feature of >>>> OpenID Connect here as well. In the Dynamic Client Registration >>>> standard, which is a bit longer than IETF version. You can see the rea= son from it: >>>> >>>> application_type >>>> OPTIONAL. Kind of the application. The default, if omitted, is web. >>>> The defined values are native or web. Web Clients using the OAuth >>>> Implicit Grant Type MUST only register URLs using the https scheme >>>> as redirect_uris; they MUST NOT use localhost as the hostname. >>>> Native Clients MUST only register redirect_uris using custom URI >>>> schemes or URLs using the http: scheme with localhost as the >>>> hostname. Authorization Servers MAY place additional constraints on >>>> Native Clients. Authorization Servers MAY reject Redirection URI >>>> values using the http scheme, other than the localhost case for >>>> Native Clients. The Authorization Server MUST verify that all the >>>> registered redirect_uris conform to these constraints. This >>>> prevents sharing a Client ID across different types of Clients. >>>> >>>> Regards, >>>> >>>> Nat >>>> >>>> >>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig >>>> >>>> >: >>>> >>>> Hi all, >>>> >>>> with version -18 you guys have added a new meta-data attribute, >>>> namely application_type. >>>> >>>> First, this new attribute is not listed in the IANA consideration >>>> section. >>>> >>>> Second, could you provide a bit of motivation why you need it? >>>> What would the authorization server do with that type of >>>> information? The description is rather short. >>>> >>>> IMHO there is also no clear boundary between a "native" and "web" app= . >>>> Just think about smart phone apps that are developed using JavaScript= . >>>> Would this be a web app or a native app? >>>> >>>> Here is the definition from the draft: >>>> >>>> application_type >>>> OPTIONAL. Kind of the application. The default, if omitted, i= s >>>> "web". The defined values are "native" or "web". >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_09F7FAD75EEC4A2284C82823D3AC0D2Fmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <10DAC84C623FAD4F8EF93636FDB6AFF9@imc.mitre.org> Content-Transfer-Encoding: quoted-printable This value was introduced in -18, and it's a direct port from OpenID Connec= t. It was never in the OAuth Dynamic Registration spec, and though it has b= een in the OpenID Connect Dynamic Registration spec for a very long time, I= think it was a mistake to add it in for several reasons: 

First, the semantics around its values and use are not clearly defined= , for the reasons . I don't see any particular harm in keeping it, but I do= n't really see what value it adds for clients or server developers. We are = in a world where there are OAuth clients that are much more than just "native" or "web"= .

Second, RFC6749 defines "Client Type" in =A7 2.1 which defin= es two values: "confidential" and "public", neither of = which maps very cleanly to "native" or "web" as stated = in -18. This is especially true when you've got dynamic registration that c= an make native clients confidential with relative ease. We actually take care of register= ing the "client type" through the use of the "token_endpoint= _auth_method" parameter, which is what =A7 2.1 is really talking about= : secure client authentication (to the token endpoint). 

With this in mind, my preference and suggestion would be to remove thi= s field. If other protocols need it, they can register and define it (like = Connect has done).

 -- Justin


On Jul 8, 2014, at 4:38 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I put it back becau= se otherwise, we wouldn't be meeting one of the requirements of the RFC 674= 9.  If you look at the client registration section http://tools.ietf.= org/html/rfc6749#section-2, you=92ll see that registering redirect_uri = values is required, as is registering the client type.  Without this, = there wasn=92t a way to register the client type.

 

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

 

-----Original Message-----
From: OAuth [mailto:oauth-bounces= @ietf.org] On Behalf Of John Bradley
Sent: Tuesday, July 08, 2014 12:37 PM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type

 

It was taken out and then put back in as it is a = common parameter used by a number of AS.

 

We have it in Connect, the best reason for keepin= g it is to stop people from coming up with a new parameter for the same thi= ng because they haven't looked at the Connect version.

 

John B.

On Jul 8, 2014, at 3:16 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

> Does this need to be in the spec?  I be= lieve we=92ve already said that others can add attributes as they need.

>

> Phil

>

> @independentid

> www.independentid.com

> phil.hunt@oracle.com

>

>

>

> On Jul 8, 2014, at 11:56 AM, John Bradley &l= t;ve7jtb@ve7jtb.com> wrote:

>

>> The application_type is collected as par= t of current registration by Google and some other OAuth providers as part = of registering redirect uri.

>>

>> The text was cut down to allow more flex= ibility in OAuth.  Connect requires registration of redirect_uri and i= s more ridged about it than OAuth 2.

>>

>> Do you think the Connect wording would b= e appropriate for OAuth?

>>

>> John B.

>>

>> On Jul 8, 2014, at 9:22 AM, Hannes Tscho= fenig <hannes.tschofenig@gmx.net> = wrote:

>>

>>> This additional information makes a = lot of sense.

>>>

>>> As you said in an earlier mail, the = attempt to copy text from the

>>> OpenID Connect spec failed a bit...<= o:p>

>>>

>>> On 07/08/2014 02:49 PM, Nat Sakimura= wrote:

>>>> I suppose authors has imported o= ne of the security feature of

>>>> OpenID Connect here as well. In = the Dynamic Client Registration

>>>> standard, which is a bit longer = than IETF version. You can see the reason from it:

>>>>

>>>> application_type

>>>>  OPTIONAL. Kind of the appl= ication. The default, if omitted, is web.

>>>>  The defined values are nat= ive or web. Web Clients using the OAuth 

>>>> Implicit Grant Type MUST only re= gister URLs using the https scheme 

>>>> as redirect_uris; they MUST NOT = use localhost as the hostname.

>>>>  Native Clients MUST only r= egister redirect_uris using custom URI 

>>>> schemes or URLs using the http: = scheme with localhost as the 

>>>> hostname. Authorization Servers = MAY place additional constraints on 

>>>> Native Clients. Authorization Se= rvers MAY reject Redirection URI 

>>>> values using the http scheme, ot= her than the localhost case for 

>>>> Native Clients. The Authorizatio= n Server MUST verify that all the 

>>>> registered redirect_uris conform= to these constraints. This

>>>> prevents  sharing a Client = ID across different types of Clients.

>>>>

>>>> Regards,

>>>>

>>>> Nat

>>>>

>>>>

>>>> 2014-07-08 21:17 GMT+09:00 H= annes Tschofenig

>>>> <hannes.tschofenig@gmx.net

>>>> <mail= to:hannes.tschofenig@gmx.net>>:

>>>>

>>>>  Hi all,

>>>>

>>>>  with version -18 you guys = have added a new meta-data attribute,

>>>> namely  application_type.

>>>>

>>>>  First, this new attribute = is not listed in the IANA consideration 

>>>> section.

>>>>

>>>>  Second, could you provide = a bit of motivation why you need it?

>>>> What  would the authorizati= on server do with that type of

>>>> information? The  descripti= on is rather short.

>>>>

>>>>  IMHO there is also no clea= r boundary between a "native" and "web" app.=

>>>>  Just think about smart pho= ne apps that are developed using JavaScript.

>>>>  Would this be a web app or= a native app?

>>>>

>>>>  Here is the definition fro= m the draft:

>>>>

>>>>  application_type

>>>>     &nb= sp;  OPTIONAL.  Kind of the application.  The default, if om= itted, is

>>>>     &nb= sp;  "web".  The defined values are "native" = or "web".

>>>>

>>>>  Ciao

>>>>  Hannes

>>>>

>>>>

>>>>  __________________________= _____________________

>>>>  OAuth mailing list

>>>>  OAuth@ietf.or= g <mailto:OAuth@ietf.org> 

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

>>>>

>>>>

>>>>

>>>>

>>>> --

>>>> Nat Sakimura (=3Dnat)=

>>>> Chairman, OpenID Foundation=

>>>> http://nat.sakim= ura.org/

>>>> @_nat_en

>>>

>>> ____________________________________= ___________

>>> 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.ie= tf.org/mailman/listinfo/oauth

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

--_000_09F7FAD75EEC4A2284C82823D3AC0D2Fmitreorg_-- From nobody Tue Jul 8 17:54:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1F91A01CA for ; Tue, 8 Jul 2014 17:54:10 -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 R6DNm6uZLrUU for ; Tue, 8 Jul 2014 17:54:06 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167111A01C8 for ; Tue, 8 Jul 2014 17:54:05 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id el20so4452504lab.7 for ; Tue, 08 Jul 2014 17:54:04 -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=7+DmGxnEkuyBnmoF6ZN6qkggyxYZT0g1MZYFZcRrUbU=; b=BdPLj8MyOhBcUZo2FvVAQC5vXWVu0yNQxRZRi1zTQAfLqguIUzB84bUhS2vOMqCMSC +d3ucfrw7pfNDh7NJUbl25qhe1xQyDRNvpmDkeesyQSPVGayvhdFs+fKF1Srs6f9f6lB EYoWrbEMZpsb1JXywgFtLCyFJjWwMhBSwYaWRhlHHXhJmGOnDnGFigNV+MzIKHT5SzmE FXEklmMw8CVhFrxWU4D6yrbZeMs6xirXXVctbLlE820R3kCkJyR24ynMQJpe/9GxclbQ 0OPNTDcTdKdZfCbPkBBjMAQhJicEiybvHerbXo3N8gfY9VK8zj8PmQwDqwJOsFejZ2Lg WlXw== MIME-Version: 1.0 X-Received: by 10.152.120.195 with SMTP id le3mr30223276lab.16.1404867244183; Tue, 08 Jul 2014 17:54:04 -0700 (PDT) Received: by 10.112.23.33 with HTTP; Tue, 8 Jul 2014 17:54:04 -0700 (PDT) In-Reply-To: <09F7FAD7-5EEC-4A22-84C8-2823D3AC0D2F@mitre.org> References: <53BBE144.90307@gmx.net> <53BBF0A6.3000801@gmx.net> <453DCBD9-89C5-4BCB-B73B-94CEF842204C@oracle.com> <53F6DF2E-5F56-420D-B94B-70D05C4ED0FC@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADA0BA8@TK5EX14MBXC294.redmond.corp.microsoft.com> <09F7FAD7-5EEC-4A22-84C8-2823D3AC0D2F@mitre.org> Date: Wed, 9 Jul 2014 09:54:04 +0900 Message-ID: From: Nat Sakimura To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=089e01227abc0bdbdf04fdb82561 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uaAB56k8DSpwJDXJ_tSl5fbSaO8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 09 Jul 2014 00:54:10 -0000 --089e01227abc0bdbdf04fdb82561 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If I understand correctly, this parameter is used to appropriately constrain the schema of the Redirect URIs at the time of the registration and is not about fulfilling the Client Type registration requirement in section 2.1. So, making go or no-go decision based on the discussion around section 2.1 probably would not be the way to go. The discussion should happen around the needs on constraining the schema depending on the kind of client. Apparently, Connect WG perceived that it is a big enough risk that they need to put a plug on based on the risk evaluation as an identity federation protocol. OAuth has different risk profile so it could decide otherwise, but my gut feeling is that unless there is a good reason not to have it, we may as well keep it. Nat 2014-07-09 7:54 GMT+09:00 Richer, Justin P. : > This value was introduced in -18, and it's a direct port from OpenID > Connect. It was never in the OAuth Dynamic Registration spec, and though = it > has been in the OpenID Connect Dynamic Registration spec for a very long > time, I think it was a mistake to add it in for several reasons: > > First, the semantics around its values and use are not clearly defined, > for the reasons . I don't see any particular harm in keeping it, but I > don't really see what value it adds for clients or server developers. We > are in a world where there are OAuth clients that are much more than just > "native" or "web". > > Second, RFC6749 defines "Client Type" in =C2=A7 2.1 which defines two va= lues: > "confidential" and "public", neither of which maps very cleanly to "nativ= e" > or "web" as stated in -18. This is especially true when you've got dynami= c > registration that can make native clients confidential with relative ease= . > We actually take care of registering the "client type" through the use of > the "token_endpoint_auth_method" parameter, which is what =C2=A7 2.1 is r= eally > talking about: secure client authentication (to the token endpoint). > > With this in mind, my preference and suggestion would be to remove this > field. If other protocols need it, they can register and define it (like > Connect has done). > > -- Justin > > > On Jul 8, 2014, at 4:38 PM, Mike Jones > wrote: > > I put it back because otherwise, we wouldn't be meeting one of the > requirements of the RFC 6749. If you look at the client registration > section http://tools.ietf.org/html/rfc6749#section-2, you=E2=80=99ll see = that > registering redirect_uri values is required, as is registering the client > type. Without this, there wasn=E2=80=99t a way to register the client ty= pe. > > > > -- Mike > > > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org ] On > Behalf Of John Bradley > Sent: Tuesday, July 08, 2014 12:37 PM > To: Phil Hunt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type > > > > It was taken out and then put back in as it is a common parameter used by > a number of AS. > > > > We have it in Connect, the best reason for keeping it is to stop people > from coming up with a new parameter for the same thing because they haven= 't > looked at the Connect version. > > > > John B. > > On Jul 8, 2014, at 3:16 PM, Phil Hunt wrote: > > > > > Does this need to be in the spec? I believe we=E2=80=99ve already said= that > others can add attributes as they need. > > > > > > Phil > > > > > > @independentid > > > www.independentid.com > > > phil.hunt@oracle.com > > > > > > > > > > > > On Jul 8, 2014, at 11:56 AM, John Bradley wrote: > > > > > >> The application_type is collected as part of current registration by > Google and some other OAuth providers as part of registering redirect uri= . > > >> > > >> The text was cut down to allow more flexibility in OAuth. Connect > requires registration of redirect_uri and is more ridged about it than > OAuth 2. > > >> > > >> Do you think the Connect wording would be appropriate for OAuth? > > >> > > >> John B. > > >> > > >> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > > >> > > >>> This additional information makes a lot of sense. > > >>> > > >>> As you said in an earlier mail, the attempt to copy text from the > > >>> OpenID Connect spec failed a bit... > > >>> > > >>> On 07/08/2014 02:49 PM, Nat Sakimura wrote: > > >>>> I suppose authors has imported one of the security feature of > > >>>> OpenID Connect here as well. In the Dynamic Client Registration > > >>>> standard, which is a bit longer than IETF version. You can see the > reason from it: > > >>>> > > >>>> application_type > > >>>> OPTIONAL. Kind of the application. The default, if omitted, is web. > > >>>> The defined values are native or web. Web Clients using the OAuth > > >>>> Implicit Grant Type MUST only register URLs using the https scheme > > >>>> as redirect_uris; they MUST NOT use localhost as the hostname. > > >>>> Native Clients MUST only register redirect_uris using custom URI > > >>>> schemes or URLs using the http: scheme with localhost as the > > >>>> hostname. Authorization Servers MAY place additional constraints on > > >>>> Native Clients. Authorization Servers MAY reject Redirection URI > > >>>> values using the http scheme, other than the localhost case for > > >>>> Native Clients. The Authorization Server MUST verify that all the > > >>>> registered redirect_uris conform to these constraints. This > > >>>> prevents sharing a Client ID across different types of Clients. > > >>>> > > >>>> Regards, > > >>>> > > >>>> Nat > > >>>> > > >>>> > > >>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig > > >>>> > >>>> >>: > > >>>> > > >>>> Hi all, > > >>>> > > >>>> with version -18 you guys have added a new meta-data attribute, > > >>>> namely application_type. > > >>>> > > >>>> First, this new attribute is not listed in the IANA consideration > > >>>> section. > > >>>> > > >>>> Second, could you provide a bit of motivation why you need it? > > >>>> What would the authorization server do with that type of > > >>>> information? The description is rather short. > > >>>> > > >>>> IMHO there is also no clear boundary between a "native" and "web" > app. > > >>>> Just think about smart phone apps that are developed using > JavaScript. > > >>>> Would this be a web app or a native app? > > >>>> > > >>>> Here is the definition from the draft: > > >>>> > > >>>> application_type > > >>>> OPTIONAL. Kind of the application. The default, if omitted, > is > > >>>> "web". The defined values are "native" or "web". > > >>>> > > >>>> Ciao > > >>>> Hannes > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> OAuth mailing list > > >>>> OAuth@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/oauth > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> Nat Sakimura (=3Dnat) > > >>>> Chairman, OpenID Foundation > > >>>> http://nat.sakimura.org/ > > >>>> @_nat_en > > >>> > > >>> _______________________________________________ > > >>> 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 > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e01227abc0bdbdf04fdb82561 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If I understand correctly, this parameter is used to appro= priately constrain the schema of the Redirect URIs at the time of the regis= tration and is not about fulfilling the Client Type registration requiremen= t in section 2.1. So, making go or no-go decision based on the discussion a= round section 2.1 probably would not be the way to go. The discussion shoul= d happen around the needs on constraining the schema depending on the kind = of client.=C2=A0

Apparently, Connect WG perceived that it is a big enough ris= k that they need to put a plug on based on the risk evaluation as an identi= ty federation protocol. OAuth has different risk profile so it could decide= otherwise, but my gut feeling is that unless there is a good reason not to= have it, we may as well keep it.=C2=A0

Nat


2014-07-09 7:54 GMT+09:00 Richer, Justin P. <jriche= r@mitre.org>:
This value was introduced in -18, and it's a direct port from OpenID Co= nnect. It was never in the OAuth Dynamic Registration spec, and though it h= as been in the OpenID Connect Dynamic Registration spec for a very long tim= e, I think it was a mistake to add it in for several reasons:=C2=A0

First, the semantics around its values and use are not clearly defined= , for the reasons . I don't see any particular harm in keeping it, but = I don't really see what value it adds for clients or server developers.= We are in a world where there are OAuth clients that are much more than just "native" or "web"= .

Second, RFC6749 defines "Client Type" in =C2=A7 2.1 which de= fines two values: "confidential" and "public", neither = of which maps very cleanly to "native" or "web" as stat= ed in -18. This is especially true when you've got dynamic registration= that can make native clients confidential with relative ease. We actually take care of register= ing the "client type" through the use of the "token_endpoint= _auth_method" parameter, which is what =C2=A7 2.1 is really talking ab= out: secure client authentication (to the token endpoint).=C2=A0

With this in mind, my preference and suggestion would be to remove thi= s field. If other protocols need it, they can register and define it (like = Connect has done).

=C2=A0-- Justin


On Jul 8, 2014, at 4:38 PM, Mike Jones <Michael.Jones@microsoft.com> w= rote:

I put it back because otherwise, we wouldn= 't be meeting one of the requirements of the RFC 6749.=C2=A0 If you loo= k at the client registration section = http://tools.ietf.org/html/rfc6749#section-2, you=E2=80=99ll see that r= egistering redirect_uri values is required, as is registering the client ty= pe.=C2=A0 Without this, there wasn=E2=80=99t a way to register the client type.

=C2=A0

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

=C2=A0

-----Original Message-----
From: OAuth [ma= ilto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, July 08, 2014 12:37 PM
To: Phil Hunt
Cc: oauth@ietf.org<= br> Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type

=C2=A0

It was taken out and then put back in as it is a common parameter used b= y a number of AS.

=C2=A0

We have it in Connect, the best reason for keeping it is to stop people = from coming up with a new parameter for the same thing because they haven&#= 39;t looked at the Connect version.

=C2=A0

John B.

On Jul 8, 2014, at 3:16 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

=C2=A0

> Does this need to be in the spec?=C2=A0 I believe we=E2=80=99ve alr= eady said that others can add attributes as they need.

>

> Phil

>

> @independentid

> www.independentid.com=

> phil.hunt@oracle.com

>

>

>

> On Jul 8, 2014, at 11:56 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

>

>> The application_type is collected as part of current registrati= on by Google and some other OAuth providers as part of registering redirect= uri.

>>

>> The text was cut down to allow more flexibility in OAuth.=C2=A0= Connect requires registration of redirect_uri and is more ridged about it = than OAuth 2.

>>

>> Do you think the Connect wording would be appropriate for OAuth= ?

>>

>> John B.

>>

>> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote= :

>>

>>> This additional information makes a lot of sense.=

>>>

>>> As you said in an earlier mail, the attempt to copy text fr= om the

>>> OpenID Connect spec failed a bit...

>>>

>>> On 07/08/2014 02:49 PM, Nat Sakimura wrote:

>>>> I suppose authors has imported one of the security feat= ure of

>>>> OpenID Connect here as well. In the Dynamic Client Regi= stration

>>>> standard, which is a bit longer than IETF version. You = can see the reason from it:

>>>>

>>>> application_type

>>>>=C2=A0 OPTIONAL. Kind of the application. The default, i= f omitted, is web.

>>>>=C2=A0 The defined values are native or web. Web Clients= using the OAuth=C2=A0

>>>> Implicit Grant Type MUST only register URLs using the h= ttps scheme=C2=A0

>>>> as redirect_uris; they MUST NOT use localhost as the ho= stname.

>>>>=C2=A0 Native Clients MUST only register redirect_uris u= sing custom URI=C2=A0

>>>> schemes or URLs using the http: scheme with localhost a= s the=C2=A0

>>>> hostname. Authorization Servers MAY place additional co= nstraints on=C2=A0

>>>> Native Clients. Authorization Servers MAY reject Redire= ction URI=C2=A0

>>>> values using the http scheme, other than the localhost = case for=C2=A0

>>>> Native Clients. The Authorization Server MUST verify th= at all the=C2=A0

>>>> registered redirect_uris conform to these constraints. = This

>>>> prevents=C2=A0 sharing a Client ID across different typ= es of Clients.

>>>>

>>>> Regards,

>>>>

>>>> Nat

>>>>

>>>>

>>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig =

>>>> <hannes.tschofenig@gmx.net

>>>> <mailto:ha= nnes.tschofenig@gmx.net>>:

>>>>

>>>>=C2=A0 Hi all,

>>>>

>>>>=C2=A0 with version -18 you guys have added a new meta-d= ata attribute,

>>>> namely=C2=A0 application_type.

>>>>

>>>>=C2=A0 First, this new attribute is not listed in the IA= NA consideration=C2=A0

>>>> section.

>>>>

>>>>=C2=A0 Second, could you provide a bit of motivation why= you need it?

>>>> What=C2=A0 would the authorization server do with that = type of

>>>> information? The=C2=A0 description is rather short.<= /u>

>>>>

>>>>=C2=A0 IMHO there is also no clear boundary between a &q= uot;native" and "web" app.

>>>>=C2=A0 Just think about smart phone apps that are develo= ped using JavaScript.

>>>>=C2=A0 Would this be a web app or a native app?

>>>>

>>>>=C2=A0 Here is the definition from the draft:<= /u>

>>>>

>>>>=C2=A0 application_type

>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2= =A0 Kind of the application.=C2=A0 The default, if omitted, is

>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "web&quo= t;.=C2=A0 The defined values are "native" or "web".<= /u>

>>>>

>>>>=C2=A0 Ciao

>>>>=C2=A0 Hannes

>>>>

>>>>

>>>>=C2=A0 _______________________________________________

>>>>=C2=A0 OAuth mailing list

>>>>=C2=A0 OAuth@ietf.org <mailto:OAuth@ietf.org= >=C2=A0

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

>>>>

>>>>

>>>>

>>>>

>>>> --

>>>> Nat Sakimura (=3Dnat)

>>>> Chairman, OpenID Foundation

>>>> = http://nat.sakimura.o= rg/

>>>> @_nat_en

>>>

>>> _______________________________________________

>>> 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

>

=C2=A0

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or= g/mailman/listinfo/oauth

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


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--089e01227abc0bdbdf04fdb82561-- From nobody Tue Jul 8 18:36:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307BD1A0203 for ; Tue, 8 Jul 2014 18:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 OYFKQbzLQVdl for ; Tue, 8 Jul 2014 18:35:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA5A1A0202 for ; Tue, 8 Jul 2014 18:35:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D420C1F0A22; Tue, 8 Jul 2014 21:35:56 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C25191F0A1E; Tue, 8 Jul 2014 21:35:56 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.118]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Tue, 8 Jul 2014 21:35:56 -0400 From: "Richer, Justin P." To: Nat Sakimura Thread-Topic: [OAUTH-WG] Dynamic Client Registration: application_type Thread-Index: AQHPmqsISlJhoAzG1kOzzUWGRyN2OpuWbSEAgABdNICAAAWYAIAABcgAgAARFICAACXzgIAAIYsAgAALrgA= Date: Wed, 9 Jul 2014 01:35:55 +0000 Message-ID: <3805694E-F081-4B07-9252-4602C531D402@mitre.org> References: <53BBE144.90307@gmx.net> <53BBF0A6.3000801@gmx.net> <453DCBD9-89C5-4BCB-B73B-94CEF842204C@oracle.com> <53F6DF2E-5F56-420D-B94B-70D05C4ED0FC@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADA0BA8@TK5EX14MBXC294.redmond.corp.microsoft.com> <09F7FAD7-5EEC-4A22-84C8-2823D3AC0D2F@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.34.95] Content-Type: multipart/alternative; boundary="_000_3805694EF0814B0792524602C531D402mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kjHGXaO7AXUqokbfRCLqRODm6ic Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 09 Jul 2014 01:36:00 -0000 --_000_3805694EF0814B0792524602C531D402mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Right, that's how it's used in Connect, which defines only redirect-based f= lows. However, the OAuth version needs to be more general purpose. It seems like this parameter really does need more discussion in the group = before it should be added to the spec, and therefore I don't think it's app= ropriate to add it at this stage (post-WGLC). -- Justin On Jul 8, 2014, at 8:54 PM, Nat Sakimura > wrote: If I understand correctly, this parameter is used to appropriately constrai= n the schema of the Redirect URIs at the time of the registration and is no= t about fulfilling the Client Type registration requirement in section 2.1.= So, making go or no-go decision based on the discussion around section 2.1= probably would not be the way to go. The discussion should happen around t= he needs on constraining the schema depending on the kind of client. Apparently, Connect WG perceived that it is a big enough risk that they nee= d to put a plug on based on the risk evaluation as an identity federation p= rotocol. OAuth has different risk profile so it could decide otherwise, but= my gut feeling is that unless there is a good reason not to have it, we ma= y as well keep it. Nat 2014-07-09 7:54 GMT+09:00 Richer, Justin P. >: This value was introduced in -18, and it's a direct port from OpenID Connec= t. It was never in the OAuth Dynamic Registration spec, and though it has b= een in the OpenID Connect Dynamic Registration spec for a very long time, I= think it was a mistake to add it in for several reasons: First, the semantics around its values and use are not clearly defined, for= the reasons . I don't see any particular harm in keeping it, but I don't r= eally see what value it adds for clients or server developers. We are in a = world where there are OAuth clients that are much more than just "native" o= r "web". Second, RFC6749 defines "Client Type" in =A7 2.1 which defines two values: = "confidential" and "public", neither of which maps very cleanly to "native"= or "web" as stated in -18. This is especially true when you've got dynamic= registration that can make native clients confidential with relative ease.= We actually take care of registering the "client type" through the use of = the "token_endpoint_auth_method" parameter, which is what =A7 2.1 is really= talking about: secure client authentication (to the token endpoint). With this in mind, my preference and suggestion would be to remove this fie= ld. If other protocols need it, they can register and define it (like Conne= ct has done). -- Justin On Jul 8, 2014, at 4:38 PM, Mike Jones > wrote: I put it back because otherwise, we wouldn't be meeting one of the requirem= ents of the RFC 6749. If you look at the client registration section http:= //tools.ietf.org/html/rfc6749#section-2, you=92ll see that registering redi= rect_uri values is required, as is registering the client type. Without th= is, there wasn=92t a way to register the client type. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley Sent: Tuesday, July 08, 2014 12:37 PM To: Phil Hunt Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type It was taken out and then put back in as it is a common parameter used by a= number of AS. We have it in Connect, the best reason for keeping it is to stop people fro= m coming up with a new parameter for the same thing because they haven't lo= oked at the Connect version. John B. On Jul 8, 2014, at 3:16 PM, Phil Hunt > wrote: > Does this need to be in the spec? I believe we=92ve already said that ot= hers can add attributes as they need. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jul 8, 2014, at 11:56 AM, John Bradley > wrote: > >> The application_type is collected as part of current registration by Goo= gle and some other OAuth providers as part of registering redirect uri. >> >> The text was cut down to allow more flexibility in OAuth. Connect requi= res registration of redirect_uri and is more ridged about it than OAuth 2. >> >> Do you think the Connect wording would be appropriate for OAuth? >> >> John B. >> >> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig > wrote: >> >>> This additional information makes a lot of sense. >>> >>> As you said in an earlier mail, the attempt to copy text from the >>> OpenID Connect spec failed a bit... >>> >>> On 07/08/2014 02:49 PM, Nat Sakimura wrote: >>>> I suppose authors has imported one of the security feature of >>>> OpenID Connect here as well. In the Dynamic Client Registration >>>> standard, which is a bit longer than IETF version. You can see the rea= son from it: >>>> >>>> application_type >>>> OPTIONAL. Kind of the application. The default, if omitted, is web. >>>> The defined values are native or web. Web Clients using the OAuth >>>> Implicit Grant Type MUST only register URLs using the https scheme >>>> as redirect_uris; they MUST NOT use localhost as the hostname. >>>> Native Clients MUST only register redirect_uris using custom URI >>>> schemes or URLs using the http: scheme with localhost as the >>>> hostname. Authorization Servers MAY place additional constraints on >>>> Native Clients. Authorization Servers MAY reject Redirection URI >>>> values using the http scheme, other than the localhost case for >>>> Native Clients. The Authorization Server MUST verify that all the >>>> registered redirect_uris conform to these constraints. This >>>> prevents sharing a Client ID across different types of Clients. >>>> >>>> Regards, >>>> >>>> Nat >>>> >>>> >>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig >>>> >>>> >: >>>> >>>> Hi all, >>>> >>>> with version -18 you guys have added a new meta-data attribute, >>>> namely application_type. >>>> >>>> First, this new attribute is not listed in the IANA consideration >>>> section. >>>> >>>> Second, could you provide a bit of motivation why you need it? >>>> What would the authorization server do with that type of >>>> information? The description is rather short. >>>> >>>> IMHO there is also no clear boundary between a "native" and "web" app= . >>>> Just think about smart phone apps that are developed using JavaScript= . >>>> Would this be a web app or a native app? >>>> >>>> Here is the definition from the draft: >>>> >>>> application_type >>>> OPTIONAL. Kind of the application. The default, if omitted, i= s >>>> "web". The defined values are "native" or "web". >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>> >>> _______________________________________________ >>> 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 -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --_000_3805694EF0814B0792524602C531D402mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Right, that's how it's used in Connect, which defines only redirect-based f= lows. However, the OAuth version needs to be more general purpose. 

It seems like this parameter really does need more discussion in the g= roup before it should be added to the spec, and therefore I don't think it'= s appropriate to add it at this stage (post-WGLC).

 -- Justin

On Jul 8, 2014, at 8:54 PM, Nat Sakimura <sakimura@gmail.com> wrote:

If I understand correctly, this parameter is used to appro= priately constrain the schema of the Redirect URIs at the time of the regis= tration and is not about fulfilling the Client Type registration requiremen= t in section 2.1. So, making go or no-go decision based on the discussion around section 2.1 probably would n= ot be the way to go. The discussion should happen around the needs on const= raining the schema depending on the kind of client. 

Apparently, Connect WG perceived that it is a big enough risk that the= y need to put a plug on based on the risk evaluation as an identity federat= ion protocol. OAuth has different risk profile so it could decide otherwise= , but my gut feeling is that unless there is a good reason not to have it, we may as well keep it. 

Nat


2014-07-09 7:54 GMT+09:00 Richer, Justin P. = <jricher@mitre.or= g>:
This value was introduced in -18, and i= t's a direct port from OpenID Connect. It was never in the OAuth Dynamic Re= gistration spec, and though it has been in the OpenID Connect Dynamic Regis= tration spec for a very long time, I think it was a mistake to add it in for several reasons: 

First, the semantics around its values and use are not clearly defined= , for the reasons . I don't see any particular harm in keeping it, but I do= n't really see what value it adds for clients or server developers. We are = in a world where there are OAuth clients that are much more than just "native" or "web"= .

Second, RFC6749 defines "Client Type" in =A7 2.1 which defin= es two values: "confidential" and "public", neither of = which maps very cleanly to "native" or "web" as stated = in -18. This is especially true when you've got dynamic registration that c= an make native clients confidential with relative ease. We actually take care of register= ing the "client type" through the use of the "token_endpoint= _auth_method" parameter, which is what =A7 2.1 is really talking about= : secure client authentication (to the token endpoint). 

With this in mind, my preference and suggestion would be to remove thi= s field. If other protocols need it, they can register and define it (like = Connect has done).

 -- Justin


On Jul 8, 2014, at 4:38 PM, Mike Jones <Michael.Jones@microsoft.com> w= rote:

I put it back because otherwise, we wouldn= 't be meeting one of the requirements of the RFC 6749.  If you look at= the client registration section = http://tools.ietf.org/html/rfc6749#section-2, you=92ll see that registe= ring redirect_uri values is required, as is registering the client type.&nb= sp; Without this, there wasn=92t a way to register the client type.

 

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

 

-----Original Message-----
From: OAuth [ma= ilto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, July 08, 2014 12:37 PM
To: Phil Hunt
Cc: oauth@ietf.org<= br> Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type

 

It was taken out and then put back in as it is a common parameter used b= y a number of AS.

 

We have it in Connect, the best reason for keeping it is to stop people = from coming up with a new parameter for the same thing because they haven't= looked at the Connect version.

 

John B.

On Jul 8, 2014, at 3:16 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

> Does this need to be in the spec?  I believe we=92ve already s= aid that others can add attributes as they need.

>

> Phil

>

> @independentid

> www.independentid.com=

> phil.hunt@oracle.com

>

>

>

> On Jul 8, 2014, at 11:56 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

>

>> The application_type is collected as part of current registrati= on by Google and some other OAuth providers as part of registering redirect= uri.

>>

>> The text was cut down to allow more flexibility in OAuth. = Connect requires registration of redirect_uri and is more ridged about it = than OAuth 2.

>>

>> Do you think the Connect wording would be appropriate for OAuth= ?

>>

>> John B.

>>

>> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote= :

>>

>>> This additional information makes a lot of sense.=

>>>

>>> As you said in an earlier mail, the attempt to copy text fr= om the

>>> OpenID Connect spec failed a bit...

>>>

>>> On 07/08/2014 02:49 PM, Nat Sakimura wrote:

>>>> I suppose authors has imported one of the security feat= ure of

>>>> OpenID Connect here as well. In the Dynamic Client Regi= stration

>>>> standard, which is a bit longer than IETF version. You = can see the reason from it:

>>>>

>>>> application_type

>>>>  OPTIONAL. Kind of the application. The default, i= f omitted, is web.

>>>>  The defined values are native or web. Web Clients= using the OAuth 

>>>> Implicit Grant Type MUST only register URLs using the h= ttps scheme 

>>>> as redirect_uris; they MUST NOT use localhost as the ho= stname.

>>>>  Native Clients MUST only register redirect_uris u= sing custom URI 

>>>> schemes or URLs using the http: scheme with localhost a= s the 

>>>> hostname. Authorization Servers MAY place additional co= nstraints on 

>>>> Native Clients. Authorization Servers MAY reject Redire= ction URI 

>>>> values using the http scheme, other than the localhost = case for 

>>>> Native Clients. The Authorization Server MUST verify th= at all the 

>>>> registered redirect_uris conform to these constraints. = This

>>>> prevents  sharing a Client ID across different typ= es of Clients.

>>>>

>>>> Regards,

>>>>

>>>> Nat

>>>>

>>>>

>>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig

>>>> <hannes.tschofenig@gmx.net

>>>> <mailto:ha= nnes.tschofenig@gmx.net>>:

>>>>

>>>>  Hi all,

>>>>

>>>>  with version -18 you guys have added a new meta-d= ata attribute,

>>>> namely  application_type.

>>>>

>>>>  First, this new attribute is not listed in the IA= NA consideration 

>>>> section.

>>>>

>>>>  Second, could you provide a bit of motivation why= you need it?

>>>> What  would the authorization server do with that = type of

>>>> information? The  description is rather short.<= /u>

>>>>

>>>>  IMHO there is also no clear boundary between a &q= uot;native" and "web" app.

>>>>  Just think about smart phone apps that are develo= ped using JavaScript.

>>>>  Would this be a web app or a native app?

>>>>

>>>>  Here is the definition from the draft:<= /u>

>>>>

>>>>  application_type

>>>>        OPTIONAL.&nbs= p; Kind of the application.  The default, if omitted, is=

>>>>        "web&quo= t;.  The defined values are "native" or "web".<= /u>

>>>>

>>>>  Ciao

>>>>  Hannes

>>>>

>>>>

>>>>  _______________________________________________

>>>>  OAuth mailing list

>>>>  OAuth@ietf.org <mailto:OAuth@ietf.org= > 

>>>> ht= tps://www.ietf.org/mailman/listinfo/oauth

>>>>

>>>>

>>>>

>>>>

>>>> --

>>>> Nat Sakimura (=3Dnat)

>>>> Chairman, OpenID Foundation

>>>> = http://nat.sakimura.o= rg/

>>>> @_nat_en

>>>

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf.org=

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

>>

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org=

>> https://w= ww.ietf.org/mailman/listinfo/oauth

>

 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or= g/mailman/listinfo/oauth

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


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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

--_000_3805694EF0814B0792524602C531D402mitreorg_-- From nobody Tue Jul 8 18:44:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCAE1A0203 for ; Tue, 8 Jul 2014 18:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 wm6SnetF36On for ; Tue, 8 Jul 2014 18:44:10 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1AABD1A020A for ; Tue, 8 Jul 2014 18:44:10 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B77031F046B for ; Tue, 8 Jul 2014 21:44:09 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9C44F1F02AF for ; Tue, 8 Jul 2014 21:44:09 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.118]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 8 Jul 2014 21:44:09 -0400 From: "Richer, Justin P." To: "oauth@ietf.org list" Thread-Topic: Dynamic Client Registration: comment on metadata requirements Thread-Index: AQHPmxdGXSqb6uV98kqyx+t2wL0I1g== Date: Wed, 9 Jul 2014 01:44:08 +0000 Message-ID: <4D1EA5D2-8862-47FD-8C17-D74C88287F87@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.34.95] Content-Type: multipart/alternative; boundary="_000_4D1EA5D2886247FD8C17D74C88287F87mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jZpKPUh3CP46A8NG7FzuvqIJexg Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements 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, 09 Jul 2014 01:44:12 -0000 --_000_4D1EA5D2886247FD8C17D74C88287F87mitreorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In draft -18, we clarified the optionality of the client metadata parameter= s in =A7 2 with new text, including the sentences: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris". redirect_uris (...) Authorization servers MUST implement support for this m= etadata value. However, since OAuth core defines two non-redirect flows (client credential= s and password) and we're about to publish another one (assertions), I sugg= est that we adopt the following clarification: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support redirect-based gra= nt types. Authorization servers that support dynamic registration of clients using re= direct-based grant types MUST implement support for this metadata value. I think this language brings the requirement more in line with the intent a= nd would like comment from the WG. -- Justin --_000_4D1EA5D2886247FD8C17D74C88287F87mitreorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable In draft -18, we clarified the optionality of the client metadata parameter= s in =A7 2 with new text, including the sentences: 

The implementation and use of all client metadata fi=
elds is OPTIONAL, other than "redirect_uris".

redirect_uris (...) Authorization servers MUST imple=
ment support for this metadata value.


However, since OAuth core defines two non-redirect flows (client crede= ntials and password) and we're about to publish another one (assertions), I= suggest that we adopt the following clarification:

The implementation and use of all client metadata fi=
elds is OPTIONAL, other than "redirect_uris"
which is REQUIRED for authorization servers that sup=
port redirect-based grant types.

Authorization servers that support dynamic registrat=
ion of clients using redirect-based
grant types MUST implement support for this metadata=
 value.

I think this language brings the requirement more in line with the int= ent and would like comment from the WG.

 -- Justin
--_000_4D1EA5D2886247FD8C17D74C88287F87mitreorg_-- From nobody Tue Jul 8 18:46:22 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD151A023E for ; Tue, 8 Jul 2014 18:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffL8WklMzZLd for ; Tue, 8 Jul 2014 18:46:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E59861A0203 for ; Tue, 8 Jul 2014 18:46:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7A7E91F0A22 for ; Tue, 8 Jul 2014 21:46:17 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5F1781F046B for ; Tue, 8 Jul 2014 21:46:17 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.118]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Tue, 8 Jul 2014 21:46:17 -0400 From: "Richer, Justin P." To: "oauth@ietf.org list" Thread-Topic: Introspection draft -06 Thread-Index: AQHPmxeS5STIH/orM0KKueo/VwH2fg== Date: Wed, 9 Jul 2014 01:46:16 +0000 Message-ID: <9DFAA6A4-16E9-4E19-9053-A25F0FA7D59D@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.34.95] Content-Type: text/plain; charset="us-ascii" Content-ID: <6336A98669B17E4B96D66CCCC39C3BF7@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/eUoFstdlo3gb-xJy-U9GlR8ubog Subject: [OAUTH-WG] Introspection draft -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, 09 Jul 2014 01:46:19 -0000 I've updated the introspection draft based on the handful of comments that = I received from -05 to allow these discussions to be incorporated into the = discussion going forward: http://tools.ietf.org/id/draft-richer-oauth-introspection-06.html -- Justin= From nobody Tue Jul 8 19:15:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057A81A0270 for ; Tue, 8 Jul 2014 19:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32AK92EwqpWu for ; Tue, 8 Jul 2014 19:15:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59791A0202 for ; Tue, 8 Jul 2014 19:15:20 -0700 (PDT) Received: from BLUPR03CA036.namprd03.prod.outlook.com (10.141.30.29) by BLUPR03MB344.namprd03.prod.outlook.com (10.141.48.24) with Microsoft SMTP Server (TLS) id 15.0.980.8; Wed, 9 Jul 2014 02:15:18 +0000 Received: from BL2FFO11FD047.protection.gbl (2a01:111:f400:7c09::142) by BLUPR03CA036.outlook.office365.com (2a01:111:e400:879::29) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Wed, 9 Jul 2014 02:15:18 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD047.mail.protection.outlook.com (10.173.161.209) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 9 Jul 2014 02:15:18 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0195.002; Wed, 9 Jul 2014 02:14:47 +0000 From: Mike Jones To: Phil Hunt , Hannes Tschofenig Thread-Topic: Dynamic Client Registration: IPR Confirmation Thread-Index: AQHPmqNjTLUtygPATEaoV9K+QkTus5uWWTqAgAAPVUaAAJbWEA== Date: Wed, 9 Jul 2014 02:14:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53BBDBEE.703@gmx.net>, <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADA1766TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(55885003)(189002)(377454003)(24454002)(51704005)(199002)(92566001)(86362001)(19580405001)(31966008)(106466001)(33656002)(15395725005)(19625215002)(92726001)(4396001)(74662001)(95666004)(15975445006)(106116001)(87936001)(81542001)(97736001)(81156004)(2656002)(16236675004)(83072002)(107046002)(80022001)(84326002)(104016002)(26826002)(66066001)(77982001)(20776003)(84676001)(64706001)(15202345003)(16297215004)(83322001)(77096002)(55846006)(21056001)(85306003)(69596002)(19580395003)(68736004)(74502001)(76482001)(54356999)(46102001)(44976005)(81342001)(71186001)(79102001)(19300405004)(85852003)(99396002)(86612001)(6806004)(50986999)(76176999); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB344; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0267E514F9 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/gHYNfEIcH6tboQBBOcm6zLMbqGk Cc: Maciej Machulak , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 09 Jul 2014 02:15:24 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADA1766TK5EX14MBXC294r_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Thinking about this some more, there is one IPR issue that we need to addre= ss before publication. This specification is a derivative work from the Op= enID Connect Dynamic Registration specification http://openid.net/specs/ope= nid-connect-registration-1_0.html. Large portions of the text were copied = wholesale from that spec to this one, so that the two would be compatible. = (This is good thing =96 not a bad thing.) This is easy to address from an IPR perspective =96 simply acknowledge that= this spec is a derivative work and provide proper attribution. The OpenID= copyright in the spec at http://openid.net/specs/openid-connect-registrati= on-1_0.html#Notices allows for this resolution. It says: Copyright (c) 2014 The OpenID Foundation. The OpenID Foundation (OIDF) grants to any Contributor, developer, implemen= ter, or other interested party a non-exclusive, royalty free, worldwide cop= yright license to reproduce, prepare derivative works from, distribute, per= form and display, this Implementers Draft or Final Specification solely for= the purposes of (i) developing specifications, and (ii) implementing Imple= menters Drafts and Final Specifications based on such documents, provided t= hat attribution be made to the OIDF as the source of the material, but that= such attribution does not indicate an endorsement by the OIDF. Let=92s add the reference and acknowledgment in the next version. -- Mike From: Mike Jones Sent: Tuesday, July 08, 2014 10:06 AM To: Phil Hunt; Hannes Tschofenig Cc: John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org Subject: RE: Dynamic Client Registration: IPR Confirmation I likewise do not hold any IPR on these specs. ________________________________ From: Phil Hunt Sent: =FD7/=FD8/=FD2014 9:11 AM To: Hannes Tschofenig Cc: Mike Jones; John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org Subject: Re: Dynamic Client Registration: IPR Confirmation I confirm I have no IPR disclosures on this document. Phil > On Jul 8, 2014, at 4:54, Hannes Tschofenig > wrote: > > Hi Phil, John, Maciej, Justin, Mike, > > I am working on the shepherd writeup for the dynamic client registration > document and 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? > > Ciao > Hannes > > --_000_4E1F6AAD24975D4BA5B16804296739439ADA1766TK5EX14MBXC294r_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Thinking about this some = more, there is one IPR issue that we need to address before publication.&nb= sp; This specification is a derivative work from the OpenID Connect Dynamic Registration specification http://openid.net/specs/openid-connect-registration-1_0.html.  Lar= ge portions of the text were copied wholesale from that spec to this one, s= o that the two would be compatible.  (This is good thing =96 not a bad= thing.)

 <= /p>

This is easy to address f= rom an IPR perspective =96 simply acknowledge that this spec is a derivativ= e work and provide proper attribution.  The OpenID copyright in the spec at http://openid.net/specs/openid-connect-registration-1_0.html#Notices al= lows for this resolution.  It says:

 <= /p>

Copyright (c) 2014 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contrib= utor, developer, implementer, or other interested party a non-exclusive, ro= yalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Imple= menters Draft or Final Specification solely for the purposes of (i) develop= ing specifications, and (ii) implementing Implementers Drafts and Final Spe= cifications based on such documents, provided that attribution be made to the OIDF as the source of the materia= l, but that such attribution does not indicate an endorsement by the OIDF.<= o:p>

Let=92s add the reference= and acknowledgment in the next version.

 <= /p>

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

 <= /p>

From: Mike Jon= es
Sent: Tuesday, July 08, 2014 10:06 AM
To: Phil Hunt; Hannes Tschofenig
Cc: John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org
Subject: RE: Dynamic Client Registration: IPR Confirmation

 

I likewise do not hold any IPR on these= specs.

I confirm I have no= IPR disclosures on this document.

Phil

> On Jul 8, 2014, at 4:54, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
> Hi Phil, John, Maciej, Justin, Mike,
>
> I am working on the shepherd writeup for the dynamic client registrati= on
> document and one item in the template requires me to indicate whether<= br> > each document author has confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 7= 8
> and BCP 79 have already been filed.
>
> Could you please confirm?
>
> Ciao
> Hannes
>
>

--_000_4E1F6AAD24975D4BA5B16804296739439ADA1766TK5EX14MBXC294r_-- From nobody Tue Jul 8 19:16:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B891A0202 for ; Tue, 8 Jul 2014 19:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, 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 DR38mIU-mghJ for ; Tue, 8 Jul 2014 19:16:02 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAA21A0282 for ; Tue, 8 Jul 2014 19:16:02 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id i8so6023726qcq.20 for ; Tue, 08 Jul 2014 19:16:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=IWRPSC02GMTk/qT8VIm6h55RyMMrZ9OQFqRHHcoMy4c=; b=m7zIDQgEr0ohK0U4OQUeLWW9tJPGIJ+mHb/HOzvormtuIo8wVFpWGRkqcjQP6bSD0m wknUFqcHCxk48jGuAbX6U/GQdXwXP5ajVVtF5AuUFXL+VNpuFV9okGZfjjvs5AwBcd45 U4vBnC4gu1JisD/69AcQ1k/9nJkDerz3Usll9Ltu1fsbC0lxRq1CJ1NiG9+iLUClDx0G 9WV0EIgUNMomi4ye7mhrWFMC8b5bcSpn8W0HzZzzZsQX66WWqh0monJpdV/UYbB8YQ0f GvA81tyhV7glRJIzqAK7bwFw26o1TufUt3splu7G+LKkn2t4B2eqZCIJzIU322H2Fthw 3Qvg== X-Gm-Message-State: ALoCoQkFpuDHhPO8S+Wr/6Cc4/BJHkI/8PtWwdbSvIZYFFVA6XDWS3adk/y0iSjhUXaFvy1CLXeH X-Received: by 10.140.37.9 with SMTP id q9mr55189264qgq.32.1404872161264; Tue, 08 Jul 2014 19:16:01 -0700 (PDT) Received: from [192.168.1.38] (186-79-213-173.baf.movistar.cl. [186.79.213.173]) by mx.google.com with ESMTPSA id x12sm3927144qaw.1.2014.07.08.19.15.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 19:16:00 -0700 (PDT) References: <4D1EA5D2-8862-47FD-8C17-D74C88287F87@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <4D1EA5D2-8862-47FD-8C17-D74C88287F87@mitre.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-24F48F2C-77AA-4DFE-A39F-D791537AA89A; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <7D66F203-1401-4B38-88D3-1FA847F68F3E@ve7jtb.com> X-Mailer: iPhone Mail (11D257) From: John Bradley Date: Tue, 8 Jul 2014 22:15:47 -0400 To: "Richer, Justin P." Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/O47xT7edI5M9nKk1eZ5uQq0iz0I Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements 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, 09 Jul 2014 02:16:04 -0000 --Apple-Mail-24F48F2C-77AA-4DFE-A39F-D791537AA89A Content-Type: multipart/alternative; boundary=Apple-Mail-A1C87C0E-9D48-4666-8ABC-5DA47345974B Content-Transfer-Encoding: 7bit --Apple-Mail-A1C87C0E-9D48-4666-8ABC-5DA47345974B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes that is reasonable. =20 Sent from my iPhone > On Jul 8, 2014, at 9:44 PM, "Richer, Justin P." wrote:= >=20 > In draft -18, we clarified the optionality of the client metadata paramete= rs in =C2=A7 2 with new text, including the sentences: >=20 > The implementation and use of all client metadata fields is OPTIONAL, othe= r than "redirect_uris". >=20 > redirect_uris (...) Authorization servers MUST implement support for this m= etadata value. >=20 >=20 > However, since OAuth core defines two non-redirect flows (client credentia= ls and password) and we're about to publish another one (assertions), I sugg= est that we adopt the following clarification: >=20 > The implementation and use of all client metadata fields is OPTIONAL, othe= r than "redirect_uris" > which is REQUIRED for authorization servers that support redirect-based gr= ant types. >=20 > Authorization servers that support dynamic registration of clients using r= edirect-based > grant types MUST implement support for this metadata value. >=20 > I think this language brings the requirement more in line with the intent a= nd would like comment from the WG. >=20 > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-A1C87C0E-9D48-4666-8ABC-5DA47345974B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes that is reasonable.  

= Sent from my iPhone

On Jul 8, 2014, at 9:44 PM, "Richer, Justi= n P." <jricher@mitre.org> wro= te:

In draft -18, we clarified the optionality of the client metadata parameters= in =C2=A7 2 with new text, including the sentences: 

The implementation and use of all client metadata fie=
lds is OPTIONAL, other than "redirect_uris".

redirect_uris (...) Authorization servers MUST implem=
ent support for this metadata value.


However, since OAuth core defines two non-redirect flows (client creden= tials and password) and we're about to publish another one (assertions), I s= uggest that we adopt the following clarification:

The implementation and use of all client metadata fie=
lds is OPTIONAL, other than "redirect_uris"
which is REQUIRED for authorization servers that supp=
ort redirect-based grant types.

Authorization servers that support dynamic registrati=
on of clients using redirect-based
grant types MUST implement support for this metadata v=
alue.

I think this language brings the requirement more in line with the inte= nt and would like comment from the WG.

 -- Justin
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-A1C87C0E-9D48-4666-8ABC-5DA47345974B-- --Apple-Mail-24F48F2C-77AA-4DFE-A39F-D791537AA89A Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNzA5MDIxNTQ4WjAjBgkqhkiG9w0BCQQxFgQUQoW0wlRUZ1NLaVUn ebMj/KSeXZAwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAAYuh781w9H08cQ6MAihXKAvpTVEDrzLuJHT5XYEE4aS40mNT jByUc0NU8PwpS2s62taoLQxEj+Atg5mqv6qBtm3f3oKtCTqPrR+HUH4S4wDaqO7dvV9awLyjEZYR czBH8Ky6jlv8SDs7hi2mPU/dXeznwwOlLZ5a0g795eiWlCqREWjlHXAtuNy79uOlmOuCeXOkDH4U 4oZModOuBe3TJfUBjbNWIp/cIJaPZNg9GdK6X8FTzcChQjKWg9KSDO1QqiKz+ayw0oPNq5zynj0V Z8feNWRi74i6BJ1xqtUHA02ApiTRfH0C2WUQSobIUb159DZPVdnMRv31S1OOItffmgAAAAAAAA== --Apple-Mail-24F48F2C-77AA-4DFE-A39F-D791537AA89A-- From nobody Tue Jul 8 19:20:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F350B1A0298 for ; Tue, 8 Jul 2014 19:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, 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 nifppqQDUDOs for ; Tue, 8 Jul 2014 19:20:31 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5D21A0295 for ; Tue, 8 Jul 2014 19:20:30 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id k15so5525276qaq.16 for ; Tue, 08 Jul 2014 19:20: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:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=7xiJaIY47L7GjRbz/P6meEaig9cfJfcdWJvuV1+BeCA=; b=l553V5EJ5tX+i/1PTmN6GBmqFcGewRr4BcUBL1DLDUS5LizkhO2OuJ9NFBlJj++ud1 ePAnwe3DMf9c9I7rEBe2XLLrWD0RWMIvWb6rQ6VDVEVu9Nn0t59Um36iXxF4+3JXifBq 5Rmmq4NgpX3Iv9jM9zzwL4yKZi9ddtQDFEbZe0txbayL/L/nv1bGcM3ZkMCkSk+JVj3v Yr9BI59VuhHcHHThZE/o1QDmSCeD9uSCaqhQCvHBfR/SwUnYztiqqu/PsX4gXPHCELdx xVtVlEbz5TwWYp4DjmAK/kgzrf5B7ND86GEOk9eFrTLlOSfcU5NV/jX18KXBwG41ngyg dkqQ== X-Gm-Message-State: ALoCoQlQnu0L1SRHuJG4jGbFnWtT63fhi8qXWP9RrLaMIKE3ZJhMN+mJdxsRcQ+1WLFkn41dtXzq X-Received: by 10.224.112.131 with SMTP id w3mr68745166qap.68.1404872429790; Tue, 08 Jul 2014 19:20:29 -0700 (PDT) Received: from [192.168.1.38] (186-79-213-173.baf.movistar.cl. [186.79.213.173]) by mx.google.com with ESMTPSA id z14sm83878263qaw.7.2014.07.08.19.20.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 19:20:28 -0700 (PDT) References: <53BBDBEE.703@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9113A546-7375-4F9C-98BC-A29A8A279E4F; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <910A58F9-03A4-46C5-B3D2-89BEF8D669A1@ve7jtb.com> X-Mailer: iPhone Mail (11D257) From: John Bradley Date: Tue, 8 Jul 2014 22:20:14 -0400 To: Mike Jones Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Osy3aQ-zd35B4lxHOG9cbMtgalw Cc: Maciej Machulak , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 09 Jul 2014 02:20:35 -0000 --Apple-Mail-9113A546-7375-4F9C-98BC-A29A8A279E4F Content-Type: multipart/alternative; boundary=Apple-Mail-934AD46E-0EB3-4E5A-BCF5-B7ED46544621 Content-Transfer-Encoding: 7bit --Apple-Mail-934AD46E-0EB3-4E5A-BCF5-B7ED46544621 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes Nat and I mentioned the need for attribution to Hannes.=20 Having that also helps clarify the relationship between the specs for reader= s.=20 Sent from my iPhone > On Jul 8, 2014, at 10:14 PM, Mike Jones wrot= e: >=20 > Thinking about this some more, there is one IPR issue that we need to addr= ess before publication. This specification is a derivative work from the Op= enID Connect Dynamic Registration specification http://openid.net/specs/open= id-connect-registration-1_0.html. Large portions of the text were copied wh= olesale from that spec to this one, so that the two would be compatible. (T= his is good thing =E2=80=93 not a bad thing.) > =20 > This is easy to address from an IPR perspective =E2=80=93 simply acknowled= ge that this spec is a derivative work and provide proper attribution. The O= penID copyright in the spec at http://openid.net/specs/openid-connect-regist= ration-1_0.html#Notices allows for this resolution. It says: > =20 > Copyright (c) 2014 The OpenID Foundation. > The OpenID Foundation (OIDF) grants to any Contributor, developer, impleme= nter, or other interested party a non-exclusive, royalty free, worldwide cop= yright license to reproduce, prepare derivative works from, distribute, perf= orm and display, this Implementers Draft or Final Specification solely for t= he purposes of (i) developing specifications, and (ii) implementing Implemen= ters Drafts and Final Specifications based on such documents, provided that a= ttribution be made to the OIDF as the source of the material, but that such a= ttribution does not indicate an endorsement by the OIDF. > Let=E2=80=99s add the reference and acknowledgment in the next version. > =20 > -- Mike > =20 > From: Mike Jones=20 > Sent: Tuesday, July 08, 2014 10:06 AM > To: Phil Hunt; Hannes Tschofenig > Cc: John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org > Subject: RE: Dynamic Client Registration: IPR Confirmation > =20 > I likewise do not hold any IPR on these specs. > From: Phil Hunt > Sent: =E2=80=8E7/=E2=80=8E8/=E2=80=8E2014 9:11 AM > To: Hannes Tschofenig > Cc: Mike Jones; John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.o= rg > Subject: Re: Dynamic Client Registration: IPR Confirmation >=20 > I confirm I have no IPR disclosures on this document.=20 >=20 > Phil >=20 > > On Jul 8, 2014, at 4:54, Hannes Tschofenig w= rote: > >=20 > > Hi Phil, John, Maciej, Justin, Mike, > >=20 > > I am working on the shepherd writeup for the dynamic client registration= > > document and 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. > >=20 > > Could you please confirm? > >=20 > > Ciao > > Hannes > >=20 > > --Apple-Mail-934AD46E-0EB3-4E5A-BCF5-B7ED46544621 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes Nat and I mentioned the need for a= ttribution to Hannes. 

Having that also helps c= larify the relationship between the specs for readers. 

Sent fro= m my iPhone

On Jul 8, 2014, at 10:14 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:

Thinking about this some mo= re, there is one IPR issue that we need to address before publication. = This specification is a derivative work from the OpenID Connect Dynamic Registration specification http://openid.net/specs/openid-connect-registration-1_0.html.  Larg= e portions of the text were copied wholesale from that spec to this one, so t= hat the two would be compatible.  (This is good thing =E2=80=93 not a b= ad thing.)

 

This is easy to address fro= m an IPR perspective =E2=80=93 simply acknowledge that this spec is a deriva= tive work and provide proper attribution.  The OpenID copyright in the spec at http://openid.net/specs/openid-connect-registration-1_0.html#Notices all= ows for this resolution.  It says:

 

Copyright (c) 2014 The OpenID Foundation.=

The OpenID Foundation (OIDF) grants to any Contribut= or, developer, implementer, or other interested party a non-exclusive, royal= ty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implem= enters Draft or Final Specification solely for the purposes of (i) developin= g specifications, and (ii) implementing Implementers Drafts and Final Specif= ications based on such documents, provided that attribution be made to the OIDF as the source of the material= , but that such attribution does not indicate an endorsement by the OIDF.

Let=E2=80=99s add the refer= ence and acknowledgment in the next version.

 

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

 

From: Mike Jones
Sent: Tuesday, July 08, 2014 10:06 AM
To: Phil Hunt; Hannes Tschofenig
Cc: John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org
Subject: RE: Dynamic Client Registration: IPR Confirmation=

 

I likewise do not hold any IPR on these s= pecs.

From: Phil Hunt=
Sent: =E2=80=8E7/=E2=80=8E8/=E2=80=8E2014 9:11 AM
To: Hannes Tschofenig
Cc: Mike Jones; John Bradley; Justin Richer; Maciej Machulak= ; oauth@ietf.org
Subject: Re: Dynamic Client Registration: IPR Confirmation

I confirm I have no I= PR disclosures on this document.

Phil

> On Jul 8, 2014, at 4:54, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
> Hi Phil, John, Maciej, Justin, Mike,
>
> I am working on the shepherd writeup for the dynamic client registratio= n
> document and 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?
>
> Ciao
> Hannes
>
>

= --Apple-Mail-934AD46E-0EB3-4E5A-BCF5-B7ED46544621-- --Apple-Mail-9113A546-7375-4F9C-98BC-A29A8A279E4F Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNzA5MDIyMDE0WjAjBgkqhkiG9w0BCQQxFgQUbGpdjSI4QPWAvFoY R8T7DTxJaokwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAFugkjb53f7XX282pCm5FPJFFIgx09Lnn2wUVI7TzifVFvRRf kpSx6V/WHoamxzUXMaLWfA6vdHHYYxJW2BQxB5jf7r7RZE5WnrEwxrljEqatCTISMu6aLm3jm7/n LyjpWwBzwYx9BtNBSMP+in82bhkpE3WHgbDt0DkXCtC/5R18l+4vj5HqaOVnV3MbFM3km+IQv/1j SlHPyBFMsC0KmU3qo2dOBABIKZsZ932S5mvlCQBDTiKCujJp6vHsApdPPG+17SFIzF81nDfF+H/0 PdK2SMWMdslxUPv1G2+nbTG54lUnPRVZetqX7viDu+5eOS4GdVO7G53RafsqBD9nnwAAAAAAAA== --Apple-Mail-9113A546-7375-4F9C-98BC-A29A8A279E4F-- From nobody Tue Jul 8 19:23:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914C91A02BA for ; Tue, 8 Jul 2014 19:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcEHUsNyq5s1 for ; Tue, 8 Jul 2014 19:23:25 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2BD1A02A3 for ; Tue, 8 Jul 2014 19:23:24 -0700 (PDT) Received: from BY2PR03CA033.namprd03.prod.outlook.com (10.242.234.154) by BLUPR03MB135.namprd03.prod.outlook.com (10.255.212.21) with Microsoft SMTP Server (TLS) id 15.0.974.11; Wed, 9 Jul 2014 02:23:23 +0000 Received: from BN1AFFO11FD048.protection.gbl (2a01:111:f400:7c10::132) by BY2PR03CA033.outlook.office365.com (2a01:111:e400:2c2c::26) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Wed, 9 Jul 2014 02:23:22 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD048.mail.protection.outlook.com (10.58.53.63) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 9 Jul 2014 02:23:21 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0195.002; Wed, 9 Jul 2014 02:22:51 +0000 From: Mike Jones To: "Richer, Justin P." , "oauth@ietf.org list" Thread-Topic: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements Thread-Index: AQHPmxdGXSqb6uV98kqyx+t2wL0I1puXAgUg Date: Wed, 9 Jul 2014 02:22:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA17D7@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <4D1EA5D2-8862-47FD-8C17-D74C88287F87@mitre.org> In-Reply-To: <4D1EA5D2-8862-47FD-8C17-D74C88287F87@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADA17D7TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(377454003)(189002)(199002)(55885003)(19300405004)(64706001)(80022001)(26826002)(84676001)(83322001)(86362001)(74502001)(15975445006)(66066001)(84326002)(19625215002)(86612001)(99396002)(71186001)(20776003)(46102001)(74662001)(81542001)(76482001)(31966008)(77096002)(104016002)(83072002)(2656002)(81342001)(4396001)(551544002)(95666004)(76176999)(19580405001)(6806004)(87936001)(85306003)(106116001)(16236675004)(15202345003)(106466001)(33656002)(69596002)(54356999)(68736004)(92726001)(92566001)(512934002)(50986999)(107046002)(55846006)(85852003)(44976005)(79102001)(21056001)(81156004)(107886001)(97736001)(19580395003)(77982001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB135; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0267E514F9 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/XeWHeJSTHmWohrGOnpsZiwFEhck Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements 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, 09 Jul 2014 02:23:29 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADA17D7TK5EX14MBXC294r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That's close but not quite right, since use is required by clients when usi= ng redirect-based grant types. We could however, use this language: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support and clients that u= se redirect-based grant types. redirect_uris (...) Authorization servers that support dynamic registration= of clients using redirect-based grant types MUST implement support for this metadata value and clients that= use redirect-based grant types MUST use this parameter. -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P. Sent: Tuesday, July 08, 2014 6:44 PM To: oauth@ietf.org list Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata requir= ements In draft -18, we clarified the optionality of the client metadata parameter= s in =A7 2 with new text, including the sentences: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris". redirect_uris (...) Authorization servers MUST implement support for this m= etadata value. However, since OAuth core defines two non-redirect flows (client credential= s and password) and we're about to publish another one (assertions), I sugg= est that we adopt the following clarification: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support redirect-based gra= nt types. Authorization servers that support dynamic registration of clients using re= direct-based grant types MUST implement support for this metadata value. I think this language brings the requirement more in line with the intent a= nd would like comment from the WG. -- Justin --_000_4E1F6AAD24975D4BA5B16804296739439ADA17D7TK5EX14MBXC294r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

That’s close but no= t quite right, since use is required by clients when using redirect-based g= rant types.  We could however, use this language:

 <= /p> 

The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"
which is REQUIRED for authorization servers that support and clients t=
hat use redirect-based grant types.
 
redirect_uris (...) Authorization servers that support dynamic registr=
ation of clients using redirect-based
grant types MUST implement support for this metadata value and clients=
 that use redirect-based grant types MUST use this parameter.

 <=
/p>

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


 <=
/p>

 <=
/p>





From: OAuth [m=
ailto:oauth-bounces@ietf.org]
On Behalf Of Richer, Justin P.

Sent: Tuesday, July 08, 2014 6:44 PM

To: oauth@ietf.org list

Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata=
 requirements






 


In draft -18, we clarified the optionality of the cl=
ient metadata parameters in =A7 2 with new text, including the sentences:





 








The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris".








 


redirect_uris (...) Authorization servers MUST implement support for t=
his metadata value.












 








 






However, since OAuth core defines two non-redirect f=
lows (client credentials and password) and we're about to publish another o=
ne (assertions), I suggest that we adopt the following clarification:<=
/o:p>






 










The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"


which is REQUIRED for authorization servers that support redirect-base=
d grant types.










 








Authorization servers that support dynamic registration of clients usi=
ng redirect-based


grant types MUST implement support for this metadata value.=











 








I think this language brings the requirement more in=
 line with the intent and would like comment from the WG.






 






 -- Justin
--_000_4E1F6AAD24975D4BA5B16804296739439ADA17D7TK5EX14MBXC294r_-- From nobody Tue Jul 8 20:39:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F921A0302 for ; Tue, 8 Jul 2014 20:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 5TKNIdrCtuFK for ; Tue, 8 Jul 2014 20:39:10 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D08751A0301 for ; Tue, 8 Jul 2014 20:39:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5460F1F0427; Tue, 8 Jul 2014 23:39:09 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 420801F03E4; Tue, 8 Jul 2014 23:39:09 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.118]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 8 Jul 2014 23:39:09 -0400 From: "Richer, Justin P." To: Mike Jones Thread-Topic: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements Thread-Index: AQHPmydWLeZkhIqV8kS4GUE/fglCmQ== Date: Wed, 9 Jul 2014 03:39:07 +0000 Message-ID: <4A01E809-C4B5-4E5E-999C-C94042290B87@mitre.org> References: <4D1EA5D2-8862-47FD-8C17-D74C88287F87@mitre.org> <4E1F6AAD24975D4BA5B16804296739439ADA17D7@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA17D7@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.9.185] Content-Type: multipart/alternative; boundary="_000_4A01E809C4B54E5E999CC94042290B87mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TQiRCgcpATjVthq8hZZHTrX4_7U Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements 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, 09 Jul 2014 03:39:12 -0000 --_000_4A01E809C4B54E5E999CC94042290B87mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I can see where you're going with it. Requiring clients to use it implies t= hat servers need to enforce it. In the security considerations we currently= have: For clients that use redirect-based grant types such as "authorization_code" and "implicit", authorization servers MUST require clients to register their "redirect_uri" values. This can help mitigate attacks where rogue actors inject and impersonate a validly registered client and intercept its authorization code or tokens through an invalid redirection URI or open redirector. However, in previous versions up to -17, this was a SHOULD, not a MUST. Thi= s is a normative requirement change for server implementors and I want to m= ake sure everyone realizes was made. As of a handful of versions ago, our s= erver started to enforce this anyway. What have other developers done with = this, and would it be difficult to comply with the new requirement? -- Justin On Jul 8, 2014, at 10:22 PM, Mike Jones > wrote: That=92s close but not quite right, since use is required by clients when u= sing redirect-based grant types. We could however, use this language: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support and clients that u= se redirect-based grant types. redirect_uris (...) Authorization servers that support dynamic registration= of clients using redirect-based grant types MUST implement support for this metadata value and clients that= use redirect-based grant types MUST use this parameter. -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P. Sent: Tuesday, July 08, 2014 6:44 PM To: oauth@ietf.org list Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata requir= ements In draft -18, we clarified the optionality of the client metadata parameter= s in =A7 2 with new text, including the sentences: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris". redirect_uris (...) Authorization servers MUST implement support for this m= etadata value. However, since OAuth core defines two non-redirect flows (client credential= s and password) and we're about to publish another one (assertions), I sugg= est that we adopt the following clarification: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support redirect-based gra= nt types. Authorization servers that support dynamic registration of clients using re= direct-based grant types MUST implement support for this metadata value. I think this language brings the requirement more in line with the intent a= nd would like comment from the WG. -- Justin --_000_4A01E809C4B54E5E999CC94042290B87mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2FBF16701A48F64098910A8F580B94D5@imc.mitre.org> Content-Transfer-Encoding: quoted-printable I can see where you're going with it. Requiring clients to use it implies t= hat servers need to enforce it. In the security considerations we currently= have: 

   For clients that use redirect-based grant types s=
uch as
   "authorization_code" and "implicit", authorization s=
ervers MUST
   require clients to register their "redirect_uri" values.  This=
 can
   help mitigate attacks where rogue actors inject and impersonate a
   validly registered client and intercept its authorization code or
   tokens through an invalid redirection URI or open redirector.

However, in previous versions up to -17, this was a SHOULD, not a MUST= . This is a normative requirement change for server implementors and I want= to make sure everyone realizes was made. As of a handful of versions ago, = our server started to enforce this anyway. What have other developers done with this, and would it be difficu= lt to comply with the new requirement?

 -- Justin

On Jul 8, 2014, at 10:22 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

That=92s close but not qu= ite right, since use is required by clients when using redirect-based grant= types.  We could however, use this language:

 

The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"
which is REQUIRED for authorization servers that support and clients t=
hat use redirect-based grant types.
 
redirect_uris (...) Authorization servers that support dynamic registr=
ation of clients using redirect-based
grant types MUST implement support for this metadata value and clients=
 that use redirect-based grant types MUST use this parameter.

 


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


 


 






From: OAuth [<=
a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org]
On Behalf Of Richer, Justin P.

Sent: Tuesday, July 08, 2014 6:44 PM

To: oauth@ietf.org list

Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata=
 requirements






 


In draft -18, we clarified the optionality of the cl=
ient metadata parameters in =A7 2 with new text, including the sentences:





 








The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris".








 


redirect_uris (...) Authorization servers MUST implement support for t=
his metadata value.












 








 






However, since OAuth core defines two non-redirect f=
lows (client credentials and password) and we're about to publish another o=
ne (assertions), I suggest that we adopt the following clarification:<=
/o:p>






 










The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"


which is REQUIRED for authorization servers that support redirect-base=
d grant types.










 








Authorization servers that support dynamic registration of clients usi=
ng redirect-based


grant types MUST implement support for this metadata value.=











 








I think this language brings the requirement more in=
 line with the intent and would like comment from the WG.






 






 -- Justin

--_000_4A01E809C4B54E5E999CC94042290B87mitreorg_-- From nobody Tue Jul 8 20:41:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50F31A0317 for ; Tue, 8 Jul 2014 20:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 IxvSVEHyJPgW for ; Tue, 8 Jul 2014 20:41:15 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA801A0302 for ; Tue, 8 Jul 2014 20:41:15 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0E8B21F046F; Tue, 8 Jul 2014 23:41:15 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E2C261F03E4; Tue, 8 Jul 2014 23:41:14 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.118]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Tue, 8 Jul 2014 23:41:14 -0400 From: "Richer, Justin P." To: Mike Jones Thread-Topic: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements Thread-Index: AQHPmydWLeZkhIqV8kS4GUE/fglCmZuXW/+A Date: Wed, 9 Jul 2014 03:41:13 +0000 Message-ID: References: <4D1EA5D2-8862-47FD-8C17-D74C88287F87@mitre.org> <4E1F6AAD24975D4BA5B16804296739439ADA17D7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4A01E809-C4B5-4E5E-999C-C94042290B87@mitre.org> In-Reply-To: <4A01E809-C4B5-4E5E-999C-C94042290B87@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.9.185] Content-Type: multipart/alternative; boundary="_000_E3ED5C75B84146CCB207752A68861B47mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/PyXv60BLAIq-rBqyJWHEcG8BuFM Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements 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, 09 Jul 2014 03:41:18 -0000 --_000_E3ED5C75B84146CCB207752A68861B47mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Also, I just noticed that paragraph has a typo: "redirect_uri" should be "r= edirect_uris". -- Justin On Jul 8, 2014, at 11:39 PM, Justin Richer > wrote: I can see where you're going with it. Requiring clients to use it implies t= hat servers need to enforce it. In the security considerations we currently= have: For clients that use redirect-based grant types such as "authorization_code" and "implicit", authorization servers MUST require clients to register their "redirect_uri" values. This can help mitigate attacks where rogue actors inject and impersonate a validly registered client and intercept its authorization code or tokens through an invalid redirection URI or open redirector. However, in previous versions up to -17, this was a SHOULD, not a MUST. Thi= s is a normative requirement change for server implementors and I want to m= ake sure everyone realizes was made. As of a handful of versions ago, our s= erver started to enforce this anyway. What have other developers done with = this, and would it be difficult to comply with the new requirement? -- Justin On Jul 8, 2014, at 10:22 PM, Mike Jones > wrote: That=92s close but not quite right, since use is required by clients when u= sing redirect-based grant types. We could however, use this language: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support and clients that u= se redirect-based grant types. redirect_uris (...) Authorization servers that support dynamic registration= of clients using redirect-based grant types MUST implement support for this metadata value and clients that= use redirect-based grant types MUST use this parameter. -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P. Sent: Tuesday, July 08, 2014 6:44 PM To: oauth@ietf.org list Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata requir= ements In draft -18, we clarified the optionality of the client metadata parameter= s in =A7 2 with new text, including the sentences: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris". redirect_uris (...) Authorization servers MUST implement support for this m= etadata value. However, since OAuth core defines two non-redirect flows (client credential= s and password) and we're about to publish another one (assertions), I sugg= est that we adopt the following clarification: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support redirect-based gra= nt types. Authorization servers that support dynamic registration of clients using re= direct-based grant types MUST implement support for this metadata value. I think this language brings the requirement more in line with the intent a= nd would like comment from the WG. -- Justin --_000_E3ED5C75B84146CCB207752A68861B47mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <20EBBE3A649A254AB2C1571FF5988F70@imc.mitre.org> Content-Transfer-Encoding: quoted-printable Also, I just noticed that paragraph has a typo: "redirect_uri" sh= ould be "redirect_uris".

 -- Justin

On Jul 8, 2014, at 11:39 PM, Justin Richer <jricher@mitre.org> wrote:

I can see where you're going with it. Requiring clients to use it implies t= hat servers need to enforce it. In the security considerations we currently= have: 

   For clients that use redirect-based grant types s=
uch as
   "authorization_code" and "implicit", authorization s=
ervers MUST
   require clients to register their "redirect_uri" values.  This=
 can
   help mitigate attacks where rogue actors inject and impersonate a
   validly registered client and intercept its authorization code or
   tokens through an invalid redirection URI or open redirector.

However, in previous versions up to -17, this was a SHOULD, not a MUST= . This is a normative requirement change for server implementors and I want= to make sure everyone realizes was made. As of a handful of versions ago, = our server started to enforce this anyway. What have other developers done with this, and would it be difficu= lt to comply with the new requirement?

 -- Justin

On Jul 8, 2014, at 10:22 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

That=92s close but not qu= ite right, since use is required by clients when using redirect-based grant= types.  We could however, use this language:

 
The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"
which is REQUIRED for authorization servers that support and clients t=
hat use redirect-based grant types.
 
redirect_uris (...) Authorization servers that support dynamic registr=
ation of clients using redirect-based
grant types MUST implement support for this metadata value and clients=
 that use redirect-based grant types MUST use this parameter.

 




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


 




 








From: OAuth [<=
a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org]
On Behalf Of Richer, Justin P.

Sent: Tuesday, July 08, 2014 6:44 PM

To: oauth@ietf.org list

Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata=
 requirements






 


In draft -18, we clarified the optionality of the cl=
ient metadata parameters in =A7 2 with new text, including the sentences:





 








The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris".








 


redirect_uris (...) Authorization servers MUST implement support for t=
his metadata value.












 








 






However, since OAuth core defines two non-redirect f=
lows (client credentials and password) and we're about to publish another o=
ne (assertions), I suggest that we adopt the following clarification:<=
/o:p>






 










The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"


which is REQUIRED for authorization servers that support redirect-base=
d grant types.










 








Authorization servers that support dynamic registration of clients usi=
ng redirect-based


grant types MUST implement support for this metadata value.=











 








I think this language brings the requirement more in=
 line with the intent and would like comment from the WG.






 






 -- Justin


--_000_E3ED5C75B84146CCB207752A68861B47mitreorg_-- From nobody Tue Jul 8 20:45:51 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF26F1A0302 for ; Tue, 8 Jul 2014 20:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcECziHvyvUt for ; Tue, 8 Jul 2014 20:45:41 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69801A030B for ; Tue, 8 Jul 2014 20:45:41 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s693jekS009457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jul 2014 03:45:41 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s693jdJO029957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Jul 2014 03:45:40 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s693jd7r029946; Wed, 9 Jul 2014 03:45:39 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jul 2014 20:45:38 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_1A9883DB-A6CC-4E4D-A23D-6DE76329A342" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <4A01E809-C4B5-4E5E-999C-C94042290B87@mitre.org> Date: Tue, 8 Jul 2014 20:45:36 -0700 Message-Id: References: <4D1EA5D2-8862-47FD-8C17-D74C88287F87@mitre.org> <4E1F6AAD24975D4BA5B16804296739439ADA17D7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4A01E809-C4B5-4E5E-999C-C94042290B87@mitre.org> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_A2ztbJXBFWh-X9JbVK29zyYPnI Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements 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, 09 Jul 2014 03:45:48 -0000 --Apple-Mail=_1A9883DB-A6CC-4E4D-A23D-6DE76329A342 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 What about the whole issue of redirect_uri fragments?=20 Are there any issues where a client for some reason can=92t register a = perm URI at registration time? Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 8, 2014, at 8:39 PM, Richer, Justin P. wrote: > I can see where you're going with it. Requiring clients to use it = implies that servers need to enforce it. In the security considerations = we currently have: >=20 > For clients that use redirect-based grant types such as > "authorization_code" and "implicit", authorization servers MUST > require clients to register their "redirect_uri" values. This can > help mitigate attacks where rogue actors inject and impersonate a > validly registered client and intercept its authorization code or > tokens through an invalid redirection URI or open redirector. >=20 > However, in previous versions up to -17, this was a SHOULD, not a = MUST. This is a normative requirement change for server implementors and = I want to make sure everyone realizes was made. As of a handful of = versions ago, our server started to enforce this anyway. What have other = developers done with this, and would it be difficult to comply with the = new requirement? >=20 > -- Justin >=20 > On Jul 8, 2014, at 10:22 PM, Mike Jones = wrote: >=20 >> That=92s close but not quite right, since use is required by clients = when using redirect-based grant types. We could however, use this = language: >> =20 >> The implementation and use of all client metadata fields is OPTIONAL, = other than "redirect_uris" >> which is REQUIRED for authorization servers that support and clients = that use redirect-based grant types. >> =20 >> redirect_uris (...) Authorization servers that support dynamic = registration of clients using redirect-based >> grant types MUST implement support for this metadata value and = clients that use redirect-based grant types MUST use this parameter. >> =20 >> -- Mike >> =20 >> =20 >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, = Justin P. >> Sent: Tuesday, July 08, 2014 6:44 PM >> To: oauth@ietf.org list >> Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata = requirements >> =20 >> In draft -18, we clarified the optionality of the client metadata = parameters in =A7 2 with new text, including the sentences: >> =20 >> The implementation and use of all client metadata fields is OPTIONAL, = other than "redirect_uris". >> =20 >> redirect_uris (...) Authorization servers MUST implement support for = this metadata value. >> =20 >> =20 >> However, since OAuth core defines two non-redirect flows (client = credentials and password) and we're about to publish another one = (assertions), I suggest that we adopt the following clarification: >> =20 >> The implementation and use of all client metadata fields is OPTIONAL, = other than "redirect_uris" >> which is REQUIRED for authorization servers that support = redirect-based grant types. >> =20 >> Authorization servers that support dynamic registration of clients = using redirect-based >> grant types MUST implement support for this metadata value. >> =20 >> I think this language brings the requirement more in line with the = intent and would like comment from the WG. >> =20 >> -- Justin >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_1A9883DB-A6CC-4E4D-A23D-6DE76329A342 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 What = about the whole issue of redirect_uri = fragments? 

Are there any issues where a client = for some reason can=92t register a perm URI at registration = time?


On Jul 8, 2014, at 8:39 PM, Richer, Justin P. <jricher@mitre.org> = wrote:

I can see where you're going with it. Requiring clients to use it = implies that servers need to enforce it. In the security considerations = we currently have: 

   For clients that use redirect-based grant =
types such as
   "authorization_code" and "implicit", authorization servers MUST
   require clients to register their "redirect_uri" values.  This can
   help mitigate attacks where rogue actors inject and impersonate a
   validly registered client and intercept its authorization code or
   tokens through an invalid redirection URI or open redirector.

However, in previous versions up to -17, this was a SHOULD, not a = MUST. This is a normative requirement change for server implementors and = I want to make sure everyone realizes was made. As of a handful of = versions ago, our server started to enforce this anyway. What have other developers done with this, and would it be = difficult to comply with the new requirement?

 -- Justin

On Jul 8, 2014, at 10:22 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

That=92s close but not quite right, since use is = required by clients when using redirect-based grant types.  We = could however, use this language:

 
The implementation and use of all client metadata fields is =
OPTIONAL, other than "redirect_uris"
which is REQUIRED for authorization servers that support and =
clients that use redirect-based grant types.
 
redirect_uris (...) Authorization servers that support dynamic =
registration of clients using redirect-based
grant types MUST implement support for this metadata value and =
clients that use redirect-based grant types MUST use this =
parameter.
 

        &nbs= p;            =             &n= bsp;           &nbs= p;            =   -- Mike

 
 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P.
Sent: Tuesday, July 08, 2014 6:44 PM
To: oauth@ietf.org list
Subject: [OAUTH-WG] Dynamic Client Registration: comment on = metadata requirements

 

In draft -18, we clarified the optionality of the = client metadata parameters in =A7 2 with new text, including the = sentences:

 

The implementation and use of all client metadata fields is =
OPTIONAL, other than "redirect_uris".
 
redirect_uris (...) Authorization servers MUST implement support =
for this metadata value.

 

 

However, since OAuth core defines two = non-redirect flows (client credentials and password) and we're about to = publish another one (assertions), I suggest that we adopt the following = clarification:

 

The implementation and use of all client metadata fields is =
OPTIONAL, other than "redirect_uris"
which is REQUIRED for authorization servers that support =
redirect-based grant types.
 
Authorization servers that support dynamic registration of clients =
using redirect-based
grant types MUST implement support for this metadata =
value.

 

I think this language brings the requirement = more in line with the intent and would like comment from the = WG.

 

 -- Justin


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

= --Apple-Mail=_1A9883DB-A6CC-4E4D-A23D-6DE76329A342-- From nobody Tue Jul 8 20:52:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF7A1A02AC for ; Tue, 8 Jul 2014 20:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIhKALlC74M1 for ; Tue, 8 Jul 2014 20:51:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB0C1A0302 for ; Tue, 8 Jul 2014 20:51:56 -0700 (PDT) Received: from DM2PR03CA003.namprd03.prod.outlook.com (10.141.52.151) by BLUPR03MB341.namprd03.prod.outlook.com (10.141.48.12) with Microsoft SMTP Server (TLS) id 15.0.980.8; Wed, 9 Jul 2014 03:51:53 +0000 Received: from BY2FFO11FD004.protection.gbl (2a01:111:f400:7c0c::178) by DM2PR03CA003.outlook.office365.com (2a01:111:e400:2414::23) with Microsoft SMTP Server (TLS) id 15.0.980.8 via Frontend Transport; Wed, 9 Jul 2014 03:51:53 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 9 Jul 2014 03:51:52 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0195.002; Wed, 9 Jul 2014 03:51:16 +0000 From: Mike Jones To: "Richer, Justin P." Thread-Topic: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements Thread-Index: AQHPmydaA+CPPLHqa0u+y0gAU7CRiZuXGwSg Date: Wed, 9 Jul 2014 03:51:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA1BD5@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <4D1EA5D2-8862-47FD-8C17-D74C88287F87@mitre.org> <4E1F6AAD24975D4BA5B16804296739439ADA17D7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4A01E809-C4B5-4E5E-999C-C94042290B87@mitre.org> In-Reply-To: <4A01E809-C4B5-4E5E-999C-C94042290B87@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADA1BD5TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(377454003)(55885003)(24454002)(189002)(199002)(99396002)(97736001)(20776003)(54356999)(2656002)(76176999)(81542001)(74502001)(19580395003)(69596002)(26826002)(50986999)(87936001)(110136001)(68736004)(46102001)(77096002)(85306003)(15975445006)(551544002)(83322001)(84676001)(76482001)(107046002)(106116001)(15202345003)(74662001)(31966008)(80022001)(77982001)(21056001)(66066001)(55846006)(86612001)(71186001)(83072002)(92566001)(92726001)(84326002)(19580405001)(81156004)(86362001)(6806004)(106466001)(4396001)(79102001)(81342001)(95666004)(19300405004)(85852003)(19625215002)(64706001)(33656002)(16236675004)(44976005)(104016002)(512934002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB341; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0267E514F9 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/o5VRy3WHdTa2AaEidat59NQkWSk Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements 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, 09 Jul 2014 03:52:01 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADA1BD5TK5EX14MBXC294r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable According to RFC 6749, it must be a MUST. http://tools.ietf.org/html/rfc67= 49#section-2 says: When registering a client, the client developer SHALL: o provide its client redirection URIs as described in Section 3.1.2, SHALL doesn't fulfill this requirement. That's why I made the change when = doing the editorial work to say which metadata values are optional and whic= h are required. -- Mike From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Tuesday, July 08, 2014 8:39 PM To: Mike Jones Cc: oauth@ietf.org list Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata re= quirements I can see where you're going with it. Requiring clients to use it implies t= hat servers need to enforce it. In the security considerations we currently= have: For clients that use redirect-based grant types such as "authorization_code" and "implicit", authorization servers MUST require clients to register their "redirect_uri" values. This can help mitigate attacks where rogue actors inject and impersonate a validly registered client and intercept its authorization code or tokens through an invalid redirection URI or open redirector. However, in previous versions up to -17, this was a SHOULD, not a MUST. Thi= s is a normative requirement change for server implementors and I want to m= ake sure everyone realizes was made. As of a handful of versions ago, our s= erver started to enforce this anyway. What have other developers done with = this, and would it be difficult to comply with the new requirement? -- Justin On Jul 8, 2014, at 10:22 PM, Mike Jones > wrote: That's close but not quite right, since use is required by clients when usi= ng redirect-based grant types. We could however, use this language: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support and clients that u= se redirect-based grant types. redirect_uris (...) Authorization servers that support dynamic registration= of clients using redirect-based grant types MUST implement support for this metadata value and clients that= use redirect-based grant types MUST use this parameter. -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P. Sent: Tuesday, July 08, 2014 6:44 PM To: oauth@ietf.org list Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata requir= ements In draft -18, we clarified the optionality of the client metadata parameter= s in =A7 2 with new text, including the sentences: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris". redirect_uris (...) Authorization servers MUST implement support for this m= etadata value. However, since OAuth core defines two non-redirect flows (client credential= s and password) and we're about to publish another one (assertions), I sugg= est that we adopt the following clarification: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support redirect-based gra= nt types. Authorization servers that support dynamic registration of clients using re= direct-based grant types MUST implement support for this metadata value. I think this language brings the requirement more in line with the intent a= nd would like comment from the WG. -- Justin --_000_4E1F6AAD24975D4BA5B16804296739439ADA1BD5TK5EX14MBXC294r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

According to RFC 6749, it= must be a MUST.  http://tools.ietf.= org/html/rfc6749#section-2 says:

 <= /p>

   When registerin= g a client, the client developer SHALL:

 

   o  provide= its client redirection URIs as described in Section 3.1.2<= /a>,

 <= /p>

SHALL doesn’t fulfi= ll this requirement.  That’s why I made the change when doing th= e editorial work to say which metadata values are optional and which are required.

 <= /p>

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

 <= /p>

From: Richer, = Justin P. [mailto:jricher@mitre.org]
Sent: Tuesday, July 08, 2014 8:39 PM
To: Mike Jones
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on meta= data requirements

 

I can see where you're going with it. Requiring clie= nts to use it implies that servers need to enforce it. In the security cons= iderations we currently have:

 

   For clients that use redirect-based grant types such as
   "authorization_code" and "implicit", =
authorization servers MUST
   require clients to register their "redirect_uri"=
; values.  This can
   help mitigate attacks where rogue actors inject and imper=
sonate a
   validly registered client and intercept its authorization=
 code or
   tokens through an invalid redirection URI or open redirec=
tor.

 

However, in previous versions up to -17, this was a = SHOULD, not a MUST. This is a normative requirement change for server imple= mentors and I want to make sure everyone realizes was made. As of a handful= of versions ago, our server started to enforce this anyway. What have other developers done with this, and wou= ld it be difficult to comply with the new requirement?

 

 -- Justin

 



That’s close but no= t quite right, since use is required by clients when using redirect-based g= rant types.  We could however, use this language:

 <= /p> 

The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"
which is REQUIRED for authorization servers that support and clients t=
hat use redirect-based grant types.
 
redirect_uris (...) Authorization servers that support dynamic registr=
ation of clients using redirect-based
grant types MUST implement support for this metadata value and clients=
 that use redirect-based grant types MUST use this parameter.

 <=
/p>

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


 <=
/p>

 <=
/p>





From: OAuth [<=
a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org]
On Behalf Of Richer, Justin P.

Sent: Tuesday, July 08, 2014 6:44 PM

To: oauth@ietf.org list

Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata=
 requirements






 


In draft -18, we clarified the optionality of the cl=
ient metadata parameters in =A7 2 with new text, including the sentences:





 








The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris".








 


redirect_uris (...) Authorization servers MUST implement support for t=
his metadata value.












 








 






However, since OAuth core defines two non-redirect f=
lows (client credentials and password) and we're about to publish another o=
ne (assertions), I suggest that we adopt the following clarification:<=
/o:p>






 










The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"


which is REQUIRED for authorization servers that support redirect-base=
d grant types.










 








Authorization servers that support dynamic registration of clients usi=
ng redirect-based


grant types MUST implement support for this metadata value.=











 








I think this language brings the requirement more in=
 line with the intent and would like comment from the WG.






 






 -- Justin

 

--_000_4E1F6AAD24975D4BA5B16804296739439ADA1BD5TK5EX14MBXC294r_-- From nobody Tue Jul 8 20:52:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB941A031B for ; Tue, 8 Jul 2014 20:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5f7Mcma-HJp for ; Tue, 8 Jul 2014 20:52:33 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D971A0318 for ; Tue, 8 Jul 2014 20:52:33 -0700 (PDT) Received: from BLUPR03CA029.namprd03.prod.outlook.com (10.141.30.22) by SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) with Microsoft SMTP Server (TLS) id 15.0.974.11; Wed, 9 Jul 2014 03:52:32 +0000 Received: from BL2FFO11FD031.protection.gbl (2a01:111:f400:7c09::150) by BLUPR03CA029.outlook.office365.com (2a01:111:e400:879::22) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Wed, 9 Jul 2014 03:52:31 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD031.mail.protection.outlook.com (10.173.160.71) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 9 Jul 2014 03:52:31 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0195.002; Wed, 9 Jul 2014 03:52:22 +0000 From: Mike Jones To: "Richer, Justin P." Thread-Topic: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements Thread-Index: AQHPmydaA+CPPLHqa0u+y0gAU7CRiZuXGPOAgAAC5gA= Date: Wed, 9 Jul 2014 03:52:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA1C15@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <4D1EA5D2-8862-47FD-8C17-D74C88287F87@mitre.org> <4E1F6AAD24975D4BA5B16804296739439ADA17D7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4A01E809-C4B5-4E5E-999C-C94042290B87@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADA1C15TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(189002)(199002)(55885003)(24454002)(377454003)(26826002)(77982001)(15975445006)(19625215002)(19300405004)(81542001)(55846006)(77096002)(107046002)(19580395003)(15202345003)(19580405001)(83322001)(68736004)(110136001)(81342001)(74662001)(86362001)(76482001)(44976005)(87936001)(85306003)(71186001)(92566001)(2656002)(64706001)(6806004)(95666004)(16236675004)(86612001)(104016002)(81156004)(66066001)(4396001)(80022001)(20776003)(21056001)(33656002)(79102001)(106116001)(84326002)(76176999)(50986999)(54356999)(97736001)(31966008)(99396002)(74502001)(84676001)(69596002)(46102001)(92726001)(106466001)(512934002)(551544002)(85852003)(93886003)(83072002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB077; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0267E514F9 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/h_AaeBDnUhwzsYI8jdngAkBK-eg Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements 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, 09 Jul 2014 03:52:38 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADA1C15TK5EX14MBXC294r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This isn't a typo. They are registering their "redirect_uri" values. They= do so using the "redirect_uris" parameter. -- Mike From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Tuesday, July 08, 2014 8:41 PM To: Mike Jones Cc: oauth@ietf.org list Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata re= quirements Also, I just noticed that paragraph has a typo: "redirect_uri" should be "r= edirect_uris". -- Justin On Jul 8, 2014, at 11:39 PM, Justin Richer > wrote: I can see where you're going with it. Requiring clients to use it implies t= hat servers need to enforce it. In the security considerations we currently= have: For clients that use redirect-based grant types such as "authorization_code" and "implicit", authorization servers MUST require clients to register their "redirect_uri" values. This can help mitigate attacks where rogue actors inject and impersonate a validly registered client and intercept its authorization code or tokens through an invalid redirection URI or open redirector. However, in previous versions up to -17, this was a SHOULD, not a MUST. Thi= s is a normative requirement change for server implementors and I want to m= ake sure everyone realizes was made. As of a handful of versions ago, our s= erver started to enforce this anyway. What have other developers done with = this, and would it be difficult to comply with the new requirement? -- Justin On Jul 8, 2014, at 10:22 PM, Mike Jones > wrote: That's close but not quite right, since use is required by clients when usi= ng redirect-based grant types. We could however, use this language: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support and clients that u= se redirect-based grant types. redirect_uris (...) Authorization servers that support dynamic registration= of clients using redirect-based grant types MUST implement support for this metadata value and clients that= use redirect-based grant types MUST use this parameter. -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P. Sent: Tuesday, July 08, 2014 6:44 PM To: oauth@ietf.org list Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata requir= ements In draft -18, we clarified the optionality of the client metadata parameter= s in =A7 2 with new text, including the sentences: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris". redirect_uris (...) Authorization servers MUST implement support for this m= etadata value. However, since OAuth core defines two non-redirect flows (client credential= s and password) and we're about to publish another one (assertions), I sugg= est that we adopt the following clarification: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support redirect-based gra= nt types. Authorization servers that support dynamic registration of clients using re= direct-based grant types MUST implement support for this metadata value. I think this language brings the requirement more in line with the intent a= nd would like comment from the WG. -- Justin --_000_4E1F6AAD24975D4BA5B16804296739439ADA1C15TK5EX14MBXC294r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This isn’t a typo.&= nbsp; They are registering their “redirect_uri” values.  T= hey do so using the “redirect_uris” parameter.

 <= /p>

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

 <= /p>

From: Richer, = Justin P. [mailto:jricher@mitre.org]
Sent: Tuesday, July 08, 2014 8:41 PM
To: Mike Jones
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on meta= data requirements

 

Also, I just noticed that paragraph has a typo: &quo= t;redirect_uri" should be "redirect_uris".

 

 -- Justin

 

On Jul 8, 2014, at 11:39 PM, Justin Richer <jricher@mitre.org> wrote:=



I can see where you're going with it. Requiring clie= nts to use it implies that servers need to enforce it. In the security cons= iderations we currently have:

 

   For clients that use redirect-based grant types such as
   "authorization_code" and "implicit", =
authorization servers MUST
   require clients to register their "redirect_uri"=
; values.  This can
   help mitigate attacks where rogue actors inject and imper=
sonate a
   validly registered client and intercept its authorization=
 code or
   tokens through an invalid redirection URI or open redirec=
tor.

 

However, in previous versions up to -17, this was a = SHOULD, not a MUST. This is a normative requirement change for server imple= mentors and I want to make sure everyone realizes was made. As of a handful= of versions ago, our server started to enforce this anyway. What have other developers done with this, and wou= ld it be difficult to comply with the new requirement?

 

 -- Justin

 

On Jul 8, 2014, at 10:22 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:



That’s close but no= t quite right, since use is required by clients when using redirect-based g= rant types.  We could however, use this language:

 <= /p> 

The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"
which is REQUIRED for authorization servers that support and clients t=
hat use redirect-based grant types.
 
redirect_uris (...) Authorization servers that support dynamic registr=
ation of clients using redirect-based
grant types MUST implement support for this metadata value and clients=
 that use redirect-based grant types MUST use this parameter.



 <=
/p>



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




 <=
/p>





 <=
/p>







From: OAuth [<=
a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org]
On Behalf Of Richer, Justin P.

Sent: Tuesday, July 08, 2014 6:44 PM

To: oauth@ietf.org list

Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata=
 requirements






 


In draft -18, we clarified the optionality of the cl=
ient metadata parameters in =A7 2 with new text, including the sentences:





 








The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris".








 


redirect_uris (...) Authorization servers MUST implement support for t=
his metadata value.












 








 






However, since OAuth core defines two non-redirect f=
lows (client credentials and password) and we're about to publish another o=
ne (assertions), I suggest that we adopt the following clarification:<=
/o:p>






 










The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"


which is REQUIRED for authorization servers that support redirect-base=
d grant types.










 








Authorization servers that support dynamic registration of clients usi=
ng redirect-based


grant types MUST implement support for this metadata value.=











 








I think this language brings the requirement more in=
 line with the intent and would like comment from the WG.






 






 -- Justin

 

 

--_000_4E1F6AAD24975D4BA5B16804296739439ADA1C15TK5EX14MBXC294r_-- From nobody Tue Jul 8 20:57:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798C71A0305 for ; Tue, 8 Jul 2014 20:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 xOtpdryCXfU4 for ; Tue, 8 Jul 2014 20:56:58 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 72A4B1A0302 for ; Tue, 8 Jul 2014 20:56:58 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 147FA1F0493; Tue, 8 Jul 2014 23:56:58 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id F002F1F02A6; Tue, 8 Jul 2014 23:56:57 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.118]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Tue, 8 Jul 2014 23:56:57 -0400 From: "Richer, Justin P." To: Mike Jones Thread-Topic: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements Thread-Index: AQHPmydWLeZkhIqV8kS4GUE/fglCmZuXW/+AgAADH4CAAAFHgA== Date: Wed, 9 Jul 2014 03:56:56 +0000 Message-ID: References: <4D1EA5D2-8862-47FD-8C17-D74C88287F87@mitre.org> <4E1F6AAD24975D4BA5B16804296739439ADA17D7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4A01E809-C4B5-4E5E-999C-C94042290B87@mitre.org> <4E1F6AAD24975D4BA5B16804296739439ADA1C15@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA1C15@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.9.185] Content-Type: multipart/alternative; boundary="_000_E5B550A598C9461082BE737E71173BC6mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/AL1NokEb9Uhx8p8rqqch6v3zQQE Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements 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, 09 Jul 2014 03:57:01 -0000 --_000_E5B550A598C9461082BE737E71173BC6mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Well, I think it's confusing, then. To me, it reads like a typo since it's = formatted as a verb. I really think it should line up with the actual name = of the parameter, or it shouldn't be formatted as a verb. So I'd suggest ei= ther: register their "redirect_uris" value or: register their redirection URIs The latter probably reads better. -- Justin On Jul 8, 2014, at 11:52 PM, Mike Jones > wrote: This isn=92t a typo. They are registering their =93redirect_uri=94 values.= They do so using the =93redirect_uris=94 parameter. -- Mike From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Tuesday, July 08, 2014 8:41 PM To: Mike Jones Cc: oauth@ietf.org list Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata re= quirements Also, I just noticed that paragraph has a typo: "redirect_uri" should be "r= edirect_uris". -- Justin On Jul 8, 2014, at 11:39 PM, Justin Richer > wrote: I can see where you're going with it. Requiring clients to use it implies t= hat servers need to enforce it. In the security considerations we currently= have: For clients that use redirect-based grant types such as "authorization_code" and "implicit", authorization servers MUST require clients to register their "redirect_uri" values. This can help mitigate attacks where rogue actors inject and impersonate a validly registered client and intercept its authorization code or tokens through an invalid redirection URI or open redirector. However, in previous versions up to -17, this was a SHOULD, not a MUST. Thi= s is a normative requirement change for server implementors and I want to m= ake sure everyone realizes was made. As of a handful of versions ago, our s= erver started to enforce this anyway. What have other developers done with = this, and would it be difficult to comply with the new requirement? -- Justin On Jul 8, 2014, at 10:22 PM, Mike Jones > wrote: That=92s close but not quite right, since use is required by clients when u= sing redirect-based grant types. We could however, use this language: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support and clients that u= se redirect-based grant types. redirect_uris (...) Authorization servers that support dynamic registration= of clients using redirect-based grant types MUST implement support for this metadata value and clients that= use redirect-based grant types MUST use this parameter. -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P. Sent: Tuesday, July 08, 2014 6:44 PM To: oauth@ietf.org list Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata requir= ements In draft -18, we clarified the optionality of the client metadata parameter= s in =A7 2 with new text, including the sentences: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris". redirect_uris (...) Authorization servers MUST implement support for this m= etadata value. However, since OAuth core defines two non-redirect flows (client credential= s and password) and we're about to publish another one (assertions), I sugg= est that we adopt the following clarification: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support redirect-based gra= nt types. Authorization servers that support dynamic registration of clients using re= direct-based grant types MUST implement support for this metadata value. I think this language brings the requirement more in line with the intent a= nd would like comment from the WG. -- Justin --_000_E5B550A598C9461082BE737E71173BC6mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Well, I think it's confusing, then. To me, it reads like a typo since it's = formatted as a verb. I really think it should line up with the actual name = of the parameter, or it shouldn't be formatted as a verb. So I'd suggest ei= ther:

    register their "redirect_uris" value

or:

    register their redirection URIs


The latter probably reads better.

  -- Justin



On Jul 8, 2014, at 11:52 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

This isn=92t a typo. = ; They are registering their =93redirect_uri=94 values.  They do so us= ing the =93redirect_uris=94 parameter.

 

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

 

From: Richer, = Justin P. [mailto:jricher@mitre.org]
Sent: Tuesday, July 08, 2014 8:41 PM
To: Mike Jones
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on meta= data requirements

 

Also, I just noticed that paragraph has a typo: &quo= t;redirect_uri" should be "redirect_uris".

 

 -- Justin

 

On Jul 8, 2014, at 11:39 PM, Justin Richer <jricher@mitre.org> wrote:=



I can see where you're going with it. Requiring clie= nts to use it implies that servers need to enforce it. In the security cons= iderations we currently have:

 

   For clients that use redirect-based grant types such as
   "authorization_code" and "implicit", =
authorization servers MUST
   require clients to register their "redirect_uri"=
; values.  This can
   help mitigate attacks where rogue actors inject and imper=
sonate a
   validly registered client and intercept its authorization=
 code or
   tokens through an invalid redirection URI or open redirec=
tor.

 

However, in previous versions up to -17, this was a = SHOULD, not a MUST. This is a normative requirement change for server imple= mentors and I want to make sure everyone realizes was made. As of a handful= of versions ago, our server started to enforce this anyway. What have other developers done with this, and wou= ld it be difficult to comply with the new requirement?

 

 -- Justin

 

On Jul 8, 2014, at 10:22 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:



That=92s close but not qu= ite right, since use is required by clients when using redirect-based grant= types.  We could however, use this language:

 <= /p> 

The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"
which is REQUIRED for authorization servers that support and clients t=
hat use redirect-based grant types.
 
redirect_uris (...) Authorization servers that support dynamic registr=
ation of clients using redirect-based
grant types MUST implement support for this metadata value and clients=
 that use redirect-based grant types MUST use this parameter.



 <=
/p>



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




 <=
/p>





 <=
/p>







From: OAuth [<=
a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org]
On Behalf Of Richer, Justin P.

Sent: Tuesday, July 08, 2014 6:44 PM

To: oauth@ietf.org list

Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata=
 requirements






 


In draft -18, we clarified the optionality of the cl=
ient metadata parameters in =A7 2 with new text, including the sentences:





 








The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris".








 


redirect_uris (...) Authorization servers MUST implement support for t=
his metadata value.












 








 






However, since OAuth core defines two non-redirect f=
lows (client credentials and password) and we're about to publish another o=
ne (assertions), I suggest that we adopt the following clarification:<=
/o:p>






 










The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"


which is REQUIRED for authorization servers that support redirect-base=
d grant types.










 








Authorization servers that support dynamic registration of clients usi=
ng redirect-based


grant types MUST implement support for this metadata value.=











 








I think this language brings the requirement more in=
 line with the intent and would like comment from the WG.






 






 -- Justin

 

 


--_000_E5B550A598C9461082BE737E71173BC6mitreorg_-- From nobody Wed Jul 9 12:14:43 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7123C1A03D4 for ; Wed, 9 Jul 2014 12:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHT_dCV6WJIz for ; Wed, 9 Jul 2014 12:14:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6601A0390 for ; Wed, 9 Jul 2014 12:14:38 -0700 (PDT) Received: from BLUPR03CA029.namprd03.prod.outlook.com (10.141.30.22) by BLUPR03MB341.namprd03.prod.outlook.com (10.141.48.12) with Microsoft SMTP Server (TLS) id 15.0.980.8; Wed, 9 Jul 2014 19:14:28 +0000 Received: from BN1BFFO11FD056.protection.gbl (2a01:111:f400:7c10::1:147) by BLUPR03CA029.outlook.office365.com (2a01:111:e400:879::22) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Wed, 9 Jul 2014 19:14:28 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD056.mail.protection.outlook.com (10.58.145.11) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 9 Jul 2014 19:14:27 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0195.002; Wed, 9 Jul 2014 19:13:50 +0000 From: Mike Jones To: "Richer, Justin P." Thread-Topic: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements Thread-Index: AQHPmydaA+CPPLHqa0u+y0gAU7CRiZuXGPOAgAAC5gCAAAF/AIABAA6Q Date: Wed, 9 Jul 2014 19:13:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA28F8@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <4D1EA5D2-8862-47FD-8C17-D74C88287F87@mitre.org> <4E1F6AAD24975D4BA5B16804296739439ADA17D7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4A01E809-C4B5-4E5E-999C-C94042290B87@mitre.org> <4E1F6AAD24975D4BA5B16804296739439ADA1C15@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADA28F8TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(199002)(189002)(377454003)(55885003)(24454002)(66066001)(21056001)(86612001)(6806004)(106466001)(55846006)(31966008)(77982001)(80022001)(74662001)(85852003)(95666004)(44976005)(33656002)(64706001)(19625215002)(512934002)(104016003)(16236675004)(19580405001)(83072002)(92726001)(79102001)(4396001)(15202345003)(84326002)(86362001)(92566001)(81342001)(19300405004)(71186001)(81156004)(106116001)(19580395003)(74502001)(69596002)(20776003)(50986999)(97736001)(99396002)(76176999)(2656002)(54356999)(107046002)(81542001)(87936001)(26826002)(110136001)(84676001)(68736004)(46102001)(76482001)(551544002)(77096002)(15975445006)(83322001)(93886003)(85306003); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB341; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0267E514F9 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DywgQfSYNmqPUHSUWveg9fDkoZk Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements 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, 09 Jul 2014 19:14:42 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADA28F8TK5EX14MBXC294r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Using "redirection URIs" is fine with me. From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Tuesday, July 08, 2014 8:57 PM To: Mike Jones Cc: oauth@ietf.org list Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata re= quirements Well, I think it's confusing, then. To me, it reads like a typo since it's = formatted as a verb. I really think it should line up with the actual name = of the parameter, or it shouldn't be formatted as a verb. So I'd suggest ei= ther: register their "redirect_uris" value or: register their redirection URIs The latter probably reads better. -- Justin On Jul 8, 2014, at 11:52 PM, Mike Jones > wrote: This isn't a typo. They are registering their "redirect_uri" values. They= do so using the "redirect_uris" parameter. -- Mike From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Tuesday, July 08, 2014 8:41 PM To: Mike Jones Cc: oauth@ietf.org list Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata re= quirements Also, I just noticed that paragraph has a typo: "redirect_uri" should be "r= edirect_uris". -- Justin On Jul 8, 2014, at 11:39 PM, Justin Richer > wrote: I can see where you're going with it. Requiring clients to use it implies t= hat servers need to enforce it. In the security considerations we currently= have: For clients that use redirect-based grant types such as "authorization_code" and "implicit", authorization servers MUST require clients to register their "redirect_uri" values. This can help mitigate attacks where rogue actors inject and impersonate a validly registered client and intercept its authorization code or tokens through an invalid redirection URI or open redirector. However, in previous versions up to -17, this was a SHOULD, not a MUST. Thi= s is a normative requirement change for server implementors and I want to m= ake sure everyone realizes was made. As of a handful of versions ago, our s= erver started to enforce this anyway. What have other developers done with = this, and would it be difficult to comply with the new requirement? -- Justin On Jul 8, 2014, at 10:22 PM, Mike Jones > wrote: That's close but not quite right, since use is required by clients when usi= ng redirect-based grant types. We could however, use this language: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support and clients that u= se redirect-based grant types. redirect_uris (...) Authorization servers that support dynamic registration= of clients using redirect-based grant types MUST implement support for this metadata value and clients that= use redirect-based grant types MUST use this parameter. -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P. Sent: Tuesday, July 08, 2014 6:44 PM To: oauth@ietf.org list Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata requir= ements In draft -18, we clarified the optionality of the client metadata parameter= s in =A7 2 with new text, including the sentences: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris". redirect_uris (...) Authorization servers MUST implement support for this m= etadata value. However, since OAuth core defines two non-redirect flows (client credential= s and password) and we're about to publish another one (assertions), I sugg= est that we adopt the following clarification: The implementation and use of all client metadata fields is OPTIONAL, other= than "redirect_uris" which is REQUIRED for authorization servers that support redirect-based gra= nt types. Authorization servers that support dynamic registration of clients using re= direct-based grant types MUST implement support for this metadata value. I think this language brings the requirement more in line with the intent a= nd would like comment from the WG. -- Justin --_000_4E1F6AAD24975D4BA5B16804296739439ADA28F8TK5EX14MBXC294r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Using “redirection = URIs” is fine with me.

 <= /p>

From: Richer, = Justin P. [mailto:jricher@mitre.org]
Sent: Tuesday, July 08, 2014 8:57 PM
To: Mike Jones
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on meta= data requirements

 

Well, I think it's confusing, then. To me, it reads = like a typo since it's formatted as a verb. I really think it should line u= p with the actual name of the parameter, or it shouldn't be formatted as a = verb. So I'd suggest either:

 

    register their "redirect_uris&quo= t; value

 

or:

 

    register their redirection URIs

 

 

The latter probably reads better.

 

  -- Justin

 

 

 

On Jul 8, 2014, at 11:52 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:



This isn’t a typo.&= nbsp; They are registering their “redirect_uri” values.  T= hey do so using the “redirect_uris” parameter.

 <= /p>

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

 <= /p>

From: Richer, = Justin P. [mailto:jricher@mitre.org]
Sent: Tuesday, July 08, 2014 8:41 PM
To: Mike Jones
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on meta= data requirements

 

Also, I just noticed that paragraph has a typo: &quo= t;redirect_uri" should be "redirect_uris".

 

 -- Justin

 

On Jul 8, 2014, at 11:39 PM, Justin Richer <jricher@mitre.org> wrote:=




I can see where you're going with it. Requiring clie= nts to use it implies that servers need to enforce it. In the security cons= iderations we currently have:

 

   For clients that use redirect-based grant types such as
   "authorization_code" and "implicit", =
authorization servers MUST
   require clients to register their "redirect_uri"=
; values.  This can
   help mitigate attacks where rogue actors inject and imper=
sonate a
   validly registered client and intercept its authorization=
 code or
   tokens through an invalid redirection URI or open redirec=
tor.

 

However, in previous versions up to -17, this was a = SHOULD, not a MUST. This is a normative requirement change for server imple= mentors and I want to make sure everyone realizes was made. As of a handful= of versions ago, our server started to enforce this anyway. What have other developers done with this, and wou= ld it be difficult to comply with the new requirement?

 

 -- Justin

 

On Jul 8, 2014, at 10:22 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:




That’s close but no= t quite right, since use is required by clients when using redirect-based g= rant types.  We could however, use this language:

 <= /p> 

The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"
which is REQUIRED for authorization servers that support and clients t=
hat use redirect-based grant types.
 
redirect_uris (...) Authorization servers that support dynamic registr=
ation of clients using redirect-based
grant types MUST implement support for this metadata value and clients=
 that use redirect-based grant types MUST use this parameter.



 <=
/p>



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




 <=
/p>





 <=
/p>







From: OAuth [<=
a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org]
On Behalf Of Richer, Justin P.

Sent: Tuesday, July 08, 2014 6:44 PM

To: oauth@ietf.org list

Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata=
 requirements






 


In draft -18, we clarified the optionality of the cl=
ient metadata parameters in =A7 2 with new text, including the sentences:





 








The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris".








 


redirect_uris (...) Authorization servers MUST implement support for t=
his metadata value.












 








 






However, since OAuth core defines two non-redirect f=
lows (client credentials and password) and we're about to publish another o=
ne (assertions), I suggest that we adopt the following clarification:<=
/o:p>






 










The implementation and use of all client metadata fields is OPTIONAL, =
other than "redirect_uris"


which is REQUIRED for authorization servers that support redirect-base=
d grant types.










 








Authorization servers that support dynamic registration of clients usi=
ng redirect-based


grant types MUST implement support for this metadata value.=











 








I think this language brings the requirement more in=
 line with the intent and would like comment from the WG.






 






 -- Justin

 

 

 

--_000_4E1F6AAD24975D4BA5B16804296739439ADA28F8TK5EX14MBXC294r_-- From nobody Wed Jul 9 13:03:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12921A0463 for ; Wed, 9 Jul 2014 13:03:09 -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 wPqmgwVwYmBH for ; Wed, 9 Jul 2014 13:03:06 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7064B1A8BB3 for ; Wed, 9 Jul 2014 13:03:06 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id ik5so8160930vcb.21 for ; Wed, 09 Jul 2014 13:03:05 -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=QMKth28dpvNQcF5nENRT6x8LvzCkoW+SQk5M1LjB6lk=; b=APNpG7EGwFIPhzI7/IpZvr7yX+RJTJ+xkOMpygzYpN4RpJ+Bc/0P1mZMOENLdJRlta R4q9jqtZUn0gng/ep71l6AjuqjWv7JBC25R0qffR+9TeZQzS2/LgYAMJ9PbyQBZ57+0E 6mSsKi5PE+Kb4DCAkCK+KkMk7Y3s6hBPjGqd8hAw8YqVACptRShSg95RScrTyA8FEEcN OJaRsqU12BY+cMJAch8gtI1E/U5rw979AE21FgY24+eS0ewH3JIAuZ0XkfQW51RGAYuV SAw6oJtabriPjMtrPrUig/y0ouT3F0r1p6URLLx/iyXLVmx+nUN11/6FyVzZrQ0ybog2 rBBA== X-Gm-Message-State: ALoCoQkRXxOT3rHaL8J9itd1YXWbDWD6CzVT9R+/vtuAloBVT2CO+zmkhnAnIlsNCFj2nUvNO4TC X-Received: by 10.220.190.197 with SMTP id dj5mr41317784vcb.19.1404936185338; Wed, 09 Jul 2014 13:03:05 -0700 (PDT) Received: from [192.168.0.200] ([201.189.48.7]) by mx.google.com with ESMTPSA id c8sm54515264qam.41.2014.07.09.13.03.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 13:03:04 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FE2D1B88-A51E-4DC1-A6A2-791F881B5350" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Wed, 9 Jul 2014 16:04:01 -0400 Message-Id: References: <4D1EA5D2-8862-47FD-8C17-D74C88287F87@mitre.org> <4E1F6AAD24975D4BA5B16804296739439ADA17D7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4A01E809-C4B5-4E5E-999C-C94042290B87@mitre.org> To: Phil Hunt X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/q0vzV181yVo9UKaw-KVjctuAg7A Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements 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, 09 Jul 2014 20:03:10 -0000 --Apple-Mail=_FE2D1B88-A51E-4DC1-A6A2-791F881B5350 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 What issue of redirect_uri fragments? For implicit and the hybrid flows the fragment is used to pass back the = parameters. =20 In Connect we were explicit on what parts of the URI are compared: One of these registered Redirection URI values MUST exactly match the = redirect_uri parameter value used in each Authorization Request, with = the matching performed as described in Section 6.2.1 of [RFC3986] = (Simple String Comparison). In the IETF version we point back to Section 2 of RFC6749 The redirection endpoint URI MUST be an absolute URI as defined by [RFC3986] Section 4.3. The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters. The endpoint URI MUST NOT include a fragment component. So the redirect_uri can't contain a fragment.=20 In RFC6749 there is some wiggle room for comparing URI components. When a redirection URI is included in an authorization request, the authorization server MUST compare and match the value received against at least one of the registered redirection URIs (or URI components) as defined in [RFC3986] Section 6, if any redirection URIs were registered. If the client registration included the full redirection URI, the authorization server MUST compare the two URIs using simple string comparison as defined in [RFC3986] Section 6.2.1. So we are not adding any additional constraints beyond RFC6749. The redirect_uris meta-data is optional. A client using the client credentials or resource owner flow wouldn't = have a redirect uri to register. John B. On Jul 8, 2014, at 11:45 PM, Phil Hunt wrote: > What about the whole issue of redirect_uri fragments?=20 >=20 > Are there any issues where a client for some reason can=92t register a = perm URI at registration time? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Jul 8, 2014, at 8:39 PM, Richer, Justin P. = wrote: >=20 >> I can see where you're going with it. Requiring clients to use it = implies that servers need to enforce it. In the security considerations = we currently have: >>=20 >> For clients that use redirect-based grant types such as >> "authorization_code" and "implicit", authorization servers MUST >> require clients to register their "redirect_uri" values. This can >> help mitigate attacks where rogue actors inject and impersonate a >> validly registered client and intercept its authorization code or >> tokens through an invalid redirection URI or open redirector. >>=20 >> However, in previous versions up to -17, this was a SHOULD, not a = MUST. This is a normative requirement change for server implementors and = I want to make sure everyone realizes was made. As of a handful of = versions ago, our server started to enforce this anyway. What have other = developers done with this, and would it be difficult to comply with the = new requirement? >>=20 >> -- Justin >>=20 >> On Jul 8, 2014, at 10:22 PM, Mike Jones = wrote: >>=20 >>> That=92s close but not quite right, since use is required by clients = when using redirect-based grant types. We could however, use this = language: >>> =20 >>> The implementation and use of all client metadata fields is = OPTIONAL, other than "redirect_uris" >>> which is REQUIRED for authorization servers that support and clients = that use redirect-based grant types. >>> =20 >>> redirect_uris (...) Authorization servers that support dynamic = registration of clients using redirect-based >>> grant types MUST implement support for this metadata value and = clients that use redirect-based grant types MUST use this parameter. >>> =20 >>> -- Mike >>> =20 >>> =20 >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, = Justin P. >>> Sent: Tuesday, July 08, 2014 6:44 PM >>> To: oauth@ietf.org list >>> Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata = requirements >>> =20 >>> In draft -18, we clarified the optionality of the client metadata = parameters in =A7 2 with new text, including the sentences: >>> =20 >>> The implementation and use of all client metadata fields is = OPTIONAL, other than "redirect_uris". >>> =20 >>> redirect_uris (...) Authorization servers MUST implement support for = this metadata value. >>> =20 >>> =20 >>> However, since OAuth core defines two non-redirect flows (client = credentials and password) and we're about to publish another one = (assertions), I suggest that we adopt the following clarification: >>> =20 >>> The implementation and use of all client metadata fields is = OPTIONAL, other than "redirect_uris" >>> which is REQUIRED for authorization servers that support = redirect-based grant types. >>> =20 >>> Authorization servers that support dynamic registration of clients = using redirect-based >>> grant types MUST implement support for this metadata value. >>> =20 >>> I think this language brings the requirement more in line with the = intent and would like comment from the WG. >>> =20 >>> -- Justin >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_FE2D1B88-A51E-4DC1-A6A2-791F881B5350 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 What = issue of redirect_uri fragments?

For implicit and the = hybrid flows the fragment is used to pass back the parameters. =   

In Connect we were explicit on = what parts of the URI are compared:
One of these registered = Redirection URI values MUST exactly match the redirect_uri parameter value used in each Authorization = Request, with the matching performed as described in Section 6.2.1 = of [RFC3986] (Simple String = Comparison).

In the IETF version we = point back to Section 2 of RFC6749

The redirection endpoint =
URI MUST be an absolute URI as defined by
   [RFC3986] =
Section 4.3.  The endpoint URI MAY include an
   "application/x-www-form-urlencoded" formatted (per Appendix B) =
query
   component ([RFC3986] =
Section 3.4), which MUST be retained when adding
   additional query parameters.  The endpoint URI MUST NOT include a
   fragment component.

So the = redirect_uri can't contain a = fragment. 


In RFC6749 there = is some wiggle room for comparing URI components.
   When a redirection =
URI is included in an authorization request, the
   authorization server MUST compare and match the value received
   against at least one of the registered redirection URIs (or URI
   components) as defined in [RFC3986] =
Section 6, if any redirection
   URIs were registered.  If the client registration included the full
   redirection URI, the authorization server MUST compare the two URIs
   using simple string comparison as defined in [RFC3986] =
Section 6.2.1.

So we =
are not adding any additional constraints beyond RFC6749.
The redirect_uris =
meta-data is optional.

A =
client using the client credentials or resource owner flow wouldn't have =
a redirect uri to register.

John =
B.

On Jul 8, 2014, at 11:45 PM, = Phil Hunt <phil.hunt@oracle.com> = wrote:

What about the whole issue of redirect_uri = fragments? 

Are there any issues where a client = for some reason can=92t register a perm URI at registration = time?


On Jul 8, 2014, = at 8:39 PM, Richer, Justin P. <jricher@mitre.org> wrote:

I can see where you're going = with it. Requiring clients to use it implies that servers need to = enforce it. In the security considerations we currently = have:

   For clients =
that use redirect-based grant types such as
   "authorization_code" and "implicit", authorization servers MUST
   require clients to register their "redirect_uri" values.  This can
   help mitigate attacks where rogue actors inject and impersonate a
   validly registered client and intercept its authorization code or
   tokens through an invalid redirection URI or open redirector.

However, in previous versions up to -17, = this was a SHOULD, not a MUST. This is a normative requirement change = for server implementors and I want to make sure everyone realizes was = made. As of a handful of versions ago, our server started to enforce = this anyway. What have other developers done with this, and would it be = difficult to comply with the new = requirement?

 -- = Justin

On Jul 8, 2014, at 10:22 PM, Mike Jones = <Michael.Jones@microsoft.com> = wrote:

That=92s close but not quite = right, since use is required by clients when using redirect-based grant = types.  We could however, use this = language:
 
The implementation and use of all client metadata fields =
is OPTIONAL, other than "redirect_uris"
which is REQUIRED for authorization servers that support =
and clients that use redirect-based grant types.
 
redirect_uris =
(...) Authorization servers that support dynamic registration of clients =
using redirect-based
grant types MUST =
implement support for this metadata value and clients that use =
redirect-based grant types MUST use this =
parameter.
 
           &= nbsp;           &nb= sp;            = ;            &= nbsp;           -- = Mike
 
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin = P.
Sent: Tuesday, July 08, 2014 6:44 = PM
To: oauth@ietf.org list
Subject: [OAUTH-WG] Dynamic Client = Registration: comment on metadata = requirements
 
In draft -18, = we clarified the optionality of the client metadata parameters in =A7 2 = with new text, including the sentences:
 
The =
implementation and use of all client metadata fields is OPTIONAL, other =
than "redirect_uris".
 
redirect_uris (...) =
Authorization servers MUST implement support for this metadata =
value.
 
 
However, since OAuth core defines two non-redirect flows (client = credentials and password) and we're about to publish another one = (assertions), I suggest that we adopt the following = clarification:
 
The implementation and use =
of all client metadata fields is OPTIONAL, other than =
"redirect_uris"
which is REQUIRED for =
authorization servers that support redirect-based grant =
types.
 
Authorization =
servers that support dynamic registration of clients using =
redirect-based
grant types MUST implement =
support for this metadata =
value.
 
I = think this language brings the requirement more in line with the intent = and would like comment from the WG.
 
 -- = Justin

_______________________________________________
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=_FE2D1B88-A51E-4DC1-A6A2-791F881B5350-- From nobody Wed Jul 9 19:18:54 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2361E1A0414 for ; Wed, 9 Jul 2014 19:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 DpjyWCqUxtFo for ; Wed, 9 Jul 2014 19:18:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845541A0204 for ; Wed, 9 Jul 2014 19:18:50 -0700 (PDT) Received: from BY2PR03CA031.namprd03.prod.outlook.com (10.242.234.152) by CY1PR0301MB0604.namprd03.prod.outlook.com (25.160.142.23) with Microsoft SMTP Server (TLS) id 15.0.980.8; Thu, 10 Jul 2014 02:18:48 +0000 Received: from BN1AFFO11FD032.protection.gbl (2a01:111:f400:7c10::151) by BY2PR03CA031.outlook.office365.com (2a01:111:e400:2c2c::24) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Thu, 10 Jul 2014 02:18:47 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD032.mail.protection.outlook.com (10.58.52.186) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Thu, 10 Jul 2014 02:18:47 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0195.002; Thu, 10 Jul 2014 02:18:13 +0000 From: Mike Jones To: Tom Yu , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Leap second ambiguity in JWT-25 (Re: I-D Action: draft-ietf-oauth-json-web-token-25.txt) Thread-Index: AQHPmjGgO9QfoSuztEeIi1wIm35Xz5uYk5nA Date: Thu, 10 Jul 2014 02:18:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA3843@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <20140704223838.27871.23006.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(43784003)(52604005)(189002)(199002)(13464003)(377454003)(97736001)(77982001)(64706001)(107046002)(81542001)(92566001)(46102001)(50466002)(2171001)(77096002)(83322001)(55846006)(79102001)(92726001)(47776003)(85306003)(81342001)(76176999)(50986999)(54356999)(76482001)(74662001)(107886001)(20776003)(104016003)(97756001)(74502001)(87936001)(26826002)(80022001)(99396002)(66066001)(31966008)(68736004)(15975445006)(69596002)(106116001)(4396001)(81156004)(44976005)(83072002)(46406003)(23726002)(84676001)(33656002)(21056001)(2656002)(95666004)(19580405001)(106466001)(85852003)(19580395003)(86612001)(86362001)(6806004); DIR:OUT; SFP:; SCL:1; SRVR:CY1PR0301MB0604; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0268246AE7 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/vKyrXXWxH60vq-tNf5YSaILTBVE Subject: Re: [OAUTH-WG] Leap second ambiguity in JWT-25 (Re: I-D Action: draft-ietf-oauth-json-web-token-25.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: Thu, 10 Jul 2014 02:18:53 -0000 Thanks for pointing this out, Tom. I agree that we should use the POSIX se= mantics. Other experts on the list - is there an RFC containing the approp= riate definition, or should I just reference my old POSIX.1 spec (IEEE Std = 1003.1-1988)? As for whether IntDate must be an integer, the normative text says "no". I= t's defined as "a JSON numeric value", which allows the values to be non-in= tegers. The name "IntDate" is misleading in that way. I'll try to come up= with a better name for use in the next version of the spec. Thanks again, -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Tom Yu Sent: Monday, July 07, 2014 3:20 PM To: oauth@ietf.org Subject: [OAUTH-WG] Leap second ambiguity in JWT-25 (Re: I-D Action: draft-= ietf-oauth-json-web-token-25.txt) Sorry for bringing this up so late in the process, but I recently had reaso= ns to read the JWT draft and saw the following definition: IntDate A JSON numeric value representing the number of seconds from 1970- 01-01T0:0:0Z UTC until the specified UTC date/time. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular. This definition is ambiguous with respect to the treatment of leap seconds.= It would probably be best to specify that this is a notional count of sec= onds from 1970-01-01T00:00:00Z, similar to the POSIX definition of "Seconds= Since the Epoch", which assumes that every calendar day contains exactly 8= 6400 seconds. I believe RFC 3339 gives no guidance in this area. It would= also useful to specify whether it's expected to be an integer; I might gue= ss yes, because the authors could intend "Int" to be an abbreviation for "I= nteger". I have seen evidence that some system administrators see operational proble= ms with some protocols when they configure their systems to keep a non-conf= orming variant of POSIX time that includes leap seconds. (Interestingly enough, these involve a set of tzdata zone names that have a= prefix of "right/".) If programs running on such systems transmit their non-conforming time_t va= lues by encoding them directly in IntDate fields, recipients may see illuso= ry time offsets representing the accumulated number of leap seconds (about = 25 currently), even though the sending and receiving systems will likely ag= ree on encoded RFC 3339 UTC time stamps except in the immediate vicinity of= a leap second. It may seem like a small offset now, but I believe that it= is expected to grow significantly larger in the future, unless leap second= s are abolished. Minor issue: the hour, minute, and second fields for the Epoch should be tw= o digits in RFC 3339 format. Recommended new text: IntDate A JSON numeric value representing the notional number of integer seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. This is equivalent to the POSIX [POSIX ref here] definition of "Seconds Since the Epoch", where each calendar day contains exactly 86400 seconds. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Jul 10 14:06:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BCD1B2A18 for ; Thu, 10 Jul 2014 14:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Da6aQPAqHdA for ; Thu, 10 Jul 2014 14:06:24 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEEE71B2A17 for ; Thu, 10 Jul 2014 14:06:23 -0700 (PDT) X-AuditID: 12074425-f79766d000006da8-d6-53bf004e4e01 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id A9.E4.28072.E400FB35; Thu, 10 Jul 2014 17:06:22 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s6AL6Ln9001237; Thu, 10 Jul 2014 17:06:22 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6AL6KRL014936; Thu, 10 Jul 2014 17:06:21 -0400 From: Tom Yu To: Mike Jones References: <20140704223838.27871.23006.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439ADA3843@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Thu, 10 Jul 2014 17:06:20 -0400 In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA3843@TK5EX14MBXC294.redmond.corp.microsoft.com> (Mike Jones's message of "Thu, 10 Jul 2014 02:18:12 +0000") Message-ID: Lines: 35 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixCmqrOvHsD/Y4OJfZYu90z6xWJx8+4rN gcljyZKfTB6tO/6yBzBFcdmkpOZklqUW6dslcGW83hZcsJG/4s/91cwNjEd4uhg5OSQETCRW fN/PAmGLSVy4t56ti5GLQ0hgNpPE78NvWSCcjYwSdy9tYIdw3jBKXFzcy9zFyMHBJiAtcXRx GUi3iICOxOOL39hAbGYBNYk97+aC2cICBRKXO19CDdrDKPFy72MmkASLgKrEwp9HmEFsToH5 jBKfz2SCzOQV0JXYeDwZJMwjwCnRt6If7DpeAUGJkzOfsEDM15K48e8l0wRGgVlIUrOQpBYw Mq1ilE3JrdLNTczMKU5N1i1OTszLSy3StdDLzSzRS00p3cQICkd2F9UdjBMOKR1iFOBgVOLh VVi/L1iINbGsuDL3EKMkB5OSKK/Id6AQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4zL4ByvCmJ lVWpRfkwKWkOFiVx3rfWVsFCAumJJanZqakFqUUwWRkODiUJ3m//gBoFi1LTUyvSMnNKENJM HJwgw3mAhheB1PAWFyTmFmemQ+RPMSpKifOuBEkIgCQySvPgemHp4hWjONArwrwW/4GqeICp Bq77FdBgJqDB1hZ7QAaXJCKkpBoYBVKO15Ydrs1cLFHSW9i92KnwSZE+f7fqDhevMwf+81T3 bw7//kDg+lzZvKozX7Qcj6SuPRDDcFVnF/vFmOWyd9XO/JnkfrN7wUM3tk+H+don9HzsfdDe 2yoxm1tMgPkIt/DB4z6Tz6/eGLnikYaOgXjTbd220EO7PzV03snw/l3ZZ31QPMJSiaU4I9FQ i7moOBEASQSSavICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/mprd_NJNxjajQymN4U06bjxMsLE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Leap second ambiguity in JWT-25 (Re: I-D Action: draft-ietf-oauth-json-web-token-25.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: Thu, 10 Jul 2014 21:06:26 -0000 Mike Jones writes: > Thanks for pointing this out, Tom. I agree that we should use the POSIX semantics. Other experts on the list - is there an RFC containing the appropriate definition, or should I just reference my old POSIX.1 spec (IEEE Std 1003.1-1988)? Hi Mike, My reference for Seconds Since the Epoch in IEEE 1003.1-2013 is http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15 I believe there have been several technical and editorial corrections to that section of POSIX since 1988, so a more recent citation might be appropriate. As far as I know, there is no RFC containing a specification of the POSIX Seconds Since the Epoch definition. I think there is also no RFC that gives general guidance on the handling of leap seconds when protocol time stamps are represented as a number of seconds elapsed since some epoch. http://www.eecis.udel.edu/~mills/leap.html (and to some extent, RFC 5905) provides a description of what happens with leap seconds in NTP. RFC 7164 provides a useful and generally applicable contrast among behaviors of official UTC, typical POSIX implementations, and NTP (even though the nominal subject of the RFC is the interaction of leap seconds with RTP). > As for whether IntDate must be an integer, the normative text says "no". It's defined as "a JSON numeric value", which allows the values to be non-integers. The name "IntDate" is misleading in that way. I'll try to come up with a better name for use in the next version of the spec. Thanks. RFC 7164 shows how there is additional ambiguity of time stamps at the sub-second level. I suspect that this does not have significant consequences for most use cases of JWT. You might or might not want to mention that there will be some ambiguities or anomalies in time stamps near leap seconds, but that they will not have serious consequences for most applications. From nobody Thu Jul 10 14:43:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DBF1B2A6F for ; Thu, 10 Jul 2014 14:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQ2OK6XaiIZN for ; Thu, 10 Jul 2014 14:43:32 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DC51B2A6E for ; Thu, 10 Jul 2014 14:43:31 -0700 (PDT) Received: from mail-ie0-f181.google.com ([209.85.223.181]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKU78JA284pqEQZhQZnE7oG0J3DeGbA97S@postini.com; Thu, 10 Jul 2014 14:43:32 PDT Received: by mail-ie0-f181.google.com with SMTP id rp18so180250iec.40 for ; Thu, 10 Jul 2014 14:43:31 -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:cc :content-type; bh=A+bACMVd3FhKmfXmAcmENntZzTdmjT9pSCGWuh4JD5Y=; b=ajPAMo88SrilgKVI7JNNaKod9nggNa8Tjva0/hrXtvBCUwIxjdL7qsc6ixoQ3tMSnc p5808U0bcmPGVpX/HgWkRhDEgxhxvra0z7u3Q9a8bKbuOMrIpC71+eDxzaV8D9JYL7e8 v4zKuX3nlwRE6s1t/ZjVpnHsu3CfjHpteR+qqGEmcXVjgw45UhKkvI1J9jG0+6W49zQi sZ+54MdWMry3uPGKLAriXh+NWfHz5LzDRvw79xTji7XoI27VcN5Gna4Y1x2zuVedePwu /k5alsxbjqbG6IOhoADvvP82S9qcGLErZ8xPbC/oZzZ/BaT3Ilh2d5S4XBYnt52EWGD+ ZYAw== X-Gm-Message-State: ALoCoQmplOfx1dfxGr9r+dJu4O9mM2d5AbqwUKrQvESXzAZT/VMuyknAfbfBVLP1+qlgAxL3IjMEdSYDALF9lNtUwb+7sn9V4Ysqya1vMTSDmH5hLnVa+zpgCGM4YCCTaRvzI43WF3vP X-Received: by 10.42.214.207 with SMTP id hb15mr310010icb.30.1405028611227; Thu, 10 Jul 2014 14:43:31 -0700 (PDT) X-Received: by 10.42.214.207 with SMTP id hb15mr309995icb.30.1405028611089; Thu, 10 Jul 2014 14:43:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Thu, 10 Jul 2014 14:43:01 -0700 (PDT) From: Brian Campbell Date: Thu, 10 Jul 2014 14:43:01 -0700 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/U6tgzOnZD-a8kQC18vywfkhfWdE Cc: "oauth@ietf.org" Subject: [OAUTH-WG] client_secret_expires_at in Dynamic Client Registration (was Shepherd Writeup for Dynamic Client Registration Draft) 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, 10 Jul 2014 21:43:34 -0000 I'm trying to understand the client_secret_expires_at parameter in Dynamic Client Registration? It seems rather awkward to have an expiration in this protocol that doesn't allow for anything to be done after expiration other than doing a whole new registration (and thus losing the client id). And why does expiration only apply to the client secret? If there's a need for expiration, isn't it broader than that and apply to the whole client or the client id? I tried to ask these questions, more or less, in April during last call but there was no response: http://www.ietf.org/mail-archive/web/oauth/current/msg12738.html On Tue, Jul 8, 2014 at 5:46 AM, Hannes Tschofenig wrote: > Hi all, > > I am working on the shepherd writeup for the dynamic client registration > draft. > > You can find the latest draft here: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_DynamicClientRegistration.txt > > As you can see it is still incomplete. > > I would need information about the implementation status. > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Thu Jul 10 15:13:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6481B27FA for ; Thu, 10 Jul 2014 15:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 7Fl1lKW7LLbS for ; Thu, 10 Jul 2014 15:13:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392E81B27F3 for ; Thu, 10 Jul 2014 15:13:09 -0700 (PDT) Received: from BN1PR0301MB0595.namprd03.prod.outlook.com (25.160.170.22) by BN1PR0301MB0612.namprd03.prod.outlook.com (25.160.170.27) with Microsoft SMTP Server (TLS) id 15.0.974.11; Thu, 10 Jul 2014 22:13:07 +0000 Received: from BY2PR03CA034.namprd03.prod.outlook.com (10.242.234.155) by BN1PR0301MB0595.namprd03.prod.outlook.com (25.160.170.22) with Microsoft SMTP Server (TLS) id 15.0.974.11; Thu, 10 Jul 2014 22:13:06 +0000 Received: from BN1BFFO11FD027.protection.gbl (2a01:111:f400:7c10::1:180) by BY2PR03CA034.outlook.office365.com (2a01:111:e400:2c2c::27) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Thu, 10 Jul 2014 22:13:06 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD027.mail.protection.outlook.com (10.58.144.90) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Thu, 10 Jul 2014 22:13:05 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0195.002; Thu, 10 Jul 2014 22:12:22 +0000 From: Mike Jones To: Brian Campbell , Hannes Tschofenig Thread-Topic: [OAUTH-WG] client_secret_expires_at in Dynamic Client Registration (was Shepherd Writeup for Dynamic Client Registration Draft) Thread-Index: AQHPnIgEmAJQXKlnJ0OYxy+Y4icPM5uZ3olg Date: Thu, 10 Jul 2014 22:12:22 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA47B9@TK5EX14MBXC294.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(51704005)(189002)(53754006)(377454003)(13464003)(199002)(24454002)(15975445006)(20776003)(50466002)(2656002)(106466001)(19580405001)(85852003)(84676001)(44976005)(31966008)(81542001)(68736004)(46102001)(77982001)(33656002)(97756001)(47776003)(107046002)(104016003)(86612001)(83072002)(76176999)(23726002)(97736001)(99396002)(74502001)(66066001)(87936001)(15202345003)(6806004)(83322001)(81156004)(92566001)(26826002)(80022001)(74662001)(92726001)(21056001)(76482001)(55846006)(50986999)(4396001)(46406003)(85306003)(19580395003)(79102001)(77096002)(86362001)(81342001)(64706001)(95666004)(106116001)(69596002)(54356999)(219293001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR0301MB0595; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0268246AE7 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FyPqPvyrfca4KkhrmStDKxgJZUM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] client_secret_expires_at in Dynamic Client Registration (was Shepherd Writeup for Dynamic Client Registration Draft) 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, 10 Jul 2014 22:13:12 -0000 I believe that client_secret_expires_at was a signal to clients that they s= hould plan on retrieving a new client_secret value around that time. That = makes sense if you have the management protocol to do so, but I agree with = you that it isn't very useful without it. Maybe it should be moved to the = management spec? -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell Sent: Thursday, July 10, 2014 2:43 PM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: [OAUTH-WG] client_secret_expires_at in Dynamic Client Registration= (was Shepherd Writeup for Dynamic Client Registration Draft) I'm trying to understand the client_secret_expires_at parameter in Dynamic = Client Registration? It seems rather awkward to have an expiration in this = protocol that doesn't allow for anything to be done after expiration other = than doing a whole new registration (and thus losing the client id). And why does expiration only apply to the client secret? If there's a need = for expiration, isn't it broader than that and apply to the whole client or= the client id? I tried to ask these questions, more or less, in April during last call but= there was no response: http://www.ietf.org/mail-archive/web/oauth/current/msg12738.html On Tue, Jul 8, 2014 at 5:46 AM, Hannes Tschofenig wrote: > Hi all, > > I am working on the shepherd writeup for the dynamic client=20 > registration draft. > > You can find the latest draft here: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepher > d-writeups/Writeup_OAuth_DynamicClientRegistration.txt > > As you can see it is still incomplete. > > I would need information about the implementation status. > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Jul 10 16:15:05 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8791A008B for ; Thu, 10 Jul 2014 16:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if0crcF0h-JZ for ; Thu, 10 Jul 2014 16:15:01 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D81C11A0078 for ; Thu, 10 Jul 2014 16:15:01 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6ANEvdP027942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Jul 2014 23:14:58 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6ANEukX013705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 23:14:57 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s6ANEtiO021924; Thu, 10 Jul 2014 23:14:56 GMT Received: from [25.69.103.141] (/24.114.24.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Jul 2014 16:14:55 -0700 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Thu, 10 Jul 2014 16:14:47 -0700 To: Brian Campbell X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5co-J4Y8Uzvlhe2D27MuRNA5a5A Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] client_secret_expires_at in Dynamic Client Registration (was Shepherd Writeup for Dynamic Client Registration Draft) 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, 10 Jul 2014 23:15:03 -0000 +1 We need an appropriate cred rotation method still.=20 Phil > On Jul 10, 2014, at 14:43, Brian Campbell wro= te: >=20 > I'm trying to understand the client_secret_expires_at parameter in > Dynamic Client Registration? It seems rather awkward to have an > expiration in this protocol that doesn't allow for anything to be done > after expiration other than doing a whole new registration (and thus > losing the client id). >=20 > And why does expiration only apply to the client secret? If there's a > need for expiration, isn't it broader than that and apply to the whole > client or the client id? >=20 > I tried to ask these questions, more or less, in April during last > call but there was no response: > http://www.ietf.org/mail-archive/web/oauth/current/msg12738.html >=20 >=20 >=20 >=20 > On Tue, Jul 8, 2014 at 5:46 AM, Hannes Tschofenig > wrote: >> Hi all, >>=20 >> I am working on the shepherd writeup for the dynamic client registration >> draft. >>=20 >> You can find the latest draft here: >> https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-w= riteups/Writeup_OAuth_DynamicClientRegistration.txt >>=20 >> As you can see it is still incomplete. >>=20 >> I would need information about the implementation status. >>=20 >> Ciao >> Hannes >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sun Jul 13 01:43:05 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EF21B2A02 for ; Sun, 13 Jul 2014 01:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLPcmvsr2w_y for ; Sun, 13 Jul 2014 01:42:59 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0AD1A000A for ; Sun, 13 Jul 2014 01:42:59 -0700 (PDT) Received: from [91.2.78.43] (helo=[192.168.71.87]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1X6FN2-0005PB-2r; Sun, 13 Jul 2014 10:42:56 +0200 Message-ID: <53C2468E.1010400@lodderstedt.net> Date: Sun, 13 Jul 2014 10:42:54 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Pedro Felix , oauth list References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010309060508040003030100" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_Ezat0RO-ACZdFqHHQaLe60rABo Subject: Re: [OAUTH-WG] Token revocation endpoint - revoking access token vs. revoking the grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 08:43:02 -0000 This is a multi-part message in MIME format. --------------010309060508040003030100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Pedro, can you please explain the rationale for choosing the mode dynamically? regards, Torsten. Am 11.06.2014 18:20, schrieb Pedro Felix: > Hi, > > In the context of RFC 7009, I've a question regarding revocation of > access tokens. > > I've a scenario where the revocation of an access token may have > different behaviors > > 1) Option 1 - just revoke the access token and not the refresh token. > An example is when OAuth 2.0 is being used for authentication (using > OpenID Connect) and we want to revoke the access token after a logout > but keep the refresh token for offline access > > 2) Option 2 - revoke both the access token *and* the refresh token. > > Both behaviors are allowed by RFC 7009, however there isn't a way for > both to be simultaneously available. > > My first thought was to add a custom parameter to the token revocation > request to differentiate between these two cases. Does this make > sense? Is there a better solution? > I know that adding custom parameters breaks compatibility and should > only be used as a last resort. > > > Regards > Pedro > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010309060508040003030100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Pedro,

can you please explain the rationale for choosing the mode dynamically?

regards,
Torsten.

Am 11.06.2014 18:20, schrieb Pedro Felix:
Hi,

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

I've a scenario where the revocation of an access token may have different behaviors

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

2) Option 2 - revoke both the access token *and* the refresh token. 

Both behaviors are allowed by RFC 7009, however there isn't a way for both to be simultaneously available.

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


Regards
Pedro


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

--------------010309060508040003030100-- From nobody Sun Jul 13 02:30:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAE41B2A23 for ; Sun, 13 Jul 2014 02:30:55 -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 dXksbBbPJ2U7 for ; Sun, 13 Jul 2014 02:30:54 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B186F1B2A21 for ; Sun, 13 Jul 2014 02:30:53 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id c11so2004801lbj.41 for ; Sun, 13 Jul 2014 02:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jYsEEA3t9/kKiTX6HNwEAnv+r9ZTLJKYQglVF9NFMz4=; b=uQXjlyBlFI8KDFy0vSx0ltGExgpuDqsbEUbqZk7oHmGm+QWRypfsgpEaz8lCSEDgrJ InDt0JR/8bFRVpCBhMZ2Kxuy3SGEfi/BpKwoM7I11J+MDE1mpvrkL373Vm6kj99KCpyh 7rOob1weRUDvOnD4aPf7yc6seedbwLUtNcOGqigO0+I7rb2KVYrJEgo3W586p6+tLbm6 JZ/953tC77XPgFrrr0ybRoBq10ReX055B40aZl1/DTqhb2/S5OyKw1niPwg80u0jRvBE OHSqANNtCLixR7hUPFjqsTsYqdkatzoKiyWflp2+xmRj1OkCKtwCKiqBvZ0QR4qLfNqH qIaw== X-Received: by 10.112.150.65 with SMTP id ug1mr8073577lbb.46.1405243851891; Sun, 13 Jul 2014 02:30:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.113.66 with HTTP; Sun, 13 Jul 2014 02:30:31 -0700 (PDT) In-Reply-To: References: From: Thomas Broyer Date: Sun, 13 Jul 2014 11:30:31 +0200 Message-ID: To: Pedro Felix Content-Type: multipart/alternative; boundary=047d7b34385a9d69c304fe0fd43f Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/cVQ0v2QNbprrgNlB0ijL20wSn2U Cc: oauth list Subject: Re: [OAUTH-WG] Token revocation endpoint - revoking access token vs. revoking the grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 09:30:55 -0000 --047d7b34385a9d69c304fe0fd43f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 11, 2014 at 6:20 PM, Pedro Felix wrote: > Hi, > > In the context of RFC 7009, I've a question regarding revocation of acces= s > tokens. > > I've a scenario where the revocation of an access token may have differen= t > behaviors > > 1) Option 1 - just revoke the access token and not the refresh token. An > example is when OAuth 2.0 is being used for authentication (using OpenID > Connect) and we want to revoke the access token after a logout but keep t= he > refresh token for offline access > > 2) Option 2 - revoke both the access token *and* the refresh token. > > Both behaviors are allowed by RFC 7009, however there isn't a way for bot= h > to be simultaneously available. > > My first thought was to add a custom parameter to the token revocation > request to differentiate between these two cases. Does this make sense? I= s > there a better solution? > I know that adding custom parameters breaks compatibility and should only > be used as a last resort. > I don't get it. If you send the refresh token for revocation, then the access token should also be revoked (as it's issued from the refresh token; you can just consider the access token returned by the token endpoint as issued from the refresh token returned at the same time) . If you send the access token for revocation, then only the access token will be revoked. Did I miss something? --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --047d7b34385a9d69c304fe0fd43f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--001a1134c792e0236604fe8c6ac1-- From nobody Sat Jul 19 07:24:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530921B2822 for ; Sat, 19 Jul 2014 07:24:11 -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 n0Qlij0b3pIi for ; Sat, 19 Jul 2014 07:24:09 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308A91A0348 for ; Sat, 19 Jul 2014 07:24:09 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so4044826qgd.19 for ; Sat, 19 Jul 2014 07:24:08 -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=p3sNRRhUoYliQFwXws6j5nMPcRf+HNcVmjQUzsuPW+I=; b=JMZMR7zqdyO2RMjSQl0okXSItISfXzm1dkPzSv7pp7zn4Varz5bnEBoLbftd5vhs50 meKvpAsxWBHLj/L8i1Bfkr87XlojEoXbH6jfm6+ekjc/OeUnI5Fv6SBMxFMxj9tx2YeQ nN0wVgMFVBtgWsdJrEc+OnOyzF7NSpzLZD/PSIRECGWRgcmVW81zZdd6vYTbtmmEU/jS 0N5gdAPULWNVdDy5aKktng18g1KieRGmoHs2UK9jV+rAY54qMzRcvlf2qD7RnTTKVNn5 60OluvSYzMJIwI45L6+54uegCaomff3sttFvLIrqSJTE83mwjegAT062Z+GHYd3BdCXA qoIA== X-Received: by 10.140.18.168 with SMTP id 37mr6986560qgf.105.1405779848293; Sat, 19 Jul 2014 07:24:08 -0700 (PDT) Received: from [192.168.1.4] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id j97sm9641239qgd.37.2014.07.19.07.24.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Jul 2014 07:24:06 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-0DB84DB2-F483-4E3A-A740-7DC313A7A5D3 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Sat, 19 Jul 2014 10:24:06 -0400 Content-Transfer-Encoding: 7bit Message-Id: <60D7F5DB-0574-4F58-ADCB-C9E4D9850401@gmail.com> References: To: Brian Campbell Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/d7xGh3tzST2dqvmG1m2OKrj4OOg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD Review of http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer 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, 19 Jul 2014 14:24:11 -0000 --Apple-Mail-0DB84DB2-F483-4E3A-A740-7DC313A7A5D3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the quick response, Brian. I think the text looks great. The on= ly change I'd like to suggest is in the second sentence, to change the 'may'= to 'SHOULD'. Best regards, Kathleen=20 Sent from my iPhone > On Jul 19, 2014, at 1:00 AM, Brian Campbell w= rote: >=20 > How about the following (which is intentionally similar to the text I just= put forth for your request for privacy consideration in draft-ietf-oauth-jw= t-bearer-09)? >=20 > A SAML Assertion may contain privacy-sensitive information and, to prevent= disclosure of such information to unintended parties, should only be transm= itted over encrypted channels, such as TLS. In cases where it=E2=80=99s desi= rable to prevent disclosure of certain information the client, the Subject a= nd/or individual attributes of a SAML Assertion may be encrypted to the auth= orization server.=20 >=20 > Deployments should determine the minimum amount of information necessary t= o complete the exchange and include only that information in an Assertion (t= ypically by limiting what information is included in an = or omitting it altogether). In some cases the Subject can be a value repres= enting an anonymous or pseudonymous user as described in Section 6.3.1 of th= e Assertion Framework for OAuth 2.0 Client Authentication and Authorization G= rants [http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3= .1].=20 >=20 >=20 >> On Tue, Jul 15, 2014 at 2:04 PM, Kathleen Moriarty wrote: >> Hello, >>=20 >> I just finished my review of http://datatracker.ietf.org/doc/draft-ietf-o= auth-saml2-bearer. The draft looks great, thank you for all of your efforts= on it! >>=20 >> I did notice that there were no privacy considerations pointing back to R= FC6973, could that text be added? The draft came after the Oauth framework p= ublication (refernced in the security considerations), so I am guessing that= is why this was missed as there are privacy considerations in the oauth ass= ertion draft (I competed that review as well and the draft looked great. I d= on't have any comments to add prior to progressing the draft). >>=20 >> Thank you. >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-0DB84DB2-F483-4E3A-A740-7DC313A7A5D3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks for the quick response, Brian. &= nbsp;I think the text looks great.  The only change I'd like to suggest= is in the second sentence, to change the 'may' to 'SHOULD'.

<= /div>
Best regards,
Kathleen 

Sent from my iPhone<= /div>

On Jul 19, 2014, at 1:00 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
How about the fol= lowing (which is intentionally similar to the text I just put forth for your= request for privacy consideration in draft-ietf-oauth-jwt-bearer-09)?
A SAML Ass= ertion may contain privacy-sensitive information and, to prevent d= isclosure of such information to unintended parties, should o= nly be transmitted over encrypted channels, such as TLS. In cases w= here it=E2=80=99s desirable to prevent disclosure of certain = information the client, the Subject and/or individual attributes of a&n= bsp;SAML Assertion may be encrypted to the authorization server. <= /span>

Deployments should determine the minimu= m amount of information necessary to complete the exchange an= d include only that information in an Assertion (typically by limiting w= hat information is included in an <AttributeStatement> or omitting it a= ltogether). In some cases the Subject can be a value represen= ting an anonymous or pseudonymous user as described in Section 6.3= .1 of the Assertion Framework for OAuth 2.0 Client Authentication and Author= ization Grants [<= u>http://tools.ietf.org/html/draft-ietf-oauth-asse= rtions-16#section-6.3.1].


On Tue, Jul 15, 2014 at 2:04 PM, Kathleen Moriarty <<= a href=3D"mailto:kathleen.moriarty.ietf@gmail.com" target=3D"_blank">kathlee= n.moriarty.ietf@gmail.com> wrote:
Hello,

I j= ust finished my review of http://datatracker.ietf.org/d= oc/draft-ietf-oauth-saml2-bearer.  The draft looks great, thank you= for all of your efforts on it!

I did notice that there were no privacy considerations p= ointing back to RFC6973, could that text be added?  The draft came afte= r the Oauth framework publication (refernced in the security considerations)= , so I am guessing that is why this was missed as there are privacy consider= ations in the oauth assertion draft (I competed that review as well and the d= raft looked great.  I don't have any comments to add prior to progressi= ng the draft).

Thank you.

--

Best regards,
Kathleen

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


= --Apple-Mail-0DB84DB2-F483-4E3A-A740-7DC313A7A5D3-- From nobody Sat Jul 19 07:28:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A0A1B2835 for ; Sat, 19 Jul 2014 07:28:32 -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 FNoNCiUQs1GP for ; Sat, 19 Jul 2014 07:28:28 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E799F1B2834 for ; Sat, 19 Jul 2014 07:28:27 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so4068872qgf.7 for ; Sat, 19 Jul 2014 07:28:27 -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=n1ox0rQoGkfaAoC7dPKJmLSJbdkavAF84FgajIPRK0E=; b=SV9n6O9hmk54GBit+JMd0dOZqkIIcY9eItVFKId0LeseIOZbnmKtpWNt4WSSh0qnIg uK2i2lC7NFXBx+B40+ARjTmIBUVSw2PhuB6/jMvTBZMBcXKxtQb0ZBYevquGbTJniX1y M1ntnIsb1gde+nMGap/yx9aIeikuooS7ShbIBRmBOJb9unWj9zKR3pg2I7tlVuU1Y52U PDvko4ltWMP9G3CqDyUoPTFzuMFVQVX+2jzRaLgrerHXhCqKCbUocHO8/nQYMtDQOPGY gsJqyzfFgeWtQ2JS7QOXAX8FJQ+kphFxpajfgnvbMO/j5Epvf0TQRY3vB9x5oyON6VoX D7fw== X-Received: by 10.140.80.74 with SMTP id b68mr18387816qgd.21.1405780107091; Sat, 19 Jul 2014 07:28:27 -0700 (PDT) Received: from [192.168.1.4] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id k6sm9666518qge.2.2014.07.19.07.28.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Jul 2014 07:28:25 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-2517B028-FA44-41B1-8AD9-CD6560EEDBF0 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Sat, 19 Jul 2014 10:28:24 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <7DDBCE8B-4B39-432E-8925-B0C6D762A54C@oracle.com> <1452B71B-DB68-477E-BFE0-0765387B2934@ve7jtb.com> To: Brian Campbell Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/BkbCzKMKCujDf-QsqKZiYRmYrJM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-jwt-bearer-09 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, 19 Jul 2014 14:28:32 -0000 --Apple-Mail-2517B028-FA44-41B1-8AD9-CD6560EEDBF0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks, again! I read the other message first and the one comment is the sa= me to emphasize that you really should be encrypting to prevent disclosure. Thanks, Kathleen=20 Sent from my iPhone > On Jul 19, 2014, at 10:08 AM, Brian Campbell w= rote: >=20 > I agree that mentioning the RS in this context is only likely to cause con= fusion.=20 >=20 > This draft is only about sending a JWT to the token endpoint at an AS as a= n authorization grant or as client authentication. >=20 >=20 >> On Sat, Jul 19, 2014 at 6:37 AM, John Bradley wrote: >> While a JWT might generically have many different audiences like resource= servers, this profile is about sending it to the token endpoint at an AS fo= r authentication or authorization. >>=20 >> I think adding something about the RS will confuse people. =20 >>=20 >> I think Brian's text is fine. >>=20 >> John B. >>=20 >>> On Jul 18, 2014, at 11:45 PM, Phil Hunt wrote: >>>=20 >>> Should that be encrypted for the intended audience (aud) of the JWT whic= h may be the AS and/or the resource server? >>>=20 >>> Phil >>>=20 >>>> On Jul 18, 2014, at 21:52, Brian Campbell w= rote: >>>>=20 >>>> Sorry for the slow response on this Kathleen, my day job has been keepi= ng me busy recently. And, honestly, I was kind of hopeful someone would volu= nteer some text in the meantime. But that didn't happen so how about the fol= lowing? >>>>=20 >>>> A JWT may contain privacy-sensitive information and, to prevent disclos= ure of such information to unintended parties, should only be transmitted ov= er encrypted channels, such as TLS. In cases where it=E2=80=99s desirable to= prevent disclosure of certain information the client, the JWT may be be enc= rypted to the authorization server.=20 >>>>=20 >>>> Deployments should determine the minimum amount of information necessar= y to complete the exchange and include only such claims in the JWT. In some c= ases the "sub" (subject) claim can be a value representing an anonymous or p= seudonymous user as described in Section 6.3.1 of the Assertion Framework fo= r OAuth 2.0 Client Authentication and Authorization Grants [http://tools.iet= f.org/html/draft-ietf-oauth-assertions-16#section-6.3.1]. >>>>=20 >>>>=20 >>>>> On Thu, Jul 3, 2014 at 3:26 PM, Kathleen Moriarty wrote: >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> I just read through draft-ietf-oauth-jwt-bearer-09 and it looks good. = The only question/comment I have is that I don't see any mention of privacy= considerations in the referenced security sections. COuld you add somethin= g? It is easily addressed by section 10.8 of RFC6749, but there is no menti= on of privacy considerations. I'm sure folks could generate great stories a= bout who accessing what causing privacy considerations to be important. >>>>>=20 >>>>> Thanks & have a nice weekend! >>>>>=20 >>>>> --=20 >>>>>=20 >>>>> Best regards, >>>>> Kathleen >>>>>=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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-2517B028-FA44-41B1-8AD9-CD6560EEDBF0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks, again!  I read the other m= essage first and the one comment is the same to emphasize that you really sh= ould be encrypting to prevent disclosure.

Thanks,
Kathleen 

Sent from my iPhone

On Jul 19, 2= 014, at 10:08 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I agree that mentioning the RS in this con= text is only likely to cause confusion.

This draft is only about sen= ding a JWT to the token endpoint at an AS as an authorization grant or as cl= ient authentication.


On Sat, J= ul 19, 2014 at 6:37 AM, John Bradley <ve7jtb@ve7jtb.com> wrote= :
While a JW= T might generically have many different audiences like resource servers, thi= s profile is about sending it to the token endpoint at an AS for authenticat= ion or authorization.

I think adding something about the RS will confuse people. &n= bsp; 

I think Brian's text is fine.
=
John B.

On Jul= 18, 2014, at 11:45 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Should that be encrypte= d for the intended audience (aud) of the JWT which may be the AS and/or the r= esource server?

Phil

On Jul 18, 2014, at 21:52, Brian C= ampbell <= bcampbell@pingidentity.com> wrote:

Sorry for the slow= response on this Kathleen, my day job has been keeping me busy recently. An= d, honestly, I was kind of hopeful someone would volunteer some text in the m= eantime. But that didn't happen so how about the following?

A JWT may contain privacy-sen= sitive information and, to prevent disclosure of such information to uninten= ded parties, should only be transmitted over encrypted channels, such as TLS= . In cases where it=E2=80=99s desirable to prevent disclosure of certain inf= ormation the client, the JWT may be be encrypted to the authorization server= .

Deployments should determine the minimum amount of information necessary= to complete the exchange and include only such claims in the JWT. In some c= ases the "sub" (subject) claim can be a value representing an anonymous or p= seudonymous user as described in Section 6.3.1 of the Assertion Framework fo= r OAuth 2.0 Client Authentication and Authorization Grants [http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6= .3.1].


On= Thu, Jul 3, 2014 at 3:26 PM, Kathleen Moriarty <kathleen.mor= iarty.ietf@gmail.com> wrote:

H= ello,

I just read through draft-ietf-oauth-jwt-bear= er-09 and it looks good.  The only question/comment I have is that I do= n't see any mention of privacy considerations in the referenced security sec= tions.  COuld you add something?  It is easily addressed by sectio= n 10.8 of RFC6749, but there is no mention of privacy considerations.  = I'm sure folks could generate great stories about who accessing what causing= privacy considerations to be important.

Thanks & have a nice weekend!

--

Best rega= rds,
Kathleen

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


_______________________________= ________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth m= ailing list
OAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/oauth


=
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-2517B028-FA44-41B1-8AD9-CD6560EEDBF0-- From nobody Sat Jul 19 09:01:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809BF1B287E for ; Sat, 19 Jul 2014 09:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmDT7K3m8p2Y for ; Sat, 19 Jul 2014 09:00:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772591B2880 for ; Sat, 19 Jul 2014 09:00:54 -0700 (PDT) Received: from BL2PR03MB242.namprd03.prod.outlook.com (10.255.231.18) by BL2PR03MB468.namprd03.prod.outlook.com (10.141.92.27) with Microsoft SMTP Server (TLS) id 15.0.990.7; Sat, 19 Jul 2014 16:00:53 +0000 Received: from CH1PR03CA004.namprd03.prod.outlook.com (10.255.156.149) by BL2PR03MB242.namprd03.prod.outlook.com (10.255.231.18) with Microsoft SMTP Server (TLS) id 15.0.990.7; Sat, 19 Jul 2014 16:00:52 +0000 Received: from BN1AFFO11FD019.protection.gbl (10.255.156.132) by CH1PR03CA004.outlook.office365.com (10.255.156.149) with Microsoft SMTP Server (TLS) id 15.0.990.7 via Frontend Transport; Sat, 19 Jul 2014 16:00:51 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD019.mail.protection.outlook.com (10.58.52.79) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Sat, 19 Jul 2014 16:00:51 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Sat, 19 Jul 2014 16:00:20 +0000 From: Mike Jones To: Kathleen Moriarty , Brian Campbell Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-jwt-bearer-09 Thread-Index: AQHPlwV0CYCrEzmZtkW1H310hSfpcZum7GyAgAAfl4CAAGI3AIAAGZoAgAAFhgCAABmfQA== Date: Sat, 19 Jul 2014 16:00:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADD6FB5@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <7DDBCE8B-4B39-432E-8925-B0C6D762A54C@oracle.com> <1452B71B-DB68-477E-BFE0-0765387B2934@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADD6FB5TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(164054003)(55674003)(199002)(52604005)(24454002)(189002)(377454003)(77096002)(4396001)(95666004)(66066001)(19300405004)(50986999)(85852003)(83072002)(19617315012)(2656002)(31966008)(71186001)(20776003)(85306003)(76176999)(107046002)(99396002)(93886003)(80022001)(512874002)(84676001)(21056001)(74662001)(92566001)(76482001)(46102001)(44976005)(19625215002)(69596002)(97736001)(26826002)(92726001)(19580405001)(77982001)(83322001)(19580395003)(84326002)(104016003)(33656002)(68736004)(81156004)(106116001)(81542001)(79102001)(15975445006)(106466001)(64706001)(86612001)(54356999)(16236675004)(81342001)(87936001)(55846006)(74502001)(15202345003)(86362001)(6806004); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB242; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02778BF158 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/mHHPNOBRTnVYHkq-X3TYu4Kfpd8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-jwt-bearer-09 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, 19 Jul 2014 16:00:59 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADD6FB5TK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEJyaWFu4oCZcyBzdWdnZXN0ZWQgdGV4dC4gIFRoYW5rcyBmb3Igd3JpdGlu ZyB0aGlzLCBCcmlhbiENCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLYXRobGVlbiBNb3JpYXJ0eQ0KU2VudDog U2F0dXJkYXksIEp1bHkgMTksIDIwMTQgNzoyOCBBTQ0KVG86IEJyaWFuIENhbXBiZWxsDQpDYzog b2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJldmlldyBvZiBkcmFmdC1p ZXRmLW9hdXRoLWp3dC1iZWFyZXItMDkNCg0KVGhhbmtzLCBhZ2FpbiEgIEkgcmVhZCB0aGUgb3Ro ZXIgbWVzc2FnZSBmaXJzdCBhbmQgdGhlIG9uZSBjb21tZW50IGlzIHRoZSBzYW1lIHRvIGVtcGhh c2l6ZSB0aGF0IHlvdSByZWFsbHkgc2hvdWxkIGJlIGVuY3J5cHRpbmcgdG8gcHJldmVudCBkaXNj bG9zdXJlLg0KDQpUaGFua3MsDQpLYXRobGVlbg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9u IEp1bCAxOSwgMjAxNCwgYXQgMTA6MDggQU0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToN CkkgYWdyZWUgdGhhdCBtZW50aW9uaW5nIHRoZSBSUyBpbiB0aGlzIGNvbnRleHQgaXMgb25seSBs aWtlbHkgdG8gY2F1c2UgY29uZnVzaW9uLg0KDQpUaGlzIGRyYWZ0IGlzIG9ubHkgYWJvdXQgc2Vu ZGluZyBhIEpXVCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgYXQgYW4gQVMgYXMgYW4gYXV0aG9yaXph dGlvbiBncmFudCBvciBhcyBjbGllbnQgYXV0aGVudGljYXRpb24uDQoNCk9uIFNhdCwgSnVsIDE5 LCAyMDE0IGF0IDY6MzcgQU0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRv OnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQpXaGlsZSBhIEpXVCBtaWdodCBnZW5lcmljYWxs eSBoYXZlIG1hbnkgZGlmZmVyZW50IGF1ZGllbmNlcyBsaWtlIHJlc291cmNlIHNlcnZlcnMsIHRo aXMgcHJvZmlsZSBpcyBhYm91dCBzZW5kaW5nIGl0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBhdCBh biBBUyBmb3IgYXV0aGVudGljYXRpb24gb3IgYXV0aG9yaXphdGlvbi4NCg0KSSB0aGluayBhZGRp bmcgc29tZXRoaW5nIGFib3V0IHRoZSBSUyB3aWxsIGNvbmZ1c2UgcGVvcGxlLg0KDQpJIHRoaW5r IEJyaWFuJ3MgdGV4dCBpcyBmaW5lLg0KDQpKb2huIEIuDQoNCk9uIEp1bCAxOCwgMjAxNCwgYXQg MTE6NDUgUE0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCg0KU2hvdWxkIHRoYXQgYmUgZW5jcnlwdGVkIGZvciB0 aGUgaW50ZW5kZWQgYXVkaWVuY2UgKGF1ZCkgb2YgdGhlIEpXVCB3aGljaCBtYXkgYmUgdGhlIEFT IGFuZC9vciB0aGUgcmVzb3VyY2Ugc2VydmVyPw0KDQpQaGlsDQoNCk9uIEp1bCAxOCwgMjAxNCwg YXQgMjE6NTIsIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWls dG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNClNvcnJ5IGZvciB0aGUgc2xv dyByZXNwb25zZSBvbiB0aGlzIEthdGhsZWVuLCBteSBkYXkgam9iIGhhcyBiZWVuIGtlZXBpbmcg bWUgYnVzeSByZWNlbnRseS4gQW5kLCBob25lc3RseSwgSSB3YXMga2luZCBvZiBob3BlZnVsIHNv bWVvbmUgd291bGQgdm9sdW50ZWVyIHNvbWUgdGV4dCBpbiB0aGUgbWVhbnRpbWUuIEJ1dCB0aGF0 IGRpZG4ndCBoYXBwZW4gc28gaG93IGFib3V0IHRoZSBmb2xsb3dpbmc/DQoNCkEgSldUIG1heSBj b250YWluIHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGFuZCwgdG8gcHJldmVudCBkaXNj bG9zdXJlIG9mIHN1Y2ggaW5mb3JtYXRpb24gdG8gdW5pbnRlbmRlZCBwYXJ0aWVzLCBzaG91bGQg b25seSBiZSB0cmFuc21pdHRlZCBvdmVyIGVuY3J5cHRlZCBjaGFubmVscywgc3VjaCBhcyBUTFMu IEluIGNhc2VzIHdoZXJlIGl04oCZcyBkZXNpcmFibGUgdG8gcHJldmVudCBkaXNjbG9zdXJlIG9m IGNlcnRhaW4gaW5mb3JtYXRpb24gdGhlIGNsaWVudCwgdGhlIEpXVCBtYXkgYmUgYmUgZW5jcnlw dGVkIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4NCg0KRGVwbG95bWVudHMgc2hvdWxkIGRl dGVybWluZSB0aGUgbWluaW11bSBhbW91bnQgb2YgaW5mb3JtYXRpb24gbmVjZXNzYXJ5IHRvIGNv bXBsZXRlIHRoZSBleGNoYW5nZSBhbmQgaW5jbHVkZSBvbmx5IHN1Y2ggY2xhaW1zIGluIHRoZSBK V1QuIEluIHNvbWUgY2FzZXMgdGhlICJzdWIiIChzdWJqZWN0KSBjbGFpbSBjYW4gYmUgYSB2YWx1 ZSByZXByZXNlbnRpbmcgYW4gYW5vbnltb3VzIG9yIHBzZXVkb255bW91cyB1c2VyIGFzIGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDYuMy4xIG9mIHRoZSBBc3NlcnRpb24gRnJhbWV3b3JrIGZvciBPQXV0 aCAyLjAgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIEdyYW50cyBbaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTE2I3Nl Y3Rpb24tNi4zLjFdLg0KDQpPbiBUaHUsIEp1bCAzLCAyMDE0IGF0IDM6MjYgUE0sIEthdGhsZWVu IE1vcmlhcnR5IDxrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86a2F0aGxl ZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGVsbG8sDQoNCkkganVzdCBy ZWFkIHRocm91Z2ggZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVhcmVyLTA5IGFuZCBpdCBsb29rcyBn b29kLiAgVGhlIG9ubHkgcXVlc3Rpb24vY29tbWVudCBJIGhhdmUgaXMgdGhhdCBJIGRvbid0IHNl ZSBhbnkgbWVudGlvbiBvZiBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGluIHRoZSByZWZlcmVuY2Vk IHNlY3VyaXR5IHNlY3Rpb25zLiAgQ091bGQgeW91IGFkZCBzb21ldGhpbmc/ICBJdCBpcyBlYXNp bHkgYWRkcmVzc2VkIGJ5IHNlY3Rpb24gMTAuOCBvZiBSRkM2NzQ5LCBidXQgdGhlcmUgaXMgbm8g bWVudGlvbiBvZiBwcml2YWN5IGNvbnNpZGVyYXRpb25zLiAgSSdtIHN1cmUgZm9sa3MgY291bGQg Z2VuZXJhdGUgZ3JlYXQgc3RvcmllcyBhYm91dCB3aG8gYWNjZXNzaW5nIHdoYXQgY2F1c2luZyBw cml2YWN5IGNvbnNpZGVyYXRpb25zIHRvIGJlIGltcG9ydGFudC4NCg0KVGhhbmtzICYgaGF2ZSBh IG5pY2Ugd2Vla2VuZCENCg0KLS0NCg0KQmVzdCByZWdhcmRzLA0KS2F0aGxlZW4NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_4E1F6AAD24975D4BA5B16804296739439ADD6FB5TK5EX14MBXC294r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIEJyaWFu4oCZcyBzdWdnZXN0ZWQg dGV4dC4mbmJzcDsgVGhhbmtzIGZvciB3cml0aW5nIHRoaXMsIEJyaWFuITxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkthdGhsZWVuIE1vcmlhcnR5 PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKdWx5IDE5LCAyMDE0IDc6MjggQU08YnI+DQo8 Yj5Ubzo8L2I+IEJyaWFuIENhbXBiZWxsPGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1v YXV0aC1qd3QtYmVhcmVyLTA5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rcywgYWdhaW4hICZuYnNwO0kgcmVhZCB0aGUgb3RoZXIgbWVz c2FnZSBmaXJzdCBhbmQgdGhlIG9uZSBjb21tZW50IGlzIHRoZSBzYW1lIHRvIGVtcGhhc2l6ZSB0 aGF0IHlvdSByZWFsbHkgc2hvdWxkIGJlIGVuY3J5cHRpbmcgdG8gcHJldmVudCBkaXNjbG9zdXJl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5LYXRobGVlbiZuYnNwOzxicj4NCjxicj4NClNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVsIDE5LCAyMDE0LCBhdCAxMDowOCBBTSwgQnJpYW4g Q2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSI+ YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgdGhh dCBtZW50aW9uaW5nIHRoZSBSUyBpbiB0aGlzIGNvbnRleHQgaXMgb25seSBsaWtlbHkgdG8gY2F1 c2UgY29uZnVzaW9uLg0KPGJyPg0KPGJyPg0KVGhpcyBkcmFmdCBpcyBvbmx5IGFib3V0IHNlbmRp bmcgYSBKV1QgdG8gdGhlIHRva2VuIGVuZHBvaW50IGF0IGFuIEFTIGFzIGFuIGF1dGhvcml6YXRp b24gZ3JhbnQgb3IgYXMgY2xpZW50IGF1dGhlbnRpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBTYXQsIEp1bCAxOSwgMjAxNCBhdCA2OjM3IEFNLCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9 Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2hpbGUgYSBKV1QgbWlnaHQgZ2VuZXJpY2FsbHkgaGF2ZSBtYW55IGRpZmZlcmVudCBh dWRpZW5jZXMgbGlrZSByZXNvdXJjZSBzZXJ2ZXJzLCB0aGlzIHByb2ZpbGUgaXMgYWJvdXQgc2Vu ZGluZyBpdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgYXQgYW4gQVMgZm9yIGF1dGhlbnRpY2F0aW9u IG9yIGF1dGhvcml6YXRpb24uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHRoaW5rIGFkZGluZyBzb21ldGhpbmcgYWJvdXQgdGhlIFJTIHdpbGwgY29uZnVz ZSBwZW9wbGUuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIEJyaWFuJ3MgdGV4dCBpcyBmaW5lLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huIEIuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBKdWwgMTgsIDIwMTQsIGF0IDExOjQ1IFBNLCBQaGlsIEh1bnQgJmx0OzxhIGhy ZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVu dEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG91bGQgdGhhdCBiZSBlbmNyeXB0ZWQgZm9yIHRoZSBp bnRlbmRlZCBhdWRpZW5jZSAoYXVkKSBvZiB0aGUgSldUIHdoaWNoIG1heSBiZSB0aGUgQVMgYW5k L29yIHRoZSByZXNvdXJjZSBzZXJ2ZXI/PGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpPbiBKdWwgMTgsIDIwMTQsIGF0IDIxOjUyLCBCcmlhbiBDYW1wYmVsbCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9i bGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvcnJ5 IGZvciB0aGUgc2xvdyByZXNwb25zZSBvbiB0aGlzIEthdGhsZWVuLCBteSBkYXkgam9iIGhhcyBi ZWVuIGtlZXBpbmcgbWUgYnVzeSByZWNlbnRseS4gQW5kLCBob25lc3RseSwgSSB3YXMga2luZCBv ZiBob3BlZnVsIHNvbWVvbmUgd291bGQgdm9sdW50ZWVyIHNvbWUgdGV4dCBpbiB0aGUgbWVhbnRp bWUuIEJ1dCB0aGF0IGRpZG4ndCBoYXBwZW4gc28gaG93IGFib3V0IHRoZSBmb2xsb3dpbmc/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BIEpXVCBtYXkgY29udGFpbiBwcml2YWN5LXNlbnNpdGl2ZSBpbmZvcm1h dGlvbiBhbmQsIHRvIHByZXZlbnQgZGlzY2xvc3VyZSBvZiBzdWNoIGluZm9ybWF0aW9uIHRvIHVu aW50ZW5kZWQgcGFydGllcywgc2hvdWxkIG9ubHkgYmUgdHJhbnNtaXR0ZWQgb3ZlciBlbmNyeXB0 ZWQgY2hhbm5lbHMsIHN1Y2ggYXMgVExTLiBJbiBjYXNlcyB3aGVyZSBpdOKAmXMgZGVzaXJhYmxl IHRvIHByZXZlbnQgZGlzY2xvc3VyZSBvZg0KIGNlcnRhaW4gaW5mb3JtYXRpb24gdGhlIGNsaWVu dCwgdGhlIEpXVCBtYXkgYmUgYmUgZW5jcnlwdGVkIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ci4NCjxicj4NCjxicj4NCkRlcGxveW1lbnRzIHNob3VsZCBkZXRlcm1pbmUgdGhlIG1pbmltdW0g YW1vdW50IG9mIGluZm9ybWF0aW9uIG5lY2Vzc2FyeSB0byBjb21wbGV0ZSB0aGUgZXhjaGFuZ2Ug YW5kIGluY2x1ZGUgb25seSBzdWNoIGNsYWltcyBpbiB0aGUgSldULiBJbiBzb21lIGNhc2VzIHRo ZSAmcXVvdDtzdWImcXVvdDsgKHN1YmplY3QpIGNsYWltIGNhbiBiZSBhIHZhbHVlIHJlcHJlc2Vu dGluZyBhbiBhbm9ueW1vdXMgb3IgcHNldWRvbnltb3VzIHVzZXIgYXMgZGVzY3JpYmVkIGluDQog U2VjdGlvbiA2LjMuMSBvZiB0aGUgQXNzZXJ0aW9uIEZyYW1ld29yayBmb3IgT0F1dGggMi4wIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBHcmFudHMgWzxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0xNiNz ZWN0aW9uLTYuMy4xIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTE2I3NlY3Rpb24tNi4zLjE8L2E+XS4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdWwgMywgMjAxNCBhdCAzOjI2 IFBNLCBLYXRobGVlbiBNb3JpYXJ0eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthdGhsZWVuLm1vcmlh cnR5LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F0aGxlZW4ubW9yaWFydHkuaWV0 ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8sPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkganVzdCByZWFkIHRocm91Z2ggZHJhZnQt aWV0Zi1vYXV0aC1qd3QtYmVhcmVyLTA5IGFuZCBpdCBsb29rcyBnb29kLiAmbmJzcDtUaGUgb25s eSBxdWVzdGlvbi9jb21tZW50IEkgaGF2ZSBpcyB0aGF0IEkgZG9uJ3Qgc2VlIGFueSBtZW50aW9u IG9mIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgaW4gdGhlIHJlZmVyZW5jZWQgc2VjdXJpdHkgc2Vj dGlvbnMuICZuYnNwO0NPdWxkIHlvdSBhZGQgc29tZXRoaW5nPyAmbmJzcDtJdCBpcyBlYXNpbHkN CiBhZGRyZXNzZWQgYnkgc2VjdGlvbiAxMC44IG9mIFJGQzY3NDksIGJ1dCB0aGVyZSBpcyBubyBt ZW50aW9uIG9mIHByaXZhY3kgY29uc2lkZXJhdGlvbnMuICZuYnNwO0knbSBzdXJlIGZvbGtzIGNv dWxkIGdlbmVyYXRlIGdyZWF0IHN0b3JpZXMgYWJvdXQgd2hvIGFjY2Vzc2luZyB3aGF0IGNhdXNp bmcgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyB0byBiZSBpbXBvcnRhbnQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyAmYW1wOyBoYXZl IGEgbmljZSB3ZWVrZW5kITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6Izg4ODg4OCI+LS0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4 ODg4OCI+S2F0aGxlZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439ADD6FB5TK5EX14MBXC294r_-- From nobody Sat Jul 19 09:01:10 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005671B287E for ; Sat, 19 Jul 2014 09:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od6gD84EzaAg for ; Sat, 19 Jul 2014 09:01:00 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78CD1B2882 for ; Sat, 19 Jul 2014 09:00:59 -0700 (PDT) Received: from BLUPR03CA031.namprd03.prod.outlook.com (10.141.30.24) by BN1PR03MB250.namprd03.prod.outlook.com (10.255.200.16) with Microsoft SMTP Server (TLS) id 15.0.985.8; Sat, 19 Jul 2014 16:00:57 +0000 Received: from BN1BFFO11FD022.protection.gbl (2a01:111:f400:7c10::1:158) by BLUPR03CA031.outlook.office365.com (2a01:111:e400:879::24) with Microsoft SMTP Server (TLS) id 15.0.995.11 via Frontend Transport; Sat, 19 Jul 2014 16:00:57 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD022.mail.protection.outlook.com (10.58.144.85) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Sat, 19 Jul 2014 16:00:57 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Sat, 19 Jul 2014 16:00:25 +0000 From: Mike Jones To: Kathleen Moriarty , Brian Campbell Thread-Topic: [OAUTH-WG] AD Review of http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer Thread-Index: AQHPoGf4gL6h/DUSdEmQrA3gAkL17Jum3AEAgACdYACAABqXAA== Date: Sat, 19 Jul 2014 16:00:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADD6FBC@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <60D7F5DB-0574-4F58-ADCB-C9E4D9850401@gmail.com> In-Reply-To: <60D7F5DB-0574-4F58-ADCB-C9E4D9850401@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADD6FBCTK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(24454002)(51914003)(377454003)(199002)(52604005)(189002)(85306003)(81342001)(84676001)(19300405004)(33656002)(16236675004)(74502001)(26826002)(71186001)(81542001)(104016003)(107046002)(44976005)(86612001)(77096002)(95666004)(69596002)(512874002)(19580395003)(83322001)(106116001)(19580405001)(68736004)(84326002)(31966008)(92726001)(15975445006)(50986999)(86362001)(92566001)(19625215002)(74662001)(76176999)(21056001)(15202345003)(6806004)(85852003)(87936001)(2656002)(220493001)(4396001)(55846006)(46102001)(99396002)(83072002)(97736001)(106466001)(81156004)(54356999)(79102001)(77982001)(66066001)(64706001)(80022001)(19617315012)(76482001)(20776003); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB250; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02778BF158 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LCSY3o2QMX4C2SriDVoELJUxyBg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD Review of http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer 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, 19 Jul 2014 16:01:05 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADD6FBCTK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEJyaWFu4oCZcyBzdWdnZXN0ZWQgdGV4dC4gIFRoYW5rcyBmb3Igd3JpdGlu ZyB0aGlzLCBCcmlhbiENCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLYXRobGVlbiBNb3JpYXJ0eQ0KU2VudDog U2F0dXJkYXksIEp1bHkgMTksIDIwMTQgNzoyNCBBTQ0KVG86IEJyaWFuIENhbXBiZWxsDQpDYzog b2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFEIFJldmlldyBvZiBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVy DQoNClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLCBCcmlhbi4gIEkgdGhpbmsgdGhlIHRl eHQgbG9va3MgZ3JlYXQuICBUaGUgb25seSBjaGFuZ2UgSSdkIGxpa2UgdG8gc3VnZ2VzdCBpcyBp biB0aGUgc2Vjb25kIHNlbnRlbmNlLCB0byBjaGFuZ2UgdGhlICdtYXknIHRvICdTSE9VTEQnLg0K DQpCZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIEp1 bCAxOSwgMjAxNCwgYXQgMTowMCBBTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KSG93 IGFib3V0IHRoZSBmb2xsb3dpbmcgKHdoaWNoIGlzIGludGVudGlvbmFsbHkgc2ltaWxhciB0byB0 aGUgdGV4dCBJIGp1c3QgcHV0IGZvcnRoIGZvciB5b3VyIHJlcXVlc3QgZm9yIHByaXZhY3kgY29u c2lkZXJhdGlvbiBpbiBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXItMDkpPw0KQSBTQU1MIEFz c2VydGlvbiBtYXkgY29udGFpbiBwcml2YWN5LXNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBhbmQsIHRv IHByZXZlbnQgZGlzY2xvc3VyZSBvZiBzdWNoIGluZm9ybWF0aW9uIHRvIHVuaW50ZW5kZWQgcGFy dGllcywgc2hvdWxkIG9ubHkgYmUgdHJhbnNtaXR0ZWQgb3ZlciBlbmNyeXB0ZWQgY2hhbm5lbHMs IHN1Y2ggYXMgVExTLiBJbiBjYXNlcyB3aGVyZSBpdOKAmXMgZGVzaXJhYmxlIHRvIHByZXZlbnQg ZGlzY2xvc3VyZSBvZiBjZXJ0YWluIGluZm9ybWF0aW9uIHRoZSBjbGllbnQsIHRoZSBTdWJqZWN0 IGFuZC9vciBpbmRpdmlkdWFsIGF0dHJpYnV0ZXMgb2YgYSBTQU1MIEFzc2VydGlvbiBtYXkgYmUg ZW5jcnlwdGVkIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4NCg0KRGVwbG95bWVudHMgc2hv dWxkIGRldGVybWluZSB0aGUgbWluaW11bSBhbW91bnQgb2YgaW5mb3JtYXRpb24gbmVjZXNzYXJ5 IHRvIGNvbXBsZXRlIHRoZSBleGNoYW5nZSBhbmQgaW5jbHVkZSBvbmx5IHRoYXQgaW5mb3JtYXRp b24gaW4gYW4gQXNzZXJ0aW9uICh0eXBpY2FsbHkgYnkgbGltaXRpbmcgd2hhdCBpbmZvcm1hdGlv biBpcyBpbmNsdWRlZCBpbiBhbiA8QXR0cmlidXRlU3RhdGVtZW50PiBvciBvbWl0dGluZyBpdCBh bHRvZ2V0aGVyKS4gSW4gc29tZSBjYXNlcyB0aGUgU3ViamVjdCBjYW4gYmUgYSB2YWx1ZSByZXBy ZXNlbnRpbmcgYW4gYW5vbnltb3VzIG9yIHBzZXVkb255bW91cyB1c2VyIGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDYuMy4xIG9mIHRoZSBBc3NlcnRpb24gRnJhbWV3b3JrIGZvciBPQXV0aCAyLjAg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIEdyYW50cyBbaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTE2I3NlY3Rpb24t Ni4zLjFdLg0KDQpPbiBUdWUsIEp1bCAxNSwgMjAxNCBhdCAyOjA0IFBNLCBLYXRobGVlbiBNb3Jp YXJ0eSA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmthdGhsZWVuLm1v cmlhcnR5LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpIZWxsbywNCg0KSSBqdXN0IGZpbmlzaGVk IG15IHJldmlldyBvZiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt b2F1dGgtc2FtbDItYmVhcmVyLiAgVGhlIGRyYWZ0IGxvb2tzIGdyZWF0LCB0aGFuayB5b3UgZm9y IGFsbCBvZiB5b3VyIGVmZm9ydHMgb24gaXQhDQoNCkkgZGlkIG5vdGljZSB0aGF0IHRoZXJlIHdl cmUgbm8gcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBwb2ludGluZyBiYWNrIHRvIFJGQzY5NzMsIGNv dWxkIHRoYXQgdGV4dCBiZSBhZGRlZD8gIFRoZSBkcmFmdCBjYW1lIGFmdGVyIHRoZSBPYXV0aCBm cmFtZXdvcmsgcHVibGljYXRpb24gKHJlZmVybmNlZCBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMpLCBzbyBJIGFtIGd1ZXNzaW5nIHRoYXQgaXMgd2h5IHRoaXMgd2FzIG1pc3NlZCBhcyB0 aGVyZSBhcmUgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBpbiB0aGUgb2F1dGggYXNzZXJ0aW9uIGRy YWZ0IChJIGNvbXBldGVkIHRoYXQgcmV2aWV3IGFzIHdlbGwgYW5kIHRoZSBkcmFmdCBsb29rZWQg Z3JlYXQuICBJIGRvbid0IGhhdmUgYW55IGNvbW1lbnRzIHRvIGFkZCBwcmlvciB0byBwcm9ncmVz c2luZyB0aGUgZHJhZnQpLg0KDQpUaGFuayB5b3UuDQoNCi0tDQoNCkJlc3QgcmVnYXJkcywNCkth dGhsZWVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_4E1F6AAD24975D4BA5B16804296739439ADD6FBCTK5EX14MBXC294r_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgYWdyZWUgd2l0aCBCcmlhbuKAmXMgc3VnZ2VzdGVkIHRleHQuJm5ic3A7IFRoYW5r cyBmb3Igd3JpdGluZyB0aGlzLCBCcmlhbiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5LYXRobGVlbiBNb3JpYXJ0eTxicj4NCjxiPlNlbnQ6PC9i PiBTYXR1cmRheSwgSnVseSAxOSwgMjAxNCA3OjI0IEFNPGJyPg0KPGI+VG86PC9iPiBCcmlhbiBD YW1wYmVsbDxicj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtPQVVUSC1XR10gQUQgUmV2aWV3IG9mIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgcXVpY2sgcmVz cG9uc2UsIEJyaWFuLiAmbmJzcDtJIHRoaW5rIHRoZSB0ZXh0IGxvb2tzIGdyZWF0LiAmbmJzcDtU aGUgb25seSBjaGFuZ2UgSSdkIGxpa2UgdG8gc3VnZ2VzdCBpcyBpbiB0aGUgc2Vjb25kIHNlbnRl bmNlLCB0byBjaGFuZ2UgdGhlICdtYXknIHRvICdTSE9VTEQnLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LYXRobGVlbiZuYnNw Ozxicj4NCjxicj4NClNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KT24gSnVsIDE5LCAyMDE0LCBhdCAxOjAwIEFNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5iY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5Ib3cgYWJvdXQgdGhlIGZvbGxvd2luZyAod2hpY2ggaXMgaW50ZW50aW9uYWxseSBzaW1pbGFy IHRvIHRoZSB0ZXh0IEkganVzdCBwdXQgZm9ydGggZm9yIHlvdXIgcmVxdWVzdCBmb3IgcHJpdmFj eSBjb25zaWRlcmF0aW9uIGluIGRyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJlci0wOSk/PG86cD48 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QSBTQU1MIEFzc2VydGlvbiZuYnNw O21heSBjb250YWluIHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGFuZCwmbmJzcDt0byBw cmV2ZW50IGRpc2Nsb3N1cmUgb2Ygc3VjaCZuYnNwO2luZm9ybWF0aW9uIHRvIHVuaW50ZW5kZWQg cGFydGllcywmbmJzcDtzaG91bGQmbmJzcDtvbmx5IGJlIHRyYW5zbWl0dGVkIG92ZXImbmJzcDtl bmNyeXB0ZWQgY2hhbm5lbHMsDQogc3VjaCBhcyBUTFMuJm5ic3A7SW4gY2FzZXMgd2hlcmUgaXTi gJlzIGRlc2lyYWJsZSB0byBwcmV2ZW50Jm5ic3A7ZGlzY2xvc3VyZSBvZiZuYnNwO2NlcnRhaW4m bmJzcDtpbmZvcm1hdGlvbiZuYnNwO3RoZSBjbGllbnQsIHRoZSBTdWJqZWN0IGFuZC9vciBpbmRp dmlkdWFsIGF0dHJpYnV0ZXMgb2YgYSZuYnNwO1NBTUwmbmJzcDtBc3NlcnRpb24gbWF5IGJlIGVu Y3J5cHRlZCB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuJm5ic3A7PC9zcGFuPjxicj4NCjxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlcGxveW1lbnRzIHNob3VsZCZuYnNwO2Rl dGVybWluZSB0aGUgbWluaW11bSBhbW91bnQgb2YmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO25lY2Vz c2FyeSB0byBjb21wbGV0ZSB0aGUmbmJzcDtleGNoYW5nZSBhbmQgaW5jbHVkZSBvbmx5IHRoYXQg aW5mb3JtYXRpb24gaW4gYW4mbmJzcDtBc3NlcnRpb24gKHR5cGljYWxseSBieSBsaW1pdGluZyB3 aGF0IGluZm9ybWF0aW9uIGlzIGluY2x1ZGVkDQogaW4gYW4gJmx0O0F0dHJpYnV0ZVN0YXRlbWVu dCZndDsgb3Igb21pdHRpbmcgaXQgYWx0b2dldGhlcikuJm5ic3A7SW4gc29tZSBjYXNlcyB0aGUm bmJzcDtTdWJqZWN0Jm5ic3A7Y2FuIGJlIGEgdmFsdWUgcmVwcmVzZW50aW5nIGFuJm5ic3A7YW5v bnltb3VzIG9yJm5ic3A7cHNldWRvbnltb3VzIHVzZXIgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g Ni4zLjEgb2YgdGhlIEFzc2VydGlvbiBGcmFtZXdvcmsgZm9yIE9BdXRoIDIuMCBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gR3JhbnRzDQogWzx1PjxzcGFuIHN0eWxlPSJj b2xvcjojMDQyRUVFIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW9hdXRoLWFzc2VydGlvbnMtMTYjc2VjdGlvbi02LjMuMSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0xNiNz ZWN0aW9uLTYuMy4xPC9hPjwvc3Bhbj48L3U+XS48L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBUdWUsIEp1bCAxNSwgMjAxNCBhdCAyOjA0IFBNLCBLYXRobGVlbiBNb3JpYXJ0 eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkganVzdCBmaW5p c2hlZCBteSByZXZpZXcgb2YmbmJzcDs8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJlYXJl cjwvYT4uICZuYnNwO1RoZSBkcmFmdCBsb29rcyBncmVhdCwgdGhhbmsgeW91IGZvciBhbGwgb2Yg eW91ciBlZmZvcnRzDQogb24gaXQhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgZGlkIG5vdGljZSB0aGF0IHRoZXJlIHdlcmUgbm8gcHJpdmFj eSBjb25zaWRlcmF0aW9ucyBwb2ludGluZyBiYWNrIHRvIFJGQzY5NzMsIGNvdWxkIHRoYXQgdGV4 dCBiZSBhZGRlZD8gJm5ic3A7VGhlIGRyYWZ0IGNhbWUgYWZ0ZXIgdGhlIE9hdXRoIGZyYW1ld29y ayBwdWJsaWNhdGlvbiAocmVmZXJuY2VkIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyks IHNvIEkgYW0gZ3Vlc3NpbmcgdGhhdCBpcyB3aHkgdGhpcw0KIHdhcyBtaXNzZWQgYXMgdGhlcmUg YXJlIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgaW4gdGhlIG9hdXRoIGFzc2VydGlvbiBkcmFmdCAo SSBjb21wZXRlZCB0aGF0IHJldmlldyBhcyB3ZWxsIGFuZCB0aGUgZHJhZnQgbG9va2VkIGdyZWF0 LiAmbmJzcDtJIGRvbid0IGhhdmUgYW55IGNvbW1lbnRzIHRvIGFkZCBwcmlvciB0byBwcm9ncmVz c2luZyB0aGUgZHJhZnQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGFuayB5b3UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiM4ODg4ODgiPkthdGhsZWVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439ADD6FBCTK5EX14MBXC294r_-- From nobody Sat Jul 19 14:18:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E471B2A0A for ; Sat, 19 Jul 2014 14:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqXzPh1XycoG for ; Sat, 19 Jul 2014 14:18:37 -0700 (PDT) Received: from na3sys009aog132.obsmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89651B299B for ; Sat, 19 Jul 2014 14:18:36 -0700 (PDT) Received: from mail-ie0-f178.google.com ([209.85.223.178]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKU8rgrOtqRHF3IiTTYHdKTOPvO8idk3Bl@postini.com; Sat, 19 Jul 2014 14:18:36 PDT Received: by mail-ie0-f178.google.com with SMTP id tp5so5698295ieb.37 for ; Sat, 19 Jul 2014 14:18:36 -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=j5RC6T83nDyIuFY7ImtsOzLutv9QNG3QN4IcbfovVVU=; b=OqvwBWj5z2gq//Aqfem3qFGcCPVTxK1F3vIgY4iA0WyTqZ5MJpVATfmx2Vju6BJHM9 x2a8UMBckHlA/MKujUGLYZkcR9YipL7j35h/A9tfLAOSoNoI4Npfznvs0IDMluy/jWvQ b11aqohIQP7uIEpsXtbaEloVXkQrVn45prvfuwiUjs6RvBStAIG5TVBLa8+hqkrLl4NU ArnLtMS/Nt8cwEWE6XjWiG+8BQGMxi491bpfgSNpHgCpHVkQ5eLL1B6TzZ6xFiq8AQYo +kCA3sAL+e1icHKCtwhYUjJvgU63+JhNY+AxsYIWvPMz4/2VdFH4cVdWzcZ36WCrB0pM P9ag== X-Gm-Message-State: ALoCoQm1OzJfOLOZxziPp86Ter7fiNmAGvzL9XA9w7/AAbmf4kb1iHYjM9+IBXohv5mCWDaYp37Vp+G/KMTX6UZQTPRBSIRXsUpBgYDGHhAepf75uCgJaDFpTHpqzhMnhtmp+BrnMXTc X-Received: by 10.50.41.6 with SMTP id b6mr25021206igl.40.1405804716106; Sat, 19 Jul 2014 14:18:36 -0700 (PDT) X-Received: by 10.50.41.6 with SMTP id b6mr25021168igl.40.1405804715866; Sat, 19 Jul 2014 14:18:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Sat, 19 Jul 2014 14:18:05 -0700 (PDT) In-Reply-To: <60D7F5DB-0574-4F58-ADCB-C9E4D9850401@gmail.com> References: <60D7F5DB-0574-4F58-ADCB-C9E4D9850401@gmail.com> From: Brian Campbell Date: Sat, 19 Jul 2014 15:18:05 -0600 Message-ID: To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=089e01161414b694cc04fe926a95 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/U7YueuIa67M_mEc9MBVSQY04wU0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD Review of http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer 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, 19 Jul 2014 21:18:38 -0000 --089e01161414b694cc04fe926a95 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Kathleen, that makes sense. I do, however, think that a little 'should' would be more appropriate there than a big 'SHOULD' as there's no other use of RFC2119 language in that text. That okay by you? It would read like this: A SAML Assertion may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, should only be transmitted over encrypted channels, such as TLS. In cases where it=E2=80= =99s desirable to prevent disclosure of certain information the client, the Subject and/or individual attributes of a SAML Assertion should be encrypted to the authorization server. Deployments should determine the minimum amount of information necessary to complete the exchange and include only that information in an Assertion (typically by limiting what information is included in an or omitting it altogether). In some cases the Subject can be a value representing an anonymous or pseudonymous user as described in Section 6.3.1 of the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [*http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3.1 *]= . On Sat, Jul 19, 2014 at 8:24 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Thanks for the quick response, Brian. I think the text looks great. The > only change I'd like to suggest is in the second sentence, to change the > 'may' to 'SHOULD'. > > Best regards, > Kathleen > > Sent from my iPhone > > On Jul 19, 2014, at 1:00 AM, Brian Campbell > wrote: > > How about the following (which is intentionally similar to the text I jus= t > put forth for your request for privacy consideration in > draft-ietf-oauth-jwt-bearer-09)? > > A SAML Assertion may contain privacy-sensitive information and, to preven= t > disclosure of such information to unintended parties, should only be > transmitted over encrypted channels, such as TLS. In cases where it=E2=80= =99s > desirable to prevent disclosure of certain information the client, the > Subject and/or individual attributes of a SAML Assertion may be encrypted > to the authorization server. > > Deployments should determine the minimum amount of information necessary > to complete the exchange and include only that information in an Assertio= n > (typically by limiting what information is included in an > or omitting it altogether). In some cases > the Subject can be a value representing an anonymous or pseudonymous user > as described in Section 6.3.1 of the Assertion Framework for OAuth 2.0 > Client Authentication and Authorization Grants [*http://tools.ietf.org/ht= ml/draft-ietf-oauth-assertions-16#section-6.3.1 > = * > ]. > > > On Tue, Jul 15, 2014 at 2:04 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Hello, >> >> I just finished my review of >> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer. The >> draft looks great, thank you for all of your efforts on it! >> >> I did notice that there were no privacy considerations pointing back to >> RFC6973, could that text be added? The draft came after the Oauth >> framework publication (refernced in the security considerations), so I a= m >> guessing that is why this was missed as there are privacy considerations= in >> the oauth assertion draft (I competed that review as well and the draft >> looked great. I don't have any comments to add prior to progressing the >> draft). >> >> Thank you. >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --089e01161414b694cc04fe926a95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Kathleen, that makes sense. I do, however, think th= at a little 'should' would be more appropriate there than a big = 9;SHOULD' as there's no other use of RFC2119 language in that text.= That okay by you? It would read like this:


A S= AML Assertion=C2=A0may contain=20 privacy-sensitive information and,=C2=A0to prevent disclosure of=20 such=C2=A0information to unintended parties,=C2=A0should=C2=A0only be trans= mitted=20 over=C2=A0encrypted channels, such as TLS.=C2=A0In cases where it=E2=80=99s= desirable to=20 prevent=C2=A0disclosure of=C2=A0certain=C2=A0information=C2=A0the client, t= he Subject and/or individual attributes of a=C2=A0SAML=C2=A0Assertion should be encrypted to= the=20 authorization server.=C2=A0

Deployments should=C2=A0determine the minim= um=20 amount of=C2=A0information=C2=A0necessary to complete the=C2=A0exchange and= include=20 only that information in an=C2=A0Assertion (typically by limiting what=20 information is included in an <AttributeStatement> or omitting it=20 altogether).=C2=A0In some cases the=C2=A0Subject=C2=A0can be a value repres= enting=20 an=C2=A0anonymous or=C2=A0pseudonymous user as described in Section 6.3.1 o= f the=20 Assertion Framework for OAuth 2.0 Client Authentication and=20 Authorization Grants [http://tools.ietf.org/html/draft-ietf-o= auth-assertions-16#section-6.3.1].


On Sat, Jul 19, 2014 at 8:24 AM, Kathleen Moriarty <= ;kath= leen.moriarty.ietf@gmail.com> wrote:
Thanks for the quick = response, Brian. =C2=A0I think the text looks great. =C2=A0The only change = I'd like to suggest is in the second sentence, to change the 'may&#= 39; to 'SHOULD'.

Best regards,
Kathleen=C2=A0

Sent from= my iPhone

On Jul 19, 2014, at 1:00 AM= , Brian Campbell <bcampbell@pingidentity.com> wrote:

How about the fol= lowing (which is intentionally similar to the text I just put forth for you= r request for privacy consideration in draft-ietf-oauth-jwt-bearer-09)?

A SAML = Assertion=C2=A0may contain privacy-sensitive information and,=C2=A0to preve= nt disclosure of such=C2=A0information to unintended parties,=C2=A0should= =C2=A0only be transmitted over=C2=A0encrypted channels, such as TLS.=C2=A0I= n cases where it=E2=80=99s desirable to prevent=C2=A0disclosure of=C2=A0cer= tain=C2=A0information=C2=A0the client, the Subject and/or individual attrib= utes of a=C2=A0SAML=C2=A0Assertion may be encrypted to the authorization se= rver.=C2=A0

Deployments should=C2=A0determine the minim= um amount of=C2=A0information=C2=A0necessary to complete the=C2=A0exchange = and include only that information in an=C2=A0Assertion (typically by limiti= ng what information is included in an <AttributeStatement> or omittin= g it altogether).=C2=A0In some cases the=C2=A0Subject=C2=A0can be a value r= epresenting an=C2=A0anonymous or=C2=A0pseudonymous user as described in Sec= tion 6.3.1 of the Assertion Framework for OAuth 2.0 Client Authentication a= nd Authorization Grants [http://tools.ietf.org/html/draft-iet= f-oauth-assertions-16#section-6.3.1].


On Tue, Jul 15, 2014 at 2:04 PM, Kathleen Moriarty <= ;kath= leen.moriarty.ietf@gmail.com> wrote:
Hello,

I= just finished my review of=C2=A0http://datatracker.ietf.o= rg/doc/draft-ietf-oauth-saml2-bearer. =C2=A0The draft looks great, than= k you for all of your efforts on it!

I did notice that there were no privacy considerations = pointing back to RFC6973, could that text be added? =C2=A0The draft came af= ter the Oauth framework publication (refernced in the security consideratio= ns), so I am guessing that is why this was missed as there are privacy cons= iderations in the oauth assertion draft (I competed that review as well and= the draft looked great. =C2=A0I don't have any comments to add prior t= o progressing the draft).

Thank you.

--

Best regards,
Kathlee= n

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



--089e01161414b694cc04fe926a95-- From nobody Sun Jul 20 06:18:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85361B2803 for ; Sun, 20 Jul 2014 06:18:45 -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 v335p1oAAfIK for ; Sun, 20 Jul 2014 06:18:43 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2661B27F2 for ; Sun, 20 Jul 2014 06:18:41 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id 10so1999845lbg.40 for ; Sun, 20 Jul 2014 06:18:40 -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=6hgr6mGI53CCzNxZUyFklgN/EDcx6UYGIbkCZfrc+8w=; b=V7P5ObrPDs9qcOOsVkcHsiVg+h2Sxk+CnEzgmgcETDWMY9la507DqlLkyoZyozyJt/ RvQTeAcCHdQk1O+dZjP0UNTh07v/actIctWv9o3EYOKpKIzZfluKPGqUbPi7b/aXL0Cj 9Z+sCK6zYCYxJ042z9f2r0FM7QRDRirbyPOo/UvoZU8ElFYWA1U5kNvk7RoHbq2yFQWA M4fPRz9TZz+4yTGtleyTlMy33sYeMWY+kzW/Onc19fFBXtic9BuNWxVWJHOykOjk8+O6 PUZkww5czZapVFH+Z9WteOW1fUDbxobWtgqaFzYQ5LvXvY8vttQb0YqaVtXHMnS+j1pj N3nA== MIME-Version: 1.0 X-Received: by 10.112.139.196 with SMTP id ra4mr17739271lbb.28.1405862320378; Sun, 20 Jul 2014 06:18:40 -0700 (PDT) Received: by 10.112.207.73 with HTTP; Sun, 20 Jul 2014 06:18:40 -0700 (PDT) In-Reply-To: References: <60D7F5DB-0574-4F58-ADCB-C9E4D9850401@gmail.com> Date: Sun, 20 Jul 2014 09:18:40 -0400 Message-ID: From: Kathleen Moriarty To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11c33fcc35984404fe9fd49b Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zU2KB9B2C5wl_HaAQE33RZ__4kc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD Review of http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer 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: Sun, 20 Jul 2014 13:18:46 -0000 --001a11c33fcc35984404fe9fd49b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Brian. That looks good to me. Kathleen On Sat, Jul 19, 2014 at 5:18 PM, Brian Campbell wrote: > Thanks Kathleen, that makes sense. I do, however, think that a little > 'should' would be more appropriate there than a big 'SHOULD' as there's n= o > other use of RFC2119 language in that text. That okay by you? It would re= ad > like this: > > > A SAML Assertion may contain privacy-sensitive information and, to preven= t > disclosure of such information to unintended parties, should only be > transmitted over encrypted channels, such as TLS. In cases where it=E2=80= =99s > desirable to prevent disclosure of certain information the client, the > Subject and/or individual attributes of a SAML Assertion should be > encrypted to the authorization server. > > > Deployments should determine the minimum amount of information necessary > to complete the exchange and include only that information in an Assertio= n > (typically by limiting what information is included in an > or omitting it altogether). In some cases > the Subject can be a value representing an anonymous or pseudonymous user > as described in Section 6.3.1 of the Assertion Framework for OAuth 2.0 > Client Authentication and Authorization Grants [*http://tools.ietf.org/ht= ml/draft-ietf-oauth-assertions-16#section-6.3.1 > = * > ]. > > > On Sat, Jul 19, 2014 at 8:24 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Thanks for the quick response, Brian. I think the text looks great. Th= e >> only change I'd like to suggest is in the second sentence, to change the >> 'may' to 'SHOULD'. >> >> Best regards, >> Kathleen >> >> Sent from my iPhone >> >> On Jul 19, 2014, at 1:00 AM, Brian Campbell >> wrote: >> >> How about the following (which is intentionally similar to the text I >> just put forth for your request for privacy consideration in >> draft-ietf-oauth-jwt-bearer-09)? >> >> A SAML Assertion may contain privacy-sensitive information and, to >> prevent disclosure of such information to unintended parties, should onl= y >> be transmitted over encrypted channels, such as TLS. In cases where it= =E2=80=99s >> desirable to prevent disclosure of certain information the client, the >> Subject and/or individual attributes of a SAML Assertion may be encrypte= d >> to the authorization server. >> >> Deployments should determine the minimum amount of information necessary >> to complete the exchange and include only that information in an Asserti= on >> (typically by limiting what information is included in an >> or omitting it altogether). In some cases >> the Subject can be a value representing an anonymous or pseudonymous use= r >> as described in Section 6.3.1 of the Assertion Framework for OAuth 2.0 >> Client Authentication and Authorization Grants [*http://tools.ietf.org/h= tml/draft-ietf-oauth-assertions-16#section-6.3.1 >> * >> ]. >> >> >> On Tue, Jul 15, 2014 at 2:04 PM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >>> Hello, >>> >>> I just finished my review of >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer. The >>> draft looks great, thank you for all of your efforts on it! >>> >>> I did notice that there were no privacy considerations pointing back to >>> RFC6973, could that text be added? The draft came after the Oauth >>> framework publication (refernced in the security considerations), so I = am >>> guessing that is why this was missed as there are privacy consideration= s in >>> the oauth assertion draft (I competed that review as well and the draft >>> looked great. I don't have any comments to add prior to progressing th= e >>> draft). >>> >>> Thank you. >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > --=20 Best regards, Kathleen --001a11c33fcc35984404fe9fd49b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Brian. =C2=A0That looks good to me. =C2=A0
Kathleen


On Sat, Jul 19, 2014 at 5:18 PM, Brian Campbell <bcamp= bell@pingidentity.com> wrote:
Thanks Kathleen, that makes= sense. I do, however, think that a little 'should' would be more a= ppropriate there than a big 'SHOULD' as there's no other use of= RFC2119 language in that text. That okay by you? It would read like this:<= br>

A S= AML Assertion=C2=A0may contain=20 privacy-sensitive information and,=C2=A0to prevent disclosure of=20 such=C2=A0information to unintended parties,=C2=A0should=C2=A0only be trans= mitted=20 over=C2=A0encrypted channels, such as TLS.=C2=A0In cases where it=E2=80=99s= desirable to=20 prevent=C2=A0disclosure of=C2=A0certain=C2=A0information=C2=A0the client, t= he Subject and/or individual attributes of a=C2=A0SAML=C2=A0Assertion should be encrypted to= the=20 authorization server.=C2=A0


Deployments should=C2=A0determine the minim= um=20 amount of=C2=A0information=C2=A0necessary to complete the=C2=A0exchange and= include=20 only that information in an=C2=A0Assertion (typically by limiting what=20 information is included in an <AttributeStatement> or omitting it=20 altogether).=C2=A0In some cases the=C2=A0Subject=C2=A0can be a value repres= enting=20 an=C2=A0anonymous or=C2=A0pseudonymous user as described in Section 6.3.1 o= f the=20 Assertion Framework for OAuth 2.0 Client Authentication and=20 Authorization Grants [http://tools.ietf.org/html/draft-ietf-o= auth-assertions-16#section-6.3.1].


On Sat, Jul 19, 2014 at 8:= 24 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<= /a>> wrote:
Thanks for the quick = response, Brian. =C2=A0I think the text looks great. =C2=A0The only change = I'd like to suggest is in the second sentence, to change the 'may&#= 39; to 'SHOULD'.

Best regards,
Kathleen=C2=A0

Sent from= my iPhone
How about the fol= lowing (which is intentionally similar to the text I just put forth for you= r request for privacy consideration in draft-ietf-oauth-jwt-bearer-09)?

A SAML = Assertion=C2=A0may contain privacy-sensitive information and,=C2=A0to preve= nt disclosure of such=C2=A0information to unintended parties,=C2=A0should= =C2=A0only be transmitted over=C2=A0encrypted channels, such as TLS.=C2=A0I= n cases where it=E2=80=99s desirable to prevent=C2=A0disclosure of=C2=A0cer= tain=C2=A0information=C2=A0the client, the Subject and/or individual attrib= utes of a=C2=A0SAML=C2=A0Assertion may be encrypted to the authorization se= rver.=C2=A0

Deployments should=C2=A0determine the minim= um amount of=C2=A0information=C2=A0necessary to complete the=C2=A0exchange = and include only that information in an=C2=A0Assertion (typically by limiti= ng what information is included in an <AttributeStatement> or omittin= g it altogether).=C2=A0In some cases the=C2=A0Subject=C2=A0can be a value r= epresenting an=C2=A0anonymous or=C2=A0pseudonymous user as described in Sec= tion 6.3.1 of the Assertion Framework for OAuth 2.0 Client Authentication a= nd Authorization Grants [http://tools.ietf.org/html/draft-iet= f-oauth-assertions-16#section-6.3.1].


On Tue, Jul 15, 2014 at 2:04 PM, Kathleen Moriarty <= ;kath= leen.moriarty.ietf@gmail.com> wrote:
Hello,

I= just finished my review of=C2=A0http://datatracker.ietf.o= rg/doc/draft-ietf-oauth-saml2-bearer. =C2=A0The draft looks great, than= k you for all of your efforts on it!

I did notice that there were no privacy considerations = pointing back to RFC6973, could that text be added? =C2=A0The draft came af= ter the Oauth framework publication (refernced in the security consideratio= ns), so I am guessing that is why this was missed as there are privacy cons= iderations in the oauth assertion draft (I competed that review as well and= the draft looked great. =C2=A0I don't have any comments to add prior t= o progressing the draft).

Thank you.

--

Best regards,
Kathlee= n

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






--
=

Best regards,
Kathleen
--001a11c33fcc35984404fe9fd49b-- From nobody Sun Jul 20 07:48:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DE81B2818 for ; Sun, 20 Jul 2014 07:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txlS9Sk-Z93d for ; Sun, 20 Jul 2014 07:48:29 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477551B2814 for ; Sun, 20 Jul 2014 07:48:29 -0700 (PDT) Received: from mail-ie0-f174.google.com ([209.85.223.174]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKU8vWvDsEyvK0qJMiRpXfJA/mQUWTs2JI@postini.com; Sun, 20 Jul 2014 07:48:29 PDT Received: by mail-ie0-f174.google.com with SMTP id rp18so6085422iec.33 for ; Sun, 20 Jul 2014 07:48:28 -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=lFWjNY80aMHLNYjE2AVbs3nHDLobrSN60qCNshxrFWY=; b=DTFyRdPvpPki2TL3fP8VumMUwJ8RMPCK/TJgjkz3pjm9+Ko4+tu8MQCuVb08/s1sAG u+kw9Kjr7TAYzpMzaNFktF/JMb8Wko4AqOfKtuZVuNygjXEVhCHLvpIpeNOQH16RBxQo dJx8e0GACyji1JuSjRocJVLY+rV+84/vODZlEYFYh+vZ5SW1pTNEGapn5TZuqzBt25iS 4Wc7PpHpEo+IpzHTLWfMnwzNV2hm/R9o3YA6mxtefIw7VQT9KAeEYrwyIi/BIjpICRp3 Jo4gZJigZcd+hpK9ccFXtWzYDFTX5IfOeWO1VmhxOD9qNhWA1LpWfMZrT4OjBQ8CYhwZ iz4Q== X-Gm-Message-State: ALoCoQkV5zdPWhgHskX7eafNSyBI2VzVt+hWyJluv2I1vpyOjLIw0i0ohyg1GM684SlmZLO7Wugr67VVvz7Zy9urziqtMy2NcP8gKklKOOG27I9a/mFQ/Bkn8AXH/fbUf6mtVVxlP18m X-Received: by 10.42.82.6 with SMTP id b6mr4553057icl.51.1405867708545; Sun, 20 Jul 2014 07:48:28 -0700 (PDT) X-Received: by 10.42.82.6 with SMTP id b6mr4553041icl.51.1405867708411; Sun, 20 Jul 2014 07:48:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Sun, 20 Jul 2014 07:47:58 -0700 (PDT) In-Reply-To: References: <60D7F5DB-0574-4F58-ADCB-C9E4D9850401@gmail.com> From: Brian Campbell Date: Sun, 20 Jul 2014 07:47:58 -0700 Message-ID: To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=485b397dd7015c8ad104fea115ad Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/W6Axintbxj-__HPVeUeRMt3m4PM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD Review of http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer 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: Sun, 20 Jul 2014 14:48:31 -0000 --485b397dd7015c8ad104fea115ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Great, thanks Kathleen. I'll get new drafts published soon(ish). On Sun, Jul 20, 2014 at 6:18 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Thanks, Brian. That looks good to me. > > Kathleen > > > On Sat, Jul 19, 2014 at 5:18 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Thanks Kathleen, that makes sense. I do, however, think that a little >> 'should' would be more appropriate there than a big 'SHOULD' as there's = no >> other use of RFC2119 language in that text. That okay by you? It would r= ead >> like this: >> >> >> A SAML Assertion may contain privacy-sensitive information and, to >> prevent disclosure of such information to unintended parties, should onl= y >> be transmitted over encrypted channels, such as TLS. In cases where it= =E2=80=99s >> desirable to prevent disclosure of certain information the client, the >> Subject and/or individual attributes of a SAML Assertion should be >> encrypted to the authorization server. >> >> >> Deployments should determine the minimum amount of information necessary >> to complete the exchange and include only that information in an Asserti= on >> (typically by limiting what information is included in an >> or omitting it altogether). In some cases >> the Subject can be a value representing an anonymous or pseudonymous use= r >> as described in Section 6.3.1 of the Assertion Framework for OAuth 2.0 >> Client Authentication and Authorization Grants [*http://tools.ietf.org/h= tml/draft-ietf-oauth-assertions-16#section-6.3.1 >> * >> ]. >> >> >> On Sat, Jul 19, 2014 at 8:24 AM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >>> Thanks for the quick response, Brian. I think the text looks great. >>> The only change I'd like to suggest is in the second sentence, to chan= ge >>> the 'may' to 'SHOULD'. >>> >>> Best regards, >>> Kathleen >>> >>> Sent from my iPhone >>> >>> On Jul 19, 2014, at 1:00 AM, Brian Campbell >>> wrote: >>> >>> How about the following (which is intentionally similar to the text I >>> just put forth for your request for privacy consideration in >>> draft-ietf-oauth-jwt-bearer-09)? >>> >>> A SAML Assertion may contain privacy-sensitive information and, to >>> prevent disclosure of such information to unintended parties, should on= ly >>> be transmitted over encrypted channels, such as TLS. In cases where it= =E2=80=99s >>> desirable to prevent disclosure of certain information the client, the >>> Subject and/or individual attributes of a SAML Assertion may be encrypt= ed >>> to the authorization server. >>> >>> Deployments should determine the minimum amount of information necessar= y >>> to complete the exchange and include only that information in an Assert= ion >>> (typically by limiting what information is included in an >>> or omitting it altogether). In some cases >>> the Subject can be a value representing an anonymous or pseudonymous us= er >>> as described in Section 6.3.1 of the Assertion Framework for OAuth 2.0 >>> Client Authentication and Authorization Grants [*http://tools.ietf.org/= html/draft-ietf-oauth-assertions-16#section-6.3.1 >>> * >>> ]. >>> >>> >>> On Tue, Jul 15, 2014 at 2:04 PM, Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> wrote: >>> >>>> Hello, >>>> >>>> I just finished my review of >>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer. The >>>> draft looks great, thank you for all of your efforts on it! >>>> >>>> I did notice that there were no privacy considerations pointing back t= o >>>> RFC6973, could that text be added? The draft came after the Oauth >>>> framework publication (refernced in the security considerations), so I= am >>>> guessing that is why this was missed as there are privacy consideratio= ns in >>>> the oauth assertion draft (I competed that review as well and the draf= t >>>> looked great. I don't have any comments to add prior to progressing t= he >>>> draft). >>>> >>>> Thank you. >>>> >>>> -- >>>> >>>> Best regards, >>>> Kathleen >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >> > > > -- > > Best regards, > Kathleen > --485b397dd7015c8ad104fea115ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great, thanks Kathleen. I'll get new drafts published = soon(ish).


On Sun, Jul 20, 2014 at 6:18 AM, Kathleen Moriarty <= kathleen.moriarty.ietf@gmail.com> wrote:
Thanks, Brian. =C2=A0That l= ooks good to me. =C2=A0

Kathleen


On Sat, Jul 19, 2014 at 5:18 PM, Brian C= ampbell <bcampbell@pingidentity.com> wrote:
Thanks Kathleen, that makes= sense. I do, however, think that a little 'should' would be more a= ppropriate there than a big 'SHOULD' as there's no other use of= RFC2119 language in that text. That okay by you? It would read like this:<= br>

A S= AML Assertion=C2=A0may contain=20 privacy-sensitive information and,=C2=A0to prevent disclosure of=20 such=C2=A0information to unintended parties,=C2=A0should=C2=A0only be trans= mitted=20 over=C2=A0encrypted channels, such as TLS.=C2=A0In cases where it=E2=80=99s= desirable to=20 prevent=C2=A0disclosure of=C2=A0certain=C2=A0information=C2=A0the client, t= he Subject and/or individual attributes of a=C2=A0SAML=C2=A0Assertion should be encrypted to= the=20 authorization server.=C2=A0


Deployments should=C2=A0determine the minim= um=20 amount of=C2=A0information=C2=A0necessary to complete the=C2=A0exchange and= include=20 only that information in an=C2=A0Assertion (typically by limiting what=20 information is included in an <AttributeStatement> or omitting it=20 altogether).=C2=A0In some cases the=C2=A0Subject=C2=A0can be a value repres= enting=20 an=C2=A0anonymous or=C2=A0pseudonymous user as described in Section 6.3.1 o= f the=20 Assertion Framework for OAuth 2.0 Client Authentication and=20 Authorization Grants [http://tools.ietf.org/html/draft-ietf-o= auth-assertions-16#section-6.3.1].


On Sat, Jul 19, 2014 at 8:24 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Thanks for the quick = response, Brian. =C2=A0I think the text looks great. =C2=A0The only change = I'd like to suggest is in the second sentence, to change the 'may&#= 39; to 'SHOULD'.

Best regards,
Kathleen=C2=A0

Sent from= my iPhone

On Jul 19, 2014, at 1:00 AM, Brian Campb= ell <bca= mpbell@pingidentity.com> wrote:

How about the fol= lowing (which is intentionally similar to the text I just put forth for you= r request for privacy consideration in draft-ietf-oauth-jwt-bearer-09)?

A SAML = Assertion=C2=A0may contain privacy-sensitive information and,=C2=A0to preve= nt disclosure of such=C2=A0information to unintended parties,=C2=A0should= =C2=A0only be transmitted over=C2=A0encrypted channels, such as TLS.=C2=A0I= n cases where it=E2=80=99s desirable to prevent=C2=A0disclosure of=C2=A0cer= tain=C2=A0information=C2=A0the client, the Subject and/or individual attrib= utes of a=C2=A0SAML=C2=A0Assertion may be encrypted to the authorization se= rver.=C2=A0

Deployments should=C2=A0determine the minim= um amount of=C2=A0information=C2=A0necessary to complete the=C2=A0exchange = and include only that information in an=C2=A0Assertion (typically by limiti= ng what information is included in an <AttributeStatement> or omittin= g it altogether).=C2=A0In some cases the=C2=A0Subject=C2=A0can be a value r= epresenting an=C2=A0anonymous or=C2=A0pseudonymous user as described in Sec= tion 6.3.1 of the Assertion Framework for OAuth 2.0 Client Authentication a= nd Authorization Grants [http://tools.ietf.org/html/draft-iet= f-oauth-assertions-16#section-6.3.1].


On Tue, Jul 15, 2014 at 2:04 PM, Kathleen Moriarty <= ;kath= leen.moriarty.ietf@gmail.com> wrote:
Hello,

I= just finished my review of=C2=A0http://datatracker.ietf.o= rg/doc/draft-ietf-oauth-saml2-bearer. =C2=A0The draft looks great, than= k you for all of your efforts on it!

I did notice that there were no privacy considerations = pointing back to RFC6973, could that text be added? =C2=A0The draft came af= ter the Oauth framework publication (refernced in the security consideratio= ns), so I am guessing that is why this was missed as there are privacy cons= iderations in the oauth assertion draft (I competed that review as well and= the draft looked great. =C2=A0I don't have any comments to add prior t= o progressing the draft).

Thank you.

--

Best regards,
Kathlee= n

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






<= /div>--

Best regards,
Kathleen
--485b397dd7015c8ad104fea115ad-- From nobody Mon Jul 21 06:59:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484501A0004; Mon, 21 Jul 2014 06:59:09 -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 B3MeCx6mgsBh; Mon, 21 Jul 2014 06:59:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF861A005D; Mon, 21 Jul 2014 06:57:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721135732.24266.98084.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 06:57:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DIxgOGzQOkUKeZPOUlKDpGD186s Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-00.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, 21 Jul 2014 13:59:09 -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-00.txt Pages : 23 Date : 2014-07-21 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: http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-00 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 Jul 21 06:59:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD66A1A00A7; Mon, 21 Jul 2014 06:59:32 -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 OswekZtJMVLh; Mon, 21 Jul 2014 06:59:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E151A0016; Mon, 21 Jul 2014 06:57:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721135747.26912.57174.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 06:57:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/xKZt-sYXYxp42OSeVnVe8nFffm8 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-00.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, 21 Jul 2014 13:59:32 -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-00.txt Pages : 18 Date : 2014-07-21 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: http://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-00 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 Jul 21 07:00:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17731A001D; Mon, 21 Jul 2014 06:59:54 -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 ry3NwfhJwhdY; Mon, 21 Jul 2014 06:59:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6BA1A000D; Mon, 21 Jul 2014 06:58:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721135803.29353.8982.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 06:58:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/VCRYCMXC2oUyb3UdR20qQI1sOCU Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-00.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, 21 Jul 2014 13:59:55 -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 Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jones John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-proof-of-possession-00.txt Pages : 11 Date : 2014-07-21 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. This property 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: http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-00 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 Jul 21 07:00:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA33E1A000B; Mon, 21 Jul 2014 07:00: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] 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 JOv_hCQRS1xF; Mon, 21 Jul 2014 07:00:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A52B1A001E; Mon, 21 Jul 2014 06:58:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721135816.30459.4950.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 06:58:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/0PAXam31l1o-J9oH6GKAYRFX-Ro Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.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, 21 Jul 2014 14:00:09 -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 : A Method for Signing an HTTP Requests for OAuth Authors : Justin Richer John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-signed-http-request-00.txt Pages : 11 Date : 2014-07-21 Abstract: This document a method for offering data origin authentication and integrity protection of HTTP requests. To convey the relevant data items in the request a JSON-based encapsulation is used and the JSON Web Signature (JWS) technique is re-used. JWS offers integrity protection using symmetric as well as asymmetric cryptography. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00 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 Jul 21 12:06:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8291A03AF for ; Mon, 21 Jul 2014 12:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPPlYLqhN51P for ; Mon, 21 Jul 2014 12:05:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6B01A037D for ; Mon, 21 Jul 2014 12:05:56 -0700 (PDT) Received: from CH1PR03CA010.namprd03.prod.outlook.com (10.255.156.155) by CY1PR0301MB0729.namprd03.prod.outlook.com (25.160.159.147) with Microsoft SMTP Server (TLS) id 15.0.985.8; Mon, 21 Jul 2014 19:05:54 +0000 Received: from BN1BFFO11FD010.protection.gbl (10.255.156.132) by CH1PR03CA010.outlook.office365.com (10.255.156.155) with Microsoft SMTP Server (TLS) id 15.0.990.7 via Frontend Transport; Mon, 21 Jul 2014 19:05:54 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD010.mail.protection.outlook.com (10.58.144.73) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Mon, 21 Jul 2014 19:05:54 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0195.002; Mon, 21 Jul 2014 19:05:43 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpRX60tv8mDmAzEK7KukSZJpZLJuq4fag Date: Mon, 21 Jul 2014 19:05:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADDA25E@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <20140721185955.29738.31476.idtracker@ietfa.amsl.com> In-Reply-To: <20140721185955.29738.31476.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADDA25ETK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(448002)(189002)(377454003)(199002)(13464003)(377424004)(81156004)(50986999)(4396001)(95666004)(77982001)(87936001)(81542001)(19625215002)(15975445006)(77096002)(15202345003)(83322001)(104016003)(74502001)(85326001)(76176999)(84676001)(46102001)(81342001)(107046002)(71186001)(76482001)(86612001)(66066001)(106466001)(21056001)(19580405001)(85306003)(84326002)(97736001)(44976005)(19580395003)(19300405004)(74662001)(110136001)(92566001)(69596002)(31966008)(55846006)(2656002)(80022001)(20776003)(83072002)(54356999)(79102001)(512874002)(92726001)(99396002)(2351001)(86362001)(64706001)(26826002)(85852003)(16236675004)(107886001)(33656002)(106116001)(19617315012)(6806004)(68736004); DIR:OUT; SFP:; SCL:1; SRVR:CY1PR0301MB0729; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0279B3DD0D Received-SPF: PermError (: domain of microsoft.com used an invalid SPF mechanism) Authentication-Results: spf=permerror (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FFccrW5-7veWvL-opIN7SvETLkA Subject: [OAUTH-WG] FW: New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Mon, 21 Jul 2014 19:06:00 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADDA25ETK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2hhbmdlcyBpbiB0aGlzIHZlcnNpb24gYXJlOg0KDQrCtyAgICAgICAgQWRkZWQgdGhlIEF1dGhl bnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzIHJlZ2lzdHJ5Lg0KDQrCtyAgICAgICAg UmVuYW1lZCB0aGUgY29kZV9mb3JfaWRfdG9rZW4gZ3JhbnQgdHlwZSB0byB1cm46aWV0ZjpwYXJh bXM6b2F1dGg6Z3JhbnQtdHlwZTpjb2RlLWZvci1pZC10b2tlbiB0byBjb25mb3JtIHRvIFNlY3Rp b24gNC41IG9mIFJGQyA2NzQ5Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXQ0KU2VudDogTW9uZGF5LCBKdWx5IDIxLCAyMDE0IDEyOjAwIFBN DQpUbzogUGhpbCBIdW50OyBBbnRob255IE5hZGFsaW47IFBoaWwgSHVudDsgTWlrZSBKb25lczsg QW50aG9ueSBOYWRhbGluOyBNaWtlIEpvbmVzDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0DQoNCg0KDQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0 DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWljaGFlbCBCLiBKb25lcyBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCg0KDQpOYW1lOiAgICAgICAgICAg ICAgICAgIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMNCg0KUmV2aXNpb246ICAgICAgICAg ICAgICAwNQ0KDQpUaXRsZTogICAgICAgICAgICAgICAgICAgICBQcm92aWRpbmcgVXNlciBBdXRo ZW50aWNhdGlvbiBJbmZvcm1hdGlvbiB0byBPQXV0aCAyLjAgQ2xpZW50cw0KDQpEb2N1bWVudCBk YXRlOiAyMDE0LTA3LTIxDQoNCkdyb3VwOiAgICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KDQpQYWdlczogICAgICAgICAgICAgICAgICAxOQ0KDQpVUkw6ICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHVudC1vYXV0aC12Mi11 c2VyLWE0Yy0wNS50eHQNCg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMvDQoNCkh0bWxpemVkOiAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRj LTA1DQoNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA1DQoNCg0KDQpBYnN0cmFjdDoNCg0KICAgVGhp cyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSB3YXkgZm9yIE9BdXRoIDIuMCBjbGllbnRzIHRvIHZl cmlmeSB0aGUNCg0KICAgaWRlbnRpdHkgb2YgdGhlIEVuZC1Vc2VyIGFuZCBvYnRhaW4gY29uc2Vu dCBiYXNlZCB1cG9uIHRoZQ0KDQogICBhdXRoZW50aWNhdGlvbiBwZXJmb3JtZWQgYnkgYW4gQXV0 aG9yaXphdGlvbiBTZXJ2ZXIuICBUaGUNCg0KICAgaW50ZXJhY3Rpb25zIGRlZmluZWQgYnkgdGhp cyBzcGVjaWZpY2F0aW9uIGFyZSBpbnRlbnRpb25hbGx5DQoNCiAgIGNvbXBhdGlibGUgd2l0aCB0 aGUgT3BlbklEIENvbm5lY3QgcHJvdG9jb2wuDQoNCg0KDQoNCg0KDQoNCg0KDQpQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_4E1F6AAD24975D4BA5B16804296739439ADDA25ETK5EX14MBXC294r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc2FtcA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQ YXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21z by1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWlu IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ bGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjQxNTU5MzM5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczo5Njk3MjIyNzQgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEN Cgl7bXNvLWxpc3QtaWQ6MTU2ODQ4NTYwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMjUyOTQ1 OTE4O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI0LjBwdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo2MC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjYwLjBwdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo5Ni4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Ojk2LjBwdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEzMi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEzMi4w cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxNjguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDoxNjguMHB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MjA0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJbWFyZ2luLWxlZnQ6MjA0LjBwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI0MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI0MC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNzYuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyNzYuMHB0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzEyLjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzEyLjBwdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6ODYzNDQ1NDgyOw0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQ3MDQ4Njc5MiA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6Ljc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEuMjVpbjsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6MS43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIuMjVpbjsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6Mi43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoz LjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6My43NWluOw0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDo0LjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQuNzVpbjsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5DaGFuZ2VzIGluIHRoaXMgdmVy c2lvbiBhcmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1yaWdodDouMjVpbjttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFkZGVkIHRoZSBBdXRoZW50aWNhdGlvbiBNZXRob2Qg UmVmZXJlbmNlIFZhbHVlcyByZWdpc3RyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1yaWdodDouMjVpbjttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xv cjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlbmFtZWQg dGhlDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5jb2RlX2Zvcl9pZF90 b2tlbjwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4gZ3JhbnQgdHlwZSB0bw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+dXJuOmlldGY6cGFyYW1zOm9hdXRoOmdyYW50LXR5cGU6Y29kZS1mb3ItaWQtdG9rZW48L3Nw YW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IHRv IGNvbmZvcm0gdG8gU2VjdGlvbiA0LjUNCiBvZiBSRkMgNjc0OS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gPGJyPg0KU2VudDogTW9uZGF5LCBKdWx5IDIxLCAyMDE0IDEyOjAwIFBNPGJyPg0KVG86 IFBoaWwgSHVudDsgQW50aG9ueSBOYWRhbGluOyBQaGlsIEh1bnQ7IE1pa2UgSm9uZXM7IEFudGhv bnkgTmFkYWxpbjsgTWlrZSBKb25lczxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQ8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5oYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IE1pY2hhZWwgQi4gSm9uZXMgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5OYW1lOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC1odW50LW9hdXRoLXYyLXVz ZXItYTRjPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZXZpc2lvbjom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMDU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBQcm92aWRpbmcgVXNlciBBdXRoZW50aWNhdGlvbiBJbmZvcm1h dGlvbiB0byBPQXV0aCAyLjAgQ2xpZW50czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+RG9jdW1lbnQgZGF0ZTogMjAxNC0wNy0yMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+R3JvdXA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+UGFnZXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDE5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5V Ukw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0Ij4NCjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dDwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdGF0dXM6Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMv Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odW50LW9hdXRoLXYyLXVzZXIt YTRjLzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5I dG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNSI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNTwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5EaWZmOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1odW50LW9h dXRoLXYyLXVzZXItYTRjLTA1Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lIj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1o dW50LW9hdXRoLXYyLXVzZXItYTRjLTA1PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+QWJzdHJhY3Q6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSB3YXkgZm9yIE9BdXRo IDIuMCBjbGllbnRzIHRvIHZlcmlmeSB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBpZGVudGl0eSBvZiB0aGUgRW5kLVVzZXIgYW5kIG9idGFp biBjb25zZW50IGJhc2VkIHVwb24gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsgYXV0aGVudGljYXRpb24gcGVyZm9ybWVkIGJ5IGFuIEF1dGhv cml6YXRpb24gU2VydmVyLiZuYnNwOyBUaGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBpbnRlcmFjdGlvbnMgZGVmaW5lZCBieSB0aGlzIHNwZWNp ZmljYXRpb24gYXJlIGludGVudGlvbmFsbHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBjb21wYXRpYmxlIHdpdGggdGhlIE9wZW5JRCBDb25uZWN0 IHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIElFVEYgU2VjcmV0 YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439ADDA25ETK5EX14MBXC294r_-- From nobody Mon Jul 21 13:47:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAE01A0328 for ; Mon, 21 Jul 2014 13:47: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 unouc5rBSnik for ; Mon, 21 Jul 2014 13:47:15 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4171A0070 for ; Mon, 21 Jul 2014 13:47:14 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id s7so5188993lbd.14 for ; Mon, 21 Jul 2014 13:47:13 -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=wS7FDP/WiO1BKAg7JgzPgxjAQSCJrXo94g8PKca9maE=; b=VS37zeMMnICZc16RoR1kSB/AeL1K2+LkkFEUAHCHXstictSf8dqNEHA9wJFYoAstht hfUccTamfKuMrf74IIOvxZ7DoG12b9kq+HMeMiTRVXsugWO+SIw21ekzT5gwCXELdmoT Yq7So9gPeTE2A9bTHxoiJgi+m+vfvLHxXgPBG8/SUzWp0ha+2cOZFd3PmKV0sEGyu0o7 2f+p0e3LhNaQM97IRbgsPmuTbLE55UdKgswu1PWvNQj0h6KI+YsTEdQHNijzwgkJ4ZJA clWopnUgpDPeAPcAep1Ol3Rj6YQ5jvGwQIGxwYKt9Suomcttq7IkJc9xQWEr0h/ilZb/ x4EQ== MIME-Version: 1.0 X-Received: by 10.112.56.148 with SMTP id a20mr28122894lbq.72.1405975632880; Mon, 21 Jul 2014 13:47:12 -0700 (PDT) Received: by 10.152.113.73 with HTTP; Mon, 21 Jul 2014 13:47:12 -0700 (PDT) Received: by 10.152.113.73 with HTTP; Mon, 21 Jul 2014 13:47:12 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADDA25E@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <20140721185955.29738.31476.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439ADDA25E@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Mon, 21 Jul 2014 22:47:12 +0200 Message-ID: From: Thomas Broyer To: Mike Jones Content-Type: multipart/alternative; boundary=001a113393c829354004feba3694 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/aDbtNbACGcbuU12eXXxxmPoxsbY Cc: "" Subject: Re: [OAUTH-WG] FW: New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Mon, 21 Jul 2014 20:47:17 -0000 --001a113393c829354004feba3694 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The end of section 2.2 talks about prompt=3Dconsent but the value is not defined above. Also, I don't understand the note about "pwd" being used by a service. In which scenario would that happen? Finally, what's the difference between providing several values for "amr" with and without including "mfa"? IOW, what's the use case for mfa? Le 21 juil. 2014 21:06, "Mike Jones" a =C3=A9= crit : > Changes in this version are: > > =C2=B7 Added the Authentication Method Reference Values registry. > > =C2=B7 Renamed the code_for_id_token grant type to > urn:ietf:params:oauth:grant-type:code-for-id-token to conform to Section > 4.5 of RFC 6749. > > -- Mike > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 21, 2014 12:00 PM > To: Phil Hunt; Anthony Nadalin; Phil Hunt; Mike Jones; Anthony Nadalin; > Mike Jones > Subject: New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt > > > > > > A new version of I-D, draft-hunt-oauth-v2-user-a4c-05.txt > > has been successfully submitted by Michael B. Jones and posted to the IET= F > repository. > > > > Name: draft-hunt-oauth-v2-user-a4c > > Revision: 05 > > Title: Providing User Authentication Information to > OAuth 2.0 Clients > > Document date: 2014-07-21 > > Group: Individual Submission > > Pages: 19 > > URL: > http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-05.txt > > Status: > https://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c/ > > Htmlized: http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-0= 5 > > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-oauth-v2-user-a4c-05 > > > > Abstract: > > This specification defines a way for OAuth 2.0 clients to verify the > > identity of the End-User and obtain consent based upon the > > authentication performed by an Authorization Server. The > > interactions defined by this specification are intentionally > > compatible with the OpenID Connect protocol. > > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113393c829354004feba3694 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The end of section 2.2 talks about prompt=3Dconsent but the = value is not defined above.

Also, I don't understand the note about "pwd" = being used by a service. In which scenario would that happen?

Finally, what's the difference between providing several= values for "amr" with and without including "mfa"? IOW= , what's the use case for mfa?

Le 21 juil. 2014 21:06, "Mike Jones" &= lt;Michael.Jones@microsoft.c= om> a =C3=A9crit :

Changes in this version are:

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Added the = Authentication Method Reference Values registry.

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Renamed th= e code_for_id_token grant type to urn:ietf:params:oauth:grant-type:code-for-id-token= to conform to Section 4.5 of RFC 6749.

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

=C2=A0

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, July 21, 2014 12:00 PM
To: Phil Hunt; Anthony Nadalin; Phil Hunt; Mike Jones; Anthony Nadalin; Mik= e Jones
Subject: New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

=C2=A0

=C2=A0

A new version of I-D, draft-hunt-oauth-v2-user-a4c-05.txt<= /p>

has been successfully submitted by Michael B. Jones and posted to the IE= TF repository.

=C2=A0

Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-hunt-oauth-v2-user-a4c=

Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 05

Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Providing User Authe= ntication Information to OAuth 2.0 Clients

Document date: 2014-07-21

Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Individual Submission

Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 19

URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= a href=3D"http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-= 05.txt" target=3D"_blank"> http://www.ietf.org/i= nternet-drafts/draft-hunt-oauth-v2-user-a4c-05.txt=

Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.i= etf.org/doc/draft-hunt-oauth-v2-user-a4c/

Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org= /html/draft-hunt-oauth-v2-user-a4c-05

Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/r= fcdiff?url2=3Ddraft-hunt-oauth-v2-user-a4c-05

=C2=A0

Abstract:

=C2=A0=C2=A0 This specification defines a way for OAuth 2.0 clients to v= erify the

=C2=A0=C2=A0 identity of the End-User and obtain consent based upon the<= u>

=C2=A0=C2=A0 authentication performed by an Authorization Server.=C2=A0 = The

=C2=A0=C2=A0 interactions defined by this specification are intentionall= y

=C2=A0=C2=A0 compatible with the OpenID Connect protocol.<= /p>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

=C2=A0

Please note that it may take a couple of minutes from the time of submis= sion until the htmlized version and diff are available at tools.ietf.org.

=C2=A0

The IETF Secretariat

=C2=A0


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

--001a113393c829354004feba3694-- From nobody Mon Jul 21 14:53:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A841A0110 for ; Mon, 21 Jul 2014 14:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXLX6iIOjupc for ; Mon, 21 Jul 2014 14:53:12 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56CEE1A006B for ; Mon, 21 Jul 2014 14:53:12 -0700 (PDT) Received: from BN3PR0301CA0033.namprd03.prod.outlook.com (25.160.180.171) by BL2PR03MB243.namprd03.prod.outlook.com (10.255.231.23) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 21:53:10 +0000 Received: from BL2FFO11FD050.protection.gbl (2a01:111:f400:7c09::111) by BN3PR0301CA0033.outlook.office365.com (2a01:111:e400:4000::43) with Microsoft SMTP Server (TLS) id 15.0.990.7 via Frontend Transport; Mon, 21 Jul 2014 21:53:11 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD050.mail.protection.outlook.com (10.173.161.212) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Mon, 21 Jul 2014 21:53:10 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0195.002; Mon, 21 Jul 2014 21:52:37 +0000 From: Mike Jones To: Thomas Broyer Thread-Topic: [OAUTH-WG] FW: New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpRX60tv8mDmAzEK7KukSZJpZLJuq4faggAAdwgCAABC0oA== Date: Mon, 21 Jul 2014 21:52:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADDAA2D@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <20140721185955.29738.31476.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439ADDA25E@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADDAA2DTK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(13464003)(199002)(189002)(377424004)(377454003)(33656002)(44976005)(79102001)(19300405004)(6806004)(15202345003)(69596002)(74502001)(87936001)(83072002)(92726001)(26826002)(76482001)(4396001)(2656002)(77982001)(19625215002)(85852003)(55846006)(19580395003)(54356999)(84676001)(50986999)(107046002)(15975445006)(68736004)(83322001)(74662001)(104016003)(110136001)(95666004)(16601075003)(19580405001)(76176999)(99396002)(85306003)(106466001)(81156004)(21056001)(512874002)(106116001)(97736001)(84326002)(16236675004)(77096002)(71186001)(64706001)(20776003)(80022001)(66066001)(19617315012)(86612001)(81342001)(46102001)(86362001)(92566001)(81542001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB243; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0279B3DD0D Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/P4pGb2_eWZOUmKBZgj_a5tEP1Nw Cc: "" Subject: Re: [OAUTH-WG] FW: New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Mon, 21 Jul 2014 21:53:14 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADDAA2DTK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIHJldmlldywgVGhvbWFzLiAgVGhlIOKAnHByb21wdD1jb25zZW504oCd IGRlZmluaXRpb24gYmVpbmcgbWlzc2luZyBpcyBhbiBlZGl0b3JpYWwgZXJyb3IuICBJdCBzaG91 bGQgYmU6DQoNCmNvbnNlbnQNClRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBTSE9VTEQgcHJvbXB0 IHRoZSBFbmQtVXNlciBmb3IgY29uc2VudCBiZWZvcmUgcmV0dXJuaW5nIGluZm9ybWF0aW9uIHRv IHRoZSBDbGllbnQuIElmIGl0IGNhbm5vdCBvYnRhaW4gY29uc2VudCwgaXQgTVVTVCByZXR1cm4g YW4gZXJyb3IsIHR5cGljYWxseSBjb25zZW50X3JlcXVpcmVkLg0KDQpJ4oCZbGwgcGxhbiB0byBh ZGQgaXQgaW4gdGhlIG5leHQgZHJhZnQuDQoNCkkgYWdyZWUgdGhhdCB0aGVyZeKAmXMgbm8gZGlm ZmVyZW5jZSBiZXR3ZWVuIGEgcmVzcG9uc2Ugd2l0aCBtdWx0aXBsZSDigJxhbXLigJ0gdmFsdWVz IHRoYXQgaW5jbHVkZXMg4oCcbWZh4oCdIGFuZCBvbmUgdGhhdCBkb2VzbuKAmXQuICBVbmxlc3Mg YSBjbGVhciB1c2UgY2FzZSBmb3Igd2h5IOKAnG1mYeKAnSBpcyBuZWVkZWQgY2FuIGJlIGlkZW50 aWZpZWQsIHdlIGNhbiBkZWxldGUgaXQgaW4gdGhlIG5leHQgZHJhZnQuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UN Cg0KRnJvbTogVGhvbWFzIEJyb3llciBbbWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbV0NClNlbnQ6 IE1vbmRheSwgSnVseSAyMSwgMjAxNCAxOjQ3IFBNDQpUbzogTWlrZSBKb25lcw0KQ2M6IDxvYXV0 aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEZXOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0DQoNCg0KVGhl IGVuZCBvZiBzZWN0aW9uIDIuMiB0YWxrcyBhYm91dCBwcm9tcHQ9Y29uc2VudCBidXQgdGhlIHZh bHVlIGlzIG5vdCBkZWZpbmVkIGFib3ZlLg0KDQpBbHNvLCBJIGRvbid0IHVuZGVyc3RhbmQgdGhl IG5vdGUgYWJvdXQgInB3ZCIgYmVpbmcgdXNlZCBieSBhIHNlcnZpY2UuIEluIHdoaWNoIHNjZW5h cmlvIHdvdWxkIHRoYXQgaGFwcGVuPw0KDQpGaW5hbGx5LCB3aGF0J3MgdGhlIGRpZmZlcmVuY2Ug YmV0d2VlbiBwcm92aWRpbmcgc2V2ZXJhbCB2YWx1ZXMgZm9yICJhbXIiIHdpdGggYW5kIHdpdGhv dXQgaW5jbHVkaW5nICJtZmEiPyBJT1csIHdoYXQncyB0aGUgdXNlIGNhc2UgZm9yIG1mYT8NCkxl IDIxIGp1aWwuIDIwMTQgMjE6MDYsICJNaWtlIEpvbmVzIiA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiBhIMOpY3JpdCA6DQoN CkNoYW5nZXMgaW4gdGhpcyB2ZXJzaW9uIGFyZToNCg0K4oCiICAgICAgICBBZGRlZCB0aGUgQXV0 aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXMgcmVnaXN0cnkuDQoNCuKAoiAgICAg ICAgUmVuYW1lZCB0aGUgY29kZV9mb3JfaWRfdG9rZW4gZ3JhbnQgdHlwZSB0byB1cm46aWV0Zjpw YXJhbXM6b2F1dGg6Z3JhbnQtdHlwZTpjb2RlLWZvci1pZC10b2tlbiB0byBjb25mb3JtIHRvIFNl Y3Rpb24gNC41IG9mIFJGQyA2NzQ5Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+XQ0KU2VudDogTW9uZGF5LCBKdWx5IDIxLCAy MDE0IDEyOjAwIFBNDQpUbzogUGhpbCBIdW50OyBBbnRob255IE5hZGFsaW47IFBoaWwgSHVudDsg TWlrZSBKb25lczsgQW50aG9ueSBOYWRhbGluOyBNaWtlIEpvbmVzDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0 DQoNCg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNl ci1hNGMtMDUudHh0DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWljaGFl bCBCLiBKb25lcyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCg0KDQpOYW1l OiAgICAgICAgICAgICAgICAgIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMNCg0KUmV2aXNp b246ICAgICAgICAgICAgICAwNQ0KDQpUaXRsZTogICAgICAgICAgICAgICAgICAgICBQcm92aWRp bmcgVXNlciBBdXRoZW50aWNhdGlvbiBJbmZvcm1hdGlvbiB0byBPQXV0aCAyLjAgQ2xpZW50cw0K DQpEb2N1bWVudCBkYXRlOiAyMDE0LTA3LTIxDQoNCkdyb3VwOiAgICAgICAgICAgICAgICAgIElu ZGl2aWR1YWwgU3VibWlzc2lvbg0KDQpQYWdlczogICAgICAgICAgICAgICAgICAxOQ0KDQpVUkw6 ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHVu dC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQNCg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMvDQoNCkh0 bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LW9hdXRo LXYyLXVzZXItYTRjLTA1DQoNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA1DQoNCg0KDQpBYnN0cmFj dDoNCg0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSB3YXkgZm9yIE9BdXRoIDIuMCBj bGllbnRzIHRvIHZlcmlmeSB0aGUNCg0KICAgaWRlbnRpdHkgb2YgdGhlIEVuZC1Vc2VyIGFuZCBv YnRhaW4gY29uc2VudCBiYXNlZCB1cG9uIHRoZQ0KDQogICBhdXRoZW50aWNhdGlvbiBwZXJmb3Jt ZWQgYnkgYW4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIuICBUaGUNCg0KICAgaW50ZXJhY3Rpb25zIGRl ZmluZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uIGFyZSBpbnRlbnRpb25hbGx5DQoNCiAgIGNvbXBh dGlibGUgd2l0aCB0aGUgT3BlbklEIENvbm5lY3QgcHJvdG9jb2wuDQoNCg0KDQoNCg0KDQoNCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4N Cg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQo= --_000_4E1F6AAD24975D4BA5B16804296739439ADDAA2DTK5EX14MBXC294r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IjsNCgljb2xvcjojMDAzMzY2O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhh bmtzIGZvciB5b3VyIHJldmlldywgVGhvbWFzLiZuYnNwOyBUaGUg4oCccHJvbXB0PWNvbnNlbnTi gJ0gZGVmaW5pdGlvbiBiZWluZyBtaXNzaW5nIGlzIGFuIGVkaXRvcmlhbCBlcnJvci4mbmJzcDsg SXQgc2hvdWxkIGJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmNvbnNlbnQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4w aW4iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgQXV0aG9yaXphdGlvbiBT ZXJ2ZXIgU0hPVUxEIHByb21wdCB0aGUgRW5kLVVzZXIgZm9yIGNvbnNlbnQgYmVmb3JlIHJldHVy bmluZyBpbmZvcm1hdGlvbiB0byB0aGUgQ2xpZW50LiBJZiBpdCBjYW5ub3Qgb2J0YWluIGNvbnNl bnQsIGl0DQogTVVTVCByZXR1cm4gYW4gZXJyb3IsIHR5cGljYWxseSA8L3NwYW4+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MDAzMzY2Ij5jb25zZW50X3JlcXVpcmVkPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJlsbCBwbGFuIHRvIGFkZCBpdCBpbiB0aGUgbmV4dCBk cmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCB0aGVyZeKAmXMgbm8gZGlmZmVyZW5jZSBiZXR3 ZWVuIGEgcmVzcG9uc2Ugd2l0aCBtdWx0aXBsZSDigJxhbXLigJ0gdmFsdWVzIHRoYXQgaW5jbHVk ZXMg4oCcbWZh4oCdIGFuZCBvbmUgdGhhdCBkb2VzbuKAmXQuJm5ic3A7IFVubGVzcyBhIGNsZWFy IHVzZSBjYXNlIGZvciB3aHkNCiDigJxtZmHigJ0gaXMgbmVlZGVkIGNhbiBiZSBpZGVudGlmaWVk LCB3ZSBjYW4gZGVsZXRlIGl0IGluIHRoZSBuZXh0IGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRo b21hcyBCcm95ZXIgW21haWx0bzp0LmJyb3llckBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBKdWx5IDIxLCAyMDE0IDE6NDcgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9u ZXM8YnI+DQo8Yj5DYzo8L2I+ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtPQVVUSC1XR10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPlRoZSBlbmQgb2Yg c2VjdGlvbiAyLjIgdGFsa3MgYWJvdXQgcHJvbXB0PWNvbnNlbnQgYnV0IHRoZSB2YWx1ZSBpcyBu b3QgZGVmaW5lZCBhYm92ZS48bzpwPjwvbzpwPjwvcD4NCjxwPkFsc28sIEkgZG9uJ3QgdW5kZXJz dGFuZCB0aGUgbm90ZSBhYm91dCAmcXVvdDtwd2QmcXVvdDsgYmVpbmcgdXNlZCBieSBhIHNlcnZp Y2UuIEluIHdoaWNoIHNjZW5hcmlvIHdvdWxkIHRoYXQgaGFwcGVuPzxvOnA+PC9vOnA+PC9wPg0K PHA+RmluYWxseSwgd2hhdCdzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gcHJvdmlkaW5nIHNldmVy YWwgdmFsdWVzIGZvciAmcXVvdDthbXImcXVvdDsgd2l0aCBhbmQgd2l0aG91dCBpbmNsdWRpbmcg JnF1b3Q7bWZhJnF1b3Q7PyBJT1csIHdoYXQncyB0aGUgdXNlIGNhc2UgZm9yIG1mYT88bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZSAyMSBqdWlsLiAyMDE0IDIx OjA2LCAmcXVvdDtNaWtlIEpvbmVzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyBh IMOpY3JpdCA6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwPkNoYW5nZXMgaW4gdGhp cyB2ZXJzaW9uIGFyZTo8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tcmlnaHQ6LjI1 aW4iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpT eW1ib2w7Y29sb3I6YmxhY2siPsK3PC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5BZGRlZCB0aGUgQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1 ZXMgcmVnaXN0cnkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1yaWdo dDouMjVpbiI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OlN5bWJvbDtjb2xvcjpibGFjayI+wrc8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPlJlbmFtZWQgdGhlDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5jb2RlX2Zvcl9pZF90b2tlbjwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gZ3JhbnQgdHlwZSB0bw0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+dXJuOmlldGY6cGFyYW1zOm9hdXRoOmdyYW50LXR5 cGU6Y29kZS1mb3ItaWQtdG9rZW48L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+IHRvIGNvbmZvcm0gdG8gU2VjdGlvbiA0LjUNCiBvZiBSRkMg Njc0OS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+ PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+IFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5dDQo8YnI+DQpTZW50OiBNb25kYXksIEp1 bHkgMjEsIDIwMTQgMTI6MDAgUE08YnI+DQpUbzogUGhpbCBIdW50OyBBbnRob255IE5hZGFsaW47 IFBoaWwgSHVudDsgTWlrZSBKb25lczsgQW50aG9ueSBOYWRhbGluOyBNaWtlIEpvbmVzPGJyPg0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LW9hdXRoLXYy LXVzZXItYTRjLTA1LnR4dDxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dDxvOnA+PC9vOnA+PC9wPg0KPHA+aGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNaWNoYWVsIEIuIEpvbmVzIGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYgcmVwb3NpdG9yeS48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHA+TmFtZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0YzxvOnA+PC9vOnA+PC9wPg0KPHA+UmV2 aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDA1PG86cD48L286cD48L3A+DQo8cD5UaXRsZTom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgUHJvdmlkaW5nIFVzZXIgQXV0aGVudGljYXRpb24gSW5mb3JtYXRpb24gdG8gT0F1dGgg Mi4wIENsaWVudHM8bzpwPjwvbzpwPjwvcD4NCjxwPkRvY3VtZW50IGRhdGU6IDIwMTQtMDctMjE8 bzpwPjwvbzpwPjwvcD4NCjxwPkdyb3VwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248bzpwPjwvbzpwPjwvcD4NCjxwPlBh Z2VzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxOTxvOnA+ PC9vOnA+PC9wPg0KPHA+VVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dCIgdGFy Z2V0PSJfYmxhbmsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1bnQt b2F1dGgtdjItdXNlci1hNGMtMDUudHh0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPlN0 YXR1czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHVudC1vYXV0aC12 Mi11c2VyLWE0Yy8iIHRhcmdldD0iX2JsYW5rIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8cD5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0 Yy0wNSIgdGFyZ2V0PSJfYmxhbmsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1bnQt b2F1dGgtdjItdXNlci1hNGMtMDU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+RGlmZjom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaHVudC1v YXV0aC12Mi11c2VyLWE0Yy0wNSIgdGFyZ2V0PSJfYmxhbmsiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDU8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5BYnN0cmFjdDo8bzpwPjwv bzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIHdh eSBmb3IgT0F1dGggMi4wIGNsaWVudHMgdG8gdmVyaWZ5IHRoZTxvOnA+PC9vOnA+PC9wPg0KPHA+ Jm5ic3A7Jm5ic3A7IGlkZW50aXR5IG9mIHRoZSBFbmQtVXNlciBhbmQgb2J0YWluIGNvbnNlbnQg YmFzZWQgdXBvbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyBhdXRoZW50aWNh dGlvbiBwZXJmb3JtZWQgYnkgYW4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIuJm5ic3A7IFRoZTxvOnA+ PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7IGludGVyYWN0aW9ucyBkZWZpbmVkIGJ5IHRoaXMg c3BlY2lmaWNhdGlvbiBhcmUgaW50ZW50aW9uYWxseTxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7 Jm5ic3A7IGNvbXBhdGlibGUgd2l0aCB0aGUgT3BlbklEIENvbm5lY3QgcHJvdG9jb2wuPG86cD48 L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50b29scy5pZXRmLm9yZzwvYT4u PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBJRVRGIFNl Y3JldGFyaWF0PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439ADDAA2DTK5EX14MBXC294r_-- From nobody Tue Jul 22 04:31:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B011A0ABF for ; Tue, 22 Jul 2014 04:31:07 -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 XkwcCkVzu_Yy for ; Tue, 22 Jul 2014 04:31:05 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D1B1A0AC6 for ; Tue, 22 Jul 2014 04:31:03 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id hr17so5747507lab.2 for ; Tue, 22 Jul 2014 04:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=X6zzhwXtNXe1el3TNkqWI15EIcbCsIZ7b7EBvfrfGtU=; b=tMSs+RlvvxqzwGFkKobscAHjWf8AvykqCYegS9AA13jDUovFyfJsSSFUzQpRqBQQSF 1iseeU5wB5n2QL/lrZ6b//rnPT7dOjlW8QbYhfuRBLgCkJE2Zcc5bMmDqqXmPJJx7R48 yV1RyF6Rm6wVhmoj+S6H/XU/Nv6At2VyStgYMKyk5uNWYhH68vMhDg1X+ZInNlzO89p8 ULIxqd11ymPu35mJPVnvb7Q4JJ9ls3fGMwuABE9vO2syzvwbbG6XORg6S42SVNG1B1ZH 5Hifu3XO/lJ/dQ2EmYbH5r/v53gvRP7OpUOoY7Y/OoX0l1u3+6DnSPxpdeky6MHdLsRn 7cDQ== X-Received: by 10.152.30.10 with SMTP id o10mr21542022lah.41.1406028662426; Tue, 22 Jul 2014 04:31:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.113.73 with HTTP; Tue, 22 Jul 2014 04:30:42 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADDAA2D@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <20140721185955.29738.31476.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439ADDA25E@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADDAA2D@TK5EX14MBXC294.redmond.corp.microsoft.com> From: Thomas Broyer Date: Tue, 22 Jul 2014 13:30:42 +0200 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=089e0158c7b4f7d17904fec68e13 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/z-ZDCo2YUCzrEAkoWHno0KSc5os Cc: "" Subject: Re: [OAUTH-WG] FW: New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Tue, 22 Jul 2014 11:31:07 -0000 --089e0158c7b4f7d17904fec68e13 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones wrote: > Thanks for your review, Thomas. The =E2=80=9Cprompt=3Dconsent=E2=80=9D = definition being > missing is an editorial error. It should be: > > > > consent > > The Authorization Server SHOULD prompt the End-User for consent before > returning information to the Client. If it cannot obtain consent, it MUST > return an error, typically consent_required. > > > > I=E2=80=99ll plan to add it in the next draft. > It looks like the consent_required error needs to be defined too, and you might have forgotten to also import account_selection_required from OpenID Connect. > > > I agree that there=E2=80=99s no difference between a response with multip= le =E2=80=9Camr=E2=80=9D > values that includes =E2=80=9Cmfa=E2=80=9D and one that doesn=E2=80=99t. = Unless a clear use case > for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete = it in the next > draft. > Thanks. How about "pwd" then? I fully understand that I should return "pwd" if the user authenticated using a password, but what "the service if a client secret is used" means in the definition for the "pwd" value? (Nota: I know you're at IETF-90, I'm ready to wait 'til you come back ;-) ) --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --089e0158c7b4f7d17904fec68e13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <= Michael.Jo= nes@microsoft.com> wrote:

Thanks for your review, Thomas.=C2=A0 The = =E2=80=9Cprompt=3Dconsent=E2=80=9D definition being missing is an editorial= error.=C2=A0 It should be:

=C2=A0

consent

The Authorization Server SHOUL= D prompt the End-User for consent before returning information to the Clien= t. If it cannot obtain consent, it MUST return an error, typically consent_required.

=C2=A0

I=E2=80=99ll plan to add it in the next draf= t.


It looks like the= consent_required error needs to be defined too, and you might have forgott= en to also import account_selection_required from OpenID Connect.
=C2=A0

=C2=A0

I agree that there=E2=80=99s no difference b= etween a response with multiple =E2=80=9Camr=E2=80=9D values that includes = =E2=80=9Cmfa=E2=80=9D and one that doesn=E2=80=99t.=C2=A0 Unless a clear us= e case for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete it in the= next draft.


Thanks.=

How about "pwd" then? I fully understan= d that I should return "pwd" if the user authenticated using a pa= ssword, but what "the service if a client secret is used" means i= n the definition for the "pwd" value?

(Nota: I know you're at IETF-90, I'm ready to w= ait 'til you come back ;-) )

--
Thomas Br= oyer
/t=C9=94.ma.b=CA=81wa= .je/
--089e0158c7b4f7d17904fec68e13-- From nobody Tue Jul 22 06:54:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4879D1B27EC for ; Tue, 22 Jul 2014 06:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 cmk3U8j6jlA9 for ; Tue, 22 Jul 2014 06:54:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 53A461B27DD for ; Tue, 22 Jul 2014 06:54:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C29881F1559; Tue, 22 Jul 2014 09:54:23 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B2D3C1F1558; Tue, 22 Jul 2014 09:54:23 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.118]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 09:54:23 -0400 From: "Richer, Justin P." To: Thomas Broyer Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpbRw2HhjKAwRPEyI0/Q0qsoAEg== Date: Tue, 22 Jul 2014 13:54:22 +0000 Message-ID: References: <20140721185955.29738.31476.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439ADDA25E@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADDAA2D@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.40.126] Content-Type: multipart/alternative; boundary="_000_CA1810B06ED0456F89896B7EF73930D9mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/04r_0GMJfa8gwpG1JxisLEStMZw Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Tue, 22 Jul 2014 13:54:26 -0000 --_000_CA1810B06ED0456F89896B7EF73930D9mitreorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJyb3JzIGxpa2UgdGhlc2UgbWFrZSBpdCBjbGVhciB0byBtZSB0aGF0IGl0IHdvdWxkIG1ha2Ug bXVjaCBtb3JlIHNlbnNlIHRvIGRldmVsb3AgdGhpcyBkb2N1bWVudCBpbiB0aGUgT3BlbklEIEZv dW5kYXRpb24uIEl0IHNob3VsZCBiZSBzb21ldGhpbmcgdGhhdCBkaXJlY3RseSByZWZlcmVuY2Vz IE9wZW5JRCBDb25uZWN0IENvcmUgZm9yIGFsbCBvZiB0aGVzZSB0ZXJtcyBpbnN0ZWFkIG9mIHJl ZGVmaW5pbmcgdGhlbS4gSXQncyBkb2luZyBhdXRoZW50aWNhdGlvbiwgd2hpY2ggaXMgZnVuZGFt ZW50YWxseSB3aGF0IE9wZW5JRCBDb25uZWN0IGRvZXMgb24gdG9wIG9mIE9BdXRoLCBhbmQgSSBk b24ndCBzZWUgYSBnb29kIGFyZ3VtZW50IGZvciBkb2luZyB0aGlzIHdvcmsgaW4gdGhpcyB3b3Jr aW5nIGdyb3VwLg0KDQogLS0gSnVzdGluDQoNCk9uIEp1bCAyMiwgMjAxNCwgYXQgNDozMCBBTSwg VGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPG1haWx0bzp0LmJyb3llckBnbWFpbC5j b20+PiB3cm90ZToNCg0KDQoNCg0KT24gTW9uLCBKdWwgMjEsIDIwMTQgYXQgMTE6NTIgUE0sIE1p a2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LCBUaG9tYXMu ICBUaGUg4oCccHJvbXB0PWNvbnNlbnTigJ0gZGVmaW5pdGlvbiBiZWluZyBtaXNzaW5nIGlzIGFu IGVkaXRvcmlhbCBlcnJvci4gIEl0IHNob3VsZCBiZToNCg0KY29uc2VudA0KVGhlIEF1dGhvcml6 YXRpb24gU2VydmVyIFNIT1VMRCBwcm9tcHQgdGhlIEVuZC1Vc2VyIGZvciBjb25zZW50IGJlZm9y ZSByZXR1cm5pbmcgaW5mb3JtYXRpb24gdG8gdGhlIENsaWVudC4gSWYgaXQgY2Fubm90IG9idGFp biBjb25zZW50LCBpdCBNVVNUIHJldHVybiBhbiBlcnJvciwgdHlwaWNhbGx5IGNvbnNlbnRfcmVx dWlyZWQuDQoNCknigJlsbCBwbGFuIHRvIGFkZCBpdCBpbiB0aGUgbmV4dCBkcmFmdC4NCg0KSXQg bG9va3MgbGlrZSB0aGUgY29uc2VudF9yZXF1aXJlZCBlcnJvciBuZWVkcyB0byBiZSBkZWZpbmVk IHRvbywgYW5kIHlvdSBtaWdodCBoYXZlIGZvcmdvdHRlbiB0byBhbHNvIGltcG9ydCBhY2NvdW50 X3NlbGVjdGlvbl9yZXF1aXJlZCBmcm9tIE9wZW5JRCBDb25uZWN0Lg0KDQoNCkkgYWdyZWUgdGhh dCB0aGVyZeKAmXMgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIGEgcmVzcG9uc2Ugd2l0aCBtdWx0aXBs ZSDigJxhbXLigJ0gdmFsdWVzIHRoYXQgaW5jbHVkZXMg4oCcbWZh4oCdIGFuZCBvbmUgdGhhdCBk b2VzbuKAmXQuICBVbmxlc3MgYSBjbGVhciB1c2UgY2FzZSBmb3Igd2h5IOKAnG1mYeKAnSBpcyBu ZWVkZWQgY2FuIGJlIGlkZW50aWZpZWQsIHdlIGNhbiBkZWxldGUgaXQgaW4gdGhlIG5leHQgZHJh ZnQuDQoNClRoYW5rcy4NCg0KSG93IGFib3V0ICJwd2QiIHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFu ZCB0aGF0IEkgc2hvdWxkIHJldHVybiAicHdkIiBpZiB0aGUgdXNlciBhdXRoZW50aWNhdGVkIHVz aW5nIGEgcGFzc3dvcmQsIGJ1dCB3aGF0ICJ0aGUgc2VydmljZSBpZiBhIGNsaWVudCBzZWNyZXQg aXMgdXNlZCIgbWVhbnMgaW4gdGhlIGRlZmluaXRpb24gZm9yIHRoZSAicHdkIiB2YWx1ZT8NCg0K KE5vdGE6IEkga25vdyB5b3UncmUgYXQgSUVURi05MCwgSSdtIHJlYWR5IHRvIHdhaXQgJ3RpbCB5 b3UgY29tZSBiYWNrIDstKSApDQoNCi0tDQpUaG9tYXMgQnJveWVyDQovdMmULm1hLmLKgXdhLmpl LzxodHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBp ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_CA1810B06ED0456F89896B7EF73930D9mitreorg_ Content-Type: text/html; charset="utf-8" Content-ID: <86A2450B78270F438A0C2AEF9398B61F@imc.mitre.org> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KRXJyb3JzIGxpa2UgdGhlc2UgbWFrZSBpdCBjbGVh ciB0byBtZSB0aGF0IGl0IHdvdWxkIG1ha2UgbXVjaCBtb3JlIHNlbnNlIHRvIGRldmVsb3AgdGhp cyBkb2N1bWVudCBpbiB0aGUgT3BlbklEIEZvdW5kYXRpb24uIEl0IHNob3VsZCBiZSBzb21ldGhp bmcgdGhhdCBkaXJlY3RseSByZWZlcmVuY2VzIE9wZW5JRCBDb25uZWN0IENvcmUgZm9yIGFsbCBv ZiB0aGVzZSB0ZXJtcyBpbnN0ZWFkIG9mIHJlZGVmaW5pbmcgdGhlbS4gSXQncyBkb2luZyBhdXRo ZW50aWNhdGlvbiwNCiB3aGljaCBpcyBmdW5kYW1lbnRhbGx5IHdoYXQgT3BlbklEIENvbm5lY3Qg ZG9lcyBvbiB0b3Agb2YgT0F1dGgsIGFuZCBJIGRvbid0IHNlZSBhIGdvb2QgYXJndW1lbnQgZm9y IGRvaW5nIHRoaXMgd29yayBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAuDQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4mbmJzcDstLSBKdXN0aW48L2Rpdj4NCjxkaXY+PGJyPg0KPGRpdj4NCjxkaXY+T24g SnVsIDIyLCAyMDE0LCBhdCA0OjMwIEFNLCBUaG9tYXMgQnJveWVyICZsdDs8YSBocmVmPSJtYWls dG86dC5icm95ZXJAZ21haWwuY29tIj50LmJyb3llckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4 dHJhIj48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBKdWwgMjEs IDIwMTQgYXQgMTE6NTIgUE0sIE1pa2UgSm9uZXMgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhy ZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5N aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAu OGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwy MDQpO2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2ZvbnQtZmFtaWx5OkNhbGlicmks c2Fucy1zZXJpZjtjb2xvcjpyZ2IoMzEsNzMsMTI1KSI+VGhhbmtzIGZvciB5b3VyIHJldmlldywg VGhvbWFzLiZuYnNwOyBUaGUg4oCccHJvbXB0PWNvbnNlbnTigJ0gZGVmaW5pdGlvbiBiZWluZyBt aXNzaW5nIGlzIGFuIGVkaXRvcmlhbCBlcnJvci4mbmJzcDsgSXQgc2hvdWxkIGJlOjx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTFwdDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Y29sb3I6cmdiKDMxLDcz LDEyNSkiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowLjVpbiI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250 LWZhbWlseTogVmVyZGFuYSwgc2Fucy1zZXJpZjsiPmNvbnNlbnQ8dT48L3U+PHU+PC91Pjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MWluIj48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBzYW5zLXNlcmlmOyI+VGhl IEF1dGhvcml6YXRpb24gU2VydmVyIFNIT1VMRCBwcm9tcHQgdGhlIEVuZC1Vc2VyIGZvciBjb25z ZW50IGJlZm9yZSByZXR1cm5pbmcgaW5mb3JtYXRpb24gdG8gdGhlIENsaWVudC4gSWYgaXQgY2Fu bm90IG9idGFpbiBjb25zZW50LCBpdCBNVVNUIHJldHVybiBhbg0KIGVycm9yLCB0eXBpY2FsbHkg PC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6J0NvdXJpZXIgTmV3Jztj b2xvcjpyZ2IoMCw1MSwxMDIpIj5jb25zZW50X3JlcXVpcmVkPC9zcGFuPjxzcGFuIGxhbmc9IkVO IiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIHNhbnMtc2VyaWY7Ij4uDQo8dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2NvbG9yOnJnYigzMSw3Mywx MjUpIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNl cmlmO2NvbG9yOnJnYigzMSw3MywxMjUpIj5J4oCZbGwgcGxhbiB0byBhZGQgaXQgaW4gdGhlIG5l eHQgZHJhZnQuPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5JdCBsb29rcyBsaWtlIHRoZSBjb25zZW50X3JlcXVpcmVkIGVy cm9yIG5lZWRzIHRvIGJlIGRlZmluZWQgdG9vLCBhbmQgeW91IG1pZ2h0IGhhdmUgZm9yZ290dGVu IHRvIGFsc28gaW1wb3J0IGFjY291bnRfc2VsZWN0aW9uX3JlcXVpcmVkIGZyb20gT3BlbklEIENv bm5lY3QuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRo OjFweDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpO2JvcmRlci1sZWZ0LXN0eWxl OnNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMXB0O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtjb2xvcjpyZ2Io MzEsNzMsMTI1KSI+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z ZXJpZjtjb2xvcjpyZ2IoMzEsNzMsMTI1KSI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2ZvbnQt ZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtjb2xvcjpyZ2IoMzEsNzMsMTI1KSI+SSBhZ3JlZSB0 aGF0IHRoZXJl4oCZcyBubyBkaWZmZXJlbmNlIGJldHdlZW4gYSByZXNwb25zZSB3aXRoIG11bHRp cGxlIOKAnGFtcuKAnSB2YWx1ZXMgdGhhdCBpbmNsdWRlcyDigJxtZmHigJ0gYW5kIG9uZSB0aGF0 IGRvZXNu4oCZdC4mbmJzcDsgVW5sZXNzIGEgY2xlYXIgdXNlIGNhc2UgZm9yIHdoeQ0KIOKAnG1m YeKAnSBpcyBuZWVkZWQgY2FuIGJlIGlkZW50aWZpZWQsIHdlIGNhbiBkZWxldGUgaXQgaW4gdGhl IG5leHQgZHJhZnQuPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5Ib3cgYWJvdXQgJnF1b3Q7cHdkJnF1b3Q7IHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFuZCB0 aGF0IEkgc2hvdWxkIHJldHVybiAmcXVvdDtwd2QmcXVvdDsgaWYgdGhlIHVzZXIgYXV0aGVudGlj YXRlZCB1c2luZyBhIHBhc3N3b3JkLCBidXQgd2hhdCAmcXVvdDt0aGUgc2VydmljZSBpZiBhIGNs aWVudCBzZWNyZXQgaXMgdXNlZCZxdW90OyBtZWFucyBpbiB0aGUgZGVmaW5pdGlvbiBmb3IgdGhl ICZxdW90O3B3ZCZxdW90OyB2YWx1ZT88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PihO b3RhOiBJIGtub3cgeW91J3JlIGF0IElFVEYtOTAsIEknbSByZWFkeSB0byB3YWl0ICd0aWwgeW91 IGNvbWUgYmFjayA7LSkgKTwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KLS0gPGJy Pg0KVGhvbWFzIEJyb3llcjxicj4NCi90PGEgaHJlZj0iaHR0cDovL3huLS1ubmEubWEueG4tLWJ3 YS14eGIuamUvIj7JlC5tYS5iyoF3YS5qZS88L2E+IDwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8 L2E+PGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CA1810B06ED0456F89896B7EF73930D9mitreorg_-- From nobody Tue Jul 22 08:35:25 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A26E1A0039 for ; Tue, 22 Jul 2014 08:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xitvFiNC-qQl for ; Tue, 22 Jul 2014 08:35:22 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DDB01A02A2 for ; Tue, 22 Jul 2014 08:35:16 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so6193301lbv.16 for ; Tue, 22 Jul 2014 08:35:14 -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=uLIMEuwuLcE31b2jY08MdFq3gGFnXYVW2mEwpZqBvWU=; b=zkFxWmAES6aPamSCxWjYYZK9VZ7f2f5TcVuDXv08nx8xzJkMMFaoBM8hixP/YUUouf lsfHJVl2IX19nt/FrbEsrhQLXK3gIGKSGUgel2jtiMsquJrBAbrmj4ob5AGN53B2IFtz wPQT2G4m4c7VNW3vbec4re8MWIjastatf9qXNf1oXNl/c9IiuIrqYH81Y/Q5lzhRDmkf bzsqBHW+5iNQbNiT2SiHPWJ5NkR+qPnf4VQn6mGw7RtsxzuIAJSFqM5oI94+2kWu2DyI kOfhde2Z33ru2arJdG8+4gYcI1OjS5rb5ZKW3MSS94/o+h/e0EDm7FdPQ17iud373vOd bDRg== MIME-Version: 1.0 X-Received: by 10.152.245.171 with SMTP id xp11mr17677575lac.61.1406043314499; Tue, 22 Jul 2014 08:35:14 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Tue, 22 Jul 2014 08:35:14 -0700 (PDT) In-Reply-To: References: <20140721185955.29738.31476.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439ADDA25E@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADDAA2D@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Tue, 22 Jul 2014 11:35:14 -0400 Message-ID: From: Nat Sakimura To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=001a11345e124cb77d04fec9f8d7 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/cNyYgbhoKGFDnG07tvHS8_ARieY Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Tue, 22 Jul 2014 15:35:24 -0000 --001a11345e124cb77d04fec9f8d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to Justin. 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : > Errors like these make it clear to me that it would make much more sense > to develop this document in the OpenID Foundation. It should be something > that directly references OpenID Connect Core for all of these terms inste= ad > of redefining them. It's doing authentication, which is fundamentally wha= t > OpenID Connect does on top of OAuth, and I don't see a good argument for > doing this work in this working group. > > -- Justin > > On Jul 22, 2014, at 4:30 AM, Thomas Broyer wrote: > > > > > On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones > wrote: > >> Thanks for your review, Thomas. The =E2=80=9Cprompt=3Dconsent=E2=80=9D= definition being >> missing is an editorial error. It should be: >> >> >> >> consent >> >> The Authorization Server SHOULD prompt the End-User for consent before >> returning information to the Client. If it cannot obtain consent, it MUS= T >> return an error, typically consent_required. >> >> >> >> I=E2=80=99ll plan to add it in the next draft. >> > > It looks like the consent_required error needs to be defined too, and > you might have forgotten to also import account_selection_required from > OpenID Connect. > > >> >> >> I agree that there=E2=80=99s no difference between a response with multi= ple =E2=80=9Camr=E2=80=9D >> values that includes =E2=80=9Cmfa=E2=80=9D and one that doesn=E2=80=99t.= Unless a clear use case >> for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete= it in the next >> draft. >> > > Thanks. > > How about "pwd" then? I fully understand that I should return "pwd" if > the user authenticated using a password, but what "the service if a clien= t > secret is used" means in the definition for the "pwd" value? > > (Nota: I know you're at IETF-90, I'm ready to wait 'til you come back > ;-) ) > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11345e124cb77d04fec9f8d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to Justin.=C2=A0

2014-07-22 9:54 GMT-04:00 Richer, Justin P. <= jricher@mitre.org>:
Errors like these make it clear to me that it would make much more sense to= develop this document in the OpenID Foundation. It should be something tha= t directly references OpenID Connect Core for all of these terms instead of= redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of OAuth, and I don= 't see a good argument for doing this work in this working group.

=C2=A0-- Justin

On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:




On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

Thanks for your review, Thomas.=C2=A0 The = =E2=80=9Cprompt=3Dconsent=E2=80=9D definition being missing is an editorial= error.=C2=A0 It should be:

=C2=A0

consent

The Authorization Server SHOULD prompt the= End-User for consent before returning information to the Client. If it can= not obtain consent, it MUST return an error, typically consent_required.

=C2=A0

I=E2=80=99ll plan to add it in the next draf= t.


It looks like the consent_required error needs to be defined too, and = you might have forgotten to also import account_selection_required from Ope= nID Connect.
=C2=A0

=C2=A0

I agree that there=E2=80=99s no difference b= etween a response with multiple =E2=80=9Camr=E2=80=9D values that includes = =E2=80=9Cmfa=E2=80=9D and one that doesn=E2=80=99t.=C2=A0 Unless a clear us= e case for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete it in the= next draft.


Thanks.

How about "pwd" then? I fully understand that I should retur= n "pwd" if the user authenticated using a password, but what &quo= t;the service if a client secret is used" means in the definition for = the "pwd" value?

(Nota: I know you're at IETF-90, I'm ready to wait 'til yo= u come back ;-) )

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11345e124cb77d04fec9f8d7-- From nobody Tue Jul 22 09:57:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67C01B29E9 for ; Tue, 22 Jul 2014 09:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 FIOXFbTjNbEE for ; Tue, 22 Jul 2014 09:57:15 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146661B29EE for ; Tue, 22 Jul 2014 09:57:15 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6MGvBnH032582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Jul 2014 16:57:12 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6MGvAUL027582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2014 16:57:11 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6MGvAeA021319; Tue, 22 Jul 2014 16:57:10 GMT Received: from [25.0.157.78] (/24.114.58.236) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Jul 2014 09:57:10 -0700 References: <20140721185955.29738.31476.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439ADDA25E@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADDAA2D@TK5EX14MBXC294.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-C4E9425C-6184-463E-976A-03ADD06CC700 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Tue, 22 Jul 2014 12:56:59 -0400 To: Nat Sakimura X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2Jd5jUVlF1JYorhtwlecxd9mn74 Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Tue, 22 Jul 2014 16:57:18 -0000 --Apple-Mail-C4E9425C-6184-463E-976A-03ADD06CC700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable That would be nice. However oidc still needs the new grant type in order to i= mplement the same flow.=20 Phil > On Jul 22, 2014, at 11:35, Nat Sakimura wrote: >=20 > +1 to Justin.=20 >=20 >=20 > 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >> Errors like these make it clear to me that it would make much more sense t= o develop this document in the OpenID Foundation. It should be something tha= t directly references OpenID Connect Core for all of these terms instead of r= edefining them. It's doing authentication, which is fundamentally what OpenI= D Connect does on top of OAuth, and I don't see a good argument for doing th= is work in this working group. >>=20 >> -- Justin >>=20 >>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones wrote: >>>> Thanks for your review, Thomas. The =E2=80=9Cprompt=3Dconsent=E2=80=9D= definition being missing is an editorial error. It should be: >>>>=20 >>>> =20 >>>>=20 >>>> consent >>>>=20 >>>> The Authorization Server SHOULD prompt the End-User for consent before r= eturning information to the Client. If it cannot obtain consent, it MUST ret= urn an error, typically consent_required. >>>>=20 >>>> =20 >>>>=20 >>>> I=E2=80=99ll plan to add it in the next draft. >>>>=20 >>>=20 >>> It looks like the consent_required error needs to be defined too, and yo= u might have forgotten to also import account_selection_required from OpenID= Connect. >>> =20 >>>> =20 >>>>=20 >>>> I agree that there=E2=80=99s no difference between a response with mult= iple =E2=80=9Camr=E2=80=9D values that includes =E2=80=9Cmfa=E2=80=9D and on= e that doesn=E2=80=99t. Unless a clear use case for why =E2=80=9Cmfa=E2=80=9D= is needed can be identified, we can delete it in the next draft. >>>>=20 >>>=20 >>> Thanks. >>>=20 >>> How about "pwd" then? I fully understand that I should return "pwd" if t= he user authenticated using a password, but what "the service if a client se= cret is used" means in the definition for the "pwd" value? >>>=20 >>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come back ;-= ) ) >>>=20 >>> --=20 >>> Thomas Broyer >>> /t=C9=94.ma.b=CA=81wa.je/ >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-C4E9425C-6184-463E-976A-03ADD06CC700 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
That would be nice. However oidc still= needs the new grant type in order to implement the same flow. 

= Phil

On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:

+1 to Justin. 


2014-07-22 9:54 GMT-0= 4:00 Richer, Justin P. <jricher@mitre.org>:
Errors like these make it clear to me that it would make much more sense to d= evelop this document in the OpenID Foundation. It should be something that d= irectly references OpenID Connect Core for all of these terms instead of red= efining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of OAuth, and I don'= t see a good argument for doing this work in this working group.

 -- Justin

On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:




On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael= .Jones@microsoft.com> wrote:

Thanks for your review, Thomas.  The =E2=80= =9Cprompt=3Dconsent=E2=80=9D definition being missing is an editorial error.=   It should be:

 

consent

The Authorization Server SHOULD prompt the E= nd-User for consent before returning information to the Client. If it cannot= obtain consent, it MUST return an error, typically


--
Thomas Broyer
/t=C9=94.ma.= b=CA=81wa.je/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/oauth


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




--
Nat Sakim= ura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-C4E9425C-6184-463E-976A-03ADD06CC700-- From nobody Tue Jul 22 10:29:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75EAA1B2AE2 for ; Tue, 22 Jul 2014 10:29:15 -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 2U_ZCBl8JqFN for ; Tue, 22 Jul 2014 10:29:08 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4720A1B2AE7 for ; Tue, 22 Jul 2014 10:29:03 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id 10so4364861lbg.12 for ; Tue, 22 Jul 2014 10:29: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=VHu2Eid6Nu0Bq9DPHxg+MN/hO2YxPAAmvkabT7KOXPI=; b=BCsx8po9jNZBPzN9P/QfSoAGesHXYNIBggTceh4ihBS3kHt/HVajOKxmCKNHr72shF +chbzl9KYkjkNM3ksX2DyEgbaC7DUBB/ZeRr1BzQvjc9YJdaFb8407ouevSX5puniLB+ QyiPzzrsaqF2kEMUJKdSxaxit2q9iDavoF41/hjKAEnYrHCVvJUQP1tUV8vjgb0fIjJO xMY+0IWER7LoZAvcKK/BecBPQpJKmVfCvLdQ3/lipB+6bCFXMajLvnQv4EXFlxX8qf6y /07hA0+vMbY2wbTRosaYVuCVngsUoPziywtAAio9qTzBvCQYPoMJ2yMTnu3MI2w/DflD sCtw== MIME-Version: 1.0 X-Received: by 10.152.5.167 with SMTP id t7mr28466368lat.54.1406050141385; Tue, 22 Jul 2014 10:29:01 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Tue, 22 Jul 2014 10:29:01 -0700 (PDT) In-Reply-To: References: <20140721185955.29738.31476.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439ADDA25E@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADDAA2D@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Tue, 22 Jul 2014 13:29:01 -0400 Message-ID: From: Nat Sakimura To: Phil Hunt Content-Type: multipart/alternative; boundary=089e01419d8636b9da04fecb8f28 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/NVtLoEztEqUp9y-20DviXn_IZuc Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Tue, 22 Jul 2014 17:29:15 -0000 --089e01419d8636b9da04fecb8f28 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What about just defining a new grant type in this WG? 2014-07-22 12:56 GMT-04:00 Phil Hunt : > That would be nice. However oidc still needs the new grant type in order > to implement the same flow. > > Phil > > On Jul 22, 2014, at 11:35, Nat Sakimura wrote: > > +1 to Justin. > > > 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : > >> Errors like these make it clear to me that it would make much more sens= e >> to develop this document in the OpenID Foundation. It should be somethin= g >> that directly references OpenID Connect Core for all of these terms inst= ead >> of redefining them. It's doing authentication, which is fundamentally wh= at >> OpenID Connect does on top of OAuth, and I don't see a good argument for >> doing this work in this working group. >> >> -- Justin >> >> On Jul 22, 2014, at 4:30 AM, Thomas Broyer wrote: >> >> >> >> >> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones > > wrote: >> >>> Thanks for your review, Thomas. The =E2=80=9Cprompt=3Dconsent=E2=80= =9D definition being >>> missing is an editorial error. It should be: >>> >>> >>> >>> consent >>> >>> The Authorization Server SHOULD prompt the End-User for consent before >>> returning information to the Client. If it cannot obtain consent, it MU= ST >>> return an error, typically consent_required. >>> >>> >>> >>> I=E2=80=99ll plan to add it in the next draft. >>> >> >> It looks like the consent_required error needs to be defined too, and >> you might have forgotten to also import account_selection_required from >> OpenID Connect. >> >> >>> >>> >>> I agree that there=E2=80=99s no difference between a response with mult= iple >>> =E2=80=9Camr=E2=80=9D values that includes =E2=80=9Cmfa=E2=80=9D and on= e that doesn=E2=80=99t. Unless a clear use >>> case for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can = delete it in the >>> next draft. >>> >> >> Thanks. >> >> How about "pwd" then? I fully understand that I should return "pwd" if >> the user authenticated using a password, but what "the service if a clie= nt >> secret is used" means in the definition for the "pwd" value? >> >> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come back >> ;-) ) >> >> -- >> Thomas Broyer >> /t=C9=94.ma.b=CA=81wa.je/ >> _______________________________________________ >> 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 >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e01419d8636b9da04fecb8f28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What about just defining a new grant type in this WG?


2014-07-22 1= 2:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
That would be nice. H= owever oidc still needs the new grant type in order to implement the same f= low.=C2=A0

Phil

On Jul 22, 2014= , at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:

+1 to Justin.=C2=A0
<= br>
2014-07-22 9:54 GMT-04:00 Richer, Justin = P. <jricher@mitre.org>:
Errors like these make it clear to me that it would make much more sense to= develop this document in the OpenID Foundation. It should be something tha= t directly references OpenID Connect Core for all of these terms instead of= redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of OAuth, and I don= 't see a good argument for doing this work in this working group.

=C2=A0-- Justin

On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:




On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

Thanks for your review, Thomas.=C2=A0 The = =E2=80=9Cprompt=3Dconsent=E2=80=9D definition being missing is an editorial= error.=C2=A0 It should be:

=C2=A0

consent

The Authorization Server SHOULD prompt the= End-User for consent before returning information to the Client. If it can= not obtain consent, it MUST return an error, typically consent_required.

=C2=A0

I=E2=80=99ll plan to add it in the next draf= t.


It looks like the consent_required error needs to be defined too, and = you might have forgotten to also import account_selection_required from Ope= nID Connect.
=C2=A0

=C2=A0

I agree that there=E2=80=99s no difference b= etween a response with multiple =E2=80=9Camr=E2=80=9D values that includes = =E2=80=9Cmfa=E2=80=9D and one that doesn=E2=80=99t.=C2=A0 Unless a clear us= e case for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete it in the= next draft.


Thanks.

How about "pwd" then? I fully understand that I should retur= n "pwd" if the user authenticated using a password, but what &quo= t;the service if a client secret is used" means in the definition for = the "pwd" value?

(Nota: I know you're at IETF-90, I'm ready to wait 'til yo= u come back ;-) )

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org=
https://www.ietf.org/mailman/listinfo/oauth



=
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/@_nat_en
--089e01419d8636b9da04fecb8f28-- From nobody Tue Jul 22 10:42:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DE21A01B0 for ; Tue, 22 Jul 2014 10:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 e8afAX77O7jz for ; Tue, 22 Jul 2014 10:42:01 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88951B2AE8 for ; Tue, 22 Jul 2014 10:42:00 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6MHfwu1031152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Jul 2014 17:41:58 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6MHfvBg020383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2014 17:41:58 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6MHfv7i020371; Tue, 22 Jul 2014 17:41:57 GMT Received: from dhcp-a0cc.meeting.ietf.org (/31.133.160.204) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Jul 2014 10:41:57 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_B6FC3A28-B86E-46DC-BDF1-C4D642447D61" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Tue, 22 Jul 2014 13:41:55 -0400 Message-Id: References: <20140721185955.29738.31476.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439ADDA25E@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADDAA2D@TK5EX14MBXC294.redmond.corp.microsoft.com> To: Nat Sakimura X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/0cF09_AzfsLQ8u4sj7sY5Poum3w Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Tue, 22 Jul 2014 17:42:02 -0000 --Apple-Mail=_B6FC3A28-B86E-46DC-BDF1-C4D642447D61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Speaking for myself, yes. Defining the simple ID_token grant showing = how an ID token only can be returned is my minimum objective. I think there needs to be some discussion in the WG on certain features = which may be better suited only within OIDC and those features which fit = better as a foundational piece in IETF OAuth WG. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 22, 2014, at 1:29 PM, Nat Sakimura wrote: > What about just defining a new grant type in this WG? >=20 >=20 > 2014-07-22 12:56 GMT-04:00 Phil Hunt : > That would be nice. However oidc still needs the new grant type in = order to implement the same flow.=20 >=20 > Phil >=20 > On Jul 22, 2014, at 11:35, Nat Sakimura wrote: >=20 >> +1 to Justin.=20 >>=20 >>=20 >> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >> Errors like these make it clear to me that it would make much more = sense to develop this document in the OpenID Foundation. It should be = something that directly references OpenID Connect Core for all of these = terms instead of redefining them. It's doing authentication, which is = fundamentally what OpenID Connect does on top of OAuth, and I don't see = a good argument for doing this work in this working group. >>=20 >> -- Justin >>=20 >> On Jul 22, 2014, at 4:30 AM, Thomas Broyer = wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones = wrote: >>> Thanks for your review, Thomas. The =E2=80=9Cprompt=3Dconsent=E2=80=9D= definition being missing is an editorial error. It should be: >>>=20 >>> =20 >>>=20 >>> consent >>>=20 >>> The Authorization Server SHOULD prompt the End-User for consent = before returning information to the Client. If it cannot obtain consent, = it MUST return an error, typically consent_required. >>>=20 >>> =20 >>>=20 >>> I=E2=80=99ll plan to add it in the next draft. >>>=20 >>>=20 >>> It looks like the consent_required error needs to be defined too, = and you might have forgotten to also import account_selection_required = from OpenID Connect. >>> =20 >>>=20 >>> =20 >>>=20 >>> I agree that there=E2=80=99s no difference between a response with = multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80=9Cmfa=E2=80=9D = and one that doesn=E2=80=99t. Unless a clear use case for why =E2=80=9Cmf= a=E2=80=9D is needed can be identified, we can delete it in the next = draft. >>>=20 >>>=20 >>> Thanks. >>>=20 >>> How about "pwd" then? I fully understand that I should return "pwd" = if the user authenticated using a password, but what "the service if a = client secret is used" means in the definition for the "pwd" value? >>>=20 >>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come = back ;-) ) >>>=20 >>> --=20 >>> Thomas Broyer >>> /t=C9=94.ma.b=CA=81wa.je/ >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail=_B6FC3A28-B86E-46DC-BDF1-C4D642447D61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Speaking for myself, yes.  Defining the simple = ID_token grant showing how an ID token only can be returned is my = minimum objective.

I think there needs to be some = discussion in the WG on certain features which may be better suited only = within OIDC and those features which fit better as a foundational piece = in IETF OAuth WG.


On Jul 22, 2014, at 1:29 PM, Nat Sakimura <sakimura@gmail.com> = wrote:

What about just defining a new grant type = in this WG?


2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
That would be nice. However oidc still needs the new = grant type in order to implement the same flow. 

Phil

On Jul 22, = 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> = wrote:

+1 to Justin. 


2014-07-22 9:54 = GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
Errors like these make it clear to me that it would make much more sense = to develop this document in the OpenID Foundation. It should be = something that directly references OpenID Connect Core for all of these = terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of OAuth, and I = don't see a good argument for doing this work in this working group.

 -- Justin

On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:




On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

Thanks for your review, Thomas.  The =E2=80=9Cprompt=3Dconsent=E2=80= =9D definition being missing is an editorial error.  It should = be:

 

consent

<= p class=3D"MsoNormal" style=3D"margin-left:1in">The Authorization Server SHOULD = prompt the End-User for consent before returning information to the = Client. If it cannot obtain consent, it MUST return an error, typically consent_required.

 

I=E2=80=99ll plan to add it in the next draft.


It looks like the consent_required error needs to be defined too, = and you might have forgotten to also import account_selection_required = from OpenID Connect.
 

 

I agree that there=E2=80=99s no difference between a response with = multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80=9Cmfa=E2=80=9D = and one that doesn=E2=80=99t.  Unless a clear use case for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete it in = the next draft.


Thanks.

How about "pwd" then? I fully understand that I should return "pwd" = if the user authenticated using a password, but what "the service if a = client secret is used" means in the definition for the "pwd" = value?

(Nota: I know you're at IETF-90, I'm ready to wait 'til you come = back ;-) )

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
_______________________________________________
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




--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________=
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

= --Apple-Mail=_B6FC3A28-B86E-46DC-BDF1-C4D642447D61-- From nobody Tue Jul 22 11:30:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5FD1A0AA9 for ; Tue, 22 Jul 2014 11:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 9H0pvT3fkkKM for ; Tue, 22 Jul 2014 11:30:43 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8971B2BA0 for ; Tue, 22 Jul 2014 11:30:41 -0700 (PDT) X-AuditID: 1209190d-f79c06d000002f07-49-53ceadd039d6 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 37.13.12039.0DDAEC35; Tue, 22 Jul 2014 14:30:40 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s6MIUdfx004480; Tue, 22 Jul 2014 14:30:39 -0400 Received: from [162.162.97.63] ([172.56.39.13]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6MIUYrf031075 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Jul 2014 14:30:37 -0400 Message-Id: <201407221830.s6MIUYrf031075@outgoing.mit.edu> Date: Tue, 22 Jul 2014 11:30:30 -0700 From: Justin Richer To: Nat Sakimura MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixCmqrHth7blgg5c3+SxOvn3FZrFgfiO7 xZlbKxgdmD12zrrL7rFkyU8mj49Pb7EEMEdx2aSk5mSWpRbp2yVwZSy/3MFesEql4uPM7+wN jBuUuxg5OSQETCQ2r7nPCGGLSVy4t56ti5GLQ0hgNpPEwpWTmSGcjYwSS26eYwGpEhJYyCRx +7MWiM0rYCUxa/p6dhCbRUBVYvmDg2CThAWiJCbt/QgWZwOKz195iwnEFgGym/YeZgWxmQU8 JSZNfcwEMUdQ4uTMJywQcXWJP/MuMUPYihJTuh+yT2Dkm4WkbBaSsllIyhYwMq9ilE3JrdLN TczMKU5N1i1OTszLSy3SNdLLzSzRS00p3cQIDkZJ3h2M7w4qHWIU4GBU4uEtqDkXLMSaWFZc mXuIUZKDSUmUt3YlUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIb3QrUI43JbGyKrUoHyYlzcGi JM771toqWEggPbEkNTs1tSC1CCYrw8GhJMHLAIw6IcGi1PTUirTMnBKENBMHJ8hwHqDhVWtA hhcXJOYWZ6ZD5E8x6nJs6z3WxiTEkpeflyolzvsSpEgApCijNA9uDiyJvGIUB3pLmPcmSBUP MAHBTXoFtIQJaElR5mmQJSWJCCmpBsa1Pw4mW1lsCpvXlZ2sutJA4pp5L3vd8fmuxTK8HQuX WBYVnFx58kL3wu8rraN8nm+PX73AdnPyDOsWjaef/7CdSVecevTnjNUZKvxbwhJrOnJLhLQd vBVKZrj+XiPXFVRbaSBlVnBh/QavvPqGf1bu71Lc/rhu0dqWyqWcO5GBTaJsue3Xc0osxRmJ hlrMRcWJAKd65pv9AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Gp7zvjBKS1KsCD7h9heEq_oG3kg Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Tue, 22 Jul 2014 18:30:47 -0000 U28gdGhlIGRyYWZ0IHdvdWxkIGxpdGVyYWxseSB0dXJuIGludG86CgoiVGhlIGE0YyByZXNwb25z ZSB0eXBlIGFuZCBncmFudCB0eXBlIHJldHVybiBhbiBpZF90b2tlbiBmcm9tIHRoZSB0b2tlbiBl bmRwb2ludCB3aXRoIG5vIGFjY2VzcyB0b2tlbi4gQWxsIHBhcmFtZXRlcnMgYW5kIHZhbHVlcyBh cmUgZGVmaW5lZCBpbiBPSURDLiIKClNlZW1zIGxpa2UgdGhlIHBlcmZlY3QgbWluaSBleHRlbnNp b24gZHJhZnQgZm9yIE9JREYgdG8gZG8uCgotLUp1c3RpbgoKL3NlbnQgZnJvbSBteSBwaG9uZS8K Ck9uIEp1bCAyMiwgMjAxNCAxMDoyOSBBTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5j b20+IHdyb3RlOgo+Cj4gV2hhdCBhYm91dCBqdXN0IGRlZmluaW5nIGEgbmV3IGdyYW50IHR5cGUg aW4gdGhpcyBXRz8KPgo+Cj4gMjAxNC0wNy0yMiAxMjo1NiBHTVQtMDQ6MDAgUGhpbCBIdW50IDxw aGlsLmh1bnRAb3JhY2xlLmNvbT46Cj4+Cj4+IFRoYXQgd291bGQgYmUgbmljZS4gSG93ZXZlciBv aWRjIHN0aWxsIG5lZWRzIHRoZSBuZXcgZ3JhbnQgdHlwZSBpbiBvcmRlciB0byBpbXBsZW1lbnQg dGhlIHNhbWUgZmxvdy7CoAo+Pgo+PiBQaGlsCj4+Cj4+IE9uIEp1bCAyMiwgMjAxNCwgYXQgMTE6 MzUsIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPiB3cm90ZToKPj4KPj4+ICsxIHRv IEp1c3Rpbi7CoAo+Pj4KPj4+Cj4+PiAyMDE0LTA3LTIyIDk6NTQgR01ULTA0OjAwIFJpY2hlciwg SnVzdGluIFAuIDxqcmljaGVyQG1pdHJlLm9yZz46Cj4+Pj4KPj4+PiBFcnJvcnMgbGlrZSB0aGVz ZSBtYWtlIGl0IGNsZWFyIHRvIG1lIHRoYXQgaXQgd291bGQgbWFrZSBtdWNoIG1vcmUgc2Vuc2Ug dG8gZGV2ZWxvcCB0aGlzIGRvY3VtZW50IGluIHRoZSBPcGVuSUQgRm91bmRhdGlvbi4gSXQgc2hv dWxkIGJlIHNvbWV0aGluZyB0aGF0IGRpcmVjdGx5IHJlZmVyZW5jZXMgT3BlbklEIENvbm5lY3Qg Q29yZSBmb3IgYWxsIG9mIHRoZXNlIHRlcm1zIGluc3RlYWQgb2YgcmVkZWZpbmluZyB0aGVtLiBJ dCdzIGRvaW5nIGF1dGhlbnRpY2F0aW9uLCB3aGljaCBpcyBmdW5kYW1lbnRhbGx5IHdoYXQgT3Bl bklEIENvbm5lY3QgZG9lcyBvbiB0b3Agb2YgT0F1dGgsIGFuZCBJIGRvbid0IHNlZSBhIGdvb2Qg YXJndW1lbnQgZm9yIGRvaW5nIHRoaXMgd29yayBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAuCj4+Pj4K Pj4+PiDCoC0tIEp1c3Rpbgo+Pj4+Cj4+Pj4gT24gSnVsIDIyLCAyMDE0LCBhdCA0OjMwIEFNLCBU aG9tYXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb20+IHdyb3RlOgo+Pj4+Cj4+Pj4+Cj4+Pj4+ Cj4+Pj4+Cj4+Pj4+IE9uIE1vbiwgSnVsIDIxLCAyMDE0IGF0IDExOjUyIFBNLCBNaWtlIEpvbmVz IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IHdyb3RlOgo+Pj4+Pj4KPj4+Pj4+IFRoYW5r cyBmb3IgeW91ciByZXZpZXcsIFRob21hcy7CoCBUaGUg4oCccHJvbXB0PWNvbnNlbnTigJ0gZGVm aW5pdGlvbiBiZWluZyBtaXNzaW5nIGlzIGFuIGVkaXRvcmlhbCBlcnJvci7CoCBJdCBzaG91bGQg YmU6Cj4+Pj4+Pgo+Pj4+Pj4gwqAKPj4+Pj4+Cj4+Pj4+PiBjb25zZW50Cj4+Pj4+Pgo+Pj4+Pj4g VGhlIEF1dGhvcml6YXRpb24gU2VydmVyIFNIT1VMRCBwcm9tcHQgdGhlIEVuZC1Vc2VyIGZvciBj b25zZW50IGJlZm9yZSByZXR1cm5pbmcgaW5mb3JtYXRpb24gdG8gdGhlIENsaWVudC4gSWYgaXQg Y2Fubm90IG9idGFpbiBjb25zZW50LCBpdCBNVVNUIHJldHVybiBhbiBlcnJvciwgdHlwaWNhbGx5 IGNvbnNlbnRfcmVxdWlyZWQuCj4+Pj4+Pgo+Pj4+Pj4gwqAKPj4+Pj4+Cj4+Pj4+PiBJ4oCZbGwg cGxhbiB0byBhZGQgaXQgaW4gdGhlIG5leHQgZHJhZnQuCj4+Pj4+Cj4+Pj4+Cj4+Pj4+IEl0IGxv b2tzIGxpa2UgdGhlIGNvbnNlbnRfcmVxdWlyZWQgZXJyb3IgbmVlZHMgdG8gYmUgZGVmaW5lZCB0 b28sIGFuZCB5b3UgbWlnaHQgaGF2ZSBmb3Jnb3R0ZW4gdG8gYWxzbyBpbXBvcnQgYWNjb3VudF9z ZWxlY3Rpb25fcmVxdWlyZWQgZnJvbSBPcGVuSUQgQ29ubmVjdC4KPj4+Pj4gwqAKPj4+Pj4+Cj4+ Pj4+PiDCoAo+Pj4+Pj4KPj4+Pj4+IEkgYWdyZWUgdGhhdCB0aGVyZeKAmXMgbm8gZGlmZmVyZW5j ZSBiZXR3ZWVuIGEgcmVzcG9uc2Ugd2l0aCBtdWx0aXBsZSDigJxhbXLigJ0gdmFsdWVzIHRoYXQg aW5jbHVkZXMg4oCcbWZh4oCdIGFuZCBvbmUgdGhhdCBkb2VzbuKAmXQuwqAgVW5sZXNzIGEgY2xl YXIgdXNlIGNhc2UgZm9yIHdoeSDigJxtZmHigJ0gaXMgbmVlZGVkIGNhbiBiZSBpZGVudGlmaWVk LCB3ZSBjYW4gZGVsZXRlIGl0IGluIHRoZSBuZXh0IGRyYWZ0Lgo+Pj4+Pgo+Pj4+Pgo+Pj4+PiBU aGFua3MuCj4+Pj4+Cj4+Pj4+IEhvdyBhYm91dCAicHdkIiB0aGVuPyBJIGZ1bGx5IHVuZGVyc3Rh bmQgdGhhdCBJIHNob3VsZCByZXR1cm4gInB3ZCIgaWYgdGhlIHVzZXIgYXV0aGVudGljYXRlZCB1 c2luZyBhIHBhc3N3b3JkLCBidXQgd2hhdCAidGhlIHNlcnZpY2UgaWYgYSBjbGllbnQgc2VjcmV0 IGlzIHVzZWQiIG1lYW5zIGluIHRoZSBkZWZpbml0aW9uIGZvciB0aGUgInB3ZCIgdmFsdWU/Cj4+ Pj4+Cj4+Pj4+IChOb3RhOiBJIGtub3cgeW91J3JlIGF0IElFVEYtOTAsIEknbSByZWFkeSB0byB3 YWl0ICd0aWwgeW91IGNvbWUgYmFjayA7LSkgKQo+Pj4+Pgo+Pj4+PiAtLSAKPj4+Pj4gVGhvbWFz IEJyb3llcgo+Pj4+PiAvdMmULm1hLmLKgXdhLmplLwo+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+ Pj4gT0F1dGhAaWV0Zi5vcmcKPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aAo+Pj4+Cj4+Pj4KPj4+Pgo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4gT0F1dGhA aWV0Zi5vcmcKPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo Cj4+Pj4KPj4+Cj4+Pgo+Pj4KPj4+IC0tIAo+Pj4gTmF0IFNha2ltdXJhICg9bmF0KQo+Pj4gQ2hh aXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uCj4+PiBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8KPj4+ IEBfbmF0X2VuCj4+Pgo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+Pj4gT0F1dGhAaWV0Zi5vcmcKPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPgo+Cj4KPgo+IC0tIAo+ IE5hdCBTYWtpbXVyYSAoPW5hdCkKPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24KPiBodHRw Oi8vbmF0LnNha2ltdXJhLm9yZy8KPiBAX25hdF9lbg== From nobody Tue Jul 22 15:27:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307C91B2993 for ; Tue, 22 Jul 2014 15:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjQYCjFFz1IC for ; Tue, 22 Jul 2014 15:27:45 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7C81B28E1 for ; Tue, 22 Jul 2014 15:27:43 -0700 (PDT) Received: from [80.67.16.118] (helo=webmail.df.eu) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1X9iX6-00055l-W0; Wed, 23 Jul 2014 00:27:40 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_33d24ce40a742227816f01ea408dd34e" Date: Tue, 22 Jul 2014 18:27:40 -0400 From: torsten@lodderstedt.net To: "Richer, Justin P." In-Reply-To: <3805694E-F081-4B07-9252-4602C531D402@mitre.org> References: <53BBE144.90307@gmx.net> <53BBF0A6.3000801@gmx.net> <453DCBD9-89C5-4BCB-B73B-94CEF842204C@oracle.com> <53F6DF2E-5F56-420D-B94B-70D05C4ED0FC@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADA0BA8@TK5EX14MBXC294.redmond.corp.microsoft.com> <09F7FAD7-5EEC-4A22-84C8-2823D3AC0D2F@mitre.org> <3805694E-F081-4B07-9252-4602C531D402@mitre.org> Message-ID: <1572ca3c9020c739e8dae67373033192@lodderstedt.net> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/WWQEHAIzjE3iIvyo1oV9AaPdHDE Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] =?utf-8?q?Dynamic_Client_Registration=3A_application?= =?utf-8?q?=5Ftype?= 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, 22 Jul 2014 22:27:48 -0000 --=_33d24ce40a742227816f01ea408dd34e Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi all, I don't think this parameter adds any security (as it is self declarded by the caller). I think the constraints on redirect_uris can be specified without the need for another registration parameter. As far as I understand, they merely depend on the grant type. So we could some text to the redirect_uri parameter definition. Something along the following lines: "All redirect URIs registered for a particular client MUST either (1) use the HTTPS scheme or (2) the HTTP scheme with localhost as the hostname or custom schemes. Additionally, clients using the implict grant type MUST only register URLs using the https scheme as redirect_uris; they MUST NOT use localhost as the hostname." regards, Torsten. Am 08.07.2014 21:35, schrieb Richer, Justin P.: > Right, that's how it's used in Connect, which defines only redirect-based flows. However, the OAuth version needs to be more general purpose. > > It seems like this parameter really does need more discussion in the group before it should be added to the spec, and therefore I don't think it's appropriate to add it at this stage (post-WGLC). > > -- Justin > > On Jul 8, 2014, at 8:54 PM, Nat Sakimura wrote: > > If I understand correctly, this parameter is used to appropriately constrain the schema of the Redirect URIs at the time of the registration and is not about fulfilling the Client Type registration requirement in section 2.1. So, making go or no-go decision based on the discussion around section 2.1 probably would not be the way to go. The discussion should happen around the needs on constraining the schema depending on the kind of client. > > Apparently, Connect WG perceived that it is a big enough risk that they need to put a plug on based on the risk evaluation as an identity federation protocol. OAuth has different risk profile so it could decide otherwise, but my gut feeling is that unless there is a good reason not to have it, we may as well keep it. > > Nat > > 2014-07-09 7:54 GMT+09:00 Richer, Justin P. : > > This value was introduced in -18, and it's a direct port from OpenID Connect. It was never in the OAuth Dynamic Registration spec, and though it has been in the OpenID Connect Dynamic Registration spec for a very long time, I think it was a mistake to add it in for several reasons: > > First, the semantics around its values and use are not clearly defined, for the reasons . I don't see any particular harm in keeping it, but I don't really see what value it adds for clients or server developers. We are in a world where there are OAuth clients that are much more than just "native" or "web". > > Second, RFC6749 defines "Client Type" in § 2.1 which defines two values: "confidential" and "public", neither of which maps very cleanly to "native" or "web" as stated in -18. This is especially true when you've got dynamic registration that can make native clients confidential with relative ease. We actually take care of registering the "client type" through the use of the "token_endpoint_auth_method" parameter, which is what § 2.1 is really talking about: secure client authentication (to the token endpoint). > > With this in mind, my preference and suggestion would be to remove this field. If other protocols need it, they can register and define it (like Connect has done). > > -- Justin > > On Jul 8, 2014, at 4:38 PM, Mike Jones wrote: > > I put it back because otherwise, we wouldn't be meeting one of the requirements of the RFC 6749. If you look at the client registration section http://tools.ietf.org/html/rfc6749#section-2 [1], you'll see that registering redirect_uri values is required, as is registering the client type. Without this, there wasn't a way to register the client type. > > -- Mike > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Tuesday, July 08, 2014 12:37 PM > To: Phil Hunt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type > > It was taken out and then put back in as it is a common parameter used by a number of AS. > > We have it in Connect, the best reason for keeping it is to stop people from coming up with a new parameter for the same thing because they haven't looked at the Connect version. > > John B. > > On Jul 8, 2014, at 3:16 PM, Phil Hunt wrote: > >> Does this need to be in the spec? I believe we've already said that others can add attributes as they need. > >> > >> Phil > >> > >> @independentid > >> www.independentid.com [2] > >> phil.hunt@oracle.com > >> > >> > >> > >> On Jul 8, 2014, at 11:56 AM, John Bradley wrote: > >> > >>> The application_type is collected as part of current registration by Google and some other OAuth providers as part of registering redirect uri. > >>> > >>> The text was cut down to allow more flexibility in OAuth. Connect requires registration of redirect_uri and is more ridged about it than OAuth 2. > >>> > >>> Do you think the Connect wording would be appropriate for OAuth? > >>> > >>> John B. > >>> > >>> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig wrote: > >>> > >>>> This additional information makes a lot of sense. > >>>> > >>>> As you said in an earlier mail, the attempt to copy text from the > >>>> OpenID Connect spec failed a bit... > >>>> > >>>> On 07/08/2014 02:49 PM, Nat Sakimura wrote: > >>>>> I suppose authors has imported one of the security feature of > >>>>> OpenID Connect here as well. In the Dynamic Client Registration > >>>>> standard, which is a bit longer than IETF version. You can see the reason from it: > >>>>> > >>>>> application_type > >>>>> OPTIONAL. Kind of the application. The default, if omitted, is web. > >>>>> The defined values are native or web. Web Clients using the OAuth > >>>>> Implicit Grant Type MUST only register URLs using the https scheme > >>>>> as redirect_uris; they MUST NOT use localhost as the hostname. > >>>>> Native Clients MUST only register redirect_uris using custom URI > >>>>> schemes or URLs using the http: scheme with localhost as the > >>>>> hostname. Authorization Servers MAY place additional constraints on > >>>>> Native Clients. Authorization Servers MAY reject Redirection URI > >>>>> values using the http scheme, other than the localhost case for > >>>>> Native Clients. The Authorization Server MUST verify that all the > >>>>> registered redirect_uris conform to these constraints. This > >>>>> prevents sharing a Client ID across different types of Clients. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Nat > >>>>> > >>>>> > >>>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig > >>>>> >>>>> >: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> with version -18 you guys have added a new meta-data attribute, > >>>>> namely application_type. > >>>>> > >>>>> First, this new attribute is not listed in the IANA consideration > >>>>> section. > >>>>> > >>>>> Second, could you provide a bit of motivation why you need it? > >>>>> What would the authorization server do with that type of > >>>>> information? The description is rather short. > >>>>> > >>>>> IMHO there is also no clear boundary between a "native" and "web" app. > >>>>> Just think about smart phone apps that are developed using JavaScript. > >>>>> Would this be a web app or a native app? > >>>>> > >>>>> Here is the definition from the draft: > >>>>> > >>>>> application_type > >>>>> OPTIONAL. Kind of the application. The default, if omitted, is > >>>>> "web". The defined values are "native" or "web". > >>>>> > >>>>> Ciao > >>>>> Hannes > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth [3] > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Nat Sakimura (=nat) > >>>>> Chairman, OpenID Foundation > >>>>> http://nat.sakimura.org/ [4] > >>>>> @_nat_en > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth [3] > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth [3] > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth [3] _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [3] > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [3] -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ [4] @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [3] Links: ------ [1] http://tools.ietf.org/html/rfc6749#section-2 [2] http://www.independentid.com/ [3] https://www.ietf.org/mailman/listinfo/oauth [4] http://nat.sakimura.org/ --=_33d24ce40a742227816f01ea408dd34e Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi all,

I don't think this parameter adds any security (as it is self declarded = by the caller). I think the constraints on redirect_uris can be specified w= ithout the need for another registration parameter. As far as I understand,= they merely depend on the grant type. So we could some text to the redirec= t_uri parameter definition. Something along the following lines:

"All redirect URIs registered for a particular client MUST either (1) = use the HTTPS scheme or (2) the HTTP scheme with localhost as the host= name or custom schemes. Additionally, clients using the implict grant = type MUST only register URLs using the https scheme as redirect_uris; they = MUST NOT use localhost as the hostname."  

regards,
Torsten.

Am 08.07.2014 21:35, schrieb Richer, Justin P.:

Right, that's how it's used in Connect, which defines only re= direct-based flows. However, the OAuth version needs to be more general pur= pose. 
 
It seems like this parameter really does need more discussion in the g= roup before it should be added to the spec, and therefore I don't think it'= s appropriate to add it at this stage (post-WGLC).
 
 -- Justin

On Jul 8, 2014, at 8:54 PM, Nat Sakimura <sakimura@gmail.com> wrote:

If I understand correctly, this parameter is used to appro= priately constrain the schema of the Redirect URIs at the time of the regis= tration and is not about fulfilling the Client Type registration requiremen= t in section 2.1. So, making go or no-go decision based on the discussion a= round section 2.1 probably would not be the way to go. The discussion shoul= d happen around the needs on constraining the schema depending on the kind = of client. 
 
Apparently, Connect WG perceived that it is a big enough risk that the= y need to put a plug on based on the risk evaluation as an identity federat= ion protocol. OAuth has different risk profile so it could decide otherwise= , but my gut feeling is that unless there is a good reason not to have it, = we may as well keep it. 
 
Nat


2014-07-09 7:54 GMT+09:00 Richer, Justin P. <jricher@mitre.org>:
This value was introduced in -18, and= it's a direct port from OpenID Connect. It was never in the OAuth Dynamic = Registration spec, and though it has been in the OpenID Connect Dynamic Reg= istration spec for a very long time, I think it was a mistake to add it in = for several reasons: 
 
First, the semantics around its values and use are not clearly defined= , for the reasons . I don't see any particular harm in keeping it, but I do= n't really see what value it adds for clients or server developers. We are = in a world where there are OAuth clients that are much more than just "nati= ve" or "web".
 
Second, RFC6749 defines "Client Type" in § 2.1 which defines two = values: "confidential" and "public", neither of which maps very cleanly to = "native" or "web" as stated in -18. This is especially true when you've got= dynamic registration that can make native clients confidential with relati= ve ease. We actually take care of registering the "client type" through the= use of the "token_endpoint_auth_method" parameter, which is what § 2= =2E1 is really talking about: secure client authentication (to the token en= dpoint). 
 
With this in mind, my preference and suggestion would be to remove thi= s field. If other protocols need it, they can register and define it (like = Connect has done).
 
 -- Justin
 

On Jul 8, 2014, at 4:38 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I put it back because otherwise, we woul= dn't be meeting one of the requirements of the RFC 6749.  If you look = at the client registration section http://tools.ietf.org/html/rfc6749#section-2, you'll s= ee that registering redirect_uri values is required, as is registering the = client type.  Without this, there wasn't a way to register the client = type.

 

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

 

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradle= y
Sent: Tuesday, July 08, 2014 12:37 PM
To: Phil Hunt
Cc:= oauth@ietf.org
Subject: Re: [O= AUTH-WG] Dynamic Client Registration: application_type

 

It was taken out and then put back in as it is a common parameter used b= y a number of AS.

 

We have it in Connect, the best reason for keeping it is to stop people = from coming up with a new parameter for the same thing because they haven't= looked at the Connect version.=

 

John B.

On Jul 8, 2014, at 3:16 PM, Phil Hunt <phil.hu= nt@oracle.com> wrote:

 

> Does this need to be in the spec?  I believe we've already sai= d that others can add attributes as they need.

>

> Phil

>

> @independentid

> www.independentid.com

> phil.hunt@oracle.com

>

>

>

> On Jul 8, 2014, at 11:56 AM, John Bradley <v= e7jtb@ve7jtb.com> wrote:

>

>> The application_type is collected as part of current registrati= on by Google and some other OAuth providers as part of registering redirect= uri.

>>

>> The text was cut down to allow more flexibility in OAuth. = Connect requires registration of redirect_uri and is more ridged about it = than OAuth 2.

>>

>> Do you think the Connect wording would be appropriate for OAuth= ?

>>

>> John B.

>>

>> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>>

>>> This additional information makes a lot of sense.

>>>

>>> As you said in an earlier mail, the attempt to copy text fr= om the

>>> OpenID Connect spec failed a bit...

>>>

>>> On 07/08/2014 02:49 PM, Nat Sakimura wrote:

>>>> I suppose authors has imported one of the security feat= ure of

>>>> OpenID Connect here as well. In the Dynamic Client Regi= stration

>>>> standard, which is a bit longer than IETF version. You = can see the reason from it:

>>>>

>>>> application_type

>>>>  OPTIONAL. Kind of the application. The default, i= f omitted, is web.

>>>>  The defined values are native or web. Web Clients= using the OAuth  <= span style=3D"text-decoration: underline;">

>>>> Implicit Grant Type MUST only register URLs using the h= ttps scheme 

>>>> as redirect_uris; they MUST NOT use localhost as the ho= stname.

>>>>  Native Clients MUST only register redirect_uris u= sing custom URI 

>>>> schemes or URLs using the http: scheme with localhost a= s the 

>>>> hostname. Authorization Servers MAY place additional co= nstraints on 

>>>> Native Clients. Authorization Servers MAY reject Redire= ction URI 

>>>> values using the http scheme, other than the localhost = case for 

>>>> Native Clients. The Authorization Server MUST verify th= at all the 

>>>> registered redirect_uris conform to these constraints= =2E This

>>>> prevents  sharing a Client ID across different typ= es of Clients.

>>>>

>>>> Regards,

>>>>

>>>> Nat<= span style=3D"text-decoration: underline;">

>>>>

>>>>

>>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig

>>>> <hannes= =2Etschofenig@gmx.net

>>>> <mailto:hannes.tschofeni= g@gmx.net>>:

>>>>

>>>>  Hi all,

>>>>

>>>>  with version -18 you guys have added a new meta-d= ata attribute,

>>>> namely  application_type.

>>>>

>>>>  First, this new attribute is not listed in the IA= NA consideration  <= span style=3D"text-decoration: underline;">

>>>> section.

>>>>

>>>>  Second, could you provide a bit of motivation why= you need it?

>>>> What  would the authorization server do with that = type of

>>>> information? The  description is rather short.

>>>>

>>>>  IMHO there is also no clear boundary between a "n= ative" and "web" app.

>>>>  Just think about smart phone apps that are develo= ped using JavaScript.

>>>>  Would this be a web app or a native app?

>>>>

>>>>  Here is the definition from the draft:

>>>>

>>>>  application_type

>>>>        OPTIONAL.&nbs= p; Kind of the application.  The default, if omitted, is

>>>>        "web".  = The defined values are "native" or "web".

>>>>

>>>>  Ciao<= /span>

>>>>  Hannes

>>>>

>>>>

>>>>  _______________________________________________

>>>>  OAuth mailing list

>>>>  OAuth@ietf.org <mailto:OAuth@ietf.org> 

>>>> https://www.ietf= =2Eorg/mailman/listinfo/oauth

>>>>

>>>>

>>>>

>>>>

>>>> --

>>>> Nat Sakimura (=3Dnat)

>>>> Chairman, OpenID Foundation<= /p>

>>>> http://nat.sakimura.org/=

>>>> @_nat_en

>>>

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf.org

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

>>

>> _______________________________________________

>> OAuth mailing list<= /span>

>> OAuth@ietf.org<= /span>

>> https://www.ietf.org/mai= lman/listinfo/oauth<= /span>

>

 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/list= info/oauth

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

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



 
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
= http://nat.sakimura.org/
@_nat_en

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

 

 
--=_33d24ce40a742227816f01ea408dd34e-- From nobody Tue Jul 22 18:16:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DB81A0012 for ; Tue, 22 Jul 2014 18:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 QXe0Wy42UTdR for ; Tue, 22 Jul 2014 18:16:00 -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 BDC5D1A0092 for ; Tue, 22 Jul 2014 18:15:59 -0700 (PDT) X-AuditID: 12074422-f79be6d000007518-fb-53cf0ccffe41 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 51.1C.29976.FCC0FC35; Tue, 22 Jul 2014 21:15:59 -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 s6N1FwF7013357; Tue, 22 Jul 2014 21:15:58 -0400 Received: from [21.58.209.89] ([172.56.38.133]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6N1FsJe030731 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Jul 2014 21:15:56 -0400 Message-Id: <201407230115.s6N1FsJe030731@outgoing.mit.edu> Date: Tue, 22 Jul 2014 18:15:51 -0700 From: Justin Richer To: torsten@lodderstedt.net MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsUixG6nrnue53ywwcl/3BYbbpxgtTj59hWb xatjT1kcmD2WLPnJ5HGsp5/V423DVfYA5igum5TUnMyy1CJ9uwSujDlvT7EW7CquONOwj6mB cU9BFyMHh4SAicSDpS5djJxAppjEhXvr2boYuTiEBGYzSVzcsJwRwtnIKPF+13t2CGchk8SD ZwfYQFp4Bawkmp4tZQGxWQRUJRYd28AOYgsLuEqsfb8PrIYNKD5/5S0mEFtEQFpi+tdDjCA2 s4CpxLtls5gg5ghKnJz5hAUiri7xZ94lZghbUWJK90P2CYx8s5CUzUJSNgtJ2QJG5lWMsim5 Vbq5iZk5xanJusXJiXl5qUW6pnq5mSV6qSmlmxjBweiitIPx50GlQ4wCHIxKPLwFNeeChVgT y4orcw8xSnIwKYnyerwHCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhjW4FyvGmJFZWpRblw6Sk OViUxHnfWlsFCwmkJ5akZqemFqQWwWRlODiUJHhjgFEnJFiUmp5akZaZU4KQZuLgBBnOAzR8 ETdQDW9xQWJucWY6RP4Uo6KUOG8kSEIAJJFRmgfXC0sWrxjFgV4R5mUDWcEDTDRw3a+ABjMB DS7KPA0yuCQRISXVwGhavnri9Lk2MyzeGTVOlap6XpQQs3qX1M4iJtEbbSs3ctY+dNaMKXFk qi5fI7mKXTJ16stzBeeCRYM4Gu1e8svEqnJ4vYsItE0xWxvpw1H4ku+5zqHwWJuYDyGOHEs2 1M3R+9LxOuWkk6Pc16Tvr29MSN9zaRvPlDnfeV/2TV14+bnXT2WRs0osxRmJhlrMRcWJAJpz KuPxAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ZIgVpTRryOFsxjlhYlasWDLNPtM Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 23 Jul 2014 01:16:03 -0000 SSdtIG9rIHdpdGggdGhhdCB0ZXh0LCBhbmQgYWN0dWFsbHkgdGhvdWdodCB3ZSBoYWQgc29tZXRo aW5nIGFsb25nIHRob3NlIGxpbmVzIGFscmVhZHkuCgotLUp1c3RpbgoKL3NlbnQgZnJvbSBteSBw aG9uZS8KCk9uIEp1bCAyMiwgMjAxNCAzOjI3IFBNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCB3 cm90ZToKPgo+IEhpIGFsbCwKPgo+IEkgZG9uJ3QgdGhpbmsgdGhpcyBwYXJhbWV0ZXIgYWRkcyBh bnkgc2VjdXJpdHkgKGFzIGl0IGlzIHNlbGYgZGVjbGFyZGVkIGJ5IHRoZSBjYWxsZXIpLiBJIHRo aW5rIHRoZSBjb25zdHJhaW50cyBvbiByZWRpcmVjdF91cmlzIGNhbiBiZSBzcGVjaWZpZWQgd2l0 aG91dCB0aGUgbmVlZCBmb3IgYW5vdGhlciByZWdpc3RyYXRpb24gcGFyYW1ldGVyLiBBcyBmYXIg YXMgSSB1bmRlcnN0YW5kLCB0aGV5IG1lcmVseSBkZXBlbmQgb24gdGhlIGdyYW50IHR5cGUuIFNv IHdlIGNvdWxkIHNvbWUgdGV4dCB0byB0aGUgcmVkaXJlY3RfdXJpIHBhcmFtZXRlciBkZWZpbml0 aW9uLiBTb21ldGhpbmcgYWxvbmcgdGhlIGZvbGxvd2luZyBsaW5lczoKPgo+ICJBbGwgcmVkaXJl Y3QgVVJJcyByZWdpc3RlcmVkIGZvciBhIHBhcnRpY3VsYXIgY2xpZW50IE1VU1QgZWl0aGVyICgx KSB1c2UgdGhlwqBIVFRQUyBzY2hlbWUgb3IgKDIpIHRoZSBIVFRQIHNjaGVtZSB3aXRoIGxvY2Fs aG9zdCBhcyB0aGUgaG9zdG5hbWUgb3IgY3VzdG9tIHNjaGVtZXMuIEFkZGl0aW9uYWxseSwgY2xp ZW50cyB1c2luZyB0aGUgaW1wbGljdMKgZ3JhbnQgdHlwZSBNVVNUIG9ubHkgcmVnaXN0ZXIgVVJM cyB1c2luZyB0aGUgaHR0cHMgc2NoZW1lIGFzIHJlZGlyZWN0X3VyaXM7IHRoZXkgTVVTVCBOT1Qg dXNlIGxvY2FsaG9zdCBhcyB0aGUgaG9zdG5hbWUuIiDCoAo+Cj4gcmVnYXJkcywKPiBUb3JzdGVu Lgo+Cj4gQW0gMDguMDcuMjAxNCAyMTozNSwgc2NocmllYiBSaWNoZXIsIEp1c3RpbiBQLjoKPj4K Pj4gUmlnaHQsIHRoYXQncyBob3cgaXQncyB1c2VkIGluIENvbm5lY3QsIHdoaWNoIGRlZmluZXMg b25seSByZWRpcmVjdC1iYXNlZCBmbG93cy4gSG93ZXZlciwgdGhlIE9BdXRoIHZlcnNpb24gbmVl ZHMgdG8gYmUgbW9yZSBnZW5lcmFsIHB1cnBvc2UuwqAKPj4gwqAKPj4gSXQgc2VlbXMgbGlrZSB0 aGlzIHBhcmFtZXRlciByZWFsbHkgZG9lcyBuZWVkIG1vcmUgZGlzY3Vzc2lvbiBpbiB0aGUgZ3Jv dXAgYmVmb3JlIGl0IHNob3VsZCBiZSBhZGRlZCB0byB0aGUgc3BlYywgYW5kIHRoZXJlZm9yZSBJ IGRvbid0IHRoaW5rIGl0J3MgYXBwcm9wcmlhdGUgdG8gYWRkIGl0IGF0IHRoaXMgc3RhZ2UgKHBv c3QtV0dMQykuCj4+IMKgCj4+IMKgLS0gSnVzdGluCj4+Cj4+IE9uIEp1bCA4LCAyMDE0LCBhdCA4 OjU0IFBNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT4gd3JvdGU6Cj4+Cj4+PiBJ ZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB0aGlzIHBhcmFtZXRlciBpcyB1c2VkIHRvIGFwcHJv cHJpYXRlbHkgY29uc3RyYWluIHRoZSBzY2hlbWEgb2YgdGhlIFJlZGlyZWN0IFVSSXMgYXQgdGhl IHRpbWUgb2YgdGhlIHJlZ2lzdHJhdGlvbiBhbmQgaXMgbm90IGFib3V0IGZ1bGZpbGxpbmcgdGhl IENsaWVudCBUeXBlIHJlZ2lzdHJhdGlvbiByZXF1aXJlbWVudCBpbiBzZWN0aW9uIDIuMS4gU28s IG1ha2luZyBnbyBvciBuby1nbyBkZWNpc2lvbiBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBhcm91 bmQgc2VjdGlvbiAyLjEgcHJvYmFibHkgd291bGQgbm90IGJlIHRoZSB3YXkgdG8gZ28uIFRoZSBk aXNjdXNzaW9uIHNob3VsZCBoYXBwZW4gYXJvdW5kIHRoZSBuZWVkcyBvbiBjb25zdHJhaW5pbmcg dGhlIHNjaGVtYSBkZXBlbmRpbmcgb24gdGhlIGtpbmQgb2YgY2xpZW50LsKgCj4+PiDCoAo+Pj4g QXBwYXJlbnRseSwgQ29ubmVjdCBXRyBwZXJjZWl2ZWQgdGhhdCBpdCBpcyBhIGJpZyBlbm91Z2gg cmlzayB0aGF0IHRoZXkgbmVlZCB0byBwdXQgYSBwbHVnIG9uIGJhc2VkIG9uIHRoZSByaXNrIGV2 YWx1YXRpb24gYXMgYW4gaWRlbnRpdHkgZmVkZXJhdGlvbiBwcm90b2NvbC4gT0F1dGggaGFzIGRp ZmZlcmVudCByaXNrIHByb2ZpbGUgc28gaXQgY291bGQgZGVjaWRlIG90aGVyd2lzZSwgYnV0IG15 IGd1dCBmZWVsaW5nIGlzIHRoYXQgdW5sZXNzIHRoZXJlIGlzIGEgZ29vZCByZWFzb24gbm90IHRv IGhhdmUgaXQsIHdlIG1heSBhcyB3ZWxsIGtlZXAgaXQuwqAKPj4+IMKgCj4+PiBOYXQKPj4+Cj4+ Pgo+Pj4gMjAxNC0wNy0wOSA3OjU0IEdNVCswOTowMCBSaWNoZXIsIEp1c3RpbiBQLiA8anJpY2hl ckBtaXRyZS5vcmc+Ogo+Pj4+Cj4+Pj4gVGhpcyB2YWx1ZSB3YXMgaW50cm9kdWNlZCBpbiAtMTgs IGFuZCBpdCdzIGEgZGlyZWN0IHBvcnQgZnJvbSBPcGVuSUQgQ29ubmVjdC4gSXQgd2FzIG5ldmVy IGluIHRoZSBPQXV0aCBEeW5hbWljIFJlZ2lzdHJhdGlvbiBzcGVjLCBhbmQgdGhvdWdoIGl0IGhh cyBiZWVuIGluIHRoZSBPcGVuSUQgQ29ubmVjdCBEeW5hbWljIFJlZ2lzdHJhdGlvbiBzcGVjIGZv ciBhIHZlcnkgbG9uZyB0aW1lLCBJIHRoaW5rIGl0IHdhcyBhIG1pc3Rha2UgdG8gYWRkIGl0IGlu IGZvciBzZXZlcmFsIHJlYXNvbnM6wqAKPj4+PiDCoAo+Pj4+IEZpcnN0LCB0aGUgc2VtYW50aWNz IGFyb3VuZCBpdHMgdmFsdWVzIGFuZCB1c2UgYXJlIG5vdCBjbGVhcmx5IGRlZmluZWQsIGZvciB0 aGUgcmVhc29ucyAuIEkgZG9uJ3Qgc2VlIGFueSBwYXJ0aWN1bGFyIGhhcm0gaW4ga2VlcGluZyBp dCwgYnV0IEkgZG9uJ3QgcmVhbGx5IHNlZSB3aGF0IHZhbHVlIGl0IGFkZHMgZm9yIGNsaWVudHMg b3Igc2VydmVyIGRldmVsb3BlcnMuIFdlIGFyZSBpbiBhIHdvcmxkIHdoZXJlIHRoZXJlIGFyZSBP QXV0aCBjbGllbnRzIHRoYXQgYXJlIG11Y2ggbW9yZSB0aGFuIGp1c3QgIm5hdGl2ZSIgb3IgIndl YiIuCj4+Pj4gwqAKPj4+PiBTZWNvbmQsIFJGQzY3NDkgZGVmaW5lcyAiQ2xpZW50IFR5cGUiIGlu IMKnIDIuMSB3aGljaCBkZWZpbmVzIHR3byB2YWx1ZXM6ICJjb25maWRlbnRpYWwiIGFuZCAicHVi bGljIiwgbmVpdGhlciBvZiB3aGljaCBtYXBzIHZlcnkgY2xlYW5seSB0byAibmF0aXZlIiBvciAi d2ViIiBhcyBzdGF0ZWQgaW4gLTE4LiBUaGlzIGlzIGVzcGVjaWFsbHkgdHJ1ZSB3aGVuIHlvdSd2 ZSBnb3QgZHluYW1pYyByZWdpc3RyYXRpb24gdGhhdCBjYW4gbWFrZSBuYXRpdmUgY2xpZW50cyBj b25maWRlbnRpYWwgd2l0aCByZWxhdGl2ZSBlYXNlLiBXZSBhY3R1YWxseSB0YWtlIGNhcmUgb2Yg cmVnaXN0ZXJpbmcgdGhlICJjbGllbnQgdHlwZSIgdGhyb3VnaCB0aGUgdXNlIG9mIHRoZSAidG9r ZW5fZW5kcG9pbnRfYXV0aF9tZXRob2QiIHBhcmFtZXRlciwgd2hpY2ggaXMgd2hhdCDCpyAyLjEg aXMgcmVhbGx5IHRhbGtpbmcgYWJvdXQ6IHNlY3VyZSBjbGllbnQgYXV0aGVudGljYXRpb24gKHRv IHRoZSB0b2tlbiBlbmRwb2ludCkuwqAKPj4+PiDCoAo+Pj4+IFdpdGggdGhpcyBpbiBtaW5kLCBt eSBwcmVmZXJlbmNlIGFuZCBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIHJlbW92ZSB0aGlzIGZpZWxk LiBJZiBvdGhlciBwcm90b2NvbHMgbmVlZCBpdCwgdGhleSBjYW4gcmVnaXN0ZXIgYW5kIGRlZmlu ZSBpdCAobGlrZSBDb25uZWN0IGhhcyBkb25lKS4KPj4+PiDCoAo+Pj4+IMKgLS0gSnVzdGluCj4+ Pj4gwqAKPj4+Pgo+Pj4+IE9uIEp1bCA4LCAyMDE0LCBhdCA0OjM4IFBNLCBNaWtlIEpvbmVzIDxN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IHdyb3RlOgo+Pj4+Cj4+Pj4+IEkgcHV0IGl0IGJh Y2sgYmVjYXVzZSBvdGhlcndpc2UsIHdlIHdvdWxkbid0IGJlIG1lZXRpbmcgb25lIG9mIHRoZSBy ZXF1aXJlbWVudHMgb2YgdGhlIFJGQyA2NzQ5LsKgIElmIHlvdSBsb29rIGF0IHRoZSBjbGllbnQg cmVnaXN0cmF0aW9uIHNlY3Rpb24gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNz ZWN0aW9uLTIsIHlvdSdsbCBzZWUgdGhhdCByZWdpc3RlcmluZyByZWRpcmVjdF91cmkgdmFsdWVz IGlzIHJlcXVpcmVkLCBhcyBpcyByZWdpc3RlcmluZyB0aGUgY2xpZW50IHR5cGUuwqAgV2l0aG91 dCB0aGlzLCB0aGVyZSB3YXNuJ3QgYSB3YXkgdG8gcmVnaXN0ZXIgdGhlIGNsaWVudCB0eXBlLgo+ Pj4+Pgo+Pj4+PiDCoAo+Pj4+Pgo+Pj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIC0tIE1pa2UKPj4+Pj4KPj4+Pj4gwqAKPj4+ Pj4KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPj4+Pj4gRnJvbTogT0F1dGggW21h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5Cj4+ Pj4+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDgsIDIwMTQgMTI6MzcgUE0KPj4+Pj4gVG86IFBoaWwg SHVudAo+Pj4+PiBDYzogb2F1dGhAaWV0Zi5vcmcKPj4+Pj4gU3ViamVjdDogUmU6IFtPQVVUSC1X R10gRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uOiBhcHBsaWNhdGlvbl90eXBlCj4+Pj4+Cj4+ Pj4+IMKgCj4+Pj4+Cj4+Pj4+IEl0IHdhcyB0YWtlbiBvdXQgYW5kIHRoZW4gcHV0IGJhY2sgaW4g YXMgaXQgaXMgYSBjb21tb24gcGFyYW1ldGVyIHVzZWQgYnkgYSBudW1iZXIgb2YgQVMuCj4+Pj4+ Cj4+Pj4+IMKgCj4+Pj4+Cj4+Pj4+IFdlIGhhdmUgaXQgaW4gQ29ubmVjdCwgdGhlIGJlc3QgcmVh c29uIGZvciBrZWVwaW5nIGl0IGlzIHRvIHN0b3AgcGVvcGxlIGZyb20gY29taW5nIHVwIHdpdGgg YSBuZXcgcGFyYW1ldGVyIGZvciB0aGUgc2FtZSB0aGluZyBiZWNhdXNlIHRoZXkgaGF2ZW4ndCBs b29rZWQgYXQgdGhlIENvbm5lY3QgdmVyc2lvbi4KPj4+Pj4KPj4+Pj4gwqAKPj4+Pj4KPj4+Pj4g Sm9obiBCLgo+Pj4+Pgo+Pj4+PiBPbiBKdWwgOCwgMjAxNCwgYXQgMzoxNiBQTSwgUGhpbCBIdW50 IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4gd3JvdGU6Cj4+Pj4+Cj4+Pj4+IMKgCj4+Pj4+Cj4+Pj4+ ID4gRG9lcyB0aGlzIG5lZWQgdG8gYmUgaW4gdGhlIHNwZWM/wqAgSSBiZWxpZXZlIHdlJ3ZlIGFs cmVhZHkgc2FpZCB0aGF0IG90aGVycyBjYW4gYWRkIGF0dHJpYnV0ZXMgYXMgdGhleSBuZWVkLgo+ Pj4+Pgo+Pj4+PiA+Cj4+Pj4+Cj4+Pj4+ID4gUGhpbAo+Pj4+Pgo+Pj4+PiA+Cj4+Pj4+Cj4+Pj4+ ID4gQGluZGVwZW5kZW50aWQKPj4+Pj4KPj4+Pj4gPiB3d3cuaW5kZXBlbmRlbnRpZC5jb20KPj4+ Pj4KPj4+Pj4gPiBwaGlsLmh1bnRAb3JhY2xlLmNvbQo+Pj4+Pgo+Pj4+PiA+Cj4+Pj4+Cj4+Pj4+ ID4KPj4+Pj4KPj4+Pj4gPgo+Pj4+Pgo+Pj4+PiA+IE9uIEp1bCA4LCAyMDE0LCBhdCAxMTo1NiBB TSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT4gd3JvdGU6Cj4+Pj4+Cj4+Pj4+ID4K Pj4+Pj4KPj4+Pj4gPj4gVGhlIGFwcGxpY2F0aW9uX3R5cGUgaXMgY29sbGVjdGVkIGFzIHBhcnQg b2YgY3VycmVudCByZWdpc3RyYXRpb24gYnkgR29vZ2xlIGFuZCBzb21lIG90aGVyIE9BdXRoIHBy b3ZpZGVycyBhcyBwYXJ0IG9mIHJlZ2lzdGVyaW5nIHJlZGlyZWN0IHVyaS4KPj4+Pj4KPj4+Pj4g Pj4KPj4+Pj4KPj4+Pj4gPj4gVGhlIHRleHQgd2FzIGN1dCBkb3duIHRvIGFsbG93IG1vcmUgZmxl eGliaWxpdHkgaW4gT0F1dGguwqAgQ29ubmVjdCByZXF1aXJlcyByZWdpc3RyYXRpb24gb2YgcmVk aXJlY3RfdXJpIGFuZCBpcyBtb3JlIHJpZGdlZCBhYm91dCBpdCB0aGFuIE9BdXRoIDIuCj4+Pj4+ Cj4+Pj4+ID4+Cj4+Pj4+Cj4+Pj4+ID4+IERvIHlvdSB0aGluayB0aGUgQ29ubmVjdCB3b3JkaW5n IHdvdWxkIGJlIGFwcHJvcHJpYXRlIGZvciBPQXV0aD8KPj4+Pj4KPj4+Pj4gPj4KPj4+Pj4KPj4+ Pj4gPj4gSm9obiBCLgo+Pj4+Pgo+Pj4+PiA+Pgo+Pj4+Pgo+Pj4+PiA+PiBPbiBKdWwgOCwgMjAx NCwgYXQgOToyMiBBTSwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQ+IHdyb3RlOgo+Pj4+Pgo+Pj4+PiA+Pgo+Pj4+Pgo+Pj4+PiA+Pj4gVGhpcyBhZGRpdGlvbmFs IGluZm9ybWF0aW9uIG1ha2VzIGEgbG90IG9mIHNlbnNlLgo+Pj4+Pgo+Pj4+PiA+Pj4KPj4+Pj4K Pj4+Pj4gPj4+IEFzIHlvdSBzYWlkIGluIGFuIGVhcmxpZXIgbWFpbCwgdGhlIGF0dGVtcHQgdG8g Y29weSB0ZXh0IGZyb20gdGhlCj4+Pj4+Cj4+Pj4+ID4+PiBPcGVuSUQgQ29ubmVjdCBzcGVjIGZh aWxlZCBhIGJpdC4uLgo+Pj4+Pgo+Pj4+PiA+Pj4KPj4+Pj4KPj4+Pj4gPj4+IE9uIDA3LzA4LzIw MTQgMDI6NDkgUE0sIE5hdCBTYWtpbXVyYSB3cm90ZToKPj4+Pj4KPj4+Pj4gPj4+PiBJIHN1cHBv c2UgYXV0aG9ycyBoYXMgaW1wb3J0ZWQgb25lIG9mIHRoZSBzZWN1cml0eSBmZWF0dXJlIG9mCj4+ Pj4+Cj4+Pj4+ID4+Pj4gT3BlbklEIENvbm5lY3QgaGVyZSBhcyB3ZWxsLiBJbiB0aGUgRHluYW1p YyBDbGllbnQgUmVnaXN0cmF0aW9uCj4+Pj4+Cj4+Pj4+ID4+Pj4gc3RhbmRhcmQsIHdoaWNoIGlz IGEgYml0IGxvbmdlciB0aGFuIElFVEYgdmVyc2lvbi4gWW91IGNhbiBzZWUgdGhlIHJlYXNvbiBm cm9tIGl0Ogo+Pj4+Pgo+Pj4+PiA+Pj4+Cj4+Pj4+Cj4+Pj4+ID4+Pj4gYXBwbGljYXRpb25fdHlw ZQo+Pj4+Pgo+Pj4+PiA+Pj4+wqAgT1BUSU9OQUwuIEtpbmQgb2YgdGhlIGFwcGxpY2F0aW9uLiBU aGUgZGVmYXVsdCwgaWYgb21pdHRlZCwgaXMgd2ViLgo+Pj4+Pgo+Pj4+PiA+Pj4+wqAgVGhlIGRl ZmluZWQgdmFsdWVzIGFyZSBuYXRpdmUgb3Igd2ViLiBXZWIgQ2xpZW50cyB1c2luZyB0aGUgT0F1 dGjCoAo+Pj4+Pgo+Pj4+PiA+Pj4+IEltcGxpY2l0IEdyYW50IFR5cGUgTVVTVCBvbmx5IHJlZ2lz dGVyIFVSTHMgdXNpbmcgdGhlIGh0dHBzIHNjaGVtZcKgCj4+Pj4+Cj4+Pj4+ID4+Pj4gYXMgcmVk aXJlY3RfdXJpczsgdGhleSBNVVNUIE5PVCB1c2UgbG9jYWxob3N0IGFzIHRoZSBob3N0bmFtZS4K Pj4+Pj4KPj4+Pj4gPj4+PsKgIE5hdGl2ZSBDbGllbnRzIE1VU1Qgb25seSByZWdpc3RlciByZWRp cmVjdF91cmlzIHVzaW5nIGN1c3RvbSBVUknCoAo+Pj4+Pgo+Pj4+PiA+Pj4+IHNjaGVtZXMgb3Ig VVJMcyB1c2luZyB0aGUgaHR0cDogc2NoZW1lIHdpdGggbG9jYWxob3N0IGFzIHRoZcKgCj4+Pj4+ Cj4+Pj4+ID4+Pj4gaG9zdG5hbWUuIEF1dGhvcml6YXRpb24gU2VydmVycyBNQVkgcGxhY2UgYWRk aXRpb25hbCBjb25zdHJhaW50cyBvbsKgCj4+Pj4+Cj4+Pj4+ID4+Pj4gTmF0aXZlIENsaWVudHMu IEF1dGhvcml6YXRpb24gU2VydmVycyBNQVkgcmVqZWN0IFJlZGlyZWN0aW9uIFVSScKgCj4+Pj4+ Cj4+Pj4+ID4+Pj4gdmFsdWVzIHVzaW5nIHRoZSBodHRwIHNjaGVtZSwgb3RoZXIgdGhhbiB0aGUg bG9jYWxob3N0IGNhc2UgZm9ywqAKPj4+Pj4KPj4+Pj4gPj4+PiBOYXRpdmUgQ2xpZW50cy4gVGhl IEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1QgdmVyaWZ5IHRoYXQgYWxsIHRoZcKgCj4+Pj4+Cj4+ Pj4+ID4+Pj4gcmVnaXN0ZXJlZCByZWRpcmVjdF91cmlzIGNvbmZvcm0gdG8gdGhlc2UgY29uc3Ry YWludHMuIFRoaXMKPj4+Pj4KPj4+Pj4gPj4+PiBwcmV2ZW50c8KgIHNoYXJpbmcgYSBDbGllbnQg SUQgYWNyb3NzIGRpZmZlcmVudCB0eXBlcyBvZiBDbGllbnRzLgo+Pj4+Pgo+Pj4+PiA+Pj4+Cj4+ Pj4+Cj4+Pj4+ID4+Pj4gUmVnYXJkcywKPj4+Pj4KPj4+Pj4gPj4+Pgo+Pj4+Pgo+Pj4+PiA+Pj4+ IE5hdAo+Pj4+Pgo+Pj4+PiA+Pj4+Cj4+Pj4+Cj4+Pj4+ID4+Pj4KPj4+Pj4KPj4+Pj4gPj4+PiAy MDE0LTA3LTA4IDIxOjE3IEdNVCswOTowMCBIYW5uZXMgVHNjaG9mZW5pZwo+Pj4+Pgo+Pj4+PiA+ Pj4+IDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Cj4+Pj4+Cj4+Pj4+ID4+Pj4gPG1haWx0bzpo YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj46Cj4+Pj4+Cj4+Pj4+ID4+Pj4KPj4+Pj4KPj4+Pj4g Pj4+PsKgIEhpIGFsbCwKPj4+Pj4KPj4+Pj4gPj4+Pgo+Pj4+Pgo+Pj4+PiA+Pj4+wqAgd2l0aCB2 ZXJzaW9uIC0xOCB5b3UgZ3V5cyBoYXZlIGFkZGVkIGEgbmV3IG1ldGEtZGF0YSBhdHRyaWJ1dGUs Cj4+Pj4+Cj4+Pj4+ID4+Pj4gbmFtZWx5wqAgYXBwbGljYXRpb25fdHlwZS4KPj4+Pj4KPj4+Pj4g Pj4+Pgo+Pj4+Pgo+Pj4+PiA+Pj4+wqAgRmlyc3QsIHRoaXMgbmV3IGF0dHJpYnV0ZSBpcyBub3Qg bGlzdGVkIGluIHRoZSBJQU5BIGNvbnNpZGVyYXRpb27CoAo+Pj4+Pgo+Pj4+PiA+Pj4+IHNlY3Rp b24uCj4+Pj4+Cj4+Pj4+ID4+Pj4KPj4+Pj4KPj4+Pj4gPj4+PsKgIFNlY29uZCwgY291bGQgeW91 IHByb3ZpZGUgYSBiaXQgb2YgbW90aXZhdGlvbiB3aHkgeW91IG5lZWQgaXQ/Cj4+Pj4+Cj4+Pj4+ ID4+Pj4gV2hhdMKgIHdvdWxkIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkbyB3aXRoIHRoYXQg dHlwZSBvZgo+Pj4+Pgo+Pj4+PiA+Pj4+IGluZm9ybWF0aW9uPyBUaGXCoCBkZXNjcmlwdGlvbiBp cyByYXRoZXIgc2hvcnQuCj4+Pj4+Cj4+Pj4+ID4+Pj4KPj4+Pj4KPj4+Pj4gPj4+PsKgIElNSE8g dGhlcmUgaXMgYWxzbyBubyBjbGVhciBib3VuZGFyeSBiZXR3ZWVuIGEgIm5hdGl2ZSIgYW5kICJ3 ZWIiIGFwcC4KPj4+Pj4KPj4+Pj4gPj4+PsKgIEp1c3QgdGhpbmsgYWJvdXQgc21hcnQgcGhvbmUg YXBwcyB0aGF0IGFyZSBkZXZlbG9wZWQgdXNpbmcgSmF2YVNjcmlwdC4KPj4+Pj4KPj4+Pj4gPj4+ PsKgIFdvdWxkIHRoaXMgYmUgYSB3ZWIgYXBwIG9yIGEgbmF0aXZlIGFwcD8KPj4+Pj4KPj4+Pj4g Pj4+Pgo+Pj4+Pgo+Pj4+PiA+Pj4+wqAgSGVyZSBpcyB0aGUgZGVmaW5pdGlvbiBmcm9tIHRoZSBk cmFmdDoKPj4+Pj4KPj4+Pj4gPj4+Pgo+Pj4+Pgo+Pj4+PiA+Pj4+wqAgYXBwbGljYXRpb25fdHlw ZQo+Pj4+Pgo+Pj4+PiA+Pj4+wqDCoMKgwqDCoMKgwqAgT1BUSU9OQUwuwqAgS2luZCBvZiB0aGUg YXBwbGljYXRpb24uwqAgVGhlIGRlZmF1bHQsIGlmIG9taXR0ZWQsIGlzCj4+Pj4+Cj4+Pj4+ID4+ Pj7CoMKgwqDCoMKgwqDCoCAid2ViIi7CoCBUaGUgZGVmaW5lZCB2YWx1ZXMgYXJlICJuYXRpdmUi IG9yICJ3ZWIiLgo+Pj4+Pgo+Pj4+PiA+Pj4+Cj4+Pj4+Cj4+Pj4+ID4+Pj7CoCBDaWFvCj4+Pj4+ Cj4+Pj4+ID4+Pj7CoCBIYW5uZXMKPj4+Pj4KPj4+Pj4gPj4+Pgo+Pj4+Pgo+Pj4+PiA+Pj4+Cj4+ Pj4+Cj4+Pj4+ID4+Pj7CoCBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwo+Pj4+Pgo+Pj4+PiA+Pj4+wqAgT0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4+Cj4+Pj4+ ID4+Pj7CoCBPQXV0aEBpZXRmLm9yZyA8bWFpbHRvOk9BdXRoQGlldGYub3JnPsKgCj4+Pj4+Cj4+ Pj4+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+ Pgo+Pj4+PiA+Pj4+Cj4+Pj4+Cj4+Pj4+ID4+Pj4KPj4+Pj4KPj4+Pj4gPj4+Pgo+Pj4+Pgo+Pj4+ PiA+Pj4+Cj4+Pj4+Cj4+Pj4+ID4+Pj4gLS0KPj4+Pj4KPj4+Pj4gPj4+PiBOYXQgU2FraW11cmEg KD1uYXQpCj4+Pj4+Cj4+Pj4+ID4+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uCj4+Pj4+ Cj4+Pj4+ID4+Pj4gaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvCj4+Pj4+Cj4+Pj4+ID4+Pj4gQF9u YXRfZW4KPj4+Pj4KPj4+Pj4gPj4+Cj4+Pj4+Cj4+Pj4+ID4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+Pgo+Pj4+PiA+Pj4gT0F1dGggbWFpbGlu ZyBsaXN0Cj4+Pj4+Cj4+Pj4+ID4+PiBPQXV0aEBpZXRmLm9yZwo+Pj4+Pgo+Pj4+PiA+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+Pgo+Pj4+PiA+Pgo+ Pj4+Pgo+Pj4+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwo+Pj4+Pgo+Pj4+PiA+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+Pj4KPj4+Pj4gPj4gT0F1 dGhAaWV0Zi5vcmcKPj4+Pj4KPj4+Pj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aAo+Pj4+Pgo+Pj4+PiA+Cj4+Pj4+Cj4+Pj4+IMKgCj4+Pj4+Cj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4+Cj4+Pj4+ IE9BdXRoIG1haWxpbmcgbGlzdAo+Pj4+Pgo+Pj4+PiBPQXV0aEBpZXRmLm9yZwo+Pj4+Pgo+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+Pj4+Cj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4+IE9B dXRoIG1haWxpbmcgbGlzdAo+Pj4+PiBPQXV0aEBpZXRmLm9yZwo+Pj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+Pj4KPj4+Pgo+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4gT0F1dGggbWFpbGluZyBs aXN0Cj4+Pj4gT0F1dGhAaWV0Zi5vcmcKPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoCj4+Pj4KPj4+Cj4+Pgo+Pj4gwqAKPj4+IC0tIAo+Pj4gTmF0IFNha2lt dXJhICg9bmF0KQo+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uCj4+PiBodHRwOi8vbmF0 LnNha2ltdXJhLm9yZy8KPj4+IEBfbmF0X2VuCj4+Cj4+Cj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Cj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+Pgo+ PiBPQXV0aEBpZXRmLm9yZwo+Pgo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoCj4+Cj4gwqAKPgo+IMKg From nobody Tue Jul 22 21:46:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDEB1B27DE for ; Tue, 22 Jul 2014 21:46: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 d1JNvJcC9LkL for ; Tue, 22 Jul 2014 21:46:28 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2EC11B27AF for ; Tue, 22 Jul 2014 21:46:27 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id c11so486585lbj.9 for ; Tue, 22 Jul 2014 21:46: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=pRW5LAVeY+/1yU1SUYkCZ0IGQIIqAdCRArS1L7+IXbY=; b=oqXrrgHxAOjyikrNPE+kBrBHvKaAqhqukjho+HTFr9sb3HPyxX342yIc69ljLXGsOi 8hKLk6js9h+wraKmm+eUT3EhNa7pFwMXlR02a6qX/mTv07+QqbvfqmukOpP1L5NG0fS9 B8HozjuBPAq1HKdJ4OgjU9cEqf1dUbQJIg0V45we3X6COQqwu4djqtSr5tTRPv8pR/Cl JWO17HZdMgCqBikRS+0pLrCpMupHCtwAMWqwYQrvqYmkp0eRgMaRM6hfOXgpXNyvQ6bN CGJFiHXuzRDLye0cY3d+hsIl7x8PbpQRpy3UOaBG2nfCwVMkehSNTgxz5xrlso39BkUs yRbQ== MIME-Version: 1.0 X-Received: by 10.112.13.137 with SMTP id h9mr37849972lbc.33.1406090785824; Tue, 22 Jul 2014 21:46:25 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Tue, 22 Jul 2014 21:46:25 -0700 (PDT) In-Reply-To: <201407221830.s6MIUYrf031075@outgoing.mit.edu> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> Date: Wed, 23 Jul 2014 00:46:25 -0400 Message-ID: From: Nat Sakimura To: Justin Richer Content-Type: multipart/alternative; boundary=001a11c3d10acfa8e104fed505ee Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/v50ynOWaDU_HFf2xKEJUfSQXoNg Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 04:46:30 -0000 --001a11c3d10acfa8e104fed505ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The new grant type that I was talking about was "authorization_code_but_do_not_return_access_nor_refresh_token", so to speak. It does not return anything per se, but an extension can define something on top of it. Then, OIDC can define a binding to it so that the binding only returns ID Token. This binding work should be done in OIDF. Should there be such a grant type, it will be an extremely short spec. At the same time, if any other specification wanted to define other type of tokens and have it returned from the token endpoint, it can also use this grant type. If what you want is to define a new grant type that returns ID Token only, then, I am with Justin. Since "other response than ID Token" is only theoretical, this is a more plausible way forward, I suppose. Nat 2014-07-22 14:30 GMT-04:00 Justin Richer : > So the draft would literally turn into: > > "The a4c response type and grant type return an id_token from the token > endpoint with no access token. All parameters and values are defined in > OIDC." > > Seems like the perfect mini extension draft for OIDF to do. > > --Justin > > /sent from my phone/ > > On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: > > > > What about just defining a new grant type in this WG? > > > > > > 2014-07-22 12:56 GMT-04:00 Phil Hunt : > >> > >> That would be nice. However oidc still needs the new grant type in > order to implement the same flow. > >> > >> Phil > >> > >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: > >> > >>> +1 to Justin. > >>> > >>> > >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : > >>>> > >>>> Errors like these make it clear to me that it would make much more > sense to develop this document in the OpenID Foundation. It should be > something that directly references OpenID Connect Core for all of these > terms instead of redefining them. It's doing authentication, which is > fundamentally what OpenID Connect does on top of OAuth, and I don't see a > good argument for doing this work in this working group. > >>>> > >>>> -- Justin > >>>> > >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer > wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < > Michael.Jones@microsoft.com> wrote: > >>>>>> > >>>>>> Thanks for your review, Thomas. The =E2=80=9Cprompt=3Dconsent=E2= =80=9D definition > being missing is an editorial error. It should be: > >>>>>> > >>>>>> > >>>>>> > >>>>>> consent > >>>>>> > >>>>>> The Authorization Server SHOULD prompt the End-User for consent > before returning information to the Client. If it cannot obtain consent, = it > MUST return an error, typically consent_required. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I=E2=80=99ll plan to add it in the next draft. > >>>>> > >>>>> > >>>>> It looks like the consent_required error needs to be defined too, > and you might have forgotten to also import account_selection_required fr= om > OpenID Connect. > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> I agree that there=E2=80=99s no difference between a response with= multiple > =E2=80=9Camr=E2=80=9D values that includes =E2=80=9Cmfa=E2=80=9D and one = that doesn=E2=80=99t. Unless a clear use > case for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can de= lete it in the > next draft. > >>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>> How about "pwd" then? I fully understand that I should return "pwd" > if the user authenticated using a password, but what "the service if a > client secret is used" means in the definition for the "pwd" value? > >>>>> > >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come > back ;-) ) > >>>>> > >>>>> -- > >>>>> Thomas Broyer > >>>>> /t=C9=94.ma.b=CA=81wa.je/ > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> > >>> > >>> > >>> -- > >>> Nat Sakimura (=3Dnat) > >>> Chairman, OpenID Foundation > >>> http://nat.sakimura.org/ > >>> @_nat_en > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c3d10acfa8e104fed505ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The new grant type that I was talking about was=C2=A0
= "authorization_code_but_do_not_return_access_nor_refresh_token", = so to speak.=C2=A0
It does not return anything per se, but an exte= nsion can define something on top of it.=C2=A0

Then, OIDC can define a binding to it so that the bindi= ng only returns ID Token.=C2=A0
This binding work should be done = in OIDF. Should there be such a grant type,=C2=A0
it = will be an extremely short spec.=C2=A0

At the same time, if any other specification wanted to = define=C2=A0
other type of tokens and have it returned from the t= oken endpoint,=C2=A0
it can also use this grant type.=C2=A0
=

If what you want is to define a new grant type that returns ID Token o= nly,=C2=A0
then, I am with Justin. Since "other response tha= n ID Token" is only=C2=A0
theoretical, this is a more plausi= ble way forward, I suppose.=C2=A0

Nat


2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.= edu>:
So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/

On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is = fundamentally what OpenID Connect does on top of OAuth, and I don't see= a good argument for doing this work in this working group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@microsoft.com&g= t; wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The =E2=80= =9Cprompt=3Dconsent=E2=80=9D definition being missing is an editorial error= .=C2=A0 It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I=E2=80=99ll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there=E2=80=99s no difference between= a response with multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80= =9Cmfa=E2=80=9D and one that doesn=E2=80=99t.=C2=A0 Unless a clear use case= for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete i= t in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/<= /a>
@_nat_en
--001a11c3d10acfa8e104fed505ee-- From nobody Wed Jul 23 02:57:22 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8983E1A038B for ; Wed, 23 Jul 2014 02:57:20 -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 jpqQV-2-ehZN for ; Wed, 23 Jul 2014 02:57:19 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDFF1A0394 for ; Wed, 23 Jul 2014 02:57:15 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i7so1289947oag.16 for ; Wed, 23 Jul 2014 02:57:14 -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=20aUKm+hkK4nEtO7VjnSIvGTZWHfxfEVQjRnz4+Qaks=; b=KTQKhAC5IxN/dZXbenSUHnLFKy2xTKVG96We5by8+BPfhI8rkSpGlCLAJ2C79xWZ8l jWfMJHeoQM/ZGWONKz0s2XimLXkGMmk4yIvrmCWf/STSEx1OHy1mqrtAGmfAftOqGZ0m 6+Wcgr49PMFlzwsaDdarkQU+tGNPwt+IfKBL1W+xZ8JnH5lohgFZXRUfxzEOkqz60mqA /8vCKzQDg6xacNOvNljQyNjWkfK95vPgkN8SkE5pOgIx3OxGq5xMGwVy1xab5f37mUDS oCX1pm38LmcIu4ubeI66p0ueXTjUK4ZgYtLzn5V17P3Xd8wLROKsv4mODQCx5bCVEXmv 9mbw== MIME-Version: 1.0 X-Received: by 10.60.132.176 with SMTP id ov16mr120845oeb.13.1406109434762; Wed, 23 Jul 2014 02:57:14 -0700 (PDT) Received: by 10.202.185.197 with HTTP; Wed, 23 Jul 2014 02:57:14 -0700 (PDT) Date: Wed, 23 Jul 2014 11:57:14 +0200 Message-ID: From: Richard Snowden To: oauth@ietf.org Content-Type: multipart/alternative; boundary=047d7b4724925fdbdb04fed95d3d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/dBTEaYBcnkbwqWQRJ-QjK36a1_o Subject: [OAUTH-WG] Please help me understand OAuth 2.0 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, 23 Jul 2014 09:57:20 -0000 --047d7b4724925fdbdb04fed95d3d Content-Type: text/plain; charset=UTF-8 I am pretty familiar with the WS-* and SOAP Web Services world. At the moment I'm trying to understand which features are available in the OAuth 2.0 world. 1) SAML tokens: This access token in OAuth 2.0 - is it similar to what SAML tokens are for? 2) STS: Is an OAuth 2.0 Authorization Server the equivalent to a STS? 3) PDP (Policy Decision Point): Is this also handled by the OAuth 2.0 Authorization Server? Or does the Resource Server, based on the access token, have to make the decision whether or not grant access to a resource? --047d7b4724925fdbdb04fed95d3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am pretty familiar with the WS-* and SOAP= Web Services world. At the moment I'm trying to understand which featu= res are available in the OAuth 2.0 world.

1) SAML tokens:= This access token in OAuth 2.0 - is it similar to what SAML tokens are for= ?

2) STS: Is an OAuth 2.0 Authorization Server the equivalent = to a STS?

3) PDP (Policy Decision Point): Is this also handled= by the OAuth 2.0 Authorization Server? Or does the Resource Server, based = on the access token, have to make the decision whether or not=C2=A0 grant a= ccess to a resource?


--047d7b4724925fdbdb04fed95d3d-- From nobody Wed Jul 23 04:21:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92BF1A038A for ; Wed, 23 Jul 2014 04:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 pAGb0Fe5jhc8 for ; Wed, 23 Jul 2014 04:21:44 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9361A037E for ; Wed, 23 Jul 2014 04:21:44 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6NBLgBq031474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 11:21:42 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6NBLfE9006911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Jul 2014 11:21:41 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6NBLe9T006899; Wed, 23 Jul 2014 11:21:41 GMT Received: from [25.8.23.182] (/24.114.57.135) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Jul 2014 04:21:40 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-431CCC8C-BC51-45BA-97FB-7CEF50709090 Content-Transfer-Encoding: 7bit References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> From: Phil Hunt Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: Date: Wed, 23 Jul 2014 07:21:02 -0400 To: Nat Sakimura X-Mailer: iPhone Mail (11D257) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/vA5DDjZybXvbi0T8EBeM6vyUcr8 Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 11:21:46 -0000 --Apple-Mail-431CCC8C-BC51-45BA-97FB-7CEF50709090 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The draft is very clear.=20 Phil > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >=20 > The new grant type that I was talking about was=20 > "authorization_code_but_do_not_return_access_nor_refresh_token", so to spe= ak.=20 > It does not return anything per se, but an extension can define something o= n top of it.=20 >=20 > Then, OIDC can define a binding to it so that the binding only returns ID T= oken.=20 > This binding work should be done in OIDF. Should there be such a grant typ= e,=20 > it will be an extremely short spec.=20 >=20 > At the same time, if any other specification wanted to define=20 > other type of tokens and have it returned from the token endpoint,=20 > it can also use this grant type.=20 >=20 > If what you want is to define a new grant type that returns ID Token only,= =20 > then, I am with Justin. Since "other response than ID Token" is only=20 > theoretical, this is a more plausible way forward, I suppose.=20 >=20 > Nat >=20 >=20 > 2014-07-22 14:30 GMT-04:00 Justin Richer : >> So the draft would literally turn into: >>=20 >> "The a4c response type and grant type return an id_token from the token e= ndpoint with no access token. All parameters and values are defined in OIDC.= " >>=20 >> Seems like the perfect mini extension draft for OIDF to do. >>=20 >> --Justin >>=20 >> /sent from my phone/ >>=20 >> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >> > >> > What about just defining a new grant type in this WG? >> > >> > >> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >> >> >> >> That would be nice. However oidc still needs the new grant type in ord= er to implement the same flow.=20 >> >> >> >> Phil >> >> >> >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: >> >> >> >>> +1 to Justin.=20 >> >>> >> >>> >> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >> >>>> >> >>>> Errors like these make it clear to me that it would make much more s= ense to develop this document in the OpenID Foundation. It should be somethi= ng that directly references OpenID Connect Core for all of these terms inste= ad of redefining them. It's doing authentication, which is fundamentally wha= t OpenID Connect does on top of OAuth, and I don't see a good argument for d= oing this work in this working group. >> >>>> >> >>>> -- Justin >> >>>> >> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer wrot= e: >> >>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones wrote: >> >>>>>> >> >>>>>> Thanks for your review, Thomas. The =E2=80=9Cprompt=3Dconsent=E2=80= =9D definition being missing is an editorial error. It should be: >> >>>>>> >> >>>>>> =20 >> >>>>>> >> >>>>>> consent >> >>>>>> >> >>>>>> The Authorization Server SHOULD prompt the End-User for consent be= fore returning information to the Client. If it cannot obtain consent, it MU= ST return an error, typically consent_required. >> >>>>>> >> >>>>>> =20 >> >>>>>> >> >>>>>> I=E2=80=99ll plan to add it in the next draft. >> >>>>> >> >>>>> >> >>>>> It looks like the consent_required error needs to be defined too, a= nd you might have forgotten to also import account_selection_required from O= penID Connect. >> >>>>> =20 >> >>>>>> >> >>>>>> =20 >> >>>>>> >> >>>>>> I agree that there=E2=80=99s no difference between a response with= multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80=9Cmfa=E2=80=9D a= nd one that doesn=E2=80=99t. Unless a clear use case for why =E2=80=9Cmfa=E2= =80=9D is needed can be identified, we can delete it in the next draft. >> >>>>> >> >>>>> >> >>>>> Thanks. >> >>>>> >> >>>>> How about "pwd" then? I fully understand that I should return "pwd"= if the user authenticated using a password, but what "the service if a clie= nt secret is used" means in the definition for the "pwd" value? >> >>>>> >> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come ba= ck ;-) ) >> >>>>> >> >>>>> -- >> >>>>> Thomas Broyer >> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >> >>>>> _______________________________________________ >> >>>>> 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 >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Nat Sakimura (=3Dnat) >> >>> Chairman, OpenID Foundation >> >>> http://nat.sakimura.org/ >> >>> @_nat_en >> >>> >> >>> _______________________________________________ >> >>> OAuth mailing list >> >>> OAuth@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > >> > -- >> > Nat Sakimura (=3Dnat) >> > Chairman, OpenID Foundation >> > http://nat.sakimura.org/ >> > @_nat_en >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail-431CCC8C-BC51-45BA-97FB-7CEF50709090 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The draft is very clear. 

= Phil
The new grant type that I was tal= king about was 
"authorization_code_but_do_not_return_access_nor_re= fresh_token", so to speak. 
It does not return anything per se= , but an extension can define something on top of it. 

Then, OIDC can define a binding to it so that the bindin= g only returns ID Token. 
This binding work should be done in= OIDF. Should there be such a grant type, 
it wil= l be an extremely short spec. 

At the same time, if any other specification wanted to d= efine 
other type of tokens and have it returned from the tok= en endpoint, 
it can also use this grant type. 

If what you want is to define a new grant type that returns ID Token on= ly, 
then, I am with Justin. Since "other response than ID To= ken" is only 
theoretical, this is a more plausible way forwa= rd, I suppose. 

Nat


2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu= >:
So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the token endp= oint with no access token. All parameters and values are defined in OIDC."
Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/

On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in o= rder to implement the same flow. 
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin. 
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make mu= ch more sense to develop this document in the OpenID Foundation. It should b= e something that directly references OpenID Connect Core for all of these te= rms instead of redefining them. It's doing authentication, which is fundamen= tally what OpenID Connect does on top of OAuth, and I don't see a good argum= ent for doing this work in this working group.
>>>>
>>>>  -- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.  The =E2=80=9C= prompt=3Dconsent=E2=80=9D definition being missing is an editorial error.&nb= sp; It should be:
>>>>>>
>>>>>>  
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-User= for consent before returning information to the Client. If it cannot obtain= consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I=E2=80=99ll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be de= fined too, and you might have forgotten to also import account_selection_req= uired from OpenID Connect.
>>>>>  
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I agree that there=E2=80=99s no difference between a= response with multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80=9C= mfa=E2=80=9D and one that doesn=E2=80=99t.  Unless a clear use case for= why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete it in t= he next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand that I should r= eturn "pwd" if the user authenticated using a password, but what "the servic= e if a client secret is used" means in the definition for the "pwd" value? >>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til= you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://n= at.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakim= ura.org/
> @_nat_en



<= /div>--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/=
@_nat_en
= --Apple-Mail-431CCC8C-BC51-45BA-97FB-7CEF50709090-- From nobody Wed Jul 23 06:43:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81C11B28FD for ; Wed, 23 Jul 2014 06:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mcy8KFtTuJOa for ; Wed, 23 Jul 2014 06:43:22 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27BD1A0AC9 for ; Wed, 23 Jul 2014 06:43:21 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id e16so938967lan.11 for ; Wed, 23 Jul 2014 06:43:20 -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=vigQlF5G7MpfWXurDQKoVhj5sYHksvrwR7zuTrZyoW4=; b=uI3HwzOMbDPiwvevImzOS3horVoOIYGCLFqDvvXrSAQOgUHzY7QvqPZvbR/SSJT43L BiGd1/+9PxCDN1/p6dIs7tki5ha8rJ2IsUsMVIxUClXYTdlRdR87GgYiLhIQZO3VfGrx dz1N8KdxnNiuelzk/WT/+tutBC/37h0fR+Mwvtyc7noGwOPGXDKD3owA8feya69D7xJu N0IgzqbNfDlqR4eKRHUoq5ZgBoViCfuwYXD5kirUFb0ENR05elMvNx09qVugvijaL8lI kBYVowTwWdIxSxJXTx3eU7WAXUsMfmyAKtoClSFrvWKI0cQ/Nk9KY7Qbdt2z1MjuceX5 uOhA== MIME-Version: 1.0 X-Received: by 10.152.182.230 with SMTP id eh6mr1749076lac.44.1406123000082; Wed, 23 Jul 2014 06:43:20 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Wed, 23 Jul 2014 06:43:19 -0700 (PDT) In-Reply-To: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> Date: Wed, 23 Jul 2014 09:43:19 -0400 Message-ID: From: Nat Sakimura To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11344428ee3a7804fedc8520 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/XF4X9RhE3Og44v7gF49SdgHu9vo Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 13:43:27 -0000 --001a11344428ee3a7804fedc8520 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Reading back the RFC6749, I am not sure if there is a good way of suppressing access token from the response and still be OAuth. It will break whole bunch of implicit definitions like: authorization server The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. After all, OAuth is all about issuing access tokens. Also, I take back my statement on the grant type in my previous mail. The definition of grant and grant_type are respectively: grant credential representing the resource owner's authorization grant_type (string representing the) type of grant sent to the token endpoint to obtain the access token Thus, the grant sent to the token endpoint in this case is still 'code'. Response type on the other hand is not so well defined in RFC6749, but it seems it is representing what is to be returned from the authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the token endpoint, which is a parallel to the response_type to the Authorization Endpoint seems to be a more symmetric way, though I am not sure at all if that is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the token endpoint such as: response_type OPTIONAL. A string representing what is to be returned from the token endpoint. Then define the behavior of the endpoint according to the values as the parallel to the multi-response type spec. http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html Nat 2014-07-23 7:21 GMT-04:00 Phil Hunt : > The draft is very clear. > > Phil > > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: > > The new grant type that I was talking about was > "authorization_code_but_do_not_return_access_nor_refresh_token", so to > speak. > It does not return anything per se, but an extension can define something > on top of it. > > Then, OIDC can define a binding to it so that the binding only returns ID > Token. > This binding work should be done in OIDF. Should there be such a grant > type, > it will be an extremely short spec. > > At the same time, if any other specification wanted to define > other type of tokens and have it returned from the token endpoint, > it can also use this grant type. > > If what you want is to define a new grant type that returns ID Token only= , > then, I am with Justin. Since "other response than ID Token" is only > theoretical, this is a more plausible way forward, I suppose. > > Nat > > > 2014-07-22 14:30 GMT-04:00 Justin Richer : > >> So the draft would literally turn into: >> >> "The a4c response type and grant type return an id_token from the token >> endpoint with no access token. All parameters and values are defined in >> OIDC." >> >> Seems like the perfect mini extension draft for OIDF to do. >> >> --Justin >> >> /sent from my phone/ >> >> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >> > >> > What about just defining a new grant type in this WG? >> > >> > >> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >> >> >> >> That would be nice. However oidc still needs the new grant type in >> order to implement the same flow. >> >> >> >> Phil >> >> >> >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: >> >> >> >>> +1 to Justin. >> >>> >> >>> >> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >> >>>> >> >>>> Errors like these make it clear to me that it would make much more >> sense to develop this document in the OpenID Foundation. It should be >> something that directly references OpenID Connect Core for all of these >> terms instead of redefining them. It's doing authentication, which is >> fundamentally what OpenID Connect does on top of OAuth, and I don't see = a >> good argument for doing this work in this working group. >> >>>> >> >>>> -- Justin >> >>>> >> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer >> wrote: >> >>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < >> Michael.Jones@microsoft.com> wrote: >> >>>>>> >> >>>>>> Thanks for your review, Thomas. The =E2=80=9Cprompt=3Dconsent=E2= =80=9D definition >> being missing is an editorial error. It should be: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> consent >> >>>>>> >> >>>>>> The Authorization Server SHOULD prompt the End-User for consent >> before returning information to the Client. If it cannot obtain consent,= it >> MUST return an error, typically consent_required. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I=E2=80=99ll plan to add it in the next draft. >> >>>>> >> >>>>> >> >>>>> It looks like the consent_required error needs to be defined too, >> and you might have forgotten to also import account_selection_required f= rom >> OpenID Connect. >> >>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I agree that there=E2=80=99s no difference between a response wit= h >> multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80=9Cmfa=E2=80= =9D and one that doesn=E2=80=99t. Unless a >> clear use case for why =E2=80=9Cmfa=E2=80=9D is needed can be identified= , we can delete it >> in the next draft. >> >>>>> >> >>>>> >> >>>>> Thanks. >> >>>>> >> >>>>> How about "pwd" then? I fully understand that I should return "pwd= " >> if the user authenticated using a password, but what "the service if a >> client secret is used" means in the definition for the "pwd" value? >> >>>>> >> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come >> back ;-) ) >> >>>>> >> >>>>> -- >> >>>>> Thomas Broyer >> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >> >>>>> _______________________________________________ >> >>>>> 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 >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Nat Sakimura (=3Dnat) >> >>> Chairman, OpenID Foundation >> >>> http://nat.sakimura.org/ >> >>> @_nat_en >> >>> >> >>> _______________________________________________ >> >>> OAuth mailing list >> >>> OAuth@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > >> > -- >> > Nat Sakimura (=3Dnat) >> > Chairman, OpenID Foundation >> > http://nat.sakimura.org/ >> > @_nat_en >> > > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11344428ee3a7804fedc8520 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Reading back the RFC6749, I am not sure if there is a good= way of suppressing access token from the response and still be OAuth. It w= ill break whole bunch of implicit definitions like:=C2=A0

aut= horization server
=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client after s= uccessfully
=C2=A0 =C2=A0 =C2=A0 authenticating the resource owner and o= btaining authorization.

After all, OAuth is all about is= suing access tokens.=C2=A0

Also, I take back my statement on the grant type in my = previous mail.=C2=A0

The definition of grant and g= rant_type are respectively:=C2=A0

grant=C2=A0=
=C2=A0 =C2=A0 credential representing the resource owner's authorizatio= n
g= rant_type
=C2=A0 (string repres= enting the) type of grant sent to the token endpoint to obtain the a= ccess token

Thus, the grant sent to the token endpoint in thi= s case is still 'code'.=C2=A0

Response typ= e on the other hand is not so well defined in RFC6749, but it seems it is r= epresenting what is to be returned from the authorization endpoint. To expr= ess what is to be returned from token endpoint, perhaps defining a new para= meter to the token endpoint, which is a parallel to the response_type to th= e Authorization Endpoint seems to be a more symmetric way, though I am not = sure at all if that is going to be OAuth any more. One straw-man is to defi= ne a new parameter called response_type to the token endpoint such as:=C2= =A0

response_type
=C2=A0 =C2=A0 OPTIONAL. A strin= g representing what is to be returned from the token endpoint.=C2=A0
<= div>=C2=A0 =C2=A0=C2=A0
Then define the behavior of the endpoint = according to the values as the parallel to the multi-response type spec.=C2= =A0



2= 014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>= :
The draft is very clear.=C2=A0

Phil

On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant typ= e that I was talking about was=C2=A0
"authorization_code_but_do_no= t_return_access_nor_refresh_token", so to speak.=C2=A0
It doe= s not return anything per se, but an extension can define something on top = of it.=C2=A0

Then, OIDC can define a binding to it so that the bindi= ng only returns ID Token.=C2=A0
This binding work should be done = in OIDF. Should there be such a grant type,=C2=A0
it = will be an extremely short spec.=C2=A0

At the same time, if any other specification wanted to = define=C2=A0
other type of tokens and have it returned from the t= oken endpoint,=C2=A0
it can also use this grant type.=C2=A0
=

If what you want is to define a new grant type that returns ID Token o= nly,=C2=A0
then, I am with Justin. Since "other response tha= n ID Token" is only=C2=A0
theoretical, this is a more plausi= ble way forward, I suppose.=C2=A0

Nat


2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.= edu>:
So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/

On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is = fundamentally what OpenID Connect does on top of OAuth, and I don't see= a good argument for doing this work in this working group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wro= te:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The =E2=80= =9Cprompt=3Dconsent=E2=80=9D definition being missing is an editorial error= .=C2=A0 It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I=E2=80=99ll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there=E2=80=99s no difference between= a response with multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80= =9Cmfa=E2=80=9D and one that doesn=E2=80=99t.=C2=A0 Unless a clear use case= for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete i= t in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/<= /a>
@_nat_en



--
Nat Sakimura (=3Dnat)
--001a11344428ee3a7804fedc8520-- From nobody Wed Jul 23 07:08:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5136B1B2863 for ; Wed, 23 Jul 2014 07:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 K5zIAGHSp6nc for ; Wed, 23 Jul 2014 07:08:37 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7CA1B2817 for ; Wed, 23 Jul 2014 07:08:36 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6NE8X7o008173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 14:08:34 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6NE8XLV017228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Jul 2014 14:08:33 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6NE8Wxb017196; Wed, 23 Jul 2014 14:08:32 GMT Received: from dhcp-9391.meeting.ietf.org (/31.133.147.145) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Jul 2014 07:08:32 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_8F3A418A-5EDC-42A2-B709-46414F68F925" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Wed, 23 Jul 2014 10:08:30 -0400 Message-Id: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> To: Nat Sakimura X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8cDJg3NvvYIktmHbqHuIl3l64Oo Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 14:08:39 -0000 --Apple-Mail=_8F3A418A-5EDC-42A2-B709-46414F68F925 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes. This is why it has to be discussed in the IETF. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: > Reading back the RFC6749, I am not sure if there is a good way of = suppressing access token from the response and still be OAuth. It will = break whole bunch of implicit definitions like:=20 >=20 > authorization server > The server issuing access tokens to the client after = successfully > authenticating the resource owner and obtaining authorization. >=20 > After all, OAuth is all about issuing access tokens.=20 >=20 > Also, I take back my statement on the grant type in my previous mail.=20= >=20 > The definition of grant and grant_type are respectively:=20 >=20 > grant=20 > credential representing the resource owner's authorization > =09 > grant_type > (string representing the) type of grant sent to the token endpoint = to obtain the access token >=20 > Thus, the grant sent to the token endpoint in this case is still = 'code'.=20 >=20 > Response type on the other hand is not so well defined in RFC6749, but = it seems it is representing what is to be returned from the = authorization endpoint. To express what is to be returned from token = endpoint, perhaps defining a new parameter to the token endpoint, which = is a parallel to the response_type to the Authorization Endpoint seems = to be a more symmetric way, though I am not sure at all if that is going = to be OAuth any more. One straw-man is to define a new parameter called = response_type to the token endpoint such as:=20 >=20 > response_type > OPTIONAL. A string representing what is to be returned from the = token endpoint.=20 > =20 > Then define the behavior of the endpoint according to the values as = the parallel to the multi-response type spec.=20 > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >=20 > Nat > =20 >=20 >=20 >=20 >=20 > 2014-07-23 7:21 GMT-04:00 Phil Hunt : > The draft is very clear.=20 >=20 > Phil >=20 > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >=20 >> The new grant type that I was talking about was=20 >> "authorization_code_but_do_not_return_access_nor_refresh_token", so = to speak.=20 >> It does not return anything per se, but an extension can define = something on top of it.=20 >>=20 >> Then, OIDC can define a binding to it so that the binding only = returns ID Token.=20 >> This binding work should be done in OIDF. Should there be such a = grant type,=20 >> it will be an extremely short spec.=20 >>=20 >> At the same time, if any other specification wanted to define=20 >> other type of tokens and have it returned from the token endpoint,=20 >> it can also use this grant type.=20 >>=20 >> If what you want is to define a new grant type that returns ID Token = only,=20 >> then, I am with Justin. Since "other response than ID Token" is only=20= >> theoretical, this is a more plausible way forward, I suppose.=20 >>=20 >> Nat >>=20 >>=20 >> 2014-07-22 14:30 GMT-04:00 Justin Richer : >> So the draft would literally turn into: >>=20 >> "The a4c response type and grant type return an id_token from the = token endpoint with no access token. All parameters and values are = defined in OIDC." >>=20 >> Seems like the perfect mini extension draft for OIDF to do. >>=20 >> --Justin >>=20 >> /sent from my phone/ >>=20 >> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >> > >> > What about just defining a new grant type in this WG? >> > >> > >> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >> >> >> >> That would be nice. However oidc still needs the new grant type in = order to implement the same flow.=20 >> >> >> >> Phil >> >> >> >> On Jul 22, 2014, at 11:35, Nat Sakimura = wrote: >> >> >> >>> +1 to Justin.=20 >> >>> >> >>> >> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >> >>>> >> >>>> Errors like these make it clear to me that it would make much = more sense to develop this document in the OpenID Foundation. It should = be something that directly references OpenID Connect Core for all of = these terms instead of redefining them. It's doing authentication, which = is fundamentally what OpenID Connect does on top of OAuth, and I don't = see a good argument for doing this work in this working group. >> >>>> >> >>>> -- Justin >> >>>> >> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer = wrote: >> >>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones = wrote: >> >>>>>> >> >>>>>> Thanks for your review, Thomas. The =E2=80=9Cprompt=3Dconsent=E2= =80=9D definition being missing is an editorial error. It should be: >> >>>>>> >> >>>>>> =20 >> >>>>>> >> >>>>>> consent >> >>>>>> >> >>>>>> The Authorization Server SHOULD prompt the End-User for = consent before returning information to the Client. If it cannot obtain = consent, it MUST return an error, typically consent_required. >> >>>>>> >> >>>>>> =20 >> >>>>>> >> >>>>>> I=E2=80=99ll plan to add it in the next draft. >> >>>>> >> >>>>> >> >>>>> It looks like the consent_required error needs to be defined = too, and you might have forgotten to also import = account_selection_required from OpenID Connect. >> >>>>> =20 >> >>>>>> >> >>>>>> =20 >> >>>>>> >> >>>>>> I agree that there=E2=80=99s no difference between a response = with multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80=9Cmfa=E2=80= =9D and one that doesn=E2=80=99t. Unless a clear use case for why = =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete it in = the next draft. >> >>>>> >> >>>>> >> >>>>> Thanks. >> >>>>> >> >>>>> How about "pwd" then? I fully understand that I should return = "pwd" if the user authenticated using a password, but what "the service = if a client secret is used" means in the definition for the "pwd" value? >> >>>>> >> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you = come back ;-) ) >> >>>>> >> >>>>> -- >> >>>>> Thomas Broyer >> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >> >>>>> _______________________________________________ >> >>>>> 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 >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Nat Sakimura (=3Dnat) >> >>> Chairman, OpenID Foundation >> >>> http://nat.sakimura.org/ >> >>> @_nat_en >> >>> >> >>> _______________________________________________ >> >>> OAuth mailing list >> >>> OAuth@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > >> > -- >> > Nat Sakimura (=3Dnat) >> > Chairman, OpenID Foundation >> > http://nat.sakimura.org/ >> > @_nat_en >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail=_8F3A418A-5EDC-42A2-B709-46414F68F925 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes. = This is why it has to be discussed in the IETF.


On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com> = wrote:

Reading back the RFC6749, I am not sure = if there is a good way of suppressing access token from the response and = still be OAuth. It will break whole bunch of implicit definitions = like: 

authorization server
      The server issuing access tokens to the client = after successfully
      authenticating the resource = owner and obtaining authorization.

After all, OAuth = is all about issuing access tokens. 

Also, I take back my statement on the grant type in = my previous mail. 

The definition of grant = and grant_type are = respectively: 

grant 
    credential representing the resource owner's = authorization
=
grant_type
  (string representing the) type = of grant sent to the token endpoint to obtain the access token

Thus, the grant sent to the token endpoint in = this case is still 'code'. 

Response type = on the other hand is not so well defined in RFC6749, but it seems it is = representing what is to be returned from the authorization endpoint. To = express what is to be returned from token endpoint, perhaps defining a = new parameter to the token endpoint, which is a parallel to the = response_type to the Authorization Endpoint seems to be a more symmetric = way, though I am not sure at all if that is going to be OAuth any more. = One straw-man is to define a new parameter called response_type to the = token endpoint such as: 

response_type
    OPTIONAL. A = string representing what is to be returned from the token = endpoint. 
    
Then define the = behavior of the endpoint according to the values as the parallel to the = multi-response type spec. 


2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
The draft is very clear. 

Phil

On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type = that I was talking about = was 
"authorization_code_but_do_not_return_access_nor_refresh_tok= en", so to speak. 
It does not return anything per se, but = an extension can define something on top of it. 

Then, OIDC can define a binding to it so that the = binding only returns ID Token. 
This binding work should = be done in OIDF. Should there be such a grant = type, 
it will be an extremely short = spec. 

At the same time, if any other specification wanted = to define 
other type of tokens and have it returned from = the token endpoint, 
it can also use this grant = type. 

If what you want is to define a new grant type that returns ID = Token only, 
then, I am with Justin. Since "other = response than ID Token" is only 
theoretical, this is a = more plausible way forward, I suppose. 

Nat


2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:
So the draft would = literally turn into:

"The a4c response type and grant type return an id_token from the token = endpoint with no access token. All parameters and values are defined in = OIDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/

On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type = in order to implement the same flow. 
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin. 
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would = make much more sense to develop this document in the OpenID Foundation. = It should be something that directly references OpenID Connect Core for = all of these terms instead of redefining them. It's doing = authentication, which is fundamentally what OpenID Connect does on top = of OAuth, and I don't see a good argument for doing this work in this = working group.
>>>>
>>>>  -- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.  The = =E2=80=9Cprompt=3Dconsent=E2=80=9D definition being missing is an = editorial error.  It should be:
>>>>>>
>>>>>>  
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the = End-User for consent before returning information to the Client. If it = cannot obtain consent, it MUST return an error, typically = consent_required.
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I=E2=80=99ll plan to add it in the next = draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to = be defined too, and you might have forgotten to also import = account_selection_required from OpenID Connect.
>>>>>  
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I agree that there=E2=80=99s no difference = between a response with multiple =E2=80=9Camr=E2=80=9D values that = includes =E2=80=9Cmfa=E2=80=9D and one that doesn=E2=80=99t.  = Unless a clear use case for why =E2=80=9Cmfa=E2=80=9D is needed can be = identified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand that I = should return "pwd" if the user authenticated using a password, but what = "the service if a client secret is used" means in the definition for the = "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to wait = 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en



--
Nat Sakimura (=3Dnat)
Chairman, = OpenID Foundation
http://nat.sakimura.org/
@_nat_en



--
Nat Sakimura (=3Dnat)
Chairman, = OpenID Foundation
http://nat.sakimura.org/
@_nat_en

= --Apple-Mail=_8F3A418A-5EDC-42A2-B709-46414F68F925-- From nobody Wed Jul 23 07:27:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C25D1B2A04 for ; Wed, 23 Jul 2014 07:27:14 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZjIXEDz9_U5 for ; Wed, 23 Jul 2014 07:27:04 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01BB1A0AD4 for ; Wed, 23 Jul 2014 07:27:03 -0700 (PDT) Received: from DM2PR03CA006.namprd03.prod.outlook.com (10.141.52.154) by DM2PR03MB592.namprd03.prod.outlook.com (10.141.85.28) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 14:27:02 +0000 Received: from BN1BFFO11FD055.protection.gbl (2a01:111:f400:7c10::1:148) by DM2PR03CA006.outlook.office365.com (2a01:111:e400:2414::26) with Microsoft SMTP Server (TLS) id 15.0.990.7 via Frontend Transport; Wed, 23 Jul 2014 14:27:02 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD055.mail.protection.outlook.com (10.58.145.10) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 23 Jul 2014 14:27:01 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0195.002; Wed, 23 Jul 2014 14:26:50 +0000 From: Mike Jones To: Phil Hunt , Nat Sakimura Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpdsD5lLSHJnTREOVCGmqo62AnZutFmeAgABuQQCAACfBgIAABwoAgAAEBVA= Date: Wed, 23 Jul 2014 14:26:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADDD8F2TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(24454002)(377454003)(189002)(51704005)(377424004)(199002)(92726001)(83072002)(16601075003)(95666004)(551544002)(19300405004)(97736001)(79102001)(44976005)(54356999)(21056001)(92566001)(76176999)(50986999)(87936001)(2656002)(99396002)(107046002)(106116001)(106466001)(33656002)(85852003)(104016003)(19625215002)(86612001)(85306003)(86362001)(31966008)(20776003)(64706001)(81542001)(74662001)(83322001)(19617315012)(77982001)(512874002)(93886003)(26826002)(76482001)(69596002)(81342001)(15974865002)(66066001)(71186001)(84326002)(80022001)(6806004)(16236675004)(46102001)(68736004)(19580395003)(19580405001)(77096002)(74502001)(81156004)(4396001)(16297215004)(15975445006)(84676001)(15395725005)(55846006)(15202345003); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR03MB592; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 028166BF91 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/L6Zj75UdVFCYSSlNaSaJ9yKzCM0 Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 14:27:14 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADDD8F2TK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHJlc3BvbnNlX3R5cGUg4oCcbm9uZeKAnSBpcyBhbHJlYWR5IHVzZWQgaW4gcHJhY3RpY2Us IHdoaWNoIHJldHVybnMgbm8gYWNjZXNzIHRva2VuLiAgSXQgd2FzIGFjY2VwdGVkIGJ5IHRoZSBk ZXNpZ25hdGVkIGV4cGVydHMgYW5kIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkEgT0F1dGggQXV0aG9y aXphdGlvbiBFbmRwb2ludCBSZXNwb25zZSBUeXBlcyByZWdpc3RyeSBhdCBodHRwOi8vd3d3Lmlh bmEub3JnL2Fzc2lnbm1lbnRzL29hdXRoLXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54bWwj ZW5kcG9pbnQuICBUaGUgcmVnaXN0ZXJlZCDigJxpZF90b2tlbuKAnSByZXNwb25zZSB0eXBlIGFs c28gcmV0dXJucyBubyBhY2Nlc3MgdG9rZW4uDQoNClNvIEkgdGhpbmsgdGhlIHF1ZXN0aW9uIG9m IHdoZXRoZXIgcmVzcG9uc2UgdHlwZXMgdGhhdCByZXN1bHQgaW4gbm8gYWNjZXNzIHRva2VuIGJl aW5nIHJldHVybmVkIGFyZSBhY2NlcHRhYmxlIHdpdGhpbiBPQXV0aCAyLjAgaXMgYWxyZWFkeSBz ZXR0bGVkLCBhcyBhIHByYWN0aWNhbCBtYXR0ZXIuICBMb3RzIG9mIE9BdXRoIGltcGxlbWVudGF0 aW9ucyBhcmUgYWxyZWFkeSB1c2luZyBzdWNoIHJlc3BvbnNlIHR5cGVzLg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFBoaWwgSHVudA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDc6MDkgQU0NClRv OiBOYXQgU2FraW11cmENCkNjOiA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRI LVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNl ci1hNGMtMDUudHh0DQoNClllcy4gVGhpcyBpcyB3aHkgaXQgaGFzIHRvIGJlIGRpc2N1c3NlZCBp biB0aGUgSUVURi4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQu Y29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQpPbiBKdWwgMjMsIDIwMTQsIGF0IDk6 NDMgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBn bWFpbC5jb20+PiB3cm90ZToNCg0KDQpSZWFkaW5nIGJhY2sgdGhlIFJGQzY3NDksIEkgYW0gbm90 IHN1cmUgaWYgdGhlcmUgaXMgYSBnb29kIHdheSBvZiBzdXBwcmVzc2luZyBhY2Nlc3MgdG9rZW4g ZnJvbSB0aGUgcmVzcG9uc2UgYW5kIHN0aWxsIGJlIE9BdXRoLiBJdCB3aWxsIGJyZWFrIHdob2xl IGJ1bmNoIG9mIGltcGxpY2l0IGRlZmluaXRpb25zIGxpa2U6DQoNCmF1dGhvcml6YXRpb24gc2Vy dmVyDQogICAgICBUaGUgc2VydmVyIGlzc3VpbmcgYWNjZXNzIHRva2VucyB0byB0aGUgY2xpZW50 IGFmdGVyIHN1Y2Nlc3NmdWxseQ0KICAgICAgYXV0aGVudGljYXRpbmcgdGhlIHJlc291cmNlIG93 bmVyIGFuZCBvYnRhaW5pbmcgYXV0aG9yaXphdGlvbi4NCg0KQWZ0ZXIgYWxsLCBPQXV0aCBpcyBh bGwgYWJvdXQgaXNzdWluZyBhY2Nlc3MgdG9rZW5zLg0KDQpBbHNvLCBJIHRha2UgYmFjayBteSBz dGF0ZW1lbnQgb24gdGhlIGdyYW50IHR5cGUgaW4gbXkgcHJldmlvdXMgbWFpbC4NCg0KVGhlIGRl ZmluaXRpb24gb2YgZ3JhbnQgYW5kIGdyYW50X3R5cGUgYXJlIHJlc3BlY3RpdmVseToNCg0KZ3Jh bnQNCiAgICBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBhdXRo b3JpemF0aW9uDQoNCmdyYW50X3R5cGUNCiAgICAoc3RyaW5nIHJlcHJlc2VudGluZyB0aGUpIHR5 cGUgb2YgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgdG8gb2J0YWluIHRoZSBhY2Nl c3MgdG9rZW4NCg0KVGh1cywgdGhlIGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IGlu IHRoaXMgY2FzZSBpcyBzdGlsbCAnY29kZScuDQoNClJlc3BvbnNlIHR5cGUgb24gdGhlIG90aGVy IGhhbmQgaXMgbm90IHNvIHdlbGwgZGVmaW5lZCBpbiBSRkM2NzQ5LCBidXQgaXQgc2VlbXMgaXQg aXMgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUgYXV0aG9yaXph dGlvbiBlbmRwb2ludC4gVG8gZXhwcmVzcyB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdG9r ZW4gZW5kcG9pbnQsIHBlcmhhcHMgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVyIHRvIHRoZSB0b2tl biBlbmRwb2ludCwgd2hpY2ggaXMgYSBwYXJhbGxlbCB0byB0aGUgcmVzcG9uc2VfdHlwZSB0byB0 aGUgQXV0aG9yaXphdGlvbiBFbmRwb2ludCBzZWVtcyB0byBiZSBhIG1vcmUgc3ltbWV0cmljIHdh eSwgdGhvdWdoIEkgYW0gbm90IHN1cmUgYXQgYWxsIGlmIHRoYXQgaXMgZ29pbmcgdG8gYmUgT0F1 dGggYW55IG1vcmUuIE9uZSBzdHJhdy1tYW4gaXMgdG8gZGVmaW5lIGEgbmV3IHBhcmFtZXRlciBj YWxsZWQgcmVzcG9uc2VfdHlwZSB0byB0aGUgdG9rZW4gZW5kcG9pbnQgc3VjaCBhczoNCg0KcmVz cG9uc2VfdHlwZQ0KICAgIE9QVElPTkFMLiBBIHN0cmluZyByZXByZXNlbnRpbmcgd2hhdCBpcyB0 byBiZSByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludC4NCg0KVGhlbiBkZWZpbmUgdGhl IGJlaGF2aW9yIG9mIHRoZSBlbmRwb2ludCBhY2NvcmRpbmcgdG8gdGhlIHZhbHVlcyBhcyB0aGUg cGFyYWxsZWwgdG8gdGhlIG11bHRpLXJlc3BvbnNlIHR5cGUgc3BlYy4NCmh0dHA6Ly9vcGVuaWQu bmV0L3NwZWNzL29hdXRoLXYyLW11bHRpcGxlLXJlc3BvbnNlLXR5cGVzLTFfMC5odG1sDQoNCk5h dA0KDQoNCg0KDQoyMDE0LTA3LTIzIDc6MjEgR01ULTA0OjAwIFBoaWwgSHVudCA8cGhpbC5odW50 QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj46DQpUaGUgZHJhZnQgaXMg dmVyeSBjbGVhci4NCg0KUGhpbA0KDQpPbiBKdWwgMjMsIDIwMTQsIGF0IDA6NDYsIE5hdCBTYWtp bXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90 ZToNClRoZSBuZXcgZ3JhbnQgdHlwZSB0aGF0IEkgd2FzIHRhbGtpbmcgYWJvdXQgd2FzDQoiYXV0 aG9yaXphdGlvbl9jb2RlX2J1dF9kb19ub3RfcmV0dXJuX2FjY2Vzc19ub3JfcmVmcmVzaF90b2tl biIsIHNvIHRvIHNwZWFrLg0KSXQgZG9lcyBub3QgcmV0dXJuIGFueXRoaW5nIHBlciBzZSwgYnV0 IGFuIGV4dGVuc2lvbiBjYW4gZGVmaW5lIHNvbWV0aGluZyBvbiB0b3Agb2YgaXQuDQoNClRoZW4s IE9JREMgY2FuIGRlZmluZSBhIGJpbmRpbmcgdG8gaXQgc28gdGhhdCB0aGUgYmluZGluZyBvbmx5 IHJldHVybnMgSUQgVG9rZW4uDQpUaGlzIGJpbmRpbmcgd29yayBzaG91bGQgYmUgZG9uZSBpbiBP SURGLiBTaG91bGQgdGhlcmUgYmUgc3VjaCBhIGdyYW50IHR5cGUsDQppdCB3aWxsIGJlIGFuIGV4 dHJlbWVseSBzaG9ydCBzcGVjLg0KDQpBdCB0aGUgc2FtZSB0aW1lLCBpZiBhbnkgb3RoZXIgc3Bl Y2lmaWNhdGlvbiB3YW50ZWQgdG8gZGVmaW5lDQpvdGhlciB0eXBlIG9mIHRva2VucyBhbmQgaGF2 ZSBpdCByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCwNCml0IGNhbiBhbHNvIHVzZSB0 aGlzIGdyYW50IHR5cGUuDQoNCklmIHdoYXQgeW91IHdhbnQgaXMgdG8gZGVmaW5lIGEgbmV3IGdy YW50IHR5cGUgdGhhdCByZXR1cm5zIElEIFRva2VuIG9ubHksDQp0aGVuLCBJIGFtIHdpdGggSnVz dGluLiBTaW5jZSAib3RoZXIgcmVzcG9uc2UgdGhhbiBJRCBUb2tlbiIgaXMgb25seQ0KdGhlb3Jl dGljYWwsIHRoaXMgaXMgYSBtb3JlIHBsYXVzaWJsZSB3YXkgZm9yd2FyZCwgSSBzdXBwb3NlLg0K DQpOYXQNCg0KMjAxNC0wNy0yMiAxNDozMCBHTVQtMDQ6MDAgSnVzdGluIFJpY2hlciA8anJpY2hl ckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PjoNClNvIHRoZSBkcmFmdCB3b3VsZCBs aXRlcmFsbHkgdHVybiBpbnRvOg0KDQoiVGhlIGE0YyByZXNwb25zZSB0eXBlIGFuZCBncmFudCB0 eXBlIHJldHVybiBhbiBpZF90b2tlbiBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCB3aXRoIG5vIGFj Y2VzcyB0b2tlbi4gQWxsIHBhcmFtZXRlcnMgYW5kIHZhbHVlcyBhcmUgZGVmaW5lZCBpbiBPSURD LiINCg0KU2VlbXMgbGlrZSB0aGUgcGVyZmVjdCBtaW5pIGV4dGVuc2lvbiBkcmFmdCBmb3IgT0lE RiB0byBkby4NCg0KLS1KdXN0aW4NCg0KL3NlbnQgZnJvbSBteSBwaG9uZS8NCg0KT24gSnVsIDIy LCAyMDE0IDEwOjI5IEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86 c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQo+DQo+IFdoYXQgYWJvdXQganVzdCBkZWZpbmlu ZyBhIG5ldyBncmFudCB0eXBlIGluIHRoaXMgV0c/DQo+DQo+DQo+IDIwMTQtMDctMjIgMTI6NTYg R01ULTA0OjAwIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tPj46DQo+Pg0KPj4gVGhhdCB3b3VsZCBiZSBuaWNlLiBIb3dldmVyIG9pZGMg c3RpbGwgbmVlZHMgdGhlIG5ldyBncmFudCB0eXBlIGluIG9yZGVyIHRvIGltcGxlbWVudCB0aGUg c2FtZSBmbG93Lg0KPj4NCj4+IFBoaWwNCj4+DQo+PiBPbiBKdWwgMjIsIDIwMTQsIGF0IDExOjM1 LCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwu Y29tPj4gd3JvdGU6DQo+Pg0KPj4+ICsxIHRvIEp1c3Rpbi4NCj4+Pg0KPj4+DQo+Pj4gMjAxNC0w Ny0yMiA5OjU0IEdNVC0wNDowMCBSaWNoZXIsIEp1c3RpbiBQLiA8anJpY2hlckBtaXRyZS5vcmc8 bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPj46DQo+Pj4+DQo+Pj4+IEVycm9ycyBsaWtlIHRoZXNl IG1ha2UgaXQgY2xlYXIgdG8gbWUgdGhhdCBpdCB3b3VsZCBtYWtlIG11Y2ggbW9yZSBzZW5zZSB0 byBkZXZlbG9wIHRoaXMgZG9jdW1lbnQgaW4gdGhlIE9wZW5JRCBGb3VuZGF0aW9uLiBJdCBzaG91 bGQgYmUgc29tZXRoaW5nIHRoYXQgZGlyZWN0bHkgcmVmZXJlbmNlcyBPcGVuSUQgQ29ubmVjdCBD b3JlIGZvciBhbGwgb2YgdGhlc2UgdGVybXMgaW5zdGVhZCBvZiByZWRlZmluaW5nIHRoZW0uIEl0 J3MgZG9pbmcgYXV0aGVudGljYXRpb24sIHdoaWNoIGlzIGZ1bmRhbWVudGFsbHkgd2hhdCBPcGVu SUQgQ29ubmVjdCBkb2VzIG9uIHRvcCBvZiBPQXV0aCwgYW5kIEkgZG9uJ3Qgc2VlIGEgZ29vZCBh cmd1bWVudCBmb3IgZG9pbmcgdGhpcyB3b3JrIGluIHRoaXMgd29ya2luZyBncm91cC4NCj4+Pj4N Cj4+Pj4gIC0tIEp1c3Rpbg0KPj4+Pg0KPj4+PiBPbiBKdWwgMjIsIDIwMTQsIGF0IDQ6MzAgQU0s IFRob21hcyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21haWwu Y29tPj4gd3JvdGU6DQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBPbiBNb24sIEp1 bCAyMSwgMjAxNCBhdCAxMTo1MiBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCj4+Pj4+ Pg0KPj4+Pj4+IFRoYW5rcyBmb3IgeW91ciByZXZpZXcsIFRob21hcy4gIFRoZSDigJxwcm9tcHQ9 Y29uc2VudOKAnSBkZWZpbml0aW9uIGJlaW5nIG1pc3NpbmcgaXMgYW4gZWRpdG9yaWFsIGVycm9y LiAgSXQgc2hvdWxkIGJlOg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IGNvbnNlbnQN Cj4+Pj4+Pg0KPj4+Pj4+IFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBTSE9VTEQgcHJvbXB0IHRo ZSBFbmQtVXNlciBmb3IgY29uc2VudCBiZWZvcmUgcmV0dXJuaW5nIGluZm9ybWF0aW9uIHRvIHRo ZSBDbGllbnQuIElmIGl0IGNhbm5vdCBvYnRhaW4gY29uc2VudCwgaXQgTVVTVCByZXR1cm4gYW4g ZXJyb3IsIHR5cGljYWxseSBjb25zZW50X3JlcXVpcmVkLg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+ Pg0KPj4+Pj4+IEnigJlsbCBwbGFuIHRvIGFkZCBpdCBpbiB0aGUgbmV4dCBkcmFmdC4NCj4+Pj4+ DQo+Pj4+Pg0KPj4+Pj4gSXQgbG9va3MgbGlrZSB0aGUgY29uc2VudF9yZXF1aXJlZCBlcnJvciBu ZWVkcyB0byBiZSBkZWZpbmVkIHRvbywgYW5kIHlvdSBtaWdodCBoYXZlIGZvcmdvdHRlbiB0byBh bHNvIGltcG9ydCBhY2NvdW50X3NlbGVjdGlvbl9yZXF1aXJlZCBmcm9tIE9wZW5JRCBDb25uZWN0 Lg0KPj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBJIGFncmVlIHRoYXQgdGhl cmXigJlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJlc3BvbnNlIHdpdGggbXVsdGlwbGUg4oCc YW1y4oCdIHZhbHVlcyB0aGF0IGluY2x1ZGVzIOKAnG1mYeKAnSBhbmQgb25lIHRoYXQgZG9lc27i gJl0LiAgVW5sZXNzIGEgY2xlYXIgdXNlIGNhc2UgZm9yIHdoeSDigJxtZmHigJ0gaXMgbmVlZGVk IGNhbiBiZSBpZGVudGlmaWVkLCB3ZSBjYW4gZGVsZXRlIGl0IGluIHRoZSBuZXh0IGRyYWZ0Lg0K Pj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MuDQo+Pj4+Pg0KPj4+Pj4gSG93IGFib3V0ICJwd2Qi IHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IEkgc2hvdWxkIHJldHVybiAicHdkIiBpZiB0 aGUgdXNlciBhdXRoZW50aWNhdGVkIHVzaW5nIGEgcGFzc3dvcmQsIGJ1dCB3aGF0ICJ0aGUgc2Vy dmljZSBpZiBhIGNsaWVudCBzZWNyZXQgaXMgdXNlZCIgbWVhbnMgaW4gdGhlIGRlZmluaXRpb24g Zm9yIHRoZSAicHdkIiB2YWx1ZT8NCj4+Pj4+DQo+Pj4+PiAoTm90YTogSSBrbm93IHlvdSdyZSBh dCBJRVRGLTkwLCBJJ20gcmVhZHkgdG8gd2FpdCAndGlsIHlvdSBjb21lIGJhY2sgOy0pICkNCj4+ Pj4+DQo+Pj4+PiAtLQ0KPj4+Pj4gVGhvbWFzIEJyb3llcg0KPj4+Pj4gL3TJlC5tYS5iyoF3YS5q ZS88aHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvPg0KPj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IE9BdXRoIG1haWxpbmcg bGlzdA0KPj4+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+Pg0KPj4+Pg0K Pj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQo+Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0NCj4+PiBOYXQgU2FraW11cmEgKD1u YXQpDQo+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQo+Pj4gaHR0cDovL25hdC5zYWtp bXVyYS5vcmcvDQo+Pj4gQF9uYXRfZW4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4gT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4NCj4NCj4NCj4gLS0NCj4gTmF0IFNha2lt dXJhICg9bmF0KQ0KPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCj4gaHR0cDovL25hdC5z YWtpbXVyYS5vcmcvDQo+IEBfbmF0X2VuDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0K Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBf bmF0X2VuDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBG b3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCg== --_000_4E1F6AAD24975D4BA5B16804296739439ADDD8F2TK5EX14MBXC294r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxl LXNwYW47fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSByZXNwb25zZV90eXBl IOKAnG5vbmXigJ0gaXMgYWxyZWFkeSB1c2VkIGluIHByYWN0aWNlLCB3aGljaCByZXR1cm5zIG5v IGFjY2VzcyB0b2tlbi4mbmJzcDsgSXQgd2FzIGFjY2VwdGVkIGJ5IHRoZSBkZXNpZ25hdGVkIGV4 cGVydHMgYW5kIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkEgT0F1dGgNCiBBdXRob3JpemF0aW9uIEVu ZHBvaW50IFJlc3BvbnNlIFR5cGVzIHJlZ2lzdHJ5IGF0IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWFu YS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhtbCNl bmRwb2ludCI+DQpodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29hdXRoLXBhcmFtZXRl cnMvb2F1dGgtcGFyYW1ldGVycy54bWwjZW5kcG9pbnQ8L2E+LiZuYnNwOyBUaGUgcmVnaXN0ZXJl ZCDigJxpZF90b2tlbuKAnSByZXNwb25zZSB0eXBlIGFsc28gcmV0dXJucyBubyBhY2Nlc3MgdG9r ZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5TbyBJIHRoaW5rIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHJlc3BvbnNl IHR5cGVzIHRoYXQgcmVzdWx0IGluIG5vIGFjY2VzcyB0b2tlbiBiZWluZyByZXR1cm5lZCBhcmUg YWNjZXB0YWJsZSB3aXRoaW4gT0F1dGggMi4wIGlzIGFscmVhZHkgc2V0dGxlZCwgYXMgYSBwcmFj dGljYWwNCiBtYXR0ZXIuJm5ic3A7IExvdHMgb2YgT0F1dGggaW1wbGVtZW50YXRpb25zIGFyZSBh bHJlYWR5IHVzaW5nIHN1Y2ggcmVzcG9uc2UgdHlwZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGhpbCBIdW50PGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgSnVseSAyMywgMjAxNCA3OjA5IEFNPGJyPg0KPGI+VG86PC9iPiBOYXQgU2Fr aW11cmE8YnI+DQo8Yj5DYzo8L2I+ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcy4gVGhpcyBpcyB3aHkgaXQgaGFzIHRvIGJlIGRpc2N1 c3NlZCBpbiB0aGUgSUVURi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5QaGlsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3Lmlu ZGVwZW5kZW50aWQuY29tIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGls Lmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKdWwgMjMsIDIwMTQsIGF0 IDk6NDMgQU0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWls LmNvbSI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlYWRpbmcgYmFjayB0aGUgUkZDNjc0OSwgSSBh bSBub3Qgc3VyZSBpZiB0aGVyZSBpcyBhIGdvb2Qgd2F5IG9mIHN1cHByZXNzaW5nIGFjY2VzcyB0 b2tlbiBmcm9tIHRoZSByZXNwb25zZSBhbmQgc3RpbGwgYmUgT0F1dGguIEl0IHdpbGwgYnJlYWsg d2hvbGUgYnVuY2ggb2YgaW1wbGljaXQgZGVmaW5pdGlvbnMgbGlrZTombmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXV0aG9yaXphdGlvbiBzZXJ2ZXI8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgc2VydmVyIGlzc3VpbmcgYWNjZXNzIHRva2VucyB0byB0 aGUgY2xpZW50IGFmdGVyIHN1Y2Nlc3NmdWxseTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGF1 dGhlbnRpY2F0aW5nIHRoZSByZXNvdXJjZSBvd25lciBhbmQgb2J0YWluaW5nIGF1dGhvcml6YXRp b24uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZnRlciBh bGwsIE9BdXRoIGlzIGFsbCBhYm91dCBpc3N1aW5nIGFjY2VzcyB0b2tlbnMuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIEkg dGFrZSBiYWNrIG15IHN0YXRlbWVudCBvbiB0aGUgZ3JhbnQgdHlwZSBpbiBteSBwcmV2aW91cyBt YWlsLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgZGVmaW5pdGlvbiBvZiBncmFudCBhbmQgZ3JhbnRfdHlwZSBhcmUgcmVzcGVj dGl2ZWx5OiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Z3JhbnQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgY3JlZGVudGlhbCByZXByZXNl bnRpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Z3JhbnRfdHlwZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IChzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSkgdHlwZSBvZiBncmFudCBzZW50IHRv IHRoZSB0b2tlbiBlbmRwb2ludCB0byBvYnRhaW4gdGhlIGFjY2VzcyB0b2tlbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRodXMs IHRoZSBncmFudCBzZW50IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBpbiB0aGlzIGNhc2UgaXMgc3Rp bGwgJ2NvZGUnLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SZXNwb25zZSB0eXBlIG9uIHRoZSBvdGhlciBoYW5kIGlzIG5vdCBzbyB3 ZWxsIGRlZmluZWQgaW4gUkZDNjc0OSwgYnV0IGl0IHNlZW1zIGl0IGlzIHJlcHJlc2VudGluZyB3 aGF0IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRv IGV4cHJlc3Mgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50LCBwZXJo YXBzIGRlZmluaW5nIGEgbmV3IHBhcmFtZXRlcg0KIHRvIHRoZSB0b2tlbiBlbmRwb2ludCwgd2hp Y2ggaXMgYSBwYXJhbGxlbCB0byB0aGUgcmVzcG9uc2VfdHlwZSB0byB0aGUgQXV0aG9yaXphdGlv biBFbmRwb2ludCBzZWVtcyB0byBiZSBhIG1vcmUgc3ltbWV0cmljIHdheSwgdGhvdWdoIEkgYW0g bm90IHN1cmUgYXQgYWxsIGlmIHRoYXQgaXMgZ29pbmcgdG8gYmUgT0F1dGggYW55IG1vcmUuIE9u ZSBzdHJhdy1tYW4gaXMgdG8gZGVmaW5lIGEgbmV3IHBhcmFtZXRlciBjYWxsZWQgcmVzcG9uc2Vf dHlwZQ0KIHRvIHRoZSB0b2tlbiBlbmRwb2ludCBzdWNoIGFzOiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZXNwb25zZV90eXBlPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7IE9QVElPTkFMLiBBIHN0cmluZyByZXByZXNlbnRpbmcgd2hhdCBpcyB0byBiZSByZXR1 cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZW4gZGVmaW5l IHRoZSBiZWhhdmlvciBvZiB0aGUgZW5kcG9pbnQgYWNjb3JkaW5nIHRvIHRoZSB2YWx1ZXMgYXMg dGhlIHBhcmFsbGVsIHRvIHRoZSBtdWx0aS1yZXNwb25zZSB0eXBlIHNwZWMuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJo dHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC12Mi1tdWx0aXBsZS1yZXNwb25zZS10eXBlcy0x XzAuaHRtbCI+aHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb2F1dGgtdjItbXVsdGlwbGUtcmVzcG9u c2UtdHlwZXMtMV8wLmh0bWw8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4yMDE0LTA3LTIzIDc6MjEgR01ULTA0OjAwIFBoaWwgSHVudCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50 QG9yYWNsZS5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIGRyYWZ0IGlzIHZlcnkgY2xlYXIuJm5ic3A7PHNwYW4gc3R5bGU9 ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPlBoaWw8L3Nw YW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9u IEp1bCAyMywgMjAxNCwgYXQgMDo0NiwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86 c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBuZXcgZ3JhbnQgdHlwZSB0aGF0IEkgd2FzIHRhbGtpbmcgYWJvdXQgd2Fz Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7 YXV0aG9yaXphdGlvbl9jb2RlX2J1dF9kb19ub3RfcmV0dXJuX2FjY2Vzc19ub3JfcmVmcmVzaF90 b2tlbiZxdW90Oywgc28gdG8gc3BlYWsuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGRvZXMgbm90IHJldHVybiBhbnl0aGluZyBwZXIg c2UsIGJ1dCBhbiBleHRlbnNpb24gY2FuIGRlZmluZSBzb21ldGhpbmcgb24gdG9wIG9mIGl0LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGVuLCBPSURDIGNhbiBkZWZpbmUgYSBiaW5kaW5nIHRvIGl0IHNvIHRoYXQgdGhlIGJpbmRp bmcgb25seSByZXR1cm5zIElEIFRva2VuLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBiaW5kaW5nIHdvcmsgc2hvdWxkIGJlIGRv bmUgaW4gT0lERi4gU2hvdWxkIHRoZXJlIGJlIHN1Y2ggYSBncmFudCB0eXBlLCZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPml0IHdpbGwgYmUgYW4gZXh0cmVtZWx5IHNob3J0IHNwZWMuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IHRoZSBzYW1l IHRpbWUsIGlmIGFueSBvdGhlciBzcGVjaWZpY2F0aW9uIHdhbnRlZCB0byBkZWZpbmUmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm90aGVy IHR5cGUgb2YgdG9rZW5zIGFuZCBoYXZlIGl0IHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBv aW50LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+aXQgY2FuIGFsc28gdXNlIHRoaXMgZ3JhbnQgdHlwZS4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2hhdCB5b3Ugd2Fu dCBpcyB0byBkZWZpbmUgYSBuZXcgZ3JhbnQgdHlwZSB0aGF0IHJldHVybnMgSUQgVG9rZW4gb25s eSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPnRoZW4sIEkgYW0gd2l0aCBKdXN0aW4uIFNpbmNlICZxdW90O290aGVyIHJlc3BvbnNlIHRo YW4gSUQgVG9rZW4mcXVvdDsgaXMgb25seSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlb3JldGljYWwsIHRoaXMgaXMgYSBtb3JlIHBs YXVzaWJsZSB3YXkgZm9yd2FyZCwgSSBzdXBwb3NlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4yMDE0LTA3LTIyIDE0OjMwIEdNVC0wNDowMCBKdXN0aW4gUmljaGVyICZsdDs8YSBo cmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQu ZWR1PC9hPiZndDs6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB0aGUg ZHJhZnQgd291bGQgbGl0ZXJhbGx5IHR1cm4gaW50bzo8YnI+DQo8YnI+DQomcXVvdDtUaGUgYTRj IHJlc3BvbnNlIHR5cGUgYW5kIGdyYW50IHR5cGUgcmV0dXJuIGFuIGlkX3Rva2VuIGZyb20gdGhl IHRva2VuIGVuZHBvaW50IHdpdGggbm8gYWNjZXNzIHRva2VuLiBBbGwgcGFyYW1ldGVycyBhbmQg dmFsdWVzIGFyZSBkZWZpbmVkIGluIE9JREMuJnF1b3Q7PGJyPg0KPGJyPg0KU2VlbXMgbGlrZSB0 aGUgcGVyZmVjdCBtaW5pIGV4dGVuc2lvbiBkcmFmdCBmb3IgT0lERiB0byBkby48YnI+DQo8YnI+ DQotLUp1c3Rpbjxicj4NCjxicj4NCi9zZW50IGZyb20gbXkgcGhvbmUvPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT24gSnVsIDIyLCAyMDE0IDEwOjI5 IEFNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7PGJyPg0KJmd0OyBXaGF0IGFib3V0IGp1c3QgZGVmaW5pbmcgYSBuZXcgZ3JhbnQgdHlwZSBp biB0aGlzIFdHPzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAyMDE0LTA3LTIyIDEyOjU2 IEdNVC0wNDowMCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs6PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGF0IHdvdWxkIGJlIG5pY2UuIEhvd2V2ZXIgb2lkYyBz dGlsbCBuZWVkcyB0aGUgbmV3IGdyYW50IHR5cGUgaW4gb3JkZXIgdG8gaW1wbGVtZW50IHRoZSBz YW1lIGZsb3cuJm5ic3A7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBQaGlsPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiBKdWwgMjIsIDIwMTQsIGF0IDExOjM1LCBOYXQgU2FraW11 cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyAmIzQzOzEgdG8gSnVzdGluLiZuYnNwOzxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAyMDE0LTA3LTIyIDk6NTQgR01ULTA0OjAw IFJpY2hlciwgSnVzdGluIFAuICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmci IHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEVycm9ycyBsaWtlIHRoZXNlIG1ha2UgaXQg Y2xlYXIgdG8gbWUgdGhhdCBpdCB3b3VsZCBtYWtlIG11Y2ggbW9yZSBzZW5zZSB0byBkZXZlbG9w IHRoaXMgZG9jdW1lbnQgaW4gdGhlIE9wZW5JRCBGb3VuZGF0aW9uLiBJdCBzaG91bGQgYmUgc29t ZXRoaW5nIHRoYXQgZGlyZWN0bHkgcmVmZXJlbmNlcyBPcGVuSUQgQ29ubmVjdCBDb3JlIGZvciBh bGwgb2YgdGhlc2UgdGVybXMgaW5zdGVhZCBvZiByZWRlZmluaW5nIHRoZW0uIEl0J3MgZG9pbmcN CiBhdXRoZW50aWNhdGlvbiwgd2hpY2ggaXMgZnVuZGFtZW50YWxseSB3aGF0IE9wZW5JRCBDb25u ZWN0IGRvZXMgb24gdG9wIG9mIE9BdXRoLCBhbmQgSSBkb24ndCBzZWUgYSBnb29kIGFyZ3VtZW50 IGZvciBkb2luZyB0aGlzIHdvcmsgaW4gdGhpcyB3b3JraW5nIGdyb3VwLjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOy0tIEp1c3Rpbjxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE9uIEp1bCAyMiwgMjAxNCwgYXQgNDoz MCBBTSwgVGhvbWFzIEJyb3llciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnQuYnJveWVyQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnQuYnJveWVyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N CiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBPbiBNb24sIEp1bCAyMSwgMjAxNCBhdCAxMTo1MiBQTSwgTWlrZSBKb25lcyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFua3Mg Zm9yIHlvdXIgcmV2aWV3LCBUaG9tYXMuJm5ic3A7IFRoZSDigJxwcm9tcHQ9Y29uc2VudOKAnSBk ZWZpbml0aW9uIGJlaW5nIG1pc3NpbmcgaXMgYW4gZWRpdG9yaWFsIGVycm9yLiZuYnNwOyBJdCBz aG91bGQgYmU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7ICZuYnNwOzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb25zZW50PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBBdXRob3JpemF0aW9uIFNlcnZl ciBTSE9VTEQgcHJvbXB0IHRoZSBFbmQtVXNlciBmb3IgY29uc2VudCBiZWZvcmUgcmV0dXJuaW5n IGluZm9ybWF0aW9uIHRvIHRoZSBDbGllbnQuIElmIGl0IGNhbm5vdCBvYnRhaW4gY29uc2VudCwg aXQgTVVTVCByZXR1cm4gYW4gZXJyb3IsIHR5cGljYWxseSBjb25zZW50X3JlcXVpcmVkLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAm bmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgSeKAmWxsIHBsYW4gdG8gYWRkIGl0IGluIHRoZSBuZXh0IGRyYWZ0Ljxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBJdCBsb29rcyBsaWtlIHRoZSBjb25zZW50X3JlcXVpcmVkIGVycm9yIG5l ZWRzIHRvIGJlIGRlZmluZWQgdG9vLCBhbmQgeW91IG1pZ2h0IGhhdmUgZm9yZ290dGVuIHRvIGFs c28gaW1wb3J0IGFjY291bnRfc2VsZWN0aW9uX3JlcXVpcmVkIGZyb20gT3BlbklEIENvbm5lY3Qu PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOzxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGFncmVlIHRo YXQgdGhlcmXigJlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJlc3BvbnNlIHdpdGggbXVsdGlw bGUg4oCcYW1y4oCdIHZhbHVlcyB0aGF0IGluY2x1ZGVzIOKAnG1mYeKAnSBhbmQgb25lIHRoYXQg ZG9lc27igJl0LiZuYnNwOyBVbmxlc3MgYSBjbGVhciB1c2UgY2FzZSBmb3Igd2h5IOKAnG1mYeKA nSBpcyBuZWVkZWQgY2FuIGJlIGlkZW50aWZpZWQsIHdlIGNhbiBkZWxldGUgaXQgaW4gdGhlIG5l eHQgZHJhZnQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcy48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhvdyBhYm91dCAmcXVvdDtwd2QmcXVv dDsgdGhlbj8gSSBmdWxseSB1bmRlcnN0YW5kIHRoYXQgSSBzaG91bGQgcmV0dXJuICZxdW90O3B3 ZCZxdW90OyBpZiB0aGUgdXNlciBhdXRoZW50aWNhdGVkIHVzaW5nIGEgcGFzc3dvcmQsIGJ1dCB3 aGF0ICZxdW90O3RoZSBzZXJ2aWNlIGlmIGEgY2xpZW50IHNlY3JldCBpcyB1c2VkJnF1b3Q7IG1l YW5zIGluIHRoZSBkZWZpbml0aW9uIGZvciB0aGUgJnF1b3Q7cHdkJnF1b3Q7IHZhbHVlPzxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgKE5vdGE6IEkg a25vdyB5b3UncmUgYXQgSUVURi05MCwgSSdtIHJlYWR5IHRvIHdhaXQgJ3RpbCB5b3UgY29tZSBi YWNrIDstKSApPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAtLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRob21hcyBCcm95ZXI8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAvdDxhIGhyZWY9Imh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhi LmplLyIgdGFyZ2V0PSJfYmxhbmsiPsmULm1hLmLKgXdhLmplLzwvYT48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcg bGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IC0tPGJyPg0KJmd0OyZn dDsmZ3Q7IE5hdCBTYWtpbXVyYSAoPW5hdCk8YnI+DQomZ3Q7Jmd0OyZndDsgQ2hhaXJtYW4sIE9w ZW5JRCBGb3VuZGF0aW9uPGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9uYXQuc2Fr aW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48 YnI+DQomZ3Q7Jmd0OyZndDsgQF9uYXRfZW48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhy ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3Jn PC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4NCiZndDsgTmF0IFNha2ltdXJhICg9bmF0KTxicj4N CiZndDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KJmd0OyA8YSBocmVmPSJodHRw Oi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJh Lm9yZy88L2E+PGJyPg0KJmd0OyBAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+DQpOYXQgU2FraW11cmEgKD1u YXQpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4s IE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcv IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0 X2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIg Y2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0g PGJyPg0KTmF0IFNha2ltdXJhICg9bmF0KTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0 dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11 cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739439ADDD8F2TK5EX14MBXC294r_-- From nobody Wed Jul 23 07:37:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC461B2A38 for ; Wed, 23 Jul 2014 07:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTopbnbzssMn for ; Wed, 23 Jul 2014 07:37:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29CC1B2A58 for ; Wed, 23 Jul 2014 07:36:38 -0700 (PDT) Received: from BY2PR03CA036.namprd03.prod.outlook.com (10.242.234.157) by DM2PR03MB592.namprd03.prod.outlook.com (10.141.85.28) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 14:36:36 +0000 Received: from BL2FFO11FD028.protection.gbl (2a01:111:f400:7c09::155) by BY2PR03CA036.outlook.office365.com (2a01:111:e400:2c2c::29) with Microsoft SMTP Server (TLS) id 15.0.990.7 via Frontend Transport; Wed, 23 Jul 2014 14:36:35 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD028.mail.protection.outlook.com (10.173.161.107) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 23 Jul 2014 14:36:34 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0195.002; Wed, 23 Jul 2014 14:35:53 +0000 From: Mike Jones To: Justin Richer , "torsten@lodderstedt.net" Thread-Topic: [OAUTH-WG] Dynamic Client Registration: application_type Thread-Index: AQHPphOknQrYoKDhtEOe+Pyl9jU/+putue/Q Date: Wed, 23 Jul 2014 14:35:52 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADDD97C@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <201407230115.s6N1FsJe030731@outgoing.mit.edu> In-Reply-To: <201407230115.s6N1FsJe030731@outgoing.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADDD97CTK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(55885003)(53754006)(51704005)(189002)(199002)(377424004)(377454003)(479174003)(24454002)(13464003)(43544003)(83322001)(74662001)(77982001)(19617315012)(20776003)(64706001)(81542001)(69596002)(76482001)(26826002)(512874002)(19625215002)(31966008)(85306003)(86362001)(86612001)(19580395003)(74502001)(19580405001)(77096002)(68736004)(46102001)(81156004)(84676001)(15202345003)(55846006)(15975445006)(4396001)(71186001)(15974865002)(81342001)(66066001)(16236675004)(84326002)(80022001)(6806004)(79102001)(44976005)(97736001)(19300405004)(21056001)(50986999)(76176999)(92566001)(54356999)(83072002)(92726001)(95666004)(16601075003)(106116001)(106466001)(33656002)(85852003)(104016003)(87936001)(107046002)(99396002)(2656002)(2171001)(559001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR03MB592; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 028166BF91 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/glSzICoMd89SErgoOMIPlHI6XzE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 23 Jul 2014 14:37:18 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADDD97CTK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQncyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gdGhhdCwgYXMgbmF0aXZlIGFwcHMgbWF5IHVzZSB0 aGUgaW1wbGljaXQgZmxvdyBhbmQgbm90IHVzZSBodHRwcy4gIFRoZSBzZXQgb2YgY29uc3RyYWlu dHMgaW4gdGhlICJhcHBsaWNhdGlvbl90eXBlIiBkZWZpbml0aW9uIGluIE9wZW5JRCBDb25uZWN0 IER5bmFtaWMgUmVnaXN0cmF0aW9uIGFyZToNCg0KDQoNCldlYiBDbGllbnRzIHVzaW5nIHRoZSBP QXV0aCBJbXBsaWNpdCBHcmFudCBUeXBlIE1VU1Qgb25seSByZWdpc3RlciBVUkxzIHVzaW5nIHRo ZSBodHRwcyBzY2hlbWUgYXMgcmVkaXJlY3RfdXJpczsgdGhleSBNVVNUIE5PVCB1c2UgbG9jYWxo b3N0IGFzIHRoZSBob3N0bmFtZS4gTmF0aXZlIENsaWVudHMgTVVTVCBvbmx5IHJlZ2lzdGVyIHJl ZGlyZWN0X3VyaXMgdXNpbmcgY3VzdG9tIFVSSSBzY2hlbWVzIG9yIFVSTHMgdXNpbmcgdGhlIGh0 dHA6IHNjaGVtZSB3aXRoIGxvY2FsaG9zdCBhcyB0aGUgaG9zdG5hbWUuIEF1dGhvcml6YXRpb24g U2VydmVycyBNQVkgcGxhY2UgYWRkaXRpb25hbCBjb25zdHJhaW50cyBvbiBOYXRpdmUgQ2xpZW50 cy4gQXV0aG9yaXphdGlvbiBTZXJ2ZXJzIE1BWSByZWplY3QgUmVkaXJlY3Rpb24gVVJJIHZhbHVl cyB1c2luZyB0aGUgaHR0cCBzY2hlbWUsIG90aGVyIHRoYW4gdGhlIGxvY2FsaG9zdCBjYXNlIGZv ciBOYXRpdmUgQ2xpZW50cy4NCg0KDQoNCklmIHdl4oCZcmUgZ29pbmcgdG8gYWRkIHN1Y2ggY29u c3RyYWludHMsIEkgYmVsaWV2ZSB0aGV5IHNob3VsZCBiZSB0aGUgc2FtZSBvbmVzIGFzIHRoZSBv bmVzIGFib3ZlLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEp1c3RpbiBSaWNoZXINClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQgNjoxNiBQ TQ0KVG86IHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0DQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbjogYXBwbGljYXRp b25fdHlwZQ0KDQoNCg0KSSdtIG9rIHdpdGggdGhhdCB0ZXh0LCBhbmQgYWN0dWFsbHkgdGhvdWdo dCB3ZSBoYWQgc29tZXRoaW5nIGFsb25nIHRob3NlIGxpbmVzIGFscmVhZHkuDQoNCg0KDQotLUp1 c3Rpbg0KDQoNCg0KL3NlbnQgZnJvbSBteSBwaG9uZS8NCg0KDQoNCk9uIEp1bCAyMiwgMjAxNCAz OjI3IFBNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQ+IHdyb3RlOg0KDQo+DQoNCj4gSGkgYWxsLA0KDQo+DQoNCj4gSSBkb24ndCB0aGluayB0 aGlzIHBhcmFtZXRlciBhZGRzIGFueSBzZWN1cml0eSAoYXMgaXQgaXMgc2VsZiBkZWNsYXJkZWQg YnkgdGhlIGNhbGxlcikuIEkgdGhpbmsgdGhlIGNvbnN0cmFpbnRzIG9uIHJlZGlyZWN0X3VyaXMg Y2FuIGJlIHNwZWNpZmllZCB3aXRob3V0IHRoZSBuZWVkIGZvciBhbm90aGVyIHJlZ2lzdHJhdGlv biBwYXJhbWV0ZXIuIEFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHRoZXkgbWVyZWx5IGRlcGVuZCBv biB0aGUgZ3JhbnQgdHlwZS4gU28gd2UgY291bGQgc29tZSB0ZXh0IHRvIHRoZSByZWRpcmVjdF91 cmkgcGFyYW1ldGVyIGRlZmluaXRpb24uIFNvbWV0aGluZyBhbG9uZyB0aGUgZm9sbG93aW5nIGxp bmVzOg0KDQo+DQoNCj4gIkFsbCByZWRpcmVjdCBVUklzIHJlZ2lzdGVyZWQgZm9yIGEgcGFydGlj dWxhciBjbGllbnQgTVVTVCBlaXRoZXIgKDEpIHVzZSB0aGUgSFRUUFMgc2NoZW1lIG9yICgyKSB0 aGUgSFRUUCBzY2hlbWUgd2l0aCBsb2NhbGhvc3QgYXMgdGhlIGhvc3RuYW1lIG9yIGN1c3RvbSBz Y2hlbWVzLiBBZGRpdGlvbmFsbHksIGNsaWVudHMgdXNpbmcgdGhlIGltcGxpY3QgZ3JhbnQgdHlw ZSBNVVNUIG9ubHkgcmVnaXN0ZXIgVVJMcyB1c2luZyB0aGUgaHR0cHMgc2NoZW1lIGFzIHJlZGly ZWN0X3VyaXM7IHRoZXkgTVVTVCBOT1QgdXNlIGxvY2FsaG9zdCBhcyB0aGUgaG9zdG5hbWUuIg0K DQo+DQoNCj4gcmVnYXJkcywNCg0KPiBUb3JzdGVuLg0KDQo+DQoNCj4gQW0gMDguMDcuMjAxNCAy MTozNSwgc2NocmllYiBSaWNoZXIsIEp1c3RpbiBQLjoNCg0KPj4NCg0KPj4gUmlnaHQsIHRoYXQn cyBob3cgaXQncyB1c2VkIGluIENvbm5lY3QsIHdoaWNoIGRlZmluZXMgb25seSByZWRpcmVjdC1i YXNlZCBmbG93cy4gSG93ZXZlciwgdGhlIE9BdXRoIHZlcnNpb24gbmVlZHMgdG8gYmUgbW9yZSBn ZW5lcmFsIHB1cnBvc2UuDQoNCj4+DQoNCj4+IEl0IHNlZW1zIGxpa2UgdGhpcyBwYXJhbWV0ZXIg cmVhbGx5IGRvZXMgbmVlZCBtb3JlIGRpc2N1c3Npb24gaW4gdGhlIGdyb3VwIGJlZm9yZSBpdCBz aG91bGQgYmUgYWRkZWQgdG8gdGhlIHNwZWMsIGFuZCB0aGVyZWZvcmUgSSBkb24ndCB0aGluayBp dCdzIGFwcHJvcHJpYXRlIHRvIGFkZCBpdCBhdCB0aGlzIHN0YWdlIChwb3N0LVdHTEMpLg0KDQo+ Pg0KDQo+PiAgLS0gSnVzdGluDQoNCj4+DQoNCj4+IE9uIEp1bCA4LCAyMDE0LCBhdCA4OjU0IFBN LCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwu Y29tPj4gd3JvdGU6DQoNCj4+DQoNCj4+PiBJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB0aGlz IHBhcmFtZXRlciBpcyB1c2VkIHRvIGFwcHJvcHJpYXRlbHkgY29uc3RyYWluIHRoZSBzY2hlbWEg b2YgdGhlIFJlZGlyZWN0IFVSSXMgYXQgdGhlIHRpbWUgb2YgdGhlIHJlZ2lzdHJhdGlvbiBhbmQg aXMgbm90IGFib3V0IGZ1bGZpbGxpbmcgdGhlIENsaWVudCBUeXBlIHJlZ2lzdHJhdGlvbiByZXF1 aXJlbWVudCBpbiBzZWN0aW9uIDIuMS4gU28sIG1ha2luZyBnbyBvciBuby1nbyBkZWNpc2lvbiBi YXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBhcm91bmQgc2VjdGlvbiAyLjEgcHJvYmFibHkgd291bGQg bm90IGJlIHRoZSB3YXkgdG8gZ28uIFRoZSBkaXNjdXNzaW9uIHNob3VsZCBoYXBwZW4gYXJvdW5k IHRoZSBuZWVkcyBvbiBjb25zdHJhaW5pbmcgdGhlIHNjaGVtYSBkZXBlbmRpbmcgb24gdGhlIGtp bmQgb2YgY2xpZW50Lg0KDQo+Pj4NCg0KPj4+IEFwcGFyZW50bHksIENvbm5lY3QgV0cgcGVyY2Vp dmVkIHRoYXQgaXQgaXMgYSBiaWcgZW5vdWdoIHJpc2sgdGhhdCB0aGV5IG5lZWQgdG8gcHV0IGEg cGx1ZyBvbiBiYXNlZCBvbiB0aGUgcmlzayBldmFsdWF0aW9uIGFzIGFuIGlkZW50aXR5IGZlZGVy YXRpb24gcHJvdG9jb2wuIE9BdXRoIGhhcyBkaWZmZXJlbnQgcmlzayBwcm9maWxlIHNvIGl0IGNv dWxkIGRlY2lkZSBvdGhlcndpc2UsIGJ1dCBteSBndXQgZmVlbGluZyBpcyB0aGF0IHVubGVzcyB0 aGVyZSBpcyBhIGdvb2QgcmVhc29uIG5vdCB0byBoYXZlIGl0LCB3ZSBtYXkgYXMgd2VsbCBrZWVw IGl0Lg0KDQo+Pj4NCg0KPj4+IE5hdA0KDQo+Pj4NCg0KPj4+DQoNCj4+PiAyMDE0LTA3LTA5IDc6 NTQgR01UKzA5OjAwIFJpY2hlciwgSnVzdGluIFAuIDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86 anJpY2hlckBtaXRyZS5vcmc+PjoNCg0KPj4+Pg0KDQo+Pj4+IFRoaXMgdmFsdWUgd2FzIGludHJv ZHVjZWQgaW4gLTE4LCBhbmQgaXQncyBhIGRpcmVjdCBwb3J0IGZyb20gT3BlbklEIENvbm5lY3Qu IEl0IHdhcyBuZXZlciBpbiB0aGUgT0F1dGggRHluYW1pYyBSZWdpc3RyYXRpb24gc3BlYywgYW5k IHRob3VnaCBpdCBoYXMgYmVlbiBpbiB0aGUgT3BlbklEIENvbm5lY3QgRHluYW1pYyBSZWdpc3Ry YXRpb24gc3BlYyBmb3IgYSB2ZXJ5IGxvbmcgdGltZSwgSSB0aGluayBpdCB3YXMgYSBtaXN0YWtl IHRvIGFkZCBpdCBpbiBmb3Igc2V2ZXJhbCByZWFzb25zOg0KDQo+Pj4+DQoNCj4+Pj4gRmlyc3Qs IHRoZSBzZW1hbnRpY3MgYXJvdW5kIGl0cyB2YWx1ZXMgYW5kIHVzZSBhcmUgbm90IGNsZWFybHkg ZGVmaW5lZCwgZm9yIHRoZSByZWFzb25zIC4gSSBkb24ndCBzZWUgYW55IHBhcnRpY3VsYXIgaGFy bSBpbiBrZWVwaW5nIGl0LCBidXQgSSBkb24ndCByZWFsbHkgc2VlIHdoYXQgdmFsdWUgaXQgYWRk cyBmb3IgY2xpZW50cyBvciBzZXJ2ZXIgZGV2ZWxvcGVycy4gV2UgYXJlIGluIGEgd29ybGQgd2hl cmUgdGhlcmUgYXJlIE9BdXRoIGNsaWVudHMgdGhhdCBhcmUgbXVjaCBtb3JlIHRoYW4ganVzdCAi bmF0aXZlIiBvciAid2ViIi4NCg0KPj4+Pg0KDQo+Pj4+IFNlY29uZCwgUkZDNjc0OSBkZWZpbmVz ICJDbGllbnQgVHlwZSIgaW4gwqcgMi4xIHdoaWNoIGRlZmluZXMgdHdvIHZhbHVlczogImNvbmZp ZGVudGlhbCIgYW5kICJwdWJsaWMiLCBuZWl0aGVyIG9mIHdoaWNoIG1hcHMgdmVyeSBjbGVhbmx5 IHRvICJuYXRpdmUiIG9yICJ3ZWIiIGFzIHN0YXRlZCBpbiAtMTguIFRoaXMgaXMgZXNwZWNpYWxs eSB0cnVlIHdoZW4geW91J3ZlIGdvdCBkeW5hbWljIHJlZ2lzdHJhdGlvbiB0aGF0IGNhbiBtYWtl IG5hdGl2ZSBjbGllbnRzIGNvbmZpZGVudGlhbCB3aXRoIHJlbGF0aXZlIGVhc2UuIFdlIGFjdHVh bGx5IHRha2UgY2FyZSBvZiByZWdpc3RlcmluZyB0aGUgImNsaWVudCB0eXBlIiB0aHJvdWdoIHRo ZSB1c2Ugb2YgdGhlICJ0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCIgcGFyYW1ldGVyLCB3aGlj aCBpcyB3aGF0IMKnIDIuMSBpcyByZWFsbHkgdGFsa2luZyBhYm91dDogc2VjdXJlIGNsaWVudCBh dXRoZW50aWNhdGlvbiAodG8gdGhlIHRva2VuIGVuZHBvaW50KS4NCg0KPj4+Pg0KDQo+Pj4+IFdp dGggdGhpcyBpbiBtaW5kLCBteSBwcmVmZXJlbmNlIGFuZCBzdWdnZXN0aW9uIHdvdWxkIGJlIHRv IHJlbW92ZSB0aGlzIGZpZWxkLiBJZiBvdGhlciBwcm90b2NvbHMgbmVlZCBpdCwgdGhleSBjYW4g cmVnaXN0ZXIgYW5kIGRlZmluZSBpdCAobGlrZSBDb25uZWN0IGhhcyBkb25lKS4NCg0KPj4+Pg0K DQo+Pj4+ICAtLSBKdXN0aW4NCg0KPj4+Pg0KDQo+Pj4+DQoNCj4+Pj4gT24gSnVsIDgsIDIwMTQs IGF0IDQ6MzggUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoNCj4+Pj4NCg0KPj4+Pj4g SSBwdXQgaXQgYmFjayBiZWNhdXNlIG90aGVyd2lzZSwgd2Ugd291bGRuJ3QgYmUgbWVldGluZyBv bmUgb2YgdGhlIHJlcXVpcmVtZW50cyBvZiB0aGUgUkZDIDY3NDkuICBJZiB5b3UgbG9vayBhdCB0 aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBzZWN0aW9uIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzY3NDkjc2VjdGlvbi0yLCB5b3UnbGwgc2VlIHRoYXQgcmVnaXN0ZXJpbmcgcmVkaXJlY3Rf dXJpIHZhbHVlcyBpcyByZXF1aXJlZCwgYXMgaXMgcmVnaXN0ZXJpbmcgdGhlIGNsaWVudCB0eXBl LiAgV2l0aG91dCB0aGlzLCB0aGVyZSB3YXNuJ3QgYSB3YXkgdG8gcmVnaXN0ZXIgdGhlIGNsaWVu dCB0eXBlLg0KDQo+Pj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN Cj4+Pj4+DQoNCj4+Pj4+DQoNCj4+Pj4+DQoNCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQoNCj4+Pj4+IEZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleQ0KDQo+Pj4+PiBTZW50OiBUdWVzZGF5LCBKdWx5IDA4 LCAyMDE0IDEyOjM3IFBNDQoNCj4+Pj4+IFRvOiBQaGlsIEh1bnQNCg0KPj4+Pj4gQ2M6IG9hdXRo QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCg0KPj4+Pj4gU3ViamVjdDogUmU6IFtP QVVUSC1XR10gRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uOiBhcHBsaWNhdGlvbl90eXBlDQoN Cj4+Pj4+DQoNCj4+Pj4+DQoNCj4+Pj4+DQoNCj4+Pj4+IEl0IHdhcyB0YWtlbiBvdXQgYW5kIHRo ZW4gcHV0IGJhY2sgaW4gYXMgaXQgaXMgYSBjb21tb24gcGFyYW1ldGVyIHVzZWQgYnkgYSBudW1i ZXIgb2YgQVMuDQoNCj4+Pj4+DQoNCj4+Pj4+DQoNCj4+Pj4+DQoNCj4+Pj4+IFdlIGhhdmUgaXQg aW4gQ29ubmVjdCwgdGhlIGJlc3QgcmVhc29uIGZvciBrZWVwaW5nIGl0IGlzIHRvIHN0b3AgcGVv cGxlIGZyb20gY29taW5nIHVwIHdpdGggYSBuZXcgcGFyYW1ldGVyIGZvciB0aGUgc2FtZSB0aGlu ZyBiZWNhdXNlIHRoZXkgaGF2ZW4ndCBsb29rZWQgYXQgdGhlIENvbm5lY3QgdmVyc2lvbi4NCg0K Pj4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4gSm9obiBCLg0KDQo+Pj4+Pg0KDQo+Pj4+ PiBPbiBKdWwgOCwgMjAxNCwgYXQgMzoxNiBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xl LmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KPj4+Pj4NCg0KPj4+ Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPiBEb2VzIHRoaXMgbmVlZCB0byBiZSBpbiB0aGUgc3BlYz8g IEkgYmVsaWV2ZSB3ZSd2ZSBhbHJlYWR5IHNhaWQgdGhhdCBvdGhlcnMgY2FuIGFkZCBhdHRyaWJ1 dGVzIGFzIHRoZXkgbmVlZC4NCg0KPj4+Pj4NCg0KPj4+Pj4gPg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+ IFBoaWwNCg0KPj4+Pj4NCg0KPj4+Pj4gPg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+IEBpbmRlcGVuZGVu dGlkDQoNCj4+Pj4+DQoNCj4+Pj4+ID4gd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cu aW5kZXBlbmRlbnRpZC5jb20+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4gcGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+DQoNCj4+ Pj4+DQoNCj4+Pj4+ID4NCg0KPj4+Pj4NCg0KPj4+Pj4gPg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+IE9u IEp1bCA4LCAyMDE0LCBhdCAxMTo1NiBBTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNv bTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCg0KPj4+Pj4NCg0KPj4+Pj4gPg0K DQo+Pj4+Pg0KDQo+Pj4+PiA+PiBUaGUgYXBwbGljYXRpb25fdHlwZSBpcyBjb2xsZWN0ZWQgYXMg cGFydCBvZiBjdXJyZW50IHJlZ2lzdHJhdGlvbiBieSBHb29nbGUgYW5kIHNvbWUgb3RoZXIgT0F1 dGggcHJvdmlkZXJzIGFzIHBhcnQgb2YgcmVnaXN0ZXJpbmcgcmVkaXJlY3QgdXJpLg0KDQo+Pj4+ Pg0KDQo+Pj4+PiA+Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+PiBUaGUgdGV4dCB3YXMgY3V0IGRvd24g dG8gYWxsb3cgbW9yZSBmbGV4aWJpbGl0eSBpbiBPQXV0aC4gIENvbm5lY3QgcmVxdWlyZXMgcmVn aXN0cmF0aW9uIG9mIHJlZGlyZWN0X3VyaSBhbmQgaXMgbW9yZSByaWRnZWQgYWJvdXQgaXQgdGhh biBPQXV0aCAyLg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+PiBEbyB5 b3UgdGhpbmsgdGhlIENvbm5lY3Qgd29yZGluZyB3b3VsZCBiZSBhcHByb3ByaWF0ZSBmb3IgT0F1 dGg/DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+IEpvaG4gQi4NCg0K Pj4+Pj4NCg0KPj4+Pj4gPj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4gT24gSnVsIDgsIDIwMTQsIGF0 IDk6MjIgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1h aWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4gd3JvdGU6DQoNCj4+Pj4+DQoNCj4+Pj4+ ID4+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+PiBUaGlzIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gbWFr ZXMgYSBsb3Qgb2Ygc2Vuc2UuDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+ PiA+Pj4gQXMgeW91IHNhaWQgaW4gYW4gZWFybGllciBtYWlsLCB0aGUgYXR0ZW1wdCB0byBjb3B5 IHRleHQgZnJvbSB0aGUNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+IE9wZW5JRCBDb25uZWN0IHNwZWMg ZmFpbGVkIGEgYml0Li4uDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+ Pj4gT24gMDcvMDgvMjAxNCAwMjo0OSBQTSwgTmF0IFNha2ltdXJhIHdyb3RlOg0KDQo+Pj4+Pg0K DQo+Pj4+PiA+Pj4+IEkgc3VwcG9zZSBhdXRob3JzIGhhcyBpbXBvcnRlZCBvbmUgb2YgdGhlIHNl Y3VyaXR5IGZlYXR1cmUgb2YNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiBPcGVuSUQgQ29ubmVjdCBo ZXJlIGFzIHdlbGwuIEluIHRoZSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24NCg0KPj4+Pj4N Cg0KPj4+Pj4gPj4+PiBzdGFuZGFyZCwgd2hpY2ggaXMgYSBiaXQgbG9uZ2VyIHRoYW4gSUVURiB2 ZXJzaW9uLiBZb3UgY2FuIHNlZSB0aGUgcmVhc29uIGZyb20gaXQ6DQoNCj4+Pj4+DQoNCj4+Pj4+ ID4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiBhcHBsaWNhdGlvbl90eXBlDQoNCj4+Pj4+DQoN Cj4+Pj4+ID4+Pj4gIE9QVElPTkFMLiBLaW5kIG9mIHRoZSBhcHBsaWNhdGlvbi4gVGhlIGRlZmF1 bHQsIGlmIG9taXR0ZWQsIGlzIHdlYi4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiAgVGhlIGRlZmlu ZWQgdmFsdWVzIGFyZSBuYXRpdmUgb3Igd2ViLiBXZWIgQ2xpZW50cyB1c2luZyB0aGUgT0F1dGgN Cg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiBJbXBsaWNpdCBHcmFudCBUeXBlIE1VU1Qgb25seSByZWdp c3RlciBVUkxzIHVzaW5nIHRoZSBodHRwcyBzY2hlbWUNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiBh cyByZWRpcmVjdF91cmlzOyB0aGV5IE1VU1QgTk9UIHVzZSBsb2NhbGhvc3QgYXMgdGhlIGhvc3Ru YW1lLg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+ICBOYXRpdmUgQ2xpZW50cyBNVVNUIG9ubHkgcmVn aXN0ZXIgcmVkaXJlY3RfdXJpcyB1c2luZyBjdXN0b20gVVJJDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+ Pj4gc2NoZW1lcyBvciBVUkxzIHVzaW5nIHRoZSBodHRwOiBzY2hlbWUgd2l0aCBsb2NhbGhvc3Qg YXMgdGhlDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gaG9zdG5hbWUuIEF1dGhvcml6YXRpb24gU2Vy dmVycyBNQVkgcGxhY2UgYWRkaXRpb25hbCBjb25zdHJhaW50cyBvbg0KDQo+Pj4+Pg0KDQo+Pj4+ PiA+Pj4+IE5hdGl2ZSBDbGllbnRzLiBBdXRob3JpemF0aW9uIFNlcnZlcnMgTUFZIHJlamVjdCBS ZWRpcmVjdGlvbiBVUkkNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiB2YWx1ZXMgdXNpbmcgdGhlIGh0 dHAgc2NoZW1lLCBvdGhlciB0aGFuIHRoZSBsb2NhbGhvc3QgY2FzZSBmb3INCg0KPj4+Pj4NCg0K Pj4+Pj4gPj4+PiBOYXRpdmUgQ2xpZW50cy4gVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1Qg dmVyaWZ5IHRoYXQgYWxsIHRoZQ0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+IHJlZ2lzdGVyZWQgcmVk aXJlY3RfdXJpcyBjb25mb3JtIHRvIHRoZXNlIGNvbnN0cmFpbnRzLiBUaGlzDQoNCj4+Pj4+DQoN Cj4+Pj4+ID4+Pj4gcHJldmVudHMgIHNoYXJpbmcgYSBDbGllbnQgSUQgYWNyb3NzIGRpZmZlcmVu dCB0eXBlcyBvZiBDbGllbnRzLg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+DQoNCj4+Pj4+DQoNCj4+ Pj4+ID4+Pj4gUmVnYXJkcywNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+ PiA+Pj4+IE5hdA0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4N Cg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiAyMDE0LTA3LTA4IDIxOjE3IEdNVCswOTowMCBIYW5uZXMg VHNjaG9mZW5pZw0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+IDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgu bmV0DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gPG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgu bmV0Pj46DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiAgSGkg YWxsLA0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gIHdpdGgg dmVyc2lvbiAtMTggeW91IGd1eXMgaGF2ZSBhZGRlZCBhIG5ldyBtZXRhLWRhdGEgYXR0cmlidXRl LA0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+IG5hbWVseSAgYXBwbGljYXRpb25fdHlwZS4NCg0KPj4+ Pj4NCg0KPj4+Pj4gPj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+ICBGaXJzdCwgdGhpcyBuZXcg YXR0cmlidXRlIGlzIG5vdCBsaXN0ZWQgaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbg0KDQo+Pj4+ Pg0KDQo+Pj4+PiA+Pj4+IHNlY3Rpb24uDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4NCg0KPj4+Pj4N Cg0KPj4+Pj4gPj4+PiAgU2Vjb25kLCBjb3VsZCB5b3UgcHJvdmlkZSBhIGJpdCBvZiBtb3RpdmF0 aW9uIHdoeSB5b3UgbmVlZCBpdD8NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiBXaGF0ICB3b3VsZCB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZG8gd2l0aCB0aGF0IHR5cGUgb2YNCg0KPj4+Pj4NCg0K Pj4+Pj4gPj4+PiBpbmZvcm1hdGlvbj8gVGhlICBkZXNjcmlwdGlvbiBpcyByYXRoZXIgc2hvcnQu DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiAgSU1ITyB0aGVy ZSBpcyBhbHNvIG5vIGNsZWFyIGJvdW5kYXJ5IGJldHdlZW4gYSAibmF0aXZlIiBhbmQgIndlYiIg YXBwLg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+ICBKdXN0IHRoaW5rIGFib3V0IHNtYXJ0IHBob25l IGFwcHMgdGhhdCBhcmUgZGV2ZWxvcGVkIHVzaW5nIEphdmFTY3JpcHQuDQoNCj4+Pj4+DQoNCj4+ Pj4+ID4+Pj4gIFdvdWxkIHRoaXMgYmUgYSB3ZWIgYXBwIG9yIGEgbmF0aXZlIGFwcD8NCg0KPj4+ Pj4NCg0KPj4+Pj4gPj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+ICBIZXJlIGlzIHRoZSBkZWZp bml0aW9uIGZyb20gdGhlIGRyYWZ0Og0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+DQoNCj4+Pj4+DQoN Cj4+Pj4+ID4+Pj4gIGFwcGxpY2F0aW9uX3R5cGUNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiAgICAg ICAgT1BUSU9OQUwuICBLaW5kIG9mIHRoZSBhcHBsaWNhdGlvbi4gIFRoZSBkZWZhdWx0LCBpZiBv bWl0dGVkLCBpcw0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+ICAgICAgICAid2ViIi4gIFRoZSBkZWZp bmVkIHZhbHVlcyBhcmUgIm5hdGl2ZSIgb3IgIndlYiIuDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4N Cg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiAgQ2lhbw0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+ICBIYW5u ZXMNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+DQoNCj4+Pj4+ DQoNCj4+Pj4+ID4+Pj4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gIE9BdXRoIG1haWxpbmcgbGlzdA0KDQo+Pj4+ Pg0KDQo+Pj4+PiA+Pj4+ICBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+IDxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+DQoN Cj4+Pj4+DQoNCj4+Pj4+ID4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+Pg0KDQo+Pj4+Pg0KDQo+ Pj4+PiA+Pj4+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gLS0NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+ PiBOYXQgU2FraW11cmEgKD1uYXQpDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gQ2hhaXJtYW4sIE9w ZW5JRCBGb3VuZGF0aW9uDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gaHR0cDovL25hdC5zYWtpbXVy YS5vcmcvDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gQF9uYXRfZW4NCg0KPj4+Pj4NCg0KPj4+Pj4g Pj4+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4gT0F1dGggbWFpbGluZyBsaXN0 DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4+Pj4+DQoN Cj4+Pj4+ID4+IE9BdXRoIG1haWxpbmcgbGlzdA0KDQo+Pj4+Pg0KDQo+Pj4+PiA+PiBPQXV0aEBp ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KPj4+Pj4NCg0KPj4+Pj4g Pg0KDQo+Pj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+Pj4+Pg0KDQo+Pj4+PiBPQXV0aCBtYWls aW5nIGxpc3QNCg0KPj4+Pj4NCg0KPj4+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KDQo+Pj4+Pg0KDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQoNCj4+Pj4+DQoNCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KDQo+Pj4+ PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KPj4+Pg0KDQo+Pj4+DQoNCj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPj4+ PiBPQXV0aCBtYWlsaW5nIGxpc3QNCg0KPj4+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+DQoNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KDQo+Pj4+DQoNCj4+Pg0KDQo+Pj4NCg0KPj4+DQoNCj4+PiAtLQ0KDQo+Pj4gTmF0IFNh a2ltdXJhICg9bmF0KQ0KDQo+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQoNCj4+PiBo dHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCg0KPj4+IEBfbmF0X2VuDQoNCj4+DQoNCj4+DQoNCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4+DQoN Cj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KDQo+Pg0KDQo+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQoNCj4+DQoNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg0KPj4NCg0KPg0KDQo+DQoNCj4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_4E1F6AAD24975D4BA5B16804296739439ADDD97CTK5EX14MBXC294r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0 LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjojMDAzMzY2O30NCnAuTXNvQWNldGF0 ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkl0J3MgbW9yZSBjb21wbGlj YXRlZCB0aGFuIHRoYXQsIGFzIG5hdGl2ZSBhcHBzIG1heSB1c2UgdGhlIGltcGxpY2l0IGZsb3cg YW5kIG5vdCB1c2UgaHR0cHMuJm5ic3A7IFRoZSBzZXQgb2YgY29uc3RyYWludHMgaW4gdGhlICZx dW90O2FwcGxpY2F0aW9uX3R5cGUmcXVvdDsgZGVmaW5pdGlvbiBpbiBPcGVuSUQgQ29ubmVjdCBE eW5hbWljIFJlZ2lzdHJhdGlvbiBhcmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5XZWIgQ2xpZW50cyB1c2luZyB0aGUgT0F1dGggSW1wbGljaXQgR3Jh bnQgVHlwZSBNVVNUIG9ubHkgcmVnaXN0ZXIgVVJMcyB1c2luZyB0aGUNCjwvc3Bhbj48dHQ+PHNw YW4gbGFuZz0iRU4iPmh0dHBzPC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IHNjaGVtZSBhcw0KPC9zcGFuPjx0dD48c3BhbiBsYW5n PSJFTiI+cmVkaXJlY3RfdXJpczwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjsgdGhleSBNVVNUIE5PVCB1c2UNCjwvc3Bhbj48dHQ+ PHNwYW4gbGFuZz0iRU4iPmxvY2FsaG9zdDwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiBhcyB0aGUgaG9zdG5hbWUuIE5hdGl2ZSBD bGllbnRzIE1VU1Qgb25seSByZWdpc3Rlcg0KPC9zcGFuPjx0dD48c3BhbiBsYW5nPSJFTiI+cmVk aXJlY3RfdXJpczwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiB1c2luZyBjdXN0b20gVVJJIHNjaGVtZXMgb3IgVVJMcyB1c2luZyB0 aGUNCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iRU4iPmh0dHA6PC9zcGFuPjwvdHQ+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IHNjaGVtZSB3aXRoDQo8 L3NwYW4+PHR0PjxzcGFuIGxhbmc9IkVOIj5sb2NhbGhvc3Q8L3NwYW4+PC90dD48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gYXMgdGhlIGhvc3RuYW1l LiBBdXRob3JpemF0aW9uIFNlcnZlcnMgTUFZIHBsYWNlIGFkZGl0aW9uYWwgY29uc3RyYWludHMg b24gTmF0aXZlIENsaWVudHMuIEF1dGhvcml6YXRpb24gU2VydmVycyBNQVkgcmVqZWN0DQogUmVk aXJlY3Rpb24gVVJJIHZhbHVlcyB1c2luZyB0aGUgPC9zcGFuPjx0dD48c3BhbiBsYW5nPSJFTiI+ aHR0cDwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiBzY2hlbWUsIG90aGVyIHRoYW4gdGhlDQo8L3NwYW4+PHR0PjxzcGFuIGxhbmc9 IkVOIj5sb2NhbGhvc3Q8L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4gY2FzZSBmb3IgTmF0aXZlIENsaWVudHMuPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPklmIHdl4oCZcmUgZ29pbmcgdG8gYWRkIHN1Y2ggY29uc3RyYWludHMsIEkgYmVsaWV2 ZSB0aGV5IHNob3VsZCBiZSB0aGUgc2FtZSBvbmVzIGFzIHRoZSBvbmVzIGFib3ZlLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IE9B dXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBS aWNoZXI8YnI+DQpTZW50OiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0IDY6MTYgUE08YnI+DQpUbzog dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8YnI+DQpDYzogb2F1dGhAaWV0Zi5vcmc8YnI+DQpTdWJq ZWN0OiBSZTogW09BVVRILVdHXSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb246IGFwcGxpY2F0 aW9uX3R5cGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkknbSBvayB3aXRoIHRoYXQgdGV4dCwgYW5kIGFj dHVhbGx5IHRob3VnaHQgd2UgaGFkIHNvbWV0aGluZyBhbG9uZyB0aG9zZSBsaW5lcyBhbHJlYWR5 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLUp1c3RpbjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4vc2VudCBmcm9tIG15IHBob25lLzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5PbiBKdWwgMjIsIDIwMTQgMzoyNyBQTSwgPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5A bG9kZGVyc3RlZHQubmV0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVj b3JhdGlvbjpub25lIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvc3Bhbj48L2E+IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBIaSBhbGwsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEkgZG9uJ3QgdGhpbmsgdGhpcyBwYXJhbWV0ZXIg YWRkcyBhbnkgc2VjdXJpdHkgKGFzIGl0IGlzIHNlbGYgZGVjbGFyZGVkIGJ5IHRoZSBjYWxsZXIp LiBJIHRoaW5rIHRoZSBjb25zdHJhaW50cyBvbiByZWRpcmVjdF91cmlzIGNhbiBiZSBzcGVjaWZp ZWQgd2l0aG91dCB0aGUgbmVlZCBmb3IgYW5vdGhlciByZWdpc3RyYXRpb24gcGFyYW1ldGVyLiBB cyBmYXIgYXMgSSB1bmRlcnN0YW5kLCB0aGV5IG1lcmVseQ0KIGRlcGVuZCBvbiB0aGUgZ3JhbnQg dHlwZS4gU28gd2UgY291bGQgc29tZSB0ZXh0IHRvIHRoZSByZWRpcmVjdF91cmkgcGFyYW1ldGVy IGRlZmluaXRpb24uIFNvbWV0aGluZyBhbG9uZyB0aGUgZm9sbG93aW5nIGxpbmVzOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmcXVvdDtBbGwgcmVkaXJlY3QgVVJJcyBy ZWdpc3RlcmVkIGZvciBhIHBhcnRpY3VsYXIgY2xpZW50IE1VU1QgZWl0aGVyICgxKSB1c2UgdGhl Jm5ic3A7SFRUUFMgc2NoZW1lIG9yICgyKSB0aGUgSFRUUCBzY2hlbWUgd2l0aCBsb2NhbGhvc3Qg YXMgdGhlIGhvc3RuYW1lIG9yIGN1c3RvbSBzY2hlbWVzLiBBZGRpdGlvbmFsbHksIGNsaWVudHMg dXNpbmcgdGhlIGltcGxpY3QmbmJzcDtncmFudCB0eXBlIE1VU1Qgb25seSByZWdpc3Rlcg0KIFVS THMgdXNpbmcgdGhlIGh0dHBzIHNjaGVtZSBhcyByZWRpcmVjdF91cmlzOyB0aGV5IE1VU1QgTk9U IHVzZSBsb2NhbGhvc3QgYXMgdGhlIGhvc3RuYW1lLiZxdW90OyAmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgVG9yc3Rlbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgQW0gMDguMDcuMjAxNCAyMTozNSwgc2NocmllYiBSaWNoZXIsIEp1c3Rp biBQLjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBSaWdo dCwgdGhhdCdzIGhvdyBpdCdzIHVzZWQgaW4gQ29ubmVjdCwgd2hpY2ggZGVmaW5lcyBvbmx5IHJl ZGlyZWN0LWJhc2VkIGZsb3dzLiBIb3dldmVyLCB0aGUgT0F1dGggdmVyc2lvbiBuZWVkcyB0byBi ZSBtb3JlIGdlbmVyYWwgcHVycG9zZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyZndDsgSXQgc2VlbXMgbGlrZSB0aGlzIHBhcmFtZXRlciByZWFsbHkg ZG9lcyBuZWVkIG1vcmUgZGlzY3Vzc2lvbiBpbiB0aGUgZ3JvdXAgYmVmb3JlIGl0IHNob3VsZCBi ZSBhZGRlZCB0byB0aGUgc3BlYywgYW5kIHRoZXJlZm9yZSBJIGRvbid0IHRoaW5rIGl0J3MgYXBw cm9wcmlhdGUgdG8gYWRkIGl0IGF0IHRoaXMgc3RhZ2UgKHBvc3QtV0dMQykuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7ICZuYnNwOy0tIEp1c3RpbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDs8bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IE9uIEp1bCA4LCAyMDE0 LCBhdCA4OjU0IFBNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBn bWFpbC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lIj5zYWtpbXVyYUBnbWFpbC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IElmIEkgdW5kZXJzdGFuZCBj b3JyZWN0bHksIHRoaXMgcGFyYW1ldGVyIGlzIHVzZWQgdG8gYXBwcm9wcmlhdGVseSBjb25zdHJh aW4gdGhlIHNjaGVtYSBvZiB0aGUgUmVkaXJlY3QgVVJJcyBhdCB0aGUgdGltZSBvZiB0aGUgcmVn aXN0cmF0aW9uIGFuZCBpcyBub3QgYWJvdXQgZnVsZmlsbGluZyB0aGUgQ2xpZW50IFR5cGUgcmVn aXN0cmF0aW9uIHJlcXVpcmVtZW50IGluIHNlY3Rpb24gMi4xLiBTbywNCiBtYWtpbmcgZ28gb3Ig bm8tZ28gZGVjaXNpb24gYmFzZWQgb24gdGhlIGRpc2N1c3Npb24gYXJvdW5kIHNlY3Rpb24gMi4x IHByb2JhYmx5IHdvdWxkIG5vdCBiZSB0aGUgd2F5IHRvIGdvLiBUaGUgZGlzY3Vzc2lvbiBzaG91 bGQgaGFwcGVuIGFyb3VuZCB0aGUgbmVlZHMgb24gY29uc3RyYWluaW5nIHRoZSBzY2hlbWEgZGVw ZW5kaW5nIG9uIHRoZSBraW5kIG9mIGNsaWVudC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyBBcHBhcmVudGx5LCBDb25uZWN0IFdH IHBlcmNlaXZlZCB0aGF0IGl0IGlzIGEgYmlnIGVub3VnaCByaXNrIHRoYXQgdGhleSBuZWVkIHRv IHB1dCBhIHBsdWcgb24gYmFzZWQgb24gdGhlIHJpc2sgZXZhbHVhdGlvbiBhcyBhbiBpZGVudGl0 eSBmZWRlcmF0aW9uIHByb3RvY29sLiBPQXV0aCBoYXMgZGlmZmVyZW50IHJpc2sgcHJvZmlsZSBz byBpdCBjb3VsZCBkZWNpZGUgb3RoZXJ3aXNlLCBidXQgbXkNCiBndXQgZmVlbGluZyBpcyB0aGF0 IHVubGVzcyB0aGVyZSBpcyBhIGdvb2QgcmVhc29uIG5vdCB0byBoYXZlIGl0LCB3ZSBtYXkgYXMg d2VsbCBrZWVwIGl0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZndDsmZ3Q7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmZ3Q7IE5hdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7Jmd0OyAyMDE0LTA3LTA5IDc6NTQgR01UJiM0MzswOTowMCBSaWNo ZXIsIEp1c3RpbiBQLiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+anJpY2hlckBt aXRyZS5vcmc8L3NwYW4+PC9hPiZndDs6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMgdmFsdWUgd2FzIGludHJvZHVjZWQg aW4gLTE4LCBhbmQgaXQncyBhIGRpcmVjdCBwb3J0IGZyb20gT3BlbklEIENvbm5lY3QuIEl0IHdh cyBuZXZlciBpbiB0aGUgT0F1dGggRHluYW1pYyBSZWdpc3RyYXRpb24gc3BlYywgYW5kIHRob3Vn aCBpdCBoYXMgYmVlbiBpbiB0aGUgT3BlbklEIENvbm5lY3QgRHluYW1pYyBSZWdpc3RyYXRpb24g c3BlYyBmb3IgYSB2ZXJ5IGxvbmcgdGltZSwgSSB0aGluaw0KIGl0IHdhcyBhIG1pc3Rha2UgdG8g YWRkIGl0IGluIGZvciBzZXZlcmFsIHJlYXNvbnM6Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyBGaXJzdCwgdGhlIHNl bWFudGljcyBhcm91bmQgaXRzIHZhbHVlcyBhbmQgdXNlIGFyZSBub3QgY2xlYXJseSBkZWZpbmVk LCBmb3IgdGhlIHJlYXNvbnMgLiBJIGRvbid0IHNlZSBhbnkgcGFydGljdWxhciBoYXJtIGluIGtl ZXBpbmcgaXQsIGJ1dCBJIGRvbid0IHJlYWxseSBzZWUgd2hhdCB2YWx1ZSBpdCBhZGRzIGZvciBj bGllbnRzIG9yIHNlcnZlciBkZXZlbG9wZXJzLiBXZSBhcmUgaW4gYSB3b3JsZA0KIHdoZXJlIHRo ZXJlIGFyZSBPQXV0aCBjbGllbnRzIHRoYXQgYXJlIG11Y2ggbW9yZSB0aGFuIGp1c3QgJnF1b3Q7 bmF0aXZlJnF1b3Q7IG9yICZxdW90O3dlYiZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IFNlY29uZCwgUkZDNjc0OSBk ZWZpbmVzICZxdW90O0NsaWVudCBUeXBlJnF1b3Q7IGluIMKnIDIuMSB3aGljaCBkZWZpbmVzIHR3 byB2YWx1ZXM6ICZxdW90O2NvbmZpZGVudGlhbCZxdW90OyBhbmQgJnF1b3Q7cHVibGljJnF1b3Q7 LCBuZWl0aGVyIG9mIHdoaWNoIG1hcHMgdmVyeSBjbGVhbmx5IHRvICZxdW90O25hdGl2ZSZxdW90 OyBvciAmcXVvdDt3ZWImcXVvdDsgYXMgc3RhdGVkIGluIC0xOC4gVGhpcyBpcyBlc3BlY2lhbGx5 IHRydWUgd2hlbiB5b3UndmUgZ290IGR5bmFtaWMgcmVnaXN0cmF0aW9uDQogdGhhdCBjYW4gbWFr ZSBuYXRpdmUgY2xpZW50cyBjb25maWRlbnRpYWwgd2l0aCByZWxhdGl2ZSBlYXNlLiBXZSBhY3R1 YWxseSB0YWtlIGNhcmUgb2YgcmVnaXN0ZXJpbmcgdGhlICZxdW90O2NsaWVudCB0eXBlJnF1b3Q7 IHRocm91Z2ggdGhlIHVzZSBvZiB0aGUgJnF1b3Q7dG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2Qm cXVvdDsgcGFyYW1ldGVyLCB3aGljaCBpcyB3aGF0IMKnIDIuMSBpcyByZWFsbHkgdGFsa2luZyBh Ym91dDogc2VjdXJlIGNsaWVudCBhdXRoZW50aWNhdGlvbiAodG8NCiB0aGUgdG9rZW4gZW5kcG9p bnQpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsmZ3Q7Jmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyZndDsgV2l0aCB0aGlzIGluIG1pbmQsIG15IHByZWZlcmVuY2UgYW5kIHN1 Z2dlc3Rpb24gd291bGQgYmUgdG8gcmVtb3ZlIHRoaXMgZmllbGQuIElmIG90aGVyIHByb3RvY29s cyBuZWVkIGl0LCB0aGV5IGNhbiByZWdpc3RlciBhbmQgZGVmaW5lIGl0IChsaWtlIENvbm5lY3Qg aGFzIGRvbmUpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsmZ3Q7Jmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7LS0gSnVzdGluPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBKdWwgOCwg MjAxNCwgYXQgNDozOCBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgcHV0IGl0IGJhY2sgYmVjYXVzZSBvdGhlcndpc2UsIHdlIHdv dWxkbid0IGJlIG1lZXRpbmcgb25lIG9mIHRoZSByZXF1aXJlbWVudHMgb2YgdGhlIFJGQyA2NzQ5 LiZuYnNwOyBJZiB5b3UgbG9vayBhdCB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBzZWN0aW9uDQo8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMiI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0yPC9zcGFuPjwvYT4sIHlvdSdsbCBz ZWUgdGhhdCByZWdpc3RlcmluZyByZWRpcmVjdF91cmkgdmFsdWVzIGlzIHJlcXVpcmVkLCBhcyBp cyByZWdpc3RlcmluZyB0aGUgY2xpZW50IHR5cGUuJm5ic3A7DQogV2l0aG91dCB0aGlzLCB0aGVy ZSB3YXNuJ3QgYSB3YXkgdG8gcmVnaXN0ZXIgdGhlIGNsaWVudCB0eXBlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZyb206 IE9BdXRoIFs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dIE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXk8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDgsIDIwMTQgMTI6MzcgUE08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBQaGlsIEh1bnQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IENjOiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5vYXV0aEBpZXRmLm9yZzwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRp b246IGFwcGxpY2F0aW9uX3R5cGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJ dCB3YXMgdGFrZW4gb3V0IGFuZCB0aGVuIHB1dCBiYWNrIGluIGFzIGl0IGlzIGEgY29tbW9uIHBh cmFtZXRlciB1c2VkIGJ5IGEgbnVtYmVyIG9mIEFTLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFdlIGhhdmUgaXQgaW4gQ29ubmVjdCwgdGhlIGJlc3QgcmVhc29uIGZvciBrZWVw aW5nIGl0IGlzIHRvIHN0b3AgcGVvcGxlIGZyb20gY29taW5nIHVwIHdpdGggYSBuZXcgcGFyYW1l dGVyIGZvciB0aGUgc2FtZSB0aGluZyBiZWNhdXNlIHRoZXkgaGF2ZW4ndCBsb29rZWQgYXQgdGhl IENvbm5lY3QgdmVyc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBKb2hu IEIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgT24gSnVsIDgsIDIwMTQsIGF0IDM6MTYgUE0sIFBoaWwgSHVudCAm bHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+cGhpbC5odW50QG9yYWNsZS5jb208 L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Jmd0OyBEb2VzIHRoaXMgbmVlZCB0byBiZSBpbiB0aGUgc3BlYz8mbmJzcDsgSSBiZWxpZXZlIHdl J3ZlIGFscmVhZHkgc2FpZCB0aGF0IG90aGVycyBjYW4gYWRkIGF0dHJpYnV0ZXMgYXMgdGhleSBu ZWVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7IFBoaWw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyBAaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 ICZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnd3dy5pbmRlcGVuZGVudGlk LmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Jmd0OyBPbiBKdWwgOCwgMjAxNCwgYXQgMTE6NTYgQU0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+dmU3anRiQHZlN2p0Yi5jb208L3NwYW4+PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFRoZSBhcHBs aWNhdGlvbl90eXBlIGlzIGNvbGxlY3RlZCBhcyBwYXJ0IG9mIGN1cnJlbnQgcmVnaXN0cmF0aW9u IGJ5IEdvb2dsZSBhbmQgc29tZSBvdGhlciBPQXV0aCBwcm92aWRlcnMgYXMgcGFydCBvZiByZWdp c3RlcmluZyByZWRpcmVjdCB1cmkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBUaGUgdGV4dCB3YXMgY3V0IGRvd24gdG8gYWxsb3cgbW9yZSBmbGV4aWJpbGl0 eSBpbiBPQXV0aC4mbmJzcDsgQ29ubmVjdCByZXF1aXJlcyByZWdpc3RyYXRpb24gb2YgcmVkaXJl Y3RfdXJpIGFuZCBpcyBtb3JlIHJpZGdlZCBhYm91dCBpdCB0aGFuIE9BdXRoIDIuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBEbyB5b3UgdGhpbmsgdGhlIENv bm5lY3Qgd29yZGluZyB3b3VsZCBiZSBhcHByb3ByaWF0ZSBmb3IgT0F1dGg/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBKb2huIEIuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBPbiBKdWwgOCwgMjAxNCwgYXQgOToyMiBB TSwgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5p Z0BnbXgubmV0Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGlzIGFkZGl0 aW9uYWwgaW5mb3JtYXRpb24gbWFrZXMgYSBsb3Qgb2Ygc2Vuc2UuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IEFzIHlvdSBzYWlkIGluIGFuIGVh cmxpZXIgbWFpbCwgdGhlIGF0dGVtcHQgdG8gY29weSB0ZXh0IGZyb20gdGhlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsmZ3Q7IE9wZW5JRCBDb25uZWN0IHNwZWMgZmFpbGVkIGEgYml0Li4uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IE9uIDA3LzA4 LzIwMTQgMDI6NDkgUE0sIE5hdCBTYWtpbXVyYSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IEkgc3VwcG9zZSBhdXRob3JzIGhhcyBpbXBvcnRlZCBvbmUgb2YgdGhlIHNlY3Vy aXR5IGZlYXR1cmUgb2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9wZW5JRCBDb25u ZWN0IGhlcmUgYXMgd2VsbC4gSW4gdGhlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgc3RhbmRhcmQsIHdoaWNoIGlzIGEgYml0IGxvbmdl ciB0aGFuIElFVEYgdmVyc2lvbi4gWW91IGNhbiBzZWUgdGhlIHJlYXNvbiBmcm9tIGl0OjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IGFwcGxpY2F0aW9uX3R5cGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IE9Q VElPTkFMLiBLaW5kIG9mIHRoZSBhcHBsaWNhdGlvbi4gVGhlIGRlZmF1bHQsIGlmIG9taXR0ZWQs IGlzIHdlYi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IFRoZSBkZWZpbmVk IHZhbHVlcyBhcmUgbmF0aXZlIG9yIHdlYi4gV2ViIENsaWVudHMgdXNpbmcgdGhlIE9BdXRoJm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJbXBsaWNpdCBHcmFudCBUeXBlIE1V U1Qgb25seSByZWdpc3RlciBVUkxzIHVzaW5nIHRoZSBodHRwcyBzY2hlbWUmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFzIHJlZGlyZWN0X3VyaXM7IHRoZXkgTVVTVCBOT1Qg dXNlIGxvY2FsaG9zdCBhcyB0aGUgaG9zdG5hbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyBOYXRpdmUgQ2xpZW50cyBNVVNUIG9ubHkgcmVnaXN0ZXIgcmVkaXJlY3RfdXJp cyB1c2luZyBjdXN0b20gVVJJJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBz Y2hlbWVzIG9yIFVSTHMgdXNpbmcgdGhlIGh0dHA6IHNjaGVtZSB3aXRoIGxvY2FsaG9zdCBhcyB0 aGUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGhvc3RuYW1lLiBBdXRob3Jp emF0aW9uIFNlcnZlcnMgTUFZIHBsYWNlIGFkZGl0aW9uYWwgY29uc3RyYWludHMgb24mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE5hdGl2ZSBDbGllbnRzLiBBdXRob3JpemF0 aW9uIFNlcnZlcnMgTUFZIHJlamVjdCBSZWRpcmVjdGlvbiBVUkkmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHZhbHVlcyB1c2luZyB0aGUgaHR0cCBzY2hlbWUsIG90aGVyIHRo YW4gdGhlIGxvY2FsaG9zdCBjYXNlIGZvciZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgTmF0aXZlIENsaWVudHMuIFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHZlcmlm eSB0aGF0IGFsbCB0aGUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZ2lz dGVyZWQgcmVkaXJlY3RfdXJpcyBjb25mb3JtIHRvIHRoZXNlIGNvbnN0cmFpbnRzLiBUaGlzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBwcmV2ZW50cyZuYnNwOyBzaGFyaW5nIGEgQ2xp ZW50IElEIGFjcm9zcyBkaWZmZXJlbnQgdHlwZXMgb2YgQ2xpZW50cy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBSZWdhcmRzLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IE5hdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAyMDE0LTA3LTA4IDIx OjE3IEdNVCYjNDM7MDk6MDAgSGFubmVzIFRzY2hvZmVuaWc8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7ICZsdDtoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5t YWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvc3Bhbj48L2E+Jmd0OyZndDs6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsgSGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IHdpdGggdmVyc2lvbiAtMTggeW91IGd1eXMgaGF2ZSBh ZGRlZCBhIG5ldyBtZXRhLWRhdGEgYXR0cmlidXRlLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgbmFtZWx5Jm5ic3A7IGFwcGxpY2F0aW9uX3R5cGUuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgRmlyc3QsIHRo aXMgbmV3IGF0dHJpYnV0ZSBpcyBub3QgbGlzdGVkIGluIHRoZSBJQU5BIGNvbnNpZGVyYXRpb24m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHNlY3Rpb24uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsg U2Vjb25kLCBjb3VsZCB5b3UgcHJvdmlkZSBhIGJpdCBvZiBtb3RpdmF0aW9uIHdoeSB5b3UgbmVl ZCBpdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFdoYXQmbmJzcDsgd291bGQgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGRvIHdpdGggdGhhdCB0eXBlIG9mPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBpbmZvcm1hdGlvbj8gVGhlJm5ic3A7IGRlc2NyaXB0aW9uIGlzIHJh dGhlciBzaG9ydC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBJTUhPIHRoZXJlIGlzIGFsc28gbm8gY2xlYXIgYm91bmRh cnkgYmV0d2VlbiBhICZxdW90O25hdGl2ZSZxdW90OyBhbmQgJnF1b3Q7d2ViJnF1b3Q7IGFwcC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IEp1c3QgdGhpbmsgYWJvdXQgc21h cnQgcGhvbmUgYXBwcyB0aGF0IGFyZSBkZXZlbG9wZWQgdXNpbmcgSmF2YVNjcmlwdC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IFdvdWxkIHRoaXMgYmUgYSB3ZWIgYXBwIG9y IGEgbmF0aXZlIGFwcD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBIZXJlIGlzIHRoZSBkZWZpbml0aW9uIGZyb20gdGhl IGRyYWZ0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7IGFwcGxpY2F0aW9uX3R5cGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9QVElP TkFMLiZuYnNwOyBLaW5kIG9mIHRoZSBhcHBsaWNhdGlvbi4mbmJzcDsgVGhlIGRlZmF1bHQsIGlm IG9taXR0ZWQsIGlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDt3ZWImcXVvdDsuJm5ic3A7IFRoZSBk ZWZpbmVkIHZhbHVlcyBhcmUgJnF1b3Q7bmF0aXZlJnF1b3Q7IG9yICZxdW90O3dlYiZxdW90Oy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyBDaWFvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBIYW5u ZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7IE9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+T0F1dGhAaWV0Zi5vcmc8 L3NwYW4+PC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOk9BdXRoQGll dGYub3JnPC9zcGFuPjwvYT4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAtLTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgTmF0IFNha2ltdXJhICg9bmF0KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8vbmF0LnNha2ltdXJh Lm9yZy88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgQF9uYXRfZW48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsm Z3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O3RleHQtZGVjb3JhdGlvbjpub25lIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVj b3JhdGlvbjpub25lIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyAtLSA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyBOYXQgU2FraW11cmEgKD1u YXQpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsg Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcv Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0 cDovL25hdC5zYWtpbXVyYS5vcmcvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyBAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPk9BdXRoQGlldGYub3Jn PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm Z3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5PQXV0aCBtYWls aW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9 Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_4E1F6AAD24975D4BA5B16804296739439ADDD97CTK5EX14MBXC294r_-- From nobody Wed Jul 23 08:03:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F0E1B2862 for ; Wed, 23 Jul 2014 08:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCgAs8UosyWB for ; Wed, 23 Jul 2014 08:03:22 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4816E1B27D1 for ; Wed, 23 Jul 2014 08:03:21 -0700 (PDT) Received: from [80.67.16.118] (helo=webmail.df.eu) by smtprelay06.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1X9y4c-00011E-Hk; Wed, 23 Jul 2014 17:03:18 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_48c147ae63863446879197b735c012c7" Date: Wed, 23 Jul 2014 11:03:14 -0400 From: torsten@lodderstedt.net To: Mike Jones In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADDD97C@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <201407230115.s6N1FsJe030731@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD97C@TK5EX14MBXC294.redmond.corp.microsoft.com> Message-ID: <0564c72d4764566535d3963bbaa19e2a@lodderstedt.net> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-4VLZ4bekdpJvQ-idsDqYqq0eDQ Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] =?utf-8?q?Dynamic_Client_Registration=3A_application?= =?utf-8?q?=5Ftype?= 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, 23 Jul 2014 15:03:30 -0000 --=_48c147ae63863446879197b735c012c7 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Good point. I don't understand why clients using the implicit response type generally shall be obliged to use HTTPS. Getting rid of this requirement would significantly simplify the text. regards, Torsten. Am 23.07.2014 10:35, schrieb Mike Jones: > It's more complicated than that, as native apps may use the implicit flow and not use https. The set of constraints in the "application_type" definition in OpenID Connect Dynamic Registration are: > > Web Clients using the OAuth Implicit Grant Type MUST only register URLs using the https scheme as redirect_uris; they MUST NOT use localhost as the hostname. Native Clients MUST only register redirect_uris using custom URI schemes or URLs using the http: scheme with localhost as the hostname. Authorization Servers MAY place additional constraints on Native Clients. Authorization Servers MAY reject Redirection URI values using the http scheme, other than the localhost case for Native Clients. > > If we're going to add such constraints, I believe they should be the same ones as the ones above. > > -- Mike > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer > Sent: Tuesday, July 22, 2014 6:16 PM > To: torsten@lodderstedt.net > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type > > I'm ok with that text, and actually thought we had something along those lines already. > > --Justin > > /sent from my phone/ > > On Jul 22, 2014 3:27 PM, torsten@lodderstedt.net wrote: > >> > >> Hi all, > >> > >> I don't think this parameter adds any security (as it is self declarded by the caller). I think the constraints on redirect_uris can be specified without the need for another registration parameter. As far as I understand, they merely depend on the grant type. So we could some text to the redirect_uri parameter definition. Something along the following lines: > >> > >> "All redirect URIs registered for a particular client MUST either (1) use the HTTPS scheme or (2) the HTTP scheme with localhost as the hostname or custom schemes. Additionally, clients using the implict grant type MUST only register URLs using the https scheme as redirect_uris; they MUST NOT use localhost as the hostname." > >> > >> regards, > >> Torsten. > >> > >> Am 08.07.2014 21:35, schrieb Richer, Justin P.: > >>> > >>> Right, that's how it's used in Connect, which defines only redirect-based flows. However, the OAuth version needs to be more general purpose. > >>> > >>> It seems like this parameter really does need more discussion in the group before it should be added to the spec, and therefore I don't think it's appropriate to add it at this stage (post-WGLC). > >>> > >>> -- Justin > >>> > >>> On Jul 8, 2014, at 8:54 PM, Nat Sakimura wrote: > >>> > >>>> If I understand correctly, this parameter is used to appropriately constrain the schema of the Redirect URIs at the time of the registration and is not about fulfilling the Client Type registration requirement in section 2.1. So, making go or no-go decision based on the discussion around section 2.1 probably would not be the way to go. The discussion should happen around the needs on constraining the schema depending on the kind of client. > >>>> > >>>> Apparently, Connect WG perceived that it is a big enough risk that they need to put a plug on based on the risk evaluation as an identity federation protocol. OAuth has different risk profile so it could decide otherwise, but my gut feeling is that unless there is a good reason not to have it, we may as well keep it. > >>>> > >>>> Nat > >>>> > >>>> > >>>> 2014-07-09 7:54 GMT+09:00 Richer, Justin P. : > >>>>> > >>>>> This value was introduced in -18, and it's a direct port from OpenID Connect. It was never in the OAuth Dynamic Registration spec, and though it has been in the OpenID Connect Dynamic Registration spec for a very long time, I think it was a mistake to add it in for several reasons: > >>>>> > >>>>> First, the semantics around its values and use are not clearly defined, for the reasons . I don't see any particular harm in keeping it, but I don't really see what value it adds for clients or server developers. We are in a world where there are OAuth clients that are much more than just "native" or "web". > >>>>> > >>>>> Second, RFC6749 defines "Client Type" in § 2.1 which defines two values: "confidential" and "public", neither of which maps very cleanly to "native" or "web" as stated in -18. This is especially true when you've got dynamic registration that can make native clients confidential with relative ease. We actually take care of registering the "client type" through the use of the "token_endpoint_auth_method" parameter, which is what § 2.1 is really talking about: secure client authentication (to the token endpoint). > >>>>> > >>>>> With this in mind, my preference and suggestion would be to remove this field. If other protocols need it, they can register and define it (like Connect has done). > >>>>> > >>>>> -- Justin > >>>>> > >>>>> > >>>>> On Jul 8, 2014, at 4:38 PM, Mike Jones wrote: > >>>>> > >>>>>> I put it back because otherwise, we wouldn't be meeting one of the requirements of the RFC 6749. If you look at the client registration section http://tools.ietf.org/html/rfc6749#section-2 [1], you'll see that registering redirect_uri values is required, as is registering the client type. Without this, there wasn't a way to register the client type. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- Mike > >>>>>> > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > >>>>>> Sent: Tuesday, July 08, 2014 12:37 PM > >>>>>> To: Phil Hunt > >>>>>> Cc: oauth@ietf.org > >>>>>> Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type > >>>>>> > >>>>>> > >>>>>> > >>>>>> It was taken out and then put back in as it is a common parameter used by a number of AS. > >>>>>> > >>>>>> > >>>>>> > >>>>>> We have it in Connect, the best reason for keeping it is to stop people from coming up with a new parameter for the same thing because they haven't looked at the Connect version. > >>>>>> > >>>>>> > >>>>>> > >>>>>> John B. > >>>>>> > >>>>>> On Jul 8, 2014, at 3:16 PM, Phil Hunt wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Does this need to be in the spec? I believe we've already said that others can add attributes as they need. > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> Phil > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> @independentid > >>>>>> > >>>>>>> www.independentid.com [2] > >>>>>> > >>>>>>> phil.hunt@oracle.com > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>>>> On Jul 8, 2014, at 11:56 AM, John Bradley wrote: > >>>>>> > >>>>>>> > >>>>>> > >>>>>>>> The application_type is collected as part of current registration by Google and some other OAuth providers as part of registering redirect uri. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> The text was cut down to allow more flexibility in OAuth. Connect requires registration of redirect_uri and is more ridged about it than OAuth 2. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> Do you think the Connect wording would be appropriate for OAuth? > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> John B. > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig wrote: > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>>> This additional information makes a lot of sense. > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> As you said in an earlier mail, the attempt to copy text from the > >>>>>> > >>>>>>>>> OpenID Connect spec failed a bit... > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> On 07/08/2014 02:49 PM, Nat Sakimura wrote: > >>>>>> > >>>>>>>>>> I suppose authors has imported one of the security feature of > >>>>>> > >>>>>>>>>> OpenID Connect here as well. In the Dynamic Client Registration > >>>>>> > >>>>>>>>>> standard, which is a bit longer than IETF version. You can see the reason from it: > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> application_type > >>>>>> > >>>>>>>>>> OPTIONAL. Kind of the application. The default, if omitted, is web. > >>>>>> > >>>>>>>>>> The defined values are native or web. Web Clients using the OAuth > >>>>>> > >>>>>>>>>> Implicit Grant Type MUST only register URLs using the https scheme > >>>>>> > >>>>>>>>>> as redirect_uris; they MUST NOT use localhost as the hostname. > >>>>>> > >>>>>>>>>> Native Clients MUST only register redirect_uris using custom URI > >>>>>> > >>>>>>>>>> schemes or URLs using the http: scheme with localhost as the > >>>>>> > >>>>>>>>>> hostname. Authorization Servers MAY place additional constraints on > >>>>>> > >>>>>>>>>> Native Clients. Authorization Servers MAY reject Redirection URI > >>>>>> > >>>>>>>>>> values using the http scheme, other than the localhost case for > >>>>>> > >>>>>>>>>> Native Clients. The Authorization Server MUST verify that all the > >>>>>> > >>>>>>>>>> registered redirect_uris conform to these constraints. This > >>>>>> > >>>>>>>>>> prevents sharing a Client ID across different types of Clients. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Regards, > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Nat > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig > >>>>>> > >>>>>>>>>> >>>>>> > >>>>>>>>>> >: > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Hi all, > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> with version -18 you guys have added a new meta-data attribute, > >>>>>> > >>>>>>>>>> namely application_type. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> First, this new attribute is not listed in the IANA consideration > >>>>>> > >>>>>>>>>> section. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Second, could you provide a bit of motivation why you need it? > >>>>>> > >>>>>>>>>> What would the authorization server do with that type of > >>>>>> > >>>>>>>>>> information? The description is rather short. > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> IMHO there is also no clear boundary between a "native" and "web" app. > >>>>>> > >>>>>>>>>> Just think about smart phone apps that are developed using JavaScript. > >>>>>> > >>>>>>>>>> Would this be a web app or a native app? > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Here is the definition from the draft: > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> application_type > >>>>>> > >>>>>>>>>> OPTIONAL. Kind of the application. The default, if omitted, is > >>>>>> > >>>>>>>>>> "web". The defined values are "native" or "web". > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> Ciao > >>>>>> > >>>>>>>>>> Hannes > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>> > >>>>>>>>>> OAuth mailing list > >>>>>> > >>>>>>>>>> OAuth@ietf.org > >>>>>> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> > >>>>>> > >>>>>>>>>> -- > >>>>>> > >>>>>>>>>> Nat Sakimura (=nat) > >>>>>> > >>>>>>>>>> Chairman, OpenID Foundation > >>>>>> > >>>>>>>>>> http://nat.sakimura.org/ [4] > >>>>>> > >>>>>>>>>> @_nat_en > >>>>>> > >>>>>>>>> > >>>>>> > >>>>>>>>> _______________________________________________ > >>>>>> > >>>>>>>>> OAuth mailing list > >>>>>> > >>>>>>>>> OAuth@ietf.org > >>>>>> > >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] > >>>>>> > >>>>>>>> > >>>>>> > >>>>>>>> _______________________________________________ > >>>>>> > >>>>>>>> OAuth mailing list > >>>>>> > >>>>>>>> OAuth@ietf.org > >>>>>> > >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] > >>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> > >>>>>> OAuth mailing list > >>>>>> > >>>>>> OAuth@ietf.org > >>>>>> > >>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] > >>>>>> > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth [3] > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Nat Sakimura (=nat) > >>>> Chairman, OpenID Foundation > >>>> http://nat.sakimura.org/ [4] > >>>> @_nat_en > >>> > >>> > >>> _______________________________________________ > >>> > >>> OAuth mailing list > >>> > >>> OAuth@ietf.org > >>> > >>> https://www.ietf.org/mailman/listinfo/oauth [3] > >>> > >> > >> > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth [3] Links: ------ [1] http://tools.ietf.org/html/rfc6749#section-2 [2] http://www.independentid.com [3] https://www.ietf.org/mailman/listinfo/oauth [4] http://nat.sakimura.org/ --=_48c147ae63863446879197b735c012c7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Good point. I don't understand why clients using the implicit response t= ype generally shall be obliged to use HTTPS. Getting rid of this requiremen= t would significantly simplify the text.

regards,
Torsten. 

Am 23.07.2014 10:35, schrieb Mike Jones:

It's more complicated than that, as native apps m= ay use the implicit flow and not use https.  The set of constraints in= the "application_type" definition in OpenID Connect Dynamic Registration a= re:

 

Web Clien= ts using the OAuth Implicit Grant Type MUST only register URLs using the https scheme as redi= rect_uris; they MUST NOT use localh= ost as the hostname. Native Clients MUST only regist= er redirect_uris using custom U= RI schemes or URLs using the http:= scheme with localhost as the hostn= ame. Authorization Servers MAY place additional constraints on Native Clien= ts. Authorization Servers MAY reject Redirection URI values using the http scheme, other than the <= span>localhost case for Native Clients.

 

If we're going to add such constraints, I believe= they should be the same ones as the ones above.

 

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

 

-----Original Message-----
From: OAuth [mai= lto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday,= July 22, 2014 6:16 PM
To: torsten@lodderstedt.net
Cc: oauth@ie= tf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: applicati= on_type

 

I'm ok with that text, and actually thought we ha= d something along those lines already.

 

--Justin

 

/sent from my phone/

 

On Jul 22, 2014 3:27 PM, torsten@lodderstedt.net wrote:

> 

> Hi all,

> 

> I don't think this parameter adds any securi= ty (as it is self declarded by the caller). I think the constraints on redi= rect_uris can be specified without the need for another registration parame= ter. As far as I understand, they merely depend on the grant type. So we co= uld some text to the redirect_uri parameter definition. Something along the= following lines:

> 

> "All redirect URIs registered for a particul= ar client MUST either (1) use the HTTPS scheme or (2) the HTTP scheme = with localhost as the hostname or custom schemes. Additionally, clients usi= ng the implict grant type MUST only register URLs using the https sche= me as redirect_uris; they MUST NOT use localhost as the hostname."  

> 

> regards,

> Torsten.

> 

> Am 08.07.2014 21:35, schrieb Richer, Justin = P.:

>> 

>> Right, that's how it's used in Connect, = which defines only redirect-based flows. However, the OAuth version needs t= o be more general purpose. 

>>  

>> It seems like this parameter really does= need more discussion in the group before it should be added to the spec, a= nd therefore I don't think it's appropriate to add it at this stage (post-W= GLC).

>>  

>>  -- Justin

>> 

>> On Jul 8, 2014, at 8:54 PM, Nat Sakimura= <sakimura@gmail.com> wrote:

>> 

>>> If I understand correctly, this para= meter is used to appropriately constrain the schema of the Redirect URIs at= the time of the registration and is not about fulfilling the Client Type r= egistration requirement in section 2.1. So, making go or no-go decision bas= ed on the discussion around section 2.1 probably would not be the way to go= =2E The discussion should happen around the needs on constraining the schem= a depending on the kind of client. 

>>>  

>>> Apparently, Connect WG perceived tha= t it is a big enough risk that they need to put a plug on based on the risk= evaluation as an identity federation protocol. OAuth has different risk pr= ofile so it could decide otherwise, but my gut feeling is that unless there= is a good reason not to have it, we may as well keep it. 

>>>  

>>> Nat

>>> 

>>> 

>>> 2014-07-09 7:54 GMT+09:00 Richer, Ju= stin P. <jricher@mitre.org>:

>>>> 

>>>> This value was introduced in -18= , and it's a direct port from OpenID Connect. It was never in the OAuth Dyn= amic Registration spec, and though it has been in the OpenID Connect Dynami= c Registration spec for a very long time, I think it was a mistake to add i= t in for several reasons: 

>>>>  

>>>> First, the semantics around its = values and use are not clearly defined, for the reasons . I don't see any p= articular harm in keeping it, but I don't really see what value it adds for= clients or server developers. We are in a world where there are OAuth clie= nts that are much more than just "native" or "web".

>>>>  

>>>> Second, RFC6749 defines "Client = Type" in § 2.1 which defines two values: "confidential" and "public", = neither of which maps very cleanly to "native" or "web" as stated in -18. T= his is especially true when you've got dynamic registration that can make n= ative clients confidential with relative ease. We actually take care of reg= istering the "client type" through the use of the "token_endpoint_auth_meth= od" parameter, which is what § 2.1 is really talking about: secure cli= ent authentication (to the token endpoint). 

>>>>  

>>>> With this in mind, my preference= and suggestion would be to remove this field. If other protocols need it, = they can register and define it (like Connect has done).<= /p>

>>>>  

>>>>  -- Justin

>>>> 

>>>> On Jul 8, 2014, at 4:38 PM, Mike= Jones <Michael.Jones@microsoft.com= > wrote:

>>>> 

>>>>> I put it back because otherw= ise, we wouldn't be meeting one of the requirements of the RFC 6749.  = If you look at the client registration section http://tools.ietf.org/html/rfc6749#section-2, you'= ll see that registering redirect_uri values is required, as is registering = the client type.  Without this, there wasn't a way to register the cli= ent type.

>>>>> 

>>>>>  

>>>>> 

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

>>>>> 

>>>>>  

>>>>> 

>>>>> -----Original Message-----

>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradl= ey

>>>>> Sent: Tuesday, July 08, 2014= 12:37 PM

>>>>> To: Phil Hunt

>>>>> Cc: oauth@i= etf.org

>>>>> Subject: Re: [OAUTH-WG] Dyna= mic Client Registration: application_type

>>>>> 

>>>>>  

>>>>> 

>>>>> It was taken out and then pu= t back in as it is a common parameter used by a number of AS.

>>>>> 

>>>>>  

>>>>> 

>>>>> We have it in Connect, the b= est reason for keeping it is to stop people from coming up with a new param= eter for the same thing because they haven't looked at the Connect version= =2E

>>>>> 

>>>>>  

>>>>> 

>>>>> John B.

>>>>> 

>>>>> On Jul 8, 2014, at 3:16 PM, = Phil Hunt <phil.hunt@oracle.com> wr= ote:

>>>>> 

>>>>>  

>>>>> 

>>>>> > Does this need to be in= the spec?  I believe we've already said that others can add attribute= s as they need.

>>>>> 

>>>>> >

>>>>> 

>>>>> > Phil<= /p>

>>>>> 

>>>>> >

>>>>> 

>>>>> > @independentid

>>>>> 

>>>>> > www.independentid.com

>>>>> 

>>>>> > phil.hunt@oracle.com

>>>>> 

>>>>> >

>>>>> 

>>>>> >

>>>>> 

>>>>> >

>>>>> 

>>>>> > On Jul 8, 2014, at 11:5= 6 AM, John Bradley <ve7jtb@ve7jtb.com>= wrote:

>>>>> 

>>>>> >

>>>>> 

>>>>> >> The application_typ= e is collected as part of current registration by Google and some other OAu= th providers as part of registering redirect uri.

>>>>> 

>>>>> >>

>>>>> 

>>>>> >> The text was cut do= wn to allow more flexibility in OAuth.  Connect requires registration = of redirect_uri and is more ridged about it than OAuth 2.=

>>>>> 

>>>>> >>

>>>>> 

>>>>> >> Do you think the Co= nnect wording would be appropriate for OAuth?

>>>>> 

>>>>> >>

>>>>> 

>>>>> >> John B.

>>>>> 

>>>>> >>

>>>>> 

>>>>> >> On Jul 8, 2014, at = 9:22 AM, Hannes Tschofenig <hannes.tschofeni= g@gmx.net> wrote:

>>>>> 

>>>>> >>

>>>>> 

>>>>> >>> This additional= information makes a lot of sense.

>>>>> 

>>>>> >>> 

>>>>> >>> As you said in = an earlier mail, the attempt to copy text from the

>>>>> 

>>>>> >>> OpenID Connect = spec failed a bit...

>>>>> 

>>>>> >>> 

>>>>> >>> On 07/08/2014 0= 2:49 PM, Nat Sakimura wrote:

>>>>> 

>>>>> >>>> I suppose a= uthors has imported one of the security feature of

>>>>> 

>>>>> >>>> OpenID Conn= ect here as well. In the Dynamic Client Registration

>>>>> 

>>>>> >>>> standard, w= hich is a bit longer than IETF version. You can see the reason from it:

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>> application= _type

>>>>> 

>>>>> >>>>  OPTIO= NAL. Kind of the application. The default, if omitted, is web.

>>>>> 

>>>>> >>>>  The d= efined values are native or web. Web Clients using the OAuth 

>>>>> 

>>>>> >>>> Implicit Gr= ant Type MUST only register URLs using the https scheme 

>>>>> 

>>>>> >>>> as redirect= _uris; they MUST NOT use localhost as the hostname.

>>>>> 

>>>>> >>>>  Nativ= e Clients MUST only register redirect_uris using custom URI 

>>>>> 

>>>>> >>>> schemes or = URLs using the http: scheme with localhost as the 

>>>>> 

>>>>> >>>> hostname. A= uthorization Servers MAY place additional constraints on 

>>>>> 

>>>>> >>>> Native Clie= nts. Authorization Servers MAY reject Redirection URI  

>>>>> >>>> values usin= g the http scheme, other than the localhost case for  

>>>>> >>>> Native Clie= nts. The Authorization Server MUST verify that all the 

>>>>> 

>>>>> >>>> registered = redirect_uris conform to these constraints. This

>>>>> 

>>>>> >>>> prevents&nb= sp; sharing a Client ID across different types of Clients. 

>>>>> >>>>

>>>>> 

>>>>> >>>> Regards,

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>> Nat

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>> 2014-07-08 = 21:17 GMT+09:00 Hannes Tschofenig

>>>>> 

>>>>> >>>> <hannes= =2Etschofenig@gmx.net

>>>>> 

>>>>> >>>> <mailto:hannes.tschofenig@gmx.net>>:

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>  Hi al= l,

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>  with = version -18 you guys have added a new meta-data attribute, 

>>>>> >>>> namely = ; application_type.

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>  First= , this new attribute is not listed in the IANA consideration 

>>>>> 

>>>>> >>>> section.

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>  Secon= d, could you provide a bit of motivation why you need it?=

>>>>> 

>>>>> >>>> What  = would the authorization server do with that type of

>>>>> 

>>>>> >>>> information= ? The  description is rather short.

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>  IMHO = there is also no clear boundary between a "native" and "web" app.

>>>>> 

>>>>> >>>>  Just = think about smart phone apps that are developed using JavaScript.

>>>>> 

>>>>> >>>>  Would= this be a web app or a native app?

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>  Here = is the definition from the draft:

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>  appli= cation_type

>>>>> 

>>>>> >>>>  =       OPTIONAL.  Kind of the application.&nbs= p; The default, if omitted, is

>>>>> 

>>>>> >>>>  =       "web".  The defined values are "native"= or "web".

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>  Ciao<= !-- o ignored -->

>>>>> 

>>>>> >>>>  Hanne= s

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>  _____= __________________________________________

>>>>> 

>>>>> >>>>  OAuth= mailing list

>>>>> 

>>>>> >>>>  OAuth@ietf.org <mailto:OAuth@iet= f.org> 

>>>>> 

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

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>>

>>>>> 

>>>>> >>>> --

>>>>> 

>>>>> >>>> Nat Sakimur= a (=3Dnat)

>>>>> 

>>>>> >>>> Chairman, O= penID Foundation

>>>>> 

>>>>> >>>> http://nat.sakimura.org/

>>>>> 

>>>>> >>>> @_nat_en

>>>>> 

>>>>> >>> 

>>>>> >>> _______________= ________________________________

>>>>> 

>>>>> >>> OAuth mailing l= ist

>>>>> 

>>>>> >>> >>>>> 

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

>>>>> 

>>>>> >>

>>>>> 

>>>>> >> ___________________= ____________________________

>>>>> 

>>>>> >> OAuth mailing list<= !-- o ignored -->

>>>>> 

>>>>> >> OA= uth@ietf.org

>>>>> 

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

>>>>> 

>>>>> >

>>>>> 

>>>>>  

>>>>> 

>>>>> ____________________________= ___________________

>>>>> 

>>>>> OAuth mailing list

>>>>> 

>>>>> OAuth@iet= f.org

>>>>> 

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

>>>>> 

>>>>> ____________________________= ___________________

>>>>> OAuth mailing list

>>>>> OAuth@iet= f.org

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

>>>> 

>>>> 

>>>> ________________________________= _______________

>>>> OAuth mailing list

>>>> OAuth@ietf.org<= /span>

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

>>>> 

>>> 

>>> 

>>>  

>>> --

>>> Nat Sakimura (=3Dnat)

>>> Chairman, OpenID Foundation

>>> http://nat.sakim= ura.org/

>>> @_nat_en

>> 

>> 

>> ________________________________________= _______

>> 

>> OAuth mailing list

>> 

>> OAuth@ietf.org

>> 

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

>> 

>  

> 

>  

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://ww= w.ietf.org/mailman/listinfo/oauth

 

 
--=_48c147ae63863446879197b735c012c7-- From nobody Wed Jul 23 08:16:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0981B2862 for ; Wed, 23 Jul 2014 08:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kue7AH7ENPrv for ; Wed, 23 Jul 2014 08:16:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E181B292F for ; Wed, 23 Jul 2014 08:16:21 -0700 (PDT) Received: from BLUPR03CA029.namprd03.prod.outlook.com (10.141.30.22) by BN1PR0301MB0676.namprd03.prod.outlook.com (25.160.171.25) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 15:16:18 +0000 Received: from BY2FFO11FD038.protection.gbl (2a01:111:f400:7c0c::129) by BLUPR03CA029.outlook.office365.com (2a01:111:e400:879::22) with Microsoft SMTP Server (TLS) id 15.0.995.11 via Frontend Transport; Wed, 23 Jul 2014 15:16:18 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD038.mail.protection.outlook.com (10.1.14.223) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 23 Jul 2014 15:16:18 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0195.002; Wed, 23 Jul 2014 15:15:40 +0000 From: Mike Jones To: "torsten@lodderstedt.net" Thread-Topic: [OAUTH-WG] Dynamic Client Registration: application_type Thread-Index: AQHPphOknQrYoKDhtEOe+Pyl9jU/+putue/QgAAIXQCAAAMlMA== Date: Wed, 23 Jul 2014 15:15:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADDDB90@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <201407230115.s6N1FsJe030731@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD97C@TK5EX14MBXC294.redmond.corp.microsoft.com> <0564c72d4764566535d3963bbaa19e2a@lodderstedt.net> In-Reply-To: <0564c72d4764566535d3963bbaa19e2a@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADDDB90TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(377424004)(53754006)(377454003)(51704005)(13464003)(189002)(24454002)(199002)(43544003)(479174003)(55885003)(85306003)(85852003)(95666004)(87936001)(19300405004)(76482001)(92566001)(106116001)(44976005)(19580405001)(81156004)(79102001)(84676001)(92726001)(84326002)(2351001)(512874002)(6806004)(54356999)(83072002)(33656002)(76176999)(106466001)(81542001)(55846006)(50986999)(26826002)(31966008)(19625215002)(16236675004)(99396002)(21056001)(77096002)(86362001)(110136001)(97736001)(86612001)(83322001)(20776003)(69596002)(68736004)(104016003)(15202345003)(46102001)(15975445006)(2656002)(4396001)(16601075003)(66066001)(81342001)(74502001)(64706001)(107046002)(15974865002)(74662001)(71186001)(19580395003)(77982001)(80022001)(19617315012)(559001)(569005); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR0301MB0676; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 028166BF91 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/aycUuESFes9VWNQvvv2t-0JVRAs Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 23 Jul 2014 15:16:32 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADDDB90TK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2ViIGNsaWVudHMgdXNpbmcgdGhlIGltcGxpY2l0IGZsb3cgTVVTVCB1c2UgaHR0cHMgb3IgdGhl IHRva2VucyByZXR1cm5lZCB3b3VsZCBiZSBjb21tdW5pY2F0ZWQgaW4gdGhlIGNsZWFyIG9uIHRo ZSBvcGVuIEludGVybmV0IGZvciBhbnlvbmUgdG8gc25vb3AuICBOb3QgYXQgZ29vZCBpZGVhIQ0K DQpGcm9tOiB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCBbbWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0XQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDg6MDMgQU0NClRvOiBNaWtl IEpvbmVzDQpDYzogSnVzdGluIFJpY2hlcjsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBb T0FVVEgtV0ddIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbjogYXBwbGljYXRpb25fdHlwZQ0K DQoNCkdvb2QgcG9pbnQuIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgY2xpZW50cyB1c2luZyB0aGUg aW1wbGljaXQgcmVzcG9uc2UgdHlwZSBnZW5lcmFsbHkgc2hhbGwgYmUgb2JsaWdlZCB0byB1c2Ug SFRUUFMuIEdldHRpbmcgcmlkIG9mIHRoaXMgcmVxdWlyZW1lbnQgd291bGQgc2lnbmlmaWNhbnRs eSBzaW1wbGlmeSB0aGUgdGV4dC4NCg0KcmVnYXJkcywNClRvcnN0ZW4uDQoNCkFtIDIzLjA3LjIw MTQgMTA6MzUsIHNjaHJpZWIgTWlrZSBKb25lczoNCg0KSXQncyBtb3JlIGNvbXBsaWNhdGVkIHRo YW4gdGhhdCwgYXMgbmF0aXZlIGFwcHMgbWF5IHVzZSB0aGUgaW1wbGljaXQgZmxvdyBhbmQgbm90 IHVzZSBodHRwcy4gIFRoZSBzZXQgb2YgY29uc3RyYWludHMgaW4gdGhlICJhcHBsaWNhdGlvbl90 eXBlIiBkZWZpbml0aW9uIGluIE9wZW5JRCBDb25uZWN0IER5bmFtaWMgUmVnaXN0cmF0aW9uIGFy ZToNCg0KDQoNCldlYiBDbGllbnRzIHVzaW5nIHRoZSBPQXV0aCBJbXBsaWNpdCBHcmFudCBUeXBl IE1VU1Qgb25seSByZWdpc3RlciBVUkxzIHVzaW5nIHRoZSBodHRwcyBzY2hlbWUgYXMgcmVkaXJl Y3RfdXJpczsgdGhleSBNVVNUIE5PVCB1c2UgbG9jYWxob3N0IGFzIHRoZSBob3N0bmFtZS4gTmF0 aXZlIENsaWVudHMgTVVTVCBvbmx5IHJlZ2lzdGVyIHJlZGlyZWN0X3VyaXMgdXNpbmcgY3VzdG9t IFVSSSBzY2hlbWVzIG9yIFVSTHMgdXNpbmcgdGhlIGh0dHA6IHNjaGVtZSB3aXRoIGxvY2FsaG9z dCBhcyB0aGUgaG9zdG5hbWUuIEF1dGhvcml6YXRpb24gU2VydmVycyBNQVkgcGxhY2UgYWRkaXRp b25hbCBjb25zdHJhaW50cyBvbiBOYXRpdmUgQ2xpZW50cy4gQXV0aG9yaXphdGlvbiBTZXJ2ZXJz IE1BWSByZWplY3QgUmVkaXJlY3Rpb24gVVJJIHZhbHVlcyB1c2luZyB0aGUgaHR0cCBzY2hlbWUs IG90aGVyIHRoYW4gdGhlIGxvY2FsaG9zdCBjYXNlIGZvciBOYXRpdmUgQ2xpZW50cy4NCg0KDQoN CklmIHdlJ3JlIGdvaW5nIHRvIGFkZCBzdWNoIGNvbnN0cmFpbnRzLCBJIGJlbGlldmUgdGhleSBz aG91bGQgYmUgdGhlIHNhbWUgb25lcyBhcyB0aGUgb25lcyBhYm92ZS4NCg0KDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1p a2UNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gUmljaGVyDQpTZW50 OiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0IDY6MTYgUE0NClRvOiB0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+DQpDYzogb2F1dGhAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gRHluYW1pYyBD bGllbnQgUmVnaXN0cmF0aW9uOiBhcHBsaWNhdGlvbl90eXBlDQoNCg0KDQpJJ20gb2sgd2l0aCB0 aGF0IHRleHQsIGFuZCBhY3R1YWxseSB0aG91Z2h0IHdlIGhhZCBzb21ldGhpbmcgYWxvbmcgdGhv c2UgbGluZXMgYWxyZWFkeS4NCg0KDQoNCi0tSnVzdGluDQoNCg0KDQovc2VudCBmcm9tIG15IHBo b25lLw0KDQoNCg0KT24gSnVsIDIyLCAyMDE0IDM6MjcgUE0sIHRvcnN0ZW5AbG9kZGVyc3RlZHQu bmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6DQoNCj4NCg0KPiBIaSBh bGwsDQoNCj4NCg0KPiBJIGRvbid0IHRoaW5rIHRoaXMgcGFyYW1ldGVyIGFkZHMgYW55IHNlY3Vy aXR5IChhcyBpdCBpcyBzZWxmIGRlY2xhcmRlZCBieSB0aGUgY2FsbGVyKS4gSSB0aGluayB0aGUg Y29uc3RyYWludHMgb24gcmVkaXJlY3RfdXJpcyBjYW4gYmUgc3BlY2lmaWVkIHdpdGhvdXQgdGhl IG5lZWQgZm9yIGFub3RoZXIgcmVnaXN0cmF0aW9uIHBhcmFtZXRlci4gQXMgZmFyIGFzIEkgdW5k ZXJzdGFuZCwgdGhleSBtZXJlbHkgZGVwZW5kIG9uIHRoZSBncmFudCB0eXBlLiBTbyB3ZSBjb3Vs ZCBzb21lIHRleHQgdG8gdGhlIHJlZGlyZWN0X3VyaSBwYXJhbWV0ZXIgZGVmaW5pdGlvbi4gU29t ZXRoaW5nIGFsb25nIHRoZSBmb2xsb3dpbmcgbGluZXM6DQoNCj4NCg0KPiAiQWxsIHJlZGlyZWN0 IFVSSXMgcmVnaXN0ZXJlZCBmb3IgYSBwYXJ0aWN1bGFyIGNsaWVudCBNVVNUIGVpdGhlciAoMSkg dXNlIHRoZSBIVFRQUyBzY2hlbWUgb3IgKDIpIHRoZSBIVFRQIHNjaGVtZSB3aXRoIGxvY2FsaG9z dCBhcyB0aGUgaG9zdG5hbWUgb3IgY3VzdG9tIHNjaGVtZXMuIEFkZGl0aW9uYWxseSwgY2xpZW50 cyB1c2luZyB0aGUgaW1wbGljdCBncmFudCB0eXBlIE1VU1Qgb25seSByZWdpc3RlciBVUkxzIHVz aW5nIHRoZSBodHRwcyBzY2hlbWUgYXMgcmVkaXJlY3RfdXJpczsgdGhleSBNVVNUIE5PVCB1c2Ug bG9jYWxob3N0IGFzIHRoZSBob3N0bmFtZS4iDQoNCj4NCg0KPiByZWdhcmRzLA0KDQo+IFRvcnN0 ZW4uDQoNCj4NCg0KPiBBbSAwOC4wNy4yMDE0IDIxOjM1LCBzY2hyaWViIFJpY2hlciwgSnVzdGlu IFAuOg0KDQo+Pg0KDQo+PiBSaWdodCwgdGhhdCdzIGhvdyBpdCdzIHVzZWQgaW4gQ29ubmVjdCwg d2hpY2ggZGVmaW5lcyBvbmx5IHJlZGlyZWN0LWJhc2VkIGZsb3dzLiBIb3dldmVyLCB0aGUgT0F1 dGggdmVyc2lvbiBuZWVkcyB0byBiZSBtb3JlIGdlbmVyYWwgcHVycG9zZS4NCg0KPj4NCg0KPj4g SXQgc2VlbXMgbGlrZSB0aGlzIHBhcmFtZXRlciByZWFsbHkgZG9lcyBuZWVkIG1vcmUgZGlzY3Vz c2lvbiBpbiB0aGUgZ3JvdXAgYmVmb3JlIGl0IHNob3VsZCBiZSBhZGRlZCB0byB0aGUgc3BlYywg YW5kIHRoZXJlZm9yZSBJIGRvbid0IHRoaW5rIGl0J3MgYXBwcm9wcmlhdGUgdG8gYWRkIGl0IGF0 IHRoaXMgc3RhZ2UgKHBvc3QtV0dMQykuDQoNCj4+DQoNCj4+ICAtLSBKdXN0aW4NCg0KPj4NCg0K Pj4gT24gSnVsIDgsIDIwMTQsIGF0IDg6NTQgUE0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21h aWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCg0KPj4NCg0KPj4+IElm IEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHRoaXMgcGFyYW1ldGVyIGlzIHVzZWQgdG8gYXBwcm9w cmlhdGVseSBjb25zdHJhaW4gdGhlIHNjaGVtYSBvZiB0aGUgUmVkaXJlY3QgVVJJcyBhdCB0aGUg dGltZSBvZiB0aGUgcmVnaXN0cmF0aW9uIGFuZCBpcyBub3QgYWJvdXQgZnVsZmlsbGluZyB0aGUg Q2xpZW50IFR5cGUgcmVnaXN0cmF0aW9uIHJlcXVpcmVtZW50IGluIHNlY3Rpb24gMi4xLiBTbywg bWFraW5nIGdvIG9yIG5vLWdvIGRlY2lzaW9uIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIGFyb3Vu ZCBzZWN0aW9uIDIuMSBwcm9iYWJseSB3b3VsZCBub3QgYmUgdGhlIHdheSB0byBnby4gVGhlIGRp c2N1c3Npb24gc2hvdWxkIGhhcHBlbiBhcm91bmQgdGhlIG5lZWRzIG9uIGNvbnN0cmFpbmluZyB0 aGUgc2NoZW1hIGRlcGVuZGluZyBvbiB0aGUga2luZCBvZiBjbGllbnQuDQoNCj4+Pg0KDQo+Pj4g QXBwYXJlbnRseSwgQ29ubmVjdCBXRyBwZXJjZWl2ZWQgdGhhdCBpdCBpcyBhIGJpZyBlbm91Z2gg cmlzayB0aGF0IHRoZXkgbmVlZCB0byBwdXQgYSBwbHVnIG9uIGJhc2VkIG9uIHRoZSByaXNrIGV2 YWx1YXRpb24gYXMgYW4gaWRlbnRpdHkgZmVkZXJhdGlvbiBwcm90b2NvbC4gT0F1dGggaGFzIGRp ZmZlcmVudCByaXNrIHByb2ZpbGUgc28gaXQgY291bGQgZGVjaWRlIG90aGVyd2lzZSwgYnV0IG15 IGd1dCBmZWVsaW5nIGlzIHRoYXQgdW5sZXNzIHRoZXJlIGlzIGEgZ29vZCByZWFzb24gbm90IHRv IGhhdmUgaXQsIHdlIG1heSBhcyB3ZWxsIGtlZXAgaXQuDQoNCj4+Pg0KDQo+Pj4gTmF0DQoNCj4+ Pg0KDQo+Pj4NCg0KPj4+IDIwMTQtMDctMDkgNzo1NCBHTVQrMDk6MDAgUmljaGVyLCBKdXN0aW4g UC4gPGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+Og0KDQo+Pj4+ DQoNCj4+Pj4gVGhpcyB2YWx1ZSB3YXMgaW50cm9kdWNlZCBpbiAtMTgsIGFuZCBpdCdzIGEgZGly ZWN0IHBvcnQgZnJvbSBPcGVuSUQgQ29ubmVjdC4gSXQgd2FzIG5ldmVyIGluIHRoZSBPQXV0aCBE eW5hbWljIFJlZ2lzdHJhdGlvbiBzcGVjLCBhbmQgdGhvdWdoIGl0IGhhcyBiZWVuIGluIHRoZSBP cGVuSUQgQ29ubmVjdCBEeW5hbWljIFJlZ2lzdHJhdGlvbiBzcGVjIGZvciBhIHZlcnkgbG9uZyB0 aW1lLCBJIHRoaW5rIGl0IHdhcyBhIG1pc3Rha2UgdG8gYWRkIGl0IGluIGZvciBzZXZlcmFsIHJl YXNvbnM6DQoNCj4+Pj4NCg0KPj4+PiBGaXJzdCwgdGhlIHNlbWFudGljcyBhcm91bmQgaXRzIHZh bHVlcyBhbmQgdXNlIGFyZSBub3QgY2xlYXJseSBkZWZpbmVkLCBmb3IgdGhlIHJlYXNvbnMgLiBJ IGRvbid0IHNlZSBhbnkgcGFydGljdWxhciBoYXJtIGluIGtlZXBpbmcgaXQsIGJ1dCBJIGRvbid0 IHJlYWxseSBzZWUgd2hhdCB2YWx1ZSBpdCBhZGRzIGZvciBjbGllbnRzIG9yIHNlcnZlciBkZXZl bG9wZXJzLiBXZSBhcmUgaW4gYSB3b3JsZCB3aGVyZSB0aGVyZSBhcmUgT0F1dGggY2xpZW50cyB0 aGF0IGFyZSBtdWNoIG1vcmUgdGhhbiBqdXN0ICJuYXRpdmUiIG9yICJ3ZWIiLg0KDQo+Pj4+DQoN Cj4+Pj4gU2Vjb25kLCBSRkM2NzQ5IGRlZmluZXMgIkNsaWVudCBUeXBlIiBpbiDCpyAyLjEgd2hp Y2ggZGVmaW5lcyB0d28gdmFsdWVzOiAiY29uZmlkZW50aWFsIiBhbmQgInB1YmxpYyIsIG5laXRo ZXIgb2Ygd2hpY2ggbWFwcyB2ZXJ5IGNsZWFubHkgdG8gIm5hdGl2ZSIgb3IgIndlYiIgYXMgc3Rh dGVkIGluIC0xOC4gVGhpcyBpcyBlc3BlY2lhbGx5IHRydWUgd2hlbiB5b3UndmUgZ290IGR5bmFt aWMgcmVnaXN0cmF0aW9uIHRoYXQgY2FuIG1ha2UgbmF0aXZlIGNsaWVudHMgY29uZmlkZW50aWFs IHdpdGggcmVsYXRpdmUgZWFzZS4gV2UgYWN0dWFsbHkgdGFrZSBjYXJlIG9mIHJlZ2lzdGVyaW5n IHRoZSAiY2xpZW50IHR5cGUiIHRocm91Z2ggdGhlIHVzZSBvZiB0aGUgInRva2VuX2VuZHBvaW50 X2F1dGhfbWV0aG9kIiBwYXJhbWV0ZXIsIHdoaWNoIGlzIHdoYXQgwqcgMi4xIGlzIHJlYWxseSB0 YWxraW5nIGFib3V0OiBzZWN1cmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uICh0byB0aGUgdG9rZW4g ZW5kcG9pbnQpLg0KDQo+Pj4+DQoNCj4+Pj4gV2l0aCB0aGlzIGluIG1pbmQsIG15IHByZWZlcmVu Y2UgYW5kIHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gcmVtb3ZlIHRoaXMgZmllbGQuIElmIG90aGVy IHByb3RvY29scyBuZWVkIGl0LCB0aGV5IGNhbiByZWdpc3RlciBhbmQgZGVmaW5lIGl0IChsaWtl IENvbm5lY3QgaGFzIGRvbmUpLg0KDQo+Pj4+DQoNCj4+Pj4gIC0tIEp1c3Rpbg0KDQo+Pj4+DQoN Cj4+Pj4NCg0KPj4+PiBPbiBKdWwgOCwgMjAxNCwgYXQgNDozOCBQTSwgTWlrZSBKb25lcyA8TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b20+PiB3cm90ZToNCg0KPj4+Pg0KDQo+Pj4+PiBJIHB1dCBpdCBiYWNrIGJlY2F1c2Ugb3RoZXJ3 aXNlLCB3ZSB3b3VsZG4ndCBiZSBtZWV0aW5nIG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIG9mIHRo ZSBSRkMgNjc0OS4gIElmIHlvdSBsb29rIGF0IHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIHNlY3Rp b24gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTIsIHlvdSdsbCBz ZWUgdGhhdCByZWdpc3RlcmluZyByZWRpcmVjdF91cmkgdmFsdWVzIGlzIHJlcXVpcmVkLCBhcyBp cyByZWdpc3RlcmluZyB0aGUgY2xpZW50IHR5cGUuICBXaXRob3V0IHRoaXMsIHRoZXJlIHdhc24n dCBhIHdheSB0byByZWdpc3RlciB0aGUgY2xpZW50IHR5cGUuDQoNCj4+Pj4+DQoNCj4+Pj4+DQoN Cj4+Pj4+DQoNCj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KPj4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4NCg0K Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPj4+Pj4gRnJvbTogT0F1dGggW21h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5DQoN Cj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDgsIDIwMTQgMTI6MzcgUE0NCg0KPj4+Pj4gVG86 IFBoaWwgSHVudA0KDQo+Pj4+PiBDYzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYu b3JnPg0KDQo+Pj4+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBEeW5hbWljIENsaWVudCBSZWdp c3RyYXRpb246IGFwcGxpY2F0aW9uX3R5cGUNCg0KPj4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4NCg0K Pj4+Pj4gSXQgd2FzIHRha2VuIG91dCBhbmQgdGhlbiBwdXQgYmFjayBpbiBhcyBpdCBpcyBhIGNv bW1vbiBwYXJhbWV0ZXIgdXNlZCBieSBhIG51bWJlciBvZiBBUy4NCg0KPj4+Pj4NCg0KPj4+Pj4N Cg0KPj4+Pj4NCg0KPj4+Pj4gV2UgaGF2ZSBpdCBpbiBDb25uZWN0LCB0aGUgYmVzdCByZWFzb24g Zm9yIGtlZXBpbmcgaXQgaXMgdG8gc3RvcCBwZW9wbGUgZnJvbSBjb21pbmcgdXAgd2l0aCBhIG5l dyBwYXJhbWV0ZXIgZm9yIHRoZSBzYW1lIHRoaW5nIGJlY2F1c2UgdGhleSBoYXZlbid0IGxvb2tl ZCBhdCB0aGUgQ29ubmVjdCB2ZXJzaW9uLg0KDQo+Pj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+Pg0KDQo+ Pj4+PiBKb2huIEIuDQoNCj4+Pj4+DQoNCj4+Pj4+IE9uIEp1bCA4LCAyMDE0LCBhdCAzOjE2IFBN LCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbT4+IHdyb3RlOg0KDQo+Pj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+IERvZXMg dGhpcyBuZWVkIHRvIGJlIGluIHRoZSBzcGVjPyAgSSBiZWxpZXZlIHdlJ3ZlIGFscmVhZHkgc2Fp ZCB0aGF0IG90aGVycyBjYW4gYWRkIGF0dHJpYnV0ZXMgYXMgdGhleSBuZWVkLg0KDQo+Pj4+Pg0K DQo+Pj4+PiA+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4gUGhpbA0KDQo+Pj4+Pg0KDQo+Pj4+PiA+DQoN Cj4+Pj4+DQoNCj4+Pj4+ID4gQGluZGVwZW5kZW50aWQNCg0KPj4+Pj4NCg0KPj4+Pj4gPiB3d3cu aW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4NCg0KPj4+Pj4N Cg0KPj4+Pj4gPiBwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5j b20+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4NCg0KPj4+Pj4NCg0KPj4+Pj4gPg0KDQo+Pj4+Pg0KDQo+ Pj4+PiA+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4gT24gSnVsIDgsIDIwMTQsIGF0IDExOjU2IEFNLCBK b2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+ IHdyb3RlOg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+IFRoZSBhcHBs aWNhdGlvbl90eXBlIGlzIGNvbGxlY3RlZCBhcyBwYXJ0IG9mIGN1cnJlbnQgcmVnaXN0cmF0aW9u IGJ5IEdvb2dsZSBhbmQgc29tZSBvdGhlciBPQXV0aCBwcm92aWRlcnMgYXMgcGFydCBvZiByZWdp c3RlcmluZyByZWRpcmVjdCB1cmkuDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+DQoNCj4+Pj4+DQoNCj4+ Pj4+ID4+IFRoZSB0ZXh0IHdhcyBjdXQgZG93biB0byBhbGxvdyBtb3JlIGZsZXhpYmlsaXR5IGlu IE9BdXRoLiAgQ29ubmVjdCByZXF1aXJlcyByZWdpc3RyYXRpb24gb2YgcmVkaXJlY3RfdXJpIGFu ZCBpcyBtb3JlIHJpZGdlZCBhYm91dCBpdCB0aGFuIE9BdXRoIDIuDQoNCj4+Pj4+DQoNCj4+Pj4+ ID4+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+IERvIHlvdSB0aGluayB0aGUgQ29ubmVjdCB3b3JkaW5n IHdvdWxkIGJlIGFwcHJvcHJpYXRlIGZvciBPQXV0aD8NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4NCg0K Pj4+Pj4NCg0KPj4+Pj4gPj4gSm9obiBCLg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pg0KDQo+Pj4+Pg0K DQo+Pj4+PiA+PiBPbiBKdWwgOCwgMjAxNCwgYXQgOToyMiBBTSwgSGFubmVzIFRzY2hvZmVuaWcg PGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQ+PiB3cm90ZToNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+IFRo aXMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBtYWtlcyBhIGxvdCBvZiBzZW5zZS4NCg0KPj4+Pj4N Cg0KPj4+Pj4gPj4+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+PiBBcyB5b3Ugc2FpZCBpbiBhbiBlYXJs aWVyIG1haWwsIHRoZSBhdHRlbXB0IHRvIGNvcHkgdGV4dCBmcm9tIHRoZQ0KDQo+Pj4+Pg0KDQo+ Pj4+PiA+Pj4gT3BlbklEIENvbm5lY3Qgc3BlYyBmYWlsZWQgYSBiaXQuLi4NCg0KPj4+Pj4NCg0K Pj4+Pj4gPj4+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+PiBPbiAwNy8wOC8yMDE0IDAyOjQ5IFBNLCBO YXQgU2FraW11cmEgd3JvdGU6DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gSSBzdXBwb3NlIGF1dGhv cnMgaGFzIGltcG9ydGVkIG9uZSBvZiB0aGUgc2VjdXJpdHkgZmVhdHVyZSBvZg0KDQo+Pj4+Pg0K DQo+Pj4+PiA+Pj4+IE9wZW5JRCBDb25uZWN0IGhlcmUgYXMgd2VsbC4gSW4gdGhlIER5bmFtaWMg Q2xpZW50IFJlZ2lzdHJhdGlvbg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+IHN0YW5kYXJkLCB3aGlj aCBpcyBhIGJpdCBsb25nZXIgdGhhbiBJRVRGIHZlcnNpb24uIFlvdSBjYW4gc2VlIHRoZSByZWFz b24gZnJvbSBpdDoNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+ IGFwcGxpY2F0aW9uX3R5cGUNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiAgT1BUSU9OQUwuIEtpbmQg b2YgdGhlIGFwcGxpY2F0aW9uLiBUaGUgZGVmYXVsdCwgaWYgb21pdHRlZCwgaXMgd2ViLg0KDQo+ Pj4+Pg0KDQo+Pj4+PiA+Pj4+ICBUaGUgZGVmaW5lZCB2YWx1ZXMgYXJlIG5hdGl2ZSBvciB3ZWIu IFdlYiBDbGllbnRzIHVzaW5nIHRoZSBPQXV0aA0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+IEltcGxp Y2l0IEdyYW50IFR5cGUgTVVTVCBvbmx5IHJlZ2lzdGVyIFVSTHMgdXNpbmcgdGhlIGh0dHBzIHNj aGVtZQ0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+IGFzIHJlZGlyZWN0X3VyaXM7IHRoZXkgTVVTVCBO T1QgdXNlIGxvY2FsaG9zdCBhcyB0aGUgaG9zdG5hbWUuDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4g IE5hdGl2ZSBDbGllbnRzIE1VU1Qgb25seSByZWdpc3RlciByZWRpcmVjdF91cmlzIHVzaW5nIGN1 c3RvbSBVUkkNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiBzY2hlbWVzIG9yIFVSTHMgdXNpbmcgdGhl IGh0dHA6IHNjaGVtZSB3aXRoIGxvY2FsaG9zdCBhcyB0aGUNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+ PiBob3N0bmFtZS4gQXV0aG9yaXphdGlvbiBTZXJ2ZXJzIE1BWSBwbGFjZSBhZGRpdGlvbmFsIGNv bnN0cmFpbnRzIG9uDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gTmF0aXZlIENsaWVudHMuIEF1dGhv cml6YXRpb24gU2VydmVycyBNQVkgcmVqZWN0IFJlZGlyZWN0aW9uIFVSSQ0KDQo+Pj4+Pg0KDQo+ Pj4+PiA+Pj4+IHZhbHVlcyB1c2luZyB0aGUgaHR0cCBzY2hlbWUsIG90aGVyIHRoYW4gdGhlIGxv Y2FsaG9zdCBjYXNlIGZvcg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+IE5hdGl2ZSBDbGllbnRzLiBU aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhhdCBhbGwgdGhlDQoNCj4+Pj4+ DQoNCj4+Pj4+ID4+Pj4gcmVnaXN0ZXJlZCByZWRpcmVjdF91cmlzIGNvbmZvcm0gdG8gdGhlc2Ug Y29uc3RyYWludHMuIFRoaXMNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiBwcmV2ZW50cyAgc2hhcmlu ZyBhIENsaWVudCBJRCBhY3Jvc3MgZGlmZmVyZW50IHR5cGVzIG9mIENsaWVudHMuDQoNCj4+Pj4+ DQoNCj4+Pj4+ID4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiBSZWdhcmRzLA0KDQo+Pj4+Pg0K DQo+Pj4+PiA+Pj4+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gTmF0DQoNCj4+Pj4+DQoNCj4+Pj4+ ID4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+IDIwMTQt MDctMDggMjE6MTcgR01UKzA5OjAwIEhhbm5lcyBUc2Nob2ZlbmlnDQoNCj4+Pj4+DQoNCj4+Pj4+ ID4+Pj4gPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiA8 bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+PjoNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+ Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+ICBIaSBhbGwsDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4N Cg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiAgd2l0aCB2ZXJzaW9uIC0xOCB5b3UgZ3V5cyBoYXZlIGFk ZGVkIGEgbmV3IG1ldGEtZGF0YSBhdHRyaWJ1dGUsDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gbmFt ZWx5ICBhcHBsaWNhdGlvbl90eXBlLg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+DQoNCj4+Pj4+DQoN Cj4+Pj4+ID4+Pj4gIEZpcnN0LCB0aGlzIG5ldyBhdHRyaWJ1dGUgaXMgbm90IGxpc3RlZCBpbiB0 aGUgSUFOQSBjb25zaWRlcmF0aW9uDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gc2VjdGlvbi4NCg0K Pj4+Pj4NCg0KPj4+Pj4gPj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+ICBTZWNvbmQsIGNvdWxk IHlvdSBwcm92aWRlIGEgYml0IG9mIG1vdGl2YXRpb24gd2h5IHlvdSBuZWVkIGl0Pw0KDQo+Pj4+ Pg0KDQo+Pj4+PiA+Pj4+IFdoYXQgIHdvdWxkIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkbyB3 aXRoIHRoYXQgdHlwZSBvZg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+IGluZm9ybWF0aW9uPyBUaGUg IGRlc2NyaXB0aW9uIGlzIHJhdGhlciBzaG9ydC4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+Pg0KDQo+ Pj4+Pg0KDQo+Pj4+PiA+Pj4+ICBJTUhPIHRoZXJlIGlzIGFsc28gbm8gY2xlYXIgYm91bmRhcnkg YmV0d2VlbiBhICJuYXRpdmUiIGFuZCAid2ViIiBhcHAuDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4g IEp1c3QgdGhpbmsgYWJvdXQgc21hcnQgcGhvbmUgYXBwcyB0aGF0IGFyZSBkZXZlbG9wZWQgdXNp bmcgSmF2YVNjcmlwdC4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiAgV291bGQgdGhpcyBiZSBhIHdl YiBhcHAgb3IgYSBuYXRpdmUgYXBwPw0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+DQoNCj4+Pj4+DQoN Cj4+Pj4+ID4+Pj4gIEhlcmUgaXMgdGhlIGRlZmluaXRpb24gZnJvbSB0aGUgZHJhZnQ6DQoNCj4+ Pj4+DQoNCj4+Pj4+ID4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiAgYXBwbGljYXRpb25fdHlw ZQ0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+ICAgICAgICBPUFRJT05BTC4gIEtpbmQgb2YgdGhlIGFw cGxpY2F0aW9uLiAgVGhlIGRlZmF1bHQsIGlmIG9taXR0ZWQsIGlzDQoNCj4+Pj4+DQoNCj4+Pj4+ ID4+Pj4gICAgICAgICJ3ZWIiLiAgVGhlIGRlZmluZWQgdmFsdWVzIGFyZSAibmF0aXZlIiBvciAi d2ViIi4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+Pg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+ICBDaWFv DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gIEhhbm5lcw0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+DQoN Cj4+Pj4+DQoNCj4+Pj4+ID4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+PiAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+ PiAgT0F1dGggbWFpbGluZyBsaXN0DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4gIE9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4gPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KPj4+ Pj4NCg0KPj4+Pj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+Pg0KDQo+Pj4+ Pg0KDQo+Pj4+PiA+Pj4+DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4g Pj4+PiAtLQ0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4+IE5hdCBTYWtpbXVyYSAoPW5hdCkNCg0KPj4+ Pj4NCg0KPj4+Pj4gPj4+PiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCg0KPj4+Pj4NCg0K Pj4+Pj4gPj4+PiBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+ PiBAX25hdF9lbg0KDQo+Pj4+Pg0KDQo+Pj4+PiA+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4+Pj4+DQoN Cj4+Pj4+ID4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+IE9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KPj4+Pj4NCg0KPj4+ Pj4gPj4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4gT0F1dGggbWFpbGluZyBsaXN0 DQoNCj4+Pj4+DQoNCj4+Pj4+ID4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCg0KPj4+Pj4NCg0KPj4+Pj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aA0KDQo+Pj4+Pg0KDQo+Pj4+PiA+DQoNCj4+Pj4+DQoNCj4+Pj4+DQoNCj4+Pj4+ DQoNCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCj4+Pj4+DQoNCj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KDQo+Pj4+Pg0KDQo+Pj4+PiBP QXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCj4+Pj4+DQoNCj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KPj4+Pj4NCg0KPj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPj4+ Pj4gT0F1dGggbWFpbGluZyBsaXN0DQoNCj4+Pj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCg0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KDQo+Pj4+DQoNCj4+Pj4NCg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQo+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KDQo+Pj4+ IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KPj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCj4+Pj4NCg0KPj4+DQoNCj4+Pg0K DQo+Pj4NCg0KPj4+IC0tDQoNCj4+PiBOYXQgU2FraW11cmEgKD1uYXQpDQoNCj4+PiBDaGFpcm1h biwgT3BlbklEIEZvdW5kYXRpb24NCg0KPj4+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KDQo+ Pj4gQF9uYXRfZW4NCg0KPj4NCg0KPj4NCg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KPj4NCg0KPj4gT0F1dGggbWFpbGluZyBsaXN0DQoNCj4+ DQoNCj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KPj4NCg0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo+Pg0KDQo+DQoN Cj4NCg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoN Cg0KDQo= --_000_4E1F6AAD24975D4BA5B16804296739439ADDDB90TK5EX14MBXC294r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2Ut MToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnANCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q29u c29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlYiBjbGllbnRzIHVz aW5nIHRoZSBpbXBsaWNpdCBmbG93IE1VU1QgdXNlIGh0dHBzIG9yIHRoZSB0b2tlbnMgcmV0dXJu ZWQgd291bGQgYmUgY29tbXVuaWNhdGVkIGluIHRoZSBjbGVhciBvbiB0aGUgb3BlbiBJbnRlcm5l dCBmb3IgYW55b25lIHRvIHNub29wLiZuYnNwOyBOb3QNCiBhdCBnb29kIGlkZWEhPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQgW21haWx0bzp0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQg ODowMyBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gSnVzdGlu IFJpY2hlcjsgb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtPQVVUSC1X R10gRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uOiBhcHBsaWNhdGlvbl90eXBlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkdvb2Qg cG9pbnQuIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgY2xpZW50cyB1c2luZyB0aGUgaW1wbGljaXQg cmVzcG9uc2UgdHlwZSBnZW5lcmFsbHkgc2hhbGwgYmUgb2JsaWdlZCB0byB1c2UgSFRUUFMuIEdl dHRpbmcgcmlkIG9mIHRoaXMgcmVxdWlyZW1lbnQgd291bGQgc2lnbmlmaWNhbnRseSBzaW1wbGlm eSB0aGUgdGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+cmVnYXJkcyw8YnI+DQpUb3JzdGVuLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5BbSAyMy4wNy4yMDE0IDEw OjM1LCBzY2hyaWViIE1pa2UgSm9uZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SXQncyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4g dGhhdCwgYXMgbmF0aXZlIGFwcHMgbWF5IHVzZSB0aGUgaW1wbGljaXQgZmxvdyBhbmQgbm90IHVz ZSBodHRwcy4mbmJzcDsgVGhlIHNldCBvZiBjb25zdHJhaW50cyBpbiB0aGUgJnF1b3Q7YXBwbGlj YXRpb25fdHlwZSZxdW90OyBkZWZpbml0aW9uIGluIE9wZW5JRCBDb25uZWN0IER5bmFtaWMgUmVn aXN0cmF0aW9uIGFyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+V2ViIENsaWVudHMgdXNp bmcgdGhlIE9BdXRoIEltcGxpY2l0IEdyYW50IFR5cGUgTVVTVCBvbmx5IHJlZ2lzdGVyIFVSTHMg dXNpbmcgdGhlDQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5odHRw czwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IHNj aGVtZSBhcw0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+cmVkaXJl Y3RfdXJpczwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+OyB0aGV5IE1VU1QgTk9UIHVzZQ0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+bG9jYWxob3N0PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4gYXMgdGhlIGhvc3RuYW1lLiBOYXRpdmUgQ2xpZW50cyBNVVNUIG9ubHkg cmVnaXN0ZXINCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPnJlZGly ZWN0X3VyaXM8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiB1c2luZyBjdXN0b20gVVJJIHNjaGVtZXMgb3IgVVJMcyB1c2luZyB0aGUNCjwvc3Bhbj48 dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmh0dHA6PC9zcGFuPjwvdHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gc2NoZW1lIHdpdGgNCjwvc3Bhbj48 dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmxvY2FsaG9zdDwvc3Bhbj48L3R0Pjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IGFzIHRoZSBob3N0bmFtZS4g QXV0aG9yaXphdGlvbiBTZXJ2ZXJzIE1BWSBwbGFjZSBhZGRpdGlvbmFsIGNvbnN0cmFpbnRzIG9u IE5hdGl2ZSBDbGllbnRzLiBBdXRob3JpemF0aW9uIFNlcnZlcnMgTUFZDQogcmVqZWN0IFJlZGly ZWN0aW9uIFVSSSB2YWx1ZXMgdXNpbmcgdGhlIDwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPmh0dHA8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiBzY2hlbWUsIG90aGVyIHRoYW4gdGhlDQo8L3NwYW4+PHR0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij5sb2NhbGhvc3Q8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiBjYXNlIGZvciBOYXRpdmUgQ2xpZW50cy48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SWYgd2UncmUgZ29pbmcgdG8gYWRkIHN1Y2ggY29u c3RyYWludHMsIEkgYmVsaWV2ZSB0aGV5IHNob3VsZCBiZSB0aGUgc2FtZSBvbmVzIGFzIHRoZSBv bmVzIGFib3ZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogT0F1 dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBKdXN0aW4gUmljaGVyPGJyPg0KU2Vu dDogVHVlc2RheSwgSnVseSAyMiwgMjAxNCA2OjE2IFBNPGJyPg0KVG86IDxhIGhyZWY9Im1haWx0 bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+PGJy Pg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9u OiBhcHBsaWNhdGlvbl90eXBlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5JJ20gb2sgd2l0aCB0aGF0IHRleHQsIGFuZCBhY3R1YWxseSB0aG91Z2h0IHdl IGhhZCBzb21ldGhpbmcgYWxvbmcgdGhvc2UgbGluZXMgYWxyZWFkeS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi0tSnVzdGluPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4vc2VudCBmcm9tIG15IHBob25lLzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+T24gSnVsIDIy LCAyMDE0IDM6MjcgUE0sIDxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+dG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQ8L3NwYW4+PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IEhpIGFsbCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IEkgZG9uJ3Qg dGhpbmsgdGhpcyBwYXJhbWV0ZXIgYWRkcyBhbnkgc2VjdXJpdHkgKGFzIGl0IGlzIHNlbGYgZGVj bGFyZGVkIGJ5IHRoZSBjYWxsZXIpLiBJIHRoaW5rIHRoZSBjb25zdHJhaW50cyBvbiByZWRpcmVj dF91cmlzIGNhbiBiZSBzcGVjaWZpZWQgd2l0aG91dCB0aGUgbmVlZCBmb3IgYW5vdGhlciByZWdp c3RyYXRpb24gcGFyYW1ldGVyLiBBcw0KIGZhciBhcyBJIHVuZGVyc3RhbmQsIHRoZXkgbWVyZWx5 IGRlcGVuZCBvbiB0aGUgZ3JhbnQgdHlwZS4gU28gd2UgY291bGQgc29tZSB0ZXh0IHRvIHRoZSBy ZWRpcmVjdF91cmkgcGFyYW1ldGVyIGRlZmluaXRpb24uIFNvbWV0aGluZyBhbG9uZyB0aGUgZm9s bG93aW5nIGxpbmVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZndDsgJnF1b3Q7QWxsIHJlZGlyZWN0IFVSSXMgcmVnaXN0ZXJlZCBmb3IgYSBw YXJ0aWN1bGFyIGNsaWVudCBNVVNUIGVpdGhlciAoMSkgdXNlIHRoZSZuYnNwO0hUVFBTIHNjaGVt ZSBvciAoMikgdGhlIEhUVFAgc2NoZW1lIHdpdGggbG9jYWxob3N0IGFzIHRoZSBob3N0bmFtZSBv ciBjdXN0b20gc2NoZW1lcy4gQWRkaXRpb25hbGx5LCBjbGllbnRzIHVzaW5nIHRoZSBpbXBsaWN0 Jm5ic3A7Z3JhbnQNCiB0eXBlIE1VU1Qgb25seSByZWdpc3RlciBVUkxzIHVzaW5nIHRoZSBodHRw cyBzY2hlbWUgYXMgcmVkaXJlY3RfdXJpczsgdGhleSBNVVNUIE5PVCB1c2UgbG9jYWxob3N0IGFz IHRoZSBob3N0bmFtZS4mcXVvdDsgJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mZ3Q7IFRvcnN0ZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jmd0OyBBbSAwOC4wNy4yMDE0IDIxOjM1LCBzY2hyaWViIFJpY2hlciwgSnVz dGluIFAuOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7Jmd0OyBSaWdodCwgdGhhdCdzIGhvdyBpdCdzIHVzZWQgaW4gQ29ubmVjdCwg d2hpY2ggZGVmaW5lcyBvbmx5IHJlZGlyZWN0LWJhc2VkIGZsb3dzLiBIb3dldmVyLCB0aGUgT0F1 dGggdmVyc2lvbiBuZWVkcyB0byBiZSBtb3JlIGdlbmVyYWwgcHVycG9zZS4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jmd0OyZndDsgJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsm Z3Q7IEl0IHNlZW1zIGxpa2UgdGhpcyBwYXJhbWV0ZXIgcmVhbGx5IGRvZXMgbmVlZCBtb3JlIGRp c2N1c3Npb24gaW4gdGhlIGdyb3VwIGJlZm9yZSBpdCBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIHNw ZWMsIGFuZCB0aGVyZWZvcmUgSSBkb24ndCB0aGluayBpdCdzIGFwcHJvcHJpYXRlIHRvIGFkZCBp dCBhdCB0aGlzIHN0YWdlIChwb3N0LVdHTEMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0 OyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsgJm5ic3A7LS0gSnVzdGluPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZn dDsmZ3Q7IE9uIEp1bCA4LCAyMDE0LCBhdCA4OjU0IFBNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhy ZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5zYWtpbXVyYUBnbWFpbC5jb208L3NwYW4+PC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyBJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB0aGlzIHBh cmFtZXRlciBpcyB1c2VkIHRvIGFwcHJvcHJpYXRlbHkgY29uc3RyYWluIHRoZSBzY2hlbWEgb2Yg dGhlIFJlZGlyZWN0IFVSSXMgYXQgdGhlIHRpbWUgb2YgdGhlIHJlZ2lzdHJhdGlvbiBhbmQgaXMg bm90IGFib3V0IGZ1bGZpbGxpbmcgdGhlIENsaWVudCBUeXBlIHJlZ2lzdHJhdGlvbg0KIHJlcXVp cmVtZW50IGluIHNlY3Rpb24gMi4xLiBTbywgbWFraW5nIGdvIG9yIG5vLWdvIGRlY2lzaW9uIGJh c2VkIG9uIHRoZSBkaXNjdXNzaW9uIGFyb3VuZCBzZWN0aW9uIDIuMSBwcm9iYWJseSB3b3VsZCBu b3QgYmUgdGhlIHdheSB0byBnby4gVGhlIGRpc2N1c3Npb24gc2hvdWxkIGhhcHBlbiBhcm91bmQg dGhlIG5lZWRzIG9uIGNvbnN0cmFpbmluZyB0aGUgc2NoZW1hIGRlcGVuZGluZyBvbiB0aGUga2lu ZCBvZiBjbGllbnQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyAmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7IEFwcGFyZW50bHksIENvbm5lY3Qg V0cgcGVyY2VpdmVkIHRoYXQgaXQgaXMgYSBiaWcgZW5vdWdoIHJpc2sgdGhhdCB0aGV5IG5lZWQg dG8gcHV0IGEgcGx1ZyBvbiBiYXNlZCBvbiB0aGUgcmlzayBldmFsdWF0aW9uIGFzIGFuIGlkZW50 aXR5IGZlZGVyYXRpb24gcHJvdG9jb2wuIE9BdXRoIGhhcyBkaWZmZXJlbnQgcmlzayBwcm9maWxl IHNvIGl0DQogY291bGQgZGVjaWRlIG90aGVyd2lzZSwgYnV0IG15IGd1dCBmZWVsaW5nIGlzIHRo YXQgdW5sZXNzIHRoZXJlIGlzIGEgZ29vZCByZWFzb24gbm90IHRvIGhhdmUgaXQsIHdlIG1heSBh cyB3ZWxsIGtlZXAgaXQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyAm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7IE5hdDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsm Z3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyAyMDE0LTA3LTA5IDc6 NTQgR01UJiM0MzswOTowMCBSaWNoZXIsIEp1c3RpbiBQLiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpy aWNoZXJAbWl0cmUub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y YXRpb246bm9uZSI+anJpY2hlckBtaXRyZS5vcmc8L3NwYW4+PC9hPiZndDs6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0 OyZndDsmZ3Q7Jmd0OyBUaGlzIHZhbHVlIHdhcyBpbnRyb2R1Y2VkIGluIC0xOCwgYW5kIGl0J3Mg YSBkaXJlY3QgcG9ydCBmcm9tIE9wZW5JRCBDb25uZWN0LiBJdCB3YXMgbmV2ZXIgaW4gdGhlIE9B dXRoIER5bmFtaWMgUmVnaXN0cmF0aW9uIHNwZWMsIGFuZCB0aG91Z2ggaXQgaGFzIGJlZW4gaW4g dGhlIE9wZW5JRCBDb25uZWN0IER5bmFtaWMgUmVnaXN0cmF0aW9uDQogc3BlYyBmb3IgYSB2ZXJ5 IGxvbmcgdGltZSwgSSB0aGluayBpdCB3YXMgYSBtaXN0YWtlIHRvIGFkZCBpdCBpbiBmb3Igc2V2 ZXJhbCByZWFzb25zOiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7 ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IEZpcnN0LCB0aGUg c2VtYW50aWNzIGFyb3VuZCBpdHMgdmFsdWVzIGFuZCB1c2UgYXJlIG5vdCBjbGVhcmx5IGRlZmlu ZWQsIGZvciB0aGUgcmVhc29ucyAuIEkgZG9uJ3Qgc2VlIGFueSBwYXJ0aWN1bGFyIGhhcm0gaW4g a2VlcGluZyBpdCwgYnV0IEkgZG9uJ3QgcmVhbGx5IHNlZSB3aGF0IHZhbHVlIGl0IGFkZHMgZm9y IGNsaWVudHMgb3Igc2VydmVyDQogZGV2ZWxvcGVycy4gV2UgYXJlIGluIGEgd29ybGQgd2hlcmUg dGhlcmUgYXJlIE9BdXRoIGNsaWVudHMgdGhhdCBhcmUgbXVjaCBtb3JlIHRoYW4ganVzdCAmcXVv dDtuYXRpdmUmcXVvdDsgb3IgJnF1b3Q7d2ViJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7IFNlY29uZCwgUkZDNjc0OSBkZWZpbmVzICZxdW90O0NsaWVudCBUeXBlJnF1b3Q7IGluIMKn IDIuMSB3aGljaCBkZWZpbmVzIHR3byB2YWx1ZXM6ICZxdW90O2NvbmZpZGVudGlhbCZxdW90OyBh bmQgJnF1b3Q7cHVibGljJnF1b3Q7LCBuZWl0aGVyIG9mIHdoaWNoIG1hcHMgdmVyeSBjbGVhbmx5 IHRvICZxdW90O25hdGl2ZSZxdW90OyBvciAmcXVvdDt3ZWImcXVvdDsgYXMgc3RhdGVkIGluIC0x OC4gVGhpcyBpcyBlc3BlY2lhbGx5IHRydWUNCiB3aGVuIHlvdSd2ZSBnb3QgZHluYW1pYyByZWdp c3RyYXRpb24gdGhhdCBjYW4gbWFrZSBuYXRpdmUgY2xpZW50cyBjb25maWRlbnRpYWwgd2l0aCBy ZWxhdGl2ZSBlYXNlLiBXZSBhY3R1YWxseSB0YWtlIGNhcmUgb2YgcmVnaXN0ZXJpbmcgdGhlICZx dW90O2NsaWVudCB0eXBlJnF1b3Q7IHRocm91Z2ggdGhlIHVzZSBvZiB0aGUgJnF1b3Q7dG9rZW5f ZW5kcG9pbnRfYXV0aF9tZXRob2QmcXVvdDsgcGFyYW1ldGVyLCB3aGljaCBpcyB3aGF0IMKnIDIu MSBpcyByZWFsbHkgdGFsa2luZyBhYm91dDoNCiBzZWN1cmUgY2xpZW50IGF1dGhlbnRpY2F0aW9u ICh0byB0aGUgdG9rZW4gZW5kcG9pbnQpLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7 IFdpdGggdGhpcyBpbiBtaW5kLCBteSBwcmVmZXJlbmNlIGFuZCBzdWdnZXN0aW9uIHdvdWxkIGJl IHRvIHJlbW92ZSB0aGlzIGZpZWxkLiBJZiBvdGhlciBwcm90b2NvbHMgbmVlZCBpdCwgdGhleSBj YW4gcmVnaXN0ZXIgYW5kIGRlZmluZSBpdCAobGlrZSBDb25uZWN0IGhhcyBkb25lKS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDstLSBKdXN0aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IE9uIEp1bCA4 LCAyMDE0LCBhdCA0OjM4IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgcHV0IGl0IGJhY2sgYmVj YXVzZSBvdGhlcndpc2UsIHdlIHdvdWxkbid0IGJlIG1lZXRpbmcgb25lIG9mIHRoZSByZXF1aXJl bWVudHMgb2YgdGhlIFJGQyA2NzQ5LiZuYnNwOyBJZiB5b3UgbG9vayBhdCB0aGUgY2xpZW50IHJl Z2lzdHJhdGlvbiBzZWN0aW9uDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM2NzQ5I3NlY3Rpb24tMiI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0y PC9zcGFuPjwvYT4sIHlvdSdsbCBzZWUgdGhhdCByZWdpc3RlcmluZyByZWRpcmVjdF91cmkgdmFs dWVzIGlzIHJlcXVpcmVkLCBhcyBpcyByZWdpc3RlcmluZyB0aGUgY2xpZW50IHR5cGUuJm5ic3A7 DQogV2l0aG91dCB0aGlzLCB0aGVyZSB3YXNuJ3QgYSB3YXkgdG8gcmVnaXN0ZXIgdGhlIGNsaWVu dCB0eXBlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IEZyb206IE9BdXRoIFs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dIE9uIEJlaGFs ZiBPZiBKb2huIEJyYWRsZXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgU2VudDogVHVlc2RheSwgSnVseSAwOCwgMjAxNCAxMjozNyBQTTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUbzogUGhpbCBIdW50PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v cmciPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi Pm9hdXRoQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtPQVVUSC1XR10gRHluYW1pYyBDbGllbnQgUmVnaXN0 cmF0aW9uOiBhcHBsaWNhdGlvbl90eXBlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCB3YXMgdGFrZW4gb3V0 IGFuZCB0aGVuIHB1dCBiYWNrIGluIGFzIGl0IGlzIGEgY29tbW9uIHBhcmFtZXRlciB1c2VkIGJ5 IGEgbnVtYmVyIG9mIEFTLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2UgaGF2ZSBpdCBpbiBDb25uZWN0LCB0 aGUgYmVzdCByZWFzb24gZm9yIGtlZXBpbmcgaXQgaXMgdG8gc3RvcCBwZW9wbGUgZnJvbSBjb21p bmcgdXAgd2l0aCBhIG5ldyBwYXJhbWV0ZXIgZm9yIHRoZSBzYW1lIHRoaW5nIGJlY2F1c2UgdGhl eSBoYXZlbid0IGxvb2tlZCBhdCB0aGUgQ29ubmVjdCB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Sm9obiBCLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBKdWwgOCwgMjAxNCwg YXQgMzoxNiBQTSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsgRG9lcyB0aGlzIG5lZWQgdG8gYmUgaW4gdGhlIHNwZWM/Jm5ic3A7IEkgYmVsaWV2 ZSB3ZSd2ZSBhbHJlYWR5IHNhaWQgdGhhdCBvdGhlcnMgY2FuIGFkZCBhdHRyaWJ1dGVzIGFzIHRo ZXkgbmVlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7IFBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7IEBpbmRl cGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsgPGEgaHJlZj0i aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyBPbiBKdWwgOCwgMjAxNCwgYXQgMTE6NTYg QU0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+dmU3anRi QHZlN2p0Yi5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg VGhlIGFwcGxpY2F0aW9uX3R5cGUgaXMgY29sbGVjdGVkIGFzIHBhcnQgb2YgY3VycmVudCByZWdp c3RyYXRpb24gYnkgR29vZ2xlIGFuZCBzb21lIG90aGVyIE9BdXRoIHByb3ZpZGVycyBhcyBwYXJ0 IG9mIHJlZ2lzdGVyaW5nIHJlZGlyZWN0IHVyaS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg VGhlIHRleHQgd2FzIGN1dCBkb3duIHRvIGFsbG93IG1vcmUgZmxleGliaWxpdHkgaW4gT0F1dGgu Jm5ic3A7IENvbm5lY3QgcmVxdWlyZXMgcmVnaXN0cmF0aW9uIG9mIHJlZGlyZWN0X3VyaSBhbmQg aXMgbW9yZSByaWRnZWQgYWJvdXQgaXQgdGhhbiBPQXV0aCAyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBEbyB5b3UgdGhpbmsgdGhlIENvbm5lY3Qgd29yZGluZyB3b3VsZCBiZSBhcHByb3By aWF0ZSBmb3IgT0F1dGg/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEpvaG4gQi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgT24gSnVsIDgsIDIwMTQsIGF0IDk6MjIgQU0sIEhhbm5lcyBU c2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmhhbm5l cy50c2Nob2ZlbmlnQGdteC5uZXQ8L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBUaGlzIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gbWFrZXMgYSBsb3Qg b2Ygc2Vuc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgQXMgeW91IHNhaWQg aW4gYW4gZWFybGllciBtYWlsLCB0aGUgYXR0ZW1wdCB0byBjb3B5IHRleHQgZnJvbSB0aGU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IE9wZW5JRCBDb25uZWN0 IHNwZWMgZmFpbGVkIGEgYml0Li4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg T24gMDcvMDgvMjAxNCAwMjo0OSBQTSwgTmF0IFNha2ltdXJhIHdyb3RlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEkgc3VwcG9zZSBhdXRob3JzIGhh cyBpbXBvcnRlZCBvbmUgb2YgdGhlIHNlY3VyaXR5IGZlYXR1cmUgb2Y8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBPcGVuSUQgQ29ubmVjdCBoZXJlIGFz IHdlbGwuIEluIHRoZSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBzdGFuZGFyZCwgd2hpY2ggaXMgYSBi aXQgbG9uZ2VyIHRoYW4gSUVURiB2ZXJzaW9uLiBZb3UgY2FuIHNlZSB0aGUgcmVhc29uIGZyb20g aXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcHBsaWNhdGlv bl90eXBlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsgT1BUSU9OQUwuIEtpbmQgb2YgdGhlIGFwcGxpY2F0aW9uLiBUaGUgZGVmYXVsdCwgaWYg b21pdHRlZCwgaXMgd2ViLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7IFRoZSBkZWZpbmVkIHZhbHVlcyBhcmUgbmF0aXZlIG9yIHdlYi4gV2Vi IENsaWVudHMgdXNpbmcgdGhlIE9BdXRoJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgSW1wbGljaXQgR3JhbnQgVHlwZSBNVVNUIG9ubHkgcmVn aXN0ZXIgVVJMcyB1c2luZyB0aGUgaHR0cHMgc2NoZW1lJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXMgcmVkaXJlY3RfdXJpczsgdGhleSBN VVNUIE5PVCB1c2UgbG9jYWxob3N0IGFzIHRoZSBob3N0bmFtZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBOYXRpdmUgQ2xpZW50cyBNVVNU IG9ubHkgcmVnaXN0ZXIgcmVkaXJlY3RfdXJpcyB1c2luZyBjdXN0b20gVVJJJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgc2NoZW1lcyBvciBV UkxzIHVzaW5nIHRoZSBodHRwOiBzY2hlbWUgd2l0aCBsb2NhbGhvc3QgYXMgdGhlJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgaG9zdG5hbWUu IEF1dGhvcml6YXRpb24gU2VydmVycyBNQVkgcGxhY2UgYWRkaXRpb25hbCBjb25zdHJhaW50cyBv biZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IE5hdGl2ZSBDbGllbnRzLiBBdXRob3JpemF0aW9uIFNlcnZlcnMgTUFZIHJlamVjdCBSZWRpcmVj dGlvbiBVUkkmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyB2YWx1ZXMgdXNpbmcgdGhlIGh0dHAgc2NoZW1lLCBvdGhlciB0aGFuIHRoZSBsb2Nh bGhvc3QgY2FzZSBmb3ImbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBOYXRpdmUgQ2xpZW50cy4gVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1V U1QgdmVyaWZ5IHRoYXQgYWxsIHRoZSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZ2lzdGVyZWQgcmVkaXJlY3RfdXJpcyBjb25mb3JtIHRv IHRoZXNlIGNvbnN0cmFpbnRzLiBUaGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgcHJldmVudHMmbmJzcDsgc2hhcmluZyBhIENsaWVudCBJRCBhY3Jv c3MgZGlmZmVyZW50IHR5cGVzIG9mIENsaWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgTmF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDIwMTQt MDctMDggMjE6MTcgR01UJiM0MzswOTowMCBIYW5uZXMgVHNjaG9mZW5pZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDtoYW5uZXMudHNjaG9mZW5p Z0BnbXgubmV0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Ij48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmhhbm5l cy50c2Nob2ZlbmlnQGdteC5uZXQ8L3NwYW4+PC9hPiZndDsmZ3Q7OjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgSGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgd2l0aCB2ZXJzaW9uIC0xOCB5b3UgZ3V5 cyBoYXZlIGFkZGVkIGEgbmV3IG1ldGEtZGF0YSBhdHRyaWJ1dGUsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgbmFtZWx5Jm5ic3A7IGFwcGxpY2F0aW9u X3R5cGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBG aXJzdCwgdGhpcyBuZXcgYXR0cmlidXRlIGlzIG5vdCBsaXN0ZWQgaW4gdGhlIElBTkEgY29uc2lk ZXJhdGlvbiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IHNlY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyBTZWNvbmQsIGNvdWxkIHlvdSBwcm92aWRlIGEgYml0IG9mIG1vdGl2YXRpb24gd2h5 IHlvdSBuZWVkIGl0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IFdoYXQmbmJzcDsgd291bGQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRvIHdpdGgg dGhhdCB0eXBlIG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgaW5mb3JtYXRpb24/IFRoZSZuYnNwOyBkZXNjcmlwdGlvbiBpcyByYXRoZXIgc2hvcnQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBJTUhPIHRo ZXJlIGlzIGFsc28gbm8gY2xlYXIgYm91bmRhcnkgYmV0d2VlbiBhICZxdW90O25hdGl2ZSZxdW90 OyBhbmQgJnF1b3Q7d2ViJnF1b3Q7IGFwcC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBKdXN0IHRoaW5rIGFib3V0IHNtYXJ0IHBob25lIGFw cHMgdGhhdCBhcmUgZGV2ZWxvcGVkIHVzaW5nIEphdmFTY3JpcHQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgV291bGQgdGhpcyBiZSBhIHdl YiBhcHAgb3IgYSBuYXRpdmUgYXBwPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsgSGVyZSBpcyB0aGUgZGVmaW5pdGlvbiBmcm9tIHRoZSBkcmFmdDo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IGFwcGxpY2F0aW9u X3R5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPUFRJT05BTC4mbmJzcDsg S2luZCBvZiB0aGUgYXBwbGljYXRpb24uJm5ic3A7IFRoZSBkZWZhdWx0LCBpZiBvbWl0dGVkLCBp czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3dlYiZxdW90Oy4mbmJz cDsgVGhlIGRlZmluZWQgdmFsdWVzIGFyZSAmcXVvdDtuYXRpdmUmcXVvdDsgb3IgJnF1b3Q7d2Vi JnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsg Q2lhbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7IEhhbm5lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IE9BdXRoIG1haWxpbmcg bGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9h PiAmbHQ7PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOk9BdXRoQGlldGYub3JnPC9z cGFuPjwvYT4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAtLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE5hdCBTYWtpbXVyYSAoPW5hdCk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBDaGFpcm1hbiwgT3BlbklEIEZvdW5k YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8 YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwv c3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgQF9uYXRfZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5PQXV0aEBp ZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj4NCjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5PQXV0aEBpZXRmLm9yZzwv c3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPg0KPHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5n IGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZn dDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZn dDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+DQo8c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPg0KPHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+Jmd0OyZndDsmZ3Q7ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0 OyZndDsgLS0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyBOYXQgU2FraW11cmEg KD1uYXQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jmd0OyBDaGFpcm1hbiwgT3BlbklE IEZvdW5kYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0 dHA6Ly9uYXQuc2FraW11cmEub3JnLyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmZ3Q7IEBfbmF0X2VuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7Jmd0 OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9u ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiZndDsgJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+Jmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+T0F1 dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439ADDDB90TK5EX14MBXC294r_-- From nobody Wed Jul 23 09:04:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058091B2ADA for ; Wed, 23 Jul 2014 09:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5oMS8T_DtwN for ; Wed, 23 Jul 2014 09:03:50 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B909E1B2ACC for ; Wed, 23 Jul 2014 09:03:49 -0700 (PDT) Received: from [80.67.16.118] (helo=webmail.df.eu) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1X9z18-00070U-Nx; Wed, 23 Jul 2014 18:03:46 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_87bbe385d9731b0f6e03495610db3958" Date: Wed, 23 Jul 2014 12:03:46 -0400 From: torsten@lodderstedt.net To: Mike Jones In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADDDB90@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <201407230115.s6N1FsJe030731@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD97C@TK5EX14MBXC294.redmond.corp.microsoft.com> <0564c72d4764566535d3963bbaa19e2a@lodderstedt.net> <4E1F6AAD24975D4BA5B16804296739439ADDDB90@TK5EX14MBXC294.redmond.corp.microsoft.com> Message-ID: <0226e80f13102c2074f1e74abaf37ef3@lodderstedt.net> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CUpGUv5He0NM0Wm2VKo0sGRORZ0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] =?utf-8?q?Dynamic_Client_Registration=3A_application?= =?utf-8?q?=5Ftype?= 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, 23 Jul 2014 16:03:55 -0000 --=_87bbe385d9731b0f6e03495610db3958 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 I thought the fragment is only delivered to the client on the AS leg, meaning if the AS uses HTTPS everything is secure. Am 23.07.2014 11:15, schrieb Mike Jones: > Web clients using the implicit flow MUST use https or the tokens returned would be communicated in the clear on the open Internet for anyone to snoop. Not at good idea! > > FROM: torsten@lodderstedt.net [mailto:torsten@lodderstedt.net] > SENT: Wednesday, July 23, 2014 8:03 AM > TO: Mike Jones > CC: Justin Richer; oauth@ietf.org > SUBJECT: RE: [OAUTH-WG] Dynamic Client Registration: application_type > > Good point. I don't understand why clients using the implicit response type generally shall be obliged to use HTTPS. Getting rid of this requirement would significantly simplify the text. > > regards, > Torsten. > > Am 23.07.2014 10:35, schrieb Mike Jones: > >> It's more complicated than that, as native apps may use the implicit flow and not use https. The set of constraints in the "application_type" definition in OpenID Connect Dynamic Registration are: >> >> Web Clients using the OAuth Implicit Grant Type MUST only register URLs using the https scheme as redirect_uris; they MUST NOT use localhost as the hostname. Native Clients MUST only register redirect_uris using custom URI schemes or URLs using the http: scheme with localhost as the hostname. Authorization Servers MAY place additional constraints on Native Clients. Authorization Servers MAY reject Redirection URI values using the http scheme, other than the localhost case for Native Clients. >> >> If we're going to add such constraints, I believe they should be the same ones as the ones above. >> >> -- Mike >> >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer >> Sent: Tuesday, July 22, 2014 6:16 PM >> To: torsten@lodderstedt.net >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type >> >> I'm ok with that text, and actually thought we had something along those lines already. >> >> --Justin >> >> /sent from my phone/ >> >> On Jul 22, 2014 3:27 PM, torsten@lodderstedt.net wrote: >> >>> >> >>> Hi all, >> >>> >> >>> I don't think this parameter adds any security (as it is self declarded by the caller). I think the constraints on redirect_uris can be specified without the need for another registration parameter. As far as I understand, they merely depend on the grant type. So we could some text to the redirect_uri parameter definition. Something along the following lines: >> >>> >> >>> "All redirect URIs registered for a particular client MUST either (1) use the HTTPS scheme or (2) the HTTP scheme with localhost as the hostname or custom schemes. Additionally, clients using the implict grant type MUST only register URLs using the https scheme as redirect_uris; they MUST NOT use localhost as the hostname." >> >>> >> >>> regards, >> >>> Torsten. >> >>> >> >>> Am 08.07.2014 21:35, schrieb Richer, Justin P.: >> >>>> >> >>>> Right, that's how it's used in Connect, which defines only redirect-based flows. However, the OAuth version needs to be more general purpose. >> >>>> >> >>>> It seems like this parameter really does need more discussion in the group before it should be added to the spec, and therefore I don't think it's appropriate to add it at this stage (post-WGLC). >> >>>> >> >>>> -- Justin >> >>>> >> >>>> On Jul 8, 2014, at 8:54 PM, Nat Sakimura wrote: >> >>>> >> >>>>> If I understand correctly, this parameter is used to appropriately constrain the schema of the Redirect URIs at the time of the registration and is not about fulfilling the Client Type registration requirement in section 2.1. So, making go or no-go decision based on the discussion around section 2.1 probably would not be the way to go. The discussion should happen around the needs on constraining the schema depending on the kind of client. >> >>>>> >> >>>>> Apparently, Connect WG perceived that it is a big enough risk that they need to put a plug on based on the risk evaluation as an identity federation protocol. OAuth has different risk profile so it could decide otherwise, but my gut feeling is that unless there is a good reason not to have it, we may as well keep it. >> >>>>> >> >>>>> Nat >> >>>>> >> >>>>> >> >>>>> 2014-07-09 7:54 GMT+09:00 Richer, Justin P. : >> >>>>>> >> >>>>>> This value was introduced in -18, and it's a direct port from OpenID Connect. It was never in the OAuth Dynamic Registration spec, and though it has been in the OpenID Connect Dynamic Registration spec for a very long time, I think it was a mistake to add it in for several reasons: >> >>>>>> >> >>>>>> First, the semantics around its values and use are not clearly defined, for the reasons . I don't see any particular harm in keeping it, but I don't really see what value it adds for clients or server developers. We are in a world where there are OAuth clients that are much more than just "native" or "web". >> >>>>>> >> >>>>>> Second, RFC6749 defines "Client Type" in § 2.1 which defines two values: "confidential" and "public", neither of which maps very cleanly to "native" or "web" as stated in -18. This is especially true when you've got dynamic registration that can make native clients confidential with relative ease. We actually take care of registering the "client type" through the use of the "token_endpoint_auth_method" parameter, which is what § 2.1 is really talking about: secure client authentication (to the token endpoint). >> >>>>>> >> >>>>>> With this in mind, my preference and suggestion would be to remove this field. If other protocols need it, they can register and define it (like Connect has done). >> >>>>>> >> >>>>>> -- Justin >> >>>>>> >> >>>>>> >> >>>>>> On Jul 8, 2014, at 4:38 PM, Mike Jones wrote: >> >>>>>> >> >>>>>>> I put it back because otherwise, we wouldn't be meeting one of the requirements of the RFC 6749. If you look at the client registration section http://tools.ietf.org/html/rfc6749#section-2 [1], you'll see that registering redirect_uri values is required, as is registering the client type. Without this, there wasn't a way to register the client type. >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> -- Mike >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley >> >>>>>>> Sent: Tuesday, July 08, 2014 12:37 PM >> >>>>>>> To: Phil Hunt >> >>>>>>> Cc: oauth@ietf.org >> >>>>>>> Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> It was taken out and then put back in as it is a common parameter used by a number of AS. >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> We have it in Connect, the best reason for keeping it is to stop people from coming up with a new parameter for the same thing because they haven't looked at the Connect version. >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> John B. >> >>>>>>> >> >>>>>>> On Jul 8, 2014, at 3:16 PM, Phil Hunt wrote: >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>>> Does this need to be in the spec? I believe we've already said that others can add attributes as they need. >> >>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>>>> Phil >> >>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>>>> @independentid >> >>>>>>> >> >>>>>>>> www.independentid.com [2] >> >>>>>>> >> >>>>>>>> phil.hunt@oracle.com >> >>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>>>> On Jul 8, 2014, at 11:56 AM, John Bradley wrote: >> >>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>>>>> The application_type is collected as part of current registration by Google and some other OAuth providers as part of registering redirect uri. >> >>>>>>> >> >>>>>>>>> >> >>>>>>> >> >>>>>>>>> The text was cut down to allow more flexibility in OAuth. Connect requires registration of redirect_uri and is more ridged about it than OAuth 2. >> >>>>>>> >> >>>>>>>>> >> >>>>>>> >> >>>>>>>>> Do you think the Connect wording would be appropriate for OAuth? >> >>>>>>> >> >>>>>>>>> >> >>>>>>> >> >>>>>>>>> John B. >> >>>>>>> >> >>>>>>>>> >> >>>>>>> >> >>>>>>>>> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig wrote: >> >>>>>>> >> >>>>>>>>> >> >>>>>>> >> >>>>>>>>>> This additional information makes a lot of sense. >> >>>>>>> >> >>>>>>>>>> >> >>>>>>> >> >>>>>>>>>> As you said in an earlier mail, the attempt to copy text from the >> >>>>>>> >> >>>>>>>>>> OpenID Connect spec failed a bit... >> >>>>>>> >> >>>>>>>>>> >> >>>>>>> >> >>>>>>>>>> On 07/08/2014 02:49 PM, Nat Sakimura wrote: >> >>>>>>> >> >>>>>>>>>>> I suppose authors has imported one of the security feature of >> >>>>>>> >> >>>>>>>>>>> OpenID Connect here as well. In the Dynamic Client Registration >> >>>>>>> >> >>>>>>>>>>> standard, which is a bit longer than IETF version. You can see the reason from it: >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> application_type >> >>>>>>> >> >>>>>>>>>>> OPTIONAL. Kind of the application. The default, if omitted, is web. >> >>>>>>> >> >>>>>>>>>>> The defined values are native or web. Web Clients using the OAuth >> >>>>>>> >> >>>>>>>>>>> Implicit Grant Type MUST only register URLs using the https scheme >> >>>>>>> >> >>>>>>>>>>> as redirect_uris; they MUST NOT use localhost as the hostname. >> >>>>>>> >> >>>>>>>>>>> Native Clients MUST only register redirect_uris using custom URI >> >>>>>>> >> >>>>>>>>>>> schemes or URLs using the http: scheme with localhost as the >> >>>>>>> >> >>>>>>>>>>> hostname. Authorization Servers MAY place additional constraints on >> >>>>>>> >> >>>>>>>>>>> Native Clients. Authorization Servers MAY reject Redirection URI >> >>>>>>> >> >>>>>>>>>>> values using the http scheme, other than the localhost case for >> >>>>>>> >> >>>>>>>>>>> Native Clients. The Authorization Server MUST verify that all the >> >>>>>>> >> >>>>>>>>>>> registered redirect_uris conform to these constraints. This >> >>>>>>> >> >>>>>>>>>>> prevents sharing a Client ID across different types of Clients. >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> Regards, >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> Nat >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig >> >>>>>>> >> >>>>>>>>>>> > >>>>>>> >> >>>>>>>>>>> >: >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> Hi all, >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> with version -18 you guys have added a new meta-data attribute, >> >>>>>>> >> >>>>>>>>>>> namely application_type. >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> First, this new attribute is not listed in the IANA consideration >> >>>>>>> >> >>>>>>>>>>> section. >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> Second, could you provide a bit of motivation why you need it? >> >>>>>>> >> >>>>>>>>>>> What would the authorization server do with that type of >> >>>>>>> >> >>>>>>>>>>> information? The description is rather short. >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> IMHO there is also no clear boundary between a "native" and "web" app. >> >>>>>>> >> >>>>>>>>>>> Just think about smart phone apps that are developed using JavaScript. >> >>>>>>> >> >>>>>>>>>>> Would this be a web app or a native app? >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> Here is the definition from the draft: >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> application_type >> >>>>>>> >> >>>>>>>>>>> OPTIONAL. Kind of the application. The default, if omitted, is >> >>>>>>> >> >>>>>>>>>>> "web". The defined values are "native" or "web". >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> Ciao >> >>>>>>> >> >>>>>>>>>>> Hannes >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> _______________________________________________ >> >>>>>>> >> >>>>>>>>>>> OAuth mailing list >> >>>>>>> >> >>>>>>>>>>> OAuth@ietf.org >> >>>>>>> >> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >>>>>>>>>>> -- >> >>>>>>> >> >>>>>>>>>>> Nat Sakimura (=nat) >> >>>>>>> >> >>>>>>>>>>> Chairman, OpenID Foundation >> >>>>>>> >> >>>>>>>>>>> http://nat.sakimura.org/ [4] >> >>>>>>> >> >>>>>>>>>>> @_nat_en >> >>>>>>> >> >>>>>>>>>> >> >>>>>>> >> >>>>>>>>>> _______________________________________________ >> >>>>>>> >> >>>>>>>>>> OAuth mailing list >> >>>>>>> >> >>>>>>>>>> OAuth@ietf.org >> >>>>>>> >> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] >> >>>>>>> >> >>>>>>>>> >> >>>>>>> >> >>>>>>>>> _______________________________________________ >> >>>>>>> >> >>>>>>>>> OAuth mailing list >> >>>>>>> >> >>>>>>>>> OAuth@ietf.org >> >>>>>>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] >> >>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> >> >>>>>>> OAuth mailing list >> >>>>>>> >> >>>>>>> OAuth@ietf.org >> >>>>>>> >> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> OAuth mailing list >> >>>>>>> OAuth@ietf.org >> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> OAuth mailing list >> >>>>>> OAuth@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Nat Sakimura (=nat) >> >>>>> Chairman, OpenID Foundation >> >>>>> http://nat.sakimura.org/ [4] >> >>>>> @_nat_en >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> >> >>>> OAuth mailing list >> >>>> >> >>>> OAuth@ietf.org >> >>>> >> >>>> https://www.ietf.org/mailman/listinfo/oauth [3] >> >>>> >> >>> >> >>> >> >>> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth [3] Links: ------ [1] http://tools.ietf.org/html/rfc6749#section-2 [2] http://www.independentid.com [3] https://www.ietf.org/mailman/listinfo/oauth [4] http://nat.sakimura.org/ --=_87bbe385d9731b0f6e03495610db3958 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

I thought the fragment is only delivered to the client on the AS leg, me= aning if the AS uses HTTPS everything is secure.

 

Am 23.07.2014 11:15, schrieb Mike Jones:

Web clients using the implicit flow MUS= T use https or the tokens returned would be communicated in the clear on th= e open Internet for anyone to snoop.  Not at good idea!

 

From: torsten@lodderstedt.net [mailt= o:torsten@lodderstedt.net]
Sent: Wednesday, July 23,= 2014 8:03 AM
To: Mike Jones
Cc: Justin Richer; oauth@ietf.org
Subject: RE: [OAUTH-W= G] Dynamic Client Registration: application_type

 

Good point. I don't understand why cl= ients using the implicit response type generally shall be obliged to use HT= TPS. Getting rid of this requirement would significantly simplify the text= =2E

regards,
Torsten. 

Am 23.07.2014 10:35, schrieb Mike Jon= es:

It's more comp= licated than that, as native apps may use the implicit flow and not use htt= ps.  The set of constraints in the "application_type" definition in Op= enID Connect Dynamic Registration are:

 

Web Clien= ts using the OAuth Implicit Grant Type MUST only register URLs using the https sc= heme as redirect_uris<= /tt>; they MUST NOT use localhost as the hostname. Native Clients M= UST only register redirect_ur= is using custom URI schemes or URLs using the http: scheme= with localhost as the hostname. Authorization Servers MAY place additional const= raints on Native Clients. Authorization Servers MAY reject Redirection URI = values using the http<= /tt> scheme, other than the localhost case for Native Clients.<= span style=3D"font-size: 10.0pt;">

 

If we're going= to add such constraints, I believe they should be the same ones as the one= s above.

 

  &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       -- Mike

 

-----Original = Message-----
From: OAuth [m= ailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Tu= esday, July 22, 2014 6:16 PM
To: torsten@lodderstedt.net
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Reg= istration: application_type

 

I'm ok with th= at text, and actually thought we had something along those lines already.

 

--Justin

 

/sent from my = phone/

 

On Jul 22, 201= 4 3:27 PM, torsten@lodderstedt.net wr= ote:

> 

> Hi all,

> 

> I don't t= hink this parameter adds any security (as it is self declarded by the calle= r). I think the constraints on redirect_uris can be specified without the n= eed for another registration parameter. As far as I understand, they merely= depend on the grant type. So we could some text to the redirect_uri parame= ter definition. Something along the following lines:

> 

> "All redi= rect URIs registered for a particular client MUST either (1) use the H= TTPS scheme or (2) the HTTP scheme with localhost as the hostname or custom= schemes. Additionally, clients using the implict grant type MUST only= register URLs using the https scheme as redirect_uris; they MUST NOT use l= ocalhost as the hostname."  

> 

> regards,<= !-- o ignored -->

> Torsten= =2E

> 

> Am 08.07= =2E2014 21:35, schrieb Richer, Justin P.:

>> =

>> Right= , that's how it's used in Connect, which defines only redirect-based flows= =2E However, the OAuth version needs to be more general purpose. 

>>  = ;

>> It se= ems like this parameter really does need more discussion in the group befor= e it should be added to the spec, and therefore I don't think it's appropri= ate to add it at this stage (post-WGLC).

>>  = ;

>>  = ;-- Justin

>> =

>> On Ju= l 8, 2014, at 8:54 PM, Nat Sakimura <sakimura@gmail= =2Ecom> wrote:

>> =

>>> I= f I understand correctly, this parameter is used to appropriately constrain= the schema of the Redirect URIs at the time of the registration and is not= about fulfilling the Client Type registration requirement in section 2.1= =2E So, making go or no-go decision based on the discussion around section = 2.1 probably would not be the way to go. The discussion should happen aroun= d the needs on constraining the schema depending on the kind of client.&nbs= p;

>>> &= nbsp;

>>> A= pparently, Connect WG perceived that it is a big enough risk that they need= to put a plug on based on the risk evaluation as an identity federation pr= otocol. OAuth has different risk profile so it could decide otherwise, but = my gut feeling is that unless there is a good reason not to have it, we may= as well keep it. 

>>> &= nbsp;

>>> N= at

>>>&n= bsp;

>>>&n= bsp;

>>> 2= 014-07-09 7:54 GMT+09:00 Richer, Justin P. <jricher@= mitre.org>:

>>>&g= t; 

>>>&g= t; This value was introduced in -18, and it's a direct port from OpenID Con= nect. It was never in the OAuth Dynamic Registration spec, and though it ha= s been in the OpenID Connect Dynamic Registration spec for a very long time= , I think it was a mistake to add it in for several reasons: 

>>>&g= t;  

>>>&g= t; First, the semantics around its values and use are not clearly defined, = for the reasons . I don't see any particular harm in keeping it, but I don'= t really see what value it adds for clients or server developers. We are in= a world where there are OAuth clients that are much more than just "native= " or "web".

>>>&g= t;  

>>>&g= t; Second, RFC6749 defines "Client Type" in § 2.1 which defines two va= lues: "confidential" and "public", neither of which maps very cleanly to "n= ative" or "web" as stated in -18. This is especially true when you've got d= ynamic registration that can make native clients confidential with relative= ease. We actually take care of registering the "client type" through the u= se of the "token_endpoint_auth_method" parameter, which is what § 2.1 = is really talking about: secure client authentication (to the token endpoin= t). 

>>>&g= t;  

>>>&g= t; With this in mind, my preference and suggestion would be to remove this = field. If other protocols need it, they can register and define it (like Co= nnect has done).

>>>&g= t;  

>>>&g= t;  -- Justin

>>>&g= t;  

>>>&g= t; 

>>>&g= t; On Jul 8, 2014, at 4:38 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:=

>>>&g= t; 

>>>&g= t;> I put it back because otherwise, we wouldn't be meeting one of the r= equirements of the RFC 6749.  If you look at the client registration s= ection http://tools.ietf.org/html/r= fc6749#section-2, you'll see that registering redirect_uri value= s is required, as is registering the client type.  Without this, there= wasn't a way to register the client type.

>>>&g= t;> 

>>>&g= t;>  

>>>&g= t;> 

>>>&g= t;>            &n= bsp;            = ;            &n= bsp;            = ;           -- Mike

>>>&g= t;> 

>>>&g= t;>  

>>>&g= t;> 

>>>&g= t;> -----Original Message-----

>>>&g= t;> From: OAuth [mailto:oauth-bounces@ietf.or= g] On Behalf Of John Bradley

>>>&g= t;> Sent: Tuesday, July 08, 2014 12:37 PM

>>>&g= t;> To: Phil Hunt

>>>&g= t;> Cc: oauth@ietf.org

>>>&g= t;> Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_typ= e

>>>&g= t;> 

>>>&g= t;>  

>>>&g= t;> 

>>>&g= t;> It was taken out and then put back in as it is a common parameter us= ed by a number of AS.

>>>&g= t;> 

>>>&g= t;>  

>>>&g= t;> 

>>>&g= t;> We have it in Connect, the best reason for keeping it is to stop peo= ple from coming up with a new parameter for the same thing because they hav= en't looked at the Connect version.

>>>&g= t;> 

>>>&g= t;>  

>>>&g= t;> 

>>>&g= t;> John B.

>>>&g= t;> 

>>>&g= t;> On Jul 8, 2014, at 3:16 PM, Phil Hunt <phi= l.hunt@oracle.com> wrote:

>>>&g= t;> 

>>>&g= t;>  

>>>&g= t;> 

>>>&g= t;> > Does this need to be in the spec?  I believe we've already= said that others can add attributes as they need.=

>>>&g= t;> 

>>>&g= t;> >

>>>&g= t;> 

>>>&g= t;> > Phil

>>>&g= t;> 

>>>&g= t;> >

>>>&g= t;> 

>>>&g= t;> > @independentid

>>>&g= t;> 

>>>&g= t;> > www.independentid.com

>>>&g= t;> 

>>>&g= t;> > phil.hunt@oracle.com

>>>&g= t;> 

>>>&g= t;> >

>>>&g= t;> 

>>>&g= t;> >

>>>&g= t;> 

>>>&g= t;> >

>>>&g= t;> 

>>>&g= t;> > On Jul 8, 2014, at 11:56 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

>>>&g= t;> 

>>>&g= t;> >

>>>&g= t;> 

>>>&g= t;> >> The application_type is collected as part of current regist= ration by Google and some other OAuth providers as part of registering redi= rect uri.

>>>&g= t;> 

>>>&g= t;> >>

>>>&g= t;> 

>>>&g= t;> >> The text was cut down to allow more flexibility in OAuth.&n= bsp; Connect requires registration of redirect_uri and is more ridged about= it than OAuth 2.

>>>&g= t;> 

>>>&g= t;> >>

>>>&g= t;> 

>>>&g= t;> >> Do you think the Connect wording would be appropriate for O= Auth?

>>>&g= t;> 

>>>&g= t;> >>

>>>&g= t;> 

>>>&g= t;> >> John B.

>>>&g= t;> 

>>>&g= t;> >>

>>>&g= t;> 

>>>&g= t;> >> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>>>&g= t;> 

>>>&g= t;> >>

>>>&g= t;> 

>>>&g= t;> >>> This additional information makes a lot of sense.

>>>&g= t;> 

>>>&g= t;> >>>

>>>&g= t;> 

>>>&g= t;> >>> As you said in an earlier mail, the attempt to copy tex= t from the

>>>&g= t;> 

>>>&g= t;> >>> OpenID Connect spec failed a bit...

>>>&g= t;> 

>>>&g= t;> >>>

>>>&g= t;> 

>>>&g= t;> >>> On 07/08/2014 02:49 PM, Nat Sakimura wrote:

>>>&g= t;> 

>>>&g= t;> >>>> I suppose authors has imported one of the security = feature of

>>>&g= t;> 

>>>&g= t;> >>>> OpenID Connect here as well. In the Dynamic Client = Registration

>>>&g= t;> 

>>>&g= t;> >>>> standard, which is a bit longer than IETF version= =2E You can see the reason from it:

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>> application_type

>>>&g= t;> 

>>>&g= t;> >>>>  OPTIONAL. Kind of the application. The defaul= t, if omitted, is web.

>>>&g= t;> 

>>>&g= t;> >>>>  The defined values are native or web. Web Cli= ents using the OAuth 

>>>&g= t;> 

>>>&g= t;> >>>> Implicit Grant Type MUST only register URLs using t= he https scheme 

>>>&g= t;> 

>>>&g= t;> >>>> as redirect_uris; they MUST NOT use localhost as th= e hostname.

>>>&g= t;> 

>>>&g= t;> >>>>  Native Clients MUST only register redirect_ur= is using custom URI 

>>>&g= t;> 

>>>&g= t;> >>>> schemes or URLs using the http: scheme with localho= st as the 

>>>&g= t;> 

>>>&g= t;> >>>> hostname. Authorization Servers MAY place additiona= l constraints on 

>>>&g= t;> 

>>>&g= t;> >>>> Native Clients. Authorization Servers MAY reject Re= direction URI 

>>>&g= t;> 

>>>&g= t;> >>>> values using the http scheme, other than the localh= ost case for 

>>>&g= t;> 

>>>&g= t;> >>>> Native Clients. The Authorization Server MUST verif= y that all the 

>>>&g= t;> 

>>>&g= t;> >>>> registered redirect_uris conform to these constrain= ts. This

>>>&g= t;> 

>>>&g= t;> >>>> prevents  sharing a Client ID across different= types of Clients.

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>> Regards,

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>> Nat

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig

>>>&g= t;> 

>>>&g= t;> >>>> <hannes.tschofenig@gmx.net

>>>&g= t;> 

>>>&g= t;> >>>> <mailto:hannes.tscho= fenig@gmx.net>>:

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>  Hi all,

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>  with version -18 you guys have added a new me= ta-data attribute,

>>>&g= t;> 

>>>&g= t;> >>>> namely  application_type.

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>  First, this new attribute is not listed in th= e IANA consideration 

>>>&g= t;> 

>>>&g= t;> >>>> section.

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>  Second, could you provide a bit of motivation= why you need it?

>>>&g= t;> 

>>>&g= t;> >>>> What  would the authorization server do with t= hat type of

>>>&g= t;> 

>>>&g= t;> >>>> information? The  description is rather short= =2E

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>  IMHO there is also no clear boundary between = a "native" and "web" app.

>>>&g= t;> 

>>>&g= t;> >>>>  Just think about smart phone apps that are de= veloped using JavaScript.

>>>&g= t;> 

>>>&g= t;> >>>>  Would this be a web app or a native app?

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>  Here is the definition from the draft:

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>  application_type

>>>&g= t;> 

>>>&g= t;> >>>>        OPTIONAL= =2E  Kind of the application.  The default, if omitted, is

>>>&g= t;> 

>>>&g= t;> >>>>        "web".&nb= sp; The defined values are "native" or "web".

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>  Ciao

>>>&g= t;> 

>>>&g= t;> >>>>  Hannes

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>  _____________________________________________= __

>>>&g= t;> 

>>>&g= t;> >>>>  OAuth mailing list

>>>&g= t;> 

>>>&g= t;> >>>>  OAuth@ietf.org &= lt;mailto:OAuth@ietf.org> 

>>>&g= t;> 

>>>&g= t;> >>>> https://www= =2Eietf.org/mailman/listinfo/oauth

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>>

>>>&g= t;> 

>>>&g= t;> >>>> --

>>>&g= t;> 

>>>&g= t;> >>>> Nat Sakimura (=3Dnat)

>>>&g= t;> 

>>>&g= t;> >>>> Chairman, OpenID Foundation

>>>&g= t;> 

>>>&g= t;> >>>> http://nat.sakimura.org/

>>>&g= t;> 

>>>&g= t;> >>>> @_nat_en

>>>&g= t;> 

>>>&g= t;> >>>

>>>&g= t;> 

>>>&g= t;> >>> _______________________________________________

>>>&g= t;> 

>>>&g= t;> >>> OAuth mailing list

>>>&g= t;> 

>>>&g= t;> >>> OAuth@ietf.org

>>>&g= t;> 

>>>&g= t;> >>> https://www.iet= f.org/mailman/listinfo/oauth

>>>&g= t;> 

>>>&g= t;> >>

>>>&g= t;> 

>>>&g= t;> >> _______________________________________________

>>>&g= t;> 

>>>&g= t;> >> OAuth mailing list

>>>&g= t;> 

>>>&g= t;> >> OAuth@ietf.org

>>>&g= t;> >> https://www.ietf.or= g/mailman/listinfo/oauth

>>>&g= t;> 

>>>&g= t;> >

>>>&g= t;> 

>>>&g= t;>  

>>>&g= t;> 

>>>&g= t;> _______________________________________________

>>>&g= t;> 

>>>&g= t;> OAuth mailing list

>>>&g= t;> 

>>>&g= t;> OAuth@ietf.org=

>>>&g= t;> 

>>>&g= t;> https://www.ietf.org/mailman= /listinfo/oauth

>>>&g= t;> 

>>>&g= t;> _______________________________________________

>>>&g= t;> OAuth mailing list

>>>&g= t;> OAuth@ietf.org=

>>>&g= t;> https://www.ietf.org/mailman= /listinfo/oauth

>>>&g= t; 

>>>&g= t; 

>>>&g= t; _______________________________________________=

>>>&g= t; OAuth mailing list

>>>&g= t; OAuth@ietf.org

>>>&g= t; https://www.ietf.org/mailman/lis= tinfo/oauth

>>>&g= t; 

>>>&n= bsp;

>>>&n= bsp;

>>> &= nbsp;

>>> -= -

>>> N= at Sakimura (=3Dnat)

>>> C= hairman, OpenID Foundation

>>> <= a href=3D"http://nat.sakimura.org/"> http://nat.sakimura.org/

>>> @= _nat_en

>> =

>> =

>> _____= __________________________________________

>> =

>> OAuth= mailing list

>> =

>> OAuth@ietf.org

>> =

>> https://www.ietf.org/mailman/listinfo/oa= uth

>> =

>  

> 

>  

______________= _________________________________

OAuth mailing = list

OAuth@ietf.org

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

 

 

 

 
--=_87bbe385d9731b0f6e03495610db3958-- From nobody Wed Jul 23 09:17:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2850F1B2970 for ; Wed, 23 Jul 2014 09:17:35 -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=[AC_DIV_BONANZA=0.001, 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 Ivhf_DrAh0vY for ; Wed, 23 Jul 2014 09:17:31 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83E11B27C7 for ; Wed, 23 Jul 2014 09:17:30 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id el20so1116856lab.27 for ; Wed, 23 Jul 2014 09:17:29 -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=2KoIt2A0jMbviKRlg57BYG+X0bL8mx1oqpFwBBt2rS4=; b=ilwru0zRQ/c6hM4w2VFmv57jVmXDcNePFrR9zC/0C1XIfcOGuhMWVTGygE4V0AyOnB tNZaYvSCTP6DPTtjkjy0OUf2yaEwKMm8PV7Dx4vbwkhVv4sct8sOfNfqzLbNSWki1d+b VwSl5IQOyvDsZLjK8NM+GO+n0kYkFJFDw7SEMmjr6NKD3+CEGzrGNxlVqeOtDbOF7n9k +dctb34htCVmAsKov9vAN2AaIR2EV2uGM5h5WNKFMbUm5iKT9NPoQJo6OxST3jw4wi3p QdA3MZy+klrFwUIC4gHgzjof4IhMvW4rwSqlSHOIXJd5S2ta8HartFBYbigCviHGiEv4 9MbA== MIME-Version: 1.0 X-Received: by 10.112.132.39 with SMTP id or7mr2505980lbb.45.1406132248868; Wed, 23 Jul 2014 09:17:28 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Wed, 23 Jul 2014 09:17:28 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Wed, 23 Jul 2014 12:17:28 -0400 Message-ID: From: Nat Sakimura To: Mike Jones Content-Type: multipart/alternative; boundary=047d7b3a806433804604fedeadf2 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/WX-GBMBEaVO4Rr8w08cUfjw_iwg Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 16:17:35 -0000 --047d7b3a806433804604fedeadf2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fair enough. It is revealing to hear that it is OK to have no access token after all as OAuth. (Though, in the next rev., I suppose the text needs to be fixed.) Then, like Justin says, it probably is just a matter of defining an 'response_type' extension parameter to the token endpoint. It is practically going to be a few liner as a mini-extension of OIDC. As far as response_type=3Did_token is concerned, it probably is better to be done in OIDF than here. I am amiable in defining this parameter itself in this WG though. So, in "OAuth response type parameter to Token endpoint" spec., it defines one parameter to the token endpoint as: response_type OPTIONAL. A string that expresses what tokens are to be returned from the Token Endpoint. Extension specifications may use this parameter to explicitly expressing the desire to obtain a particular type of token. Then, in an mini-extension spec to OIDC, such as "OIDC ID Token only profile" response_type If the value of this parameter is "id_token", only ID Token SHOULD be returned in the successful response. Cheers, Nat 2014-07-23 10:26 GMT-04:00 Mike Jones : > The response_type =E2=80=9Cnone=E2=80=9D is already used in practice, wh= ich returns no > access token. It was accepted by the designated experts and registered i= n > the IANA OAuth Authorization Endpoint Response Types registry at > http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#end= point. > The registered =E2=80=9Cid_token=E2=80=9D response type also returns no a= ccess token. > > > > So I think the question of whether response types that result in no acces= s > token being returned are acceptable within OAuth 2.0 is already settled, = as > a practical matter. Lots of OAuth implementations are already using such > response types. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Wednesday, July 23, 2014 7:09 AM > *To:* Nat Sakimura > *Cc:* > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > Yes. This is why it has to be discussed in the IETF. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: > > > > Reading back the RFC6749, I am not sure if there is a good way of > suppressing access token from the response and still be OAuth. It will > break whole bunch of implicit definitions like: > > > > authorization server > The server issuing access tokens to the client after successfully > authenticating the resource owner and obtaining authorization. > > > > After all, OAuth is all about issuing access tokens. > > > > Also, I take back my statement on the grant type in my previous mail. > > > > The definition of grant and grant_type are respectively: > > > > grant > > credential representing the resource owner's authorization > > > > grant_type > > (string representing the) type of grant sent to the token endpoint to > obtain the access token > > > > Thus, the grant sent to the token endpoint in this case is still 'code'. > > > > Response type on the other hand is not so well defined in RFC6749, but it > seems it is representing what is to be returned from the authorization > endpoint. To express what is to be returned from token endpoint, perhaps > defining a new parameter to the token endpoint, which is a parallel to th= e > response_type to the Authorization Endpoint seems to be a more symmetric > way, though I am not sure at all if that is going to be OAuth any more. O= ne > straw-man is to define a new parameter called response_type to the token > endpoint such as: > > > > response_type > > OPTIONAL. A string representing what is to be returned from the token > endpoint. > > > > Then define the behavior of the endpoint according to the values as the > parallel to the multi-response type spec. > > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html > > > > Nat > > > > > > > > > > 2014-07-23 7:21 GMT-04:00 Phil Hunt : > > The draft is very clear. > > Phil > > > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: > > The new grant type that I was talking about was > > "authorization_code_but_do_not_return_access_nor_refresh_token", so to > speak. > > It does not return anything per se, but an extension can define something > on top of it. > > > > Then, OIDC can define a binding to it so that the binding only returns ID > Token. > > This binding work should be done in OIDF. Should there be such a grant > type, > > it will be an extremely short spec. > > > > At the same time, if any other specification wanted to define > > other type of tokens and have it returned from the token endpoint, > > it can also use this grant type. > > > > If what you want is to define a new grant type that returns ID Token only= , > > then, I am with Justin. Since "other response than ID Token" is only > > theoretical, this is a more plausible way forward, I suppose. > > > > Nat > > > > 2014-07-22 14:30 GMT-04:00 Justin Richer : > > So the draft would literally turn into: > > "The a4c response type and grant type return an id_token from the token > endpoint with no access token. All parameters and values are defined in > OIDC." > > Seems like the perfect mini extension draft for OIDF to do. > > --Justin > > /sent from my phone/ > > > On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: > > > > What about just defining a new grant type in this WG? > > > > > > 2014-07-22 12:56 GMT-04:00 Phil Hunt : > >> > >> That would be nice. However oidc still needs the new grant type in > order to implement the same flow. > >> > >> Phil > >> > >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: > >> > >>> +1 to Justin. > >>> > >>> > >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : > >>>> > >>>> Errors like these make it clear to me that it would make much more > sense to develop this document in the OpenID Foundation. It should be > something that directly references OpenID Connect Core for all of these > terms instead of redefining them. It's doing authentication, which is > fundamentally what OpenID Connect does on top of OAuth, and I don't see a > good argument for doing this work in this working group. > >>>> > >>>> -- Justin > >>>> > >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer > wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < > Michael.Jones@microsoft.com> wrote: > >>>>>> > >>>>>> Thanks for your review, Thomas. The =E2=80=9Cprompt=3Dconsent=E2= =80=9D definition > being missing is an editorial error. It should be: > >>>>>> > >>>>>> > >>>>>> > >>>>>> consent > >>>>>> > >>>>>> The Authorization Server SHOULD prompt the End-User for consent > before returning information to the Client. If it cannot obtain consent, = it > MUST return an error, typically consent_required. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I=E2=80=99ll plan to add it in the next draft. > >>>>> > >>>>> > >>>>> It looks like the consent_required error needs to be defined too, > and you might have forgotten to also import account_selection_required fr= om > OpenID Connect. > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> I agree that there=E2=80=99s no difference between a response with= multiple > =E2=80=9Camr=E2=80=9D values that includes =E2=80=9Cmfa=E2=80=9D and one = that doesn=E2=80=99t. Unless a clear use > case for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can de= lete it in the > next draft. > >>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>> How about "pwd" then? I fully understand that I should return "pwd" > if the user authenticated using a password, but what "the service if a > client secret is used" means in the definition for the "pwd" value? > >>>>> > >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come > back ;-) ) > >>>>> > >>>>> -- > >>>>> Thomas Broyer > >>>>> /t=C9=94.ma.b=CA=81wa.je/ > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> > >>> > >>> > >>> -- > >>> Nat Sakimura (=3Dnat) > >>> Chairman, OpenID Foundation > >>> http://nat.sakimura.org/ > >>> @_nat_en > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --047d7b3a806433804604fedeadf2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fair enough. It is revealing to hear that it is OK to have= no access token after all as OAuth. (Though, in the next rev., I suppose t= he text needs to be fixed.)=C2=A0

Then, like Justin says= , it probably is just a matter of defining an 'response_type' exten= sion parameter to the token endpoint.=C2=A0
It is practically going to be a few liner as a mini-extension of OIDC.= As far as response_type=3Did_token is concerned, it probably is better to = be done in OIDF than here. I am amiable in defining this parameter itself i= n this WG though.=C2=A0

So, in "OAuth response type parameter to Token end= point" spec., it defines one parameter to the token endpoint as:=C2=A0=

response_type
=C2=A0 OPTIONAL. A string= that expresses what tokens are to be returned from the Token Endpoint.=C2= =A0
=C2=A0 Extension specifications may use this parameter to explicitly e= xpressing the desire to=C2=A0
=C2=A0 obtain a particular type of = token.=C2=A0

Then, in an mini-extension spec to OI= DC, such as "OIDC ID Token only profile"

response_type
=C2=A0 =C2=A0If the value of th= is parameter is "id_token", =C2=A0only ID Token SHOULD be returne= d in the successful response.=C2=A0

Cheers,=C2=A0<= /div>

Nat



2014-07-23 10:26 GMT-04:00 Mike Jones <Michael.Jones@microsoft.com>:

The response_type =E2=80= =9Cnone=E2=80=9D is already used in practice, which returns no access token= .=C2=A0 It was accepted by the designated experts and registered in the IAN= A OAuth Authorization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpo= int.=C2=A0 The registered =E2=80=9Cid_token=E2=80=9D response type also= returns no access token.

=C2=A0

So I think the question o= f whether response types that result in no access token being returned are = acceptable within OAuth 2.0 is already settled, as a practical matter.=C2=A0 Lots of OAuth implementations are already using such respons= e types.

=C2=A0

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

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ie= tf.org>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oaut= h-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

Phil<= /p>

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:



Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client after s= uccessfully
=C2=A0 =C2=A0 =C2=A0 authenticating the resource owner and obtaining author= ization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token<= /p>

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token en= dpoint, perhaps defining a new parameter to the token endpoint, which is a parallel to the response_type to the Aut= horization Endpoint seems to be a more symmetric way, though I am not sure = at all if that is going to be OAuth any more. One straw-man is to define a = new parameter called response_type to the token endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0<= u>

=C2=A0

Nat

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0<= /u>

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0=

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat

=C2=A0<= /p>

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of = OAuth, and I don't see a good argument for doing this work in this work= ing group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wro= te:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The =E2=80= =9Cprompt=3Dconsent=E2=80=9D definition being missing is an editorial error= .=C2=A0 It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I=E2=80=99ll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there=E2=80=99s no difference between= a response with multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80= =9Cmfa=E2=80=9D and one that doesn=E2=80=99t.=C2=A0 Unless a clear use case= for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete i= t in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0




--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--047d7b3a806433804604fedeadf2-- From nobody Wed Jul 23 09:30:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0FB1A0084 for ; Wed, 23 Jul 2014 09:30:45 -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=[AC_DIV_BONANZA=0.001, 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 KaPuLWuRHEAb for ; Wed, 23 Jul 2014 09:30:39 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6EE1A0409 for ; Wed, 23 Jul 2014 09:30:38 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id s7so1123131lbd.14 for ; Wed, 23 Jul 2014 09:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0b8uMnOAb3CXiL/ioiMoclYBGqrLQ8HrwUO+rJTYt0o=; b=ZIESLn1clr6ruLXj3yctKr3whiSTIHZluqcvErXYwRboG8psf0gEB9usPpaFK+2Q2X v1cniE/Z1N5cHEESTjiClJQT00jrz2B8to0AltNiNcXzMk7E4nPm7lu4aFKI2gEPlmJE o53bLgc/HMjommEhTNDk6/2pnFm2aXSOnGQMG8QsHrPJFkC7u6LAaMxVOt7WeWluWzsd VMQq76pxo1AfYPxfBLIYcir3fXWn816O21n29w7JgyRFmaUtd8yNvdwzdEx6FV4gnY6K 6hLKBWCzNK399yZemjbb5EFLoTiesF0bV9LczM2R9fWIegN2EYR4/DmMU0iSryud22mc odkQ== X-Received: by 10.152.37.194 with SMTP id a2mr2784882lak.29.1406133036470; Wed, 23 Jul 2014 09:30:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.113.73 with HTTP; Wed, 23 Jul 2014 09:30:16 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> From: Thomas Broyer Date: Wed, 23 Jul 2014 18:30:16 +0200 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=089e013d1656255aaa04fededc2d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/PUVGZltaBV6SnF7jPz40uez7tnE Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 16:30:46 -0000 --089e013d1656255aaa04fededc2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Except that these are about not using the Token Endpoint at all, whereas the current proposal is about the Token Endpoint not returning an access_token field in the JSON. On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones wrote: > The response_type =E2=80=9Cnone=E2=80=9D is already used in practice, wh= ich returns no > access token. It was accepted by the designated experts and registered i= n > the IANA OAuth Authorization Endpoint Response Types registry at > http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#end= point. > The registered =E2=80=9Cid_token=E2=80=9D response type also returns no a= ccess token. > > > > So I think the question of whether response types that result in no acces= s > token being returned are acceptable within OAuth 2.0 is already settled, = as > a practical matter. Lots of OAuth implementations are already using such > response types. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Wednesday, July 23, 2014 7:09 AM > *To:* Nat Sakimura > *Cc:* > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > Yes. This is why it has to be discussed in the IETF. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: > > > > Reading back the RFC6749, I am not sure if there is a good way of > suppressing access token from the response and still be OAuth. It will > break whole bunch of implicit definitions like: > > > > authorization server > The server issuing access tokens to the client after successfully > authenticating the resource owner and obtaining authorization. > > > > After all, OAuth is all about issuing access tokens. > > > > Also, I take back my statement on the grant type in my previous mail. > > > > The definition of grant and grant_type are respectively: > > > > grant > > credential representing the resource owner's authorization > > > > grant_type > > (string representing the) type of grant sent to the token endpoint to > obtain the access token > > > > Thus, the grant sent to the token endpoint in this case is still 'code'. > > > > Response type on the other hand is not so well defined in RFC6749, but it > seems it is representing what is to be returned from the authorization > endpoint. To express what is to be returned from token endpoint, perhaps > defining a new parameter to the token endpoint, which is a parallel to th= e > response_type to the Authorization Endpoint seems to be a more symmetric > way, though I am not sure at all if that is going to be OAuth any more. O= ne > straw-man is to define a new parameter called response_type to the token > endpoint such as: > > > > response_type > > OPTIONAL. A string representing what is to be returned from the token > endpoint. > > > > Then define the behavior of the endpoint according to the values as the > parallel to the multi-response type spec. > > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html > > > > Nat > > > > > > > > > > 2014-07-23 7:21 GMT-04:00 Phil Hunt : > > The draft is very clear. > > Phil > > > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: > > The new grant type that I was talking about was > > "authorization_code_but_do_not_return_access_nor_refresh_token", so to > speak. > > It does not return anything per se, but an extension can define something > on top of it. > > > > Then, OIDC can define a binding to it so that the binding only returns ID > Token. > > This binding work should be done in OIDF. Should there be such a grant > type, > > it will be an extremely short spec. > > > > At the same time, if any other specification wanted to define > > other type of tokens and have it returned from the token endpoint, > > it can also use this grant type. > > > > If what you want is to define a new grant type that returns ID Token only= , > > then, I am with Justin. Since "other response than ID Token" is only > > theoretical, this is a more plausible way forward, I suppose. > > > > Nat > > > > 2014-07-22 14:30 GMT-04:00 Justin Richer : > > So the draft would literally turn into: > > "The a4c response type and grant type return an id_token from the token > endpoint with no access token. All parameters and values are defined in > OIDC." > > Seems like the perfect mini extension draft for OIDF to do. > > --Justin > > /sent from my phone/ > > > On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: > > > > What about just defining a new grant type in this WG? > > > > > > 2014-07-22 12:56 GMT-04:00 Phil Hunt : > >> > >> That would be nice. However oidc still needs the new grant type in > order to implement the same flow. > >> > >> Phil > >> > >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: > >> > >>> +1 to Justin. > >>> > >>> > >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : > >>>> > >>>> Errors like these make it clear to me that it would make much more > sense to develop this document in the OpenID Foundation. It should be > something that directly references OpenID Connect Core for all of these > terms instead of redefining them. It's doing authentication, which is > fundamentally what OpenID Connect does on top of OAuth, and I don't see a > good argument for doing this work in this working group. > >>>> > >>>> -- Justin > >>>> > >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer > wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < > Michael.Jones@microsoft.com> wrote: > >>>>>> > >>>>>> Thanks for your review, Thomas. The =E2=80=9Cprompt=3Dconsent=E2= =80=9D definition > being missing is an editorial error. It should be: > >>>>>> > >>>>>> > >>>>>> > >>>>>> consent > >>>>>> > >>>>>> The Authorization Server SHOULD prompt the End-User for consent > before returning information to the Client. If it cannot obtain consent, = it > MUST return an error, typically consent_required. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I=E2=80=99ll plan to add it in the next draft. > >>>>> > >>>>> > >>>>> It looks like the consent_required error needs to be defined too, > and you might have forgotten to also import account_selection_required fr= om > OpenID Connect. > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> I agree that there=E2=80=99s no difference between a response with= multiple > =E2=80=9Camr=E2=80=9D values that includes =E2=80=9Cmfa=E2=80=9D and one = that doesn=E2=80=99t. Unless a clear use > case for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can de= lete it in the > next draft. > >>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>> How about "pwd" then? I fully understand that I should return "pwd" > if the user authenticated using a password, but what "the service if a > client secret is used" means in the definition for the "pwd" value? > >>>>> > >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come > back ;-) ) > >>>>> > >>>>> -- > >>>>> Thomas Broyer > >>>>> /t=C9=94.ma.b=CA=81wa.je/ > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> > >>> > >>> > >>> -- > >>> Nat Sakimura (=3Dnat) > >>> Chairman, OpenID Foundation > >>> http://nat.sakimura.org/ > >>> @_nat_en > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --089e013d1656255aaa04fededc2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Except that these are about not using the Token Endpoint a= t all, whereas the current proposal is about the Token Endpoint not returni= ng an access_token field in the JSON.

<= br>
On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The response_type =E2=80= =9Cnone=E2=80=9D is already used in practice, which returns no access token= .=C2=A0 It was accepted by the designated experts and registered in the IAN= A OAuth Authorization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpo= int.=C2=A0 The registered =E2=80=9Cid_token=E2=80=9D response type also= returns no access token.

=C2=A0

So I think the question o= f whether response types that result in no access token being returned are = acceptable within OAuth 2.0 is already settled, as a practical matter.=C2=A0 Lots of OAuth implementations are already using such respons= e types.

=C2=A0

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

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ie= tf.org>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oaut= h-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

Phil<= /p>

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:



Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client after s= uccessfully
=C2=A0 =C2=A0 =C2=A0 authenticating the resource owner and obtaining author= ization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token<= /p>

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token en= dpoint, perhaps defining a new parameter to the token endpoint, which is a parallel to the response_type to the Aut= horization Endpoint seems to be a more symmetric way, though I am not sure = at all if that is going to be OAuth any more. One straw-man is to define a = new parameter called response_type to the token endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0<= u>

=C2=A0

Nat

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0<= /u>

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0=

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat

=C2=A0<= /p>

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of = OAuth, and I don't see a good argument for doing this work in this work= ing group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wro= te:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The =E2=80= =9Cprompt=3Dconsent=E2=80=9D definition being missing is an editorial error= .=C2=A0 It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I=E2=80=99ll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there=E2=80=99s no difference between= a response with multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80= =9Cmfa=E2=80=9D and one that doesn=E2=80=99t.=C2=A0 Unless a clear use case= for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete i= t in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0


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




--
Thomas B= royer
/t=C9=94.ma.b=CA=81w= a.je/
--089e013d1656255aaa04fededc2d-- From nobody Wed Jul 23 09:45:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CCE1B2B4C for ; Wed, 23 Jul 2014 09:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 krisr6EsZITW for ; Wed, 23 Jul 2014 09:45:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3B71B27B0 for ; Wed, 23 Jul 2014 09:45:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A740E1F1D3C; Wed, 23 Jul 2014 12:45:18 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 925711F1D3B; Wed, 23 Jul 2014 12:45:18 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.118]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 12:45:18 -0400 From: "Richer, Justin P." To: Thomas Broyer Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpdsD2HhjKAwRPEyI0/Q0qsoAEputWXWAgABuQgCAACfAgIAABwoAgAAFHwCAACJ9AIAABDoA Date: Wed, 23 Jul 2014 16:45:17 +0000 Message-ID: <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.13.135] Content-Type: multipart/alternative; boundary="_000_04E6EF5CF36C49879BA6AF92408EEFCEmitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/dLsbqua8rub0lKm2ooaCoQg_Hv4 Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 16:45:23 -0000 --_000_04E6EF5CF36C49879BA6AF92408EEFCEmitreorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQncyBvbmx5ICJub3QgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50IiBiZWNhdXNlIHRoZSB0b2tl biBlbmRwb2ludCBjb3B5LXBhc3RlZCBhbmQgcmVuYW1lZCB0aGUgYXV0aGVudGljYXRpb24gZW5k cG9pbnQuDQoNCiAtLSBKdXN0aW4NCg0KT24gSnVsIDIzLCAyMDE0LCBhdCA5OjMwIEFNLCBUaG9t YXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+ IHdyb3RlOg0KDQpFeGNlcHQgdGhhdCB0aGVzZSBhcmUgYWJvdXQgbm90IHVzaW5nIHRoZSBUb2tl biBFbmRwb2ludCBhdCBhbGwsIHdoZXJlYXMgdGhlIGN1cnJlbnQgcHJvcG9zYWwgaXMgYWJvdXQg dGhlIFRva2VuIEVuZHBvaW50IG5vdCByZXR1cm5pbmcgYW4gYWNjZXNzX3Rva2VuIGZpZWxkIGlu IHRoZSBKU09OLg0KDQoNCk9uIFdlZCwgSnVsIDIzLCAyMDE0IGF0IDQ6MjYgUE0sIE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPj4gd3JvdGU6DQpUaGUgcmVzcG9uc2VfdHlwZSDigJxub25l4oCdIGlzIGFscmVh ZHkgdXNlZCBpbiBwcmFjdGljZSwgd2hpY2ggcmV0dXJucyBubyBhY2Nlc3MgdG9rZW4uICBJdCB3 YXMgYWNjZXB0ZWQgYnkgdGhlIGRlc2lnbmF0ZWQgZXhwZXJ0cyBhbmQgcmVnaXN0ZXJlZCBpbiB0 aGUgSUFOQSBPQXV0aCBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGVzIHJlZ2lz dHJ5IGF0IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9v YXV0aC1wYXJhbWV0ZXJzLnhtbCNlbmRwb2ludC4gIFRoZSByZWdpc3RlcmVkIOKAnGlkX3Rva2Vu 4oCdIHJlc3BvbnNlIHR5cGUgYWxzbyByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi4NCg0KU28gSSB0 aGluayB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciByZXNwb25zZSB0eXBlcyB0aGF0IHJlc3VsdCBp biBubyBhY2Nlc3MgdG9rZW4gYmVpbmcgcmV0dXJuZWQgYXJlIGFjY2VwdGFibGUgd2l0aGluIE9B dXRoIDIuMCBpcyBhbHJlYWR5IHNldHRsZWQsIGFzIGEgcHJhY3RpY2FsIG1hdHRlci4gIExvdHMg b2YgT0F1dGggaW1wbGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IHVzaW5nIHN1Y2ggcmVzcG9uc2Ug dHlwZXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFBo aWwgSHVudA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDc6MDkgQU0NClRvOiBOYXQg U2FraW11cmENCkNjOiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt aHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQNCg0KWWVzLiBUaGlzIGlzIHdoeSBpdCBoYXMg dG8gYmUgZGlzY3Vzc2VkIGluIHRoZSBJRVRGLg0KDQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3 d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8+DQpwaGls Lmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQpPbiBK dWwgMjMsIDIwMTQsIGF0IDk6NDMgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29t PG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQpSZWFkaW5nIGJhY2sgdGhl IFJGQzY3NDksIEkgYW0gbm90IHN1cmUgaWYgdGhlcmUgaXMgYSBnb29kIHdheSBvZiBzdXBwcmVz c2luZyBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgcmVzcG9uc2UgYW5kIHN0aWxsIGJlIE9BdXRoLiBJ dCB3aWxsIGJyZWFrIHdob2xlIGJ1bmNoIG9mIGltcGxpY2l0IGRlZmluaXRpb25zIGxpa2U6DQoN CmF1dGhvcml6YXRpb24gc2VydmVyDQogICAgICBUaGUgc2VydmVyIGlzc3VpbmcgYWNjZXNzIHRv a2VucyB0byB0aGUgY2xpZW50IGFmdGVyIHN1Y2Nlc3NmdWxseQ0KICAgICAgYXV0aGVudGljYXRp bmcgdGhlIHJlc291cmNlIG93bmVyIGFuZCBvYnRhaW5pbmcgYXV0aG9yaXphdGlvbi4NCg0KQWZ0 ZXIgYWxsLCBPQXV0aCBpcyBhbGwgYWJvdXQgaXNzdWluZyBhY2Nlc3MgdG9rZW5zLg0KDQpBbHNv LCBJIHRha2UgYmFjayBteSBzdGF0ZW1lbnQgb24gdGhlIGdyYW50IHR5cGUgaW4gbXkgcHJldmlv dXMgbWFpbC4NCg0KVGhlIGRlZmluaXRpb24gb2YgZ3JhbnQgYW5kIGdyYW50X3R5cGUgYXJlIHJl c3BlY3RpdmVseToNCg0KZ3JhbnQNCiAgICBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVz b3VyY2Ugb3duZXIncyBhdXRob3JpemF0aW9uDQoNCmdyYW50X3R5cGUNCiAgICAoc3RyaW5nIHJl cHJlc2VudGluZyB0aGUpIHR5cGUgb2YgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQg dG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW4NCg0KVGh1cywgdGhlIGdyYW50IHNlbnQgdG8gdGhl IHRva2VuIGVuZHBvaW50IGluIHRoaXMgY2FzZSBpcyBzdGlsbCAnY29kZScuDQoNClJlc3BvbnNl IHR5cGUgb24gdGhlIG90aGVyIGhhbmQgaXMgbm90IHNvIHdlbGwgZGVmaW5lZCBpbiBSRkM2NzQ5 LCBidXQgaXQgc2VlbXMgaXQgaXMgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQg ZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gVG8gZXhwcmVzcyB3aGF0IGlzIHRvIGJl IHJldHVybmVkIGZyb20gdG9rZW4gZW5kcG9pbnQsIHBlcmhhcHMgZGVmaW5pbmcgYSBuZXcgcGFy YW1ldGVyIHRvIHRoZSB0b2tlbiBlbmRwb2ludCwgd2hpY2ggaXMgYSBwYXJhbGxlbCB0byB0aGUg cmVzcG9uc2VfdHlwZSB0byB0aGUgQXV0aG9yaXphdGlvbiBFbmRwb2ludCBzZWVtcyB0byBiZSBh IG1vcmUgc3ltbWV0cmljIHdheSwgdGhvdWdoIEkgYW0gbm90IHN1cmUgYXQgYWxsIGlmIHRoYXQg aXMgZ29pbmcgdG8gYmUgT0F1dGggYW55IG1vcmUuIE9uZSBzdHJhdy1tYW4gaXMgdG8gZGVmaW5l IGEgbmV3IHBhcmFtZXRlciBjYWxsZWQgcmVzcG9uc2VfdHlwZSB0byB0aGUgdG9rZW4gZW5kcG9p bnQgc3VjaCBhczoNCg0KcmVzcG9uc2VfdHlwZQ0KICAgIE9QVElPTkFMLiBBIHN0cmluZyByZXBy ZXNlbnRpbmcgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludC4N Cg0KVGhlbiBkZWZpbmUgdGhlIGJlaGF2aW9yIG9mIHRoZSBlbmRwb2ludCBhY2NvcmRpbmcgdG8g dGhlIHZhbHVlcyBhcyB0aGUgcGFyYWxsZWwgdG8gdGhlIG11bHRpLXJlc3BvbnNlIHR5cGUgc3Bl Yy4NCmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29hdXRoLXYyLW11bHRpcGxlLXJlc3BvbnNlLXR5 cGVzLTFfMC5odG1sDQoNCk5hdA0KDQoNCg0KDQoyMDE0LTA3LTIzIDc6MjEgR01ULTA0OjAwIFBo aWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t Pj46DQpUaGUgZHJhZnQgaXMgdmVyeSBjbGVhci4NCg0KUGhpbA0KDQpPbiBKdWwgMjMsIDIwMTQs IGF0IDA6NDYsIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVy YUBnbWFpbC5jb20+PiB3cm90ZToNClRoZSBuZXcgZ3JhbnQgdHlwZSB0aGF0IEkgd2FzIHRhbGtp bmcgYWJvdXQgd2FzDQoiYXV0aG9yaXphdGlvbl9jb2RlX2J1dF9kb19ub3RfcmV0dXJuX2FjY2Vz c19ub3JfcmVmcmVzaF90b2tlbiIsIHNvIHRvIHNwZWFrLg0KSXQgZG9lcyBub3QgcmV0dXJuIGFu eXRoaW5nIHBlciBzZSwgYnV0IGFuIGV4dGVuc2lvbiBjYW4gZGVmaW5lIHNvbWV0aGluZyBvbiB0 b3Agb2YgaXQuDQoNClRoZW4sIE9JREMgY2FuIGRlZmluZSBhIGJpbmRpbmcgdG8gaXQgc28gdGhh dCB0aGUgYmluZGluZyBvbmx5IHJldHVybnMgSUQgVG9rZW4uDQpUaGlzIGJpbmRpbmcgd29yayBz aG91bGQgYmUgZG9uZSBpbiBPSURGLiBTaG91bGQgdGhlcmUgYmUgc3VjaCBhIGdyYW50IHR5cGUs DQppdCB3aWxsIGJlIGFuIGV4dHJlbWVseSBzaG9ydCBzcGVjLg0KDQpBdCB0aGUgc2FtZSB0aW1l LCBpZiBhbnkgb3RoZXIgc3BlY2lmaWNhdGlvbiB3YW50ZWQgdG8gZGVmaW5lDQpvdGhlciB0eXBl IG9mIHRva2VucyBhbmQgaGF2ZSBpdCByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCwN Cml0IGNhbiBhbHNvIHVzZSB0aGlzIGdyYW50IHR5cGUuDQoNCklmIHdoYXQgeW91IHdhbnQgaXMg dG8gZGVmaW5lIGEgbmV3IGdyYW50IHR5cGUgdGhhdCByZXR1cm5zIElEIFRva2VuIG9ubHksDQp0 aGVuLCBJIGFtIHdpdGggSnVzdGluLiBTaW5jZSAib3RoZXIgcmVzcG9uc2UgdGhhbiBJRCBUb2tl biIgaXMgb25seQ0KdGhlb3JldGljYWwsIHRoaXMgaXMgYSBtb3JlIHBsYXVzaWJsZSB3YXkgZm9y d2FyZCwgSSBzdXBwb3NlLg0KDQpOYXQNCg0KMjAxNC0wNy0yMiAxNDozMCBHTVQtMDQ6MDAgSnVz dGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PjoNClNv IHRoZSBkcmFmdCB3b3VsZCBsaXRlcmFsbHkgdHVybiBpbnRvOg0KDQoiVGhlIGE0YyByZXNwb25z ZSB0eXBlIGFuZCBncmFudCB0eXBlIHJldHVybiBhbiBpZF90b2tlbiBmcm9tIHRoZSB0b2tlbiBl bmRwb2ludCB3aXRoIG5vIGFjY2VzcyB0b2tlbi4gQWxsIHBhcmFtZXRlcnMgYW5kIHZhbHVlcyBh cmUgZGVmaW5lZCBpbiBPSURDLiINCg0KU2VlbXMgbGlrZSB0aGUgcGVyZmVjdCBtaW5pIGV4dGVu c2lvbiBkcmFmdCBmb3IgT0lERiB0byBkby4NCg0KLS1KdXN0aW4NCg0KL3NlbnQgZnJvbSBteSBw aG9uZS8NCg0KT24gSnVsIDIyLCAyMDE0IDEwOjI5IEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJh QGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQo+DQo+IFdoYXQg YWJvdXQganVzdCBkZWZpbmluZyBhIG5ldyBncmFudCB0eXBlIGluIHRoaXMgV0c/DQo+DQo+DQo+ IDIwMTQtMDctMjIgMTI6NTYgR01ULTA0OjAwIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj46DQo+Pg0KPj4gVGhhdCB3b3VsZCBiZSBu aWNlLiBIb3dldmVyIG9pZGMgc3RpbGwgbmVlZHMgdGhlIG5ldyBncmFudCB0eXBlIGluIG9yZGVy IHRvIGltcGxlbWVudCB0aGUgc2FtZSBmbG93Lg0KPj4NCj4+IFBoaWwNCj4+DQo+PiBPbiBKdWwg MjIsIDIwMTQsIGF0IDExOjM1LCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWls dG86c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQo+Pg0KPj4+ICsxIHRvIEp1c3Rpbi4NCj4+ Pg0KPj4+DQo+Pj4gMjAxNC0wNy0yMiA5OjU0IEdNVC0wNDowMCBSaWNoZXIsIEp1c3RpbiBQLiA8 anJpY2hlckBtaXRyZS5vcmc8bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPj46DQo+Pj4+DQo+Pj4+ IEVycm9ycyBsaWtlIHRoZXNlIG1ha2UgaXQgY2xlYXIgdG8gbWUgdGhhdCBpdCB3b3VsZCBtYWtl IG11Y2ggbW9yZSBzZW5zZSB0byBkZXZlbG9wIHRoaXMgZG9jdW1lbnQgaW4gdGhlIE9wZW5JRCBG b3VuZGF0aW9uLiBJdCBzaG91bGQgYmUgc29tZXRoaW5nIHRoYXQgZGlyZWN0bHkgcmVmZXJlbmNl cyBPcGVuSUQgQ29ubmVjdCBDb3JlIGZvciBhbGwgb2YgdGhlc2UgdGVybXMgaW5zdGVhZCBvZiBy ZWRlZmluaW5nIHRoZW0uIEl0J3MgZG9pbmcgYXV0aGVudGljYXRpb24sIHdoaWNoIGlzIGZ1bmRh bWVudGFsbHkgd2hhdCBPcGVuSUQgQ29ubmVjdCBkb2VzIG9uIHRvcCBvZiBPQXV0aCwgYW5kIEkg ZG9uJ3Qgc2VlIGEgZ29vZCBhcmd1bWVudCBmb3IgZG9pbmcgdGhpcyB3b3JrIGluIHRoaXMgd29y a2luZyBncm91cC4NCj4+Pj4NCj4+Pj4gIC0tIEp1c3Rpbg0KPj4+Pg0KPj4+PiBPbiBKdWwgMjIs IDIwMTQsIGF0IDQ6MzAgQU0sIFRob21hcyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxtYWls dG86dC5icm95ZXJAZ21haWwuY29tPj4gd3JvdGU6DQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+PiBPbiBNb24sIEp1bCAyMSwgMjAxNCBhdCAxMTo1MiBQTSwgTWlrZSBKb25lcyA8TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b20+PiB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcyBmb3IgeW91ciByZXZpZXcsIFRob21h cy4gIFRoZSDigJxwcm9tcHQ9Y29uc2VudOKAnSBkZWZpbml0aW9uIGJlaW5nIG1pc3NpbmcgaXMg YW4gZWRpdG9yaWFsIGVycm9yLiAgSXQgc2hvdWxkIGJlOg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+ Pg0KPj4+Pj4+IGNvbnNlbnQNCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBBdXRob3JpemF0aW9uIFNlcnZl ciBTSE9VTEQgcHJvbXB0IHRoZSBFbmQtVXNlciBmb3IgY29uc2VudCBiZWZvcmUgcmV0dXJuaW5n IGluZm9ybWF0aW9uIHRvIHRoZSBDbGllbnQuIElmIGl0IGNhbm5vdCBvYnRhaW4gY29uc2VudCwg aXQgTVVTVCByZXR1cm4gYW4gZXJyb3IsIHR5cGljYWxseSBjb25zZW50X3JlcXVpcmVkLg0KPj4+ Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEnigJlsbCBwbGFuIHRvIGFkZCBpdCBpbiB0aGUg bmV4dCBkcmFmdC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gSXQgbG9va3MgbGlrZSB0aGUgY29uc2Vu dF9yZXF1aXJlZCBlcnJvciBuZWVkcyB0byBiZSBkZWZpbmVkIHRvbywgYW5kIHlvdSBtaWdodCBo YXZlIGZvcmdvdHRlbiB0byBhbHNvIGltcG9ydCBhY2NvdW50X3NlbGVjdGlvbl9yZXF1aXJlZCBm cm9tIE9wZW5JRCBDb25uZWN0Lg0KPj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+ PiBJIGFncmVlIHRoYXQgdGhlcmXigJlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJlc3BvbnNl IHdpdGggbXVsdGlwbGUg4oCcYW1y4oCdIHZhbHVlcyB0aGF0IGluY2x1ZGVzIOKAnG1mYeKAnSBh bmQgb25lIHRoYXQgZG9lc27igJl0LiAgVW5sZXNzIGEgY2xlYXIgdXNlIGNhc2UgZm9yIHdoeSDi gJxtZmHigJ0gaXMgbmVlZGVkIGNhbiBiZSBpZGVudGlmaWVkLCB3ZSBjYW4gZGVsZXRlIGl0IGlu IHRoZSBuZXh0IGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MuDQo+Pj4+Pg0KPj4+ Pj4gSG93IGFib3V0ICJwd2QiIHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IEkgc2hvdWxk IHJldHVybiAicHdkIiBpZiB0aGUgdXNlciBhdXRoZW50aWNhdGVkIHVzaW5nIGEgcGFzc3dvcmQs IGJ1dCB3aGF0ICJ0aGUgc2VydmljZSBpZiBhIGNsaWVudCBzZWNyZXQgaXMgdXNlZCIgbWVhbnMg aW4gdGhlIGRlZmluaXRpb24gZm9yIHRoZSAicHdkIiB2YWx1ZT8NCj4+Pj4+DQo+Pj4+PiAoTm90 YTogSSBrbm93IHlvdSdyZSBhdCBJRVRGLTkwLCBJJ20gcmVhZHkgdG8gd2FpdCAndGlsIHlvdSBj b21lIGJhY2sgOy0pICkNCj4+Pj4+DQo+Pj4+PiAtLQ0KPj4+Pj4gVGhvbWFzIEJyb3llcg0KPj4+ Pj4gL3TJlC5tYS5iyoF3YS5qZS88aHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvPg0K Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4gT0F1dGhA aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0NCj4+ PiBOYXQgU2FraW11cmEgKD1uYXQpDQo+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQo+ Pj4gaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQo+Pj4gQF9uYXRfZW4NCj4+Pg0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gT0F1dGggbWFp bGluZyBsaXN0DQo+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4NCj4NCj4N Cj4gLS0NCj4gTmF0IFNha2ltdXJhICg9bmF0KQ0KPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRp b24NCj4gaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQo+IEBfbmF0X2VuDQoNCg0KDQotLQ0KTmF0 IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0 LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0K Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBf bmF0X2VuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0K DQotLQ0KVGhvbWFzIEJyb3llcg0KL3TJlC5tYS5iyoF3YS5qZS88aHR0cDovL3huLS1ubmEubWEu eG4tLWJ3YS14eGIuamUvPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K DQo= --_000_04E6EF5CF36C49879BA6AF92408EEFCEmitreorg_ Content-Type: text/html; charset="utf-8" Content-ID: <7FB25BF88926434EAA49BC466EAF2DC2@imc.mitre.org> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KSXQncyBvbmx5ICZxdW90O25vdCB1c2luZyB0aGUg dG9rZW4gZW5kcG9pbnQmcXVvdDsgYmVjYXVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgY29weS1wYXN0 ZWQgYW5kIHJlbmFtZWQgdGhlIGF1dGhlbnRpY2F0aW9uIGVuZHBvaW50Lg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+Jm5ic3A7LS0gSnVzdGluPC9kaXY+DQo8ZGl2Pjxicj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj5PbiBKdWwgMjMsIDIwMTQsIGF0IDk6MzAgQU0sIFRob21hcyBCcm95ZXIgJmx0Ozxh IGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iPnQuYnJveWVyQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+RXhjZXB0IHRoYXQgdGhl c2UgYXJlIGFib3V0IG5vdCB1c2luZyB0aGUgVG9rZW4gRW5kcG9pbnQgYXQgYWxsLCB3aGVyZWFz IHRoZSBjdXJyZW50IHByb3Bvc2FsIGlzIGFib3V0IHRoZSBUb2tlbiBFbmRwb2ludCBub3QgcmV0 dXJuaW5nIGFuIGFjY2Vzc190b2tlbiBmaWVsZCBpbiB0aGUgSlNPTi48L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24g V2VkLCBKdWwgMjMsIDIwMTQgYXQgNDoyNiBQTSwgTWlrZSBKb25lcyA8c3BhbiBkaXI9Imx0ciI+ DQombHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90 ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxk aXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdk Ij5UaGUgcmVzcG9uc2VfdHlwZSDigJxub25l4oCdIGlzIGFscmVhZHkgdXNlZCBpbiBwcmFjdGlj ZSwgd2hpY2ggcmV0dXJucyBubyBhY2Nlc3MgdG9rZW4uJm5ic3A7IEl0IHdhcyBhY2NlcHRlZCBi eSB0aGUgZGVzaWduYXRlZCBleHBlcnRzIGFuZCByZWdpc3RlcmVkIGluIHRoZSBJQU5BIE9BdXRo DQogQXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNwb25zZSBUeXBlcyByZWdpc3RyeSBhdCA8YSBo cmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29hdXRoLXBhcmFtZXRlcnMvb2F1 dGgtcGFyYW1ldGVycy54bWwjZW5kcG9pbnQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cu aWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnht bCNlbmRwb2ludDwvYT4uJm5ic3A7IFRoZSByZWdpc3RlcmVkIOKAnGlkX3Rva2Vu4oCdIHJlc3Bv bnNlIHR5cGUgYWxzbyByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi48dT48L3U+PHU+PC91Pjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPlNv IEkgdGhpbmsgdGhlIHF1ZXN0aW9uIG9mIHdoZXRoZXIgcmVzcG9uc2UgdHlwZXMgdGhhdCByZXN1 bHQgaW4gbm8gYWNjZXNzIHRva2VuIGJlaW5nIHJldHVybmVkIGFyZSBhY2NlcHRhYmxlIHdpdGhp biBPQXV0aCAyLjAgaXMgYWxyZWFkeSBzZXR0bGVkLCBhcyBhIHByYWN0aWNhbA0KIG1hdHRlci4m bmJzcDsgTG90cyBvZiBPQXV0aCBpbXBsZW1lbnRhdGlvbnMgYXJlIGFscmVhZHkgdXNpbmcgc3Vj aCByZXNwb25zZSB0eXBlcy48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+PHU+PC91 PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNi NWM0ZGYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQ8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDc6MDkgQU08YnI+DQo8Yj5Ubzo8L2I+IE5hdCBTYWtp bXVyYTxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtPQVVUSC1XR10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50 LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMuIFRoaXMg aXMgd2h5IGl0IGhhcyB0byBiZSBkaXNjdXNzZWQgaW4gdGhlIElFVEYuPHU+PC91Pjx1PjwvdT48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyI+UGhpbDx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fucy1z ZXJpZjsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1p bHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsiPkBpbmRlcGVuZGVudGlkPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyI+ PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iIHRhcmdldD0iX2JsYW5rIj53 d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhLCBzYW5zLXNlcmlmOyI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7Ij48dT48L3U+Jm5ic3A7 PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48 L3U+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91 PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVsIDIzLCAyMDE0 LCBhdCA5OjQzIEFNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyPg0KPHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVh ZGluZyBiYWNrIHRoZSBSRkM2NzQ5LCBJIGFtIG5vdCBzdXJlIGlmIHRoZXJlIGlzIGEgZ29vZCB3 YXkgb2Ygc3VwcHJlc3NpbmcgYWNjZXNzIHRva2VuIGZyb20gdGhlIHJlc3BvbnNlIGFuZCBzdGls bCBiZSBPQXV0aC4gSXQgd2lsbCBicmVhayB3aG9sZSBidW5jaCBvZiBpbXBsaWNpdCBkZWZpbml0 aW9ucyBsaWtlOiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hdXRob3JpemF0aW9uIHNlcnZlcjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBz ZXJ2ZXIgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0ZXIgc3VjY2Vzc2Z1 bGx5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYXV0aGVudGljYXRpbmcgdGhlIHJlc291cmNl IG93bmVyIGFuZCBvYnRhaW5pbmcgYXV0aG9yaXphdGlvbi48dT48L3U+PHU+PC91PjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFmdGVyIGFsbCwgT0F1dGggaXMgYWxsIGFi b3V0IGlzc3VpbmcgYWNjZXNzIHRva2Vucy4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgSSB0YWtlIGJhY2sgbXkg c3RhdGVtZW50IG9uIHRoZSBncmFudCB0eXBlIGluIG15IHByZXZpb3VzIG1haWwuJm5ic3A7PHU+ PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48 L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBkZWZpbml0aW9uIG9mIGdyYW50IGFuZCBncmFudF90eXBlIGFyZSByZXNwZWN0aXZlbHk6 Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5ncmFudCZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBjcmVkZW50aWFsIHJlcHJl c2VudGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBhdXRob3JpemF0aW9uPHU+PC91Pjx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPHU+PC91 Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ncmFudF90 eXBlPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsmbmJzcDsgKHN0cmluZyByZXByZXNlbnRpbmcgdGhlKSB0eXBlIG9mIGdy YW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IHRvIG9idGFpbiB0aGUgYWNjZXNzIHRva2Vu PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGh1cywgdGhlIGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IGlu IHRoaXMgY2FzZSBpcyBzdGlsbCAnY29kZScuJm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlc3BvbnNlIHR5cGUgb24gdGhl IG90aGVyIGhhbmQgaXMgbm90IHNvIHdlbGwgZGVmaW5lZCBpbiBSRkM2NzQ5LCBidXQgaXQgc2Vl bXMgaXQgaXMgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUgYXV0 aG9yaXphdGlvbiBlbmRwb2ludC4gVG8gZXhwcmVzcyB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZy b20gdG9rZW4gZW5kcG9pbnQsIHBlcmhhcHMgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVyDQogdG8g dGhlIHRva2VuIGVuZHBvaW50LCB3aGljaCBpcyBhIHBhcmFsbGVsIHRvIHRoZSByZXNwb25zZV90 eXBlIHRvIHRoZSBBdXRob3JpemF0aW9uIEVuZHBvaW50IHNlZW1zIHRvIGJlIGEgbW9yZSBzeW1t ZXRyaWMgd2F5LCB0aG91Z2ggSSBhbSBub3Qgc3VyZSBhdCBhbGwgaWYgdGhhdCBpcyBnb2luZyB0 byBiZSBPQXV0aCBhbnkgbW9yZS4gT25lIHN0cmF3LW1hbiBpcyB0byBkZWZpbmUgYSBuZXcgcGFy YW1ldGVyIGNhbGxlZCByZXNwb25zZV90eXBlDQogdG8gdGhlIHRva2VuIGVuZHBvaW50IHN1Y2gg YXM6Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnJlc3BvbnNlX3R5cGU8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgT1BUSU9OQUwuIEEgc3RyaW5n IHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBv aW50LiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlbiBkZWZpbmUgdGhlIGJlaGF2aW9yIG9mIHRo ZSBlbmRwb2ludCBhY2NvcmRpbmcgdG8gdGhlIHZhbHVlcyBhcyB0aGUgcGFyYWxsZWwgdG8gdGhl IG11bHRpLXJlc3BvbnNlIHR5cGUgc3BlYy4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0 L3NwZWNzL29hdXRoLXYyLW11bHRpcGxlLXJlc3BvbnNlLXR5cGVzLTFfMC5odG1sIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb2F1dGgtdjItbXVsdGlwbGUtcmVzcG9u c2UtdHlwZXMtMV8wLmh0bWw8L2E+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdDx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyZuYnNwOzx1PjwvdT48dT48 L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNw Ozx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+ Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE0LTA3LTIzIDc6MjEgR01ULTA0OjAw IFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozo8dT48L3U+PHU+PC91Pjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRyYWZ0IGlzIHZlcnkg Y2xlYXIuJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxzcGFu PlBoaWw8L3NwYW4+PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCk9uIEp1bCAyMywgMjAxNCwgYXQgMDo0NiwgTmF0IFNha2ltdXJhICZsdDs8YSBo cmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBuZXcgZ3JhbnQgdHlwZSB0aGF0IEkgd2FzIHRh bGtpbmcgYWJvdXQgd2FzJm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+JnF1b3Q7YXV0aG9yaXphdGlvbl9jb2RlX2J1dF9kb19ub3RfcmV0dXJuX2Fj Y2Vzc19ub3JfcmVmcmVzaF90b2tlbiZxdW90Oywgc28gdG8gc3BlYWsuJm5ic3A7PHU+PC91Pjx1 PjwvdT48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGRvZXMgbm90 IHJldHVybiBhbnl0aGluZyBwZXIgc2UsIGJ1dCBhbiBleHRlbnNpb24gY2FuIGRlZmluZSBzb21l dGhpbmcgb24gdG9wIG9mIGl0LiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVuLCBPSURDIGNhbiBkZWZpbmUgYSBiaW5k aW5nIHRvIGl0IHNvIHRoYXQgdGhlIGJpbmRpbmcgb25seSByZXR1cm5zIElEIFRva2VuLiZuYnNw Ozx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyBiaW5kaW5nIHdvcmsgc2hvdWxkIGJlIGRvbmUgaW4gT0lERi4gU2hvdWxkIHRoZXJlIGJl IHN1Y2ggYSBncmFudCB0eXBlLCZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPml0IHdpbGwgYmUgYW4gZXh0 cmVtZWx5IHNob3J0IHNwZWMuJm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IHRoZSBzYW1lIHRpbWUsIGlmIGFueSBvdGhl ciBzcGVjaWZpY2F0aW9uIHdhbnRlZCB0byBkZWZpbmUmbmJzcDs8dT48L3U+PHU+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm90aGVyIHR5cGUgb2YgdG9rZW5z IGFuZCBoYXZlIGl0IHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LCZuYnNwOzx1Pjwv dT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXQgY2Fu IGFsc28gdXNlIHRoaXMgZ3JhbnQgdHlwZS4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2hhdCB5b3Ugd2FudCBpcyB0 byBkZWZpbmUgYSBuZXcgZ3JhbnQgdHlwZSB0aGF0IHJldHVybnMgSUQgVG9rZW4gb25seSwmbmJz cDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnRoZW4sIEkgYW0gd2l0aCBKdXN0aW4uIFNpbmNlICZxdW90O290aGVyIHJlc3BvbnNlIHRoYW4g SUQgVG9rZW4mcXVvdDsgaXMgb25seSZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlb3JldGljYWwsIHRoaXMgaXMgYSBtb3JlIHBs YXVzaWJsZSB3YXkgZm9yd2FyZCwgSSBzdXBwb3NlLiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQ8dT48L3U+PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE0LTA3LTIyIDE0OjMwIEdNVC0wNDowMCBKdXN0aW4gUmlj aGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+ anJpY2hlckBtaXQuZWR1PC9hPiZndDs6PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TbyB0aGUgZHJhZnQgd291bGQgbGl0ZXJhbGx5IHR1cm4gaW50bzo8YnI+DQo8YnI+ DQomcXVvdDtUaGUgYTRjIHJlc3BvbnNlIHR5cGUgYW5kIGdyYW50IHR5cGUgcmV0dXJuIGFuIGlk X3Rva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IHdpdGggbm8gYWNjZXNzIHRva2VuLiBBbGwg cGFyYW1ldGVycyBhbmQgdmFsdWVzIGFyZSBkZWZpbmVkIGluIE9JREMuJnF1b3Q7PGJyPg0KPGJy Pg0KU2VlbXMgbGlrZSB0aGUgcGVyZmVjdCBtaW5pIGV4dGVuc2lvbiBkcmFmdCBmb3IgT0lERiB0 byBkby48YnI+DQo8YnI+DQotLUp1c3Rpbjxicj4NCjxicj4NCi9zZW50IGZyb20gbXkgcGhvbmUv PHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT24g SnVsIDIyLCAyMDE0IDEwOjI5IEFNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpz YWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGF0IGFib3V0IGp1c3QgZGVmaW5pbmcg YSBuZXcgZ3JhbnQgdHlwZSBpbiB0aGlzIFdHPzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 OyAyMDE0LTA3LTIyIDEyOjU2IEdNVC0wNDowMCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUu Y29tPC9hPiZndDs6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGF0IHdvdWxkIGJlIG5p Y2UuIEhvd2V2ZXIgb2lkYyBzdGlsbCBuZWVkcyB0aGUgbmV3IGdyYW50IHR5cGUgaW4gb3JkZXIg dG8gaW1wbGVtZW50IHRoZSBzYW1lIGZsb3cuJm5ic3A7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBQaGlsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiBKdWwgMjIsIDIwMTQsIGF0 IDExOjM1LCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmIzQzOzEgdG8gSnVzdGluLiZuYnNwOzxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAyMDE0LTA3 LTIyIDk6NTQgR01ULTA0OjAwIFJpY2hlciwgSnVzdGluIFAuICZsdDs8YSBocmVmPSJtYWlsdG86 anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4m Z3Q7Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEVycm9ycyBs aWtlIHRoZXNlIG1ha2UgaXQgY2xlYXIgdG8gbWUgdGhhdCBpdCB3b3VsZCBtYWtlIG11Y2ggbW9y ZSBzZW5zZSB0byBkZXZlbG9wIHRoaXMgZG9jdW1lbnQgaW4gdGhlIE9wZW5JRCBGb3VuZGF0aW9u LiBJdCBzaG91bGQgYmUgc29tZXRoaW5nIHRoYXQgZGlyZWN0bHkgcmVmZXJlbmNlcyBPcGVuSUQg Q29ubmVjdCBDb3JlIGZvciBhbGwgb2YgdGhlc2UgdGVybXMgaW5zdGVhZCBvZiByZWRlZmluaW5n IHRoZW0uIEl0J3MgZG9pbmcNCiBhdXRoZW50aWNhdGlvbiwgd2hpY2ggaXMgZnVuZGFtZW50YWxs eSB3aGF0IE9wZW5JRCBDb25uZWN0IGRvZXMgb24gdG9wIG9mIE9BdXRoLCBhbmQgSSBkb24ndCBz ZWUgYSBnb29kIGFyZ3VtZW50IGZvciBkb2luZyB0aGlzIHdvcmsgaW4gdGhpcyB3b3JraW5nIGdy b3VwLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOy0t IEp1c3Rpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE9uIEp1 bCAyMiwgMjAxNCwgYXQgNDozMCBBTSwgVGhvbWFzIEJyb3llciAmbHQ7PGEgaHJlZj0ibWFpbHRv OnQuYnJveWVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnQuYnJveWVyQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBNb24sIEp1bCAyMSwgMjAxNCBhdCAxMTo1MiBQ TSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBUaGFua3MgZm9yIHlvdXIgcmV2aWV3LCBUaG9tYXMuJm5ic3A7IFRoZSDigJxw cm9tcHQ9Y29uc2VudOKAnSBkZWZpbml0aW9uIGJlaW5nIG1pc3NpbmcgaXMgYW4gZWRpdG9yaWFs IGVycm9yLiZuYnNwOyBJdCBzaG91bGQgYmU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOzxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb25zZW50PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBB dXRob3JpemF0aW9uIFNlcnZlciBTSE9VTEQgcHJvbXB0IHRoZSBFbmQtVXNlciBmb3IgY29uc2Vu dCBiZWZvcmUgcmV0dXJuaW5nIGluZm9ybWF0aW9uIHRvIHRoZSBDbGllbnQuIElmIGl0IGNhbm5v dCBvYnRhaW4gY29uc2VudCwgaXQgTVVTVCByZXR1cm4gYW4gZXJyb3IsIHR5cGljYWxseSBjb25z ZW50X3JlcXVpcmVkLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSeKAmWxsIHBsYW4gdG8gYWRkIGl0IGluIHRoZSBu ZXh0IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBsb29rcyBsaWtlIHRoZSBjb25zZW50 X3JlcXVpcmVkIGVycm9yIG5lZWRzIHRvIGJlIGRlZmluZWQgdG9vLCBhbmQgeW91IG1pZ2h0IGhh dmUgZm9yZ290dGVuIHRvIGFsc28gaW1wb3J0IGFjY291bnRfc2VsZWN0aW9uX3JlcXVpcmVkIGZy b20gT3BlbklEIENvbm5lY3QuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZu YnNwOzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBJIGFncmVlIHRoYXQgdGhlcmXigJlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJl c3BvbnNlIHdpdGggbXVsdGlwbGUg4oCcYW1y4oCdIHZhbHVlcyB0aGF0IGluY2x1ZGVzIOKAnG1m YeKAnSBhbmQgb25lIHRoYXQgZG9lc27igJl0LiZuYnNwOyBVbmxlc3MgYSBjbGVhciB1c2UgY2Fz ZSBmb3Igd2h5IOKAnG1mYeKAnSBpcyBuZWVkZWQgY2FuIGJlIGlkZW50aWZpZWQsIHdlIGNhbiBk ZWxldGUgaXQgaW4gdGhlIG5leHQgZHJhZnQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcy48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhvdyBh Ym91dCAmcXVvdDtwd2QmcXVvdDsgdGhlbj8gSSBmdWxseSB1bmRlcnN0YW5kIHRoYXQgSSBzaG91 bGQgcmV0dXJuICZxdW90O3B3ZCZxdW90OyBpZiB0aGUgdXNlciBhdXRoZW50aWNhdGVkIHVzaW5n IGEgcGFzc3dvcmQsIGJ1dCB3aGF0ICZxdW90O3RoZSBzZXJ2aWNlIGlmIGEgY2xpZW50IHNlY3Jl dCBpcyB1c2VkJnF1b3Q7IG1lYW5zIGluIHRoZSBkZWZpbml0aW9uIGZvciB0aGUgJnF1b3Q7cHdk JnF1b3Q7IHZhbHVlPzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgKE5vdGE6IEkga25vdyB5b3UncmUgYXQgSUVURi05MCwgSSdtIHJlYWR5IHRvIHdh aXQgJ3RpbCB5b3UgY29tZSBiYWNrIDstKSApPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRob21h cyBCcm95ZXI8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAvdDxhIGhyZWY9Imh0dHA6Ly94bi0t bm5hLm1hLnhuLS1id2EteHhiLmplLyIgdGFyZ2V0PSJfYmxhbmsiPsmULm1hLmLKgXdhLmplLzwv YT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxp bmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7IC0tPGJyPg0KJmd0OyZndDsmZ3Q7IE5hdCBTYWtpbXVyYSAoPW5hdCk8YnI+DQomZ3Q7Jmd0 OyZndDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhy ZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQu c2FraW11cmEub3JnLzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgQF9uYXRfZW48YnI+DQomZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4NCiZndDsgTmF0IFNh a2ltdXJhICg9bmF0KTxicj4NCiZndDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0K Jmd0OyA8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KJmd0OyBAX25hdF9lbjx1PjwvdT48dT48 L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBj bGVhcj0iYWxsIj4NCjx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tLSA8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpPHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KPGEg aHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25h dC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8dT48L3U+PHU+ PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KTmF0IFNha2ltdXJh ICg9bmF0KTx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNo YWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11 cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+ DQpAX25hdF9lbjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxi cj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0K PGRpdj48YnI+DQo8L2Rpdj4NCi0tIDxicj4NClRob21hcyBCcm95ZXI8YnI+DQovdDxhIGhyZWY9 Imh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhiLmplLyI+yZQubWEuYsqBd2EuamUvPC9hPiA8 L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_04E6EF5CF36C49879BA6AF92408EEFCEmitreorg_-- From nobody Wed Jul 23 09:48:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176161A036A for ; Wed, 23 Jul 2014 09:48:31 -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=[AC_DIV_BONANZA=0.001, 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 EuNFbzviYK-o for ; Wed, 23 Jul 2014 09:48:27 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C2F1A0319 for ; Wed, 23 Jul 2014 09:48:26 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id pv20so1163199lab.29 for ; Wed, 23 Jul 2014 09:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xpR9f088VaQtiOSuxxW0AnP45+L6aJWBlk+GgcBR224=; b=ipFD9BstYGQQeFpFOhCMIv5UfV6MJkTZ8gymTQc+v5iQLZSSmZKAXLWD5EWyHaj/N2 eaIHqi++tHMtvXMU1SFGnhA5kNCTwAXUZjdr0DE1V4+/oAbz3wkEZ8V6aKjWDDc/ncn7 Gec0AyKruf75m2ezmZIliWeMXtXW7oMY5zt9rVaL2Cv3fauu1WJAUU340yUMvAu6GPzg CTwHkRcU/BUWZ+SPE7VOIfY/ngpFRnj5v1ABamk3f1zlybww3GoyfsyD1geqkDg4zjfD zbs2IQ6wEXF95dJ8np5DPmq1sGYcq54G952s9jfVh9+yLKNJBbzMTyd+v//DZ5QwKKlQ UzOw== X-Received: by 10.112.255.36 with SMTP id an4mr2738925lbd.31.1406134104810; Wed, 23 Jul 2014 09:48:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.113.73 with HTTP; Wed, 23 Jul 2014 09:48:04 -0700 (PDT) In-Reply-To: <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> From: Thomas Broyer Date: Wed, 23 Jul 2014 18:48:04 +0200 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=001a1134d438d2ed1704fedf1bef Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TuNnI4dHDOObznut3r2EbQF6Kww Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 16:48:31 -0000 --001a1134d438d2ed1704fedf1bef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No, I mean response_type=3Dnone and response_type=3Did_token don't generate= a code or access token so you don't use the Token Endpoint (which is not the same as the Authentication Endpoint BTW). With response_type=3Dcode_for_id_token, you get a code and exchange it for = an id_token only, rather than an access_token, so you're changing the semantics of the Token Endpoint. I'm not saying it's a bad thing, just that you can't really compare none and id_token with code_for_id_token. On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. wrote: > It's only "not using the token endpoint" because the token endpoint > copy-pasted and renamed the authentication endpoint. > > -- Justin > > On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: > > Except that these are about not using the Token Endpoint at all, whereas > the current proposal is about the Token Endpoint not returning an > access_token field in the JSON. > > > On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones > wrote: > >> The response_type =E2=80=9Cnone=E2=80=9D is already used in practice, w= hich returns no >> access token. It was accepted by the designated experts and registered = in >> the IANA OAuth Authorization Endpoint Response Types registry at >> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#en= dpoint. >> The registered =E2=80=9Cid_token=E2=80=9D response type also returns no = access token. >> >> >> >> So I think the question of whether response types that result in no >> access token being returned are acceptable within OAuth 2.0 is already >> settled, as a practical matter. Lots of OAuth implementations are alrea= dy >> using such response types. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt >> *Sent:* Wednesday, July 23, 2014 7:09 AM >> *To:* Nat Sakimura >> *Cc:* >> *Subject:* Re: [OAUTH-WG] New Version Notification for >> draft-hunt-oauth-v2-user-a4c-05.txt >> >> >> >> Yes. This is why it has to be discussed in the IETF. >> >> >> >> Phil >> >> >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: >> >> >> >> Reading back the RFC6749, I am not sure if there is a good way of >> suppressing access token from the response and still be OAuth. It will >> break whole bunch of implicit definitions like: >> >> >> >> authorization server >> The server issuing access tokens to the client after successfully >> authenticating the resource owner and obtaining authorization. >> >> >> >> After all, OAuth is all about issuing access tokens. >> >> >> >> Also, I take back my statement on the grant type in my previous mail. >> >> >> >> The definition of grant and grant_type are respectively: >> >> >> >> grant >> >> credential representing the resource owner's authorization >> >> >> >> grant_type >> >> (string representing the) type of grant sent to the token endpoint t= o >> obtain the access token >> >> >> >> Thus, the grant sent to the token endpoint in this case is still 'code'. >> >> >> >> Response type on the other hand is not so well defined in RFC6749, but i= t >> seems it is representing what is to be returned from the authorization >> endpoint. To express what is to be returned from token endpoint, perhaps >> defining a new parameter to the token endpoint, which is a parallel to t= he >> response_type to the Authorization Endpoint seems to be a more symmetric >> way, though I am not sure at all if that is going to be OAuth any more. = One >> straw-man is to define a new parameter called response_type to the token >> endpoint such as: >> >> >> >> response_type >> >> OPTIONAL. A string representing what is to be returned from the toke= n >> endpoint. >> >> >> >> Then define the behavior of the endpoint according to the values as the >> parallel to the multi-response type spec. >> >> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >> >> >> >> Nat >> >> >> >> >> >> >> >> >> >> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >> >> The draft is very clear. >> >> Phil >> >> >> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >> >> The new grant type that I was talking about was >> >> "authorization_code_but_do_not_return_access_nor_refresh_token", so to >> speak. >> >> It does not return anything per se, but an extension can define somethin= g >> on top of it. >> >> >> >> Then, OIDC can define a binding to it so that the binding only returns I= D >> Token. >> >> This binding work should be done in OIDF. Should there be such a grant >> type, >> >> it will be an extremely short spec. >> >> >> >> At the same time, if any other specification wanted to define >> >> other type of tokens and have it returned from the token endpoint, >> >> it can also use this grant type. >> >> >> >> If what you want is to define a new grant type that returns ID Token >> only, >> >> then, I am with Justin. Since "other response than ID Token" is only >> >> theoretical, this is a more plausible way forward, I suppose. >> >> >> >> Nat >> >> >> >> 2014-07-22 14:30 GMT-04:00 Justin Richer : >> >> So the draft would literally turn into: >> >> "The a4c response type and grant type return an id_token from the token >> endpoint with no access token. All parameters and values are defined in >> OIDC." >> >> Seems like the perfect mini extension draft for OIDF to do. >> >> --Justin >> >> /sent from my phone/ >> >> >> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >> > >> > What about just defining a new grant type in this WG? >> > >> > >> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >> >> >> >> That would be nice. However oidc still needs the new grant type in >> order to implement the same flow. >> >> >> >> Phil >> >> >> >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: >> >> >> >>> +1 to Justin. >> >>> >> >>> >> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >> >>>> >> >>>> Errors like these make it clear to me that it would make much more >> sense to develop this document in the OpenID Foundation. It should be >> something that directly references OpenID Connect Core for all of these >> terms instead of redefining them. It's doing authentication, which is >> fundamentally what OpenID Connect does on top of OAuth, and I don't see = a >> good argument for doing this work in this working group. >> >>>> >> >>>> -- Justin >> >>>> >> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer >> wrote: >> >>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < >> Michael.Jones@microsoft.com> wrote: >> >>>>>> >> >>>>>> Thanks for your review, Thomas. The =E2=80=9Cprompt=3Dconsent=E2= =80=9D definition >> being missing is an editorial error. It should be: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> consent >> >>>>>> >> >>>>>> The Authorization Server SHOULD prompt the End-User for consent >> before returning information to the Client. If it cannot obtain consent,= it >> MUST return an error, typically consent_required. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I=E2=80=99ll plan to add it in the next draft. >> >>>>> >> >>>>> >> >>>>> It looks like the consent_required error needs to be defined too, >> and you might have forgotten to also import account_selection_required f= rom >> OpenID Connect. >> >>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I agree that there=E2=80=99s no difference between a response wit= h >> multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80=9Cmfa=E2=80= =9D and one that doesn=E2=80=99t. Unless a >> clear use case for why =E2=80=9Cmfa=E2=80=9D is needed can be identified= , we can delete it >> in the next draft. >> >>>>> >> >>>>> >> >>>>> Thanks. >> >>>>> >> >>>>> How about "pwd" then? I fully understand that I should return "pwd= " >> if the user authenticated using a password, but what "the service if a >> client secret is used" means in the definition for the "pwd" value? >> >>>>> >> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come >> back ;-) ) >> >>>>> >> >>>>> -- >> >>>>> Thomas Broyer >> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >> >>>>> _______________________________________________ >> >>>>> 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 >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Nat Sakimura (=3Dnat) >> >>> Chairman, OpenID Foundation >> >>> http://nat.sakimura.org/ >> >>> @_nat_en >> >>> >> >>> _______________________________________________ >> >>> OAuth mailing list >> >>> OAuth@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > >> > -- >> > Nat Sakimura (=3Dnat) >> > Chairman, OpenID Foundation >> > http://nat.sakimura.org/ >> > @_nat_en >> >> >> >> >> >> -- >> Nat Sakimura (=3Dnat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> >> >> -- >> Nat Sakimura (=3Dnat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --001a1134d438d2ed1704fedf1bef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, I mean response_type=3Dnone and response_type=3Did_tok= en don't generate a code or access token so you don't use the Token= Endpoint (which is not the same as the Authentication Endpoint BTW).
W= ith response_type=3Dcode_for_id_token, you get a code and exchange it for a= n id_token only, rather than an access_token, so you're changing the se= mantics of the Token Endpoint.

I'm not saying it's a bad thing, just that you = can't really compare none and id_token with code_for_id_token.


On Wed, Ju= l 23, 2014 at 6:45 PM, Richer, Justin P. <jricher@mitre.org>= wrote:
It's only "not using the token endpoint" because the token en= dpoint copy-pasted and renamed the authentication endpoint.

=C2=A0-- Justin

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:

Except that these are about not using the Token Endpoint a= t all, whereas the current proposal is about the Token Endpoint not returni= ng an access_token field in the JSON.


On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

The response_type =E2=80= =9Cnone=E2=80=9D is already used in practice, which returns no access token= .=C2=A0 It was accepted by the designated experts and registered in the IAN= A OAuth Authorization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpo= int.=C2=A0 The registered =E2=80=9Cid_token=E2=80=9D response type also= returns no access token.

=C2=A0

So I think the question o= f whether response types that result in no access token being returned are = acceptable within OAuth 2.0 is already settled, as a practical matter.=C2=A0 Lots of OAuth implementations are already using such respons= e types.

=C2=A0

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

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ie= tf.org>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oaut= h-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

= =C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:



Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client after s= uccessfully
=C2=A0 =C2=A0 =C2=A0 authenticating the resource owner and obtaining author= ization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token<= /p>

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token en= dpoint, perhaps defining a new parameter to the token endpoint, which is a parallel to the response_type to the Aut= horization Endpoint seems to be a more symmetric way, though I am not sure = at all if that is going to be OAuth any more. One straw-man is to define a = new parameter called response_type to the token endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0<= u>

=C2=A0

Nat

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0<= /u>

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0=

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat

=C2=A0<= /p>

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of = OAuth, and I don't see a good argument for doing this work in this work= ing group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wro= te:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The =E2=80= =9Cprompt=3Dconsent=E2=80=9D definition being missing is an editorial error= .=C2=A0 It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I=E2=80=99ll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there=E2=80=99s no difference between= a response with multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80= =9Cmfa=E2=80=9D and one that doesn=E2=80=99t.=C2=A0 Unless a clear use case= for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete i= t in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0


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




--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Thomas Broye= r
/t=C9=94.ma.b=CA=81wa.je= /
--001a1134d438d2ed1704fedf1bef-- From nobody Wed Jul 23 10:04:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C2A1B29EF for ; Wed, 23 Jul 2014 10:04:30 -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=[AC_DIV_BONANZA=0.001, 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 qM52XkaGUKI4 for ; Wed, 23 Jul 2014 10:04:25 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C141B2973 for ; Wed, 23 Jul 2014 10:04:20 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id gf5so1139971lab.23 for ; Wed, 23 Jul 2014 10:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=54nJE+jjwCBDg6IWoG/WUFX0KFJNtoAx0yIKedTk6zE=; b=M0hivqlklqU2uzwCVpI1xSYAarKzf8y19V5BLw2cdtSqGifMmeI2HfQD73m7bpdbCT /cl+2PNzcU3agJTP+PlDf9mC73JLoDYmDB3ddTLUk4y/URuqk6WyRkSEqZxE8Jn0hRV3 u8PydE4gPpADv4uS2/K88LtqY46isVWskXuwKuk4mKo0q1LKxswZhacoRoY8FxuRfaPV w/ooUx5ZTEySbimr3QLZjU5qfj32mldONcehmZOSIcCw+qqQD0agVJYk42jGtFxn9WHS 7fp9YHpFTshnsu1Scgnlop/Zs/rvQJvJGb5NPVvndUr7c22PoChsFljqLAtG8a5RjaB3 lWdg== MIME-Version: 1.0 X-Received: by 10.112.54.197 with SMTP id l5mr2644478lbp.103.1406135058858; Wed, 23 Jul 2014 10:04:18 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Wed, 23 Jul 2014 10:04:18 -0700 (PDT) In-Reply-To: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> Date: Wed, 23 Jul 2014 13:04:18 -0400 Message-ID: From: Nat Sakimura To: Thomas Broyer Content-Type: multipart/alternative; boundary=001a11c3e852b08c4804fedf5496 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CiZmeZNgO7OFujboAwkPlpi7Trw Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 17:04:32 -0000 --001a11c3e852b08c4804fedf5496 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IMHO, changing the semantics of "response_type" @ authz endpoint this way is not a good thing. Instead, defining a new parameter "response_type" @ token endpoint, as I described in my previous message, probably is better. At least, it does not change the semantics of the parameters of RFC6749. Nat 2014-07-23 12:48 GMT-04:00 Thomas Broyer : > No, I mean response_type=3Dnone and response_type=3Did_token don't genera= te a > code or access token so you don't use the Token Endpoint (which is not th= e > same as the Authentication Endpoint BTW). > With response_type=3Dcode_for_id_token, you get a code and exchange it fo= r > an id_token only, rather than an access_token, so you're changing the > semantics of the Token Endpoint. > > I'm not saying it's a bad thing, just that you can't really compare none > and id_token with code_for_id_token. > > > On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. > wrote: > >> It's only "not using the token endpoint" because the token endpoint >> copy-pasted and renamed the authentication endpoint. >> >> -- Justin >> >> On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: >> >> Except that these are about not using the Token Endpoint at all, >> whereas the current proposal is about the Token Endpoint not returning a= n >> access_token field in the JSON. >> >> >> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones >> wrote: >> >>> The response_type =E2=80=9Cnone=E2=80=9D is already used in practice, = which returns no >>> access token. It was accepted by the designated experts and registered= in >>> the IANA OAuth Authorization Endpoint Response Types registry at >>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#e= ndpoint. >>> The registered =E2=80=9Cid_token=E2=80=9D response type also returns no= access token. >>> >>> >>> >>> So I think the question of whether response types that result in no >>> access token being returned are acceptable within OAuth 2.0 is already >>> settled, as a practical matter. Lots of OAuth implementations are alre= ady >>> using such response types. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt >>> *Sent:* Wednesday, July 23, 2014 7:09 AM >>> *To:* Nat Sakimura >>> *Cc:* >>> *Subject:* Re: [OAUTH-WG] New Version Notification for >>> draft-hunt-oauth-v2-user-a4c-05.txt >>> >>> >>> >>> Yes. This is why it has to be discussed in the IETF. >>> >>> >>> >>> Phil >>> >>> >>> >>> @independentid >>> >>> www.independentid.com >>> >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> >>> >>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: >>> >>> >>> >>> Reading back the RFC6749, I am not sure if there is a good way of >>> suppressing access token from the response and still be OAuth. It will >>> break whole bunch of implicit definitions like: >>> >>> >>> >>> authorization server >>> The server issuing access tokens to the client after successfully >>> authenticating the resource owner and obtaining authorization. >>> >>> >>> >>> After all, OAuth is all about issuing access tokens. >>> >>> >>> >>> Also, I take back my statement on the grant type in my previous mail. >>> >>> >>> >>> The definition of grant and grant_type are respectively: >>> >>> >>> >>> grant >>> >>> credential representing the resource owner's authorization >>> >>> >>> >>> grant_type >>> >>> (string representing the) type of grant sent to the token endpoint >>> to obtain the access token >>> >>> >>> >>> Thus, the grant sent to the token endpoint in this case is still 'code'= . >>> >>> >>> >>> Response type on the other hand is not so well defined in RFC6749, but >>> it seems it is representing what is to be returned from the authorizati= on >>> endpoint. To express what is to be returned from token endpoint, perhap= s >>> defining a new parameter to the token endpoint, which is a parallel to = the >>> response_type to the Authorization Endpoint seems to be a more symmetri= c >>> way, though I am not sure at all if that is going to be OAuth any more.= One >>> straw-man is to define a new parameter called response_type to the toke= n >>> endpoint such as: >>> >>> >>> >>> response_type >>> >>> OPTIONAL. A string representing what is to be returned from the >>> token endpoint. >>> >>> >>> >>> Then define the behavior of the endpoint according to the values as the >>> parallel to the multi-response type spec. >>> >>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>> >>> >>> >>> Nat >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>> >>> The draft is very clear. >>> >>> Phil >>> >>> >>> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >>> >>> The new grant type that I was talking about was >>> >>> "authorization_code_but_do_not_return_access_nor_refresh_token", so to >>> speak. >>> >>> It does not return anything per se, but an extension can define >>> something on top of it. >>> >>> >>> >>> Then, OIDC can define a binding to it so that the binding only returns >>> ID Token. >>> >>> This binding work should be done in OIDF. Should there be such a grant >>> type, >>> >>> it will be an extremely short spec. >>> >>> >>> >>> At the same time, if any other specification wanted to define >>> >>> other type of tokens and have it returned from the token endpoint, >>> >>> it can also use this grant type. >>> >>> >>> >>> If what you want is to define a new grant type that returns ID Token >>> only, >>> >>> then, I am with Justin. Since "other response than ID Token" is only >>> >>> theoretical, this is a more plausible way forward, I suppose. >>> >>> >>> >>> Nat >>> >>> >>> >>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>> >>> So the draft would literally turn into: >>> >>> "The a4c response type and grant type return an id_token from the token >>> endpoint with no access token. All parameters and values are defined in >>> OIDC." >>> >>> Seems like the perfect mini extension draft for OIDF to do. >>> >>> --Justin >>> >>> /sent from my phone/ >>> >>> >>> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >>> > >>> > What about just defining a new grant type in this WG? >>> > >>> > >>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>> >> >>> >> That would be nice. However oidc still needs the new grant type in >>> order to implement the same flow. >>> >> >>> >> Phil >>> >> >>> >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: >>> >> >>> >>> +1 to Justin. >>> >>> >>> >>> >>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >>> >>>> >>> >>>> Errors like these make it clear to me that it would make much more >>> sense to develop this document in the OpenID Foundation. It should be >>> something that directly references OpenID Connect Core for all of these >>> terms instead of redefining them. It's doing authentication, which is >>> fundamentally what OpenID Connect does on top of OAuth, and I don't see= a >>> good argument for doing this work in this working group. >>> >>>> >>> >>>> -- Justin >>> >>>> >>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer >>> wrote: >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < >>> Michael.Jones@microsoft.com> wrote: >>> >>>>>> >>> >>>>>> Thanks for your review, Thomas. The =E2=80=9Cprompt=3Dconsent= =E2=80=9D definition >>> being missing is an editorial error. It should be: >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> consent >>> >>>>>> >>> >>>>>> The Authorization Server SHOULD prompt the End-User for consent >>> before returning information to the Client. If it cannot obtain consent= , it >>> MUST return an error, typically consent_required. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> I=E2=80=99ll plan to add it in the next draft. >>> >>>>> >>> >>>>> >>> >>>>> It looks like the consent_required error needs to be defined too, >>> and you might have forgotten to also import account_selection_required = from >>> OpenID Connect. >>> >>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> I agree that there=E2=80=99s no difference between a response wi= th >>> multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80=9Cmfa=E2=80= =9D and one that doesn=E2=80=99t. Unless a >>> clear use case for why =E2=80=9Cmfa=E2=80=9D is needed can be identifie= d, we can delete it >>> in the next draft. >>> >>>>> >>> >>>>> >>> >>>>> Thanks. >>> >>>>> >>> >>>>> How about "pwd" then? I fully understand that I should return >>> "pwd" if the user authenticated using a password, but what "the service= if >>> a client secret is used" means in the definition for the "pwd" value? >>> >>>>> >>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come >>> back ;-) ) >>> >>>>> >>> >>>>> -- >>> >>>>> Thomas Broyer >>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>> >>>>> _______________________________________________ >>> >>>>> 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 >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Nat Sakimura (=3Dnat) >>> >>> Chairman, OpenID Foundation >>> >>> http://nat.sakimura.org/ >>> >>> @_nat_en >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > >>> > >>> > >>> > -- >>> > Nat Sakimura (=3Dnat) >>> > Chairman, OpenID Foundation >>> > http://nat.sakimura.org/ >>> > @_nat_en >>> >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> -- >> Thomas Broyer >> /t=C9=94.ma.b=CA=81wa.je/ >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c3e852b08c4804fedf5496 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMHO, changing the semantics of "response_type&q= uot; @ authz endpoint this way is not a good thing.=C2=A0

Instead, defining a new parameter "response_type" @ token endp= oint, as I described in my previous message,=C2=A0
probably is better. At least, it does not change the semantics of the param= eters of RFC6749.=C2=A0

=C2=A0Nat=C2=A0
<= /div>


2014-07-= 23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:
No, I mean response_type=3D= none and response_type=3Did_token don't generate a code or access token= so you don't use the Token Endpoint (which is not the same as the Auth= entication Endpoint BTW).
With response_type=3Dcode_for_id_token, you get a code and exchange it for = an id_token only, rather than an access_token, so you're changing the s= emantics of the Token Endpoint.

I'm not saying it's a bad thing, just that you = can't really compare none and id_token with code_for_id_token.


On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. <jricher@mitre.org&= gt; wrote:
It's only "not using the token endpoint" because the token en= dpoint copy-pasted and renamed the authentication endpoint.

=C2=A0-- Justin

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:

Except that these are about not using the Token Endpoint a= t all, whereas the current proposal is about the Token Endpoint not returni= ng an access_token field in the JSON.


On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

The response_type =E2=80= =9Cnone=E2=80=9D is already used in practice, which returns no access token= .=C2=A0 It was accepted by the designated experts and registered in the IAN= A OAuth Authorization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpo= int.=C2=A0 The registered =E2=80=9Cid_token=E2=80=9D response type also= returns no access token.

=C2=A0

So I think the question o= f whether response types that result in no access token being returned are = acceptable within OAuth 2.0 is already settled, as a practical matter.=C2=A0 Lots of OAuth implementations are already using such respons= e types.

=C2=A0

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

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ie= tf.org>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oaut= h-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

= =C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:



Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client after s= uccessfully
=C2=A0 =C2=A0 =C2=A0 authenticating the resource owner and obtaining author= ization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token<= /p>

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token en= dpoint, perhaps defining a new parameter to the token endpoint, which is a parallel to the response_type to the Aut= horization Endpoint seems to be a more symmetric way, though I am not sure = at all if that is going to be OAuth any more. One straw-man is to define a = new parameter called response_type to the token endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0<= u>

=C2=A0

Nat

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0<= /u>

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0=

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat

=C2=A0<= /p>

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of = OAuth, and I don't see a good argument for doing this work in this work= ing group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wro= te:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The =E2=80= =9Cprompt=3Dconsent=E2=80=9D definition being missing is an editorial error= .=C2=A0 It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I=E2=80=99ll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there=E2=80=99s no difference between= a response with multiple =E2=80=9Camr=E2=80=9D values that includes =E2=80= =9Cmfa=E2=80=9D and one that doesn=E2=80=99t.=C2=A0 Unless a clear use case= for why =E2=80=9Cmfa=E2=80=9D is needed can be identified, we can delete i= t in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0


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




--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Thomas Broyer
/t=C9=94.ma.b=CA=81w= a.je/

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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c3e852b08c4804fedf5496-- From nobody Wed Jul 23 10:16:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26231B2822 for ; Wed, 23 Jul 2014 10:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrojP0sKFDKj for ; Wed, 23 Jul 2014 10:16:14 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582DF1B2996 for ; Wed, 23 Jul 2014 10:15:57 -0700 (PDT) Received: from [80.67.16.118] (helo=webmail.df.eu) by smtprelay05.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1XA08x-0007qh-Cv; Wed, 23 Jul 2014 19:15:55 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_7739f2ee95bd7cf949cd36160ae76cb0" Date: Wed, 23 Jul 2014 13:15:55 -0400 From: torsten@lodderstedt.net To: Nat Sakimura In-Reply-To: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> Message-ID: <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Jqm_m_yBWrsWfs0WaZDsL8skPQA Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 17:16:23 -0000 --=_7739f2ee95bd7cf949cd36160ae76cb0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 The "response type" of the token endpoint is controlled by the value of the parameter "grant_type". So there is no need to introduce a new parameter. wrt to a potential "no_access_token" grant type. I do not consider this a good idea as it changes the semantics of the token endpoint (as already pointed out by Thomas). This endpoint ALWAYS responds with an access token to any grant type. I therefore would prefer to use another endpoint for the intended purpose. regards, Torsten. Am 23.07.2014 13:04, schrieb Nat Sakimura: > IMHO, changing the semantics of "response_type" @ authz endpoint this way is not a good thing. > Instead, defining a new parameter "response_type" @ token endpoint, as I described in my previous message, > probably is better. At least, it does not change the semantics of the parameters of RFC6749. > > Nat > > 2014-07-23 12:48 GMT-04:00 Thomas Broyer : > > No, I mean response_type=none and response_type=id_token don't generate a code or access token so you don't use the Token Endpoint (which is not the same as the Authentication Endpoint BTW). > With response_type=code_for_id_token, you get a code and exchange it for an id_token only, rather than an access_token, so you're changing the semantics of the Token Endpoint. > > I'm not saying it's a bad thing, just that you can't really compare none and id_token with code_for_id_token. > > On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. wrote: > > It's only "not using the token endpoint" because the token endpoint copy-pasted and renamed the authentication endpoint. > > -- Justin > > On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: > > Except that these are about not using the Token Endpoint at all, whereas the current proposal is about the Token Endpoint not returning an access_token field in the JSON. > > On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones wrote: > > The response_type "none" is already used in practice, which returns no access token. It was accepted by the designated experts and registered in the IANA OAuth Authorization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint [1]. The registered "id_token" response type also returns no access token. > > So I think the question of whether response types that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical matter. Lots of OAuth implementations are already using such response types. > > -- Mike > > FROM: OAuth [mailto:oauth-bounces@ietf.org] ON BEHALF OF Phil Hunt > SENT: Wednesday, July 23, 2014 7:09 AM > TO: Nat Sakimura > CC: > SUBJECT: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt > > Yes. This is why it has to be discussed in the IETF. > > Phil > > @independentid > > www.independentid.com [2] > > phil.hunt@oracle.com > > On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: > > Reading back the RFC6749, I am not sure if there is a good way of suppressing access token from the response and still be OAuth. It will break whole bunch of implicit definitions like: > > authorization server > The server issuing access tokens to the client after successfully > authenticating the resource owner and obtaining authorization. > > After all, OAuth is all about issuing access tokens. > > Also, I take back my statement on the grant type in my previous mail. > > The definition of grant and grant_type are respectively: > > grant > > credential representing the resource owner's authorization > > grant_type > > (string representing the) type of grant sent to the token endpoint to obtain the access token > > Thus, the grant sent to the token endpoint in this case is still 'code'. > > Response type on the other hand is not so well defined in RFC6749, but it seems it is representing what is to be returned from the authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the token endpoint, which is a parallel to the response_type to the Authorization Endpoint seems to be a more symmetric way, though I am not sure at all if that is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the token endpoint such as: > > response_type > > OPTIONAL. A string representing what is to be returned from the token endpoint. > > Then define the behavior of the endpoint according to the values as the parallel to the multi-response type spec. > > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html [3] > > Nat > > 2014-07-23 7:21 GMT-04:00 Phil Hunt : > > The draft is very clear. > > Phil > > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: > > The new grant type that I was talking about was > > "authorization_code_but_do_not_return_access_nor_refresh_token", so to speak. > > It does not return anything per se, but an extension can define something on top of it. > > Then, OIDC can define a binding to it so that the binding only returns ID Token. > > This binding work should be done in OIDF. Should there be such a grant type, > > it will be an extremely short spec. > > At the same time, if any other specification wanted to define > > other type of tokens and have it returned from the token endpoint, > > it can also use this grant type. > > If what you want is to define a new grant type that returns ID Token only, > > then, I am with Justin. Since "other response than ID Token" is only > > theoretical, this is a more plausible way forward, I suppose. > > Nat > > 2014-07-22 14:30 GMT-04:00 Justin Richer : > > So the draft would literally turn into: > > "The a4c response type and grant type return an id_token from the token endpoint with no access token. All parameters and values are defined in OIDC." > > Seems like the perfect mini extension draft for OIDF to do. > > --Justin > > /sent from my phone/ > > On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >> >> What about just defining a new grant type in this WG? >> >> >> 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>> >>> That would be nice. However oidc still needs the new grant type in order to implement the same flow. >>> >>> Phil >>> >>> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: >>> >>>> +1 to Justin. >>>> >>>> >>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >>>>> >>>>> Errors like these make it clear to me that it would make much more sense to develop this document in the OpenID Foundation. It should be something that directly references OpenID Connect Core for all of these terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of OAuth, and I don't see a good argument for doing this work in this working group. >>>>> >>>>> -- Justin >>>>> >>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones wrote: >>>>>>> >>>>>>> Thanks for your review, Thomas. The "prompt=consent" definition being missing is an editorial error. It should be: >>>>>>> >>>>>>> >>>>>>> >>>>>>> consent >>>>>>> >>>>>>> The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client. If it cannot obtain consent, it MUST return an error, typically consent_required. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'll plan to add it in the next draft. >>>>>> >>>>>> >>>>>> It looks like the consent_required error needs to be defined too, and you might have forgotten to also import account_selection_required from OpenID Connect. >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I agree that there's no difference between a response with multiple "amr" values that includes "mfa" and one that doesn't. Unless a clear use case for why "mfa" is needed can be identified, we can delete it in the next draft. >>>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> How about "pwd" then? I fully understand that I should return "pwd" if the user authenticated using a password, but what "the service if a client secret is used" means in the definition for the "pwd" value? >>>>>> >>>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come back ;-) ) >>>>>> >>>>>> -- >>>>>> Thomas Broyer >>>>>> /tÉ”.ma.bÊwa.je/ [4] >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth [5] >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth [5] >>>>> >>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=nat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ [6] >>>> @_nat_en >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth [5] >> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ [6] >> @_nat_en > > -- > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ [6] > @_nat_en > > -- > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ [6] > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [5] -- Thomas Broyer /tÉ”.ma.bÊwa.je/ [4] _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [5] -- Thomas Broyer /tÉ”.ma.bÊwa.je/ [4] _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [5] -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ [6] @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [5] Links: ------ [1] http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint [2] http://www.independentid.com/ [3] http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html [4] http://xn--nna.ma.xn--bwa-xxb.je/ [5] https://www.ietf.org/mailman/listinfo/oauth [6] http://nat.sakimura.org/ --=_7739f2ee95bd7cf949cd36160ae76cb0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

The "response type" of the token endpoint is controlled by the value of = the parameter "grant_type". So there is no need to introduce a new paramete= r.

wrt to a potential "no_access_token" grant type. I do not consider this = a good idea as it changes the semantics of the token endpoint (as already p= ointed out by Thomas). This endpoint ALWAYS responds with an access token t= o any grant type. I therefore would prefer to use another endpoint for the = intended purpose.

regards,
Torsten.

 

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type" @ authz endpoint this = way is not a good thing. 
 
Instead, defining a new parameter "response_type" @ token endpoint, as I de= scribed in my previous message, 
probably is better. At least, it does not change the semantics of the = parameters of RFC6749. 
 
 Nat 


2014-07-23 12:48 GMT-04:00 Thomas Broyer &= lt;t.broyer@gmail.com>:=
No, I mean response_type=3Dnone and response_type=3Did_tok= en don't generate a code or access token so you don't use the Token Endpoin= t (which is not the same as the Authentication Endpoint BTW).
With response_type=3Dcode_for_id_token, you get a code and exchange it= for an id_token only, rather than an access_token, so you're changing the = semantics of the Token Endpoint.
 
I'm not saying it's a bad thing, just that you can't really compare no= ne and id_token with code_for_id_token.


On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin = P. <jricher@mitre.org>= wrote:
It's only "not using the token endpoi= nt" because the token endpoint copy-pasted and renamed the authentication e= ndpoint.
 
 -- Justin

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:

Except that these are about not using the Token Endpoint a= t all, whereas the current proposal is about the Token Endpoint not returni= ng an access_token field in the JSON.


On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@microso= ft.com> wrote:

The response_type "none" is already use= d in practice, which returns no access token.  It was accepted by the = designated experts and registered in the IANA OAuth Authorization Endpoint = Response Types registry at http://www.iana.org/assignments= /oauth-parameters/oauth-parameters.xml#endpoint.  The registered "= id_token" response type also returns no access token.

 

So I think the question of whether resp= onse types that result in no access token being returned are acceptable wit= hin OAuth 2.0 is already settled, as a practical matter.  Lots of OAut= h implementations are already using such response types.

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   -- Mike<= span style=3D"text-decoration: underline;">

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of = Phil Hunt
Sent: Wednesday, July 23, 2014 7:0= 9 AM
To: Nat Sakimura
Cc: <<= a href=3D"mailto:oauth@ietf.org">oauth@ietf.org>
Subjec= t: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2= -user-a4c-05.txt

&= nbsp;

Yes. This is why it has to be discussed in the IETF= =2E

&= nbsp;

Phil

 

@independentid

<= a href=3D"mailto:phil.hunt@oracle.com">phil.hunt@oracle.com

<= span style=3D"text-decoration: underline;"> 

&= nbsp;

&= nbsp;

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com> wrote:



Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= =2E It will break whole bunch of implicit definitions like: 

&= nbsp;

authorization server
      The = server issuing access tokens to the client after successfully
  =     authenticating the resource owner and obtaining authorization= =2E

&= nbsp;

After all, OAuth is all about issuing access tokens= =2E 

&= nbsp;

Also, I take back my statement on the grant type in = my previous mail. <= span style=3D"text-decoration: underline;">

&= nbsp;

The definition of grant and grant_type are respectiv= ely: 

&= nbsp;

grant 

    credential representing the resource o= wner's authorization

        &nbs= p;  

grant_type

    (string representing the) type of= grant sent to the token endpoint to obtain the access token

&= nbsp;

Thus, the grant sent to the token endpoint in this c= ase is still 'code'. 

&= nbsp;

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token en= dpoint, perhaps defining a new parameter to the token endpoint, which is a = parallel to the response_type to the Authorization Endpoint seems to be a m= ore symmetric way, though I am not sure at all if that is going to be OAuth= any more. One straw-man is to define a new parameter called response_type = to the token endpoint such as: 

&= nbsp;

response_type

    OPTIONAL. A string representing what i= s to be returned from the token endpoint. <= /p>

    

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec. 

&= nbsp;

Nat

    

&= nbsp;

&= nbsp;

 

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:The draft is very clear. 

Phil


On Jul 23, 2= 014, at 0:46, Nat Sakimura <sakimu= ra@gmail.com> wrote:

The new grant type that I was talking about was = ;

"authorization_code_but_do_not_return_access_nor_ref= resh_token", so to speak. =

It does not return anything per se, but an extension= can define something on top of it. 

&= nbsp;

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token. 

This binding work should be done in OIDF. Should the= re be such a grant type, <= /span>

it will be an extremely short spec. 

&= nbsp;

At the same time, if any other specification wanted = to define 

other type of tokens and have it returned from the t= oken endpoint, 

it can also use this grant type. 

&= nbsp;

If what you want is to define a new grant type that = returns ID Token only, 

then, I am with Justin. Since "other response than I= D Token" is only 

theoretical, this is a more plausible way forward, I= suppose. 

&= nbsp;

Nat

 

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

= "The a4c response type and grant type return an id_token from the token end= point with no access token. All parameters and values are defined in OIDC= =2E"

Seems like the perfect mini extension draft for OIDF to do= =2E

--Justin

/sent from my phone/
On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
= >
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>= >
>> That would be nice. However oidc still needs the new gr= ant type in order to implement the same flow. 
>>
&g= t;> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sa= kimura <sakimura@gmail.com>= wrote:
>>
>>> +1 to Justin. 
>>= ;>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Riche= r, Justin P. <jricher@mitre.org= >:
>>>>
>>>> Errors like these make = it clear to me that it would make much more sense to develop this document = in the OpenID Foundation. It should be something that directly references O= penID Connect Core for all of these terms instead of redefining them. It's = doing authentication, which is fundamentally what OpenID Connect does on to= p of OAuth, and I don't see a good argument for doing this work in this wor= king group.
>>>>
>>>>  -- Justin >>>>
>>>> On Jul 22, 2014, at 4:30 AM, T= homas Broyer <t.broyer@gmail.com> wrote:
>>>>
>>>>>
>&= gt;>>>
>>>>>
>>>>> On Mo= n, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>&g= t;>>>
>>>>>> Thanks for your review, Thoma= s.  The "prompt=3Dconsent" definition being missing is an editorial er= ror.  It should be:
>>>>>>
>>>&= gt;>>  
>>>>>>
>>>>>= ;> consent
>>>>>>
>>>>>>= The Authorization Server SHOULD prompt the End-User for consent before ret= urning information to the Client. If it cannot obtain consent, it MUST retu= rn an error, typically consent_required.
>>>>>>
>>>>>>  
>>>>>>
>= ;>>>>> I'll plan to add it in the next draft.
>>= >>>
>>>>>
>>>>> It looks= like the consent_required error needs to be defined too, and you might hav= e forgotten to also import account_selection_required from OpenID Connect= =2E
>>>>>  
>>>>>>
= >>>>>>  
>>>>>>
>&g= t;>>>> I agree that there's no difference between a response wi= th multiple "amr" values that includes "mfa" and one that doesn't.  Un= less a clear use case for why "mfa" is needed can be identified, we can del= ete it in the next draft.
>>>>>
>>>>= >
>>>>> Thanks.
>>>>>
&g= t;>>>> How about "pwd" then? I fully understand that I should r= eturn "pwd" if the user authenticated using a password, but what "the servi= ce if a client secret is used" means in the definition for the "pwd" value?=
>>>>>
>>>>> (Nota: I know you're= at IETF-90, I'm ready to wait 'til you come back ;-) )
>>>&= gt;>
>>>>> --
>>>>> Thomas Bro= yer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> ____________= ___________________________________
>>>>> OAuth mailin= g list
>>>>> OAuth@i= etf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
&= gt;>>>
>>>>
>>>>
>>= ;>> _______________________________________________
>>>= ;> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>&= gt;>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_n= at_en
>>>
>>> _______________________________= ________________
>>> OAuth mailing list
>>> <= a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org
>>> https://www.ietf.org/ma= ilman/listinfo/oauth
>
>
>
>
= > --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Founda= tion
> http://nat.sakimura.or= g/
> @_nat_en



&= nbsp;

--
Nat Sakimura (=3Dnat)<= /span>

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



&= nbsp;

--
Nat Sakimura (=3Dnat)<= /span>

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

&= nbsp;


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



 
--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
_______________________________________________
OAuth mailing listOAuth@ietf.org
https://www.ietf.org/mailman/list= info/oauth


 
--
Thomas Broy= er
/t=C9=94.ma.b=CA=81wa= =2Eje/
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth



 
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
= http://nat.sakimura.org/
@_nat_en

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

 

 
--=_7739f2ee95bd7cf949cd36160ae76cb0-- From nobody Wed Jul 23 10:22:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FA61B2996 for ; Wed, 23 Jul 2014 10:22:55 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcFWLZEKDCE1 for ; Wed, 23 Jul 2014 10:22:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A1F1B2B7A for ; Wed, 23 Jul 2014 10:22:07 -0700 (PDT) Received: from BN3PR0301CA0082.namprd03.prod.outlook.com (25.160.152.178) by BY2PR03MB620.namprd03.prod.outlook.com (10.255.93.42) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 17:22:03 +0000 Received: from BN1AFFO11FD040.protection.gbl (2a01:111:f400:7c10::165) by BN3PR0301CA0082.outlook.office365.com (2a01:111:e400:401e::50) with Microsoft SMTP Server (TLS) id 15.0.990.7 via Frontend Transport; Wed, 23 Jul 2014 17:22:03 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD040.mail.protection.outlook.com (10.58.52.251) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 23 Jul 2014 17:22:02 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0195.002; Wed, 23 Jul 2014 17:21:21 +0000 From: Mike Jones To: "torsten@lodderstedt.net" , Nat Sakimura Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpdsD5lLSHJnTREOVCGmqo62AnZutFmeAgABuQQCAACfBgIAABwoAgAAEBVCAACOWAIAABDOAgAAAxwCAAASJAIAAAz+AgAAAinA= Date: Wed, 23 Jul 2014 17:21:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADDDF56@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> In-Reply-To: <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADDDF56TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(199002)(189002)(377454003)(24454002)(377424004)(51704005)(2656002)(15202345003)(87936001)(95666004)(85306003)(79102001)(16297215004)(19300405004)(92566001)(92726001)(83072002)(85852003)(77982001)(551544002)(93886003)(55846006)(77096002)(4396001)(76176999)(64706001)(54356999)(50986999)(20776003)(99396002)(512874002)(76482001)(81156004)(68736004)(69596002)(19625215002)(19580395003)(83322001)(19580405001)(86362001)(26826002)(84326002)(15975445006)(84676001)(33656002)(106466001)(561944003)(106116001)(15974865002)(6806004)(104016003)(19617315012)(16236675004)(74662001)(46102001)(31966008)(44976005)(107046002)(21056001)(81342001)(97736001)(80022001)(71186001)(86612001)(15395725005)(74502001)(81542001)(66066001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB620; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 028166BF91 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/xcB-ltNpTP1Av_n9oyDMRY03MEo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 17:22:55 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADDDF56TK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIFRvcnN0ZW4gb24gdGhpcy4gIEFsc28sIEpvaG4gQnJhZGxleSBoYWQgcG9p bnRlZCBvdXQgZWFybGllciB0aGF0IGEgbmV3IGdyYW50IHR5cGUgd2FzIG5lZWRlZC4NCg0KVGhl IGFjNCBkcmFmdCBkZWZpbmVzIHRoZSBncmFudCB0eXBlIHVybjppZXRmOnBhcmFtczpvYXV0aDpn cmFudC10eXBlOmNvZGUtZm9yLWlkLXRva2VuIGZvciB0aGlzIHB1cnBvc2UsIHNpbmNlIHNlY3Rp b24gNC41IG9mIFJGQyA2NzQ5IHJlcXVpcmVzIGV4dGVuc2lvbiBncmFudHMgdG8gYmUgYWJzb2x1 dGUgVVJMcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldA0KU2VudDog V2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDEwOjE2IEFNDQpUbzogTmF0IFNha2ltdXJhDQpDYzog b2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQNCg0KDQpUaGUg InJlc3BvbnNlIHR5cGUiIG9mIHRoZSB0b2tlbiBlbmRwb2ludCBpcyBjb250cm9sbGVkIGJ5IHRo ZSB2YWx1ZSBvZiB0aGUgcGFyYW1ldGVyICJncmFudF90eXBlIi4gU28gdGhlcmUgaXMgbm8gbmVl ZCB0byBpbnRyb2R1Y2UgYSBuZXcgcGFyYW1ldGVyLg0KDQp3cnQgdG8gYSBwb3RlbnRpYWwgIm5v X2FjY2Vzc190b2tlbiIgZ3JhbnQgdHlwZS4gSSBkbyBub3QgY29uc2lkZXIgdGhpcyBhIGdvb2Qg aWRlYSBhcyBpdCBjaGFuZ2VzIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHRva2VuIGVuZHBvaW50IChh cyBhbHJlYWR5IHBvaW50ZWQgb3V0IGJ5IFRob21hcykuIFRoaXMgZW5kcG9pbnQgQUxXQVlTIHJl c3BvbmRzIHdpdGggYW4gYWNjZXNzIHRva2VuIHRvIGFueSBncmFudCB0eXBlLiBJIHRoZXJlZm9y ZSB3b3VsZCBwcmVmZXIgdG8gdXNlIGFub3RoZXIgZW5kcG9pbnQgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlLg0KDQpyZWdhcmRzLA0KVG9yc3Rlbi4NCg0KDQoNCkFtIDIzLjA3LjIwMTQgMTM6MDQs IHNjaHJpZWIgTmF0IFNha2ltdXJhOg0KSU1ITywgY2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiAi cmVzcG9uc2VfdHlwZSIgQCBhdXRoeiBlbmRwb2ludCB0aGlzIHdheSBpcyBub3QgYSBnb29kIHRo aW5nLg0KDQpJbnN0ZWFkLCBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXIgInJlc3BvbnNlX3R5cGUi IEAgdG9rZW4gZW5kcG9pbnQsIGFzIEkgZGVzY3JpYmVkIGluIG15IHByZXZpb3VzIG1lc3NhZ2Us DQpwcm9iYWJseSBpcyBiZXR0ZXIuIEF0IGxlYXN0LCBpdCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHNl bWFudGljcyBvZiB0aGUgcGFyYW1ldGVycyBvZiBSRkM2NzQ5Lg0KDQogTmF0DQoNCjIwMTQtMDct MjMgMTI6NDggR01ULTA0OjAwIFRob21hcyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxtYWls dG86dC5icm95ZXJAZ21haWwuY29tPj46DQpObywgSSBtZWFuIHJlc3BvbnNlX3R5cGU9bm9uZSBh bmQgcmVzcG9uc2VfdHlwZT1pZF90b2tlbiBkb24ndCBnZW5lcmF0ZSBhIGNvZGUgb3IgYWNjZXNz IHRva2VuIHNvIHlvdSBkb24ndCB1c2UgdGhlIFRva2VuIEVuZHBvaW50ICh3aGljaCBpcyBub3Qg dGhlIHNhbWUgYXMgdGhlIEF1dGhlbnRpY2F0aW9uIEVuZHBvaW50IEJUVykuDQpXaXRoIHJlc3Bv bnNlX3R5cGU9Y29kZV9mb3JfaWRfdG9rZW4sIHlvdSBnZXQgYSBjb2RlIGFuZCBleGNoYW5nZSBp dCBmb3IgYW4gaWRfdG9rZW4gb25seSwgcmF0aGVyIHRoYW4gYW4gYWNjZXNzX3Rva2VuLCBzbyB5 b3UncmUgY2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgVG9rZW4gRW5kcG9pbnQuDQoNCkkn bSBub3Qgc2F5aW5nIGl0J3MgYSBiYWQgdGhpbmcsIGp1c3QgdGhhdCB5b3UgY2FuJ3QgcmVhbGx5 IGNvbXBhcmUgbm9uZSBhbmQgaWRfdG9rZW4gd2l0aCBjb2RlX2Zvcl9pZF90b2tlbi4NCg0KT24g V2VkLCBKdWwgMjMsIDIwMTQgYXQgNjo0NSBQTSwgUmljaGVyLCBKdXN0aW4gUC4gPGpyaWNoZXJA bWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+IHdyb3RlOg0KSXQncyBvbmx5ICJu b3QgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50IiBiZWNhdXNlIHRoZSB0b2tlbiBlbmRwb2ludCBj b3B5LXBhc3RlZCBhbmQgcmVuYW1lZCB0aGUgYXV0aGVudGljYXRpb24gZW5kcG9pbnQuDQoNCiAt LSBKdXN0aW4NCg0KT24gSnVsIDIzLCAyMDE0LCBhdCA5OjMwIEFNLCBUaG9tYXMgQnJveWVyIDx0 LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoN CkV4Y2VwdCB0aGF0IHRoZXNlIGFyZSBhYm91dCBub3QgdXNpbmcgdGhlIFRva2VuIEVuZHBvaW50 IGF0IGFsbCwgd2hlcmVhcyB0aGUgY3VycmVudCBwcm9wb3NhbCBpcyBhYm91dCB0aGUgVG9rZW4g RW5kcG9pbnQgbm90IHJldHVybmluZyBhbiBhY2Nlc3NfdG9rZW4gZmllbGQgaW4gdGhlIEpTT04u DQoNCk9uIFdlZCwgSnVsIDIzLCAyMDE0IGF0IDQ6MjYgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQpUaGUgcmVzcG9uc2VfdHlwZSAibm9uZSIgaXMgYWxyZWFkeSB1c2VkIGluIHByYWN0 aWNlLCB3aGljaCByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi4gIEl0IHdhcyBhY2NlcHRlZCBieSB0 aGUgZGVzaWduYXRlZCBleHBlcnRzIGFuZCByZWdpc3RlcmVkIGluIHRoZSBJQU5BIE9BdXRoIEF1 dGhvcml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2UgVHlwZXMgcmVnaXN0cnkgYXQgaHR0cDovL3d3 dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMu eG1sI2VuZHBvaW50LiAgVGhlIHJlZ2lzdGVyZWQgImlkX3Rva2VuIiByZXNwb25zZSB0eXBlIGFs c28gcmV0dXJucyBubyBhY2Nlc3MgdG9rZW4uDQoNClNvIEkgdGhpbmsgdGhlIHF1ZXN0aW9uIG9m IHdoZXRoZXIgcmVzcG9uc2UgdHlwZXMgdGhhdCByZXN1bHQgaW4gbm8gYWNjZXNzIHRva2VuIGJl aW5nIHJldHVybmVkIGFyZSBhY2NlcHRhYmxlIHdpdGhpbiBPQXV0aCAyLjAgaXMgYWxyZWFkeSBz ZXR0bGVkLCBhcyBhIHByYWN0aWNhbCBtYXR0ZXIuICBMb3RzIG9mIE9BdXRoIGltcGxlbWVudGF0 aW9ucyBhcmUgYWxyZWFkeSB1c2luZyBzdWNoIHJlc3BvbnNlIHR5cGVzLg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IFdlZG5l c2RheSwgSnVseSAyMywgMjAxNCA3OjA5IEFNDQpUbzogTmF0IFNha2ltdXJhDQpDYzogPG9hdXRo QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1h NGMtMDUudHh0DQoNClllcy4gVGhpcyBpcyB3aHkgaXQgaGFzIHRvIGJlIGRpc2N1c3NlZCBpbiB0 aGUgSUVURi4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29t PGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KT24gSnVsIDIzLCAyMDE0LCBhdCA5OjQz IEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21h aWwuY29tPj4gd3JvdGU6DQoNClJlYWRpbmcgYmFjayB0aGUgUkZDNjc0OSwgSSBhbSBub3Qgc3Vy ZSBpZiB0aGVyZSBpcyBhIGdvb2Qgd2F5IG9mIHN1cHByZXNzaW5nIGFjY2VzcyB0b2tlbiBmcm9t IHRoZSByZXNwb25zZSBhbmQgc3RpbGwgYmUgT0F1dGguIEl0IHdpbGwgYnJlYWsgd2hvbGUgYnVu Y2ggb2YgaW1wbGljaXQgZGVmaW5pdGlvbnMgbGlrZToNCg0KYXV0aG9yaXphdGlvbiBzZXJ2ZXIN CiAgICAgIFRoZSBzZXJ2ZXIgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0 ZXIgc3VjY2Vzc2Z1bGx5DQogICAgICBhdXRoZW50aWNhdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIg YW5kIG9idGFpbmluZyBhdXRob3JpemF0aW9uLg0KDQpBZnRlciBhbGwsIE9BdXRoIGlzIGFsbCBh Ym91dCBpc3N1aW5nIGFjY2VzcyB0b2tlbnMuDQoNCkFsc28sIEkgdGFrZSBiYWNrIG15IHN0YXRl bWVudCBvbiB0aGUgZ3JhbnQgdHlwZSBpbiBteSBwcmV2aW91cyBtYWlsLg0KDQpUaGUgZGVmaW5p dGlvbiBvZiBncmFudCBhbmQgZ3JhbnRfdHlwZSBhcmUgcmVzcGVjdGl2ZWx5Og0KDQpncmFudA0K ICAgIGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGF1dGhvcml6 YXRpb24NCg0KZ3JhbnRfdHlwZQ0KICAgIChzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSkgdHlwZSBv ZiBncmFudCBzZW50IHRvIHRoZSB0b2tlbiBlbmRwb2ludCB0byBvYnRhaW4gdGhlIGFjY2VzcyB0 b2tlbg0KDQpUaHVzLCB0aGUgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgaW4gdGhp cyBjYXNlIGlzIHN0aWxsICdjb2RlJy4NCg0KUmVzcG9uc2UgdHlwZSBvbiB0aGUgb3RoZXIgaGFu ZCBpcyBub3Qgc28gd2VsbCBkZWZpbmVkIGluIFJGQzY3NDksIGJ1dCBpdCBzZWVtcyBpdCBpcyBy ZXByZXNlbnRpbmcgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRoZSBhdXRob3JpemF0aW9u IGVuZHBvaW50LiBUbyBleHByZXNzIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0b2tlbiBl bmRwb2ludCwgcGVyaGFwcyBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXIgdG8gdGhlIHRva2VuIGVu ZHBvaW50LCB3aGljaCBpcyBhIHBhcmFsbGVsIHRvIHRoZSByZXNwb25zZV90eXBlIHRvIHRoZSBB dXRob3JpemF0aW9uIEVuZHBvaW50IHNlZW1zIHRvIGJlIGEgbW9yZSBzeW1tZXRyaWMgd2F5LCB0 aG91Z2ggSSBhbSBub3Qgc3VyZSBhdCBhbGwgaWYgdGhhdCBpcyBnb2luZyB0byBiZSBPQXV0aCBh bnkgbW9yZS4gT25lIHN0cmF3LW1hbiBpcyB0byBkZWZpbmUgYSBuZXcgcGFyYW1ldGVyIGNhbGxl ZCByZXNwb25zZV90eXBlIHRvIHRoZSB0b2tlbiBlbmRwb2ludCBzdWNoIGFzOg0KDQpyZXNwb25z ZV90eXBlDQogICAgT1BUSU9OQUwuIEEgc3RyaW5nIHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJl IHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50Lg0KDQpUaGVuIGRlZmluZSB0aGUgYmVo YXZpb3Igb2YgdGhlIGVuZHBvaW50IGFjY29yZGluZyB0byB0aGUgdmFsdWVzIGFzIHRoZSBwYXJh bGxlbCB0byB0aGUgbXVsdGktcmVzcG9uc2UgdHlwZSBzcGVjLg0KaHR0cDovL29wZW5pZC5uZXQv c3BlY3Mvb2F1dGgtdjItbXVsdGlwbGUtcmVzcG9uc2UtdHlwZXMtMV8wLmh0bWwNCg0KTmF0DQoN Cg0KDQoNCjIwMTQtMDctMjMgNzoyMSBHTVQtMDQ6MDAgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3Jh Y2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PjoNClRoZSBkcmFmdCBpcyB2ZXJ5 IGNsZWFyLg0KDQpQaGlsDQoNCk9uIEp1bCAyMywgMjAxNCwgYXQgMDo0NiwgTmF0IFNha2ltdXJh IDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0K VGhlIG5ldyBncmFudCB0eXBlIHRoYXQgSSB3YXMgdGFsa2luZyBhYm91dCB3YXMNCiJhdXRob3Jp emF0aW9uX2NvZGVfYnV0X2RvX25vdF9yZXR1cm5fYWNjZXNzX25vcl9yZWZyZXNoX3Rva2VuIiwg c28gdG8gc3BlYWsuDQpJdCBkb2VzIG5vdCByZXR1cm4gYW55dGhpbmcgcGVyIHNlLCBidXQgYW4g ZXh0ZW5zaW9uIGNhbiBkZWZpbmUgc29tZXRoaW5nIG9uIHRvcCBvZiBpdC4NCg0KVGhlbiwgT0lE QyBjYW4gZGVmaW5lIGEgYmluZGluZyB0byBpdCBzbyB0aGF0IHRoZSBiaW5kaW5nIG9ubHkgcmV0 dXJucyBJRCBUb2tlbi4NClRoaXMgYmluZGluZyB3b3JrIHNob3VsZCBiZSBkb25lIGluIE9JREYu IFNob3VsZCB0aGVyZSBiZSBzdWNoIGEgZ3JhbnQgdHlwZSwNCml0IHdpbGwgYmUgYW4gZXh0cmVt ZWx5IHNob3J0IHNwZWMuDQoNCkF0IHRoZSBzYW1lIHRpbWUsIGlmIGFueSBvdGhlciBzcGVjaWZp Y2F0aW9uIHdhbnRlZCB0byBkZWZpbmUNCm90aGVyIHR5cGUgb2YgdG9rZW5zIGFuZCBoYXZlIGl0 IHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LA0KaXQgY2FuIGFsc28gdXNlIHRoaXMg Z3JhbnQgdHlwZS4NCg0KSWYgd2hhdCB5b3Ugd2FudCBpcyB0byBkZWZpbmUgYSBuZXcgZ3JhbnQg dHlwZSB0aGF0IHJldHVybnMgSUQgVG9rZW4gb25seSwNCnRoZW4sIEkgYW0gd2l0aCBKdXN0aW4u IFNpbmNlICJvdGhlciByZXNwb25zZSB0aGFuIElEIFRva2VuIiBpcyBvbmx5DQp0aGVvcmV0aWNh bCwgdGhpcyBpcyBhIG1vcmUgcGxhdXNpYmxlIHdheSBmb3J3YXJkLCBJIHN1cHBvc2UuDQoNCk5h dA0KDQoyMDE0LTA3LTIyIDE0OjMwIEdNVC0wNDowMCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1p dC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+Og0KU28gdGhlIGRyYWZ0IHdvdWxkIGxpdGVy YWxseSB0dXJuIGludG86DQoNCiJUaGUgYTRjIHJlc3BvbnNlIHR5cGUgYW5kIGdyYW50IHR5cGUg cmV0dXJuIGFuIGlkX3Rva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IHdpdGggbm8gYWNjZXNz IHRva2VuLiBBbGwgcGFyYW1ldGVycyBhbmQgdmFsdWVzIGFyZSBkZWZpbmVkIGluIE9JREMuIg0K DQpTZWVtcyBsaWtlIHRoZSBwZXJmZWN0IG1pbmkgZXh0ZW5zaW9uIGRyYWZ0IGZvciBPSURGIHRv IGRvLg0KDQotLUp1c3Rpbg0KDQovc2VudCBmcm9tIG15IHBob25lLw0KDQpPbiBKdWwgMjIsIDIw MTQgMTA6MjkgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtp bXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4gV2hhdCBhYm91dCBqdXN0IGRlZmluaW5nIGEg bmV3IGdyYW50IHR5cGUgaW4gdGhpcyBXRz8NCj4NCj4NCj4gMjAxNC0wNy0yMiAxMjo1NiBHTVQt MDQ6MDAgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20+PjoNCj4+DQo+PiBUaGF0IHdvdWxkIGJlIG5pY2UuIEhvd2V2ZXIgb2lkYyBzdGls bCBuZWVkcyB0aGUgbmV3IGdyYW50IHR5cGUgaW4gb3JkZXIgdG8gaW1wbGVtZW50IHRoZSBzYW1l IGZsb3cuDQo+Pg0KPj4gUGhpbA0KPj4NCj4+IE9uIEp1bCAyMiwgMjAxNCwgYXQgMTE6MzUsIE5h dCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+ PiB3cm90ZToNCj4+DQo+Pj4gKzEgdG8gSnVzdGluLg0KPj4+DQo+Pj4NCj4+PiAyMDE0LTA3LTIy IDk6NTQgR01ULTA0OjAwIFJpY2hlciwgSnVzdGluIFAuIDxqcmljaGVyQG1pdHJlLm9yZzxtYWls dG86anJpY2hlckBtaXRyZS5vcmc+PjoNCj4+Pj4NCj4+Pj4gRXJyb3JzIGxpa2UgdGhlc2UgbWFr ZSBpdCBjbGVhciB0byBtZSB0aGF0IGl0IHdvdWxkIG1ha2UgbXVjaCBtb3JlIHNlbnNlIHRvIGRl dmVsb3AgdGhpcyBkb2N1bWVudCBpbiB0aGUgT3BlbklEIEZvdW5kYXRpb24uIEl0IHNob3VsZCBi ZSBzb21ldGhpbmcgdGhhdCBkaXJlY3RseSByZWZlcmVuY2VzIE9wZW5JRCBDb25uZWN0IENvcmUg Zm9yIGFsbCBvZiB0aGVzZSB0ZXJtcyBpbnN0ZWFkIG9mIHJlZGVmaW5pbmcgdGhlbS4gSXQncyBk b2luZyBhdXRoZW50aWNhdGlvbiwgd2hpY2ggaXMgZnVuZGFtZW50YWxseSB3aGF0IE9wZW5JRCBD b25uZWN0IGRvZXMgb24gdG9wIG9mIE9BdXRoLCBhbmQgSSBkb24ndCBzZWUgYSBnb29kIGFyZ3Vt ZW50IGZvciBkb2luZyB0aGlzIHdvcmsgaW4gdGhpcyB3b3JraW5nIGdyb3VwLg0KPj4+Pg0KPj4+ PiAgLS0gSnVzdGluDQo+Pj4+DQo+Pj4+IE9uIEp1bCAyMiwgMjAxNCwgYXQgNDozMCBBTSwgVGhv bWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPG1haWx0bzp0LmJyb3llckBnbWFpbC5jb20+ PiB3cm90ZToNCj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE9uIE1vbiwgSnVsIDIx LCAyMDE0IGF0IDExOjUyIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KPj4+Pj4+DQo+ Pj4+Pj4gVGhhbmtzIGZvciB5b3VyIHJldmlldywgVGhvbWFzLiAgVGhlICJwcm9tcHQ9Y29uc2Vu dCIgZGVmaW5pdGlvbiBiZWluZyBtaXNzaW5nIGlzIGFuIGVkaXRvcmlhbCBlcnJvci4gIEl0IHNo b3VsZCBiZToNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBjb25zZW50DQo+Pj4+Pj4N Cj4+Pj4+PiBUaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgU0hPVUxEIHByb21wdCB0aGUgRW5kLVVz ZXIgZm9yIGNvbnNlbnQgYmVmb3JlIHJldHVybmluZyBpbmZvcm1hdGlvbiB0byB0aGUgQ2xpZW50 LiBJZiBpdCBjYW5ub3Qgb2J0YWluIGNvbnNlbnQsIGl0IE1VU1QgcmV0dXJuIGFuIGVycm9yLCB0 eXBpY2FsbHkgY29uc2VudF9yZXF1aXJlZC4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+ PiBJJ2xsIHBsYW4gdG8gYWRkIGl0IGluIHRoZSBuZXh0IGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+DQo+ Pj4+PiBJdCBsb29rcyBsaWtlIHRoZSBjb25zZW50X3JlcXVpcmVkIGVycm9yIG5lZWRzIHRvIGJl IGRlZmluZWQgdG9vLCBhbmQgeW91IG1pZ2h0IGhhdmUgZm9yZ290dGVuIHRvIGFsc28gaW1wb3J0 IGFjY291bnRfc2VsZWN0aW9uX3JlcXVpcmVkIGZyb20gT3BlbklEIENvbm5lY3QuDQo+Pj4+Pg0K Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEkgYWdyZWUgdGhhdCB0aGVyZSdzIG5vIGRp ZmZlcmVuY2UgYmV0d2VlbiBhIHJlc3BvbnNlIHdpdGggbXVsdGlwbGUgImFtciIgdmFsdWVzIHRo YXQgaW5jbHVkZXMgIm1mYSIgYW5kIG9uZSB0aGF0IGRvZXNuJ3QuICBVbmxlc3MgYSBjbGVhciB1 c2UgY2FzZSBmb3Igd2h5ICJtZmEiIGlzIG5lZWRlZCBjYW4gYmUgaWRlbnRpZmllZCwgd2UgY2Fu IGRlbGV0ZSBpdCBpbiB0aGUgbmV4dCBkcmFmdC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhhbmtz Lg0KPj4+Pj4NCj4+Pj4+IEhvdyBhYm91dCAicHdkIiB0aGVuPyBJIGZ1bGx5IHVuZGVyc3RhbmQg dGhhdCBJIHNob3VsZCByZXR1cm4gInB3ZCIgaWYgdGhlIHVzZXIgYXV0aGVudGljYXRlZCB1c2lu ZyBhIHBhc3N3b3JkLCBidXQgd2hhdCAidGhlIHNlcnZpY2UgaWYgYSBjbGllbnQgc2VjcmV0IGlz IHVzZWQiIG1lYW5zIGluIHRoZSBkZWZpbml0aW9uIGZvciB0aGUgInB3ZCIgdmFsdWU/DQo+Pj4+ Pg0KPj4+Pj4gKE5vdGE6IEkga25vdyB5b3UncmUgYXQgSUVURi05MCwgSSdtIHJlYWR5IHRvIHdh aXQgJ3RpbCB5b3UgY29tZSBiYWNrIDstKSApDQo+Pj4+Pg0KPj4+Pj4gLS0NCj4+Pj4+IFRob21h cyBCcm95ZXINCj4+Pj4+IC90yZQubWEuYsqBd2EuamUvPGh0dHA6Ly94bi0tbm5hLm1hLnhuLS1i d2EteHhiLmplLz4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4+IE9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0 DQo+Pj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+Pg0KPj4+DQo+Pj4NCj4+ Pg0KPj4+IC0tDQo+Pj4gTmF0IFNha2ltdXJhICg9bmF0KQ0KPj4+IENoYWlybWFuLCBPcGVuSUQg Rm91bmRhdGlvbg0KPj4+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPj4+IEBfbmF0X2VuDQo+ Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo DQo+DQo+DQo+DQo+DQo+IC0tDQo+IE5hdCBTYWtpbXVyYSAoPW5hdCkNCj4gQ2hhaXJtYW4sIE9w ZW5JRCBGb3VuZGF0aW9uDQo+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPiBAX25hdF9lbg0K DQoNCg0KLS0NCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlv bg0KaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQpAX25hdF9lbg0KDQoNCg0KLS0NCk5hdCBTYWtp bXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtp bXVyYS5vcmcvDQpAX25hdF9lbg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg0KDQoNCi0tDQpUaG9tYXMgQnJveWVyDQovdMmULm1hLmLKgXdhLmplLzxodHRwOi8v eG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQoNCg0KDQotLQ0KVGhvbWFzIEJyb3llcg0KL3TJlC5tYS5iyoF3YS5qZS88aHR0 cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvPg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4s IE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1 dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0K --_000_4E1F6AAD24975D4BA5B16804296739439ADDDF56TK5EX14MBXC294r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHls ZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHdpdGggVG9yc3RlbiBvbiB0aGlzLiZuYnNwOyBB bHNvLCBKb2huIEJyYWRsZXkgaGFkIHBvaW50ZWQgb3V0IGVhcmxpZXIgdGhhdCBhIG5ldyBncmFu dCB0eXBlIHdhcyBuZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgYWM0IGRyYWZ0IGRlZmluZXMgdGhlIGdy YW50IHR5cGUNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+dXJuOmlldGY6cGFyYW1zOm9hdXRoOmdy YW50LXR5cGU6Y29kZS1mb3ItaWQtdG9rZW48L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Zm9yIHRoaXMgcHVycG9zZSwgc2luY2Ugc2VjdGlvbiA0 LjUgb2YgUkZDIDY3NDkgcmVxdWlyZXMgZXh0ZW5zaW9uIGdyYW50cyB0byBiZSBhYnNvbHV0ZSBV UkxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBP QXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVs eSAyMywgMjAxNCAxMDoxNiBBTTxicj4NCjxiPlRvOjwvYj4gTmF0IFNha2ltdXJhPGJyPg0KPGI+ Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdH XSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1h NGMtMDUudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPlRoZSAmcXVvdDtyZXNwb25zZSB0eXBlJnF1b3Q7IG9mIHRoZSB0b2tlbiBl bmRwb2ludCBpcyBjb250cm9sbGVkIGJ5IHRoZSB2YWx1ZSBvZiB0aGUgcGFyYW1ldGVyICZxdW90 O2dyYW50X3R5cGUmcXVvdDsuIFNvIHRoZXJlIGlzIG5vIG5lZWQgdG8gaW50cm9kdWNlIGEgbmV3 IHBhcmFtZXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+d3J0IHRvIGEgcG90ZW50aWFsICZxdW90O25vX2FjY2Vzc190b2tlbiZxdW90 OyBncmFudCB0eXBlLiBJIGRvIG5vdCBjb25zaWRlciB0aGlzIGEgZ29vZCBpZGVhIGFzIGl0IGNo YW5nZXMgdGhlIHNlbWFudGljcyBvZiB0aGUgdG9rZW4gZW5kcG9pbnQgKGFzIGFscmVhZHkgcG9p bnRlZCBvdXQgYnkgVGhvbWFzKS4gVGhpcyBlbmRwb2ludCBBTFdBWVMgcmVzcG9uZHMgd2l0aCBh biBhY2Nlc3MgdG9rZW4gdG8NCiBhbnkgZ3JhbnQgdHlwZS4gSSB0aGVyZWZvcmUgd291bGQgcHJl ZmVyIHRvIHVzZSBhbm90aGVyIGVuZHBvaW50IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+cmVn YXJkcyw8YnI+DQpUb3JzdGVuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+QW0gMjMuMDcuMjAxNCAxMzowNCwgc2NocmllYiBO YXQgU2FraW11cmE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPklNSE8sIGNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgJnF1 b3Q7cmVzcG9uc2VfdHlwZSZxdW90OyBAIGF1dGh6IGVuZHBvaW50IHRoaXMgd2F5IGlzIG5vdCBh IGdvb2QgdGhpbmcuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkluc3RlYWQsIGRlZmluaW5nIGEgbmV3IHBhcmFt ZXRlciAmcXVvdDtyZXNwb25zZV90eXBlJnF1b3Q7IEAgdG9rZW4gZW5kcG9pbnQsIGFzIEkgZGVz Y3JpYmVkIGluIG15IHByZXZpb3VzIG1lc3NhZ2UsJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPnByb2JhYmx5IGlzIGJldHRlci4gQXQgbGVhc3QsIGl0IGRvZXMgbm90IGNoYW5nZSB0 aGUgc2VtYW50aWNzIG9mIHRoZSBwYXJhbWV0ZXJzIG9mIFJGQzY3NDkuJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mbmJzcDtOYXQmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+MjAxNC0wNy0yMyAxMjo0OCBHTVQtMDQ6MDAgVGhvbWFzIEJyb3llciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSI+dC5icm95ZXJAZ21haWwuY29tPC9h PiZndDs6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5ObywgSSBtZWFuIHJlc3BvbnNlX3R5cGU9 bm9uZSBhbmQgcmVzcG9uc2VfdHlwZT1pZF90b2tlbiBkb24ndCBnZW5lcmF0ZSBhIGNvZGUgb3Ig YWNjZXNzIHRva2VuIHNvIHlvdSBkb24ndCB1c2UgdGhlIFRva2VuIEVuZHBvaW50ICh3aGljaCBp cyBub3QgdGhlIHNhbWUgYXMgdGhlIEF1dGhlbnRpY2F0aW9uIEVuZHBvaW50IEJUVykuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPldpdGggcmVzcG9uc2VfdHlwZT1jb2RlX2Zvcl9pZF90b2tl biwgeW91IGdldCBhIGNvZGUgYW5kIGV4Y2hhbmdlIGl0IGZvciBhbiBpZF90b2tlbiBvbmx5LCBy YXRoZXIgdGhhbiBhbiBhY2Nlc3NfdG9rZW4sIHNvIHlvdSdyZSBjaGFuZ2luZyB0aGUgc2VtYW50 aWNzIG9mIHRoZSBUb2tlbiBFbmRwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkknbSBub3Qgc2F5aW5n IGl0J3MgYSBiYWQgdGhpbmcsIGp1c3QgdGhhdCB5b3UgY2FuJ3QgcmVhbGx5IGNvbXBhcmUgbm9u ZSBhbmQgaWRfdG9rZW4gd2l0aCBjb2RlX2Zvcl9pZF90b2tlbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5PbiBXZWQsIEp1bCAyMywg MjAxNCBhdCA2OjQ1IFBNLCBSaWNoZXIsIEp1c3RpbiBQLiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpy aWNoZXJAbWl0cmUub3JnIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+SXQncyBvbmx5ICZxdW90O25vdCB1c2luZyB0aGUgdG9rZW4gZW5k cG9pbnQmcXVvdDsgYmVjYXVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgY29weS1wYXN0ZWQgYW5kIHJl bmFtZWQgdGhlIGF1dGhlbnRpY2F0aW9uIGVuZHBvaW50Lg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7LS0gSnVz dGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk9uIEp1bCAyMywgMjAxNCwg YXQgOTozMCBBTSwgVGhvbWFzIEJyb3llciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnQuYnJveWVyQGdt YWlsLmNvbSI+dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5FeGNlcHQg dGhhdCB0aGVzZSBhcmUgYWJvdXQgbm90IHVzaW5nIHRoZSBUb2tlbiBFbmRwb2ludCBhdCBhbGws IHdoZXJlYXMgdGhlIGN1cnJlbnQgcHJvcG9zYWwgaXMgYWJvdXQgdGhlIFRva2VuIEVuZHBvaW50 IG5vdCByZXR1cm5pbmcgYW4gYWNjZXNzX3Rva2VuIGZpZWxkIGluIHRoZSBKU09OLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+T24gV2VkLCBKdWwgMjMsIDIwMTQgYXQgNDoy NiBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgcmVzcG9uc2VfdHlw ZSAmcXVvdDtub25lJnF1b3Q7IGlzIGFscmVhZHkgdXNlZCBpbiBwcmFjdGljZSwgd2hpY2ggcmV0 dXJucyBubyBhY2Nlc3MgdG9rZW4uJm5ic3A7IEl0IHdhcyBhY2NlcHRlZA0KIGJ5IHRoZSBkZXNp Z25hdGVkIGV4cGVydHMgYW5kIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkEgT0F1dGggQXV0aG9yaXph dGlvbiBFbmRwb2ludCBSZXNwb25zZSBUeXBlcyByZWdpc3RyeSBhdA0KPGEgaHJlZj0iaHR0cDov L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRl cnMueG1sI2VuZHBvaW50Ij4NCmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgt cGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhtbCNlbmRwb2ludDwvYT4uJm5ic3A7IFRoZSBy ZWdpc3RlcmVkICZxdW90O2lkX3Rva2VuJnF1b3Q7IHJlc3BvbnNlIHR5cGUgYWxzbyByZXR1cm5z IG5vIGFjY2VzcyB0b2tlbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBJIHRoaW5rIHRoZSBxdWVzdGlvbiBv ZiB3aGV0aGVyIHJlc3BvbnNlIHR5cGVzIHRoYXQgcmVzdWx0IGluIG5vIGFjY2VzcyB0b2tlbiBi ZWluZyByZXR1cm5lZCBhcmUNCiBhY2NlcHRhYmxlIHdpdGhpbiBPQXV0aCAyLjAgaXMgYWxyZWFk eSBzZXR0bGVkLCBhcyBhIHByYWN0aWNhbCBtYXR0ZXIuJm5ic3A7IExvdHMgb2YgT0F1dGggaW1w bGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IHVzaW5nIHN1Y2ggcmVzcG9uc2UgdHlwZXMuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IE9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIEJl aGFsZiBPZiA8L3NwYW4+PC9zdHJvbmc+UGhpbCBIdW50PGJyPg0KPHN0cm9uZz48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlNlbnQ6PC9zcGFuPjwvc3Ryb25nPiBXZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQgNzowOSBBTTxi cj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ubzo8L3NwYW4+PC9zdHJvbmc+IE5hdCBTYWtpbXVyYTxi cj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DYzo8L3NwYW4+PC9zdHJvbmc+ICZsdDs8YSBocmVmPSJt YWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3Ryb25n PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+U3ViamVjdDo8L3NwYW4+PC9zdHJvbmc+IFJlOiBbT0FVVEgtV0ddIE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50 eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5ZZXMuIFRoaXMgaXMgd2h5IGl0IGhhcyB0byBiZSBkaXNjdXNzZWQgaW4gdGhl IElFVEYuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlBoaWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QGluZGVw ZW5kZW50aWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6 Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwu aHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gSnVsIDIzLCAyMDE0LCBhdCA5OjQz IEFNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20i PnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+UmVhZGluZyBiYWNrIHRoZSBSRkM2NzQ5LCBJIGFtIG5vdCBzdXJlIGlm IHRoZXJlIGlzIGEgZ29vZCB3YXkgb2Ygc3VwcHJlc3NpbmcgYWNjZXNzIHRva2VuIGZyb20gdGhl IHJlc3BvbnNlIGFuZCBzdGlsbCBiZSBPQXV0aC4gSXQgd2lsbCBicmVhayB3aG9sZSBidW5jaCBv ZiBpbXBsaWNpdCBkZWZpbml0aW9ucw0KIGxpa2U6Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5hdXRob3JpemF0aW9uIHNlcnZlcjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7IFRoZSBzZXJ2ZXIgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBjbGll bnQgYWZ0ZXIgc3VjY2Vzc2Z1bGx5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYXV0aGVudGlj YXRpbmcgdGhlIHJlc291cmNlIG93bmVyIGFuZCBvYnRhaW5pbmcgYXV0aG9yaXphdGlvbi48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BZnRlciBhbGws IE9BdXRoIGlzIGFsbCBhYm91dCBpc3N1aW5nIGFjY2VzcyB0b2tlbnMuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbHNvLCBJ IHRha2UgYmFjayBteSBzdGF0ZW1lbnQgb24gdGhlIGdyYW50IHR5cGUgaW4gbXkgcHJldmlvdXMg bWFpbC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoZSBkZWZpbml0aW9uIG9mIGdyYW50IGFuZCBncmFudF90eXBlIGFyZSBy ZXNwZWN0aXZlbHk6Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Z3JhbnQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBjcmVkZW50 aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBhdXRob3JpemF0aW9uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PmdyYW50X3R5cGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IChzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSkgdHlw ZSBvZiBncmFudCBzZW50IHRvIHRoZSB0b2tlbiBlbmRwb2ludCB0byBvYnRhaW4gdGhlIGFjY2Vz cyB0b2tlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5UaHVzLCB0aGUgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9p bnQgaW4gdGhpcyBjYXNlIGlzIHN0aWxsICdjb2RlJy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlc3BvbnNlIHR5cGUgb24g dGhlIG90aGVyIGhhbmQgaXMgbm90IHNvIHdlbGwgZGVmaW5lZCBpbiBSRkM2NzQ5LCBidXQgaXQg c2VlbXMgaXQgaXMgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludC4gVG8gZXhwcmVzcyB3aGF0IGlzIHRvDQogYmUgcmV0dXJu ZWQgZnJvbSB0b2tlbiBlbmRwb2ludCwgcGVyaGFwcyBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXIg dG8gdGhlIHRva2VuIGVuZHBvaW50LCB3aGljaCBpcyBhIHBhcmFsbGVsIHRvIHRoZSByZXNwb25z ZV90eXBlIHRvIHRoZSBBdXRob3JpemF0aW9uIEVuZHBvaW50IHNlZW1zIHRvIGJlIGEgbW9yZSBz eW1tZXRyaWMgd2F5LCB0aG91Z2ggSSBhbSBub3Qgc3VyZSBhdCBhbGwgaWYgdGhhdCBpcyBnb2lu ZyB0byBiZSBPQXV0aCBhbnkgbW9yZS4NCiBPbmUgc3RyYXctbWFuIGlzIHRvIGRlZmluZSBhIG5l dyBwYXJhbWV0ZXIgY2FsbGVkIHJlc3BvbnNlX3R5cGUgdG8gdGhlIHRva2VuIGVuZHBvaW50IHN1 Y2ggYXM6Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5yZXNwb25zZV90eXBlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgT1BUSU9OQUwuIEEgc3RyaW5n IHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBv aW50LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZW4gZGVmaW5lIHRoZSBiZWhhdmlvciBvZiB0aGUg ZW5kcG9pbnQgYWNjb3JkaW5nIHRvIHRoZSB2YWx1ZXMgYXMgdGhlIHBhcmFsbGVsIHRvIHRoZSBt dWx0aS1yZXNwb25zZSB0eXBlIHNwZWMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3Nw ZWNzL29hdXRoLXYyLW11bHRpcGxlLXJlc3BvbnNlLXR5cGVzLTFfMC5odG1sIj5odHRwOi8vb3Bl bmlkLm5ldC9zcGVjcy9vYXV0aC12Mi1tdWx0aXBsZS1yZXNwb25zZS10eXBlcy0xXzAuaHRtbDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIwMTQtMDctMjMgNzoyMSBHTVQtMDQ6MDAgUGhp bCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVu dEBvcmFjbGUuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGhlIGRyYWZ0IGlzIHZlcnkgY2xlYXIuJm5ic3A7PHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NClBoaWw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24g SnVsIDIzLCAyMDE0LCBhdCAwOjQ2LCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpz YWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBu ZXcgZ3JhbnQgdHlwZSB0aGF0IEkgd2FzIHRhbGtpbmcgYWJvdXQgd2FzJm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVvdDthdXRob3JpemF0aW9u X2NvZGVfYnV0X2RvX25vdF9yZXR1cm5fYWNjZXNzX25vcl9yZWZyZXNoX3Rva2VuJnF1b3Q7LCBz byB0byBzcGVhay4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JdCBkb2VzIG5vdCByZXR1cm4gYW55dGhpbmcgcGVyIHNlLCBidXQgYW4g ZXh0ZW5zaW9uIGNhbiBkZWZpbmUgc29tZXRoaW5nIG9uIHRvcCBvZiBpdC4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZW4s IE9JREMgY2FuIGRlZmluZSBhIGJpbmRpbmcgdG8gaXQgc28gdGhhdCB0aGUgYmluZGluZyBvbmx5 IHJldHVybnMgSUQgVG9rZW4uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgYmluZGluZyB3b3JrIHNob3VsZCBiZSBkb25lIGlu IE9JREYuIFNob3VsZCB0aGVyZSBiZSBzdWNoIGEgZ3JhbnQgdHlwZSwmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPml0IHdpbGwgYmUgYW4gZXh0cmVtZWx5IHNob3J0IHNwZWMuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BdCB0aGUgc2Ft ZSB0aW1lLCBpZiBhbnkgb3RoZXIgc3BlY2lmaWNhdGlvbiB3YW50ZWQgdG8gZGVmaW5lJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPm90 aGVyIHR5cGUgb2YgdG9rZW5zIGFuZCBoYXZlIGl0IHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVu ZHBvaW50LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5pdCBjYW4gYWxzbyB1c2UgdGhpcyBncmFudCB0eXBlLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgd2hh dCB5b3Ugd2FudCBpcyB0byBkZWZpbmUgYSBuZXcgZ3JhbnQgdHlwZSB0aGF0IHJldHVybnMgSUQg VG9rZW4gb25seSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+dGhlbiwgSSBhbSB3aXRoIEp1c3Rpbi4gU2luY2UgJnF1b3Q7b3RoZXIg cmVzcG9uc2UgdGhhbiBJRCBUb2tlbiZxdW90OyBpcyBvbmx5Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoZW9yZXRpY2FsLCB0aGlz IGlzIGEgbW9yZSBwbGF1c2libGUgd2F5IGZvcndhcmQsIEkgc3VwcG9zZS4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5hdDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MjAxNC0w Ny0yMiAxNDozMCBHTVQtMDQ6MDAgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpy aWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvIHRoZSBkcmFmdCB3b3VsZCBsaXRlcmFsbHkgdHVybiBp bnRvOjxicj4NCjxicj4NCiZxdW90O1RoZSBhNGMgcmVzcG9uc2UgdHlwZSBhbmQgZ3JhbnQgdHlw ZSByZXR1cm4gYW4gaWRfdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCBubyBhY2Nl c3MgdG9rZW4uIEFsbCBwYXJhbWV0ZXJzIGFuZCB2YWx1ZXMgYXJlIGRlZmluZWQgaW4gT0lEQy4m cXVvdDs8YnI+DQo8YnI+DQpTZWVtcyBsaWtlIHRoZSBwZXJmZWN0IG1pbmkgZXh0ZW5zaW9uIGRy YWZ0IGZvciBPSURGIHRvIGRvLjxicj4NCjxicj4NCi0tSnVzdGluPGJyPg0KPGJyPg0KL3NlbnQg ZnJvbSBteSBwaG9uZS88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxicj4NCk9uIEp1bCAyMiwgMjAxNCAxMDoyOSBBTSwgTmF0IFNha2ltdXJhICZsdDs8YSBo cmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGF0IGFib3V0IGp1c3QgZGVmaW5pbmcgYSBu ZXcgZ3JhbnQgdHlwZSBpbiB0aGlzIFdHPzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAy MDE0LTA3LTIyIDEyOjU2IEdNVC0wNDowMCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozo8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYXQgd291bGQgYmUgbmljZS4gSG93ZXZlciBvaWRjIHN0 aWxsIG5lZWRzIHRoZSBuZXcgZ3JhbnQgdHlwZSBpbiBvcmRlciB0byBpbXBsZW1lbnQgdGhlIHNh bWUgZmxvdy4mbmJzcDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFBoaWw8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIEp1bCAyMiwgMjAxNCwgYXQgMTE6MzUsIE5hdCBTYWtpbXVy YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+c2FraW11cmFAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJiM0Mzsx IHRvIEp1c3Rpbi4mbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgMjAxNC0wNy0yMiA5OjU0IEdNVC0wNDowMCBSaWNoZXIsIEp1c3RpbiBQ LiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIj5qcmljaGVyQG1pdHJlLm9y ZzwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEVy cm9ycyBsaWtlIHRoZXNlIG1ha2UgaXQgY2xlYXIgdG8gbWUgdGhhdCBpdCB3b3VsZCBtYWtlIG11 Y2ggbW9yZSBzZW5zZSB0byBkZXZlbG9wIHRoaXMgZG9jdW1lbnQgaW4gdGhlIE9wZW5JRCBGb3Vu ZGF0aW9uLiBJdCBzaG91bGQgYmUgc29tZXRoaW5nIHRoYXQgZGlyZWN0bHkgcmVmZXJlbmNlcyBP cGVuSUQgQ29ubmVjdCBDb3JlIGZvciBhbGwgb2YgdGhlc2UgdGVybXMgaW5zdGVhZCBvZiByZWRl ZmluaW5nIHRoZW0uIEl0J3MgZG9pbmcNCiBhdXRoZW50aWNhdGlvbiwgd2hpY2ggaXMgZnVuZGFt ZW50YWxseSB3aGF0IE9wZW5JRCBDb25uZWN0IGRvZXMgb24gdG9wIG9mIE9BdXRoLCBhbmQgSSBk b24ndCBzZWUgYSBnb29kIGFyZ3VtZW50IGZvciBkb2luZyB0aGlzIHdvcmsgaW4gdGhpcyB3b3Jr aW5nIGdyb3VwLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZu YnNwOy0tIEp1c3Rpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IE9uIEp1bCAyMiwgMjAxNCwgYXQgNDozMCBBTSwgVGhvbWFzIEJyb3llciAmbHQ7PGEgaHJlZj0i bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSI+dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE9uIE1vbiwgSnVsIDIxLCAyMDE0IGF0IDExOjUyIFBNLCBNaWtlIEpv bmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZvciB5b3Vy IHJldmlldywgVGhvbWFzLiZuYnNwOyBUaGUgJnF1b3Q7cHJvbXB0PWNvbnNlbnQmcXVvdDsgZGVm aW5pdGlvbiBiZWluZyBtaXNzaW5nIGlzIGFuIGVkaXRvcmlhbCBlcnJvci4mbmJzcDsgSXQgc2hv dWxkIGJlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uc2VudDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIg U0hPVUxEIHByb21wdCB0aGUgRW5kLVVzZXIgZm9yIGNvbnNlbnQgYmVmb3JlIHJldHVybmluZyBp bmZvcm1hdGlvbiB0byB0aGUgQ2xpZW50LiBJZiBpdCBjYW5ub3Qgb2J0YWluIGNvbnNlbnQsIGl0 IE1VU1QgcmV0dXJuIGFuIGVycm9yLCB0eXBpY2FsbHkgY29uc2VudF9yZXF1aXJlZC48YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5i c3A7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEknbGwgcGxhbiB0byBhZGQgaXQgaW4gdGhlIG5leHQgZHJhZnQuPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEl0IGxvb2tzIGxpa2UgdGhlIGNvbnNlbnRfcmVxdWlyZWQgZXJyb3IgbmVlZHMg dG8gYmUgZGVmaW5lZCB0b28sIGFuZCB5b3UgbWlnaHQgaGF2ZSBmb3Jnb3R0ZW4gdG8gYWxzbyBp bXBvcnQgYWNjb3VudF9zZWxlY3Rpb25fcmVxdWlyZWQgZnJvbSBPcGVuSUQgQ29ubmVjdC48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgYWdyZWUgdGhhdCB0 aGVyZSdzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJlc3BvbnNlIHdpdGggbXVsdGlwbGUgJnF1 b3Q7YW1yJnF1b3Q7IHZhbHVlcyB0aGF0IGluY2x1ZGVzICZxdW90O21mYSZxdW90OyBhbmQgb25l IHRoYXQgZG9lc24ndC4mbmJzcDsgVW5sZXNzIGEgY2xlYXIgdXNlIGNhc2UgZm9yIHdoeSAmcXVv dDttZmEmcXVvdDsgaXMgbmVlZGVkIGNhbiBiZSBpZGVudGlmaWVkLCB3ZSBjYW4gZGVsZXRlIGl0 IGluIHRoZSBuZXh0IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFua3MuPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIb3cgYWJvdXQgJnF1 b3Q7cHdkJnF1b3Q7IHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IEkgc2hvdWxkIHJldHVy biAmcXVvdDtwd2QmcXVvdDsgaWYgdGhlIHVzZXIgYXV0aGVudGljYXRlZCB1c2luZyBhIHBhc3N3 b3JkLCBidXQgd2hhdCAmcXVvdDt0aGUgc2VydmljZSBpZiBhIGNsaWVudCBzZWNyZXQgaXMgdXNl ZCZxdW90OyBtZWFucyBpbiB0aGUgZGVmaW5pdGlvbiBmb3IgdGhlICZxdW90O3B3ZCZxdW90OyB2 YWx1ZT88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IChOb3RhOiBJIGtub3cgeW91J3JlIGF0IElFVEYtOTAsIEknbSByZWFkeSB0byB3YWl0ICd0aWwg eW91IGNvbWUgYmFjayA7LSkgKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaG9tYXMgQnJveWVy PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgL3Q8YSBocmVmPSJodHRwOi8veG4tLW5uYS5tYS54 bi0tYndhLXh4Yi5qZS8iPsmULm1hLmLKgXdhLmplLzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyZndDsgTmF0IFNh a2ltdXJhICg9bmF0KTxicj4NCiZndDsmZ3Q7Jmd0OyBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRp b248YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIj5o dHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KJmd0OyZndDsmZ3Q7IEBfbmF0X2VuPGJy Pg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcg bGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9B dXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBOYXQgU2FraW11cmEgKD1uYXQpPGJyPg0KJmd0 OyBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9u YXQuc2FraW11cmEub3JnLyI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCiZndDsg QF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCk8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoYWlybWFuLCBPcGVuSUQgRm91 bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyI+aHR0cDovL25h dC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxicj4NCk5hdCBTYWtpbXVyYSAo PW5hdCk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoYWly bWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEu b3JnLyI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+LS0gPGJyPg0KVGhvbWFzIEJyb3ll cjxicj4NCi90PGEgaHJlZj0iaHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvIj7JlC5t YS5iyoF3YS5qZS88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtjb2xvcjojODg4ODg4Ij4tLQ0KPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9l bnpiIj5UaG9tYXMgQnJveWVyPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi90PGEg aHJlZj0iaHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvIj7JlC5tYS5iyoF3YS5qZS88 L2E+DQo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ LS0gPGJyPg0KTmF0IFNha2ltdXJhICg9bmF0KSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkNo YWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11 cmEub3JnLyI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86 cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4N CjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_4E1F6AAD24975D4BA5B16804296739439ADDDF56TK5EX14MBXC294r_-- From nobody Wed Jul 23 10:29:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE041A0104 for ; Wed, 23 Jul 2014 10:28:58 -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 i3jlP_jvBXlU for ; Wed, 23 Jul 2014 10:28:53 -0700 (PDT) Received: from mail-yh0-f41.google.com (mail-yh0-f41.google.com [209.85.213.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101A41A00F4 for ; Wed, 23 Jul 2014 10:28:52 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id b6so1037666yha.14 for ; Wed, 23 Jul 2014 10:28:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:thread-index:content-language; bh=JvwgNLwXX8s5itjHRgQm+bNYjYWD57atV01zW0rpqD8=; b=D8AWaT59d3U0h6YUxE5OCzbFRGkEoJ/dlfHAeLQgKUfYwlq67S+jLBGokUAssgvR0p Z2z0vG1PyNRg2tFMWT7HdP+hfTaGy1GrhgE/HMcqJLFyfajtBDhRz+N8DqS9ZSvw7qLu inxjhLD3Wr+cH8jK0KGvaZaAfosuVzMuqBT4lQYcg3wtlEkrF+H843mPwnVdVsi5aSxN FuJtTpr90bD6d4X8sj6TNf1vihKGVvJYF8rrklJ2ruWBAnHax/xHfXGjxUEIgu4vguaT rEiY8nbcO+zrA6a74EzRR4+NwgPEJEHHgEjcsDoyavBCGUv8Wk/Vl6NDuM7JuFKJMY67 cjnA== X-Gm-Message-State: ALoCoQlvCMJDm8e1QmYoPYS6XUX8UFbaxlRFqMX1ziVf5mN2so8UP5KOeCC5ginU8NwangNfmgVx X-Received: by 10.236.209.97 with SMTP id r61mr3655663yho.3.1406136531873; Wed, 23 Jul 2014 10:28:51 -0700 (PDT) Received: from gilszenbook ([12.236.17.3]) by mx.google.com with ESMTPSA id l46sm8474630yhq.44.2014.07.23.10.28.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 Jul 2014 10:28:51 -0700 (PDT) From: "Gil Kirkpatrick" To: "'Richard Snowden'" , References: In-Reply-To: Date: Wed, 23 Jul 2014 10:28:46 -0700 Message-ID: <00e001cfa69b$8f7b7c10$ae727430$@viewds.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E1_01CFA660.E3202680" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLGM5FMqYzc6UiaebJ5/hLKUG3h2JnAz9Ng Content-Language: en-au Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ClJ-D3j0m0flXQeNP4nXhVzFwh8 Subject: Re: [OAUTH-WG] Please help me understand OAuth 2.0 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, 23 Jul 2014 17:28:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E1_01CFA660.E3202680 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The RFCs 6749 and 6750 are a good place to start. = http://tools.ietf.org/html/rfc6749 and = http://tools.ietf.org/html/rfc6750.=20 =20 The first thing to understand is that OAuth2 targets a very specific use = case of a user authorizing an application (like Twitter) access to = resources they own (like photos) through a resource server (like = Facebook). It=E2=80=99s more an authN/authZ framework than a complete = system, and doesn=E2=80=99t directly address the traditional enterprise = use cases. Once you get your head around that, the rest is pretty = straightforward. Because it=E2=80=99s lightweight and thin, OAuth2 can = be used in lots of authN/authZ scenarios, for instance OpenID Connect = http://openid.net/connect/ and UMA = http://docs.kantarainitiative.org/uma/draft-uma-core.html. =20 You=E2=80=99d be best off clearing your mind of SAML concepts and = reading the RFCs, but to answer your questions: 1. Not really. Access tokens represent a user-granted authorization = for a specific application to access a specific resource scope. The = semantics of a scopes are left to the developer, but you can think of a = scope as a representation of what access(es) are allowed to what = resource(s). There is no user identity information necessarily conveyed = in the access token=E2=80=A6 that is what OpenID Connect is for. OpenID = Connect maps pretty closely to SAML. 2. Sort of. When the resource owner grants access, the AS issues an = authorization grant code. The client then presents the grant code to the = AS for an access token. The client includes the access token with each = resource request, and the resource server uses the scope in the token to = determine if access should be granted or not. 3. The role of the PDP is split between the AS and the RS. The AS = provides a token representing the user=E2=80=99s consent to access of a = particular scope, and the RS interprets the scope to grant access. The = scope _could_ just be a Boolean value indicating that access is allowed = or not, in which case the AS would be a PDP, but in practice the scope = encodes a set of permissions that the RS interprets in the context of = the specific resource request. =20 HTH, =20 -gil =20 =20 From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard Snowden Sent: Wednesday, 23 July 2014 2:57 AM To: oauth@ietf.org Subject: [OAUTH-WG] Please help me understand OAuth 2.0 =20 I am pretty familiar with the WS-* and SOAP Web Services world. At the = moment I'm trying to understand which features are available in the = OAuth 2.0 world. 1) SAML tokens: This access token in OAuth 2.0 - is it similar to what = SAML tokens are for? 2) STS: Is an OAuth 2.0 Authorization Server the equivalent to a STS? 3) PDP (Policy Decision Point): Is this also handled by the OAuth 2.0 = Authorization Server? Or does the Resource Server, based on the access = token, have to make the decision whether or not grant access to a = resource? ------=_NextPart_000_00E1_01CFA660.E3202680 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The RFCs 6749 and 6750 are a good place to = start. http://tools.ietf.org/html/rf= c6749 and http://tools.ietf.org/html/rf= c6750.

 

The first thing to understand is that = OAuth2 targets a very specific use case of a user authorizing an = application (like Twitter) access to resources they own (like photos) = through a resource server (like Facebook). It=E2=80=99s more an = authN/authZ framework than a complete system, and doesn=E2=80=99t = directly address the traditional enterprise use cases. Once you get your = head around that, the rest is pretty straightforward. Because = it=E2=80=99s lightweight and thin, OAuth2 can be used in lots of = authN/authZ scenarios, for instance =C2=A0OpenID Connect http://openid.net/connect/ and = UMA http:/= /docs.kantarainitiative.org/uma/draft-uma-core.html.

 

You=E2=80=99d be best off clearing your = mind of SAML concepts and reading the RFCs, but to answer your = questions:

1.      = Not really. Access tokens represent a = user-granted authorization for a specific application to access a = specific resource scope. The semantics of a scopes are left to the = developer, but you can think of a scope as a representation of what = access(es) are allowed to what resource(s). There is no user identity = information necessarily conveyed in the access token=E2=80=A6 that is = what OpenID Connect is for. OpenID Connect maps pretty closely to = SAML.

2.      = Sort of. When the resource owner grants = access, the AS issues an authorization grant code. The client then = presents the grant code to the AS for an access token. The client = includes the access token with each resource request, and the resource = server uses the scope in the token to determine if access should be = granted or not.

3.      = The role of the PDP is split between the = AS and the RS. The AS provides a token representing the user=E2=80=99s = consent to access of a particular scope, and the RS interprets the scope = to grant access. The scope _could_ just be a Boolean value = indicating that access is allowed or not, in which case the AS would be = a PDP, but in practice the scope encodes a set of permissions that the = RS interprets in the context of the specific resource = request.

 

HTH,

 

-gil

 

 

From: OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of Richard = Snowden
Sent: Wednesday, 23 July 2014 2:57 AM
To: = oauth@ietf.org
Subject: [OAUTH-WG] Please help me understand = OAuth 2.0

 

I am pretty familiar = with the WS-* and SOAP Web Services world. At the moment I'm trying to = understand which features are available in the OAuth 2.0 = world.

1) SAML tokens: This access token in = OAuth 2.0 - is it similar to what SAML tokens are = for?

2) STS: Is an OAuth 2.0 Authorization = Server the equivalent to a STS?

3) PDP (Policy Decision Point): Is this = also handled by the OAuth 2.0 Authorization Server? Or does the Resource = Server, based on the access token, have to make the decision whether or = not  grant access to a = resource?

------=_NextPart_000_00E1_01CFA660.E3202680-- From nobody Wed Jul 23 10:34:22 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056941B2BD3 for ; Wed, 23 Jul 2014 10:34:19 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD2GGQuHCjmS for ; Wed, 23 Jul 2014 10:34:15 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A4F1B2BCA for ; Wed, 23 Jul 2014 10:33:26 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id dc16so1649838qab.36 for ; Wed, 23 Jul 2014 10:33:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=2XkRQ/cdf0rLgdYzADG/pNmIJ7Hd4XBk3vb09ArCnb8=; b=CM3Bdqtr7Z6OjIAL3D51DGtieelzZQmjB0R4aH4o72AJwb5qnBqioHaX4uBATrUj74 c5Lvtq4zfooUwCjIks8R8Zt13Ofu9+q6axAAQd3iOfZug4wAGIvrcof4e6K55547tJo6 lgOmI15gwMKc960N3q9ZGf4WyeBa9YDcvdiwtKKaR22uO+EjxQjTO34C10xPN3BG7DrF dqDnG0KO12k3oq/m8zE/uz/6GrSrHP3SCN6k54c982EuwRx1QdeH6r82LVu9oc85tGne iDIwpYAvfVxpgoSH1Eo4lyo09D1wHM6r8Qs6zoDgGsV2Svo4kcMpyAQ8RUCTuhCDrXjd 16uw== X-Gm-Message-State: ALoCoQk00vBQTXYjsQFQPScJTuRgfElFvTWQTiKcNqCLvk2hqcm7KMjAFp+wpkOjNYJnB/n73o8V X-Received: by 10.140.95.241 with SMTP id i104mr4610125qge.6.1406136805504; Wed, 23 Jul 2014 10:33:25 -0700 (PDT) Received: from [10.190.115.223] (249.sub-70-194-140.myvzw.com. [70.194.140.249]) by mx.google.com with ESMTPSA id g6sm5003632qaf.15.2014.07.23.10.33.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 10:33:24 -0700 (PDT) References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> Mime-Version: 1.0 (1.0) In-Reply-To: <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-36AF50AB-D1EE-4BC0-85BE-24EFCC29FCF7; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> X-Mailer: iPhone Mail (11D257) From: John Bradley Date: Wed, 23 Jul 2014 12:33:22 -0500 To: "torsten@lodderstedt.net" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3zSvZMSBTAPbHluQgc99_RmTXeI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 17:34:19 -0000 --Apple-Mail-36AF50AB-D1EE-4BC0-85BE-24EFCC29FCF7 Content-Type: multipart/alternative; boundary=Apple-Mail-B8D44758-71A6-400B-B206-FF3C91369242 Content-Transfer-Encoding: 7bit --Apple-Mail-B8D44758-71A6-400B-B206-FF3C91369242 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If we use the token endpoint then a new grant_type is the best way.=20 It sort of overloads code, but that is better than messing with response_typ= e for the authorization endpoint to change the response from the token_endpo= int. That is in my opinion a champion bad idea.=20 In discussions developing Connect we decided not to open this can of worms b= ecause no good would come of it. =20 The token_endpoint returns a access token. Nothing requires scope to be ass= ociates with the token.=20 That is the best solution. No change required. Better interoperability in m= y opinion.=20 Still on my way to TO, getting in later today.=20 John B.=20 Sent from my iPhone > On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >=20 > The "response type" of the token endpoint is controlled by the value of th= e parameter "grant_type". So there is no need to introduce a new parameter. >=20 > wrt to a potential "no_access_token" grant type. I do not consider this a g= ood idea as it changes the semantics of the token endpoint (as already point= ed out by Thomas). This endpoint ALWAYS responds with an access token to any= grant type. I therefore would prefer to use another endpoint for the intend= ed purpose. >=20 > regards, > Torsten. >=20 > =20 >=20 > Am 23.07.2014 13:04, schrieb Nat Sakimura: >=20 >> IMHO, changing the semantics of "response_type" @ authz endpoint this way= is not a good thing.=20 >> =20 >> Instead, defining a new parameter "response_type" @ token endpoint, as I d= escribed in my previous message,=20 >> probably is better. At least, it does not change the semantics of the par= ameters of RFC6749.=20 >> =20 >> Nat=20 >>=20 >>=20 >> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >>> No, I mean response_type=3Dnone and response_type=3Did_token don't gener= ate a code or access token so you don't use the Token Endpoint (which is not= the same as the Authentication Endpoint BTW). >>> With response_type=3Dcode_for_id_token, you get a code and exchange it f= or an id_token only, rather than an access_token, so you're changing the sem= antics of the Token Endpoint. >>> =20 >>> I'm not saying it's a bad thing, just that you can't really compare none= and id_token with code_for_id_token. >>>=20 >>>=20 >>>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. w= rote: >>>> It's only "not using the token endpoint" because the token endpoint cop= y-pasted and renamed the authentication endpoint. >>>> =20 >>>> -- Justin >>>>=20 >>>>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote:= >>>>>=20 >>>>> Except that these are about not using the Token Endpoint at all, where= as the current proposal is about the Token Endpoint not returning an access_= token field in the JSON. >>>>>=20 >>>>>=20 >>>>>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones wrote: >>>>>> The response_type "none" is already used in practice, which returns n= o access token. It was accepted by the designated experts and registered in= the IANA OAuth Authorization Endpoint Response Types registry at http://www= .iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint. The r= egistered "id_token" response type also returns no access token. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> So I think the question of whether response types that result in no a= ccess token being returned are acceptable within OAuth 2.0 is already settle= d, as a practical matter. Lots of OAuth implementations are already using s= uch response types. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt >>>>>> Sent: Wednesday, July 23, 2014 7:09 AM >>>>>> To: Nat Sakimura >>>>>> Cc: >>>>>> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth= -v2-user-a4c-05.txt >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Yes. This is why it has to be discussed in the IETF. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> @independentid >>>>>>=20 >>>>>> www.independentid.com >>>>>>=20 >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote:= >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Reading back the RFC6749, I am not sure if there is a good way of sup= pressing access token from the response and still be OAuth. It will break wh= ole bunch of implicit definitions like:=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> authorization server >>>>>> The server issuing access tokens to the client after successful= ly >>>>>> authenticating the resource owner and obtaining authorization. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> After all, OAuth is all about issuing access tokens.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Also, I take back my statement on the grant type in my previous mail.= =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> The definition of grant and grant_type are respectively:=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> grant=20 >>>>>>=20 >>>>>> credential representing the resource owner's authorization >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> grant_type >>>>>>=20 >>>>>> (string representing the) type of grant sent to the token endpoin= t to obtain the access token >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Thus, the grant sent to the token endpoint in this case is still 'cod= e'.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Response type on the other hand is not so well defined in RFC6749, bu= t it seems it is representing what is to be returned from the authorization e= ndpoint. To express what is to be returned from token endpoint, perhaps defi= ning a new parameter to the token endpoint, which is a parallel to the respo= nse_type to the Authorization Endpoint seems to be a more symmetric way, tho= ugh I am not sure at all if that is going to be OAuth any more. One straw-ma= n is to define a new parameter called response_type to the token endpoint su= ch as:=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> response_type >>>>>>=20 >>>>>> OPTIONAL. A string representing what is to be returned from the t= oken endpoint.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Then define the behavior of the endpoint according to the values as t= he parallel to the multi-response type spec.=20 >>>>>>=20 >>>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Nat >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>>>>>=20 >>>>>> The draft is very clear.=20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>>=20 >>>>>> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >>>>>>=20 >>>>>> The new grant type that I was talking about was=20 >>>>>>=20 >>>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", so t= o speak.=20 >>>>>>=20 >>>>>> It does not return anything per se, but an extension can define somet= hing on top of it.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Then, OIDC can define a binding to it so that the binding only return= s ID Token.=20 >>>>>>=20 >>>>>> This binding work should be done in OIDF. Should there be such a gran= t type,=20 >>>>>>=20 >>>>>> it will be an extremely short spec.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> At the same time, if any other specification wanted to define=20 >>>>>>=20 >>>>>> other type of tokens and have it returned from the token endpoint,=20= >>>>>>=20 >>>>>> it can also use this grant type.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> If what you want is to define a new grant type that returns ID Token o= nly,=20 >>>>>>=20 >>>>>> then, I am with Justin. Since "other response than ID Token" is only=20= >>>>>>=20 >>>>>> theoretical, this is a more plausible way forward, I suppose.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Nat >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>>>>>=20 >>>>>> So the draft would literally turn into: >>>>>>=20 >>>>>> "The a4c response type and grant type return an id_token from the tok= en endpoint with no access token. All parameters and values are defined in O= IDC." >>>>>>=20 >>>>>> Seems like the perfect mini extension draft for OIDF to do. >>>>>>=20 >>>>>> --Justin >>>>>>=20 >>>>>> /sent from my phone/ >>>>>>=20 >>>>>>=20 >>>>>> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >>>>>> > >>>>>> > What about just defining a new grant type in this WG? >>>>>> > >>>>>> > >>>>>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>>>>> >> >>>>>> >> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=20 >>>>>> >> >>>>>> >> Phil >>>>>> >> >>>>>> >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote= : >>>>>> >> >>>>>> >>> +1 to Justin.=20 >>>>>> >>> >>>>>> >>> >>>>>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >>>>>> >>>> >>>>>> >>>> Errors like these make it clear to me that it would make much mo= re sense to develop this document in the OpenID Foundation. It should be som= ething that directly references OpenID Connect Core for all of these terms i= nstead of redefining them. It's doing authentication, which is fundamentally= what OpenID Connect does on top of OAuth, and I don't see a good argument f= or doing this work in this working group. >>>>>> >>>> >>>>>> >>>> -- Justin >>>>>> >>>> >>>>>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer w= rote: >>>>>> >>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones wrote: >>>>>> >>>>>> >>>>>> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" defini= tion being missing is an editorial error. It should be: >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>>> >>>>>> >>>>>> consent >>>>>> >>>>>> >>>>>> >>>>>> The Authorization Server SHOULD prompt the End-User for consen= t before returning information to the Client. If it cannot obtain consent, i= t MUST return an error, typically consent_required. >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>>> >>>>>> >>>>>> I'll plan to add it in the next draft. >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> It looks like the consent_required error needs to be defined to= o, and you might have forgotten to also import account_selection_required fr= om OpenID Connect. >>>>>> >>>>> =20 >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>>> >>>>>> >>>>>> I agree that there's no difference between a response with mul= tiple "amr" values that includes "mfa" and one that doesn't. Unless a clear= use case for why "mfa" is needed can be identified, we can delete it in the= next draft. >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> Thanks. >>>>>> >>>>> >>>>>> >>>>> How about "pwd" then? I fully understand that I should return "= pwd" if the user authenticated using a password, but what "the service if a c= lient secret is used" means in the definition for the "pwd" value? >>>>>> >>>>> >>>>>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you com= e back ;-) ) >>>>>> >>>>> >>>>>> >>>>> -- >>>>>> >>>>> Thomas Broyer >>>>>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>> >>>>> _______________________________________________ >>>>>> >>>>> 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 >>>>>> >>>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> -- >>>>>> >>> Nat Sakimura (=3Dnat) >>>>>> >>> Chairman, OpenID Foundation >>>>>> >>> http://nat.sakimura.org/ >>>>>> >>> @_nat_en >>>>>> >>> >>>>>> >>> _______________________________________________ >>>>>> >>> OAuth mailing list >>>>>> >>> OAuth@ietf.org >>>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Nat Sakimura (=3Dnat) >>>>>> > Chairman, OpenID Foundation >>>>>> > http://nat.sakimura.org/ >>>>>> > @_nat_en >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> --=20 >>>>>> Nat Sakimura (=3Dnat) >>>>>>=20 >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> --=20 >>>>>> Nat Sakimura (=3Dnat) >>>>>>=20 >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Thomas Broyer >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> =20 >>> --=20 >>> Thomas Broyer >>> /t=C9=94.ma.b=CA=81wa.je/ >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> =20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > =20 >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-B8D44758-71A6-400B-B206-FF3C91369242 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If we use the token endpoint then a ne= w grant_type is the best way. 

It sort of over= loads code, but that is better than messing with response_type for the autho= rization endpoint to change the response from the token_endpoint.  That= is in my opinion a champion bad idea. 

In dis= cussions developing Connect we decided not to open this can of worms because= no good would come of it.   

The token_e= ndpoint returns a access token.  Nothing requires scope to be associate= s with the token. 

That is the best solution. &= nbsp;No change required.  Better interoperability in my opinion. <= /div>

Still on my way to TO, getting in later today. = ;

John B. 



Se= nt from my iPhone

On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the value of t= he parameter "grant_type". So there is no need to introduce a new parameter.=

wrt to a potential "no_access_token" grant type. I do not consider this a= good idea as it changes the semantics of the token endpoint (as already poi= nted out by Thomas). This endpoint ALWAYS responds with an access token to a= ny grant type. I therefore would prefer to use another endpoint for the inte= nded purpose.

regards,
Torsten.

 

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type" @ authz endpoint this w= ay is not a good thing. 
 
Instead, defining a new parameter "response_type" @ token endpoint, as I des= cribed in my previous message, 
probably is better. At least, it does not change the semantics of the p= arameters of RFC6749. 
 
 Nat 


2014-07-23 12:48 GMT-04:00 Thomas Broyer &l= t;t.broyer@gmail.com>:
No, I mean response_type=3Dnone and response_type=3Did_toke= n don't generate a code or access token so you don't use the Token Endpoint (= which is not the same as the Authentication Endpoint BTW).
With response_type=3Dcode_for_id_token, you get a code and exchange it f= or an id_token only, rather than an access_token, so you're changing the sem= antics of the Token Endpoint.
 
I'm not saying it's a bad thing, just that you can't really compare non= e and id_token with code_for_id_token.


On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P= . <jricher@mitre.org> wrote:
It's only "not using the token endpoin= t" because the token endpoint copy-pasted and renamed the authentication end= point.
 
 -- Justin

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:

Except that these are about not using the Token Endpoint at= all, whereas the current proposal is about the Token Endpoint not returning= an access_token field in the JSON.


On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@microsoft= .com> wrote:

The response_type "none" is already used i= n practice, which returns no access token.  It was accepted by the desi= gnated experts and registered in the IANA OAuth Authorization Endpoint Respo= nse Types registry at http://www.iana.org/assignments/oauth-= parameters/oauth-parameters.xml#endpoint.  The registered "id_token= " response type also returns no access token.

 

So I think the question of whether respon= se types that result in no access token being returned are acceptable within= OAuth 2.0 is already settled, as a practical matter.  Lots of OAuth im= plementations are already using such response types.

 

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AMTo: Nat Sakimura
Cc: <oauth@ietf.org>
Subject: Re:= [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt=

&n= bsp;

Yes. This is why it has to be discussed in the IETF.<= span style=3D"text-decoration: underline;">

&n= bsp;

Phil

 

@independentid

phil.hunt@oracle.com

 

&n= bsp;

&n= bsp;

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com> wrote:



<= /span>

Reading back the RFC6749, I am not sure if there is a= good way of suppressing access token from the response and still be OAuth. I= t will break whole bunch of implicit definitions like: 

&n= bsp;

authorization server
      The ser= ver issuing access tokens to the client after successfully
   =   authenticating the resource owner and obtaining authorization.

&n= bsp;

After all, OAuth is all about issuing access tokens.&= nbsp;

&n= bsp;

Also, I take back my statement on the grant type in m= y previous mail. 

&n= bsp;

The definition of grant and grant_type are respective= ly: 

&n= bsp;

grant 

    credential representing the resource ow= ner's authorization

         = ;  

grant_type

    (string representing the) type of g= rant sent to the token endpoint to obtain the access token

&n= bsp;

Thus, the grant sent to the token endpoint in this ca= se is still 'code'. =

&n= bsp;

Response type on the other hand is not so well define= d in RFC6749, but it seems it is representing what is to be returned from th= e authorization endpoint. To express what is to be returned from token endpo= int, perhaps defining a new parameter to the token endpoint, which is a para= llel to the response_type to the Authorization Endpoint seems to be a more s= ymmetric way, though I am not sure at all if that is going to be OAuth any m= ore. One straw-man is to define a new parameter called response_type to the t= oken endpoint such as: 

&n= bsp;

response_type

    OPTIONAL. A string representing what is= to be returned from the token endpoint. 

=

    

Then define the behavior of the endpoint according to= the values as the parallel to the multi-response type spec. 

&n= bsp;

Nat

    

&n= bsp;

&n= bsp;

 

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:<= /span>

The draft is very clear. 

Phil


On Jul 23, 2014= , at 0:46, Nat Sakimura <sakimura@g= mail.com> wrote:

The new grant type that I was talking about was =

"authorization_code_but_do_not_return_access_nor_refr= esh_token", so to speak. 

It does not return anything per se, but an extension c= an define something on top of it. 

&n= bsp;

Then, OIDC can define a binding to it so that the bin= ding only returns ID Token. 

This binding work should be done in OIDF. Should ther= e be such a grant type, 

it will be an extremely short spec. 

&n= bsp;

At the same time, if any other specification wanted t= o define 

other type of tokens and have it returned from the to= ken endpoint, 

it can also use this grant type. 

&n= bsp;

If what you want is to define a new grant type that r= eturns ID Token only, 

then, I am with Justin. Since "other response than ID= Token" is only 

theoretical, this is a more plausible way forward, I s= uppose. 

&n= bsp;

Nat

 

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:<= /p>

So the draft would literally turn into:

"The a= 4c response type and grant type return an id_token from the token endpoint w= ith no access token. All parameters and values are defined in OIDC."

= Seems like the perfect mini extension draft for OIDF to do.

--Justi= n

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
><= br> > What about just defining a new grant type in this WG?
>
&= gt;
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> Th= at would be nice. However oidc still needs the new grant type in order to im= plement the same flow. 
>>
>> Phil
>>
= >> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>&= gt; +1 to Justin. 
>>>
>>>
>>> 2= 014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>>= Errors like these make it clear to me that it would make much more sense to= develop this document in the OpenID Foundation. It should be something that= directly references OpenID Connect Core for all of these terms instead of r= edefining them. It's doing authentication, which is fundamentally what OpenI= D Connect does on top of OAuth, and I don't see a good argument for doing th= is work in this working group.
>>>>
>>>> &nb= sp;-- Justin
>>>>
>>>> On Jul 22, 2014, at 4= :30 AM, Thomas Broyer <t.broyer@gma= il.com> wrote:
>>>>
>>>>>
>= >>>>
>>>>>
>>>>> On Mon, J= ul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>&g= t;>
>>>>>> Thanks for your review, Thomas.  Th= e "prompt=3Dconsent" definition being missing is an editorial error.  I= t should be:
>>>>>>
>>>>>>  = ;
>>>>>>
>>>>>> consent
>= >>>>>
>>>>>> The Authorization Server S= HOULD prompt the End-User for consent before returning information to the Cl= ient. If it cannot obtain consent, it MUST return an error, typically consen= t_required.
>>>>>>
>>>>>>  =
>>>>>>
>>>>>> I'll plan to add i= t in the next draft.
>>>>>
>>>>>
&= gt;>>>> It looks like the consent_required error needs to be def= ined too, and you might have forgotten to also import account_selection_requ= ired from OpenID Connect.
>>>>>  
>>>&g= t;>>
>>>>>>  
>>>>>><= br> >>>>>> I agree that there's no difference between a re= sponse with multiple "amr" values that includes "mfa" and one that doesn't.&= nbsp; Unless a clear use case for why "mfa" is needed can be identified, we c= an delete it in the next draft.
>>>>>
>>>>= ;>
>>>>> Thanks.
>>>>>
>>= >>> How about "pwd" then? I fully understand that I should return "= pwd" if the user authenticated using a password, but what "the service if a c= lient secret is used" means in the definition for the "pwd" value?
>&= gt;>>>
>>>>> (Nota: I know you're at IETF-90, I'= m ready to wait 'til you come back ;-) )
>>>>>
>&g= t;>>> --
>>>>> Thomas Broyer
>>>>= ;> /t=C9=94.ma.b=CA=81wa.je= /
>>>>> _____________________________________________= __
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/m= ailman/listinfo/oauth
>>>>
>>>>
>= >>>
>>>> __________________________________________= _____
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/lis= tinfo/oauth
>>>>
>>>
>>>
&= gt;>>
>>> --
>>> Nat Sakimura (=3Dnat)
&= gt;>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
= >>>
>>> _____________________________________________= __
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3D= nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en



&n= bsp;

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en<= /span>



&n= bsp;

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en<= /span>

&n= bsp;


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



 
--
Thomas Broyer
/t=C9= =94.ma.b=CA=81wa.je/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h


 
--
Thomas Broyer<= br>/t=C9=94.ma.b=CA=81wa.je/

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



 
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
htt= p://nat.sakimura.org/
@_nat_en

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

 

 
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-B8D44758-71A6-400B-B206-FF3C91369242-- --Apple-Mail-36AF50AB-D1EE-4BC0-85BE-24EFCC29FCF7 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNzIzMTczMzIzWjAjBgkqhkiG9w0BCQQxFgQUWWPpubeAqckjIL0N kCXIh84xAB4wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAanSzz3TfrTBOvIyxpACrK2Cb8cV3NcXhhO5/5KFvMNw5AZbD TorwL+GjlsIyZE7tOVgYV7ryKW3p25Jmxm7+Ef8TRIa1Yln50XGnqZnxdhnOmlj8Og3BzWicppXb c4LFxrj8xMiJFES8pLb/U7RZEm+IIKG05dNODGNf3TuPSKnX99R6kL+z57twB14a3z7mWfQtKB+o 1vbvSU3y7fU4Yp6dJ4Nb7L52v150W/Q+Wh8dVL/apBrlc/OcYdvj4I0XInduoUcUHhsfJ2veLtPy P4eCtCRMDl1rSZiKaaeTKpDI4Lu2Hxm1UmZu6targ5OwMJ1X/RH37LqrzC9xm1hrngAAAAAAAA== --Apple-Mail-36AF50AB-D1EE-4BC0-85BE-24EFCC29FCF7-- From nobody Wed Jul 23 10:35:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3806B1B2BCD for ; Wed, 23 Jul 2014 10:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGfw3p1HQZGy for ; Wed, 23 Jul 2014 10:35:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 188B01B2BDF for ; Wed, 23 Jul 2014 10:34:43 -0700 (PDT) Received: from BLUPR03CA036.namprd03.prod.outlook.com (10.141.30.29) by CY1PR0301MB0763.namprd03.prod.outlook.com (25.160.160.11) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 17:34:41 +0000 Received: from BY2FFO11FD042.protection.gbl (2a01:111:f400:7c0c::144) by BLUPR03CA036.outlook.office365.com (2a01:111:e400:879::29) with Microsoft SMTP Server (TLS) id 15.0.995.11 via Frontend Transport; Wed, 23 Jul 2014 17:34:40 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD042.mail.protection.outlook.com (10.1.14.227) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 23 Jul 2014 17:34:39 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Wed, 23 Jul 2014 17:33:54 +0000 From: Mike Jones To: Gil Kirkpatrick , 'Richard Snowden' , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Please help me understand OAuth 2.0 Thread-Index: AQHPplyF7UlCloj2LkOY1JHjTz2egJut6mQAgAABHBA= Date: Wed, 23 Jul 2014 17:33:54 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADDE0B4@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <00e001cfa69b$8f7b7c10$ae727430$@viewds.com> In-Reply-To: <00e001cfa69b$8f7b7c10$ae727430$@viewds.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADDE0B4TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(199002)(189002)(53474002)(69234005)(377454003)(31966008)(92726001)(81542001)(79102001)(83072002)(76482001)(21056001)(19625215002)(4396001)(97736001)(46102001)(512874002)(19580395003)(77096002)(50986999)(106116001)(81342001)(66066001)(107886001)(20776003)(83322001)(85852003)(15975445006)(84326002)(19617315012)(44976005)(16236675004)(2656002)(107046002)(54356999)(74502001)(69596002)(64706001)(85306003)(86362001)(26826002)(80022001)(77982001)(92566001)(19580405001)(33656002)(86612001)(87936001)(16297215004)(84676001)(106466001)(95666004)(15202345003)(68736004)(55846006)(71186001)(6806004)(76176999)(15395725005)(19300405004)(74662001)(99396002)(81156004)(104016003)(182903001); DIR:OUT; SFP:; SCL:1; SRVR:CY1PR0301MB0763; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 028166BF91 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jhDgUshlsa_YoZJnYKfE_sU1OXY Subject: Re: [OAUTH-WG] Please help me understand OAuth 2.0 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, 23 Jul 2014 17:35:24 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADDE0B4TK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJLCB0aGUgaW5kaXZpZHVhbCBzdWJtaXNzaW9uIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWV4Y2hhbmdlIGRlc2NyaWJlcyBhZGRpbmcg c29tZXRoaW5nIGFuYWxvZ291cyB0byBXUy1UcnVzdCB0b2tlbiBleGNoYW5nZSB0byBPQXV0aCAy LjAuICBUaGF0IHdpbGwgYmUgZGlzY3Vzc2VkIGF0IHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIG1l ZXRpbmcgdG9tb3Jyb3cuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR2lsIEtpcmtwYXRyaWNrDQpTZW50OiBX ZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQgMTA6MjkgQU0NClRvOiAnUmljaGFyZCBTbm93ZGVuJzsg b2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFBsZWFzZSBoZWxwIG1lIHVu ZGVyc3RhbmQgT0F1dGggMi4wDQoNClRoZSBSRkNzIDY3NDkgYW5kIDY3NTAgYXJlIGEgZ29vZCBw bGFjZSB0byBzdGFydC4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSBhbmQgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc1MC4NCg0KVGhlIGZpcnN0IHRoaW5nIHRvIHVu ZGVyc3RhbmQgaXMgdGhhdCBPQXV0aDIgdGFyZ2V0cyBhIHZlcnkgc3BlY2lmaWMgdXNlIGNhc2Ug b2YgYSB1c2VyIGF1dGhvcml6aW5nIGFuIGFwcGxpY2F0aW9uIChsaWtlIFR3aXR0ZXIpIGFjY2Vz cyB0byByZXNvdXJjZXMgdGhleSBvd24gKGxpa2UgcGhvdG9zKSB0aHJvdWdoIGEgcmVzb3VyY2Ug c2VydmVyIChsaWtlIEZhY2Vib29rKS4gSXTigJlzIG1vcmUgYW4gYXV0aE4vYXV0aFogZnJhbWV3 b3JrIHRoYW4gYSBjb21wbGV0ZSBzeXN0ZW0sIGFuZCBkb2VzbuKAmXQgZGlyZWN0bHkgYWRkcmVz cyB0aGUgdHJhZGl0aW9uYWwgZW50ZXJwcmlzZSB1c2UgY2FzZXMuIE9uY2UgeW91IGdldCB5b3Vy IGhlYWQgYXJvdW5kIHRoYXQsIHRoZSByZXN0IGlzIHByZXR0eSBzdHJhaWdodGZvcndhcmQuIEJl Y2F1c2UgaXTigJlzIGxpZ2h0d2VpZ2h0IGFuZCB0aGluLCBPQXV0aDIgY2FuIGJlIHVzZWQgaW4g bG90cyBvZiBhdXRoTi9hdXRoWiBzY2VuYXJpb3MsIGZvciBpbnN0YW5jZSAgT3BlbklEIENvbm5l Y3QgaHR0cDovL29wZW5pZC5uZXQvY29ubmVjdC8gYW5kIFVNQSBodHRwOi8vZG9jcy5rYW50YXJh aW5pdGlhdGl2ZS5vcmcvdW1hL2RyYWZ0LXVtYS1jb3JlLmh0bWwuDQoNCllvdeKAmWQgYmUgYmVz dCBvZmYgY2xlYXJpbmcgeW91ciBtaW5kIG9mIFNBTUwgY29uY2VwdHMgYW5kIHJlYWRpbmcgdGhl IFJGQ3MsIGJ1dCB0byBhbnN3ZXIgeW91ciBxdWVzdGlvbnM6DQoNCjEuICAgICAgTm90IHJlYWxs eS4gQWNjZXNzIHRva2VucyByZXByZXNlbnQgYSB1c2VyLWdyYW50ZWQgYXV0aG9yaXphdGlvbiBm b3IgYSBzcGVjaWZpYyBhcHBsaWNhdGlvbiB0byBhY2Nlc3MgYSBzcGVjaWZpYyByZXNvdXJjZSBz Y29wZS4gVGhlIHNlbWFudGljcyBvZiBhIHNjb3BlcyBhcmUgbGVmdCB0byB0aGUgZGV2ZWxvcGVy LCBidXQgeW91IGNhbiB0aGluayBvZiBhIHNjb3BlIGFzIGEgcmVwcmVzZW50YXRpb24gb2Ygd2hh dCBhY2Nlc3MoZXMpIGFyZSBhbGxvd2VkIHRvIHdoYXQgcmVzb3VyY2UocykuIFRoZXJlIGlzIG5v IHVzZXIgaWRlbnRpdHkgaW5mb3JtYXRpb24gbmVjZXNzYXJpbHkgY29udmV5ZWQgaW4gdGhlIGFj Y2VzcyB0b2tlbuKApiB0aGF0IGlzIHdoYXQgT3BlbklEIENvbm5lY3QgaXMgZm9yLiBPcGVuSUQg Q29ubmVjdCBtYXBzIHByZXR0eSBjbG9zZWx5IHRvIFNBTUwuDQoNCjIuICAgICAgU29ydCBvZi4g V2hlbiB0aGUgcmVzb3VyY2Ugb3duZXIgZ3JhbnRzIGFjY2VzcywgdGhlIEFTIGlzc3VlcyBhbiBh dXRob3JpemF0aW9uIGdyYW50IGNvZGUuIFRoZSBjbGllbnQgdGhlbiBwcmVzZW50cyB0aGUgZ3Jh bnQgY29kZSB0byB0aGUgQVMgZm9yIGFuIGFjY2VzcyB0b2tlbi4gVGhlIGNsaWVudCBpbmNsdWRl cyB0aGUgYWNjZXNzIHRva2VuIHdpdGggZWFjaCByZXNvdXJjZSByZXF1ZXN0LCBhbmQgdGhlIHJl c291cmNlIHNlcnZlciB1c2VzIHRoZSBzY29wZSBpbiB0aGUgdG9rZW4gdG8gZGV0ZXJtaW5lIGlm IGFjY2VzcyBzaG91bGQgYmUgZ3JhbnRlZCBvciBub3QuDQoNCjMuICAgICAgVGhlIHJvbGUgb2Yg dGhlIFBEUCBpcyBzcGxpdCBiZXR3ZWVuIHRoZSBBUyBhbmQgdGhlIFJTLiBUaGUgQVMgcHJvdmlk ZXMgYSB0b2tlbiByZXByZXNlbnRpbmcgdGhlIHVzZXLigJlzIGNvbnNlbnQgdG8gYWNjZXNzIG9m IGEgcGFydGljdWxhciBzY29wZSwgYW5kIHRoZSBSUyBpbnRlcnByZXRzIHRoZSBzY29wZSB0byBn cmFudCBhY2Nlc3MuIFRoZSBzY29wZSBfY291bGRfIGp1c3QgYmUgYSBCb29sZWFuIHZhbHVlIGlu ZGljYXRpbmcgdGhhdCBhY2Nlc3MgaXMgYWxsb3dlZCBvciBub3QsIGluIHdoaWNoIGNhc2UgdGhl IEFTIHdvdWxkIGJlIGEgUERQLCBidXQgaW4gcHJhY3RpY2UgdGhlIHNjb3BlIGVuY29kZXMgYSBz ZXQgb2YgcGVybWlzc2lvbnMgdGhhdCB0aGUgUlMgaW50ZXJwcmV0cyBpbiB0aGUgY29udGV4dCBv ZiB0aGUgc3BlY2lmaWMgcmVzb3VyY2UgcmVxdWVzdC4NCg0KSFRILA0KDQotZ2lsDQoNCg0KRnJv bTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmlj aGFyZCBTbm93ZGVuDQpTZW50OiBXZWRuZXNkYXksIDIzIEp1bHkgMjAxNCAyOjU3IEFNDQpUbzog b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogW09BVVRILVdH XSBQbGVhc2UgaGVscCBtZSB1bmRlcnN0YW5kIE9BdXRoIDIuMA0KDQpJIGFtIHByZXR0eSBmYW1p bGlhciB3aXRoIHRoZSBXUy0qIGFuZCBTT0FQIFdlYiBTZXJ2aWNlcyB3b3JsZC4gQXQgdGhlIG1v bWVudCBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2hpY2ggZmVhdHVyZXMgYXJlIGF2YWlsYWJs ZSBpbiB0aGUgT0F1dGggMi4wIHdvcmxkLg0KMSkgU0FNTCB0b2tlbnM6IFRoaXMgYWNjZXNzIHRv a2VuIGluIE9BdXRoIDIuMCAtIGlzIGl0IHNpbWlsYXIgdG8gd2hhdCBTQU1MIHRva2VucyBhcmUg Zm9yPw0KMikgU1RTOiBJcyBhbiBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdGhlIGVx dWl2YWxlbnQgdG8gYSBTVFM/DQozKSBQRFAgKFBvbGljeSBEZWNpc2lvbiBQb2ludCk6IElzIHRo aXMgYWxzbyBoYW5kbGVkIGJ5IHRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXI/IE9y IGRvZXMgdGhlIFJlc291cmNlIFNlcnZlciwgYmFzZWQgb24gdGhlIGFjY2VzcyB0b2tlbiwgaGF2 ZSB0byBtYWtlIHRoZSBkZWNpc2lvbiB3aGV0aGVyIG9yIG5vdCAgZ3JhbnQgYWNjZXNzIHRvIGEg cmVzb3VyY2U/DQo= --_000_4E1F6AAD24975D4BA5B16804296739439ADDE0B4TK5EX14MBXC294r_ 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 IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1 NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9w OjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1s ZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5GWUksIHRoZSBpbmRpdmlkdWFsIHN1Ym1pc3Npb24gZHJhZnQNCjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWV4Y2hh bmdlIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC10b2tlbi1l eGNoYW5nZTwvYT4gZGVzY3JpYmVzIGFkZGluZyBzb21ldGhpbmcgYW5hbG9nb3VzIHRvIFdTLVRy dXN0IHRva2VuIGV4Y2hhbmdlIHRvIE9BdXRoIDIuMC4mbmJzcDsgVGhhdCB3aWxsIGJlIGRpc2N1 c3NlZCBhdCB0aGUgT0F1dGggd29ya2luZw0KIGdyb3VwIG1lZXRpbmcgdG9tb3Jyb3cuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+R2lsIEtpcmtw YXRyaWNrPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAyMywgMjAxNCAxMDoyOSBB TTxicj4NCjxiPlRvOjwvYj4gJ1JpY2hhcmQgU25vd2Rlbic7IG9hdXRoQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFBsZWFzZSBoZWxwIG1lIHVuZGVyc3RhbmQg T0F1dGggMi4wPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGUgUkZDcyA2NzQ5IGFuZCA2NzUwIGFyZSBhIGdvb2QgcGxhY2UgdG8gc3RhcnQuDQo8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5Ij5odHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2NzQ5PC9hPiBhbmQNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzY3NTAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NTA8L2E+Lg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t QVUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBmaXJzdCB0aGluZyB0byB1bmRl cnN0YW5kIGlzIHRoYXQgT0F1dGgyIHRhcmdldHMgYSB2ZXJ5IHNwZWNpZmljIHVzZSBjYXNlIG9m IGEgdXNlciBhdXRob3JpemluZyBhbiBhcHBsaWNhdGlvbiAobGlrZSBUd2l0dGVyKSBhY2Nlc3Mg dG8gcmVzb3VyY2VzDQogdGhleSBvd24gKGxpa2UgcGhvdG9zKSB0aHJvdWdoIGEgcmVzb3VyY2Ug c2VydmVyIChsaWtlIEZhY2Vib29rKS4gSXTigJlzIG1vcmUgYW4gYXV0aE4vYXV0aFogZnJhbWV3 b3JrIHRoYW4gYSBjb21wbGV0ZSBzeXN0ZW0sIGFuZCBkb2VzbuKAmXQgZGlyZWN0bHkgYWRkcmVz cyB0aGUgdHJhZGl0aW9uYWwgZW50ZXJwcmlzZSB1c2UgY2FzZXMuIE9uY2UgeW91IGdldCB5b3Vy IGhlYWQgYXJvdW5kIHRoYXQsIHRoZSByZXN0IGlzIHByZXR0eSBzdHJhaWdodGZvcndhcmQuDQog QmVjYXVzZSBpdOKAmXMgbGlnaHR3ZWlnaHQgYW5kIHRoaW4sIE9BdXRoMiBjYW4gYmUgdXNlZCBp biBsb3RzIG9mIGF1dGhOL2F1dGhaIHNjZW5hcmlvcywgZm9yIGluc3RhbmNlICZuYnNwO09wZW5J RCBDb25uZWN0DQo8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9jb25uZWN0LyI+aHR0cDovL29w ZW5pZC5uZXQvY29ubmVjdC88L2E+IGFuZCBVTUEgPGEgaHJlZj0iaHR0cDovL2RvY3Mua2FudGFy YWluaXRpYXRpdmUub3JnL3VtYS9kcmFmdC11bWEtY29yZS5odG1sIj4NCmh0dHA6Ly9kb2NzLmth bnRhcmFpbml0aWF0aXZlLm9yZy91bWEvZHJhZnQtdW1hLWNvcmUuaHRtbDwvYT4uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdeKAmWQgYmUgYmVzdCBvZmYgY2xlYXJpbmcg eW91ciBtaW5kIG9mIFNBTUwgY29uY2VwdHMgYW5kIHJlYWRpbmcgdGhlIFJGQ3MsIGJ1dCB0byBh bnN3ZXIgeW91ciBxdWVzdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIGxhbmc9IkVO LUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MS48L3NwYW4+PHNwYW4g bGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ob3QgcmVhbGx5LiBBY2Nlc3MgdG9rZW5z IHJlcHJlc2VudCBhIHVzZXItZ3JhbnRlZCBhdXRob3JpemF0aW9uIGZvciBhIHNwZWNpZmljIGFw cGxpY2F0aW9uIHRvIGFjY2VzcyBhIHNwZWNpZmljIHJlc291cmNlIHNjb3BlLiBUaGUgc2VtYW50 aWNzIG9mIGEgc2NvcGVzIGFyZQ0KIGxlZnQgdG8gdGhlIGRldmVsb3BlciwgYnV0IHlvdSBjYW4g dGhpbmsgb2YgYSBzY29wZSBhcyBhIHJlcHJlc2VudGF0aW9uIG9mIHdoYXQgYWNjZXNzKGVzKSBh cmUgYWxsb3dlZCB0byB3aGF0IHJlc291cmNlKHMpLiBUaGVyZSBpcyBubyB1c2VyIGlkZW50aXR5 IGluZm9ybWF0aW9uIG5lY2Vzc2FyaWx5IGNvbnZleWVkIGluIHRoZSBhY2Nlc3MgdG9rZW7igKYg dGhhdCBpcyB3aGF0IE9wZW5JRCBDb25uZWN0IGlzIGZvci4gT3BlbklEIENvbm5lY3QgbWFwcw0K IHByZXR0eSBjbG9zZWx5IHRvIFNBTUwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIGxhbmc9 IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Mi48L3NwYW4+PHNw YW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQVUiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb3J0IG9mLiBXaGVuIHRoZSByZXNv dXJjZSBvd25lciBncmFudHMgYWNjZXNzLCB0aGUgQVMgaXNzdWVzIGFuIGF1dGhvcml6YXRpb24g Z3JhbnQgY29kZS4gVGhlIGNsaWVudCB0aGVuIHByZXNlbnRzIHRoZSBncmFudCBjb2RlIHRvIHRo ZSBBUyBmb3IgYW4gYWNjZXNzIHRva2VuLg0KIFRoZSBjbGllbnQgaW5jbHVkZXMgdGhlIGFjY2Vz cyB0b2tlbiB3aXRoIGVhY2ggcmVzb3VyY2UgcmVxdWVzdCwgYW5kIHRoZSByZXNvdXJjZSBzZXJ2 ZXIgdXNlcyB0aGUgc2NvcGUgaW4gdGhlIHRva2VuIHRvIGRldGVybWluZSBpZiBhY2Nlc3Mgc2hv dWxkIGJlIGdyYW50ZWQgb3Igbm90LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBsYW5nPSJF Ti1BVSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjMuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHJvbGUgb2YgdGhlIFBEUCBpcyBz cGxpdCBiZXR3ZWVuIHRoZSBBUyBhbmQgdGhlIFJTLiBUaGUgQVMgcHJvdmlkZXMgYSB0b2tlbiBy ZXByZXNlbnRpbmcgdGhlIHVzZXLigJlzIGNvbnNlbnQgdG8gYWNjZXNzIG9mIGEgcGFydGljdWxh ciBzY29wZSwgYW5kIHRoZSBSUyBpbnRlcnByZXRzDQogdGhlIHNjb3BlIHRvIGdyYW50IGFjY2Vz cy4gVGhlIHNjb3BlIF88aT5jb3VsZDwvaT5fIGp1c3QgYmUgYSBCb29sZWFuIHZhbHVlIGluZGlj YXRpbmcgdGhhdCBhY2Nlc3MgaXMgYWxsb3dlZCBvciBub3QsIGluIHdoaWNoIGNhc2UgdGhlIEFT IHdvdWxkIGJlIGEgUERQLCBidXQgaW4gcHJhY3RpY2UgdGhlIHNjb3BlIGVuY29kZXMgYSBzZXQg b2YgcGVybWlzc2lvbnMgdGhhdCB0aGUgUlMgaW50ZXJwcmV0cyBpbiB0aGUgY29udGV4dCBvZiB0 aGUgc3BlY2lmaWMNCiByZXNvdXJjZSByZXF1ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5IVEgsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1naWw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1BVSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGgg WzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJpY2hhcmQgU25vd2Rlbjxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIDIzIEp1bHkgMjAxNCAyOjU3IEFNPGJyPg0KPGI+ VG86PC9iPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIFBsZWFzZSBoZWxwIG1lIHVuZGVyc3Rh bmQgT0F1dGggMi4wPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQVUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUFVIj5JIGFtIHByZXR0eSBmYW1pbGlhciB3aXRo IHRoZSBXUy0qIGFuZCBTT0FQIFdlYiBTZXJ2aWNlcyB3b3JsZC4gQXQgdGhlIG1vbWVudCBJJ20g dHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2hpY2ggZmVhdHVyZXMgYXJlIGF2YWlsYWJsZSBpbiB0aGUg T0F1dGggMi4wIHdvcmxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu Zz0iRU4tQVUiPjEpIFNBTUwgdG9rZW5zOiBUaGlzIGFjY2VzcyB0b2tlbiBpbiBPQXV0aCAyLjAg LSBpcyBpdCBzaW1pbGFyIHRvIHdoYXQgU0FNTCB0b2tlbnMgYXJlIGZvcj88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUFVIj4yKSBTVFM6IElzIGFuIE9BdXRo IDIuMCBBdXRob3JpemF0aW9uIFNlcnZlciB0aGUgZXF1aXZhbGVudCB0byBhIFNUUz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tQVUiPjMpIFBEUCAoUG9saWN5IERlY2lz aW9uIFBvaW50KTogSXMgdGhpcyBhbHNvIGhhbmRsZWQgYnkgdGhlIE9BdXRoIDIuMCBBdXRob3Jp emF0aW9uIFNlcnZlcj8gT3IgZG9lcyB0aGUgUmVzb3VyY2UgU2VydmVyLCBiYXNlZCBvbiB0aGUg YWNjZXNzIHRva2VuLCBoYXZlIHRvIG1ha2UgdGhlIGRlY2lzaW9uIHdoZXRoZXIgb3Igbm90Jm5i c3A7DQogZ3JhbnQgYWNjZXNzIHRvIGEgcmVzb3VyY2U/PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439ADDE0B4TK5EX14MBXC294r_-- From nobody Wed Jul 23 10:39:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB4C1A083D for ; Wed, 23 Jul 2014 10:39:31 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDtSycnjcETp for ; Wed, 23 Jul 2014 10:39:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5A11B29B5 for ; Wed, 23 Jul 2014 10:39:16 -0700 (PDT) Received: from BN3PR0301CA0081.namprd03.prod.outlook.com (25.160.152.177) by BLUPR03MB614.namprd03.prod.outlook.com (10.255.124.42) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 17:39:12 +0000 Received: from BN1BFFO11FD005.protection.gbl (2a01:111:f400:7c10::1:125) by BN3PR0301CA0081.outlook.office365.com (2a01:111:e400:401e::49) with Microsoft SMTP Server (TLS) id 15.0.990.7 via Frontend Transport; Wed, 23 Jul 2014 17:39:12 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD005.mail.protection.outlook.com (10.58.144.68) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 23 Jul 2014 17:39:12 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0195.002; Wed, 23 Jul 2014 17:39:03 +0000 From: Mike Jones To: John Bradley , "torsten@lodderstedt.net" Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpdsD5lLSHJnTREOVCGmqo62AnZutFmeAgABuQQCAACfBgIAABwoAgAAEBVCAACOWAIAABDOAgAAAxwCAAASJAIAAAz+AgAAE4ACAAAEQQA== Date: Wed, 23 Jul 2014 17:39:03 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> In-Reply-To: <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADDE116TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(377454003)(189002)(199002)(51704005)(377424004)(24454002)(19300405004)(6806004)(44976005)(84326002)(107046002)(84676001)(15975445006)(81542001)(77982001)(54356999)(86612001)(551544002)(15395725005)(512874002)(97736001)(86362001)(79102001)(68736004)(55846006)(46102001)(71186001)(21056001)(69596002)(76482001)(83322001)(99396002)(76176999)(50986999)(19580405001)(81342001)(64706001)(20776003)(66066001)(19580395003)(80022001)(31966008)(16236675004)(19617315012)(87936001)(104016003)(15974865002)(2656002)(16297215004)(83072002)(85852003)(26826002)(92726001)(15202345003)(74662001)(92566001)(33656002)(4396001)(19625215002)(93886003)(74502001)(95666004)(77096002)(106116001)(561944003)(85306003)(106466001)(81156004)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB614; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 028166BF91 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/bgdZU2pr1bg4TgWvI15r5UmJZR8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 17:39:31 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADDE116TK5EX14MBXC294r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IG5lZWQgdGhlIGFsdGVybmF0aXZlIHJlc3BvbnNlX3R5cGUgdmFsdWUgKOKAnGNvZGVfZm9y X2lkX3Rva2Vu4oCdIGluIHRoZSBBNEMgZHJhZnQpIHRvIHRlbGwgdGhlIEF1dGhvcml6YXRpb24g U2VydmVyIHRvIHJldHVybiBhIGNvZGUgdG8gYmUgdXNlZCB3aXRoIHRoZSBuZXcgZ3JhbnQgdHlw ZSwgcmF0aGVyIHRoYW4gb25lIHRvIHVzZSB3aXRoIHRoZSDigJxhdXRob3JpemF0aW9uX2NvZGXi gJ0gZ3JhbnQgdHlwZSAod2hpY2ggaXMgd2hhdCByZXNwb25zZV90eXBlPWNvZGUgZG9lcykuDQoN CkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEpvaG4gQnJhZGxleQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDEwOjMzIEFNDQpU bzogdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQNCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtPQVVUSC1XR10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LW9h dXRoLXYyLXVzZXItYTRjLTA1LnR4dA0KDQpJZiB3ZSB1c2UgdGhlIHRva2VuIGVuZHBvaW50IHRo ZW4gYSBuZXcgZ3JhbnRfdHlwZSBpcyB0aGUgYmVzdCB3YXkuDQoNCkl0IHNvcnQgb2Ygb3Zlcmxv YWRzIGNvZGUsIGJ1dCB0aGF0IGlzIGJldHRlciB0aGFuIG1lc3Npbmcgd2l0aCByZXNwb25zZV90 eXBlIGZvciB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB0byBjaGFuZ2UgdGhlIHJlc3BvbnNl IGZyb20gdGhlIHRva2VuX2VuZHBvaW50LiAgVGhhdCBpcyBpbiBteSBvcGluaW9uIGEgY2hhbXBp b24gYmFkIGlkZWEuDQoNCkluIGRpc2N1c3Npb25zIGRldmVsb3BpbmcgQ29ubmVjdCB3ZSBkZWNp ZGVkIG5vdCB0byBvcGVuIHRoaXMgY2FuIG9mIHdvcm1zIGJlY2F1c2Ugbm8gZ29vZCB3b3VsZCBj b21lIG9mIGl0Lg0KDQpUaGUgdG9rZW5fZW5kcG9pbnQgcmV0dXJucyBhIGFjY2VzcyB0b2tlbi4g IE5vdGhpbmcgcmVxdWlyZXMgc2NvcGUgdG8gYmUgYXNzb2NpYXRlcyB3aXRoIHRoZSB0b2tlbi4N Cg0KVGhhdCBpcyB0aGUgYmVzdCBzb2x1dGlvbi4gIE5vIGNoYW5nZSByZXF1aXJlZC4gIEJldHRl ciBpbnRlcm9wZXJhYmlsaXR5IGluIG15IG9waW5pb24uDQoNClN0aWxsIG9uIG15IHdheSB0byBU TywgZ2V0dGluZyBpbiBsYXRlciB0b2RheS4NCg0KSm9obiBCLg0KDQoNCg0KU2VudCBmcm9tIG15 IGlQaG9uZQ0KDQpPbiBKdWwgMjMsIDIwMTQsIGF0IDEyOjE1IFBNLCB0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KDQpUaGUgInJl c3BvbnNlIHR5cGUiIG9mIHRoZSB0b2tlbiBlbmRwb2ludCBpcyBjb250cm9sbGVkIGJ5IHRoZSB2 YWx1ZSBvZiB0aGUgcGFyYW1ldGVyICJncmFudF90eXBlIi4gU28gdGhlcmUgaXMgbm8gbmVlZCB0 byBpbnRyb2R1Y2UgYSBuZXcgcGFyYW1ldGVyLg0KDQp3cnQgdG8gYSBwb3RlbnRpYWwgIm5vX2Fj Y2Vzc190b2tlbiIgZ3JhbnQgdHlwZS4gSSBkbyBub3QgY29uc2lkZXIgdGhpcyBhIGdvb2QgaWRl YSBhcyBpdCBjaGFuZ2VzIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHRva2VuIGVuZHBvaW50IChhcyBh bHJlYWR5IHBvaW50ZWQgb3V0IGJ5IFRob21hcykuIFRoaXMgZW5kcG9pbnQgQUxXQVlTIHJlc3Bv bmRzIHdpdGggYW4gYWNjZXNzIHRva2VuIHRvIGFueSBncmFudCB0eXBlLiBJIHRoZXJlZm9yZSB3 b3VsZCBwcmVmZXIgdG8gdXNlIGFub3RoZXIgZW5kcG9pbnQgZm9yIHRoZSBpbnRlbmRlZCBwdXJw b3NlLg0KDQpyZWdhcmRzLA0KVG9yc3Rlbi4NCg0KDQoNCkFtIDIzLjA3LjIwMTQgMTM6MDQsIHNj aHJpZWIgTmF0IFNha2ltdXJhOg0KSU1ITywgY2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiAicmVz cG9uc2VfdHlwZSIgQCBhdXRoeiBlbmRwb2ludCB0aGlzIHdheSBpcyBub3QgYSBnb29kIHRoaW5n Lg0KDQpJbnN0ZWFkLCBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXIgInJlc3BvbnNlX3R5cGUiIEAg dG9rZW4gZW5kcG9pbnQsIGFzIEkgZGVzY3JpYmVkIGluIG15IHByZXZpb3VzIG1lc3NhZ2UsDQpw cm9iYWJseSBpcyBiZXR0ZXIuIEF0IGxlYXN0LCBpdCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHNlbWFu dGljcyBvZiB0aGUgcGFyYW1ldGVycyBvZiBSRkM2NzQ5Lg0KDQogTmF0DQoNCjIwMTQtMDctMjMg MTI6NDggR01ULTA0OjAwIFRob21hcyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxtYWlsdG86 dC5icm95ZXJAZ21haWwuY29tPj46DQpObywgSSBtZWFuIHJlc3BvbnNlX3R5cGU9bm9uZSBhbmQg cmVzcG9uc2VfdHlwZT1pZF90b2tlbiBkb24ndCBnZW5lcmF0ZSBhIGNvZGUgb3IgYWNjZXNzIHRv a2VuIHNvIHlvdSBkb24ndCB1c2UgdGhlIFRva2VuIEVuZHBvaW50ICh3aGljaCBpcyBub3QgdGhl IHNhbWUgYXMgdGhlIEF1dGhlbnRpY2F0aW9uIEVuZHBvaW50IEJUVykuDQpXaXRoIHJlc3BvbnNl X3R5cGU9Y29kZV9mb3JfaWRfdG9rZW4sIHlvdSBnZXQgYSBjb2RlIGFuZCBleGNoYW5nZSBpdCBm b3IgYW4gaWRfdG9rZW4gb25seSwgcmF0aGVyIHRoYW4gYW4gYWNjZXNzX3Rva2VuLCBzbyB5b3Un cmUgY2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgVG9rZW4gRW5kcG9pbnQuDQoNCkknbSBu b3Qgc2F5aW5nIGl0J3MgYSBiYWQgdGhpbmcsIGp1c3QgdGhhdCB5b3UgY2FuJ3QgcmVhbGx5IGNv bXBhcmUgbm9uZSBhbmQgaWRfdG9rZW4gd2l0aCBjb2RlX2Zvcl9pZF90b2tlbi4NCg0KT24gV2Vk LCBKdWwgMjMsIDIwMTQgYXQgNjo0NSBQTSwgUmljaGVyLCBKdXN0aW4gUC4gPGpyaWNoZXJAbWl0 cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+IHdyb3RlOg0KSXQncyBvbmx5ICJub3Qg dXNpbmcgdGhlIHRva2VuIGVuZHBvaW50IiBiZWNhdXNlIHRoZSB0b2tlbiBlbmRwb2ludCBjb3B5 LXBhc3RlZCBhbmQgcmVuYW1lZCB0aGUgYXV0aGVudGljYXRpb24gZW5kcG9pbnQuDQoNCiAtLSBK dXN0aW4NCg0KT24gSnVsIDIzLCAyMDE0LCBhdCA5OjMwIEFNLCBUaG9tYXMgQnJveWVyIDx0LmJy b3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCkV4 Y2VwdCB0aGF0IHRoZXNlIGFyZSBhYm91dCBub3QgdXNpbmcgdGhlIFRva2VuIEVuZHBvaW50IGF0 IGFsbCwgd2hlcmVhcyB0aGUgY3VycmVudCBwcm9wb3NhbCBpcyBhYm91dCB0aGUgVG9rZW4gRW5k cG9pbnQgbm90IHJldHVybmluZyBhbiBhY2Nlc3NfdG9rZW4gZmllbGQgaW4gdGhlIEpTT04uDQoN Ck9uIFdlZCwgSnVsIDIzLCAyMDE0IGF0IDQ6MjYgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3Jv dGU6DQpUaGUgcmVzcG9uc2VfdHlwZSAibm9uZSIgaXMgYWxyZWFkeSB1c2VkIGluIHByYWN0aWNl LCB3aGljaCByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi4gIEl0IHdhcyBhY2NlcHRlZCBieSB0aGUg ZGVzaWduYXRlZCBleHBlcnRzIGFuZCByZWdpc3RlcmVkIGluIHRoZSBJQU5BIE9BdXRoIEF1dGhv cml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2UgVHlwZXMgcmVnaXN0cnkgYXQgaHR0cDovL3d3dy5p YW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueG1s I2VuZHBvaW50LiAgVGhlIHJlZ2lzdGVyZWQgImlkX3Rva2VuIiByZXNwb25zZSB0eXBlIGFsc28g cmV0dXJucyBubyBhY2Nlc3MgdG9rZW4uDQoNClNvIEkgdGhpbmsgdGhlIHF1ZXN0aW9uIG9mIHdo ZXRoZXIgcmVzcG9uc2UgdHlwZXMgdGhhdCByZXN1bHQgaW4gbm8gYWNjZXNzIHRva2VuIGJlaW5n IHJldHVybmVkIGFyZSBhY2NlcHRhYmxlIHdpdGhpbiBPQXV0aCAyLjAgaXMgYWxyZWFkeSBzZXR0 bGVkLCBhcyBhIHByYWN0aWNhbCBtYXR0ZXIuICBMb3RzIG9mIE9BdXRoIGltcGxlbWVudGF0aW9u cyBhcmUgYWxyZWFkeSB1c2luZyBzdWNoIHJlc3BvbnNlIHR5cGVzLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN CkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IFdlZG5lc2Rh eSwgSnVseSAyMywgMjAxNCA3OjA5IEFNDQpUbzogTmF0IFNha2ltdXJhDQpDYzogPG9hdXRoQGll dGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMt MDUudHh0DQoNClllcy4gVGhpcyBpcyB3aHkgaXQgaGFzIHRvIGJlIGRpc2N1c3NlZCBpbiB0aGUg SUVURi4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0 dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KT24gSnVsIDIzLCAyMDE0LCBhdCA5OjQzIEFN LCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwu Y29tPj4gd3JvdGU6DQoNClJlYWRpbmcgYmFjayB0aGUgUkZDNjc0OSwgSSBhbSBub3Qgc3VyZSBp ZiB0aGVyZSBpcyBhIGdvb2Qgd2F5IG9mIHN1cHByZXNzaW5nIGFjY2VzcyB0b2tlbiBmcm9tIHRo ZSByZXNwb25zZSBhbmQgc3RpbGwgYmUgT0F1dGguIEl0IHdpbGwgYnJlYWsgd2hvbGUgYnVuY2gg b2YgaW1wbGljaXQgZGVmaW5pdGlvbnMgbGlrZToNCg0KYXV0aG9yaXphdGlvbiBzZXJ2ZXINCiAg ICAgIFRoZSBzZXJ2ZXIgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0ZXIg c3VjY2Vzc2Z1bGx5DQogICAgICBhdXRoZW50aWNhdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIgYW5k IG9idGFpbmluZyBhdXRob3JpemF0aW9uLg0KDQpBZnRlciBhbGwsIE9BdXRoIGlzIGFsbCBhYm91 dCBpc3N1aW5nIGFjY2VzcyB0b2tlbnMuDQoNCkFsc28sIEkgdGFrZSBiYWNrIG15IHN0YXRlbWVu dCBvbiB0aGUgZ3JhbnQgdHlwZSBpbiBteSBwcmV2aW91cyBtYWlsLg0KDQpUaGUgZGVmaW5pdGlv biBvZiBncmFudCBhbmQgZ3JhbnRfdHlwZSBhcmUgcmVzcGVjdGl2ZWx5Og0KDQpncmFudA0KICAg IGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGF1dGhvcml6YXRp b24NCg0KZ3JhbnRfdHlwZQ0KICAgIChzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSkgdHlwZSBvZiBn cmFudCBzZW50IHRvIHRoZSB0b2tlbiBlbmRwb2ludCB0byBvYnRhaW4gdGhlIGFjY2VzcyB0b2tl bg0KDQpUaHVzLCB0aGUgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgaW4gdGhpcyBj YXNlIGlzIHN0aWxsICdjb2RlJy4NCg0KUmVzcG9uc2UgdHlwZSBvbiB0aGUgb3RoZXIgaGFuZCBp cyBub3Qgc28gd2VsbCBkZWZpbmVkIGluIFJGQzY3NDksIGJ1dCBpdCBzZWVtcyBpdCBpcyByZXBy ZXNlbnRpbmcgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVu ZHBvaW50LiBUbyBleHByZXNzIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0b2tlbiBlbmRw b2ludCwgcGVyaGFwcyBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXIgdG8gdGhlIHRva2VuIGVuZHBv aW50LCB3aGljaCBpcyBhIHBhcmFsbGVsIHRvIHRoZSByZXNwb25zZV90eXBlIHRvIHRoZSBBdXRo b3JpemF0aW9uIEVuZHBvaW50IHNlZW1zIHRvIGJlIGEgbW9yZSBzeW1tZXRyaWMgd2F5LCB0aG91 Z2ggSSBhbSBub3Qgc3VyZSBhdCBhbGwgaWYgdGhhdCBpcyBnb2luZyB0byBiZSBPQXV0aCBhbnkg bW9yZS4gT25lIHN0cmF3LW1hbiBpcyB0byBkZWZpbmUgYSBuZXcgcGFyYW1ldGVyIGNhbGxlZCBy ZXNwb25zZV90eXBlIHRvIHRoZSB0b2tlbiBlbmRwb2ludCBzdWNoIGFzOg0KDQpyZXNwb25zZV90 eXBlDQogICAgT1BUSU9OQUwuIEEgc3RyaW5nIHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJlIHJl dHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50Lg0KDQpUaGVuIGRlZmluZSB0aGUgYmVoYXZp b3Igb2YgdGhlIGVuZHBvaW50IGFjY29yZGluZyB0byB0aGUgdmFsdWVzIGFzIHRoZSBwYXJhbGxl bCB0byB0aGUgbXVsdGktcmVzcG9uc2UgdHlwZSBzcGVjLg0KaHR0cDovL29wZW5pZC5uZXQvc3Bl Y3Mvb2F1dGgtdjItbXVsdGlwbGUtcmVzcG9uc2UtdHlwZXMtMV8wLmh0bWwNCg0KTmF0DQoNCg0K DQoNCjIwMTQtMDctMjMgNzoyMSBHTVQtMDQ6MDAgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xl LmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PjoNClRoZSBkcmFmdCBpcyB2ZXJ5IGNs ZWFyLg0KDQpQaGlsDQoNCk9uIEp1bCAyMywgMjAxNCwgYXQgMDo0NiwgTmF0IFNha2ltdXJhIDxz YWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhl IG5ldyBncmFudCB0eXBlIHRoYXQgSSB3YXMgdGFsa2luZyBhYm91dCB3YXMNCiJhdXRob3JpemF0 aW9uX2NvZGVfYnV0X2RvX25vdF9yZXR1cm5fYWNjZXNzX25vcl9yZWZyZXNoX3Rva2VuIiwgc28g dG8gc3BlYWsuDQpJdCBkb2VzIG5vdCByZXR1cm4gYW55dGhpbmcgcGVyIHNlLCBidXQgYW4gZXh0 ZW5zaW9uIGNhbiBkZWZpbmUgc29tZXRoaW5nIG9uIHRvcCBvZiBpdC4NCg0KVGhlbiwgT0lEQyBj YW4gZGVmaW5lIGEgYmluZGluZyB0byBpdCBzbyB0aGF0IHRoZSBiaW5kaW5nIG9ubHkgcmV0dXJu cyBJRCBUb2tlbi4NClRoaXMgYmluZGluZyB3b3JrIHNob3VsZCBiZSBkb25lIGluIE9JREYuIFNo b3VsZCB0aGVyZSBiZSBzdWNoIGEgZ3JhbnQgdHlwZSwNCml0IHdpbGwgYmUgYW4gZXh0cmVtZWx5 IHNob3J0IHNwZWMuDQoNCkF0IHRoZSBzYW1lIHRpbWUsIGlmIGFueSBvdGhlciBzcGVjaWZpY2F0 aW9uIHdhbnRlZCB0byBkZWZpbmUNCm90aGVyIHR5cGUgb2YgdG9rZW5zIGFuZCBoYXZlIGl0IHJl dHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LA0KaXQgY2FuIGFsc28gdXNlIHRoaXMgZ3Jh bnQgdHlwZS4NCg0KSWYgd2hhdCB5b3Ugd2FudCBpcyB0byBkZWZpbmUgYSBuZXcgZ3JhbnQgdHlw ZSB0aGF0IHJldHVybnMgSUQgVG9rZW4gb25seSwNCnRoZW4sIEkgYW0gd2l0aCBKdXN0aW4uIFNp bmNlICJvdGhlciByZXNwb25zZSB0aGFuIElEIFRva2VuIiBpcyBvbmx5DQp0aGVvcmV0aWNhbCwg dGhpcyBpcyBhIG1vcmUgcGxhdXNpYmxlIHdheSBmb3J3YXJkLCBJIHN1cHBvc2UuDQoNCk5hdA0K DQoyMDE0LTA3LTIyIDE0OjMwIEdNVC0wNDowMCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5l ZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+Og0KU28gdGhlIGRyYWZ0IHdvdWxkIGxpdGVyYWxs eSB0dXJuIGludG86DQoNCiJUaGUgYTRjIHJlc3BvbnNlIHR5cGUgYW5kIGdyYW50IHR5cGUgcmV0 dXJuIGFuIGlkX3Rva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IHdpdGggbm8gYWNjZXNzIHRv a2VuLiBBbGwgcGFyYW1ldGVycyBhbmQgdmFsdWVzIGFyZSBkZWZpbmVkIGluIE9JREMuIg0KDQpT ZWVtcyBsaWtlIHRoZSBwZXJmZWN0IG1pbmkgZXh0ZW5zaW9uIGRyYWZ0IGZvciBPSURGIHRvIGRv Lg0KDQotLUp1c3Rpbg0KDQovc2VudCBmcm9tIG15IHBob25lLw0KDQpPbiBKdWwgMjIsIDIwMTQg MTA6MjkgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVy YUBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4gV2hhdCBhYm91dCBqdXN0IGRlZmluaW5nIGEgbmV3 IGdyYW50IHR5cGUgaW4gdGhpcyBXRz8NCj4NCj4NCj4gMjAxNC0wNy0yMiAxMjo1NiBHTVQtMDQ6 MDAgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20+PjoNCj4+DQo+PiBUaGF0IHdvdWxkIGJlIG5pY2UuIEhvd2V2ZXIgb2lkYyBzdGlsbCBu ZWVkcyB0aGUgbmV3IGdyYW50IHR5cGUgaW4gb3JkZXIgdG8gaW1wbGVtZW50IHRoZSBzYW1lIGZs b3cuDQo+Pg0KPj4gUGhpbA0KPj4NCj4+IE9uIEp1bCAyMiwgMjAxNCwgYXQgMTE6MzUsIE5hdCBT YWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3 cm90ZToNCj4+DQo+Pj4gKzEgdG8gSnVzdGluLg0KPj4+DQo+Pj4NCj4+PiAyMDE0LTA3LTIyIDk6 NTQgR01ULTA0OjAwIFJpY2hlciwgSnVzdGluIFAuIDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86 anJpY2hlckBtaXRyZS5vcmc+PjoNCj4+Pj4NCj4+Pj4gRXJyb3JzIGxpa2UgdGhlc2UgbWFrZSBp dCBjbGVhciB0byBtZSB0aGF0IGl0IHdvdWxkIG1ha2UgbXVjaCBtb3JlIHNlbnNlIHRvIGRldmVs b3AgdGhpcyBkb2N1bWVudCBpbiB0aGUgT3BlbklEIEZvdW5kYXRpb24uIEl0IHNob3VsZCBiZSBz b21ldGhpbmcgdGhhdCBkaXJlY3RseSByZWZlcmVuY2VzIE9wZW5JRCBDb25uZWN0IENvcmUgZm9y IGFsbCBvZiB0aGVzZSB0ZXJtcyBpbnN0ZWFkIG9mIHJlZGVmaW5pbmcgdGhlbS4gSXQncyBkb2lu ZyBhdXRoZW50aWNhdGlvbiwgd2hpY2ggaXMgZnVuZGFtZW50YWxseSB3aGF0IE9wZW5JRCBDb25u ZWN0IGRvZXMgb24gdG9wIG9mIE9BdXRoLCBhbmQgSSBkb24ndCBzZWUgYSBnb29kIGFyZ3VtZW50 IGZvciBkb2luZyB0aGlzIHdvcmsgaW4gdGhpcyB3b3JraW5nIGdyb3VwLg0KPj4+Pg0KPj4+PiAg LS0gSnVzdGluDQo+Pj4+DQo+Pj4+IE9uIEp1bCAyMiwgMjAxNCwgYXQgNDozMCBBTSwgVGhvbWFz IEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPG1haWx0bzp0LmJyb3llckBnbWFpbC5jb20+PiB3 cm90ZToNCj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE9uIE1vbiwgSnVsIDIxLCAy MDE0IGF0IDExOjUyIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+ Pj4gVGhhbmtzIGZvciB5b3VyIHJldmlldywgVGhvbWFzLiAgVGhlICJwcm9tcHQ9Y29uc2VudCIg ZGVmaW5pdGlvbiBiZWluZyBtaXNzaW5nIGlzIGFuIGVkaXRvcmlhbCBlcnJvci4gIEl0IHNob3Vs ZCBiZToNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBjb25zZW50DQo+Pj4+Pj4NCj4+ Pj4+PiBUaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgU0hPVUxEIHByb21wdCB0aGUgRW5kLVVzZXIg Zm9yIGNvbnNlbnQgYmVmb3JlIHJldHVybmluZyBpbmZvcm1hdGlvbiB0byB0aGUgQ2xpZW50LiBJ ZiBpdCBjYW5ub3Qgb2J0YWluIGNvbnNlbnQsIGl0IE1VU1QgcmV0dXJuIGFuIGVycm9yLCB0eXBp Y2FsbHkgY29uc2VudF9yZXF1aXJlZC4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBJ J2xsIHBsYW4gdG8gYWRkIGl0IGluIHRoZSBuZXh0IGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ PiBJdCBsb29rcyBsaWtlIHRoZSBjb25zZW50X3JlcXVpcmVkIGVycm9yIG5lZWRzIHRvIGJlIGRl ZmluZWQgdG9vLCBhbmQgeW91IG1pZ2h0IGhhdmUgZm9yZ290dGVuIHRvIGFsc28gaW1wb3J0IGFj Y291bnRfc2VsZWN0aW9uX3JlcXVpcmVkIGZyb20gT3BlbklEIENvbm5lY3QuDQo+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEkgYWdyZWUgdGhhdCB0aGVyZSdzIG5vIGRpZmZl cmVuY2UgYmV0d2VlbiBhIHJlc3BvbnNlIHdpdGggbXVsdGlwbGUgImFtciIgdmFsdWVzIHRoYXQg aW5jbHVkZXMgIm1mYSIgYW5kIG9uZSB0aGF0IGRvZXNuJ3QuICBVbmxlc3MgYSBjbGVhciB1c2Ug Y2FzZSBmb3Igd2h5ICJtZmEiIGlzIG5lZWRlZCBjYW4gYmUgaWRlbnRpZmllZCwgd2UgY2FuIGRl bGV0ZSBpdCBpbiB0aGUgbmV4dCBkcmFmdC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzLg0K Pj4+Pj4NCj4+Pj4+IEhvdyBhYm91dCAicHdkIiB0aGVuPyBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhh dCBJIHNob3VsZCByZXR1cm4gInB3ZCIgaWYgdGhlIHVzZXIgYXV0aGVudGljYXRlZCB1c2luZyBh IHBhc3N3b3JkLCBidXQgd2hhdCAidGhlIHNlcnZpY2UgaWYgYSBjbGllbnQgc2VjcmV0IGlzIHVz ZWQiIG1lYW5zIGluIHRoZSBkZWZpbml0aW9uIGZvciB0aGUgInB3ZCIgdmFsdWU/DQo+Pj4+Pg0K Pj4+Pj4gKE5vdGE6IEkga25vdyB5b3UncmUgYXQgSUVURi05MCwgSSdtIHJlYWR5IHRvIHdhaXQg J3RpbCB5b3UgY29tZSBiYWNrIDstKSApDQo+Pj4+Pg0KPj4+Pj4gLS0NCj4+Pj4+IFRob21hcyBC cm95ZXINCj4+Pj4+IC90yZQubWEuYsqBd2EuamUvPGh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2Et eHhiLmplLz4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4+IE9BdXRoQGlldGYub3JnPG1h aWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ Pj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+Pg0KPj4+DQo+Pj4NCj4+Pg0K Pj4+IC0tDQo+Pj4gTmF0IFNha2ltdXJhICg9bmF0KQ0KPj4+IENoYWlybWFuLCBPcGVuSUQgRm91 bmRhdGlvbg0KPj4+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPj4+IEBfbmF0X2VuDQo+Pj4N Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ DQo+DQo+DQo+DQo+IC0tDQo+IE5hdCBTYWtpbXVyYSAoPW5hdCkNCj4gQ2hhaXJtYW4sIE9wZW5J RCBGb3VuZGF0aW9uDQo+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPiBAX25hdF9lbg0KDQoN Cg0KLS0NCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0K aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQpAX25hdF9lbg0KDQoNCg0KLS0NCk5hdCBTYWtpbXVy YSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVy YS5vcmcvDQpAX25hdF9lbg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg0KDQoNCi0tDQpUaG9tYXMgQnJveWVyDQovdMmULm1hLmLKgXdhLmplLzxodHRwOi8veG4t LW5uYS5tYS54bi0tYndhLXh4Yi5qZS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQoNCg0KDQotLQ0KVGhvbWFzIEJyb3llcg0KL3TJlC5tYS5iyoF3YS5qZS88aHR0cDov L3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9w ZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGgg bWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_4E1F6AAD24975D4BA5B16804296739439ADDE116TK5EX14MBXC294r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPllvdSBuZWVkIHRoZSBhbHRlcm5hdGl2ZSByZXNwb25zZV90eXBlIHZhbHVlICji gJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4iPmNvZGVfZm9yX2lkX3Rva2VuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0NCiBpbiB0aGUgQTRDIGRyYWZ0 KSB0byB0ZWxsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciB0byByZXR1cm4gYSBjb2RlIHRvIGJl IHVzZWQgd2l0aCB0aGUgbmV3IGdyYW50IHR5cGUsIHJhdGhlciB0aGFuIG9uZSB0byB1c2Ugd2l0 aCB0aGUg4oCcYXV0aG9yaXphdGlvbl9jb2Rl4oCdIGdyYW50IHR5cGUgKHdoaWNoIGlzIHdoYXQg cmVzcG9uc2VfdHlwZT1jb2RlIGRvZXMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9obiBCcmFk bGV5PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAyMywgMjAxNCAxMDozMyBBTTxi cj4NCjxiPlRvOjwvYj4gdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8YnI+DQo8Yj5DYzo8L2I+IG9h dXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYg d2UgdXNlIHRoZSB0b2tlbiBlbmRwb2ludCB0aGVuIGEgbmV3IGdyYW50X3R5cGUgaXMgdGhlIGJl c3Qgd2F5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JdCBzb3J0IG9mIG92ZXJsb2FkcyBjb2RlLCBidXQgdGhhdCBpcyBiZXR0ZXIg dGhhbiBtZXNzaW5nIHdpdGggcmVzcG9uc2VfdHlwZSBmb3IgdGhlIGF1dGhvcml6YXRpb24gZW5k cG9pbnQgdG8gY2hhbmdlIHRoZSByZXNwb25zZSBmcm9tIHRoZSB0b2tlbl9lbmRwb2ludC4gJm5i c3A7VGhhdCBpcyBpbiBteSBvcGluaW9uIGEgY2hhbXBpb24gYmFkIGlkZWEuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGRpc2N1 c3Npb25zIGRldmVsb3BpbmcgQ29ubmVjdCB3ZSBkZWNpZGVkIG5vdCB0byBvcGVuIHRoaXMgY2Fu IG9mIHdvcm1zIGJlY2F1c2Ugbm8gZ29vZCB3b3VsZCBjb21lIG9mIGl0LiAmbmJzcDsmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IHRva2VuX2VuZHBvaW50IHJldHVybnMgYSBhY2Nlc3MgdG9rZW4uICZuYnNwO05vdGhpbmcgcmVx dWlyZXMgc2NvcGUgdG8gYmUgYXNzb2NpYXRlcyB3aXRoIHRoZSB0b2tlbi4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBpcyB0 aGUgYmVzdCBzb2x1dGlvbi4gJm5ic3A7Tm8gY2hhbmdlIHJlcXVpcmVkLiAmbmJzcDtCZXR0ZXIg aW50ZXJvcGVyYWJpbGl0eSBpbiBteSBvcGluaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdGlsbCBvbiBteSB3YXkgdG8gVE8s IGdldHRpbmcgaW4gbGF0ZXIgdG9kYXkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4gQi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KU2VudCBm cm9tIG15IGlQaG9uZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBKdWwgMjMsIDIw MTQsIGF0IDEyOjE1IFBNLCA8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQi PnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHA+VGhlICZxdW90O3Jlc3BvbnNlIHR5cGUmcXVvdDsgb2YgdGhlIHRva2Vu IGVuZHBvaW50IGlzIGNvbnRyb2xsZWQgYnkgdGhlIHZhbHVlIG9mIHRoZSBwYXJhbWV0ZXIgJnF1 b3Q7Z3JhbnRfdHlwZSZxdW90Oy4gU28gdGhlcmUgaXMgbm8gbmVlZCB0byBpbnRyb2R1Y2UgYSBu ZXcgcGFyYW1ldGVyLjxvOnA+PC9vOnA+PC9wPg0KPHA+d3J0IHRvIGEgcG90ZW50aWFsICZxdW90 O25vX2FjY2Vzc190b2tlbiZxdW90OyBncmFudCB0eXBlLiBJIGRvIG5vdCBjb25zaWRlciB0aGlz IGEgZ29vZCBpZGVhIGFzIGl0IGNoYW5nZXMgdGhlIHNlbWFudGljcyBvZiB0aGUgdG9rZW4gZW5k cG9pbnQgKGFzIGFscmVhZHkgcG9pbnRlZCBvdXQgYnkgVGhvbWFzKS4gVGhpcyBlbmRwb2ludCBB TFdBWVMgcmVzcG9uZHMgd2l0aCBhbiBhY2Nlc3MgdG9rZW4gdG8gYW55IGdyYW50IHR5cGUuIEkg dGhlcmVmb3JlIHdvdWxkDQogcHJlZmVyIHRvIHVzZSBhbm90aGVyIGVuZHBvaW50IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZS48bzpwPjwvbzpwPjwvcD4NCjxwPnJlZ2FyZHMsPGJyPg0KVG9yc3Rl bi48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+QW0gMjMuMDcu MjAxNCAxMzowNCwgc2NocmllYiBOYXQgU2FraW11cmE6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzEwMTBGRiAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JTUhPLCBjaGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mICZxdW90O3Jlc3BvbnNlX3R5cGUm cXVvdDsgQCBhdXRoeiBlbmRwb2ludCB0aGlzIHdheSBpcyBub3QgYSBnb29kIHRoaW5nLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluc3RlYWQs IGRlZmluaW5nIGEgbmV3IHBhcmFtZXRlciAmcXVvdDtyZXNwb25zZV90eXBlJnF1b3Q7IEAgdG9r ZW4gZW5kcG9pbnQsIGFzIEkgZGVzY3JpYmVkIGluIG15IHByZXZpb3VzIG1lc3NhZ2UsJm5ic3A7 DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wcm9iYWJseSBp cyBiZXR0ZXIuIEF0IGxlYXN0LCBpdCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiB0 aGUgcGFyYW1ldGVycyBvZiBSRkM2NzQ5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtOYXQmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4yMDE0LTA3LTIzIDEyOjQ4IEdNVC0wNDowMCBUaG9tYXMgQnJveWVyICZs dDs8YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21haWwuY29tIj50LmJyb3llckBnbWFpbC5jb208 L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Obywg SSBtZWFuIHJlc3BvbnNlX3R5cGU9bm9uZSBhbmQgcmVzcG9uc2VfdHlwZT1pZF90b2tlbiBkb24n dCBnZW5lcmF0ZSBhIGNvZGUgb3IgYWNjZXNzIHRva2VuIHNvIHlvdSBkb24ndCB1c2UgdGhlIFRv a2VuIEVuZHBvaW50ICh3aGljaCBpcyBub3QgdGhlIHNhbWUgYXMgdGhlIEF1dGhlbnRpY2F0aW9u IEVuZHBvaW50IEJUVykuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XaXRoIHJlc3BvbnNlX3R5cGU9Y29kZV9mb3JfaWRfdG9rZW4sIHlvdSBnZXQgYSBjb2Rl IGFuZCBleGNoYW5nZSBpdCBmb3IgYW4gaWRfdG9rZW4gb25seSwgcmF0aGVyIHRoYW4gYW4gYWNj ZXNzX3Rva2VuLCBzbyB5b3UncmUgY2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgVG9rZW4g RW5kcG9pbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkknbSBub3Qgc2F5aW5nIGl0J3MgYSBiYWQgdGhpbmcsIGp1c3QgdGhhdCB5b3UgY2Fu J3QgcmVhbGx5IGNvbXBhcmUgbm9uZSBhbmQgaWRfdG9rZW4gd2l0aCBjb2RlX2Zvcl9pZF90b2tl bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSnVsIDIz LCAyMDE0IGF0IDY6NDUgUE0sIFJpY2hlciwgSnVzdGluIFAuICZsdDs8YSBocmVmPSJtYWlsdG86 anJpY2hlckBtaXRyZS5vcmciPmpyaWNoZXJAbWl0cmUub3JnPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQncyBvbmx5ICZxdW90O25v dCB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQmcXVvdDsgYmVjYXVzZSB0aGUgdG9rZW4gZW5kcG9p bnQgY29weS1wYXN0ZWQgYW5kIHJlbmFtZWQgdGhlIGF1dGhlbnRpY2F0aW9uIGVuZHBvaW50Lg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDstLSBK dXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKdWwgMjMsIDIwMTQsIGF0IDk6MzAgQU0sIFRob21h cyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iPnQuYnJveWVy QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5FeGNlcHQgdGhhdCB0aGVzZSBhcmUgYWJvdXQgbm90IHVzaW5nIHRoZSBU b2tlbiBFbmRwb2ludCBhdCBhbGwsIHdoZXJlYXMgdGhlIGN1cnJlbnQgcHJvcG9zYWwgaXMgYWJv dXQgdGhlIFRva2VuIEVuZHBvaW50IG5vdCByZXR1cm5pbmcgYW4gYWNjZXNzX3Rva2VuIGZpZWxk IGluIHRoZSBKU09OLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1bCAyMywgMjAxNCBhdCA0 OjI2IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHJlc3BvbnNlX3R5cGUgJnF1 b3Q7bm9uZSZxdW90OyBpcyBhbHJlYWR5IHVzZWQgaW4gcHJhY3RpY2UsIHdoaWNoIHJldHVybnMg bm8gYWNjZXNzIHRva2VuLiZuYnNwOyBJdCB3YXMgYWNjZXB0ZWQNCiBieSB0aGUgZGVzaWduYXRl ZCBleHBlcnRzIGFuZCByZWdpc3RlcmVkIGluIHRoZSBJQU5BIE9BdXRoIEF1dGhvcml6YXRpb24g RW5kcG9pbnQgUmVzcG9uc2UgVHlwZXMgcmVnaXN0cnkgYXQNCjxhIGhyZWY9Imh0dHA6Ly93d3cu aWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnht bCNlbmRwb2ludCI+DQpodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29hdXRoLXBhcmFt ZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54bWwjZW5kcG9pbnQ8L2E+LiZuYnNwOyBUaGUgcmVnaXN0 ZXJlZCAmcXVvdDtpZF90b2tlbiZxdW90OyByZXNwb25zZSB0eXBlIGFsc28gcmV0dXJucyBubyBh Y2Nlc3MgdG9rZW4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28gSSB0aGluayB0aGUgcXVlc3Rpb24gb2Ygd2hl dGhlciByZXNwb25zZSB0eXBlcyB0aGF0IHJlc3VsdCBpbiBubyBhY2Nlc3MgdG9rZW4gYmVpbmcg cmV0dXJuZWQgYXJlDQogYWNjZXB0YWJsZSB3aXRoaW4gT0F1dGggMi4wIGlzIGFscmVhZHkgc2V0 dGxlZCwgYXMgYSBwcmFjdGljYWwgbWF0dGVyLiZuYnNwOyBMb3RzIG9mIE9BdXRoIGltcGxlbWVu dGF0aW9ucyBhcmUgYWxyZWFkeSB1c2luZyBzdWNoIHJlc3BvbnNlIHR5cGVzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBPQXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5v YXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBCZWhhbGYg T2YgPC9zcGFuPjwvc3Ryb25nPlBoaWwgSHVudDxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZW50 Ojwvc3Bhbj48L3N0cm9uZz4gV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDc6MDkgQU08YnI+DQo8 c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+VG86PC9zcGFuPjwvc3Ryb25nPiBOYXQgU2FraW11cmE8YnI+DQo8 c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Q2M6PC9zcGFuPjwvc3Ryb25nPiAmbHQ7PGEgaHJlZj0ibWFpbHRv Om9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHN0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPlN1YmplY3Q6PC9zcGFuPjwvc3Ryb25nPiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+WWVzLiBUaGlzIGlzIHdoeSBpdCBoYXMgdG8gYmUgZGlzY3Vzc2VkIGluIHRoZSBJRVRG LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkBpbmRlcGVuZGVu dGlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3 LmluZGVwZW5kZW50aWQuY29tLyI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEp1bCAyMywgMjAxNCwgYXQgOTo0MyBBTSwg TmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtp bXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlJlYWRpbmcgYmFjayB0aGUgUkZDNjc0OSwgSSBhbSBub3Qgc3VyZSBpZiB0aGVy ZSBpcyBhIGdvb2Qgd2F5IG9mIHN1cHByZXNzaW5nIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSByZXNw b25zZSBhbmQgc3RpbGwgYmUgT0F1dGguIEl0IHdpbGwgYnJlYWsgd2hvbGUgYnVuY2ggb2YgaW1w bGljaXQgZGVmaW5pdGlvbnMNCiBsaWtlOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+YXV0aG9yaXphdGlvbiBzZXJ2ZXI8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyBUaGUgc2VydmVyIGlzc3VpbmcgYWNjZXNzIHRva2VucyB0byB0aGUgY2xpZW50IGFm dGVyIHN1Y2Nlc3NmdWxseTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGF1dGhlbnRpY2F0aW5n IHRoZSByZXNvdXJjZSBvd25lciBhbmQgb2J0YWluaW5nIGF1dGhvcml6YXRpb24uPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWZ0ZXIgYWxsLCBPQXV0 aCBpcyBhbGwgYWJvdXQgaXNzdWluZyBhY2Nlc3MgdG9rZW5zLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWxzbywgSSB0YWtl IGJhY2sgbXkgc3RhdGVtZW50IG9uIHRoZSBncmFudCB0eXBlIGluIG15IHByZXZpb3VzIG1haWwu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGUgZGVmaW5pdGlvbiBvZiBncmFudCBhbmQgZ3JhbnRfdHlwZSBhcmUgcmVzcGVj dGl2ZWx5OiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPmdyYW50Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgY3JlZGVudGlhbCBy ZXByZXNlbnRpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ncmFu dF90eXBlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyAoc3RyaW5nIHJlcHJlc2VudGluZyB0aGUpIHR5cGUgb2Yg Z3JhbnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9r ZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGh1cywgdGhlIGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IGlu IHRoaXMgY2FzZSBpcyBzdGlsbCAnY29kZScuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZXNwb25zZSB0eXBlIG9uIHRoZSBv dGhlciBoYW5kIGlzIG5vdCBzbyB3ZWxsIGRlZmluZWQgaW4gUkZDNjc0OSwgYnV0IGl0IHNlZW1z IGl0IGlzIHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlIGF1dGhv cml6YXRpb24gZW5kcG9pbnQuIFRvIGV4cHJlc3Mgd2hhdCBpcyB0bw0KIGJlIHJldHVybmVkIGZy b20gdG9rZW4gZW5kcG9pbnQsIHBlcmhhcHMgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVyIHRvIHRo ZSB0b2tlbiBlbmRwb2ludCwgd2hpY2ggaXMgYSBwYXJhbGxlbCB0byB0aGUgcmVzcG9uc2VfdHlw ZSB0byB0aGUgQXV0aG9yaXphdGlvbiBFbmRwb2ludCBzZWVtcyB0byBiZSBhIG1vcmUgc3ltbWV0 cmljIHdheSwgdGhvdWdoIEkgYW0gbm90IHN1cmUgYXQgYWxsIGlmIHRoYXQgaXMgZ29pbmcgdG8g YmUgT0F1dGggYW55IG1vcmUuDQogT25lIHN0cmF3LW1hbiBpcyB0byBkZWZpbmUgYSBuZXcgcGFy YW1ldGVyIGNhbGxlZCByZXNwb25zZV90eXBlIHRvIHRoZSB0b2tlbiBlbmRwb2ludCBzdWNoIGFz OiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+cmVzcG9uc2VfdHlwZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IE9QVElPTkFMLiBBIHN0cmluZyByZXBy ZXNlbnRpbmcgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludC4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaGVuIGRlZmluZSB0aGUgYmVoYXZpb3Igb2YgdGhlIGVuZHBv aW50IGFjY29yZGluZyB0byB0aGUgdmFsdWVzIGFzIHRoZSBwYXJhbGxlbCB0byB0aGUgbXVsdGkt cmVzcG9uc2UgdHlwZSBzcGVjLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9v YXV0aC12Mi1tdWx0aXBsZS1yZXNwb25zZS10eXBlcy0xXzAuaHRtbCI+aHR0cDovL29wZW5pZC5u ZXQvc3BlY3Mvb2F1dGgtdjItbXVsdGlwbGUtcmVzcG9uc2UtdHlwZXMtMV8wLmh0bWw8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5O YXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4yMDE0LTA3LTIzIDc6MjEgR01ULTA0OjAwIFBoaWwgSHVu dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3Jh Y2xlLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoZSBkcmFmdCBpcyB2ZXJ5IGNsZWFyLiZuYnNwOzxzcGFuIHN0eWxlPSJj b2xvcjojODg4ODg4Ij48YnI+DQo8YnI+DQpQaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEp1bCAy MywgMjAxNCwgYXQgMDo0NiwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11 cmFAZ21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgbmV3IGdy YW50IHR5cGUgdGhhdCBJIHdhcyB0YWxraW5nIGFib3V0IHdhcyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JnF1b3Q7YXV0aG9yaXphdGlvbl9jb2Rl X2J1dF9kb19ub3RfcmV0dXJuX2FjY2Vzc19ub3JfcmVmcmVzaF90b2tlbiZxdW90Oywgc28gdG8g c3BlYWsuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SXQgZG9lcyBub3QgcmV0dXJuIGFueXRoaW5nIHBlciBzZSwgYnV0IGFuIGV4dGVu c2lvbiBjYW4gZGVmaW5lIHNvbWV0aGluZyBvbiB0b3Agb2YgaXQuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGVuLCBPSURD IGNhbiBkZWZpbmUgYSBiaW5kaW5nIHRvIGl0IHNvIHRoYXQgdGhlIGJpbmRpbmcgb25seSByZXR1 cm5zIElEIFRva2VuLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5UaGlzIGJpbmRpbmcgd29yayBzaG91bGQgYmUgZG9uZSBpbiBPSURG LiBTaG91bGQgdGhlcmUgYmUgc3VjaCBhIGdyYW50IHR5cGUsJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5p dCB3aWxsIGJlIGFuIGV4dHJlbWVseSBzaG9ydCBzcGVjLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXQgdGhlIHNhbWUgdGlt ZSwgaWYgYW55IG90aGVyIHNwZWNpZmljYXRpb24gd2FudGVkIHRvIGRlZmluZSZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5vdGhlciB0 eXBlIG9mIHRva2VucyBhbmQgaGF2ZSBpdCByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2lu dCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+aXQgY2FuIGFsc28gdXNlIHRoaXMgZ3JhbnQgdHlwZS4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHdoYXQgeW91 IHdhbnQgaXMgdG8gZGVmaW5lIGEgbmV3IGdyYW50IHR5cGUgdGhhdCByZXR1cm5zIElEIFRva2Vu IG9ubHksJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPnRoZW4sIEkgYW0gd2l0aCBKdXN0aW4uIFNpbmNlICZxdW90O290aGVyIHJlc3Bv bnNlIHRoYW4gSUQgVG9rZW4mcXVvdDsgaXMgb25seSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50aGVvcmV0aWNhbCwgdGhpcyBpcyBh IG1vcmUgcGxhdXNpYmxlIHdheSBmb3J3YXJkLCBJIHN1cHBvc2UuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5OYXQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIwMTQtMDctMjIg MTQ6MzAgR01ULTA0OjAwIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVy QG1pdC5lZHUiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5TbyB0aGUgZHJhZnQgd291bGQgbGl0ZXJhbGx5IHR1cm4gaW50bzo8 YnI+DQo8YnI+DQomcXVvdDtUaGUgYTRjIHJlc3BvbnNlIHR5cGUgYW5kIGdyYW50IHR5cGUgcmV0 dXJuIGFuIGlkX3Rva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IHdpdGggbm8gYWNjZXNzIHRv a2VuLiBBbGwgcGFyYW1ldGVycyBhbmQgdmFsdWVzIGFyZSBkZWZpbmVkIGluIE9JREMuJnF1b3Q7 PGJyPg0KPGJyPg0KU2VlbXMgbGlrZSB0aGUgcGVyZmVjdCBtaW5pIGV4dGVuc2lvbiBkcmFmdCBm b3IgT0lERiB0byBkby48YnI+DQo8YnI+DQotLUp1c3Rpbjxicj4NCjxicj4NCi9zZW50IGZyb20g bXkgcGhvbmUvPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 YnI+DQpPbiBKdWwgMjIsIDIwMTQgMTA6MjkgQU0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgV2hhdCBhYm91dCBqdXN0IGRlZmluaW5nIGEgbmV3IGdy YW50IHR5cGUgaW4gdGhpcyBXRz88YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgMjAxNC0w Ny0yMiAxMjo1NiBHTVQtMDQ6MDAgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs6PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBUaGF0IHdvdWxkIGJlIG5pY2UuIEhvd2V2ZXIgb2lkYyBzdGlsbCBu ZWVkcyB0aGUgbmV3IGdyYW50IHR5cGUgaW4gb3JkZXIgdG8gaW1wbGVtZW50IHRoZSBzYW1lIGZs b3cuJm5ic3A7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBQaGlsPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyBPbiBKdWwgMjIsIDIwMTQsIGF0IDExOjM1LCBOYXQgU2FraW11cmEgJmx0 OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICYjNDM7MSB0byBK dXN0aW4uJm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7IDIwMTQtMDctMjIgOTo1NCBHTVQtMDQ6MDAgUmljaGVyLCBKdXN0aW4gUC4gJmx0 OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyI+anJpY2hlckBtaXRyZS5vcmc8L2E+ Jmd0Ozo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBFcnJvcnMg bGlrZSB0aGVzZSBtYWtlIGl0IGNsZWFyIHRvIG1lIHRoYXQgaXQgd291bGQgbWFrZSBtdWNoIG1v cmUgc2Vuc2UgdG8gZGV2ZWxvcCB0aGlzIGRvY3VtZW50IGluIHRoZSBPcGVuSUQgRm91bmRhdGlv bi4gSXQgc2hvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGRpcmVjdGx5IHJlZmVyZW5jZXMgT3BlbklE IENvbm5lY3QgQ29yZSBmb3IgYWxsIG9mIHRoZXNlIHRlcm1zIGluc3RlYWQgb2YgcmVkZWZpbmlu ZyB0aGVtLiBJdCdzIGRvaW5nDQogYXV0aGVudGljYXRpb24sIHdoaWNoIGlzIGZ1bmRhbWVudGFs bHkgd2hhdCBPcGVuSUQgQ29ubmVjdCBkb2VzIG9uIHRvcCBvZiBPQXV0aCwgYW5kIEkgZG9uJ3Qg c2VlIGEgZ29vZCBhcmd1bWVudCBmb3IgZG9pbmcgdGhpcyB3b3JrIGluIHRoaXMgd29ya2luZyBn cm91cC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDst LSBKdXN0aW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbiBK dWwgMjIsIDIwMTQsIGF0IDQ6MzAgQU0sIFRob21hcyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0 bzp0LmJyb3llckBnbWFpbC5jb20iPnQuYnJveWVyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBPbiBNb24sIEp1bCAyMSwgMjAxNCBhdCAxMTo1MiBQTSwgTWlrZSBKb25lcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyBmb3IgeW91ciByZXZp ZXcsIFRob21hcy4mbmJzcDsgVGhlICZxdW90O3Byb21wdD1jb25zZW50JnF1b3Q7IGRlZmluaXRp b24gYmVpbmcgbWlzc2luZyBpcyBhbiBlZGl0b3JpYWwgZXJyb3IuJm5ic3A7IEl0IHNob3VsZCBi ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgJm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGNvbnNlbnQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIFNIT1VM RCBwcm9tcHQgdGhlIEVuZC1Vc2VyIGZvciBjb25zZW50IGJlZm9yZSByZXR1cm5pbmcgaW5mb3Jt YXRpb24gdG8gdGhlIENsaWVudC4gSWYgaXQgY2Fubm90IG9idGFpbiBjb25zZW50LCBpdCBNVVNU IHJldHVybiBhbiBlcnJvciwgdHlwaWNhbGx5IGNvbnNlbnRfcmVxdWlyZWQuPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOzxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBJJ2xsIHBsYW4gdG8gYWRkIGl0IGluIHRoZSBuZXh0IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBJdCBsb29rcyBsaWtlIHRoZSBjb25zZW50X3JlcXVpcmVkIGVycm9yIG5lZWRzIHRvIGJl IGRlZmluZWQgdG9vLCBhbmQgeW91IG1pZ2h0IGhhdmUgZm9yZ290dGVuIHRvIGFsc28gaW1wb3J0 IGFjY291bnRfc2VsZWN0aW9uX3JlcXVpcmVkIGZyb20gT3BlbklEIENvbm5lY3QuPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGFncmVlIHRoYXQgdGhlcmUn cyBubyBkaWZmZXJlbmNlIGJldHdlZW4gYSByZXNwb25zZSB3aXRoIG11bHRpcGxlICZxdW90O2Ft ciZxdW90OyB2YWx1ZXMgdGhhdCBpbmNsdWRlcyAmcXVvdDttZmEmcXVvdDsgYW5kIG9uZSB0aGF0 IGRvZXNuJ3QuJm5ic3A7IFVubGVzcyBhIGNsZWFyIHVzZSBjYXNlIGZvciB3aHkgJnF1b3Q7bWZh JnF1b3Q7IGlzIG5lZWRlZCBjYW4gYmUgaWRlbnRpZmllZCwgd2UgY2FuIGRlbGV0ZSBpdCBpbiB0 aGUgbmV4dCBkcmFmdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzLjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSG93IGFib3V0ICZxdW90O3B3 ZCZxdW90OyB0aGVuPyBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhhdCBJIHNob3VsZCByZXR1cm4gJnF1 b3Q7cHdkJnF1b3Q7IGlmIHRoZSB1c2VyIGF1dGhlbnRpY2F0ZWQgdXNpbmcgYSBwYXNzd29yZCwg YnV0IHdoYXQgJnF1b3Q7dGhlIHNlcnZpY2UgaWYgYSBjbGllbnQgc2VjcmV0IGlzIHVzZWQmcXVv dDsgbWVhbnMgaW4gdGhlIGRlZmluaXRpb24gZm9yIHRoZSAmcXVvdDtwd2QmcXVvdDsgdmFsdWU/ PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAoTm90 YTogSSBrbm93IHlvdSdyZSBhdCBJRVRGLTkwLCBJJ20gcmVhZHkgdG8gd2FpdCAndGlsIHlvdSBj b21lIGJhY2sgOy0pICk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IC0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhvbWFzIEJyb3llcjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC90PGEgaHJlZj0iaHR0cDovL3huLS1ubmEubWEueG4tLWJ3 YS14eGIuamUvIj7JlC5tYS5iyoF3YS5qZS88L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IC0tPGJyPg0KJmd0OyZndDsmZ3Q7IE5hdCBTYWtpbXVy YSAoPW5hdCk8YnI+DQomZ3Q7Jmd0OyZndDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJy Pg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyI+aHR0cDov L25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyBAX25hdF9lbjxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyAtLTxicj4NCiZndDsgTmF0IFNha2ltdXJhICg9bmF0KTxicj4NCiZndDsgQ2hh aXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwOi8vbmF0LnNh a2ltdXJhLm9yZy8iPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQomZ3Q7IEBfbmF0 X2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPi0tDQo8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRp b248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iPmh0dHA6Ly9uYXQuc2Fr aW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQp PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGFpcm1hbiwg T3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8i Pmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LS0gPGJyPg0KVGhvbWFzIEJyb3llcjxicj4NCi90PGEgaHJlZj0iaHR0cDovL3huLS1ubmEubWEu eG4tLWJ3YS14eGIuamUvIj7JlC5tYS5iyoF3YS5qZS88L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJob2VuemIiPjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLSA8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5UaG9tYXMgQnJveWVyPC9z cGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi90PGEgaHJlZj0iaHR0cDovL3huLS1ubmEu bWEueG4tLWJ3YS14eGIuamUvIj7JlC5tYS5iyoF3YS5qZS88L2E+DQo8L3NwYW4+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KTmF0IFNha2ltdXJhICg9bmF0KSA8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFpcm1hbiwgT3BlbklE IEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iPmh0dHA6 Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86 cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739439ADDE116TK5EX14MBXC294r_-- From nobody Wed Jul 23 10:45:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1771B2C02 for ; Wed, 23 Jul 2014 10:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, 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 NAJ0jWQwebtV for ; Wed, 23 Jul 2014 10:45:04 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267881B2BEA for ; Wed, 23 Jul 2014 10:44:45 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id w8so1614998qac.2 for ; Wed, 23 Jul 2014 10:44:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=8I4qyUkgrm3tCwc9JdBvJnHzyjd6O/N1fG2Yhx4WtAs=; b=Jl+9Xgte52rExbCvrvvnqq1rnP/+gy6/BHvUdquhlx+q/nAXVdnUz4F8+tqt7uVbio FgFR6150rAvwfV0J5f1T+aDXzJ8Yjh83JB/CZys7GiOg/J7fqCouRpWi+M0s+qGOxBIR cL4Dvc5QVsRuVG5TaM9lej20b7SOlAQavMTrTh3+KfQqcpQqL9lLoO1c7dkH3dF3XeVh Y2lEYKqnJRGR/YwTl3aQW+1i17tjlv0r6yAGsPYNNKXS+O04VGtV012QpBT5J+CnhaCC fV4XU8wM+T0czKyO63IJ745fngDIg4ESYNr6pX5lmHJ1bwM+H9os0xYSIutC6R6c/9C1 Lmxg== X-Gm-Message-State: ALoCoQnDkwulSnE9P9tb9MyfXLzhNuqWpqKoCRNPkWO0fwQ8FYfUvMS6HmFJU+gisWzk5QjG8CCQ X-Received: by 10.224.136.200 with SMTP id s8mr4367932qat.85.1406137485025; Wed, 23 Jul 2014 10:44:45 -0700 (PDT) Received: from ?IPv6:2600:1008:b122:ec03:f47d:7d07:8cdf:ab97? ([2600:1008:b122:ec03:f47d:7d07:8cdf:ab97]) by mx.google.com with ESMTPSA id b80sm4118281qgd.20.2014.07.23.10.44.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 10:44:42 -0700 (PDT) References: <201407230115.s6N1FsJe030731@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD97C@TK5EX14MBXC294.redmond.corp.microsoft.com> <0564c72d4764566535d3963bbaa19e2a@lodderstedt.net> <4E1F6AAD24975D4BA5B16804296739439ADDDB90@TK5EX14MBXC294.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADDDB90@TK5EX14MBXC294.redmond.corp.microsoft.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5A7F21D0-1EBA-4160-B8B0-746EA63DF66A; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <12893A4D-AB36-4D16-B770-69BBFADEA96D@ve7jtb.com> X-Mailer: iPhone Mail (11D257) From: John Bradley Date: Wed, 23 Jul 2014 12:44:40 -0500 To: Mike Jones Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/A1g0SbnSOmF30T5kdW94iOU6B5s Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type 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, 23 Jul 2014 17:45:09 -0000 --Apple-Mail-5A7F21D0-1EBA-4160-B8B0-746EA63DF66A Content-Type: multipart/alternative; boundary=Apple-Mail-62D0685F-046F-4CF1-859C-09357F2C246A Content-Transfer-Encoding: 7bit --Apple-Mail-62D0685F-046F-4CF1-859C-09357F2C246A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If the request to the AS was over https then the response to the UA is over h= ttps. The redirect from the UA wold not be https, that could be intercepted= on the device but not over the Internet. So we probably shouldn't oversta= te that element.=20 In the implicit flow identifying the client is done via a https identifier (= redirect_uri) that MUST be registered for that client as the client cannot b= e confidential.=20 I need to check with some of the OAuth providers, but I think the concern wa= s that non https uri for implicit makes client impersonation too easy.=20 John B.=20 Sent from my iPhone > On Jul 23, 2014, at 10:15 AM, Mike Jones wro= te: >=20 > Web clients using the implicit flow MUST use https or the tokens returned w= ould be communicated in the clear on the open Internet for anyone to snoop. = Not at good idea! > =20 > From: torsten@lodderstedt.net [mailto:torsten@lodderstedt.net]=20 > Sent: Wednesday, July 23, 2014 8:03 AM > To: Mike Jones > Cc: Justin Richer; oauth@ietf.org > Subject: RE: [OAUTH-WG] Dynamic Client Registration: application_type > =20 > Good point. I don't understand why clients using the implicit response typ= e generally shall be obliged to use HTTPS. Getting rid of this requirement w= ould significantly simplify the text. >=20 > regards, > Torsten.=20 >=20 > Am 23.07.2014 10:35, schrieb Mike Jones: >=20 > It's more complicated than that, as native apps may use the implicit flow a= nd not use https. The set of constraints in the "application_type" definiti= on in OpenID Connect Dynamic Registration are: >=20 > =20 >=20 > Web Clients using the OAuth Implicit Grant Type MUST only register URLs us= ing the https scheme as redirect_uris; they MUST NOT use localhost as the ho= stname. Native Clients MUST only register redirect_uris using custom URI sch= emes or URLs using the http: scheme with localhost as the hostname. Authoriz= ation Servers MAY place additional constraints on Native Clients. Authorizat= ion Servers MAY reject Redirection URI values using the http scheme, other t= han the localhost case for Native Clients. >=20 > =20 >=20 > If we're going to add such constraints, I believe they should be the same o= nes as the ones above. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer > Sent: Tuesday, July 22, 2014 6:16 PM > To: torsten@lodderstedt.net > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type >=20 > =20 >=20 > I'm ok with that text, and actually thought we had something along those l= ines already. >=20 > =20 >=20 > --Justin >=20 > =20 >=20 > /sent from my phone/ >=20 > =20 >=20 > On Jul 22, 2014 3:27 PM, torsten@lodderstedt.net wrote: >=20 > >=20 >=20 > > Hi all, >=20 > >=20 >=20 > > I don't think this parameter adds any security (as it is self declarded b= y the caller). I think the constraints on redirect_uris can be specified wit= hout the need for another registration parameter. As far as I understand, th= ey merely depend on the grant type. So we could some text to the redirect_ur= i parameter definition. Something along the following lines: >=20 > >=20 >=20 > > "All redirect URIs registered for a particular client MUST either (1) us= e the HTTPS scheme or (2) the HTTP scheme with localhost as the hostname or c= ustom schemes. Additionally, clients using the implict grant type MUST only r= egister URLs using the https scheme as redirect_uris; they MUST NOT use loca= lhost as the hostname." =20 >=20 > >=20 >=20 > > regards, >=20 > > Torsten. >=20 > >=20 >=20 > > Am 08.07.2014 21:35, schrieb Richer, Justin P.: >=20 > >>=20 >=20 > >> Right, that's how it's used in Connect, which defines only redirect-bas= ed flows. However, the OAuth version needs to be more general purpose.=20 >=20 > >> =20 >=20 > >> It seems like this parameter really does need more discussion in the gr= oup before it should be added to the spec, and therefore I don't think it's a= ppropriate to add it at this stage (post-WGLC). >=20 > >> =20 >=20 > >> -- Justin >=20 > >>=20 >=20 > >> On Jul 8, 2014, at 8:54 PM, Nat Sakimura wrote: >=20 > >>=20 >=20 > >>> If I understand correctly, this parameter is used to appropriately con= strain the schema of the Redirect URIs at the time of the registration and i= s not about fulfilling the Client Type registration requirement in section 2= .1. So, making go or no-go decision based on the discussion around section 2= .1 probably would not be the way to go. The discussion should happen around t= he needs on constraining the schema depending on the kind of client.=20 >=20 > >>> =20 >=20 > >>> Apparently, Connect WG perceived that it is a big enough risk that the= y need to put a plug on based on the risk evaluation as an identity federati= on protocol. OAuth has different risk profile so it could decide otherwise, b= ut my gut feeling is that unless there is a good reason not to have it, we m= ay as well keep it.=20 >=20 > >>> =20 >=20 > >>> Nat >=20 > >>>=20 >=20 > >>>=20 >=20 > >>> 2014-07-09 7:54 GMT+09:00 Richer, Justin P. : >=20 > >>>>=20 >=20 > >>>> This value was introduced in -18, and it's a direct port from OpenID C= onnect. It was never in the OAuth Dynamic Registration spec, and though it h= as been in the OpenID Connect Dynamic Registration spec for a very long time= , I think it was a mistake to add it in for several reasons:=20 >=20 > >>>> =20 >=20 > >>>> First, the semantics around its values and use are not clearly define= d, for the reasons . I don't see any particular harm in keeping it, but I do= n't really see what value it adds for clients or server developers. We are i= n a world where there are OAuth clients that are much more than just "native= " or "web". >=20 > >>>> =20 >=20 > >>>> Second, RFC6749 defines "Client Type" in =C2=A7 2.1 which defines two= values: "confidential" and "public", neither of which maps very cleanly to "= native" or "web" as stated in -18. This is especially true when you've got d= ynamic registration that can make native clients confidential with relative e= ase. We actually take care of registering the "client type" through the use o= f the "token_endpoint_auth_method" parameter, which is what =C2=A7 2.1 is re= ally talking about: secure client authentication (to the token endpoint).=20= >=20 > >>>> =20 >=20 > >>>> With this in mind, my preference and suggestion would be to remove th= is field. If other protocols need it, they can register and define it (like C= onnect has done). >=20 > >>>> =20 >=20 > >>>> -- Justin >=20 > >>>> =20 >=20 > >>>>=20 >=20 > >>>> On Jul 8, 2014, at 4:38 PM, Mike Jones w= rote: >=20 > >>>>=20 >=20 > >>>>> I put it back because otherwise, we wouldn't be meeting one of the r= equirements of the RFC 6749. If you look at the client registration section= http://tools.ietf.org/html/rfc6749#section-2, you'll see that registering r= edirect_uri values is required, as is registering the client type. Without t= his, there wasn't a way to register the client type. >=20 > >>>>>=20 >=20 > >>>>> =20 >=20 > >>>>>=20 >=20 > >>>>> -- Mike >=20 > >>>>>=20 >=20 > >>>>> =20 >=20 > >>>>>=20 >=20 > >>>>> -----Original Message----- >=20 > >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradle= y >=20 > >>>>> Sent: Tuesday, July 08, 2014 12:37 PM >=20 > >>>>> To: Phil Hunt >=20 > >>>>> Cc: oauth@ietf.org >=20 > >>>>> Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_typ= e >=20 > >>>>>=20 >=20 > >>>>> =20 >=20 > >>>>>=20 >=20 > >>>>> It was taken out and then put back in as it is a common parameter us= ed by a number of AS. >=20 > >>>>>=20 >=20 > >>>>> =20 >=20 > >>>>>=20 >=20 > >>>>> We have it in Connect, the best reason for keeping it is to stop peo= ple from coming up with a new parameter for the same thing because they have= n't looked at the Connect version. >=20 > >>>>>=20 >=20 > >>>>> =20 >=20 > >>>>>=20 >=20 > >>>>> John B. >=20 > >>>>>=20 >=20 > >>>>> On Jul 8, 2014, at 3:16 PM, Phil Hunt wrote: >=20 > >>>>>=20 >=20 > >>>>> =20 >=20 > >>>>>=20 >=20 > >>>>> > Does this need to be in the spec? I believe we've already said th= at others can add attributes as they need. >=20 > >>>>>=20 >=20 > >>>>> > >=20 > >>>>>=20 >=20 > >>>>> > Phil >=20 > >>>>>=20 >=20 > >>>>> > >=20 > >>>>>=20 >=20 > >>>>> > @independentid >=20 > >>>>>=20 >=20 > >>>>> > www.independentid.com >=20 > >>>>>=20 >=20 > >>>>> > phil.hunt@oracle.com >=20 > >>>>>=20 >=20 > >>>>> > >=20 > >>>>>=20 >=20 > >>>>> > >=20 > >>>>>=20 >=20 > >>>>> > >=20 > >>>>>=20 >=20 > >>>>> > On Jul 8, 2014, at 11:56 AM, John Bradley wrot= e: >=20 > >>>>>=20 >=20 > >>>>> > >=20 > >>>>>=20 >=20 > >>>>> >> The application_type is collected as part of current registration= by Google and some other OAuth providers as part of registering redirect ur= i. >=20 > >>>>>=20 >=20 > >>>>> >> >=20 > >>>>>=20 >=20 > >>>>> >> The text was cut down to allow more flexibility in OAuth. Connec= t requires registration of redirect_uri and is more ridged about it than OAu= th 2. >=20 > >>>>>=20 >=20 > >>>>> >> >=20 > >>>>>=20 >=20 > >>>>> >> Do you think the Connect wording would be appropriate for OAuth? >=20 > >>>>>=20 >=20 > >>>>> >> >=20 > >>>>>=20 >=20 > >>>>> >> John B. >=20 > >>>>>=20 >=20 > >>>>> >> >=20 > >>>>>=20 >=20 > >>>>> >> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig wrote: >=20 > >>>>>=20 >=20 > >>>>> >> >=20 > >>>>>=20 >=20 > >>>>> >>> This additional information makes a lot of sense. >=20 > >>>>>=20 >=20 > >>>>> >>> >=20 > >>>>>=20 >=20 > >>>>> >>> As you said in an earlier mail, the attempt to copy text from th= e >=20 > >>>>>=20 >=20 > >>>>> >>> OpenID Connect spec failed a bit... >=20 > >>>>>=20 >=20 > >>>>> >>> >=20 > >>>>>=20 >=20 > >>>>> >>> On 07/08/2014 02:49 PM, Nat Sakimura wrote: >=20 > >>>>>=20 >=20 > >>>>> >>>> I suppose authors has imported one of the security feature of >=20 > >>>>>=20 >=20 > >>>>> >>>> OpenID Connect here as well. In the Dynamic Client Registration= >=20 > >>>>>=20 >=20 > >>>>> >>>> standard, which is a bit longer than IETF version. You can see t= he reason from it: >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> application_type >=20 > >>>>>=20 >=20 > >>>>> >>>> OPTIONAL. Kind of the application. The default, if omitted, is= web. >=20 > >>>>>=20 >=20 > >>>>> >>>> The defined values are native or web. Web Clients using the OA= uth=20 >=20 > >>>>>=20 >=20 > >>>>> >>>> Implicit Grant Type MUST only register URLs using the https sch= eme=20 >=20 > >>>>>=20 >=20 > >>>>> >>>> as redirect_uris; they MUST NOT use localhost as the hostname. >=20 > >>>>>=20 >=20 > >>>>> >>>> Native Clients MUST only register redirect_uris using custom U= RI=20 >=20 > >>>>>=20 >=20 > >>>>> >>>> schemes or URLs using the http: scheme with localhost as the=20= >=20 > >>>>>=20 >=20 > >>>>> >>>> hostname. Authorization Servers MAY place additional constraint= s on=20 >=20 > >>>>>=20 >=20 > >>>>> >>>> Native Clients. Authorization Servers MAY reject Redirection UR= I=20 >=20 > >>>>>=20 >=20 > >>>>> >>>> values using the http scheme, other than the localhost case for= =20 >=20 > >>>>>=20 >=20 > >>>>> >>>> Native Clients. The Authorization Server MUST verify that all t= he=20 >=20 > >>>>>=20 >=20 > >>>>> >>>> registered redirect_uris conform to these constraints. This >=20 > >>>>>=20 >=20 > >>>>> >>>> prevents sharing a Client ID across different types of Clients= . >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> Regards, >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> Nat >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig >=20 > >>>>>=20 >=20 > >>>>> >>>> =20 > >>>>>=20 >=20 > >>>>> >>>> >: >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> Hi all, >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> with version -18 you guys have added a new meta-data attribute= , >=20 > >>>>>=20 >=20 > >>>>> >>>> namely application_type. >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> First, this new attribute is not listed in the IANA considerat= ion=20 >=20 > >>>>>=20 >=20 > >>>>> >>>> section. >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> Second, could you provide a bit of motivation why you need it?= >=20 > >>>>>=20 >=20 > >>>>> >>>> What would the authorization server do with that type of >=20 > >>>>>=20 >=20 > >>>>> >>>> information? The description is rather short. >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> IMHO there is also no clear boundary between a "native" and "w= eb" app. >=20 > >>>>>=20 >=20 > >>>>> >>>> Just think about smart phone apps that are developed using Jav= aScript. >=20 > >>>>>=20 >=20 > >>>>> >>>> Would this be a web app or a native app? >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> Here is the definition from the draft: >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> application_type >=20 > >>>>>=20 >=20 > >>>>> >>>> OPTIONAL. Kind of the application. The default, if omi= tted, is >=20 > >>>>>=20 >=20 > >>>>> >>>> "web". The defined values are "native" or "web". >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> Ciao >=20 > >>>>>=20 >=20 > >>>>> >>>> Hannes >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> _______________________________________________ >=20 > >>>>>=20 >=20 > >>>>> >>>> OAuth mailing list >=20 > >>>>>=20 >=20 > >>>>> >>>> OAuth@ietf.org =20 >=20 > >>>>>=20 >=20 > >>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> >=20 > >>>>>=20 >=20 > >>>>> >>>> -- >=20 > >>>>>=20 >=20 > >>>>> >>>> Nat Sakimura (=3Dnat) >=20 > >>>>>=20 >=20 > >>>>> >>>> Chairman, OpenID Foundation >=20 > >>>>>=20 >=20 > >>>>> >>>> http://nat.sakimura.org/ >=20 > >>>>>=20 >=20 > >>>>> >>>> @_nat_en >=20 > >>>>>=20 >=20 > >>>>> >>> >=20 > >>>>>=20 >=20 > >>>>> >>> _______________________________________________ >=20 > >>>>>=20 >=20 > >>>>> >>> OAuth mailing list >=20 > >>>>>=20 >=20 > >>>>> >>> OAuth@ietf.org >=20 > >>>>>=20 >=20 > >>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >=20 > >>>>>=20 >=20 > >>>>> >> >=20 > >>>>>=20 >=20 > >>>>> >> _______________________________________________ >=20 > >>>>>=20 >=20 > >>>>> >> OAuth mailing list >=20 > >>>>>=20 >=20 > >>>>> >> OAuth@ietf.org >=20 > >>>>>=20 >=20 > >>>>> >> https://www.ietf.org/mailman/listinfo/oauth >=20 > >>>>>=20 >=20 > >>>>> > >=20 > >>>>>=20 >=20 > >>>>> =20 >=20 > >>>>>=20 >=20 > >>>>> _______________________________________________ >=20 > >>>>>=20 >=20 > >>>>> OAuth mailing list >=20 > >>>>>=20 >=20 > >>>>> OAuth@ietf.org >=20 > >>>>>=20 >=20 > >>>>> https://www.ietf.org/mailman/listinfo/oauth >=20 > >>>>>=20 >=20 > >>>>> _______________________________________________ >=20 > >>>>> OAuth mailing list >=20 > >>>>> OAuth@ietf.org >=20 > >>>>> https://www.ietf.org/mailman/listinfo/oauth >=20 > >>>>=20 >=20 > >>>>=20 >=20 > >>>> _______________________________________________ >=20 > >>>> OAuth mailing list >=20 > >>>> OAuth@ietf.org >=20 > >>>> https://www.ietf.org/mailman/listinfo/oauth >=20 > >>>>=20 >=20 > >>>=20 >=20 > >>>=20 >=20 > >>> =20 >=20 > >>> -- >=20 > >>> Nat Sakimura (=3Dnat) >=20 > >>> Chairman, OpenID Foundation >=20 > >>> http://nat.sakimura.org/ >=20 > >>> @_nat_en >=20 > >>=20 >=20 > >>=20 >=20 > >> _______________________________________________ >=20 > >>=20 >=20 > >> OAuth mailing list >=20 > >>=20 >=20 > >> OAuth@ietf.org >=20 > >>=20 >=20 > >> https://www.ietf.org/mailman/listinfo/oauth >=20 > >>=20 >=20 > > =20 >=20 > >=20 >=20 > > =20 >=20 > _______________________________________________ >=20 > OAuth mailing list >=20 > OAuth@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-62D0685F-046F-4CF1-859C-09357F2C246A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If the request to the AS was over http= s then the response to the UA is over https.  The redirect from the UA w= old not be https, that could be intercepted on the device but not over the I= nternet.   So we probably shouldn't overstate that element. 
=

In the implicit flow identifying the client is done via a= https identifier ( redirect_uri) that MUST be registered for that client as= the client cannot be confidential. 

I need to= check with some of the OAuth providers, but I think the concern was that no= n https uri for implicit makes client impersonation too easy. 

John B. 

Sent from my iPhone
<= br>On Jul 23, 2014, at 10:15 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

<= blockquote type=3D"cite">

Web clients using the impli= cit flow MUST use https or the tokens returned would be communicated in the c= lear on the open Internet for anyone to snoop.  Not at good idea!

 

 

Good point. I don't understand why clien= ts using the implicit response type generally shall be obliged to use HTTPS.= Getting rid of this requirement would significantly simplify the text.=

regards,
Torsten. 

Am 23.07.2014 10:35, schrieb Mike Jones:=

It's more complic= ated than that, as native apps may use the implicit flow and not use https.&= nbsp; The set of constraints in the "application_type" definition in OpenID C= onnect Dynamic Registration are:

 =

Web Clients using the OAuth Implicit Grant Type MUST only register URLs usi= ng the https scheme as redirect_uris; they MUST NOT use localhost as the hostname. Native Clients MUST only register redirect_uris using custom URI schemes or URLs using the http: scheme with localhost as the hostname. Authorization Servers MAY place additional co= nstraints on Native Clients. Authorization Servers MAY reject Redirection URI values using the http scheme, other than the localhost case for Native Clients.

 =

If we're going to= add such constraints, I believe they should be the same ones as the ones ab= ove.

 =

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

 =

-----Original Mes= sage-----
From: OAuth [mailto:oauth-bounces@= ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, July 22, 2014 6:16 PM
To: torsten@lodderstedt.net Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type

 =

I'm ok with that t= ext, and actually thought we had something along those lines already.

 =

--Justin

 =

/sent from my pho= ne/

 =

On Jul 22, 2014 3= :27 PM, torsten@lodderstedt.ne= t wrote:

> 

> Hi all,=

> 

> I don't thin= k this parameter adds any security (as it is self declarded by the caller). I= think the constraints on redirect_uris can be specified without the need fo= r another registration parameter. As far as I understand, they merely depend on the grant type. So we could some= text to the redirect_uri parameter definition. Something along the followin= g lines:

> 

> "All redirec= t URIs registered for a particular client MUST either (1) use the HTTPS= scheme or (2) the HTTP scheme with localhost as the hostname or custom sche= mes. Additionally, clients using the implict grant type MUST only register URLs using the https scheme as redirect_uris; they M= UST NOT use localhost as the hostname."  

> 

> regards,

> Torsten.

> 

> Am 08.07.201= 4 21:35, schrieb Richer, Justin P.:

>> 

>> Right, t= hat's how it's used in Connect, which defines only redirect-based flows. How= ever, the OAuth version needs to be more general purpose. 

>>  

>> It seems= like this parameter really does need more discussion in the group before it= should be added to the spec, and therefore I don't think it's appropriate t= o add it at this stage (post-WGLC).

>>  

>>  --= Justin

>> 

>> On Jul 8= , 2014, at 8:54 PM, Nat Sakimura <<= span style=3D"color:windowtext;text-decoration:none">sakimura@gmail.com> wrote:

>> 

>>> If I= understand correctly, this parameter is used to appropriately constrain the= schema of the Redirect URIs at the time of the registration and is not abou= t fulfilling the Client Type registration requirement in section 2.1. So, making go or no-go decision based on the di= scussion around section 2.1 probably would not be the way to go. The discuss= ion should happen around the needs on constraining the schema depending on t= he kind of client. 

>>> &nbs= p;

>>> Appa= rently, Connect WG perceived that it is a big enough risk that they need to p= ut a plug on based on the risk evaluation as an identity federation protocol= . OAuth has different risk profile so it could decide otherwise, but my gut feeling is that unless there is a good r= eason not to have it, we may as well keep it. 

>>> &nbs= p;

>>> Nat<= o:p>

>>> = ;

>>> = ;

>>> 2014= -07-09 7:54 GMT+09:00 Richer, Justin P. <jricher@mitre.org= >:

>>>>&= nbsp;

>>>> T= his value was introduced in -18, and it's a direct port from OpenID Connect.= It was never in the OAuth Dynamic Registration spec, and though it has been= in the OpenID Connect Dynamic Registration spec for a very long time, I think it was a mistake to add it in for severa= l reasons: 

>>>> &= nbsp;

>>>> = First, the semantics around its values and use are not clearly defined, for t= he reasons . I don't see any particular harm in keeping it, but I don't real= ly see what value it adds for clients or server developers. We are in a world where there are OAuth clients that are much m= ore than just "native" or "web".

>>>> &= nbsp;

>>>> S= econd, RFC6749 defines "Client Type" in =C2=A7 2.1 which defines two values:= "confidential" and "public", neither of which maps very cleanly to "native"= or "web" as stated in -18. This is especially true when you've got dynamic registration that can make native clients confident= ial with relative ease. We actually take care of registering the "client typ= e" through the use of the "token_endpoint_auth_method" parameter, which is w= hat =C2=A7 2.1 is really talking about: secure client authentication (to the token endpoint). 

>>>> &= nbsp;

>>>> W= ith this in mind, my preference and suggestion would be to remove this field= . If other protocols need it, they can register and define it (like Connect h= as done).

>>>> &= nbsp;

>>>> &= nbsp;-- Justin

>>>> &= nbsp;

>>>>&= nbsp;

>>>> O= n Jul 8, 2014, at 4:38 PM, Mike Jones <Michael.J= ones@microsoft.com> wrote:

>>>>&= nbsp;

>>>>&= gt; I put it back because otherwise, we wouldn't be meeting one of the requi= rements of the RFC 6749.  If you look at the client registration sectio= n http://tools.ietf.org/html/rfc6749#sectio= n-2, you'll see that registering redirect_uri values is required,= as is registering the client type.  Without this, there wasn't a way to register the client type.

>>>>&= gt; 

>>>>&= gt;  

>>>>&= gt; 

>>>>&= gt;             =             &nbs= p;            &n= bsp;            =           -- Mike

>>>>&= gt; 

>>>>&= gt;  

>>>>&= gt; 

>>>>&= gt; -----Original Message-----

>>>>&= gt; From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley

>>>>&= gt; Sent: Tuesday, July 08, 2014 12:37 PM

>>>>&= gt; To: Phil Hunt

>>>>&= gt; Cc: oauth@ietf.org<= /a>

>>>>&= gt; Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type

>>>>&= gt; 

>>>>&= gt;  

>>>>&= gt; 

>>>>&= gt; It was taken out and then put back in as it is a common parameter used b= y a number of AS.

>>>>&= gt; 

>>>>&= gt;  

>>>>&= gt; 

>>>>&= gt; We have it in Connect, the best reason for keeping it is to stop people f= rom coming up with a new parameter for the same thing because they haven't l= ooked at the Connect version.

>>>>&= gt; 

>>>>&= gt;  

>>>>&= gt; 

>>>>&= gt; John B.

>>>>&= gt; 

>>>>&= gt; On Jul 8, 2014, at 3:16 PM, Phil Hunt <phil.hunt@or= acle.com> wrote:

>>>>&= gt; 

>>>>&= gt;  

>>>>&= gt; 

>>>>&= gt; > Does this need to be in the spec?  I believe we've already sai= d that others can add attributes as they need.

>>>>&= gt; 

>>>>&= gt; >

>>>>&= gt; 

>>>>&= gt; > Phil

>>>>&= gt; 

>>>>&= gt; >

>>>>&= gt; 

>>>>&= gt; > @independentid

>>>>&= gt; 

>>>>&= gt; > www.independentid.com<= /span>

>>>>&= gt; 

>>>>&= gt; > phil.hunt@oracle.com

>>>>&= gt; 

>>>>&= gt; >

>>>>&= gt; 

>>>>&= gt; >

>>>>&= gt; 

>>>>&= gt; >

>>>>&= gt; 

>>>>&= gt; > On Jul 8, 2014, at 11:56 AM, John Bradley <ve7jtb= @ve7jtb.com> wrote:

>>>>&= gt; 

>>>>&= gt; >

>>>>&= gt; 

>>>>&= gt; >> The application_type is collected as part of current registrati= on by Google and some other OAuth providers as part of registering redirect u= ri.

>>>>&= gt; 

>>>>&= gt; >>

>>>>&= gt; 

>>>>&= gt; >> The text was cut down to allow more flexibility in OAuth. = Connect requires registration of redirect_uri and is more ridged about it t= han OAuth 2.

>>>>&= gt; 

>>>>&= gt; >>

>>>>&= gt; 

>>>>&= gt; >> Do you think the Connect wording would be appropriate for OAuth= ?

>>>>&= gt; 

>>>>&= gt; >>

>>>>&= gt; 

>>>>&= gt; >> John B.

>>>>&= gt; 

>>>>&= gt; >>

>>>>&= gt; 

>>>>&= gt; >> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:<= /p>

>>>>&= gt; 

>>>>&= gt; >>

>>>>&= gt; 

>>>>&= gt; >>> This additional information makes a lot of sense.

>>>>&= gt; 

>>>>&= gt; >>>

>>>>&= gt; 

>>>>&= gt; >>> As you said in an earlier mail, the attempt to copy text fr= om the

>>>>&= gt; 

>>>>&= gt; >>> OpenID Connect spec failed a bit...

>>>>&= gt; 

>>>>&= gt; >>>

>>>>&= gt; 

>>>>&= gt; >>> On 07/08/2014 02:49 PM, Nat Sakimura wrote:

>>>>&= gt; 

>>>>&= gt; >>>> I suppose authors has imported one of the security feat= ure of

>>>>&= gt; 

>>>>&= gt; >>>> OpenID Connect here as well. In the Dynamic Client Regi= stration

>>>>&= gt; 

>>>>&= gt; >>>> standard, which is a bit longer than IETF version. You c= an see the reason from it:

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>> application_type

>>>>&= gt; 

>>>>&= gt; >>>>  OPTIONAL. Kind of the application. The default, i= f omitted, is web.

>>>>&= gt; 

>>>>&= gt; >>>>  The defined values are native or web. Web Clients= using the OAuth 

>>>>&= gt; 

>>>>&= gt; >>>> Implicit Grant Type MUST only register URLs using the h= ttps scheme 

>>>>&= gt; 

>>>>&= gt; >>>> as redirect_uris; they MUST NOT use localhost as the ho= stname.

>>>>&= gt; 

>>>>&= gt; >>>>  Native Clients MUST only register redirect_uris u= sing custom URI 

>>>>&= gt; 

>>>>&= gt; >>>> schemes or URLs using the http: scheme with localhost a= s the 

>>>>&= gt; 

>>>>&= gt; >>>> hostname. Authorization Servers MAY place additional co= nstraints on 

>>>>&= gt; 

>>>>&= gt; >>>> Native Clients. Authorization Servers MAY reject Redire= ction URI 

>>>>&= gt; 

>>>>&= gt; >>>> values using the http scheme, other than the localhost c= ase for 

>>>>&= gt; 

>>>>&= gt; >>>> Native Clients. The Authorization Server MUST verify th= at all the 

>>>>&= gt; 

>>>>&= gt; >>>> registered redirect_uris conform to these constraints. T= his

>>>>&= gt; 

>>>>&= gt; >>>> prevents  sharing a Client ID across different typ= es of Clients.

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>> Regards,

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>> Nat

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig=

>>>>&= gt; 

>>>>&= gt; >>>> <hannes= .tschofenig@gmx.net

>>>>&= gt; 

>>>>&= gt; >>>> <mailto:hannes.tschofenig@gmx.= net>>:

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>  Hi all,

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>  with version -18 you guys have added a new meta-d= ata attribute,

>>>>&= gt; 

>>>>&= gt; >>>> namely  application_type.

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>  First, this new attribute is not listed in the IA= NA consideration 

>>>>&= gt; 

>>>>&= gt; >>>> section.

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>  Second, could you provide a bit of motivation why= you need it?

>>>>&= gt; 

>>>>&= gt; >>>> What  would the authorization server do with that t= ype of

>>>>&= gt; 

>>>>&= gt; >>>> information? The  description is rather short.

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>  IMHO there is also no clear boundary between a "n= ative" and "web" app.

>>>>&= gt; 

>>>>&= gt; >>>>  Just think about smart phone apps that are develo= ped using JavaScript.

>>>>&= gt; 

>>>>&= gt; >>>>  Would this be a web app or a native app?

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>  Here is the definition from the draft:=

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>  application_type

>>>>&= gt; 

>>>>&= gt; >>>>        OPTIONAL.&nbs= p; Kind of the application.  The default, if omitted, is

>>>>&= gt; 

>>>>&= gt; >>>>        "web".  T= he defined values are "native" or "web".

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>  Ciao

>>>>&= gt; 

>>>>&= gt; >>>>  Hannes

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>  _______________________________________________

>>>>&= gt; 

>>>>&= gt; >>>>  OAuth mailing list

>>>>&= gt; 

>>>>&= gt; >>>>  OAuth@ietf.org<= /a> <mailto:OAuth@ietf.org> 

>>>>&= gt; 

>>>>&= gt; >>>> https://www.ietf.org/m= ailman/listinfo/oauth

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>>

>>>>&= gt; 

>>>>&= gt; >>>> --

>>>>&= gt; 

>>>>&= gt; >>>> Nat Sakimura (=3Dnat)

>>>>&= gt; 

>>>>&= gt; >>>> Chairman, OpenID Foundation

>>>>&= gt; 

>>>>&= gt; >>>> http://nat.sakimura.or= g/

>>>>&= gt; 

>>>>&= gt; >>>> @_nat_en

>>>>&= gt; 

>>>>&= gt; >>>

>>>>&= gt; 

>>>>&= gt; >>> _______________________________________________<= /span>

>>>>&= gt; 

>>>>&= gt; >>> OAuth mailing list

>>>>&= gt; 

>>>>&= gt; >>> OAuth@ietf.org<= /a>

>>>>&= gt; 

>>>>&= gt; >>> https://www.ietf.org/m= ailman/listinfo/oauth

>>>>&= gt; 

>>>>&= gt; >>

>>>>&= gt; 

>>>>&= gt; >> _______________________________________________

>>>>&= gt; 

>>>>&= gt; >> OAuth mailing list

>>>>&= gt; 

>>>>&= gt; >> OAuth@ietf.org<= /a>

>>>>&= gt; 

>>>>&= gt; >> https://www.ietf.org/m= ailman/listinfo/oauth

>>>>&= gt; 

>>>>&= gt; >

>>>>&= gt; 

>>>>&= gt;  

>>>>&= gt; 

>>>>&= gt; _______________________________________________

>>>>&= gt; 

>>>>&= gt; OAuth mailing list

>>>>&= gt; 

>>>>&= gt; OAuth@ietf.org<= /a>

>>>>&= gt; 

>>>>&= gt; https://www.ietf.org/m= ailman/listinfo/oauth

>>>>&= gt; 

>>>>&= gt; _______________________________________________

>>>>&= gt; OAuth mailing list

>>>>&= gt; OAuth@ietf.org<= /a>

>>>>&= gt; https://www.ietf.org/m= ailman/listinfo/oauth

>>>>&= nbsp;

>>>>&= nbsp;

>>>> _= ______________________________________________

>>>> O= Auth mailing list

>>>> <= a href=3D"mailto:OAuth@ietf.org"> OAuth@ietf.org<= /a>

>>>> <= a href=3D"https://www.ietf.org/mailman/listinfo/oauth"> https://www.ietf.org/m= ailman/listinfo/oauth

>>>>&= nbsp;

>>> = ;

>>> = ;

>>> &nbs= p;

>>> -- <= o:p>

>>> Nat S= akimura (=3Dnat)

>>> Chai= rman, OpenID Foundation

>>> http://nat.sakimura.or= g/

>>> @_na= t_en

>> 

>> 

>> ________= _______________________________________

>> 

>> OAuth ma= iling list

>> 

>> OAuth@ietf.org<= /a>

>> 

>> https://www.ietf.org/m= ailman/listinfo/oauth

>> 

>  <= /o:p>

> 

>  <= /o:p>

_________________= ______________________________

OAuth mailing lis= t

OAuth= @ietf.org

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

 

 

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-62D0685F-046F-4CF1-859C-09357F2C246A-- --Apple-Mail-5A7F21D0-1EBA-4160-B8B0-746EA63DF66A Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNzIzMTc0NDQxWjAjBgkqhkiG9w0BCQQxFgQUXquPjIyfMAWbOKlK a2zDtOs2DhkwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEARaBX1woXuJVgo1uR87IkWvAZWytNG9T5J77MzMsETid99bms dWb6uHf0jVusceV9dvWPeGKqeCkJTDq5lB2SCret6Jb8XwzkJPtcAE+AeTF0l5JE+AT7PW3udHcj 8h0qdc/OSFIL5crL4a2XV6dsK6PvxmD+zweUfHZrFcxxtJ3o7GrEEKRmBwGXMdJdE9MofvnsdAfj HXsLE8DV9bD8HFOuBii+YF5Mscvhv0KyJ9w7QMpG7h6EqcYXALUMzRMaxx3HZRGEIQDJFzH38oIt +bcqXlUwoiTMerfNyNV9s+rIpwfklHlsV79oLcL8IwiMJuxmH8hBmrHZ5NY2CMx++wAAAAAAAA== --Apple-Mail-5A7F21D0-1EBA-4160-B8B0-746EA63DF66A-- From nobody Wed Jul 23 11:12:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2981B27A8 for ; Wed, 23 Jul 2014 11:12:35 -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=[AC_DIV_BONANZA=0.001, 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 Kb_pSy7AJ757 for ; Wed, 23 Jul 2014 11:12:25 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57FA61A0196 for ; Wed, 23 Jul 2014 11:12:24 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so1250882lam.28 for ; Wed, 23 Jul 2014 11:12:22 -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=cYM7aoX4SvtBmg1m4Yk4O80A0nsFWDImS8TUiN2kSIo=; b=ejCRMQ39/RCqun3LW7hjknIEpooRrmDupBhEc7rS9XrxKqB4xVpnTvmgIIP7BFdZaB 9eDVn5o6i5q0+zxtDuHo/MR5cg6qXvrygF0jz0rAbh4Ago3v5taRzgLSzFy/sEJT70r2 E1E0Hve4NQCw+uQtYJcJdutryOjVbOWYqllGU9KvhJ21t8Pqvnb3EaA++8LloCCQx2Ru noRThyrt88RX0UOoTSYd2qMuAPW6zk1Rpr0U4bRPz9H1BPj4lx9AZ1vCbPI2r5noENqS BmoIjWXzSlIgjLnVRavkSSe02M+QvmkDH1q6JWaWmHPt2xMBsjCQPqIL/gWRPTfARXDE m/aQ== MIME-Version: 1.0 X-Received: by 10.112.204.36 with SMTP id kv4mr3309763lbc.106.1406139142407; Wed, 23 Jul 2014 11:12:22 -0700 (PDT) Received: by 10.112.135.106 with HTTP; Wed, 23 Jul 2014 11:12:22 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Thu, 24 Jul 2014 03:12:22 +0900 Message-ID: From: Takahiko Kawasaki To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c3cf32168dfd04fee04806 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SgOwifrzSBWLNbT6dvWB_ksdXrc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 18:12:35 -0000 --001a11c3cf32168dfd04fee04806 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, (1) RFC 6749 grant_type=3Dauthorization_code response=3D{"access_token":...} (2) OpenID Connect Core grant_type=3Dauthorization_code response=3D{"access_token":..., "id_token":...} (3) Currently being discussed (3)-1 grant_type=3Dauthorization_code response_type=3Did_token (a new parameter for the token endpoint) response=3D{"id_token":...} (3)-2 grant_type=3Dsomething_new (a new value for the token endpoint) response=3D{"id_token":...} (3)-3 response_type=3Dsomething_new (a new value for the authz endpoint) grant_type=3Dsomething_new However, taking a logical expansion below into account, (4) Not being discussed yet, but logically possible grant_type=3Dpassword response=3D{"id_token":...} it seems "grant_type" should be treated as a parameter to specify just a 'flow'. IMHO, what tokens should be included in the response from the token endpoint should be specified by another different means. For example, "response_type" (a new parameter for the *token* endpoint) as suggested by Nat. Nat> response_type Nat> OPTIONAL. A string that expresses what tokens are to be returned Nat> from the Token Endpoint. Extension specifications may use this Nat> parameter to explicitly expressing the desire to obtain a Nat> particular type of token. If asked, I would add the following: The default value of "response_type" is "token" which means that an access token is requested. However, when the following conditions are satisfied, the default value is "token id_token". Condition-1: grant_type=3Dauthorization_code Condition-2: The authorization code was issued at the authorization endpoint with 'openid' scope. -- Best Regards, Takahiko Kawasaki 2014-07-24 2:39 GMT+09:00 Mike Jones : > You need the alternative response_type value (=E2=80=9Ccode_for_id_token= =E2=80=9D in the > A4C draft) to tell the Authorization Server to return a code to be used > with the new grant type, rather than one to use with the > =E2=80=9Cauthorization_code=E2=80=9D grant type (which is what response_t= ype=3Dcode does). > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Wednesday, July 23, 2014 10:33 AM > *To:* torsten@lodderstedt.net > > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > If we use the token endpoint then a new grant_type is the best way. > > > > It sort of overloads code, but that is better than messing with > response_type for the authorization endpoint to change the response from > the token_endpoint. That is in my opinion a champion bad idea. > > > > In discussions developing Connect we decided not to open this can of worm= s > because no good would come of it. > > > > The token_endpoint returns a access token. Nothing requires scope to be > associates with the token. > > > > That is the best solution. No change required. Better interoperability > in my opinion. > > > > Still on my way to TO, getting in later today. > > > > John B. > > > > > > Sent from my iPhone > > > On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: > > The "response type" of the token endpoint is controlled by the value of > the parameter "grant_type". So there is no need to introduce a new > parameter. > > wrt to a potential "no_access_token" grant type. I do not consider this a > good idea as it changes the semantics of the token endpoint (as already > pointed out by Thomas). This endpoint ALWAYS responds with an access toke= n > to any grant type. I therefore would prefer to use another endpoint for t= he > intended purpose. > > regards, > Torsten. > > > > Am 23.07.2014 13:04, schrieb Nat Sakimura: > > IMHO, changing the semantics of "response_type" @ authz endpoint this > way is not a good thing. > > > > Instead, defining a new parameter "response_type" @ token endpoint, as I > described in my previous message, > > probably is better. At least, it does not change the semantics of the > parameters of RFC6749. > > > > Nat > > > > 2014-07-23 12:48 GMT-04:00 Thomas Broyer : > > No, I mean response_type=3Dnone and response_type=3Did_token don't genera= te a > code or access token so you don't use the Token Endpoint (which is not th= e > same as the Authentication Endpoint BTW). > > With response_type=3Dcode_for_id_token, you get a code and exchange it fo= r > an id_token only, rather than an access_token, so you're changing the > semantics of the Token Endpoint. > > > > I'm not saying it's a bad thing, just that you can't really compare none > and id_token with code_for_id_token. > > > > On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. > wrote: > > It's only "not using the token endpoint" because the token endpoint > copy-pasted and renamed the authentication endpoint. > > > > -- Justin > > > > On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: > > > > Except that these are about not using the Token Endpoint at all, whereas > the current proposal is about the Token Endpoint not returning an > access_token field in the JSON. > > > > On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones > wrote: > > The response_type "none" is already used in practice, which returns no > access token. It was accepted by the designated experts and registered i= n > the IANA OAuth Authorization Endpoint Response Types registry at > http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#end= point. > The registered "id_token" response type also returns no access token. > > > > So I think the question of whether response types that result in no acces= s > token being returned are acceptable within OAuth 2.0 is already settled, = as > a practical matter. Lots of OAuth implementations are already using such > response types. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Wednesday, July 23, 2014 7:09 AM > *To:* Nat Sakimura > *Cc:* > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > Yes. This is why it has to be discussed in the IETF. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: > > > > Reading back the RFC6749, I am not sure if there is a good way of > suppressing access token from the response and still be OAuth. It will > break whole bunch of implicit definitions like: > > > > authorization server > The server issuing access tokens to the client after successfully > authenticating the resource owner and obtaining authorization. > > > > After all, OAuth is all about issuing access tokens. > > > > Also, I take back my statement on the grant type in my previous mail. > > > > The definition of grant and grant_type are respectively: > > > > grant > > credential representing the resource owner's authorization > > > > grant_type > > (string representing the) type of grant sent to the token endpoint to > obtain the access token > > > > Thus, the grant sent to the token endpoint in this case is still 'code'. > > > > Response type on the other hand is not so well defined in RFC6749, but it > seems it is representing what is to be returned from the authorization > endpoint. To express what is to be returned from token endpoint, perhaps > defining a new parameter to the token endpoint, which is a parallel to th= e > response_type to the Authorization Endpoint seems to be a more symmetric > way, though I am not sure at all if that is going to be OAuth any more. O= ne > straw-man is to define a new parameter called response_type to the token > endpoint such as: > > > > response_type > > OPTIONAL. A string representing what is to be returned from the token > endpoint. > > > > Then define the behavior of the endpoint according to the values as the > parallel to the multi-response type spec. > > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html > > > > Nat > > > > > > > > > > 2014-07-23 7:21 GMT-04:00 Phil Hunt : > > The draft is very clear. > > Phil > > > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: > > The new grant type that I was talking about was > > "authorization_code_but_do_not_return_access_nor_refresh_token", so to > speak. > > It does not return anything per se, but an extension can define something > on top of it. > > > > Then, OIDC can define a binding to it so that the binding only returns ID > Token. > > This binding work should be done in OIDF. Should there be such a grant > type, > > it will be an extremely short spec. > > > > At the same time, if any other specification wanted to define > > other type of tokens and have it returned from the token endpoint, > > it can also use this grant type. > > > > If what you want is to define a new grant type that returns ID Token only= , > > then, I am with Justin. Since "other response than ID Token" is only > > theoretical, this is a more plausible way forward, I suppose. > > > > Nat > > > > 2014-07-22 14:30 GMT-04:00 Justin Richer : > > So the draft would literally turn into: > > "The a4c response type and grant type return an id_token from the token > endpoint with no access token. All parameters and values are defined in > OIDC." > > Seems like the perfect mini extension draft for OIDF to do. > > --Justin > > /sent from my phone/ > > > On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: > > > > What about just defining a new grant type in this WG? > > > > > > 2014-07-22 12:56 GMT-04:00 Phil Hunt : > >> > >> That would be nice. However oidc still needs the new grant type in > order to implement the same flow. > >> > >> Phil > >> > >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: > >> > >>> +1 to Justin. > >>> > >>> > >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : > >>>> > >>>> Errors like these make it clear to me that it would make much more > sense to develop this document in the OpenID Foundation. It should be > something that directly references OpenID Connect Core for all of these > terms instead of redefining them. It's doing authentication, which is > fundamentally what OpenID Connect does on top of OAuth, and I don't see a > good argument for doing this work in this working group. > >>>> > >>>> -- Justin > >>>> > >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer > wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < > Michael.Jones@microsoft.com> wrote: > >>>>>> > >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" definition > being missing is an editorial error. It should be: > >>>>>> > >>>>>> > >>>>>> > >>>>>> consent > >>>>>> > >>>>>> The Authorization Server SHOULD prompt the End-User for consent > before returning information to the Client. If it cannot obtain consent, = it > MUST return an error, typically consent_required. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I'll plan to add it in the next draft. > >>>>> > >>>>> > >>>>> It looks like the consent_required error needs to be defined too, > and you might have forgotten to also import account_selection_required fr= om > OpenID Connect. > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> I agree that there's no difference between a response with multipl= e > "amr" values that includes "mfa" and one that doesn't. Unless a clear us= e > case for why "mfa" is needed can be identified, we can delete it in the > next draft. > >>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>> How about "pwd" then? I fully understand that I should return "pwd" > if the user authenticated using a password, but what "the service if a > client secret is used" means in the definition for the "pwd" value? > >>>>> > >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come > back ;-) ) > >>>>> > >>>>> -- > >>>>> Thomas Broyer > >>>>> /t=C9=94.ma.b=CA=81wa.je/ > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> > >>> > >>> > >>> -- > >>> Nat Sakimura (=3Dnat) > >>> Chairman, OpenID Foundation > >>> http://nat.sakimura.org/ > >>> @_nat_en > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > _______________________________________________ > > 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 > > --001a11c3cf32168dfd04fee04806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

(1) RFC 6749
=C2=A0 grant_type=3Dauthoriz= ation_code
=C2=A0 response=3D{"access_token":...}

(2) O= penID Connect Core
=C2=A0 grant_type=3Dauthorization_code
=C2=A0 resp= onse=3D{"access_token":..., "id_token":...}

(3) Currently being discussed
=C2=A0 (3)-1
=C2=A0=C2=A0=C2=A0 gra= nt_type=3Dauthorization_code
=C2=A0=C2=A0=C2=A0 response_type=3Did_token= =C2=A0 (a new parameter for the token endpoint)
=C2=A0=C2=A0=C2=A0 respo= nse=3D{"id_token":...}

=C2=A0 (3)-2
=C2=A0=C2=A0=C2=A0 = grant_type=3Dsomething_new=C2=A0 (a new value for the token endpoint)
=C2=A0=C2=A0=C2=A0 response=3D{"id_token":...}

=C2=A0 (3)-= 3
=C2=A0=C2=A0=C2=A0 response_type=3Dsomething_new (a new value for the = authz endpoint)
=C2=A0=C2=A0=C2=A0 grant_type=3Dsomething_new

How= ever, taking a logical expansion below into account,

(4) Not being discussed yet, but logically possible
=C2=A0 grant_typ= e=3Dpassword
=C2=A0 response=3D{"id_token":...}

it seem= s "grant_type" should be treated as a parameter to specify
jus= t a 'flow'. IMHO, what tokens should be included in the response from the token endpoint should be specified by another different means.
= For example, "response_type" (a new parameter for the *token* end= point)
as suggested by Nat.

Nat> response_type
Nat>=C2= =A0=C2=A0 OPTIONAL. A string that expresses what tokens are to be returned<= br> Nat>=C2=A0=C2=A0 from the Token Endpoint. Extension specifications may u= se this
Nat>=C2=A0=C2=A0 parameter to explicitly expressing the desir= e to=C2=A0 obtain a
Nat>=C2=A0=C2=A0 particular type of token.
If asked, I would add the following:

=C2=A0 The default value of "response_type" is "token&qu= ot; which means that
=C2=A0 an access token is requested. However, when = the following conditions
=C2=A0 are satisfied, the default value is &quo= t;token id_token".

=C2=A0=C2=A0=C2=A0 Condition-1:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 grant= _type=3Dauthorization_code

=C2=A0=C2=A0=C2=A0 Condition-2:
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The authorization code was issued at the authoriza= tion endpoint
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with 'openid' scope= .

--
Best Regards,
Takahiko Kawasaki



2014-07-24 2:39 GMT+09:00 Mike Jones &l= t;Michael.= Jones@microsoft.com>:

You need the alternative = response_type value (=E2=80=9Ccode_for_id_token=E2=80=9D in the A4C draft) to tell the Authorization Server to return a code to be = used with the new grant type, rather than one to use with the =E2=80=9Cauth= orization_code=E2=80=9D grant type (which is what response_type=3Dcode does= ).

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: tor= sten@lodderstedt.net


Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oaut= h-v2-user-a4c-05.txt

=C2=A0

If we use the token endpoint then a new grant_type i= s the best way.=C2=A0

=C2=A0

It sort of overloads code, but that is better than m= essing with response_type for the authorization endpoint to change the resp= onse from the token_endpoint. =C2=A0That is in my opinion a champion bad id= ea.=C2=A0

=C2=A0

In discussions developing Connect we decided not to = open this can of worms because no good would come of it. =C2=A0=C2=A0

=C2=A0

The token_endpoint returns a access token. =C2=A0Not= hing requires scope to be associates with the token.=C2=A0

=C2=A0

That is the best solution. =C2=A0No change required.= =C2=A0Better interoperability in my opinion.=C2=A0

=C2=A0

Still on my way to TO, getting in later today.=C2=A0=

=C2=A0

John B.=C2=A0

=C2=A0



Sent from my iPhone


On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the= value of the parameter "grant_type". So there is no need to intr= oduce a new parameter.

wrt to a potential "no_access_token" grant type. I do not cons= ider this a good idea as it changes the semantics of the token endpoint (as= already pointed out by Thomas). This endpoint ALWAYS responds with an acce= ss token to any grant type. I therefore would prefer to use another endpoint for the intended purpose.

regards,
Torsten.

=C2=A0

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type&= quot; @ authz endpoint this way is not a good thing.=C2=A0

=C2=A0

Instead, defining a new parameter "response_typ= e" @ token endpoint, as I described in my previous message,=C2=A0

probably is better. At least, it does not change the= semantics of the parameters of RFC6749.=C2=A0

=C2=A0

=C2=A0Nat=C2=A0

=C2=A0<= /p>

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>= :

No, I mean response_type=3Dnone and response_type=3D= id_token don't generate a code or access token so you don't use the= Token Endpoint (which is not the same as the Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you get a co= de and exchange it for an id_token only, rather than an access_token, so yo= u're changing the semantics of the Token Endpoint.

=C2=A0

I'm not saying it's a bad thing, just that y= ou can't really compare none and id_token with code_for_id_token.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It's only "not using the token endpoint&quo= t; because the token endpoint copy-pasted and renamed the authentication en= dpoint.

=C2=A0

=C2=A0-- Justin

=C2=A0

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com&g= t; wrote:



Except that these are about not using the Token Endp= oint at all, whereas the current proposal is about the Token Endpoint not r= eturning an access_token field in the JSON.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

The response_type "n= one" is already used in practice, which returns no access token.=C2=A0= It was accepted by the designated experts and registered in the IANA OAuth Authorization E= ndpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpo= int.=C2=A0 The registered "id_token" response type also retur= ns no access token.

=C2=A0

So I think the question o= f whether response types that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical matter.=C2= =A0 Lots of OAuth implementations are already using such response types.

=C2=A0

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for dra= ft-hunt-oauth-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

Phil

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

=C2=A0<= /p>

Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client after s= uccessfully
=C2=A0 =C2=A0 =C2=A0 authenticating the resource owner and obtaining author= ization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token<= /p>

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the t= oken endpoint, which is a parallel to the response_type to the Authorizatio= n Endpoint seems to be a more symmetric way, though I am not sure at all if= that is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the tok= en endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0<= u>

=C2=A0

Nat

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0<= /u>

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0=

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat

=C2=A0<= /p>

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of = OAuth, and I don't see a good argument for doing this work in this work= ing group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wro= te:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The "pr= ompt=3Dconsent" definition being missing is an editorial error.=C2=A0 = It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I'll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there's no difference between a r= esponse with multiple "amr" values that includes "mfa" = and one that doesn't.=C2=A0 Unless a clear use case for why "mfa&q= uot; is needed can be identified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0


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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/

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



=C2=A0

--
Thomas Broyer
/t=C9= =94.ma.b=CA=81wa.je/


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

=C2=A0

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


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


--001a11c3cf32168dfd04fee04806-- From nobody Wed Jul 23 11:17:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3601A0313; Wed, 23 Jul 2014 11:17:32 -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 v2XUbghYXVk6; Wed, 23 Jul 2014 11:17:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 501751B29EC; Wed, 23 Jul 2014 11:17:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723181729.10472.26349.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 11:17:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lIeVYVrv8C0QYiSvWbZjkRXqbpg Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-17.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:17:32 -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 : Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants Authors : Brian Campbell Chuck Mortimore Michael B. Jones Yaron Y. Goland Filename : draft-ietf-oauth-assertions-17.txt Pages : 24 Date : 2014-07-23 Abstract: This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-assertions-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-17 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 Wed Jul 23 11:19:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C651B2C14; Wed, 23 Jul 2014 11:19:01 -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 u6zG6mF0rK5x; Wed, 23 Jul 2014 11:19:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E061B2C2E; Wed, 23 Jul 2014 11:18:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723181858.22796.74186.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 11:18:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/byBhVCMOxoTOFposmmXoYcplaNo Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bearer-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:19:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants Authors : Michael B. Jones Brian Campbell Chuck Mortimore Filename : draft-ietf-oauth-jwt-bearer-10.txt Pages : 14 Date : 2014-07-23 Abstract: This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bearer-10 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 Wed Jul 23 11:22:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401101ABD17; Wed, 23 Jul 2014 11:21:55 -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 kzBNBSBuIolt; Wed, 23 Jul 2014 11:21:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C7A1B27A8; Wed, 23 Jul 2014 11:21:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723182144.14914.41524.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 11:21:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/aG13jDQbFmYoiXIIWgCpVHx2oYk Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-21.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:21:55 -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 : SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants Authors : Brian Campbell Chuck Mortimore Michael B. Jones Filename : draft-ietf-oauth-saml2-bearer-21.txt Pages : 21 Date : 2014-07-23 Abstract: This specification defines the use of a SAML 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-saml2-bearer-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 23 11:44:51 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530991B2AFA for ; Wed, 23 Jul 2014 11:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 U_5v2f8dchXQ for ; Wed, 23 Jul 2014 11:44:48 -0700 (PDT) Received: from na6sys009bog027.obsmtp.com (na6sys009bog027.obsmtp.com [74.125.150.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0F11B2AD9 for ; Wed, 23 Jul 2014 11:44:47 -0700 (PDT) Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na6sys009bob027.postini.com ([74.125.148.12]) with SMTP ID DSNKU9ACnj2v8t6jd5BOp71OBHCbZe9WHuJl@postini.com; Wed, 23 Jul 2014 11:44:47 PDT Received: by mail-ie0-f177.google.com with SMTP id at20so1336566iec.36 for ; Wed, 23 Jul 2014 11:44: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:from:date:message-id:subject:to :content-type; bh=b354YTMHFrpxQmhPfPkgpAuPxNLAgqcdCTkBZNmjAlw=; b=nALu410M+abCRRetHCUB5uJ9Po6D96MQ0C6BLNvxeIwZoLq1/L15S8vSp4csuTJhJM JIzvzGttiJtGF9mzFqsX72280W0htWubRvVCcPo+JLt+33C7C+sbXx3F5c9qWnP2Vo/e VO+uKlgupL+n75ib37SUTvQubEeK/B5XFhsRpRHrxFYEUVHu5TFttfBSHvt7Gij23mNN TS0KgZizwUMoua+TlZyGIETmhasrBLRs6Dmh2vUuYqtyAyxrsYYOItl3DFdz1IExljIx 478qV6YqB5UOQ8NcLECIlJEKS9CJtKK9jJhZHJBJrUjO/GE6hJUt2bK+ESU/5lNrnLbt Eriw== X-Gm-Message-State: ALoCoQlHaBG6Svt1Ugx2LJ1qw+76C28QTylQXcA9SYTqQmlj4UsD3Lagn51aFs8LOovqg6i25V4JuKmlMp1wJgvbQ8hoW4t53S7tMceXVja5nhIk6i5/Ul7DZMxEFNz84s9IhpMp7UBf X-Received: by 10.42.154.132 with SMTP id q4mr5614046icw.4.1406141086662; Wed, 23 Jul 2014 11:44:46 -0700 (PDT) X-Received: by 10.42.154.132 with SMTP id q4mr5614036icw.4.1406141086586; Wed, 23 Jul 2014 11:44:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Wed, 23 Jul 2014 11:44:15 -0700 (PDT) From: Brian Campbell Date: Wed, 23 Jul 2014 11:44:15 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=90e6ba6e87a6f871bb04fee0bb93 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/F0gJRBDFBtXYxbklhy5ei806QzU Subject: [OAUTH-WG] New Assertion Drafts Published 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, 23 Jul 2014 18:44:50 -0000 --90e6ba6e87a6f871bb04fee0bb93 Content-Type: text/plain; charset=UTF-8 New versions of all three OAuth related assertion documents (listed below) have been published with Privacy Considerations added to each. The request for Privacy Considerations came out of AD review and, with this update, all known issues/comments have now been addressed. Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ --90e6ba6e87a6f871bb04fee0bb93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
3D""New versions of all three OAuth related assertion documents (listed below) have been publi= shed with Privacy Considerations added to each. The request for Priv= acy Considerations came out of AD review and, with this update, all known i= ssues/comments have now been addressed.

Assertion Framework for OAuth 2.0 Client Authentication and Authorizati= on Grants
https://datatracker.ietf.org/doc/draft-ietf-o= auth-assertions/

JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Au= thorization Grants
https://datatracker.ietf.org/doc/dra= ft-ietf-oauth-jwt-bearer/

SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization = Grants
https://datatracker.ietf.org/doc/draft-ietf-oaut= h-jwt-bearer/
--90e6ba6e87a6f871bb04fee0bb93-- From nobody Wed Jul 23 11:46:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A7F1A0026 for ; Wed, 23 Jul 2014 11:46:02 -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=[AC_DIV_BONANZA=0.001, 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 x8W5U43C-02k for ; Wed, 23 Jul 2014 11:45:58 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EBC11B2B25 for ; Wed, 23 Jul 2014 11:45:57 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id c11so1224254lbj.5 for ; Wed, 23 Jul 2014 11:45:55 -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=A3uEKSHLbS6e2fH1nnL0NTh1s6B6IhgttZYEgW9FlKY=; b=01QRiOymyPVAxbsbpdN0VkaUqYHMgHHXv/gtEh48JBFyVoo9n93Yfw/HAGDQEb1685 tVNtJMEbY1b7eOF+STVbiOt27ds7Jm/M7EM4wv60poHpDzzKRw4HpyOzqByrimQvWz2j rNUzWFvqpZwtSJ5zQNgaMoAORDQ3lGWwD+Yid2Gh0tLvOLsbllhjYlnb6kEoymiZtUzM FIX+LBc9IbzSwDIcV1gFnSmj+Fpwml7whMKCS834yniC6IvXrd/iVwSYaCrvHOWTGoEL l6sStO+eD90ll8bu8ZLDLvI1NdNaEMRAqikb3HADYT/hIUVNnqmkPB/m7aPkaoHHpgUD LOeg== MIME-Version: 1.0 X-Received: by 10.152.183.236 with SMTP id ep12mr3801261lac.82.1406141155751; Wed, 23 Jul 2014 11:45:55 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Wed, 23 Jul 2014 11:45:55 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Wed, 23 Jul 2014 14:45:55 -0400 Message-ID: From: Nat Sakimura To: Mike Jones Content-Type: multipart/alternative; boundary=001a1134570217bee804fee0c0ea Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ADSDX8uN8A_D-m5PlKkiBISB0v4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 18:46:03 -0000 --001a1134570217bee804fee0c0ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with John that overloading response_type @ authz endpoint is a bad idea. It completely changes the semantics of this parameter. NOTE: what I was proposing was not this parameter, but a new parameter response_type @ token endpoint. I also think overloading grant_type is a bad idea since it changes its semantics. I quote the definition here again: grant credential representing the resource owner's authorization grant_type type of grant sent to the token endpoint to obtain the access token It is not about controlling what is to be returned from the token endpoint, but the hint to the token endpoint describing the type of credential the endpoint has received. It seems the "control of what is being returned from token endpoint" is just a side effect. I am somewhat ambivalent[1] in changing the semantics of token endpoint, but in as much as "text is the king" for a spec., we probably should not change the semantics of it as Torsten points out. If it is ok to change this semantics, I believe defining a new parameter to this endpoint to control the response would be the best way to go. This is what I have described previously. Defining a new endpoint to send code to get ID Token and forbidding the use of it against token endpoint would not change the semantics of any existing parameter or endpoint, which is good. However, I doubt if it is not worth doing. What's the point of avoiding access token scoped to UserInfo endpoint after all? Defining a new endpoint for just avoiding the access token for userinfo endpoint seems way too much the heavy wait way and it breaks interoperabiliy: it defeats the purpose of standardization. I have started feeling that no change is the best way out. Nat [1] If instead of saying "Token endpoint - used by the client to exchange an authorization grant for an access token, typically with client authentication", it were saying "Token endpoint - used by the client to exchange an authorization grant for tokens, typically with client authentication", then it would have been OK. It is an expansion of the capability rather than changing the semantics. 2014-07-23 13:39 GMT-04:00 Mike Jones : > You need the alternative response_type value (=E2=80=9Ccode_for_id_token= =E2=80=9D in the > A4C draft) to tell the Authorization Server to return a code to be used > with the new grant type, rather than one to use with the > =E2=80=9Cauthorization_code=E2=80=9D grant type (which is what response_t= ype=3Dcode does). > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Wednesday, July 23, 2014 10:33 AM > *To:* torsten@lodderstedt.net > > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > If we use the token endpoint then a new grant_type is the best way. > > > > It sort of overloads code, but that is better than messing with > response_type for the authorization endpoint to change the response from > the token_endpoint. That is in my opinion a champion bad idea. > > > > In discussions developing Connect we decided not to open this can of worm= s > because no good would come of it. > > > > The token_endpoint returns a access token. Nothing requires scope to be > associates with the token. > > > > That is the best solution. No change required. Better interoperability > in my opinion. > > > > Still on my way to TO, getting in later today. > > > > John B. > > > > > > Sent from my iPhone > > > On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: > > The "response type" of the token endpoint is controlled by the value of > the parameter "grant_type". So there is no need to introduce a new > parameter. > > wrt to a potential "no_access_token" grant type. I do not consider this a > good idea as it changes the semantics of the token endpoint (as already > pointed out by Thomas). This endpoint ALWAYS responds with an access toke= n > to any grant type. I therefore would prefer to use another endpoint for t= he > intended purpose. > > regards, > Torsten. > > > > Am 23.07.2014 13:04, schrieb Nat Sakimura: > > IMHO, changing the semantics of "response_type" @ authz endpoint this > way is not a good thing. > > > > Instead, defining a new parameter "response_type" @ token endpoint, as I > described in my previous message, > > probably is better. At least, it does not change the semantics of the > parameters of RFC6749. > > > > Nat > > > > 2014-07-23 12:48 GMT-04:00 Thomas Broyer : > > No, I mean response_type=3Dnone and response_type=3Did_token don't genera= te a > code or access token so you don't use the Token Endpoint (which is not th= e > same as the Authentication Endpoint BTW). > > With response_type=3Dcode_for_id_token, you get a code and exchange it fo= r > an id_token only, rather than an access_token, so you're changing the > semantics of the Token Endpoint. > > > > I'm not saying it's a bad thing, just that you can't really compare none > and id_token with code_for_id_token. > > > > On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. > wrote: > > It's only "not using the token endpoint" because the token endpoint > copy-pasted and renamed the authentication endpoint. > > > > -- Justin > > > > On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: > > > > Except that these are about not using the Token Endpoint at all, whereas > the current proposal is about the Token Endpoint not returning an > access_token field in the JSON. > > > > On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones > wrote: > > The response_type "none" is already used in practice, which returns no > access token. It was accepted by the designated experts and registered i= n > the IANA OAuth Authorization Endpoint Response Types registry at > http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#end= point. > The registered "id_token" response type also returns no access token. > > > > So I think the question of whether response types that result in no acces= s > token being returned are acceptable within OAuth 2.0 is already settled, = as > a practical matter. Lots of OAuth implementations are already using such > response types. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Wednesday, July 23, 2014 7:09 AM > *To:* Nat Sakimura > *Cc:* > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > Yes. This is why it has to be discussed in the IETF. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: > > > > Reading back the RFC6749, I am not sure if there is a good way of > suppressing access token from the response and still be OAuth. It will > break whole bunch of implicit definitions like: > > > > authorization server > The server issuing access tokens to the client after successfully > authenticating the resource owner and obtaining authorization. > > > > After all, OAuth is all about issuing access tokens. > > > > Also, I take back my statement on the grant type in my previous mail. > > > > The definition of grant and grant_type are respectively: > > > > grant > > credential representing the resource owner's authorization > > > > grant_type > > (string representing the) type of grant sent to the token endpoint to > obtain the access token > > > > Thus, the grant sent to the token endpoint in this case is still 'code'. > > > > Response type on the other hand is not so well defined in RFC6749, but it > seems it is representing what is to be returned from the authorization > endpoint. To express what is to be returned from token endpoint, perhaps > defining a new parameter to the token endpoint, which is a parallel to th= e > response_type to the Authorization Endpoint seems to be a more symmetric > way, though I am not sure at all if that is going to be OAuth any more. O= ne > straw-man is to define a new parameter called response_type to the token > endpoint such as: > > > > response_type > > OPTIONAL. A string representing what is to be returned from the token > endpoint. > > > > Then define the behavior of the endpoint according to the values as the > parallel to the multi-response type spec. > > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html > > > > Nat > > > > > > > > > > 2014-07-23 7:21 GMT-04:00 Phil Hunt : > > The draft is very clear. > > Phil > > > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: > > The new grant type that I was talking about was > > "authorization_code_but_do_not_return_access_nor_refresh_token", so to > speak. > > It does not return anything per se, but an extension can define something > on top of it. > > > > Then, OIDC can define a binding to it so that the binding only returns ID > Token. > > This binding work should be done in OIDF. Should there be such a grant > type, > > it will be an extremely short spec. > > > > At the same time, if any other specification wanted to define > > other type of tokens and have it returned from the token endpoint, > > it can also use this grant type. > > > > If what you want is to define a new grant type that returns ID Token only= , > > then, I am with Justin. Since "other response than ID Token" is only > > theoretical, this is a more plausible way forward, I suppose. > > > > Nat > > > > 2014-07-22 14:30 GMT-04:00 Justin Richer : > > So the draft would literally turn into: > > "The a4c response type and grant type return an id_token from the token > endpoint with no access token. All parameters and values are defined in > OIDC." > > Seems like the perfect mini extension draft for OIDF to do. > > --Justin > > /sent from my phone/ > > > On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: > > > > What about just defining a new grant type in this WG? > > > > > > 2014-07-22 12:56 GMT-04:00 Phil Hunt : > >> > >> That would be nice. However oidc still needs the new grant type in > order to implement the same flow. > >> > >> Phil > >> > >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: > >> > >>> +1 to Justin. > >>> > >>> > >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : > >>>> > >>>> Errors like these make it clear to me that it would make much more > sense to develop this document in the OpenID Foundation. It should be > something that directly references OpenID Connect Core for all of these > terms instead of redefining them. It's doing authentication, which is > fundamentally what OpenID Connect does on top of OAuth, and I don't see a > good argument for doing this work in this working group. > >>>> > >>>> -- Justin > >>>> > >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer > wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < > Michael.Jones@microsoft.com> wrote: > >>>>>> > >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" definition > being missing is an editorial error. It should be: > >>>>>> > >>>>>> > >>>>>> > >>>>>> consent > >>>>>> > >>>>>> The Authorization Server SHOULD prompt the End-User for consent > before returning information to the Client. If it cannot obtain consent, = it > MUST return an error, typically consent_required. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I'll plan to add it in the next draft. > >>>>> > >>>>> > >>>>> It looks like the consent_required error needs to be defined too, > and you might have forgotten to also import account_selection_required fr= om > OpenID Connect. > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> I agree that there's no difference between a response with multipl= e > "amr" values that includes "mfa" and one that doesn't. Unless a clear us= e > case for why "mfa" is needed can be identified, we can delete it in the > next draft. > >>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>> How about "pwd" then? I fully understand that I should return "pwd" > if the user authenticated using a password, but what "the service if a > client secret is used" means in the definition for the "pwd" value? > >>>>> > >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come > back ;-) ) > >>>>> > >>>>> -- > >>>>> Thomas Broyer > >>>>> /t=C9=94.ma.b=CA=81wa.je/ > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> > >>> > >>> > >>> -- > >>> Nat Sakimura (=3Dnat) > >>> Chairman, OpenID Foundation > >>> http://nat.sakimura.org/ > >>> @_nat_en > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a1134570217bee804fee0c0ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with John that overloading response_type @ au= thz endpoint is a bad idea. It completely changes the semantics of this par= ameter. NOTE: what I was proposing was not this parameter, but a new parame= ter response_type @ token endpoint.=C2=A0

I also think overloading grant_type is a bad idea since= it changes its semantics. I quote the definition here again:=C2=A0

grant=C2=A0
=C2=A0 =C2=A0 credential repre= senting the resource owner's authorization
grant_ty= pe
type of gra= nt sent to the token endpoint to obtain the access token
It is not about controlling what is to be returned from the token endp= oint, but the hint to the token endpoint describing the type of credential = the endpoint has received. It seems the "control of what is being retu= rned from token endpoint" =C2=A0is just a side effect.=C2=A0

I am somewhat ambivalent[1] in changing the semantics o= f token endpoint, but in as much as "text is the king" for a spec= ., we probably should not change the semantics of it as Torsten points out.= If it is ok to change this semantics, I believe defining a new parameter t= o this endpoint to control the response would be the best way to go. This i= s what I have described previously.=C2=A0

Defining a new endpoint to send code to get ID Token an= d forbidding the use of it against token endpoint would not change the sema= ntics of any existing parameter or endpoint, which is good. However, I doub= t if it is not worth doing. What's the point of avoiding access token s= coped to UserInfo endpoint after all? Defining a new endpoint for just avoi= ding the access token for userinfo endpoint seems way too much the heavy wa= it way and it breaks interoperabiliy: it defeats the purpose of standardiza= tion.=C2=A0

I have started feeling that no change is the best way o= ut.=C2=A0

Nat
=C2=A0
[1] = =C2=A0If instead of saying "Token endpoint - used by the client to exchange an authorization=C2=A0= grant for an access token, typically with client authentication"= ;, it were saying "Toke= n endpoint - used by the client to exchange an authorization=C2=A0gr= ant for tokens, typically with client authentication", then it would h= ave been OK. It is an expansion of the capability rather than changing the = semantics.



2014-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@mic= rosoft.com>:

You need the alternative = response_type value (=E2=80=9Ccode_for_id_token=E2=80=9D in the A4C draft) to tell the Authorization Server to return a code to be = used with the new grant type, rather than one to use with the =E2=80=9Cauth= orization_code=E2=80=9D grant type (which is what response_type=3Dcode does= ).

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: tor= sten@lodderstedt.net


Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oaut= h-v2-user-a4c-05.txt

=C2=A0

If we use the token endpoint then a new grant_type i= s the best way.=C2=A0

=C2=A0

It sort of overloads code, but that is better than m= essing with response_type for the authorization endpoint to change the resp= onse from the token_endpoint. =C2=A0That is in my opinion a champion bad id= ea.=C2=A0

=C2=A0

In discussions developing Connect we decided not to = open this can of worms because no good would come of it. =C2=A0=C2=A0

=C2=A0

The token_endpoint returns a access token. =C2=A0Not= hing requires scope to be associates with the token.=C2=A0

=C2=A0

That is the best solution. =C2=A0No change required.= =C2=A0Better interoperability in my opinion.=C2=A0

=C2=A0

Still on my way to TO, getting in later today.=C2=A0=

=C2=A0

John B.=C2=A0

=C2=A0



Sent from my iPhone


On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the= value of the parameter "grant_type". So there is no need to intr= oduce a new parameter.

wrt to a potential "no_access_token" grant type. I do not cons= ider this a good idea as it changes the semantics of the token endpoint (as= already pointed out by Thomas). This endpoint ALWAYS responds with an acce= ss token to any grant type. I therefore would prefer to use another endpoint for the intended purpose.

regards,
Torsten.

=C2=A0

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type&= quot; @ authz endpoint this way is not a good thing.=C2=A0

=C2=A0

Instead, defining a new parameter "response_typ= e" @ token endpoint, as I described in my previous message,=C2=A0

probably is better. At least, it does not change the= semantics of the parameters of RFC6749.=C2=A0

=C2=A0

=C2=A0Nat=C2=A0

=C2=A0<= /p>

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>= :

No, I mean response_type=3Dnone and response_type=3D= id_token don't generate a code or access token so you don't use the= Token Endpoint (which is not the same as the Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you get a co= de and exchange it for an id_token only, rather than an access_token, so yo= u're changing the semantics of the Token Endpoint.

=C2=A0

I'm not saying it's a bad thing, just that y= ou can't really compare none and id_token with code_for_id_token.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It's only "not using the token endpoint&quo= t; because the token endpoint copy-pasted and renamed the authentication en= dpoint.

=C2=A0

=C2=A0-- Justin

=C2=A0

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com&g= t; wrote:



Except that these are about not using the Token Endp= oint at all, whereas the current proposal is about the Token Endpoint not r= eturning an access_token field in the JSON.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

The response_type "n= one" is already used in practice, which returns no access token.=C2=A0= It was accepted by the designated experts and registered in the IANA OAuth Authorization E= ndpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpo= int.=C2=A0 The registered "id_token" response type also retur= ns no access token.

=C2=A0

So I think the question o= f whether response types that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical matter.=C2= =A0 Lots of OAuth implementations are already using such response types.

=C2=A0

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for dra= ft-hunt-oauth-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

Phil

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

=C2=A0<= /p>

Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client after s= uccessfully
=C2=A0 =C2=A0 =C2=A0 authenticating the resource owner and obtaining author= ization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token<= /p>

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the t= oken endpoint, which is a parallel to the response_type to the Authorizatio= n Endpoint seems to be a more symmetric way, though I am not sure at all if= that is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the tok= en endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0<= u>

=C2=A0

Nat

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0<= /u>

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0=

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat

=C2=A0<= /p>

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of = OAuth, and I don't see a good argument for doing this work in this work= ing group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wro= te:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The "pr= ompt=3Dconsent" definition being missing is an editorial error.=C2=A0 = It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I'll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there's no difference between a r= esponse with multiple "amr" values that includes "mfa" = and one that doesn't.=C2=A0 Unless a clear use case for why "mfa&q= uot; is needed can be identified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0


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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/

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



=C2=A0

--
Thomas Broyer
/t=C9= =94.ma.b=CA=81wa.je/


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

=C2=A0

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


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a1134570217bee804fee0c0ea-- From nobody Wed Jul 23 11:48:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5C81A0162 for ; Wed, 23 Jul 2014 11:48:35 -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=[AC_DIV_BONANZA=0.001, 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 mlfA2pSsm5lB for ; Wed, 23 Jul 2014 11:48:30 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE7E1A0193 for ; Wed, 23 Jul 2014 11:48:29 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id e16so1239443lan.25 for ; Wed, 23 Jul 2014 11:48: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=D2wMy7hmQ8qd8cACXQtPA3su0ulOMJnNYGiG+w1emn8=; b=Y+6ZghtyV71ODXHQIABJsWl7lqh4HOzY+SpC1EeXu0dkoAnq0JOkzEAbSjErbJzTrN rtQqus3rdmp+PhIRBD/rEVbjTGk4QHn7FHW85Cl/t1UbvS7fP8O8USLc4q+cKMwH/KF4 3Qmm9goUvE5sQu8wDz9jblR0FXS2uS8bCGDjYdfwUsc5gkWV3VhkNfFf9IO+OQno6G8T 9dHkgIkK/uc1aliL11A+Uqmkzz7V78rnsBVU/8wQpMVyn8UMNgTEKkKhz6dUQKousDFz 7Tu8M+Zeu/gNBIDQS04a5W61wGq9OU9FJLQghm8Dl/h0QcDyIkjsKkOybQJiNTDPDCpT lrCg== MIME-Version: 1.0 X-Received: by 10.112.54.197 with SMTP id l5mr3279889lbp.103.1406141307527; Wed, 23 Jul 2014 11:48:27 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Wed, 23 Jul 2014 11:48:27 -0700 (PDT) In-Reply-To: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Wed, 23 Jul 2014 14:48:27 -0400 Message-ID: From: Nat Sakimura To: Takahiko Kawasaki Content-Type: multipart/alternative; boundary=001a11c3e85223a93604fee0c9cc Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/4MvxH91L9X1vyGFQD8E76dNbSQQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 18:48:35 -0000 --001a11c3e85223a93604fee0c9cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Takahiko. Good analysis. 2014-07-23 14:12 GMT-04:00 Takahiko Kawasaki : > Hello, > > (1) RFC 6749 > grant_type=3Dauthorization_code > response=3D{"access_token":...} > > (2) OpenID Connect Core > grant_type=3Dauthorization_code > response=3D{"access_token":..., "id_token":...} > > (3) Currently being discussed > (3)-1 > grant_type=3Dauthorization_code > response_type=3Did_token (a new parameter for the token endpoint) > response=3D{"id_token":...} > > (3)-2 > grant_type=3Dsomething_new (a new value for the token endpoint) > response=3D{"id_token":...} > > (3)-3 > response_type=3Dsomething_new (a new value for the authz endpoint) > grant_type=3Dsomething_new > > However, taking a logical expansion below into account, > > (4) Not being discussed yet, but logically possible > grant_type=3Dpassword > response=3D{"id_token":...} > > it seems "grant_type" should be treated as a parameter to specify > just a 'flow'. IMHO, what tokens should be included in the response > from the token endpoint should be specified by another different means. > For example, "response_type" (a new parameter for the *token* endpoint) > as suggested by Nat. > > Nat> response_type > Nat> OPTIONAL. A string that expresses what tokens are to be returned > Nat> from the Token Endpoint. Extension specifications may use this > Nat> parameter to explicitly expressing the desire to obtain a > Nat> particular type of token. > > If asked, I would add the following: > > The default value of "response_type" is "token" which means that > an access token is requested. However, when the following conditions > are satisfied, the default value is "token id_token". > > Condition-1: > grant_type=3Dauthorization_code > > Condition-2: > The authorization code was issued at the authorization endpoint > with 'openid' scope. > > -- > Best Regards, > Takahiko Kawasaki > > > > 2014-07-24 2:39 GMT+09:00 Mike Jones : > > You need the alternative response_type value (=E2=80=9Ccode_for_id_toke= n=E2=80=9D in >> the A4C draft) to tell the Authorization Server to return a code to be u= sed >> with the new grant type, rather than one to use with the >> =E2=80=9Cauthorization_code=E2=80=9D grant type (which is what response_= type=3Dcode does). >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradle= y >> *Sent:* Wednesday, July 23, 2014 10:33 AM >> *To:* torsten@lodderstedt.net >> >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] New Version Notification for >> draft-hunt-oauth-v2-user-a4c-05.txt >> >> >> >> If we use the token endpoint then a new grant_type is the best way. >> >> >> >> It sort of overloads code, but that is better than messing with >> response_type for the authorization endpoint to change the response from >> the token_endpoint. That is in my opinion a champion bad idea. >> >> >> >> In discussions developing Connect we decided not to open this can of >> worms because no good would come of it. >> >> >> >> The token_endpoint returns a access token. Nothing requires scope to be >> associates with the token. >> >> >> >> That is the best solution. No change required. Better interoperability >> in my opinion. >> >> >> >> Still on my way to TO, getting in later today. >> >> >> >> John B. >> >> >> >> >> >> Sent from my iPhone >> >> >> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >> >> The "response type" of the token endpoint is controlled by the value of >> the parameter "grant_type". So there is no need to introduce a new >> parameter. >> >> wrt to a potential "no_access_token" grant type. I do not consider this = a >> good idea as it changes the semantics of the token endpoint (as already >> pointed out by Thomas). This endpoint ALWAYS responds with an access tok= en >> to any grant type. I therefore would prefer to use another endpoint for = the >> intended purpose. >> >> regards, >> Torsten. >> >> >> >> Am 23.07.2014 13:04, schrieb Nat Sakimura: >> >> IMHO, changing the semantics of "response_type" @ authz endpoint this >> way is not a good thing. >> >> >> >> Instead, defining a new parameter "response_type" @ token endpoint, as I >> described in my previous message, >> >> probably is better. At least, it does not change the semantics of the >> parameters of RFC6749. >> >> >> >> Nat >> >> >> >> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >> >> No, I mean response_type=3Dnone and response_type=3Did_token don't gener= ate a >> code or access token so you don't use the Token Endpoint (which is not t= he >> same as the Authentication Endpoint BTW). >> >> With response_type=3Dcode_for_id_token, you get a code and exchange it f= or >> an id_token only, rather than an access_token, so you're changing the >> semantics of the Token Endpoint. >> >> >> >> I'm not saying it's a bad thing, just that you can't really compare none >> and id_token with code_for_id_token. >> >> >> >> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. >> wrote: >> >> It's only "not using the token endpoint" because the token endpoint >> copy-pasted and renamed the authentication endpoint. >> >> >> >> -- Justin >> >> >> >> On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: >> >> >> >> Except that these are about not using the Token Endpoint at all, >> whereas the current proposal is about the Token Endpoint not returning a= n >> access_token field in the JSON. >> >> >> >> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones >> wrote: >> >> The response_type "none" is already used in practice, which returns no >> access token. It was accepted by the designated experts and registered = in >> the IANA OAuth Authorization Endpoint Response Types registry at >> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#en= dpoint. >> The registered "id_token" response type also returns no access token. >> >> >> >> So I think the question of whether response types that result in no >> access token being returned are acceptable within OAuth 2.0 is already >> settled, as a practical matter. Lots of OAuth implementations are alrea= dy >> using such response types. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt >> *Sent:* Wednesday, July 23, 2014 7:09 AM >> *To:* Nat Sakimura >> *Cc:* >> *Subject:* Re: [OAUTH-WG] New Version Notification for >> draft-hunt-oauth-v2-user-a4c-05.txt >> >> >> >> Yes. This is why it has to be discussed in the IETF. >> >> >> >> Phil >> >> >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: >> >> >> >> Reading back the RFC6749, I am not sure if there is a good way of >> suppressing access token from the response and still be OAuth. It will >> break whole bunch of implicit definitions like: >> >> >> >> authorization server >> The server issuing access tokens to the client after successfully >> authenticating the resource owner and obtaining authorization. >> >> >> >> After all, OAuth is all about issuing access tokens. >> >> >> >> Also, I take back my statement on the grant type in my previous mail. >> >> >> >> The definition of grant and grant_type are respectively: >> >> >> >> grant >> >> credential representing the resource owner's authorization >> >> >> >> grant_type >> >> (string representing the) type of grant sent to the token endpoint t= o >> obtain the access token >> >> >> >> Thus, the grant sent to the token endpoint in this case is still 'code'. >> >> >> >> Response type on the other hand is not so well defined in RFC6749, but i= t >> seems it is representing what is to be returned from the authorization >> endpoint. To express what is to be returned from token endpoint, perhaps >> defining a new parameter to the token endpoint, which is a parallel to t= he >> response_type to the Authorization Endpoint seems to be a more symmetric >> way, though I am not sure at all if that is going to be OAuth any more. = One >> straw-man is to define a new parameter called response_type to the token >> endpoint such as: >> >> >> >> response_type >> >> OPTIONAL. A string representing what is to be returned from the toke= n >> endpoint. >> >> >> >> Then define the behavior of the endpoint according to the values as the >> parallel to the multi-response type spec. >> >> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >> >> >> >> Nat >> >> >> >> >> >> >> >> >> >> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >> >> The draft is very clear. >> >> Phil >> >> >> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >> >> The new grant type that I was talking about was >> >> "authorization_code_but_do_not_return_access_nor_refresh_token", so to >> speak. >> >> It does not return anything per se, but an extension can define somethin= g >> on top of it. >> >> >> >> Then, OIDC can define a binding to it so that the binding only returns I= D >> Token. >> >> This binding work should be done in OIDF. Should there be such a grant >> type, >> >> it will be an extremely short spec. >> >> >> >> At the same time, if any other specification wanted to define >> >> other type of tokens and have it returned from the token endpoint, >> >> it can also use this grant type. >> >> >> >> If what you want is to define a new grant type that returns ID Token >> only, >> >> then, I am with Justin. Since "other response than ID Token" is only >> >> theoretical, this is a more plausible way forward, I suppose. >> >> >> >> Nat >> >> >> >> 2014-07-22 14:30 GMT-04:00 Justin Richer : >> >> So the draft would literally turn into: >> >> "The a4c response type and grant type return an id_token from the token >> endpoint with no access token. All parameters and values are defined in >> OIDC." >> >> Seems like the perfect mini extension draft for OIDF to do. >> >> --Justin >> >> /sent from my phone/ >> >> >> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >> > >> > What about just defining a new grant type in this WG? >> > >> > >> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >> >> >> >> That would be nice. However oidc still needs the new grant type in >> order to implement the same flow. >> >> >> >> Phil >> >> >> >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: >> >> >> >>> +1 to Justin. >> >>> >> >>> >> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >> >>>> >> >>>> Errors like these make it clear to me that it would make much more >> sense to develop this document in the OpenID Foundation. It should be >> something that directly references OpenID Connect Core for all of these >> terms instead of redefining them. It's doing authentication, which is >> fundamentally what OpenID Connect does on top of OAuth, and I don't see = a >> good argument for doing this work in this working group. >> >>>> >> >>>> -- Justin >> >>>> >> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer >> wrote: >> >>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < >> Michael.Jones@microsoft.com> wrote: >> >>>>>> >> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" definitio= n >> being missing is an editorial error. It should be: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> consent >> >>>>>> >> >>>>>> The Authorization Server SHOULD prompt the End-User for consent >> before returning information to the Client. If it cannot obtain consent,= it >> MUST return an error, typically consent_required. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I'll plan to add it in the next draft. >> >>>>> >> >>>>> >> >>>>> It looks like the consent_required error needs to be defined too, >> and you might have forgotten to also import account_selection_required f= rom >> OpenID Connect. >> >>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I agree that there's no difference between a response with >> multiple "amr" values that includes "mfa" and one that doesn't. Unless = a >> clear use case for why "mfa" is needed can be identified, we can delete = it >> in the next draft. >> >>>>> >> >>>>> >> >>>>> Thanks. >> >>>>> >> >>>>> How about "pwd" then? I fully understand that I should return "pwd= " >> if the user authenticated using a password, but what "the service if a >> client secret is used" means in the definition for the "pwd" value? >> >>>>> >> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come >> back ;-) ) >> >>>>> >> >>>>> -- >> >>>>> Thomas Broyer >> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >> >>>>> _______________________________________________ >> >>>>> 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 >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Nat Sakimura (=3Dnat) >> >>> Chairman, OpenID Foundation >> >>> http://nat.sakimura.org/ >> >>> @_nat_en >> >>> >> >>> _______________________________________________ >> >>> OAuth mailing list >> >>> OAuth@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > >> > -- >> > Nat Sakimura (=3Dnat) >> > Chairman, OpenID Foundation >> > http://nat.sakimura.org/ >> > @_nat_en >> >> >> >> >> >> -- >> Nat Sakimura (=3Dnat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> >> >> -- >> Nat Sakimura (=3Dnat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> -- >> Thomas Broyer >> /t=C9=94.ma.b=CA=81wa.je/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> -- >> Thomas Broyer >> /t=C9=94.ma.b=CA=81wa.je/ >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> -- >> Nat Sakimura (=3Dnat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> _______________________________________________ >> >> 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 > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c3e85223a93604fee0c9cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Takahiko. Good analysis.=C2=A0


2014-07-23 14:12 GMT-04:00 T= akahiko Kawasaki <daru.tk@gmail.com>:
Hello,

(1) RFC 6749<= br>=C2=A0 grant_type=3Dauthorization_code
=C2=A0 response=3D{"acces= s_token":...}

(2) OpenID Connect Core
=C2=A0 grant_type=3Dauthorization_code
= =C2=A0 response=3D{"access_token":..., "id_token":...}<= br>
(3) Currently being discussed
=C2=A0 (3)-1
=C2=A0=C2=A0=C2=A0 gra= nt_type=3Dauthorization_code
=C2=A0=C2=A0=C2=A0 response_type=3Did_token= =C2=A0 (a new parameter for the token endpoint)
=C2=A0=C2=A0=C2=A0 respo= nse=3D{"id_token":...}

=C2=A0 (3)-2
=C2=A0=C2=A0=C2=A0 = grant_type=3Dsomething_new=C2=A0 (a new value for the token endpoint)
=C2=A0=C2=A0=C2=A0 response=3D{"id_token":...}

=C2=A0 (3)-= 3
=C2=A0=C2=A0=C2=A0 response_type=3Dsomething_new (a new value for the = authz endpoint)
=C2=A0=C2=A0=C2=A0 grant_type=3Dsomething_new

How= ever, taking a logical expansion below into account,

(4) Not being discussed yet, but logically possible
=C2=A0 grant_typ= e=3Dpassword
=C2=A0 response=3D{"id_token":...}

it seem= s "grant_type" should be treated as a parameter to specify
jus= t a 'flow'. IMHO, what tokens should be included in the response from the token endpoint should be specified by another different means.
= For example, "response_type" (a new parameter for the *token* end= point)
as suggested by Nat.

Nat> response_type
Nat>=C2= =A0=C2=A0 OPTIONAL. A string that expresses what tokens are to be returned<= br> Nat>=C2=A0=C2=A0 from the Token Endpoint. Extension specifications may u= se this
Nat>=C2=A0=C2=A0 parameter to explicitly expressing the desir= e to=C2=A0 obtain a
Nat>=C2=A0=C2=A0 particular type of token.
If asked, I would add the following:

=C2=A0 The default value of "response_type" is "token&qu= ot; which means that
=C2=A0 an access token is requested. However, when = the following conditions
=C2=A0 are satisfied, the default value is &quo= t;token id_token".

=C2=A0=C2=A0=C2=A0 Condition-1:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 grant= _type=3Dauthorization_code

=C2=A0=C2=A0=C2=A0 Condition-2:
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The authorization code was issued at the authoriza= tion endpoint
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with 'openid' scope= .

--
Best Regards,
Takahiko Kawasaki



2014-07-24 2:39 GMT+09:00 Mike Jones &l= t;Michael.= Jones@microsoft.com>:

You need the alternative = response_type value (=E2=80=9Ccode_for_id_token=E2=80=9D in the A4C draft) to tell the Authorization Server to return a code to be = used with the new grant type, rather than one to use with the =E2=80=9Cauth= orization_code=E2=80=9D grant type (which is what response_type=3Dcode does= ).

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: tor= sten@lodderstedt.net


Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oaut= h-v2-user-a4c-05.txt

=C2=A0

If we use the token endpoint then a new grant_type i= s the best way.=C2=A0

=C2=A0

It sort of overloads code, but that is better than m= essing with response_type for the authorization endpoint to change the resp= onse from the token_endpoint. =C2=A0That is in my opinion a champion bad id= ea.=C2=A0

=C2=A0

In discussions developing Connect we decided not to = open this can of worms because no good would come of it. =C2=A0=C2=A0

=C2=A0

The token_endpoint returns a access token. =C2=A0Not= hing requires scope to be associates with the token.=C2=A0

=C2=A0

That is the best solution. =C2=A0No change required.= =C2=A0Better interoperability in my opinion.=C2=A0

=C2=A0

Still on my way to TO, getting in later today.=C2=A0=

=C2=A0

John B.=C2=A0

=C2=A0



Sent from my iPhone


On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the= value of the parameter "grant_type". So there is no need to intr= oduce a new parameter.

wrt to a potential "no_access_token" grant type. I do not cons= ider this a good idea as it changes the semantics of the token endpoint (as= already pointed out by Thomas). This endpoint ALWAYS responds with an acce= ss token to any grant type. I therefore would prefer to use another endpoint for the intended purpose.

regards,
Torsten.

=C2=A0

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type&= quot; @ authz endpoint this way is not a good thing.=C2=A0

=C2=A0

Instead, defining a new parameter "response_typ= e" @ token endpoint, as I described in my previous message,=C2=A0

probably is better. At least, it does not change the= semantics of the parameters of RFC6749.=C2=A0

=C2=A0

=C2=A0Nat=C2=A0

=C2=A0<= /p>

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>= :

No, I mean response_type=3Dnone and response_type=3D= id_token don't generate a code or access token so you don't use the= Token Endpoint (which is not the same as the Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you get a co= de and exchange it for an id_token only, rather than an access_token, so yo= u're changing the semantics of the Token Endpoint.

=C2=A0

I'm not saying it's a bad thing, just that y= ou can't really compare none and id_token with code_for_id_token.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It's only "not using the token endpoint&quo= t; because the token endpoint copy-pasted and renamed the authentication en= dpoint.

=C2=A0

=C2=A0-- Justin

=C2=A0

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com&g= t; wrote:



Except that these are about not using the Token Endp= oint at all, whereas the current proposal is about the Token Endpoint not r= eturning an access_token field in the JSON.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

The response_type "n= one" is already used in practice, which returns no access token.=C2=A0= It was accepted by the designated experts and registered in the IANA OAuth Authorization E= ndpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpo= int.=C2=A0 The registered "id_token" response type also retur= ns no access token.

=C2=A0

So I think the question o= f whether response types that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical matter.=C2= =A0 Lots of OAuth implementations are already using such response types.

=C2=A0

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for dra= ft-hunt-oauth-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

Phil

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

=C2=A0<= /p>

Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client after s= uccessfully
=C2=A0 =C2=A0 =C2=A0 authenticating the resource owner and obtaining author= ization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token<= /p>

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the t= oken endpoint, which is a parallel to the response_type to the Authorizatio= n Endpoint seems to be a more symmetric way, though I am not sure at all if= that is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the tok= en endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0<= u>

=C2=A0

Nat

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0<= /u>

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0=

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat

=C2=A0<= /p>

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of = OAuth, and I don't see a good argument for doing this work in this work= ing group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wro= te:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The "pr= ompt=3Dconsent" definition being missing is an editorial error.=C2=A0 = It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I'll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there's no difference between a r= esponse with multiple "amr" values that includes "mfa" = and one that doesn't.=C2=A0 Unless a clear use case for why "mfa&q= uot; is needed can be identified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0


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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/

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



=C2=A0

--
Thomas Broyer
/t=C9= =94.ma.b=CA=81wa.je/


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

=C2=A0

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


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



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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c3e85223a93604fee0c9cc-- From nobody Wed Jul 23 11:49:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E801B2A05 for ; Wed, 23 Jul 2014 11:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUIsC3BjKs0c for ; Wed, 23 Jul 2014 11:49:36 -0700 (PDT) Received: from na6sys009bog022.obsmtp.com (na6sys009bog022.obsmtp.com [74.125.150.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22B71A0347 for ; Wed, 23 Jul 2014 11:49:35 -0700 (PDT) Received: from mail-ig0-f181.google.com ([209.85.213.181]) (using TLSv1) by na6sys009bob022.postini.com ([74.125.148.12]) with SMTP ID DSNKU9ADv/TnW9n4qVAHg+1dFKTG85cVW2Ew@postini.com; Wed, 23 Jul 2014 11:49:36 PDT Received: by mail-ig0-f181.google.com with SMTP id h3so1785892igd.14 for ; Wed, 23 Jul 2014 11:49:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cxO3hJiQnqxIkU0NYYJJkLWJxkhNf49FwhXDBa+E06c=; b=OCTkiDgUr40vUZMF/EvI79NN9ud9r8GxX2BdA9oU0hA7VEBj9++B2RSGkRGSIN5ZNk /Mo+oZj26nj5/CaXf5ySUhSg0ufr+B/+6RRSHvztWQ0oVfjSHMboTWWgwcZXPcOd27ke cR9jiI9ldjRRDkUr2xwLySU/JHRQF99BwuZs3zMBDyhSU+Psq7ZsSZpD1EaxLBeV2yw5 tSv0M23SL0raEQzNuNwwrTzZKoQMWH4d8Nxi7QhVp4dEJhleVGyyk38JC70oA/PB4oFe CHFrlcBBZSSJfimqymLlmDh8EQi9FKV3sQA8qBGcEgJ1SVt+Vv+PnC460FcrvhZyQzLh dp3w== X-Gm-Message-State: ALoCoQloqM9krgHh19CxABzcUHQBd7wzSFZkuGqskQQVfB5rkC4MOpbEkOJy/eZakS5DtNdCyCwus1nKkaJVeOfzkGGirwtmsKFj6G/cv8912QduhxMdGkwchIc2iVarmkJKDsJQglPg X-Received: by 10.50.138.72 with SMTP id qo8mr6868234igb.2.1406141374924; Wed, 23 Jul 2014 11:49:34 -0700 (PDT) X-Received: by 10.50.138.72 with SMTP id qo8mr6868206igb.2.1406141374766; Wed, 23 Jul 2014 11:49:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Wed, 23 Jul 2014 11:49:04 -0700 (PDT) In-Reply-To: References: <60D7F5DB-0574-4F58-ADCB-C9E4D9850401@gmail.com> From: Brian Campbell Date: Wed, 23 Jul 2014 11:49:04 -0700 Message-ID: To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a1134c79225e23104fee0cd6a Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/72W43QkBmyBblN6dNoD2eClxcm8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD Review of http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer 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, 23 Jul 2014 18:49:38 -0000 --001a1134c79225e23104fee0cd6a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks again for the review and feedback, Kathleen. I added privacy considerations, as discussed on this thread, to the assertion drafts and published them this morning. On Sun, Jul 20, 2014 at 6:18 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Thanks, Brian. That looks good to me. > > Kathleen > > > On Sat, Jul 19, 2014 at 5:18 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Thanks Kathleen, that makes sense. I do, however, think that a little >> 'should' would be more appropriate there than a big 'SHOULD' as there's = no >> other use of RFC2119 language in that text. That okay by you? It would r= ead >> like this: >> >> >> A SAML Assertion may contain privacy-sensitive information and, to >> prevent disclosure of such information to unintended parties, should onl= y >> be transmitted over encrypted channels, such as TLS. In cases where it= =E2=80=99s >> desirable to prevent disclosure of certain information the client, the >> Subject and/or individual attributes of a SAML Assertion should be >> encrypted to the authorization server. >> >> >> Deployments should determine the minimum amount of information necessary >> to complete the exchange and include only that information in an Asserti= on >> (typically by limiting what information is included in an >> or omitting it altogether). In some cases >> the Subject can be a value representing an anonymous or pseudonymous use= r >> as described in Section 6.3.1 of the Assertion Framework for OAuth 2.0 >> Client Authentication and Authorization Grants [*http://tools.ietf.org/h= tml/draft-ietf-oauth-assertions-16#section-6.3.1 >> * >> ]. >> >> >> On Sat, Jul 19, 2014 at 8:24 AM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >>> Thanks for the quick response, Brian. I think the text looks great. >>> The only change I'd like to suggest is in the second sentence, to chan= ge >>> the 'may' to 'SHOULD'. >>> >>> Best regards, >>> Kathleen >>> >>> Sent from my iPhone >>> >>> On Jul 19, 2014, at 1:00 AM, Brian Campbell >>> wrote: >>> >>> How about the following (which is intentionally similar to the text I >>> just put forth for your request for privacy consideration in >>> draft-ietf-oauth-jwt-bearer-09)? >>> >>> A SAML Assertion may contain privacy-sensitive information and, to >>> prevent disclosure of such information to unintended parties, should on= ly >>> be transmitted over encrypted channels, such as TLS. In cases where it= =E2=80=99s >>> desirable to prevent disclosure of certain information the client, the >>> Subject and/or individual attributes of a SAML Assertion may be encrypt= ed >>> to the authorization server. >>> >>> Deployments should determine the minimum amount of information necessar= y >>> to complete the exchange and include only that information in an Assert= ion >>> (typically by limiting what information is included in an >>> or omitting it altogether). In some cases >>> the Subject can be a value representing an anonymous or pseudonymous us= er >>> as described in Section 6.3.1 of the Assertion Framework for OAuth 2.0 >>> Client Authentication and Authorization Grants [*http://tools.ietf.org/= html/draft-ietf-oauth-assertions-16#section-6.3.1 >>> * >>> ]. >>> >>> >>> On Tue, Jul 15, 2014 at 2:04 PM, Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> wrote: >>> >>>> Hello, >>>> >>>> I just finished my review of >>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer. The >>>> draft looks great, thank you for all of your efforts on it! >>>> >>>> I did notice that there were no privacy considerations pointing back t= o >>>> RFC6973, could that text be added? The draft came after the Oauth >>>> framework publication (refernced in the security considerations), so I= am >>>> guessing that is why this was missed as there are privacy consideratio= ns in >>>> the oauth assertion draft (I competed that review as well and the draf= t >>>> looked great. I don't have any comments to add prior to progressing t= he >>>> draft). >>>> >>>> Thank you. >>>> >>>> -- >>>> >>>> Best regards, >>>> Kathleen >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >> > > > -- > > Best regards, > Kathleen > --001a1134c79225e23104fee0cd6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks again for the review and feedback, Kathleen. I adde= d privacy considerations, as discussed on this thread, to the assertion dra= fts and published them this morning.




On Sun, Jul 20, 2014 at 6:18 AM, Kathlee= n Moriarty <kathleen.moriarty.ietf@gmail.com>= wrote:
Thanks, Brian. =C2=A0That l= ooks good to me. =C2=A0

Kathleen


On Sat, Jul 19, 2014 at 5:18 PM, Brian C= ampbell <bcampbell@pingidentity.com> wrote:
Thanks Kathleen, that makes= sense. I do, however, think that a little 'should' would be more a= ppropriate there than a big 'SHOULD' as there's no other use of= RFC2119 language in that text. That okay by you? It would read like this:<= br>

A S= AML Assertion=C2=A0may contain=20 privacy-sensitive information and,=C2=A0to prevent disclosure of=20 such=C2=A0information to unintended parties,=C2=A0should=C2=A0only be trans= mitted=20 over=C2=A0encrypted channels, such as TLS.=C2=A0In cases where it=E2=80=99s= desirable to=20 prevent=C2=A0disclosure of=C2=A0certain=C2=A0information=C2=A0the client, t= he Subject and/or individual attributes of a=C2=A0SAML=C2=A0Assertion should be encrypted to= the=20 authorization server.=C2=A0


Deployments should=C2=A0determine the minim= um=20 amount of=C2=A0information=C2=A0necessary to complete the=C2=A0exchange and= include=20 only that information in an=C2=A0Assertion (typically by limiting what=20 information is included in an <AttributeStatement> or omitting it=20 altogether).=C2=A0In some cases the=C2=A0Subject=C2=A0can be a value repres= enting=20 an=C2=A0anonymous or=C2=A0pseudonymous user as described in Section 6.3.1 o= f the=20 Assertion Framework for OAuth 2.0 Client Authentication and=20 Authorization Grants [http://tools.ietf.org/html/draft-ietf-o= auth-assertions-16#section-6.3.1].


On Sat, Jul 19, 2014 at 8:24 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Thanks for the quick = response, Brian. =C2=A0I think the text looks great. =C2=A0The only change = I'd like to suggest is in the second sentence, to change the 'may&#= 39; to 'SHOULD'.

Best regards,
Kathleen=C2=A0

Sent from= my iPhone

On Jul 19, 2014, at 1:00 AM, Brian Campb= ell <bca= mpbell@pingidentity.com> wrote:

How about the fol= lowing (which is intentionally similar to the text I just put forth for you= r request for privacy consideration in draft-ietf-oauth-jwt-bearer-09)?

A SAML = Assertion=C2=A0may contain privacy-sensitive information and,=C2=A0to preve= nt disclosure of such=C2=A0information to unintended parties,=C2=A0should= =C2=A0only be transmitted over=C2=A0encrypted channels, such as TLS.=C2=A0I= n cases where it=E2=80=99s desirable to prevent=C2=A0disclosure of=C2=A0cer= tain=C2=A0information=C2=A0the client, the Subject and/or individual attrib= utes of a=C2=A0SAML=C2=A0Assertion may be encrypted to the authorization se= rver.=C2=A0

Deployments should=C2=A0determine the minim= um amount of=C2=A0information=C2=A0necessary to complete the=C2=A0exchange = and include only that information in an=C2=A0Assertion (typically by limiti= ng what information is included in an <AttributeStatement> or omittin= g it altogether).=C2=A0In some cases the=C2=A0Subject=C2=A0can be a value r= epresenting an=C2=A0anonymous or=C2=A0pseudonymous user as described in Sec= tion 6.3.1 of the Assertion Framework for OAuth 2.0 Client Authentication a= nd Authorization Grants [http://tools.ietf.org/html/draft-iet= f-oauth-assertions-16#section-6.3.1].


On Tue, Jul 15, 2014 at 2:04 PM, Kathleen Moriarty <= ;kath= leen.moriarty.ietf@gmail.com> wrote:
Hello,

I= just finished my review of=C2=A0http://datatracker.ietf.o= rg/doc/draft-ietf-oauth-saml2-bearer. =C2=A0The draft looks great, than= k you for all of your efforts on it!

I did notice that there were no privacy considerations = pointing back to RFC6973, could that text be added? =C2=A0The draft came af= ter the Oauth framework publication (refernced in the security consideratio= ns), so I am guessing that is why this was missed as there are privacy cons= iderations in the oauth assertion draft (I competed that review as well and= the draft looked great. =C2=A0I don't have any comments to add prior t= o progressing the draft).

Thank you.

--

Best regards,
Kathlee= n

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






<= /div>--

Best regards,
Kathleen
--001a1134c79225e23104fee0cd6a-- From nobody Wed Jul 23 12:19:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435471B2B70 for ; Wed, 23 Jul 2014 12:19:03 -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=[AC_DIV_BONANZA=0.001, 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 DPvBvFjzDyIR for ; Wed, 23 Jul 2014 12:18:56 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC621B2B50 for ; Wed, 23 Jul 2014 12:18:55 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id v6so1254435lbi.24 for ; Wed, 23 Jul 2014 12:18:53 -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=+i27m4xtKP0tZ601+IpATNUSI9C/4Ilarq2w6GwDnLA=; b=sE7W7Cic3G71IRUlzfUITwZ2ncKFhtROfk2JVX7i/x3ozm5WzxHMbjV0etze2owup0 /7svWVIduukhNvzKHmgy0qYjpyileQEM4U/HXjm3KUWnvPpce5We/QRTImXz8vFuEn74 Dbe0rdpTO88KIP7BE2Q+ZotdeuKs80FVJcIBRytBLLO6a6heLgj2BWgLMmWuO4QaDDV7 QrW765DLoh8KAcTduW6vEdpmR4yAqLrw6EikF5Oji4evsJQrm86e1xGWYTIcdDm51ql6 NyBDY4CC+P9XOGtvg7llCy5lmIeB51DrNujkqjkbz9fHKmZmaw0YvgE7RRSpPLeKgjw4 jUgw== MIME-Version: 1.0 X-Received: by 10.112.30.99 with SMTP id r3mr3966149lbh.14.1406143133494; Wed, 23 Jul 2014 12:18:53 -0700 (PDT) Received: by 10.152.113.73 with HTTP; Wed, 23 Jul 2014 12:18:53 -0700 (PDT) Received: by 10.152.113.73 with HTTP; Wed, 23 Jul 2014 12:18:53 -0700 (PDT) In-Reply-To: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Wed, 23 Jul 2014 21:18:53 +0200 Message-ID: From: Thomas Broyer To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a1133a628f9b49604fee1350a Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DQdBiGJYxzScGbipQLFFKZaX6QI Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 19:19:03 -0000 --001a1133a628f9b49604fee1350a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I hadn't realized the JSON response that requires the access_token field is defined per grant_type, so I'd be OK to "extend the semantics" as in the current draft. That was actually my main concern: that the token endpoint mandates access_token; but its actually not the case. Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9crit : > I agree with John that overloading response_type @ authz endpoint is a ba= d > idea. It completely changes the semantics of this parameter. NOTE: what I > was proposing was not this parameter, but a new parameter response_type @ > token endpoint. > > I also think overloading grant_type is a bad idea since it changes its > semantics. I quote the definition here again: > > grant > credential representing the resource owner's authorization > grant_type > type of grant sent to the token endpoint to obtain the access token > > It is not about controlling what is to be returned from the token > endpoint, but the hint to the token endpoint describing the type of > credential the endpoint has received. It seems the "control of what is > being returned from token endpoint" is just a side effect. > > I am somewhat ambivalent[1] in changing the semantics of token endpoint, > but in as much as "text is the king" for a spec., we probably should not > change the semantics of it as Torsten points out. If it is ok to change > this semantics, I believe defining a new parameter to this endpoint to > control the response would be the best way to go. This is what I have > described previously. > > Defining a new endpoint to send code to get ID Token and forbidding the > use of it against token endpoint would not change the semantics of any > existing parameter or endpoint, which is good. However, I doubt if it is > not worth doing. What's the point of avoiding access token scoped to > UserInfo endpoint after all? Defining a new endpoint for just avoiding th= e > access token for userinfo endpoint seems way too much the heavy wait way > and it breaks interoperabiliy: it defeats the purpose of standardization. > > I have started feeling that no change is the best way out. > > Nat > > [1] If instead of saying "Token endpoint - used by the client to > exchange an authorization grant for an access token, typically with > client authentication", it were saying "Token endpoint - used by the > client to exchange an authorization grant for tokens, typically with > client authentication", then it would have been OK. It is an expansion of > the capability rather than changing the semantics. > > > > 2014-07-23 13:39 GMT-04:00 Mike Jones : > >> You need the alternative response_type value (=E2=80=9Ccode_for_id_toke= n=E2=80=9D in >> the A4C draft) to tell the Authorization Server to return a code to be u= sed >> with the new grant type, rather than one to use with the >> =E2=80=9Cauthorization_code=E2=80=9D grant type (which is what response_= type=3Dcode does). >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradle= y >> *Sent:* Wednesday, July 23, 2014 10:33 AM >> *To:* torsten@lodderstedt.net >> >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] New Version Notification for >> draft-hunt-oauth-v2-user-a4c-05.txt >> >> >> >> If we use the token endpoint then a new grant_type is the best way. >> >> >> >> It sort of overloads code, but that is better than messing with >> response_type for the authorization endpoint to change the response from >> the token_endpoint. That is in my opinion a champion bad idea. >> >> >> >> In discussions developing Connect we decided not to open this can of >> worms because no good would come of it. >> >> >> >> The token_endpoint returns a access token. Nothing requires scope to be >> associates with the token. >> >> >> >> That is the best solution. No change required. Better interoperability >> in my opinion. >> >> >> >> Still on my way to TO, getting in later today. >> >> >> >> John B. >> >> >> >> >> >> Sent from my iPhone >> >> >> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >> >> The "response type" of the token endpoint is controlled by the value of >> the parameter "grant_type". So there is no need to introduce a new >> parameter. >> >> wrt to a potential "no_access_token" grant type. I do not consider this = a >> good idea as it changes the semantics of the token endpoint (as already >> pointed out by Thomas). This endpoint ALWAYS responds with an access tok= en >> to any grant type. I therefore would prefer to use another endpoint for = the >> intended purpose. >> >> regards, >> Torsten. >> >> >> >> Am 23.07.2014 13:04, schrieb Nat Sakimura: >> >> IMHO, changing the semantics of "response_type" @ authz endpoint this >> way is not a good thing. >> >> >> >> Instead, defining a new parameter "response_type" @ token endpoint, as I >> described in my previous message, >> >> probably is better. At least, it does not change the semantics of the >> parameters of RFC6749. >> >> >> >> Nat >> >> >> >> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >> >> No, I mean response_type=3Dnone and response_type=3Did_token don't gener= ate a >> code or access token so you don't use the Token Endpoint (which is not t= he >> same as the Authentication Endpoint BTW). >> >> With response_type=3Dcode_for_id_token, you get a code and exchange it f= or >> an id_token only, rather than an access_token, so you're changing the >> semantics of the Token Endpoint. >> >> >> >> I'm not saying it's a bad thing, just that you can't really compare none >> and id_token with code_for_id_token. >> >> >> >> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. >> wrote: >> >> It's only "not using the token endpoint" because the token endpoint >> copy-pasted and renamed the authentication endpoint. >> >> >> >> -- Justin >> >> >> >> On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: >> >> >> >> Except that these are about not using the Token Endpoint at all, >> whereas the current proposal is about the Token Endpoint not returning a= n >> access_token field in the JSON. >> >> >> >> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones >> wrote: >> >> The response_type "none" is already used in practice, which returns no >> access token. It was accepted by the designated experts and registered = in >> the IANA OAuth Authorization Endpoint Response Types registry at >> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#en= dpoint. >> The registered "id_token" response type also returns no access token. >> >> >> >> So I think the question of whether response types that result in no >> access token being returned are acceptable within OAuth 2.0 is already >> settled, as a practical matter. Lots of OAuth implementations are alrea= dy >> using such response types. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt >> *Sent:* Wednesday, July 23, 2014 7:09 AM >> *To:* Nat Sakimura >> *Cc:* >> *Subject:* Re: [OAUTH-WG] New Version Notification for >> draft-hunt-oauth-v2-user-a4c-05.txt >> >> >> >> Yes. This is why it has to be discussed in the IETF. >> >> >> >> Phil >> >> >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: >> >> >> >> Reading back the RFC6749, I am not sure if there is a good way of >> suppressing access token from the response and still be OAuth. It will >> break whole bunch of implicit definitions like: >> >> >> >> authorization server >> The server issuing access tokens to the client after successfully >> authenticating the resource owner and obtaining authorization. >> >> >> >> After all, OAuth is all about issuing access tokens. >> >> >> >> Also, I take back my statement on the grant type in my previous mail. >> >> >> >> The definition of grant and grant_type are respectively: >> >> >> >> grant >> >> credential representing the resource owner's authorization >> >> >> >> grant_type >> >> (string representing the) type of grant sent to the token endpoint t= o >> obtain the access token >> >> >> >> Thus, the grant sent to the token endpoint in this case is still 'code'. >> >> >> >> Response type on the other hand is not so well defined in RFC6749, but i= t >> seems it is representing what is to be returned from the authorization >> endpoint. To express what is to be returned from token endpoint, perhaps >> defining a new parameter to the token endpoint, which is a parallel to t= he >> response_type to the Authorization Endpoint seems to be a more symmetric >> way, though I am not sure at all if that is going to be OAuth any more. = One >> straw-man is to define a new parameter called response_type to the token >> endpoint such as: >> >> >> >> response_type >> >> OPTIONAL. A string representing what is to be returned from the toke= n >> endpoint. >> >> >> >> Then define the behavior of the endpoint according to the values as the >> parallel to the multi-response type spec. >> >> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >> >> >> >> Nat >> >> >> >> >> >> >> >> >> >> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >> >> The draft is very clear. >> >> Phil >> >> >> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >> >> The new grant type that I was talking about was >> >> "authorization_code_but_do_not_return_access_nor_refresh_token", so to >> speak. >> >> It does not return anything per se, but an extension can define somethin= g >> on top of it. >> >> >> >> Then, OIDC can define a binding to it so that the binding only returns I= D >> Token. >> >> This binding work should be done in OIDF. Should there be such a grant >> type, >> >> it will be an extremely short spec. >> >> >> >> At the same time, if any other specification wanted to define >> >> other type of tokens and have it returned from the token endpoint, >> >> it can also use this grant type. >> >> >> >> If what you want is to define a new grant type that returns ID Token >> only, >> >> then, I am with Justin. Since "other response than ID Token" is only >> >> theoretical, this is a more plausible way forward, I suppose. >> >> >> >> Nat >> >> >> >> 2014-07-22 14:30 GMT-04:00 Justin Richer : >> >> So the draft would literally turn into: >> >> "The a4c response type and grant type return an id_token from the token >> endpoint with no access token. All parameters and values are defined in >> OIDC." >> >> Seems like the perfect mini extension draft for OIDF to do. >> >> --Justin >> >> /sent from my phone/ >> >> >> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >> > >> > What about just defining a new grant type in this WG? >> > >> > >> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >> >> >> >> That would be nice. However oidc still needs the new grant type in >> order to implement the same flow. >> >> >> >> Phil >> >> >> >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: >> >> >> >>> +1 to Justin. >> >>> >> >>> >> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >> >>>> >> >>>> Errors like these make it clear to me that it would make much more >> sense to develop this document in the OpenID Foundation. It should be >> something that directly references OpenID Connect Core for all of these >> terms instead of redefining them. It's doing authentication, which is >> fundamentally what OpenID Connect does on top of OAuth, and I don't see = a >> good argument for doing this work in this working group. >> >>>> >> >>>> -- Justin >> >>>> >> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer >> wrote: >> >>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < >> Michael.Jones@microsoft.com> wrote: >> >>>>>> >> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" definitio= n >> being missing is an editorial error. It should be: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> consent >> >>>>>> >> >>>>>> The Authorization Server SHOULD prompt the End-User for consent >> before returning information to the Client. If it cannot obtain consent,= it >> MUST return an error, typically consent_required. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I'll plan to add it in the next draft. >> >>>>> >> >>>>> >> >>>>> It looks like the consent_required error needs to be defined too, >> and you might have forgotten to also import account_selection_required f= rom >> OpenID Connect. >> >>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I agree that there's no difference between a response with >> multiple "amr" values that includes "mfa" and one that doesn't. Unless = a >> clear use case for why "mfa" is needed can be identified, we can delete = it >> in the next draft. >> >>>>> >> >>>>> >> >>>>> Thanks. >> >>>>> >> >>>>> How about "pwd" then? I fully understand that I should return "pwd= " >> if the user authenticated using a password, but what "the service if a >> client secret is used" means in the definition for the "pwd" value? >> >>>>> >> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come >> back ;-) ) >> >>>>> >> >>>>> -- >> >>>>> Thomas Broyer >> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >> >>>>> _______________________________________________ >> >>>>> 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 >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Nat Sakimura (=3Dnat) >> >>> Chairman, OpenID Foundation >> >>> http://nat.sakimura.org/ >> >>> @_nat_en >> >>> >> >>> _______________________________________________ >> >>> OAuth mailing list >> >>> OAuth@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > >> > -- >> > Nat Sakimura (=3Dnat) >> > Chairman, OpenID Foundation >> > http://nat.sakimura.org/ >> > @_nat_en >> >> >> >> >> >> -- >> Nat Sakimura (=3Dnat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> >> >> -- >> Nat Sakimura (=3Dnat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> -- >> Thomas Broyer >> /t=C9=94.ma.b=CA=81wa.je/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> -- >> Thomas Broyer >> /t=C9=94.ma.b=CA=81wa.je/ >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> -- >> Nat Sakimura (=3Dnat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> _______________________________________________ >> >> 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 >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a1133a628f9b49604fee1350a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I hadn't realized the JSON response that requires the ac= cess_token field is defined per grant_type, so I'd be OK to "exten= d the semantics" as in the current draft.
That was actually my main concern: that the token endpoint mandates access_= token; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura"= <sakimura@gmail.com> a =C3= =A9crit :
I agree with John that overloading response_type @ au= thz endpoint is a bad idea. It completely changes the semantics of this par= ameter. NOTE: what I was proposing was not this parameter, but a new parame= ter response_type @ token endpoint.=C2=A0

I also think overloading grant_type is a bad idea since= it changes its semantics. I quote the definition here again:=C2=A0

grant=C2=A0
=C2=A0 =C2=A0 credential repre= senting the resource owner's authorization
grant_type
type of grant sent to t= he token endpoint to obtain the access token

It is not about controlling what is to be returned from the token endp= oint, but the hint to the token endpoint describing the type of credential = the endpoint has received. It seems the "control of what is being retu= rned from token endpoint" =C2=A0is just a side effect.=C2=A0

I am somewhat ambivalent[1] in changing the semantics o= f token endpoint, but in as much as "text is the king" for a spec= ., we probably should not change the semantics of it as Torsten points out.= If it is ok to change this semantics, I believe defining a new parameter t= o this endpoint to control the response would be the best way to go. This i= s what I have described previously.=C2=A0

Defining a new endpoint to send code to get ID Token an= d forbidding the use of it against token endpoint would not change the sema= ntics of any existing parameter or endpoint, which is good. However, I doub= t if it is not worth doing. What's the point of avoiding access token s= coped to UserInfo endpoint after all? Defining a new endpoint for just avoi= ding the access token for userinfo endpoint seems way too much the heavy wa= it way and it breaks interoperabiliy: it defeats the purpose of standardiza= tion.=C2=A0

I have started feeling that no change is the best way o= ut.=C2=A0

Nat
=C2=A0
[1] = =C2=A0If instead of saying "Token endpoint - used by the client to exchange an authorization=C2=A0= grant for an access token, typically with client authentication"= ;, it were saying "Toke= n endpoint - used by the client to exchange an authorization=C2=A0gr= ant for tokens, typically with client authentication", then it would h= ave been OK. It is an expansion of the capability rather than changing the = semantics.



2014-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@mic= rosoft.com>:

You need the alternative = response_type value (=E2=80=9Ccode_for_id_token=E2=80=9D in the A4C draft) to tell the Authorization Server to return a code to be = used with the new grant type, rather than one to use with the =E2=80=9Cauth= orization_code=E2=80=9D grant type (which is what response_type=3Dcode does= ).

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: tor= sten@lodderstedt.net


Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oaut= h-v2-user-a4c-05.txt

=C2=A0

If we use the token endpoint then a new grant_type i= s the best way.=C2=A0

=C2=A0

It sort of overloads code, but that is better than m= essing with response_type for the authorization endpoint to change the resp= onse from the token_endpoint. =C2=A0That is in my opinion a champion bad id= ea.=C2=A0

=C2=A0

In discussions developing Connect we decided not to = open this can of worms because no good would come of it. =C2=A0=C2=A0

=C2=A0

The token_endpoint returns a access token. =C2=A0Not= hing requires scope to be associates with the token.=C2=A0

=C2=A0

That is the best solution. =C2=A0No change required.= =C2=A0Better interoperability in my opinion.=C2=A0

=C2=A0

Still on my way to TO, getting in later today.=C2=A0=

=C2=A0

John B.=C2=A0

=C2=A0



Sent from my iPhone


On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the= value of the parameter "grant_type". So there is no need to intr= oduce a new parameter.

wrt to a potential "no_access_token" grant type. I do not cons= ider this a good idea as it changes the semantics of the token endpoint (as= already pointed out by Thomas). This endpoint ALWAYS responds with an acce= ss token to any grant type. I therefore would prefer to use another endpoint for the intended purpose.

regards,
Torsten.

=C2=A0

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type&= quot; @ authz endpoint this way is not a good thing.=C2=A0

=C2=A0

Instead, defining a new parameter "response_typ= e" @ token endpoint, as I described in my previous message,=C2=A0

probably is better. At least, it does not change the= semantics of the parameters of RFC6749.=C2=A0

=C2=A0

=C2=A0Nat=C2=A0

=C2=A0<= /p>

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>= :

No, I mean response_type=3Dnone and response_type=3D= id_token don't generate a code or access token so you don't use the= Token Endpoint (which is not the same as the Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you get a co= de and exchange it for an id_token only, rather than an access_token, so yo= u're changing the semantics of the Token Endpoint.

=C2=A0

I'm not saying it's a bad thing, just that y= ou can't really compare none and id_token with code_for_id_token.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It's only "not using the token endpoint&quo= t; because the token endpoint copy-pasted and renamed the authentication en= dpoint.

=C2=A0

=C2=A0-- Justin

=C2=A0

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com&g= t; wrote:



Except that these are about not using the Token Endp= oint at all, whereas the current proposal is about the Token Endpoint not r= eturning an access_token field in the JSON.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

The response_type "n= one" is already used in practice, which returns no access token.=C2=A0= It was accepted by the designated experts and registered in the IANA OAuth Authorization E= ndpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpo= int.=C2=A0 The registered "id_token" response type also retur= ns no access token.

=C2=A0

So I think the question o= f whether response types that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical matter.=C2= =A0 Lots of OAuth implementations are already using such response types.

=C2=A0

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for dra= ft-hunt-oauth-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

Phil

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

=C2=A0<= /p>

Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client after s= uccessfully
=C2=A0 =C2=A0 =C2=A0 authenticating the resource owner and obtaining author= ization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token<= /p>

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the t= oken endpoint, which is a parallel to the response_type to the Authorizatio= n Endpoint seems to be a more symmetric way, though I am not sure at all if= that is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the tok= en endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0<= u>

=C2=A0

Nat

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0<= /u>

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0=

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat

=C2=A0<= /p>

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of = OAuth, and I don't see a good argument for doing this work in this work= ing group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wro= te:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The "pr= ompt=3Dconsent" definition being missing is an editorial error.=C2=A0 = It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I'll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there's no difference between a r= esponse with multiple "amr" values that includes "mfa" = and one that doesn't.=C2=A0 Unless a clear use case for why "mfa&q= uot; is needed can be identified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0


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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/

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



=C2=A0

--
Thomas Broyer
/t=C9= =94.ma.b=CA=81wa.je/


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

=C2=A0

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


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

--001a1133a628f9b49604fee1350a-- From nobody Wed Jul 23 12:30:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB961B2BDA for ; Wed, 23 Jul 2014 12:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ-Qqh3FmE7d for ; Wed, 23 Jul 2014 12:30:41 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C3F1B2A87 for ; Wed, 23 Jul 2014 12:30:40 -0700 (PDT) Received: from [31.133.166.94] by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1XA2FI-0005cR-J2; Wed, 23 Jul 2014 21:30:37 +0200 References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-FCEF4DD9-873D-413B-9CA3-E0068269940A Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (11D257) From: Torsten Lodderstedt Date: Wed, 23 Jul 2014 15:30:34 -0400 To: Thomas Broyer X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/oDL0lqG4wSWqPtbQcofQE3EwuSA Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 19:30:46 -0000 --Apple-Mail-FCEF4DD9-873D-413B-9CA3-E0068269940A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Section 5.1 defines _the_ token endpoint response for all grant types. The a= ssumption always was that different grant types allow the client to exchange= different authz grants into an access token (and probably a refresh token).= =20 > Am 23.07.2014 um 15:18 schrieb Thomas Broyer : >=20 > I hadn't realized the JSON response that requires the access_token field i= s defined per grant_type, so I'd be OK to "extend the semantics" as in the c= urrent draft. > That was actually my main concern: that the token endpoint mandates access= _token; but its actually not the case. >=20 > Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9crit := >> I agree with John that overloading response_type @ authz endpoint is a ba= d idea. It completely changes the semantics of this parameter. NOTE: what I w= as proposing was not this parameter, but a new parameter response_type @ tok= en endpoint.=20 >>=20 >> I also think overloading grant_type is a bad idea since it changes its se= mantics. I quote the definition here again:=20 >>=20 >> grant=20 >> credential representing the resource owner's authorization >> =09 >> grant_type >> type of grant sent to the token endpoint to obtain the access token= >>=20 >> It is not about controlling what is to be returned from the token endpoin= t, but the hint to the token endpoint describing the type of credential the e= ndpoint has received. It seems the "control of what is being returned from t= oken endpoint" is just a side effect.=20 >>=20 >> I am somewhat ambivalent[1] in changing the semantics of token endpoint, b= ut in as much as "text is the king" for a spec., we probably should not chan= ge the semantics of it as Torsten points out. If it is ok to change this sem= antics, I believe defining a new parameter to this endpoint to control the r= esponse would be the best way to go. This is what I have described previousl= y.=20 >>=20 >> Defining a new endpoint to send code to get ID Token and forbidding the u= se of it against token endpoint would not change the semantics of any existi= ng parameter or endpoint, which is good. However, I doubt if it is not worth= doing. What's the point of avoiding access token scoped to UserInfo endpoin= t after all? Defining a new endpoint for just avoiding the access token for u= serinfo endpoint seems way too much the heavy wait way and it breaks interop= erabiliy: it defeats the purpose of standardization.=20 >>=20 >> I have started feeling that no change is the best way out.=20 >>=20 >> Nat >> =20 >> [1] If instead of saying "Token endpoint - used by the client to exchang= e an authorization grant for an access token, typically with client authenti= cation", it were saying "Token endpoint - used by the client to exchange an a= uthorization grant for tokens, typically with client authentication", then i= t would have been OK. It is an expansion of the capability rather than chang= ing the semantics. >>=20 >>=20 >>=20 >> 2014-07-23 13:39 GMT-04:00 Mike Jones : >>> You need the alternative response_type value (=E2=80=9Ccode_for_id_token= =E2=80=9D in the A4C draft) to tell the Authorization Server to return a cod= e to be used with the new grant type, rather than one to use with the =E2=80= =9Cauthorization_code=E2=80=9D grant type (which is what response_type=3Dcod= e does). >>>=20 >>> =20 >>>=20 >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley >>> Sent: Wednesday, July 23, 2014 10:33 AM >>> To: torsten@lodderstedt.net >>>=20 >>>=20 >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2= -user-a4c-05.txt >>> =20 >>>=20 >>> If we use the token endpoint then a new grant_type is the best way.=20 >>>=20 >>> =20 >>>=20 >>> It sort of overloads code, but that is better than messing with response= _type for the authorization endpoint to change the response from the token_e= ndpoint. That is in my opinion a champion bad idea.=20 >>>=20 >>> =20 >>>=20 >>> In discussions developing Connect we decided not to open this can of wor= ms because no good would come of it. =20 >>>=20 >>> =20 >>>=20 >>> The token_endpoint returns a access token. Nothing requires scope to be= associates with the token.=20 >>>=20 >>> =20 >>>=20 >>> That is the best solution. No change required. Better interoperability= in my opinion.=20 >>>=20 >>> =20 >>>=20 >>> Still on my way to TO, getting in later today.=20 >>>=20 >>> =20 >>>=20 >>> John B.=20 >>>=20 >>> =20 >>>=20 >>>=20 >>>=20 >>> Sent from my iPhone >>>=20 >>>=20 >>> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >>>=20 >>> The "response type" of the token endpoint is controlled by the value of t= he parameter "grant_type". So there is no need to introduce a new parameter.= >>>=20 >>> wrt to a potential "no_access_token" grant type. I do not consider this a= good idea as it changes the semantics of the token endpoint (as already poi= nted out by Thomas). This endpoint ALWAYS responds with an access token to a= ny grant type. I therefore would prefer to use another endpoint for the inte= nded purpose. >>>=20 >>> regards, >>> Torsten. >>>=20 >>> =20 >>>=20 >>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>>=20 >>> IMHO, changing the semantics of "response_type" @ authz endpoint this wa= y is not a good thing.=20 >>>=20 >>> =20 >>>=20 >>> Instead, defining a new parameter "response_type" @ token endpoint, as I= described in my previous message,=20 >>>=20 >>> probably is better. At least, it does not change the semantics of the pa= rameters of RFC6749.=20 >>>=20 >>> =20 >>>=20 >>> Nat=20 >>>=20 >>> =20 >>>=20 >>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >>>=20 >>> No, I mean response_type=3Dnone and response_type=3Did_token don't gener= ate a code or access token so you don't use the Token Endpoint (which is not= the same as the Authentication Endpoint BTW). >>>=20 >>> With response_type=3Dcode_for_id_token, you get a code and exchange it f= or an id_token only, rather than an access_token, so you're changing the sem= antics of the Token Endpoint. >>>=20 >>> =20 >>>=20 >>> I'm not saying it's a bad thing, just that you can't really compare none= and id_token with code_for_id_token. >>>=20 >>> =20 >>>=20 >>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. w= rote: >>>=20 >>> It's only "not using the token endpoint" because the token endpoint copy= -pasted and renamed the authentication endpoint. >>>=20 >>> =20 >>>=20 >>> -- Justin >>>=20 >>> =20 >>>=20 >>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>> Except that these are about not using the Token Endpoint at all, whereas= the current proposal is about the Token Endpoint not returning an access_to= ken field in the JSON. >>>=20 >>> =20 >>>=20 >>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones wrote: >>>=20 >>> The response_type "none" is already used in practice, which returns no a= ccess token. It was accepted by the designated experts and registered in th= e IANA OAuth Authorization Endpoint Response Types registry at http://www.ia= na.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint. The regi= stered "id_token" response type also returns no access token. >>>=20 >>> =20 >>>=20 >>> So I think the question of whether response types that result in no acce= ss token being returned are acceptable within OAuth 2.0 is already settled, a= s a practical matter. Lots of OAuth implementations are already using such r= esponse types. >>>=20 >>> =20 >>>=20 >>> -- Mike >>>=20 >>> =20 >>>=20 >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt >>> Sent: Wednesday, July 23, 2014 7:09 AM >>> To: Nat Sakimura >>> Cc: >>> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2= -user-a4c-05.txt >>>=20 >>> =20 >>>=20 >>> Yes. This is why it has to be discussed in the IETF. >>>=20 >>> =20 >>>=20 >>> Phil >>>=20 >>> =20 >>>=20 >>> @independentid >>>=20 >>> www.independentid.com >>>=20 >>> phil.hunt@oracle.com >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: >>>=20 >>> =20 >>>=20 >>> Reading back the RFC6749, I am not sure if there is a good way of suppre= ssing access token from the response and still be OAuth. It will break whole= bunch of implicit definitions like:=20 >>>=20 >>> =20 >>>=20 >>> authorization server >>> The server issuing access tokens to the client after successfully >>> authenticating the resource owner and obtaining authorization. >>>=20 >>> =20 >>>=20 >>> After all, OAuth is all about issuing access tokens.=20 >>>=20 >>> =20 >>>=20 >>> Also, I take back my statement on the grant type in my previous mail.=20= >>>=20 >>> =20 >>>=20 >>> The definition of grant and grant_type are respectively:=20 >>>=20 >>> =20 >>>=20 >>> grant=20 >>>=20 >>> credential representing the resource owner's authorization >>>=20 >>> =20 >>>=20 >>> grant_type >>>=20 >>> (string representing the) type of grant sent to the token endpoint t= o obtain the access token >>>=20 >>> =20 >>>=20 >>> Thus, the grant sent to the token endpoint in this case is still 'code'.= =20 >>>=20 >>> =20 >>>=20 >>> Response type on the other hand is not so well defined in RFC6749, but i= t seems it is representing what is to be returned from the authorization end= point. To express what is to be returned from token endpoint, perhaps defini= ng a new parameter to the token endpoint, which is a parallel to the respons= e_type to the Authorization Endpoint seems to be a more symmetric way, thoug= h I am not sure at all if that is going to be OAuth any more. One straw-man i= s to define a new parameter called response_type to the token endpoint such a= s:=20 >>>=20 >>> =20 >>>=20 >>> response_type >>>=20 >>> OPTIONAL. A string representing what is to be returned from the toke= n endpoint.=20 >>>=20 >>> =20 >>>=20 >>> Then define the behavior of the endpoint according to the values as the p= arallel to the multi-response type spec.=20 >>>=20 >>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>=20 >>> =20 >>>=20 >>> Nat >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>>=20 >>> The draft is very clear.=20 >>>=20 >>> Phil >>>=20 >>>=20 >>> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >>>=20 >>> The new grant type that I was talking about was=20 >>>=20 >>> "authorization_code_but_do_not_return_access_nor_refresh_token", so to s= peak.=20 >>>=20 >>> It does not return anything per se, but an extension can define somethin= g on top of it.=20 >>>=20 >>> =20 >>>=20 >>> Then, OIDC can define a binding to it so that the binding only returns I= D Token.=20 >>>=20 >>> This binding work should be done in OIDF. Should there be such a grant t= ype,=20 >>>=20 >>> it will be an extremely short spec.=20 >>>=20 >>> =20 >>>=20 >>> At the same time, if any other specification wanted to define=20 >>>=20 >>> other type of tokens and have it returned from the token endpoint,=20 >>>=20 >>> it can also use this grant type.=20 >>>=20 >>> =20 >>>=20 >>> If what you want is to define a new grant type that returns ID Token onl= y,=20 >>>=20 >>> then, I am with Justin. Since "other response than ID Token" is only=20 >>>=20 >>> theoretical, this is a more plausible way forward, I suppose.=20 >>>=20 >>> =20 >>>=20 >>> Nat >>>=20 >>> =20 >>>=20 >>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>>=20 >>> So the draft would literally turn into: >>>=20 >>> "The a4c response type and grant type return an id_token from the token e= ndpoint with no access token. All parameters and values are defined in OIDC.= " >>>=20 >>> Seems like the perfect mini extension draft for OIDF to do. >>>=20 >>> --Justin >>>=20 >>> /sent from my phone/ >>>=20 >>>=20 >>> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >>> > >>> > What about just defining a new grant type in this WG? >>> > >>> > >>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>> >> >>> >> That would be nice. However oidc still needs the new grant type in or= der to implement the same flow.=20 >>> >> >>> >> Phil >>> >> >>> >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: >>> >> >>> >>> +1 to Justin.=20 >>> >>> >>> >>> >>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >>> >>>> >>> >>>> Errors like these make it clear to me that it would make much more s= ense to develop this document in the OpenID Foundation. It should be somethi= ng that directly references OpenID Connect Core for all of these terms inste= ad of redefining them. It's doing authentication, which is fundamentally wha= t OpenID Connect does on top of OAuth, and I don't see a good argument for d= oing this work in this working group. >>> >>>> >>> >>>> -- Justin >>> >>>> >>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer wro= te: >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones wrote: >>> >>>>>> >>> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" definitio= n being missing is an editorial error. It should be: >>> >>>>>> >>> >>>>>> =20 >>> >>>>>> >>> >>>>>> consent >>> >>>>>> >>> >>>>>> The Authorization Server SHOULD prompt the End-User for consent b= efore returning information to the Client. If it cannot obtain consent, it M= UST return an error, typically consent_required. >>> >>>>>> >>> >>>>>> =20 >>> >>>>>> >>> >>>>>> I'll plan to add it in the next draft. >>> >>>>> >>> >>>>> >>> >>>>> It looks like the consent_required error needs to be defined too, a= nd you might have forgotten to also import account_selection_required from O= penID Connect. >>> >>>>> =20 >>> >>>>>> >>> >>>>>> =20 >>> >>>>>> >>> >>>>>> I agree that there's no difference between a response with multip= le "amr" values that includes "mfa" and one that doesn't. Unless a clear us= e case for why "mfa" is needed can be identified, we can delete it in the ne= xt draft. >>> >>>>> >>> >>>>> >>> >>>>> Thanks. >>> >>>>> >>> >>>>> How about "pwd" then? I fully understand that I should return "pwd= " if the user authenticated using a password, but what "the service if a cli= ent secret is used" means in the definition for the "pwd" value? >>> >>>>> >>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come b= ack ;-) ) >>> >>>>> >>> >>>>> -- >>> >>>>> Thomas Broyer >>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>> >>>>> _______________________________________________ >>> >>>>> 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 >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Nat Sakimura (=3Dnat) >>> >>> Chairman, OpenID Foundation >>> >>> http://nat.sakimura.org/ >>> >>> @_nat_en >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > >>> > >>> > >>> > -- >>> > Nat Sakimura (=3Dnat) >>> > Chairman, OpenID Foundation >>> > http://nat.sakimura.org/ >>> > @_nat_en >>>=20 >>>=20 >>>=20 >>>=20 >>> =20 >>>=20 >>> --=20 >>> Nat Sakimura (=3Dnat) >>>=20 >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>>=20 >>>=20 >>>=20 >>>=20 >>> =20 >>>=20 >>> --=20 >>> Nat Sakimura (=3Dnat) >>>=20 >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>>=20 >>> =20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>> =20 >>>=20 >>> --=20 >>> Thomas Broyer >>> /t=C9=94.ma.b=CA=81wa.je/ >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>> =20 >>>=20 >>> --=20 >>> Thomas Broyer >>> /t=C9=94.ma.b=CA=81wa.je/ >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>> =20 >>>=20 >>> --=20 >>> Nat Sakimura (=3Dnat) >>>=20 >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>>=20 >>> =20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> =20 >>>=20 >>> =20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-FCEF4DD9-873D-413B-9CA3-E0068269940A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Section 5.1 defines _the_ token endpoi= nt response for all grant types. The assumption always was that different gr= ant types allow the client to exchange different authz grants into an access= token (and probably a refresh token). 

Am 23.07.2014 um 1= 5:18 schrieb Thomas Broyer <t.broye= r@gmail.com>:

I hadn't realized the JSON response that requires the access_token field= is defined per grant_type, so I'd be OK to "extend the semantics" as in the= current draft.
That was actually my main concern: that the token endpoint mandates access_t= oken; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit :
I agree with John that overloading response_type @ aut= hz endpoint is a bad idea. It completely changes the semantics of this param= eter. NOTE: what I was proposing was not this parameter, but a new parameter= response_type @ token endpoint. 

I also think overloading grant_type is a bad idea since i= t changes its semantics. I quote the definition here again: 
=
grant 
    credential represent= ing the resource owner's authorization
grant_typ= e
type of gran= t sent to the token endpoint to obtain the access token

=
It is not about controlling what is to be returned from the token endpo= int, but the hint to the token endpoint describing the type of credential th= e endpoint has received. It seems the "control of what is being returned fro= m token endpoint"  is just a side effect. 

I am somewhat ambivalent[1] in changing the semantics of= token endpoint, but in as much as "text is the king" for a spec., we probab= ly should not change the semantics of it as Torsten points out. If it is ok t= o change this semantics, I believe defining a new parameter to this endpoint= to control the response would be the best way to go. This is what I have de= scribed previously. 

Defining a new endpoint to send code to get ID Token and= forbidding the use of it against token endpoint would not change the semant= ics of any existing parameter or endpoint, which is good. However, I doubt i= f it is not worth doing. What's the point of avoiding access token scoped to= UserInfo endpoint after all? Defining a new endpoint for just avoiding the a= ccess token for userinfo endpoint seems way too much the heavy wait way and i= t breaks interoperabiliy: it defeats the purpose of standardization. 

I have started feeling that no change is the best way ou= t. 

Nat
 
[1] &nb= sp;If instead of saying "Toke= n endpoint - used by the client to exchange an authorization gra= nt for an access token, typically with client authentication", it were sayin= g "Token endpoint - used by t= he client to exchange an authorization grant for tokens, typical= ly with client authentication", then it would have been OK. It is an expansi= on of the capability rather than changing the semantics.



2014-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@microso= ft.com>:

You need the alternative re= sponse_type value (=E2=80=9Ccode_for_id_token=E2=80=9D in the A4C draft) to tell the Authorization Server to return a code to be u= sed with the new grant type, rather than one to use with the =E2=80=9Cauthor= ization_code=E2=80=9D grant type (which is what response_type=3Dcode does).<= u>

 =

From: OAuth [mail= to:oauth-bounces= @ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: tors= ten@lodderstedt.net


Cc: oauth@ietf.or= g
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth= -v2-user-a4c-05.txt

 

If we use the token endpoint then a new grant_type is= the best way. 

 

It sort of overloads code, but that is better than me= ssing with response_type for the authorization endpoint to change the respon= se from the token_endpoint.  That is in my opinion a champion bad idea.=  

 

In discussions developing Connect we decided not to o= pen this can of worms because no good would come of it.   <= u>

 

The token_endpoint returns a access token.  Noth= ing requires scope to be associates with the token. 

 

That is the best solution.  No change required. &= nbsp;Better interoperability in my opinion. 

 

Still on my way to TO, getting in later today. <= u>

 

John B. 

 



Sent from my iPhone


On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the value of t= he parameter "grant_type". So there is no need to introduce a new parameter.=

wrt to a potential "no_access_token" grant type. I do not consider this a= good idea as it changes the semantics of the token endpoint (as already poi= nted out by Thomas). This endpoint ALWAYS responds with an access token to a= ny grant type. I therefore would prefer to use another endpoint for the intended purpose.

regards,
Torsten.

 

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type" @ aut= hz endpoint this way is not a good thing. 

 

Instead, defining a new parameter "response_type" @ t= oken endpoint, as I described in my previous message, 

probably is better. At least, it does not change the s= emantics of the parameters of RFC6749. 

 

 Nat 

 

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:=

No, I mean response_type=3Dnone and response_type=3Di= d_token don't generate a code or access token so you don't use the Token End= point (which is not the same as the Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you get a cod= e and exchange it for an id_token only, rather than an access_token, so you'= re changing the semantics of the Token Endpoint.

 

I'm not saying it's a bad thing, just that you can't r= eally compare none and id_token with code_for_id_token.

 

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. &l= t;jricher@mitre.org> wrote:

It's only "not using the token endpoint" because the t= oken endpoint copy-pasted and renamed the authentication endpoint.

 

 -- Justin

 



Except that these are about not using the Token Endpo= int at all, whereas the current proposal is about the Token Endpoint not ret= urning an access_token field in the JSON.

 

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@mi= crosoft.com> wrote:

The response_type "none" is= already used in practice, which returns no access token.  It was accep= ted by the designated experts and registered in the IANA OAuth Authorization En= dpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoi= nt.  The registered "id_token" response type also returns no access= token.

 =

So I think the question of w= hether response types that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical matter. = ; Lots of OAuth implementations are already using such response types.

 =

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

 =

From: OA= uth [mailto:oaut= h-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for draft= -hunt-oauth-v2-user-a4c-05.txt

 

Yes. This is why it has to be discussed in the IETF.<= u>

 

 

 

 

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com> w= rote:

 

Reading back the RFC6749, I am not sure if there is a= good way of suppressing access token from the response and still be OAuth. I= t will break whole bunch of implicit definitions like: 

 

authorization server
      The server issuing access tokens to the client after su= ccessfully
      authenticating the resource owner and obtaining authori= zation.

 

After all, OAuth is all about issuing access tokens.&= nbsp;

 

Also, I take back my statement on the grant type in m= y previous mail. 

 

The definition of grant and grant_type are respective= ly: 

 

grant 

    credential representing the resource ow= ner's authorization

         = ;  

grant_type

    (string representing the) type of g= rant sent to the token endpoint to obtain the access token

=

 

Thus, the grant sent to the token endpoint in this ca= se is still 'code'. 

 

Response type on the other hand is not so well define= d in RFC6749, but it seems it is representing what is to be returned from th= e authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the to= ken endpoint, which is a parallel to the response_type to the Authorization E= ndpoint seems to be a more symmetric way, though I am not sure at all if tha= t is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the toke= n endpoint such as: 

 

response_type

    OPTIONAL. A string representing what is= to be returned from the token endpoint. 

    

Then define the behavior of the endpoint according to= the values as the parallel to the multi-response type spec. =

 

Nat

    

 

 

 

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:

The draft is very clear. 

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was =

"authorization_code_but_do_not_return_access_nor_refr= esh_token", so to speak. 

It does not return anything per se, but an extension c= an define something on top of it. 

 

Then, OIDC can define a binding to it so that the bin= ding only returns ID Token. 

This binding work should be done in OIDF. Should ther= e be such a grant type, 

it will be an extremely short spec. 

 

At the same time, if any other specification wanted t= o define 

other type of tokens and have it returned from the to= ken endpoint, 

it can also use this grant type. <= /p>

 

If what you want is to define a new grant type that r= eturns ID Token only, 

then, I am with Justin. Since "other response than ID= Token" is only 

theoretical, this is a more plausible way forward, I s= uppose. 

 

Nat

 

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the token endp= oint with no access token. All parameters and values are defined in OIDC."
Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in o= rder to implement the same flow. 
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin. 
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make mu= ch more sense to develop this document in the OpenID Foundation. It should b= e something that directly references OpenID Connect Core for all of these te= rms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of O= Auth, and I don't see a good argument for doing this work in this working gr= oup.
>>>>
>>>>  -- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote= :
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.  The "prompt=3D= consent" definition being missing is an editorial error.  It should be:=
>>>>>>
>>>>>>  
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-User= for consent before returning information to the Client. If it cannot obtain= consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I'll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be de= fined too, and you might have forgotten to also import account_selection_req= uired from OpenID Connect.
>>>>>  
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I agree that there's no difference between a respon= se with multiple "amr" values that includes "mfa" and one that doesn't. = ; Unless a clear use case for why "mfa" is needed can be identified, we can d= elete it in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand that I should r= eturn "pwd" if the user authenticated using a password, but what "the servic= e if a client secret is used" means in the definition for the "pwd" value? >>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til= you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAu= th@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@i= etf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://n= at.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.= org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakim= ura.org/
> @_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.o= rg/
@_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.o= rg/
@_nat_en

 


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



 

--
Thomas Broyer
/t=C9=94.ma.= b=CA=81wa.je/

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



 

-- =
Thomas Broyer
/t=C9=94= .ma.b=CA=81wa.je/


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.o= rg/
@_nat_en

 

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

 

 

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


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




--
Nat Sakim= ura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-FCEF4DD9-873D-413B-9CA3-E0068269940A-- From nobody Wed Jul 23 12:32:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0A01B2A87 for ; Wed, 23 Jul 2014 12:32:09 -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=[AC_DIV_BONANZA=0.001, 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 ss8M-OYmX7_E for ; Wed, 23 Jul 2014 12:32:05 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D7781A033A for ; Wed, 23 Jul 2014 12:32:04 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id s7so1305235lbd.0 for ; Wed, 23 Jul 2014 12:32:02 -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=EMdTwgi3M2k/fvkS+cHR0suE/dcpyRMZ+U5zHQTeg6Y=; b=PFkYrHqBtNI7PzH+grVSNkpYfLUzPGygcWPILKnF3RRQXLcSGryuamQ503hzlXGn5+ wgDLQGKCiapxEbRqs3Z7/XC4S4Sm6oN7ILI1Qy3oSpj8xPZ3dx+4ZS4Z8PIB9q/zmDpe a/IQhcQv8mbBocHQwoQzjdoTtGLMKr2m0NrNZEpIoCvzVq6Dnvb+aohtr90tFDVG2pzB X8GUjCnkQpP91uF3J5hV4TKOLSy0zb89EAUaD49GSmkNS+doZj+VL/GMJcA5+vetcXPv MU0eJW4KTQWBk5Cf+TzQvDijNFf6GDOUUD6sArGFpiVLJROXVXYUwXxHTK+2U87tF/i5 eNVw== MIME-Version: 1.0 X-Received: by 10.152.183.236 with SMTP id ep12mr4098897lac.82.1406143922169; Wed, 23 Jul 2014 12:32:02 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Wed, 23 Jul 2014 12:32:02 -0700 (PDT) In-Reply-To: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Wed, 23 Jul 2014 15:32:02 -0400 Message-ID: From: Nat Sakimura To: Thomas Broyer Content-Type: multipart/alternative; boundary=001a11345702fbf57b04fee1648d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fCyDJ59tWHzfYb4VMXYrQB-LFK4 Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 19:32:09 -0000 --001a11345702fbf57b04fee1648d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is it? Apart from the implicit grant that does not use token endpoint, all other grant references section 5.1 for the response, i.e., all shares the same response. 2014-07-23 15:18 GMT-04:00 Thomas Broyer : > I hadn't realized the JSON response that requires the access_token field > is defined per grant_type, so I'd be OK to "extend the semantics" as in t= he > current draft. > That was actually my main concern: that the token endpoint mandates > access_token; but its actually not the case. > Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9crit = : > > I agree with John that overloading response_type @ authz endpoint is a ba= d >> idea. It completely changes the semantics of this parameter. NOTE: what = I >> was proposing was not this parameter, but a new parameter response_type = @ >> token endpoint. >> >> I also think overloading grant_type is a bad idea since it changes its >> semantics. I quote the definition here again: >> >> grant >> credential representing the resource owner's authorization >> grant_type >> type of grant sent to the token endpoint to obtain the access token >> >> It is not about controlling what is to be returned from the token >> endpoint, but the hint to the token endpoint describing the type of >> credential the endpoint has received. It seems the "control of what is >> being returned from token endpoint" is just a side effect. >> >> I am somewhat ambivalent[1] in changing the semantics of token endpoint, >> but in as much as "text is the king" for a spec., we probably should not >> change the semantics of it as Torsten points out. If it is ok to change >> this semantics, I believe defining a new parameter to this endpoint to >> control the response would be the best way to go. This is what I have >> described previously. >> >> Defining a new endpoint to send code to get ID Token and forbidding the >> use of it against token endpoint would not change the semantics of any >> existing parameter or endpoint, which is good. However, I doubt if it is >> not worth doing. What's the point of avoiding access token scoped to >> UserInfo endpoint after all? Defining a new endpoint for just avoiding t= he >> access token for userinfo endpoint seems way too much the heavy wait way >> and it breaks interoperabiliy: it defeats the purpose of standardization= . >> >> I have started feeling that no change is the best way out. >> >> Nat >> >> [1] If instead of saying "Token endpoint - used by the client to >> exchange an authorization grant for an access token, typically with >> client authentication", it were saying "Token endpoint - used by the >> client to exchange an authorization grant for tokens, typically with >> client authentication", then it would have been OK. It is an expansion o= f >> the capability rather than changing the semantics. >> >> >> >> 2014-07-23 13:39 GMT-04:00 Mike Jones : >> >>> You need the alternative response_type value (=E2=80=9Ccode_for_id_tok= en=E2=80=9D in >>> the A4C draft) to tell the Authorization Server to return a code to be = used >>> with the new grant type, rather than one to use with the >>> =E2=80=9Cauthorization_code=E2=80=9D grant type (which is what response= _type=3Dcode does). >>> >>> >>> >>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John >>> Bradley >>> *Sent:* Wednesday, July 23, 2014 10:33 AM >>> *To:* torsten@lodderstedt.net >>> >>> *Cc:* oauth@ietf.org >>> *Subject:* Re: [OAUTH-WG] New Version Notification for >>> draft-hunt-oauth-v2-user-a4c-05.txt >>> >>> >>> >>> If we use the token endpoint then a new grant_type is the best way. >>> >>> >>> >>> It sort of overloads code, but that is better than messing with >>> response_type for the authorization endpoint to change the response fro= m >>> the token_endpoint. That is in my opinion a champion bad idea. >>> >>> >>> >>> In discussions developing Connect we decided not to open this can of >>> worms because no good would come of it. >>> >>> >>> >>> The token_endpoint returns a access token. Nothing requires scope to b= e >>> associates with the token. >>> >>> >>> >>> That is the best solution. No change required. Better interoperabilit= y >>> in my opinion. >>> >>> >>> >>> Still on my way to TO, getting in later today. >>> >>> >>> >>> John B. >>> >>> >>> >>> >>> >>> Sent from my iPhone >>> >>> >>> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >>> >>> The "response type" of the token endpoint is controlled by the value >>> of the parameter "grant_type". So there is no need to introduce a new >>> parameter. >>> >>> wrt to a potential "no_access_token" grant type. I do not consider this >>> a good idea as it changes the semantics of the token endpoint (as alrea= dy >>> pointed out by Thomas). This endpoint ALWAYS responds with an access to= ken >>> to any grant type. I therefore would prefer to use another endpoint for= the >>> intended purpose. >>> >>> regards, >>> Torsten. >>> >>> >>> >>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>> >>> IMHO, changing the semantics of "response_type" @ authz endpoint this >>> way is not a good thing. >>> >>> >>> >>> Instead, defining a new parameter "response_type" @ token endpoint, as = I >>> described in my previous message, >>> >>> probably is better. At least, it does not change the semantics of the >>> parameters of RFC6749. >>> >>> >>> >>> Nat >>> >>> >>> >>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >>> >>> No, I mean response_type=3Dnone and response_type=3Did_token don't gene= rate >>> a code or access token so you don't use the Token Endpoint (which is no= t >>> the same as the Authentication Endpoint BTW). >>> >>> With response_type=3Dcode_for_id_token, you get a code and exchange it = for >>> an id_token only, rather than an access_token, so you're changing the >>> semantics of the Token Endpoint. >>> >>> >>> >>> I'm not saying it's a bad thing, just that you can't really compare non= e >>> and id_token with code_for_id_token. >>> >>> >>> >>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. >>> wrote: >>> >>> It's only "not using the token endpoint" because the token endpoint >>> copy-pasted and renamed the authentication endpoint. >>> >>> >>> >>> -- Justin >>> >>> >>> >>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: >>> >>> >>> >>> Except that these are about not using the Token Endpoint at all, >>> whereas the current proposal is about the Token Endpoint not returning = an >>> access_token field in the JSON. >>> >>> >>> >>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones >>> wrote: >>> >>> The response_type "none" is already used in practice, which returns no >>> access token. It was accepted by the designated experts and registered= in >>> the IANA OAuth Authorization Endpoint Response Types registry at >>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#e= ndpoint. >>> The registered "id_token" response type also returns no access token. >>> >>> >>> >>> So I think the question of whether response types that result in no >>> access token being returned are acceptable within OAuth 2.0 is already >>> settled, as a practical matter. Lots of OAuth implementations are alre= ady >>> using such response types. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt >>> *Sent:* Wednesday, July 23, 2014 7:09 AM >>> *To:* Nat Sakimura >>> *Cc:* >>> *Subject:* Re: [OAUTH-WG] New Version Notification for >>> draft-hunt-oauth-v2-user-a4c-05.txt >>> >>> >>> >>> Yes. This is why it has to be discussed in the IETF. >>> >>> >>> >>> Phil >>> >>> >>> >>> @independentid >>> >>> www.independentid.com >>> >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> >>> >>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: >>> >>> >>> >>> Reading back the RFC6749, I am not sure if there is a good way of >>> suppressing access token from the response and still be OAuth. It will >>> break whole bunch of implicit definitions like: >>> >>> >>> >>> authorization server >>> The server issuing access tokens to the client after successfully >>> authenticating the resource owner and obtaining authorization. >>> >>> >>> >>> After all, OAuth is all about issuing access tokens. >>> >>> >>> >>> Also, I take back my statement on the grant type in my previous mail. >>> >>> >>> >>> The definition of grant and grant_type are respectively: >>> >>> >>> >>> grant >>> >>> credential representing the resource owner's authorization >>> >>> >>> >>> grant_type >>> >>> (string representing the) type of grant sent to the token endpoint >>> to obtain the access token >>> >>> >>> >>> Thus, the grant sent to the token endpoint in this case is still 'code'= . >>> >>> >>> >>> Response type on the other hand is not so well defined in RFC6749, but >>> it seems it is representing what is to be returned from the authorizati= on >>> endpoint. To express what is to be returned from token endpoint, perhap= s >>> defining a new parameter to the token endpoint, which is a parallel to = the >>> response_type to the Authorization Endpoint seems to be a more symmetri= c >>> way, though I am not sure at all if that is going to be OAuth any more.= One >>> straw-man is to define a new parameter called response_type to the toke= n >>> endpoint such as: >>> >>> >>> >>> response_type >>> >>> OPTIONAL. A string representing what is to be returned from the >>> token endpoint. >>> >>> >>> >>> Then define the behavior of the endpoint according to the values as the >>> parallel to the multi-response type spec. >>> >>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>> >>> >>> >>> Nat >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>> >>> The draft is very clear. >>> >>> Phil >>> >>> >>> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >>> >>> The new grant type that I was talking about was >>> >>> "authorization_code_but_do_not_return_access_nor_refresh_token", so to >>> speak. >>> >>> It does not return anything per se, but an extension can define >>> something on top of it. >>> >>> >>> >>> Then, OIDC can define a binding to it so that the binding only returns >>> ID Token. >>> >>> This binding work should be done in OIDF. Should there be such a grant >>> type, >>> >>> it will be an extremely short spec. >>> >>> >>> >>> At the same time, if any other specification wanted to define >>> >>> other type of tokens and have it returned from the token endpoint, >>> >>> it can also use this grant type. >>> >>> >>> >>> If what you want is to define a new grant type that returns ID Token >>> only, >>> >>> then, I am with Justin. Since "other response than ID Token" is only >>> >>> theoretical, this is a more plausible way forward, I suppose. >>> >>> >>> >>> Nat >>> >>> >>> >>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>> >>> So the draft would literally turn into: >>> >>> "The a4c response type and grant type return an id_token from the token >>> endpoint with no access token. All parameters and values are defined in >>> OIDC." >>> >>> Seems like the perfect mini extension draft for OIDF to do. >>> >>> --Justin >>> >>> /sent from my phone/ >>> >>> >>> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >>> > >>> > What about just defining a new grant type in this WG? >>> > >>> > >>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>> >> >>> >> That would be nice. However oidc still needs the new grant type in >>> order to implement the same flow. >>> >> >>> >> Phil >>> >> >>> >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: >>> >> >>> >>> +1 to Justin. >>> >>> >>> >>> >>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >>> >>>> >>> >>>> Errors like these make it clear to me that it would make much more >>> sense to develop this document in the OpenID Foundation. It should be >>> something that directly references OpenID Connect Core for all of these >>> terms instead of redefining them. It's doing authentication, which is >>> fundamentally what OpenID Connect does on top of OAuth, and I don't see= a >>> good argument for doing this work in this working group. >>> >>>> >>> >>>> -- Justin >>> >>>> >>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer >>> wrote: >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < >>> Michael.Jones@microsoft.com> wrote: >>> >>>>>> >>> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" definiti= on >>> being missing is an editorial error. It should be: >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> consent >>> >>>>>> >>> >>>>>> The Authorization Server SHOULD prompt the End-User for consent >>> before returning information to the Client. If it cannot obtain consent= , it >>> MUST return an error, typically consent_required. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> I'll plan to add it in the next draft. >>> >>>>> >>> >>>>> >>> >>>>> It looks like the consent_required error needs to be defined too, >>> and you might have forgotten to also import account_selection_required = from >>> OpenID Connect. >>> >>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> I agree that there's no difference between a response with >>> multiple "amr" values that includes "mfa" and one that doesn't. Unless= a >>> clear use case for why "mfa" is needed can be identified, we can delete= it >>> in the next draft. >>> >>>>> >>> >>>>> >>> >>>>> Thanks. >>> >>>>> >>> >>>>> How about "pwd" then? I fully understand that I should return >>> "pwd" if the user authenticated using a password, but what "the service= if >>> a client secret is used" means in the definition for the "pwd" value? >>> >>>>> >>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come >>> back ;-) ) >>> >>>>> >>> >>>>> -- >>> >>>>> Thomas Broyer >>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>> >>>>> _______________________________________________ >>> >>>>> 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 >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Nat Sakimura (=3Dnat) >>> >>> Chairman, OpenID Foundation >>> >>> http://nat.sakimura.org/ >>> >>> @_nat_en >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > >>> > >>> > >>> > -- >>> > Nat Sakimura (=3Dnat) >>> > Chairman, OpenID Foundation >>> > http://nat.sakimura.org/ >>> > @_nat_en >>> >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >>> -- >>> Thomas Broyer >>> /t=C9=94.ma.b=CA=81wa.je/ >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >>> -- >>> Thomas Broyer >>> /t=C9=94.ma.b=CA=81wa.je/ >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> >>> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11345702fbf57b04fee1648d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is it? Apart from the implicit grant that does not use tok= en endpoint, all other grant references section 5.1 for the response, i.e.,= all shares the same response.=C2=A0

2014-07-23 15:18 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:

I hadn't realized the JSON response that requires the ac= cess_token field is defined per grant_type, so I'd be OK to "exten= d the semantics" as in the current draft.
That was actually my main concern: that the token endpoint mandates access_= token; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura"= <sakimura@gmail= .com> a =C3=A9crit :

=
I agree with John that overloading response_type @ au= thz endpoint is a bad idea. It completely changes the semantics of this par= ameter. NOTE: what I was proposing was not this parameter, but a new parame= ter response_type @ token endpoint.=C2=A0

I also think overloading grant_type is a bad idea since= it changes its semantics. I quote the definition here again:=C2=A0

grant=C2=A0
=C2=A0 =C2=A0 credential repre= senting the resource owner's authorization
grant_type
type of grant sent to t= he token endpoint to obtain the access token

It is not about controlling what is to be returned from the token endp= oint, but the hint to the token endpoint describing the type of credential = the endpoint has received. It seems the "control of what is being retu= rned from token endpoint" =C2=A0is just a side effect.=C2=A0

I am somewhat ambivalent[1] in changing the semantics o= f token endpoint, but in as much as "text is the king" for a spec= ., we probably should not change the semantics of it as Torsten points out.= If it is ok to change this semantics, I believe defining a new parameter t= o this endpoint to control the response would be the best way to go. This i= s what I have described previously.=C2=A0

Defining a new endpoint to send code to get ID Token an= d forbidding the use of it against token endpoint would not change the sema= ntics of any existing parameter or endpoint, which is good. However, I doub= t if it is not worth doing. What's the point of avoiding access token s= coped to UserInfo endpoint after all? Defining a new endpoint for just avoi= ding the access token for userinfo endpoint seems way too much the heavy wa= it way and it breaks interoperabiliy: it defeats the purpose of standardiza= tion.=C2=A0

I have started feeling that no change is the best way o= ut.=C2=A0

Nat
=C2=A0
[1] = =C2=A0If instead of saying "Token endpoint - used by the client to exchange an authorization=C2=A0= grant for an access token, typically with client authentication"= ;, it were saying "Toke= n endpoint - used by the client to exchange an authorization=C2=A0gr= ant for tokens, typically with client authentication", then it would h= ave been OK. It is an expansion of the capability rather than changing the = semantics.



2014-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@mic= rosoft.com>:

You need the alternative = response_type value (=E2=80=9Ccode_for_id_token=E2=80=9D in the A4C draft) to tell the Authorization Server to return a code to be = used with the new grant type, rather than one to use with the =E2=80=9Cauth= orization_code=E2=80=9D grant type (which is what response_type=3Dcode does= ).

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: tor= sten@lodderstedt.net


Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oaut= h-v2-user-a4c-05.txt

=C2=A0

If we use the token endpoint then a new grant_type i= s the best way.=C2=A0

=C2=A0

It sort of overloads code, but that is better than m= essing with response_type for the authorization endpoint to change the resp= onse from the token_endpoint. =C2=A0That is in my opinion a champion bad id= ea.=C2=A0

=C2=A0

In discussions developing Connect we decided not to = open this can of worms because no good would come of it. =C2=A0=C2=A0

=C2=A0

The token_endpoint returns a access token. =C2=A0Not= hing requires scope to be associates with the token.=C2=A0

=C2=A0

That is the best solution. =C2=A0No change required.= =C2=A0Better interoperability in my opinion.=C2=A0

=C2=A0

Still on my way to TO, getting in later today.=C2=A0=

=C2=A0

John B.=C2=A0

=C2=A0



Sent from my iPhone


On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the= value of the parameter "grant_type". So there is no need to intr= oduce a new parameter.

wrt to a potential "no_access_token" grant type. I do not cons= ider this a good idea as it changes the semantics of the token endpoint (as= already pointed out by Thomas). This endpoint ALWAYS responds with an acce= ss token to any grant type. I therefore would prefer to use another endpoint for the intended purpose.

regards,
Torsten.

=C2=A0

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type&= quot; @ authz endpoint this way is not a good thing.=C2=A0

=C2=A0

Instead, defining a new parameter "response_typ= e" @ token endpoint, as I described in my previous message,=C2=A0

probably is better. At least, it does not change the= semantics of the parameters of RFC6749.=C2=A0

=C2=A0

=C2=A0Nat=C2=A0

=C2=A0<= /p>

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>= :

No, I mean response_type=3Dnone and response_type=3D= id_token don't generate a code or access token so you don't use the= Token Endpoint (which is not the same as the Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you get a co= de and exchange it for an id_token only, rather than an access_token, so yo= u're changing the semantics of the Token Endpoint.

=C2=A0

I'm not saying it's a bad thing, just that y= ou can't really compare none and id_token with code_for_id_token.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It's only "not using the token endpoint&quo= t; because the token endpoint copy-pasted and renamed the authentication en= dpoint.

=C2=A0

=C2=A0-- Justin

=C2=A0

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com&g= t; wrote:



Except that these are about not using the Token Endp= oint at all, whereas the current proposal is about the Token Endpoint not r= eturning an access_token field in the JSON.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

The response_type "n= one" is already used in practice, which returns no access token.=C2=A0= It was accepted by the designated experts and registered in the IANA OAuth Authorization E= ndpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpo= int.=C2=A0 The registered "id_token" response type also retur= ns no access token.

=C2=A0

So I think the question o= f whether response types that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical matter.=C2= =A0 Lots of OAuth implementations are already using such response types.

=C2=A0

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for dra= ft-hunt-oauth-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

Phil

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

=C2=A0<= /p>

Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client after s= uccessfully
=C2=A0 =C2=A0 =C2=A0 authenticating the resource owner and obtaining author= ization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token<= /p>

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the t= oken endpoint, which is a parallel to the response_type to the Authorizatio= n Endpoint seems to be a more symmetric way, though I am not sure at all if= that is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the tok= en endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0<= u>

=C2=A0

Nat

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0<= /u>

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0=

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat

=C2=A0<= /p>

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of = OAuth, and I don't see a good argument for doing this work in this work= ing group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wro= te:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The "pr= ompt=3Dconsent" definition being missing is an editorial error.=C2=A0 = It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I'll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there's no difference between a r= esponse with multiple "amr" values that includes "mfa" = and one that doesn't.=C2=A0 Unless a clear use case for why "mfa&q= uot; is needed can be identified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0


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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/

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



=C2=A0

--
Thomas Broyer
/t=C9= =94.ma.b=CA=81wa.je/


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

=C2=A0

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


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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




--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11345702fbf57b04fee1648d-- From nobody Wed Jul 23 12:41:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851321A016A for ; Wed, 23 Jul 2014 12:41:45 -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=[AC_DIV_BONANZA=0.001, 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 Zlb4wshm3g-d for ; Wed, 23 Jul 2014 12:41:41 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC801A014F for ; Wed, 23 Jul 2014 12:41:40 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id el20so1279154lab.41 for ; Wed, 23 Jul 2014 12:41:39 -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=oF+KcHTdQyDcbHw1YGtTdhcPdmNKMVWK14GZIBRsRsQ=; b=PbUEizW1XK5c4DTQszNPWnf0/BtIzBHi8qqvBaQHhdwyxVffKk3pQsgNUaHKC1LKce QnaDl3TUPvy7T76dwDKaFQ1xhDhhwKNZCkn7wr0YnnqFmhs4sova1Qfyc17vSmEav/Yu cm5zzCmCGkhbvwAiFiRmWzJvS/cdB3TbiejMHTlSonIYX7fW0r5UztaoZQ0Wkc99ilve i08f1Ebyj9FKXPQ8kNWEPtL0jK+ygnebG010Xum5oq8P67DMTB4hc5aXTkIFzHWbhNnY mGo2Jy0varpJB8tFFIHyYd+WYa4f4CnsubHDqReZi8i07HzWn4Gwc/p+0iJtwoc5pgP/ OB/g== MIME-Version: 1.0 X-Received: by 10.152.234.2 with SMTP id ua2mr4151955lac.34.1406144499073; Wed, 23 Jul 2014 12:41:39 -0700 (PDT) Received: by 10.152.113.73 with HTTP; Wed, 23 Jul 2014 12:41:38 -0700 (PDT) Received: by 10.152.113.73 with HTTP; Wed, 23 Jul 2014 12:41:38 -0700 (PDT) In-Reply-To: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Wed, 23 Jul 2014 21:41:38 +0200 Message-ID: From: Thomas Broyer To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a113431645ed7a704fee187a8 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TXjcsqbdZvZKMm8KwsxEsdFOE4s Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 19:41:45 -0000 --001a113431645ed7a704fee187a8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is it said anywhere that ALL grant types MUST use Section 5.1 responses? Each grant type references Section 5.1, and "access token request" is only defined in the context of the defined grant types. Section 2.2 doesn't talk about the request or response format. Le 23 juil. 2014 21:32, "Nat Sakimura" a =C3=A9crit : > Is it? Apart from the implicit grant that does not use token endpoint, al= l > other grant references section 5.1 for the response, i.e., all shares the > same response. > > > 2014-07-23 15:18 GMT-04:00 Thomas Broyer : > >> I hadn't realized the JSON response that requires the access_token field >> is defined per grant_type, so I'd be OK to "extend the semantics" as in = the >> current draft. >> That was actually my main concern: that the token endpoint mandates >> access_token; but its actually not the case. >> Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9crit= : >> >> I agree with John that overloading response_type @ authz endpoint is a >>> bad idea. It completely changes the semantics of this parameter. NOTE: = what >>> I was proposing was not this parameter, but a new parameter response_ty= pe @ >>> token endpoint. >>> >>> I also think overloading grant_type is a bad idea since it changes its >>> semantics. I quote the definition here again: >>> >>> grant >>> credential representing the resource owner's authorization >>> grant_type >>> type of grant sent to the token endpoint to obtain the access token >>> >>> It is not about controlling what is to be returned from the token >>> endpoint, but the hint to the token endpoint describing the type of >>> credential the endpoint has received. It seems the "control of what is >>> being returned from token endpoint" is just a side effect. >>> >>> I am somewhat ambivalent[1] in changing the semantics of token endpoint= , >>> but in as much as "text is the king" for a spec., we probably should no= t >>> change the semantics of it as Torsten points out. If it is ok to change >>> this semantics, I believe defining a new parameter to this endpoint to >>> control the response would be the best way to go. This is what I have >>> described previously. >>> >>> Defining a new endpoint to send code to get ID Token and forbidding the >>> use of it against token endpoint would not change the semantics of any >>> existing parameter or endpoint, which is good. However, I doubt if it i= s >>> not worth doing. What's the point of avoiding access token scoped to >>> UserInfo endpoint after all? Defining a new endpoint for just avoiding = the >>> access token for userinfo endpoint seems way too much the heavy wait wa= y >>> and it breaks interoperabiliy: it defeats the purpose of standardizatio= n. >>> >>> I have started feeling that no change is the best way out. >>> >>> Nat >>> >>> [1] If instead of saying "Token endpoint - used by the client to >>> exchange an authorization grant for an access token, typically with >>> client authentication", it were saying "Token endpoint - used by the >>> client to exchange an authorization grant for tokens, typically with >>> client authentication", then it would have been OK. It is an expansion = of >>> the capability rather than changing the semantics. >>> >>> >>> >>> 2014-07-23 13:39 GMT-04:00 Mike Jones : >>> >>>> You need the alternative response_type value (=E2=80=9Ccode_for_id_to= ken=E2=80=9D in >>>> the A4C draft) to tell the Authorization Server to return a code to be= used >>>> with the new grant type, rather than one to use with the >>>> =E2=80=9Cauthorization_code=E2=80=9D grant type (which is what respons= e_type=3Dcode does). >>>> >>>> >>>> >>>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John >>>> Bradley >>>> *Sent:* Wednesday, July 23, 2014 10:33 AM >>>> *To:* torsten@lodderstedt.net >>>> >>>> *Cc:* oauth@ietf.org >>>> *Subject:* Re: [OAUTH-WG] New Version Notification for >>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>> >>>> >>>> >>>> If we use the token endpoint then a new grant_type is the best way. >>>> >>>> >>>> >>>> It sort of overloads code, but that is better than messing with >>>> response_type for the authorization endpoint to change the response fr= om >>>> the token_endpoint. That is in my opinion a champion bad idea. >>>> >>>> >>>> >>>> In discussions developing Connect we decided not to open this can of >>>> worms because no good would come of it. >>>> >>>> >>>> >>>> The token_endpoint returns a access token. Nothing requires scope to >>>> be associates with the token. >>>> >>>> >>>> >>>> That is the best solution. No change required. Better >>>> interoperability in my opinion. >>>> >>>> >>>> >>>> Still on my way to TO, getting in later today. >>>> >>>> >>>> >>>> John B. >>>> >>>> >>>> >>>> >>>> >>>> Sent from my iPhone >>>> >>>> >>>> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >>>> >>>> The "response type" of the token endpoint is controlled by the value >>>> of the parameter "grant_type". So there is no need to introduce a new >>>> parameter. >>>> >>>> wrt to a potential "no_access_token" grant type. I do not consider thi= s >>>> a good idea as it changes the semantics of the token endpoint (as alre= ady >>>> pointed out by Thomas). This endpoint ALWAYS responds with an access t= oken >>>> to any grant type. I therefore would prefer to use another endpoint fo= r the >>>> intended purpose. >>>> >>>> regards, >>>> Torsten. >>>> >>>> >>>> >>>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>>> >>>> IMHO, changing the semantics of "response_type" @ authz endpoint this >>>> way is not a good thing. >>>> >>>> >>>> >>>> Instead, defining a new parameter "response_type" @ token endpoint, as >>>> I described in my previous message, >>>> >>>> probably is better. At least, it does not change the semantics of the >>>> parameters of RFC6749. >>>> >>>> >>>> >>>> Nat >>>> >>>> >>>> >>>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >>>> >>>> No, I mean response_type=3Dnone and response_type=3Did_token don't gen= erate >>>> a code or access token so you don't use the Token Endpoint (which is n= ot >>>> the same as the Authentication Endpoint BTW). >>>> >>>> With response_type=3Dcode_for_id_token, you get a code and exchange it >>>> for an id_token only, rather than an access_token, so you're changing = the >>>> semantics of the Token Endpoint. >>>> >>>> >>>> >>>> I'm not saying it's a bad thing, just that you can't really compare >>>> none and id_token with code_for_id_token. >>>> >>>> >>>> >>>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. >>>> wrote: >>>> >>>> It's only "not using the token endpoint" because the token endpoint >>>> copy-pasted and renamed the authentication endpoint. >>>> >>>> >>>> >>>> -- Justin >>>> >>>> >>>> >>>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: >>>> >>>> >>>> >>>> Except that these are about not using the Token Endpoint at all, >>>> whereas the current proposal is about the Token Endpoint not returning= an >>>> access_token field in the JSON. >>>> >>>> >>>> >>>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones < >>>> Michael.Jones@microsoft.com> wrote: >>>> >>>> The response_type "none" is already used in practice, which returns no >>>> access token. It was accepted by the designated experts and registere= d in >>>> the IANA OAuth Authorization Endpoint Response Types registry at >>>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#= endpoint. >>>> The registered "id_token" response type also returns no access token. >>>> >>>> >>>> >>>> So I think the question of whether response types that result in no >>>> access token being returned are acceptable within OAuth 2.0 is already >>>> settled, as a practical matter. Lots of OAuth implementations are alr= eady >>>> using such response types. >>>> >>>> >>>> >>>> -- Mike >>>> >>>> >>>> >>>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt >>>> *Sent:* Wednesday, July 23, 2014 7:09 AM >>>> *To:* Nat Sakimura >>>> *Cc:* >>>> *Subject:* Re: [OAUTH-WG] New Version Notification for >>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>> >>>> >>>> >>>> Yes. This is why it has to be discussed in the IETF. >>>> >>>> >>>> >>>> Phil >>>> >>>> >>>> >>>> @independentid >>>> >>>> www.independentid.com >>>> >>>> phil.hunt@oracle.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: >>>> >>>> >>>> >>>> Reading back the RFC6749, I am not sure if there is a good way of >>>> suppressing access token from the response and still be OAuth. It will >>>> break whole bunch of implicit definitions like: >>>> >>>> >>>> >>>> authorization server >>>> The server issuing access tokens to the client after successfull= y >>>> authenticating the resource owner and obtaining authorization. >>>> >>>> >>>> >>>> After all, OAuth is all about issuing access tokens. >>>> >>>> >>>> >>>> Also, I take back my statement on the grant type in my previous mail. >>>> >>>> >>>> >>>> The definition of grant and grant_type are respectively: >>>> >>>> >>>> >>>> grant >>>> >>>> credential representing the resource owner's authorization >>>> >>>> >>>> >>>> grant_type >>>> >>>> (string representing the) type of grant sent to the token endpoint >>>> to obtain the access token >>>> >>>> >>>> >>>> Thus, the grant sent to the token endpoint in this case is still >>>> 'code'. >>>> >>>> >>>> >>>> Response type on the other hand is not so well defined in RFC6749, but >>>> it seems it is representing what is to be returned from the authorizat= ion >>>> endpoint. To express what is to be returned from token endpoint, perha= ps >>>> defining a new parameter to the token endpoint, which is a parallel to= the >>>> response_type to the Authorization Endpoint seems to be a more symmetr= ic >>>> way, though I am not sure at all if that is going to be OAuth any more= . One >>>> straw-man is to define a new parameter called response_type to the tok= en >>>> endpoint such as: >>>> >>>> >>>> >>>> response_type >>>> >>>> OPTIONAL. A string representing what is to be returned from the >>>> token endpoint. >>>> >>>> >>>> >>>> Then define the behavior of the endpoint according to the values as th= e >>>> parallel to the multi-response type spec. >>>> >>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>> >>>> >>>> >>>> Nat >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>>> >>>> The draft is very clear. >>>> >>>> Phil >>>> >>>> >>>> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >>>> >>>> The new grant type that I was talking about was >>>> >>>> "authorization_code_but_do_not_return_access_nor_refresh_token", so to >>>> speak. >>>> >>>> It does not return anything per se, but an extension can define >>>> something on top of it. >>>> >>>> >>>> >>>> Then, OIDC can define a binding to it so that the binding only returns >>>> ID Token. >>>> >>>> This binding work should be done in OIDF. Should there be such a grant >>>> type, >>>> >>>> it will be an extremely short spec. >>>> >>>> >>>> >>>> At the same time, if any other specification wanted to define >>>> >>>> other type of tokens and have it returned from the token endpoint, >>>> >>>> it can also use this grant type. >>>> >>>> >>>> >>>> If what you want is to define a new grant type that returns ID Token >>>> only, >>>> >>>> then, I am with Justin. Since "other response than ID Token" is only >>>> >>>> theoretical, this is a more plausible way forward, I suppose. >>>> >>>> >>>> >>>> Nat >>>> >>>> >>>> >>>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>>> >>>> So the draft would literally turn into: >>>> >>>> "The a4c response type and grant type return an id_token from the toke= n >>>> endpoint with no access token. All parameters and values are defined i= n >>>> OIDC." >>>> >>>> Seems like the perfect mini extension draft for OIDF to do. >>>> >>>> --Justin >>>> >>>> /sent from my phone/ >>>> >>>> >>>> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >>>> > >>>> > What about just defining a new grant type in this WG? >>>> > >>>> > >>>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>>> >> >>>> >> That would be nice. However oidc still needs the new grant type in >>>> order to implement the same flow. >>>> >> >>>> >> Phil >>>> >> >>>> >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: >>>> >> >>>> >>> +1 to Justin. >>>> >>> >>>> >>> >>>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >>>> >>>> >>>> >>>> Errors like these make it clear to me that it would make much mor= e >>>> sense to develop this document in the OpenID Foundation. It should be >>>> something that directly references OpenID Connect Core for all of thes= e >>>> terms instead of redefining them. It's doing authentication, which is >>>> fundamentally what OpenID Connect does on top of OAuth, and I don't se= e a >>>> good argument for doing this work in this working group. >>>> >>>> >>>> >>>> -- Justin >>>> >>>> >>>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer >>>> wrote: >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < >>>> Michael.Jones@microsoft.com> wrote: >>>> >>>>>> >>>> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" definit= ion >>>> being missing is an editorial error. It should be: >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> consent >>>> >>>>>> >>>> >>>>>> The Authorization Server SHOULD prompt the End-User for consent >>>> before returning information to the Client. If it cannot obtain consen= t, it >>>> MUST return an error, typically consent_required. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> I'll plan to add it in the next draft. >>>> >>>>> >>>> >>>>> >>>> >>>>> It looks like the consent_required error needs to be defined too= , >>>> and you might have forgotten to also import account_selection_required= from >>>> OpenID Connect. >>>> >>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> I agree that there's no difference between a response with >>>> multiple "amr" values that includes "mfa" and one that doesn't. Unles= s a >>>> clear use case for why "mfa" is needed can be identified, we can delet= e it >>>> in the next draft. >>>> >>>>> >>>> >>>>> >>>> >>>>> Thanks. >>>> >>>>> >>>> >>>>> How about "pwd" then? I fully understand that I should return >>>> "pwd" if the user authenticated using a password, but what "the servic= e if >>>> a client secret is used" means in the definition for the "pwd" value? >>>> >>>>> >>>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come >>>> back ;-) ) >>>> >>>>> >>>> >>>>> -- >>>> >>>>> Thomas Broyer >>>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>> >>>>> _______________________________________________ >>>> >>>>> 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 >>>> >>>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> Nat Sakimura (=3Dnat) >>>> >>> Chairman, OpenID Foundation >>>> >>> http://nat.sakimura.org/ >>>> >>> @_nat_en >>>> >>> >>>> >>> _______________________________________________ >>>> >>> OAuth mailing list >>>> >>> OAuth@ietf.org >>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Nat Sakimura (=3Dnat) >>>> > Chairman, OpenID Foundation >>>> > http://nat.sakimura.org/ >>>> > @_nat_en >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=3Dnat) >>>> >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=3Dnat) >>>> >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Thomas Broyer >>>> /t=C9=94.ma.b=CA=81wa.je/ >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Thomas Broyer >>>> /t=C9=94.ma.b=CA=81wa.je/ >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=3Dnat) >>>> >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > --001a113431645ed7a704fee187a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Is it said anywhere that ALL grant types MUST use Section 5.= 1 responses? Each grant type references Section 5.1, and "access token= request" is only defined in the context of the defined grant types. S= ection 2.2 doesn't talk about the request or response format.

Le 23 juil. 2014 21:32, "Nat Sakimura"= <sakimura@gmail.com> a =C3= =A9crit :
Is it? Apart from the implicit grant that does not use tok= en endpoint, all other grant references section 5.1 for the response, i.e.,= all shares the same response.=C2=A0

2014-07-23 15:18 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:

I hadn't realized the JSON response that requires the ac= cess_token field is defined per grant_type, so I'd be OK to "exten= d the semantics" as in the current draft.
That was actually my main concern: that the token endpoint mandates access_= token; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura"= <sakimura@gmail= .com> a =C3=A9crit :

I agree with John that overloading response_type @ au= thz endpoint is a bad idea. It completely changes the semantics of this par= ameter. NOTE: what I was proposing was not this parameter, but a new parame= ter response_type @ token endpoint.=C2=A0

I also think overloading grant_type is a bad idea since= it changes its semantics. I quote the definition here again:=C2=A0

grant=C2=A0
=C2=A0 =C2=A0 credential repre= senting the resource owner's authorization
grant_type
type of grant sent to t= he token endpoint to obtain the access token

It is not about controlling what is to be returned from the token endp= oint, but the hint to the token endpoint describing the type of credential = the endpoint has received. It seems the "control of what is being retu= rned from token endpoint" =C2=A0is just a side effect.=C2=A0

I am somewhat ambivalent[1] in changing the semantics o= f token endpoint, but in as much as "text is the king" for a spec= ., we probably should not change the semantics of it as Torsten points out.= If it is ok to change this semantics, I believe defining a new parameter t= o this endpoint to control the response would be the best way to go. This i= s what I have described previously.=C2=A0

Defining a new endpoint to send code to get ID Token an= d forbidding the use of it against token endpoint would not change the sema= ntics of any existing parameter or endpoint, which is good. However, I doub= t if it is not worth doing. What's the point of avoiding access token s= coped to UserInfo endpoint after all? Defining a new endpoint for just avoi= ding the access token for userinfo endpoint seems way too much the heavy wa= it way and it breaks interoperabiliy: it defeats the purpose of standardiza= tion.=C2=A0

I have started feeling that no change is the best way o= ut.=C2=A0

Nat
=C2=A0
[1] = =C2=A0If instead of saying "Token endpoint - used by the client to exchange an authorization=C2=A0= grant for an access token, typically with client authentication"= ;, it were saying "Toke= n endpoint - used by the client to exchange an authorization=C2=A0gr= ant for tokens, typically with client authentication", then it would h= ave been OK. It is an expansion of the capability rather than changing the = semantics.



2014-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@mic= rosoft.com>:

You need the alternative = response_type value (=E2=80=9Ccode_for_id_token=E2=80=9D in the A4C draft) to tell the Authorization Server to return a code to be = used with the new grant type, rather than one to use with the =E2=80=9Cauth= orization_code=E2=80=9D grant type (which is what response_type=3Dcode does= ).

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: tor= sten@lodderstedt.net


Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oaut= h-v2-user-a4c-05.txt

=C2=A0

If we use the token endpoint then a new grant_type i= s the best way.=C2=A0

=C2=A0

It sort of overloads code, but that is better than m= essing with response_type for the authorization endpoint to change the resp= onse from the token_endpoint. =C2=A0That is in my opinion a champion bad id= ea.=C2=A0

=C2=A0

In discussions developing Connect we decided not to = open this can of worms because no good would come of it. =C2=A0=C2=A0

=C2=A0

The token_endpoint returns a access token. =C2=A0Not= hing requires scope to be associates with the token.=C2=A0

=C2=A0

That is the best solution. =C2=A0No change required.= =C2=A0Better interoperability in my opinion.=C2=A0

=C2=A0

Still on my way to TO, getting in later today.=C2=A0=

=C2=A0

John B.=C2=A0

=C2=A0



Sent from my iPhone


On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the= value of the parameter "grant_type". So there is no need to intr= oduce a new parameter.

wrt to a potential "no_access_token" grant type. I do not cons= ider this a good idea as it changes the semantics of the token endpoint (as= already pointed out by Thomas). This endpoint ALWAYS responds with an acce= ss token to any grant type. I therefore would prefer to use another endpoint for the intended purpose.

regards,
Torsten.

=C2=A0

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type&= quot; @ authz endpoint this way is not a good thing.=C2=A0

=C2=A0

Instead, defining a new parameter "response_typ= e" @ token endpoint, as I described in my previous message,=C2=A0

probably is better. At least, it does not change the= semantics of the parameters of RFC6749.=C2=A0

=C2=A0

=C2=A0Nat=C2=A0

=C2=A0<= /p>

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>= :

No, I mean response_type=3Dnone and response_type=3D= id_token don't generate a code or access token so you don't use the= Token Endpoint (which is not the same as the Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you get a co= de and exchange it for an id_token only, rather than an access_token, so yo= u're changing the semantics of the Token Endpoint.

=C2=A0

I'm not saying it's a bad thing, just that y= ou can't really compare none and id_token with code_for_id_token.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It's only "not using the token endpoint&quo= t; because the token endpoint copy-pasted and renamed the authentication en= dpoint.

=C2=A0

=C2=A0-- Justin

=C2=A0

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com&g= t; wrote:



Except that these are about not using the Token Endp= oint at all, whereas the current proposal is about the Token Endpoint not r= eturning an access_token field in the JSON.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

The response_type "n= one" is already used in practice, which returns no access token.=C2=A0= It was accepted by the designated experts and registered in the IANA OAuth Authorization E= ndpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpo= int.=C2=A0 The registered "id_token" response type also retur= ns no access token.

=C2=A0

So I think the question o= f whether response types that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical matter.=C2= =A0 Lots of OAuth implementations are already using such response types.

=C2=A0

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for dra= ft-hunt-oauth-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

Phil

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

=C2=A0<= /p>

Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client after s= uccessfully
=C2=A0 =C2=A0 =C2=A0 authenticating the resource owner and obtaining author= ization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token<= /p>

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the t= oken endpoint, which is a parallel to the response_type to the Authorizatio= n Endpoint seems to be a more symmetric way, though I am not sure at all if= that is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the tok= en endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0<= u>

=C2=A0

Nat

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0<= /u>

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0=

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat

=C2=A0<= /p>

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of = OAuth, and I don't see a good argument for doing this work in this work= ing group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wro= te:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The "pr= ompt=3Dconsent" definition being missing is an editorial error.=C2=A0 = It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I'll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there's no difference between a r= esponse with multiple "amr" values that includes "mfa" = and one that doesn't.=C2=A0 Unless a clear use case for why "mfa&q= uot; is needed can be identified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0


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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/

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



=C2=A0

--
Thomas Broyer
/t=C9= =94.ma.b=CA=81wa.je/


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

=C2=A0

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


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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




--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a113431645ed7a704fee187a8-- From nobody Wed Jul 23 13:01:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794051A01D9 for ; Wed, 23 Jul 2014 13:01:26 -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 q0r0B9SSDl9g for ; Wed, 23 Jul 2014 13:01:24 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9410C1A03BB for ; Wed, 23 Jul 2014 13:01:21 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so8434744wib.14 for ; Wed, 23 Jul 2014 13:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=V50VUAZLU6KIdjB5Px5xghB9YwvH3mMehpwmpn7M67w=; b=Km99NtL19XpZVYJXR9Fcux+A7Ewz/zU+NCAnEoddewAnW78ZSo3IIP8DtKo83phx8v 6ouyy7tnnN0bN/cDWEyKQQRtQ3AKJ4SII0EPvNUuzall171z0B93Swq6dY8S/pnz3FyX VhEwUnebaROPyhnZE4BTE8QJTaEzF+wxv0dkW0OjrHZWpZ10DKhKmlWKFee8KT4/BdUS zmHXXUg2Gd+kjglOc4FZEuLL/9A3FFZe6Glfjz2hOlmoKQAke45OOvAsNDEGayYvYsPB R2gBMBRbZP7GgBNSGjxI7B8JP8H4SfduCBD3Q26uxk8rykr6cF8xvnElSbBjBVjKLx5H L7Vw== X-Received: by 10.194.20.230 with SMTP id q6mr5136114wje.43.1406145680081; Wed, 23 Jul 2014 13:01:20 -0700 (PDT) Received: from [10.39.0.31] ([87.252.227.100]) by mx.google.com with ESMTPSA id 20sm8951688wjt.42.2014.07.23.13.01.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 13:01:19 -0700 (PDT) Message-ID: <53D0148B.4090206@gmail.com> Date: Wed, 23 Jul 2014 23:01:15 +0300 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: oauth@ietf.org References: <00e001cfa69b$8f7b7c10$ae727430$@viewds.com> In-Reply-To: <00e001cfa69b$8f7b7c10$ae727430$@viewds.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jKp-7bQ1Vf1H1VRq03yTW6lwIg8 Subject: Re: [OAUTH-WG] Please help me understand OAuth 2.0 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, 23 Jul 2014 20:01:26 -0000 Hi, On 23/07/14 20:28, Gil Kirkpatrick wrote: > The RFCs 6749 and 6750 are a good place to start. > http://tools.ietf.org/html/rfc6749 and http://tools.ietf.org/html/rfc6750. > > The first thing to understand is that OAuth2 targets a very specific use > case of a user authorizing an application (like Twitter) access to > resources they own (like photos) through a resource server (like > Facebook). It’s more an authN/authZ framework than a complete system, > and doesn’t directly address the traditional enterprise use cases. Once > you get your head around that, the rest is pretty straightforward. IMHO OAuth2 is becoming much bigger... Take the client credentials grant. People are using it today in the traditional scenarios, because OAuth2 tokens have good security properties. Cheers, Sergey > Because it’s lightweight and thin, OAuth2 can be used in lots of > authN/authZ scenarios, for instance OpenID Connect > http://openid.net/connect/ and UMA > http://docs.kantarainitiative.org/uma/draft-uma-core.html. > > You’d be best off clearing your mind of SAML concepts and reading the > RFCs, but to answer your questions: > > 1.Not really. Access tokens represent a user-granted authorization for a > specific application to access a specific resource scope. The semantics > of a scopes are left to the developer, but you can think of a scope as a > representation of what access(es) are allowed to what resource(s). There > is no user identity information necessarily conveyed in the access > token… that is what OpenID Connect is for. OpenID Connect maps pretty > closely to SAML. > > 2.Sort of. When the resource owner grants access, the AS issues an > authorization grant code. The client then presents the grant code to the > AS for an access token. The client includes the access token with each > resource request, and the resource server uses the scope in the token to > determine if access should be granted or not. > > 3.The role of the PDP is split between the AS and the RS. The AS > provides a token representing the user’s consent to access of a > particular scope, and the RS interprets the scope to grant access. The > scope _/could/_ just be a Boolean value indicating that access is > allowed or not, in which case the AS would be a PDP, but in practice the > scope encodes a set of permissions that the RS interprets in the context > of the specific resource request. > > HTH, > > -gil > > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Richard Snowden > *Sent:* Wednesday, 23 July 2014 2:57 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Please help me understand OAuth 2.0 > > I am pretty familiar with the WS-* and SOAP Web Services world. At the > moment I'm trying to understand which features are available in the > OAuth 2.0 world. > > 1) SAML tokens: This access token in OAuth 2.0 - is it similar to what > SAML tokens are for? > > 2) STS: Is an OAuth 2.0 Authorization Server the equivalent to a STS? > > 3) PDP (Policy Decision Point): Is this also handled by the OAuth 2.0 > Authorization Server? Or does the Resource Server, based on the access > token, have to make the decision whether or not grant access to a resource? > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Wed Jul 23 13:04:25 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819C11A0338 for ; Wed, 23 Jul 2014 13:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BudHkAO2v5ia for ; Wed, 23 Jul 2014 13:04:19 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037B41A00B7 for ; Wed, 23 Jul 2014 13:04:19 -0700 (PDT) Received: from [31.133.166.94] by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1XA2lq-0001cX-PO; Wed, 23 Jul 2014 22:04:16 +0200 References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-746A924C-C8BA-4FF2-BAA9-7E0E9EA62871 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (11D257) From: Torsten Lodderstedt Date: Wed, 23 Jul 2014 16:04:12 -0400 To: Thomas Broyer X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/dKaKdh8qMf2KHIl0kfVOvW4Frtc Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 20:04:23 -0000 --Apple-Mail-746A924C-C8BA-4FF2-BAA9-7E0E9EA62871 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable You are right from a theoretical perspective. Practically this was caused by= editorial decisions during the creation of the RFC. As far as I remember, t= here was a definition of the (one) token endpoint response in early versions= . No one every considered to NOT respond with an access token from the token= endpoint. So one might call it an implicit assumption. I'm worried that people get totally confused if an exception is introduced n= ow given the broad adoption of OAuth based on this assumption. regards, Torsten. > Am 23.07.2014 um 15:41 schrieb Thomas Broyer : >=20 > Is it said anywhere that ALL grant types MUST use Section 5.1 responses? E= ach grant type references Section 5.1, and "access token request" is only de= fined in the context of the defined grant types. Section 2.2 doesn't talk ab= out the request or response format. >=20 > Le 23 juil. 2014 21:32, "Nat Sakimura" a =C3=A9crit := >> Is it? Apart from the implicit grant that does not use token endpoint, al= l other grant references section 5.1 for the response, i.e., all shares the s= ame response.=20 >>=20 >>=20 >> 2014-07-23 15:18 GMT-04:00 Thomas Broyer : >>> I hadn't realized the JSON response that requires the access_token field= is defined per grant_type, so I'd be OK to "extend the semantics" as in the= current draft. >>> That was actually my main concern: that the token endpoint mandates acce= ss_token; but its actually not the case. >>>=20 >>> Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9crit= : >>>=20 >>>> I agree with John that overloading response_type @ authz endpoint is a b= ad idea. It completely changes the semantics of this parameter. NOTE: what I= was proposing was not this parameter, but a new parameter response_type @ t= oken endpoint.=20 >>>>=20 >>>> I also think overloading grant_type is a bad idea since it changes its s= emantics. I quote the definition here again:=20 >>>>=20 >>>> grant=20 >>>> credential representing the resource owner's authorization >>>> =09 >>>> grant_type >>>> type of grant sent to the token endpoint to obtain the access token= >>>>=20 >>>> It is not about controlling what is to be returned from the token endpo= int, but the hint to the token endpoint describing the type of credential th= e endpoint has received. It seems the "control of what is being returned fro= m token endpoint" is just a side effect.=20 >>>>=20 >>>> I am somewhat ambivalent[1] in changing the semantics of token endpoint= , but in as much as "text is the king" for a spec., we probably should not c= hange the semantics of it as Torsten points out. If it is ok to change this s= emantics, I believe defining a new parameter to this endpoint to control the= response would be the best way to go. This is what I have described previou= sly.=20 >>>>=20 >>>> Defining a new endpoint to send code to get ID Token and forbidding the= use of it against token endpoint would not change the semantics of any exis= ting parameter or endpoint, which is good. However, I doubt if it is not wor= th doing. What's the point of avoiding access token scoped to UserInfo endpo= int after all? Defining a new endpoint for just avoiding the access token fo= r userinfo endpoint seems way too much the heavy wait way and it breaks inte= roperabiliy: it defeats the purpose of standardization.=20 >>>>=20 >>>> I have started feeling that no change is the best way out.=20 >>>>=20 >>>> Nat >>>> =20 >>>> [1] If instead of saying "Token endpoint - used by the client to excha= nge an authorization grant for an access token, typically with client authen= tication", it were saying "Token endpoint - used by the client to exchange a= n authorization grant for tokens, typically with client authentication", the= n it would have been OK. It is an expansion of the capability rather than ch= anging the semantics. >>>>=20 >>>>=20 >>>>=20 >>>> 2014-07-23 13:39 GMT-04:00 Mike Jones : >>>>> You need the alternative response_type value (=E2=80=9Ccode_for_id_tok= en=E2=80=9D in the A4C draft) to tell the Authorization Server to return a c= ode to be used with the new grant type, rather than one to use with the =E2=80= =9Cauthorization_code=E2=80=9D grant type (which is what response_type=3Dcod= e does). >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley >>>>> Sent: Wednesday, July 23, 2014 10:33 AM >>>>> To: torsten@lodderstedt.net >>>>>=20 >>>>>=20 >>>>> Cc: oauth@ietf.org >>>>> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-= v2-user-a4c-05.txt >>>>> =20 >>>>>=20 >>>>> If we use the token endpoint then a new grant_type is the best way.=20= >>>>>=20 >>>>> =20 >>>>>=20 >>>>> It sort of overloads code, but that is better than messing with respon= se_type for the authorization endpoint to change the response from the token= _endpoint. That is in my opinion a champion bad idea.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> In discussions developing Connect we decided not to open this can of w= orms because no good would come of it. =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The token_endpoint returns a access token. Nothing requires scope to b= e associates with the token.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> That is the best solution. No change required. Better interoperabili= ty in my opinion.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Still on my way to TO, getting in later today.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> John B.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>=20 >>>>> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >>>>>=20 >>>>> The "response type" of the token endpoint is controlled by the value o= f the parameter "grant_type". So there is no need to introduce a new paramet= er. >>>>>=20 >>>>> wrt to a potential "no_access_token" grant type. I do not consider thi= s a good idea as it changes the semantics of the token endpoint (as already p= ointed out by Thomas). This endpoint ALWAYS responds with an access token to= any grant type. I therefore would prefer to use another endpoint for the in= tended purpose. >>>>>=20 >>>>> regards, >>>>> Torsten. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>>>>=20 >>>>> IMHO, changing the semantics of "response_type" @ authz endpoint this w= ay is not a good thing.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Instead, defining a new parameter "response_type" @ token endpoint, as= I described in my previous message,=20 >>>>>=20 >>>>> probably is better. At least, it does not change the semantics of the p= arameters of RFC6749.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Nat=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >>>>>=20 >>>>> No, I mean response_type=3Dnone and response_type=3Did_token don't gen= erate a code or access token so you don't use the Token Endpoint (which is n= ot the same as the Authentication Endpoint BTW). >>>>>=20 >>>>> With response_type=3Dcode_for_id_token, you get a code and exchange it= for an id_token only, rather than an access_token, so you're changing the s= emantics of the Token Endpoint. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I'm not saying it's a bad thing, just that you can't really compare no= ne and id_token with code_for_id_token. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. = wrote: >>>>>=20 >>>>> It's only "not using the token endpoint" because the token endpoint co= py-pasted and renamed the authentication endpoint. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote:= >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Except that these are about not using the Token Endpoint at all, where= as the current proposal is about the Token Endpoint not returning an access_= token field in the JSON. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones wrote: >>>>>=20 >>>>> The response_type "none" is already used in practice, which returns no= access token. It was accepted by the designated experts and registered in t= he IANA OAuth Authorization Endpoint Response Types registry at http://www.i= ana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint. The reg= istered "id_token" response type also returns no access token. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> So I think the question of whether response types that result in no ac= cess token being returned are acceptable within OAuth 2.0 is already settled= , as a practical matter. Lots of OAuth implementations are already using su= ch response types. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt >>>>> Sent: Wednesday, July 23, 2014 7:09 AM >>>>> To: Nat Sakimura >>>>> Cc: >>>>> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-= v2-user-a4c-05.txt >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Yes. This is why it has to be discussed in the IETF. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> =20 >>>>>=20 >>>>> @independentid >>>>>=20 >>>>> www.independentid.com >>>>>=20 >>>>> phil.hunt@oracle.com >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Reading back the RFC6749, I am not sure if there is a good way of supp= ressing access token from the response and still be OAuth. It will break who= le bunch of implicit definitions like:=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> authorization server >>>>> The server issuing access tokens to the client after successfull= y >>>>> authenticating the resource owner and obtaining authorization. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> After all, OAuth is all about issuing access tokens.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Also, I take back my statement on the grant type in my previous mail.=20= >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The definition of grant and grant_type are respectively:=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> grant=20 >>>>>=20 >>>>> credential representing the resource owner's authorization >>>>>=20 >>>>> =20 >>>>>=20 >>>>> grant_type >>>>>=20 >>>>> (string representing the) type of grant sent to the token endpoint= to obtain the access token >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Thus, the grant sent to the token endpoint in this case is still 'code= '.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Response type on the other hand is not so well defined in RFC6749, but= it seems it is representing what is to be returned from the authorization e= ndpoint. To express what is to be returned from token endpoint, perhaps defi= ning a new parameter to the token endpoint, which is a parallel to the respo= nse_type to the Authorization Endpoint seems to be a more symmetric way, tho= ugh I am not sure at all if that is going to be OAuth any more. One straw-ma= n is to define a new parameter called response_type to the token endpoint su= ch as:=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> response_type >>>>>=20 >>>>> OPTIONAL. A string representing what is to be returned from the to= ken endpoint.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Then define the behavior of the endpoint according to the values as th= e parallel to the multi-response type spec.=20 >>>>>=20 >>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Nat >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>>>>=20 >>>>> The draft is very clear.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>>=20 >>>>> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >>>>>=20 >>>>> The new grant type that I was talking about was=20 >>>>>=20 >>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", so to= speak.=20 >>>>>=20 >>>>> It does not return anything per se, but an extension can define someth= ing on top of it.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Then, OIDC can define a binding to it so that the binding only returns= ID Token.=20 >>>>>=20 >>>>> This binding work should be done in OIDF. Should there be such a grant= type,=20 >>>>>=20 >>>>> it will be an extremely short spec.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> At the same time, if any other specification wanted to define=20 >>>>>=20 >>>>> other type of tokens and have it returned from the token endpoint,=20 >>>>>=20 >>>>> it can also use this grant type.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> If what you want is to define a new grant type that returns ID Token o= nly,=20 >>>>>=20 >>>>> then, I am with Justin. Since "other response than ID Token" is only=20= >>>>>=20 >>>>> theoretical, this is a more plausible way forward, I suppose.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Nat >>>>>=20 >>>>> =20 >>>>>=20 >>>>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>>>>=20 >>>>> So the draft would literally turn into: >>>>>=20 >>>>> "The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in OI= DC." >>>>>=20 >>>>> Seems like the perfect mini extension draft for OIDF to do. >>>>>=20 >>>>> --Justin >>>>>=20 >>>>> /sent from my phone/ >>>>>=20 >>>>>=20 >>>>> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >>>>> > >>>>> > What about just defining a new grant type in this WG? >>>>> > >>>>> > >>>>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>>>> >> >>>>> >> That would be nice. However oidc still needs the new grant type in o= rder to implement the same flow.=20 >>>>> >> >>>>> >> Phil >>>>> >> >>>>> >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote:= >>>>> >> >>>>> >>> +1 to Justin.=20 >>>>> >>> >>>>> >>> >>>>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >>>>> >>>> >>>>> >>>> Errors like these make it clear to me that it would make much mor= e sense to develop this document in the OpenID Foundation. It should be some= thing that directly references OpenID Connect Core for all of these terms in= stead of redefining them. It's doing authentication, which is fundamentally w= hat OpenID Connect does on top of OAuth, and I don't see a good argument for= doing this work in this working group. >>>>> >>>> >>>>> >>>> -- Justin >>>>> >>>> >>>>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer w= rote: >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones wrote: >>>>> >>>>>> >>>>> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" definit= ion being missing is an editorial error. It should be: >>>>> >>>>>> >>>>> >>>>>> =20 >>>>> >>>>>> >>>>> >>>>>> consent >>>>> >>>>>> >>>>> >>>>>> The Authorization Server SHOULD prompt the End-User for consent= before returning information to the Client. If it cannot obtain consent, it= MUST return an error, typically consent_required. >>>>> >>>>>> >>>>> >>>>>> =20 >>>>> >>>>>> >>>>> >>>>>> I'll plan to add it in the next draft. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> It looks like the consent_required error needs to be defined too= , and you might have forgotten to also import account_selection_required fro= m OpenID Connect. >>>>> >>>>> =20 >>>>> >>>>>> >>>>> >>>>>> =20 >>>>> >>>>>> >>>>> >>>>>> I agree that there's no difference between a response with mult= iple "amr" values that includes "mfa" and one that doesn't. Unless a clear u= se case for why "mfa" is needed can be identified, we can delete it in the n= ext draft. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> How about "pwd" then? I fully understand that I should return "p= wd" if the user authenticated using a password, but what "the service if a c= lient secret is used" means in the definition for the "pwd" value? >>>>> >>>>> >>>>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come= back ;-) ) >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thomas Broyer >>>>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>> >>>>> _______________________________________________ >>>>> >>>>> 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 >>>>> >>>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> -- >>>>> >>> Nat Sakimura (=3Dnat) >>>>> >>> Chairman, OpenID Foundation >>>>> >>> http://nat.sakimura.org/ >>>>> >>> @_nat_en >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> OAuth mailing list >>>>> >>> OAuth@ietf.org >>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Nat Sakimura (=3Dnat) >>>>> > Chairman, OpenID Foundation >>>>> > http://nat.sakimura.org/ >>>>> > @_nat_en >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>>=20 >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>>=20 >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> --=20 >>>>> Thomas Broyer >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> --=20 >>>>> Thomas Broyer >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>>=20 >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>> =20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-746A924C-C8BA-4FF2-BAA9-7E0E9EA62871 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You are right from a theoretical persp= ective. Practically this was caused by editorial decisions during the creati= on of the RFC. As far as I remember, there was a definition of the (one) tok= en endpoint response in early versions. No one every considered to NOT respo= nd with an access token from the token endpoint. So one might call it an imp= licit assumption.

I'm worried that people get total= ly confused if an exception is introduced now given the broad adoption of OA= uth based on this assumption.

regards,
To= rsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

Is it said anywhere that ALL gran= t types MUST use Section 5.1 responses? Each grant type references Section 5= .1, and "access token request" is only defined in the context of the defined= grant types. Section 2.2 doesn't talk about the request or response format.=

Le 23 juil. 2014 21:32, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit :
Is it? Apart from the implicit grant that does not use toke= n endpoint, all other grant references section 5.1 for the response, i.e., a= ll shares the same response. 


<= div class=3D"gmail_quote"> 2014-07-23 15:18 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>= :

I hadn't realized the JSON response that requires the access_= token field is defined per grant_type, so I'd be OK to "extend the semantics= " as in the current draft.
That was actually my main concern: that the token endpoint mandates access_t= oken; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura" <sakimura@gmail.com>= a =C3=A9crit :

I agree with John that overloading response_type @ aut= hz endpoint is a bad idea. It completely changes the semantics of this param= eter. NOTE: what I was proposing was not this parameter, but a new parameter= response_type @ token endpoint. 

I also think overloading grant_type is a bad idea since i= t changes its semantics. I quote the definition here again: 
=
grant 
    credential represent= ing the resource owner's authorization
grant_typ= e
type of gran= t sent to the token endpoint to obtain the access token

=
It is not about controlling what is to be returned from the token endpo= int, but the hint to the token endpoint describing the type of credential th= e endpoint has received. It seems the "control of what is being returned fro= m token endpoint"  is just a side effect. 

I am somewhat ambivalent[1] in changing the semantics of= token endpoint, but in as much as "text is the king" for a spec., we probab= ly should not change the semantics of it as Torsten points out. If it is ok t= o change this semantics, I believe defining a new parameter to this endpoint= to control the response would be the best way to go. This is what I have de= scribed previously. 

Defining a new endpoint to send code to get ID Token and= forbidding the use of it against token endpoint would not change the semant= ics of any existing parameter or endpoint, which is good. However, I doubt i= f it is not worth doing. What's the point of avoiding access token scoped to= UserInfo endpoint after all? Defining a new endpoint for just avoiding the a= ccess token for userinfo endpoint seems way too much the heavy wait way and i= t breaks interoperabiliy: it defeats the purpose of standardization. 

I have started feeling that no change is the best way ou= t. 

Nat
 
[1] &nb= sp;If instead of saying "Toke= n endpoint - used by the client to exchange an authorization gra= nt for an access token, typically with client authentication", it were sayin= g "Token endpoint - used by t= he client to exchange an authorization grant for tokens, typical= ly with client authentication", then it would have been OK. It is an expansi= on of the capability rather than changing the semantics.



2014-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@microso= ft.com>:

You need the alternative re= sponse_type value (=E2=80=9Ccode_for_id_token=E2=80=9D in the A4C draft) to tell the Authorization Server to return a code to be u= sed with the new grant type, rather than one to use with the =E2=80=9Cauthor= ization_code=E2=80=9D grant type (which is what response_type=3Dcode does).<= u>

 =

From: OAuth [mail= to:oauth-bounces= @ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: tors= ten@lodderstedt.net


Cc: oauth@ietf.or= g
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth= -v2-user-a4c-05.txt

 

If we use the token endpoint then a new grant_type is= the best way. 

 

It sort of overloads code, but that is better than me= ssing with response_type for the authorization endpoint to change the respon= se from the token_endpoint.  That is in my opinion a champion bad idea.=  

 

In discussions developing Connect we decided not to o= pen this can of worms because no good would come of it.   <= u>

 

The token_endpoint returns a access token.  Noth= ing requires scope to be associates with the token. 

 

That is the best solution.  No change required. &= nbsp;Better interoperability in my opinion. 

 

Still on my way to TO, getting in later today. <= u>

 

John B. 

 



Sent from my iPhone


On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the value of t= he parameter "grant_type". So there is no need to introduce a new parameter.=

wrt to a potential "no_access_token" grant type. I do not consider this a= good idea as it changes the semantics of the token endpoint (as already poi= nted out by Thomas). This endpoint ALWAYS responds with an access token to a= ny grant type. I therefore would prefer to use another endpoint for the intended purpose.

regards,
Torsten.

 

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type" @ aut= hz endpoint this way is not a good thing. 

 

Instead, defining a new parameter "response_type" @ t= oken endpoint, as I described in my previous message, 

probably is better. At least, it does not change the s= emantics of the parameters of RFC6749. 

 

 Nat 

 

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:=

No, I mean response_type=3Dnone and response_type=3Di= d_token don't generate a code or access token so you don't use the Token End= point (which is not the same as the Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you get a cod= e and exchange it for an id_token only, rather than an access_token, so you'= re changing the semantics of the Token Endpoint.

 

I'm not saying it's a bad thing, just that you can't r= eally compare none and id_token with code_for_id_token.

 

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. &l= t;jricher@mitre.org> wrote:

It's only "not using the token endpoint" because the t= oken endpoint copy-pasted and renamed the authentication endpoint.

 

 -- Justin

 



Except that these are about not using the Token Endpo= int at all, whereas the current proposal is about the Token Endpoint not ret= urning an access_token field in the JSON.

 

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@mi= crosoft.com> wrote:

The response_type "none" is= already used in practice, which returns no access token.  It was accep= ted by the designated experts and registered in the IANA OAuth Authorization En= dpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoi= nt.  The registered "id_token" response type also returns no access= token.

 =

So I think the question of w= hether response types that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical matter. = ; Lots of OAuth implementations are already using such response types.

 =

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

 =

From: OA= uth [mailto:oaut= h-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for draft= -hunt-oauth-v2-user-a4c-05.txt

 

Yes. This is why it has to be discussed in the IETF.<= u>

 

 

 

 

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com> w= rote:

 

Reading back the RFC6749, I am not sure if there is a= good way of suppressing access token from the response and still be OAuth. I= t will break whole bunch of implicit definitions like: 

 

authorization server
      The server issuing access tokens to the client after su= ccessfully
      authenticating the resource owner and obtaining authori= zation.

 

After all, OAuth is all about issuing access tokens.&= nbsp;

 

Also, I take back my statement on the grant type in m= y previous mail. 

 

The definition of grant and grant_type are respective= ly: 

 

grant 

    credential representing the resource ow= ner's authorization

         = ;  

grant_type

    (string representing the) type of g= rant sent to the token endpoint to obtain the access token

=

 

Thus, the grant sent to the token endpoint in this ca= se is still 'code'. 

 

Response type on the other hand is not so well define= d in RFC6749, but it seems it is representing what is to be returned from th= e authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the to= ken endpoint, which is a parallel to the response_type to the Authorization E= ndpoint seems to be a more symmetric way, though I am not sure at all if tha= t is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the toke= n endpoint such as: 

 

response_type

    OPTIONAL. A string representing what is= to be returned from the token endpoint. 

    

Then define the behavior of the endpoint according to= the values as the parallel to the multi-response type spec. =

 

Nat

    

 

 

 

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:

The draft is very clear. 

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was =

"authorization_code_but_do_not_return_access_nor_refr= esh_token", so to speak. 

It does not return anything per se, but an extension c= an define something on top of it. 

 

Then, OIDC can define a binding to it so that the bin= ding only returns ID Token. 

This binding work should be done in OIDF. Should ther= e be such a grant type, 

it will be an extremely short spec. 

 

At the same time, if any other specification wanted t= o define 

other type of tokens and have it returned from the to= ken endpoint, 

it can also use this grant type. <= /p>

 

If what you want is to define a new grant type that r= eturns ID Token only, 

then, I am with Justin. Since "other response than ID= Token" is only 

theoretical, this is a more plausible way forward, I s= uppose. 

 

Nat

 

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the token endp= oint with no access token. All parameters and values are defined in OIDC."
Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in o= rder to implement the same flow. 
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin. 
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make mu= ch more sense to develop this document in the OpenID Foundation. It should b= e something that directly references OpenID Connect Core for all of these te= rms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of O= Auth, and I don't see a good argument for doing this work in this working gr= oup.
>>>>
>>>>  -- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote= :
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.  The "prompt=3D= consent" definition being missing is an editorial error.  It should be:=
>>>>>>
>>>>>>  
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-User= for consent before returning information to the Client. If it cannot obtain= consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I'll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be de= fined too, and you might have forgotten to also import account_selection_req= uired from OpenID Connect.
>>>>>  
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I agree that there's no difference between a respon= se with multiple "amr" values that includes "mfa" and one that doesn't. = ; Unless a clear use case for why "mfa" is needed can be identified, we can d= elete it in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand that I should r= eturn "pwd" if the user authenticated using a password, but what "the servic= e if a client secret is used" means in the definition for the "pwd" value? >>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til= you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAu= th@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@i= etf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://n= at.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.= org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakim= ura.org/
> @_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.o= rg/
@_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.o= rg/
@_nat_en

 


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



 

--
Thomas Broyer
/t=C9=94.ma.= b=CA=81wa.je/

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



 

-- =
Thomas Broyer
/t=C9=94= .ma.b=CA=81wa.je/


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.o= rg/
@_nat_en

 

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

 

 

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


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




--
Nat Sakim= ura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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




--
Nat Sakimura (= =3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-746A924C-C8BA-4FF2-BAA9-7E0E9EA62871-- From nobody Wed Jul 23 13:53:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0111C1A035A for ; Wed, 23 Jul 2014 13:53:52 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppen3LX4AzaQ for ; Wed, 23 Jul 2014 13:53:47 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A67A1B2B43 for ; Wed, 23 Jul 2014 13:53:46 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id j5so2193295qga.1 for ; Wed, 23 Jul 2014 13:53:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=wVO1897nCCsXZm50kMKKhlPTWq12EKT2w5FylVgx/z4=; b=c9haCNHF7DFikj2LkGTgHsoS2FAW4YMxXxKg35Wnj/84MxwhmGN3AqNPYhpuA+EJeN Ppr9mSSbmQjm+OZFlhdjXQRpS+NI+bcp5t8QfH75vm1hvBGN1pOBfXAZWkk6hf1/I5U/ ycz9pNYh0YfbcLhIWG86VCL8WNIBepGL6NAcB5fflHWLf71OzpxlGDRb66tXAov/ueyR 0D0tUEEDg0B2PNIfW2XLfpkVfb3srzb+w3rthPBZGEXBURfVRLonseRnlCAUjDqB+Tp9 Rm+7eoxQv2Pq1XkWsv/mKoKv+uxtReW2BHxG5ihkWG+H5G9ertrOlMtxTC8ZF+ZUuw81 9FJw== X-Gm-Message-State: ALoCoQlC7HQwtiBEJTqi6glH4NYGaUzMIs3dYdCYA9jHGMW5FODhoDafeI80PO3NVkj7xSd6GwP8 X-Received: by 10.140.101.86 with SMTP id t80mr5858821qge.91.1406148825584; Wed, 23 Jul 2014 13:53:45 -0700 (PDT) Received: from [10.184.81.199] (36.sub-70-192-128.myvzw.com. [70.192.128.36]) by mx.google.com with ESMTPSA id g35sm4685182qgf.49.2014.07.23.13.53.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 13:53:44 -0700 (PDT) References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1AF8400B-ACFE-40CB-A315-71AFE675A9C4; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> X-Mailer: iPhone Mail (11D257) From: John Bradley Date: Wed, 23 Jul 2014 16:53:37 -0400 To: "torsten@lodderstedt.net" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/AP5wTEYI4hW6_SsWO3dTTQ7oidQ Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 20:53:52 -0000 --Apple-Mail-1AF8400B-ACFE-40CB-A315-71AFE675A9C4 Content-Type: multipart/alternative; boundary=Apple-Mail-0B28C340-E4C2-4D42-A5C6-F7EA0FD5F762 Content-Transfer-Encoding: 7bit --Apple-Mail-0B28C340-E4C2-4D42-A5C6-F7EA0FD5F762 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I thought I did post this to the list.=20 I guess I hit the wrong reply on my phone.=20 =20 John B.=20 Sent from my iPhone > On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: >=20 > we are two, at least :-) >=20 > Why didn't you post this on the list? >=20 > When will be be arriving? >=20 > Am 23.07.2014 16:39, schrieb John Bradley: >=20 >> Ian Glazer mentioned this in his keynote at CIS yesterday.=20 >> =20 >> His advice was please stop, we are creating confusion and uncertainty.=20= >> =20 >> We are becoming our own wort enemy. ( my view though Ian may share it) >> =20 >> Returning just an id_ token from the token endpoint has little real value= .=20 >> =20 >> Something really useful to do would be sorting out channel_id so we can d= o PoP for id tokens to make them and other cookies secure in the front chann= el. I think that is a better use of time.=20 >> =20 >> I may be in the minority opinion on that, it won't be the first time. =20= >>=20 >> John B.=20 >> Sent from my iPhone >>=20 >>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt wrote: >>>=20 >>> You are right from a theoretical perspective. Practically this was cause= d by editorial decisions during the creation of the RFC. As far as I remembe= r, there was a definition of the (one) token endpoint response in early vers= ions. No one every considered to NOT respond with an access token from the t= oken endpoint. So one might call it an implicit assumption. >>> =20 >>> I'm worried that people get totally confused if an exception is introduc= ed now given the broad adoption of OAuth based on this assumption. >>> =20 >>> regards, >>> Torsten. >>>=20 >>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer : >>>>=20 >>>> Is it said anywhere that ALL grant types MUST use Section 5.1 responses= ? Each grant type references Section 5.1, and "access token request" is only= defined in the context of the defined grant types. Section 2.2 doesn't talk= about the request or response format. >>>>=20 >>>> Le 23 juil. 2014 21:32, "Nat Sakimura" a =C3=A9cri= t : >>>>> Is it? Apart from the implicit grant that does not use token endpoint,= all other grant references section 5.1 for the response, i.e., all shares t= he same response.=20 >>>>>=20 >>>>>=20 >>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer : >>>>>> I hadn't realized the JSON response that requires the access_token fi= eld is defined per grant_type, so I'd be OK to "extend the semantics" as in t= he current draft. >>>>>> That was actually my main concern: that the token endpoint mandates a= ccess_token; but its actually not the case. >>>>>>=20 >>>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9c= rit : >>>>>>=20 >>>>>>> I agree with John that overloading response_type @ authz endpoint is= a bad idea. It completely changes the semantics of this parameter. NOTE: wh= at I was proposing was not this parameter, but a new parameter response_type= @ token endpoint.=20 >>>>>>> =20 >>>>>>> I also think overloading grant_type is a bad idea since it changes i= ts semantics. I quote the definition here again:=20 >>>>>>> =20 >>>>>>> grant=20 >>>>>>> credential representing the resource owner's authorization >>>>>>> =20 >>>>>>> grant_type >>>>>>> type of grant sent to the token endpoint to obtain the access token= >>>>>>> =20 >>>>>>> It is not about controlling what is to be returned from the token en= dpoint, but the hint to the token endpoint describing the type of credential= the endpoint has received. It seems the "control of what is being returned f= rom token endpoint" is just a side effect.=20 >>>>>>> =20 >>>>>>> I am somewhat ambivalent[1] in changing the semantics of token endpo= int, but in as much as "text is the king" for a spec., we probably should no= t change the semantics of it as Torsten points out. If it is ok to change th= is semantics, I believe defining a new parameter to this endpoint to control= the response would be the best way to go. This is what I have described pre= viously.=20 >>>>>>> =20 >>>>>>> Defining a new endpoint to send code to get ID Token and forbidding t= he use of it against token endpoint would not change the semantics of any ex= isting parameter or endpoint, which is good. However, I doubt if it is not w= orth doing. What's the point of avoiding access token scoped to UserInfo end= point after all? Defining a new endpoint for just avoiding the access token f= or userinfo endpoint seems way too much the heavy wait way and it breaks int= eroperabiliy: it defeats the purpose of standardization.=20 >>>>>>> =20 >>>>>>> I have started feeling that no change is the best way out.=20 >>>>>>> =20 >>>>>>> Nat >>>>>>> =20 >>>>>>> [1] If instead of saying "Token endpoint - used by the client to ex= change an authorization grant for an access token, typically with client aut= hentication", it were saying "Token endpoint - used by the client to exchang= e an authorization grant for tokens, typically with client authentication", t= hen it would have been OK. It is an expansion of the capability rather than c= hanging the semantics. >>>>>>> =20 >>>>>>>=20 >>>>>>>=20 >>>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones := >>>>>>>> You need the alternative response_type value ("code_for_id_token" i= n the A4C draft) to tell the Authorization Server to return a code to be use= d with the new grant type, rather than one to use with the "authorization_co= de" grant type (which is what response_type=3Dcode does). >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradl= ey >>>>>>>> Sent: Wednesday, July 23, 2014 10:33 AM >>>>>>>> To: torsten@lodderstedt.net >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Cc: oauth@ietf.org >>>>>>>> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oau= th-v2-user-a4c-05.txt >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> If we use the token endpoint then a new grant_type is the best way.= =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> It sort of overloads code, but that is better than messing with res= ponse_type for the authorization endpoint to change the response from the to= ken_endpoint. That is in my opinion a champion bad idea.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> In discussions developing Connect we decided not to open this can o= f worms because no good would come of it. =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> The token_endpoint returns a access token. Nothing requires scope t= o be associates with the token.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> That is the best solution. No change required. Better interoperab= ility in my opinion.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Still on my way to TO, getting in later today.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> John B.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Sent from my iPhone >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >>>>>>>>=20 >>>>>>>> The "response type" of the token endpoint is controlled by the valu= e of the parameter "grant_type". So there is no need to introduce a new para= meter. >>>>>>>>=20 >>>>>>>> wrt to a potential "no_access_token" grant type. I do not consider t= his a good idea as it changes the semantics of the token endpoint (as alread= y pointed out by Thomas). This endpoint ALWAYS responds with an access token= to any grant type. I therefore would prefer to use another endpoint for the= intended purpose. >>>>>>>>=20 >>>>>>>> regards, >>>>>>>> Torsten. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>>>>>>>=20 >>>>>>>> IMHO, changing the semantics of "response_type" @ authz endpoint th= is way is not a good thing.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Instead, defining a new parameter "response_type" @ token endpoint,= as I described in my previous message,=20 >>>>>>>>=20 >>>>>>>> probably is better. At least, it does not change the semantics of t= he parameters of RFC6749.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Nat=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >>>>>>>>=20 >>>>>>>> No, I mean response_type=3Dnone and response_type=3Did_token don't g= enerate a code or access token so you don't use the Token Endpoint (which is= not the same as the Authentication Endpoint BTW). >>>>>>>>=20 >>>>>>>> With response_type=3Dcode_for_id_token, you get a code and exchange= it for an id_token only, rather than an access_token, so you're changing th= e semantics of the Token Endpoint. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> I'm not saying it's a bad thing, just that you can't really compare= none and id_token with code_for_id_token. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. wrote: >>>>>>>>=20 >>>>>>>> It's only "not using the token endpoint" because the token endpoint= copy-pasted and renamed the authentication endpoint. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer wro= te: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Except that these are about not using the Token Endpoint at all, wh= ereas the current proposal is about the Token Endpoint not returning an acce= ss_token field in the JSON. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones wrote: >>>>>>>>=20 >>>>>>>> The response_type "none" is already used in practice, which returns= no access token. It was accepted by the designated experts and registered i= n the IANA OAuth Authorization Endpoint Response Types registry at http://ww= w.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint. The r= egistered "id_token" response type also returns no access token. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> So I think the question of whether response types that result in no= access token being returned are acceptable within OAuth 2.0 is already sett= led, as a practical matter. Lots of OAuth implementations are already using= such response types. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> -- Mike= >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt >>>>>>>> Sent: Wednesday, July 23, 2014 7:09 AM >>>>>>>> To: Nat Sakimura >>>>>>>> Cc: >>>>>>>> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oau= th-v2-user-a4c-05.txt >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Yes. This is why it has to be discussed in the IETF. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>>=20 >>>>>>>> www.independentid.com >>>>>>>>=20 >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrot= e: >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Reading back the RFC6749, I am not sure if there is a good way of s= uppressing access token from the response and still be OAuth. It will break w= hole bunch of implicit definitions like:=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> authorization server >>>>>>>> The server issuing access tokens to the client after successf= ully >>>>>>>> authenticating the resource owner and obtaining authorization= . >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> After all, OAuth is all about issuing access tokens.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Also, I take back my statement on the grant type in my previous mai= l.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> The definition of grant and grant_type are respectively:=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> grant=20 >>>>>>>>=20 >>>>>>>> credential representing the resource owner's authorization >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> grant_type >>>>>>>>=20 >>>>>>>> (string representing the) type of grant sent to the token endpo= int to obtain the access token >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Thus, the grant sent to the token endpoint in this case is still 'c= ode'.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Response type on the other hand is not so well defined in RFC6749, b= ut it seems it is representing what is to be returned from the authorization= endpoint. To express what is to be returned from token endpoint, perhaps de= fining a new parameter to the token endpoint, which is a parallel to the res= ponse_type to the Authorization Endpoint seems to be a more symmetric way, t= hough I am not sure at all if that is going to be OAuth any more. One straw-= man is to define a new parameter called response_type to the token endpoint s= uch as:=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> response_type >>>>>>>>=20 >>>>>>>> OPTIONAL. A string representing what is to be returned from the= token endpoint.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Then define the behavior of the endpoint according to the values as= the parallel to the multi-response type spec.=20 >>>>>>>>=20 >>>>>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Nat >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>>>>>>>=20 >>>>>>>> The draft is very clear.=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >>>>>>>>=20 >>>>>>>> The new grant type that I was talking about was=20 >>>>>>>>=20 >>>>>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", so= to speak.=20 >>>>>>>>=20 >>>>>>>> It does not return anything per se, but an extension can define som= ething on top of it.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Then, OIDC can define a binding to it so that the binding only retu= rns ID Token.=20 >>>>>>>>=20 >>>>>>>> This binding work should be done in OIDF. Should there be such a gr= ant type,=20 >>>>>>>>=20 >>>>>>>> it will be an extremely short spec.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> At the same time, if any other specification wanted to define=20 >>>>>>>>=20 >>>>>>>> other type of tokens and have it returned from the token endpoint,=20= >>>>>>>>=20 >>>>>>>> it can also use this grant type.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> If what you want is to define a new grant type that returns ID Toke= n only,=20 >>>>>>>>=20 >>>>>>>> then, I am with Justin. Since "other response than ID Token" is onl= y=20 >>>>>>>>=20 >>>>>>>> theoretical, this is a more plausible way forward, I suppose.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Nat >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>>>>>>>=20 >>>>>>>> So the draft would literally turn into: >>>>>>>>=20 >>>>>>>> "The a4c response type and grant type return an id_token from the t= oken endpoint with no access token. All parameters and values are defined in= OIDC." >>>>>>>>=20 >>>>>>>> Seems like the perfect mini extension draft for OIDF to do. >>>>>>>>=20 >>>>>>>> --Justin >>>>>>>>=20 >>>>>>>> /sent from my phone/ >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >>>>>>>> > >>>>>>>> > What about just defining a new grant type in this WG? >>>>>>>> > >>>>>>>> > >>>>>>>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>>>>>>> >> >>>>>>>> >> That would be nice. However oidc still needs the new grant type i= n order to implement the same flow.=20 >>>>>>>> >> >>>>>>>> >> Phil >>>>>>>> >> >>>>>>>> >> On Jul 22, 2014, at 11:35, Nat Sakimura wro= te: >>>>>>>> >> >>>>>>>> >>> +1 to Justin.=20 >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. = : >>>>>>>> >>>> >>>>>>>> >>>> Errors like these make it clear to me that it would make much m= ore sense to develop this document in the OpenID Foundation. It should be so= mething that directly references OpenID Connect Core for all of these terms i= nstead of redefining them. It's doing authentication, which is fundamentally= what OpenID Connect does on top of OAuth, and I don't see a good argument f= or doing this work in this working group. >>>>>>>> >>>> >>>>>>>> >>>> -- Justin >>>>>>>> >>>> >>>>>>>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer wrote: >>>>>>>> >>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones wrote: >>>>>>>> >>>>>> >>>>>>>> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" defi= nition being missing is an editorial error. It should be: >>>>>>>> >>>>>> >>>>>>>> >>>>>> =20 >>>>>>>> >>>>>> >>>>>>>> >>>>>> consent >>>>>>>> >>>>>> >>>>>>>> >>>>>> The Authorization Server SHOULD prompt the End-User for cons= ent before returning information to the Client. If it cannot obtain consent,= it MUST return an error, typically consent_required. >>>>>>>> >>>>>> >>>>>>>> >>>>>> =20 >>>>>>>> >>>>>> >>>>>>>> >>>>>> I'll plan to add it in the next draft. >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> It looks like the consent_required error needs to be defined t= oo, and you might have forgotten to also import account_selection_required f= rom OpenID Connect. >>>>>>>> >>>>> =20 >>>>>>>> >>>>>> >>>>>>>> >>>>>> =20 >>>>>>>> >>>>>> >>>>>>>> >>>>>> I agree that there's no difference between a response with m= ultiple "amr" values that includes "mfa" and one that doesn't. Unless a cle= ar use case for why "mfa" is needed can be identified, we can delete it in t= he next draft. >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> Thanks. >>>>>>>> >>>>> >>>>>>>> >>>>> How about "pwd" then? I fully understand that I should return= "pwd" if the user authenticated using a password, but what "the service if a= client secret is used" means in the definition for the "pwd" value? >>>>>>>> >>>>> >>>>>>>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you c= ome back ;-) ) >>>>>>>> >>>>> >>>>>>>> >>>>> -- >>>>>>>> >>>>> Thomas Broyer >>>>>>>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>>>> >>>>> _______________________________________________ >>>>>>>> >>>>> 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 >>>>>>>> >>>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> -- >>>>>>>> >>> Nat Sakimura (=3Dnat) >>>>>>>> >>> Chairman, OpenID Foundation >>>>>>>> >>> http://nat.sakimura.org/ >>>>>>>> >>> @_nat_en >>>>>>>> >>> >>>>>>>> >>> _______________________________________________ >>>>>>>> >>> OAuth mailing list >>>>>>>> >>> OAuth@ietf.org >>>>>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > -- >>>>>>>> > Nat Sakimura (=3Dnat) >>>>>>>> > Chairman, OpenID Foundation >>>>>>>> > http://nat.sakimura.org/ >>>>>>>> > @_nat_en >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>>=20 >>>>>>>> Chairman, OpenID Foundation >>>>>>>> http://nat.sakimura.org/ >>>>>>>> @_nat_en >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>>=20 >>>>>>>> Chairman, OpenID Foundation >>>>>>>> http://nat.sakimura.org/ >>>>>>>> @_nat_en >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Thomas Broyer >>>>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Thomas Broyer >>>>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>>=20 >>>>>>>> Chairman, OpenID Foundation >>>>>>>> http://nat.sakimura.org/ >>>>>>>> @_nat_en >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>>=20 >>>>>>> =20 >>>>>>> --=20 >>>>>>> Nat Sakimura (=3Dnat) >>>>>>> Chairman, OpenID Foundation >>>>>>> http://nat.sakimura.org/ >>>>>>> @_nat_en >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > =20 >=20 > =20 --Apple-Mail-0B28C340-E4C2-4D42-A5C6-F7EA0FD5F762 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I thought I did post this to the list.=  

I guess I hit the wrong reply on my phone.&n= bsp;
 
John B. 
Sent from my iPhone

= On Jul 23, 2014, at 4:50 PM, tors= ten@lodderstedt.net wrote:

we are two, at least :-)

Why didn't you post this on the list?

When will be be arriving?

Am 23.07.2014 16:39, schrieb John Bradley:

Ian Glazer mentioned this in his keynote at CIS yesterday. 
 
His advice was please stop,  we are creating confusion and uncerta= inty. 
 
We are becoming our own wort enemy. ( my view though Ian may share it)<= /div>
 
Returning just an id_ token from the token endpoint has little real val= ue. 
 
Something really useful to do would be sorting out channel_id so we can= do PoP for id tokens to make them and other cookies secure in the front cha= nnel.   I think that is a better use of time. 
 
I may be in the minority opinion on that,  it won't be the first t= ime.  

John B. 
Sent from my iPhone

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

<= /div>
You are right from a theoretical perspective. Practically this was caus= ed by editorial decisions during the creation of the RFC. As far as I rememb= er, there was a definition of the (one) token endpoint response in early ver= sions. No one every considered to NOT respond with an access token from the t= oken endpoint. So one might call it an implicit assumption.
 
I'm worried that people get totally confused if an exception is introdu= ced now given the broad adoption of OAuth based on this assumption.
 
regards,
Torsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

Is it said anywhere that ALL grant types MUST use Section 5.1= responses? Each grant type references Section 5.1, and "access token reques= t" is only defined in the context of the defined grant types. Section 2.2 do= esn't talk about the request or response format.

Le 23 juil. 2014 21:32, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit :
Is it? Apart from the implicit grant that does not use toke= n endpoint, all other grant references section 5.1 for the response, i.e., a= ll shares the same response. 


2014-07-23 15:18 GMT-04:00 Thomas Broyer &l= t;t.broyer@gmail.com>:

I hadn't realized the JSON response that requires the access_= token field is defined per grant_type, so I'd be OK to "extend the semantics= " as in the current draft.
That was actually my main concern: that the t= oken endpoint mandates access_token; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit :

I agree with John that overloading response_type @ authz endpoint is a b= ad idea. It completely changes the semantics of this parameter. NOTE: what I= was proposing was not this parameter, but a new parameter response_type @ t= oken endpoint. 
 
I also think overloading grant_type is a bad idea since it changes its s= emantics. I quote the definition here again: 
 
grant 
    credential representing the resource owner's authorizatio= n
 
grant_type
type of grant sent to th= e token endpoint to obtain the access token
 
It is not about controlling what is to be returned from the token endpo= int, but the hint to the token endpoint describing the type of credential th= e endpoint has received. It seems the "control of what is being returned fro= m token endpoint"  is just a side effect. 
 
I am somewhat ambivalent[1] in changing the semantics of token endpoint= , but in as much as "text is the king" for a spec., we probably should not c= hange the semantics of it as Torsten points out. If it is ok to change this s= emantics, I believe defining a new parameter to this endpoint to control the= response would be the best way to go. This is what I have described previou= sly. 
 
Defining a new endpoint to send code to get ID Token and forbidding the= use of it against token endpoint would not change the semantics of any exis= ting parameter or endpoint, which is good. However, I doubt if it is not wor= th doing. What's the point of avoiding access token scoped to UserInfo endpo= int after all? Defining a new endpoint for just avoiding the access token fo= r userinfo endpoint seems way too much the heavy wait way and it breaks inte= roperabiliy: it defeats the purpose of standardization. 
 
I have started feeling that no change is the best way out. 
 
Nat
 
[1]  If instead of saying "Token endpoint - used by the client to exchange an authorization&nb= sp;grant for an access token, typically with client authentication", i= t were saying "Token endpoin= t - used by the client to exchange an authorization grant for to= kens, typically with client authentication", then it would have been OK. It i= s an expansion of the capability rather than changing the semantics.
 


2014-07-23 13:39 GMT-04:00 Mike Jones <<= a href=3D"mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com>:

You need the alternative response_type va= lue ("code_for_id_token" in the A4C draft) t= o tell the Authorization Server to return a code to be used with the new gra= nt type, rather than one to use with the "authorization_code" grant type (wh= ich is what response_type=3Dcode does).

=

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 A= M
To: torsten= @lodderstedt.net


Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] New Version Notification f= or draft-hunt-oauth-v2-user-a4c-05.txt

 

&n= bsp;

If we use the token endpoint then a new grant_type is= the best way. 

&n= bsp;

It sort of overloads code, but that is better than me= ssing with response_type for the authorization endpoint to change the respon= se from the token_endpoint.  That is in my opinion a champion bad idea.=  

&n= bsp;

In discussions developing Connect we decided not to o= pen this can of worms because no good would come of it.   

&n= bsp;

The token_endpoint returns a access token.  Noth= ing requires scope to be associates with the token. =

&n= bsp;

That is the best solution.  No change required. &= nbsp;Better interoperability in my opinion. <= /p>

&n= bsp;

Still on my way to TO, getting in later today. <= span style=3D"text-decoration: underline;">

&n= bsp;

John B. 

&n= bsp;



Sent from my iPhone


On Jul 23, 2014= , at 12:15 PM, torsten@loddersted= t.net wrote:

The "response type" of the token endpoint is controlled by the value of t= he parameter "grant_type". So there is no need to introduce a new parameter.=

wrt to a potential "no_access_token" grant type. I do not consider this a= good idea as it changes the semantics of the token endpoint (as already poi= nted out by Thomas). This endpoint ALWAYS responds with an access token to a= ny grant type. I therefore would prefer to use another endpoint for the inte= nded purpose.

regards,
Torsten.<= span style=3D"text-decoration: underline;">

 

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type" @ aut= hz endpoint this way is not a good thing. 

 

Instead, defining a new parameter "response_type" @ t= oken endpoint, as I described in my previous message, 

probably is better. At least, it does not change the s= emantics of the parameters of RFC6749. 

 

 Nat 

 

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:

No, I mean response_type=3Dnone and response_type=3Di= d_token don't generate a code or access token so you don't use the Token End= point (which is not the same as the Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you get a cod= e and exchange it for an id_token only, rather than an access_token, so you'= re changing the semantics of the Token Endpoint.

 

I'm not saying it's a bad thing, just that you can't r= eally compare none and id_token with code_for_id_token.

 

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. &l= t;jricher@mitre.org> wrote:

It's only "not using the token endpoint" because the t= oken endpoint copy-pasted and renamed the authentication endpoint.

 

 -- Justin

&n= bsp;

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:



<= /span>

Except that these are about not using the Token Endpo= int at all, whereas the current proposal is about the Token Endpoint not ret= urning an access_token field in the JSON.

 

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@microsoft.com>= ; wrote:

The response_type "none" is already used i= n practice, which returns no access token.  It was accepted by the desi= gnated experts and registered in the IANA OAuth Authorization Endpoint Respo= nse Types registry at http://www.iana.org/assignments/oauth-= parameters/oauth-parameters.xml#endpoint.  The registered "id_token= " response type also returns no access token.

 

So I think the question of whether respon= se types that result in no access token being returned are acceptable within= OAuth 2.0 is already settled, as a practical matter.  Lots of OAuth im= plementations are already using such response types. 

       = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;  -- Mike<= span style=3D"text-decoration: underline;">

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil HuntSent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG= ] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

 

Yes. This is why it has to be discussed in the IETF.<= span style=3D"text-decoration: underline;">

 

Phil<= /span>

 

@independentid

phil.hunt@oracle.com

 

 

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com> wrote:

 

Reading back the RFC6749, I am not sure if there is a= good way of suppressing access token from the response and still be OAuth. I= t will break whole bunch of implicit definitions like: 

 

authorization server
      The ser= ver issuing access tokens to the client after successfully
   =   authenticating the resource owner and obtaining authorization.

 

After all, OAuth is all about issuing access tokens.&= nbsp;

 

Also, I take back my statement on the grant type in m= y previous mail. 

 

The definition of grant and grant_type are respective= ly: 

 

grant 

    credential representing the resource ow= ner's authorization

         = ;  

grant_type

    (string representing the) type of g= rant sent to the token endpoint to obtain the access token

 

Thus, the grant sent to the token endpoint in this ca= se is still 'code'. =

 

Response type on the other hand is not so well define= d in RFC6749, but it seems it is representing what is to be returned from th= e authorization endpoint. To express what is to be returned from token endpo= int, perhaps defining a new parameter to the token endpoint, which is a para= llel to the response_type to the Authorization Endpoint seems to be a more s= ymmetric way, though I am not sure at all if that is going to be OAuth any m= ore. One straw-man is to define a new parameter called response_type to the t= oken endpoint such as: 

 

response_type

    OPTIONAL. A string representing what is= to be returned from the token endpoint. 

=

    

Then define the behavior of the endpoint according to= the values as the parallel to the multi-response type spec. 

 

Nat

    

 

 

 

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:<= /span>

The draft is very clear. 

Phil


On Jul 23, 2014= , at 0:46, Nat Sakimura <sakimura@g= mail.com> wrote:

The new grant type that I was talking about was =

"authorization_code_but_do_not_return_access_nor_refr= esh_token", so to speak. 

It does not return anything per se, but an extension c= an define something on top of it. 

 

Then, OIDC can define a binding to it so that the bin= ding only returns ID Token. 

This binding work should be done in OIDF. Should ther= e be such a grant type, 

it will be an extremely short spec. 

 

At the same time, if any other specification wanted t= o define 

other type of tokens and have it returned from the to= ken endpoint, 

it can also use this grant type. 

 

If what you want is to define a new grant type that r= eturns ID Token only, 

then, I am with Justin. Since "other response than ID= Token" is only 

theoretical, this is a more plausible way forward, I s= uppose. 

 

Nat

 

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:<= /p>

So the draft would literally turn into:

"The a= 4c response type and grant type return an id_token from the token endpoint w= ith no access token. All parameters and values are defined in OIDC."

= Seems like the perfect mini extension draft for OIDF to do.

--Justi= n

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
><= br> > What about just defining a new grant type in this WG?
>
&= gt;
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> Th= at would be nice. However oidc still needs the new grant type in order to im= plement the same flow. 
>>
>> Phil
>>
= >> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>&= gt; +1 to Justin. 
>>>
>>>
>>> 2= 014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>>= Errors like these make it clear to me that it would make much more sense to= develop this document in the OpenID Foundation. It should be something that= directly references OpenID Connect Core for all of these terms instead of r= edefining them. It's doing authentication, which is fundamentally what OpenI= D Connect does on top of OAuth, and I don't see a good argument for doing th= is work in this working group.
>>>>
>>>> &nb= sp;-- Justin
>>>>
>>>> On Jul 22, 2014, at 4= :30 AM, Thomas Broyer <t.broyer@gma= il.com> wrote:
>>>>
>>>>>
>= >>>>
>>>>>
>>>>> On Mon, J= ul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>&g= t;>
>>>>>> Thanks for your review, Thomas.  Th= e "prompt=3Dconsent" definition being missing is an editorial error.  I= t should be:
>>>>>>
>>>>>>  = ;
>>>>>>
>>>>>> consent
>= >>>>>
>>>>>> The Authorization Server S= HOULD prompt the End-User for consent before returning information to the Cl= ient. If it cannot obtain consent, it MUST return an error, typically consen= t_required.
>>>>>>
>>>>>>  =
>>>>>>
>>>>>> I'll plan to add i= t in the next draft.
>>>>>
>>>>>
&= gt;>>>> It looks like the consent_required error needs to be def= ined too, and you might have forgotten to also import account_selection_requ= ired from OpenID Connect.
>>>>>  
>>>&g= t;>>
>>>>>>  
>>>>>><= br> >>>>>> I agree that there's no difference between a re= sponse with multiple "amr" values that includes "mfa" and one that doesn't.&= nbsp; Unless a clear use case for why "mfa" is needed can be identified, we c= an delete it in the next draft.
>>>>>
>>>>= ;>
>>>>> Thanks.
>>>>>
>>= >>> How about "pwd" then? I fully understand that I should return "= pwd" if the user authenticated using a password, but what "the service if a c= lient secret is used" means in the definition for the "pwd" value?
>&= gt;>>>
>>>>> (Nota: I know you're at IETF-90, I'= m ready to wait 'til you come back ;-) )
>>>>>
>&g= t;>>> --
>>>>> Thomas Broyer
>>>>= ;> /t=C9=94.ma.b=CA=81wa.je= /
>>>>> _____________________________________________= __
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/m= ailman/listinfo/oauth
>>>>
>>>>
>= >>>
>>>> __________________________________________= _____
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/lis= tinfo/oauth
>>>>
>>>
>>>
&= gt;>>
>>> --
>>> Nat Sakimura (=3Dnat)
&= gt;>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
= >>>
>>> _____________________________________________= __
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3D= nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en<= /span>



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en<= /span>

 


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



 

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

_______________________________________________
O= Auth mailing list
OAuth@ietf.orghttps://www.ietf.or= g/mailman/listinfo/oauth



 

--
Thomas Broyer
/t= =C9=94.ma.b=CA=81wa.je/


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en<= /span>

&n= bsp;

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.iet=
f.org/mailman/listinfo/oauth=

 

 

_______________________________________________
O= Auth mailing list
OAuth@ietf.orghttps://www.ietf.or= g/mailman/listinfo/oauth


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



 
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
htt= p://nat.sakimura.org/
@_nat_en

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



 
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
htt= p://nat.sakimura.org/
@_nat_en
_______________________________________________
O= Auth mailing list
OAuth@ie= tf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
O= Auth mailing list
OAuth@ie= tf.org
https://www.ietf.org/mailman/listinfo/oauth

 

 
= --Apple-Mail-0B28C340-E4C2-4D42-A5C6-F7EA0FD5F762-- --Apple-Mail-1AF8400B-ACFE-40CB-A315-71AFE675A9C4 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNzIzMjA1MzM4WjAjBgkqhkiG9w0BCQQxFgQUDWe++Yz4fha+mRSk 8zQyxDtN4bYwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAPQcanDtZDP2GO97k7/n5uxtYnjiXgNYjeFGPWwucflVx1J1X pRwsmY9CRbxN1hYame/pOtmlXywTuOl+VrX48wBIhbk+IYIobW79kqAAijTODlVoJ+SX0FiZICC2 9l1my7xHzaXEmgfXH1RYTz3nD9XeQRywSTzvi1JeqipOBhqEwwY5FysJZMMpVmemTa49vszTgHXC +STc4+nQpRi8/Yi6Ren7toM4DYo2sj3gVxsp37ZDUHse/N7LXIJiXasn9xLH7RLMijHjtf1ennDA dXrayapdLQcelQBCCn8MJh/4mEz8gAY+gfK+qlJ/ALHxc/UAnMtpeIqZS2PiwtRBMgAAAAAAAA== --Apple-Mail-1AF8400B-ACFE-40CB-A315-71AFE675A9C4-- From nobody Wed Jul 23 14:07:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7881A00E6 for ; Wed, 23 Jul 2014 14:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 NxQ7NrI1g4xV for ; Wed, 23 Jul 2014 14:07:21 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB161A0199 for ; Wed, 23 Jul 2014 14:07:21 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6NL7JuR019204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 21:07:20 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6NL7I9O023907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 21:07:19 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6NL7IZx008702; Wed, 23 Jul 2014 21:07:18 GMT Received: from dhcp-a6be.meeting.ietf.org (/31.133.166.190) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Jul 2014 14:07:17 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_EF4C121D-E36E-46DA-94CD-2081EDD53010" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> Date: Wed, 23 Jul 2014 17:07:15 -0400 Message-Id: <95D6ADD6-5298-4426-B226-0CB08F515254@oracle.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zcXXPoicoj-J5j7NR8tO0UjPLLo Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 21:07:28 -0000 --Apple-Mail=_EF4C121D-E36E-46DA-94CD-2081EDD53010 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So=E2=80=A6.your answer to existing confusion is to avoid talking about = it because it would be confusing? Really? Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 23, 2014, at 4:53 PM, John Bradley wrote: > I thought I did post this to the list.=20 >=20 > I guess I hit the wrong reply on my phone.=20 > =20 > John B.=20 > Sent from my iPhone >=20 > On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: >=20 >> we are two, at least :-) >>=20 >> Why didn't you post this on the list? >>=20 >> When will be be arriving? >>=20 >> Am 23.07.2014 16:39, schrieb John Bradley: >>=20 >>> Ian Glazer mentioned this in his keynote at CIS yesterday.=20 >>> =20 >>> His advice was please stop, we are creating confusion and = uncertainty.=20 >>> =20 >>> We are becoming our own wort enemy. ( my view though Ian may share = it) >>> =20 >>> Returning just an id_ token from the token endpoint has little real = value.=20 >>> =20 >>> Something really useful to do would be sorting out channel_id so we = can do PoP for id tokens to make them and other cookies secure in the = front channel. I think that is a better use of time.=20 >>> =20 >>> I may be in the minority opinion on that, it won't be the first = time. =20 >>>=20 >>> John B.=20 >>> Sent from my iPhone >>>=20 >>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt = wrote: >>>=20 >>>> You are right from a theoretical perspective. Practically this was = caused by editorial decisions during the creation of the RFC. As far as = I remember, there was a definition of the (one) token endpoint response = in early versions. No one every considered to NOT respond with an access = token from the token endpoint. So one might call it an implicit = assumption. >>>> =20 >>>> I'm worried that people get totally confused if an exception is = introduced now given the broad adoption of OAuth based on this = assumption. >>>> =20 >>>> regards, >>>> Torsten. >>>>=20 >>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer : >>>>=20 >>>>> Is it said anywhere that ALL grant types MUST use Section 5.1 = responses? Each grant type references Section 5.1, and "access token = request" is only defined in the context of the defined grant types. = Section 2.2 doesn't talk about the request or response format. >>>>>=20 >>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" a = =C3=A9crit : >>>>> Is it? Apart from the implicit grant that does not use token = endpoint, all other grant references section 5.1 for the response, i.e., = all shares the same response.=20 >>>>>=20 >>>>>=20 >>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer : >>>>> I hadn't realized the JSON response that requires the access_token = field is defined per grant_type, so I'd be OK to "extend the semantics" = as in the current draft. >>>>> That was actually my main concern: that the token endpoint = mandates access_token; but its actually not the case. >>>>>=20 >>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" a = =C3=A9crit : >>>>>=20 >>>>> I agree with John that overloading response_type @ authz endpoint = is a bad idea. It completely changes the semantics of this parameter. = NOTE: what I was proposing was not this parameter, but a new parameter = response_type @ token endpoint.=20 >>>>> =20 >>>>> I also think overloading grant_type is a bad idea since it changes = its semantics. I quote the definition here again:=20 >>>>> =20 >>>>> grant=20 >>>>> credential representing the resource owner's authorization >>>>> =20 >>>>> grant_type >>>>> type of grant sent to the token endpoint to obtain the access = token >>>>> =20 >>>>> It is not about controlling what is to be returned from the token = endpoint, but the hint to the token endpoint describing the type of = credential the endpoint has received. It seems the "control of what is = being returned from token endpoint" is just a side effect.=20 >>>>> =20 >>>>> I am somewhat ambivalent[1] in changing the semantics of token = endpoint, but in as much as "text is the king" for a spec., we probably = should not change the semantics of it as Torsten points out. If it is ok = to change this semantics, I believe defining a new parameter to this = endpoint to control the response would be the best way to go. This is = what I have described previously.=20 >>>>> =20 >>>>> Defining a new endpoint to send code to get ID Token and = forbidding the use of it against token endpoint would not change the = semantics of any existing parameter or endpoint, which is good. However, = I doubt if it is not worth doing. What's the point of avoiding access = token scoped to UserInfo endpoint after all? Defining a new endpoint for = just avoiding the access token for userinfo endpoint seems way too much = the heavy wait way and it breaks interoperabiliy: it defeats the purpose = of standardization.=20 >>>>> =20 >>>>> I have started feeling that no change is the best way out.=20 >>>>> =20 >>>>> Nat >>>>> =20 >>>>> [1] If instead of saying "Token endpoint - used by the client to = exchange an authorization grant for an access token, typically with = client authentication", it were saying "Token endpoint - used by the = client to exchange an authorization grant for tokens, typically with = client authentication", then it would have been OK. It is an expansion = of the capability rather than changing the semantics. >>>>> =20 >>>>>=20 >>>>>=20 >>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones = : >>>>> You need the alternative response_type value ("code_for_id_token" = in the A4C draft) to tell the Authorization Server to return a code to = be used with the new grant type, rather than one to use with the = "authorization_code" grant type (which is what response_type=3Dcode = does). >>>>>=20 >>>>> =20 >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John = Bradley >>>>> Sent: Wednesday, July 23, 2014 10:33 AM >>>>> To: torsten@lodderstedt.net >>>>>=20 >>>>>=20 >>>>> Cc: oauth@ietf.org >>>>> Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt >>>>> =20 >>>>> =20 >>>>> If we use the token endpoint then a new grant_type is the best = way.=20 >>>>>=20 >>>>> =20 >>>>> It sort of overloads code, but that is better than messing with = response_type for the authorization endpoint to change the response from = the token_endpoint. That is in my opinion a champion bad idea.=20 >>>>>=20 >>>>> =20 >>>>> In discussions developing Connect we decided not to open this can = of worms because no good would come of it. =20 >>>>>=20 >>>>> =20 >>>>> The token_endpoint returns a access token. Nothing requires scope = to be associates with the token.=20 >>>>>=20 >>>>> =20 >>>>> That is the best solution. No change required. Better = interoperability in my opinion.=20 >>>>>=20 >>>>> =20 >>>>> Still on my way to TO, getting in later today.=20 >>>>>=20 >>>>> =20 >>>>> John B.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>=20 >>>>> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >>>>>=20 >>>>> The "response type" of the token endpoint is controlled by the = value of the parameter "grant_type". So there is no need to introduce a = new parameter. >>>>>=20 >>>>> wrt to a potential "no_access_token" grant type. I do not consider = this a good idea as it changes the semantics of the token endpoint (as = already pointed out by Thomas). This endpoint ALWAYS responds with an = access token to any grant type. I therefore would prefer to use another = endpoint for the intended purpose. >>>>>=20 >>>>> regards, >>>>> Torsten. >>>>>=20 >>>>> =20 >>>>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>>>>=20 >>>>> IMHO, changing the semantics of "response_type" @ authz endpoint = this way is not a good thing.=20 >>>>>=20 >>>>> =20 >>>>> Instead, defining a new parameter "response_type" @ token = endpoint, as I described in my previous message,=20 >>>>>=20 >>>>> probably is better. At least, it does not change the semantics of = the parameters of RFC6749.=20 >>>>>=20 >>>>> =20 >>>>> Nat=20 >>>>>=20 >>>>> =20 >>>>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >>>>>=20 >>>>> No, I mean response_type=3Dnone and response_type=3Did_token don't = generate a code or access token so you don't use the Token Endpoint = (which is not the same as the Authentication Endpoint BTW). >>>>>=20 >>>>> With response_type=3Dcode_for_id_token, you get a code and = exchange it for an id_token only, rather than an access_token, so you're = changing the semantics of the Token Endpoint. >>>>>=20 >>>>> =20 >>>>> I'm not saying it's a bad thing, just that you can't really = compare none and id_token with code_for_id_token. >>>>>=20 >>>>> =20 >>>>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. = wrote: >>>>>=20 >>>>> It's only "not using the token endpoint" because the token = endpoint copy-pasted and renamed the authentication endpoint. >>>>>=20 >>>>> =20 >>>>> -- Justin >>>>>=20 >>>>> =20 >>>>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer = wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Except that these are about not using the Token Endpoint at all, = whereas the current proposal is about the Token Endpoint not returning = an access_token field in the JSON. >>>>>=20 >>>>> =20 >>>>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones = wrote: >>>>>=20 >>>>> The response_type "none" is already used in practice, which = returns no access token. It was accepted by the designated experts and = registered in the IANA OAuth Authorization Endpoint Response Types = registry at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endp= oint. The registered "id_token" response type also returns no access = token. >>>>>=20 >>>>> =20 >>>>> So I think the question of whether response types that result in = no access token being returned are acceptable within OAuth 2.0 is = already settled, as a practical matter. Lots of OAuth implementations = are already using such response types. >>>>>=20 >>>>> =20 >>>>> -- = Mike >>>>>=20 >>>>> =20 >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt >>>>> Sent: Wednesday, July 23, 2014 7:09 AM >>>>> To: Nat Sakimura >>>>> Cc: >>>>> Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt >>>>>=20 >>>>> =20 >>>>> Yes. This is why it has to be discussed in the IETF. >>>>>=20 >>>>> =20 >>>>> Phil >>>>>=20 >>>>> =20 >>>>> @independentid >>>>>=20 >>>>> www.independentid.com >>>>>=20 >>>>> phil.hunt@oracle.com >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura = wrote: >>>>>=20 >>>>> =20 >>>>> Reading back the RFC6749, I am not sure if there is a good way of = suppressing access token from the response and still be OAuth. It will = break whole bunch of implicit definitions like:=20 >>>>>=20 >>>>> =20 >>>>> authorization server >>>>> The server issuing access tokens to the client after = successfully >>>>> authenticating the resource owner and obtaining = authorization. >>>>>=20 >>>>> =20 >>>>> After all, OAuth is all about issuing access tokens.=20 >>>>>=20 >>>>> =20 >>>>> Also, I take back my statement on the grant type in my previous = mail.=20 >>>>>=20 >>>>> =20 >>>>> The definition of grant and grant_type are respectively:=20 >>>>>=20 >>>>> =20 >>>>> grant=20 >>>>>=20 >>>>> credential representing the resource owner's authorization >>>>>=20 >>>>> =20 >>>>> grant_type >>>>>=20 >>>>> (string representing the) type of grant sent to the token = endpoint to obtain the access token >>>>>=20 >>>>> =20 >>>>> Thus, the grant sent to the token endpoint in this case is still = 'code'.=20 >>>>>=20 >>>>> =20 >>>>> Response type on the other hand is not so well defined in RFC6749, = but it seems it is representing what is to be returned from the = authorization endpoint. To express what is to be returned from token = endpoint, perhaps defining a new parameter to the token endpoint, which = is a parallel to the response_type to the Authorization Endpoint seems = to be a more symmetric way, though I am not sure at all if that is going = to be OAuth any more. One straw-man is to define a new parameter called = response_type to the token endpoint such as:=20 >>>>>=20 >>>>> =20 >>>>> response_type >>>>>=20 >>>>> OPTIONAL. A string representing what is to be returned from = the token endpoint.=20 >>>>>=20 >>>>> =20 >>>>> Then define the behavior of the endpoint according to the values = as the parallel to the multi-response type spec.=20 >>>>>=20 >>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>>=20 >>>>> =20 >>>>> Nat >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>>>>=20 >>>>> The draft is very clear.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>>=20 >>>>> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >>>>>=20 >>>>> The new grant type that I was talking about was=20 >>>>>=20 >>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", = so to speak.=20 >>>>>=20 >>>>> It does not return anything per se, but an extension can define = something on top of it.=20 >>>>>=20 >>>>> =20 >>>>> Then, OIDC can define a binding to it so that the binding only = returns ID Token.=20 >>>>>=20 >>>>> This binding work should be done in OIDF. Should there be such a = grant type,=20 >>>>>=20 >>>>> it will be an extremely short spec.=20 >>>>>=20 >>>>> =20 >>>>> At the same time, if any other specification wanted to define=20 >>>>>=20 >>>>> other type of tokens and have it returned from the token endpoint,=20= >>>>>=20 >>>>> it can also use this grant type.=20 >>>>>=20 >>>>> =20 >>>>> If what you want is to define a new grant type that returns ID = Token only,=20 >>>>>=20 >>>>> then, I am with Justin. Since "other response than ID Token" is = only=20 >>>>>=20 >>>>> theoretical, this is a more plausible way forward, I suppose.=20 >>>>>=20 >>>>> =20 >>>>> Nat >>>>>=20 >>>>> =20 >>>>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>>>>=20 >>>>> So the draft would literally turn into: >>>>>=20 >>>>> "The a4c response type and grant type return an id_token from the = token endpoint with no access token. All parameters and values are = defined in OIDC." >>>>>=20 >>>>> Seems like the perfect mini extension draft for OIDF to do. >>>>>=20 >>>>> --Justin >>>>>=20 >>>>> /sent from my phone/ >>>>>=20 >>>>>=20 >>>>> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >>>>> > >>>>> > What about just defining a new grant type in this WG? >>>>> > >>>>> > >>>>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>>>> >> >>>>> >> That would be nice. However oidc still needs the new grant type = in order to implement the same flow.=20 >>>>> >> >>>>> >> Phil >>>>> >> >>>>> >> On Jul 22, 2014, at 11:35, Nat Sakimura = wrote: >>>>> >> >>>>> >>> +1 to Justin.=20 >>>>> >>> >>>>> >>> >>>>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. = : >>>>> >>>> >>>>> >>>> Errors like these make it clear to me that it would make much = more sense to develop this document in the OpenID Foundation. It should = be something that directly references OpenID Connect Core for all of = these terms instead of redefining them. It's doing authentication, which = is fundamentally what OpenID Connect does on top of OAuth, and I don't = see a good argument for doing this work in this working group. >>>>> >>>> >>>>> >>>> -- Justin >>>>> >>>> >>>>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer = wrote: >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones = wrote: >>>>> >>>>>> >>>>> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" = definition being missing is an editorial error. It should be: >>>>> >>>>>> >>>>> >>>>>> =20 >>>>> >>>>>> >>>>> >>>>>> consent >>>>> >>>>>> >>>>> >>>>>> The Authorization Server SHOULD prompt the End-User for = consent before returning information to the Client. If it cannot obtain = consent, it MUST return an error, typically consent_required. >>>>> >>>>>> >>>>> >>>>>> =20 >>>>> >>>>>> >>>>> >>>>>> I'll plan to add it in the next draft. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> It looks like the consent_required error needs to be defined = too, and you might have forgotten to also import = account_selection_required from OpenID Connect. >>>>> >>>>> =20 >>>>> >>>>>> >>>>> >>>>>> =20 >>>>> >>>>>> >>>>> >>>>>> I agree that there's no difference between a response with = multiple "amr" values that includes "mfa" and one that doesn't. Unless = a clear use case for why "mfa" is needed can be identified, we can = delete it in the next draft. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> How about "pwd" then? I fully understand that I should = return "pwd" if the user authenticated using a password, but what "the = service if a client secret is used" means in the definition for the = "pwd" value? >>>>> >>>>> >>>>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you = come back ;-) ) >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thomas Broyer >>>>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>> >>>>> _______________________________________________ >>>>> >>>>> 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 >>>>> >>>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> -- >>>>> >>> Nat Sakimura (=3Dnat) >>>>> >>> Chairman, OpenID Foundation >>>>> >>> http://nat.sakimura.org/ >>>>> >>> @_nat_en >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> OAuth mailing list >>>>> >>> OAuth@ietf.org >>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Nat Sakimura (=3Dnat) >>>>> > Chairman, OpenID Foundation >>>>> > http://nat.sakimura.org/ >>>>> > @_nat_en >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>>=20 >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>>=20 >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>> =20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Thomas Broyer >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Thomas Broyer >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>>=20 >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>> =20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> =20 >>>>> =20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> =20 >> =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_EF4C121D-E36E-46DA-94CD-2081EDD53010 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 So=E2=80=A6.your answer to existing confusion is to = avoid talking about it because it would be = confusing?

Really?


On Jul 23, 2014, at 4:53 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

I thought I did post this to the = list. 

I guess I hit the wrong reply on my = phone. 
 
John B. 
Sent from my = iPhone

On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net = wrote:

we are two, at least = :-)

Why didn't you post this on the list?

When will be be = arriving?

Am 23.07.2014 16:39, schrieb John Bradley:

Ian Glazer mentioned this in his keynote at CIS = yesterday. 
 
His advice was please stop,  we are creating confusion and = uncertainty. 
 
We are becoming our own wort enemy. ( my view though Ian may share = it)
 
Returning just an id_ token from the token endpoint has little real = value. 
 
Something really useful to do would be sorting out channel_id so we = can do PoP for id tokens to make them and other cookies secure in the = front channel.   I think that is a better use of time. 
 
I may be in the minority opinion on that,  it won't be the = first time.  

John B. 
Sent from my iPhone

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

You are right from a theoretical perspective. Practically this was = caused by editorial decisions during the creation of the RFC. As far as = I remember, there was a definition of the (one) token endpoint response = in early versions. No one every considered to NOT respond with an access = token from the token endpoint. So one might call it an implicit = assumption.
 
I'm worried that people get totally confused if an exception is = introduced now given the broad adoption of OAuth based on this = assumption.
 
regards,
Torsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

Is it said anywhere that ALL grant types MUST use = Section 5.1 responses? Each grant type references Section 5.1, and = "access token request" is only defined in the context of the defined = grant types. Section 2.2 doesn't talk about the request or response = format.

Le 23 juil. 2014 21:32, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit= :
Is it? Apart from the implicit grant that does not use = token endpoint, all other grant references section 5.1 for the response, = i.e., all shares the same response. 


2014-07-23 15:18 GMT-04:00 Thomas Broyer = <t.broyer@gmail.com>:

I hadn't = realized the JSON response that requires the access_token field is = defined per grant_type, so I'd be OK to "extend the semantics" as in the = current draft.
That was actually my main concern: that the token = endpoint mandates access_token; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit= :

I agree with John that overloading response_type @ authz endpoint = is a bad idea. It completely changes the semantics of this parameter. = NOTE: what I was proposing was not this parameter, but a new parameter = response_type @ token endpoint. 
 
I also think overloading grant_type is a bad idea since it changes = its semantics. I quote the definition here again: 
 
grant 
    credential representing the resource owner's = authorization
 
grant_type
type of grant sent = to the token endpoint to obtain the access token
 
It is not about controlling what is to be returned from the token = endpoint, but the hint to the token endpoint describing the type of = credential the endpoint has received. It seems the "control of what is = being returned from token endpoint"  is just a side = effect. 
 
I am somewhat ambivalent[1] in changing the semantics of token = endpoint, but in as much as "text is the king" for a spec., we probably = should not change the semantics of it as Torsten points out. If it is ok = to change this semantics, I believe defining a new parameter to this = endpoint to control the response would be the best way to go. This is = what I have described previously. 
 
Defining a new endpoint to send code to get ID Token and forbidding = the use of it against token endpoint would not change the semantics of = any existing parameter or endpoint, which is good. However, I doubt if = it is not worth doing. What's the point of avoiding access token scoped = to UserInfo endpoint after all? Defining a new endpoint for just = avoiding the access token for userinfo endpoint seems way too much the = heavy wait way and it breaks interoperabiliy: it defeats the purpose of = standardization. 
 
I have started feeling that no change is the best way = out. 
 
Nat
 
[1]  If instead of saying "Token endpoint - used by the client to exchange an = authorization grant for an access token, typically with = client authentication", it were saying "Token endpoint - used by the client to exchange an = authorization grant for tokens, typically with client = authentication", then it would have been OK. It is an expansion of the = capability rather than changing the semantics.
 


2014-07-23 13:39 GMT-04:00 Mike Jones = <Michael.Jones@microsoft.com>:

You need the = alternative response_type value = ("code_for_id_token" in the A4C = draft) to tell the Authorization Server to return a code to be used with = the new grant type, rather than one to use with the "authorization_code" = grant type (which is what response_type=3Dcode does).

 

From: OAuth [mailto:oauth-bounces@ietf.org] = On Behalf Of John Bradley
Sent: = Wednesday, July 23, 2014 10:33 AM
To: torsten@lodderstedt.net=


Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt
 
 

If we use the token endpoint then a new = grant_type is the best way. 

 

It sort of overloads code, but that is = better than messing with response_type for the authorization endpoint to = change the response from the token_endpoint.  That is in my opinion = a champion bad idea. 

 

In discussions developing Connect we decided = not to open this can of worms because no good would come of it. =   

 

The token_endpoint returns a access token. =  Nothing requires scope to be associates with the token. 

 

That is the best solution.  No change = required.  Better interoperability in my opinion. 

 

Still on my way to TO, getting in later = today. 

 

John B. 

 



Sent from my iPhone


On Jul = 23, 2014, at 12:15 PM, torsten@lodderstedt.net = wrote:

The "response type" of the token endpoint is controlled by the = value of the parameter "grant_type". So there is no need to introduce a = new parameter.

wrt to a potential = "no_access_token" grant type. I do not consider this a good idea as it = changes the semantics of the token endpoint (as already pointed out by = Thomas). This endpoint ALWAYS responds with an access token to any grant = type. I therefore would prefer to use another endpoint for the intended = purpose.

regards,
= Torsten.

 

Am 23.07.2014 13:04, schrieb = Nat Sakimura:

IMHO, changing the semantics of = "response_type" @ authz endpoint this way is not a good = thing. 

 

Instead, defining a new parameter = "response_type" @ token endpoint, as I described in my previous = message, 

probably is better. At least, it does not = change the semantics of the parameters of RFC6749. 

 

 Nat 

 

2014-07-23 12:48 GMT-04:00 Thomas Broyer = <t.broyer@gmail.com>:

No, I mean response_type=3Dnone and = response_type=3Did_token don't generate a code or access token so you = don't use the Token Endpoint (which is not the same as the = Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you = get a code and exchange it for an id_token only, rather than an = access_token, so you're changing the semantics of the Token = Endpoint.

 

I'm not saying it's a bad thing, just that = you can't really compare none and id_token with code_for_id_token.

 

On Wed, Jul 23, 2014 at 6:45 PM, Richer, = Justin P. <jricher@mitre.org> wrote:

It's only "not using the token endpoint" = because the token endpoint copy-pasted and renamed the authentication = endpoint.

 

 -- Justin

 

On Jul 23, 2014, at 9:30 AM, Thomas Broyer = <t.broyer@gmail.com> = wrote:



Except that these are about not using the = Token Endpoint at all, whereas the current proposal is about the Token = Endpoint not returning an access_token field in the JSON.

 

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

The response_type = "none" is already used in practice, which returns no access token.  = It was accepted by the designated experts and registered in the IANA = OAuth Authorization Endpoint Response Types registry at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endp= oint.  The registered "id_token" response type also returns no = access token.

 

So I think the question of whether response types that result = in no access token being returned are acceptable within OAuth 2.0 is = already settled, as a practical matter.  Lots of OAuth = implementations are already using such response types.

 

          &nbs= p;            =             &n= bsp;           &nbs= p;            -- = Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] = On Behalf Of = Phil Hunt
Sent: Wednesday, July 23, 2014 = 7:09 AM
To: Nat = Sakimura
Cc: <oauth@ietf.org>
Subject: = Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt

 

Yes. = This is why it has to be discussed in the IETF.

 
 
 
 

On Jul 23, 2014, at 9:43 AM, Nat Sakimura = <sakimura@gmail.com> = wrote:

 

Reading back the RFC6749, I am not sure if = there is a good way of suppressing access token from the response and = still be OAuth. It will break whole bunch of implicit definitions = like: 

 

authorization server
    =   The server issuing access tokens to the client after = successfully
      authenticating the resource owner = and obtaining authorization.

 

After all, OAuth is all about issuing access = tokens. 

 

Also, I take back my statement on the grant = type in my previous mail. 

 

The definition of grant and grant_type are = respectively: 

 

grant 

    credential representing the = resource owner's authorization

=
          &nbs= p;

grant_type

    (string representing the) = type of grant sent to the token endpoint to obtain the access token

 

Thus, the grant sent to the token endpoint = in this case is still 'code'. 

 

Response type on the other hand is not so = well defined in RFC6749, but it seems it is representing what is to be = returned from the authorization endpoint. To express what is to be = returned from token endpoint, perhaps defining a new parameter to the = token endpoint, which is a parallel to the response_type to the = Authorization Endpoint seems to be a more symmetric way, though I am not = sure at all if that is going to be OAuth any more. One straw-man is to = define a new parameter called response_type to the token endpoint such = as: 

 

response_type

    OPTIONAL. A string = representing what is to be returned from the token endpoint. 

    

Then define the behavior of the endpoint = according to the values as the parallel to the multi-response type = spec. 

 

Nat

    
 
 
 

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:

The draft is very clear. 

Phil


On Jul = 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> = wrote:

The new grant type that I was talking about = was 

"authorization_code_but_do_not_return_access_nor_refre= sh_token", so to speak. 

It does not return anything per se, but an = extension can define something on top of it. 

 

Then, OIDC can define a binding to it so = that the binding only returns ID Token. 

This binding work should be done in OIDF. = Should there be such a grant type, 

it will be an extremely short = spec. 

 

At the same time, if any other specification = wanted to define 

other type of tokens and have it returned = from the token endpoint, 

it can also use this grant type. 

 

If what you want is to define a new grant = type that returns ID Token only, 

then, I am with Justin. Since "other = response than ID Token" is only 

theoretical, this is a more plausible way = forward, I suppose. 

 

Nat

 

2014-07-22 14:30 GMT-04:00 Justin Richer = <jricher@mit.edu>:

So= the draft would literally turn into:

"The a4c response type and = grant type return an id_token from the token endpoint with no access = token. All parameters and values are defined in OIDC."

Seems = like the perfect mini extension draft for OIDF to do.

= --Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura = <sakimura@gmail.com> = wrote:
>
> What about just defining a new grant type in = this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt = <phil.hunt@oracle.com>:
= >>
>> That would be nice. However oidc still needs the = new grant type in order to implement the same flow. 
= >>
>> Phil
>>
>> On Jul 22, 2014, at = 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
= >>
>>> +1 to Justin. 
>>>
= >>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin = P. <jricher@mitre.org>:
= >>>>
>>>> Errors like these make it clear = to me that it would make much more sense to develop this document in the = OpenID Foundation. It should be something that directly references = OpenID Connect Core for all of these terms instead of redefining them. = It's doing authentication, which is fundamentally what OpenID Connect = does on top of OAuth, and I don't see a good argument for doing this = work in this working group.
>>>>
>>>> =  -- Justin
>>>>
>>>> On Jul 22, = 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:
= >>>>
>>>>>
>>>>>
= >>>>>
>>>>> On Mon, Jul 21, 2014 at = 11:52 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>>>
>>>>>> = Thanks for your review, Thomas.  The "prompt=3Dconsent" definition = being missing is an editorial error.  It should be:
= >>>>>>
>>>>>>  
= >>>>>>
>>>>>> consent
= >>>>>>
>>>>>> The Authorization = Server SHOULD prompt the End-User for consent before returning = information to the Client. If it cannot obtain consent, it MUST return = an error, typically consent_required.
>>>>>>
= >>>>>>  
>>>>>>
= >>>>>> I'll plan to add it in the next draft.
= >>>>>
>>>>>
>>>>> = It looks like the consent_required error needs to be defined too, and = you might have forgotten to also import account_selection_required from = OpenID Connect.
>>>>>  
= >>>>>>
>>>>>>  
= >>>>>>
>>>>>> I agree that = there's no difference between a response with multiple "amr" values that = includes "mfa" and one that doesn't.  Unless a clear use case for = why "mfa" is needed can be identified, we can delete it in the next = draft.
>>>>>
>>>>>
= >>>>> Thanks.
>>>>>
= >>>>> How about "pwd" then? I fully understand that I = should return "pwd" if the user authenticated using a password, but what = "the service if a client secret is used" means in the definition for the = "pwd" value?
>>>>>
>>>>> (Nota: I = know you're at IETF-90, I'm ready to wait 'til you come back ;-) )
= >>>>>
>>>>> --
= >>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
= >>>>> = _______________________________________________
>>>>> = 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
>>>>
>>>
= >>>
>>>
>>> --
>>> Nat = Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
= >>> http://nat.sakimura.org/
= >>> @_nat_en
>>>
>>> = _______________________________________________
>>> OAuth = mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/= mailman/listinfo/oauth
>
>
>
>
> = --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID = Foundation
> http://nat.sakimura.org/
> = @_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
= @_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
= @_nat_en

 


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



 

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

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



 

-- =
Thomas = Broyer
/t=C9=94.ma.b=CA=81wa.je/ =


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
= @_nat_en

 
_______________________________________________
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



 
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en=

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



 
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en=
=
_______________________________________________
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
 
 
=
_______________________________________________
OAut= h mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_EF4C121D-E36E-46DA-94CD-2081EDD53010-- From nobody Wed Jul 23 14:17:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06AE1A035A for ; Wed, 23 Jul 2014 14:17:10 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xA5qUGdnsB-H for ; Wed, 23 Jul 2014 14:17:04 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4C51A0358 for ; Wed, 23 Jul 2014 14:17:04 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id j15so1868202qaq.25 for ; Wed, 23 Jul 2014 14:17:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=o6N+oXWS01eEbCJxn3bx2rDLvytCrpMx/j0/q5ntQs0=; b=bYo565RIA0pQjzj6i8WdAKQilkHhhWwjk5CucOfcx8zCUd+cyABkUf3RISxldd8XiX ifW4gYLNtgy69eoBKIIeaV8PXcDfJMd+9n9CHe+6Z9FOxQqef2AdPf7Bs7lEPiHE7NZn zovUo8vimKvFnHTwUf1E5y5WgOuaKbbkDAirB09FNqANkfzanybRRd+iUXpHH4NNtVBH UVuur/n6Q2pvzX4dUuL1mKG5svPONiOvjWQovuM0sWGM8Ar7A6I+TxOoyTPwJuv4c4nJ NCNpk2A8B/G31+KZD1/PsAueiuD2uZRIAxdU+d9I3onew2Z6GCneeNrW8QsRiyTEGtRT OCAQ== X-Gm-Message-State: ALoCoQnnDHZT9hIsU9CKh9za1zO55t+vvlpJ5rB6VxWnigj7UmGDvqCITsG3y+NKT81qbnEojAQH X-Received: by 10.224.130.5 with SMTP id q5mr6710077qas.72.1406150223297; Wed, 23 Jul 2014 14:17:03 -0700 (PDT) Received: from [10.184.81.199] (36.sub-70-192-128.myvzw.com. [70.192.128.36]) by mx.google.com with ESMTPSA id 33sm4763317qgj.11.2014.07.23.14.17.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 14:17:02 -0700 (PDT) References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <95D6ADD6-5298-4426-B226-0CB08F515254@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: <95D6ADD6-5298-4426-B226-0CB08F515254@oracle.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5E69A43A-7F1E-4B16-8991-912053F48367; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: John Bradley Date: Wed, 23 Jul 2014 17:16:55 -0400 To: Phil Hunt Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fY00eYMGf78e0e1TvxT_InhckH4 Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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, 23 Jul 2014 21:17:11 -0000 --Apple-Mail-5E69A43A-7F1E-4B16-8991-912053F48367 Content-Type: multipart/alternative; boundary=Apple-Mail-A0D76F61-08E2-4946-BA44-C187C5F7EB37 Content-Transfer-Encoding: 7bit --Apple-Mail-A0D76F61-08E2-4946-BA44-C187C5F7EB37 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable No I am not saying that we shouldn't discuss it.=20 We do however need to be mindful that the perception of Change and uncertain= ty causes IT people to delay and defer adoption.=20 Having people delay because they think that there may be more changes are no= t helpful.=20 The perception of stability may be more important than a small optimization.= =20 I think that is a legitimate view as part of the discussion.=20 John B. =20 Sent from my iPhone > On Jul 23, 2014, at 5:07 PM, Phil Hunt wrote: >=20 > So=E2=80=A6.your answer to existing confusion is to avoid talking about it= because it would be confusing? >=20 > Really? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >> On Jul 23, 2014, at 4:53 PM, John Bradley wrote: >>=20 >> I thought I did post this to the list.=20 >>=20 >> I guess I hit the wrong reply on my phone.=20 >> =20 >> John B.=20 >> Sent from my iPhone >>=20 >>> On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: >>>=20 >>> we are two, at least :-) >>>=20 >>> Why didn't you post this on the list? >>>=20 >>> When will be be arriving? >>>=20 >>> Am 23.07.2014 16:39, schrieb John Bradley: >>>=20 >>>> Ian Glazer mentioned this in his keynote at CIS yesterday.=20 >>>> =20 >>>> His advice was please stop, we are creating confusion and uncertainty.= =20 >>>> =20 >>>> We are becoming our own wort enemy. ( my view though Ian may share it) >>>> =20 >>>> Returning just an id_ token from the token endpoint has little real val= ue.=20 >>>> =20 >>>> Something really useful to do would be sorting out channel_id so we can= do PoP for id tokens to make them and other cookies secure in the front cha= nnel. I think that is a better use of time.=20 >>>> =20 >>>> I may be in the minority opinion on that, it won't be the first time. = =20 >>>>=20 >>>> John B.=20 >>>> Sent from my iPhone >>>>=20 >>>>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt wrote: >>>>>=20 >>>>> You are right from a theoretical perspective. Practically this was cau= sed by editorial decisions during the creation of the RFC. As far as I remem= ber, there was a definition of the (one) token endpoint response in early ve= rsions. No one every considered to NOT respond with an access token from the= token endpoint. So one might call it an implicit assumption. >>>>> =20 >>>>> I'm worried that people get totally confused if an exception is introd= uced now given the broad adoption of OAuth based on this assumption. >>>>> =20 >>>>> regards, >>>>> Torsten. >>>>>=20 >>>>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer : >>>>>>=20 >>>>>> Is it said anywhere that ALL grant types MUST use Section 5.1 respons= es? Each grant type references Section 5.1, and "access token request" is on= ly defined in the context of the defined grant types. Section 2.2 doesn't ta= lk about the request or response format. >>>>>>=20 >>>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" a =C3=A9c= rit : >>>>>>> Is it? Apart from the implicit grant that does not use token endpoin= t, all other grant references section 5.1 for the response, i.e., all shares= the same response.=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer : >>>>>>>> I hadn't realized the JSON response that requires the access_token f= ield is defined per grant_type, so I'd be OK to "extend the semantics" as in= the current draft. >>>>>>>> That was actually my main concern: that the token endpoint mandates= access_token; but its actually not the case. >>>>>>>>=20 >>>>>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9= crit : >>>>>>>>=20 >>>>>>>>> I agree with John that overloading response_type @ authz endpoint i= s a bad idea. It completely changes the semantics of this parameter. NOTE: w= hat I was proposing was not this parameter, but a new parameter response_typ= e @ token endpoint.=20 >>>>>>>>> =20 >>>>>>>>> I also think overloading grant_type is a bad idea since it changes= its semantics. I quote the definition here again:=20 >>>>>>>>> =20 >>>>>>>>> grant=20 >>>>>>>>> credential representing the resource owner's authorization >>>>>>>>> =20 >>>>>>>>> grant_type >>>>>>>>> type of grant sent to the token endpoint to obtain the access tok= en >>>>>>>>> =20 >>>>>>>>> It is not about controlling what is to be returned from the token e= ndpoint, but the hint to the token endpoint describing the type of credentia= l the endpoint has received. It seems the "control of what is being returned= from token endpoint" is just a side effect.=20 >>>>>>>>> =20 >>>>>>>>> I am somewhat ambivalent[1] in changing the semantics of token end= point, but in as much as "text is the king" for a spec., we probably should n= ot change the semantics of it as Torsten points out. If it is ok to change t= his semantics, I believe defining a new parameter to this endpoint to contro= l the response would be the best way to go. This is what I have described pr= eviously.=20 >>>>>>>>> =20 >>>>>>>>> Defining a new endpoint to send code to get ID Token and forbiddin= g the use of it against token endpoint would not change the semantics of any= existing parameter or endpoint, which is good. However, I doubt if it is no= t worth doing. What's the point of avoiding access token scoped to UserInfo e= ndpoint after all? Defining a new endpoint for just avoiding the access toke= n for userinfo endpoint seems way too much the heavy wait way and it breaks i= nteroperabiliy: it defeats the purpose of standardization.=20 >>>>>>>>> =20 >>>>>>>>> I have started feeling that no change is the best way out.=20 >>>>>>>>> =20 >>>>>>>>> Nat >>>>>>>>> =20 >>>>>>>>> [1] If instead of saying "Token endpoint - used by the client to e= xchange an authorization grant for an access token, typically with client au= thentication", it were saying "Token endpoint - used by the client to exchan= ge an authorization grant for tokens, typically with client authentication",= then it would have been OK. It is an expansion of the capability rather tha= n changing the semantics. >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones : >>>>>>>>>> You need the alternative response_type value ("code_for_id_token"= in the A4C draft) to tell the Authorization Server to return a code to be u= sed with the new grant type, rather than one to use with the "authorization_= code" grant type (which is what response_type=3Dcode does). >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bra= dley >>>>>>>>>> Sent: Wednesday, July 23, 2014 10:33 AM >>>>>>>>>> To: torsten@lodderstedt.net >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Cc: oauth@ietf.org >>>>>>>>>> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-o= auth-v2-user-a4c-05.txt >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> If we use the token endpoint then a new grant_type is the best wa= y.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> It sort of overloads code, but that is better than messing with r= esponse_type for the authorization endpoint to change the response from the t= oken_endpoint. That is in my opinion a champion bad idea.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> In discussions developing Connect we decided not to open this can= of worms because no good would come of it. =20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> The token_endpoint returns a access token. Nothing requires scop= e to be associates with the token.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> That is the best solution. No change required. Better interoper= ability in my opinion.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Still on my way to TO, getting in later today.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> John B.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPhone >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >>>>>>>>>>=20 >>>>>>>>>> The "response type" of the token endpoint is controlled by the va= lue of the parameter "grant_type". So there is no need to introduce a new pa= rameter. >>>>>>>>>>=20 >>>>>>>>>> wrt to a potential "no_access_token" grant type. I do not conside= r this a good idea as it changes the semantics of the token endpoint (as alr= eady pointed out by Thomas). This endpoint ALWAYS responds with an access to= ken to any grant type. I therefore would prefer to use another endpoint for t= he intended purpose. >>>>>>>>>>=20 >>>>>>>>>> regards, >>>>>>>>>> Torsten. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>>>>>>>>>=20 >>>>>>>>>> IMHO, changing the semantics of "response_type" @ authz endpoint t= his way is not a good thing.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Instead, defining a new parameter "response_type" @ token endpoin= t, as I described in my previous message, =20 >>>>>>>>>>=20 >>>>>>>>>> probably is better. At least, it does not change the semantics of= the parameters of RFC6749.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Nat=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >>>>>>>>>>=20 >>>>>>>>>> No, I mean response_type=3Dnone and response_type=3Did_token don'= t generate a code or access token so you don't use the Token Endpoint (which= is not the same as the Authentication Endpoint BTW). >>>>>>>>>>=20 >>>>>>>>>> With response_type=3Dcode_for_id_token, you get a code and exchan= ge it for an id_token only, rather than an access_token, so you're changing t= he semantics of the Token Endpoint. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> I'm not saying it's a bad thing, just that you can't really compa= re none and id_token with code_for_id_token. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. wrote: >>>>>>>>>>=20 >>>>>>>>>> It's only "not using the token endpoint" because the token endpoi= nt copy-pasted and renamed the authentication endpoint. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> -- Justin >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer w= rote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Except that these are about not using the Token Endpoint at all, w= hereas the current proposal is about the Token Endpoint not returning an acc= ess_token field in the JSON. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones wrote: >>>>>>>>>>=20 >>>>>>>>>> The response_type "none" is already used in practice, which retur= ns no access token. It was accepted by the designated experts and registere= d in the IANA OAuth Authorization Endpoint Response Types registry at http:/= /www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint. T= he registered "id_token" response type also returns no access token. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> So I think the question of whether response types that result in n= o access token being returned are acceptable within OAuth 2.0 is already set= tled, as a practical matter. Lots of OAuth implementations are already usin= g such response types. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> -- Mi= ke >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hun= t >>>>>>>>>> Sent: Wednesday, July 23, 2014 7:09 AM >>>>>>>>>> To: Nat Sakimura >>>>>>>>>> Cc: >>>>>>>>>> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-o= auth-v2-user-a4c-05.txt >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Yes. This is why it has to be discussed in the IETF. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> @independentid >>>>>>>>>>=20 >>>>>>>>>> www.independentid.com >>>>>>>>>>=20 >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura wr= ote: >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Reading back the RFC6749, I am not sure if there is a good way of= suppressing access token from the response and still be OAuth. It will brea= k whole bunch of implicit definitions like:=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> authorization server >>>>>>>>>> The server issuing access tokens to the client after succes= sfully >>>>>>>>>> authenticating the resource owner and obtaining authorizati= on. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> After all, OAuth is all about issuing access tokens.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Also, I take back my statement on the grant type in my previous m= ail.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> The definition of grant and grant_type are respectively:=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> grant=20 >>>>>>>>>>=20 >>>>>>>>>> credential representing the resource owner's authorization >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> grant_type >>>>>>>>>>=20 >>>>>>>>>> (string representing the) type of grant sent to the token end= point to obtain the access token >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Thus, the grant sent to the token endpoint in this case is still '= code'.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Response type on the other hand is not so well defined in RFC6749= , but it seems it is representing what is to be returned from the authorizat= ion endpoint. To express what is to be returned from token endpoint, perhaps= defining a new parameter to the token endpoint, which is a parallel to the r= esponse_type to the Authorization Endpoint seems to be a more symmetric way,= though I am not sure at all if that is going to be OAuth any more. One stra= w-man is to define a new parameter called response_type to the token endpoin= t such as:=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> response_type >>>>>>>>>>=20 >>>>>>>>>> OPTIONAL. A string representing what is to be returned from t= he token endpoint.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Then define the behavior of the endpoint according to the values a= s the parallel to the multi-response type spec.=20 >>>>>>>>>>=20 >>>>>>>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html= >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Nat >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>>>>>>>>>=20 >>>>>>>>>> The draft is very clear.=20 >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Jul 23, 2014, at 0:46, Nat Sakimura wrote= : >>>>>>>>>>=20 >>>>>>>>>> The new grant type that I was talking about was=20 >>>>>>>>>>=20 >>>>>>>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", s= o to speak.=20 >>>>>>>>>>=20 >>>>>>>>>> It does not return anything per se, but an extension can define s= omething on top of it.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Then, OIDC can define a binding to it so that the binding only re= turns ID Token.=20 >>>>>>>>>>=20 >>>>>>>>>> This binding work should be done in OIDF. Should there be such a g= rant type,=20 >>>>>>>>>>=20 >>>>>>>>>> it will be an extremely short spec.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> At the same time, if any other specification wanted to define=20 >>>>>>>>>>=20 >>>>>>>>>> other type of tokens and have it returned from the token endpoint= ,=20 >>>>>>>>>>=20 >>>>>>>>>> it can also use this grant type.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> If what you want is to define a new grant type that returns ID To= ken only,=20 >>>>>>>>>>=20 >>>>>>>>>> then, I am with Justin. Since "other response than ID Token" is o= nly=20 >>>>>>>>>>=20 >>>>>>>>>> theoretical, this is a more plausible way forward, I suppose.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Nat >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>>>>>>>>>=20 >>>>>>>>>> So the draft would literally turn into: >>>>>>>>>>=20 >>>>>>>>>> "The a4c response type and grant type return an id_token from the= token endpoint with no access token. All parameters and values are defined i= n OIDC." >>>>>>>>>>=20 >>>>>>>>>> Seems like the perfect mini extension draft for OIDF to do. >>>>>>>>>>=20 >>>>>>>>>> --Justin >>>>>>>>>>=20 >>>>>>>>>> /sent from my phone/ >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote= : >>>>>>>>>> > >>>>>>>>>> > What about just defining a new grant type in this WG? >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>>>>>>>>> >> >>>>>>>>>> >> That would be nice. However oidc still needs the new grant typ= e in order to implement the same flow.=20 >>>>>>>>>> >> >>>>>>>>>> >> Phil >>>>>>>>>> >> >>>>>>>>>> >> On Jul 22, 2014, at 11:35, Nat Sakimura w= rote: >>>>>>>>>> >> >>>>>>>>>> >>> +1 to Justin.=20 >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >>>>>>>>>> >>>> >>>>>>>>>> >>>> Errors like these make it clear to me that it would make muc= h more sense to develop this document in the OpenID Foundation. It should be= something that directly references OpenID Connect Core for all of these ter= ms instead of redefining them. It's doing authentication, which is fundament= ally what OpenID Connect does on top of OAuth, and I don't see a good argume= nt for doing this work in this working group. >>>>>>>>>> >>>> >>>>>>>>>> >>>> -- Justin >>>>>>>>>> >>>> >>>>>>>>>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer wrote: >>>>>>>>>> >>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones wrote: >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" de= finition being missing is an editorial error. It should be: >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> =20 >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> consent >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> The Authorization Server SHOULD prompt the End-User for co= nsent before returning information to the Client. If it cannot obtain consen= t, it MUST return an error, typically consent_required. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> =20 >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> I'll plan to add it in the next draft. >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> It looks like the consent_required error needs to be define= d too, and you might have forgotten to also import account_selection_require= d from OpenID Connect. >>>>>>>>>> >>>>> =20 >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> =20 >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> I agree that there's no difference between a response with= multiple "amr" values that includes "mfa" and one that doesn't. Unless a c= lear use case for why "mfa" is needed can be identified, we can delete it in= the next draft. >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Thanks. >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> How about "pwd" then? I fully understand that I should retu= rn "pwd" if the user authenticated using a password, but what "the service i= f a client secret is used" means in the definition for the "pwd" value? >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you= come back ;-) ) >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> -- >>>>>>>>>> >>>>> Thomas Broyer >>>>>>>>>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>>>>>> >>>>> _______________________________________________ >>>>>>>>>> >>>>> 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 >>>>>>>>>> >>>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> -- >>>>>>>>>> >>> Nat Sakimura (=3Dnat) >>>>>>>>>> >>> Chairman, OpenID Foundation >>>>>>>>>> >>> http://nat.sakimura.org/ >>>>>>>>>> >>> @_nat_en >>>>>>>>>> >>> >>>>>>>>>> >>> _______________________________________________ >>>>>>>>>> >>> OAuth mailing list >>>>>>>>>> >>> OAuth@ietf.org >>>>>>>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > -- >>>>>>>>>> > Nat Sakimura (=3Dnat) >>>>>>>>>> > Chairman, OpenID Foundation >>>>>>>>>> > http://nat.sakimura.org/ >>>>>>>>>> > @_nat_en >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> --=20 >>>>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>>>>=20 >>>>>>>>>> Chairman, OpenID Foundation >>>>>>>>>> http://nat.sakimura.org/ >>>>>>>>>> @_nat_en >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> --=20 >>>>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>>>>=20 >>>>>>>>>> Chairman, OpenID Foundation >>>>>>>>>> http://nat.sakimura.org/ >>>>>>>>>> @_nat_en >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> --=20 >>>>>>>>>> Thomas Broyer >>>>>>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> --=20 >>>>>>>>>> Thomas Broyer >>>>>>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> --=20 >>>>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>>>>=20 >>>>>>>>>> Chairman, OpenID Foundation >>>>>>>>>> http://nat.sakimura.org/ >>>>>>>>>> @_nat_en >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>> --=20 >>>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>>> Chairman, OpenID Foundation >>>>>>>>> http://nat.sakimura.org/ >>>>>>>>> @_nat_en >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>>=20 >>>>>>> =20 >>>>>>> --=20 >>>>>>> Nat Sakimura (=3Dnat) >>>>>>> Chairman, OpenID Foundation >>>>>>> http://nat.sakimura.org/ >>>>>>> @_nat_en >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-A0D76F61-08E2-4946-BA44-C187C5F7EB37 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
No I am not saying that we shouldn't d= iscuss it. 

We do however need to be mindful t= hat the perception of Change and uncertainty causes IT people to delay and d= efer adoption. 

Having people delay because th= ey think that there may be more changes are not helpful. 
The perception of stability may be more important than a small o= ptimization. 

I think that is a legitimate vie= w as part of the discussion. 

John B.  
Sent from my iPhone

On Jul 23, 2014, at 5:07 PM, Phil Hu= nt <phil.hunt@oracle.com> w= rote:

So=E2=80=A6.your answer to exi= sting confusion is to avoid talking about it because it would be confusing?<= div>
Really?



I thoug= ht I did post this to the list. 

I guess I hit= the wrong reply on my phone. 
 
John B. 
Sen= t from my iPhone

On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote:

<= blockquote type=3D"cite">

we are two, at least :-)

Why didn't you po= st this on the list?

When will be be arriving?

Am 23.07.2014 16:= 39, schrieb John Bradley:

Ian Glazer mentioned this in his keynote at CIS yesterday. 
 
His advice was please stop,  we are creating confusion and uncerta= inty. 
 
We are becoming our own wort enemy. ( my view though Ian may share it)<= /div>
 
Returning just an id_ token from the token endpoint has little real val= ue. 
 
Something really useful to do would be sorting out channel_id so we can= do PoP for id tokens to make them and other cookies secure in the front cha= nnel.   I think that is a better use of time. 
 
I may be in the minority opinion on that,  it won't be the first t= ime.  

John B. 
Sent from my iPhone

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

<= /div>
You are right from a theoretical perspective. Practically this was caus= ed by editorial decisions during the creation of the RFC. As far as I rememb= er, there was a definition of the (one) token endpoint response in early ver= sions. No one every considered to NOT respond with an access token from the t= oken endpoint. So one might call it an implicit assumption.
 
I'm worried that people get totally confused if an exception is introdu= ced now given the broad adoption of OAuth based on this assumption.
 
regards,
Torsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

Is it said anywhere that ALL grant types MUST use Sectio= n 5.1 responses? Each grant type references Section 5.1, and "access token r= equest" is only defined in the context of the defined grant types. Section 2= .2 doesn't talk about the request or response format.

Le 23 juil. 2014 21:32, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit :
Is it? Apart from the implicit grant that does not use toke= n endpoint, all other grant references section 5.1 for the response, i.e., a= ll shares the same response. 


2014-07-23 15:18 GMT-04:00 Thomas Broyer &l= t;t.broyer@gmail.com>:

I hadn't realized the JSON= response that requires the access_token field is defined per grant_type, so= I'd be OK to "extend the semantics" as in the current draft.
That was a= ctually my main concern: that the token endpoint mandates access_token; but i= ts actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit :

I agree with John that overloading response_type @ authz endpoint is a b= ad idea. It completely changes the semantics of this parameter. NOTE: what I= was proposing was not this parameter, but a new parameter response_type @ t= oken endpoint. 
 
I also think overloading grant_type is a bad idea since it changes its s= emantics. I quote the definition here again: 
 
grant 
    credential representing the resource owner's authorizatio= n
 
grant_type
type of grant sent to th= e token endpoint to obtain the access token
 
It is not about controlling what is to be returned from the token endpo= int, but the hint to the token endpoint describing the type of credential th= e endpoint has received. It seems the "control of what is being returned fro= m token endpoint"  is just a side effect. 
 
I am somewhat ambivalent[1] in changing the semantics of token endpoint= , but in as much as "text is the king" for a spec., we probably should not c= hange the semantics of it as Torsten points out. If it is ok to change this s= emantics, I believe defining a new parameter to this endpoint to control the= response would be the best way to go. This is what I have described previou= sly. 
 
Defining a new endpoint to send code to get ID Token and forbidding the= use of it against token endpoint would not change the semantics of any exis= ting parameter or endpoint, which is good. However, I doubt if it is not wor= th doing. What's the point of avoiding access token scoped to UserInfo endpo= int after all? Defining a new endpoint for just avoiding the access token fo= r userinfo endpoint seems way too much the heavy wait way and it breaks inte= roperabiliy: it defeats the purpose of standardization. 
 
I have started feeling that no change is the best way out. 
 
Nat
 
[1]  If instead of saying "Token e= ndpoint - used by the client to exchange an authorization grant f= or an access token, typically with client authentication", it were saying "<= span style=3D"font-size: 1em;">Token endpoint - used by the client to exchan= ge an authorization grant for tokens, typically with client auth= entication", then it would have been OK. It is an expansion of the capabilit= y rather than changing the semantics.
 


2014-07-23 13:39 GMT-04:00 Mike Jones <<= a href=3D"mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com>:

You need the alternative response_ty= pe value ("code_for_id_token" in the A4C dra= ft) to tell the Authorization Server to return a code to be used with the ne= w grant type, rather than one to use with the "authorization_code" grant typ= e (which is what response_type=3Dcode does).=

&nbs= p;

From: OAuth [mailto:oauth-bounces@ietf.org] On B= ehalf Of John Bradley
Sent: Wednesday, July 23,= 2014 10:33 AM
To: torsten@lodderstedt.net


Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] New Version Notification f= or draft-hunt-oauth-v2-user-a4c-05.txt
 
 

If we use the token endpoint then a new grant_ty= pe is the best way. =

 

It sort of overloads code, but that is better th= an messing with response_type for the authorization endpoint to change the r= esponse from the token_endpoint.  That is in my opinion a champion bad i= dea. 

 

In discussions developing Connect we decided not= to open this can of worms because no good would come of it.   

 

The token_endpoint returns a access token.  = ;Nothing requires scope to be associates with the token. 

 

That is the best solution.  No change requi= red.  Better interoperability in my opinion. 

 

Still on my way to TO, getting in later today.&n= bsp;

 

John B. 

 



Sent from my iPhone<= /span>


On Jul 23,= 2014, at 12:15 PM, torsten@lodde= rstedt.net wrote:

The "response type" of the token endpoint is controlled by the value= of the parameter "grant_type". So there is no need to introduce a new param= eter.

wrt to a potential "no_access_token" g= rant type. I do not consider this a good idea as it changes the semantics of= the token endpoint (as already pointed out by Thomas). This endpoint ALWAYS= responds with an access token to any grant type. I therefore would prefer t= o use another endpoint for the intended purpose.

regards,
Torsten.

 

Am 23.07.20= 14 13:04, schrieb Nat Sakimura:<= /span>

IMHO, changing the semantics of "response_type" @= authz endpoint this way is not a good thing. 

 

Instead, defining a new parameter "response_typ= e" @ token endpoint, as I described in my previous message, 

probably is better. At least, it does not change= the semantics of the parameters of RFC6749. =

 

 Nat 

 

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:

No, I mean response_type=3Dnone and response_typ= e=3Did_token don't generate a code or access token so you don't use the Toke= n Endpoint (which is not the same as the Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you get a= code and exchange it for an id_token only, rather than an access_token, so y= ou're changing the semantics of the Token Endpoint.

 

I'm not saying it's a bad thing, just that you c= an't really compare none and id_token with code_for_id_token.

 

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P= . <jricher@mitre.org> wrote:<= span style=3D"text-decoration: underline;">

It's only "not using the token endpoint" because= the token endpoint copy-pasted and renamed the authentication endpoint.

 

 -- Justin

 

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <<= a href=3D"mailto:t.broyer@gmail.com">t.broyer@gmail.com> wrote:



Except that these are about not using the Token E= ndpoint at all, whereas the current proposal is about the Token Endpoint not= returning an access_token field in the JSON.

 

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <= Michael.Jones@microsoft.com> wrote:

The response_type "none" is already u= sed in practice, which returns no access token.  It was accepted by the= designated experts and registered in the IANA OAuth Authorization Endpoint R= esponse Types registry at http://www.iana.org/assignments/oa= uth-parameters/oauth-parameters.xml#endpoint.  The registered "id_t= oken" response type also returns no access token.<= /span>

 

So I thi= nk the question of whether response types that result in no access token bei= ng returned are acceptable within OAuth 2.0 is already settled, as a practic= al matter.  Lots of OAuth implementations are already using such respon= se types.

 =

       &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp; -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Se= nt: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ietf.org>
Subject: R= e: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.t= xt

 

Yes. This is why it has to be discussed in= the IETF.

 
 
 
 

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com> wrote:

 

Reading back the RFC6749, I am not sure if there= is a good way of suppressing access token from the response and still be OA= uth. It will break whole bunch of implicit definitions like: 

 

authorization server
      T= he server issuing access tokens to the client after successfully
  &= nbsp;   authenticating the resource owner and obtaining authorization.<= span style=3D"text-decoration: underline;">

 

After all, OAuth is all about issuing access tok= ens. 

 

Also, I take back my statement on the grant type= in my previous mail. 

 

The definition of grant and grant_type are respe= ctively: 

 

grant 

    credential representing the resour= ce owner's authorization<= span style=3D"text-decoration: underline;">

           =

grant_type

    (string representing the) typ= e of grant sent to the token endpoint to obtain the access token

 

Thus, the grant sent to the token endpoint in th= is case is still 'code'. 

 

Response type on the other hand is not so well d= efined in RFC6749, but it seems it is representing what is to be returned fr= om the authorization endpoint. To express what is to be returned from token e= ndpoint, perhaps defining a new parameter to the token endpoint, which is a p= arallel to the response_type to the Authorization Endpoint seems to be a mor= e symmetric way, though I am not sure at all if that is going to be OAuth an= y more. One straw-man is to define a new parameter called response_type to t= he token endpoint such as: =

 

response_type

    OPTIONAL. A string representing wh= at is to be returned from the token endpoint. 

    

Then define the behavior of the endpoint accordi= ng to the values as the parallel to the multi-response type spec. 

 

Nat<= /span>

    
 
 
 

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:The draft is very clear. 

Phil


On Jul 23,= 2014, at 0:46, Nat Sakimura <sakim= ura@gmail.com> wrote:

The new grant type that I was talking about was&= nbsp;

"authorization_code_but_do_not_return_access_nor= _refresh_token", so to speak. 

It does not return anything per se, but an exten= sion can define something on top of it. 

 

Then, OIDC can define a binding to it so that th= e binding only returns ID Token. 

This binding work should be done in OIDF. Should= there be such a grant type, 

it will be an extremely short spec. 

 

At the same time, if any other specification wan= ted to define 

other type of tokens and have it returned from t= he token endpoint, <= span style=3D"text-decoration: underline;">

it can also use this grant type. 

 

If what you want is to define a new grant type t= hat returns ID Token only, =

then, I am with Justin. Since "other response th= an ID Token" is only 

theoretical, this is a more plausible way forwar= d, I suppose. 

 

Nat<= /span>

 

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:
<= br> "The a4c response type and grant type return an id_token from the token e= ndpoint with no access token. All parameters and values are defined in OIDC.= "

Seems like the perfect mini extension draft for OIDF to do.
--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <= sakimura@gmail.com> wrote:
&= gt;
> What about just defining a new grant type in this WG?
><= br> >
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>&g= t; That would be nice. However oidc still needs the new grant type in order t= o implement the same flow. 
>>
>> Phil
>>=
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>&= gt;> +1 to Justin. 
>>>
>>>
>>&g= t; 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>= > Errors like these make it clear to me that it would make much more sens= e to develop this document in the OpenID Foundation. It should be something t= hat directly references OpenID Connect Core for all of these terms instead o= f redefining them. It's doing authentication, which is fundamentally what Op= enID Connect does on top of OAuth, and I don't see a good argument for doing= this work in this working group.
>>>>
>>>> &= nbsp;-- Justin
>>>>
>>>> On Jul 22, 2014, at= 4:30 AM, Thomas Broyer <t.broyer@g= mail.com> wrote:
>>>>
>>>>>
&g= t;>>>>
>>>>>
>>>>> On Mon,= Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>= >>
>>>>>> Thanks for your review, Thomas.  T= he "prompt=3Dconsent" definition being missing is an editorial error.  I= t should be:
>>>>>>
>>>>>>  = ;
>>>>>>
>>>>>> consent
>= >>>>>
>>>>>> The Authorization Server S= HOULD prompt the End-User for consent before returning information to the Cl= ient. If it cannot obtain consent, it MUST return an error, typically consen= t_required.
>>>>>>
>>>>>>  =
>>>>>>
>>>>>> I'll plan to add i= t in the next draft.
>>>>>
>>>>>
&= gt;>>>> It looks like the consent_required error needs to be def= ined too, and you might have forgotten to also import account_selection_requ= ired from OpenID Connect.
>>>>>  
>>>&g= t;>>
>>>>>>  
>>>>>><= br> >>>>>> I agree that there's no difference between a re= sponse with multiple "amr" values that includes "mfa" and one that doesn't.&= nbsp; Unless a clear use case for why "mfa" is needed can be identified, we c= an delete it in the next draft.
>>>>>
>>>>= ;>
>>>>> Thanks.
>>>>>
>>= >>> How about "pwd" then? I fully understand that I should return "= pwd" if the user authenticated using a password, but what "the service if a c= lient secret is used" means in the definition for the "pwd" value?
>&= gt;>>>
>>>>> (Nota: I know you're at IETF-90, I'= m ready to wait 'til you come back ;-) )
>>>>>
>&g= t;>>> --
>>>>> Thomas Broyer
>>>>= ;> /t=C9=94.ma.b=CA=81wa.je= /
>>>>> _____________________________________________= __
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/m= ailman/listinfo/oauth
>>>>
>>>>
>= >>>
>>>> __________________________________________= _____
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/lis= tinfo/oauth
>>>>
>>>
>>>
&= gt;>>
>>> --
>>> Nat Sakimura (=3Dnat)
&= gt;>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
= >>>
>>> _____________________________________________= __
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3D= nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 


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



 

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

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



 

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/<= /a>


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



 

--
Nat Sakimura (=3Dnat) Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 
_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.iet=
f.org/mailman/listinfo/oauth=
 <= span style=3D"text-decoration: underline;">
 

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


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



 
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
htt= p://nat.sakimura.org/
@_nat_en

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



 
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
htt= p://nat.sakimura.org/
@_nat_en
_______________________________________________
O= Auth mailing list
OAuth@ie= tf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
O= Auth mailing list
OAuth@ie= tf.org
https://www.ietf.org/mailman/listinfo/oauth
 
 
_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.org/mail= man/listinfo/oauth

= --Apple-Mail-A0D76F61-08E2-4946-BA44-C187C5F7EB37-- --Apple-Mail-5E69A43A-7F1E-4B16-8991-912053F48367 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNzIzMjExNjU2WjAjBgkqhkiG9w0BCQQxFgQUyDYtH59QD1Hzrp9v MVI0XKYjGzYwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEArpubh585Y2F7nDX6bZvVwLmQ9XwRv9m0Jh/DgDK7BjPzns++ NrajbDy2qaxZaMntbVv7RYxyTu9EWd6NtlldVRnrqSnbkVfO+TDafw7Ddr3DtEwdPIeMt5GKgJfP tQj7p/XlyYufaocheeqRxVKlnQ275RYF61hM5FsAZZ7KdN0daeQbHPXNtoPMKLa0zRNQiX4R6wmt pCZ5VGaD29C0FGSwosNw188fbuSRlqWkgOpNY9uOg/ieBEXVvdVuQsEYyrzj1kvEP/Um+uEg0k04 0eIcUABR966BQAx2h3cRaOwM36MYvq+Hr+m0elkdHJiVMDj6RlFKewk1rC9Gtza97wAAAAAAAA== --Apple-Mail-5E69A43A-7F1E-4B16-8991-912053F48367-- From nobody Wed Jul 23 16:21:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A221A0373 for ; Wed, 23 Jul 2014 16:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRmmQTW8vJIL for ; Wed, 23 Jul 2014 16:21:13 -0700 (PDT) Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286481A0174 for ; Wed, 23 Jul 2014 16:21:13 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id f10so1322362yha.6 for ; Wed, 23 Jul 2014 16:21:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=hWIEHRa0Ba0BTEnBTV1Q1JOOJwSCUQuPMAlFl5OjfeM=; b=TJGT3DAc2obWVe98KPXgt3ZEa5sbOVwhja7DwvPoxcBrORJ7XZGcy2WSZoerMb0ysU BKQbXhCFz5QyqyyBLlD9U2MbQ/hWhGTZkPsFwnSZMKb1Px5t1zLC2d0UNJNunRHvfp0I L7CiDrBBlsRKXlRLMuF85LEgz8bFBonO92xgqxzRuyV4r+gRmDJi6SpjUlOTFa/skijw AEuz2dr2pVgCpd6iLTj+triwcIpw8Par2uvSzbO3PUCZLavOKlLQ7BlykHJhVbvcRUU4 qBVFTG08YHx553eRUCZIUZALzdPX81utrw3LT+cqvXv3EYUDT9eOUxTxvxQW7VOgzlxu wwRg== X-Gm-Message-State: ALoCoQmohNVuLy4MRI3yCl9e0Z8pxt/EZNrmfji7HooE916PEePgi4+rACq2orE5lFX41njswEZW X-Received: by 10.236.220.197 with SMTP id o65mr6276667yhp.125.1406157672523; Wed, 23 Jul 2014 16:21:12 -0700 (PDT) Received: from gilszenbook ([12.236.17.3]) by mx.google.com with ESMTPSA id q5sm10274480yhk.8.2014.07.23.16.21.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 Jul 2014 16:21:11 -0700 (PDT) From: "Gil Kirkpatrick" To: "'Sergey Beryozkin'" , References: <00e001cfa69b$8f7b7c10$ae727430$@viewds.com> <53D0148B.4090206@gmail.com> In-Reply-To: <53D0148B.4090206@gmail.com> Date: Wed, 23 Jul 2014 16:21:06 -0700 Message-ID: <04b901cfa6cc$c8363a50$58a2aef0$@viewds.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLGM5FMqYzc6UiaebJ5/hLKUG3h2AL7pTZ/Ai/pdtqZl9Wt8A== Content-Language: en-au Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JqSF79h3K6z92CYi93h_k0kMkXk Subject: Re: [OAUTH-WG] Please help me understand OAuth 2.0 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, 23 Jul 2014 23:21:14 -0000 >> IMHO OAuth2 is becoming much bigger... Take the client credentials grant. People are using it today in the traditional scenarios, because OAuth2 tokens have good security properties. Agreed. -gil From nobody Wed Jul 23 18:43:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F0D1A03B1 for ; Wed, 23 Jul 2014 18:43:31 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjDP6ImPidY8 for ; Wed, 23 Jul 2014 18:43:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B8C1A03B8 for ; Wed, 23 Jul 2014 18:43:17 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) with Microsoft SMTP Server (TLS) id 15.0.995.11; Thu, 24 Jul 2014 01:43:15 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0995.011; Thu, 24 Jul 2014 01:43:15 +0000 From: Anthony Nadalin To: John Bradley , "torsten@lodderstedt.net" Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpdsDt+c24NfaK06ekEi1OvV9MZutFmeAgABuQQCAACfBgIAABwoAgAAFHwCAACJ8AIAABDOAgAAAxwCAAASJAIAAAz+AgAAE4ACAAAGWgIAAEq+AgAAJNoCAAAOsAIAAAq8AgAAGTgCAAA3vkIAAT38w Date: Thu, 24 Jul 2014 01:43:14 +0000 Message-ID: <3e463e686b2e4c5f87ef26969ef967c6@BLUPR03MB309.namprd03.prod.outlook.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> In-Reply-To: <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.165.189.130] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(51704005)(377454003)(377424004)(189002)(24454002)(51444003)(76482001)(93886003)(20776003)(31966008)(15202345003)(77982001)(33646002)(66066001)(4396001)(16236675004)(54356999)(551544002)(46102001)(21056001)(64706001)(85306003)(561944003)(105586002)(74316001)(81342001)(101416001)(99396002)(87936001)(92566001)(2656002)(15975445006)(107046002)(81542001)(80022001)(19580405001)(83072002)(19300405004)(106356001)(19625215002)(15395725005)(74662001)(83322001)(74502001)(79102001)(76576001)(19580395003)(106116001)(99286002)(19617315012)(95666004)(86362001)(50986999)(85852003)(86612001)(76176999)(108616002)(42262001)(24736002)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB309; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_3e463e686b2e4c5f87ef26969ef967c6BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lKz9L1X6UE2IccWP0MupKqazt0g Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 01:43:31 -0000 --_000_3e463e686b2e4c5f87ef26969ef967c6BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PlNvbWV0aGluZyByZWFsbHkgdXNlZnVsIHRvIGRvIHdvdWxkIGJlIHNvcnRpbmcgb3V0IGNoYW5u ZWxfaWQgc28gd2UgY2FuIGRvIFBvUCBmb3IgaWQgdG9rZW5zIHRvIG1ha2UgdGhlbSBhbmQgb3Ro ZXIgY29va2llcyBzZWN1cmUgaW4gdGhlIGZyb250IGNoYW5uZWwuICAgSSB0aGluayB0aGF0IGlz IGEgYmV0dGVyIHVzZSBvZiB0aW1lDQoNCkZvbGtzIGFyZSBhbHJlYWR5IHdvcmtpbmcgb24gdGhp cyBhbmQgaXQgZG9lcyBub3QgdGFrZSBhIGFueXRoaW5nIGZyb20gT0F1dGggdG8gbWFrZSBpdCB3 b3JrLCBPQXV0aCBUb2tlbnMgY2FuIGJlIHVzZWQgYW5kIHRoZXJlIGlzIG5vdCBhIG5lZWQgZm9y IE9BdXRoIFBPUCBUb2tlbnMuIEE0QyBpcyBhbHJlYWR5IGluIHVzZSBvbiBvbmUgb2YgdGhlIGxh cmdlc3QgSWRQcywgYnV0IEkgZG9u4oCZdCB0aGluayB5b3Ugd291bGQgdW5kZXJzdGFuZCBob3cg dXNlZnVsIGl0IGlzDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAy MDE0IDE6NTQgUE0NClRvOiB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldA0KQ2M6IG9hdXRoQGlldGYu b3JnIGxpc3QNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQNCg0KSSB0aG91Z2h0IEkg ZGlkIHBvc3QgdGhpcyB0byB0aGUgbGlzdC4NCg0KSSBndWVzcyBJIGhpdCB0aGUgd3JvbmcgcmVw bHkgb24gbXkgcGhvbmUuDQoNCkpvaG4gQi4NClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gSnVs IDIzLCAyMDE0LCBhdCA0OjUwIFBNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KDQp3ZSBhcmUgdHdvLCBhdCBsZWFzdCA6LSkN Cg0KV2h5IGRpZG4ndCB5b3UgcG9zdCB0aGlzIG9uIHRoZSBsaXN0Pw0KDQpXaGVuIHdpbGwgYmUg YmUgYXJyaXZpbmc/DQoNCkFtIDIzLjA3LjIwMTQgMTY6MzksIHNjaHJpZWIgSm9obiBCcmFkbGV5 Og0KSWFuIEdsYXplciBtZW50aW9uZWQgdGhpcyBpbiBoaXMga2V5bm90ZSBhdCBDSVMgeWVzdGVy ZGF5Lg0KDQpIaXMgYWR2aWNlIHdhcyBwbGVhc2Ugc3RvcCwgIHdlIGFyZSBjcmVhdGluZyBjb25m dXNpb24gYW5kIHVuY2VydGFpbnR5Lg0KDQpXZSBhcmUgYmVjb21pbmcgb3VyIG93biB3b3J0IGVu ZW15LiAoIG15IHZpZXcgdGhvdWdoIElhbiBtYXkgc2hhcmUgaXQpDQoNClJldHVybmluZyBqdXN0 IGFuIGlkXyB0b2tlbiBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCBoYXMgbGl0dGxlIHJlYWwgdmFs dWUuDQoNClNvbWV0aGluZyByZWFsbHkgdXNlZnVsIHRvIGRvIHdvdWxkIGJlIHNvcnRpbmcgb3V0 IGNoYW5uZWxfaWQgc28gd2UgY2FuIGRvIFBvUCBmb3IgaWQgdG9rZW5zIHRvIG1ha2UgdGhlbSBh bmQgb3RoZXIgY29va2llcyBzZWN1cmUgaW4gdGhlIGZyb250IGNoYW5uZWwuICAgSSB0aGluayB0 aGF0IGlzIGEgYmV0dGVyIHVzZSBvZiB0aW1lLg0KDQpJIG1heSBiZSBpbiB0aGUgbWlub3JpdHkg b3BpbmlvbiBvbiB0aGF0LCAgaXQgd29uJ3QgYmUgdGhlIGZpcnN0IHRpbWUuDQoNCkpvaG4gQi4N ClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gSnVsIDIzLCAyMDE0LCBhdCA0OjA0IFBNLCBUb3Jz dGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBs b2RkZXJzdGVkdC5uZXQ+PiB3cm90ZToNCllvdSBhcmUgcmlnaHQgZnJvbSBhIHRoZW9yZXRpY2Fs IHBlcnNwZWN0aXZlLiBQcmFjdGljYWxseSB0aGlzIHdhcyBjYXVzZWQgYnkgZWRpdG9yaWFsIGRl Y2lzaW9ucyBkdXJpbmcgdGhlIGNyZWF0aW9uIG9mIHRoZSBSRkMuIEFzIGZhciBhcyBJIHJlbWVt YmVyLCB0aGVyZSB3YXMgYSBkZWZpbml0aW9uIG9mIHRoZSAob25lKSB0b2tlbiBlbmRwb2ludCBy ZXNwb25zZSBpbiBlYXJseSB2ZXJzaW9ucy4gTm8gb25lIGV2ZXJ5IGNvbnNpZGVyZWQgdG8gTk9U IHJlc3BvbmQgd2l0aCBhbiBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQuIFNv IG9uZSBtaWdodCBjYWxsIGl0IGFuIGltcGxpY2l0IGFzc3VtcHRpb24uDQoNCkknbSB3b3JyaWVk IHRoYXQgcGVvcGxlIGdldCB0b3RhbGx5IGNvbmZ1c2VkIGlmIGFuIGV4Y2VwdGlvbiBpcyBpbnRy b2R1Y2VkIG5vdyBnaXZlbiB0aGUgYnJvYWQgYWRvcHRpb24gb2YgT0F1dGggYmFzZWQgb24gdGhp cyBhc3N1bXB0aW9uLg0KDQpyZWdhcmRzLA0KVG9yc3Rlbi4NCg0KQW0gMjMuMDcuMjAxNCB1bSAx NTo0MSBzY2hyaWViIFRob21hcyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxtYWlsdG86dC5i cm95ZXJAZ21haWwuY29tPj46DQoNCklzIGl0IHNhaWQgYW55d2hlcmUgdGhhdCBBTEwgZ3JhbnQg dHlwZXMgTVVTVCB1c2UgU2VjdGlvbiA1LjEgcmVzcG9uc2VzPyBFYWNoIGdyYW50IHR5cGUgcmVm ZXJlbmNlcyBTZWN0aW9uIDUuMSwgYW5kICJhY2Nlc3MgdG9rZW4gcmVxdWVzdCIgaXMgb25seSBk ZWZpbmVkIGluIHRoZSBjb250ZXh0IG9mIHRoZSBkZWZpbmVkIGdyYW50IHR5cGVzLiBTZWN0aW9u IDIuMiBkb2Vzbid0IHRhbGsgYWJvdXQgdGhlIHJlcXVlc3Qgb3IgcmVzcG9uc2UgZm9ybWF0Lg0K TGUgMjMganVpbC4gMjAxNCAyMTozMiwgIk5hdCBTYWtpbXVyYSIgPHNha2ltdXJhQGdtYWlsLmNv bTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gYSDDqWNyaXQgOg0KSXMgaXQ/IEFwYXJ0IGZy b20gdGhlIGltcGxpY2l0IGdyYW50IHRoYXQgZG9lcyBub3QgdXNlIHRva2VuIGVuZHBvaW50LCBh bGwgb3RoZXIgZ3JhbnQgcmVmZXJlbmNlcyBzZWN0aW9uIDUuMSBmb3IgdGhlIHJlc3BvbnNlLCBp LmUuLCBhbGwgc2hhcmVzIHRoZSBzYW1lIHJlc3BvbnNlLg0KDQoyMDE0LTA3LTIzIDE1OjE4IEdN VC0wNDowMCBUaG9tYXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVy QGdtYWlsLmNvbT4+Og0KDQpJIGhhZG4ndCByZWFsaXplZCB0aGUgSlNPTiByZXNwb25zZSB0aGF0 IHJlcXVpcmVzIHRoZSBhY2Nlc3NfdG9rZW4gZmllbGQgaXMgZGVmaW5lZCBwZXIgZ3JhbnRfdHlw ZSwgc28gSSdkIGJlIE9LIHRvICJleHRlbmQgdGhlIHNlbWFudGljcyIgYXMgaW4gdGhlIGN1cnJl bnQgZHJhZnQuDQpUaGF0IHdhcyBhY3R1YWxseSBteSBtYWluIGNvbmNlcm46IHRoYXQgdGhlIHRv a2VuIGVuZHBvaW50IG1hbmRhdGVzIGFjY2Vzc190b2tlbjsgYnV0IGl0cyBhY3R1YWxseSBub3Qg dGhlIGNhc2UuDQpMZSAyMyBqdWlsLiAyMDE0IDIwOjQ2LCAiTmF0IFNha2ltdXJhIiA8c2FraW11 cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiBhIMOpY3JpdCA6DQoNCkkg YWdyZWUgd2l0aCBKb2huIHRoYXQgb3ZlcmxvYWRpbmcgcmVzcG9uc2VfdHlwZSBAIGF1dGh6IGVu ZHBvaW50IGlzIGEgYmFkIGlkZWEuIEl0IGNvbXBsZXRlbHkgY2hhbmdlcyB0aGUgc2VtYW50aWNz IG9mIHRoaXMgcGFyYW1ldGVyLiBOT1RFOiB3aGF0IEkgd2FzIHByb3Bvc2luZyB3YXMgbm90IHRo aXMgcGFyYW1ldGVyLCBidXQgYSBuZXcgcGFyYW1ldGVyIHJlc3BvbnNlX3R5cGUgQCB0b2tlbiBl bmRwb2ludC4NCg0KSSBhbHNvIHRoaW5rIG92ZXJsb2FkaW5nIGdyYW50X3R5cGUgaXMgYSBiYWQg aWRlYSBzaW5jZSBpdCBjaGFuZ2VzIGl0cyBzZW1hbnRpY3MuIEkgcXVvdGUgdGhlIGRlZmluaXRp b24gaGVyZSBhZ2FpbjoNCg0KZ3JhbnQNCiAgICBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUg cmVzb3VyY2Ugb3duZXIncyBhdXRob3JpemF0aW9uDQoNCmdyYW50X3R5cGUNCnR5cGUgb2YgZ3Jh bnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW4N Cg0KSXQgaXMgbm90IGFib3V0IGNvbnRyb2xsaW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJv bSB0aGUgdG9rZW4gZW5kcG9pbnQsIGJ1dCB0aGUgaGludCB0byB0aGUgdG9rZW4gZW5kcG9pbnQg ZGVzY3JpYmluZyB0aGUgdHlwZSBvZiBjcmVkZW50aWFsIHRoZSBlbmRwb2ludCBoYXMgcmVjZWl2 ZWQuIEl0IHNlZW1zIHRoZSAiY29udHJvbCBvZiB3aGF0IGlzIGJlaW5nIHJldHVybmVkIGZyb20g dG9rZW4gZW5kcG9pbnQiICBpcyBqdXN0IGEgc2lkZSBlZmZlY3QuDQoNCkkgYW0gc29tZXdoYXQg YW1iaXZhbGVudFsxXSBpbiBjaGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mIHRva2VuIGVuZHBvaW50 LCBidXQgaW4gYXMgbXVjaCBhcyAidGV4dCBpcyB0aGUga2luZyIgZm9yIGEgc3BlYy4sIHdlIHBy b2JhYmx5IHNob3VsZCBub3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgaXQgYXMgVG9yc3RlbiBw b2ludHMgb3V0LiBJZiBpdCBpcyBvayB0byBjaGFuZ2UgdGhpcyBzZW1hbnRpY3MsIEkgYmVsaWV2 ZSBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXIgdG8gdGhpcyBlbmRwb2ludCB0byBjb250cm9sIHRo ZSByZXNwb25zZSB3b3VsZCBiZSB0aGUgYmVzdCB3YXkgdG8gZ28uIFRoaXMgaXMgd2hhdCBJIGhh dmUgZGVzY3JpYmVkIHByZXZpb3VzbHkuDQoNCkRlZmluaW5nIGEgbmV3IGVuZHBvaW50IHRvIHNl bmQgY29kZSB0byBnZXQgSUQgVG9rZW4gYW5kIGZvcmJpZGRpbmcgdGhlIHVzZSBvZiBpdCBhZ2Fp bnN0IHRva2VuIGVuZHBvaW50IHdvdWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBhbnkg ZXhpc3RpbmcgcGFyYW1ldGVyIG9yIGVuZHBvaW50LCB3aGljaCBpcyBnb29kLiBIb3dldmVyLCBJ IGRvdWJ0IGlmIGl0IGlzIG5vdCB3b3J0aCBkb2luZy4gV2hhdCdzIHRoZSBwb2ludCBvZiBhdm9p ZGluZyBhY2Nlc3MgdG9rZW4gc2NvcGVkIHRvIFVzZXJJbmZvIGVuZHBvaW50IGFmdGVyIGFsbD8g RGVmaW5pbmcgYSBuZXcgZW5kcG9pbnQgZm9yIGp1c3QgYXZvaWRpbmcgdGhlIGFjY2VzcyB0b2tl biBmb3IgdXNlcmluZm8gZW5kcG9pbnQgc2VlbXMgd2F5IHRvbyBtdWNoIHRoZSBoZWF2eSB3YWl0 IHdheSBhbmQgaXQgYnJlYWtzIGludGVyb3BlcmFiaWxpeTogaXQgZGVmZWF0cyB0aGUgcHVycG9z ZSBvZiBzdGFuZGFyZGl6YXRpb24uDQoNCkkgaGF2ZSBzdGFydGVkIGZlZWxpbmcgdGhhdCBubyBj aGFuZ2UgaXMgdGhlIGJlc3Qgd2F5IG91dC4NCg0KTmF0DQoNClsxXSAgSWYgaW5zdGVhZCBvZiBz YXlpbmcgIlRva2VuIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvIGV4Y2hhbmdlIGFu IGF1dGhvcml6YXRpb24gZ3JhbnQgZm9yIGFuIGFjY2VzcyB0b2tlbiwgdHlwaWNhbGx5IHdpdGgg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIiwgaXQgd2VyZSBzYXlpbmcgIlRva2VuIGVuZHBvaW50IC0g dXNlZCBieSB0aGUgY2xpZW50IHRvIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgZm9y IHRva2VucywgdHlwaWNhbGx5IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0aW9uIiwgdGhlbiBpdCB3 b3VsZCBoYXZlIGJlZW4gT0suIEl0IGlzIGFuIGV4cGFuc2lvbiBvZiB0aGUgY2FwYWJpbGl0eSBy YXRoZXIgdGhhbiBjaGFuZ2luZyB0aGUgc2VtYW50aWNzLg0KDQoNCjIwMTQtMDctMjMgMTM6Mzkg R01ULTA0OjAwIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj46DQpZb3UgbmVlZCB0aGUgYWx0ZXJuYXRpdmUg cmVzcG9uc2VfdHlwZSB2YWx1ZSAoImNvZGVfZm9yX2lkX3Rva2VuIiBpbiB0aGUgQTRDIGRyYWZ0 KSB0byB0ZWxsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciB0byByZXR1cm4gYSBjb2RlIHRvIGJl IHVzZWQgd2l0aCB0aGUgbmV3IGdyYW50IHR5cGUsIHJhdGhlciB0aGFuIG9uZSB0byB1c2Ugd2l0 aCB0aGUgImF1dGhvcml6YXRpb25fY29kZSIgZ3JhbnQgdHlwZSAod2hpY2ggaXMgd2hhdCByZXNw b25zZV90eXBlPWNvZGUgZG9lcykuDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBK b2huIEJyYWRsZXkNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMywgMjAxNCAxMDozMyBBTQ0KVG86 IHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4N Cg0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0 aC12Mi11c2VyLWE0Yy0wNS50eHQNCg0KDQoNCklmIHdlIHVzZSB0aGUgdG9rZW4gZW5kcG9pbnQg dGhlbiBhIG5ldyBncmFudF90eXBlIGlzIHRoZSBiZXN0IHdheS4NCg0KSXQgc29ydCBvZiBvdmVy bG9hZHMgY29kZSwgYnV0IHRoYXQgaXMgYmV0dGVyIHRoYW4gbWVzc2luZyB3aXRoIHJlc3BvbnNl X3R5cGUgZm9yIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHRvIGNoYW5nZSB0aGUgcmVzcG9u c2UgZnJvbSB0aGUgdG9rZW5fZW5kcG9pbnQuICBUaGF0IGlzIGluIG15IG9waW5pb24gYSBjaGFt cGlvbiBiYWQgaWRlYS4NCg0KSW4gZGlzY3Vzc2lvbnMgZGV2ZWxvcGluZyBDb25uZWN0IHdlIGRl Y2lkZWQgbm90IHRvIG9wZW4gdGhpcyBjYW4gb2Ygd29ybXMgYmVjYXVzZSBubyBnb29kIHdvdWxk IGNvbWUgb2YgaXQuDQoNClRoZSB0b2tlbl9lbmRwb2ludCByZXR1cm5zIGEgYWNjZXNzIHRva2Vu LiAgTm90aGluZyByZXF1aXJlcyBzY29wZSB0byBiZSBhc3NvY2lhdGVzIHdpdGggdGhlIHRva2Vu Lg0KDQpUaGF0IGlzIHRoZSBiZXN0IHNvbHV0aW9uLiAgTm8gY2hhbmdlIHJlcXVpcmVkLiAgQmV0 dGVyIGludGVyb3BlcmFiaWxpdHkgaW4gbXkgb3Bpbmlvbi4NCg0KU3RpbGwgb24gbXkgd2F5IHRv IFRPLCBnZXR0aW5nIGluIGxhdGVyIHRvZGF5Lg0KDQpKb2huIEIuDQoNCg0KDQpTZW50IGZyb20g bXkgaVBob25lDQoNCk9uIEp1bCAyMywgMjAxNCwgYXQgMTI6MTUgUE0sIHRvcnN0ZW5AbG9kZGVy c3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6DQoNClRoZSAi cmVzcG9uc2UgdHlwZSIgb2YgdGhlIHRva2VuIGVuZHBvaW50IGlzIGNvbnRyb2xsZWQgYnkgdGhl IHZhbHVlIG9mIHRoZSBwYXJhbWV0ZXIgImdyYW50X3R5cGUiLiBTbyB0aGVyZSBpcyBubyBuZWVk IHRvIGludHJvZHVjZSBhIG5ldyBwYXJhbWV0ZXIuDQoNCndydCB0byBhIHBvdGVudGlhbCAibm9f YWNjZXNzX3Rva2VuIiBncmFudCB0eXBlLiBJIGRvIG5vdCBjb25zaWRlciB0aGlzIGEgZ29vZCBp ZGVhIGFzIGl0IGNoYW5nZXMgdGhlIHNlbWFudGljcyBvZiB0aGUgdG9rZW4gZW5kcG9pbnQgKGFz IGFscmVhZHkgcG9pbnRlZCBvdXQgYnkgVGhvbWFzKS4gVGhpcyBlbmRwb2ludCBBTFdBWVMgcmVz cG9uZHMgd2l0aCBhbiBhY2Nlc3MgdG9rZW4gdG8gYW55IGdyYW50IHR5cGUuIEkgdGhlcmVmb3Jl IHdvdWxkIHByZWZlciB0byB1c2UgYW5vdGhlciBlbmRwb2ludCBmb3IgdGhlIGludGVuZGVkIHB1 cnBvc2UuDQoNCnJlZ2FyZHMsDQpUb3JzdGVuLg0KDQoNCg0KQW0gMjMuMDcuMjAxNCAxMzowNCwg c2NocmllYiBOYXQgU2FraW11cmE6DQpJTUhPLCBjaGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mICJy ZXNwb25zZV90eXBlIiBAIGF1dGh6IGVuZHBvaW50IHRoaXMgd2F5IGlzIG5vdCBhIGdvb2QgdGhp bmcuDQoNCkluc3RlYWQsIGRlZmluaW5nIGEgbmV3IHBhcmFtZXRlciAicmVzcG9uc2VfdHlwZSIg QCB0b2tlbiBlbmRwb2ludCwgYXMgSSBkZXNjcmliZWQgaW4gbXkgcHJldmlvdXMgbWVzc2FnZSwN CnByb2JhYmx5IGlzIGJldHRlci4gQXQgbGVhc3QsIGl0IGRvZXMgbm90IGNoYW5nZSB0aGUgc2Vt YW50aWNzIG9mIHRoZSBwYXJhbWV0ZXJzIG9mIFJGQzY3NDkuDQoNCiBOYXQNCg0KMjAxNC0wNy0y MyAxMjo0OCBHTVQtMDQ6MDAgVGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPG1haWx0 bzp0LmJyb3llckBnbWFpbC5jb20+PjoNCk5vLCBJIG1lYW4gcmVzcG9uc2VfdHlwZT1ub25lIGFu ZCByZXNwb25zZV90eXBlPWlkX3Rva2VuIGRvbid0IGdlbmVyYXRlIGEgY29kZSBvciBhY2Nlc3Mg dG9rZW4gc28geW91IGRvbid0IHVzZSB0aGUgVG9rZW4gRW5kcG9pbnQgKHdoaWNoIGlzIG5vdCB0 aGUgc2FtZSBhcyB0aGUgQXV0aGVudGljYXRpb24gRW5kcG9pbnQgQlRXKS4NCldpdGggcmVzcG9u c2VfdHlwZT1jb2RlX2Zvcl9pZF90b2tlbiwgeW91IGdldCBhIGNvZGUgYW5kIGV4Y2hhbmdlIGl0 IGZvciBhbiBpZF90b2tlbiBvbmx5LCByYXRoZXIgdGhhbiBhbiBhY2Nlc3NfdG9rZW4sIHNvIHlv dSdyZSBjaGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mIHRoZSBUb2tlbiBFbmRwb2ludC4NCg0KSSdt IG5vdCBzYXlpbmcgaXQncyBhIGJhZCB0aGluZywganVzdCB0aGF0IHlvdSBjYW4ndCByZWFsbHkg Y29tcGFyZSBub25lIGFuZCBpZF90b2tlbiB3aXRoIGNvZGVfZm9yX2lkX3Rva2VuLg0KDQpPbiBX ZWQsIEp1bCAyMywgMjAxNCBhdCA2OjQ1IFBNLCBSaWNoZXIsIEp1c3RpbiBQLiA8anJpY2hlckBt aXRyZS5vcmc8bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPj4gd3JvdGU6DQpJdCdzIG9ubHkgIm5v dCB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQiIGJlY2F1c2UgdGhlIHRva2VuIGVuZHBvaW50IGNv cHktcGFzdGVkIGFuZCByZW5hbWVkIHRoZSBhdXRoZW50aWNhdGlvbiBlbmRwb2ludC4NCg0KIC0t IEp1c3Rpbg0KDQpPbiBKdWwgMjMsIDIwMTQsIGF0IDk6MzAgQU0sIFRob21hcyBCcm95ZXIgPHQu YnJveWVyQGdtYWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPj4gd3JvdGU6DQoNCkV4 Y2VwdCB0aGF0IHRoZXNlIGFyZSBhYm91dCBub3QgdXNpbmcgdGhlIFRva2VuIEVuZHBvaW50IGF0 IGFsbCwgd2hlcmVhcyB0aGUgY3VycmVudCBwcm9wb3NhbCBpcyBhYm91dCB0aGUgVG9rZW4gRW5k cG9pbnQgbm90IHJldHVybmluZyBhbiBhY2Nlc3NfdG9rZW4gZmllbGQgaW4gdGhlIEpTT04uDQoN Ck9uIFdlZCwgSnVsIDIzLCAyMDE0IGF0IDQ6MjYgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3Jv dGU6DQpUaGUgcmVzcG9uc2VfdHlwZSAibm9uZSIgaXMgYWxyZWFkeSB1c2VkIGluIHByYWN0aWNl LCB3aGljaCByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi4gIEl0IHdhcyBhY2NlcHRlZCBieSB0aGUg ZGVzaWduYXRlZCBleHBlcnRzIGFuZCByZWdpc3RlcmVkIGluIHRoZSBJQU5BIE9BdXRoIEF1dGhv cml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2UgVHlwZXMgcmVnaXN0cnkgYXQgaHR0cDovL3d3dy5p YW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueG1s I2VuZHBvaW50LiAgVGhlIHJlZ2lzdGVyZWQgImlkX3Rva2VuIiByZXNwb25zZSB0eXBlIGFsc28g cmV0dXJucyBubyBhY2Nlc3MgdG9rZW4uDQoNClNvIEkgdGhpbmsgdGhlIHF1ZXN0aW9uIG9mIHdo ZXRoZXIgcmVzcG9uc2UgdHlwZXMgdGhhdCByZXN1bHQgaW4gbm8gYWNjZXNzIHRva2VuIGJlaW5n IHJldHVybmVkIGFyZSBhY2NlcHRhYmxlIHdpdGhpbiBPQXV0aCAyLjAgaXMgYWxyZWFkeSBzZXR0 bGVkLCBhcyBhIHByYWN0aWNhbCBtYXR0ZXIuICBMb3RzIG9mIE9BdXRoIGltcGxlbWVudGF0aW9u cyBhcmUgYWxyZWFkeSB1c2luZyBzdWNoIHJlc3BvbnNlIHR5cGVzLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN CkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IFdlZG5lc2Rh eSwgSnVseSAyMywgMjAxNCA3OjA5IEFNDQpUbzogTmF0IFNha2ltdXJhDQpDYzogPG9hdXRoQGll dGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMt MDUudHh0DQoNClllcy4gVGhpcyBpcyB3aHkgaXQgaGFzIHRvIGJlIGRpc2N1c3NlZCBpbiB0aGUg SUVURi4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0 dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KT24gSnVsIDIzLCAyMDE0LCBhdCA5OjQzIEFN LCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwu Y29tPj4gd3JvdGU6DQoNClJlYWRpbmcgYmFjayB0aGUgUkZDNjc0OSwgSSBhbSBub3Qgc3VyZSBp ZiB0aGVyZSBpcyBhIGdvb2Qgd2F5IG9mIHN1cHByZXNzaW5nIGFjY2VzcyB0b2tlbiBmcm9tIHRo ZSByZXNwb25zZSBhbmQgc3RpbGwgYmUgT0F1dGguIEl0IHdpbGwgYnJlYWsgd2hvbGUgYnVuY2gg b2YgaW1wbGljaXQgZGVmaW5pdGlvbnMgbGlrZToNCg0KYXV0aG9yaXphdGlvbiBzZXJ2ZXINCiAg ICAgIFRoZSBzZXJ2ZXIgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0ZXIg c3VjY2Vzc2Z1bGx5DQogICAgICBhdXRoZW50aWNhdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIgYW5k IG9idGFpbmluZyBhdXRob3JpemF0aW9uLg0KDQpBZnRlciBhbGwsIE9BdXRoIGlzIGFsbCBhYm91 dCBpc3N1aW5nIGFjY2VzcyB0b2tlbnMuDQoNCkFsc28sIEkgdGFrZSBiYWNrIG15IHN0YXRlbWVu dCBvbiB0aGUgZ3JhbnQgdHlwZSBpbiBteSBwcmV2aW91cyBtYWlsLg0KDQpUaGUgZGVmaW5pdGlv biBvZiBncmFudCBhbmQgZ3JhbnRfdHlwZSBhcmUgcmVzcGVjdGl2ZWx5Og0KDQpncmFudA0KICAg IGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGF1dGhvcml6YXRp b24NCg0KZ3JhbnRfdHlwZQ0KICAgIChzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSkgdHlwZSBvZiBn cmFudCBzZW50IHRvIHRoZSB0b2tlbiBlbmRwb2ludCB0byBvYnRhaW4gdGhlIGFjY2VzcyB0b2tl bg0KDQpUaHVzLCB0aGUgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgaW4gdGhpcyBj YXNlIGlzIHN0aWxsICdjb2RlJy4NCg0KUmVzcG9uc2UgdHlwZSBvbiB0aGUgb3RoZXIgaGFuZCBp cyBub3Qgc28gd2VsbCBkZWZpbmVkIGluIFJGQzY3NDksIGJ1dCBpdCBzZWVtcyBpdCBpcyByZXBy ZXNlbnRpbmcgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVu ZHBvaW50LiBUbyBleHByZXNzIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0b2tlbiBlbmRw b2ludCwgcGVyaGFwcyBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXIgdG8gdGhlIHRva2VuIGVuZHBv aW50LCB3aGljaCBpcyBhIHBhcmFsbGVsIHRvIHRoZSByZXNwb25zZV90eXBlIHRvIHRoZSBBdXRo b3JpemF0aW9uIEVuZHBvaW50IHNlZW1zIHRvIGJlIGEgbW9yZSBzeW1tZXRyaWMgd2F5LCB0aG91 Z2ggSSBhbSBub3Qgc3VyZSBhdCBhbGwgaWYgdGhhdCBpcyBnb2luZyB0byBiZSBPQXV0aCBhbnkg bW9yZS4gT25lIHN0cmF3LW1hbiBpcyB0byBkZWZpbmUgYSBuZXcgcGFyYW1ldGVyIGNhbGxlZCBy ZXNwb25zZV90eXBlIHRvIHRoZSB0b2tlbiBlbmRwb2ludCBzdWNoIGFzOg0KDQpyZXNwb25zZV90 eXBlDQogICAgT1BUSU9OQUwuIEEgc3RyaW5nIHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJlIHJl dHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50Lg0KDQpUaGVuIGRlZmluZSB0aGUgYmVoYXZp b3Igb2YgdGhlIGVuZHBvaW50IGFjY29yZGluZyB0byB0aGUgdmFsdWVzIGFzIHRoZSBwYXJhbGxl bCB0byB0aGUgbXVsdGktcmVzcG9uc2UgdHlwZSBzcGVjLg0KaHR0cDovL29wZW5pZC5uZXQvc3Bl Y3Mvb2F1dGgtdjItbXVsdGlwbGUtcmVzcG9uc2UtdHlwZXMtMV8wLmh0bWwNCg0KTmF0DQoNCg0K DQoNCjIwMTQtMDctMjMgNzoyMSBHTVQtMDQ6MDAgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xl LmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PjoNClRoZSBkcmFmdCBpcyB2ZXJ5IGNs ZWFyLg0KDQpQaGlsDQoNCk9uIEp1bCAyMywgMjAxNCwgYXQgMDo0NiwgTmF0IFNha2ltdXJhIDxz YWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhl IG5ldyBncmFudCB0eXBlIHRoYXQgSSB3YXMgdGFsa2luZyBhYm91dCB3YXMNCiJhdXRob3JpemF0 aW9uX2NvZGVfYnV0X2RvX25vdF9yZXR1cm5fYWNjZXNzX25vcl9yZWZyZXNoX3Rva2VuIiwgc28g dG8gc3BlYWsuDQpJdCBkb2VzIG5vdCByZXR1cm4gYW55dGhpbmcgcGVyIHNlLCBidXQgYW4gZXh0 ZW5zaW9uIGNhbiBkZWZpbmUgc29tZXRoaW5nIG9uIHRvcCBvZiBpdC4NCg0KVGhlbiwgT0lEQyBj YW4gZGVmaW5lIGEgYmluZGluZyB0byBpdCBzbyB0aGF0IHRoZSBiaW5kaW5nIG9ubHkgcmV0dXJu cyBJRCBUb2tlbi4NClRoaXMgYmluZGluZyB3b3JrIHNob3VsZCBiZSBkb25lIGluIE9JREYuIFNo b3VsZCB0aGVyZSBiZSBzdWNoIGEgZ3JhbnQgdHlwZSwNCml0IHdpbGwgYmUgYW4gZXh0cmVtZWx5 IHNob3J0IHNwZWMuDQoNCkF0IHRoZSBzYW1lIHRpbWUsIGlmIGFueSBvdGhlciBzcGVjaWZpY2F0 aW9uIHdhbnRlZCB0byBkZWZpbmUNCm90aGVyIHR5cGUgb2YgdG9rZW5zIGFuZCBoYXZlIGl0IHJl dHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LA0KaXQgY2FuIGFsc28gdXNlIHRoaXMgZ3Jh bnQgdHlwZS4NCg0KSWYgd2hhdCB5b3Ugd2FudCBpcyB0byBkZWZpbmUgYSBuZXcgZ3JhbnQgdHlw ZSB0aGF0IHJldHVybnMgSUQgVG9rZW4gb25seSwNCnRoZW4sIEkgYW0gd2l0aCBKdXN0aW4uIFNp bmNlICJvdGhlciByZXNwb25zZSB0aGFuIElEIFRva2VuIiBpcyBvbmx5DQp0aGVvcmV0aWNhbCwg dGhpcyBpcyBhIG1vcmUgcGxhdXNpYmxlIHdheSBmb3J3YXJkLCBJIHN1cHBvc2UuDQoNCk5hdA0K DQoyMDE0LTA3LTIyIDE0OjMwIEdNVC0wNDowMCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5l ZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+Og0KU28gdGhlIGRyYWZ0IHdvdWxkIGxpdGVyYWxs eSB0dXJuIGludG86DQoNCiJUaGUgYTRjIHJlc3BvbnNlIHR5cGUgYW5kIGdyYW50IHR5cGUgcmV0 dXJuIGFuIGlkX3Rva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IHdpdGggbm8gYWNjZXNzIHRv a2VuLiBBbGwgcGFyYW1ldGVycyBhbmQgdmFsdWVzIGFyZSBkZWZpbmVkIGluIE9JREMuIg0KDQpT ZWVtcyBsaWtlIHRoZSBwZXJmZWN0IG1pbmkgZXh0ZW5zaW9uIGRyYWZ0IGZvciBPSURGIHRvIGRv Lg0KDQotLUp1c3Rpbg0KDQovc2VudCBmcm9tIG15IHBob25lLw0KDQpPbiBKdWwgMjIsIDIwMTQg MTA6MjkgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVy YUBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4gV2hhdCBhYm91dCBqdXN0IGRlZmluaW5nIGEgbmV3 IGdyYW50IHR5cGUgaW4gdGhpcyBXRz8NCj4NCj4NCj4gMjAxNC0wNy0yMiAxMjo1NiBHTVQtMDQ6 MDAgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20+PjoNCj4+DQo+PiBUaGF0IHdvdWxkIGJlIG5pY2UuIEhvd2V2ZXIgb2lkYyBzdGlsbCBu ZWVkcyB0aGUgbmV3IGdyYW50IHR5cGUgaW4gb3JkZXIgdG8gaW1wbGVtZW50IHRoZSBzYW1lIGZs b3cuDQo+Pg0KPj4gUGhpbA0KPj4NCj4+IE9uIEp1bCAyMiwgMjAxNCwgYXQgMTE6MzUsIE5hdCBT YWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3 cm90ZToNCj4+DQo+Pj4gKzEgdG8gSnVzdGluLg0KPj4+DQo+Pj4NCj4+PiAyMDE0LTA3LTIyIDk6 NTQgR01ULTA0OjAwIFJpY2hlciwgSnVzdGluIFAuIDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86 anJpY2hlckBtaXRyZS5vcmc+PjoNCj4+Pj4NCj4+Pj4gRXJyb3JzIGxpa2UgdGhlc2UgbWFrZSBp dCBjbGVhciB0byBtZSB0aGF0IGl0IHdvdWxkIG1ha2UgbXVjaCBtb3JlIHNlbnNlIHRvIGRldmVs b3AgdGhpcyBkb2N1bWVudCBpbiB0aGUgT3BlbklEIEZvdW5kYXRpb24uIEl0IHNob3VsZCBiZSBz b21ldGhpbmcgdGhhdCBkaXJlY3RseSByZWZlcmVuY2VzIE9wZW5JRCBDb25uZWN0IENvcmUgZm9y IGFsbCBvZiB0aGVzZSB0ZXJtcyBpbnN0ZWFkIG9mIHJlZGVmaW5pbmcgdGhlbS4gSXQncyBkb2lu ZyBhdXRoZW50aWNhdGlvbiwgd2hpY2ggaXMgZnVuZGFtZW50YWxseSB3aGF0IE9wZW5JRCBDb25u ZWN0IGRvZXMgb24gdG9wIG9mIE9BdXRoLCBhbmQgSSBkb24ndCBzZWUgYSBnb29kIGFyZ3VtZW50 IGZvciBkb2luZyB0aGlzIHdvcmsgaW4gdGhpcyB3b3JraW5nIGdyb3VwLg0KPj4+Pg0KPj4+PiAg LS0gSnVzdGluDQo+Pj4+DQo+Pj4+IE9uIEp1bCAyMiwgMjAxNCwgYXQgNDozMCBBTSwgVGhvbWFz IEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPG1haWx0bzp0LmJyb3llckBnbWFpbC5jb20+PiB3 cm90ZToNCj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE9uIE1vbiwgSnVsIDIxLCAy MDE0IGF0IDExOjUyIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+ Pj4gVGhhbmtzIGZvciB5b3VyIHJldmlldywgVGhvbWFzLiAgVGhlICJwcm9tcHQ9Y29uc2VudCIg ZGVmaW5pdGlvbiBiZWluZyBtaXNzaW5nIGlzIGFuIGVkaXRvcmlhbCBlcnJvci4gIEl0IHNob3Vs ZCBiZToNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBjb25zZW50DQo+Pj4+Pj4NCj4+ Pj4+PiBUaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgU0hPVUxEIHByb21wdCB0aGUgRW5kLVVzZXIg Zm9yIGNvbnNlbnQgYmVmb3JlIHJldHVybmluZyBpbmZvcm1hdGlvbiB0byB0aGUgQ2xpZW50LiBJ ZiBpdCBjYW5ub3Qgb2J0YWluIGNvbnNlbnQsIGl0IE1VU1QgcmV0dXJuIGFuIGVycm9yLCB0eXBp Y2FsbHkgY29uc2VudF9yZXF1aXJlZC4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBJ J2xsIHBsYW4gdG8gYWRkIGl0IGluIHRoZSBuZXh0IGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ PiBJdCBsb29rcyBsaWtlIHRoZSBjb25zZW50X3JlcXVpcmVkIGVycm9yIG5lZWRzIHRvIGJlIGRl ZmluZWQgdG9vLCBhbmQgeW91IG1pZ2h0IGhhdmUgZm9yZ290dGVuIHRvIGFsc28gaW1wb3J0IGFj Y291bnRfc2VsZWN0aW9uX3JlcXVpcmVkIGZyb20gT3BlbklEIENvbm5lY3QuDQo+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEkgYWdyZWUgdGhhdCB0aGVyZSdzIG5vIGRpZmZl cmVuY2UgYmV0d2VlbiBhIHJlc3BvbnNlIHdpdGggbXVsdGlwbGUgImFtciIgdmFsdWVzIHRoYXQg aW5jbHVkZXMgIm1mYSIgYW5kIG9uZSB0aGF0IGRvZXNuJ3QuICBVbmxlc3MgYSBjbGVhciB1c2Ug Y2FzZSBmb3Igd2h5ICJtZmEiIGlzIG5lZWRlZCBjYW4gYmUgaWRlbnRpZmllZCwgd2UgY2FuIGRl bGV0ZSBpdCBpbiB0aGUgbmV4dCBkcmFmdC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzLg0K Pj4+Pj4NCj4+Pj4+IEhvdyBhYm91dCAicHdkIiB0aGVuPyBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhh dCBJIHNob3VsZCByZXR1cm4gInB3ZCIgaWYgdGhlIHVzZXIgYXV0aGVudGljYXRlZCB1c2luZyBh IHBhc3N3b3JkLCBidXQgd2hhdCAidGhlIHNlcnZpY2UgaWYgYSBjbGllbnQgc2VjcmV0IGlzIHVz ZWQiIG1lYW5zIGluIHRoZSBkZWZpbml0aW9uIGZvciB0aGUgInB3ZCIgdmFsdWU/DQo+Pj4+Pg0K Pj4+Pj4gKE5vdGE6IEkga25vdyB5b3UncmUgYXQgSUVURi05MCwgSSdtIHJlYWR5IHRvIHdhaXQg J3RpbCB5b3UgY29tZSBiYWNrIDstKSApDQo+Pj4+Pg0KPj4+Pj4gLS0NCj4+Pj4+IFRob21hcyBC cm95ZXINCj4+Pj4+IC90yZQubWEuYsqBd2EuamUvPGh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2Et eHhiLmplLz4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4+IE9BdXRoQGlldGYub3JnPG1h aWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ Pj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+Pg0KPj4+DQo+Pj4NCj4+Pg0K Pj4+IC0tDQo+Pj4gTmF0IFNha2ltdXJhICg9bmF0KQ0KPj4+IENoYWlybWFuLCBPcGVuSUQgRm91 bmRhdGlvbg0KPj4+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPj4+IEBfbmF0X2VuDQo+Pj4N Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ DQo+DQo+DQo+DQo+IC0tDQo+IE5hdCBTYWtpbXVyYSAoPW5hdCkNCj4gQ2hhaXJtYW4sIE9wZW5J RCBGb3VuZGF0aW9uDQo+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPiBAX25hdF9lbg0KDQoN Cg0KLS0NCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0K aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQpAX25hdF9lbg0KDQoNCg0KLS0NCk5hdCBTYWtpbXVy YSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVy YS5vcmcvDQpAX25hdF9lbg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg0KDQoNCi0tDQpUaG9tYXMgQnJveWVyDQovdMmULm1hLmLKgXdhLmplLzxodHRwOi8veG4t LW5uYS5tYS54bi0tYndhLXh4Yi5qZS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQoNCg0KDQotLQ0KVGhvbWFzIEJyb3llcg0KL3TJlC5tYS5iyoF3YS5qZS88aHR0cDov L3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9w ZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGgg bWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4s IE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt YWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpOYXQgU2Fr aW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQuc2Fr aW11cmEub3JnLw0KQF9uYXRfZW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg== --_000_3e463e686b2e4c5f87ef26969ef967c6BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7U29tZXRoaW5nIHJlYWxseSB1 c2VmdWwgdG8gZG8gd291bGQgYmUgc29ydGluZyBvdXQgY2hhbm5lbF9pZCBzbyB3ZSBjYW4gZG8g UG9QIGZvciBpZCB0b2tlbnMgdG8gbWFrZSB0aGVtIGFuZCBvdGhlciBjb29raWVzIHNlY3VyZSBp biB0aGUgZnJvbnQgY2hhbm5lbC4gJm5ic3A7IEkgdGhpbmsgdGhhdCBpcyBhIGJldHRlciB1c2Ug b2YgdGltZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb2xrcyBhcmUgYWxyZWFkeSB3b3JraW5n IG9uIHRoaXMgYW5kIGl0IGRvZXMgbm90IHRha2UgYSBhbnl0aGluZyBmcm9tIE9BdXRoIHRvIG1h a2UgaXQgd29yaywgT0F1dGggVG9rZW5zIGNhbiBiZSB1c2VkIGFuZCB0aGVyZSBpcyBub3QgYSBu ZWVkIGZvciBPQXV0aCBQT1AgVG9rZW5zLiBBNEMgaXMgYWxyZWFkeSBpbiB1c2Ugb24gb25lIG9m IHRoZSBsYXJnZXN0IElkUHMsIGJ1dCBJIGRvbuKAmXQgdGhpbmsgeW91DQogd291bGQgdW5kZXJz dGFuZCBob3cgdXNlZnVsIGl0IGlzPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5h bWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5Kb2huIEJyYWRsZXk8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDIzLCAy MDE0IDE6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+IHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PGJyPg0K PGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZyBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb T0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12 Mi11c2VyLWE0Yy0wNS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB0aG91Z2h0IEkgZGlkIHBvc3QgdGhpcyB0byB0aGUgbGlzdC4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBndWVzcyBJIGhpdCB0aGUgd3JvbmcgcmVwbHkgb24gbXkgcGhvbmUuJm5ic3A7PGJyPg0KJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5K b2huIEIuJm5ic3A7PGJyPg0KU2VudCBmcm9tIG15IGlQaG9uZTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48YnI+DQpPbiBKdWwgMjMsIDIwMTQsIGF0IDQ6NTAgUE0sIDxhIGhyZWY9Im1haWx0bzp0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cD53ZSBhcmUgdHdvLCBhdCBsZWFz dCA6LSk8bzpwPjwvbzpwPjwvcD4NCjxwPldoeSBkaWRuJ3QgeW91IHBvc3QgdGhpcyBvbiB0aGUg bGlzdD88bzpwPjwvbzpwPjwvcD4NCjxwPldoZW4gd2lsbCBiZSBiZSBhcnJpdmluZz88bzpwPjwv bzpwPjwvcD4NCjxwPkFtIDIzLjA3LjIwMTQgMTY6MzksIHNjaHJpZWIgSm9obiBCcmFkbGV5Ojxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVm dDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JYW4gR2xhemVyIG1lbnRpb25lZCB0aGlzIGluIGhpcyBrZXlu b3RlIGF0IENJUyB5ZXN0ZXJkYXkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpcyBhZHZpY2Ugd2FzIHBsZWFzZSBzdG9wLCAmbmJz cDt3ZSBhcmUgY3JlYXRpbmcgY29uZnVzaW9uIGFuZCB1bmNlcnRhaW50eS4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgYXJlIGJl Y29taW5nIG91ciBvd24gd29ydCBlbmVteS4gKCBteSB2aWV3IHRob3VnaCBJYW4gbWF5IHNoYXJl IGl0KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5SZXR1cm5pbmcganVzdCBhbiBpZF8gdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgaGFz IGxpdHRsZSByZWFsIHZhbHVlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21ldGhpbmcgcmVhbGx5IHVzZWZ1bCB0byBkbyB3b3Vs ZCBiZSBzb3J0aW5nIG91dCBjaGFubmVsX2lkIHNvIHdlIGNhbiBkbyBQb1AgZm9yIGlkIHRva2Vu cyB0byBtYWtlIHRoZW0gYW5kIG90aGVyIGNvb2tpZXMgc2VjdXJlIGluIHRoZSBmcm9udCBjaGFu bmVsLiAmbmJzcDsgSSB0aGluayB0aGF0IGlzIGEgYmV0dGVyIHVzZSBvZiB0aW1lLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG1h eSBiZSBpbiB0aGUgbWlub3JpdHkgb3BpbmlvbiBvbiB0aGF0LCAmbmJzcDtpdCB3b24ndCBiZSB0 aGUgZmlyc3QgdGltZS4gJm5ic3A7PGJyPg0KPGJyPg0KSm9obiBCLiZuYnNwOzxicj4NClNlbnQg ZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVsIDIzLCAy MDE0LCBhdCA0OjA0IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiPnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBhcmUgcmlnaHQg ZnJvbSBhIHRoZW9yZXRpY2FsIHBlcnNwZWN0aXZlLiBQcmFjdGljYWxseSB0aGlzIHdhcyBjYXVz ZWQgYnkgZWRpdG9yaWFsIGRlY2lzaW9ucyBkdXJpbmcgdGhlIGNyZWF0aW9uIG9mIHRoZSBSRkMu IEFzIGZhciBhcyBJIHJlbWVtYmVyLCB0aGVyZSB3YXMgYSBkZWZpbml0aW9uIG9mIHRoZSAob25l KSB0b2tlbiBlbmRwb2ludCByZXNwb25zZSBpbiBlYXJseSB2ZXJzaW9ucy4gTm8gb25lDQogZXZl cnkgY29uc2lkZXJlZCB0byBOT1QgcmVzcG9uZCB3aXRoIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRo ZSB0b2tlbiBlbmRwb2ludC4gU28gb25lIG1pZ2h0IGNhbGwgaXQgYW4gaW1wbGljaXQgYXNzdW1w dGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSdtIHdvcnJpZWQgdGhhdCBwZW9wbGUgZ2V0IHRvdGFsbHkgY29uZnVzZWQgaWYgYW4gZXhj ZXB0aW9uIGlzIGludHJvZHVjZWQgbm93IGdpdmVuIHRoZSBicm9hZCBhZG9wdGlvbiBvZiBPQXV0 aCBiYXNlZCBvbiB0aGlzIGFzc3VtcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub3JzdGVuLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48YnI+DQpBbSAyMy4wNy4yMDE0IHVtIDE1OjQxIHNjaHJpZWIgVGhvbWFzIEJyb3llciAm bHQ7PGEgaHJlZj0ibWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSI+dC5icm95ZXJAZ21haWwuY29t PC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHA+SXMgaXQgc2FpZCBhbnl3aGVyZSB0aGF0IEFMTCBncmFudCB0 eXBlcyBNVVNUIHVzZSBTZWN0aW9uIDUuMSByZXNwb25zZXM/IEVhY2ggZ3JhbnQgdHlwZSByZWZl cmVuY2VzIFNlY3Rpb24gNS4xLCBhbmQgJnF1b3Q7YWNjZXNzIHRva2VuIHJlcXVlc3QmcXVvdDsg aXMgb25seSBkZWZpbmVkIGluIHRoZSBjb250ZXh0IG9mIHRoZSBkZWZpbmVkIGdyYW50IHR5cGVz LiBTZWN0aW9uIDIuMiBkb2Vzbid0IHRhbGsgYWJvdXQgdGhlIHJlcXVlc3Qgb3IgcmVzcG9uc2UN CiBmb3JtYXQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGUg MjMganVpbC4gMjAxNCAyMTozMiwgJnF1b3Q7TmF0IFNha2ltdXJhJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyBh IMOpY3JpdCA6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklzIGl0PyBBcGFydCBmcm9tIHRoZSBpbXBsaWNpdCBncmFudCB0aGF0IGRvZXMg bm90IHVzZSB0b2tlbiBlbmRwb2ludCwgYWxsIG90aGVyIGdyYW50IHJlZmVyZW5jZXMgc2VjdGlv biA1LjEgZm9yIHRoZSByZXNwb25zZSwgaS5lLiwgYWxsIHNoYXJlcyB0aGUgc2FtZSByZXNwb25z ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNC0wNy0yMyAxNToxOCBHTVQtMDQ6MDAgVGhv bWFzIEJyb3llciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSI+dC5icm95 ZXJAZ21haWwuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHA+SSBo YWRuJ3QgcmVhbGl6ZWQgdGhlIEpTT04gcmVzcG9uc2UgdGhhdCByZXF1aXJlcyB0aGUgYWNjZXNz X3Rva2VuIGZpZWxkIGlzIGRlZmluZWQgcGVyIGdyYW50X3R5cGUsIHNvIEknZCBiZSBPSyB0byAm cXVvdDtleHRlbmQgdGhlIHNlbWFudGljcyZxdW90OyBhcyBpbiB0aGUgY3VycmVudCBkcmFmdC48 YnI+DQpUaGF0IHdhcyBhY3R1YWxseSBteSBtYWluIGNvbmNlcm46IHRoYXQgdGhlIHRva2VuIGVu ZHBvaW50IG1hbmRhdGVzIGFjY2Vzc190b2tlbjsgYnV0IGl0cyBhY3R1YWxseSBub3QgdGhlIGNh c2UuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGUgMjMganVp bC4gMjAxNCAyMDo0NiwgJnF1b3Q7TmF0IFNha2ltdXJhJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86c2FraW11cmFAZ21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyBhIMOpY3Jp dCA6DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGFncmVlIHdpdGggSm9obiB0aGF0IG92ZXJsb2FkaW5nIHJlc3BvbnNl X3R5cGUgQCBhdXRoeiBlbmRwb2ludCBpcyBhIGJhZCBpZGVhLiBJdCBjb21wbGV0ZWx5IGNoYW5n ZXMgdGhlIHNlbWFudGljcyBvZiB0aGlzIHBhcmFtZXRlci4gTk9URTogd2hhdCBJIHdhcyBwcm9w b3Npbmcgd2FzIG5vdCB0aGlzIHBhcmFtZXRlciwgYnV0IGEgbmV3IHBhcmFtZXRlciByZXNwb25z ZV90eXBlIEAgdG9rZW4gZW5kcG9pbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyB0aGluayBvdmVybG9hZGluZyBncmFu dF90eXBlIGlzIGEgYmFkIGlkZWEgc2luY2UgaXQgY2hhbmdlcyBpdHMgc2VtYW50aWNzLiBJIHF1 b3RlIHRoZSBkZWZpbml0aW9uIGhlcmUgYWdhaW46Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ncmFudCZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwOyBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBhdXRob3Jp emF0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmdyYW50X3R5cGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnR5cGUgb2YgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgdG8gb2J0 YWluIHRoZSBhY2Nlc3MgdG9rZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBub3QgYWJvdXQgY29udHJvbGxpbmcgd2hh dCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCwgYnV0IHRoZSBoaW50 IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBkZXNjcmliaW5nIHRoZSB0eXBlIG9mIGNyZWRlbnRpYWwg dGhlIGVuZHBvaW50IGhhcyByZWNlaXZlZC4gSXQgc2VlbXMgdGhlICZxdW90O2NvbnRyb2wgb2Yg d2hhdCBpcyBiZWluZyByZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50JnF1b3Q7DQogJm5ic3A7 aXMganVzdCBhIHNpZGUgZWZmZWN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIHNvbWV3aGF0IGFtYml2YWxlbnRbMV0gaW4g Y2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiB0b2tlbiBlbmRwb2ludCwgYnV0IGluIGFzIG11Y2gg YXMgJnF1b3Q7dGV4dCBpcyB0aGUga2luZyZxdW90OyBmb3IgYSBzcGVjLiwgd2UgcHJvYmFibHkg c2hvdWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBpdCBhcyBUb3JzdGVuIHBvaW50cyBv dXQuIElmIGl0IGlzIG9rIHRvIGNoYW5nZSB0aGlzIHNlbWFudGljcywgSQ0KIGJlbGlldmUgZGVm aW5pbmcgYSBuZXcgcGFyYW1ldGVyIHRvIHRoaXMgZW5kcG9pbnQgdG8gY29udHJvbCB0aGUgcmVz cG9uc2Ugd291bGQgYmUgdGhlIGJlc3Qgd2F5IHRvIGdvLiBUaGlzIGlzIHdoYXQgSSBoYXZlIGRl c2NyaWJlZCBwcmV2aW91c2x5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWZpbmluZyBhIG5ldyBlbmRwb2ludCB0byBzZW5kIGNv ZGUgdG8gZ2V0IElEIFRva2VuIGFuZCBmb3JiaWRkaW5nIHRoZSB1c2Ugb2YgaXQgYWdhaW5zdCB0 b2tlbiBlbmRwb2ludCB3b3VsZCBub3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgYW55IGV4aXN0 aW5nIHBhcmFtZXRlciBvciBlbmRwb2ludCwgd2hpY2ggaXMgZ29vZC4gSG93ZXZlciwgSSBkb3Vi dCBpZiBpdCBpcyBub3Qgd29ydGggZG9pbmcuIFdoYXQncw0KIHRoZSBwb2ludCBvZiBhdm9pZGlu ZyBhY2Nlc3MgdG9rZW4gc2NvcGVkIHRvIFVzZXJJbmZvIGVuZHBvaW50IGFmdGVyIGFsbD8gRGVm aW5pbmcgYSBuZXcgZW5kcG9pbnQgZm9yIGp1c3QgYXZvaWRpbmcgdGhlIGFjY2VzcyB0b2tlbiBm b3IgdXNlcmluZm8gZW5kcG9pbnQgc2VlbXMgd2F5IHRvbyBtdWNoIHRoZSBoZWF2eSB3YWl0IHdh eSBhbmQgaXQgYnJlYWtzIGludGVyb3BlcmFiaWxpeTogaXQgZGVmZWF0cyB0aGUgcHVycG9zZSBv ZiBzdGFuZGFyZGl6YXRpb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBzdGFydGVkIGZlZWxpbmcgdGhhdCBubyBjaGFu Z2UgaXMgdGhlIGJlc3Qgd2F5IG91dC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsxXSAmbmJzcDtJZiBpbnN0ZWFkIG9mIHNheWlu ZyAmcXVvdDs8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRva2VuIGVuZHBvaW50IC0gdXNlZCBi eSB0aGUgY2xpZW50IHRvIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24mbmJzcDs8L3NwYW4+Z3Jh bnQgZm9yIGFuIGFjY2VzcyB0b2tlbiwgdHlwaWNhbGx5IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0 aW9uJnF1b3Q7LCBpdCB3ZXJlIHNheWluZyAmcXVvdDs8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlRva2VuDQogZW5kcG9pbnQgLSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gZXhjaGFuZ2UgYW4gYXV0 aG9yaXphdGlvbiZuYnNwOzwvc3Bhbj5ncmFudCBmb3IgdG9rZW5zLCB0eXBpY2FsbHkgd2l0aCBj bGllbnQgYXV0aGVudGljYXRpb24mcXVvdDssIHRoZW4gaXQgd291bGQgaGF2ZSBiZWVuIE9LLiBJ dCBpcyBhbiBleHBhbnNpb24gb2YgdGhlIGNhcGFiaWxpdHkgcmF0aGVyIHRoYW4gY2hhbmdpbmcg dGhlIHNlbWFudGljcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTQtMDctMjMgMTM6 MzkgR01ULTA0OjAwIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91IG5lZWQg dGhlIGFsdGVybmF0aXZlIHJlc3BvbnNlX3R5cGUgdmFsdWUgKCZxdW90Ozwvc3Bhbj5jb2RlX2Zv cl9pZF90b2tlbjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mcXVv dDsNCiBpbiB0aGUgQTRDIGRyYWZ0KSB0byB0ZWxsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciB0 byByZXR1cm4gYSBjb2RlIHRvIGJlIHVzZWQgd2l0aCB0aGUgbmV3IGdyYW50IHR5cGUsIHJhdGhl ciB0aGFuIG9uZSB0byB1c2Ugd2l0aCB0aGUgJnF1b3Q7YXV0aG9yaXphdGlvbl9jb2RlJnF1b3Q7 IGdyYW50IHR5cGUgKHdoaWNoIGlzIHdoYXQgcmVzcG9uc2VfdHlwZT1jb2RlIGRvZXMpLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvc3Ryb25n PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzo8YSBocmVmPSJtYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+T24gQmVoYWxmIE9mIDwvc3Bhbj48L3N0cm9uZz5Kb2huIEJyYWRs ZXk8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2VudDo8L3NwYW4+PC9zdHJvbmc+IFdlZG5lc2Rh eSwgSnVseSAyMywgMjAxNCAxMDozMyBBTTxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ubzo8L3Nw YW4+PC9zdHJvbmc+IDxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+DQp0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxzdHJvbmc+Q2M6PC9zdHJvbmc+IDxh IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPHN0 cm9uZz5TdWJqZWN0Ojwvc3Ryb25nPiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgd2UgdXNlIHRoZSB0b2tl biBlbmRwb2ludCB0aGVuIGEgbmV3IGdyYW50X3R5cGUgaXMgdGhlIGJlc3Qgd2F5LiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SXQgc29ydCBvZiBvdmVybG9hZHMgY29kZSwgYnV0IHRoYXQgaXMgYmV0dGVyIHRoYW4gbWVzc2lu ZyB3aXRoIHJlc3BvbnNlX3R5cGUgZm9yIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHRvIGNo YW5nZSB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgdG9rZW5fZW5kcG9pbnQuICZuYnNwO1RoYXQgaXMg aW4gbXkgb3Bpbmlvbg0KIGEgY2hhbXBpb24gYmFkIGlkZWEuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiBkaXNjdXNzaW9u cyBkZXZlbG9waW5nIENvbm5lY3Qgd2UgZGVjaWRlZCBub3QgdG8gb3BlbiB0aGlzIGNhbiBvZiB3 b3JtcyBiZWNhdXNlIG5vIGdvb2Qgd291bGQgY29tZSBvZiBpdC4gJm5ic3A7Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUg dG9rZW5fZW5kcG9pbnQgcmV0dXJucyBhIGFjY2VzcyB0b2tlbi4gJm5ic3A7Tm90aGluZyByZXF1 aXJlcyBzY29wZSB0byBiZSBhc3NvY2lhdGVzIHdpdGggdGhlIHRva2VuLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhdCBp cyB0aGUgYmVzdCBzb2x1dGlvbi4gJm5ic3A7Tm8gY2hhbmdlIHJlcXVpcmVkLiAmbmJzcDtCZXR0 ZXIgaW50ZXJvcGVyYWJpbGl0eSBpbiBteSBvcGluaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3RpbGwgb24gbXkgd2F5 IHRvIFRPLCBnZXR0aW5nIGluIGxhdGVyIHRvZGF5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Sm9obiBCLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJy Pg0KPGJyPg0KU2VudCBmcm9tIG15IGlQaG9uZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBKdWwgMjMsIDIwMTQsIGF0IDEyOjE1IFBNLCA8 YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiPnRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHA+VGhl ICZxdW90O3Jlc3BvbnNlIHR5cGUmcXVvdDsgb2YgdGhlIHRva2VuIGVuZHBvaW50IGlzIGNvbnRy b2xsZWQgYnkgdGhlIHZhbHVlIG9mIHRoZSBwYXJhbWV0ZXIgJnF1b3Q7Z3JhbnRfdHlwZSZxdW90 Oy4gU28gdGhlcmUgaXMgbm8gbmVlZCB0byBpbnRyb2R1Y2UgYSBuZXcgcGFyYW1ldGVyLjxvOnA+ PC9vOnA+PC9wPg0KPHA+d3J0IHRvIGEgcG90ZW50aWFsICZxdW90O25vX2FjY2Vzc190b2tlbiZx dW90OyBncmFudCB0eXBlLiBJIGRvIG5vdCBjb25zaWRlciB0aGlzIGEgZ29vZCBpZGVhIGFzIGl0 IGNoYW5nZXMgdGhlIHNlbWFudGljcyBvZiB0aGUgdG9rZW4gZW5kcG9pbnQgKGFzIGFscmVhZHkg cG9pbnRlZCBvdXQgYnkgVGhvbWFzKS4gVGhpcyBlbmRwb2ludCBBTFdBWVMgcmVzcG9uZHMgd2l0 aCBhbiBhY2Nlc3MgdG9rZW4gdG8gYW55IGdyYW50IHR5cGUuIEkgdGhlcmVmb3JlIHdvdWxkDQog cHJlZmVyIHRvIHVzZSBhbm90aGVyIGVuZHBvaW50IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZS48 bzpwPjwvbzpwPjwvcD4NCjxwPnJlZ2FyZHMsPGJyPg0KVG9yc3Rlbi48bzpwPjwvbzpwPjwvcD4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+QW0gMjMuMDcuMjAxNCAxMzowNCwgc2Nocmll YiBOYXQgU2FraW11cmE6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzEwMTBGRiAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklNSE8sIGNoYW5n aW5nIHRoZSBzZW1hbnRpY3Mgb2YgJnF1b3Q7cmVzcG9uc2VfdHlwZSZxdW90OyBAIGF1dGh6IGVu ZHBvaW50IHRoaXMgd2F5IGlzIG5vdCBhIGdvb2QgdGhpbmcuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluc3RlYWQsIGRlZmluaW5nIGEg bmV3IHBhcmFtZXRlciAmcXVvdDtyZXNwb25zZV90eXBlJnF1b3Q7IEAgdG9rZW4gZW5kcG9pbnQs IGFzIEkgZGVzY3JpYmVkIGluIG15IHByZXZpb3VzIG1lc3NhZ2UsJm5ic3A7DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnByb2JhYmx5IGlzIGJldHRlci4g QXQgbGVhc3QsIGl0IGRvZXMgbm90IGNoYW5nZSB0aGUgc2VtYW50aWNzIG9mIHRoZSBwYXJhbWV0 ZXJzIG9mIFJGQzY3NDkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDtOYXQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIwMTQtMDctMjMgMTI6NDggR01ULTA0 OjAwIFRob21hcyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20i PnQuYnJveWVyQGdtYWlsLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Tm8sIEkgbWVhbiByZXNwb25zZV90eXBlPW5vbmUgYW5kIHJlc3Bv bnNlX3R5cGU9aWRfdG9rZW4gZG9uJ3QgZ2VuZXJhdGUgYSBjb2RlIG9yIGFjY2VzcyB0b2tlbiBz byB5b3UgZG9uJ3QgdXNlIHRoZSBUb2tlbiBFbmRwb2ludCAod2hpY2ggaXMgbm90IHRoZSBzYW1l IGFzIHRoZSBBdXRoZW50aWNhdGlvbiBFbmRwb2ludA0KIEJUVykuIDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2l0aCByZXNwb25zZV90eXBlPWNvZGVfZm9y X2lkX3Rva2VuLCB5b3UgZ2V0IGEgY29kZSBhbmQgZXhjaGFuZ2UgaXQgZm9yIGFuIGlkX3Rva2Vu IG9ubHksIHJhdGhlciB0aGFuIGFuIGFjY2Vzc190b2tlbiwgc28geW91J3JlIGNoYW5naW5nIHRo ZSBzZW1hbnRpY3Mgb2YgdGhlIFRva2VuIEVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdtIG5vdCBzYXlpbmcgaXQncyBh IGJhZCB0aGluZywganVzdCB0aGF0IHlvdSBjYW4ndCByZWFsbHkgY29tcGFyZSBub25lIGFuZCBp ZF90b2tlbiB3aXRoIGNvZGVfZm9yX2lkX3Rva2VuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEp1bCAyMywg MjAxNCBhdCA2OjQ1IFBNLCBSaWNoZXIsIEp1c3RpbiBQLiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpy aWNoZXJAbWl0cmUub3JnIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQncyBvbmx5ICZxdW90O25v dCB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQmcXVvdDsgYmVjYXVzZSB0aGUgdG9rZW4gZW5kcG9p bnQgY29weS1wYXN0ZWQgYW5kIHJlbmFtZWQgdGhlIGF1dGhlbnRpY2F0aW9uIGVuZHBvaW50Lg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 LS0gSnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEp1bCAyMywgMjAxNCwgYXQgOTozMCBB TSwgVGhvbWFzIEJyb3llciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSI+ dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5FeGNlcHQgdGhhdCB0aGVzZSBhcmUgYWJvdXQgbm90IHVzaW5nIHRoZSBU b2tlbiBFbmRwb2ludCBhdCBhbGwsIHdoZXJlYXMgdGhlIGN1cnJlbnQgcHJvcG9zYWwgaXMgYWJv dXQgdGhlIFRva2VuIEVuZHBvaW50IG5vdCByZXR1cm5pbmcgYW4gYWNjZXNzX3Rva2VuIGZpZWxk IGluIHRoZSBKU09OLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIFdlZCwgSnVsIDIzLCAyMDE0IGF0IDQ6MjYgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9 Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGUgcmVzcG9uc2VfdHlwZSAmcXVvdDtub25lJnF1b3Q7IGlzIGFscmVhZHkgdXNlZCBp biBwcmFjdGljZSwgd2hpY2ggcmV0dXJucyBubyBhY2Nlc3MgdG9rZW4uJm5ic3A7IEl0IHdhcyBh Y2NlcHRlZA0KIGJ5IHRoZSBkZXNpZ25hdGVkIGV4cGVydHMgYW5kIHJlZ2lzdGVyZWQgaW4gdGhl IElBTkEgT0F1dGggQXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNwb25zZSBUeXBlcyByZWdpc3Ry eSBhdA0KPGEgaHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJh bWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueG1sI2VuZHBvaW50Ij4NCmh0dHA6Ly93d3cuaWFuYS5v cmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhtbCNlbmRw b2ludDwvYT4uJm5ic3A7IFRoZSByZWdpc3RlcmVkICZxdW90O2lkX3Rva2VuJnF1b3Q7IHJlc3Bv bnNlIHR5cGUgYWxzbyByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBJ IHRoaW5rIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHJlc3BvbnNlIHR5cGVzIHRoYXQgcmVzdWx0 IGluIG5vIGFjY2VzcyB0b2tlbiBiZWluZyByZXR1cm5lZCBhcmUNCiBhY2NlcHRhYmxlIHdpdGhp biBPQXV0aCAyLjAgaXMgYWxyZWFkeSBzZXR0bGVkLCBhcyBhIHByYWN0aWNhbCBtYXR0ZXIuJm5i c3A7IExvdHMgb2YgT0F1dGggaW1wbGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IHVzaW5nIHN1Y2gg cmVzcG9uc2UgdHlwZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L3N0cm9uZz48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPHN0 cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPk9uIEJlaGFsZiBPZiA8L3NwYW4+PC9zdHJvbmc+UGhpbCBIdW50PGJy Pg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlbnQ6PC9zcGFuPjwvc3Ryb25nPiBXZWRuZXNkYXksIEp1 bHkgMjMsIDIwMTQgNzowOSBBTTxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ubzo8L3NwYW4+PC9z dHJvbmc+IE5hdCBTYWtpbXVyYTxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DYzo8L3NwYW4+PC9z dHJvbmc+ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3ViamVjdDo8L3NwYW4+PC9zdHJvbmc+ IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1v YXV0aC12Mi11c2VyLWE0Yy0wNS50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMuIFRoaXMgaXMgd2h5IGl0IGhhcyB0 byBiZSBkaXNjdXNzZWQgaW4gdGhlIElFVEYuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlBoaWw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vIj53d3cuaW5kZXBl bmRlbnRpZC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g SnVsIDIzLCAyMDE0LCBhdCA5OjQzIEFNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0 bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVhZGluZyBiYWNrIHRoZSBSRkM2 NzQ5LCBJIGFtIG5vdCBzdXJlIGlmIHRoZXJlIGlzIGEgZ29vZCB3YXkgb2Ygc3VwcHJlc3Npbmcg YWNjZXNzIHRva2VuIGZyb20gdGhlIHJlc3BvbnNlIGFuZCBzdGlsbCBiZSBPQXV0aC4gSXQgd2ls bCBicmVhayB3aG9sZSBidW5jaCBvZiBpbXBsaWNpdCBkZWZpbml0aW9ucw0KIGxpa2U6Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hdXRob3JpemF0aW9u IHNlcnZlcjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBzZXJ2ZXIgaXNzdWluZyBhY2Nl c3MgdG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0ZXIgc3VjY2Vzc2Z1bGx5PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgYXV0aGVudGljYXRpbmcgdGhlIHJlc291cmNlIG93bmVyIGFuZCBvYnRhaW5p bmcgYXV0aG9yaXphdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5BZnRlciBhbGwsIE9BdXRoIGlzIGFsbCBhYm91dCBpc3N1aW5nIGFjY2VzcyB0 b2tlbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5BbHNvLCBJIHRha2UgYmFjayBteSBzdGF0ZW1lbnQgb24gdGhlIGdyYW50 IHR5cGUgaW4gbXkgcHJldmlvdXMgbWFpbC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBkZWZpbml0aW9uIG9mIGdyYW50 IGFuZCBncmFudF90eXBlIGFyZSByZXNwZWN0aXZlbHk6Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Z3JhbnQmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7ICZuYnNwOyBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3VyY2Ugb3duZXIn cyBhdXRob3JpemF0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPmdyYW50X3R5cGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IChzdHJpbmcg cmVwcmVzZW50aW5nIHRoZSkgdHlwZSBvZiBncmFudCBzZW50IHRvIHRoZSB0b2tlbiBlbmRwb2lu dCB0byBvYnRhaW4gdGhlIGFjY2VzcyB0b2tlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaHVzLCB0aGUgZ3JhbnQgc2Vu dCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgaW4gdGhpcyBjYXNlIGlzIHN0aWxsICdjb2RlJy4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlJlc3BvbnNlIHR5cGUgb24gdGhlIG90aGVyIGhhbmQgaXMgbm90IHNvIHdlbGwgZGVmaW5l ZCBpbiBSRkM2NzQ5LCBidXQgaXQgc2VlbXMgaXQgaXMgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8g YmUgcmV0dXJuZWQgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gVG8gZXhwcmVzcyB3 aGF0IGlzIHRvDQogYmUgcmV0dXJuZWQgZnJvbSB0b2tlbiBlbmRwb2ludCwgcGVyaGFwcyBkZWZp bmluZyBhIG5ldyBwYXJhbWV0ZXIgdG8gdGhlIHRva2VuIGVuZHBvaW50LCB3aGljaCBpcyBhIHBh cmFsbGVsIHRvIHRoZSByZXNwb25zZV90eXBlIHRvIHRoZSBBdXRob3JpemF0aW9uIEVuZHBvaW50 IHNlZW1zIHRvIGJlIGEgbW9yZSBzeW1tZXRyaWMgd2F5LCB0aG91Z2ggSSBhbSBub3Qgc3VyZSBh dCBhbGwgaWYgdGhhdCBpcyBnb2luZyB0byBiZSBPQXV0aCBhbnkgbW9yZS4NCiBPbmUgc3RyYXct bWFuIGlzIHRvIGRlZmluZSBhIG5ldyBwYXJhbWV0ZXIgY2FsbGVkIHJlc3BvbnNlX3R5cGUgdG8g dGhlIHRva2VuIGVuZHBvaW50IHN1Y2ggYXM6Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5yZXNwb25zZV90eXBlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJz cDsgT1BUSU9OQUwuIEEgc3RyaW5nIHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJlIHJldHVybmVk IGZyb20gdGhlIHRva2VuIGVuZHBvaW50LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZW4gZGVmaW5l IHRoZSBiZWhhdmlvciBvZiB0aGUgZW5kcG9pbnQgYWNjb3JkaW5nIHRvIHRoZSB2YWx1ZXMgYXMg dGhlIHBhcmFsbGVsIHRvIHRoZSBtdWx0aS1yZXNwb25zZSB0eXBlIHNwZWMuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9 Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29hdXRoLXYyLW11bHRpcGxlLXJlc3BvbnNlLXR5cGVz LTFfMC5odG1sIj5odHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC12Mi1tdWx0aXBsZS1yZXNw b25zZS10eXBlcy0xXzAuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIwMTQtMDct MjMgNzoyMSBHTVQtMDQ6MDAgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGRyYWZ0IGlzIHZlcnkg Y2xlYXIuJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NClBoaWw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVsIDIzLCAyMDE0LCBhdCAwOjQ2LCBOYXQgU2FraW11cmEg Jmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoZSBuZXcgZ3JhbnQgdHlwZSB0aGF0IEkgd2FzIHRhbGtpbmcgYWJv dXQgd2FzJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mcXVvdDthdXRob3JpemF0aW9uX2NvZGVfYnV0X2RvX25vdF9yZXR1cm5fYWNjZXNzX25vcl9y ZWZyZXNoX3Rva2VuJnF1b3Q7LCBzbyB0byBzcGVhay4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBkb2VzIG5vdCByZXR1cm4gYW55 dGhpbmcgcGVyIHNlLCBidXQgYW4gZXh0ZW5zaW9uIGNhbiBkZWZpbmUgc29tZXRoaW5nIG9uIHRv cCBvZiBpdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoZW4sIE9JREMgY2FuIGRlZmluZSBhIGJpbmRpbmcgdG8gaXQgc28g dGhhdCB0aGUgYmluZGluZyBvbmx5IHJldHVybnMgSUQgVG9rZW4uJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgYmluZGluZyB3 b3JrIHNob3VsZCBiZSBkb25lIGluIE9JREYuIFNob3VsZCB0aGVyZSBiZSBzdWNoIGEgZ3JhbnQg dHlwZSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPml0IHdpbGwgYmUgYW4gZXh0cmVtZWx5IHNob3J0IHNw ZWMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5BdCB0aGUgc2FtZSB0aW1lLCBpZiBhbnkgb3RoZXIgc3BlY2lmaWNhdGlvbiB3 YW50ZWQgdG8gZGVmaW5lJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPm90aGVyIHR5cGUgb2YgdG9rZW5zIGFuZCBoYXZlIGl0IHJldHVy bmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5pdCBjYW4gYWxzbyB1c2UgdGhpcyBncmFu dCB0eXBlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SWYgd2hhdCB5b3Ugd2FudCBpcyB0byBkZWZpbmUgYSBuZXcgZ3JhbnQg dHlwZSB0aGF0IHJldHVybnMgSUQgVG9rZW4gb25seSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGhlbiwgSSBhbSB3aXRoIEp1c3Rp bi4gU2luY2UgJnF1b3Q7b3RoZXIgcmVzcG9uc2UgdGhhbiBJRCBUb2tlbiZxdW90OyBpcyBvbmx5 Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPnRoZW9yZXRpY2FsLCB0aGlzIGlzIGEgbW9yZSBwbGF1c2libGUgd2F5IGZvcndhcmQsIEkg c3VwcG9zZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+MjAxNC0wNy0yMiAxNDozMCBHTVQtMDQ6MDAgSnVzdGluIFJpY2hlciAm bHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9hPiZn dDs6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvIHRoZSBkcmFmdCB3 b3VsZCBsaXRlcmFsbHkgdHVybiBpbnRvOjxicj4NCjxicj4NCiZxdW90O1RoZSBhNGMgcmVzcG9u c2UgdHlwZSBhbmQgZ3JhbnQgdHlwZSByZXR1cm4gYW4gaWRfdG9rZW4gZnJvbSB0aGUgdG9rZW4g ZW5kcG9pbnQgd2l0aCBubyBhY2Nlc3MgdG9rZW4uIEFsbCBwYXJhbWV0ZXJzIGFuZCB2YWx1ZXMg YXJlIGRlZmluZWQgaW4gT0lEQy4mcXVvdDs8YnI+DQo8YnI+DQpTZWVtcyBsaWtlIHRoZSBwZXJm ZWN0IG1pbmkgZXh0ZW5zaW9uIGRyYWZ0IGZvciBPSURGIHRvIGRvLjxicj4NCjxicj4NCi0tSnVz dGluPGJyPg0KPGJyPg0KL3NlbnQgZnJvbSBteSBwaG9uZS88bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCk9uIEp1bCAyMiwgMjAxNCAxMDoyOSBBTSwg TmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtp bXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGF0IGFi b3V0IGp1c3QgZGVmaW5pbmcgYSBuZXcgZ3JhbnQgdHlwZSBpbiB0aGlzIFdHPzxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyAyMDE0LTA3LTIyIDEyOjU2IEdNVC0wNDowMCBQaGlsIEh1bnQg Jmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNs ZS5jb208L2E+Jmd0Ozo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYXQgd291bGQgYmUg bmljZS4gSG93ZXZlciBvaWRjIHN0aWxsIG5lZWRzIHRoZSBuZXcgZ3JhbnQgdHlwZSBpbiBvcmRl ciB0byBpbXBsZW1lbnQgdGhlIHNhbWUgZmxvdy4mbmJzcDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IFBoaWw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIEp1bCAyMiwgMjAxNCwg YXQgMTE6MzUsIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWls LmNvbSI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgJiM0MzsxIHRvIEp1c3Rpbi4mbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgMjAxNC0wNy0yMiA5OjU0IEdNVC0w NDowMCBSaWNoZXIsIEp1c3RpbiBQLiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUu b3JnIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IEVycm9ycyBsaWtlIHRoZXNlIG1ha2UgaXQgY2xlYXIgdG8gbWUg dGhhdCBpdCB3b3VsZCBtYWtlIG11Y2ggbW9yZSBzZW5zZSB0byBkZXZlbG9wIHRoaXMgZG9jdW1l bnQgaW4gdGhlIE9wZW5JRCBGb3VuZGF0aW9uLiBJdCBzaG91bGQgYmUgc29tZXRoaW5nIHRoYXQg ZGlyZWN0bHkgcmVmZXJlbmNlcyBPcGVuSUQgQ29ubmVjdCBDb3JlIGZvciBhbGwgb2YgdGhlc2Ug dGVybXMgaW5zdGVhZCBvZiByZWRlZmluaW5nIHRoZW0uIEl0J3MgZG9pbmcNCiBhdXRoZW50aWNh dGlvbiwgd2hpY2ggaXMgZnVuZGFtZW50YWxseSB3aGF0IE9wZW5JRCBDb25uZWN0IGRvZXMgb24g dG9wIG9mIE9BdXRoLCBhbmQgSSBkb24ndCBzZWUgYSBnb29kIGFyZ3VtZW50IGZvciBkb2luZyB0 aGlzIHdvcmsgaW4gdGhpcyB3b3JraW5nIGdyb3VwLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOy0tIEp1c3Rpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE9uIEp1bCAyMiwgMjAxNCwgYXQgNDozMCBBTSwgVGhvbWFz IEJyb3llciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSI+dC5icm95ZXJA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIE1vbiwgSnVsIDIxLCAyMDE0 IGF0IDExOjUyIFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgVGhhbmtzIGZvciB5b3VyIHJldmlldywgVGhvbWFzLiZuYnNwOyBUaGUgJnF1b3Q7cHJv bXB0PWNvbnNlbnQmcXVvdDsgZGVmaW5pdGlvbiBiZWluZyBtaXNzaW5nIGlzIGFuIGVkaXRvcmlh bCBlcnJvci4mbmJzcDsgSXQgc2hvdWxkIGJlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uc2VudDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUg QXV0aG9yaXphdGlvbiBTZXJ2ZXIgU0hPVUxEIHByb21wdCB0aGUgRW5kLVVzZXIgZm9yIGNvbnNl bnQgYmVmb3JlIHJldHVybmluZyBpbmZvcm1hdGlvbiB0byB0aGUgQ2xpZW50LiBJZiBpdCBjYW5u b3Qgb2J0YWluIGNvbnNlbnQsIGl0IE1VU1QgcmV0dXJuIGFuIGVycm9yLCB0eXBpY2FsbHkgY29u c2VudF9yZXF1aXJlZC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEknbGwgcGxhbiB0byBhZGQgaXQgaW4gdGhlIG5l eHQgZHJhZnQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEl0IGxvb2tzIGxpa2UgdGhlIGNvbnNlbnRf cmVxdWlyZWQgZXJyb3IgbmVlZHMgdG8gYmUgZGVmaW5lZCB0b28sIGFuZCB5b3UgbWlnaHQgaGF2 ZSBmb3Jnb3R0ZW4gdG8gYWxzbyBpbXBvcnQgYWNjb3VudF9zZWxlY3Rpb25fcmVxdWlyZWQgZnJv bSBPcGVuSUQgQ29ubmVjdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5i c3A7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEkgYWdyZWUgdGhhdCB0aGVyZSdzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJlc3Bv bnNlIHdpdGggbXVsdGlwbGUgJnF1b3Q7YW1yJnF1b3Q7IHZhbHVlcyB0aGF0IGluY2x1ZGVzICZx dW90O21mYSZxdW90OyBhbmQgb25lIHRoYXQgZG9lc24ndC4mbmJzcDsgVW5sZXNzIGEgY2xlYXIg dXNlIGNhc2UgZm9yIHdoeSAmcXVvdDttZmEmcXVvdDsgaXMgbmVlZGVkIGNhbiBiZSBpZGVudGlm aWVkLCB3ZSBjYW4gZGVsZXRlIGl0IGluIHRoZSBuZXh0IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBUaGFua3MuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBIb3cgYWJvdXQgJnF1b3Q7cHdkJnF1b3Q7IHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFu ZCB0aGF0IEkgc2hvdWxkIHJldHVybiAmcXVvdDtwd2QmcXVvdDsgaWYgdGhlIHVzZXIgYXV0aGVu dGljYXRlZCB1c2luZyBhIHBhc3N3b3JkLCBidXQgd2hhdCAmcXVvdDt0aGUgc2VydmljZSBpZiBh IGNsaWVudCBzZWNyZXQgaXMgdXNlZCZxdW90OyBtZWFucyBpbiB0aGUgZGVmaW5pdGlvbiBmb3Ig dGhlICZxdW90O3B3ZCZxdW90OyB2YWx1ZT88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IChOb3RhOiBJIGtub3cgeW91J3JlIGF0IElFVEYtOTAsIEkn bSByZWFkeSB0byB3YWl0ICd0aWwgeW91IGNvbWUgYmFjayA7LSkgKTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBUaG9tYXMgQnJveWVyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgL3Q8YSBocmVm PSJodHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8iPsmULm1hLmLKgXdhLmplLzwvYT48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcg bGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm Lm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLS08YnI+ DQomZ3Q7Jmd0OyZndDsgTmF0IFNha2ltdXJhICg9bmF0KTxicj4NCiZndDsmZ3Q7Jmd0OyBDaGFp cm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDov L25hdC5zYWtpbXVyYS5vcmcvIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KJmd0 OyZndDsmZ3Q7IEBfbmF0X2VuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZn dDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyA8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBOYXQgU2Fr aW11cmEgKD1uYXQpPGJyPg0KJmd0OyBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQom Z3Q7IDxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyI+aHR0cDovL25hdC5zYWtpbXVy YS5vcmcvPC9hPjxicj4NCiZndDsgQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxicj4NCk5hdCBTYWtp bXVyYSAoPW5hdCk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2Fr aW11cmEub3JnLyI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVh cj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0N Cjxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9 Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxi cj4NCkBfbmF0X2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyIGNs ZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4t LQ0KPGJyPg0KVGhvbWFzIEJyb3llcjxicj4NCi90PGEgaHJlZj0iaHR0cDovL3huLS1ubmEubWEu eG4tLWJ3YS14eGIuamUvIj7JlC5tYS5iyoF3YS5qZS88L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiM4ODg4ODgiPi0tDQo8YnI+DQpUaG9tYXMgQnJveWVyPGJyPg0KL3Q8YSBocmVmPSJodHRw Oi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8iPsmULm1hLmLKgXdhLmplLzwvYT4gPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBj bGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ LS0NCjxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCkgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBo cmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwv YT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+ T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBp ZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NCk5hdCBTYWtpbXVyYSAoPW5h dCkgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4s IE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcv Ij5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KTmF0IFNha2ltdXJhICg9bmF0KSA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5k YXRpb248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iPmh0dHA6Ly9uYXQu c2FraW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzEwMTBGRiAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1 dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0 aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6 My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1 dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3e463e686b2e4c5f87ef26969ef967c6BLUPR03MB309namprd03pro_-- From nobody Wed Jul 23 19:02:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC281A04B9 for ; Wed, 23 Jul 2014 19:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 6Cn5w_GHY8De for ; Wed, 23 Jul 2014 19:02:21 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7950A1A05C0 for ; Wed, 23 Jul 2014 19:02:20 -0700 (PDT) X-AuditID: 1209190c-f79ef6d000005dd6-8b-53d0692ae792 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 22.3C.24022.B2960D35; Wed, 23 Jul 2014 22:02:19 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s6O22IDG012193; Wed, 23 Jul 2014 22:02:18 -0400 Received: from [192.168.211.47] ([209.117.47.248]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6O22G7S012543 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 Jul 2014 22:02:17 -0400 Message-Id: <201407240202.s6O22G7S012543@outgoing.mit.edu> Date: Wed, 23 Jul 2014 22:02:13 -0400 From: Justin Richer To: Anthony Nadalin , oauth@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixCmqraudeSHY4PxcNouTb1+xWWyau43R gcljyZKfTB6tO/6yBzBFcdmkpOZklqUW6dslcGU86PzLVHBnJVPFinkTWBoYOxYxdTFyckgI mEgcbD/ABmGLSVy4tx7I5uIQEpjNJLFm7wQmCGcjo8S/l5sZIZwlTBLTT+5lBGnhFbCSuPCi EWwUi4CqxNXnx1i6GDk4hAWiJH7PdwAJswGF56+8BVYiImAtsWLNQjaIVkGJkzOfsIDYzALq En/mXWKGsBUlpnQ/ZJ/AyDsLSdksJGWzkJQtYGRexSibklulm5uYmVOcmqxbnJyYl5dapGuo l5tZopeaUrqJERxkkjw7GN8cVDrEKMDBqMTD27H3fLAQa2JZcWXuIUZJDiYlUd7jkReChfiS 8lMqMxKLM+KLSnNSiw8xSnAwK4nw3rMByvGmJFZWpRblw6SkOViUxHnfWlsFCwmkJ5akZqem FqQWwWRlODiUJHi/pQM1ChalpqdWpGXmlCCkmTg4QYbzAA2/C1LDW1yQmFucmQ6RP8WoKCXO ezANKCEAksgozYPrhSWBV4ziQK8I85plAFXxABMIXPcroMFMQINfJZwHGVySiJCSamDkmlko c4rhieySOaFvHxklbcpb+1RgI6eM2dwIj+X/Q9Ut0iO3RPhaPzTaY3syT1L29aLM8yva5rRc tvgh7bzv1Wb1JNvGuY5OPadOz7t87FbFrQ1vJcMY6vhsTj0pnhy34eWJX4xx7ndV/t66u6B8 jv6pLanssy3UT/5wnvPzNcORV6kHOqIWKLEUZyQaajEXFScCAFKvPo3dAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DNEl6x6aPR6pPqy2coL3Em40yew Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 02:02:25 -0000 QnV0Li4uIHRoaXMgcHJvcG9zYWwgaXNzdWVzIGlkX3Rva2Vucy4gSXMgdGhpcyBwcm9wb3NhbCBz dHVwaWQgZm9yIGRvaW5nIHNvLCBvciBkb2VzIE1pY3Jvc29mdCBub3QgYWN0dWFsbHkgaW1wbGVt ZW50IGl0IGFzIHdyaXR0ZW4/CgpBbHNvLCBJIGNhbid0IGZpbmQgYW55IG1lbnRpb24gb2YgdGhp cyBpbiB5b3VyIGRvY3MuIENhbiB5b3UgcG9pbnQgdXMgdG8gaXQ/CgpBbmQgZG9lc24ndCBNaWNy b3NvZnQgaW1wbGVtZW50IE9wZW5JRCBDb25uZWN0IGFscmVhZHk/IFlvdSBndXlzIGpvaW5lZCB0 aGUgT0lEQyBpbnRlcm9wIHdpdGggeW91ciBpbXBsZW1lbnRhdGlvbiBhZnRlciBhbGwuIElmIHlv dSdyZSBkb2luZyBib3RoLCBncmVhdCwgYWxsIHRoZSBtb3JlIHJlYXNvbiB0byBkbyB0aGlzIHdv cmsgaW4gT0lERi4KCi0tSnVzdGluCgovc2VudCBmcm9tIG15IHBob25lLwoKT24gSnVsIDIzLCAy MDE0IDk6NTUgUE0sIEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPiB3cm90 ZToKPgo+IEkgYWxyZWFkeSBpbmRpY2F0ZWQgdGhhdCBNaWNyb3NvZnQgaGFzIGltcGxlbWVudGVk IHRoaXMgYW5kIGlzIGluIHByb2R1Y3Rpb24sIGFzIGlkX3Rva2VucyBhcmUgc3R1cGlkIG9uIGlu dGVyc3lzdGVtIGFuZCBwYXJ0bmVyIGNvbGxhYm9yYXRpb24gc2l0ZXMgCj4KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLSAKPiBGcm9tOiBKdXN0aW4gUmljaGVyIFttYWlsdG86anJpY2hlckBN SVQuRURVXSAKPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQgNjo1MiBQTSAKPiBUbzog QW50aG9ueSBOYWRhbGluIAo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQgCj4KPiBB bmQgd2hpY2ggSWRQIGlzIHRoYXQ/IENhbiB5b3UgcG9pbnQgdXMgdG8gdGhlIGltcGxlbWVudGF0 aW9uPyAKPgo+IC0tSnVzdGluIAo+Cj4gL3NlbnQgZnJvbSBteSBwaG9uZS8gCj4KPiBPbiBKdWwg MjMsIDIwMTQgOTo0MyBQTSwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb20+ IHdyb3RlOiAKPiA+IAo+ID4gPlNvbWV0aGluZyByZWFsbHkgdXNlZnVsIHRvIGRvIHdvdWxkIGJl IHNvcnRpbmcgb3V0IGNoYW5uZWxfaWQgc28gd2UgCj4gPiA+Y2FuIGRvIFBvUCBmb3IgaWQgdG9r ZW5zIHRvIG1ha2UgdGhlbSBhbmQgb3RoZXIgY29va2llcyBzZWN1cmUgaW4gdGhlIAo+ID4gPmZy b250IGNoYW5uZWwuIMKgIEkgdGhpbmsgdGhhdCBpcyBhIGJldHRlciB1c2Ugb2YgdGltZSAKPiA+ IAo+ID4gwqAgCj4gPiAKPiA+IEZvbGtzIGFyZSBhbHJlYWR5IHdvcmtpbmcgb24gdGhpcyBhbmQg aXQgZG9lcyBub3QgdGFrZSBhIGFueXRoaW5nIGZyb20gCj4gPiBPQXV0aCB0byBtYWtlIGl0IHdv cmssIE9BdXRoIFRva2VucyBjYW4gYmUgdXNlZCBhbmQgdGhlcmUgaXMgbm90IGEgCj4gPiBuZWVk IGZvciBPQXV0aCBQT1AgVG9rZW5zLiBBNEMgaXMgYWxyZWFkeSBpbiB1c2Ugb24gb25lIG9mIHRo ZSBsYXJnZXN0IAo+ID4gSWRQcywgYnV0IEkgZG9u4oCZdCB0aGluayB5b3Ugd291bGQgdW5kZXJz dGFuZCBob3cgdXNlZnVsIGl0IGlzIAo+ID4gCj4gPiDCoCAKPiA+IAo+ID4gRnJvbTogT0F1dGgg W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5 IAo+ID4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDE6NTQgUE0gCj4gPiBUbzogdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQgCj4gPiBDYzogb2F1dGhAaWV0Zi5vcmcgbGlzdCAKPiA+IFN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgCj4gPiBk cmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dCAKPiA+IAo+ID4gwqAgCj4gPiAKPiA+ IEkgdGhvdWdodCBJIGRpZCBwb3N0IHRoaXMgdG8gdGhlIGxpc3QuIAo+ID4gCj4gPiDCoCAKPiA+ IAo+ID4gSSBndWVzcyBJIGhpdCB0aGUgd3JvbmcgcmVwbHkgb24gbXkgcGhvbmUuIAo+ID4gwqAg Cj4gPiAKPiA+IEpvaG4gQi4gCj4gPiBTZW50IGZyb20gbXkgaVBob25lIAo+ID4gCj4gPiAKPiA+ IE9uIEp1bCAyMywgMjAxNCwgYXQgNDo1MCBQTSwgdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQgd3Jv dGU6IAo+ID4+IAo+ID4+IHdlIGFyZSB0d28sIGF0IGxlYXN0IDotKSAKPiA+PiAKPiA+PiBXaHkg ZGlkbid0IHlvdSBwb3N0IHRoaXMgb24gdGhlIGxpc3Q/IAo+ID4+IAo+ID4+IFdoZW4gd2lsbCBi ZSBiZSBhcnJpdmluZz8gCj4gPj4gCj4gPj4gQW0gMjMuMDcuMjAxNCAxNjozOSwgc2NocmllYiBK b2huIEJyYWRsZXk6IAo+ID4+PiAKPiA+Pj4gSWFuIEdsYXplciBtZW50aW9uZWQgdGhpcyBpbiBo aXMga2V5bm90ZSBhdCBDSVMgeWVzdGVyZGF5LiAKPiA+Pj4gCj4gPj4+IMKgIAo+ID4+PiAKPiA+ Pj4gSGlzIGFkdmljZSB3YXMgcGxlYXNlIHN0b3AsIMKgd2UgYXJlIGNyZWF0aW5nIGNvbmZ1c2lv biBhbmQgCj4gPj4+IHVuY2VydGFpbnR5LiAKPiA+Pj4gCj4gPj4+IMKgIAo+ID4+PiAKPiA+Pj4g V2UgYXJlIGJlY29taW5nIG91ciBvd24gd29ydCBlbmVteS4gKCBteSB2aWV3IHRob3VnaCBJYW4g bWF5IHNoYXJlIAo+ID4+PiBpdCkgCj4gPj4+IAo+ID4+PiDCoCAKPiA+Pj4gCj4gPj4+IFJldHVy bmluZyBqdXN0IGFuIGlkXyB0b2tlbiBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCBoYXMgbGl0dGxl IHJlYWwgCj4gPj4+IHZhbHVlLiAKPiA+Pj4gCj4gPj4+IMKgIAo+ID4+PiAKPiA+Pj4gU29tZXRo aW5nIHJlYWxseSB1c2VmdWwgdG8gZG8gd291bGQgYmUgc29ydGluZyBvdXQgY2hhbm5lbF9pZCBz byB3ZSAKPiA+Pj4gY2FuIGRvIFBvUCBmb3IgaWQgdG9rZW5zIHRvIG1ha2UgdGhlbSBhbmQgb3Ro ZXIgY29va2llcyBzZWN1cmUgaW4gdGhlIGZyb250IGNoYW5uZWwuIMKgIEkgdGhpbmsgdGhhdCBp cyBhIGJldHRlciB1c2Ugb2YgdGltZS4gCj4gPj4+IAo+ID4+PiDCoCAKPiA+Pj4gCj4gPj4+IEkg bWF5IGJlIGluIHRoZSBtaW5vcml0eSBvcGluaW9uIG9uIHRoYXQsIMKgaXQgd29uJ3QgYmUgdGhl IGZpcnN0IAo+ID4+PiB0aW1lLiAKPiA+Pj4gCj4gPj4+IEpvaG4gQi4gCj4gPj4+IFNlbnQgZnJv bSBteSBpUGhvbmUgCj4gPj4+IAo+ID4+PiAKPiA+Pj4gT24gSnVsIDIzLCAyMDE0LCBhdCA0OjA0 IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6 IAo+ID4+Pj4gCj4gPj4+PiBZb3UgYXJlIHJpZ2h0IGZyb20gYSB0aGVvcmV0aWNhbCBwZXJzcGVj dGl2ZS4gUHJhY3RpY2FsbHkgdGhpcyB3YXMgY2F1c2VkIGJ5IGVkaXRvcmlhbCBkZWNpc2lvbnMg ZHVyaW5nIHRoZSBjcmVhdGlvbiBvZiB0aGUgUkZDLiBBcyBmYXIgYXMgSSByZW1lbWJlciwgdGhl cmUgd2FzIGEgZGVmaW5pdGlvbiBvZiB0aGUgKG9uZSkgdG9rZW4gZW5kcG9pbnQgcmVzcG9uc2Ug aW4gZWFybHkgdmVyc2lvbnMuIE5vIG9uZSBldmVyeSBjb25zaWRlcmVkIHRvIE5PVCByZXNwb25k IHdpdGggYW4gYWNjZXNzIHRva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LiBTbyBvbmUgbWln aHQgY2FsbCBpdCBhbiBpbXBsaWNpdCBhc3N1bXB0aW9uLiAKPiA+Pj4+IAo+ID4+Pj4gwqAgCj4g Pj4+PiAKPiA+Pj4+IEknbSB3b3JyaWVkIHRoYXQgcGVvcGxlIGdldCB0b3RhbGx5IGNvbmZ1c2Vk IGlmIGFuIGV4Y2VwdGlvbiBpcyBpbnRyb2R1Y2VkIG5vdyBnaXZlbiB0aGUgYnJvYWQgYWRvcHRp b24gb2YgT0F1dGggYmFzZWQgb24gdGhpcyBhc3N1bXB0aW9uLiAKPiA+Pj4+IAo+ID4+Pj4gwqAg Cj4gPj4+PiAKPiA+Pj4+IHJlZ2FyZHMsIAo+ID4+Pj4gCj4gPj4+PiBUb3JzdGVuLiAKPiA+Pj4+ IAo+ID4+Pj4gCj4gPj4+PiBBbSAyMy4wNy4yMDE0IHVtIDE1OjQxIHNjaHJpZWIgVGhvbWFzIEJy b3llciA8dC5icm95ZXJAZ21haWwuY29tPjogCj4gPj4+Pj4gCj4gPj4+Pj4gSXMgaXQgc2FpZCBh bnl3aGVyZSB0aGF0IEFMTCBncmFudCB0eXBlcyBNVVNUIHVzZSBTZWN0aW9uIDUuMSByZXNwb25z ZXM/IEVhY2ggZ3JhbnQgdHlwZSByZWZlcmVuY2VzIFNlY3Rpb24gNS4xLCBhbmQgImFjY2VzcyB0 b2tlbiByZXF1ZXN0IiBpcyBvbmx5IGRlZmluZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGRlZmlu ZWQgZ3JhbnQgdHlwZXMuIFNlY3Rpb24gMi4yIGRvZXNuJ3QgdGFsayBhYm91dCB0aGUgcmVxdWVz dCBvciByZXNwb25zZSBmb3JtYXQuIAo+ID4+Pj4+IAo+ID4+Pj4+IExlIDIzIGp1aWwuIDIwMTQg MjE6MzIsICJOYXQgU2FraW11cmEiIDxzYWtpbXVyYUBnbWFpbC5jb20+IGEgw6ljcml0IDogCj4g Pj4+Pj4+IAo+ID4+Pj4+PiBJcyBpdD8gQXBhcnQgZnJvbSB0aGUgaW1wbGljaXQgZ3JhbnQgdGhh dCBkb2VzIG5vdCB1c2UgdG9rZW4gCj4gPj4+Pj4+IGVuZHBvaW50LCBhbGwgb3RoZXIgZ3JhbnQg cmVmZXJlbmNlcyBzZWN0aW9uIDUuMSBmb3IgdGhlIHJlc3BvbnNlLCBpLmUuLCBhbGwgc2hhcmVz IHRoZSBzYW1lIHJlc3BvbnNlLiAKPiA+Pj4+Pj4gCj4gPj4+Pj4+IMKgIAo+ID4+Pj4+PiAKPiA+ Pj4+Pj4gMjAxNC0wNy0yMyAxNToxOCBHTVQtMDQ6MDAgVGhvbWFzIEJyb3llciA8dC5icm95ZXJA Z21haWwuY29tPjogCj4gPj4+Pj4+PiAKPiA+Pj4+Pj4+IEkgaGFkbid0IHJlYWxpemVkIHRoZSBK U09OIHJlc3BvbnNlIHRoYXQgcmVxdWlyZXMgdGhlIGFjY2Vzc190b2tlbiBmaWVsZCBpcyBkZWZp bmVkIHBlciBncmFudF90eXBlLCBzbyBJJ2QgYmUgT0sgdG8gImV4dGVuZCB0aGUgc2VtYW50aWNz IiBhcyBpbiB0aGUgY3VycmVudCBkcmFmdC4gCj4gPj4+Pj4+PiBUaGF0IHdhcyBhY3R1YWxseSBt eSBtYWluIGNvbmNlcm46IHRoYXQgdGhlIHRva2VuIGVuZHBvaW50IG1hbmRhdGVzIGFjY2Vzc190 b2tlbjsgYnV0IGl0cyBhY3R1YWxseSBub3QgdGhlIGNhc2UuIAo+ID4+Pj4+Pj4gCj4gPj4+Pj4+ PiBMZSAyMyBqdWlsLiAyMDE0IDIwOjQ2LCAiTmF0IFNha2ltdXJhIiA8c2FraW11cmFAZ21haWwu Y29tPiBhIMOpY3JpdCA6IAo+ID4+Pj4+Pj4gCj4gPj4+Pj4+PiDCoCAKPiA+Pj4+Pj4+PiAKPiA+ Pj4+Pj4+PiBJIGFncmVlIHdpdGggSm9obiB0aGF0IG92ZXJsb2FkaW5nIHJlc3BvbnNlX3R5cGUg QCBhdXRoeiAKPiA+Pj4+Pj4+PiBlbmRwb2ludCBpcyBhIGJhZCBpZGVhLiBJdCBjb21wbGV0ZWx5 IGNoYW5nZXMgdGhlIHNlbWFudGljcyBvZiB0aGlzIHBhcmFtZXRlci4gTk9URTogd2hhdCBJIHdh cyBwcm9wb3Npbmcgd2FzIG5vdCB0aGlzIHBhcmFtZXRlciwgYnV0IGEgbmV3IHBhcmFtZXRlciBy ZXNwb25zZV90eXBlIEAgdG9rZW4gZW5kcG9pbnQuIAo+ID4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+IMKg IAo+ID4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+IEkgYWxzbyB0aGluayBvdmVybG9hZGluZyBncmFudF90 eXBlIGlzIGEgYmFkIGlkZWEgc2luY2UgaXQgCj4gPj4+Pj4+Pj4gY2hhbmdlcyBpdHMgc2VtYW50 aWNzLiBJIHF1b3RlIHRoZSBkZWZpbml0aW9uIGhlcmUgYWdhaW46IAo+ID4+Pj4+Pj4+IAo+ID4+ Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+IGdyYW50IAo+ID4+Pj4+Pj4+IAo+ID4+ Pj4+Pj4+IMKgIMKgIGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZSBvd25lcidz IGF1dGhvcml6YXRpb24gCj4gPj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4gCj4g Pj4+Pj4+Pj4gZ3JhbnRfdHlwZSAKPiA+Pj4+Pj4+PiAKPiA+Pj4+Pj4+PiB0eXBlIG9mIGdyYW50 IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IHRvIG9idGFpbiB0aGUgYWNjZXNzIAo+ID4+Pj4+ Pj4+IHRva2VuIAo+ID4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+IAo+ID4+Pj4+ Pj4+IEl0IGlzIG5vdCBhYm91dCBjb250cm9sbGluZyB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZy b20gdGhlIAo+ID4+Pj4+Pj4+IHRva2VuIGVuZHBvaW50LCBidXQgdGhlIGhpbnQgdG8gdGhlIHRv a2VuIGVuZHBvaW50IGRlc2NyaWJpbmcgdGhlIHR5cGUgb2YgY3JlZGVudGlhbCB0aGUgZW5kcG9p bnQgaGFzIHJlY2VpdmVkLiBJdCBzZWVtcyB0aGUgImNvbnRyb2wgb2Ygd2hhdCBpcyBiZWluZyBy ZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50IiDCoGlzIGp1c3QgYSBzaWRlIGVmZmVjdC4gCj4g Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4gSSBhbSBzb21l d2hhdCBhbWJpdmFsZW50WzFdIGluIGNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgdG9rZW4gCj4g Pj4+Pj4+Pj4gZW5kcG9pbnQsIGJ1dCBpbiBhcyBtdWNoIGFzICJ0ZXh0IGlzIHRoZSBraW5nIiBm b3IgYSBzcGVjLiwgd2UgcHJvYmFibHkgc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBv ZiBpdCBhcyBUb3JzdGVuIHBvaW50cyBvdXQuIElmIGl0IGlzIG9rIHRvIGNoYW5nZSB0aGlzIHNl bWFudGljcywgSSBiZWxpZXZlIGRlZmluaW5nIGEgbmV3IHBhcmFtZXRlciB0byB0aGlzIGVuZHBv aW50IHRvIGNvbnRyb2wgdGhlIHJlc3BvbnNlIHdvdWxkIGJlIHRoZSBiZXN0IHdheSB0byBnby4g VGhpcyBpcyB3aGF0IEkgaGF2ZSBkZXNjcmliZWQgcHJldmlvdXNseS4gCj4gPj4+Pj4+Pj4gCj4g Pj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4gRGVmaW5pbmcgYSBuZXcgZW5kcG9p bnQgdG8gc2VuZCBjb2RlIHRvIGdldCBJRCBUb2tlbiBhbmQgCj4gPj4+Pj4+Pj4gZm9yYmlkZGlu ZyB0aGUgdXNlIG9mIGl0IGFnYWluc3QgdG9rZW4gZW5kcG9pbnQgd291bGQgbm90IGNoYW5nZSB0 aGUgc2VtYW50aWNzIG9mIGFueSBleGlzdGluZyBwYXJhbWV0ZXIgb3IgZW5kcG9pbnQsIHdoaWNo IGlzIGdvb2QuIEhvd2V2ZXIsIEkgZG91YnQgaWYgaXQgaXMgbm90IHdvcnRoIGRvaW5nLiBXaGF0 J3MgdGhlIHBvaW50IG9mIGF2b2lkaW5nIGFjY2VzcyB0b2tlbiBzY29wZWQgdG8gVXNlckluZm8g ZW5kcG9pbnQgYWZ0ZXIgYWxsPyBEZWZpbmluZyBhIG5ldyBlbmRwb2ludCBmb3IganVzdCBhdm9p ZGluZyB0aGUgYWNjZXNzIHRva2VuIGZvciB1c2VyaW5mbyBlbmRwb2ludCBzZWVtcyB3YXkgdG9v IG11Y2ggdGhlIGhlYXZ5IHdhaXQgd2F5IGFuZCBpdCBicmVha3MgaW50ZXJvcGVyYWJpbGl5OiBp dCBkZWZlYXRzIHRoZSBwdXJwb3NlIG9mIHN0YW5kYXJkaXphdGlvbi4gCj4gPj4+Pj4+Pj4gCj4g Pj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4gSSBoYXZlIHN0YXJ0ZWQgZmVlbGlu ZyB0aGF0IG5vIGNoYW5nZSBpcyB0aGUgYmVzdCB3YXkgb3V0LiAKPiA+Pj4+Pj4+PiAKPiA+Pj4+ Pj4+PiDCoCAKPiA+Pj4+Pj4+PiAKPiA+Pj4+Pj4+PiBOYXQgCj4gPj4+Pj4+Pj4gCj4gPj4+Pj4+ Pj4gwqAgCj4gPj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4gWzFdIMKgSWYgaW5zdGVhZCBvZiBzYXlpbmcg IlRva2VuIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvIGV4Y2hhbmdlIGFuIGF1dGhv cml6YXRpb27CoGdyYW50IGZvciBhbiBhY2Nlc3MgdG9rZW4sIHR5cGljYWxseSB3aXRoIGNsaWVu dCBhdXRoZW50aWNhdGlvbiIsIGl0IHdlcmUgc2F5aW5nICJUb2tlbiBlbmRwb2ludCAtIHVzZWQg YnkgdGhlIGNsaWVudCB0byBleGNoYW5nZSBhbiBhdXRob3JpemF0aW9uwqBncmFudCBmb3IgdG9r ZW5zLCB0eXBpY2FsbHkgd2l0aCBjbGllbnQgYXV0aGVudGljYXRpb24iLCB0aGVuIGl0IHdvdWxk IGhhdmUgYmVlbiBPSy4gSXQgaXMgYW4gZXhwYW5zaW9uIG9mIHRoZSBjYXBhYmlsaXR5IHJhdGhl ciB0aGFuIGNoYW5naW5nIHRoZSBzZW1hbnRpY3MuIAo+ID4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+IMKg IAo+ID4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+IDIwMTQt MDctMjMgMTM6MzkgR01ULTA0OjAwIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT46IAo+ID4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4gWW91IG5lZWQgdGhlIGFsdGVybmF0aXZl IHJlc3BvbnNlX3R5cGUgdmFsdWUgKCJjb2RlX2Zvcl9pZF90b2tlbiIgaW4gdGhlIEE0QyBkcmFm dCkgdG8gdGVsbCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdG8gcmV0dXJuIGEgY29kZSB0byBi ZSB1c2VkIHdpdGggdGhlIG5ldyBncmFudCB0eXBlLCByYXRoZXIgdGhhbiBvbmUgdG8gdXNlIHdp dGggdGhlICJhdXRob3JpemF0aW9uX2NvZGUiIGdyYW50IHR5cGUgKHdoaWNoIGlzIHdoYXQgcmVz cG9uc2VfdHlwZT1jb2RlIGRvZXMpLiAKPiA+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+IMKgIAo+ID4+ Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4gRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiAKPiA+Pj4+Pj4+Pj4gQnJhZGxleSAKPiA+Pj4+Pj4+ Pj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDEwOjMzIEFNIAo+ID4+Pj4+Pj4+PiBU bzogdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQgCj4gPj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+PiAKPiA+ Pj4+Pj4+Pj4gQ2M6IG9hdXRoQGlldGYub3JnIAo+ID4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW09B VVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIAo+ID4+Pj4+Pj4+PiBkcmFmdC1o dW50LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dCAKPiA+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+IMKg IAo+ID4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+PiBJ ZiB3ZSB1c2UgdGhlIHRva2VuIGVuZHBvaW50IHRoZW4gYSBuZXcgZ3JhbnRfdHlwZSBpcyB0aGUg YmVzdCAKPiA+Pj4+Pj4+Pj4gd2F5LiAKPiA+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+IMKgIAo+ID4+ Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4gSXQgc29ydCBvZiBvdmVybG9hZHMgY29kZSwgYnV0IHRoYXQg aXMgYmV0dGVyIHRoYW4gbWVzc2luZyAKPiA+Pj4+Pj4+Pj4gd2l0aCByZXNwb25zZV90eXBlIGZv ciB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB0byBjaGFuZ2UgdGhlIHJlc3BvbnNlIGZyb20g dGhlIHRva2VuX2VuZHBvaW50LiDCoFRoYXQgaXMgaW4gbXkgb3BpbmlvbiBhIGNoYW1waW9uIGJh ZCBpZGVhLiAKPiA+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+PiAKPiA+Pj4+ Pj4+Pj4gSW4gZGlzY3Vzc2lvbnMgZGV2ZWxvcGluZyBDb25uZWN0IHdlIGRlY2lkZWQgbm90IHRv IG9wZW4gdGhpcyAKPiA+Pj4+Pj4+Pj4gY2FuIG9mIHdvcm1zIGJlY2F1c2Ugbm8gZ29vZCB3b3Vs ZCBjb21lIG9mIGl0LiAKPiA+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+PiAK PiA+Pj4+Pj4+Pj4gVGhlIHRva2VuX2VuZHBvaW50IHJldHVybnMgYSBhY2Nlc3MgdG9rZW4uIMKg Tm90aGluZyByZXF1aXJlcyAKPiA+Pj4+Pj4+Pj4gc2NvcGUgdG8gYmUgYXNzb2NpYXRlcyB3aXRo IHRoZSB0b2tlbi4gCj4gPj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+PiDCoCAKPiA+Pj4+Pj4+Pj4gCj4g Pj4+Pj4+Pj4+IFRoYXQgaXMgdGhlIGJlc3Qgc29sdXRpb24uIMKgTm8gY2hhbmdlIHJlcXVpcmVk LiDCoEJldHRlciAKPiA+Pj4+Pj4+Pj4gaW50ZXJvcGVyYWJpbGl0eSBpbiBteSBvcGluaW9uLiAK PiA+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4gU3Rp bGwgb24gbXkgd2F5IHRvIFRPLCBnZXR0aW5nIGluIGxhdGVyIHRvZGF5LiAKPiA+Pj4+Pj4+Pj4g Cj4gPj4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4gSm9obiBCLiAKPiA+Pj4+ Pj4+Pj4gCj4gPj4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4gCj4gPj4+Pj4+ Pj4+IAo+ID4+Pj4+Pj4+PiBTZW50IGZyb20gbXkgaVBob25lIAo+ID4+Pj4+Pj4+PiAKPiA+Pj4+ Pj4+Pj4gCj4gPj4+Pj4+Pj4+IE9uIEp1bCAyMywgMjAxNCwgYXQgMTI6MTUgUE0sIHRvcnN0ZW5A bG9kZGVyc3RlZHQubmV0IHdyb3RlOiAKPiA+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4gVGhlICJy ZXNwb25zZSB0eXBlIiBvZiB0aGUgdG9rZW4gZW5kcG9pbnQgaXMgY29udHJvbGxlZCBieSB0aGUg dmFsdWUgb2YgdGhlIHBhcmFtZXRlciAiZ3JhbnRfdHlwZSIuIFNvIHRoZXJlIGlzIG5vIG5lZWQg dG8gaW50cm9kdWNlIGEgbmV3IHBhcmFtZXRlci4gCj4gPj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+ IHdydCB0byBhIHBvdGVudGlhbCAibm9fYWNjZXNzX3Rva2VuIiBncmFudCB0eXBlLiBJIGRvIG5v dCBjb25zaWRlciB0aGlzIGEgZ29vZCBpZGVhIGFzIGl0IGNoYW5nZXMgdGhlIHNlbWFudGljcyBv ZiB0aGUgdG9rZW4gZW5kcG9pbnQgKGFzIGFscmVhZHkgcG9pbnRlZCBvdXQgYnkgVGhvbWFzKS4g VGhpcyBlbmRwb2ludCBBTFdBWVMgcmVzcG9uZHMgd2l0aCBhbiBhY2Nlc3MgdG9rZW4gdG8gYW55 IGdyYW50IHR5cGUuIEkgdGhlcmVmb3JlIHdvdWxkIHByZWZlciB0byB1c2UgYW5vdGhlciBlbmRw b2ludCBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UuIAo+ID4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+ PiByZWdhcmRzLCAKPiA+Pj4+Pj4+Pj4+IFRvcnN0ZW4uIAo+ID4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+ Pj4+PiDCoCAKPiA+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4gQW0gMjMuMDcuMjAxNCAxMzowNCwg c2NocmllYiBOYXQgU2FraW11cmE6IAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IElNSE8s IGNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgInJlc3BvbnNlX3R5cGUiIEAgYXV0aHogCj4gPj4+ Pj4+Pj4+Pj4gZW5kcG9pbnQgdGhpcyB3YXkgaXMgbm90IGEgZ29vZCB0aGluZy4gCj4gPj4+Pj4+ Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gSW5z dGVhZCwgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVyICJyZXNwb25zZV90eXBlIiBAIHRva2VuIAo+ ID4+Pj4+Pj4+Pj4+IGVuZHBvaW50LCBhcyBJIGRlc2NyaWJlZCBpbiBteSBwcmV2aW91cyBtZXNz YWdlLCAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiBwcm9iYWJseSBpcyBiZXR0ZXIuIEF0 IGxlYXN0LCBpdCBkb2VzIG5vdCBjaGFuZ2UgdGhlIAo+ID4+Pj4+Pj4+Pj4+IHNlbWFudGljcyBv ZiB0aGUgcGFyYW1ldGVycyBvZiBSRkM2NzQ5LiAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+ PiDCoCAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiDCoE5hdCAKPiA+Pj4+Pj4+Pj4+PiAK PiA+Pj4+Pj4+Pj4+PiDCoCAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiAyMDE0LTA3LTIz IDEyOjQ4IEdNVC0wNDowMCBUaG9tYXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb20+OiAKPiA+ Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiBObywgSSBtZWFuIHJlc3BvbnNlX3R5cGU9bm9uZSBh bmQgcmVzcG9uc2VfdHlwZT1pZF90b2tlbiBkb24ndCBnZW5lcmF0ZSBhIGNvZGUgb3IgYWNjZXNz IHRva2VuIHNvIHlvdSBkb24ndCB1c2UgdGhlIFRva2VuIEVuZHBvaW50ICh3aGljaCBpcyBub3Qg dGhlIHNhbWUgYXMgdGhlIEF1dGhlbnRpY2F0aW9uIEVuZHBvaW50IEJUVykuIAo+ID4+Pj4+Pj4+ Pj4+IAo+ID4+Pj4+Pj4+Pj4+IFdpdGggcmVzcG9uc2VfdHlwZT1jb2RlX2Zvcl9pZF90b2tlbiwg eW91IGdldCBhIGNvZGUgYW5kIGV4Y2hhbmdlIGl0IGZvciBhbiBpZF90b2tlbiBvbmx5LCByYXRo ZXIgdGhhbiBhbiBhY2Nlc3NfdG9rZW4sIHNvIHlvdSdyZSBjaGFuZ2luZyB0aGUgc2VtYW50aWNz IG9mIHRoZSBUb2tlbiBFbmRwb2ludC4gCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gwqAg Cj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gSSdtIG5vdCBzYXlpbmcgaXQncyBhIGJhZCB0 aGluZywganVzdCB0aGF0IHlvdSBjYW4ndCByZWFsbHkgY29tcGFyZSBub25lIGFuZCBpZF90b2tl biB3aXRoIGNvZGVfZm9yX2lkX3Rva2VuLiAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiDC oCAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiBPbiBXZWQsIEp1bCAyMywgMjAxNCBhdCA2 OjQ1IFBNLCBSaWNoZXIsIEp1c3RpbiBQLiA8anJpY2hlckBtaXRyZS5vcmc+IHdyb3RlOiAKPiA+ Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiBJdCdzIG9ubHkgIm5vdCB1c2luZyB0aGUgdG9rZW4g ZW5kcG9pbnQiIGJlY2F1c2UgdGhlIHRva2VuIGVuZHBvaW50IGNvcHktcGFzdGVkIGFuZCByZW5h bWVkIHRoZSBhdXRoZW50aWNhdGlvbiBlbmRwb2ludC4gCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+ Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gwqAtLSBKdXN0aW4gCj4gPj4+ Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4g T24gSnVsIDIzLCAyMDE0LCBhdCA5OjMwIEFNLCBUaG9tYXMgQnJveWVyIDx0LmJyb3llckBnbWFp bC5jb20+IHdyb3RlOiAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiDCoCAKPiA+Pj4+Pj4+ Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiBFeGNlcHQgdGhhdCB0aGVzZSBhcmUgYWJvdXQgbm90IHVzaW5n IHRoZSBUb2tlbiBFbmRwb2ludCBhdCBhbGwsIHdoZXJlYXMgdGhlIGN1cnJlbnQgcHJvcG9zYWwg aXMgYWJvdXQgdGhlIFRva2VuIEVuZHBvaW50IG5vdCByZXR1cm5pbmcgYW4gYWNjZXNzX3Rva2Vu IGZpZWxkIGluIHRoZSBKU09OLiAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiDCoCAKPiA+ Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiBPbiBXZWQsIEp1bCAyMywgMjAxNCBhdCA0OjI2IFBN LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IHdyb3RlOiAKPiA+Pj4+ Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiBUaGUgcmVzcG9uc2VfdHlwZSAibm9uZSIgaXMgYWxyZWFk eSB1c2VkIGluIHByYWN0aWNlLCB3aGljaCByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi7CoCBJdCB3 YXMgYWNjZXB0ZWQgYnkgdGhlIGRlc2lnbmF0ZWQgZXhwZXJ0cyBhbmQgcmVnaXN0ZXJlZCBpbiB0 aGUgSUFOQSBPQXV0aCBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGVzIHJlZ2lz dHJ5IGF0IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9v YXV0aC1wYXJhbWV0ZXJzLnhtbCNlbmRwb2ludC7CoCBUaGUgcmVnaXN0ZXJlZCAiaWRfdG9rZW4i IHJlc3BvbnNlIHR5cGUgYWxzbyByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi4gCj4gPj4+Pj4+Pj4+ Pj4gCj4gPj4+Pj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gU28gSSB0 aGluayB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciByZXNwb25zZSB0eXBlcyB0aGF0IHJlc3VsdCBp biBubyBhY2Nlc3MgdG9rZW4gYmVpbmcgcmV0dXJuZWQgYXJlIGFjY2VwdGFibGUgd2l0aGluIE9B dXRoIDIuMCBpcyBhbHJlYWR5IHNldHRsZWQsIGFzIGEgcHJhY3RpY2FsIG1hdHRlci7CoCBMb3Rz IG9mIE9BdXRoIGltcGxlbWVudGF0aW9ucyBhcmUgYWxyZWFkeSB1c2luZyBzdWNoIHJlc3BvbnNl IHR5cGVzLiAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiDCoCAKPiA+Pj4+Pj4+Pj4+PiAK PiA+Pj4+Pj4+Pj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIAo+ID4+Pj4+Pj4+Pj4+IC0tIE1pa2UgCj4gPj4+Pj4+Pj4+Pj4g Cj4gPj4+Pj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gRnJvbTogT0F1 dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgCj4gPj4+Pj4+ Pj4+Pj4gUGhpbCBIdW50IAo+ID4+Pj4+Pj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMywg MjAxNCA3OjA5IEFNIAo+ID4+Pj4+Pj4+Pj4+IFRvOiBOYXQgU2FraW11cmEgCj4gPj4+Pj4+Pj4+ Pj4gQ2M6IDxvYXV0aEBpZXRmLm9yZz4gCj4gPj4+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtPQVVU SC1XR10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciAKPiA+Pj4+Pj4+Pj4+PiBkcmFmdC1o dW50LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dCAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+ PiDCoCAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiBZZXMuIFRoaXMgaXMgd2h5IGl0IGhh cyB0byBiZSBkaXNjdXNzZWQgaW4gdGhlIElFVEYuIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+ Pj4+IMKgIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IFBoaWwgCj4gPj4+Pj4+Pj4+Pj4g Cj4gPj4+Pj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gQGluZGVwZW5k ZW50aWQgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gd3d3LmluZGVwZW5kZW50aWQuY29t IAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IHBoaWwuaHVudEBvcmFjbGUuY29tIAo+ID4+ Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+ IMKgIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+ Pj4+Pj4+Pj4+IE9uIEp1bCAyMywgMjAxNCwgYXQgOTo0MyBBTSwgTmF0IFNha2ltdXJhIDxzYWtp bXVyYUBnbWFpbC5jb20+IHdyb3RlOiAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiDCoCAK PiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiBSZWFkaW5nIGJhY2sgdGhlIFJGQzY3NDksIEkg YW0gbm90IHN1cmUgaWYgdGhlcmUgaXMgYSBnb29kIAo+ID4+Pj4+Pj4+Pj4+IHdheSBvZiBzdXBw cmVzc2luZyBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgcmVzcG9uc2UgYW5kIHN0aWxsIGJlIE9BdXRo LiBJdCB3aWxsIGJyZWFrIHdob2xlIGJ1bmNoIG9mIGltcGxpY2l0IGRlZmluaXRpb25zIGxpa2U6 IAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+ Pj4+Pj4+IGF1dGhvcml6YXRpb24gc2VydmVyIAo+ID4+Pj4+Pj4+Pj4+IMKgIMKgIMKgIFRoZSBz ZXJ2ZXIgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0ZXIgCj4gPj4+Pj4+ Pj4+Pj4gc3VjY2Vzc2Z1bGx5IAo+ID4+Pj4+Pj4+Pj4+IMKgIMKgIMKgIGF1dGhlbnRpY2F0aW5n IHRoZSByZXNvdXJjZSBvd25lciBhbmQgb2J0YWluaW5nIGF1dGhvcml6YXRpb24uIAo+ID4+Pj4+ Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IEFm dGVyIGFsbCwgT0F1dGggaXMgYWxsIGFib3V0IGlzc3VpbmcgYWNjZXNzIHRva2Vucy4gCj4gPj4+ Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4g QWxzbywgSSB0YWtlIGJhY2sgbXkgc3RhdGVtZW50IG9uIHRoZSBncmFudCB0eXBlIGluIG15IAo+ ID4+Pj4+Pj4+Pj4+IHByZXZpb3VzIG1haWwuIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+ IMKgIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IFRoZSBkZWZpbml0aW9uIG9mIGdyYW50 IGFuZCBncmFudF90eXBlIGFyZSByZXNwZWN0aXZlbHk6IAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+ Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IGdyYW50IAo+ID4+Pj4+Pj4+ Pj4+IAo+ID4+Pj4+Pj4+Pj4+IMKgIMKgIGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNv dXJjZSBvd25lcidzIAo+ID4+Pj4+Pj4+Pj4+IGF1dGhvcml6YXRpb24gCj4gPj4+Pj4+Pj4+Pj4g Cj4gPj4+Pj4+Pj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAKPiA+Pj4+Pj4+Pj4+PiAKPiA+ Pj4+Pj4+Pj4+PiBncmFudF90eXBlIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IMKgwqDC oCAoc3RyaW5nIHJlcHJlc2VudGluZyB0aGUpIHR5cGUgb2YgZ3JhbnQgc2VudCB0byB0aGUgCj4g Pj4+Pj4+Pj4+Pj4gdG9rZW4gZW5kcG9pbnQgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW4gCj4g Pj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+ Pj4gVGh1cywgdGhlIGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IGluIHRoaXMgY2Fz ZSBpcyAKPiA+Pj4+Pj4+Pj4+PiBzdGlsbCAnY29kZScuIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+ Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IFJlc3BvbnNlIHR5cGUgb24g dGhlIG90aGVyIGhhbmQgaXMgbm90IHNvIHdlbGwgZGVmaW5lZCBpbiAKPiA+Pj4+Pj4+Pj4+PiBS RkM2NzQ5LCBidXQgaXQgc2VlbXMgaXQgaXMgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0 dXJuZWQgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gVG8gZXhwcmVzcyB3aGF0IGlz IHRvIGJlIHJldHVybmVkIGZyb20gdG9rZW4gZW5kcG9pbnQsIHBlcmhhcHMgZGVmaW5pbmcgYSBu ZXcgcGFyYW1ldGVyIHRvIHRoZSB0b2tlbiBlbmRwb2ludCwgd2hpY2ggaXMgYSBwYXJhbGxlbCB0 byB0aGUgcmVzcG9uc2VfdHlwZSB0byB0aGUgQXV0aG9yaXphdGlvbiBFbmRwb2ludCBzZWVtcyB0 byBiZSBhIG1vcmUgc3ltbWV0cmljIHdheSwgdGhvdWdoIEkgYW0gbm90IHN1cmUgYXQgYWxsIGlm IHRoYXQgaXMgZ29pbmcgdG8gYmUgT0F1dGggYW55IG1vcmUuIE9uZSBzdHJhdy1tYW4gaXMgdG8g ZGVmaW5lIGEgbmV3IHBhcmFtZXRlciBjYWxsZWQgcmVzcG9uc2VfdHlwZSB0byB0aGUgdG9rZW4g ZW5kcG9pbnQgc3VjaCBhczogCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gwqAgCj4gPj4+ Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gcmVzcG9uc2VfdHlwZSAKPiA+Pj4+Pj4+Pj4+PiAKPiA+ Pj4+Pj4+Pj4+PiDCoCDCoCBPUFRJT05BTC4gQSBzdHJpbmcgcmVwcmVzZW50aW5nIHdoYXQgaXMg dG8gYmUgcmV0dXJuZWQgCj4gPj4+Pj4+Pj4+Pj4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQuIAo+ ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IMKgIMKgwqAgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+ Pj4+Pj4+Pj4gVGhlbiBkZWZpbmUgdGhlIGJlaGF2aW9yIG9mIHRoZSBlbmRwb2ludCBhY2NvcmRp bmcgdG8gdGhlIAo+ID4+Pj4+Pj4+Pj4+IHZhbHVlcyBhcyB0aGUgcGFyYWxsZWwgdG8gdGhlIG11 bHRpLXJlc3BvbnNlIHR5cGUgc3BlYy4gCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gaHR0 cDovL29wZW5pZC5uZXQvc3BlY3Mvb2F1dGgtdjItbXVsdGlwbGUtcmVzcG9uc2UtdHlwZXMtMV8w IAo+ID4+Pj4+Pj4+Pj4+IC5odG1sIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IMKgIAo+ ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IE5hdCAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+ Pj4+PiDCoCDCoMKgIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+ Pj4+IAo+ID4+Pj4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IMKgIAo+ ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IDIwMTQtMDctMjMgNzoyMSBHTVQtMDQ6MDAgUGhp bCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT46IAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+ Pj4+IFRoZSBkcmFmdCBpcyB2ZXJ5IGNsZWFyLiAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+ PiBQaGlsIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IE9uIEp1 bCAyMywgMjAxNCwgYXQgMDo0NiwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+IHdy b3RlOiAKPiA+Pj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+IFRoZSBuZXcgZ3JhbnQgdHlwZSB0 aGF0IEkgd2FzIHRhbGtpbmcgYWJvdXQgd2FzIAo+ID4+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+ Pj4gImF1dGhvcml6YXRpb25fY29kZV9idXRfZG9fbm90X3JldHVybl9hY2Nlc3Nfbm9yX3JlZnJl c2hfdG8gCj4gPj4+Pj4+Pj4+Pj4+IGtlbiIsIHNvIHRvIHNwZWFrLiAKPiA+Pj4+Pj4+Pj4+Pj4g Cj4gPj4+Pj4+Pj4+Pj4+IEl0IGRvZXMgbm90IHJldHVybiBhbnl0aGluZyBwZXIgc2UsIGJ1dCBh biBleHRlbnNpb24gY2FuIAo+ID4+Pj4+Pj4+Pj4+PiBkZWZpbmUgc29tZXRoaW5nIG9uIHRvcCBv ZiBpdC4gCj4gPj4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiDCoCAKPiA+Pj4+Pj4+Pj4+Pj4g Cj4gPj4+Pj4+Pj4+Pj4+IFRoZW4sIE9JREMgY2FuIGRlZmluZSBhIGJpbmRpbmcgdG8gaXQgc28g dGhhdCB0aGUgYmluZGluZyAKPiA+Pj4+Pj4+Pj4+Pj4gb25seSByZXR1cm5zIElEIFRva2VuLiAK PiA+Pj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+IFRoaXMgYmluZGluZyB3b3JrIHNob3VsZCBi ZSBkb25lIGluIE9JREYuIFNob3VsZCB0aGVyZSBiZSAKPiA+Pj4+Pj4+Pj4+Pj4gc3VjaCBhIGdy YW50IHR5cGUsIAo+ID4+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gaXQgd2lsbCBiZSBhbiBl eHRyZW1lbHkgc2hvcnQgc3BlYy4gCj4gPj4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiDCoCAK PiA+Pj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+IEF0IHRoZSBzYW1lIHRpbWUsIGlmIGFueSBv dGhlciBzcGVjaWZpY2F0aW9uIHdhbnRlZCB0byAKPiA+Pj4+Pj4+Pj4+Pj4gZGVmaW5lIAo+ID4+ Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gb3RoZXIgdHlwZSBvZiB0b2tlbnMgYW5kIGhhdmUg aXQgcmV0dXJuZWQgZnJvbSB0aGUgdG9rZW4gCj4gPj4+Pj4+Pj4+Pj4+IGVuZHBvaW50LCAKPiA+ Pj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+IGl0IGNhbiBhbHNvIHVzZSB0aGlzIGdyYW50IHR5 cGUuIAo+ID4+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+Pj4+IAo+ ID4+Pj4+Pj4+Pj4+PiBJZiB3aGF0IHlvdSB3YW50IGlzIHRvIGRlZmluZSBhIG5ldyBncmFudCB0 eXBlIHRoYXQgcmV0dXJucyAKPiA+Pj4+Pj4+Pj4+Pj4gSUQgVG9rZW4gb25seSwgCj4gPj4+Pj4+ Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiB0aGVuLCBJIGFtIHdpdGggSnVzdGluLiBTaW5jZSAib3Ro ZXIgcmVzcG9uc2UgdGhhbiBJRCAKPiA+Pj4+Pj4+Pj4+Pj4gVG9rZW4iIGlzIG9ubHkgCj4gPj4+ Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiB0aGVvcmV0aWNhbCwgdGhpcyBpcyBhIG1vcmUgcGxh dXNpYmxlIHdheSBmb3J3YXJkLCBJIAo+ID4+Pj4+Pj4+Pj4+PiBzdXBwb3NlLiAKPiA+Pj4+Pj4+ Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+Pj4g TmF0IAo+ID4+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+Pj4+IAo+ ID4+Pj4+Pj4+Pj4+PiAyMDE0LTA3LTIyIDE0OjMwIEdNVC0wNDowMCBKdXN0aW4gUmljaGVyIDxq cmljaGVyQG1pdC5lZHU+OiAKPiA+Pj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+IFNvIHRoZSBk cmFmdCB3b3VsZCBsaXRlcmFsbHkgdHVybiBpbnRvOiAKPiA+Pj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+ Pj4+Pj4+ICJUaGUgYTRjIHJlc3BvbnNlIHR5cGUgYW5kIGdyYW50IHR5cGUgcmV0dXJuIGFuIGlk X3Rva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IHdpdGggbm8gYWNjZXNzIHRva2VuLiBBbGwg cGFyYW1ldGVycyBhbmQgdmFsdWVzIGFyZSBkZWZpbmVkIGluIE9JREMuIiAKPiA+Pj4+Pj4+Pj4+ Pj4gCj4gPj4+Pj4+Pj4+Pj4+IFNlZW1zIGxpa2UgdGhlIHBlcmZlY3QgbWluaSBleHRlbnNpb24g ZHJhZnQgZm9yIE9JREYgdG8gZG8uIAo+ID4+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gLS1K dXN0aW4gCj4gPj4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiAvc2VudCBmcm9tIG15IHBob25l LyAKPiA+Pj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiBPbiBKdWwg MjIsIDIwMTQgMTA6MjkgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPiB3cm90 ZTogCj4gPj4+Pj4+Pj4+Pj4+ID4gCj4gPj4+Pj4+Pj4+Pj4+ID4gV2hhdCBhYm91dCBqdXN0IGRl ZmluaW5nIGEgbmV3IGdyYW50IHR5cGUgaW4gdGhpcyBXRz8gCj4gPj4+Pj4+Pj4+Pj4+ID4gCj4g Pj4+Pj4+Pj4+Pj4+ID4gCj4gPj4+Pj4+Pj4+Pj4+ID4gMjAxNC0wNy0yMiAxMjo1NiBHTVQtMDQ6 MDAgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT46IAo+ID4+Pj4+Pj4+Pj4+PiA+PiAK PiA+Pj4+Pj4+Pj4+Pj4gPj4gVGhhdCB3b3VsZCBiZSBuaWNlLiBIb3dldmVyIG9pZGMgc3RpbGwg bmVlZHMgdGhlIG5ldyAKPiA+Pj4+Pj4+Pj4+Pj4gPj4gZ3JhbnQgdHlwZSBpbiBvcmRlciB0byBp bXBsZW1lbnQgdGhlIHNhbWUgZmxvdy4gCj4gPj4+Pj4+Pj4+Pj4+ID4+IAo+ID4+Pj4+Pj4+Pj4+ PiA+PiBQaGlsIAo+ID4+Pj4+Pj4+Pj4+PiA+PiAKPiA+Pj4+Pj4+Pj4+Pj4gPj4gT24gSnVsIDIy LCAyMDE0LCBhdCAxMTozNSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+IHdyb3Rl OiAKPiA+Pj4+Pj4+Pj4+Pj4gPj4gCj4gPj4+Pj4+Pj4+Pj4+ID4+PiArMSB0byBKdXN0aW4uIAo+ ID4+Pj4+Pj4+Pj4+PiA+Pj4gCj4gPj4+Pj4+Pj4+Pj4+ID4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+ IDIwMTQtMDctMjIgOTo1NCBHTVQtMDQ6MDAgUmljaGVyLCBKdXN0aW4gUC4gPGpyaWNoZXJAbWl0 cmUub3JnPjogCj4gPj4+Pj4+Pj4+Pj4+ID4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+ID4+Pj4gRXJyb3Jz IGxpa2UgdGhlc2UgbWFrZSBpdCBjbGVhciB0byBtZSB0aGF0IGl0IHdvdWxkIG1ha2UgbXVjaCBt b3JlIHNlbnNlIHRvIGRldmVsb3AgdGhpcyBkb2N1bWVudCBpbiB0aGUgT3BlbklEIEZvdW5kYXRp b24uIEl0IHNob3VsZCBiZSBzb21ldGhpbmcgdGhhdCBkaXJlY3RseSByZWZlcmVuY2VzIE9wZW5J RCBDb25uZWN0IENvcmUgZm9yIGFsbCBvZiB0aGVzZSB0ZXJtcyBpbnN0ZWFkIG9mIHJlZGVmaW5p bmcgdGhlbS4gSXQncyBkb2luZyBhdXRoZW50aWNhdGlvbiwgd2hpY2ggaXMgZnVuZGFtZW50YWxs eSB3aGF0IE9wZW5JRCBDb25uZWN0IGRvZXMgb24gdG9wIG9mIE9BdXRoLCBhbmQgSSBkb24ndCBz ZWUgYSBnb29kIGFyZ3VtZW50IGZvciBkb2luZyB0aGlzIHdvcmsgaW4gdGhpcyB3b3JraW5nIGdy b3VwLiAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+PiDCoC0tIEp1c3Rp biAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+PiBPbiBKdWwgMjIsIDIw MTQsIGF0IDQ6MzAgQU0sIFRob21hcyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbT4gd3JvdGU6 IAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+PiAKPiA+Pj4+Pj4+Pj4+ Pj4gPj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+ID4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+PiBPbiBN b24sIEp1bCAyMSwgMjAxNCBhdCAxMTo1MiBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPiB3cm90ZTogCj4gPj4+Pj4+Pj4+Pj4+ID4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+ Pj4gPj4+Pj4+IFRoYW5rcyBmb3IgeW91ciByZXZpZXcsIFRob21hcy7CoCBUaGUgInByb21wdD1j b25zZW50IiBkZWZpbml0aW9uIGJlaW5nIG1pc3NpbmcgaXMgYW4gZWRpdG9yaWFsIGVycm9yLsKg IEl0IHNob3VsZCBiZTogCj4gPj4+Pj4+Pj4+Pj4+ID4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+ Pj4+IMKgIAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+ID4+Pj4+PiBjb25z ZW50IAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+ID4+Pj4+PiBUaGUgQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgU0hPVUxEIHByb21wdCB0aGUgRW5kLVVzZXIgZm9yIGNvbnNlbnQg YmVmb3JlIHJldHVybmluZyBpbmZvcm1hdGlvbiB0byB0aGUgQ2xpZW50LiBJZiBpdCBjYW5ub3Qg b2J0YWluIGNvbnNlbnQsIGl0IE1VU1QgcmV0dXJuIGFuIGVycm9yLCB0eXBpY2FsbHkgY29uc2Vu dF9yZXF1aXJlZC4gCj4gPj4+Pj4+Pj4+Pj4+ID4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+Pj4+ IMKgIAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+ID4+Pj4+PiBJJ2xsIHBs YW4gdG8gYWRkIGl0IGluIHRoZSBuZXh0IGRyYWZ0LiAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+Pj4gCj4g Pj4+Pj4+Pj4+Pj4+ID4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+PiBJdCBsb29rcyBsaWtlIHRo ZSBjb25zZW50X3JlcXVpcmVkIGVycm9yIG5lZWRzIHRvIGJlIGRlZmluZWQgdG9vLCBhbmQgeW91 IG1pZ2h0IGhhdmUgZm9yZ290dGVuIHRvIGFsc28gaW1wb3J0IGFjY291bnRfc2VsZWN0aW9uX3Jl cXVpcmVkIGZyb20gT3BlbklEIENvbm5lY3QuIAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+PiDCoCAKPiA+ Pj4+Pj4+Pj4+Pj4gPj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+ Pj4+ID4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+Pj4+IEkgYWdyZWUgdGhhdCB0aGVyZSdzIG5v IGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJlc3BvbnNlIHdpdGggbXVsdGlwbGUgImFtciIgdmFsdWVz IHRoYXQgaW5jbHVkZXMgIm1mYSIgYW5kIG9uZSB0aGF0IGRvZXNuJ3QuwqAgVW5sZXNzIGEgY2xl YXIgdXNlIGNhc2UgZm9yIHdoeSAibWZhIiBpcyBuZWVkZWQgY2FuIGJlIGlkZW50aWZpZWQsIHdl IGNhbiBkZWxldGUgaXQgaW4gdGhlIG5leHQgZHJhZnQuIAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+PiAK PiA+Pj4+Pj4+Pj4+Pj4gPj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+ID4+Pj4+IFRoYW5rcy4gCj4gPj4+ Pj4+Pj4+Pj4+ID4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+PiBIb3cgYWJvdXQgInB3ZCIgdGhl bj8gSSBmdWxseSB1bmRlcnN0YW5kIHRoYXQgSSBzaG91bGQgcmV0dXJuICJwd2QiIGlmIHRoZSB1 c2VyIGF1dGhlbnRpY2F0ZWQgdXNpbmcgYSBwYXNzd29yZCwgYnV0IHdoYXQgInRoZSBzZXJ2aWNl IGlmIGEgY2xpZW50IHNlY3JldCBpcyB1c2VkIiBtZWFucyBpbiB0aGUgZGVmaW5pdGlvbiBmb3Ig dGhlICJwd2QiIHZhbHVlPyAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+ID4+ Pj4+IChOb3RhOiBJIGtub3cgeW91J3JlIGF0IElFVEYtOTAsIEknbSByZWFkeSB0byB3YWl0IAo+ ID4+Pj4+Pj4+Pj4+PiA+Pj4+PiAndGlsIHlvdSBjb21lIGJhY2sgOy0pICkgCj4gPj4+Pj4+Pj4+ Pj4+ID4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+PiAtLSAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+Pj4g VGhvbWFzIEJyb3llciAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+Pj4gL3TJlC5tYS5iyoF3YS5qZS8gCj4g Pj4+Pj4+Pj4+Pj4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fIAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QgCj4gPj4+ Pj4+Pj4+Pj4+ID4+Pj4+IE9BdXRoQGlldGYub3JnIAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIAo+ID4+Pj4+Pj4+Pj4+PiA+ Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+IAo+ID4+Pj4+Pj4+ Pj4+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdCAKPiA+Pj4+Pj4+Pj4+Pj4g Pj4+PiBPQXV0aEBpZXRmLm9yZyAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4+IAo+ID4+Pj4+ Pj4+Pj4+PiA+Pj4gCj4gPj4+Pj4+Pj4+Pj4+ID4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+IAo+ID4+ Pj4+Pj4+Pj4+PiA+Pj4gLS0gCj4gPj4+Pj4+Pj4+Pj4+ID4+PiBOYXQgU2FraW11cmEgKD1uYXQp IAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uIGh0dHA6Ly9u YXQuc2FraW11cmEub3JnLyAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+IEBfbmF0X2VuIAo+ID4+Pj4+Pj4+ Pj4+PiA+Pj4gCj4gPj4+Pj4+Pj4+Pj4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXyAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+IE9BdXRoIG1haWxpbmcgbGlz dCAKPiA+Pj4+Pj4+Pj4+Pj4gPj4+IE9BdXRoQGlldGYub3JnIAo+ID4+Pj4+Pj4+Pj4+PiA+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCAKPiA+Pj4+Pj4+Pj4+ Pj4gPiAKPiA+Pj4+Pj4+Pj4+Pj4gPiAKPiA+Pj4+Pj4+Pj4+Pj4gPiAKPiA+Pj4+Pj4+Pj4+Pj4g PiAKPiA+Pj4+Pj4+Pj4+Pj4gPiAtLSAKPiA+Pj4+Pj4+Pj4+Pj4gPiBOYXQgU2FraW11cmEgKD1u YXQpIAo+ID4+Pj4+Pj4+Pj4+PiA+IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbiBodHRwOi8v bmF0LnNha2ltdXJhLm9yZy8gCj4gPj4+Pj4+Pj4+Pj4+ID4gQF9uYXRfZW4gCj4gPj4+Pj4+Pj4+ Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4+IMKgIAo+ ID4+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+Pj4gLS0gCj4gPj4+Pj4+Pj4+Pj4+IE5hdCBTYWtp bXVyYSAoPW5hdCkgCj4gPj4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+PiBDaGFpcm1hbiwgT3Bl bklEIEZvdW5kYXRpb24gaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIAo+ID4+Pj4+Pj4+Pj4+PiBA X25hdF9lbiAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiAKPiA+ Pj4+Pj4+Pj4+PiDCoCAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiAtLSAKPiA+Pj4+Pj4+ Pj4+PiBOYXQgU2FraW11cmEgKD1uYXQpIAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IENo YWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbiAKPiA+Pj4+Pj4+Pj4+PiBodHRwOi8vbmF0LnNha2lt dXJhLm9yZy8gCj4gPj4+Pj4+Pj4+Pj4gQF9uYXRfZW4gCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+ Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gCj4gPj4+Pj4+Pj4+ Pj4gT0F1dGggbWFpbGluZyBsaXN0IAo+ID4+Pj4+Pj4+Pj4+IE9BdXRoQGlldGYub3JnIAo+ID4+ Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGggCj4g Pj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4g wqAgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gLS0gCj4gPj4+Pj4+Pj4+Pj4gVGhvbWFz IEJyb3llciAKPiA+Pj4+Pj4+Pj4+PiAvdMmULm1hLmLKgXdhLmplLyAKPiA+Pj4+Pj4+Pj4+PiAK PiA+Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXyAKPiA+Pj4+Pj4+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QgCj4gPj4+Pj4+Pj4+Pj4gT0F1 dGhAaWV0Zi5vcmcgCj4gPj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+ PiAKPiA+Pj4+Pj4+Pj4+PiDCoCAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiAtLSAKPiA+ Pj4+Pj4+Pj4+PiBUaG9tYXMgQnJveWVyIAo+ID4+Pj4+Pj4+Pj4+IC90yZQubWEuYsqBd2EuamUv IAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIAo+ID4+Pj4+Pj4+Pj4+IE9BdXRo IG1haWxpbmcgbGlzdCAKPiA+Pj4+Pj4+Pj4+PiBPQXV0aEBpZXRmLm9yZyAKPiA+Pj4+Pj4+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIAo+ID4+Pj4+Pj4+ Pj4+IAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IMKgIAo+ID4+ Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4+IC0tIAo+ID4+Pj4+Pj4+Pj4+IE5hdCBTYWtpbXVyYSAo PW5hdCkgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3Vu ZGF0aW9uIAo+ID4+Pj4+Pj4+Pj4+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyAKPiA+Pj4+Pj4+ Pj4+PiBAX25hdF9lbiAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiDCoCAKPiA+Pj4+Pj4+ Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyAKPiA+Pj4+Pj4+Pj4+PiAKPiA+Pj4+Pj4+Pj4+PiBPQXV0aCBtYWlsaW5nIGxp c3QgCj4gPj4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gT0F1dGhAaWV0Zi5vcmcgCj4gPj4+Pj4+ Pj4+Pj4gCj4gPj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCAKPiA+Pj4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+Pj4gwqAgCj4gPj4+Pj4+Pj4+PiAKPiA+ Pj4+Pj4+Pj4+IMKgIAo+ID4+Pj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyAKPiA+Pj4+Pj4+Pj4+IE9BdXRoIG1haWxp bmcgbGlzdCAKPiA+Pj4+Pj4+Pj4+IE9BdXRoQGlldGYub3JnIAo+ID4+Pj4+Pj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCAKPiA+Pj4+Pj4+Pj4gCj4gPj4+ Pj4+Pj4+IAo+ID4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyAKPiA+Pj4+Pj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0IAo+ID4+Pj4+Pj4+PiBP QXV0aEBpZXRmLm9yZyAKPiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCAKPiA+Pj4+Pj4+PiAKPiA+Pj4+Pj4+PiAKPiA+Pj4+Pj4+PiAKPiA+Pj4+ Pj4+PiDCoCAKPiA+Pj4+Pj4+PiAKPiA+Pj4+Pj4+PiAtLSAKPiA+Pj4+Pj4+PiBOYXQgU2FraW11 cmEgKD1uYXQpIAo+ID4+Pj4+Pj4+IAo+ID4+Pj4+Pj4+IENoYWlybWFuLCBPcGVuSUQgRm91bmRh dGlvbiAKPiA+Pj4+Pj4+PiBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8gCj4gPj4+Pj4+Pj4gQF9u YXRfZW4gCj4gPj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4gCj4gPj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gCj4gPj4+Pj4+Pj4gT0F1dGggbWFpbGlu ZyBsaXN0IAo+ID4+Pj4+Pj4+IE9BdXRoQGlldGYub3JnIAo+ID4+Pj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGggCj4gPj4+Pj4+IAo+ID4+Pj4+PiAKPiA+ Pj4+Pj4gCj4gPj4+Pj4+IMKgIAo+ID4+Pj4+PiAKPiA+Pj4+Pj4gLS0gCj4gPj4+Pj4+IE5hdCBT YWtpbXVyYSAoPW5hdCkgCj4gPj4+Pj4+IAo+ID4+Pj4+PiBDaGFpcm1hbiwgT3BlbklEIEZvdW5k YXRpb24gCj4gPj4+Pj4+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyAKPiA+Pj4+Pj4gQF9uYXRf ZW4gCj4gPj4+Pj4gCj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gCj4gPj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0IAo+ID4+Pj4+IE9BdXRoQGll dGYub3JnIAo+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGggCj4gPj4+PiAKPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fIAo+ID4+Pj4gT0F1dGggbWFpbGluZyBsaXN0IAo+ID4+Pj4gT0F1dGhAaWV0Zi5v cmcgCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIAo+ ID4+IAo+ID4+IMKgIAo+ID4+IAo+ID4+IMKgIAo= From nobody Thu Jul 24 05:29:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7521A0243 for ; Thu, 24 Jul 2014 05:29:23 -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=[AC_DIV_BONANZA=0.001, 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 iL_BjaDj5lFC for ; Thu, 24 Jul 2014 05:29:17 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9718D1A023E for ; Thu, 24 Jul 2014 05:29:16 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so1866819lam.0 for ; Thu, 24 Jul 2014 05:29:14 -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=6GCHw35DX1mhTf60yXSUKxTuQDgniS1FgrdU5cHOlcE=; b=0ZxEgJ9tRA7NnTXJ7UshwzOSzM8DPpZlZB/4wQreikrnOkATQfA+EpnokefNBkTTQT gcg6pxaV/uZapmD21CGZ9OKogT41Jj33wza6EhqRIobzAFBnua2kWMGDJAThq10H/oYd NdW70CHG3tbBQ9/ZrVh9ZUuWGlbp7J93KuHU6uIwGg4pLuJVPGIxKbdBD5J/OCzoGZga AuoeBj/ftjeQl99pLx+NsDVbZYXShm5sKzouaJ7LGusz9m5ItrMxMKcgajrw5O7M2Vdr U1vXnkrBlOWUUqU8cpNdiixfiRVPaTKLC1Yfl9I0de2xGNmkQtDTJPBDpMyAkQol3RM8 vZKg== MIME-Version: 1.0 X-Received: by 10.112.155.129 with SMTP id vw1mr8619712lbb.7.1406204954397; Thu, 24 Jul 2014 05:29:14 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Thu, 24 Jul 2014 05:29:14 -0700 (PDT) In-Reply-To: <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> Date: Thu, 24 Jul 2014 08:29:14 -0400 Message-ID: From: Nat Sakimura To: John Bradley Content-Type: multipart/alternative; boundary=089e01183046c9d66604feef9a86 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Bor_SS7juq_pZcpaNIxjAZPH9bM Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 12:29:23 -0000 --089e01183046c9d66604feef9a86 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And here is a quote from Ian's blog. And although the authentication wheel is round, that doesn=E2=80=99t mean i= t isn=E2=80=99t > without its lumps. First, we do see some reinventing the wheel just to > reinvent the wheel. OAuth A4C is simply not a fruitful activity and shoul= d > be put down. > (Source) > http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musin= gs-on-identity-standards-part-1.html 2014-07-23 16:53 GMT-04:00 John Bradley : > I thought I did post this to the list. > > I guess I hit the wrong reply on my phone. > > John B. > Sent from my iPhone > > On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: > > we are two, at least :-) > > Why didn't you post this on the list? > > When will be be arriving? > > Am 23.07.2014 16:39, schrieb John Bradley: > > Ian Glazer mentioned this in his keynote at CIS yesterday. > > His advice was please stop, we are creating confusion and uncertainty. > > We are becoming our own wort enemy. ( my view though Ian may share it) > > Returning just an id_ token from the token endpoint has little real value= . > > Something really useful to do would be sorting out channel_id so we can d= o > PoP for id tokens to make them and other cookies secure in the front > channel. I think that is a better use of time. > > I may be in the minority opinion on that, it won't be the first time. > > > John B. > Sent from my iPhone > > On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt > wrote: > > You are right from a theoretical perspective. Practically this was > caused by editorial decisions during the creation of the RFC. As far as I > remember, there was a definition of the (one) token endpoint response in > early versions. No one every considered to NOT respond with an access tok= en > from the token endpoint. So one might call it an implicit assumption. > > I'm worried that people get totally confused if an exception is introduce= d > now given the broad adoption of OAuth based on this assumption. > > regards, > Torsten. > > Am 23.07.2014 um 15:41 schrieb Thomas Broyer : > > Is it said anywhere that ALL grant types MUST use Section 5.1 responses? > Each grant type references Section 5.1, and "access token request" is onl= y > defined in the context of the defined grant types. Section 2.2 doesn't ta= lk > about the request or response format. > Le 23 juil. 2014 21:32, "Nat Sakimura" a =C3=A9crit = : > >> Is it? Apart from the implicit grant that does not use token endpoint, >> all other grant references section 5.1 for the response, i.e., all share= s >> the same response. >> >> >> 2014-07-23 15:18 GMT-04:00 Thomas Broyer : >> >>> I hadn't realized the JSON response that requires the access_token fiel= d >>> is defined per grant_type, so I'd be OK to "extend the semantics" as in= the >>> current draft. >>> That was actually my main concern: that the token endpoint mandates >>> access_token; but its actually not the case. >>> Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9cri= t : >>> >>> I agree with John that overloading response_type @ authz endpoint is a >>>> bad idea. It completely changes the semantics of this parameter. NOTE:= what >>>> I was proposing was not this parameter, but a new parameter response_t= ype @ >>>> token endpoint. >>>> >>>> I also think overloading grant_type is a bad idea since it changes its >>>> semantics. I quote the definition here again: >>>> >>>> grant >>>> credential representing the resource owner's authorization >>>> >>>> grant_type >>>> type of grant sent to the token endpoint to obtain the access token >>>> >>>> It is not about controlling what is to be returned from the token >>>> endpoint, but the hint to the token endpoint describing the type of >>>> credential the endpoint has received. It seems the "control of what is >>>> being returned from token endpoint" is just a side effect. >>>> >>>> I am somewhat ambivalent[1] in changing the semantics of token >>>> endpoint, but in as much as "text is the king" for a spec., we probabl= y >>>> should not change the semantics of it as Torsten points out. If it is = ok to >>>> change this semantics, I believe defining a new parameter to this endp= oint >>>> to control the response would be the best way to go. This is what I ha= ve >>>> described previously. >>>> >>>> Defining a new endpoint to send code to get ID Token and forbidding th= e >>>> use of it against token endpoint would not change the semantics of any >>>> existing parameter or endpoint, which is good. However, I doubt if it = is >>>> not worth doing. What's the point of avoiding access token scoped to >>>> UserInfo endpoint after all? Defining a new endpoint for just avoiding= the >>>> access token for userinfo endpoint seems way too much the heavy wait w= ay >>>> and it breaks interoperabiliy: it defeats the purpose of standardizati= on. >>>> >>>> I have started feeling that no change is the best way out. >>>> >>>> Nat >>>> >>>> [1] If instead of saying "Token endpoint - used by the client to >>>> exchange an authorization grant for an access token, typically with >>>> client authentication", it were saying "Token endpoint - used by the >>>> client to exchange an authorization grant for tokens, typically with >>>> client authentication", then it would have been OK. It is an expansion= of >>>> the capability rather than changing the semantics. >>>> >>>> >>>> >>>> 2014-07-23 13:39 GMT-04:00 Mike Jones : >>>> >>>>> You need the alternative response_type value ("code_for_id_token" in >>>>> the A4C draft) to tell the Authorization Server to return a code to b= e used >>>>> with the new grant type, rather than one to use with the >>>>> "authorization_code" grant type (which is what response_type=3Dcode d= oes). >>>>> >>>>> >>>>> >>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John >>>>> Bradley >>>>> *Sent:* Wednesday, July 23, 2014 10:33 AM >>>>> *To:* torsten@lodderstedt.net >>>>> >>>>> *Cc:* oauth@ietf.org >>>>> *Subject:* Re: [OAUTH-WG] New Version Notification for >>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> If we use the token endpoint then a new grant_type is the best way. >>>>> >>>>> >>>>> >>>>> It sort of overloads code, but that is better than messing with >>>>> response_type for the authorization endpoint to change the response f= rom >>>>> the token_endpoint. That is in my opinion a champion bad idea. >>>>> >>>>> >>>>> >>>>> In discussions developing Connect we decided not to open this can of >>>>> worms because no good would come of it. >>>>> >>>>> >>>>> >>>>> The token_endpoint returns a access token. Nothing requires scope to >>>>> be associates with the token. >>>>> >>>>> >>>>> >>>>> That is the best solution. No change required. Better >>>>> interoperability in my opinion. >>>>> >>>>> >>>>> >>>>> Still on my way to TO, getting in later today. >>>>> >>>>> >>>>> >>>>> John B. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Sent from my iPhone >>>>> >>>>> >>>>> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >>>>> >>>>> The "response type" of the token endpoint is controlled by the value >>>>> of the parameter "grant_type". So there is no need to introduce a new >>>>> parameter. >>>>> >>>>> wrt to a potential "no_access_token" grant type. I do not consider >>>>> this a good idea as it changes the semantics of the token endpoint (a= s >>>>> already pointed out by Thomas). This endpoint ALWAYS responds with an >>>>> access token to any grant type. I therefore would prefer to use anoth= er >>>>> endpoint for the intended purpose. >>>>> >>>>> regards, >>>>> Torsten. >>>>> >>>>> >>>>> >>>>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>>>> >>>>> IMHO, changing the semantics of "response_type" @ authz endpoint >>>>> this way is not a good thing. >>>>> >>>>> >>>>> >>>>> Instead, defining a new parameter "response_type" @ token endpoint, a= s >>>>> I described in my previous message, >>>>> >>>>> probably is better. At least, it does not change the semantics of the >>>>> parameters of RFC6749. >>>>> >>>>> >>>>> >>>>> Nat >>>>> >>>>> >>>>> >>>>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >>>>> >>>>> No, I mean response_type=3Dnone and response_type=3Did_token don't >>>>> generate a code or access token so you don't use the Token Endpoint (= which >>>>> is not the same as the Authentication Endpoint BTW). >>>>> >>>>> With response_type=3Dcode_for_id_token, you get a code and exchange i= t >>>>> for an id_token only, rather than an access_token, so you're changing= the >>>>> semantics of the Token Endpoint. >>>>> >>>>> >>>>> >>>>> I'm not saying it's a bad thing, just that you can't really compare >>>>> none and id_token with code_for_id_token. >>>>> >>>>> >>>>> >>>>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. >>>>> wrote: >>>>> >>>>> It's only "not using the token endpoint" because the token endpoint >>>>> copy-pasted and renamed the authentication endpoint. >>>>> >>>>> >>>>> >>>>> -- Justin >>>>> >>>>> >>>>> >>>>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote= : >>>>> >>>>> >>>>> >>>>> Except that these are about not using the Token Endpoint at all, >>>>> whereas the current proposal is about the Token Endpoint not returnin= g an >>>>> access_token field in the JSON. >>>>> >>>>> >>>>> >>>>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones < >>>>> Michael.Jones@microsoft.com> wrote: >>>>> >>>>> The response_type "none" is already used in practice, which returns n= o >>>>> access token. It was accepted by the designated experts and register= ed in >>>>> the IANA OAuth Authorization Endpoint Response Types registry at >>>>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml= #endpoint. >>>>> The registered "id_token" response type also returns no access token. >>>>> >>>>> >>>>> >>>>> So I think the question of whether response types that result in no >>>>> access token being returned are acceptable within OAuth 2.0 is alread= y >>>>> settled, as a practical matter. Lots of OAuth implementations are al= ready >>>>> using such response types. >>>>> >>>>> >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> >>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hun= t >>>>> *Sent:* Wednesday, July 23, 2014 7:09 AM >>>>> *To:* Nat Sakimura >>>>> *Cc:* >>>>> *Subject:* Re: [OAUTH-WG] New Version Notification for >>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>> >>>>> >>>>> >>>>> Yes. This is why it has to be discussed in the IETF. >>>>> >>>>> >>>>> >>>>> Phil >>>>> >>>>> >>>>> >>>>> @independentid >>>>> >>>>> www.independentid.com >>>>> >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: >>>>> >>>>> >>>>> >>>>> Reading back the RFC6749, I am not sure if there is a good way of >>>>> suppressing access token from the response and still be OAuth. It wil= l >>>>> break whole bunch of implicit definitions like: >>>>> >>>>> >>>>> >>>>> authorization server >>>>> The server issuing access tokens to the client after successful= ly >>>>> authenticating the resource owner and obtaining authorization. >>>>> >>>>> >>>>> >>>>> After all, OAuth is all about issuing access tokens. >>>>> >>>>> >>>>> >>>>> Also, I take back my statement on the grant type in my previous mail. >>>>> >>>>> >>>>> >>>>> The definition of grant and grant_type are respectively: >>>>> >>>>> >>>>> >>>>> grant >>>>> >>>>> credential representing the resource owner's authorization >>>>> >>>>> >>>>> >>>>> grant_type >>>>> >>>>> (string representing the) type of grant sent to the token endpoin= t >>>>> to obtain the access token >>>>> >>>>> >>>>> >>>>> Thus, the grant sent to the token endpoint in this case is still >>>>> 'code'. >>>>> >>>>> >>>>> >>>>> Response type on the other hand is not so well defined in RFC6749, bu= t >>>>> it seems it is representing what is to be returned from the authoriza= tion >>>>> endpoint. To express what is to be returned from token endpoint, perh= aps >>>>> defining a new parameter to the token endpoint, which is a parallel t= o the >>>>> response_type to the Authorization Endpoint seems to be a more symmet= ric >>>>> way, though I am not sure at all if that is going to be OAuth any mor= e. One >>>>> straw-man is to define a new parameter called response_type to the to= ken >>>>> endpoint such as: >>>>> >>>>> >>>>> >>>>> response_type >>>>> >>>>> OPTIONAL. A string representing what is to be returned from the >>>>> token endpoint. >>>>> >>>>> >>>>> >>>>> Then define the behavior of the endpoint according to the values as >>>>> the parallel to the multi-response type spec. >>>>> >>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>> >>>>> >>>>> >>>>> Nat >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>>>> >>>>> The draft is very clear. >>>>> >>>>> Phil >>>>> >>>>> >>>>> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >>>>> >>>>> The new grant type that I was talking about was >>>>> >>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", so t= o >>>>> speak. >>>>> >>>>> It does not return anything per se, but an extension can define >>>>> something on top of it. >>>>> >>>>> >>>>> >>>>> Then, OIDC can define a binding to it so that the binding only return= s >>>>> ID Token. >>>>> >>>>> This binding work should be done in OIDF. Should there be such a gran= t >>>>> type, >>>>> >>>>> it will be an extremely short spec. >>>>> >>>>> >>>>> >>>>> At the same time, if any other specification wanted to define >>>>> >>>>> other type of tokens and have it returned from the token endpoint, >>>>> >>>>> it can also use this grant type. >>>>> >>>>> >>>>> >>>>> If what you want is to define a new grant type that returns ID Token >>>>> only, >>>>> >>>>> then, I am with Justin. Since "other response than ID Token" is only >>>>> >>>>> theoretical, this is a more plausible way forward, I suppose. >>>>> >>>>> >>>>> >>>>> Nat >>>>> >>>>> >>>>> >>>>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>>>> >>>>> So the draft would literally turn into: >>>>> >>>>> "The a4c response type and grant type return an id_token from the >>>>> token endpoint with no access token. All parameters and values are de= fined >>>>> in OIDC." >>>>> >>>>> Seems like the perfect mini extension draft for OIDF to do. >>>>> >>>>> --Justin >>>>> >>>>> /sent from my phone/ >>>>> >>>>> >>>>> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >>>>> > >>>>> > What about just defining a new grant type in this WG? >>>>> > >>>>> > >>>>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>>>> >> >>>>> >> That would be nice. However oidc still needs the new grant type in >>>>> order to implement the same flow. >>>>> >> >>>>> >> Phil >>>>> >> >>>>> >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote= : >>>>> >> >>>>> >>> +1 to Justin. >>>>> >>> >>>>> >>> >>>>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >>>>> >>>> >>>>> >>>> Errors like these make it clear to me that it would make much >>>>> more sense to develop this document in the OpenID Foundation. It shou= ld be >>>>> something that directly references OpenID Connect Core for all of the= se >>>>> terms instead of redefining them. It's doing authentication, which is >>>>> fundamentally what OpenID Connect does on top of OAuth, and I don't s= ee a >>>>> good argument for doing this work in this working group. >>>>> >>>> >>>>> >>>> -- Justin >>>>> >>>> >>>>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer >>>>> wrote: >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < >>>>> Michael.Jones@microsoft.com> wrote: >>>>> >>>>>> >>>>> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" >>>>> definition being missing is an editorial error. It should be: >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> consent >>>>> >>>>>> >>>>> >>>>>> The Authorization Server SHOULD prompt the End-User for consen= t >>>>> before returning information to the Client. If it cannot obtain conse= nt, it >>>>> MUST return an error, typically consent_required. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> I'll plan to add it in the next draft. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> It looks like the consent_required error needs to be defined >>>>> too, and you might have forgotten to also import account_selection_re= quired >>>>> from OpenID Connect. >>>>> >>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> I agree that there's no difference between a response with >>>>> multiple "amr" values that includes "mfa" and one that doesn't. Unle= ss a >>>>> clear use case for why "mfa" is needed can be identified, we can dele= te it >>>>> in the next draft. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> How about "pwd" then? I fully understand that I should return >>>>> "pwd" if the user authenticated using a password, but what "the servi= ce if >>>>> a client secret is used" means in the definition for the "pwd" value? >>>>> >>>>> >>>>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you com= e >>>>> back ;-) ) >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thomas Broyer >>>>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>> >>>>> _______________________________________________ >>>>> >>>>> 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 >>>>> >>>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> -- >>>>> >>> Nat Sakimura (=3Dnat) >>>>> >>> Chairman, OpenID Foundation >>>>> >>> http://nat.sakimura.org/ >>>>> >>> @_nat_en >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> OAuth mailing list >>>>> >>> OAuth@ietf.org >>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Nat Sakimura (=3Dnat) >>>>> > Chairman, OpenID Foundation >>>>> > http://nat.sakimura.org/ >>>>> > @_nat_en >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Nat Sakimura (=3Dnat) >>>>> >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Nat Sakimura (=3Dnat) >>>>> >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Broyer >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Broyer >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Nat Sakimura (=3Dnat) >>>>> >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e01183046c9d66604feef9a86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And here is a quote from Ian's blog.=C2=A0

And although the authentication wheel is round, that doesn=E2=80=99t mean i= t isn=E2=80=99t without its lumps. First, we do see some reinventing the wh= eel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity= and should be put down. =C2=A0
=C2=A0
(Source) http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wh= eel-yet-musings-on-identity-standards-part-1.html


2014-07= -23 16:53 GMT-04:00 John Bradley <ve7jtb@ve7jtb.com>:
I thought I did post this to the list.=C2=A0

I guess I hit the wrong reply on my phone.=C2=A0
=C2= =A0
John B.=C2=A0
Sent from my iPhone

On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote:

we are two, at least :-)

Why didn't you post this on the list?

When will be be arriving?

Am 23.07.2014 16:39, schrieb John Bradley:

Ian Glazer mentioned this in his keynote at CIS yesterday.=C2=A0
=C2=A0
His advice was please stop, =C2=A0we are creating confusion and uncert= ainty.=C2=A0
=C2=A0
We are becoming our own wort enemy. ( my view though Ian may share it)=
=C2=A0
Returning just an id_ token from the token endpoint has little real va= lue.=C2=A0
=C2=A0
Something really useful to do would be sorting out channel_id so we ca= n do PoP for id tokens to make them and other cookies secure in the front c= hannel. =C2=A0 I think that is a better use of time.=C2=A0
=C2=A0
I may be in the minority opinion on that, =C2=A0it won't be the fi= rst time. =C2=A0


John B.=C2=A0
Sent from my iPhon= e

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <torsten@lodderstedt.net= > wrote:

You are right from a theoretical perspective. Practically this was cau= sed by editorial decisions during the creation of the RFC. As far as I reme= mber, there was a definition of the (one) token endpoint response in early = versions. No one every considered to NOT respond with an access token from = the token endpoint. So one might call it an implicit assumption.
=C2=A0
I'm worried that people get totally confused if an exception is in= troduced now given the broad adoption of OAuth based on this assumption.
=C2=A0
regards,
Torsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

<= /div>

Is it said anywhere that ALL grant types MUST use Section 5.= 1 responses? Each grant type references Section 5.1, and "access token= request" is only defined in the context of the defined grant types. S= ection 2.2 doesn't talk about the request or response format.

Le 23 juil. 2014 21:32, "Nat Sakimura"= <sakimura@gmail= .com> a =C3=A9crit :
Is it? Apart from the implicit grant that does not use tok= en endpoint, all other grant references section 5.1 for the response, i.e.,= all shares the same response.=C2=A0


2014-07-23 15:18 GMT-04:00 Thomas Broyer &= lt;t.broyer@gmail.c= om>:

I hadn't realized the JSON response that requires the ac= cess_token field is defined per grant_type, so I'd be OK to "exten= d the semantics" as in the current draft.
That was actually my mai= n concern: that the token endpoint mandates access_token; but its actually = not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura"= <sakimura@gmail= .com> a =C3=A9crit :

I agree with John that overloading response_type @ authz endpoint is a= bad idea. It completely changes the semantics of this parameter. NOTE: wha= t I was proposing was not this parameter, but a new parameter response_type= @ token endpoint.=C2=A0
=C2=A0
I also think overloading grant_type is a bad idea since it changes its= semantics. I quote the definition here again:=C2=A0
=C2=A0
grant=C2=A0
=C2=A0 =C2=A0 credential representing the resource owner's authori= zation
=C2=A0
grant_type
type of grant sent to the= token endpoint to obtain the access token
=C2=A0
It is not about controlling what is to be returned from the token endp= oint, but the hint to the token endpoint describing the type of credential = the endpoint has received. It seems the "control of what is being retu= rned from token endpoint" =C2=A0is just a side effect.=C2=A0
=C2=A0
I am somewhat ambivalent[1] in changing the semantics of token endpoin= t, but in as much as "text is the king" for a spec., we probably = should not change the semantics of it as Torsten points out. If it is ok to= change this semantics, I believe defining a new parameter to this endpoint= to control the response would be the best way to go. This is what I have d= escribed previously.=C2=A0
=C2=A0
Defining a new endpoint to send code to get ID Token and forbidding th= e use of it against token endpoint would not change the semantics of any ex= isting parameter or endpoint, which is good. However, I doubt if it is not = worth doing. What's the point of avoiding access token scoped to UserIn= fo endpoint after all? Defining a new endpoint for just avoiding the access= token for userinfo endpoint seems way too much the heavy wait way and it b= reaks interoperabiliy: it defeats the purpose of standardization.=C2=A0
=C2=A0
I have started feeling that no change is the best way out.=C2=A0
=C2=A0
Nat
=C2=A0
[1] =C2=A0If instead of saying "Token endpoint - used by the client to exchange an authorization= =C2=A0grant for an access token, typically with client authenticatio= n", it were saying "T= oken endpoint - used by the client to exchange an authorization=C2=A0grant for tokens, typically with client authentication", then it woul= d have been OK. It is an expansion of the capability rather than changing t= he semantics.
=C2=A0


2014-07-23 13:39 GMT-04:00 Mike Jones <= Michael.Jo= nes@microsoft.com>:

You need the alternative resp= onse_type value ("code_for_id_token" in the A4C draft) to tell the Authorization Server to return= a code to be used with the new grant type, rather than one to use with the= "authorization_code" grant type (which is what response_type=3Dc= ode does).

=C2=A0=

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: torsten@= lodderstedt.net


Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New V= ersion Notification for draft-hunt-oauth-v2-user-a4c-05.txt=

=C2=A0

=C2= =A0

If we use the token endpoint then a new grant_type i= s the best way.=C2=A0

=C2= =A0

It sort of overloads code, but that is better than m= essing with response_type for the authorization endpoint to change the resp= onse from the token_endpoint. =C2=A0That is in my opinion a champion bad id= ea.=C2=A0

=C2= =A0

In discussions developing Connect we decided not to = open this can of worms because no good would come of it. =C2=A0=C2=A0

=C2= =A0

The token_endpoint returns a access token. =C2=A0Not= hing requires scope to be associates with the token.=C2=A0<= /span>

=C2= =A0

That is the best solution. =C2=A0No change required.= =C2=A0Better interoperability in my opinion.=C2=A0<= /p>

=C2= =A0

Still on my way to TO, getting in later today.=C2=A0=

=C2= =A0

John B.=C2=A0

=C2= =A0



Sent from my iPhone<= /p>


On Jul 23, 2014,= at 12:15 PM, = torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the= value of the parameter "grant_type". So there is no need to intr= oduce a new parameter.

wrt to a potential "no_access_token" grant type. I do not cons= ider this a good idea as it changes the semantics of the token endpoint (as= already pointed out by Thomas). This endpoint ALWAYS responds with an acce= ss token to any grant type. I therefore would prefer to use another endpoin= t for the intended purpose.

regards,
Torsten.

=C2=A0

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type&= quot; @ authz endpoint this way is not a good thing.=C2=A0<= /span>

=C2=A0

Instead, defining a new parameter "response_typ= e" @ token endpoint, as I described in my previous message,=C2=A0

probably is better. At least, it does not change the= semantics of the parameters of RFC6749.=C2=A0

=C2=A0

=C2=A0Nat=C2=A0

=C2=A0

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>= :

No, I mean response_type=3Dnone and response_type=3D= id_token don't generate a code or access token so you don't use the= Token Endpoint (which is not the same as the Authentication Endpoint BTW).=

With response_type=3Dcode_for_id_token, you get a co= de and exchange it for an id_token only, rather than an access_token, so yo= u're changing the semantics of the Token Endpoint.

=C2=A0

I'm not saying it's a bad thing, just that y= ou can't really compare none and id_token with code_for_id_token.

=C2=A0

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It's only "not using the token endpoint&quo= t; because the token endpoint copy-pasted and renamed the authentication en= dpoint.

=C2=A0

=C2=A0-- Justin

=C2= =A0

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com&g= t; wrote:



Except that these are about not using the Token Endp= oint at all, whereas the current proposal is about the Token Endpoint not r= eturning an access_token field in the JSON.

=C2=A0

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

The response_type "none&= quot; is already used in practice, which returns no access token.=C2=A0 It = was accepted by the designated experts and registered in the IANA OAuth Aut= horization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xm= l#endpoint.=C2=A0 The registered "id_token" response type als= o returns no access token.=

=C2=A0=

So I think the question of wh= ether response types that result in no access token being returned are acce= ptable within OAuth 2.0 is already settled, as a practical matter.=C2=A0 Lo= ts of OAuth implementations are already using such response types.

=C2=A0=

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

=C2=A0=

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of Phil Hunt
S= ent: Wednesday, July 23, 2014 7:09 AM
To:= Nat Sakimura
C= c: <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Versio= n Notification for draft-hunt-oauth-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

Phil

=C2=A0

@independentid

= phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

=C2=A0

Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The se= rver issuing access tokens to the client after successfully
=C2=A0 =C2= =A0 =C2=A0 authenticating the resource owner and obtaining authorization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type=

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token en= dpoint, perhaps defining a new parameter to the token endpoint, which is a = parallel to the response_type to the Authorization Endpoint seems to be a m= ore symmetric way, though I am not sure at all if that is going to be OAuth= any more. One straw-man is to define a new parameter called response_type = to the token endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0

=C2=A0

Nat=

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014,= at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0<= /span>

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat=

=C2=A0

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

&quo= t;The a4c response type and grant type return an id_token from the token en= dpoint with no access token. All parameters and values are defined in OIDC.= "

Seems like the perfect mini extension draft for OIDF to do.

--= Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com&= gt; wrote:
>
> What about just defining a new grant type in t= his WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>= ;:
>>
>> That would be nice. However oidc still needs t= he new grant type in order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 1= 1:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to J= ustin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 R= icher, Justin P. <jricher@mitre.org>:
>>>>
>>>> Error= s like these make it clear to me that it would make much more sense to deve= lop this document in the OpenID Foundation. It should be something that dir= ectly references OpenID Connect Core for all of these terms instead of rede= fining them. It's doing authentication, which is fundamentally what Ope= nID Connect does on top of OAuth, and I don't see a good argument for d= oing this work in this working group.
>>>>
>>>> =C2=A0-- Justin
>>>>=
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com>= ; wrote:
>>>>
>>>>>
>>>>>
>= ;>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM= , Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>>>
>>>>>> Thanks for your revi= ew, Thomas.=C2=A0 The "prompt=3Dconsent" definition being missing= is an editorial error.=C2=A0 It should be:
>>>>>> >>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>= >>>>
>>>>>> The Authorization Server SHOU= LD prompt the End-User for consent before returning information to the Clie= nt. If it cannot obtain consent, it MUST return an error, typically consent= _required.
>>>>>>
>>>>>> =C2=A0
>>&= gt;>>>
>>>>>> I'll plan to add it in the= next draft.
>>>>>
>>>>>
>>= >>> It looks like the consent_required error needs to be defined t= oo, and you might have forgotten to also import account_selection_required = from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>&= gt;>> =C2=A0
>>>>>>
>>>>>>= ; I agree that there's no difference between a response with multiple &= quot;amr" values that includes "mfa" and one that doesn'= t.=C2=A0 Unless a clear use case for why "mfa" is needed can be i= dentified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Tha= nks.
>>>>>
>>>>> How about "pwd&= quot; then? I fully understand that I should return "pwd" if the = user authenticated using a password, but what "the service if a client= secret is used" means in the definition for the "pwd" value= ?
>>>>>
>>>>> (Nota: I know you're at = IETF-90, I'm ready to wait 'til you come back ;-) )
>>>= ;>>
>>>>> --
>>>>> Thomas Broye= r
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _________= ______________________________________
>>>>> OAuth maili= ng list
>>>>> O= Auth@ietf.org
>>>>> https://www.ietf.org/mailman/list= info/oauth
>>>>
>>>>
>>>>
>>>= ;> _______________________________________________
>>>> = OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>&g= t;>>
>>>
>>>
>>>
>>&= gt; --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Found= ation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>><= br> >>> _______________________________________________
>>&= gt; OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/ma= ilman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)=
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)=

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en=



=C2=A0

--
Nat Sakimura (=3Dnat)=

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en=

=C2=A0


________________= _______________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth



=C2=A0

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma.b= =CA=81wa.je/


________________= _______________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en=

=C2= =A0

_______________________________________________=

OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth<=
/pre>

=C2=A0

=C2=A0

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


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



=C2=A0
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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



=C2=A0
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
= 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

=C2=A0

=C2=A0

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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--089e01183046c9d66604feef9a86-- From nobody Thu Jul 24 06:08:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B1E1A011C for ; Thu, 24 Jul 2014 06:08:38 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diOXadchbYVX for ; Thu, 24 Jul 2014 06:08:27 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03C21A0299 for ; Thu, 24 Jul 2014 06:08:25 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB312.namprd03.prod.outlook.com (10.141.48.28) with Microsoft SMTP Server (TLS) id 15.0.995.11; Thu, 24 Jul 2014 13:08:22 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0995.011; Thu, 24 Jul 2014 13:08:22 +0000 From: Anthony Nadalin To: Nat Sakimura , John Bradley Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpdsDt+c24NfaK06ekEi1OvV9MZutFmeAgABuQQCAACfBgIAABwoAgAAFHwCAACJ8AIAABDOAgAAAxwCAAASJAIAAAz+AgAAE4ACAAAGWgIAAEq+AgAAJNoCAAAOsAIAAAq8AgAAGTgCAAA3vkIABBUgAgAAJpGA= Date: Thu, 24 Jul 2014 13:08:22 +0000 Message-ID: <2a9c32ab66ce4d86a38717a028d2d265@BLUPR03MB309.namprd03.prod.outlook.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:160:bd80:f316:8c8:bc9] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(377424004)(51704005)(377454003)(199002)(189002)(24454002)(106116001)(77982001)(79102001)(81542001)(81342001)(92566001)(19300405004)(93886003)(76576001)(19625215002)(107046002)(50986999)(105586002)(83072002)(54356999)(99286002)(31966008)(101416001)(561944003)(85306003)(106356001)(74502001)(76176999)(76482001)(85852003)(15202345003)(99396002)(74662001)(95666004)(83322001)(74316001)(15975445006)(20776003)(551544002)(19580405001)(33646002)(15395725005)(19617315012)(86362001)(16236675004)(19609705001)(64706001)(19580395003)(86612001)(46102001)(2656002)(4396001)(21056001)(80022001)(87936001)(108616002)(42262001)(24736002)(3826002)(559001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB312; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_2a9c32ab66ce4d86a38717a028d2d265BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/a1t-cQP7bD8S5-H2mCdOwo9XMrk Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 13:08:38 -0000 --_000_2a9c32ab66ce4d86a38717a028d2d265BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aWYgd2UgdGFrZSBJYW7igJlzIG5vbiB0ZWNobmljYWwgIGFkdmljZSB0aGVuIG1vc3Qgb2YgdGhl IHdvcmsgaW4gT2F1dGggc2hvdWxkIGJlIHB1dCBkb3duLg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOYXQgU2FraW11cmENClNlbnQ6 IFRodXJzZGF5LCBKdWx5IDI0LCAyMDE0IDU6MjkgQU0NClRvOiBKb2huIEJyYWRsZXkNCkNjOiBv YXV0aEBpZXRmLm9yZyBsaXN0DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0DQoNCkFu ZCBoZXJlIGlzIGEgcXVvdGUgZnJvbSBJYW4ncyBibG9nLg0KDQpBbmQgYWx0aG91Z2ggdGhlIGF1 dGhlbnRpY2F0aW9uIHdoZWVsIGlzIHJvdW5kLCB0aGF0IGRvZXNu4oCZdCBtZWFuIGl0IGlzbuKA mXQgd2l0aG91dCBpdHMgbHVtcHMuIEZpcnN0LCB3ZSBkbyBzZWUgc29tZSByZWludmVudGluZyB0 aGUgd2hlZWwganVzdCB0byByZWludmVudCB0aGUgd2hlZWwuIE9BdXRoIEE0QyBpcyBzaW1wbHkg bm90IGEgZnJ1aXRmdWwgYWN0aXZpdHkgYW5kIHNob3VsZCBiZSBwdXQgZG93bi4NCg0KKFNvdXJj ZSkgaHR0cDovL3d3dy50dWVzZGF5bmlnaHQub3JnLzIwMTQvMDcvMjMvZG8td2UtaGF2ZS1hLXJv dW5kLXdoZWVsLXlldC1tdXNpbmdzLW9uLWlkZW50aXR5LXN0YW5kYXJkcy1wYXJ0LTEuaHRtbA0K DQoyMDE0LTA3LTIzIDE2OjUzIEdNVC0wNDowMCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIu Y29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+Og0KSSB0aG91Z2h0IEkgZGlkIHBvc3QgdGhp cyB0byB0aGUgbGlzdC4NCg0KSSBndWVzcyBJIGhpdCB0aGUgd3JvbmcgcmVwbHkgb24gbXkgcGhv bmUuDQoNCkpvaG4gQi4NClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gSnVsIDIzLCAyMDE0LCBh dCA0OjUwIFBNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQ+IHdyb3RlOg0KDQp3ZSBhcmUgdHdvLCBhdCBsZWFzdCA6LSkNCg0KV2h5IGRpZG4n dCB5b3UgcG9zdCB0aGlzIG9uIHRoZSBsaXN0Pw0KDQpXaGVuIHdpbGwgYmUgYmUgYXJyaXZpbmc/ DQoNCkFtIDIzLjA3LjIwMTQgMTY6MzksIHNjaHJpZWIgSm9obiBCcmFkbGV5Og0KSWFuIEdsYXpl ciBtZW50aW9uZWQgdGhpcyBpbiBoaXMga2V5bm90ZSBhdCBDSVMgeWVzdGVyZGF5Lg0KDQpIaXMg YWR2aWNlIHdhcyBwbGVhc2Ugc3RvcCwgIHdlIGFyZSBjcmVhdGluZyBjb25mdXNpb24gYW5kIHVu Y2VydGFpbnR5Lg0KDQpXZSBhcmUgYmVjb21pbmcgb3VyIG93biB3b3J0IGVuZW15LiAoIG15IHZp ZXcgdGhvdWdoIElhbiBtYXkgc2hhcmUgaXQpDQoNClJldHVybmluZyBqdXN0IGFuIGlkXyB0b2tl biBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCBoYXMgbGl0dGxlIHJlYWwgdmFsdWUuDQoNClNvbWV0 aGluZyByZWFsbHkgdXNlZnVsIHRvIGRvIHdvdWxkIGJlIHNvcnRpbmcgb3V0IGNoYW5uZWxfaWQg c28gd2UgY2FuIGRvIFBvUCBmb3IgaWQgdG9rZW5zIHRvIG1ha2UgdGhlbSBhbmQgb3RoZXIgY29v a2llcyBzZWN1cmUgaW4gdGhlIGZyb250IGNoYW5uZWwuICAgSSB0aGluayB0aGF0IGlzIGEgYmV0 dGVyIHVzZSBvZiB0aW1lLg0KDQpJIG1heSBiZSBpbiB0aGUgbWlub3JpdHkgb3BpbmlvbiBvbiB0 aGF0LCAgaXQgd29uJ3QgYmUgdGhlIGZpcnN0IHRpbWUuDQoNCg0KSm9obiBCLg0KU2VudCBmcm9t IG15IGlQaG9uZQ0KDQpPbiBKdWwgMjMsIDIwMTQsIGF0IDQ6MDQgUE0sIFRvcnN0ZW4gTG9kZGVy c3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldD4+IHdyb3RlOg0KWW91IGFyZSByaWdodCBmcm9tIGEgdGhlb3JldGljYWwgcGVyc3BlY3Rp dmUuIFByYWN0aWNhbGx5IHRoaXMgd2FzIGNhdXNlZCBieSBlZGl0b3JpYWwgZGVjaXNpb25zIGR1 cmluZyB0aGUgY3JlYXRpb24gb2YgdGhlIFJGQy4gQXMgZmFyIGFzIEkgcmVtZW1iZXIsIHRoZXJl IHdhcyBhIGRlZmluaXRpb24gb2YgdGhlIChvbmUpIHRva2VuIGVuZHBvaW50IHJlc3BvbnNlIGlu IGVhcmx5IHZlcnNpb25zLiBObyBvbmUgZXZlcnkgY29uc2lkZXJlZCB0byBOT1QgcmVzcG9uZCB3 aXRoIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludC4gU28gb25lIG1pZ2h0 IGNhbGwgaXQgYW4gaW1wbGljaXQgYXNzdW1wdGlvbi4NCg0KSSdtIHdvcnJpZWQgdGhhdCBwZW9w bGUgZ2V0IHRvdGFsbHkgY29uZnVzZWQgaWYgYW4gZXhjZXB0aW9uIGlzIGludHJvZHVjZWQgbm93 IGdpdmVuIHRoZSBicm9hZCBhZG9wdGlvbiBvZiBPQXV0aCBiYXNlZCBvbiB0aGlzIGFzc3VtcHRp b24uDQoNCnJlZ2FyZHMsDQpUb3JzdGVuLg0KDQpBbSAyMy4wNy4yMDE0IHVtIDE1OjQxIHNjaHJp ZWIgVGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPG1haWx0bzp0LmJyb3llckBnbWFp bC5jb20+PjoNCg0KSXMgaXQgc2FpZCBhbnl3aGVyZSB0aGF0IEFMTCBncmFudCB0eXBlcyBNVVNU IHVzZSBTZWN0aW9uIDUuMSByZXNwb25zZXM/IEVhY2ggZ3JhbnQgdHlwZSByZWZlcmVuY2VzIFNl Y3Rpb24gNS4xLCBhbmQgImFjY2VzcyB0b2tlbiByZXF1ZXN0IiBpcyBvbmx5IGRlZmluZWQgaW4g dGhlIGNvbnRleHQgb2YgdGhlIGRlZmluZWQgZ3JhbnQgdHlwZXMuIFNlY3Rpb24gMi4yIGRvZXNu J3QgdGFsayBhYm91dCB0aGUgcmVxdWVzdCBvciByZXNwb25zZSBmb3JtYXQuDQpMZSAyMyBqdWls LiAyMDE0IDIxOjMyLCAiTmF0IFNha2ltdXJhIiA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpz YWtpbXVyYUBnbWFpbC5jb20+PiBhIMOpY3JpdCA6DQpJcyBpdD8gQXBhcnQgZnJvbSB0aGUgaW1w bGljaXQgZ3JhbnQgdGhhdCBkb2VzIG5vdCB1c2UgdG9rZW4gZW5kcG9pbnQsIGFsbCBvdGhlciBn cmFudCByZWZlcmVuY2VzIHNlY3Rpb24gNS4xIGZvciB0aGUgcmVzcG9uc2UsIGkuZS4sIGFsbCBz aGFyZXMgdGhlIHNhbWUgcmVzcG9uc2UuDQoNCjIwMTQtMDctMjMgMTU6MTggR01ULTA0OjAwIFRo b21hcyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21haWwuY29t Pj46DQoNCkkgaGFkbid0IHJlYWxpemVkIHRoZSBKU09OIHJlc3BvbnNlIHRoYXQgcmVxdWlyZXMg dGhlIGFjY2Vzc190b2tlbiBmaWVsZCBpcyBkZWZpbmVkIHBlciBncmFudF90eXBlLCBzbyBJJ2Qg YmUgT0sgdG8gImV4dGVuZCB0aGUgc2VtYW50aWNzIiBhcyBpbiB0aGUgY3VycmVudCBkcmFmdC4N ClRoYXQgd2FzIGFjdHVhbGx5IG15IG1haW4gY29uY2VybjogdGhhdCB0aGUgdG9rZW4gZW5kcG9p bnQgbWFuZGF0ZXMgYWNjZXNzX3Rva2VuOyBidXQgaXRzIGFjdHVhbGx5IG5vdCB0aGUgY2FzZS4N CkxlIDIzIGp1aWwuIDIwMTQgMjA6NDYsICJOYXQgU2FraW11cmEiIDxzYWtpbXVyYUBnbWFpbC5j b208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IGEgw6ljcml0IDoNCg0KSSBhZ3JlZSB3aXRo IEpvaG4gdGhhdCBvdmVybG9hZGluZyByZXNwb25zZV90eXBlIEAgYXV0aHogZW5kcG9pbnQgaXMg YSBiYWQgaWRlYS4gSXQgY29tcGxldGVseSBjaGFuZ2VzIHRoZSBzZW1hbnRpY3Mgb2YgdGhpcyBw YXJhbWV0ZXIuIE5PVEU6IHdoYXQgSSB3YXMgcHJvcG9zaW5nIHdhcyBub3QgdGhpcyBwYXJhbWV0 ZXIsIGJ1dCBhIG5ldyBwYXJhbWV0ZXIgcmVzcG9uc2VfdHlwZSBAIHRva2VuIGVuZHBvaW50Lg0K DQpJIGFsc28gdGhpbmsgb3ZlcmxvYWRpbmcgZ3JhbnRfdHlwZSBpcyBhIGJhZCBpZGVhIHNpbmNl IGl0IGNoYW5nZXMgaXRzIHNlbWFudGljcy4gSSBxdW90ZSB0aGUgZGVmaW5pdGlvbiBoZXJlIGFn YWluOg0KDQpncmFudA0KICAgIGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZSBv d25lcidzIGF1dGhvcml6YXRpb24NCg0KZ3JhbnRfdHlwZQ0KdHlwZSBvZiBncmFudCBzZW50IHRv IHRoZSB0b2tlbiBlbmRwb2ludCB0byBvYnRhaW4gdGhlIGFjY2VzcyB0b2tlbg0KDQpJdCBpcyBu b3QgYWJvdXQgY29udHJvbGxpbmcgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRoZSB0b2tl biBlbmRwb2ludCwgYnV0IHRoZSBoaW50IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBkZXNjcmliaW5n IHRoZSB0eXBlIG9mIGNyZWRlbnRpYWwgdGhlIGVuZHBvaW50IGhhcyByZWNlaXZlZC4gSXQgc2Vl bXMgdGhlICJjb250cm9sIG9mIHdoYXQgaXMgYmVpbmcgcmV0dXJuZWQgZnJvbSB0b2tlbiBlbmRw b2ludCIgIGlzIGp1c3QgYSBzaWRlIGVmZmVjdC4NCg0KSSBhbSBzb21ld2hhdCBhbWJpdmFsZW50 WzFdIGluIGNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgdG9rZW4gZW5kcG9pbnQsIGJ1dCBpbiBh cyBtdWNoIGFzICJ0ZXh0IGlzIHRoZSBraW5nIiBmb3IgYSBzcGVjLiwgd2UgcHJvYmFibHkgc2hv dWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBpdCBhcyBUb3JzdGVuIHBvaW50cyBvdXQu IElmIGl0IGlzIG9rIHRvIGNoYW5nZSB0aGlzIHNlbWFudGljcywgSSBiZWxpZXZlIGRlZmluaW5n IGEgbmV3IHBhcmFtZXRlciB0byB0aGlzIGVuZHBvaW50IHRvIGNvbnRyb2wgdGhlIHJlc3BvbnNl IHdvdWxkIGJlIHRoZSBiZXN0IHdheSB0byBnby4gVGhpcyBpcyB3aGF0IEkgaGF2ZSBkZXNjcmli ZWQgcHJldmlvdXNseS4NCg0KRGVmaW5pbmcgYSBuZXcgZW5kcG9pbnQgdG8gc2VuZCBjb2RlIHRv IGdldCBJRCBUb2tlbiBhbmQgZm9yYmlkZGluZyB0aGUgdXNlIG9mIGl0IGFnYWluc3QgdG9rZW4g ZW5kcG9pbnQgd291bGQgbm90IGNoYW5nZSB0aGUgc2VtYW50aWNzIG9mIGFueSBleGlzdGluZyBw YXJhbWV0ZXIgb3IgZW5kcG9pbnQsIHdoaWNoIGlzIGdvb2QuIEhvd2V2ZXIsIEkgZG91YnQgaWYg aXQgaXMgbm90IHdvcnRoIGRvaW5nLiBXaGF0J3MgdGhlIHBvaW50IG9mIGF2b2lkaW5nIGFjY2Vz cyB0b2tlbiBzY29wZWQgdG8gVXNlckluZm8gZW5kcG9pbnQgYWZ0ZXIgYWxsPyBEZWZpbmluZyBh IG5ldyBlbmRwb2ludCBmb3IganVzdCBhdm9pZGluZyB0aGUgYWNjZXNzIHRva2VuIGZvciB1c2Vy aW5mbyBlbmRwb2ludCBzZWVtcyB3YXkgdG9vIG11Y2ggdGhlIGhlYXZ5IHdhaXQgd2F5IGFuZCBp dCBicmVha3MgaW50ZXJvcGVyYWJpbGl5OiBpdCBkZWZlYXRzIHRoZSBwdXJwb3NlIG9mIHN0YW5k YXJkaXphdGlvbi4NCg0KSSBoYXZlIHN0YXJ0ZWQgZmVlbGluZyB0aGF0IG5vIGNoYW5nZSBpcyB0 aGUgYmVzdCB3YXkgb3V0Lg0KDQpOYXQNCg0KWzFdICBJZiBpbnN0ZWFkIG9mIHNheWluZyAiVG9r ZW4gZW5kcG9pbnQgLSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gZXhjaGFuZ2UgYW4gYXV0aG9yaXph dGlvbiBncmFudCBmb3IgYW4gYWNjZXNzIHRva2VuLCB0eXBpY2FsbHkgd2l0aCBjbGllbnQgYXV0 aGVudGljYXRpb24iLCBpdCB3ZXJlIHNheWluZyAiVG9rZW4gZW5kcG9pbnQgLSB1c2VkIGJ5IHRo ZSBjbGllbnQgdG8gZXhjaGFuZ2UgYW4gYXV0aG9yaXphdGlvbiBncmFudCBmb3IgdG9rZW5zLCB0 eXBpY2FsbHkgd2l0aCBjbGllbnQgYXV0aGVudGljYXRpb24iLCB0aGVuIGl0IHdvdWxkIGhhdmUg YmVlbiBPSy4gSXQgaXMgYW4gZXhwYW5zaW9uIG9mIHRoZSBjYXBhYmlsaXR5IHJhdGhlciB0aGFu IGNoYW5naW5nIHRoZSBzZW1hbnRpY3MuDQoNCg0KMjAxNC0wNy0yMyAxMzozOSBHTVQtMDQ6MDAg TWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20+PjoNCllvdSBuZWVkIHRoZSBhbHRlcm5hdGl2ZSByZXNwb25zZV90 eXBlIHZhbHVlICgiY29kZV9mb3JfaWRfdG9rZW4iIGluIHRoZSBBNEMgZHJhZnQpIHRvIHRlbGwg dGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRvIHJldHVybiBhIGNvZGUgdG8gYmUgdXNlZCB3aXRo IHRoZSBuZXcgZ3JhbnQgdHlwZSwgcmF0aGVyIHRoYW4gb25lIHRvIHVzZSB3aXRoIHRoZSAiYXV0 aG9yaXphdGlvbl9jb2RlIiBncmFudCB0eXBlICh3aGljaCBpcyB3aGF0IHJlc3BvbnNlX3R5cGU9 Y29kZSBkb2VzKS4NCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxl eQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDEwOjMzIEFNDQpUbzogdG9yc3RlbkBs b2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KDQpDYzogb2F1 dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1X R10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXIt YTRjLTA1LnR4dA0KDQoNCg0KSWYgd2UgdXNlIHRoZSB0b2tlbiBlbmRwb2ludCB0aGVuIGEgbmV3 IGdyYW50X3R5cGUgaXMgdGhlIGJlc3Qgd2F5Lg0KDQpJdCBzb3J0IG9mIG92ZXJsb2FkcyBjb2Rl LCBidXQgdGhhdCBpcyBiZXR0ZXIgdGhhbiBtZXNzaW5nIHdpdGggcmVzcG9uc2VfdHlwZSBmb3Ig dGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgdG8gY2hhbmdlIHRoZSByZXNwb25zZSBmcm9tIHRo ZSB0b2tlbl9lbmRwb2ludC4gIFRoYXQgaXMgaW4gbXkgb3BpbmlvbiBhIGNoYW1waW9uIGJhZCBp ZGVhLg0KDQpJbiBkaXNjdXNzaW9ucyBkZXZlbG9waW5nIENvbm5lY3Qgd2UgZGVjaWRlZCBub3Qg dG8gb3BlbiB0aGlzIGNhbiBvZiB3b3JtcyBiZWNhdXNlIG5vIGdvb2Qgd291bGQgY29tZSBvZiBp dC4NCg0KVGhlIHRva2VuX2VuZHBvaW50IHJldHVybnMgYSBhY2Nlc3MgdG9rZW4uICBOb3RoaW5n IHJlcXVpcmVzIHNjb3BlIHRvIGJlIGFzc29jaWF0ZXMgd2l0aCB0aGUgdG9rZW4uDQoNClRoYXQg aXMgdGhlIGJlc3Qgc29sdXRpb24uICBObyBjaGFuZ2UgcmVxdWlyZWQuICBCZXR0ZXIgaW50ZXJv cGVyYWJpbGl0eSBpbiBteSBvcGluaW9uLg0KDQpTdGlsbCBvbiBteSB3YXkgdG8gVE8sIGdldHRp bmcgaW4gbGF0ZXIgdG9kYXkuDQoNCkpvaG4gQi4NCg0KDQoNClNlbnQgZnJvbSBteSBpUGhvbmUN Cg0KT24gSnVsIDIzLCAyMDE0LCBhdCAxMjoxNSBQTSwgdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8 bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB3cm90ZToNCg0KVGhlICJyZXNwb25zZSB0 eXBlIiBvZiB0aGUgdG9rZW4gZW5kcG9pbnQgaXMgY29udHJvbGxlZCBieSB0aGUgdmFsdWUgb2Yg dGhlIHBhcmFtZXRlciAiZ3JhbnRfdHlwZSIuIFNvIHRoZXJlIGlzIG5vIG5lZWQgdG8gaW50cm9k dWNlIGEgbmV3IHBhcmFtZXRlci4NCg0Kd3J0IHRvIGEgcG90ZW50aWFsICJub19hY2Nlc3NfdG9r ZW4iIGdyYW50IHR5cGUuIEkgZG8gbm90IGNvbnNpZGVyIHRoaXMgYSBnb29kIGlkZWEgYXMgaXQg Y2hhbmdlcyB0aGUgc2VtYW50aWNzIG9mIHRoZSB0b2tlbiBlbmRwb2ludCAoYXMgYWxyZWFkeSBw b2ludGVkIG91dCBieSBUaG9tYXMpLiBUaGlzIGVuZHBvaW50IEFMV0FZUyByZXNwb25kcyB3aXRo IGFuIGFjY2VzcyB0b2tlbiB0byBhbnkgZ3JhbnQgdHlwZS4gSSB0aGVyZWZvcmUgd291bGQgcHJl ZmVyIHRvIHVzZSBhbm90aGVyIGVuZHBvaW50IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZS4NCg0K cmVnYXJkcywNClRvcnN0ZW4uDQoNCg0KDQpBbSAyMy4wNy4yMDE0IDEzOjA0LCBzY2hyaWViIE5h dCBTYWtpbXVyYToNCklNSE8sIGNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgInJlc3BvbnNlX3R5 cGUiIEAgYXV0aHogZW5kcG9pbnQgdGhpcyB3YXkgaXMgbm90IGEgZ29vZCB0aGluZy4NCg0KSW5z dGVhZCwgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVyICJyZXNwb25zZV90eXBlIiBAIHRva2VuIGVu ZHBvaW50LCBhcyBJIGRlc2NyaWJlZCBpbiBteSBwcmV2aW91cyBtZXNzYWdlLA0KcHJvYmFibHkg aXMgYmV0dGVyLiBBdCBsZWFzdCwgaXQgZG9lcyBub3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2Yg dGhlIHBhcmFtZXRlcnMgb2YgUkZDNjc0OS4NCg0KIE5hdA0KDQoyMDE0LTA3LTIzIDEyOjQ4IEdN VC0wNDowMCBUaG9tYXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVy QGdtYWlsLmNvbT4+Og0KTm8sIEkgbWVhbiByZXNwb25zZV90eXBlPW5vbmUgYW5kIHJlc3BvbnNl X3R5cGU9aWRfdG9rZW4gZG9uJ3QgZ2VuZXJhdGUgYSBjb2RlIG9yIGFjY2VzcyB0b2tlbiBzbyB5 b3UgZG9uJ3QgdXNlIHRoZSBUb2tlbiBFbmRwb2ludCAod2hpY2ggaXMgbm90IHRoZSBzYW1lIGFz IHRoZSBBdXRoZW50aWNhdGlvbiBFbmRwb2ludCBCVFcpLg0KV2l0aCByZXNwb25zZV90eXBlPWNv ZGVfZm9yX2lkX3Rva2VuLCB5b3UgZ2V0IGEgY29kZSBhbmQgZXhjaGFuZ2UgaXQgZm9yIGFuIGlk X3Rva2VuIG9ubHksIHJhdGhlciB0aGFuIGFuIGFjY2Vzc190b2tlbiwgc28geW91J3JlIGNoYW5n aW5nIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIFRva2VuIEVuZHBvaW50Lg0KDQpJJ20gbm90IHNheWlu ZyBpdCdzIGEgYmFkIHRoaW5nLCBqdXN0IHRoYXQgeW91IGNhbid0IHJlYWxseSBjb21wYXJlIG5v bmUgYW5kIGlkX3Rva2VuIHdpdGggY29kZV9mb3JfaWRfdG9rZW4uDQoNCk9uIFdlZCwgSnVsIDIz LCAyMDE0IGF0IDY6NDUgUE0sIFJpY2hlciwgSnVzdGluIFAuIDxqcmljaGVyQG1pdHJlLm9yZzxt YWlsdG86anJpY2hlckBtaXRyZS5vcmc+PiB3cm90ZToNCkl0J3Mgb25seSAibm90IHVzaW5nIHRo ZSB0b2tlbiBlbmRwb2ludCIgYmVjYXVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgY29weS1wYXN0ZWQg YW5kIHJlbmFtZWQgdGhlIGF1dGhlbnRpY2F0aW9uIGVuZHBvaW50Lg0KDQogLS0gSnVzdGluDQoN Ck9uIEp1bCAyMywgMjAxNCwgYXQgOTozMCBBTSwgVGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21h aWwuY29tPG1haWx0bzp0LmJyb3llckBnbWFpbC5jb20+PiB3cm90ZToNCg0KRXhjZXB0IHRoYXQg dGhlc2UgYXJlIGFib3V0IG5vdCB1c2luZyB0aGUgVG9rZW4gRW5kcG9pbnQgYXQgYWxsLCB3aGVy ZWFzIHRoZSBjdXJyZW50IHByb3Bvc2FsIGlzIGFib3V0IHRoZSBUb2tlbiBFbmRwb2ludCBub3Qg cmV0dXJuaW5nIGFuIGFjY2Vzc190b2tlbiBmaWVsZCBpbiB0aGUgSlNPTi4NCg0KT24gV2VkLCBK dWwgMjMsIDIwMTQgYXQgNDoyNiBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRoZSBy ZXNwb25zZV90eXBlICJub25lIiBpcyBhbHJlYWR5IHVzZWQgaW4gcHJhY3RpY2UsIHdoaWNoIHJl dHVybnMgbm8gYWNjZXNzIHRva2VuLiAgSXQgd2FzIGFjY2VwdGVkIGJ5IHRoZSBkZXNpZ25hdGVk IGV4cGVydHMgYW5kIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkEgT0F1dGggQXV0aG9yaXphdGlvbiBF bmRwb2ludCBSZXNwb25zZSBUeXBlcyByZWdpc3RyeSBhdCBodHRwOi8vd3d3LmlhbmEub3JnL2Fz c2lnbm1lbnRzL29hdXRoLXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54bWwjZW5kcG9pbnQu ICBUaGUgcmVnaXN0ZXJlZCAiaWRfdG9rZW4iIHJlc3BvbnNlIHR5cGUgYWxzbyByZXR1cm5zIG5v IGFjY2VzcyB0b2tlbi4NCg0KU28gSSB0aGluayB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciByZXNw b25zZSB0eXBlcyB0aGF0IHJlc3VsdCBpbiBubyBhY2Nlc3MgdG9rZW4gYmVpbmcgcmV0dXJuZWQg YXJlIGFjY2VwdGFibGUgd2l0aGluIE9BdXRoIDIuMCBpcyBhbHJlYWR5IHNldHRsZWQsIGFzIGEg cHJhY3RpY2FsIG1hdHRlci4gIExvdHMgb2YgT0F1dGggaW1wbGVtZW50YXRpb25zIGFyZSBhbHJl YWR5IHVzaW5nIHN1Y2ggcmVzcG9uc2UgdHlwZXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1 dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIz LCAyMDE0IDc6MDkgQU0NClRvOiBOYXQgU2FraW11cmENCkNjOiA8b2F1dGhAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQNCg0K WWVzLiBUaGlzIGlzIHdoeSBpdCBoYXMgdG8gYmUgZGlzY3Vzc2VkIGluIHRoZSBJRVRGLg0KDQpQ aGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5p bmRlcGVuZGVudGlkLmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb20+DQoNCg0KDQpPbiBKdWwgMjMsIDIwMTQsIGF0IDk6NDMgQU0sIE5hdCBTYWtp bXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90 ZToNCg0KUmVhZGluZyBiYWNrIHRoZSBSRkM2NzQ5LCBJIGFtIG5vdCBzdXJlIGlmIHRoZXJlIGlz IGEgZ29vZCB3YXkgb2Ygc3VwcHJlc3NpbmcgYWNjZXNzIHRva2VuIGZyb20gdGhlIHJlc3BvbnNl IGFuZCBzdGlsbCBiZSBPQXV0aC4gSXQgd2lsbCBicmVhayB3aG9sZSBidW5jaCBvZiBpbXBsaWNp dCBkZWZpbml0aW9ucyBsaWtlOg0KDQphdXRob3JpemF0aW9uIHNlcnZlcg0KICAgICAgVGhlIHNl cnZlciBpc3N1aW5nIGFjY2VzcyB0b2tlbnMgdG8gdGhlIGNsaWVudCBhZnRlciBzdWNjZXNzZnVs bHkNCiAgICAgIGF1dGhlbnRpY2F0aW5nIHRoZSByZXNvdXJjZSBvd25lciBhbmQgb2J0YWluaW5n IGF1dGhvcml6YXRpb24uDQoNCkFmdGVyIGFsbCwgT0F1dGggaXMgYWxsIGFib3V0IGlzc3Vpbmcg YWNjZXNzIHRva2Vucy4NCg0KQWxzbywgSSB0YWtlIGJhY2sgbXkgc3RhdGVtZW50IG9uIHRoZSBn cmFudCB0eXBlIGluIG15IHByZXZpb3VzIG1haWwuDQoNClRoZSBkZWZpbml0aW9uIG9mIGdyYW50 IGFuZCBncmFudF90eXBlIGFyZSByZXNwZWN0aXZlbHk6DQoNCmdyYW50DQogICAgY3JlZGVudGlh bCByZXByZXNlbnRpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbg0KDQpncmFu dF90eXBlDQogICAgKHN0cmluZyByZXByZXNlbnRpbmcgdGhlKSB0eXBlIG9mIGdyYW50IHNlbnQg dG8gdGhlIHRva2VuIGVuZHBvaW50IHRvIG9idGFpbiB0aGUgYWNjZXNzIHRva2VuDQoNClRodXMs IHRoZSBncmFudCBzZW50IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBpbiB0aGlzIGNhc2UgaXMgc3Rp bGwgJ2NvZGUnLg0KDQpSZXNwb25zZSB0eXBlIG9uIHRoZSBvdGhlciBoYW5kIGlzIG5vdCBzbyB3 ZWxsIGRlZmluZWQgaW4gUkZDNjc0OSwgYnV0IGl0IHNlZW1zIGl0IGlzIHJlcHJlc2VudGluZyB3 aGF0IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRv IGV4cHJlc3Mgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50LCBwZXJo YXBzIGRlZmluaW5nIGEgbmV3IHBhcmFtZXRlciB0byB0aGUgdG9rZW4gZW5kcG9pbnQsIHdoaWNo IGlzIGEgcGFyYWxsZWwgdG8gdGhlIHJlc3BvbnNlX3R5cGUgdG8gdGhlIEF1dGhvcml6YXRpb24g RW5kcG9pbnQgc2VlbXMgdG8gYmUgYSBtb3JlIHN5bW1ldHJpYyB3YXksIHRob3VnaCBJIGFtIG5v dCBzdXJlIGF0IGFsbCBpZiB0aGF0IGlzIGdvaW5nIHRvIGJlIE9BdXRoIGFueSBtb3JlLiBPbmUg c3RyYXctbWFuIGlzIHRvIGRlZmluZSBhIG5ldyBwYXJhbWV0ZXIgY2FsbGVkIHJlc3BvbnNlX3R5 cGUgdG8gdGhlIHRva2VuIGVuZHBvaW50IHN1Y2ggYXM6DQoNCnJlc3BvbnNlX3R5cGUNCiAgICBP UFRJT05BTC4gQSBzdHJpbmcgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJv bSB0aGUgdG9rZW4gZW5kcG9pbnQuDQoNClRoZW4gZGVmaW5lIHRoZSBiZWhhdmlvciBvZiB0aGUg ZW5kcG9pbnQgYWNjb3JkaW5nIHRvIHRoZSB2YWx1ZXMgYXMgdGhlIHBhcmFsbGVsIHRvIHRoZSBt dWx0aS1yZXNwb25zZSB0eXBlIHNwZWMuDQpodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC12 Mi1tdWx0aXBsZS1yZXNwb25zZS10eXBlcy0xXzAuaHRtbA0KDQpOYXQNCg0KDQoNCg0KMjAxNC0w Ny0yMyA3OjIxIEdNVC0wNDowMCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+Og0KVGhlIGRyYWZ0IGlzIHZlcnkgY2xlYXIuDQoNClBo aWwNCg0KT24gSnVsIDIzLCAyMDE0LCBhdCAwOjQ2LCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdt YWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQpUaGUgbmV3IGdyYW50 IHR5cGUgdGhhdCBJIHdhcyB0YWxraW5nIGFib3V0IHdhcw0KImF1dGhvcml6YXRpb25fY29kZV9i dXRfZG9fbm90X3JldHVybl9hY2Nlc3Nfbm9yX3JlZnJlc2hfdG9rZW4iLCBzbyB0byBzcGVhay4N Ckl0IGRvZXMgbm90IHJldHVybiBhbnl0aGluZyBwZXIgc2UsIGJ1dCBhbiBleHRlbnNpb24gY2Fu IGRlZmluZSBzb21ldGhpbmcgb24gdG9wIG9mIGl0Lg0KDQpUaGVuLCBPSURDIGNhbiBkZWZpbmUg YSBiaW5kaW5nIHRvIGl0IHNvIHRoYXQgdGhlIGJpbmRpbmcgb25seSByZXR1cm5zIElEIFRva2Vu Lg0KVGhpcyBiaW5kaW5nIHdvcmsgc2hvdWxkIGJlIGRvbmUgaW4gT0lERi4gU2hvdWxkIHRoZXJl IGJlIHN1Y2ggYSBncmFudCB0eXBlLA0KaXQgd2lsbCBiZSBhbiBleHRyZW1lbHkgc2hvcnQgc3Bl Yy4NCg0KQXQgdGhlIHNhbWUgdGltZSwgaWYgYW55IG90aGVyIHNwZWNpZmljYXRpb24gd2FudGVk IHRvIGRlZmluZQ0Kb3RoZXIgdHlwZSBvZiB0b2tlbnMgYW5kIGhhdmUgaXQgcmV0dXJuZWQgZnJv bSB0aGUgdG9rZW4gZW5kcG9pbnQsDQppdCBjYW4gYWxzbyB1c2UgdGhpcyBncmFudCB0eXBlLg0K DQpJZiB3aGF0IHlvdSB3YW50IGlzIHRvIGRlZmluZSBhIG5ldyBncmFudCB0eXBlIHRoYXQgcmV0 dXJucyBJRCBUb2tlbiBvbmx5LA0KdGhlbiwgSSBhbSB3aXRoIEp1c3Rpbi4gU2luY2UgIm90aGVy IHJlc3BvbnNlIHRoYW4gSUQgVG9rZW4iIGlzIG9ubHkNCnRoZW9yZXRpY2FsLCB0aGlzIGlzIGEg bW9yZSBwbGF1c2libGUgd2F5IGZvcndhcmQsIEkgc3VwcG9zZS4NCg0KTmF0DQoNCjIwMTQtMDct MjIgMTQ6MzAgR01ULTA0OjAwIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86 anJpY2hlckBtaXQuZWR1Pj46DQpTbyB0aGUgZHJhZnQgd291bGQgbGl0ZXJhbGx5IHR1cm4gaW50 bzoNCg0KIlRoZSBhNGMgcmVzcG9uc2UgdHlwZSBhbmQgZ3JhbnQgdHlwZSByZXR1cm4gYW4gaWRf dG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCBubyBhY2Nlc3MgdG9rZW4uIEFsbCBw YXJhbWV0ZXJzIGFuZCB2YWx1ZXMgYXJlIGRlZmluZWQgaW4gT0lEQy4iDQoNClNlZW1zIGxpa2Ug dGhlIHBlcmZlY3QgbWluaSBleHRlbnNpb24gZHJhZnQgZm9yIE9JREYgdG8gZG8uDQoNCi0tSnVz dGluDQoNCi9zZW50IGZyb20gbXkgcGhvbmUvDQoNCk9uIEp1bCAyMiwgMjAxNCAxMDoyOSBBTSwg TmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNv bT4+IHdyb3RlOg0KPg0KPiBXaGF0IGFib3V0IGp1c3QgZGVmaW5pbmcgYSBuZXcgZ3JhbnQgdHlw ZSBpbiB0aGlzIFdHPw0KPg0KPg0KPiAyMDE0LTA3LTIyIDEyOjU2IEdNVC0wNDowMCBQaGlsIEh1 bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+Og0K Pj4NCj4+IFRoYXQgd291bGQgYmUgbmljZS4gSG93ZXZlciBvaWRjIHN0aWxsIG5lZWRzIHRoZSBu ZXcgZ3JhbnQgdHlwZSBpbiBvcmRlciB0byBpbXBsZW1lbnQgdGhlIHNhbWUgZmxvdy4NCj4+DQo+ PiBQaGlsDQo+Pg0KPj4gT24gSnVsIDIyLCAyMDE0LCBhdCAxMTozNSwgTmF0IFNha2ltdXJhIDxz YWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4N Cj4+PiArMSB0byBKdXN0aW4uDQo+Pj4NCj4+Pg0KPj4+IDIwMTQtMDctMjIgOTo1NCBHTVQtMDQ6 MDAgUmljaGVyLCBKdXN0aW4gUC4gPGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1p dHJlLm9yZz4+Og0KPj4+Pg0KPj4+PiBFcnJvcnMgbGlrZSB0aGVzZSBtYWtlIGl0IGNsZWFyIHRv IG1lIHRoYXQgaXQgd291bGQgbWFrZSBtdWNoIG1vcmUgc2Vuc2UgdG8gZGV2ZWxvcCB0aGlzIGRv Y3VtZW50IGluIHRoZSBPcGVuSUQgRm91bmRhdGlvbi4gSXQgc2hvdWxkIGJlIHNvbWV0aGluZyB0 aGF0IGRpcmVjdGx5IHJlZmVyZW5jZXMgT3BlbklEIENvbm5lY3QgQ29yZSBmb3IgYWxsIG9mIHRo ZXNlIHRlcm1zIGluc3RlYWQgb2YgcmVkZWZpbmluZyB0aGVtLiBJdCdzIGRvaW5nIGF1dGhlbnRp Y2F0aW9uLCB3aGljaCBpcyBmdW5kYW1lbnRhbGx5IHdoYXQgT3BlbklEIENvbm5lY3QgZG9lcyBv biB0b3Agb2YgT0F1dGgsIGFuZCBJIGRvbid0IHNlZSBhIGdvb2QgYXJndW1lbnQgZm9yIGRvaW5n IHRoaXMgd29yayBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAuDQo+Pj4+DQo+Pj4+ICAtLSBKdXN0aW4N Cj4+Pj4NCj4+Pj4gT24gSnVsIDIyLCAyMDE0LCBhdCA0OjMwIEFNLCBUaG9tYXMgQnJveWVyIDx0 LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+ Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gT24gTW9uLCBKdWwgMjEsIDIwMTQgYXQgMTE6 NTIgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+PiBUaGFua3Mg Zm9yIHlvdXIgcmV2aWV3LCBUaG9tYXMuICBUaGUgInByb21wdD1jb25zZW50IiBkZWZpbml0aW9u IGJlaW5nIG1pc3NpbmcgaXMgYW4gZWRpdG9yaWFsIGVycm9yLiAgSXQgc2hvdWxkIGJlOg0KPj4+ Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IGNvbnNlbnQNCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBB dXRob3JpemF0aW9uIFNlcnZlciBTSE9VTEQgcHJvbXB0IHRoZSBFbmQtVXNlciBmb3IgY29uc2Vu dCBiZWZvcmUgcmV0dXJuaW5nIGluZm9ybWF0aW9uIHRvIHRoZSBDbGllbnQuIElmIGl0IGNhbm5v dCBvYnRhaW4gY29uc2VudCwgaXQgTVVTVCByZXR1cm4gYW4gZXJyb3IsIHR5cGljYWxseSBjb25z ZW50X3JlcXVpcmVkLg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEknbGwgcGxhbiB0 byBhZGQgaXQgaW4gdGhlIG5leHQgZHJhZnQuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IEl0IGxvb2tz IGxpa2UgdGhlIGNvbnNlbnRfcmVxdWlyZWQgZXJyb3IgbmVlZHMgdG8gYmUgZGVmaW5lZCB0b28s IGFuZCB5b3UgbWlnaHQgaGF2ZSBmb3Jnb3R0ZW4gdG8gYWxzbyBpbXBvcnQgYWNjb3VudF9zZWxl Y3Rpb25fcmVxdWlyZWQgZnJvbSBPcGVuSUQgQ29ubmVjdC4NCj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+ Pg0KPj4+Pj4+DQo+Pj4+Pj4gSSBhZ3JlZSB0aGF0IHRoZXJlJ3Mgbm8gZGlmZmVyZW5jZSBiZXR3 ZWVuIGEgcmVzcG9uc2Ugd2l0aCBtdWx0aXBsZSAiYW1yIiB2YWx1ZXMgdGhhdCBpbmNsdWRlcyAi bWZhIiBhbmQgb25lIHRoYXQgZG9lc24ndC4gIFVubGVzcyBhIGNsZWFyIHVzZSBjYXNlIGZvciB3 aHkgIm1mYSIgaXMgbmVlZGVkIGNhbiBiZSBpZGVudGlmaWVkLCB3ZSBjYW4gZGVsZXRlIGl0IGlu IHRoZSBuZXh0IGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MuDQo+Pj4+Pg0KPj4+ Pj4gSG93IGFib3V0ICJwd2QiIHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IEkgc2hvdWxk IHJldHVybiAicHdkIiBpZiB0aGUgdXNlciBhdXRoZW50aWNhdGVkIHVzaW5nIGEgcGFzc3dvcmQs IGJ1dCB3aGF0ICJ0aGUgc2VydmljZSBpZiBhIGNsaWVudCBzZWNyZXQgaXMgdXNlZCIgbWVhbnMg aW4gdGhlIGRlZmluaXRpb24gZm9yIHRoZSAicHdkIiB2YWx1ZT8NCj4+Pj4+DQo+Pj4+PiAoTm90 YTogSSBrbm93IHlvdSdyZSBhdCBJRVRGLTkwLCBJJ20gcmVhZHkgdG8gd2FpdCAndGlsIHlvdSBj b21lIGJhY2sgOy0pICkNCj4+Pj4+DQo+Pj4+PiAtLQ0KPj4+Pj4gVGhvbWFzIEJyb3llcg0KPj4+ Pj4gL3TJlC5tYS5iyoF3YS5qZS88aHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvPg0K Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4gT0F1dGhA aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0NCj4+ PiBOYXQgU2FraW11cmEgKD1uYXQpDQo+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQo+ Pj4gaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQo+Pj4gQF9uYXRfZW4NCj4+Pg0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gT0F1dGggbWFp bGluZyBsaXN0DQo+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4NCj4NCj4N Cj4gLS0NCj4gTmF0IFNha2ltdXJhICg9bmF0KQ0KPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRp b24NCj4gaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQo+IEBfbmF0X2VuDQoNCg0KDQotLQ0KTmF0 IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0 LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0K Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBf bmF0X2VuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0K LS0NClRob21hcyBCcm95ZXINCi90yZQubWEuYsqBd2EuamUvPGh0dHA6Ly94bi0tbm5hLm1hLnhu LS1id2EteHhiLmplLz4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K DQoNCi0tDQpUaG9tYXMgQnJveWVyDQovdMmULm1hLmLKgXdhLmplLzxodHRwOi8veG4tLW5uYS5t YS54bi0tYndhLXh4Yi5qZS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5k YXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxp c3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0 aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZv dW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz dA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KLS0NCk5hdCBTYWtpbXVyYSAoPW5h dCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVyYS5vcmcv DQpAX25hdF9lbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0 aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hh aXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0 X2VuDQo= --_000_2a9c32ab66ce4d86a38717a028d2d265BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+aWYgd2UgdGFrZSBJYW7igJlz IG5vbiB0ZWNobmljYWwgJm5ic3A7YWR2aWNlIHRoZW4gbW9zdCBvZiB0aGUgd29yayBpbiBPYXV0 aCBzaG91bGQgYmUgcHV0IGRvd24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5OYXQgU2FraW11cmE8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMjQsIDIwMTQgNToyOSBBTTxicj4NCjxi PlRvOjwvYj4gSm9obiBCcmFkbGV5PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZyBsaXN0 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgaGVyZSBpcyBhIHF1b3RlIGZyb20gSWFuJ3Mg YmxvZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFuZCBhbHRob3VnaCB0aGUgYXV0aGVudGljYXRpb24gd2hlZWwgaXMgcm91bmQsIHRo YXQgZG9lc27igJl0IG1lYW4gaXQgaXNu4oCZdCB3aXRob3V0IGl0cyBsdW1wcy4gRmlyc3QsIHdl IGRvIHNlZSBzb21lIHJlaW52ZW50aW5nIHRoZSB3aGVlbCBqdXN0IHRvIHJlaW52ZW50IHRoZSB3 aGVlbC4gT0F1dGggQTRDIGlzIHNpbXBseSBub3QgYSBmcnVpdGZ1bCBhY3Rpdml0eSBhbmQgc2hv dWxkIGJlIHB1dCBkb3duLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihTb3VyY2UpIDxhIGhyZWY9Imh0dHA6 Ly93d3cudHVlc2RheW5pZ2h0Lm9yZy8yMDE0LzA3LzIzL2RvLXdlLWhhdmUtYS1yb3VuZC13aGVl bC15ZXQtbXVzaW5ncy1vbi1pZGVudGl0eS1zdGFuZGFyZHMtcGFydC0xLmh0bWwiPg0KaHR0cDov L3d3dy50dWVzZGF5bmlnaHQub3JnLzIwMTQvMDcvMjMvZG8td2UtaGF2ZS1hLXJvdW5kLXdoZWVs LXlldC1tdXNpbmdzLW9uLWlkZW50aXR5LXN0YW5kYXJkcy1wYXJ0LTEuaHRtbDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNC0wNy0yMyAxNjo1MyBHTVQtMDQ6MDAgSm9o biBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0i X2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aG91Z2h0IEkgZGlk IHBvc3QgdGhpcyB0byB0aGUgbGlzdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBndWVzcyBJIGhpdCB0aGUgd3JvbmcgcmVwbHkg b24gbXkgcGhvbmUuJm5ic3A7PGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLiZuYnNwOzxicj4NClNlbnQg ZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBK dWwgMjMsIDIwMTQsIGF0IDQ6NTAgUE0sIDxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cD53ZSBhcmUgdHdvLCBhdCBs ZWFzdCA6LSk8bzpwPjwvbzpwPjwvcD4NCjxwPldoeSBkaWRuJ3QgeW91IHBvc3QgdGhpcyBvbiB0 aGUgbGlzdD88bzpwPjwvbzpwPjwvcD4NCjxwPldoZW4gd2lsbCBiZSBiZSBhcnJpdmluZz88bzpw PjwvbzpwPjwvcD4NCjxwPkFtIDIzLjA3LjIwMTQgMTY6MzksIHNjaHJpZWIgSm9obiBCcmFkbGV5 OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4t bGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JYW4gR2xhemVyIG1lbnRpb25lZCB0aGlzIGluIGhpcyBr ZXlub3RlIGF0IENJUyB5ZXN0ZXJkYXkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpcyBhZHZpY2Ugd2FzIHBsZWFzZSBzdG9wLCAm bmJzcDt3ZSBhcmUgY3JlYXRpbmcgY29uZnVzaW9uIGFuZCB1bmNlcnRhaW50eS4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgYXJl IGJlY29taW5nIG91ciBvd24gd29ydCBlbmVteS4gKCBteSB2aWV3IHRob3VnaCBJYW4gbWF5IHNo YXJlIGl0KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZXR1cm5pbmcganVzdCBhbiBpZF8gdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQg aGFzIGxpdHRsZSByZWFsIHZhbHVlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21ldGhpbmcgcmVhbGx5IHVzZWZ1bCB0byBkbyB3 b3VsZCBiZSBzb3J0aW5nIG91dCBjaGFubmVsX2lkIHNvIHdlIGNhbiBkbyBQb1AgZm9yIGlkIHRv a2VucyB0byBtYWtlIHRoZW0gYW5kIG90aGVyIGNvb2tpZXMgc2VjdXJlIGluIHRoZSBmcm9udCBj aGFubmVsLiAmbmJzcDsgSSB0aGluayB0aGF0IGlzIGEgYmV0dGVyIHVzZSBvZiB0aW1lLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IG1heSBiZSBpbiB0aGUgbWlub3JpdHkgb3BpbmlvbiBvbiB0aGF0LCAmbmJzcDtpdCB3b24ndCBi ZSB0aGUgZmlyc3QgdGltZS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KSm9obiBCLiZuYnNwOzxicj4NClNlbnQgZnJvbSBteSBp UGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N Ck9uIEp1bCAyMywgMjAxNCwgYXQgNDowNCBQTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMxMDEw RkYgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+WW91IGFyZSByaWdodCBmcm9tIGEgdGhlb3JldGljYWwgcGVyc3BlY3Rp dmUuIFByYWN0aWNhbGx5IHRoaXMgd2FzIGNhdXNlZCBieSBlZGl0b3JpYWwgZGVjaXNpb25zIGR1 cmluZyB0aGUgY3JlYXRpb24gb2YgdGhlIFJGQy4gQXMgZmFyIGFzIEkgcmVtZW1iZXIsIHRoZXJl IHdhcyBhIGRlZmluaXRpb24gb2YgdGhlIChvbmUpIHRva2VuIGVuZHBvaW50IHJlc3BvbnNlIGlu IGVhcmx5IHZlcnNpb25zLiBObyBvbmUNCiBldmVyeSBjb25zaWRlcmVkIHRvIE5PVCByZXNwb25k IHdpdGggYW4gYWNjZXNzIHRva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LiBTbyBvbmUgbWln aHQgY2FsbCBpdCBhbiBpbXBsaWNpdCBhc3N1bXB0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gd29ycmllZCB0aGF0IHBlb3BsZSBn ZXQgdG90YWxseSBjb25mdXNlZCBpZiBhbiBleGNlcHRpb24gaXMgaW50cm9kdWNlZCBub3cgZ2l2 ZW4gdGhlIGJyb2FkIGFkb3B0aW9uIG9mIE9BdXRoIGJhc2VkIG9uIHRoaXMgYXNzdW1wdGlvbi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVn YXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRvcnN0ZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkFtIDIzLjA3LjIwMTQgdW0g MTU6NDEgc2NocmllYiBUaG9tYXMgQnJveWVyICZsdDs8YSBocmVmPSJtYWlsdG86dC5icm95ZXJA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDs6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFy Z2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHA+SXMgaXQgc2FpZCBhbnl3aGVyZSB0aGF0IEFMTCBncmFudCB0eXBlcyBNVVNUIHVz ZSBTZWN0aW9uIDUuMSByZXNwb25zZXM/IEVhY2ggZ3JhbnQgdHlwZSByZWZlcmVuY2VzIFNlY3Rp b24gNS4xLCBhbmQgJnF1b3Q7YWNjZXNzIHRva2VuIHJlcXVlc3QmcXVvdDsgaXMgb25seSBkZWZp bmVkIGluIHRoZSBjb250ZXh0IG9mIHRoZSBkZWZpbmVkIGdyYW50IHR5cGVzLiBTZWN0aW9uIDIu MiBkb2Vzbid0IHRhbGsgYWJvdXQgdGhlIHJlcXVlc3Qgb3IgcmVzcG9uc2UNCiBmb3JtYXQuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGUgMjMganVpbC4gMjAx NCAyMTozMiwgJnF1b3Q7TmF0IFNha2ltdXJhJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2Fr aW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZn dDsgYSDDqWNyaXQgOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JcyBpdD8gQXBhcnQgZnJvbSB0aGUgaW1wbGljaXQgZ3JhbnQgdGhhdCBk b2VzIG5vdCB1c2UgdG9rZW4gZW5kcG9pbnQsIGFsbCBvdGhlciBncmFudCByZWZlcmVuY2VzIHNl Y3Rpb24gNS4xIGZvciB0aGUgcmVzcG9uc2UsIGkuZS4sIGFsbCBzaGFyZXMgdGhlIHNhbWUgcmVz cG9uc2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTQtMDctMjMgMTU6MTggR01ULTA0OjAw IFRob21hcyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj50LmJyb3llckBnbWFpbC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cD5JIGhhZG4ndCByZWFsaXplZCB0aGUgSlNPTiByZXNwb25zZSB0aGF0 IHJlcXVpcmVzIHRoZSBhY2Nlc3NfdG9rZW4gZmllbGQgaXMgZGVmaW5lZCBwZXIgZ3JhbnRfdHlw ZSwgc28gSSdkIGJlIE9LIHRvICZxdW90O2V4dGVuZCB0aGUgc2VtYW50aWNzJnF1b3Q7IGFzIGlu IHRoZSBjdXJyZW50IGRyYWZ0Ljxicj4NClRoYXQgd2FzIGFjdHVhbGx5IG15IG1haW4gY29uY2Vy bjogdGhhdCB0aGUgdG9rZW4gZW5kcG9pbnQgbWFuZGF0ZXMgYWNjZXNzX3Rva2VuOyBidXQgaXRz IGFjdHVhbGx5IG5vdCB0aGUgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5MZSAyMyBqdWlsLiAyMDE0IDIwOjQ2LCAmcXVvdDtOYXQgU2FraW11cmEmcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyBhIMOpY3JpdCA6DQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVl IHdpdGggSm9obiB0aGF0IG92ZXJsb2FkaW5nIHJlc3BvbnNlX3R5cGUgQCBhdXRoeiBlbmRwb2lu dCBpcyBhIGJhZCBpZGVhLiBJdCBjb21wbGV0ZWx5IGNoYW5nZXMgdGhlIHNlbWFudGljcyBvZiB0 aGlzIHBhcmFtZXRlci4gTk9URTogd2hhdCBJIHdhcyBwcm9wb3Npbmcgd2FzIG5vdCB0aGlzIHBh cmFtZXRlciwgYnV0IGEgbmV3IHBhcmFtZXRlciByZXNwb25zZV90eXBlIEAgdG9rZW4gZW5kcG9p bnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgYWxzbyB0aGluayBvdmVybG9hZGluZyBncmFudF90eXBlIGlzIGEgYmFkIGlkZWEg c2luY2UgaXQgY2hhbmdlcyBpdHMgc2VtYW50aWNzLiBJIHF1b3RlIHRoZSBkZWZpbml0aW9uIGhl cmUgYWdhaW46Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5ncmFudCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBjcmVkZW50aWFsIHJlcHJl c2VudGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBhdXRob3JpemF0aW9uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmdyYW50X3R5cGU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnR5cGUgb2YgZ3Jh bnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JdCBpcyBub3QgYWJvdXQgY29udHJvbGxpbmcgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBm cm9tIHRoZSB0b2tlbiBlbmRwb2ludCwgYnV0IHRoZSBoaW50IHRvIHRoZSB0b2tlbiBlbmRwb2lu dCBkZXNjcmliaW5nIHRoZSB0eXBlIG9mIGNyZWRlbnRpYWwgdGhlIGVuZHBvaW50IGhhcyByZWNl aXZlZC4gSXQgc2VlbXMgdGhlICZxdW90O2NvbnRyb2wgb2Ygd2hhdCBpcyBiZWluZyByZXR1cm5l ZCBmcm9tIHRva2VuIGVuZHBvaW50JnF1b3Q7DQogJm5ic3A7aXMganVzdCBhIHNpZGUgZWZmZWN0 LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGFtIHNvbWV3aGF0IGFtYml2YWxlbnRbMV0gaW4gY2hhbmdpbmcgdGhlIHNlbWFudGlj cyBvZiB0b2tlbiBlbmRwb2ludCwgYnV0IGluIGFzIG11Y2ggYXMgJnF1b3Q7dGV4dCBpcyB0aGUg a2luZyZxdW90OyBmb3IgYSBzcGVjLiwgd2UgcHJvYmFibHkgc2hvdWxkIG5vdCBjaGFuZ2UgdGhl IHNlbWFudGljcyBvZiBpdCBhcyBUb3JzdGVuIHBvaW50cyBvdXQuIElmIGl0IGlzIG9rIHRvIGNo YW5nZSB0aGlzIHNlbWFudGljcywgSQ0KIGJlbGlldmUgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVy IHRvIHRoaXMgZW5kcG9pbnQgdG8gY29udHJvbCB0aGUgcmVzcG9uc2Ugd291bGQgYmUgdGhlIGJl c3Qgd2F5IHRvIGdvLiBUaGlzIGlzIHdoYXQgSSBoYXZlIGRlc2NyaWJlZCBwcmV2aW91c2x5LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5EZWZpbmluZyBhIG5ldyBlbmRwb2ludCB0byBzZW5kIGNvZGUgdG8gZ2V0IElEIFRva2VuIGFu ZCBmb3JiaWRkaW5nIHRoZSB1c2Ugb2YgaXQgYWdhaW5zdCB0b2tlbiBlbmRwb2ludCB3b3VsZCBu b3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgYW55IGV4aXN0aW5nIHBhcmFtZXRlciBvciBlbmRw b2ludCwgd2hpY2ggaXMgZ29vZC4gSG93ZXZlciwgSSBkb3VidCBpZiBpdCBpcyBub3Qgd29ydGgg ZG9pbmcuIFdoYXQncw0KIHRoZSBwb2ludCBvZiBhdm9pZGluZyBhY2Nlc3MgdG9rZW4gc2NvcGVk IHRvIFVzZXJJbmZvIGVuZHBvaW50IGFmdGVyIGFsbD8gRGVmaW5pbmcgYSBuZXcgZW5kcG9pbnQg Zm9yIGp1c3QgYXZvaWRpbmcgdGhlIGFjY2VzcyB0b2tlbiBmb3IgdXNlcmluZm8gZW5kcG9pbnQg c2VlbXMgd2F5IHRvbyBtdWNoIHRoZSBoZWF2eSB3YWl0IHdheSBhbmQgaXQgYnJlYWtzIGludGVy b3BlcmFiaWxpeTogaXQgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBzdGFuZGFyZGl6YXRpb24uJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgaGF2ZSBzdGFydGVkIGZlZWxpbmcgdGhhdCBubyBjaGFuZ2UgaXMgdGhlIGJlc3Qgd2F5IG91 dC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TmF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlsxXSAmbmJzcDtJZiBpbnN0ZWFkIG9mIHNheWluZyAmcXVvdDs8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlRva2VuIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvIGV4Y2hh bmdlIGFuIGF1dGhvcml6YXRpb24mbmJzcDs8L3NwYW4+Z3JhbnQgZm9yIGFuIGFjY2VzcyB0b2tl biwgdHlwaWNhbGx5IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0aW9uJnF1b3Q7LCBpdCB3ZXJlIHNh eWluZyAmcXVvdDs8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRva2VuDQogZW5kcG9pbnQgLSB1 c2VkIGJ5IHRoZSBjbGllbnQgdG8gZXhjaGFuZ2UgYW4gYXV0aG9yaXphdGlvbiZuYnNwOzwvc3Bh bj5ncmFudCBmb3IgdG9rZW5zLCB0eXBpY2FsbHkgd2l0aCBjbGllbnQgYXV0aGVudGljYXRpb24m cXVvdDssIHRoZW4gaXQgd291bGQgaGF2ZSBiZWVuIE9LLiBJdCBpcyBhbiBleHBhbnNpb24gb2Yg dGhlIGNhcGFiaWxpdHkgcmF0aGVyIHRoYW4gY2hhbmdpbmcgdGhlIHNlbWFudGljcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTQtMDctMjMgMTM6MzkgR01ULTA0OjAwIE1pa2UgSm9u ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdl dD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdSBuZWVkIHRoZSBh bHRlcm5hdGl2ZSByZXNwb25zZV90eXBlIHZhbHVlICgmcXVvdDs8L3NwYW4+Y29kZV9mb3JfaWRf dG9rZW48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JnF1b3Q7DQog aW4gdGhlIEE0QyBkcmFmdCkgdG8gdGVsbCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdG8gcmV0 dXJuIGEgY29kZSB0byBiZSB1c2VkIHdpdGggdGhlIG5ldyBncmFudCB0eXBlLCByYXRoZXIgdGhh biBvbmUgdG8gdXNlIHdpdGggdGhlICZxdW90O2F1dGhvcml6YXRpb25fY29kZSZxdW90OyBncmFu dCB0eXBlICh3aGljaCBpcyB3aGF0IHJlc3BvbnNlX3R5cGU9Y29kZSBkb2VzKS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Ry b25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L3N0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYu b3JnPC9hPl0NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBCZWhhbGYgT2YgPC9zcGFuPjwvc3Ryb25n PkpvaG4gQnJhZGxleTxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZW50Ojwvc3Bhbj48L3N0cm9u Zz4gV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDEwOjMzIEFNPGJyPg0KPHN0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPlRvOjwvc3Bhbj48L3N0cm9uZz4gPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+DQp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT48L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxzdHJvbmc+Q2M6PC9zdHJvbmc+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxzdHJvbmc+U3ViamVjdDo8 L3N0cm9uZz4gUmU6IFtPQVVUSC1XR10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHdlIHVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgdGhl biBhIG5ldyBncmFudF90eXBlIGlzIHRoZSBiZXN0IHdheS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IHNvcnQgb2Ygb3Zl cmxvYWRzIGNvZGUsIGJ1dCB0aGF0IGlzIGJldHRlciB0aGFuIG1lc3Npbmcgd2l0aCByZXNwb25z ZV90eXBlIGZvciB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB0byBjaGFuZ2UgdGhlIHJlc3Bv bnNlIGZyb20gdGhlIHRva2VuX2VuZHBvaW50LiAmbmJzcDtUaGF0IGlzIGluIG15IG9waW5pb24N CiBhIGNoYW1waW9uIGJhZCBpZGVhLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gZGlzY3Vzc2lvbnMgZGV2ZWxvcGluZyBD b25uZWN0IHdlIGRlY2lkZWQgbm90IHRvIG9wZW4gdGhpcyBjYW4gb2Ygd29ybXMgYmVjYXVzZSBu byBnb29kIHdvdWxkIGNvbWUgb2YgaXQuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHRva2VuX2VuZHBvaW50 IHJldHVybnMgYSBhY2Nlc3MgdG9rZW4uICZuYnNwO05vdGhpbmcgcmVxdWlyZXMgc2NvcGUgdG8g YmUgYXNzb2NpYXRlcyB3aXRoIHRoZSB0b2tlbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYXQgaXMgdGhlIGJlc3Qgc29s dXRpb24uICZuYnNwO05vIGNoYW5nZSByZXF1aXJlZC4gJm5ic3A7QmV0dGVyIGludGVyb3BlcmFi aWxpdHkgaW4gbXkgb3Bpbmlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlN0aWxsIG9uIG15IHdheSB0byBUTywgZ2V0dGlu ZyBpbiBsYXRlciB0b2RheS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkpvaG4gQi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxicj4NClNlbnQg ZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KT24gSnVsIDIzLCAyMDE0LCBhdCAxMjoxNSBQTSwgPGEgaHJlZj0ibWFpbHRv OnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+DQp0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldDwvYT4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw PlRoZSAmcXVvdDtyZXNwb25zZSB0eXBlJnF1b3Q7IG9mIHRoZSB0b2tlbiBlbmRwb2ludCBpcyBj b250cm9sbGVkIGJ5IHRoZSB2YWx1ZSBvZiB0aGUgcGFyYW1ldGVyICZxdW90O2dyYW50X3R5cGUm cXVvdDsuIFNvIHRoZXJlIGlzIG5vIG5lZWQgdG8gaW50cm9kdWNlIGEgbmV3IHBhcmFtZXRlci48 bzpwPjwvbzpwPjwvcD4NCjxwPndydCB0byBhIHBvdGVudGlhbCAmcXVvdDtub19hY2Nlc3NfdG9r ZW4mcXVvdDsgZ3JhbnQgdHlwZS4gSSBkbyBub3QgY29uc2lkZXIgdGhpcyBhIGdvb2QgaWRlYSBh cyBpdCBjaGFuZ2VzIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHRva2VuIGVuZHBvaW50IChhcyBhbHJl YWR5IHBvaW50ZWQgb3V0IGJ5IFRob21hcykuIFRoaXMgZW5kcG9pbnQgQUxXQVlTIHJlc3BvbmRz IHdpdGggYW4gYWNjZXNzIHRva2VuIHRvIGFueSBncmFudCB0eXBlLiBJIHRoZXJlZm9yZSB3b3Vs ZA0KIHByZWZlciB0byB1c2UgYW5vdGhlciBlbmRwb2ludCBmb3IgdGhlIGludGVuZGVkIHB1cnBv c2UuPG86cD48L286cD48L3A+DQo8cD5yZWdhcmRzLDxicj4NClRvcnN0ZW4uPG86cD48L286cD48 L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkFtIDIzLjA3LjIwMTQgMTM6MDQsIHNj aHJpZWIgTmF0IFNha2ltdXJhOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JTUhPLCBj aGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mICZxdW90O3Jlc3BvbnNlX3R5cGUmcXVvdDsgQCBhdXRo eiBlbmRwb2ludCB0aGlzIHdheSBpcyBub3QgYSBnb29kIHRoaW5nLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbnN0ZWFkLCBkZWZpbmlu ZyBhIG5ldyBwYXJhbWV0ZXIgJnF1b3Q7cmVzcG9uc2VfdHlwZSZxdW90OyBAIHRva2VuIGVuZHBv aW50LCBhcyBJIGRlc2NyaWJlZCBpbiBteSBwcmV2aW91cyBtZXNzYWdlLCZuYnNwOw0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5wcm9iYWJseSBpcyBiZXR0 ZXIuIEF0IGxlYXN0LCBpdCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiB0aGUgcGFy YW1ldGVycyBvZiBSRkM2NzQ5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7TmF0Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4yMDE0LTA3LTIzIDEyOjQ4IEdN VC0wNDowMCBUaG9tYXMgQnJveWVyICZsdDs8YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDs6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ObywgSSBtZWFuIHJlc3BvbnNl X3R5cGU9bm9uZSBhbmQgcmVzcG9uc2VfdHlwZT1pZF90b2tlbiBkb24ndCBnZW5lcmF0ZSBhIGNv ZGUgb3IgYWNjZXNzIHRva2VuIHNvIHlvdSBkb24ndCB1c2UgdGhlIFRva2VuIEVuZHBvaW50ICh3 aGljaCBpcyBub3QgdGhlIHNhbWUgYXMgdGhlIEF1dGhlbnRpY2F0aW9uIEVuZHBvaW50DQogQlRX KS4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaXRoIHJl c3BvbnNlX3R5cGU9Y29kZV9mb3JfaWRfdG9rZW4sIHlvdSBnZXQgYSBjb2RlIGFuZCBleGNoYW5n ZSBpdCBmb3IgYW4gaWRfdG9rZW4gb25seSwgcmF0aGVyIHRoYW4gYW4gYWNjZXNzX3Rva2VuLCBz byB5b3UncmUgY2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgVG9rZW4gRW5kcG9pbnQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J J20gbm90IHNheWluZyBpdCdzIGEgYmFkIHRoaW5nLCBqdXN0IHRoYXQgeW91IGNhbid0IHJlYWxs eSBjb21wYXJlIG5vbmUgYW5kIGlkX3Rva2VuIHdpdGggY29kZV9mb3JfaWRfdG9rZW4uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIFdlZCwgSnVsIDIzLCAyMDE0IGF0IDY6NDUgUE0sIFJpY2hlciwgSnVzdGluIFAuICZs dDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmlj aGVyQG1pdHJlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SXQncyBvbmx5ICZxdW90O25vdCB1c2luZyB0aGUgdG9rZW4gZW5k cG9pbnQmcXVvdDsgYmVjYXVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgY29weS1wYXN0ZWQgYW5kIHJl bmFtZWQgdGhlIGF1dGhlbnRpY2F0aW9uIGVuZHBvaW50Lg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7LS0gSnVzdGluPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIEp1bCAyMywgMjAxNCwgYXQgOTozMCBBTSwgVGhvbWFzIEJyb3llciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnQuYnJv eWVyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+RXhjZXB0IHRoYXQgdGhlc2UgYXJlIGFib3V0IG5vdCB1c2luZyB0aGUgVG9rZW4g RW5kcG9pbnQgYXQgYWxsLCB3aGVyZWFzIHRoZSBjdXJyZW50IHByb3Bvc2FsIGlzIGFib3V0IHRo ZSBUb2tlbiBFbmRwb2ludCBub3QgcmV0dXJuaW5nIGFuIGFjY2Vzc190b2tlbiBmaWVsZCBpbiB0 aGUgSlNPTi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBX ZWQsIEp1bCAyMywgMjAxNCBhdCA0OjI2IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoZSByZXNwb25zZV90eXBlICZxdW90O25vbmUmcXVvdDsgaXMgYWxy ZWFkeSB1c2VkIGluIHByYWN0aWNlLCB3aGljaCByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi4mbmJz cDsgSXQgd2FzIGFjY2VwdGVkDQogYnkgdGhlIGRlc2lnbmF0ZWQgZXhwZXJ0cyBhbmQgcmVnaXN0 ZXJlZCBpbiB0aGUgSUFOQSBPQXV0aCBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5 cGVzIHJlZ2lzdHJ5IGF0DQo8YSBocmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRz L29hdXRoLXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54bWwjZW5kcG9pbnQiIHRhcmdldD0i X2JsYW5rIj4NCmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVy cy9vYXV0aC1wYXJhbWV0ZXJzLnhtbCNlbmRwb2ludDwvYT4uJm5ic3A7IFRoZSByZWdpc3RlcmVk ICZxdW90O2lkX3Rva2VuJnF1b3Q7IHJlc3BvbnNlIHR5cGUgYWxzbyByZXR1cm5zIG5vIGFjY2Vz cyB0b2tlbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBJIHRoaW5rIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVy IHJlc3BvbnNlIHR5cGVzIHRoYXQgcmVzdWx0IGluIG5vIGFjY2VzcyB0b2tlbiBiZWluZyByZXR1 cm5lZCBhcmUNCiBhY2NlcHRhYmxlIHdpdGhpbiBPQXV0aCAyLjAgaXMgYWxyZWFkeSBzZXR0bGVk LCBhcyBhIHByYWN0aWNhbCBtYXR0ZXIuJm5ic3A7IExvdHMgb2YgT0F1dGggaW1wbGVtZW50YXRp b25zIGFyZSBhbHJlYWR5IHVzaW5nIHN1Y2ggcmVzcG9uc2UgdHlwZXMuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9B dXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxzdHJvbmc+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5PbiBCZWhhbGYgT2YgPC9zcGFuPjwvc3Ryb25nPlBoaWwgSHVudDxicj4NCjxzdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5TZW50Ojwvc3Bhbj48L3N0cm9uZz4gV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDc6 MDkgQU08YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VG86PC9zcGFuPjwvc3Ryb25nPiBOYXQgU2Fr aW11cmE8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2M6PC9zcGFuPjwvc3Ryb25nPiAmbHQ7PGEg aHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0Ojwvc3Bhbj48L3N0cm9u Zz4gUmU6IFtPQVVUSC1XR10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50 LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlllcy4gVGhpcyBpcyB3aHkgaXQgaGFz IHRvIGJlIGRpc2N1c3NlZCBpbiB0aGUgSUVURi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGhpbDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5AaW5kZXBlbmRlbnRpZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iIHRhcmdldD0i X2JsYW5rIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBo cmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1 bnRAb3JhY2xlLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEp1bCAyMywgMjAxNCwgYXQgOTo0MyBB TSwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWFkaW5nIGJhY2sgdGhlIFJGQzY3NDksIEkg YW0gbm90IHN1cmUgaWYgdGhlcmUgaXMgYSBnb29kIHdheSBvZiBzdXBwcmVzc2luZyBhY2Nlc3Mg dG9rZW4gZnJvbSB0aGUgcmVzcG9uc2UgYW5kIHN0aWxsIGJlIE9BdXRoLiBJdCB3aWxsIGJyZWFr IHdob2xlIGJ1bmNoIG9mIGltcGxpY2l0IGRlZmluaXRpb25zDQogbGlrZTombmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmF1dGhvcml6YXRpb24gc2VydmVy PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlIHNlcnZlciBpc3N1aW5nIGFjY2VzcyB0b2tl bnMgdG8gdGhlIGNsaWVudCBhZnRlciBzdWNjZXNzZnVsbHk8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyBhdXRoZW50aWNhdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIG9idGFpbmluZyBhdXRo b3JpemF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkFmdGVyIGFsbCwgT0F1dGggaXMgYWxsIGFib3V0IGlzc3VpbmcgYWNjZXNzIHRva2Vucy4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkFsc28sIEkgdGFrZSBiYWNrIG15IHN0YXRlbWVudCBvbiB0aGUgZ3JhbnQgdHlwZSBp biBteSBwcmV2aW91cyBtYWlsLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGRlZmluaXRpb24gb2YgZ3JhbnQgYW5kIGdy YW50X3R5cGUgYXJlIHJlc3BlY3RpdmVseTombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ncmFudCZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsg Jm5ic3A7IGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGF1dGhv cml6YXRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Z3JhbnRfdHlwZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsgKHN0cmluZyByZXByZXNl bnRpbmcgdGhlKSB0eXBlIG9mIGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IHRvIG9i dGFpbiB0aGUgYWNjZXNzIHRva2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRodXMsIHRoZSBncmFudCBzZW50IHRvIHRo ZSB0b2tlbiBlbmRwb2ludCBpbiB0aGlzIGNhc2UgaXMgc3RpbGwgJ2NvZGUnLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVz cG9uc2UgdHlwZSBvbiB0aGUgb3RoZXIgaGFuZCBpcyBub3Qgc28gd2VsbCBkZWZpbmVkIGluIFJG QzY3NDksIGJ1dCBpdCBzZWVtcyBpdCBpcyByZXByZXNlbnRpbmcgd2hhdCBpcyB0byBiZSByZXR1 cm5lZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBUbyBleHByZXNzIHdoYXQgaXMg dG8NCiBiZSByZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50LCBwZXJoYXBzIGRlZmluaW5nIGEg bmV3IHBhcmFtZXRlciB0byB0aGUgdG9rZW4gZW5kcG9pbnQsIHdoaWNoIGlzIGEgcGFyYWxsZWwg dG8gdGhlIHJlc3BvbnNlX3R5cGUgdG8gdGhlIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgc2VlbXMg dG8gYmUgYSBtb3JlIHN5bW1ldHJpYyB3YXksIHRob3VnaCBJIGFtIG5vdCBzdXJlIGF0IGFsbCBp ZiB0aGF0IGlzIGdvaW5nIHRvIGJlIE9BdXRoIGFueSBtb3JlLg0KIE9uZSBzdHJhdy1tYW4gaXMg dG8gZGVmaW5lIGEgbmV3IHBhcmFtZXRlciBjYWxsZWQgcmVzcG9uc2VfdHlwZSB0byB0aGUgdG9r ZW4gZW5kcG9pbnQgc3VjaCBhczombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnJlc3BvbnNlX3R5cGU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBPUFRJ T05BTC4gQSBzdHJpbmcgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0 aGUgdG9rZW4gZW5kcG9pbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlbiBkZWZpbmUgdGhlIGJl aGF2aW9yIG9mIHRoZSBlbmRwb2ludCBhY2NvcmRpbmcgdG8gdGhlIHZhbHVlcyBhcyB0aGUgcGFy YWxsZWwgdG8gdGhlIG11bHRpLXJlc3BvbnNlIHR5cGUgc3BlYy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cDov L29wZW5pZC5uZXQvc3BlY3Mvb2F1dGgtdjItbXVsdGlwbGUtcmVzcG9uc2UtdHlwZXMtMV8wLmh0 bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC12Mi1tdWx0 aXBsZS1yZXNwb25zZS10eXBlcy0xXzAuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjIwMTQtMDctMjMgNzoyMSBHTVQtMDQ6MDAgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNv bTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlRoZSBkcmFmdCBpcyB2ZXJ5IGNsZWFyLiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjoj ODg4ODg4Ij48YnI+DQo8YnI+DQpQaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEp1bCAyMywgMjAx NCwgYXQgMDo0NiwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ VGhlIG5ldyBncmFudCB0eXBlIHRoYXQgSSB3YXMgdGFsa2luZyBhYm91dCB3YXMmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZxdW90O2F1dGhvcml6 YXRpb25fY29kZV9idXRfZG9fbm90X3JldHVybl9hY2Nlc3Nfbm9yX3JlZnJlc2hfdG9rZW4mcXVv dDssIHNvIHRvIHNwZWFrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkl0IGRvZXMgbm90IHJldHVybiBhbnl0aGluZyBwZXIgc2UsIGJ1 dCBhbiBleHRlbnNpb24gY2FuIGRlZmluZSBzb21ldGhpbmcgb24gdG9wIG9mIGl0LiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ VGhlbiwgT0lEQyBjYW4gZGVmaW5lIGEgYmluZGluZyB0byBpdCBzbyB0aGF0IHRoZSBiaW5kaW5n IG9ubHkgcmV0dXJucyBJRCBUb2tlbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBiaW5kaW5nIHdvcmsgc2hvdWxkIGJlIGRv bmUgaW4gT0lERi4gU2hvdWxkIHRoZXJlIGJlIHN1Y2ggYSBncmFudCB0eXBlLCZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+aXQgd2lsbCBiZSBhbiBleHRyZW1lbHkgc2hvcnQgc3BlYy4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkF0IHRo ZSBzYW1lIHRpbWUsIGlmIGFueSBvdGhlciBzcGVjaWZpY2F0aW9uIHdhbnRlZCB0byBkZWZpbmUm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+b3RoZXIgdHlwZSBvZiB0b2tlbnMgYW5kIGhhdmUgaXQgcmV0dXJuZWQgZnJvbSB0aGUgdG9r ZW4gZW5kcG9pbnQsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPml0IGNhbiBhbHNvIHVzZSB0aGlzIGdyYW50IHR5cGUuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J ZiB3aGF0IHlvdSB3YW50IGlzIHRvIGRlZmluZSBhIG5ldyBncmFudCB0eXBlIHRoYXQgcmV0dXJu cyBJRCBUb2tlbiBvbmx5LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj50aGVuLCBJIGFtIHdpdGggSnVzdGluLiBTaW5jZSAmcXVvdDtv dGhlciByZXNwb25zZSB0aGFuIElEIFRva2VuJnF1b3Q7IGlzIG9ubHkmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGhlb3JldGljYWws IHRoaXMgaXMgYSBtb3JlIHBsYXVzaWJsZSB3YXkgZm9yd2FyZCwgSSBzdXBwb3NlLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ TmF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4y MDE0LTA3LTIyIDE0OjMwIEdNVC0wNDowMCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWls dG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZn dDs6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvIHRoZSBkcmFmdCB3 b3VsZCBsaXRlcmFsbHkgdHVybiBpbnRvOjxicj4NCjxicj4NCiZxdW90O1RoZSBhNGMgcmVzcG9u c2UgdHlwZSBhbmQgZ3JhbnQgdHlwZSByZXR1cm4gYW4gaWRfdG9rZW4gZnJvbSB0aGUgdG9rZW4g ZW5kcG9pbnQgd2l0aCBubyBhY2Nlc3MgdG9rZW4uIEFsbCBwYXJhbWV0ZXJzIGFuZCB2YWx1ZXMg YXJlIGRlZmluZWQgaW4gT0lEQy4mcXVvdDs8YnI+DQo8YnI+DQpTZWVtcyBsaWtlIHRoZSBwZXJm ZWN0IG1pbmkgZXh0ZW5zaW9uIGRyYWZ0IGZvciBPSURGIHRvIGRvLjxicj4NCjxicj4NCi0tSnVz dGluPGJyPg0KPGJyPg0KL3NlbnQgZnJvbSBteSBwaG9uZS88bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCk9uIEp1bCAyMiwgMjAxNCAxMDoyOSBBTSwg TmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxi cj4NCiZndDsgV2hhdCBhYm91dCBqdXN0IGRlZmluaW5nIGEgbmV3IGdyYW50IHR5cGUgaW4gdGhp cyBXRz88YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgMjAxNC0wNy0yMiAxMjo1NiBHTVQt MDQ6MDAgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgVGhhdCB3b3VsZCBiZSBuaWNlLiBIb3dldmVyIG9pZGMgc3RpbGwg bmVlZHMgdGhlIG5ldyBncmFudCB0eXBlIGluIG9yZGVyIHRvIGltcGxlbWVudCB0aGUgc2FtZSBm bG93LiZuYnNwOzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUGhpbDxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgT24gSnVsIDIyLCAyMDE0LCBhdCAxMTozNSwgTmF0IFNha2ltdXJhICZs dDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2Fr aW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsgJiM0MzsxIHRvIEp1c3Rpbi4mbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgMjAxNC0wNy0yMiA5OjU0IEdNVC0wNDowMCBSaWNo ZXIsIEp1c3RpbiBQLiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJn ZXQ9Il9ibGFuayI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0Ozo8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBFcnJvcnMgbGlrZSB0aGVzZSBtYWtlIGl0IGNsZWFy IHRvIG1lIHRoYXQgaXQgd291bGQgbWFrZSBtdWNoIG1vcmUgc2Vuc2UgdG8gZGV2ZWxvcCB0aGlz IGRvY3VtZW50IGluIHRoZSBPcGVuSUQgRm91bmRhdGlvbi4gSXQgc2hvdWxkIGJlIHNvbWV0aGlu ZyB0aGF0IGRpcmVjdGx5IHJlZmVyZW5jZXMgT3BlbklEIENvbm5lY3QgQ29yZSBmb3IgYWxsIG9m IHRoZXNlIHRlcm1zIGluc3RlYWQgb2YgcmVkZWZpbmluZyB0aGVtLiBJdCdzIGRvaW5nDQogYXV0 aGVudGljYXRpb24sIHdoaWNoIGlzIGZ1bmRhbWVudGFsbHkgd2hhdCBPcGVuSUQgQ29ubmVjdCBk b2VzIG9uIHRvcCBvZiBPQXV0aCwgYW5kIEkgZG9uJ3Qgc2VlIGEgZ29vZCBhcmd1bWVudCBmb3Ig ZG9pbmcgdGhpcyB3b3JrIGluIHRoaXMgd29ya2luZyBncm91cC48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDstLSBKdXN0aW48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbiBKdWwgMjIsIDIwMTQsIGF0IDQ6MzAgQU0s IFRob21hcyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj50LmJyb3llckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgT24gTW9uLCBKdWwgMjEsIDIwMTQgYXQgMTE6NTIgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhy ZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5N aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZvciB5 b3VyIHJldmlldywgVGhvbWFzLiZuYnNwOyBUaGUgJnF1b3Q7cHJvbXB0PWNvbnNlbnQmcXVvdDsg ZGVmaW5pdGlvbiBiZWluZyBtaXNzaW5nIGlzIGFuIGVkaXRvcmlhbCBlcnJvci4mbmJzcDsgSXQg c2hvdWxkIGJlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uc2VudDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgQXV0aG9yaXphdGlvbiBTZXJ2 ZXIgU0hPVUxEIHByb21wdCB0aGUgRW5kLVVzZXIgZm9yIGNvbnNlbnQgYmVmb3JlIHJldHVybmlu ZyBpbmZvcm1hdGlvbiB0byB0aGUgQ2xpZW50LiBJZiBpdCBjYW5ub3Qgb2J0YWluIGNvbnNlbnQs IGl0IE1VU1QgcmV0dXJuIGFuIGVycm9yLCB0eXBpY2FsbHkgY29uc2VudF9yZXF1aXJlZC48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Jm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEknbGwgcGxhbiB0byBhZGQgaXQgaW4gdGhlIG5leHQgZHJhZnQuPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEl0IGxvb2tzIGxpa2UgdGhlIGNvbnNlbnRfcmVxdWlyZWQgZXJyb3IgbmVl ZHMgdG8gYmUgZGVmaW5lZCB0b28sIGFuZCB5b3UgbWlnaHQgaGF2ZSBmb3Jnb3R0ZW4gdG8gYWxz byBpbXBvcnQgYWNjb3VudF9zZWxlY3Rpb25fcmVxdWlyZWQgZnJvbSBPcGVuSUQgQ29ubmVjdC48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgYWdyZWUgdGhh dCB0aGVyZSdzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJlc3BvbnNlIHdpdGggbXVsdGlwbGUg JnF1b3Q7YW1yJnF1b3Q7IHZhbHVlcyB0aGF0IGluY2x1ZGVzICZxdW90O21mYSZxdW90OyBhbmQg b25lIHRoYXQgZG9lc24ndC4mbmJzcDsgVW5sZXNzIGEgY2xlYXIgdXNlIGNhc2UgZm9yIHdoeSAm cXVvdDttZmEmcXVvdDsgaXMgbmVlZGVkIGNhbiBiZSBpZGVudGlmaWVkLCB3ZSBjYW4gZGVsZXRl IGl0IGluIHRoZSBuZXh0IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFua3MuPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIb3cgYWJvdXQg JnF1b3Q7cHdkJnF1b3Q7IHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IEkgc2hvdWxkIHJl dHVybiAmcXVvdDtwd2QmcXVvdDsgaWYgdGhlIHVzZXIgYXV0aGVudGljYXRlZCB1c2luZyBhIHBh c3N3b3JkLCBidXQgd2hhdCAmcXVvdDt0aGUgc2VydmljZSBpZiBhIGNsaWVudCBzZWNyZXQgaXMg dXNlZCZxdW90OyBtZWFucyBpbiB0aGUgZGVmaW5pdGlvbiBmb3IgdGhlICZxdW90O3B3ZCZxdW90 OyB2YWx1ZT88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IChOb3RhOiBJIGtub3cgeW91J3JlIGF0IElFVEYtOTAsIEknbSByZWFkeSB0byB3YWl0ICd0 aWwgeW91IGNvbWUgYmFjayA7LSkgKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaG9tYXMgQnJv eWVyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgL3Q8YSBocmVmPSJodHRwOi8veG4tLW5uYS5t YS54bi0tYndhLXh4Yi5qZS8iIHRhcmdldD0iX2JsYW5rIj7JlC5tYS5iyoF3YS5qZS88L2E+PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpP QXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAt LTxicj4NCiZndDsmZ3Q7Jmd0OyBOYXQgU2FraW11cmEgKD1uYXQpPGJyPg0KJmd0OyZndDsmZ3Q7 IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJo dHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2lt dXJhLm9yZy88L2E+PGJyPg0KJmd0OyZndDsmZ3Q7IEBfbmF0X2VuPGJyPg0KJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P QXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IE5hdCBTYWtpbXVy YSAoPW5hdCk8YnI+DQomZ3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsg PGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov L25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCiZndDsgQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0i YWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxi cj4NCk5hdCBTYWtpbXVyYSAoPW5hdCk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0 dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11 cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGFpcm1hbiwgT3Bl bklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRh cmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxicj4NClRob21hcyBCcm95ZXI8YnI+DQovdDxhIGhyZWY9 Imh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhiLmplLyIgdGFyZ2V0PSJfYmxhbmsiPsmULm1h LmLKgXdhLmplLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Ck9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLQ0KPGJyPg0KVGhvbWFzIEJyb3llcjxicj4NCi90PGEg aHJlZj0iaHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvIiB0YXJnZXQ9Il9ibGFuayI+ yZQubWEuYsqBd2EuamUvPC9hPiA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpP QXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxi ciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+LS0NCjxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCkgPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8 YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v bmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRo QGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+DQpOYXQgU2FraW11cmEgKD1u YXQpIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoYWlybWFu LCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3Jn LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQpAX25h dF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0tIDxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCkgPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJy Pg0KPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAx MEZGIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzEwMTBGRiAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1 dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KTmF0IFNha2ltdXJhICg9bmF0 KTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoYWlybWFuLCBP cGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9l bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_2a9c32ab66ce4d86a38717a028d2d265BLUPR03MB309namprd03pro_-- From nobody Thu Jul 24 06:53:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3C81A035D for ; Thu, 24 Jul 2014 06:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRYCQ26Eunmj for ; Thu, 24 Jul 2014 06:53:47 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056EB1A0326 for ; Thu, 24 Jul 2014 06:53:04 -0700 (PDT) Received: from mail-ig0-f177.google.com ([209.85.213.177]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKU9EPvx3Fi0kJuPSuo8eT4GZvpWLrChg3@postini.com; Thu, 24 Jul 2014 06:53:04 PDT Received: by mail-ig0-f177.google.com with SMTP id hn18so2686763igb.10 for ; Thu, 24 Jul 2014 06:53:03 -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=26cIIy8v/x9vzI6QsVRn466rbKrEoI43/9Ad7osxT7s=; b=Moo55V2NigMk5JONvBbbiZl3Pm11fnlmGTuUGG0iSu4BI+0oJRKI98oyh8l1A6JSlr /oK8tknVTwWt/lMmTfe2+Hb6IiMpiB5BTBXIfmTMO1RiTWkaSCVFKLFIa6GwTtR6eKs9 rakq43l9QiKWYexuNb9LrTUBatcZBEtD0fBon9re3nsWeO4CvXiD5Ozr9Ov8M+BL31Tu Tt8MTcQuK1O4WW5wI1STvJikJZMBZTelnwWUv+XgMef+k/Ncd+NtwYQA/d72roXS2iGf 3WtRoMK2noAplwTqEyir7J4H38h7yPm17NnI9lJ4oBus2ieegQZsBk+83mx2Wha9kC/C aTcA== X-Gm-Message-State: ALoCoQmOashe+Ffur1FiYJIEdlTCEiVZnMKQb2pgR1f6BCtWY1OI60XPVW8BjzEetQYJ8hfx8fbe75pLVRjq/IWSaaRuXONUz/iEN8GvwCL7B2vxVxtHdi7BWMt2hFS4j55EZFZoL0Pu X-Received: by 10.50.36.106 with SMTP id p10mr39848672igj.9.1406209983384; Thu, 24 Jul 2014 06:53:03 -0700 (PDT) X-Received: by 10.50.36.106 with SMTP id p10mr39848636igj.9.1406209983134; Thu, 24 Jul 2014 06:53:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Thu, 24 Jul 2014 06:52:32 -0700 (PDT) In-Reply-To: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> From: Brian Campbell Date: Thu, 24 Jul 2014 06:52:32 -0700 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=089e0115ebd086585304fef0c6d5 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HDRMWZTYzhOQd9IHBinfr19Bh_c Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 13:53:55 -0000 --089e0115ebd086585304fef0c6d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd note that the reaction at the conference to Ian's statement was overwhelmingly positive. There was a wide range of industry people here - implementers, practitioners, deployers, strategists, etc. - and it seems pretty clear that the "rough consensus" of the industry at large is that a4c is not wanted or needed. On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura wrote: > And here is a quote from Ian's blog. > > And although the authentication wheel is round, that doesn=E2=80=99t mean= it isn=E2=80=99t >> without its lumps. First, we do see some reinventing the wheel just to >> reinvent the wheel. OAuth A4C is simply not a fruitful activity and shou= ld >> be put down. > > > >> (Source) >> http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musi= ngs-on-identity-standards-part-1.html > > > > 2014-07-23 16:53 GMT-04:00 John Bradley : > > I thought I did post this to the list. >> >> I guess I hit the wrong reply on my phone. >> >> John B. >> Sent from my iPhone >> >> On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: >> >> we are two, at least :-) >> >> Why didn't you post this on the list? >> >> When will be be arriving? >> >> Am 23.07.2014 16:39, schrieb John Bradley: >> >> Ian Glazer mentioned this in his keynote at CIS yesterday. >> >> His advice was please stop, we are creating confusion and uncertainty. >> >> We are becoming our own wort enemy. ( my view though Ian may share it) >> >> Returning just an id_ token from the token endpoint has little real >> value. >> >> Something really useful to do would be sorting out channel_id so we can >> do PoP for id tokens to make them and other cookies secure in the front >> channel. I think that is a better use of time. >> >> I may be in the minority opinion on that, it won't be the first time. >> >> >> John B. >> Sent from my iPhone >> >> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt >> wrote: >> >> You are right from a theoretical perspective. Practically this was >> caused by editorial decisions during the creation of the RFC. As far as = I >> remember, there was a definition of the (one) token endpoint response in >> early versions. No one every considered to NOT respond with an access to= ken >> from the token endpoint. So one might call it an implicit assumption. >> >> I'm worried that people get totally confused if an exception is >> introduced now given the broad adoption of OAuth based on this assumptio= n. >> >> regards, >> Torsten. >> >> Am 23.07.2014 um 15:41 schrieb Thomas Broyer : >> >> Is it said anywhere that ALL grant types MUST use Section 5.1 >> responses? Each grant type references Section 5.1, and "access token >> request" is only defined in the context of the defined grant types. Sect= ion >> 2.2 doesn't talk about the request or response format. >> Le 23 juil. 2014 21:32, "Nat Sakimura" a =C3=A9crit= : >> >>> Is it? Apart from the implicit grant that does not use token endpoint, >>> all other grant references section 5.1 for the response, i.e., all shar= es >>> the same response. >>> >>> >>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer : >>> >>>> I hadn't realized the JSON response that requires the access_token >>>> field is defined per grant_type, so I'd be OK to "extend the semantics= " as >>>> in the current draft. >>>> That was actually my main concern: that the token endpoint mandates >>>> access_token; but its actually not the case. >>>> Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9cr= it : >>>> >>>> I agree with John that overloading response_type @ authz endpoint is >>>>> a bad idea. It completely changes the semantics of this parameter. NO= TE: >>>>> what I was proposing was not this parameter, but a new parameter >>>>> response_type @ token endpoint. >>>>> >>>>> I also think overloading grant_type is a bad idea since it changes it= s >>>>> semantics. I quote the definition here again: >>>>> >>>>> grant >>>>> credential representing the resource owner's authorization >>>>> >>>>> grant_type >>>>> type of grant sent to the token endpoint to obtain the access token >>>>> >>>>> It is not about controlling what is to be returned from the token >>>>> endpoint, but the hint to the token endpoint describing the type of >>>>> credential the endpoint has received. It seems the "control of what i= s >>>>> being returned from token endpoint" is just a side effect. >>>>> >>>>> I am somewhat ambivalent[1] in changing the semantics of token >>>>> endpoint, but in as much as "text is the king" for a spec., we probab= ly >>>>> should not change the semantics of it as Torsten points out. If it is= ok to >>>>> change this semantics, I believe defining a new parameter to this end= point >>>>> to control the response would be the best way to go. This is what I h= ave >>>>> described previously. >>>>> >>>>> Defining a new endpoint to send code to get ID Token and forbidding >>>>> the use of it against token endpoint would not change the semantics o= f any >>>>> existing parameter or endpoint, which is good. However, I doubt if it= is >>>>> not worth doing. What's the point of avoiding access token scoped to >>>>> UserInfo endpoint after all? Defining a new endpoint for just avoidin= g the >>>>> access token for userinfo endpoint seems way too much the heavy wait = way >>>>> and it breaks interoperabiliy: it defeats the purpose of standardizat= ion. >>>>> >>>>> I have started feeling that no change is the best way out. >>>>> >>>>> Nat >>>>> >>>>> [1] If instead of saying "Token endpoint - used by the client to >>>>> exchange an authorization grant for an access token, typically with >>>>> client authentication", it were saying "Token endpoint - used by the >>>>> client to exchange an authorization grant for tokens, typically with >>>>> client authentication", then it would have been OK. It is an expansio= n of >>>>> the capability rather than changing the semantics. >>>>> >>>>> >>>>> >>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones : >>>>> >>>>>> You need the alternative response_type value ("code_for_id_token" >>>>>> in the A4C draft) to tell the Authorization Server to return a code = to be >>>>>> used with the new grant type, rather than one to use with the >>>>>> "authorization_code" grant type (which is what response_type=3Dcode = does). >>>>>> >>>>>> >>>>>> >>>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John >>>>>> Bradley >>>>>> *Sent:* Wednesday, July 23, 2014 10:33 AM >>>>>> *To:* torsten@lodderstedt.net >>>>>> >>>>>> *Cc:* oauth@ietf.org >>>>>> *Subject:* Re: [OAUTH-WG] New Version Notification for >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> If we use the token endpoint then a new grant_type is the best way. >>>>>> >>>>>> >>>>>> >>>>>> It sort of overloads code, but that is better than messing with >>>>>> response_type for the authorization endpoint to change the response = from >>>>>> the token_endpoint. That is in my opinion a champion bad idea. >>>>>> >>>>>> >>>>>> >>>>>> In discussions developing Connect we decided not to open this can of >>>>>> worms because no good would come of it. >>>>>> >>>>>> >>>>>> >>>>>> The token_endpoint returns a access token. Nothing requires scope t= o >>>>>> be associates with the token. >>>>>> >>>>>> >>>>>> >>>>>> That is the best solution. No change required. Better >>>>>> interoperability in my opinion. >>>>>> >>>>>> >>>>>> >>>>>> Still on my way to TO, getting in later today. >>>>>> >>>>>> >>>>>> >>>>>> John B. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >>>>>> >>>>>> The "response type" of the token endpoint is controlled by the >>>>>> value of the parameter "grant_type". So there is no need to introduc= e a new >>>>>> parameter. >>>>>> >>>>>> wrt to a potential "no_access_token" grant type. I do not consider >>>>>> this a good idea as it changes the semantics of the token endpoint (= as >>>>>> already pointed out by Thomas). This endpoint ALWAYS responds with a= n >>>>>> access token to any grant type. I therefore would prefer to use anot= her >>>>>> endpoint for the intended purpose. >>>>>> >>>>>> regards, >>>>>> Torsten. >>>>>> >>>>>> >>>>>> >>>>>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>>>>> >>>>>> IMHO, changing the semantics of "response_type" @ authz endpoint >>>>>> this way is not a good thing. >>>>>> >>>>>> >>>>>> >>>>>> Instead, defining a new parameter "response_type" @ token endpoint, >>>>>> as I described in my previous message, >>>>>> >>>>>> probably is better. At least, it does not change the semantics of th= e >>>>>> parameters of RFC6749. >>>>>> >>>>>> >>>>>> >>>>>> Nat >>>>>> >>>>>> >>>>>> >>>>>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >>>>>> >>>>>> No, I mean response_type=3Dnone and response_type=3Did_token don't >>>>>> generate a code or access token so you don't use the Token Endpoint = (which >>>>>> is not the same as the Authentication Endpoint BTW). >>>>>> >>>>>> With response_type=3Dcode_for_id_token, you get a code and exchange = it >>>>>> for an id_token only, rather than an access_token, so you're changin= g the >>>>>> semantics of the Token Endpoint. >>>>>> >>>>>> >>>>>> >>>>>> I'm not saying it's a bad thing, just that you can't really compare >>>>>> none and id_token with code_for_id_token. >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. >>>>>> wrote: >>>>>> >>>>>> It's only "not using the token endpoint" because the token endpoint >>>>>> copy-pasted and renamed the authentication endpoint. >>>>>> >>>>>> >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Except that these are about not using the Token Endpoint at all, >>>>>> whereas the current proposal is about the Token Endpoint not returni= ng an >>>>>> access_token field in the JSON. >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones < >>>>>> Michael.Jones@microsoft.com> wrote: >>>>>> >>>>>> The response_type "none" is already used in practice, which returns >>>>>> no access token. It was accepted by the designated experts and regi= stered >>>>>> in the IANA OAuth Authorization Endpoint Response Types registry at >>>>>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xm= l#endpoint. >>>>>> The registered "id_token" response type also returns no access token= . >>>>>> >>>>>> >>>>>> >>>>>> So I think the question of whether response types that result in no >>>>>> access token being returned are acceptable within OAuth 2.0 is alrea= dy >>>>>> settled, as a practical matter. Lots of OAuth implementations are a= lready >>>>>> using such response types. >>>>>> >>>>>> >>>>>> >>>>>> -- Mike >>>>>> >>>>>> >>>>>> >>>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil >>>>>> Hunt >>>>>> *Sent:* Wednesday, July 23, 2014 7:09 AM >>>>>> *To:* Nat Sakimura >>>>>> *Cc:* >>>>>> *Subject:* Re: [OAUTH-WG] New Version Notification for >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>> >>>>>> >>>>>> >>>>>> Yes. This is why it has to be discussed in the IETF. >>>>>> >>>>>> >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> >>>>>> @independentid >>>>>> >>>>>> www.independentid.com >>>>>> >>>>>> phil.hunt@oracle.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote= : >>>>>> >>>>>> >>>>>> >>>>>> Reading back the RFC6749, I am not sure if there is a good way of >>>>>> suppressing access token from the response and still be OAuth. It wi= ll >>>>>> break whole bunch of implicit definitions like: >>>>>> >>>>>> >>>>>> >>>>>> authorization server >>>>>> The server issuing access tokens to the client after >>>>>> successfully >>>>>> authenticating the resource owner and obtaining authorization. >>>>>> >>>>>> >>>>>> >>>>>> After all, OAuth is all about issuing access tokens. >>>>>> >>>>>> >>>>>> >>>>>> Also, I take back my statement on the grant type in my previous mail= . >>>>>> >>>>>> >>>>>> >>>>>> The definition of grant and grant_type are respectively: >>>>>> >>>>>> >>>>>> >>>>>> grant >>>>>> >>>>>> credential representing the resource owner's authorization >>>>>> >>>>>> >>>>>> >>>>>> grant_type >>>>>> >>>>>> (string representing the) type of grant sent to the token >>>>>> endpoint to obtain the access token >>>>>> >>>>>> >>>>>> >>>>>> Thus, the grant sent to the token endpoint in this case is still >>>>>> 'code'. >>>>>> >>>>>> >>>>>> >>>>>> Response type on the other hand is not so well defined in RFC6749, >>>>>> but it seems it is representing what is to be returned from the >>>>>> authorization endpoint. To express what is to be returned from token >>>>>> endpoint, perhaps defining a new parameter to the token endpoint, wh= ich is >>>>>> a parallel to the response_type to the Authorization Endpoint seems = to be a >>>>>> more symmetric way, though I am not sure at all if that is going to = be >>>>>> OAuth any more. One straw-man is to define a new parameter called >>>>>> response_type to the token endpoint such as: >>>>>> >>>>>> >>>>>> >>>>>> response_type >>>>>> >>>>>> OPTIONAL. A string representing what is to be returned from the >>>>>> token endpoint. >>>>>> >>>>>> >>>>>> >>>>>> Then define the behavior of the endpoint according to the values as >>>>>> the parallel to the multi-response type spec. >>>>>> >>>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>>> >>>>>> >>>>>> >>>>>> Nat >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>>>>> >>>>>> The draft is very clear. >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >>>>>> >>>>>> The new grant type that I was talking about was >>>>>> >>>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", so >>>>>> to speak. >>>>>> >>>>>> It does not return anything per se, but an extension can define >>>>>> something on top of it. >>>>>> >>>>>> >>>>>> >>>>>> Then, OIDC can define a binding to it so that the binding only >>>>>> returns ID Token. >>>>>> >>>>>> This binding work should be done in OIDF. Should there be such a >>>>>> grant type, >>>>>> >>>>>> it will be an extremely short spec. >>>>>> >>>>>> >>>>>> >>>>>> At the same time, if any other specification wanted to define >>>>>> >>>>>> other type of tokens and have it returned from the token endpoint, >>>>>> >>>>>> it can also use this grant type. >>>>>> >>>>>> >>>>>> >>>>>> If what you want is to define a new grant type that returns ID Token >>>>>> only, >>>>>> >>>>>> then, I am with Justin. Since "other response than ID Token" is only >>>>>> >>>>>> theoretical, this is a more plausible way forward, I suppose. >>>>>> >>>>>> >>>>>> >>>>>> Nat >>>>>> >>>>>> >>>>>> >>>>>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>>>>> >>>>>> So the draft would literally turn into: >>>>>> >>>>>> "The a4c response type and grant type return an id_token from the >>>>>> token endpoint with no access token. All parameters and values are d= efined >>>>>> in OIDC." >>>>>> >>>>>> Seems like the perfect mini extension draft for OIDF to do. >>>>>> >>>>>> --Justin >>>>>> >>>>>> /sent from my phone/ >>>>>> >>>>>> >>>>>> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >>>>>> > >>>>>> > What about just defining a new grant type in this WG? >>>>>> > >>>>>> > >>>>>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>>>>> >> >>>>>> >> That would be nice. However oidc still needs the new grant type i= n >>>>>> order to implement the same flow. >>>>>> >> >>>>>> >> Phil >>>>>> >> >>>>>> >> On Jul 22, 2014, at 11:35, Nat Sakimura >>>>>> wrote: >>>>>> >> >>>>>> >>> +1 to Justin. >>>>>> >>> >>>>>> >>> >>>>>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >>>>>> >>>> >>>>>> >>>> Errors like these make it clear to me that it would make much >>>>>> more sense to develop this document in the OpenID Foundation. It sho= uld be >>>>>> something that directly references OpenID Connect Core for all of th= ese >>>>>> terms instead of redefining them. It's doing authentication, which i= s >>>>>> fundamentally what OpenID Connect does on top of OAuth, and I don't = see a >>>>>> good argument for doing this work in this working group. >>>>>> >>>> >>>>>> >>>> -- Justin >>>>>> >>>> >>>>>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer >>>>>> wrote: >>>>>> >>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < >>>>>> Michael.Jones@microsoft.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" >>>>>> definition being missing is an editorial error. It should be: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> consent >>>>>> >>>>>> >>>>>> >>>>>> The Authorization Server SHOULD prompt the End-User for >>>>>> consent before returning information to the Client. If it cannot obt= ain >>>>>> consent, it MUST return an error, typically consent_required. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I'll plan to add it in the next draft. >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> It looks like the consent_required error needs to be defined >>>>>> too, and you might have forgotten to also import account_selection_r= equired >>>>>> from OpenID Connect. >>>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I agree that there's no difference between a response with >>>>>> multiple "amr" values that includes "mfa" and one that doesn't. Unl= ess a >>>>>> clear use case for why "mfa" is needed can be identified, we can del= ete it >>>>>> in the next draft. >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> Thanks. >>>>>> >>>>> >>>>>> >>>>> How about "pwd" then? I fully understand that I should return >>>>>> "pwd" if the user authenticated using a password, but what "the serv= ice if >>>>>> a client secret is used" means in the definition for the "pwd" value= ? >>>>>> >>>>> >>>>>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you >>>>>> come back ;-) ) >>>>>> >>>>> >>>>>> >>>>> -- >>>>>> >>>>> Thomas Broyer >>>>>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>> >>>>> _______________________________________________ >>>>>> >>>>> 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 >>>>>> >>>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> -- >>>>>> >>> Nat Sakimura (=3Dnat) >>>>>> >>> Chairman, OpenID Foundation >>>>>> >>> http://nat.sakimura.org/ >>>>>> >>> @_nat_en >>>>>> >>> >>>>>> >>> _______________________________________________ >>>>>> >>> OAuth mailing list >>>>>> >>> OAuth@ietf.org >>>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Nat Sakimura (=3Dnat) >>>>>> > Chairman, OpenID Foundation >>>>>> > http://nat.sakimura.org/ >>>>>> > @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=3Dnat) >>>>>> >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=3Dnat) >>>>>> >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thomas Broyer >>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thomas Broyer >>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=3Dnat) >>>>>> >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Nat Sakimura (=3Dnat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >> _______________________________________________ >> 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 >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e0115ebd086585304fef0c6d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd note that the reaction at the conference to Ian= 9;s statement was overwhelmingly positive. There was a wide range of indust= ry people here - implementers, practitioners, deployers, strategists, etc. = - and it seems pretty clear that the "rough consensus" of the ind= ustry at large is that a4c is not wanted or needed.


On Thu,= Jul 24, 2014 at 5:29 AM, Nat Sakimura <sakimura@gmail.com>= wrote:
And here is a quote from Ia= n's blog.=C2=A0

And although the authentication wheel is round, that doesn=E2=80=99t mean i= t isn=E2=80=99t without its lumps. First, we do see some reinventing the wh= eel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity= and should be put down. =C2=A0
=C2=A0
(Source) http://www.tuesdaynight.org/2014/07/23/do-= we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html


2014-07= -23 16:53 GMT-04:00 John Bradley <ve7jtb@ve7jtb.com>:

I thought I did post this to the list.=C2=A0

I guess I hit the wrong reply on my phone.=C2=A0
=C2= =A0
John B.=C2=A0
Sent from my iPhone
On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote:

we are two, at least :-)

Why didn't you post this on the list?

When will be be arriving?

Am 23.07.2014 16:39, schrieb John Bradley:

Ian Glazer mentioned this in his keynote at CIS yesterday.=C2=A0
=C2=A0
His advice was please stop, =C2=A0we are creating confusion and uncert= ainty.=C2=A0
=C2=A0
We are becoming our own wort enemy. ( my view though Ian may share it)=
=C2=A0
Returning just an id_ token from the token endpoint has little real va= lue.=C2=A0
=C2=A0
Something really useful to do would be sorting out channel_id so we ca= n do PoP for id tokens to make them and other cookies secure in the front c= hannel. =C2=A0 I think that is a better use of time.=C2=A0
=C2=A0
I may be in the minority opinion on that, =C2=A0it won't be the fi= rst time. =C2=A0


John B.=C2=A0
Sent from my iPhone

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <torsten@lodderstedt.net= > wrote:

You are right from a theoretical perspective. Practically this was cau= sed by editorial decisions during the creation of the RFC. As far as I reme= mber, there was a definition of the (one) token endpoint response in early = versions. No one every considered to NOT respond with an access token from = the token endpoint. So one might call it an implicit assumption.
=C2=A0
I'm worried that people get totally confused if an exception is in= troduced now given the broad adoption of OAuth based on this assumption.
=C2=A0
regards,
Torsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

<= /div>

Is it said anywhere that ALL grant types MUST use Section 5.= 1 responses? Each grant type references Section 5.1, and "access token= request" is only defined in the context of the defined grant types. S= ection 2.2 doesn't talk about the request or response format.

Le 23 juil. 2014 21:32, "Nat Sakimura"= <sakimura@gmail= .com> a =C3=A9crit :
Is it? Apart from the implicit grant that does not use tok= en endpoint, all other grant references section 5.1 for the response, i.e.,= all shares the same response.=C2=A0


2014-07-23 15:18 GMT-04:00 Thomas Broyer &= lt;t.broyer@gmail.c= om>:

I hadn't realized the JSON response that requires the ac= cess_token field is defined per grant_type, so I'd be OK to "exten= d the semantics" as in the current draft.
That was actually my mai= n concern: that the token endpoint mandates access_token; but its actually = not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura"= <sakimura@gmail= .com> a =C3=A9crit :

I agree with John that overloading response_type @ authz endpoint is a= bad idea. It completely changes the semantics of this parameter. NOTE: wha= t I was proposing was not this parameter, but a new parameter response_type= @ token endpoint.=C2=A0
=C2=A0
I also think overloading grant_type is a bad idea since it changes its= semantics. I quote the definition here again:=C2=A0
=C2=A0
grant=C2=A0
=C2=A0 =C2=A0 credential representing the resource owner's authori= zation
=C2=A0
grant_type
type of grant sent to the= token endpoint to obtain the access token
=C2=A0
It is not about controlling what is to be returned from the token endp= oint, but the hint to the token endpoint describing the type of credential = the endpoint has received. It seems the "control of what is being retu= rned from token endpoint" =C2=A0is just a side effect.=C2=A0
=C2=A0
I am somewhat ambivalent[1] in changing the semantics of token endpoin= t, but in as much as "text is the king" for a spec., we probably = should not change the semantics of it as Torsten points out. If it is ok to= change this semantics, I believe defining a new parameter to this endpoint= to control the response would be the best way to go. This is what I have d= escribed previously.=C2=A0
=C2=A0
Defining a new endpoint to send code to get ID Token and forbidding th= e use of it against token endpoint would not change the semantics of any ex= isting parameter or endpoint, which is good. However, I doubt if it is not = worth doing. What's the point of avoiding access token scoped to UserIn= fo endpoint after all? Defining a new endpoint for just avoiding the access= token for userinfo endpoint seems way too much the heavy wait way and it b= reaks interoperabiliy: it defeats the purpose of standardization.=C2=A0
=C2=A0
I have started feeling that no change is the best way out.=C2=A0
=C2=A0
Nat
=C2=A0
[1] =C2=A0If instead of saying "Token endpoint - used by the client to exchange an authorization= =C2=A0grant for an access token, typically with client authenticatio= n", it were saying "T= oken endpoint - used by the client to exchange an authorization=C2=A0grant for tokens, typically with client authentication", then it woul= d have been OK. It is an expansion of the capability rather than changing t= he semantics.
=C2=A0


2014-07-23 13:39 GMT-04:00 Mike Jones <= Michael.Jo= nes@microsoft.com>:

You need the alternative resp= onse_type value ("code_for_id_token" in the A4C draft) to tell the Authorization Server to return= a code to be used with the new grant type, rather than one to use with the= "authorization_code" grant type (which is what response_type=3Dc= ode does).

=C2=A0=

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: torsten@= lodderstedt.net


Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New V= ersion Notification for draft-hunt-oauth-v2-user-a4c-05.txt=

=C2=A0

=C2= =A0

If we use the token endpoint then a new grant_type i= s the best way.=C2=A0

=C2= =A0

It sort of overloads code, but that is better than m= essing with response_type for the authorization endpoint to change the resp= onse from the token_endpoint. =C2=A0That is in my opinion a champion bad id= ea.=C2=A0

=C2= =A0

In discussions developing Connect we decided not to = open this can of worms because no good would come of it. =C2=A0=C2=A0

=C2= =A0

The token_endpoint returns a access token. =C2=A0Not= hing requires scope to be associates with the token.=C2=A0<= /span>

=C2= =A0

That is the best solution. =C2=A0No change required.= =C2=A0Better interoperability in my opinion.=C2=A0<= /p>

=C2= =A0

Still on my way to TO, getting in later today.=C2=A0=

=C2= =A0

John B.=C2=A0

=C2= =A0



Sent from my iPhone<= /p>


On Jul 23, 2014,= at 12:15 PM, = torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the= value of the parameter "grant_type". So there is no need to intr= oduce a new parameter.

wrt to a potential "no_access_token" grant type. I do not cons= ider this a good idea as it changes the semantics of the token endpoint (as= already pointed out by Thomas). This endpoint ALWAYS responds with an acce= ss token to any grant type. I therefore would prefer to use another endpoin= t for the intended purpose.

regards,
Torsten.

=C2=A0

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type&= quot; @ authz endpoint this way is not a good thing.=C2=A0<= /span>

=C2=A0

Instead, defining a new parameter "response_typ= e" @ token endpoint, as I described in my previous message,=C2=A0

probably is better. At least, it does not change the= semantics of the parameters of RFC6749.=C2=A0

=C2=A0

=C2=A0Nat=C2=A0

=C2=A0

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>= :

No, I mean response_type=3Dnone and response_type=3D= id_token don't generate a code or access token so you don't use the= Token Endpoint (which is not the same as the Authentication Endpoint BTW).=

With response_type=3Dcode_for_id_token, you get a co= de and exchange it for an id_token only, rather than an access_token, so yo= u're changing the semantics of the Token Endpoint.

=C2=A0

I'm not saying it's a bad thing, just that y= ou can't really compare none and id_token with code_for_id_token.

=C2=A0

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It's only "not using the token endpoint&quo= t; because the token endpoint copy-pasted and renamed the authentication en= dpoint.

=C2=A0

=C2=A0-- Justin

=C2= =A0

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com&g= t; wrote:



Except that these are about not using the Token Endp= oint at all, whereas the current proposal is about the Token Endpoint not r= eturning an access_token field in the JSON.

=C2=A0

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

The response_type "none&= quot; is already used in practice, which returns no access token.=C2=A0 It = was accepted by the designated experts and registered in the IANA OAuth Aut= horization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xm= l#endpoint.=C2=A0 The registered "id_token" response type als= o returns no access token.=

=C2=A0=

So I think the question of wh= ether response types that result in no access token being returned are acce= ptable within OAuth 2.0 is already settled, as a practical matter.=C2=A0 Lo= ts of OAuth implementations are already using such response types.

=C2=A0=

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

=C2=A0=

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of Phil Hunt
S= ent: Wednesday, July 23, 2014 7:09 AM
To:= Nat Sakimura
C= c: <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Versio= n Notification for draft-hunt-oauth-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

Phil

=C2=A0

@independentid

= phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

=C2=A0

Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The se= rver issuing access tokens to the client after successfully
=C2=A0 =C2= =A0 =C2=A0 authenticating the resource owner and obtaining authorization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type=

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token en= dpoint, perhaps defining a new parameter to the token endpoint, which is a = parallel to the response_type to the Authorization Endpoint seems to be a m= ore symmetric way, though I am not sure at all if that is going to be OAuth= any more. One straw-man is to define a new parameter called response_type = to the token endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0

=C2=A0

Nat=

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014,= at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0<= /span>

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat=

=C2=A0

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

&quo= t;The a4c response type and grant type return an id_token from the token en= dpoint with no access token. All parameters and values are defined in OIDC.= "

Seems like the perfect mini extension draft for OIDF to do.

--= Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com&= gt; wrote:
>
> What about just defining a new grant type in t= his WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>= ;:
>>
>> That would be nice. However oidc still needs t= he new grant type in order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 1= 1:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to J= ustin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 R= icher, Justin P. <jricher@mitre.org>:
>>>>
>>>> Error= s like these make it clear to me that it would make much more sense to deve= lop this document in the OpenID Foundation. It should be something that dir= ectly references OpenID Connect Core for all of these terms instead of rede= fining them. It's doing authentication, which is fundamentally what Ope= nID Connect does on top of OAuth, and I don't see a good argument for d= oing this work in this working group.
>>>>
>>>> =C2=A0-- Justin
>>>>=
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com>= ; wrote:
>>>>
>>>>>
>>>>>
>= ;>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM= , Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>>>
>>>>>> Thanks for your revi= ew, Thomas.=C2=A0 The "prompt=3Dconsent" definition being missing= is an editorial error.=C2=A0 It should be:
>>>>>> >>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>= >>>>
>>>>>> The Authorization Server SHOU= LD prompt the End-User for consent before returning information to the Clie= nt. If it cannot obtain consent, it MUST return an error, typically consent= _required.
>>>>>>
>>>>>> =C2=A0
>>&= gt;>>>
>>>>>> I'll plan to add it in the= next draft.
>>>>>
>>>>>
>>= >>> It looks like the consent_required error needs to be defined t= oo, and you might have forgotten to also import account_selection_required = from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>&= gt;>> =C2=A0
>>>>>>
>>>>>>= ; I agree that there's no difference between a response with multiple &= quot;amr" values that includes "mfa" and one that doesn'= t.=C2=A0 Unless a clear use case for why "mfa" is needed can be i= dentified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Tha= nks.
>>>>>
>>>>> How about "pwd&= quot; then? I fully understand that I should return "pwd" if the = user authenticated using a password, but what "the service if a client= secret is used" means in the definition for the "pwd" value= ?
>>>>>
>>>>> (Nota: I know you're at = IETF-90, I'm ready to wait 'til you come back ;-) )
>>>= ;>>
>>>>> --
>>>>> Thomas Broye= r
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _________= ______________________________________
>>>>> OAuth maili= ng list
>>>>> O= Auth@ietf.org
>>>>> https://www.ietf.org/mailman/list= info/oauth
>>>>
>>>>
>>>>
>>>= ;> _______________________________________________
>>>> = OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>&g= t;>>
>>>
>>>
>>>
>>&= gt; --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Found= ation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>><= br> >>> _______________________________________________
>>&= gt; OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/ma= ilman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)=
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)=

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en=



=C2=A0

--
Nat Sakimura (=3Dnat)=

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en=

=C2=A0


________________= _______________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth



=C2=A0

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma.b= =CA=81wa.je/


________________= _______________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en=

=C2= =A0

_______________________________________________=

OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth<=
/pre>

=C2=A0

=C2=A0

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


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



=C2=A0
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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



=C2=A0
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
= 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

=C2=A0

=C2=A0

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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en

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


--089e0115ebd086585304fef0c6d5-- From nobody Thu Jul 24 07:01:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C209C1A031C for ; Thu, 24 Jul 2014 07:01:01 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WI6c2XzzGA7K for ; Thu, 24 Jul 2014 07:00:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BCC1A02E7 for ; Thu, 24 Jul 2014 07:00:45 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB311.namprd03.prod.outlook.com (10.141.48.26) with Microsoft SMTP Server (TLS) id 15.0.995.11; Thu, 24 Jul 2014 14:00:42 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0995.011; Thu, 24 Jul 2014 14:00:42 +0000 From: Anthony Nadalin To: Brian Campbell , Nat Sakimura Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpdsDt+c24NfaK06ekEi1OvV9MZutFmeAgABuQQCAACfBgIAABwoAgAAFHwCAACJ8AIAABDOAgAAAxwCAAASJAIAAAz+AgAAE4ACAAAGWgIAAEq+AgAAJNoCAAAOsAIAAAq8AgAAGTgCAAA3vkIABBUgAgAAXRgCAAACnwA== Date: Thu, 24 Jul 2014 14:00:41 +0000 Message-ID: <9dbf8c7384e341a08334a9ee093697f8@BLUPR03MB309.namprd03.prod.outlook.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:160:bd80:f316:8c8:bc9] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(189002)(377424004)(199002)(24454002)(377454003)(74316001)(15975445006)(19609705001)(74502001)(19580395003)(106116001)(4396001)(19580405001)(105586002)(21056001)(81542001)(64706001)(15395725005)(551544002)(74662001)(83322001)(99396002)(99286002)(46102001)(86362001)(85306003)(19617315012)(92566001)(561944003)(101416001)(79102001)(106356001)(107046002)(33646002)(19625215002)(2656002)(81342001)(93886003)(76576001)(76482001)(16236675004)(85852003)(19300405004)(77982001)(83072002)(80022001)(15202345003)(95666004)(50986999)(76176999)(86612001)(20776003)(87936001)(54356999)(31966008)(108616002)(42262001)(24736002)(3826002)(559001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB311; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_9dbf8c7384e341a08334a9ee093697f8BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3O0rKHCPY6utptgdGxPQARngZMM Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 14:01:01 -0000 --_000_9dbf8c7384e341a08334a9ee093697f8BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gc3VyZSBpdCB3YXMgc3B1biBpbiBhIHdheSB0aGF0IGNvdWxkIGJlIHRydWUgc2luY2Ug dGhlcmUgd2FzIG5vIHRlY2huaWNhbCB2YWx1ZSB0byBJYW7igJlzIHN0YXRlbWVudCBhbmQgSeKA mW0gc3VyZSB0aGF0IGZvbGtzIGhhZCBub3QgcmVhZCBvciB1bmRlcnN0YW5kIHRoZSB1c2FnZS4N Cg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IFRodXJzZGF5LCBKdWx5IDI0LCAyMDE0IDY6NTMgQU0N ClRvOiBOYXQgU2FraW11cmENCkNjOiBvYXV0aEBpZXRmLm9yZyBsaXN0DQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgt djItdXNlci1hNGMtMDUudHh0DQoNCkknZCBub3RlIHRoYXQgdGhlIHJlYWN0aW9uIGF0IHRoZSBj b25mZXJlbmNlIHRvIElhbidzIHN0YXRlbWVudCB3YXMgb3ZlcndoZWxtaW5nbHkgcG9zaXRpdmUu IFRoZXJlIHdhcyBhIHdpZGUgcmFuZ2Ugb2YgaW5kdXN0cnkgcGVvcGxlIGhlcmUgLSBpbXBsZW1l bnRlcnMsIHByYWN0aXRpb25lcnMsIGRlcGxveWVycywgc3RyYXRlZ2lzdHMsIGV0Yy4gLSBhbmQg aXQgc2VlbXMgcHJldHR5IGNsZWFyIHRoYXQgdGhlICJyb3VnaCBjb25zZW5zdXMiIG9mIHRoZSBp bmR1c3RyeSBhdCBsYXJnZSBpcyB0aGF0IGE0YyBpcyBub3Qgd2FudGVkIG9yIG5lZWRlZC4NCg0K T24gVGh1LCBKdWwgMjQsIDIwMTQgYXQgNToyOSBBTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBn bWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KQW5kIGhlcmUgaXMg YSBxdW90ZSBmcm9tIElhbidzIGJsb2cuDQoNCkFuZCBhbHRob3VnaCB0aGUgYXV0aGVudGljYXRp b24gd2hlZWwgaXMgcm91bmQsIHRoYXQgZG9lc27igJl0IG1lYW4gaXQgaXNu4oCZdCB3aXRob3V0 IGl0cyBsdW1wcy4gRmlyc3QsIHdlIGRvIHNlZSBzb21lIHJlaW52ZW50aW5nIHRoZSB3aGVlbCBq dXN0IHRvIHJlaW52ZW50IHRoZSB3aGVlbC4gT0F1dGggQTRDIGlzIHNpbXBseSBub3QgYSBmcnVp dGZ1bCBhY3Rpdml0eSBhbmQgc2hvdWxkIGJlIHB1dCBkb3duLg0KDQooU291cmNlKSBodHRwOi8v d3d3LnR1ZXNkYXluaWdodC5vcmcvMjAxNC8wNy8yMy9kby13ZS1oYXZlLWEtcm91bmQtd2hlZWwt eWV0LW11c2luZ3Mtb24taWRlbnRpdHktc3RhbmRhcmRzLXBhcnQtMS5odG1sDQoNCjIwMTQtMDct MjMgMTY6NTMgR01ULTA0OjAwIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRv OnZlN2p0YkB2ZTdqdGIuY29tPj46DQoNCkkgdGhvdWdodCBJIGRpZCBwb3N0IHRoaXMgdG8gdGhl IGxpc3QuDQoNCkkgZ3Vlc3MgSSBoaXQgdGhlIHdyb25nIHJlcGx5IG9uIG15IHBob25lLg0KDQpK b2huIEIuDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIEp1bCAyMywgMjAxNCwgYXQgNDo1MCBQ TSwgdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0 PiB3cm90ZToNCg0Kd2UgYXJlIHR3bywgYXQgbGVhc3QgOi0pDQoNCldoeSBkaWRuJ3QgeW91IHBv c3QgdGhpcyBvbiB0aGUgbGlzdD8NCg0KV2hlbiB3aWxsIGJlIGJlIGFycml2aW5nPw0KDQpBbSAy My4wNy4yMDE0IDE2OjM5LCBzY2hyaWViIEpvaG4gQnJhZGxleToNCklhbiBHbGF6ZXIgbWVudGlv bmVkIHRoaXMgaW4gaGlzIGtleW5vdGUgYXQgQ0lTIHllc3RlcmRheS4NCg0KSGlzIGFkdmljZSB3 YXMgcGxlYXNlIHN0b3AsICB3ZSBhcmUgY3JlYXRpbmcgY29uZnVzaW9uIGFuZCB1bmNlcnRhaW50 eS4NCg0KV2UgYXJlIGJlY29taW5nIG91ciBvd24gd29ydCBlbmVteS4gKCBteSB2aWV3IHRob3Vn aCBJYW4gbWF5IHNoYXJlIGl0KQ0KDQpSZXR1cm5pbmcganVzdCBhbiBpZF8gdG9rZW4gZnJvbSB0 aGUgdG9rZW4gZW5kcG9pbnQgaGFzIGxpdHRsZSByZWFsIHZhbHVlLg0KDQpTb21ldGhpbmcgcmVh bGx5IHVzZWZ1bCB0byBkbyB3b3VsZCBiZSBzb3J0aW5nIG91dCBjaGFubmVsX2lkIHNvIHdlIGNh biBkbyBQb1AgZm9yIGlkIHRva2VucyB0byBtYWtlIHRoZW0gYW5kIG90aGVyIGNvb2tpZXMgc2Vj dXJlIGluIHRoZSBmcm9udCBjaGFubmVsLiAgIEkgdGhpbmsgdGhhdCBpcyBhIGJldHRlciB1c2Ug b2YgdGltZS4NCg0KSSBtYXkgYmUgaW4gdGhlIG1pbm9yaXR5IG9waW5pb24gb24gdGhhdCwgIGl0 IHdvbid0IGJlIHRoZSBmaXJzdCB0aW1lLg0KDQoNCkpvaG4gQi4NClNlbnQgZnJvbSBteSBpUGhv bmUNCg0KT24gSnVsIDIzLCAyMDE0LCBhdCA0OjA0IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3 cm90ZToNCllvdSBhcmUgcmlnaHQgZnJvbSBhIHRoZW9yZXRpY2FsIHBlcnNwZWN0aXZlLiBQcmFj dGljYWxseSB0aGlzIHdhcyBjYXVzZWQgYnkgZWRpdG9yaWFsIGRlY2lzaW9ucyBkdXJpbmcgdGhl IGNyZWF0aW9uIG9mIHRoZSBSRkMuIEFzIGZhciBhcyBJIHJlbWVtYmVyLCB0aGVyZSB3YXMgYSBk ZWZpbml0aW9uIG9mIHRoZSAob25lKSB0b2tlbiBlbmRwb2ludCByZXNwb25zZSBpbiBlYXJseSB2 ZXJzaW9ucy4gTm8gb25lIGV2ZXJ5IGNvbnNpZGVyZWQgdG8gTk9UIHJlc3BvbmQgd2l0aCBhbiBh Y2Nlc3MgdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQuIFNvIG9uZSBtaWdodCBjYWxsIGl0 IGFuIGltcGxpY2l0IGFzc3VtcHRpb24uDQoNCkknbSB3b3JyaWVkIHRoYXQgcGVvcGxlIGdldCB0 b3RhbGx5IGNvbmZ1c2VkIGlmIGFuIGV4Y2VwdGlvbiBpcyBpbnRyb2R1Y2VkIG5vdyBnaXZlbiB0 aGUgYnJvYWQgYWRvcHRpb24gb2YgT0F1dGggYmFzZWQgb24gdGhpcyBhc3N1bXB0aW9uLg0KDQpy ZWdhcmRzLA0KVG9yc3Rlbi4NCg0KQW0gMjMuMDcuMjAxNCB1bSAxNTo0MSBzY2hyaWViIFRob21h cyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPj46 DQoNCklzIGl0IHNhaWQgYW55d2hlcmUgdGhhdCBBTEwgZ3JhbnQgdHlwZXMgTVVTVCB1c2UgU2Vj dGlvbiA1LjEgcmVzcG9uc2VzPyBFYWNoIGdyYW50IHR5cGUgcmVmZXJlbmNlcyBTZWN0aW9uIDUu MSwgYW5kICJhY2Nlc3MgdG9rZW4gcmVxdWVzdCIgaXMgb25seSBkZWZpbmVkIGluIHRoZSBjb250 ZXh0IG9mIHRoZSBkZWZpbmVkIGdyYW50IHR5cGVzLiBTZWN0aW9uIDIuMiBkb2Vzbid0IHRhbGsg YWJvdXQgdGhlIHJlcXVlc3Qgb3IgcmVzcG9uc2UgZm9ybWF0Lg0KTGUgMjMganVpbC4gMjAxNCAy MTozMiwgIk5hdCBTYWtpbXVyYSIgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFA Z21haWwuY29tPj4gYSDDqWNyaXQgOg0KSXMgaXQ/IEFwYXJ0IGZyb20gdGhlIGltcGxpY2l0IGdy YW50IHRoYXQgZG9lcyBub3QgdXNlIHRva2VuIGVuZHBvaW50LCBhbGwgb3RoZXIgZ3JhbnQgcmVm ZXJlbmNlcyBzZWN0aW9uIDUuMSBmb3IgdGhlIHJlc3BvbnNlLCBpLmUuLCBhbGwgc2hhcmVzIHRo ZSBzYW1lIHJlc3BvbnNlLg0KDQoyMDE0LTA3LTIzIDE1OjE4IEdNVC0wNDowMCBUaG9tYXMgQnJv eWVyIDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+Og0KDQpJ IGhhZG4ndCByZWFsaXplZCB0aGUgSlNPTiByZXNwb25zZSB0aGF0IHJlcXVpcmVzIHRoZSBhY2Nl c3NfdG9rZW4gZmllbGQgaXMgZGVmaW5lZCBwZXIgZ3JhbnRfdHlwZSwgc28gSSdkIGJlIE9LIHRv ICJleHRlbmQgdGhlIHNlbWFudGljcyIgYXMgaW4gdGhlIGN1cnJlbnQgZHJhZnQuDQpUaGF0IHdh cyBhY3R1YWxseSBteSBtYWluIGNvbmNlcm46IHRoYXQgdGhlIHRva2VuIGVuZHBvaW50IG1hbmRh dGVzIGFjY2Vzc190b2tlbjsgYnV0IGl0cyBhY3R1YWxseSBub3QgdGhlIGNhc2UuDQpMZSAyMyBq dWlsLiAyMDE0IDIwOjQ2LCAiTmF0IFNha2ltdXJhIiA8c2FraW11cmFAZ21haWwuY29tPG1haWx0 bzpzYWtpbXVyYUBnbWFpbC5jb20+PiBhIMOpY3JpdCA6DQoNCkkgYWdyZWUgd2l0aCBKb2huIHRo YXQgb3ZlcmxvYWRpbmcgcmVzcG9uc2VfdHlwZSBAIGF1dGh6IGVuZHBvaW50IGlzIGEgYmFkIGlk ZWEuIEl0IGNvbXBsZXRlbHkgY2hhbmdlcyB0aGUgc2VtYW50aWNzIG9mIHRoaXMgcGFyYW1ldGVy LiBOT1RFOiB3aGF0IEkgd2FzIHByb3Bvc2luZyB3YXMgbm90IHRoaXMgcGFyYW1ldGVyLCBidXQg YSBuZXcgcGFyYW1ldGVyIHJlc3BvbnNlX3R5cGUgQCB0b2tlbiBlbmRwb2ludC4NCg0KSSBhbHNv IHRoaW5rIG92ZXJsb2FkaW5nIGdyYW50X3R5cGUgaXMgYSBiYWQgaWRlYSBzaW5jZSBpdCBjaGFu Z2VzIGl0cyBzZW1hbnRpY3MuIEkgcXVvdGUgdGhlIGRlZmluaXRpb24gaGVyZSBhZ2FpbjoNCg0K Z3JhbnQNCiAgICBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBh dXRob3JpemF0aW9uDQoNCmdyYW50X3R5cGUNCnR5cGUgb2YgZ3JhbnQgc2VudCB0byB0aGUgdG9r ZW4gZW5kcG9pbnQgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW4NCg0KSXQgaXMgbm90IGFib3V0 IGNvbnRyb2xsaW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUgdG9rZW4gZW5kcG9p bnQsIGJ1dCB0aGUgaGludCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgZGVzY3JpYmluZyB0aGUgdHlw ZSBvZiBjcmVkZW50aWFsIHRoZSBlbmRwb2ludCBoYXMgcmVjZWl2ZWQuIEl0IHNlZW1zIHRoZSAi Y29udHJvbCBvZiB3aGF0IGlzIGJlaW5nIHJldHVybmVkIGZyb20gdG9rZW4gZW5kcG9pbnQiICBp cyBqdXN0IGEgc2lkZSBlZmZlY3QuDQoNCkkgYW0gc29tZXdoYXQgYW1iaXZhbGVudFsxXSBpbiBj aGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mIHRva2VuIGVuZHBvaW50LCBidXQgaW4gYXMgbXVjaCBh cyAidGV4dCBpcyB0aGUga2luZyIgZm9yIGEgc3BlYy4sIHdlIHByb2JhYmx5IHNob3VsZCBub3Qg Y2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgaXQgYXMgVG9yc3RlbiBwb2ludHMgb3V0LiBJZiBpdCBp cyBvayB0byBjaGFuZ2UgdGhpcyBzZW1hbnRpY3MsIEkgYmVsaWV2ZSBkZWZpbmluZyBhIG5ldyBw YXJhbWV0ZXIgdG8gdGhpcyBlbmRwb2ludCB0byBjb250cm9sIHRoZSByZXNwb25zZSB3b3VsZCBi ZSB0aGUgYmVzdCB3YXkgdG8gZ28uIFRoaXMgaXMgd2hhdCBJIGhhdmUgZGVzY3JpYmVkIHByZXZp b3VzbHkuDQoNCkRlZmluaW5nIGEgbmV3IGVuZHBvaW50IHRvIHNlbmQgY29kZSB0byBnZXQgSUQg VG9rZW4gYW5kIGZvcmJpZGRpbmcgdGhlIHVzZSBvZiBpdCBhZ2FpbnN0IHRva2VuIGVuZHBvaW50 IHdvdWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBhbnkgZXhpc3RpbmcgcGFyYW1ldGVy IG9yIGVuZHBvaW50LCB3aGljaCBpcyBnb29kLiBIb3dldmVyLCBJIGRvdWJ0IGlmIGl0IGlzIG5v dCB3b3J0aCBkb2luZy4gV2hhdCdzIHRoZSBwb2ludCBvZiBhdm9pZGluZyBhY2Nlc3MgdG9rZW4g c2NvcGVkIHRvIFVzZXJJbmZvIGVuZHBvaW50IGFmdGVyIGFsbD8gRGVmaW5pbmcgYSBuZXcgZW5k cG9pbnQgZm9yIGp1c3QgYXZvaWRpbmcgdGhlIGFjY2VzcyB0b2tlbiBmb3IgdXNlcmluZm8gZW5k cG9pbnQgc2VlbXMgd2F5IHRvbyBtdWNoIHRoZSBoZWF2eSB3YWl0IHdheSBhbmQgaXQgYnJlYWtz IGludGVyb3BlcmFiaWxpeTogaXQgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBzdGFuZGFyZGl6YXRp b24uDQoNCkkgaGF2ZSBzdGFydGVkIGZlZWxpbmcgdGhhdCBubyBjaGFuZ2UgaXMgdGhlIGJlc3Qg d2F5IG91dC4NCg0KTmF0DQoNClsxXSAgSWYgaW5zdGVhZCBvZiBzYXlpbmcgIlRva2VuIGVuZHBv aW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gZ3Jh bnQgZm9yIGFuIGFjY2VzcyB0b2tlbiwgdHlwaWNhbGx5IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0 aW9uIiwgaXQgd2VyZSBzYXlpbmcgIlRva2VuIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgY2xpZW50 IHRvIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgZm9yIHRva2VucywgdHlwaWNhbGx5 IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0aW9uIiwgdGhlbiBpdCB3b3VsZCBoYXZlIGJlZW4gT0su IEl0IGlzIGFuIGV4cGFuc2lvbiBvZiB0aGUgY2FwYWJpbGl0eSByYXRoZXIgdGhhbiBjaGFuZ2lu ZyB0aGUgc2VtYW50aWNzLg0KDQoNCjIwMTQtMDctMjMgMTM6MzkgR01ULTA0OjAwIE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPj46DQpZb3UgbmVlZCB0aGUgYWx0ZXJuYXRpdmUgcmVzcG9uc2VfdHlwZSB2YWx1 ZSAoImNvZGVfZm9yX2lkX3Rva2VuIiBpbiB0aGUgQTRDIGRyYWZ0KSB0byB0ZWxsIHRoZSBBdXRo b3JpemF0aW9uIFNlcnZlciB0byByZXR1cm4gYSBjb2RlIHRvIGJlIHVzZWQgd2l0aCB0aGUgbmV3 IGdyYW50IHR5cGUsIHJhdGhlciB0aGFuIG9uZSB0byB1c2Ugd2l0aCB0aGUgImF1dGhvcml6YXRp b25fY29kZSIgZ3JhbnQgdHlwZSAod2hpY2ggaXMgd2hhdCByZXNwb25zZV90eXBlPWNvZGUgZG9l cykuDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNClNlbnQ6 IFdlZG5lc2RheSwgSnVseSAyMywgMjAxNCAxMDozMyBBTQ0KVG86IHRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4NCg0KQ2M6IG9hdXRoQGlldGYu b3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50 eHQNCg0KDQoNCklmIHdlIHVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgdGhlbiBhIG5ldyBncmFudF90 eXBlIGlzIHRoZSBiZXN0IHdheS4NCg0KSXQgc29ydCBvZiBvdmVybG9hZHMgY29kZSwgYnV0IHRo YXQgaXMgYmV0dGVyIHRoYW4gbWVzc2luZyB3aXRoIHJlc3BvbnNlX3R5cGUgZm9yIHRoZSBhdXRo b3JpemF0aW9uIGVuZHBvaW50IHRvIGNoYW5nZSB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgdG9rZW5f ZW5kcG9pbnQuICBUaGF0IGlzIGluIG15IG9waW5pb24gYSBjaGFtcGlvbiBiYWQgaWRlYS4NCg0K SW4gZGlzY3Vzc2lvbnMgZGV2ZWxvcGluZyBDb25uZWN0IHdlIGRlY2lkZWQgbm90IHRvIG9wZW4g dGhpcyBjYW4gb2Ygd29ybXMgYmVjYXVzZSBubyBnb29kIHdvdWxkIGNvbWUgb2YgaXQuDQoNClRo ZSB0b2tlbl9lbmRwb2ludCByZXR1cm5zIGEgYWNjZXNzIHRva2VuLiAgTm90aGluZyByZXF1aXJl cyBzY29wZSB0byBiZSBhc3NvY2lhdGVzIHdpdGggdGhlIHRva2VuLg0KDQpUaGF0IGlzIHRoZSBi ZXN0IHNvbHV0aW9uLiAgTm8gY2hhbmdlIHJlcXVpcmVkLiAgQmV0dGVyIGludGVyb3BlcmFiaWxp dHkgaW4gbXkgb3Bpbmlvbi4NCg0KU3RpbGwgb24gbXkgd2F5IHRvIFRPLCBnZXR0aW5nIGluIGxh dGVyIHRvZGF5Lg0KDQpKb2huIEIuDQoNCg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIEp1 bCAyMywgMjAxNCwgYXQgMTI6MTUgUE0sIHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6DQoNClRoZSAicmVzcG9uc2UgdHlwZSIgb2Yg dGhlIHRva2VuIGVuZHBvaW50IGlzIGNvbnRyb2xsZWQgYnkgdGhlIHZhbHVlIG9mIHRoZSBwYXJh bWV0ZXIgImdyYW50X3R5cGUiLiBTbyB0aGVyZSBpcyBubyBuZWVkIHRvIGludHJvZHVjZSBhIG5l dyBwYXJhbWV0ZXIuDQoNCndydCB0byBhIHBvdGVudGlhbCAibm9fYWNjZXNzX3Rva2VuIiBncmFu dCB0eXBlLiBJIGRvIG5vdCBjb25zaWRlciB0aGlzIGEgZ29vZCBpZGVhIGFzIGl0IGNoYW5nZXMg dGhlIHNlbWFudGljcyBvZiB0aGUgdG9rZW4gZW5kcG9pbnQgKGFzIGFscmVhZHkgcG9pbnRlZCBv dXQgYnkgVGhvbWFzKS4gVGhpcyBlbmRwb2ludCBBTFdBWVMgcmVzcG9uZHMgd2l0aCBhbiBhY2Nl c3MgdG9rZW4gdG8gYW55IGdyYW50IHR5cGUuIEkgdGhlcmVmb3JlIHdvdWxkIHByZWZlciB0byB1 c2UgYW5vdGhlciBlbmRwb2ludCBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UuDQoNCnJlZ2FyZHMs DQpUb3JzdGVuLg0KDQoNCg0KQW0gMjMuMDcuMjAxNCAxMzowNCwgc2NocmllYiBOYXQgU2FraW11 cmE6DQpJTUhPLCBjaGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mICJyZXNwb25zZV90eXBlIiBAIGF1 dGh6IGVuZHBvaW50IHRoaXMgd2F5IGlzIG5vdCBhIGdvb2QgdGhpbmcuDQoNCkluc3RlYWQsIGRl ZmluaW5nIGEgbmV3IHBhcmFtZXRlciAicmVzcG9uc2VfdHlwZSIgQCB0b2tlbiBlbmRwb2ludCwg YXMgSSBkZXNjcmliZWQgaW4gbXkgcHJldmlvdXMgbWVzc2FnZSwNCnByb2JhYmx5IGlzIGJldHRl ci4gQXQgbGVhc3QsIGl0IGRvZXMgbm90IGNoYW5nZSB0aGUgc2VtYW50aWNzIG9mIHRoZSBwYXJh bWV0ZXJzIG9mIFJGQzY3NDkuDQoNCiBOYXQNCg0KMjAxNC0wNy0yMyAxMjo0OCBHTVQtMDQ6MDAg VGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPG1haWx0bzp0LmJyb3llckBnbWFpbC5j b20+PjoNCk5vLCBJIG1lYW4gcmVzcG9uc2VfdHlwZT1ub25lIGFuZCByZXNwb25zZV90eXBlPWlk X3Rva2VuIGRvbid0IGdlbmVyYXRlIGEgY29kZSBvciBhY2Nlc3MgdG9rZW4gc28geW91IGRvbid0 IHVzZSB0aGUgVG9rZW4gRW5kcG9pbnQgKHdoaWNoIGlzIG5vdCB0aGUgc2FtZSBhcyB0aGUgQXV0 aGVudGljYXRpb24gRW5kcG9pbnQgQlRXKS4NCldpdGggcmVzcG9uc2VfdHlwZT1jb2RlX2Zvcl9p ZF90b2tlbiwgeW91IGdldCBhIGNvZGUgYW5kIGV4Y2hhbmdlIGl0IGZvciBhbiBpZF90b2tlbiBv bmx5LCByYXRoZXIgdGhhbiBhbiBhY2Nlc3NfdG9rZW4sIHNvIHlvdSdyZSBjaGFuZ2luZyB0aGUg c2VtYW50aWNzIG9mIHRoZSBUb2tlbiBFbmRwb2ludC4NCg0KSSdtIG5vdCBzYXlpbmcgaXQncyBh IGJhZCB0aGluZywganVzdCB0aGF0IHlvdSBjYW4ndCByZWFsbHkgY29tcGFyZSBub25lIGFuZCBp ZF90b2tlbiB3aXRoIGNvZGVfZm9yX2lkX3Rva2VuLg0KDQpPbiBXZWQsIEp1bCAyMywgMjAxNCBh dCA2OjQ1IFBNLCBSaWNoZXIsIEp1c3RpbiBQLiA8anJpY2hlckBtaXRyZS5vcmc8bWFpbHRvOmpy aWNoZXJAbWl0cmUub3JnPj4gd3JvdGU6DQpJdCdzIG9ubHkgIm5vdCB1c2luZyB0aGUgdG9rZW4g ZW5kcG9pbnQiIGJlY2F1c2UgdGhlIHRva2VuIGVuZHBvaW50IGNvcHktcGFzdGVkIGFuZCByZW5h bWVkIHRoZSBhdXRoZW50aWNhdGlvbiBlbmRwb2ludC4NCg0KIC0tIEp1c3Rpbg0KDQpPbiBKdWwg MjMsIDIwMTQsIGF0IDk6MzAgQU0sIFRob21hcyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxt YWlsdG86dC5icm95ZXJAZ21haWwuY29tPj4gd3JvdGU6DQoNCkV4Y2VwdCB0aGF0IHRoZXNlIGFy ZSBhYm91dCBub3QgdXNpbmcgdGhlIFRva2VuIEVuZHBvaW50IGF0IGFsbCwgd2hlcmVhcyB0aGUg Y3VycmVudCBwcm9wb3NhbCBpcyBhYm91dCB0aGUgVG9rZW4gRW5kcG9pbnQgbm90IHJldHVybmlu ZyBhbiBhY2Nlc3NfdG9rZW4gZmllbGQgaW4gdGhlIEpTT04uDQoNCk9uIFdlZCwgSnVsIDIzLCAy MDE0IGF0IDQ6MjYgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxt YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUaGUgcmVzcG9uc2Vf dHlwZSAibm9uZSIgaXMgYWxyZWFkeSB1c2VkIGluIHByYWN0aWNlLCB3aGljaCByZXR1cm5zIG5v IGFjY2VzcyB0b2tlbi4gIEl0IHdhcyBhY2NlcHRlZCBieSB0aGUgZGVzaWduYXRlZCBleHBlcnRz IGFuZCByZWdpc3RlcmVkIGluIHRoZSBJQU5BIE9BdXRoIEF1dGhvcml6YXRpb24gRW5kcG9pbnQg UmVzcG9uc2UgVHlwZXMgcmVnaXN0cnkgYXQgaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50 cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueG1sI2VuZHBvaW50LiAgVGhlIHJl Z2lzdGVyZWQgImlkX3Rva2VuIiByZXNwb25zZSB0eXBlIGFsc28gcmV0dXJucyBubyBhY2Nlc3Mg dG9rZW4uDQoNClNvIEkgdGhpbmsgdGhlIHF1ZXN0aW9uIG9mIHdoZXRoZXIgcmVzcG9uc2UgdHlw ZXMgdGhhdCByZXN1bHQgaW4gbm8gYWNjZXNzIHRva2VuIGJlaW5nIHJldHVybmVkIGFyZSBhY2Nl cHRhYmxlIHdpdGhpbiBPQXV0aCAyLjAgaXMgYWxyZWFkeSBzZXR0bGVkLCBhcyBhIHByYWN0aWNh bCBtYXR0ZXIuICBMb3RzIG9mIE9BdXRoIGltcGxlbWVudGF0aW9ucyBhcmUgYWxyZWFkeSB1c2lu ZyBzdWNoIHJlc3BvbnNlIHR5cGVzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5d IE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMywgMjAxNCA3 OjA5IEFNDQpUbzogTmF0IFNha2ltdXJhDQpDYzogPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0 aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0DQoNClllcy4gVGhp cyBpcyB3aHkgaXQgaGFzIHRvIGJlIGRpc2N1c3NlZCBpbiB0aGUgSUVURi4NCg0KUGhpbA0KDQpA aW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRl bnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tPg0KDQoNCg0KT24gSnVsIDIzLCAyMDE0LCBhdCA5OjQzIEFNLCBOYXQgU2FraW11cmEgPHNh a2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQoNClJl YWRpbmcgYmFjayB0aGUgUkZDNjc0OSwgSSBhbSBub3Qgc3VyZSBpZiB0aGVyZSBpcyBhIGdvb2Qg d2F5IG9mIHN1cHByZXNzaW5nIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSByZXNwb25zZSBhbmQgc3Rp bGwgYmUgT0F1dGguIEl0IHdpbGwgYnJlYWsgd2hvbGUgYnVuY2ggb2YgaW1wbGljaXQgZGVmaW5p dGlvbnMgbGlrZToNCg0KYXV0aG9yaXphdGlvbiBzZXJ2ZXINCiAgICAgIFRoZSBzZXJ2ZXIgaXNz dWluZyBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0ZXIgc3VjY2Vzc2Z1bGx5DQogICAg ICBhdXRoZW50aWNhdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIG9idGFpbmluZyBhdXRob3Jp emF0aW9uLg0KDQpBZnRlciBhbGwsIE9BdXRoIGlzIGFsbCBhYm91dCBpc3N1aW5nIGFjY2VzcyB0 b2tlbnMuDQoNCkFsc28sIEkgdGFrZSBiYWNrIG15IHN0YXRlbWVudCBvbiB0aGUgZ3JhbnQgdHlw ZSBpbiBteSBwcmV2aW91cyBtYWlsLg0KDQpUaGUgZGVmaW5pdGlvbiBvZiBncmFudCBhbmQgZ3Jh bnRfdHlwZSBhcmUgcmVzcGVjdGl2ZWx5Og0KDQpncmFudA0KICAgIGNyZWRlbnRpYWwgcmVwcmVz ZW50aW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGF1dGhvcml6YXRpb24NCg0KZ3JhbnRfdHlwZQ0K ICAgIChzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSkgdHlwZSBvZiBncmFudCBzZW50IHRvIHRoZSB0 b2tlbiBlbmRwb2ludCB0byBvYnRhaW4gdGhlIGFjY2VzcyB0b2tlbg0KDQpUaHVzLCB0aGUgZ3Jh bnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgaW4gdGhpcyBjYXNlIGlzIHN0aWxsICdjb2Rl Jy4NCg0KUmVzcG9uc2UgdHlwZSBvbiB0aGUgb3RoZXIgaGFuZCBpcyBub3Qgc28gd2VsbCBkZWZp bmVkIGluIFJGQzY3NDksIGJ1dCBpdCBzZWVtcyBpdCBpcyByZXByZXNlbnRpbmcgd2hhdCBpcyB0 byBiZSByZXR1cm5lZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBUbyBleHByZXNz IHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0b2tlbiBlbmRwb2ludCwgcGVyaGFwcyBkZWZp bmluZyBhIG5ldyBwYXJhbWV0ZXIgdG8gdGhlIHRva2VuIGVuZHBvaW50LCB3aGljaCBpcyBhIHBh cmFsbGVsIHRvIHRoZSByZXNwb25zZV90eXBlIHRvIHRoZSBBdXRob3JpemF0aW9uIEVuZHBvaW50 IHNlZW1zIHRvIGJlIGEgbW9yZSBzeW1tZXRyaWMgd2F5LCB0aG91Z2ggSSBhbSBub3Qgc3VyZSBh dCBhbGwgaWYgdGhhdCBpcyBnb2luZyB0byBiZSBPQXV0aCBhbnkgbW9yZS4gT25lIHN0cmF3LW1h biBpcyB0byBkZWZpbmUgYSBuZXcgcGFyYW1ldGVyIGNhbGxlZCByZXNwb25zZV90eXBlIHRvIHRo ZSB0b2tlbiBlbmRwb2ludCBzdWNoIGFzOg0KDQpyZXNwb25zZV90eXBlDQogICAgT1BUSU9OQUwu IEEgc3RyaW5nIHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlIHRv a2VuIGVuZHBvaW50Lg0KDQpUaGVuIGRlZmluZSB0aGUgYmVoYXZpb3Igb2YgdGhlIGVuZHBvaW50 IGFjY29yZGluZyB0byB0aGUgdmFsdWVzIGFzIHRoZSBwYXJhbGxlbCB0byB0aGUgbXVsdGktcmVz cG9uc2UgdHlwZSBzcGVjLg0KaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb2F1dGgtdjItbXVsdGlw bGUtcmVzcG9uc2UtdHlwZXMtMV8wLmh0bWwNCg0KTmF0DQoNCg0KDQoNCjIwMTQtMDctMjMgNzoy MSBHTVQtMDQ6MDAgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20+PjoNClRoZSBkcmFmdCBpcyB2ZXJ5IGNsZWFyLg0KDQpQaGlsDQoNCk9u IEp1bCAyMywgMjAxNCwgYXQgMDo0NiwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208 bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhlIG5ldyBncmFudCB0eXBlIHRo YXQgSSB3YXMgdGFsa2luZyBhYm91dCB3YXMNCiJhdXRob3JpemF0aW9uX2NvZGVfYnV0X2RvX25v dF9yZXR1cm5fYWNjZXNzX25vcl9yZWZyZXNoX3Rva2VuIiwgc28gdG8gc3BlYWsuDQpJdCBkb2Vz IG5vdCByZXR1cm4gYW55dGhpbmcgcGVyIHNlLCBidXQgYW4gZXh0ZW5zaW9uIGNhbiBkZWZpbmUg c29tZXRoaW5nIG9uIHRvcCBvZiBpdC4NCg0KVGhlbiwgT0lEQyBjYW4gZGVmaW5lIGEgYmluZGlu ZyB0byBpdCBzbyB0aGF0IHRoZSBiaW5kaW5nIG9ubHkgcmV0dXJucyBJRCBUb2tlbi4NClRoaXMg YmluZGluZyB3b3JrIHNob3VsZCBiZSBkb25lIGluIE9JREYuIFNob3VsZCB0aGVyZSBiZSBzdWNo IGEgZ3JhbnQgdHlwZSwNCml0IHdpbGwgYmUgYW4gZXh0cmVtZWx5IHNob3J0IHNwZWMuDQoNCkF0 IHRoZSBzYW1lIHRpbWUsIGlmIGFueSBvdGhlciBzcGVjaWZpY2F0aW9uIHdhbnRlZCB0byBkZWZp bmUNCm90aGVyIHR5cGUgb2YgdG9rZW5zIGFuZCBoYXZlIGl0IHJldHVybmVkIGZyb20gdGhlIHRv a2VuIGVuZHBvaW50LA0KaXQgY2FuIGFsc28gdXNlIHRoaXMgZ3JhbnQgdHlwZS4NCg0KSWYgd2hh dCB5b3Ugd2FudCBpcyB0byBkZWZpbmUgYSBuZXcgZ3JhbnQgdHlwZSB0aGF0IHJldHVybnMgSUQg VG9rZW4gb25seSwNCnRoZW4sIEkgYW0gd2l0aCBKdXN0aW4uIFNpbmNlICJvdGhlciByZXNwb25z ZSB0aGFuIElEIFRva2VuIiBpcyBvbmx5DQp0aGVvcmV0aWNhbCwgdGhpcyBpcyBhIG1vcmUgcGxh dXNpYmxlIHdheSBmb3J3YXJkLCBJIHN1cHBvc2UuDQoNCk5hdA0KDQoyMDE0LTA3LTIyIDE0OjMw IEdNVC0wNDowMCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJA bWl0LmVkdT4+Og0KU28gdGhlIGRyYWZ0IHdvdWxkIGxpdGVyYWxseSB0dXJuIGludG86DQoNCiJU aGUgYTRjIHJlc3BvbnNlIHR5cGUgYW5kIGdyYW50IHR5cGUgcmV0dXJuIGFuIGlkX3Rva2VuIGZy b20gdGhlIHRva2VuIGVuZHBvaW50IHdpdGggbm8gYWNjZXNzIHRva2VuLiBBbGwgcGFyYW1ldGVy cyBhbmQgdmFsdWVzIGFyZSBkZWZpbmVkIGluIE9JREMuIg0KDQpTZWVtcyBsaWtlIHRoZSBwZXJm ZWN0IG1pbmkgZXh0ZW5zaW9uIGRyYWZ0IGZvciBPSURGIHRvIGRvLg0KDQotLUp1c3Rpbg0KDQov c2VudCBmcm9tIG15IHBob25lLw0KDQpPbiBKdWwgMjIsIDIwMTQgMTA6MjkgQU0sIE5hdCBTYWtp bXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90 ZToNCj4NCj4gV2hhdCBhYm91dCBqdXN0IGRlZmluaW5nIGEgbmV3IGdyYW50IHR5cGUgaW4gdGhp cyBXRz8NCj4NCj4NCj4gMjAxNC0wNy0yMiAxMjo1NiBHTVQtMDQ6MDAgUGhpbCBIdW50IDxwaGls Lmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PjoNCj4+DQo+PiBU aGF0IHdvdWxkIGJlIG5pY2UuIEhvd2V2ZXIgb2lkYyBzdGlsbCBuZWVkcyB0aGUgbmV3IGdyYW50 IHR5cGUgaW4gb3JkZXIgdG8gaW1wbGVtZW50IHRoZSBzYW1lIGZsb3cuDQo+Pg0KPj4gUGhpbA0K Pj4NCj4+IE9uIEp1bCAyMiwgMjAxNCwgYXQgMTE6MzUsIE5hdCBTYWtpbXVyYSA8c2FraW11cmFA Z21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCj4+DQo+Pj4gKzEg dG8gSnVzdGluLg0KPj4+DQo+Pj4NCj4+PiAyMDE0LTA3LTIyIDk6NTQgR01ULTA0OjAwIFJpY2hl ciwgSnVzdGluIFAuIDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+ PjoNCj4+Pj4NCj4+Pj4gRXJyb3JzIGxpa2UgdGhlc2UgbWFrZSBpdCBjbGVhciB0byBtZSB0aGF0 IGl0IHdvdWxkIG1ha2UgbXVjaCBtb3JlIHNlbnNlIHRvIGRldmVsb3AgdGhpcyBkb2N1bWVudCBp biB0aGUgT3BlbklEIEZvdW5kYXRpb24uIEl0IHNob3VsZCBiZSBzb21ldGhpbmcgdGhhdCBkaXJl Y3RseSByZWZlcmVuY2VzIE9wZW5JRCBDb25uZWN0IENvcmUgZm9yIGFsbCBvZiB0aGVzZSB0ZXJt cyBpbnN0ZWFkIG9mIHJlZGVmaW5pbmcgdGhlbS4gSXQncyBkb2luZyBhdXRoZW50aWNhdGlvbiwg d2hpY2ggaXMgZnVuZGFtZW50YWxseSB3aGF0IE9wZW5JRCBDb25uZWN0IGRvZXMgb24gdG9wIG9m IE9BdXRoLCBhbmQgSSBkb24ndCBzZWUgYSBnb29kIGFyZ3VtZW50IGZvciBkb2luZyB0aGlzIHdv cmsgaW4gdGhpcyB3b3JraW5nIGdyb3VwLg0KPj4+Pg0KPj4+PiAgLS0gSnVzdGluDQo+Pj4+DQo+ Pj4+IE9uIEp1bCAyMiwgMjAxNCwgYXQgNDozMCBBTSwgVGhvbWFzIEJyb3llciA8dC5icm95ZXJA Z21haWwuY29tPG1haWx0bzp0LmJyb3llckBnbWFpbC5jb20+PiB3cm90ZToNCj4+Pj4NCj4+Pj4+ DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE9uIE1vbiwgSnVsIDIxLCAyMDE0IGF0IDExOjUyIFBNLCBN aWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4gVGhhbmtzIGZvciB5b3Vy IHJldmlldywgVGhvbWFzLiAgVGhlICJwcm9tcHQ9Y29uc2VudCIgZGVmaW5pdGlvbiBiZWluZyBt aXNzaW5nIGlzIGFuIGVkaXRvcmlhbCBlcnJvci4gIEl0IHNob3VsZCBiZToNCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBjb25zZW50DQo+Pj4+Pj4NCj4+Pj4+PiBUaGUgQXV0aG9yaXph dGlvbiBTZXJ2ZXIgU0hPVUxEIHByb21wdCB0aGUgRW5kLVVzZXIgZm9yIGNvbnNlbnQgYmVmb3Jl IHJldHVybmluZyBpbmZvcm1hdGlvbiB0byB0aGUgQ2xpZW50LiBJZiBpdCBjYW5ub3Qgb2J0YWlu IGNvbnNlbnQsIGl0IE1VU1QgcmV0dXJuIGFuIGVycm9yLCB0eXBpY2FsbHkgY29uc2VudF9yZXF1 aXJlZC4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBJJ2xsIHBsYW4gdG8gYWRkIGl0 IGluIHRoZSBuZXh0IGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBJdCBsb29rcyBsaWtlIHRo ZSBjb25zZW50X3JlcXVpcmVkIGVycm9yIG5lZWRzIHRvIGJlIGRlZmluZWQgdG9vLCBhbmQgeW91 IG1pZ2h0IGhhdmUgZm9yZ290dGVuIHRvIGFsc28gaW1wb3J0IGFjY291bnRfc2VsZWN0aW9uX3Jl cXVpcmVkIGZyb20gT3BlbklEIENvbm5lY3QuDQo+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+ Pg0KPj4+Pj4+IEkgYWdyZWUgdGhhdCB0aGVyZSdzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJl c3BvbnNlIHdpdGggbXVsdGlwbGUgImFtciIgdmFsdWVzIHRoYXQgaW5jbHVkZXMgIm1mYSIgYW5k IG9uZSB0aGF0IGRvZXNuJ3QuICBVbmxlc3MgYSBjbGVhciB1c2UgY2FzZSBmb3Igd2h5ICJtZmEi IGlzIG5lZWRlZCBjYW4gYmUgaWRlbnRpZmllZCwgd2UgY2FuIGRlbGV0ZSBpdCBpbiB0aGUgbmV4 dCBkcmFmdC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzLg0KPj4+Pj4NCj4+Pj4+IEhvdyBh Ym91dCAicHdkIiB0aGVuPyBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhhdCBJIHNob3VsZCByZXR1cm4g InB3ZCIgaWYgdGhlIHVzZXIgYXV0aGVudGljYXRlZCB1c2luZyBhIHBhc3N3b3JkLCBidXQgd2hh dCAidGhlIHNlcnZpY2UgaWYgYSBjbGllbnQgc2VjcmV0IGlzIHVzZWQiIG1lYW5zIGluIHRoZSBk ZWZpbml0aW9uIGZvciB0aGUgInB3ZCIgdmFsdWU/DQo+Pj4+Pg0KPj4+Pj4gKE5vdGE6IEkga25v dyB5b3UncmUgYXQgSUVURi05MCwgSSdtIHJlYWR5IHRvIHdhaXQgJ3RpbCB5b3UgY29tZSBiYWNr IDstKSApDQo+Pj4+Pg0KPj4+Pj4gLS0NCj4+Pj4+IFRob21hcyBCcm95ZXINCj4+Pj4+IC90yZQu bWEuYsqBd2EuamUvPGh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhiLmplLz4NCj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBPQXV0 aCBtYWlsaW5nIGxpc3QNCj4+Pj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4+ Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+IE9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aA0KPj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IC0tDQo+Pj4gTmF0IFNh a2ltdXJhICg9bmF0KQ0KPj4+IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KPj4+IGh0dHA6 Ly9uYXQuc2FraW11cmEub3JnLw0KPj4+IEBfbmF0X2VuDQo+Pj4NCj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE9BdXRoIG1haWxpbmcgbGlz dA0KPj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+DQo+DQo+DQo+DQo+IC0tDQo+ IE5hdCBTYWtpbXVyYSAoPW5hdCkNCj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQo+IGh0 dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPiBAX25hdF9lbg0KDQoNCg0KLS0NCk5hdCBTYWtpbXVy YSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVy YS5vcmcvDQpAX25hdF9lbg0KDQoNCg0KLS0NCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFu LCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQpAX25hdF9lbg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpUaG9t YXMgQnJveWVyDQovdMmULm1hLmLKgXdhLmplLzxodHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4 Yi5qZS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0K VGhvbWFzIEJyb3llcg0KL3TJlC5tYS5iyoF3YS5qZS88aHR0cDovL3huLS1ubmEubWEueG4tLWJ3 YS14eGIuamUvPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0K DQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpo dHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoN Cg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9u DQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFp cm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRf ZW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQoNCg0KLS0NCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFuLCBP cGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQpAX25hdF9lbg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_9dbf8c7384e341a08334a9ee093697f8BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZbSBzdXJlIGl0IHdhcyBzcHVuIGluIGEg d2F5IHRoYXQgY291bGQgYmUgdHJ1ZSBzaW5jZSB0aGVyZSB3YXMgbm8gdGVjaG5pY2FsIHZhbHVl IHRvIElhbuKAmXMgc3RhdGVtZW50IGFuZCBJ4oCZbSBzdXJlIHRoYXQgZm9sa3MgaGFkIG5vdCBy ZWFkIG9yIHVuZGVyc3RhbmQgdGhlDQogdXNhZ2UuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv YT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBb bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFu IENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDI0LCAyMDE0IDY6NTMg QU08YnI+DQo8Yj5Ubzo8L2I+IE5hdCBTYWtpbXVyYTxicj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0 Zi5vcmcgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdkIG5vdGUgdGhhdCB0aGUgcmVh Y3Rpb24gYXQgdGhlIGNvbmZlcmVuY2UgdG8gSWFuJ3Mgc3RhdGVtZW50IHdhcyBvdmVyd2hlbG1p bmdseSBwb3NpdGl2ZS4gVGhlcmUgd2FzIGEgd2lkZSByYW5nZSBvZiBpbmR1c3RyeSBwZW9wbGUg aGVyZSAtIGltcGxlbWVudGVycywgcHJhY3RpdGlvbmVycywgZGVwbG95ZXJzLCBzdHJhdGVnaXN0 cywgZXRjLiAtIGFuZCBpdCBzZWVtcyBwcmV0dHkgY2xlYXIgdGhhdCB0aGUNCiAmcXVvdDtyb3Vn aCBjb25zZW5zdXMmcXVvdDsgb2YgdGhlIGluZHVzdHJ5IGF0IGxhcmdlIGlzIHRoYXQgYTRjIGlz IG5vdCB3YW50ZWQgb3IgbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAyNCwg MjAxNCBhdCA1OjI5IEFNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVy YUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QW5kIGhlcmUgaXMgYSBxdW90ZSBmcm9tIElhbidzIGJsb2cuJm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgYWx0aG91Z2gg dGhlIGF1dGhlbnRpY2F0aW9uIHdoZWVsIGlzIHJvdW5kLCB0aGF0IGRvZXNu4oCZdCBtZWFuIGl0 IGlzbuKAmXQgd2l0aG91dCBpdHMgbHVtcHMuIEZpcnN0LCB3ZSBkbyBzZWUgc29tZSByZWludmVu dGluZyB0aGUgd2hlZWwganVzdCB0byByZWludmVudCB0aGUgd2hlZWwuIE9BdXRoIEE0QyBpcyBz aW1wbHkgbm90IGEgZnJ1aXRmdWwgYWN0aXZpdHkgYW5kIHNob3VsZCBiZSBwdXQgZG93bi4gJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4oU291cmNlKSA8YSBocmVmPSJodHRwOi8vd3d3LnR1ZXNkYXluaWdodC5v cmcvMjAxNC8wNy8yMy9kby13ZS1oYXZlLWEtcm91bmQtd2hlZWwteWV0LW11c2luZ3Mtb24taWRl bnRpdHktc3RhbmRhcmRzLXBhcnQtMS5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3 LnR1ZXNkYXluaWdodC5vcmcvMjAxNC8wNy8yMy9kby13ZS1oYXZlLWEtcm91bmQtd2hlZWwteWV0 LW11c2luZ3Mtb24taWRlbnRpdHktc3RhbmRhcmRzLXBhcnQtMS5odG1sPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE0LTA3LTIzIDE2OjUzIEdNVC0wNDowMCBKb2huIEJy YWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aG91Z2h0IEkgZGlkIHBv c3QgdGhpcyB0byB0aGUgbGlzdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBndWVzcyBJIGhpdCB0aGUgd3JvbmcgcmVwbHkgb24g bXkgcGhvbmUuJm5ic3A7PGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLiZuYnNwOzxicj4NClNlbnQgZnJv bSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBKdWwg MjMsIDIwMTQsIGF0IDQ6NTAgUE0sIDxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cD53ZSBhcmUgdHdvLCBhdCBsZWFz dCA6LSk8bzpwPjwvbzpwPjwvcD4NCjxwPldoeSBkaWRuJ3QgeW91IHBvc3QgdGhpcyBvbiB0aGUg bGlzdD88bzpwPjwvbzpwPjwvcD4NCjxwPldoZW4gd2lsbCBiZSBiZSBhcnJpdmluZz88bzpwPjwv bzpwPjwvcD4NCjxwPkFtIDIzLjA3LjIwMTQgMTY6MzksIHNjaHJpZWIgSm9obiBCcmFkbGV5Ojxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVm dDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JYW4gR2xhemVyIG1lbnRpb25lZCB0aGlzIGluIGhpcyBrZXlu b3RlIGF0IENJUyB5ZXN0ZXJkYXkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpcyBhZHZpY2Ugd2FzIHBsZWFzZSBzdG9wLCAmbmJz cDt3ZSBhcmUgY3JlYXRpbmcgY29uZnVzaW9uIGFuZCB1bmNlcnRhaW50eS4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgYXJlIGJl Y29taW5nIG91ciBvd24gd29ydCBlbmVteS4gKCBteSB2aWV3IHRob3VnaCBJYW4gbWF5IHNoYXJl IGl0KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5SZXR1cm5pbmcganVzdCBhbiBpZF8gdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgaGFz IGxpdHRsZSByZWFsIHZhbHVlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21ldGhpbmcgcmVhbGx5IHVzZWZ1bCB0byBkbyB3b3Vs ZCBiZSBzb3J0aW5nIG91dCBjaGFubmVsX2lkIHNvIHdlIGNhbiBkbyBQb1AgZm9yIGlkIHRva2Vu cyB0byBtYWtlIHRoZW0gYW5kIG90aGVyIGNvb2tpZXMgc2VjdXJlIGluIHRoZSBmcm9udCBjaGFu bmVsLiAmbmJzcDsgSSB0aGluayB0aGF0IGlzIGEgYmV0dGVyIHVzZSBvZiB0aW1lLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG1h eSBiZSBpbiB0aGUgbWlub3JpdHkgb3BpbmlvbiBvbiB0aGF0LCAmbmJzcDtpdCB3b24ndCBiZSB0 aGUgZmlyc3QgdGltZS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KSm9obiBCLiZuYnNwOzxicj4NClNlbnQgZnJvbSBteSBpUGhv bmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9u IEp1bCAyMywgMjAxNCwgYXQgNDowNCBQTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+WW91IGFyZSByaWdodCBmcm9tIGEgdGhlb3JldGljYWwgcGVyc3BlY3RpdmUu IFByYWN0aWNhbGx5IHRoaXMgd2FzIGNhdXNlZCBieSBlZGl0b3JpYWwgZGVjaXNpb25zIGR1cmlu ZyB0aGUgY3JlYXRpb24gb2YgdGhlIFJGQy4gQXMgZmFyIGFzIEkgcmVtZW1iZXIsIHRoZXJlIHdh cyBhIGRlZmluaXRpb24gb2YgdGhlIChvbmUpIHRva2VuIGVuZHBvaW50IHJlc3BvbnNlIGluIGVh cmx5IHZlcnNpb25zLiBObyBvbmUNCiBldmVyeSBjb25zaWRlcmVkIHRvIE5PVCByZXNwb25kIHdp dGggYW4gYWNjZXNzIHRva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LiBTbyBvbmUgbWlnaHQg Y2FsbCBpdCBhbiBpbXBsaWNpdCBhc3N1bXB0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gd29ycmllZCB0aGF0IHBlb3BsZSBnZXQg dG90YWxseSBjb25mdXNlZCBpZiBhbiBleGNlcHRpb24gaXMgaW50cm9kdWNlZCBub3cgZ2l2ZW4g dGhlIGJyb2FkIGFkb3B0aW9uIG9mIE9BdXRoIGJhc2VkIG9uIHRoaXMgYXNzdW1wdGlvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVnYXJk cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRv cnN0ZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkFtIDIzLjA3LjIwMTQgdW0gMTU6 NDEgc2NocmllYiBUaG9tYXMgQnJveWVyICZsdDs8YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDs6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2lu LWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHA+SXMgaXQgc2FpZCBhbnl3aGVyZSB0aGF0IEFMTCBncmFudCB0eXBlcyBNVVNUIHVzZSBT ZWN0aW9uIDUuMSByZXNwb25zZXM/IEVhY2ggZ3JhbnQgdHlwZSByZWZlcmVuY2VzIFNlY3Rpb24g NS4xLCBhbmQgJnF1b3Q7YWNjZXNzIHRva2VuIHJlcXVlc3QmcXVvdDsgaXMgb25seSBkZWZpbmVk IGluIHRoZSBjb250ZXh0IG9mIHRoZSBkZWZpbmVkIGdyYW50IHR5cGVzLiBTZWN0aW9uIDIuMiBk b2Vzbid0IHRhbGsgYWJvdXQgdGhlIHJlcXVlc3Qgb3IgcmVzcG9uc2UNCiBmb3JtYXQuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGUgMjMganVpbC4gMjAxNCAy MTozMiwgJnF1b3Q7TmF0IFNha2ltdXJhJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11 cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsg YSDDqWNyaXQgOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JcyBpdD8gQXBhcnQgZnJvbSB0aGUgaW1wbGljaXQgZ3JhbnQgdGhhdCBkb2Vz IG5vdCB1c2UgdG9rZW4gZW5kcG9pbnQsIGFsbCBvdGhlciBncmFudCByZWZlcmVuY2VzIHNlY3Rp b24gNS4xIGZvciB0aGUgcmVzcG9uc2UsIGkuZS4sIGFsbCBzaGFyZXMgdGhlIHNhbWUgcmVzcG9u c2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTQtMDctMjMgMTU6MTggR01ULTA0OjAwIFRo b21hcyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj50LmJyb3llckBnbWFpbC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8cD5JIGhhZG4ndCByZWFsaXplZCB0aGUgSlNPTiByZXNwb25zZSB0aGF0IHJl cXVpcmVzIHRoZSBhY2Nlc3NfdG9rZW4gZmllbGQgaXMgZGVmaW5lZCBwZXIgZ3JhbnRfdHlwZSwg c28gSSdkIGJlIE9LIHRvICZxdW90O2V4dGVuZCB0aGUgc2VtYW50aWNzJnF1b3Q7IGFzIGluIHRo ZSBjdXJyZW50IGRyYWZ0Ljxicj4NClRoYXQgd2FzIGFjdHVhbGx5IG15IG1haW4gY29uY2Vybjog dGhhdCB0aGUgdG9rZW4gZW5kcG9pbnQgbWFuZGF0ZXMgYWNjZXNzX3Rva2VuOyBidXQgaXRzIGFj dHVhbGx5IG5vdCB0aGUgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5MZSAyMyBqdWlsLiAyMDE0IDIwOjQ2LCAmcXVvdDtOYXQgU2FraW11cmEmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5z YWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyBhIMOpY3JpdCA6DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdp dGggSm9obiB0aGF0IG92ZXJsb2FkaW5nIHJlc3BvbnNlX3R5cGUgQCBhdXRoeiBlbmRwb2ludCBp cyBhIGJhZCBpZGVhLiBJdCBjb21wbGV0ZWx5IGNoYW5nZXMgdGhlIHNlbWFudGljcyBvZiB0aGlz IHBhcmFtZXRlci4gTk9URTogd2hhdCBJIHdhcyBwcm9wb3Npbmcgd2FzIG5vdCB0aGlzIHBhcmFt ZXRlciwgYnV0IGEgbmV3IHBhcmFtZXRlciByZXNwb25zZV90eXBlIEAgdG9rZW4gZW5kcG9pbnQu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgYWxzbyB0aGluayBvdmVybG9hZGluZyBncmFudF90eXBlIGlzIGEgYmFkIGlkZWEgc2lu Y2UgaXQgY2hhbmdlcyBpdHMgc2VtYW50aWNzLiBJIHF1b3RlIHRoZSBkZWZpbml0aW9uIGhlcmUg YWdhaW46Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5ncmFudCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBjcmVkZW50aWFsIHJlcHJlc2Vu dGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBhdXRob3JpemF0aW9uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmdyYW50X3R5cGU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnR5cGUgb2YgZ3JhbnQg c2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JdCBpcyBub3QgYWJvdXQgY29udHJvbGxpbmcgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9t IHRoZSB0b2tlbiBlbmRwb2ludCwgYnV0IHRoZSBoaW50IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBk ZXNjcmliaW5nIHRoZSB0eXBlIG9mIGNyZWRlbnRpYWwgdGhlIGVuZHBvaW50IGhhcyByZWNlaXZl ZC4gSXQgc2VlbXMgdGhlICZxdW90O2NvbnRyb2wgb2Ygd2hhdCBpcyBiZWluZyByZXR1cm5lZCBm cm9tIHRva2VuIGVuZHBvaW50JnF1b3Q7DQogJm5ic3A7aXMganVzdCBhIHNpZGUgZWZmZWN0LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGFtIHNvbWV3aGF0IGFtYml2YWxlbnRbMV0gaW4gY2hhbmdpbmcgdGhlIHNlbWFudGljcyBv ZiB0b2tlbiBlbmRwb2ludCwgYnV0IGluIGFzIG11Y2ggYXMgJnF1b3Q7dGV4dCBpcyB0aGUga2lu ZyZxdW90OyBmb3IgYSBzcGVjLiwgd2UgcHJvYmFibHkgc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIHNl bWFudGljcyBvZiBpdCBhcyBUb3JzdGVuIHBvaW50cyBvdXQuIElmIGl0IGlzIG9rIHRvIGNoYW5n ZSB0aGlzIHNlbWFudGljcywgSQ0KIGJlbGlldmUgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVyIHRv IHRoaXMgZW5kcG9pbnQgdG8gY29udHJvbCB0aGUgcmVzcG9uc2Ugd291bGQgYmUgdGhlIGJlc3Qg d2F5IHRvIGdvLiBUaGlzIGlzIHdoYXQgSSBoYXZlIGRlc2NyaWJlZCBwcmV2aW91c2x5LiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5E ZWZpbmluZyBhIG5ldyBlbmRwb2ludCB0byBzZW5kIGNvZGUgdG8gZ2V0IElEIFRva2VuIGFuZCBm b3JiaWRkaW5nIHRoZSB1c2Ugb2YgaXQgYWdhaW5zdCB0b2tlbiBlbmRwb2ludCB3b3VsZCBub3Qg Y2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgYW55IGV4aXN0aW5nIHBhcmFtZXRlciBvciBlbmRwb2lu dCwgd2hpY2ggaXMgZ29vZC4gSG93ZXZlciwgSSBkb3VidCBpZiBpdCBpcyBub3Qgd29ydGggZG9p bmcuIFdoYXQncw0KIHRoZSBwb2ludCBvZiBhdm9pZGluZyBhY2Nlc3MgdG9rZW4gc2NvcGVkIHRv IFVzZXJJbmZvIGVuZHBvaW50IGFmdGVyIGFsbD8gRGVmaW5pbmcgYSBuZXcgZW5kcG9pbnQgZm9y IGp1c3QgYXZvaWRpbmcgdGhlIGFjY2VzcyB0b2tlbiBmb3IgdXNlcmluZm8gZW5kcG9pbnQgc2Vl bXMgd2F5IHRvbyBtdWNoIHRoZSBoZWF2eSB3YWl0IHdheSBhbmQgaXQgYnJlYWtzIGludGVyb3Bl cmFiaWxpeTogaXQgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBzdGFuZGFyZGl6YXRpb24uJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg aGF2ZSBzdGFydGVkIGZlZWxpbmcgdGhhdCBubyBjaGFuZ2UgaXMgdGhlIGJlc3Qgd2F5IG91dC4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TmF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlsxXSAmbmJzcDtJZiBpbnN0ZWFkIG9mIHNheWluZyAmcXVvdDs8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPlRva2VuIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvIGV4Y2hhbmdl IGFuIGF1dGhvcml6YXRpb24mbmJzcDs8L3NwYW4+Z3JhbnQgZm9yIGFuIGFjY2VzcyB0b2tlbiwg dHlwaWNhbGx5IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0aW9uJnF1b3Q7LCBpdCB3ZXJlIHNheWlu ZyAmcXVvdDs8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRva2VuDQogZW5kcG9pbnQgLSB1c2Vk IGJ5IHRoZSBjbGllbnQgdG8gZXhjaGFuZ2UgYW4gYXV0aG9yaXphdGlvbiZuYnNwOzwvc3Bhbj5n cmFudCBmb3IgdG9rZW5zLCB0eXBpY2FsbHkgd2l0aCBjbGllbnQgYXV0aGVudGljYXRpb24mcXVv dDssIHRoZW4gaXQgd291bGQgaGF2ZSBiZWVuIE9LLiBJdCBpcyBhbiBleHBhbnNpb24gb2YgdGhl IGNhcGFiaWxpdHkgcmF0aGVyIHRoYW4gY2hhbmdpbmcgdGhlIHNlbWFudGljcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjIwMTQtMDctMjMgMTM6MzkgR01ULTA0OjAwIE1pa2UgSm9uZXMg Jmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0i X2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdSBuZWVkIHRoZSBhbHRl cm5hdGl2ZSByZXNwb25zZV90eXBlIHZhbHVlICgmcXVvdDs8L3NwYW4+Y29kZV9mb3JfaWRfdG9r ZW48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JnF1b3Q7DQogaW4g dGhlIEE0QyBkcmFmdCkgdG8gdGVsbCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdG8gcmV0dXJu IGEgY29kZSB0byBiZSB1c2VkIHdpdGggdGhlIG5ldyBncmFudCB0eXBlLCByYXRoZXIgdGhhbiBv bmUgdG8gdXNlIHdpdGggdGhlICZxdW90O2F1dGhvcml6YXRpb25fY29kZSZxdW90OyBncmFudCB0 eXBlICh3aGljaCBpcyB3aGF0IHJlc3BvbnNlX3R5cGU9Y29kZSBkb2VzKS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Ryb25n PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L3N0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBCZWhhbGYgT2YgPC9zcGFuPjwvc3Ryb25nPkpv aG4gQnJhZGxleTxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZW50Ojwvc3Bhbj48L3N0cm9uZz4g V2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDEwOjMzIEFNPGJyPg0KPHN0cm9uZz48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlRvOjwvc3Bhbj48L3N0cm9uZz4gPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQu bmV0IiB0YXJnZXQ9Il9ibGFuayI+DQp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT48L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N CjxzdHJvbmc+Q2M6PC9zdHJvbmc+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxzdHJvbmc+U3ViamVjdDo8L3N0 cm9uZz4gUmU6IFtPQVVUSC1XR10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1o dW50LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHdlIHVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgdGhlbiBh IG5ldyBncmFudF90eXBlIGlzIHRoZSBiZXN0IHdheS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IHNvcnQgb2Ygb3Zlcmxv YWRzIGNvZGUsIGJ1dCB0aGF0IGlzIGJldHRlciB0aGFuIG1lc3Npbmcgd2l0aCByZXNwb25zZV90 eXBlIGZvciB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB0byBjaGFuZ2UgdGhlIHJlc3BvbnNl IGZyb20gdGhlIHRva2VuX2VuZHBvaW50LiAmbmJzcDtUaGF0IGlzIGluIG15IG9waW5pb24NCiBh IGNoYW1waW9uIGJhZCBpZGVhLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gZGlzY3Vzc2lvbnMgZGV2ZWxvcGluZyBDb25u ZWN0IHdlIGRlY2lkZWQgbm90IHRvIG9wZW4gdGhpcyBjYW4gb2Ygd29ybXMgYmVjYXVzZSBubyBn b29kIHdvdWxkIGNvbWUgb2YgaXQuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHRva2VuX2VuZHBvaW50IHJl dHVybnMgYSBhY2Nlc3MgdG9rZW4uICZuYnNwO05vdGhpbmcgcmVxdWlyZXMgc2NvcGUgdG8gYmUg YXNzb2NpYXRlcyB3aXRoIHRoZSB0b2tlbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYXQgaXMgdGhlIGJlc3Qgc29sdXRp b24uICZuYnNwO05vIGNoYW5nZSByZXF1aXJlZC4gJm5ic3A7QmV0dGVyIGludGVyb3BlcmFiaWxp dHkgaW4gbXkgb3Bpbmlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlN0aWxsIG9uIG15IHdheSB0byBUTywgZ2V0dGluZyBp biBsYXRlciB0b2RheS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkpvaG4gQi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxicj4NClNlbnQgZnJv bSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KT24gSnVsIDIzLCAyMDE0LCBhdCAxMjoxNSBQTSwgPGEgaHJlZj0ibWFpbHRvOnRv cnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+DQp0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldDwvYT4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwPlRo ZSAmcXVvdDtyZXNwb25zZSB0eXBlJnF1b3Q7IG9mIHRoZSB0b2tlbiBlbmRwb2ludCBpcyBjb250 cm9sbGVkIGJ5IHRoZSB2YWx1ZSBvZiB0aGUgcGFyYW1ldGVyICZxdW90O2dyYW50X3R5cGUmcXVv dDsuIFNvIHRoZXJlIGlzIG5vIG5lZWQgdG8gaW50cm9kdWNlIGEgbmV3IHBhcmFtZXRlci48bzpw PjwvbzpwPjwvcD4NCjxwPndydCB0byBhIHBvdGVudGlhbCAmcXVvdDtub19hY2Nlc3NfdG9rZW4m cXVvdDsgZ3JhbnQgdHlwZS4gSSBkbyBub3QgY29uc2lkZXIgdGhpcyBhIGdvb2QgaWRlYSBhcyBp dCBjaGFuZ2VzIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHRva2VuIGVuZHBvaW50IChhcyBhbHJlYWR5 IHBvaW50ZWQgb3V0IGJ5IFRob21hcykuIFRoaXMgZW5kcG9pbnQgQUxXQVlTIHJlc3BvbmRzIHdp dGggYW4gYWNjZXNzIHRva2VuIHRvIGFueSBncmFudCB0eXBlLiBJIHRoZXJlZm9yZSB3b3VsZA0K IHByZWZlciB0byB1c2UgYW5vdGhlciBlbmRwb2ludCBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2Uu PG86cD48L286cD48L3A+DQo8cD5yZWdhcmRzLDxicj4NClRvcnN0ZW4uPG86cD48L286cD48L3A+ DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkFtIDIzLjA3LjIwMTQgMTM6MDQsIHNjaHJp ZWIgTmF0IFNha2ltdXJhOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JTUhPLCBjaGFu Z2luZyB0aGUgc2VtYW50aWNzIG9mICZxdW90O3Jlc3BvbnNlX3R5cGUmcXVvdDsgQCBhdXRoeiBl bmRwb2ludCB0aGlzIHdheSBpcyBub3QgYSBnb29kIHRoaW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbnN0ZWFkLCBkZWZpbmluZyBh IG5ldyBwYXJhbWV0ZXIgJnF1b3Q7cmVzcG9uc2VfdHlwZSZxdW90OyBAIHRva2VuIGVuZHBvaW50 LCBhcyBJIGRlc2NyaWJlZCBpbiBteSBwcmV2aW91cyBtZXNzYWdlLCZuYnNwOw0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5wcm9iYWJseSBpcyBiZXR0ZXIu IEF0IGxlYXN0LCBpdCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiB0aGUgcGFyYW1l dGVycyBvZiBSRkM2NzQ5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7TmF0Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4yMDE0LTA3LTIzIDEyOjQ4IEdNVC0w NDowMCBUaG9tYXMgQnJveWVyICZsdDs8YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDs6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ObywgSSBtZWFuIHJlc3BvbnNlX3R5 cGU9bm9uZSBhbmQgcmVzcG9uc2VfdHlwZT1pZF90b2tlbiBkb24ndCBnZW5lcmF0ZSBhIGNvZGUg b3IgYWNjZXNzIHRva2VuIHNvIHlvdSBkb24ndCB1c2UgdGhlIFRva2VuIEVuZHBvaW50ICh3aGlj aCBpcyBub3QgdGhlIHNhbWUgYXMgdGhlIEF1dGhlbnRpY2F0aW9uIEVuZHBvaW50DQogQlRXKS4g PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaXRoIHJlc3Bv bnNlX3R5cGU9Y29kZV9mb3JfaWRfdG9rZW4sIHlvdSBnZXQgYSBjb2RlIGFuZCBleGNoYW5nZSBp dCBmb3IgYW4gaWRfdG9rZW4gb25seSwgcmF0aGVyIHRoYW4gYW4gYWNjZXNzX3Rva2VuLCBzbyB5 b3UncmUgY2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgVG9rZW4gRW5kcG9pbnQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ20g bm90IHNheWluZyBpdCdzIGEgYmFkIHRoaW5nLCBqdXN0IHRoYXQgeW91IGNhbid0IHJlYWxseSBj b21wYXJlIG5vbmUgYW5kIGlkX3Rva2VuIHdpdGggY29kZV9mb3JfaWRfdG9rZW4uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIFdlZCwgSnVsIDIzLCAyMDE0IGF0IDY6NDUgUE0sIFJpY2hlciwgSnVzdGluIFAuICZsdDs8 YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVy QG1pdHJlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SXQncyBvbmx5ICZxdW90O25vdCB1c2luZyB0aGUgdG9rZW4gZW5kcG9p bnQmcXVvdDsgYmVjYXVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgY29weS1wYXN0ZWQgYW5kIHJlbmFt ZWQgdGhlIGF1dGhlbnRpY2F0aW9uIGVuZHBvaW50Lg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7LS0gSnVzdGluPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIEp1bCAyMywgMjAxNCwgYXQgOTozMCBBTSwgVGhvbWFzIEJyb3llciAmbHQ7PGEg aHJlZj0ibWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnQuYnJveWVy QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+RXhjZXB0IHRoYXQgdGhlc2UgYXJlIGFib3V0IG5vdCB1c2luZyB0aGUgVG9rZW4gRW5k cG9pbnQgYXQgYWxsLCB3aGVyZWFzIHRoZSBjdXJyZW50IHByb3Bvc2FsIGlzIGFib3V0IHRoZSBU b2tlbiBFbmRwb2ludCBub3QgcmV0dXJuaW5nIGFuIGFjY2Vzc190b2tlbiBmaWVsZCBpbiB0aGUg SlNPTi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQs IEp1bCAyMywgMjAxNCBhdCA0OjI2IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoZSByZXNwb25zZV90eXBlICZxdW90O25vbmUmcXVvdDsgaXMgYWxyZWFk eSB1c2VkIGluIHByYWN0aWNlLCB3aGljaCByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi4mbmJzcDsg SXQgd2FzIGFjY2VwdGVkDQogYnkgdGhlIGRlc2lnbmF0ZWQgZXhwZXJ0cyBhbmQgcmVnaXN0ZXJl ZCBpbiB0aGUgSUFOQSBPQXV0aCBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGVz IHJlZ2lzdHJ5IGF0DQo8YSBocmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29h dXRoLXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54bWwjZW5kcG9pbnQiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9v YXV0aC1wYXJhbWV0ZXJzLnhtbCNlbmRwb2ludDwvYT4uJm5ic3A7IFRoZSByZWdpc3RlcmVkICZx dW90O2lkX3Rva2VuJnF1b3Q7IHJlc3BvbnNlIHR5cGUgYWxzbyByZXR1cm5zIG5vIGFjY2VzcyB0 b2tlbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5TbyBJIHRoaW5rIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHJl c3BvbnNlIHR5cGVzIHRoYXQgcmVzdWx0IGluIG5vIGFjY2VzcyB0b2tlbiBiZWluZyByZXR1cm5l ZCBhcmUNCiBhY2NlcHRhYmxlIHdpdGhpbiBPQXV0aCAyLjAgaXMgYWxyZWFkeSBzZXR0bGVkLCBh cyBhIHByYWN0aWNhbCBtYXR0ZXIuJm5ic3A7IExvdHMgb2YgT0F1dGggaW1wbGVtZW50YXRpb25z IGFyZSBhbHJlYWR5IHVzaW5nIHN1Y2ggcmVzcG9uc2UgdHlwZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRo IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxzdHJvbmc+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5P biBCZWhhbGYgT2YgPC9zcGFuPjwvc3Ryb25nPlBoaWwgSHVudDxicj4NCjxzdHJvbmc+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5TZW50Ojwvc3Bhbj48L3N0cm9uZz4gV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDc6MDkg QU08YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VG86PC9zcGFuPjwvc3Ryb25nPiBOYXQgU2FraW11 cmE8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2M6PC9zcGFuPjwvc3Ryb25nPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0Ojwvc3Bhbj48L3N0cm9uZz4g UmU6IFtPQVVUSC1XR10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LW9h dXRoLXYyLXVzZXItYTRjLTA1LnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlllcy4gVGhpcyBpcyB3aHkgaXQgaGFzIHRv IGJlIGRpc2N1c3NlZCBpbiB0aGUgSUVURi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGhpbDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5AaW5kZXBlbmRlbnRpZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iIHRhcmdldD0iX2Js YW5rIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEp1bCAyMywgMjAxNCwgYXQgOTo0MyBBTSwg TmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWFkaW5nIGJhY2sgdGhlIFJGQzY3NDksIEkgYW0g bm90IHN1cmUgaWYgdGhlcmUgaXMgYSBnb29kIHdheSBvZiBzdXBwcmVzc2luZyBhY2Nlc3MgdG9r ZW4gZnJvbSB0aGUgcmVzcG9uc2UgYW5kIHN0aWxsIGJlIE9BdXRoLiBJdCB3aWxsIGJyZWFrIHdo b2xlIGJ1bmNoIG9mIGltcGxpY2l0IGRlZmluaXRpb25zDQogbGlrZTombmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmF1dGhvcml6YXRpb24gc2VydmVyPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlIHNlcnZlciBpc3N1aW5nIGFjY2VzcyB0b2tlbnMg dG8gdGhlIGNsaWVudCBhZnRlciBzdWNjZXNzZnVsbHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyBhdXRoZW50aWNhdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIG9idGFpbmluZyBhdXRob3Jp emF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkFmdGVyIGFsbCwgT0F1dGggaXMgYWxsIGFib3V0IGlzc3VpbmcgYWNjZXNzIHRva2Vucy4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkFsc28sIEkgdGFrZSBiYWNrIG15IHN0YXRlbWVudCBvbiB0aGUgZ3JhbnQgdHlwZSBpbiBt eSBwcmV2aW91cyBtYWlsLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGRlZmluaXRpb24gb2YgZ3JhbnQgYW5kIGdyYW50 X3R5cGUgYXJlIHJlc3BlY3RpdmVseTombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ncmFudCZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5i c3A7IGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGF1dGhvcml6 YXRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Z3JhbnRfdHlwZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsgKHN0cmluZyByZXByZXNlbnRp bmcgdGhlKSB0eXBlIG9mIGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IHRvIG9idGFp biB0aGUgYWNjZXNzIHRva2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRodXMsIHRoZSBncmFudCBzZW50IHRvIHRoZSB0 b2tlbiBlbmRwb2ludCBpbiB0aGlzIGNhc2UgaXMgc3RpbGwgJ2NvZGUnLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVzcG9u c2UgdHlwZSBvbiB0aGUgb3RoZXIgaGFuZCBpcyBub3Qgc28gd2VsbCBkZWZpbmVkIGluIFJGQzY3 NDksIGJ1dCBpdCBzZWVtcyBpdCBpcyByZXByZXNlbnRpbmcgd2hhdCBpcyB0byBiZSByZXR1cm5l ZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBUbyBleHByZXNzIHdoYXQgaXMgdG8N CiBiZSByZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50LCBwZXJoYXBzIGRlZmluaW5nIGEgbmV3 IHBhcmFtZXRlciB0byB0aGUgdG9rZW4gZW5kcG9pbnQsIHdoaWNoIGlzIGEgcGFyYWxsZWwgdG8g dGhlIHJlc3BvbnNlX3R5cGUgdG8gdGhlIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgc2VlbXMgdG8g YmUgYSBtb3JlIHN5bW1ldHJpYyB3YXksIHRob3VnaCBJIGFtIG5vdCBzdXJlIGF0IGFsbCBpZiB0 aGF0IGlzIGdvaW5nIHRvIGJlIE9BdXRoIGFueSBtb3JlLg0KIE9uZSBzdHJhdy1tYW4gaXMgdG8g ZGVmaW5lIGEgbmV3IHBhcmFtZXRlciBjYWxsZWQgcmVzcG9uc2VfdHlwZSB0byB0aGUgdG9rZW4g ZW5kcG9pbnQgc3VjaCBhczombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnJlc3BvbnNlX3R5cGU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBPUFRJT05B TC4gQSBzdHJpbmcgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUg dG9rZW4gZW5kcG9pbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlbiBkZWZpbmUgdGhlIGJlaGF2 aW9yIG9mIHRoZSBlbmRwb2ludCBhY2NvcmRpbmcgdG8gdGhlIHZhbHVlcyBhcyB0aGUgcGFyYWxs ZWwgdG8gdGhlIG11bHRpLXJlc3BvbnNlIHR5cGUgc3BlYy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cDovL29w ZW5pZC5uZXQvc3BlY3Mvb2F1dGgtdjItbXVsdGlwbGUtcmVzcG9uc2UtdHlwZXMtMV8wLmh0bWwi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC12Mi1tdWx0aXBs ZS1yZXNwb25zZS10eXBlcy0xXzAuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIw MTQtMDctMjMgNzoyMSBHTVQtMDQ6MDAgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwv YT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlRoZSBkcmFmdCBpcyB2ZXJ5IGNsZWFyLiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjojODg4 ODg4Ij48YnI+DQo8YnI+DQpQaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEp1bCAyMywgMjAxNCwg YXQgMDo0NiwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhl IG5ldyBncmFudCB0eXBlIHRoYXQgSSB3YXMgdGFsa2luZyBhYm91dCB3YXMmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZxdW90O2F1dGhvcml6YXRp b25fY29kZV9idXRfZG9fbm90X3JldHVybl9hY2Nlc3Nfbm9yX3JlZnJlc2hfdG9rZW4mcXVvdDss IHNvIHRvIHNwZWFrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkl0IGRvZXMgbm90IHJldHVybiBhbnl0aGluZyBwZXIgc2UsIGJ1dCBh biBleHRlbnNpb24gY2FuIGRlZmluZSBzb21ldGhpbmcgb24gdG9wIG9mIGl0LiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhl biwgT0lEQyBjYW4gZGVmaW5lIGEgYmluZGluZyB0byBpdCBzbyB0aGF0IHRoZSBiaW5kaW5nIG9u bHkgcmV0dXJucyBJRCBUb2tlbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBiaW5kaW5nIHdvcmsgc2hvdWxkIGJlIGRvbmUg aW4gT0lERi4gU2hvdWxkIHRoZXJlIGJlIHN1Y2ggYSBncmFudCB0eXBlLCZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+aXQgd2lsbCBiZSBhbiBleHRyZW1lbHkgc2hvcnQgc3BlYy4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkF0IHRoZSBz YW1lIHRpbWUsIGlmIGFueSBvdGhlciBzcGVjaWZpY2F0aW9uIHdhbnRlZCB0byBkZWZpbmUmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ b3RoZXIgdHlwZSBvZiB0b2tlbnMgYW5kIGhhdmUgaXQgcmV0dXJuZWQgZnJvbSB0aGUgdG9rZW4g ZW5kcG9pbnQsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPml0IGNhbiBhbHNvIHVzZSB0aGlzIGdyYW50IHR5cGUuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB3 aGF0IHlvdSB3YW50IGlzIHRvIGRlZmluZSBhIG5ldyBncmFudCB0eXBlIHRoYXQgcmV0dXJucyBJ RCBUb2tlbiBvbmx5LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj50aGVuLCBJIGFtIHdpdGggSnVzdGluLiBTaW5jZSAmcXVvdDtvdGhl ciByZXNwb25zZSB0aGFuIElEIFRva2VuJnF1b3Q7IGlzIG9ubHkmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGhlb3JldGljYWwsIHRo aXMgaXMgYSBtb3JlIHBsYXVzaWJsZSB3YXkgZm9yd2FyZCwgSSBzdXBwb3NlLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TmF0 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4yMDE0 LTA3LTIyIDE0OjMwIEdNVC0wNDowMCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86 anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvIHRoZSBkcmFmdCB3b3Vs ZCBsaXRlcmFsbHkgdHVybiBpbnRvOjxicj4NCjxicj4NCiZxdW90O1RoZSBhNGMgcmVzcG9uc2Ug dHlwZSBhbmQgZ3JhbnQgdHlwZSByZXR1cm4gYW4gaWRfdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5k cG9pbnQgd2l0aCBubyBhY2Nlc3MgdG9rZW4uIEFsbCBwYXJhbWV0ZXJzIGFuZCB2YWx1ZXMgYXJl IGRlZmluZWQgaW4gT0lEQy4mcXVvdDs8YnI+DQo8YnI+DQpTZWVtcyBsaWtlIHRoZSBwZXJmZWN0 IG1pbmkgZXh0ZW5zaW9uIGRyYWZ0IGZvciBPSURGIHRvIGRvLjxicj4NCjxicj4NCi0tSnVzdGlu PGJyPg0KPGJyPg0KL3NlbnQgZnJvbSBteSBwaG9uZS88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCk9uIEp1bCAyMiwgMjAxNCAxMDoyOSBBTSwgTmF0 IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4N CiZndDsgV2hhdCBhYm91dCBqdXN0IGRlZmluaW5nIGEgbmV3IGdyYW50IHR5cGUgaW4gdGhpcyBX Rz88YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgMjAxNC0wNy0yMiAxMjo1NiBHTVQtMDQ6 MDAgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRh cmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgVGhhdCB3b3VsZCBiZSBuaWNlLiBIb3dldmVyIG9pZGMgc3RpbGwgbmVl ZHMgdGhlIG5ldyBncmFudCB0eXBlIGluIG9yZGVyIHRvIGltcGxlbWVudCB0aGUgc2FtZSBmbG93 LiZuYnNwOzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUGhpbDxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgT24gSnVsIDIyLCAyMDE0LCBhdCAxMTozNSwgTmF0IFNha2ltdXJhICZsdDs8 YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11 cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsgJiM0MzsxIHRvIEp1c3Rpbi4mbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgMjAxNC0wNy0yMiA5OjU0IEdNVC0wNDowMCBSaWNoZXIs IEp1c3RpbiBQLiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9 Il9ibGFuayI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0Ozo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBFcnJvcnMgbGlrZSB0aGVzZSBtYWtlIGl0IGNsZWFyIHRv IG1lIHRoYXQgaXQgd291bGQgbWFrZSBtdWNoIG1vcmUgc2Vuc2UgdG8gZGV2ZWxvcCB0aGlzIGRv Y3VtZW50IGluIHRoZSBPcGVuSUQgRm91bmRhdGlvbi4gSXQgc2hvdWxkIGJlIHNvbWV0aGluZyB0 aGF0IGRpcmVjdGx5IHJlZmVyZW5jZXMgT3BlbklEIENvbm5lY3QgQ29yZSBmb3IgYWxsIG9mIHRo ZXNlIHRlcm1zIGluc3RlYWQgb2YgcmVkZWZpbmluZyB0aGVtLiBJdCdzIGRvaW5nDQogYXV0aGVu dGljYXRpb24sIHdoaWNoIGlzIGZ1bmRhbWVudGFsbHkgd2hhdCBPcGVuSUQgQ29ubmVjdCBkb2Vz IG9uIHRvcCBvZiBPQXV0aCwgYW5kIEkgZG9uJ3Qgc2VlIGEgZ29vZCBhcmd1bWVudCBmb3IgZG9p bmcgdGhpcyB3b3JrIGluIHRoaXMgd29ya2luZyBncm91cC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDstLSBKdXN0aW48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbiBKdWwgMjIsIDIwMTQsIGF0IDQ6MzAgQU0sIFRo b21hcyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj50LmJyb3llckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg T24gTW9uLCBKdWwgMjEsIDIwMTQgYXQgMTE6NTIgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9 Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZvciB5b3Vy IHJldmlldywgVGhvbWFzLiZuYnNwOyBUaGUgJnF1b3Q7cHJvbXB0PWNvbnNlbnQmcXVvdDsgZGVm aW5pdGlvbiBiZWluZyBtaXNzaW5nIGlzIGFuIGVkaXRvcmlhbCBlcnJvci4mbmJzcDsgSXQgc2hv dWxkIGJlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uc2VudDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIg U0hPVUxEIHByb21wdCB0aGUgRW5kLVVzZXIgZm9yIGNvbnNlbnQgYmVmb3JlIHJldHVybmluZyBp bmZvcm1hdGlvbiB0byB0aGUgQ2xpZW50LiBJZiBpdCBjYW5ub3Qgb2J0YWluIGNvbnNlbnQsIGl0 IE1VU1QgcmV0dXJuIGFuIGVycm9yLCB0eXBpY2FsbHkgY29uc2VudF9yZXF1aXJlZC48YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5i c3A7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEknbGwgcGxhbiB0byBhZGQgaXQgaW4gdGhlIG5leHQgZHJhZnQuPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEl0IGxvb2tzIGxpa2UgdGhlIGNvbnNlbnRfcmVxdWlyZWQgZXJyb3IgbmVlZHMg dG8gYmUgZGVmaW5lZCB0b28sIGFuZCB5b3UgbWlnaHQgaGF2ZSBmb3Jnb3R0ZW4gdG8gYWxzbyBp bXBvcnQgYWNjb3VudF9zZWxlY3Rpb25fcmVxdWlyZWQgZnJvbSBPcGVuSUQgQ29ubmVjdC48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgYWdyZWUgdGhhdCB0 aGVyZSdzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJlc3BvbnNlIHdpdGggbXVsdGlwbGUgJnF1 b3Q7YW1yJnF1b3Q7IHZhbHVlcyB0aGF0IGluY2x1ZGVzICZxdW90O21mYSZxdW90OyBhbmQgb25l IHRoYXQgZG9lc24ndC4mbmJzcDsgVW5sZXNzIGEgY2xlYXIgdXNlIGNhc2UgZm9yIHdoeSAmcXVv dDttZmEmcXVvdDsgaXMgbmVlZGVkIGNhbiBiZSBpZGVudGlmaWVkLCB3ZSBjYW4gZGVsZXRlIGl0 IGluIHRoZSBuZXh0IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFua3MuPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIb3cgYWJvdXQgJnF1 b3Q7cHdkJnF1b3Q7IHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IEkgc2hvdWxkIHJldHVy biAmcXVvdDtwd2QmcXVvdDsgaWYgdGhlIHVzZXIgYXV0aGVudGljYXRlZCB1c2luZyBhIHBhc3N3 b3JkLCBidXQgd2hhdCAmcXVvdDt0aGUgc2VydmljZSBpZiBhIGNsaWVudCBzZWNyZXQgaXMgdXNl ZCZxdW90OyBtZWFucyBpbiB0aGUgZGVmaW5pdGlvbiBmb3IgdGhlICZxdW90O3B3ZCZxdW90OyB2 YWx1ZT88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IChOb3RhOiBJIGtub3cgeW91J3JlIGF0IElFVEYtOTAsIEknbSByZWFkeSB0byB3YWl0ICd0aWwg eW91IGNvbWUgYmFjayA7LSkgKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaG9tYXMgQnJveWVy PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgL3Q8YSBocmVmPSJodHRwOi8veG4tLW5uYS5tYS54 bi0tYndhLXh4Yi5qZS8iIHRhcmdldD0iX2JsYW5rIj7JlC5tYS5iyoF3YS5qZS88L2E+PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLTxi cj4NCiZndDsmZ3Q7Jmd0OyBOYXQgU2FraW11cmEgKD1uYXQpPGJyPg0KJmd0OyZndDsmZ3Q7IENo YWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRw Oi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJh Lm9yZy88L2E+PGJyPg0KJmd0OyZndDsmZ3Q7IEBfbmF0X2VuPGJyPg0KJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7 Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0 aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IE5hdCBTYWtpbXVyYSAo PW5hdCk8YnI+DQomZ3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsgPGEg aHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25h dC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCiZndDsgQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxs Ij4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxicj4N Ck5hdCBTYWtpbXVyYSAoPW5hdCk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6 Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEu b3JnLzwvYT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGFpcm1hbiwgT3BlbklE IEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdl dD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+LS0NCjxicj4NClRob21hcyBCcm95ZXI8YnI+DQovdDxhIGhyZWY9Imh0 dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhiLmplLyIgdGFyZ2V0PSJfYmxhbmsiPsmULm1hLmLK gXdhLmplLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9B dXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij4tLQ0KPGJyPg0KVGhvbWFzIEJyb3llcjxicj4NCi90PGEgaHJl Zj0iaHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvIiB0YXJnZXQ9Il9ibGFuayI+yZQu bWEuYsqBd2EuamUvPC9hPiA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBj bGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ LS0NCjxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCkgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBo cmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0 LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHBy ZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGll dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0 aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQp IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoYWlybWFuLCBP cGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9l bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tIDxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCkgPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0K PGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov L25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZG IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzEwMTBGRiAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCk8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRp b248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_9dbf8c7384e341a08334a9ee093697f8BLUPR03MB309namprd03pro_-- From nobody Thu Jul 24 07:05:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA891A031B for ; Thu, 24 Jul 2014 07:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Adh9VZ3YT9NF for ; Thu, 24 Jul 2014 07:05:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF261A033B for ; Thu, 24 Jul 2014 07:05:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 91D7E1F272E; Thu, 24 Jul 2014 10:05:41 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 45BC31F0398; Thu, 24 Jul 2014 10:05:41 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.118]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 10:05:41 -0400 From: "Richer, Justin P." To: Brian Campbell Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpdsD2HhjKAwRPEyI0/Q0qsoAEputWXWAgABuQgCAACfAgIAABwoAgAAFHwCAACJ9AIAABDoAgAAAvwCAAASJAIAAAz+AgAAE4ACAAAGWgIAAEq+AgAAJNoCAAAOtAIAAAq4AgAAGTgD//8rapYABSF0AgAAXRgCAAAOpAA== Date: Thu, 24 Jul 2014 14:05:40 +0000 Message-ID: <59B4FD06-C1E2-4629-B46B-09A6E00EDB57@mitre.org> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.11.236] Content-Type: multipart/alternative; boundary="_000_59B4FD06C1E24629B46B09A6E00EDB57mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5EfB9Jr_9D466bNnNnljued7OJk Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 14:05:49 -0000 --_000_59B4FD06C1E24629B46B09A6E00EDB57mitreorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdsbCBzZWNvbmQgdGhpcyBzZW50aW1lbnQuIElhbidzIG92ZXJhbGwgdGFsayB3YXMgYWJvdXQg d2hlbiByZWludmVudGluZyB3aGVlbHMgd2FzIGEgZ29vZCB0aGluZyAobGlrZSBYTUwgLT4gSlNP TiksIGFuZCBoZSBjYWxsZWQgb3V0IEE0QyBzcGVjaWZpY2FsbHkgYXMgYW4gZXhhbXBsZSBvZiBy ZWludmVudGlvbiBmb3IgaXRzIG93biBzYWtlLCBhIGhhcm1mdWwgYW5kIHdhc3RlZnVsIHByYWN0 aWNlLiBJdCB3YXMgYSB2ZXJ5IGdvb2Qga2V5bm90ZSB0YWxrLCBhbmQgSSBoaWdobHkgcmVjb21t ZW5kIHRoYXQgcGVvcGxlIHJlYWQgdGhlIGJsb2cgcG9zdChzKSBhbmQgbG9vayBmb3IgdGhlIHZp ZGVvcyBvbmNlIHRoZXkncmUgcG9zdGVkLg0KDQogLS0gSnVzdGluDQoNCk9uIEp1bCAyNCwgMjAx NCwgYXQgOTo1MiBBTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t PG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KDQpJJ2Qgbm90ZSB0 aGF0IHRoZSByZWFjdGlvbiBhdCB0aGUgY29uZmVyZW5jZSB0byBJYW4ncyBzdGF0ZW1lbnQgd2Fz IG92ZXJ3aGVsbWluZ2x5IHBvc2l0aXZlLiBUaGVyZSB3YXMgYSB3aWRlIHJhbmdlIG9mIGluZHVz dHJ5IHBlb3BsZSBoZXJlIC0gaW1wbGVtZW50ZXJzLCBwcmFjdGl0aW9uZXJzLCBkZXBsb3llcnMs IHN0cmF0ZWdpc3RzLCBldGMuIC0gYW5kIGl0IHNlZW1zIHByZXR0eSBjbGVhciB0aGF0IHRoZSAi cm91Z2ggY29uc2Vuc3VzIiBvZiB0aGUgaW5kdXN0cnkgYXQgbGFyZ2UgaXMgdGhhdCBhNGMgaXMg bm90IHdhbnRlZCBvciBuZWVkZWQuDQoNCg0KT24gVGh1LCBKdWwgMjQsIDIwMTQgYXQgNToyOSBB TSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWls LmNvbT4+IHdyb3RlOg0KQW5kIGhlcmUgaXMgYSBxdW90ZSBmcm9tIElhbidzIGJsb2cuDQoNCkFu ZCBhbHRob3VnaCB0aGUgYXV0aGVudGljYXRpb24gd2hlZWwgaXMgcm91bmQsIHRoYXQgZG9lc27i gJl0IG1lYW4gaXQgaXNu4oCZdCB3aXRob3V0IGl0cyBsdW1wcy4gRmlyc3QsIHdlIGRvIHNlZSBz b21lIHJlaW52ZW50aW5nIHRoZSB3aGVlbCBqdXN0IHRvIHJlaW52ZW50IHRoZSB3aGVlbC4gT0F1 dGggQTRDIGlzIHNpbXBseSBub3QgYSBmcnVpdGZ1bCBhY3Rpdml0eSBhbmQgc2hvdWxkIGJlIHB1 dCBkb3duLg0KDQooU291cmNlKSBodHRwOi8vd3d3LnR1ZXNkYXluaWdodC5vcmcvMjAxNC8wNy8y My9kby13ZS1oYXZlLWEtcm91bmQtd2hlZWwteWV0LW11c2luZ3Mtb24taWRlbnRpdHktc3RhbmRh cmRzLXBhcnQtMS5odG1sDQoNCg0KMjAxNC0wNy0yMyAxNjo1MyBHTVQtMDQ6MDAgSm9obiBCcmFk bGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PjoNCg0KSSB0 aG91Z2h0IEkgZGlkIHBvc3QgdGhpcyB0byB0aGUgbGlzdC4NCg0KSSBndWVzcyBJIGhpdCB0aGUg d3JvbmcgcmVwbHkgb24gbXkgcGhvbmUuDQoNCkpvaG4gQi4NClNlbnQgZnJvbSBteSBpUGhvbmUN Cg0KT24gSnVsIDIzLCAyMDE0LCBhdCA0OjUwIFBNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxt YWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KDQoNCndlIGFyZSB0d28sIGF0 IGxlYXN0IDotKQ0KDQpXaHkgZGlkbid0IHlvdSBwb3N0IHRoaXMgb24gdGhlIGxpc3Q/DQoNCldo ZW4gd2lsbCBiZSBiZSBhcnJpdmluZz8NCg0KQW0gMjMuMDcuMjAxNCAxNjozOSwgc2NocmllYiBK b2huIEJyYWRsZXk6DQoNCklhbiBHbGF6ZXIgbWVudGlvbmVkIHRoaXMgaW4gaGlzIGtleW5vdGUg YXQgQ0lTIHllc3RlcmRheS4NCg0KSGlzIGFkdmljZSB3YXMgcGxlYXNlIHN0b3AsICB3ZSBhcmUg Y3JlYXRpbmcgY29uZnVzaW9uIGFuZCB1bmNlcnRhaW50eS4NCg0KV2UgYXJlIGJlY29taW5nIG91 ciBvd24gd29ydCBlbmVteS4gKCBteSB2aWV3IHRob3VnaCBJYW4gbWF5IHNoYXJlIGl0KQ0KDQpS ZXR1cm5pbmcganVzdCBhbiBpZF8gdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgaGFzIGxp dHRsZSByZWFsIHZhbHVlLg0KDQpTb21ldGhpbmcgcmVhbGx5IHVzZWZ1bCB0byBkbyB3b3VsZCBi ZSBzb3J0aW5nIG91dCBjaGFubmVsX2lkIHNvIHdlIGNhbiBkbyBQb1AgZm9yIGlkIHRva2VucyB0 byBtYWtlIHRoZW0gYW5kIG90aGVyIGNvb2tpZXMgc2VjdXJlIGluIHRoZSBmcm9udCBjaGFubmVs LiAgIEkgdGhpbmsgdGhhdCBpcyBhIGJldHRlciB1c2Ugb2YgdGltZS4NCg0KSSBtYXkgYmUgaW4g dGhlIG1pbm9yaXR5IG9waW5pb24gb24gdGhhdCwgIGl0IHdvbid0IGJlIHRoZSBmaXJzdCB0aW1l Lg0KDQoNCkpvaG4gQi4NClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gSnVsIDIzLCAyMDE0LCBh dCA0OjA0IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxt YWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3cm90ZToNCg0KWW91IGFyZSByaWdodCBm cm9tIGEgdGhlb3JldGljYWwgcGVyc3BlY3RpdmUuIFByYWN0aWNhbGx5IHRoaXMgd2FzIGNhdXNl ZCBieSBlZGl0b3JpYWwgZGVjaXNpb25zIGR1cmluZyB0aGUgY3JlYXRpb24gb2YgdGhlIFJGQy4g QXMgZmFyIGFzIEkgcmVtZW1iZXIsIHRoZXJlIHdhcyBhIGRlZmluaXRpb24gb2YgdGhlIChvbmUp IHRva2VuIGVuZHBvaW50IHJlc3BvbnNlIGluIGVhcmx5IHZlcnNpb25zLiBObyBvbmUgZXZlcnkg Y29uc2lkZXJlZCB0byBOT1QgcmVzcG9uZCB3aXRoIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSB0 b2tlbiBlbmRwb2ludC4gU28gb25lIG1pZ2h0IGNhbGwgaXQgYW4gaW1wbGljaXQgYXNzdW1wdGlv bi4NCg0KSSdtIHdvcnJpZWQgdGhhdCBwZW9wbGUgZ2V0IHRvdGFsbHkgY29uZnVzZWQgaWYgYW4g ZXhjZXB0aW9uIGlzIGludHJvZHVjZWQgbm93IGdpdmVuIHRoZSBicm9hZCBhZG9wdGlvbiBvZiBP QXV0aCBiYXNlZCBvbiB0aGlzIGFzc3VtcHRpb24uDQoNCnJlZ2FyZHMsDQpUb3JzdGVuLg0KDQpB bSAyMy4wNy4yMDE0IHVtIDE1OjQxIHNjaHJpZWIgVGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21h aWwuY29tPG1haWx0bzp0LmJyb3llckBnbWFpbC5jb20+PjoNCg0KDQpJcyBpdCBzYWlkIGFueXdo ZXJlIHRoYXQgQUxMIGdyYW50IHR5cGVzIE1VU1QgdXNlIFNlY3Rpb24gNS4xIHJlc3BvbnNlcz8g RWFjaCBncmFudCB0eXBlIHJlZmVyZW5jZXMgU2VjdGlvbiA1LjEsIGFuZCAiYWNjZXNzIHRva2Vu IHJlcXVlc3QiIGlzIG9ubHkgZGVmaW5lZCBpbiB0aGUgY29udGV4dCBvZiB0aGUgZGVmaW5lZCBn cmFudCB0eXBlcy4gU2VjdGlvbiAyLjIgZG9lc24ndCB0YWxrIGFib3V0IHRoZSByZXF1ZXN0IG9y IHJlc3BvbnNlIGZvcm1hdC4NCg0KTGUgMjMganVpbC4gMjAxNCAyMTozMiwgIk5hdCBTYWtpbXVy YSIgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gYSDDqWNy aXQgOg0KSXMgaXQ/IEFwYXJ0IGZyb20gdGhlIGltcGxpY2l0IGdyYW50IHRoYXQgZG9lcyBub3Qg dXNlIHRva2VuIGVuZHBvaW50LCBhbGwgb3RoZXIgZ3JhbnQgcmVmZXJlbmNlcyBzZWN0aW9uIDUu MSBmb3IgdGhlIHJlc3BvbnNlLCBpLmUuLCBhbGwgc2hhcmVzIHRoZSBzYW1lIHJlc3BvbnNlLg0K DQoNCjIwMTQtMDctMjMgMTU6MTggR01ULTA0OjAwIFRob21hcyBCcm95ZXIgPHQuYnJveWVyQGdt YWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPj46DQoNCkkgaGFkbid0IHJlYWxpemVk IHRoZSBKU09OIHJlc3BvbnNlIHRoYXQgcmVxdWlyZXMgdGhlIGFjY2Vzc190b2tlbiBmaWVsZCBp cyBkZWZpbmVkIHBlciBncmFudF90eXBlLCBzbyBJJ2QgYmUgT0sgdG8gImV4dGVuZCB0aGUgc2Vt YW50aWNzIiBhcyBpbiB0aGUgY3VycmVudCBkcmFmdC4NClRoYXQgd2FzIGFjdHVhbGx5IG15IG1h aW4gY29uY2VybjogdGhhdCB0aGUgdG9rZW4gZW5kcG9pbnQgbWFuZGF0ZXMgYWNjZXNzX3Rva2Vu OyBidXQgaXRzIGFjdHVhbGx5IG5vdCB0aGUgY2FzZS4NCg0KTGUgMjMganVpbC4gMjAxNCAyMDo0 NiwgIk5hdCBTYWtpbXVyYSIgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21h aWwuY29tPj4gYSDDqWNyaXQgOg0KDQpJIGFncmVlIHdpdGggSm9obiB0aGF0IG92ZXJsb2FkaW5n IHJlc3BvbnNlX3R5cGUgQCBhdXRoeiBlbmRwb2ludCBpcyBhIGJhZCBpZGVhLiBJdCBjb21wbGV0 ZWx5IGNoYW5nZXMgdGhlIHNlbWFudGljcyBvZiB0aGlzIHBhcmFtZXRlci4gTk9URTogd2hhdCBJ IHdhcyBwcm9wb3Npbmcgd2FzIG5vdCB0aGlzIHBhcmFtZXRlciwgYnV0IGEgbmV3IHBhcmFtZXRl ciByZXNwb25zZV90eXBlIEAgdG9rZW4gZW5kcG9pbnQuDQoNCkkgYWxzbyB0aGluayBvdmVybG9h ZGluZyBncmFudF90eXBlIGlzIGEgYmFkIGlkZWEgc2luY2UgaXQgY2hhbmdlcyBpdHMgc2VtYW50 aWNzLiBJIHF1b3RlIHRoZSBkZWZpbml0aW9uIGhlcmUgYWdhaW46DQoNCmdyYW50DQogICAgY3Jl ZGVudGlhbCByZXByZXNlbnRpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbg0K DQpncmFudF90eXBlDQp0eXBlIG9mIGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IHRv IG9idGFpbiB0aGUgYWNjZXNzIHRva2VuDQoNCkl0IGlzIG5vdCBhYm91dCBjb250cm9sbGluZyB3 aGF0IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LCBidXQgdGhlIGhp bnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IGRlc2NyaWJpbmcgdGhlIHR5cGUgb2YgY3JlZGVudGlh bCB0aGUgZW5kcG9pbnQgaGFzIHJlY2VpdmVkLiBJdCBzZWVtcyB0aGUgImNvbnRyb2wgb2Ygd2hh dCBpcyBiZWluZyByZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50IiAgaXMganVzdCBhIHNpZGUg ZWZmZWN0Lg0KDQpJIGFtIHNvbWV3aGF0IGFtYml2YWxlbnRbMV0gaW4gY2hhbmdpbmcgdGhlIHNl bWFudGljcyBvZiB0b2tlbiBlbmRwb2ludCwgYnV0IGluIGFzIG11Y2ggYXMgInRleHQgaXMgdGhl IGtpbmciIGZvciBhIHNwZWMuLCB3ZSBwcm9iYWJseSBzaG91bGQgbm90IGNoYW5nZSB0aGUgc2Vt YW50aWNzIG9mIGl0IGFzIFRvcnN0ZW4gcG9pbnRzIG91dC4gSWYgaXQgaXMgb2sgdG8gY2hhbmdl IHRoaXMgc2VtYW50aWNzLCBJIGJlbGlldmUgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVyIHRvIHRo aXMgZW5kcG9pbnQgdG8gY29udHJvbCB0aGUgcmVzcG9uc2Ugd291bGQgYmUgdGhlIGJlc3Qgd2F5 IHRvIGdvLiBUaGlzIGlzIHdoYXQgSSBoYXZlIGRlc2NyaWJlZCBwcmV2aW91c2x5Lg0KDQpEZWZp bmluZyBhIG5ldyBlbmRwb2ludCB0byBzZW5kIGNvZGUgdG8gZ2V0IElEIFRva2VuIGFuZCBmb3Ji aWRkaW5nIHRoZSB1c2Ugb2YgaXQgYWdhaW5zdCB0b2tlbiBlbmRwb2ludCB3b3VsZCBub3QgY2hh bmdlIHRoZSBzZW1hbnRpY3Mgb2YgYW55IGV4aXN0aW5nIHBhcmFtZXRlciBvciBlbmRwb2ludCwg d2hpY2ggaXMgZ29vZC4gSG93ZXZlciwgSSBkb3VidCBpZiBpdCBpcyBub3Qgd29ydGggZG9pbmcu IFdoYXQncyB0aGUgcG9pbnQgb2YgYXZvaWRpbmcgYWNjZXNzIHRva2VuIHNjb3BlZCB0byBVc2Vy SW5mbyBlbmRwb2ludCBhZnRlciBhbGw/IERlZmluaW5nIGEgbmV3IGVuZHBvaW50IGZvciBqdXN0 IGF2b2lkaW5nIHRoZSBhY2Nlc3MgdG9rZW4gZm9yIHVzZXJpbmZvIGVuZHBvaW50IHNlZW1zIHdh eSB0b28gbXVjaCB0aGUgaGVhdnkgd2FpdCB3YXkgYW5kIGl0IGJyZWFrcyBpbnRlcm9wZXJhYmls aXk6IGl0IGRlZmVhdHMgdGhlIHB1cnBvc2Ugb2Ygc3RhbmRhcmRpemF0aW9uLg0KDQpJIGhhdmUg c3RhcnRlZCBmZWVsaW5nIHRoYXQgbm8gY2hhbmdlIGlzIHRoZSBiZXN0IHdheSBvdXQuDQoNCk5h dA0KDQpbMV0gIElmIGluc3RlYWQgb2Ygc2F5aW5nICJUb2tlbiBlbmRwb2ludCAtIHVzZWQgYnkg dGhlIGNsaWVudCB0byBleGNoYW5nZSBhbiBhdXRob3JpemF0aW9uIGdyYW50IGZvciBhbiBhY2Nl c3MgdG9rZW4sIHR5cGljYWxseSB3aXRoIGNsaWVudCBhdXRoZW50aWNhdGlvbiIsIGl0IHdlcmUg c2F5aW5nICJUb2tlbiBlbmRwb2ludCAtIHVzZWQgYnkgdGhlIGNsaWVudCB0byBleGNoYW5nZSBh biBhdXRob3JpemF0aW9uIGdyYW50IGZvciB0b2tlbnMsIHR5cGljYWxseSB3aXRoIGNsaWVudCBh dXRoZW50aWNhdGlvbiIsIHRoZW4gaXQgd291bGQgaGF2ZSBiZWVuIE9LLiBJdCBpcyBhbiBleHBh bnNpb24gb2YgdGhlIGNhcGFiaWxpdHkgcmF0aGVyIHRoYW4gY2hhbmdpbmcgdGhlIHNlbWFudGlj cy4NCg0KDQoNCjIwMTQtMDctMjMgMTM6MzkgR01ULTA0OjAwIE1pa2UgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj46 DQpZb3UgbmVlZCB0aGUgYWx0ZXJuYXRpdmUgcmVzcG9uc2VfdHlwZSB2YWx1ZSAoImNvZGVfZm9y X2lkX3Rva2VuIiBpbiB0aGUgQTRDIGRyYWZ0KSB0byB0ZWxsIHRoZSBBdXRob3JpemF0aW9uIFNl cnZlciB0byByZXR1cm4gYSBjb2RlIHRvIGJlIHVzZWQgd2l0aCB0aGUgbmV3IGdyYW50IHR5cGUs IHJhdGhlciB0aGFuIG9uZSB0byB1c2Ugd2l0aCB0aGUgImF1dGhvcml6YXRpb25fY29kZSIgZ3Jh bnQgdHlwZSAod2hpY2ggaXMgd2hhdCByZXNwb25zZV90eXBlPWNvZGUgZG9lcykuDQoNCkZyb206 IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNClNlbnQ6IFdlZG5lc2RheSwg SnVseSAyMywgMjAxNCAxMDozMyBBTQ0KVG86IHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0 bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4NCg0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpv YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQNCg0KDQpJZiB3 ZSB1c2UgdGhlIHRva2VuIGVuZHBvaW50IHRoZW4gYSBuZXcgZ3JhbnRfdHlwZSBpcyB0aGUgYmVz dCB3YXkuDQoNCkl0IHNvcnQgb2Ygb3ZlcmxvYWRzIGNvZGUsIGJ1dCB0aGF0IGlzIGJldHRlciB0 aGFuIG1lc3Npbmcgd2l0aCByZXNwb25zZV90eXBlIGZvciB0aGUgYXV0aG9yaXphdGlvbiBlbmRw b2ludCB0byBjaGFuZ2UgdGhlIHJlc3BvbnNlIGZyb20gdGhlIHRva2VuX2VuZHBvaW50LiAgVGhh dCBpcyBpbiBteSBvcGluaW9uIGEgY2hhbXBpb24gYmFkIGlkZWEuDQoNCkluIGRpc2N1c3Npb25z IGRldmVsb3BpbmcgQ29ubmVjdCB3ZSBkZWNpZGVkIG5vdCB0byBvcGVuIHRoaXMgY2FuIG9mIHdv cm1zIGJlY2F1c2Ugbm8gZ29vZCB3b3VsZCBjb21lIG9mIGl0Lg0KDQpUaGUgdG9rZW5fZW5kcG9p bnQgcmV0dXJucyBhIGFjY2VzcyB0b2tlbi4gIE5vdGhpbmcgcmVxdWlyZXMgc2NvcGUgdG8gYmUg YXNzb2NpYXRlcyB3aXRoIHRoZSB0b2tlbi4NCg0KVGhhdCBpcyB0aGUgYmVzdCBzb2x1dGlvbi4g IE5vIGNoYW5nZSByZXF1aXJlZC4gIEJldHRlciBpbnRlcm9wZXJhYmlsaXR5IGluIG15IG9waW5p b24uDQoNClN0aWxsIG9uIG15IHdheSB0byBUTywgZ2V0dGluZyBpbiBsYXRlciB0b2RheS4NCg0K Sm9obiBCLg0KDQoNCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiBKdWwgMjMsIDIwMTQsIGF0 IDEyOjE1IFBNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQ+IHdyb3RlOg0KDQpUaGUgInJlc3BvbnNlIHR5cGUiIG9mIHRoZSB0b2tlbiBlbmRw b2ludCBpcyBjb250cm9sbGVkIGJ5IHRoZSB2YWx1ZSBvZiB0aGUgcGFyYW1ldGVyICJncmFudF90 eXBlIi4gU28gdGhlcmUgaXMgbm8gbmVlZCB0byBpbnRyb2R1Y2UgYSBuZXcgcGFyYW1ldGVyLg0K DQp3cnQgdG8gYSBwb3RlbnRpYWwgIm5vX2FjY2Vzc190b2tlbiIgZ3JhbnQgdHlwZS4gSSBkbyBu b3QgY29uc2lkZXIgdGhpcyBhIGdvb2QgaWRlYSBhcyBpdCBjaGFuZ2VzIHRoZSBzZW1hbnRpY3Mg b2YgdGhlIHRva2VuIGVuZHBvaW50IChhcyBhbHJlYWR5IHBvaW50ZWQgb3V0IGJ5IFRob21hcyku IFRoaXMgZW5kcG9pbnQgQUxXQVlTIHJlc3BvbmRzIHdpdGggYW4gYWNjZXNzIHRva2VuIHRvIGFu eSBncmFudCB0eXBlLiBJIHRoZXJlZm9yZSB3b3VsZCBwcmVmZXIgdG8gdXNlIGFub3RoZXIgZW5k cG9pbnQgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlLg0KDQpyZWdhcmRzLA0KVG9yc3Rlbi4NCg0K DQoNCkFtIDIzLjA3LjIwMTQgMTM6MDQsIHNjaHJpZWIgTmF0IFNha2ltdXJhOg0KSU1ITywgY2hh bmdpbmcgdGhlIHNlbWFudGljcyBvZiAicmVzcG9uc2VfdHlwZSIgQCBhdXRoeiBlbmRwb2ludCB0 aGlzIHdheSBpcyBub3QgYSBnb29kIHRoaW5nLg0KDQpJbnN0ZWFkLCBkZWZpbmluZyBhIG5ldyBw YXJhbWV0ZXIgInJlc3BvbnNlX3R5cGUiIEAgdG9rZW4gZW5kcG9pbnQsIGFzIEkgZGVzY3JpYmVk IGluIG15IHByZXZpb3VzIG1lc3NhZ2UsDQpwcm9iYWJseSBpcyBiZXR0ZXIuIEF0IGxlYXN0LCBp dCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiB0aGUgcGFyYW1ldGVycyBvZiBSRkM2 NzQ5Lg0KDQogTmF0DQoNCjIwMTQtMDctMjMgMTI6NDggR01ULTA0OjAwIFRob21hcyBCcm95ZXIg PHQuYnJveWVyQGdtYWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPj46DQpObywgSSBt ZWFuIHJlc3BvbnNlX3R5cGU9bm9uZSBhbmQgcmVzcG9uc2VfdHlwZT1pZF90b2tlbiBkb24ndCBn ZW5lcmF0ZSBhIGNvZGUgb3IgYWNjZXNzIHRva2VuIHNvIHlvdSBkb24ndCB1c2UgdGhlIFRva2Vu IEVuZHBvaW50ICh3aGljaCBpcyBub3QgdGhlIHNhbWUgYXMgdGhlIEF1dGhlbnRpY2F0aW9uIEVu ZHBvaW50IEJUVykuDQpXaXRoIHJlc3BvbnNlX3R5cGU9Y29kZV9mb3JfaWRfdG9rZW4sIHlvdSBn ZXQgYSBjb2RlIGFuZCBleGNoYW5nZSBpdCBmb3IgYW4gaWRfdG9rZW4gb25seSwgcmF0aGVyIHRo YW4gYW4gYWNjZXNzX3Rva2VuLCBzbyB5b3UncmUgY2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiB0 aGUgVG9rZW4gRW5kcG9pbnQuDQoNCkknbSBub3Qgc2F5aW5nIGl0J3MgYSBiYWQgdGhpbmcsIGp1 c3QgdGhhdCB5b3UgY2FuJ3QgcmVhbGx5IGNvbXBhcmUgbm9uZSBhbmQgaWRfdG9rZW4gd2l0aCBj b2RlX2Zvcl9pZF90b2tlbi4NCg0KT24gV2VkLCBKdWwgMjMsIDIwMTQgYXQgNjo0NSBQTSwgUmlj aGVyLCBKdXN0aW4gUC4gPGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9y Zz4+IHdyb3RlOg0KSXQncyBvbmx5ICJub3QgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50IiBiZWNh dXNlIHRoZSB0b2tlbiBlbmRwb2ludCBjb3B5LXBhc3RlZCBhbmQgcmVuYW1lZCB0aGUgYXV0aGVu dGljYXRpb24gZW5kcG9pbnQuDQoNCiAtLSBKdXN0aW4NCg0KT24gSnVsIDIzLCAyMDE0LCBhdCA5 OjMwIEFNLCBUaG9tYXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVy QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCkV4Y2VwdCB0aGF0IHRoZXNlIGFyZSBhYm91dCBub3Qg dXNpbmcgdGhlIFRva2VuIEVuZHBvaW50IGF0IGFsbCwgd2hlcmVhcyB0aGUgY3VycmVudCBwcm9w b3NhbCBpcyBhYm91dCB0aGUgVG9rZW4gRW5kcG9pbnQgbm90IHJldHVybmluZyBhbiBhY2Nlc3Nf dG9rZW4gZmllbGQgaW4gdGhlIEpTT04uDQoNCk9uIFdlZCwgSnVsIDIzLCAyMDE0IGF0IDQ6MjYg UE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUaGUgcmVzcG9uc2VfdHlwZSAibm9uZSIg aXMgYWxyZWFkeSB1c2VkIGluIHByYWN0aWNlLCB3aGljaCByZXR1cm5zIG5vIGFjY2VzcyB0b2tl bi4gIEl0IHdhcyBhY2NlcHRlZCBieSB0aGUgZGVzaWduYXRlZCBleHBlcnRzIGFuZCByZWdpc3Rl cmVkIGluIHRoZSBJQU5BIE9BdXRoIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2UgVHlw ZXMgcmVnaXN0cnkgYXQgaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJh bWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueG1sI2VuZHBvaW50LiAgVGhlIHJlZ2lzdGVyZWQgImlk X3Rva2VuIiByZXNwb25zZSB0eXBlIGFsc28gcmV0dXJucyBubyBhY2Nlc3MgdG9rZW4uDQoNClNv IEkgdGhpbmsgdGhlIHF1ZXN0aW9uIG9mIHdoZXRoZXIgcmVzcG9uc2UgdHlwZXMgdGhhdCByZXN1 bHQgaW4gbm8gYWNjZXNzIHRva2VuIGJlaW5nIHJldHVybmVkIGFyZSBhY2NlcHRhYmxlIHdpdGhp biBPQXV0aCAyLjAgaXMgYWxyZWFkeSBzZXR0bGVkLCBhcyBhIHByYWN0aWNhbCBtYXR0ZXIuICBM b3RzIG9mIE9BdXRoIGltcGxlbWVudGF0aW9ucyBhcmUgYWxyZWFkeSB1c2luZyBzdWNoIHJlc3Bv bnNlIHR5cGVzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP ZiBQaGlsIEh1bnQNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMywgMjAxNCA3OjA5IEFNDQpUbzog TmF0IFNha2ltdXJhDQpDYzogPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0DQoNClllcy4gVGhpcyBpcyB3aHkgaXQg aGFzIHRvIGJlIGRpc2N1c3NlZCBpbiB0aGUgSUVURi4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRp ZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0K cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0K T24gSnVsIDIzLCAyMDE0LCBhdCA5OjQzIEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWls LmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQoNClJlYWRpbmcgYmFjayB0 aGUgUkZDNjc0OSwgSSBhbSBub3Qgc3VyZSBpZiB0aGVyZSBpcyBhIGdvb2Qgd2F5IG9mIHN1cHBy ZXNzaW5nIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSByZXNwb25zZSBhbmQgc3RpbGwgYmUgT0F1dGgu IEl0IHdpbGwgYnJlYWsgd2hvbGUgYnVuY2ggb2YgaW1wbGljaXQgZGVmaW5pdGlvbnMgbGlrZToN Cg0KYXV0aG9yaXphdGlvbiBzZXJ2ZXINCiAgICAgIFRoZSBzZXJ2ZXIgaXNzdWluZyBhY2Nlc3Mg dG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0ZXIgc3VjY2Vzc2Z1bGx5DQogICAgICBhdXRoZW50aWNh dGluZyB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIG9idGFpbmluZyBhdXRob3JpemF0aW9uLg0KDQpB ZnRlciBhbGwsIE9BdXRoIGlzIGFsbCBhYm91dCBpc3N1aW5nIGFjY2VzcyB0b2tlbnMuDQoNCkFs c28sIEkgdGFrZSBiYWNrIG15IHN0YXRlbWVudCBvbiB0aGUgZ3JhbnQgdHlwZSBpbiBteSBwcmV2 aW91cyBtYWlsLg0KDQpUaGUgZGVmaW5pdGlvbiBvZiBncmFudCBhbmQgZ3JhbnRfdHlwZSBhcmUg cmVzcGVjdGl2ZWx5Og0KDQpncmFudA0KICAgIGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSBy ZXNvdXJjZSBvd25lcidzIGF1dGhvcml6YXRpb24NCg0KZ3JhbnRfdHlwZQ0KICAgIChzdHJpbmcg cmVwcmVzZW50aW5nIHRoZSkgdHlwZSBvZiBncmFudCBzZW50IHRvIHRoZSB0b2tlbiBlbmRwb2lu dCB0byBvYnRhaW4gdGhlIGFjY2VzcyB0b2tlbg0KDQpUaHVzLCB0aGUgZ3JhbnQgc2VudCB0byB0 aGUgdG9rZW4gZW5kcG9pbnQgaW4gdGhpcyBjYXNlIGlzIHN0aWxsICdjb2RlJy4NCg0KUmVzcG9u c2UgdHlwZSBvbiB0aGUgb3RoZXIgaGFuZCBpcyBub3Qgc28gd2VsbCBkZWZpbmVkIGluIFJGQzY3 NDksIGJ1dCBpdCBzZWVtcyBpdCBpcyByZXByZXNlbnRpbmcgd2hhdCBpcyB0byBiZSByZXR1cm5l ZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBUbyBleHByZXNzIHdoYXQgaXMgdG8g YmUgcmV0dXJuZWQgZnJvbSB0b2tlbiBlbmRwb2ludCwgcGVyaGFwcyBkZWZpbmluZyBhIG5ldyBw YXJhbWV0ZXIgdG8gdGhlIHRva2VuIGVuZHBvaW50LCB3aGljaCBpcyBhIHBhcmFsbGVsIHRvIHRo ZSByZXNwb25zZV90eXBlIHRvIHRoZSBBdXRob3JpemF0aW9uIEVuZHBvaW50IHNlZW1zIHRvIGJl IGEgbW9yZSBzeW1tZXRyaWMgd2F5LCB0aG91Z2ggSSBhbSBub3Qgc3VyZSBhdCBhbGwgaWYgdGhh dCBpcyBnb2luZyB0byBiZSBPQXV0aCBhbnkgbW9yZS4gT25lIHN0cmF3LW1hbiBpcyB0byBkZWZp bmUgYSBuZXcgcGFyYW1ldGVyIGNhbGxlZCByZXNwb25zZV90eXBlIHRvIHRoZSB0b2tlbiBlbmRw b2ludCBzdWNoIGFzOg0KDQpyZXNwb25zZV90eXBlDQogICAgT1BUSU9OQUwuIEEgc3RyaW5nIHJl cHJlc2VudGluZyB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50 Lg0KDQpUaGVuIGRlZmluZSB0aGUgYmVoYXZpb3Igb2YgdGhlIGVuZHBvaW50IGFjY29yZGluZyB0 byB0aGUgdmFsdWVzIGFzIHRoZSBwYXJhbGxlbCB0byB0aGUgbXVsdGktcmVzcG9uc2UgdHlwZSBz cGVjLg0KaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb2F1dGgtdjItbXVsdGlwbGUtcmVzcG9uc2Ut dHlwZXMtMV8wLmh0bWwNCg0KTmF0DQoNCg0KDQoNCjIwMTQtMDctMjMgNzoyMSBHTVQtMDQ6MDAg UGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5j b20+PjoNClRoZSBkcmFmdCBpcyB2ZXJ5IGNsZWFyLg0KDQpQaGlsDQoNCk9uIEp1bCAyMywgMjAx NCwgYXQgMDo0NiwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2lt dXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhlIG5ldyBncmFudCB0eXBlIHRoYXQgSSB3YXMgdGFs a2luZyBhYm91dCB3YXMNCiJhdXRob3JpemF0aW9uX2NvZGVfYnV0X2RvX25vdF9yZXR1cm5fYWNj ZXNzX25vcl9yZWZyZXNoX3Rva2VuIiwgc28gdG8gc3BlYWsuDQpJdCBkb2VzIG5vdCByZXR1cm4g YW55dGhpbmcgcGVyIHNlLCBidXQgYW4gZXh0ZW5zaW9uIGNhbiBkZWZpbmUgc29tZXRoaW5nIG9u IHRvcCBvZiBpdC4NCg0KVGhlbiwgT0lEQyBjYW4gZGVmaW5lIGEgYmluZGluZyB0byBpdCBzbyB0 aGF0IHRoZSBiaW5kaW5nIG9ubHkgcmV0dXJucyBJRCBUb2tlbi4NClRoaXMgYmluZGluZyB3b3Jr IHNob3VsZCBiZSBkb25lIGluIE9JREYuIFNob3VsZCB0aGVyZSBiZSBzdWNoIGEgZ3JhbnQgdHlw ZSwNCml0IHdpbGwgYmUgYW4gZXh0cmVtZWx5IHNob3J0IHNwZWMuDQoNCkF0IHRoZSBzYW1lIHRp bWUsIGlmIGFueSBvdGhlciBzcGVjaWZpY2F0aW9uIHdhbnRlZCB0byBkZWZpbmUNCm90aGVyIHR5 cGUgb2YgdG9rZW5zIGFuZCBoYXZlIGl0IHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50 LA0KaXQgY2FuIGFsc28gdXNlIHRoaXMgZ3JhbnQgdHlwZS4NCg0KSWYgd2hhdCB5b3Ugd2FudCBp cyB0byBkZWZpbmUgYSBuZXcgZ3JhbnQgdHlwZSB0aGF0IHJldHVybnMgSUQgVG9rZW4gb25seSwN CnRoZW4sIEkgYW0gd2l0aCBKdXN0aW4uIFNpbmNlICJvdGhlciByZXNwb25zZSB0aGFuIElEIFRv a2VuIiBpcyBvbmx5DQp0aGVvcmV0aWNhbCwgdGhpcyBpcyBhIG1vcmUgcGxhdXNpYmxlIHdheSBm b3J3YXJkLCBJIHN1cHBvc2UuDQoNCk5hdA0KDQoyMDE0LTA3LTIyIDE0OjMwIEdNVC0wNDowMCBK dXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+Og0K U28gdGhlIGRyYWZ0IHdvdWxkIGxpdGVyYWxseSB0dXJuIGludG86DQoNCiJUaGUgYTRjIHJlc3Bv bnNlIHR5cGUgYW5kIGdyYW50IHR5cGUgcmV0dXJuIGFuIGlkX3Rva2VuIGZyb20gdGhlIHRva2Vu IGVuZHBvaW50IHdpdGggbm8gYWNjZXNzIHRva2VuLiBBbGwgcGFyYW1ldGVycyBhbmQgdmFsdWVz IGFyZSBkZWZpbmVkIGluIE9JREMuIg0KDQpTZWVtcyBsaWtlIHRoZSBwZXJmZWN0IG1pbmkgZXh0 ZW5zaW9uIGRyYWZ0IGZvciBPSURGIHRvIGRvLg0KDQotLUp1c3Rpbg0KDQovc2VudCBmcm9tIG15 IHBob25lLw0KDQpPbiBKdWwgMjIsIDIwMTQgMTA6MjkgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11 cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4gV2hh dCBhYm91dCBqdXN0IGRlZmluaW5nIGEgbmV3IGdyYW50IHR5cGUgaW4gdGhpcyBXRz8NCj4NCj4N Cj4gMjAxNC0wNy0yMiAxMjo1NiBHTVQtMDQ6MDAgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xl LmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PjoNCj4+DQo+PiBUaGF0IHdvdWxkIGJl IG5pY2UuIEhvd2V2ZXIgb2lkYyBzdGlsbCBuZWVkcyB0aGUgbmV3IGdyYW50IHR5cGUgaW4gb3Jk ZXIgdG8gaW1wbGVtZW50IHRoZSBzYW1lIGZsb3cuDQo+Pg0KPj4gUGhpbA0KPj4NCj4+IE9uIEp1 bCAyMiwgMjAxNCwgYXQgMTE6MzUsIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1h aWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCj4+DQo+Pj4gKzEgdG8gSnVzdGluLg0K Pj4+DQo+Pj4NCj4+PiAyMDE0LTA3LTIyIDk6NTQgR01ULTA0OjAwIFJpY2hlciwgSnVzdGluIFAu IDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+PjoNCj4+Pj4NCj4+ Pj4gRXJyb3JzIGxpa2UgdGhlc2UgbWFrZSBpdCBjbGVhciB0byBtZSB0aGF0IGl0IHdvdWxkIG1h a2UgbXVjaCBtb3JlIHNlbnNlIHRvIGRldmVsb3AgdGhpcyBkb2N1bWVudCBpbiB0aGUgT3BlbklE IEZvdW5kYXRpb24uIEl0IHNob3VsZCBiZSBzb21ldGhpbmcgdGhhdCBkaXJlY3RseSByZWZlcmVu Y2VzIE9wZW5JRCBDb25uZWN0IENvcmUgZm9yIGFsbCBvZiB0aGVzZSB0ZXJtcyBpbnN0ZWFkIG9m IHJlZGVmaW5pbmcgdGhlbS4gSXQncyBkb2luZyBhdXRoZW50aWNhdGlvbiwgd2hpY2ggaXMgZnVu ZGFtZW50YWxseSB3aGF0IE9wZW5JRCBDb25uZWN0IGRvZXMgb24gdG9wIG9mIE9BdXRoLCBhbmQg SSBkb24ndCBzZWUgYSBnb29kIGFyZ3VtZW50IGZvciBkb2luZyB0aGlzIHdvcmsgaW4gdGhpcyB3 b3JraW5nIGdyb3VwLg0KPj4+Pg0KPj4+PiAgLS0gSnVzdGluDQo+Pj4+DQo+Pj4+IE9uIEp1bCAy MiwgMjAxNCwgYXQgNDozMCBBTSwgVGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPG1h aWx0bzp0LmJyb3llckBnbWFpbC5jb20+PiB3cm90ZToNCj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+ Pj4NCj4+Pj4+IE9uIE1vbiwgSnVsIDIxLCAyMDE0IGF0IDExOjUyIFBNLCBNaWtlIEpvbmVzIDxN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4gVGhhbmtzIGZvciB5b3VyIHJldmlldywgVGhv bWFzLiAgVGhlICJwcm9tcHQ9Y29uc2VudCIgZGVmaW5pdGlvbiBiZWluZyBtaXNzaW5nIGlzIGFu IGVkaXRvcmlhbCBlcnJvci4gIEl0IHNob3VsZCBiZToNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4N Cj4+Pj4+PiBjb25zZW50DQo+Pj4+Pj4NCj4+Pj4+PiBUaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIg U0hPVUxEIHByb21wdCB0aGUgRW5kLVVzZXIgZm9yIGNvbnNlbnQgYmVmb3JlIHJldHVybmluZyBp bmZvcm1hdGlvbiB0byB0aGUgQ2xpZW50LiBJZiBpdCBjYW5ub3Qgb2J0YWluIGNvbnNlbnQsIGl0 IE1VU1QgcmV0dXJuIGFuIGVycm9yLCB0eXBpY2FsbHkgY29uc2VudF9yZXF1aXJlZC4NCj4+Pj4+ Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBJJ2xsIHBsYW4gdG8gYWRkIGl0IGluIHRoZSBuZXh0 IGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBJdCBsb29rcyBsaWtlIHRoZSBjb25zZW50X3Jl cXVpcmVkIGVycm9yIG5lZWRzIHRvIGJlIGRlZmluZWQgdG9vLCBhbmQgeW91IG1pZ2h0IGhhdmUg Zm9yZ290dGVuIHRvIGFsc28gaW1wb3J0IGFjY291bnRfc2VsZWN0aW9uX3JlcXVpcmVkIGZyb20g T3BlbklEIENvbm5lY3QuDQo+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEkg YWdyZWUgdGhhdCB0aGVyZSdzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJlc3BvbnNlIHdpdGgg bXVsdGlwbGUgImFtciIgdmFsdWVzIHRoYXQgaW5jbHVkZXMgIm1mYSIgYW5kIG9uZSB0aGF0IGRv ZXNuJ3QuICBVbmxlc3MgYSBjbGVhciB1c2UgY2FzZSBmb3Igd2h5ICJtZmEiIGlzIG5lZWRlZCBj YW4gYmUgaWRlbnRpZmllZCwgd2UgY2FuIGRlbGV0ZSBpdCBpbiB0aGUgbmV4dCBkcmFmdC4NCj4+ Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzLg0KPj4+Pj4NCj4+Pj4+IEhvdyBhYm91dCAicHdkIiB0 aGVuPyBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhhdCBJIHNob3VsZCByZXR1cm4gInB3ZCIgaWYgdGhl IHVzZXIgYXV0aGVudGljYXRlZCB1c2luZyBhIHBhc3N3b3JkLCBidXQgd2hhdCAidGhlIHNlcnZp Y2UgaWYgYSBjbGllbnQgc2VjcmV0IGlzIHVzZWQiIG1lYW5zIGluIHRoZSBkZWZpbml0aW9uIGZv ciB0aGUgInB3ZCIgdmFsdWU/DQo+Pj4+Pg0KPj4+Pj4gKE5vdGE6IEkga25vdyB5b3UncmUgYXQg SUVURi05MCwgSSdtIHJlYWR5IHRvIHdhaXQgJ3RpbCB5b3UgY29tZSBiYWNrIDstKSApDQo+Pj4+ Pg0KPj4+Pj4gLS0NCj4+Pj4+IFRob21hcyBCcm95ZXINCj4+Pj4+IC90yZQubWEuYsqBd2EuamUv PGh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhiLmplLz4NCj4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBPQXV0aCBtYWlsaW5nIGxp c3QNCj4+Pj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4+Pj4NCj4+Pj4NCj4+ Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KPj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IC0tDQo+Pj4gTmF0IFNha2ltdXJhICg9bmF0 KQ0KPj4+IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KPj4+IGh0dHA6Ly9uYXQuc2FraW11 cmEub3JnLw0KPj4+IEBfbmF0X2VuDQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+IE9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+DQo+DQo+DQo+DQo+IC0tDQo+IE5hdCBTYWtpbXVy YSAoPW5hdCkNCj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQo+IGh0dHA6Ly9uYXQuc2Fr aW11cmEub3JnLw0KPiBAX25hdF9lbg0KDQoNCg0KLS0NCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNo YWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQpAX25h dF9lbg0KDQoNCg0KLS0NCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91 bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQpAX25hdF9lbg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpUaG9tYXMgQnJveWVyDQov dMmULm1hLmLKgXdhLmplLzxodHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KVGhvbWFzIEJyb3ll cg0KL3TJlC5tYS5iyoF3YS5qZS88aHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvPg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KTmF0IFNh a2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNh a2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1 dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoNCi0tDQpO YXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHA6Ly9u YXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8 bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aA0KDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9w ZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQoNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZv dW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz dA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg0K --_000_59B4FD06C1E24629B46B09A6E00EDB57mitreorg_ Content-Type: text/html; charset="utf-8" Content-ID: <6B5DEB1C7539F14997D4137842D4AE7E@imc.mitre.org> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KSSdsbCBzZWNvbmQgdGhpcyBzZW50aW1lbnQuIElh bidzIG92ZXJhbGwgdGFsayB3YXMgYWJvdXQgd2hlbiByZWludmVudGluZyB3aGVlbHMgd2FzIGEg Z29vZCB0aGluZyAobGlrZSBYTUwgLSZndDsgSlNPTiksIGFuZCBoZSBjYWxsZWQgb3V0IEE0QyBz cGVjaWZpY2FsbHkgYXMgYW4gZXhhbXBsZSBvZiByZWludmVudGlvbiBmb3IgaXRzIG93biBzYWtl LCBhIGhhcm1mdWwgYW5kIHdhc3RlZnVsIHByYWN0aWNlLiBJdCB3YXMgYSB2ZXJ5IGdvb2Qga2V5 bm90ZQ0KIHRhbGssIGFuZCBJIGhpZ2hseSByZWNvbW1lbmQgdGhhdCBwZW9wbGUgcmVhZCB0aGUg YmxvZyBwb3N0KHMpIGFuZCBsb29rIGZvciB0aGUgdmlkZW9zIG9uY2UgdGhleSdyZSBwb3N0ZWQu DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDstLSBKdXN0aW48L2Rpdj4NCjxkaXY+PGJy Pg0KPGRpdj4NCjxkaXY+T24gSnVsIDI0LCAyMDE0LCBhdCA5OjUyIEFNLCBCcmlhbiBDYW1wYmVs bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5iY2FtcGJl bGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBs ZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBk aXI9Imx0ciI+SSdkIG5vdGUgdGhhdCB0aGUgcmVhY3Rpb24gYXQgdGhlIGNvbmZlcmVuY2UgdG8g SWFuJ3Mgc3RhdGVtZW50IHdhcyBvdmVyd2hlbG1pbmdseSBwb3NpdGl2ZS4gVGhlcmUgd2FzIGEg d2lkZSByYW5nZSBvZiBpbmR1c3RyeSBwZW9wbGUgaGVyZSAtIGltcGxlbWVudGVycywgcHJhY3Rp dGlvbmVycywgZGVwbG95ZXJzLCBzdHJhdGVnaXN0cywgZXRjLiAtIGFuZCBpdCBzZWVtcyBwcmV0 dHkgY2xlYXIgdGhhdCB0aGUgJnF1b3Q7cm91Z2gNCiBjb25zZW5zdXMmcXVvdDsgb2YgdGhlIGlu ZHVzdHJ5IGF0IGxhcmdlIGlzIHRoYXQgYTRjIGlzIG5vdCB3YW50ZWQgb3IgbmVlZGVkLjxicj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxicj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj5PbiBUaHUsIEp1bCAyNCwgMjAxNCBhdCA1OjI5IEFNLCBOYXQgU2FraW11 cmEgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3Jv dGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8 ZGl2IGRpcj0ibHRyIj5BbmQgaGVyZSBpcyBhIHF1b3RlIGZyb20gSWFuJ3MgYmxvZy4mbmJzcDsN CjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQtd2lkdGg6MXB4O2JvcmRlci1s ZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7cGFkZGlu Zy1sZWZ0OjFleCI+DQpBbmQgYWx0aG91Z2ggdGhlIGF1dGhlbnRpY2F0aW9uIHdoZWVsIGlzIHJv dW5kLCB0aGF0IGRvZXNu4oCZdCBtZWFuIGl0IGlzbuKAmXQgd2l0aG91dCBpdHMgbHVtcHMuIEZp cnN0LCB3ZSBkbyBzZWUgc29tZSByZWludmVudGluZyB0aGUgd2hlZWwganVzdCB0byByZWludmVu dCB0aGUgd2hlZWwuIE9BdXRoIEE0QyBpcyBzaW1wbHkgbm90IGEgZnJ1aXRmdWwgYWN0aXZpdHkg YW5kIHNob3VsZCBiZSBwdXQgZG93bi4gJm5ic3A7PC9ibG9ja3F1b3RlPg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHgg MHB4IDBweCAwLjhleDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtY29sb3I6cmdi KDIwNCwyMDQsMjA0KTtib3JkZXItbGVmdC1zdHlsZTpzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4N CihTb3VyY2UpIDxhIGhyZWY9Imh0dHA6Ly93d3cudHVlc2RheW5pZ2h0Lm9yZy8yMDE0LzA3LzIz L2RvLXdlLWhhdmUtYS1yb3VuZC13aGVlbC15ZXQtbXVzaW5ncy1vbi1pZGVudGl0eS1zdGFuZGFy ZHMtcGFydC0xLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cudHVlc2RheW5pZ2h0 Lm9yZy8yMDE0LzA3LzIzL2RvLXdlLWhhdmUtYS1yb3VuZC13aGVlbC15ZXQtbXVzaW5ncy1vbi1p ZGVudGl0eS1zdGFuZGFyZHMtcGFydC0xLmh0bWw8L2E+PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPjIwMTQtMDctMjMgMTY6NTMgR01ULTA0OjAwIEpvaG4gQnJhZGxleSA8c3BhbiBkaXI9Imx0 ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozwvc3Bhbj46DQo8ZGl2Pg0KPGRpdiBjbGFzcz0i aDUiPjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjow IDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0K PGRpdiBkaXI9ImF1dG8iPg0KPGRpdj5JIHRob3VnaHQgSSBkaWQgcG9zdCB0aGlzIHRvIHRoZSBs aXN0LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBndWVzcyBJIGhpdCB0 aGUgd3JvbmcgcmVwbHkgb24gbXkgcGhvbmUuJm5ic3A7PGJyPg0KJm5ic3A7PC9kaXY+DQo8ZGl2 PkpvaG4gQi4mbmJzcDs8YnI+DQpTZW50IGZyb20gbXkgaVBob25lPC9kaXY+DQo8ZGl2Pjxicj4N Ck9uIEp1bCAyMywgMjAxNCwgYXQgNDo1MCBQTSwgPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+DQp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwv YT4gd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxw PndlIGFyZSB0d28sIGF0IGxlYXN0IDotKTwvcD4NCjxwPldoeSBkaWRuJ3QgeW91IHBvc3QgdGhp cyBvbiB0aGUgbGlzdD88L3A+DQo8cD5XaGVuIHdpbGwgYmUgYmUgYXJyaXZpbmc/PC9wPg0KPHA+ QW0gMjMuMDcuMjAxNCAxNjozOSwgc2NocmllYiBKb2huIEJyYWRsZXk6PC9wPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgc3R5bGU9InBhZGRpbmctbGVmdDo1cHg7Ym9yZGVyLWxlZnQ6IzEwMTBm ZiAycHggc29saWQ7bWFyZ2luLWxlZnQ6NXB4Ij4NCjxkaXY+SWFuIEdsYXplciBtZW50aW9uZWQg dGhpcyBpbiBoaXMga2V5bm90ZSBhdCBDSVMgeWVzdGVyZGF5LiZuYnNwOzwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+SGlzIGFkdmljZSB3YXMgcGxlYXNlIHN0b3AsICZuYnNwO3dlIGFy ZSBjcmVhdGluZyBjb25mdXNpb24gYW5kIHVuY2VydGFpbnR5LiZuYnNwOzwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+V2UgYXJlIGJlY29taW5nIG91ciBvd24gd29ydCBlbmVteS4gKCBt eSB2aWV3IHRob3VnaCBJYW4gbWF5IHNoYXJlIGl0KTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+UmV0dXJuaW5nIGp1c3QgYW4gaWRfIHRva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50 IGhhcyBsaXR0bGUgcmVhbCB2YWx1ZS4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PlNvbWV0aGluZyByZWFsbHkgdXNlZnVsIHRvIGRvIHdvdWxkIGJlIHNvcnRpbmcgb3V0IGNo YW5uZWxfaWQgc28gd2UgY2FuIGRvIFBvUCBmb3IgaWQgdG9rZW5zIHRvIG1ha2UgdGhlbSBhbmQg b3RoZXIgY29va2llcyBzZWN1cmUgaW4gdGhlIGZyb250IGNoYW5uZWwuICZuYnNwOyBJIHRoaW5r IHRoYXQgaXMgYSBiZXR0ZXIgdXNlIG9mIHRpbWUuJm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj5JIG1heSBiZSBpbiB0aGUgbWlub3JpdHkgb3BpbmlvbiBvbiB0aGF0LCAmbmJz cDtpdCB3b24ndCBiZSB0aGUgZmlyc3QgdGltZS4gJm5ic3A7DQo8ZGl2Pjxicj4NCjxicj4NCkpv aG4gQi4mbmJzcDs8YnI+DQpTZW50IGZyb20gbXkgaVBob25lPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pjxicj4NCk9uIEp1bCAyMywgMjAxNCwgYXQgNDowNCBQTSwgVG9yc3RlbiBMb2RkZXJz dGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9 Il9ibGFuayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJwYWRkaW5nLWxlZnQ6NXB4 O2JvcmRlci1sZWZ0OiMxMDEwZmYgMnB4IHNvbGlkO21hcmdpbi1sZWZ0OjVweCI+DQo8ZGl2Pg0K PGRpdj5Zb3UgYXJlIHJpZ2h0IGZyb20gYSB0aGVvcmV0aWNhbCBwZXJzcGVjdGl2ZS4gUHJhY3Rp Y2FsbHkgdGhpcyB3YXMgY2F1c2VkIGJ5IGVkaXRvcmlhbCBkZWNpc2lvbnMgZHVyaW5nIHRoZSBj cmVhdGlvbiBvZiB0aGUgUkZDLiBBcyBmYXIgYXMgSSByZW1lbWJlciwgdGhlcmUgd2FzIGEgZGVm aW5pdGlvbiBvZiB0aGUgKG9uZSkgdG9rZW4gZW5kcG9pbnQgcmVzcG9uc2UgaW4gZWFybHkgdmVy c2lvbnMuIE5vIG9uZSBldmVyeSBjb25zaWRlcmVkDQogdG8gTk9UIHJlc3BvbmQgd2l0aCBhbiBh Y2Nlc3MgdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQuIFNvIG9uZSBtaWdodCBjYWxsIGl0 IGFuIGltcGxpY2l0IGFzc3VtcHRpb24uPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5J J20gd29ycmllZCB0aGF0IHBlb3BsZSBnZXQgdG90YWxseSBjb25mdXNlZCBpZiBhbiBleGNlcHRp b24gaXMgaW50cm9kdWNlZCBub3cgZ2l2ZW4gdGhlIGJyb2FkIGFkb3B0aW9uIG9mIE9BdXRoIGJh c2VkIG9uIHRoaXMgYXNzdW1wdGlvbi48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PnJl Z2FyZHMsPC9kaXY+DQo8ZGl2PlRvcnN0ZW4uPC9kaXY+DQo8ZGl2Pjxicj4NCkFtIDIzLjA3LjIw MTQgdW0gMTU6NDEgc2NocmllYiBUaG9tYXMgQnJveWVyICZsdDs8YSBocmVmPSJtYWlsdG86dC5i cm95ZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dC5icm95ZXJAZ21haWwuY29tPC9hPiZn dDs6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0icGFk ZGluZy1sZWZ0OjVweDtib3JkZXItbGVmdDojMTAxMGZmIDJweCBzb2xpZDttYXJnaW4tbGVmdDo1 cHgiPg0KPGRpdj4NCjxwIGRpcj0ibHRyIj5JcyBpdCBzYWlkIGFueXdoZXJlIHRoYXQgQUxMIGdy YW50IHR5cGVzIE1VU1QgdXNlIFNlY3Rpb24gNS4xIHJlc3BvbnNlcz8gRWFjaCBncmFudCB0eXBl IHJlZmVyZW5jZXMgU2VjdGlvbiA1LjEsIGFuZCAmcXVvdDthY2Nlc3MgdG9rZW4gcmVxdWVzdCZx dW90OyBpcyBvbmx5IGRlZmluZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGRlZmluZWQgZ3JhbnQg dHlwZXMuIFNlY3Rpb24gMi4yIGRvZXNuJ3QgdGFsayBhYm91dCB0aGUgcmVxdWVzdCBvcg0KIHJl c3BvbnNlIGZvcm1hdC48L3A+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+TGUgMjMganVpbC4g MjAxNCAyMTozMiwgJnF1b3Q7TmF0IFNha2ltdXJhJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9h PiZndDsgYSDDqWNyaXQgOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct bGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+SXMgaXQ/IEFwYXJ0IGZyb20gdGhlIGltcGxpY2l0 IGdyYW50IHRoYXQgZG9lcyBub3QgdXNlIHRva2VuIGVuZHBvaW50LCBhbGwgb3RoZXIgZ3JhbnQg cmVmZXJlbmNlcyBzZWN0aW9uIDUuMSBmb3IgdGhlIHJlc3BvbnNlLCBpLmUuLCBhbGwgc2hhcmVz IHRoZSBzYW1lIHJlc3BvbnNlLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEi Pjxicj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDE0LTA3LTIzIDE1OjE4IEdN VC0wNDowMCBUaG9tYXMgQnJveWVyIDxzcGFuPiZsdDs8YSBocmVmPSJtYWlsdG86dC5icm95ZXJA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDs8L3Nw YW4+Ojxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjow IDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0K PHAgZGlyPSJsdHIiPkkgaGFkbid0IHJlYWxpemVkIHRoZSBKU09OIHJlc3BvbnNlIHRoYXQgcmVx dWlyZXMgdGhlIGFjY2Vzc190b2tlbiBmaWVsZCBpcyBkZWZpbmVkIHBlciBncmFudF90eXBlLCBz byBJJ2QgYmUgT0sgdG8gJnF1b3Q7ZXh0ZW5kIHRoZSBzZW1hbnRpY3MmcXVvdDsgYXMgaW4gdGhl IGN1cnJlbnQgZHJhZnQuPGJyPg0KVGhhdCB3YXMgYWN0dWFsbHkgbXkgbWFpbiBjb25jZXJuOiB0 aGF0IHRoZSB0b2tlbiBlbmRwb2ludCBtYW5kYXRlcyBhY2Nlc3NfdG9rZW47IGJ1dCBpdHMgYWN0 dWFsbHkgbm90IHRoZSBjYXNlLjwvcD4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5MZSAyMyBq dWlsLiAyMDE0IDIwOjQ2LCAmcXVvdDtOYXQgU2FraW11cmEmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5j b208L2E+Jmd0OyBhIMOpY3JpdCA6DQo8ZGl2Pg0KPGRpdj48YnI+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5JIGFn cmVlIHdpdGggSm9obiB0aGF0IG92ZXJsb2FkaW5nIHJlc3BvbnNlX3R5cGUgQCBhdXRoeiBlbmRw b2ludCBpcyBhIGJhZCBpZGVhLiBJdCBjb21wbGV0ZWx5IGNoYW5nZXMgdGhlIHNlbWFudGljcyBv ZiB0aGlzIHBhcmFtZXRlci4gTk9URTogd2hhdCBJIHdhcyBwcm9wb3Npbmcgd2FzIG5vdCB0aGlz IHBhcmFtZXRlciwgYnV0IGEgbmV3IHBhcmFtZXRlciByZXNwb25zZV90eXBlIEAgdG9rZW4gZW5k cG9pbnQuJm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JIGFsc28gdGhpbmsg b3ZlcmxvYWRpbmcgZ3JhbnRfdHlwZSBpcyBhIGJhZCBpZGVhIHNpbmNlIGl0IGNoYW5nZXMgaXRz IHNlbWFudGljcy4gSSBxdW90ZSB0aGUgZGVmaW5pdGlvbiBoZXJlIGFnYWluOiZuYnNwOzwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+DQo8ZGl2PmdyYW50Jm5ic3A7PC9kaXY+DQo8ZGl2 PiZuYnNwOyAmbmJzcDsgY3JlZGVudGlhbCByZXByZXNlbnRpbmcgdGhlIHJlc291cmNlIG93bmVy J3MgYXV0aG9yaXphdGlvbjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Z3JhbnRfdHlw ZTwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjwvc3Bhbj50 eXBlIG9mIGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IHRvIG9idGFpbiB0aGUgYWNj ZXNzIHRva2VuPC9kaXY+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pkl0IGlzIG5v dCBhYm91dCBjb250cm9sbGluZyB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlIHRva2Vu IGVuZHBvaW50LCBidXQgdGhlIGhpbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IGRlc2NyaWJpbmcg dGhlIHR5cGUgb2YgY3JlZGVudGlhbCB0aGUgZW5kcG9pbnQgaGFzIHJlY2VpdmVkLiBJdCBzZWVt cyB0aGUgJnF1b3Q7Y29udHJvbCBvZiB3aGF0IGlzIGJlaW5nIHJldHVybmVkIGZyb20gdG9rZW4g ZW5kcG9pbnQmcXVvdDsgJm5ic3A7aXMganVzdCBhDQogc2lkZSBlZmZlY3QuJm5ic3A7PC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JIGFtIHNvbWV3aGF0IGFtYml2YWxlbnRbMV0gaW4g Y2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiB0b2tlbiBlbmRwb2ludCwgYnV0IGluIGFzIG11Y2gg YXMgJnF1b3Q7dGV4dCBpcyB0aGUga2luZyZxdW90OyBmb3IgYSBzcGVjLiwgd2UgcHJvYmFibHkg c2hvdWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBpdCBhcyBUb3JzdGVuIHBvaW50cyBv dXQuIElmIGl0IGlzIG9rIHRvIGNoYW5nZSB0aGlzIHNlbWFudGljcywgSSBiZWxpZXZlIGRlZmlu aW5nDQogYSBuZXcgcGFyYW1ldGVyIHRvIHRoaXMgZW5kcG9pbnQgdG8gY29udHJvbCB0aGUgcmVz cG9uc2Ugd291bGQgYmUgdGhlIGJlc3Qgd2F5IHRvIGdvLiBUaGlzIGlzIHdoYXQgSSBoYXZlIGRl c2NyaWJlZCBwcmV2aW91c2x5LiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+ RGVmaW5pbmcgYSBuZXcgZW5kcG9pbnQgdG8gc2VuZCBjb2RlIHRvIGdldCBJRCBUb2tlbiBhbmQg Zm9yYmlkZGluZyB0aGUgdXNlIG9mIGl0IGFnYWluc3QgdG9rZW4gZW5kcG9pbnQgd291bGQgbm90 IGNoYW5nZSB0aGUgc2VtYW50aWNzIG9mIGFueSBleGlzdGluZyBwYXJhbWV0ZXIgb3IgZW5kcG9p bnQsIHdoaWNoIGlzIGdvb2QuIEhvd2V2ZXIsIEkgZG91YnQgaWYgaXQgaXMgbm90IHdvcnRoIGRv aW5nLiBXaGF0J3MgdGhlIHBvaW50IG9mDQogYXZvaWRpbmcgYWNjZXNzIHRva2VuIHNjb3BlZCB0 byBVc2VySW5mbyBlbmRwb2ludCBhZnRlciBhbGw/IERlZmluaW5nIGEgbmV3IGVuZHBvaW50IGZv ciBqdXN0IGF2b2lkaW5nIHRoZSBhY2Nlc3MgdG9rZW4gZm9yIHVzZXJpbmZvIGVuZHBvaW50IHNl ZW1zIHdheSB0b28gbXVjaCB0aGUgaGVhdnkgd2FpdCB3YXkgYW5kIGl0IGJyZWFrcyBpbnRlcm9w ZXJhYmlsaXk6IGl0IGRlZmVhdHMgdGhlIHB1cnBvc2Ugb2Ygc3RhbmRhcmRpemF0aW9uLiZuYnNw OzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SSBoYXZlIHN0YXJ0ZWQgZmVlbGluZyB0 aGF0IG5vIGNoYW5nZSBpcyB0aGUgYmVzdCB3YXkgb3V0LiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+TmF0PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5bMV0gJm5i c3A7SWYgaW5zdGVhZCBvZiBzYXlpbmcgJnF1b3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMWVt OyI+VG9rZW4gZW5kcG9pbnQgLSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gZXhjaGFuZ2UgYW4gYXV0 aG9yaXphdGlvbiZuYnNwOzwvc3Bhbj5ncmFudCBmb3IgYW4gYWNjZXNzIHRva2VuLCB0eXBpY2Fs bHkgd2l0aCBjbGllbnQgYXV0aGVudGljYXRpb24mcXVvdDssIGl0IHdlcmUgc2F5aW5nICZxdW90 OzxzcGFuIHN0eWxlPSJmb250LXNpemU6IDFlbTsiPlRva2VuIGVuZHBvaW50DQogLSB1c2VkIGJ5 IHRoZSBjbGllbnQgdG8gZXhjaGFuZ2UgYW4gYXV0aG9yaXphdGlvbiZuYnNwOzwvc3Bhbj5ncmFu dCBmb3IgdG9rZW5zLCB0eXBpY2FsbHkgd2l0aCBjbGllbnQgYXV0aGVudGljYXRpb24mcXVvdDss IHRoZW4gaXQgd291bGQgaGF2ZSBiZWVuIE9LLiBJdCBpcyBhbiBleHBhbnNpb24gb2YgdGhlIGNh cGFiaWxpdHkgcmF0aGVyIHRoYW4gY2hhbmdpbmcgdGhlIHNlbWFudGljcy48L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8YnI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+MjAxNC0wNy0yMyAxMzozOSBHTVQtMDQ6MDAgTWlr ZSBKb25lcyA8c3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7 PC9zcGFuPjo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 Ij4NCjxkaXYgbGFuZz0iRU4tVVMiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OidDYWxpYnJpJywnc2Fucy1zZXJp Zic7Y29sb3I6IzFmNDk3ZCI+WW91IG5lZWQgdGhlIGFsdGVybmF0aXZlIHJlc3BvbnNlX3R5cGUg dmFsdWUgKCZxdW90Ozwvc3Bhbj48c3Bhbj5jb2RlX2Zvcl9pZF90b2tlbjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTonQ2FsaWJyaScsJ3NhbnMtc2VyaWYn O2NvbG9yOiMxZjQ5N2QiPiZxdW90Ow0KIGluIHRoZSBBNEMgZHJhZnQpIHRvIHRlbGwgdGhlIEF1 dGhvcml6YXRpb24gU2VydmVyIHRvIHJldHVybiBhIGNvZGUgdG8gYmUgdXNlZCB3aXRoIHRoZSBu ZXcgZ3JhbnQgdHlwZSwgcmF0aGVyIHRoYW4gb25lIHRvIHVzZSB3aXRoIHRoZSAmcXVvdDthdXRo b3JpemF0aW9uX2NvZGUmcXVvdDsgZ3JhbnQgdHlwZSAod2hpY2ggaXMgd2hhdCByZXNwb25zZV90 eXBlPWNvZGUgZG9lcykuPHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwv c3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvc3Bh bj48L3A+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OidD YWxpYnJpJywnc2Fucy1zZXJpZic7Y29sb3I6IzFmNDk3ZCI+PHNwYW4gc3R5bGU9InRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFj ZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNiNWM0ZGYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OidUYWhvbWEnLCdzYW5zLXNlcmlmJyI+RnJvbTo8L3NwYW4+PC9zdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6J1RhaG9tYScsJ3NhbnMtc2Vy aWYnIj4gT0F1dGggW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPHN0cm9uZz5P biBCZWhhbGYgT2YgPC9zdHJvbmc+Sm9obiBCcmFkbGV5PGJyPg0KPHN0cm9uZz5TZW50Ojwvc3Ry b25nPiBXZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQgMTA6MzMgQU08YnI+DQo8c3Ryb25nPlRvOjwv c3Ryb25nPiA8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0i X2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+PGJyPg0KPHN0cm9uZz5DYzo8L3N0cm9uZz4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPHN0cm9uZz5TdWJq ZWN0Ojwvc3Ryb25nPiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0PHNwYW4gc3R5bGU9InRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZSI+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzxiciBjbGFzcz0id2Vi a2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFu PiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PGJy IGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SWYgd2UgdXNlIHRoZSB0b2tlbiBlbmRwb2ludCB0aGVuIGEgbmV3IGdy YW50X3R5cGUgaXMgdGhlIGJlc3Qgd2F5LiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJ0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRl ciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNvcnQg b2Ygb3ZlcmxvYWRzIGNvZGUsIGJ1dCB0aGF0IGlzIGJldHRlciB0aGFuIG1lc3Npbmcgd2l0aCBy ZXNwb25zZV90eXBlIGZvciB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB0byBjaGFuZ2UgdGhl IHJlc3BvbnNlIGZyb20gdGhlIHRva2VuX2VuZHBvaW50LiAmbmJzcDtUaGF0IGlzIGluIG15IG9w aW5pb24gYSBjaGFtcGlvbiBiYWQgaWRlYS4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0idGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lIj48L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xk ZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBkaXNj dXNzaW9ucyBkZXZlbG9waW5nIENvbm5lY3Qgd2UgZGVjaWRlZCBub3QgdG8gb3BlbiB0aGlzIGNh biBvZiB3b3JtcyBiZWNhdXNlIG5vIGdvb2Qgd291bGQgY29tZSBvZiBpdC4gJm5ic3A7Jm5ic3A7 PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj4mbmJz cDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxiciBjbGFz cz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRva2VuX2VuZHBvaW50IHJldHVybnMgYSBhY2Nlc3MgdG9r ZW4uICZuYnNwO05vdGhpbmcgcmVxdWlyZXMgc2NvcGUgdG8gYmUgYXNzb2NpYXRlcyB3aXRoIHRo ZSB0b2tlbi4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9z cGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZSI+PC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48 L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGlzIHRoZSBiZXN0IHNvbHV0aW9u LiAmbmJzcDtObyBjaGFuZ2UgcmVxdWlyZWQuICZuYnNwO0JldHRlciBpbnRlcm9wZXJhYmlsaXR5 IGluIG15IG9waW5pb24uJm5ic3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmUiPjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZSI+PC9zcGFuPjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3RpbGwgb24gbXkgd2F5IHRv IFRPLCBnZXR0aW5nIGluIGxhdGVyIHRvZGF5LiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9InRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhv bGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4g Qi4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxz cGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9z cGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+ PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgaVBob25l PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K T24gSnVsIDIzLCAyMDE0LCBhdCAxMjoxNSBQTSwgPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+DQp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwv YT4gd3JvdGU6PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48 c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHA+VGhlICZxdW90O3Jlc3BvbnNlIHR5cGUmcXVvdDsgb2YgdGhlIHRva2Vu IGVuZHBvaW50IGlzIGNvbnRyb2xsZWQgYnkgdGhlIHZhbHVlIG9mIHRoZSBwYXJhbWV0ZXIgJnF1 b3Q7Z3JhbnRfdHlwZSZxdW90Oy4gU28gdGhlcmUgaXMgbm8gbmVlZCB0byBpbnRyb2R1Y2UgYSBu ZXcgcGFyYW1ldGVyLjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3Nw YW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8 cD53cnQgdG8gYSBwb3RlbnRpYWwgJnF1b3Q7bm9fYWNjZXNzX3Rva2VuJnF1b3Q7IGdyYW50IHR5 cGUuIEkgZG8gbm90IGNvbnNpZGVyIHRoaXMgYSBnb29kIGlkZWEgYXMgaXQgY2hhbmdlcyB0aGUg c2VtYW50aWNzIG9mIHRoZSB0b2tlbiBlbmRwb2ludCAoYXMgYWxyZWFkeSBwb2ludGVkIG91dCBi eSBUaG9tYXMpLiBUaGlzIGVuZHBvaW50IEFMV0FZUyByZXNwb25kcyB3aXRoIGFuIGFjY2VzcyB0 b2tlbiB0byBhbnkgZ3JhbnQgdHlwZS4gSSB0aGVyZWZvcmUgd291bGQNCiBwcmVmZXIgdG8gdXNl IGFub3RoZXIgZW5kcG9pbnQgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlLjxzcGFuIHN0eWxlPSJ0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8cD5yZWdhcmRzLDxicj4NClRvcnN0ZW4uPHNw YW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0i dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjxkaXY+Jm5ic3A7PHNwYW4g c3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBs YWNlaG9sZGVyIj4NCjwvZGl2Pg0KPHA+QW0gMjMuMDcuMjAxNCAxMzowNCwgc2NocmllYiBOYXQg U2FraW11cmE6PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48 c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMGZmIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPklNSE8sIGNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgJnF1b3Q7cmVzcG9uc2VfdHlw ZSZxdW90OyBAIGF1dGh6IGVuZHBvaW50IHRoaXMgd2F5IGlzIG5vdCBhIGdvb2QgdGhpbmcuJm5i c3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBz dHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+Jm5ic3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwv c3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxiciBj bGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbnN0ZWFkLCBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXIgJnF1b3Q7cmVz cG9uc2VfdHlwZSZxdW90OyBAIHRva2VuIGVuZHBvaW50LCBhcyBJIGRlc2NyaWJlZCBpbiBteSBw cmV2aW91cyBtZXNzYWdlLCZuYnNwOw0KPHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wcm9iYWJseSBpcyBiZXR0ZXIu IEF0IGxlYXN0LCBpdCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiB0aGUgcGFyYW1l dGVycyBvZiBSRkM2NzQ5LiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2PiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO05hdCZuYnNwOzxz cGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9 InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206IDEycHQ7Ij48c3BhbiBzdHlsZT0idGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vo b2xkZXIiPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNC0wNy0yMyAx Mjo0OCBHTVQtMDQ6MDAgVGhvbWFzIEJyb3llciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnQuYnJveWVy QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnQuYnJveWVyQGdtYWlsLmNvbTwvYT4mZ3Q7Ojxz cGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9 InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Tm8sIEkgbWVhbiByZXNwb25zZV90eXBlPW5vbmUgYW5kIHJlc3BvbnNlX3R5 cGU9aWRfdG9rZW4gZG9uJ3QgZ2VuZXJhdGUgYSBjb2RlIG9yIGFjY2VzcyB0b2tlbiBzbyB5b3Ug ZG9uJ3QgdXNlIHRoZSBUb2tlbiBFbmRwb2ludCAod2hpY2ggaXMgbm90IHRoZSBzYW1lIGFzIHRo ZSBBdXRoZW50aWNhdGlvbiBFbmRwb2ludCBCVFcpLg0KPHNwYW4gc3R5bGU9InRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZSI+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHJlc3Bv bnNlX3R5cGU9Y29kZV9mb3JfaWRfdG9rZW4sIHlvdSBnZXQgYSBjb2RlIGFuZCBleGNoYW5nZSBp dCBmb3IgYW4gaWRfdG9rZW4gb25seSwgcmF0aGVyIHRoYW4gYW4gYWNjZXNzX3Rva2VuLCBzbyB5 b3UncmUgY2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgVG9rZW4gRW5kcG9pbnQuPHNwYW4g c3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ Jm5ic3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3Bh biBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxiciBjbGFzcz0id2Vi a2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSdtIG5vdCBzYXlpbmcgaXQncyBhIGJhZCB0aGluZywganVzdCB0aGF0IHlv dSBjYW4ndCByZWFsbHkgY29tcGFyZSBub25lIGFuZCBpZF90b2tlbiB3aXRoIGNvZGVfZm9yX2lk X3Rva2VuLjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNw YW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbTog MTJwdDsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+Jm5i c3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xh c3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBXZWQsIEp1bCAyMywgMjAxNCBhdCA2OjQ1IFBNLCBSaWNoZXIsIEp1c3Rp biBQLiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFu ayI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0OyB3cm90ZTo8c3BhbiBzdHlsZT0idGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lIj48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0J3Mgb25s eSAmcXVvdDtub3QgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50JnF1b3Q7IGJlY2F1c2UgdGhlIHRv a2VuIGVuZHBvaW50IGNvcHktcGFzdGVkIGFuZCByZW5hbWVkIHRoZSBhdXRoZW50aWNhdGlvbiBl bmRwb2ludC4NCjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+ PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9z cGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PGJyIGNs YXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDstLSBKdXN0aW48c3BhbiBzdHlsZT0idGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pjxz cGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+Jm5ic3A7PHNwYW4g c3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtp dC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAyMywgMjAxNCwgYXQgOTozMCBBTSwgVGhvbWFzIEJyb3ll ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnQuYnJveWVyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi cj4NCjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4g c3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RXhjZXB0IHRoYXQgdGhlc2UgYXJlIGFib3V0IG5vdCB1c2luZyB0 aGUgVG9rZW4gRW5kcG9pbnQgYXQgYWxsLCB3aGVyZWFzIHRoZSBjdXJyZW50IHByb3Bvc2FsIGlz IGFib3V0IHRoZSBUb2tlbiBFbmRwb2ludCBub3QgcmV0dXJuaW5nIGFuIGFjY2Vzc190b2tlbiBm aWVsZCBpbiB0aGUgSlNPTi48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+ PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPjxzcGFu IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+Jm5ic3A7PHNwYW4gc3R5 bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1i bG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBXZWQsIEp1bCAyMywgMjAxNCBhdCA0OjI2IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJt YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PHNwYW4gc3R5bGU9InRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZSI+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6J0NhbGlicmknLCdzYW5z LXNlcmlmJztjb2xvcjojMWY0OTdkIj5UaGUgcmVzcG9uc2VfdHlwZSAmcXVvdDtub25lJnF1b3Q7 IGlzIGFscmVhZHkgdXNlZCBpbiBwcmFjdGljZSwgd2hpY2ggcmV0dXJucyBubyBhY2Nlc3MgdG9r ZW4uJm5ic3A7IEl0IHdhcyBhY2NlcHRlZCBieSB0aGUgZGVzaWduYXRlZCBleHBlcnRzIGFuZCBy ZWdpc3RlcmVkIGluIHRoZSBJQU5BIE9BdXRoDQogQXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNw b25zZSBUeXBlcyByZWdpc3RyeSBhdCA8YSBocmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2ln bm1lbnRzL29hdXRoLXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54bWwjZW5kcG9pbnQiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFy YW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhtbCNlbmRwb2ludDwvYT4uJm5ic3A7IFRoZSByZWdp c3RlcmVkICZxdW90O2lkX3Rva2VuJnF1b3Q7IHJlc3BvbnNlIHR5cGUgYWxzbyByZXR1cm5zIG5v IGFjY2VzcyB0b2tlbi48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFu PjwvcD4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6J0Nh bGlicmknLCdzYW5zLXNlcmlmJztjb2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNl aG9sZGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6J0NhbGlicmknLCdzYW5zLXNlcmlmJztjb2xvcjojMWY0 OTdkIj5TbyBJIHRoaW5rIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHJlc3BvbnNlIHR5cGVzIHRo YXQgcmVzdWx0IGluIG5vIGFjY2VzcyB0b2tlbiBiZWluZyByZXR1cm5lZCBhcmUgYWNjZXB0YWJs ZSB3aXRoaW4gT0F1dGggMi4wIGlzIGFscmVhZHkgc2V0dGxlZCwgYXMgYSBwcmFjdGljYWwNCiBt YXR0ZXIuJm5ic3A7IExvdHMgb2YgT0F1dGggaW1wbGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IHVz aW5nIHN1Y2ggcmVzcG9uc2UgdHlwZXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmUiPjwvc3Bhbj48L3A+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OidDYWxpYnJpJywnc2Fucy1zZXJpZic7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5 bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1i bG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OidDYWxpYnJpJywnc2Fucy1zZXJpZic7 Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PHNwYW4gc3R5bGU9InRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6J0NhbGlicmknLCdzYW5zLXNlcmlmJztjb2xvcjojMWY0OTdkIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bh bj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxiciBjbGFz cz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI2I1YzRkZiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzdHJvbmc+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6J1RhaG9tYScsJ3NhbnMtc2VyaWYnIj5Gcm9t Ojwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTonVGFob21hJywnc2Fucy1zZXJpZiciPiBPQXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRm Lm9yZzwvYT5dDQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTonVGFob21hJywnc2Fu cy1zZXJpZiciPk9uIEJlaGFsZiBPZiA8L3NwYW4+PC9zdHJvbmc+UGhpbCBIdW50PGJyPg0KPHN0 cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6J1RhaG9tYScsJ3NhbnMtc2VyaWYnIj5TZW50 Ojwvc3Bhbj48L3N0cm9uZz4gV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDc6MDkgQU08YnI+DQo8 c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTonVGFob21hJywnc2Fucy1zZXJpZiciPlRv Ojwvc3Bhbj48L3N0cm9uZz4gTmF0IFNha2ltdXJhPGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6J1RhaG9tYScsJ3NhbnMtc2VyaWYnIj5DYzo8L3NwYW4+PC9zdHJvbmc+ICZs dDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6J1Rh aG9tYScsJ3NhbnMtc2VyaWYnIj5TdWJqZWN0Ojwvc3Bhbj48L3N0cm9uZz4gUmU6IFtPQVVUSC1X R10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXIt YTRjLTA1LnR4dDwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+ PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4mbmJzcDs8c3BhbiBzdHlsZT0i dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lIj48L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xk ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMuIFRoaXMgaXMgd2h5IGl0IGhh cyB0byBiZSBkaXNjdXNzZWQgaW4gdGhlIElFVEYuPHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZSI+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2PiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OidIZWx2ZXRpY2EnLCdzYW5zLXNlcmlmJyI+UGhpbDwvc3Bh bj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0 eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OidIZWx2ZXRp Y2EnLCdzYW5zLXNlcmlmJyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6J0hlbHZldGljYScsJ3NhbnMtc2VyaWYnIj5AaW5kZXBlbmRl bnRpZDwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFu PjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTonSGVsdmV0aWNhJywnc2Fucy1zZXJpZiciPjxhIGhyZWY9Imh0dHA6 Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmluZGVwZW5kZW50 aWQuY29tPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+ PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTonSGVsdmV0aWNhJywnc2Fucy1zZXJpZiciPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwv c3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFu IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6J0hlbHZldGljYScsJ3NhbnMtc2Vy aWYnIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUi Pjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxi ciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzxz cGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9 InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9j ay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8c3BhbiBzdHlsZT0i dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lIj48L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xk ZXIiPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAy MywgMjAxNCwgYXQgOTo0MyBBTSwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2Fr aW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48 c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRl ciI+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWFkaW5nIGJhY2sgdGhl IFJGQzY3NDksIEkgYW0gbm90IHN1cmUgaWYgdGhlcmUgaXMgYSBnb29kIHdheSBvZiBzdXBwcmVz c2luZyBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgcmVzcG9uc2UgYW5kIHN0aWxsIGJlIE9BdXRoLiBJ dCB3aWxsIGJyZWFrIHdob2xlIGJ1bmNoIG9mIGltcGxpY2l0IGRlZmluaXRpb25zIGxpa2U6Jm5i c3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBz dHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 PiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNw YW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9Indl YmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+YXV0aG9yaXphdGlvbiBzZXJ2ZXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUg c2VydmVyIGlzc3VpbmcgYWNjZXNzIHRva2VucyB0byB0aGUgY2xpZW50IGFmdGVyIHN1Y2Nlc3Nm dWxseTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGF1dGhlbnRpY2F0aW5nIHRoZSByZXNvdXJj ZSBvd25lciBhbmQgb2J0YWluaW5nIGF1dGhvcml6YXRpb24uPHNwYW4gc3R5bGU9InRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZSI+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2PiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFmdGVyIGFsbCwg T0F1dGggaXMgYWxsIGFib3V0IGlzc3VpbmcgYWNjZXNzIHRva2Vucy4mbmJzcDs8c3BhbiBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4mbmJz cDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0 eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQt YmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BbHNvLCBJIHRha2UgYmFjayBteSBzdGF0ZW1lbnQgb24gdGhlIGdyYW50IHR5cGUg aW4gbXkgcHJldmlvdXMgbWFpbC4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lIj48L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZGVmaW5pdGlv biBvZiBncmFudCBhbmQgZ3JhbnRfdHlwZSBhcmUgcmVzcGVjdGl2ZWx5OiZuYnNwOzxzcGFuIHN0 eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2PiZu YnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4g c3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtp dC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5ncmFudCZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUi Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7IGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGF1dGhv cml6YXRpb248c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxz cGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9z cGFuPjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Z3JhbnRfdHlwZTxzcGFuIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgKHN0cmluZyByZXByZXNlbnRpbmcgdGhlKSB0eXBlIG9m IGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IHRvIG9idGFpbiB0aGUgYWNjZXNzIHRv a2VuPHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBz dHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3Nw YW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaHVzLCB0aGUgZ3JhbnQgc2VudCB0byB0aGUg dG9rZW4gZW5kcG9pbnQgaW4gdGhpcyBjYXNlIGlzIHN0aWxsICdjb2RlJy4mbmJzcDs8c3BhbiBz dHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4m bmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFu IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PGJyIGNsYXNzPSJ3ZWJr aXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5SZXNwb25zZSB0eXBlIG9uIHRoZSBvdGhlciBoYW5kIGlzIG5vdCBzbyB3ZWxs IGRlZmluZWQgaW4gUkZDNjc0OSwgYnV0IGl0IHNlZW1zIGl0IGlzIHJlcHJlc2VudGluZyB3aGF0 IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRvIGV4 cHJlc3Mgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50LCBwZXJoYXBz IGRlZmluaW5nIGEgbmV3IHBhcmFtZXRlcg0KIHRvIHRoZSB0b2tlbiBlbmRwb2ludCwgd2hpY2gg aXMgYSBwYXJhbGxlbCB0byB0aGUgcmVzcG9uc2VfdHlwZSB0byB0aGUgQXV0aG9yaXphdGlvbiBF bmRwb2ludCBzZWVtcyB0byBiZSBhIG1vcmUgc3ltbWV0cmljIHdheSwgdGhvdWdoIEkgYW0gbm90 IHN1cmUgYXQgYWxsIGlmIHRoYXQgaXMgZ29pbmcgdG8gYmUgT0F1dGggYW55IG1vcmUuIE9uZSBz dHJhdy1tYW4gaXMgdG8gZGVmaW5lIGEgbmV3IHBhcmFtZXRlciBjYWxsZWQgcmVzcG9uc2VfdHlw ZQ0KIHRvIHRoZSB0b2tlbiBlbmRwb2ludCBzdWNoIGFzOiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2PiZuYnNwOzxzcGFu IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1w bGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnJlc3BvbnNlX3R5cGU8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9z cGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBPUFRJT05B TC4gQSBzdHJpbmcgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUg dG9rZW4gZW5kcG9pbnQuJm5ic3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyZuYnNwOzxzcGFuIHN0eWxl PSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhv bGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZW4g ZGVmaW5lIHRoZSBiZWhhdmlvciBvZiB0aGUgZW5kcG9pbnQgYWNjb3JkaW5nIHRvIHRoZSB2YWx1 ZXMgYXMgdGhlIHBhcmFsbGVsIHRvIHRoZSBtdWx0aS1yZXNwb25zZSB0eXBlIHNwZWMuJm5ic3A7 PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29h dXRoLXYyLW11bHRpcGxlLXJlc3BvbnNlLXR5cGVzLTFfMC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb2F1dGgtdjItbXVsdGlwbGUtcmVzcG9uc2UtdHlwZXMt MV8wLmh0bWw8L2E+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bh bj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+Jm5ic3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9z cGFuPjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0PHNwYW4gc3R5bGU9InRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyZuYnNw OzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5 bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1i bG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+Jm5ic3A7PHNw YW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0i dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxiciBjbGFzcz0id2Via2l0LWJsb2Nr LXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4mbmJzcDs8c3BhbiBz dHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxh Y2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1ib3R0b206IDEycHQ7Ij4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48 L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNC0wNy0yMyA3OjIxIEdNVC0wNDowMCBQaGlsIEh1 bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs6PHNwYW4gc3R5bGU9InRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZSI+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IGRyYWZ0IGlzIHZlcnkgY2xlYXIuJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxi cj4NCjxicj4NClBoaWw8L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBKdWwgMjMsIDIwMTQsIGF0IDA6 NDYsIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxzcGFuIHN0 eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBuZXcgZ3JhbnQgdHlwZSB0aGF0IEkgd2FzIHRhbGtpbmcgYWJv dXQgd2FzJm5ic3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bh bj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDthdXRob3JpemF0aW9uX2NvZGVfYnV0X2Rv X25vdF9yZXR1cm5fYWNjZXNzX25vcl9yZWZyZXNoX3Rva2VuJnF1b3Q7LCBzbyB0byBzcGVhay4m bmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFu IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBkb2VzIG5vdCByZXR1cm4gYW55dGhpbmcgcGVy IHNlLCBidXQgYW4gZXh0ZW5zaW9uIGNhbiBkZWZpbmUgc29tZXRoaW5nIG9uIHRvcCBvZiBpdC4m bmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFu IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+ PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PGJy IGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVuLCBPSURDIGNhbiBkZWZpbmUgYSBiaW5kaW5nIHRv IGl0IHNvIHRoYXQgdGhlIGJpbmRpbmcgb25seSByZXR1cm5zIElEIFRva2VuLiZuYnNwOzxzcGFu IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGlzIGJpbmRpbmcgd29yayBzaG91bGQgYmUgZG9uZSBpbiBPSURG LiBTaG91bGQgdGhlcmUgYmUgc3VjaCBhIGdyYW50IHR5cGUsJm5ic3A7PHNwYW4gc3R5bGU9InRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pdCB3aWxsIGJlIGFuIGV4dHJlbWVseSBzaG9ydCBzcGVj LiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNw YW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2PiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l Ij48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48 YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IHRoZSBzYW1lIHRpbWUsIGlmIGFueSBvdGhlciBz cGVjaWZpY2F0aW9uIHdhbnRlZCB0byBkZWZpbmUmbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ b3RoZXIgdHlwZSBvZiB0b2tlbnMgYW5kIGhhdmUgaXQgcmV0dXJuZWQgZnJvbSB0aGUgdG9rZW4g ZW5kcG9pbnQsJm5ic3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwv c3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPml0IGNhbiBhbHNvIHVzZSB0aGlz IGdyYW50IHR5cGUuJm5ic3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUi Pjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+Jm5ic3A7PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZSI+PC9zcGFuPjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2hhdCB5b3Ugd2FudCBpcyB0 byBkZWZpbmUgYSBuZXcgZ3JhbnQgdHlwZSB0aGF0IHJldHVybnMgSUQgVG9rZW4gb25seSwmbmJz cDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0 eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlbiwgSSBhbSB3aXRoIEp1c3Rpbi4gU2luY2UgJnF1 b3Q7b3RoZXIgcmVzcG9uc2UgdGhhbiBJRCBUb2tlbiZxdW90OyBpcyBvbmx5Jm5ic3A7PHNwYW4g c3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnRoZW9yZXRpY2FsLCB0aGlzIGlzIGEgbW9yZSBwbGF1c2libGUgd2F5 IGZvcndhcmQsIEkgc3VwcG9zZS4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lIj48L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQ8c3BhbiBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOiAxMnB0OyI+Jm5ic3A7PHNwYW4gc3R5bGU9InRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZSI+PC9zcGFuPjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTQtMDctMjIgMTQ6MzAgR01U LTA0OjAwIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUi IHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0Ozo8c3BhbiBzdHlsZT0idGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gdGhlIGRy YWZ0IHdvdWxkIGxpdGVyYWxseSB0dXJuIGludG86PGJyPg0KPGJyPg0KJnF1b3Q7VGhlIGE0YyBy ZXNwb25zZSB0eXBlIGFuZCBncmFudCB0eXBlIHJldHVybiBhbiBpZF90b2tlbiBmcm9tIHRoZSB0 b2tlbiBlbmRwb2ludCB3aXRoIG5vIGFjY2VzcyB0b2tlbi4gQWxsIHBhcmFtZXRlcnMgYW5kIHZh bHVlcyBhcmUgZGVmaW5lZCBpbiBPSURDLiZxdW90Ozxicj4NCjxicj4NClNlZW1zIGxpa2UgdGhl IHBlcmZlY3QgbWluaSBleHRlbnNpb24gZHJhZnQgZm9yIE9JREYgdG8gZG8uPGJyPg0KPGJyPg0K LS1KdXN0aW48YnI+DQo8YnI+DQovc2VudCBmcm9tIG15IHBob25lLzxzcGFuIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KT24gSnVsIDIyLCAyMDE0IDEwOjI5IEFNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1h aWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGF0IGFib3V0IGp1c3QgZGVm aW5pbmcgYSBuZXcgZ3JhbnQgdHlwZSBpbiB0aGlzIFdHPzxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0OyAyMDE0LTA3LTIyIDEyOjU2IEdNVC0wNDowMCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9 Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBv cmFjbGUuY29tPC9hPiZndDs6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGF0IHdvdWxk IGJlIG5pY2UuIEhvd2V2ZXIgb2lkYyBzdGlsbCBuZWVkcyB0aGUgbmV3IGdyYW50IHR5cGUgaW4g b3JkZXIgdG8gaW1wbGVtZW50IHRoZSBzYW1lIGZsb3cuJm5ic3A7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBQaGlsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiBKdWwgMjIsIDIw MTQsIGF0IDExOjM1LCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmIzQzOzEgdG8gSnVzdGluLiZuYnNw Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAy MDE0LTA3LTIyIDk6NTQgR01ULTA0OjAwIFJpY2hlciwgSnVzdGluIFAuICZsdDs8YSBocmVmPSJt YWlsdG86anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9y ZzwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEVy cm9ycyBsaWtlIHRoZXNlIG1ha2UgaXQgY2xlYXIgdG8gbWUgdGhhdCBpdCB3b3VsZCBtYWtlIG11 Y2ggbW9yZSBzZW5zZSB0byBkZXZlbG9wIHRoaXMgZG9jdW1lbnQgaW4gdGhlIE9wZW5JRCBGb3Vu ZGF0aW9uLiBJdCBzaG91bGQgYmUgc29tZXRoaW5nIHRoYXQgZGlyZWN0bHkgcmVmZXJlbmNlcyBP cGVuSUQgQ29ubmVjdCBDb3JlIGZvciBhbGwgb2YgdGhlc2UgdGVybXMgaW5zdGVhZCBvZiByZWRl ZmluaW5nIHRoZW0uIEl0J3MgZG9pbmcNCiBhdXRoZW50aWNhdGlvbiwgd2hpY2ggaXMgZnVuZGFt ZW50YWxseSB3aGF0IE9wZW5JRCBDb25uZWN0IGRvZXMgb24gdG9wIG9mIE9BdXRoLCBhbmQgSSBk b24ndCBzZWUgYSBnb29kIGFyZ3VtZW50IGZvciBkb2luZyB0aGlzIHdvcmsgaW4gdGhpcyB3b3Jr aW5nIGdyb3VwLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZu YnNwOy0tIEp1c3Rpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IE9uIEp1bCAyMiwgMjAxNCwgYXQgNDozMCBBTSwgVGhvbWFzIEJyb3llciAmbHQ7PGEgaHJlZj0i bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnQuYnJveWVyQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBNb24sIEp1bCAyMSwgMjAxNCBhdCAx MTo1MiBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFua3MgZm9yIHlvdXIgcmV2aWV3LCBUaG9tYXMuJm5ic3A7IFRo ZSAmcXVvdDtwcm9tcHQ9Y29uc2VudCZxdW90OyBkZWZpbml0aW9uIGJlaW5nIG1pc3NpbmcgaXMg YW4gZWRpdG9yaWFsIGVycm9yLiZuYnNwOyBJdCBzaG91bGQgYmU6PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOzxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb25z ZW50PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBTSE9VTEQgcHJvbXB0IHRoZSBFbmQtVXNl ciBmb3IgY29uc2VudCBiZWZvcmUgcmV0dXJuaW5nIGluZm9ybWF0aW9uIHRvIHRoZSBDbGllbnQu IElmIGl0IGNhbm5vdCBvYnRhaW4gY29uc2VudCwgaXQgTVVTVCByZXR1cm4gYW4gZXJyb3IsIHR5 cGljYWxseSBjb25zZW50X3JlcXVpcmVkLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSdsbCBwbGFuIHRvIGFkZCBp dCBpbiB0aGUgbmV4dCBkcmFmdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgbG9va3MgbGlrZSB0 aGUgY29uc2VudF9yZXF1aXJlZCBlcnJvciBuZWVkcyB0byBiZSBkZWZpbmVkIHRvbywgYW5kIHlv dSBtaWdodCBoYXZlIGZvcmdvdHRlbiB0byBhbHNvIGltcG9ydCBhY2NvdW50X3NlbGVjdGlvbl9y ZXF1aXJlZCBmcm9tIE9wZW5JRCBDb25uZWN0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZu YnNwOzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSSBhZ3JlZSB0aGF0IHRoZXJlJ3Mgbm8gZGlmZmVyZW5jZSBiZXR3 ZWVuIGEgcmVzcG9uc2Ugd2l0aCBtdWx0aXBsZSAmcXVvdDthbXImcXVvdDsgdmFsdWVzIHRoYXQg aW5jbHVkZXMgJnF1b3Q7bWZhJnF1b3Q7IGFuZCBvbmUgdGhhdCBkb2Vzbid0LiZuYnNwOyBVbmxl c3MgYSBjbGVhciB1c2UgY2FzZSBmb3Igd2h5ICZxdW90O21mYSZxdW90OyBpcyBuZWVkZWQgY2Fu IGJlIGlkZW50aWZpZWQsIHdlIGNhbiBkZWxldGUgaXQgaW4gdGhlIG5leHQgZHJhZnQuPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhvdyBhYm91dCAmcXVvdDtwd2QmcXVvdDsgdGhlbj8gSSBmdWxs eSB1bmRlcnN0YW5kIHRoYXQgSSBzaG91bGQgcmV0dXJuICZxdW90O3B3ZCZxdW90OyBpZiB0aGUg dXNlciBhdXRoZW50aWNhdGVkIHVzaW5nIGEgcGFzc3dvcmQsIGJ1dCB3aGF0ICZxdW90O3RoZSBz ZXJ2aWNlIGlmIGEgY2xpZW50IHNlY3JldCBpcyB1c2VkJnF1b3Q7IG1lYW5zIGluIHRoZSBkZWZp bml0aW9uIGZvciB0aGUgJnF1b3Q7cHdkJnF1b3Q7IHZhbHVlPzxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgKE5vdGE6IEkga25vdyB5b3UncmUgYXQg SUVURi05MCwgSSdtIHJlYWR5IHRvIHdhaXQgJ3RpbCB5b3UgY29tZSBiYWNrIDstKSApPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLTxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRob21hcyBCcm95ZXI8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAvdDxhIGhyZWY9Imh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhiLmplLyIgdGFyZ2V0PSJf YmxhbmsiPsmULm1hLmLKgXdhLmplLzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGll dGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IC0tPGJyPg0KJmd0OyZndDsmZ3Q7IE5hdCBTYWtp bXVyYSAoPW5hdCk8YnI+DQomZ3Q7Jmd0OyZndDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9u PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQomZ3Q7Jmd0OyZn dDsgQF9uYXRfZW48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsg T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyAtLTxicj4NCiZndDsgTmF0IFNha2ltdXJhICg9bmF0KTxicj4NCiZndDsgQ2hhaXJtYW4s IE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJh Lm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0K Jmd0OyBAX25hdF9lbjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3Nw YW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwi Pg0KPHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBz dHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 PiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNw YW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9Indl YmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LS0gPGJyPg0KTmF0IFNha2ltdXJhICg9bmF0KTxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmUiPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4s IE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcv IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0 X2VuPHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBz dHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxzcGFuIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4mbmJzcDs8c3BhbiBzdHlsZT0i dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lIj48L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xk ZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NCk5hdCBT YWtpbXVyYSAoPW5hdCk8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9z cGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxi cj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjxzcGFuIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PiZu YnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4g c3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtp dC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PHNwYW4g c3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPHNwYW4gc3R5bGU9InRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZSI+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2PiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KVGhvbWFzIEJyb3ll cjxicj4NCi90PGEgaHJlZj0iaHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvIiB0YXJn ZXQ9Il9ibGFuayI+yZQubWEuYsqBd2EuamUvPC9hPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0K PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2PiZu YnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4g c3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtp dC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLSA8 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3Bhbj5UaG9t YXMgQnJveWVyPC9zcGFuPjxicj4NCjxzcGFuPi90PGEgaHJlZj0iaHR0cDovL3huLS1ubmEubWEu eG4tLWJ3YS14eGIuamUvIiB0YXJnZXQ9Il9ibGFuayI+yZQubWEuYsqBd2EuamUvPC9hPg0KPC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFu PjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PHNwYW4gc3R5bGU9InRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmUiPjwvc3Bhbj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2PiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUi Pjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KTmF0IFNha2ltdXJhICg9bmF0KSA8 c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxl PSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0 dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11 cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lIj48L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZSI+PC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lIj48L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0K PC9kaXY+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48c3BhbiBz dHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcHJlPg0KPHByZT5PQXV0 aCBtYWlsaW5nIGxpc3Q8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9z cGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PC9wcmU+ DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9B dXRoQGlldGYub3JnPC9hPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48 L3NwYW4+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bhbj48L3By ZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8L2E+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiPjwvc3Bh bj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9zcGFuPjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48 L3NwYW4+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+PC9z cGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48L3NwYW4+PGJyIGNs YXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZSI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIj48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJy Pg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KLS0gPGJyPg0KTmF0IFNha2ltdXJhICg9bmF0KQ0KPGRpdj5DaGFp cm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJh Lm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0K QF9uYXRfZW48L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQotLSA8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpDQo8ZGl2PkNoYWlybWFu LCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3Jn LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQpAX25h dF9lbjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9InBhZGRpbmctbGVmdDo1cHg7 Ym9yZGVyLWxlZnQ6IzEwMTBmZiAycHggc29saWQ7bWFyZ2luLWxlZnQ6NXB4Ij4NCjxkaXY+PHNw YW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+ PGJyPg0KPHNwYW4+T0F1dGggbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9 Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9h Pjwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJwYWRkaW5n LWxlZnQ6NXB4O2JvcmRlci1sZWZ0OiMxMDEwZmYgMnB4IHNvbGlkO21hcmdpbi1sZWZ0OjVweCI+ DQo8ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9zcGFuPjxicj4NCjxzcGFuPk9BdXRoIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8c3Bh bj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBp ZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PiZuYnNwOzxiciBjbGFzcz0id2Via2l0 LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv YT48YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBjbGFzcz0iaDUiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxkaXY+PGJyPg0KPC9k aXY+DQotLSA8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpDQo8ZGl2PkNoYWlybWFuLCBPcGVuSUQg Rm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxi cj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8 L2E+PGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_59B4FD06C1E24629B46B09A6E00EDB57mitreorg_-- From nobody Thu Jul 24 07:19:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A491A039D for ; Thu, 24 Jul 2014 07:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a5JzPZqlHW2 for ; Thu, 24 Jul 2014 07:19:04 -0700 (PDT) Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1D51A0373 for ; Thu, 24 Jul 2014 07:19:04 -0700 (PDT) Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKU9EV140xK3dBLZAWjcd4czHI643A/b7I@postini.com; Thu, 24 Jul 2014 07:19:04 PDT Received: by mail-ie0-f177.google.com with SMTP id at20so2310358iec.22 for ; Thu, 24 Jul 2014 07:19:03 -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=WMfEWjC3UatSH3W4nFQ9/Blrn2bbJXjtWF6E42rtsU4=; b=SAckXNJfBPuJ96FaPYbdmLHI44mF81vA+JJ7AOq7BYSk6cjw63MK5+k/ges24lXXnB xkdIJ2VL+b/FWuVELr0upXVcpgko5bBKcAzx1y/vPZI+LQTdGtlcENaN5/Bo07zTPG+G t4JT9qrSs/9oEX8FXDTQxUlchbylO4joavC1BxcV0FSR6y0uo6Bd81PRO5RRlNTVojDV QzIybtHPhIHjXrNR7pinHWc69+DkGFUOaF3rWR//EKz6WQXzFaaVi0hUA4w1io0uvJeC 5rLD0IPcb6otAmz6y1D5QZw0MVqkLp4Iy8NB9kzw+pgUClGvJ54CpNu/HJYmpl1qup3V wcQg== X-Gm-Message-State: ALoCoQlRt3vxXCF5wMeIRb3T/0z62muhaDmnYSuUhs1K/18q9N/psD2Wy2yo0S+e81BFVuOWKdTeBDoxfkkK8ZrXqukktSFR+5hhwnhCpziBOKGvRpCXCTH/ds3/9YdWn1DMrdZIY6FA X-Received: by 10.50.41.6 with SMTP id b6mr15580923igl.40.1406211543506; Thu, 24 Jul 2014 07:19:03 -0700 (PDT) X-Received: by 10.50.41.6 with SMTP id b6mr15580876igl.40.1406211543221; Thu, 24 Jul 2014 07:19:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Thu, 24 Jul 2014 07:18:32 -0700 (PDT) In-Reply-To: <9dbf8c7384e341a08334a9ee093697f8@BLUPR03MB309.namprd03.prod.outlook.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <9dbf8c7384e341a08334a9ee093697f8@BLUPR03MB309.namprd03.prod.outlook.com> From: Brian Campbell Date: Thu, 24 Jul 2014 07:18:32 -0700 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=089e011614148359fb04fef12335 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Kyak1h0KHme1-VWI34P249pEOOc Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 14:19:13 -0000 --089e011614148359fb04fef12335 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is a lot of spin being applied, yes. But not from Ian. On Thu, Jul 24, 2014 at 7:00 AM, Anthony Nadalin wrote: > I=E2=80=99m sure it was spun in a way that could be true since there was= no > technical value to Ian=E2=80=99s statement and I=E2=80=99m sure that folk= s had not read or > understand the usage. > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Thursday, July 24, 2014 6:53 AM > *To:* Nat Sakimura > *Cc:* oauth@ietf.org list > > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > I'd note that the reaction at the conference to Ian's statement was > overwhelmingly positive. There was a wide range of industry people here - > implementers, practitioners, deployers, strategists, etc. - and it seems > pretty clear that the "rough consensus" of the industry at large is that > a4c is not wanted or needed. > > > > On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura wrote: > > And here is a quote from Ian's blog. > > > > And although the authentication wheel is round, that doesn=E2=80=99t mean= it isn=E2=80=99t > without its lumps. First, we do see some reinventing the wheel just to > reinvent the wheel. OAuth A4C is simply not a fruitful activity and shoul= d > be put down. > > > > (Source) > http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musin= gs-on-identity-standards-part-1.html > > > > 2014-07-23 16:53 GMT-04:00 John Bradley : > > > > I thought I did post this to the list. > > > > I guess I hit the wrong reply on my phone. > > > John B. > Sent from my iPhone > > > On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: > > we are two, at least :-) > > Why didn't you post this on the list? > > When will be be arriving? > > Am 23.07.2014 16:39, schrieb John Bradley: > > Ian Glazer mentioned this in his keynote at CIS yesterday. > > > > His advice was please stop, we are creating confusion and uncertainty. > > > > We are becoming our own wort enemy. ( my view though Ian may share it) > > > > Returning just an id_ token from the token endpoint has little real value= . > > > > Something really useful to do would be sorting out channel_id so we can d= o > PoP for id tokens to make them and other cookies secure in the front > channel. I think that is a better use of time. > > > > I may be in the minority opinion on that, it won't be the first time. > > > > John B. > Sent from my iPhone > > > On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt > wrote: > > You are right from a theoretical perspective. Practically this was > caused by editorial decisions during the creation of the RFC. As far as I > remember, there was a definition of the (one) token endpoint response in > early versions. No one every considered to NOT respond with an access tok= en > from the token endpoint. So one might call it an implicit assumption. > > > > I'm worried that people get totally confused if an exception is introduce= d > now given the broad adoption of OAuth based on this assumption. > > > > regards, > > Torsten. > > > Am 23.07.2014 um 15:41 schrieb Thomas Broyer : > > Is it said anywhere that ALL grant types MUST use Section 5.1 responses? > Each grant type references Section 5.1, and "access token request" is onl= y > defined in the context of the defined grant types. Section 2.2 doesn't ta= lk > about the request or response format. > > Le 23 juil. 2014 21:32, "Nat Sakimura" a =C3=A9crit = : > > Is it? Apart from the implicit grant that does not use token endpoint, > all other grant references section 5.1 for the response, i.e., all shares > the same response. > > > > 2014-07-23 15:18 GMT-04:00 Thomas Broyer : > > I hadn't realized the JSON response that requires the access_token field > is defined per grant_type, so I'd be OK to "extend the semantics" as in t= he > current draft. > That was actually my main concern: that the token endpoint mandates > access_token; but its actually not the case. > > Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9crit = : > > > > I agree with John that overloading response_type @ authz endpoint is a > bad idea. It completely changes the semantics of this parameter. NOTE: wh= at > I was proposing was not this parameter, but a new parameter response_type= @ > token endpoint. > > > > I also think overloading grant_type is a bad idea since it changes its > semantics. I quote the definition here again: > > > > grant > > credential representing the resource owner's authorization > > > > grant_type > > type of grant sent to the token endpoint to obtain the access token > > > > It is not about controlling what is to be returned from the token > endpoint, but the hint to the token endpoint describing the type of > credential the endpoint has received. It seems the "control of what is > being returned from token endpoint" is just a side effect. > > > > I am somewhat ambivalent[1] in changing the semantics of token endpoint, > but in as much as "text is the king" for a spec., we probably should not > change the semantics of it as Torsten points out. If it is ok to change > this semantics, I believe defining a new parameter to this endpoint to > control the response would be the best way to go. This is what I have > described previously. > > > > Defining a new endpoint to send code to get ID Token and forbidding the > use of it against token endpoint would not change the semantics of any > existing parameter or endpoint, which is good. However, I doubt if it is > not worth doing. What's the point of avoiding access token scoped to > UserInfo endpoint after all? Defining a new endpoint for just avoiding th= e > access token for userinfo endpoint seems way too much the heavy wait way > and it breaks interoperabiliy: it defeats the purpose of standardization. > > > > I have started feeling that no change is the best way out. > > > > Nat > > > > [1] If instead of saying "Token endpoint - used by the client to > exchange an authorization grant for an access token, typically with > client authentication", it were saying "Token endpoint - used by the > client to exchange an authorization grant for tokens, typically with > client authentication", then it would have been OK. It is an expansion of > the capability rather than changing the semantics. > > > > > > 2014-07-23 13:39 GMT-04:00 Mike Jones : > > You need the alternative response_type value ("code_for_id_token" in the > A4C draft) to tell the Authorization Server to return a code to be used > with the new grant type, rather than one to use with the > "authorization_code" grant type (which is what response_type=3Dcode does)= . > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Wednesday, July 23, 2014 10:33 AM > *To:* torsten@lodderstedt.net > > > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > > > If we use the token endpoint then a new grant_type is the best way. > > > > It sort of overloads code, but that is better than messing with > response_type for the authorization endpoint to change the response from > the token_endpoint. That is in my opinion a champion bad idea. > > > > In discussions developing Connect we decided not to open this can of worm= s > because no good would come of it. > > > > The token_endpoint returns a access token. Nothing requires scope to be > associates with the token. > > > > That is the best solution. No change required. Better interoperability > in my opinion. > > > > Still on my way to TO, getting in later today. > > > > John B. > > > > > > Sent from my iPhone > > > On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: > > The "response type" of the token endpoint is controlled by the value of > the parameter "grant_type". So there is no need to introduce a new > parameter. > > wrt to a potential "no_access_token" grant type. I do not consider this a > good idea as it changes the semantics of the token endpoint (as already > pointed out by Thomas). This endpoint ALWAYS responds with an access toke= n > to any grant type. I therefore would prefer to use another endpoint for t= he > intended purpose. > > regards, > Torsten. > > > > Am 23.07.2014 13:04, schrieb Nat Sakimura: > > IMHO, changing the semantics of "response_type" @ authz endpoint this > way is not a good thing. > > > > Instead, defining a new parameter "response_type" @ token endpoint, as I > described in my previous message, > > probably is better. At least, it does not change the semantics of the > parameters of RFC6749. > > > > Nat > > > > 2014-07-23 12:48 GMT-04:00 Thomas Broyer : > > No, I mean response_type=3Dnone and response_type=3Did_token don't genera= te a > code or access token so you don't use the Token Endpoint (which is not th= e > same as the Authentication Endpoint BTW). > > With response_type=3Dcode_for_id_token, you get a code and exchange it fo= r > an id_token only, rather than an access_token, so you're changing the > semantics of the Token Endpoint. > > > > I'm not saying it's a bad thing, just that you can't really compare none > and id_token with code_for_id_token. > > > > On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. > wrote: > > It's only "not using the token endpoint" because the token endpoint > copy-pasted and renamed the authentication endpoint. > > > > -- Justin > > > > On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: > > > > Except that these are about not using the Token Endpoint at all, whereas > the current proposal is about the Token Endpoint not returning an > access_token field in the JSON. > > > > On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones > wrote: > > The response_type "none" is already used in practice, which returns no > access token. It was accepted by the designated experts and registered i= n > the IANA OAuth Authorization Endpoint Response Types registry at > http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#end= point. > The registered "id_token" response type also returns no access token. > > > > So I think the question of whether response types that result in no acces= s > token being returned are acceptable within OAuth 2.0 is already settled, = as > a practical matter. Lots of OAuth implementations are already using such > response types. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Wednesday, July 23, 2014 7:09 AM > *To:* Nat Sakimura > *Cc:* > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > Yes. This is why it has to be discussed in the IETF. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: > > > > Reading back the RFC6749, I am not sure if there is a good way of > suppressing access token from the response and still be OAuth. It will > break whole bunch of implicit definitions like: > > > > authorization server > The server issuing access tokens to the client after successfully > authenticating the resource owner and obtaining authorization. > > > > After all, OAuth is all about issuing access tokens. > > > > Also, I take back my statement on the grant type in my previous mail. > > > > The definition of grant and grant_type are respectively: > > > > grant > > credential representing the resource owner's authorization > > > > grant_type > > (string representing the) type of grant sent to the token endpoint to > obtain the access token > > > > Thus, the grant sent to the token endpoint in this case is still 'code'. > > > > Response type on the other hand is not so well defined in RFC6749, but it > seems it is representing what is to be returned from the authorization > endpoint. To express what is to be returned from token endpoint, perhaps > defining a new parameter to the token endpoint, which is a parallel to th= e > response_type to the Authorization Endpoint seems to be a more symmetric > way, though I am not sure at all if that is going to be OAuth any more. O= ne > straw-man is to define a new parameter called response_type to the token > endpoint such as: > > > > response_type > > OPTIONAL. A string representing what is to be returned from the token > endpoint. > > > > Then define the behavior of the endpoint according to the values as the > parallel to the multi-response type spec. > > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html > > > > Nat > > > > > > > > > > 2014-07-23 7:21 GMT-04:00 Phil Hunt : > > The draft is very clear. > > Phil > > > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: > > The new grant type that I was talking about was > > "authorization_code_but_do_not_return_access_nor_refresh_token", so to > speak. > > It does not return anything per se, but an extension can define something > on top of it. > > > > Then, OIDC can define a binding to it so that the binding only returns ID > Token. > > This binding work should be done in OIDF. Should there be such a grant > type, > > it will be an extremely short spec. > > > > At the same time, if any other specification wanted to define > > other type of tokens and have it returned from the token endpoint, > > it can also use this grant type. > > > > If what you want is to define a new grant type that returns ID Token only= , > > then, I am with Justin. Since "other response than ID Token" is only > > theoretical, this is a more plausible way forward, I suppose. > > > > Nat > > > > 2014-07-22 14:30 GMT-04:00 Justin Richer : > > So the draft would literally turn into: > > "The a4c response type and grant type return an id_token from the token > endpoint with no access token. All parameters and values are defined in > OIDC." > > Seems like the perfect mini extension draft for OIDF to do. > > --Justin > > /sent from my phone/ > > > On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: > > > > What about just defining a new grant type in this WG? > > > > > > 2014-07-22 12:56 GMT-04:00 Phil Hunt : > >> > >> That would be nice. However oidc still needs the new grant type in > order to implement the same flow. > >> > >> Phil > >> > >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: > >> > >>> +1 to Justin. > >>> > >>> > >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : > >>>> > >>>> Errors like these make it clear to me that it would make much more > sense to develop this document in the OpenID Foundation. It should be > something that directly references OpenID Connect Core for all of these > terms instead of redefining them. It's doing authentication, which is > fundamentally what OpenID Connect does on top of OAuth, and I don't see a > good argument for doing this work in this working group. > >>>> > >>>> -- Justin > >>>> > >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer > wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < > Michael.Jones@microsoft.com> wrote: > >>>>>> > >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" definition > being missing is an editorial error. It should be: > >>>>>> > >>>>>> > >>>>>> > >>>>>> consent > >>>>>> > >>>>>> The Authorization Server SHOULD prompt the End-User for consent > before returning information to the Client. If it cannot obtain consent, = it > MUST return an error, typically consent_required. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I'll plan to add it in the next draft. > >>>>> > >>>>> > >>>>> It looks like the consent_required error needs to be defined too, > and you might have forgotten to also import account_selection_required fr= om > OpenID Connect. > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> I agree that there's no difference between a response with multipl= e > "amr" values that includes "mfa" and one that doesn't. Unless a clear us= e > case for why "mfa" is needed can be identified, we can delete it in the > next draft. > >>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>> How about "pwd" then? I fully understand that I should return "pwd" > if the user authenticated using a password, but what "the service if a > client secret is used" means in the definition for the "pwd" value? > >>>>> > >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come > back ;-) ) > >>>>> > >>>>> -- > >>>>> Thomas Broyer > >>>>> /t=C9=94.ma.b=CA=81wa.je/ > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> > >>> > >>> > >>> -- > >>> Nat Sakimura (=3Dnat) > >>> Chairman, OpenID Foundation > >>> http://nat.sakimura.org/ > >>> @_nat_en > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > _______________________________________________ > > 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 > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > 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 > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --089e011614148359fb04fef12335 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is a lot of spin being applied, yes. But not from Ia= n.


O= n Thu, Jul 24, 2014 at 7:00 AM, Anthony Nadalin <tonynad@microsoft.com= > wrote:

I=E2=80=99m sure it was s= pun in a way that could be true since there was no technical value to Ian= =E2=80=99s statement and I=E2=80=99m sure that folks had not read or unders= tand the usage.

=C2=A0

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 6:53 AM
To: Nat Sakimura
Cc: oauth@ietf.o= rg list


Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oaut= h-v2-user-a4c-05.txt

=C2=A0

I'd note that the reaction at the conference to = Ian's statement was overwhelmingly positive. There was a wide range of = industry people here - implementers, practitioners, deployers, strategists,= etc. - and it seems pretty clear that the "rough consensus" of the industry at large is that a4c is not wa= nted or needed.

=C2=A0<= /p>

On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:

And here is a quote from Ian's blog.=C2=A0

=C2=A0

And although the authentication wheel is round, that= doesn=E2=80=99t mean it isn=E2=80=99t without its lumps. First, we do see = some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply = not a fruitful activity and should be put down. =C2=A0

=C2=A0

(Source) http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings= -on-identity-standards-part-1.html

=C2=A0<= /p>

2014-07-23 16:53 GMT-04:00 John Bradley <ve7jtb@ve7jtb.com>:<= u>

=C2=A0

I thought I did post this to the list.=C2=A0<= u>

=C2=A0

I guess I hit the wrong reply on my phone.=C2=A0
=C2=A0

John B.=C2=A0
Sent from my iPhone


On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote:

we are two, at least :-)

Why didn't you post this on the list?

When will be be arriving?

Am 23.07.2014 16:39, schrieb John Bradley:

Ian Glazer mentioned this in his keynote at CIS yest= erday.=C2=A0

=C2=A0

His advice was please stop, =C2=A0we are creating co= nfusion and uncertainty.=C2=A0

=C2=A0

We are becoming our own wort enemy. ( my view though= Ian may share it)

=C2=A0

Returning just an id_ token from the token endpoint = has little real value.=C2=A0

=C2=A0

Something really useful to do would be sorting out c= hannel_id so we can do PoP for id tokens to make them and other cookies sec= ure in the front channel. =C2=A0 I think that is a better use of time.=C2= =A0

=C2=A0

I may be in the minority opinion on that, =C2=A0it w= on't be the first time. =C2=A0



John B.=C2=A0
Sent from my iPhone


On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrot= e:

You are right from a theoretical perspective. Practi= cally this was caused by editorial decisions during the creation of the RFC= . As far as I remember, there was a definition of the (one) token endpoint = response in early versions. No one every considered to NOT respond with an access token from the token endpoi= nt. So one might call it an implicit assumption.

=C2=A0

I'm worried that people get totally confused if = an exception is introduced now given the broad adoption of OAuth based on t= his assumption.

=C2=A0

regards,

Torsten.


Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

Is it said anywhere that ALL grant types MUST use Section 5.1 responses?= Each grant type references Section 5.1, and "access token request&quo= t; is only defined in the context of the defined grant types. Section 2.2 d= oesn't talk about the request or response format.

Le 23 juil. 2014 21:32, "Nat Sakimura" <= ;sakimura@gmail.com= > a =C3=A9crit :

Is it? Apart from the implicit grant that does not u= se token endpoint, all other grant references section 5.1 for the response,= i.e., all shares the same response.=C2=A0

=C2=A0<= /p>

2014-07-23 15:18 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>= :

I hadn't realized the JSON response that requires the access_token f= ield is defined per grant_type, so I'd be OK to "extend the semant= ics" as in the current draft.
That was actually my main concern: that the token endpoint mandates access_= token; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura" <= ;sakimura@gmail.com= > a =C3=A9crit :

=C2=A0

I agree with John that overloading response_type @ a= uthz endpoint is a bad idea. It completely changes the semantics of this pa= rameter. NOTE: what I was proposing was not this parameter, but a new param= eter response_type @ token endpoint.=C2=A0

=C2=A0

I also think overloading grant_type is a bad idea si= nce it changes its semantics. I quote the definition here again:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0

grant_type

type of grant sent to the token endpoint to obtain t= he access token

=C2=A0

It is not about controlling what is to be returned f= rom the token endpoint, but the hint to the token endpoint describing the t= ype of credential the endpoint has received. It seems the "control of = what is being returned from token endpoint" =C2=A0is just a side effect.=C2=A0

=C2=A0

I am somewhat ambivalent[1] in changing the semantic= s of token endpoint, but in as much as "text is the king" for a s= pec., we probably should not change the semantics of it as Torsten points o= ut. If it is ok to change this semantics, I believe defining a new parameter to this endpoint to control the response = would be the best way to go. This is what I have described previously.=C2= =A0

=C2=A0

Defining a new endpoint to send code to get ID Token= and forbidding the use of it against token endpoint would not change the s= emantics of any existing parameter or endpoint, which is good. However, I d= oubt if it is not worth doing. What's the point of avoiding access token scoped to UserInfo endpoint after all? = Defining a new endpoint for just avoiding the access token for userinfo end= point seems way too much the heavy wait way and it breaks interoperabiliy: = it defeats the purpose of standardization.=C2=A0

=C2=A0

I have started feeling that no change is the best wa= y out.=C2=A0

=C2=A0

Nat

=C2=A0

[1] =C2=A0If instead of saying "Token endpoint - used by the client to exchange an authorizati= on=C2=A0grant for an access token, typically with client authenticat= ion", it were saying "Token endpoint - used by the client to exchange an authorization=C2=A0gra= nt for tokens, typically with client authentication", then it would ha= ve been OK. It is an expansion of the capability rather than changing the s= emantics.

=C2=A0

=C2=A0<= /p>

2014-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@micros= oft.com>:

You need the alternative = response_type value ("code_for_id_token" in the A4C draft) to tell the Authorization Server to return a code to be = used with the new grant type, rather than one to use with the "authori= zation_code" grant type (which is what response_type=3Dcode does).

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: torsten@lodderstedt.net


Cc: oa= uth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft= -hunt-oauth-v2-user-a4c-05.txt

=C2=A0

=C2=A0

If we use the token endpoint then a new grant_type i= s the best way.=C2=A0

=C2=A0

It sort of overloads code, but that is better than m= essing with response_type for the authorization endpoint to change the resp= onse from the token_endpoint. =C2=A0That is in my opinion a champion bad idea.=C2=A0

=C2=A0

In discussions developing Connect we decided not to = open this can of worms because no good would come of it. =C2=A0=C2=A0

=C2=A0

The token_endpoint returns a access token. =C2=A0Not= hing requires scope to be associates with the token.=C2=A0

=C2=A0

That is the best solution. =C2=A0No change required.= =C2=A0Better interoperability in my opinion.=C2=A0

=C2=A0

Still on my way to TO, getting in later today.=C2=A0=

=C2=A0

John B.=C2=A0

=C2=A0



Sent from my iPhone


On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the= value of the parameter "grant_type". So there is no need to intr= oduce a new parameter.

wrt to a potential "no_access_token" grant type. I do not cons= ider this a good idea as it changes the semantics of the token endpoint (as= already pointed out by Thomas). This endpoint ALWAYS responds with an acce= ss token to any grant type. I therefore would prefer to use another endpoint for the intended purpose.

regards,
Torsten.

=C2=A0

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type&= quot; @ authz endpoint this way is not a good thing.=C2=A0

=C2=A0

Instead, defining a new parameter "response_typ= e" @ token endpoint, as I described in my previous message,=C2=A0

probably is better. At least, it does not change the= semantics of the parameters of RFC6749.=C2=A0

=C2=A0

=C2=A0Nat=C2=A0

=C2=A0<= /p>

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>= :

No, I mean response_type=3Dnone and response_type=3D= id_token don't generate a code or access token so you don't use the= Token Endpoint (which is not the same as the Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you get a co= de and exchange it for an id_token only, rather than an access_token, so yo= u're changing the semantics of the Token Endpoint.

=C2=A0

I'm not saying it's a bad thing, just that y= ou can't really compare none and id_token with code_for_id_token.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It's only "not using the token endpoint&quo= t; because the token endpoint copy-pasted and renamed the authentication en= dpoint.

=C2=A0

=C2=A0-- Justin

=C2=A0

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com&g= t; wrote:

=C2=A0<= /p>

Except that these are about not using the Token Endp= oint at all, whereas the current proposal is about the Token Endpoint not r= eturning an access_token field in the JSON.

=C2=A0<= /p>

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

The response_type "n= one" is already used in practice, which returns no access token.=C2=A0= It was accepted by the designated experts and registered in the IANA OAuth Authorization E= ndpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpo= int.=C2=A0 The registered "id_token" response type also retur= ns no access token.

=C2=A0

So I think the question o= f whether response types that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical matter.=C2= =A0 Lots of OAuth implementations are already using such response types.

=C2=A0

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for dra= ft-hunt-oauth-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

Phil

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

=C2=A0<= /p>

Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client after s= uccessfully
=C2=A0 =C2=A0 =C2=A0 authenticating the resource owner and obtaining author= ization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token<= /p>

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the t= oken endpoint, which is a parallel to the response_type to the Authorizatio= n Endpoint seems to be a more symmetric way, though I am not sure at all if= that is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the tok= en endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0<= u>

=C2=A0

Nat

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0<= /u>

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0=

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat

=C2=A0<= /p>

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of = OAuth, and I don't see a good argument for doing this work in this work= ing group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wro= te:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The "pr= ompt=3Dconsent" definition being missing is an editorial error.=C2=A0 = It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I'll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there's no difference between a r= esponse with multiple "amr" values that includes "mfa" = and one that doesn't.=C2=A0 Unless a clear use case for why "mfa&q= uot; is needed can be identified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0


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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/

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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

=C2=A0

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


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

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

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

=C2=A0

=C2=A0


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en


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

=C2=A0


--089e011614148359fb04fef12335-- From nobody Thu Jul 24 07:25:09 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111471A004E for ; Thu, 24 Jul 2014 07:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 LLY4Q0vY5BjZ for ; Thu, 24 Jul 2014 07:25:00 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EA81A00D7 for ; Thu, 24 Jul 2014 07:24:59 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so2716648wgh.26 for ; Thu, 24 Jul 2014 07:24:56 -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=HlaVigxtxo/YsfpMIPXXVnImNJn1tV+mxZNb7zxgFOk=; b=eRBlLjGnhrkn5WZXW+BW5vuotsrWnivfErWpjeL8G3kZhQihSuCibAl764CVkXlwAa dQPc1KOffPqcSoINGbVC0xpXIZXSxLYSN7QNiVY4tpdC6LTFciRlOPLbunMqrfaqIpHs C/RDJ4W5dm8EI1qd9FXrbarF67W5MIvIpBxvtiyz+1x38aAnuU5j2crjy4xnNxyJzPmv x1RiSFTBtMP71KwqB5xeqAjpbB9vlPdLFxb6xKntb2dud8B7jmbPElrgMw4NZsdg9shv TmdPpCeANQ0YEUaNywIzSN/iuBb8eCPHkMD4AQFYgFSTiED8XKQT1veVOd9X9OIkPmcI 0/fA== X-Gm-Message-State: ALoCoQl1P6R1xPzOkZKQV+zhoHyPZUDEV/XTlytmvXwOB+7JbnOafghu8qy2HYlvJ2IA2xmx23hk X-Received: by 10.194.91.228 with SMTP id ch4mr12646028wjb.59.1406211895718; Thu, 24 Jul 2014 07:24:55 -0700 (PDT) Received: from dhcp-937d.meeting.ietf.org (dhcp-937d.meeting.ietf.org. [31.133.147.125]) by mx.google.com with ESMTPSA id nc19sm23371722wic.4.2014.07.24.07.24.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 07:24:54 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D08D5767-A436-48C8-8375-550134CAD819" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Thu, 24 Jul 2014 07:25:04 -0700 Message-Id: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> To: Brian Campbell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3h29n9EjOg8nFDr3mZvYIUq0Xcc Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 14:25:07 -0000 --Apple-Mail=_D08D5767-A436-48C8-8375-550134CAD819 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am not against discussion in the WG. I happen to agree with Phil's fundamental premise that some developers = are using OAuth in a insecure way to do authentication. That raises the question of how to best educate them, and or address = technical barriers. It is on the second point that people's opinions seem to divide. Some people thing that if we have a OAuth flow that eliminates the = access token (primarily to avoid asking for consent as I understand it) = and just return a id_token from the token endpoint that can be done in a = spec short enough to het people to read. The subtext of this is that = the Connect specification is too large that it scare people, and they = don't find the spec in the first place because it is not a RFC. An other common possession is that if you don't want to prompt the user = for consent then don't ask for scopes. Twisting the OAuth spec to not = return an access token is not OAuth, yes you could use a different = endpoint rather than the token endpoint, but that is not OAuth. = Connect was careful not to break the OAuth spec. As long as you are = willing to take a access token with no scopes (the client needs to = understand that there are no attributes one way or another anyway or it = will break) then you don't need to change OAuth. You can publish a = profile of connect that satisfies the use case. I think Mike has largely done that but it might be better being less = stingy on references back to the larger spec. The questions are do we modify OAuth to not return an access token, and = if so how, and if we do is it still OAuth. The other largely separable question is do we create confusion in the = market and slow the the adoption of identity federation on top of OAuth, = or find a way to make this look like a positive alignment of interests = around a subset of Connect. There are a number of options. =20 1: We can do a profile in the OIDF and publish it as a IETF document. = Perhaps the cleanest from an IPR point of view. 2:We can do a profile in the OAuth WG referencing connect. 3:We can do a AD sponsored profile that is not in the OAuth WG. 4:We can do a small spec in OAuth to add response_type to the token = endpoint. in combination with 1, 2, or 3 I agree that stoping developers doing insecure things needs to be = addressed somehow. =20 I am not personally convinced that Oauth without access tokens is = sensible. Looking forward to the meeting:) John B. On Jul 24, 2014, at 6:52 AM, Brian Campbell = wrote: > I'd note that the reaction at the conference to Ian's statement was = overwhelmingly positive. There was a wide range of industry people here = - implementers, practitioners, deployers, strategists, etc. - and it = seems pretty clear that the "rough consensus" of the industry at large = is that a4c is not wanted or needed. >=20 >=20 > On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura = wrote: > And here is a quote from Ian's blog.=20 >=20 > And although the authentication wheel is round, that doesn=E2=80=99t = mean it isn=E2=80=99t without its lumps. First, we do see some = reinventing the wheel just to reinvent the wheel. OAuth A4C is simply = not a fruitful activity and should be put down. =20 > =20 > (Source) = http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musing= s-on-identity-standards-part-1.html >=20 >=20 > 2014-07-23 16:53 GMT-04:00 John Bradley : >=20 > I thought I did post this to the list.=20 >=20 > I guess I hit the wrong reply on my phone.=20 > =20 > John B.=20 > Sent from my iPhone >=20 > On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: >=20 >> we are two, at least :-) >>=20 >> Why didn't you post this on the list? >>=20 >> When will be be arriving? >>=20 >> Am 23.07.2014 16:39, schrieb John Bradley: >>=20 >>> Ian Glazer mentioned this in his keynote at CIS yesterday.=20 >>> =20 >>> His advice was please stop, we are creating confusion and = uncertainty.=20 >>> =20 >>> We are becoming our own wort enemy. ( my view though Ian may share = it) >>> =20 >>> Returning just an id_ token from the token endpoint has little real = value.=20 >>> =20 >>> Something really useful to do would be sorting out channel_id so we = can do PoP for id tokens to make them and other cookies secure in the = front channel. I think that is a better use of time.=20 >>> =20 >>> I may be in the minority opinion on that, it won't be the first = time. =20 >>>=20 >>>=20 >>> John B.=20 >>> Sent from my iPhone >>>=20 >>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt = wrote: >>>=20 >>>> You are right from a theoretical perspective. Practically this was = caused by editorial decisions during the creation of the RFC. As far as = I remember, there was a definition of the (one) token endpoint response = in early versions. No one every considered to NOT respond with an access = token from the token endpoint. So one might call it an implicit = assumption. >>>> =20 >>>> I'm worried that people get totally confused if an exception is = introduced now given the broad adoption of OAuth based on this = assumption. >>>> =20 >>>> regards, >>>> Torsten. >>>>=20 >>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer : >>>>=20 >>>>> Is it said anywhere that ALL grant types MUST use Section 5.1 = responses? Each grant type references Section 5.1, and "access token = request" is only defined in the context of the defined grant types. = Section 2.2 doesn't talk about the request or response format. >>>>>=20 >>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" a = =C3=A9crit : >>>>> Is it? Apart from the implicit grant that does not use token = endpoint, all other grant references section 5.1 for the response, i.e., = all shares the same response.=20 >>>>>=20 >>>>>=20 >>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer : >>>>> I hadn't realized the JSON response that requires the access_token = field is defined per grant_type, so I'd be OK to "extend the semantics" = as in the current draft. >>>>> That was actually my main concern: that the token endpoint = mandates access_token; but its actually not the case. >>>>>=20 >>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" a = =C3=A9crit : >>>>>=20 >>>>> I agree with John that overloading response_type @ authz endpoint = is a bad idea. It completely changes the semantics of this parameter. = NOTE: what I was proposing was not this parameter, but a new parameter = response_type @ token endpoint.=20 >>>>> =20 >>>>> I also think overloading grant_type is a bad idea since it changes = its semantics. I quote the definition here again:=20 >>>>> =20 >>>>> grant=20 >>>>> credential representing the resource owner's authorization >>>>> =20 >>>>> grant_type >>>>> type of grant sent to the token endpoint to obtain the access = token >>>>> =20 >>>>> It is not about controlling what is to be returned from the token = endpoint, but the hint to the token endpoint describing the type of = credential the endpoint has received. It seems the "control of what is = being returned from token endpoint" is just a side effect.=20 >>>>> =20 >>>>> I am somewhat ambivalent[1] in changing the semantics of token = endpoint, but in as much as "text is the king" for a spec., we probably = should not change the semantics of it as Torsten points out. If it is ok = to change this semantics, I believe defining a new parameter to this = endpoint to control the response would be the best way to go. This is = what I have described previously.=20 >>>>> =20 >>>>> Defining a new endpoint to send code to get ID Token and = forbidding the use of it against token endpoint would not change the = semantics of any existing parameter or endpoint, which is good. However, = I doubt if it is not worth doing. What's the point of avoiding access = token scoped to UserInfo endpoint after all? Defining a new endpoint for = just avoiding the access token for userinfo endpoint seems way too much = the heavy wait way and it breaks interoperabiliy: it defeats the purpose = of standardization.=20 >>>>> =20 >>>>> I have started feeling that no change is the best way out.=20 >>>>> =20 >>>>> Nat >>>>> =20 >>>>> [1] If instead of saying "Token endpoint - used by the client to = exchange an authorization grant for an access token, typically with = client authentication", it were saying "Token endpoint - used by the = client to exchange an authorization grant for tokens, typically with = client authentication", then it would have been OK. It is an expansion = of the capability rather than changing the semantics. >>>>> =20 >>>>>=20 >>>>>=20 >>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones = : >>>>> You need the alternative response_type value ("code_for_id_token" = in the A4C draft) to tell the Authorization Server to return a code to = be used with the new grant type, rather than one to use with the = "authorization_code" grant type (which is what response_type=3Dcode = does). >>>>>=20 >>>>> =20 >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John = Bradley >>>>> Sent: Wednesday, July 23, 2014 10:33 AM >>>>> To: torsten@lodderstedt.net >>>>>=20 >>>>>=20 >>>>> Cc: oauth@ietf.org >>>>> Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt >>>>> =20 >>>>> =20 >>>>> If we use the token endpoint then a new grant_type is the best = way.=20 >>>>>=20 >>>>> =20 >>>>> It sort of overloads code, but that is better than messing with = response_type for the authorization endpoint to change the response from = the token_endpoint. That is in my opinion a champion bad idea.=20 >>>>>=20 >>>>> =20 >>>>> In discussions developing Connect we decided not to open this can = of worms because no good would come of it. =20 >>>>>=20 >>>>> =20 >>>>> The token_endpoint returns a access token. Nothing requires scope = to be associates with the token.=20 >>>>>=20 >>>>> =20 >>>>> That is the best solution. No change required. Better = interoperability in my opinion.=20 >>>>>=20 >>>>> =20 >>>>> Still on my way to TO, getting in later today.=20 >>>>>=20 >>>>> =20 >>>>> John B.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>=20 >>>>> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >>>>>=20 >>>>> The "response type" of the token endpoint is controlled by the = value of the parameter "grant_type". So there is no need to introduce a = new parameter. >>>>>=20 >>>>> wrt to a potential "no_access_token" grant type. I do not consider = this a good idea as it changes the semantics of the token endpoint (as = already pointed out by Thomas). This endpoint ALWAYS responds with an = access token to any grant type. I therefore would prefer to use another = endpoint for the intended purpose. >>>>>=20 >>>>> regards, >>>>> Torsten. >>>>>=20 >>>>> =20 >>>>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>>>>=20 >>>>> IMHO, changing the semantics of "response_type" @ authz endpoint = this way is not a good thing.=20 >>>>>=20 >>>>> =20 >>>>> Instead, defining a new parameter "response_type" @ token = endpoint, as I described in my previous message,=20 >>>>>=20 >>>>> probably is better. At least, it does not change the semantics of = the parameters of RFC6749.=20 >>>>>=20 >>>>> =20 >>>>> Nat=20 >>>>>=20 >>>>> =20 >>>>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >>>>>=20 >>>>> No, I mean response_type=3Dnone and response_type=3Did_token don't = generate a code or access token so you don't use the Token Endpoint = (which is not the same as the Authentication Endpoint BTW). >>>>>=20 >>>>> With response_type=3Dcode_for_id_token, you get a code and = exchange it for an id_token only, rather than an access_token, so you're = changing the semantics of the Token Endpoint. >>>>>=20 >>>>> =20 >>>>> I'm not saying it's a bad thing, just that you can't really = compare none and id_token with code_for_id_token. >>>>>=20 >>>>> =20 >>>>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. = wrote: >>>>>=20 >>>>> It's only "not using the token endpoint" because the token = endpoint copy-pasted and renamed the authentication endpoint. >>>>>=20 >>>>> =20 >>>>> -- Justin >>>>>=20 >>>>> =20 >>>>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer = wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Except that these are about not using the Token Endpoint at all, = whereas the current proposal is about the Token Endpoint not returning = an access_token field in the JSON. >>>>>=20 >>>>> =20 >>>>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones = wrote: >>>>>=20 >>>>> The response_type "none" is already used in practice, which = returns no access token. It was accepted by the designated experts and = registered in the IANA OAuth Authorization Endpoint Response Types = registry at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endp= oint. The registered "id_token" response type also returns no access = token. >>>>>=20 >>>>> =20 >>>>> So I think the question of whether response types that result in = no access token being returned are acceptable within OAuth 2.0 is = already settled, as a practical matter. Lots of OAuth implementations = are already using such response types. >>>>>=20 >>>>> =20 >>>>> -- = Mike >>>>>=20 >>>>> =20 >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt >>>>> Sent: Wednesday, July 23, 2014 7:09 AM >>>>> To: Nat Sakimura >>>>> Cc: >>>>> Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt >>>>>=20 >>>>> =20 >>>>> Yes. This is why it has to be discussed in the IETF. >>>>>=20 >>>>> =20 >>>>> Phil >>>>>=20 >>>>> =20 >>>>> @independentid >>>>>=20 >>>>> www.independentid.com >>>>>=20 >>>>> phil.hunt@oracle.com >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura = wrote: >>>>>=20 >>>>> =20 >>>>> Reading back the RFC6749, I am not sure if there is a good way of = suppressing access token from the response and still be OAuth. It will = break whole bunch of implicit definitions like:=20 >>>>>=20 >>>>> =20 >>>>> authorization server >>>>> The server issuing access tokens to the client after = successfully >>>>> authenticating the resource owner and obtaining = authorization. >>>>>=20 >>>>> =20 >>>>> After all, OAuth is all about issuing access tokens.=20 >>>>>=20 >>>>> =20 >>>>> Also, I take back my statement on the grant type in my previous = mail.=20 >>>>>=20 >>>>> =20 >>>>> The definition of grant and grant_type are respectively:=20 >>>>>=20 >>>>> =20 >>>>> grant=20 >>>>>=20 >>>>> credential representing the resource owner's authorization >>>>>=20 >>>>> =20 >>>>> grant_type >>>>>=20 >>>>> (string representing the) type of grant sent to the token = endpoint to obtain the access token >>>>>=20 >>>>> =20 >>>>> Thus, the grant sent to the token endpoint in this case is still = 'code'.=20 >>>>>=20 >>>>> =20 >>>>> Response type on the other hand is not so well defined in RFC6749, = but it seems it is representing what is to be returned from the = authorization endpoint. To express what is to be returned from token = endpoint, perhaps defining a new parameter to the token endpoint, which = is a parallel to the response_type to the Authorization Endpoint seems = to be a more symmetric way, though I am not sure at all if that is going = to be OAuth any more. One straw-man is to define a new parameter called = response_type to the token endpoint such as:=20 >>>>>=20 >>>>> =20 >>>>> response_type >>>>>=20 >>>>> OPTIONAL. A string representing what is to be returned from = the token endpoint.=20 >>>>>=20 >>>>> =20 >>>>> Then define the behavior of the endpoint according to the values = as the parallel to the multi-response type spec.=20 >>>>>=20 >>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>>=20 >>>>> =20 >>>>> Nat >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>>>>=20 >>>>> The draft is very clear.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>>=20 >>>>> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >>>>>=20 >>>>> The new grant type that I was talking about was=20 >>>>>=20 >>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", = so to speak.=20 >>>>>=20 >>>>> It does not return anything per se, but an extension can define = something on top of it.=20 >>>>>=20 >>>>> =20 >>>>> Then, OIDC can define a binding to it so that the binding only = returns ID Token.=20 >>>>>=20 >>>>> This binding work should be done in OIDF. Should there be such a = grant type,=20 >>>>>=20 >>>>> it will be an extremely short spec.=20 >>>>>=20 >>>>> =20 >>>>> At the same time, if any other specification wanted to define=20 >>>>>=20 >>>>> other type of tokens and have it returned from the token endpoint,=20= >>>>>=20 >>>>> it can also use this grant type.=20 >>>>>=20 >>>>> =20 >>>>> If what you want is to define a new grant type that returns ID = Token only,=20 >>>>>=20 >>>>> then, I am with Justin. Since "other response than ID Token" is = only=20 >>>>>=20 >>>>> theoretical, this is a more plausible way forward, I suppose.=20 >>>>>=20 >>>>> =20 >>>>> Nat >>>>>=20 >>>>> =20 >>>>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>>>>=20 >>>>> So the draft would literally turn into: >>>>>=20 >>>>> "The a4c response type and grant type return an id_token from the = token endpoint with no access token. All parameters and values are = defined in OIDC." >>>>>=20 >>>>> Seems like the perfect mini extension draft for OIDF to do. >>>>>=20 >>>>> --Justin >>>>>=20 >>>>> /sent from my phone/ >>>>>=20 >>>>>=20 >>>>> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >>>>> > >>>>> > What about just defining a new grant type in this WG? >>>>> > >>>>> > >>>>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>>>> >> >>>>> >> That would be nice. However oidc still needs the new grant type = in order to implement the same flow.=20 >>>>> >> >>>>> >> Phil >>>>> >> >>>>> >> On Jul 22, 2014, at 11:35, Nat Sakimura = wrote: >>>>> >> >>>>> >>> +1 to Justin.=20 >>>>> >>> >>>>> >>> >>>>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. = : >>>>> >>>> >>>>> >>>> Errors like these make it clear to me that it would make much = more sense to develop this document in the OpenID Foundation. It should = be something that directly references OpenID Connect Core for all of = these terms instead of redefining them. It's doing authentication, which = is fundamentally what OpenID Connect does on top of OAuth, and I don't = see a good argument for doing this work in this working group. >>>>> >>>> >>>>> >>>> -- Justin >>>>> >>>> >>>>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer = wrote: >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones = wrote: >>>>> >>>>>> >>>>> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" = definition being missing is an editorial error. It should be: >>>>> >>>>>> >>>>> >>>>>> =20 >>>>> >>>>>> >>>>> >>>>>> consent >>>>> >>>>>> >>>>> >>>>>> The Authorization Server SHOULD prompt the End-User for = consent before returning information to the Client. If it cannot obtain = consent, it MUST return an error, typically consent_required. >>>>> >>>>>> >>>>> >>>>>> =20 >>>>> >>>>>> >>>>> >>>>>> I'll plan to add it in the next draft. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> It looks like the consent_required error needs to be defined = too, and you might have forgotten to also import = account_selection_required from OpenID Connect. >>>>> >>>>> =20 >>>>> >>>>>> >>>>> >>>>>> =20 >>>>> >>>>>> >>>>> >>>>>> I agree that there's no difference between a response with = multiple "amr" values that includes "mfa" and one that doesn't. Unless = a clear use case for why "mfa" is needed can be identified, we can = delete it in the next draft. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> How about "pwd" then? I fully understand that I should = return "pwd" if the user authenticated using a password, but what "the = service if a client secret is used" means in the definition for the = "pwd" value? >>>>> >>>>> >>>>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you = come back ;-) ) >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thomas Broyer >>>>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>> >>>>> _______________________________________________ >>>>> >>>>> 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 >>>>> >>>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> -- >>>>> >>> Nat Sakimura (=3Dnat) >>>>> >>> Chairman, OpenID Foundation >>>>> >>> http://nat.sakimura.org/ >>>>> >>> @_nat_en >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> OAuth mailing list >>>>> >>> OAuth@ietf.org >>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Nat Sakimura (=3Dnat) >>>>> > Chairman, OpenID Foundation >>>>> > http://nat.sakimura.org/ >>>>> > @_nat_en >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>>=20 >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>>=20 >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>> =20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Thomas Broyer >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Thomas Broyer >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>>=20 >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>> =20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> =20 >>>>> =20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> =20 >> =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail=_D08D5767-A436-48C8-8375-550134CAD819 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I am = not against discussion in the WG.

I happen to agree = with Phil's fundamental premise that some developers are using OAuth in = a insecure way to do authentication.

That = raises the question of how to best educate them, and or address = technical barriers.

It is on the second point = that people's opinions seem to divide.

Some = people thing that if we have a OAuth flow that eliminates the access = token (primarily to avoid asking for consent as I understand it) and = just return a id_token from the token endpoint that can be done in a = spec short enough to het people to read.   The subtext of this is = that the Connect specification is too large that it scare people, =  and they don't find the spec in the first place because it is not = a RFC.

An other common possession is that if = you don't want to prompt the user for consent then don't ask for scopes. =  Twisting the OAuth spec to not return an access token is not = OAuth,  yes you could use a different endpoint rather than the = token endpoint, but that is not OAuth.   Connect was careful not to = break the OAuth spec.    As long as you are willing to take a = access token with no scopes (the client needs to understand that there = are no attributes one way or another anyway or it will break) then you = don't need to change OAuth.   You can publish a profile of connect = that satisfies the use case.

I think Mike has = largely done that but it might be better being less stingy on references = back to the larger spec.

The questions are do = we modify OAuth to not return an access token, and if so how,  and = if we do is it still OAuth.

The other largely = separable question is do we create confusion in the market and slow the = the adoption of identity federation on top of OAuth, or find a way to = make this look like a positive alignment of interests around a subset of = Connect.

There are a number of options. =  
1: We can do a profile in the OIDF and publish it as a = IETF document.   Perhaps the cleanest from an IPR point of = view.
2:We can do a profile in the OAuth WG referencing = connect.
3:We can do a AD sponsored profile that is not in the = OAuth WG.
4:We can do a small spec in OAuth to add = response_type to the token endpoint.  in combination with 1, 2, or = 3

I agree that stoping developers doing = insecure things needs to be addressed somehow.  
I am not = personally convinced that Oauth without access tokens is = sensible.

Looking forward to the = meeting:)

John B.
On Jul 24, = 2014, at 6:52 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

I'd note that the reaction at the = conference to Ian's statement was overwhelmingly positive. There was a = wide range of industry people here - implementers, practitioners, = deployers, strategists, etc. - and it seems pretty clear that the "rough = consensus" of the industry at large is that a4c is not wanted or = needed.


On = Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
And = here is a quote from Ian's blog. 

And although the authentication wheel is round, that doesn=E2=80=99t = mean it isn=E2=80=99t without its lumps. First, we do see some = reinventing the wheel just to reinvent the wheel. OAuth A4C is simply = not a fruitful activity and should be put down.  
 
(Source) http://www.tuesdaynight.org/2014/07/23/do-we-have-a-roun= d-wheel-yet-musings-on-identity-standards-part-1.html


2014-07-23 16:53 GMT-04:00 John Bradley <ve7jtb@ve7jtb.com>:
=
I thought I did post this to the = list. 

I guess I hit the wrong reply on my = phone. 
 
John B. 
Sent from my = iPhone

On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote:

we are two, at least = :-)

Why didn't you post this on the list?

When will be be = arriving?

Am 23.07.2014 16:39, schrieb John Bradley:

Ian Glazer mentioned this in his keynote at CIS = yesterday. 
 
His advice was please stop,  we are creating confusion and = uncertainty. 
 
We are becoming our own wort enemy. ( my view though Ian may share = it)
 
Returning just an id_ token from the token endpoint has little real = value. 
 
Something really useful to do would be sorting out channel_id so we = can do PoP for id tokens to make them and other cookies secure in the = front channel.   I think that is a better use of time. 
 
I may be in the minority opinion on that,  it won't be the = first time.  


John B. 
Sent from my = iPhone

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

You are right from a theoretical perspective. Practically this was = caused by editorial decisions during the creation of the RFC. As far as = I remember, there was a definition of the (one) token endpoint response = in early versions. No one every considered to NOT respond with an access = token from the token endpoint. So one might call it an implicit = assumption.
 
I'm worried that people get totally confused if an exception is = introduced now given the broad adoption of OAuth based on this = assumption.
 
regards,
Torsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

Is it said anywhere that ALL grant types MUST use = Section 5.1 responses? Each grant type references Section 5.1, and = "access token request" is only defined in the context of the defined = grant types. Section 2.2 doesn't talk about the request or response = format.

Le 23 juil. 2014 21:32, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit :
Is it? Apart from the implicit grant that does not use = token endpoint, all other grant references section 5.1 for the response, = i.e., all shares the same response. 


2014-07-23 15:18 GMT-04:00 Thomas Broyer = <t.broyer@gmail.com>:

I = hadn't realized the JSON response that requires the access_token field = is defined per grant_type, so I'd be OK to "extend the semantics" as in = the current draft.
That was actually my main concern: that the token = endpoint mandates access_token; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit :

I agree with John that overloading response_type @ authz endpoint = is a bad idea. It completely changes the semantics of this parameter. = NOTE: what I was proposing was not this parameter, but a new parameter = response_type @ token endpoint. 
 
I also think overloading grant_type is a bad idea since it changes = its semantics. I quote the definition here again: 
 
grant 
    credential representing the resource owner's = authorization
 
grant_type
type of grant sent to = the token endpoint to obtain the access token
 
It is not about controlling what is to be returned from the token = endpoint, but the hint to the token endpoint describing the type of = credential the endpoint has received. It seems the "control of what is = being returned from token endpoint"  is just a side = effect. 
 
I am somewhat ambivalent[1] in changing the semantics of token = endpoint, but in as much as "text is the king" for a spec., we probably = should not change the semantics of it as Torsten points out. If it is ok = to change this semantics, I believe defining a new parameter to this = endpoint to control the response would be the best way to go. This is = what I have described previously. 
 
Defining a new endpoint to send code to get ID Token and forbidding = the use of it against token endpoint would not change the semantics of = any existing parameter or endpoint, which is good. However, I doubt if = it is not worth doing. What's the point of avoiding access token scoped = to UserInfo endpoint after all? Defining a new endpoint for just = avoiding the access token for userinfo endpoint seems way too much the = heavy wait way and it breaks interoperabiliy: it defeats the purpose of = standardization. 
 
I have started feeling that no change is the best way = out. 
 
Nat
 
[1]  If instead of saying "Token endpoint - used by the client to exchange an = authorization grant for an access token, typically with = client authentication", it were saying "Token endpoint - used by the client to exchange an = authorization grant for tokens, typically with client = authentication", then it would have been OK. It is an expansion of the = capability rather than changing the semantics.
 


2014-07-23 13:39 GMT-04:00 Mike Jones = <Michael.Jones@microsoft.com>:

You need the alternative response_type value = ("code_for_id_token" in the A4C draft) to tell the Authorization Server to return a code = to be used with the new grant type, rather than one to use with the = "authorization_code" grant type (which is what response_type=3Dcode = does).

 

From:<= /strong> OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of = John Bradley
Sent: Wednesday, July 23, 2014 10:33 = AM
To: torsten@lodderstedt.net


Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt
 
 

If we use the token endpoint then a new = grant_type is the best way. 

 

It sort of overloads code, but that is = better than messing with response_type for the authorization endpoint to = change the response from the token_endpoint.  That is in my opinion = a champion bad idea. 

 

In discussions developing Connect we decided = not to open this can of worms because no good would come of it. =   

 

The token_endpoint returns a access token. =  Nothing requires scope to be associates with the token. 

 

That is the best solution.  No change = required.  Better interoperability in my opinion. 

 

Still on my way to TO, getting in later = today. 

 

John B. 

 



Sent from my iPhone


On Jul = 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the = value of the parameter "grant_type". So there is no need to introduce a = new parameter.

wrt to a potential = "no_access_token" grant type. I do not consider this a good idea as it = changes the semantics of the token endpoint (as already pointed out by = Thomas). This endpoint ALWAYS responds with an access token to any grant = type. I therefore would prefer to use another endpoint for the intended = purpose.

regards,
= Torsten.

 

Am 23.07.2014 13:04, schrieb = Nat Sakimura:

IMHO, changing the semantics of = "response_type" @ authz endpoint this way is not a good = thing. 

 

Instead, defining a new parameter = "response_type" @ token endpoint, as I described in my previous = message, 

probably is better. At least, it does not = change the semantics of the parameters of RFC6749. 

 

 Nat 

 

2014-07-23 12:48 GMT-04:00 Thomas Broyer = <t.broyer@gmail.com>:

No, I mean response_type=3Dnone and = response_type=3Did_token don't generate a code or access token so you = don't use the Token Endpoint (which is not the same as the = Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you = get a code and exchange it for an id_token only, rather than an = access_token, so you're changing the semantics of the Token = Endpoint.

 

I'm not saying it's a bad thing, just that = you can't really compare none and id_token with code_for_id_token.

 

On Wed, Jul 23, 2014 at 6:45 PM, Richer, = Justin P. <jricher@mitre.org> wrote:

It's only "not using the token endpoint" = because the token endpoint copy-pasted and renamed the authentication = endpoint.

 

 -- Justin

 

On Jul 23, 2014, at 9:30 AM, Thomas Broyer = <t.broyer@gmail.com> wrote:



Except that these are about not using the = Token Endpoint at all, whereas the current proposal is about the Token = Endpoint not returning an access_token field in the JSON.

 

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

The response_type "none" is already used in practice, which returns no = access token.  It was accepted by the designated experts and = registered in the IANA OAuth Authorization Endpoint Response Types = registry at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endp= oint.  The registered "id_token" response type also returns no = access token.

 

So I think the question of whether response types that result in no = access token being returned are acceptable within OAuth 2.0 is already = settled, as a practical matter.  Lots of OAuth implementations are = already using such response types.

 

            =             &n= bsp;           &nbs= p;            =            -- = Mike

 

From:<= /strong> OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of = Phil Hunt
Sent: = Wednesday, July 23, 2014 7:09 AM
To: Nat = Sakimura
Cc: <oauth@ietf.org>
Subject: Re: = [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt

 

Yes. = This is why it has to be discussed in the IETF.

 

Phil=

 

@independen= tid

phil.hunt@oracle.com

 
 
 

On Jul 23, 2014, at 9:43 AM, Nat Sakimura = <sakimura@gmail.com> wrote:

 

Reading back the RFC6749, I am not sure if = there is a good way of suppressing access token from the response and = still be OAuth. It will break whole bunch of implicit definitions = like: 

 

authorization server
    =   The server issuing access tokens to the client after = successfully
      authenticating the resource owner = and obtaining authorization.

 

After all, OAuth is all about issuing access = tokens. 

 

Also, I take back my statement on the grant = type in my previous mail. 

 

The definition of grant and grant_type are = respectively: 

 

grant 

    credential representing the = resource owner's authorization

=
          &nbs= p;

grant_type

    (string representing the) = type of grant sent to the token endpoint to obtain the access token

 

Thus, the grant sent to the token endpoint = in this case is still 'code'. 

 

Response type on the other hand is not so = well defined in RFC6749, but it seems it is representing what is to be = returned from the authorization endpoint. To express what is to be = returned from token endpoint, perhaps defining a new parameter to the = token endpoint, which is a parallel to the response_type to the = Authorization Endpoint seems to be a more symmetric way, though I am not = sure at all if that is going to be OAuth any more. One straw-man is to = define a new parameter called response_type to the token endpoint such = as: 

 

response_type

    OPTIONAL. A string = representing what is to be returned from the token endpoint. 

    

Then define the behavior of the endpoint = according to the values as the parallel to the multi-response type = spec. 

 

Nat

    
 
 
 

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:

The draft is very clear. 

Phil


On Jul = 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about = was 

"authorization_code_but_do_not_return_access_nor_refre= sh_token", so to speak. 

It does not return anything per se, but an = extension can define something on top of it. 

 

Then, OIDC can define a binding to it so = that the binding only returns ID Token. 

This binding work should be done in OIDF. = Should there be such a grant type, 

it will be an extremely short = spec. 

 

At the same time, if any other specification = wanted to define 

other type of tokens and have it returned = from the token endpoint, 

it can also use this grant type. 

 

If what you want is to define a new grant = type that returns ID Token only, 

then, I am with Justin. Since "other = response than ID Token" is only 

theoretical, this is a more plausible way = forward, I suppose. 

 

Nat

 

2014-07-22 14:30 GMT-04:00 Justin Richer = <jricher@mit.edu>:

So = the draft would literally turn into:

"The a4c response type and = grant type return an id_token from the token endpoint with no access = token. All parameters and values are defined in OIDC."

Seems like the perfect mini extension draft for OIDF to do.

= --Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura = <sakimura@gmail.com> wrote:
>
> = What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
= >> That would be nice. However oidc still needs the new grant type = in order to implement the same flow. 
>>
>> Phil
>>
>> On Jul 22, 2014, = at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
= >>> +1 to Justin. 
>>>
>>>
>>> 2014-07-22 9:54 = GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
= >>>> Errors like these make it clear to me that it would = make much more sense to develop this document in the OpenID Foundation. = It should be something that directly references OpenID Connect Core for = all of these terms instead of redefining them. It's doing = authentication, which is fundamentally what OpenID Connect does on top = of OAuth, and I don't see a good argument for doing this work in this = working group.
>>>>
>>>>  -- Justin
= >>>>
>>>> On Jul 22, 2014, at 4:30 AM, = Thomas Broyer <t.broyer@gmail.com> wrote:
>>>>
>>>>>
>>>>>
= >>>>>
>>>>> On Mon, Jul 21, 2014 at = 11:52 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>>>
>>>>>> Thanks for your = review, Thomas.  The "prompt=3Dconsent" definition being missing is = an editorial error.  It should be:
>>>>>>
= >>>>>>  
>>>>>>
>>>>>> consent
= >>>>>>
>>>>>> The Authorization = Server SHOULD prompt the End-User for consent before returning = information to the Client. If it cannot obtain consent, it MUST return = an error, typically consent_required.
>>>>>>
>>>>>>  
= >>>>>>
>>>>>> I'll plan to add = it in the next draft.
>>>>>
= >>>>>
>>>>> It looks like the = consent_required error needs to be defined too, and you might have = forgotten to also import account_selection_required from OpenID = Connect.
>>>>>  
>>>>>>
= >>>>>>  
>>>>>>
= >>>>>> I agree that there's no difference between a = response with multiple "amr" values that includes "mfa" and one that = doesn't.  Unless a clear use case for why "mfa" is needed can be = identified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> = Thanks.
>>>>>
>>>>> How about = "pwd" then? I fully understand that I should return "pwd" if the user = authenticated using a password, but what "the service if a client secret = is used" means in the definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at = IETF-90, I'm ready to wait 'til you come back ;-) )
= >>>>>
>>>>> --
= >>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> = _______________________________________________
>>>>> = 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
= >>>>
>>>
>>>
>>>
= >>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID = Foundation
>>> http://nat.sakimura.org/
>>> = @_nat_en
>>>
>>> _______________________________________________
= >>> OAuth mailing list
>>> OAuth@ietf.org
= >>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura = (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 


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



 

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

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



 

-- =
Thomas = Broyer
/t=C9=94.ma.b=CA=81wa.je/


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 
_______________________________________________
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



 
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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



 
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=
_______________________________________________
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




--
Nat Sakimura (=3Dnat)
Chairman, = OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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



= --Apple-Mail=_D08D5767-A436-48C8-8375-550134CAD819-- From nobody Thu Jul 24 07:30:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171111A0030 for ; Thu, 24 Jul 2014 07:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 oEC8iDQX8Kz3 for ; Thu, 24 Jul 2014 07:30:11 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691D31A0375 for ; Thu, 24 Jul 2014 07:30:11 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6OEU9GI027772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Jul 2014 14:30:10 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6OEU8gZ014997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2014 14:30:09 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s6OEU6EL003609; Thu, 24 Jul 2014 14:30:07 GMT Received: from [172.16.54.146] (/206.47.221.210) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 Jul 2014 07:30:06 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_E66BE86D-746A-4EA6-9FC9-4F1F21BDA40F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Thu, 24 Jul 2014 10:30:04 -0400 Message-Id: <45D858DE-6F5E-46D4-828C-9C4C80C3AC2A@oracle.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <9dbf8c7384e341a08334a9ee093697f8@BLUPR03MB309.namprd03.prod.outlook.com> To: Brian Campbell X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/0jD6VeRqrreMH8s1wa43raCWFus Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 14:30:19 -0000 --Apple-Mail=_E66BE86D-746A-4EA6-9FC9-4F1F21BDA40F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Horseshit. Ian failed to mention that we=E2=80=99re responding to bad use of 6749 = by assuming receipt of access token =3D=3D authentication. The OAuth WG is not creating a new feature and we are not re-inventing = here. If anyone is, one could argue that would be OpenID =E2=80=94> at = least in the minds of the web developers. They don=E2=80=99t get why = they have to use OpenID at all. Doesn=E2=80=99t OAuth already do = this??? The working group is responding to an issue that the market has ALREADY = chosen to do all by itself without the presence of any additional = specification like A4C or for that matter OpenID. The market is doing this because they are under the false assumption = that OAuth is doing authentication and that receipt of the access token = IS authentication. It is unbelievable how many developers think OAuth = stands for Open Authentication. The specifications are clear. Yet, the = problem persists. If a developer already thinks they have a solution that is good enough, = why would they go to another standards organization? They aren=E2=80=99t = even looking for an OpenID. They think they already have THE solution! = Which is precisely why OpenID can=E2=80=99t address the issue by itself! = OpenID as an authenticator *is* re-invenention. Yes, OpenID as an IDP = provider standard is its own innovation (re-inventing SAML and many many = other protocols of the past), but within the realm of OAuth, yes it is = innovation in my opinion..=20 But keep in mind that these developers do NOT want an IDP architecture. My point in producing the original draft was to show how simple the = correction could be =E2=80=94 a few pages of clarifying text. Since OpenID has been proposed as the simple solution, let me point out = why it is not for these developers: it is a specification that = incredibly complicates OAuth: OpenID adds 6 response types to OAuth=E2=80=99s 2 OpenID adds 6 errors to OAuth=E2=80=99s 4 OpenID doubles the number of parameters OpenID=E2=80=99s core specification is approximately NINETY THREE pages = to 6749=E2=80=99s 76 pages I=E2=80=99m not at all saying that OpenID is bad. If you want an IDP, = its fine. But if all a client wants is authentication, they think why = can=E2=80=99t I just use RFC6749? The people in the CIS audience were not aware of the facts, so of = course, they cheered against what appears to be a fork. That=E2=80=99s = after all how it was presented. In fact, Ian=E2=80=99s presentation = sounds horribly trivial and insensitive in its handling of this case. The point is, NOT responding to this issue does not mean it goes away. = It gets worse. The market is already choosing to use OAuth for = authentication. Apparently none of those people were at CIS. They = should have listened to Ian! Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 24, 2014, at 10:18 AM, Brian Campbell = wrote: > There is a lot of spin being applied, yes. But not from Ian. >=20 >=20 > On Thu, Jul 24, 2014 at 7:00 AM, Anthony Nadalin = wrote: > I=E2=80=99m sure it was spun in a way that could be true since there = was no technical value to Ian=E2=80=99s statement and I=E2=80=99m sure = that folks had not read or understand the usage. >=20 > =20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian = Campbell > Sent: Thursday, July 24, 2014 6:53 AM > To: Nat Sakimura > Cc: oauth@ietf.org list >=20 >=20 > Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt >=20 > =20 >=20 > I'd note that the reaction at the conference to Ian's statement was = overwhelmingly positive. There was a wide range of industry people here = - implementers, practitioners, deployers, strategists, etc. - and it = seems pretty clear that the "rough consensus" of the industry at large = is that a4c is not wanted or needed. >=20 > =20 >=20 > On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura = wrote: >=20 > And here is a quote from Ian's blog.=20 >=20 > =20 >=20 > And although the authentication wheel is round, that doesn=E2=80=99t = mean it isn=E2=80=99t without its lumps. First, we do see some = reinventing the wheel just to reinvent the wheel. OAuth A4C is simply = not a fruitful activity and should be put down. =20 >=20 > =20 >=20 > (Source) = http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musing= s-on-identity-standards-part-1.html >=20 > =20 >=20 > 2014-07-23 16:53 GMT-04:00 John Bradley : >=20 > =20 >=20 > I thought I did post this to the list.=20 >=20 > =20 >=20 > I guess I hit the wrong reply on my phone.=20 > =20 >=20 > John B.=20 > Sent from my iPhone >=20 >=20 > On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: >=20 > we are two, at least :-) >=20 > Why didn't you post this on the list? >=20 > When will be be arriving? >=20 > Am 23.07.2014 16:39, schrieb John Bradley: >=20 > Ian Glazer mentioned this in his keynote at CIS yesterday.=20 >=20 > =20 >=20 > His advice was please stop, we are creating confusion and = uncertainty.=20 >=20 > =20 >=20 > We are becoming our own wort enemy. ( my view though Ian may share it) >=20 > =20 >=20 > Returning just an id_ token from the token endpoint has little real = value.=20 >=20 > =20 >=20 > Something really useful to do would be sorting out channel_id so we = can do PoP for id tokens to make them and other cookies secure in the = front channel. I think that is a better use of time.=20 >=20 > =20 >=20 > I may be in the minority opinion on that, it won't be the first time. = =20 >=20 >=20 >=20 > John B.=20 > Sent from my iPhone >=20 >=20 > On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt = wrote: >=20 > You are right from a theoretical perspective. Practically this was = caused by editorial decisions during the creation of the RFC. As far as = I remember, there was a definition of the (one) token endpoint response = in early versions. No one every considered to NOT respond with an access = token from the token endpoint. So one might call it an implicit = assumption. >=20 > =20 >=20 > I'm worried that people get totally confused if an exception is = introduced now given the broad adoption of OAuth based on this = assumption. >=20 > =20 >=20 > regards, >=20 > Torsten. >=20 >=20 > Am 23.07.2014 um 15:41 schrieb Thomas Broyer : >=20 > Is it said anywhere that ALL grant types MUST use Section 5.1 = responses? Each grant type references Section 5.1, and "access token = request" is only defined in the context of the defined grant types. = Section 2.2 doesn't talk about the request or response format. >=20 > Le 23 juil. 2014 21:32, "Nat Sakimura" a =C3=A9crit= : >=20 > Is it? Apart from the implicit grant that does not use token endpoint, = all other grant references section 5.1 for the response, i.e., all = shares the same response.=20 >=20 > =20 >=20 > 2014-07-23 15:18 GMT-04:00 Thomas Broyer : >=20 > I hadn't realized the JSON response that requires the access_token = field is defined per grant_type, so I'd be OK to "extend the semantics" = as in the current draft. > That was actually my main concern: that the token endpoint mandates = access_token; but its actually not the case. >=20 > Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9crit= : >=20 > =20 >=20 > I agree with John that overloading response_type @ authz endpoint is a = bad idea. It completely changes the semantics of this parameter. NOTE: = what I was proposing was not this parameter, but a new parameter = response_type @ token endpoint.=20 >=20 > =20 >=20 > I also think overloading grant_type is a bad idea since it changes its = semantics. I quote the definition here again:=20 >=20 > =20 >=20 > grant=20 >=20 > credential representing the resource owner's authorization >=20 > =20 >=20 > grant_type >=20 > type of grant sent to the token endpoint to obtain the access token >=20 > =20 >=20 > It is not about controlling what is to be returned from the token = endpoint, but the hint to the token endpoint describing the type of = credential the endpoint has received. It seems the "control of what is = being returned from token endpoint" is just a side effect.=20 >=20 > =20 >=20 > I am somewhat ambivalent[1] in changing the semantics of token = endpoint, but in as much as "text is the king" for a spec., we probably = should not change the semantics of it as Torsten points out. If it is ok = to change this semantics, I believe defining a new parameter to this = endpoint to control the response would be the best way to go. This is = what I have described previously.=20 >=20 > =20 >=20 > Defining a new endpoint to send code to get ID Token and forbidding = the use of it against token endpoint would not change the semantics of = any existing parameter or endpoint, which is good. However, I doubt if = it is not worth doing. What's the point of avoiding access token scoped = to UserInfo endpoint after all? Defining a new endpoint for just = avoiding the access token for userinfo endpoint seems way too much the = heavy wait way and it breaks interoperabiliy: it defeats the purpose of = standardization.=20 >=20 > =20 >=20 > I have started feeling that no change is the best way out.=20 >=20 > =20 >=20 > Nat >=20 > =20 >=20 > [1] If instead of saying "Token endpoint - used by the client to = exchange an authorization grant for an access token, typically with = client authentication", it were saying "Token endpoint - used by the = client to exchange an authorization grant for tokens, typically with = client authentication", then it would have been OK. It is an expansion = of the capability rather than changing the semantics. >=20 > =20 >=20 > =20 >=20 > 2014-07-23 13:39 GMT-04:00 Mike Jones : >=20 > You need the alternative response_type value ("code_for_id_token" in = the A4C draft) to tell the Authorization Server to return a code to be = used with the new grant type, rather than one to use with the = "authorization_code" grant type (which is what response_type=3Dcode = does). >=20 > =20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Wednesday, July 23, 2014 10:33 AM > To: torsten@lodderstedt.net >=20 >=20 > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt >=20 > =20 >=20 > =20 >=20 > If we use the token endpoint then a new grant_type is the best way.=20 >=20 > =20 >=20 > It sort of overloads code, but that is better than messing with = response_type for the authorization endpoint to change the response from = the token_endpoint. That is in my opinion a champion bad idea.=20 >=20 > =20 >=20 > In discussions developing Connect we decided not to open this can of = worms because no good would come of it. =20 >=20 > =20 >=20 > The token_endpoint returns a access token. Nothing requires scope to = be associates with the token.=20 >=20 > =20 >=20 > That is the best solution. No change required. Better = interoperability in my opinion.=20 >=20 > =20 >=20 > Still on my way to TO, getting in later today.=20 >=20 > =20 >=20 > John B.=20 >=20 > =20 >=20 >=20 >=20 > Sent from my iPhone >=20 >=20 > On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >=20 > The "response type" of the token endpoint is controlled by the value = of the parameter "grant_type". So there is no need to introduce a new = parameter. >=20 > wrt to a potential "no_access_token" grant type. I do not consider = this a good idea as it changes the semantics of the token endpoint (as = already pointed out by Thomas). This endpoint ALWAYS responds with an = access token to any grant type. I therefore would prefer to use another = endpoint for the intended purpose. >=20 > regards, > Torsten. >=20 > =20 >=20 > Am 23.07.2014 13:04, schrieb Nat Sakimura: >=20 > IMHO, changing the semantics of "response_type" @ authz endpoint this = way is not a good thing.=20 >=20 > =20 >=20 > Instead, defining a new parameter "response_type" @ token endpoint, as = I described in my previous message,=20 >=20 > probably is better. At least, it does not change the semantics of the = parameters of RFC6749.=20 >=20 > =20 >=20 > Nat=20 >=20 > =20 >=20 > 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >=20 > No, I mean response_type=3Dnone and response_type=3Did_token don't = generate a code or access token so you don't use the Token Endpoint = (which is not the same as the Authentication Endpoint BTW). >=20 > With response_type=3Dcode_for_id_token, you get a code and exchange it = for an id_token only, rather than an access_token, so you're changing = the semantics of the Token Endpoint. >=20 > =20 >=20 > I'm not saying it's a bad thing, just that you can't really compare = none and id_token with code_for_id_token. >=20 > =20 >=20 > On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. = wrote: >=20 > It's only "not using the token endpoint" because the token endpoint = copy-pasted and renamed the authentication endpoint. >=20 > =20 >=20 > -- Justin >=20 > =20 >=20 > On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: >=20 > =20 >=20 > Except that these are about not using the Token Endpoint at all, = whereas the current proposal is about the Token Endpoint not returning = an access_token field in the JSON. >=20 > =20 >=20 > On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones = wrote: >=20 > The response_type "none" is already used in practice, which returns no = access token. It was accepted by the designated experts and registered = in the IANA OAuth Authorization Endpoint Response Types registry at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endp= oint. The registered "id_token" response type also returns no access = token. >=20 > =20 >=20 > So I think the question of whether response types that result in no = access token being returned are acceptable within OAuth 2.0 is already = settled, as a practical matter. Lots of OAuth implementations are = already using such response types. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Wednesday, July 23, 2014 7:09 AM > To: Nat Sakimura > Cc: > Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt >=20 > =20 >=20 > Yes. This is why it has to be discussed in the IETF. >=20 > =20 >=20 > Phil >=20 > =20 >=20 > @independentid >=20 > www.independentid.com >=20 > phil.hunt@oracle.com >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: >=20 > =20 >=20 > Reading back the RFC6749, I am not sure if there is a good way of = suppressing access token from the response and still be OAuth. It will = break whole bunch of implicit definitions like:=20 >=20 > =20 >=20 > authorization server > The server issuing access tokens to the client after = successfully > authenticating the resource owner and obtaining authorization. >=20 > =20 >=20 > After all, OAuth is all about issuing access tokens.=20 >=20 > =20 >=20 > Also, I take back my statement on the grant type in my previous mail.=20= >=20 > =20 >=20 > The definition of grant and grant_type are respectively:=20 >=20 > =20 >=20 > grant=20 >=20 > credential representing the resource owner's authorization >=20 > =20 >=20 > grant_type >=20 > (string representing the) type of grant sent to the token endpoint = to obtain the access token >=20 > =20 >=20 > Thus, the grant sent to the token endpoint in this case is still = 'code'.=20 >=20 > =20 >=20 > Response type on the other hand is not so well defined in RFC6749, but = it seems it is representing what is to be returned from the = authorization endpoint. To express what is to be returned from token = endpoint, perhaps defining a new parameter to the token endpoint, which = is a parallel to the response_type to the Authorization Endpoint seems = to be a more symmetric way, though I am not sure at all if that is going = to be OAuth any more. One straw-man is to define a new parameter called = response_type to the token endpoint such as:=20 >=20 > =20 >=20 > response_type >=20 > OPTIONAL. A string representing what is to be returned from the = token endpoint.=20 >=20 > =20 >=20 > Then define the behavior of the endpoint according to the values as = the parallel to the multi-response type spec.=20 >=20 > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >=20 > =20 >=20 > Nat >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > 2014-07-23 7:21 GMT-04:00 Phil Hunt : >=20 > The draft is very clear.=20 >=20 > Phil >=20 >=20 > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >=20 > The new grant type that I was talking about was=20 >=20 > "authorization_code_but_do_not_return_access_nor_refresh_token", so to = speak.=20 >=20 > It does not return anything per se, but an extension can define = something on top of it.=20 >=20 > =20 >=20 > Then, OIDC can define a binding to it so that the binding only returns = ID Token.=20 >=20 > This binding work should be done in OIDF. Should there be such a grant = type,=20 >=20 > it will be an extremely short spec.=20 >=20 > =20 >=20 > At the same time, if any other specification wanted to define=20 >=20 > other type of tokens and have it returned from the token endpoint,=20 >=20 > it can also use this grant type.=20 >=20 > =20 >=20 > If what you want is to define a new grant type that returns ID Token = only,=20 >=20 > then, I am with Justin. Since "other response than ID Token" is only=20= >=20 > theoretical, this is a more plausible way forward, I suppose.=20 >=20 > =20 >=20 > Nat >=20 > =20 >=20 > 2014-07-22 14:30 GMT-04:00 Justin Richer : >=20 > So the draft would literally turn into: >=20 > "The a4c response type and grant type return an id_token from the = token endpoint with no access token. All parameters and values are = defined in OIDC." >=20 > Seems like the perfect mini extension draft for OIDF to do. >=20 > --Justin >=20 > /sent from my phone/ >=20 >=20 > On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: > > > > What about just defining a new grant type in this WG? > > > > > > 2014-07-22 12:56 GMT-04:00 Phil Hunt : > >> > >> That would be nice. However oidc still needs the new grant type in = order to implement the same flow.=20 > >> > >> Phil > >> > >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: > >> > >>> +1 to Justin.=20 > >>> > >>> > >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : > >>>> > >>>> Errors like these make it clear to me that it would make much = more sense to develop this document in the OpenID Foundation. It should = be something that directly references OpenID Connect Core for all of = these terms instead of redefining them. It's doing authentication, which = is fundamentally what OpenID Connect does on top of OAuth, and I don't = see a good argument for doing this work in this working group. > >>>> > >>>> -- Justin > >>>> > >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer = wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones = wrote: > >>>>>> > >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" = definition being missing is an editorial error. It should be: > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> consent > >>>>>> > >>>>>> The Authorization Server SHOULD prompt the End-User for consent = before returning information to the Client. If it cannot obtain consent, = it MUST return an error, typically consent_required. > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> I'll plan to add it in the next draft. > >>>>> > >>>>> > >>>>> It looks like the consent_required error needs to be defined = too, and you might have forgotten to also import = account_selection_required from OpenID Connect. > >>>>> =20 > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> I agree that there's no difference between a response with = multiple "amr" values that includes "mfa" and one that doesn't. Unless = a clear use case for why "mfa" is needed can be identified, we can = delete it in the next draft. > >>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>> How about "pwd" then? I fully understand that I should return = "pwd" if the user authenticated using a password, but what "the service = if a client secret is used" means in the definition for the "pwd" value? > >>>>> > >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come = back ;-) ) > >>>>> > >>>>> -- > >>>>> Thomas Broyer > >>>>> /t=C9=94.ma.b=CA=81wa.je/ > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> > >>> > >>> > >>> -- > >>> Nat Sakimura (=3Dnat) > >>> Chairman, OpenID Foundation > >>> http://nat.sakimura.org/ > >>> @_nat_en > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en >=20 >=20 >=20 >=20 > =20 >=20 > --=20 > Nat Sakimura (=3Dnat) >=20 > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 >=20 >=20 >=20 > =20 >=20 > --=20 > Nat Sakimura (=3Dnat) >=20 > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > =20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > =20 >=20 > --=20 > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > =20 >=20 > --=20 > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > =20 >=20 > --=20 > Nat Sakimura (=3Dnat) >=20 > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > =20 >=20 > --=20 > Nat Sakimura (=3Dnat) >=20 > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > =20 >=20 > --=20 > Nat Sakimura (=3Dnat) >=20 > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=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 >=20 > =20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > =20 >=20 > --=20 > Nat Sakimura (=3Dnat) >=20 > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=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 --Apple-Mail=_E66BE86D-746A-4EA6-9FC9-4F1F21BDA40F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Horseshit.

Ian failed to mention = that we=E2=80=99re responding to bad use of 6749 by assuming receipt of = access token =3D=3D authentication.

The OAuth WG is = not creating a new feature and we are not re-inventing here. If anyone = is, one could argue that would be OpenID =E2=80=94> at least in the = minds of the web developers. They don=E2=80=99t get why they have to use = OpenID at all.  Doesn=E2=80=99t OAuth already do = this???

The working group is responding to an = issue that the market has ALREADY chosen to do all by itself without the = presence of any additional specification like A4C or for that matter = OpenID.

The market is doing this = because they are under the false assumption that OAuth is doing = authentication and that receipt of the access token IS = authentication. It is unbelievable how many developers think OAuth = stands for Open Authentication.  The specifications are clear. Yet, = the problem persists.

If a developer already = thinks they have a solution that is good enough, why would they go to = another standards organization? They aren=E2=80=99t even looking for an = OpenID. They think they already have THE solution!  Which is = precisely why OpenID can=E2=80=99t address the issue by itself! =  OpenID as an authenticator *is* re-invenention.  Yes, OpenID = as an IDP provider standard is its own innovation (re-inventing SAML and = many many other protocols of the past), but within the realm of OAuth, = yes it is innovation in my opinion.. 

But = keep in mind that these developers do NOT want an IDP = architecture.

My point in producing the = original draft was to show how simple the correction could be =E2=80=94 = a few pages of clarifying text.

Since OpenID = has been proposed as the simple solution, let me point out why it is not = for these developers: it is a specification that incredibly complicates = OAuth:
  • OpenID adds 6 response = types to OAuth=E2=80=99s 2
  • OpenID adds 6 errors to OAuth=E2=80=99s= 4
  • OpenID doubles the number of parameters
  • OpenID=E2=80=99= s core specification is approximately NINETY THREE pages to 6749=E2=80=99s= 76 pages

I=E2=80=99m not at all = saying that OpenID is bad. If you want an IDP, its fine.  But if = all a client wants is authentication, they think why can=E2=80=99t I = just use RFC6749?

The people in the CIS = audience were not aware of the facts, so of course, they cheered against = what appears to be a fork. That=E2=80=99s after all how it was = presented. In fact, Ian=E2=80=99s presentation sounds horribly trivial = and insensitive in its handling of this = case.

The point is, NOT responding to this = issue does not mean it goes away. It gets worse. The market is already = choosing to use OAuth for authentication. Apparently none of those = people were at CIS.  They should have listened to = Ian!


On Jul 24, 2014, at 10:18 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

There is a lot of spin being applied, = yes. But not from Ian.


On Thu, Jul 24, 2014 at 7:00 AM, Anthony Nadalin = <tonynad@microsoft.com> wrote:

I=E2=80=99m sure it was spun in a way that could = be true since there was no technical value to Ian=E2=80=99s statement = and I=E2=80=99m sure that folks had not read or understand the usage.

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 6:53 AM
To: Nat Sakimura
Cc: oauth@ietf.org list


Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt

 

I'd note that the reaction at the conference = to Ian's statement was overwhelmingly positive. There was a wide range = of industry people here - implementers, practitioners, deployers, = strategists, etc. - and it seems pretty clear that the "rough consensus" of the industry at large is that a4c is not wanted or = needed.

 

On Thu, Jul 24, 2014 at 5:29 AM, Nat = Sakimura <sakimura@gmail.com> wrote:

And here is a quote from Ian's = blog. 

 

And although the authentication wheel is round, that = doesn=E2=80=99t mean it isn=E2=80=99t without its lumps. First, we do = see some reinventing the wheel just to reinvent the wheel. OAuth A4C is = simply not a fruitful activity and should be put down. =  

 

(Source) = http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musing= s-on-identity-standards-part-1.html

 

2014-07-23 16:53 GMT-04:00 John Bradley = <ve7jtb@ve7jtb.com>:

 

I thought I did post this to the = list. 

 

I guess I hit the wrong reply on my = phone. 
 

John B. 
Sent from my iPhone


On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote:

we are two, at least :-)

Why didn't you post = this on the list?

When will be be = arriving?

Am 23.07.2014 16:39, schrieb John = Bradley:

Ian Glazer mentioned this in his keynote at = CIS yesterday. 

 

His advice was please stop,  we are = creating confusion and uncertainty. 

 

We are becoming our own wort enemy. ( my = view though Ian may share it)

 

Returning just an id_ token from the token = endpoint has little real value. 

 

Something really useful to do would be = sorting out channel_id so we can do PoP for id tokens to make them and = other cookies secure in the front channel.   I think that is a = better use of time. 

 

I may be in the minority opinion on that, =  it won't be the first time.  



John B. 
Sent from my iPhone


On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

You are right from a theoretical = perspective. Practically this was caused by editorial decisions during = the creation of the RFC. As far as I remember, there was a definition of = the (one) token endpoint response in early versions. No one every considered to NOT respond with an access token from the token = endpoint. So one might call it an implicit assumption.

 

I'm worried that people get totally confused = if an exception is introduced now given the broad adoption of OAuth = based on this assumption.

 

regards,

Torsten.


Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

Is it said anywhere that ALL grant types MUST use Section 5.1 = responses? Each grant type references Section 5.1, and "access token = request" is only defined in the context of the defined grant types. = Section 2.2 doesn't talk about the request or response format.

Le 23 juil. 2014 21:32, "Nat Sakimura" = <sakimura@gmail.com> a =C3=A9crit = :

Is it? Apart from the implicit grant that = does not use token endpoint, all other grant references section 5.1 for = the response, i.e., all shares the same = response. 

 

2014-07-23 15:18 GMT-04:00 Thomas Broyer = <t.broyer@gmail.com>:

I = hadn't realized the JSON response that requires the access_token field = is defined per grant_type, so I'd be OK to "extend the semantics" as in = the current draft.
That was actually my main concern: that the token endpoint mandates = access_token; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura" = <sakimura@gmail.com> a =C3=A9crit :

 

I agree with John that overloading = response_type @ authz endpoint is a bad idea. It completely changes the = semantics of this parameter. NOTE: what I was proposing was not this = parameter, but a new parameter response_type @ token = endpoint. 

 

I also think overloading grant_type is a bad = idea since it changes its semantics. I quote the definition here = again: 

 

grant 

    credential representing the = resource owner's authorization

 

grant_type

type of grant sent to the token endpoint to = obtain the access token

 

It is not about controlling what is to be = returned from the token endpoint, but the hint to the token endpoint = describing the type of credential the endpoint has received. It seems = the "control of what is being returned from token endpoint"  is just a side effect. 

 

I am somewhat ambivalent[1] in changing the = semantics of token endpoint, but in as much as "text is the king" for a = spec., we probably should not change the semantics of it as Torsten = points out. If it is ok to change this semantics, I believe defining a new parameter to this endpoint to control the = response would be the best way to go. This is what I have described = previously. 

 

Defining a new endpoint to send code to get = ID Token and forbidding the use of it against token endpoint would not = change the semantics of any existing parameter or endpoint, which is = good. However, I doubt if it is not worth doing. What's the point of avoiding access token scoped to UserInfo endpoint after = all? Defining a new endpoint for just avoiding the access token for = userinfo endpoint seems way too much the heavy wait way and it breaks = interoperabiliy: it defeats the purpose of = standardization. 

 

I have started feeling that no change is the = best way out. 

 

Nat

 

[1]  If instead of saying "Token endpoint - used by the client to exchange an = authorization grant for an access token, typically with = client authentication", it were saying "Token endpoint - used by the client to exchange an = authorization grant for tokens, typically with client = authentication", then it would have been OK. It is an expansion of the = capability rather than changing the semantics.

 

 

2014-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@microsoft.com>:

You need the alternative response_type value = ("code_for_id_token" in the A4C draft) to tell the Authorization Server to return a code to = be used with the new grant type, rather than one to use with the = "authorization_code" grant type (which is what response_type=3Dcode = does).

 

From: OAuth [mailto:oauth-bounces@ietf.org] On = Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To:= torsten@lodderstedt.net


Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt

 

 

If we use the token endpoint then a new = grant_type is the best way. 

 

It sort of overloads code, but that is = better than messing with response_type for the authorization endpoint to = change the response from the token_endpoint.  That is in my opinion a champion bad idea. 

 

In discussions developing Connect we decided = not to open this can of worms because no good would come of it. =   

 

The token_endpoint returns a access token. =  Nothing requires scope to be associates with the = token. 

 

That is the best solution.  No change = required.  Better interoperability in my = opinion. 

 

Still on my way to TO, getting in later = today. 

 

John B. 

 



Sent from my iPhone


On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the = value of the parameter "grant_type". So there is no need to introduce a = new parameter.

wrt to a potential "no_access_token" = grant type. I do not consider this a good idea as it changes the = semantics of the token endpoint (as already pointed out by Thomas). This = endpoint ALWAYS responds with an access token to any grant type. I = therefore would prefer to use another endpoint for the intended = purpose.

regards,
Torsten.

 

Am 23.07.2014 = 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of = "response_type" @ authz endpoint this way is not a good = thing. 

 

Instead, defining a new parameter = "response_type" @ token endpoint, as I described in my previous = message, 

probably is better. At least, it does not = change the semantics of the parameters of = RFC6749. 

 

 Nat 

 

2014-07-23 12:48 GMT-04:00 Thomas Broyer = <t.broyer@gmail.com>:

No, I mean response_type=3Dnone and = response_type=3Did_token don't generate a code or access token so you = don't use the Token Endpoint (which is not the same as the = Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you = get a code and exchange it for an id_token only, rather than an = access_token, so you're changing the semantics of the Token = Endpoint.

 

I'm not saying it's a bad thing, just that = you can't really compare none and id_token with = code_for_id_token.

 

On Wed, Jul 23, 2014 at 6:45 PM, Richer, = Justin P. <jricher@mitre.org> wrote:

It's only "not using the token endpoint" = because the token endpoint copy-pasted and renamed the authentication = endpoint.

 

 -- Justin

 

On Jul 23, 2014, at 9:30 AM, Thomas Broyer = <t.broyer@gmail.com> wrote:

 

Except that these are about not using the = Token Endpoint at all, whereas the current proposal is about the Token = Endpoint not returning an access_token field in the = JSON.

 

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones = <Michael.Jones@microsoft.com> = wrote:

The response_type "none" is already used in = practice, which returns no access token.  It was accepted by the designated experts and registered in the IANA OAuth = Authorization Endpoint Response Types registry at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endp= oint.  The registered "id_token" response type also returns no = access token.

 

So I think the question of whether response types = that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical = matter.  Lots of OAuth implementations are already using such = response types.

 

        &nbs= p;            =             &n= bsp;           &nbs= p;            =   -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On = Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To:= Nat Sakimura
Cc:= <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt

 

Yes. This is why it has to be discussed in the = IETF.

 

 <= /span>

 

 

On Jul 23, 2014, at 9:43 AM, Nat Sakimura = <sakimura@gmail.com> wrote:

 

Reading back the RFC6749, I am not sure if = there is a good way of suppressing access token from the response and = still be OAuth. It will break whole bunch of implicit definitions like: 

 

authorization server
      The server issuing access tokens to the client = after successfully
      authenticating the resource owner and obtaining = authorization.

 

After all, OAuth is all about issuing access = tokens. 

 

Also, I take back my statement on the grant = type in my previous mail. 

 

The definition of grant and grant_type are = respectively: 

 

grant 

    credential representing the = resource owner's authorization

         =   

grant_type

    (string representing the) = type of grant sent to the token endpoint to obtain the access = token

 

Thus, the grant sent to the token endpoint = in this case is still 'code'. 

 

Response type on the other hand is not so = well defined in RFC6749, but it seems it is representing what is to be = returned from the authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to = the token endpoint, which is a parallel to the response_type to the = Authorization Endpoint seems to be a more symmetric way, though I am not = sure at all if that is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the = token endpoint such as: 

 

response_type

    OPTIONAL. A string = representing what is to be returned from the token = endpoint. 

    

Then define the behavior of the endpoint = according to the values as the parallel to the multi-response type = spec. 

 

Nat

    

 

 

 

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:

The draft is very clear. 

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about = was 

"authorization_code_but_do_not_return_access_nor_refre= sh_token", so to speak. 

It does not return anything per se, but an = extension can define something on top of it. 

 

Then, OIDC can define a binding to it so = that the binding only returns ID Token. 

This binding work should be done in OIDF. = Should there be such a grant type, 

it will be an extremely short = spec. 

 

At the same time, if any other specification = wanted to define 

other type of tokens and have it returned = from the token endpoint, 

it can also use this grant = type. 

 

If what you want is to define a new grant = type that returns ID Token only, 

then, I am with Justin. Since "other = response than ID Token" is only 

theoretical, this is a more plausible way = forward, I suppose. 

 

Nat

 

2014-07-22 14:30 GMT-04:00 Justin Richer = <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the token = endpoint with no access token. All parameters and values are defined in = OIDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type = in order to implement the same flow. 
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin. 
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would = make much more sense to develop this document in the OpenID Foundation. = It should be something that directly references OpenID Connect Core for = all of these terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top = of OAuth, and I don't see a good argument for doing this work in this = working group.
>>>>
>>>>  -- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.  The = "prompt=3Dconsent" definition being missing is an editorial error.  = It should be:
>>>>>>
>>>>>>  
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the = End-User for consent before returning information to the Client. If it = cannot obtain consent, it MUST return an error, typically = consent_required.
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I'll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to = be defined too, and you might have forgotten to also import = account_selection_required from OpenID Connect.
>>>>>  
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I agree that there's no difference between a = response with multiple "amr" values that includes "mfa" and one that = doesn't.  Unless a clear use case for why "mfa" is needed can be = identified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand that I = should return "pwd" if the user authenticated using a password, but what = "the service if a client secret is used" means in the definition for the = "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to wait = 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 


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



 

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

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



 

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 

_______________________________________________
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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________
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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
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=_E66BE86D-746A-4EA6-9FC9-4F1F21BDA40F-- From nobody Thu Jul 24 07:34:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BB91A03A8 for ; Thu, 24 Jul 2014 07:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 VirC9_uAhbF0 for ; Thu, 24 Jul 2014 07:33:48 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC53A1A039C for ; Thu, 24 Jul 2014 07:33:47 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6OEXktA016730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Jul 2014 14:33:47 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s6OEXisN015821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2014 14:33:45 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6OEXiGZ026737; Thu, 24 Jul 2014 14:33:44 GMT Received: from [172.16.54.146] (/206.47.221.210) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 Jul 2014 07:33:43 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_73B9110A-C4B3-4AB1-98FD-227211F72BA3" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Thu, 24 Jul 2014 10:33:41 -0400 Message-Id: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wa-RFurA-ZhGz9dv0fRVxGPiDvY Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 14:34:09 -0000 --Apple-Mail=_73B9110A-C4B3-4AB1-98FD-227211F72BA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 24, 2014, at 10:25 AM, John Bradley wrote: > I am not against discussion in the WG. >=20 > I happen to agree with Phil's fundamental premise that some developers = are using OAuth in a insecure way to do authentication. >=20 > That raises the question of how to best educate them, and or address = technical barriers. >=20 > It is on the second point that people's opinions seem to divide. >=20 > Some people thing that if we have a OAuth flow that eliminates the = access token (primarily to avoid asking for consent as I understand it) = and just return a id_token from the token endpoint that can be done in a = spec short enough to het people to read. The subtext of this is that = the Connect specification is too large that it scare people, and they = don't find the spec in the first place because it is not a RFC. >=20 > An other common possession is that if you don't want to prompt the = user for consent then don't ask for scopes. Twisting the OAuth spec to = not return an access token is not OAuth, yes you could use a different = endpoint rather than the token endpoint, but that is not OAuth. = Connect was careful not to break the OAuth spec. As long as you are = willing to take a access token with no scopes (the client needs to = understand that there are no attributes one way or another anyway or it = will break) then you don't need to change OAuth. You can publish a = profile of connect that satisfies the use case. >=20 > I think Mike has largely done that but it might be better being less = stingy on references back to the larger spec. >=20 > The questions are do we modify OAuth to not return an access token, = and if so how, and if we do is it still OAuth. >=20 > The other largely separable question is do we create confusion in the = market and slow the the adoption of identity federation on top of OAuth, = or find a way to make this look like a positive alignment of interests = around a subset of Connect. >=20 > There are a number of options. =20 > 1: We can do a profile in the OIDF and publish it as a IETF document. = Perhaps the cleanest from an IPR point of view. > 2:We can do a profile in the OAuth WG referencing connect. > 3:We can do a AD sponsored profile that is not in the OAuth WG. > 4:We can do a small spec in OAuth to add response_type to the token = endpoint. in combination with 1, 2, or 3 >=20 > I agree that stoping developers doing insecure things needs to be = addressed somehow. =20 > I am not personally convinced that Oauth without access tokens is = sensible. >=20 > Looking forward to the meeting:) >=20 > John B. > On Jul 24, 2014, at 6:52 AM, Brian Campbell = wrote: >=20 >> I'd note that the reaction at the conference to Ian's statement was = overwhelmingly positive. There was a wide range of industry people here = - implementers, practitioners, deployers, strategists, etc. - and it = seems pretty clear that the "rough consensus" of the industry at large = is that a4c is not wanted or needed. >>=20 >>=20 >> On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura = wrote: >> And here is a quote from Ian's blog.=20 >>=20 >> And although the authentication wheel is round, that doesn=E2=80=99t = mean it isn=E2=80=99t without its lumps. First, we do see some = reinventing the wheel just to reinvent the wheel. OAuth A4C is simply = not a fruitful activity and should be put down. =20 >> =20 >> (Source) = http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musing= s-on-identity-standards-part-1.html >>=20 >>=20 >> 2014-07-23 16:53 GMT-04:00 John Bradley : >>=20 >> I thought I did post this to the list.=20 >>=20 >> I guess I hit the wrong reply on my phone.=20 >> =20 >> John B.=20 >> Sent from my iPhone >>=20 >> On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: >>=20 >>> we are two, at least :-) >>>=20 >>> Why didn't you post this on the list? >>>=20 >>> When will be be arriving? >>>=20 >>> Am 23.07.2014 16:39, schrieb John Bradley: >>>=20 >>>> Ian Glazer mentioned this in his keynote at CIS yesterday.=20 >>>> =20 >>>> His advice was please stop, we are creating confusion and = uncertainty.=20 >>>> =20 >>>> We are becoming our own wort enemy. ( my view though Ian may share = it) >>>> =20 >>>> Returning just an id_ token from the token endpoint has little real = value.=20 >>>> =20 >>>> Something really useful to do would be sorting out channel_id so we = can do PoP for id tokens to make them and other cookies secure in the = front channel. I think that is a better use of time.=20 >>>> =20 >>>> I may be in the minority opinion on that, it won't be the first = time. =20 >>>>=20 >>>>=20 >>>> John B.=20 >>>> Sent from my iPhone >>>>=20 >>>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt = wrote: >>>>=20 >>>>> You are right from a theoretical perspective. Practically this was = caused by editorial decisions during the creation of the RFC. As far as = I remember, there was a definition of the (one) token endpoint response = in early versions. No one every considered to NOT respond with an access = token from the token endpoint. So one might call it an implicit = assumption. >>>>> =20 >>>>> I'm worried that people get totally confused if an exception is = introduced now given the broad adoption of OAuth based on this = assumption. >>>>> =20 >>>>> regards, >>>>> Torsten. >>>>>=20 >>>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer : >>>>>=20 >>>>>> Is it said anywhere that ALL grant types MUST use Section 5.1 = responses? Each grant type references Section 5.1, and "access token = request" is only defined in the context of the defined grant types. = Section 2.2 doesn't talk about the request or response format. >>>>>>=20 >>>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" a = =C3=A9crit : >>>>>> Is it? Apart from the implicit grant that does not use token = endpoint, all other grant references section 5.1 for the response, i.e., = all shares the same response.=20 >>>>>>=20 >>>>>>=20 >>>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer : >>>>>> I hadn't realized the JSON response that requires the = access_token field is defined per grant_type, so I'd be OK to "extend = the semantics" as in the current draft. >>>>>> That was actually my main concern: that the token endpoint = mandates access_token; but its actually not the case. >>>>>>=20 >>>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" a = =C3=A9crit : >>>>>>=20 >>>>>> I agree with John that overloading response_type @ authz endpoint = is a bad idea. It completely changes the semantics of this parameter. = NOTE: what I was proposing was not this parameter, but a new parameter = response_type @ token endpoint.=20 >>>>>> =20 >>>>>> I also think overloading grant_type is a bad idea since it = changes its semantics. I quote the definition here again:=20 >>>>>> =20 >>>>>> grant=20 >>>>>> credential representing the resource owner's authorization >>>>>> =20 >>>>>> grant_type >>>>>> type of grant sent to the token endpoint to obtain the access = token >>>>>> =20 >>>>>> It is not about controlling what is to be returned from the token = endpoint, but the hint to the token endpoint describing the type of = credential the endpoint has received. It seems the "control of what is = being returned from token endpoint" is just a side effect.=20 >>>>>> =20 >>>>>> I am somewhat ambivalent[1] in changing the semantics of token = endpoint, but in as much as "text is the king" for a spec., we probably = should not change the semantics of it as Torsten points out. If it is ok = to change this semantics, I believe defining a new parameter to this = endpoint to control the response would be the best way to go. This is = what I have described previously.=20 >>>>>> =20 >>>>>> Defining a new endpoint to send code to get ID Token and = forbidding the use of it against token endpoint would not change the = semantics of any existing parameter or endpoint, which is good. However, = I doubt if it is not worth doing. What's the point of avoiding access = token scoped to UserInfo endpoint after all? Defining a new endpoint for = just avoiding the access token for userinfo endpoint seems way too much = the heavy wait way and it breaks interoperabiliy: it defeats the purpose = of standardization.=20 >>>>>> =20 >>>>>> I have started feeling that no change is the best way out.=20 >>>>>> =20 >>>>>> Nat >>>>>> =20 >>>>>> [1] If instead of saying "Token endpoint - used by the client to = exchange an authorization grant for an access token, typically with = client authentication", it were saying "Token endpoint - used by the = client to exchange an authorization grant for tokens, typically with = client authentication", then it would have been OK. It is an expansion = of the capability rather than changing the semantics. >>>>>> =20 >>>>>>=20 >>>>>>=20 >>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones = : >>>>>> You need the alternative response_type value ("code_for_id_token" = in the A4C draft) to tell the Authorization Server to return a code to = be used with the new grant type, rather than one to use with the = "authorization_code" grant type (which is what response_type=3Dcode = does). >>>>>>=20 >>>>>> =20 >>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John = Bradley >>>>>> Sent: Wednesday, July 23, 2014 10:33 AM >>>>>> To: torsten@lodderstedt.net >>>>>>=20 >>>>>>=20 >>>>>> Cc: oauth@ietf.org >>>>>> Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt >>>>>> =20 >>>>>> =20 >>>>>> If we use the token endpoint then a new grant_type is the best = way.=20 >>>>>>=20 >>>>>> =20 >>>>>> It sort of overloads code, but that is better than messing with = response_type for the authorization endpoint to change the response from = the token_endpoint. That is in my opinion a champion bad idea.=20 >>>>>>=20 >>>>>> =20 >>>>>> In discussions developing Connect we decided not to open this can = of worms because no good would come of it. =20 >>>>>>=20 >>>>>> =20 >>>>>> The token_endpoint returns a access token. Nothing requires = scope to be associates with the token.=20 >>>>>>=20 >>>>>> =20 >>>>>> That is the best solution. No change required. Better = interoperability in my opinion.=20 >>>>>>=20 >>>>>> =20 >>>>>> Still on my way to TO, getting in later today.=20 >>>>>>=20 >>>>>> =20 >>>>>> John B.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>>=20 >>>>>> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >>>>>>=20 >>>>>> The "response type" of the token endpoint is controlled by the = value of the parameter "grant_type". So there is no need to introduce a = new parameter. >>>>>>=20 >>>>>> wrt to a potential "no_access_token" grant type. I do not = consider this a good idea as it changes the semantics of the token = endpoint (as already pointed out by Thomas). This endpoint ALWAYS = responds with an access token to any grant type. I therefore would = prefer to use another endpoint for the intended purpose. >>>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>>=20 >>>>>> =20 >>>>>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>>>>>=20 >>>>>> IMHO, changing the semantics of "response_type" @ authz endpoint = this way is not a good thing.=20 >>>>>>=20 >>>>>> =20 >>>>>> Instead, defining a new parameter "response_type" @ token = endpoint, as I described in my previous message,=20 >>>>>>=20 >>>>>> probably is better. At least, it does not change the semantics of = the parameters of RFC6749.=20 >>>>>>=20 >>>>>> =20 >>>>>> Nat=20 >>>>>>=20 >>>>>> =20 >>>>>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >>>>>>=20 >>>>>> No, I mean response_type=3Dnone and response_type=3Did_token = don't generate a code or access token so you don't use the Token = Endpoint (which is not the same as the Authentication Endpoint BTW). >>>>>>=20 >>>>>> With response_type=3Dcode_for_id_token, you get a code and = exchange it for an id_token only, rather than an access_token, so you're = changing the semantics of the Token Endpoint. >>>>>>=20 >>>>>> =20 >>>>>> I'm not saying it's a bad thing, just that you can't really = compare none and id_token with code_for_id_token. >>>>>>=20 >>>>>> =20 >>>>>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. = wrote: >>>>>>=20 >>>>>> It's only "not using the token endpoint" because the token = endpoint copy-pasted and renamed the authentication endpoint. >>>>>>=20 >>>>>> =20 >>>>>> -- Justin >>>>>>=20 >>>>>> =20 >>>>>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer = wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Except that these are about not using the Token Endpoint at all, = whereas the current proposal is about the Token Endpoint not returning = an access_token field in the JSON. >>>>>>=20 >>>>>> =20 >>>>>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones = wrote: >>>>>>=20 >>>>>> The response_type "none" is already used in practice, which = returns no access token. It was accepted by the designated experts and = registered in the IANA OAuth Authorization Endpoint Response Types = registry at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endp= oint. The registered "id_token" response type also returns no access = token. >>>>>>=20 >>>>>> =20 >>>>>> So I think the question of whether response types that result in = no access token being returned are acceptable within OAuth 2.0 is = already settled, as a practical matter. Lots of OAuth implementations = are already using such response types. >>>>>>=20 >>>>>> =20 >>>>>> -- = Mike >>>>>>=20 >>>>>> =20 >>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil = Hunt >>>>>> Sent: Wednesday, July 23, 2014 7:09 AM >>>>>> To: Nat Sakimura >>>>>> Cc: >>>>>> Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt >>>>>>=20 >>>>>> =20 >>>>>> Yes. This is why it has to be discussed in the IETF. >>>>>>=20 >>>>>> =20 >>>>>> Phil >>>>>>=20 >>>>>> =20 >>>>>> @independentid >>>>>>=20 >>>>>> www.independentid.com >>>>>>=20 >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura = wrote: >>>>>>=20 >>>>>> =20 >>>>>> Reading back the RFC6749, I am not sure if there is a good way of = suppressing access token from the response and still be OAuth. It will = break whole bunch of implicit definitions like:=20 >>>>>>=20 >>>>>> =20 >>>>>> authorization server >>>>>> The server issuing access tokens to the client after = successfully >>>>>> authenticating the resource owner and obtaining = authorization. >>>>>>=20 >>>>>> =20 >>>>>> After all, OAuth is all about issuing access tokens.=20 >>>>>>=20 >>>>>> =20 >>>>>> Also, I take back my statement on the grant type in my previous = mail.=20 >>>>>>=20 >>>>>> =20 >>>>>> The definition of grant and grant_type are respectively:=20 >>>>>>=20 >>>>>> =20 >>>>>> grant=20 >>>>>>=20 >>>>>> credential representing the resource owner's authorization >>>>>>=20 >>>>>> =20 >>>>>> grant_type >>>>>>=20 >>>>>> (string representing the) type of grant sent to the token = endpoint to obtain the access token >>>>>>=20 >>>>>> =20 >>>>>> Thus, the grant sent to the token endpoint in this case is still = 'code'.=20 >>>>>>=20 >>>>>> =20 >>>>>> Response type on the other hand is not so well defined in = RFC6749, but it seems it is representing what is to be returned from the = authorization endpoint. To express what is to be returned from token = endpoint, perhaps defining a new parameter to the token endpoint, which = is a parallel to the response_type to the Authorization Endpoint seems = to be a more symmetric way, though I am not sure at all if that is going = to be OAuth any more. One straw-man is to define a new parameter called = response_type to the token endpoint such as:=20 >>>>>>=20 >>>>>> =20 >>>>>> response_type >>>>>>=20 >>>>>> OPTIONAL. A string representing what is to be returned from = the token endpoint.=20 >>>>>>=20 >>>>>> =20 >>>>>> Then define the behavior of the endpoint according to the values = as the parallel to the multi-response type spec.=20 >>>>>>=20 >>>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>>>=20 >>>>>> =20 >>>>>> Nat >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>>>>>=20 >>>>>> The draft is very clear.=20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>>=20 >>>>>> On Jul 23, 2014, at 0:46, Nat Sakimura = wrote: >>>>>>=20 >>>>>> The new grant type that I was talking about was=20 >>>>>>=20 >>>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", = so to speak.=20 >>>>>>=20 >>>>>> It does not return anything per se, but an extension can define = something on top of it.=20 >>>>>>=20 >>>>>> =20 >>>>>> Then, OIDC can define a binding to it so that the binding only = returns ID Token.=20 >>>>>>=20 >>>>>> This binding work should be done in OIDF. Should there be such a = grant type,=20 >>>>>>=20 >>>>>> it will be an extremely short spec.=20 >>>>>>=20 >>>>>> =20 >>>>>> At the same time, if any other specification wanted to define=20 >>>>>>=20 >>>>>> other type of tokens and have it returned from the token = endpoint,=20 >>>>>>=20 >>>>>> it can also use this grant type.=20 >>>>>>=20 >>>>>> =20 >>>>>> If what you want is to define a new grant type that returns ID = Token only,=20 >>>>>>=20 >>>>>> then, I am with Justin. Since "other response than ID Token" is = only=20 >>>>>>=20 >>>>>> theoretical, this is a more plausible way forward, I suppose.=20 >>>>>>=20 >>>>>> =20 >>>>>> Nat >>>>>>=20 >>>>>> =20 >>>>>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>>>>>=20 >>>>>> So the draft would literally turn into: >>>>>>=20 >>>>>> "The a4c response type and grant type return an id_token from the = token endpoint with no access token. All parameters and values are = defined in OIDC." >>>>>>=20 >>>>>> Seems like the perfect mini extension draft for OIDF to do. >>>>>>=20 >>>>>> --Justin >>>>>>=20 >>>>>> /sent from my phone/ >>>>>>=20 >>>>>>=20 >>>>>> On Jul 22, 2014 10:29 AM, Nat Sakimura = wrote: >>>>>> > >>>>>> > What about just defining a new grant type in this WG? >>>>>> > >>>>>> > >>>>>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>>>>> >> >>>>>> >> That would be nice. However oidc still needs the new grant = type in order to implement the same flow.=20 >>>>>> >> >>>>>> >> Phil >>>>>> >> >>>>>> >> On Jul 22, 2014, at 11:35, Nat Sakimura = wrote: >>>>>> >> >>>>>> >>> +1 to Justin.=20 >>>>>> >>> >>>>>> >>> >>>>>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. = : >>>>>> >>>> >>>>>> >>>> Errors like these make it clear to me that it would make = much more sense to develop this document in the OpenID Foundation. It = should be something that directly references OpenID Connect Core for all = of these terms instead of redefining them. It's doing authentication, = which is fundamentally what OpenID Connect does on top of OAuth, and I = don't see a good argument for doing this work in this working group. >>>>>> >>>> >>>>>> >>>> -- Justin >>>>>> >>>> >>>>>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer = wrote: >>>>>> >>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones = wrote: >>>>>> >>>>>> >>>>>> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" = definition being missing is an editorial error. It should be: >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>>> >>>>>> >>>>>> consent >>>>>> >>>>>> >>>>>> >>>>>> The Authorization Server SHOULD prompt the End-User for = consent before returning information to the Client. If it cannot obtain = consent, it MUST return an error, typically consent_required. >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>>> >>>>>> >>>>>> I'll plan to add it in the next draft. >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> It looks like the consent_required error needs to be = defined too, and you might have forgotten to also import = account_selection_required from OpenID Connect. >>>>>> >>>>> =20 >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>>> >>>>>> >>>>>> I agree that there's no difference between a response with = multiple "amr" values that includes "mfa" and one that doesn't. Unless = a clear use case for why "mfa" is needed can be identified, we can = delete it in the next draft. >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> Thanks. >>>>>> >>>>> >>>>>> >>>>> How about "pwd" then? I fully understand that I should = return "pwd" if the user authenticated using a password, but what "the = service if a client secret is used" means in the definition for the = "pwd" value? >>>>>> >>>>> >>>>>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you = come back ;-) ) >>>>>> >>>>> >>>>>> >>>>> -- >>>>>> >>>>> Thomas Broyer >>>>>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>> >>>>> _______________________________________________ >>>>>> >>>>> 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 >>>>>> >>>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> -- >>>>>> >>> Nat Sakimura (=3Dnat) >>>>>> >>> Chairman, OpenID Foundation >>>>>> >>> http://nat.sakimura.org/ >>>>>> >>> @_nat_en >>>>>> >>> >>>>>> >>> _______________________________________________ >>>>>> >>> OAuth mailing list >>>>>> >>> OAuth@ietf.org >>>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Nat Sakimura (=3Dnat) >>>>>> > Chairman, OpenID Foundation >>>>>> > http://nat.sakimura.org/ >>>>>> > @_nat_en >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>> Nat Sakimura (=3Dnat) >>>>>>=20 >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>> Nat Sakimura (=3Dnat) >>>>>>=20 >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>> Thomas Broyer >>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>> Thomas Broyer >>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>> Nat Sakimura (=3Dnat) >>>>>>=20 >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>>=20 >>>>>> =20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> =20 >>>>>> =20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>> Nat Sakimura (=3Dnat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>> Nat Sakimura (=3Dnat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> =20 >>> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_73B9110A-C4B3-4AB1-98FD-227211F72BA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1


On Jul 24, 2014, at 10:25 AM, John Bradley = <ve7jtb@ve7jtb.com> = wrote:

I am not against = discussion in the WG.

I happen to agree with Phil's = fundamental premise that some developers are using OAuth in a insecure = way to do authentication.

That raises the = question of how to best educate them, and or address technical = barriers.

It is on the second point that = people's opinions seem to divide.

Some people = thing that if we have a OAuth flow that eliminates the access token = (primarily to avoid asking for consent as I understand it) and just = return a id_token from the token endpoint that can be done in a spec = short enough to het people to read.   The subtext of this is that = the Connect specification is too large that it scare people,  and = they don't find the spec in the first place because it is not a = RFC.

An other common possession is that if you = don't want to prompt the user for consent then don't ask for scopes. =  Twisting the OAuth spec to not return an access token is not = OAuth,  yes you could use a different endpoint rather than the = token endpoint, but that is not OAuth.   Connect was careful not to = break the OAuth spec.    As long as you are willing to take a = access token with no scopes (the client needs to understand that there = are no attributes one way or another anyway or it will break) then you = don't need to change OAuth.   You can publish a profile of connect = that satisfies the use case.

I think Mike has = largely done that but it might be better being less stingy on references = back to the larger spec.

The questions are do = we modify OAuth to not return an access token, and if so how,  and = if we do is it still OAuth.

The other largely = separable question is do we create confusion in the market and slow the = the adoption of identity federation on top of OAuth, or find a way to = make this look like a positive alignment of interests around a subset of = Connect.

There are a number of options. =  
1: We can do a profile in the OIDF and publish it as a = IETF document.   Perhaps the cleanest from an IPR point of = view.
2:We can do a profile in the OAuth WG referencing = connect.
3:We can do a AD sponsored profile that is not in the = OAuth WG.
4:We can do a small spec in OAuth to add = response_type to the token endpoint.  in combination with 1, 2, or = 3

I agree that stoping developers doing = insecure things needs to be addressed somehow.  
I am not = personally convinced that Oauth without access tokens is = sensible.

Looking forward to the = meeting:)

John B.
On Jul 24, = 2014, at 6:52 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

I'd note that the reaction at the = conference to Ian's statement was overwhelmingly positive. There was a = wide range of industry people here - implementers, practitioners, = deployers, strategists, etc. - and it seems pretty clear that the "rough = consensus" of the industry at large is that a4c is not wanted or = needed.


On = Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
And = here is a quote from Ian's blog. 

And although the authentication wheel is round, that doesn=E2=80=99t = mean it isn=E2=80=99t without its lumps. First, we do see some = reinventing the wheel just to reinvent the wheel. OAuth A4C is simply = not a fruitful activity and should be put down.  
 
(Source) http://www.tuesdaynight.org/2014/07/23/do-we-have-a-roun= d-wheel-yet-musings-on-identity-standards-part-1.html


2014-07-23 16:53 GMT-04:00 John Bradley <ve7jtb@ve7jtb.com>:
=
I thought I did post this to the = list. 

I guess I hit the wrong reply on my = phone. 
 
John B. 
Sent from my = iPhone

On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote:

we are two, at least = :-)

Why didn't you post this on the list?

When will be be = arriving?

Am 23.07.2014 16:39, schrieb John Bradley:

Ian Glazer mentioned this in his keynote at CIS = yesterday. 
 
His advice was please stop,  we are creating confusion and = uncertainty. 
 
We are becoming our own wort enemy. ( my view though Ian may share = it)
 
Returning just an id_ token from the token endpoint has little real = value. 
 
Something really useful to do would be sorting out channel_id so we = can do PoP for id tokens to make them and other cookies secure in the = front channel.   I think that is a better use of time. 
 
I may be in the minority opinion on that,  it won't be the = first time.  


John B. 
Sent from my = iPhone

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

You are right from a theoretical perspective. Practically this was = caused by editorial decisions during the creation of the RFC. As far as = I remember, there was a definition of the (one) token endpoint response = in early versions. No one every considered to NOT respond with an access = token from the token endpoint. So one might call it an implicit = assumption.
 
I'm worried that people get totally confused if an exception is = introduced now given the broad adoption of OAuth based on this = assumption.
 
regards,
Torsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

Is it said anywhere that ALL grant types MUST use = Section 5.1 responses? Each grant type references Section 5.1, and = "access token request" is only defined in the context of the defined = grant types. Section 2.2 doesn't talk about the request or response = format.

Le 23 juil. 2014 21:32, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit :
Is it? Apart from the implicit grant that does not use = token endpoint, all other grant references section 5.1 for the response, = i.e., all shares the same response. 


2014-07-23 15:18 GMT-04:00 Thomas Broyer = <t.broyer@gmail.com>:

I = hadn't realized the JSON response that requires the access_token field = is defined per grant_type, so I'd be OK to "extend the semantics" as in = the current draft.
That was actually my main concern: that the token = endpoint mandates access_token; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit :

I agree with John that overloading response_type @ authz endpoint = is a bad idea. It completely changes the semantics of this parameter. = NOTE: what I was proposing was not this parameter, but a new parameter = response_type @ token endpoint. 
 
I also think overloading grant_type is a bad idea since it changes = its semantics. I quote the definition here again: 
 
grant 
    credential representing the resource owner's = authorization
 
grant_type
type of grant sent to = the token endpoint to obtain the access token
 
It is not about controlling what is to be returned from the token = endpoint, but the hint to the token endpoint describing the type of = credential the endpoint has received. It seems the "control of what is = being returned from token endpoint"  is just a side = effect. 
 
I am somewhat ambivalent[1] in changing the semantics of token = endpoint, but in as much as "text is the king" for a spec., we probably = should not change the semantics of it as Torsten points out. If it is ok = to change this semantics, I believe defining a new parameter to this = endpoint to control the response would be the best way to go. This is = what I have described previously. 
 
Defining a new endpoint to send code to get ID Token and forbidding = the use of it against token endpoint would not change the semantics of = any existing parameter or endpoint, which is good. However, I doubt if = it is not worth doing. What's the point of avoiding access token scoped = to UserInfo endpoint after all? Defining a new endpoint for just = avoiding the access token for userinfo endpoint seems way too much the = heavy wait way and it breaks interoperabiliy: it defeats the purpose of = standardization. 
 
I have started feeling that no change is the best way = out. 
 
Nat
 
[1]  If instead of saying "Token endpoint - used by the client to exchange an = authorization grant for an access token, typically with = client authentication", it were saying "Token endpoint - used by the client to exchange an = authorization grant for tokens, typically with client = authentication", then it would have been OK. It is an expansion of the = capability rather than changing the semantics.
 


2014-07-23 13:39 GMT-04:00 Mike Jones = <Michael.Jones@microsoft.com>:

You need the alternative response_type value = ("code_for_id_token" in the A4C draft) to tell the Authorization Server to return a code = to be used with the new grant type, rather than one to use with the = "authorization_code" grant type (which is what response_type=3Dcode = does).

 

From:<= /strong> OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of = John Bradley
Sent: Wednesday, July 23, 2014 10:33 = AM
To: torsten@lodderstedt.net


Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt
 
 

If we use the token endpoint then a new = grant_type is the best way. 

 

It sort of overloads code, but that is = better than messing with response_type for the authorization endpoint to = change the response from the token_endpoint.  That is in my opinion = a champion bad idea. 

 

In discussions developing Connect we decided = not to open this can of worms because no good would come of it. =   

 

The token_endpoint returns a access token. =  Nothing requires scope to be associates with the token. 

 

That is the best solution.  No change = required.  Better interoperability in my opinion. 

 

Still on my way to TO, getting in later = today. 

 

John B. 

 



Sent from my iPhone


On Jul = 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the = value of the parameter "grant_type". So there is no need to introduce a = new parameter.

wrt to a potential = "no_access_token" grant type. I do not consider this a good idea as it = changes the semantics of the token endpoint (as already pointed out by = Thomas). This endpoint ALWAYS responds with an access token to any grant = type. I therefore would prefer to use another endpoint for the intended = purpose.

regards,
= Torsten.

 

Am 23.07.2014 13:04, schrieb = Nat Sakimura:

IMHO, changing the semantics of = "response_type" @ authz endpoint this way is not a good = thing. 

 

Instead, defining a new parameter = "response_type" @ token endpoint, as I described in my previous = message, 

probably is better. At least, it does not = change the semantics of the parameters of RFC6749. 

 

 Nat 

 

2014-07-23 12:48 GMT-04:00 Thomas Broyer = <t.broyer@gmail.com>:

No, I mean response_type=3Dnone and = response_type=3Did_token don't generate a code or access token so you = don't use the Token Endpoint (which is not the same as the = Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you = get a code and exchange it for an id_token only, rather than an = access_token, so you're changing the semantics of the Token = Endpoint.

 

I'm not saying it's a bad thing, just that = you can't really compare none and id_token with code_for_id_token.

 

On Wed, Jul 23, 2014 at 6:45 PM, Richer, = Justin P. <jricher@mitre.org> wrote:

It's only "not using the token endpoint" = because the token endpoint copy-pasted and renamed the authentication = endpoint.

 

 -- Justin

 

On Jul 23, 2014, at 9:30 AM, Thomas Broyer = <t.broyer@gmail.com> wrote:



Except that these are about not using the = Token Endpoint at all, whereas the current proposal is about the Token = Endpoint not returning an access_token field in the JSON.

 

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

The response_type "none" is already used in practice, which returns no = access token.  It was accepted by the designated experts and = registered in the IANA OAuth Authorization Endpoint Response Types = registry at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endp= oint.  The registered "id_token" response type also returns no = access token.

 

So I think the question of whether response types that result in no = access token being returned are acceptable within OAuth 2.0 is already = settled, as a practical matter.  Lots of OAuth implementations are = already using such response types.

 

            =             &n= bsp;           &nbs= p;            =            -- = Mike

 

From:<= /strong> OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of = Phil Hunt
Sent: = Wednesday, July 23, 2014 7:09 AM
To: Nat = Sakimura
Cc: <oauth@ietf.org>
Subject: Re: = [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt

 

Yes. = This is why it has to be discussed in the IETF.

 

Phil=

 

@independen= tid

phil.hunt@oracle.com

 
 
 

On Jul 23, 2014, at 9:43 AM, Nat Sakimura = <sakimura@gmail.com> wrote:

 

Reading back the RFC6749, I am not sure if = there is a good way of suppressing access token from the response and = still be OAuth. It will break whole bunch of implicit definitions = like: 

 

authorization server
    =   The server issuing access tokens to the client after = successfully
      authenticating the resource owner = and obtaining authorization.

 

After all, OAuth is all about issuing access = tokens. 

 

Also, I take back my statement on the grant = type in my previous mail. 

 

The definition of grant and grant_type are = respectively: 

 

grant 

    credential representing the = resource owner's authorization

=
          &nbs= p;

grant_type

    (string representing the) = type of grant sent to the token endpoint to obtain the access token

 

Thus, the grant sent to the token endpoint = in this case is still 'code'. 

 

Response type on the other hand is not so = well defined in RFC6749, but it seems it is representing what is to be = returned from the authorization endpoint. To express what is to be = returned from token endpoint, perhaps defining a new parameter to the = token endpoint, which is a parallel to the response_type to the = Authorization Endpoint seems to be a more symmetric way, though I am not = sure at all if that is going to be OAuth any more. One straw-man is to = define a new parameter called response_type to the token endpoint such = as: 

 

response_type

    OPTIONAL. A string = representing what is to be returned from the token endpoint. 

    

Then define the behavior of the endpoint = according to the values as the parallel to the multi-response type = spec. 

 

Nat

    
 
 
 

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:

The draft is very clear. 

Phil


On Jul = 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about = was 

"authorization_code_but_do_not_return_access_nor_refre= sh_token", so to speak. 

It does not return anything per se, but an = extension can define something on top of it. 

 

Then, OIDC can define a binding to it so = that the binding only returns ID Token. 

This binding work should be done in OIDF. = Should there be such a grant type, 

it will be an extremely short = spec. 

 

At the same time, if any other specification = wanted to define 

other type of tokens and have it returned = from the token endpoint, 

it can also use this grant type. 

 

If what you want is to define a new grant = type that returns ID Token only, 

then, I am with Justin. Since "other = response than ID Token" is only 

theoretical, this is a more plausible way = forward, I suppose. 

 

Nat

 

2014-07-22 14:30 GMT-04:00 Justin Richer = <jricher@mit.edu>:

So = the draft would literally turn into:

"The a4c response type and = grant type return an id_token from the token endpoint with no access = token. All parameters and values are defined in OIDC."

Seems like the perfect mini extension draft for OIDF to do.

= --Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura = <sakimura@gmail.com> wrote:
>
> = What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
= >> That would be nice. However oidc still needs the new grant type = in order to implement the same flow. 
>>
>> Phil
>>
>> On Jul 22, 2014, = at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
= >>> +1 to Justin. 
>>>
>>>
>>> 2014-07-22 9:54 = GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
= >>>> Errors like these make it clear to me that it would = make much more sense to develop this document in the OpenID Foundation. = It should be something that directly references OpenID Connect Core for = all of these terms instead of redefining them. It's doing = authentication, which is fundamentally what OpenID Connect does on top = of OAuth, and I don't see a good argument for doing this work in this = working group.
>>>>
>>>>  -- Justin
= >>>>
>>>> On Jul 22, 2014, at 4:30 AM, = Thomas Broyer <t.broyer@gmail.com> wrote:
>>>>
>>>>>
>>>>>
= >>>>>
>>>>> On Mon, Jul 21, 2014 at = 11:52 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>>>
>>>>>> Thanks for your = review, Thomas.  The "prompt=3Dconsent" definition being missing is = an editorial error.  It should be:
>>>>>>
= >>>>>>  
>>>>>>
>>>>>> consent
= >>>>>>
>>>>>> The Authorization = Server SHOULD prompt the End-User for consent before returning = information to the Client. If it cannot obtain consent, it MUST return = an error, typically consent_required.
>>>>>>
>>>>>>  
= >>>>>>
>>>>>> I'll plan to add = it in the next draft.
>>>>>
= >>>>>
>>>>> It looks like the = consent_required error needs to be defined too, and you might have = forgotten to also import account_selection_required from OpenID = Connect.
>>>>>  
>>>>>>
= >>>>>>  
>>>>>>
= >>>>>> I agree that there's no difference between a = response with multiple "amr" values that includes "mfa" and one that = doesn't.  Unless a clear use case for why "mfa" is needed can be = identified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> = Thanks.
>>>>>
>>>>> How about = "pwd" then? I fully understand that I should return "pwd" if the user = authenticated using a password, but what "the service if a client secret = is used" means in the definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at = IETF-90, I'm ready to wait 'til you come back ;-) )
= >>>>>
>>>>> --
= >>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> = _______________________________________________
>>>>> = 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
= >>>>
>>>
>>>
>>>
= >>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID = Foundation
>>> http://nat.sakimura.org/
>>> = @_nat_en
>>>
>>> _______________________________________________
= >>> OAuth mailing list
>>> OAuth@ietf.org
= >>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura = (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 


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



 

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

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



 

-- =
Thomas = Broyer
/t=C9=94.ma.b=CA=81wa.je/


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 
_______________________________________________
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



 
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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



 
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=
_______________________________________________
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




--
Nat Sakimura (=3Dnat)
Chairman, = OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________
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=_73B9110A-C4B3-4AB1-98FD-227211F72BA3-- From nobody Thu Jul 24 07:50:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ECA1A03D6 for ; Thu, 24 Jul 2014 07:50:14 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIfhuVffqG1f for ; Thu, 24 Jul 2014 07:50:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC1A1A03D0 for ; Thu, 24 Jul 2014 07:50:07 -0700 (PDT) Received: from BN3PR0301CA0074.namprd03.prod.outlook.com (25.160.152.170) by BN1PR03MB249.namprd03.prod.outlook.com (10.255.200.13) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 24 Jul 2014 14:50:04 +0000 Received: from BN1BFFO11FD015.protection.gbl (2a01:111:f400:7c10::1:168) by BN3PR0301CA0074.outlook.office365.com (2a01:111:e400:401e::42) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Thu, 24 Jul 2014 14:50:04 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD015.mail.protection.outlook.com (10.58.144.78) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Thu, 24 Jul 2014 14:50:03 +0000 Received: from TK5EX14MBXC293.redmond.corp.microsoft.com ([169.254.2.111]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0195.002; Thu, 24 Jul 2014 14:49:26 +0000 From: Mike Jones To: Phil Hunt , John Bradley Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpdsD5lLSHJnTREOVCGmqo62AnZutFmeAgABuQQCAACfBgIAABwoAgAAEBVCAACOWAIAABDOAgAAAxwCAAASJAIAAAz+AgAAE4ACAAAEQQIAAEzWAgAAJNoCAAAOsAIAAAq8AgAAGTgCAAA3t0oABBUoAgAAXRgCAAAkXAIAAAmmAgAACQ9A= Date: Thu, 24 Jul 2014 14:49:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADE8ED3@TK5EX14MBXC293.redmond.corp.microsoft.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADE8ED3TK5EX14MBXC293r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(189002)(51704005)(377424004)(199002)(24454002)(377454003)(51444003)(16236675004)(97736001)(20776003)(15202345003)(71186001)(19617315012)(69596002)(84326002)(4396001)(77982001)(16297215004)(50986999)(561944003)(19625215002)(15974865002)(55846006)(77096002)(81342001)(26826002)(81542001)(64706001)(31966008)(84676001)(15975445006)(86612001)(86362001)(46102001)(74662001)(83322001)(19580405001)(19580395003)(76482001)(66066001)(6806004)(44976005)(79102001)(21056001)(15395725005)(74502001)(83072002)(80022001)(93886003)(92566001)(19300405004)(76176999)(54356999)(106116001)(68736004)(92726001)(512874002)(85852003)(551544002)(99396002)(95666004)(107046002)(33656002)(106466001)(85306003)(104016003)(16601075003)(2656002)(87936001)(81156004)(569005); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB249; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 028256169F Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/GunnTO4nAilb4kAWUDiXheoVq2o Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 14:50:15 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADE8ED3TK5EX14MBXC293r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZeKAmXMgYSBwb2ludCBvZiB0ZWNobmljYWwgZGlzY3Vzc2lvbiBmb3IgeW91ciBjb25zaWRl cmF0aW9uIGFib3V0IHRoZSBjdXJyZW50IGNvbnRlbnQgb2YgYTRjIGFuZCBhIHBvc3NpYmxlIHNp bXBsaWZpY2F0aW9uLg0KDQoNCg0KSGF2aW5nIHRob3VnaHQgYWJvdXQgdGhlIHZpZXdzIGV4cHJl c3NlZCBhYm91dCBkZWZpbmluZyB0aGUgbmV3IHJlc3BvbnNlIHR5cGUgYW5kIGdyYW50IHR5cGUg dmFsdWVzLCBJIGNhbWUgdXAgd2l0aCBhIHBvc3NpYmxlIHN5bnRheCBjaGFuZ2UgdGhhdCB3b3Vs ZCBiZSBtdWNoIG1vcmUgbWluaW1hbCBhbmQgYWNjb21wbGlzaCB0aGUgc2FtZSB0aGluZy4gIFJh dGhlciB0aGFuIGRlZmluaW5nIGEgbmV3IHJlc3BvbnNlIHR5cGUgYW5kIGEgbmV3IGdyYW50IHR5 cGUsIGluc3RlYWQsIHdlIGNvdWxkIGp1c3QgdXNlIHRoZSBleGlzdGluZyBjb2RlIGZsb3cgYW5k IHNheSB0aGF0IGl0J3MgbGVnYWwgZm9yIHRoZSB0b2tlbiBlbmRwb2ludCB0byByZXR1cm4gdGhl IHZhbHVlICJhY2Nlc3NfdG9rZW49bm9uZSIuICBUaGF0IHdheSwgdGhlIGRlbHRhIHRvIE9BdXRo IDIuMCBmb3IgdGhlIG5vLWFjY2Vzcy10b2tlbiBjYXNlIHdvdWxkIGJlIHZlcnkgc21hbGwgYW5k IHRoZSBzeW50YXggb2YgdGhlIHJlc3BvbnNlIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IHdvdWxk IGJlIHVuY2hhbmdlZC4NCg0KDQpBbmQgd2hpbGUgcGVvcGxlIG1pZ2h0IGluaXRpYWxseSB0aGlu ayB0aGF0IHNpbmNlIHdl4oCZZCBiZSBkZWZpbmluZyBhIGRpc3Rpbmd1aXNoZWQgYWNjZXNzX3Rv a2VuIHJlc3VsdCB2YWx1ZSB3ZSBtaWdodCBiZSBzdGVwcGluZyBvbiBpbXBsZW1lbnRhdGlvbnMs ICJub25lIiBkb2Vzbid0IG1lZXQgdGhlIG1pbmltdW0gZW50cm9weSByZXF1aXJlbWVudHMgaW4g T0F1dGggMi4wLCBzbyB3b3VsZG4ndCBjb25mbGljdCB3aXRoIGFueSBjb25mb3JtaW5nIGltcGxl bWVudGF0aW9uLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgQmVzdCB3aXNoZXMsDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTog T0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGhpbCBI dW50DQpTZW50OiBUaHVyc2RheSwgSnVseSAyNCwgMjAxNCA3OjM0IEFNDQpUbzogSm9obiBCcmFk bGV5DQpDYzogb2F1dGhAaWV0Zi5vcmcgbGlzdA0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA1 LnR4dA0KDQorMQ0KDQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5j b208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCk9uIEp1bCAyNCwgMjAxNCwgYXQgMTA6 MjUgQU0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdq dGIuY29tPj4gd3JvdGU6DQoNCg0KSSBhbSBub3QgYWdhaW5zdCBkaXNjdXNzaW9uIGluIHRoZSBX Ry4NCg0KSSBoYXBwZW4gdG8gYWdyZWUgd2l0aCBQaGlsJ3MgZnVuZGFtZW50YWwgcHJlbWlzZSB0 aGF0IHNvbWUgZGV2ZWxvcGVycyBhcmUgdXNpbmcgT0F1dGggaW4gYSBpbnNlY3VyZSB3YXkgdG8g ZG8gYXV0aGVudGljYXRpb24uDQoNClRoYXQgcmFpc2VzIHRoZSBxdWVzdGlvbiBvZiBob3cgdG8g YmVzdCBlZHVjYXRlIHRoZW0sIGFuZCBvciBhZGRyZXNzIHRlY2huaWNhbCBiYXJyaWVycy4NCg0K SXQgaXMgb24gdGhlIHNlY29uZCBwb2ludCB0aGF0IHBlb3BsZSdzIG9waW5pb25zIHNlZW0gdG8g ZGl2aWRlLg0KDQpTb21lIHBlb3BsZSB0aGluZyB0aGF0IGlmIHdlIGhhdmUgYSBPQXV0aCBmbG93 IHRoYXQgZWxpbWluYXRlcyB0aGUgYWNjZXNzIHRva2VuIChwcmltYXJpbHkgdG8gYXZvaWQgYXNr aW5nIGZvciBjb25zZW50IGFzIEkgdW5kZXJzdGFuZCBpdCkgYW5kIGp1c3QgcmV0dXJuIGEgaWRf dG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgdGhhdCBjYW4gYmUgZG9uZSBpbiBhIHNwZWMg c2hvcnQgZW5vdWdoIHRvIGhldCBwZW9wbGUgdG8gcmVhZC4gICBUaGUgc3VidGV4dCBvZiB0aGlz IGlzIHRoYXQgdGhlIENvbm5lY3Qgc3BlY2lmaWNhdGlvbiBpcyB0b28gbGFyZ2UgdGhhdCBpdCBz Y2FyZSBwZW9wbGUsICBhbmQgdGhleSBkb24ndCBmaW5kIHRoZSBzcGVjIGluIHRoZSBmaXJzdCBw bGFjZSBiZWNhdXNlIGl0IGlzIG5vdCBhIFJGQy4NCg0KQW4gb3RoZXIgY29tbW9uIHBvc3Nlc3Np b24gaXMgdGhhdCBpZiB5b3UgZG9uJ3Qgd2FudCB0byBwcm9tcHQgdGhlIHVzZXIgZm9yIGNvbnNl bnQgdGhlbiBkb24ndCBhc2sgZm9yIHNjb3Blcy4gIFR3aXN0aW5nIHRoZSBPQXV0aCBzcGVjIHRv IG5vdCByZXR1cm4gYW4gYWNjZXNzIHRva2VuIGlzIG5vdCBPQXV0aCwgIHllcyB5b3UgY291bGQg dXNlIGEgZGlmZmVyZW50IGVuZHBvaW50IHJhdGhlciB0aGFuIHRoZSB0b2tlbiBlbmRwb2ludCwg YnV0IHRoYXQgaXMgbm90IE9BdXRoLiAgIENvbm5lY3Qgd2FzIGNhcmVmdWwgbm90IHRvIGJyZWFr IHRoZSBPQXV0aCBzcGVjLiAgICBBcyBsb25nIGFzIHlvdSBhcmUgd2lsbGluZyB0byB0YWtlIGEg YWNjZXNzIHRva2VuIHdpdGggbm8gc2NvcGVzICh0aGUgY2xpZW50IG5lZWRzIHRvIHVuZGVyc3Rh bmQgdGhhdCB0aGVyZSBhcmUgbm8gYXR0cmlidXRlcyBvbmUgd2F5IG9yIGFub3RoZXIgYW55d2F5 IG9yIGl0IHdpbGwgYnJlYWspIHRoZW4geW91IGRvbid0IG5lZWQgdG8gY2hhbmdlIE9BdXRoLiAg IFlvdSBjYW4gcHVibGlzaCBhIHByb2ZpbGUgb2YgY29ubmVjdCB0aGF0IHNhdGlzZmllcyB0aGUg dXNlIGNhc2UuDQoNCkkgdGhpbmsgTWlrZSBoYXMgbGFyZ2VseSBkb25lIHRoYXQgYnV0IGl0IG1p Z2h0IGJlIGJldHRlciBiZWluZyBsZXNzIHN0aW5neSBvbiByZWZlcmVuY2VzIGJhY2sgdG8gdGhl IGxhcmdlciBzcGVjLg0KDQpUaGUgcXVlc3Rpb25zIGFyZSBkbyB3ZSBtb2RpZnkgT0F1dGggdG8g bm90IHJldHVybiBhbiBhY2Nlc3MgdG9rZW4sIGFuZCBpZiBzbyBob3csICBhbmQgaWYgd2UgZG8g aXMgaXQgc3RpbGwgT0F1dGguDQoNClRoZSBvdGhlciBsYXJnZWx5IHNlcGFyYWJsZSBxdWVzdGlv biBpcyBkbyB3ZSBjcmVhdGUgY29uZnVzaW9uIGluIHRoZSBtYXJrZXQgYW5kIHNsb3cgdGhlIHRo ZSBhZG9wdGlvbiBvZiBpZGVudGl0eSBmZWRlcmF0aW9uIG9uIHRvcCBvZiBPQXV0aCwgb3IgZmlu ZCBhIHdheSB0byBtYWtlIHRoaXMgbG9vayBsaWtlIGEgcG9zaXRpdmUgYWxpZ25tZW50IG9mIGlu dGVyZXN0cyBhcm91bmQgYSBzdWJzZXQgb2YgQ29ubmVjdC4NCg0KVGhlcmUgYXJlIGEgbnVtYmVy IG9mIG9wdGlvbnMuDQoxOiBXZSBjYW4gZG8gYSBwcm9maWxlIGluIHRoZSBPSURGIGFuZCBwdWJs aXNoIGl0IGFzIGEgSUVURiBkb2N1bWVudC4gICBQZXJoYXBzIHRoZSBjbGVhbmVzdCBmcm9tIGFu IElQUiBwb2ludCBvZiB2aWV3Lg0KMjpXZSBjYW4gZG8gYSBwcm9maWxlIGluIHRoZSBPQXV0aCBX RyByZWZlcmVuY2luZyBjb25uZWN0Lg0KMzpXZSBjYW4gZG8gYSBBRCBzcG9uc29yZWQgcHJvZmls ZSB0aGF0IGlzIG5vdCBpbiB0aGUgT0F1dGggV0cuDQo0OldlIGNhbiBkbyBhIHNtYWxsIHNwZWMg aW4gT0F1dGggdG8gYWRkIHJlc3BvbnNlX3R5cGUgdG8gdGhlIHRva2VuIGVuZHBvaW50LiAgaW4g Y29tYmluYXRpb24gd2l0aCAxLCAyLCBvciAzDQoNCkkgYWdyZWUgdGhhdCBzdG9waW5nIGRldmVs b3BlcnMgZG9pbmcgaW5zZWN1cmUgdGhpbmdzIG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBzb21laG93 Lg0KSSBhbSBub3QgcGVyc29uYWxseSBjb252aW5jZWQgdGhhdCBPYXV0aCB3aXRob3V0IGFjY2Vz cyB0b2tlbnMgaXMgc2Vuc2libGUuDQoNCkxvb2tpbmcgZm9yd2FyZCB0byB0aGUgbWVldGluZzop DQoNCkpvaG4gQi4NCk9uIEp1bCAyNCwgMjAxNCwgYXQgNjo1MiBBTSwgQnJpYW4gQ2FtcGJlbGwg PGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbT4+IHdyb3RlOg0KDQoNCkknZCBub3RlIHRoYXQgdGhlIHJlYWN0aW9uIGF0IHRoZSBjb25m ZXJlbmNlIHRvIElhbidzIHN0YXRlbWVudCB3YXMgb3ZlcndoZWxtaW5nbHkgcG9zaXRpdmUuIFRo ZXJlIHdhcyBhIHdpZGUgcmFuZ2Ugb2YgaW5kdXN0cnkgcGVvcGxlIGhlcmUgLSBpbXBsZW1lbnRl cnMsIHByYWN0aXRpb25lcnMsIGRlcGxveWVycywgc3RyYXRlZ2lzdHMsIGV0Yy4gLSBhbmQgaXQg c2VlbXMgcHJldHR5IGNsZWFyIHRoYXQgdGhlICJyb3VnaCBjb25zZW5zdXMiIG9mIHRoZSBpbmR1 c3RyeSBhdCBsYXJnZSBpcyB0aGF0IGE0YyBpcyBub3Qgd2FudGVkIG9yIG5lZWRlZC4NCg0KT24g VGh1LCBKdWwgMjQsIDIwMTQgYXQgNToyOSBBTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFp bC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KQW5kIGhlcmUgaXMgYSBx dW90ZSBmcm9tIElhbidzIGJsb2cuDQoNCkFuZCBhbHRob3VnaCB0aGUgYXV0aGVudGljYXRpb24g d2hlZWwgaXMgcm91bmQsIHRoYXQgZG9lc27igJl0IG1lYW4gaXQgaXNu4oCZdCB3aXRob3V0IGl0 cyBsdW1wcy4gRmlyc3QsIHdlIGRvIHNlZSBzb21lIHJlaW52ZW50aW5nIHRoZSB3aGVlbCBqdXN0 IHRvIHJlaW52ZW50IHRoZSB3aGVlbC4gT0F1dGggQTRDIGlzIHNpbXBseSBub3QgYSBmcnVpdGZ1 bCBhY3Rpdml0eSBhbmQgc2hvdWxkIGJlIHB1dCBkb3duLg0KDQooU291cmNlKSBodHRwOi8vd3d3 LnR1ZXNkYXluaWdodC5vcmcvMjAxNC8wNy8yMy9kby13ZS1oYXZlLWEtcm91bmQtd2hlZWwteWV0 LW11c2luZ3Mtb24taWRlbnRpdHktc3RhbmRhcmRzLXBhcnQtMS5odG1sDQoNCjIwMTQtMDctMjMg MTY6NTMgR01ULTA0OjAwIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZl N2p0YkB2ZTdqdGIuY29tPj46DQoNCkkgdGhvdWdodCBJIGRpZCBwb3N0IHRoaXMgdG8gdGhlIGxp c3QuDQoNCkkgZ3Vlc3MgSSBoaXQgdGhlIHdyb25nIHJlcGx5IG9uIG15IHBob25lLg0KDQpKb2hu IEIuDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIEp1bCAyMywgMjAxNCwgYXQgNDo1MCBQTSwg dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB3 cm90ZToNCg0Kd2UgYXJlIHR3bywgYXQgbGVhc3QgOi0pDQoNCldoeSBkaWRuJ3QgeW91IHBvc3Qg dGhpcyBvbiB0aGUgbGlzdD8NCg0KV2hlbiB3aWxsIGJlIGJlIGFycml2aW5nPw0KDQpBbSAyMy4w Ny4yMDE0IDE2OjM5LCBzY2hyaWViIEpvaG4gQnJhZGxleToNCklhbiBHbGF6ZXIgbWVudGlvbmVk IHRoaXMgaW4gaGlzIGtleW5vdGUgYXQgQ0lTIHllc3RlcmRheS4NCg0KSGlzIGFkdmljZSB3YXMg cGxlYXNlIHN0b3AsICB3ZSBhcmUgY3JlYXRpbmcgY29uZnVzaW9uIGFuZCB1bmNlcnRhaW50eS4N Cg0KV2UgYXJlIGJlY29taW5nIG91ciBvd24gd29ydCBlbmVteS4gKCBteSB2aWV3IHRob3VnaCBJ YW4gbWF5IHNoYXJlIGl0KQ0KDQpSZXR1cm5pbmcganVzdCBhbiBpZF8gdG9rZW4gZnJvbSB0aGUg dG9rZW4gZW5kcG9pbnQgaGFzIGxpdHRsZSByZWFsIHZhbHVlLg0KDQpTb21ldGhpbmcgcmVhbGx5 IHVzZWZ1bCB0byBkbyB3b3VsZCBiZSBzb3J0aW5nIG91dCBjaGFubmVsX2lkIHNvIHdlIGNhbiBk byBQb1AgZm9yIGlkIHRva2VucyB0byBtYWtlIHRoZW0gYW5kIG90aGVyIGNvb2tpZXMgc2VjdXJl IGluIHRoZSBmcm9udCBjaGFubmVsLiAgIEkgdGhpbmsgdGhhdCBpcyBhIGJldHRlciB1c2Ugb2Yg dGltZS4NCg0KSSBtYXkgYmUgaW4gdGhlIG1pbm9yaXR5IG9waW5pb24gb24gdGhhdCwgIGl0IHdv bid0IGJlIHRoZSBmaXJzdCB0aW1lLg0KDQoNCkpvaG4gQi4NClNlbnQgZnJvbSBteSBpUGhvbmUN Cg0KT24gSnVsIDIzLCAyMDE0LCBhdCA0OjA0IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3cm90 ZToNCllvdSBhcmUgcmlnaHQgZnJvbSBhIHRoZW9yZXRpY2FsIHBlcnNwZWN0aXZlLiBQcmFjdGlj YWxseSB0aGlzIHdhcyBjYXVzZWQgYnkgZWRpdG9yaWFsIGRlY2lzaW9ucyBkdXJpbmcgdGhlIGNy ZWF0aW9uIG9mIHRoZSBSRkMuIEFzIGZhciBhcyBJIHJlbWVtYmVyLCB0aGVyZSB3YXMgYSBkZWZp bml0aW9uIG9mIHRoZSAob25lKSB0b2tlbiBlbmRwb2ludCByZXNwb25zZSBpbiBlYXJseSB2ZXJz aW9ucy4gTm8gb25lIGV2ZXJ5IGNvbnNpZGVyZWQgdG8gTk9UIHJlc3BvbmQgd2l0aCBhbiBhY2Nl c3MgdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQuIFNvIG9uZSBtaWdodCBjYWxsIGl0IGFu IGltcGxpY2l0IGFzc3VtcHRpb24uDQoNCkknbSB3b3JyaWVkIHRoYXQgcGVvcGxlIGdldCB0b3Rh bGx5IGNvbmZ1c2VkIGlmIGFuIGV4Y2VwdGlvbiBpcyBpbnRyb2R1Y2VkIG5vdyBnaXZlbiB0aGUg YnJvYWQgYWRvcHRpb24gb2YgT0F1dGggYmFzZWQgb24gdGhpcyBhc3N1bXB0aW9uLg0KDQpyZWdh cmRzLA0KVG9yc3Rlbi4NCg0KQW0gMjMuMDcuMjAxNCB1bSAxNTo0MSBzY2hyaWViIFRob21hcyBC cm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPj46DQoN CklzIGl0IHNhaWQgYW55d2hlcmUgdGhhdCBBTEwgZ3JhbnQgdHlwZXMgTVVTVCB1c2UgU2VjdGlv biA1LjEgcmVzcG9uc2VzPyBFYWNoIGdyYW50IHR5cGUgcmVmZXJlbmNlcyBTZWN0aW9uIDUuMSwg YW5kICJhY2Nlc3MgdG9rZW4gcmVxdWVzdCIgaXMgb25seSBkZWZpbmVkIGluIHRoZSBjb250ZXh0 IG9mIHRoZSBkZWZpbmVkIGdyYW50IHR5cGVzLiBTZWN0aW9uIDIuMiBkb2Vzbid0IHRhbGsgYWJv dXQgdGhlIHJlcXVlc3Qgb3IgcmVzcG9uc2UgZm9ybWF0Lg0KTGUgMjMganVpbC4gMjAxNCAyMToz MiwgIk5hdCBTYWtpbXVyYSIgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21h aWwuY29tPj4gYSDDqWNyaXQgOg0KSXMgaXQ/IEFwYXJ0IGZyb20gdGhlIGltcGxpY2l0IGdyYW50 IHRoYXQgZG9lcyBub3QgdXNlIHRva2VuIGVuZHBvaW50LCBhbGwgb3RoZXIgZ3JhbnQgcmVmZXJl bmNlcyBzZWN0aW9uIDUuMSBmb3IgdGhlIHJlc3BvbnNlLCBpLmUuLCBhbGwgc2hhcmVzIHRoZSBz YW1lIHJlc3BvbnNlLg0KDQoyMDE0LTA3LTIzIDE1OjE4IEdNVC0wNDowMCBUaG9tYXMgQnJveWVy IDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+Og0KDQpJIGhh ZG4ndCByZWFsaXplZCB0aGUgSlNPTiByZXNwb25zZSB0aGF0IHJlcXVpcmVzIHRoZSBhY2Nlc3Nf dG9rZW4gZmllbGQgaXMgZGVmaW5lZCBwZXIgZ3JhbnRfdHlwZSwgc28gSSdkIGJlIE9LIHRvICJl eHRlbmQgdGhlIHNlbWFudGljcyIgYXMgaW4gdGhlIGN1cnJlbnQgZHJhZnQuDQpUaGF0IHdhcyBh Y3R1YWxseSBteSBtYWluIGNvbmNlcm46IHRoYXQgdGhlIHRva2VuIGVuZHBvaW50IG1hbmRhdGVz IGFjY2Vzc190b2tlbjsgYnV0IGl0cyBhY3R1YWxseSBub3QgdGhlIGNhc2UuDQpMZSAyMyBqdWls LiAyMDE0IDIwOjQ2LCAiTmF0IFNha2ltdXJhIiA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpz YWtpbXVyYUBnbWFpbC5jb20+PiBhIMOpY3JpdCA6DQoNCkkgYWdyZWUgd2l0aCBKb2huIHRoYXQg b3ZlcmxvYWRpbmcgcmVzcG9uc2VfdHlwZSBAIGF1dGh6IGVuZHBvaW50IGlzIGEgYmFkIGlkZWEu IEl0IGNvbXBsZXRlbHkgY2hhbmdlcyB0aGUgc2VtYW50aWNzIG9mIHRoaXMgcGFyYW1ldGVyLiBO T1RFOiB3aGF0IEkgd2FzIHByb3Bvc2luZyB3YXMgbm90IHRoaXMgcGFyYW1ldGVyLCBidXQgYSBu ZXcgcGFyYW1ldGVyIHJlc3BvbnNlX3R5cGUgQCB0b2tlbiBlbmRwb2ludC4NCg0KSSBhbHNvIHRo aW5rIG92ZXJsb2FkaW5nIGdyYW50X3R5cGUgaXMgYSBiYWQgaWRlYSBzaW5jZSBpdCBjaGFuZ2Vz IGl0cyBzZW1hbnRpY3MuIEkgcXVvdGUgdGhlIGRlZmluaXRpb24gaGVyZSBhZ2FpbjoNCg0KZ3Jh bnQNCiAgICBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBhdXRo b3JpemF0aW9uDQoNCmdyYW50X3R5cGUNCnR5cGUgb2YgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4g ZW5kcG9pbnQgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW4NCg0KSXQgaXMgbm90IGFib3V0IGNv bnRyb2xsaW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQs IGJ1dCB0aGUgaGludCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgZGVzY3JpYmluZyB0aGUgdHlwZSBv ZiBjcmVkZW50aWFsIHRoZSBlbmRwb2ludCBoYXMgcmVjZWl2ZWQuIEl0IHNlZW1zIHRoZSAiY29u dHJvbCBvZiB3aGF0IGlzIGJlaW5nIHJldHVybmVkIGZyb20gdG9rZW4gZW5kcG9pbnQiICBpcyBq dXN0IGEgc2lkZSBlZmZlY3QuDQoNCkkgYW0gc29tZXdoYXQgYW1iaXZhbGVudFsxXSBpbiBjaGFu Z2luZyB0aGUgc2VtYW50aWNzIG9mIHRva2VuIGVuZHBvaW50LCBidXQgaW4gYXMgbXVjaCBhcyAi dGV4dCBpcyB0aGUga2luZyIgZm9yIGEgc3BlYy4sIHdlIHByb2JhYmx5IHNob3VsZCBub3QgY2hh bmdlIHRoZSBzZW1hbnRpY3Mgb2YgaXQgYXMgVG9yc3RlbiBwb2ludHMgb3V0LiBJZiBpdCBpcyBv ayB0byBjaGFuZ2UgdGhpcyBzZW1hbnRpY3MsIEkgYmVsaWV2ZSBkZWZpbmluZyBhIG5ldyBwYXJh bWV0ZXIgdG8gdGhpcyBlbmRwb2ludCB0byBjb250cm9sIHRoZSByZXNwb25zZSB3b3VsZCBiZSB0 aGUgYmVzdCB3YXkgdG8gZ28uIFRoaXMgaXMgd2hhdCBJIGhhdmUgZGVzY3JpYmVkIHByZXZpb3Vz bHkuDQoNCkRlZmluaW5nIGEgbmV3IGVuZHBvaW50IHRvIHNlbmQgY29kZSB0byBnZXQgSUQgVG9r ZW4gYW5kIGZvcmJpZGRpbmcgdGhlIHVzZSBvZiBpdCBhZ2FpbnN0IHRva2VuIGVuZHBvaW50IHdv dWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBhbnkgZXhpc3RpbmcgcGFyYW1ldGVyIG9y IGVuZHBvaW50LCB3aGljaCBpcyBnb29kLiBIb3dldmVyLCBJIGRvdWJ0IGlmIGl0IGlzIG5vdCB3 b3J0aCBkb2luZy4gV2hhdCdzIHRoZSBwb2ludCBvZiBhdm9pZGluZyBhY2Nlc3MgdG9rZW4gc2Nv cGVkIHRvIFVzZXJJbmZvIGVuZHBvaW50IGFmdGVyIGFsbD8gRGVmaW5pbmcgYSBuZXcgZW5kcG9p bnQgZm9yIGp1c3QgYXZvaWRpbmcgdGhlIGFjY2VzcyB0b2tlbiBmb3IgdXNlcmluZm8gZW5kcG9p bnQgc2VlbXMgd2F5IHRvbyBtdWNoIHRoZSBoZWF2eSB3YWl0IHdheSBhbmQgaXQgYnJlYWtzIGlu dGVyb3BlcmFiaWxpeTogaXQgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBzdGFuZGFyZGl6YXRpb24u DQoNCkkgaGF2ZSBzdGFydGVkIGZlZWxpbmcgdGhhdCBubyBjaGFuZ2UgaXMgdGhlIGJlc3Qgd2F5 IG91dC4NCg0KTmF0DQoNClsxXSAgSWYgaW5zdGVhZCBvZiBzYXlpbmcgIlRva2VuIGVuZHBvaW50 IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQg Zm9yIGFuIGFjY2VzcyB0b2tlbiwgdHlwaWNhbGx5IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0aW9u IiwgaXQgd2VyZSBzYXlpbmcgIlRva2VuIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRv IGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgZm9yIHRva2VucywgdHlwaWNhbGx5IHdp dGggY2xpZW50IGF1dGhlbnRpY2F0aW9uIiwgdGhlbiBpdCB3b3VsZCBoYXZlIGJlZW4gT0suIEl0 IGlzIGFuIGV4cGFuc2lvbiBvZiB0aGUgY2FwYWJpbGl0eSByYXRoZXIgdGhhbiBjaGFuZ2luZyB0 aGUgc2VtYW50aWNzLg0KDQoNCjIwMTQtMDctMjMgMTM6MzkgR01ULTA0OjAwIE1pa2UgSm9uZXMg PE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPj46DQpZb3UgbmVlZCB0aGUgYWx0ZXJuYXRpdmUgcmVzcG9uc2VfdHlwZSB2YWx1ZSAo ImNvZGVfZm9yX2lkX3Rva2VuIiBpbiB0aGUgQTRDIGRyYWZ0KSB0byB0ZWxsIHRoZSBBdXRob3Jp emF0aW9uIFNlcnZlciB0byByZXR1cm4gYSBjb2RlIHRvIGJlIHVzZWQgd2l0aCB0aGUgbmV3IGdy YW50IHR5cGUsIHJhdGhlciB0aGFuIG9uZSB0byB1c2Ugd2l0aCB0aGUgImF1dGhvcml6YXRpb25f Y29kZSIgZ3JhbnQgdHlwZSAod2hpY2ggaXMgd2hhdCByZXNwb25zZV90eXBlPWNvZGUgZG9lcyku DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNClNlbnQ6IFdl ZG5lc2RheSwgSnVseSAyMywgMjAxNCAxMDozMyBBTQ0KVG86IHRvcnN0ZW5AbG9kZGVyc3RlZHQu bmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4NCg0KQ2M6IG9hdXRoQGlldGYub3Jn PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQN Cg0KDQpJZiB3ZSB1c2UgdGhlIHRva2VuIGVuZHBvaW50IHRoZW4gYSBuZXcgZ3JhbnRfdHlwZSBp cyB0aGUgYmVzdCB3YXkuDQoNCkl0IHNvcnQgb2Ygb3ZlcmxvYWRzIGNvZGUsIGJ1dCB0aGF0IGlz IGJldHRlciB0aGFuIG1lc3Npbmcgd2l0aCByZXNwb25zZV90eXBlIGZvciB0aGUgYXV0aG9yaXph dGlvbiBlbmRwb2ludCB0byBjaGFuZ2UgdGhlIHJlc3BvbnNlIGZyb20gdGhlIHRva2VuX2VuZHBv aW50LiAgVGhhdCBpcyBpbiBteSBvcGluaW9uIGEgY2hhbXBpb24gYmFkIGlkZWEuDQoNCkluIGRp c2N1c3Npb25zIGRldmVsb3BpbmcgQ29ubmVjdCB3ZSBkZWNpZGVkIG5vdCB0byBvcGVuIHRoaXMg Y2FuIG9mIHdvcm1zIGJlY2F1c2Ugbm8gZ29vZCB3b3VsZCBjb21lIG9mIGl0Lg0KDQpUaGUgdG9r ZW5fZW5kcG9pbnQgcmV0dXJucyBhIGFjY2VzcyB0b2tlbi4gIE5vdGhpbmcgcmVxdWlyZXMgc2Nv cGUgdG8gYmUgYXNzb2NpYXRlcyB3aXRoIHRoZSB0b2tlbi4NCg0KVGhhdCBpcyB0aGUgYmVzdCBz b2x1dGlvbi4gIE5vIGNoYW5nZSByZXF1aXJlZC4gIEJldHRlciBpbnRlcm9wZXJhYmlsaXR5IGlu IG15IG9waW5pb24uDQoNClN0aWxsIG9uIG15IHdheSB0byBUTywgZ2V0dGluZyBpbiBsYXRlciB0 b2RheS4NCg0KSm9obiBCLg0KDQoNCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiBKdWwgMjMs IDIwMTQsIGF0IDEyOjE1IFBNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KDQpUaGUgInJlc3BvbnNlIHR5cGUiIG9mIHRoZSB0 b2tlbiBlbmRwb2ludCBpcyBjb250cm9sbGVkIGJ5IHRoZSB2YWx1ZSBvZiB0aGUgcGFyYW1ldGVy ICJncmFudF90eXBlIi4gU28gdGhlcmUgaXMgbm8gbmVlZCB0byBpbnRyb2R1Y2UgYSBuZXcgcGFy YW1ldGVyLg0KDQp3cnQgdG8gYSBwb3RlbnRpYWwgIm5vX2FjY2Vzc190b2tlbiIgZ3JhbnQgdHlw ZS4gSSBkbyBub3QgY29uc2lkZXIgdGhpcyBhIGdvb2QgaWRlYSBhcyBpdCBjaGFuZ2VzIHRoZSBz ZW1hbnRpY3Mgb2YgdGhlIHRva2VuIGVuZHBvaW50IChhcyBhbHJlYWR5IHBvaW50ZWQgb3V0IGJ5 IFRob21hcykuIFRoaXMgZW5kcG9pbnQgQUxXQVlTIHJlc3BvbmRzIHdpdGggYW4gYWNjZXNzIHRv a2VuIHRvIGFueSBncmFudCB0eXBlLiBJIHRoZXJlZm9yZSB3b3VsZCBwcmVmZXIgdG8gdXNlIGFu b3RoZXIgZW5kcG9pbnQgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlLg0KDQpyZWdhcmRzLA0KVG9y c3Rlbi4NCg0KDQpBbSAyMy4wNy4yMDE0IDEzOjA0LCBzY2hyaWViIE5hdCBTYWtpbXVyYToNCklN SE8sIGNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgInJlc3BvbnNlX3R5cGUiIEAgYXV0aHogZW5k cG9pbnQgdGhpcyB3YXkgaXMgbm90IGEgZ29vZCB0aGluZy4NCg0KSW5zdGVhZCwgZGVmaW5pbmcg YSBuZXcgcGFyYW1ldGVyICJyZXNwb25zZV90eXBlIiBAIHRva2VuIGVuZHBvaW50LCBhcyBJIGRl c2NyaWJlZCBpbiBteSBwcmV2aW91cyBtZXNzYWdlLA0KcHJvYmFibHkgaXMgYmV0dGVyLiBBdCBs ZWFzdCwgaXQgZG9lcyBub3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHBhcmFtZXRlcnMg b2YgUkZDNjc0OS4NCg0KIE5hdA0KDQoyMDE0LTA3LTIzIDEyOjQ4IEdNVC0wNDowMCBUaG9tYXMg QnJveWVyIDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+Og0K Tm8sIEkgbWVhbiByZXNwb25zZV90eXBlPW5vbmUgYW5kIHJlc3BvbnNlX3R5cGU9aWRfdG9rZW4g ZG9uJ3QgZ2VuZXJhdGUgYSBjb2RlIG9yIGFjY2VzcyB0b2tlbiBzbyB5b3UgZG9uJ3QgdXNlIHRo ZSBUb2tlbiBFbmRwb2ludCAod2hpY2ggaXMgbm90IHRoZSBzYW1lIGFzIHRoZSBBdXRoZW50aWNh dGlvbiBFbmRwb2ludCBCVFcpLg0KV2l0aCByZXNwb25zZV90eXBlPWNvZGVfZm9yX2lkX3Rva2Vu LCB5b3UgZ2V0IGEgY29kZSBhbmQgZXhjaGFuZ2UgaXQgZm9yIGFuIGlkX3Rva2VuIG9ubHksIHJh dGhlciB0aGFuIGFuIGFjY2Vzc190b2tlbiwgc28geW91J3JlIGNoYW5naW5nIHRoZSBzZW1hbnRp Y3Mgb2YgdGhlIFRva2VuIEVuZHBvaW50Lg0KDQpJJ20gbm90IHNheWluZyBpdCdzIGEgYmFkIHRo aW5nLCBqdXN0IHRoYXQgeW91IGNhbid0IHJlYWxseSBjb21wYXJlIG5vbmUgYW5kIGlkX3Rva2Vu IHdpdGggY29kZV9mb3JfaWRfdG9rZW4uDQoNCk9uIFdlZCwgSnVsIDIzLCAyMDE0IGF0IDY6NDUg UE0sIFJpY2hlciwgSnVzdGluIFAuIDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBt aXRyZS5vcmc+PiB3cm90ZToNCkl0J3Mgb25seSAibm90IHVzaW5nIHRoZSB0b2tlbiBlbmRwb2lu dCIgYmVjYXVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgY29weS1wYXN0ZWQgYW5kIHJlbmFtZWQgdGhl IGF1dGhlbnRpY2F0aW9uIGVuZHBvaW50Lg0KDQogLS0gSnVzdGluDQoNCk9uIEp1bCAyMywgMjAx NCwgYXQgOTozMCBBTSwgVGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPG1haWx0bzp0 LmJyb3llckBnbWFpbC5jb20+PiB3cm90ZToNCg0KRXhjZXB0IHRoYXQgdGhlc2UgYXJlIGFib3V0 IG5vdCB1c2luZyB0aGUgVG9rZW4gRW5kcG9pbnQgYXQgYWxsLCB3aGVyZWFzIHRoZSBjdXJyZW50 IHByb3Bvc2FsIGlzIGFib3V0IHRoZSBUb2tlbiBFbmRwb2ludCBub3QgcmV0dXJuaW5nIGFuIGFj Y2Vzc190b2tlbiBmaWVsZCBpbiB0aGUgSlNPTi4NCg0KT24gV2VkLCBKdWwgMjMsIDIwMTQgYXQg NDoyNiBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRoZSByZXNwb25zZV90eXBlICJu b25lIiBpcyBhbHJlYWR5IHVzZWQgaW4gcHJhY3RpY2UsIHdoaWNoIHJldHVybnMgbm8gYWNjZXNz IHRva2VuLiAgSXQgd2FzIGFjY2VwdGVkIGJ5IHRoZSBkZXNpZ25hdGVkIGV4cGVydHMgYW5kIHJl Z2lzdGVyZWQgaW4gdGhlIElBTkEgT0F1dGggQXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNwb25z ZSBUeXBlcyByZWdpc3RyeSBhdCBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29hdXRo LXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54bWwjZW5kcG9pbnQuICBUaGUgcmVnaXN0ZXJl ZCAiaWRfdG9rZW4iIHJlc3BvbnNlIHR5cGUgYWxzbyByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi4N Cg0KU28gSSB0aGluayB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciByZXNwb25zZSB0eXBlcyB0aGF0 IHJlc3VsdCBpbiBubyBhY2Nlc3MgdG9rZW4gYmVpbmcgcmV0dXJuZWQgYXJlIGFjY2VwdGFibGUg d2l0aGluIE9BdXRoIDIuMCBpcyBhbHJlYWR5IHNldHRsZWQsIGFzIGEgcHJhY3RpY2FsIG1hdHRl ci4gIExvdHMgb2YgT0F1dGggaW1wbGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IHVzaW5nIHN1Y2gg cmVzcG9uc2UgdHlwZXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVo YWxmIE9mIFBoaWwgSHVudA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDc6MDkgQU0N ClRvOiBOYXQgU2FraW11cmENCkNjOiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYu b3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQNCg0KWWVzLiBUaGlzIGlzIHdo eSBpdCBoYXMgdG8gYmUgZGlzY3Vzc2VkIGluIHRoZSBJRVRGLg0KDQpQaGlsDQoNCkBpbmRlcGVu ZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNv bS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoN Cg0KDQpPbiBKdWwgMjMsIDIwMTQsIGF0IDk6NDMgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFA Z21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCg0KUmVhZGluZyBi YWNrIHRoZSBSRkM2NzQ5LCBJIGFtIG5vdCBzdXJlIGlmIHRoZXJlIGlzIGEgZ29vZCB3YXkgb2Yg c3VwcHJlc3NpbmcgYWNjZXNzIHRva2VuIGZyb20gdGhlIHJlc3BvbnNlIGFuZCBzdGlsbCBiZSBP QXV0aC4gSXQgd2lsbCBicmVhayB3aG9sZSBidW5jaCBvZiBpbXBsaWNpdCBkZWZpbml0aW9ucyBs aWtlOg0KDQphdXRob3JpemF0aW9uIHNlcnZlcg0KICAgICAgVGhlIHNlcnZlciBpc3N1aW5nIGFj Y2VzcyB0b2tlbnMgdG8gdGhlIGNsaWVudCBhZnRlciBzdWNjZXNzZnVsbHkNCiAgICAgIGF1dGhl bnRpY2F0aW5nIHRoZSByZXNvdXJjZSBvd25lciBhbmQgb2J0YWluaW5nIGF1dGhvcml6YXRpb24u DQoNCkFmdGVyIGFsbCwgT0F1dGggaXMgYWxsIGFib3V0IGlzc3VpbmcgYWNjZXNzIHRva2Vucy4N Cg0KQWxzbywgSSB0YWtlIGJhY2sgbXkgc3RhdGVtZW50IG9uIHRoZSBncmFudCB0eXBlIGluIG15 IHByZXZpb3VzIG1haWwuDQoNClRoZSBkZWZpbml0aW9uIG9mIGdyYW50IGFuZCBncmFudF90eXBl IGFyZSByZXNwZWN0aXZlbHk6DQoNCmdyYW50DQogICAgY3JlZGVudGlhbCByZXByZXNlbnRpbmcg dGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbg0KDQpncmFudF90eXBlDQogICAgKHN0 cmluZyByZXByZXNlbnRpbmcgdGhlKSB0eXBlIG9mIGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVu ZHBvaW50IHRvIG9idGFpbiB0aGUgYWNjZXNzIHRva2VuDQoNClRodXMsIHRoZSBncmFudCBzZW50 IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBpbiB0aGlzIGNhc2UgaXMgc3RpbGwgJ2NvZGUnLg0KDQpS ZXNwb25zZSB0eXBlIG9uIHRoZSBvdGhlciBoYW5kIGlzIG5vdCBzbyB3ZWxsIGRlZmluZWQgaW4g UkZDNjc0OSwgYnV0IGl0IHNlZW1zIGl0IGlzIHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJlIHJl dHVybmVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRvIGV4cHJlc3Mgd2hhdCBp cyB0byBiZSByZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50LCBwZXJoYXBzIGRlZmluaW5nIGEg bmV3IHBhcmFtZXRlciB0byB0aGUgdG9rZW4gZW5kcG9pbnQsIHdoaWNoIGlzIGEgcGFyYWxsZWwg dG8gdGhlIHJlc3BvbnNlX3R5cGUgdG8gdGhlIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgc2VlbXMg dG8gYmUgYSBtb3JlIHN5bW1ldHJpYyB3YXksIHRob3VnaCBJIGFtIG5vdCBzdXJlIGF0IGFsbCBp ZiB0aGF0IGlzIGdvaW5nIHRvIGJlIE9BdXRoIGFueSBtb3JlLiBPbmUgc3RyYXctbWFuIGlzIHRv IGRlZmluZSBhIG5ldyBwYXJhbWV0ZXIgY2FsbGVkIHJlc3BvbnNlX3R5cGUgdG8gdGhlIHRva2Vu IGVuZHBvaW50IHN1Y2ggYXM6DQoNCnJlc3BvbnNlX3R5cGUNCiAgICBPUFRJT05BTC4gQSBzdHJp bmcgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUgdG9rZW4gZW5k cG9pbnQuDQoNClRoZW4gZGVmaW5lIHRoZSBiZWhhdmlvciBvZiB0aGUgZW5kcG9pbnQgYWNjb3Jk aW5nIHRvIHRoZSB2YWx1ZXMgYXMgdGhlIHBhcmFsbGVsIHRvIHRoZSBtdWx0aS1yZXNwb25zZSB0 eXBlIHNwZWMuDQpodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC12Mi1tdWx0aXBsZS1yZXNw b25zZS10eXBlcy0xXzAuaHRtbA0KDQpOYXQNCg0KDQoNCg0KMjAxNC0wNy0yMyA3OjIxIEdNVC0w NDowMCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbT4+Og0KVGhlIGRyYWZ0IGlzIHZlcnkgY2xlYXIuDQoNClBoaWwNCg0KT24gSnVsIDIz LCAyMDE0LCBhdCAwOjQ2LCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86 c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQpUaGUgbmV3IGdyYW50IHR5cGUgdGhhdCBJIHdh cyB0YWxraW5nIGFib3V0IHdhcw0KImF1dGhvcml6YXRpb25fY29kZV9idXRfZG9fbm90X3JldHVy bl9hY2Nlc3Nfbm9yX3JlZnJlc2hfdG9rZW4iLCBzbyB0byBzcGVhay4NCkl0IGRvZXMgbm90IHJl dHVybiBhbnl0aGluZyBwZXIgc2UsIGJ1dCBhbiBleHRlbnNpb24gY2FuIGRlZmluZSBzb21ldGhp bmcgb24gdG9wIG9mIGl0Lg0KDQpUaGVuLCBPSURDIGNhbiBkZWZpbmUgYSBiaW5kaW5nIHRvIGl0 IHNvIHRoYXQgdGhlIGJpbmRpbmcgb25seSByZXR1cm5zIElEIFRva2VuLg0KVGhpcyBiaW5kaW5n IHdvcmsgc2hvdWxkIGJlIGRvbmUgaW4gT0lERi4gU2hvdWxkIHRoZXJlIGJlIHN1Y2ggYSBncmFu dCB0eXBlLA0KaXQgd2lsbCBiZSBhbiBleHRyZW1lbHkgc2hvcnQgc3BlYy4NCg0KQXQgdGhlIHNh bWUgdGltZSwgaWYgYW55IG90aGVyIHNwZWNpZmljYXRpb24gd2FudGVkIHRvIGRlZmluZQ0Kb3Ro ZXIgdHlwZSBvZiB0b2tlbnMgYW5kIGhhdmUgaXQgcmV0dXJuZWQgZnJvbSB0aGUgdG9rZW4gZW5k cG9pbnQsDQppdCBjYW4gYWxzbyB1c2UgdGhpcyBncmFudCB0eXBlLg0KDQpJZiB3aGF0IHlvdSB3 YW50IGlzIHRvIGRlZmluZSBhIG5ldyBncmFudCB0eXBlIHRoYXQgcmV0dXJucyBJRCBUb2tlbiBv bmx5LA0KdGhlbiwgSSBhbSB3aXRoIEp1c3Rpbi4gU2luY2UgIm90aGVyIHJlc3BvbnNlIHRoYW4g SUQgVG9rZW4iIGlzIG9ubHkNCnRoZW9yZXRpY2FsLCB0aGlzIGlzIGEgbW9yZSBwbGF1c2libGUg d2F5IGZvcndhcmQsIEkgc3VwcG9zZS4NCg0KTmF0DQoNCjIwMTQtMDctMjIgMTQ6MzAgR01ULTA0 OjAwIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1 Pj46DQpTbyB0aGUgZHJhZnQgd291bGQgbGl0ZXJhbGx5IHR1cm4gaW50bzoNCg0KIlRoZSBhNGMg cmVzcG9uc2UgdHlwZSBhbmQgZ3JhbnQgdHlwZSByZXR1cm4gYW4gaWRfdG9rZW4gZnJvbSB0aGUg dG9rZW4gZW5kcG9pbnQgd2l0aCBubyBhY2Nlc3MgdG9rZW4uIEFsbCBwYXJhbWV0ZXJzIGFuZCB2 YWx1ZXMgYXJlIGRlZmluZWQgaW4gT0lEQy4iDQoNClNlZW1zIGxpa2UgdGhlIHBlcmZlY3QgbWlu aSBleHRlbnNpb24gZHJhZnQgZm9yIE9JREYgdG8gZG8uDQoNCi0tSnVzdGluDQoNCi9zZW50IGZy b20gbXkgcGhvbmUvDQoNCk9uIEp1bCAyMiwgMjAxNCAxMDoyOSBBTSwgTmF0IFNha2ltdXJhIDxz YWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KPg0K PiBXaGF0IGFib3V0IGp1c3QgZGVmaW5pbmcgYSBuZXcgZ3JhbnQgdHlwZSBpbiB0aGlzIFdHPw0K Pg0KPg0KPiAyMDE0LTA3LTIyIDEyOjU2IEdNVC0wNDowMCBQaGlsIEh1bnQgPHBoaWwuaHVudEBv cmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+Og0KPj4NCj4+IFRoYXQgd291 bGQgYmUgbmljZS4gSG93ZXZlciBvaWRjIHN0aWxsIG5lZWRzIHRoZSBuZXcgZ3JhbnQgdHlwZSBp biBvcmRlciB0byBpbXBsZW1lbnQgdGhlIHNhbWUgZmxvdy4NCj4+DQo+PiBQaGlsDQo+Pg0KPj4g T24gSnVsIDIyLCAyMDE0LCBhdCAxMTozNSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5j b208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4NCj4+PiArMSB0byBKdXN0 aW4uDQo+Pj4NCj4+Pg0KPj4+IDIwMTQtMDctMjIgOTo1NCBHTVQtMDQ6MDAgUmljaGVyLCBKdXN0 aW4gUC4gPGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+Og0KPj4+ Pg0KPj4+PiBFcnJvcnMgbGlrZSB0aGVzZSBtYWtlIGl0IGNsZWFyIHRvIG1lIHRoYXQgaXQgd291 bGQgbWFrZSBtdWNoIG1vcmUgc2Vuc2UgdG8gZGV2ZWxvcCB0aGlzIGRvY3VtZW50IGluIHRoZSBP cGVuSUQgRm91bmRhdGlvbi4gSXQgc2hvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGRpcmVjdGx5IHJl ZmVyZW5jZXMgT3BlbklEIENvbm5lY3QgQ29yZSBmb3IgYWxsIG9mIHRoZXNlIHRlcm1zIGluc3Rl YWQgb2YgcmVkZWZpbmluZyB0aGVtLiBJdCdzIGRvaW5nIGF1dGhlbnRpY2F0aW9uLCB3aGljaCBp cyBmdW5kYW1lbnRhbGx5IHdoYXQgT3BlbklEIENvbm5lY3QgZG9lcyBvbiB0b3Agb2YgT0F1dGgs IGFuZCBJIGRvbid0IHNlZSBhIGdvb2QgYXJndW1lbnQgZm9yIGRvaW5nIHRoaXMgd29yayBpbiB0 aGlzIHdvcmtpbmcgZ3JvdXAuDQo+Pj4+DQo+Pj4+ICAtLSBKdXN0aW4NCj4+Pj4NCj4+Pj4gT24g SnVsIDIyLCAyMDE0LCBhdCA0OjMwIEFNLCBUaG9tYXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5j b208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+Pg0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+Pg0KPj4+Pj4gT24gTW9uLCBKdWwgMjEsIDIwMTQgYXQgMTE6NTIgUE0sIE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPj4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+PiBUaGFua3MgZm9yIHlvdXIgcmV2aWV3 LCBUaG9tYXMuICBUaGUgInByb21wdD1jb25zZW50IiBkZWZpbml0aW9uIGJlaW5nIG1pc3Npbmcg aXMgYW4gZWRpdG9yaWFsIGVycm9yLiAgSXQgc2hvdWxkIGJlOg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+ Pj4+Pg0KPj4+Pj4+IGNvbnNlbnQNCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBBdXRob3JpemF0aW9uIFNl cnZlciBTSE9VTEQgcHJvbXB0IHRoZSBFbmQtVXNlciBmb3IgY29uc2VudCBiZWZvcmUgcmV0dXJu aW5nIGluZm9ybWF0aW9uIHRvIHRoZSBDbGllbnQuIElmIGl0IGNhbm5vdCBvYnRhaW4gY29uc2Vu dCwgaXQgTVVTVCByZXR1cm4gYW4gZXJyb3IsIHR5cGljYWxseSBjb25zZW50X3JlcXVpcmVkLg0K Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEknbGwgcGxhbiB0byBhZGQgaXQgaW4gdGhl IG5leHQgZHJhZnQuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IEl0IGxvb2tzIGxpa2UgdGhlIGNvbnNl bnRfcmVxdWlyZWQgZXJyb3IgbmVlZHMgdG8gYmUgZGVmaW5lZCB0b28sIGFuZCB5b3UgbWlnaHQg aGF2ZSBmb3Jnb3R0ZW4gdG8gYWxzbyBpbXBvcnQgYWNjb3VudF9zZWxlY3Rpb25fcmVxdWlyZWQg ZnJvbSBPcGVuSUQgQ29ubmVjdC4NCj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+ Pj4gSSBhZ3JlZSB0aGF0IHRoZXJlJ3Mgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIGEgcmVzcG9uc2Ug d2l0aCBtdWx0aXBsZSAiYW1yIiB2YWx1ZXMgdGhhdCBpbmNsdWRlcyAibWZhIiBhbmQgb25lIHRo YXQgZG9lc24ndC4gIFVubGVzcyBhIGNsZWFyIHVzZSBjYXNlIGZvciB3aHkgIm1mYSIgaXMgbmVl ZGVkIGNhbiBiZSBpZGVudGlmaWVkLCB3ZSBjYW4gZGVsZXRlIGl0IGluIHRoZSBuZXh0IGRyYWZ0 Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MuDQo+Pj4+Pg0KPj4+Pj4gSG93IGFib3V0ICJw d2QiIHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IEkgc2hvdWxkIHJldHVybiAicHdkIiBp ZiB0aGUgdXNlciBhdXRoZW50aWNhdGVkIHVzaW5nIGEgcGFzc3dvcmQsIGJ1dCB3aGF0ICJ0aGUg c2VydmljZSBpZiBhIGNsaWVudCBzZWNyZXQgaXMgdXNlZCIgbWVhbnMgaW4gdGhlIGRlZmluaXRp b24gZm9yIHRoZSAicHdkIiB2YWx1ZT8NCj4+Pj4+DQo+Pj4+PiAoTm90YTogSSBrbm93IHlvdSdy ZSBhdCBJRVRGLTkwLCBJJ20gcmVhZHkgdG8gd2FpdCAndGlsIHlvdSBjb21lIGJhY2sgOy0pICkN Cj4+Pj4+DQo+Pj4+PiAtLQ0KPj4+Pj4gVGhvbWFzIEJyb3llcg0KPj4+Pj4gL3TJlC5tYS5iyoF3 YS5qZS88aHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvPg0KPj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IE9BdXRoIG1haWxp bmcgbGlzdA0KPj4+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+Pg0KPj4+ Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRv Ok9BdXRoQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQo+Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0NCj4+PiBOYXQgU2FraW11cmEg KD1uYXQpDQo+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQo+Pj4gaHR0cDovL25hdC5z YWtpbXVyYS5vcmcvDQo+Pj4gQF9uYXRfZW4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4g T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4NCj4NCj4NCj4gLS0NCj4gTmF0IFNh a2ltdXJhICg9bmF0KQ0KPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCj4gaHR0cDovL25h dC5zYWtpbXVyYS5vcmcvDQo+IEBfbmF0X2VuDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0 KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8N CkBfbmF0X2VuDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5J RCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KLS0NClRob21hcyBCcm95 ZXINCi90yZQubWEuYsqBd2EuamUvPGh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhiLmplLz4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt YWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpUaG9tYXMg QnJveWVyDQovdMmULm1hLmLKgXdhLmplLzxodHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5q ZS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpO YXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHA6Ly9u YXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0 Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRv Ok9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0K TmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8v bmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3Bl bklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5k YXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCg0K --_000_4E1F6AAD24975D4BA5B16804296739439ADE8ED3TK5EX14MBXC293r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYu TXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1z dHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBs YWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5IZXJl4oCZcyBhIHBvaW50IG9mIHRlY2huaWNhbCBkaXNjdXNzaW9uIGZvciB5 b3VyIGNvbnNpZGVyYXRpb24gYWJvdXQgdGhlIGN1cnJlbnQgY29udGVudCBvZiBhNGMgYW5kIGEg cG9zc2libGUgc2ltcGxpZmljYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhh dmluZyB0aG91Z2h0IGFib3V0IHRoZSB2aWV3cyBleHByZXNzZWQgYWJvdXQgZGVmaW5pbmcgdGhl IG5ldyByZXNwb25zZSB0eXBlIGFuZCBncmFudCB0eXBlIHZhbHVlcywgSSBjYW1lIHVwIHdpdGgg YSBwb3NzaWJsZSBzeW50YXggY2hhbmdlIHRoYXQgd291bGQgYmUgbXVjaCBtb3JlIG1pbmltYWwg YW5kIGFjY29tcGxpc2ggdGhlIHNhbWUgdGhpbmcuJm5ic3A7IFJhdGhlciB0aGFuIGRlZmluaW5n IGEgbmV3IHJlc3BvbnNlDQogdHlwZSBhbmQgYSBuZXcgZ3JhbnQgdHlwZSwgaW5zdGVhZCwgd2Ug Y291bGQganVzdCB1c2UgdGhlIGV4aXN0aW5nIGNvZGUgZmxvdyBhbmQgc2F5IHRoYXQgaXQncyBs ZWdhbCBmb3IgdGhlIHRva2VuIGVuZHBvaW50IHRvIHJldHVybiB0aGUgdmFsdWUgJnF1b3Q7YWNj ZXNzX3Rva2VuPW5vbmUmcXVvdDsuJm5ic3A7IFRoYXQgd2F5LCB0aGUgZGVsdGEgdG8gT0F1dGgg Mi4wIGZvciB0aGUgbm8tYWNjZXNzLXRva2VuIGNhc2Ugd291bGQgYmUgdmVyeSBzbWFsbCBhbmQg dGhlDQogc3ludGF4IG9mIHRoZSByZXNwb25zZSBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCB3b3Vs ZCBiZSB1bmNoYW5nZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QW5kIHdoaWxlIHBlb3BsZSBtaWdo dCBpbml0aWFsbHkgdGhpbmsgdGhhdCBzaW5jZSB3ZeKAmWQgYmUgZGVmaW5pbmcgYSBkaXN0aW5n dWlzaGVkIGFjY2Vzc190b2tlbiByZXN1bHQgdmFsdWUgd2UgbWlnaHQgYmUgc3RlcHBpbmcgb24g aW1wbGVtZW50YXRpb25zLCAmcXVvdDtub25lJnF1b3Q7IGRvZXNuJ3QgbWVldCB0aGUgbWluaW11 bSBlbnRyb3B5IHJlcXVpcmVtZW50cyBpbiBPQXV0aCAyLjAsIHNvIHdvdWxkbid0IGNvbmZsaWN0 DQogd2l0aCBhbnkgY29uZm9ybWluZyBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lzaGVzLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9B dXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ UGhpbCBIdW50PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDI0LCAyMDE0IDc6MzQg QU08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gQnJhZGxleTxicj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0 Zi5vcmcgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSI+d3d3Lmlu ZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9 Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gSnVsIDI0LCAyMDE0LCBhdCAxMDoyNSBBTSwgSm9obiBCcmFkbGV5 ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgYW0gbm90IGFnYWluc3QgZGlzY3Vzc2lvbiBpbiB0aGUgV0cuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhcHBlbiB0byBhZ3JlZSB3aXRoIFBo aWwncyBmdW5kYW1lbnRhbCBwcmVtaXNlIHRoYXQgc29tZSBkZXZlbG9wZXJzIGFyZSB1c2luZyBP QXV0aCBpbiBhIGluc2VjdXJlIHdheSB0byBkbyBhdXRoZW50aWNhdGlvbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCByYWlzZXMgdGhl IHF1ZXN0aW9uIG9mIGhvdyB0byBiZXN0IGVkdWNhdGUgdGhlbSwgYW5kIG9yIGFkZHJlc3MgdGVj aG5pY2FsIGJhcnJpZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JdCBpcyBvbiB0aGUgc2Vjb25kIHBvaW50IHRoYXQgcGVvcGxlJ3Mgb3Bp bmlvbnMgc2VlbSB0byBkaXZpZGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNvbWUgcGVvcGxlIHRoaW5nIHRoYXQgaWYgd2UgaGF2ZSBhIE9B dXRoIGZsb3cgdGhhdCBlbGltaW5hdGVzIHRoZSBhY2Nlc3MgdG9rZW4gKHByaW1hcmlseSB0byBh dm9pZCBhc2tpbmcgZm9yIGNvbnNlbnQgYXMgSSB1bmRlcnN0YW5kIGl0KSBhbmQganVzdCByZXR1 cm4gYSBpZF90b2tlbiBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCB0aGF0IGNhbiBiZSBkb25lIGlu IGEgc3BlYyBzaG9ydCBlbm91Z2ggdG8gaGV0DQogcGVvcGxlIHRvIHJlYWQuICZuYnNwOyBUaGUg c3VidGV4dCBvZiB0aGlzIGlzIHRoYXQgdGhlIENvbm5lY3Qgc3BlY2lmaWNhdGlvbiBpcyB0b28g bGFyZ2UgdGhhdCBpdCBzY2FyZSBwZW9wbGUsICZuYnNwO2FuZCB0aGV5IGRvbid0IGZpbmQgdGhl IHNwZWMgaW4gdGhlIGZpcnN0IHBsYWNlIGJlY2F1c2UgaXQgaXMgbm90IGEgUkZDLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbiBvdGhlciBj b21tb24gcG9zc2Vzc2lvbiBpcyB0aGF0IGlmIHlvdSBkb24ndCB3YW50IHRvIHByb21wdCB0aGUg dXNlciBmb3IgY29uc2VudCB0aGVuIGRvbid0IGFzayBmb3Igc2NvcGVzLiAmbmJzcDtUd2lzdGlu ZyB0aGUgT0F1dGggc3BlYyB0byBub3QgcmV0dXJuIGFuIGFjY2VzcyB0b2tlbiBpcyBub3QgT0F1 dGgsICZuYnNwO3llcyB5b3UgY291bGQgdXNlIGEgZGlmZmVyZW50IGVuZHBvaW50IHJhdGhlciB0 aGFuIHRoZQ0KIHRva2VuIGVuZHBvaW50LCBidXQgdGhhdCBpcyBub3QgT0F1dGguICZuYnNwOyBD b25uZWN0IHdhcyBjYXJlZnVsIG5vdCB0byBicmVhayB0aGUgT0F1dGggc3BlYy4gJm5ic3A7ICZu YnNwO0FzIGxvbmcgYXMgeW91IGFyZSB3aWxsaW5nIHRvIHRha2UgYSBhY2Nlc3MgdG9rZW4gd2l0 aCBubyBzY29wZXMgKHRoZSBjbGllbnQgbmVlZHMgdG8gdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGFy ZSBubyBhdHRyaWJ1dGVzIG9uZSB3YXkgb3IgYW5vdGhlciBhbnl3YXkgb3IgaXQgd2lsbA0KIGJy ZWFrKSB0aGVuIHlvdSBkb24ndCBuZWVkIHRvIGNoYW5nZSBPQXV0aC4gJm5ic3A7IFlvdSBjYW4g cHVibGlzaCBhIHByb2ZpbGUgb2YgY29ubmVjdCB0aGF0IHNhdGlzZmllcyB0aGUgdXNlIGNhc2Uu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg dGhpbmsgTWlrZSBoYXMgbGFyZ2VseSBkb25lIHRoYXQgYnV0IGl0IG1pZ2h0IGJlIGJldHRlciBi ZWluZyBsZXNzIHN0aW5neSBvbiByZWZlcmVuY2VzIGJhY2sgdG8gdGhlIGxhcmdlciBzcGVjLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg cXVlc3Rpb25zIGFyZSBkbyB3ZSBtb2RpZnkgT0F1dGggdG8gbm90IHJldHVybiBhbiBhY2Nlc3Mg dG9rZW4sIGFuZCBpZiBzbyBob3csICZuYnNwO2FuZCBpZiB3ZSBkbyBpcyBpdCBzdGlsbCBPQXV0 aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIG90aGVyIGxhcmdlbHkgc2VwYXJhYmxlIHF1ZXN0aW9uIGlzIGRvIHdlIGNyZWF0ZSBjb25m dXNpb24gaW4gdGhlIG1hcmtldCBhbmQgc2xvdyB0aGUgdGhlIGFkb3B0aW9uIG9mIGlkZW50aXR5 IGZlZGVyYXRpb24gb24gdG9wIG9mIE9BdXRoLCBvciBmaW5kIGEgd2F5IHRvIG1ha2UgdGhpcyBs b29rIGxpa2UgYSBwb3NpdGl2ZSBhbGlnbm1lbnQgb2YgaW50ZXJlc3RzIGFyb3VuZCBhIHN1YnNl dCBvZiBDb25uZWN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGVyZSBhcmUgYSBudW1iZXIgb2Ygb3B0aW9ucy4gJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xOiBXZSBjYW4gZG8g YSBwcm9maWxlIGluIHRoZSBPSURGIGFuZCBwdWJsaXNoIGl0IGFzIGEgSUVURiBkb2N1bWVudC4g Jm5ic3A7IFBlcmhhcHMgdGhlIGNsZWFuZXN0IGZyb20gYW4gSVBSIHBvaW50IG9mIHZpZXcuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yOldlIGNh biBkbyBhIHByb2ZpbGUgaW4gdGhlIE9BdXRoIFdHIHJlZmVyZW5jaW5nIGNvbm5lY3QuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zOldlIGNhbiBk byBhIEFEIHNwb25zb3JlZCBwcm9maWxlIHRoYXQgaXMgbm90IGluIHRoZSBPQXV0aCBXRy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQ6V2UgY2Fu IGRvIGEgc21hbGwgc3BlYyBpbiBPQXV0aCB0byBhZGQgcmVzcG9uc2VfdHlwZSB0byB0aGUgdG9r ZW4gZW5kcG9pbnQuICZuYnNwO2luIGNvbWJpbmF0aW9uIHdpdGggMSwgMiwgb3IgMzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRo YXQgc3RvcGluZyBkZXZlbG9wZXJzIGRvaW5nIGluc2VjdXJlIHRoaW5ncyBuZWVkcyB0byBiZSBh ZGRyZXNzZWQgc29tZWhvdy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBwZXJzb25hbGx5IGNvbnZpbmNlZCB0aGF0IE9h dXRoIHdpdGhvdXQgYWNjZXNzIHRva2VucyBpcyBzZW5zaWJsZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9va2luZyBmb3J3YXJkIHRvIHRo ZSBtZWV0aW5nOik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gSnVsIDI0LCAyMDE0LCBhdCA2OjUyIEFNLCBCcmlhbiBDYW1w YmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5iY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ2Qgbm90ZSB0aGF0IHRoZSByZWFjdGlvbiBhdCB0 aGUgY29uZmVyZW5jZSB0byBJYW4ncyBzdGF0ZW1lbnQgd2FzIG92ZXJ3aGVsbWluZ2x5IHBvc2l0 aXZlLiBUaGVyZSB3YXMgYSB3aWRlIHJhbmdlIG9mIGluZHVzdHJ5IHBlb3BsZSBoZXJlIC0gaW1w bGVtZW50ZXJzLCBwcmFjdGl0aW9uZXJzLCBkZXBsb3llcnMsIHN0cmF0ZWdpc3RzLCBldGMuIC0g YW5kIGl0IHNlZW1zIHByZXR0eSBjbGVhciB0aGF0IHRoZQ0KICZxdW90O3JvdWdoIGNvbnNlbnN1 cyZxdW90OyBvZiB0aGUgaW5kdXN0cnkgYXQgbGFyZ2UgaXMgdGhhdCBhNGMgaXMgbm90IHdhbnRl ZCBvciBuZWVkZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVsIDI0LCAyMDE0IGF0IDU6 MjkgQU0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBoZXJlIGlzIGEgcXVv dGUgZnJvbSBJYW4ncyBibG9nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIGFsdGhvdWdoIHRoZSBhdXRoZW50aWNhdGlvbiB3aGVl bCBpcyByb3VuZCwgdGhhdCBkb2VzbuKAmXQgbWVhbiBpdCBpc27igJl0IHdpdGhvdXQgaXRzIGx1 bXBzLiBGaXJzdCwgd2UgZG8gc2VlIHNvbWUgcmVpbnZlbnRpbmcgdGhlIHdoZWVsIGp1c3QgdG8g cmVpbnZlbnQgdGhlIHdoZWVsLiBPQXV0aCBBNEMgaXMgc2ltcGx5IG5vdCBhIGZydWl0ZnVsIGFj dGl2aXR5IGFuZCBzaG91bGQgYmUgcHV0IGRvd24uICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KFNvdXJjZSkg PGEgaHJlZj0iaHR0cDovL3d3dy50dWVzZGF5bmlnaHQub3JnLzIwMTQvMDcvMjMvZG8td2UtaGF2 ZS1hLXJvdW5kLXdoZWVsLXlldC1tdXNpbmdzLW9uLWlkZW50aXR5LXN0YW5kYXJkcy1wYXJ0LTEu aHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy50dWVzZGF5bmlnaHQub3JnLzIwMTQv MDcvMjMvZG8td2UtaGF2ZS1hLXJvdW5kLXdoZWVsLXlldC1tdXNpbmdzLW9uLWlkZW50aXR5LXN0 YW5kYXJkcy1wYXJ0LTEuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ MjAxNC0wNy0yMyAxNjo1MyBHTVQtMDQ6MDAgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWls dG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwv YT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgdGhvdWdodCBJIGRpZCBwb3N0IHRoaXMgdG8gdGhlIGxpc3QuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgZ3Vlc3MgSSBoaXQgdGhlIHdyb25nIHJlcGx5IG9uIG15IHBob25lLiZuYnNwOzxicj4NCiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Sm9obiBCLiZuYnNwOzxicj4NClNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KT24gSnVsIDIzLCAyMDE0LCBhdCA0OjUwIFBNLCA8YSBocmVmPSJtYWlsdG86 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj4NCnRvcnN0ZW5AbG9kZGVy c3RlZHQubmV0PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cD53ZSBhcmUg dHdvLCBhdCBsZWFzdCA6LSk8bzpwPjwvbzpwPjwvcD4NCjxwPldoeSBkaWRuJ3QgeW91IHBvc3Qg dGhpcyBvbiB0aGUgbGlzdD88bzpwPjwvbzpwPjwvcD4NCjxwPldoZW4gd2lsbCBiZSBiZSBhcnJp dmluZz88bzpwPjwvbzpwPjwvcD4NCjxwPkFtIDIzLjA3LjIwMTQgMTY6MzksIHNjaHJpZWIgSm9o biBCcmFkbGV5OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JYW4gR2xhemVyIG1lbnRpb25lZCB0aGlz IGluIGhpcyBrZXlub3RlIGF0IENJUyB5ZXN0ZXJkYXkuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpcyBhZHZpY2Ugd2FzIHBsZWFz ZSBzdG9wLCAmbmJzcDt3ZSBhcmUgY3JlYXRpbmcgY29uZnVzaW9uIGFuZCB1bmNlcnRhaW50eS4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2UgYXJlIGJlY29taW5nIG91ciBvd24gd29ydCBlbmVteS4gKCBteSB2aWV3IHRob3VnaCBJ YW4gbWF5IHNoYXJlIGl0KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SZXR1cm5pbmcganVzdCBhbiBpZF8gdG9rZW4gZnJvbSB0aGUgdG9rZW4g ZW5kcG9pbnQgaGFzIGxpdHRsZSByZWFsIHZhbHVlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21ldGhpbmcgcmVhbGx5IHVzZWZ1 bCB0byBkbyB3b3VsZCBiZSBzb3J0aW5nIG91dCBjaGFubmVsX2lkIHNvIHdlIGNhbiBkbyBQb1Ag Zm9yIGlkIHRva2VucyB0byBtYWtlIHRoZW0gYW5kIG90aGVyIGNvb2tpZXMgc2VjdXJlIGluIHRo ZSBmcm9udCBjaGFubmVsLiAmbmJzcDsgSSB0aGluayB0aGF0IGlzIGEgYmV0dGVyIHVzZSBvZiB0 aW1lLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIG1heSBiZSBpbiB0aGUgbWlub3JpdHkgb3BpbmlvbiBvbiB0aGF0LCAmbmJzcDtp dCB3b24ndCBiZSB0aGUgZmlyc3QgdGltZS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KSm9obiBCLiZuYnNwOzxicj4NClNlbnQg ZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KT24gSnVsIDIzLCAyMDE0LCBhdCA0OjA0IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8 YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzEw MTBGRiAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Zb3UgYXJlIHJpZ2h0IGZyb20gYSB0aGVvcmV0aWNhbCBwZXJzcGVj dGl2ZS4gUHJhY3RpY2FsbHkgdGhpcyB3YXMgY2F1c2VkIGJ5IGVkaXRvcmlhbCBkZWNpc2lvbnMg ZHVyaW5nIHRoZSBjcmVhdGlvbiBvZiB0aGUgUkZDLiBBcyBmYXIgYXMgSSByZW1lbWJlciwgdGhl cmUgd2FzIGEgZGVmaW5pdGlvbiBvZiB0aGUgKG9uZSkgdG9rZW4gZW5kcG9pbnQgcmVzcG9uc2Ug aW4gZWFybHkgdmVyc2lvbnMuIE5vIG9uZQ0KIGV2ZXJ5IGNvbnNpZGVyZWQgdG8gTk9UIHJlc3Bv bmQgd2l0aCBhbiBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQuIFNvIG9uZSBt aWdodCBjYWxsIGl0IGFuIGltcGxpY2l0IGFzc3VtcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSB3b3JyaWVkIHRoYXQgcGVvcGxl IGdldCB0b3RhbGx5IGNvbmZ1c2VkIGlmIGFuIGV4Y2VwdGlvbiBpcyBpbnRyb2R1Y2VkIG5vdyBn aXZlbiB0aGUgYnJvYWQgYWRvcHRpb24gb2YgT0F1dGggYmFzZWQgb24gdGhpcyBhc3N1bXB0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5y ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VG9yc3Rlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KQW0gMjMuMDcuMjAxNCB1 bSAxNTo0MSBzY2hyaWViIFRob21hcyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3ll ckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj50LmJyb3llckBnbWFpbC5jb208L2E+Jmd0Ozo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtt YXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cD5JcyBpdCBzYWlkIGFueXdoZXJlIHRoYXQgQUxMIGdyYW50IHR5cGVzIE1VU1Qg dXNlIFNlY3Rpb24gNS4xIHJlc3BvbnNlcz8gRWFjaCBncmFudCB0eXBlIHJlZmVyZW5jZXMgU2Vj dGlvbiA1LjEsIGFuZCAmcXVvdDthY2Nlc3MgdG9rZW4gcmVxdWVzdCZxdW90OyBpcyBvbmx5IGRl ZmluZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGRlZmluZWQgZ3JhbnQgdHlwZXMuIFNlY3Rpb24g Mi4yIGRvZXNuJ3QgdGFsayBhYm91dCB0aGUgcmVxdWVzdCBvciByZXNwb25zZQ0KIGZvcm1hdC48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZSAyMyBqdWlsLiAy MDE0IDIxOjMyLCAmcXVvdDtOYXQgU2FraW11cmEmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpz YWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+ Jmd0OyBhIMOpY3JpdCA6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SXMgaXQ/IEFwYXJ0IGZyb20gdGhlIGltcGxpY2l0IGdyYW50IHRoYXQgZG9lcyBub3QgdXNl IHRva2VuIGVuZHBvaW50LCBhbGwgb3RoZXIgZ3JhbnQgcmVmZXJlbmNlcyBzZWN0aW9uIDUuMSBm b3IgdGhlIHJlc3BvbnNlLCBpLmUuLCBhbGwgc2hhcmVzIHRoZSBzYW1lIHJlc3BvbnNlLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE0LTA3LTIzIDE1OjE4IEdNVC0wNDowMCBUaG9tYXMgQnJv eWVyICZsdDs8YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8cD5JIGhhZG4n dCByZWFsaXplZCB0aGUgSlNPTiByZXNwb25zZSB0aGF0IHJlcXVpcmVzIHRoZSBhY2Nlc3NfdG9r ZW4gZmllbGQgaXMgZGVmaW5lZCBwZXIgZ3JhbnRfdHlwZSwgc28gSSdkIGJlIE9LIHRvICZxdW90 O2V4dGVuZCB0aGUgc2VtYW50aWNzJnF1b3Q7IGFzIGluIHRoZSBjdXJyZW50IGRyYWZ0Ljxicj4N ClRoYXQgd2FzIGFjdHVhbGx5IG15IG1haW4gY29uY2VybjogdGhhdCB0aGUgdG9rZW4gZW5kcG9p bnQgbWFuZGF0ZXMgYWNjZXNzX3Rva2VuOyBidXQgaXRzIGFjdHVhbGx5IG5vdCB0aGUgY2FzZS48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZSAyMyBqdWlsLiAy MDE0IDIwOjQ2LCAmcXVvdDtOYXQgU2FraW11cmEmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpz YWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+ Jmd0OyBhIMOpY3JpdCA6DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdpdGggSm9obiB0aGF0IG92ZXJsb2Fk aW5nIHJlc3BvbnNlX3R5cGUgQCBhdXRoeiBlbmRwb2ludCBpcyBhIGJhZCBpZGVhLiBJdCBjb21w bGV0ZWx5IGNoYW5nZXMgdGhlIHNlbWFudGljcyBvZiB0aGlzIHBhcmFtZXRlci4gTk9URTogd2hh dCBJIHdhcyBwcm9wb3Npbmcgd2FzIG5vdCB0aGlzIHBhcmFtZXRlciwgYnV0IGEgbmV3IHBhcmFt ZXRlciByZXNwb25zZV90eXBlIEAgdG9rZW4gZW5kcG9pbnQuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyB0aGluayBvdmVy bG9hZGluZyBncmFudF90eXBlIGlzIGEgYmFkIGlkZWEgc2luY2UgaXQgY2hhbmdlcyBpdHMgc2Vt YW50aWNzLiBJIHF1b3RlIHRoZSBkZWZpbml0aW9uIGhlcmUgYWdhaW46Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ncmFu dCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3VyY2Ugb3du ZXIncyBhdXRob3JpemF0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmdyYW50X3R5cGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnR5cGUgb2YgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4gZW5k cG9pbnQgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBub3QgYWJvdXQgY29u dHJvbGxpbmcgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCwg YnV0IHRoZSBoaW50IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBkZXNjcmliaW5nIHRoZSB0eXBlIG9m IGNyZWRlbnRpYWwgdGhlIGVuZHBvaW50IGhhcyByZWNlaXZlZC4gSXQgc2VlbXMgdGhlICZxdW90 O2NvbnRyb2wgb2Ygd2hhdCBpcyBiZWluZyByZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50JnF1 b3Q7DQogJm5ic3A7aXMganVzdCBhIHNpZGUgZWZmZWN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIHNvbWV3aGF0IGFtYml2 YWxlbnRbMV0gaW4gY2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiB0b2tlbiBlbmRwb2ludCwgYnV0 IGluIGFzIG11Y2ggYXMgJnF1b3Q7dGV4dCBpcyB0aGUga2luZyZxdW90OyBmb3IgYSBzcGVjLiwg d2UgcHJvYmFibHkgc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBpdCBhcyBUb3Jz dGVuIHBvaW50cyBvdXQuIElmIGl0IGlzIG9rIHRvIGNoYW5nZSB0aGlzIHNlbWFudGljcywgSQ0K IGJlbGlldmUgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVyIHRvIHRoaXMgZW5kcG9pbnQgdG8gY29u dHJvbCB0aGUgcmVzcG9uc2Ugd291bGQgYmUgdGhlIGJlc3Qgd2F5IHRvIGdvLiBUaGlzIGlzIHdo YXQgSSBoYXZlIGRlc2NyaWJlZCBwcmV2aW91c2x5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWZpbmluZyBhIG5ldyBlbmRwb2lu dCB0byBzZW5kIGNvZGUgdG8gZ2V0IElEIFRva2VuIGFuZCBmb3JiaWRkaW5nIHRoZSB1c2Ugb2Yg aXQgYWdhaW5zdCB0b2tlbiBlbmRwb2ludCB3b3VsZCBub3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mg b2YgYW55IGV4aXN0aW5nIHBhcmFtZXRlciBvciBlbmRwb2ludCwgd2hpY2ggaXMgZ29vZC4gSG93 ZXZlciwgSSBkb3VidCBpZiBpdCBpcyBub3Qgd29ydGggZG9pbmcuIFdoYXQncw0KIHRoZSBwb2lu dCBvZiBhdm9pZGluZyBhY2Nlc3MgdG9rZW4gc2NvcGVkIHRvIFVzZXJJbmZvIGVuZHBvaW50IGFm dGVyIGFsbD8gRGVmaW5pbmcgYSBuZXcgZW5kcG9pbnQgZm9yIGp1c3QgYXZvaWRpbmcgdGhlIGFj Y2VzcyB0b2tlbiBmb3IgdXNlcmluZm8gZW5kcG9pbnQgc2VlbXMgd2F5IHRvbyBtdWNoIHRoZSBo ZWF2eSB3YWl0IHdheSBhbmQgaXQgYnJlYWtzIGludGVyb3BlcmFiaWxpeTogaXQgZGVmZWF0cyB0 aGUgcHVycG9zZSBvZiBzdGFuZGFyZGl6YXRpb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBzdGFydGVkIGZlZWxpbmcg dGhhdCBubyBjaGFuZ2UgaXMgdGhlIGJlc3Qgd2F5IG91dC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsxXSAmbmJzcDtJZiBpbnN0 ZWFkIG9mIHNheWluZyAmcXVvdDtUb2tlbiBlbmRwb2ludCAtIHVzZWQgYnkgdGhlIGNsaWVudCB0 byBleGNoYW5nZSBhbiBhdXRob3JpemF0aW9uJm5ic3A7Z3JhbnQgZm9yIGFuIGFjY2VzcyB0b2tl biwgdHlwaWNhbGx5IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0aW9uJnF1b3Q7LCBpdCB3ZXJlIHNh eWluZyAmcXVvdDtUb2tlbiBlbmRwb2ludCAtIHVzZWQgYnkgdGhlIGNsaWVudCB0byBleGNoYW5n ZSBhbiBhdXRob3JpemF0aW9uJm5ic3A7Z3JhbnQNCiBmb3IgdG9rZW5zLCB0eXBpY2FsbHkgd2l0 aCBjbGllbnQgYXV0aGVudGljYXRpb24mcXVvdDssIHRoZW4gaXQgd291bGQgaGF2ZSBiZWVuIE9L LiBJdCBpcyBhbiBleHBhbnNpb24gb2YgdGhlIGNhcGFiaWxpdHkgcmF0aGVyIHRoYW4gY2hhbmdp bmcgdGhlIHNlbWFudGljcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTQtMDctMjMg MTM6MzkgR01ULTA0OjAwIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91 IG5lZWQgdGhlIGFsdGVybmF0aXZlIHJlc3BvbnNlX3R5cGUgdmFsdWUgKCZxdW90Ozwvc3Bhbj5j b2RlX2Zvcl9pZF90b2tlbjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mcXVvdDsNCiBpbiB0aGUgQTRDIGRyYWZ0KSB0byB0ZWxsIHRoZSBBdXRob3JpemF0aW9uIFNl cnZlciB0byByZXR1cm4gYSBjb2RlIHRvIGJlIHVzZWQgd2l0aCB0aGUgbmV3IGdyYW50IHR5cGUs IHJhdGhlciB0aGFuIG9uZSB0byB1c2Ugd2l0aCB0aGUgJnF1b3Q7YXV0aG9yaXphdGlvbl9jb2Rl JnF1b3Q7IGdyYW50IHR5cGUgKHdoaWNoIGlzIHdoYXQgcmVzcG9uc2VfdHlwZT1jb2RlIGRvZXMp Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBC ZWhhbGYgT2YgPC9zcGFuPjwvc3Ryb25nPkpvaG4gQnJhZGxleTxicj4NCjxzdHJvbmc+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5TZW50Ojwvc3Bhbj48L3N0cm9uZz4gV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDEwOjMz IEFNPGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRvOjwvc3Bhbj48L3N0cm9uZz4gPGEgaHJlZj0i bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+DQp0b3JzdGVu QGxvZGRlcnN0ZWR0Lm5ldDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxzdHJvbmc+Q2M6PC9zdHJvbmc+IDxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9h Pjxicj4NCjxzdHJvbmc+U3ViamVjdDo8L3N0cm9uZz4gUmU6IFtPQVVUSC1XR10gTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB3ZSB1c2UgdGhlIHRva2Vu IGVuZHBvaW50IHRoZW4gYSBuZXcgZ3JhbnRfdHlwZSBpcyB0aGUgYmVzdCB3YXkuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SXQgc29ydCBvZiBvdmVybG9hZHMgY29kZSwgYnV0IHRoYXQgaXMgYmV0dGVy IHRoYW4gbWVzc2luZyB3aXRoIHJlc3BvbnNlX3R5cGUgZm9yIHRoZSBhdXRob3JpemF0aW9uIGVu ZHBvaW50IHRvIGNoYW5nZSB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgdG9rZW5fZW5kcG9pbnQuICZu YnNwO1RoYXQgaXMgaW4gbXkgb3Bpbmlvbg0KIGEgY2hhbXBpb24gYmFkIGlkZWEuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SW4gZGlzY3Vzc2lvbnMgZGV2ZWxvcGluZyBDb25uZWN0IHdlIGRlY2lkZWQg bm90IHRvIG9wZW4gdGhpcyBjYW4gb2Ygd29ybXMgYmVjYXVzZSBubyBnb29kIHdvdWxkIGNvbWUg b2YgaXQuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSB0b2tlbl9lbmRwb2ludCByZXR1 cm5zIGEgYWNjZXNzIHRva2VuLiAmbmJzcDtOb3RoaW5nIHJlcXVpcmVzIHNjb3BlIHRvIGJlIGFz c29jaWF0ZXMgd2l0aCB0aGUgdG9rZW4uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhdCBpcyB0aGUg YmVzdCBzb2x1dGlvbi4gJm5ic3A7Tm8gY2hhbmdlIHJlcXVpcmVkLiAmbmJzcDtCZXR0ZXIgaW50 ZXJvcGVyYWJpbGl0eSBpbiBteSBvcGluaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlN0aWxsIG9u IG15IHdheSB0byBUTywgZ2V0dGluZyBpbiBsYXRlciB0b2RheS4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5Kb2huIEIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IGlQ aG9uZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpPbiBKdWwgMjMsIDIwMTQsIGF0IDEyOjE1IFBNLCA8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBs b2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj4NCnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0 PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHA+VGhlICZxdW90 O3Jlc3BvbnNlIHR5cGUmcXVvdDsgb2YgdGhlIHRva2VuIGVuZHBvaW50IGlzIGNvbnRyb2xsZWQg YnkgdGhlIHZhbHVlIG9mIHRoZSBwYXJhbWV0ZXIgJnF1b3Q7Z3JhbnRfdHlwZSZxdW90Oy4gU28g dGhlcmUgaXMgbm8gbmVlZCB0byBpbnRyb2R1Y2UgYSBuZXcgcGFyYW1ldGVyLjxvOnA+PC9vOnA+ PC9wPg0KPHA+d3J0IHRvIGEgcG90ZW50aWFsICZxdW90O25vX2FjY2Vzc190b2tlbiZxdW90OyBn cmFudCB0eXBlLiBJIGRvIG5vdCBjb25zaWRlciB0aGlzIGEgZ29vZCBpZGVhIGFzIGl0IGNoYW5n ZXMgdGhlIHNlbWFudGljcyBvZiB0aGUgdG9rZW4gZW5kcG9pbnQgKGFzIGFscmVhZHkgcG9pbnRl ZCBvdXQgYnkgVGhvbWFzKS4gVGhpcyBlbmRwb2ludCBBTFdBWVMgcmVzcG9uZHMgd2l0aCBhbiBh Y2Nlc3MgdG9rZW4gdG8gYW55IGdyYW50IHR5cGUuIEkgdGhlcmVmb3JlIHdvdWxkDQogcHJlZmVy IHRvIHVzZSBhbm90aGVyIGVuZHBvaW50IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZS48bzpwPjwv bzpwPjwvcD4NCjxwPnJlZ2FyZHMsPGJyPg0KVG9yc3Rlbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHA+ QW0gMjMuMDcuMjAxNCAxMzowNCwgc2NocmllYiBOYXQgU2FraW11cmE6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzEwMTBG RiAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPklNSE8sIGNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgJnF1b3Q7cmVz cG9uc2VfdHlwZSZxdW90OyBAIGF1dGh6IGVuZHBvaW50IHRoaXMgd2F5IGlzIG5vdCBhIGdvb2Qg dGhpbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JbnN0ZWFkLCBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXIgJnF1 b3Q7cmVzcG9uc2VfdHlwZSZxdW90OyBAIHRva2VuIGVuZHBvaW50LCBhcyBJIGRlc2NyaWJlZCBp biBteSBwcmV2aW91cyBtZXNzYWdlLCZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5wcm9iYWJseSBpcyBiZXR0ZXIuIEF0IGxlYXN0LCBpdCBkb2Vz IG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiB0aGUgcGFyYW1ldGVycyBvZiBSRkM2NzQ5LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwO05hdCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+MjAxNC0wNy0yMyAxMjo0OCBHTVQtMDQ6MDAgVGhvbWFzIEJy b3llciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnQuYnJveWVyQGdtYWlsLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Tm8sIEkgbWVhbiByZXNwb25zZV90eXBlPW5vbmUgYW5kIHJl c3BvbnNlX3R5cGU9aWRfdG9rZW4gZG9uJ3QgZ2VuZXJhdGUgYSBjb2RlIG9yIGFjY2VzcyB0b2tl biBzbyB5b3UgZG9uJ3QgdXNlIHRoZSBUb2tlbiBFbmRwb2ludCAod2hpY2ggaXMgbm90IHRoZSBz YW1lIGFzIHRoZSBBdXRoZW50aWNhdGlvbiBFbmRwb2ludA0KIEJUVykuIDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2l0aCByZXNwb25zZV90eXBlPWNvZGVf Zm9yX2lkX3Rva2VuLCB5b3UgZ2V0IGEgY29kZSBhbmQgZXhjaGFuZ2UgaXQgZm9yIGFuIGlkX3Rv a2VuIG9ubHksIHJhdGhlciB0aGFuIGFuIGFjY2Vzc190b2tlbiwgc28geW91J3JlIGNoYW5naW5n IHRoZSBzZW1hbnRpY3Mgb2YgdGhlIFRva2VuIEVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbSBu b3Qgc2F5aW5nIGl0J3MgYSBiYWQgdGhpbmcsIGp1c3QgdGhhdCB5b3UgY2FuJ3QgcmVhbGx5IGNv bXBhcmUgbm9uZSBhbmQgaWRfdG9rZW4gd2l0aCBjb2RlX2Zvcl9pZF90b2tlbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBK dWwgMjMsIDIwMTQgYXQgNjo0NSBQTSwgUmljaGVyLCBKdXN0aW4gUC4gJmx0OzxhIGhyZWY9Im1h aWx0bzpqcmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0cmUub3Jn PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JdCdzIG9ubHkgJnF1b3Q7bm90IHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludCZxdW90OyBi ZWNhdXNlIHRoZSB0b2tlbiBlbmRwb2ludCBjb3B5LXBhc3RlZCBhbmQgcmVuYW1lZCB0aGUgYXV0 aGVudGljYXRpb24gZW5kcG9pbnQuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7LS0gSnVzdGluPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBKdWwgMjMsIDIwMTQsIGF0IDk6MzAgQU0sIFRob21h cyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj50LmJyb3llckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkV4Y2VwdCB0aGF0IHRoZXNlIGFyZSBhYm91dCBub3QgdXNp bmcgdGhlIFRva2VuIEVuZHBvaW50IGF0IGFsbCwgd2hlcmVhcyB0aGUgY3VycmVudCBwcm9wb3Nh bCBpcyBhYm91dCB0aGUgVG9rZW4gRW5kcG9pbnQgbm90IHJldHVybmluZyBhbiBhY2Nlc3NfdG9r ZW4gZmllbGQgaW4gdGhlIEpTT04uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ T24gV2VkLCBKdWwgMjMsIDIwMTQgYXQgNDoyNiBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0i bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGUgcmVzcG9uc2VfdHlwZSAmcXVvdDtub25lJnF1b3Q7IGlz IGFscmVhZHkgdXNlZCBpbiBwcmFjdGljZSwgd2hpY2ggcmV0dXJucyBubyBhY2Nlc3MgdG9rZW4u Jm5ic3A7IEl0IHdhcyBhY2NlcHRlZA0KIGJ5IHRoZSBkZXNpZ25hdGVkIGV4cGVydHMgYW5kIHJl Z2lzdGVyZWQgaW4gdGhlIElBTkEgT0F1dGggQXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNwb25z ZSBUeXBlcyByZWdpc3RyeSBhdA0KPGEgaHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25t ZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueG1sI2VuZHBvaW50IiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29hdXRoLXBhcmFt ZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54bWwjZW5kcG9pbnQ8L2E+LiZuYnNwOyBUaGUgcmVnaXN0 ZXJlZCAmcXVvdDtpZF90b2tlbiZxdW90OyByZXNwb25zZSB0eXBlIGFsc28gcmV0dXJucyBubyBh Y2Nlc3MgdG9rZW4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIEkgdGhpbmsgdGhlIHF1 ZXN0aW9uIG9mIHdoZXRoZXIgcmVzcG9uc2UgdHlwZXMgdGhhdCByZXN1bHQgaW4gbm8gYWNjZXNz IHRva2VuIGJlaW5nIHJldHVybmVkIGFyZQ0KIGFjY2VwdGFibGUgd2l0aGluIE9BdXRoIDIuMCBp cyBhbHJlYWR5IHNldHRsZWQsIGFzIGEgcHJhY3RpY2FsIG1hdHRlci4mbmJzcDsgTG90cyBvZiBP QXV0aCBpbXBsZW1lbnRhdGlvbnMgYXJlIGFscmVhZHkgdXNpbmcgc3VjaCByZXNwb25zZSB0eXBl cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1 dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gQmVoYWxmIE9m IDwvc3Bhbj48L3N0cm9uZz5QaGlsIEh1bnQ8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2VudDo8 L3NwYW4+PC9zdHJvbmc+IFdlZG5lc2RheSwgSnVseSAyMywgMjAxNCA3OjA5IEFNPGJyPg0KPHN0 cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlRvOjwvc3Bhbj48L3N0cm9uZz4gTmF0IFNha2ltdXJhPGJyPg0KPHN0 cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkNjOjwvc3Bhbj48L3N0cm9uZz4gJmx0OzxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3ViamVjdDo8L3NwYW4+PC9zdHJvbmc+IFJlOiBbT0FVVEgt V0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2Vy LWE0Yy0wNS50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WWVzLiBUaGlzIGlzIHdoeSBpdCBoYXMg dG8gYmUgZGlzY3Vzc2VkIGluIHRoZSBJRVRGLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+UGhpbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QGluZGVwZW5kZW50aWQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5k ZXBlbmRlbnRpZC5jb20vIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9h Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBKdWwgMjMsIDIwMTQsIGF0 IDk6NDMgQU0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVhZGluZyBiYWNrIHRoZSBSRkM2NzQ5LCBJIGFt IG5vdCBzdXJlIGlmIHRoZXJlIGlzIGEgZ29vZCB3YXkgb2Ygc3VwcHJlc3NpbmcgYWNjZXNzIHRv a2VuIGZyb20gdGhlIHJlc3BvbnNlIGFuZCBzdGlsbCBiZSBPQXV0aC4gSXQgd2lsbCBicmVhayB3 aG9sZSBidW5jaCBvZiBpbXBsaWNpdCBkZWZpbml0aW9ucw0KIGxpa2U6Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YXV0aG9yaXph dGlvbiBzZXJ2ZXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgc2VydmVyIGlzc3Vpbmcg YWNjZXNzIHRva2VucyB0byB0aGUgY2xpZW50IGFmdGVyIHN1Y2Nlc3NmdWxseTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7IGF1dGhlbnRpY2F0aW5nIHRoZSByZXNvdXJjZSBvd25lciBhbmQgb2J0 YWluaW5nIGF1dGhvcml6YXRpb24uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFmdGVyIGFsbCwgT0F1dGggaXMgYWxsIGFib3V0 IGlzc3VpbmcgYWNjZXNzIHRva2Vucy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbHNvLCBJIHRha2Ug YmFjayBteSBzdGF0ZW1lbnQgb24gdGhlIGdyYW50IHR5cGUgaW4gbXkgcHJldmlvdXMgbWFpbC4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaGUgZGVmaW5pdGlvbiBvZiBncmFudCBhbmQgZ3JhbnRfdHlw ZSBhcmUgcmVzcGVjdGl2ZWx5OiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ncmFudCZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDsgJm5ic3A7IGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZSBvd25lcidz IGF1dGhvcml6YXRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Z3JhbnRfdHlwZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJz cDsgKHN0cmluZyByZXByZXNlbnRpbmcgdGhlKSB0eXBlIG9mIGdyYW50IHNlbnQgdG8gdGhlIHRv a2VuIGVuZHBvaW50IHRvIG9idGFpbiB0aGUgYWNjZXNzIHRva2VuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaHVzLCB0aGUgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgaW4gdGhpcyBj YXNlIGlzIHN0aWxsICdjb2RlJy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZXNwb25zZSB0eXBlIG9u IHRoZSBvdGhlciBoYW5kIGlzIG5vdCBzbyB3ZWxsIGRlZmluZWQgaW4gUkZDNjc0OSwgYnV0IGl0 IHNlZW1zIGl0IGlzIHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdGhl IGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRvIGV4cHJlc3Mgd2hhdCBpcyB0bw0KIGJlIHJldHVy bmVkIGZyb20gdG9rZW4gZW5kcG9pbnQsIHBlcmhhcHMgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVy IHRvIHRoZSB0b2tlbiBlbmRwb2ludCwgd2hpY2ggaXMgYSBwYXJhbGxlbCB0byB0aGUgcmVzcG9u c2VfdHlwZSB0byB0aGUgQXV0aG9yaXphdGlvbiBFbmRwb2ludCBzZWVtcyB0byBiZSBhIG1vcmUg c3ltbWV0cmljIHdheSwgdGhvdWdoIEkgYW0gbm90IHN1cmUgYXQgYWxsIGlmIHRoYXQgaXMgZ29p bmcgdG8gYmUgT0F1dGggYW55IG1vcmUuDQogT25lIHN0cmF3LW1hbiBpcyB0byBkZWZpbmUgYSBu ZXcgcGFyYW1ldGVyIGNhbGxlZCByZXNwb25zZV90eXBlIHRvIHRoZSB0b2tlbiBlbmRwb2ludCBz dWNoIGFzOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnJlc3BvbnNlX3R5cGU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBPUFRJ T05BTC4gQSBzdHJpbmcgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0 aGUgdG9rZW4gZW5kcG9pbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZW4g ZGVmaW5lIHRoZSBiZWhhdmlvciBvZiB0aGUgZW5kcG9pbnQgYWNjb3JkaW5nIHRvIHRoZSB2YWx1 ZXMgYXMgdGhlIHBhcmFsbGVsIHRvIHRoZSBtdWx0aS1yZXNwb25zZSB0eXBlIHNwZWMuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxh IGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29hdXRoLXYyLW11bHRpcGxlLXJlc3BvbnNl LXR5cGVzLTFfMC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL29wZW5pZC5uZXQvc3BlY3Mv b2F1dGgtdjItbXVsdGlwbGUtcmVzcG9uc2UtdHlwZXMtMV8wLmh0bWw8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+TmF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ MjAxNC0wNy0yMyA3OjIxIEdNVC0wNDowMCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29t PC9hPiZndDs6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhlIGRyYWZ0IGlzIHZlcnkgY2xlYXIuJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPjxicj4NCjxicj4NClBoaWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVsIDIzLCAyMDE0 LCBhdCAwOjQ2LCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGUgbmV3IGdyYW50IHR5cGUgdGhhdCBJIHdhcyB0YWxraW5nIGFib3V0IHdhcyZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JnF1b3Q7YXV0aG9yaXph dGlvbl9jb2RlX2J1dF9kb19ub3RfcmV0dXJuX2FjY2Vzc19ub3JfcmVmcmVzaF90b2tlbiZxdW90 Oywgc28gdG8gc3BlYWsuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SXQgZG9lcyBub3QgcmV0dXJuIGFueXRoaW5nIHBlciBzZSwgYnV0 IGFuIGV4dGVuc2lvbiBjYW4gZGVmaW5lIHNvbWV0aGluZyBvbiB0b3Agb2YgaXQuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhlbiwgT0lEQyBjYW4gZGVmaW5lIGEgYmluZGluZyB0byBpdCBzbyB0aGF0 IHRoZSBiaW5kaW5nIG9ubHkgcmV0dXJucyBJRCBUb2tlbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBiaW5kaW5nIHdvcmsg c2hvdWxkIGJlIGRvbmUgaW4gT0lERi4gU2hvdWxkIHRoZXJlIGJlIHN1Y2ggYSBncmFudCB0eXBl LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+aXQgd2lsbCBiZSBhbiBleHRyZW1lbHkgc2hvcnQgc3BlYy4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5BdCB0aGUgc2FtZSB0aW1lLCBpZiBhbnkgb3RoZXIgc3BlY2lm aWNhdGlvbiB3YW50ZWQgdG8gZGVmaW5lJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPm90aGVyIHR5cGUgb2YgdG9rZW5zIGFuZCBoYXZl IGl0IHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LCZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5pdCBjYW4gYWxzbyB1c2Ug dGhpcyBncmFudCB0eXBlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHdoYXQgeW91IHdhbnQgaXMg dG8gZGVmaW5lIGEgbmV3IGdyYW50IHR5cGUgdGhhdCByZXR1cm5zIElEIFRva2VuIG9ubHksJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PnRoZW4sIEkgYW0gd2l0aCBKdXN0aW4uIFNpbmNlICZxdW90O290aGVyIHJlc3BvbnNlIHRoYW4g SUQgVG9rZW4mcXVvdDsgaXMgb25seSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50aGVvcmV0aWNhbCwgdGhpcyBpcyBhIG1vcmUgcGxh dXNpYmxlIHdheSBmb3J3YXJkLCBJIHN1cHBvc2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TmF0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4yMDE0LTA3LTIyIDE0OjMw IEdNVC0wNDowMCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQu ZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvIHRoZSBkcmFmdCB3b3VsZCBsaXRlcmFsbHkg dHVybiBpbnRvOjxicj4NCjxicj4NCiZxdW90O1RoZSBhNGMgcmVzcG9uc2UgdHlwZSBhbmQgZ3Jh bnQgdHlwZSByZXR1cm4gYW4gaWRfdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCBu byBhY2Nlc3MgdG9rZW4uIEFsbCBwYXJhbWV0ZXJzIGFuZCB2YWx1ZXMgYXJlIGRlZmluZWQgaW4g T0lEQy4mcXVvdDs8YnI+DQo8YnI+DQpTZWVtcyBsaWtlIHRoZSBwZXJmZWN0IG1pbmkgZXh0ZW5z aW9uIGRyYWZ0IGZvciBPSURGIHRvIGRvLjxicj4NCjxicj4NCi0tSnVzdGluPGJyPg0KPGJyPg0K L3NlbnQgZnJvbSBteSBwaG9uZS88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxicj4NCk9uIEp1bCAyMiwgMjAxNCAxMDoyOSBBTSwgTmF0IFNha2ltdXJhICZs dDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2Fr aW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgV2hhdCBh Ym91dCBqdXN0IGRlZmluaW5nIGEgbmV3IGdyYW50IHR5cGUgaW4gdGhpcyBXRz88YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgMjAxNC0wNy0yMiAxMjo1NiBHTVQtMDQ6MDAgUGhpbCBIdW50 ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgVGhhdCB3b3VsZCBiZSBuaWNlLiBIb3dldmVyIG9pZGMgc3RpbGwgbmVlZHMgdGhlIG5ldyBn cmFudCB0eXBlIGluIG9yZGVyIHRvIGltcGxlbWVudCB0aGUgc2FtZSBmbG93LiZuYnNwOzxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUGhpbDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg T24gSnVsIDIyLCAyMDE0LCBhdCAxMTozNSwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWls dG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJiM0MzsxIHRv IEp1c3Rpbi4mbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsgMjAxNC0wNy0yMiA5OjU0IEdNVC0wNDowMCBSaWNoZXIsIEp1c3RpbiBQLiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+anJp Y2hlckBtaXRyZS5vcmc8L2E+Jmd0Ozo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBFcnJvcnMgbGlrZSB0aGVzZSBtYWtlIGl0IGNsZWFyIHRvIG1lIHRoYXQgaXQg d291bGQgbWFrZSBtdWNoIG1vcmUgc2Vuc2UgdG8gZGV2ZWxvcCB0aGlzIGRvY3VtZW50IGluIHRo ZSBPcGVuSUQgRm91bmRhdGlvbi4gSXQgc2hvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGRpcmVjdGx5 IHJlZmVyZW5jZXMgT3BlbklEIENvbm5lY3QgQ29yZSBmb3IgYWxsIG9mIHRoZXNlIHRlcm1zIGlu c3RlYWQgb2YgcmVkZWZpbmluZyB0aGVtLiBJdCdzIGRvaW5nDQogYXV0aGVudGljYXRpb24sIHdo aWNoIGlzIGZ1bmRhbWVudGFsbHkgd2hhdCBPcGVuSUQgQ29ubmVjdCBkb2VzIG9uIHRvcCBvZiBP QXV0aCwgYW5kIEkgZG9uJ3Qgc2VlIGEgZ29vZCBhcmd1bWVudCBmb3IgZG9pbmcgdGhpcyB3b3Jr IGluIHRoaXMgd29ya2luZyBncm91cC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyAmbmJzcDstLSBKdXN0aW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyBPbiBKdWwgMjIsIDIwMTQsIGF0IDQ6MzAgQU0sIFRob21hcyBCcm95ZXIg Jmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj50 LmJyb3llckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gTW9uLCBKdWwg MjEsIDIwMTQgYXQgMTE6NTIgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZvciB5b3VyIHJldmlldywgVGhv bWFzLiZuYnNwOyBUaGUgJnF1b3Q7cHJvbXB0PWNvbnNlbnQmcXVvdDsgZGVmaW5pdGlvbiBiZWlu ZyBtaXNzaW5nIGlzIGFuIGVkaXRvcmlhbCBlcnJvci4mbmJzcDsgSXQgc2hvdWxkIGJlOjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAm bmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgY29uc2VudDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgU0hPVUxEIHByb21w dCB0aGUgRW5kLVVzZXIgZm9yIGNvbnNlbnQgYmVmb3JlIHJldHVybmluZyBpbmZvcm1hdGlvbiB0 byB0aGUgQ2xpZW50LiBJZiBpdCBjYW5ub3Qgb2J0YWluIGNvbnNlbnQsIGl0IE1VU1QgcmV0dXJu IGFuIGVycm9yLCB0eXBpY2FsbHkgY29uc2VudF9yZXF1aXJlZC48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEknbGwg cGxhbiB0byBhZGQgaXQgaW4gdGhlIG5leHQgZHJhZnQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEl0 IGxvb2tzIGxpa2UgdGhlIGNvbnNlbnRfcmVxdWlyZWQgZXJyb3IgbmVlZHMgdG8gYmUgZGVmaW5l ZCB0b28sIGFuZCB5b3UgbWlnaHQgaGF2ZSBmb3Jnb3R0ZW4gdG8gYWxzbyBpbXBvcnQgYWNjb3Vu dF9zZWxlY3Rpb25fcmVxdWlyZWQgZnJvbSBPcGVuSUQgQ29ubmVjdC48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgYWdyZWUgdGhhdCB0aGVyZSdzIG5vIGRp ZmZlcmVuY2UgYmV0d2VlbiBhIHJlc3BvbnNlIHdpdGggbXVsdGlwbGUgJnF1b3Q7YW1yJnF1b3Q7 IHZhbHVlcyB0aGF0IGluY2x1ZGVzICZxdW90O21mYSZxdW90OyBhbmQgb25lIHRoYXQgZG9lc24n dC4mbmJzcDsgVW5sZXNzIGEgY2xlYXIgdXNlIGNhc2UgZm9yIHdoeSAmcXVvdDttZmEmcXVvdDsg aXMgbmVlZGVkIGNhbiBiZSBpZGVudGlmaWVkLCB3ZSBjYW4gZGVsZXRlIGl0IGluIHRoZSBuZXh0 IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFua3MuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIb3cgYWJvdXQgJnF1b3Q7cHdkJnF1b3Q7 IHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IEkgc2hvdWxkIHJldHVybiAmcXVvdDtwd2Qm cXVvdDsgaWYgdGhlIHVzZXIgYXV0aGVudGljYXRlZCB1c2luZyBhIHBhc3N3b3JkLCBidXQgd2hh dCAmcXVvdDt0aGUgc2VydmljZSBpZiBhIGNsaWVudCBzZWNyZXQgaXMgdXNlZCZxdW90OyBtZWFu cyBpbiB0aGUgZGVmaW5pdGlvbiBmb3IgdGhlICZxdW90O3B3ZCZxdW90OyB2YWx1ZT88YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IChOb3RhOiBJIGtu b3cgeW91J3JlIGF0IElFVEYtOTAsIEknbSByZWFkeSB0byB3YWl0ICd0aWwgeW91IGNvbWUgYmFj ayA7LSkgKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaG9tYXMgQnJveWVyPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgL3Q8YSBocmVmPSJodHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5q ZS8iIHRhcmdldD0iX2JsYW5rIj7JlC5tYS5iyoF3YS5qZS88L2E+PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLTxicj4NCiZndDsmZ3Q7 Jmd0OyBOYXQgU2FraW11cmEgKD1uYXQpPGJyPg0KJmd0OyZndDsmZ3Q7IENoYWlybWFuLCBPcGVu SUQgRm91bmRhdGlvbjxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vbmF0LnNha2lt dXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJy Pg0KJmd0OyZndDsmZ3Q7IEBfbmF0X2VuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IE5hdCBTYWtpbXVyYSAoPW5hdCk8YnI+DQom Z3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDov L25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25hdC5zYWtpbXVyYS5v cmcvPC9hPjxicj4NCiZndDsgQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8YnI+ DQpOYXQgU2FraW11cmEgKD1uYXQpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRw Oi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJh Lm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxicj4NCk5hdCBTYWtpbXVy YSAoPW5hdCk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNo YWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11 cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+ DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9B dXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0t DQo8YnI+DQpUaG9tYXMgQnJveWVyPGJyPg0KL3Q8YSBocmVmPSJodHRwOi8veG4tLW5uYS5tYS54 bi0tYndhLXh4Yi5qZS8iIHRhcmdldD0iX2JsYW5rIj7JlC5tYS5iyoF3YS5qZS88L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0 aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiM4ODg4ODgiPi0tDQo8YnI+DQpUaG9tYXMgQnJveWVyPGJyPg0KL3Q8YSBocmVmPSJo dHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8iIHRhcmdldD0iX2JsYW5rIj7JlC5tYS5i yoF3YS5qZS88L2E+IDwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyIGNsZWFy PSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+LS0NCjxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCkgPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248 YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv YT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCkgPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4sIE9wZW5J RCBGb3VuZGF0aW9uPGJyPg0KPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFs bCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KTmF0 IFNha2ltdXJhICg9bmF0KSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0 LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88 L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtt YXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxl ZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi ciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LSA8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KPGEgaHJlZj0i aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25hdC5zYWtp bXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1 dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439ADE8ED3TK5EX14MBXC293r_-- From nobody Thu Jul 24 08:32:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE751A02D5 for ; Thu, 24 Jul 2014 08:32:18 -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 JHzXDL7Os3oc for ; Thu, 24 Jul 2014 08:32:10 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299B31A024E for ; Thu, 24 Jul 2014 08:32:09 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id n3so4209292wiv.7 for ; Thu, 24 Jul 2014 08:32:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=xeFX3Egtp2IfTdr/qeh0loylIv8kjyMvGzSyYISh3fQ=; b=Ul4GnVFDz+5Id9Y02++5LMQ37RaWn/pDQVTtjOoivlFeg0oIfOWJIlWn/FzGCDJBLW h8F/ERWipZNn31MDxQmzR/QuSGX8idUydBDan4MyVZY9F51UXqvUtQkQx3x0XvIf89G9 4nwfd+jE9GivVYNaUxJBwkOle/BASBiX4S7OCs0sk0FTtJhhZ2PdsnHqrFQkQwZ9ao07 moQRzN97K47xnkFXiyfIjjMfYti3kcpcqTjAZiv0EKZZknkbJxxSArzH2qDyDZXnXaXT cexuPF26dPHl2i2qQlqqqZDEopiFXG7F1K6NjecsAgdsLUBoJhm9WDUrTF4JTPYGscwX 040w== X-Gm-Message-State: ALoCoQkYttf/L3xcPvm4Y8DOlGEawuUGsZKcKscoLDBPjfBxAGBxzQlPR/Gkils6zMNfFzo0F0u5 X-Received: by 10.194.134.70 with SMTP id pi6mr13587810wjb.1.1406215927186; Thu, 24 Jul 2014 08:32:07 -0700 (PDT) Received: from dhcp-937d.meeting.ietf.org (dhcp-937d.meeting.ietf.org. [31.133.147.125]) by mx.google.com with ESMTPSA id ev18sm7400663wid.1.2014.07.24.08.32.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 08:32:05 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9A9B6A02-01C1-4B09-9CFF-05EC956D8011" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADE8ED3@TK5EX14MBXC293.redmond.corp.microsoft.com> Date: Thu, 24 Jul 2014 08:32:16 -0700 Message-Id: <883492A9-AA4B-4BFF-AB85-F4269E8DE0D1@ve7jtb.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADE8ED3@TK5EX14MBXC293.redmond.corp.microsoft.com> To: Michael Jones X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Eu1DitGPy5ZmGoiZCGIoiPeRkwk Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 15:32:18 -0000 --Apple-Mail=_9A9B6A02-01C1-4B09-9CFF-05EC956D8011 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The audience of a access token is a RS, and we have a principal of the = token being opaque to the client. On the other hand that is in line with what In was thinking. It is a = access token with no scopes that confers no access to a resource. We can define a sting for that or perhaps a JWT with a claim, to fit = with future interoperable access tokens using JWT in PoP and other = places. I was thinking that the token_endpoint also returns the scopes granted = as another parameter. Given that the access token is opaque but the scopes for the token are = not, it may fit better with existing libraries to just have a reserved = scope "urn:ietf:oauth:no-at-scopes" returned to indicate that there are = no resource grants associated with the issued AT. If we want to get down to it that doesn't step on namespace and is 100% = compatible with the existing OAuth spec. =20 A scope and a flag for each of the token types, eg none for bearer and a = claim in the JWT for the PoP types, but that probably should be part of = the token definition. =20 John B. On Jul 24, 2014, at 7:49 AM, Mike Jones = wrote: > Here=E2=80=99s a point of technical discussion for your consideration = about the current content of a4c and a possible simplification. > =20 > Having thought about the views expressed about defining the new = response type and grant type values, I came up with a possible syntax = change that would be much more minimal and accomplish the same thing. = Rather than defining a new response type and a new grant type, instead, = we could just use the existing code flow and say that it's legal for the = token endpoint to return the value "access_token=3Dnone". That way, the = delta to OAuth 2.0 for the no-access-token case would be very small and = the syntax of the response from the token endpoint would be unchanged. > =20 > And while people might initially think that since we=E2=80=99d be = defining a distinguished access_token result value we might be stepping = on implementations, "none" doesn't meet the minimum entropy requirements = in OAuth 2.0, so wouldn't conflict with any conforming implementation. > =20 > Best = wishes, > -- Mike > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Thursday, July 24, 2014 7:34 AM > To: John Bradley > Cc: oauth@ietf.org list > Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt > =20 > +1 > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On Jul 24, 2014, at 10:25 AM, John Bradley wrote: >=20 >=20 > I am not against discussion in the WG. > =20 > I happen to agree with Phil's fundamental premise that some developers = are using OAuth in a insecure way to do authentication. > =20 > That raises the question of how to best educate them, and or address = technical barriers. > =20 > It is on the second point that people's opinions seem to divide. > =20 > Some people thing that if we have a OAuth flow that eliminates the = access token (primarily to avoid asking for consent as I understand it) = and just return a id_token from the token endpoint that can be done in a = spec short enough to het people to read. The subtext of this is that = the Connect specification is too large that it scare people, and they = don't find the spec in the first place because it is not a RFC. > =20 > An other common possession is that if you don't want to prompt the = user for consent then don't ask for scopes. Twisting the OAuth spec to = not return an access token is not OAuth, yes you could use a different = endpoint rather than the token endpoint, but that is not OAuth. = Connect was careful not to break the OAuth spec. As long as you are = willing to take a access token with no scopes (the client needs to = understand that there are no attributes one way or another anyway or it = will break) then you don't need to change OAuth. You can publish a = profile of connect that satisfies the use case. > =20 > I think Mike has largely done that but it might be better being less = stingy on references back to the larger spec. > =20 > The questions are do we modify OAuth to not return an access token, = and if so how, and if we do is it still OAuth. > =20 > The other largely separable question is do we create confusion in the = market and slow the the adoption of identity federation on top of OAuth, = or find a way to make this look like a positive alignment of interests = around a subset of Connect. > =20 > There are a number of options. =20 > 1: We can do a profile in the OIDF and publish it as a IETF document. = Perhaps the cleanest from an IPR point of view. > 2:We can do a profile in the OAuth WG referencing connect. > 3:We can do a AD sponsored profile that is not in the OAuth WG. > 4:We can do a small spec in OAuth to add response_type to the token = endpoint. in combination with 1, 2, or 3 > =20 > I agree that stoping developers doing insecure things needs to be = addressed somehow. =20 > I am not personally convinced that Oauth without access tokens is = sensible. > =20 > Looking forward to the meeting:) > =20 > John B. > On Jul 24, 2014, at 6:52 AM, Brian Campbell = wrote: >=20 >=20 > I'd note that the reaction at the conference to Ian's statement was = overwhelmingly positive. There was a wide range of industry people here = - implementers, practitioners, deployers, strategists, etc. - and it = seems pretty clear that the "rough consensus" of the industry at large = is that a4c is not wanted or needed. > =20 >=20 > On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura = wrote: > And here is a quote from Ian's blog.=20 > =20 > And although the authentication wheel is round, that doesn=E2=80=99t = mean it isn=E2=80=99t without its lumps. First, we do see some = reinventing the wheel just to reinvent the wheel. OAuth A4C is simply = not a fruitful activity and should be put down. =20 > =20 > (Source) = http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musing= s-on-identity-standards-part-1.html > =20 >=20 > 2014-07-23 16:53 GMT-04:00 John Bradley : > =20 > I thought I did post this to the list.=20 > =20 > I guess I hit the wrong reply on my phone.=20 > =20 > John B.=20 > Sent from my iPhone >=20 > On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: >=20 > we are two, at least :-) >=20 > Why didn't you post this on the list? >=20 > When will be be arriving? >=20 > Am 23.07.2014 16:39, schrieb John Bradley: >=20 > Ian Glazer mentioned this in his keynote at CIS yesterday.=20 > =20 > His advice was please stop, we are creating confusion and = uncertainty.=20 > =20 > We are becoming our own wort enemy. ( my view though Ian may share it) > =20 > Returning just an id_ token from the token endpoint has little real = value.=20 > =20 > Something really useful to do would be sorting out channel_id so we = can do PoP for id tokens to make them and other cookies secure in the = front channel. I think that is a better use of time.=20 > =20 > I may be in the minority opinion on that, it won't be the first time. = =20 >=20 >=20 > John B.=20 > Sent from my iPhone >=20 > On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt = wrote: >=20 > You are right from a theoretical perspective. Practically this was = caused by editorial decisions during the creation of the RFC. As far as = I remember, there was a definition of the (one) token endpoint response = in early versions. No one every considered to NOT respond with an access = token from the token endpoint. So one might call it an implicit = assumption. > =20 > I'm worried that people get totally confused if an exception is = introduced now given the broad adoption of OAuth based on this = assumption. > =20 > regards, > Torsten. >=20 > Am 23.07.2014 um 15:41 schrieb Thomas Broyer : >=20 > Is it said anywhere that ALL grant types MUST use Section 5.1 = responses? Each grant type references Section 5.1, and "access token = request" is only defined in the context of the defined grant types. = Section 2.2 doesn't talk about the request or response format. >=20 > Le 23 juil. 2014 21:32, "Nat Sakimura" a =C3=A9crit= : > Is it? Apart from the implicit grant that does not use token endpoint, = all other grant references section 5.1 for the response, i.e., all = shares the same response.=20 > =20 >=20 > 2014-07-23 15:18 GMT-04:00 Thomas Broyer : > I hadn't realized the JSON response that requires the access_token = field is defined per grant_type, so I'd be OK to "extend the semantics" = as in the current draft. > That was actually my main concern: that the token endpoint mandates = access_token; but its actually not the case. >=20 > Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9crit= : > =20 > I agree with John that overloading response_type @ authz endpoint is a = bad idea. It completely changes the semantics of this parameter. NOTE: = what I was proposing was not this parameter, but a new parameter = response_type @ token endpoint.=20 > =20 > I also think overloading grant_type is a bad idea since it changes its = semantics. I quote the definition here again:=20 > =20 > grant=20 > credential representing the resource owner's authorization > =20 > grant_type > type of grant sent to the token endpoint to obtain the access token > =20 > It is not about controlling what is to be returned from the token = endpoint, but the hint to the token endpoint describing the type of = credential the endpoint has received. It seems the "control of what is = being returned from token endpoint" is just a side effect.=20 > =20 > I am somewhat ambivalent[1] in changing the semantics of token = endpoint, but in as much as "text is the king" for a spec., we probably = should not change the semantics of it as Torsten points out. If it is ok = to change this semantics, I believe defining a new parameter to this = endpoint to control the response would be the best way to go. This is = what I have described previously.=20 > =20 > Defining a new endpoint to send code to get ID Token and forbidding = the use of it against token endpoint would not change the semantics of = any existing parameter or endpoint, which is good. However, I doubt if = it is not worth doing. What's the point of avoiding access token scoped = to UserInfo endpoint after all? Defining a new endpoint for just = avoiding the access token for userinfo endpoint seems way too much the = heavy wait way and it breaks interoperabiliy: it defeats the purpose of = standardization.=20 > =20 > I have started feeling that no change is the best way out.=20 > =20 > Nat > =20 > [1] If instead of saying "Token endpoint - used by the client to = exchange an authorization grant for an access token, typically with = client authentication", it were saying "Token endpoint - used by the = client to exchange an authorization grant for tokens, typically with = client authentication", then it would have been OK. It is an expansion = of the capability rather than changing the semantics. > =20 > =20 >=20 > 2014-07-23 13:39 GMT-04:00 Mike Jones : > You need the alternative response_type value ("code_for_id_token" in = the A4C draft) to tell the Authorization Server to return a code to be = used with the new grant type, rather than one to use with the = "authorization_code" grant type (which is what response_type=3Dcode = does). > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Wednesday, July 23, 2014 10:33 AM > To: torsten@lodderstedt.net >=20 > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt > =20 > =20 > If we use the token endpoint then a new grant_type is the best way.=20 > =20 > It sort of overloads code, but that is better than messing with = response_type for the authorization endpoint to change the response from = the token_endpoint. That is in my opinion a champion bad idea.=20 > =20 > In discussions developing Connect we decided not to open this can of = worms because no good would come of it. =20 > =20 > The token_endpoint returns a access token. Nothing requires scope to = be associates with the token.=20 > =20 > That is the best solution. No change required. Better = interoperability in my opinion.=20 > =20 > Still on my way to TO, getting in later today.=20 > =20 > John B.=20 > =20 >=20 >=20 > Sent from my iPhone >=20 > On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >=20 > The "response type" of the token endpoint is controlled by the value = of the parameter "grant_type". So there is no need to introduce a new = parameter. >=20 > wrt to a potential "no_access_token" grant type. I do not consider = this a good idea as it changes the semantics of the token endpoint (as = already pointed out by Thomas). This endpoint ALWAYS responds with an = access token to any grant type. I therefore would prefer to use another = endpoint for the intended purpose. >=20 > regards, > Torsten. >=20 > =20 > Am 23.07.2014 13:04, schrieb Nat Sakimura: >=20 > IMHO, changing the semantics of "response_type" @ authz endpoint this = way is not a good thing.=20 > =20 > Instead, defining a new parameter "response_type" @ token endpoint, as = I described in my previous message,=20 > probably is better. At least, it does not change the semantics of the = parameters of RFC6749.=20 > =20 > Nat=20 > =20 > 2014-07-23 12:48 GMT-04:00 Thomas Broyer : > No, I mean response_type=3Dnone and response_type=3Did_token don't = generate a code or access token so you don't use the Token Endpoint = (which is not the same as the Authentication Endpoint BTW). > With response_type=3Dcode_for_id_token, you get a code and exchange it = for an id_token only, rather than an access_token, so you're changing = the semantics of the Token Endpoint. > =20 > I'm not saying it's a bad thing, just that you can't really compare = none and id_token with code_for_id_token. > =20 > On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. = wrote: > It's only "not using the token endpoint" because the token endpoint = copy-pasted and renamed the authentication endpoint. > =20 > -- Justin > =20 > On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: > =20 >=20 > Except that these are about not using the Token Endpoint at all, = whereas the current proposal is about the Token Endpoint not returning = an access_token field in the JSON. > =20 > On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones = wrote: > The response_type "none" is already used in practice, which returns no = access token. It was accepted by the designated experts and registered = in the IANA OAuth Authorization Endpoint Response Types registry = athttp://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#en= dpoint. The registered "id_token" response type also returns no access = token. > =20 > So I think the question of whether response types that result in no = access token being returned are acceptable within OAuth 2.0 is already = settled, as a practical matter. Lots of OAuth implementations are = already using such response types. > =20 > -- Mike > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf OfPhil Hunt > Sent: Wednesday, July 23, 2014 7:09 AM > To: Nat Sakimura > Cc: > Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt > =20 > Yes. This is why it has to be discussed in the IETF. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: > =20 > Reading back the RFC6749, I am not sure if there is a good way of = suppressing access token from the response and still be OAuth. It will = break whole bunch of implicit definitions like:=20 > =20 > authorization server > The server issuing access tokens to the client after = successfully > authenticating the resource owner and obtaining authorization. > =20 > After all, OAuth is all about issuing access tokens.=20 > =20 > Also, I take back my statement on the grant type in my previous mail.=20= > =20 > The definition of grant and grant_type are respectively:=20 > =20 > grant=20 > credential representing the resource owner's authorization > =20 > grant_type > (string representing the) type of grant sent to the token endpoint = to obtain the access token > =20 > Thus, the grant sent to the token endpoint in this case is still = 'code'.=20 > =20 > Response type on the other hand is not so well defined in RFC6749, but = it seems it is representing what is to be returned from the = authorization endpoint. To express what is to be returned from token = endpoint, perhaps defining a new parameter to the token endpoint, which = is a parallel to the response_type to the Authorization Endpoint seems = to be a more symmetric way, though I am not sure at all if that is going = to be OAuth any more. One straw-man is to define a new parameter called = response_type to the token endpoint such as:=20 > =20 > response_type > OPTIONAL. A string representing what is to be returned from the = token endpoint.=20 > =20 > Then define the behavior of the endpoint according to the values as = the parallel to the multi-response type spec.=20 > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html > =20 > Nat > =20 > =20 > =20 > =20 > 2014-07-23 7:21 GMT-04:00 Phil Hunt : > The draft is very clear.=20 >=20 > Phil >=20 > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >=20 > The new grant type that I was talking about was=20 > "authorization_code_but_do_not_return_access_nor_refresh_token", so to = speak.=20 > It does not return anything per se, but an extension can define = something on top of it.=20 > =20 > Then, OIDC can define a binding to it so that the binding only returns = ID Token.=20 > This binding work should be done in OIDF. Should there be such a grant = type,=20 > it will be an extremely short spec.=20 > =20 > At the same time, if any other specification wanted to define=20 > other type of tokens and have it returned from the token endpoint,=20 > it can also use this grant type.=20 > =20 > If what you want is to define a new grant type that returns ID Token = only,=20 > then, I am with Justin. Since "other response than ID Token" is only=20= > theoretical, this is a more plausible way forward, I suppose.=20 > =20 > Nat > =20 > 2014-07-22 14:30 GMT-04:00 Justin Richer : > So the draft would literally turn into: >=20 > "The a4c response type and grant type return an id_token from the = token endpoint with no access token. All parameters and values are = defined in OIDC." >=20 > Seems like the perfect mini extension draft for OIDF to do. >=20 > --Justin >=20 > /sent from my phone/ >=20 > On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: > > > > What about just defining a new grant type in this WG? > > > > > > 2014-07-22 12:56 GMT-04:00 Phil Hunt : > >> > >> That would be nice. However oidc still needs the new grant type in = order to implement the same flow.=20 > >> > >> Phil > >> > >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: > >> > >>> +1 to Justin.=20 > >>> > >>> > >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : > >>>> > >>>> Errors like these make it clear to me that it would make much = more sense to develop this document in the OpenID Foundation. It should = be something that directly references OpenID Connect Core for all of = these terms instead of redefining them. It's doing authentication, which = is fundamentally what OpenID Connect does on top of OAuth, and I don't = see a good argument for doing this work in this working group. > >>>> > >>>> -- Justin > >>>> > >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer = wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones = wrote: > >>>>>> > >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" = definition being missing is an editorial error. It should be: > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> consent > >>>>>> > >>>>>> The Authorization Server SHOULD prompt the End-User for consent = before returning information to the Client. If it cannot obtain consent, = it MUST return an error, typically consent_required. > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> I'll plan to add it in the next draft. > >>>>> > >>>>> > >>>>> It looks like the consent_required error needs to be defined = too, and you might have forgotten to also import = account_selection_required from OpenID Connect. > >>>>> =20 > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> I agree that there's no difference between a response with = multiple "amr" values that includes "mfa" and one that doesn't. Unless = a clear use case for why "mfa" is needed can be identified, we can = delete it in the next draft. > >>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>> How about "pwd" then? I fully understand that I should return = "pwd" if the user authenticated using a password, but what "the service = if a client secret is used" means in the definition for the "pwd" value? > >>>>> > >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come = back ;-) ) > >>>>> > >>>>> -- > >>>>> Thomas Broyer > >>>>> /t=C9=94.ma.b=CA=81wa.je/ > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> > >>> > >>> > >>> -- > >>> Nat Sakimura (=3Dnat) > >>> Chairman, OpenID Foundation > >>> http://nat.sakimura.org/ > >>> @_nat_en > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>>https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > =20 > --=20 > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > =20 > --=20 > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_9A9B6A02-01C1-4B09-9CFF-05EC956D8011 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = audience of a access token is a RS,  and we have a principal of the = token being opaque to the client.

On the other hand = that is in line with what In was thinking.   It is a access token = with no scopes that confers no access to a resource.
We can = define a sting for that or perhaps a JWT with a claim, to fit with = future interoperable access tokens using JWT in PoP and other = places.

I was thinking that the token_endpoint = also returns the scopes granted as another = parameter.

Given that the access token is = opaque but the scopes for the token are not, it may fit better with = existing libraries to just have a reserved scope = "urn:ietf:oauth:no-at-scopes"  returned to indicate that there are = no resource grants associated with the issued = AT.

If we want to get down to it that doesn't = step on namespace and is 100% compatible with the existing OAuth spec. =   
A scope and a flag for each of the token types, = eg none for bearer and a claim in the JWT for the PoP types, but that = probably should be part of the token definition. =  

John = B.

On Jul 24, 2014, at 7:49 AM, Mike = Jones <Michael.Jones@microsoft.com> wrote:

Here=E2=80=99s a = point of technical discussion for your consideration about the current = content of a4c and a possible simplification.
 
Having = thought about the views expressed about defining the new response type = and grant type values, I came up with a possible syntax change that = would be much more minimal and accomplish the same thing.  Rather = than defining a new response type and a new grant type, instead, we = could just use the existing code flow and say that it's legal for the = token endpoint to return the value "access_token=3Dnone".  That = way, the delta to OAuth 2.0 for the no-access-token case would be very = small and the syntax of the response from the token endpoint would be = unchanged.
 
And while = people might initially think that since we=E2=80=99d be defining a = distinguished access_token result value we might be stepping on = implementations, "none" doesn't meet the minimum entropy requirements in = OAuth 2.0, so wouldn't conflict with any conforming = implementation.
 
          &= nbsp;           &nb= sp;            = ;            &= nbsp;            = Best wishes,
          &= nbsp;           &nb= sp;            = ;            &= nbsp;            = -- Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org]<= span class=3D"Apple-converted-space"> On Behalf Of Phil = Hunt
Sent: Thursday, July 24, 2014 = 7:34 AM
To: John = Bradley
Cc: oauth@ietf.org = list
Subject: Re: [OAUTH-WG] New Version = Notification for = draft-hunt-oauth-v2-user-a4c-05.txt
 
+1
 
Phil
 
@independentid
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;">phil.hunt@oracle.com
 
 
 
On = Jul 24, 2014, at 10:25 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:


I am = not against discussion in the WG.
 
I happen to agree with Phil's fundamental premise = that some developers are using OAuth in a insecure way to do = authentication.
 
That = raises the question of how to best educate them, and or address = technical barriers.
 
It is = on the second point that people's opinions seem to = divide.
 
Some = people thing that if we have a OAuth flow that eliminates the access = token (primarily to avoid asking for consent as I understand it) and = just return a id_token from the token endpoint that can be done in a = spec short enough to het people to read.   The subtext of this is = that the Connect specification is too large that it scare people, =  and they don't find the spec in the first place because it is not = a RFC.
 
An = other common possession is that if you don't want to prompt the user for = consent then don't ask for scopes.  Twisting the OAuth spec to not = return an access token is not OAuth,  yes you could use a different = endpoint rather than the token endpoint, but that is not OAuth.   = Connect was careful not to break the OAuth spec.    As long as = you are willing to take a access token with no scopes (the client needs = to understand that there are no attributes one way or another anyway or = it will break) then you don't need to change OAuth.   You can = publish a profile of connect that satisfies the use = case.
 
I = think Mike has largely done that but it might be better being less = stingy on references back to the larger = spec.
 
The = questions are do we modify OAuth to not return an access token, and if = so how,  and if we do is it still = OAuth.
 
The = other largely separable question is do we create confusion in the market = and slow the the adoption of identity federation on top of OAuth, or = find a way to make this look like a positive alignment of interests = around a subset of Connect.
 
There are a number of options. =  
1: We = can do a profile in the OIDF and publish it as a IETF document.   = Perhaps the cleanest from an IPR point of = view.
2:We can do a = profile in the OAuth WG referencing = connect.
3:We = can do a AD sponsored profile that is not in the OAuth = WG.
4:We can do a = small spec in OAuth to add response_type to the token endpoint.  in = combination with 1, 2, or 3
 
I agree that stoping developers doing insecure = things needs to be addressed somehow. =  
I am = not personally convinced that Oauth without access tokens is = sensible.
 
Looking forward to the meeting:)
 
John B.
On Jul 24, 2014, at 6:52 AM, Brian Campbell <bcampbell@pingidentity.com> = wrote:


I'd = note that the reaction at the conference to Ian's statement was = overwhelmingly positive. There was a wide range of industry people here = - implementers, practitioners, deployers, strategists, etc. - and it = seems pretty clear that the "rough consensus" of the industry at large = is that a4c is not wanted or needed.

 

On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura <sakimura@gmail.com> = wrote:
And here is a = quote from Ian's blog. 
 
And although the = authentication wheel is round, that doesn=E2=80=99t mean it isn=E2=80=99t = without its lumps. First, we do see some reinventing the wheel just to = reinvent the wheel. OAuth A4C is simply not a fruitful activity and = should be put down.  
 

 

2014-07-23 16:53 GMT-04:00 John Bradley <ve7jtb@ve7jtb.com>:
 
I = thought I did post this to the = list. 
 
I = guess I hit the wrong reply on my = phone. 
 
John B. 
Sent from my = iPhone


On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote:

we are two, at least = :-)

Why didn't you = post this on the list?

When will be be arriving?

Am 23.07.2014 16:39, schrieb John = Bradley:

Ian Glazer = mentioned this in his keynote at CIS = yesterday. 
 
His = advice was please stop,  we are creating confusion and = uncertainty. 
 
We = are becoming our own wort enemy. ( my view though Ian may share = it)
 
Returning just an id_ token from the token endpoint has little = real value. 
 
Something really useful to do would be sorting out channel_id so = we can do PoP for id tokens to make them and other cookies secure in the = front channel.   I think that is a better use of = time. 
 
I may = be in the minority opinion on that,  it won't be the first time. =  


John = B. 
Sent from my iPhone


On Jul 23, 2014, at 4:04 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

You are right = from a theoretical perspective. Practically this was caused by editorial = decisions during the creation of the RFC. As far as I remember, there = was a definition of the (one) token endpoint response in early versions. = No one every considered to NOT respond with an access token from the = token endpoint. So one might call it an implicit = assumption.
 
I'm = worried that people get totally confused if an exception is introduced = now given the broad adoption of OAuth based on this = assumption.
 
regards,
Torsten.


Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

Is it said anywhere that ALL = grant types MUST use Section 5.1 responses? Each grant type references = Section 5.1, and "access token request" is only defined in the context = of the defined grant types. Section 2.2 doesn't talk about the request = or response format.

Le 23 = juil. 2014 21:32, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit = :
Is it? Apart = from the implicit grant that does not use token endpoint, all other = grant references section 5.1 for the response, i.e., all shares the same = response. 

 

2014-07-23 15:18 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:

I hadn't realized the JSON = response that requires the access_token field is defined per grant_type, = so I'd be OK to "extend the semantics" as in the current draft.
That = was actually my main concern: that the token endpoint mandates = access_token; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9cr= it :
 
I = agree with John that overloading response_type @ authz endpoint is a bad = idea. It completely changes the semantics of this parameter. NOTE: what = I was proposing was not this parameter, but a new parameter = response_type @ token endpoint. 
 
I also think overloading grant_type is a bad idea = since it changes its semantics. I quote the definition here = again: 
 
grant 
    credential representing the resource owner's = authorization
 
grant_type
type of grant sent to the token endpoint to obtain the access = token
 
It is = not about controlling what is to be returned from the token endpoint, = but the hint to the token endpoint describing the type of credential the = endpoint has received. It seems the "control of what is being returned = from token endpoint"  is just a side = effect. 
 
I am = somewhat ambivalent[1] in changing the semantics of token endpoint, but = in as much as "text is the king" for a spec., we probably should not = change the semantics of it as Torsten points out. If it is ok to change = this semantics, I believe defining a new parameter to this endpoint to = control the response would be the best way to go. This is what I have = described previously. 
 
Defining a new endpoint to send code to get ID Token = and forbidding the use of it against token endpoint would not change the = semantics of any existing parameter or endpoint, which is good. However, = I doubt if it is not worth doing. What's the point of avoiding access = token scoped to UserInfo endpoint after all? Defining a new endpoint for = just avoiding the access token for userinfo endpoint seems way too much = the heavy wait way and it breaks interoperabiliy: it defeats the purpose = of standardization. 
 
I = have started feeling that no change is the best way = out. 
 
Nat
 
[1] =  If instead of saying "Token endpoint - used by the client to = exchange an authorization grant for an access token, typically with = client authentication", it were saying "Token endpoint - used by the = client to exchange an authorization grant for tokens, typically = with client authentication", then it would have been OK. It is an = expansion of the capability rather than changing the = semantics.
 

 

2014-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@microsoft.com>:
You need the alternative = response_type value ("code_for_id_token" in = the A4C draft) to tell the Authorization Server to return a code to be = used with the new grant type, rather than one to use with the = "authorization_code" grant type (which is what response_type=3Dcode = does).
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Wednesday, July 23, 2014 = 10:33 AM
To: torsten@lodderstedt.net

Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version = Notification for = draft-hunt-oauth-v2-user-a4c-05.txt
 
 
If we use the token endpoint then a new grant_type = is the best way. 
 
It = sort of overloads code, but that is better than messing with = response_type for the authorization endpoint to change the response from = the token_endpoint.  That is in my opinion a champion bad = idea. 
 
In = discussions developing Connect we decided not to open this can of worms = because no good would come of it. =   
 
The = token_endpoint returns a access token.  Nothing requires scope to = be associates with the token. 
 
That is the best solution.  No change required. =  Better interoperability in my = opinion. 
 
Still = on my way to TO, getting in later = today. 
 
John = B. 
 


Sent from my iPhone


On Jul 23, 2014, at 12:15 = PM, torsten@lodderstedt.net wrote:

The "response type" of the token = endpoint is controlled by the value of the parameter "grant_type". So = there is no need to introduce a new parameter.

wrt to a potential = "no_access_token" grant type. I do not consider this a good idea as it = changes the semantics of the token endpoint (as already pointed out by = Thomas). This endpoint ALWAYS responds with an access token to any grant = type. I therefore would prefer to use another endpoint for the intended = purpose.

regards,
Torsten.

 

Am 23.07.2014 13:04, schrieb Nat = Sakimura:

IMHO, changing = the semantics of "response_type" @ authz endpoint this way is not a good = thing. 
 
Instead, defining a new parameter "response_type" @ token = endpoint, as I described in my previous = message, 
probably is better. At least, it does not change the semantics = of the parameters of RFC6749. 
 
 Nat 
 
2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:
No, I mean response_type=3Dnone and = response_type=3Did_token don't generate a code or access token so you = don't use the Token Endpoint (which is not the same as the = Authentication Endpoint BTW).
With response_type=3Dcode_for_id_token, you get a code and = exchange it for an id_token only, rather than an access_token, so you're = changing the semantics of the Token = Endpoint.
 
I'm = not saying it's a bad thing, just that you can't really compare none and = id_token with = code_for_id_token.
 
On = Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. <jricher@mitre.org> = wrote:
It's only "not = using the token endpoint" because the token endpoint copy-pasted and = renamed the authentication endpoint.
 
 -- Justin
 
On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com> = wrote:

 

Except that these are about not using the Token Endpoint at all, = whereas the current proposal is about the Token Endpoint not returning = an access_token field in the JSON.
 
On = Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:
The response_type "none" is already used in practice, = which returns no access token.  It was accepted by the designated = experts and registered in the IANA OAuth Authorization Endpoint Response = Types registry athttp://www.iana.org/assignments/oauth-parameters/oauth-paramet= ers.xml#endpoint.  The registered "id_token" response type also = returns no access token.
 
So I think the question of whether response types = that result in no access token being returned are acceptable within = OAuth 2.0 is already settled, as a practical matter.  Lots of OAuth = implementations are already using such response = types.
 
           &= nbsp;           &nb= sp;            = ;            &= nbsp;           -- = Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = OfPhil Hunt
Sent: Wednesday, July 23, 2014 = 7:09 AM
To: Nat = Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version = Notification for = draft-hunt-oauth-v2-user-a4c-05.txt
 
Yes. = This is why it has to be discussed in the = IETF.
 
Phil
 
@independentid
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;">phil.hunt@oracle.com
 
 
 
On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com> = wrote:
 
Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be = OAuth. It will break whole bunch of implicit definitions = like: 
 
authorization server
      The server issuing = access tokens to the client after successfully
      = authenticating the resource owner and obtaining = authorization.
 
After = all, OAuth is all about issuing access = tokens. 
 
Also, = I take back my statement on the grant type in my previous = mail. 
 
The = definition of grant and grant_type are = respectively: 
 
grant 
    credential representing the resource owner's = authorization
           =
grant_type
    (string representing the) type of grant sent = to the token endpoint to obtain the access = token
 
Thus, = the grant sent to the token endpoint in this case is still = 'code'. 
 
Response type on the other hand is not so well defined in = RFC6749, but it seems it is representing what is to be returned from the = authorization endpoint. To express what is to be returned from token = endpoint, perhaps defining a new parameter to the token endpoint, which = is a parallel to the response_type to the Authorization Endpoint seems = to be a more symmetric way, though I am not sure at all if that is going = to be OAuth any more. One straw-man is to define a new parameter called = response_type to the token endpoint such = as: 
 
response_type
    OPTIONAL. A string representing what is to be = returned from the token endpoint. 
    
Then define the behavior of the endpoint according = to the values as the parallel to the multi-response type = spec. 
 
Nat
    
 
 
 
2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
The draft is very clear. 

Phil


On Jul 23, 2014, at 0:46, = Nat Sakimura <sakimura@gmail.com> = wrote:

The new grant = type that I was talking about was 
"authorization_code_but_do_not_return_access_nor_refresh_token", = so to speak. 
It does not return anything per se, but an extension can define = something on top of it. 
 
Then, OIDC can define a binding to it so that the = binding only returns ID Token. 
This binding work should be done in OIDF. Should = there be such a grant = type, 
it will be an extremely short = spec. 
 
At = the same time, if any other specification wanted to = define 
other = type of tokens and have it returned from the token = endpoint, 
it = can also use this grant type. 
 
If what you want is to define a new grant type that = returns ID Token only, 
then, I am with Justin. Since "other response than = ID Token" is only 
theoretical, this is a more plausible way forward, I = suppose. 
 
Nat
 
2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:
So the draft would literally turn into:

"The a4c response = type and grant type return an id_token from the token endpoint with no = access token. All parameters and values are defined in = OIDC."

Seems like the perfect mini extension draft for OIDF to = do.

--Justin

/sent from my = phone/

On Jul 22, = 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about = just defining a new grant type in this WG?
>
>
> = 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That = would be nice. However oidc still needs the new grant type in order to = implement the same flow. 
>>
>> = Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura = <sakimura@gmail.com> = wrote:
>>
>>> +1 to = Justin. 
>>>
>>>
>>> 2014-07-22 = 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>= > Errors like these make it clear to me that it would make much more = sense to develop this document in the OpenID Foundation. It should be = something that directly references OpenID Connect Core for all of these = terms instead of redefining them. It's doing authentication, which is = fundamentally what OpenID Connect does on top of OAuth, and I don't see = a good argument for doing this work in this working = group.
>>>>
>>>>  -- = Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 = AM, Thomas Broyer <t.broyer@gmail.com> = wrote:
>>>>
>>>>>
>>>>>=
>>>>>
>>>>> On Mon, Jul 21, 2014 at = 11:52 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:
>>>>>>
>>>>>> Thanks = for your review, Thomas.  The "prompt=3Dconsent" definition being = missing is an editorial error.  It should = be:
>>>>>>
>>>>>> =  
>>>>>>
>>>>>> = consent
>>>>>>
>>>>>> The = Authorization Server SHOULD prompt the End-User for consent before = returning information to the Client. If it cannot obtain consent, it = MUST return an error, typically = consent_required.
>>>>>>
>>>>>> =  
>>>>>>
>>>>>> I'll plan = to add it in the next = draft.
>>>>>
>>>>>
>>>>= > It looks like the consent_required error needs to be defined too, = and you might have forgotten to also import account_selection_required = from OpenID Connect.
>>>>> =  
>>>>>>
>>>>>> =  
>>>>>>
>>>>>> I agree = that there's no difference between a response with multiple "amr" values = that includes "mfa" and one that doesn't.  Unless a clear use case = for why "mfa" is needed can be identified, we can delete it in the next = draft.
>>>>>
>>>>>
>>>>= > Thanks.
>>>>>
>>>>> How about = "pwd" then? I fully understand that I should return "pwd" if the user = authenticated using a password, but what "the service if a client secret = is used" means in the definition for the "pwd" = value?
>>>>>
>>>>> (Nota: I know = you're at IETF-90, I'm ready to wait 'til you come back ;-) = )
>>>>>
>>>>> = --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> = _______________________________________________
>>>>> = 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
>>>= ;>
>>>
>>>
>>>
>>> = --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, = OpenID Foundation
>>> http://nat.sakimura.org/
>>> = @_nat_en
>>>
>>> = _______________________________________________
>>> OAuth = mailing list
>>> OAuth@ietf.org
>>>https://www.ietf.org/mailman/listinfo/oauth
>
>= ;
>
>
> --
> Nat Sakimura (=3Dnat)
> = Chairman, OpenID Foundation
> http://nat.sakimura.org/
> = @_nat_en


 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
 


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

=


 
-- 
Thomas = Broyer
/t=C9=94.ma.b=CA=81wa.je/
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


 
-- 
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/


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

=


 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
 
_______________________________________________
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

=


 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


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

=


 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
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

=


 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
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=_9A9B6A02-01C1-4B09-9CFF-05EC956D8011-- From nobody Thu Jul 24 08:34:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21DC1A0354 for ; Thu, 24 Jul 2014 08:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZ4Blak9aIl7 for ; Thu, 24 Jul 2014 08:33:51 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0FF1A0345 for ; Thu, 24 Jul 2014 08:33:50 -0700 (PDT) Received: from [80.67.16.118] (helo=webmail.df.eu) by smtprelay06.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1XAL1f-0006Xv-7O; Thu, 24 Jul 2014 17:33:47 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_b3eae0205d4325adad271bb64ff666be" Date: Thu, 24 Jul 2014 11:33:46 -0400 From: torsten@lodderstedt.net To: Mike Jones In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADE8ED3@TK5EX14MBXC293.redmond.corp.microsoft.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADE8ED3@TK5EX14MBXC293.redmond.corp.microsoft.com> Message-ID: <99ba4e3014fa2b4526df2e888ab9e38d@lodderstedt.net> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/oBnu3CtG4JRMsouQLEwkyvyvkvw Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 15:33:58 -0000 --=_b3eae0205d4325adad271bb64ff666be Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 I honestely don't understand why you care about omiting the access token on the token endpoint response. You want to omit user consent? Fine, do it. There is no text in the spec that forces an AS to explicitely acquire user consent. Authorization from the resource owner can be acquired in many ways, showing an user consent page is just one option. We authorize DT internal services using a pre-configured policy. So the customer will never (need to) see a consent screen. The same approach can be used in enterprise deployments. regards, Torsten. Am 24.07.2014 10:49, schrieb Mike Jones: > Here's a point of technical discussion for your consideration about the current content of a4c and a possible simplification. > > Having thought about the views expressed about defining the new response type and grant type values, I came up with a possible syntax change that would be much more minimal and accomplish the same thing. Rather than defining a new response type and a new grant type, instead, we could just use the existing code flow and say that it's legal for the token endpoint to return the value "access_token=none". That way, the delta to OAuth 2.0 for the no-access-token case would be very small and the syntax of the response from the token endpoint would be unchanged. > > And while people might initially think that since we'd be defining a distinguished access_token result value we might be stepping on implementations, "none" doesn't meet the minimum entropy requirements in OAuth 2.0, so wouldn't conflict with any conforming implementation. > > Best wishes, > > -- Mike > > FROM: OAuth [mailto:oauth-bounces@ietf.org] ON BEHALF OF Phil Hunt > SENT: Thursday, July 24, 2014 7:34 AM > TO: John Bradley > CC: oauth@ietf.org list > SUBJECT: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt > > +1 > > Phil > > @independentid > > www.independentid.com [3] > > phil.hunt@oracle.com > > On Jul 24, 2014, at 10:25 AM, John Bradley wrote: > > I am not against discussion in the WG. > > I happen to agree with Phil's fundamental premise that some developers are using OAuth in a insecure way to do authentication. > > That raises the question of how to best educate them, and or address technical barriers. > > It is on the second point that people's opinions seem to divide. > > Some people thing that if we have a OAuth flow that eliminates the access token (primarily to avoid asking for consent as I understand it) and just return a id_token from the token endpoint that can be done in a spec short enough to het people to read. The subtext of this is that the Connect specification is too large that it scare people, and they don't find the spec in the first place because it is not a RFC. > > An other common possession is that if you don't want to prompt the user for consent then don't ask for scopes. Twisting the OAuth spec to not return an access token is not OAuth, yes you could use a different endpoint rather than the token endpoint, but that is not OAuth. Connect was careful not to break the OAuth spec. As long as you are willing to take a access token with no scopes (the client needs to understand that there are no attributes one way or another anyway or it will break) then you don't need to change OAuth. You can publish a profile of connect that satisfies the use case. > > I think Mike has largely done that but it might be better being less stingy on references back to the larger spec. > > The questions are do we modify OAuth to not return an access token, and if so how, and if we do is it still OAuth. > > The other largely separable question is do we create confusion in the market and slow the the adoption of identity federation on top of OAuth, or find a way to make this look like a positive alignment of interests around a subset of Connect. > > There are a number of options. > > 1: We can do a profile in the OIDF and publish it as a IETF document. Perhaps the cleanest from an IPR point of view. > > 2:We can do a profile in the OAuth WG referencing connect. > > 3:We can do a AD sponsored profile that is not in the OAuth WG. > > 4:We can do a small spec in OAuth to add response_type to the token endpoint. in combination with 1, 2, or 3 > > I agree that stoping developers doing insecure things needs to be addressed somehow. > > I am not personally convinced that Oauth without access tokens is sensible. > > Looking forward to the meeting:) > > John B. > > On Jul 24, 2014, at 6:52 AM, Brian Campbell wrote: > > I'd note that the reaction at the conference to Ian's statement was overwhelmingly positive. There was a wide range of industry people here - implementers, practitioners, deployers, strategists, etc. - and it seems pretty clear that the "rough consensus" of the industry at large is that a4c is not wanted or needed. > > On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura wrote: > > And here is a quote from Ian's blog. > >> And although the authentication wheel is round, that doesn't mean it isn't without its lumps. First, we do see some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity and should be put down. > >> (Source) http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html [1] > > 2014-07-23 16:53 GMT-04:00 John Bradley : > > I thought I did post this to the list. > > I guess I hit the wrong reply on my phone. > > John B. > Sent from my iPhone > > On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: > > we are two, at least :-) > > Why didn't you post this on the list? > > When will be be arriving? > > Am 23.07.2014 16:39, schrieb John Bradley: > > Ian Glazer mentioned this in his keynote at CIS yesterday. > > His advice was please stop, we are creating confusion and uncertainty. > > We are becoming our own wort enemy. ( my view though Ian may share it) > > Returning just an id_ token from the token endpoint has little real value. > > Something really useful to do would be sorting out channel_id so we can do PoP for id tokens to make them and other cookies secure in the front channel. I think that is a better use of time. > > I may be in the minority opinion on that, it won't be the first time. > > John B. > Sent from my iPhone > > On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt wrote: > > You are right from a theoretical perspective. Practically this was caused by editorial decisions during the creation of the RFC. As far as I remember, there was a definition of the (one) token endpoint response in early versions. No one every considered to NOT respond with an access token from the token endpoint. So one might call it an implicit assumption. > > I'm worried that people get totally confused if an exception is introduced now given the broad adoption of OAuth based on this assumption. > > regards, > > Torsten. > > Am 23.07.2014 um 15:41 schrieb Thomas Broyer : > > Is it said anywhere that ALL grant types MUST use Section 5.1 responses? Each grant type references Section 5.1, and "access token request" is only defined in the context of the defined grant types. Section 2.2 doesn't talk about the request or response format. > > Le 23 juil. 2014 21:32, "Nat Sakimura" a écrit : > > Is it? Apart from the implicit grant that does not use token endpoint, all other grant references section 5.1 for the response, i.e., all shares the same response. > > 2014-07-23 15:18 GMT-04:00 Thomas Broyer : > > I hadn't realized the JSON response that requires the access_token field is defined per grant_type, so I'd be OK to "extend the semantics" as in the current draft. > That was actually my main concern: that the token endpoint mandates access_token; but its actually not the case. > > Le 23 juil. 2014 20:46, "Nat Sakimura" a écrit : > > I agree with John that overloading response_type @ authz endpoint is a bad idea. It completely changes the semantics of this parameter. NOTE: what I was proposing was not this parameter, but a new parameter response_type @ token endpoint. > > I also think overloading grant_type is a bad idea since it changes its semantics. I quote the definition here again: > > grant > > credential representing the resource owner's authorization > > grant_type > > type of grant sent to the token endpoint to obtain the access token > > It is not about controlling what is to be returned from the token endpoint, but the hint to the token endpoint describing the type of credential the endpoint has received. It seems the "control of what is being returned from token endpoint" is just a side effect. > > I am somewhat ambivalent[1] in changing the semantics of token endpoint, but in as much as "text is the king" for a spec., we probably should not change the semantics of it as Torsten points out. If it is ok to change this semantics, I believe defining a new parameter to this endpoint to control the response would be the best way to go. This is what I have described previously. > > Defining a new endpoint to send code to get ID Token and forbidding the use of it against token endpoint would not change the semantics of any existing parameter or endpoint, which is good. However, I doubt if it is not worth doing. What's the point of avoiding access token scoped to UserInfo endpoint after all? Defining a new endpoint for just avoiding the access token for userinfo endpoint seems way too much the heavy wait way and it breaks interoperabiliy: it defeats the purpose of standardization. > > I have started feeling that no change is the best way out. > > Nat > > [1] If instead of saying "Token endpoint - used by the client to exchange an authorization grant for an access token, typically with client authentication", it were saying "Token endpoint - used by the client to exchange an authorization grant for tokens, typically with client authentication", then it would have been OK. It is an expansion of the capability rather than changing the semantics. > > 2014-07-23 13:39 GMT-04:00 Mike Jones : > > You need the alternative response_type value ("code_for_id_token" in the A4C draft) to tell the Authorization Server to return a code to be used with the new grant type, rather than one to use with the "authorization_code" grant type (which is what response_type=code does). > > FROM: OAuth [mailto:oauth-bounces@ietf.org] ON BEHALF OF John Bradley > SENT: Wednesday, July 23, 2014 10:33 AM > TO: torsten@lodderstedt.net > > CC: oauth@ietf.org > SUBJECT: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt > > If we use the token endpoint then a new grant_type is the best way. > > It sort of overloads code, but that is better than messing with response_type for the authorization endpoint to change the response from the token_endpoint. That is in my opinion a champion bad idea. > > In discussions developing Connect we decided not to open this can of worms because no good would come of it. > > The token_endpoint returns a access token. Nothing requires scope to be associates with the token. > > That is the best solution. No change required. Better interoperability in my opinion. > > Still on my way to TO, getting in later today. > > John B. > > Sent from my iPhone > > On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: > > The "response type" of the token endpoint is controlled by the value of the parameter "grant_type". So there is no need to introduce a new parameter. > > wrt to a potential "no_access_token" grant type. I do not consider this a good idea as it changes the semantics of the token endpoint (as already pointed out by Thomas). This endpoint ALWAYS responds with an access token to any grant type. I therefore would prefer to use another endpoint for the intended purpose. > > regards, > Torsten. > > Am 23.07.2014 13:04, schrieb Nat Sakimura: > > IMHO, changing the semantics of "response_type" @ authz endpoint this way is not a good thing. > > Instead, defining a new parameter "response_type" @ token endpoint, as I described in my previous message, > > probably is better. At least, it does not change the semantics of the parameters of RFC6749. > > Nat > > 2014-07-23 12:48 GMT-04:00 Thomas Broyer : > > No, I mean response_type=none and response_type=id_token don't generate a code or access token so you don't use the Token Endpoint (which is not the same as the Authentication Endpoint BTW). > > With response_type=code_for_id_token, you get a code and exchange it for an id_token only, rather than an access_token, so you're changing the semantics of the Token Endpoint. > > I'm not saying it's a bad thing, just that you can't really compare none and id_token with code_for_id_token. > > On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. wrote: > > It's only "not using the token endpoint" because the token endpoint copy-pasted and renamed the authentication endpoint. > > -- Justin > > On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: > > Except that these are about not using the Token Endpoint at all, whereas the current proposal is about the Token Endpoint not returning an access_token field in the JSON. > > On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones wrote: > > The response_type "none" is already used in practice, which returns no access token. It was accepted by the designated experts and registered in the IANA OAuth Authorization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint [4]. The registered "id_token" response type also returns no access token. > > So I think the question of whether response types that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical matter. Lots of OAuth implementations are already using such response types. > > -- Mike > > FROM: OAuth [mailto:oauth-bounces@ietf.org] ON BEHALF OF Phil Hunt > SENT: Wednesday, July 23, 2014 7:09 AM > TO: Nat Sakimura > CC: > SUBJECT: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt > > Yes. This is why it has to be discussed in the IETF. > > Phil > > @independentid > > www.independentid.com [5] > > phil.hunt@oracle.com > > On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: > > Reading back the RFC6749, I am not sure if there is a good way of suppressing access token from the response and still be OAuth. It will break whole bunch of implicit definitions like: > > authorization server > The server issuing access tokens to the client after successfully > authenticating the resource owner and obtaining authorization. > > After all, OAuth is all about issuing access tokens. > > Also, I take back my statement on the grant type in my previous mail. > > The definition of grant and grant_type are respectively: > > grant > > credential representing the resource owner's authorization > > grant_type > > (string representing the) type of grant sent to the token endpoint to obtain the access token > > Thus, the grant sent to the token endpoint in this case is still 'code'. > > Response type on the other hand is not so well defined in RFC6749, but it seems it is representing what is to be returned from the authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the token endpoint, which is a parallel to the response_type to the Authorization Endpoint seems to be a more symmetric way, though I am not sure at all if that is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the token endpoint such as: > > response_type > > OPTIONAL. A string representing what is to be returned from the token endpoint. > > Then define the behavior of the endpoint according to the values as the parallel to the multi-response type spec. > > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html [6] > > Nat > > 2014-07-23 7:21 GMT-04:00 Phil Hunt : > > The draft is very clear. > > Phil > > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: > > The new grant type that I was talking about was > > "authorization_code_but_do_not_return_access_nor_refresh_token", so to speak. > > It does not return anything per se, but an extension can define something on top of it. > > Then, OIDC can define a binding to it so that the binding only returns ID Token. > > This binding work should be done in OIDF. Should there be such a grant type, > > it will be an extremely short spec. > > At the same time, if any other specification wanted to define > > other type of tokens and have it returned from the token endpoint, > > it can also use this grant type. > > If what you want is to define a new grant type that returns ID Token only, > > then, I am with Justin. Since "other response than ID Token" is only > > theoretical, this is a more plausible way forward, I suppose. > > Nat > > 2014-07-22 14:30 GMT-04:00 Justin Richer : > > So the draft would literally turn into: > > "The a4c response type and grant type return an id_token from the token endpoint with no access token. All parameters and values are defined in OIDC." > > Seems like the perfect mini extension draft for OIDF to do. > > --Justin > > /sent from my phone/ > > On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >> >> What about just defining a new grant type in this WG? >> >> >> 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>> >>> That would be nice. However oidc still needs the new grant type in order to implement the same flow. >>> >>> Phil >>> >>> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: >>> >>>> +1 to Justin. >>>> >>>> >>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : >>>>> >>>>> Errors like these make it clear to me that it would make much more sense to develop this document in the OpenID Foundation. It should be something that directly references OpenID Connect Core for all of these terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of OAuth, and I don't see a good argument for doing this work in this working group. >>>>> >>>>> -- Justin >>>>> >>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones wrote: >>>>>>> >>>>>>> Thanks for your review, Thomas. The "prompt=consent" definition being missing is an editorial error. It should be: >>>>>>> >>>>>>> >>>>>>> >>>>>>> consent >>>>>>> >>>>>>> The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client. If it cannot obtain consent, it MUST return an error, typically consent_required. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'll plan to add it in the next draft. >>>>>> >>>>>> >>>>>> It looks like the consent_required error needs to be defined too, and you might have forgotten to also import account_selection_required from OpenID Connect. >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I agree that there's no difference between a response with multiple "amr" values that includes "mfa" and one that doesn't. Unless a clear use case for why "mfa" is needed can be identified, we can delete it in the next draft. >>>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> How about "pwd" then? I fully understand that I should return "pwd" if the user authenticated using a password, but what "the service if a client secret is used" means in the definition for the "pwd" value? >>>>>> >>>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come back ;-) ) >>>>>> >>>>>> -- >>>>>> Thomas Broyer >>>>>> /tÉ”.ma.bÊwa.je/ [7] >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth [2] >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth [2] >>>>> >>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=nat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ [8] >>>> @_nat_en >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth [2] >> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ [8] >> @_nat_en > > -- > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ [8] > @_nat_en > > -- > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ [8] > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [2] > > -- > Thomas Broyer > /tÉ”.ma.bÊwa.je/ [7] > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [2] > > -- > Thomas Broyer > /tÉ”.ma.bÊwa.je/ [7] > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [2] > > -- > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ [8] > @_nat_en > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth [2] > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [2] _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [2] -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ [8] @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [2] -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ [8] @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [2] > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [2] _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [2] -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ [8] @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [2] _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [2] _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [2] Links: ------ [1] http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html [2] https://www.ietf.org/mailman/listinfo/oauth [3] http://www.independentid.com [4] http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint [5] http://www.independentid.com/ [6] http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html [7] http://xn--nna.ma.xn--bwa-xxb.je/ [8] http://nat.sakimura.org/ --=_b3eae0205d4325adad271bb64ff666be Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

I honestely don't understand why you care about omiting the access token= on the token endpoint response. You want to omit user consent? Fine, do it= =2E There is no text in the spec that forces an AS to explicitely acquire u= ser consent. Authorization from the resource owner can be acquired in many = ways, showing an user consent page is just one option. We authorize DT inte= rnal services using a pre-configured policy. So the customer will never (ne= ed to) see a consent screen. The same approach can be used in enterprise de= ployments. 

regards,
Torsten.

Am 24.07.2014 10:49, schrieb Mike Jones:

Here's a point of technical discussion for your c= onsideration about the current content of a4c and a possible simplification= =2E

 

Having thought about the views expressed about de= fining the new response type and grant type values, I came up with a possib= le syntax change that would be much more minimal and accomplish the same th= ing.  Rather than defining a new response type and a new grant type, i= nstead, we could just use the existing code flow and say that it's legal fo= r the token endpoint to return the value "access_token=3Dnone".  That = way, the delta to OAuth 2.0 for the no-access-token case would be very smal= l and the syntax of the response from the token endpoint would be unchanged= =2E

 

And while people might initially think that since= we'd be defining a distinguished access_token result value we might be ste= pping on implementations, "none" doesn't meet the minimum entropy requireme= nts in OAuth 2.0, so wouldn't conflict with any conforming implementation= =2E

 

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

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

 

From: OAuth [mailto:oauth-bounces@ie= tf.org] On Behalf Of Phil Hunt
Sent:= Thursday, July 24, 2014 7:34 AM
To: John Bradley
Cc: oauth@ietf.org list
Subject: R= e: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05= =2Etxt

 

+1

 

Phil

 

@independentid<= /p>

phil.hunt@oracle= =2Ecom

 

 

 

On Jul 24, 2014, at 10:25 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:



I am not against discussion in the WG.

 

I happen to agree with Phil's fundamental premise th= at some developers are using OAuth in a insecure way to do authentication= =2E

 

That raises the question of how to best educate them= , and or address technical barriers.

 

It is on the second point that people's opinions see= m to divide.

 

Some people thing that if we have a OAuth flow that = eliminates the access token (primarily to avoid asking for consent as I und= erstand it) and just return a id_token from the token endpoint that can be = done in a spec short enough to het people to read.   The subtext of th= is is that the Connect specification is too large that it scare people, &nb= sp;and they don't find the spec in the first place because it is not a RFC= =2E

 

An other common possession is that if you don't want= to prompt the user for consent then don't ask for scopes.  Twisting t= he OAuth spec to not return an access token is not OAuth,  yes you cou= ld use a different endpoint rather than the token endpoint, but that is not= OAuth.   Connect was careful not to break the OAuth spec.   &nbs= p;As long as you are willing to take a access token with no scopes (the cli= ent needs to understand that there are no attributes one way or another any= way or it will break) then you don't need to change OAuth.   You can p= ublish a profile of connect that satisfies the use case.<= /p>

 

I think Mike has largely done that but it might be b= etter being less stingy on references back to the larger spec.

 

The questions are do we modify OAuth to not return a= n access token, and if so how,  and if we do is it still OAuth.

 

The other largely separable question is do we create= confusion in the market and slow the the adoption of identity federation o= n top of OAuth, or find a way to make this look like a positive alignment o= f interests around a subset of Connect.

 

There are a number of options.  

1: We can do a profile in the OIDF and publish it as= a IETF document.   Perhaps the cleanest from an IPR point of view.

2:We can do a profile in the OAuth WG referencing co= nnect.

3:We can do a AD sponsored profile that is not in th= e OAuth WG.

4:We can do a small spec in OAuth to add response_ty= pe to the token endpoint.  in combination with 1, 2, or 3

 

I agree that stoping developers doing insecure thing= s needs to be addressed somehow.  

I am not personally convinced that Oauth without acc= ess tokens is sensible.

 

Looking forward to the meeting:)

 

John B.

On Jul 24, 2014, at 6:52 AM, Brian Campbell <bcampbell@pingidentity.com>= ; wrote:



I'd note that the reaction at the conference to Ian'= s statement was overwhelmingly positive. There was a wide range of industry= people here - implementers, practitioners, deployers, strategists, etc. - = and it seems pretty clear that the "rough consensus" of the industry at lar= ge is that a4c is not wanted or needed.

&= nbsp;

On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:

And here is a quote from Ian's blog. 

 

And although the authentication wheel is round, that= doesn't mean it isn't without its lumps. First, we do see some reinventing= the wheel just to reinvent the wheel. OAuth A4C is simply not a fruitful a= ctivity and should be put down.  

 

(Source) http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-mu= sings-on-identity-standards-part-1.html

&= nbsp;

2014-07-23 16:53 GMT-04:00 John Bradley <ve7jtb@ve7jtb.com>:<= /p>

 

I thought I did post this to the list. 

 

I guess I hit the wrong reply on my phone. 
 

John B. 
Sent from my iPhone


On Jul 23, 2= 014, at 4:50 PM, torsten@lodder= stedt.net wrote:

we are two, at least :-)

Why didn't you post this on the list?

When will be be arriving?

Am 23.07.2014 16:39, schrieb John Bradley:

Ian Glazer mentioned this in his keynote at CIS yest= erday. 

 

His advice was please stop,  we are creating co= nfusion and uncertainty. 

 

We are becoming our own wort enemy. ( my view though= Ian may share it)

 

Returning just an id_ token from the token endpoint = has little real value. 

 

Something really useful to do would be sorting out c= hannel_id so we can do PoP for id tokens to make them and other cookies sec= ure in the front channel.   I think that is a better use of time. = ;

 

I may be in the minority opinion on that,  it w= on't be the first time.  



John B. 
Sent from my iPhone=


On Jul 23, 2= 014, at 4:04 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

You are right from a theoretical perspective. Practi= cally this was caused by editorial decisions during the creation of the RFC= =2E As far as I remember, there was a definition of the (one) token endpoin= t response in early versions. No one every considered to NOT respond with a= n access token from the token endpoint. So one might call it an implicit as= sumption.

 

I'm worried that people get totally confused if an e= xception is introduced now given the broad adoption of OAuth based on this = assumption.

 

regards,

Torsten.


Am 23.07.201= 4 um 15:41 schrieb Thomas Broyer <= t.broyer@gmail.com>:

Is it said anywhere that ALL grant types MUST use Section 5.1 responses?= Each grant type references Section 5.1, and "access token request" is only= defined in the context of the defined grant types. Section 2.2 doesn't tal= k about the request or response format.

Le 23 juil. 2014 21:32, "Nat Sakimura" <sakimura@gmail.com> a écrit :<= !-- o ignored -->

Is it? Apart from the implicit grant that does not u= se token endpoint, all other grant references section 5.1 for the response,= i.e., all shares the same response. 

&= nbsp;

2014-07-23 15:18 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:

Le 23 juil. 2014 20:46, "Nat Sakimura" <sakimura@gmail.com> a écrit : =

 

I agree with John that overloading response_type @ a= uthz endpoint is a bad idea. It completely changes the semantics of this pa= rameter. NOTE: what I was proposing was not this parameter, but a new param= eter response_type @ token endpoint. 

 

I also think overloading grant_type is a bad idea si= nce it changes its semantics. I quote the definition here again: 

 

grant 

    credential representing the resource o= wner's authorization

 

grant_type

type of grant sent to the token endpoint to obtain t= he access token

 

It is not about controlling what is to be returned f= rom the token endpoint, but the hint to the token endpoint describing the t= ype of credential the endpoint has received. It seems the "control of what = is being returned from token endpoint"  is just a side effect. 

 

I am somewhat ambivalent[1] in changing the semantic= s of token endpoint, but in as much as "text is the king" for a spec., we p= robably should not change the semantics of it as Torsten points out. If it = is ok to change this semantics, I believe defining a new parameter to this = endpoint to control the response would be the best way to go. This is what = I have described previously. 

 

Defining a new endpoint to send code to get ID Token= and forbidding the use of it against token endpoint would not change the s= emantics of any existing parameter or endpoint, which is good. However, I d= oubt if it is not worth doing. What's the point of avoiding access token sc= oped to UserInfo endpoint after all? Defining a new endpoint for just avoid= ing the access token for userinfo endpoint seems way too much the heavy wai= t way and it breaks interoperabiliy: it defeats the purpose of standardizat= ion. 

 

I have started feeling that no change is the best wa= y out. 

 

Nat

 

[1]  If instead of saying "Token endpoint - use= d by the client to exchange an authorization grant for an access token= , typically with client authentication", it were saying "Token endpoint - u= sed by the client to exchange an authorization grant for tokens, typic= ally with client authentication", then it would have been OK. It is an expa= nsion of the capability rather than changing the semantics.

&= nbsp;

2014-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@microsoft.com>:

You need the alternative response_type value ("code_for_id_token" in the A4C draft) to tell the Authoriz= ation Server to return a code to be used with the new grant type, rather th= an one to use with the "authorization_code" grant type (which is what respo= nse_type=3Dcode does).

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: torsten@lodderstedt.net


Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] N= ew Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

 

 

If we use the token endpoint then a new grant_type is the best= way. 

 

It sort of overloads code, but that is better than messing wit= h response_type for the authorization endpoint to change the response from = the token_endpoint.  That is in my opinion a champion bad idea. <= !-- o ignored -->

 

In discussions developing Connect we decided not to open this = can of worms because no good would come of it.   

The token_endpoint returns a access token.  Nothing requi= res scope to be associates with the token. 

 

That is the best solution.  No change required.  Bet= ter interoperability in my opinion. 

 

Still on my way to TO, getting in later today. 

 

John B. 

 



Sent from my iPhone


On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the value of = the parameter "grant_type". So there is no need to introduce a new paramete= r.

wrt to a potential "no_access_token" grant type. I do not consider this = a good idea as it changes the semantics of the token endpoint (as already p= ointed out by Thomas). This endpoint ALWAYS responds with an access token t= o any grant type. I therefore would prefer to use another endpoint for the = intended purpose.

regards,
Torsten.

 

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type" @ authz endpoi= nt this way is not a good thing. 

 

Instead, defining a new parameter "response_type" @ token endp= oint, as I described in my previous message, 

probably is better. At least, it does not change the semantics= of the parameters of RFC6749. 

 

 Nat 

 

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:

No, I mean response_type=3Dnone and response_type=3Did_token d= on't generate a code or access token so you don't use the Token Endpoint (w= hich is not the same as the Authentication Endpoint BTW).

 

I'm not saying it's a bad thing, just that you can't really co= mpare none and id_token with code_for_id_token.

 

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. <jricher@mitre.org> wrote:

It's only "not using the token endpoint" because the token end= point copy-pasted and renamed the authentication endpoint.

 -- Justin

 

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:<= /p>

 

Except that these are about not using the Token Endpoint at al= l, whereas the current proposal is about the Token Endpoint not returning a= n access_token field in the JSON.

 

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:=

The response_type "none" is already used in pract= ice, which returns no access token.  It was accepted by the designated= experts and registered in the IANA OAuth Authorization Endpoint Response T= ypes registry at http://www.iana.org/assignments/oauth-par= ameters/oauth-parameters.xml#endpoint.  The registered "id_token" = response type also returns no access token.

 

So I think the question of whether response types= that result in no access token being returned are acceptable within OAuth = 2.0 is already settled, as a practical matter.  Lots of OAuth implemen= tations are already using such response types.

 

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
<= span style=3D"font-family: 'Tahoma','sans-serif';">Cc: <= oauth@ietf.org>
Subject: Re:= [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.tx= t

 

Yes. This is why it has to be discussed in the IETF.

 

 

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com> wrote:

 

Reading back the RFC6749, I am not sure if there is a good way= of suppressing access token from the response and still be OAuth. It will = break whole bunch of implicit definitions like: 

 

authorization server
      The server iss= uing access tokens to the client after successfully
    &nb= sp; authenticating the resource owner and obtaining authorization.

 

After all, OAuth is all about issuing access tokens. 

 

Also, I take back my statement on the grant type in my previou= s mail. 

 

The definition of grant and grant_type are respectively: =

 

grant 

    credential representing the resource owner's aut= horization

        &nbs= p;  

grant_type

    (string representing the) type of grant sen= t to the token endpoint to obtain the access token

 

Thus, the grant sent to the token endpoint in this case is sti= ll 'code'. 

 

Response type on the other hand is not so well defined in RFC6= 749, but it seems it is representing what is to be returned from the author= ization endpoint. To express what is to be returned from token endpoint, pe= rhaps defining a new parameter to the token endpoint, which is a parallel t= o the response_type to the Authorization Endpoint seems to be a more symmet= ric way, though I am not sure at all if that is going to be OAuth any more= =2E One straw-man is to define a new parameter called response_type to the = token endpoint such as: 

 

response_type

    OPTIONAL. A string representing what is to be re= turned from the token endpoint. 

    

Then define the behavior of the endpoint according to the valu= es as the parallel to the multi-response type spec. =

 

Nat

    

 

 

 

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:

The draft is very clear. =

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was 

"authorization_code_but_do_not_return_access_nor_refresh_token= ", so to speak. 

It does not return anything per se, but an extension can defin= e something on top of it. 

 

Then, OIDC can define a binding to it so that the binding only= returns ID Token. 

This binding work should be done in OIDF. Should there be such= a grant type, 

it will be an extremely short spec. 

 

At the same time, if any other specification wanted to define&= nbsp;

other type of tokens and have it returned from the token endpo= int, 

it can also use this grant type. 

 

If what you want is to define a new grant type that returns ID= Token only, 

then, I am with Justin. Since "other response than ID Token" i= s only 

theoretical, this is a more plausible way forward, I suppose= =2E 

 

Nat

 

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c r= esponse type and grant type return an id_token from the token endpoint with= no access token. All parameters and values are defined in OIDC."

Seems like the perfect mini extension draft for OIDF to do.

= --Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
= >> That would be nice. However oidc still needs the new grant type i= n order to implement the same flow. 
>>
>> Phi= l
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <= ;sakimura@gmail.com> wrote: >>
>>> +1 to Justin. 
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin = P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear t= o me that it would make much more sense to develop this document in the Ope= nID Foundation. It should be something that directly references OpenID Conn= ect Core for all of these terms instead of redefining them. It's doing auth= entication, which is fundamentally what OpenID Connect does on top of OAuth= , and I don't see a good argument for doing this work in this working group= =2E
>>>>
>>>>  -- Justin
>= ;>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Br= oyer <t.broyer@gmail.com> w= rote:
>>>>
>>>>>
>>>&= gt;>
>>>>>
>>>>> On Mon, Jul 2= 1, 2014 at 11:52 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>&g= t;>
>>>>>> Thanks for your review, Thomas. = The "prompt=3Dconsent" definition being missing is an editorial error.&nbs= p; It should be:
>>>>>>
>>>>>&= gt;  
>>>>>>
>>>>>> co= nsent
>>>>>>
>>>>>> The Aut= horization Server SHOULD prompt the End-User for consent before returning i= nformation to the Client. If it cannot obtain consent, it MUST return an er= ror, typically consent_required.
>>>>>>
>&= gt;>>>>  
>>>>>>
>>>= ;>>> I'll plan to add it in the next draft.
>>>>= >
>>>>>
>>>>> It looks like th= e consent_required error needs to be defined too, and you might have forgot= ten to also import account_selection_required from OpenID Connect.
&g= t;>>>>  
>>>>>>
>>>= >>>  
>>>>>>
>>>>&g= t;> I agree that there's no difference between a response with multiple = "amr" values that includes "mfa" and one that doesn't.  Unless a clear= use case for why "mfa" is needed can be identified, we can delete it in th= e next draft.
>>>>>
>>>>>
&= gt;>>>> Thanks.
>>>>>
>>>&g= t;> How about "pwd" then? I fully understand that I should return "pwd" = if the user authenticated using a password, but what "the service if a clie= nt secret is used" means in the definition for the "pwd" value?
>&= gt;>>>
>>>>> (Nota: I know you're at IETF-90,= I'm ready to wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
&g= t;>>>> /t=C9=94= =2Ema.b=CA=81wa.je/
>>>>> ________________________= _______________________
>>>>> OAuth mailing list
= >>>>> OAuth@ietf.org<= br /> >>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>&= gt;
>>>>
>>>>
>>>> __= _____________________________________________
>>>> OAuth = mailing list
>>>> OAuth= @ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>= ;>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>&g= t; Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
= >>>
>>> ___________________________________________= ____
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listin= fo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
&= gt; http://nat.sakimura.org/
= > @_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 


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



 

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

_______________________________________________
OAuth ma= iling list
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org= /mailman/listinfo/oauth



 

--
Thomas Broyer
= /t=C9=94.ma.b=CA=81wa.je/=


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



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 

_______________________________________________

OAuth mailing list


OAuth@ietf.org=



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

 

 

_______________________________________________
OAuth ma= iling list
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org= /mailman/listinfo/oauth


____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________
OAuth mailing list
OAuth@ietf.org<= /a>
https://ww= w.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<= /a>
https://ww= w.ietf.org/mailman/listinfo/oauth

 

 


____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth

 

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org<= /a>
https://ww= w.ietf.org/mailman/listinfo/oauth

 


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

 

 
--=_b3eae0205d4325adad271bb64ff666be-- From nobody Thu Jul 24 08:50:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA72B1A0393 for ; Thu, 24 Jul 2014 08:50:48 -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 9uP97Ys3PJQw for ; Thu, 24 Jul 2014 08:50:40 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644171A016C for ; Thu, 24 Jul 2014 08:50:39 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gl10so2052985lab.21 for ; Thu, 24 Jul 2014 08:50:37 -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=YKD4K89SJQuz3ckqMWbKjcemEL5bbSlOCzvqiToOQpo=; b=KkG7R5j+i8m49ZsR6gq6rwye+1Eegom7XJF8Q9Hhll4wIZ7T2KvxtzWdjGg0a1J8p+ aaX0pcMShEdp3WWbd8NO5SUKepO3rKoTS9eRM7q179S8/rA2Kc70GyYmgR6MDahm83Zn 6cN/8s0iPNZ7PzBGf42wpYTJtl7daqEjGaaImi3cIhkpPZca2H+f3xj9wPHGptJ7APTW ESQCUCQkpRMGXYh7C/E38nRseT7MDjke7TbXPXgeadr1y9QVT5p6NUyqroFoKjX4PIGf sCqrSMZVLhCppin5wncO+ASFdbRqseCM7gOfPDwa7bvtMTs1YP4Kps9Facu/qWYbVPgV PPmw== MIME-Version: 1.0 X-Received: by 10.152.202.197 with SMTP id kk5mr10475911lac.19.1406217037566; Thu, 24 Jul 2014 08:50:37 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Thu, 24 Jul 2014 08:50:37 -0700 (PDT) In-Reply-To: <45D858DE-6F5E-46D4-828C-9C4C80C3AC2A@oracle.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <9dbf8c7384e341a08334a9ee093697f8@BLUPR03MB309.namprd03.prod.outlook.com> <45D858DE-6F5E-46D4-828C-9C4C80C3AC2A@oracle.com> Date: Thu, 24 Jul 2014 11:50:37 -0400 Message-ID: From: Nat Sakimura To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1135f8dc00593304fef26b4d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/hEj_FB6Nw5_gkRQHDghRAqY07E4 Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 15:50:49 -0000 --001a1135f8dc00593304fef26b4d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2014-07-24 10:30 GMT-04:00 Phil Hunt : > I=E2=80=99m not at all saying that OpenID is bad. If you want an IDP, its= fine. > But if all a client wants is authentication, they think why can=E2=80=99= t I just > use RFC6749? If all what one wants is to build a simple client, there is a standing document called OpenID Connect Basic Client Implementer's Guide 1.0. It is a profile that deals only the 'code' flow. Size-wise, it is 32 pages. The break down are as below approximately: Abstract, Intro, ToC - 2.5 pages Terminology - 1.5 pages Getting ID Token - 9 pages ID Token Validation - 1 page (Seems missing from a4c draft?) Userinfo Endpoint - 7 pages Serializations - 1 page (missing in a4c?) String Operations etc. - 1 pages (missing in a4c?) Considerations - 2 pages (very brief in a4c) References, Acknowledgement - 2 pages Document History etc. - 7 pages The a4c draft is 14 pages long. It will be longer than this in the end as it is missing bunch of things. The comparable portion of the Basic Client Profile is 14 pages or so. Just one data point. --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a1135f8dc00593304fef26b4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2014-07-24 10:30 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
I=E2=80=99m not at all saying that OpenID is bad. If you want an IDP, its f= ine. =C2=A0But if all a client wants is authentication, they think why can= =E2=80=99t I just use RFC6749?

If all what one wants = is to build a simple client, there is a standing document called OpenID Con= nect Basic Client Implementer's Guide 1.0.=C2=A0

It is a pro= file that deals only the 'code' flow.=C2=A0
Size-wise, it is 32 pages. The break down are as below approximate= ly:=C2=A0

Abstract, I= ntro, ToC - 2.5 pages
Terminology - 1.5 pag= es
Getting ID Token - 9 pages
ID Token Validation - 1 page (Seems missing from a4c draft?)
Userinfo Endpoint - 7 pages
Serializations - 1 page (missing in a4c?)
String Operations etc. - 1 pages (missing in a4c= ?)
Considerations - 2 pages (very brief in = a4c)
References, Acknowledgement - 2 pages<= /div>
Document History etc. - 7 pages

The a4c draft is 14 pages long. It will be longer than this in the = end as it is missing bunch of things.=C2=A0
The comparable portion of the Basic Client Profile is 14 pages or so.=C2= =A0

Just one da= ta point.=C2=A0

--
Nat Sakimura (=3Dnat= )
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a1135f8dc00593304fef26b4d-- From nobody Thu Jul 24 08:57:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD611A033D for ; Thu, 24 Jul 2014 08:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Soq7bmvBA9KG for ; Thu, 24 Jul 2014 08:57:49 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B541A03CB for ; Thu, 24 Jul 2014 08:57:42 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6OFvdqt002223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Jul 2014 15:57:40 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s6OFvcSa019810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2014 15:57:39 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s6OFvbSq019719; Thu, 24 Jul 2014 15:57:37 GMT Received: from [25.1.113.147] (/24.114.76.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 Jul 2014 08:57:36 -0700 References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <9dbf8c7384e341a08334a9ee093697f8@BLUPR03MB309.namprd03.prod.outlook.com> <45D858DE-6F5E-46D4-828C-9C4C80C3AC2A@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-DAE09653-A98B-488C-90E1-6BAE3391F742 Content-Transfer-Encoding: 7bit Message-Id: <5BB520C5-EBBB-41A7-8D1A-0ED48DE44E21@oracle.com> X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Thu, 24 Jul 2014 11:57:33 -0400 To: Nat Sakimura X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/pw2zH8jTwpMpJogqj1vN5aFqxPk Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 15:57:51 -0000 --Apple-Mail-DAE09653-A98B-488C-90E1-6BAE3391F742 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Nat, You don't have to convince me.=20 You have to sell all the people not implementing OpenId who think OAuth is s= ufficient.=20 I agree A4C is currently too long. I think Mike and John may be on to someth= ing even better.=20 Phil > On Jul 24, 2014, at 11:50, Nat Sakimura wrote: >=20 >=20 > 2014-07-24 10:30 GMT-04:00 Phil Hunt : >> I=E2=80=99m not at all saying that OpenID is bad. If you want an IDP, its= fine. But if all a client wants is authentication, they think why can=E2=80= =99t I just use RFC6749? >=20 > If all what one wants is to build a simple client, there is a standing doc= ument called OpenID Connect Basic Client Implementer's Guide 1.0.=20 >=20 > It is a profile that deals only the 'code' flow.=20 > Size-wise, it is 32 pages. The break down are as below approximately:=20 >=20 > Abstract, Intro, ToC - 2.5 pages > Terminology - 1.5 pages > Getting ID Token - 9 pages > ID Token Validation - 1 page (Seems missing from a4c draft?) > Userinfo Endpoint - 7 pages > Serializations - 1 page (missing in a4c?) > String Operations etc. - 1 pages (missing in a4c?) > Considerations - 2 pages (very brief in a4c) > References, Acknowledgement - 2 pages > Document History etc. - 7 pages >=20 > The a4c draft is 14 pages long. It will be longer than this in the end as i= t is missing bunch of things.=20 > The comparable portion of the Basic Client Profile is 14 pages or so.=20 >=20 > Just one data point.=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail-DAE09653-A98B-488C-90E1-6BAE3391F742 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Nat,

You don'= t have to convince me. 

You have to sell all t= he people not implementing OpenId who think OAuth is sufficient. 
=

I agree A4C is currently too long. I think Mike and John= may be on to something even better. 

Phil

On Jul 2= 4, 2014, at 11:50, Nat Sakimura <sa= kimura@gmail.com> wrote:

=

2= 014-07-24 10:30 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=
I=E2=80=99m not at all saying that OpenID is bad. If you want an IDP, its fi= ne.  But if all a client wants is authentication, they think why can=E2= =80=99t I just use RFC6749?

If all what one wants is t= o build a simple client, there is a standing document called OpenID Connect B= asic Client Implementer's Guide 1.0. 

It is a prof= ile that deals only the 'code' flow. 
S= ize-wise, it is 32 pages. The break down are as below approximately: 

Abstract, In= tro, ToC - 2.5 pages
Terminology - 1.5 pages=
Getting ID Token - 9 pages
ID Token Validation - 1 page (Seems missing from a4c draft?)
Userinfo Endpoint - 7 pages
Serializations - 1 page (missing in a4c?)
String Operations etc. - 1 pages (missing in a4c?= )
Considerations - 2 pages (very brief in a4= c)
References, Acknowledgement - 2 pages
Document History etc. - 7 pages

The a4c draft is 14 pages long. It will be longer than this in the en= d as it is missing bunch of things. 
Th= e comparable portion of the Basic Client Profile is 14 pages or so. 

Just one dat= a point. 

--
Nat Sakimura (=3Dnat)<= div>Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
= --Apple-Mail-DAE09653-A98B-488C-90E1-6BAE3391F742-- From nobody Thu Jul 24 09:32:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F1C1A01E7 for ; Thu, 24 Jul 2014 09:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.912 X-Spam-Level: X-Spam-Status: No, score=-4.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 1ALGIZQX_tEa for ; Thu, 24 Jul 2014 09:32:41 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD841A0282 for ; Thu, 24 Jul 2014 09:32:41 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 06A0A28180 for ; Thu, 24 Jul 2014 09:32:38 -0700 (PDT) Received: from EX13-CAS-005.vmware.com (EX13-CAS-005.vmware.com [10.113.191.55]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 02B2018E53 for ; Thu, 24 Jul 2014 09:32:38 -0700 (PDT) Received: from EX13-MBX-025.vmware.com (10.113.191.45) by EX13-MBX-012.vmware.com (10.113.191.32) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 24 Jul 2014 09:32:32 -0700 Received: from [192.168.0.24] (10.113.160.246) by EX13-MBX-025.vmware.com (10.113.191.45) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 24 Jul 2014 09:32:14 -0700 Message-ID: <53D1350C.7020908@vmware.com> Date: Thu, 24 Jul 2014 09:32:12 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <9dbf8c7384e341a08334a9ee093697f8@BLUPR03MB309.namprd03.prod.outlook.com> <45D858DE-6F5E-46D4-828C-9C4C80C3AC2A@oracle.com> <5BB520C5-EBBB-41A7-8D1A-0ED48DE44E21@oracle.com> In-Reply-To: <5BB520C5-EBBB-41A7-8D1A-0ED48DE44E21@oracle.com> Content-Type: multipart/alternative; boundary="------------090702080807020509010009" X-Originating-IP: [10.113.160.246] X-ClientProxiedBy: EX13-CAS-013.vmware.com (10.113.191.65) To EX13-MBX-025.vmware.com (10.113.191.45) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/pP_22lWwUpbpxSHJNacHeISZUXY Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 16:32:47 -0000 --------------090702080807020509010009 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Phil, I thoroughly enjoy working with you whenever I can, and I really liked your work on SCIM, but from the perspective of the web developers I work with, I have a few concerns about what you wrote: 1. Developer experience and usability of the standards You keep mentioning that web developers are demanding the new spec because they don't understand/use OAuth2 properly. I estimate that most people on this thread know web developers that they can claim to represent -- so I'd rather hear what you think and why. From my reading, the rough consensus appears to be that everyone agrees that OIDC and OAuth2 could be improved, and better developer experience is one of those improvements. However, after reading your draft (basically because of Ian's presentation) it does appear to me that some minor changes/additions to OIDC would suffice. Personally, I don't see the requirement to NOT return an access token as significant or even desirable in most use cases. I'd rather focus on the one point in 30 years where the industry has agreed on a core identity stack (OAuth2/OIDC/SCIM) and move on to adoption and improved developer education/experience. 2. Standards bodies, corporations, and IPR issues John's suggestion to link OIDC and an IETF draft for the minor additions sounds reasonable as well, but, from my limited recent involvement, it brings up a MUCH more concerning issue. I've always associated IETF as the primary example of successful standards that are not overly influenced by useless specs and large corporations. Interestingly, overlarge, unnecessary specs and large corporations tend to go together. Is the real issue here that some large corporations object to OIDF IPR policy or weren't in the initial bandwagon -- so they must drive another spec. Really? Is this just WS-Fed vs SAML again? Personally, I'd hate to see the great individualistic, running-code, rough-consensus body of the IETF do unnecessary (and market confusing) work to satisfy a few lawyers' comfort zone. --Dale On 07/24/2014 08:57 AM, Phil Hunt wrote: > Nat, > > You don't have to convince me. > > You have to sell all the people not implementing OpenId who think > OAuth is sufficient. > > I agree A4C is currently too long. I think Mike and John may be on to > something even better. > > Phil > > On Jul 24, 2014, at 11:50, Nat Sakimura > wrote: > >> >> 2014-07-24 10:30 GMT-04:00 Phil Hunt > >: >> >> I’m not at all saying that OpenID is bad. If you want an IDP, its >> fine. But if all a client wants is authentication, they think >> why can’t I just use RFC6749? >> >> >> If all what one wants is to build a simple client, there is a >> standing document called OpenID Connect Basic Client Implementer's >> Guide 1.0. >> >> It is a profile that deals only the 'code' flow. >> Size-wise, it is 32 pages. The break down are as below approximately: >> >> Abstract, Intro, ToC - 2.5 pages >> Terminology - 1.5 pages >> Getting ID Token - 9 pages >> ID Token Validation - 1 page (Seems missing from a4c draft?) >> Userinfo Endpoint - 7 pages >> Serializations - 1 page (missing in a4c?) >> String Operations etc. - 1 pages (missing in a4c?) >> Considerations - 2 pages (very brief in a4c) >> References, Acknowledgement - 2 pages >> Document History etc. - 7 pages >> >> The a4c draft is 14 pages long. It will be longer than this in the >> end as it is missing bunch of things. >> The comparable portion of the Basic Client Profile is 14 pages or so. >> >> Just one data point. >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> >> @_nat_en > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/oauth&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=tZSv3T50ptdrF5VJeQfPow%3D%3D%0A&m=%2FHNlBS8t0nyksP6%2BTpUnVRbQACmczqcvThYucu1ZQ2w%3D%0A&s=a9405b77aec5d4156f53d2912a337b972dbbc4ba7ebd16121efbd325de47c65a --------------090702080807020509010009 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Phil,

I thoroughly enjoy working with you whenever I can, and I really liked your work on SCIM, but from the perspective of the web developers I work with, I have a few concerns about what you wrote:

1. Developer experience and usability of the standards

You keep mentioning that web developers are demanding the new spec because they don't understand/use OAuth2 properly. I estimate that most people on this thread know web developers that they can claim to represent -- so I'd rather hear what you think and why.

From my reading, the rough consensus appears to be that everyone agrees that OIDC and OAuth2 could be improved, and better developer experience is one of those improvements.

However, after reading your draft (basically because of Ian's presentation) it does appear to me that some minor changes/additions to OIDC would suffice. Personally, I don't see the requirement to NOT return an access token as significant or even desirable in most use cases.

I'd rather focus on the one point in 30 years where the industry has agreed on a core identity stack (OAuth2/OIDC/SCIM) and move on to adoption and improved developer education/experience.

2. Standards bodies, corporations, and IPR issues

John's suggestion to link OIDC and an IETF draft for the minor additions sounds reasonable as well, but, from my limited recent involvement, it brings up a MUCH more concerning issue. I've always associated IETF as the primary example of successful standards that are not overly influenced by useless specs and large corporations. Interestingly, overlarge, unnecessary specs and large corporations tend to go together.

Is the real issue here that some large corporations object to OIDF IPR policy or weren't in the initial bandwagon -- so they must drive another spec. Really? Is this just WS-Fed vs SAML again?

Personally, I'd hate to see the great individualistic, running-code, rough-consensus body of the IETF do unnecessary (and market confusing) work to satisfy a few lawyers' comfort zone.

--Dale


On 07/24/2014 08:57 AM, Phil Hunt wrote:
Nat,

You don't have to convince me. 

You have to sell all the people not implementing OpenId who think OAuth is sufficient. 

I agree A4C is currently too long. I think Mike and John may be on to something even better. 

Phil

On Jul 24, 2014, at 11:50, Nat Sakimura <sakimura@gmail.com> wrote:


2014-07-24 10:30 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
I’m not at all saying that OpenID is bad. If you want an IDP, its fine.  But if all a client wants is authentication, they think why can’t I just use RFC6749?

If all what one wants is to build a simple client, there is a standing document called OpenID Connect Basic Client Implementer's Guide 1.0. 

It is a profile that deals only the 'code' flow. 
Size-wise, it is 32 pages. The break down are as below approximately: 

Abstract, Intro, ToC - 2.5 pages
Terminology - 1.5 pages
Getting ID Token - 9 pages
ID Token Validation - 1 page (Seems missing from a4c draft?)
Userinfo Endpoint - 7 pages
Serializations - 1 page (missing in a4c?)
String Operations etc. - 1 pages (missing in a4c?)
Considerations - 2 pages (very brief in a4c)
References, Acknowledgement - 2 pages
Document History etc. - 7 pages

The a4c draft is 14 pages long. It will be longer than this in the end as it is missing bunch of things. 
The comparable portion of the Basic Client Profile is 14 pages or so. 

Just one data point. 

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/oauth&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=tZSv3T50ptdrF5VJeQfPow%3D%3D%0A&m=%2FHNlBS8t0nyksP6%2BTpUnVRbQACmczqcvThYucu1ZQ2w%3D%0A&s=a9405b77aec5d4156f53d2912a337b972dbbc4ba7ebd16121efbd325de47c65a

--------------090702080807020509010009-- From nobody Thu Jul 24 09:47:32 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B67F1A0439 for ; Thu, 24 Jul 2014 09:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 VZVY55pvyBIq for ; Thu, 24 Jul 2014 09:47:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 236BD1A0176 for ; Thu, 24 Jul 2014 09:47:20 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6OGlJHp027791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 24 Jul 2014 12:47:19 -0400 Received: from [10.10.53.242] (vpn-53-242.rdu2.redhat.com [10.10.53.242]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6OGlIgL024824 for ; Thu, 24 Jul 2014 12:47:18 -0400 Message-ID: <53D13898.9060701@redhat.com> Date: Thu, 24 Jul 2014 12:47:20 -0400 From: Bill Burke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: oauth@ietf.org References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <9dbf8c7384e341a08334a9ee093697f8@BLUPR03MB309.namprd03.prod.outlook.com> <45D858DE-6F5E-46D4-828C-9C4C80C3AC2A@oracle.com> In-Reply-To: <45D858DE-6F5E-46D4-828C-9C4C80C3AC2A@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/pOfHs6SeWRIE3hlomplZYrGm__s Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 16:47:29 -0000 On 7/24/2014 10:30 AM, Phil Hunt wrote: > Horseshit. > Horseshit to your horseshit. > Ian failed to mention that we’re responding to bad use of 6749 by > assuming receipt of access token == authentication. > > The OAuth WG is not creating a new feature and we are not re-inventing > here. If anyone is, one could argue that would be OpenID —> at least in > the minds of the web developers. They don’t get why they have to use > OpenID at all. Doesn’t OAuth already do this??? > Maybe from your perspective. From my perspective in the Java community at least, security for REST services is a cluster fuck. Developers in the Java community are looking for answers. For most of them, security is an afterthought done at the last minute. They think OAuth will solve their RESTful security issues only to find that OAuth is just a framework not a protocol and delegates many difficult issues to underlying implementations. > The working group is responding to an issue that the market has ALREADY > chosen to do all by itself without the presence of any additional > specification like A4C or for that matter OpenID. > > The market is doing this because_ they are under the false assumption > that OAuth is doing authentication_ and that receipt of the access token > IS authentication. It is unbelievable how many developers think OAuth > stands for Open Authentication. The specifications are clear. Yet, the > problem persists. > > If a developer already thinks they have a solution that is good enough, > why would they go to another standards organization? They aren’t even > looking for an OpenID. They think they already have THE solution! Which > is precisely why OpenID can’t address the issue by itself! OpenID as an > authenticator *is* re-invenention. Yes, OpenID as an IDP provider > standard is its own innovation (re-inventing SAML and many many other > protocols of the past), but within the realm of OAuth, yes it is > innovation in my opinion.. > Ridiculous statements. How does anything above justify the existence of A4C. If developers already have their solutions, why would they give a shit about A4C? > But keep in mind that these developers do NOT want an IDP architecture. > Says who? You? And what does an IDP architecture have to do with Open ID Connect or its use with OIDC? You can still use a vanilla OAuth2 client library with an IDP that implements Open ID Connect. > My point in producing the original draft was to show how simple the > correction could be — a few pages of clarifying text. > > Since OpenID has been proposed as the simple solution, let me point out > why it is not for these developers: it is a specification that > incredibly complicates OAuth: > > * OpenID adds 6 response types to OAuth’s 2 > * OpenID adds 6 errors to OAuth’s 4 > * OpenID doubles the number of parameters > * OpenID’s core specification is approximately NINETY THREE pages to > 6749’s 76 pages > Like many have said over and over, A4C is already covered by OpenID. The subset of A4C is already legal under OpenID. Besides, you actually think web developers care about reading some IETF specification? From my 20+ years of developing middleware, developers do not read specifications! They read the documentation and examples of the frameworks that implement these specifications. > > I’m not at all saying that OpenID is bad. If you want an IDP, its fine. > But if all a client wants is authentication, they think why can’t I > just use RFC6749? > Yup. Like I said before. If the IDP implements OpenID Connect, there is nothing stopping a client just using vanilla OAuth. > The people in the CIS audience were not aware of the facts, so of > course, they cheered against what appears to be a fork. That’s after all > how it was presented. In fact, Ian’s presentation sounds horribly > trivial and insensitive in its handling of this case. > > The point is, NOT responding to this issue does not mean it goes away. > It gets worse. The market is already choosing to use OAuth for > authentication. And OpenID Connect is OAUTH! -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From nobody Thu Jul 24 10:15:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ADC1A064A for ; Thu, 24 Jul 2014 10:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 uEnvjUA7uoGd for ; Thu, 24 Jul 2014 10:15:49 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3321A0444 for ; Thu, 24 Jul 2014 10:15:49 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6OHFm09012572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Jul 2014 17:15:49 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6OHFl43012726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2014 17:15:48 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6OHFlkl007059; Thu, 24 Jul 2014 17:15:47 GMT Received: from [31.133.145.238] (/31.133.145.238) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 Jul 2014 10:15:47 -0700 References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <9dbf8c7384e341a08334a9ee093697f8@BLUPR03MB309.namprd03.prod.outlook.com> <45D858DE-6F5E-46D4-828C-9C4C80C3AC2A@oracle.com! > <53D13898.9060701@redhat.com> Mime-Version: 1.0 (1.0) In-Reply-To: <53D13898.9060701@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <42DC0AD2-FF37-405B-B72B-DCD39DAF379F@oracle.com> X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Thu, 24 Jul 2014 13:15:48 -0400 To: Bill Burke X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/GQ-O-mxewXAoJAEcFNBiJY3GOWo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 17:15:51 -0000 My comments are not motivated in any way by my employer. The probably wish l= ike you I would drop it.=20 I am simply reporting what I see in the wild.=20 Phil > On Jul 24, 2014, at 12:47, Bill Burke wrote: >=20 >=20 >=20 >> On 7/24/2014 10:30 AM, Phil Hunt wrote: >> Horseshit. >=20 > Horseshit to your horseshit. >=20 >> Ian failed to mention that we=E2=80=99re responding to bad use of 6749 by= >> assuming receipt of access token =3D=3D authentication. >>=20 >> The OAuth WG is not creating a new feature and we are not re-inventing >> here. If anyone is, one could argue that would be OpenID =E2=80=94> at le= ast in >> the minds of the web developers. They don=E2=80=99t get why they have to u= se >> OpenID at all. Doesn=E2=80=99t OAuth already do this??? >=20 > Maybe from your perspective. =46rom my perspective in the Java community a= t least, security for REST services is a cluster fuck. Developers in the Ja= va community are looking for answers. For most of them, security is an afte= rthought done at the last minute. They think OAuth will solve their RESTful= security issues only to find that OAuth is just a framework not a protocol a= nd delegates many difficult issues to underlying implementations. >=20 >> The working group is responding to an issue that the market has ALREADY >> chosen to do all by itself without the presence of any additional >> specification like A4C or for that matter OpenID. >>=20 >> The market is doing this because_ they are under the false assumption >> that OAuth is doing authentication_ and that receipt of the access token >> IS authentication. It is unbelievable how many developers think OAuth >> stands for Open Authentication. The specifications are clear. Yet, the >> problem persists. >>=20 >> If a developer already thinks they have a solution that is good enough, >> why would they go to another standards organization? They aren=E2=80=99t e= ven >> looking for an OpenID. They think they already have THE solution! Which >> is precisely why OpenID can=E2=80=99t address the issue by itself! OpenI= D as an >> authenticator *is* re-invenention. Yes, OpenID as an IDP provider >> standard is its own innovation (re-inventing SAML and many many other >> protocols of the past), but within the realm of OAuth, yes it is >> innovation in my opinion.. >=20 > Ridiculous statements. How does anything above justify the existence of A= 4C. If developers already have their solutions, why would they give a shit a= bout A4C? >=20 >> But keep in mind that these developers do NOT want an IDP architecture. >=20 > Says who? You? And what does an IDP architecture have to do with Open ID= Connect or its use with OIDC? You can still use a vanilla OAuth2 client li= brary with an IDP that implements Open ID Connect. >=20 >> My point in producing the original draft was to show how simple the >> correction could be =E2=80=94 a few pages of clarifying text. >>=20 >> Since OpenID has been proposed as the simple solution, let me point out >> why it is not for these developers: it is a specification that >> incredibly complicates OAuth: >>=20 >> * OpenID adds 6 response types to OAuth=E2=80=99s 2 >> * OpenID adds 6 errors to OAuth=E2=80=99s 4 >> * OpenID doubles the number of parameters >> * OpenID=E2=80=99s core specification is approximately NINETY THREE page= s to >> 6749=E2=80=99s 76 pages >=20 > Like many have said over and over, A4C is already covered by OpenID. The s= ubset of A4C is already legal under OpenID. >=20 >=20 > Besides, you actually think web developers care about reading some IETF sp= ecification? =46rom my 20+ years of developing middleware, developers do no= t read specifications! They read the documentation and examples of the fram= eworks that implement these specifications. >=20 >>=20 >> I=E2=80=99m not at all saying that OpenID is bad. If you want an IDP, its= fine. >> But if all a client wants is authentication, they think why can=E2=80=99= t I >> just use RFC6749? >=20 > Yup. Like I said before. If the IDP implements OpenID Connect, there is n= othing stopping a client just using vanilla OAuth. >=20 >> The people in the CIS audience were not aware of the facts, so of >> course, they cheered against what appears to be a fork. That=E2=80=99s af= ter all >> how it was presented. In fact, Ian=E2=80=99s presentation sounds horribly= >> trivial and insensitive in its handling of this case. >>=20 >> The point is, NOT responding to this issue does not mean it goes away. >> It gets worse. The market is already choosing to use OAuth for >> authentication. >=20 > And OpenID Connect is OAUTH! >=20 >=20 > --=20 > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Jul 24 10:18:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B987C1A0ABC for ; Thu, 24 Jul 2014 10:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 lm1flaGrl_OM for ; Thu, 24 Jul 2014 10:18:39 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0781A0AB1 for ; Thu, 24 Jul 2014 10:18:27 -0700 (PDT) X-AuditID: 1209190f-f79f86d0000061c8-8b-53d13fe1d7b6 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 5E.BB.25032.2EF31D35; Thu, 24 Jul 2014 13:18:26 -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 s6OHIPGB031011; Thu, 24 Jul 2014 13:18:25 -0400 Received: from [31.133.167.164] (dhcp-a7a4.meeting.ietf.org [31.133.167.164]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6OHIJPT025045 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Jul 2014 13:18:22 -0400 Message-Id: <201407241718.s6OHIJPT025045@outgoing.mit.edu> Date: Thu, 24 Jul 2014 13:18:17 -0400 From: Justin Richer To: torsten@lodderstedt.net MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixG6nrvvI/mKwwYk2Dou90z6xWJx8+4rN 4tWxpywOzB5Llvxk8jjW08/q0brjL3sAcxSXTUpqTmZZapG+XQJXxo5u1oIzJ5kqtuyqbGCc cJCpi5GTQ0LARGLZzrNQtpjEhXvr2boYuTiEBGYzSaz5dZMFwtnIKDH96XooZz+TRPOaB8wg LbwCVhLftz1lBbFZBFQlDl3oYwGxhQWiJCbt/cgOYrMBxeevvAW2QkRAWmL610OMIDazQLxE 07IpTBBzBCVOznzCAhFXl/gz7xIzhK0oMaX7IfsERr5ZSMpmISmbhaRsASPzKkbZlNwq3dzE zJzi1GTd4uTEvLzUIl0TvdzMEr3UlNJNjKBw5JTk38H47aDSIUYBDkYlHt6OveeDhVgTy4or cw8xSnIwKYnypttcDBbiS8pPqcxILM6ILyrNSS0+xCjBwawkwqtqDZTjTUmsrEotyodJSXOw KInzvrW2ChYSSE8sSc1OTS1ILYLJynBwKEnwPrEDahQsSk1PrUjLzClBSDNxcIIM5wEa3gdS w1tckJhbnJkOkT/FqCglzusGkhAASWSU5sH1wtLFK0ZxoFeEebeAVPEAUw1c9yugwUxAg18l nAcZXJKIkJJqYOTWuLx6f+XT/2Yahxo6CnbV71ibUeskuvWO34Rt0w5WcM/4Hl7ktPXWhhMW sUkffzs32Yecy3F4ccPO232FhijP8hcHnxWxJVzvVqqcI669VdvybtKBMz3RC83W5CvcjEzb YNI01Xnh5ACDXSkpLz9GnSx7NVHw2q5X16TPvfYMl620ivO4c1OJpTgj0VCLuag4EQBhMaSi 8gIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/x-jk0zfJdJMcmSgNfELm0rdmDq8 Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 17:18:44 -0000 V2UgZG8gdGhlIHNhbWUgdGhpbmcgd2l0aCB3ZWxsLWtub3duIChpZSwgd2hpdGVsaXN0ZWQpIGNs aWVudCBhcHBzIGZvciBib3RoIE9JREMgYW5kIHZhbmlsbGEgT0F1dGguIFRoZXNlIGFyZSBjYXNl cyB3aGVyZSB0aGUgY29uc2VudCBkZWNpc2lvbiBpc24ndCBpbiB0aGUgdXNlcnMnIGhhbmRzLCBz byB3ZSBkb24ndCBhc2sgdGhlbS4gQnV0IGhlcmUncyB0aGUgdGhpbmc6IHRoYXQncyBhbiBpbXBs ZW1lbnRhdGlvbiBkZXRhaWwgb2Ygb3VyIEFTIHBvbGljeSwgdGhlIGNsaWVudHMgYXJlIGFsbCBq dXN0IGRvaW5nIE9BdXRoIHNvIHRoZSBkZXZlbG9wZXJzIGRvbid0IG5vdGljZSwgYW5kIHRoZSB1 c2VycyAoZm9yIHRoZSBtb3N0IHBhcnQpIGRvbid0IGV2ZW4gcmVhbGl6ZSB0aGV5J3JlIGdvaW5n IHRocm91Z2ggYW4gT0F1dGggZmxvdy4gQ291cGxlZCB3aXRoIFNTTywgdGhpbmdzICJqdXN0IHdv cmsiIGZvciB0aGVzZSBjYXNlcywgZm9yIGJvdGggdXNlcnMgYW5kIGRldmVsb3BlcnMuCgpBbmQg SSB3b3VsZCBmdXJ0aGVyIGFyZ3VlIHRoYXQgaWYgaXQncyBhbiB1bmtub3duIG9yIHVudHJ1c3Rl ZCBjbGllbnQsIEkgKndhbnQqIHVzZXIgY29uc2VudCwgZXZlbiBmb3IganVzdCBhdXRoZW50aWNh dGlvbi4gVE9GVSB3b3JrcyBncmVhdCBoZXJlLgoKLS1KdXN0aW4KCi9zZW50IGZyb20gbXkgcGhv bmUvCgpPbiBKdWwgMjQsIDIwMTQgMTE6MzMgQU0sIHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IHdy b3RlOgo+Cj4gSSBob25lc3RlbHkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgeW91IGNhcmUgYWJvdXQg b21pdGluZyB0aGUgYWNjZXNzIHRva2VuIG9uIHRoZSB0b2tlbiBlbmRwb2ludCByZXNwb25zZS4g WW91IHdhbnQgdG8gb21pdCB1c2VyIGNvbnNlbnQ/IEZpbmUsIGRvIGl0LiBUaGVyZSBpcyBubyB0 ZXh0IGluIHRoZSBzcGVjIHRoYXQgZm9yY2VzIGFuIEFTIHRvIGV4cGxpY2l0ZWx5IGFjcXVpcmUg dXNlciBjb25zZW50LiBBdXRob3JpemF0aW9uIGZyb20gdGhlIHJlc291cmNlIG93bmVyIGNhbiBi ZSBhY3F1aXJlZCBpbiBtYW55IHdheXMsIHNob3dpbmcgYW4gdXNlciBjb25zZW50IHBhZ2UgaXMg anVzdCBvbmUgb3B0aW9uLiBXZSBhdXRob3JpemUgRFQgaW50ZXJuYWwgc2VydmljZXMgdXNpbmcg YSBwcmUtY29uZmlndXJlZCBwb2xpY3kuIFNvIHRoZSBjdXN0b21lciB3aWxsIG5ldmVyIChuZWVk IHRvKSBzZWUgYSBjb25zZW50IHNjcmVlbi4gVGhlIHNhbWUgYXBwcm9hY2ggY2FuIGJlIHVzZWQg aW4gZW50ZXJwcmlzZSBkZXBsb3ltZW50cy7CoAo+Cj4gcmVnYXJkcywKPiBUb3JzdGVuLgo+Cj4g QW0gMjQuMDcuMjAxNCAxMDo0OSwgc2NocmllYiBNaWtlIEpvbmVzOgo+Pgo+PiBIZXJlJ3MgYSBw b2ludCBvZiB0ZWNobmljYWwgZGlzY3Vzc2lvbiBmb3IgeW91ciBjb25zaWRlcmF0aW9uIGFib3V0 IHRoZSBjdXJyZW50IGNvbnRlbnQgb2YgYTRjIGFuZCBhIHBvc3NpYmxlIHNpbXBsaWZpY2F0aW9u Lgo+Pgo+PiDCoAo+Pgo+PiBIYXZpbmcgdGhvdWdodCBhYm91dCB0aGUgdmlld3MgZXhwcmVzc2Vk IGFib3V0IGRlZmluaW5nIHRoZSBuZXcgcmVzcG9uc2UgdHlwZSBhbmQgZ3JhbnQgdHlwZSB2YWx1 ZXMsIEkgY2FtZSB1cCB3aXRoIGEgcG9zc2libGUgc3ludGF4IGNoYW5nZSB0aGF0IHdvdWxkIGJl IG11Y2ggbW9yZSBtaW5pbWFsIGFuZCBhY2NvbXBsaXNoIHRoZSBzYW1lIHRoaW5nLsKgIFJhdGhl ciB0aGFuIGRlZmluaW5nIGEgbmV3IHJlc3BvbnNlIHR5cGUgYW5kIGEgbmV3IGdyYW50IHR5cGUs IGluc3RlYWQsIHdlIGNvdWxkIGp1c3QgdXNlIHRoZSBleGlzdGluZyBjb2RlIGZsb3cgYW5kIHNh eSB0aGF0IGl0J3MgbGVnYWwgZm9yIHRoZSB0b2tlbiBlbmRwb2ludCB0byByZXR1cm4gdGhlIHZh bHVlICJhY2Nlc3NfdG9rZW49bm9uZSIuwqAgVGhhdCB3YXksIHRoZSBkZWx0YSB0byBPQXV0aCAy LjAgZm9yIHRoZSBuby1hY2Nlc3MtdG9rZW4gY2FzZSB3b3VsZCBiZSB2ZXJ5IHNtYWxsIGFuZCB0 aGUgc3ludGF4IG9mIHRoZSByZXNwb25zZSBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCB3b3VsZCBi ZSB1bmNoYW5nZWQuCj4+Cj4+IMKgCj4+Cj4+IEFuZCB3aGlsZSBwZW9wbGUgbWlnaHQgaW5pdGlh bGx5IHRoaW5rIHRoYXQgc2luY2Ugd2UnZCBiZSBkZWZpbmluZyBhIGRpc3Rpbmd1aXNoZWQgYWNj ZXNzX3Rva2VuIHJlc3VsdCB2YWx1ZSB3ZSBtaWdodCBiZSBzdGVwcGluZyBvbiBpbXBsZW1lbnRh dGlvbnMsICJub25lIiBkb2Vzbid0IG1lZXQgdGhlIG1pbmltdW0gZW50cm9weSByZXF1aXJlbWVu dHMgaW4gT0F1dGggMi4wLCBzbyB3b3VsZG4ndCBjb25mbGljdCB3aXRoIGFueSBjb25mb3JtaW5n IGltcGxlbWVudGF0aW9uLgo+Pgo+PiDCoAo+Pgo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEJlc3Qgd2lzaGVzLAo+Pgo+PiDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIC0tIE1pa2UKPj4KPj4gwqAKPj4KPj4gRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGhpbCBIdW50Cj4+IFNlbnQ6IFRodXJzZGF5LCBK dWx5IDI0LCAyMDE0IDc6MzQgQU0KPj4gVG86IEpvaG4gQnJhZGxleQo+PiBDYzogb2F1dGhAaWV0 Zi5vcmcgbGlzdAo+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0Cj4+Cj4+IMKgCj4+ Cj4+ICsxCj4+Cj4+IMKgCj4+Cj4+IFBoaWwKPj4KPj4gwqAKPj4KPj4gQGluZGVwZW5kZW50aWQK Pj4KPj4gd3d3LmluZGVwZW5kZW50aWQuY29tCj4+Cj4+IHBoaWwuaHVudEBvcmFjbGUuY29tCj4+ Cj4+IMKgCj4+Cj4+IMKgCj4+Cj4+IMKgCj4+Cj4+IE9uIEp1bCAyNCwgMjAxNCwgYXQgMTA6MjUg QU0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+IHdyb3RlOgo+Pgo+Pgo+Pgo+PiBJ IGFtIG5vdCBhZ2FpbnN0IGRpc2N1c3Npb24gaW4gdGhlIFdHLgo+Pgo+PiDCoAo+Pgo+PiBJIGhh cHBlbiB0byBhZ3JlZSB3aXRoIFBoaWwncyBmdW5kYW1lbnRhbCBwcmVtaXNlIHRoYXQgc29tZSBk ZXZlbG9wZXJzIGFyZSB1c2luZyBPQXV0aCBpbiBhIGluc2VjdXJlIHdheSB0byBkbyBhdXRoZW50 aWNhdGlvbi4KPj4KPj4gwqAKPj4KPj4gVGhhdCByYWlzZXMgdGhlIHF1ZXN0aW9uIG9mIGhvdyB0 byBiZXN0IGVkdWNhdGUgdGhlbSwgYW5kIG9yIGFkZHJlc3MgdGVjaG5pY2FsIGJhcnJpZXJzLgo+ Pgo+PiDCoAo+Pgo+PiBJdCBpcyBvbiB0aGUgc2Vjb25kIHBvaW50IHRoYXQgcGVvcGxlJ3Mgb3Bp bmlvbnMgc2VlbSB0byBkaXZpZGUuCj4+Cj4+IMKgCj4+Cj4+IFNvbWUgcGVvcGxlIHRoaW5nIHRo YXQgaWYgd2UgaGF2ZSBhIE9BdXRoIGZsb3cgdGhhdCBlbGltaW5hdGVzIHRoZSBhY2Nlc3MgdG9r ZW4gKHByaW1hcmlseSB0byBhdm9pZCBhc2tpbmcgZm9yIGNvbnNlbnQgYXMgSSB1bmRlcnN0YW5k IGl0KSBhbmQganVzdCByZXR1cm4gYSBpZF90b2tlbiBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCB0 aGF0IGNhbiBiZSBkb25lIGluIGEgc3BlYyBzaG9ydCBlbm91Z2ggdG8gaGV0IHBlb3BsZSB0byBy ZWFkLiDCoCBUaGUgc3VidGV4dCBvZiB0aGlzIGlzIHRoYXQgdGhlIENvbm5lY3Qgc3BlY2lmaWNh dGlvbiBpcyB0b28gbGFyZ2UgdGhhdCBpdCBzY2FyZSBwZW9wbGUsIMKgYW5kIHRoZXkgZG9uJ3Qg ZmluZCB0aGUgc3BlYyBpbiB0aGUgZmlyc3QgcGxhY2UgYmVjYXVzZSBpdCBpcyBub3QgYSBSRkMu Cj4+Cj4+IMKgCj4+Cj4+IEFuIG90aGVyIGNvbW1vbiBwb3NzZXNzaW9uIGlzIHRoYXQgaWYgeW91 IGRvbid0IHdhbnQgdG8gcHJvbXB0IHRoZSB1c2VyIGZvciBjb25zZW50IHRoZW4gZG9uJ3QgYXNr IGZvciBzY29wZXMuIMKgVHdpc3RpbmcgdGhlIE9BdXRoIHNwZWMgdG8gbm90IHJldHVybiBhbiBh Y2Nlc3MgdG9rZW4gaXMgbm90IE9BdXRoLCDCoHllcyB5b3UgY291bGQgdXNlIGEgZGlmZmVyZW50 IGVuZHBvaW50IHJhdGhlciB0aGFuIHRoZSB0b2tlbiBlbmRwb2ludCwgYnV0IHRoYXQgaXMgbm90 IE9BdXRoLiDCoCBDb25uZWN0IHdhcyBjYXJlZnVsIG5vdCB0byBicmVhayB0aGUgT0F1dGggc3Bl Yy4gwqAgwqBBcyBsb25nIGFzIHlvdSBhcmUgd2lsbGluZyB0byB0YWtlIGEgYWNjZXNzIHRva2Vu IHdpdGggbm8gc2NvcGVzICh0aGUgY2xpZW50IG5lZWRzIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGVy ZSBhcmUgbm8gYXR0cmlidXRlcyBvbmUgd2F5IG9yIGFub3RoZXIgYW55d2F5IG9yIGl0IHdpbGwg YnJlYWspIHRoZW4geW91IGRvbid0IG5lZWQgdG8gY2hhbmdlIE9BdXRoLiDCoCBZb3UgY2FuIHB1 Ymxpc2ggYSBwcm9maWxlIG9mIGNvbm5lY3QgdGhhdCBzYXRpc2ZpZXMgdGhlIHVzZSBjYXNlLgo+ Pgo+PiDCoAo+Pgo+PiBJIHRoaW5rIE1pa2UgaGFzIGxhcmdlbHkgZG9uZSB0aGF0IGJ1dCBpdCBt aWdodCBiZSBiZXR0ZXIgYmVpbmcgbGVzcyBzdGluZ3kgb24gcmVmZXJlbmNlcyBiYWNrIHRvIHRo ZSBsYXJnZXIgc3BlYy4KPj4KPj4gwqAKPj4KPj4gVGhlIHF1ZXN0aW9ucyBhcmUgZG8gd2UgbW9k aWZ5IE9BdXRoIHRvIG5vdCByZXR1cm4gYW4gYWNjZXNzIHRva2VuLCBhbmQgaWYgc28gaG93LCDC oGFuZCBpZiB3ZSBkbyBpcyBpdCBzdGlsbCBPQXV0aC4KPj4KPj4gwqAKPj4KPj4gVGhlIG90aGVy IGxhcmdlbHkgc2VwYXJhYmxlIHF1ZXN0aW9uIGlzIGRvIHdlIGNyZWF0ZSBjb25mdXNpb24gaW4g dGhlIG1hcmtldCBhbmQgc2xvdyB0aGUgdGhlIGFkb3B0aW9uIG9mIGlkZW50aXR5IGZlZGVyYXRp b24gb24gdG9wIG9mIE9BdXRoLCBvciBmaW5kIGEgd2F5IHRvIG1ha2UgdGhpcyBsb29rIGxpa2Ug YSBwb3NpdGl2ZSBhbGlnbm1lbnQgb2YgaW50ZXJlc3RzIGFyb3VuZCBhIHN1YnNldCBvZiBDb25u ZWN0Lgo+Pgo+PiDCoAo+Pgo+PiBUaGVyZSBhcmUgYSBudW1iZXIgb2Ygb3B0aW9ucy4gwqAKPj4K Pj4gMTogV2UgY2FuIGRvIGEgcHJvZmlsZSBpbiB0aGUgT0lERiBhbmQgcHVibGlzaCBpdCBhcyBh IElFVEYgZG9jdW1lbnQuIMKgIFBlcmhhcHMgdGhlIGNsZWFuZXN0IGZyb20gYW4gSVBSIHBvaW50 IG9mIHZpZXcuCj4+Cj4+IDI6V2UgY2FuIGRvIGEgcHJvZmlsZSBpbiB0aGUgT0F1dGggV0cgcmVm ZXJlbmNpbmcgY29ubmVjdC4KPj4KPj4gMzpXZSBjYW4gZG8gYSBBRCBzcG9uc29yZWQgcHJvZmls ZSB0aGF0IGlzIG5vdCBpbiB0aGUgT0F1dGggV0cuCj4+Cj4+IDQ6V2UgY2FuIGRvIGEgc21hbGwg c3BlYyBpbiBPQXV0aCB0byBhZGQgcmVzcG9uc2VfdHlwZSB0byB0aGUgdG9rZW4gZW5kcG9pbnQu IMKgaW4gY29tYmluYXRpb24gd2l0aCAxLCAyLCBvciAzCj4+Cj4+IMKgCj4+Cj4+IEkgYWdyZWUg dGhhdCBzdG9waW5nIGRldmVsb3BlcnMgZG9pbmcgaW5zZWN1cmUgdGhpbmdzIG5lZWRzIHRvIGJl IGFkZHJlc3NlZCBzb21laG93LiDCoAo+Pgo+PiBJIGFtIG5vdCBwZXJzb25hbGx5IGNvbnZpbmNl ZCB0aGF0IE9hdXRoIHdpdGhvdXQgYWNjZXNzIHRva2VucyBpcyBzZW5zaWJsZS4KPj4KPj4gwqAK Pj4KPj4gTG9va2luZyBmb3J3YXJkIHRvIHRoZSBtZWV0aW5nOikKPj4KPj4gwqAKPj4KPj4gSm9o biBCLgo+Pgo+PiBPbiBKdWwgMjQsIDIwMTQsIGF0IDY6NTIgQU0sIEJyaWFuIENhbXBiZWxsIDxi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4gd3JvdGU6Cj4+Cj4+Cj4+Cj4+IEknZCBub3RlIHRo YXQgdGhlIHJlYWN0aW9uIGF0IHRoZSBjb25mZXJlbmNlIHRvIElhbidzIHN0YXRlbWVudCB3YXMg b3ZlcndoZWxtaW5nbHkgcG9zaXRpdmUuIFRoZXJlIHdhcyBhIHdpZGUgcmFuZ2Ugb2YgaW5kdXN0 cnkgcGVvcGxlIGhlcmUgLSBpbXBsZW1lbnRlcnMsIHByYWN0aXRpb25lcnMsIGRlcGxveWVycywg c3RyYXRlZ2lzdHMsIGV0Yy4gLSBhbmQgaXQgc2VlbXMgcHJldHR5IGNsZWFyIHRoYXQgdGhlICJy b3VnaCBjb25zZW5zdXMiIG9mIHRoZSBpbmR1c3RyeSBhdCBsYXJnZSBpcyB0aGF0IGE0YyBpcyBu b3Qgd2FudGVkIG9yIG5lZWRlZC4KPj4KPj4gwqAKPj4KPj4gT24gVGh1LCBKdWwgMjQsIDIwMTQg YXQgNToyOSBBTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+IHdyb3RlOgo+Pgo+ PiBBbmQgaGVyZSBpcyBhIHF1b3RlIGZyb20gSWFuJ3MgYmxvZy7CoAo+Pgo+PiDCoAo+Pj4KPj4+ IEFuZCBhbHRob3VnaCB0aGUgYXV0aGVudGljYXRpb24gd2hlZWwgaXMgcm91bmQsIHRoYXQgZG9l c24ndCBtZWFuIGl0IGlzbid0IHdpdGhvdXQgaXRzIGx1bXBzLiBGaXJzdCwgd2UgZG8gc2VlIHNv bWUgcmVpbnZlbnRpbmcgdGhlIHdoZWVsIGp1c3QgdG8gcmVpbnZlbnQgdGhlIHdoZWVsLiBPQXV0 aCBBNEMgaXMgc2ltcGx5IG5vdCBhIGZydWl0ZnVsIGFjdGl2aXR5IGFuZCBzaG91bGQgYmUgcHV0 IGRvd24uIMKgCj4+Cj4+IMKgCj4+Pgo+Pj4gKFNvdXJjZSkgaHR0cDovL3d3dy50dWVzZGF5bmln aHQub3JnLzIwMTQvMDcvMjMvZG8td2UtaGF2ZS1hLXJvdW5kLXdoZWVsLXlldC1tdXNpbmdzLW9u LWlkZW50aXR5LXN0YW5kYXJkcy1wYXJ0LTEuaHRtbAo+Pgo+PiDCoAo+Pgo+PiAyMDE0LTA3LTIz IDE2OjUzIEdNVC0wNDowMCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPjoKPj4+Cj4+ PiDCoAo+Pj4KPj4+IEkgdGhvdWdodCBJIGRpZCBwb3N0IHRoaXMgdG8gdGhlIGxpc3QuwqAKPj4+ Cj4+PiDCoAo+Pj4KPj4+IEkgZ3Vlc3MgSSBoaXQgdGhlIHdyb25nIHJlcGx5IG9uIG15IHBob25l LsKgCj4+PiDCoAo+Pj4KPj4+IEpvaG4gQi7CoAo+Pj4gU2VudCBmcm9tIG15IGlQaG9uZQo+Pj4K Pj4+Cj4+PiBPbiBKdWwgMjMsIDIwMTQsIGF0IDQ6NTAgUE0sIHRvcnN0ZW5AbG9kZGVyc3RlZHQu bmV0IHdyb3RlOgo+Pj4+Cj4+Pj4gd2UgYXJlIHR3bywgYXQgbGVhc3QgOi0pCj4+Pj4KPj4+PiBX aHkgZGlkbid0IHlvdSBwb3N0IHRoaXMgb24gdGhlIGxpc3Q/Cj4+Pj4KPj4+PiBXaGVuIHdpbGwg YmUgYmUgYXJyaXZpbmc/Cj4+Pj4KPj4+PiBBbSAyMy4wNy4yMDE0IDE2OjM5LCBzY2hyaWViIEpv aG4gQnJhZGxleToKPj4+Pj4KPj4+Pj4gSWFuIEdsYXplciBtZW50aW9uZWQgdGhpcyBpbiBoaXMg a2V5bm90ZSBhdCBDSVMgeWVzdGVyZGF5LsKgCj4+Pj4+Cj4+Pj4+IMKgCj4+Pj4+Cj4+Pj4+IEhp cyBhZHZpY2Ugd2FzIHBsZWFzZSBzdG9wLCDCoHdlIGFyZSBjcmVhdGluZyBjb25mdXNpb24gYW5k IHVuY2VydGFpbnR5LsKgCj4+Pj4+Cj4+Pj4+IMKgCj4+Pj4+Cj4+Pj4+IFdlIGFyZSBiZWNvbWlu ZyBvdXIgb3duIHdvcnQgZW5lbXkuICggbXkgdmlldyB0aG91Z2ggSWFuIG1heSBzaGFyZSBpdCkK Pj4+Pj4KPj4+Pj4gwqAKPj4+Pj4KPj4+Pj4gUmV0dXJuaW5nIGp1c3QgYW4gaWRfIHRva2VuIGZy b20gdGhlIHRva2VuIGVuZHBvaW50IGhhcyBsaXR0bGUgcmVhbCB2YWx1ZS7CoAo+Pj4+Pgo+Pj4+ PiDCoAo+Pj4+Pgo+Pj4+PiBTb21ldGhpbmcgcmVhbGx5IHVzZWZ1bCB0byBkbyB3b3VsZCBiZSBz b3J0aW5nIG91dCBjaGFubmVsX2lkIHNvIHdlIGNhbiBkbyBQb1AgZm9yIGlkIHRva2VucyB0byBt YWtlIHRoZW0gYW5kIG90aGVyIGNvb2tpZXMgc2VjdXJlIGluIHRoZSBmcm9udCBjaGFubmVsLiDC oCBJIHRoaW5rIHRoYXQgaXMgYSBiZXR0ZXIgdXNlIG9mIHRpbWUuwqAKPj4+Pj4KPj4+Pj4gwqAK Pj4+Pj4KPj4+Pj4gSSBtYXkgYmUgaW4gdGhlIG1pbm9yaXR5IG9waW5pb24gb24gdGhhdCwgwqBp dCB3b24ndCBiZSB0aGUgZmlyc3QgdGltZS4gwqAKPj4+Pj4KPj4+Pj4KPj4+Pj4KPj4+Pj4gSm9o biBCLsKgCj4+Pj4+IFNlbnQgZnJvbSBteSBpUGhvbmUKPj4+Pj4KPj4+Pj4KPj4+Pj4gT24gSnVs IDIzLCAyMDE0LCBhdCA0OjA0IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldD4gd3JvdGU6Cj4+Pj4+Pgo+Pj4+Pj4gWW91IGFyZSByaWdodCBmcm9tIGEgdGhl b3JldGljYWwgcGVyc3BlY3RpdmUuIFByYWN0aWNhbGx5IHRoaXMgd2FzIGNhdXNlZCBieSBlZGl0 b3JpYWwgZGVjaXNpb25zIGR1cmluZyB0aGUgY3JlYXRpb24gb2YgdGhlIFJGQy4gQXMgZmFyIGFz IEkgcmVtZW1iZXIsIHRoZXJlIHdhcyBhIGRlZmluaXRpb24gb2YgdGhlIChvbmUpIHRva2VuIGVu ZHBvaW50IHJlc3BvbnNlIGluIGVhcmx5IHZlcnNpb25zLiBObyBvbmUgZXZlcnkgY29uc2lkZXJl ZCB0byBOT1QgcmVzcG9uZCB3aXRoIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSB0b2tlbiBlbmRw b2ludC4gU28gb25lIG1pZ2h0IGNhbGwgaXQgYW4gaW1wbGljaXQgYXNzdW1wdGlvbi4KPj4+Pj4+ Cj4+Pj4+PiDCoAo+Pj4+Pj4KPj4+Pj4+IEknbSB3b3JyaWVkIHRoYXQgcGVvcGxlIGdldCB0b3Rh bGx5IGNvbmZ1c2VkIGlmIGFuIGV4Y2VwdGlvbiBpcyBpbnRyb2R1Y2VkIG5vdyBnaXZlbiB0aGUg YnJvYWQgYWRvcHRpb24gb2YgT0F1dGggYmFzZWQgb24gdGhpcyBhc3N1bXB0aW9uLgo+Pj4+Pj4K Pj4+Pj4+IMKgCj4+Pj4+Pgo+Pj4+Pj4gcmVnYXJkcywKPj4+Pj4+Cj4+Pj4+PiBUb3JzdGVuLgo+ Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiBBbSAyMy4wNy4yMDE0IHVtIDE1OjQxIHNjaHJpZWIgVGhvbWFz IEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPjoKPj4+Pj4+Pgo+Pj4+Pj4+IElzIGl0IHNhaWQg YW55d2hlcmUgdGhhdCBBTEwgZ3JhbnQgdHlwZXMgTVVTVCB1c2UgU2VjdGlvbiA1LjEgcmVzcG9u c2VzPyBFYWNoIGdyYW50IHR5cGUgcmVmZXJlbmNlcyBTZWN0aW9uIDUuMSwgYW5kICJhY2Nlc3Mg dG9rZW4gcmVxdWVzdCIgaXMgb25seSBkZWZpbmVkIGluIHRoZSBjb250ZXh0IG9mIHRoZSBkZWZp bmVkIGdyYW50IHR5cGVzLiBTZWN0aW9uIDIuMiBkb2Vzbid0IHRhbGsgYWJvdXQgdGhlIHJlcXVl c3Qgb3IgcmVzcG9uc2UgZm9ybWF0Lgo+Pj4+Pj4+Cj4+Pj4+Pj4gTGUgMjMganVpbC4gMjAxNCAy MTozMiwgIk5hdCBTYWtpbXVyYSIgPHNha2ltdXJhQGdtYWlsLmNvbT4gYSDDqWNyaXQgOgo+Pj4+ Pj4+Cj4+Pj4+Pj4gSXMgaXQ/IEFwYXJ0IGZyb20gdGhlIGltcGxpY2l0IGdyYW50IHRoYXQgZG9l cyBub3QgdXNlIHRva2VuIGVuZHBvaW50LCBhbGwgb3RoZXIgZ3JhbnQgcmVmZXJlbmNlcyBzZWN0 aW9uIDUuMSBmb3IgdGhlIHJlc3BvbnNlLCBpLmUuLCBhbGwgc2hhcmVzIHRoZSBzYW1lIHJlc3Bv bnNlLsKgCj4+Pj4+Pj4KPj4+Pj4+PiDCoAo+Pj4+Pj4+Cj4+Pj4+Pj4gMjAxNC0wNy0yMyAxNTox OCBHTVQtMDQ6MDAgVGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPjoKPj4+Pj4+Pgo+ Pj4+Pj4+IEkgaGFkbid0IHJlYWxpemVkIHRoZSBKU09OIHJlc3BvbnNlIHRoYXQgcmVxdWlyZXMg dGhlIGFjY2Vzc190b2tlbiBmaWVsZCBpcyBkZWZpbmVkIHBlciBncmFudF90eXBlLCBzbyBJJ2Qg YmUgT0sgdG8gImV4dGVuZCB0aGUgc2VtYW50aWNzIiBhcyBpbiB0aGUgY3VycmVudCBkcmFmdC4K Pj4+Pj4+PiBUaGF0IHdhcyBhY3R1YWxseSBteSBtYWluIGNvbmNlcm46IHRoYXQgdGhlIHRva2Vu IGVuZHBvaW50IG1hbmRhdGVzIGFjY2Vzc190b2tlbjsgYnV0IGl0cyBhY3R1YWxseSBub3QgdGhl IGNhc2UuCj4+Pj4+Pj4KPj4+Pj4+PiBMZSAyMyBqdWlsLiAyMDE0IDIwOjQ2LCAiTmF0IFNha2lt dXJhIiA8c2FraW11cmFAZ21haWwuY29tPiBhIMOpY3JpdCA6Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+IMKg Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+IEkgYWdyZWUgd2l0aCBKb2huIHRoYXQgb3ZlcmxvYWRpbmcgcmVz cG9uc2VfdHlwZSBAIGF1dGh6IGVuZHBvaW50IGlzIGEgYmFkIGlkZWEuIEl0IGNvbXBsZXRlbHkg Y2hhbmdlcyB0aGUgc2VtYW50aWNzIG9mIHRoaXMgcGFyYW1ldGVyLiBOT1RFOiB3aGF0IEkgd2Fz IHByb3Bvc2luZyB3YXMgbm90IHRoaXMgcGFyYW1ldGVyLCBidXQgYSBuZXcgcGFyYW1ldGVyIHJl c3BvbnNlX3R5cGUgQCB0b2tlbiBlbmRwb2ludC7CoAo+Pj4+Pj4+Pgo+Pj4+Pj4+PiDCoAo+Pj4+ Pj4+Pgo+Pj4+Pj4+PiBJIGFsc28gdGhpbmsgb3ZlcmxvYWRpbmcgZ3JhbnRfdHlwZSBpcyBhIGJh ZCBpZGVhIHNpbmNlIGl0IGNoYW5nZXMgaXRzIHNlbWFudGljcy4gSSBxdW90ZSB0aGUgZGVmaW5p dGlvbiBoZXJlIGFnYWluOsKgCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Cj4+Pj4+Pj4+ IGdyYW50wqAKPj4+Pj4+Pj4KPj4+Pj4+Pj4gwqAgwqAgY3JlZGVudGlhbCByZXByZXNlbnRpbmcg dGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiDCoAo+ Pj4+Pj4+Pgo+Pj4+Pj4+PiBncmFudF90eXBlCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IHR5cGUgb2YgZ3Jh bnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW4K Pj4+Pj4+Pj4KPj4+Pj4+Pj4gwqAKPj4+Pj4+Pj4KPj4+Pj4+Pj4gSXQgaXMgbm90IGFib3V0IGNv bnRyb2xsaW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQs IGJ1dCB0aGUgaGludCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgZGVzY3JpYmluZyB0aGUgdHlwZSBv ZiBjcmVkZW50aWFsIHRoZSBlbmRwb2ludCBoYXMgcmVjZWl2ZWQuIEl0IHNlZW1zIHRoZSAiY29u dHJvbCBvZiB3aGF0IGlzIGJlaW5nIHJldHVybmVkIGZyb20gdG9rZW4gZW5kcG9pbnQiIMKgaXMg anVzdCBhIHNpZGUgZWZmZWN0LsKgCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Cj4+Pj4+ Pj4+IEkgYW0gc29tZXdoYXQgYW1iaXZhbGVudFsxXSBpbiBjaGFuZ2luZyB0aGUgc2VtYW50aWNz IG9mIHRva2VuIGVuZHBvaW50LCBidXQgaW4gYXMgbXVjaCBhcyAidGV4dCBpcyB0aGUga2luZyIg Zm9yIGEgc3BlYy4sIHdlIHByb2JhYmx5IHNob3VsZCBub3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mg b2YgaXQgYXMgVG9yc3RlbiBwb2ludHMgb3V0LiBJZiBpdCBpcyBvayB0byBjaGFuZ2UgdGhpcyBz ZW1hbnRpY3MsIEkgYmVsaWV2ZSBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXIgdG8gdGhpcyBlbmRw b2ludCB0byBjb250cm9sIHRoZSByZXNwb25zZSB3b3VsZCBiZSB0aGUgYmVzdCB3YXkgdG8gZ28u IFRoaXMgaXMgd2hhdCBJIGhhdmUgZGVzY3JpYmVkIHByZXZpb3VzbHkuwqAKPj4+Pj4+Pj4KPj4+ Pj4+Pj4gwqAKPj4+Pj4+Pj4KPj4+Pj4+Pj4gRGVmaW5pbmcgYSBuZXcgZW5kcG9pbnQgdG8gc2Vu ZCBjb2RlIHRvIGdldCBJRCBUb2tlbiBhbmQgZm9yYmlkZGluZyB0aGUgdXNlIG9mIGl0IGFnYWlu c3QgdG9rZW4gZW5kcG9pbnQgd291bGQgbm90IGNoYW5nZSB0aGUgc2VtYW50aWNzIG9mIGFueSBl eGlzdGluZyBwYXJhbWV0ZXIgb3IgZW5kcG9pbnQsIHdoaWNoIGlzIGdvb2QuIEhvd2V2ZXIsIEkg ZG91YnQgaWYgaXQgaXMgbm90IHdvcnRoIGRvaW5nLiBXaGF0J3MgdGhlIHBvaW50IG9mIGF2b2lk aW5nIGFjY2VzcyB0b2tlbiBzY29wZWQgdG8gVXNlckluZm8gZW5kcG9pbnQgYWZ0ZXIgYWxsPyBE ZWZpbmluZyBhIG5ldyBlbmRwb2ludCBmb3IganVzdCBhdm9pZGluZyB0aGUgYWNjZXNzIHRva2Vu IGZvciB1c2VyaW5mbyBlbmRwb2ludCBzZWVtcyB3YXkgdG9vIG11Y2ggdGhlIGhlYXZ5IHdhaXQg d2F5IGFuZCBpdCBicmVha3MgaW50ZXJvcGVyYWJpbGl5OiBpdCBkZWZlYXRzIHRoZSBwdXJwb3Nl IG9mIHN0YW5kYXJkaXphdGlvbi7CoAo+Pj4+Pj4+Pgo+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pgo+Pj4+ Pj4+PiBJIGhhdmUgc3RhcnRlZCBmZWVsaW5nIHRoYXQgbm8gY2hhbmdlIGlzIHRoZSBiZXN0IHdh eSBvdXQuwqAKPj4+Pj4+Pj4KPj4+Pj4+Pj4gwqAKPj4+Pj4+Pj4KPj4+Pj4+Pj4gTmF0Cj4+Pj4+ Pj4+Cj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IFsxXSDCoElmIGluc3RlYWQgb2Ygc2F5 aW5nICJUb2tlbiBlbmRwb2ludCAtIHVzZWQgYnkgdGhlIGNsaWVudCB0byBleGNoYW5nZSBhbiBh dXRob3JpemF0aW9uwqBncmFudCBmb3IgYW4gYWNjZXNzIHRva2VuLCB0eXBpY2FsbHkgd2l0aCBj bGllbnQgYXV0aGVudGljYXRpb24iLCBpdCB3ZXJlIHNheWluZyAiVG9rZW4gZW5kcG9pbnQgLSB1 c2VkIGJ5IHRoZSBjbGllbnQgdG8gZXhjaGFuZ2UgYW4gYXV0aG9yaXphdGlvbsKgZ3JhbnQgZm9y IHRva2VucywgdHlwaWNhbGx5IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0aW9uIiwgdGhlbiBpdCB3 b3VsZCBoYXZlIGJlZW4gT0suIEl0IGlzIGFuIGV4cGFuc2lvbiBvZiB0aGUgY2FwYWJpbGl0eSBy YXRoZXIgdGhhbiBjaGFuZ2luZyB0aGUgc2VtYW50aWNzLgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiDCoAo+ Pj4+Pj4+Pgo+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pgo+Pj4+Pj4+PiAyMDE0LTA3LTIzIDEzOjM5IEdN VC0wNDowMCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Ogo+Pj4+Pj4+ Pgo+Pj4+Pj4+PiBZb3UgbmVlZCB0aGUgYWx0ZXJuYXRpdmUgcmVzcG9uc2VfdHlwZSB2YWx1ZSAo ImNvZGVfZm9yX2lkX3Rva2VuIiBpbiB0aGUgQTRDIGRyYWZ0KSB0byB0ZWxsIHRoZSBBdXRob3Jp emF0aW9uIFNlcnZlciB0byByZXR1cm4gYSBjb2RlIHRvIGJlIHVzZWQgd2l0aCB0aGUgbmV3IGdy YW50IHR5cGUsIHJhdGhlciB0aGFuIG9uZSB0byB1c2Ugd2l0aCB0aGUgImF1dGhvcml6YXRpb25f Y29kZSIgZ3JhbnQgdHlwZSAod2hpY2ggaXMgd2hhdCByZXNwb25zZV90eXBlPWNvZGUgZG9lcyku Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IEZyb206IE9BdXRoIFttYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleQo+Pj4+ Pj4+PiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQgMTA6MzMgQU0KPj4+Pj4+Pj4gVG86 IHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+IENjOiBv YXV0aEBpZXRmLm9yZwo+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0Cj4+ Pj4+Pj4+Cj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Cj4+Pj4+Pj4+ IElmIHdlIHVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgdGhlbiBhIG5ldyBncmFudF90eXBlIGlzIHRo ZSBiZXN0IHdheS7CoAo+Pj4+Pj4+Pgo+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBJdCBz b3J0IG9mIG92ZXJsb2FkcyBjb2RlLCBidXQgdGhhdCBpcyBiZXR0ZXIgdGhhbiBtZXNzaW5nIHdp dGggcmVzcG9uc2VfdHlwZSBmb3IgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgdG8gY2hhbmdl IHRoZSByZXNwb25zZSBmcm9tIHRoZSB0b2tlbl9lbmRwb2ludC4gwqBUaGF0IGlzIGluIG15IG9w aW5pb24gYSBjaGFtcGlvbiBiYWQgaWRlYS7CoAo+Pj4+Pj4+Pgo+Pj4+Pj4+PiDCoAo+Pj4+Pj4+ Pgo+Pj4+Pj4+PiBJbiBkaXNjdXNzaW9ucyBkZXZlbG9waW5nIENvbm5lY3Qgd2UgZGVjaWRlZCBu b3QgdG8gb3BlbiB0aGlzIGNhbiBvZiB3b3JtcyBiZWNhdXNlIG5vIGdvb2Qgd291bGQgY29tZSBv ZiBpdC4gwqDCoAo+Pj4+Pj4+Pgo+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBUaGUgdG9r ZW5fZW5kcG9pbnQgcmV0dXJucyBhIGFjY2VzcyB0b2tlbi4gwqBOb3RoaW5nIHJlcXVpcmVzIHNj b3BlIHRvIGJlIGFzc29jaWF0ZXMgd2l0aCB0aGUgdG9rZW4uwqAKPj4+Pj4+Pj4KPj4+Pj4+Pj4g wqAKPj4+Pj4+Pj4KPj4+Pj4+Pj4gVGhhdCBpcyB0aGUgYmVzdCBzb2x1dGlvbi4gwqBObyBjaGFu Z2UgcmVxdWlyZWQuIMKgQmV0dGVyIGludGVyb3BlcmFiaWxpdHkgaW4gbXkgb3Bpbmlvbi7CoAo+ Pj4+Pj4+Pgo+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBTdGlsbCBvbiBteSB3YXkgdG8g VE8sIGdldHRpbmcgaW4gbGF0ZXIgdG9kYXkuwqAKPj4+Pj4+Pj4KPj4+Pj4+Pj4gwqAKPj4+Pj4+ Pj4KPj4+Pj4+Pj4gSm9obiBCLsKgCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Cj4+Pj4+ Pj4+Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+IFNlbnQgZnJvbSBteSBpUGhvbmUKPj4+Pj4+Pj4KPj4+Pj4+ Pj4KPj4+Pj4+Pj4gT24gSnVsIDIzLCAyMDE0LCBhdCAxMjoxNSBQTSwgdG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQgd3JvdGU6Cj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4gVGhlICJyZXNwb25zZSB0eXBlIiBv ZiB0aGUgdG9rZW4gZW5kcG9pbnQgaXMgY29udHJvbGxlZCBieSB0aGUgdmFsdWUgb2YgdGhlIHBh cmFtZXRlciAiZ3JhbnRfdHlwZSIuIFNvIHRoZXJlIGlzIG5vIG5lZWQgdG8gaW50cm9kdWNlIGEg bmV3IHBhcmFtZXRlci4KPj4+Pj4+Pj4+Cj4+Pj4+Pj4+PiB3cnQgdG8gYSBwb3RlbnRpYWwgIm5v X2FjY2Vzc190b2tlbiIgZ3JhbnQgdHlwZS4gSSBkbyBub3QgY29uc2lkZXIgdGhpcyBhIGdvb2Qg aWRlYSBhcyBpdCBjaGFuZ2VzIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHRva2VuIGVuZHBvaW50IChh cyBhbHJlYWR5IHBvaW50ZWQgb3V0IGJ5IFRob21hcykuIFRoaXMgZW5kcG9pbnQgQUxXQVlTIHJl c3BvbmRzIHdpdGggYW4gYWNjZXNzIHRva2VuIHRvIGFueSBncmFudCB0eXBlLiBJIHRoZXJlZm9y ZSB3b3VsZCBwcmVmZXIgdG8gdXNlIGFub3RoZXIgZW5kcG9pbnQgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlLgo+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+IHJlZ2FyZHMsCj4+Pj4+Pj4+PiBUb3JzdGVuLgo+ Pj4+Pj4+Pj4KPj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4gQW0gMjMuMDcuMjAxNCAx MzowNCwgc2NocmllYiBOYXQgU2FraW11cmE6Cj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBJTUhPLCBj aGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mICJyZXNwb25zZV90eXBlIiBAIGF1dGh6IGVuZHBvaW50 IHRoaXMgd2F5IGlzIG5vdCBhIGdvb2QgdGhpbmcuwqAKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IMKg Cj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBJbnN0ZWFkLCBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXIg InJlc3BvbnNlX3R5cGUiIEAgdG9rZW4gZW5kcG9pbnQsIGFzIEkgZGVzY3JpYmVkIGluIG15IHBy ZXZpb3VzIG1lc3NhZ2UswqAKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IHByb2JhYmx5IGlzIGJldHRl ci4gQXQgbGVhc3QsIGl0IGRvZXMgbm90IGNoYW5nZSB0aGUgc2VtYW50aWNzIG9mIHRoZSBwYXJh bWV0ZXJzIG9mIFJGQzY3NDkuwqAKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4K Pj4+Pj4+Pj4+PiDCoE5hdMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pj4+Cj4+ Pj4+Pj4+Pj4gMjAxNC0wNy0yMyAxMjo0OCBHTVQtMDQ6MDAgVGhvbWFzIEJyb3llciA8dC5icm95 ZXJAZ21haWwuY29tPjoKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IE5vLCBJIG1lYW4gcmVzcG9uc2Vf dHlwZT1ub25lIGFuZCByZXNwb25zZV90eXBlPWlkX3Rva2VuIGRvbid0IGdlbmVyYXRlIGEgY29k ZSBvciBhY2Nlc3MgdG9rZW4gc28geW91IGRvbid0IHVzZSB0aGUgVG9rZW4gRW5kcG9pbnQgKHdo aWNoIGlzIG5vdCB0aGUgc2FtZSBhcyB0aGUgQXV0aGVudGljYXRpb24gRW5kcG9pbnQgQlRXKS4K Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IFdpdGggcmVzcG9uc2VfdHlwZT1jb2RlX2Zvcl9pZF90b2tl biwgeW91IGdldCBhIGNvZGUgYW5kIGV4Y2hhbmdlIGl0IGZvciBhbiBpZF90b2tlbiBvbmx5LCBy YXRoZXIgdGhhbiBhbiBhY2Nlc3NfdG9rZW4sIHNvIHlvdSdyZSBjaGFuZ2luZyB0aGUgc2VtYW50 aWNzIG9mIHRoZSBUb2tlbiBFbmRwb2ludC4KPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+ Pj4+Pj4KPj4+Pj4+Pj4+PiBJJ20gbm90IHNheWluZyBpdCdzIGEgYmFkIHRoaW5nLCBqdXN0IHRo YXQgeW91IGNhbid0IHJlYWxseSBjb21wYXJlIG5vbmUgYW5kIGlkX3Rva2VuIHdpdGggY29kZV9m b3JfaWRfdG9rZW4uCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+ Pj4gT24gV2VkLCBKdWwgMjMsIDIwMTQgYXQgNjo0NSBQTSwgUmljaGVyLCBKdXN0aW4gUC4gPGpy aWNoZXJAbWl0cmUub3JnPiB3cm90ZToKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IEl0J3Mgb25seSAi bm90IHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludCIgYmVjYXVzZSB0aGUgdG9rZW4gZW5kcG9pbnQg Y29weS1wYXN0ZWQgYW5kIHJlbmFtZWQgdGhlIGF1dGhlbnRpY2F0aW9uIGVuZHBvaW50Lgo+Pj4+ Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gwqAKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IMKgLS0gSnVzdGluCj4+ Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gT24gSnVsIDIzLCAy MDE0LCBhdCA5OjMwIEFNLCBUaG9tYXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb20+IHdyb3Rl Ogo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gwqAKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IEV4Y2VwdCB0 aGF0IHRoZXNlIGFyZSBhYm91dCBub3QgdXNpbmcgdGhlIFRva2VuIEVuZHBvaW50IGF0IGFsbCwg d2hlcmVhcyB0aGUgY3VycmVudCBwcm9wb3NhbCBpcyBhYm91dCB0aGUgVG9rZW4gRW5kcG9pbnQg bm90IHJldHVybmluZyBhbiBhY2Nlc3NfdG9rZW4gZmllbGQgaW4gdGhlIEpTT04uCj4+Pj4+Pj4+ Pj4KPj4+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gT24gV2VkLCBKdWwgMjMsIDIw MTQgYXQgNDoyNiBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3 cm90ZToKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IFRoZSByZXNwb25zZV90eXBlICJub25lIiBpcyBh bHJlYWR5IHVzZWQgaW4gcHJhY3RpY2UsIHdoaWNoIHJldHVybnMgbm8gYWNjZXNzIHRva2VuLsKg IEl0IHdhcyBhY2NlcHRlZCBieSB0aGUgZGVzaWduYXRlZCBleHBlcnRzIGFuZCByZWdpc3RlcmVk IGluIHRoZSBJQU5BIE9BdXRoIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2UgVHlwZXMg cmVnaXN0cnkgYXQgaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0 ZXJzL29hdXRoLXBhcmFtZXRlcnMueG1sI2VuZHBvaW50LsKgIFRoZSByZWdpc3RlcmVkICJpZF90 b2tlbiIgcmVzcG9uc2UgdHlwZSBhbHNvIHJldHVybnMgbm8gYWNjZXNzIHRva2VuLgo+Pj4+Pj4+ Pj4+Cj4+Pj4+Pj4+Pj4gwqAKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IFNvIEkgdGhpbmsgdGhlIHF1 ZXN0aW9uIG9mIHdoZXRoZXIgcmVzcG9uc2UgdHlwZXMgdGhhdCByZXN1bHQgaW4gbm8gYWNjZXNz IHRva2VuIGJlaW5nIHJldHVybmVkIGFyZSBhY2NlcHRhYmxlIHdpdGhpbiBPQXV0aCAyLjAgaXMg YWxyZWFkeSBzZXR0bGVkLCBhcyBhIHByYWN0aWNhbCBtYXR0ZXIuwqAgTG90cyBvZiBPQXV0aCBp bXBsZW1lbnRhdGlvbnMgYXJlIGFscmVhZHkgdXNpbmcgc3VjaCByZXNwb25zZSB0eXBlcy4KPj4+ Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIC0tIE1pa2UK Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBGcm9tOiBPQXV0 aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQK Pj4+Pj4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQgNzowOSBBTQo+Pj4+Pj4+ Pj4+IFRvOiBOYXQgU2FraW11cmEKPj4+Pj4+Pj4+PiBDYzogPG9hdXRoQGlldGYub3JnPgo+Pj4+ Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+ Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBZZXMuIFRoaXMgaXMgd2h5IGl0IGhhcyB0byBi ZSBkaXNjdXNzZWQgaW4gdGhlIElFVEYuCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiDCoAo+Pj4+Pj4+ Pj4+Cj4+Pj4+Pj4+Pj4gUGhpbAo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gwqAKPj4+Pj4+Pj4+Pgo+ Pj4+Pj4+Pj4+IEBpbmRlcGVuZGVudGlkCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiB3d3cuaW5kZXBl bmRlbnRpZC5jb20KPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IHBoaWwuaHVudEBvcmFjbGUuY29tCj4+ Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gwqAKPj4+Pj4+Pj4+ Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBPbiBKdWwgMjMsIDIwMTQsIGF0 IDk6NDMgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPiB3cm90ZToKPj4+Pj4+ Pj4+Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBSZWFkaW5nIGJhY2sgdGhl IFJGQzY3NDksIEkgYW0gbm90IHN1cmUgaWYgdGhlcmUgaXMgYSBnb29kIHdheSBvZiBzdXBwcmVz c2luZyBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgcmVzcG9uc2UgYW5kIHN0aWxsIGJlIE9BdXRoLiBJ dCB3aWxsIGJyZWFrIHdob2xlIGJ1bmNoIG9mIGltcGxpY2l0IGRlZmluaXRpb25zIGxpa2U6wqAK Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBhdXRob3JpemF0 aW9uIHNlcnZlcgo+Pj4+Pj4+Pj4+IMKgIMKgIMKgIFRoZSBzZXJ2ZXIgaXNzdWluZyBhY2Nlc3Mg dG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0ZXIgc3VjY2Vzc2Z1bGx5Cj4+Pj4+Pj4+Pj4gwqAgwqAg wqAgYXV0aGVudGljYXRpbmcgdGhlIHJlc291cmNlIG93bmVyIGFuZCBvYnRhaW5pbmcgYXV0aG9y aXphdGlvbi4KPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBB ZnRlciBhbGwsIE9BdXRoIGlzIGFsbCBhYm91dCBpc3N1aW5nIGFjY2VzcyB0b2tlbnMuwqAKPj4+ Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBBbHNvLCBJIHRha2Ug YmFjayBteSBzdGF0ZW1lbnQgb24gdGhlIGdyYW50IHR5cGUgaW4gbXkgcHJldmlvdXMgbWFpbC7C oAo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gwqAKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IFRoZSBkZWZp bml0aW9uIG9mIGdyYW50IGFuZCBncmFudF90eXBlIGFyZSByZXNwZWN0aXZlbHk6wqAKPj4+Pj4+ Pj4+Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBncmFudMKgCj4+Pj4+Pj4+ Pj4KPj4+Pj4+Pj4+PiDCoCDCoCBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3VyY2Ug b3duZXIncyBhdXRob3JpemF0aW9uCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBncmFudF90eXBlCj4+Pj4+Pj4+Pj4KPj4+ Pj4+Pj4+PiDCoMKgwqAgKHN0cmluZyByZXByZXNlbnRpbmcgdGhlKSB0eXBlIG9mIGdyYW50IHNl bnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IHRvIG9idGFpbiB0aGUgYWNjZXNzIHRva2VuCj4+Pj4+ Pj4+Pj4KPj4+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gVGh1cywgdGhlIGdyYW50 IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IGluIHRoaXMgY2FzZSBpcyBzdGlsbCAnY29kZScu wqAKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBSZXNwb25z ZSB0eXBlIG9uIHRoZSBvdGhlciBoYW5kIGlzIG5vdCBzbyB3ZWxsIGRlZmluZWQgaW4gUkZDNjc0 OSwgYnV0IGl0IHNlZW1zIGl0IGlzIHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJlIHJldHVybmVk IGZyb20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRvIGV4cHJlc3Mgd2hhdCBpcyB0byBi ZSByZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50LCBwZXJoYXBzIGRlZmluaW5nIGEgbmV3IHBh cmFtZXRlciB0byB0aGUgdG9rZW4gZW5kcG9pbnQsIHdoaWNoIGlzIGEgcGFyYWxsZWwgdG8gdGhl IHJlc3BvbnNlX3R5cGUgdG8gdGhlIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgc2VlbXMgdG8gYmUg YSBtb3JlIHN5bW1ldHJpYyB3YXksIHRob3VnaCBJIGFtIG5vdCBzdXJlIGF0IGFsbCBpZiB0aGF0 IGlzIGdvaW5nIHRvIGJlIE9BdXRoIGFueSBtb3JlLiBPbmUgc3RyYXctbWFuIGlzIHRvIGRlZmlu ZSBhIG5ldyBwYXJhbWV0ZXIgY2FsbGVkIHJlc3BvbnNlX3R5cGUgdG8gdGhlIHRva2VuIGVuZHBv aW50IHN1Y2ggYXM6wqAKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+ Pj4+PiByZXNwb25zZV90eXBlCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiDCoCDCoCBPUFRJT05BTC4g QSBzdHJpbmcgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUgdG9r ZW4gZW5kcG9pbnQuwqAKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IMKgIMKgwqAKPj4+Pj4+Pj4+Pgo+ Pj4+Pj4+Pj4+IFRoZW4gZGVmaW5lIHRoZSBiZWhhdmlvciBvZiB0aGUgZW5kcG9pbnQgYWNjb3Jk aW5nIHRvIHRoZSB2YWx1ZXMgYXMgdGhlIHBhcmFsbGVsIHRvIHRoZSBtdWx0aS1yZXNwb25zZSB0 eXBlIHNwZWMuwqAKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNz L29hdXRoLXYyLW11bHRpcGxlLXJlc3BvbnNlLXR5cGVzLTFfMC5odG1sCj4+Pj4+Pj4+Pj4KPj4+ Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gTmF0Cj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+ PiDCoCDCoMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4g wqAKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiAyMDE0LTA3 LTIzIDc6MjEgR01ULTA0OjAwIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+Ogo+Pj4+ Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gVGhlIGRyYWZ0IGlzIHZlcnkgY2xlYXIuwqAKPj4+Pj4+Pj4+Pgo+ Pj4+Pj4+Pj4+IFBoaWwKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gT24gSnVsIDIz LCAyMDE0LCBhdCAwOjQ2LCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT4gd3JvdGU6 Cj4+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4+IFRoZSBuZXcgZ3JhbnQgdHlwZSB0aGF0IEkgd2FzIHRh bGtpbmcgYWJvdXQgd2FzwqAKPj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4gImF1dGhvcml6YXRpb25f Y29kZV9idXRfZG9fbm90X3JldHVybl9hY2Nlc3Nfbm9yX3JlZnJlc2hfdG9rZW4iLCBzbyB0byBz cGVhay7CoAo+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+PiBJdCBkb2VzIG5vdCByZXR1cm4gYW55dGhp bmcgcGVyIHNlLCBidXQgYW4gZXh0ZW5zaW9uIGNhbiBkZWZpbmUgc29tZXRoaW5nIG9uIHRvcCBv ZiBpdC7CoAo+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+ PiBUaGVuLCBPSURDIGNhbiBkZWZpbmUgYSBiaW5kaW5nIHRvIGl0IHNvIHRoYXQgdGhlIGJpbmRp bmcgb25seSByZXR1cm5zIElEIFRva2VuLsKgCj4+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4+IFRoaXMg YmluZGluZyB3b3JrIHNob3VsZCBiZSBkb25lIGluIE9JREYuIFNob3VsZCB0aGVyZSBiZSBzdWNo IGEgZ3JhbnQgdHlwZSzCoAo+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+PiBpdCB3aWxsIGJlIGFuIGV4 dHJlbWVseSBzaG9ydCBzcGVjLsKgCj4+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+ Pj4+Cj4+Pj4+Pj4+Pj4+IEF0IHRoZSBzYW1lIHRpbWUsIGlmIGFueSBvdGhlciBzcGVjaWZpY2F0 aW9uIHdhbnRlZCB0byBkZWZpbmXCoAo+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+PiBvdGhlciB0eXBl IG9mIHRva2VucyBhbmQgaGF2ZSBpdCByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCzC oAo+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+PiBpdCBjYW4gYWxzbyB1c2UgdGhpcyBncmFudCB0eXBl LsKgCj4+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4+IElm IHdoYXQgeW91IHdhbnQgaXMgdG8gZGVmaW5lIGEgbmV3IGdyYW50IHR5cGUgdGhhdCByZXR1cm5z IElEIFRva2VuIG9ubHkswqAKPj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4gdGhlbiwgSSBhbSB3aXRo IEp1c3Rpbi4gU2luY2UgIm90aGVyIHJlc3BvbnNlIHRoYW4gSUQgVG9rZW4iIGlzIG9ubHnCoAo+ Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+PiB0aGVvcmV0aWNhbCwgdGhpcyBpcyBhIG1vcmUgcGxhdXNp YmxlIHdheSBmb3J3YXJkLCBJIHN1cHBvc2UuwqAKPj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4gwqAK Pj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4gTmF0Cj4+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4+IMKgCj4+ Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4+IDIwMTQtMDctMjIgMTQ6MzAgR01ULTA0OjAwIEp1c3RpbiBS aWNoZXIgPGpyaWNoZXJAbWl0LmVkdT46Cj4+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4+IFNvIHRoZSBk cmFmdCB3b3VsZCBsaXRlcmFsbHkgdHVybiBpbnRvOgo+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+PiAi VGhlIGE0YyByZXNwb25zZSB0eXBlIGFuZCBncmFudCB0eXBlIHJldHVybiBhbiBpZF90b2tlbiBm cm9tIHRoZSB0b2tlbiBlbmRwb2ludCB3aXRoIG5vIGFjY2VzcyB0b2tlbi4gQWxsIHBhcmFtZXRl cnMgYW5kIHZhbHVlcyBhcmUgZGVmaW5lZCBpbiBPSURDLiIKPj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+ Pj4gU2VlbXMgbGlrZSB0aGUgcGVyZmVjdCBtaW5pIGV4dGVuc2lvbiBkcmFmdCBmb3IgT0lERiB0 byBkby4KPj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4gLS1KdXN0aW4KPj4+Pj4+Pj4+Pj4KPj4+Pj4+ Pj4+Pj4gL3NlbnQgZnJvbSBteSBwaG9uZS8KPj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4KPj4+Pj4+ Pj4+Pj4gT24gSnVsIDIyLCAyMDE0IDEwOjI5IEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdt YWlsLmNvbT4gd3JvdGU6Cj4+Pj4+Pj4+Pj4+ID4KPj4+Pj4+Pj4+Pj4gPiBXaGF0IGFib3V0IGp1 c3QgZGVmaW5pbmcgYSBuZXcgZ3JhbnQgdHlwZSBpbiB0aGlzIFdHPwo+Pj4+Pj4+Pj4+PiA+Cj4+ Pj4+Pj4+Pj4+ID4KPj4+Pj4+Pj4+Pj4gPiAyMDE0LTA3LTIyIDEyOjU2IEdNVC0wNDowMCBQaGls IEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPjoKPj4+Pj4+Pj4+Pj4gPj4KPj4+Pj4+Pj4+Pj4g Pj4gVGhhdCB3b3VsZCBiZSBuaWNlLiBIb3dldmVyIG9pZGMgc3RpbGwgbmVlZHMgdGhlIG5ldyBn cmFudCB0eXBlIGluIG9yZGVyIHRvIGltcGxlbWVudCB0aGUgc2FtZSBmbG93LsKgCj4+Pj4+Pj4+ Pj4+ID4+Cj4+Pj4+Pj4+Pj4+ID4+IFBoaWwKPj4+Pj4+Pj4+Pj4gPj4KPj4+Pj4+Pj4+Pj4gPj4g T24gSnVsIDIyLCAyMDE0LCBhdCAxMTozNSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5j b20+IHdyb3RlOgo+Pj4+Pj4+Pj4+PiA+Pgo+Pj4+Pj4+Pj4+PiA+Pj4gKzEgdG8gSnVzdGluLsKg Cj4+Pj4+Pj4+Pj4+ID4+Pgo+Pj4+Pj4+Pj4+PiA+Pj4KPj4+Pj4+Pj4+Pj4gPj4+IDIwMTQtMDct MjIgOTo1NCBHTVQtMDQ6MDAgUmljaGVyLCBKdXN0aW4gUC4gPGpyaWNoZXJAbWl0cmUub3JnPjoK Pj4+Pj4+Pj4+Pj4gPj4+Pgo+Pj4+Pj4+Pj4+PiA+Pj4+IEVycm9ycyBsaWtlIHRoZXNlIG1ha2Ug aXQgY2xlYXIgdG8gbWUgdGhhdCBpdCB3b3VsZCBtYWtlIG11Y2ggbW9yZSBzZW5zZSB0byBkZXZl bG9wIHRoaXMgZG9jdW1lbnQgaW4gdGhlIE9wZW5JRCBGb3VuZGF0aW9uLiBJdCBzaG91bGQgYmUg c29tZXRoaW5nIHRoYXQgZGlyZWN0bHkgcmVmZXJlbmNlcyBPcGVuSUQgQ29ubmVjdCBDb3JlIGZv ciBhbGwgb2YgdGhlc2UgdGVybXMgaW5zdGVhZCBvZiByZWRlZmluaW5nIHRoZW0uIEl0J3MgZG9p bmcgYXV0aGVudGljYXRpb24sIHdoaWNoIGlzIGZ1bmRhbWVudGFsbHkgd2hhdCBPcGVuSUQgQ29u bmVjdCBkb2VzIG9uIHRvcCBvZiBPQXV0aCwgYW5kIEkgZG9uJ3Qgc2VlIGEgZ29vZCBhcmd1bWVu dCBmb3IgZG9pbmcgdGhpcyB3b3JrIGluIHRoaXMgd29ya2luZyBncm91cC4KPj4+Pj4+Pj4+Pj4g Pj4+Pgo+Pj4+Pj4+Pj4+PiA+Pj4+IMKgLS0gSnVzdGluCj4+Pj4+Pj4+Pj4+ID4+Pj4KPj4+Pj4+ Pj4+Pj4gPj4+PiBPbiBKdWwgMjIsIDIwMTQsIGF0IDQ6MzAgQU0sIFRob21hcyBCcm95ZXIgPHQu YnJveWVyQGdtYWlsLmNvbT4gd3JvdGU6Cj4+Pj4+Pj4+Pj4+ID4+Pj4KPj4+Pj4+Pj4+Pj4gPj4+ Pj4KPj4+Pj4+Pj4+Pj4gPj4+Pj4KPj4+Pj4+Pj4+Pj4gPj4+Pj4KPj4+Pj4+Pj4+Pj4gPj4+Pj4g T24gTW9uLCBKdWwgMjEsIDIwMTQgYXQgMTE6NTIgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbT4gd3JvdGU6Cj4+Pj4+Pj4+Pj4+ID4+Pj4+Pgo+Pj4+Pj4+Pj4+PiA+ Pj4+Pj4gVGhhbmtzIGZvciB5b3VyIHJldmlldywgVGhvbWFzLsKgIFRoZSAicHJvbXB0PWNvbnNl bnQiIGRlZmluaXRpb24gYmVpbmcgbWlzc2luZyBpcyBhbiBlZGl0b3JpYWwgZXJyb3IuwqAgSXQg c2hvdWxkIGJlOgo+Pj4+Pj4+Pj4+PiA+Pj4+Pj4KPj4+Pj4+Pj4+Pj4gPj4+Pj4+IMKgCj4+Pj4+ Pj4+Pj4+ID4+Pj4+Pgo+Pj4+Pj4+Pj4+PiA+Pj4+Pj4gY29uc2VudAo+Pj4+Pj4+Pj4+PiA+Pj4+ Pj4KPj4+Pj4+Pj4+Pj4gPj4+Pj4+IFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBTSE9VTEQgcHJv bXB0IHRoZSBFbmQtVXNlciBmb3IgY29uc2VudCBiZWZvcmUgcmV0dXJuaW5nIGluZm9ybWF0aW9u IHRvIHRoZSBDbGllbnQuIElmIGl0IGNhbm5vdCBvYnRhaW4gY29uc2VudCwgaXQgTVVTVCByZXR1 cm4gYW4gZXJyb3IsIHR5cGljYWxseSBjb25zZW50X3JlcXVpcmVkLgo+Pj4+Pj4+Pj4+PiA+Pj4+ Pj4KPj4+Pj4+Pj4+Pj4gPj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4+ID4+Pj4+Pgo+Pj4+Pj4+Pj4+PiA+ Pj4+Pj4gSSdsbCBwbGFuIHRvIGFkZCBpdCBpbiB0aGUgbmV4dCBkcmFmdC4KPj4+Pj4+Pj4+Pj4g Pj4+Pj4KPj4+Pj4+Pj4+Pj4gPj4+Pj4KPj4+Pj4+Pj4+Pj4gPj4+Pj4gSXQgbG9va3MgbGlrZSB0 aGUgY29uc2VudF9yZXF1aXJlZCBlcnJvciBuZWVkcyB0byBiZSBkZWZpbmVkIHRvbywgYW5kIHlv dSBtaWdodCBoYXZlIGZvcmdvdHRlbiB0byBhbHNvIGltcG9ydCBhY2NvdW50X3NlbGVjdGlvbl9y ZXF1aXJlZCBmcm9tIE9wZW5JRCBDb25uZWN0Lgo+Pj4+Pj4+Pj4+PiA+Pj4+PiDCoAo+Pj4+Pj4+ Pj4+PiA+Pj4+Pj4KPj4+Pj4+Pj4+Pj4gPj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4+ID4+Pj4+Pgo+Pj4+ Pj4+Pj4+PiA+Pj4+Pj4gSSBhZ3JlZSB0aGF0IHRoZXJlJ3Mgbm8gZGlmZmVyZW5jZSBiZXR3ZWVu IGEgcmVzcG9uc2Ugd2l0aCBtdWx0aXBsZSAiYW1yIiB2YWx1ZXMgdGhhdCBpbmNsdWRlcyAibWZh IiBhbmQgb25lIHRoYXQgZG9lc24ndC7CoCBVbmxlc3MgYSBjbGVhciB1c2UgY2FzZSBmb3Igd2h5 ICJtZmEiIGlzIG5lZWRlZCBjYW4gYmUgaWRlbnRpZmllZCwgd2UgY2FuIGRlbGV0ZSBpdCBpbiB0 aGUgbmV4dCBkcmFmdC4KPj4+Pj4+Pj4+Pj4gPj4+Pj4KPj4+Pj4+Pj4+Pj4gPj4+Pj4KPj4+Pj4+ Pj4+Pj4gPj4+Pj4gVGhhbmtzLgo+Pj4+Pj4+Pj4+PiA+Pj4+Pgo+Pj4+Pj4+Pj4+PiA+Pj4+PiBI b3cgYWJvdXQgInB3ZCIgdGhlbj8gSSBmdWxseSB1bmRlcnN0YW5kIHRoYXQgSSBzaG91bGQgcmV0 dXJuICJwd2QiIGlmIHRoZSB1c2VyIGF1dGhlbnRpY2F0ZWQgdXNpbmcgYSBwYXNzd29yZCwgYnV0 IHdoYXQgInRoZSBzZXJ2aWNlIGlmIGEgY2xpZW50IHNlY3JldCBpcyB1c2VkIiBtZWFucyBpbiB0 aGUgZGVmaW5pdGlvbiBmb3IgdGhlICJwd2QiIHZhbHVlPwo+Pj4+Pj4+Pj4+PiA+Pj4+Pgo+Pj4+ Pj4+Pj4+PiA+Pj4+PiAoTm90YTogSSBrbm93IHlvdSdyZSBhdCBJRVRGLTkwLCBJJ20gcmVhZHkg dG8gd2FpdCAndGlsIHlvdSBjb21lIGJhY2sgOy0pICkKPj4+Pj4+Pj4+Pj4gPj4+Pj4KPj4+Pj4+ Pj4+Pj4gPj4+Pj4gLS0KPj4+Pj4+Pj4+Pj4gPj4+Pj4gVGhvbWFzIEJyb3llcgo+Pj4+Pj4+Pj4+ PiA+Pj4+PiAvdMmULm1hLmLKgXdhLmplLwo+Pj4+Pj4+Pj4+PiA+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+Pj4+Pj4+PiA+Pj4+PiBPQXV0 aCBtYWlsaW5nIGxpc3QKPj4+Pj4+Pj4+Pj4gPj4+Pj4gT0F1dGhAaWV0Zi5vcmcKPj4+Pj4+Pj4+ Pj4gPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+ Pj4+Pj4+PiA+Pj4+Cj4+Pj4+Pj4+Pj4+ID4+Pj4KPj4+Pj4+Pj4+Pj4gPj4+Pgo+Pj4+Pj4+Pj4+ PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+ Pj4+Pj4+Pj4+ID4+Pj4gT0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4+Pj4+Pj4+ID4+Pj4gT0F1dGhA aWV0Zi5vcmcKPj4+Pj4+Pj4+Pj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoCj4+Pj4+Pj4+Pj4+ID4+Pj4KPj4+Pj4+Pj4+Pj4gPj4+Cj4+Pj4+Pj4+Pj4+ ID4+Pgo+Pj4+Pj4+Pj4+PiA+Pj4KPj4+Pj4+Pj4+Pj4gPj4+IC0tCj4+Pj4+Pj4+Pj4+ID4+PiBO YXQgU2FraW11cmEgKD1uYXQpCj4+Pj4+Pj4+Pj4+ID4+PiBDaGFpcm1hbiwgT3BlbklEIEZvdW5k YXRpb24KPj4+Pj4+Pj4+Pj4gPj4+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLwo+Pj4+Pj4+Pj4+ PiA+Pj4gQF9uYXRfZW4KPj4+Pj4+Pj4+Pj4gPj4+Cj4+Pj4+Pj4+Pj4+ID4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+Pj4+Pj4+PiA+Pj4gT0F1 dGggbWFpbGluZyBsaXN0Cj4+Pj4+Pj4+Pj4+ID4+PiBPQXV0aEBpZXRmLm9yZwo+Pj4+Pj4+Pj4+ PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+Pj4+ Pj4+PiA+Cj4+Pj4+Pj4+Pj4+ID4KPj4+Pj4+Pj4+Pj4gPgo+Pj4+Pj4+Pj4+PiA+Cj4+Pj4+Pj4+ Pj4+ID4gLS0KPj4+Pj4+Pj4+Pj4gPiBOYXQgU2FraW11cmEgKD1uYXQpCj4+Pj4+Pj4+Pj4+ID4g Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uCj4+Pj4+Pj4+Pj4+ID4gaHR0cDovL25hdC5zYWtp bXVyYS5vcmcvCj4+Pj4+Pj4+Pj4+ID4gQF9uYXRfZW4KPj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4K Pj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4gwqAKPj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4gLS0gCj4+ Pj4+Pj4+Pj4+IE5hdCBTYWtpbXVyYSAoPW5hdCkKPj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4gQ2hh aXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uCj4+Pj4+Pj4+Pj4+IGh0dHA6Ly9uYXQuc2FraW11cmEu b3JnLwo+Pj4+Pj4+Pj4+PiBAX25hdF9lbgo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+ Pgo+Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiAtLSAKPj4+Pj4+Pj4+PiBOYXQg U2FraW11cmEgKD1uYXQpCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBDaGFpcm1hbiwgT3BlbklEIEZv dW5kYXRpb24KPj4+Pj4+Pj4+PiBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8KPj4+Pj4+Pj4+PiBA X25hdF9lbgo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gwqAKPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+Cj4+ Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K Pj4+Pj4+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+Pj4+Pj4+PiBPQXV0aEBpZXRmLm9yZwo+ Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPj4+ Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pj4+Cj4+ Pj4+Pj4+Pj4gLS0gCj4+Pj4+Pj4+Pj4gVGhvbWFzIEJyb3llcgo+Pj4+Pj4+Pj4+IC90yZQubWEu YsqBd2EuamUvCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwo+Pj4+Pj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+Pj4+ Pj4+Pj4+IE9BdXRoQGlldGYub3JnCj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pgo+Pj4+ Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiAtLSAKPj4+Pj4+Pj4+PiBUaG9tYXMgQnJv eWVyCj4+Pj4+Pj4+Pj4gL3TJlC5tYS5iyoF3YS5qZS8KPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+Cj4+ Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K Pj4+Pj4+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+Pj4+Pj4+PiBPQXV0aEBpZXRmLm9yZwo+ Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPj4+ Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pj4+Cj4+ Pj4+Pj4+Pj4gLS0gCj4+Pj4+Pj4+Pj4gTmF0IFNha2ltdXJhICg9bmF0KQo+Pj4+Pj4+Pj4+Cj4+ Pj4+Pj4+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uCj4+Pj4+Pj4+Pj4gaHR0cDovL25h dC5zYWtpbXVyYS5vcmcvCj4+Pj4+Pj4+Pj4gQF9uYXRfZW4KPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+ IMKgCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0 Cj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBPQXV0aEBpZXRmLm9yZwo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+Pj4+Pj4K Pj4+Pj4+Pj4+IMKgCj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4gwqAKPj4+Pj4+Pj4+Cj4+Pj4+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+Pj4+Pj4g T0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4+Pj4+PiBPQXV0aEBpZXRmLm9yZwo+Pj4+Pj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+Pj4+Pgo+Pj4+Pj4+ Pgo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+Pj4+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+Pj4+Pj4gT0F1dGhAaWV0Zi5vcmcKPj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+Pj4+ Pgo+Pj4+Pj4+Pgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiDCoAo+Pj4+Pj4+Pgo+Pj4+Pj4+PiAtLSAKPj4+ Pj4+Pj4gTmF0IFNha2ltdXJhICg9bmF0KQo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBDaGFpcm1hbiwgT3Bl bklEIEZvdW5kYXRpb24KPj4+Pj4+Pj4gaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvCj4+Pj4+Pj4+ IEBfbmF0X2VuCj4+Pj4+Pj4+Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+ Pj4+Pj4+PiBPQXV0aEBpZXRmLm9yZwo+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoCj4+Pj4+Pj4KPj4+Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+Pj4gwqAKPj4+ Pj4+Pgo+Pj4+Pj4+IC0tIAo+Pj4+Pj4+IE5hdCBTYWtpbXVyYSAoPW5hdCkKPj4+Pj4+Pgo+Pj4+ Pj4+IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbgo+Pj4+Pj4+IGh0dHA6Ly9uYXQuc2FraW11 cmEub3JnLwo+Pj4+Pj4+IEBfbmF0X2VuCj4+Pj4+Pj4KPj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlz dAo+Pj4+Pj4+IE9BdXRoQGlldGYub3JnCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+Pj4KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+Pj4+ IE9BdXRoQGlldGYub3JnCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoCj4+Pj4KPj4+PiDCoAo+Pj4+Cj4+Pj4gwqAKPj4+Cj4+Pgo+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+IE9BdXRoIG1haWxpbmcg bGlzdAo+Pj4gT0F1dGhAaWV0Zi5vcmcKPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgKPj4KPj4KPj4KPj4gwqAKPj4KPj4gLS0gCj4+IE5hdCBTYWtpbXVyYSAo PW5hdCkKPj4KPj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uCj4+IGh0dHA6Ly9uYXQuc2Fr aW11cmEub3JnLwo+PiBAX25hdF9lbgo+Pgo+Pgo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwo+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4gT0F1dGhAaWV0 Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pgo+ PiDCoAo+Pgo+PiDCoAo+Pgo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4gT0F1dGhAaWV0Zi5vcmcKPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pgo+PiDCoAo+Pgo+Pgo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pgo+PiBP QXV0aCBtYWlsaW5nIGxpc3QKPj4KPj4gT0F1dGhAaWV0Zi5vcmcKPj4KPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pgo+IMKgCj4KPiDCoA== From nobody Thu Jul 24 10:23:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BA21A0B08 for ; Thu, 24 Jul 2014 10:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVyw1qlxsR21 for ; Thu, 24 Jul 2014 10:22:57 -0700 (PDT) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FEB1A0AB7 for ; Thu, 24 Jul 2014 10:22:14 -0700 (PDT) Received: from mail-ig0-f176.google.com ([209.85.213.176]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKU9FAxp5yyCFRHACUE9BN4F01zVzo46GN@postini.com; Thu, 24 Jul 2014 10:22:14 PDT Received: by mail-ig0-f176.google.com with SMTP id hn18so6727094igb.3 for ; Thu, 24 Jul 2014 10:22:13 -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=51JNfz49k9FMI1/fc+Z5ghqFDwm/eeaPabRxl8sdbmw=; b=i8cyyZxNK50MSonk69jiHLSF97Le+ZXPHxWG3c0Qo0W7pgO3GBdhnHlrmlO9W9JcWl PCAuZnPoFC3hVfKFoYWiADhwz7hZyp+L6U3qDQinxCQkbkjc7UNNkZjXP2gdb+N8dDWo LcK5aE+5BHOBsLz/D0tPg/TbF8IIhUv3tZG7sEnycGsNFPFliXyoEz02vDzqoYV4oLcE zwpxhlkcHMUXJ5zBQ7uZP0Suk0ma3tZK/YCAk9VXcPrltBiWRc/MfLfmkLCMavEC7qTO /rr7hIkzjsd+gGZeM/fuoD6YSZeS/2KKfHmDB8Rj5GwGeYTOxxuAHXN0N4TzFqJ3ajRs xpjA== X-Gm-Message-State: ALoCoQljcW6klET7ZHv/puKHRyivRI6pVH1re8rqiOCTLo9vrPxz91CHuYS/nGqm67FYDvfIwbOlH4BmGk1KoAa9DpCDlluQzym1mhUsdceP/pys/dk1WNU0dSesw159OA9HzBuzYCTp X-Received: by 10.50.176.202 with SMTP id ck10mr41643492igc.2.1406222533775; Thu, 24 Jul 2014 10:22:13 -0700 (PDT) X-Received: by 10.50.176.202 with SMTP id ck10mr41643462igc.2.1406222533586; Thu, 24 Jul 2014 10:22:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Thu, 24 Jul 2014 10:21:43 -0700 (PDT) In-Reply-To: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> From: Brian Campbell Date: Thu, 24 Jul 2014 10:21:43 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=089e0111d758970f3704fef3b2af Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/tTWJLLfELFdMNaFNOGNUU1a2BdM Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 17:23:08 -0000 --089e0111d758970f3704fef3b2af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm sorry to miss what will likely be a very engaging meeting today. The premise that some developers are using OAuth in a insecure way to do authentication is something we can probably all agree on. It doesn't necessarily follow from that premise, however, that the solution is yet another spec which either duplicates some subset of OpenID Connect (in a different SDO) or forks how to do SSO/authentication using OAuth. On Thu, Jul 24, 2014 at 7:25 AM, John Bradley wrote: > I am not against discussion in the WG. > > I happen to agree with Phil's fundamental premise that some developers ar= e > using OAuth in a insecure way to do authentication. > > That raises the question of how to best educate them, and or address > technical barriers. > > It is on the second point that people's opinions seem to divide. > > Some people thing that if we have a OAuth flow that eliminates the access > token (primarily to avoid asking for consent as I understand it) and just > return a id_token from the token endpoint that can be done in a spec shor= t > enough to het people to read. The subtext of this is that the Connect > specification is too large that it scare people, and they don't find the > spec in the first place because it is not a RFC. > > An other common possession is that if you don't want to prompt the user > for consent then don't ask for scopes. Twisting the OAuth spec to not > return an access token is not OAuth, yes you could use a different > endpoint rather than the token endpoint, but that is not OAuth. Connect > was careful not to break the OAuth spec. As long as you are willing to > take a access token with no scopes (the client needs to understand that > there are no attributes one way or another anyway or it will break) then > you don't need to change OAuth. You can publish a profile of connect th= at > satisfies the use case. > > I think Mike has largely done that but it might be better being less > stingy on references back to the larger spec. > > The questions are do we modify OAuth to not return an access token, and i= f > so how, and if we do is it still OAuth. > > The other largely separable question is do we create confusion in the > market and slow the the adoption of identity federation on top of OAuth, = or > find a way to make this look like a positive alignment of interests aroun= d > a subset of Connect. > > There are a number of options. > 1: We can do a profile in the OIDF and publish it as a IETF document. > Perhaps the cleanest from an IPR point of view. > 2:We can do a profile in the OAuth WG referencing connect. > 3:We can do a AD sponsored profile that is not in the OAuth WG. > 4:We can do a small spec in OAuth to add response_type to the token > endpoint. in combination with 1, 2, or 3 > > I agree that stoping developers doing insecure things needs to be > addressed somehow. > I am not personally convinced that Oauth without access tokens is sensibl= e. > > Looking forward to the meeting:) > > John B. > > On Jul 24, 2014, at 6:52 AM, Brian Campbell > wrote: > > I'd note that the reaction at the conference to Ian's statement was > overwhelmingly positive. There was a wide range of industry people here - > implementers, practitioners, deployers, strategists, etc. - and it seems > pretty clear that the "rough consensus" of the industry at large is that > a4c is not wanted or needed. > > > On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura wrote: > >> And here is a quote from Ian's blog. >> >> And although the authentication wheel is round, that doesn=E2=80=99t mea= n it >>> isn=E2=80=99t without its lumps. First, we do see some reinventing the = wheel just >>> to reinvent the wheel. OAuth A4C is simply not a fruitful activity and >>> should be put down. >> >> >> >>> (Source) >>> http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-mus= ings-on-identity-standards-part-1.html >> >> >> >> 2014-07-23 16:53 GMT-04:00 John Bradley : >> >> I thought I did post this to the list. >>> >>> I guess I hit the wrong reply on my phone. >>> >>> John B. >>> Sent from my iPhone >>> >>> On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: >>> >>> we are two, at least :-) >>> >>> Why didn't you post this on the list? >>> >>> When will be be arriving? >>> >>> Am 23.07.2014 16:39, schrieb John Bradley: >>> >>> Ian Glazer mentioned this in his keynote at CIS yesterday. >>> >>> His advice was please stop, we are creating confusion and uncertainty. >>> >>> We are becoming our own wort enemy. ( my view though Ian may share it) >>> >>> Returning just an id_ token from the token endpoint has little real >>> value. >>> >>> Something really useful to do would be sorting out channel_id so we can >>> do PoP for id tokens to make them and other cookies secure in the front >>> channel. I think that is a better use of time. >>> >>> I may be in the minority opinion on that, it won't be the first time. >>> >>> >>> John B. >>> Sent from my iPhone >>> >>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>> You are right from a theoretical perspective. Practically this was >>> caused by editorial decisions during the creation of the RFC. As far as= I >>> remember, there was a definition of the (one) token endpoint response i= n >>> early versions. No one every considered to NOT respond with an access t= oken >>> from the token endpoint. So one might call it an implicit assumption. >>> >>> I'm worried that people get totally confused if an exception is >>> introduced now given the broad adoption of OAuth based on this assumpti= on. >>> >>> regards, >>> Torsten. >>> >>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer : >>> >>> Is it said anywhere that ALL grant types MUST use Section 5.1 >>> responses? Each grant type references Section 5.1, and "access token >>> request" is only defined in the context of the defined grant types. Sec= tion >>> 2.2 doesn't talk about the request or response format. >>> Le 23 juil. 2014 21:32, "Nat Sakimura" a =C3=A9cri= t : >>> >>>> Is it? Apart from the implicit grant that does not use token endpoint, >>>> all other grant references section 5.1 for the response, i.e., all sha= res >>>> the same response. >>>> >>>> >>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer : >>>> >>>>> I hadn't realized the JSON response that requires the access_token >>>>> field is defined per grant_type, so I'd be OK to "extend the semantic= s" as >>>>> in the current draft. >>>>> That was actually my main concern: that the token endpoint mandates >>>>> access_token; but its actually not the case. >>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9c= rit : >>>>> >>>>> I agree with John that overloading response_type @ authz endpoint is >>>>>> a bad idea. It completely changes the semantics of this parameter. N= OTE: >>>>>> what I was proposing was not this parameter, but a new parameter >>>>>> response_type @ token endpoint. >>>>>> >>>>>> I also think overloading grant_type is a bad idea since it changes >>>>>> its semantics. I quote the definition here again: >>>>>> >>>>>> grant >>>>>> credential representing the resource owner's authorization >>>>>> >>>>>> grant_type >>>>>> type of grant sent to the token endpoint to obtain the access token >>>>>> >>>>>> It is not about controlling what is to be returned from the token >>>>>> endpoint, but the hint to the token endpoint describing the type of >>>>>> credential the endpoint has received. It seems the "control of what = is >>>>>> being returned from token endpoint" is just a side effect. >>>>>> >>>>>> I am somewhat ambivalent[1] in changing the semantics of token >>>>>> endpoint, but in as much as "text is the king" for a spec., we proba= bly >>>>>> should not change the semantics of it as Torsten points out. If it i= s ok to >>>>>> change this semantics, I believe defining a new parameter to this en= dpoint >>>>>> to control the response would be the best way to go. This is what I = have >>>>>> described previously. >>>>>> >>>>>> Defining a new endpoint to send code to get ID Token and forbidding >>>>>> the use of it against token endpoint would not change the semantics = of any >>>>>> existing parameter or endpoint, which is good. However, I doubt if i= t is >>>>>> not worth doing. What's the point of avoiding access token scoped to >>>>>> UserInfo endpoint after all? Defining a new endpoint for just avoidi= ng the >>>>>> access token for userinfo endpoint seems way too much the heavy wait= way >>>>>> and it breaks interoperabiliy: it defeats the purpose of standardiza= tion. >>>>>> >>>>>> I have started feeling that no change is the best way out. >>>>>> >>>>>> Nat >>>>>> >>>>>> [1] If instead of saying "Token endpoint - used by the client to >>>>>> exchange an authorization grant for an access token, typically with >>>>>> client authentication", it were saying "Token endpoint - used by the >>>>>> client to exchange an authorization grant for tokens, typically with >>>>>> client authentication", then it would have been OK. It is an expansi= on of >>>>>> the capability rather than changing the semantics. >>>>>> >>>>>> >>>>>> >>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones : >>>>>> >>>>>>> You need the alternative response_type value ("code_for_id_token" >>>>>>> in the A4C draft) to tell the Authorization Server to return a code= to be >>>>>>> used with the new grant type, rather than one to use with the >>>>>>> "authorization_code" grant type (which is what response_type=3Dcode= does). >>>>>>> >>>>>>> >>>>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John >>>>>>> Bradley >>>>>>> *Sent:* Wednesday, July 23, 2014 10:33 AM >>>>>>> *To:* torsten@lodderstedt.net >>>>>>> >>>>>>> *Cc:* oauth@ietf.org >>>>>>> *Subject:* Re: [OAUTH-WG] New Version Notification for >>>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>>> >>>>>>> >>>>>>> >>>>>>> If we use the token endpoint then a new grant_type is the best way. >>>>>>> >>>>>>> >>>>>>> It sort of overloads code, but that is better than messing with >>>>>>> response_type for the authorization endpoint to change the response= from >>>>>>> the token_endpoint. That is in my opinion a champion bad idea. >>>>>>> >>>>>>> >>>>>>> In discussions developing Connect we decided not to open this can o= f >>>>>>> worms because no good would come of it. >>>>>>> >>>>>>> >>>>>>> The token_endpoint returns a access token. Nothing requires scope >>>>>>> to be associates with the token. >>>>>>> >>>>>>> >>>>>>> That is the best solution. No change required. Better >>>>>>> interoperability in my opinion. >>>>>>> >>>>>>> >>>>>>> Still on my way to TO, getting in later today. >>>>>>> >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> >>>>>>> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >>>>>>> >>>>>>> The "response type" of the token endpoint is controlled by the valu= e >>>>>>> of the parameter "grant_type". So there is no need to introduce a n= ew >>>>>>> parameter. >>>>>>> >>>>>>> wrt to a potential "no_access_token" grant type. I do not consider >>>>>>> this a good idea as it changes the semantics of the token endpoint = (as >>>>>>> already pointed out by Thomas). This endpoint ALWAYS responds with = an >>>>>>> access token to any grant type. I therefore would prefer to use ano= ther >>>>>>> endpoint for the intended purpose. >>>>>>> >>>>>>> regards, >>>>>>> Torsten. >>>>>>> >>>>>>> >>>>>>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>>>>>> >>>>>>> IMHO, changing the semantics of "response_type" @ authz endpoint >>>>>>> this way is not a good thing. >>>>>>> >>>>>>> >>>>>>> Instead, defining a new parameter "response_type" @ token endpoint, >>>>>>> as I described in my previous message, >>>>>>> >>>>>>> probably is better. At least, it does not change the semantics of >>>>>>> the parameters of RFC6749. >>>>>>> >>>>>>> >>>>>>> Nat >>>>>>> >>>>>>> >>>>>>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer : >>>>>>> >>>>>>> No, I mean response_type=3Dnone and response_type=3Did_token don't >>>>>>> generate a code or access token so you don't use the Token Endpoint= (which >>>>>>> is not the same as the Authentication Endpoint BTW). >>>>>>> >>>>>>> With response_type=3Dcode_for_id_token, you get a code and exchange= it >>>>>>> for an id_token only, rather than an access_token, so you're changi= ng the >>>>>>> semantics of the Token Endpoint. >>>>>>> >>>>>>> >>>>>>> I'm not saying it's a bad thing, just that you can't really compare >>>>>>> none and id_token with code_for_id_token. >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. < >>>>>>> jricher@mitre.org> wrote: >>>>>>> >>>>>>> It's only "not using the token endpoint" because the token endpoint >>>>>>> copy-pasted and renamed the authentication endpoint. >>>>>>> >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> >>>>>>> On Jul 23, 2014, at 9:30 AM, Thomas Broyer >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Except that these are about not using the Token Endpoint at all, >>>>>>> whereas the current proposal is about the Token Endpoint not return= ing an >>>>>>> access_token field in the JSON. >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones < >>>>>>> Michael.Jones@microsoft.com> wrote: >>>>>>> >>>>>>> The response_type "none" is already used in practice, which returns >>>>>>> no access token. It was accepted by the designated experts and reg= istered >>>>>>> in the IANA OAuth Authorization Endpoint Response Types registry at >>>>>>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.x= ml#endpoint. >>>>>>> The registered "id_token" response type also returns no access toke= n. >>>>>>> >>>>>>> >>>>>>> So I think the question of whether response types that result in no >>>>>>> access token being returned are acceptable within OAuth 2.0 is alre= ady >>>>>>> settled, as a practical matter. Lots of OAuth implementations are = already >>>>>>> using such response types. >>>>>>> >>>>>>> >>>>>>> -- Mike >>>>>>> >>>>>>> >>>>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil >>>>>>> Hunt >>>>>>> *Sent:* Wednesday, July 23, 2014 7:09 AM >>>>>>> *To:* Nat Sakimura >>>>>>> *Cc:* >>>>>>> *Subject:* Re: [OAUTH-WG] New Version Notification for >>>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>>> >>>>>>> >>>>>>> Yes. This is why it has to be discussed in the IETF. >>>>>>> >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> @independentid >>>>>>> >>>>>>> www.independentid.com >>>>>>> >>>>>>> phil.hunt@oracle.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Reading back the RFC6749, I am not sure if there is a good way of >>>>>>> suppressing access token from the response and still be OAuth. It w= ill >>>>>>> break whole bunch of implicit definitions like: >>>>>>> >>>>>>> >>>>>>> authorization server >>>>>>> The server issuing access tokens to the client after >>>>>>> successfully >>>>>>> authenticating the resource owner and obtaining authorization= . >>>>>>> >>>>>>> >>>>>>> After all, OAuth is all about issuing access tokens. >>>>>>> >>>>>>> >>>>>>> Also, I take back my statement on the grant type in my previous >>>>>>> mail. >>>>>>> >>>>>>> >>>>>>> The definition of grant and grant_type are respectively: >>>>>>> >>>>>>> >>>>>>> grant >>>>>>> >>>>>>> credential representing the resource owner's authorization >>>>>>> >>>>>>> >>>>>>> grant_type >>>>>>> >>>>>>> (string representing the) type of grant sent to the token >>>>>>> endpoint to obtain the access token >>>>>>> >>>>>>> >>>>>>> Thus, the grant sent to the token endpoint in this case is still >>>>>>> 'code'. >>>>>>> >>>>>>> >>>>>>> Response type on the other hand is not so well defined in RFC6749, >>>>>>> but it seems it is representing what is to be returned from the >>>>>>> authorization endpoint. To express what is to be returned from toke= n >>>>>>> endpoint, perhaps defining a new parameter to the token endpoint, w= hich is >>>>>>> a parallel to the response_type to the Authorization Endpoint seems= to be a >>>>>>> more symmetric way, though I am not sure at all if that is going to= be >>>>>>> OAuth any more. One straw-man is to define a new parameter called >>>>>>> response_type to the token endpoint such as: >>>>>>> >>>>>>> >>>>>>> response_type >>>>>>> >>>>>>> OPTIONAL. A string representing what is to be returned from the >>>>>>> token endpoint. >>>>>>> >>>>>>> >>>>>>> Then define the behavior of the endpoint according to the values as >>>>>>> the parallel to the multi-response type spec. >>>>>>> >>>>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>>>> >>>>>>> >>>>>>> Nat >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2014-07-23 7:21 GMT-04:00 Phil Hunt : >>>>>>> >>>>>>> The draft is very clear. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >>>>>>> >>>>>>> The new grant type that I was talking about was >>>>>>> >>>>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", so >>>>>>> to speak. >>>>>>> >>>>>>> It does not return anything per se, but an extension can define >>>>>>> something on top of it. >>>>>>> >>>>>>> >>>>>>> Then, OIDC can define a binding to it so that the binding only >>>>>>> returns ID Token. >>>>>>> >>>>>>> This binding work should be done in OIDF. Should there be such a >>>>>>> grant type, >>>>>>> >>>>>>> it will be an extremely short spec. >>>>>>> >>>>>>> >>>>>>> At the same time, if any other specification wanted to define >>>>>>> >>>>>>> other type of tokens and have it returned from the token endpoint, >>>>>>> >>>>>>> it can also use this grant type. >>>>>>> >>>>>>> >>>>>>> If what you want is to define a new grant type that returns ID Toke= n >>>>>>> only, >>>>>>> >>>>>>> then, I am with Justin. Since "other response than ID Token" is onl= y >>>>>>> >>>>>>> theoretical, this is a more plausible way forward, I suppose. >>>>>>> >>>>>>> >>>>>>> Nat >>>>>>> >>>>>>> >>>>>>> 2014-07-22 14:30 GMT-04:00 Justin Richer : >>>>>>> >>>>>>> So the draft would literally turn into: >>>>>>> >>>>>>> "The a4c response type and grant type return an id_token from the >>>>>>> token endpoint with no access token. All parameters and values are = defined >>>>>>> in OIDC." >>>>>>> >>>>>>> Seems like the perfect mini extension draft for OIDF to do. >>>>>>> >>>>>>> --Justin >>>>>>> >>>>>>> /sent from my phone/ >>>>>>> >>>>>>> >>>>>>> On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: >>>>>>> > >>>>>>> > What about just defining a new grant type in this WG? >>>>>>> > >>>>>>> > >>>>>>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt : >>>>>>> >> >>>>>>> >> That would be nice. However oidc still needs the new grant type >>>>>>> in order to implement the same flow. >>>>>>> >> >>>>>>> >> Phil >>>>>>> >> >>>>>>> >> On Jul 22, 2014, at 11:35, Nat Sakimura >>>>>>> wrote: >>>>>>> >> >>>>>>> >>> +1 to Justin. >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. = : >>>>>>> >>>> >>>>>>> >>>> Errors like these make it clear to me that it would make much >>>>>>> more sense to develop this document in the OpenID Foundation. It sh= ould be >>>>>>> something that directly references OpenID Connect Core for all of t= hese >>>>>>> terms instead of redefining them. It's doing authentication, which = is >>>>>>> fundamentally what OpenID Connect does on top of OAuth, and I don't= see a >>>>>>> good argument for doing this work in this working group. >>>>>>> >>>> >>>>>>> >>>> -- Justin >>>>>>> >>>> >>>>>>> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer >>>>>>> wrote: >>>>>>> >>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < >>>>>>> Michael.Jones@microsoft.com> wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" >>>>>>> definition being missing is an editorial error. It should be: >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> consent >>>>>>> >>>>>> >>>>>>> >>>>>> The Authorization Server SHOULD prompt the End-User for >>>>>>> consent before returning information to the Client. If it cannot ob= tain >>>>>>> consent, it MUST return an error, typically consent_required. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> I'll plan to add it in the next draft. >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> It looks like the consent_required error needs to be defined >>>>>>> too, and you might have forgotten to also import account_selection_= required >>>>>>> from OpenID Connect. >>>>>>> >>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> I agree that there's no difference between a response with >>>>>>> multiple "amr" values that includes "mfa" and one that doesn't. Un= less a >>>>>>> clear use case for why "mfa" is needed can be identified, we can de= lete it >>>>>>> in the next draft. >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> Thanks. >>>>>>> >>>>> >>>>>>> >>>>> How about "pwd" then? I fully understand that I should return >>>>>>> "pwd" if the user authenticated using a password, but what "the ser= vice if >>>>>>> a client secret is used" means in the definition for the "pwd" valu= e? >>>>>>> >>>>> >>>>>>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you >>>>>>> come back ;-) ) >>>>>>> >>>>> >>>>>>> >>>>> -- >>>>>>> >>>>> Thomas Broyer >>>>>>> >>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>>> >>>>> _______________________________________________ >>>>>>> >>>>> 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 >>>>>>> >>>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> -- >>>>>>> >>> Nat Sakimura (=3Dnat) >>>>>>> >>> Chairman, OpenID Foundation >>>>>>> >>> http://nat.sakimura.org/ >>>>>>> >>> @_nat_en >>>>>>> >>> >>>>>>> >>> _______________________________________________ >>>>>>> >>> OAuth mailing list >>>>>>> >>> OAuth@ietf.org >>>>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > Nat Sakimura (=3Dnat) >>>>>>> > Chairman, OpenID Foundation >>>>>>> > http://nat.sakimura.org/ >>>>>>> > @_nat_en >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nat Sakimura (=3Dnat) >>>>>>> >>>>>>> Chairman, OpenID Foundation >>>>>>> http://nat.sakimura.org/ >>>>>>> @_nat_en >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nat Sakimura (=3Dnat) >>>>>>> >>>>>>> Chairman, OpenID Foundation >>>>>>> http://nat.sakimura.org/ >>>>>>> @_nat_en >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thomas Broyer >>>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thomas Broyer >>>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nat Sakimura (=3Dnat) >>>>>>> >>>>>>> Chairman, OpenID Foundation >>>>>>> http://nat.sakimura.org/ >>>>>>> @_nat_en >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=3Dnat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>> >>> _______________________________________________ >>> 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 >>> >>> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > --089e0111d758970f3704fef3b2af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm sorry to miss what will likely be a very engaging = meeting today.

The premise that some developers are using OAuth in a= insecure way to do authentication is something we can probably all agree o= n.

It doesn't necessarily follow from that premise, however, that the = solution is yet another spec which either duplicates some subset of OpenID = Connect (in a different SDO) or forks how to do SSO/authentication using OA= uth.


On Thu,= Jul 24, 2014 at 7:25 AM, John Bradley <ve7jtb@ve7jtb.com> w= rote:
I am not= against discussion in the WG.

I happen to agree with Ph= il's fundamental premise that some developers are using OAuth in a inse= cure way to do authentication.

That raises the question of how to best educate them, a= nd or address technical barriers.

It is on the sec= ond point that people's opinions seem to divide.

Some people thing that if we have a OAuth flow that eliminates the acc= ess token (primarily to avoid asking for consent as I understand it) and ju= st return a id_token from the token endpoint that can be done in a spec sho= rt enough to het people to read. =C2=A0 The subtext of this is that the Con= nect specification is too large that it scare people, =C2=A0and they don= 9;t find the spec in the first place because it is not a RFC.

An other common possession is that if you don't wan= t to prompt the user for consent then don't ask for scopes. =C2=A0Twist= ing the OAuth spec to not return an access token is not OAuth, =C2=A0yes yo= u could use a different endpoint rather than the token endpoint, but that i= s not OAuth. =C2=A0 Connect was careful not to break the OAuth spec. =C2=A0= =C2=A0As long as you are willing to take a access token with no scopes (th= e client needs to understand that there are no attributes one way or anothe= r anyway or it will break) then you don't need to change OAuth. =C2=A0 = You can publish a profile of connect that satisfies the use case.

I think Mike has largely done that but it might be bett= er being less stingy on references back to the larger spec.

<= /div>
The questions are do we modify OAuth to not return an access toke= n, and if so how, =C2=A0and if we do is it still OAuth.

The other largely separable question is do we create co= nfusion in the market and slow the the adoption of identity federation on t= op of OAuth, or find a way to make this look like a positive alignment of i= nterests around a subset of Connect.

There are a number of options. =C2=A0
1: We c= an do a profile in the OIDF and publish it as a IETF document. =C2=A0 Perha= ps the cleanest from an IPR point of view.
2:We can do a profile = in the OAuth WG referencing connect.
3:We can do a AD sponsored profile that is not in the OAuth WG.
<= div>4:We can do a small spec in OAuth to add response_type to the token end= point. =C2=A0in combination with 1, 2, or 3

I agre= e that stoping developers doing insecure things needs to be addressed someh= ow. =C2=A0
I am not personally convinced that Oauth without access tokens is sens= ible.

Looking forward to the meeting:)
<= br>
John B.

On Jul 24, 2= 014, at 6:52 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I'd note that the reacti= on at the conference to Ian's statement was overwhelmingly positive. Th= ere was a wide range of industry people here - implementers, practitioners,= deployers, strategists, etc. - and it seems pretty clear that the "ro= ugh consensus" of the industry at large is that a4c is not wanted or n= eeded.


On Thu,= Jul 24, 2014 at 5:29 AM, Nat Sakimura <sakimura@gmail.com>= wrote:
And here is a quote from Ia= n's blog.=C2=A0

And although the authentication wheel is round, that doesn=E2=80=99t mean i= t isn=E2=80=99t without its lumps. First, we do see some reinventing the wh= eel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity= and should be put down. =C2=A0
=C2=A0
(Source) http://www.tuesdaynight.org/2014/07/23/do-= we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html


2014-07= -23 16:53 GMT-04:00 John Bradley <ve7jtb@ve7jtb.com>:

I thought I did post this to the list.=C2=A0

I guess I hit the wrong reply on my phone.=C2=A0
=C2= =A0
John B.=C2=A0
Sent from my iPhone

On Jul 23,= 2014, at 4:50 PM, torsten@lodderstedt.net wrote:

we are two, at least :-)

Why d= idn't you post this on the list?

When will be be arriving?

= Am 23.07.2014 16:39, schrieb John Bradley:

Ian Glazer mentioned this in his keynote at CIS yesterday.=C2=A0
=C2=A0
His advice was please stop, =C2=A0we are creating confusion and uncert= ainty.=C2=A0
=C2=A0
We are becoming our own wort enemy. ( my view though Ian may share it)=
=C2=A0
Returning just an id_ token from the token endpoint has little real va= lue.=C2=A0
=C2=A0
Something really useful to do would be sorting out channel_id so we ca= n do PoP for id tokens to make them and other cookies secure in the front c= hannel. =C2=A0 I think that is a better use of time.=C2=A0
=C2=A0
I may be in the minority opinion on that, =C2=A0it won't be the fi= rst time. =C2=A0


John B.=C2=A0
Sent from my iPhone

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <torsten@lodderstedt.net= > wrote:

You are right from a theoretical perspective. Practically this was cau= sed by editorial decisions during the creation of the RFC. As far as I reme= mber, there was a definition of the (one) token endpoint response in early = versions. No one every considered to NOT respond with an access token from = the token endpoint. So one might call it an implicit assumption.
=C2=A0
I'm worried that people get totally confused if an exception is in= troduced now given the broad adoption of OAuth based on this assumption.
=C2=A0
regards,
Torsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

<= /div>

Is it said anywhere that ALL grant types MUST use Secti= on 5.1 responses? Each grant type references Section 5.1, and "access = token request" is only defined in the context of the defined grant typ= es. Section 2.2 doesn't talk about the request or response format.

Le 23 juil. 2014 21:32, "Nat Sakimura"= <sakimura@gmail= .com> a =C3=A9crit :
Is it? Apart from the implicit grant that does not use tok= en endpoint, all other grant references section 5.1 for the response, i.e.,= all shares the same response.=C2=A0


2014-07-23 15:18 GMT-04:00 Thomas Broyer &= lt;t.broyer@gmail.c= om>:

I hadn't realized the JSO= N response that requires the access_token field is defined per grant_type, = so I'd be OK to "extend the semantics" as in the current draf= t.
That was actually my main concern: that the token endpoint mandates access= _token; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura"= <sakimura@gmail= .com> a =C3=A9crit :

I agree with John that overloading response_type @ authz endpoint is a= bad idea. It completely changes the semantics of this parameter. NOTE: wha= t I was proposing was not this parameter, but a new parameter response_type= @ token endpoint.=C2=A0
=C2=A0
I also think overloading grant_type is a bad idea since it changes its= semantics. I quote the definition here again:=C2=A0
=C2=A0
grant=C2=A0
=C2=A0 =C2=A0 credential representing the resource owner's authori= zation
=C2=A0
grant_type
type of grant sent to the= token endpoint to obtain the access token
=C2=A0
It is not about controlling what is to be returned from the token endp= oint, but the hint to the token endpoint describing the type of credential = the endpoint has received. It seems the "control of what is being retu= rned from token endpoint" =C2=A0is just a side effect.=C2=A0
=C2=A0
I am somewhat ambivalent[1] in changing the semantics of token endpoin= t, but in as much as "text is the king" for a spec., we probably = should not change the semantics of it as Torsten points out. If it is ok to= change this semantics, I believe defining a new parameter to this endpoint= to control the response would be the best way to go. This is what I have d= escribed previously.=C2=A0
=C2=A0
Defining a new endpoint to send code to get ID Token and forbidding th= e use of it against token endpoint would not change the semantics of any ex= isting parameter or endpoint, which is good. However, I doubt if it is not = worth doing. What's the point of avoiding access token scoped to UserIn= fo endpoint after all? Defining a new endpoint for just avoiding the access= token for userinfo endpoint seems way too much the heavy wait way and it b= reaks interoperabiliy: it defeats the purpose of standardization.=C2=A0
=C2=A0
I have started feeling that no change is the best way out.=C2=A0
=C2=A0
Nat
=C2=A0
[1] =C2=A0If instead of saying "Tok= en endpoint - used by the client to exchange an authorization=C2=A0g= rant for an access token, typically with client authentication", it we= re saying "Token endpoint - used by the = client to exchange an authorization=C2=A0grant for tokens, typically= with client authentication", then it would have been OK. It is an exp= ansion of the capability rather than changing the semantics.
=C2=A0


2014-07-23 13:39 GMT-04:00 Mike Jones <= Michael.Jo= nes@microsoft.com>:

You need the alternative= response_type value ("code_for_id_token" in the A4C draft) to tell the Authorization Server to r= eturn a code to be used with the new grant type, rather than one to use wit= h the "authorization_code" grant type (which is what response_typ= e=3Dcode does).

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley Sent: Wednesday, July 23, 2014 10:33 AM
To: torsten@= lodderstedt.net


Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New V= ersion Notification for draft-hunt-oauth-v2-user-a4c-05.txt=
=C2=A0
=C2=A0

If we use the token endpoint then a new grant_t= ype is the best way.=C2=A0=

=C2=A0

It sort of overloads code, but that is better t= han messing with response_type for the authorization endpoint to change the= response from the token_endpoint. =C2=A0That is in my opinion a champion b= ad idea.=C2=A0

=C2=A0

In discussions developing Connect we decided no= t to open this can of worms because no good would come of it. =C2=A0=C2=A0<= span style=3D"text-decoration:underline">

=C2=A0

The token_endpoint returns a access token. =C2= =A0Nothing requires scope to be associates with the token.=C2=A0

=C2=A0

That is the best solution. =C2=A0No change requ= ired. =C2=A0Better interoperability in my opinion.=C2=A0

=C2=A0

Still on my way to TO, getting in later today.= =C2=A0

=C2=A0

John B.=C2=A0

=C2=A0



Sent from my iPhone


On Jul 23, = 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled b= y the value of the parameter "grant_type". So there is no need to= introduce a new parameter.

wrt to a potential "no_access_token" grant type. I do not cons= ider this a good idea as it changes the semantics of the token endpoint (as= already pointed out by Thomas). This endpoint ALWAYS responds with an acce= ss token to any grant type. I therefore would prefer to use another endpoin= t for the intended purpose.

regards,
Torsten.

=C2=A0

Am 23.07.2014 13:04, schrieb Nat Sakimura:<= /p>

IMHO, changing the semantics of "response_= type" @ authz endpoint this way is not a good thing.=C2=A0

=C2=A0

Instead, defining a new parameter "respon= se_type" @ token endpoint, as I described in my previous message,=C2= =A0

probably is better. At least, it does not chang= e the semantics of the parameters of RFC6749.=C2=A0<= /p>

=C2=A0

=C2=A0Nat=C2=A0

=C2=A0

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:

No, I mean response_type=3Dnone and response_ty= pe=3Did_token don't generate a code or access token so you don't us= e the Token Endpoint (which is not the same as the Authentication Endpoint = BTW).

With response_type=3Dcode_for_id_token, you get= a code and exchange it for an id_token only, rather than an access_token, = so you're changing the semantics of the Token Endpoint.=

=C2=A0

I'm not saying it's a bad thing, just t= hat you can't really compare none and id_token with code_for_id_token.<= span style=3D"text-decoration:underline">

=C2=A0

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin= P. <jricher@mitr= e.org> wrote:

It's only "not using the token endpoin= t" because the token endpoint copy-pasted and renamed the authenticati= on endpoint.

=C2=A0

=C2=A0-- Justin

=C2=A0

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <= t.broyer@gmail.com<= /a>> wrote:



Except that these are about not using the Token= Endpoint at all, whereas the current proposal is about the Token Endpoint = not returning an access_token field in the JSON.

=C2=A0

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <= ;Michael.J= ones@microsoft.com> wrote:=

The response_type "= none" is already used in practice, which returns no access token.=C2= =A0 It was accepted by the designated experts and registered in the IANA OA= uth Authorization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parame= ters.xml#endpoint.=C2=A0 The registered "id_token" response t= ype also returns no access token.

=C2=A0
<= p class=3D"MsoNormal"> So I think the question of whether response types th= at result in no access token being returned are acceptable within OAuth 2.0= is already settled, as a practical matter.=C2=A0 Lots of OAuth implementat= ions are already using such response types.
=C2=A0
<= p class=3D"MsoNormal"> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 -- Mike

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
S= ent: Wednesday, July 23, 2014 7:09 AM
To:= Nat Sakimura
C= c: <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Versio= n Notification for draft-hunt-oauth-v2-user-a4c-05.txt

=C2=A0

Yes= . This is why it has to be discussed in the IETF.

=C2=A0

Phil

=C2=A0=

@independentid=

phil.hunt@oracle.com

=C2=A0
=C2=A0
=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <<= a href=3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com> wrote:

=C2=A0

Reading back the RFC6749, I am not sure if ther= e is a good way of suppressing access token from the response and still be = OAuth. It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 = The server issuing access tokens to the client after successfully
=C2= =A0 =C2=A0 =C2=A0 authenticating the resource owner and obtaining authoriza= tion.

=C2=A0

After all, OAuth is all about issuing access to= kens.=C2=A0

=C2=A0

Also, I take back my statement on the grant typ= e in my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are resp= ectively:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resou= rce owner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0

grant_type

=C2=A0=C2=A0=C2=A0 (string representing the) ty= pe of grant sent to the token endpoint to obtain the access token

=C2=A0

Thus, the grant sent to the token endpoint in t= his case is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well = defined in RFC6749, but it seems it is representing what is to be returned = from the authorization endpoint. To express what is to be returned from tok= en endpoint, perhaps defining a new parameter to the token endpoint, which = is a parallel to the response_type to the Authorization Endpoint seems to b= e a more symmetric way, though I am not sure at all if that is going to be = OAuth any more. One straw-man is to define a new parameter called response_= type to the token endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing w= hat is to be returned from the token endpoint.=C2=A0=

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint accord= ing to the values as the parallel to the multi-response type spec.=C2=A0

=C2=A0

Nat

=C2=A0 =C2=A0=C2=A0
=C2=A0
=C2=A0
=C2=A0

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com= >:

The draft is very clear.=C2=A0

Phil=


On Jul 23, = 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was= =C2=A0

"authorization_code_but_do_not_return_acce= ss_nor_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an exte= nsion can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that t= he binding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Shoul= d there be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0

=C2=A0

At the same time, if any other specification wa= nted to define=C2=A0

other type of tokens and have it returned from = the token endpoint,=C2=A0<= span style=3D"text-decoration:underline">

it can also use this grant type.=C2=A0

=C2=A0

If what you want is to define a new grant type = that returns ID Token only,=C2=A0=

then, I am with Justin. Since "other respo= nse than ID Token" is only=C2=A0

theoretical, this is a more plausible way forwa= rd, I suppose.=C2=A0

=C2=A0

Nat

=C2=A0

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:=

So the draft would literally turn into:

&quo= t;The a4c response type and grant type return an id_token from the token en= dpoint with no access token. All parameters and values are defined in OIDC.= "

Seems like the perfect mini extension draft for OIDF to do.

--= Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <= ;sakimura@gmail.com= > wrote:
>
> What about just defining a new grant type= in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>= ;:
>>
>> That would be nice. However oidc still needs t= he new grant type in order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 1= 1:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to J= ustin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 R= icher, Justin P. <jricher@mitre.org>:
>>>>
>>>> Error= s like these make it clear to me that it would make much more sense to deve= lop this document in the OpenID Foundation. It should be something that dir= ectly references OpenID Connect Core for all of these terms instead of rede= fining them. It's doing authentication, which is fundamentally what Ope= nID Connect does on top of OAuth, and I don't see a good argument for d= oing this work in this working group.
>>>>
>>>> =C2=A0-- Justin
>>>>=
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com>= ; wrote:
>>>>
>>>>>
>>>>>
>= ;>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM= , Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>>>
>>>>>> Thanks for your revi= ew, Thomas.=C2=A0 The "prompt=3Dconsent" definition being missing= is an editorial error.=C2=A0 It should be:
>>>>>> >>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>= >>>>
>>>>>> The Authorization Server SHOU= LD prompt the End-User for consent before returning information to the Clie= nt. If it cannot obtain consent, it MUST return an error, typically consent= _required.
>>>>>>
>>>>>> =C2=A0
>>&= gt;>>>
>>>>>> I'll plan to add it in the= next draft.
>>>>>
>>>>>
>>= >>> It looks like the consent_required error needs to be defined t= oo, and you might have forgotten to also import account_selection_required = from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>&= gt;>> =C2=A0
>>>>>>
>>>>>>= ; I agree that there's no difference between a response with multiple &= quot;amr" values that includes "mfa" and one that doesn'= t.=C2=A0 Unless a clear use case for why "mfa" is needed can be i= dentified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Tha= nks.
>>>>>
>>>>> How about "pwd&= quot; then? I fully understand that I should return "pwd" if the = user authenticated using a password, but what "the service if a client= secret is used" means in the definition for the "pwd" value= ?
>>>>>
>>>>> (Nota: I know you're at = IETF-90, I'm ready to wait 'til you come back ;-) )
>>>= ;>>
>>>>> --
>>>>> Thomas Broye= r
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _________= ______________________________________
>>>>> OAuth maili= ng list
>>>>> O= Auth@ietf.org
>>>>> https://www.ietf.org/mailman/list= info/oauth
>>>>
>>>>
>>>>
>>>= ;> _______________________________________________
>>>> = OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>&g= t;>>
>>>
>>>
>>>
>>&= gt; --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Found= ation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>><= br> >>> _______________________________________________
>>&= gt; OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/ma= ilman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)=
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en



<= /p>

=C2=A0

--
Nat Sakimura (=3Dnat)<= /span>

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_n= at_en



<= /p>

=C2=A0

--
Nat Sakimura (=3Dnat)<= /span>

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_n= at_en

=C2=A0


__________= _____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth



<= /p>

=C2=A0

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

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



<= /p>

=C2=A0

-- =
Thomas Broyer
/t=C9=94.= ma.b=CA=81wa.je/


__________= _____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth



<= /p>

=C2=A0

--
Nat Sakimura (=3Dnat) =

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_n= at_en

=C2=A0
_______________________________________________=

OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth<=
/pre>
=C2=A0
=C2=A0

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


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



=C2=A0
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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



=C2=A0
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
= 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
=C2=A0
=C2=A0

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



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/=
@_nat_en

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



--089e0111d758970f3704fef3b2af-- From nobody Thu Jul 24 10:26:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79D01A0AF4 for ; Thu, 24 Jul 2014 10:26: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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkGaiymmj9_1 for ; Thu, 24 Jul 2014 10:26:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C981A0AE1 for ; Thu, 24 Jul 2014 10:25:45 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB311.namprd03.prod.outlook.com (10.141.48.26) with Microsoft SMTP Server (TLS) id 15.0.995.11; Thu, 24 Jul 2014 17:25:41 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0995.011; Thu, 24 Jul 2014 17:25:41 +0000 From: Anthony Nadalin To: Brian Campbell , John Bradley Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpdsDt+c24NfaK06ekEi1OvV9MZutFmeAgABuQQCAACfBgIAABwoAgAAFHwCAACJ8AIAABDOAgAAAxwCAAASJAIAAAz+AgAAE4ACAAAGWgIAAEq+AgAAJNoCAAAOsAIAAAq8AgAAGTgCAAA3vkIABBUgAgAAXRgCAAAkXAIAAMVuAgAAAsoA= Date: Thu, 24 Jul 2014 17:25:41 +0000 Message-ID: <054c4958db6545cf99d3f0339e34c776@BLUPR03MB309.namprd03.prod.outlook.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.165.73] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(51704005)(377424004)(199002)(51444003)(24454002)(377454003)(105586002)(74316001)(19580395003)(106116001)(19580405001)(74502001)(4396001)(21056001)(81542001)(64706001)(19609705001)(15975445006)(551544002)(15395725005)(74662001)(83322001)(99286002)(86362001)(46102001)(99396002)(106356001)(85306003)(19617315012)(561944003)(92566001)(79102001)(66066001)(101416001)(33646002)(107046002)(19625215002)(2656002)(81342001)(93886003)(76482001)(76576001)(16236675004)(85852003)(19300405004)(77982001)(80022001)(83072002)(15202345003)(95666004)(76176999)(50986999)(86612001)(20776003)(87936001)(54356999)(31966008)(108616002)(42262001)(24736002)(559001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB311; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_054c4958db6545cf99d3f0339e34c776BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_NjpMPncwW1za3L3GLwuTpGrBdg Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 17:26:44 -0000 --_000_054c4958db6545cf99d3f0339e34c776BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T01HLCBob3cgY2FuIHlvdSBzYXkgdGhhdCB3aGVuIHRoZSBEeW5hbWtjIFJlZyBkb2VzIHRoZSBz YW1lIHRoaW5nIChkdXBsaWNhdGVzKSBidXQgdGhhdCBpcyBPSyB0byBkbw0KDQpGcm9tOiBPQXV0 aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1w YmVsbA0KU2VudDogVGh1cnNkYXksIEp1bHkgMjQsIDIwMTQgMTA6MjIgQU0NClRvOiBKb2huIEJy YWRsZXkNCkNjOiBvYXV0aEBpZXRmLm9yZyBsaXN0DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMt MDUudHh0DQoNCkknbSBzb3JyeSB0byBtaXNzIHdoYXQgd2lsbCBsaWtlbHkgYmUgYSB2ZXJ5IGVu Z2FnaW5nIG1lZXRpbmcgdG9kYXkuDQoNClRoZSBwcmVtaXNlIHRoYXQgc29tZSBkZXZlbG9wZXJz IGFyZSB1c2luZyBPQXV0aCBpbiBhIGluc2VjdXJlIHdheSB0byBkbyBhdXRoZW50aWNhdGlvbiBp cyBzb21ldGhpbmcgd2UgY2FuIHByb2JhYmx5IGFsbCBhZ3JlZSBvbi4NCg0KSXQgZG9lc24ndCBu ZWNlc3NhcmlseSBmb2xsb3cgZnJvbSB0aGF0IHByZW1pc2UsIGhvd2V2ZXIsIHRoYXQgdGhlIHNv bHV0aW9uIGlzIHlldCBhbm90aGVyIHNwZWMgd2hpY2ggZWl0aGVyIGR1cGxpY2F0ZXMgc29tZSBz dWJzZXQgb2YgT3BlbklEIENvbm5lY3QgKGluIGEgZGlmZmVyZW50IFNETykgb3IgZm9ya3MgaG93 IHRvIGRvIFNTTy9hdXRoZW50aWNhdGlvbiB1c2luZyBPQXV0aC4NCg0KT24gVGh1LCBKdWwgMjQs IDIwMTQgYXQgNzoyNSBBTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86 dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCkkgYW0gbm90IGFnYWluc3QgZGlzY3Vzc2lvbiBp biB0aGUgV0cuDQoNCkkgaGFwcGVuIHRvIGFncmVlIHdpdGggUGhpbCdzIGZ1bmRhbWVudGFsIHBy ZW1pc2UgdGhhdCBzb21lIGRldmVsb3BlcnMgYXJlIHVzaW5nIE9BdXRoIGluIGEgaW5zZWN1cmUg d2F5IHRvIGRvIGF1dGhlbnRpY2F0aW9uLg0KDQpUaGF0IHJhaXNlcyB0aGUgcXVlc3Rpb24gb2Yg aG93IHRvIGJlc3QgZWR1Y2F0ZSB0aGVtLCBhbmQgb3IgYWRkcmVzcyB0ZWNobmljYWwgYmFycmll cnMuDQoNCkl0IGlzIG9uIHRoZSBzZWNvbmQgcG9pbnQgdGhhdCBwZW9wbGUncyBvcGluaW9ucyBz ZWVtIHRvIGRpdmlkZS4NCg0KU29tZSBwZW9wbGUgdGhpbmcgdGhhdCBpZiB3ZSBoYXZlIGEgT0F1 dGggZmxvdyB0aGF0IGVsaW1pbmF0ZXMgdGhlIGFjY2VzcyB0b2tlbiAocHJpbWFyaWx5IHRvIGF2 b2lkIGFza2luZyBmb3IgY29uc2VudCBhcyBJIHVuZGVyc3RhbmQgaXQpIGFuZCBqdXN0IHJldHVy biBhIGlkX3Rva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IHRoYXQgY2FuIGJlIGRvbmUgaW4g YSBzcGVjIHNob3J0IGVub3VnaCB0byBoZXQgcGVvcGxlIHRvIHJlYWQuICAgVGhlIHN1YnRleHQg b2YgdGhpcyBpcyB0aGF0IHRoZSBDb25uZWN0IHNwZWNpZmljYXRpb24gaXMgdG9vIGxhcmdlIHRo YXQgaXQgc2NhcmUgcGVvcGxlLCAgYW5kIHRoZXkgZG9uJ3QgZmluZCB0aGUgc3BlYyBpbiB0aGUg Zmlyc3QgcGxhY2UgYmVjYXVzZSBpdCBpcyBub3QgYSBSRkMuDQoNCkFuIG90aGVyIGNvbW1vbiBw b3NzZXNzaW9uIGlzIHRoYXQgaWYgeW91IGRvbid0IHdhbnQgdG8gcHJvbXB0IHRoZSB1c2VyIGZv ciBjb25zZW50IHRoZW4gZG9uJ3QgYXNrIGZvciBzY29wZXMuICBUd2lzdGluZyB0aGUgT0F1dGgg c3BlYyB0byBub3QgcmV0dXJuIGFuIGFjY2VzcyB0b2tlbiBpcyBub3QgT0F1dGgsICB5ZXMgeW91 IGNvdWxkIHVzZSBhIGRpZmZlcmVudCBlbmRwb2ludCByYXRoZXIgdGhhbiB0aGUgdG9rZW4gZW5k cG9pbnQsIGJ1dCB0aGF0IGlzIG5vdCBPQXV0aC4gICBDb25uZWN0IHdhcyBjYXJlZnVsIG5vdCB0 byBicmVhayB0aGUgT0F1dGggc3BlYy4gICAgQXMgbG9uZyBhcyB5b3UgYXJlIHdpbGxpbmcgdG8g dGFrZSBhIGFjY2VzcyB0b2tlbiB3aXRoIG5vIHNjb3BlcyAodGhlIGNsaWVudCBuZWVkcyB0byB1 bmRlcnN0YW5kIHRoYXQgdGhlcmUgYXJlIG5vIGF0dHJpYnV0ZXMgb25lIHdheSBvciBhbm90aGVy IGFueXdheSBvciBpdCB3aWxsIGJyZWFrKSB0aGVuIHlvdSBkb24ndCBuZWVkIHRvIGNoYW5nZSBP QXV0aC4gICBZb3UgY2FuIHB1Ymxpc2ggYSBwcm9maWxlIG9mIGNvbm5lY3QgdGhhdCBzYXRpc2Zp ZXMgdGhlIHVzZSBjYXNlLg0KDQpJIHRoaW5rIE1pa2UgaGFzIGxhcmdlbHkgZG9uZSB0aGF0IGJ1 dCBpdCBtaWdodCBiZSBiZXR0ZXIgYmVpbmcgbGVzcyBzdGluZ3kgb24gcmVmZXJlbmNlcyBiYWNr IHRvIHRoZSBsYXJnZXIgc3BlYy4NCg0KVGhlIHF1ZXN0aW9ucyBhcmUgZG8gd2UgbW9kaWZ5IE9B dXRoIHRvIG5vdCByZXR1cm4gYW4gYWNjZXNzIHRva2VuLCBhbmQgaWYgc28gaG93LCAgYW5kIGlm IHdlIGRvIGlzIGl0IHN0aWxsIE9BdXRoLg0KDQpUaGUgb3RoZXIgbGFyZ2VseSBzZXBhcmFibGUg cXVlc3Rpb24gaXMgZG8gd2UgY3JlYXRlIGNvbmZ1c2lvbiBpbiB0aGUgbWFya2V0IGFuZCBzbG93 IHRoZSB0aGUgYWRvcHRpb24gb2YgaWRlbnRpdHkgZmVkZXJhdGlvbiBvbiB0b3Agb2YgT0F1dGgs IG9yIGZpbmQgYSB3YXkgdG8gbWFrZSB0aGlzIGxvb2sgbGlrZSBhIHBvc2l0aXZlIGFsaWdubWVu dCBvZiBpbnRlcmVzdHMgYXJvdW5kIGEgc3Vic2V0IG9mIENvbm5lY3QuDQoNClRoZXJlIGFyZSBh IG51bWJlciBvZiBvcHRpb25zLg0KMTogV2UgY2FuIGRvIGEgcHJvZmlsZSBpbiB0aGUgT0lERiBh bmQgcHVibGlzaCBpdCBhcyBhIElFVEYgZG9jdW1lbnQuICAgUGVyaGFwcyB0aGUgY2xlYW5lc3Qg ZnJvbSBhbiBJUFIgcG9pbnQgb2Ygdmlldy4NCjI6V2UgY2FuIGRvIGEgcHJvZmlsZSBpbiB0aGUg T0F1dGggV0cgcmVmZXJlbmNpbmcgY29ubmVjdC4NCjM6V2UgY2FuIGRvIGEgQUQgc3BvbnNvcmVk IHByb2ZpbGUgdGhhdCBpcyBub3QgaW4gdGhlIE9BdXRoIFdHLg0KNDpXZSBjYW4gZG8gYSBzbWFs bCBzcGVjIGluIE9BdXRoIHRvIGFkZCByZXNwb25zZV90eXBlIHRvIHRoZSB0b2tlbiBlbmRwb2lu dC4gIGluIGNvbWJpbmF0aW9uIHdpdGggMSwgMiwgb3IgMw0KDQpJIGFncmVlIHRoYXQgc3RvcGlu ZyBkZXZlbG9wZXJzIGRvaW5nIGluc2VjdXJlIHRoaW5ncyBuZWVkcyB0byBiZSBhZGRyZXNzZWQg c29tZWhvdy4NCkkgYW0gbm90IHBlcnNvbmFsbHkgY29udmluY2VkIHRoYXQgT2F1dGggd2l0aG91 dCBhY2Nlc3MgdG9rZW5zIGlzIHNlbnNpYmxlLg0KDQpMb29raW5nIGZvcndhcmQgdG8gdGhlIG1l ZXRpbmc6KQ0KDQpKb2huIEIuDQoNCk9uIEp1bCAyNCwgMjAxNCwgYXQgNjo1MiBBTSwgQnJpYW4g Q2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KDQoNCkknZCBub3RlIHRoYXQgdGhlIHJlYWN0aW9uIGF0 IHRoZSBjb25mZXJlbmNlIHRvIElhbidzIHN0YXRlbWVudCB3YXMgb3ZlcndoZWxtaW5nbHkgcG9z aXRpdmUuIFRoZXJlIHdhcyBhIHdpZGUgcmFuZ2Ugb2YgaW5kdXN0cnkgcGVvcGxlIGhlcmUgLSBp bXBsZW1lbnRlcnMsIHByYWN0aXRpb25lcnMsIGRlcGxveWVycywgc3RyYXRlZ2lzdHMsIGV0Yy4g LSBhbmQgaXQgc2VlbXMgcHJldHR5IGNsZWFyIHRoYXQgdGhlICJyb3VnaCBjb25zZW5zdXMiIG9m IHRoZSBpbmR1c3RyeSBhdCBsYXJnZSBpcyB0aGF0IGE0YyBpcyBub3Qgd2FudGVkIG9yIG5lZWRl ZC4NCg0KT24gVGh1LCBKdWwgMjQsIDIwMTQgYXQgNToyOSBBTSwgTmF0IFNha2ltdXJhIDxzYWtp bXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KQW5kIGhl cmUgaXMgYSBxdW90ZSBmcm9tIElhbidzIGJsb2cuDQoNCkFuZCBhbHRob3VnaCB0aGUgYXV0aGVu dGljYXRpb24gd2hlZWwgaXMgcm91bmQsIHRoYXQgZG9lc27igJl0IG1lYW4gaXQgaXNu4oCZdCB3 aXRob3V0IGl0cyBsdW1wcy4gRmlyc3QsIHdlIGRvIHNlZSBzb21lIHJlaW52ZW50aW5nIHRoZSB3 aGVlbCBqdXN0IHRvIHJlaW52ZW50IHRoZSB3aGVlbC4gT0F1dGggQTRDIGlzIHNpbXBseSBub3Qg YSBmcnVpdGZ1bCBhY3Rpdml0eSBhbmQgc2hvdWxkIGJlIHB1dCBkb3duLg0KDQooU291cmNlKSBo dHRwOi8vd3d3LnR1ZXNkYXluaWdodC5vcmcvMjAxNC8wNy8yMy9kby13ZS1oYXZlLWEtcm91bmQt d2hlZWwteWV0LW11c2luZ3Mtb24taWRlbnRpdHktc3RhbmRhcmRzLXBhcnQtMS5odG1sDQoNCjIw MTQtMDctMjMgMTY6NTMgR01ULTA0OjAwIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208 bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj46DQoNCkkgdGhvdWdodCBJIGRpZCBwb3N0IHRoaXMg dG8gdGhlIGxpc3QuDQoNCkkgZ3Vlc3MgSSBoaXQgdGhlIHdyb25nIHJlcGx5IG9uIG15IHBob25l Lg0KDQpKb2huIEIuDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIEp1bCAyMywgMjAxNCwgYXQg NDo1MCBQTSwgdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0PiB3cm90ZToNCg0Kd2UgYXJlIHR3bywgYXQgbGVhc3QgOi0pDQoNCldoeSBkaWRuJ3Qg eW91IHBvc3QgdGhpcyBvbiB0aGUgbGlzdD8NCg0KV2hlbiB3aWxsIGJlIGJlIGFycml2aW5nPw0K DQpBbSAyMy4wNy4yMDE0IDE2OjM5LCBzY2hyaWViIEpvaG4gQnJhZGxleToNCklhbiBHbGF6ZXIg bWVudGlvbmVkIHRoaXMgaW4gaGlzIGtleW5vdGUgYXQgQ0lTIHllc3RlcmRheS4NCg0KSGlzIGFk dmljZSB3YXMgcGxlYXNlIHN0b3AsICB3ZSBhcmUgY3JlYXRpbmcgY29uZnVzaW9uIGFuZCB1bmNl cnRhaW50eS4NCg0KV2UgYXJlIGJlY29taW5nIG91ciBvd24gd29ydCBlbmVteS4gKCBteSB2aWV3 IHRob3VnaCBJYW4gbWF5IHNoYXJlIGl0KQ0KDQpSZXR1cm5pbmcganVzdCBhbiBpZF8gdG9rZW4g ZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgaGFzIGxpdHRsZSByZWFsIHZhbHVlLg0KDQpTb21ldGhp bmcgcmVhbGx5IHVzZWZ1bCB0byBkbyB3b3VsZCBiZSBzb3J0aW5nIG91dCBjaGFubmVsX2lkIHNv IHdlIGNhbiBkbyBQb1AgZm9yIGlkIHRva2VucyB0byBtYWtlIHRoZW0gYW5kIG90aGVyIGNvb2tp ZXMgc2VjdXJlIGluIHRoZSBmcm9udCBjaGFubmVsLiAgIEkgdGhpbmsgdGhhdCBpcyBhIGJldHRl ciB1c2Ugb2YgdGltZS4NCg0KSSBtYXkgYmUgaW4gdGhlIG1pbm9yaXR5IG9waW5pb24gb24gdGhh dCwgIGl0IHdvbid0IGJlIHRoZSBmaXJzdCB0aW1lLg0KDQoNCkpvaG4gQi4NClNlbnQgZnJvbSBt eSBpUGhvbmUNCg0KT24gSnVsIDIzLCAyMDE0LCBhdCA0OjA0IFBNLCBUb3JzdGVuIExvZGRlcnN0 ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5u ZXQ+PiB3cm90ZToNCllvdSBhcmUgcmlnaHQgZnJvbSBhIHRoZW9yZXRpY2FsIHBlcnNwZWN0aXZl LiBQcmFjdGljYWxseSB0aGlzIHdhcyBjYXVzZWQgYnkgZWRpdG9yaWFsIGRlY2lzaW9ucyBkdXJp bmcgdGhlIGNyZWF0aW9uIG9mIHRoZSBSRkMuIEFzIGZhciBhcyBJIHJlbWVtYmVyLCB0aGVyZSB3 YXMgYSBkZWZpbml0aW9uIG9mIHRoZSAob25lKSB0b2tlbiBlbmRwb2ludCByZXNwb25zZSBpbiBl YXJseSB2ZXJzaW9ucy4gTm8gb25lIGV2ZXJ5IGNvbnNpZGVyZWQgdG8gTk9UIHJlc3BvbmQgd2l0 aCBhbiBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQuIFNvIG9uZSBtaWdodCBj YWxsIGl0IGFuIGltcGxpY2l0IGFzc3VtcHRpb24uDQoNCkknbSB3b3JyaWVkIHRoYXQgcGVvcGxl IGdldCB0b3RhbGx5IGNvbmZ1c2VkIGlmIGFuIGV4Y2VwdGlvbiBpcyBpbnRyb2R1Y2VkIG5vdyBn aXZlbiB0aGUgYnJvYWQgYWRvcHRpb24gb2YgT0F1dGggYmFzZWQgb24gdGhpcyBhc3N1bXB0aW9u Lg0KDQpyZWdhcmRzLA0KVG9yc3Rlbi4NCg0KQW0gMjMuMDcuMjAxNCB1bSAxNTo0MSBzY2hyaWVi IFRob21hcyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21haWwu Y29tPj46DQoNCklzIGl0IHNhaWQgYW55d2hlcmUgdGhhdCBBTEwgZ3JhbnQgdHlwZXMgTVVTVCB1 c2UgU2VjdGlvbiA1LjEgcmVzcG9uc2VzPyBFYWNoIGdyYW50IHR5cGUgcmVmZXJlbmNlcyBTZWN0 aW9uIDUuMSwgYW5kICJhY2Nlc3MgdG9rZW4gcmVxdWVzdCIgaXMgb25seSBkZWZpbmVkIGluIHRo ZSBjb250ZXh0IG9mIHRoZSBkZWZpbmVkIGdyYW50IHR5cGVzLiBTZWN0aW9uIDIuMiBkb2Vzbid0 IHRhbGsgYWJvdXQgdGhlIHJlcXVlc3Qgb3IgcmVzcG9uc2UgZm9ybWF0Lg0KTGUgMjMganVpbC4g MjAxNCAyMTozMiwgIk5hdCBTYWtpbXVyYSIgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2Fr aW11cmFAZ21haWwuY29tPj4gYSDDqWNyaXQgOg0KSXMgaXQ/IEFwYXJ0IGZyb20gdGhlIGltcGxp Y2l0IGdyYW50IHRoYXQgZG9lcyBub3QgdXNlIHRva2VuIGVuZHBvaW50LCBhbGwgb3RoZXIgZ3Jh bnQgcmVmZXJlbmNlcyBzZWN0aW9uIDUuMSBmb3IgdGhlIHJlc3BvbnNlLCBpLmUuLCBhbGwgc2hh cmVzIHRoZSBzYW1lIHJlc3BvbnNlLg0KDQoyMDE0LTA3LTIzIDE1OjE4IEdNVC0wNDowMCBUaG9t YXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+ Og0KDQpJIGhhZG4ndCByZWFsaXplZCB0aGUgSlNPTiByZXNwb25zZSB0aGF0IHJlcXVpcmVzIHRo ZSBhY2Nlc3NfdG9rZW4gZmllbGQgaXMgZGVmaW5lZCBwZXIgZ3JhbnRfdHlwZSwgc28gSSdkIGJl IE9LIHRvICJleHRlbmQgdGhlIHNlbWFudGljcyIgYXMgaW4gdGhlIGN1cnJlbnQgZHJhZnQuDQpU aGF0IHdhcyBhY3R1YWxseSBteSBtYWluIGNvbmNlcm46IHRoYXQgdGhlIHRva2VuIGVuZHBvaW50 IG1hbmRhdGVzIGFjY2Vzc190b2tlbjsgYnV0IGl0cyBhY3R1YWxseSBub3QgdGhlIGNhc2UuDQpM ZSAyMyBqdWlsLiAyMDE0IDIwOjQ2LCAiTmF0IFNha2ltdXJhIiA8c2FraW11cmFAZ21haWwuY29t PG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiBhIMOpY3JpdCA6DQoNCkkgYWdyZWUgd2l0aCBK b2huIHRoYXQgb3ZlcmxvYWRpbmcgcmVzcG9uc2VfdHlwZSBAIGF1dGh6IGVuZHBvaW50IGlzIGEg YmFkIGlkZWEuIEl0IGNvbXBsZXRlbHkgY2hhbmdlcyB0aGUgc2VtYW50aWNzIG9mIHRoaXMgcGFy YW1ldGVyLiBOT1RFOiB3aGF0IEkgd2FzIHByb3Bvc2luZyB3YXMgbm90IHRoaXMgcGFyYW1ldGVy LCBidXQgYSBuZXcgcGFyYW1ldGVyIHJlc3BvbnNlX3R5cGUgQCB0b2tlbiBlbmRwb2ludC4NCg0K SSBhbHNvIHRoaW5rIG92ZXJsb2FkaW5nIGdyYW50X3R5cGUgaXMgYSBiYWQgaWRlYSBzaW5jZSBp dCBjaGFuZ2VzIGl0cyBzZW1hbnRpY3MuIEkgcXVvdGUgdGhlIGRlZmluaXRpb24gaGVyZSBhZ2Fp bjoNCg0KZ3JhbnQNCiAgICBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3VyY2Ugb3du ZXIncyBhdXRob3JpemF0aW9uDQoNCmdyYW50X3R5cGUNCnR5cGUgb2YgZ3JhbnQgc2VudCB0byB0 aGUgdG9rZW4gZW5kcG9pbnQgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW4NCg0KSXQgaXMgbm90 IGFib3V0IGNvbnRyb2xsaW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUgdG9rZW4g ZW5kcG9pbnQsIGJ1dCB0aGUgaGludCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgZGVzY3JpYmluZyB0 aGUgdHlwZSBvZiBjcmVkZW50aWFsIHRoZSBlbmRwb2ludCBoYXMgcmVjZWl2ZWQuIEl0IHNlZW1z IHRoZSAiY29udHJvbCBvZiB3aGF0IGlzIGJlaW5nIHJldHVybmVkIGZyb20gdG9rZW4gZW5kcG9p bnQiICBpcyBqdXN0IGEgc2lkZSBlZmZlY3QuDQoNCkkgYW0gc29tZXdoYXQgYW1iaXZhbGVudFsx XSBpbiBjaGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mIHRva2VuIGVuZHBvaW50LCBidXQgaW4gYXMg bXVjaCBhcyAidGV4dCBpcyB0aGUga2luZyIgZm9yIGEgc3BlYy4sIHdlIHByb2JhYmx5IHNob3Vs ZCBub3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgaXQgYXMgVG9yc3RlbiBwb2ludHMgb3V0LiBJ ZiBpdCBpcyBvayB0byBjaGFuZ2UgdGhpcyBzZW1hbnRpY3MsIEkgYmVsaWV2ZSBkZWZpbmluZyBh IG5ldyBwYXJhbWV0ZXIgdG8gdGhpcyBlbmRwb2ludCB0byBjb250cm9sIHRoZSByZXNwb25zZSB3 b3VsZCBiZSB0aGUgYmVzdCB3YXkgdG8gZ28uIFRoaXMgaXMgd2hhdCBJIGhhdmUgZGVzY3JpYmVk IHByZXZpb3VzbHkuDQoNCkRlZmluaW5nIGEgbmV3IGVuZHBvaW50IHRvIHNlbmQgY29kZSB0byBn ZXQgSUQgVG9rZW4gYW5kIGZvcmJpZGRpbmcgdGhlIHVzZSBvZiBpdCBhZ2FpbnN0IHRva2VuIGVu ZHBvaW50IHdvdWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBhbnkgZXhpc3RpbmcgcGFy YW1ldGVyIG9yIGVuZHBvaW50LCB3aGljaCBpcyBnb29kLiBIb3dldmVyLCBJIGRvdWJ0IGlmIGl0 IGlzIG5vdCB3b3J0aCBkb2luZy4gV2hhdCdzIHRoZSBwb2ludCBvZiBhdm9pZGluZyBhY2Nlc3Mg dG9rZW4gc2NvcGVkIHRvIFVzZXJJbmZvIGVuZHBvaW50IGFmdGVyIGFsbD8gRGVmaW5pbmcgYSBu ZXcgZW5kcG9pbnQgZm9yIGp1c3QgYXZvaWRpbmcgdGhlIGFjY2VzcyB0b2tlbiBmb3IgdXNlcmlu Zm8gZW5kcG9pbnQgc2VlbXMgd2F5IHRvbyBtdWNoIHRoZSBoZWF2eSB3YWl0IHdheSBhbmQgaXQg YnJlYWtzIGludGVyb3BlcmFiaWxpeTogaXQgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBzdGFuZGFy ZGl6YXRpb24uDQoNCkkgaGF2ZSBzdGFydGVkIGZlZWxpbmcgdGhhdCBubyBjaGFuZ2UgaXMgdGhl IGJlc3Qgd2F5IG91dC4NCg0KTmF0DQoNClsxXSAgSWYgaW5zdGVhZCBvZiBzYXlpbmcgIlRva2Vu IGVuZHBvaW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRp b24gZ3JhbnQgZm9yIGFuIGFjY2VzcyB0b2tlbiwgdHlwaWNhbGx5IHdpdGggY2xpZW50IGF1dGhl bnRpY2F0aW9uIiwgaXQgd2VyZSBzYXlpbmcgIlRva2VuIGVuZHBvaW50IC0gdXNlZCBieSB0aGUg Y2xpZW50IHRvIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgZm9yIHRva2VucywgdHlw aWNhbGx5IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0aW9uIiwgdGhlbiBpdCB3b3VsZCBoYXZlIGJl ZW4gT0suIEl0IGlzIGFuIGV4cGFuc2lvbiBvZiB0aGUgY2FwYWJpbGl0eSByYXRoZXIgdGhhbiBj aGFuZ2luZyB0aGUgc2VtYW50aWNzLg0KDQoNCjIwMTQtMDctMjMgMTM6MzkgR01ULTA0OjAwIE1p a2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPj46DQpZb3UgbmVlZCB0aGUgYWx0ZXJuYXRpdmUgcmVzcG9uc2VfdHlw ZSB2YWx1ZSAoImNvZGVfZm9yX2lkX3Rva2VuIiBpbiB0aGUgQTRDIGRyYWZ0KSB0byB0ZWxsIHRo ZSBBdXRob3JpemF0aW9uIFNlcnZlciB0byByZXR1cm4gYSBjb2RlIHRvIGJlIHVzZWQgd2l0aCB0 aGUgbmV3IGdyYW50IHR5cGUsIHJhdGhlciB0aGFuIG9uZSB0byB1c2Ugd2l0aCB0aGUgImF1dGhv cml6YXRpb25fY29kZSIgZ3JhbnQgdHlwZSAod2hpY2ggaXMgd2hhdCByZXNwb25zZV90eXBlPWNv ZGUgZG9lcykuDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkN ClNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMywgMjAxNCAxMDozMyBBTQ0KVG86IHRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4NCg0KQ2M6IG9hdXRo QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0 Yy0wNS50eHQNCg0KDQpJZiB3ZSB1c2UgdGhlIHRva2VuIGVuZHBvaW50IHRoZW4gYSBuZXcgZ3Jh bnRfdHlwZSBpcyB0aGUgYmVzdCB3YXkuDQoNCkl0IHNvcnQgb2Ygb3ZlcmxvYWRzIGNvZGUsIGJ1 dCB0aGF0IGlzIGJldHRlciB0aGFuIG1lc3Npbmcgd2l0aCByZXNwb25zZV90eXBlIGZvciB0aGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludCB0byBjaGFuZ2UgdGhlIHJlc3BvbnNlIGZyb20gdGhlIHRv a2VuX2VuZHBvaW50LiAgVGhhdCBpcyBpbiBteSBvcGluaW9uIGEgY2hhbXBpb24gYmFkIGlkZWEu DQoNCkluIGRpc2N1c3Npb25zIGRldmVsb3BpbmcgQ29ubmVjdCB3ZSBkZWNpZGVkIG5vdCB0byBv cGVuIHRoaXMgY2FuIG9mIHdvcm1zIGJlY2F1c2Ugbm8gZ29vZCB3b3VsZCBjb21lIG9mIGl0Lg0K DQpUaGUgdG9rZW5fZW5kcG9pbnQgcmV0dXJucyBhIGFjY2VzcyB0b2tlbi4gIE5vdGhpbmcgcmVx dWlyZXMgc2NvcGUgdG8gYmUgYXNzb2NpYXRlcyB3aXRoIHRoZSB0b2tlbi4NCg0KVGhhdCBpcyB0 aGUgYmVzdCBzb2x1dGlvbi4gIE5vIGNoYW5nZSByZXF1aXJlZC4gIEJldHRlciBpbnRlcm9wZXJh YmlsaXR5IGluIG15IG9waW5pb24uDQoNClN0aWxsIG9uIG15IHdheSB0byBUTywgZ2V0dGluZyBp biBsYXRlciB0b2RheS4NCg0KSm9obiBCLg0KDQoNCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpP biBKdWwgMjMsIDIwMTQsIGF0IDEyOjE1IFBNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWls dG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KDQpUaGUgInJlc3BvbnNlIHR5cGUi IG9mIHRoZSB0b2tlbiBlbmRwb2ludCBpcyBjb250cm9sbGVkIGJ5IHRoZSB2YWx1ZSBvZiB0aGUg cGFyYW1ldGVyICJncmFudF90eXBlIi4gU28gdGhlcmUgaXMgbm8gbmVlZCB0byBpbnRyb2R1Y2Ug YSBuZXcgcGFyYW1ldGVyLg0KDQp3cnQgdG8gYSBwb3RlbnRpYWwgIm5vX2FjY2Vzc190b2tlbiIg Z3JhbnQgdHlwZS4gSSBkbyBub3QgY29uc2lkZXIgdGhpcyBhIGdvb2QgaWRlYSBhcyBpdCBjaGFu Z2VzIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHRva2VuIGVuZHBvaW50IChhcyBhbHJlYWR5IHBvaW50 ZWQgb3V0IGJ5IFRob21hcykuIFRoaXMgZW5kcG9pbnQgQUxXQVlTIHJlc3BvbmRzIHdpdGggYW4g YWNjZXNzIHRva2VuIHRvIGFueSBncmFudCB0eXBlLiBJIHRoZXJlZm9yZSB3b3VsZCBwcmVmZXIg dG8gdXNlIGFub3RoZXIgZW5kcG9pbnQgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlLg0KDQpyZWdh cmRzLA0KVG9yc3Rlbi4NCg0KDQpBbSAyMy4wNy4yMDE0IDEzOjA0LCBzY2hyaWViIE5hdCBTYWtp bXVyYToNCklNSE8sIGNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgInJlc3BvbnNlX3R5cGUiIEAg YXV0aHogZW5kcG9pbnQgdGhpcyB3YXkgaXMgbm90IGEgZ29vZCB0aGluZy4NCg0KSW5zdGVhZCwg ZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVyICJyZXNwb25zZV90eXBlIiBAIHRva2VuIGVuZHBvaW50 LCBhcyBJIGRlc2NyaWJlZCBpbiBteSBwcmV2aW91cyBtZXNzYWdlLA0KcHJvYmFibHkgaXMgYmV0 dGVyLiBBdCBsZWFzdCwgaXQgZG9lcyBub3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHBh cmFtZXRlcnMgb2YgUkZDNjc0OS4NCg0KIE5hdA0KDQoyMDE0LTA3LTIzIDEyOjQ4IEdNVC0wNDow MCBUaG9tYXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWls LmNvbT4+Og0KTm8sIEkgbWVhbiByZXNwb25zZV90eXBlPW5vbmUgYW5kIHJlc3BvbnNlX3R5cGU9 aWRfdG9rZW4gZG9uJ3QgZ2VuZXJhdGUgYSBjb2RlIG9yIGFjY2VzcyB0b2tlbiBzbyB5b3UgZG9u J3QgdXNlIHRoZSBUb2tlbiBFbmRwb2ludCAod2hpY2ggaXMgbm90IHRoZSBzYW1lIGFzIHRoZSBB dXRoZW50aWNhdGlvbiBFbmRwb2ludCBCVFcpLg0KV2l0aCByZXNwb25zZV90eXBlPWNvZGVfZm9y X2lkX3Rva2VuLCB5b3UgZ2V0IGEgY29kZSBhbmQgZXhjaGFuZ2UgaXQgZm9yIGFuIGlkX3Rva2Vu IG9ubHksIHJhdGhlciB0aGFuIGFuIGFjY2Vzc190b2tlbiwgc28geW91J3JlIGNoYW5naW5nIHRo ZSBzZW1hbnRpY3Mgb2YgdGhlIFRva2VuIEVuZHBvaW50Lg0KDQpJJ20gbm90IHNheWluZyBpdCdz IGEgYmFkIHRoaW5nLCBqdXN0IHRoYXQgeW91IGNhbid0IHJlYWxseSBjb21wYXJlIG5vbmUgYW5k IGlkX3Rva2VuIHdpdGggY29kZV9mb3JfaWRfdG9rZW4uDQoNCk9uIFdlZCwgSnVsIDIzLCAyMDE0 IGF0IDY6NDUgUE0sIFJpY2hlciwgSnVzdGluIFAuIDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86 anJpY2hlckBtaXRyZS5vcmc+PiB3cm90ZToNCkl0J3Mgb25seSAibm90IHVzaW5nIHRoZSB0b2tl biBlbmRwb2ludCIgYmVjYXVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgY29weS1wYXN0ZWQgYW5kIHJl bmFtZWQgdGhlIGF1dGhlbnRpY2F0aW9uIGVuZHBvaW50Lg0KDQogLS0gSnVzdGluDQoNCk9uIEp1 bCAyMywgMjAxNCwgYXQgOTozMCBBTSwgVGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29t PG1haWx0bzp0LmJyb3llckBnbWFpbC5jb20+PiB3cm90ZToNCg0KRXhjZXB0IHRoYXQgdGhlc2Ug YXJlIGFib3V0IG5vdCB1c2luZyB0aGUgVG9rZW4gRW5kcG9pbnQgYXQgYWxsLCB3aGVyZWFzIHRo ZSBjdXJyZW50IHByb3Bvc2FsIGlzIGFib3V0IHRoZSBUb2tlbiBFbmRwb2ludCBub3QgcmV0dXJu aW5nIGFuIGFjY2Vzc190b2tlbiBmaWVsZCBpbiB0aGUgSlNPTi4NCg0KT24gV2VkLCBKdWwgMjMs IDIwMTQgYXQgNDoyNiBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRoZSByZXNwb25z ZV90eXBlICJub25lIiBpcyBhbHJlYWR5IHVzZWQgaW4gcHJhY3RpY2UsIHdoaWNoIHJldHVybnMg bm8gYWNjZXNzIHRva2VuLiAgSXQgd2FzIGFjY2VwdGVkIGJ5IHRoZSBkZXNpZ25hdGVkIGV4cGVy dHMgYW5kIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkEgT0F1dGggQXV0aG9yaXphdGlvbiBFbmRwb2lu dCBSZXNwb25zZSBUeXBlcyByZWdpc3RyeSBhdCBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1l bnRzL29hdXRoLXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54bWwjZW5kcG9pbnQuICBUaGUg cmVnaXN0ZXJlZCAiaWRfdG9rZW4iIHJlc3BvbnNlIHR5cGUgYWxzbyByZXR1cm5zIG5vIGFjY2Vz cyB0b2tlbi4NCg0KU28gSSB0aGluayB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciByZXNwb25zZSB0 eXBlcyB0aGF0IHJlc3VsdCBpbiBubyBhY2Nlc3MgdG9rZW4gYmVpbmcgcmV0dXJuZWQgYXJlIGFj Y2VwdGFibGUgd2l0aGluIE9BdXRoIDIuMCBpcyBhbHJlYWR5IHNldHRsZWQsIGFzIGEgcHJhY3Rp Y2FsIG1hdHRlci4gIExvdHMgb2YgT0F1dGggaW1wbGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IHVz aW5nIHN1Y2ggcmVzcG9uc2UgdHlwZXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn Pl0gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0 IDc6MDkgQU0NClRvOiBOYXQgU2FraW11cmENCkNjOiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9h dXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQNCg0KWWVzLiBU aGlzIGlzIHdoeSBpdCBoYXMgdG8gYmUgZGlzY3Vzc2VkIGluIHRoZSBJRVRGLg0KDQpQaGlsDQoN CkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVu ZGVudGlkLmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20+DQoNCg0KDQpPbiBKdWwgMjMsIDIwMTQsIGF0IDk6NDMgQU0sIE5hdCBTYWtpbXVyYSA8 c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCg0K UmVhZGluZyBiYWNrIHRoZSBSRkM2NzQ5LCBJIGFtIG5vdCBzdXJlIGlmIHRoZXJlIGlzIGEgZ29v ZCB3YXkgb2Ygc3VwcHJlc3NpbmcgYWNjZXNzIHRva2VuIGZyb20gdGhlIHJlc3BvbnNlIGFuZCBz dGlsbCBiZSBPQXV0aC4gSXQgd2lsbCBicmVhayB3aG9sZSBidW5jaCBvZiBpbXBsaWNpdCBkZWZp bml0aW9ucyBsaWtlOg0KDQphdXRob3JpemF0aW9uIHNlcnZlcg0KICAgICAgVGhlIHNlcnZlciBp c3N1aW5nIGFjY2VzcyB0b2tlbnMgdG8gdGhlIGNsaWVudCBhZnRlciBzdWNjZXNzZnVsbHkNCiAg ICAgIGF1dGhlbnRpY2F0aW5nIHRoZSByZXNvdXJjZSBvd25lciBhbmQgb2J0YWluaW5nIGF1dGhv cml6YXRpb24uDQoNCkFmdGVyIGFsbCwgT0F1dGggaXMgYWxsIGFib3V0IGlzc3VpbmcgYWNjZXNz IHRva2Vucy4NCg0KQWxzbywgSSB0YWtlIGJhY2sgbXkgc3RhdGVtZW50IG9uIHRoZSBncmFudCB0 eXBlIGluIG15IHByZXZpb3VzIG1haWwuDQoNClRoZSBkZWZpbml0aW9uIG9mIGdyYW50IGFuZCBn cmFudF90eXBlIGFyZSByZXNwZWN0aXZlbHk6DQoNCmdyYW50DQogICAgY3JlZGVudGlhbCByZXBy ZXNlbnRpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbg0KDQpncmFudF90eXBl DQogICAgKHN0cmluZyByZXByZXNlbnRpbmcgdGhlKSB0eXBlIG9mIGdyYW50IHNlbnQgdG8gdGhl IHRva2VuIGVuZHBvaW50IHRvIG9idGFpbiB0aGUgYWNjZXNzIHRva2VuDQoNClRodXMsIHRoZSBn cmFudCBzZW50IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBpbiB0aGlzIGNhc2UgaXMgc3RpbGwgJ2Nv ZGUnLg0KDQpSZXNwb25zZSB0eXBlIG9uIHRoZSBvdGhlciBoYW5kIGlzIG5vdCBzbyB3ZWxsIGRl ZmluZWQgaW4gUkZDNjc0OSwgYnV0IGl0IHNlZW1zIGl0IGlzIHJlcHJlc2VudGluZyB3aGF0IGlz IHRvIGJlIHJldHVybmVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRvIGV4cHJl c3Mgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50LCBwZXJoYXBzIGRl ZmluaW5nIGEgbmV3IHBhcmFtZXRlciB0byB0aGUgdG9rZW4gZW5kcG9pbnQsIHdoaWNoIGlzIGEg cGFyYWxsZWwgdG8gdGhlIHJlc3BvbnNlX3R5cGUgdG8gdGhlIEF1dGhvcml6YXRpb24gRW5kcG9p bnQgc2VlbXMgdG8gYmUgYSBtb3JlIHN5bW1ldHJpYyB3YXksIHRob3VnaCBJIGFtIG5vdCBzdXJl IGF0IGFsbCBpZiB0aGF0IGlzIGdvaW5nIHRvIGJlIE9BdXRoIGFueSBtb3JlLiBPbmUgc3RyYXct bWFuIGlzIHRvIGRlZmluZSBhIG5ldyBwYXJhbWV0ZXIgY2FsbGVkIHJlc3BvbnNlX3R5cGUgdG8g dGhlIHRva2VuIGVuZHBvaW50IHN1Y2ggYXM6DQoNCnJlc3BvbnNlX3R5cGUNCiAgICBPUFRJT05B TC4gQSBzdHJpbmcgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUg dG9rZW4gZW5kcG9pbnQuDQoNClRoZW4gZGVmaW5lIHRoZSBiZWhhdmlvciBvZiB0aGUgZW5kcG9p bnQgYWNjb3JkaW5nIHRvIHRoZSB2YWx1ZXMgYXMgdGhlIHBhcmFsbGVsIHRvIHRoZSBtdWx0aS1y ZXNwb25zZSB0eXBlIHNwZWMuDQpodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC12Mi1tdWx0 aXBsZS1yZXNwb25zZS10eXBlcy0xXzAuaHRtbA0KDQpOYXQNCg0KDQoNCg0KMjAxNC0wNy0yMyA3 OjIxIEdNVC0wNDowMCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbT4+Og0KVGhlIGRyYWZ0IGlzIHZlcnkgY2xlYXIuDQoNClBoaWwNCg0K T24gSnVsIDIzLCAyMDE0LCBhdCAwOjQ2LCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNv bTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQpUaGUgbmV3IGdyYW50IHR5cGUg dGhhdCBJIHdhcyB0YWxraW5nIGFib3V0IHdhcw0KImF1dGhvcml6YXRpb25fY29kZV9idXRfZG9f bm90X3JldHVybl9hY2Nlc3Nfbm9yX3JlZnJlc2hfdG9rZW4iLCBzbyB0byBzcGVhay4NCkl0IGRv ZXMgbm90IHJldHVybiBhbnl0aGluZyBwZXIgc2UsIGJ1dCBhbiBleHRlbnNpb24gY2FuIGRlZmlu ZSBzb21ldGhpbmcgb24gdG9wIG9mIGl0Lg0KDQpUaGVuLCBPSURDIGNhbiBkZWZpbmUgYSBiaW5k aW5nIHRvIGl0IHNvIHRoYXQgdGhlIGJpbmRpbmcgb25seSByZXR1cm5zIElEIFRva2VuLg0KVGhp cyBiaW5kaW5nIHdvcmsgc2hvdWxkIGJlIGRvbmUgaW4gT0lERi4gU2hvdWxkIHRoZXJlIGJlIHN1 Y2ggYSBncmFudCB0eXBlLA0KaXQgd2lsbCBiZSBhbiBleHRyZW1lbHkgc2hvcnQgc3BlYy4NCg0K QXQgdGhlIHNhbWUgdGltZSwgaWYgYW55IG90aGVyIHNwZWNpZmljYXRpb24gd2FudGVkIHRvIGRl ZmluZQ0Kb3RoZXIgdHlwZSBvZiB0b2tlbnMgYW5kIGhhdmUgaXQgcmV0dXJuZWQgZnJvbSB0aGUg dG9rZW4gZW5kcG9pbnQsDQppdCBjYW4gYWxzbyB1c2UgdGhpcyBncmFudCB0eXBlLg0KDQpJZiB3 aGF0IHlvdSB3YW50IGlzIHRvIGRlZmluZSBhIG5ldyBncmFudCB0eXBlIHRoYXQgcmV0dXJucyBJ RCBUb2tlbiBvbmx5LA0KdGhlbiwgSSBhbSB3aXRoIEp1c3Rpbi4gU2luY2UgIm90aGVyIHJlc3Bv bnNlIHRoYW4gSUQgVG9rZW4iIGlzIG9ubHkNCnRoZW9yZXRpY2FsLCB0aGlzIGlzIGEgbW9yZSBw bGF1c2libGUgd2F5IGZvcndhcmQsIEkgc3VwcG9zZS4NCg0KTmF0DQoNCjIwMTQtMDctMjIgMTQ6 MzAgR01ULTA0OjAwIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hl ckBtaXQuZWR1Pj46DQpTbyB0aGUgZHJhZnQgd291bGQgbGl0ZXJhbGx5IHR1cm4gaW50bzoNCg0K IlRoZSBhNGMgcmVzcG9uc2UgdHlwZSBhbmQgZ3JhbnQgdHlwZSByZXR1cm4gYW4gaWRfdG9rZW4g ZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCBubyBhY2Nlc3MgdG9rZW4uIEFsbCBwYXJhbWV0 ZXJzIGFuZCB2YWx1ZXMgYXJlIGRlZmluZWQgaW4gT0lEQy4iDQoNClNlZW1zIGxpa2UgdGhlIHBl cmZlY3QgbWluaSBleHRlbnNpb24gZHJhZnQgZm9yIE9JREYgdG8gZG8uDQoNCi0tSnVzdGluDQoN Ci9zZW50IGZyb20gbXkgcGhvbmUvDQoNCk9uIEp1bCAyMiwgMjAxNCAxMDoyOSBBTSwgTmF0IFNh a2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdy b3RlOg0KPg0KPiBXaGF0IGFib3V0IGp1c3QgZGVmaW5pbmcgYSBuZXcgZ3JhbnQgdHlwZSBpbiB0 aGlzIFdHPw0KPg0KPg0KPiAyMDE0LTA3LTIyIDEyOjU2IEdNVC0wNDowMCBQaGlsIEh1bnQgPHBo aWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+Og0KPj4NCj4+ IFRoYXQgd291bGQgYmUgbmljZS4gSG93ZXZlciBvaWRjIHN0aWxsIG5lZWRzIHRoZSBuZXcgZ3Jh bnQgdHlwZSBpbiBvcmRlciB0byBpbXBsZW1lbnQgdGhlIHNhbWUgZmxvdy4NCj4+DQo+PiBQaGls DQo+Pg0KPj4gT24gSnVsIDIyLCAyMDE0LCBhdCAxMTozNSwgTmF0IFNha2ltdXJhIDxzYWtpbXVy YUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4NCj4+PiAr MSB0byBKdXN0aW4uDQo+Pj4NCj4+Pg0KPj4+IDIwMTQtMDctMjIgOTo1NCBHTVQtMDQ6MDAgUmlj aGVyLCBKdXN0aW4gUC4gPGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9y Zz4+Og0KPj4+Pg0KPj4+PiBFcnJvcnMgbGlrZSB0aGVzZSBtYWtlIGl0IGNsZWFyIHRvIG1lIHRo YXQgaXQgd291bGQgbWFrZSBtdWNoIG1vcmUgc2Vuc2UgdG8gZGV2ZWxvcCB0aGlzIGRvY3VtZW50 IGluIHRoZSBPcGVuSUQgRm91bmRhdGlvbi4gSXQgc2hvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGRp cmVjdGx5IHJlZmVyZW5jZXMgT3BlbklEIENvbm5lY3QgQ29yZSBmb3IgYWxsIG9mIHRoZXNlIHRl cm1zIGluc3RlYWQgb2YgcmVkZWZpbmluZyB0aGVtLiBJdCdzIGRvaW5nIGF1dGhlbnRpY2F0aW9u LCB3aGljaCBpcyBmdW5kYW1lbnRhbGx5IHdoYXQgT3BlbklEIENvbm5lY3QgZG9lcyBvbiB0b3Ag b2YgT0F1dGgsIGFuZCBJIGRvbid0IHNlZSBhIGdvb2QgYXJndW1lbnQgZm9yIGRvaW5nIHRoaXMg d29yayBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAuDQo+Pj4+DQo+Pj4+ICAtLSBKdXN0aW4NCj4+Pj4N Cj4+Pj4gT24gSnVsIDIyLCAyMDE0LCBhdCA0OjMwIEFNLCBUaG9tYXMgQnJveWVyIDx0LmJyb3ll ckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+Pg0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gT24gTW9uLCBKdWwgMjEsIDIwMTQgYXQgMTE6NTIgUE0s IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+PiBUaGFua3MgZm9yIHlv dXIgcmV2aWV3LCBUaG9tYXMuICBUaGUgInByb21wdD1jb25zZW50IiBkZWZpbml0aW9uIGJlaW5n IG1pc3NpbmcgaXMgYW4gZWRpdG9yaWFsIGVycm9yLiAgSXQgc2hvdWxkIGJlOg0KPj4+Pj4+DQo+ Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IGNvbnNlbnQNCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBBdXRob3Jp emF0aW9uIFNlcnZlciBTSE9VTEQgcHJvbXB0IHRoZSBFbmQtVXNlciBmb3IgY29uc2VudCBiZWZv cmUgcmV0dXJuaW5nIGluZm9ybWF0aW9uIHRvIHRoZSBDbGllbnQuIElmIGl0IGNhbm5vdCBvYnRh aW4gY29uc2VudCwgaXQgTVVTVCByZXR1cm4gYW4gZXJyb3IsIHR5cGljYWxseSBjb25zZW50X3Jl cXVpcmVkLg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEknbGwgcGxhbiB0byBhZGQg aXQgaW4gdGhlIG5leHQgZHJhZnQuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IEl0IGxvb2tzIGxpa2Ug dGhlIGNvbnNlbnRfcmVxdWlyZWQgZXJyb3IgbmVlZHMgdG8gYmUgZGVmaW5lZCB0b28sIGFuZCB5 b3UgbWlnaHQgaGF2ZSBmb3Jnb3R0ZW4gdG8gYWxzbyBpbXBvcnQgYWNjb3VudF9zZWxlY3Rpb25f cmVxdWlyZWQgZnJvbSBPcGVuSUQgQ29ubmVjdC4NCj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4gSSBhZ3JlZSB0aGF0IHRoZXJlJ3Mgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIGEg cmVzcG9uc2Ugd2l0aCBtdWx0aXBsZSAiYW1yIiB2YWx1ZXMgdGhhdCBpbmNsdWRlcyAibWZhIiBh bmQgb25lIHRoYXQgZG9lc24ndC4gIFVubGVzcyBhIGNsZWFyIHVzZSBjYXNlIGZvciB3aHkgIm1m YSIgaXMgbmVlZGVkIGNhbiBiZSBpZGVudGlmaWVkLCB3ZSBjYW4gZGVsZXRlIGl0IGluIHRoZSBu ZXh0IGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MuDQo+Pj4+Pg0KPj4+Pj4gSG93 IGFib3V0ICJwd2QiIHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IEkgc2hvdWxkIHJldHVy biAicHdkIiBpZiB0aGUgdXNlciBhdXRoZW50aWNhdGVkIHVzaW5nIGEgcGFzc3dvcmQsIGJ1dCB3 aGF0ICJ0aGUgc2VydmljZSBpZiBhIGNsaWVudCBzZWNyZXQgaXMgdXNlZCIgbWVhbnMgaW4gdGhl IGRlZmluaXRpb24gZm9yIHRoZSAicHdkIiB2YWx1ZT8NCj4+Pj4+DQo+Pj4+PiAoTm90YTogSSBr bm93IHlvdSdyZSBhdCBJRVRGLTkwLCBJJ20gcmVhZHkgdG8gd2FpdCAndGlsIHlvdSBjb21lIGJh Y2sgOy0pICkNCj4+Pj4+DQo+Pj4+PiAtLQ0KPj4+Pj4gVGhvbWFzIEJyb3llcg0KPj4+Pj4gL3TJ lC5tYS5iyoF3YS5qZS88aHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvPg0KPj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IE9B dXRoIG1haWxpbmcgbGlzdA0KPj4+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K Pj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4gT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQo+Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0NCj4+PiBOYXQg U2FraW11cmEgKD1uYXQpDQo+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQo+Pj4gaHR0 cDovL25hdC5zYWtpbXVyYS5vcmcvDQo+Pj4gQF9uYXRfZW4NCj4+Pg0KPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gT0F1dGggbWFpbGluZyBs aXN0DQo+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4NCj4NCj4NCj4gLS0N Cj4gTmF0IFNha2ltdXJhICg9bmF0KQ0KPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCj4g aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQo+IEBfbmF0X2VuDQoNCg0KDQotLQ0KTmF0IFNha2lt dXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2lt dXJhLm9yZy8NCkBfbmF0X2VuDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJt YW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2Vu DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KLS0NClRo b21hcyBCcm95ZXINCi90yZQubWEuYsqBd2EuamUvPGh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2Et eHhiLmplLz4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0t DQpUaG9tYXMgQnJveWVyDQovdMmULm1hLmLKgXdhLmplLzxodHRwOi8veG4tLW5uYS5tYS54bi0t YndhLXh4Yi5qZS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K DQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24N Cmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0K T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoN Cg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9u DQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFp cm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRf ZW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3Bl bklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0K --_000_054c4958db6545cf99d3f0339e34c776BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PTUcsIGhvdyBjYW4geW91IHNheSB0aGF0IHdo ZW4gdGhlIER5bmFta2MgUmVnIGRvZXMgdGhlIHNhbWUgdGhpbmcgKGR1cGxpY2F0ZXMpIGJ1dCB0 aGF0IGlzIE9LIHRvIGRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJpYW4gQ2FtcGJlbGw8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMjQsIDIwMTQgMTA6MjIgQU08YnI+DQo8Yj5Ubzo8 L2I+IEpvaG4gQnJhZGxleTxicj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmcgbGlzdDxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHNvcnJ5IHRvIG1pc3Mgd2hhdCB3aWxsIGxpa2VseSBi ZSBhIHZlcnkgZW5nYWdpbmcgbWVldGluZyB0b2RheS48YnI+DQo8YnI+DQpUaGUgcHJlbWlzZSB0 aGF0IHNvbWUgZGV2ZWxvcGVycyBhcmUgdXNpbmcgT0F1dGggaW4gYSBpbnNlY3VyZSB3YXkgdG8g ZG8gYXV0aGVudGljYXRpb24gaXMgc29tZXRoaW5nIHdlIGNhbiBwcm9iYWJseSBhbGwgYWdyZWUg b24uDQo8YnI+DQo8YnI+DQpJdCBkb2Vzbid0IG5lY2Vzc2FyaWx5IGZvbGxvdyBmcm9tIHRoYXQg cHJlbWlzZSwgaG93ZXZlciwgdGhhdCB0aGUgc29sdXRpb24gaXMgeWV0IGFub3RoZXIgc3BlYyB3 aGljaCBlaXRoZXIgZHVwbGljYXRlcyBzb21lIHN1YnNldCBvZiBPcGVuSUQgQ29ubmVjdCAoaW4g YSBkaWZmZXJlbnQgU0RPKSBvciBmb3JrcyBob3cgdG8gZG8gU1NPL2F1dGhlbnRpY2F0aW9uIHVz aW5nIE9BdXRoLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVsIDI0LCAyMDE0IGF0IDc6 MjUgQU0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29t IiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBu b3QgYWdhaW5zdCBkaXNjdXNzaW9uIGluIHRoZSBXRy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGFwcGVuIHRvIGFncmVlIHdpdGggUGhpbCdzIGZ1bmRh bWVudGFsIHByZW1pc2UgdGhhdCBzb21lIGRldmVsb3BlcnMgYXJlIHVzaW5nIE9BdXRoIGluIGEg aW5zZWN1cmUgd2F5IHRvIGRvIGF1dGhlbnRpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHJhaXNlcyB0aGUgcXVlc3Rpb24g b2YgaG93IHRvIGJlc3QgZWR1Y2F0ZSB0aGVtLCBhbmQgb3IgYWRkcmVzcyB0ZWNobmljYWwgYmFy cmllcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkl0IGlzIG9uIHRoZSBzZWNvbmQgcG9pbnQgdGhhdCBwZW9wbGUncyBvcGluaW9ucyBzZWVt IHRvIGRpdmlkZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U29tZSBwZW9wbGUgdGhpbmcgdGhhdCBpZiB3ZSBoYXZlIGEgT0F1dGggZmxvdyB0 aGF0IGVsaW1pbmF0ZXMgdGhlIGFjY2VzcyB0b2tlbiAocHJpbWFyaWx5IHRvIGF2b2lkIGFza2lu ZyBmb3IgY29uc2VudCBhcyBJIHVuZGVyc3RhbmQgaXQpIGFuZCBqdXN0IHJldHVybiBhIGlkX3Rv a2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IHRoYXQgY2FuIGJlIGRvbmUgaW4gYSBzcGVjIHNo b3J0IGVub3VnaCB0byBoZXQNCiBwZW9wbGUgdG8gcmVhZC4gJm5ic3A7IFRoZSBzdWJ0ZXh0IG9m IHRoaXMgaXMgdGhhdCB0aGUgQ29ubmVjdCBzcGVjaWZpY2F0aW9uIGlzIHRvbyBsYXJnZSB0aGF0 IGl0IHNjYXJlIHBlb3BsZSwgJm5ic3A7YW5kIHRoZXkgZG9uJ3QgZmluZCB0aGUgc3BlYyBpbiB0 aGUgZmlyc3QgcGxhY2UgYmVjYXVzZSBpdCBpcyBub3QgYSBSRkMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuIG90aGVyIGNvbW1vbiBwb3Nz ZXNzaW9uIGlzIHRoYXQgaWYgeW91IGRvbid0IHdhbnQgdG8gcHJvbXB0IHRoZSB1c2VyIGZvciBj b25zZW50IHRoZW4gZG9uJ3QgYXNrIGZvciBzY29wZXMuICZuYnNwO1R3aXN0aW5nIHRoZSBPQXV0 aCBzcGVjIHRvIG5vdCByZXR1cm4gYW4gYWNjZXNzIHRva2VuIGlzIG5vdCBPQXV0aCwgJm5ic3A7 eWVzIHlvdSBjb3VsZCB1c2UgYSBkaWZmZXJlbnQgZW5kcG9pbnQgcmF0aGVyIHRoYW4gdGhlDQog dG9rZW4gZW5kcG9pbnQsIGJ1dCB0aGF0IGlzIG5vdCBPQXV0aC4gJm5ic3A7IENvbm5lY3Qgd2Fz IGNhcmVmdWwgbm90IHRvIGJyZWFrIHRoZSBPQXV0aCBzcGVjLiAmbmJzcDsgJm5ic3A7QXMgbG9u ZyBhcyB5b3UgYXJlIHdpbGxpbmcgdG8gdGFrZSBhIGFjY2VzcyB0b2tlbiB3aXRoIG5vIHNjb3Bl cyAodGhlIGNsaWVudCBuZWVkcyB0byB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgYXJlIG5vIGF0dHJp YnV0ZXMgb25lIHdheSBvciBhbm90aGVyIGFueXdheSBvciBpdCB3aWxsDQogYnJlYWspIHRoZW4g eW91IGRvbid0IG5lZWQgdG8gY2hhbmdlIE9BdXRoLiAmbmJzcDsgWW91IGNhbiBwdWJsaXNoIGEg cHJvZmlsZSBvZiBjb25uZWN0IHRoYXQgc2F0aXNmaWVzIHRoZSB1c2UgY2FzZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBNaWtl IGhhcyBsYXJnZWx5IGRvbmUgdGhhdCBidXQgaXQgbWlnaHQgYmUgYmV0dGVyIGJlaW5nIGxlc3Mg c3Rpbmd5IG9uIHJlZmVyZW5jZXMgYmFjayB0byB0aGUgbGFyZ2VyIHNwZWMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBxdWVzdGlvbnMg YXJlIGRvIHdlIG1vZGlmeSBPQXV0aCB0byBub3QgcmV0dXJuIGFuIGFjY2VzcyB0b2tlbiwgYW5k IGlmIHNvIGhvdywgJm5ic3A7YW5kIGlmIHdlIGRvIGlzIGl0IHN0aWxsIE9BdXRoLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb3RoZXIg bGFyZ2VseSBzZXBhcmFibGUgcXVlc3Rpb24gaXMgZG8gd2UgY3JlYXRlIGNvbmZ1c2lvbiBpbiB0 aGUgbWFya2V0IGFuZCBzbG93IHRoZSB0aGUgYWRvcHRpb24gb2YgaWRlbnRpdHkgZmVkZXJhdGlv biBvbiB0b3Agb2YgT0F1dGgsIG9yIGZpbmQgYSB3YXkgdG8gbWFrZSB0aGlzIGxvb2sgbGlrZSBh IHBvc2l0aXZlIGFsaWdubWVudCBvZiBpbnRlcmVzdHMgYXJvdW5kIGEgc3Vic2V0IG9mIENvbm5l Y3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZXJlIGFyZSBhIG51bWJlciBvZiBvcHRpb25zLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjE6IFdlIGNhbiBkbyBhIHByb2ZpbGUg aW4gdGhlIE9JREYgYW5kIHB1Ymxpc2ggaXQgYXMgYSBJRVRGIGRvY3VtZW50LiAmbmJzcDsgUGVy aGFwcyB0aGUgY2xlYW5lc3QgZnJvbSBhbiBJUFIgcG9pbnQgb2Ygdmlldy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjI6V2UgY2FuIGRvIGEgcHJv ZmlsZSBpbiB0aGUgT0F1dGggV0cgcmVmZXJlbmNpbmcgY29ubmVjdC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjM6V2UgY2FuIGRvIGEgQUQgc3Bv bnNvcmVkIHByb2ZpbGUgdGhhdCBpcyBub3QgaW4gdGhlIE9BdXRoIFdHLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NDpXZSBjYW4gZG8gYSBzbWFs bCBzcGVjIGluIE9BdXRoIHRvIGFkZCByZXNwb25zZV90eXBlIHRvIHRoZSB0b2tlbiBlbmRwb2lu dC4gJm5ic3A7aW4gY29tYmluYXRpb24gd2l0aCAxLCAyLCBvciAzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgdGhhdCBzdG9waW5n IGRldmVsb3BlcnMgZG9pbmcgaW5zZWN1cmUgdGhpbmdzIG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBz b21laG93LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgYW0gbm90IHBlcnNvbmFsbHkgY29udmluY2VkIHRoYXQgT2F1dGggd2l0aG91 dCBhY2Nlc3MgdG9rZW5zIGlzIHNlbnNpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb29raW5nIGZvcndhcmQgdG8gdGhlIG1lZXRpbmc6 KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5K b2huIEIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gSnVsIDI0LCAyMDE0LCBhdCA2OjUyIEFNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFu ayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ2Qgbm90ZSB0aGF0IHRoZSByZWFj dGlvbiBhdCB0aGUgY29uZmVyZW5jZSB0byBJYW4ncyBzdGF0ZW1lbnQgd2FzIG92ZXJ3aGVsbWlu Z2x5IHBvc2l0aXZlLiBUaGVyZSB3YXMgYSB3aWRlIHJhbmdlIG9mIGluZHVzdHJ5IHBlb3BsZSBo ZXJlIC0gaW1wbGVtZW50ZXJzLCBwcmFjdGl0aW9uZXJzLCBkZXBsb3llcnMsIHN0cmF0ZWdpc3Rz LCBldGMuIC0gYW5kIGl0IHNlZW1zIHByZXR0eSBjbGVhciB0aGF0IHRoZQ0KICZxdW90O3JvdWdo IGNvbnNlbnN1cyZxdW90OyBvZiB0aGUgaW5kdXN0cnkgYXQgbGFyZ2UgaXMgdGhhdCBhNGMgaXMg bm90IHdhbnRlZCBvciBuZWVkZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVsIDI0LCAy MDE0IGF0IDU6MjkgQU0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJh QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BbmQgaGVyZSBpcyBhIHF1b3RlIGZyb20gSWFuJ3MgYmxvZy4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBhbHRob3VnaCB0 aGUgYXV0aGVudGljYXRpb24gd2hlZWwgaXMgcm91bmQsIHRoYXQgZG9lc27igJl0IG1lYW4gaXQg aXNu4oCZdCB3aXRob3V0IGl0cyBsdW1wcy4gRmlyc3QsIHdlIGRvIHNlZSBzb21lIHJlaW52ZW50 aW5nIHRoZSB3aGVlbCBqdXN0IHRvIHJlaW52ZW50IHRoZSB3aGVlbC4gT0F1dGggQTRDIGlzIHNp bXBseSBub3QgYSBmcnVpdGZ1bCBhY3Rpdml0eSBhbmQgc2hvdWxkIGJlIHB1dCBkb3duLiAmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPihTb3VyY2UpIDxhIGhyZWY9Imh0dHA6Ly93d3cudHVlc2RheW5pZ2h0Lm9y Zy8yMDE0LzA3LzIzL2RvLXdlLWhhdmUtYS1yb3VuZC13aGVlbC15ZXQtbXVzaW5ncy1vbi1pZGVu dGl0eS1zdGFuZGFyZHMtcGFydC0xLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cu dHVlc2RheW5pZ2h0Lm9yZy8yMDE0LzA3LzIzL2RvLXdlLWhhdmUtYS1yb3VuZC13aGVlbC15ZXQt bXVzaW5ncy1vbi1pZGVudGl0eS1zdGFuZGFyZHMtcGFydC0xLmh0bWw8L2E+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTQtMDctMjMgMTY6NTMgR01ULTA0OjAwIEpvaG4gQnJh ZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRob3VnaHQgSSBkaWQgcG9z dCB0aGlzIHRvIHRoZSBsaXN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGd1ZXNzIEkgaGl0IHRoZSB3cm9uZyByZXBseSBvbiBt eSBwaG9uZS4mbmJzcDs8YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4gQi4mbmJzcDs8YnI+DQpTZW50IGZyb20gbXkgaVBo b25lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEp1bCAyMywgMjAxNCwgYXQgNDo1 MCBQTSwgPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9i bGFuayI+DQp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4gd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHA+d2UgYXJlIHR3bywgYXQgbGVhc3QgOi0pPG86cD48L286cD48L3A+DQo8 cD5XaHkgZGlkbid0IHlvdSBwb3N0IHRoaXMgb24gdGhlIGxpc3Q/PG86cD48L286cD48L3A+DQo8 cD5XaGVuIHdpbGwgYmUgYmUgYXJyaXZpbmc/PG86cD48L286cD48L3A+DQo8cD5BbSAyMy4wNy4y MDE0IDE2OjM5LCBzY2hyaWViIEpvaG4gQnJhZGxleTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWFu IEdsYXplciBtZW50aW9uZWQgdGhpcyBpbiBoaXMga2V5bm90ZSBhdCBDSVMgeWVzdGVyZGF5LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaXMgYWR2aWNlIHdhcyBwbGVhc2Ugc3RvcCwgJm5ic3A7d2UgYXJlIGNyZWF0aW5nIGNvbmZ1 c2lvbiBhbmQgdW5jZXJ0YWludHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSBiZWNvbWluZyBvdXIgb3duIHdvcnQgZW5l bXkuICggbXkgdmlldyB0aG91Z2ggSWFuIG1heSBzaGFyZSBpdCk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV0dXJuaW5nIGp1c3QgYW4gaWRf IHRva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IGhhcyBsaXR0bGUgcmVhbCB2YWx1ZS4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U29tZXRoaW5nIHJlYWxseSB1c2VmdWwgdG8gZG8gd291bGQgYmUgc29ydGluZyBvdXQgY2hhbm5l bF9pZCBzbyB3ZSBjYW4gZG8gUG9QIGZvciBpZCB0b2tlbnMgdG8gbWFrZSB0aGVtIGFuZCBvdGhl ciBjb29raWVzIHNlY3VyZSBpbiB0aGUgZnJvbnQgY2hhbm5lbC4gJm5ic3A7IEkgdGhpbmsgdGhh dCBpcyBhIGJldHRlciB1c2Ugb2YgdGltZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBtYXkgYmUgaW4gdGhlIG1pbm9yaXR5IG9w aW5pb24gb24gdGhhdCwgJm5ic3A7aXQgd29uJ3QgYmUgdGhlIGZpcnN0IHRpbWUuICZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCkpv aG4gQi4mbmJzcDs8YnI+DQpTZW50IGZyb20gbXkgaVBob25lPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEp1bCAyMywgMjAxNCwgYXQgNDowNCBQTSwgVG9y c3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQu bmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGFyZSByaWdodCBmcm9t IGEgdGhlb3JldGljYWwgcGVyc3BlY3RpdmUuIFByYWN0aWNhbGx5IHRoaXMgd2FzIGNhdXNlZCBi eSBlZGl0b3JpYWwgZGVjaXNpb25zIGR1cmluZyB0aGUgY3JlYXRpb24gb2YgdGhlIFJGQy4gQXMg ZmFyIGFzIEkgcmVtZW1iZXIsIHRoZXJlIHdhcyBhIGRlZmluaXRpb24gb2YgdGhlIChvbmUpIHRv a2VuIGVuZHBvaW50IHJlc3BvbnNlIGluIGVhcmx5IHZlcnNpb25zLiBObyBvbmUNCiBldmVyeSBj b25zaWRlcmVkIHRvIE5PVCByZXNwb25kIHdpdGggYW4gYWNjZXNzIHRva2VuIGZyb20gdGhlIHRv a2VuIGVuZHBvaW50LiBTbyBvbmUgbWlnaHQgY2FsbCBpdCBhbiBpbXBsaWNpdCBhc3N1bXB0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J J20gd29ycmllZCB0aGF0IHBlb3BsZSBnZXQgdG90YWxseSBjb25mdXNlZCBpZiBhbiBleGNlcHRp b24gaXMgaW50cm9kdWNlZCBub3cgZ2l2ZW4gdGhlIGJyb2FkIGFkb3B0aW9uIG9mIE9BdXRoIGJh c2VkIG9uIHRoaXMgYXNzdW1wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvcnN0ZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCkFtIDIzLjA3LjIwMTQgdW0gMTU6NDEgc2NocmllYiBUaG9tYXMgQnJveWVyICZsdDs8 YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dC5icm95 ZXJAZ21haWwuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHA+SXMgaXQgc2FpZCBhbnl3aGVyZSB0aGF0 IEFMTCBncmFudCB0eXBlcyBNVVNUIHVzZSBTZWN0aW9uIDUuMSByZXNwb25zZXM/IEVhY2ggZ3Jh bnQgdHlwZSByZWZlcmVuY2VzIFNlY3Rpb24gNS4xLCBhbmQgJnF1b3Q7YWNjZXNzIHRva2VuIHJl cXVlc3QmcXVvdDsgaXMgb25seSBkZWZpbmVkIGluIHRoZSBjb250ZXh0IG9mIHRoZSBkZWZpbmVk IGdyYW50IHR5cGVzLiBTZWN0aW9uIDIuMiBkb2Vzbid0IHRhbGsgYWJvdXQgdGhlIHJlcXVlc3Qg b3IgcmVzcG9uc2UNCiBmb3JtYXQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TGUgMjMganVpbC4gMjAxNCAyMTozMiwgJnF1b3Q7TmF0IFNha2ltdXJhJnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgYSDDqWNyaXQgOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyBpdD8gQXBhcnQgZnJvbSB0 aGUgaW1wbGljaXQgZ3JhbnQgdGhhdCBkb2VzIG5vdCB1c2UgdG9rZW4gZW5kcG9pbnQsIGFsbCBv dGhlciBncmFudCByZWZlcmVuY2VzIHNlY3Rpb24gNS4xIGZvciB0aGUgcmVzcG9uc2UsIGkuZS4s IGFsbCBzaGFyZXMgdGhlIHNhbWUgcmVzcG9uc2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIw MTQtMDctMjMgMTU6MTggR01ULTA0OjAwIFRob21hcyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0 bzp0LmJyb3llckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj50LmJyb3llckBnbWFpbC5jb208 L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cD5JIGhhZG4ndCByZWFsaXpl ZCB0aGUgSlNPTiByZXNwb25zZSB0aGF0IHJlcXVpcmVzIHRoZSBhY2Nlc3NfdG9rZW4gZmllbGQg aXMgZGVmaW5lZCBwZXIgZ3JhbnRfdHlwZSwgc28gSSdkIGJlIE9LIHRvICZxdW90O2V4dGVuZCB0 aGUgc2VtYW50aWNzJnF1b3Q7IGFzIGluIHRoZSBjdXJyZW50IGRyYWZ0Ljxicj4NClRoYXQgd2Fz IGFjdHVhbGx5IG15IG1haW4gY29uY2VybjogdGhhdCB0aGUgdG9rZW4gZW5kcG9pbnQgbWFuZGF0 ZXMgYWNjZXNzX3Rva2VuOyBidXQgaXRzIGFjdHVhbGx5IG5vdCB0aGUgY2FzZS48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZSAyMyBqdWlsLiAyMDE0IDIwOjQ2 LCAmcXVvdDtOYXQgU2FraW11cmEmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyBhIMOp Y3JpdCA6DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdpdGggSm9obiB0aGF0IG92ZXJsb2FkaW5nIHJlc3Bv bnNlX3R5cGUgQCBhdXRoeiBlbmRwb2ludCBpcyBhIGJhZCBpZGVhLiBJdCBjb21wbGV0ZWx5IGNo YW5nZXMgdGhlIHNlbWFudGljcyBvZiB0aGlzIHBhcmFtZXRlci4gTk9URTogd2hhdCBJIHdhcyBw cm9wb3Npbmcgd2FzIG5vdCB0aGlzIHBhcmFtZXRlciwgYnV0IGEgbmV3IHBhcmFtZXRlciByZXNw b25zZV90eXBlIEAgdG9rZW4gZW5kcG9pbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyB0aGluayBvdmVybG9hZGluZyBn cmFudF90eXBlIGlzIGEgYmFkIGlkZWEgc2luY2UgaXQgY2hhbmdlcyBpdHMgc2VtYW50aWNzLiBJ IHF1b3RlIHRoZSBkZWZpbml0aW9uIGhlcmUgYWdhaW46Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ncmFudCZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBhdXRo b3JpemF0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmdyYW50X3R5cGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnR5cGUgb2YgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgdG8g b2J0YWluIHRoZSBhY2Nlc3MgdG9rZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBub3QgYWJvdXQgY29udHJvbGxpbmcg d2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCwgYnV0IHRoZSBo aW50IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBkZXNjcmliaW5nIHRoZSB0eXBlIG9mIGNyZWRlbnRp YWwgdGhlIGVuZHBvaW50IGhhcyByZWNlaXZlZC4gSXQgc2VlbXMgdGhlICZxdW90O2NvbnRyb2wg b2Ygd2hhdCBpcyBiZWluZyByZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50JnF1b3Q7DQogJm5i c3A7aXMganVzdCBhIHNpZGUgZWZmZWN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIHNvbWV3aGF0IGFtYml2YWxlbnRbMV0g aW4gY2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiB0b2tlbiBlbmRwb2ludCwgYnV0IGluIGFzIG11 Y2ggYXMgJnF1b3Q7dGV4dCBpcyB0aGUga2luZyZxdW90OyBmb3IgYSBzcGVjLiwgd2UgcHJvYmFi bHkgc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBpdCBhcyBUb3JzdGVuIHBvaW50 cyBvdXQuIElmIGl0IGlzIG9rIHRvIGNoYW5nZSB0aGlzIHNlbWFudGljcywgSQ0KIGJlbGlldmUg ZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVyIHRvIHRoaXMgZW5kcG9pbnQgdG8gY29udHJvbCB0aGUg cmVzcG9uc2Ugd291bGQgYmUgdGhlIGJlc3Qgd2F5IHRvIGdvLiBUaGlzIGlzIHdoYXQgSSBoYXZl IGRlc2NyaWJlZCBwcmV2aW91c2x5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWZpbmluZyBhIG5ldyBlbmRwb2ludCB0byBzZW5k IGNvZGUgdG8gZ2V0IElEIFRva2VuIGFuZCBmb3JiaWRkaW5nIHRoZSB1c2Ugb2YgaXQgYWdhaW5z dCB0b2tlbiBlbmRwb2ludCB3b3VsZCBub3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgYW55IGV4 aXN0aW5nIHBhcmFtZXRlciBvciBlbmRwb2ludCwgd2hpY2ggaXMgZ29vZC4gSG93ZXZlciwgSSBk b3VidCBpZiBpdCBpcyBub3Qgd29ydGggZG9pbmcuIFdoYXQncw0KIHRoZSBwb2ludCBvZiBhdm9p ZGluZyBhY2Nlc3MgdG9rZW4gc2NvcGVkIHRvIFVzZXJJbmZvIGVuZHBvaW50IGFmdGVyIGFsbD8g RGVmaW5pbmcgYSBuZXcgZW5kcG9pbnQgZm9yIGp1c3QgYXZvaWRpbmcgdGhlIGFjY2VzcyB0b2tl biBmb3IgdXNlcmluZm8gZW5kcG9pbnQgc2VlbXMgd2F5IHRvbyBtdWNoIHRoZSBoZWF2eSB3YWl0 IHdheSBhbmQgaXQgYnJlYWtzIGludGVyb3BlcmFiaWxpeTogaXQgZGVmZWF0cyB0aGUgcHVycG9z ZSBvZiBzdGFuZGFyZGl6YXRpb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBzdGFydGVkIGZlZWxpbmcgdGhhdCBubyBj aGFuZ2UgaXMgdGhlIGJlc3Qgd2F5IG91dC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsxXSAmbmJzcDtJZiBpbnN0ZWFkIG9mIHNh eWluZyAmcXVvdDtUb2tlbiBlbmRwb2ludCAtIHVzZWQgYnkgdGhlIGNsaWVudCB0byBleGNoYW5n ZSBhbiBhdXRob3JpemF0aW9uJm5ic3A7Z3JhbnQgZm9yIGFuIGFjY2VzcyB0b2tlbiwgdHlwaWNh bGx5IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0aW9uJnF1b3Q7LCBpdCB3ZXJlIHNheWluZyAmcXVv dDtUb2tlbiBlbmRwb2ludCAtIHVzZWQgYnkgdGhlIGNsaWVudCB0byBleGNoYW5nZSBhbiBhdXRo b3JpemF0aW9uJm5ic3A7Z3JhbnQNCiBmb3IgdG9rZW5zLCB0eXBpY2FsbHkgd2l0aCBjbGllbnQg YXV0aGVudGljYXRpb24mcXVvdDssIHRoZW4gaXQgd291bGQgaGF2ZSBiZWVuIE9LLiBJdCBpcyBh biBleHBhbnNpb24gb2YgdGhlIGNhcGFiaWxpdHkgcmF0aGVyIHRoYW4gY2hhbmdpbmcgdGhlIHNl bWFudGljcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTQtMDctMjMgMTM6MzkgR01U LTA0OjAwIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+ Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PllvdSBuZWVkIHRoZSBhbHRlcm5hdGl2ZSByZXNwb25zZV90eXBlIHZhbHVlICgmcXVvdDs8L3Nw YW4+Y29kZV9mb3JfaWRfdG9rZW48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+JnF1b3Q7DQogaW4gdGhlIEE0QyBkcmFmdCkgdG8gdGVsbCB0aGUgQXV0aG9yaXphdGlv biBTZXJ2ZXIgdG8gcmV0dXJuIGEgY29kZSB0byBiZSB1c2VkIHdpdGggdGhlIG5ldyBncmFudCB0 eXBlLCByYXRoZXIgdGhhbiBvbmUgdG8gdXNlIHdpdGggdGhlICZxdW90O2F1dGhvcml6YXRpb25f Y29kZSZxdW90OyBncmFudCB0eXBlICh3aGljaCBpcyB3aGF0IHJlc3BvbnNlX3R5cGU9Y29kZSBk b2VzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0 aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8c3Ryb25nPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ T24gQmVoYWxmIE9mIDwvc3Bhbj48L3N0cm9uZz5Kb2huIEJyYWRsZXk8YnI+DQo8c3Ryb25nPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+U2VudDo8L3NwYW4+PC9zdHJvbmc+IFdlZG5lc2RheSwgSnVseSAyMywgMjAxNCAx MDozMyBBTTxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ubzo8L3NwYW4+PC9zdHJvbmc+IDxhIGhy ZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8c3Ryb25nPkNjOjwvc3Ryb25nPiA8YSBo cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9y ZzwvYT48YnI+DQo8c3Ryb25nPlN1YmplY3Q6PC9zdHJvbmc+IFJlOiBbT0FVVEgtV0ddIE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50 eHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgd2UgdXNlIHRoZSB0 b2tlbiBlbmRwb2ludCB0aGVuIGEgbmV3IGdyYW50X3R5cGUgaXMgdGhlIGJlc3Qgd2F5LiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkl0IHNvcnQgb2Ygb3ZlcmxvYWRzIGNvZGUsIGJ1dCB0aGF0IGlzIGJl dHRlciB0aGFuIG1lc3Npbmcgd2l0aCByZXNwb25zZV90eXBlIGZvciB0aGUgYXV0aG9yaXphdGlv biBlbmRwb2ludCB0byBjaGFuZ2UgdGhlIHJlc3BvbnNlIGZyb20gdGhlIHRva2VuX2VuZHBvaW50 LiAmbmJzcDtUaGF0IGlzIGluIG15IG9waW5pb24NCiBhIGNoYW1waW9uIGJhZCBpZGVhLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkluIGRpc2N1c3Npb25zIGRldmVsb3BpbmcgQ29ubmVjdCB3ZSBkZWNp ZGVkIG5vdCB0byBvcGVuIHRoaXMgY2FuIG9mIHdvcm1zIGJlY2F1c2Ugbm8gZ29vZCB3b3VsZCBj b21lIG9mIGl0LiAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgdG9rZW5fZW5kcG9pbnQg cmV0dXJucyBhIGFjY2VzcyB0b2tlbi4gJm5ic3A7Tm90aGluZyByZXF1aXJlcyBzY29wZSB0byBi ZSBhc3NvY2lhdGVzIHdpdGggdGhlIHRva2VuLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYXQgaXMg dGhlIGJlc3Qgc29sdXRpb24uICZuYnNwO05vIGNoYW5nZSByZXF1aXJlZC4gJm5ic3A7QmV0dGVy IGludGVyb3BlcmFiaWxpdHkgaW4gbXkgb3Bpbmlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TdGls bCBvbiBteSB3YXkgdG8gVE8sIGdldHRpbmcgaW4gbGF0ZXIgdG9kYXkuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Sm9obiBCLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxicj4NClNlbnQgZnJvbSBt eSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KT24gSnVsIDIzLCAyMDE0LCBhdCAxMjoxNSBQTSwgPGEgaHJlZj0ibWFpbHRvOnRvcnN0 ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+DQp0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldDwvYT4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwPlRoZSAm cXVvdDtyZXNwb25zZSB0eXBlJnF1b3Q7IG9mIHRoZSB0b2tlbiBlbmRwb2ludCBpcyBjb250cm9s bGVkIGJ5IHRoZSB2YWx1ZSBvZiB0aGUgcGFyYW1ldGVyICZxdW90O2dyYW50X3R5cGUmcXVvdDsu IFNvIHRoZXJlIGlzIG5vIG5lZWQgdG8gaW50cm9kdWNlIGEgbmV3IHBhcmFtZXRlci48bzpwPjwv bzpwPjwvcD4NCjxwPndydCB0byBhIHBvdGVudGlhbCAmcXVvdDtub19hY2Nlc3NfdG9rZW4mcXVv dDsgZ3JhbnQgdHlwZS4gSSBkbyBub3QgY29uc2lkZXIgdGhpcyBhIGdvb2QgaWRlYSBhcyBpdCBj aGFuZ2VzIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHRva2VuIGVuZHBvaW50IChhcyBhbHJlYWR5IHBv aW50ZWQgb3V0IGJ5IFRob21hcykuIFRoaXMgZW5kcG9pbnQgQUxXQVlTIHJlc3BvbmRzIHdpdGgg YW4gYWNjZXNzIHRva2VuIHRvIGFueSBncmFudCB0eXBlLiBJIHRoZXJlZm9yZSB3b3VsZA0KIHBy ZWZlciB0byB1c2UgYW5vdGhlciBlbmRwb2ludCBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UuPG86 cD48L286cD48L3A+DQo8cD5yZWdhcmRzLDxicj4NClRvcnN0ZW4uPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwPkFtIDIzLjA3LjIwMTQgMTM6MDQsIHNjaHJpZWIgTmF0IFNha2ltdXJhOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMx MDEwRkYgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JTUhPLCBjaGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mICZxdW90 O3Jlc3BvbnNlX3R5cGUmcXVvdDsgQCBhdXRoeiBlbmRwb2ludCB0aGlzIHdheSBpcyBub3QgYSBn b29kIHRoaW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW5zdGVhZCwgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVy ICZxdW90O3Jlc3BvbnNlX3R5cGUmcXVvdDsgQCB0b2tlbiBlbmRwb2ludCwgYXMgSSBkZXNjcmli ZWQgaW4gbXkgcHJldmlvdXMgbWVzc2FnZSwmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+cHJvYmFibHkgaXMgYmV0dGVyLiBBdCBsZWFzdCwgaXQg ZG9lcyBub3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHBhcmFtZXRlcnMgb2YgUkZDNjc0 OS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDtOYXQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIwMTQtMDctMjMgMTI6NDggR01ULTA0OjAwIFRob21h cyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj50LmJyb3llckBnbWFpbC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vLCBJIG1lYW4gcmVzcG9uc2VfdHlwZT1ub25lIGFu ZCByZXNwb25zZV90eXBlPWlkX3Rva2VuIGRvbid0IGdlbmVyYXRlIGEgY29kZSBvciBhY2Nlc3Mg dG9rZW4gc28geW91IGRvbid0IHVzZSB0aGUgVG9rZW4gRW5kcG9pbnQgKHdoaWNoIGlzIG5vdCB0 aGUgc2FtZSBhcyB0aGUgQXV0aGVudGljYXRpb24gRW5kcG9pbnQNCiBCVFcpLiA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldpdGggcmVzcG9uc2VfdHlwZT1j b2RlX2Zvcl9pZF90b2tlbiwgeW91IGdldCBhIGNvZGUgYW5kIGV4Y2hhbmdlIGl0IGZvciBhbiBp ZF90b2tlbiBvbmx5LCByYXRoZXIgdGhhbiBhbiBhY2Nlc3NfdG9rZW4sIHNvIHlvdSdyZSBjaGFu Z2luZyB0aGUgc2VtYW50aWNzIG9mIHRoZSBUb2tlbiBFbmRwb2ludC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J J20gbm90IHNheWluZyBpdCdzIGEgYmFkIHRoaW5nLCBqdXN0IHRoYXQgeW91IGNhbid0IHJlYWxs eSBjb21wYXJlIG5vbmUgYW5kIGlkX3Rva2VuIHdpdGggY29kZV9mb3JfaWRfdG9rZW4uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdl ZCwgSnVsIDIzLCAyMDE0IGF0IDY6NDUgUE0sIFJpY2hlciwgSnVzdGluIFAuICZsdDs8YSBocmVm PSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJl Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SXQncyBvbmx5ICZxdW90O25vdCB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQmcXVv dDsgYmVjYXVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgY29weS1wYXN0ZWQgYW5kIHJlbmFtZWQgdGhl IGF1dGhlbnRpY2F0aW9uIGVuZHBvaW50Lg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOy0tIEp1c3RpbjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gSnVsIDIzLCAyMDE0LCBhdCA5OjMwIEFNLCBU aG9tYXMgQnJveWVyICZsdDs8YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5FeGNlcHQgdGhhdCB0aGVzZSBhcmUgYWJvdXQgbm90 IHVzaW5nIHRoZSBUb2tlbiBFbmRwb2ludCBhdCBhbGwsIHdoZXJlYXMgdGhlIGN1cnJlbnQgcHJv cG9zYWwgaXMgYWJvdXQgdGhlIFRva2VuIEVuZHBvaW50IG5vdCByZXR1cm5pbmcgYW4gYWNjZXNz X3Rva2VuIGZpZWxkIGluIHRoZSBKU09OLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIFdlZCwgSnVsIDIzLCAyMDE0IGF0IDQ6MjYgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhy ZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5N aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHJlc3BvbnNlX3R5cGUgJnF1b3Q7bm9uZSZxdW90 OyBpcyBhbHJlYWR5IHVzZWQgaW4gcHJhY3RpY2UsIHdoaWNoIHJldHVybnMgbm8gYWNjZXNzIHRv a2VuLiZuYnNwOyBJdCB3YXMgYWNjZXB0ZWQNCiBieSB0aGUgZGVzaWduYXRlZCBleHBlcnRzIGFu ZCByZWdpc3RlcmVkIGluIHRoZSBJQU5BIE9BdXRoIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgUmVz cG9uc2UgVHlwZXMgcmVnaXN0cnkgYXQNCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNz aWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhtbCNlbmRwb2ludCIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1w YXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueG1sI2VuZHBvaW50PC9hPi4mbmJzcDsgVGhlIHJl Z2lzdGVyZWQgJnF1b3Q7aWRfdG9rZW4mcXVvdDsgcmVzcG9uc2UgdHlwZSBhbHNvIHJldHVybnMg bm8gYWNjZXNzIHRva2VuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBJIHRoaW5rIHRo ZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHJlc3BvbnNlIHR5cGVzIHRoYXQgcmVzdWx0IGluIG5vIGFj Y2VzcyB0b2tlbiBiZWluZyByZXR1cm5lZCBhcmUNCiBhY2NlcHRhYmxlIHdpdGhpbiBPQXV0aCAy LjAgaXMgYWxyZWFkeSBzZXR0bGVkLCBhcyBhIHByYWN0aWNhbCBtYXR0ZXIuJm5ic3A7IExvdHMg b2YgT0F1dGggaW1wbGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IHVzaW5nIHN1Y2ggcmVzcG9uc2Ug dHlwZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0 bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIEJlaGFs ZiBPZiA8L3NwYW4+PC9zdHJvbmc+UGhpbCBIdW50PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNl bnQ6PC9zcGFuPjwvc3Ryb25nPiBXZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQgNzowOSBBTTxicj4N CjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ubzo8L3NwYW4+PC9zdHJvbmc+IE5hdCBTYWtpbXVyYTxicj4N CjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5DYzo8L3NwYW4+PC9zdHJvbmc+ICZsdDs8YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN1YmplY3Q6PC9zcGFuPjwvc3Ryb25nPiBSZTogW09B VVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjIt dXNlci1hNGMtMDUudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlllcy4gVGhpcyBpcyB3aHkgaXQg aGFzIHRvIGJlIGRpc2N1c3NlZCBpbiB0aGUgSUVURi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlBoaWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkBpbmRlcGVuZGVu dGlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3 LmluZGVwZW5kZW50aWQuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVudGlkLmNv bTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gSnVsIDIzLCAyMDE0 LCBhdCA5OjQzIEFNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlYWRpbmcgYmFjayB0aGUgUkZDNjc0OSwg SSBhbSBub3Qgc3VyZSBpZiB0aGVyZSBpcyBhIGdvb2Qgd2F5IG9mIHN1cHByZXNzaW5nIGFjY2Vz cyB0b2tlbiBmcm9tIHRoZSByZXNwb25zZSBhbmQgc3RpbGwgYmUgT0F1dGguIEl0IHdpbGwgYnJl YWsgd2hvbGUgYnVuY2ggb2YgaW1wbGljaXQgZGVmaW5pdGlvbnMNCiBsaWtlOiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmF1dGhv cml6YXRpb24gc2VydmVyPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlIHNlcnZlciBpc3N1 aW5nIGFjY2VzcyB0b2tlbnMgdG8gdGhlIGNsaWVudCBhZnRlciBzdWNjZXNzZnVsbHk8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyBhdXRoZW50aWNhdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIgYW5k IG9idGFpbmluZyBhdXRob3JpemF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BZnRlciBhbGwsIE9BdXRoIGlzIGFsbCBh Ym91dCBpc3N1aW5nIGFjY2VzcyB0b2tlbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWxzbywgSSB0 YWtlIGJhY2sgbXkgc3RhdGVtZW50IG9uIHRoZSBncmFudCB0eXBlIGluIG15IHByZXZpb3VzIG1h aWwuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGRlZmluaXRpb24gb2YgZ3JhbnQgYW5kIGdyYW50 X3R5cGUgYXJlIHJlc3BlY3RpdmVseTombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Z3JhbnQm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7ICZuYnNwOyBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3VyY2Ugb3du ZXIncyBhdXRob3JpemF0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmdyYW50X3R5cGU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IChzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSkgdHlwZSBvZiBncmFudCBzZW50IHRvIHRo ZSB0b2tlbiBlbmRwb2ludCB0byBvYnRhaW4gdGhlIGFjY2VzcyB0b2tlbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+VGh1cywgdGhlIGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IGluIHRo aXMgY2FzZSBpcyBzdGlsbCAnY29kZScuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVzcG9uc2UgdHlw ZSBvbiB0aGUgb3RoZXIgaGFuZCBpcyBub3Qgc28gd2VsbCBkZWZpbmVkIGluIFJGQzY3NDksIGJ1 dCBpdCBzZWVtcyBpdCBpcyByZXByZXNlbnRpbmcgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9t IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBUbyBleHByZXNzIHdoYXQgaXMgdG8NCiBiZSBy ZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50LCBwZXJoYXBzIGRlZmluaW5nIGEgbmV3IHBhcmFt ZXRlciB0byB0aGUgdG9rZW4gZW5kcG9pbnQsIHdoaWNoIGlzIGEgcGFyYWxsZWwgdG8gdGhlIHJl c3BvbnNlX3R5cGUgdG8gdGhlIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgc2VlbXMgdG8gYmUgYSBt b3JlIHN5bW1ldHJpYyB3YXksIHRob3VnaCBJIGFtIG5vdCBzdXJlIGF0IGFsbCBpZiB0aGF0IGlz IGdvaW5nIHRvIGJlIE9BdXRoIGFueSBtb3JlLg0KIE9uZSBzdHJhdy1tYW4gaXMgdG8gZGVmaW5l IGEgbmV3IHBhcmFtZXRlciBjYWxsZWQgcmVzcG9uc2VfdHlwZSB0byB0aGUgdG9rZW4gZW5kcG9p bnQgc3VjaCBhczombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5yZXNwb25zZV90eXBlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsg T1BUSU9OQUwuIEEgc3RyaW5nIHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZy b20gdGhlIHRva2VuIGVuZHBvaW50LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGVuIGRlZmluZSB0aGUgYmVoYXZpb3Igb2YgdGhlIGVuZHBvaW50IGFjY29yZGluZyB0byB0aGUg dmFsdWVzIGFzIHRoZSBwYXJhbGxlbCB0byB0aGUgbXVsdGktcmVzcG9uc2UgdHlwZSBzcGVjLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC12Mi1tdWx0aXBsZS1yZXNw b25zZS10eXBlcy0xXzAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9vcGVuaWQubmV0L3Nw ZWNzL29hdXRoLXYyLW11bHRpcGxlLXJlc3BvbnNlLXR5cGVzLTFfMC5odG1sPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjIwMTQtMDctMjMgNzoyMSBHTVQtMDQ6MDAgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWls dG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xl LmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoZSBkcmFmdCBpcyB2ZXJ5IGNsZWFyLiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xv cjojODg4ODg4Ij48YnI+DQo8YnI+DQpQaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEp1bCAyMywg MjAxNCwgYXQgMDo0NiwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+VGhlIG5ldyBncmFudCB0eXBlIHRoYXQgSSB3YXMgdGFsa2luZyBhYm91dCB3YXMmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZxdW90O2F1dGhv cml6YXRpb25fY29kZV9idXRfZG9fbm90X3JldHVybl9hY2Nlc3Nfbm9yX3JlZnJlc2hfdG9rZW4m cXVvdDssIHNvIHRvIHNwZWFrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGRvZXMgbm90IHJldHVybiBhbnl0aGluZyBwZXIgc2Us IGJ1dCBhbiBleHRlbnNpb24gY2FuIGRlZmluZSBzb21ldGhpbmcgb24gdG9wIG9mIGl0LiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoZW4sIE9JREMgY2FuIGRlZmluZSBhIGJpbmRpbmcgdG8gaXQgc28g dGhhdCB0aGUgYmluZGluZyBvbmx5IHJldHVybnMgSUQgVG9rZW4uJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgYmluZGluZyB3 b3JrIHNob3VsZCBiZSBkb25lIGluIE9JREYuIFNob3VsZCB0aGVyZSBiZSBzdWNoIGEgZ3JhbnQg dHlwZSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPml0IHdpbGwgYmUgYW4gZXh0cmVtZWx5IHNob3J0IHNw ZWMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXQgdGhlIHNhbWUgdGltZSwgaWYgYW55IG90aGVyIHNw ZWNpZmljYXRpb24gd2FudGVkIHRvIGRlZmluZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5vdGhlciB0eXBlIG9mIHRva2VucyBhbmQg aGF2ZSBpdCByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCwmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aXQgY2FuIGFsc28g dXNlIHRoaXMgZ3JhbnQgdHlwZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB3aGF0IHlvdSB3YW50 IGlzIHRvIGRlZmluZSBhIG5ldyBncmFudCB0eXBlIHRoYXQgcmV0dXJucyBJRCBUb2tlbiBvbmx5 LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj50aGVuLCBJIGFtIHdpdGggSnVzdGluLiBTaW5jZSAmcXVvdDtvdGhlciByZXNwb25zZSB0 aGFuIElEIFRva2VuJnF1b3Q7IGlzIG9ubHkmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGhlb3JldGljYWwsIHRoaXMgaXMgYSBtb3Jl IHBsYXVzaWJsZSB3YXkgZm9yd2FyZCwgSSBzdXBwb3NlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5h dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MjAxNC0wNy0yMiAx NDozMCBHTVQtMDQ6MDAgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJA bWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7OjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TbyB0aGUgZHJhZnQgd291bGQgbGl0ZXJh bGx5IHR1cm4gaW50bzo8YnI+DQo8YnI+DQomcXVvdDtUaGUgYTRjIHJlc3BvbnNlIHR5cGUgYW5k IGdyYW50IHR5cGUgcmV0dXJuIGFuIGlkX3Rva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IHdp dGggbm8gYWNjZXNzIHRva2VuLiBBbGwgcGFyYW1ldGVycyBhbmQgdmFsdWVzIGFyZSBkZWZpbmVk IGluIE9JREMuJnF1b3Q7PGJyPg0KPGJyPg0KU2VlbXMgbGlrZSB0aGUgcGVyZmVjdCBtaW5pIGV4 dGVuc2lvbiBkcmFmdCBmb3IgT0lERiB0byBkby48YnI+DQo8YnI+DQotLUp1c3Rpbjxicj4NCjxi cj4NCi9zZW50IGZyb20gbXkgcGhvbmUvPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YnI+DQpPbiBKdWwgMjIsIDIwMTQgMTA6MjkgQU0sIE5hdCBTYWtpbXVy YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IFdo YXQgYWJvdXQganVzdCBkZWZpbmluZyBhIG5ldyBncmFudCB0eXBlIGluIHRoaXMgV0c/PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IDIwMTQtMDctMjIgMTI6NTYgR01ULTA0OjAwIFBoaWwg SHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IFRoYXQgd291bGQgYmUgbmljZS4gSG93ZXZlciBvaWRjIHN0aWxsIG5lZWRzIHRoZSBu ZXcgZ3JhbnQgdHlwZSBpbiBvcmRlciB0byBpbXBsZW1lbnQgdGhlIHNhbWUgZmxvdy4mbmJzcDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFBoaWw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IE9uIEp1bCAyMiwgMjAxNCwgYXQgMTE6MzUsIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICYjNDM7 MSB0byBKdXN0aW4uJm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IDIwMTQtMDctMjIgOTo1NCBHTVQtMDQ6MDAgUmljaGVyLCBKdXN0aW4g UC4gJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmpyaWNoZXJAbWl0cmUub3JnPC9hPiZndDs6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgRXJyb3JzIGxpa2UgdGhlc2UgbWFrZSBpdCBjbGVhciB0byBtZSB0aGF0 IGl0IHdvdWxkIG1ha2UgbXVjaCBtb3JlIHNlbnNlIHRvIGRldmVsb3AgdGhpcyBkb2N1bWVudCBp biB0aGUgT3BlbklEIEZvdW5kYXRpb24uIEl0IHNob3VsZCBiZSBzb21ldGhpbmcgdGhhdCBkaXJl Y3RseSByZWZlcmVuY2VzIE9wZW5JRCBDb25uZWN0IENvcmUgZm9yIGFsbCBvZiB0aGVzZSB0ZXJt cyBpbnN0ZWFkIG9mIHJlZGVmaW5pbmcgdGhlbS4gSXQncyBkb2luZw0KIGF1dGhlbnRpY2F0aW9u LCB3aGljaCBpcyBmdW5kYW1lbnRhbGx5IHdoYXQgT3BlbklEIENvbm5lY3QgZG9lcyBvbiB0b3Ag b2YgT0F1dGgsIGFuZCBJIGRvbid0IHNlZSBhIGdvb2QgYXJndW1lbnQgZm9yIGRvaW5nIHRoaXMg d29yayBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgJm5ic3A7LS0gSnVzdGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgT24gSnVsIDIyLCAyMDE0LCBhdCA0OjMwIEFNLCBUaG9tYXMgQnJv eWVyICZsdDs8YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIE1vbiwg SnVsIDIxLCAyMDE0IGF0IDExOjUyIFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyBmb3IgeW91ciByZXZpZXcs IFRob21hcy4mbmJzcDsgVGhlICZxdW90O3Byb21wdD1jb25zZW50JnF1b3Q7IGRlZmluaXRpb24g YmVpbmcgbWlzc2luZyBpcyBhbiBlZGl0b3JpYWwgZXJyb3IuJm5ic3A7IEl0IHNob3VsZCBiZTo8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgJm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGNvbnNlbnQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIFNIT1VMRCBw cm9tcHQgdGhlIEVuZC1Vc2VyIGZvciBjb25zZW50IGJlZm9yZSByZXR1cm5pbmcgaW5mb3JtYXRp b24gdG8gdGhlIENsaWVudC4gSWYgaXQgY2Fubm90IG9idGFpbiBjb25zZW50LCBpdCBNVVNUIHJl dHVybiBhbiBlcnJvciwgdHlwaWNhbGx5IGNvbnNlbnRfcmVxdWlyZWQuPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOzxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJ J2xsIHBsYW4gdG8gYWRkIGl0IGluIHRoZSBuZXh0IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBJdCBsb29rcyBsaWtlIHRoZSBjb25zZW50X3JlcXVpcmVkIGVycm9yIG5lZWRzIHRvIGJlIGRl ZmluZWQgdG9vLCBhbmQgeW91IG1pZ2h0IGhhdmUgZm9yZ290dGVuIHRvIGFsc28gaW1wb3J0IGFj Y291bnRfc2VsZWN0aW9uX3JlcXVpcmVkIGZyb20gT3BlbklEIENvbm5lY3QuPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGFncmVlIHRoYXQgdGhlcmUncyBu byBkaWZmZXJlbmNlIGJldHdlZW4gYSByZXNwb25zZSB3aXRoIG11bHRpcGxlICZxdW90O2FtciZx dW90OyB2YWx1ZXMgdGhhdCBpbmNsdWRlcyAmcXVvdDttZmEmcXVvdDsgYW5kIG9uZSB0aGF0IGRv ZXNuJ3QuJm5ic3A7IFVubGVzcyBhIGNsZWFyIHVzZSBjYXNlIGZvciB3aHkgJnF1b3Q7bWZhJnF1 b3Q7IGlzIG5lZWRlZCBjYW4gYmUgaWRlbnRpZmllZCwgd2UgY2FuIGRlbGV0ZSBpdCBpbiB0aGUg bmV4dCBkcmFmdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzLjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSG93IGFib3V0ICZxdW90O3B3ZCZx dW90OyB0aGVuPyBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhhdCBJIHNob3VsZCByZXR1cm4gJnF1b3Q7 cHdkJnF1b3Q7IGlmIHRoZSB1c2VyIGF1dGhlbnRpY2F0ZWQgdXNpbmcgYSBwYXNzd29yZCwgYnV0 IHdoYXQgJnF1b3Q7dGhlIHNlcnZpY2UgaWYgYSBjbGllbnQgc2VjcmV0IGlzIHVzZWQmcXVvdDsg bWVhbnMgaW4gdGhlIGRlZmluaXRpb24gZm9yIHRoZSAmcXVvdDtwd2QmcXVvdDsgdmFsdWU/PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAoTm90YTog SSBrbm93IHlvdSdyZSBhdCBJRVRGLTkwLCBJJ20gcmVhZHkgdG8gd2FpdCAndGlsIHlvdSBjb21l IGJhY2sgOy0pICk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IC0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhvbWFzIEJyb3llcjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IC90PGEgaHJlZj0iaHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14 eGIuamUvIiB0YXJnZXQ9Il9ibGFuayI+yZQubWEuYsqBd2EuamUvPC9hPjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+ PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLS08YnI+DQomZ3Q7 Jmd0OyZndDsgTmF0IFNha2ltdXJhICg9bmF0KTxicj4NCiZndDsmZ3Q7Jmd0OyBDaGFpcm1hbiwg T3BlbklEIEZvdW5kYXRpb248YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL25hdC5z YWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9h Pjxicj4NCiZndDsmZ3Q7Jmd0OyBAX25hdF9lbjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsgPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5v cmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBOYXQgU2FraW11cmEgKD1uYXQpPGJy Pg0KJmd0OyBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQomZ3Q7IDxhIGhyZWY9Imh0 dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11 cmEub3JnLzwvYT48YnI+DQomZ3Q7IEBfbmF0X2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLQ0K PGJyPg0KTmF0IFNha2ltdXJhICg9bmF0KTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KPGEgaHJlZj0i aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25hdC5zYWtp bXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8YnI+DQpOYXQgU2Fr aW11cmEgKD1uYXQpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNh a2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+ PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4tLQ0KPGJyPg0KVGhvbWFzIEJyb3llcjxicj4NCi90PGEgaHJlZj0iaHR0cDovL3huLS1ubmEu bWEueG4tLWJ3YS14eGIuamUvIiB0YXJnZXQ9Il9ibGFuayI+yZQubWEuYsqBd2EuamUvPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij4tLQ0KPGJyPg0KVGhvbWFzIEJyb3llcjxicj4NCi90PGEgaHJl Zj0iaHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvIiB0YXJnZXQ9Il9ibGFuayI+yZQu bWEuYsqBd2EuamUvPC9hPiA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBj bGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPi0tDQo8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpIDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0 aW9uPGJyPg0KPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBs aXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxw cmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxs Ij4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+DQpOYXQg U2FraW11cmEgKD1uYXQpIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQu c2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwv YT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCkgPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4sIE9wZW5JRCBG b3VuZGF0aW9uPGJyPg0KPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxl ZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg IzEwMTBGRiAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9 ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0K TmF0IFNha2ltdXJhICg9bmF0KTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9u YXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3Jn LzwvYT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_054c4958db6545cf99d3f0339e34c776BLUPR03MB309namprd03pro_-- From nobody Thu Jul 24 10:51:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1071B27A7 for ; Thu, 24 Jul 2014 10:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBp1226kGuv0 for ; Thu, 24 Jul 2014 10:51:15 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C261B279B for ; Thu, 24 Jul 2014 10:50:39 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so10079180wiv.17 for ; Thu, 24 Jul 2014 10:50:38 -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=OZio4OJWhS3W55XZ/7flVbFBAqZxgX4p8RvYeWtpZuM=; b=YEmQepkwiDU+75VjzF9ksYh8Q1lD3puieC0N9M+Ww2JKbitPK/aoUtAz4CkkPHa07M uvC8HRp79jD+o77p0X9q3Qp1lFoxPRpHJjjqRA1YIuNZ8diLvQd3jLSuBAPIiAtv1zTA gwmacTubmT2VxmusVIMiej8mS/cxqs91qTkUyEwwAtffjIK/bIQ8i4rfbdfRgNRu2UMb pp/dsbL9+7FOc/EoYTgW2wUR/N2TgS5qsOn2otM2ud0L+4XFmy5zfLX4gydrJ0qiaAKF S+yWvq1HwQvE0/u9KNddgjoCD/DHTf9tZPjNV5l107NinJ0hsxM0qtox+lvWkvysILB1 RR8g== X-Gm-Message-State: ALoCoQlB7tsIItUyZ2378QBoSj0uV1T0G7uvz4IBINCKZoGUW+5W/HeTdBD7BH8NS+caGuQ2RrFR X-Received: by 10.180.19.35 with SMTP id b3mr14954631wie.52.1406224237413; Thu, 24 Jul 2014 10:50:37 -0700 (PDT) Received: from dhcp-937d.meeting.ietf.org (dhcp-937d.meeting.ietf.org. [31.133.147.125]) by mx.google.com with ESMTPSA id de6sm17724762wjc.16.2014.07.24.10.50.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 10:50:35 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D1F23F06-03A8-45F6-A8D4-03A2BF17CB33" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <054c4958db6545cf99d3f0339e34c776@BLUPR03MB309.namprd03.prod.outlook.com> Date: Thu, 24 Jul 2014 10:50:46 -0700 Message-Id: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <054c4958db6545cf99d3f0339e34c776@BLUPR03MB309.namprd03.prod.outlook.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/gUI4ac4fyukAbb--bxnjFNyA_cI Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 17:51:28 -0000 --Apple-Mail=_D1F23F06-03A8-45F6-A8D4-03A2BF17CB33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Connect needed to be completed. To do that some things that were not = Identity specific but required for Connect to be interoperable also = needed to be completed in a stable form. The fact that with some tweaking based on input from the IETF community = like software statements Connect's dynamic registration could be = generally applied to the problem of dynamic client registration for = OAuth, should not come as a surprise. Given the OIDF copyright of allowing derivative works with attribution = this is not a unexpected or undesired outcome. The outcome is more support for a spec that increases support and = interoperability. Yes the two are similar but not the same. A IETF published profile of Connect using code flow only and not = attaching scopes to the access token or additional claims to the = id_token could be seen as a fine bridge for enterprise SSO moving from = the old WS-* to something REST friendly on the road to full OAuth and = Connect support. The point for many of us is to make it clear that it is a step on a path = and not to become it's own incompatible dead end where the clients = libraries can't deal with access tokens or multiple issuers etc. I also take Bills point about developers. They care far more about good code examples on SalesForece, Google, = Microsoft and other sites as well as packaged library support from = reliable open-source projects than they do about IETF or OIDF = specifications Better communication and support for developers is required. How to do = that is the more important discussion. The format of a parameter to = suppress an access_token being issued is largely a snipe hunt. It is unfortunate that this is making some people cranky. I think we do mostly agree that we have a communications and education = problem. Just because our main tool is crating new RFC's that doesn't = necessarily mea that it is our only or best option in this case. Best Regards John B. On Jul 24, 2014, at 10:25 AM, Anthony Nadalin = wrote: > OMG, how can you say that when the Dynamkc Reg does the same thing = (duplicates) but that is OK to do > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian = Campbell > Sent: Thursday, July 24, 2014 10:22 AM > To: John Bradley > Cc: oauth@ietf.org list > Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt > =20 > I'm sorry to miss what will likely be a very engaging meeting today. >=20 > The premise that some developers are using OAuth in a insecure way to = do authentication is something we can probably all agree on.=20 >=20 > It doesn't necessarily follow from that premise, however, that the = solution is yet another spec which either duplicates some subset of = OpenID Connect (in a different SDO) or forks how to do = SSO/authentication using OAuth. > =20 >=20 > On Thu, Jul 24, 2014 at 7:25 AM, John Bradley = wrote: > I am not against discussion in the WG. > =20 > I happen to agree with Phil's fundamental premise that some developers = are using OAuth in a insecure way to do authentication. > =20 > That raises the question of how to best educate them, and or address = technical barriers. > =20 > It is on the second point that people's opinions seem to divide. > =20 > Some people thing that if we have a OAuth flow that eliminates the = access token (primarily to avoid asking for consent as I understand it) = and just return a id_token from the token endpoint that can be done in a = spec short enough to het people to read. The subtext of this is that = the Connect specification is too large that it scare people, and they = don't find the spec in the first place because it is not a RFC. > =20 > An other common possession is that if you don't want to prompt the = user for consent then don't ask for scopes. Twisting the OAuth spec to = not return an access token is not OAuth, yes you could use a different = endpoint rather than the token endpoint, but that is not OAuth. = Connect was careful not to break the OAuth spec. As long as you are = willing to take a access token with no scopes (the client needs to = understand that there are no attributes one way or another anyway or it = will break) then you don't need to change OAuth. You can publish a = profile of connect that satisfies the use case. > =20 > I think Mike has largely done that but it might be better being less = stingy on references back to the larger spec. > =20 > The questions are do we modify OAuth to not return an access token, = and if so how, and if we do is it still OAuth. > =20 > The other largely separable question is do we create confusion in the = market and slow the the adoption of identity federation on top of OAuth, = or find a way to make this look like a positive alignment of interests = around a subset of Connect. > =20 > There are a number of options. =20 > 1: We can do a profile in the OIDF and publish it as a IETF document. = Perhaps the cleanest from an IPR point of view. > 2:We can do a profile in the OAuth WG referencing connect. > 3:We can do a AD sponsored profile that is not in the OAuth WG. > 4:We can do a small spec in OAuth to add response_type to the token = endpoint. in combination with 1, 2, or 3 > =20 > I agree that stoping developers doing insecure things needs to be = addressed somehow. =20 > I am not personally convinced that Oauth without access tokens is = sensible. > =20 > Looking forward to the meeting:) > =20 > John B. > =20 > On Jul 24, 2014, at 6:52 AM, Brian Campbell = wrote: >=20 >=20 > I'd note that the reaction at the conference to Ian's statement was = overwhelmingly positive. There was a wide range of industry people here = - implementers, practitioners, deployers, strategists, etc. - and it = seems pretty clear that the "rough consensus" of the industry at large = is that a4c is not wanted or needed. > =20 >=20 > On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura = wrote: > And here is a quote from Ian's blog.=20 > =20 > And although the authentication wheel is round, that doesn=E2=80=99t = mean it isn=E2=80=99t without its lumps. First, we do see some = reinventing the wheel just to reinvent the wheel. OAuth A4C is simply = not a fruitful activity and should be put down. =20 > =20 > (Source) = http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musing= s-on-identity-standards-part-1.html > =20 >=20 > 2014-07-23 16:53 GMT-04:00 John Bradley : > =20 > I thought I did post this to the list.=20 > =20 > I guess I hit the wrong reply on my phone.=20 > =20 > John B.=20 > Sent from my iPhone >=20 > On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: >=20 > we are two, at least :-) >=20 > Why didn't you post this on the list? >=20 > When will be be arriving? >=20 > Am 23.07.2014 16:39, schrieb John Bradley: >=20 > Ian Glazer mentioned this in his keynote at CIS yesterday.=20 > =20 > His advice was please stop, we are creating confusion and = uncertainty.=20 > =20 > We are becoming our own wort enemy. ( my view though Ian may share it) > =20 > Returning just an id_ token from the token endpoint has little real = value.=20 > =20 > Something really useful to do would be sorting out channel_id so we = can do PoP for id tokens to make them and other cookies secure in the = front channel. I think that is a better use of time.=20 > =20 > I may be in the minority opinion on that, it won't be the first time. = =20 >=20 >=20 > John B.=20 > Sent from my iPhone >=20 > On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt = wrote: >=20 > You are right from a theoretical perspective. Practically this was = caused by editorial decisions during the creation of the RFC. As far as = I remember, there was a definition of the (one) token endpoint response = in early versions. No one every considered to NOT respond with an access = token from the token endpoint. So one might call it an implicit = assumption. > =20 > I'm worried that people get totally confused if an exception is = introduced now given the broad adoption of OAuth based on this = assumption. > =20 > regards, > Torsten. >=20 > Am 23.07.2014 um 15:41 schrieb Thomas Broyer : >=20 > Is it said anywhere that ALL grant types MUST use Section 5.1 = responses? Each grant type references Section 5.1, and "access token = request" is only defined in the context of the defined grant types. = Section 2.2 doesn't talk about the request or response format. >=20 > Le 23 juil. 2014 21:32, "Nat Sakimura" a =C3=A9crit= : > Is it? Apart from the implicit grant that does not use token endpoint, = all other grant references section 5.1 for the response, i.e., all = shares the same response.=20 > =20 >=20 > 2014-07-23 15:18 GMT-04:00 Thomas Broyer : > I hadn't realized the JSON response that requires the access_token = field is defined per grant_type, so I'd be OK to "extend the semantics" = as in the current draft. > That was actually my main concern: that the token endpoint mandates = access_token; but its actually not the case. >=20 > Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9crit= : > =20 > I agree with John that overloading response_type @ authz endpoint is a = bad idea. It completely changes the semantics of this parameter. NOTE: = what I was proposing was not this parameter, but a new parameter = response_type @ token endpoint.=20 > =20 > I also think overloading grant_type is a bad idea since it changes its = semantics. I quote the definition here again:=20 > =20 > grant=20 > credential representing the resource owner's authorization > =20 > grant_type > type of grant sent to the token endpoint to obtain the access token > =20 > It is not about controlling what is to be returned from the token = endpoint, but the hint to the token endpoint describing the type of = credential the endpoint has received. It seems the "control of what is = being returned from token endpoint" is just a side effect.=20 > =20 > I am somewhat ambivalent[1] in changing the semantics of token = endpoint, but in as much as "text is the king" for a spec., we probably = should not change the semantics of it as Torsten points out. If it is ok = to change this semantics, I believe defining a new parameter to this = endpoint to control the response would be the best way to go. This is = what I have described previously.=20 > =20 > Defining a new endpoint to send code to get ID Token and forbidding = the use of it against token endpoint would not change the semantics of = any existing parameter or endpoint, which is good. However, I doubt if = it is not worth doing. What's the point of avoiding access token scoped = to UserInfo endpoint after all? Defining a new endpoint for just = avoiding the access token for userinfo endpoint seems way too much the = heavy wait way and it breaks interoperabiliy: it defeats the purpose of = standardization.=20 > =20 > I have started feeling that no change is the best way out.=20 > =20 > Nat > =20 > [1] If instead of saying "Token endpoint - used by the client to = exchange an authorization grant for an access token, typically with = client authentication", it were saying "Token endpoint - used by the = client to exchange an authorization grant for tokens, typically with = client authentication", then it would have been OK. It is an expansion = of the capability rather than changing the semantics. > =20 > =20 >=20 > 2014-07-23 13:39 GMT-04:00 Mike Jones : > You need the alternative response_type value ("code_for_id_token" in = the A4C draft) to tell the Authorization Server to return a code to be = used with the new grant type, rather than one to use with the = "authorization_code" grant type (which is what response_type=3Dcode = does). > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Wednesday, July 23, 2014 10:33 AM > To: torsten@lodderstedt.net >=20 > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt > =20 > =20 > If we use the token endpoint then a new grant_type is the best way.=20 > =20 > It sort of overloads code, but that is better than messing with = response_type for the authorization endpoint to change the response from = the token_endpoint. That is in my opinion a champion bad idea.=20 > =20 > In discussions developing Connect we decided not to open this can of = worms because no good would come of it. =20 > =20 > The token_endpoint returns a access token. Nothing requires scope to = be associates with the token.=20 > =20 > That is the best solution. No change required. Better = interoperability in my opinion.=20 > =20 > Still on my way to TO, getting in later today.=20 > =20 > John B.=20 > =20 >=20 >=20 > Sent from my iPhone >=20 > On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >=20 > The "response type" of the token endpoint is controlled by the value = of the parameter "grant_type". So there is no need to introduce a new = parameter. >=20 > wrt to a potential "no_access_token" grant type. I do not consider = this a good idea as it changes the semantics of the token endpoint (as = already pointed out by Thomas). This endpoint ALWAYS responds with an = access token to any grant type. I therefore would prefer to use another = endpoint for the intended purpose. >=20 > regards, > Torsten. >=20 > =20 > Am 23.07.2014 13:04, schrieb Nat Sakimura: >=20 > IMHO, changing the semantics of "response_type" @ authz endpoint this = way is not a good thing.=20 > =20 > Instead, defining a new parameter "response_type" @ token endpoint, as = I described in my previous message,=20 > probably is better. At least, it does not change the semantics of the = parameters of RFC6749.=20 > =20 > Nat=20 > =20 > 2014-07-23 12:48 GMT-04:00 Thomas Broyer : > No, I mean response_type=3Dnone and response_type=3Did_token don't = generate a code or access token so you don't use the Token Endpoint = (which is not the same as the Authentication Endpoint BTW). > With response_type=3Dcode_for_id_token, you get a code and exchange it = for an id_token only, rather than an access_token, so you're changing = the semantics of the Token Endpoint. > =20 > I'm not saying it's a bad thing, just that you can't really compare = none and id_token with code_for_id_token. > =20 > On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. = wrote: > It's only "not using the token endpoint" because the token endpoint = copy-pasted and renamed the authentication endpoint. > =20 > -- Justin > =20 > On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: > =20 >=20 > Except that these are about not using the Token Endpoint at all, = whereas the current proposal is about the Token Endpoint not returning = an access_token field in the JSON. > =20 > On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones = wrote: > The response_type "none" is already used in practice, which returns no = access token. It was accepted by the designated experts and registered = in the IANA OAuth Authorization Endpoint Response Types registry = athttp://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#en= dpoint. The registered "id_token" response type also returns no access = token. > =20 > So I think the question of whether response types that result in no = access token being returned are acceptable within OAuth 2.0 is already = settled, as a practical matter. Lots of OAuth implementations are = already using such response types. > =20 > -- Mike > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf OfPhil Hunt > Sent: Wednesday, July 23, 2014 7:09 AM > To: Nat Sakimura > Cc: > Subject: Re: [OAUTH-WG] New Version Notification for = draft-hunt-oauth-v2-user-a4c-05.txt > =20 > Yes. This is why it has to be discussed in the IETF. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: > =20 > Reading back the RFC6749, I am not sure if there is a good way of = suppressing access token from the response and still be OAuth. It will = break whole bunch of implicit definitions like:=20 > =20 > authorization server > The server issuing access tokens to the client after = successfully > authenticating the resource owner and obtaining authorization. > =20 > After all, OAuth is all about issuing access tokens.=20 > =20 > Also, I take back my statement on the grant type in my previous mail.=20= > =20 > The definition of grant and grant_type are respectively:=20 > =20 > grant=20 > credential representing the resource owner's authorization > =20 > grant_type > (string representing the) type of grant sent to the token endpoint = to obtain the access token > =20 > Thus, the grant sent to the token endpoint in this case is still = 'code'.=20 > =20 > Response type on the other hand is not so well defined in RFC6749, but = it seems it is representing what is to be returned from the = authorization endpoint. To express what is to be returned from token = endpoint, perhaps defining a new parameter to the token endpoint, which = is a parallel to the response_type to the Authorization Endpoint seems = to be a more symmetric way, though I am not sure at all if that is going = to be OAuth any more. One straw-man is to define a new parameter called = response_type to the token endpoint such as:=20 > =20 > response_type > OPTIONAL. A string representing what is to be returned from the = token endpoint.=20 > =20 > Then define the behavior of the endpoint according to the values as = the parallel to the multi-response type spec.=20 > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html > =20 > Nat > =20 > =20 > =20 > =20 > 2014-07-23 7:21 GMT-04:00 Phil Hunt : > The draft is very clear.=20 >=20 > Phil >=20 > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: >=20 > The new grant type that I was talking about was=20 > "authorization_code_but_do_not_return_access_nor_refresh_token", so to = speak.=20 > It does not return anything per se, but an extension can define = something on top of it.=20 > =20 > Then, OIDC can define a binding to it so that the binding only returns = ID Token.=20 > This binding work should be done in OIDF. Should there be such a grant = type,=20 > it will be an extremely short spec.=20 > =20 > At the same time, if any other specification wanted to define=20 > other type of tokens and have it returned from the token endpoint,=20 > it can also use this grant type.=20 > =20 > If what you want is to define a new grant type that returns ID Token = only,=20 > then, I am with Justin. Since "other response than ID Token" is only=20= > theoretical, this is a more plausible way forward, I suppose.=20 > =20 > Nat > =20 > 2014-07-22 14:30 GMT-04:00 Justin Richer : > So the draft would literally turn into: >=20 > "The a4c response type and grant type return an id_token from the = token endpoint with no access token. All parameters and values are = defined in OIDC." >=20 > Seems like the perfect mini extension draft for OIDF to do. >=20 > --Justin >=20 > /sent from my phone/ >=20 > On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: > > > > What about just defining a new grant type in this WG? > > > > > > 2014-07-22 12:56 GMT-04:00 Phil Hunt : > >> > >> That would be nice. However oidc still needs the new grant type in = order to implement the same flow.=20 > >> > >> Phil > >> > >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: > >> > >>> +1 to Justin.=20 > >>> > >>> > >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : > >>>> > >>>> Errors like these make it clear to me that it would make much = more sense to develop this document in the OpenID Foundation. It should = be something that directly references OpenID Connect Core for all of = these terms instead of redefining them. It's doing authentication, which = is fundamentally what OpenID Connect does on top of OAuth, and I don't = see a good argument for doing this work in this working group. > >>>> > >>>> -- Justin > >>>> > >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer = wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones = wrote: > >>>>>> > >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" = definition being missing is an editorial error. It should be: > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> consent > >>>>>> > >>>>>> The Authorization Server SHOULD prompt the End-User for consent = before returning information to the Client. If it cannot obtain consent, = it MUST return an error, typically consent_required. > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> I'll plan to add it in the next draft. > >>>>> > >>>>> > >>>>> It looks like the consent_required error needs to be defined = too, and you might have forgotten to also import = account_selection_required from OpenID Connect. > >>>>> =20 > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> I agree that there's no difference between a response with = multiple "amr" values that includes "mfa" and one that doesn't. Unless = a clear use case for why "mfa" is needed can be identified, we can = delete it in the next draft. > >>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>> How about "pwd" then? I fully understand that I should return = "pwd" if the user authenticated using a password, but what "the service = if a client secret is used" means in the definition for the "pwd" value? > >>>>> > >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come = back ;-) ) > >>>>> > >>>>> -- > >>>>> Thomas Broyer > >>>>> /t=C9=94.ma.b=CA=81wa.je/ > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> > >>> > >>> > >>> -- > >>> Nat Sakimura (=3Dnat) > >>> Chairman, OpenID Foundation > >>> http://nat.sakimura.org/ > >>> @_nat_en > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>>https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > =20 > --=20 > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > =20 > --=20 > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_D1F23F06-03A8-45F6-A8D4-03A2BF17CB33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Connect needed to be completed.  To do that = some things that were not Identity specific but required for Connect to = be interoperable also needed to be completed in a stable = form.

The fact that with some tweaking based on input = from the IETF community like software statements Connect's dynamic = registration could be generally applied to the problem of dynamic client = registration for OAuth, should not come as a = surprise.

Given the OIDF copyright of allowing = derivative works with attribution this is not a unexpected or undesired = outcome.

The outcome is more support for a spec = that increases support and = interoperability.

Yes the two are similar but = not the same.

A IETF published profile of = Connect using code flow only and not attaching scopes to the access = token or additional claims to the id_token could be seen as a fine = bridge for enterprise SSO moving from the old WS-* to something REST = friendly on the road to full OAuth and Connect = support.

The point for many of us is to make it = clear that it is a step on a path and not to become it's own = incompatible dead end where the clients libraries can't deal with access = tokens or multiple issuers etc.

I also take = Bills point about developers.

They care far = more about good code examples on SalesForece,  Google, Microsoft = and other sites as well as packaged library support from reliable = open-source projects than they do about IETF or OIDF = specifications

Better communication and support = for developers is required.  How to do that is the more important = discussion.   The format of a parameter to suppress an access_token = being issued is largely a snipe hunt.

It is = unfortunate that this is making some people = cranky.

I think we do mostly agree that we have = a communications and education problem.   Just because our main = tool is crating new RFC's that doesn't necessarily mea that it is our = only or best option in this case.

Best = Regards
John B.


On Jul = 24, 2014, at 10:25 AM, Anthony Nadalin <tonynad@microsoft.com> = wrote:

OMG, how can you say that when the Dynamkc Reg does = the same thing (duplicates) but that is OK to = do
From: OAuth [mailto:oauth-bounces@ietf.org]<= span class=3D"Apple-converted-space"> On Behalf Of Brian = Campbell
Sent: Thursday, July 24, 2014 = 10:22 AM
To: John = Bradley
Cc: oauth@ietf.org = list
Subject: Re: [OAUTH-WG] New Version = Notification for = draft-hunt-oauth-v2-user-a4c-05.txt
 
I'm sorry to miss what will likely be a very engaging meeting = today.

The premise that some developers are using OAuth in a = insecure way to do authentication is something we can probably all agree = on. 

It doesn't = necessarily follow from that premise, however, that the solution is yet = another spec which either duplicates some subset of OpenID Connect (in a = different SDO) or forks how to do SSO/authentication using = OAuth.

 

On = Thu, Jul 24, 2014 at 7:25 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
I am not against discussion in the = WG.
 
I = happen to agree with Phil's fundamental premise that some developers are = using OAuth in a insecure way to do = authentication.
 
That = raises the question of how to best educate them, and or address = technical barriers.
 
It is = on the second point that people's opinions seem to = divide.
 
Some = people thing that if we have a OAuth flow that eliminates the access = token (primarily to avoid asking for consent as I understand it) and = just return a id_token from the token endpoint that can be done in a = spec short enough to het people to read.   The subtext of this is = that the Connect specification is too large that it scare people, =  and they don't find the spec in the first place because it is not = a RFC.
 
An = other common possession is that if you don't want to prompt the user for = consent then don't ask for scopes.  Twisting the OAuth spec to not = return an access token is not OAuth,  yes you could use a different = endpoint rather than the token endpoint, but that is not OAuth.   = Connect was careful not to break the OAuth spec.    As long as = you are willing to take a access token with no scopes (the client needs = to understand that there are no attributes one way or another anyway or = it will break) then you don't need to change OAuth.   You can = publish a profile of connect that satisfies the use = case.
 
I = think Mike has largely done that but it might be better being less = stingy on references back to the larger = spec.
 
The = questions are do we modify OAuth to not return an access token, and if = so how,  and if we do is it still = OAuth.
 
The = other largely separable question is do we create confusion in the market = and slow the the adoption of identity federation on top of OAuth, or = find a way to make this look like a positive alignment of interests = around a subset of Connect.
 
There are a number of options. =  
1: We = can do a profile in the OIDF and publish it as a IETF document.   = Perhaps the cleanest from an IPR point of = view.
2:We can do a = profile in the OAuth WG referencing = connect.
3:We = can do a AD sponsored profile that is not in the OAuth = WG.
4:We can do a = small spec in OAuth to add response_type to the token endpoint.  in = combination with 1, 2, or 3
 
I agree that stoping developers doing insecure = things needs to be addressed somehow. =  
I am = not personally convinced that Oauth without access tokens is = sensible.
 
Looking forward to the meeting:)
 
John B.
 
On = Jul 24, 2014, at 6:52 AM, Brian Campbell <bcampbell@pingidentity.com> = wrote:


I'd note that = the reaction at the conference to Ian's statement was overwhelmingly = positive. There was a wide range of industry people here - implementers, = practitioners, deployers, strategists, etc. - and it seems pretty clear = that the "rough consensus" of the industry at large is that a4c is not = wanted or needed.

 

On = Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura <sakimura@gmail.com> = wrote:
And here is a quote from Ian's = blog. 
 
And although the = authentication wheel is round, that doesn=E2=80=99t mean it isn=E2=80=99t = without its lumps. First, we do see some reinventing the wheel just to = reinvent the wheel. OAuth A4C is simply not a fruitful activity and = should be put down.  
 

 

2014-07-23 16:53 GMT-04:00 John Bradley <ve7jtb@ve7jtb.com>:
 
I thought I did post this to the = list. 
 
I = guess I hit the wrong reply on my = phone. 
 
John B. 
Sent from my = iPhone


On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote:

we are two, at least = :-)

Why didn't you = post this on the list?

When will be be arriving?

Am 23.07.2014 16:39, schrieb John = Bradley:

Ian Glazer = mentioned this in his keynote at CIS = yesterday. 
 
His = advice was please stop,  we are creating confusion and = uncertainty. 
 
We = are becoming our own wort enemy. ( my view though Ian may share = it)
 
Returning just an id_ token from the token endpoint has little = real value. 
 
Something really useful to do would be sorting out channel_id so = we can do PoP for id tokens to make them and other cookies secure in the = front channel.   I think that is a better use of = time. 
 
I may = be in the minority opinion on that,  it won't be the first time. =  


John = B. 
Sent from my iPhone


On Jul 23, 2014, at 4:04 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

You are right = from a theoretical perspective. Practically this was caused by editorial = decisions during the creation of the RFC. As far as I remember, there = was a definition of the (one) token endpoint response in early versions. = No one every considered to NOT respond with an access token from the = token endpoint. So one might call it an implicit = assumption.
 
I'm = worried that people get totally confused if an exception is introduced = now given the broad adoption of OAuth based on this = assumption.
 
regards,
Torsten.


Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

Is it said anywhere that ALL = grant types MUST use Section 5.1 responses? Each grant type references = Section 5.1, and "access token request" is only defined in the context = of the defined grant types. Section 2.2 doesn't talk about the request = or response format.

Le 23 = juil. 2014 21:32, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit = :
Is it? Apart from the implicit = grant that does not use token endpoint, all other grant references = section 5.1 for the response, i.e., all shares the same = response. 

 

2014-07-23 15:18 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:

I hadn't realized the JSON response that requires the = access_token field is defined per grant_type, so I'd be OK to "extend = the semantics" as in the current draft.
That was actually my main = concern: that the token endpoint mandates access_token; but its actually = not the case.

Le 23 juil. = 2014 20:46, "Nat Sakimura" <sakimura@gmail.com> a =C3=A9crit = :
 
I agree with = John that overloading response_type @ authz endpoint is a bad idea. It = completely changes the semantics of this parameter. NOTE: what I was = proposing was not this parameter, but a new parameter response_type @ = token endpoint. 
 
I = also think overloading grant_type is a bad idea since it changes its = semantics. I quote the definition here = again: 
 
grant 
    credential representing the resource owner's = authorization
 
grant_type
type of grant sent to the token endpoint to obtain the access = token
 
It is = not about controlling what is to be returned from the token endpoint, = but the hint to the token endpoint describing the type of credential the = endpoint has received. It seems the "control of what is being returned = from token endpoint"  is just a side = effect. 
 
I am = somewhat ambivalent[1] in changing the semantics of token endpoint, but = in as much as "text is the king" for a spec., we probably should not = change the semantics of it as Torsten points out. If it is ok to change = this semantics, I believe defining a new parameter to this endpoint to = control the response would be the best way to go. This is what I have = described previously. 
 
Defining a new endpoint to send code to get ID Token = and forbidding the use of it against token endpoint would not change the = semantics of any existing parameter or endpoint, which is good. However, = I doubt if it is not worth doing. What's the point of avoiding access = token scoped to UserInfo endpoint after all? Defining a new endpoint for = just avoiding the access token for userinfo endpoint seems way too much = the heavy wait way and it breaks interoperabiliy: it defeats the purpose = of standardization. 
 
I = have started feeling that no change is the best way = out. 
 
Nat
 
[1] =  If instead of saying "Token endpoint - used by the client to = exchange an authorization grant for an access token, typically with = client authentication", it were saying "Token endpoint - used by the = client to exchange an authorization grant for tokens, typically = with client authentication", then it would have been OK. It is an = expansion of the capability rather than changing the = semantics.
 

 

2014-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@microsoft.com>:
You need the alternative = response_type value ("code_for_id_token" in = the A4C draft) to tell the Authorization Server to return a code to be = used with the new grant type, rather than one to use with the = "authorization_code" grant type (which is what response_type=3Dcode = does).
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Wednesday, July 23, 2014 = 10:33 AM
To: torsten@lodderstedt.net

Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version = Notification for = draft-hunt-oauth-v2-user-a4c-05.txt
 
 
If we use the token endpoint then a new grant_type = is the best way. 
 
It = sort of overloads code, but that is better than messing with = response_type for the authorization endpoint to change the response from = the token_endpoint.  That is in my opinion a champion bad = idea. 
 
In = discussions developing Connect we decided not to open this can of worms = because no good would come of it. =   
 
The = token_endpoint returns a access token.  Nothing requires scope to = be associates with the token. 
 
That is the best solution.  No change required. =  Better interoperability in my = opinion. 
 
Still = on my way to TO, getting in later = today. 
 
John = B. 
 


Sent from my iPhone


On Jul 23, 2014, at 12:15 = PM, torsten@lodderstedt.net wrote:

The "response type" of the token = endpoint is controlled by the value of the parameter "grant_type". So = there is no need to introduce a new parameter.

wrt to a potential = "no_access_token" grant type. I do not consider this a good idea as it = changes the semantics of the token endpoint (as already pointed out by = Thomas). This endpoint ALWAYS responds with an access token to any grant = type. I therefore would prefer to use another endpoint for the intended = purpose.

regards,
Torsten.

 

Am 23.07.2014 13:04, schrieb Nat = Sakimura:

IMHO, changing = the semantics of "response_type" @ authz endpoint this way is not a good = thing. 
 
Instead, defining a new parameter "response_type" @ token = endpoint, as I described in my previous = message, 
probably is better. At least, it does not change the semantics = of the parameters of RFC6749. 
 
 Nat 
 
2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:
No, I mean response_type=3Dnone and = response_type=3Did_token don't generate a code or access token so you = don't use the Token Endpoint (which is not the same as the = Authentication Endpoint BTW).
With response_type=3Dcode_for_id_token, you get a code and = exchange it for an id_token only, rather than an access_token, so you're = changing the semantics of the Token = Endpoint.
 
I'm = not saying it's a bad thing, just that you can't really compare none and = id_token with = code_for_id_token.
 
On = Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. <jricher@mitre.org> = wrote:
It's only "not = using the token endpoint" because the token endpoint copy-pasted and = renamed the authentication endpoint.
 
 -- Justin
 
On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com> = wrote:

 

Except that these are about not using the Token Endpoint at all, = whereas the current proposal is about the Token Endpoint not returning = an access_token field in the JSON.
 
On = Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:
The response_type "none" is already used in practice, = which returns no access token.  It was accepted by the designated = experts and registered in the IANA OAuth Authorization Endpoint Response = Types registry athttp://www.iana.org/assignments/oauth-parameters/oauth-paramet= ers.xml#endpoint.  The registered "id_token" response type also = returns no access token.
 
So I think the question of whether response types = that result in no access token being returned are acceptable within = OAuth 2.0 is already settled, as a practical matter.  Lots of OAuth = implementations are already using such response = types.
 
           &= nbsp;           &nb= sp;            = ;            &= nbsp;           -- = Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = OfPhil Hunt
Sent: Wednesday, July 23, 2014 = 7:09 AM
To: Nat = Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version = Notification for = draft-hunt-oauth-v2-user-a4c-05.txt
 
Yes. = This is why it has to be discussed in the = IETF.
 
Phil
 
@independentid
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;">phil.hunt@oracle.com
 
 
 
On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com> = wrote:
 
Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be = OAuth. It will break whole bunch of implicit definitions = like: 
 
authorization server
      The server issuing = access tokens to the client after successfully
      = authenticating the resource owner and obtaining = authorization.
 
After = all, OAuth is all about issuing access = tokens. 
 
Also, = I take back my statement on the grant type in my previous = mail. 
 
The = definition of grant and grant_type are = respectively: 
 
grant 
    credential representing the resource owner's = authorization
           =
grant_type
    (string representing the) type of grant sent = to the token endpoint to obtain the access = token
 
Thus, = the grant sent to the token endpoint in this case is still = 'code'. 
 
Response type on the other hand is not so well defined in = RFC6749, but it seems it is representing what is to be returned from the = authorization endpoint. To express what is to be returned from token = endpoint, perhaps defining a new parameter to the token endpoint, which = is a parallel to the response_type to the Authorization Endpoint seems = to be a more symmetric way, though I am not sure at all if that is going = to be OAuth any more. One straw-man is to define a new parameter called = response_type to the token endpoint such = as: 
 
response_type
    OPTIONAL. A string representing what is to be = returned from the token endpoint. 
    
Then define the behavior of the endpoint according = to the values as the parallel to the multi-response type = spec. 
 
Nat
    
 
 
 
2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
The draft is very clear. 

Phil


On Jul 23, 2014, at 0:46, = Nat Sakimura <sakimura@gmail.com> = wrote:

The new grant = type that I was talking about was 
"authorization_code_but_do_not_return_access_nor_refresh_token", = so to speak. 
It does not return anything per se, but an extension can define = something on top of it. 
 
Then, OIDC can define a binding to it so that the = binding only returns ID Token. 
This binding work should be done in OIDF. Should = there be such a grant = type, 
it will be an extremely short = spec. 
 
At = the same time, if any other specification wanted to = define 
other = type of tokens and have it returned from the token = endpoint, 
it = can also use this grant type. 
 
If what you want is to define a new grant type that = returns ID Token only, 
then, I am with Justin. Since "other response than = ID Token" is only 
theoretical, this is a more plausible way forward, I = suppose. 
 
Nat
 
2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:
So the draft would literally turn into:

"The a4c response = type and grant type return an id_token from the token endpoint with no = access token. All parameters and values are defined in = OIDC."

Seems like the perfect mini extension draft for OIDF to = do.

--Justin

/sent from my = phone/

On Jul 22, = 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about = just defining a new grant type in this WG?
>
>
> = 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That = would be nice. However oidc still needs the new grant type in order to = implement the same flow. 
>>
>> = Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura = <sakimura@gmail.com> = wrote:
>>
>>> +1 to = Justin. 
>>>
>>>
>>> 2014-07-22 = 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>= > Errors like these make it clear to me that it would make much more = sense to develop this document in the OpenID Foundation. It should be = something that directly references OpenID Connect Core for all of these = terms instead of redefining them. It's doing authentication, which is = fundamentally what OpenID Connect does on top of OAuth, and I don't see = a good argument for doing this work in this working = group.
>>>>
>>>>  -- = Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 = AM, Thomas Broyer <t.broyer@gmail.com> = wrote:
>>>>
>>>>>
>>>>>=
>>>>>
>>>>> On Mon, Jul 21, 2014 at = 11:52 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:
>>>>>>
>>>>>> Thanks = for your review, Thomas.  The "prompt=3Dconsent" definition being = missing is an editorial error.  It should = be:
>>>>>>
>>>>>> =  
>>>>>>
>>>>>> = consent
>>>>>>
>>>>>> The = Authorization Server SHOULD prompt the End-User for consent before = returning information to the Client. If it cannot obtain consent, it = MUST return an error, typically = consent_required.
>>>>>>
>>>>>> =  
>>>>>>
>>>>>> I'll plan = to add it in the next = draft.
>>>>>
>>>>>
>>>>= > It looks like the consent_required error needs to be defined too, = and you might have forgotten to also import account_selection_required = from OpenID Connect.
>>>>> =  
>>>>>>
>>>>>> =  
>>>>>>
>>>>>> I agree = that there's no difference between a response with multiple "amr" values = that includes "mfa" and one that doesn't.  Unless a clear use case = for why "mfa" is needed can be identified, we can delete it in the next = draft.
>>>>>
>>>>>
>>>>= > Thanks.
>>>>>
>>>>> How about = "pwd" then? I fully understand that I should return "pwd" if the user = authenticated using a password, but what "the service if a client secret = is used" means in the definition for the "pwd" = value?
>>>>>
>>>>> (Nota: I know = you're at IETF-90, I'm ready to wait 'til you come back ;-) = )
>>>>>
>>>>> = --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> = _______________________________________________
>>>>> = 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
>>>= ;>
>>>
>>>
>>>
>>> = --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, = OpenID Foundation
>>> http://nat.sakimura.org/
>>> = @_nat_en
>>>
>>> = _______________________________________________
>>> OAuth = mailing list
>>> OAuth@ietf.org
>>>https://www.ietf.org/mailman/listinfo/oauth
>
>= ;
>
>
> --
> Nat Sakimura (=3Dnat)
> = Chairman, OpenID Foundation
> http://nat.sakimura.org/
> = @_nat_en


 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
 


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

=


 
-- 
Thomas = Broyer
/t=C9=94.ma.b=CA=81wa.je/
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


 
-- 
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/


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

=


 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
 
_______________________________________________
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

=


 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


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

=


 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
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

=


 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


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


= --Apple-Mail=_D1F23F06-03A8-45F6-A8D4-03A2BF17CB33-- From nobody Thu Jul 24 11:11:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118D31B2797 for ; Thu, 24 Jul 2014 11:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 GUcO8da55voh for ; Thu, 24 Jul 2014 11:11:17 -0700 (PDT) Received: from nm34-vm3.bullet.mail.bf1.yahoo.com (nm34-vm3.bullet.mail.bf1.yahoo.com [72.30.239.75]) (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 C1B361A0386 for ; Thu, 24 Jul 2014 11:11:12 -0700 (PDT) Received: from [66.196.81.172] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2014 18:11:12 -0000 Received: from [98.139.212.214] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2014 18:11:12 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 24 Jul 2014 18:11:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 25124.62338.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 12966 invoked by uid 60001); 24 Jul 2014 18:11:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1406225471; bh=Q88c8aC8qr9GOsRnkuszN+C1NE5mUB0IsfkL6V+3yWI=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LkGUGkycc7R/CM1RmHi6pGWBo6gd0BQ+FtmTTOQ24RFTcv8aMwml+UjwBLc4RQ1rJlo5PL9SWtkClZ/siWm2OYTYOJOVNukkzZGoRFV/deogNyjXSEAmh8km4hs+0LDs45L+97UYJlBDOZwH5GcH2jxvTqGzrT535Ab8/L2Ld0g= X-YMail-OSG: B8ZnbGEVM1kQH2S8Gbg43s06smgESEyJwPJqY0ciMgL3tLZ IebD4YNnUoZsuqwpuzi0sNVJ7kqfjapKxPRwoSOIdlb402oD15HZe747BpPR stgQbnYyGyiYzfgK3Q44xfW66QuLZU51AktsGLfQXOqsgw1P7gJJpJhGr2ed vKWnybRnsg.RSXGbMxqGYAU.K2FZIx4NgO4iAhU2NeYFW9_U77vQwru8.vXV Rm.pHdxK1J5mhcLI0iirsCddo2QvEAlk33wbDFx2oZ5EdIa7C6paSWApg77x KyxiZg2h888BtdqZEb_fmk3fq5OCiIfVoEVcrjY8gPsrRBxgDUW9RDcnJ7v_ aKE96hoCoj3.MS6BdtqSHU6pzxpJYus7Z6KLk5U.yhltigAmWDEjbLPm3PBM TH9.xM4h4PSnA_dBmYz_1lDOBV0gj3_VJpi6wbG_hw44ih4DVeGq9hoJqwkd ej_qo07RjbQlyGQ.dKGh2wv80GkOAcw6WQGZZlTWXYjqChJiMu5AuV4QClX6 Unp50gBrA.dlsEhh.Ai9x2k6dGYOe8GFtIAR6M6GfDLZ2IOgiWkfZJqWhILq W1qjdILueeM2envWaW6ieBSisKGctpFgu8RHk6QbILc_AQjpBk4V0_2eyJlc pFE.gIgzfoEz7moOxfUqYgvPHLckjNOz5QsN4JQ5UJCwpcfWTMuUpbiuW6BY RHITz.5DKN2rEJQmIcA5R3kbndlYuAXxLQJQULVckeL8xfJ82zThnl6CE9Mi 1XpeWQFMkJzrh2UX8N4s.KTGqN.BMdYbjIb08zPZ7iUN_vRVpLtwFnxwtcrN GIxF33A.t3C7pDtGrgmzLuv_s.ZQohjDLExIVwByC2F1qdpcm8lMfs5pwjky .PvNEE_Nmm2y.q2VewuPc57DtHUHIn2OvcqjaqUl4RQM6hFDO Received: from [167.220.24.190] by web142803.mail.bf1.yahoo.com via HTTP; Thu, 24 Jul 2014 11:11:11 PDT X-Rocket-MIMEInfo: 002.001, VGhpcyBjb3VsZCBhbHNvIGJlIHNvbHZlZCBieSBleHBsaWNpdGx5IGRlZmluaW5nIGEgc2NvcGUgZm9yIGFjY2VzcyB0b2tlbnMgc3BlY2lmaWMgdG8gdGhlIG5lZWRlZCAobm8tb3A_KSBiZWhhdmlvciBmb3IgYWM0LgoKCk9uIFRodXJzZGF5LCBKdWx5IDI0LCAyMDE0IDg6MzQgQU0sICJ0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB3cm90ZToKIAoKCkkgaG9uZXN0ZWx5IGRvbid0IHVuZGVyc3RhbmQgd2h5IHlvdSBjYXJlIGFib3V0IG9taXRpbmcgdGhlIGFjY2UBMAEBAQE- X-Mailer: YahooMailWebService/0.8.196.685 References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADE8ED3@TK5EX14MBXC293.redmond.corp.microsoft.com> <99ba4e3014fa2b4526df2e888ab9e38d@lodderstedt.net> Message-ID: <1406225471.11804.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Thu, 24 Jul 2014 11:11:11 -0700 From: Bill Mills To: "torsten@lodderstedt.net" , Mike Jones In-Reply-To: <99ba4e3014fa2b4526df2e888ab9e38d@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="905790552-462800050-1406225471=:11804" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/R_W9zKWJh82FWOfIcjqVwW_PpUA Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:11:27 -0000 --905790552-462800050-1406225471=:11804 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This could also be solved by explicitly defining a scope for access tokens = specific to the needed (no-op?) behavior for ac4.=0A=0A=0AOn Thursday, July= 24, 2014 8:34 AM, "torsten@lodderstedt.net" wrot= e:=0A =0A=0A=0AI honestely don't understand why you care about omiting the = access token on the token endpoint response. You want to omit user consent?= Fine, do it. There is no text in the spec that forces an AS to explicitely= acquire user consent. Authorization from the resource owner can be acquire= d in many ways, showing an user consent page is just one option. We authori= ze DT internal services using a pre-configured policy. So the customer will= never (need to) see a consent screen. The same approach can be used in ent= erprise deployments.=C2=A0=0Aregards,=0ATorsten.=0AAm 24.07.2014 10:49, sch= rieb Mike Jones:=0AHere's a point of technical discussion for your consider= ation about the current content of a4c and a possible simplification.=0A>= =C2=A0=0A>Having thought about the views expressed about defining the new r= esponse type and grant type values, I came up with a possible syntax change= that would be much more minimal and accomplish the same thing.=C2=A0 Rathe= r than defining a new response type and a new grant type, instead, we could= just use the existing code flow and say that it's legal for the token endp= oint to return the value "access_token=3Dnone".=C2=A0 That way, the delta t= o OAuth 2.0 for the no-access-token case would be very small and the syntax= of the response from the token endpoint would be unchanged.=0A>=C2=A0=0A>A= nd while people might initially think that since we'd be defining a disting= uished access_token result value we might be stepping on implementations, "= none" doesn't meet the minimum entropy requirements in OAuth 2.0, so wouldn= 't conflict with any conforming implementation.=0A>=C2=A0=0A>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best wishes,=0A>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=0A>=C2=A0=0A>From:OAuth [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt=0A>Sent: Thursday, July= 24, 2014 7:34 AM=0A>To: John Bradley=0A>Cc: oauth@ietf.org list=0A>Subject= : Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-= 05.txt=0A>=C2=A0=0A>+1=0A>=C2=A0=0A>Phil=0A>=C2=A0=0A>@independentid=0A>www= .independentid.com=0A>phil.hunt@oracle.com=0A>=C2=A0=0A>=C2=A0=0A>=C2=A0=0A= >On Jul 24, 2014, at 10:25 AM, John Bradley wrote:=0A>= =0A>=0A>=0A>I am not against discussion in the WG.=0A>=C2=A0=0A>I happen to= agree with Phil's fundamental premise that some developers are using OAuth= in a insecure way to do authentication.=0A>=C2=A0=0A>That raises the quest= ion of how to best educate them, and or address technical barriers.=0A>=C2= =A0=0A>It is on the second point that people's opinions seem to divide.=0A>= =C2=A0=0A>Some people thing that if we have a OAuth flow that eliminates th= e access token (primarily to avoid asking for consent as I understand it) a= nd just return a id_token from the token endpoint that can be done in a spe= c short enough to het people to read. =C2=A0 The subtext of this is that th= e Connect specification is too large that it scare people, =C2=A0and they d= on't find the spec in the first place because it is not a RFC.=0A>=C2=A0=0A= >An other common possession is that if you don't want to prompt the user fo= r consent then don't ask for scopes. =C2=A0Twisting the OAuth spec to not r= eturn an access token is not OAuth, =C2=A0yes you could use a different end= point rather than the token endpoint, but that is not OAuth. =C2=A0 Connect= was careful not to break the OAuth spec. =C2=A0 =C2=A0As long as you are w= illing to take a access token with no scopes (the client needs to understan= d that there are no attributes one way or another anyway or it will break) = then you don't need to change OAuth. =C2=A0 You can publish a profile of co= nnect that satisfies the use case.=0A>=C2=A0=0A>I think Mike has largely do= ne that but it might be better being less stingy on references back to the = larger spec.=0A>=C2=A0=0A>The questions are do we modify OAuth to not retur= n an access token, and if so how, =C2=A0and if we do is it still OAuth.=0A>= =C2=A0=0A>The other largely separable question is do we create confusion in= the market and slow the the adoption of identity federation on top of OAut= h, or find a way to make this look like a positive alignment of interests a= round a subset of Connect.=0A>=C2=A0=0A>There are a number of options. =C2= =A0=0A>1: We can do a profile in the OIDF and publish it as a IETF document= . =C2=A0 Perhaps the cleanest from an IPR point of view.=0A>2:We can do a p= rofile in the OAuth WG referencing connect.=0A>3:We can do a AD sponsored p= rofile that is not in the OAuth WG.=0A>4:We can do a small spec in OAuth to= add response_type to the token endpoint. =C2=A0in combination with 1, 2, o= r 3=0A>=C2=A0=0A>I agree that stoping developers doing insecure things need= s to be addressed somehow. =C2=A0=0A>I am not personally convinced that Oau= th without access tokens is sensible.=0A>=C2=A0=0A>Looking forward to the m= eeting:)=0A>=C2=A0=0A>John B.=0A>On Jul 24, 2014, at 6:52 AM, Brian Campbel= l wrote:=0A>=0A>=0A>=0A>I'd note that the reac= tion at the conference to Ian's statement was overwhelmingly positive. Ther= e was a wide range of industry people here - implementers, practitioners, d= eployers, strategists, etc. - and it seems pretty clear that the "rough con= sensus" of the industry at large is that a4c is not wanted or needed.=0A>= =C2=A0=0A>On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura wrote:=0A>And here is a quote from Ian's blog.=C2=A0=0A>=C2=A0=0A>And alt= hough the authentication wheel is round, that doesn't mean it isn't without= its lumps. First, we do see some reinventing the wheel just to reinvent th= e wheel. OAuth A4C is simply not a fruitful activity and should be put down= . =C2=A0=0A>=C2=A0=0A>(Source) http://www.tuesdaynight.org/2014/07/23/do-we= -have-a-round-wheel-yet-musings-on-identity-standards-part-1.html=0A>=C2=A0= =0A>2014-07-23 16:53 GMT-04:00 John Bradley :=0A>=C2=A0= =0A>>I thought I did post this to the list.=C2=A0=0A>>=C2=A0=0A>>I guess I = hit the wrong reply on my phone.=C2=A0=0A>>=C2=A0=0A>>John B.=C2=A0=0A>>Sen= t from my iPhone=0A>>=0A>>On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.= net wrote:=0A>>we are two, at least :-)=0A>>>Why didn't you post this on th= e list?=0A>>>When will be be arriving?=0A>>>Am 23.07.2014 16:39, schrieb Jo= hn Bradley:=0A>>>Ian Glazer mentioned this in his keynote at CIS yesterday.= =C2=A0=0A>>>>=C2=A0=0A>>>>His advice was please stop, =C2=A0we are creating= confusion and uncertainty.=C2=A0=0A>>>>=C2=A0=0A>>>>We are becoming our ow= n wort enemy. ( my view though Ian may share it)=0A>>>>=C2=A0=0A>>>>Returni= ng just an id_ token from the token endpoint has little real value.=C2=A0= =0A>>>>=C2=A0=0A>>>>Something really useful to do would be sorting out chan= nel_id so we can do PoP for id tokens to make them and other cookies secure= in the front channel. =C2=A0 I think that is a better use of time.=C2=A0= =0A>>>>=C2=A0=0A>>>>I may be in the minority opinion on that, =C2=A0it won'= t be the first time. =C2=A0=0A>>>>=0A>>>>=0A>>>>John B.=C2=A0=0A>>>>Sent fr= om my iPhone=0A>>>>=0A>>>>On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt = wrote:=0A>>>>You are right from a theoretical per= spective. Practically this was caused by editorial decisions during the cre= ation of the RFC. As far as I remember, there was a definition of the (one)= token endpoint response in early versions. No one every considered to NOT = respond with an access token from the token endpoint. So one might call it = an implicit assumption.=0A>>>>>=C2=A0=0A>>>>>I'm worried that people get to= tally confused if an exception is introduced now given the broad adoption o= f OAuth based on this assumption.=0A>>>>>=C2=A0=0A>>>>>regards,=0A>>>>>Tors= ten.=0A>>>>>=0A>>>>>Am 23.07.2014 um 15:41 schrieb Thomas Broyer :=0A>>>>>Is it said anywhere that ALL grant types MUST use Sectio= n 5.1 responses? Each grant type references Section 5.1, and "access token = request" is only defined in the context of the defined grant types. Section= 2.2 doesn't talk about the request or response format.=0A>>>>>>Le 23 juil.= 2014 21:32, "Nat Sakimura" a =C3=A9crit :=0A>>>>>>Is = it? Apart from the implicit grant that does not use token endpoint, all oth= er grant references section 5.1 for the response, i.e., all shares the same= response.=C2=A0=0A>>>>>>=C2=A0=0A>>>>>>2014-07-23 15:18 GMT-04:00 Thomas B= royer :=0A>>>>>>I hadn't realized the JSON response tha= t requires the access_token field is defined per grant_type, so I'd be OK t= o "extend the semantics" as in the current draft.=0A>>>>>>That was actually= my main concern: that the token endpoint mandates access_token; but its ac= tually not the case.=0A>>>>>>Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9crit : =0A>>>>>>=C2=A0=0A>>>>>>>I agree with John tha= t overloading response_type @ authz endpoint is a bad idea. It completely c= hanges the semantics of this parameter. NOTE: what I was proposing was not = this parameter, but a new parameter response_type @ token endpoint.=C2=A0= =0A>>>>>>>=C2=A0=0A>>>>>>>I also think overloading grant_type is a bad idea= since it changes its semantics. I quote the definition here again:=C2=A0= =0A>>>>>>>=C2=A0=0A>>>>>>>grant=C2=A0=0A>>>>>>>=C2=A0 =C2=A0 credential rep= resenting the resource owner's authorization=0A>>>>>>>=C2=A0=0A>>>>>>>grant= _type=0A>>>>>>>type of grant sent to the token endpoint to obtain the acces= s token=0A>>>>>>>=C2=A0=0A>>>>>>>It is not about controlling what is to be = returned from the token endpoint, but the hint to the token endpoint descri= bing the type of credential the endpoint has received. It seems the "contro= l of what is being returned from token endpoint" =C2=A0is just a side effec= t.=C2=A0=0A>>>>>>>=C2=A0=0A>>>>>>>I am somewhat ambivalent[1] in changing t= he semantics of token endpoint, but in as much as "text is the king" for a = spec., we probably should not change the semantics of it as Torsten points = out. If it is ok to change this semantics, I believe defining a new paramet= er to this endpoint to control the response would be the best way to go. Th= is is what I have described previously.=C2=A0=0A>>>>>>>=C2=A0=0A>>>>>>>Defi= ning a new endpoint to send code to get ID Token and forbidding the use of = it against token endpoint would not change the semantics of any existing pa= rameter or endpoint, which is good. However, I doubt if it is not worth doi= ng. What's the point of avoiding access token scoped to UserInfo endpoint a= fter all? Defining a new endpoint for just avoiding the access token for us= erinfo endpoint seems way too much the heavy wait way and it breaks interop= erabiliy: it defeats the purpose of standardization.=C2=A0=0A>>>>>>>=C2=A0= =0A>>>>>>>I have started feeling that no change is the best way out.=C2=A0= =0A>>>>>>>=C2=A0=0A>>>>>>>Nat=0A>>>>>>>=C2=A0=0A>>>>>>>[1] =C2=A0If instead= of saying "Token endpoint - used by the client to exchange an authorizatio= n=C2=A0grant for an access token, typically with client authentication", it= were saying "Token endpoint - used by the client to exchange an authorizat= ion=C2=A0grant for tokens, typically with client authentication", then it w= ould have been OK. It is an expansion of the capability rather than changin= g the semantics.=0A>>>>>>>=C2=A0=0A>>>>>>>=C2=A0=0A>>>>>>>2014-07-23 13:39 = GMT-04:00 Mike Jones :=0A>>>>>>>You need the a= lternative response_type value ("code_for_id_token" in the A4C draft) to te= ll the Authorization Server to return a code to be used with the new grant = type, rather than one to use with the "authorization_code" grant type (whic= h is what response_type=3Dcode does).=0A>>>>>>>=C2=A0=0A>>>>>>>From:OAuth [= mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley=0A>>>>>>>Sent: Wed= nesday, July 23, 2014 10:33 AM=0A>>>>>>>To: torsten@lodderstedt.net=0A>>>>>= >>=0A>>>>>>>Cc: oauth@ietf.org=0A>>>>>>>Subject: Re: [OAUTH-WG] New Version= Notification for draft-hunt-oauth-v2-user-a4c-05.txt=0A>>>>>>>=C2=A0=0A>>>= >>>>=C2=A0=0A>>>>>>>If we use the token endpoint then a new grant_type is t= he best way.=C2=A0=0A>>>>>>>=C2=A0=0A>>>>>>>It sort of overloads code, but = that is better than messing with response_type for the authorization endpoi= nt to change the response from the token_endpoint. =C2=A0That is in my opin= ion a champion bad idea.=C2=A0=0A>>>>>>>=C2=A0=0A>>>>>>>In discussions deve= loping Connect we decided not to open this can of worms because no good wou= ld come of it. =C2=A0=C2=A0=0A>>>>>>>=C2=A0=0A>>>>>>>The token_endpoint ret= urns a access token. =C2=A0Nothing requires scope to be associates with the= token.=C2=A0=0A>>>>>>>=C2=A0=0A>>>>>>>That is the best solution. =C2=A0No = change required. =C2=A0Better interoperability in my opinion.=C2=A0=0A>>>>>= >>=C2=A0=0A>>>>>>>Still on my way to TO, getting in later today.=C2=A0=0A>>= >>>>>=C2=A0=0A>>>>>>>John B.=C2=A0=0A>>>>>>>=C2=A0=0A>>>>>>>=0A>>>>>>>=0A>>= >>>>>Sent from my iPhone=0A>>>>>>>=0A>>>>>>>On Jul 23, 2014, at 12:15 PM, t= orsten@lodderstedt.net wrote:=0A>>>>>>>The "response type" of the token end= point is controlled by the value of the parameter "grant_type". So there is= no need to introduce a new parameter.=0A>>>>>>>>wrt to a potential "no_acc= ess_token" grant type. I do not consider this a good idea as it changes the= semantics of the token endpoint (as already pointed out by Thomas). This e= ndpoint ALWAYS responds with an access token to any grant type. I therefore= would prefer to use another endpoint for the intended purpose.=0A>>>>>>>>r= egards,=0A>>>>>>>>Torsten.=0A>>>>>>>>=C2=A0=0A>>>>>>>>Am 23.07.2014 13:04, = schrieb Nat Sakimura:=0A>>>>>>>>IMHO, changing the semantics of "response_t= ype" @ authz endpoint this way is not a good thing.=C2=A0=0A>>>>>>>>>=C2=A0= =0A>>>>>>>>>Instead, defining a new parameter "response_type" @ token endpo= int, as I described in my previous message,=C2=A0 =0A>>>>>>>>>probably is b= etter. At least, it does not change the semantics of the parameters of RFC6= 749.=C2=A0=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>=C2=A0Nat=C2=A0=0A>>>>>>>>>=C2=A0= =0A>>>>>>>>>2014-07-23 12:48 GMT-04:00 Thomas Broyer := =0A>>>>>>>>>No, I mean response_type=3Dnone and response_type=3Did_token do= n't generate a code or access token so you don't use the Token Endpoint (wh= ich is not the same as the Authentication Endpoint BTW). =0A>>>>>>>>>With r= esponse_type=3Dcode_for_id_token, you get a code and exchange it for an id_= token only, rather than an access_token, so you're changing the semantics o= f the Token Endpoint.=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>I'm not saying it's a ba= d thing, just that you can't really compare none and id_token with code_for= _id_token.=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>On Wed, Jul 23, 2014 at 6:45 PM, Ri= cher, Justin P. wrote:=0A>>>>>>>>>It's only "not using = the token endpoint" because the token endpoint copy-pasted and renamed the = authentication endpoint. =0A>>>>>>>>>=C2=A0=0A>>>>>>>>>=C2=A0-- Justin=0A>>= >>>>>>>=C2=A0=0A>>>>>>>>>On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote:=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>Except that these are abo= ut not using the Token Endpoint at all, whereas the current proposal is abo= ut the Token Endpoint not returning an access_token field in the JSON.=0A>>= >>>>>>>=C2=A0=0A>>>>>>>>>On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones wrote:=0A>>>>>>>>>The response_type "none" is alrea= dy used in practice, which returns no access token.=C2=A0 It was accepted b= y the designated experts and registered in the IANA OAuth Authorization End= point Response Types registry at http://www.iana.org/assignments/oauth-para= meters/oauth-parameters.xml#endpoint.=C2=A0 The registered "id_token" respo= nse type also returns no access token.=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>So I th= ink the question of whether response types that result in no access token b= eing returned are acceptable within OAuth 2.0 is already settled, as a prac= tical matter.=C2=A0 Lots of OAuth implementations are already using such re= sponse types.=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>From:OAuth [m= ailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt=0A>>>>>>>>>Sent: Wedne= sday, July 23, 2014 7:09 AM=0A>>>>>>>>>To: Nat Sakimura=0A>>>>>>>>>Cc: =0A>>>>>>>>>Subject: Re: [OAUTH-WG] New Version Notification fo= r draft-hunt-oauth-v2-user-a4c-05.txt=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>Yes. Thi= s is why it has to be discussed in the IETF.=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>P= hil=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>@independentid=0A>>>>>>>>>www.independenti= d.com=0A>>>>>>>>>phil.hunt@oracle.com=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>=C2=A0= =0A>>>>>>>>>=C2=A0=0A>>>>>>>>>On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote:=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>Reading back the RFC6= 749, I am not sure if there is a good way of suppressing access token from = the response and still be OAuth. It will break whole bunch of implicit defi= nitions like:=C2=A0=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>authorization server=0A>>>= >>>>>>=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client a= fter successfully=0A>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 authenticating the resour= ce owner and obtaining authorization.=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>After al= l, OAuth is all about issuing access tokens.=C2=A0=0A>>>>>>>>>=C2=A0=0A>>>>= >>>>>Also, I take back my statement on the grant type in my previous mail.= =C2=A0=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>The definition of grant and grant_type = are respectively:=C2=A0=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>grant=C2=A0=0A>>>>>>>>= >=C2=A0 =C2=A0 credential representing the resource owner's authorization= =0A>>>>>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =0A>>>>>>>>>grant_type=0A>>>>>>>>>=C2=A0=C2=A0=C2=A0 (string representi= ng the) type of grant sent to the token endpoint to obtain the access token= =0A>>>>>>>>>=C2=A0=0A>>>>>>>>>Thus, the grant sent to the token endpoint in= this case is still 'code'.=C2=A0=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>Response typ= e on the other hand is not so well defined in RFC6749, but it seems it is r= epresenting what is to be returned from the authorization endpoint. To expr= ess what is to be returned from token endpoint, perhaps defining a new para= meter to the token endpoint, which is a parallel to the response_type to th= e Authorization Endpoint seems to be a more symmetric way, though I am not = sure at all if that is going to be OAuth any more. One straw-man is to defi= ne a new parameter called response_type to the token endpoint such as:=C2= =A0=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>response_type=0A>>>>>>>>>=C2=A0 =C2=A0 OPT= IONAL. A string representing what is to be returned from the token endpoint= .=C2=A0=0A>>>>>>>>>=C2=A0 =C2=A0=C2=A0=0A>>>>>>>>>Then define the behavior = of the endpoint according to the values as the parallel to the multi-respon= se type spec.=C2=A0=0A>>>>>>>>>http://openid.net/specs/oauth-v2-multiple-re= sponse-types-1_0.html=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>Nat=0A>>>>>>>>>=C2=A0 = =C2=A0=C2=A0=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>=C2=A0=0A>>>>>>= >>>2014-07-23 7:21 GMT-04:00 Phil Hunt :=0A>>>>>>>>>T= he draft is very clear.=C2=A0=0A>>>>>>>>>=0A>>>>>>>>>Phil=0A>>>>>>>>>=0A>>>= >>>>>>On Jul 23, 2014, at 0:46, Nat Sakimura wrote:=0A= >>>>>>>>>The new grant type that I was talking about was=C2=A0=0A>>>>>>>>>>= "authorization_code_but_do_not_return_access_nor_refresh_token", so to spea= k.=C2=A0=0A>>>>>>>>>>It does not return anything per se, but an extension c= an define something on top of it.=C2=A0=0A>>>>>>>>>>=C2=A0=0A>>>>>>>>>>Then= , OIDC can define a binding to it so that the binding only returns ID Token= .=C2=A0=0A>>>>>>>>>>This binding work should be done in OIDF. Should there = be such a grant type,=C2=A0=0A>>>>>>>>>>it will be an extremely short spec.= =C2=A0=0A>>>>>>>>>>=C2=A0=0A>>>>>>>>>>At the same time, if any other specif= ication wanted to define=C2=A0=0A>>>>>>>>>>other type of tokens and have it= returned from the token endpoint,=C2=A0=0A>>>>>>>>>>it can also use this g= rant type.=C2=A0=0A>>>>>>>>>>=C2=A0=0A>>>>>>>>>>If what you want is to defi= ne a new grant type that returns ID Token only,=C2=A0=0A>>>>>>>>>>then, I a= m with Justin. Since "other response than ID Token" is only=C2=A0=0A>>>>>>>= >>>theoretical, this is a more plausible way forward, I suppose.=C2=A0=0A>>= >>>>>>>>=C2=A0=0A>>>>>>>>>>Nat=0A>>>>>>>>>>=C2=A0=0A>>>>>>>>>>2014-07-22 14= :30 GMT-04:00 Justin Richer :=0A>>>>>>>>>>So the draft wou= ld literally turn into:=0A>>>>>>>>>>=0A>>>>>>>>>>"The a4c response type and= grant type return an id_token from the token endpoint with no access token= . All parameters and values are defined in OIDC."=0A>>>>>>>>>>=0A>>>>>>>>>>= Seems like the perfect mini extension draft for OIDF to do.=0A>>>>>>>>>>=0A= >>>>>>>>>>--Justin=0A>>>>>>>>>>=0A>>>>>>>>>>/sent from my phone/=0A>>>>>>>>= >>=0A>>>>>>>>>>On Jul 22, 2014 10:29 AM, Nat Sakimura = wrote:=0A>>>>>>>>>>>=0A>>>>>>>>>>> What about just defining a new grant typ= e in this WG?=0A>>>>>>>>>>>=0A>>>>>>>>>>>=0A>>>>>>>>>>> 2014-07-22 12:56 GM= T-04:00 Phil Hunt :=0A>>>>>>>>>>>>=0A>>>>>>>>>>>> Tha= t would be nice. However oidc still needs the new grant type in order to im= plement the same flow.=C2=A0=0A>>>>>>>>>>>>=0A>>>>>>>>>>>> Phil=0A>>>>>>>>>= >>>=0A>>>>>>>>>>>> On Jul 22, 2014, at 11:35, Nat Sakimura wrote:=0A>>>>>>>>>>>>=0A>>>>>>>>>>>>> +1 to Justin.=C2=A0=0A>>>>>>>>>>= >>>=0A>>>>>>>>>>>>>=0A>>>>>>>>>>>>> 2014-07-22 9:54 GMT-04:00 Richer, Justi= n P. :=0A>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>> Errors like the= se make it clear to me that it would make much more sense to develop this d= ocument in the OpenID Foundation. It should be something that directly refe= rences OpenID Connect Core for all of these terms instead of redefining the= m. It's doing authentication, which is fundamentally what OpenID Connect do= es on top of OAuth, and I don't see a good argument for doing this work in = this working group.=0A>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>> =C2=A0-- Justin=0A>>>= >>>>>>>>>>>=0A>>>>>>>>>>>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer wrote:=0A>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>= >>=0A>>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mi= ke Jones wrote:=0A>>>>>>>>>>>>>>>>=0A>>>>>>>>= >>>>>>>> Thanks for your review, Thomas.=C2=A0 The "prompt=3Dconsent" defin= ition being missing is an editorial error.=C2=A0 It should be:=0A>>>>>>>>>>= >>>>>>=0A>>>>>>>>>>>>>>>> =C2=A0=0A>>>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>>>> cons= ent=0A>>>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>>>> The Authorization Server SHOULD p= rompt the End-User for consent before returning information to the Client. = If it cannot obtain consent, it MUST return an error, typically consent_req= uired.=0A>>>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>>>> =C2=A0=0A>>>>>>>>>>>>>>>>=0A>>= >>>>>>>>>>>>>> I'll plan to add it in the next draft.=0A>>>>>>>>>>>>>>>=0A>= >>>>>>>>>>>>>>=0A>>>>>>>>>>>>>>> It looks like the consent_required error n= eeds to be defined too, and you might have forgotten to also import account= _selection_required from OpenID Connect.=0A>>>>>>>>>>>>>>> =C2=A0=0A>>>>>>>= >>>>>>>>>=0A>>>>>>>>>>>>>>>> =C2=A0=0A>>>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>>>> I= agree that there's no difference between a response with multiple "amr" va= lues that includes "mfa" and one that doesn't.=C2=A0 Unless a clear use cas= e for why "mfa" is needed can be identified, we can delete it in the next d= raft.=0A>>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>>> Thanks.=0A>>>>>= >>>>>>>>>>=0A>>>>>>>>>>>>>>> How about "pwd" then? I fully understand that = I should return "pwd" if the user authenticated using a password, but what = "the service if a client secret is used" means in the definition for the "p= wd" value?=0A>>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>>> (Nota: I know you're at IETF= -90, I'm ready to wait 'til you come back ;-) )=0A>>>>>>>>>>>>>>>=0A>>>>>>>= >>>>>>>> --=0A>>>>>>>>>>>>>>> Thomas Broyer=0A>>>>>>>>>>>>>>> /t=C9=94.ma.b= =CA=81wa.je/=0A>>>>>>>>>>>>>>> ____________________________________________= ___=0A>>>>>>>>>>>>>>> OAuth mailing list=0A>>>>>>>>>>>>>>> OAuth@ietf.org= =0A>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth=0A>>>>>>>>>>= >>>>=0A>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>> ___________________= ____________________________=0A>>>>>>>>>>>>>> OAuth mailing list=0A>>>>>>>>= >>>>>> OAuth@ietf.org=0A>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinf= o/oauth=0A>>>>>>>>>>>>>>=0A>>>>>>>>>>>>>=0A>>>>>>>>>>>>>=0A>>>>>>>>>>>>>=0A= >>>>>>>>>>>>> --=0A>>>>>>>>>>>>> Nat Sakimura (=3Dnat)=0A>>>>>>>>>>>>> Chai= rman, OpenID Foundation=0A>>>>>>>>>>>>> http://nat.sakimura.org/=0A>>>>>>>>= >>>>> @_nat_en=0A>>>>>>>>>>>>>=0A>>>>>>>>>>>>> ____________________________= ___________________=0A>>>>>>>>>>>>> OAuth mailing list=0A>>>>>>>>>>>>> OAut= h@ietf.org=0A>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth=0A>>= >>>>>>>>>=0A>>>>>>>>>>>=0A>>>>>>>>>>>=0A>>>>>>>>>>>=0A>>>>>>>>>>> --=0A>>>>= >>>>>>> Nat Sakimura (=3Dnat)=0A>>>>>>>>>>> Chairman, OpenID Foundation=0A>= >>>>>>>>>> http://nat.sakimura.org/=0A>>>>>>>>>>> @_nat_en=0A>>>>>>>>>>=0A>= >>>>>>>>>=0A>>>>>>>>>>=0A>>>>>>>>>>=C2=A0=0A>>>>>>>>>>-- =0A>>>>>>>>>>Nat S= akimura (=3Dnat)=0A>>>>>>>>>>Chairman, OpenID Foundation=0A>>>>>>>>>>http:/= /nat.sakimura.org/=0A>>>>>>>>>>@_nat_en=0A>>>>>>>>>=0A>>>>>>>>>=0A>>>>>>>>>= =0A>>>>>>>>>=C2=A0=0A>>>>>>>>>-- =0A>>>>>>>>>Nat Sakimura (=3Dnat)=0A>>>>>>= >>>Chairman, OpenID Foundation=0A>>>>>>>>>http://nat.sakimura.org/=0A>>>>>>= >>>@_nat_en=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>=0A>>>>>>>>>______________________= _________________________=0A>>>>>>>>>OAuth mailing list=0A>>>>>>>>>OAuth@ie= tf.org=0A>>>>>>>>>https://www.ietf.org/mailman/listinfo/oauth=0A>>>>>>>>>= =0A>>>>>>>>>=0A>>>>>>>>>=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>-- =0A>>>>>>>>>Thomas= Broyer=0A>>>>>>>>>/t=C9=94.ma.b=CA=81wa.je/=0A>>>>>>>>>___________________= ____________________________=0A>>>>>>>>>OAuth mailing list=0A>>>>>>>>>OAuth= @ietf.org=0A>>>>>>>>>https://www.ietf.org/mailman/listinfo/oauth=0A>>>>>>>>= >=0A>>>>>>>>>=0A>>>>>>>>>=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>-- =0A>>>>>>>>>Thoma= s Broyer=0A>>>>>>>>>/t=C9=94.ma.b=CA=81wa.je/ =0A>>>>>>>>>=0A>>>>>>>>>____= ___________________________________________=0A>>>>>>>>>OAuth mailing list= =0A>>>>>>>>>OAuth@ietf.org=0A>>>>>>>>>https://www.ietf.org/mailman/listinfo= /oauth=0A>>>>>>>>>=0A>>>>>>>>>=0A>>>>>>>>>=0A>>>>>>>>>=C2=A0=0A>>>>>>>>>-- = =0A>>>>>>>>>Nat Sakimura (=3Dnat) =0A>>>>>>>>>Chairman, OpenID Foundation= =0A>>>>>>>>>http://nat.sakimura.org/=0A>>>>>>>>>@_nat_en=0A>>>>>>>>>=C2=A0= =0A>>>>>>>>>_______________________________________________=0A>>>>>>>>>OAut= h mailing list=0A>>>>>>>>>OAuth@ietf.org=0A>>>>>>>>>https://www.ietf.org/ma= ilman/listinfo/oauth=0A>>>>>>>>=C2=A0=0A>>>>>>>>=C2=A0=0A>>>>>>>___________= ____________________________________=0A>>>>>>>>OAuth mailing list=0A>>>>>>>= >OAuth@ietf.org=0A>>>>>>>>https://www.ietf.org/mailman/listinfo/oauth=0A>>>= >>>>=0A>>>>>>>_______________________________________________=0A>>>>>>>OAut= h mailing list=0A>>>>>>>OAuth@ietf.org=0A>>>>>>>https://www.ietf.org/mailma= n/listinfo/oauth=0A>>>>>>>=0A>>>>>>>=0A>>>>>>>=0A>>>>>>>=C2=A0=0A>>>>>>>-- = =0A>>>>>>>Nat Sakimura (=3Dnat) =0A>>>>>>>Chairman, OpenID Foundation=0A>>>= >>>>http://nat.sakimura.org/=0A>>>>>>>@_nat_en=0A>>>>>>>=0A>>>>>>>_________= ______________________________________=0A>>>>>>>OAuth mailing list=0A>>>>>>= >OAuth@ietf.org=0A>>>>>>>https://www.ietf.org/mailman/listinfo/oauth=0A>>>>= >>=0A>>>>>>=0A>>>>>>=0A>>>>>>=C2=A0=0A>>>>>>-- =0A>>>>>>Nat Sakimura (=3Dna= t) =0A>>>>>>Chairman, OpenID Foundation=0A>>>>>>http://nat.sakimura.org/=0A= >>>>>>@_nat_en=0A>>>>>_______________________________________________=0A>>>= >>>OAuth mailing list=0A>>>>>>OAuth@ietf.org=0A>>>>>>https://www.ietf.org/m= ailman/listinfo/oauth=0A>>>>_______________________________________________= =0A>>>>>OAuth mailing list=0A>>>>>OAuth@ietf.org=0A>>>>>https://www.ietf.or= g/mailman/listinfo/oauth=0A>>>=C2=A0=0A>>>=C2=A0=0A>>=0A>>_________________= ______________________________=0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A= >>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A>=0A>=C2=A0=0A>-- = =0A>Nat Sakimura (=3Dnat)=0A>Chairman, OpenID Foundation=0A>http://nat.saki= mura.org/=0A>@_nat_en=0A>=0A>______________________________________________= _=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/l= istinfo/oauth=0A>=C2=A0=0A>=C2=A0=0A>______________________________________= _________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/m= ailman/listinfo/oauth=0A>=C2=A0=0A>=0A>____________________________________= ___________=0AOAuth mailing list OAuth@ietf.org https://www.ietf.org/mailma= n/listinfo/oauth =0A=C2=A0=0A=C2=A0=0A_____________________________________= __________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mai= lman/listinfo/oauth --905790552-462800050-1406225471=:11804 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This could also be solved by explicitly defining a scope= for access tokens specific to the needed (no-op?) behavior for ac4.
=


<= div style=3D"font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial= , 'Lucida Grande', sans-serif; font-size: 12pt;">
On Thursday, July 24, 2014 8:34 AM, "torsten@lodd= erstedt.net" <torsten@lodderstedt.net> wrote:

=0A
=0A<= div>I honestely don't understand why you care about omiting the access toke= n on the token endpoint response. You want to omit user consent? Fine, do i= t. There is no text in the spec that forces an AS to explicitely acquire us= er consent. Authorization from the resource owner can be acquired in many w= ays, showing an user consent page is just one option. We authorize DT inter= nal services using a pre-configured policy. So the customer will never (nee= d to) see a consent screen. The same approach can be used in enterprise dep= loyments. 
=0A
regards,
Torsten.
=0A
Am 24.07.201= 4 10:49, schrieb Mike Jones:
=0A
=0A
=0A
= Here's a point of technical discussion for your consideration about the cur= rent content of a4c and a possible simplification.
=0A
 
=0A
Having thought about the views expressed about defining the new respo= nse type and grant type values, I came up with a possible syntax change tha= t would be much more minimal and accomplish the same thing.  Rather th= an defining a new response type and a new grant type, instead, we could jus= t use the existing code flow and say that it's legal for the token endpoint= to return the value "access_token=3Dnone".  That way, the delta to OA= uth 2.0 for the no-access-token case would be very small and the syntax of = the response from the token endpoint would be unchanged.
=0A
 
=0A
And while people might initially think tha= t since we'd be defining a distinguished access_token result value we might= be stepping on implementations, "none" doesn't meet the minimum entropy re= quirements in OAuth 2.0, so wouldn't conflict with any conforming implement= ation.
=0A
 
=0A      &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   Best wishes,
=0A
            = ;            &n= bsp;            = ;            &n= bsp;          -- Mike
=0A=
 
= =0A
=0A
=0A
From: OAuth [mailto:oauth-bounces@ietf.org] O= n Behalf Of Phil Hunt
Sent: Thursday, July 24, 2014 7:34 AMTo: John Bradley
Cc: oauth@ietf.org list
Subject:<= /b> Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4= c-05.txt
=0A
=0A
=0A
 
=0A
+1
=0A
= =0A
 
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
Phil
=0A
=0A
=0A
 
=0A
=0A
= =0A
@independentid
= =0A
=0A=0A
=0A
phil.hunt@oracle.com
=0A
=0A
=0A
 
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
 
=0A
=0A
=0A
On Jul 24, 2014, at 10:25 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
=0A
=0A


=0A
=0A
I am not against discussion in the WG.
=0A
=0A 
=0A
=0A
=0A
I happen to agree with Phil's fundamental pre= mise that some developers are using OAuth in a insecure way to do authentic= ation.
=0A
=0A
=0A
 = ;
=0A
=0A
=0A
That raise= s the question of how to best educate them, and or address technical barrie= rs.
=0A
=0A
=0A
 =0A
=0A
=0A
It is on the = second point that people's opinions seem to divide.
=0A
=0A
= =0A
 
=0A
=0A
=0ASome people thing that if we have a OAu= th flow that eliminates the access token (primarily to avoid asking for con= sent as I understand it) and just return a id_token from the token endpoint= that can be done in a spec short enough to het people to read.   The = subtext of this is that the Connect specification is too large that it scar= e people,  and they don't find the spec in the first place because it = is not a RFC.
=0A
=0A
=0A
 
=0A
=0A
=0A
An = other common possession is that if you don't want to prompt the user for co= nsent then don't ask for scopes.  Twisting the OAuth spec to not retur= n an access token is not OAuth,  yes you could use a different endpoin= t rather than the token endpoint, but that is not OAuth.   Connect was= careful not to break the OAuth spec.    As long as you are willi= ng to take a access token with no scopes (the client needs to understand th= at there are no attributes one way or another anyway or it will break) then= you don't need to change OAuth.   You can publish a profile of connec= t that satisfies the use case.
=0A
=0A
=0A
 
=0A
=0A
=0A
I think Mike has largely done that but it might be better bei= ng less stingy on references back to the larger spec.
=0A
=0A=0A
 
=0A
=0A
=0A<= div class=3D"yiv7015674266MsoNormal">The questions are do we modify OAuth t= o not return an access token, and if so how,  and if we do is it still= OAuth.
=0A
=0A
=0A
&nbs= p;
=0A
=0A
=0A
The other= largely separable question is do we create confusion in the market and slo= w the the adoption of identity federation on top of OAuth, or find a way to= make this look like a positive alignment of interests around a subset of C= onnect.
=0A
=0A
=0A
&nbs= p;
=0A
=0A
=0A
There are= a number of options.  
=0A
=0A
=0A
1: We can do a profile in the OIDF and publish it as a IET= F document.   Perhaps the cleanest from an IPR point of view.
=0A=
=0A
=0A
2:We can do a profil= e in the OAuth WG referencing connect.
=0A
=0A
=0A
3:We can do a AD sponsored profile that is not = in the OAuth WG.
=0A
=0A
=0A
4:We can do a small spec in OAuth to add response_type to the token en= dpoint.  in combination with 1, 2, or 3
=0A
=0A
=0A
 
=0A
=0A
=0A
I agree that stoping developers doing insecure = things needs to be addressed somehow.  
=0A
=0A
=0A
I am not personally convinced that Oauth w= ithout access tokens is sensible.
=0A
=0A
=0A
 
=0A
=0A
=0A
Looking forward to the meeting:)
=0A
=0A
=0A=
 
=0A
=0A
=0A
John B.
=0A
=0A
=0A
=0AOn Jul 24, 2014, at 6:52 AM, Brian Camp= bell <bcampbell@ping= identity.com> wrote:
=0A
=0A


=0A
=0A
I'd = note that the reaction at the conference to Ian's statement was overwhelmin= gly positive. There was a wide range of industry people here - implementers= , practitioners, deployers, strategists, etc. - and it seems pretty clear t= hat the "rough consensus" of the industry at large is that a4c is not wante= d or needed.
=0A
=0A
=0A
 
=0A
=0A
On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
=0A=0A
And here is a quote from Ian's = blog. 
=0A
=0A
 =0A
=0A
=0AAnd although the authentication wheel is = round, that doesn't mean it isn't without its lumps. First, we do see some = reinventing the wheel just to reinvent the wheel. OAuth A4C is simply not a= fruitful activity and should be put down.  
=0A=0A<= div>=0A
 
=0A
=0A=0A
(Source) http://www.tuesdaynight.org/2014/07/23/do-we-= have-a-round-wheel-yet-musings-on-identity-standards-part-1.html
= =0A=0A
=0A
=0A
 
=0A
=0A
2014-07-23 16:53 GMT-04:00 John Bradley <ve7jtb@ve7jtb.com>:
=0A
=0A
=0A=0A
 
=0A
=0A
=0A
I thought I did post this to the list. 
=0A
=0A=0A
 
=0A
=0A
=0A<= div class=3D"yiv7015674266MsoNormal">I guess I hit the wrong reply on my ph= one. 
 
=0A
=0A
=0A
John B. 
Sent from my iPhone
=0A
=0A
=0A
On= Jul 23, 2014, at 4:50 PM, t= orsten@lodderstedt.net wrote:
=0A
=0A
=0A
we are two, at least :-)
= =0A
Why didn't you post this on the list?
=0A
When will be be = arriving?
=0A
Am 23.07.2014 16:39, schrieb John Bradley:
=0A<= blockquote style=3D"border:none;border-left:solid #1010FF 1.5pt;padding:0in= 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt;">= =0A
=0A
Ian Glazer mentioned this = in his keynote at CIS yesterday. 
=0A
=0A
=0A
 
=0A
=0A
=0A
His advice was please stop,  we are creating co= nfusion and uncertainty. 
=0A
=0A
=0A
 
=0A
=0A
=0A
We are becoming our own wort enemy. ( my view though Ian may = share it)
=0A
=0A
=0A
&n= bsp;
=0A
=0A
=0A
Returni= ng just an id_ token from the token endpoint has little real value. =0A
=0A
=0A
 
= =0A
=0A
=0A
Something really = useful to do would be sorting out channel_id so we can do PoP for id tokens= to make them and other cookies secure in the front channel.   I think= that is a better use of time. 
=0A
=0A
=0A
 
=0A
=0A
=0A
I may be in the minority opinion on that,  it won'= t be the first time.  
=0A
=0A


John B. 
Sent from my iPhone
=0A
=0A=0A
=0A
=0A

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <<= a rel=3D"nofollow" ymailto=3D"mailto:torsten@lodderstedt.net" target=3D"_bl= ank" href=3D"mailto:torsten@lodderstedt.net">torsten@lodderstedt.net>= ; wrote:
=0A
=0A
=0A
=0A
=0A
You are right from a theoretical perspective. Practically this was c= aused by editorial decisions during the creation of the RFC. As far as I re= member, there was a definition of the (one) token endpoint response in earl= y versions. No one every considered to NOT respond with an access token fro= m the token endpoint. So one might call it an implicit assumption.
=0A=
=0A
=0A
 
=0A=0A
=0A
I'm worried that people g= et totally confused if an exception is introduced now given the broad adopt= ion of OAuth based on this assumption.
=0A
=0A
=0A
 
=0A
=0A
=0A
regards,
=0A
=0A
=0A
Torsten.
=0A
=0A
=0A

Am 23.07.2014 um 15:4= 1 schrieb Thomas Broyer <t.broyer@gm= ail.com>:
=0A
=0A
=0A
=0A
Is it said anywhere that A= LL grant types MUST use Section 5.1 responses? Each grant type references S= ection 5.1, and "access token request" is only defined in the context of th= e defined grant types. Section 2.2 doesn't talk about the request or respon= se format.
=0A
=0A
Le 23 juil= . 2014 21:32, "Nat Sakimura" <sakimu= ra@gmail.com> a =C3=A9crit :
=0A
=0A
Is it? Apart from the implicit grant that does not use token= endpoint, all other grant references section 5.1 for the response, i.e., a= ll shares the same response. 
=0A
=0A
=0A
 
=0A
= =0A
2014-07-23 15:18 GMT-04:00 Thomas = Broyer <t.broyer@gmail.com>:<= /div>=0A
I hadn't realized the JSON response that requires the access_t= oken field is defined per grant_type, so I'd be OK to "extend the semantics= " as in the current draft.
That was actually my main concern: that the = token endpoint mandates access_token; but its actually not the case.
= =0A
=0A
Le 23 juil. 2014 20:46, "N= at Sakimura" <sakimura@gmail.com= > a =C3=A9crit :
=0A
=0A
=0A
=0A
 =0A
=0A
=0A
I agree with John= that overloading response_type @ authz endpoint is a bad idea. It complete= ly changes the semantics of this parameter. NOTE: what I was proposing was = not this parameter, but a new parameter response_type @ token endpoint.&nbs= p;
=0A
=0A
=0A
 =0A
=0A
=0A
I also think o= verloading grant_type is a bad idea since it changes its semantics. I quote= the definition here again: 
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
grant 
=0A
=0A
=0A
    credential representing the resource= owner's authorization
=0A
=0A
=0A
 
=0A
=0A
=0A
grant_type
=0A
=0A
=0A
type of grant sent to the token endpoint to obtain the access token=0A
=0A
=0A
=0A
 = ;
=0A
=0A
=0A
It is not = about controlling what is to be returned from the token endpoint, but the h= int to the token endpoint describing the type of credential the endpoint ha= s received. It seems the "control of what is being returned from token endp= oint"  is just a side effect. 
=0A
=0A
=0A
 
=0A
=0A
=0A
I am somewhat ambivalent[1] in changing the semanti= cs of token endpoint, but in as much as "text is the king" for a spec., we = probably should not change the semantics of it as Torsten points out. If it= is ok to change this semantics, I believe defining a new parameter to this= endpoint to control the response would be the best way to go. This is what= I have described previously. 
=0A
=0A
=0A
 
=0A
=0A
=0A
Defining a new endpoint to send code to get ID Token and= forbidding the use of it against token endpoint would not change the seman= tics of any existing parameter or endpoint, which is good. However, I doubt= if it is not worth doing. What's the point of avoiding access token scoped= to UserInfo endpoint after all? Defining a new endpoint for just avoiding = the access token for userinfo endpoint seems way too much the heavy wait wa= y and it breaks interoperabiliy: it defeats the purpose of standardization.=  
=0A
=0A
=0A
 = ;
=0A
=0A
=0A
I have sta= rted feeling that no change is the best way out. 
=0A
=0A=0A
 
=0A
=0A
=0A=
Nat
=0A
=0A
=0A
 
=0A
=0A
=0A
[1]  If instead of saying "Token endpoint - u= sed by the client to exchange an authorization grant for an access tok= en, typically with client authentication", it were saying "Token endpoint -= used by the client to exchange an authorization grant for tokens, typ= ically with client authentication", then it would have been OK. It is an ex= pansion of the capability rather than changing the semantics.
=0A=0A
=0A
 
=0A
=0A<= /div>=0A
=0A
 
=0A
=0A
201= 4-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@microsoft.com>:
=0A
=0A=0A
You n= eed the alternative response_type value ("code_for_id_token" in the A4C draft) to tell the Authorization Server to return a co= de to be used with the new grant type, rather than one to use with the "aut= horization_code" grant type (which is what response_type=3Dcode does).
=0A
=0A
&= nbsp;
=0A
=0A
=0A
=0A
From:= OAut= h [mailto:oauth-bounces@ietf.or= g] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: = torsten@lodderstedt.net
=0A
=0A
=0A

Cc: oauth@iet= f.org
Subject: Re: [OAUTH-WG] New Version Notification for dr= aft-hunt-oauth-v2-user-a4c-05.txt
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A=0A
=0A
=0A
 
=0A=
=0A
=0A
If we use= the token endpoint then a new grant_type is the best way. 
=0A=0A
=0A
=0A
 
= =0A
=0A
=0A
=0A
It sort of overloads code, but that is better than messing with response= _type for the authorization endpoint to change the response from the token_= endpoint.  That is in my opinion a champion bad idea. 
=0A=0A
=0A
=0A
 
= =0A
=0A
=0A
=0A
In discussions developing Connect we decided not to open this can of wor= ms because no good would come of it.   
=0A
=0A
=0A=
=0A
 
=0A
=0A=0A
=0A
The token_endp= oint returns a access token.  Nothing requires scope to be associates = with the token. 
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
That is the best solution.  No change= required.  Better interoperability in my opinion. 
=0A=0A
=0A
=0A
 
=0A=0A
=0A
=0A
St= ill on my way to TO, getting in later today. 
=0A
=0A
= =0A
=0A
 
=0A
=0A=0A
=0A
John B.&nbs= p;
=0A
=0A
=0A
=0A
&= nbsp;
=0A
=0A
=0A
=0A


Sent from my iPhone
=0A
=0A
=0A

On Jul = 23, 2014, at 12:15 PM, torst= en@lodderstedt.net wrote:
=0A
=0A
=0A
=0A
The "response type" of the = token endpoint is controlled by the value of the parameter "grant_type". So= there is no need to introduce a new parameter.
=0A
wrt to a poten= tial "no_access_token" grant type. I do not consider this a good idea as it= changes the semantics of the token endpoint (as already pointed out by Tho= mas). This endpoint ALWAYS responds with an access token to any grant type.= I therefore would prefer to use another endpoint for the intended purpose.=
=0A
regards,
Torsten.
=0A
=0A
 
=0A
=0A
Am 23.07.2014 13:04, schrieb Na= t Sakimura:
=0A
=0A
=0A
=0A
IMHO, changing the semantics of "response_type" @ authz endpoin= t this way is not a good thing. 
=0A
=0A
=0A
=0A 
=0A
=0A
=0A
Instead, defining a new parameter = "response_type" @ token endpoint, as I described in my previous message,&nb= sp;
=0A
=0A
proba= bly is better. At least, it does not change the semantics of the parameters= of RFC6749. 
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
 Nat 
=0A
=0A
=0A=0A
=0A
 
=0A
=0A
=0A
2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>:
=0A
=0A
No, I mean response_type=3Dnone and = response_type=3Did_token don't generate a code or access token so you don't= use the Token Endpoint (which is not the same as the Authentication Endpoi= nt BTW).
=0A
=0A
= With response_type=3Dcode_for_id_token, you get a code and exchange it for = an id_token only, rather than an access_token, so you're changing the seman= tics of the Token Endpoint.
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
I'm not saying it's a bad thing, jus= t that you can't really compare none and id_token with code_for_id_token.=0A
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
= =0A
=0A
On Wed, Jul 23,= 2014 at 6:45 PM, Richer, Justin P. <j= richer@mitre.org> wrote:
=0A
=0A
It's only "not using the token endpoint" because the = token endpoint copy-pasted and renamed the authentication endpoint.
= =0A
=0A
=0A
 
=0A=0A
=0A
=0A
&nb= sp;-- Justin
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0AOn Jul 23, 2014, at 9:30 AM,= Thomas Broyer <t.broyer@gmail.com> wrote:
=0A
=0A
 
=0A
=0A
Except that these are about not using the Token End= point at all, whereas the current proposal is about the Token Endpoint not = returning an access_token field in the JSON.
=0A
=0A
=0A
=0A
&n= bsp;
=0A
=0A
=0A
On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:=
=0A
=0A
=0A
<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb= (31, 73, 125);">The response_type "none" is already used in practice, which= returns no access token.  It was accepted by the designated experts a= nd registered in the IANA OAuth Authorization Endpoint Response Types regis= try at http://www.iana.= org/assignments/oauth-parameters/oauth-parameters.xml#endpoint.  T= he registered "id_token" response type also returns no access token.=
=0A
=0A
&nb= sp;
=0A
=0A
So I think the question of whether response types that r= esult in no access token being returned are acceptable within OAuth 2.0 is = already settled, as a practical matter.  Lots of OAuth implementations= are already using such response types.
=0A
=0A
 
=0A
= =0A
 =             &nb= sp;            =             &nb= sp;            =          -- Mike
=0A=0A
 =0A
=0A
=0A
=0A
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sen= t: Wednesday, July 23, 2014 7:09 AM
To:<= /span> Nat Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for draft-h= unt-oauth-v2-user-a4c-05.txt
=0A
=0A
=0A
=0A
= =0A
=0A
 
=0A
=0AYes. This is why it has to b= e discussed in the IETF.
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A
= =0A
=0A
=0A
=0A
=0A
=0A
Phil
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
@independentid
=0A
=0A
=0Awww.independentid.com<= /div>=0A
=0A
=0A
= phil.hunt@oracle.com
=0A
=0A
=0A<= div>=0A
 
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
On Jul 23, 2014, at 9:43 AM, Nat Sakimura <= ;sakimura@gmail.com> wrote:=0A
=0A
=0A
 
=0A
=0A
=0A
Reading back the RFC6749, I am not sure if there is a= good way of suppressing access token from the response and still be OAuth.= It will break whole bunch of implicit definitions like: 
=0A=0A
=0A
 
=0A
=0A<= /div>=0A
authorization serv= er
      The server issuing access tokens to the client = after successfully
      authenticating the resource own= er and obtaining authorization.
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
After all, OAuth is all about issuing acc= ess tokens. 
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
Also, I take back my statement on the grant ty= pe in my previous mail. 
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
The definition of grant and gran= t_type are respectively: 
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
= =0A
grant 
=0A=0A
=0A
   = ; credential representing the resource owner's authorization
=0A
= =0A
=0A
=0A
   =         
=0A
=0A
= =0A
=0A
grant_type=0A
=0A
=0A
 = ;   (string representing the) type of grant sent to the token end= point to obtain the access token
=0A
=0A
=0A
=0A
=0A=
 
=0A
=0A
=0A=0A
Thus, the grant sent t= o the token endpoint in this case is still 'code'. 
=0A
=0A<= div>=0A
=0A
 
=0A
= =0A
=0A
=0A
Respon= se type on the other hand is not so well defined in RFC6749, but it seems i= t is representing what is to be returned from the authorization endpoint. T= o express what is to be returned from token endpoint, perhaps defining a ne= w parameter to the token endpoint, which is a parallel to the response_type= to the Authorization Endpoint seems to be a more symmetric way, though I a= m not sure at all if that is going to be OAuth any more. One straw-man is t= o define a new parameter called response_type to the token endpoint such as= : 
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
response_type
=0A
=0A
=0A
    OPTIONAL. A string representi= ng what is to be returned from the token endpoint. 
=0A
=0A<= div>=0A
=0A
    =0A
=0A
=0A
=0A
Then define the behavior of the endpoint according to the values as t= he parallel to the multi-response type spec. 
=0A
=0A=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
Nat
=0A
=0A
=0A
=0A
    
=0A
=0A
=0A
=0A=
=0A
 
=0A
=0A=0A
=0A
=0A
 
=0A=0A
=0A
=0A
=0A
=0A 
=0A
=0A
=0A
2014-07-23 7:21 GMT-04:00 Phil Hu= nt <phil.hunt@oracle.com&g= t;:
=0A
=0A
=0A
The draft is very clear. 

Phi= l
=0A
=0A
=0A
=0A
=0A

On Jul 23, 2014, at 0:46,= Nat Sakimura <sakimura@gmail.com> wrote:
=0A
=0A
=0A
=0A
= The new grant type that I was talking about was 
=0A
=0A
"authorization_code_but_do_not_= return_access_nor_refresh_token", so to speak. 
=0A
=0A
= =0A
It does not return anyt= hing per se, but an extension can define something on top of it. =0A
=0A
=0A
=0A
 =0A
=0A
=0A
=0A
Then, OIDC can define a binding to it so that the binding only retur= ns ID Token. 
=0A
=0A
=0A
This binding work should be done in OIDF. Should there be= such a grant type, 
=0A
=0A
=0A
=0A
=0A
it will be an extremely short sp= ec. 
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
At the same time, if any other specification wanted to= define 
=0A
=0A
=0A
other type of tokens and have it returned from the token endpo= int, 
=0A
=0A
=0A
it can also use this grant type. 
=0A
=0A
=0A<= div>=0A
 
=0A
=0A
= =0A
=0A
If what you wan= t is to define a new grant type that returns ID Token only, 
=0A<= /div>=0A
=0A
then, I am= with Justin. Since "other response than ID Token" is only 
=0A=0A
=0A
theoretical= , this is a more plausible way forward, I suppose. 
=0A
=0A<= div>=0A
=0A
 
=0A
= =0A
=0A
=0A
Nat=0A
=0A
=0A
=0A
=0A 
=0A
=0A
=0A=0A<= div class=3D"yiv7015674266MsoNormal" style=3D"">So the draft would literall= y turn into:

"The a4c response type and grant type return an id_tok= en from the token endpoint with no access token. All parameters and values = are defined in OIDC."

Seems like the perfect mini extension draft f= or OIDF to do.

--Justin

/sent from my phone/
=0A
= =0A

On Jul 22, 2014 10= :29 AM, Nat Sakimura <sakimura@gmail= .com> wrote:
>
> What about just defining a new grant = type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil= Hunt <phil.hunt@oracle.com&= gt;:
>>
>> That would be nice. However oidc still needs= the new grant type in order to implement the same flow. 
>>=
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat= Sakimura <sakimura@gmail.com>= ; wrote:
>>
>>> +1 to Justin. 
>>>=
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
&g= t;>>> Errors like these make it clear to me that it would make muc= h more sense to develop this document in the OpenID Foundation. It should b= e something that directly references OpenID Connect Core for all of these t= erms instead of redefining them. It's doing authentication, which is fundam= entally what OpenID Connect does on top of OAuth, and I don't see a good ar= gument for doing this work in this working group.
>>>>
= >>>>  -- Justin
>>>>
>>>> = On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>
= >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@microsoft.c= om> wrote:
>>>>>>
>>>>>>= Thanks for your review, Thomas.  The "prompt=3Dconsent" definition be= ing missing is an editorial error.  It should be:
>>>>= >>
>>>>>>  
>>>>>> >>>>>> consent
>>>>>>
>&g= t;>>>> The Authorization Server SHOULD prompt the End-User for = consent before returning information to the Client. If it cannot obtain con= sent, it MUST return an error, typically consent_required.
>>>= >>>
>>>>>>  
>>>>>>
>>>>>> I'll plan to add it = in the next draft.
>>>>>
>>>>>
&g= t;>>>> It looks like the consent_required error needs to be def= ined too, and you might have forgotten to also import account_selection_req= uired from OpenID Connect.
>>>>>  
>>>= >>>
>>>>>>  
>>>>>&g= t;
>>>>>> I agree that there's no difference between = a response with multiple "amr" values that includes "mfa" and one that does= n't.  Unless a clear use case for why "mfa" is needed can be identifie= d, we can delete it in the next draft.
>>>>>
>>= ;>>>
>>>>> Thanks.
>>>>>
= >>>>> How about "pwd" then? I fully understand that I shoul= d return "pwd" if the user authenticated using a password, but what "the service if a client secret is used" means in the definition for the "= pwd" value?
>>>>>
>>>>> (Nota: I know= you're at IETF-90, I'm ready to wait 'til you come back ;-) )
>>= >>>
>>>>> --
>>>>> Thomas Br= oyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>= >>>> _______________________________________________
>&g= t;>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> htt= ps://www.ietf.org/mailman/listinfo/oauth
>>>>
>&= gt;>>
>>>>
>>>> _______________________________________________
>>>> OAuth= mailing list
>>>> OAuth@ietf.o= rg
>>>> https://www.ietf.org/mailman/li= stinfo/oauth
>>>>
>>>
>>>
= >>>
>>> --
>>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation
>>> http://nat.sakimur= a.org/
>>> @_nat_en
>>>
>>> ____= ___________________________________________
>>> OAuth mailing = list
>>> OAuth@ietf.org
&g= t;>> https://www.ietf.org/mailman/listinfo/oauth
>
= >
>
>
> --
> Nat Sakimura (=3Dnat)
> = Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_n= at_en
=0A
=0A
=0A


=0A
=0A
=0A
 
=0A
=0A
=0A
--
Nat Sakimura (=3Dnat)
=0A
=0A
Chairman, OpenID Foundation
<= a rel=3D"nofollow" target=3D"_blank" href=3D"http://nat.sakimura.org/">http= ://nat.sakimura.org/
@_nat_en
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A


=0A
=0A
=0A
 
=0A
=0A
=0A
--
Nat Sakimura (=3Dnat)
=0A
= =0A
Chairman, OpenID Founda= tion
http://nat.sakimura.org/
@_nat_en
=0A
=0A
=0A=0A
=0A
 
=0A
= =0A
=0A
=0A
=0A
=0A
=0A

___________________________= ____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf= o/oauth
=0A
=0A


=0A
=0A
=0A
 
=0A
=0A
=0A
--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.= je/
=0A
=0A
_= ______________________________________________
OAuth mailing list
OAuth@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A


=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
-= -
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
= =0A
=0A

_______________________________________________
OAuth maili= ng list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=0A
=0A


=0A=0A
=0A
 
=0A
=0A=
=0A
--
Nat Sakim= ura (=3Dnat)
=0A
=0A
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en=
=0A
=0A
=0A
=0A
&n= bsp;
=0A
=0A
_______________________________________________<=
/pre>=0A
OAuth mailing list
=0A
OA=
uth@ietf.org
=0A
https://www.ietf.org/mailman/=
listinfo/oauth
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A=
=0A
=0A______________________________= _________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/oa= uth
=0A
=0A
=0A
=0A
=0A
=0A
= =0A
_______________________________________________
OAuth mailing listOAuth@ietf.org
https:/= /www.ietf.org/mailman/listinfo/oauth
=0A
=0A


=0A
=0A
 
=0A
=0A
--
Nat Sakimura (=3Dnat)
=0A
=0A
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=0A
=0A
=0A

__________________________________= _____________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>
=0A=0A
=0A
=0A
=0A
=0A


=0A
=0A
 
=0A
=0A
--
Nat Sakimura (=3Dnat)
=0A=0A
=0A
=0A
=0A=0A
=0A
=0A
___________________= ____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/= listinfo/oauth
=0A
=0A
=0A=0A= =0A
________________________= _______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth=0A=0A
=0A=0A=0A=0A
 
=0A=0A
=0A=
 
=0A
=0A= =0A=0A

_______________________________________________
OAuth maili= ng list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=0A=0A<= /div>=0A=0A=0A
=0A
=0A


=0A
=0A
 
=0A
=0A
-- Nat Sakimura (=3Dnat)
=0A
=0A
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en=0A
=0A
=0A
=0A
=0A

_________________________________= ______________
OAuth mailing list
OAuth@= ietf.org
https://www.ietf.org/mailman/listinfo/oauth=
=0A=0A
 
=0A= =0A=0A
 
=0A=0A=0A=0A
______________= _________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
=0A=0A
 
=0A=0A=0A
=0A
__________________________=
_____________________=0AOAuth mailing list=0AOA=
uth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oa=
uth=0A
=0A=0A
 
=0A
 
=0A=
_______________________________________________
OAuth ma= iling list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=


--905790552-462800050-1406225471=:11804-- From nobody Thu Jul 24 11:17:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC1F1B27B8 for ; Thu, 24 Jul 2014 11:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 Gugu7wVbZwV9 for ; Thu, 24 Jul 2014 11:17:49 -0700 (PDT) Received: from nm50-vm2.bullet.mail.bf1.yahoo.com (nm50-vm2.bullet.mail.bf1.yahoo.com [216.109.115.221]) (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 436681B27BF for ; Thu, 24 Jul 2014 11:17:42 -0700 (PDT) Received: from [98.139.212.149] by nm50.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2014 18:17:41 -0000 Received: from [98.139.212.218] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2014 18:17:41 -0000 Received: from [127.0.0.1] by omp1027.mail.bf1.yahoo.com with NNFMP; 24 Jul 2014 18:17:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 261432.76516.bm@omp1027.mail.bf1.yahoo.com Received: (qmail 74499 invoked by uid 60001); 24 Jul 2014 18:17:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1406225861; bh=DzZhv4ZuT/rE3WsEOtGGxonTpa53o8FYG7wSbFsMw0w=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ts5o62uJPh78/M/Z3GrYQPpX/oghEkdXUp/gvAI8mye2kxQURZG/iLPrbJxn/Pi5rCDi2Ae7+T2P5QYiSJGaX0qx33wPMOzLPXqF33kbBNDlkf27jPVVxubHCvgvtBSnl43raVxRubjwtrjWrUmASq9HcNZF9DfLV3Ao7oV4Vm4= X-YMail-OSG: Dcmoj0EVM1mIBA4KhUREPI8H9.VtxHpCeG3OLe9j.wGZDLR S6JunO0xL31p2SHvZoJNMtTmYHCf.jdMXM6jfgNgcJdpD5B_80S.zKeg8T1o xqOqcen7lxy1Dh9UJSXYs0f1wv20KJlVfKpP4Zt7HhRrSj2qh5Uu_AYK2259 9OIWZfeosV_PKcU15IDX_Jzzk72Llv6TYr8I7i186mjYVVF_lv6vceW9wGIF zFx_MisUfMsNytxTxrWuR6jJsz2XqZ5cuaAACbvGxHhPwIydgFndbrVLJT_6 k182rR18AxFtJNazPg8TZR.IDCNcMs3iyMlbBvO34Rh.IFfwu_u2zgOZaFl4 sww8M.4AEnHiFxyMckQ9LYm7rgohvRpiZviTIC8np2PiL2Qb1GqQCgwdNY9G I.pmZpbjlTulqxT7j_6S4j_CNiIYhIVcQAJP.toilDMY_EZrbZ8wYB.Grcic JXDzWASJWFWmvpaJLwX18fX_nV105IDTrS14jpDb_IC7qpqdNGdzCmbm758T 97f6NGma69euo2xEbnlO82fgpN8lM4j3J7UKy.Z4syXzY5t.i7iJW878eVBm rcqkUCaUt9LfU1i5Z2KYawDki6_bC0eR6oYTdpnzXdlav5tBqkdHBTA5DV.Y Heg-- Received: from [167.220.24.190] by web142802.mail.bf1.yahoo.com via HTTP; Thu, 24 Jul 2014 11:17:41 PDT X-Rocket-MIMEInfo: 002.001, VGhlbiB3aHkgYXJlbid0IHBlb3BsZSB1c2luZyB0aGlzIGluc3RlYWQgb2YgKG1pcyl1c2luZyBPQXV0aCBmb3IgdGhpcz8KCkRpZmZlcmVudCBxdWVzdGlvbiwgaWYgd2UgZG8gZGVmaW5lIEFDNCB3aWxsIHBlb3BsZSBtb3ZlIHRvIHRoYXQsIG9yIGNvbnRpbnVlIGRvaW5nIHRoZSB3cm9uZyB0aGluZyBhbnl3YXk_CgoKT24gVGh1cnNkYXksIEp1bHkgMjQsIDIwMTQgODo1NyBBTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20.IHdyb3RlOgogCgoKCgoyMDE0LTA3LTI0IDEwOjMwIEdNVC0wNDoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.196.685 References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <9dbf8c7384e341a08334a9ee093697f8@BLUPR03MB309.namprd03.prod.outlook.com> <45D858DE-6F5E-46D4-828C-9C4C80C3AC2A@oracle.com> Message-ID: <1406225861.40476.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Thu, 24 Jul 2014 11:17:41 -0700 From: Bill Mills To: Nat Sakimura , Phil Hunt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-829016114-1406225861=:40476" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/tXY2EkzmNgyiqZw91vTgrtdhggw Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:17:52 -0000 --1397251415-829016114-1406225861=:40476 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Then why aren't people using this instead of (mis)using OAuth for this?=0A= =0ADifferent question, if we do define AC4 will people move to that, or con= tinue doing the wrong thing anyway?=0A=0A=0AOn Thursday, July 24, 2014 8:57= AM, Nat Sakimura wrote:=0A =0A=0A=0A=0A=0A2014-07-24 = 10:30 GMT-04:00 Phil Hunt :=0A=0AI=E2=80=99m not at a= ll saying that OpenID is bad. If you want an IDP, its fine. =C2=A0But if al= l a client wants is authentication, they think why can=E2=80=99t I just use= RFC6749?=0AIf all what one wants is to build a simple client, there is a s= tanding document called OpenID Connect Basic Client Implementer's Guide 1.0= .=C2=A0=0A=0AIt is a profile that deals only the 'code' flow.=C2=A0=0ASize-= wise, it is 32 pages. The break down are as below approximately:=C2=A0=0A= =0AAbstract, Intro, ToC - 2.5 pages=0ATerminology - 1.5 pages=0AGetting ID = Token - 9 pages=0AID Token Validation - 1 page (Seems missing from a4c draf= t?)=0AUserinfo Endpoint - 7 pages=0ASerializations - 1 page (missing in a4c= ?)=0AString Operations etc. - 1 pages (missing in a4c?)=0AConsiderations - = 2 pages (very brief in a4c)=0AReferences, Acknowledgement - 2 pages=0ADocum= ent History etc. - 7 pages=0A=0A=0AThe a4c draft is 14 pages long. It will = be longer than this in the end as it is missing bunch of things.=C2=A0=0ATh= e comparable portion of the Basic Client Profile is 14 pages or so.=C2=A0= =0A=0AJust one data point.=C2=A0=0A=0A-- =0ANat Sakimura (=3Dnat)=0AChairma= n, OpenID Foundation=0Ahttp://nat.sakimura.org/=0A@_nat_en=0A______________= _________________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ah= ttps://www.ietf.org/mailman/listinfo/oauth --1397251415-829016114-1406225861=:40476 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Then why aren't people using this instead of (mis)= using OAuth for this?

Different question, if we do define = AC4 will people move to that, or continue doing the wrong thing anyway?


On Thursday, July 24, 2014 8:57 AM, Na= t Sakimura <sakimura@gmail.com> wrote:


<= div class=3D"y_msg_container">

2014-07-24 10:30 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
=0AI=E2=80=99m not at all saying that OpenID i= s bad. If you want an IDP, its fine.  But if all a client wants is aut= hentication, they think why can=E2=80=99t I just use RFC6749?<= /div>
If all what one wants is to build a simple client, there is a stan= ding document called OpenID Connect Basic Client Implementer's Guide 1.0.&n= bsp;
=0A

It is a profile that deals only the 'code' fl= ow. 
Size-wise, it is 32 = pages. The break down are as below approximately: 
=0A

Abstract, Intro, ToC - 2.5 pages
Terminology - 1.5 pages
Getting ID Token - 9 pages
= =0AID Token Validation - 1 page (Seems missing from a4c draft?)
U= serinfo Endpoint - 7 pages
Ser= ializations - 1 page (missing in a4c?)
=0A
String Operations etc. - 1 pages (missing in a4c?)
Considerations - 2 pages (very brief in a4= c)
References, Acknowledgement= - 2 pages
=0A
Document History etc. - 7 pages

The a4c draft is 14 pages long. It = will be longer than this in the end as it is missing bunch of things. =
The comparable portion of the= Basic Client Profile is 14 pages or so. 
=0A

Just = one data point. 

--
Nat Sakimura (= =3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
=0A= @_nat_en
=0A

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


--1397251415-829016114-1406225861=:40476-- From nobody Thu Jul 24 11:52:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D131A002A for ; Thu, 24 Jul 2014 11:52:13 -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 Ny403AUBLeMA for ; Thu, 24 Jul 2014 11:52:12 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0834B1ABB34 for ; Thu, 24 Jul 2014 11:52:08 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id 10so2580965lbg.6 for ; Thu, 24 Jul 2014 11:52:07 -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=CAO6g6eUU926M5gffLFDqh3GlPU0zgRg6r1ViXQe+FI=; b=u34LqRXlnxGh/VZ2OO/XHifrLdabK3AsrYdj5p+u1Ls+ZHBO0k2i5PMhcQbyxV59Ww DckbTgCuPDjAgZ+fljK8pHMP4CHMLmgF630tusKtnp/RugmFIoo7LDzrCgSOxLsgBtFe Nbp/DDuOclDHOjt/7bayhFLfQoCBWtvOXmD6t3NqExTIbEIz01WqW/UR1CJmvLXnCo+Z ZvyumtK/+tMFi80dGMbMa4omKS11a2o9tZHdRUDRgHTgCG4tAdSyQDzeYpyBMbGd//2P 9VarQ53eWKxG5nszG4CCIStzFG3FfbueAWxZXig16DdhNGUG4mLFvdj/ZF7khvrexQNu 06oQ== MIME-Version: 1.0 X-Received: by 10.112.54.197 with SMTP id l5mr5912825lbp.103.1406227927275; Thu, 24 Jul 2014 11:52:07 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Thu, 24 Jul 2014 11:52:06 -0700 (PDT) In-Reply-To: <1406225861.40476.YahooMailNeo@web142802.mail.bf1.yahoo.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <9dbf8c7384e341a08334a9ee093697f8@BLUPR03MB309.namprd03.prod.outlook.com> <45D858DE-6F5E-46D4-828C-9C4C80C3AC2A@oracle.com> <1406225861.40476.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Thu, 24 Jul 2014 14:52:06 -0400 Message-ID: From: Nat Sakimura To: Bill Mills Content-Type: multipart/alternative; boundary=001a11c3e85214201f04fef4f46d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HJUdIXhhdE861wFsk1_QJZJH7HI Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Thu, 24 Jul 2014 18:52:13 -0000 --001a11c3e85214201f04fef4f46d Content-Type: text/plain; charset=UTF-8 2014-07-24 14:17 GMT-04:00 Bill Mills : > Then why aren't people using this instead of (mis)using OAuth for this? Even with a spec this short, IMHO, developers would not read it. What they want is easy to read description with sample code, I suppose. It also does not have adequate amount of publicity/marketing/education, etc. Example code repository in Github and Bitbucket etc. may help a bit. > > Different question, if we do define AC4 will people move to that, or continue doing the wrong thing anyway? They would not move to it because they will not read a spec. Instead they will google or search stackoverflow for "OAuth Authentication sample REST" or something like that and will use whatever comes up as easy and appealing to read. -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c3e85214201f04fef4f46d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2014-07-24 14:17 GMT-04:00 Bill Mills <wmills_92105@yahoo.com>= :
> Then why aren't people using this instead of (mis)using OAuth for = this?

= Even with a spec this short, IMHO, developers would not read it.=C2=A0
What they want is easy to read description with sample code, I suppose.=C2= =A0
It also does not have adequate amount o= f publicity/marketing/education, etc.=C2=A0
Example code repository in Github and Bitbucket etc. may help a bit.=C2=A0=

>
> Different question, if we do de= fine AC4 will people move to that, or continue doing the wrong thing anyway= ?

They would not move to it because they will not read a spec.=C2= =A0
Instead they will google or search stackoverflow for "OAuth Authe= ntication sample REST" or something like that and will use whatever co= mes up as easy and appealing to read.=C2=A0

--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c3e85214201f04fef4f46d-- From nobody Thu Jul 24 18:31:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70871A0386 for ; Thu, 24 Jul 2014 18:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOGkuBmx1gBl for ; Thu, 24 Jul 2014 18:31:29 -0700 (PDT) Received: from na3sys009aog135.obsmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64CD1A0360 for ; Thu, 24 Jul 2014 18:31:28 -0700 (PDT) Received: from mail-ie0-f173.google.com ([209.85.223.173]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKU9GzcJufQK80bMXv+0CBp38WwQzWxtbP@postini.com; Thu, 24 Jul 2014 18:31:28 PDT Received: by mail-ie0-f173.google.com with SMTP id tr6so3020113ieb.4 for ; Thu, 24 Jul 2014 18:31:28 -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=ZwYlhHFp8ANk/vi4JaFzDfmHfhWAGgtKLk2UBmIlZpY=; b=mgkowAdb1pDL+j5NoupPoG5c6gJznDZPs1SZ5CHPMDM+Qr96wKlx9zsTEoKOeWwFrD s9xAwyFR62g9iKdqpj4X8Er36aLcEnR6Vrkdeg59s5G5Abxc9+NPFFkfY8LfqgnJbu2w yRHs+/vIlsog9jS6+nlbUL/AgIapPldCfJkimGXMuUO5mFkeqewg5CcqqnQV0aORcAen 19gQG56TZUIArCl9CysLl5pw0phuK7/b3aPBOQTVkUyUj5ww1qLWKwu+0dwAvclaCxtO cSZniiziOkxdvhd2dPx+fdsK9bz281o+BMxgNT+bw6L0Dka+9mplUnBofhyqwYoy2/cF uG2w== X-Gm-Message-State: ALoCoQnqWjh0A823bVVdEf24zJKa01mrntxnQy9tcyME5f3L5pg01r+HeB4CO9NNjq3Gp+x8rwPeCY+trcY3aQcUSAj1oheD5TTy1sBQVegV4GzvXpnpRA3/ei5G4wh6lKtPugpEW5em X-Received: by 10.42.93.84 with SMTP id w20mr17036878icm.49.1406251888020; Thu, 24 Jul 2014 18:31:28 -0700 (PDT) X-Received: by 10.42.93.84 with SMTP id w20mr17036865icm.49.1406251887798; Thu, 24 Jul 2014 18:31:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Thu, 24 Jul 2014 18:30:57 -0700 (PDT) In-Reply-To: <054c4958db6545cf99d3f0339e34c776@BLUPR03MB309.namprd03.prod.outlook.com> References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <054c4958db6545cf99d3f0339e34c776@BLUPR03MB309.namprd03.prod.outlook.com> From: Brian Campbell Date: Thu, 24 Jul 2014 19:30:57 -0600 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=90e6ba6150343ccb1c04fefa8827 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/yfbVtGtcYsWiSNnlmHkDlgmZz3Q Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Fri, 25 Jul 2014 01:31:36 -0000 --90e6ba6150343ccb1c04fefa8827 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The situations are rather different. On Thu, Jul 24, 2014 at 11:25 AM, Anthony Nadalin wrote: > OMG, how can you say that when the Dynamkc Reg does the same thing > (duplicates) but that is OK to do > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Thursday, July 24, 2014 10:22 AM > > *To:* John Bradley > *Cc:* oauth@ietf.org list > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > I'm sorry to miss what will likely be a very engaging meeting today. > > The premise that some developers are using OAuth in a insecure way to do > authentication is something we can probably all agree on. > > It doesn't necessarily follow from that premise, however, that the > solution is yet another spec which either duplicates some subset of OpenI= D > Connect (in a different SDO) or forks how to do SSO/authentication using > OAuth. > > > > On Thu, Jul 24, 2014 at 7:25 AM, John Bradley wrote: > > I am not against discussion in the WG. > > > > I happen to agree with Phil's fundamental premise that some developers ar= e > using OAuth in a insecure way to do authentication. > > > > That raises the question of how to best educate them, and or address > technical barriers. > > > > It is on the second point that people's opinions seem to divide. > > > > Some people thing that if we have a OAuth flow that eliminates the access > token (primarily to avoid asking for consent as I understand it) and just > return a id_token from the token endpoint that can be done in a spec shor= t > enough to het people to read. The subtext of this is that the Connect > specification is too large that it scare people, and they don't find the > spec in the first place because it is not a RFC. > > > > An other common possession is that if you don't want to prompt the user > for consent then don't ask for scopes. Twisting the OAuth spec to not > return an access token is not OAuth, yes you could use a different > endpoint rather than the token endpoint, but that is not OAuth. Connect > was careful not to break the OAuth spec. As long as you are willing to > take a access token with no scopes (the client needs to understand that > there are no attributes one way or another anyway or it will break) then > you don't need to change OAuth. You can publish a profile of connect th= at > satisfies the use case. > > > > I think Mike has largely done that but it might be better being less > stingy on references back to the larger spec. > > > > The questions are do we modify OAuth to not return an access token, and i= f > so how, and if we do is it still OAuth. > > > > The other largely separable question is do we create confusion in the > market and slow the the adoption of identity federation on top of OAuth, = or > find a way to make this look like a positive alignment of interests aroun= d > a subset of Connect. > > > > There are a number of options. > > 1: We can do a profile in the OIDF and publish it as a IETF document. > Perhaps the cleanest from an IPR point of view. > > 2:We can do a profile in the OAuth WG referencing connect. > > 3:We can do a AD sponsored profile that is not in the OAuth WG. > > 4:We can do a small spec in OAuth to add response_type to the token > endpoint. in combination with 1, 2, or 3 > > > > I agree that stoping developers doing insecure things needs to be > addressed somehow. > > I am not personally convinced that Oauth without access tokens is sensibl= e. > > > > Looking forward to the meeting:) > > > > John B. > > > > On Jul 24, 2014, at 6:52 AM, Brian Campbell > wrote: > > > > I'd note that the reaction at the conference to Ian's statement was > overwhelmingly positive. There was a wide range of industry people here - > implementers, practitioners, deployers, strategists, etc. - and it seems > pretty clear that the "rough consensus" of the industry at large is that > a4c is not wanted or needed. > > > > On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura wrote: > > And here is a quote from Ian's blog. > > > > And although the authentication wheel is round, that doesn=E2=80=99t mean= it isn=E2=80=99t > without its lumps. First, we do see some reinventing the wheel just to > reinvent the wheel. OAuth A4C is simply not a fruitful activity and shoul= d > be put down. > > > > (Source) > http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musin= gs-on-identity-standards-part-1.html > > > > 2014-07-23 16:53 GMT-04:00 John Bradley : > > > > I thought I did post this to the list. > > > > I guess I hit the wrong reply on my phone. > > > John B. > Sent from my iPhone > > > On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote: > > we are two, at least :-) > > Why didn't you post this on the list? > > When will be be arriving? > > Am 23.07.2014 16:39, schrieb John Bradley: > > Ian Glazer mentioned this in his keynote at CIS yesterday. > > > > His advice was please stop, we are creating confusion and uncertainty. > > > > We are becoming our own wort enemy. ( my view though Ian may share it) > > > > Returning just an id_ token from the token endpoint has little real value= . > > > > Something really useful to do would be sorting out channel_id so we can d= o > PoP for id tokens to make them and other cookies secure in the front > channel. I think that is a better use of time. > > > > I may be in the minority opinion on that, it won't be the first time. > > > > John B. > Sent from my iPhone > > > On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt > wrote: > > You are right from a theoretical perspective. Practically this was > caused by editorial decisions during the creation of the RFC. As far as I > remember, there was a definition of the (one) token endpoint response in > early versions. No one every considered to NOT respond with an access tok= en > from the token endpoint. So one might call it an implicit assumption. > > > > I'm worried that people get totally confused if an exception is introduce= d > now given the broad adoption of OAuth based on this assumption. > > > > regards, > > Torsten. > > > Am 23.07.2014 um 15:41 schrieb Thomas Broyer : > > Is it said anywhere that ALL grant types MUST use Section 5.1 responses? > Each grant type references Section 5.1, and "access token request" is onl= y > defined in the context of the defined grant types. Section 2.2 doesn't ta= lk > about the request or response format. > > Le 23 juil. 2014 21:32, "Nat Sakimura" a =C3=A9crit = : > > Is it? Apart from the implicit grant that does not use token endpoint, > all other grant references section 5.1 for the response, i.e., all shares > the same response. > > > > 2014-07-23 15:18 GMT-04:00 Thomas Broyer : > > I hadn't realized the JSON response that requires the access_token field > is defined per grant_type, so I'd be OK to "extend the semantics" as in t= he > current draft. > That was actually my main concern: that the token endpoint mandates > access_token; but its actually not the case. > > Le 23 juil. 2014 20:46, "Nat Sakimura" a =C3=A9crit = : > > > > I agree with John that overloading response_type @ authz endpoint is a > bad idea. It completely changes the semantics of this parameter. NOTE: wh= at > I was proposing was not this parameter, but a new parameter response_type= @ > token endpoint. > > > > I also think overloading grant_type is a bad idea since it changes its > semantics. I quote the definition here again: > > > > grant > > credential representing the resource owner's authorization > > > > grant_type > > type of grant sent to the token endpoint to obtain the access token > > > > It is not about controlling what is to be returned from the token > endpoint, but the hint to the token endpoint describing the type of > credential the endpoint has received. It seems the "control of what is > being returned from token endpoint" is just a side effect. > > > > I am somewhat ambivalent[1] in changing the semantics of token endpoint, > but in as much as "text is the king" for a spec., we probably should not > change the semantics of it as Torsten points out. If it is ok to change > this semantics, I believe defining a new parameter to this endpoint to > control the response would be the best way to go. This is what I have > described previously. > > > > Defining a new endpoint to send code to get ID Token and forbidding the > use of it against token endpoint would not change the semantics of any > existing parameter or endpoint, which is good. However, I doubt if it is > not worth doing. What's the point of avoiding access token scoped to > UserInfo endpoint after all? Defining a new endpoint for just avoiding th= e > access token for userinfo endpoint seems way too much the heavy wait way > and it breaks interoperabiliy: it defeats the purpose of standardization. > > > > I have started feeling that no change is the best way out. > > > > Nat > > > > [1] If instead of saying "Token endpoint - used by the client to exchang= e > an authorization grant for an access token, typically with client > authentication", it were saying "Token endpoint - used by the client to > exchange an authorization grant for tokens, typically with client > authentication", then it would have been OK. It is an expansion of the > capability rather than changing the semantics. > > > > > > 2014-07-23 13:39 GMT-04:00 Mike Jones : > > You need the alternative response_type value ("code_for_id_token" in the > A4C draft) to tell the Authorization Server to return a code to be used > with the new grant type, rather than one to use with the > "authorization_code" grant type (which is what response_type=3Dcode does)= . > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Wednesday, July 23, 2014 10:33 AM > *To:* torsten@lodderstedt.net > > > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > > > If we use the token endpoint then a new grant_type is the best way. > > > > It sort of overloads code, but that is better than messing with > response_type for the authorization endpoint to change the response from > the token_endpoint. That is in my opinion a champion bad idea. > > > > In discussions developing Connect we decided not to open this can of worm= s > because no good would come of it. > > > > The token_endpoint returns a access token. Nothing requires scope to be > associates with the token. > > > > That is the best solution. No change required. Better interoperability > in my opinion. > > > > Still on my way to TO, getting in later today. > > > > John B. > > > > > > Sent from my iPhone > > > On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: > > The "response type" of the token endpoint is controlled by the value of > the parameter "grant_type". So there is no need to introduce a new > parameter. > > wrt to a potential "no_access_token" grant type. I do not consider this a > good idea as it changes the semantics of the token endpoint (as already > pointed out by Thomas). This endpoint ALWAYS responds with an access toke= n > to any grant type. I therefore would prefer to use another endpoint for t= he > intended purpose. > > regards, > Torsten. > > > > Am 23.07.2014 13:04, schrieb Nat Sakimura: > > IMHO, changing the semantics of "response_type" @ authz endpoint this > way is not a good thing. > > > > Instead, defining a new parameter "response_type" @ token endpoint, as I > described in my previous message, > > probably is better. At least, it does not change the semantics of the > parameters of RFC6749. > > > > Nat > > > > 2014-07-23 12:48 GMT-04:00 Thomas Broyer : > > No, I mean response_type=3Dnone and response_type=3Did_token don't genera= te a > code or access token so you don't use the Token Endpoint (which is not th= e > same as the Authentication Endpoint BTW). > > With response_type=3Dcode_for_id_token, you get a code and exchange it fo= r > an id_token only, rather than an access_token, so you're changing the > semantics of the Token Endpoint. > > > > I'm not saying it's a bad thing, just that you can't really compare none > and id_token with code_for_id_token. > > > > On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. > wrote: > > It's only "not using the token endpoint" because the token endpoint > copy-pasted and renamed the authentication endpoint. > > > > -- Justin > > > > On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote: > > > > Except that these are about not using the Token Endpoint at all, whereas > the current proposal is about the Token Endpoint not returning an > access_token field in the JSON. > > > > On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones > wrote: > > The response_type "none" is already used in practice, which returns no > access token. It was accepted by the designated experts and registered i= n > the IANA OAuth Authorization Endpoint Response Types registry at > http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#end= point. > The registered "id_token" response type also returns no access token. > > > > So I think the question of whether response types that result in no acces= s > token being returned are acceptable within OAuth 2.0 is already settled, = as > a practical matter. Lots of OAuth implementations are already using such > response types. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Wednesday, July 23, 2014 7:09 AM > *To:* Nat Sakimura > *Cc:* > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > Yes. This is why it has to be discussed in the IETF. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote: > > > > Reading back the RFC6749, I am not sure if there is a good way of > suppressing access token from the response and still be OAuth. It will > break whole bunch of implicit definitions like: > > > > authorization server > The server issuing access tokens to the client after successfully > authenticating the resource owner and obtaining authorization. > > > > After all, OAuth is all about issuing access tokens. > > > > Also, I take back my statement on the grant type in my previous mail. > > > > The definition of grant and grant_type are respectively: > > > > grant > > credential representing the resource owner's authorization > > > > grant_type > > (string representing the) type of grant sent to the token endpoint to > obtain the access token > > > > Thus, the grant sent to the token endpoint in this case is still 'code'. > > > > Response type on the other hand is not so well defined in RFC6749, but it > seems it is representing what is to be returned from the authorization > endpoint. To express what is to be returned from token endpoint, perhaps > defining a new parameter to the token endpoint, which is a parallel to th= e > response_type to the Authorization Endpoint seems to be a more symmetric > way, though I am not sure at all if that is going to be OAuth any more. O= ne > straw-man is to define a new parameter called response_type to the token > endpoint such as: > > > > response_type > > OPTIONAL. A string representing what is to be returned from the token > endpoint. > > > > Then define the behavior of the endpoint according to the values as the > parallel to the multi-response type spec. > > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html > > > > Nat > > > > > > > > > > 2014-07-23 7:21 GMT-04:00 Phil Hunt : > > The draft is very clear. > > Phil > > > On Jul 23, 2014, at 0:46, Nat Sakimura wrote: > > The new grant type that I was talking about was > > "authorization_code_but_do_not_return_access_nor_refresh_token", so to > speak. > > It does not return anything per se, but an extension can define something > on top of it. > > > > Then, OIDC can define a binding to it so that the binding only returns ID > Token. > > This binding work should be done in OIDF. Should there be such a grant > type, > > it will be an extremely short spec. > > > > At the same time, if any other specification wanted to define > > other type of tokens and have it returned from the token endpoint, > > it can also use this grant type. > > > > If what you want is to define a new grant type that returns ID Token only= , > > then, I am with Justin. Since "other response than ID Token" is only > > theoretical, this is a more plausible way forward, I suppose. > > > > Nat > > > > 2014-07-22 14:30 GMT-04:00 Justin Richer : > > So the draft would literally turn into: > > "The a4c response type and grant type return an id_token from the token > endpoint with no access token. All parameters and values are defined in > OIDC." > > Seems like the perfect mini extension draft for OIDF to do. > > --Justin > > /sent from my phone/ > > > On Jul 22, 2014 10:29 AM, Nat Sakimura wrote: > > > > What about just defining a new grant type in this WG? > > > > > > 2014-07-22 12:56 GMT-04:00 Phil Hunt : > >> > >> That would be nice. However oidc still needs the new grant type in > order to implement the same flow. > >> > >> Phil > >> > >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote: > >> > >>> +1 to Justin. > >>> > >>> > >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. : > >>>> > >>>> Errors like these make it clear to me that it would make much more > sense to develop this document in the OpenID Foundation. It should be > something that directly references OpenID Connect Core for all of these > terms instead of redefining them. It's doing authentication, which is > fundamentally what OpenID Connect does on top of OAuth, and I don't see a > good argument for doing this work in this working group. > >>>> > >>>> -- Justin > >>>> > >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer > wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < > Michael.Jones@microsoft.com> wrote: > >>>>>> > >>>>>> Thanks for your review, Thomas. The "prompt=3Dconsent" definition > being missing is an editorial error. It should be: > >>>>>> > >>>>>> > >>>>>> > >>>>>> consent > >>>>>> > >>>>>> The Authorization Server SHOULD prompt the End-User for consent > before returning information to the Client. If it cannot obtain consent, = it > MUST return an error, typically consent_required. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I'll plan to add it in the next draft. > >>>>> > >>>>> > >>>>> It looks like the consent_required error needs to be defined too, > and you might have forgotten to also import account_selection_required fr= om > OpenID Connect. > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> I agree that there's no difference between a response with multipl= e > "amr" values that includes "mfa" and one that doesn't. Unless a clear us= e > case for why "mfa" is needed can be identified, we can delete it in the > next draft. > >>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>> How about "pwd" then? I fully understand that I should return "pwd" > if the user authenticated using a password, but what "the service if a > client secret is used" means in the definition for the "pwd" value? > >>>>> > >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come > back ;-) ) > >>>>> > >>>>> -- > >>>>> Thomas Broyer > >>>>> /t=C9=94.ma.b=CA=81wa.je/ > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> > >>> > >>> > >>> -- > >>> Nat Sakimura (=3Dnat) > >>> Chairman, OpenID Foundation > >>> http://nat.sakimura.org/ > >>> @_nat_en > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > _______________________________________________ > > 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 > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > 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 > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > --90e6ba6150343ccb1c04fefa8827 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The situations are rather different.


On Thu, Jul 24, 2014 at= 11:25 AM, Anthony Nadalin <tonynad@microsoft.com> wrote= :

OMG, how can you say that= when the Dynamkc Reg does the same thing (duplicates) but that is OK to do=

=C2=A0

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 10:22 AM

To: John Bradley
Cc: oauth@ietf.o= rg list
Subject: Re: [OAUTH-WG] New Version Not= ification for draft-hunt-oauth-v2-user-a4c-05.txt
=

=C2=A0

I'm sorry to miss what will likely be a very eng= aging meeting today.

The premise that some developers are using OAuth in a insecure way to do au= thentication is something we can probably all agree on.

It doesn't necessarily follow from that premise, however, that the solu= tion is yet another spec which either duplicates some subset of OpenID Conn= ect (in a different SDO) or forks how to do SSO/authentication using OAuth.

=C2=A0<= /p>

On Thu, Jul 24, 2014 at 7:25 AM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:

I am not against discussion in the WG.=

=C2=A0

I happen to agree with Phil's fundamental premis= e that some developers are using OAuth in a insecure way to do authenticati= on.

=C2=A0

That raises the question of how to best educate them= , and or address technical barriers.

=C2=A0

It is on the second point that people's opinions= seem to divide.

=C2=A0

Some people thing that if we have a OAuth flow that = eliminates the access token (primarily to avoid asking for consent as I und= erstand it) and just return a id_token from the token endpoint that can be = done in a spec short enough to het people to read. =C2=A0 The subtext of this is that the Connect specificati= on is too large that it scare people, =C2=A0and they don't find the spe= c in the first place because it is not a RFC.

=C2=A0

An other common possession is that if you don't = want to prompt the user for consent then don't ask for scopes. =C2=A0Tw= isting the OAuth spec to not return an access token is not OAuth, =C2=A0yes= you could use a different endpoint rather than the token endpoint, but that is not OAuth. =C2=A0 Connect was careful not to b= reak the OAuth spec. =C2=A0 =C2=A0As long as you are willing to take a acce= ss token with no scopes (the client needs to understand that there are no a= ttributes one way or another anyway or it will break) then you don't need to change OAuth. =C2=A0 You can publish a p= rofile of connect that satisfies the use case.

=C2=A0

I think Mike has largely done that but it might be b= etter being less stingy on references back to the larger spec.

=C2=A0

The questions are do we modify OAuth to not return a= n access token, and if so how, =C2=A0and if we do is it still OAuth.=

=C2=A0

The other largely separable question is do we create= confusion in the market and slow the the adoption of identity federation o= n top of OAuth, or find a way to make this look like a positive alignment o= f interests around a subset of Connect.

=C2=A0

There are a number of options. =C2=A0<= /p>

1: We can do a profile in the OIDF and publish it as= a IETF document. =C2=A0 Perhaps the cleanest from an IPR point of view.=

2:We can do a profile in the OAuth WG referencing co= nnect.

3:We can do a AD sponsored profile that is not in th= e OAuth WG.

4:We can do a small spec in OAuth to add response_ty= pe to the token endpoint. =C2=A0in combination with 1, 2, or 3

=C2=A0

I agree that stoping developers doing insecure thing= s needs to be addressed somehow. =C2=A0

I am not personally convinced that Oauth without acc= ess tokens is sensible.

=C2=A0

Looking forward to the meeting:)

=C2=A0

John B.

=C2=A0

On Jul 24, 2014, at 6:52 AM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:



I'd note that the reaction at the conference to = Ian's statement was overwhelmingly positive. There was a wide range of = industry people here - implementers, practitioners, deployers, strategists,= etc. - and it seems pretty clear that the "rough consensus" of the industry at large is that a4c is not wa= nted or needed.

=C2=A0<= /p>

On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:

And here is a quote from Ian's blog.=C2=A0

=C2=A0

And although the authentication wheel is round, that= doesn=E2=80=99t mean it isn=E2=80=99t without its lumps. First, we do see = some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply = not a fruitful activity and should be put down. =C2=A0

=C2=A0

(Source) http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings= -on-identity-standards-part-1.html

=C2=A0<= /p>

2014-07-23 16:53 GMT-04:00 John Bradley <ve7jtb@ve7jtb.com>:<= u>

=C2=A0

I thought I did post this to the list.=C2=A0<= u>

=C2=A0

I guess I hit the wrong reply on my phone.=C2=A0
=C2=A0

John B.=C2=A0
Sent from my iPhone


On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net wrote:

we are two, at least :-)

Why didn't you post this on the list?

When will be be arriving?

Am 23.07.2014 16:39, schrieb John Bradley:

Ian Glazer mentioned this in his keynote at CIS yest= erday.=C2=A0

=C2=A0

His advice was please stop, =C2=A0we are creating co= nfusion and uncertainty.=C2=A0

=C2=A0

We are becoming our own wort enemy. ( my view though= Ian may share it)

=C2=A0

Returning just an id_ token from the token endpoint = has little real value.=C2=A0

=C2=A0

Something really useful to do would be sorting out c= hannel_id so we can do PoP for id tokens to make them and other cookies sec= ure in the front channel. =C2=A0 I think that is a better use of time.=C2= =A0

=C2=A0

I may be in the minority opinion on that, =C2=A0it w= on't be the first time. =C2=A0



John B.=C2=A0
Sent from my iPhone


On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrot= e:

You are right from a theoretical perspective. Practi= cally this was caused by editorial decisions during the creation of the RFC= . As far as I remember, there was a definition of the (one) token endpoint = response in early versions. No one every considered to NOT respond with an access token from the token endpoi= nt. So one might call it an implicit assumption.

=C2=A0

I'm worried that people get totally confused if = an exception is introduced now given the broad adoption of OAuth based on t= his assumption.

=C2=A0

regards,

Torsten.


Am 23.07.2014 um 15:41 schrieb Thomas Broyer <t.broyer@gmail.com>:

Is it said anywhere that ALL grant types MUST use Section 5.1 responses?= Each grant type references Section 5.1, and "access token request&quo= t; is only defined in the context of the defined grant types. Section 2.2 d= oesn't talk about the request or response format.

Le 23 juil. 2014 21:32, "Nat Sakimura" <= ;sakimura@gmail.com= > a =C3=A9crit :

Is it? Apart from the implicit grant that does not u= se token endpoint, all other grant references section 5.1 for the response,= i.e., all shares the same response.=C2=A0

=C2=A0<= /p>

2014-07-23 15:18 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>= :

I hadn't realized the JSON response that requires the access_token f= ield is defined per grant_type, so I'd be OK to "extend the semant= ics" as in the current draft.
That was actually my main concern: that the token endpoint mandates access_= token; but its actually not the case.

Le 23 juil. 2014 20:46, "Nat Sakimura" <= ;sakimura@gmail.com= > a =C3=A9crit :

=C2=A0

I agree with John that overloading response_type @ a= uthz endpoint is a bad idea. It completely changes the semantics of this pa= rameter. NOTE: what I was proposing was not this parameter, but a new param= eter response_type @ token endpoint.=C2=A0

=C2=A0

I also think overloading grant_type is a bad idea si= nce it changes its semantics. I quote the definition here again:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0

grant_type

type of grant sent to the token endpoint to obtain t= he access token

=C2=A0

It is not about controlling what is to be returned f= rom the token endpoint, but the hint to the token endpoint describing the t= ype of credential the endpoint has received. It seems the "control of = what is being returned from token endpoint" =C2=A0is just a side effect.=C2=A0

=C2=A0

I am somewhat ambivalent[1] in changing the semantic= s of token endpoint, but in as much as "text is the king" for a s= pec., we probably should not change the semantics of it as Torsten points o= ut. If it is ok to change this semantics, I believe defining a new parameter to this endpoint to control the response = would be the best way to go. This is what I have described previously.=C2= =A0

=C2=A0

Defining a new endpoint to send code to get ID Token= and forbidding the use of it against token endpoint would not change the s= emantics of any existing parameter or endpoint, which is good. However, I d= oubt if it is not worth doing. What's the point of avoiding access token scoped to UserInfo endpoint after all? = Defining a new endpoint for just avoiding the access token for userinfo end= point seems way too much the heavy wait way and it breaks interoperabiliy: = it defeats the purpose of standardization.=C2=A0

=C2=A0

I have started feeling that no change is the best wa= y out.=C2=A0

=C2=A0

Nat

=C2=A0

[1] =C2=A0If instead of saying "Token endpoint = - used by the client to exchange an authorization=C2=A0grant for an access = token, typically with client authentication", it were saying "Tok= en endpoint - used by the client to exchange an authorization=C2=A0grant for tokens, typically with client authentication", then it would have= been OK. It is an expansion of the capability rather than changing the sem= antics.

=C2=A0

=C2=A0<= /p>

2014-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@micros= oft.com>:

You need the alternative = response_type value ("code_for_id_token" in the A4C draft) to tell the Authorization Server to return a code to be = used with the new grant type, rather than one to use with the "authori= zation_code" grant type (which is what response_type=3Dcode does).

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: torsten@lodderstedt.net


Cc: oa= uth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft= -hunt-oauth-v2-user-a4c-05.txt

=C2=A0

=C2=A0

If we use the token endpoint then a new grant_type i= s the best way.=C2=A0

=C2=A0

It sort of overloads code, but that is better than m= essing with response_type for the authorization endpoint to change the resp= onse from the token_endpoint. =C2=A0That is in my opinion a champion bad idea.=C2=A0

=C2=A0

In discussions developing Connect we decided not to = open this can of worms because no good would come of it. =C2=A0=C2=A0

=C2=A0

The token_endpoint returns a access token. =C2=A0Not= hing requires scope to be associates with the token.=C2=A0

=C2=A0

That is the best solution. =C2=A0No change required.= =C2=A0Better interoperability in my opinion.=C2=A0

=C2=A0

Still on my way to TO, getting in later today.=C2=A0=

=C2=A0

John B.=C2=A0

=C2=A0



Sent from my iPhone


On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:

The "response type" of the token endpoint is controlled by the= value of the parameter "grant_type". So there is no need to intr= oduce a new parameter.

wrt to a potential "no_access_token" grant type. I do not cons= ider this a good idea as it changes the semantics of the token endpoint (as= already pointed out by Thomas). This endpoint ALWAYS responds with an acce= ss token to any grant type. I therefore would prefer to use another endpoint for the intended purpose.

regards,
Torsten.

=C2=A0

Am 23.07.2014 13:04, schrieb Nat Sakimura:

IMHO, changing the semantics of "response_type&= quot; @ authz endpoint this way is not a good thing.=C2=A0

=C2=A0

Instead, defining a new parameter "response_typ= e" @ token endpoint, as I described in my previous message,=C2=A0

probably is better. At least, it does not change the= semantics of the parameters of RFC6749.=C2=A0

=C2=A0

=C2=A0Nat=C2=A0

=C2=A0

2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>= :

No, I mean response_type=3Dnone and response_type=3D= id_token don't generate a code or access token so you don't use the= Token Endpoint (which is not the same as the Authentication Endpoint BTW).

With response_type=3Dcode_for_id_token, you get a co= de and exchange it for an id_token only, rather than an access_token, so yo= u're changing the semantics of the Token Endpoint.

=C2=A0

I'm not saying it's a bad thing, just that y= ou can't really compare none and id_token with code_for_id_token.

=C2=A0

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. &= lt;jricher@mitre.org= > wrote:

It's only "not using the token endpoint&quo= t; because the token endpoint copy-pasted and renamed the authentication en= dpoint.

=C2=A0

=C2=A0-- Justin

=C2=A0

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com&g= t; wrote:

=C2=A0<= /p>

Except that these are about not using the Token Endp= oint at all, whereas the current proposal is about the Token Endpoint not r= eturning an access_token field in the JSON.

=C2=A0

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

The response_type "n= one" is already used in practice, which returns no access token.=C2=A0= It was accepted by the designated experts and registered in the IANA OAuth Authorization E= ndpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpo= int.=C2=A0 The registered "id_token" response type also retur= ns no access token.

=C2=A0

So I think the question o= f whether response types that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical matter.=C2= =A0 Lots of OAuth implementations are already using such response types.

=C2=A0

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for dra= ft-hunt-oauth-v2-user-a4c-05.txt

=C2=A0

Yes. This is why it has to be discussed in the IETF.=

=C2=A0

Phil

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

=C2=A0

Reading back the RFC6749, I am not sure if there is = a good way of suppressing access token from the response and still be OAuth= . It will break whole bunch of implicit definitions like:=C2=A0

=C2=A0

authorization server
=C2=A0 =C2=A0 =C2=A0 The server issuing access tokens to the client after s= uccessfully
=C2=A0 =C2=A0 =C2=A0 authenticating the resource owner and obtaining author= ization.

=C2=A0

After all, OAuth is all about issuing access tokens.= =C2=A0

=C2=A0

Also, I take back my statement on the grant type in = my previous mail.=C2=A0

=C2=A0

The definition of grant and grant_type are respectiv= ely:=C2=A0

=C2=A0

grant=C2=A0

=C2=A0 =C2=A0 credential representing the resource o= wner's authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

grant_type

=C2=A0=C2=A0=C2=A0 (string representing the) type of= grant sent to the token endpoint to obtain the access token<= /p>

=C2=A0

Thus, the grant sent to the token endpoint in this c= ase is still 'code'.=C2=A0

=C2=A0

Response type on the other hand is not so well defin= ed in RFC6749, but it seems it is representing what is to be returned from = the authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the t= oken endpoint, which is a parallel to the response_type to the Authorizatio= n Endpoint seems to be a more symmetric way, though I am not sure at all if= that is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the tok= en endpoint such as:=C2=A0

=C2=A0

response_type

=C2=A0 =C2=A0 OPTIONAL. A string representing what i= s to be returned from the token endpoint.=C2=A0

=C2=A0 =C2=A0=C2=A0

Then define the behavior of the endpoint according t= o the values as the parallel to the multi-response type spec.=C2=A0<= u>

=C2=A0

Nat

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0

2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:=

The draft is very clear.=C2=A0

Phil


On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote:

The new grant type that I was talking about was=C2= =A0

"authorization_code_but_do_not_return_access_no= r_refresh_token", so to speak.=C2=A0

It does not return anything per se, but an extension= can define something on top of it.=C2=A0

=C2=A0

Then, OIDC can define a binding to it so that the bi= nding only returns ID Token.=C2=A0

This binding work should be done in OIDF. Should the= re be such a grant type,=C2=A0

it will be an extremely short spec.=C2=A0<= /u>

=C2=A0

At the same time, if any other specification wanted = to define=C2=A0

other type of tokens and have it returned from the t= oken endpoint,=C2=A0

it can also use this grant type.=C2=A0=

=C2=A0

If what you want is to define a new grant type that = returns ID Token only,=C2=A0

then, I am with Justin. Since "other response t= han ID Token" is only=C2=A0

theoretical, this is a more plausible way forward, I= suppose.=C2=A0

=C2=A0

Nat

=C2=A0

2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>:

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the toke= n endpoint with no access token. All parameters and values are defined in O= IDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/


On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> That would be nice. However oidc still needs the new grant type in= order to implement the same flow.=C2=A0
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>>> +1 to Justin.=C2=A0
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>:
>>>>
>>>> Errors like these make it clear to me that it would make m= uch more sense to develop this document in the OpenID Foundation. It should= be something that directly references OpenID Connect Core for all of these= terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of = OAuth, and I don't see a good argument for doing this work in this work= ing group.
>>>>
>>>> =C2=A0-- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> wro= te:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.=C2=A0 The "pr= ompt=3Dconsent" definition being missing is an editorial error.=C2=A0 = It should be:
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-Use= r for consent before returning information to the Client. If it cannot obta= in consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I'll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be d= efined too, and you might have forgotten to also import account_selection_r= equired from OpenID Connect.
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> I agree that there's no difference between a r= esponse with multiple "amr" values that includes "mfa" = and one that doesn't.=C2=A0 Unless a clear use case for why "mfa&q= uot; is needed can be identified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand tha= t I should return "pwd" if the user authenticated using a passwor= d, but what "the service if a client secret is used" means in the= definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to = wait 'til you come back ;-) )
>>>>>
>>>>> --
>>>>> Thomas Broyer
>>>>> /t=C9=94.ma.b=CA=81wa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://= nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0


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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/

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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

=C2=A0

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


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

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

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

=C2=A0

=C2=A0


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



=C2=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en


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

=C2=A0

=C2=A0

=C2=A0


--90e6ba6150343ccb1c04fefa8827-- From nobody Thu Jul 24 19:04:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66BC1A0AB6 for ; Thu, 24 Jul 2014 19:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocNsL2jpWGtV for ; Thu, 24 Jul 2014 19:04:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AAC81A0340 for ; Thu, 24 Jul 2014 19:04:41 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB311.namprd03.prod.outlook.com (10.141.48.26) with Microsoft SMTP Server (TLS) id 15.0.995.11; Fri, 25 Jul 2014 02:04:38 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0995.011; Fri, 25 Jul 2014 02:04:38 +0000 From: Anthony Nadalin To: Brian Campbell Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt Thread-Index: AQHPpdsDt+c24NfaK06ekEi1OvV9MZutFmeAgABuQQCAACfBgIAABwoAgAAFHwCAACJ8AIAABDOAgAAAxwCAAASJAIAAAz+AgAAE4ACAAAGWgIAAEq+AgAAJNoCAAAOsAIAAAq8AgAAGTgCAAA3vkIABBUgAgAAXRgCAAAkXAIAAMVuAgAAAsoCAAIf/gIAACTHw Date: Fri, 25 Jul 2014 02:04:38 +0000 Message-ID: References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <054c4958db6545cf99d3f0339e34c776@BLUPR03MB309.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.165.189.130] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(377424004)(51704005)(189002)(199002)(51444003)(24454002)(377454003)(105586002)(74316001)(106116001)(19580405001)(92566001)(4396001)(74502001)(19580395003)(21056001)(551544002)(15395725005)(64706001)(19609705001)(15975445006)(83322001)(46102001)(86362001)(99396002)(106356001)(99286002)(19617315012)(561944003)(85306003)(33646002)(66066001)(79102001)(74662001)(101416001)(107046002)(19625215002)(2656002)(81342001)(93886003)(76576001)(16236675004)(85852003)(76482001)(19300405004)(77982001)(83072002)(110136001)(15202345003)(80022001)(95666004)(81542001)(86612001)(50986999)(76176999)(54356999)(87936001)(31966008)(20776003)(108616002)(42262001)(24736002)(579004)(559001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB311; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_a3cec5f516f74c8c879dfd623ba71168BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Q7zKYe0fjW6Z9KTIqxyTJew0N5c Cc: "oauth@ietf.org list" Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.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: Fri, 25 Jul 2014 02:04:49 -0000 --_000_a3cec5f516f74c8c879dfd623ba71168BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2ggeWVhLCByZWFsIGRpZmZlcmVudCwgZ2l2ZSBtZSBhIGZyZWFraW5nIGJyZWFrDQoNCkZyb206 IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQpTZW50 OiBUaHVyc2RheSwgSnVseSAyNCwgMjAxNCA2OjMxIFBNDQpUbzogQW50aG9ueSBOYWRhbGluDQpD YzogSm9obiBCcmFkbGV5OyBvYXV0aEBpZXRmLm9yZyBsaXN0DQpTdWJqZWN0OiBSZTogW09BVVRI LVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNl ci1hNGMtMDUudHh0DQoNClRoZSBzaXR1YXRpb25zIGFyZSByYXRoZXIgZGlmZmVyZW50Lg0KDQpP biBUaHUsIEp1bCAyNCwgMjAxNCBhdCAxMToyNSBBTSwgQW50aG9ueSBOYWRhbGluIDx0b255bmFk QG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KT01H LCBob3cgY2FuIHlvdSBzYXkgdGhhdCB3aGVuIHRoZSBEeW5hbWtjIFJlZyBkb2VzIHRoZSBzYW1l IHRoaW5nIChkdXBsaWNhdGVzKSBidXQgdGhhdCBpcyBPSyB0byBkbw0KDQpGcm9tOiBPQXV0aCBb bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc+XSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IFRodXJzZGF5LCBKdWx5IDI0 LCAyMDE0IDEwOjIyIEFNDQoNClRvOiBKb2huIEJyYWRsZXkNCkNjOiBvYXV0aEBpZXRmLm9yZzxt YWlsdG86b2F1dGhAaWV0Zi5vcmc+IGxpc3QNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50 eHQNCg0KSSdtIHNvcnJ5IHRvIG1pc3Mgd2hhdCB3aWxsIGxpa2VseSBiZSBhIHZlcnkgZW5nYWdp bmcgbWVldGluZyB0b2RheS4NCg0KVGhlIHByZW1pc2UgdGhhdCBzb21lIGRldmVsb3BlcnMgYXJl IHVzaW5nIE9BdXRoIGluIGEgaW5zZWN1cmUgd2F5IHRvIGRvIGF1dGhlbnRpY2F0aW9uIGlzIHNv bWV0aGluZyB3ZSBjYW4gcHJvYmFibHkgYWxsIGFncmVlIG9uLg0KDQpJdCBkb2Vzbid0IG5lY2Vz c2FyaWx5IGZvbGxvdyBmcm9tIHRoYXQgcHJlbWlzZSwgaG93ZXZlciwgdGhhdCB0aGUgc29sdXRp b24gaXMgeWV0IGFub3RoZXIgc3BlYyB3aGljaCBlaXRoZXIgZHVwbGljYXRlcyBzb21lIHN1YnNl dCBvZiBPcGVuSUQgQ29ubmVjdCAoaW4gYSBkaWZmZXJlbnQgU0RPKSBvciBmb3JrcyBob3cgdG8g ZG8gU1NPL2F1dGhlbnRpY2F0aW9uIHVzaW5nIE9BdXRoLg0KDQpPbiBUaHUsIEp1bCAyNCwgMjAx NCBhdCA3OjI1IEFNLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdq dGJAdmU3anRiLmNvbT4+IHdyb3RlOg0KSSBhbSBub3QgYWdhaW5zdCBkaXNjdXNzaW9uIGluIHRo ZSBXRy4NCg0KSSBoYXBwZW4gdG8gYWdyZWUgd2l0aCBQaGlsJ3MgZnVuZGFtZW50YWwgcHJlbWlz ZSB0aGF0IHNvbWUgZGV2ZWxvcGVycyBhcmUgdXNpbmcgT0F1dGggaW4gYSBpbnNlY3VyZSB3YXkg dG8gZG8gYXV0aGVudGljYXRpb24uDQoNClRoYXQgcmFpc2VzIHRoZSBxdWVzdGlvbiBvZiBob3cg dG8gYmVzdCBlZHVjYXRlIHRoZW0sIGFuZCBvciBhZGRyZXNzIHRlY2huaWNhbCBiYXJyaWVycy4N Cg0KSXQgaXMgb24gdGhlIHNlY29uZCBwb2ludCB0aGF0IHBlb3BsZSdzIG9waW5pb25zIHNlZW0g dG8gZGl2aWRlLg0KDQpTb21lIHBlb3BsZSB0aGluZyB0aGF0IGlmIHdlIGhhdmUgYSBPQXV0aCBm bG93IHRoYXQgZWxpbWluYXRlcyB0aGUgYWNjZXNzIHRva2VuIChwcmltYXJpbHkgdG8gYXZvaWQg YXNraW5nIGZvciBjb25zZW50IGFzIEkgdW5kZXJzdGFuZCBpdCkgYW5kIGp1c3QgcmV0dXJuIGEg aWRfdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgdGhhdCBjYW4gYmUgZG9uZSBpbiBhIHNw ZWMgc2hvcnQgZW5vdWdoIHRvIGhldCBwZW9wbGUgdG8gcmVhZC4gICBUaGUgc3VidGV4dCBvZiB0 aGlzIGlzIHRoYXQgdGhlIENvbm5lY3Qgc3BlY2lmaWNhdGlvbiBpcyB0b28gbGFyZ2UgdGhhdCBp dCBzY2FyZSBwZW9wbGUsICBhbmQgdGhleSBkb24ndCBmaW5kIHRoZSBzcGVjIGluIHRoZSBmaXJz dCBwbGFjZSBiZWNhdXNlIGl0IGlzIG5vdCBhIFJGQy4NCg0KQW4gb3RoZXIgY29tbW9uIHBvc3Nl c3Npb24gaXMgdGhhdCBpZiB5b3UgZG9uJ3Qgd2FudCB0byBwcm9tcHQgdGhlIHVzZXIgZm9yIGNv bnNlbnQgdGhlbiBkb24ndCBhc2sgZm9yIHNjb3Blcy4gIFR3aXN0aW5nIHRoZSBPQXV0aCBzcGVj IHRvIG5vdCByZXR1cm4gYW4gYWNjZXNzIHRva2VuIGlzIG5vdCBPQXV0aCwgIHllcyB5b3UgY291 bGQgdXNlIGEgZGlmZmVyZW50IGVuZHBvaW50IHJhdGhlciB0aGFuIHRoZSB0b2tlbiBlbmRwb2lu dCwgYnV0IHRoYXQgaXMgbm90IE9BdXRoLiAgIENvbm5lY3Qgd2FzIGNhcmVmdWwgbm90IHRvIGJy ZWFrIHRoZSBPQXV0aCBzcGVjLiAgICBBcyBsb25nIGFzIHlvdSBhcmUgd2lsbGluZyB0byB0YWtl IGEgYWNjZXNzIHRva2VuIHdpdGggbm8gc2NvcGVzICh0aGUgY2xpZW50IG5lZWRzIHRvIHVuZGVy c3RhbmQgdGhhdCB0aGVyZSBhcmUgbm8gYXR0cmlidXRlcyBvbmUgd2F5IG9yIGFub3RoZXIgYW55 d2F5IG9yIGl0IHdpbGwgYnJlYWspIHRoZW4geW91IGRvbid0IG5lZWQgdG8gY2hhbmdlIE9BdXRo LiAgIFlvdSBjYW4gcHVibGlzaCBhIHByb2ZpbGUgb2YgY29ubmVjdCB0aGF0IHNhdGlzZmllcyB0 aGUgdXNlIGNhc2UuDQoNCkkgdGhpbmsgTWlrZSBoYXMgbGFyZ2VseSBkb25lIHRoYXQgYnV0IGl0 IG1pZ2h0IGJlIGJldHRlciBiZWluZyBsZXNzIHN0aW5neSBvbiByZWZlcmVuY2VzIGJhY2sgdG8g dGhlIGxhcmdlciBzcGVjLg0KDQpUaGUgcXVlc3Rpb25zIGFyZSBkbyB3ZSBtb2RpZnkgT0F1dGgg dG8gbm90IHJldHVybiBhbiBhY2Nlc3MgdG9rZW4sIGFuZCBpZiBzbyBob3csICBhbmQgaWYgd2Ug ZG8gaXMgaXQgc3RpbGwgT0F1dGguDQoNClRoZSBvdGhlciBsYXJnZWx5IHNlcGFyYWJsZSBxdWVz dGlvbiBpcyBkbyB3ZSBjcmVhdGUgY29uZnVzaW9uIGluIHRoZSBtYXJrZXQgYW5kIHNsb3cgdGhl IHRoZSBhZG9wdGlvbiBvZiBpZGVudGl0eSBmZWRlcmF0aW9uIG9uIHRvcCBvZiBPQXV0aCwgb3Ig ZmluZCBhIHdheSB0byBtYWtlIHRoaXMgbG9vayBsaWtlIGEgcG9zaXRpdmUgYWxpZ25tZW50IG9m IGludGVyZXN0cyBhcm91bmQgYSBzdWJzZXQgb2YgQ29ubmVjdC4NCg0KVGhlcmUgYXJlIGEgbnVt YmVyIG9mIG9wdGlvbnMuDQoxOiBXZSBjYW4gZG8gYSBwcm9maWxlIGluIHRoZSBPSURGIGFuZCBw dWJsaXNoIGl0IGFzIGEgSUVURiBkb2N1bWVudC4gICBQZXJoYXBzIHRoZSBjbGVhbmVzdCBmcm9t IGFuIElQUiBwb2ludCBvZiB2aWV3Lg0KMjpXZSBjYW4gZG8gYSBwcm9maWxlIGluIHRoZSBPQXV0 aCBXRyByZWZlcmVuY2luZyBjb25uZWN0Lg0KMzpXZSBjYW4gZG8gYSBBRCBzcG9uc29yZWQgcHJv ZmlsZSB0aGF0IGlzIG5vdCBpbiB0aGUgT0F1dGggV0cuDQo0OldlIGNhbiBkbyBhIHNtYWxsIHNw ZWMgaW4gT0F1dGggdG8gYWRkIHJlc3BvbnNlX3R5cGUgdG8gdGhlIHRva2VuIGVuZHBvaW50LiAg aW4gY29tYmluYXRpb24gd2l0aCAxLCAyLCBvciAzDQoNCkkgYWdyZWUgdGhhdCBzdG9waW5nIGRl dmVsb3BlcnMgZG9pbmcgaW5zZWN1cmUgdGhpbmdzIG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBzb21l aG93Lg0KSSBhbSBub3QgcGVyc29uYWxseSBjb252aW5jZWQgdGhhdCBPYXV0aCB3aXRob3V0IGFj Y2VzcyB0b2tlbnMgaXMgc2Vuc2libGUuDQoNCkxvb2tpbmcgZm9yd2FyZCB0byB0aGUgbWVldGlu ZzopDQoNCkpvaG4gQi4NCg0KT24gSnVsIDI0LCAyMDE0LCBhdCA2OjUyIEFNLCBCcmlhbiBDYW1w YmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPj4gd3JvdGU6DQoNCkknZCBub3RlIHRoYXQgdGhlIHJlYWN0aW9uIGF0IHRoZSBj b25mZXJlbmNlIHRvIElhbidzIHN0YXRlbWVudCB3YXMgb3ZlcndoZWxtaW5nbHkgcG9zaXRpdmUu IFRoZXJlIHdhcyBhIHdpZGUgcmFuZ2Ugb2YgaW5kdXN0cnkgcGVvcGxlIGhlcmUgLSBpbXBsZW1l bnRlcnMsIHByYWN0aXRpb25lcnMsIGRlcGxveWVycywgc3RyYXRlZ2lzdHMsIGV0Yy4gLSBhbmQg aXQgc2VlbXMgcHJldHR5IGNsZWFyIHRoYXQgdGhlICJyb3VnaCBjb25zZW5zdXMiIG9mIHRoZSBp bmR1c3RyeSBhdCBsYXJnZSBpcyB0aGF0IGE0YyBpcyBub3Qgd2FudGVkIG9yIG5lZWRlZC4NCg0K T24gVGh1LCBKdWwgMjQsIDIwMTQgYXQgNToyOSBBTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBn bWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KQW5kIGhlcmUgaXMg YSBxdW90ZSBmcm9tIElhbidzIGJsb2cuDQoNCkFuZCBhbHRob3VnaCB0aGUgYXV0aGVudGljYXRp b24gd2hlZWwgaXMgcm91bmQsIHRoYXQgZG9lc27igJl0IG1lYW4gaXQgaXNu4oCZdCB3aXRob3V0 IGl0cyBsdW1wcy4gRmlyc3QsIHdlIGRvIHNlZSBzb21lIHJlaW52ZW50aW5nIHRoZSB3aGVlbCBq dXN0IHRvIHJlaW52ZW50IHRoZSB3aGVlbC4gT0F1dGggQTRDIGlzIHNpbXBseSBub3QgYSBmcnVp dGZ1bCBhY3Rpdml0eSBhbmQgc2hvdWxkIGJlIHB1dCBkb3duLg0KDQooU291cmNlKSBodHRwOi8v d3d3LnR1ZXNkYXluaWdodC5vcmcvMjAxNC8wNy8yMy9kby13ZS1oYXZlLWEtcm91bmQtd2hlZWwt eWV0LW11c2luZ3Mtb24taWRlbnRpdHktc3RhbmRhcmRzLXBhcnQtMS5odG1sDQoNCjIwMTQtMDct MjMgMTY6NTMgR01ULTA0OjAwIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRv OnZlN2p0YkB2ZTdqdGIuY29tPj46DQoNCkkgdGhvdWdodCBJIGRpZCBwb3N0IHRoaXMgdG8gdGhl IGxpc3QuDQoNCkkgZ3Vlc3MgSSBoaXQgdGhlIHdyb25nIHJlcGx5IG9uIG15IHBob25lLg0KDQpK b2huIEIuDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIEp1bCAyMywgMjAxNCwgYXQgNDo1MCBQ TSwgdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0 PiB3cm90ZToNCg0Kd2UgYXJlIHR3bywgYXQgbGVhc3QgOi0pDQoNCldoeSBkaWRuJ3QgeW91IHBv c3QgdGhpcyBvbiB0aGUgbGlzdD8NCg0KV2hlbiB3aWxsIGJlIGJlIGFycml2aW5nPw0KDQpBbSAy My4wNy4yMDE0IDE2OjM5LCBzY2hyaWViIEpvaG4gQnJhZGxleToNCklhbiBHbGF6ZXIgbWVudGlv bmVkIHRoaXMgaW4gaGlzIGtleW5vdGUgYXQgQ0lTIHllc3RlcmRheS4NCg0KSGlzIGFkdmljZSB3 YXMgcGxlYXNlIHN0b3AsICB3ZSBhcmUgY3JlYXRpbmcgY29uZnVzaW9uIGFuZCB1bmNlcnRhaW50 eS4NCg0KV2UgYXJlIGJlY29taW5nIG91ciBvd24gd29ydCBlbmVteS4gKCBteSB2aWV3IHRob3Vn aCBJYW4gbWF5IHNoYXJlIGl0KQ0KDQpSZXR1cm5pbmcganVzdCBhbiBpZF8gdG9rZW4gZnJvbSB0 aGUgdG9rZW4gZW5kcG9pbnQgaGFzIGxpdHRsZSByZWFsIHZhbHVlLg0KDQpTb21ldGhpbmcgcmVh bGx5IHVzZWZ1bCB0byBkbyB3b3VsZCBiZSBzb3J0aW5nIG91dCBjaGFubmVsX2lkIHNvIHdlIGNh biBkbyBQb1AgZm9yIGlkIHRva2VucyB0byBtYWtlIHRoZW0gYW5kIG90aGVyIGNvb2tpZXMgc2Vj dXJlIGluIHRoZSBmcm9udCBjaGFubmVsLiAgIEkgdGhpbmsgdGhhdCBpcyBhIGJldHRlciB1c2Ug b2YgdGltZS4NCg0KSSBtYXkgYmUgaW4gdGhlIG1pbm9yaXR5IG9waW5pb24gb24gdGhhdCwgIGl0 IHdvbid0IGJlIHRoZSBmaXJzdCB0aW1lLg0KDQoNCkpvaG4gQi4NClNlbnQgZnJvbSBteSBpUGhv bmUNCg0KT24gSnVsIDIzLCAyMDE0LCBhdCA0OjA0IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3 cm90ZToNCllvdSBhcmUgcmlnaHQgZnJvbSBhIHRoZW9yZXRpY2FsIHBlcnNwZWN0aXZlLiBQcmFj dGljYWxseSB0aGlzIHdhcyBjYXVzZWQgYnkgZWRpdG9yaWFsIGRlY2lzaW9ucyBkdXJpbmcgdGhl IGNyZWF0aW9uIG9mIHRoZSBSRkMuIEFzIGZhciBhcyBJIHJlbWVtYmVyLCB0aGVyZSB3YXMgYSBk ZWZpbml0aW9uIG9mIHRoZSAob25lKSB0b2tlbiBlbmRwb2ludCByZXNwb25zZSBpbiBlYXJseSB2 ZXJzaW9ucy4gTm8gb25lIGV2ZXJ5IGNvbnNpZGVyZWQgdG8gTk9UIHJlc3BvbmQgd2l0aCBhbiBh Y2Nlc3MgdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQuIFNvIG9uZSBtaWdodCBjYWxsIGl0 IGFuIGltcGxpY2l0IGFzc3VtcHRpb24uDQoNCkknbSB3b3JyaWVkIHRoYXQgcGVvcGxlIGdldCB0 b3RhbGx5IGNvbmZ1c2VkIGlmIGFuIGV4Y2VwdGlvbiBpcyBpbnRyb2R1Y2VkIG5vdyBnaXZlbiB0 aGUgYnJvYWQgYWRvcHRpb24gb2YgT0F1dGggYmFzZWQgb24gdGhpcyBhc3N1bXB0aW9uLg0KDQpy ZWdhcmRzLA0KVG9yc3Rlbi4NCg0KQW0gMjMuMDcuMjAxNCB1bSAxNTo0MSBzY2hyaWViIFRob21h cyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPj46 DQoNCklzIGl0IHNhaWQgYW55d2hlcmUgdGhhdCBBTEwgZ3JhbnQgdHlwZXMgTVVTVCB1c2UgU2Vj dGlvbiA1LjEgcmVzcG9uc2VzPyBFYWNoIGdyYW50IHR5cGUgcmVmZXJlbmNlcyBTZWN0aW9uIDUu MSwgYW5kICJhY2Nlc3MgdG9rZW4gcmVxdWVzdCIgaXMgb25seSBkZWZpbmVkIGluIHRoZSBjb250 ZXh0IG9mIHRoZSBkZWZpbmVkIGdyYW50IHR5cGVzLiBTZWN0aW9uIDIuMiBkb2Vzbid0IHRhbGsg YWJvdXQgdGhlIHJlcXVlc3Qgb3IgcmVzcG9uc2UgZm9ybWF0Lg0KTGUgMjMganVpbC4gMjAxNCAy MTozMiwgIk5hdCBTYWtpbXVyYSIgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFA Z21haWwuY29tPj4gYSDDqWNyaXQgOg0KSXMgaXQ/IEFwYXJ0IGZyb20gdGhlIGltcGxpY2l0IGdy YW50IHRoYXQgZG9lcyBub3QgdXNlIHRva2VuIGVuZHBvaW50LCBhbGwgb3RoZXIgZ3JhbnQgcmVm ZXJlbmNlcyBzZWN0aW9uIDUuMSBmb3IgdGhlIHJlc3BvbnNlLCBpLmUuLCBhbGwgc2hhcmVzIHRo ZSBzYW1lIHJlc3BvbnNlLg0KDQoyMDE0LTA3LTIzIDE1OjE4IEdNVC0wNDowMCBUaG9tYXMgQnJv eWVyIDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+Og0KDQpJ IGhhZG4ndCByZWFsaXplZCB0aGUgSlNPTiByZXNwb25zZSB0aGF0IHJlcXVpcmVzIHRoZSBhY2Nl c3NfdG9rZW4gZmllbGQgaXMgZGVmaW5lZCBwZXIgZ3JhbnRfdHlwZSwgc28gSSdkIGJlIE9LIHRv ICJleHRlbmQgdGhlIHNlbWFudGljcyIgYXMgaW4gdGhlIGN1cnJlbnQgZHJhZnQuDQpUaGF0IHdh cyBhY3R1YWxseSBteSBtYWluIGNvbmNlcm46IHRoYXQgdGhlIHRva2VuIGVuZHBvaW50IG1hbmRh dGVzIGFjY2Vzc190b2tlbjsgYnV0IGl0cyBhY3R1YWxseSBub3QgdGhlIGNhc2UuDQpMZSAyMyBq dWlsLiAyMDE0IDIwOjQ2LCAiTmF0IFNha2ltdXJhIiA8c2FraW11cmFAZ21haWwuY29tPG1haWx0 bzpzYWtpbXVyYUBnbWFpbC5jb20+PiBhIMOpY3JpdCA6DQoNCkkgYWdyZWUgd2l0aCBKb2huIHRo YXQgb3ZlcmxvYWRpbmcgcmVzcG9uc2VfdHlwZSBAIGF1dGh6IGVuZHBvaW50IGlzIGEgYmFkIGlk ZWEuIEl0IGNvbXBsZXRlbHkgY2hhbmdlcyB0aGUgc2VtYW50aWNzIG9mIHRoaXMgcGFyYW1ldGVy LiBOT1RFOiB3aGF0IEkgd2FzIHByb3Bvc2luZyB3YXMgbm90IHRoaXMgcGFyYW1ldGVyLCBidXQg YSBuZXcgcGFyYW1ldGVyIHJlc3BvbnNlX3R5cGUgQCB0b2tlbiBlbmRwb2ludC4NCg0KSSBhbHNv IHRoaW5rIG92ZXJsb2FkaW5nIGdyYW50X3R5cGUgaXMgYSBiYWQgaWRlYSBzaW5jZSBpdCBjaGFu Z2VzIGl0cyBzZW1hbnRpY3MuIEkgcXVvdGUgdGhlIGRlZmluaXRpb24gaGVyZSBhZ2FpbjoNCg0K Z3JhbnQNCiAgICBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBh dXRob3JpemF0aW9uDQoNCmdyYW50X3R5cGUNCnR5cGUgb2YgZ3JhbnQgc2VudCB0byB0aGUgdG9r ZW4gZW5kcG9pbnQgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW4NCg0KSXQgaXMgbm90IGFib3V0 IGNvbnRyb2xsaW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUgdG9rZW4gZW5kcG9p bnQsIGJ1dCB0aGUgaGludCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgZGVzY3JpYmluZyB0aGUgdHlw ZSBvZiBjcmVkZW50aWFsIHRoZSBlbmRwb2ludCBoYXMgcmVjZWl2ZWQuIEl0IHNlZW1zIHRoZSAi Y29udHJvbCBvZiB3aGF0IGlzIGJlaW5nIHJldHVybmVkIGZyb20gdG9rZW4gZW5kcG9pbnQiICBp cyBqdXN0IGEgc2lkZSBlZmZlY3QuDQoNCkkgYW0gc29tZXdoYXQgYW1iaXZhbGVudFsxXSBpbiBj aGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mIHRva2VuIGVuZHBvaW50LCBidXQgaW4gYXMgbXVjaCBh cyAidGV4dCBpcyB0aGUga2luZyIgZm9yIGEgc3BlYy4sIHdlIHByb2JhYmx5IHNob3VsZCBub3Qg Y2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgaXQgYXMgVG9yc3RlbiBwb2ludHMgb3V0LiBJZiBpdCBp cyBvayB0byBjaGFuZ2UgdGhpcyBzZW1hbnRpY3MsIEkgYmVsaWV2ZSBkZWZpbmluZyBhIG5ldyBw YXJhbWV0ZXIgdG8gdGhpcyBlbmRwb2ludCB0byBjb250cm9sIHRoZSByZXNwb25zZSB3b3VsZCBi ZSB0aGUgYmVzdCB3YXkgdG8gZ28uIFRoaXMgaXMgd2hhdCBJIGhhdmUgZGVzY3JpYmVkIHByZXZp b3VzbHkuDQoNCkRlZmluaW5nIGEgbmV3IGVuZHBvaW50IHRvIHNlbmQgY29kZSB0byBnZXQgSUQg VG9rZW4gYW5kIGZvcmJpZGRpbmcgdGhlIHVzZSBvZiBpdCBhZ2FpbnN0IHRva2VuIGVuZHBvaW50 IHdvdWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBhbnkgZXhpc3RpbmcgcGFyYW1ldGVy IG9yIGVuZHBvaW50LCB3aGljaCBpcyBnb29kLiBIb3dldmVyLCBJIGRvdWJ0IGlmIGl0IGlzIG5v dCB3b3J0aCBkb2luZy4gV2hhdCdzIHRoZSBwb2ludCBvZiBhdm9pZGluZyBhY2Nlc3MgdG9rZW4g c2NvcGVkIHRvIFVzZXJJbmZvIGVuZHBvaW50IGFmdGVyIGFsbD8gRGVmaW5pbmcgYSBuZXcgZW5k cG9pbnQgZm9yIGp1c3QgYXZvaWRpbmcgdGhlIGFjY2VzcyB0b2tlbiBmb3IgdXNlcmluZm8gZW5k cG9pbnQgc2VlbXMgd2F5IHRvbyBtdWNoIHRoZSBoZWF2eSB3YWl0IHdheSBhbmQgaXQgYnJlYWtz IGludGVyb3BlcmFiaWxpeTogaXQgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBzdGFuZGFyZGl6YXRp b24uDQoNCkkgaGF2ZSBzdGFydGVkIGZlZWxpbmcgdGhhdCBubyBjaGFuZ2UgaXMgdGhlIGJlc3Qg d2F5IG91dC4NCg0KTmF0DQoNClsxXSAgSWYgaW5zdGVhZCBvZiBzYXlpbmcgIlRva2VuIGVuZHBv aW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gZ3Jh bnQgZm9yIGFuIGFjY2VzcyB0b2tlbiwgdHlwaWNhbGx5IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0 aW9uIiwgaXQgd2VyZSBzYXlpbmcgIlRva2VuIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgY2xpZW50 IHRvIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgZm9yIHRva2VucywgdHlwaWNhbGx5 IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0aW9uIiwgdGhlbiBpdCB3b3VsZCBoYXZlIGJlZW4gT0su IEl0IGlzIGFuIGV4cGFuc2lvbiBvZiB0aGUgY2FwYWJpbGl0eSByYXRoZXIgdGhhbiBjaGFuZ2lu ZyB0aGUgc2VtYW50aWNzLg0KDQoNCjIwMTQtMDctMjMgMTM6MzkgR01ULTA0OjAwIE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPj46DQpZb3UgbmVlZCB0aGUgYWx0ZXJuYXRpdmUgcmVzcG9uc2VfdHlwZSB2YWx1 ZSAoImNvZGVfZm9yX2lkX3Rva2VuIiBpbiB0aGUgQTRDIGRyYWZ0KSB0byB0ZWxsIHRoZSBBdXRo b3JpemF0aW9uIFNlcnZlciB0byByZXR1cm4gYSBjb2RlIHRvIGJlIHVzZWQgd2l0aCB0aGUgbmV3 IGdyYW50IHR5cGUsIHJhdGhlciB0aGFuIG9uZSB0byB1c2Ugd2l0aCB0aGUgImF1dGhvcml6YXRp b25fY29kZSIgZ3JhbnQgdHlwZSAod2hpY2ggaXMgd2hhdCByZXNwb25zZV90eXBlPWNvZGUgZG9l cykuDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNClNlbnQ6 IFdlZG5lc2RheSwgSnVseSAyMywgMjAxNCAxMDozMyBBTQ0KVG86IHRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4NCg0KQ2M6IG9hdXRoQGlldGYu b3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50 eHQNCg0KDQpJZiB3ZSB1c2UgdGhlIHRva2VuIGVuZHBvaW50IHRoZW4gYSBuZXcgZ3JhbnRfdHlw ZSBpcyB0aGUgYmVzdCB3YXkuDQoNCkl0IHNvcnQgb2Ygb3ZlcmxvYWRzIGNvZGUsIGJ1dCB0aGF0 IGlzIGJldHRlciB0aGFuIG1lc3Npbmcgd2l0aCByZXNwb25zZV90eXBlIGZvciB0aGUgYXV0aG9y aXphdGlvbiBlbmRwb2ludCB0byBjaGFuZ2UgdGhlIHJlc3BvbnNlIGZyb20gdGhlIHRva2VuX2Vu ZHBvaW50LiAgVGhhdCBpcyBpbiBteSBvcGluaW9uIGEgY2hhbXBpb24gYmFkIGlkZWEuDQoNCklu IGRpc2N1c3Npb25zIGRldmVsb3BpbmcgQ29ubmVjdCB3ZSBkZWNpZGVkIG5vdCB0byBvcGVuIHRo aXMgY2FuIG9mIHdvcm1zIGJlY2F1c2Ugbm8gZ29vZCB3b3VsZCBjb21lIG9mIGl0Lg0KDQpUaGUg dG9rZW5fZW5kcG9pbnQgcmV0dXJucyBhIGFjY2VzcyB0b2tlbi4gIE5vdGhpbmcgcmVxdWlyZXMg c2NvcGUgdG8gYmUgYXNzb2NpYXRlcyB3aXRoIHRoZSB0b2tlbi4NCg0KVGhhdCBpcyB0aGUgYmVz dCBzb2x1dGlvbi4gIE5vIGNoYW5nZSByZXF1aXJlZC4gIEJldHRlciBpbnRlcm9wZXJhYmlsaXR5 IGluIG15IG9waW5pb24uDQoNClN0aWxsIG9uIG15IHdheSB0byBUTywgZ2V0dGluZyBpbiBsYXRl ciB0b2RheS4NCg0KSm9obiBCLg0KDQoNCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiBKdWwg MjMsIDIwMTQsIGF0IDEyOjE1IFBNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KDQpUaGUgInJlc3BvbnNlIHR5cGUiIG9mIHRo ZSB0b2tlbiBlbmRwb2ludCBpcyBjb250cm9sbGVkIGJ5IHRoZSB2YWx1ZSBvZiB0aGUgcGFyYW1l dGVyICJncmFudF90eXBlIi4gU28gdGhlcmUgaXMgbm8gbmVlZCB0byBpbnRyb2R1Y2UgYSBuZXcg cGFyYW1ldGVyLg0KDQp3cnQgdG8gYSBwb3RlbnRpYWwgIm5vX2FjY2Vzc190b2tlbiIgZ3JhbnQg dHlwZS4gSSBkbyBub3QgY29uc2lkZXIgdGhpcyBhIGdvb2QgaWRlYSBhcyBpdCBjaGFuZ2VzIHRo ZSBzZW1hbnRpY3Mgb2YgdGhlIHRva2VuIGVuZHBvaW50IChhcyBhbHJlYWR5IHBvaW50ZWQgb3V0 IGJ5IFRob21hcykuIFRoaXMgZW5kcG9pbnQgQUxXQVlTIHJlc3BvbmRzIHdpdGggYW4gYWNjZXNz IHRva2VuIHRvIGFueSBncmFudCB0eXBlLiBJIHRoZXJlZm9yZSB3b3VsZCBwcmVmZXIgdG8gdXNl IGFub3RoZXIgZW5kcG9pbnQgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlLg0KDQpyZWdhcmRzLA0K VG9yc3Rlbi4NCg0KDQpBbSAyMy4wNy4yMDE0IDEzOjA0LCBzY2hyaWViIE5hdCBTYWtpbXVyYToN CklNSE8sIGNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgInJlc3BvbnNlX3R5cGUiIEAgYXV0aHog ZW5kcG9pbnQgdGhpcyB3YXkgaXMgbm90IGEgZ29vZCB0aGluZy4NCg0KSW5zdGVhZCwgZGVmaW5p bmcgYSBuZXcgcGFyYW1ldGVyICJyZXNwb25zZV90eXBlIiBAIHRva2VuIGVuZHBvaW50LCBhcyBJ IGRlc2NyaWJlZCBpbiBteSBwcmV2aW91cyBtZXNzYWdlLA0KcHJvYmFibHkgaXMgYmV0dGVyLiBB dCBsZWFzdCwgaXQgZG9lcyBub3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHBhcmFtZXRl cnMgb2YgUkZDNjc0OS4NCg0KIE5hdA0KDQoyMDE0LTA3LTIzIDEyOjQ4IEdNVC0wNDowMCBUaG9t YXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+ Og0KTm8sIEkgbWVhbiByZXNwb25zZV90eXBlPW5vbmUgYW5kIHJlc3BvbnNlX3R5cGU9aWRfdG9r ZW4gZG9uJ3QgZ2VuZXJhdGUgYSBjb2RlIG9yIGFjY2VzcyB0b2tlbiBzbyB5b3UgZG9uJ3QgdXNl IHRoZSBUb2tlbiBFbmRwb2ludCAod2hpY2ggaXMgbm90IHRoZSBzYW1lIGFzIHRoZSBBdXRoZW50 aWNhdGlvbiBFbmRwb2ludCBCVFcpLg0KV2l0aCByZXNwb25zZV90eXBlPWNvZGVfZm9yX2lkX3Rv a2VuLCB5b3UgZ2V0IGEgY29kZSBhbmQgZXhjaGFuZ2UgaXQgZm9yIGFuIGlkX3Rva2VuIG9ubHks IHJhdGhlciB0aGFuIGFuIGFjY2Vzc190b2tlbiwgc28geW91J3JlIGNoYW5naW5nIHRoZSBzZW1h bnRpY3Mgb2YgdGhlIFRva2VuIEVuZHBvaW50Lg0KDQpJJ20gbm90IHNheWluZyBpdCdzIGEgYmFk IHRoaW5nLCBqdXN0IHRoYXQgeW91IGNhbid0IHJlYWxseSBjb21wYXJlIG5vbmUgYW5kIGlkX3Rv a2VuIHdpdGggY29kZV9mb3JfaWRfdG9rZW4uDQoNCk9uIFdlZCwgSnVsIDIzLCAyMDE0IGF0IDY6 NDUgUE0sIFJpY2hlciwgSnVzdGluIFAuIDxqcmljaGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hl ckBtaXRyZS5vcmc+PiB3cm90ZToNCkl0J3Mgb25seSAibm90IHVzaW5nIHRoZSB0b2tlbiBlbmRw b2ludCIgYmVjYXVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgY29weS1wYXN0ZWQgYW5kIHJlbmFtZWQg dGhlIGF1dGhlbnRpY2F0aW9uIGVuZHBvaW50Lg0KDQogLS0gSnVzdGluDQoNCk9uIEp1bCAyMywg MjAxNCwgYXQgOTozMCBBTSwgVGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPG1haWx0 bzp0LmJyb3llckBnbWFpbC5jb20+PiB3cm90ZToNCg0KRXhjZXB0IHRoYXQgdGhlc2UgYXJlIGFi b3V0IG5vdCB1c2luZyB0aGUgVG9rZW4gRW5kcG9pbnQgYXQgYWxsLCB3aGVyZWFzIHRoZSBjdXJy ZW50IHByb3Bvc2FsIGlzIGFib3V0IHRoZSBUb2tlbiBFbmRwb2ludCBub3QgcmV0dXJuaW5nIGFu IGFjY2Vzc190b2tlbiBmaWVsZCBpbiB0aGUgSlNPTi4NCg0KT24gV2VkLCBKdWwgMjMsIDIwMTQg YXQgNDoyNiBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0 bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRoZSByZXNwb25zZV90eXBl ICJub25lIiBpcyBhbHJlYWR5IHVzZWQgaW4gcHJhY3RpY2UsIHdoaWNoIHJldHVybnMgbm8gYWNj ZXNzIHRva2VuLiAgSXQgd2FzIGFjY2VwdGVkIGJ5IHRoZSBkZXNpZ25hdGVkIGV4cGVydHMgYW5k IHJlZ2lzdGVyZWQgaW4gdGhlIElBTkEgT0F1dGggQXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNw b25zZSBUeXBlcyByZWdpc3RyeSBhdCBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29h dXRoLXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54bWwjZW5kcG9pbnQuICBUaGUgcmVnaXN0 ZXJlZCAiaWRfdG9rZW4iIHJlc3BvbnNlIHR5cGUgYWxzbyByZXR1cm5zIG5vIGFjY2VzcyB0b2tl bi4NCg0KU28gSSB0aGluayB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciByZXNwb25zZSB0eXBlcyB0 aGF0IHJlc3VsdCBpbiBubyBhY2Nlc3MgdG9rZW4gYmVpbmcgcmV0dXJuZWQgYXJlIGFjY2VwdGFi bGUgd2l0aGluIE9BdXRoIDIuMCBpcyBhbHJlYWR5IHNldHRsZWQsIGFzIGEgcHJhY3RpY2FsIG1h dHRlci4gIExvdHMgb2YgT0F1dGggaW1wbGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IHVzaW5nIHN1 Y2ggcmVzcG9uc2UgdHlwZXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0gT24g QmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDc6MDkg QU0NClRvOiBOYXQgU2FraW11cmENCkNjOiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGll dGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQNCg0KWWVzLiBUaGlzIGlz IHdoeSBpdCBoYXMgdG8gYmUgZGlzY3Vzc2VkIGluIHRoZSBJRVRGLg0KDQpQaGlsDQoNCkBpbmRl cGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlk LmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+ DQoNCg0KDQpPbiBKdWwgMjMsIDIwMTQsIGF0IDk6NDMgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11 cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCg0KUmVhZGlu ZyBiYWNrIHRoZSBSRkM2NzQ5LCBJIGFtIG5vdCBzdXJlIGlmIHRoZXJlIGlzIGEgZ29vZCB3YXkg b2Ygc3VwcHJlc3NpbmcgYWNjZXNzIHRva2VuIGZyb20gdGhlIHJlc3BvbnNlIGFuZCBzdGlsbCBi ZSBPQXV0aC4gSXQgd2lsbCBicmVhayB3aG9sZSBidW5jaCBvZiBpbXBsaWNpdCBkZWZpbml0aW9u cyBsaWtlOg0KDQphdXRob3JpemF0aW9uIHNlcnZlcg0KICAgICAgVGhlIHNlcnZlciBpc3N1aW5n IGFjY2VzcyB0b2tlbnMgdG8gdGhlIGNsaWVudCBhZnRlciBzdWNjZXNzZnVsbHkNCiAgICAgIGF1 dGhlbnRpY2F0aW5nIHRoZSByZXNvdXJjZSBvd25lciBhbmQgb2J0YWluaW5nIGF1dGhvcml6YXRp b24uDQoNCkFmdGVyIGFsbCwgT0F1dGggaXMgYWxsIGFib3V0IGlzc3VpbmcgYWNjZXNzIHRva2Vu cy4NCg0KQWxzbywgSSB0YWtlIGJhY2sgbXkgc3RhdGVtZW50IG9uIHRoZSBncmFudCB0eXBlIGlu IG15IHByZXZpb3VzIG1haWwuDQoNClRoZSBkZWZpbml0aW9uIG9mIGdyYW50IGFuZCBncmFudF90 eXBlIGFyZSByZXNwZWN0aXZlbHk6DQoNCmdyYW50DQogICAgY3JlZGVudGlhbCByZXByZXNlbnRp bmcgdGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbg0KDQpncmFudF90eXBlDQogICAg KHN0cmluZyByZXByZXNlbnRpbmcgdGhlKSB0eXBlIG9mIGdyYW50IHNlbnQgdG8gdGhlIHRva2Vu IGVuZHBvaW50IHRvIG9idGFpbiB0aGUgYWNjZXNzIHRva2VuDQoNClRodXMsIHRoZSBncmFudCBz ZW50IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBpbiB0aGlzIGNhc2UgaXMgc3RpbGwgJ2NvZGUnLg0K DQpSZXNwb25zZSB0eXBlIG9uIHRoZSBvdGhlciBoYW5kIGlzIG5vdCBzbyB3ZWxsIGRlZmluZWQg aW4gUkZDNjc0OSwgYnV0IGl0IHNlZW1zIGl0IGlzIHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJl IHJldHVybmVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRvIGV4cHJlc3Mgd2hh dCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRva2VuIGVuZHBvaW50LCBwZXJoYXBzIGRlZmluaW5n IGEgbmV3IHBhcmFtZXRlciB0byB0aGUgdG9rZW4gZW5kcG9pbnQsIHdoaWNoIGlzIGEgcGFyYWxs ZWwgdG8gdGhlIHJlc3BvbnNlX3R5cGUgdG8gdGhlIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgc2Vl bXMgdG8gYmUgYSBtb3JlIHN5bW1ldHJpYyB3YXksIHRob3VnaCBJIGFtIG5vdCBzdXJlIGF0IGFs bCBpZiB0aGF0IGlzIGdvaW5nIHRvIGJlIE9BdXRoIGFueSBtb3JlLiBPbmUgc3RyYXctbWFuIGlz IHRvIGRlZmluZSBhIG5ldyBwYXJhbWV0ZXIgY2FsbGVkIHJlc3BvbnNlX3R5cGUgdG8gdGhlIHRv a2VuIGVuZHBvaW50IHN1Y2ggYXM6DQoNCnJlc3BvbnNlX3R5cGUNCiAgICBPUFRJT05BTC4gQSBz dHJpbmcgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUgdG9rZW4g ZW5kcG9pbnQuDQoNClRoZW4gZGVmaW5lIHRoZSBiZWhhdmlvciBvZiB0aGUgZW5kcG9pbnQgYWNj b3JkaW5nIHRvIHRoZSB2YWx1ZXMgYXMgdGhlIHBhcmFsbGVsIHRvIHRoZSBtdWx0aS1yZXNwb25z ZSB0eXBlIHNwZWMuDQpodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC12Mi1tdWx0aXBsZS1y ZXNwb25zZS10eXBlcy0xXzAuaHRtbA0KDQpOYXQNCg0KDQoNCg0KMjAxNC0wNy0yMyA3OjIxIEdN VC0wNDowMCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbT4+Og0KVGhlIGRyYWZ0IGlzIHZlcnkgY2xlYXIuDQoNClBoaWwNCg0KT24gSnVs IDIzLCAyMDE0LCBhdCAwOjQ2LCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWls dG86c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQpUaGUgbmV3IGdyYW50IHR5cGUgdGhhdCBJ IHdhcyB0YWxraW5nIGFib3V0IHdhcw0KImF1dGhvcml6YXRpb25fY29kZV9idXRfZG9fbm90X3Jl dHVybl9hY2Nlc3Nfbm9yX3JlZnJlc2hfdG9rZW4iLCBzbyB0byBzcGVhay4NCkl0IGRvZXMgbm90 IHJldHVybiBhbnl0aGluZyBwZXIgc2UsIGJ1dCBhbiBleHRlbnNpb24gY2FuIGRlZmluZSBzb21l dGhpbmcgb24gdG9wIG9mIGl0Lg0KDQpUaGVuLCBPSURDIGNhbiBkZWZpbmUgYSBiaW5kaW5nIHRv IGl0IHNvIHRoYXQgdGhlIGJpbmRpbmcgb25seSByZXR1cm5zIElEIFRva2VuLg0KVGhpcyBiaW5k aW5nIHdvcmsgc2hvdWxkIGJlIGRvbmUgaW4gT0lERi4gU2hvdWxkIHRoZXJlIGJlIHN1Y2ggYSBn cmFudCB0eXBlLA0KaXQgd2lsbCBiZSBhbiBleHRyZW1lbHkgc2hvcnQgc3BlYy4NCg0KQXQgdGhl IHNhbWUgdGltZSwgaWYgYW55IG90aGVyIHNwZWNpZmljYXRpb24gd2FudGVkIHRvIGRlZmluZQ0K b3RoZXIgdHlwZSBvZiB0b2tlbnMgYW5kIGhhdmUgaXQgcmV0dXJuZWQgZnJvbSB0aGUgdG9rZW4g ZW5kcG9pbnQsDQppdCBjYW4gYWxzbyB1c2UgdGhpcyBncmFudCB0eXBlLg0KDQpJZiB3aGF0IHlv dSB3YW50IGlzIHRvIGRlZmluZSBhIG5ldyBncmFudCB0eXBlIHRoYXQgcmV0dXJucyBJRCBUb2tl biBvbmx5LA0KdGhlbiwgSSBhbSB3aXRoIEp1c3Rpbi4gU2luY2UgIm90aGVyIHJlc3BvbnNlIHRo YW4gSUQgVG9rZW4iIGlzIG9ubHkNCnRoZW9yZXRpY2FsLCB0aGlzIGlzIGEgbW9yZSBwbGF1c2li bGUgd2F5IGZvcndhcmQsIEkgc3VwcG9zZS4NCg0KTmF0DQoNCjIwMTQtMDctMjIgMTQ6MzAgR01U LTA0OjAwIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQu ZWR1Pj46DQpTbyB0aGUgZHJhZnQgd291bGQgbGl0ZXJhbGx5IHR1cm4gaW50bzoNCg0KIlRoZSBh NGMgcmVzcG9uc2UgdHlwZSBhbmQgZ3JhbnQgdHlwZSByZXR1cm4gYW4gaWRfdG9rZW4gZnJvbSB0 aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCBubyBhY2Nlc3MgdG9rZW4uIEFsbCBwYXJhbWV0ZXJzIGFu ZCB2YWx1ZXMgYXJlIGRlZmluZWQgaW4gT0lEQy4iDQoNClNlZW1zIGxpa2UgdGhlIHBlcmZlY3Qg bWluaSBleHRlbnNpb24gZHJhZnQgZm9yIE9JREYgdG8gZG8uDQoNCi0tSnVzdGluDQoNCi9zZW50 IGZyb20gbXkgcGhvbmUvDQoNCk9uIEp1bCAyMiwgMjAxNCAxMDoyOSBBTSwgTmF0IFNha2ltdXJh IDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0K Pg0KPiBXaGF0IGFib3V0IGp1c3QgZGVmaW5pbmcgYSBuZXcgZ3JhbnQgdHlwZSBpbiB0aGlzIFdH Pw0KPg0KPg0KPiAyMDE0LTA3LTIyIDEyOjU2IEdNVC0wNDowMCBQaGlsIEh1bnQgPHBoaWwuaHVu dEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+Og0KPj4NCj4+IFRoYXQg d291bGQgYmUgbmljZS4gSG93ZXZlciBvaWRjIHN0aWxsIG5lZWRzIHRoZSBuZXcgZ3JhbnQgdHlw ZSBpbiBvcmRlciB0byBpbXBsZW1lbnQgdGhlIHNhbWUgZmxvdy4NCj4+DQo+PiBQaGlsDQo+Pg0K Pj4gT24gSnVsIDIyLCAyMDE0LCBhdCAxMTozNSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFp bC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4NCj4+PiArMSB0byBK dXN0aW4uDQo+Pj4NCj4+Pg0KPj4+IDIwMTQtMDctMjIgOTo1NCBHTVQtMDQ6MDAgUmljaGVyLCBK dXN0aW4gUC4gPGpyaWNoZXJAbWl0cmUub3JnPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+Og0K Pj4+Pg0KPj4+PiBFcnJvcnMgbGlrZSB0aGVzZSBtYWtlIGl0IGNsZWFyIHRvIG1lIHRoYXQgaXQg d291bGQgbWFrZSBtdWNoIG1vcmUgc2Vuc2UgdG8gZGV2ZWxvcCB0aGlzIGRvY3VtZW50IGluIHRo ZSBPcGVuSUQgRm91bmRhdGlvbi4gSXQgc2hvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGRpcmVjdGx5 IHJlZmVyZW5jZXMgT3BlbklEIENvbm5lY3QgQ29yZSBmb3IgYWxsIG9mIHRoZXNlIHRlcm1zIGlu c3RlYWQgb2YgcmVkZWZpbmluZyB0aGVtLiBJdCdzIGRvaW5nIGF1dGhlbnRpY2F0aW9uLCB3aGlj aCBpcyBmdW5kYW1lbnRhbGx5IHdoYXQgT3BlbklEIENvbm5lY3QgZG9lcyBvbiB0b3Agb2YgT0F1 dGgsIGFuZCBJIGRvbid0IHNlZSBhIGdvb2QgYXJndW1lbnQgZm9yIGRvaW5nIHRoaXMgd29yayBp biB0aGlzIHdvcmtpbmcgZ3JvdXAuDQo+Pj4+DQo+Pj4+ICAtLSBKdXN0aW4NCj4+Pj4NCj4+Pj4g T24gSnVsIDIyLCAyMDE0LCBhdCA0OjMwIEFNLCBUaG9tYXMgQnJveWVyIDx0LmJyb3llckBnbWFp bC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+Pg0KPj4+Pj4NCj4+ Pj4+DQo+Pj4+Pg0KPj4+Pj4gT24gTW9uLCBKdWwgMjEsIDIwMTQgYXQgMTE6NTIgUE0sIE1pa2Ug Sm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPj4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+PiBUaGFua3MgZm9yIHlvdXIgcmV2 aWV3LCBUaG9tYXMuICBUaGUgInByb21wdD1jb25zZW50IiBkZWZpbml0aW9uIGJlaW5nIG1pc3Np bmcgaXMgYW4gZWRpdG9yaWFsIGVycm9yLiAgSXQgc2hvdWxkIGJlOg0KPj4+Pj4+DQo+Pj4+Pj4N Cj4+Pj4+Pg0KPj4+Pj4+IGNvbnNlbnQNCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBBdXRob3JpemF0aW9u IFNlcnZlciBTSE9VTEQgcHJvbXB0IHRoZSBFbmQtVXNlciBmb3IgY29uc2VudCBiZWZvcmUgcmV0 dXJuaW5nIGluZm9ybWF0aW9uIHRvIHRoZSBDbGllbnQuIElmIGl0IGNhbm5vdCBvYnRhaW4gY29u c2VudCwgaXQgTVVTVCByZXR1cm4gYW4gZXJyb3IsIHR5cGljYWxseSBjb25zZW50X3JlcXVpcmVk Lg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEknbGwgcGxhbiB0byBhZGQgaXQgaW4g dGhlIG5leHQgZHJhZnQuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IEl0IGxvb2tzIGxpa2UgdGhlIGNv bnNlbnRfcmVxdWlyZWQgZXJyb3IgbmVlZHMgdG8gYmUgZGVmaW5lZCB0b28sIGFuZCB5b3UgbWln aHQgaGF2ZSBmb3Jnb3R0ZW4gdG8gYWxzbyBpbXBvcnQgYWNjb3VudF9zZWxlY3Rpb25fcmVxdWly ZWQgZnJvbSBPcGVuSUQgQ29ubmVjdC4NCj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+ Pj4+Pj4gSSBhZ3JlZSB0aGF0IHRoZXJlJ3Mgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIGEgcmVzcG9u c2Ugd2l0aCBtdWx0aXBsZSAiYW1yIiB2YWx1ZXMgdGhhdCBpbmNsdWRlcyAibWZhIiBhbmQgb25l IHRoYXQgZG9lc24ndC4gIFVubGVzcyBhIGNsZWFyIHVzZSBjYXNlIGZvciB3aHkgIm1mYSIgaXMg bmVlZGVkIGNhbiBiZSBpZGVudGlmaWVkLCB3ZSBjYW4gZGVsZXRlIGl0IGluIHRoZSBuZXh0IGRy YWZ0Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MuDQo+Pj4+Pg0KPj4+Pj4gSG93IGFib3V0 ICJwd2QiIHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IEkgc2hvdWxkIHJldHVybiAicHdk IiBpZiB0aGUgdXNlciBhdXRoZW50aWNhdGVkIHVzaW5nIGEgcGFzc3dvcmQsIGJ1dCB3aGF0ICJ0 aGUgc2VydmljZSBpZiBhIGNsaWVudCBzZWNyZXQgaXMgdXNlZCIgbWVhbnMgaW4gdGhlIGRlZmlu aXRpb24gZm9yIHRoZSAicHdkIiB2YWx1ZT8NCj4+Pj4+DQo+Pj4+PiAoTm90YTogSSBrbm93IHlv dSdyZSBhdCBJRVRGLTkwLCBJJ20gcmVhZHkgdG8gd2FpdCAndGlsIHlvdSBjb21lIGJhY2sgOy0p ICkNCj4+Pj4+DQo+Pj4+PiAtLQ0KPj4+Pj4gVGhvbWFzIEJyb3llcg0KPj4+Pj4gL3TJlC5tYS5i yoF3YS5qZS88aHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvPg0KPj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IE9BdXRoIG1h aWxpbmcgbGlzdA0KPj4+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+Pg0K Pj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFp bHRvOk9BdXRoQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQo+Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0NCj4+PiBOYXQgU2FraW11 cmEgKD1uYXQpDQo+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQo+Pj4gaHR0cDovL25h dC5zYWtpbXVyYS5vcmcvDQo+Pj4gQF9uYXRfZW4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4NCj4NCj4NCj4gLS0NCj4gTmF0 IFNha2ltdXJhICg9bmF0KQ0KPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCj4gaHR0cDov L25hdC5zYWtpbXVyYS5vcmcvDQo+IEBfbmF0X2VuDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9 bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9y Zy8NCkBfbmF0X2VuDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9w ZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KLS0NClRob21hcyBC cm95ZXINCi90yZQubWEuYsqBd2EuamUvPGh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhiLmpl Lz4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpUaG9t YXMgQnJveWVyDQovdMmULm1hLmLKgXdhLmplLzxodHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4 Yi5qZS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0t DQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHA6 Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhA aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFp bHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQot LQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRw Oi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwg T3BlbklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZv dW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz dA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQo= --_000_a3cec5f516f74c8c879dfd623ba71168BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PaCB5ZWEsIHJlYWwgZGlmZmVyZW50LCBnaXZl IG1lIGEgZnJlYWtpbmcgYnJlYWs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQnJpYW4gQ2FtcGJlbGwgW21h aWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgSnVseSAyNCwgMjAxNCA2OjMxIFBNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFs aW48YnI+DQo8Yj5DYzo8L2I+IEpvaG4gQnJhZGxleTsgb2F1dGhAaWV0Zi5vcmcgbGlzdDxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNpdHVhdGlvbnMgYXJlIHJhdGhlciBkaWZmZXJlbnQu IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAyNCwgMjAxNCBhdCAxMToyNSBBTSwgQW50 aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIiB0 YXJnZXQ9Il9ibGFuayI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PTUcsIGhvdyBj YW4geW91IHNheSB0aGF0IHdoZW4gdGhlIER5bmFta2MgUmVnIGRvZXMgdGhlIHNhbWUgdGhpbmcg KGR1cGxpY2F0ZXMpIGJ1dCB0aGF0IGlzIE9LIHRvDQogZG88L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9IjE0NzY5Njg0MmRmODk2NjdfX01haWxF bmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgSnVseSAyNCwgMjAxNCAxMDoyMiBBTTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gQnJhZGxleTxi cj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+IGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVU SC1XR10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LW9hdXRoLXYyLXVz ZXItYTRjLTA1LnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbSBzb3JyeSB0byBtaXNzIHdoYXQgd2lsbCBsaWtlbHkg YmUgYSB2ZXJ5IGVuZ2FnaW5nIG1lZXRpbmcgdG9kYXkuPGJyPg0KPGJyPg0KVGhlIHByZW1pc2Ug dGhhdCBzb21lIGRldmVsb3BlcnMgYXJlIHVzaW5nIE9BdXRoIGluIGEgaW5zZWN1cmUgd2F5IHRv IGRvIGF1dGhlbnRpY2F0aW9uIGlzIHNvbWV0aGluZyB3ZSBjYW4gcHJvYmFibHkgYWxsIGFncmVl IG9uLg0KPGJyPg0KPGJyPg0KSXQgZG9lc24ndCBuZWNlc3NhcmlseSBmb2xsb3cgZnJvbSB0aGF0 IHByZW1pc2UsIGhvd2V2ZXIsIHRoYXQgdGhlIHNvbHV0aW9uIGlzIHlldCBhbm90aGVyIHNwZWMg d2hpY2ggZWl0aGVyIGR1cGxpY2F0ZXMgc29tZSBzdWJzZXQgb2YgT3BlbklEIENvbm5lY3QgKGlu IGEgZGlmZmVyZW50IFNETykgb3IgZm9ya3MgaG93IHRvIGRvIFNTTy9hdXRoZW50aWNhdGlvbiB1 c2luZyBPQXV0aC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIFRodSwgSnVsIDI0LCAyMDE0IGF0IDc6MjUgQU0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0 Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSBhbSBub3QgYWdhaW5zdCBkaXNjdXNzaW9uIGluIHRoZSBXRy48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhhcHBlbiB0byBhZ3JlZSB3aXRo IFBoaWwncyBmdW5kYW1lbnRhbCBwcmVtaXNlIHRoYXQgc29tZSBkZXZlbG9wZXJzIGFyZSB1c2lu ZyBPQXV0aCBpbiBhIGluc2VjdXJlIHdheSB0byBkbyBhdXRoZW50aWNhdGlvbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYXQgcmFp c2VzIHRoZSBxdWVzdGlvbiBvZiBob3cgdG8gYmVzdCBlZHVjYXRlIHRoZW0sIGFuZCBvciBhZGRy ZXNzIHRlY2huaWNhbCBiYXJyaWVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGlzIG9uIHRoZSBzZWNvbmQgcG9pbnQgdGhhdCBw ZW9wbGUncyBvcGluaW9ucyBzZWVtIHRvIGRpdmlkZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvbWUgcGVvcGxlIHRoaW5nIHRoYXQg aWYgd2UgaGF2ZSBhIE9BdXRoIGZsb3cgdGhhdCBlbGltaW5hdGVzIHRoZSBhY2Nlc3MgdG9rZW4g KHByaW1hcmlseSB0byBhdm9pZCBhc2tpbmcgZm9yIGNvbnNlbnQgYXMgSSB1bmRlcnN0YW5kIGl0 KSBhbmQganVzdCByZXR1cm4gYSBpZF90b2tlbiBmcm9tIHRoZSB0b2tlbg0KIGVuZHBvaW50IHRo YXQgY2FuIGJlIGRvbmUgaW4gYSBzcGVjIHNob3J0IGVub3VnaCB0byBoZXQgcGVvcGxlIHRvIHJl YWQuICZuYnNwOyBUaGUgc3VidGV4dCBvZiB0aGlzIGlzIHRoYXQgdGhlIENvbm5lY3Qgc3BlY2lm aWNhdGlvbiBpcyB0b28gbGFyZ2UgdGhhdCBpdCBzY2FyZSBwZW9wbGUsICZuYnNwO2FuZCB0aGV5 IGRvbid0IGZpbmQgdGhlIHNwZWMgaW4gdGhlIGZpcnN0IHBsYWNlIGJlY2F1c2UgaXQgaXMgbm90 IGEgUkZDLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+QW4gb3RoZXIgY29tbW9uIHBvc3Nlc3Npb24gaXMgdGhhdCBpZiB5b3UgZG9uJ3Qg d2FudCB0byBwcm9tcHQgdGhlIHVzZXIgZm9yIGNvbnNlbnQgdGhlbiBkb24ndCBhc2sgZm9yIHNj b3Blcy4gJm5ic3A7VHdpc3RpbmcgdGhlIE9BdXRoIHNwZWMgdG8gbm90IHJldHVybiBhbiBhY2Nl c3MgdG9rZW4gaXMgbm90IE9BdXRoLA0KICZuYnNwO3llcyB5b3UgY291bGQgdXNlIGEgZGlmZmVy ZW50IGVuZHBvaW50IHJhdGhlciB0aGFuIHRoZSB0b2tlbiBlbmRwb2ludCwgYnV0IHRoYXQgaXMg bm90IE9BdXRoLiAmbmJzcDsgQ29ubmVjdCB3YXMgY2FyZWZ1bCBub3QgdG8gYnJlYWsgdGhlIE9B dXRoIHNwZWMuICZuYnNwOyAmbmJzcDtBcyBsb25nIGFzIHlvdSBhcmUgd2lsbGluZyB0byB0YWtl IGEgYWNjZXNzIHRva2VuIHdpdGggbm8gc2NvcGVzICh0aGUgY2xpZW50IG5lZWRzIHRvIHVuZGVy c3RhbmQgdGhhdCB0aGVyZQ0KIGFyZSBubyBhdHRyaWJ1dGVzIG9uZSB3YXkgb3IgYW5vdGhlciBh bnl3YXkgb3IgaXQgd2lsbCBicmVhaykgdGhlbiB5b3UgZG9uJ3QgbmVlZCB0byBjaGFuZ2UgT0F1 dGguICZuYnNwOyBZb3UgY2FuIHB1Ymxpc2ggYSBwcm9maWxlIG9mIGNvbm5lY3QgdGhhdCBzYXRp c2ZpZXMgdGhlIHVzZSBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayBNaWtlIGhhcyBsYXJnZWx5IGRvbmUgdGhhdCBi dXQgaXQgbWlnaHQgYmUgYmV0dGVyIGJlaW5nIGxlc3Mgc3Rpbmd5IG9uIHJlZmVyZW5jZXMgYmFj ayB0byB0aGUgbGFyZ2VyIHNwZWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgcXVlc3Rpb25zIGFyZSBkbyB3ZSBtb2RpZnkgT0F1 dGggdG8gbm90IHJldHVybiBhbiBhY2Nlc3MgdG9rZW4sIGFuZCBpZiBzbyBob3csICZuYnNwO2Fu ZCBpZiB3ZSBkbyBpcyBpdCBzdGlsbCBPQXV0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBvdGhlciBsYXJnZWx5IHNlcGFyYWJs ZSBxdWVzdGlvbiBpcyBkbyB3ZSBjcmVhdGUgY29uZnVzaW9uIGluIHRoZSBtYXJrZXQgYW5kIHNs b3cgdGhlIHRoZSBhZG9wdGlvbiBvZiBpZGVudGl0eSBmZWRlcmF0aW9uIG9uIHRvcCBvZiBPQXV0 aCwgb3IgZmluZCBhIHdheSB0byBtYWtlIHRoaXMgbG9vayBsaWtlDQogYSBwb3NpdGl2ZSBhbGln bm1lbnQgb2YgaW50ZXJlc3RzIGFyb3VuZCBhIHN1YnNldCBvZiBDb25uZWN0LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlcmUgYXJl IGEgbnVtYmVyIG9mIG9wdGlvbnMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xOiBXZSBjYW4gZG8gYSBwcm9maWxlIGluIHRoZSBP SURGIGFuZCBwdWJsaXNoIGl0IGFzIGEgSUVURiBkb2N1bWVudC4gJm5ic3A7IFBlcmhhcHMgdGhl IGNsZWFuZXN0IGZyb20gYW4gSVBSIHBvaW50IG9mIHZpZXcuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjI6V2UgY2FuIGRvIGEgcHJvZmlsZSBp biB0aGUgT0F1dGggV0cgcmVmZXJlbmNpbmcgY29ubmVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MzpXZSBjYW4gZG8gYSBBRCBzcG9uc29y ZWQgcHJvZmlsZSB0aGF0IGlzIG5vdCBpbiB0aGUgT0F1dGggV0cuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQ6V2UgY2FuIGRvIGEgc21hbGwg c3BlYyBpbiBPQXV0aCB0byBhZGQgcmVzcG9uc2VfdHlwZSB0byB0aGUgdG9rZW4gZW5kcG9pbnQu ICZuYnNwO2luIGNvbWJpbmF0aW9uIHdpdGggMSwgMiwgb3IgMzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhZ3JlZSB0aGF0IHN0b3Bp bmcgZGV2ZWxvcGVycyBkb2luZyBpbnNlY3VyZSB0aGluZ3MgbmVlZHMgdG8gYmUgYWRkcmVzc2Vk IHNvbWVob3cuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JIGFtIG5vdCBwZXJzb25hbGx5IGNvbnZpbmNlZCB0aGF0IE9hdXRoIHdp dGhvdXQgYWNjZXNzIHRva2VucyBpcyBzZW5zaWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkxvb2tpbmcgZm9yd2FyZCB0byB0aGUg bWVldGluZzopPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEp1bCAyNCwgMjAxNCwgYXQgNjo1MiBBTSwgQnJp YW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkknZCBub3RlIHRoYXQg dGhlIHJlYWN0aW9uIGF0IHRoZSBjb25mZXJlbmNlIHRvIElhbidzIHN0YXRlbWVudCB3YXMgb3Zl cndoZWxtaW5nbHkgcG9zaXRpdmUuIFRoZXJlIHdhcyBhIHdpZGUgcmFuZ2Ugb2YgaW5kdXN0cnkg cGVvcGxlIGhlcmUgLSBpbXBsZW1lbnRlcnMsIHByYWN0aXRpb25lcnMsIGRlcGxveWVycywNCiBz dHJhdGVnaXN0cywgZXRjLiAtIGFuZCBpdCBzZWVtcyBwcmV0dHkgY2xlYXIgdGhhdCB0aGUgJnF1 b3Q7cm91Z2ggY29uc2Vuc3VzJnF1b3Q7IG9mIHRoZSBpbmR1c3RyeSBhdCBsYXJnZSBpcyB0aGF0 IGE0YyBpcyBub3Qgd2FudGVkIG9yIG5lZWRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEp1bCAyNCwgMjAxNCBhdCA1OjI5IEFNLCBOYXQgU2Fr aW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+QW5kIGhlcmUgaXMgYSBxdW90ZSBmcm9tIElhbidzIGJsb2cu Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZCBhbHRob3VnaCB0 aGUgYXV0aGVudGljYXRpb24gd2hlZWwgaXMgcm91bmQsIHRoYXQgZG9lc27igJl0IG1lYW4gaXQg aXNu4oCZdCB3aXRob3V0IGl0cyBsdW1wcy4gRmlyc3QsIHdlIGRvIHNlZSBzb21lIHJlaW52ZW50 aW5nIHRoZSB3aGVlbCBqdXN0IHRvIHJlaW52ZW50IHRoZSB3aGVlbC4gT0F1dGggQTRDIGlzDQog c2ltcGx5IG5vdCBhIGZydWl0ZnVsIGFjdGl2aXR5IGFuZCBzaG91bGQgYmUgcHV0IGRvd24uICZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4o U291cmNlKQ0KPGEgaHJlZj0iaHR0cDovL3d3dy50dWVzZGF5bmlnaHQub3JnLzIwMTQvMDcvMjMv ZG8td2UtaGF2ZS1hLXJvdW5kLXdoZWVsLXlldC1tdXNpbmdzLW9uLWlkZW50aXR5LXN0YW5kYXJk cy1wYXJ0LTEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy50dWVzZGF5bmlnaHQu b3JnLzIwMTQvMDcvMjMvZG8td2UtaGF2ZS1hLXJvdW5kLXdoZWVsLXlldC1tdXNpbmdzLW9uLWlk ZW50aXR5LXN0YW5kYXJkcy1wYXJ0LTEuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4yMDE0LTA3LTIzIDE2OjUzIEdNVC0w NDowMCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRob3VnaHQgSSBkaWQgcG9zdCB0 aGlzIHRvIHRoZSBsaXN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBndWVzcyBJIGhpdCB0aGUgd3JvbmcgcmVwbHkgb24g bXkgcGhvbmUuJm5ic3A7PGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkpvaG4gQi4mbmJzcDs8YnI+DQpTZW50IGZyb20gbXkg aVBob25lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCk9uIEp1bCAyMywgMjAxNCwgYXQgNDo1MCBQTSwgPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5A bG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+DQp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l dDwvYT4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHA+d2UgYXJlIHR3bywgYXQg bGVhc3QgOi0pPG86cD48L286cD48L3A+DQo8cD5XaHkgZGlkbid0IHlvdSBwb3N0IHRoaXMgb24g dGhlIGxpc3Q/PG86cD48L286cD48L3A+DQo8cD5XaGVuIHdpbGwgYmUgYmUgYXJyaXZpbmc/PG86 cD48L286cD48L3A+DQo8cD5BbSAyMy4wNy4yMDE0IDE2OjM5LCBzY2hyaWViIEpvaG4gQnJhZGxl eTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2lu LWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JYW4gR2xhemVyIG1lbnRpb25lZCB0aGlzIGluIGhp cyBrZXlub3RlIGF0IENJUyB5ZXN0ZXJkYXkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaXMgYWR2aWNlIHdhcyBwbGVhc2Ug c3RvcCwgJm5ic3A7d2UgYXJlIGNyZWF0aW5nIGNvbmZ1c2lvbiBhbmQgdW5jZXJ0YWludHkuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5XZSBhcmUgYmVjb21pbmcgb3VyIG93biB3b3J0IGVuZW15LiAoIG15IHZpZXcgdGhvdWdo IElhbiBtYXkgc2hhcmUgaXQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5SZXR1cm5pbmcganVzdCBhbiBpZF8gdG9rZW4gZnJvbSB0aGUg dG9rZW4gZW5kcG9pbnQgaGFzIGxpdHRsZSByZWFsIHZhbHVlLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U29tZXRoaW5nIHJl YWxseSB1c2VmdWwgdG8gZG8gd291bGQgYmUgc29ydGluZyBvdXQgY2hhbm5lbF9pZCBzbyB3ZSBj YW4gZG8gUG9QIGZvciBpZCB0b2tlbnMgdG8gbWFrZSB0aGVtIGFuZCBvdGhlciBjb29raWVzIHNl Y3VyZSBpbiB0aGUgZnJvbnQgY2hhbm5lbC4gJm5ic3A7IEkgdGhpbmsgdGhhdCBpcyBhIGJldHRl cg0KIHVzZSBvZiB0aW1lLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBtYXkgYmUgaW4gdGhlIG1pbm9yaXR5IG9waW5pb24g b24gdGhhdCwgJm5ic3A7aXQgd29uJ3QgYmUgdGhlIGZpcnN0IHRpbWUuICZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyPg0KSm9obiBC LiZuYnNwOzxicj4NClNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVsIDIzLCAy MDE0LCBhdCA0OjA0IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzEwMTBGRiAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPllvdSBhcmUgcmlnaHQgZnJvbSBhIHRoZW9yZXRpY2FsIHBlcnNwZWN0aXZlLiBQcmFjdGlj YWxseSB0aGlzIHdhcyBjYXVzZWQgYnkgZWRpdG9yaWFsIGRlY2lzaW9ucyBkdXJpbmcgdGhlIGNy ZWF0aW9uIG9mIHRoZSBSRkMuIEFzIGZhciBhcyBJIHJlbWVtYmVyLCB0aGVyZSB3YXMgYSBkZWZp bml0aW9uIG9mDQogdGhlIChvbmUpIHRva2VuIGVuZHBvaW50IHJlc3BvbnNlIGluIGVhcmx5IHZl cnNpb25zLiBObyBvbmUgZXZlcnkgY29uc2lkZXJlZCB0byBOT1QgcmVzcG9uZCB3aXRoIGFuIGFj Y2VzcyB0b2tlbiBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludC4gU28gb25lIG1pZ2h0IGNhbGwgaXQg YW4gaW1wbGljaXQgYXNzdW1wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbSB3b3JyaWVkIHRoYXQgcGVvcGxlIGdldCB0b3Rh bGx5IGNvbmZ1c2VkIGlmIGFuIGV4Y2VwdGlvbiBpcyBpbnRyb2R1Y2VkIG5vdyBnaXZlbiB0aGUg YnJvYWQgYWRvcHRpb24gb2YgT0F1dGggYmFzZWQgb24gdGhpcyBhc3N1bXB0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+cmVnYXJk cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ VG9yc3Rlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KQW0gMjMuMDcuMjAxNCB1bSAxNTo0MSBzY2hyaWViIFRob21hcyBCcm95ZXIgJmx0Ozxh IGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj50LmJyb3ll ckBnbWFpbC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cD5JcyBpdCBzYWlkIGFueXdoZXJlIHRoYXQg QUxMIGdyYW50IHR5cGVzIE1VU1QgdXNlIFNlY3Rpb24gNS4xIHJlc3BvbnNlcz8gRWFjaCBncmFu dCB0eXBlIHJlZmVyZW5jZXMgU2VjdGlvbiA1LjEsIGFuZCAmcXVvdDthY2Nlc3MgdG9rZW4gcmVx dWVzdCZxdW90OyBpcyBvbmx5IGRlZmluZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGRlZmluZWQg Z3JhbnQgdHlwZXMuIFNlY3Rpb24gMi4yIGRvZXNuJ3QgdGFsayBhYm91dCB0aGUgcmVxdWVzdCBv ciByZXNwb25zZQ0KIGZvcm1hdC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkxlIDIzIGp1aWwuIDIwMTQgMjE6MzIsICZxdW90O05hdCBTYWtpbXVyYSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IGEgw6ljcml0IDo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SXMgaXQ/IEFwYXJ0IGZyb20gdGhlIGltcGxpY2l0IGdyYW50 IHRoYXQgZG9lcyBub3QgdXNlIHRva2VuIGVuZHBvaW50LCBhbGwgb3RoZXIgZ3JhbnQgcmVmZXJl bmNlcyBzZWN0aW9uIDUuMSBmb3IgdGhlIHJlc3BvbnNlLCBpLmUuLCBhbGwgc2hhcmVzIHRoZSBz YW1lIHJlc3BvbnNlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjIwMTQtMDctMjMgMTU6MTggR01ULTA0OjAwIFRob21hcyBCcm95ZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj50LmJyb3llckBn bWFpbC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHA+SSBoYWRuJ3QgcmVhbGl6ZWQgdGhlIEpTT04g cmVzcG9uc2UgdGhhdCByZXF1aXJlcyB0aGUgYWNjZXNzX3Rva2VuIGZpZWxkIGlzIGRlZmluZWQg cGVyIGdyYW50X3R5cGUsIHNvIEknZCBiZSBPSyB0byAmcXVvdDtleHRlbmQgdGhlIHNlbWFudGlj cyZxdW90OyBhcyBpbiB0aGUgY3VycmVudCBkcmFmdC48YnI+DQpUaGF0IHdhcyBhY3R1YWxseSBt eSBtYWluIGNvbmNlcm46IHRoYXQgdGhlIHRva2VuIGVuZHBvaW50IG1hbmRhdGVzIGFjY2Vzc190 b2tlbjsgYnV0IGl0cyBhY3R1YWxseSBub3QgdGhlIGNhc2UuPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5MZSAyMyBqdWlsLiAyMDE0IDIwOjQ2LCAmcXVvdDtO YXQgU2FraW11cmEmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyBhIMOpY3JpdCA6DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYWdyZWUg d2l0aCBKb2huIHRoYXQgb3ZlcmxvYWRpbmcgcmVzcG9uc2VfdHlwZSBAIGF1dGh6IGVuZHBvaW50 IGlzIGEgYmFkIGlkZWEuIEl0IGNvbXBsZXRlbHkgY2hhbmdlcyB0aGUgc2VtYW50aWNzIG9mIHRo aXMgcGFyYW1ldGVyLiBOT1RFOiB3aGF0IEkgd2FzIHByb3Bvc2luZyB3YXMgbm90IHRoaXMgcGFy YW1ldGVyLA0KIGJ1dCBhIG5ldyBwYXJhbWV0ZXIgcmVzcG9uc2VfdHlwZSBAIHRva2VuIGVuZHBv aW50LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SSBhbHNvIHRoaW5rIG92ZXJsb2FkaW5nIGdyYW50X3R5cGUgaXMgYSBiYWQg aWRlYSBzaW5jZSBpdCBjaGFuZ2VzIGl0cyBzZW1hbnRpY3MuIEkgcXVvdGUgdGhlIGRlZmluaXRp b24gaGVyZSBhZ2FpbjombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ncmFudCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IGNyZWRl bnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGF1dGhvcml6YXRpb248bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmdy YW50X3R5cGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+dHlwZSBvZiBncmFudCBzZW50IHRvIHRoZSB0b2tlbiBlbmRwb2ludCB0byBvYnRhaW4g dGhlIGFjY2VzcyB0b2tlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBpcyBub3QgYWJvdXQgY29udHJvbGxpbmcgd2hh dCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCwgYnV0IHRoZSBoaW50 IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBkZXNjcmliaW5nIHRoZSB0eXBlIG9mIGNyZWRlbnRpYWwg dGhlIGVuZHBvaW50IGhhcyByZWNlaXZlZC4gSXQgc2VlbXMNCiB0aGUgJnF1b3Q7Y29udHJvbCBv ZiB3aGF0IGlzIGJlaW5nIHJldHVybmVkIGZyb20gdG9rZW4gZW5kcG9pbnQmcXVvdDsgJm5ic3A7 aXMganVzdCBhIHNpZGUgZWZmZWN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhbSBzb21ld2hhdCBhbWJpdmFsZW50WzFd IGluIGNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgdG9rZW4gZW5kcG9pbnQsIGJ1dCBpbiBhcyBt dWNoIGFzICZxdW90O3RleHQgaXMgdGhlIGtpbmcmcXVvdDsgZm9yIGEgc3BlYy4sIHdlIHByb2Jh Ymx5IHNob3VsZCBub3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgaXQgYXMgVG9yc3Rlbg0KIHBv aW50cyBvdXQuIElmIGl0IGlzIG9rIHRvIGNoYW5nZSB0aGlzIHNlbWFudGljcywgSSBiZWxpZXZl IGRlZmluaW5nIGEgbmV3IHBhcmFtZXRlciB0byB0aGlzIGVuZHBvaW50IHRvIGNvbnRyb2wgdGhl IHJlc3BvbnNlIHdvdWxkIGJlIHRoZSBiZXN0IHdheSB0byBnby4gVGhpcyBpcyB3aGF0IEkgaGF2 ZSBkZXNjcmliZWQgcHJldmlvdXNseS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRlZmluaW5nIGEgbmV3IGVuZHBvaW50IHRv IHNlbmQgY29kZSB0byBnZXQgSUQgVG9rZW4gYW5kIGZvcmJpZGRpbmcgdGhlIHVzZSBvZiBpdCBh Z2FpbnN0IHRva2VuIGVuZHBvaW50IHdvdWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiBh bnkgZXhpc3RpbmcgcGFyYW1ldGVyIG9yIGVuZHBvaW50LCB3aGljaA0KIGlzIGdvb2QuIEhvd2V2 ZXIsIEkgZG91YnQgaWYgaXQgaXMgbm90IHdvcnRoIGRvaW5nLiBXaGF0J3MgdGhlIHBvaW50IG9m IGF2b2lkaW5nIGFjY2VzcyB0b2tlbiBzY29wZWQgdG8gVXNlckluZm8gZW5kcG9pbnQgYWZ0ZXIg YWxsPyBEZWZpbmluZyBhIG5ldyBlbmRwb2ludCBmb3IganVzdCBhdm9pZGluZyB0aGUgYWNjZXNz IHRva2VuIGZvciB1c2VyaW5mbyBlbmRwb2ludCBzZWVtcyB3YXkgdG9vIG11Y2ggdGhlIGhlYXZ5 IHdhaXQgd2F5IGFuZA0KIGl0IGJyZWFrcyBpbnRlcm9wZXJhYmlsaXk6IGl0IGRlZmVhdHMgdGhl IHB1cnBvc2Ugb2Ygc3RhbmRhcmRpemF0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBoYXZlIHN0YXJ0ZWQgZmVlbGlu ZyB0aGF0IG5vIGNoYW5nZSBpcyB0aGUgYmVzdCB3YXkgb3V0LiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TmF0PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5bMV0gJm5i c3A7SWYgaW5zdGVhZCBvZiBzYXlpbmcgJnF1b3Q7VG9rZW4gZW5kcG9pbnQgLSB1c2VkIGJ5IHRo ZSBjbGllbnQgdG8gZXhjaGFuZ2UgYW4gYXV0aG9yaXphdGlvbiZuYnNwO2dyYW50IGZvciBhbiBh Y2Nlc3MgdG9rZW4sIHR5cGljYWxseSB3aXRoIGNsaWVudCBhdXRoZW50aWNhdGlvbiZxdW90Oywg aXQgd2VyZSBzYXlpbmcgJnF1b3Q7VG9rZW4NCiBlbmRwb2ludCAtIHVzZWQgYnkgdGhlIGNsaWVu dCB0byBleGNoYW5nZSBhbiBhdXRob3JpemF0aW9uJm5ic3A7Z3JhbnQgZm9yIHRva2VucywgdHlw aWNhbGx5IHdpdGggY2xpZW50IGF1dGhlbnRpY2F0aW9uJnF1b3Q7LCB0aGVuIGl0IHdvdWxkIGhh dmUgYmVlbiBPSy4gSXQgaXMgYW4gZXhwYW5zaW9uIG9mIHRoZSBjYXBhYmlsaXR5IHJhdGhlciB0 aGFuIGNoYW5naW5nIHRoZSBzZW1hbnRpY3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MjAxNC0wNy0yMyAxMzozOSBHTVQtMDQ6MDAgTWlr ZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdSBuZWVkIHRoZSBhbHRlcm5hdGl2ZSByZXNw b25zZV90eXBlIHZhbHVlICgmcXVvdDs8L3NwYW4+Y29kZV9mb3JfaWRfdG9rZW48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JnF1b3Q7DQogaW4gdGhlIEE0QyBkcmFm dCkgdG8gdGVsbCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdG8gcmV0dXJuIGEgY29kZSB0byBi ZSB1c2VkIHdpdGggdGhlIG5ldyBncmFudCB0eXBlLCByYXRoZXIgdGhhbiBvbmUgdG8gdXNlIHdp dGggdGhlICZxdW90O2F1dGhvcml6YXRpb25fY29kZSZxdW90OyBncmFudCB0eXBlICh3aGljaCBp cyB3aGF0IHJlc3BvbnNlX3R5cGU9Y29kZSBkb2VzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Ry b25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L3N0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYu b3JnPC9hPl0NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBCZWhhbGYgT2YgPC9zcGFuPjwvc3Ryb25n PkpvaG4gQnJhZGxleTxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZW50Ojwvc3Bhbj48L3N0cm9u Zz4gV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDEwOjMzIEFNPGJyPg0KPHN0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPlRvOjwvc3Bhbj48L3N0cm9uZz4gPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+DQp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT48L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGJyPg0KPHN0cm9uZz5DYzo8L3N0cm9uZz4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPHN0cm9uZz5TdWJqZWN0 Ojwvc3Ryb25nPiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JZiB3ZSB1c2UgdGhlIHRva2VuIGVuZHBvaW50IHRoZW4gYSBu ZXcgZ3JhbnRfdHlwZSBpcyB0aGUgYmVzdCB3YXkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBz b3J0IG9mIG92ZXJsb2FkcyBjb2RlLCBidXQgdGhhdCBpcyBiZXR0ZXIgdGhhbiBtZXNzaW5nIHdp dGggcmVzcG9uc2VfdHlwZSBmb3IgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgdG8gY2hhbmdl IHRoZSByZXNwb25zZSBmcm9tIHRoZSB0b2tlbl9lbmRwb2ludC4gJm5ic3A7VGhhdCBpcyBpbiBt eSBvcGluaW9uDQogYSBjaGFtcGlvbiBiYWQgaWRlYS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklu IGRpc2N1c3Npb25zIGRldmVsb3BpbmcgQ29ubmVjdCB3ZSBkZWNpZGVkIG5vdCB0byBvcGVuIHRo aXMgY2FuIG9mIHdvcm1zIGJlY2F1c2Ugbm8gZ29vZCB3b3VsZCBjb21lIG9mIGl0LiAmbmJzcDsm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSB0b2tlbl9lbmRwb2ludCByZXR1cm5zIGEgYWNjZXNz IHRva2VuLiAmbmJzcDtOb3RoaW5nIHJlcXVpcmVzIHNjb3BlIHRvIGJlIGFzc29jaWF0ZXMgd2l0 aCB0aGUgdG9rZW4uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGF0IGlzIHRoZSBiZXN0IHNvbHV0 aW9uLiAmbmJzcDtObyBjaGFuZ2UgcmVxdWlyZWQuICZuYnNwO0JldHRlciBpbnRlcm9wZXJhYmls aXR5IGluIG15IG9waW5pb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TdGlsbCBvbiBteSB3YXkg dG8gVE8sIGdldHRpbmcgaW4gbGF0ZXIgdG9kYXkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Kb2hu IEIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgaVBob25l PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9u IEp1bCAyMywgMjAxNCwgYXQgMTI6MTUgUE0sIDxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+ IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cD5UaGUgJnF1b3Q7cmVz cG9uc2UgdHlwZSZxdW90OyBvZiB0aGUgdG9rZW4gZW5kcG9pbnQgaXMgY29udHJvbGxlZCBieSB0 aGUgdmFsdWUgb2YgdGhlIHBhcmFtZXRlciAmcXVvdDtncmFudF90eXBlJnF1b3Q7LiBTbyB0aGVy ZSBpcyBubyBuZWVkIHRvIGludHJvZHVjZSBhIG5ldyBwYXJhbWV0ZXIuPG86cD48L286cD48L3A+ DQo8cD53cnQgdG8gYSBwb3RlbnRpYWwgJnF1b3Q7bm9fYWNjZXNzX3Rva2VuJnF1b3Q7IGdyYW50 IHR5cGUuIEkgZG8gbm90IGNvbnNpZGVyIHRoaXMgYSBnb29kIGlkZWEgYXMgaXQgY2hhbmdlcyB0 aGUgc2VtYW50aWNzIG9mIHRoZSB0b2tlbiBlbmRwb2ludCAoYXMgYWxyZWFkeSBwb2ludGVkIG91 dCBieSBUaG9tYXMpLiBUaGlzIGVuZHBvaW50IEFMV0FZUyByZXNwb25kcyB3aXRoIGFuIGFjY2Vz cyB0b2tlbiB0byBhbnkgZ3JhbnQgdHlwZS4gSSB0aGVyZWZvcmUgd291bGQNCiBwcmVmZXIgdG8g dXNlIGFub3RoZXIgZW5kcG9pbnQgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlLjxvOnA+PC9vOnA+ PC9wPg0KPHA+cmVnYXJkcyw8YnI+DQpUb3JzdGVuLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwPkFt IDIzLjA3LjIwMTQgMTM6MDQsIHNjaHJpZWIgTmF0IFNha2ltdXJhOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JTUhPLCBjaGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mICZxdW90O3Jlc3Bv bnNlX3R5cGUmcXVvdDsgQCBhdXRoeiBlbmRwb2ludCB0aGlzIHdheSBpcyBub3QgYSBnb29kIHRo aW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JbnN0ZWFkLCBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXIgJnF1 b3Q7cmVzcG9uc2VfdHlwZSZxdW90OyBAIHRva2VuIGVuZHBvaW50LCBhcyBJIGRlc2NyaWJlZCBp biBteSBwcmV2aW91cyBtZXNzYWdlLCZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5wcm9iYWJseSBpcyBiZXR0ZXIuIEF0IGxlYXN0LCBpdCBkb2Vz IG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiB0aGUgcGFyYW1ldGVycyBvZiBSRkM2NzQ5LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7TmF0Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIwMTQtMDctMjMgMTI6NDggR01ULTA0OjAwIFRob21h cyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj50LmJyb3llckBnbWFpbC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vLCBJIG1lYW4gcmVzcG9uc2VfdHlwZT1ub25lIGFu ZCByZXNwb25zZV90eXBlPWlkX3Rva2VuIGRvbid0IGdlbmVyYXRlIGEgY29kZSBvciBhY2Nlc3Mg dG9rZW4gc28geW91IGRvbid0IHVzZSB0aGUgVG9rZW4gRW5kcG9pbnQgKHdoaWNoIGlzIG5vdCB0 aGUgc2FtZSBhcyB0aGUgQXV0aGVudGljYXRpb24gRW5kcG9pbnQNCiBCVFcpLiA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldpdGggcmVzcG9uc2VfdHlwZT1j b2RlX2Zvcl9pZF90b2tlbiwgeW91IGdldCBhIGNvZGUgYW5kIGV4Y2hhbmdlIGl0IGZvciBhbiBp ZF90b2tlbiBvbmx5LCByYXRoZXIgdGhhbiBhbiBhY2Nlc3NfdG9rZW4sIHNvIHlvdSdyZSBjaGFu Z2luZyB0aGUgc2VtYW50aWNzIG9mIHRoZSBUb2tlbiBFbmRwb2ludC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkknbSBub3Qgc2F5aW5nIGl0J3MgYSBiYWQgdGhpbmcsIGp1c3QgdGhhdCB5b3UgY2FuJ3QgcmVh bGx5IGNvbXBhcmUgbm9uZSBhbmQgaWRfdG9rZW4gd2l0aCBjb2RlX2Zvcl9pZF90b2tlbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBXZWQsIEp1bCAyMywgMjAxNCBhdCA2OjQ1IFBNLCBSaWNoZXIsIEp1c3RpbiBQLiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBt aXRyZS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkl0J3Mgb25seSAmcXVvdDtub3QgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50 JnF1b3Q7IGJlY2F1c2UgdGhlIHRva2VuIGVuZHBvaW50IGNvcHktcGFzdGVkIGFuZCByZW5hbWVk IHRoZSBhdXRoZW50aWNhdGlvbiBlbmRwb2ludC4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOy0tIEp1c3Rpbjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBKdWwgMjMsIDIwMTQsIGF0IDk6 MzAgQU0sIFRob21hcyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj50LmJyb3llckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkV4Y2VwdCB0aGF0IHRoZXNlIGFyZSBh Ym91dCBub3QgdXNpbmcgdGhlIFRva2VuIEVuZHBvaW50IGF0IGFsbCwgd2hlcmVhcyB0aGUgY3Vy cmVudCBwcm9wb3NhbCBpcyBhYm91dCB0aGUgVG9rZW4gRW5kcG9pbnQgbm90IHJldHVybmluZyBh biBhY2Nlc3NfdG9rZW4gZmllbGQgaW4gdGhlIEpTT04uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiBXZWQsIEp1bCAyMywgMjAxNCBhdCA0OjI2IFBNLCBNaWtlIEpvbmVz ICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSByZXNwb25zZV90eXBlICZxdW90 O25vbmUmcXVvdDsgaXMgYWxyZWFkeSB1c2VkIGluIHByYWN0aWNlLCB3aGljaCByZXR1cm5zIG5v IGFjY2VzcyB0b2tlbi4mbmJzcDsgSXQgd2FzIGFjY2VwdGVkDQogYnkgdGhlIGRlc2lnbmF0ZWQg ZXhwZXJ0cyBhbmQgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQSBPQXV0aCBBdXRob3JpemF0aW9uIEVu ZHBvaW50IFJlc3BvbnNlIFR5cGVzIHJlZ2lzdHJ5IGF0DQo8YSBocmVmPSJodHRwOi8vd3d3Lmlh bmEub3JnL2Fzc2lnbm1lbnRzL29hdXRoLXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54bWwj ZW5kcG9pbnQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVu dHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhtbCNlbmRwb2ludDwvYT4uJm5i c3A7IFRoZSByZWdpc3RlcmVkICZxdW90O2lkX3Rva2VuJnF1b3Q7IHJlc3BvbnNlIHR5cGUgYWxz byByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5T byBJIHRoaW5rIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHJlc3BvbnNlIHR5cGVzIHRoYXQgcmVz dWx0IGluIG5vIGFjY2VzcyB0b2tlbiBiZWluZyByZXR1cm5lZCBhcmUNCiBhY2NlcHRhYmxlIHdp dGhpbiBPQXV0aCAyLjAgaXMgYWxyZWFkeSBzZXR0bGVkLCBhcyBhIHByYWN0aWNhbCBtYXR0ZXIu Jm5ic3A7IExvdHMgb2YgT0F1dGggaW1wbGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IHVzaW5nIHN1 Y2ggcmVzcG9uc2UgdHlwZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IE9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxzdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5PbiBCZWhhbGYgT2YgPC9zcGFuPjwvc3Ryb25nPlBoaWwgSHVudDxicj4NCjxzdHJv bmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5TZW50Ojwvc3Bhbj48L3N0cm9uZz4gV2VkbmVzZGF5LCBKdWx5IDIzLCAy MDE0IDc6MDkgQU08YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VG86PC9zcGFuPjwvc3Ryb25nPiBO YXQgU2FraW11cmE8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2M6PC9zcGFuPjwvc3Ryb25nPiAm bHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0Ojwvc3Bhbj48 L3N0cm9uZz4gUmU6IFtPQVVUSC1XR10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlll cy4gVGhpcyBpcyB3aHkgaXQgaGFzIHRvIGJlIGRpc2N1c3NlZCBpbiB0aGUgSUVURi48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGhpbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5AaW5kZXBlbmRlbnRpZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iIHRhcmdldD0iX2JsYW5r Ij53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3Jh Y2xlLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk9uIEp1bCAyMywgMjAxNCwgYXQgOTo0MyBBTSwgTmF0IFNha2ltdXJhICZs dDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2Fr aW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlJlYWRpbmcgYmFjayB0aGUgUkZDNjc0OSwgSSBhbSBub3Qgc3VyZSBpZiB0aGVyZSBpcyBh IGdvb2Qgd2F5IG9mIHN1cHByZXNzaW5nIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSByZXNwb25zZSBh bmQgc3RpbGwgYmUgT0F1dGguIEl0IHdpbGwgYnJlYWsgd2hvbGUgYnVuY2ggb2YgaW1wbGljaXQg ZGVmaW5pdGlvbnMNCiBsaWtlOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YXV0aG9yaXphdGlvbiBzZXJ2ZXI8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyBUaGUgc2VydmVyIGlzc3VpbmcgYWNjZXNzIHRva2VucyB0byB0aGUg Y2xpZW50IGFmdGVyIHN1Y2Nlc3NmdWxseTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGF1dGhl bnRpY2F0aW5nIHRoZSByZXNvdXJjZSBvd25lciBhbmQgb2J0YWluaW5nIGF1dGhvcml6YXRpb24u PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+QWZ0ZXIgYWxsLCBPQXV0aCBpcyBhbGwgYWJvdXQgaXNzdWluZyBhY2Nlc3MgdG9r ZW5zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWxzbywgSSB0YWtlIGJhY2sgbXkgc3RhdGVtZW50 IG9uIHRoZSBncmFudCB0eXBlIGluIG15IHByZXZpb3VzIG1haWwuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGUgZGVmaW5pdGlvbiBvZiBncmFudCBhbmQgZ3JhbnRfdHlwZSBhcmUgcmVzcGVjdGl2 ZWx5OiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmdyYW50Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsg Y3JlZGVudGlhbCByZXByZXNlbnRpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlv bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5ncmFudF90eXBlPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyAoc3RyaW5n IHJlcHJlc2VudGluZyB0aGUpIHR5cGUgb2YgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4gZW5kcG9p bnQgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGh1 cywgdGhlIGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IGluIHRoaXMgY2FzZSBpcyBz dGlsbCAnY29kZScuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZXNwb25zZSB0eXBlIG9uIHRoZSBv dGhlciBoYW5kIGlzIG5vdCBzbyB3ZWxsIGRlZmluZWQgaW4gUkZDNjc0OSwgYnV0IGl0IHNlZW1z IGl0IGlzIHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlIGF1dGhv cml6YXRpb24gZW5kcG9pbnQuIFRvIGV4cHJlc3Mgd2hhdCBpcyB0bw0KIGJlIHJldHVybmVkIGZy b20gdG9rZW4gZW5kcG9pbnQsIHBlcmhhcHMgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVyIHRvIHRo ZSB0b2tlbiBlbmRwb2ludCwgd2hpY2ggaXMgYSBwYXJhbGxlbCB0byB0aGUgcmVzcG9uc2VfdHlw ZSB0byB0aGUgQXV0aG9yaXphdGlvbiBFbmRwb2ludCBzZWVtcyB0byBiZSBhIG1vcmUgc3ltbWV0 cmljIHdheSwgdGhvdWdoIEkgYW0gbm90IHN1cmUgYXQgYWxsIGlmIHRoYXQgaXMgZ29pbmcgdG8g YmUgT0F1dGggYW55IG1vcmUuDQogT25lIHN0cmF3LW1hbiBpcyB0byBkZWZpbmUgYSBuZXcgcGFy YW1ldGVyIGNhbGxlZCByZXNwb25zZV90eXBlIHRvIHRoZSB0b2tlbiBlbmRwb2ludCBzdWNoIGFz OiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+cmVzcG9uc2VfdHlwZTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IE9QVElPTkFM LiBBIHN0cmluZyByZXByZXNlbnRpbmcgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRoZSB0 b2tlbiBlbmRwb2ludC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGVuIGRl ZmluZSB0aGUgYmVoYXZpb3Igb2YgdGhlIGVuZHBvaW50IGFjY29yZGluZyB0byB0aGUgdmFsdWVz IGFzIHRoZSBwYXJhbGxlbCB0byB0aGUgbXVsdGktcmVzcG9uc2UgdHlwZSBzcGVjLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBo cmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC12Mi1tdWx0aXBsZS1yZXNwb25zZS10 eXBlcy0xXzAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29h dXRoLXYyLW11bHRpcGxlLXJlc3BvbnNlLXR5cGVzLTFfMC5odG1sPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+TmF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4yMDE0LTA3LTIzIDc6MjEgR01ULTA0OjAwIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9y YWNsZS5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UaGUgZHJhZnQgaXMgdmVyeSBjbGVhci4mbmJzcDs8c3BhbiBzdHlsZT0i Y29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KUGhpbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBKdWwg MjMsIDIwMTQsIGF0IDA6NDYsIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2lt dXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlRoZSBuZXcgZ3JhbnQgdHlwZSB0aGF0IEkgd2FzIHRhbGtpbmcgYWJvdXQgd2FzJm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVvdDth dXRob3JpemF0aW9uX2NvZGVfYnV0X2RvX25vdF9yZXR1cm5fYWNjZXNzX25vcl9yZWZyZXNoX3Rv a2VuJnF1b3Q7LCBzbyB0byBzcGVhay4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBkb2VzIG5vdCByZXR1cm4gYW55dGhpbmcgcGVy IHNlLCBidXQgYW4gZXh0ZW5zaW9uIGNhbiBkZWZpbmUgc29tZXRoaW5nIG9uIHRvcCBvZiBpdC4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZW4sIE9JREMgY2FuIGRlZmluZSBhIGJpbmRpbmcgdG8g aXQgc28gdGhhdCB0aGUgYmluZGluZyBvbmx5IHJldHVybnMgSUQgVG9rZW4uJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgYmlu ZGluZyB3b3JrIHNob3VsZCBiZSBkb25lIGluIE9JREYuIFNob3VsZCB0aGVyZSBiZSBzdWNoIGEg Z3JhbnQgdHlwZSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPml0IHdpbGwgYmUgYW4gZXh0cmVtZWx5IHNo b3J0IHNwZWMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BdCB0aGUgc2FtZSB0aW1lLCBpZiBhbnkg b3RoZXIgc3BlY2lmaWNhdGlvbiB3YW50ZWQgdG8gZGVmaW5lJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPm90aGVyIHR5cGUgb2YgdG9r ZW5zIGFuZCBoYXZlIGl0IHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LCZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5pdCBj YW4gYWxzbyB1c2UgdGhpcyBncmFudCB0eXBlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgd2hh dCB5b3Ugd2FudCBpcyB0byBkZWZpbmUgYSBuZXcgZ3JhbnQgdHlwZSB0aGF0IHJldHVybnMgSUQg VG9rZW4gb25seSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+dGhlbiwgSSBhbSB3aXRoIEp1c3Rpbi4gU2luY2UgJnF1b3Q7b3RoZXIg cmVzcG9uc2UgdGhhbiBJRCBUb2tlbiZxdW90OyBpcyBvbmx5Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoZW9yZXRpY2FsLCB0aGlz IGlzIGEgbW9yZSBwbGF1c2libGUgd2F5IGZvcndhcmQsIEkgc3VwcG9zZS4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4yMDE0LTA3LTIyIDE0OjMwIEdNVC0wNDowMCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJt YWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9h PiZndDs6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvIHRoZSBkcmFm dCB3b3VsZCBsaXRlcmFsbHkgdHVybiBpbnRvOjxicj4NCjxicj4NCiZxdW90O1RoZSBhNGMgcmVz cG9uc2UgdHlwZSBhbmQgZ3JhbnQgdHlwZSByZXR1cm4gYW4gaWRfdG9rZW4gZnJvbSB0aGUgdG9r ZW4gZW5kcG9pbnQgd2l0aCBubyBhY2Nlc3MgdG9rZW4uIEFsbCBwYXJhbWV0ZXJzIGFuZCB2YWx1 ZXMgYXJlIGRlZmluZWQgaW4gT0lEQy4mcXVvdDs8YnI+DQo8YnI+DQpTZWVtcyBsaWtlIHRoZSBw ZXJmZWN0IG1pbmkgZXh0ZW5zaW9uIGRyYWZ0IGZvciBPSURGIHRvIGRvLjxicj4NCjxicj4NCi0t SnVzdGluPGJyPg0KPGJyPg0KL3NlbnQgZnJvbSBteSBwaG9uZS88bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCk9uIEp1bCAyMiwgMjAxNCAxMDoyOSBB TSwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0 Ozxicj4NCiZndDsgV2hhdCBhYm91dCBqdXN0IGRlZmluaW5nIGEgbmV3IGdyYW50IHR5cGUgaW4g dGhpcyBXRz88YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgMjAxNC0wNy0yMiAxMjo1NiBH TVQtMDQ6MDAgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5j b20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7Ojxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhhdCB3b3VsZCBiZSBuaWNlLiBIb3dldmVyIG9pZGMgc3Rp bGwgbmVlZHMgdGhlIG5ldyBncmFudCB0eXBlIGluIG9yZGVyIHRvIGltcGxlbWVudCB0aGUgc2Ft ZSBmbG93LiZuYnNwOzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUGhpbDxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgT24gSnVsIDIyLCAyMDE0LCBhdCAxMTozNSwgTmF0IFNha2ltdXJh ICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsgJiM0MzsxIHRvIEp1c3Rpbi4mbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgMjAxNC0wNy0yMiA5OjU0IEdNVC0wNDowMCBS aWNoZXIsIEp1c3RpbiBQLiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0 YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0Ozo8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBFcnJvcnMgbGlrZSB0aGVzZSBtYWtlIGl0IGNs ZWFyIHRvIG1lIHRoYXQgaXQgd291bGQgbWFrZSBtdWNoIG1vcmUgc2Vuc2UgdG8gZGV2ZWxvcCB0 aGlzIGRvY3VtZW50IGluIHRoZSBPcGVuSUQgRm91bmRhdGlvbi4gSXQgc2hvdWxkIGJlIHNvbWV0 aGluZyB0aGF0IGRpcmVjdGx5IHJlZmVyZW5jZXMgT3BlbklEIENvbm5lY3QgQ29yZSBmb3IgYWxs IG9mIHRoZXNlIHRlcm1zIGluc3RlYWQgb2YgcmVkZWZpbmluZyB0aGVtLiBJdCdzIGRvaW5nDQog YXV0aGVudGljYXRpb24sIHdoaWNoIGlzIGZ1bmRhbWVudGFsbHkgd2hhdCBPcGVuSUQgQ29ubmVj dCBkb2VzIG9uIHRvcCBvZiBPQXV0aCwgYW5kIEkgZG9uJ3Qgc2VlIGEgZ29vZCBhcmd1bWVudCBm b3IgZG9pbmcgdGhpcyB3b3JrIGluIHRoaXMgd29ya2luZyBncm91cC48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDstLSBKdXN0aW48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbiBKdWwgMjIsIDIwMTQsIGF0IDQ6MzAg QU0sIFRob21hcyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj50LmJyb3llckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgT24gTW9uLCBKdWwgMjEsIDIwMTQgYXQgMTE6NTIgUE0sIE1pa2UgSm9uZXMgJmx0Ozxh IGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5r Ij5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZv ciB5b3VyIHJldmlldywgVGhvbWFzLiZuYnNwOyBUaGUgJnF1b3Q7cHJvbXB0PWNvbnNlbnQmcXVv dDsgZGVmaW5pdGlvbiBiZWluZyBtaXNzaW5nIGlzIGFuIGVkaXRvcmlhbCBlcnJvci4mbmJzcDsg SXQgc2hvdWxkIGJlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uc2VudDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgQXV0aG9yaXphdGlvbiBT ZXJ2ZXIgU0hPVUxEIHByb21wdCB0aGUgRW5kLVVzZXIgZm9yIGNvbnNlbnQgYmVmb3JlIHJldHVy bmluZyBpbmZvcm1hdGlvbiB0byB0aGUgQ2xpZW50LiBJZiBpdCBjYW5ub3Qgb2J0YWluIGNvbnNl bnQsIGl0IE1VU1QgcmV0dXJuIGFuIGVycm9yLCB0eXBpY2FsbHkgY29uc2VudF9yZXF1aXJlZC48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgJm5ic3A7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEknbGwgcGxhbiB0byBhZGQgaXQgaW4gdGhlIG5leHQgZHJhZnQuPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IEl0IGxvb2tzIGxpa2UgdGhlIGNvbnNlbnRfcmVxdWlyZWQgZXJyb3Ig bmVlZHMgdG8gYmUgZGVmaW5lZCB0b28sIGFuZCB5b3UgbWlnaHQgaGF2ZSBmb3Jnb3R0ZW4gdG8g YWxzbyBpbXBvcnQgYWNjb3VudF9zZWxlY3Rpb25fcmVxdWlyZWQgZnJvbSBPcGVuSUQgQ29ubmVj dC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgYWdyZWUg dGhhdCB0aGVyZSdzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJlc3BvbnNlIHdpdGggbXVsdGlw bGUgJnF1b3Q7YW1yJnF1b3Q7IHZhbHVlcyB0aGF0IGluY2x1ZGVzICZxdW90O21mYSZxdW90OyBh bmQgb25lIHRoYXQgZG9lc24ndC4mbmJzcDsgVW5sZXNzIGEgY2xlYXIgdXNlIGNhc2UgZm9yIHdo eSAmcXVvdDttZmEmcXVvdDsgaXMgbmVlZGVkIGNhbiBiZSBpZGVudGlmaWVkLCB3ZSBjYW4gZGVs ZXRlIGl0IGluIHRoZSBuZXh0IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFua3MuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIb3cgYWJv dXQgJnF1b3Q7cHdkJnF1b3Q7IHRoZW4/IEkgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IEkgc2hvdWxk IHJldHVybiAmcXVvdDtwd2QmcXVvdDsgaWYgdGhlIHVzZXIgYXV0aGVudGljYXRlZCB1c2luZyBh IHBhc3N3b3JkLCBidXQgd2hhdCAmcXVvdDt0aGUgc2VydmljZSBpZiBhIGNsaWVudCBzZWNyZXQg aXMgdXNlZCZxdW90OyBtZWFucyBpbiB0aGUgZGVmaW5pdGlvbiBmb3IgdGhlICZxdW90O3B3ZCZx dW90OyB2YWx1ZT88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IChOb3RhOiBJIGtub3cgeW91J3JlIGF0IElFVEYtOTAsIEknbSByZWFkeSB0byB3YWl0 ICd0aWwgeW91IGNvbWUgYmFjayA7LSkgKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaG9tYXMg QnJveWVyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgL3Q8YSBocmVmPSJodHRwOi8veG4tLW5u YS5tYS54bi0tYndhLXh4Yi5qZS8iIHRhcmdldD0iX2JsYW5rIj7JlC5tYS5iyoF3YS5qZS88L2E+ PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0 bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyAtLTxicj4NCiZndDsmZ3Q7Jmd0OyBOYXQgU2FraW11cmEgKD1uYXQpPGJyPg0KJmd0OyZndDsm Z3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVm PSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNh a2ltdXJhLm9yZy88L2E+PGJyPg0KJmd0OyZndDsmZ3Q7IEBfbmF0X2VuPGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZn dDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IE5hdCBTYWtp bXVyYSAoPW5hdCk8YnI+DQomZ3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZn dDsgPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCiZndDsgQF9uYXRfZW48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVh cj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+LS0NCjxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCk8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlv bjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pi0tDQo8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBo cmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0 LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi cj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxicj4NClRob21hcyBCcm95ZXI8YnI+DQovdDxh IGhyZWY9Imh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhiLmplLyIgdGFyZ2V0PSJfYmxhbmsi PsmULm1hLmLKgXdhLmplLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLQ0KPGJyPg0KVGhv bWFzIEJyb3llcjxicj4NCi90PGEgaHJlZj0iaHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIu amUvIiB0YXJnZXQ9Il9ibGFuayI+yZQubWEuYsqBd2EuamUvPC9hPiA8L3NwYW4+DQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRo QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxicj4NCk5hdCBTYWtp bXVyYSAoPW5hdCkgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNh a2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+ PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZT5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYu b3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFs bCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8YnI+ DQpOYXQgU2FraW11cmEgKD1uYXQpIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KPGEgaHJlZj0iaHR0 cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25hdC5zYWtpbXVy YS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxi ciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+LS0NCjxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCkgPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8 YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v bmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1 dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0 aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPi0tDQo8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRp b248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9B dXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_a3cec5f516f74c8c879dfd623ba71168BLUPR03MB309namprd03pro_-- From nobody Mon Jul 28 10:33:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E15B1A0417 for ; Mon, 28 Jul 2014 10:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 7G2647GqXvxm for ; Mon, 28 Jul 2014 10:33: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 09C101A03FD for ; Mon, 28 Jul 2014 10:33:20 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MF5C3-1XIBef1D0F-00GGnL for ; Mon, 28 Jul 2014 19:33:18 +0200 Message-ID: <53D6895F.4050104@gmx.net> Date: Mon, 28 Jul 2014 19:33:19 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OsSQ7i5uvrMgD0HnOUAmL5LsRWXXMKKjb" X-Provags-ID: V03:K0:HELz3tSbSPzuf/9JvfMFLnu6wxqRF8ut7bXyZwOaUiqLuD5biAe mntFL+dIBSOCWDpOKLpxPsmRW2J6C1yvh4vZLaETpg0/UNtxX4cIgRIie2eP0UbpgIirxwo 2W4D2jhxMGcYCTg0VABRJsXm11f/EMVFrvQZxs9aUOHJKfsOiVuglm1Y3Ae14kovWhKZSWN dza6cSn9q4crWQ+b9h5dQ== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/r37SyF3mUrQPysAsZbY983XCM4Q Subject: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 28 Jul 2014 17:33:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OsSQ7i5uvrMgD0HnOUAmL5LsRWXXMKKjb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, during the IETF #90 OAuth WG meeting, there was strong consensus in adopting the "OAuth Token Introspection" (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG work item. We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document: http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion as to the suitability of adopting this document as a WG work item, please send mail to the OAuth WG list indicating your opinion (Yes/No). The confirmation call for adoption will last until August 10, 2014. If you have issues/edits/comments on the document, please send these comments along to the list in your response to this Call for Adoption. Ciao Hannes & Derek --OsSQ7i5uvrMgD0HnOUAmL5LsRWXXMKKjb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJT1olfAAoJEGhJURNOOiAtGaMH/34Jk8q0b2vhT6NYELG/IJZm 026/kAJoyax8a9OGbR1tpiBtQSCp34ijBfob7mMfd9y/DLBdLMixFFPF15BqQrxS bDvApcWqUiC/ctbNlh2atLHdRoSk3FDDi8hH9jpLWEjfPlLA+2KloXstXIRuKgEw jycMMhNEeTboFt7opEcBRShC5WtYugzLgYZA/7IX0XD9ebWtELETue7YK+O139g/ nLJZeh81XcVJeTfrZSCDtbCUcEy391ha8R3anFJH8+YMHBXOR2+JQ2C9/eAd4OgI CNNdVD0526jIQ7mQfA2SZ3TSoi+7zCEC/2IIHT/vA2dK/jZXq6IdnjZynIp49I4= =CnDJ -----END PGP SIGNATURE----- --OsSQ7i5uvrMgD0HnOUAmL5LsRWXXMKKjb-- From nobody Mon Jul 28 10:33:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25581A0502 for ; Mon, 28 Jul 2014 10:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 neykknhUen8i for ; Mon, 28 Jul 2014 10:33:26 -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 E142B1A046A for ; Mon, 28 Jul 2014 10:33:23 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MRocn-1X5aRf075N-00Syw7 for ; Mon, 28 Jul 2014 19:33:22 +0200 Message-ID: <53D68963.6040600@gmx.net> Date: Mon, 28 Jul 2014 19:33:23 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="p5M70BmA4vNKkM5d4aXxopFUtu4Vh7H3E" X-Provags-ID: V03:K0:vim6w8KoxNKWYN03D5U9PW+Tn+la+DdmOx7E5D5+QX2Oy6EVFTD +NXZavbAuiP1GZ+8aWVyKY6jyLgv1SRLiKtYMfYaUBjsPJ9Flih3fPSHXffC4qEUVZ0tp5J O/CSLDlUlSiBLBfia041nhtmaifRhhT5Htm6lrC7yd4Xl30lKE+rEmDEauMgTdHfkTGw07V O3HV7VJ973wcxKf9QKJjA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lHdPCWSZJVFWXzLlv5-RYwXp-7o Subject: [OAUTH-WG] Confirmation: Call for Adoption of "Request by JWS ver.1.0 for OAuth 2.0" as an OAuth Working Group Item 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, 28 Jul 2014 17:33:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --p5M70BmA4vNKkM5d4aXxopFUtu4Vh7H3E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, during the IETF #90 OAuth WG meeting, there was strong consensus in adopting the " Request by JWS ver.1.0 for OAuth 2.0" (draft-sakimura-oauth-requrl-05.txt) specification as an OAuth WG work item. We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document: http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion as to the suitability of adopting this document as a WG work item, please send mail to the OAuth WG list indicating your opinion (Yes/No). The confirmation call for adoption will last until August 10, 2014. If you have issues/edits/comments on the document, please send these comments along to the list in your response to this Call for Adoption. Ciao Hannes & Derek --p5M70BmA4vNKkM5d4aXxopFUtu4Vh7H3E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJT1oljAAoJEGhJURNOOiAtN0MH/ipIBKKauy6ixp0ot9SxajqQ 18HRHuFHJc7EQX9nAC//pD90iY2mkScANhrzkMbXZUZO1DCJ6RfCMc1if/JKGjLv XXMJa4G8uNhLAjzYqAMwo7K4FYkQvRgMsPETOOQFpVb780snjNj6z6FrKQiCBMm1 P4NT5xUv9dcfNBpRI0YarFn9j6opFlm4Mkjr1okG8If5UwzAEPKgxcZ2znbkYVGW v6jWfxZ4tX53ywj/QtHjSAsa11pMnLRgqfbse0QF7x0gpoBqOp8N2MZZ0frt4rXc DFLNibdUgn0nubanqCYXL6d7kHKFv8fm0xEE9JsFXCJu6s9NfrkYRORGMWB+MzI= =xkwr -----END PGP SIGNATURE----- --p5M70BmA4vNKkM5d4aXxopFUtu4Vh7H3E-- From nobody Mon Jul 28 10:33:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97AC1A050E for ; Mon, 28 Jul 2014 10:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 pV_rBTzFtws8 for ; Mon, 28 Jul 2014 10:33:31 -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 303E01A03CA for ; Mon, 28 Jul 2014 10:33:27 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Ltqmn-1WSxu41IqD-0116oe for ; Mon, 28 Jul 2014 19:33:25 +0200 Message-ID: <53D68967.7000206@gmx.net> Date: Mon, 28 Jul 2014 19:33:27 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="X7dDLNIOkUeeq8GfnO648tJF3w78f0w1n" X-Provags-ID: V03:K0:LbI30DbnDGGihnZaVguPBp1BR+dcQd4PogyOHqvYJzSFnhDXBdT EfTZ/rlfj0exsgBEGcDctBJj2QoDs1jpJuoqxQF/X19nrl+5FUeLmbnx+DOjw0j3ipX5i0n owat27RBrQk6ly3nBM9aDAaC+IzHWiUYV0XbJyYaBKvDhxoqw2jfOSIwkBLBieB+SDNkrhS TN8e1grLnR0i7kTa95yKg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JVhIP3GoPef5z30XWyS9NnYDmfY Subject: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Symmetric Proof of Posession for Code Extension" as an OAuth Working Group Item 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, 28 Jul 2014 17:33:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X7dDLNIOkUeeq8GfnO648tJF3w78f0w1n Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, during the IETF #90 OAuth WG meeting, there was strong consensus in adopting the "OAuth Symmetric Proof of Posession for Code Extension" (draft-sakimura-oauth-tcse-03.txt) specification as an OAuth WG work item= =2E We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion as to the suitability of adopting this document as a WG work item, please send mail to the OAuth WG list indicating your opinion (Yes/No). The confirmation call for adoption will last until August 10, 2014. If you have issues/edits/comments on the document, please send these comments along to the list in your response to this Call for Adoption. Ciao Hannes & Derek --X7dDLNIOkUeeq8GfnO648tJF3w78f0w1n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJT1olnAAoJEGhJURNOOiAtX24IAI2+UJjNRvSKU7LfiEp753S2 G5TmCpgUDEXuHDmdVbiZNuLrMAGAydsfCe8wSF2nSvpE+QrUxEh2lrbDt6oBeuzt lb9DKD89IZpjqyMOq78HVmg2E+cQhBz/eUD4Vu7ySz3ysVVMoMvQwwoiH5tn1z3F RsAr7RNtlFjsOKZOu1ACMqn6FbSWHdMUE9DSaCuEkxJpYxr+zegW0EALLDh5Fdf+ yshxHRzhyhenZ2l2vzqzfPdNYsmm4IZu1DOs/KkeZBPspKKrEGXmbB9p/MvH8lqw Bn9kdb2zatdLKB6jzX9iC9pl4KFDfB0x/LmurAIMQUenkLFFWmRqoqs3R0QELFI= =UxBs -----END PGP SIGNATURE----- --X7dDLNIOkUeeq8GfnO648tJF3w78f0w1n-- From nobody Mon Jul 28 10:33:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E34B1A050E for ; Mon, 28 Jul 2014 10:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 nttEUFq-9ctn for ; Mon, 28 Jul 2014 10:33:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87ABC1A03CA for ; Mon, 28 Jul 2014 10:33:34 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lqhaw-1WXYNC3nn8-00ePRG for ; Mon, 28 Jul 2014 19:33:33 +0200 Message-ID: <53D6896E.1030701@gmx.net> Date: Mon, 28 Jul 2014 19:33:34 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0J0utbEplvxHw8XFgfIoAMEl7xwJkR9x2" X-Provags-ID: V03:K0:7PIFpM92fzuq8Lx/5u3WlfXjOlIsnytZiM837y03/YP2KzugKxR f20ugjhXMqM4NFeP2N1UP/JtYWgr3+X4ovYA4lFlYWWeOExoNtvDr6Je4PNOsWSQGe0smyN flOeGNC3mTXHsYN1zpDifaf5ZUWgK0P9dqItx2JZ0nbbWhdzLNHQjeI808Ee7et7fn4DWke khM977iQffrRFQSnFjIXg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Y9vlg-EcpK5SVcwJivUs4xOIhvI Subject: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth Working Group Item 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, 28 Jul 2014 17:33:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0J0utbEplvxHw8XFgfIoAMEl7xwJkR9x2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, during the IETF #90 OAuth WG meeting, there was strong consensus in adopting the "OAuth 2.0 Token Exchange" (draft-jones-oauth-token-exchange-01.txt) specification as an OAuth WG work item. We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document: http://datatracker.ietf.org/doc/draft-jones-oauth-token-exchange/ If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion as to the suitability of adopting this document as a WG work item, please send mail to the OAuth WG list indicating your opinion (Yes/No). The confirmation call for adoption will last until August 10, 2014. If you have issues/edits/comments on the document, please send these comments along to the list in your response to this Call for Adoption. Ciao Hannes & Derek --0J0utbEplvxHw8XFgfIoAMEl7xwJkR9x2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJT1oluAAoJEGhJURNOOiAtzDsH+gMQLPeFncP6nPHIxY1+qS2V 0bJivQ38n/TGVVw7k492XTh+xnF7gV2yK5AJwgjq+AkyE6dxMk+sFYaiSzbVjxO8 zz1V8de7ne7vGzkG65Z0IX/iNdAPZXVORWdJZAj8tm47Vr2f7JvuGAjoJxtwMzRV idndjBucjS+oLCsOGBZumHmEzVp6neOCHWkEsCVDr+rTfJ5/INxaVmqdrOCs3iIu y9csl5qn986lP5ydRzEbgoeFScMIl3lpT0oHmyQ6+CRgmEj4Beg4UmGD9b8mQfhg tsEQQ32z1svqDhwKkvFO5uputSIcjgLPVrhsrJbhvgnezfsRFse8YiKejHSj5I0= =LmuQ -----END PGP SIGNATURE----- --0J0utbEplvxHw8XFgfIoAMEl7xwJkR9x2-- From nobody Mon Jul 28 10:56:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A96B1A0564 for ; Mon, 28 Jul 2014 10:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_DOMAIN_NOVOWEL=0.5, URI_NOVOWEL=0.5] 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 yuXS9cJ51svs for ; Mon, 28 Jul 2014 10:56:07 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 486B31A0643 for ; Mon, 28 Jul 2014 10:56:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 517B64FC0417; Mon, 28 Jul 2014 10:55:58 -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 36KMhMqkoKJt; Mon, 28 Jul 2014 10:55:53 -0700 (PDT) Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 2A7934FC03FE; Mon, 28 Jul 2014 10:55:52 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <53D6895F.4050104@gmx.net> Date: Mon, 28 Jul 2014 10:56:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <76529C23-F662-466E-B56F-15E5A72D8C78@xmlgrrl.com> References: <53D6895F.4050104@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/nGUR4Tq1b-hdlJdTp1Zl7UoyfNQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 28 Jul 2014 17:56:09 -0000 Yes. This spec is of particular interest to UMA, for which it's valuable = to have a standardized and interoperable way to perform run-time token = introspection at the AS. To see how UMA uses profiles the existing token = introspection spec, see this section and its subsections: http://tools.ietf.org/html/draft-hardjono-oauth-umacore-10#section-3.3 Eve On 28 Jul 2014, at 10:33 AM, Hannes Tschofenig = wrote: > Hi all, >=20 > during the IETF #90 OAuth WG meeting, there was strong consensus in > adopting the "OAuth Token Introspection" > (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG > work item. >=20 > We would now like to verify the outcome of this call for adoption on = the > OAuth WG mailing list. Here is the link to the document: > http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >=20 > If you did not hum at the IETF 90 OAuth WG meeting, and have an = opinion > as to the suitability of adopting this document as a WG work item, > please send mail to the OAuth WG list indicating your opinion = (Yes/No). >=20 > The confirmation call for adoption will last until August 10, 2014. = If > you have issues/edits/comments on the document, please send these > comments along to the list in your response to this Call for Adoption. >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From nobody Mon Jul 28 11:46:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC94F1A04B8 for ; Mon, 28 Jul 2014 11:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.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 ZJHMdm2qmpI2 for ; Mon, 28 Jul 2014 11:46:18 -0700 (PDT) Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) (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 78FA81A0176 for ; Mon, 28 Jul 2014 11:46:18 -0700 (PDT) Received: from [98.139.212.153] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 28 Jul 2014 18:46:17 -0000 Received: from [98.139.212.249] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 28 Jul 2014 18:46:17 -0000 Received: from [127.0.0.1] by omp1058.mail.bf1.yahoo.com with NNFMP; 28 Jul 2014 18:46:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 605658.96478.bm@omp1058.mail.bf1.yahoo.com Received: (qmail 88516 invoked by uid 60001); 28 Jul 2014 18:46:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1406573177; bh=nW5mzcSMYcfjfuRFlJ5+6wCuF7GTnwua66iOjRzJ4mk=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ZSjEfeyn8L2yOk8bO0ZQeHfcDxpFwFvl2IEcOeKQ5Uo2SKdh44RyEySTncpA5NmhruPAW/j2tjGjdgMLoM/rkk7PF4cmdCcWQ01X+f3d6eAS4BkI2hwBbWNUOcJiQENUeTKVQbU2MowVhAJXPCQXK3pvmAXW3VPZpJzz162ZlIo= X-YMail-OSG: SCDrH1gVM1nVuyPBraEfXs4HzZqXkLpcE59g.sSEPhHw065 UPlHJEyAAJLhgKdc23se.Nztq7O1jznL6hqyxHhAey3Bb35QQCYiMj3r33W5 OvKx9V0YfxV_EHUOGVwc0sfu1hD7HiP3ennLu9mAtjSY7wLoXjgS8pNOQjj3 MUli92_hvGN.pvwqdutC5TSaRLtEQVrtThIqvRG.VisubkVKCTdSmv78lcZk rNS7HwB_EEoiCdpSxZQYtJDLqH1HbG52zoVEO3V_thECWRd7rGPVPIrhictQ 61PRiOdrVed7DlcwInrPvzDEw9uv1_NHCAZY3mQVBSCUF8aZkKzIrZDdiW16 GecWhPmdIfWI33YpmsW2oxNMkE6MOwKZ_xuhHoGc4Pi.t3VmXrfIpm1zk8dX xkJFHEJIBYErAbY1i5OKdohX_T.UYr9N4lK9B.Or_hJsFjuGDH1Do0gTztOb UW_b8Hq0BAULGcG7.9aoKsXsWk9c6HZ.CBI_pqYutiBjTPrK_hn3tHisBv23 Cfg0YeSQCUC3dGO8axDhBGHZGFqVuGDFEqGKwhaHXtVnIY3s.ACa.zW.fdQ- - Received: from [167.220.24.190] by web142804.mail.bf1.yahoo.com via HTTP; Mon, 28 Jul 2014 11:46:17 PDT X-Rocket-MIMEInfo: 002.001, KzEgYWRvcHRpb24KCgpPbiBNb25kYXksIEp1bHkgMjgsIDIwMTQgMTE6NDEgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToKIAoKCkhpIGFsbCwKCmR1cmluZyB0aGUgSUVURiAjOTAgT0F1dGggV0cgbWVldGluZywgdGhlcmUgd2FzIHN0cm9uZyBjb25zZW5zdXMgaW4KYWRvcHRpbmcgdGhlICJPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uIgooZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDYudHh0KSBzcGVjaWZpY2F0aW9uIGFzIGFuIE9BdXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.196.685 References: <53D6895F.4050104@gmx.net> Message-ID: <1406573177.74702.YahooMailNeo@web142804.mail.bf1.yahoo.com> Date: Mon, 28 Jul 2014 11:46:17 -0700 From: Bill Mills To: Hannes Tschofenig , "oauth@ietf.org" In-Reply-To: <53D6895F.4050104@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2129327256-2143182665-1406573177=:74702" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-zCigDLLiUCG1LZN2Js0n-JzExM Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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: Mon, 28 Jul 2014 18:46:19 -0000 ---2129327256-2143182665-1406573177=:74702 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable +1 adoption=0A=0A=0AOn Monday, July 28, 2014 11:41 AM, Hannes Tschofenig wrote:=0A =0A=0A=0AHi all,=0A=0Aduring the IETF #= 90 OAuth WG meeting, there was strong consensus in=0Aadopting the "OAuth To= ken Introspection"=0A(draft-richer-oauth-introspection-06.txt) specificatio= n as an OAuth WG=0Awork item.=0A=0AWe would now like to verify the outcome = of this call for adoption on the=0AOAuth WG mailing list. Here is the link = to the document:=0Ahttp://datatracker.ietf.org/doc/draft-richer-oauth-intro= spection/=0A=0AIf you did not hum at the IETF 90 OAuth WG meeting, and have= an opinion=0Aas to the suitability of adopting this document as a WG work = item,=0Aplease send mail to the OAuth WG list indicating your opinion (Yes/= No).=0A=0AThe confirmation call for adoption will last until August 10, 201= 4.=A0 If=0Ayou have issues/edits/comments on the document, please send thes= e=0Acomments along to the list in your response to this Call for Adoption.= =0A=0ACiao=0AHannes & Derek=0A=0A__________________________________________= _____=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/= listinfo/oauth ---2129327256-2143182665-1406573177=:74702 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
+1 adoption


= On Monday, July 28, 2014 11:41 AM, Hannes Tschofenig <hannes.tschofenig= @gmx.net> wrote:


Hi all,

during the IETF #90 OAuth WG meeting, there was strong = consensus in
adopting the "OAuth Token Introspection"
(draft-richer-o= auth-introspection-06.txt) specification as an OAuth WG
work item.
We would now like to verify the outcome of this call for adoption on the
OAuth W= G mailing list. Here is the link to the document:
h= ttp://datatracker.ietf.org/doc/draft-richer-oauth-introspection/
If you did not hum at the IETF 90 OAuth WG meeting, and have an opinionas to the suitability of adopting this document as a WG work item,
plea= se send mail to the OAuth WG list indicating your opinion (Yes/No).

= The confirmation call for adoption will last until August 10, 2014.  I= f
you have issues/edits/comments on the document, please send these
c= omments along to the list in your response to this Call for Adoption.
Ciao
Hannes & Derek

_______________________________________= ________
OAuth mailing list
OAuth@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/oauth


---2129327256-2143182665-1406573177=:74702-- From nobody Mon Jul 28 11:55:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2F01A0647 for ; Mon, 28 Jul 2014 11:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bItAljJlOaJg for ; Mon, 28 Jul 2014 11:55:23 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01501A0AC4 for ; Mon, 28 Jul 2014 11:55:23 -0700 (PDT) Received: from mail-ig0-f176.google.com ([209.85.213.176]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKU9acmlRTLGwq350YFZYm9oxqP58+SQwz@postini.com; Mon, 28 Jul 2014 11:55:23 PDT Received: by mail-ig0-f176.google.com with SMTP id hn18so4135551igb.9 for ; Mon, 28 Jul 2014 11:55:22 -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=t5Ovm+wXn/Ha9UgrjEJUl44myHeJfH7QG1eMsMRpllA=; b=YYaoPN32pJtto7UFeToossSHbChhuLw4CszyEtLKm+qH3qyhMMBjUnXcIsWMKYyfUR siruyeepmfb8TEtre/zV3aG3kcGZ8MPWUxuXzMY6A2pOAnFPuTgLCtQZTcjiVLsVPHet KBYtrRr+938eazpfIrr9HkWhOe2nbi4RtIpmsdOcIP75iW66xyC/18EK1/Wi6GcDF8qe xRr5AnqbXTYwIAONVCGBJzQHesE+jn0hcDBTWTGPqrcJ2Kvk+1QC4tw5i/ZUYJPfV5fm P5TlX3j4jUOl2SJ4tXrrJ6RQY2YRB7nwIlMKKQJv8jt6XkWHgEaJhBVfqUFOQFnMKwG7 E0Ug== X-Gm-Message-State: ALoCoQmfBA/xmo+hOceptJvsfeRIN9JcJTPuc2WqjFj9ZDquq1zVV8wRVBmpuzazn0axbDARK8N512CbWtWIyr4CqRaNsdtSWAL86Io94HnZXZRqcVPklLN1bZjV6RY36hkpGD+4esHH X-Received: by 10.51.17.2 with SMTP id ga2mr27985014igd.2.1406573722023; Mon, 28 Jul 2014 11:55:22 -0700 (PDT) X-Received: by 10.51.17.2 with SMTP id ga2mr27985001igd.2.1406573721934; Mon, 28 Jul 2014 11:55:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Mon, 28 Jul 2014 11:54:51 -0700 (PDT) In-Reply-To: <53D68967.7000206@gmx.net> References: <53D68967.7000206@gmx.net> From: Brian Campbell Date: Mon, 28 Jul 2014 12:54:51 -0600 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113491e40c388b04ff45775a Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/W1HduZKR1IxkiZuaNfcD_OPUj_g Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Symmetric Proof of Posession for Code Extension" as an OAuth Working Group Item 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, 28 Jul 2014 18:55:26 -0000 --001a113491e40c388b04ff45775a Content-Type: text/plain; charset=UTF-8 Yes, I am in favor of adopting this document as a WG work item. On Mon, Jul 28, 2014 at 11:33 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > during the IETF #90 OAuth WG meeting, there was strong consensus in > adopting the "OAuth Symmetric Proof of Posession for Code Extension" > (draft-sakimura-oauth-tcse-03.txt) specification as an OAuth WG work item. > > We would now like to verify the outcome of this call for adoption on the > OAuth WG mailing list. Here is the link to the document: > http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ > > If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion > as to the suitability of adopting this document as a WG work item, > please send mail to the OAuth WG list indicating your opinion (Yes/No). > > The confirmation call for adoption will last until August 10, 2014. If > you have issues/edits/comments on the document, please send these > comments along to the list in your response to this Call for Adoption. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113491e40c388b04ff45775a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I am in favor of adopting this document as a WG work = item.


On= Mon, Jul 28, 2014 at 11:33 AM, Hannes Tschofenig <hannes.tschofen= ig@gmx.net> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Symmetric Proof of Posession for Code Extension&qu= ot;
(draft-sakimura-oauth-tcse-03.txt) specification as an OAuth WG work item.<= br>
We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014. =C2=A0I= f
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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


--001a113491e40c388b04ff45775a-- From nobody Mon Jul 28 11:57:54 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949311A083D for ; Mon, 28 Jul 2014 11:57:52 -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 Nsekxdzuod1O for ; Mon, 28 Jul 2014 11:57:51 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139031A05F5 for ; Mon, 28 Jul 2014 11:57:51 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 10so4958738ykt.3 for ; Mon, 28 Jul 2014 11:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=bbmoJBVGi9X+epAkfF9085vMRWLyfIw6tCIf4zGdrzs=; b=iKhyDqFnmpOGHgoLna5JkpJS6rmCgCh6ZnHbwHa+oZcvT18/2ByVjq5Va4cWA0TS3v gh8tXTtqiiJKJkpdMMbgHfD/bmZvZ5NRIWW7X6eTI99B9XmXRzmo7BeN1CasONT91K9D ttTXRd/KZidHQeL66Azvm9VS2uaRqm8mxoJ2KNWTJ2R7VT/ZQ1d+hhljmXau6hcPgZa2 FBY3cdjcLeqfcuac3/0QIu3I6gpvRnOqDUWoLgUZlFa+dmHZk4rwnDZ4cvT9/urqa9l6 FkRSRqptu55AQRB4Oahgz6b7t7vD58Gpz5LApua/5TKUgzIHNlBwBH8pLHf9AAZyQgbz 712g== X-Received: by 10.236.203.33 with SMTP id e21mr54377179yho.92.1406573870390; Mon, 28 Jul 2014 11:57:50 -0700 (PDT) Received: from [192.168.0.111] ([199.167.110.10]) by mx.google.com with ESMTPSA id n6sm23198824yha.20.2014.07.28.11.57.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 11:57:49 -0700 (PDT) Message-ID: <53D69D2A.2020908@gmail.com> Date: Mon, 28 Jul 2014 14:57:46 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , "oauth@ietf.org" References: <53D68967.7000206@gmx.net> In-Reply-To: <53D68967.7000206@gmx.net> Content-Type: multipart/alternative; boundary="------------070005060203010505090602" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/orsVYKbpeJBRKJmDBLyyXAzwgPQ Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Symmetric Proof of Posession for Code Extension" as an OAuth Working Group Item 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, 28 Jul 2014 18:57:52 -0000 This is a multi-part message in MIME format. --------------070005060203010505090602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I support the WG taking this on On 7/28/14, 1:33 PM, Hannes Tschofenig wrote: > Hi all, > > during the IETF #90 OAuth WG meeting, there was strong consensus in > adopting the "OAuth Symmetric Proof of Posession for Code Extension" > (draft-sakimura-oauth-tcse-03.txt) specification as an OAuth WG work item. > > We would now like to verify the outcome of this call for adoption on the > OAuth WG mailing list. Here is the link to the document: > http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ > > If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion > as to the suitability of adopting this document as a WG work item, > please send mail to the OAuth WG list indicating your opinion (Yes/No). > > The confirmation call for adoption will last until August 10, 2014. If > you have issues/edits/comments on the document, please send these > comments along to the list in your response to this Call for Adoption. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------070005060203010505090602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I support the WG taking this on
On 7/28/14, 1:33 PM, Hannes Tschofenig wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Symmetric Proof of Posession for Code Extension"
(draft-sakimura-oauth-tcse-03.txt) specification as an OAuth WG work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek




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

--------------070005060203010505090602-- From nobody Mon Jul 28 17:01:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016911A0298 for ; Mon, 28 Jul 2014 17:01:11 -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 6G93IOAzlATM for ; Mon, 28 Jul 2014 17:01:09 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027C41A0267 for ; Mon, 28 Jul 2014 17:01:08 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id v6so6269628lbi.25 for ; Mon, 28 Jul 2014 17:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vc0w+loVRwksh9hH6Uzs1D4GRWS/tHzXGVE4jbwOhsQ=; b=nvy94PQjHJ2nz3RAW7/y/wCHZuUEEVKeu7bf2absc+TV0bfToPINeLxQVqQ3zy2K83 XGMp56a0d7MWiL/Mul43MAUhm7fGlqzSnUmRQtEhOaPmCQ4sj3oMSC86FsvUvpmxKSzI nPP+h7myBAlObD0BrZtfhVdX9I/ap09QSOyL8XkxYjQyGScly6idzE0HdGUKgdawbs9z sbuMVazICP6l1CmXBe8nFr0Z97O1f5RuXdxSHa70E/j6/adsy2OXBgfCpwPZf+vbIf5e EVrUUqNTL8mIUvtwe7YFEL8laf9GwFQQhrbval2+ZsNggv4NlQnyocvJci73jgFKwPfB DEFA== X-Received: by 10.112.137.136 with SMTP id qi8mr35639627lbb.41.1406592067203; Mon, 28 Jul 2014 17:01:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.113.73 with HTTP; Mon, 28 Jul 2014 17:00:46 -0700 (PDT) In-Reply-To: <53D6895F.4050104@gmx.net> References: <53D6895F.4050104@gmx.net> From: Thomas Broyer Date: Tue, 29 Jul 2014 02:00:46 +0200 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e012287a28278db04ff49bc01 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LVZsz8qmgZtF1V6Cw35dA_BsM2U Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 00:01:11 -0000 --089e012287a28278db04ff49bc01 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/ On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > during the IETF #90 OAuth WG meeting, there was strong consensus in > adopting the "OAuth Token Introspection" > (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG > work item. > > We would now like to verify the outcome of this call for adoption on the > OAuth WG mailing list. Here is the link to the document: > http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ > > If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion > as to the suitability of adopting this document as a WG work item, > please send mail to the OAuth WG list indicating your opinion (Yes/No). > > The confirmation call for adoption will last until August 10, 2014. If > you have issues/edits/comments on the document, please send these > comments along to the list in your response to this Call for Adoption. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --089e012287a28278db04ff49bc01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes. This spec is of special interest to the platform we&#= 39;re building for=C2=A0http://www.oas= is-eu.org/


On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.= tschofenig@gmx.net> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-int= rospection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014. =C2=A0I= f
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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




--
Thomas B= royer
/t=C9=94.ma.b=CA=81w= a.je/
--089e012287a28278db04ff49bc01-- From nobody Mon Jul 28 17:11:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE551A03B7 for ; Mon, 28 Jul 2014 17:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 j3FUUrIGRkIZ for ; Mon, 28 Jul 2014 17:11:27 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C351A03C6 for ; Mon, 28 Jul 2014 17:11:19 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6T0BFnS030944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Jul 2014 00:11:15 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s6T0BEKR022703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Jul 2014 00:11:14 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6T0BE7q001259; Tue, 29 Jul 2014 00:11:14 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Jul 2014 17:11:13 -0700 References: <53D6895F.4050104@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-9892AB60-29A0-4C0D-BD58-2F920FE07FA5 Content-Transfer-Encoding: 7bit Message-Id: <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Mon, 28 Jul 2014 17:11:11 -0700 To: Thomas Broyer X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/EOiBODUDh4HX14lRqtm_QImLRww Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 00:11:35 -0000 --Apple-Mail-9892AB60-29A0-4C0D-BD58-2F920FE07FA5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Could we have some discussion on the interop cases? Is it driven by scenarios where AS and resource are separate domains? Or may= this be only of interest to specific protocols like UMA? =46rom a technique principle, the draft is important and sound. I am just no= t there yet on the reasons for an interoperable standard.=20 Phil > On Jul 28, 2014, at 17:00, Thomas Broyer wrote: >=20 > Yes. This spec is of special interest to the platform we're building for h= ttp://www.oasis-eu.org/ >=20 >=20 >> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig wrote: >> Hi all, >>=20 >> during the IETF #90 OAuth WG meeting, there was strong consensus in >> adopting the "OAuth Token Introspection" >> (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG >> work item. >>=20 >> We would now like to verify the outcome of this call for adoption on the >> OAuth WG mailing list. Here is the link to the document: >> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>=20 >> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion >> as to the suitability of adopting this document as a WG work item, >> please send mail to the OAuth WG list indicating your opinion (Yes/No). >>=20 >> The confirmation call for adoption will last until August 10, 2014. If >> you have issues/edits/comments on the document, please send these >> comments along to the list in your response to this Call for Adoption. >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-9892AB60-29A0-4C0D-BD58-2F920FE07FA5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Could we have some discussion on the i= nterop cases?

Is it driven by scenarios where AS an= d resource are separate domains? Or may this be only of interest to specific= protocols like UMA?

=46rom a technique principle, t= he draft is important and sound. I am just not there yet on the reasons for a= n interoperable standard. 

Phil

= On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platf= orm we're building for http://www.= oasis-eu.org/


On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.= tschofenig@gmx.net> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
= OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-intro= spection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If=
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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




--
Thomas Br= oyer
/t=C9=94.ma.b=CA=81wa.= je/
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-9892AB60-29A0-4C0D-BD58-2F920FE07FA5-- From nobody Mon Jul 28 17:40:09 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7961A0A92 for ; Mon, 28 Jul 2014 17:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 0juoTlooWndu for ; Mon, 28 Jul 2014 17:40:03 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CDC1A090D for ; Mon, 28 Jul 2014 17:40:03 -0700 (PDT) X-AuditID: 12074423-f79bf6d000007580-3b-53d6ed625ffd Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 72.58.30080.26DE6D35; Mon, 28 Jul 2014 20:40:02 -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 s6T0e1sm017956 for ; Mon, 28 Jul 2014 20:40:02 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6T0dxVB026872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 28 Jul 2014 20:40:01 -0400 Message-ID: <53D6ED5A.10500@mit.edu> Date: Mon, 28 Jul 2014 20:39:54 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: oauth@ietf.org References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> In-Reply-To: <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> Content-Type: multipart/alternative; boundary="------------030807020703080101060009" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IRYrdT1016ey3YYOtnLouTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48/736wF070qnm89xtrAONW0i5GTQ0LARKL300VWCFtM4sK9 9WwgtpDAbCaJKzNLuhi5gOxjjBKr/zWzQzgfmCS+dTeBVfEKqEi8+vmdCcRmEVCVWP7vCzuI zQZkz195CywuKhAlcedSPytEvaDEyZlPWEBsEQEhiec7+4BqODiEBcolzl/hgpg/l1Gi6/QX sF5OATuJTf9eg/UyC4RJtM2eyzaBkX8WklGzkKRmAY1iFrCW+La7CCIsL7H97RxmCFtbYlXv WSZk8QWMbKsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfRyM0v0UlNKNzGCQ9hFeQfjn4NKhxgF OBiVeHg3zL0WLMSaWFZcmXuIUZKDSUmUN/UGUIgvKT+lMiOxOCO+qDQntfgQowQHs5II7/wl QDnelMTKqtSifJiUNAeLkjjvW2urYCGB9MSS1OzU1ILUIpisDAeHkgSv7BugRsGi1PTUirTM nBKENBMHJ8hwHqDh716DDC8uSMwtzkyHyJ9iNOaYc/dYGxPHAhApxJKXn5cqJc4bBjJOAKQ0 ozQPbhosDb1iFAd6Tpj3PMhAHmAKg5v3CmgVE9AqFv/LIKtKEhFSUg2MxaFr2IvWcyxgY/97 dv2S2f/+sM/9mrT7bohlP2/XVMmcv10N2/NfnjuuqbaP7Z3s1KkXpdRi9hwrnlaz/8uUw9EC MpkiEZoik30zFxcdvWfoZreoTUT3YWiFj5rPk76jN0SS2XrCpK3Phi/ZuoVL5kfzxpV/fh02 2r/nTM9jhr5HLvaiOe8tlFiKMxINtZiLihMBR9ZNmB4DAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/G5_NMzoRWjcqy_z--dngErGoCGw Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 00:40:06 -0000 This is a multi-part message in MIME format. --------------030807020703080101060009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It's analogous to JWT in many ways: when you've got the AS and the RS separated somehow (different box, different domain, even different software vendor) and you need to communicate a set of information about the approval delegation from the AS (who has the context to know about it) through to the RS (who needs to know about it to make the authorization call). JWT gives us an interoperable way to do this by passing values inside the token itself, introspection gives a way to pass the values by reference via the token as an artifact. The two are complementary, and there are even cases where you'd want to deploy them together. -- Justin On 7/28/2014 8:11 PM, Phil Hunt wrote: > Could we have some discussion on the interop cases? > > Is it driven by scenarios where AS and resource are separate domains? > Or may this be only of interest to specific protocols like UMA? > > From a technique principle, the draft is important and sound. I am > just not there yet on the reasons for an interoperable standard. > > Phil > > On Jul 28, 2014, at 17:00, Thomas Broyer > wrote: > >> Yes. This spec is of special interest to the platform we're building >> for http://www.oasis-eu.org/ >> >> >> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >> > wrote: >> >> Hi all, >> >> during the IETF #90 OAuth WG meeting, there was strong consensus in >> adopting the "OAuth Token Introspection" >> (draft-richer-oauth-introspection-06.txt) specification as an >> OAuth WG >> work item. >> >> We would now like to verify the outcome of this call for adoption >> on the >> OAuth WG mailing list. Here is the link to the document: >> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >> >> If you did not hum at the IETF 90 OAuth WG meeting, and have an >> opinion >> as to the suitability of adopting this document as a WG work item, >> please send mail to the OAuth WG list indicating your opinion >> (Yes/No). >> >> The confirmation call for adoption will last until August 10, >> 2014. If >> you have issues/edits/comments on the document, please send these >> comments along to the list in your response to this Call for >> Adoption. >> >> Ciao >> Hannes & Derek >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> -- >> Thomas Broyer >> /t?.ma.b?wa.je/ >> _______________________________________________ >> 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 --------------030807020703080101060009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
It's analogous to JWT in many ways: when you've got the AS and the RS separated somehow (different box, different domain, even different software vendor) and you need to communicate a set of information about the approval delegation from the AS (who has the context to know about it) through to the RS (who needs to know about it to make the authorization call). JWT gives us an interoperable way to do this by passing values inside the token itself, introspection gives a way to pass the values by reference via the token as an artifact. The two are complementary, and there are even cases where you'd want to deploy them together.

 -- Justin

On 7/28/2014 8:11 PM, Phil Hunt wrote:
Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/


On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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




--
Thomas Broyer
/tɔ.ma.bʁwa.je/
_______________________________________________
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

--------------030807020703080101060009-- From nobody Mon Jul 28 17:59:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780041A042D for ; Mon, 28 Jul 2014 17:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 pkr01kqKMeON for ; Mon, 28 Jul 2014 17:59:12 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BA81A059F for ; Mon, 28 Jul 2014 17:59:09 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6T0x8Lt027561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Jul 2014 00:59:09 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6T0x7cA016245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Jul 2014 00:59:08 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6T0x7F6005007; Tue, 29 Jul 2014 00:59:07 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Jul 2014 17:59:06 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_FDDF2153-ADCF-4A0F-9BB1-04461E32FC91" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <53D6ED5A.10500@mit.edu> Date: Mon, 28 Jul 2014 17:59:05 -0700 Message-Id: <33F1EE39-2BDF-4F3D-B4DD-4AB9848BC4BF@oracle.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D6ED5A.10500@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/yZ687ryDLq1QvQF_uNRMrfPC4d0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 00:59:20 -0000 --Apple-Mail=_FDDF2153-ADCF-4A0F-9BB1-04461E32FC91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That doesn=E2=80=99t explain the need for inter-operability. What = you=E2=80=99ve described is what will be common practice. It=E2=80=99s a great open source technique, but that=E2=80=99s not a = standard. JWT is much different. JWT is a foundational specification that = describes the construction and parsing of JSON based tokens. There is = inter-op with token formats that build on top and there is inter-op = between every communicating party. In OAuth, a site may never implement token introspection nor may it do = it the way you describe. Why would that be a problem? Why should the = group spend time on something where there may be no inter-op need. Now that said, if you are in the UMA community. Inter-op is quite = foundational. It is very very important. But then maybe the spec should = be defined within UMA? Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 28, 2014, at 5:39 PM, Justin Richer wrote: > It's analogous to JWT in many ways: when you've got the AS and the RS = separated somehow (different box, different domain, even different = software vendor) and you need to communicate a set of information about = the approval delegation from the AS (who has the context to know about = it) through to the RS (who needs to know about it to make the = authorization call). JWT gives us an interoperable way to do this by = passing values inside the token itself, introspection gives a way to = pass the values by reference via the token as an artifact. The two are = complementary, and there are even cases where you'd want to deploy them = together. >=20 > -- Justin >=20 > On 7/28/2014 8:11 PM, Phil Hunt wrote: >> Could we have some discussion on the interop cases? >>=20 >> Is it driven by scenarios where AS and resource are separate domains? = Or may this be only of interest to specific protocols like UMA? >>=20 >> =46rom a technique principle, the draft is important and sound. I am = just not there yet on the reasons for an interoperable standard.=20 >>=20 >> Phil >>=20 >> On Jul 28, 2014, at 17:00, Thomas Broyer wrote: >>=20 >>> Yes. This spec is of special interest to the platform we're building = for http://www.oasis-eu.org/ >>>=20 >>>=20 >>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig = wrote: >>> Hi all, >>>=20 >>> during the IETF #90 OAuth WG meeting, there was strong consensus in >>> adopting the "OAuth Token Introspection" >>> (draft-richer-oauth-introspection-06.txt) specification as an OAuth = WG >>> work item. >>>=20 >>> We would now like to verify the outcome of this call for adoption on = the >>> OAuth WG mailing list. Here is the link to the document: >>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>=20 >>> If you did not hum at the IETF 90 OAuth WG meeting, and have an = opinion >>> as to the suitability of adopting this document as a WG work item, >>> please send mail to the OAuth WG list indicating your opinion = (Yes/No). >>>=20 >>> The confirmation call for adoption will last until August 10, 2014. = If >>> you have issues/edits/comments on the document, please send these >>> comments along to the list in your response to this Call for = Adoption. >>>=20 >>> Ciao >>> Hannes & Derek >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Thomas Broyer >>> /t=C9=94.ma.b=CA=81wa.je/ >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_FDDF2153-ADCF-4A0F-9BB1-04461E32FC91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That = doesn=E2=80=99t explain the need for inter-operability. What you=E2=80=99v= e described is what will be common practice.

It=E2=80=99= s a great open source technique, but that=E2=80=99s not a = standard.

JWT is much different. JWT is a = foundational specification that describes the construction and parsing = of JSON based tokens. There is inter-op with token formats that build on = top and there is inter-op between every communicating = party.

In OAuth, a site may never implement = token introspection nor may it do it the way you describe.  Why = would that be a problem?  Why should the group spend time on = something where there may be no inter-op = need.

Now that said, if you are in the UMA = community.  Inter-op is quite foundational.  It is very very = important. But then maybe the spec should be defined within = UMA?


On Jul 28, 2014, at 5:39 PM, Justin Richer <jricher@MIT.EDU> wrote:

=20 =20
It's analogous to JWT in many ways: when you've got the AS and the RS separated somehow (different box, different domain, even different software vendor) and you need to communicate a set of information about the approval delegation from the AS (who has the context to know about it) through to the RS (who needs to know about it to make the authorization call). JWT gives us an interoperable way to do this by passing values inside the token itself, introspection gives a way to pass the values by reference via the token as an artifact. The two are complementary, and there are even cases where you'd want to deploy them together.

 -- Justin

On 7/28/2014 8:11 PM, Phil Hunt wrote:
Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

=46rom a technique principle, the draft is important and = sound. I am just not there yet on the reasons for an interoperable standard. 

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/


On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the = document:
http://datatracker.ietf.org/doc/draft-richer-oauth-intro= spection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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




--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
=
_______________________________________________
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=_FDDF2153-ADCF-4A0F-9BB1-04461E32FC91-- From nobody Mon Jul 28 18:16:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7961A0375 for ; Mon, 28 Jul 2014 18:16:51 -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 jBSfQ-jlmwSL for ; Mon, 28 Jul 2014 18:16:49 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551861A031F for ; Mon, 28 Jul 2014 18:16:49 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id v6so6309360lbi.25 for ; Mon, 28 Jul 2014 18:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=x64k4i5DKIfSlKHmOeaw3Rq8ZnAmpLcs22FC/p80890=; b=VMlM9aKtxUPtkE0fe0a492+HYXh0AaOIpuPeeyrlRDfSZw2pnR/ZPf9vS7kT9QAQrW lhuxtIcS6KG/981rpyLE0nNdTSXzYZXdKoUzvXBL25pJRoKVzPWHSrX9XUoqKWAXS7RW udvi9822c9UWOBRuyYNjHbkRRZYVBJH2XzDi5A5IgJNPD6GRdAwkTX/5i+pxa8WmSOjK imtnVkLK+OUN4twz2zzdDdM+DGmf9pux765nivOdI/D523A7z1WV/mYD/aIEV/mzE4N4 LGtGxhdx76pq7ShQqbCf/zLuOsnTetWz24RVKmuoMHtkUjXIuG/W8QlZAEPno7pcJ2lR iEbg== X-Received: by 10.112.172.38 with SMTP id az6mr858189lbc.53.1406596607375; Mon, 28 Jul 2014 18:16:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.113.73 with HTTP; Mon, 28 Jul 2014 18:16:26 -0700 (PDT) In-Reply-To: <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> From: Thomas Broyer Date: Tue, 29 Jul 2014 03:16:26 +0200 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c3442e1fff8004ff4acb15 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/e3XgB4s-saaZp3_tbE9cX6qyfnI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 01:16:52 -0000 --001a11c3442e1fff8004ff4acb15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Interesting question. In our specific case, we don't really *need* interop as we have a single AS, so the protocol could be specific to our needs. Building on a standard however means that it might be easier to find software libraries implementing it that could be used to build apps for our platform. Similarly: we use OpenID Connect but we could have defined our own protocol that issues OAuth access tokens. The benefit of standards are peer reviews (particularly of privacy and security concerns) and software libraries. >From my PoV, this goes along with registration: you register an app to an AS, and if the app exposes resources protected using OAuth then it can use introspection to allow/deny access. Interop of introspection is as necessary as interop of registration; it means an app can easily be "portable": deployable in different environments provided they implement introspection (and/or registration, and/or OpenID Connect, etc.) Maybe it falls under the UMA scope more than the OAuth WG though (registration is not enough, you also need to register "resource sets" with their scopes). On Tue, Jul 29, 2014 at 2:11 AM, Phil Hunt wrote: > Could we have some discussion on the interop cases? > > Is it driven by scenarios where AS and resource are separate domains? Or > may this be only of interest to specific protocols like UMA? > > From a technique principle, the draft is important and sound. I am just > not there yet on the reasons for an interoperable standard. > > Phil > > On Jul 28, 2014, at 17:00, Thomas Broyer wrote: > > Yes. This spec is of special interest to the platform we're building for > http://www.oasis-eu.org/ > > > On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> Hi all, >> >> during the IETF #90 OAuth WG meeting, there was strong consensus in >> adopting the "OAuth Token Introspection" >> (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG >> work item. >> >> We would now like to verify the outcome of this call for adoption on the >> OAuth WG mailing list. Here is the link to the document: >> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >> >> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion >> as to the suitability of adopting this document as a WG work item, >> please send mail to the OAuth WG list indicating your opinion (Yes/No). >> >> The confirmation call for adoption will last until August 10, 2014. If >> you have issues/edits/comments on the document, please send these >> comments along to the list in your response to this Call for Adoption. >> >> Ciao >> Hannes & Derek >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --001a11c3442e1fff8004ff4acb15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Interesting question.

In our specific c= ase, we don't really *need* interop as we have a single AS, so the prot= ocol could be specific to our needs. Building on a standard however means t= hat it might be easier to find software libraries implementing it that coul= d be used to build apps for our platform.
Similarly: we use OpenID Connect but we could have defined our own protocol= that issues OAuth access tokens. The benefit of standards are peer reviews= (particularly of privacy and security concerns) and software libraries.

From my PoV, this goes along with registration: you reg= ister an app to an AS, and if the app exposes resources protected using OAu= th then it can use introspection to allow/deny access. Interop of introspec= tion is as necessary as interop of registration; it means an app can easily= be "portable": deployable in different environments provided the= y implement introspection (and/or registration, and/or OpenID Connect, etc.= )
Maybe it falls under the UMA scope more than the OAuth WG though= (registration is not enough, you also need to register "resource sets= " with their scopes).


On Tue, Jul 29, 2014 at 2:11 AM, Phil Hunt <= phil.hunt@oracle.com> wrote:
Could we have some discussion on the interop cases?<= /div>

Is it driven by scenarios where AS and resource ar= e separate domains? Or may this be only of interest to specific protocols l= ike UMA?

From a technique principle, the draft is important and = sound. I am just not there yet on the reasons for an interoperable standard= .=C2=A0

=
Phil

On Jul 28, 2014, at= 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform= we're building for=C2=A0http://www.oasis-eu.org/

<= br>
On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofe= nig@gmx.net> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-int= rospection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014. =C2=A0I= f
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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




--
Thomas B= royer
/t= =C9=94.ma.b=CA=81wa.je/
___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org=
https://www.ietf.org/mailman/listinfo/oauth



=
--
Thomas Broyer
/t=C9= =94.ma.b=CA=81wa.je/
--001a11c3442e1fff8004ff4acb15-- From nobody Mon Jul 28 18:24:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8341A031F for ; Mon, 28 Jul 2014 18:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 KD89jAS5nxHp for ; Mon, 28 Jul 2014 18:23:59 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7806B1A02DF for ; Mon, 28 Jul 2014 18:23:58 -0700 (PDT) X-AuditID: 1209190c-f79ef6d000005dd6-87-53d6f7ac8e05 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 61.D8.24022.DA7F6D35; Mon, 28 Jul 2014 21:23:57 -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 s6T1NteB021137; Mon, 28 Jul 2014 21:23:56 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6T1Nspc006721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Jul 2014 21:23:55 -0400 Message-ID: <53D6F7A5.3070209@mit.edu> Date: Mon, 28 Jul 2014 21:23:49 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Phil Hunt References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D6ED5A.10500@mit.edu> <33F1EE39-2BDF-4F3D-B4DD-4AB9848BC4BF@oracle.com> In-Reply-To: <33F1EE39-2BDF-4F3D-B4DD-4AB9848BC4BF@oracle.com> Content-Type: multipart/alternative; boundary="------------040100070400000109050509" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixG6nrrv2+7Vgg7f7WCxOvn3FZrFgfiO7 A5PHkiU/mTw+Pr3FEsAUxWWTkpqTWZZapG+XwJXxeHsvW8GNM4wVR29+Y2pg/NXI2MXIySEh YCJxb+sGdghbTOLCvfVsXYxcHEICs5kkTl//AJYQEtjIKNH3XhcicZtJYtaW5awgCV4BNYkF r2+DTWIRUJXofjyNGcRmA7Lnr7zFBGKLCkRJ3LnUD1UvKHFy5hMWEFtEQEXi29XrYL3MAkIS n49PBKrn4BAWKJc4f4ULYu8LRonvKxJBbE4BO4l/B64xQZSHSTz/8YdpAqPALCRTZyFJQdhm El1buxghbHmJ5q2zmSFsNYnb266yI4svYGRbxSibklulm5uYmVOcmqxbnJyYl5dapGuol5tZ opeaUrqJERTynJI8OxjfHFQ6xCjAwajEw7th7rVgIdbEsuLK3EOMkhxMSqK8B74ChfiS8lMq MxKLM+KLSnNSiw8xSnAwK4nwzl8ClONNSaysSi3Kh0lJc7AoifO+tbYKFhJITyxJzU5NLUgt gsnKcHAoSfDmfwNqFCxKTU+tSMvMKUFIM3FwggznARruAFLDW1yQmFucmQ6RP8VozDHn7rE2 Jo4FIFKIJS8/L1VKnFcfpFQApDSjNA9uGixtvWIUB3pOmHcOSBUPMOXBzXsFtIoJaBWL/2WQ VSWJCCmpBsbVly+pTv2U7jbJend8b0bx6/wDAX8FbH/G31TabXz8lfOV2/nrXxgurU5Svpb5 dn7sJLnTM8x9+abqiNZtzvR5teXNpdcPFdyfLH2W3K2TJpLx+toaN3ulZGUbrS2fTP9m/T5r XzLl1Lq9Zbr+ofdPVXF/Fnm2lW1jwJmVnElyz08X/K1tKNRWYinOSDTUYi4qTgQArf4siDYD AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/VF7vufcujPwWjat4dIlkAhQA9VY Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 01:24:02 -0000 This is a multi-part message in MIME format. --------------040100070400000109050509 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I think this perspective has a lot to do with your idea of OAuth's deployment model. You're right in that many people bundle the RS and the AS very tightly, but that's not always case, nor is it desirable. We're increasingly seeing cases where a group (often an enterprise) has their own AS on premises and wants to stand up an RS from a vendor. Without a means to connect the RS to the AS in a standard way, you're stuck with using whatever AS the RS vendor wants to sell you along side their RS. But with the right mechanisms (like JWT and token introspection), you're able to connect the RS from one vendor to the AS from another vendor, and it works together. I'm not sure what's unclear, but this is the very definition of interoperability. This is to say nothing of simply being able to locate the RS remotely from the AS within a particular security domain and still use artifact-style tokens (ie, tokens that don't encode everything within them). I have already had to deal directly with several cases of RS'es and AS'es from different vendors doing effectively the token introspection thing in different ways, in protecting vanilla OAuth within a single security domain. They were doing it slightly differently for no compelling reason other than having to invent the "I have a token and need to look it up" mechanism independently. When both sides were able to speak the same token introspection protocol (based on the individual draft I'd submitted), then we could actually make things work. And none of this was running UMA, which also makes use of this. I really don't see JWT as any different. To borrow your statement: In OAuth, a site may never implement JWT nor may it do it in the way that JWT describes. Why would that be a problem? (Hint: it isn't, they're free to do whatever token they want. Same with introspection, it's a tool that you can use if it makes sense for you to use it. So far a whole bunch of people have said it makes sense.) -- Justin On 7/28/2014 8:59 PM, Phil Hunt wrote: > That doesn’t explain the need for inter-operability. What you’ve > described is what will be common practice. > > It’s a great open source technique, but that’s not a standard. > > JWT is much different. JWT is a foundational specification that > describes the construction and parsing of JSON based tokens. There is > inter-op with token formats that build on top and there is inter-op > between every communicating party. > > In OAuth, a site may never implement token introspection nor may it do > it the way you describe. Why would that be a problem? Why should the > group spend time on something where there may be no inter-op need. > > Now that said, if you are in the UMA community. Inter-op is quite > foundational. It is very very important. But then maybe the spec > should be defined within UMA? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jul 28, 2014, at 5:39 PM, Justin Richer > wrote: > >> It's analogous to JWT in many ways: when you've got the AS and the RS >> separated somehow (different box, different domain, even different >> software vendor) and you need to communicate a set of information >> about the approval delegation from the AS (who has the context to >> know about it) through to the RS (who needs to know about it to make >> the authorization call). JWT gives us an interoperable way to do this >> by passing values inside the token itself, introspection gives a way >> to pass the values by reference via the token as an artifact. The two >> are complementary, and there are even cases where you'd want to >> deploy them together. >> >> -- Justin >> >> On 7/28/2014 8:11 PM, Phil Hunt wrote: >>> Could we have some discussion on the interop cases? >>> >>> Is it driven by scenarios where AS and resource are separate >>> domains? Or may this be only of interest to specific protocols like UMA? >>> >>> From a technique principle, the draft is important and sound. I am >>> just not there yet on the reasons for an interoperable standard. >>> >>> Phil >>> >>> On Jul 28, 2014, at 17:00, Thomas Broyer >> > wrote: >>> >>>> Yes. This spec is of special interest to the platform we're >>>> building for http://www.oasis-eu.org/ >>>> >>>> >>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>> > wrote: >>>> >>>> Hi all, >>>> >>>> during the IETF #90 OAuth WG meeting, there was strong consensus in >>>> adopting the "OAuth Token Introspection" >>>> (draft-richer-oauth-introspection-06.txt) specification as an >>>> OAuth WG >>>> work item. >>>> >>>> We would now like to verify the outcome of this call for >>>> adoption on the >>>> OAuth WG mailing list. Here is the link to the document: >>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>> >>>> If you did not hum at the IETF 90 OAuth WG meeting, and have an >>>> opinion >>>> as to the suitability of adopting this document as a WG work item, >>>> please send mail to the OAuth WG list indicating your opinion >>>> (Yes/No). >>>> >>>> The confirmation call for adoption will last until August 10, >>>> 2014. If >>>> you have issues/edits/comments on the document, please send these >>>> comments along to the list in your response to this Call for >>>> Adoption. >>>> >>>> Ciao >>>> Hannes & Derek >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> -- >>>> Thomas Broyer >>>> /tÉ”.ma.bÊwa.je/ >>>> _______________________________________________ >>>> 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 > --------------040100070400000109050509 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
I think this perspective has a lot to do with your idea of OAuth's deployment model. You're right in that many people bundle the RS and the AS very tightly, but that's not always case, nor is it desirable. We're increasingly seeing cases where a group (often an enterprise) has their own AS on premises and wants to stand up an RS from a vendor. Without a means to connect the RS to the AS in a standard way, you're stuck with using whatever AS the RS vendor wants to sell you along side their RS. But with the right mechanisms (like JWT and token introspection), you're able to connect the RS from one vendor to the AS from another vendor, and it works together. I'm not sure what's unclear, but this is the very definition of interoperability.

This is to say nothing of simply being able to locate the RS remotely from the AS within a particular security domain and still use artifact-style tokens (ie, tokens that don't encode everything within them).

I have already had to deal directly with several cases of RS'es and AS'es from different vendors doing effectively the token introspection thing in different ways, in protecting vanilla OAuth within a single security domain. They were doing it slightly differently for no compelling reason other than having to invent the "I have a token and need to look it up" mechanism independently. When both sides were able to speak the same token introspection protocol (based on the individual draft I'd submitted), then we could actually make things work. And none of this was running UMA, which also makes use of this.

I really don't see JWT as any different. To borrow your statement: In OAuth, a site may never implement JWT nor may it do it in the way that JWT describes. Why would that be a problem? (Hint: it isn't, they're free to do whatever token they want. Same with introspection, it's a tool that you can use if it makes sense for you to use it. So far a whole bunch of people have said it makes sense.)

 -- Justin

On 7/28/2014 8:59 PM, Phil Hunt wrote:
That doesn’t explain the need for inter-operability. What you’ve described is what will be common practice.

It’s a great open source technique, but that’s not a standard.

JWT is much different. JWT is a foundational specification that describes the construction and parsing of JSON based tokens. There is inter-op with token formats that build on top and there is inter-op between every communicating party.

In OAuth, a site may never implement token introspection nor may it do it the way you describe.  Why would that be a problem?  Why should the group spend time on something where there may be no inter-op need.

Now that said, if you are in the UMA community.  Inter-op is quite foundational.  It is very very important. But then maybe the spec should be defined within UMA?


On Jul 28, 2014, at 5:39 PM, Justin Richer <jricher@MIT.EDU> wrote:

It's analogous to JWT in many ways: when you've got the AS and the RS separated somehow (different box, different domain, even different software vendor) and you need to communicate a set of information about the approval delegation from the AS (who has the context to know about it) through to the RS (who needs to know about it to make the authorization call). JWT gives us an interoperable way to do this by passing values inside the token itself, introspection gives a way to pass the values by reference via the token as an artifact. The two are complementary, and there are even cases where you'd want to deploy them together.

 -- Justin

On 7/28/2014 8:11 PM, Phil Hunt wrote:
Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/


On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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




--
Thomas Broyer
/tÉ”.ma.bÊwa.je/
_______________________________________________
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


--------------040100070400000109050509-- From nobody Mon Jul 28 23:57:06 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150CD1A0233 for ; Mon, 28 Jul 2014 23:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 O6z4ITnh4bYW for ; Mon, 28 Jul 2014 23:57:02 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19EA1A00B8 for ; Mon, 28 Jul 2014 23:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2324; q=dns/txt; s=iport; t=1406617022; x=1407826622; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=754nklsAWSbnTTNUH+ihUVDOm/5qO8hrM9KoA71JJco=; b=jHLkC8XoCzUW7rtRQ2TRdipmYwwaenuj22xTwnIre+/1EXTjuWzG4OWk itPGfyS3BpTgMZ/jbcoKywdUCc1yVOG7qMJVYaMt8TJBe4D41nNQYpyyj EGs6vaWAgeYj6yKPn8YuUKW0E2iWOVikALC+38pbZVuAM70zUbz/dPC+B k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAFNF11OtJV2S/2dsb2JhbABZgw5SVwSCdMkUh0sBGXkWd4QDAQEBBB0GEToXBAIBCBEEAQEDAgYZBAMCAgIwFAEICAIEARIIiDoNp0mXXReBLI1PAQEeFiIGgnM2gRsBBJ0eknqCA4FGbIEFBxcGHA X-IronPort-AV: E=Sophos;i="5.01,755,1400025600"; d="scan'208";a="64787823" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 29 Jul 2014 06:57:02 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6T6v2wu005912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 06:57:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 01:57:01 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item Thread-Index: AQHPqooPziDikvoCDEyWh/+CHL2pVJu2nGvg Date: Tue, 29 Jul 2014 06:57:01 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282FC64D@xmb-rcd-x10.cisco.com> References: <53D6895F.4050104@gmx.net> In-Reply-To: <53D6895F.4050104@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.40.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6LAq2TVxwD0DMV0geKgmaIsjgfA Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 06:57:04 -0000 KzEgc3VwcG9ydCBmb3IgYWRvcHRpb24uIFRoaXMgZHJhZnQgaXMgdXNlZnVsIGZvciBQQ1AgdGhp cmQgcGFydHkgYXV0aG9yaXphdGlvbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13 aW5nLXBjcC10aGlyZC1wYXJ0eS1hdXRoei0wMywgd2hlcmUgUENQIHNlcnZlciBpbiB0aGUgRW50 ZXJwcmlzZSBuZXR3b3JrIChSZXNvdXJjZSBzZXJ2ZXIpIGFuZCBXZWJSVEMgc2VydmVyIChBdXRo b3JpemF0aW9uIHNlcnZlcikgYXJlIGluIGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2ZSBkb21haW5z LiBQQ1AgdGhpcmQgcGFydHkgYXV0aG9yaXphdGlvbiBpcyB1c2luZyBoYW5kbGUgdG9rZW4gYW5k IG5lZWQgYSBzdGFuZGFyZCBjb21tdW5pY2F0aW9uIG1lY2hhbmlzbSBiL3cgUlMgYW5kIEFTIHRv IHZhbGlkYXRlIHRva2VuLiBSUyBhbmQgQVMgYXJlIHByb3ZpZGVkIGJ5IGRpZmZlcmVudCB2ZW5k b3JzIGFuZCBuZWVkIGludGVyb3BlcmFiaWxpdHkuDQoNCi1UaXJ1DQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWcNCj4gU2VudDogTW9uZGF5LCBKdWx5 IDI4LCAyMDE0IDExOjAzIFBNDQo+IFRvOiBvYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbT0FV VEgtV0ddIENvbmZpcm1hdGlvbjogQ2FsbCBmb3IgQWRvcHRpb24gb2YgIk9BdXRoIFRva2VuDQo+ IEludHJvc3BlY3Rpb24iIGFzIGFuIE9BdXRoIFdvcmtpbmcgR3JvdXAgSXRlbQ0KPiANCj4gSGkg YWxsLA0KPiANCj4gZHVyaW5nIHRoZSBJRVRGICM5MCBPQXV0aCBXRyBtZWV0aW5nLCB0aGVyZSB3 YXMgc3Ryb25nIGNvbnNlbnN1cyBpbiBhZG9wdGluZw0KPiB0aGUgIk9BdXRoIFRva2VuIEludHJv c3BlY3Rpb24iDQo+IChkcmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVjdGlvbi0wNi50eHQpIHNw ZWNpZmljYXRpb24gYXMgYW4gT0F1dGggV0cgd29yaw0KPiBpdGVtLg0KPiANCj4gV2Ugd291bGQg bm93IGxpa2UgdG8gdmVyaWZ5IHRoZSBvdXRjb21lIG9mIHRoaXMgY2FsbCBmb3IgYWRvcHRpb24g b24gdGhlIE9BdXRoDQo+IFdHIG1haWxpbmcgbGlzdC4gSGVyZSBpcyB0aGUgbGluayB0byB0aGUg ZG9jdW1lbnQ6DQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmljaGVy LW9hdXRoLWludHJvc3BlY3Rpb24vDQo+IA0KPiBJZiB5b3UgZGlkIG5vdCBodW0gYXQgdGhlIElF VEYgOTAgT0F1dGggV0cgbWVldGluZywgYW5kIGhhdmUgYW4gb3BpbmlvbiBhcyB0bw0KPiB0aGUg c3VpdGFiaWxpdHkgb2YgYWRvcHRpbmcgdGhpcyBkb2N1bWVudCBhcyBhIFdHIHdvcmsgaXRlbSwg cGxlYXNlIHNlbmQgbWFpbCB0bw0KPiB0aGUgT0F1dGggV0cgbGlzdCBpbmRpY2F0aW5nIHlvdXIg b3BpbmlvbiAoWWVzL05vKS4NCj4gDQo+IFRoZSBjb25maXJtYXRpb24gY2FsbCBmb3IgYWRvcHRp b24gd2lsbCBsYXN0IHVudGlsIEF1Z3VzdCAxMCwgMjAxNC4gIElmIHlvdSBoYXZlDQo+IGlzc3Vl cy9lZGl0cy9jb21tZW50cyBvbiB0aGUgZG9jdW1lbnQsIHBsZWFzZSBzZW5kIHRoZXNlIGNvbW1l bnRzIGFsb25nIHRvDQo+IHRoZSBsaXN0IGluIHlvdXIgcmVzcG9uc2UgdG8gdGhpcyBDYWxsIGZv ciBBZG9wdGlvbi4NCj4gDQo+IENpYW8NCj4gSGFubmVzICYgRGVyZWsNCg0K From nobody Tue Jul 29 02:46:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D5B1A02F9 for ; Tue, 29 Jul 2014 02:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.795 X-Spam-Level: X-Spam-Status: No, score=0.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYOrewuIqKvZ for ; Tue, 29 Jul 2014 02:46:45 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02AF21A0311 for ; Tue, 29 Jul 2014 02:46:44 -0700 (PDT) Received: from speedym.lan (ip5651156e.adsl-surfen.hetnet.nl [86.81.21.110]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id s6T9kcUN031561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 Jul 2014 11:46:40 +0200 (CEST) (envelope-from mdobrinic@cozmanova.com) Message-ID: <53D76D7E.5090905@cozmanova.com> Date: Tue, 29 Jul 2014 11:46:38 +0200 From: Mark Dobrinic User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Justin Richer , Phil Hunt References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D6ED5A.10500@mit.edu> <33F1EE39-2BDF-4F3D-B4DD-4AB9848BC4BF@oracle.com> <53D6F7A5.3070209@mit.edu> In-Reply-To: <53D6F7A5.3070209@mit.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/botSF4QVhApOAsJiY1EEVymXMzQ Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 09:46:51 -0000 Just some way I could look at this discussion: One way to separate an AS and an RS is specified by UMA, so for UMA it is required to have a standardized Token Introspection feature. If there are no other uses for separating AS/RS, then UMA would be the place for standardizing Token Introspection. On the other hand, if there might be other uses for a standardized Token Introspection, then it would make the most sense that it would be made a feature of the set of OAuth specifications. Personally, I've been surprised to find that the main OAuth spec does not specify a standard way to return a token's info. Cheers! Mark On 29/07/14 03:23, Justin Richer wrote: > I think this perspective has a lot to do with your idea of OAuth's > deployment model. You're right in that many people bundle the RS and the > AS very tightly, but that's not always case, nor is it desirable. We're > increasingly seeing cases where a group (often an enterprise) has their > own AS on premises and wants to stand up an RS from a vendor. Without a > means to connect the RS to the AS in a standard way, you're stuck with > using whatever AS the RS vendor wants to sell you along side their RS. > But with the right mechanisms (like JWT and token introspection), you're > able to connect the RS from one vendor to the AS from another vendor, > and it works together. I'm not sure what's unclear, but this is the very > definition of interoperability. > > This is to say nothing of simply being able to locate the RS remotely > from the AS within a particular security domain and still use > artifact-style tokens (ie, tokens that don't encode everything within > them). > > I have already had to deal directly with several cases of RS'es and > AS'es from different vendors doing effectively the token introspection > thing in different ways, in protecting vanilla OAuth within a single > security domain. They were doing it slightly differently for no > compelling reason other than having to invent the "I have a token and > need to look it up" mechanism independently. When both sides were able > to speak the same token introspection protocol (based on the individual > draft I'd submitted), then we could actually make things work. And none > of this was running UMA, which also makes use of this. > > I really don't see JWT as any different. To borrow your statement: In > OAuth, a site may never implement JWT nor may it do it in the way that > JWT describes. Why would that be a problem? (Hint: it isn't, they're > free to do whatever token they want. Same with introspection, it's a > tool that you can use if it makes sense for you to use it. So far a > whole bunch of people have said it makes sense.) > > -- Justin > > On 7/28/2014 8:59 PM, Phil Hunt wrote: >> That doesn’t explain the need for inter-operability. What you’ve >> described is what will be common practice. >> >> It’s a great open source technique, but that’s not a standard. >> >> JWT is much different. JWT is a foundational specification that >> describes the construction and parsing of JSON based tokens. There is >> inter-op with token formats that build on top and there is inter-op >> between every communicating party. >> >> In OAuth, a site may never implement token introspection nor may it do >> it the way you describe. Why would that be a problem? Why should the >> group spend time on something where there may be no inter-op need. >> >> Now that said, if you are in the UMA community. Inter-op is quite >> foundational. It is very very important. But then maybe the spec >> should be defined within UMA? >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> On Jul 28, 2014, at 5:39 PM, Justin Richer > > wrote: >> >>> It's analogous to JWT in many ways: when you've got the AS and the RS >>> separated somehow (different box, different domain, even different >>> software vendor) and you need to communicate a set of information >>> about the approval delegation from the AS (who has the context to >>> know about it) through to the RS (who needs to know about it to make >>> the authorization call). JWT gives us an interoperable way to do this >>> by passing values inside the token itself, introspection gives a way >>> to pass the values by reference via the token as an artifact. The two >>> are complementary, and there are even cases where you'd want to >>> deploy them together. >>> >>> -- Justin >>> >>> On 7/28/2014 8:11 PM, Phil Hunt wrote: >>>> Could we have some discussion on the interop cases? >>>> >>>> Is it driven by scenarios where AS and resource are separate >>>> domains? Or may this be only of interest to specific protocols like UMA? >>>> >>>> From a technique principle, the draft is important and sound. I am >>>> just not there yet on the reasons for an interoperable standard. >>>> >>>> Phil >>>> >>>> On Jul 28, 2014, at 17:00, Thomas Broyer >>> > wrote: >>>> >>>>> Yes. This spec is of special interest to the platform we're >>>>> building for http://www.oasis-eu.org/ >>>>> >>>>> >>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>>> > wrote: >>>>> >>>>> Hi all, >>>>> >>>>> during the IETF #90 OAuth WG meeting, there was strong consensus in >>>>> adopting the "OAuth Token Introspection" >>>>> (draft-richer-oauth-introspection-06.txt) specification as an >>>>> OAuth WG >>>>> work item. >>>>> >>>>> We would now like to verify the outcome of this call for >>>>> adoption on the >>>>> OAuth WG mailing list. Here is the link to the document: >>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>>> >>>>> If you did not hum at the IETF 90 OAuth WG meeting, and have an >>>>> opinion >>>>> as to the suitability of adopting this document as a WG work item, >>>>> please send mail to the OAuth WG list indicating your opinion >>>>> (Yes/No). >>>>> >>>>> The confirmation call for adoption will last until August 10, >>>>> 2014. If >>>>> you have issues/edits/comments on the document, please send these >>>>> comments along to the list in your response to this Call for >>>>> Adoption. >>>>> >>>>> Ciao >>>>> Hannes & Derek >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Broyer >>>>> /tÉ”.ma.bÊwa.je/ >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Tue Jul 29 02:48:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E63A1A0311 for ; Tue, 29 Jul 2014 02:48:00 -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 rc8PdxRKJ-Vh for ; Tue, 29 Jul 2014 02:47:58 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4234B1A02F9 for ; Tue, 29 Jul 2014 02:47:58 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id x19so8321008ier.20 for ; Tue, 29 Jul 2014 02:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=fF8SCPXHRzvJF9gPPYZ57nJ10CcSrmO4nXGvsBHU2F8=; b=MMYf5JZLXVly2JJlNZsjNvFoukKJKjqlICZHu2/DbOghV45w3qPm16bCOgUb8TtUrx WIIHxrtL8Li19iW52oeklnv0DaDhJyyVGN1wzxcCl5Z7CALVcmaWyytNJFXFbdtsHSWv ex8D4JvJ/lg8YToq88/JwvwUSf0Sm+SZQrDPttHPk1Iw6ZinzVQ76H3o7HAy//U7kANv 32g1UjJmGTiqdyFUSNa9OQfdHwiPncrp3F69Wdl8oIOz0ZjG/qZD/mZ7oLNMaJBsb31E suVWOGHCjel8JqixSZZny9b9ZwgbEiuUEC+5xLfFb7VNSHpK+JzjQklkDJPXTDv9SrjI Y60w== X-Received: by 10.42.201.204 with SMTP id fb12mr3818558icb.57.1406627277691; Tue, 29 Jul 2014 02:47:57 -0700 (PDT) Received: from [192.168.1.17] (CPE14109fe647a3-CMbc1401e98fa0.cpe.net.cable.rogers.com. [99.240.78.36]) by mx.google.com with ESMTPSA id l9sm8515219ige.2.2014.07.29.02.47.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 02:47:57 -0700 (PDT) References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D6ED5A.10500@mit.edu> <33F1EE39-2BDF-4F3D-B4DD-4AB9848BC4BF@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: <33F1EE39-2BDF-4F3D-B4DD-4AB9848BC4BF@oracle.com> Content-Type: multipart/alternative; boundary=Apple-Mail-BD2D6EB0-69F3-4211-856E-E80860BCE094 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (11D257) From: Paul Madsen Date: Tue, 29 Jul 2014 05:47:55 -0400 To: Phil Hunt Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jih1ozoTri68M-4Raeeqak8HHqs Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 09:48:00 -0000 --Apple-Mail-BD2D6EB0-69F3-4211-856E-E80860BCE094 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Standardized Introspection will be valuable in NAPPS, where the AS and RS ma= y be in different policy domains. Even for single policy domains, there are enterprise scenarios where the RS i= s from a different vendor than the AS, such as when an API gateway validates= tokens issued by an 'IdP' . We've necessarily defined our own introspection= endpoint and our gateway partners have implemented it, (at the instruction o= f the customer in question). But of course it's proprietary to us. Paul > On Jul 28, 2014, at 8:59 PM, Phil Hunt wrote: >=20 > That doesn=E2=80=99t explain the need for inter-operability. What you=E2=80= =99ve described is what will be common practice. >=20 > It=E2=80=99s a great open source technique, but that=E2=80=99s not a stand= ard. >=20 > JWT is much different. JWT is a foundational specification that describes t= he construction and parsing of JSON based tokens. There is inter-op with tok= en formats that build on top and there is inter-op between every communicati= ng party. >=20 > In OAuth, a site may never implement token introspection nor may it do it t= he way you describe. Why would that be a problem? Why should the group spe= nd time on something where there may be no inter-op need. >=20 > Now that said, if you are in the UMA community. Inter-op is quite foundat= ional. It is very very important. But then maybe the spec should be defined= within UMA? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >> On Jul 28, 2014, at 5:39 PM, Justin Richer wrote: >>=20 >> It's analogous to JWT in many ways: when you've got the AS and the RS sep= arated somehow (different box, different domain, even different software ven= dor) and you need to communicate a set of information about the approval del= egation from the AS (who has the context to know about it) through to the RS= (who needs to know about it to make the authorization call). JWT gives us a= n interoperable way to do this by passing values inside the token itself, in= trospection gives a way to pass the values by reference via the token as an a= rtifact. The two are complementary, and there are even cases where you'd wan= t to deploy them together. >>=20 >> -- Justin >>=20 >>> On 7/28/2014 8:11 PM, Phil Hunt wrote: >>> Could we have some discussion on the interop cases? >>>=20 >>> Is it driven by scenarios where AS and resource are separate domains? Or= may this be only of interest to specific protocols like UMA? >>>=20 >>> =46rom a technique principle, the draft is important and sound. I am jus= t not there yet on the reasons for an interoperable standard.=20 >>>=20 >>> Phil >>>=20 >>> On Jul 28, 2014, at 17:00, Thomas Broyer wrote: >>>=20 >>>> Yes. This spec is of special interest to the platform we're building fo= r http://www.oasis-eu.org/ >>>>=20 >>>>=20 >>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig wrote: >>>>> Hi all, >>>>>=20 >>>>> during the IETF #90 OAuth WG meeting, there was strong consensus in >>>>> adopting the "OAuth Token Introspection" >>>>> (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG= >>>>> work item. >>>>>=20 >>>>> We would now like to verify the outcome of this call for adoption on t= he >>>>> OAuth WG mailing list. Here is the link to the document: >>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>>>=20 >>>>> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinio= n >>>>> as to the suitability of adopting this document as a WG work item, >>>>> please send mail to the OAuth WG list indicating your opinion (Yes/No)= . >>>>>=20 >>>>> The confirmation call for adoption will last until August 10, 2014. I= f >>>>> you have issues/edits/comments on the document, please send these >>>>> comments along to the list in your response to this Call for Adoption.= >>>>>=20 >>>>> Ciao >>>>> Hannes & Derek >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Thomas Broyer >>>> /t=C9=94.ma.b=CA=81wa.je/ >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-BD2D6EB0-69F3-4211-856E-E80860BCE094 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Standardized Introspection will be val= uable in NAPPS, where the AS and RS may be in different policy domains.

Even for single policy domains, there are enterprise sc= enarios where the RS is from a different vendor than the AS, such as when an= API gateway validates tokens issued by an 'IdP' . We've necessarily defined= our own introspection endpoint and our gateway partners have implemented it= , (at the instruction of the customer in question). But of course it's propr= ietary to us.

Paul

On Jul 28, 2014, a= t 8:59 PM, Phil Hunt <phil.hunt@o= racle.com> wrote:

That doesn=E2= =80=99t explain the need for inter-operability. What you=E2=80=99ve describe= d is what will be common practice.

It=E2=80=99s a great o= pen source technique, but that=E2=80=99s not a standard.

JWT is much different. JWT is a foundational specification that descri= bes the construction and parsing of JSON based tokens. There is inter-op wit= h token formats that build on top and there is inter-op between every commun= icating party.

In OAuth, a site may never implement= token introspection nor may it do it the way you describe.  Why would t= hat be a problem?  Why should the group spend time on something where t= here may be no inter-op need.

Now that said, if you= are in the UMA community.  Inter-op is quite foundational.  It is= very very important. But then maybe the spec should be defined within UMA?<= /div>



=20 =20
It's analogous to JWT in many ways: when you've got the AS and the RS separated somehow (different box, different domain, even different software vendor) and you need to communicate a set of information about the approval delegation from the AS (who has the context to know about it) through to the RS (who needs to know about it to make the authorization call). JWT gives us an interoperable way to do this by passing values inside the token itself, introspection gives a way to pass the values by reference via the token as an artifact. The two are complementary, and there are even cases where you'd want to deploy them together.

 -- Justin

On 7/28/2014 8:11 PM, Phil Hunt wrote:
Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

=46rom a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/


On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tsc= hofenig@gmx.net> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
= http://datatrac= ker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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




--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
_______________________________________________ OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= br> 


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

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

= --Apple-Mail-BD2D6EB0-69F3-4211-856E-E80860BCE094-- From nobody Tue Jul 29 10:15:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B171D1B2925 for ; Tue, 29 Jul 2014 10:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0zTBItz9-dK for ; Tue, 29 Jul 2014 10:15:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD851B2920 for ; Tue, 29 Jul 2014 10:15:29 -0700 (PDT) Received: from BN3PR0301CA0061.namprd03.prod.outlook.com (25.160.152.157) by BLUPR03MB246.namprd03.prod.outlook.com (10.255.213.18) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 29 Jul 2014 17:15:28 +0000 Received: from BN1AFFO11FD013.protection.gbl (2a01:111:f400:7c10::177) by BN3PR0301CA0061.outlook.office365.com (2a01:111:e400:401e::29) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Tue, 29 Jul 2014 17:15:28 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD013.mail.protection.outlook.com (10.58.52.73) with Microsoft SMTP Server (TLS) id 15.0.990.10 via Frontend Transport; Tue, 29 Jul 2014 17:15:28 +0000 Received: from TK5EX14MBXC293.redmond.corp.microsoft.com ([169.254.2.111]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0195.002; Tue, 29 Jul 2014 17:15:21 +0000 From: Mike Jones To: Paul Madsen , Phil Hunt Thread-Topic: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item Thread-Index: AQHPqooP3+C2DjUTZkSSZigQ7bEA65u2KzcAgAAC6YCAAAgGAIAABVyAgACTwYCAAHuPUA== Date: Tue, 29 Jul 2014 17:15:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADF615D@TK5EX14MBXC293.redmond.corp.microsoft.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D6ED5A.10500@mit.edu> <33F1EE39-2BDF-4F3D-B4DD-4AB9848BC4BF@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADF615DTK5EX14MBXC293r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(53754006)(479174003)(377454003)(24454002)(199002)(189002)(55846006)(83322001)(79102001)(84326002)(107046002)(99396002)(80022001)(95666004)(106116001)(84676001)(81156004)(77096002)(106466001)(21056001)(76482001)(31966008)(66066001)(50986999)(77982001)(15975445006)(6806004)(19617315012)(104016003)(54356999)(16236675004)(87936001)(68736004)(15974865002)(76176999)(19580405001)(93886003)(46102001)(15202345003)(19580395003)(19300405004)(64706001)(86362001)(4396001)(20776003)(74662001)(19625215002)(74502001)(83072002)(44976005)(81542001)(26826002)(16601075003)(86612001)(69596002)(92566001)(85306003)(33656002)(97736001)(81342001)(71186001)(512874002)(2656002)(85852003)(92726001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB246; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0287BBA78D Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/G3rxv_1WZRanwZx2yRhem9XcRTA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 17:15:35 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADF615DTK5EX14MBXC293r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSSBzZWUgaXQsIHRoZXJlIGFyZSB0d28gZGlmZmVyZW50IGtpbmRzIG9mIHN0YW5kYXJkaXph dGlvbiBmb3IgaW50cm9zcGVjdGlvbiB0aGF0IGNvdWxkIG9jY3VyLiAgT25lIGlzIGRlZmluaW5n IGEgc3RhbmRhcmQgZW5kcG9pbnQgZm9yIGRvaW5nIGludHJvc3BlY3Rpb24gb24gYW4gYWNjZXNz IHRva2VuIGFuZCBwb3NzaWJseSByZWZyZXNoIHRva2VuLiAgVGhlIG90aGVyIGlzIGRlZmluaW5n IHN0YW5kYXJkIGNvbnRlbnRzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlIGludHJvc3BlY3Rpb24u DQoNCknigJltIHNrZXB0aWNhbCBvZiB0aGUgc3RhbmRhcmQgY29udGVudHMsIGdpdmVuIHRoYXQg YWNjZXNzIHRva2VucyBhbmQgcmVmcmVzaCB0b2tlbnMgYXJlIGludGVudGlvbmFsbHkgb3BhcXVl LiAgSW1wbGVtZW50YXRpb25zIGNvdWxkIHJhbmdlIGZyb20gYmVpbmcgYW4gaW50ZWdlciBpbmRl eCBpbnRvIGEgZGF0YWJhc2UgdGFibGUsIHRvIGJlaW5nIGEgVVVJRCB0byBiZWluZyBhbiBlbmNy eXB0ZWQgSldUIHdpdGggY29udGV4dC1zcGVjaWZpYyBjbGFpbXMuICBJIGRvbuKAmXQgc2VlIGFu eXRoaW5nIGluIGNvbW1vbiBpbiB0aG9zZSBpbXBsZW1lbnRhdGlvbnMgZm9yIGludHJvc3BlY3Rp b24gdG8gcmV0dXJuLg0KDQpXaGlsZSBJIGNhbiBzZWUgbWFyZ2luYWwgdXRpbGl0eSB0byBoYXZp bmcgYSBjb21tb24gZW5kcG9pbnQgYW5kIHJlcXVlc3Qgc3ludGF4LCBJIHdvdWxkIGJlIGFnYWlu c3QgdHJ5aW5nIHRvIHN0YW5kYXJkaXplIHRoZSBjb250ZW50cyBvZiB3aGF0IGFuIGludHJvc3Bl Y3Rpb24gcmVxdWVzdCBtaWdodCByZXR1cm4uICBJdOKAmXMgYXMgZGVwbG95bWVudC1zcGVjaWZp YyBhcyB0aGUgYWNjZXNzIHRva2VuIHJlcHJlc2VudGF0aW9uIGl0c2VsZi4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlr ZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBQYXVsIE1hZHNlbg0KU2VudDogVHVlc2RheSwgSnVseSAyOSwgMjAxNCAyOjQ4IEFNDQpU bzogUGhpbCBIdW50DQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IENvbmZpcm1hdGlvbjogQ2FsbCBmb3IgQWRvcHRpb24gb2YgIk9BdXRoIFRva2VuIEludHJvc3Bl Y3Rpb24iIGFzIGFuIE9BdXRoIFdvcmtpbmcgR3JvdXAgSXRlbQ0KDQpTdGFuZGFyZGl6ZWQgSW50 cm9zcGVjdGlvbiB3aWxsIGJlIHZhbHVhYmxlIGluIE5BUFBTLCB3aGVyZSB0aGUgQVMgYW5kIFJT IG1heSBiZSBpbiBkaWZmZXJlbnQgcG9saWN5IGRvbWFpbnMuDQoNCkV2ZW4gZm9yIHNpbmdsZSBw b2xpY3kgZG9tYWlucywgdGhlcmUgYXJlIGVudGVycHJpc2Ugc2NlbmFyaW9zIHdoZXJlIHRoZSBS UyBpcyBmcm9tIGEgZGlmZmVyZW50IHZlbmRvciB0aGFuIHRoZSBBUywgc3VjaCBhcyB3aGVuIGFu IEFQSSBnYXRld2F5IHZhbGlkYXRlcyB0b2tlbnMgaXNzdWVkIGJ5IGFuICdJZFAnIC4gV2UndmUg bmVjZXNzYXJpbHkgZGVmaW5lZCBvdXIgb3duIGludHJvc3BlY3Rpb24gZW5kcG9pbnQgYW5kIG91 ciBnYXRld2F5IHBhcnRuZXJzIGhhdmUgaW1wbGVtZW50ZWQgaXQsIChhdCB0aGUgaW5zdHJ1Y3Rp b24gb2YgdGhlIGN1c3RvbWVyIGluIHF1ZXN0aW9uKS4gQnV0IG9mIGNvdXJzZSBpdCdzIHByb3By aWV0YXJ5IHRvIHVzLg0KDQpQYXVsDQoNCk9uIEp1bCAyOCwgMjAxNCwgYXQgODo1OSBQTSwgUGhp bCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+ PiB3cm90ZToNClRoYXQgZG9lc27igJl0IGV4cGxhaW4gdGhlIG5lZWQgZm9yIGludGVyLW9wZXJh YmlsaXR5LiBXaGF0IHlvdeKAmXZlIGRlc2NyaWJlZCBpcyB3aGF0IHdpbGwgYmUgY29tbW9uIHBy YWN0aWNlLg0KDQpJdOKAmXMgYSBncmVhdCBvcGVuIHNvdXJjZSB0ZWNobmlxdWUsIGJ1dCB0aGF0 4oCZcyBub3QgYSBzdGFuZGFyZC4NCg0KSldUIGlzIG11Y2ggZGlmZmVyZW50LiBKV1QgaXMgYSBm b3VuZGF0aW9uYWwgc3BlY2lmaWNhdGlvbiB0aGF0IGRlc2NyaWJlcyB0aGUgY29uc3RydWN0aW9u IGFuZCBwYXJzaW5nIG9mIEpTT04gYmFzZWQgdG9rZW5zLiBUaGVyZSBpcyBpbnRlci1vcCB3aXRo IHRva2VuIGZvcm1hdHMgdGhhdCBidWlsZCBvbiB0b3AgYW5kIHRoZXJlIGlzIGludGVyLW9wIGJl dHdlZW4gZXZlcnkgY29tbXVuaWNhdGluZyBwYXJ0eS4NCg0KSW4gT0F1dGgsIGEgc2l0ZSBtYXkg bmV2ZXIgaW1wbGVtZW50IHRva2VuIGludHJvc3BlY3Rpb24gbm9yIG1heSBpdCBkbyBpdCB0aGUg d2F5IHlvdSBkZXNjcmliZS4gIFdoeSB3b3VsZCB0aGF0IGJlIGEgcHJvYmxlbT8gIFdoeSBzaG91 bGQgdGhlIGdyb3VwIHNwZW5kIHRpbWUgb24gc29tZXRoaW5nIHdoZXJlIHRoZXJlIG1heSBiZSBu byBpbnRlci1vcCBuZWVkLg0KDQpOb3cgdGhhdCBzYWlkLCBpZiB5b3UgYXJlIGluIHRoZSBVTUEg Y29tbXVuaXR5LiAgSW50ZXItb3AgaXMgcXVpdGUgZm91bmRhdGlvbmFsLiAgSXQgaXMgdmVyeSB2 ZXJ5IGltcG9ydGFudC4gQnV0IHRoZW4gbWF5YmUgdGhlIHNwZWMgc2hvdWxkIGJlIGRlZmluZWQg d2l0aGluIFVNQT8NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQu Y29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQpPbiBKdWwgMjgsIDIwMTQsIGF0IDU6 MzkgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJATUlULkVEVTxtYWlsdG86anJpY2hlckBNSVQu RURVPj4gd3JvdGU6DQoNCg0KSXQncyBhbmFsb2dvdXMgdG8gSldUIGluIG1hbnkgd2F5czogd2hl biB5b3UndmUgZ290IHRoZSBBUyBhbmQgdGhlIFJTIHNlcGFyYXRlZCBzb21laG93IChkaWZmZXJl bnQgYm94LCBkaWZmZXJlbnQgZG9tYWluLCBldmVuIGRpZmZlcmVudCBzb2Z0d2FyZSB2ZW5kb3Ip IGFuZCB5b3UgbmVlZCB0byBjb21tdW5pY2F0ZSBhIHNldCBvZiBpbmZvcm1hdGlvbiBhYm91dCB0 aGUgYXBwcm92YWwgZGVsZWdhdGlvbiBmcm9tIHRoZSBBUyAod2hvIGhhcyB0aGUgY29udGV4dCB0 byBrbm93IGFib3V0IGl0KSB0aHJvdWdoIHRvIHRoZSBSUyAod2hvIG5lZWRzIHRvIGtub3cgYWJv dXQgaXQgdG8gbWFrZSB0aGUgYXV0aG9yaXphdGlvbiBjYWxsKS4gSldUIGdpdmVzIHVzIGFuIGlu dGVyb3BlcmFibGUgd2F5IHRvIGRvIHRoaXMgYnkgcGFzc2luZyB2YWx1ZXMgaW5zaWRlIHRoZSB0 b2tlbiBpdHNlbGYsIGludHJvc3BlY3Rpb24gZ2l2ZXMgYSB3YXkgdG8gcGFzcyB0aGUgdmFsdWVz IGJ5IHJlZmVyZW5jZSB2aWEgdGhlIHRva2VuIGFzIGFuIGFydGlmYWN0LiBUaGUgdHdvIGFyZSBj b21wbGVtZW50YXJ5LCBhbmQgdGhlcmUgYXJlIGV2ZW4gY2FzZXMgd2hlcmUgeW91J2Qgd2FudCB0 byBkZXBsb3kgdGhlbSB0b2dldGhlci4NCg0KIC0tIEp1c3Rpbg0KDQpPbiA3LzI4LzIwMTQgODox MSBQTSwgUGhpbCBIdW50IHdyb3RlOg0KQ291bGQgd2UgaGF2ZSBzb21lIGRpc2N1c3Npb24gb24g dGhlIGludGVyb3AgY2FzZXM/DQoNCklzIGl0IGRyaXZlbiBieSBzY2VuYXJpb3Mgd2hlcmUgQVMg YW5kIHJlc291cmNlIGFyZSBzZXBhcmF0ZSBkb21haW5zPyBPciBtYXkgdGhpcyBiZSBvbmx5IG9m IGludGVyZXN0IHRvIHNwZWNpZmljIHByb3RvY29scyBsaWtlIFVNQT8NCg0KRnJvbSBhIHRlY2hu aXF1ZSBwcmluY2lwbGUsIHRoZSBkcmFmdCBpcyBpbXBvcnRhbnQgYW5kIHNvdW5kLiBJIGFtIGp1 c3Qgbm90IHRoZXJlIHlldCBvbiB0aGUgcmVhc29ucyBmb3IgYW4gaW50ZXJvcGVyYWJsZSBzdGFu ZGFyZC4NCg0KUGhpbA0KDQpPbiBKdWwgMjgsIDIwMTQsIGF0IDE3OjAwLCBUaG9tYXMgQnJveWVy IDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+IHdyb3RlOg0K WWVzLiBUaGlzIHNwZWMgaXMgb2Ygc3BlY2lhbCBpbnRlcmVzdCB0byB0aGUgcGxhdGZvcm0gd2Un cmUgYnVpbGRpbmcgZm9yIGh0dHA6Ly93d3cub2FzaXMtZXUub3JnLw0KDQpPbiBNb24sIEp1bCAy OCwgMjAxNCBhdCA3OjMzIFBNLCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdA Z214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdyb3RlOg0KSGkgYWxs LA0KDQpkdXJpbmcgdGhlIElFVEYgIzkwIE9BdXRoIFdHIG1lZXRpbmcsIHRoZXJlIHdhcyBzdHJv bmcgY29uc2Vuc3VzIGluDQphZG9wdGluZyB0aGUgIk9BdXRoIFRva2VuIEludHJvc3BlY3Rpb24i DQooZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDYudHh0KSBzcGVjaWZpY2F0aW9u IGFzIGFuIE9BdXRoIFdHDQp3b3JrIGl0ZW0uDQoNCldlIHdvdWxkIG5vdyBsaWtlIHRvIHZlcmlm eSB0aGUgb3V0Y29tZSBvZiB0aGlzIGNhbGwgZm9yIGFkb3B0aW9uIG9uIHRoZQ0KT0F1dGggV0cg bWFpbGluZyBsaXN0LiBIZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBkb2N1bWVudDoNCmh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24v DQoNCklmIHlvdSBkaWQgbm90IGh1bSBhdCB0aGUgSUVURiA5MCBPQXV0aCBXRyBtZWV0aW5nLCBh bmQgaGF2ZSBhbiBvcGluaW9uDQphcyB0byB0aGUgc3VpdGFiaWxpdHkgb2YgYWRvcHRpbmcgdGhp cyBkb2N1bWVudCBhcyBhIFdHIHdvcmsgaXRlbSwNCnBsZWFzZSBzZW5kIG1haWwgdG8gdGhlIE9B dXRoIFdHIGxpc3QgaW5kaWNhdGluZyB5b3VyIG9waW5pb24gKFllcy9ObykuDQoNClRoZSBjb25m aXJtYXRpb24gY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBsYXN0IHVudGlsIEF1Z3VzdCAxMCwgMjAx NC4gIElmDQp5b3UgaGF2ZSBpc3N1ZXMvZWRpdHMvY29tbWVudHMgb24gdGhlIGRvY3VtZW50LCBw bGVhc2Ugc2VuZCB0aGVzZQ0KY29tbWVudHMgYWxvbmcgdG8gdGhlIGxpc3QgaW4geW91ciByZXNw b25zZSB0byB0aGlzIENhbGwgZm9yIEFkb3B0aW9uLg0KDQpDaWFvDQpIYW5uZXMgJiBEZXJlaw0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpUaG9t YXMgQnJveWVyDQovdMmULm1hLmLKgXdhLmplLzxodHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4 Yi5qZS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1h aWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQo= --_000_4E1F6AAD24975D4BA5B16804296739439ADF615DTK5EX14MBXC293r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxl LXN0eWxlLXNwYW47fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgSSBz ZWUgaXQsIHRoZXJlIGFyZSB0d28gZGlmZmVyZW50IGtpbmRzIG9mIHN0YW5kYXJkaXphdGlvbiBm b3IgaW50cm9zcGVjdGlvbiB0aGF0IGNvdWxkIG9jY3VyLiZuYnNwOyBPbmUgaXMgZGVmaW5pbmcg YSBzdGFuZGFyZCBlbmRwb2ludCBmb3IgZG9pbmcgaW50cm9zcGVjdGlvbg0KIG9uIGFuIGFjY2Vz cyB0b2tlbiBhbmQgcG9zc2libHkgcmVmcmVzaCB0b2tlbi4mbmJzcDsgVGhlIG90aGVyIGlzIGRl ZmluaW5nIHN0YW5kYXJkIGNvbnRlbnRzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlIGludHJvc3Bl Y3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5J4oCZbSBza2VwdGljYWwgb2YgdGhlIHN0YW5kYXJkIGNvbnRlbnRz LCBnaXZlbiB0aGF0IGFjY2VzcyB0b2tlbnMgYW5kIHJlZnJlc2ggdG9rZW5zIGFyZSBpbnRlbnRp b25hbGx5IG9wYXF1ZS4mbmJzcDsgSW1wbGVtZW50YXRpb25zIGNvdWxkIHJhbmdlIGZyb20gYmVp bmcgYW4gaW50ZWdlcg0KIGluZGV4IGludG8gYSBkYXRhYmFzZSB0YWJsZSwgdG8gYmVpbmcgYSBV VUlEIHRvIGJlaW5nIGFuIGVuY3J5cHRlZCBKV1Qgd2l0aCBjb250ZXh0LXNwZWNpZmljIGNsYWlt cy4mbmJzcDsgSSBkb27igJl0IHNlZSBhbnl0aGluZyBpbiBjb21tb24gaW4gdGhvc2UgaW1wbGVt ZW50YXRpb25zIGZvciBpbnRyb3NwZWN0aW9uIHRvIHJldHVybi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoaWxlIEkg Y2FuIHNlZSBtYXJnaW5hbCB1dGlsaXR5IHRvIGhhdmluZyBhIGNvbW1vbiBlbmRwb2ludCBhbmQg cmVxdWVzdCBzeW50YXgsIEkgd291bGQgYmUgYWdhaW5zdCB0cnlpbmcgdG8gc3RhbmRhcmRpemUg dGhlIGNvbnRlbnRzIG9mIHdoYXQgYW4gaW50cm9zcGVjdGlvbg0KIHJlcXVlc3QgbWlnaHQgcmV0 dXJuLiZuYnNwOyBJdOKAmXMgYXMgZGVwbG95bWVudC1zcGVjaWZpYyBhcyB0aGUgYWNjZXNzIHRv a2VuIHJlcHJlc2VudGF0aW9uIGl0c2VsZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QYXVsIE1hZHNlbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBKdWx5IDI5LCAyMDE0IDI6NDggQU08YnI+DQo8Yj5Ubzo8L2I+IFBoaWwgSHVudDxicj4N CjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVU SC1XR10gQ29uZmlybWF0aW9uOiBDYWxsIGZvciBBZG9wdGlvbiBvZiAmcXVvdDtPQXV0aCBUb2tl biBJbnRyb3NwZWN0aW9uJnF1b3Q7IGFzIGFuIE9BdXRoIFdvcmtpbmcgR3JvdXAgSXRlbTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdGFuZGFy ZGl6ZWQgSW50cm9zcGVjdGlvbiB3aWxsIGJlIHZhbHVhYmxlIGluIE5BUFBTLCB3aGVyZSB0aGUg QVMgYW5kIFJTIG1heSBiZSBpbiBkaWZmZXJlbnQgcG9saWN5IGRvbWFpbnMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV2ZW4gZm9yIHNpbmds ZSBwb2xpY3kgZG9tYWlucywgdGhlcmUgYXJlIGVudGVycHJpc2Ugc2NlbmFyaW9zIHdoZXJlIHRo ZSBSUyBpcyBmcm9tIGEgZGlmZmVyZW50IHZlbmRvciB0aGFuIHRoZSBBUywgc3VjaCBhcyB3aGVu IGFuIEFQSSBnYXRld2F5IHZhbGlkYXRlcyB0b2tlbnMgaXNzdWVkIGJ5IGFuICdJZFAnIC4gV2Un dmUgbmVjZXNzYXJpbHkgZGVmaW5lZCBvdXIgb3duIGludHJvc3BlY3Rpb24gZW5kcG9pbnQNCiBh bmQgb3VyIGdhdGV3YXkgcGFydG5lcnMgaGF2ZSBpbXBsZW1lbnRlZCBpdCwgKGF0IHRoZSBpbnN0 cnVjdGlvbiBvZiB0aGUgY3VzdG9tZXIgaW4gcXVlc3Rpb24pLiBCdXQgb2YgY291cnNlIGl0J3Mg cHJvcHJpZXRhcnkgdG8gdXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlBhdWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVs IDI4LCAyMDE0LCBhdCA4OjU5IFBNLCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBk b2VzbuKAmXQgZXhwbGFpbiB0aGUgbmVlZCBmb3IgaW50ZXItb3BlcmFiaWxpdHkuIFdoYXQgeW91 4oCZdmUgZGVzY3JpYmVkIGlzIHdoYXQgd2lsbCBiZSBjb21tb24gcHJhY3RpY2UuPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdOKAmXMgYSBncmVhdCBvcGVu IHNvdXJjZSB0ZWNobmlxdWUsIGJ1dCB0aGF04oCZcyBub3QgYSBzdGFuZGFyZC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SldUIGlzIG11Y2gg ZGlmZmVyZW50LiBKV1QgaXMgYSBmb3VuZGF0aW9uYWwgc3BlY2lmaWNhdGlvbiB0aGF0IGRlc2Ny aWJlcyB0aGUgY29uc3RydWN0aW9uIGFuZCBwYXJzaW5nIG9mIEpTT04gYmFzZWQgdG9rZW5zLiBU aGVyZSBpcyBpbnRlci1vcCB3aXRoIHRva2VuIGZvcm1hdHMgdGhhdCBidWlsZCBvbiB0b3AgYW5k IHRoZXJlIGlzIGludGVyLW9wIGJldHdlZW4gZXZlcnkgY29tbXVuaWNhdGluZyBwYXJ0eS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gT0F1 dGgsIGEgc2l0ZSBtYXkgbmV2ZXIgaW1wbGVtZW50IHRva2VuIGludHJvc3BlY3Rpb24gbm9yIG1h eSBpdCBkbyBpdCB0aGUgd2F5IHlvdSBkZXNjcmliZS4gJm5ic3A7V2h5IHdvdWxkIHRoYXQgYmUg YSBwcm9ibGVtPyAmbmJzcDtXaHkgc2hvdWxkIHRoZSBncm91cCBzcGVuZCB0aW1lIG9uIHNvbWV0 aGluZyB3aGVyZSB0aGVyZSBtYXkgYmUgbm8gaW50ZXItb3AgbmVlZC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm93IHRoYXQgc2FpZCwgaWYg eW91IGFyZSBpbiB0aGUgVU1BIGNvbW11bml0eS4gJm5ic3A7SW50ZXItb3AgaXMgcXVpdGUgZm91 bmRhdGlvbmFsLiAmbmJzcDtJdCBpcyB2ZXJ5IHZlcnkgaW1wb3J0YW50LiBCdXQgdGhlbiBtYXli ZSB0aGUgc3BlYyBzaG91bGQgYmUgZGVmaW5lZCB3aXRoaW4gVU1BPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iPnd3 dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBo cmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAyOCwgMjAxNCwgYXQgNTozOSBQTSwgSnVzdGluIFJp Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJATUlULkVEVSI+anJpY2hlckBNSVQuRURV PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JdCdzIGFuYWxvZ291cyB0byBKV1QgaW4gbWFueSB3YXlzOiB3aGVuIHlvdSd2 ZSBnb3QgdGhlIEFTIGFuZCB0aGUgUlMgc2VwYXJhdGVkIHNvbWVob3cgKGRpZmZlcmVudCBib3gs IGRpZmZlcmVudCBkb21haW4sIGV2ZW4gZGlmZmVyZW50IHNvZnR3YXJlIHZlbmRvcikgYW5kIHlv dSBuZWVkIHRvIGNvbW11bmljYXRlIGEgc2V0IG9mIGluZm9ybWF0aW9uIGFib3V0IHRoZSBhcHBy b3ZhbCBkZWxlZ2F0aW9uIGZyb20NCiB0aGUgQVMgKHdobyBoYXMgdGhlIGNvbnRleHQgdG8ga25v dyBhYm91dCBpdCkgdGhyb3VnaCB0byB0aGUgUlMgKHdobyBuZWVkcyB0byBrbm93IGFib3V0IGl0 IHRvIG1ha2UgdGhlIGF1dGhvcml6YXRpb24gY2FsbCkuIEpXVCBnaXZlcyB1cyBhbiBpbnRlcm9w ZXJhYmxlIHdheSB0byBkbyB0aGlzIGJ5IHBhc3NpbmcgdmFsdWVzIGluc2lkZSB0aGUgdG9rZW4g aXRzZWxmLCBpbnRyb3NwZWN0aW9uIGdpdmVzIGEgd2F5IHRvIHBhc3MgdGhlIHZhbHVlcw0KIGJ5 IHJlZmVyZW5jZSB2aWEgdGhlIHRva2VuIGFzIGFuIGFydGlmYWN0LiBUaGUgdHdvIGFyZSBjb21w bGVtZW50YXJ5LCBhbmQgdGhlcmUgYXJlIGV2ZW4gY2FzZXMgd2hlcmUgeW91J2Qgd2FudCB0byBk ZXBsb3kgdGhlbSB0b2dldGhlci48YnI+DQo8YnI+DQombmJzcDstLSBKdXN0aW48YnI+DQo8YnI+ DQpPbiA3LzI4LzIwMTQgODoxMSBQTSwgUGhpbCBIdW50IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db3VsZCB3ZSBoYXZlIHNvbWUg ZGlzY3Vzc2lvbiBvbiB0aGUgaW50ZXJvcCBjYXNlcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgaXQgZHJpdmVuIGJ5IHNjZW5hcmlvcyB3 aGVyZSBBUyBhbmQgcmVzb3VyY2UgYXJlIHNlcGFyYXRlIGRvbWFpbnM/IE9yIG1heSB0aGlzIGJl IG9ubHkgb2YgaW50ZXJlc3QgdG8gc3BlY2lmaWMgcHJvdG9jb2xzIGxpa2UgVU1BPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gcm9tIGEgdGVj aG5pcXVlIHByaW5jaXBsZSwgdGhlIGRyYWZ0IGlzIGltcG9ydGFudCBhbmQgc291bmQuIEkgYW0g anVzdCBub3QgdGhlcmUgeWV0IG9uIHRoZSByZWFzb25zIGZvciBhbiBpbnRlcm9wZXJhYmxlIHN0 YW5kYXJkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5QaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEp1bCAyOCwg MjAxNCwgYXQgMTc6MDAsIFRob21hcyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3ll ckBnbWFpbC5jb20iPnQuYnJveWVyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLiBU aGlzIHNwZWMgaXMgb2Ygc3BlY2lhbCBpbnRlcmVzdCB0byB0aGUgcGxhdGZvcm0gd2UncmUgYnVp bGRpbmcgZm9yJm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5vYXNpcy1ldS5vcmcvIj5odHRwOi8v d3d3Lm9hc2lzLWV1Lm9yZy88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgSnVsIDI4LCAy MDE0IGF0IDc6MzMgUE0sIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86aGFu bmVzLnRzY2hvZmVuaWdAZ214Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmhhbm5lcy50c2Nob2Zlbmln QGdteC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgYWxsLDxicj4NCjxicj4NCmR1cmlu ZyB0aGUgSUVURiAjOTAgT0F1dGggV0cgbWVldGluZywgdGhlcmUgd2FzIHN0cm9uZyBjb25zZW5z dXMgaW48YnI+DQphZG9wdGluZyB0aGUgJnF1b3Q7T0F1dGggVG9rZW4gSW50cm9zcGVjdGlvbiZx dW90Ozxicj4NCihkcmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVjdGlvbi0wNi50eHQpIHNwZWNp ZmljYXRpb24gYXMgYW4gT0F1dGggV0c8YnI+DQp3b3JrIGl0ZW0uPGJyPg0KPGJyPg0KV2Ugd291 bGQgbm93IGxpa2UgdG8gdmVyaWZ5IHRoZSBvdXRjb21lIG9mIHRoaXMgY2FsbCBmb3IgYWRvcHRp b24gb24gdGhlPGJyPg0KT0F1dGggV0cgbWFpbGluZyBsaXN0LiBIZXJlIGlzIHRoZSBsaW5rIHRv IHRoZSBkb2N1bWVudDo8YnI+DQo8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3Bl Y3Rpb24vPC9hPjxicj4NCjxicj4NCklmIHlvdSBkaWQgbm90IGh1bSBhdCB0aGUgSUVURiA5MCBP QXV0aCBXRyBtZWV0aW5nLCBhbmQgaGF2ZSBhbiBvcGluaW9uPGJyPg0KYXMgdG8gdGhlIHN1aXRh YmlsaXR5IG9mIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQgYXMgYSBXRyB3b3JrIGl0ZW0sPGJyPg0K cGxlYXNlIHNlbmQgbWFpbCB0byB0aGUgT0F1dGggV0cgbGlzdCBpbmRpY2F0aW5nIHlvdXIgb3Bp bmlvbiAoWWVzL05vKS48YnI+DQo8YnI+DQpUaGUgY29uZmlybWF0aW9uIGNhbGwgZm9yIGFkb3B0 aW9uIHdpbGwgbGFzdCB1bnRpbCBBdWd1c3QgMTAsIDIwMTQuICZuYnNwO0lmPGJyPg0KeW91IGhh dmUgaXNzdWVzL2VkaXRzL2NvbW1lbnRzIG9uIHRoZSBkb2N1bWVudCwgcGxlYXNlIHNlbmQgdGhl c2U8YnI+DQpjb21tZW50cyBhbG9uZyB0byB0aGUgbGlzdCBpbiB5b3VyIHJlc3BvbnNlIHRvIHRo aXMgQ2FsbCBmb3IgQWRvcHRpb24uPGJyPg0KPGJyPg0KQ2lhbzxicj4NCkhhbm5lcyAmYW1wOyBE ZXJlazxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NClRob21hcyBC cm95ZXI8YnI+DQovdDxhIGhyZWY9Imh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhiLmplLyI+ yZQubWEuYsqBd2EuamUvPC9hPiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFp bGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9B dXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739439ADF615DTK5EX14MBXC293r_-- From nobody Tue Jul 29 10:37:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BB91B296F for ; Tue, 29 Jul 2014 10:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 dJ2cqlkt0Qnr for ; Tue, 29 Jul 2014 10:37:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7F61B2963 for ; Tue, 29 Jul 2014 10:37:31 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DF37C1F2011; Tue, 29 Jul 2014 13:37:30 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C87351F1FFC; Tue, 29 Jul 2014 13:37:30 -0400 (EDT) Received: from [10.146.15.61] (10.140.19.249) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 29 Jul 2014 13:37:30 -0400 Message-ID: <53D7DBA6.1090505@mitre.org> Date: Tue, 29 Jul 2014 13:36:38 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mike Jones , Paul Madsen , Phil Hunt References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D6ED5A.10500@mit.edu> <33F1EE39-2BDF-4F3D-B4DD-4AB9848BC4BF@oracle.com> <4E1F6AAD24975D4BA5B16804296739439ADF615D@TK5EX14MBXC293.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADF615D@TK5EX14MBXC293.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------060202000400070109010609" X-Originating-IP: [10.140.19.249] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-cLQlcgTFPxVVqhR7ChmhjaCS8s Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 17:37:46 -0000 --------------060202000400070109010609 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I disagree with this position and think it's vital to standardize a return structure and a common set of return values -- and that this work would be rather pointless without it. Mike, I think you might be thinking in terms of introspection simply unpacking what's already contained inside the token, and the AS doing the effort of unpacking that for the RS. This is, after all, what used to be the case for the now-defunct OpenID Connect "CheckID Endpoint". But what's really happening here is this general pattern: - The client passes the token to the RS. The client doesn't know or care what's in the token or what it's used for, it just knows that it can use the token at the RS. - The RS gets the token and passes it along to the introspection endpoint on the AS. The means by which the RS figures out where its AS is is out of scope for this bit of work. - The AS is looking at the token as passed in, (whether it's structured like a JWT, a random UUID, an integer into a DB, whatever deployment-specific bit you want) and figures out if the token is any good and what it's for. The AS can do this in whatever deployment-specific way it wants to: look up the token in a DB, unpack the JWT and check the signature, decrypt the token's payload, whatever. - The AS returns (in a standardized JSON object) a set of claims about the token. While it's possible that these claims can be included in the token directly (as a JWT, for instance) and the RS could have read them if it knew how to parse said token, it's important that they don't have to be communicated that way and the token itself does not have to be structured at all. The AS can literally issue a token of "foo.bar.123" and the RS can do an introspection call to turn "foo.bar.123" into {valid: true, sub: user-person, aud: resource-server, ... } - The RS looks at the returned JSON value and uses that to make its authorization decision. It's imperative to note that the token in OAuth is opaque to the *client* -- it is not opaque to other parties, namely the AS. And in most deployments, it's not opaque to the RS either, since the RS has to be able to turn the OAuth token into something that can help it make authorization decisions. Having an introspection endpoint with a standardized return value would actually allow the token content itself to be opaque to the RS as well as the Client. All that said, I think there is enough variability and flexibility in OAuth deployments that the introspection data response should (and so far, has) follow the JWT model: define a core set of claims with clear semantics, make them all optional apart from the common "active" field, and allow for copious extension. It's a very simple, very useful pattern that's been implemented by many different developers. -- Justin On 07/29/2014 01:15 PM, Mike Jones wrote: > > As I see it, there are two different kinds of standardization for > introspection that could occur. One is defining a standard endpoint > for doing introspection on an access token and possibly refresh > token. The other is defining standard contents to be returned from > the introspection. > > I'm skeptical of the standard contents, given that access tokens and > refresh tokens are intentionally opaque. Implementations could range > from being an integer index into a database table, to being a UUID to > being an encrypted JWT with context-specific claims. I don't see > anything in common in those implementations for introspection to return. > > While I can see marginal utility to having a common endpoint and > request syntax, I would be against trying to standardize the contents > of what an introspection request might return. It's as > deployment-specific as the access token representation itself. > > -- Mike > > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Paul Madsen > *Sent:* Tuesday, July 29, 2014 2:48 AM > *To:* Phil Hunt > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth > Token Introspection" as an OAuth Working Group Item > > Standardized Introspection will be valuable in NAPPS, where the AS and > RS may be in different policy domains. > > Even for single policy domains, there are enterprise scenarios where > the RS is from a different vendor than the AS, such as when an API > gateway validates tokens issued by an 'IdP' . We've necessarily > defined our own introspection endpoint and our gateway partners have > implemented it, (at the instruction of the customer in question). But > of course it's proprietary to us. > > Paul > > > On Jul 28, 2014, at 8:59 PM, Phil Hunt > wrote: > > That doesn't explain the need for inter-operability. What you've > described is what will be common practice. > > It's a great open source technique, but that's not a standard. > > JWT is much different. JWT is a foundational specification that > describes the construction and parsing of JSON based tokens. There > is inter-op with token formats that build on top and there is > inter-op between every communicating party. > > In OAuth, a site may never implement token introspection nor may > it do it the way you describe. Why would that be a problem? Why > should the group spend time on something where there may be no > inter-op need. > > Now that said, if you are in the UMA community. Inter-op is quite > foundational. It is very very important. But then maybe the spec > should be defined within UMA? > > Phil > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > On Jul 28, 2014, at 5:39 PM, Justin Richer > wrote: > > > > It's analogous to JWT in many ways: when you've got the AS and the > RS separated somehow (different box, different domain, even > different software vendor) and you need to communicate a set of > information about the approval delegation from the AS (who has the > context to know about it) through to the RS (who needs to know > about it to make the authorization call). JWT gives us an > interoperable way to do this by passing values inside the token > itself, introspection gives a way to pass the values by reference > via the token as an artifact. The two are complementary, and there > are even cases where you'd want to deploy them together. > > -- Justin > > On 7/28/2014 8:11 PM, Phil Hunt wrote: > > Could we have some discussion on the interop cases? > > Is it driven by scenarios where AS and resource are separate > domains? Or may this be only of interest to specific protocols > like UMA? > > From a technique principle, the draft is important and sound. > I am just not there yet on the reasons for an interoperable > standard. > > Phil > > > On Jul 28, 2014, at 17:00, Thomas Broyer > wrote: > > Yes. This spec is of special interest to the platform > we're building for http://www.oasis-eu.org/ > > On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig > > wrote: > > Hi all, > > during the IETF #90 OAuth WG meeting, there was strong > consensus in > adopting the "OAuth Token Introspection" > (draft-richer-oauth-introspection-06.txt) specification as > an OAuth WG > work item. > > We would now like to verify the outcome of this call for > adoption on the > OAuth WG mailing list. Here is the link to the document: > http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ > > If you did not hum at the IETF 90 OAuth WG meeting, and > have an opinion > as to the suitability of adopting this document as a WG > work item, > please send mail to the OAuth WG list indicating your > opinion (Yes/No). > > The confirmation call for adoption will last until August > 10, 2014. If > you have issues/edits/comments on the document, please > send these > comments along to the list in your response to this Call > for Adoption. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Thomas Broyer > /t?.ma.b?wa.je/ > > _______________________________________________ > 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 --------------060202000400070109010609 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I disagree with this position and think it's vital to standardize a return structure and a common set of return values -- and that this work would be rather pointless without it. Mike, I think you might be thinking in terms of introspection simply unpacking what's already contained inside the token, and the AS doing the effort of unpacking that for the RS. This is, after all, what used to be the case for the now-defunct OpenID Connect "CheckID Endpoint". But what's really happening here is this general pattern:

 - The client passes the token to the RS. The client doesn't know or care what's in the token or what it's used for, it just knows that it can use the token at the RS.
 - The RS gets the token and passes it along to the introspection endpoint on the AS. The means by which the RS figures out where its AS is is out of scope for this bit of work.
 - The AS is looking at the token as passed in, (whether it's structured like a JWT, a random UUID, an integer into a DB, whatever deployment-specific bit you want) and figures out if the token is any good and what it's for. The AS can do this in whatever deployment-specific way it wants to: look up the token in a DB, unpack the JWT and check the signature, decrypt the token's payload, whatever.
 - The AS returns (in a standardized JSON object) a set of claims about the token. While it's possible that these claims can be included in the token directly (as a JWT, for instance) and the RS could have read them if it knew how to parse said token, it's important that they don't have to be communicated that way and the token itself does not have to be structured at all. The AS can literally issue a token of "foo.bar.123" and the RS can do an introspection call to turn "foo.bar.123" into {valid: true, sub: user-person, aud: resource-server, ... }
 - The RS looks at the returned JSON value and uses that to make its authorization decision.

It's imperative to note that the token in OAuth is opaque to the *client* -- it is not opaque to other parties, namely the AS. And in most deployments, it's not opaque to the RS either, since the RS has to be able to turn the OAuth token into something that can help it make authorization decisions. Having an introspection endpoint with a standardized return value would actually allow the token content itself to be opaque to the RS as well as the Client.

All that said, I think there is enough variability and flexibility in OAuth deployments that the introspection data response should (and so far, has) follow the JWT model: define a core set of claims with clear semantics, make them all optional apart from the common "active" field, and allow for copious extension. It's a very simple, very useful pattern that's been implemented by many different developers.

 -- Justin

On 07/29/2014 01:15 PM, Mike Jones wrote:

As I see it, there are two different kinds of standardization for introspection that could occur.  One is defining a standard endpoint for doing introspection on an access token and possibly refresh token.  The other is defining standard contents to be returned from the introspection.

 

I’m skeptical of the standard contents, given that access tokens and refresh tokens are intentionally opaque.  Implementations could range from being an integer index into a database table, to being a UUID to being an encrypted JWT with context-specific claims.  I don’t see anything in common in those implementations for introspection to return.

 

While I can see marginal utility to having a common endpoint and request syntax, I would be against trying to standardize the contents of what an introspection request might return.  It’s as deployment-specific as the access token representation itself.

 

                                                            -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Paul Madsen
Sent: Tuesday, July 29, 2014 2:48 AM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

 

Standardized Introspection will be valuable in NAPPS, where the AS and RS may be in different policy domains.

 

Even for single policy domains, there are enterprise scenarios where the RS is from a different vendor than the AS, such as when an API gateway validates tokens issued by an 'IdP' . We've necessarily defined our own introspection endpoint and our gateway partners have implemented it, (at the instruction of the customer in question). But of course it's proprietary to us.

 

Paul


On Jul 28, 2014, at 8:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

That doesn’t explain the need for inter-operability. What you’ve described is what will be common practice.

 

It’s a great open source technique, but that’s not a standard.

 

JWT is much different. JWT is a foundational specification that describes the construction and parsing of JSON based tokens. There is inter-op with token formats that build on top and there is inter-op between every communicating party.

 

In OAuth, a site may never implement token introspection nor may it do it the way you describe.  Why would that be a problem?  Why should the group spend time on something where there may be no inter-op need.

 

Now that said, if you are in the UMA community.  Inter-op is quite foundational.  It is very very important. But then maybe the spec should be defined within UMA?

 

 

 

 

On Jul 28, 2014, at 5:39 PM, Justin Richer <jricher@MIT.EDU> wrote:



It's analogous to JWT in many ways: when you've got the AS and the RS separated somehow (different box, different domain, even different software vendor) and you need to communicate a set of information about the approval delegation from the AS (who has the context to know about it) through to the RS (who needs to know about it to make the authorization call). JWT gives us an interoperable way to do this by passing values inside the token itself, introspection gives a way to pass the values by reference via the token as an artifact. The two are complementary, and there are even cases where you'd want to deploy them together.

 -- Justin

On 7/28/2014 8:11 PM, Phil Hunt wrote:

Could we have some discussion on the interop cases?

 

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

 

From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

 

Phil


On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/

 

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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



 

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

_______________________________________________
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

--------------060202000400070109010609-- From nobody Tue Jul 29 11:11:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F361B2A0D for ; Tue, 29 Jul 2014 11:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.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 1elZV68e_g3Q for ; Tue, 29 Jul 2014 11:11:34 -0700 (PDT) Received: from nm32-vm1.bullet.mail.bf1.yahoo.com (nm32-vm1.bullet.mail.bf1.yahoo.com [72.30.239.137]) (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 7E09F1A04BA for ; Tue, 29 Jul 2014 11:11:29 -0700 (PDT) Received: from [66.196.81.172] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 29 Jul 2014 18:11:28 -0000 Received: from [98.139.212.201] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 29 Jul 2014 18:11:28 -0000 Received: from [127.0.0.1] by omp1010.mail.bf1.yahoo.com with NNFMP; 29 Jul 2014 18:11:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 636008.25051.bm@omp1010.mail.bf1.yahoo.com Received: (qmail 28599 invoked by uid 60001); 29 Jul 2014 18:11:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1406657488; bh=Q4MZH4wVJUyY5oB1CmAh8b4TYnMcMB4HlD98TdSgmeA=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dW1QwfRUEzMVM3ZxPqbKODYr/M3mk2Kx8vFWZGWx9jcsSIQ+in6NDoq4U6ydXr5Iab53yRDNxuPnPL6qyOIASIvlQb0RG38TyAXU+anEKLcFDiWMYj54Z4c5DCADNb0K6Oh781QS1QzUX/NphaQZoJ35qWWbZheXWPMQTyO7A7U= X-YMail-OSG: wGxpmaYVM1n3NpmG1wb7u8P40KHm71jAjoLPp6mAt67k_4F Sej8IAbuGvqPtuIvPBBrNFK69ktzTQL8eOc3TnC52uy8Dqbc8VP.G.6iVmnw 2TPD2Kyh7ZGCRcTMCmcfwG08fj6s4NASqc3s0qRzY2r3k8_4Air4W_SQ4jUA Wy67d7r2iqgnUbwd500F_Bu.W33fJVM_8FrFYD6yvjwJdAnZhsyLEmykej9A FAtTGG9xRMxE6A.Iyzbogiph6vkm6IAcf7lek_pGTlA3l3Ni5qq3v0wvT1lT Ywx7Jw2RQwIvkv24LSWB.CIcY9Y0vUL0gd7cldMuLRLBhWvsLFuK8VN5GKO7 sSjQr21zNmx9Clin38e6ZU48SF3nBA2_0Yfette7z3uc38XQUduF4yFPbCyd FKl.1BF7OOFQ3skjlwSb1L1dALaPGBF04UO1_Pf3qheFXkwLD13Cm_mU71vv v3JCmA2hnbVGKFt1njidDzi_eBhcBh2GSbdN5Kyxq.Alek2UZBk5NHkLLCHV 2XuE2V4HKCOqVK2D5iTy2RE.FMSYV3oW8Tovt5yKuWu0vxGnaw4sPLF2vS3J pYn2zpjtRjy5N6NBF8I4igSA.GPsme5gRHaOQ11qfRgL7SheqwP5TNCPPEia .QM3lzDJZiU6RPKSoqtU2salkI2Ae4jBBBTGK6j_7ToQmqR_F3VdErS.9qAH CcleMzQwsVsbhyHTPm7oQwWOYGSkW08dYrDIfnRuJBAXHp6Fo30_rXUyXuRs yx6QiP0cjiaTxsV.sKhmRhmQTEaZBr2bZwGZsbcTKuZKFG7S8G4h2.jUkZxg tUr35JL4bq5Jbjxvuo2O2fn6Iao8zJnR.bC44x4i9G8mvPFhsl8lC8Y_jO0k v0Y0qSG4dzDJI9hcGC_JTgEY2lUd1SlVaFP1rlWgoOpLvCo1FrxEI.duT9g8 yQJgDvHW3dtia_GQPBjYZYZ5duOJ.cQ-- Received: from [167.220.24.190] by web142801.mail.bf1.yahoo.com via HTTP; Tue, 29 Jul 2014 11:11:28 PDT X-Rocket-MIMEInfo: 002.001, VGhpcyBpcyBleGFjdGx5IHRoZSBzYW1lIHByb2JsZW0gc3BhY2UgYXMgd2ViZmluZ2VyLCB5b3Ugd2FudCB0byBrbm93IHNvbWV0aGluZyBhYm91dCBhIHVzZXIgYW5kIHRoZXJlJ3MgYSB1c2VmdWwgc2V0IG9mIGluZm9ybWF0aW9uIHlvdSBtaWdodCByZWFzb25hYmx5IHF1ZXJ5LCBidXQgaW4gdGhlIGVuZCB0aGUgc2VydmVyIG1heSBoYXZlIGl0J3Mgb3duIHNjaGVtYSBvZiBkYXRhIGl0IHJldHVybnMuIMKgVGhlcmUgd29uJ3QgYmUgYSBzaW5nbGUgc2NoZW1hIHRoYXQgZml0cyBhbGwgdXNlIGNhc2VzLCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.196.685 References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D6ED5A.10500@mit.edu> <33F1EE39-2BDF-4F3D-B4DD-4AB9848BC4BF@oracle.com> Message-ID: <1406657488.80350.YahooMailNeo@web142801.mail.bf1.yahoo.com> Date: Tue, 29 Jul 2014 11:11:28 -0700 From: Bill Mills To: Paul Madsen , Phil Hunt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="469468616-14357203-1406657488=:80350" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/KnQVu43z2NAoEcyjtJS3w8QXGiA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 18:11:43 -0000 --469468616-14357203-1406657488=:80350 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is exactly the same problem space as webfinger, you want to know somet= hing about a user and there's a useful set of information you might reasona= bly query, but in the end the server may have it's own schema of data it re= turns. =C2=A0There won't be a single schema that fits all use cases, Any gi= ven RS/AS ecosystem may decide they have custom stuff and omit other stuff.= =C2=A0I think the more rigid the MTI schema gets the harder the battle in = this case.=0A=0A=0AOn Tuesday, July 29, 2014 2:56 AM, Paul Madsen wrote:=0A =0A=0A=0AStandardized Introspection will be valuab= le in NAPPS, where the AS and RS may be in different policy domains.=0A=0AE= ven for single policy domains, there are enterprise scenarios where the RS = is from a different vendor than the AS, such as when an API gateway validat= es tokens issued by an 'IdP' . We've necessarily defined our own introspect= ion endpoint and our gateway partners have implemented it, (at the instruct= ion of the customer in question). But of course it's proprietary to us.=0A= =0APaul=0A=0AOn Jul 28, 2014, at 8:59 PM, Phil Hunt = wrote:=0A=0A=0AThat doesn=E2=80=99t explain the need for inter-operability.= What you=E2=80=99ve described is what will be common practice.=0A>=0A>=0A>= It=E2=80=99s a great open source technique, but that=E2=80=99s not a standa= rd.=0A>=0A>=0A>JWT is much different. JWT is a foundational specification t= hat describes the construction and parsing of JSON based tokens. There is i= nter-op with token formats that build on top and there is inter-op between = every communicating party.=0A>=0A>=0A>In OAuth, a site may never implement = token introspection nor may it do it the way you describe. =C2=A0Why would = that be a problem? =C2=A0Why should the group spend time on something where= there may be no inter-op need.=0A>=0A>=0A>Now that said, if you are in the= UMA community. =C2=A0Inter-op is quite foundational. =C2=A0It is very very= important. But then maybe the spec should be defined within UMA?=0A>=0A>= =0A>Phil=0A>=0A>=0A>@independentid=0A>www.independentid.comphil.hunt@oracle= .com=0A>=0A>=0A>=0A>=0A>On Jul 28, 2014, at 5:39 PM, Justin Richer wrote:=0A>=0A>It's analogous to JWT in many ways: when you've got= the AS and the RS separated somehow (different box, different domain, even= different software vendor) and you need to communicate a set of informatio= n about the approval delegation from the AS (who has the context to know ab= out it) through to the RS (who needs to know about it to make the authoriza= tion call). JWT gives us an interoperable way to do this by passing values = inside the token itself, introspection gives a way to pass the values by re= ference via the token as an artifact. The two are complementary, and there = are even cases where you'd want to deploy them together.=0A>>=0A>>=C2=A0-- = Justin=0A>>=0A>>On 7/28/2014 8:11 PM, Phil Hunt wrote:=0A>>=0A>>Could we ha= ve some discussion on the interop cases?=0A>>>=0A>>>=0A>>>Is it driven by s= cenarios where AS and resource are separate domains? Or may this be only of= interest to specific protocols like UMA?=0A>>>=0A>>>=0A>>>From a technique= principle, the draft is important and sound. I am just not there yet on th= e reasons for an interoperable standard.=C2=A0=0A>>>=0A>>>=0A>>>Phil=0A>>>= =0A>>>On Jul 28, 2014, at 17:00, Thomas Broyer wrote:= =0A>>>=0A>>>=0A>>>Yes. This spec is of special interest to the platform we'= re building for=C2=A0http://www.oasis-eu.org/=0A>>>>=0A>>>>=0A>>>>=0A>>>>On= Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig wrote:=0A>>>>=0A>>>>Hi all,=0A>>>>>=0A>>>>>during the IETF #90 OAuth WG m= eeting, there was strong=0A consensus in=0A>>>>>adopting the= "OAuth Token Introspection"=0A>>>>>(draft-richer-oauth-introspection-06.tx= t) specification=0A as an OAuth WG=0A>>>>>work item.=0A>>>>>= =0A>>>>>We would now like to verify the outcome of this call for=0A = adoption on the=0A>>>>>OAuth WG mailing list. Here is the link to t= he document:=0A>>>>>http://datatracker.ietf.org/doc/draft-richer-oauth-intr= ospection/=0A>>>>>=0A>>>>>If you did not hum at the IETF 90 OAuth WG meetin= g, and=0A have an opinion=0A>>>>>as to the suitability of ad= opting this document as a WG=0A work item,=0A>>>>>please sen= d mail to the OAuth WG list indicating your=0A opinion (Yes/= No).=0A>>>>>=0A>>>>>The confirmation call for adoption will last until=0A = August 10, 2014. =C2=A0If=0A>>>>>you have issues/edits/commen= ts on the document, please=0A send these=0A>>>>>comments alo= ng to the list in your response to this Call=0A for Adoption= .=0A>>>>>=0A>>>>>Ciao=0A>>>>>Hannes & Derek=0A>>>>>=0A>>>>>=0A>>>>>________= _______________________________________=0A>>>>>OAuth mailing list=0A>>>>>OA= uth@ietf.org=0A>>>>>https://www.ietf.org/mailman/listinfo/oauth=0A>>>>>=0A>= >>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A-- =0A>>>>Thomas Broyer=0A>>>>/t=C9=94.m= a.b=CA=81wa.je/ =0A>>>_______________________________________________=0A>>>= >OAuth mailing list=0A>>>>OAuth@ietf.org=0A>>>>https://www.ietf.org/mailman= /listinfo/oauth=0A>>>>=0A>>>=0A>>>=0A>>>___________________________________= ____________=0AOAuth mailing list OAuth@ietf.org https://www.ietf.org/mailm= an/listinfo/oauth =0A>>=0A_______________________________________________= =0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>https://www.ietf.org/mailman= /listinfo/oauth=0A>>=0A>=0A_______________________________________________= =0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/li= stinfo/oauth=0A>=0A_______________________________________________=0AOAuth = mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --469468616-14357203-1406657488=:80350 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This is exactly the same problem space as webfinger, you= want to know something about a user and there's a useful set of informatio= n you might reasonably query, but in the end the server may have it's own s= chema of data it returns.  There won't be a single schema that fits al= l use cases, Any given RS/AS ecosystem may decide they have custom stuff an= d omit other stuff.  I think the more rigid the MTI schema gets the ha= rder the battle in this case.


On Tuesday, Jul= y 29, 2014 2:56 AM, Paul Madsen <paul.madsen@gmail.com> wrote:


Standardized Introspection will be valuable in NAPPS, where = the AS and RS may be in different policy domains.

= Even for single policy domains, there are enterprise scenarios where the RS= is from a different vendor than the AS, such as when an API gateway valida= tes tokens issued by an 'IdP' . We've necessarily defined our own introspec= tion endpoint and our gateway partners have implemented it, (at the instruc= tion of the customer in question). But of course it's proprietary to us.

Paul

On Jul 28, 2014, at 8:59 PM, Phil= Hunt <phil.hunt@oracle.com&= gt; wrote:

That doesn=E2=80=99t e= xplain the need for inter-operability. What you=E2=80=99ve described is wha= t will be common practice.

It=E2=80=99s a great open sou= rce technique, but that=E2=80=99s not a standard.

= JWT is much different. JWT is a foundational specification that describes t= he construction and parsing of JSON based tokens. There is inter-op with to= ken formats that build on top and there is inter-op between every communica= ting party.

In OAuth, a site may never implement t= oken introspection nor may it do it the way you describe.  Why would t= hat be a problem?  Why should the group spend time on something where = there may be no inter-op need.

Now that said, if y= ou are in the UMA community.  Inter-op is quite foundational.  It= is very very important. But then maybe the spec should be defined within UMA?

=0A
On Jul 28, 2014, at 5:39 PM, Justin Richer <jricher@MIT.EDU> wrote:

=0A = =0A =0A =0A
=0A
It= 's analogous to JWT in many ways:=0A when you've got the AS and the RS= separated somehow (different=0A box, different domain, even different= software vendor) and you=0A need to communicate a set of information = about the approval=0A delegation from the AS (who has the context to k= now about it)=0A through to the RS (who needs to know about it to make= the=0A authorization call). JWT gives us an interoperable way to do t= his=0A by passing values inside the token itself, introspection gives = a=0A way to pass the values by reference via the token as an artifact.= =0A The two are complementary, and there are even cases where you'd=0A= want to deploy them together.
=0A
=0A  -- Justi= n
=0A
=0A On 7/28/2014 8:11 PM, Phil Hunt wrote:
=0A =
=0A
=0A =0A
Could we hav= e some discussion on the interop cases?
=0A

=0A =0A
Is it driven by scenarios where AS and resource are separa= te=0A domains? Or may this be only of interest to specific protocols= =0A like UMA?
=0A

=0A
=0A
Fr= om a technique principle, the draft is important and sound.=0A I am = just not there yet on the reasons for an interoperable=0A standard.&= nbsp;
=0A

=0A
=0A
Phil
=0A =

=0A On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com>=0A wrote:<= br>=0A
=0A
=0A
=0A =
=0A
Yes. This spec is of special interes= t to the=0A platform we're building for http://www.oasis-eu.or= g/
=0A

=0A =
=0A
On Mon,= Jul 28, 2014 at 7:33 PM,=0A Hannes Tschofenig <hannes.tschofenig@= gmx.net>=0A wrote:
=0A Hi=0A all,
=0A =
=0A during the IETF #90 OAuth WG meeting, there= was strong=0A consensus in
=0A adopting t= he "OAuth Token Introspection"
=0A (draft-richer-oauth-in= trospection-06.txt) specification=0A as an OAuth WG
=0A = work item.
=0A
=0A We wo= uld now like to verify the outcome of this call for=0A adopt= ion on the
=0A OAuth WG mailing list. Here is the link to= the document:
=0A = http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/
= =0A
=0A If you did not hum at the IETF 90= OAuth WG meeting, and=0A have an opinion
=0A = as to the suitability of adopting this document as a WG=0A = work item,
=0A please send mail to the OAuth WG list i= ndicating your=0A opinion (Yes/No).
=0A =0A The confirmation call for adoption will last until=0A = August 10, 2014.  If
=0A you have iss= ues/edits/comments on the document, please=0A send these
= =0A comments along to the list in your response to this Call= =0A for Adoption.
=0A
=0A = Ciao
=0A Hannes & Derek
=0A
= =0A
=0A _________________________________= ______________
=0A OAuth mailing list
=0A = OAuth@ietf.org
=0A https://www.ietf.org/mailman/listinfo/oauth
=0A =
=0A
=0A
=0A =
=0A
=0A

=0A =
=0A --
=0A Thomas Broyer
=0A = /t=C9=94.ma.b=CA=81wa.je/=0A
=0A
= =0A
=0A
=0A
_______________________________________________
=0A = OAuth mailing list
=0A OAuth@ietf.org
=0A http= s://www.ietf.org/mailman/listinfo/oauth
=0A
=0A =
=0A
=0A
=0A
=0A 
__________________=
_____________________________=0AOAuth mailing list=0AOAuth@ietf.org=0A=
https://www.ie=
tf.org/mailman/listinfo/oauth=0A
=0A =0A
= =0A
=0A=0A_______________________________________________
OAuth m= ailing 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/m= ailman/listinfo/oauth


--469468616-14357203-1406657488=:80350-- From nobody Tue Jul 29 11:14:06 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030781A026E for ; Tue, 29 Jul 2014 11:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 MUdYriupfQit for ; Tue, 29 Jul 2014 11:13:58 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBFB1B2A0A for ; Tue, 29 Jul 2014 11:13:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 49B2C1F203A; Tue, 29 Jul 2014 14:13:57 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 34BEB1F0536; Tue, 29 Jul 2014 14:13:57 -0400 (EDT) Received: from [10.146.15.61] (10.140.19.249) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 29 Jul 2014 14:13:56 -0400 Message-ID: <53D7E430.2070400@mitre.org> Date: Tue, 29 Jul 2014 14:13:04 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bill Mills , Paul Madsen , Phil Hunt References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D6ED5A.10500@mit.edu> <33F1EE39-2BDF-4F3D-B4DD-4AB9848BC4BF@oracle.com> <1406657488.80350.YahooMailNeo@web142801.mail.bf1.yahoo.com> In-Reply-To: <1406657488.80350.YahooMailNeo@web142801.mail.bf1.yahoo.com> Content-Type: multipart/alternative; boundary="------------030307020004060400020409" X-Originating-IP: [10.140.19.249] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/a4bxcDdCBA_1Xj-I4Sqw5ZbX_gQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 18:14:03 -0000 --------------030307020004060400020409 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Agreed on this point -- which is why the only MTI bit in the individual draft is "active", which is whether or not the token was any good to begin with. There are a set of claims with defined semantics but all are optional, and the list is extensible. I think in practice we'll see people settle on a set of common ones. -- Justin On 07/29/2014 02:11 PM, Bill Mills wrote: > This is exactly the same problem space as webfinger, you want to know > something about a user and there's a useful set of information you > might reasonably query, but in the end the server may have it's own > schema of data it returns. There won't be a single schema that fits > all use cases, Any given RS/AS ecosystem may decide they have custom > stuff and omit other stuff. I think the more rigid the MTI schema > gets the harder the battle in this case. > > > On Tuesday, July 29, 2014 2:56 AM, Paul Madsen > wrote: > > > Standardized Introspection will be valuable in NAPPS, where the AS and > RS may be in different policy domains. > > Even for single policy domains, there are enterprise scenarios where > the RS is from a different vendor than the AS, such as when an API > gateway validates tokens issued by an 'IdP' . We've necessarily > defined our own introspection endpoint and our gateway partners have > implemented it, (at the instruction of the customer in question). But > of course it's proprietary to us. > > Paul > > On Jul 28, 2014, at 8:59 PM, Phil Hunt > wrote: > >> That doesn't explain the need for inter-operability. What you've >> described is what will be common practice. >> >> It's a great open source technique, but that's not a standard. >> >> JWT is much different. JWT is a foundational specification that >> describes the construction and parsing of JSON based tokens. There is >> inter-op with token formats that build on top and there is inter-op >> between every communicating party. >> >> In OAuth, a site may never implement token introspection nor may it >> do it the way you describe. Why would that be a problem? Why should >> the group spend time on something where there may be no inter-op need. >> >> Now that said, if you are in the UMA community. Inter-op is quite >> foundational. It is very very important. But then maybe the spec >> should be defined within UMA? >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> On Jul 28, 2014, at 5:39 PM, Justin Richer > > wrote: >> >>> It's analogous to JWT in many ways: when you've got the AS and the >>> RS separated somehow (different box, different domain, even >>> different software vendor) and you need to communicate a set of >>> information about the approval delegation from the AS (who has the >>> context to know about it) through to the RS (who needs to know about >>> it to make the authorization call). JWT gives us an interoperable >>> way to do this by passing values inside the token itself, >>> introspection gives a way to pass the values by reference via the >>> token as an artifact. The two are complementary, and there are even >>> cases where you'd want to deploy them together. >>> >>> -- Justin >>> >>> On 7/28/2014 8:11 PM, Phil Hunt wrote: >>>> Could we have some discussion on the interop cases? >>>> >>>> Is it driven by scenarios where AS and resource are separate >>>> domains? Or may this be only of interest to specific protocols like >>>> UMA? >>>> >>>> From a technique principle, the draft is important and sound. I am >>>> just not there yet on the reasons for an interoperable standard. >>>> >>>> Phil >>>> >>>> On Jul 28, 2014, at 17:00, Thomas Broyer >>> > wrote: >>>> >>>>> Yes. This spec is of special interest to the platform we're >>>>> building for http://www.oasis-eu.org/ >>>>> >>>>> >>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>>> > wrote: >>>>> >>>>> Hi all, >>>>> >>>>> during the IETF #90 OAuth WG meeting, there was strong >>>>> consensus in >>>>> adopting the "OAuth Token Introspection" >>>>> (draft-richer-oauth-introspection-06.txt) specification as an >>>>> OAuth WG >>>>> work item. >>>>> >>>>> We would now like to verify the outcome of this call for >>>>> adoption on the >>>>> OAuth WG mailing list. Here is the link to the document: >>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>>> >>>>> If you did not hum at the IETF 90 OAuth WG meeting, and have >>>>> an opinion >>>>> as to the suitability of adopting this document as a WG work item, >>>>> please send mail to the OAuth WG list indicating your opinion >>>>> (Yes/No). >>>>> >>>>> The confirmation call for adoption will last until August 10, >>>>> 2014. If >>>>> you have issues/edits/comments on the document, please send these >>>>> comments along to the list in your response to this Call for >>>>> Adoption. >>>>> >>>>> Ciao >>>>> Hannes & Derek >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Broyer >>>>> /t?.ma.b?wa.je/ >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030307020004060400020409 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Agreed on this point -- which is why the only MTI bit in the individual draft is "active", which is whether or not the token was any good to begin with. There are a set of claims with defined semantics but all are optional, and the list is extensible. I think in practice we'll see people settle on a set of common ones.

 -- Justin

On 07/29/2014 02:11 PM, Bill Mills wrote:
This is exactly the same problem space as webfinger, you want to know something about a user and there's a useful set of information you might reasonably query, but in the end the server may have it's own schema of data it returns.  There won't be a single schema that fits all use cases, Any given RS/AS ecosystem may decide they have custom stuff and omit other stuff.  I think the more rigid the MTI schema gets the harder the battle in this case.


On Tuesday, July 29, 2014 2:56 AM, Paul Madsen <paul.madsen@gmail.com> wrote:


Standardized Introspection will be valuable in NAPPS, where the AS and RS may be in different policy domains.

Even for single policy domains, there are enterprise scenarios where the RS is from a different vendor than the AS, such as when an API gateway validates tokens issued by an 'IdP' . We've necessarily defined our own introspection endpoint and our gateway partners have implemented it, (at the instruction of the customer in question). But of course it's proprietary to us.

Paul

On Jul 28, 2014, at 8:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

That doesn’t explain the need for inter-operability. What you’ve described is what will be common practice.

It’s a great open source technique, but that’s not a standard.

JWT is much different. JWT is a foundational specification that describes the construction and parsing of JSON based tokens. There is inter-op with token formats that build on top and there is inter-op between every communicating party.

In OAuth, a site may never implement token introspection nor may it do it the way you describe.  Why would that be a problem?  Why should the group spend time on something where there may be no inter-op need.

Now that said, if you are in the UMA community.  Inter-op is quite foundational.  It is very very important. But then maybe the spec should be defined within UMA?


On Jul 28, 2014, at 5:39 PM, Justin Richer <jricher@MIT.EDU> wrote:

It's analogous to JWT in many ways: when you've got the AS and the RS separated somehow (different box, different domain, even different software vendor) and you need to communicate a set of information about the approval delegation from the AS (who has the context to know about it) through to the RS (who needs to know about it to make the authorization call). JWT gives us an interoperable way to do this by passing values inside the token itself, introspection gives a way to pass the values by reference via the token as an artifact. The two are complementary, and there are even cases where you'd want to deploy them together.

 -- Justin

On 7/28/2014 8:11 PM, Phil Hunt wrote:
Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/


On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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




--
Thomas Broyer
/tɔ.ma.bʁwa.je/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


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

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

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

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




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

--------------030307020004060400020409-- From nobody Tue Jul 29 12:08:25 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3FB1B2A04 for ; Tue, 29 Jul 2014 12:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, URI_NOVOWEL=0.5] 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 UMmKIs2Fwjib for ; Tue, 29 Jul 2014 12:08:17 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5C96E1A0ABD for ; Tue, 29 Jul 2014 12:08:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 0E42F4FE59CD; Tue, 29 Jul 2014 12:08:17 -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 dHY607bxeJO2; Tue, 29 Jul 2014 12:08:15 -0700 (PDT) Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 6345B4FE59AF; Tue, 29 Jul 2014 12:08:15 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_BEF8A735-C417-47DD-B895-F8E37F6EE666" From: Eve Maler In-Reply-To: <53D7E430.2070400@mitre.org> Date: Tue, 29 Jul 2014 12:08:47 -0700 Message-Id: <33726B38-BE97-400D-A55B-BE3888429737@xmlgrrl.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D6ED5A.10500@mit.edu> <33F1EE39-2BDF-4F3D-B4DD-4AB9848BC4BF@oracle.com> <1406657488.80350.YahooMailNeo@web142801.mail.bf1.yahoo.com> <53D7E430.2070400@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/pjij16Xl2Bgu6qgyCz_ZfdHvm5w Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 19:08:21 -0000 --Apple-Mail=_BEF8A735-C417-47DD-B895-F8E37F6EE666 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agreed on this point too, and also wanted to point out that the UMA = usage of token introspection calls out to Justin's latest draft and = formally profiles it, which we found easy to do. UMA has a = mandatory-to-implement token format but also an extensible framework for = defining whatever format suits. The method of run-time introspection at = the AS, on the other hand, is locked down to increase interop. Eve On 29 Jul 2014, at 11:13 AM, Justin Richer wrote: > Agreed on this point -- which is why the only MTI bit in the = individual draft is "active", which is whether or not the token was any = good to begin with. There are a set of claims with defined semantics but = all are optional, and the list is extensible. I think in practice we'll = see people settle on a set of common ones. >=20 > -- Justin >=20 > On 07/29/2014 02:11 PM, Bill Mills wrote: >> This is exactly the same problem space as webfinger, you want to know = something about a user and there's a useful set of information you might = reasonably query, but in the end the server may have it's own schema of = data it returns. There won't be a single schema that fits all use = cases, Any given RS/AS ecosystem may decide they have custom stuff and = omit other stuff. I think the more rigid the MTI schema gets the harder = the battle in this case. >>=20 >>=20 >> On Tuesday, July 29, 2014 2:56 AM, Paul Madsen = wrote: >>=20 >>=20 >> Standardized Introspection will be valuable in NAPPS, where the AS = and RS may be in different policy domains. >>=20 >> Even for single policy domains, there are enterprise scenarios where = the RS is from a different vendor than the AS, such as when an API = gateway validates tokens issued by an 'IdP' . We've necessarily defined = our own introspection endpoint and our gateway partners have implemented = it, (at the instruction of the customer in question). But of course it's = proprietary to us. >>=20 >> Paul >>=20 >> On Jul 28, 2014, at 8:59 PM, Phil Hunt wrote: >>=20 >>> That doesn=E2=80=99t explain the need for inter-operability. What = you=E2=80=99ve described is what will be common practice. >>>=20 >>> It=E2=80=99s a great open source technique, but that=E2=80=99s not a = standard. >>>=20 >>> JWT is much different. JWT is a foundational specification that = describes the construction and parsing of JSON based tokens. There is = inter-op with token formats that build on top and there is inter-op = between every communicating party. >>>=20 >>> In OAuth, a site may never implement token introspection nor may it = do it the way you describe. Why would that be a problem? Why should = the group spend time on something where there may be no inter-op need. >>>=20 >>> Now that said, if you are in the UMA community. Inter-op is quite = foundational. It is very very important. But then maybe the spec should = be defined within UMA? >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>> On Jul 28, 2014, at 5:39 PM, Justin Richer wrote: >>>=20 >>>> It's analogous to JWT in many ways: when you've got the AS and the = RS separated somehow (different box, different domain, even different = software vendor) and you need to communicate a set of information about = the approval delegation from the AS (who has the context to know about = it) through to the RS (who needs to know about it to make the = authorization call). JWT gives us an interoperable way to do this by = passing values inside the token itself, introspection gives a way to = pass the values by reference via the token as an artifact. The two are = complementary, and there are even cases where you'd want to deploy them = together. >>>>=20 >>>> -- Justin >>>>=20 >>>> On 7/28/2014 8:11 PM, Phil Hunt wrote: >>>>> Could we have some discussion on the interop cases? >>>>>=20 >>>>> Is it driven by scenarios where AS and resource are separate = domains? Or may this be only of interest to specific protocols like UMA? >>>>>=20 >>>>> =46rom a technique principle, the draft is important and sound. I = am just not there yet on the reasons for an interoperable standard.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On Jul 28, 2014, at 17:00, Thomas Broyer = wrote: >>>>>=20 >>>>>> Yes. This spec is of special interest to the platform we're = building for http://www.oasis-eu.org/ >>>>>>=20 >>>>>>=20 >>>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig = wrote: >>>>>> Hi all, >>>>>>=20 >>>>>> during the IETF #90 OAuth WG meeting, there was strong consensus = in >>>>>> adopting the "OAuth Token Introspection" >>>>>> (draft-richer-oauth-introspection-06.txt) specification as an = OAuth WG >>>>>> work item. >>>>>>=20 >>>>>> We would now like to verify the outcome of this call for adoption = on the >>>>>> OAuth WG mailing list. Here is the link to the document: >>>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>>>>=20 >>>>>> If you did not hum at the IETF 90 OAuth WG meeting, and have an = opinion >>>>>> as to the suitability of adopting this document as a WG work = item, >>>>>> please send mail to the OAuth WG list indicating your opinion = (Yes/No). >>>>>>=20 >>>>>> The confirmation call for adoption will last until August 10, = 2014. If >>>>>> you have issues/edits/comments on the document, please send these >>>>>> comments along to the list in your response to this Call for = Adoption. >>>>>>=20 >>>>>> Ciao >>>>>> Hannes & Derek >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> Thomas Broyer >>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=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 >>=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 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail=_BEF8A735-C417-47DD-B895-F8E37F6EE666 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Agreed on this point too, and also wanted to = point out that the UMA usage of token introspection calls out to = Justin's latest draft and formally profiles it, which we found easy to = do. UMA has a mandatory-to-implement token format but also an extensible = framework for defining whatever format suits. The method of run-time = introspection at the AS, on the other hand, is locked down to increase = interop.

Eve

On 29 Jul = 2014, at 11:13 AM, Justin Richer <jricher@mitre.org> = wrote:

=20 =20
Agreed on this point -- which is why the only MTI bit in the individual draft is "active", which is whether or not the token was any good to begin with. There are a set of claims with defined semantics but all are optional, and the list is extensible. I think in practice we'll see people settle on a set of common ones.

 -- Justin

On 07/29/2014 02:11 PM, Bill Mills wrote:
This is exactly the same problem space as webfinger, you want to know something about a user and there's a useful set of information you might reasonably query, but in the end the server may have it's own schema of data it returns. =  There won't be a single schema that fits all use cases, Any given RS/AS ecosystem may decide they have custom stuff and omit other stuff.  I think the more rigid the MTI schema gets = the harder the battle in this case.


On = Tuesday, July 29, 2014 2:56 AM, Paul Madsen <paul.madsen@gmail.com> = wrote:


Standardized Introspection will be valuable in NAPPS, where the AS and RS may be in different policy domains.

Even for single policy domains, there are enterprise scenarios where the RS is from a different vendor than the AS, such as when an API gateway validates tokens issued by an 'IdP' . We've necessarily defined our own introspection endpoint and our gateway partners have implemented it, (at the instruction of the customer in question). But of course it's proprietary to = us.

Paul

On Jul 28, 2014, at 8:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

That doesn=E2=80=99t explain the need for inter-operability. What you=E2=80=99ve described = is what will be common practice.

It=E2=80=99s a great open source technique, = but that=E2=80=99s not a standard.

JWT is much different. JWT is a foundational specification that describes the construction and parsing of JSON based tokens. There is inter-op with token formats that build on top and there is inter-op between every communicating party.

In OAuth, a site may never implement token introspection nor may it do it the way you describe.  Why would that be a problem? =  Why should the group spend time on something where there may be no inter-op need.

Now that said, if you are in the UMA community.  Inter-op is quite = foundational.  It is very very important. But then = maybe the spec should be defined within UMA?


On Jul 28, 2014, at 5:39 PM, Justin Richer <jricher@MIT.EDU> wrote:

It's analogous to JWT in many ways: when you've got the AS and the RS separated somehow (different box, different domain, even different software vendor) and you need to communicate a set of information about the approval delegation from the AS (who has the context to know about it) through to the RS (who needs to know about it to make the authorization call). JWT gives us an interoperable way to do this by passing values inside the token itself, introspection gives a way to pass the values by reference via the token as an artifact. The two are complementary, and there are even cases where you'd want to deploy them together.

 -- Justin

On 7/28/2014 8:11 PM, Phil Hunt wrote:
Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

=46rom a technique principle, = the draft is important and sound. I am just not there yet on the reasons for an interoperable = standard. 

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec = is of special interest to the platform we're building = for http://www.oasis-eu.org/


On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net>= ; wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
= (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on = the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/
=
If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014. =  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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




--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
=
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


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

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

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

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




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

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


Eve Maler       =                     =        http://www.xmlgrrl.com/blog
+1= 425 345 6756                 =         http://www.twitter.com/xmlgrrl=

= --Apple-Mail=_BEF8A735-C417-47DD-B895-F8E37F6EE666-- From nobody Tue Jul 29 13:41:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E018D1B2815 for ; Tue, 29 Jul 2014 13:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 9i2fEck9lkOs for ; Tue, 29 Jul 2014 13:41:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9390E1A0B02 for ; Tue, 29 Jul 2014 13:41:51 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6TKfmmO023924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Jul 2014 20:41:49 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s6TKfkB7029149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2014 20:41:47 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6TKfkPU001296; Tue, 29 Jul 2014 20:41:46 GMT Received: from [10.98.6.31] (/24.244.23.143) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Jul 2014 13:41:44 -0700 References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D6ED5A.10500@mit.edu> <33F1EE39-2BDF-4F3D-B4DD-4AB9848BC4BF@oracle.com> <1406657488.80350.YahooMailNeo@web142801.mail.bf1.yahoo.com> <53D7E430.2070400@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <53D7E430.2070400@mitre.org> Content-Type: multipart/alternative; boundary=Apple-Mail-DD994183-48E3-4F4E-877D-1D9E4FD3BCF8 Content-Transfer-Encoding: 7bit Message-Id: <620AF4CA-B7F7-487E-A833-3483D2B41B26@oracle.com> X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Tue, 29 Jul 2014 13:41:16 -0700 To: Justin Richer X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/D2lF5-Yr61H03CaHfimc9h33op4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 20:41:55 -0000 --Apple-Mail-DD994183-48E3-4F4E-877D-1D9E4FD3BCF8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Making everything optional achieves no benefits, you just end up with a comp= lex set of options and no inter op.=20 We had the same issue with dyn reg.=20 I prefer to first get agreement on use case.=20 What are the questions a caller can ask and what form of responses are avail= able.=20 Should this be limited to authz info or is this a back door for user data an= d wbfinger data? I would prefer to have agreement on use cases before picking a solution righ= t now.=20 Phil > On Jul 29, 2014, at 11:13, Justin Richer wrote: >=20 > Agreed on this point -- which is why the only MTI bit in the individual dr= aft is "active", which is whether or not the token was any good to begin wit= h. There are a set of claims with defined semantics but all are optional, an= d the list is extensible. I think in practice we'll see people settle on a s= et of common ones. >=20 > -- Justin >=20 >> On 07/29/2014 02:11 PM, Bill Mills wrote: >> This is exactly the same problem space as webfinger, you want to know som= ething about a user and there's a useful set of information you might reason= ably query, but in the end the server may have it's own schema of data it re= turns. There won't be a single schema that fits all use cases, Any given RS= /AS ecosystem may decide they have custom stuff and omit other stuff. I thi= nk the more rigid the MTI schema gets the harder the battle in this case. >>=20 >>=20 >> On Tuesday, July 29, 2014 2:56 AM, Paul Madsen wr= ote: >>=20 >>=20 >> Standardized Introspection will be valuable in NAPPS, where the AS and RS= may be in different policy domains. >>=20 >> Even for single policy domains, there are enterprise scenarios where the R= S is from a different vendor than the AS, such as when an API gateway valida= tes tokens issued by an 'IdP' . We've necessarily defined our own introspect= ion endpoint and our gateway partners have implemented it, (at the instructi= on of the customer in question). But of course it's proprietary to us. >>=20 >> Paul >>=20 >> On Jul 28, 2014, at 8:59 PM, Phil Hunt wrote: >>=20 >>> That doesn=E2=80=99t explain the need for inter-operability. What you=E2= =80=99ve described is what will be common practice. >>>=20 >>> It=E2=80=99s a great open source technique, but that=E2=80=99s not a sta= ndard. >>>=20 >>> JWT is much different. JWT is a foundational specification that describe= s the construction and parsing of JSON based tokens. There is inter-op with t= oken formats that build on top and there is inter-op between every communica= ting party. >>>=20 >>> In OAuth, a site may never implement token introspection nor may it do i= t the way you describe. Why would that be a problem? Why should the group s= pend time on something where there may be no inter-op need. >>>=20 >>> Now that said, if you are in the UMA community. Inter-op is quite found= ational. It is very very important. But then maybe the spec should be defin= ed within UMA? >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>> On Jul 28, 2014, at 5:39 PM, Justin Richer = wrote: >>>>=20 >>>> It's analogous to JWT in many ways: when you've got the AS and the RS s= eparated somehow (different box, different domain, even different software v= endor) and you need to communicate a set of information about the approval d= elegation from the AS (who has the context to know about it) through to the R= S (who needs to know about it to make the authorization call). JWT gives us a= n interoperable way to do this by passing values inside the token itself, in= trospection gives a way to pass the values by reference via the token as an a= rtifact. The two are complementary, and there are even cases where you'd wan= t to deploy them together. >>>>=20 >>>> -- Justin >>>>=20 >>>>> On 7/28/2014 8:11 PM, Phil Hunt wrote: >>>>> Could we have some discussion on the interop cases? >>>>>=20 >>>>> Is it driven by scenarios where AS and resource are separate domains? O= r may this be only of interest to specific protocols like UMA? >>>>>=20 >>>>> =46rom a technique principle, the draft is important and sound. I am j= ust not there yet on the reasons for an interoperable standard.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On Jul 28, 2014, at 17:00, Thomas Broyer wrote: >>>>>=20 >>>>>> Yes. This spec is of special interest to the platform we're building f= or http://www.oasis-eu.org/ >>>>>>=20 >>>>>>=20 >>>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig wrote: >>>>>> Hi all, >>>>>>=20 >>>>>> during the IETF #90 OAuth WG meeting, there was strong consensus in >>>>>> adopting the "OAuth Token Introspection" >>>>>> (draft-richer-oauth-introspection-06.txt) specification as an OAuth W= G >>>>>> work item. >>>>>>=20 >>>>>> We would now like to verify the outcome of this call for adoption on t= he >>>>>> OAuth WG mailing list. Here is the link to the document: >>>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>>>>=20 >>>>>> If you did not hum at the IETF 90 OAuth WG meeting, = and have an opinion >>>>>> as to the suitability of adopting this document as a WG work item, >>>>>> please send mail to the OAuth WG list indicating your opinion (Yes/No= ). >>>>>>=20 >>>>>> The confirmation call for adoption will last until August 10, 2014. I= f >>>>>> you have issues/edits/comments on the document, please send these >>>>>> comments along to the list in your response to this Call for Adoption= . >>>>>>=20 >>>>>> Ciao >>>>>> Hannes & Derek >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> Thomas Broyer >>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> 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 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-DD994183-48E3-4F4E-877D-1D9E4FD3BCF8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Making everything optional achieves no= benefits, you just end up with a complex set of options and no inter op.&nb= sp;

We had the same issue with dyn reg. 
=

I prefer to first get agreement on use case. 
=

What are the questions a caller can ask and what form of= responses are available. 

Should this be limi= ted to authz info or is this a back door for user data and wbfinger data?

I would prefer to have agreement on use cases before p= icking a solution right now. 

Phil

On Jul 2= 9, 2014, at 11:13, Justin Richer <jr= icher@mitre.org> wrote:

=20 =20 =20 Agreed on this point -- which is why the only MTI bit in the individual draft is "active", which is whether or not the token was any good to begin with. There are a set of claims with defined semantics but all are optional, and the list is extensible. I think in practice we'll see people settle on a set of common ones.

 -- Justin

On 07/29/2014 02:11 PM, Bill Mills wrote:
This is exactly the same problem space as webfinger, you want to know something about a user and there's a useful set of information you might reasonably query, but in the end the server may have it's own schema of data it returns.  There won't be a single schema that fits all use cases, Any given RS/AS ecosystem may decide they have custom stuff and omit other stuff.  I think the more rigid the MTI schema gets the harder the battle in this case.


On Tuesday,= July 29, 2014 2:56 AM, Paul Madsen <paul.madsen@gmail.com> wrote:


Standardized Introspection will be valuable in NAPPS, where the AS and RS may be in different policy domains.

Even for single policy domains, there are enterprise scenarios where the RS is from a different vendor than the AS, such as when an API gateway validates tokens issued by an 'IdP' . We've necessarily defined our own introspection endpoint and our gateway partners have implemented it, (at the instruction of the customer in question). But of course it's proprietary to us.
=

Paul

On Jul 28, 2014, at 8:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

That doesn=E2=80=99t explain the need for inter-operability. What you=E2=80=99ve described is w= hat will be common practice.

It=E2=80=99s a great open source technique, but= that=E2=80=99s not a standard.

JWT is much different. JWT is a foundational specification that describes the construction and parsing of JSON based tokens. There is inter-op with token formats that build on top and there is inter-op between every communicating party.

In OAuth, a site may never implement token introspection nor may it do it the way you describe.  Why would that be a problem?  = ;Why should the group spend time on something where there may be no inter-op need.

Now that said, if you are in the UMA community.  Inter-op is quite foundational.  It is very very important. But then maybe th= e spec should be defined within UMA?


On Jul 28, 2014, at 5:39 PM, Justin Richer <jricher@MIT.EDU> wrote:

It's analogous to JWT in many ways: when you've got the AS and the RS separated somehow (different box, different domain, even different software vendor) and you need to communicate a set of information about the approval delegation from the AS (who has the context to know about it) through to the RS (who needs to know about it to make the authorization call). JWT gives us an interoperable way to do this by passing values inside the token itself, introspection gives a way to pass the values by reference via the token as an artifact. The two are complementary, and there are even cases where you'd want to deploy them together.

 -- Justin

On 7/28/2014 8:11 PM, Phil Hunt wrote:
Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

=46rom a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for <= a moz-do-not-send=3D"true" rel=3D"nofollow" target=3D"_blank" href=3D"http:/= /www.oasis-eu.org/">http://www.oasis-eu.org/


On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspect= ion-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer= -oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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




--
Thomas Broyer
/t=C9=94= .ma.b=CA=81wa.je/
___________________________= ____________________
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
http= s://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@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth

=20
= --Apple-Mail-DD994183-48E3-4F4E-877D-1D9E4FD3BCF8-- From nobody Tue Jul 29 14:31:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EB81A0171 for ; Tue, 29 Jul 2014 14:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcdNd9O04RoY for ; Tue, 29 Jul 2014 14:31:44 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAFFD1A010C for ; Tue, 29 Jul 2014 14:31:43 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so209622lbv.30 for ; Tue, 29 Jul 2014 14:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OC4xtV3VSlnL+Suz/yu5/y0//hnnh/GbfuT0CvEow5Y=; b=w4ceBgfBjQ02JJ0XJbi1dvdRql3l9gauxpK1LJFxK23HrZIiCEei//aoZ3cav1L8sH ZupRxI45315b//t/LF71od2/FVepVXqJZ7mexSWrGNInDlKCH1xj+91TxoZyHrL0Frxw fVqdfVE79+FRUe4j6pVmGuZ8RQZyv0e6Da7c6iXVYd2tZtEnF5K6gRsvLwNvKLhN2Rlb 2on0cb24I4yYghpp5U9/IrZ1V5FdK6oUJJTb3Xnb/gVhuKDNCuNTGWr43pqzYOMF9uO0 LQBkJrME3M/0xftAjXC+4pL/6bIspdFW1DF9a3C2C5KDIXrUdhbyHrTEWr5ybfHDxnL0 pHXA== X-Received: by 10.152.27.197 with SMTP id v5mr5285479lag.84.1406669501897; Tue, 29 Jul 2014 14:31:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.113.73 with HTTP; Tue, 29 Jul 2014 14:31:21 -0700 (PDT) In-Reply-To: <620AF4CA-B7F7-487E-A833-3483D2B41B26@oracle.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D6ED5A.10500@mit.edu> <33F1EE39-2BDF-4F3D-B4DD-4AB9848BC4BF@oracle.com> <1406657488.80350.YahooMailNeo@web142801.mail.bf1.yahoo.com> <53D7E430.2070400@mitre.org> <620AF4CA-B7F7-487E-A833-3483D2B41B26@oracle.com> From: Thomas Broyer Date: Tue, 29 Jul 2014 23:31:21 +0200 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=089e0160acaefa211404ff5bc3cb Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/rp_0LQTNpHxKJHfxushejrWwXPE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 21:31:46 -0000 --089e0160acaefa211404ff5bc3cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 29, 2014 at 10:41 PM, Phil Hunt wrote: > Making everything optional achieves no benefits, you just end up with a > complex set of options and no inter op. > > We had the same issue with dyn reg. > > I prefer to first get agreement on use case. > > What are the questions a caller can ask and what form of responses are > available. > > Should this be limited to authz info or is this a back door for user data > and wbfinger data? > > I would prefer to have agreement on use cases before picking a solution > right now. > The use-case (in our case) is driving authorization at an RS from a different vendor than the AS (we have a single AS, and everyone is free to register a RS in the AS catalog), as explained by Justin 3 hours ago. If the response is {"active":false}, the RS is supposed to reply with a 401 and invalid_token. This could happen if the token is invalid/unknown to the AS, expired, or does not grant any scope registered by the calling RS (identified by HTTP Basic auth =E2=80=93Client Authentication=E2=80=93 a= t the endpoint). Our "active":true responses include the "scope" claim filtered to only include the scopes registered by the calling RS, so it can possibly return a 403 with insufficient_scope. They also include the "sub" claim and a custom "sub_groups" claim so the RS can drive authorization depending on the user. Our "sub_groups" claim includes identifiers for groups the user is a member of (so that you could control access by groups rather than only a list of users). Finally, we also send the "client_id" claim so the RS could identify who uses its data, and possibly charge them accordingly (or refuse them access if they need prior, out-of-band, approval, or they've been blacklisted, etc.), and the "iat" and "exp" claims so they could possibly refuse access if the token is not recent enough or will expire too soon. In due course, we'll probably add "amr" and/or "acr" claims (or similar) because some processes (in France for example) require the use of client certificates, etc. --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --089e0160acaefa211404ff5bc3cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 29, 2014 at 10:41 PM, Phil Hunt <<= a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.c= om> wrote:
Making everything optional achieves= no benefits, you just end up with a complex set of options and no inter op= .=C2=A0

We had the same issue with dyn reg.=C2=A0
I prefer to first get agreement on use case.=C2=A0
What are the questions a caller can ask and what form of respo= nses are available.=C2=A0

Should this be limited to authz info or is this a back = door for user data and wbfinger data?

I would pref= er to have agreement on use cases before picking a solution right now.=C2= =A0

The use-case (in our case) is drivin= g authorization at an RS from a different vendor than the AS (we have a sin= gle AS, and everyone is free to register a RS in the AS catalog), as explai= ned by Justin 3 hours ago.

If th= e response is {"active":false}, the RS is supposed to reply with = a 401 and invalid_token. This could happen if the token is invalid/unknown = to the AS, expired, or does not grant any scope registered by the calling R= S=C2=A0(identified by HTTP Basic auth =E2=80=93Client Authentication=E2=80= =93 at the endpoint).
Our "active":true responses include th= e "scope" claim filtered to only include the scopes registered by= the calling RS, so it can possibly return a 403 with insufficient_scope. They also include the "sub" claim and a custom "sub_groups&q= uot; claim so the RS can drive authorization depending on the user. Our &qu= ot;sub_groups" claim includes identifiers for groups the user is a mem= ber of (so that you could control access by groups rather than only a list = of users).
Finally, we also send the "client_id" = claim so the RS could identify who uses its data, and possibly charge them = accordingly (or refuse them access if they need prior, out-of-band, approva= l, or they've been blacklisted, etc.), and the "iat" and &quo= t;exp" claims so they could possibly refuse access if the token is not= recent enough or will expire too soon.

In due cour= se, we'll probably add "amr" and/or "acr" claims (o= r similar) because some processes (in France for example) require the use o= f client certificates, etc.

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
--089e0160acaefa211404ff5bc3cb-- From nobody Tue Jul 29 15:24:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C391A0B08 for ; Tue, 29 Jul 2014 15:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 VY1rLpYYU0W4 for ; Tue, 29 Jul 2014 15:24:46 -0700 (PDT) Received: from omr-d01.mx.aol.com (omr-d01.mx.aol.com [205.188.252.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D71B1B2863 for ; Tue, 29 Jul 2014 15:24:45 -0700 (PDT) Received: from mtaout-mcd02.mx.aol.com (mtaout-mcd02.mx.aol.com [172.26.223.206]) by omr-d01.mx.aol.com (Outbound Mail Relay) with ESMTP id 7B13A700000A2; Tue, 29 Jul 2014 18:24:44 -0400 (EDT) Received: from [10.181.176.18] (unknown [10.181.176.18]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mcd02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 4636D38000096; Tue, 29 Jul 2014 18:24:44 -0400 (EDT) Message-ID: <53D81F2C.2060700@aol.com> Date: Tue, 29 Jul 2014 18:24:44 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Phil Hunt , Thomas Broyer References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> In-Reply-To: <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> Content-Type: multipart/alternative; boundary="------------000905090208050307080007" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1406672684; bh=uOPZC0vhw7Ecf+KBkXBFCCfRi6QDIAFW6WHwqMhMK+8=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=bUub+JdWrEz1WdCQAp2R0y+5VmYHKe7ML/PrrfEGq74UWEbFm56aae/8NfZs5AWp/ Re6HJulkT+fGZVsrxNzg+J7SIg8iXrANy14MDnictGt8aDjTpjQI/bgUMsv52u6mDu CzmKSxZhW2CNBCiEJm0+oOtaEdoVqOg/GXSpGSS0= x-aol-sid: 3039ac1adfce53d81f2c7661 X-AOL-IP: 10.181.176.18 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JQXxeX5bcT4Scgz3-CmmFnBZ6iU Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 22:24:48 -0000 This is a multi-part message in MIME format. --------------000905090208050307080007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS. Thanks, George On 7/28/14, 8:11 PM, Phil Hunt wrote: > Could we have some discussion on the interop cases? > > Is it driven by scenarios where AS and resource are separate domains? > Or may this be only of interest to specific protocols like UMA? > > From a technique principle, the draft is important and sound. I am > just not there yet on the reasons for an interoperable standard. > > Phil > > On Jul 28, 2014, at 17:00, Thomas Broyer > wrote: > >> Yes. This spec is of special interest to the platform we're building >> for http://www.oasis-eu.org/ >> >> >> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >> > wrote: >> >> Hi all, >> >> during the IETF #90 OAuth WG meeting, there was strong consensus in >> adopting the "OAuth Token Introspection" >> (draft-richer-oauth-introspection-06.txt) specification as an >> OAuth WG >> work item. >> >> We would now like to verify the outcome of this call for adoption >> on the >> OAuth WG mailing list. Here is the link to the document: >> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >> >> If you did not hum at the IETF 90 OAuth WG meeting, and have an >> opinion >> as to the suitability of adopting this document as a WG work item, >> please send mail to the OAuth WG list indicating your opinion >> (Yes/No). >> >> The confirmation call for adoption will last until August 10, >> 2014. If >> you have issues/edits/comments on the document, please send these >> comments along to the list in your response to this Call for >> Adoption. >> >> Ciao >> Hannes & Derek >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> -- >> Thomas Broyer >> /t?.ma.b?wa.je/ >> _______________________________________________ >> 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 --------------000905090208050307080007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS.

Thanks,
George
On 7/28/14, 8:11 PM, Phil Hunt wrote:
Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/


On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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




--
Thomas Broyer
/tɔ.ma.bʁwa.je/
_______________________________________________
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

--------------000905090208050307080007-- From nobody Tue Jul 29 16:44:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB27B1A037C for ; Tue, 29 Jul 2014 16:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 mqiTw3EY6d9e for ; Tue, 29 Jul 2014 16:44:42 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68EB31A0337 for ; Tue, 29 Jul 2014 16:44:42 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6TNiciB013908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Jul 2014 23:44:38 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6TNibUT008716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2014 23:44:37 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6TNibku027542; Tue, 29 Jul 2014 23:44:37 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Jul 2014 16:44:36 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_9363A154-307E-453F-A8C5-7316111D274A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <53D81F2C.2060700@aol.com> Date: Tue, 29 Jul 2014 16:44:34 -0700 Message-Id: <3A57B125-504B-4427-930A-75F0D58AF26C@oracle.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> To: George Fletcher X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/nVqNIkWBUA6exnYO86zyRSSJ6qI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 29 Jul 2014 23:44:45 -0000 --Apple-Mail=_9363A154-307E-453F-A8C5-7316111D274A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks everyone for the comments. It sounds like we have multiple dimensions to introspection features and = requirements:=20 * there are UMA cases,=20 * corporate third-party AS-RS relationships (e.g. the RS chooses a = third-party AS),=20 * multi-vendor cases,=20 * tooling/library cases, There=E2=80=99s also federation cases. Federated authorization seems = like a different problem than federated authentication from a trust = perspective. Another dimension to this is methodology: 1. Lookup by token / token id / reference 2. Query by token / token id / reference 3. Passing standardized information in a standardized token format or = token URI. There may be some complex privacy issues involved as well. For example, = in many cases, the desire is to allow authz information *only* the = actual content owner / delegator may be intentionally pseudonymous. I would support first developing a use case document to figure out if = there is an appropriate pattern that can satisfy (and simplify) a = majority of cases. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 29, 2014, at 3:24 PM, George Fletcher wrote: > We also have a use case where the AS is provided by a partner and the = RS is provided by AOL. Being able to have a standardized way of = validating and getting data about the token from the AS would make our = implementation much simpler as we can use the same mechanism for all = Authorization Servers and not have to implement one off solutions for = each AS. >=20 > Thanks, > George >=20 > On 7/28/14, 8:11 PM, Phil Hunt wrote: >> Could we have some discussion on the interop cases? >>=20 >> Is it driven by scenarios where AS and resource are separate domains? = Or may this be only of interest to specific protocols like UMA? >>=20 >> =46rom a technique principle, the draft is important and sound. I am = just not there yet on the reasons for an interoperable standard.=20 >>=20 >> Phil >>=20 >> On Jul 28, 2014, at 17:00, Thomas Broyer wrote: >>=20 >>> Yes. This spec is of special interest to the platform we're building = for http://www.oasis-eu.org/ >>>=20 >>>=20 >>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig = wrote: >>> Hi all, >>>=20 >>> during the IETF #90 OAuth WG meeting, there was strong consensus in >>> adopting the "OAuth Token Introspection" >>> (draft-richer-oauth-introspection-06.txt) specification as an OAuth = WG >>> work item. >>>=20 >>> We would now like to verify the outcome of this call for adoption on = the >>> OAuth WG mailing list. Here is the link to the document: >>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>=20 >>> If you did not hum at the IETF 90 OAuth WG meeting, and have an = opinion >>> as to the suitability of adopting this document as a WG work item, >>> please send mail to the OAuth WG list indicating your opinion = (Yes/No). >>>=20 >>> The confirmation call for adoption will last until August 10, 2014. = If >>> you have issues/edits/comments on the document, please send these >>> comments along to the list in your response to this Call for = Adoption. >>>=20 >>> Ciao >>> Hannes & Derek >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Thomas Broyer >>> /t=C9=94.ma.b=CA=81wa.je/ >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_9363A154-307E-453F-A8C5-7316111D274A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks = everyone for the comments.

It sounds like we have = multiple dimensions to introspection features and = requirements: 

* there are UMA = cases, 
* corporate third-party AS-RS relationships (e.g. = the RS chooses a third-party AS), 
* multi-vendor = cases, 
* tooling/library = cases,

There=E2=80=99s also federation cases. = Federated authorization seems like a different problem than federated = authentication from a trust perspective.

Another = dimension to this is methodology:
1.  Lookup by token / = token id / reference
2.  Query by token / token id / = reference
3.  Passing standardized information in a = standardized token format or token URI.

There = may be some complex privacy issues involved as well. For example, in = many cases, the desire is to allow authz information *only* the actual = content owner / delegator may be intentionally = pseudonymous.

I would support first = developing a use case document to figure out if there is an appropriate = pattern that can satisfy (and simplify) a majority of = cases.

Phil

On Jul 29, 2014, at 3:24 PM, George Fletcher <gffletch@aol.com> = wrote:

=20 =20
We also have a use case = where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all = Authorization Servers and not have to implement one off solutions for each = AS.

Thanks,
George
On 7/28/14, 8:11 PM, Phil Hunt = wrote:
Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

=46rom a technique principle, the draft is important and = sound. I am just not there yet on the reasons for an interoperable standard. 

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/


On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the = document:
http://datatracker.ietf.org/doc/draft-richer-oauth-intro= spection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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




--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
=
_______________________________________________
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=_9363A154-307E-453F-A8C5-7316111D274A-- From nobody Tue Jul 29 17:16:49 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7BC1A03A9 for ; Tue, 29 Jul 2014 17:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJfpDR8X8opt for ; Tue, 29 Jul 2014 17:16:46 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3719C1A0104 for ; Tue, 29 Jul 2014 17:16:45 -0700 (PDT) Received: from BLUPR03MB614.namprd03.prod.outlook.com (10.255.124.42) by BLUPR03MB002.namprd03.prod.outlook.com (10.255.208.36) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 30 Jul 2014 00:16:45 +0000 Received: from BY2PR03CA066.namprd03.prod.outlook.com (10.141.249.39) by BLUPR03MB614.namprd03.prod.outlook.com (10.255.124.42) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 30 Jul 2014 00:16:43 +0000 Received: from BY2FFO11FD007.protection.gbl (2a01:111:f400:7c0c::164) by BY2PR03CA066.outlook.office365.com (2a01:111:e400:2c5d::39) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Wed, 30 Jul 2014 00:16:43 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD007.mail.protection.outlook.com (10.1.14.128) with Microsoft SMTP Server (TLS) id 15.0.990.10 via Frontend Transport; Wed, 30 Jul 2014 00:16:42 +0000 Received: from TK5EX14MBXC293.redmond.corp.microsoft.com ([169.254.2.111]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0195.002; Wed, 30 Jul 2014 00:16:30 +0000 From: Mike Jones To: George Fletcher , Phil Hunt , Thomas Broyer Thread-Topic: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item Thread-Index: AQHPqooP3+C2DjUTZkSSZigQ7bEA65u2KzcAgAAC6YCAAXSXAIAAHpYg Date: Wed, 30 Jul 2014 00:16:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> In-Reply-To: <53D81F2C.2060700@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADF77B2TK5EX14MBXC293r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(189002)(199002)(24454002)(53754006)(164054003)(377454003)(479174003)(87936001)(26826002)(81342001)(76176999)(81542001)(64706001)(31966008)(74502001)(33656002)(44976005)(76482001)(19625215002)(54356999)(19300405004)(19580395003)(15202345003)(6806004)(93886003)(85852003)(46102001)(71186001)(15975445006)(74662001)(92566001)(2656002)(69596002)(92726001)(86362001)(20776003)(512874002)(4396001)(68736004)(16236675004)(85306003)(86612001)(97736001)(83072002)(80022001)(55846006)(106116001)(77982001)(66066001)(95666004)(106466001)(77096002)(99396002)(79102001)(21056001)(83322001)(19617315012)(84326002)(50986999)(19580405001)(107046002)(81156004)(104016003)(84676001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB614; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0288CD37D9 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/do6L7KR4uCs5LQ4i9eNwhEw8RPo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 00:16:49 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADF77B2TK5EX14MBXC293r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGlkIHlvdSBjb25zaWRlciBzdGFuZGFyZGl6aW5nIHRoZSBhY2Nlc3MgdG9rZW4gZm9ybWF0IHdp dGhpbiB0aGF0IGRlcGxveW1lbnQgc28gYWxsIHRoZSBwYXJ0aWVzIHRoYXQgbmVlZGVkIHRvIGNv dWxkIHVuZGVyc3RhbmQgaXQsIHJhdGhlciByZXF1aXJpbmcgYW4gZXh0cmEgcm91bmQgdHJpcCB0 byBhbiBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IHNvIGFzIHRvIGJlIGFibGUgdG8gdW5kZXJzdGFu ZCB0aGluZ3MgYWJvdXQgaXQ/DQoNCkkgcmVhbGl6ZSB0aGF0IG1pZ2h0IG9yIG1pZ2h0IG5vdCBi ZSBwcmFjdGljYWwgaW4gc29tZSBjYXNlcywgYnV0IEkgaGF2ZW7igJl0IGhlYXJkIHRoYXQgYWx0 ZXJuYXRpdmUgZGlzY3Vzc2VkLCBzbyBJIHRob3VnaHQgSeKAmWQgYnJpbmcgaXQgdXAuDQoNCkkg YWxzbyBzZWNvbmQgUGhpbOKAmXMgY29tbWVudCB0aGF0IGl0IHdvdWxkIGJlIGdvb2QgdG8gdW5k ZXJzdGFuZCB0aGUgdXNlIGNhc2VzIHRoYXQgdGhpcyBpcyBpbnRlbmRlZCB0byBzb2x2ZSBiZWZv cmUgZW1iYXJraW5nIG9uIGEgcGFydGljdWxhciBzb2x1dGlvbiBwYXRoLg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEdlb3JnZSBGbGV0Y2hlcg0KU2VudDogVHVlc2RheSwgSnVseSAyOSwgMjAxNCAzOjI1IFBN DQpUbzogUGhpbCBIdW50OyBUaG9tYXMgQnJveWVyDQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIENvbmZpcm1hdGlvbjogQ2FsbCBmb3IgQWRvcHRpb24gb2YgIk9B dXRoIFRva2VuIEludHJvc3BlY3Rpb24iIGFzIGFuIE9BdXRoIFdvcmtpbmcgR3JvdXAgSXRlbQ0K DQpXZSBhbHNvIGhhdmUgYSB1c2UgY2FzZSB3aGVyZSB0aGUgQVMgaXMgcHJvdmlkZWQgYnkgYSBw YXJ0bmVyIGFuZCB0aGUgUlMgaXMgcHJvdmlkZWQgYnkgQU9MLiBCZWluZyBhYmxlIHRvIGhhdmUg YSBzdGFuZGFyZGl6ZWQgd2F5IG9mIHZhbGlkYXRpbmcgYW5kIGdldHRpbmcgZGF0YSBhYm91dCB0 aGUgdG9rZW4gZnJvbSB0aGUgQVMgd291bGQgbWFrZSBvdXIgaW1wbGVtZW50YXRpb24gbXVjaCBz aW1wbGVyIGFzIHdlIGNhbiB1c2UgdGhlIHNhbWUgbWVjaGFuaXNtIGZvciBhbGwgQXV0aG9yaXph dGlvbiBTZXJ2ZXJzIGFuZCBub3QgaGF2ZSB0byBpbXBsZW1lbnQgb25lIG9mZiBzb2x1dGlvbnMg Zm9yIGVhY2ggQVMuDQoNClRoYW5rcywNCkdlb3JnZQ0KT24gNy8yOC8xNCwgODoxMSBQTSwgUGhp bCBIdW50IHdyb3RlOg0KQ291bGQgd2UgaGF2ZSBzb21lIGRpc2N1c3Npb24gb24gdGhlIGludGVy b3AgY2FzZXM/DQoNCklzIGl0IGRyaXZlbiBieSBzY2VuYXJpb3Mgd2hlcmUgQVMgYW5kIHJlc291 cmNlIGFyZSBzZXBhcmF0ZSBkb21haW5zPyBPciBtYXkgdGhpcyBiZSBvbmx5IG9mIGludGVyZXN0 IHRvIHNwZWNpZmljIHByb3RvY29scyBsaWtlIFVNQT8NCg0KRnJvbSBhIHRlY2huaXF1ZSBwcmlu Y2lwbGUsIHRoZSBkcmFmdCBpcyBpbXBvcnRhbnQgYW5kIHNvdW5kLiBJIGFtIGp1c3Qgbm90IHRo ZXJlIHlldCBvbiB0aGUgcmVhc29ucyBmb3IgYW4gaW50ZXJvcGVyYWJsZSBzdGFuZGFyZC4NCg0K UGhpbA0KDQpPbiBKdWwgMjgsIDIwMTQsIGF0IDE3OjAwLCBUaG9tYXMgQnJveWVyIDx0LmJyb3ll ckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+IHdyb3RlOg0KWWVzLiBUaGlz IHNwZWMgaXMgb2Ygc3BlY2lhbCBpbnRlcmVzdCB0byB0aGUgcGxhdGZvcm0gd2UncmUgYnVpbGRp bmcgZm9yIGh0dHA6Ly93d3cub2FzaXMtZXUub3JnLw0KDQpPbiBNb24sIEp1bCAyOCwgMjAxNCBh dCA3OjMzIFBNLCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxt YWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdyb3RlOg0KSGkgYWxsLA0KDQpkdXJp bmcgdGhlIElFVEYgIzkwIE9BdXRoIFdHIG1lZXRpbmcsIHRoZXJlIHdhcyBzdHJvbmcgY29uc2Vu c3VzIGluDQphZG9wdGluZyB0aGUgIk9BdXRoIFRva2VuIEludHJvc3BlY3Rpb24iDQooZHJhZnQt cmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDYudHh0KSBzcGVjaWZpY2F0aW9uIGFzIGFuIE9B dXRoIFdHDQp3b3JrIGl0ZW0uDQoNCldlIHdvdWxkIG5vdyBsaWtlIHRvIHZlcmlmeSB0aGUgb3V0 Y29tZSBvZiB0aGlzIGNhbGwgZm9yIGFkb3B0aW9uIG9uIHRoZQ0KT0F1dGggV0cgbWFpbGluZyBs aXN0LiBIZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBkb2N1bWVudDoNCmh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24vDQoNCklmIHlv dSBkaWQgbm90IGh1bSBhdCB0aGUgSUVURiA5MCBPQXV0aCBXRyBtZWV0aW5nLCBhbmQgaGF2ZSBh biBvcGluaW9uDQphcyB0byB0aGUgc3VpdGFiaWxpdHkgb2YgYWRvcHRpbmcgdGhpcyBkb2N1bWVu dCBhcyBhIFdHIHdvcmsgaXRlbSwNCnBsZWFzZSBzZW5kIG1haWwgdG8gdGhlIE9BdXRoIFdHIGxp c3QgaW5kaWNhdGluZyB5b3VyIG9waW5pb24gKFllcy9ObykuDQoNClRoZSBjb25maXJtYXRpb24g Y2FsbCBmb3IgYWRvcHRpb24gd2lsbCBsYXN0IHVudGlsIEF1Z3VzdCAxMCwgMjAxNC4gIElmDQp5 b3UgaGF2ZSBpc3N1ZXMvZWRpdHMvY29tbWVudHMgb24gdGhlIGRvY3VtZW50LCBwbGVhc2Ugc2Vu ZCB0aGVzZQ0KY29tbWVudHMgYWxvbmcgdG8gdGhlIGxpc3QgaW4geW91ciByZXNwb25zZSB0byB0 aGlzIENhbGwgZm9yIEFkb3B0aW9uLg0KDQpDaWFvDQpIYW5uZXMgJiBEZXJlaw0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpUaG9tYXMgQnJveWVy DQovdMmULm1hLmLKgXdhLmplLzxodHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlz dA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_4E1F6AAD24975D4BA5B16804296739439ADF77B2TK5EX14MBXC293r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRpZCB5 b3UgY29uc2lkZXIgc3RhbmRhcmRpemluZyB0aGUgYWNjZXNzIHRva2VuIGZvcm1hdCB3aXRoaW4g dGhhdCBkZXBsb3ltZW50IHNvIGFsbCB0aGUgcGFydGllcyB0aGF0IG5lZWRlZCB0byBjb3VsZCB1 bmRlcnN0YW5kIGl0LCByYXRoZXIgcmVxdWlyaW5nIGFuIGV4dHJhDQogcm91bmQgdHJpcCB0byBh biBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IHNvIGFzIHRvIGJlIGFibGUgdG8gdW5kZXJzdGFuZCB0 aGluZ3MgYWJvdXQgaXQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHJlYWxpemUgdGhhdCBtaWdodCBvciBtaWdodCBu b3QgYmUgcHJhY3RpY2FsIGluIHNvbWUgY2FzZXMsIGJ1dCBJIGhhdmVu4oCZdCBoZWFyZCB0aGF0 IGFsdGVybmF0aXZlIGRpc2N1c3NlZCwgc28gSSB0aG91Z2h0IEnigJlkIGJyaW5nIGl0IHVwLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SSBhbHNvIHNlY29uZCBQaGls4oCZcyBjb21tZW50IHRoYXQgaXQgd291bGQgYmUg Z29vZCB0byB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZXMgdGhhdCB0aGlzIGlzIGludGVuZGVkIHRv IHNvbHZlIGJlZm9yZSBlbWJhcmtpbmcgb24gYSBwYXJ0aWN1bGFyIHNvbHV0aW9uIHBhdGguPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdlb3JnZSBGbGV0Y2hlcjxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0IDM6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IFBoaWwg SHVudDsgVGhvbWFzIEJyb3llcjxicj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gQ29uZmlybWF0aW9uOiBDYWxsIGZvciBBZG9w dGlvbiBvZiAmcXVvdDtPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uJnF1b3Q7IGFzIGFuIE9BdXRo IFdvcmtpbmcgR3JvdXAgSXRlbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XZSBh bHNvIGhhdmUgYSB1c2UgY2FzZSB3aGVyZSB0aGUgQVMgaXMgcHJvdmlkZWQgYnkgYSBwYXJ0bmVy IGFuZCB0aGUgUlMgaXMgcHJvdmlkZWQgYnkgQU9MLiBCZWluZyBhYmxlIHRvIGhhdmUgYSBzdGFu ZGFyZGl6ZWQgd2F5IG9mIHZhbGlkYXRpbmcgYW5kIGdldHRpbmcNCiBkYXRhIGFib3V0IHRoZSB0 b2tlbiBmcm9tIHRoZSBBUyB3b3VsZCBtYWtlIG91ciBpbXBsZW1lbnRhdGlvbiBtdWNoIHNpbXBs ZXIgYXMgd2UgY2FuIHVzZSB0aGUgc2FtZSBtZWNoYW5pc20gZm9yIGFsbCBBdXRob3JpemF0aW9u IFNlcnZlcnMgYW5kIG5vdCBoYXZlIHRvIGltcGxlbWVudCBvbmUgb2ZmIHNvbHV0aW9ucyBmb3Ig ZWFjaCBBUy48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KR2VvcmdlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDcvMjgvMTQsIDg6MTEgUE0sIFBo aWwgSHVudCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Q291bGQgd2UgaGF2ZSBzb21lIGRpc2N1c3Npb24gb24gdGhlIGludGVyb3Ag Y2FzZXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPklzIGl0IGRyaXZlbiBieSBzY2VuYXJpb3Mgd2hlcmUgQVMgYW5kIHJlc291cmNlIGFyZSBz ZXBhcmF0ZSBkb21haW5zPyBPciBtYXkgdGhpcyBiZSBvbmx5IG9mIGludGVyZXN0IHRvIHNwZWNp ZmljIHByb3RvY29scyBsaWtlIFVNQT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJvbSBhIHRlY2huaXF1ZSBwcmluY2lwbGUsIHRoZSBkcmFm dCBpcyBpbXBvcnRhbnQgYW5kIHNvdW5kLiBJIGFtIGp1c3Qgbm90IHRoZXJlIHlldCBvbiB0aGUg cmVhc29ucyBmb3IgYW4gaW50ZXJvcGVyYWJsZSBzdGFuZGFyZC4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQpPbiBKdWwgMjgsIDIwMTQsIGF0IDE3OjAwLCBUaG9tYXMgQnJv eWVyICZsdDs8YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21haWwuY29tIj50LmJyb3llckBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcy4gVGhpcyBzcGVjIGlzIG9mIHNwZWNpYWwgaW50 ZXJlc3QgdG8gdGhlIHBsYXRmb3JtIHdlJ3JlIGJ1aWxkaW5nIGZvciZuYnNwOzxhIGhyZWY9Imh0 dHA6Ly93d3cub2FzaXMtZXUub3JnLyI+aHR0cDovL3d3dy5vYXNpcy1ldS5vcmcvPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBNb24sIEp1bCAyOCwgMjAxNCBhdCA3OjMzIFBNLCBIYW5uZXMgVHNj aG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiIHRh cmdldD0iX2JsYW5rIj5oYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPkhpIGFsbCw8YnI+DQo8YnI+DQpkdXJpbmcgdGhlIElFVEYgIzkwIE9BdXRoIFdHIG1l ZXRpbmcsIHRoZXJlIHdhcyBzdHJvbmcgY29uc2Vuc3VzIGluPGJyPg0KYWRvcHRpbmcgdGhlICZx dW90O09BdXRoIFRva2VuIEludHJvc3BlY3Rpb24mcXVvdDs8YnI+DQooZHJhZnQtcmljaGVyLW9h dXRoLWludHJvc3BlY3Rpb24tMDYudHh0KSBzcGVjaWZpY2F0aW9uIGFzIGFuIE9BdXRoIFdHPGJy Pg0Kd29yayBpdGVtLjxicj4NCjxicj4NCldlIHdvdWxkIG5vdyBsaWtlIHRvIHZlcmlmeSB0aGUg b3V0Y29tZSBvZiB0aGlzIGNhbGwgZm9yIGFkb3B0aW9uIG9uIHRoZTxicj4NCk9BdXRoIFdHIG1h aWxpbmcgbGlzdC4gSGVyZSBpcyB0aGUgbGluayB0byB0aGUgZG9jdW1lbnQ6PGJyPg0KPGEgaHJl Zj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yaWNoZXItb2F1dGgtaW50 cm9zcGVjdGlvbi8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLzwvYT48YnI+DQo8YnI+DQpJZiB5 b3UgZGlkIG5vdCBodW0gYXQgdGhlIElFVEYgOTAgT0F1dGggV0cgbWVldGluZywgYW5kIGhhdmUg YW4gb3Bpbmlvbjxicj4NCmFzIHRvIHRoZSBzdWl0YWJpbGl0eSBvZiBhZG9wdGluZyB0aGlzIGRv Y3VtZW50IGFzIGEgV0cgd29yayBpdGVtLDxicj4NCnBsZWFzZSBzZW5kIG1haWwgdG8gdGhlIE9B dXRoIFdHIGxpc3QgaW5kaWNhdGluZyB5b3VyIG9waW5pb24gKFllcy9ObykuPGJyPg0KPGJyPg0K VGhlIGNvbmZpcm1hdGlvbiBjYWxsIGZvciBhZG9wdGlvbiB3aWxsIGxhc3QgdW50aWwgQXVndXN0 IDEwLCAyMDE0LiAmbmJzcDtJZjxicj4NCnlvdSBoYXZlIGlzc3Vlcy9lZGl0cy9jb21tZW50cyBv biB0aGUgZG9jdW1lbnQsIHBsZWFzZSBzZW5kIHRoZXNlPGJyPg0KY29tbWVudHMgYWxvbmcgdG8g dGhlIGxpc3QgaW4geW91ciByZXNwb25zZSB0byB0aGlzIENhbGwgZm9yIEFkb3B0aW9uLjxicj4N Cjxicj4NCkNpYW88YnI+DQpIYW5uZXMgJmFtcDsgRGVyZWs8YnI+DQo8YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tLSA8YnI+DQpUaG9tYXMgQnJveWVyPGJyPg0KL3Q8YSBocmVmPSJodHRw Oi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8iPsmULm1hLmLKgXdhLmplLzwvYT4gPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_4E1F6AAD24975D4BA5B16804296739439ADF77B2TK5EX14MBXC293r_-- From nobody Tue Jul 29 17:42:49 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217721A0298 for ; Tue, 29 Jul 2014 17:42:48 -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 BYNfWQmOxGux for ; Tue, 29 Jul 2014 17:42:45 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88461B28F7 for ; Tue, 29 Jul 2014 17:42:44 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id pv20so335894lab.1 for ; Tue, 29 Jul 2014 17:42: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=uU8C3yf1BZuv6FEMuqCQEOSZu5EYAUbrYDcF9lLVQQ0=; b=PRsw55utgT8GzIxKU9MrhbiRgiidnGENa8vaZ8lb/WPpe6WuEmR0F3zejn8fwYf//W MemW8BGIZ9H8eURMsZhfofpTzyq+Twh3cspPifV/3YLIcS7S1NWNzHhB+xYB7ViWP5hg VofNOeSB2NPmvdm4Dfn+8oGOGgj7YWf/YKg/yuktzX7zw3zvLVQmG1GsGV1L2MUIn9x1 AF+Mb9DquIIL3ticcPusGF3gdBh5+AgETjFHau0mYUEdieGegMTXF6tjcPJJ7idzqQXw 0MgTpXWOEK1w4iMai3uUbsOq3+uq+iVF/KYafTlCenCNBV6L3pwG7KEwGESSRtx8jq2W HAXg== MIME-Version: 1.0 X-Received: by 10.152.204.5 with SMTP id ku5mr529420lac.68.1406680963047; Tue, 29 Jul 2014 17:42:43 -0700 (PDT) Received: by 10.152.113.73 with HTTP; Tue, 29 Jul 2014 17:42:42 -0700 (PDT) Received: by 10.152.113.73 with HTTP; Tue, 29 Jul 2014 17:42:42 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> Date: Wed, 30 Jul 2014 02:42:42 +0200 Message-ID: From: Thomas Broyer To: Mike Jones Content-Type: multipart/alternative; boundary=001a113451701d669604ff5e6ff1 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ircUY7w1EXxq1Jp3Aa4O_RwDX68 Cc: "" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 00:42:48 -0000 --001a113451701d669604ff5e6ff1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Decoding a token with a specific format wouldn't tell you whether the token is still live: it could have been revoked before its expiration. Le 30 juil. 2014 02:16, "Mike Jones" a =C3=A9= crit : > Did you consider standardizing the access token format within that > deployment so all the parties that needed to could understand it, rather > requiring an extra round trip to an introspection endpoint so as to be ab= le > to understand things about it? > > > > I realize that might or might not be practical in some cases, but I > haven=E2=80=99t heard that alternative discussed, so I thought I=E2=80=99= d bring it up. > > > > I also second Phil=E2=80=99s comment that it would be good to understand = the use > cases that this is intended to solve before embarking on a particular > solution path. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George > Fletcher > *Sent:* Tuesday, July 29, 2014 3:25 PM > *To:* Phil Hunt; Thomas Broyer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token > Introspection" as an OAuth Working Group Item > > > > We also have a use case where the AS is provided by a partner and the RS > is provided by AOL. Being able to have a standardized way of validating a= nd > getting data about the token from the AS would make our implementation mu= ch > simpler as we can use the same mechanism for all Authorization Servers an= d > not have to implement one off solutions for each AS. > > Thanks, > George > > On 7/28/14, 8:11 PM, Phil Hunt wrote: > > Could we have some discussion on the interop cases? > > > > Is it driven by scenarios where AS and resource are separate domains? Or > may this be only of interest to specific protocols like UMA? > > > > From a technique principle, the draft is important and sound. I am just > not there yet on the reasons for an interoperable standard. > > > > Phil > > > On Jul 28, 2014, at 17:00, Thomas Broyer wrote: > > Yes. This spec is of special interest to the platform we're building for > http://www.oasis-eu.org/ > > > > On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > > Hi all, > > during the IETF #90 OAuth WG meeting, there was strong consensus in > adopting the "OAuth Token Introspection" > (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG > work item. > > We would now like to verify the outcome of this call for adoption on the > OAuth WG mailing list. Here is the link to the document: > http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ > > If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion > as to the suitability of adopting this document as a WG work item, > please send mail to the OAuth WG list indicating your opinion (Yes/No). > > The confirmation call for adoption will last until August 10, 2014. If > you have issues/edits/comments on the document, please send these > comments along to the list in your response to this Call for Adoption. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > > _______________________________________________ > 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 > > > --001a113451701d669604ff5e6ff1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Decoding a token with a specific format wouldn't tell yo= u whether the token is still live: it could have been revoked before its ex= piration.

Le 30 juil. 2014 02:16, "Mike Jones" &= lt;Michael.Jones@microsoft.c= om> a =C3=A9crit :

Did you consider standard= izing the access token format within that deployment so all the parties tha= t needed to could understand it, rather requiring an extra round trip to an introspection endpoint so as to be able to understand thi= ngs about it?

=C2=A0

I realize that might or m= ight not be practical in some cases, but I haven=E2=80=99t heard that alter= native discussed, so I thought I=E2=80=99d bring it up.

=C2=A0

I also second Phil=E2=80= =99s comment that it would be good to understand the use cases that this is= intended to solve before embarking on a particular solution path.

=C2=A0

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAu= th Token Introspection" as an OAuth Working Group Item

=C2=A0

We also have a use case= where the AS is provided by a partner and the RS is provided by AOL. Being= able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simple= r as we can use the same mechanism for all Authorization Servers and not ha= ve to implement one off solutions for each AS.

Thanks,
George

On 7/28/14, 8:11 PM, Phil Hunt wrote:<= /p>

Could we have some discussion on the interop cases?<= u>

=C2=A0

Is it driven by scenarios where AS and resource are = separate domains? Or may this be only of interest to specific protocols lik= e UMA?

=C2=A0

From a technique principle, the draft is important a= nd sound. I am just not there yet on the reasons for an interoperable stand= ard.=C2=A0

=C2=A0

Phil


On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platfor= m we're building for=C2=A0http://www.oasis-eu.org/

=C2=A0<= /p>

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig &= lt;hannes.ts= chofenig@gmx.net> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-int= rospection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014. =C2=A0I= f
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/

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




_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

--001a113451701d669604ff5e6ff1-- From nobody Tue Jul 29 17:50:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CC91B29FF for ; Tue, 29 Jul 2014 17:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzwKC3UAenYu for ; Tue, 29 Jul 2014 17:49:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86351A0298 for ; Tue, 29 Jul 2014 17:49:56 -0700 (PDT) Received: from BLUPR03MB614.namprd03.prod.outlook.com (10.255.124.42) by BLUPR03MB504.namprd03.prod.outlook.com (10.141.80.28) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 30 Jul 2014 00:49:55 +0000 Received: from CH1PR03CA007.namprd03.prod.outlook.com (10.255.156.152) by BLUPR03MB614.namprd03.prod.outlook.com (10.255.124.42) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 30 Jul 2014 00:49:54 +0000 Received: from BY2FFO11FD030.protection.gbl (10.255.156.132) by CH1PR03CA007.outlook.office365.com (10.255.156.152) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Wed, 30 Jul 2014 00:49:54 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD030.mail.protection.outlook.com (10.1.14.211) with Microsoft SMTP Server (TLS) id 15.0.990.10 via Frontend Transport; Wed, 30 Jul 2014 00:49:53 +0000 Received: from TK5EX14MBXC293.redmond.corp.microsoft.com ([169.254.2.111]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Wed, 30 Jul 2014 00:49:24 +0000 From: Mike Jones To: Thomas Broyer Thread-Topic: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item Thread-Index: AQHPqooP3+C2DjUTZkSSZigQ7bEA65u2KzcAgAAC6YCAAXSXAIAAHpYggAAH9gCAAAGwUA== Date: Wed, 30 Jul 2014 00:49:23 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADF7A6FTK5EX14MBXC293r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(189002)(199002)(24454002)(53754006)(164054003)(377454003)(479174003)(87936001)(26826002)(74502001)(81342001)(81542001)(64706001)(31966008)(33656002)(44976005)(76482001)(19625215002)(19300405004)(19580395003)(15202345003)(54356999)(6806004)(93886003)(85852003)(76176999)(71186001)(15975445006)(46102001)(74662001)(92566001)(2656002)(69596002)(92726001)(86362001)(20776003)(512874002)(4396001)(16236675004)(85306003)(68736004)(86612001)(97736001)(80022001)(83072002)(55846006)(106116001)(77982001)(66066001)(95666004)(106466001)(77096002)(99396002)(79102001)(21056001)(83322001)(19617315012)(84326002)(50986999)(19580405001)(107046002)(81156004)(104016003)(84676001)(110136001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB614; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0288CD37D9 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7I02Q_mwMsODN2UvuJFdl55cf44 Cc: "" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 00:50:00 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADF7A6FTK5EX14MBXC293r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBidXQgdGhhdOKAmXMgdGhlIHNpbXBsZXN0IHRoaW5nIHRvIGRldGVybWluZSDigJMgdHJ5 IHRoZSB0b2tlbiBhbmQgc2VlIHdoZXRoZXIgaXQgd29ya3Mgb3Igbm90Lg0KDQpGcm9tOiBUaG9t YXMgQnJveWVyIFttYWlsdG86dC5icm95ZXJAZ21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgSnVs eSAyOSwgMjAxNCA1OjQzIFBNDQpUbzogTWlrZSBKb25lcw0KQ2M6IDxvYXV0aEBpZXRmLm9yZz47 IEdlb3JnZSBGbGV0Y2hlcjsgUGhpbCBIdW50DQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBDb25m aXJtYXRpb246IENhbGwgZm9yIEFkb3B0aW9uIG9mICJPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9u IiBhcyBhbiBPQXV0aCBXb3JraW5nIEdyb3VwIEl0ZW0NCg0KDQpEZWNvZGluZyBhIHRva2VuIHdp dGggYSBzcGVjaWZpYyBmb3JtYXQgd291bGRuJ3QgdGVsbCB5b3Ugd2hldGhlciB0aGUgdG9rZW4g aXMgc3RpbGwgbGl2ZTogaXQgY291bGQgaGF2ZSBiZWVuIHJldm9rZWQgYmVmb3JlIGl0cyBleHBp cmF0aW9uLg0KTGUgMzAganVpbC4gMjAxNCAwMjoxNiwgIk1pa2UgSm9uZXMiIDxNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IGEg w6ljcml0IDoNCkRpZCB5b3UgY29uc2lkZXIgc3RhbmRhcmRpemluZyB0aGUgYWNjZXNzIHRva2Vu IGZvcm1hdCB3aXRoaW4gdGhhdCBkZXBsb3ltZW50IHNvIGFsbCB0aGUgcGFydGllcyB0aGF0IG5l ZWRlZCB0byBjb3VsZCB1bmRlcnN0YW5kIGl0LCByYXRoZXIgcmVxdWlyaW5nIGFuIGV4dHJhIHJv dW5kIHRyaXAgdG8gYW4gaW50cm9zcGVjdGlvbiBlbmRwb2ludCBzbyBhcyB0byBiZSBhYmxlIHRv IHVuZGVyc3RhbmQgdGhpbmdzIGFib3V0IGl0Pw0KDQpJIHJlYWxpemUgdGhhdCBtaWdodCBvciBt aWdodCBub3QgYmUgcHJhY3RpY2FsIGluIHNvbWUgY2FzZXMsIGJ1dCBJIGhhdmVu4oCZdCBoZWFy ZCB0aGF0IGFsdGVybmF0aXZlIGRpc2N1c3NlZCwgc28gSSB0aG91Z2h0IEnigJlkIGJyaW5nIGl0 IHVwLg0KDQpJIGFsc28gc2Vjb25kIFBoaWzigJlzIGNvbW1lbnQgdGhhdCBpdCB3b3VsZCBiZSBn b29kIHRvIHVuZGVyc3RhbmQgdGhlIHVzZSBjYXNlcyB0aGF0IHRoaXMgaXMgaW50ZW5kZWQgdG8g c29sdmUgYmVmb3JlIGVtYmFya2luZyBvbiBhIHBhcnRpY3VsYXIgc29sdXRpb24gcGF0aC4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgR2VvcmdlIEZsZXRj aGVyDQpTZW50OiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0IDM6MjUgUE0NClRvOiBQaGlsIEh1bnQ7 IFRob21hcyBCcm95ZXINCkNjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBDb25maXJtYXRpb246IENhbGwgZm9yIEFkb3B0aW9u IG9mICJPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uIiBhcyBhbiBPQXV0aCBXb3JraW5nIEdyb3Vw IEl0ZW0NCg0KV2UgYWxzbyBoYXZlIGEgdXNlIGNhc2Ugd2hlcmUgdGhlIEFTIGlzIHByb3ZpZGVk IGJ5IGEgcGFydG5lciBhbmQgdGhlIFJTIGlzIHByb3ZpZGVkIGJ5IEFPTC4gQmVpbmcgYWJsZSB0 byBoYXZlIGEgc3RhbmRhcmRpemVkIHdheSBvZiB2YWxpZGF0aW5nIGFuZCBnZXR0aW5nIGRhdGEg YWJvdXQgdGhlIHRva2VuIGZyb20gdGhlIEFTIHdvdWxkIG1ha2Ugb3VyIGltcGxlbWVudGF0aW9u IG11Y2ggc2ltcGxlciBhcyB3ZSBjYW4gdXNlIHRoZSBzYW1lIG1lY2hhbmlzbSBmb3IgYWxsIEF1 dGhvcml6YXRpb24gU2VydmVycyBhbmQgbm90IGhhdmUgdG8gaW1wbGVtZW50IG9uZSBvZmYgc29s dXRpb25zIGZvciBlYWNoIEFTLg0KDQpUaGFua3MsDQpHZW9yZ2UNCk9uIDcvMjgvMTQsIDg6MTEg UE0sIFBoaWwgSHVudCB3cm90ZToNCkNvdWxkIHdlIGhhdmUgc29tZSBkaXNjdXNzaW9uIG9uIHRo ZSBpbnRlcm9wIGNhc2VzPw0KDQpJcyBpdCBkcml2ZW4gYnkgc2NlbmFyaW9zIHdoZXJlIEFTIGFu ZCByZXNvdXJjZSBhcmUgc2VwYXJhdGUgZG9tYWlucz8gT3IgbWF5IHRoaXMgYmUgb25seSBvZiBp bnRlcmVzdCB0byBzcGVjaWZpYyBwcm90b2NvbHMgbGlrZSBVTUE/DQoNCkZyb20gYSB0ZWNobmlx dWUgcHJpbmNpcGxlLCB0aGUgZHJhZnQgaXMgaW1wb3J0YW50IGFuZCBzb3VuZC4gSSBhbSBqdXN0 IG5vdCB0aGVyZSB5ZXQgb24gdGhlIHJlYXNvbnMgZm9yIGFuIGludGVyb3BlcmFibGUgc3RhbmRh cmQuDQoNClBoaWwNCg0KT24gSnVsIDI4LCAyMDE0LCBhdCAxNzowMCwgVGhvbWFzIEJyb3llciA8 dC5icm95ZXJAZ21haWwuY29tPG1haWx0bzp0LmJyb3llckBnbWFpbC5jb20+PiB3cm90ZToNClll cy4gVGhpcyBzcGVjIGlzIG9mIHNwZWNpYWwgaW50ZXJlc3QgdG8gdGhlIHBsYXRmb3JtIHdlJ3Jl IGJ1aWxkaW5nIGZvciBodHRwOi8vd3d3Lm9hc2lzLWV1Lm9yZy8NCg0KT24gTW9uLCBKdWwgMjgs IDIwMTQgYXQgNzozMyBQTSwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdt eC5uZXQ8bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+PiB3cm90ZToNCkhpIGFsbCwN Cg0KZHVyaW5nIHRoZSBJRVRGICM5MCBPQXV0aCBXRyBtZWV0aW5nLCB0aGVyZSB3YXMgc3Ryb25n IGNvbnNlbnN1cyBpbg0KYWRvcHRpbmcgdGhlICJPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uIg0K KGRyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLTA2LnR4dCkgc3BlY2lmaWNhdGlvbiBh cyBhbiBPQXV0aCBXRw0Kd29yayBpdGVtLg0KDQpXZSB3b3VsZCBub3cgbGlrZSB0byB2ZXJpZnkg dGhlIG91dGNvbWUgb2YgdGhpcyBjYWxsIGZvciBhZG9wdGlvbiBvbiB0aGUNCk9BdXRoIFdHIG1h aWxpbmcgbGlzdC4gSGVyZSBpcyB0aGUgbGluayB0byB0aGUgZG9jdW1lbnQ6DQpodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLw0K DQpJZiB5b3UgZGlkIG5vdCBodW0gYXQgdGhlIElFVEYgOTAgT0F1dGggV0cgbWVldGluZywgYW5k IGhhdmUgYW4gb3Bpbmlvbg0KYXMgdG8gdGhlIHN1aXRhYmlsaXR5IG9mIGFkb3B0aW5nIHRoaXMg ZG9jdW1lbnQgYXMgYSBXRyB3b3JrIGl0ZW0sDQpwbGVhc2Ugc2VuZCBtYWlsIHRvIHRoZSBPQXV0 aCBXRyBsaXN0IGluZGljYXRpbmcgeW91ciBvcGluaW9uIChZZXMvTm8pLg0KDQpUaGUgY29uZmly bWF0aW9uIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgbGFzdCB1bnRpbCBBdWd1c3QgMTAsIDIwMTQu ICBJZg0KeW91IGhhdmUgaXNzdWVzL2VkaXRzL2NvbW1lbnRzIG9uIHRoZSBkb2N1bWVudCwgcGxl YXNlIHNlbmQgdGhlc2UNCmNvbW1lbnRzIGFsb25nIHRvIHRoZSBsaXN0IGluIHlvdXIgcmVzcG9u c2UgdG8gdGhpcyBDYWxsIGZvciBBZG9wdGlvbi4NCg0KQ2lhbw0KSGFubmVzICYgRGVyZWsNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KVGhvbWFz IEJyb3llcg0KL3TJlC5tYS5iyoF3YS5qZS88aHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIu amUvPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGlu ZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_4E1F6AAD24975D4BA5B16804296739439ADF7A6FTK5EX14MBXC293r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVt YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCBidXQgdGhh dOKAmXMgdGhlIHNpbXBsZXN0IHRoaW5nIHRvIGRldGVybWluZSDigJMgdHJ5IHRoZSB0b2tlbiBh bmQgc2VlIHdoZXRoZXIgaXQgd29ya3Mgb3Igbm90LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gVGhvbWFzIEJyb3llciBbbWFpbHRvOnQuYnJveWVyQGdtYWlsLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0IDU6NDMgUE08YnI+ DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+ICZsdDtvYXV0aEBpZXRmLm9y ZyZndDs7IEdlb3JnZSBGbGV0Y2hlcjsgUGhpbCBIdW50PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJF OiBbT0FVVEgtV0ddIENvbmZpcm1hdGlvbjogQ2FsbCBmb3IgQWRvcHRpb24gb2YgJnF1b3Q7T0F1 dGggVG9rZW4gSW50cm9zcGVjdGlvbiZxdW90OyBhcyBhbiBPQXV0aCBXb3JraW5nIEdyb3VwIEl0 ZW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwPkRlY29kaW5nIGEgdG9rZW4gd2l0aCBhIHNwZWNpZmljIGZvcm1hdCB3 b3VsZG4ndCB0ZWxsIHlvdSB3aGV0aGVyIHRoZSB0b2tlbiBpcyBzdGlsbCBsaXZlOiBpdCBjb3Vs ZCBoYXZlIGJlZW4gcmV2b2tlZCBiZWZvcmUgaXRzIGV4cGlyYXRpb24uPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGUgMzAganVpbC4gMjAxNCAwMjoxNiwgJnF1 b3Q7TWlrZSBKb25lcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgYSDDqWNyaXQg OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EaWQgeW91IGNvbnNpZGVy IHN0YW5kYXJkaXppbmcgdGhlIGFjY2VzcyB0b2tlbiBmb3JtYXQgd2l0aGluIHRoYXQgZGVwbG95 bWVudCBzbyBhbGwgdGhlIHBhcnRpZXMNCiB0aGF0IG5lZWRlZCB0byBjb3VsZCB1bmRlcnN0YW5k IGl0LCByYXRoZXIgcmVxdWlyaW5nIGFuIGV4dHJhIHJvdW5kIHRyaXAgdG8gYW4gaW50cm9zcGVj dGlvbiBlbmRwb2ludCBzbyBhcyB0byBiZSBhYmxlIHRvIHVuZGVyc3RhbmQgdGhpbmdzIGFib3V0 IGl0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgcmVhbGl6ZSB0aGF0IG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBw cmFjdGljYWwgaW4gc29tZSBjYXNlcywgYnV0IEkgaGF2ZW7igJl0IGhlYXJkIHRoYXQgYWx0ZXJu YXRpdmUNCiBkaXNjdXNzZWQsIHNvIEkgdGhvdWdodCBJ4oCZZCBicmluZyBpdCB1cC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JIGFsc28gc2Vjb25kIFBoaWzigJlzIGNvbW1lbnQgdGhhdCBpdCB3b3VsZCBiZSBn b29kIHRvIHVuZGVyc3RhbmQgdGhlIHVzZSBjYXNlcyB0aGF0IHRoaXMgaXMgaW50ZW5kZWQNCiB0 byBzb2x2ZSBiZWZvcmUgZW1iYXJraW5nIG9uIGEgcGFydGljdWxhciBzb2x1dGlvbiBwYXRoLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IE9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+R2VvcmdlIEZsZXRjaGVyPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMjks IDIwMTQgMzoyNSBQTTxicj4NCjxiPlRvOjwvYj4gUGhpbCBIdW50OyBUaG9tYXMgQnJveWVyPGJy Pg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gQ29uZmlybWF0aW9uOiBDYWxsIGZvciBBZG9wdGlvbiBvZiAmcXVvdDtPQXV0aCBUb2tlbiBJ bnRyb3NwZWN0aW9uJnF1b3Q7IGFzIGFuIE9BdXRoIFdvcmtpbmcgR3JvdXAgSXRlbTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldlIGFs c28gaGF2ZSBhIHVzZSBjYXNlIHdoZXJlIHRoZSBBUyBpcyBwcm92aWRlZCBieSBhIHBhcnRuZXIg YW5kIHRoZSBSUyBpcyBwcm92aWRlZCBieSBBT0wuIEJlaW5nIGFibGUgdG8gaGF2ZSBhIHN0YW5k YXJkaXplZCB3YXkgb2YNCiB2YWxpZGF0aW5nIGFuZCBnZXR0aW5nIGRhdGEgYWJvdXQgdGhlIHRv a2VuIGZyb20gdGhlIEFTIHdvdWxkIG1ha2Ugb3VyIGltcGxlbWVudGF0aW9uIG11Y2ggc2ltcGxl ciBhcyB3ZSBjYW4gdXNlIHRoZSBzYW1lIG1lY2hhbmlzbSBmb3IgYWxsIEF1dGhvcml6YXRpb24g U2VydmVycyBhbmQgbm90IGhhdmUgdG8gaW1wbGVtZW50IG9uZSBvZmYgc29sdXRpb25zIGZvciBl YWNoIEFTLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpHZW9yZ2U8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiA3LzI4LzE0LCA4OjExIFBNLCBQ aGlsIEh1bnQgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Q291bGQgd2UgaGF2ZSBzb21lIGRpc2N1c3Npb24gb24gdGhlIGludGVy b3AgY2FzZXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5JcyBpdCBkcml2ZW4gYnkgc2NlbmFyaW9zIHdoZXJlIEFTIGFuZCByZXNvdXJj ZSBhcmUgc2VwYXJhdGUgZG9tYWlucz8gT3IgbWF5IHRoaXMgYmUgb25seSBvZiBpbnRlcmVzdCB0 byBzcGVjaWZpYyBwcm90b2NvbHMgbGlrZSBVTUE/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gcm9tIGEgdGVjaG5pcXVlIHByaW5jaXBs ZSwgdGhlIGRyYWZ0IGlzIGltcG9ydGFudCBhbmQgc291bmQuIEkgYW0ganVzdCBub3QgdGhlcmUg eWV0IG9uIHRoZSByZWFzb25zIGZvciBhbiBpbnRlcm9wZXJhYmxlIHN0YW5kYXJkLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpPbiBKdWwgMjgsIDIwMTQsIGF0IDE3OjAwLCBUaG9tYXMgQnJveWVyICZsdDs8YSBocmVmPSJt YWlsdG86dC5icm95ZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dC5icm95ZXJAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlllcy4gVGhpcyBzcGVjIGlzIG9mIHNwZWNpYWwgaW50 ZXJlc3QgdG8gdGhlIHBsYXRmb3JtIHdlJ3JlIGJ1aWxkaW5nIGZvciZuYnNwOzxhIGhyZWY9Imh0 dHA6Ly93d3cub2FzaXMtZXUub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cub2FzaXMt ZXUub3JnLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBNb24sIEp1bCAyOCwgMjAxNCBhdCA3OjMzIFBNLCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiIHRhcmdldD0iX2JsYW5rIj5o YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPkhpIGFsbCw8YnI+DQo8YnI+DQpkdXJpbmcgdGhlIElFVEYgIzkwIE9B dXRoIFdHIG1lZXRpbmcsIHRoZXJlIHdhcyBzdHJvbmcgY29uc2Vuc3VzIGluPGJyPg0KYWRvcHRp bmcgdGhlICZxdW90O09BdXRoIFRva2VuIEludHJvc3BlY3Rpb24mcXVvdDs8YnI+DQooZHJhZnQt cmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDYudHh0KSBzcGVjaWZpY2F0aW9uIGFzIGFuIE9B dXRoIFdHPGJyPg0Kd29yayBpdGVtLjxicj4NCjxicj4NCldlIHdvdWxkIG5vdyBsaWtlIHRvIHZl cmlmeSB0aGUgb3V0Y29tZSBvZiB0aGlzIGNhbGwgZm9yIGFkb3B0aW9uIG9uIHRoZTxicj4NCk9B dXRoIFdHIG1haWxpbmcgbGlzdC4gSGVyZSBpcyB0aGUgbGluayB0byB0aGUgZG9jdW1lbnQ6PGJy Pg0KPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yaWNoZXIt b2F1dGgtaW50cm9zcGVjdGlvbi8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLzwvYT48YnI+DQo8 YnI+DQpJZiB5b3UgZGlkIG5vdCBodW0gYXQgdGhlIElFVEYgOTAgT0F1dGggV0cgbWVldGluZywg YW5kIGhhdmUgYW4gb3Bpbmlvbjxicj4NCmFzIHRvIHRoZSBzdWl0YWJpbGl0eSBvZiBhZG9wdGlu ZyB0aGlzIGRvY3VtZW50IGFzIGEgV0cgd29yayBpdGVtLDxicj4NCnBsZWFzZSBzZW5kIG1haWwg dG8gdGhlIE9BdXRoIFdHIGxpc3QgaW5kaWNhdGluZyB5b3VyIG9waW5pb24gKFllcy9ObykuPGJy Pg0KPGJyPg0KVGhlIGNvbmZpcm1hdGlvbiBjYWxsIGZvciBhZG9wdGlvbiB3aWxsIGxhc3QgdW50 aWwgQXVndXN0IDEwLCAyMDE0LiAmbmJzcDtJZjxicj4NCnlvdSBoYXZlIGlzc3Vlcy9lZGl0cy9j b21tZW50cyBvbiB0aGUgZG9jdW1lbnQsIHBsZWFzZSBzZW5kIHRoZXNlPGJyPg0KY29tbWVudHMg YWxvbmcgdG8gdGhlIGxpc3QgaW4geW91ciByZXNwb25zZSB0byB0aGlzIENhbGwgZm9yIEFkb3B0 aW9uLjxicj4NCjxicj4NCkNpYW88YnI+DQpIYW5uZXMgJmFtcDsgRGVyZWs8YnI+DQo8YnI+DQo8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Ck9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiciBjbGVhcj0iYWxsIj4N CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxicj4NClRo b21hcyBCcm95ZXI8YnI+DQovdDxhIGhyZWY9Imh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhi LmplLyIgdGFyZ2V0PSJfYmxhbmsiPsmULm1hLmLKgXdhLmplLzwvYT4gPG86cD4NCjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0 PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439ADF7A6FTK5EX14MBXC293r_-- From nobody Tue Jul 29 17:50:59 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD03C1B2A1F for ; Tue, 29 Jul 2014 17:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 MFAci5CBfvQY for ; Tue, 29 Jul 2014 17:50:53 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6BD1B29FF for ; Tue, 29 Jul 2014 17:50:52 -0700 (PDT) X-AuditID: 1209190e-f79946d000007db1-4f-53d8416b23a4 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id D6.FD.32177.B6148D35; Tue, 29 Jul 2014 20:50:51 -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 s6U0oo0o001922; Tue, 29 Jul 2014 20:50:50 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6U0omFj018407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Jul 2014 20:50:49 -0400 Message-ID: <53D84162.2020406@mit.edu> Date: Tue, 29 Jul 2014 20:50:42 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mike Jones , Thomas Broyer References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------000108060701060109050301" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIKsWRmVeSWpSXmKPExsUixG6nrpvteCPYoHuxpMXeaZ9YLE6+fcVm cfzfRWYHZo+ds+6yeyxZ8pPJo3XHX/YA5igum5TUnMyy1CJ9uwSujNtXzzMVbD/AWPF2/iP2 Bsa+VsYuRk4OCQETiXtH7rFC2GISF+6tZ+ti5OIQEpjNJHHjXyMzhLORUeLWkiVMEM5tJomz Rx+wgbTwCqhJXDx+HWwUi4CqxL/+mywgNhuQPX/lLSYQW1QgSuLOpX5WiHpBiZMzn4DViAhE Svx93cQOYjMLqEv0/l4JVMPBISxQLnH+ChfEruXMEpsXLmMHiXMKJEpsbnUCMZkFwiR2vwyd wCgwC8nQWQgZCNNa4tvuollg4+UlmrfOZoawtSVW9Z5lgolvfzuHeQEj2ypG2ZTcKt3cxMyc 4tRk3eLkxLy81CJdY73czBK91JTSTYygGOCU5NvB+PWg0iFGAQ5GJR7eGf+vBwuxJpYVV+Ye YpTkYFIS5Z2hfyNYiC8pP6UyI7E4I76oNCe1+BCjBAezkgjvVzmgHG9KYmVValE+TEqag0VJ nPettVWwkEB6YklqdmpqQWoRTFaGg0NJglfVAahRsCg1PbUiLTOnBCHNxMEJMpwHaLgSSA1v cUFibnFmOkT+FKMlx5y7x9qYOBaAyXszT7UxCbHk5eelSonzstsDNQiANGSU5sHNhKW0V4zi QC8K8+qCjOUBpkO4qa+AFjIBLXx+6zrIwpJEhJRUA6PygS3X2U2bbZbse1B/4az0g05Tz5Rr d++nH7b5+El0/t+PKxhVO3UPdirEeT1l1XqteOvytIWThf7/THDs1ViU8rfQ4bj+/skHeHIe 3LFRD3aLXyv5xewIo015xMoZbdrXGkUv9Ozr0eeeXl0pJ+3vqxFxRFx7yrPsG3ke0nZNp6at 1RXbt0mJpTgj0VCLuag4EQAyFgpQRAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/e0VoGTn24R1SGeXGfSRYXD0RMGE Cc: "" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 00:50:56 -0000 This is a multi-part message in MIME format. --------------000108060701060109050301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Not true if I revoke the token after it's been issued but before it expires. On 7/29/2014 8:49 PM, Mike Jones wrote: > > Yes, but that's the simplest thing to determine -- try the token and > see whether it works or not. > > *From:*Thomas Broyer [mailto:t.broyer@gmail.com] > *Sent:* Tuesday, July 29, 2014 5:43 PM > *To:* Mike Jones > *Cc:* ; George Fletcher; Phil Hunt > *Subject:* RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth > Token Introspection" as an OAuth Working Group Item > > Decoding a token with a specific format wouldn't tell you whether the > token is still live: it could have been revoked before its expiration. > > Le 30 juil. 2014 02:16, "Mike Jones" > a écrit : > > Did you consider standardizing the access token format within that > deployment so all the parties that needed to could understand it, > rather requiring an extra round trip to an introspection endpoint so > as to be able to understand things about it? > > I realize that might or might not be practical in some cases, but I > haven't heard that alternative discussed, so I thought I'd bring it up. > > I also second Phil's comment that it would be good to understand the > use cases that this is intended to solve before embarking on a > particular solution path. > > -- Mike > > *From:*OAuth [mailto:oauth-bounces@ietf.org > ] *On Behalf Of *George Fletcher > *Sent:* Tuesday, July 29, 2014 3:25 PM > *To:* Phil Hunt; Thomas Broyer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth > Token Introspection" as an OAuth Working Group Item > > We also have a use case where the AS is provided by a partner and the > RS is provided by AOL. Being able to have a standardized way of > validating and getting data about the token from the AS would make our > implementation much simpler as we can use the same mechanism for all > Authorization Servers and not have to implement one off solutions for > each AS. > > Thanks, > George > > On 7/28/14, 8:11 PM, Phil Hunt wrote: > > Could we have some discussion on the interop cases? > > Is it driven by scenarios where AS and resource are separate > domains? Or may this be only of interest to specific protocols > like UMA? > > From a technique principle, the draft is important and sound. I am > just not there yet on the reasons for an interoperable standard. > > Phil > > > On Jul 28, 2014, at 17:00, Thomas Broyer > wrote: > > Yes. This spec is of special interest to the platform we're > building for http://www.oasis-eu.org/ > > On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig > > > wrote: > > Hi all, > > during the IETF #90 OAuth WG meeting, there was strong > consensus in > adopting the "OAuth Token Introspection" > (draft-richer-oauth-introspection-06.txt) specification as an > OAuth WG > work item. > > We would now like to verify the outcome of this call for > adoption on the > OAuth WG mailing list. Here is the link to the document: > http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ > > If you did not hum at the IETF 90 OAuth WG meeting, and have > an opinion > as to the suitability of adopting this document as a WG work item, > please send mail to the OAuth WG list indicating your opinion > (Yes/No). > > The confirmation call for adoption will last until August 10, > 2014. If > you have issues/edits/comments on the document, please send these > comments along to the list in your response to this Call for > Adoption. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Thomas Broyer > /t?.ma.b?wa.je/ > > _______________________________________________ > 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 --------------000108060701060109050301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Not true if I revoke the token after it's been issued but before it expires.

On 7/29/2014 8:49 PM, Mike Jones wrote:

Yes, but that’s the simplest thing to determine – try the token and see whether it works or not.

 

From: Thomas Broyer [mailto:t.broyer@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: <oauth@ietf.org>; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

 

Decoding a token with a specific format wouldn't tell you whether the token is still live: it could have been revoked before its expiration.

Le 30 juil. 2014 02:16, "Mike Jones" <Michael.Jones@microsoft.com> a écrit :

Did you consider standardizing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip to an introspection endpoint so as to be able to understand things about it?

 

I realize that might or might not be practical in some cases, but I haven’t heard that alternative discussed, so I thought I’d bring it up.

 

I also second Phil’s comment that it would be good to understand the use cases that this is intended to solve before embarking on a particular solution path.

 

                                                            -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

 

We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS.

Thanks,
George

On 7/28/14, 8:11 PM, Phil Hunt wrote:

Could we have some discussion on the interop cases?

 

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

 

From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

 

Phil


On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/

 

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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



 

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

_______________________________________________
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

--------------000108060701060109050301-- From nobody Tue Jul 29 17:52:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA27D1B29FF for ; Tue, 29 Jul 2014 17:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Ru2lyK9x-9vD for ; Tue, 29 Jul 2014 17:52:47 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4149A1A0A9A for ; Tue, 29 Jul 2014 17:52:47 -0700 (PDT) X-AuditID: 1209190e-f79946d000007db1-8b-53d841de72ab Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 2E.FD.32177.ED148D35; Tue, 29 Jul 2014 20:52:46 -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 s6U0qiTB002050; Tue, 29 Jul 2014 20:52:44 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6U0qgx4018914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Jul 2014 20:52:43 -0400 Message-ID: <53D841D3.6020505@mit.edu> Date: Tue, 29 Jul 2014 20:52:35 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mike Jones , George Fletcher , Phil Hunt , Thomas Broyer References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------090808090106020405020403" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKKsWRmVeSWpSXmKPExsUixG6nrnvP8UawwbtX7BZ3ulawW+yd9onF 4uTbV2wWC+Y3slsc/3eR2YHV4/7uleweO2fdZfdYsuQnk0frjr/sHh+f3mIJYI3isklJzcks Sy3St0vgyui7aFawZxJjRUv7D9YGxluZXYycHBICJhKbG9ezQ9hiEhfurWfrYuTiEBKYzSRx +8EJVghnI6PE0s65zBDObSaJHRvPsYC08AqoSUy+vZYJxGYRUJV42bMTzGYDsuevvAVmiwpE Sdy51M8KUS8ocXLmExaQQSICKxgl7vRMAxvEDNSwfvVFoAYODmGBconzV7gglvUyScw4/xJs EKdAosT6pxA1zAJhEouXuU1gFJiFZOwshAyEaS3xbXfRLLD58hLb385hhrC1JVb1nmVCFl/A yLaKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11gvN7NELzWldBMjKFY4Jfl2MH49qHSIUYCDUYmH d8b/68FCrIllxZW5hxglOZiURHln6N8IFuJLyk+pzEgszogvKs1JLT7EKMHBrCTC+1UOKMeb klhZlVqUD5OS5mBREud9a20VLCSQnliSmp2aWpBaBJOV4eBQkuBVdQBqFCxKTU+tSMvMKUFI M3FwggznARquBFLDW1yQmFucmQ6RP8VoyTHn7rE2Jo4FYPLezFNtTEIsefl5qVLivO0gDQIg DRmleXAzYanvFaM40IvCvLogVTzAtAk39RXQQiaghc9vXQdZWJKIkJJqYFwtyZ8itfLgOfOP LXsiKo0e2zXNqY9k6xLQS529fJPoL9P+i6GBDaW8e8/9FH3xa9PXPi1J60v7VW1/HXTlX3Di wPIb4kp3tRnj+T4bffrPIHd8Gvc6iX1XZ3+WqvUSC5o7g+3v+gkByz/9ebw6Y+4TvQMp/Vtk LuZxcl+OWLB8z6k3B3+kCtUosRRnJBpqMRcVJwIAY01lkFgDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JjqhM6VOrBAqF2z3okUVMSiWyWE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 00:52:51 -0000 This is a multi-part message in MIME format. --------------090808090106020405020403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reading through this thread, it appears very clear to me that the use cases are very well established by a number of existing implementers who want to work together to build a common standard. I see no reason to delay the work artificially by creating a use case document when such a vast array of understanding and interest already exists. Any use cases and explanations of applications are welcome to be added to the working group draft as it progresses. -- Justin On 7/29/2014 8:16 PM, Mike Jones wrote: > > Did you consider standardizing the access token format within that > deployment so all the parties that needed to could understand it, > rather requiring an extra round trip to an introspection endpoint so > as to be able to understand things about it? > > I realize that might or might not be practical in some cases, but I > haven't heard that alternative discussed, so I thought I'd bring it up. > > I also second Phil's comment that it would be good to understand the > use cases that this is intended to solve before embarking on a > particular solution path. > > -- Mike > > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George > Fletcher > *Sent:* Tuesday, July 29, 2014 3:25 PM > *To:* Phil Hunt; Thomas Broyer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth > Token Introspection" as an OAuth Working Group Item > > We also have a use case where the AS is provided by a partner and the > RS is provided by AOL. Being able to have a standardized way of > validating and getting data about the token from the AS would make our > implementation much simpler as we can use the same mechanism for all > Authorization Servers and not have to implement one off solutions for > each AS. > > Thanks, > George > > On 7/28/14, 8:11 PM, Phil Hunt wrote: > > Could we have some discussion on the interop cases? > > Is it driven by scenarios where AS and resource are separate > domains? Or may this be only of interest to specific protocols > like UMA? > > From a technique principle, the draft is important and sound. I am > just not there yet on the reasons for an interoperable standard. > > Phil > > > On Jul 28, 2014, at 17:00, Thomas Broyer > wrote: > > Yes. This spec is of special interest to the platform we're > building for http://www.oasis-eu.org/ > > On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig > > > wrote: > > Hi all, > > during the IETF #90 OAuth WG meeting, there was strong > consensus in > adopting the "OAuth Token Introspection" > (draft-richer-oauth-introspection-06.txt) specification as an > OAuth WG > work item. > > We would now like to verify the outcome of this call for > adoption on the > OAuth WG mailing list. Here is the link to the document: > http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ > > If you did not hum at the IETF 90 OAuth WG meeting, and have > an opinion > as to the suitability of adopting this document as a WG work item, > please send mail to the OAuth WG list indicating your opinion > (Yes/No). > > The confirmation call for adoption will last until August 10, > 2014. If > you have issues/edits/comments on the document, please send these > comments along to the list in your response to this Call for > Adoption. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Thomas Broyer > /t?.ma.b?wa.je/ > > _______________________________________________ > 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 --------------090808090106020405020403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Reading through this thread, it appears very clear to me that the use cases are very well established by a number of existing implementers who want to work together to build a common standard. I see no reason to delay the work artificially by creating a use case document when such a vast array of understanding and interest already exists. Any use cases and explanations of applications are welcome to be added to the working group draft as it progresses.

 -- Justin


On 7/29/2014 8:16 PM, Mike Jones wrote:

Did you consider standardizing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip to an introspection endpoint so as to be able to understand things about it?

 

I realize that might or might not be practical in some cases, but I haven’t heard that alternative discussed, so I thought I’d bring it up.

 

I also second Phil’s comment that it would be good to understand the use cases that this is intended to solve before embarking on a particular solution path.

 

                                                            -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

 

We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS.

Thanks,
George

On 7/28/14, 8:11 PM, Phil Hunt wrote:

Could we have some discussion on the interop cases?

 

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

 

From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

 

Phil


On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/

 

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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



 

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

_______________________________________________
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

--------------090808090106020405020403-- From nobody Tue Jul 29 17:55:05 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123CF1B2A1F for ; Tue, 29 Jul 2014 17:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 3GUDKQjteZh1 for ; Tue, 29 Jul 2014 17:55:00 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 748621B2A20 for ; Tue, 29 Jul 2014 17:55:00 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6U0su2r014240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jul 2014 00:54:57 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s6U0suJU000375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Jul 2014 00:54:56 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6U0stHt004698; Wed, 30 Jul 2014 00:54:55 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Jul 2014 17:54:54 -0700 References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <53D841D3.6020505@mit.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <53D841D3.6020505@mit.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-6937D7E9-177C-4F36-A32B-0F690BC69F14 Content-Transfer-Encoding: 7bit Message-Id: <311A2204-E968-4657-BD27-58DCD072542A@oracle.com> X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Tue, 29 Jul 2014 17:54:51 -0700 To: Justin Richer X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/bXzikgJU5dCiYAI4BX4AZS6h37o Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 00:55:03 -0000 --Apple-Mail-6937D7E9-177C-4F36-A32B-0F690BC69F14 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable -100 Phil > On Jul 29, 2014, at 17:52, Justin Richer wrote: >=20 > Reading through this thread, it appears very clear to me that the use case= s are very well established by a number of existing implementers who want to= work together to build a common standard. I see no reason to delay the work= artificially by creating a use case document when such a vast array of unde= rstanding and interest already exists. Any use cases and explanations of app= lications are welcome to be added to the working group draft as it progresse= s. >=20 > -- Justin >=20 >=20 >> On 7/29/2014 8:16 PM, Mike Jones wrote: >> Did you consider standardizing the access token format within that deploy= ment so all the parties that needed to could understand it, rather requiring= an extra round trip to an introspection endpoint so as to be able to unders= tand things about it? >> =20 >> I realize that might or might not be practical in some cases, but I haven= =E2=80=99t heard that alternative discussed, so I thought I=E2=80=99d bring i= t up. >> =20 >> I also second Phil=E2=80=99s comment that it would be good to understand t= he use cases that this is intended to solve before embarking on a particular= solution path. >> =20 >> -- Mike >> =20 >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of G= eorge Fletcher >> Sent: Tuesday, July 29, 2014 3:25 PM >> To: Phil Hunt; Thomas Broyer >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token I= ntrospection" as an OAuth Working Group Item >> =20 >> We also have a use case where the AS is provided by a partner and the RS i= s provided by AOL. Being able to have a standardized way of validating and g= etting data about the token from the AS would make our implementation much s= impler as we can use the same mechanism for all Authorization Servers and no= t have to implement one off solutions for each AS. >>=20 >> Thanks, >> George >>=20 >> On 7/28/14, 8:11 PM, Phil Hunt wrote: >> Could we have some discussion on the interop cases? >> =20 >> Is it driven by scenarios where AS and resource are separate domains? Or m= ay this be only of interest to specific protocols like UMA? >> =20 >> =46rom a technique principle, the draft is important and sound. I am just= not there yet on the reasons for an interoperable standard.=20 >> =20 >> Phil >>=20 >> On Jul 28, 2014, at 17:00, Thomas Broyer wrote: >>=20 >> Yes. This spec is of special interest to the platform we're building for h= ttp://www.oasis-eu.org/ >> =20 >>=20 >> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig wrote: >> Hi all, >>=20 >> during the IETF #90 OAuth WG meeting, there was strong consensus in >> adopting the "OAuth Token Introspection" >> (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG >> work item. >>=20 >> We would now like to verify the outcome of this call for adoption on the >> OAuth WG mailing list. Here is the link to the document: >> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>=20 >> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion >> as to the suitability of adopting this document as a WG work item, >> please send mail to the OAuth WG list indicating your opinion (Yes/No). >>=20 >> The confirmation call for adoption will last until August 10, 2014. If >> you have issues/edits/comments on the document, please send these >> comments along to the list in your response to this Call for Adoption. >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> =20 >> --=20 >> Thomas Broyer >> /t=C9=94.ma.b=CA=81wa.je/ >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-6937D7E9-177C-4F36-A32B-0F690BC69F14 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
-100

Phil

On Jul 2= 9, 2014, at 17:52, Justin Richer <jric= her@mit.edu> wrote:

=20 =20 =20
Reading through this thread, it appears very clear to me that the use cases are very well established by a number of existing implementers who want to work together to build a common standard. I see no reason to delay the work artificially by creating a use case document when such a vast array of understanding and interest already exists. Any use cases and explanations of applications are welcome to be added to the working group draft as it progresses.

 -- Justin


On 7/29/2014 8:16 PM, Mike Jones wrote:

Did you consider standardizing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip to an introspection endpoint so as to be able to understand things about it?

 

I realize that might or might not be practical in some cases, but I haven=E2=80=99t heard that alternative discussed, so I tho= ught I=E2=80=99d bring it up.

 

I also second Phil=E2=80=99s comment that it would be good to understand the use cases that this is intended to solve before embarking on a particular solution path.

 

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

 

We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS.

Thanks,
George

On 7/28/14, 8:11 PM, Phil Hunt wrote:<= /o:p>

Could we have some discussion on the interop cases?

 

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

 

=46rom a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

 

Phil


On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org= /

&= nbsp;

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.n= et> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://data= tracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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



 

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

_______________________________________= ________
OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
          
OAuth mailing list

          
OA=
uth@ietf.org

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

 



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

=20
= --Apple-Mail-6937D7E9-177C-4F36-A32B-0F690BC69F14-- From nobody Tue Jul 29 17:55:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A53F1B2A1F for ; Tue, 29 Jul 2014 17:55: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 UZvaNRdwnHlk for ; Tue, 29 Jul 2014 17:55:23 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4861B2A34 for ; Tue, 29 Jul 2014 17:55:22 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id hz20so344697lab.13 for ; Tue, 29 Jul 2014 17:55:20 -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=8J0BfPjkTYba4BosVWFL1BttnqTfE9p3fnaCWjj9B4g=; b=hCohnMpATJvqqRKupn7/bRhm42lsqN2VMNUgcsw11JyEWSu4HS7IZiZRy68oL4Tuzo yCQ1ce2fZpCB0RjIHDbMS1BsCfLY70Uw+kQ20gJVLRndc8iSVgJkS0JoIVGh/J1cP+Lm ZkFcSEBLuyU5N2cfENhT+U5WKYNOrr9/lcTGALcDluBoSUz81RT8QQY5C3HFdyc61tKZ FqiRicYGCy39R7gq1IPANanvoOGkZN73dtwpOz1OFr/swKgLx0Eebt+gtlL6Q9ipEDEF l4LBtDx3Z6FmouVZ/YH4XuHO3OBo8n0aaNA9z1JrX/tUYQvJbQmln4+NUSqjeqPABvz6 8SXg== MIME-Version: 1.0 X-Received: by 10.152.30.100 with SMTP id r4mr444633lah.87.1406681720840; Tue, 29 Jul 2014 17:55:20 -0700 (PDT) Received: by 10.152.113.73 with HTTP; Tue, 29 Jul 2014 17:55:20 -0700 (PDT) Received: by 10.152.113.73 with HTTP; Tue, 29 Jul 2014 17:55:20 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> Date: Wed, 30 Jul 2014 02:55:20 +0200 Message-ID: From: Thomas Broyer To: Mike Jones Content-Type: multipart/alternative; boundary=089e0158cba0486b2904ff5e9cda Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_TYarvzE5Sb0B2wo5b_M2hUy-hQ Cc: "" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 00:55:25 -0000 --089e0158cba0486b2904ff5e9cda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Try it where? When you're the RS trying to determine whether you should accept the token or reject it? Le 30 juil. 2014 02:49, "Mike Jones" a =C3=A9= crit : > Yes, but that=E2=80=99s the simplest thing to determine =E2=80=93 try th= e token and see > whether it works or not. > > > > *From:* Thomas Broyer [mailto:t.broyer@gmail.com] > *Sent:* Tuesday, July 29, 2014 5:43 PM > *To:* Mike Jones > *Cc:* ; George Fletcher; Phil Hunt > *Subject:* RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token > Introspection" as an OAuth Working Group Item > > > > Decoding a token with a specific format wouldn't tell you whether the > token is still live: it could have been revoked before its expiration. > > Le 30 juil. 2014 02:16, "Mike Jones" a > =C3=A9crit : > > Did you consider standardizing the access token format within that > deployment so all the parties that needed to could understand it, rather > requiring an extra round trip to an introspection endpoint so as to be ab= le > to understand things about it? > > > > I realize that might or might not be practical in some cases, but I > haven=E2=80=99t heard that alternative discussed, so I thought I=E2=80=99= d bring it up. > > > > I also second Phil=E2=80=99s comment that it would be good to understand = the use > cases that this is intended to solve before embarking on a particular > solution path. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George > Fletcher > *Sent:* Tuesday, July 29, 2014 3:25 PM > *To:* Phil Hunt; Thomas Broyer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token > Introspection" as an OAuth Working Group Item > > > > We also have a use case where the AS is provided by a partner and the RS > is provided by AOL. Being able to have a standardized way of validating a= nd > getting data about the token from the AS would make our implementation mu= ch > simpler as we can use the same mechanism for all Authorization Servers an= d > not have to implement one off solutions for each AS. > > Thanks, > George > > On 7/28/14, 8:11 PM, Phil Hunt wrote: > > Could we have some discussion on the interop cases? > > > > Is it driven by scenarios where AS and resource are separate domains? Or > may this be only of interest to specific protocols like UMA? > > > > From a technique principle, the draft is important and sound. I am just > not there yet on the reasons for an interoperable standard. > > > > Phil > > > On Jul 28, 2014, at 17:00, Thomas Broyer wrote: > > Yes. This spec is of special interest to the platform we're building for > http://www.oasis-eu.org/ > > > > On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > > Hi all, > > during the IETF #90 OAuth WG meeting, there was strong consensus in > adopting the "OAuth Token Introspection" > (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG > work item. > > We would now like to verify the outcome of this call for adoption on the > OAuth WG mailing list. Here is the link to the document: > http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ > > If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion > as to the suitability of adopting this document as a WG work item, > please send mail to the OAuth WG list indicating your opinion (Yes/No). > > The confirmation call for adoption will last until August 10, 2014. If > you have issues/edits/comments on the document, please send these > comments along to the list in your response to this Call for Adoption. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > > _______________________________________________ > 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 > > > --089e0158cba0486b2904ff5e9cda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Try it where? When you're the RS trying to determine whe= ther you should accept the token or reject it?

Le 30 juil. 2014 02:49, "Mike Jones" &= lt;Michael.Jones@microsoft.c= om> a =C3=A9crit :

Yes, but that=E2=80=99s t= he simplest thing to determine =E2=80=93 try the token and see whether it w= orks or not.

=C2=A0

From: Thomas B= royer [mailto:t.bro= yer@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: <oauth@ie= tf.org>; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAu= th Token Introspection" as an OAuth Working Group Item

=C2=A0

Decoding a token with a specific format wouldn't tell you whether th= e token is still live: it could have been revoked before its expiration.=

Le 30 juil. 2014 02:16, "Mike Jones" <<= a href=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jon= es@microsoft.com> a =C3=A9crit :

Did you consider standard= izing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip t= o an introspection endpoint so as to be able to understand things about it?=

=C2=A0

I realize that might or m= ight not be practical in some cases, but I haven=E2=80=99t heard that alter= native discussed, so I thought I=E2=80=99d bring it up.

=C2=A0

I also second Phil=E2=80= =99s comment that it would be good to understand the use cases that this is= intended to solve before embarking on a particular solution path.<= /u>

=C2=A0

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

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAu= th Token Introspection" as an OAuth Working Group Item

=C2=A0

We also have a use case= where the AS is provided by a partner and the RS is provided by AOL. Being= able to have a standardized way of validating and getting data about the token from the AS would make our imp= lementation much simpler as we can use the same mechanism for all Authoriza= tion Servers and not have to implement one off solutions for each AS.

Thanks,
George

On 7/28/14, 8:11 PM, Phil Hunt wrote:<= /p>

Could we have some discussion on the interop cases?<= u>

=C2=A0

Is it driven by scenarios where AS and resource are = separate domains? Or may this be only of interest to specific protocols lik= e UMA?

=C2=A0

From a technique principle, the draft is important a= nd sound. I am just not there yet on the reasons for an interoperable stand= ard.=C2=A0

=C2=A0

Phil


On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platfor= m we're building for=C2=A0http://www.oasis-eu.org/

=C2=A0<= /p>

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig &= lt;hannes.ts= chofenig@gmx.net> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-int= rospection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014. =C2=A0I= f
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma= .b=CA=81wa.je/

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



_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

--089e0158cba0486b2904ff5e9cda-- From nobody Tue Jul 29 18:02:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186121B28F8 for ; Tue, 29 Jul 2014 18:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 j-ZabRBjyFNh for ; Tue, 29 Jul 2014 18:02:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68F71A03A2 for ; Tue, 29 Jul 2014 18:02:52 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6U12mWX016918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jul 2014 01:02:49 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6U12lQB019281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2014 01:02:48 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6U12llL015787; Wed, 30 Jul 2014 01:02:47 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Jul 2014 18:02:47 -0700 References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-109E425F-4701-4F87-8CE5-3F3494013158 Content-Transfer-Encoding: 7bit Message-Id: <5C8461F3-CD04-4F5E-9BDF-6E91336D5F50@oracle.com> X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Tue, 29 Jul 2014 18:02:44 -0700 To: Thomas Broyer X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/BXOKpIveEr2suI_pU1Sj_RZqRFI Cc: "" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 01:02:55 -0000 --Apple-Mail-109E425F-4701-4F87-8CE5-3F3494013158 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think one alternative to an introspection service is a revocation status s= ervice.=20 But it is often not needed if token lifetimes are small (minutes / session l= ife) compared to the refresh token which might last much longer.=20 Again having info on the case helps explain the requirements of your case an= d we can tell what the best pattern is.=20 Phil > On Jul 29, 2014, at 17:55, Thomas Broyer wrote: >=20 > Try it where? When you're the RS trying to determine whether you should ac= cept the token or reject it? >=20 > Le 30 juil. 2014 02:49, "Mike Jones" a =C3=A9= crit : >> Yes, but that=E2=80=99s the simplest thing to determine =E2=80=93 try the= token and see whether it works or not. >>=20 >> =20 >>=20 >> From: Thomas Broyer [mailto:t.broyer@gmail.com]=20 >> Sent: Tuesday, July 29, 2014 5:43 PM >> To: Mike Jones >> Cc: ; George Fletcher; Phil Hunt >> Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token I= ntrospection" as an OAuth Working Group Item >>=20 >> =20 >>=20 >> Decoding a token with a specific format wouldn't tell you whether the tok= en is still live: it could have been revoked before its expiration. >>=20 >> Le 30 juil. 2014 02:16, "Mike Jones" a =C3=A9= crit : >>=20 >> Did you consider standardizing the access token format within that deploy= ment so all the parties that needed to could understand it, rather requiring= an extra round trip to an introspection endpoint so as to be able to unders= tand things about it? >>=20 >> =20 >>=20 >> I realize that might or might not be practical in some cases, but I haven= =E2=80=99t heard that alternative discussed, so I thought I=E2=80=99d bring i= t up. >>=20 >> =20 >>=20 >> I also second Phil=E2=80=99s comment that it would be good to understand t= he use cases that this is intended to solve before embarking on a particular= solution path. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher >> Sent: Tuesday, July 29, 2014 3:25 PM >> To: Phil Hunt; Thomas Broyer >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token I= ntrospection" as an OAuth Working Group Item >>=20 >> =20 >>=20 >> We also have a use case where the AS is provided by a partner and the RS i= s provided by AOL. Being able to have a standardized way of validating and g= etting data about the token from the AS would make our implementation much s= impler as we can use the same mechanism for all Authorization Servers and no= t have to implement one off solutions for each AS. >>=20 >> Thanks, >> George >>=20 >> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>=20 >> Could we have some discussion on the interop cases? >>=20 >> =20 >>=20 >> Is it driven by scenarios where AS and resource are separate domains? Or m= ay this be only of interest to specific protocols like UMA? >>=20 >> =20 >>=20 >> =46rom a technique principle, the draft is important and sound. I am just= not there yet on the reasons for an interoperable standard.=20 >>=20 >> =20 >>=20 >> Phil >>=20 >>=20 >> On Jul 28, 2014, at 17:00, Thomas Broyer wrote: >>=20 >> Yes. This spec is of special interest to the platform we're building for h= ttp://www.oasis-eu.org/ >>=20 >> =20 >>=20 >> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig wrote: >>=20 >> Hi all, >>=20 >> during the IETF #90 OAuth WG meeting, there was strong consensus in >> adopting the "OAuth Token Introspection" >> (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG >> work item. >>=20 >> We would now like to verify the outcome of this call for adoption on the >> OAuth WG mailing list. Here is the link to the document: >> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>=20 >> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion >> as to the suitability of adopting this document as a WG work item, >> please send mail to the OAuth WG list indicating your opinion (Yes/No). >>=20 >> The confirmation call for adoption will last until August 10, 2014. If >> you have issues/edits/comments on the document, please send these >> comments along to the list in your response to this Call for Adoption. >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> =20 >>=20 >> --=20 >> Thomas Broyer >> /t=C9=94.ma.b=CA=81wa.je/ >>=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 --Apple-Mail-109E425F-4701-4F87-8CE5-3F3494013158 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think one alternative to an introspe= ction service is a revocation status service. 

But it is often not needed if token lifetimes are small (minutes / session l= ife) compared to the refresh token which might last much longer. 
=

Again having info on the case helps explain the requirem= ents of your case and we can tell what the best pattern is. 

Phi= l

On Jul 29, 2014, at 17:55, Thomas Broyer <t.broyer@gmail.com> wrote:

Try it where? When you're the RS try= ing to determine whether you should accept the token or reject it?

Le 30 juil. 2014 02:49, "Mike Jones" <Michael.Jones@microsoft.com> a =C3= =A9crit :

Yes, but that=E2=80=99s the= simplest thing to determine =E2=80=93 try the token and see whether it work= s or not.

 =

From: Thomas Broy= er [mailto:t.broyer@= gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: <oauth@iet= f.org>; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Tok= en Introspection" as an OAuth Working Group Item

 

Decoding a token with a specific format wouldn't tell you whether the tok= en is still live: it could have been revoked before its expiration.

Le 30 juil. 2014 02:16, "Mike Jones" <Michael.Jones@microsoft= .com> a =C3=A9crit :

Did you consider standardiz= ing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip to= an introspection endpoint so as to be able to understand things about it?

 =

I realize that might or mig= ht not be practical in some cases, but I haven=E2=80=99t heard that alternat= ive discussed, so I thought I=E2=80=99d bring it up.

 =

I also second Phil=E2=80=99= s comment that it would be good to understand the use cases that this is int= ended to solve before embarking on a particular solution path.

 =

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

 =

From: OAuth [mail= to:oauth-bounces= @ietf.org] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.or= g
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Tok= en Introspection" as an OAuth Working Group Item

 

We also have a use case w= here the AS is provided by a partner and the RS is provided by AOL. Being ab= le to have a standardized way of validating and getting data about the token from the AS would make our impl= ementation much simpler as we can use the same mechanism for all Authorizati= on Servers and not have to implement one off solutions for each AS.

Thanks,
George

On 7/28/14, 8:11 PM, Phil Hunt wrote:

Could we have some discussion on the interop cases?

 

Is it driven by scenarios where AS and resource are s= eparate domains? Or may this be only of interest to specific protocols like U= MA?

 

=46rom a technique principle, the draft is important a= nd sound. I am just not there yet on the reasons for an interoperable standa= rd. 

 

Phil


On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

=

Yes. This spec is of special interest to the platform= we're building for http://www.oasis-eu.org/

 

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig &l= t;hannes.tsch= ofenig@gmx.net> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
= OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-intro= spection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If=
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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



 

--
Thomas Broyer
/t=C9=94.ma.= b=CA=81wa.je/

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



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

 

= --Apple-Mail-109E425F-4701-4F87-8CE5-3F3494013158-- From nobody Tue Jul 29 18:08:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B0F1B2A26 for ; Tue, 29 Jul 2014 18:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 h3jpGYzZQ6C3 for ; Tue, 29 Jul 2014 18:07:50 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E3B1B29F3 for ; Tue, 29 Jul 2014 18:07:49 -0700 (PDT) X-AuditID: 1209190f-f79f86d0000061c8-b1-53d845641af6 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 04.8E.25032.46548D35; Tue, 29 Jul 2014 21:07:48 -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 s6U17lQd003259; Tue, 29 Jul 2014 21:07:47 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6U17jnk022821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Jul 2014 21:07:46 -0400 Message-ID: <53D8455B.1030303@mit.edu> Date: Tue, 29 Jul 2014 21:07:39 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Phil Hunt , Thomas Broyer References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> <5C8461F3-CD04-4F5E-9BDF-6E91336D5F50@oracle.com> In-Reply-To: <5C8461F3-CD04-4F5E-9BDF-6E91336D5F50@oracle.com> Content-Type: multipart/alternative; boundary="------------070501090402090809050402" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKsWRmVeSWpSXmKPExsUixG6nrpvieiPYYO1cSYuTb1+xWSyY38hu cfzfRWYHZo+ds+6yeyxZ8pPJ4+PTWywBzFFcNimpOZllqUX6dglcGWdXPGEvOH6bsWLB1IPs DYw7mhm7GDk5JARMJN7OecQOYYtJXLi3nq2LkYtDSGA2k8THJTPZIZyNjBLdey+wQji3mSSe nt8M1s4roCaxYv42FhCbRUBVYmb7fCYQmw3Inr/yFpgtKhAlcedSPytEvaDEyZlPwOpFBDwk GnYtYwOxmQXUJXp/rwSq4eAQFiiXOH+FCyQsJDCPRaLxszyIzSlgJ9G35RtUeZjE/4UXWScw CsxCMnUWktQsoEnMAtYS33YXQYTlJZq3zmaGsLUlVvWeZYKJb387h3kBI9sqRtmU3Crd3MTM nOLUZN3i5MS8vNQiXRO93MwSvdSU0k2MoDjglOTfwfjtoNIhRgEORiUe3g+MN4KFWBPLiitz DzFKcjApifLO0AcK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuH9KgeU401JrKxKLcqHSUlzsCiJ 8761tgoWEkhPLEnNTk0tSC2CycpwcChJ8G50BmoULEpNT61Iy8wpQUgzcXCCDOcBGv4epIa3 uCAxtzgzHSJ/itGSY87dY21MHAvA5L2Zp9qYhFjy8vNSpcR5s0EaBEAaMkrz4GbC0torRnGg F4V5P4FU8QBTItzUV0ALmYAWPr91HWRhSSJCSqqBUUzU/OpqbQEtlcZ3vRm+/duuuPzvPPq2 SeP12W3b5rgort3J9/5vVMlN4y8FS/045lUHGr8vCJOf/FTcZv1ZhcZjvQ+6rtz2TCyQFwhY +LnTjEX/B2/hoZdKZ+VOdmcudLv798z5ZOcNL9buSTj/hPOwl9yetpjLkd+3T2FZaPzldwqz 0VyJeiWW4oxEQy3mouJEAMTEn9hGAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/liwr77MQsY84iZxDeo_gRbHhY20 Cc: "" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 01:07:59 -0000 This is a multi-part message in MIME format. --------------070501090402090809050402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit So you want a service where the RS can call an HTTP endpoint to see if the token is alive or not? That sounds like an awesome idea! Very useful for a variety of use cases that people have already mentioned on that list. Maybe that service should respond in JSON with, say, { "active": true } if it's still valid. That's a great start, and that should obviously be MTI. But while we're there, we probably want to know what else the token is for, since this service will probably know that, so let's add in the "scope" and "client_id" and whatever other meta-information we have about the token. If this endpoint doesn't have that information? Well then, I guess it can't return it. So we need to make sure to be flexible about that while we define a common core set of semantics. Flexibility like that is very powerful and could be used in a variety of protocols and deployments across domains and vendors. You know, this idea is sounding better and better. In fact, I'll do you one better. I think this is such a fantastic idea that I wrote it all down in RFC format: http://tools.ietf.org/html/draft-richer-oauth-introspection-06 Glad to have you on board, Phil. -- Justin On 7/29/2014 9:02 PM, Phil Hunt wrote: > I think one alternative to an introspection service is a revocation > status service. > > But it is often not needed if token lifetimes are small (minutes / > session life) compared to the refresh token which might last much longer. > > Again having info on the case helps explain the requirements of your > case and we can tell what the best pattern is. > > Phil > > On Jul 29, 2014, at 17:55, Thomas Broyer > wrote: > >> Try it where? When you're the RS trying to determine whether you >> should accept the token or reject it? >> >> Le 30 juil. 2014 02:49, "Mike Jones" > > a écrit : >> >> Yes, but that's the simplest thing to determine -- try the token >> and see whether it works or not. >> >> *From:*Thomas Broyer [mailto:t.broyer@gmail.com >> ] >> *Sent:* Tuesday, July 29, 2014 5:43 PM >> *To:* Mike Jones >> *Cc:* >; George Fletcher; >> Phil Hunt >> *Subject:* RE: [OAUTH-WG] Confirmation: Call for Adoption of >> "OAuth Token Introspection" as an OAuth Working Group Item >> >> Decoding a token with a specific format wouldn't tell you whether >> the token is still live: it could have been revoked before its >> expiration. >> >> Le 30 juil. 2014 02:16, "Mike Jones" > > a écrit : >> >> Did you consider standardizing the access token format within >> that deployment so all the parties that needed to could >> understand it, rather requiring an extra round trip to an >> introspection endpoint so as to be able to understand things >> about it? >> >> I realize that might or might not be practical in some cases, but >> I haven't heard that alternative discussed, so I thought I'd >> bring it up. >> >> I also second Phil's comment that it would be good to understand >> the use cases that this is intended to solve before embarking on >> a particular solution path. >> >> -- Mike >> >> *From:*OAuth [mailto:oauth-bounces@ietf.org >> ] *On Behalf Of *George Fletcher >> *Sent:* Tuesday, July 29, 2014 3:25 PM >> *To:* Phil Hunt; Thomas Broyer >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of >> "OAuth Token Introspection" as an OAuth Working Group Item >> >> We also have a use case where the AS is provided by a partner and >> the RS is provided by AOL. Being able to have a standardized way >> of validating and getting data about the token from the AS would >> make our implementation much simpler as we can use the same >> mechanism for all Authorization Servers and not have to implement >> one off solutions for each AS. >> >> Thanks, >> George >> >> On 7/28/14, 8:11 PM, Phil Hunt wrote: >> >> Could we have some discussion on the interop cases? >> >> Is it driven by scenarios where AS and resource are separate >> domains? Or may this be only of interest to specific >> protocols like UMA? >> >> From a technique principle, the draft is important and sound. >> I am just not there yet on the reasons for an interoperable >> standard. >> >> Phil >> >> >> On Jul 28, 2014, at 17:00, Thomas Broyer > > wrote: >> >> Yes. This spec is of special interest to the platform >> we're building for http://www.oasis-eu.org/ >> >> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >> > > wrote: >> >> Hi all, >> >> during the IETF #90 OAuth WG meeting, there was strong >> consensus in >> adopting the "OAuth Token Introspection" >> (draft-richer-oauth-introspection-06.txt) specification >> as an OAuth WG >> work item. >> >> We would now like to verify the outcome of this call for >> adoption on the >> OAuth WG mailing list. Here is the link to the document: >> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >> >> If you did not hum at the IETF 90 OAuth WG meeting, and >> have an opinion >> as to the suitability of adopting this document as a WG >> work item, >> please send mail to the OAuth WG list indicating your >> opinion (Yes/No). >> >> The confirmation call for adoption will last until August >> 10, 2014. If >> you have issues/edits/comments on the document, please >> send these >> comments along to the list in your response to this Call >> for Adoption. >> >> Ciao >> Hannes & Derek >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> -- >> Thomas Broyer >> /t?.ma.b?wa.je/ >> >> _______________________________________________ >> 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 --------------070501090402090809050402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
So you want a service where the RS can call an HTTP endpoint to see if the token is alive or not? That sounds like an awesome idea! Very useful for a variety of use cases that people have already mentioned on that list. Maybe that service should respond in JSON with, say, { "active": true } if it's still valid. That's a great start, and that should obviously be MTI.

But while we're there, we probably want to know what else the token is for, since this service will probably know that, so let's add in the "scope" and "client_id" and whatever other meta-information we have about the token. If this endpoint doesn't have that information? Well then, I guess it can't return it. So we need to make sure to be flexible about that while we define a common core set of semantics. Flexibility like that is very powerful and could be used in a variety of protocols and deployments across domains and vendors.

You know, this idea is sounding better and better. In fact, I'll do you one better. I think this is such a fantastic idea that I wrote it all down in RFC format:

http://tools.ietf.org/html/draft-richer-oauth-introspection-06

Glad to have you on board, Phil.

 -- Justin

On 7/29/2014 9:02 PM, Phil Hunt wrote:
I think one alternative to an introspection service is a revocation status service. 

But it is often not needed if token lifetimes are small (minutes / session life) compared to the refresh token which might last much longer. 

Again having info on the case helps explain the requirements of your case and we can tell what the best pattern is. 

Phil

On Jul 29, 2014, at 17:55, Thomas Broyer <t.broyer@gmail.com> wrote:

Try it where? When you're the RS trying to determine whether you should accept the token or reject it?

Le 30 juil. 2014 02:49, "Mike Jones" <Michael.Jones@microsoft.com> a écrit :

Yes, but that’s the simplest thing to determine – try the token and see whether it works or not.

 

From: Thomas Broyer [mailto:t.broyer@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: <oauth@ietf.org>; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

 

Decoding a token with a specific format wouldn't tell you whether the token is still live: it could have been revoked before its expiration.

Le 30 juil. 2014 02:16, "Mike Jones" <Michael.Jones@microsoft.com> a écrit :

Did you consider standardizing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip to an introspection endpoint so as to be able to understand things about it?

 

I realize that might or might not be practical in some cases, but I haven’t heard that alternative discussed, so I thought I’d bring it up.

 

I also second Phil’s comment that it would be good to understand the use cases that this is intended to solve before embarking on a particular solution path.

 

                                                            -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

 

We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS.

Thanks,
George

On 7/28/14, 8:11 PM, Phil Hunt wrote:

Could we have some discussion on the interop cases?

 

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

 

From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

 

Phil


On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/

 

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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



 

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

_______________________________________________
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

--------------070501090402090809050402-- From nobody Tue Jul 29 18:17:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8DB1A04F1 for ; Tue, 29 Jul 2014 18:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJSnBIorNDxU for ; Tue, 29 Jul 2014 18:17:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6AE1A03A2 for ; Tue, 29 Jul 2014 18:17:46 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB311.namprd03.prod.outlook.com (10.141.48.26) with Microsoft SMTP Server (TLS) id 15.0.995.11; Wed, 30 Jul 2014 01:17:44 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0995.011; Wed, 30 Jul 2014 01:17:44 +0000 From: Anthony Nadalin To: Justin Richer , Phil Hunt , "Thomas Broyer" Thread-Topic: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item Thread-Index: AQHPqooP8wIKNi1N/E+X2zjP/3sagZu2KzcAgAAC6YCAAXSXAIAAHzgAgAAHVACAAAHegIAAAaoAgAACEQCAAAFfgIAAAXZg Date: Wed, 30 Jul 2014 01:17:42 +0000 Message-ID: <7a0dabb3d5e04ef5b2528da42fea9f7b@BLUPR03MB309.namprd03.prod.outlook.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> <5C8461F3-CD04-4F5E-9BDF-6E91336D5F50@oracle.com> <53D8455B.1030303@mit.edu> In-Reply-To: <53D8455B.1030303@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.126.7] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(479174003)(24454002)(164054003)(377454003)(189002)(199002)(53754006)(54356999)(79102001)(74502001)(106116001)(105586002)(2171001)(95666004)(106356001)(76176999)(15202345003)(31966008)(92566001)(85306003)(83072002)(87936001)(85852003)(86612001)(99286002)(19300405004)(76482001)(15975445006)(561944003)(99396002)(50986999)(2656002)(107046002)(19580405001)(4396001)(93886003)(81542001)(21056001)(66066001)(86362001)(80022001)(33646002)(16236675004)(101416001)(19625215002)(77982001)(46102001)(76576001)(19580395003)(20776003)(81342001)(64706001)(74316001)(83322001)(19617315012)(108616002)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB311; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_7a0dabb3d5e04ef5b2528da42fea9f7bBLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/12ikOAYzc7-QCjG7gUpOLXeTrsw Cc: "" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 01:17:50 -0000 --_000_7a0dabb3d5e04ef5b2528da42fea9f7bBLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB3ZSBuZWVkIG1hbmFnZW1lbnQgQVBJcyBub3cgdG8gbWFuYWdlIHRoZSBuZXcgZW5k cG9pbnQsIGJ1dCBzZXJpb3VzbHkgdGhpcyBpbnRyb3NwZWN0aW9uIHByb3Bvc2FsIGhhcyBwcml2 YWN5IGlzc3VlcywgdG8gYXZvaWQgdGhlc2UgSSB3b3VsZCBlbmNyeXB0IHRoZSB0b2tlbnMgYW5k IHRoZW4gdGhpcyB3b3VsZCBiZSBhIHVzZWxlc3MgZW5kcG9pbnQsIGFsc28gdGhpcyBoYXMgaXNz dWVzIHdpdGggc3ltbWV0cmljIFBPUCB0b2tlbnMsIGJ1dCBtYXliZSB0aGlzIHdhcyBvbmx5IGRl c2lnbmVkIHRvIHdvcmsgb24gYmVhcmVyIHRva2Vucy4NCg0KDQoNCkZyb206IE9BdXRoIFttYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBSaWNoZXINClNl bnQ6IFR1ZXNkYXksIEp1bHkgMjksIDIwMTQgNjowOCBQTQ0KVG86IFBoaWwgSHVudDsgVGhvbWFz IEJyb3llcg0KQ2M6IDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENv bmZpcm1hdGlvbjogQ2FsbCBmb3IgQWRvcHRpb24gb2YgIk9BdXRoIFRva2VuIEludHJvc3BlY3Rp b24iIGFzIGFuIE9BdXRoIFdvcmtpbmcgR3JvdXAgSXRlbQ0KDQpTbyB5b3Ugd2FudCBhIHNlcnZp Y2Ugd2hlcmUgdGhlIFJTIGNhbiBjYWxsIGFuIEhUVFAgZW5kcG9pbnQgdG8gc2VlIGlmIHRoZSB0 b2tlbiBpcyBhbGl2ZSBvciBub3Q/IFRoYXQgc291bmRzIGxpa2UgYW4gYXdlc29tZSBpZGVhISBW ZXJ5IHVzZWZ1bCBmb3IgYSB2YXJpZXR5IG9mIHVzZSBjYXNlcyB0aGF0IHBlb3BsZSBoYXZlIGFs cmVhZHkgbWVudGlvbmVkIG9uIHRoYXQgbGlzdC4gTWF5YmUgdGhhdCBzZXJ2aWNlIHNob3VsZCBy ZXNwb25kIGluIEpTT04gd2l0aCwgc2F5LCB7ICJhY3RpdmUiOiB0cnVlIH0gaWYgaXQncyBzdGls bCB2YWxpZC4gVGhhdCdzIGEgZ3JlYXQgc3RhcnQsIGFuZCB0aGF0IHNob3VsZCBvYnZpb3VzbHkg YmUgTVRJLg0KDQpCdXQgd2hpbGUgd2UncmUgdGhlcmUsIHdlIHByb2JhYmx5IHdhbnQgdG8ga25v dyB3aGF0IGVsc2UgdGhlIHRva2VuIGlzIGZvciwgc2luY2UgdGhpcyBzZXJ2aWNlIHdpbGwgcHJv YmFibHkga25vdyB0aGF0LCBzbyBsZXQncyBhZGQgaW4gdGhlICJzY29wZSIgYW5kICJjbGllbnRf aWQiIGFuZCB3aGF0ZXZlciBvdGhlciBtZXRhLWluZm9ybWF0aW9uIHdlIGhhdmUgYWJvdXQgdGhl IHRva2VuLiBJZiB0aGlzIGVuZHBvaW50IGRvZXNuJ3QgaGF2ZSB0aGF0IGluZm9ybWF0aW9uPyBX ZWxsIHRoZW4sIEkgZ3Vlc3MgaXQgY2FuJ3QgcmV0dXJuIGl0LiBTbyB3ZSBuZWVkIHRvIG1ha2Ug c3VyZSB0byBiZSBmbGV4aWJsZSBhYm91dCB0aGF0IHdoaWxlIHdlIGRlZmluZSBhIGNvbW1vbiBj b3JlIHNldCBvZiBzZW1hbnRpY3MuIEZsZXhpYmlsaXR5IGxpa2UgdGhhdCBpcyB2ZXJ5IHBvd2Vy ZnVsIGFuZCBjb3VsZCBiZSB1c2VkIGluIGEgdmFyaWV0eSBvZiBwcm90b2NvbHMgYW5kIGRlcGxv eW1lbnRzIGFjcm9zcyBkb21haW5zIGFuZCB2ZW5kb3JzLg0KDQpZb3Uga25vdywgdGhpcyBpZGVh IGlzIHNvdW5kaW5nIGJldHRlciBhbmQgYmV0dGVyLiBJbiBmYWN0LCBJJ2xsIGRvIHlvdSBvbmUg YmV0dGVyLiBJIHRoaW5rIHRoaXMgaXMgc3VjaCBhIGZhbnRhc3RpYyBpZGVhIHRoYXQgSSB3cm90 ZSBpdCBhbGwgZG93biBpbiBSRkMgZm9ybWF0Og0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVjdGlvbi0wNg0KDQpHbGFkIHRvIGhhdmUgeW91 IG9uIGJvYXJkLCBQaGlsLg0KDQogLS0gSnVzdGluDQoNCk9uIDcvMjkvMjAxNCA5OjAyIFBNLCBQ aGlsIEh1bnQgd3JvdGU6DQpJIHRoaW5rIG9uZSBhbHRlcm5hdGl2ZSB0byBhbiBpbnRyb3NwZWN0 aW9uIHNlcnZpY2UgaXMgYSByZXZvY2F0aW9uIHN0YXR1cyBzZXJ2aWNlLg0KDQpCdXQgaXQgaXMg b2Z0ZW4gbm90IG5lZWRlZCBpZiB0b2tlbiBsaWZldGltZXMgYXJlIHNtYWxsIChtaW51dGVzIC8g c2Vzc2lvbiBsaWZlKSBjb21wYXJlZCB0byB0aGUgcmVmcmVzaCB0b2tlbiB3aGljaCBtaWdodCBs YXN0IG11Y2ggbG9uZ2VyLg0KDQpBZ2FpbiBoYXZpbmcgaW5mbyBvbiB0aGUgY2FzZSBoZWxwcyBl eHBsYWluIHRoZSByZXF1aXJlbWVudHMgb2YgeW91ciBjYXNlIGFuZCB3ZSBjYW4gdGVsbCB3aGF0 IHRoZSBiZXN0IHBhdHRlcm4gaXMuDQoNClBoaWwNCg0KT24gSnVsIDI5LCAyMDE0LCBhdCAxNzo1 NSwgVGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPG1haWx0bzp0LmJyb3llckBnbWFp bC5jb20+PiB3cm90ZToNCg0KVHJ5IGl0IHdoZXJlPyBXaGVuIHlvdSdyZSB0aGUgUlMgdHJ5aW5n IHRvIGRldGVybWluZSB3aGV0aGVyIHlvdSBzaG91bGQgYWNjZXB0IHRoZSB0b2tlbiBvciByZWpl Y3QgaXQ/DQpMZSAzMCBqdWlsLiAyMDE0IDAyOjQ5LCAiTWlrZSBKb25lcyIgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gYSDD qWNyaXQgOg0KWWVzLCBidXQgdGhhdOKAmXMgdGhlIHNpbXBsZXN0IHRoaW5nIHRvIGRldGVybWlu ZSDigJMgdHJ5IHRoZSB0b2tlbiBhbmQgc2VlIHdoZXRoZXIgaXQgd29ya3Mgb3Igbm90Lg0KDQpG cm9tOiBUaG9tYXMgQnJveWVyIFttYWlsdG86dC5icm95ZXJAZ21haWwuY29tPG1haWx0bzp0LmJy b3llckBnbWFpbC5jb20+XQ0KU2VudDogVHVlc2RheSwgSnVseSAyOSwgMjAxNCA1OjQzIFBNDQpU bzogTWlrZSBKb25lcw0KQ2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ PjsgR2VvcmdlIEZsZXRjaGVyOyBQaGlsIEh1bnQNClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIENv bmZpcm1hdGlvbjogQ2FsbCBmb3IgQWRvcHRpb24gb2YgIk9BdXRoIFRva2VuIEludHJvc3BlY3Rp b24iIGFzIGFuIE9BdXRoIFdvcmtpbmcgR3JvdXAgSXRlbQ0KDQoNCkRlY29kaW5nIGEgdG9rZW4g d2l0aCBhIHNwZWNpZmljIGZvcm1hdCB3b3VsZG4ndCB0ZWxsIHlvdSB3aGV0aGVyIHRoZSB0b2tl biBpcyBzdGlsbCBsaXZlOiBpdCBjb3VsZCBoYXZlIGJlZW4gcmV2b2tlZCBiZWZvcmUgaXRzIGV4 cGlyYXRpb24uDQpMZSAzMCBqdWlsLiAyMDE0IDAyOjE2LCAiTWlrZSBKb25lcyIgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4g YSDDqWNyaXQgOg0KRGlkIHlvdSBjb25zaWRlciBzdGFuZGFyZGl6aW5nIHRoZSBhY2Nlc3MgdG9r ZW4gZm9ybWF0IHdpdGhpbiB0aGF0IGRlcGxveW1lbnQgc28gYWxsIHRoZSBwYXJ0aWVzIHRoYXQg bmVlZGVkIHRvIGNvdWxkIHVuZGVyc3RhbmQgaXQsIHJhdGhlciByZXF1aXJpbmcgYW4gZXh0cmEg cm91bmQgdHJpcCB0byBhbiBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IHNvIGFzIHRvIGJlIGFibGUg dG8gdW5kZXJzdGFuZCB0aGluZ3MgYWJvdXQgaXQ/DQoNCkkgcmVhbGl6ZSB0aGF0IG1pZ2h0IG9y IG1pZ2h0IG5vdCBiZSBwcmFjdGljYWwgaW4gc29tZSBjYXNlcywgYnV0IEkgaGF2ZW7igJl0IGhl YXJkIHRoYXQgYWx0ZXJuYXRpdmUgZGlzY3Vzc2VkLCBzbyBJIHRob3VnaHQgSeKAmWQgYnJpbmcg aXQgdXAuDQoNCkkgYWxzbyBzZWNvbmQgUGhpbOKAmXMgY29tbWVudCB0aGF0IGl0IHdvdWxkIGJl IGdvb2QgdG8gdW5kZXJzdGFuZCB0aGUgdXNlIGNhc2VzIHRoYXQgdGhpcyBpcyBpbnRlbmRlZCB0 byBzb2x2ZSBiZWZvcmUgZW1iYXJraW5nIG9uIGEgcGFydGljdWxhciBzb2x1dGlvbiBwYXRoLg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBHZW9yZ2UgRmxl dGNoZXINClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjksIDIwMTQgMzoyNSBQTQ0KVG86IFBoaWwgSHVu dDsgVGhvbWFzIEJyb3llcg0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENvbmZpcm1hdGlvbjogQ2FsbCBmb3IgQWRvcHRp b24gb2YgIk9BdXRoIFRva2VuIEludHJvc3BlY3Rpb24iIGFzIGFuIE9BdXRoIFdvcmtpbmcgR3Jv dXAgSXRlbQ0KDQpXZSBhbHNvIGhhdmUgYSB1c2UgY2FzZSB3aGVyZSB0aGUgQVMgaXMgcHJvdmlk ZWQgYnkgYSBwYXJ0bmVyIGFuZCB0aGUgUlMgaXMgcHJvdmlkZWQgYnkgQU9MLiBCZWluZyBhYmxl IHRvIGhhdmUgYSBzdGFuZGFyZGl6ZWQgd2F5IG9mIHZhbGlkYXRpbmcgYW5kIGdldHRpbmcgZGF0 YSBhYm91dCB0aGUgdG9rZW4gZnJvbSB0aGUgQVMgd291bGQgbWFrZSBvdXIgaW1wbGVtZW50YXRp b24gbXVjaCBzaW1wbGVyIGFzIHdlIGNhbiB1c2UgdGhlIHNhbWUgbWVjaGFuaXNtIGZvciBhbGwg QXV0aG9yaXphdGlvbiBTZXJ2ZXJzIGFuZCBub3QgaGF2ZSB0byBpbXBsZW1lbnQgb25lIG9mZiBz b2x1dGlvbnMgZm9yIGVhY2ggQVMuDQoNClRoYW5rcywNCkdlb3JnZQ0KT24gNy8yOC8xNCwgODox MSBQTSwgUGhpbCBIdW50IHdyb3RlOg0KQ291bGQgd2UgaGF2ZSBzb21lIGRpc2N1c3Npb24gb24g dGhlIGludGVyb3AgY2FzZXM/DQoNCklzIGl0IGRyaXZlbiBieSBzY2VuYXJpb3Mgd2hlcmUgQVMg YW5kIHJlc291cmNlIGFyZSBzZXBhcmF0ZSBkb21haW5zPyBPciBtYXkgdGhpcyBiZSBvbmx5IG9m IGludGVyZXN0IHRvIHNwZWNpZmljIHByb3RvY29scyBsaWtlIFVNQT8NCg0KRnJvbSBhIHRlY2hu aXF1ZSBwcmluY2lwbGUsIHRoZSBkcmFmdCBpcyBpbXBvcnRhbnQgYW5kIHNvdW5kLiBJIGFtIGp1 c3Qgbm90IHRoZXJlIHlldCBvbiB0aGUgcmVhc29ucyBmb3IgYW4gaW50ZXJvcGVyYWJsZSBzdGFu ZGFyZC4NCg0KUGhpbA0KDQpPbiBKdWwgMjgsIDIwMTQsIGF0IDE3OjAwLCBUaG9tYXMgQnJveWVy IDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+IHdyb3RlOg0K WWVzLiBUaGlzIHNwZWMgaXMgb2Ygc3BlY2lhbCBpbnRlcmVzdCB0byB0aGUgcGxhdGZvcm0gd2Un cmUgYnVpbGRpbmcgZm9yIGh0dHA6Ly93d3cub2FzaXMtZXUub3JnLw0KDQpPbiBNb24sIEp1bCAy OCwgMjAxNCBhdCA3OjMzIFBNLCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdA Z214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdyb3RlOg0KSGkgYWxs LA0KDQpkdXJpbmcgdGhlIElFVEYgIzkwIE9BdXRoIFdHIG1lZXRpbmcsIHRoZXJlIHdhcyBzdHJv bmcgY29uc2Vuc3VzIGluDQphZG9wdGluZyB0aGUgIk9BdXRoIFRva2VuIEludHJvc3BlY3Rpb24i DQooZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDYudHh0KSBzcGVjaWZpY2F0aW9u IGFzIGFuIE9BdXRoIFdHDQp3b3JrIGl0ZW0uDQoNCldlIHdvdWxkIG5vdyBsaWtlIHRvIHZlcmlm eSB0aGUgb3V0Y29tZSBvZiB0aGlzIGNhbGwgZm9yIGFkb3B0aW9uIG9uIHRoZQ0KT0F1dGggV0cg bWFpbGluZyBsaXN0LiBIZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBkb2N1bWVudDoNCmh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24v DQoNCklmIHlvdSBkaWQgbm90IGh1bSBhdCB0aGUgSUVURiA5MCBPQXV0aCBXRyBtZWV0aW5nLCBh bmQgaGF2ZSBhbiBvcGluaW9uDQphcyB0byB0aGUgc3VpdGFiaWxpdHkgb2YgYWRvcHRpbmcgdGhp cyBkb2N1bWVudCBhcyBhIFdHIHdvcmsgaXRlbSwNCnBsZWFzZSBzZW5kIG1haWwgdG8gdGhlIE9B dXRoIFdHIGxpc3QgaW5kaWNhdGluZyB5b3VyIG9waW5pb24gKFllcy9ObykuDQoNClRoZSBjb25m aXJtYXRpb24gY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBsYXN0IHVudGlsIEF1Z3VzdCAxMCwgMjAx NC4gIElmDQp5b3UgaGF2ZSBpc3N1ZXMvZWRpdHMvY29tbWVudHMgb24gdGhlIGRvY3VtZW50LCBw bGVhc2Ugc2VuZCB0aGVzZQ0KY29tbWVudHMgYWxvbmcgdG8gdGhlIGxpc3QgaW4geW91ciByZXNw b25zZSB0byB0aGlzIENhbGwgZm9yIEFkb3B0aW9uLg0KDQpDaWFvDQpIYW5uZXMgJiBEZXJlaw0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpUaG9t YXMgQnJveWVyDQovdMmULm1hLmLKgXdhLmplLzxodHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4 Yi5qZS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGlu ZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcg bGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_7a0dabb3d5e04ef5b2528da42fea9f7bBLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNh Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2Ut MToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9t YTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xv cjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCglj b2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB3ZSBuZWVkIG1hbmFnZW1lbnQgQVBJcyBub3cg dG8gbWFuYWdlIHRoZSBuZXcgZW5kcG9pbnQsIGJ1dCBzZXJpb3VzbHkgdGhpcyBpbnRyb3NwZWN0 aW9uIHByb3Bvc2FsIGhhcyBwcml2YWN5IGlzc3VlcywgdG8gYXZvaWQgdGhlc2UgSSB3b3VsZCBl bmNyeXB0DQogdGhlIHRva2VucyBhbmQgdGhlbiB0aGlzIHdvdWxkIGJlIGEgdXNlbGVzcyBlbmRw b2ludCwgYWxzbyB0aGlzIGhhcyBpc3N1ZXMgd2l0aCBzeW1tZXRyaWMgUE9QIHRva2VucywgYnV0 IG1heWJlIHRoaXMgd2FzIG9ubHkgZGVzaWduZWQgdG8gd29yayBvbiBiZWFyZXIgdG9rZW5zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gT0F1dGggW21haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gUmlj aGVyPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMjksIDIwMTQgNjowOCBQTTxicj4N CjxiPlRvOjwvYj4gUGhpbCBIdW50OyBUaG9tYXMgQnJveWVyPGJyPg0KPGI+Q2M6PC9iPiAmbHQ7 b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENv bmZpcm1hdGlvbjogQ2FsbCBmb3IgQWRvcHRpb24gb2YgJnF1b3Q7T0F1dGggVG9rZW4gSW50cm9z cGVjdGlvbiZxdW90OyBhcyBhbiBPQXV0aCBXb3JraW5nIEdyb3VwIEl0ZW08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28geW91IHdhbnQgYSBz ZXJ2aWNlIHdoZXJlIHRoZSBSUyBjYW4gY2FsbCBhbiBIVFRQIGVuZHBvaW50IHRvIHNlZSBpZiB0 aGUgdG9rZW4gaXMgYWxpdmUgb3Igbm90PyBUaGF0IHNvdW5kcyBsaWtlIGFuIGF3ZXNvbWUgaWRl YSEgVmVyeSB1c2VmdWwgZm9yIGEgdmFyaWV0eSBvZiB1c2UgY2FzZXMgdGhhdCBwZW9wbGUgaGF2 ZSBhbHJlYWR5IG1lbnRpb25lZCBvbiB0aGF0IGxpc3QuIE1heWJlIHRoYXQgc2VydmljZQ0KIHNo b3VsZCByZXNwb25kIGluIEpTT04gd2l0aCwgc2F5LCB7ICZxdW90O2FjdGl2ZSZxdW90OzogdHJ1 ZSB9IGlmIGl0J3Mgc3RpbGwgdmFsaWQuIFRoYXQncyBhIGdyZWF0IHN0YXJ0LCBhbmQgdGhhdCBz aG91bGQgb2J2aW91c2x5IGJlIE1USS48YnI+DQo8YnI+DQpCdXQgd2hpbGUgd2UncmUgdGhlcmUs IHdlIHByb2JhYmx5IHdhbnQgdG8ga25vdyB3aGF0IGVsc2UgdGhlIHRva2VuIGlzIGZvciwgc2lu Y2UgdGhpcyBzZXJ2aWNlIHdpbGwgcHJvYmFibHkga25vdyB0aGF0LCBzbyBsZXQncyBhZGQgaW4g dGhlICZxdW90O3Njb3BlJnF1b3Q7IGFuZCAmcXVvdDtjbGllbnRfaWQmcXVvdDsgYW5kIHdoYXRl dmVyIG90aGVyIG1ldGEtaW5mb3JtYXRpb24gd2UgaGF2ZSBhYm91dCB0aGUgdG9rZW4uIElmIHRo aXMgZW5kcG9pbnQgZG9lc24ndCBoYXZlIHRoYXQNCiBpbmZvcm1hdGlvbj8gV2VsbCB0aGVuLCBJ IGd1ZXNzIGl0IGNhbid0IHJldHVybiBpdC4gU28gd2UgbmVlZCB0byBtYWtlIHN1cmUgdG8gYmUg ZmxleGlibGUgYWJvdXQgdGhhdCB3aGlsZSB3ZSBkZWZpbmUgYSBjb21tb24gY29yZSBzZXQgb2Yg c2VtYW50aWNzLiBGbGV4aWJpbGl0eSBsaWtlIHRoYXQgaXMgdmVyeSBwb3dlcmZ1bCBhbmQgY291 bGQgYmUgdXNlZCBpbiBhIHZhcmlldHkgb2YgcHJvdG9jb2xzIGFuZCBkZXBsb3ltZW50cyBhY3Jv c3MNCiBkb21haW5zIGFuZCB2ZW5kb3JzLjxicj4NCjxicj4NCllvdSBrbm93LCB0aGlzIGlkZWEg aXMgc291bmRpbmcgYmV0dGVyIGFuZCBiZXR0ZXIuIEluIGZhY3QsIEknbGwgZG8geW91IG9uZSBi ZXR0ZXIuIEkgdGhpbmsgdGhpcyBpcyBzdWNoIGEgZmFudGFzdGljIGlkZWEgdGhhdCBJIHdyb3Rl IGl0IGFsbCBkb3duIGluIFJGQyBmb3JtYXQ6PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDYiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9u LTA2PC9hPjxicj4NCjxicj4NCkdsYWQgdG8gaGF2ZSB5b3Ugb24gYm9hcmQsIFBoaWwuPGJyPg0K PGJyPg0KJm5ic3A7LS0gSnVzdGluPGJyPg0KPGJyPg0KT24gNy8yOS8yMDE0IDk6MDIgUE0sIFBo aWwgSHVudCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSB0aGluayBvbmUgYWx0ZXJuYXRpdmUgdG8gYW4gaW50cm9zcGVjdGlvbiBz ZXJ2aWNlIGlzIGEgcmV2b2NhdGlvbiBzdGF0dXMgc2VydmljZS4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IGl0IGlzIG9mdGVu IG5vdCBuZWVkZWQgaWYgdG9rZW4gbGlmZXRpbWVzIGFyZSBzbWFsbCAobWludXRlcyAvIHNlc3Np b24gbGlmZSkgY29tcGFyZWQgdG8gdGhlIHJlZnJlc2ggdG9rZW4gd2hpY2ggbWlnaHQgbGFzdCBt dWNoIGxvbmdlci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWdhaW4gaGF2aW5nIGluZm8gb24gdGhlIGNhc2UgaGVscHMgZXhwbGFp biB0aGUgcmVxdWlyZW1lbnRzIG9mIHlvdXIgY2FzZSBhbmQgd2UgY2FuIHRlbGwgd2hhdCB0aGUg YmVzdCBwYXR0ZXJuIGlzLiZuYnNwOzxicj4NCjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KT24gSnVsIDI5LCAyMDE0LCBhdCAxNzo1NSwgVGhvbWFzIEJyb3llciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSI+dC5icm95ZXJAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwPlRyeSBpdCB3 aGVyZT8gV2hlbiB5b3UncmUgdGhlIFJTIHRyeWluZyB0byBkZXRlcm1pbmUgd2hldGhlciB5b3Ug c2hvdWxkIGFjY2VwdCB0aGUgdG9rZW4gb3IgcmVqZWN0IGl0PzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxlIDMwIGp1aWwuIDIwMTQgMDI6NDksICZxdW90O01p a2UgSm9uZXMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IGEgw6ljcml0IDo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgYnV0 IHRoYXTigJlzIHRoZSBzaW1wbGVzdCB0aGluZyB0byBkZXRlcm1pbmUg4oCTIHRyeSB0aGUgdG9r ZW4gYW5kIHNlZSB3aGV0aGVyIGl0IHdvcmtzIG9yIG5vdC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUaG9tYXMgQnJveWVyIFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnQuYnJveWVyQGdtYWls LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyOSwgMjAxNCA1OjQz IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8 L2E+Jmd0OzsgR2VvcmdlIEZsZXRjaGVyOyBQaGlsIEh1bnQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UkU6IFtPQVVUSC1XR10gQ29uZmlybWF0aW9uOiBDYWxsIGZvciBBZG9wdGlvbiBvZiAmcXVvdDtP QXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uJnF1b3Q7IGFzIGFuIE9BdXRoIFdvcmtpbmcgR3JvdXAg SXRlbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cD5EZWNvZGluZyBhIHRva2VuIHdpdGggYSBzcGVjaWZpYyBmb3Jt YXQgd291bGRuJ3QgdGVsbCB5b3Ugd2hldGhlciB0aGUgdG9rZW4gaXMgc3RpbGwgbGl2ZTogaXQg Y291bGQgaGF2ZSBiZWVuIHJldm9rZWQgYmVmb3JlIGl0cyBleHBpcmF0aW9uLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TGUgMzAganVpbC4gMjAxNCAwMjox NiwgJnF1b3Q7TWlrZSBKb25lcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7IGEgw6ljcml0IDo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+RGlkIHlvdSBjb25zaWRlciBzdGFuZGFyZGl6aW5nIHRoZSBhY2Nlc3MgdG9rZW4gZm9y bWF0IHdpdGhpbiB0aGF0IGRlcGxveW1lbnQgc28gYWxsIHRoZSBwYXJ0aWVzDQogdGhhdCBuZWVk ZWQgdG8gY291bGQgdW5kZXJzdGFuZCBpdCwgcmF0aGVyIHJlcXVpcmluZyBhbiBleHRyYSByb3Vu ZCB0cmlwIHRvIGFuIGludHJvc3BlY3Rpb24gZW5kcG9pbnQgc28gYXMgdG8gYmUgYWJsZSB0byB1 bmRlcnN0YW5kIHRoaW5ncyBhYm91dCBpdD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHJlYWxpemUgdGhhdCBt aWdodCBvciBtaWdodCBub3QgYmUgcHJhY3RpY2FsIGluIHNvbWUgY2FzZXMsIGJ1dCBJIGhhdmVu 4oCZdCBoZWFyZCB0aGF0IGFsdGVybmF0aXZlDQogZGlzY3Vzc2VkLCBzbyBJIHRob3VnaHQgSeKA mWQgYnJpbmcgaXQgdXAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbHNvIHNlY29uZCBQaGls4oCZcyBjb21t ZW50IHRoYXQgaXQgd291bGQgYmUgZ29vZCB0byB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZXMgdGhh dCB0aGlzIGlzIGludGVuZGVkDQogdG8gc29sdmUgYmVmb3JlIGVtYmFya2luZyBvbiBhIHBhcnRp Y3VsYXIgc29sdXRpb24gcGF0aC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9y ZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdlb3JnZSBGbGV0Y2hlcjxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0IDM6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IFBoaWwg SHVudDsgVGhvbWFzIEJyb3llcjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENvbmZpcm1hdGlvbjogQ2FsbCBmb3IgQWRvcHRpb24g b2YgJnF1b3Q7T0F1dGggVG9rZW4gSW50cm9zcGVjdGlvbiZxdW90OyBhcyBhbiBPQXV0aCBXb3Jr aW5nIEdyb3VwIEl0ZW08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5XZSBhbHNvIGhhdmUgYSB1c2UgY2FzZSB3aGVyZSB0aGUgQVMgaXMg cHJvdmlkZWQgYnkgYSBwYXJ0bmVyIGFuZCB0aGUgUlMgaXMgcHJvdmlkZWQgYnkgQU9MLiBCZWlu ZyBhYmxlIHRvIGhhdmUgYSBzdGFuZGFyZGl6ZWQgd2F5IG9mDQogdmFsaWRhdGluZyBhbmQgZ2V0 dGluZyBkYXRhIGFib3V0IHRoZSB0b2tlbiBmcm9tIHRoZSBBUyB3b3VsZCBtYWtlIG91ciBpbXBs ZW1lbnRhdGlvbiBtdWNoIHNpbXBsZXIgYXMgd2UgY2FuIHVzZSB0aGUgc2FtZSBtZWNoYW5pc20g Zm9yIGFsbCBBdXRob3JpemF0aW9uIFNlcnZlcnMgYW5kIG5vdCBoYXZlIHRvIGltcGxlbWVudCBv bmUgb2ZmIHNvbHV0aW9ucyBmb3IgZWFjaCBBUy48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KR2Vv cmdlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ T24gNy8yOC8xNCwgODoxMSBQTSwgUGhpbCBIdW50IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvdWxkIHdlIGhhdmUgc29tZSBk aXNjdXNzaW9uIG9uIHRoZSBpbnRlcm9wIGNhc2VzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXMgaXQgZHJpdmVuIGJ5IHNjZW5hcmlv cyB3aGVyZSBBUyBhbmQgcmVzb3VyY2UgYXJlIHNlcGFyYXRlIGRvbWFpbnM/IE9yIG1heSB0aGlz IGJlIG9ubHkgb2YgaW50ZXJlc3QgdG8gc3BlY2lmaWMgcHJvdG9jb2xzIGxpa2UgVU1BPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RnJv bSBhIHRlY2huaXF1ZSBwcmluY2lwbGUsIHRoZSBkcmFmdCBpcyBpbXBvcnRhbnQgYW5kIHNvdW5k LiBJIGFtIGp1c3Qgbm90IHRoZXJlIHlldCBvbiB0aGUgcmVhc29ucyBmb3IgYW4gaW50ZXJvcGVy YWJsZSBzdGFuZGFyZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVsIDI4LCAyMDE0LCBhdCAxNzowMCwgVGhvbWFz IEJyb3llciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnQuYnJveWVyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMuIFRoaXMg c3BlYyBpcyBvZiBzcGVjaWFsIGludGVyZXN0IHRvIHRoZSBwbGF0Zm9ybSB3ZSdyZSBidWlsZGlu ZyBmb3ImbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3Lm9hc2lzLWV1Lm9yZy8iIHRhcmdldD0iX2Js YW5rIj5odHRwOi8vd3d3Lm9hc2lzLWV1Lm9yZy88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBKdWwgMjgsIDIwMTQgYXQgNzozMyBQTSwgSGFu bmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgu bmV0IiB0YXJnZXQ9Il9ibGFuayI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBhbGwsPGJyPg0KPGJyPg0K ZHVyaW5nIHRoZSBJRVRGICM5MCBPQXV0aCBXRyBtZWV0aW5nLCB0aGVyZSB3YXMgc3Ryb25nIGNv bnNlbnN1cyBpbjxicj4NCmFkb3B0aW5nIHRoZSAmcXVvdDtPQXV0aCBUb2tlbiBJbnRyb3NwZWN0 aW9uJnF1b3Q7PGJyPg0KKGRyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLTA2LnR4dCkg c3BlY2lmaWNhdGlvbiBhcyBhbiBPQXV0aCBXRzxicj4NCndvcmsgaXRlbS48YnI+DQo8YnI+DQpX ZSB3b3VsZCBub3cgbGlrZSB0byB2ZXJpZnkgdGhlIG91dGNvbWUgb2YgdGhpcyBjYWxsIGZvciBh ZG9wdGlvbiBvbiB0aGU8YnI+DQpPQXV0aCBXRyBtYWlsaW5nIGxpc3QuIEhlcmUgaXMgdGhlIGxp bmsgdG8gdGhlIGRvY3VtZW50Ojxicj4NCjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24vIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yaWNoZXItb2F1dGgtaW50 cm9zcGVjdGlvbi88L2E+PGJyPg0KPGJyPg0KSWYgeW91IGRpZCBub3QgaHVtIGF0IHRoZSBJRVRG IDkwIE9BdXRoIFdHIG1lZXRpbmcsIGFuZCBoYXZlIGFuIG9waW5pb248YnI+DQphcyB0byB0aGUg c3VpdGFiaWxpdHkgb2YgYWRvcHRpbmcgdGhpcyBkb2N1bWVudCBhcyBhIFdHIHdvcmsgaXRlbSw8 YnI+DQpwbGVhc2Ugc2VuZCBtYWlsIHRvIHRoZSBPQXV0aCBXRyBsaXN0IGluZGljYXRpbmcgeW91 ciBvcGluaW9uIChZZXMvTm8pLjxicj4NCjxicj4NClRoZSBjb25maXJtYXRpb24gY2FsbCBmb3Ig YWRvcHRpb24gd2lsbCBsYXN0IHVudGlsIEF1Z3VzdCAxMCwgMjAxNC4gJm5ic3A7SWY8YnI+DQp5 b3UgaGF2ZSBpc3N1ZXMvZWRpdHMvY29tbWVudHMgb24gdGhlIGRvY3VtZW50LCBwbGVhc2Ugc2Vu ZCB0aGVzZTxicj4NCmNvbW1lbnRzIGFsb25nIHRvIHRoZSBsaXN0IGluIHlvdXIgcmVzcG9uc2Ug dG8gdGhpcyBDYWxsIGZvciBBZG9wdGlvbi48YnI+DQo8YnI+DQpDaWFvPGJyPg0KSGFubmVzICZh bXA7IERlcmVrPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPi0tDQo8YnI+DQpUaG9tYXMgQnJveWVyPGJyPg0KL3Q8YSBocmVmPSJodHRwOi8v eG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8iIHRhcmdldD0iX2JsYW5rIj7JlC5tYS5iyoF3YS5q ZS88L2E+IDxvOnA+DQo8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9B dXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpP QXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGll dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_7a0dabb3d5e04ef5b2528da42fea9f7bBLUPR03MB309namprd03pro_-- From nobody Tue Jul 29 18:18:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C651A1B2A35 for ; Tue, 29 Jul 2014 18:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 gIQrdLyaPOnF for ; Tue, 29 Jul 2014 18:17:56 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 871771B2A31 for ; Tue, 29 Jul 2014 18:17:56 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6U1Hrig031875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jul 2014 01:17:54 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6U1Hqjl016516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2014 01:17:53 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6U1HqP2005674; Wed, 30 Jul 2014 01:17:52 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Jul 2014 18:17:52 -0700 References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> <5C8461F3-CD04-4F5E-9BDF-6E91336D5F50@oracle.com> <53D8455B.1030303@mit.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <53D8455B.1030303@mit.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-4299ED13-5ED3-4A95-B09A-32DD67B45094 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Tue, 29 Jul 2014 18:17:49 -0700 To: Justin Richer X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/beSjNSfUlBVTWS1Yq1DFZDftsAQ Cc: "" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 01:17:59 -0000 --Apple-Mail-4299ED13-5ED3-4A95-B09A-32DD67B45094 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mike's proposal may be sufficient for Thomas' case given a small token lifet= ime.=20 The federated cases may have other issues.... How does the RS know who issued the opaque token and what introspection poin= t is authoritative?=20 I am not saying your spec is not the right answer. I am just not prepared to= limit functionality yet by adopting the draft until we have sufficient requ= irements understood.=20 Let the rest of us catch up please.=20 Phil > On Jul 29, 2014, at 18:07, Justin Richer wrote: >=20 > So you want a service where the RS can call an HTTP endpoint to see if the= token is alive or not? That sounds like an awesome idea! Very useful for a v= ariety of use cases that people have already mentioned on that list. Maybe t= hat service should respond in JSON with, say, { "active": true } if it's sti= ll valid. That's a great start, and that should obviously be MTI. >=20 > But while we're there, we probably want to know what else the token is for= , since this service will probably know that, so let's add in the "scope" an= d "client_id" and whatever other meta-information we have about the token. I= f this endpoint doesn't have that information? Well then, I guess it can't r= eturn it. So we need to make sure to be flexible about that while we define a= common core set of semantics. Flexibility like that is very powerful and co= uld be used in a variety of protocols and deployments across domains and ven= dors. >=20 > You know, this idea is sounding better and better. In fact, I'll do you on= e better. I think this is such a fantastic idea that I wrote it all down in R= FC format: >=20 > http://tools.ietf.org/html/draft-richer-oauth-introspection-06 >=20 > Glad to have you on board, Phil. >=20 > -- Justin >=20 >> On 7/29/2014 9:02 PM, Phil Hunt wrote: >> I think one alternative to an introspection service is a revocation statu= s service.=20 >>=20 >> But it is often not needed if token lifetimes are small (minutes / sessio= n life) compared to the refresh token which might last much longer.=20 >>=20 >> Again having info on the case helps explain the requirements of your case= and we can tell what the best pattern is.=20 >>=20 >> Phil >>=20 >> On Jul 29, 2014, at 17:55, Thomas Broyer wrote: >>=20 >>> Try it where? When you're the RS trying to determine whether you should a= ccept the token or reject it? >>>=20 >>> Le 30 juil. 2014 02:49, "Mike Jones" a =C3= =A9crit : >>>> Yes, but that=E2=80=99s the simplest thing to determine =E2=80=93 try t= he token and see whether it works or not. >>>>=20 >>>> =20 >>>>=20 >>>> From: Thomas Broyer [mailto:t.broyer@gmail.com]=20 >>>> Sent: Tuesday, July 29, 2014 5:43 PM >>>> To: Mike Jones >>>> Cc: ; George Fletcher; Phil Hunt >>>> Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token= Introspection" as an OAuth Working Group Item >>>>=20 >>>> =20 >>>>=20 >>>> Decoding a token with a specific format wouldn't tell you whether the t= oken is still live: it could have been revoked before its expiration. >>>>=20 >>>> Le 30 juil. 2014 02:16, "Mike Jones" a =C3= =A9crit : >>>>=20 >>>> Did you consider standardizing the access token format within that depl= oyment so all the parties that needed to could understand it, rather requiri= ng an extra round trip to an introspection endpoint so as to be able to unde= rstand things about it? >>>>=20 >>>> =20 >>>>=20 >>>> I realize that might or might not be practical in some cases, but I hav= en=E2=80=99t heard that alternative discussed, so I thought I=E2=80=99d brin= g it up. >>>>=20 >>>> =20 >>>>=20 >>>> I also second Phil=E2=80=99s comment that it would be good to understan= d the use cases that this is intended to solve before embarking on a particu= lar solution path. >>>>=20 >>>> =20 >>>>=20 >>>> = -- Mike >>>>=20 >>>> =20 >>>>=20 >>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletche= r >>>> Sent: Tuesday, July 29, 2014 3:25 PM >>>> To: Phil Hunt; Thomas Broyer >>>> Cc: oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token= Introspection" as an OAuth Working Group Item >>>>=20 >>>> =20 >>>>=20 >>>> We also have a use case where the AS is provided by a partner and the R= S is provided by AOL. Being able to have a standardized way of validating an= d getting data about the token from the AS would make our implementation muc= h simpler as we can use the same mechanism for all Authorization Servers and= not have to implement one off solutions for each AS. >>>>=20 >>>> Thanks, >>>> George >>>>=20 >>>> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>>>=20 >>>> Could we have some discussion on the interop cases? >>>>=20 >>>> =20 >>>>=20 >>>> Is it driven by scenarios where AS and resource are separate domains? O= r may this be only of interest to specific protocols like UMA? >>>>=20 >>>> =20 >>>>=20 >>>> =46rom a technique principle, the draft is important and sound. I am ju= st not there yet on the reasons for an interoperable standard.=20 >>>>=20 >>>> =20 >>>>=20 >>>> Phil >>>>=20 >>>>=20 >>>> On Jul 28, 2014, at 17:00, Thomas Broyer wrote: >>>>=20 >>>> Yes. This spec is of special interest to the platform we're building fo= r http://www.oasis-eu.org/ >>>>=20 >>>> =20 >>>>=20 >>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> during the IETF #90 OAuth WG meeting, there was strong consensus in >>>> adopting the "OAuth Token Introspection" >>>> (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG >>>> work item. >>>>=20 >>>> We would now like to verify the outcome of this call for adoption on th= e >>>> OAuth WG mailing list. Here is the link to the document: >>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>>=20 >>>> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion= >>>> as to the suitability of adopting this document as a WG work item, >>>> please send mail to the OAuth WG list indicating your opinion (Yes/No).= >>>>=20 >>>> The confirmation call for adoption will last until August 10, 2014. If= >>>> you have issues/edits/comments on the document, please send these >>>> comments along to the list in your response to this Call for Adoption. >>>>=20 >>>> Ciao >>>> Hannes & Derek >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> =20 >>>>=20 >>>> --=20 >>>> Thomas Broyer >>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-4299ED13-5ED3-4A95-B09A-32DD67B45094 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Mike's proposal may be sufficient for T= homas' case given a small token lifetime. 

The= federated cases may have other issues....

How does= the RS know who issued the opaque token and what introspection point is aut= horitative? 

I am not saying your spec is not t= he right answer. I am just not prepared to limit functionality yet by adopti= ng the draft until we have sufficient requirements understood. 

= Let the rest of us catch up please. 

Phil

O= n Jul 29, 2014, at 18:07, Justin Richer <jricher@mit.edu> wrote:

=20 =20 =20
So you want a service where the RS can call an HTTP endpoint to see if the token is alive or not? That sounds like an awesome idea! Very useful for a variety of use cases that people have already mentioned on that list. Maybe that service should respond in JSON with, say, { "active": true } if it's still valid. That's a great start, and that should obviously be MTI.

But while we're there, we probably want to know what else the token is for, since this service will probably know that, so let's add in the "scope" and "client_id" and whatever other meta-information we have about the token. If this endpoint doesn't have that information? Well then, I guess it can't return it. So we need to make sure to be flexible about that while we define a common core set of semantics. Flexibility like that is very powerful and could be used in a variety of protocols and deployments across domains and vendors.

You know, this idea is sounding better and better. In fact, I'll do you one better. I think this is such a fantastic idea that I wrote it all down in RFC format:

http://tools.ietf.org/html/draft-richer= -oauth-introspection-06

Glad to have you on board, Phil.

 -- Justin

On 7/29/2014 9:02 PM, Phil Hunt wrote:
I think one alternative to an introspection service is a revocation status service. 

But it is often not needed if token lifetimes are small (minutes / session life) compared to the refresh token which might last much longer. 

Again having info on the case helps explain the requirements of your case and we can tell what the best pattern is. 

Phil

On Jul 29, 2014, at 17:55, Thomas Broyer <t.broyer@gmail.com> wrote:

Try it where? When you're the RS trying to determine whether you should accept the token or reject it?

Le 30 juil. 2014 02:49, "Mike Jones" <Michael.Jones@microsoft.com> a =C3=A9crit :

Yes, but that=E2=80=99s the simplest thing to determine =E2= =80=93 try the token and see whether it works or not.

 

From: Thomas Broyer [mailto:t.broyer@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: <oauth@ietf.org>; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

 

Decoding a token with a specific format wouldn't tell you whether the token is still live: it could have been revoked before its expiration.

Le 30 juil. 2014 02:16, "Mike Jones" <Michael.Jones@microsoft.com> a =C3=A9crit :

Did= you consider standardizing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip to an introspection endpoint so as to be able to understand things about it?

&nb= sp;

I realize that might or might not be practical in some cases, but I haven=E2=80=99t heard that alternative discussed, so I thought I=E2=80=99d bring it up.

&nb= sp;

I also second Phil=E2=80=99s comment that it would= be good to understand the use cases that this is intended to solve before embarking on a particular solution path.

&nb= sp;

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

&nb= sp;

From: OAuth [mailto:oauth-bounces@ietf.or= g] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

 

W= e also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS.

Thanks,
George

On 7/28/14, 8:11 PM, Phil Hunt wrote:

Could we have some discussion on the interop cases?

 

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

 

=46rom a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

 

Phil


On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oas= is-eu.org/

 

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.ne= t> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt= ) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/
If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  I= f
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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



 

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/=

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



_____________________________________________=
__
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m=
ailman/listinfo/oauth

 



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

=20
= --Apple-Mail-4299ED13-5ED3-4A95-B09A-32DD67B45094-- From nobody Tue Jul 29 18:45:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6531B29ED for ; Tue, 29 Jul 2014 18:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, URI_NOVOWEL=0.5] 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 H8AgLfOi_DXh for ; Tue, 29 Jul 2014 18:45:00 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id E1B8F1A0ACD for ; Tue, 29 Jul 2014 18:44:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 5A1234FF0DE8; Tue, 29 Jul 2014 18:44:54 -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 X7zONaJWq1vX; Tue, 29 Jul 2014 18:44:45 -0700 (PDT) Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 936FF4FF0DB8; Tue, 29 Jul 2014 18:44:45 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_A3B6DD79-FD34-4564-AB8D-C8C5D0F4E4F7" From: Eve Maler In-Reply-To: Date: Tue, 29 Jul 2014 18:45:21 -0700 Message-Id: <2E4485F3-8283-40E9-930E-53D149F2D5AA@xmlgrrl.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> <5C8461F3-CD04-4F5E-9BDF-6E91336D5F50@oracle.com> <53D8455B.1030303@mit.edu> To: Phil Hunt X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/t3kyhUJAxxo0is9Pf1lNIEenvy8 Cc: "" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 01:45:03 -0000 --Apple-Mail=_A3B6DD79-FD34-4564-AB8D-C8C5D0F4E4F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would say that if an RS and AS are relatively tightly coupled and have = established their trust "off stage", then the RS will know where to go = and how to interpret the results. If an RS and AS are entirely loosely = coupled, then there are a number of options for trust establishment for = which UMA provides one solution, leveraging an OAuth-protected token = introspection endpoint and an endpoint discovery mechanism. (BTW, I first wrote about this usage of token introspection on this list = in November 2012, where I distinguished "shallow" and "deep" options for = RS/AS communication.) Eve On 29 Jul 2014, at 6:17 PM, Phil Hunt wrote: > Mike's proposal may be sufficient for Thomas' case given a small token = lifetime.=20 >=20 > The federated cases may have other issues.... >=20 > How does the RS know who issued the opaque token and what = introspection point is authoritative?=20 >=20 > I am not saying your spec is not the right answer. I am just not = prepared to limit functionality yet by adopting the draft until we have = sufficient requirements understood.=20 >=20 > Let the rest of us catch up please.=20 >=20 > Phil >=20 > On Jul 29, 2014, at 18:07, Justin Richer wrote: >=20 >> So you want a service where the RS can call an HTTP endpoint to see = if the token is alive or not? That sounds like an awesome idea! Very = useful for a variety of use cases that people have already mentioned on = that list. Maybe that service should respond in JSON with, say, { = "active": true } if it's still valid. That's a great start, and that = should obviously be MTI. >>=20 >> But while we're there, we probably want to know what else the token = is for, since this service will probably know that, so let's add in the = "scope" and "client_id" and whatever other meta-information we have = about the token. If this endpoint doesn't have that information? Well = then, I guess it can't return it. So we need to make sure to be flexible = about that while we define a common core set of semantics. Flexibility = like that is very powerful and could be used in a variety of protocols = and deployments across domains and vendors. >>=20 >> You know, this idea is sounding better and better. In fact, I'll do = you one better. I think this is such a fantastic idea that I wrote it = all down in RFC format: >>=20 >> http://tools.ietf.org/html/draft-richer-oauth-introspection-06 >>=20 >> Glad to have you on board, Phil. >>=20 >> -- Justin >>=20 >> On 7/29/2014 9:02 PM, Phil Hunt wrote: >>> I think one alternative to an introspection service is a revocation = status service.=20 >>>=20 >>> But it is often not needed if token lifetimes are small (minutes / = session life) compared to the refresh token which might last much = longer.=20 >>>=20 >>> Again having info on the case helps explain the requirements of your = case and we can tell what the best pattern is.=20 >>>=20 >>> Phil >>>=20 >>> On Jul 29, 2014, at 17:55, Thomas Broyer wrote: >>>=20 >>>> Try it where? When you're the RS trying to determine whether you = should accept the token or reject it? >>>>=20 >>>> Le 30 juil. 2014 02:49, "Mike Jones" = a =C3=A9crit : >>>> Yes, but that=E2=80=99s the simplest thing to determine =E2=80=93 = try the token and see whether it works or not. >>>>=20 >>>> =20 >>>> From: Thomas Broyer [mailto:t.broyer@gmail.com]=20 >>>> Sent: Tuesday, July 29, 2014 5:43 PM >>>> To: Mike Jones >>>> Cc: ; George Fletcher; Phil Hunt >>>> Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth = Token Introspection" as an OAuth Working Group Item >>>>=20 >>>> =20 >>>> Decoding a token with a specific format wouldn't tell you whether = the token is still live: it could have been revoked before its = expiration. >>>>=20 >>>> Le 30 juil. 2014 02:16, "Mike Jones" = a =C3=A9crit : >>>>=20 >>>> Did you consider standardizing the access token format within that = deployment so all the parties that needed to could understand it, rather = requiring an extra round trip to an introspection endpoint so as to be = able to understand things about it? >>>>=20 >>>> =20 >>>> I realize that might or might not be practical in some cases, but I = haven=E2=80=99t heard that alternative discussed, so I thought I=E2=80=99d= bring it up. >>>>=20 >>>> =20 >>>> I also second Phil=E2=80=99s comment that it would be good to = understand the use cases that this is intended to solve before embarking = on a particular solution path. >>>>=20 >>>> =20 >>>> -- Mike >>>>=20 >>>> =20 >>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George = Fletcher >>>> Sent: Tuesday, July 29, 2014 3:25 PM >>>> To: Phil Hunt; Thomas Broyer >>>> Cc: oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth = Token Introspection" as an OAuth Working Group Item >>>>=20 >>>> =20 >>>> We also have a use case where the AS is provided by a partner and = the RS is provided by AOL. Being able to have a standardized way of = validating and getting data about the token from the AS would make our = implementation much simpler as we can use the same mechanism for all = Authorization Servers and not have to implement one off solutions for = each AS. >>>>=20 >>>> Thanks, >>>> George >>>>=20 >>>> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>>>=20 >>>> Could we have some discussion on the interop cases? >>>>=20 >>>> =20 >>>> Is it driven by scenarios where AS and resource are separate = domains? Or may this be only of interest to specific protocols like UMA? >>>>=20 >>>> =20 >>>> =46rom a technique principle, the draft is important and sound. I = am just not there yet on the reasons for an interoperable standard.=20 >>>>=20 >>>> =20 >>>> Phil >>>>=20 >>>>=20 >>>> On Jul 28, 2014, at 17:00, Thomas Broyer = wrote: >>>>=20 >>>> Yes. This spec is of special interest to the platform we're = building for http://www.oasis-eu.org/ >>>>=20 >>>> =20 >>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig = wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> during the IETF #90 OAuth WG meeting, there was strong consensus in >>>> adopting the "OAuth Token Introspection" >>>> (draft-richer-oauth-introspection-06.txt) specification as an OAuth = WG >>>> work item. >>>>=20 >>>> We would now like to verify the outcome of this call for adoption = on the >>>> OAuth WG mailing list. Here is the link to the document: >>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>>=20 >>>> If you did not hum at the IETF 90 OAuth WG meeting, and have an = opinion >>>> as to the suitability of adopting this document as a WG work item, >>>> please send mail to the OAuth WG list indicating your opinion = (Yes/No). >>>>=20 >>>> The confirmation call for adoption will last until August 10, 2014. = If >>>> you have issues/edits/comments on the document, please send these >>>> comments along to the list in your response to this Call for = Adoption. >>>>=20 >>>> Ciao >>>> Hannes & Derek >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> =20 >>>> --=20 >>>> Thomas Broyer >>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> =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 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail=_A3B6DD79-FD34-4564-AB8D-C8C5D0F4E4F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I = would say that if an RS and AS are relatively tightly coupled and have = established their trust "off stage", then the RS will know where to go = and how to interpret the results. If an RS and AS are entirely loosely = coupled, then there are a number of options for trust establishment for = which UMA provides one solution, leveraging an OAuth-protected token = introspection endpoint and an endpoint discovery = mechanism.

(BTW, I first wrote about this usage = of token introspection on this list in = November 2012, where I distinguished "shallow" and "deep" = options for RS/AS communication.)

= Eve

On 29 Jul 2014, at 6:17 PM, Phil Hunt = <phil.hunt@oracle.com> = wrote:

Mike's proposal may be = sufficient for Thomas' case given a small token = lifetime. 

The federated cases may have = other issues....

How does the RS know who = issued the opaque token and what introspection point is = authoritative? 

I am not saying your spec = is not the right answer. I am just not prepared to limit functionality = yet by adopting the draft until we have sufficient requirements = understood. 

Let the rest of us catch up = please. 

Phil

On Jul 29, 2014, at = 18:07, Justin Richer <jricher@mit.edu> = wrote:

=20 =20 =20
So you want a service where the RS = can call an HTTP endpoint to see if the token is alive or not? That sounds like an awesome idea! Very useful for a variety of use cases that people have already mentioned on that list. Maybe that service should respond in JSON with, say, { "active": true } if it's still valid. That's a great start, and that should obviously be MTI.

But while we're there, we probably want to know what else the token is for, since this service will probably know that, so let's add in the "scope" and "client_id" and whatever other meta-information we have about the token. If this endpoint doesn't have that information? Well then, I guess it can't return it. So we need to make sure to be flexible about that while we define a common core set of semantics. Flexibility like that is very powerful and could be used in a variety of protocols and deployments across domains and vendors.

You know, this idea is sounding better and better. In fact, I'll do you one better. I think this is such a fantastic idea that I wrote it all down in RFC format:

ht= tp://tools.ietf.org/html/draft-richer-oauth-introspection-06

Glad to have you on board, Phil.

 -- Justin

On 7/29/2014 9:02 PM, Phil Hunt wrote:
I think one alternative to an introspection service is a revocation status service. 

But it is often not needed if token lifetimes are small (minutes / session life) compared to the refresh token which might last much longer. 

Again having info on the case helps explain the requirements of your case and we can tell what the best pattern is. 

Phil

On Jul 29, 2014, at 17:55, Thomas Broyer <t.broyer@gmail.com> wrote:

Try it where? When you're the RS trying to determine whether you should accept the token or reject = it?

Le 30 juil. 2014 02:49, "Mike = Jones" <Michael.Jones@microsoft.com> a =C3=A9crit :

Yes, but that=E2=80=99s the simplest thing to determine = =E2=80=93 try the token and see whether it works or = not.

 

From: Thomas Broyer [mailto:t.broyer@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: <oauth@ietf.org>; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

 

Decoding a token with a = specific format wouldn't tell you whether the token is still live: it could have been revoked before its expiration.

Le 30 juil. 2014 02:16, = "Mike Jones" <Michael.Jones@microsoft.com> a =C3=A9crit :

Did you consider standardizing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip to an introspection endpoint so as to be able to understand things about = it?

 

I realize that might or might not be practical in some cases, but I haven=E2=80=99t heard = that alternative discussed, so I thought I=E2=80=99= d bring it up.

 

I also second Phil=E2=80=99s comment that it = would be good to understand the use cases that this is intended to solve before embarking on a particular solution = path.

 

        &nbs= p;            =             &n= bsp;           &nbs= p;            =   -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

 

We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS.

Thanks,
George

On 7/28/14, 8:11 PM, = Phil Hunt wrote:

Could we have some discussion on the interop cases?

 

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like = UMA?

 

=46rom a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable = standard. 

 

Phil


On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec = is of special interest to the platform we're building for http://www.oasis-eu.org/

 

On Mon, Jul = 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
= (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-intro= spection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014. =  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for = Adoption.

Ciao
Hannes & Derek


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



 

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

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



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


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

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


Eve Maler       =                     =        http://www.xmlgrrl.com/blog
+1= 425 345 6756                 =         http://www.twitter.com/xmlgrrl=

= --Apple-Mail=_A3B6DD79-FD34-4564-AB8D-C8C5D0F4E4F7-- From nobody Tue Jul 29 19:10:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E771B2A52 for ; Tue, 29 Jul 2014 19:10:08 -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 mchBHIJmeNj5 for ; Tue, 29 Jul 2014 19:10:06 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA99A1B2A51 for ; Tue, 29 Jul 2014 19:10:05 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id 10so366876lbg.26 for ; Tue, 29 Jul 2014 19:10:04 -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:cc:content-type; bh=hTjIuGzJ/8JfG9Cx34+sJmkjbuwm4wMLu3iD1U8uDqI=; b=mi/qy2pBs6f/nEY9ud+psMySpohRck6UIRD2f5WYBI+WP4zZJg1CEkfbCwQOTj2vS4 zjsJ5v5fQHiCRxj+q7oetFYzzEybXvHZ3rMgF1qlcCgZ5n7QcOyVCobde0qEWCHqVzkH LQ2EbfbaNh4BNJhec/ppGxW+azO101xwzseZcgdBmQLxXZzdcH6L4JGl9EPd9ZytJUTN YZEbSOS9eSoPRZh4ZLkol+VSYBtlGLKoYN3wUkXFspDeUEcA/EczZFuMmSSyJvBJHOm2 l3/NZvhYnYrPexyVgcXBLpAHFZGm6adLUGFecw0LFC3Qd4PZ1i1ePfLxQTEP8vgLP1kg PFEw== MIME-Version: 1.0 X-Received: by 10.112.149.200 with SMTP id uc8mr797464lbb.70.1406686204111; Tue, 29 Jul 2014 19:10:04 -0700 (PDT) Received: by 10.112.135.106 with HTTP; Tue, 29 Jul 2014 19:10:04 -0700 (PDT) Date: Wed, 30 Jul 2014 11:10:04 +0900 Message-ID: From: Takahiko Kawasaki To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/UTFbb9zidgDWjHaixTuVSCUmstg Subject: [OAUTH-WG] Standardized error responses from protected resource endpoints 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, 30 Jul 2014 02:10:08 -0000 Hello, I have a question. Is there any standardized specification about error responses from protected resource endpoints? "RFC 6749, 7.2. Error Response" says "the specifics of such error responses are beyond the scope of this specification", but I'm wondering if OAuth WG has done something for that. >From error responses, I'd like to know information about: (1) Usability (active or expired? (or not exist?)) (2) Refreshability (associated usable refresh token exists?) (3) Sufficiency (usable but lacking necessary permissions?) For example, I'm expecting an error response like below with "400 Bad Request" or "403 Forbidden". { "error":"...", "error_description":"...", "error_uri":"...", "usable": true, "refreshable": true, "sufficient": false } Best Regards, Takahiko Kawasaki From nobody Tue Jul 29 22:03:25 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D821A0AD6 for ; Tue, 29 Jul 2014 22:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 wvpqE85X6Bmy for ; Tue, 29 Jul 2014 22:03:16 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761C01A0AFA for ; Tue, 29 Jul 2014 22:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28762; q=dns/txt; s=iport; t=1406696595; x=1407906195; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3WgthYqCZHjGAmQ7ehPUICUW3BXPvsq/yS6oQidFVdI=; b=hq7mINWsNNMlJ47Dr8oSoYYHdVjGhtN9u0Ue9jjQ/xnFMFG6SlbBLt7k MqensvBWoFq7G0XHpwfPi5x9BhJXPhFuNKE7yptHZHUX5+9CmRd6AV7jQ j7CpIUL8LqnFmQkzoNqDTWZnZqRJZLeCiZxxaT0iqHDFqJfD88MdKWRkQ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoPABp82FOtJA2G/2dsb2JhbABaDoI5R1JXBIJ0hmSpcpZQgVgBCYdLARl4FneEAwEBAQQBAQEaBgpBAwgQAgEIDgMEAQELFgMEAwICAh8GCxQJCAIEAQ0FCBOIEwMRDagzhwCJUw2HCReNH4FcAQEeDQkXBAYBCYJwNoEbBYR1lFqDV4xZhiWCA4EEQmwBgQICBxcCBBw X-IronPort-AV: E=Sophos; i="5.01,762,1400025600"; d="scan'208,217"; a="65057981" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 30 Jul 2014 05:03:12 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6U53CNU028048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 05:03:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 00:03:12 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Richer , Mike Jones , Thomas Broyer Thread-Topic: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item Thread-Index: AQHPqooPziDikvoCDEyWh/+CHL2pVJu2fwgAgAAC6oCAAXSWAIAAHzgAgAAHVQCAAAHegIAAAF4A///yA2A= Date: Wed, 30 Jul 2014 05:03:11 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282FCD52@xmb-rcd-x10.cisco.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> <53D84162.2020406@mit.edu> In-Reply-To: <53D84162.2020406@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.50.29] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A282FCD52xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/rT6f666hvtbF-i396VH2aFK-Z38 Cc: "" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 05:03:20 -0000 --_000_913383AAA69FF945B8F946018B75898A282FCD52xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG9rZW4gcmV2b2NhdGlvbiB3aWxsIHJlcXVpcmUgdW5zb2xpY2l0ZWQgdXBkYXRlIGZyb20gQVMg dG8gUlMgdGhhdCB0aGUgdG9rZW4gaXMgbm8gbG9uZ2VyIHZhbGlkLCBpdCB3aWxsIGJlIHVzZWZ1 bCB0byBhZGQgdGhpcyBjb21tdW5pY2F0aW9uIG1lY2hhbmlzbSBpbiB0aGlzIGRyYWZ0Lg0KDQot VGlydQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBKdXN0aW4gUmljaGVyDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMzAsIDIwMTQgNjoy MSBBTQ0KVG86IE1pa2UgSm9uZXM7IFRob21hcyBCcm95ZXINCkNjOiA8b2F1dGhAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBDb25maXJtYXRpb246IENhbGwgZm9yIEFkb3B0aW9u IG9mICJPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uIiBhcyBhbiBPQXV0aCBXb3JraW5nIEdyb3Vw IEl0ZW0NCg0KTm90IHRydWUgaWYgSSByZXZva2UgdGhlIHRva2VuIGFmdGVyIGl0J3MgYmVlbiBp c3N1ZWQgYnV0IGJlZm9yZSBpdCBleHBpcmVzLg0KDQpPbiA3LzI5LzIwMTQgODo0OSBQTSwgTWlr ZSBKb25lcyB3cm90ZToNClllcywgYnV0IHRoYXTigJlzIHRoZSBzaW1wbGVzdCB0aGluZyB0byBk ZXRlcm1pbmUg4oCTIHRyeSB0aGUgdG9rZW4gYW5kIHNlZSB3aGV0aGVyIGl0IHdvcmtzIG9yIG5v dC4NCg0KRnJvbTogVGhvbWFzIEJyb3llciBbbWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbV0NClNl bnQ6IFR1ZXNkYXksIEp1bHkgMjksIDIwMTQgNTo0MyBQTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiA8 b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz47IEdlb3JnZSBGbGV0Y2hlcjsg UGhpbCBIdW50DQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBDb25maXJtYXRpb246IENhbGwgZm9y IEFkb3B0aW9uIG9mICJPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uIiBhcyBhbiBPQXV0aCBXb3Jr aW5nIEdyb3VwIEl0ZW0NCg0KDQpEZWNvZGluZyBhIHRva2VuIHdpdGggYSBzcGVjaWZpYyBmb3Jt YXQgd291bGRuJ3QgdGVsbCB5b3Ugd2hldGhlciB0aGUgdG9rZW4gaXMgc3RpbGwgbGl2ZTogaXQg Y291bGQgaGF2ZSBiZWVuIHJldm9rZWQgYmVmb3JlIGl0cyBleHBpcmF0aW9uLg0KTGUgMzAganVp bC4gMjAxNCAwMjoxNiwgIk1pa2UgSm9uZXMiIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IGEgw6ljcml0IDoNCkRpZCB5b3Ug Y29uc2lkZXIgc3RhbmRhcmRpemluZyB0aGUgYWNjZXNzIHRva2VuIGZvcm1hdCB3aXRoaW4gdGhh dCBkZXBsb3ltZW50IHNvIGFsbCB0aGUgcGFydGllcyB0aGF0IG5lZWRlZCB0byBjb3VsZCB1bmRl cnN0YW5kIGl0LCByYXRoZXIgcmVxdWlyaW5nIGFuIGV4dHJhIHJvdW5kIHRyaXAgdG8gYW4gaW50 cm9zcGVjdGlvbiBlbmRwb2ludCBzbyBhcyB0byBiZSBhYmxlIHRvIHVuZGVyc3RhbmQgdGhpbmdz IGFib3V0IGl0Pw0KDQpJIHJlYWxpemUgdGhhdCBtaWdodCBvciBtaWdodCBub3QgYmUgcHJhY3Rp Y2FsIGluIHNvbWUgY2FzZXMsIGJ1dCBJIGhhdmVu4oCZdCBoZWFyZCB0aGF0IGFsdGVybmF0aXZl IGRpc2N1c3NlZCwgc28gSSB0aG91Z2h0IEnigJlkIGJyaW5nIGl0IHVwLg0KDQpJIGFsc28gc2Vj b25kIFBoaWzigJlzIGNvbW1lbnQgdGhhdCBpdCB3b3VsZCBiZSBnb29kIHRvIHVuZGVyc3RhbmQg dGhlIHVzZSBjYXNlcyB0aGF0IHRoaXMgaXMgaW50ZW5kZWQgdG8gc29sdmUgYmVmb3JlIGVtYmFy a2luZyBvbiBhIHBhcnRpY3VsYXIgc29sdXRpb24gcGF0aC4NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9t OiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgR2VvcmdlIEZsZXRjaGVyDQpTZW50OiBUdWVzZGF5 LCBKdWx5IDI5LCAyMDE0IDM6MjUgUE0NClRvOiBQaGlsIEh1bnQ7IFRob21hcyBCcm95ZXINCkNj OiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09B VVRILVdHXSBDb25maXJtYXRpb246IENhbGwgZm9yIEFkb3B0aW9uIG9mICJPQXV0aCBUb2tlbiBJ bnRyb3NwZWN0aW9uIiBhcyBhbiBPQXV0aCBXb3JraW5nIEdyb3VwIEl0ZW0NCg0KV2UgYWxzbyBo YXZlIGEgdXNlIGNhc2Ugd2hlcmUgdGhlIEFTIGlzIHByb3ZpZGVkIGJ5IGEgcGFydG5lciBhbmQg dGhlIFJTIGlzIHByb3ZpZGVkIGJ5IEFPTC4gQmVpbmcgYWJsZSB0byBoYXZlIGEgc3RhbmRhcmRp emVkIHdheSBvZiB2YWxpZGF0aW5nIGFuZCBnZXR0aW5nIGRhdGEgYWJvdXQgdGhlIHRva2VuIGZy b20gdGhlIEFTIHdvdWxkIG1ha2Ugb3VyIGltcGxlbWVudGF0aW9uIG11Y2ggc2ltcGxlciBhcyB3 ZSBjYW4gdXNlIHRoZSBzYW1lIG1lY2hhbmlzbSBmb3IgYWxsIEF1dGhvcml6YXRpb24gU2VydmVy cyBhbmQgbm90IGhhdmUgdG8gaW1wbGVtZW50IG9uZSBvZmYgc29sdXRpb25zIGZvciBlYWNoIEFT Lg0KDQpUaGFua3MsDQpHZW9yZ2UNCk9uIDcvMjgvMTQsIDg6MTEgUE0sIFBoaWwgSHVudCB3cm90 ZToNCkNvdWxkIHdlIGhhdmUgc29tZSBkaXNjdXNzaW9uIG9uIHRoZSBpbnRlcm9wIGNhc2VzPw0K DQpJcyBpdCBkcml2ZW4gYnkgc2NlbmFyaW9zIHdoZXJlIEFTIGFuZCByZXNvdXJjZSBhcmUgc2Vw YXJhdGUgZG9tYWlucz8gT3IgbWF5IHRoaXMgYmUgb25seSBvZiBpbnRlcmVzdCB0byBzcGVjaWZp YyBwcm90b2NvbHMgbGlrZSBVTUE/DQoNCkZyb20gYSB0ZWNobmlxdWUgcHJpbmNpcGxlLCB0aGUg ZHJhZnQgaXMgaW1wb3J0YW50IGFuZCBzb3VuZC4gSSBhbSBqdXN0IG5vdCB0aGVyZSB5ZXQgb24g dGhlIHJlYXNvbnMgZm9yIGFuIGludGVyb3BlcmFibGUgc3RhbmRhcmQuDQoNClBoaWwNCg0KT24g SnVsIDI4LCAyMDE0LCBhdCAxNzowMCwgVGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29t PG1haWx0bzp0LmJyb3llckBnbWFpbC5jb20+PiB3cm90ZToNClllcy4gVGhpcyBzcGVjIGlzIG9m IHNwZWNpYWwgaW50ZXJlc3QgdG8gdGhlIHBsYXRmb3JtIHdlJ3JlIGJ1aWxkaW5nIGZvciBodHRw Oi8vd3d3Lm9hc2lzLWV1Lm9yZy8NCg0KT24gTW9uLCBKdWwgMjgsIDIwMTQgYXQgNzozMyBQTSwg SGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOmhhbm5l cy50c2Nob2ZlbmlnQGdteC5uZXQ+PiB3cm90ZToNCkhpIGFsbCwNCg0KZHVyaW5nIHRoZSBJRVRG ICM5MCBPQXV0aCBXRyBtZWV0aW5nLCB0aGVyZSB3YXMgc3Ryb25nIGNvbnNlbnN1cyBpbg0KYWRv cHRpbmcgdGhlICJPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uIg0KKGRyYWZ0LXJpY2hlci1vYXV0 aC1pbnRyb3NwZWN0aW9uLTA2LnR4dCkgc3BlY2lmaWNhdGlvbiBhcyBhbiBPQXV0aCBXRw0Kd29y ayBpdGVtLg0KDQpXZSB3b3VsZCBub3cgbGlrZSB0byB2ZXJpZnkgdGhlIG91dGNvbWUgb2YgdGhp cyBjYWxsIGZvciBhZG9wdGlvbiBvbiB0aGUNCk9BdXRoIFdHIG1haWxpbmcgbGlzdC4gSGVyZSBp cyB0aGUgbGluayB0byB0aGUgZG9jdW1lbnQ6DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLw0KDQpJZiB5b3UgZGlkIG5vdCBo dW0gYXQgdGhlIElFVEYgOTAgT0F1dGggV0cgbWVldGluZywgYW5kIGhhdmUgYW4gb3Bpbmlvbg0K YXMgdG8gdGhlIHN1aXRhYmlsaXR5IG9mIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQgYXMgYSBXRyB3 b3JrIGl0ZW0sDQpwbGVhc2Ugc2VuZCBtYWlsIHRvIHRoZSBPQXV0aCBXRyBsaXN0IGluZGljYXRp bmcgeW91ciBvcGluaW9uIChZZXMvTm8pLg0KDQpUaGUgY29uZmlybWF0aW9uIGNhbGwgZm9yIGFk b3B0aW9uIHdpbGwgbGFzdCB1bnRpbCBBdWd1c3QgMTAsIDIwMTQuICBJZg0KeW91IGhhdmUgaXNz dWVzL2VkaXRzL2NvbW1lbnRzIG9uIHRoZSBkb2N1bWVudCwgcGxlYXNlIHNlbmQgdGhlc2UNCmNv bW1lbnRzIGFsb25nIHRvIHRoZSBsaXN0IGluIHlvdXIgcmVzcG9uc2UgdG8gdGhpcyBDYWxsIGZv ciBBZG9wdGlvbi4NCg0KQ2lhbw0KSGFubmVzICYgRGVyZWsNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0 aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KVGhvbWFzIEJyb3llcg0KL3TJlC5tYS5i yoF3YS5qZS88aHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhA aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_913383AAA69FF945B8F946018B75898A282FCD52xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6 YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpi bGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjIN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBi Z2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ub2tlbiByZXZvY2F0aW9uIHdpbGwg cmVxdWlyZSB1bnNvbGljaXRlZCB1cGRhdGUgZnJvbSBBUyB0byBSUyB0aGF0IHRoZSB0b2tlbiBp cyBubyBsb25nZXIgdmFsaWQsIGl0IHdpbGwgYmUgdXNlZnVsIHRvIGFkZCB0aGlzIGNvbW11bmlj YXRpb24gbWVjaGFuaXNtIGluIHRoaXMNCiBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2lu ZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OndpbmRvd3RleHQiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5P biBCZWhhbGYgT2YgPC9iPkp1c3RpbiBSaWNoZXI8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBKdWx5IDMwLCAyMDE0IDY6MjEgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM7IFRob21h cyBCcm95ZXI8YnI+DQo8Yj5DYzo8L2I+ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gQ29uZmlybWF0aW9uOiBDYWxsIGZvciBBZG9wdGlv biBvZiAmcXVvdDtPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uJnF1b3Q7IGFzIGFuIE9BdXRoIFdv cmtpbmcgR3JvdXAgSXRlbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Ob3QgdHJ1ZSBpZiBJIHJldm9rZSB0aGUgdG9rZW4gYWZ0ZXIgaXQncyBi ZWVuIGlzc3VlZCBidXQgYmVmb3JlIGl0IGV4cGlyZXMuPGJyPg0KPGJyPg0KT24gNy8yOS8yMDE0 IDg6NDkgUE0sIE1pa2UgSm9uZXMgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlllcywgYnV0IHRoYXTigJlzIHRoZSBzaW1wbGVzdCB0aGluZyB0byBkZXRlcm1pbmUg4oCT IHRyeSB0aGUgdG9rZW4gYW5kIHNlZSB3aGV0aGVyIGl0IHdvcmtzIG9yIG5vdC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRob21hcyBCcm95ZXIgWzxhIGhyZWY9 Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iPm1haWx0bzp0LmJyb3llckBnbWFpbC5jb208L2E+ XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMjksIDIwMTQgNTo0MyBQTTxicj4N CjxiPlRvOjwvYj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPjsgR2VvcmdlIEZsZXRjaGVy OyBQaGlsIEh1bnQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtPQVVUSC1XR10gQ29uZmlybWF0 aW9uOiBDYWxsIGZvciBBZG9wdGlvbiBvZiAmcXVvdDtPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9u JnF1b3Q7IGFzIGFuIE9BdXRoIFdvcmtpbmcgR3JvdXAgSXRlbTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+RGVjb2Rp bmcgYSB0b2tlbiB3aXRoIGEgc3BlY2lmaWMgZm9ybWF0IHdvdWxkbid0IHRlbGwgeW91IHdoZXRo ZXIgdGhlIHRva2VuIGlzIHN0aWxsIGxpdmU6IGl0IGNvdWxkIGhhdmUgYmVlbiByZXZva2VkIGJl Zm9yZSBpdHMgZXhwaXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5MZSAzMCBqdWlsLiAyMDE0IDAyOjE2LCAmcXVvdDtNaWtlIEpvbmVzJnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyBhIMOpY3JpdCA6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkRpZCB5b3UgY29uc2lkZXIgc3RhbmRhcmRpemluZyB0aGUgYWNj ZXNzIHRva2VuIGZvcm1hdCB3aXRoaW4gdGhhdCBkZXBsb3ltZW50IHNvIGFsbCB0aGUgcGFydGll cw0KIHRoYXQgbmVlZGVkIHRvIGNvdWxkIHVuZGVyc3RhbmQgaXQsIHJhdGhlciByZXF1aXJpbmcg YW4gZXh0cmEgcm91bmQgdHJpcCB0byBhbiBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IHNvIGFzIHRv IGJlIGFibGUgdG8gdW5kZXJzdGFuZCB0aGluZ3MgYWJvdXQgaXQ/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBy ZWFsaXplIHRoYXQgbWlnaHQgb3IgbWlnaHQgbm90IGJlIHByYWN0aWNhbCBpbiBzb21lIGNhc2Vz LCBidXQgSSBoYXZlbuKAmXQgaGVhcmQgdGhhdCBhbHRlcm5hdGl2ZQ0KIGRpc2N1c3NlZCwgc28g SSB0aG91Z2h0IEnigJlkIGJyaW5nIGl0IHVwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWxzbyBzZWNvbmQg UGhpbOKAmXMgY29tbWVudCB0aGF0IGl0IHdvdWxkIGJlIGdvb2QgdG8gdW5kZXJzdGFuZCB0aGUg dXNlIGNhc2VzIHRoYXQgdGhpcyBpcyBpbnRlbmRlZA0KIHRvIHNvbHZlIGJlZm9yZSBlbWJhcmtp bmcgb24gYSBwYXJ0aWN1bGFyIHNvbHV0aW9uIHBhdGguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzo8YSBocmVm PSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5HZW9yZ2UgRmxldGNoZXI8 YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyOSwgMjAxNCAzOjI1IFBNPGJyPg0KPGI+ VG86PC9iPiBQaGlsIEh1bnQ7IFRob21hcyBCcm95ZXI8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBDb25maXJtYXRpb246IENhbGwg Zm9yIEFkb3B0aW9uIG9mICZxdW90O09BdXRoIFRva2VuIEludHJvc3BlY3Rpb24mcXVvdDsgYXMg YW4gT0F1dGggV29ya2luZyBHcm91cCBJdGVtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2UgYWxzbyBoYXZlIGEgdXNlIGNhc2Ugd2hl cmUgdGhlIEFTIGlzIHByb3ZpZGVkIGJ5IGEgcGFydG5lciBhbmQgdGhlIFJTIGlzIHByb3ZpZGVk IGJ5IEFPTC4gQmVpbmcgYWJsZSB0byBoYXZlIGEgc3RhbmRhcmRpemVkIHdheSBvZg0KIHZhbGlk YXRpbmcgYW5kIGdldHRpbmcgZGF0YSBhYm91dCB0aGUgdG9rZW4gZnJvbSB0aGUgQVMgd291bGQg bWFrZSBvdXIgaW1wbGVtZW50YXRpb24gbXVjaCBzaW1wbGVyIGFzIHdlIGNhbiB1c2UgdGhlIHNh bWUgbWVjaGFuaXNtIGZvciBhbGwgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzIGFuZCBub3QgaGF2ZSB0 byBpbXBsZW1lbnQgb25lIG9mZiBzb2x1dGlvbnMgZm9yIGVhY2ggQVMuPGJyPg0KPGJyPg0KVGhh bmtzLDxicj4NCkdlb3JnZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk9uIDcvMjgvMTQsIDg6MTEgUE0sIFBoaWwgSHVudCB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db3VsZCB3 ZSBoYXZlIHNvbWUgZGlzY3Vzc2lvbiBvbiB0aGUgaW50ZXJvcCBjYXNlcz88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklzIGl0IGRyaXZl biBieSBzY2VuYXJpb3Mgd2hlcmUgQVMgYW5kIHJlc291cmNlIGFyZSBzZXBhcmF0ZSBkb21haW5z PyBPciBtYXkgdGhpcyBiZSBvbmx5IG9mIGludGVyZXN0IHRvIHNwZWNpZmljIHByb3RvY29scyBs aWtlIFVNQT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkZyb20gYSB0ZWNobmlxdWUgcHJpbmNpcGxlLCB0aGUgZHJhZnQgaXMgaW1wb3J0 YW50IGFuZCBzb3VuZC4gSSBhbSBqdXN0IG5vdCB0aGVyZSB5ZXQgb24gdGhlIHJlYXNvbnMgZm9y IGFuIGludGVyb3BlcmFibGUgc3RhbmRhcmQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QaGlsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEp1bCAyOCwgMjAxNCwgYXQg MTc6MDAsIFRob21hcyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj50LmJyb3llckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+WWVzLiBUaGlzIHNwZWMgaXMgb2Ygc3BlY2lhbCBpbnRlcmVzdCB0byB0aGUgcGxhdGZvcm0g d2UncmUgYnVpbGRpbmcgZm9yJm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5vYXNpcy1ldS5vcmcv IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5vYXNpcy1ldS5vcmcvPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgSnVsIDI4LCAyMDE0IGF0 IDc6MzMgUE0sIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86aGFubmVzLnRz Y2hvZmVuaWdAZ214Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgYWxs LDxicj4NCjxicj4NCmR1cmluZyB0aGUgSUVURiAjOTAgT0F1dGggV0cgbWVldGluZywgdGhlcmUg d2FzIHN0cm9uZyBjb25zZW5zdXMgaW48YnI+DQphZG9wdGluZyB0aGUgJnF1b3Q7T0F1dGggVG9r ZW4gSW50cm9zcGVjdGlvbiZxdW90Ozxicj4NCihkcmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVj dGlvbi0wNi50eHQpIHNwZWNpZmljYXRpb24gYXMgYW4gT0F1dGggV0c8YnI+DQp3b3JrIGl0ZW0u PGJyPg0KPGJyPg0KV2Ugd291bGQgbm93IGxpa2UgdG8gdmVyaWZ5IHRoZSBvdXRjb21lIG9mIHRo aXMgY2FsbCBmb3IgYWRvcHRpb24gb24gdGhlPGJyPg0KT0F1dGggV0cgbWFpbGluZyBsaXN0LiBI ZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBkb2N1bWVudDo8YnI+DQo8YSBocmVmPSJodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmlj aGVyLW9hdXRoLWludHJvc3BlY3Rpb24vPC9hPjxicj4NCjxicj4NCklmIHlvdSBkaWQgbm90IGh1 bSBhdCB0aGUgSUVURiA5MCBPQXV0aCBXRyBtZWV0aW5nLCBhbmQgaGF2ZSBhbiBvcGluaW9uPGJy Pg0KYXMgdG8gdGhlIHN1aXRhYmlsaXR5IG9mIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQgYXMgYSBX RyB3b3JrIGl0ZW0sPGJyPg0KcGxlYXNlIHNlbmQgbWFpbCB0byB0aGUgT0F1dGggV0cgbGlzdCBp bmRpY2F0aW5nIHlvdXIgb3BpbmlvbiAoWWVzL05vKS48YnI+DQo8YnI+DQpUaGUgY29uZmlybWF0 aW9uIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgbGFzdCB1bnRpbCBBdWd1c3QgMTAsIDIwMTQuICZu YnNwO0lmPGJyPg0KeW91IGhhdmUgaXNzdWVzL2VkaXRzL2NvbW1lbnRzIG9uIHRoZSBkb2N1bWVu dCwgcGxlYXNlIHNlbmQgdGhlc2U8YnI+DQpjb21tZW50cyBhbG9uZyB0byB0aGUgbGlzdCBpbiB5 b3VyIHJlc3BvbnNlIHRvIHRoaXMgQ2FsbCBmb3IgQWRvcHRpb24uPGJyPg0KPGJyPg0KQ2lhbzxi cj4NCkhhbm5lcyAmYW1wOyBEZXJlazxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLQ0KPGJyPg0KVGhvbWFzIEJyb3llcjxicj4NCi90PGEg aHJlZj0iaHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvIiB0YXJnZXQ9Il9ibGFuayI+ yZQubWEuYsqBd2EuamUvPC9hPiA8bzpwPg0KPC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P QXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRo IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A282FCD52xmbrcdx10ciscoc_-- From nobody Wed Jul 30 00:13:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210631B2860 for ; Wed, 30 Jul 2014 00:13:38 -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 LQGxuO1AW4j2 for ; Wed, 30 Jul 2014 00:13:34 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4751B2815 for ; Wed, 30 Jul 2014 00:13:33 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id hz20so569290lab.13 for ; Wed, 30 Jul 2014 00:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+oQedbclgHfaSj9oLv7Uv57u5TFuX0C6w1rEYXIWG+8=; b=KHkmF9XlmForapv2YWzRVOvzKGVA77FpNahycCoURlkz7sJ7Eaf6bZi8V6UrGYDEO5 aNuxWwemiLpASHSrqi697W4WPS4KkanXMDA+55HKZ0e5v5+TsPe5p7iJpye5ubEkVccm Liyo+KqI3ny/ilWSFMm9LdDprpq4l7Dve4mpcqLgUkzxhuDfyjlSlAcYv+Sa4JmFPW+r dusJXTJ1z560wZX0MpIuDtAMCCjdh30HMdsckqGoCquQ/LAXb4MmBg/5mxLejcRI++H5 sprxecrIrDHwkLwN5nP9VXSix+piO2gN+LcQCy2u0sc/hQAOTLTFncmBgqOGVNoR2lGf R/Zg== MIME-Version: 1.0 X-Received: by 10.112.225.229 with SMTP id rn5mr2037072lbc.48.1406704411541; Wed, 30 Jul 2014 00:13:31 -0700 (PDT) Received: by 10.152.113.73 with HTTP; Wed, 30 Jul 2014 00:13:31 -0700 (PDT) Received: by 10.152.113.73 with HTTP; Wed, 30 Jul 2014 00:13:31 -0700 (PDT) In-Reply-To: References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> <5C8461F3-CD04-4F5E-9BDF-6E91336D5F50@oracle.com> <53D8455B.1030303@mit.edu> Date: Wed, 30 Jul 2014 09:13:31 +0200 Message-ID: From: Thomas Broyer To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1134de46c10a6204ff63e4d7 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/eJFJg8EDygY6h8dP-8s7hbfadwc Cc: "" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 07:13:38 -0000 --001a1134de46c10a6204ff63e4d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One issue with Mike's proposal is that all RSs receiving the token would know all the scopes the token is valid for. Imagine an app requesting access to scopes allowing it to see your bank balance and retrieve your wish lists from another RS. It'll get it in the form of a Bearer token with those two scopes, and will use it at the wish list RS. Now the wish list RS decodes the token and sees it grants access to your bank balance. Because it's a bearer token, it now knows it can use it at your bank and see your balance. With opaque tokens and the introspection endpoint, the endpoint could just tell the wish list RS the token is valid for it, without leaking the fact it's also valid at your bank. I know there are better alternatives but they all involve more complexity for the clients and/or RSs. You won't believe me if I'd tell you how bad are some developers at their work. I've seen some sending their client secret as a parameter to the authorization endpoint and all sort of other stupid things you'd never imagine a web dev to do. The OAuth dance is already too complex for many, so adding crypto (PoP) or, e.g., asking them to manage distinct tokens per RS is not realizable in practice. Not now at least. And our platform goes live in one month from now and we want to have an ecosystem of clients and resource servers. When devs are lazy, wouldn't understand crypto, and treat security and privacy as an afterthought, an introspection endpoint is the way to go. Le 30 juil. 2014 03:17, "Phil Hunt" a =C3=A9crit : > Mike's proposal may be sufficient for Thomas' case given a small token > lifetime. > > The federated cases may have other issues.... > > How does the RS know who issued the opaque token and what introspection > point is authoritative? > > I am not saying your spec is not the right answer. I am just not prepared > to limit functionality yet by adopting the draft until we have sufficient > requirements understood. > > Let the rest of us catch up please. > > Phil > > On Jul 29, 2014, at 18:07, Justin Richer wrote: > > So you want a service where the RS can call an HTTP endpoint to see if th= e > token is alive or not? That sounds like an awesome idea! Very useful for = a > variety of use cases that people have already mentioned on that list. May= be > that service should respond in JSON with, say, { "active": true } if it's > still valid. That's a great start, and that should obviously be MTI. > > But while we're there, we probably want to know what else the token is > for, since this service will probably know that, so let's add in the > "scope" and "client_id" and whatever other meta-information we have about > the token. If this endpoint doesn't have that information? Well then, I > guess it can't return it. So we need to make sure to be flexible about th= at > while we define a common core set of semantics. Flexibility like that is > very powerful and could be used in a variety of protocols and deployments > across domains and vendors. > > You know, this idea is sounding better and better. In fact, I'll do you > one better. I think this is such a fantastic idea that I wrote it all dow= n > in RFC format: > > http://tools.ietf.org/html/draft-richer-oauth-introspection-06 > > Glad to have you on board, Phil. > > -- Justin > > On 7/29/2014 9:02 PM, Phil Hunt wrote: > > I think one alternative to an introspection service is a revocation statu= s > service. > > But it is often not needed if token lifetimes are small (minutes / > session life) compared to the refresh token which might last much longer. > > Again having info on the case helps explain the requirements of your > case and we can tell what the best pattern is. > > Phil > > On Jul 29, 2014, at 17:55, Thomas Broyer wrote: > > Try it where? When you're the RS trying to determine whether you should > accept the token or reject it? > Le 30 juil. 2014 02:49, "Mike Jones" a > =C3=A9crit : > >> Yes, but that=E2=80=99s the simplest thing to determine =E2=80=93 try t= he token and see >> whether it works or not. >> >> >> >> *From:* Thomas Broyer [mailto:t.broyer@gmail.com] >> *Sent:* Tuesday, July 29, 2014 5:43 PM >> *To:* Mike Jones >> *Cc:* ; George Fletcher; Phil Hunt >> *Subject:* RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth >> Token Introspection" as an OAuth Working Group Item >> >> >> >> Decoding a token with a specific format wouldn't tell you whether the >> token is still live: it could have been revoked before its expiration. >> >> Le 30 juil. 2014 02:16, "Mike Jones" a >> =C3=A9crit : >> >> Did you consider standardizing the access token format within that >> deployment so all the parties that needed to could understand it, rather >> requiring an extra round trip to an introspection endpoint so as to be a= ble >> to understand things about it? >> >> >> >> I realize that might or might not be practical in some cases, but I >> haven=E2=80=99t heard that alternative discussed, so I thought I=E2=80= =99d bring it up. >> >> >> >> I also second Phil=E2=80=99s comment that it would be good to understand= the use >> cases that this is intended to solve before embarking on a particular >> solution path. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George >> Fletcher >> *Sent:* Tuesday, July 29, 2014 3:25 PM >> *To:* Phil Hunt; Thomas Broyer >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth >> Token Introspection" as an OAuth Working Group Item >> >> >> >> We also have a use case where the AS is provided by a partner and the RS >> is provided by AOL. Being able to have a standardized way of validating = and >> getting data about the token from the AS would make our implementation m= uch >> simpler as we can use the same mechanism for all Authorization Servers a= nd >> not have to implement one off solutions for each AS. >> >> Thanks, >> George >> >> On 7/28/14, 8:11 PM, Phil Hunt wrote: >> >> Could we have some discussion on the interop cases? >> >> >> >> Is it driven by scenarios where AS and resource are separate domains? Or >> may this be only of interest to specific protocols like UMA? >> >> >> >> From a technique principle, the draft is important and sound. I am just >> not there yet on the reasons for an interoperable standard. >> >> >> >> Phil >> >> >> On Jul 28, 2014, at 17:00, Thomas Broyer wrote: >> >> Yes. This spec is of special interest to the platform we're building >> for http://www.oasis-eu.org/ >> >> >> >> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig < >> hannes.tschofenig@gmx.net> wrote: >> >> Hi all, >> >> during the IETF #90 OAuth WG meeting, there was strong consensus in >> adopting the "OAuth Token Introspection" >> (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG >> work item. >> >> We would now like to verify the outcome of this call for adoption on the >> OAuth WG mailing list. Here is the link to the document: >> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >> >> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion >> as to the suitability of adopting this document as a WG work item, >> please send mail to the OAuth WG list indicating your opinion (Yes/No). >> >> The confirmation call for adoption will last until August 10, 2014. If >> you have issues/edits/comments on the document, please send these >> comments along to the list in your response to this Call for Adoption. >> >> Ciao >> Hannes & Derek >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> -- >> Thomas Broyer >> /t=C9=94.ma.b=CA=81wa.je/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > --001a1134de46c10a6204ff63e4d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

One issue with Mike's proposal is that all RSs receiving= the token would know all the scopes the token is valid for.

Imagine an app requesting access to scopes allowing it to se= e your bank balance and retrieve your wish lists from another RS. It'll= get it in the form of a Bearer token with those two scopes, and will use i= t at the wish list RS.
Now the wish list RS decodes the token and sees it grants access to your ba= nk balance. Because it's a bearer token, it now knows it can use it at = your bank and see your balance.
With opaque tokens and the introspection endpoint, the endpoint could just = tell the wish list RS the token is valid for it, without leaking the fact i= t's also valid at your bank.

I know there are better alternatives but they all involve mo= re complexity for the clients and/or RSs. You won't believe me if I'= ;d tell you how bad are some developers at their work. I've seen some s= ending their client secret as a parameter to the authorization endpoint and= all sort of other stupid things you'd never imagine a web dev to do. T= he OAuth dance is already too complex for many, so adding crypto (PoP) or, = e.g., asking them to manage distinct tokens per RS is not realizable in pra= ctice. Not now at least. And our platform goes live in one month from now a= nd we want to have an ecosystem of clients and resource servers.

When devs are lazy, wouldn't understand crypto, and trea= t security and privacy as an afterthought, an introspection endpoint is the= way to go.

Le 30 juil. 2014 03:17, "Phil Hunt" &l= t;phil.hunt@oracle.com> a = =C3=A9crit :
Mike's proposal may be sufficient for Thomas'= ; case given a small token lifetime.=C2=A0

The fed= erated cases may have other issues....

How does th= e RS know who issued the opaque token and what introspection point is autho= ritative?=C2=A0

I am not saying your spec is not the right answer. I am= just not prepared to limit functionality yet by adopting the draft until w= e have sufficient requirements understood.=C2=A0

Let the rest of us = catch up please.=C2=A0

Phil

On Jul 29, 2014, at 18:07, Justin Richer <jricher@mit.edu> = wrote:

=20 =20 =20 =20
So you want a service where the RS can call an HTTP endpoint to see if the token is alive or not? That sounds like an awesome idea! Very useful for a variety of use cases that people have already mentioned on that list. Maybe that service should respond in JSON with, say, { "active": true = } if it's still valid. That's a great start, and that should obvio= usly be MTI.

But while we're there, we probably want to know what else the token is for, since this service will probably know that, so let'= s add in the "scope" and "client_id" and whatever o= ther meta-information we have about the token. If this endpoint doesn'= t have that information? Well then, I guess it can't return it. So we need to make sure to be flexible about that while we define a common core set of semantics. Flexibility like that is very powerful and could be used in a variety of protocols and deployments across domains and vendors.

You know, this idea is sounding better and better. In fact, I'll do you one better. I think this is such a fantastic idea that I wrote it all down in RFC format:

http://tools.ietf.org/html/draft-richer-oauth-intro= spection-06

Glad to have you on board, Phil.

=C2=A0-- Justin

On 7/29/2014 9:02 PM, Phil Hunt wrote:
=20
I think one alternative to an introspection service is a revocation status service.=C2=A0

But it is often not needed if token lifetimes are small (minutes / session life) compared to the refresh token which might last much longer.=C2=A0

Again having info on the case helps explain the requirements of your case and we can tell what the best pattern is.=C2=A0

Phil

On Jul 29, 2014, at 17:55, Thomas Broyer <t.broyer@gmail.com> wrote:

Try it where? When you're the RS trying to determine whether you should accept the token or reject it?

Le 30 juil. 2014 02:49, "Mike Jon= es" <Michael.Jones@microsoft.com> a =C3=A9crit :

Yes, but that=E2=80=99s the simplest thing to determine = =E2=80=93 try the token and see whether it works or not.

=C2=A0<= /span>

From: Thomas Broyer [mailto:t.broyer@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: <oauth@ietf.org>; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection"= as an OAuth Working Group Item

=C2=A0

Decoding a token with a specific format wouldn't tell you whether the token is still live: it could have been revoked before its expiration.

Le 30 juil. 2014 02:16, "Mi= ke Jones" <Michael.Jones@microsoft.com> a =C3=A9crit :

D= id you consider standardizing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip to an introspection endpoint so as to be able to understand things about it?

= =C2=A0

I realize that might or might not be practical in some cases, but I haven=E2=80=99t heard that alternative discussed, so I thought I=E2=80=99d bring it up.

= =C2=A0

I also second Phil=E2=80=99s comment that it woul= d be good to understand the use cases that this is intended to solve before embarking on a particular solution path.

= =C2=A0

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

= =C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an= OAuth Working Group Item

=C2=A0

We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS.

Thanks,
George

On 7/28/14, 8:11 PM, Phil Hunt wrote:

Could we have some discussion on the interop cases?

=C2=A0

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

=C2=A0

From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard.=C2=A0<= /p>

=C2=A0

Phil


On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for=C2=A0http://www.oasis-eu.org/

=C2=A0

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.tx= t) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker= .ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014. =C2=A0= If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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



=C2=A0

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

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



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

=C2=A0



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

=20
--001a1134de46c10a6204ff63e4d7-- From nobody Wed Jul 30 00:45:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209641ABB33 for ; Wed, 30 Jul 2014 00:45:43 -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 CjXmgs3hCeFL for ; Wed, 30 Jul 2014 00:45:40 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F871ABB2F for ; Wed, 30 Jul 2014 00:45:40 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so756769wgh.8 for ; Wed, 30 Jul 2014 00:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=jv8Oo0hTXbih7xpK0/PgK7X6ukxN43vSo4zeDvyyRZk=; b=MW0qUIgpE0+VhRNQ0hdQlde3v5NMJKQjaXdM8vhmKv6thPBMdKbCeL5n6HJC3sPdhk cS0tgCnHxLEpnSdL62gHCRHY3oaVZjHgv6Urm8hzgfOP5R6WuQPdp6aBH9FeKGjpCuKA UfEPpPL/gzP6ZFLrMkF6urMBw2WfMydWLH9XPNr1foeTUldh3/pZuuMXNhO+iKrlFa8+ JnVNA4eXSozC1f2RPkoNDykLqh4KpnOvaNjwaSl99CZWigTfx/ETlDnvigE8yiZKqPqd t1k+KZXmxvcz9LFdGbn6rykShiKIlhmBMHoTEdLSZ/GhTdJDeZ0o6XyLTEbeILNanJ1Z krQA== X-Received: by 10.180.186.3 with SMTP id fg3mr4325628wic.78.1406706339246; Wed, 30 Jul 2014 00:45:39 -0700 (PDT) Received: from [10.39.0.31] ([87.252.227.100]) by mx.google.com with ESMTPSA id dj2sm52450360wib.11.2014.07.30.00.45.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 00:45:38 -0700 (PDT) Message-ID: <53D8A2A0.5040205@gmail.com> Date: Wed, 30 Jul 2014 10:45:36 +0300 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: oauth@ietf.org References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <53D841D3.6020505@mit.edu> <311A2204-E968-4657-BD27-58DCD072542A@oracle.com> In-Reply-To: <311A2204-E968-4657-BD27-58DCD072542A@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/MhEFUvcnHByeXeWialdJrRzd7uA Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 07:45:43 -0000 +1. I've understood from what Justin said the idea is to introduce a standard way for RS to communicate to AS about the tokens issued by the AS. I think it is a good idea, I'd only not focus on the RS-to-3rd party AS communications because it complicates it a bit. Clearly it would be of help to implementers of OAuth2 filters protecting RS, having a new lengthy process to collect the cases seems to be a very administrative idea to me Thanks, Sergey On 30/07/14 03:54, Phil Hunt wrote: > -100 > > Phil > > On Jul 29, 2014, at 17:52, Justin Richer > wrote: > >> Reading through this thread, it appears very clear to me that the use >> cases are very well established by a number of existing implementers >> who want to work together to build a common standard. I see no reason >> to delay the work artificially by creating a use case document when >> such a vast array of understanding and interest already exists. Any >> use cases and explanations of applications are welcome to be added to >> the working group draft as it progresses. >> >> -- Justin >> >> >> On 7/29/2014 8:16 PM, Mike Jones wrote: >>> >>> Did you consider standardizing the access token format within that >>> deployment so all the parties that needed to could understand it, >>> rather requiring an extra round trip to an introspection endpoint so >>> as to be able to understand things about it? >>> >>> I realize that might or might not be practical in some cases, but I >>> haven’t heard that alternative discussed, so I thought I’d bring it up. >>> >>> I also second Phil’s comment that it would be good to understand the >>> use cases that this is intended to solve before embarking on a >>> particular solution path. >>> >>> -- Mike >>> >>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George >>> Fletcher >>> *Sent:* Tuesday, July 29, 2014 3:25 PM >>> *To:* Phil Hunt; Thomas Broyer >>> *Cc:* oauth@ietf.org >>> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth >>> Token Introspection" as an OAuth Working Group Item >>> >>> We also have a use case where the AS is provided by a partner and the >>> RS is provided by AOL. Being able to have a standardized way of >>> validating and getting data about the token from the AS would make >>> our implementation much simpler as we can use the same mechanism for >>> all Authorization Servers and not have to implement one off solutions >>> for each AS. >>> >>> Thanks, >>> George >>> >>> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>> >>> Could we have some discussion on the interop cases? >>> >>> Is it driven by scenarios where AS and resource are separate >>> domains? Or may this be only of interest to specific protocols >>> like UMA? >>> >>> From a technique principle, the draft is important and sound. I >>> am just not there yet on the reasons for an interoperable standard. >>> >>> Phil >>> >>> >>> On Jul 28, 2014, at 17:00, Thomas Broyer >> > wrote: >>> >>> Yes. This spec is of special interest to the platform we're >>> building for http://www.oasis-eu.org/ >>> >>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>> >> > wrote: >>> >>> Hi all, >>> >>> during the IETF #90 OAuth WG meeting, there was strong >>> consensus in >>> adopting the "OAuth Token Introspection" >>> (draft-richer-oauth-introspection-06.txt) specification as an >>> OAuth WG >>> work item. >>> >>> We would now like to verify the outcome of this call for >>> adoption on the >>> OAuth WG mailing list. Here is the link to the document: >>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>> >>> If you did not hum at the IETF 90 OAuth WG meeting, and have >>> an opinion >>> as to the suitability of adopting this document as a WG work >>> item, >>> please send mail to the OAuth WG list indicating your opinion >>> (Yes/No). >>> >>> The confirmation call for adoption will last until August 10, >>> 2014. If >>> you have issues/edits/comments on the document, please send these >>> comments along to the list in your response to this Call for >>> Adoption. >>> >>> Ciao >>> Hannes & Derek >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> -- >>> Thomas Broyer >>> /tÉ”.ma.bÊwa.je/ >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Wed Jul 30 00:49:34 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694881B2933 for ; Wed, 30 Jul 2014 00:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 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, URI_NOVOWEL=0.5] 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 HDVKvI8vapgV for ; Wed, 30 Jul 2014 00:49:31 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E2F1ABB33 for ; Wed, 30 Jul 2014 00:49:30 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so7036381wib.2 for ; Wed, 30 Jul 2014 00:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=pAa826UacKyHp1y9k8eS89mWhd/sU8e+sBZjCIjb+wU=; b=b1uuptToNlMLKJFSdDolM3jPifRVhR1unlpj8LvCmG6gEbo+ia2y1glW5oMEbHan// mXMLJDH4+yn6ZZSK0KJUPVX1bntBIUuUeknBE09F9UlZoS8/1XJFswPcsB1xjIymyEW+ O5S5KuzWBnZzA0I+imwbFXMmfOy5+Q4YC5/joXv3i5/qE+BtjmEWoaQtzUiHLbzRn3JF yvFJjYP/EC+xWCxPc/0AQqKm67ZN68H3GhYJIG2thx7cdYxBKpR8YvMyhxUIhak+sU4i gYjBjXFXsZDNm8LOgqw/RPnQg+NoCK1nmG2snvEzRLZGllL0AOYvDdGOeCZJdiHK8Sgi XUfQ== X-Received: by 10.180.12.79 with SMTP id w15mr4346422wib.35.1406706568963; Wed, 30 Jul 2014 00:49:28 -0700 (PDT) Received: from [10.39.0.31] ([87.252.227.100]) by mx.google.com with ESMTPSA id 20sm3547828wjt.42.2014.07.30.00.49.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 00:49:28 -0700 (PDT) Message-ID: <53D8A386.6010309@gmail.com> Date: Wed, 30 Jul 2014 10:49:26 +0300 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: oauth@ietf.org References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> <5C8461F3-CD04-4F5E-9BDF-6E91336D5F50@oracle.com> <53D8455B.1030303@mit.edu> <2E4485F3-8283-40E9-930E-53D149F2D5AA@xmlgrrl.com> In-Reply-To: <2E4485F3-8283-40E9-930E-53D149F2D5AA@xmlgrrl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2qo-2ISzp6QKoWYkvjEAQqmD3vE Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 07:49:33 -0000 On 30/07/14 04:45, Eve Maler wrote: > I would say that if an RS and AS are relatively tightly coupled and have > established their trust "off stage", then the RS will know where to go > and how to interpret the results. +1. It is an obvious answer, there has to be a trust established between RS and AS. let me ask Phil: How does RS know today, when it asks AS to return the info about a given token that the AS endpoint is authoritative ? Thanks, Sergey > If an RS and AS are entirely loosely > coupled, then there are a number of options for trust establishment for > which UMA provides one solution, leveraging an OAuth-protected token > introspection endpoint and an endpoint discovery mechanism. > > (BTW, I first wrote about this usage of token introspection on this list > in November 2012 > , > where I distinguished "shallow" and "deep" options for RS/AS communication.) > > Eve > > On 29 Jul 2014, at 6:17 PM, Phil Hunt > wrote: > >> Mike's proposal may be sufficient for Thomas' case given a small token >> lifetime. >> >> The federated cases may have other issues.... >> >> How does the RS know who issued the opaque token and what >> introspection point is authoritative? >> >> I am not saying your spec is not the right answer. I am just not >> prepared to limit functionality yet by adopting the draft until we >> have sufficient requirements understood. >> >> Let the rest of us catch up please. >> >> Phil >> >> On Jul 29, 2014, at 18:07, Justin Richer > > wrote: >> >>> So you want a service where the RS can call an HTTP endpoint to see >>> if the token is alive or not? That sounds like an awesome idea! Very >>> useful for a variety of use cases that people have already mentioned >>> on that list. Maybe that service should respond in JSON with, say, { >>> "active": true } if it's still valid. That's a great start, and that >>> should obviously be MTI. >>> >>> But while we're there, we probably want to know what else the token >>> is for, since this service will probably know that, so let's add in >>> the "scope" and "client_id" and whatever other meta-information we >>> have about the token. If this endpoint doesn't have that information? >>> Well then, I guess it can't return it. So we need to make sure to be >>> flexible about that while we define a common core set of semantics. >>> Flexibility like that is very powerful and could be used in a variety >>> of protocols and deployments across domains and vendors. >>> >>> You know, this idea is sounding better and better. In fact, I'll do >>> you one better. I think this is such a fantastic idea that I wrote it >>> all down in RFC format: >>> >>> http://tools.ietf.org/html/draft-richer-oauth-introspection-06 >>> >>> Glad to have you on board, Phil. >>> >>> -- Justin >>> >>> On 7/29/2014 9:02 PM, Phil Hunt wrote: >>>> I think one alternative to an introspection service is a revocation >>>> status service. >>>> >>>> But it is often not needed if token lifetimes are small (minutes / >>>> session life) compared to the refresh token which might last much >>>> longer. >>>> >>>> Again having info on the case helps explain the requirements of your >>>> case and we can tell what the best pattern is. >>>> >>>> Phil >>>> >>>> On Jul 29, 2014, at 17:55, Thomas Broyer >>> > wrote: >>>> >>>>> Try it where? When you're the RS trying to determine whether you >>>>> should accept the token or reject it? >>>>> >>>>> Le 30 juil. 2014 02:49, "Mike Jones" >>>> > a écrit : >>>>> >>>>> Yes, but that’s the simplest thing to determine – try the token >>>>> and see whether it works or not. >>>>> >>>>> >>>>> *From:*Thomas Broyer [mailto:t.broyer@gmail.com >>>>> ] >>>>> *Sent:* Tuesday, July 29, 2014 5:43 PM >>>>> *To:* Mike Jones >>>>> *Cc:* >; George >>>>> Fletcher; Phil Hunt >>>>> *Subject:* RE: [OAUTH-WG] Confirmation: Call for Adoption of >>>>> "OAuth Token Introspection" as an OAuth Working Group Item >>>>> >>>>> >>>>> Decoding a token with a specific format wouldn't tell you >>>>> whether the token is still live: it could have been revoked >>>>> before its expiration. >>>>> >>>>> Le 30 juil. 2014 02:16, "Mike Jones" >>>>> >>>> > a écrit : >>>>> >>>>> Did you consider standardizing the access token format within >>>>> that deployment so all the parties that needed to could >>>>> understand it, rather requiring an extra round trip to an >>>>> introspection endpoint so as to be able to understand things >>>>> about it? >>>>> >>>>> >>>>> I realize that might or might not be practical in some cases, >>>>> but I haven’t heard that alternative discussed, so I thought >>>>> I’d bring it up. >>>>> >>>>> >>>>> I also second Phil’s comment that it would be good to >>>>> understand the use cases that this is intended to solve before >>>>> embarking on a particular solution path. >>>>> >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org >>>>> ] *On Behalf Of *George Fletcher >>>>> *Sent:* Tuesday, July 29, 2014 3:25 PM >>>>> *To:* Phil Hunt; Thomas Broyer >>>>> *Cc:* oauth@ietf.org >>>>> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of >>>>> "OAuth Token Introspection" as an OAuth Working Group Item >>>>> >>>>> >>>>> We also have a use case where the AS is provided by a partner >>>>> and the RS is provided by AOL. Being able to have a >>>>> standardized way of validating and getting data about the token >>>>> from the AS would make our implementation much simpler as we >>>>> can use the same mechanism for all Authorization Servers and >>>>> not have to implement one off solutions for each AS. >>>>> >>>>> Thanks, >>>>> George >>>>> >>>>> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>>>> >>>>> Could we have some discussion on the interop cases? >>>>> >>>>> >>>>> Is it driven by scenarios where AS and resource are >>>>> separate domains? Or may this be only of interest to >>>>> specific protocols like UMA? >>>>> >>>>> >>>>> From a technique principle, the draft is important and >>>>> sound. I am just not there yet on the reasons for an >>>>> interoperable standard. >>>>> >>>>> >>>>> Phil >>>>> >>>>> >>>>> On Jul 28, 2014, at 17:00, Thomas Broyer >>>>> > wrote: >>>>> >>>>> Yes. This spec is of special interest to the platform >>>>> we're building for http://www.oasis-eu.org/ >>>>> >>>>> >>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>>> >>>> > wrote: >>>>> >>>>> Hi all, >>>>> >>>>> during the IETF #90 OAuth WG meeting, there was strong >>>>> consensus in >>>>> adopting the "OAuth Token Introspection" >>>>> (draft-richer-oauth-introspection-06.txt) specification >>>>> as an OAuth WG >>>>> work item. >>>>> >>>>> We would now like to verify the outcome of this call >>>>> for adoption on the >>>>> OAuth WG mailing list. Here is the link to the document: >>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>>> >>>>> If you did not hum at the IETF 90 OAuth WG meeting, and >>>>> have an opinion >>>>> as to the suitability of adopting this document as a WG >>>>> work item, >>>>> please send mail to the OAuth WG list indicating your >>>>> opinion (Yes/No). >>>>> >>>>> The confirmation call for adoption will last until >>>>> August 10, 2014. If >>>>> you have issues/edits/comments on the document, please >>>>> send these >>>>> comments along to the list in your response to this >>>>> Call for Adoption. >>>>> >>>>> Ciao >>>>> Hannes & Derek >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Broyer >>>>> /tÉ”.ma.bÊwa.je/ >>>>> >>>>> _______________________________________________ >>>>> 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 > > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Wed Jul 30 01:28:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EF41AD62C for ; Wed, 30 Jul 2014 01:28:38 -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 bMalfkhquEom for ; Wed, 30 Jul 2014 01:28:36 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6F31A0ADD for ; Wed, 30 Jul 2014 01:28:36 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so7054652wiv.13 for ; Wed, 30 Jul 2014 01:28:34 -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=dhba6lm3H9L7GkKnowYBAnSBKy+tqq7To+0s0+O63xE=; b=dX9JX3wuDgGVurK29PNEM+4PYik7VO5DHAaXJJzVxtjWtB3exUCqIIjmzpF1sPgweh bm0NQMPB5Oigv1Zjc3DyrFoVB7TwLA2JtUq5ghrKvaBBdqoyBKw2DClXmUr65lhDSYkU rWPKF1zp1u251OwzUyk/beNfS1A502WIGTV+YMTEKBhmn+Rvq+6aBRsFGRbs2f4H6dUm zgesc+l8j5jalc6OeLCYTnCdxBcVF09IonjbGYrcyCUEt0KCiwTmTl6LUbNpX4U3vlDh IvJ3tQ+EnKhLOdiLtjOmm3cUhcNkd8IAuHDsHkfhWbOn6zYHeLnqHIP9tCqdxe/QO5yT PDsw== MIME-Version: 1.0 X-Received: by 10.180.98.196 with SMTP id ek4mr3730273wib.13.1406708914644; Wed, 30 Jul 2014 01:28:34 -0700 (PDT) Received: by 10.216.158.195 with HTTP; Wed, 30 Jul 2014 01:28:34 -0700 (PDT) In-Reply-To: <53D69D2A.2020908@gmail.com> References: <53D68967.7000206@gmx.net> <53D69D2A.2020908@gmail.com> Date: Wed, 30 Jul 2014 01:28:34 -0700 Message-ID: From: Naveen Agarwal To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=f46d044303dc294af604ff64f16a Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/RmF5maKEb91krvQ8zC_80h81A98 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Symmetric Proof of Posession for Code Extension" as an OAuth Working Group Item 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, 30 Jul 2014 08:28:38 -0000 --f46d044303dc294af604ff64f16a Content-Type: text/plain; charset=UTF-8 Yes, I support WG taking this on. On Mon, Jul 28, 2014 at 11:57 AM, Paul Madsen wrote: > I support the WG taking this on > > On 7/28/14, 1:33 PM, Hannes Tschofenig wrote: > > Hi all, > > during the IETF #90 OAuth WG meeting, there was strong consensus in > adopting the "OAuth Symmetric Proof of Posession for Code Extension" > (draft-sakimura-oauth-tcse-03.txt) specification as an OAuth WG work item. > > We would now like to verify the outcome of this call for adoption on the > OAuth WG mailing list. Here is the link to the document:http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ > > If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion > as to the suitability of adopting this document as a WG work item, > please send mail to the OAuth WG list indicating your opinion (Yes/No). > > The confirmation call for adoption will last until August 10, 2014. If > you have issues/edits/comments on the document, please send these > comments along to the list in your response to this Call for Adoption. > > Ciao > Hannes & Derek > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --f46d044303dc294af604ff64f16a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes, I support WG taking this on.


On Mon, Jul 28, 2= 014 at 11:57 AM, Paul Madsen <paul.madsen@gmail.com> wro= te:
=20 =20 =20
I support the WG taking this on<= br>
On 7/28/14, 1:33 PM, Hannes Tschofenig wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Symmetric Proof of Posession for Code Extension&qu=
ot;
(draft-sakimura-oauth-tcse-03.txt) specification as an OAuth WG work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek




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


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


--f46d044303dc294af604ff64f16a-- From nobody Wed Jul 30 04:42:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCBF1B2796 for ; Wed, 30 Jul 2014 04:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUsL8AIwnhVe for ; Wed, 30 Jul 2014 04:42:08 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71171B2794 for ; Wed, 30 Jul 2014 04:42:07 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id j5so1263289qga.1 for ; Wed, 30 Jul 2014 04:42:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=SDFUlkMMoZau58pGfFhoVKutN8h+0uBkQ28VX45HhHw=; b=XulTqzrcufUffIx9VTaoCNf4IaZJCr4ioX2YFAztRPyXCjYb9vbFnSXkFLYQ0CnkOS rYZ+C7WfY84QKzLQ92rjhcFLNO5BDo52Sm/1qkW3STNYMqJWoNAWIVm//LLssi6nywEB Z7pUDeGpOfMl3YxtdZb4kv0K6JKTL92W7AZVrJq8C+/XL6OreUSr1/l60gGDmDOdjDbq 50x3BAm0iRvvQx0EpTNiUrVoArqtxGXtDJkL3VLiTn4W03uU0E6szLq0QBK0ioT1+mvF q7Hsx0tukzb7PAIpPVeR/zWb2N9s9UJGGdFWGa3UabmFJ98oTDoWzk15VwEmXJ5jy18n Tt2Q== X-Gm-Message-State: ALoCoQl+ojShjUVyaKpUMPZislwIW23WuWHI2q8EHUJobDL42mUyLPcOUAKg9RQedfZudG6fSXgA X-Received: by 10.140.80.2 with SMTP id b2mr5329425qgd.75.1406720526737; Wed, 30 Jul 2014 04:42:06 -0700 (PDT) Received: from [192.168.1.37] ([190.22.79.243]) by mx.google.com with ESMTPSA id w91sm2252910qge.47.2014.07.30.04.42.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 04:42:04 -0700 (PDT) References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <53D841D3.6020505@mit.edu> <311A2204-E968-4657-BD27-58DCD072542A@oracle.com> <53D8A2A0.5040205@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <53D8A2A0.5040205@gmail.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-EEE71C32-2BE6-48C2-8374-7F89117A09C4; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <9AF95517-3415-4A3C-A2FB-3BBDFC49E218@ve7jtb.com> X-Mailer: iPad Mail (11D257) From: John Bradley Date: Wed, 30 Jul 2014 07:42:00 -0400 To: Sergey Beryozkin Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uS4o83RvOdRvkj3tj9FHmyIzWmo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 11:42:10 -0000 --Apple-Mail-EEE71C32-2BE6-48C2-8374-7F89117A09C4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This request for only those not at the F2F to add to the hum has gone a bit o= ff the rails.=20 For those not in the room there was discussion that the draft needed a metho= d to deal with: - Multiple AS - Supporting the PoP specs - stopping clients or other interceptors of the token from introspecting it.= Justin stated that his implementation already had a number of those features= .=20 I offered to help get those into the spec as part of my support for making t= his a WG item.=20 Yes if AS and RS are monolithic and there is only one software vendor, then t= his is not needed.=20 On the other hand there is evidence that is not the case.=20 John B.=20 Sent from my iPad > On Jul 30, 2014, at 3:45 AM, Sergey Beryozkin wrote= : >=20 > +1. >=20 > I've understood from what Justin said the idea is to introduce a standard w= ay for RS to communicate to AS about the tokens issued by the AS. I think it= is a good idea, I'd only not focus on the RS-to-3rd party AS communications= because it complicates it a bit. >=20 > Clearly it would be of help to implementers of OAuth2 filters protecting R= S, having a new lengthy process to collect the cases seems to be a very admi= nistrative idea to me >=20 > Thanks, Sergey >=20 >> On 30/07/14 03:54, Phil Hunt wrote: >> -100 >>=20 >> Phil >>=20 >> On Jul 29, 2014, at 17:52, Justin Richer > > wrote: >>=20 >>> Reading through this thread, it appears very clear to me that the use >>> cases are very well established by a number of existing implementers >>> who want to work together to build a common standard. I see no reason >>> to delay the work artificially by creating a use case document when >>> such a vast array of understanding and interest already exists. Any >>> use cases and explanations of applications are welcome to be added to >>> the working group draft as it progresses. >>>=20 >>> -- Justin >>>=20 >>>=20 >>>> On 7/29/2014 8:16 PM, Mike Jones wrote: >>>>=20 >>>> Did you consider standardizing the access token format within that >>>> deployment so all the parties that needed to could understand it, >>>> rather requiring an extra round trip to an introspection endpoint so >>>> as to be able to understand things about it? >>>>=20 >>>> I realize that might or might not be practical in some cases, but I >>>> haven=E2=80=99t heard that alternative discussed, so I thought I=E2=80=99= d bring it up. >>>>=20 >>>> I also second Phil=E2=80=99s comment that it would be good to understan= d the >>>> use cases that this is intended to solve before embarking on a >>>> particular solution path. >>>>=20 >>>> -- Mike >>>>=20 >>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George >>>> Fletcher >>>> *Sent:* Tuesday, July 29, 2014 3:25 PM >>>> *To:* Phil Hunt; Thomas Broyer >>>> *Cc:* oauth@ietf.org >>>> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth >>>> Token Introspection" as an OAuth Working Group Item >>>>=20 >>>> We also have a use case where the AS is provided by a partner and the >>>> RS is provided by AOL. Being able to have a standardized way of >>>> validating and getting data about the token from the AS would make >>>> our implementation much simpler as we can use the same mechanism for >>>> all Authorization Servers and not have to implement one off solutions >>>> for each AS. >>>>=20 >>>> Thanks, >>>> George >>>>=20 >>>> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>>>=20 >>>> Could we have some discussion on the interop cases? >>>>=20 >>>> Is it driven by scenarios where AS and resource are separate >>>> domains? Or may this be only of interest to specific protocols >>>> like UMA? >>>>=20 >>>> =46rom a technique principle, the draft is important and sound. I >>>> am just not there yet on the reasons for an interoperable standard. >>>>=20 >>>> Phil >>>>=20 >>>>=20 >>>> On Jul 28, 2014, at 17:00, Thomas Broyer >>> > wrote: >>>>=20 >>>> Yes. This spec is of special interest to the platform we're >>>> building for http://www.oasis-eu.org/ >>>>=20 >>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>> >>> > wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> during the IETF #90 OAuth WG meeting, there was strong >>>> consensus in >>>> adopting the "OAuth Token Introspection" >>>> (draft-richer-oauth-introspection-06.txt) specification as an >>>> OAuth WG >>>> work item. >>>>=20 >>>> We would now like to verify the outcome of this call for >>>> adoption on the >>>> OAuth WG mailing list. Here is the link to the document: >>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection= / >>>>=20 >>>> If you did not hum at the IETF 90 OAuth WG meeting, and have >>>> an opinion >>>> as to the suitability of adopting this document as a WG work >>>> item, >>>> please send mail to the OAuth WG list indicating your opinion >>>> (Yes/No). >>>>=20 >>>> The confirmation call for adoption will last until August 10, >>>> 2014. If >>>> you have issues/edits/comments on the document, please send thes= e >>>> comments along to the list in your response to this Call for >>>> Adoption. >>>>=20 >>>> Ciao >>>> Hannes & Derek >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Thomas Broyer >>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>>=20 >>>> OAuth mailing list >>>>=20 >>>> OAuth@ietf.org >>>>=20 >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-EEE71C32-2BE6-48C2-8374-7F89117A09C4 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDczMDExNDIwMVowIwYJKoZIhvcNAQkEMRYEFOlu xdjqM+DqB8WvY9LAhF1SiymLMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBACRHyaTi5tL4Nz/kwFwdf1gYzXm1FnHyh1+g +mmvoSVCo2nKhSevKkzyqQeT5ttqBxM9zAwLPhS4qvdhgFBO3qnX1WCR6Vs0+bjscwdSTCo+JTso 4k3seVDaBjJhrqOorga0jEISe4392LkrtKSx7UHOY3D/HsdMWKJ3Q1gYrW/5ES0Zxu5KnAi9VUzH rcifdQ1oyqKHcyQiDCbeoPaygqVtgBZK8IsnUSvsKnUUqrYJsPddghx7vXNW28T7DIFUTza1JxBK XxtBPeK7Zu+Ykxb5qmx+G35BTKKsRjvKH2MKDLFjQ+Bq609xLFyyN/6Xf/HxWm4xgjT9tY1rUapA tgMAAAAAAAA= --Apple-Mail-EEE71C32-2BE6-48C2-8374-7F89117A09C4-- From nobody Wed Jul 30 04:51:22 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0C31B27AD for ; Wed, 30 Jul 2014 04:51:19 -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 SJPHOIY_Q1WC for ; Wed, 30 Jul 2014 04:51:13 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCED1B27A2 for ; Wed, 30 Jul 2014 04:51:12 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so1052432wgh.3 for ; Wed, 30 Jul 2014 04:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=L1zAZ2uV/wY3RBTINb1klbVSxKOOKT5c05u4hwW6UmI=; b=HOlHF1SyKufqD3dlNa3LM76iE5GaUBWoLIlrc2AV40nQWzqNMeNEGu0r2xAWUoSaiI NxS+PnpvMUwVgukC7OjrgwgVDiRcyFk0vhGkvNNVUkUhgx2OokmGtsfvMBoC0SYc4zwI Qkax0wWG4BO7RUyLbPxjB41f1adXU1CFN848CU/67b4UD4YpGA3HkmN391pXFnZXT2Uj cs1cwKP5ymHhstNj3K4KvSf9rhXr88PdP60sFg/8fLZy5SMD86r6Ihs3WOaigps938Rl ZWiHvLZJsSqYGZTo3xBE17STLoaPQc2cEDTeGOTla4Fvqovp5adGAFK/GA9kYFtCetI1 +8UA== X-Received: by 10.194.57.132 with SMTP id i4mr5462464wjq.6.1406721069081; Wed, 30 Jul 2014 04:51:09 -0700 (PDT) Received: from [10.39.0.31] ([87.252.227.100]) by mx.google.com with ESMTPSA id fb8sm54577642wib.15.2014.07.30.04.51.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 04:51:08 -0700 (PDT) Message-ID: <53D8DC2A.6030503@gmail.com> Date: Wed, 30 Jul 2014 14:51:06 +0300 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Bradley References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <53D841D3.6020505@mit.edu> <311A2204-E968-4657-BD27-58DCD072542A@oracle.com> <53D8A2A0.5040205@gmail.com> <9AF95517-3415-4A3C-A2FB-3BBDFC49E218@ve7jtb.com> In-Reply-To: <9AF95517-3415-4A3C-A2FB-3BBDFC49E218@ve7jtb.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3tUZ1UWJCFy3L8fFHY6W2CwsvjE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 11:51:19 -0000 On 30/07/14 14:42, John Bradley wrote: > This request for only those not at the F2F to add to the hum has gone a bit off the rails. > Meaning you see too much feedback, is it bad, even if some of it may be off topic ? > For those not in the room there was discussion that the draft needed a method to deal with: > - Multiple AS > - Supporting the PoP specs > - stopping clients or other interceptors of the token from introspecting it. > > Justin stated that his implementation already had a number of those features. > > I offered to help get those into the spec as part of my support for making this a WG item. > > Yes if AS and RS are monolithic and there is only one software vendor, then this is not needed. Why not ? What is wrong with standardizing an introspection process which even RS & AS from the same vendor may want to use as opposed to every vendor inventing its own protocol ? This is why I thought focusing on the RS to 3rd party only diverts from the idea which I 'read' in the thread (may be I'm wrong), i.e, standardizing on the RS-to-AS communication, which may not have been considered, Cheers, Sergey > > On the other hand there is evidence that is not the case. > > John B. > > > Sent from my iPad > >> On Jul 30, 2014, at 3:45 AM, Sergey Beryozkin wrote: >> >> +1. >> >> I've understood from what Justin said the idea is to introduce a standard way for RS to communicate to AS about the tokens issued by the AS. I think it is a good idea, I'd only not focus on the RS-to-3rd party AS communications because it complicates it a bit. >> >> Clearly it would be of help to implementers of OAuth2 filters protecting RS, having a new lengthy process to collect the cases seems to be a very administrative idea to me >> >> Thanks, Sergey >> >>> On 30/07/14 03:54, Phil Hunt wrote: >>> -100 >>> >>> Phil >>> >>> On Jul 29, 2014, at 17:52, Justin Richer >> > wrote: >>> >>>> Reading through this thread, it appears very clear to me that the use >>>> cases are very well established by a number of existing implementers >>>> who want to work together to build a common standard. I see no reason >>>> to delay the work artificially by creating a use case document when >>>> such a vast array of understanding and interest already exists. Any >>>> use cases and explanations of applications are welcome to be added to >>>> the working group draft as it progresses. >>>> >>>> -- Justin >>>> >>>> >>>>> On 7/29/2014 8:16 PM, Mike Jones wrote: >>>>> >>>>> Did you consider standardizing the access token format within that >>>>> deployment so all the parties that needed to could understand it, >>>>> rather requiring an extra round trip to an introspection endpoint so >>>>> as to be able to understand things about it? >>>>> >>>>> I realize that might or might not be practical in some cases, but I >>>>> haven’t heard that alternative discussed, so I thought I’d bring it up. >>>>> >>>>> I also second Phil’s comment that it would be good to understand the >>>>> use cases that this is intended to solve before embarking on a >>>>> particular solution path. >>>>> >>>>> -- Mike >>>>> >>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George >>>>> Fletcher >>>>> *Sent:* Tuesday, July 29, 2014 3:25 PM >>>>> *To:* Phil Hunt; Thomas Broyer >>>>> *Cc:* oauth@ietf.org >>>>> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth >>>>> Token Introspection" as an OAuth Working Group Item >>>>> >>>>> We also have a use case where the AS is provided by a partner and the >>>>> RS is provided by AOL. Being able to have a standardized way of >>>>> validating and getting data about the token from the AS would make >>>>> our implementation much simpler as we can use the same mechanism for >>>>> all Authorization Servers and not have to implement one off solutions >>>>> for each AS. >>>>> >>>>> Thanks, >>>>> George >>>>> >>>>> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>>>> >>>>> Could we have some discussion on the interop cases? >>>>> >>>>> Is it driven by scenarios where AS and resource are separate >>>>> domains? Or may this be only of interest to specific protocols >>>>> like UMA? >>>>> >>>>> From a technique principle, the draft is important and sound. I >>>>> am just not there yet on the reasons for an interoperable standard. >>>>> >>>>> Phil >>>>> >>>>> >>>>> On Jul 28, 2014, at 17:00, Thomas Broyer >>>> > wrote: >>>>> >>>>> Yes. This spec is of special interest to the platform we're >>>>> building for http://www.oasis-eu.org/ >>>>> >>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>>> >>>> > wrote: >>>>> >>>>> Hi all, >>>>> >>>>> during the IETF #90 OAuth WG meeting, there was strong >>>>> consensus in >>>>> adopting the "OAuth Token Introspection" >>>>> (draft-richer-oauth-introspection-06.txt) specification as an >>>>> OAuth WG >>>>> work item. >>>>> >>>>> We would now like to verify the outcome of this call for >>>>> adoption on the >>>>> OAuth WG mailing list. Here is the link to the document: >>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>>> >>>>> If you did not hum at the IETF 90 OAuth WG meeting, and have >>>>> an opinion >>>>> as to the suitability of adopting this document as a WG work >>>>> item, >>>>> please send mail to the OAuth WG list indicating your opinion >>>>> (Yes/No). >>>>> >>>>> The confirmation call for adoption will last until August 10, >>>>> 2014. If >>>>> you have issues/edits/comments on the document, please send these >>>>> comments along to the list in your response to this Call for >>>>> Adoption. >>>>> >>>>> Ciao >>>>> Hannes & Derek >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Broyer >>>>> /tÉ”.ma.bÊwa.je/ >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> OAuth mailing list >>>>> >>>>> OAuth@ietf.org >>>>> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Jul 30 05:00:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9DF1B279E for ; Wed, 30 Jul 2014 05:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXY_t8CDtmoC for ; Wed, 30 Jul 2014 05:00:12 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F8E1B279D for ; Wed, 30 Jul 2014 05:00:11 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id a108so1298337qge.10 for ; Wed, 30 Jul 2014 05:00:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=D4eWNhQ1fDSE/EIUZ3GhtljFipidGqBPxLLmUsFONZI=; b=mu6lZVNJKRHNbnoVK3Dwh6QIP6Ai0bUiEfJQYS1ZsDX/A+6mmlxaoBO3XIxjDY6/9i Q57stfvAptVvfb7Et57DnCZTM/fvVADwmQ8M3owHzx3FYGKnt0OHVSv38OlNOGK1j0+h 4/UR4Sz2yKm04NZB/ZEptie/C53dwubsvP7q4XSKcqJaOCJw0E9/ld2GwWjee3lfZ3rk EytmSsGv0cbcEI8OE0UBDYLGOz0YMtI9M35ywWp6EpT4biYzEhzWaJ6fAlxI9xJ4lBpp gAvZ4yeLB5wGIUpbv+sZG1ThVnj0whvTI1S9dj+71QJvHT7+jUbGvK/k2ntZHd7d1nik Xtag== X-Gm-Message-State: ALoCoQnpptamzK9UzkO08G3b5W3Cj6+e/q2PafEJT8eU0utAPNu4nURF5RglaCLKDOKiBjI8hVTR X-Received: by 10.140.104.138 with SMTP id a10mr3475487qgf.19.1406721610841; Wed, 30 Jul 2014 05:00:10 -0700 (PDT) Received: from [192.168.1.47] ([190.22.79.243]) by mx.google.com with ESMTPSA id c6sm3673765qag.36.2014.07.30.05.00.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 05:00:09 -0700 (PDT) References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <53D841D3.6020505@mit.edu> <311A2204-E968-4657-BD27-58DCD072542A@oracle.com> <53D8A2A0.5040205@gmail.com> <9AF95517-3415-4A3C-A2FB-3BBDFC49E218@ve7jtb.com> <53D8DC2A.6030503@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <53D8DC2A.6030503@gmail.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-BA1FB667-BDBE-49EF-BBF9-066E7C931826; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <7189BB03-0962-4B62-A82B-052E70B0A7DF@ve7jtb.com> X-Mailer: iPhone Mail (11D257) From: John Bradley Date: Wed, 30 Jul 2014 07:59:56 -0400 To: Sergey Beryozkin Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/EvWIWHPGJ83L2gSYNq4bCKu8uFk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 12:00:14 -0000 --Apple-Mail-BA1FB667-BDBE-49EF-BBF9-066E7C931826 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable No, that those of us who we're fallowing the instructions not to comment if= our hum was recorded in the room, should not hold back given the nature of t= he thread has changed.=20 It was also an indication to the char that the original intent of the thread= to judge consensus is impacted by some people who previously hummed piling o= n the thread.=20 I am more than fine with discussion. It probably should have been a differe= nt thread though. John B.=20 Sent from my iPhone > On Jul 30, 2014, at 7:51 AM, Sergey Beryozkin wrote= : >=20 >> On 30/07/14 14:42, John Bradley wrote: >> This request for only those not at the F2F to add to the hum has gone a b= it off the rails. > Meaning you see too much feedback, is it bad, even if some of it may be of= f topic ? >> For those not in the room there was discussion that the draft needed a me= thod to deal with: >> - Multiple AS >> - Supporting the PoP specs >> - stopping clients or other interceptors of the token from introspecting i= t. >>=20 >> Justin stated that his implementation already had a number of those featu= res. >>=20 >> I offered to help get those into the spec as part of my support for makin= g this a WG item. >>=20 >> Yes if AS and RS are monolithic and there is only one software vendor, th= en this is not needed. > Why not ? What is wrong with standardizing an introspection process which e= ven RS & AS from the same vendor may want to use as opposed to every vendor i= nventing its own protocol ? >=20 > This is why I thought focusing on the RS to 3rd party only diverts from th= e idea which I 'read' in the thread (may be I'm wrong), i.e, standardizing o= n the RS-to-AS communication, which may not have been considered, >=20 > Cheers, Sergey >=20 >>=20 >> On the other hand there is evidence that is not the case. >>=20 >> John B. >>=20 >>=20 >> Sent from my iPad >>=20 >>> On Jul 30, 2014, at 3:45 AM, Sergey Beryozkin wro= te: >>>=20 >>> +1. >>>=20 >>> I've understood from what Justin said the idea is to introduce a standar= d way for RS to communicate to AS about the tokens issued by the AS. I think= it is a good idea, I'd only not focus on the RS-to-3rd party AS communicati= ons because it complicates it a bit. >>>=20 >>> Clearly it would be of help to implementers of OAuth2 filters protecting= RS, having a new lengthy process to collect the cases seems to be a very ad= ministrative idea to me >>>=20 >>> Thanks, Sergey >>>=20 >>>> On 30/07/14 03:54, Phil Hunt wrote: >>>> -100 >>>>=20 >>>> Phil >>>>=20 >>>> On Jul 29, 2014, at 17:52, Justin Richer >>> > wrote: >>>>=20 >>>>> Reading through this thread, it appears very clear to me that the use >>>>> cases are very well established by a number of existing implementers >>>>> who want to work together to build a common standard. I see no reason >>>>> to delay the work artificially by creating a use case document when >>>>> such a vast array of understanding and interest already exists. Any >>>>> use cases and explanations of applications are welcome to be added to >>>>> the working group draft as it progresses. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>>=20 >>>>>> On 7/29/2014 8:16 PM, Mike Jones wrote: >>>>>>=20 >>>>>> Did you consider standardizing the access token format within that >>>>>> deployment so all the parties that needed to could understand it, >>>>>> rather requiring an extra round trip to an introspection endpoint so >>>>>> as to be able to understand things about it? >>>>>>=20 >>>>>> I realize that might or might not be practical in some cases, but I >>>>>> haven=E2=80=99t heard that alternative discussed, so I thought I=E2=80= =99d bring it up. >>>>>>=20 >>>>>> I also second Phil=E2=80=99s comment that it would be good to underst= and the >>>>>> use cases that this is intended to solve before embarking on a >>>>>> particular solution path. >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George >>>>>> Fletcher >>>>>> *Sent:* Tuesday, July 29, 2014 3:25 PM >>>>>> *To:* Phil Hunt; Thomas Broyer >>>>>> *Cc:* oauth@ietf.org >>>>>> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth >>>>>> Token Introspection" as an OAuth Working Group Item >>>>>>=20 >>>>>> We also have a use case where the AS is provided by a partner and the= >>>>>> RS is provided by AOL. Being able to have a standardized way of >>>>>> validating and getting data about the token from the AS would make >>>>>> our implementation much simpler as we can use the same mechanism for >>>>>> all Authorization Servers and not have to implement one off solutions= >>>>>> for each AS. >>>>>>=20 >>>>>> Thanks, >>>>>> George >>>>>>=20 >>>>>> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>>>>>=20 >>>>>> Could we have some discussion on the interop cases? >>>>>>=20 >>>>>> Is it driven by scenarios where AS and resource are separate >>>>>> domains? Or may this be only of interest to specific protocols >>>>>> like UMA? >>>>>>=20 >>>>>> =46rom a technique principle, the draft is important and sound. I >>>>>> am just not there yet on the reasons for an interoperable standard= . >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>>=20 >>>>>> On Jul 28, 2014, at 17:00, Thomas Broyer >>>>> > wrote: >>>>>>=20 >>>>>> Yes. This spec is of special interest to the platform we're >>>>>> building for http://www.oasis-eu.org/ >>>>>>=20 >>>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>>>> >>>>> > wrote: >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> during the IETF #90 OAuth WG meeting, there was strong >>>>>> consensus in >>>>>> adopting the "OAuth Token Introspection" >>>>>> (draft-richer-oauth-introspection-06.txt) specification as an >>>>>> OAuth WG >>>>>> work item. >>>>>>=20 >>>>>> We would now like to verify the outcome of this call for >>>>>> adoption on the >>>>>> OAuth WG mailing list. Here is the link to the document: >>>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspecti= on/ >>>>>>=20 >>>>>> If you did not hum at the IETF 90 OAuth WG meeting, and have >>>>>> an opinion >>>>>> as to the suitability of adopting this document as a WG work >>>>>> item, >>>>>> please send mail to the OAuth WG list indicating your opinion >>>>>> (Yes/No). >>>>>>=20 >>>>>> The confirmation call for adoption will last until August 10, >>>>>> 2014. If >>>>>> you have issues/edits/comments on the document, please send th= ese >>>>>> comments along to the list in your response to this Call for >>>>>> Adoption. >>>>>>=20 >>>>>> Ciao >>>>>> Hannes & Derek >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Thomas Broyer >>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>>=20 >>>>>> OAuth mailing list >>>>>>=20 >>>>>> OAuth@ietf.org >>>>>>=20 >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-BA1FB667-BDBE-49EF-BBF9-066E7C931826 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwNzMwMTE1OTU3WjAjBgkqhkiG9w0BCQQxFgQUTWQKgHt3vK2Fe2c7 smkGDnoZK0swgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAGM53WoO83AA4ojFI55mDLT3jL1DgZerOxbWjl43lihwKfQCi NUw1SosdsdsSnrwplO/7PCfL0PYx0W6hoiqFPe9eC5fT9cl6kwaeTaz3LhzO0blJayYP12rbS886 e6qg5o6SYYUxJu6lnrb9bs1566f7LdjxDoQ5krxrp04u1etQR9bMFcNZDYx+5FiYfYg2i1y+zotd VawLUbN6MUHac83xLx7Yc1f4NskUOfH/t5ILrOTWXdyeEoPM/nc9JchGh50M5T189yW3J9MwCJ9n E9a21TK4oN4vVN8qxgD3+ONRXgJLGs0QOyVKfkMRU51/zI78o6O+D/6cnLdTbjeSlAAAAAAAAA== --Apple-Mail-BA1FB667-BDBE-49EF-BBF9-066E7C931826-- From nobody Wed Jul 30 05:05:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEB71B27A2 for ; Wed, 30 Jul 2014 05:05:27 -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 HAuFa-ZgXu_r for ; Wed, 30 Jul 2014 05:05:24 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E281B1B279E for ; Wed, 30 Jul 2014 05:05:23 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so7463744wiw.0 for ; Wed, 30 Jul 2014 05:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ikRdaQkhsraqN491VM7RQNTDFNeQQZE9AVoHkIPbnb0=; b=ci4OENVWM1nI/XsWYvXSAINad0MyTIcMIyD725QP/GAVPQr1mQDIQqAMpwSM7eyeYB yTRfNhqJH/nX8VFHFMRXDgOOjMkU+Q0JmJJgHhlUK9csf7GTgU+UtbDg7GKCsuttD2eD pVyTE+C+ZsH8fzFzYEYb/ua66vKVCilZOR3u/OX7ejQDJedeL5SQusXDYZ82ITThp8zr 9/kuE724f5EFmiUbniMz5UHt+Ok0N5ZiMqV9NuRCdMKQr5fHo1wBnv5yE717pQSG9SDg fwQ3MAwNqroAm8IunCCeBd1HmbhUr3VXehmZ59roXZmp9qFXXo4qESBBB3+2EgqpCpXo 7rpA== X-Received: by 10.194.202.165 with SMTP id kj5mr5796009wjc.50.1406721922575; Wed, 30 Jul 2014 05:05:22 -0700 (PDT) Received: from [10.39.0.31] ([87.252.227.100]) by mx.google.com with ESMTPSA id gl4sm1156055wib.19.2014.07.30.05.05.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 05:05:21 -0700 (PDT) Message-ID: <53D8DF80.4010301@gmail.com> Date: Wed, 30 Jul 2014 15:05:20 +0300 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Bradley References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <53D841D3.6020505@mit.edu> <311A2204-E968-4657-BD27-58DCD072542A@oracle.com> <53D8A2A0.5040205@gmail.com> <9AF95517-3415-4A3C-A2FB-3BBDFC49E218@ve7jtb.com> <53D8DC2A.6030503@gmail.com> <7189BB03-0962-4B62-A82B-052E70B0A7DF@ve7jtb.com> In-Reply-To: <7189BB03-0962-4B62-A82B-052E70B0A7DF@ve7jtb.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/oDLlBbopzzoiQVay94MwkksT6io Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 12:05:27 -0000 Hi John On 30/07/14 14:59, John Bradley wrote: > No, that those of us who we're fallowing the instructions not to comment if our hum was recorded in the room, should not hold back given the nature of the thread has changed. > > It was also an indication to the char that the original intent of the thread to judge consensus is impacted by some people who previously hummed piling on the thread. > I think I understand, thanks for the clarifications, though it appears to be more subtle to me that various OAuth2 technical ambiguities :-) > I am more than fine with discussion. It probably should have been a different thread though. > Thanks, sorry for the noise anyway Sergey > John B. > Sent from my iPhone > >> On Jul 30, 2014, at 7:51 AM, Sergey Beryozkin wrote: >> >>> On 30/07/14 14:42, John Bradley wrote: >>> This request for only those not at the F2F to add to the hum has gone a bit off the rails. >> Meaning you see too much feedback, is it bad, even if some of it may be off topic ? >>> For those not in the room there was discussion that the draft needed a method to deal with: >>> - Multiple AS >>> - Supporting the PoP specs >>> - stopping clients or other interceptors of the token from introspecting it. >>> >>> Justin stated that his implementation already had a number of those features. >>> >>> I offered to help get those into the spec as part of my support for making this a WG item. >>> >>> Yes if AS and RS are monolithic and there is only one software vendor, then this is not needed. >> Why not ? What is wrong with standardizing an introspection process which even RS & AS from the same vendor may want to use as opposed to every vendor inventing its own protocol ? >> >> This is why I thought focusing on the RS to 3rd party only diverts from the idea which I 'read' in the thread (may be I'm wrong), i.e, standardizing on the RS-to-AS communication, which may not have been considered, >> >> Cheers, Sergey >> >>> >>> On the other hand there is evidence that is not the case. >>> >>> John B. >>> >>> >>> Sent from my iPad >>> >>>> On Jul 30, 2014, at 3:45 AM, Sergey Beryozkin wrote: >>>> >>>> +1. >>>> >>>> I've understood from what Justin said the idea is to introduce a standard way for RS to communicate to AS about the tokens issued by the AS. I think it is a good idea, I'd only not focus on the RS-to-3rd party AS communications because it complicates it a bit. >>>> >>>> Clearly it would be of help to implementers of OAuth2 filters protecting RS, having a new lengthy process to collect the cases seems to be a very administrative idea to me >>>> >>>> Thanks, Sergey >>>> >>>>> On 30/07/14 03:54, Phil Hunt wrote: >>>>> -100 >>>>> >>>>> Phil >>>>> >>>>> On Jul 29, 2014, at 17:52, Justin Richer >>>> > wrote: >>>>> >>>>>> Reading through this thread, it appears very clear to me that the use >>>>>> cases are very well established by a number of existing implementers >>>>>> who want to work together to build a common standard. I see no reason >>>>>> to delay the work artificially by creating a use case document when >>>>>> such a vast array of understanding and interest already exists. Any >>>>>> use cases and explanations of applications are welcome to be added to >>>>>> the working group draft as it progresses. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>>> On 7/29/2014 8:16 PM, Mike Jones wrote: >>>>>>> >>>>>>> Did you consider standardizing the access token format within that >>>>>>> deployment so all the parties that needed to could understand it, >>>>>>> rather requiring an extra round trip to an introspection endpoint so >>>>>>> as to be able to understand things about it? >>>>>>> >>>>>>> I realize that might or might not be practical in some cases, but I >>>>>>> haven’t heard that alternative discussed, so I thought I’d bring it up. >>>>>>> >>>>>>> I also second Phil’s comment that it would be good to understand the >>>>>>> use cases that this is intended to solve before embarking on a >>>>>>> particular solution path. >>>>>>> >>>>>>> -- Mike >>>>>>> >>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George >>>>>>> Fletcher >>>>>>> *Sent:* Tuesday, July 29, 2014 3:25 PM >>>>>>> *To:* Phil Hunt; Thomas Broyer >>>>>>> *Cc:* oauth@ietf.org >>>>>>> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth >>>>>>> Token Introspection" as an OAuth Working Group Item >>>>>>> >>>>>>> We also have a use case where the AS is provided by a partner and the >>>>>>> RS is provided by AOL. Being able to have a standardized way of >>>>>>> validating and getting data about the token from the AS would make >>>>>>> our implementation much simpler as we can use the same mechanism for >>>>>>> all Authorization Servers and not have to implement one off solutions >>>>>>> for each AS. >>>>>>> >>>>>>> Thanks, >>>>>>> George >>>>>>> >>>>>>> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>>>>>> >>>>>>> Could we have some discussion on the interop cases? >>>>>>> >>>>>>> Is it driven by scenarios where AS and resource are separate >>>>>>> domains? Or may this be only of interest to specific protocols >>>>>>> like UMA? >>>>>>> >>>>>>> From a technique principle, the draft is important and sound. I >>>>>>> am just not there yet on the reasons for an interoperable standard. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> On Jul 28, 2014, at 17:00, Thomas Broyer >>>>>> > wrote: >>>>>>> >>>>>>> Yes. This spec is of special interest to the platform we're >>>>>>> building for http://www.oasis-eu.org/ >>>>>>> >>>>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> during the IETF #90 OAuth WG meeting, there was strong >>>>>>> consensus in >>>>>>> adopting the "OAuth Token Introspection" >>>>>>> (draft-richer-oauth-introspection-06.txt) specification as an >>>>>>> OAuth WG >>>>>>> work item. >>>>>>> >>>>>>> We would now like to verify the outcome of this call for >>>>>>> adoption on the >>>>>>> OAuth WG mailing list. Here is the link to the document: >>>>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>>>>> >>>>>>> If you did not hum at the IETF 90 OAuth WG meeting, and have >>>>>>> an opinion >>>>>>> as to the suitability of adopting this document as a WG work >>>>>>> item, >>>>>>> please send mail to the OAuth WG list indicating your opinion >>>>>>> (Yes/No). >>>>>>> >>>>>>> The confirmation call for adoption will last until August 10, >>>>>>> 2014. If >>>>>>> you have issues/edits/comments on the document, please send these >>>>>>> comments along to the list in your response to this Call for >>>>>>> Adoption. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes & Derek >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thomas Broyer >>>>>>> /tÉ”.ma.bÊwa.je/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>>> OAuth mailing list >>>>>>> >>>>>>> OAuth@ietf.org >>>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> From nobody Wed Jul 30 05:24:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F5A1A000A for ; Wed, 30 Jul 2014 05:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koCCrS3_ZngT for ; Wed, 30 Jul 2014 05:24:09 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B971A0009 for ; Wed, 30 Jul 2014 05:24:08 -0700 (PDT) Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKU9jj6MgOpyS+9xEBwH2xg6hPffcs82ld@postini.com; Wed, 30 Jul 2014 05:24:08 PDT Received: by mail-ie0-f177.google.com with SMTP id at20so1394308iec.36 for ; Wed, 30 Jul 2014 05:24:08 -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=63k24z6ixRjBEtshkPG0bVvjzU5SjgQq4i3BEhFSQoY=; b=jWHet+Le6T2HtnrUS4IVBC86EeXJa9MJ1So/buMqv+3kckRcTBIubQ97wIzmNYum55 XxvxPZlxrOhAJ6JN9cBkO+7nd+1VA5sHqNWaWw66926WPYIDZ3AjHNDd0wNdbEkXMzO0 uRJ7epbrc9kv4wpW/rTmHO9UactoctVG5RKgL6NWgdRivJNBz39YrSHOcOnkDK3AAYHk Q7PR/OF0IQsWUwiMlgCX7kspM7bK28tJnC4Bda4Cnpec8rpKyYue74YetOWpIw2KR6Y0 tRBGKPhhBSiVUmIMF27kgVOfZE3FJNDoQ1uEIen4RYZ8LIYn5jVJjLdE8Sgfzlqt1yD3 Iowg== X-Gm-Message-State: ALoCoQnMJErSPSKZLSSfJFryIUYzNQK4t+qRUSVdXFMi/I4jIH89oBb+XITn4C9LH7EIGaEnHDc5CoZU//9SzaJbx3MIeeHX0L4/e6kqoZeOTR9HeUiEwFVYv3ELQyuKH6Q1Cd7TCnYZ X-Received: by 10.50.152.40 with SMTP id uv8mr54422997igb.40.1406723048100; Wed, 30 Jul 2014 05:24:08 -0700 (PDT) X-Received: by 10.50.152.40 with SMTP id uv8mr54422979igb.40.1406723047969; Wed, 30 Jul 2014 05:24:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Wed, 30 Jul 2014 05:23:37 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 30 Jul 2014 06:23:37 -0600 Message-ID: To: Takahiko Kawasaki Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/C19iSW7vli0XmSzdGmoJ3jaRNYA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Standardized error responses from protected resource endpoints 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, 30 Jul 2014 12:24:10 -0000 Take a look at RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer Token Usage" - particularly section 3: http://tools.ietf.org/html/rfc6750#section-3 which describes using the "WWW-Authenticate" response header field in response to a request with an invalid/insufficient/missing/etc token. On Tue, Jul 29, 2014 at 8:10 PM, Takahiko Kawasaki wrote: > Hello, > > I have a question. Is there any standardized specification about > error responses from protected resource endpoints? > > "RFC 6749, 7.2. Error Response" says "the specifics of such error > responses are beyond the scope of this specification", but I'm > wondering if OAuth WG has done something for that. > > >From error responses, I'd like to know information about: > > (1) Usability (active or expired? (or not exist?)) > (2) Refreshability (associated usable refresh token exists?) > (3) Sufficiency (usable but lacking necessary permissions?) > > For example, I'm expecting an error response like below with > "400 Bad Request" or "403 Forbidden". > > { > "error":"...", > "error_description":"...", > "error_uri":"...", > "usable": true, > "refreshable": true, > "sufficient": false > } > > > Best Regards, > Takahiko Kawasaki > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Jul 30 06:29:51 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6CA1A006C for ; Wed, 30 Jul 2014 06:29:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 Y1Kl1-PMaS8e for ; Wed, 30 Jul 2014 06:29:47 -0700 (PDT) Received: from omr-m05.mx.aol.com (omr-m05.mx.aol.com [64.12.143.79]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC511A0030 for ; Wed, 30 Jul 2014 06:29:46 -0700 (PDT) Received: from mtaout-aam02.mx.aol.com (mtaout-aam02.mx.aol.com [172.27.19.146]) by omr-m05.mx.aol.com (Outbound Mail Relay) with ESMTP id 7B144700000A9; Wed, 30 Jul 2014 09:29:45 -0400 (EDT) Received: from [10.181.176.18] (unknown [10.181.176.18]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aam02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 1C00638000087; Wed, 30 Jul 2014 09:29:45 -0400 (EDT) Message-ID: <53D8F348.4000002@aol.com> Date: Wed, 30 Jul 2014 09:29:44 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Phil Hunt References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <3A57B125-504B-4427-930A-75F0D58AF26C@oracle.com> In-Reply-To: <3A57B125-504B-4427-930A-75F0D58AF26C@oracle.com> Content-Type: multipart/alternative; boundary="------------020207070301010706030907" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1406726985; bh=I0iV88QQ6u/r+PATU9qufQJ4WLO/59dbJhupajKRTOU=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=pnVa0HkikbhqMKTi9cRGSD8132egJ6dneMH8UOTHN0bqoEqIUxboRhVr4yNghfYm3 p6o57UbxKXelTrHPR5VdlR7N+JQWxeKlHjg44CEQu4xrWXkHornryjFmarV3iQQjw4 9W6vBDkrFd1O65hxuXYvI+dfehYR2M9vDuJ6MQHU= x-aol-sid: 3039ac1b139253d8f349260a X-AOL-IP: 10.181.176.18 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HyqbbHBPFCZy_NdvFs3OMubezJM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 13:29:50 -0000 This is a multi-part message in MIME format. --------------020207070301010706030907 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Actually, I view this in a much simpler way. In today's environment there is a tight coupling between AS and RS. Each deployment has to develop it's own mechanism for dealing with understanding tokens (even if the AS and RS are in the same domain). The introspection spec solve probably 80+ percent of those tight coupling use cases. As an RS, I do not want to have to write special code for every AS to understand their unique token or mechanism for validating tokens and I'm sure that every AS does not want to implement our specific token. In both of these cases there is a tight coupling required. As for the privacy issues, the introspection endpoint is an OAuth2 protected API and can enforce the presentation of an authorization token (RFC 6750) before responding with the token data. This allows for the return of pseudonymous identifiers and other privacy protecting mechanisms. Thanks, George // Line feeds added for formatting purposes only :) { "bit_of_a_rant" : "Since the introspection spec is not mandatory to implement, I don't see why there is such concern over it. If an AS doesn't want to implement the endpoint, they don't need to. However, for those who do (and there is a good number in this community) it solves a real problem." } On 7/29/14, 7:44 PM, Phil Hunt wrote: > Thanks everyone for the comments. > > It sounds like we have multiple dimensions to introspection features > and requirements: > > * there are UMA cases, > * corporate third-party AS-RS relationships (e.g. the RS chooses a > third-party AS), > * multi-vendor cases, > * tooling/library cases, > > There’s also federation cases. Federated authorization seems like a > different problem than federated authentication from a trust perspective. > > Another dimension to this is methodology: > 1. Lookup by token / token id / reference > 2. Query by token / token id / reference > 3. Passing standardized information in a standardized token format or > token URI. > > There may be some complex privacy issues involved as well. For > example, in many cases, the desire is to allow authz information > *only* the actual content owner / delegator may be intentionally > pseudonymous. > > _I would support first developing a use case document to figure out if > there is an appropriate pattern that can satisfy (and simplify) a > majority of cases._ > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jul 29, 2014, at 3:24 PM, George Fletcher > wrote: > >> We also have a use case where the AS is provided by a partner and the >> RS is provided by AOL. Being able to have a standardized way of >> validating and getting data about the token from the AS would make >> our implementation much simpler as we can use the same mechanism for >> all Authorization Servers and not have to implement one off solutions >> for each AS. >> >> Thanks, >> George >> >> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>> Could we have some discussion on the interop cases? >>> >>> Is it driven by scenarios where AS and resource are separate >>> domains? Or may this be only of interest to specific protocols like UMA? >>> >>> From a technique principle, the draft is important and sound. I am >>> just not there yet on the reasons for an interoperable standard. >>> >>> Phil >>> >>> On Jul 28, 2014, at 17:00, Thomas Broyer >> > wrote: >>> >>>> Yes. This spec is of special interest to the platform we're >>>> building for http://www.oasis-eu.org/ >>>> >>>> >>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>> > wrote: >>>> >>>> Hi all, >>>> >>>> during the IETF #90 OAuth WG meeting, there was strong consensus in >>>> adopting the "OAuth Token Introspection" >>>> (draft-richer-oauth-introspection-06.txt) specification as an >>>> OAuth WG >>>> work item. >>>> >>>> We would now like to verify the outcome of this call for >>>> adoption on the >>>> OAuth WG mailing list. Here is the link to the document: >>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>> >>>> If you did not hum at the IETF 90 OAuth WG meeting, and have an >>>> opinion >>>> as to the suitability of adopting this document as a WG work item, >>>> please send mail to the OAuth WG list indicating your opinion >>>> (Yes/No). >>>> >>>> The confirmation call for adoption will last until August 10, >>>> 2014. If >>>> you have issues/edits/comments on the document, please send these >>>> comments along to the list in your response to this Call for >>>> Adoption. >>>> >>>> Ciao >>>> Hannes & Derek >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> -- >>>> Thomas Broyer >>>> /tÉ”.ma.bÊwa.je/ >>>> _______________________________________________ >>>> 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 >> > --------------020207070301010706030907 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Actually, I view this in a much simpler way. In today's environment there is a tight coupling between AS and RS. Each deployment has to develop it's own mechanism for dealing with understanding tokens (even if the AS and RS are in the same domain).

The introspection spec solve probably 80+ percent of those tight coupling use cases.

As an RS, I do not want to have to write special code for every AS to understand their unique token or mechanism for validating tokens and I'm sure that every AS does not want to implement our specific token. In both of these cases there is a tight coupling required.

As for the privacy issues, the introspection endpoint is an OAuth2 protected API and can enforce the presentation of an authorization token (RFC 6750) before responding with the token data. This allows for the return of pseudonymous identifiers and other privacy protecting mechanisms.

Thanks,
George

// Line feeds added for formatting purposes only :)
{
   "bit_of_a_rant" : "Since the introspection spec is not mandatory to
                      implement, I don't see why there is such concern over
                      it. If an AS doesn't want to implement the endpoint,
                      they don't need to. However, for those who do (and there
                      is a good number in this community) it solves a
                      real problem."
}
On 7/29/14, 7:44 PM, Phil Hunt wrote:
Thanks everyone for the comments.

It sounds like we have multiple dimensions to introspection features and requirements: 

* there are UMA cases, 
* corporate third-party AS-RS relationships (e.g. the RS chooses a third-party AS), 
* multi-vendor cases, 
* tooling/library cases,

There’s also federation cases. Federated authorization seems like a different problem than federated authentication from a trust perspective.

Another dimension to this is methodology:
1.  Lookup by token / token id / reference
2.  Query by token / token id / reference
3.  Passing standardized information in a standardized token format or token URI.

There may be some complex privacy issues involved as well. For example, in many cases, the desire is to allow authz information *only* the actual content owner / delegator may be intentionally pseudonymous.

I would support first developing a use case document to figure out if there is an appropriate pattern that can satisfy (and simplify) a majority of cases.

Phil

On Jul 29, 2014, at 3:24 PM, George Fletcher <gffletch@aol.com> wrote:

We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS.

Thanks,
George
On 7/28/14, 8:11 PM, Phil Hunt wrote:
Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/


On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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




--
Thomas Broyer
/tÉ”.ma.bÊwa.je/
_______________________________________________
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



--------------020207070301010706030907-- From nobody Wed Jul 30 06:32:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB521A0047 for ; Wed, 30 Jul 2014 06:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 Dj7OdRpgT23Y for ; Wed, 30 Jul 2014 06:32:21 -0700 (PDT) Received: from omr-d02.mx.aol.com (omr-d02.mx.aol.com [205.188.109.194]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976031A0030 for ; Wed, 30 Jul 2014 06:32:20 -0700 (PDT) Received: from mtaout-aai01.mx.aol.com (mtaout-aai01.mx.aol.com [172.27.2.97]) by omr-d02.mx.aol.com (Outbound Mail Relay) with ESMTP id B248F702C885D; Wed, 30 Jul 2014 09:32:19 -0400 (EDT) Received: from [10.181.176.18] (unknown [10.181.176.18]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aai01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 5DC943800008C; Wed, 30 Jul 2014 09:32:19 -0400 (EDT) Message-ID: <53D8F3E0.3050908@aol.com> Date: Wed, 30 Jul 2014 09:32:16 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mike Jones , Phil Hunt , Thomas Broyer References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------070708080106060402070906" x-aol-global-disposition: G X-AOL-VSS-INFO: 5600.1067/98281 X-AOL-VSS-CODE: clean DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1406727139; bh=rZ1R8iZTXfjUm+Uz5zmUXnJQzvZKMYKhHz2sXlOMc5c=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=EhDr/9WayK8zf8I5F19UJZVqpPnG5i0S0Hr9fL4MTHSHwkMSJjiQF/7ADAxra8ZSV KZGQEtFC5CvjgeleBaxw4mBnh45MQcBwHh7Uc5TVo8QwInFmC6vpTSAJfPYZeahMSL 9ijy6bBEpZgd6FkBdFk76j2OiyZmV9L4rl2ZbdXY= x-aol-sid: 3039ac1b026153d8f3e349d1 X-AOL-IP: 10.181.176.18 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/qSp7dDp-3tQxG7XWNAwbf3ehAEk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 13:32:23 -0000 This is a multi-part message in MIME format. --------------070708080106060402070906 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Actually there is both:) There is a JWS that contains an opaque token from the partner AS. We "introspect" the opaque token with the partner at every JWS validation to ensure the authorization is still valid. This is a risk decisions agreed to by both parties. Obviously there are other ways to solve that part of the problem. So even though there is a JWS involved, it doesn't necessarily remove the need for introspection. Thanks, George On 7/29/14, 8:16 PM, Mike Jones wrote: > > Did you consider standardizing the access token format within that > deployment so all the parties that needed to could understand it, > rather requiring an extra round trip to an introspection endpoint so > as to be able to understand things about it? > > I realize that might or might not be practical in some cases, but I > haven’t heard that alternative discussed, so I thought I’d bring it up. > > I also second Phil’s comment that it would be good to understand the > use cases that this is intended to solve before embarking on a > particular solution path. > > -- Mike > > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George > Fletcher > *Sent:* Tuesday, July 29, 2014 3:25 PM > *To:* Phil Hunt; Thomas Broyer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth > Token Introspection" as an OAuth Working Group Item > > We also have a use case where the AS is provided by a partner and the > RS is provided by AOL. Being able to have a standardized way of > validating and getting data about the token from the AS would make our > implementation much simpler as we can use the same mechanism for all > Authorization Servers and not have to implement one off solutions for > each AS. > > Thanks, > George > > On 7/28/14, 8:11 PM, Phil Hunt wrote: > > Could we have some discussion on the interop cases? > > Is it driven by scenarios where AS and resource are separate > domains? Or may this be only of interest to specific protocols > like UMA? > > From a technique principle, the draft is important and sound. I am > just not there yet on the reasons for an interoperable standard. > > Phil > > > On Jul 28, 2014, at 17:00, Thomas Broyer > wrote: > > Yes. This spec is of special interest to the platform we're > building for http://www.oasis-eu.org/ > > On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig > > > wrote: > > Hi all, > > during the IETF #90 OAuth WG meeting, there was strong > consensus in > adopting the "OAuth Token Introspection" > (draft-richer-oauth-introspection-06.txt) specification as an > OAuth WG > work item. > > We would now like to verify the outcome of this call for > adoption on the > OAuth WG mailing list. Here is the link to the document: > http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ > > If you did not hum at the IETF 90 OAuth WG meeting, and have > an opinion > as to the suitability of adopting this document as a WG work item, > please send mail to the OAuth WG list indicating your opinion > (Yes/No). > > The confirmation call for adoption will last until August 10, > 2014. If > you have issues/edits/comments on the document, please send these > comments along to the list in your response to this Call for > Adoption. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Thomas Broyer > /tÉ”.ma.bÊwa.je/ > > _______________________________________________ > 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 > -- George Fletcher --------------070708080106060402070906 Content-Type: multipart/related; boundary="------------090307030509070900000501" --------------090307030509070900000501 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Actually there is both:) There is a JWS that contains an opaque token from the partner AS. We "introspect" the opaque token with the partner at every JWS validation to ensure the authorization is still valid. This is a risk decisions agreed to by both parties. Obviously there are other ways to solve that part of the problem.

So even though there is a JWS involved, it doesn't necessarily remove the need for introspection.

Thanks,
George
On 7/29/14, 8:16 PM, Mike Jones wrote:

Did you consider standardizing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip to an introspection endpoint so as to be able to understand things about it?

 

I realize that might or might not be practical in some cases, but I haven’t heard that alternative discussed, so I thought I’d bring it up.

 

I also second Phil’s comment that it would be good to understand the use cases that this is intended to solve before embarking on a particular solution path.

 

                                                            -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

 

We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS.

Thanks,
George

On 7/28/14, 8:11 PM, Phil Hunt wrote:

Could we have some discussion on the interop cases?

 

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

 

From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

 

Phil


On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/

 

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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



 

--
Thomas Broyer
/tÉ”.ma.bÊwa.je/

_______________________________________________
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

 


--
George Fletcher
--------------090307030509070900000501 Content-Type: image/png; name="XeC" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="XeC" iVBORw0KGgoAAAANSUhEUgAAAWcAAABxEAYAAABZ0L78AAAABmJLR0TIyMjIyMhnRJJpAAAA CXBIWXMAAABIAAAASABGyWs+AACAAElEQVR42uzddYAUV77w/W9VtY67wuDu7u5uQYMEhxAk ENxCggWCk6AJJLgmEDQwuLszOAMzzDBuPa1V5/3jXnb22b25m92wN/d53v78M3R11a/Oqa7T /OrUqdPSpUuXLl26JARubm5ubm5ubm5ubr9J9+4fNWrUqFGjxp9dHDc3Nzc3Nzc3N7f/XS5f vnz58mWQ/+yCuLm5ubm5ubm5uf3fwJ04u7m5ubm5ubm5uf0O7sTZzc3Nzc3Nzc3N7XdwJ85u bm5ubm5ubm5uv4M7cXZzc3Nzc3Nzc3P7HXR/NIDVarfbbP/5QgYc6EgCKZRdUgMQY6QwyQ+0 X5zFHWFAjKWodQOI0pauqeXBVvNt0isv0K8L8Pc7CsbcoKuRM8HV0XzYfAGUzzhvPAbSt6Sz A9TFcjH9a5AO5f6c8RU4O1rTsoaA8Wzw1agfQIy1xVqSwPHxs4O3Z4FYIzdQfgHuub5RB4P2 OntVxlJQD0qjlI6g5aoPzQXB+lHmfGcs5A7LLp15AHKL5kRmD4XcJFs/NQss3o5020WwPLfm z94I9oH2KdaeoH/mvcHPBtIE7xC/NLAkZJzMzIScbzJJ6QGuTtI6uQKIqnTSVQVtpuf3AfnB diA3N/coKP6mwuZ7kDkp3SN9JXicCrkdkQlavPKj10swe3lGee8EYeKpsSLoVxg3ywdA/dJV X/sVagyq9WG5RlBDqlgs/DlopVyLXPdA2iDaEgnCXwoWF0FqjJkgELm4cAEg/R8fpMJ/TEl4 DwkZCGA840E3R1qiDITXVxMfpm6EgxtPd7i0AYRR/9w1CnpNaTKrYWNwTpKXSJGg7RGz8ATf 554rjflAXir5y3tBd9XU3XwcomecSDrYADLyWW1qO3iSkLT44lLwehs8K6cX2B8meCh34WHM m9LP14N0VdfOthmymqZMF1cga2DOWJ/x4H1T95XhDgQv808qcA2K7yqUXXoDWLvZJ+gWQWp4 UmBuKEQ1Cv1GDAXrZ2q2ZTIUPOyRG1kd/PoV+DxyBuQ2tT5N/QL8/D06Bu6Hi41jPv9lF1i/ UbumNIYBES0GzpgDjh/kbsrHUHZL8Y9DN8Pjz5+tyC4PB8dcjF42C7J8rJZr3cGrvTzS1w+S 7ydV9PGG+fcmR62a+Wc3czc3Nzc3N7f34f31OMsINCBTMuEH1EYT50FaKt4IFaTh4qbsC9j0 W8UFcD5MXZLYHIwBPvm8zoPmr32sVQWa6Eqavwb9eVn1OgOan4hRl4OwiBnOQFCuSRGiNnDO 67V/ZzB86R0f+BFok10fOS4A0aKuVhWE7NplbwxOnyS/2L2gfpz7UXpHUIc7m9k+BTE/Myl7 EjiGZR5Ouw7SBeWZOgtEgu6a3B2UtYY7hqFgqG/K1C8AT6fnNfMhMB81r/GoCoaPdRP0r0Dx dKU5PgG9UyjO4WBaZ7qoLwHKB1KYHATyJtcJVwBoFZ2VbEVB6ax+Yq8L+kQmuoLA1EvfRZsE xlQPm9cGkEY66ti7gfdQzyPmySB+Ucs5m0HQmpCuAafBc5nP4TAT6Lz0Ov0teDw8JuflEbBM tVS2aSB/qIwTd0EbIH0hhYA0n12EgUiUArEAIP4mZf4PKiCAolIoAqSa1JE2grO1eOV6Bvlm hXv71YN+lvbdmh6E+gcqJJf5DoJ+CiLACBcHX9ff+RweDnve+l5VyMqfPtDiB1yXF8mdwdCJ sdIKMDfyfhMxCpQwpZRdByFv/b62WsCmZAm9J1TtU2J7u1bglyMlFDkBmUdS9wemge9Qj2qB 5aFQ+8BuRdaAM9tRtKgEWeeyc3kK9wu/UG7rodDC8DpebaCwI8JStjzcmPzgUMZIeGtP35Ix A3T7pRGv64LXDrm68xt4UyPp4NPv4Wa5+zV/mgXaN5bW/oUgLNyjYadtoGtu7KMbBF6nzKN0 UZDkTPom4yXc/fSZ77HLkNkss8+jaHC1zk7LyYG0OwmjMgpB7ijbS1f0n9283dzc3Nzc3N6n P9zj/BdOJARIhYRNCgJxkSdiCWh1pTviS5Ar6ZcqZ0HdaYm3VgKuyN8ZZoM819BeNw+UicpQ 9RKIO3JvURO0gXI/rTRIYWK1bgwIf0049SCNcS60DAGplH6yxyBQvxSfuayglY1v8Kg6aIn2 W85tIN2VF+jWg+GM51D/qeA8aDlrSQbptKugEgcuf2cf5wRwfWpvYP8c1AiluagLhoX6lnoP MGzzMnvXBTnKNtwxA1Dst21twGuB1Eo6CdI52SoZQZ3nmmQvBfpH8iUCwLFdHqP1B/MYD7M5 BhiXnc/yM6iVtKnaDBBLbebsXiBt0oKU5eBULaas8eBZxDDAcxWgYHd9AtoJ66a0LwGDfEUf BdYhOfLb6qBf4nEoOAB8kwKK+M+CzDvptvTF8GLsq8/Tg6Di8dItQn3B9dI1SAPoJ3/CfEAT qdJiQEIWsfxHkvx/JtASBkATsVwB8Ugqy08g3RcrFAtoOWpDbTZYn1BTewXFbAVH5TdDQrfU Q0lloEaPcruLdoGwngGpoUlg09SDrjOQ8WvWPcfX8GBUaqFnP0DaV7afXpeCW1diI+93hJSV loQUb1DvZ8/PTgWfUH3RW+mgT/Hb5FwPjZYW6li+OrjKaQXlBDgz+s6ZJyaQt+m+D6kEUmmS jPHQcGulMo1/hkrzCnpXeQNZdyKPJlyA+l/Wkrr1hPtfxLx9+gYeN3pg2fEangfaNzguQsZL feDzIeA9D9U0E6oVK3u+YTXw/zQyxT8W/FsH+nt3grQlb4dmfgYp6zKNYgU8W/v448QqIBpo R8yTwFYnMyP/HHAlqD7ZCZBRihuvPwWg/p/dyN3c3Nzc3Nzej/eXOMv8RzLmRxYm4IDUlOeg ayFG0ANcwdo1pwGUVeKMuA7KzSLli+WA+rVY4LwFyklnz8wPQXym72/yBfm5liI6g6glt9H1 AamfHM9s0OJypqQroF3M7ZDUEXT79JU8csD2So0VI0Drkzwsvhm4cqwLbBnAVGmFch3kvkoT jgP5DWO974DugXRMXwa893qNVgqDo61jr9QNnIW04WoncC1Si+INhvVipzEVXH20geImaHaC pSngVdSriq432LOsq7K+Bfmac5crBTxLKr/Iz0G+Y75ijAS5oJoulQBprb2GsyFY9zpb2IoA W6TeSguwT87RW26DPlmvZh8CbnucDSoHxm6uXtlDwHnc/opnkOnK/jC1G3hWDuyf+iXoS4dp JQ+D9zzfTX4/w4Nlj+PjW0HJFYV3BJUA3Zc6L9Ee1MniE9kIch3JU/wK4o7IRQEUJLT/4xMU OAGBL4WAGaKueAVyU1lhIOTE5ky21YDLU25WutkFEkpnnI67Bzm1c95oHaHy2wofl5gMph4e DYJC4eWShF7Pe8F31oM/7NwHuqq6g7nbwTVFvzKlDxS5G9g7fxLcn/P8vs9icOxzFbK+Au/r idXvVYSIYP/WpT6HjOP25qk+UGhcwPIG38DrEW9rHpoGH65v5mreC3xS7FsNY6FMVCnPwmsg pnh86mMfeJ0Yvz82HSy3bN9ZesIL69vCRy+Da4OYr0SDf1lrSsJFEFusG8O/hFJ1SucvtwqC AoNG+JwBz191mvUxJG6Mv5aig8RtGSteRcMrOSHi2RwIig27xF3IXP08LG0tcFBvlw5DZqmM k8bOIN/x6eQ5EajOmD+7kbu5ubm5ubm9H+83cZZBPMUl3oBUlkhSQNiYLoeA/Ak9pfkgKnv1 MO8E6RJH9JNAHihbJQfIjw1tIgJBCkCvywIxG192guQSx8Q+0MblxiUvAp7pgrz9QL7kcSng K1D9s7q+HgqSRaqm1gFFDSgXPhO0HxIsLzNBa+pqpE4G5Z6nNSQWuGlSPW6ASMv9Vp0Aopz6 ubwYDFbplRYDUoSWrSWClGMv6LKAK5881LkclAZKeTkddIe1XGUqSC/FEzEXhKTM1A8HTlNL tAJzuuiktQY1ga5ySZB7mR+b7oE8X/lW5wW4rGGiNljbutqqM0FLljYpn4MtwRJsmw+GU7gy 14GyUfcZL8D8zPDU3AXS8qevtRQG3fe81DZCllXqbIwEn8Dgp1ES5Ay1tnFdhtf6ODltLhRr Xax/cEVQU+y/qqEgnkkL8QdswH/1A+sSoAEqmlQIpL18KdaAOKr1EN+B+bhpsdEEzYPrPKm5 Ho40O//L7RGw+/C5tTsOwFHuLT3dDWpcLzq81BbQNZNUXyvkH+FbKCwayuwpXKvickgumjvn 1WV4I6cG/1oTguv7v3YWBscFqaF1GfjXNo80fwyKd/a9zBSIOfl2qKs3WDytpU/fgjLL8xUI vwdx+9Iu30+FgafaftwnBNZGb9X/HAIpPW3rHw2A2rElSnYaBU8+e5F6/wHkVBAHPI9C5CCv vrrLYGuSVcXzNZTyLHqs6q9QaUUBU4m1YP7BqPPMhbfLEmukP4eXJRL33dgDB69fn7T3IIQ8 9NU5y0KDk0WCWkyHiCT/8bUtYPzVVEqqDpmv/btb1sDbCrln42r+G1psZSpTGY7MPTL3yFzY 6b/Tf6c/PGn0pNGTRqCuUlepq6DIV0W+KvIVtD/Q/kD7A9A5pXNK5xRQqivVler/hnK5/beq Vq1atWrVf367yc0nN5/cHLrM7TK3y9y/j3P8+PHjx4+Dn5+fn5/fHy/ns53Pdj7bmfe6YMGC BQsWfP/nzb+7Hm5ubm7/Lu8vcRYIZMAohZACIk48lj4FjjFXjAepj3Jerg5MlCb7BIN2Ve2c swWUHKmOUgsYKdU1jQDxQqRIM4Fm0hnWgrgjbdbOgRRmOOZZDfhE2W4qBtplx5dZPwHztGDx CcgFfEWgJ8iWcE9zKshr9C75NLDJNNNzPUjn5C3mkuD6KuNLy2IQA+1e9oYg9TfGKgkgqfZj rhBQfrVb1c1gD3fkd3qD6rRfc4wGFqlbRXnQTZZKKmaQvtRNlHqC1MeU69UbRIpor70AVwM1 1JUJ5jXqcTkXXLf0hZSFoCzUXVQfgHxUaizpQSuX29XeG9Qnjr3sAeNnuhzzRFBjnJXtIyB7 R/bw1KZgVr0G+TUA3/m+Ts8dkDM9q2P6F0DxlNCXo8A+3VjZ6A2Gl775I7fB07WvIlO/g8Kn Cu8LDgPpB+maqAJcETFyOaAskngFeKDDD7DhwAoINEwgRUh6NBCHxB0EkJ9+8gNQqug+FrPB uceZz3EXAgf6SmolaORVoWHUBrCMNqx6Fg26WtrxmJEgNc5MrpgOVfqX3VmjIvwQ9mvzn65C 6OjQ/qZqUGNE6U/qDobWX5Y9nW8uPC6cOelNEuz56OjF76uCYZxyM6kYWBurgb4z4VbCY8+A B+DXw5DquwZiPJ9Ll/fDiu7bNhscENTd0FGeCtZ+GS8Dd4NaUhGpJyHiTcC6ItGQM9ByLuoI WGRL/fPNwdTeQ5bqwI2Cj5tf2gBP6sQaYoqD3MKc4WGG+BtvbyVshPBUz2eBD6FcSsChptfA t0hQpbi+4O/M177kEtCa6komvYDcduo6ix/oQ8S+h9sgpWxKfOIFAIq9zwa74OSCkwtOws4m O5vsbJK3XO/Su/Qu/pJYP/R46PHQAx52e9jtYTe43vR60+tNYf6w+cPmDwNucIMb7/nbxO13 C5keMj1kOijDleHK8N9ez2OMxxiPMf9z5eq+oPuC7gvyXv8locUPvz/rYLm5ubn9L/L+Emf4 j55MvRB4Aek85xbwEotYA5QjTDKDCNXStDGgLXJ5544EaaJ8yGwBaabxIF+DtFgsVReASCNY BIIwyJV0lUGqau2VlQMumRa5RlBme4z07QtSa79Lvr1Ad13uKvcDsdk1U9sG0p4ilcPKgFRK V1JXCOihbnRZQKkmE18H7Eeds1M+AGd4Zr/sGHClWA67AsFa1Xrd1gdyV1i/yX0FLj9XmsgG aYW0U9cClGXyWXkhGOsZKhr7gyhj6C0NAPsEZ7JzA0hH1Xmu2qCW14orISDV0jqK+iA7pEeu RuAa4hiuSODpY7IZ7eDabt9q3wPaEVdB512Qd+lm6ReCLdb2nXoM7HoRkl0STCd80nVvwFhG f1c3GRRvp2LfDvbB6RPjn4HXVd/5ATvAespa3VQasuZkX7ClgU+md7zhNqh71FniNdAQB3VA FBYztO9BypW2SC+BE9IyKQdEBuHiHqBxm2LAOZq6hoN2RsQqJ0E+zzpjEUjt9DY90wK+xeXZ DgOoH0gNMrIhLSxDpQKo+swR99PhUPbVU4/Pg+m1SU6pA4ZH+rSwgpBePHueeRKcbp10wJoG iUtTv7q1G5Kzne1SzKB2yPlceIHpoVY9rRZoF2yDEm+CuB3cM6QClE+JHFBzPjhOWve4NkFm Z9nl7AAFj0QMrD0MHgc+3hf/I4SFBi7zbwJJA7IXpo2F5GqWsJSWYOiae8wxHaq1Ld29sQns T7ITAr3gbUxmq5juMLVBD9MAX9C10U8yfwKvnckts8pDjOHlsWOn4dcLlyZtuwRN51Tt8sEw 8Flpjw55AsfrXp1xoyZkL9Zee34H7OXr99G0Tp06derUKdj52c7Pdn4GxtrG2sbaMDN+ZvzM eGjybZNvm3wL0jnpnHQOTmeezjydCdNDp4dOD81LgM5az1rPWqEe9aj3P/Md4/Zf2Npga4Ot DcDvjd8bvzd/dmnc3Nzc3H6v9zmPs/Sft/otUgHAQyorugFm7ktzQHpFKaU/qKGOGam1gaEW U9bHIAvSdcdB60tLORyk02IoXwMe0kHlKFDY1ivrIRCns5qfgbLG09u/I0h1dVOMvUE6ShNF BS2fluO8Auoz+a3jAcibtTNsBjY6ZjsmgKiCv/N7cIbYX+XGgFRdPFCngi6/7o6hKdiu5vS0 ZENm3dSsjIVg1yxjHBqIB2qWuAO6CXK6Uh48fAx3zcng+bFhsEcx0LeUesrxoF0SN1kA9FM2 638FXYghzFQYaCt9JC8A12xXhvMD0H+iPyf/CsZGRpPSFLwmmBM874P+V6WQIQDEGnWB2gD0 +5W1sh9o2112ux7sXhaPFBvITvmmywzaQamRdhRsm7J6ph+GtDtxxR7sBTXLsc26F3K+tDx0 vABpi5QptQRtmTivXgTdT0q8shnMBsMoj+qgzJNNxuXAVhEkeYBUTsyXfgFO0ZZcYKAIlT8F lkhDpf6QWSX7QHocmM+bq+MD2QX1IskIGUMdprQL8DLtzdH4peCaJ0/O7QPpc5zFEs9BgU1+ Q/LvA9e03Iq+Ejz4MPbu9WA48vxGq02fwqsZyTueFYImZYptbPQxGCIls28nkO4aZmgNwZTh 20JvBO/qjK16FFxnqJKZANlTndOenIGXKxNaJkVCwyoVLWFXoMR5vyLBMuiOKB/cmgaRoQFX DNFgHGf3DBwJbUvUzmjhAWO9BxUavBQC34R857UGmkypUbDyAZAcXuvEWDjU99Lxg1vg55PR zb75ER4VfmV6vRYKzw2tFngUnux6/PL0aUi0Ja681Qiq3y4+pVQrKHg8YMurZ++vcW3fvn37 9u15r4cNGzZs2DBovqf5nuZ78m6ly8Pl4fJwaPSk0ZNGT2Dizok7J+6EViGtQlqFQM7pnNM5 p/8+fvz++P3x+2Hc1nFbx22Feg/rPaz3EOp51POo5wHjG49vPL4xJLRLaJfQ7r8o4H/2dL/r Ce/YsWPHjh2hZs2aNWvWhA5fdPiiwxewY8KOCTsm5K3/TkZGRkZGRt4t/Hd/H9Z7WO9hPeia 3jW9azpserDpwaYHf7/fzZs3b968Oe94NAtoFtAsAE4WO1nsZLG/j/tuf++t/v9L/LP1UK+o V9Qrvz2UpGnTpk2bNoV7hnuGe4a/P+77ZuybsW8GdC3ctXDXwnmfd7MXzV40ewELTyw8sfAE 2ErbSttK/3a5b8o35Zvy38cZcHnA5QGX4UWzF81eNPvj9f3D55ubm9v/772/Hud3Y2SzgBCQ 6mJnFzCUHqITqJ2llvIikOEpS0C9nfT86WvQXpozQ7qC7GmaI5UFrR4VKQ30Fzek/iBV1Xf0 BCRPwwGpB0iPtS+0l4BdC1B3gWgin9QVADy081JfkNpTRXkIJMqVpQxguBipGwyMVp3aMJC2 efUL2A36QX4ZoXYQH4l+6lbwnxDcJmQnmGemtszID9ph6yprR5ATpSlkAMUd8bZ9oGsjF1XW g83TFSW8IGecvb2zEXDDWcXlD64t2lhHDDgd6mW1KvBUbFWjQSnHND4A6SvlR0MjMOyntbYa sJiDiQBXD8d5fWGgNw1MGeCo5PzeMR+0+WKUoxy4bjmWWkNA+8F52eUL0gldcUNpMHY1Z/ic BduT9BJJfcHyOq1YvAdkrsyKj+gDBQvlaxY4ApRbTNZ/Aa9uZ/jFbYfcTrmt456B3xWPy77z IWiad/miP4OrG/tdISCVFfFyEUBII+gLUl0tmGVgqG7SGfwhalVYQlEvsHwjjomPIPF6zK+v BkNwQb811oJgaOTZN1mDrKC0STY/uLj48cDkXWAcYqyR+Qw8iyttPN+A+aw2Vf81BLUynan8 IYhPlLmSHgJ+8egZ8DV47FMy8h8F9YYry7gCKi+uXLrUY1AipM0Fz8PZAedLnZ8MnbyqJjbv BmVaVD1a8md4YXl9IWsopOS+Ki98we9M6K+Rk8An1OPoYwcYhpmGeKrww6PdzoOn4N7m2FqX D0NGUuYCv+2woe3BjJ0FwN/Pv5N3LyiWGdXadwRow3JqaA4wN/U4EPYcdAf11+xp8GvUlZbH K4E50U/2XQrmGroN/g3+eLMSg8VgMRhu/3D7h9s/AOUpT/m8xPAfaRfRLqJdBLQ71O5Qu0N/ /37uktwluUtgaPTQ6KHRkJiYmJiYCHVG1RlVZxQ4yjrKOsrCyayTWSez8oaAbM/ZnrM9B7y8 vLy8vGDX7l27d+2GBd0WdFvQDfRL9Uv1S6GyVlmrrOUlRgv7L+y/sD/Iu+Xd8m7oSle6/jfl n7Bzws4JOyGhWUKzhGbAj/zIj3nv/5LwS8IvCbB06dKlS5fmXUAUji0cWzgWZu6fuX/mfmAJ S1jy76v/P+ujjz766KOPfnvscMmSJUuWLAlzOs/pPKfzP473r9ZjS9EtRbcUhQKdC3Qu0Bli 98bujd2bFzdfvnz58uUDQwNDA8Nfnc8//fzTzz/9nFc+w0zDTMNMqKJWUauo8LzG8xrPa8CO qB1RO6Ig+1j2sexj8AVf8MV/Uf5p06ZNmzYNIogggrwLwDsj7oy4MwK+cHzh+MIBG9jAhvfw uf2r55ubm5vb++tx1gAJpHy4yAHxLQVoA6I6C6XtIH9IiOsSyBvkfeab4FiYWyh3MojrqskZ AHIP6alUBcQ2EjgMREpVxDSQjssvlCcgnopK4mfQmmjfab8AC0mRckCycI00oI5cW1cIpCLS ckMEaPHaQEkDqZworoWCEiBFGseAMst/vWdroLSHv/oRyJV96hjsYNZCTpoiwbzAvMG1CrxH BfZRksH42OtrrRjYGjhHWYZA+qT08slHwfI8c9LbrqC+FoWcBUBbzTZ1ODiX2Yc4vwLXF+ot 0Q8cA4VJKgvic7mo3BWUm/Ia3XIwf23cYWgLfl94tfMcB75nfFJ9JoCphbGa2RsMw30KBfwE 2npttfQW5N2iJLGgWyffxwPEKld3hw7USvbvs3OA8cpoUz3IuJugfzIQUvem1k2rDi+SXq9L XArHpt798LsWsPnU0X7LtsCy77cf/f4K/BAdPXVHBXg1IGlMYhLoD4gtum9BzRH9pM9Ba60l URRM9XRXdOXgbPDtzKt94GaVuJ6P2wDTXenKz+AZoozyWwNmb88ixs/AUEgfrlghdVr6ppRo UHYr0w1HwHOKvmG+LpA7zTLdcxiEZ5ik/FvBf7vPVH0sGL82d8o5DW2WVZ9QtS+oIdzIvQll jhTt49ceTtQ/F3L9GBw5duXjc6egzszyP/a4CmcH3C709jNY/+XGQ4fHwUv/2EkxE8AYbGzg 5Q1qGfkb+zaosrTEyFZTISXt5aIcFS7m3GxzrinUT62cU+QwBIwKdBVbAuZ+xj2O2WCpYO2Z PhCezXgxKn4qxFhTuj4KhvPXH97YcwoujXjp2jsf7JGipHoGnP2thdKvwctFiXrl1z/erCxL LEssS8BZ3lneWT5veVBQUFBQ0N+vv9iy2LLYkvcw2d/+Xbly5cqVK/PWP5x8OPlwcl7i8cEH H3zwwQewrO+yvsv6wqorq66supK3/N16B784+MXBv8qANj3c9HDTw7zX74aQfFvh2wrfVoAZ oTNCZ4Tmvb+14daGWxv+4/rXHV13dN3RsL/N/jb720CXo12Odjma9/6PD3588ONf9Qi+S8C2 eW/z3uYNQ8QQMUT8dvz3Vf9/VlxcXFxcXF6i+rd/3+3n9/pX63Fk/pH5R+bDnil7puyZ8vdx N27cuHHjRii+qPii4ov+6rjX/bHuj3XzXs9qN6vdrHbwzYBvBnwzIO8OgP6O/o7+Dhydc3TO 0Tlgs9lsf/nBrL/y7iHIXc93Pd/1HJaXWV5meZm89x/UfVD3wV/t79/1uf2j883Nzc3t/Y5x lgEXingOBJGODVDYRzqIF9oxdRmI6WKGowMYZvvMDBkIyudKG7kciMWij/gMpCQpTa4MDBT3 hA3Ec/FIdAOu0UQ+A3KQYiMQmMdGMQiwiWdaRSASoQwCqYioJ1oAD+WP1LGgdaacvBOkVfQQ I4D6GcXjNcjVnve4/xAcuembMuuBpd7rtimfgNZKF+7pDdpXpnTP85D7YXYbdQWI89oYQwGQ DbruxjhwDlOrOl4DGdJ1mxc4TxOi1AHptJ/eqy+kXMiWcnMgOzwrI3UQ2OZkr8o6Dt5fmAZ4 jAWpsrxYLgEmf2WZ7gOQu+lOK41AL6u/uqaDrYfeoS8Erh2sFDfAuMk129ESqKmUIRJEftcr uRPY7zge5U4A06f6hcYoUGK1NOMeyBmZEZ29DXasPvjiwgm4dzXt2vqa4HHKUL3IXVB6qPOj WsHNXvfLXR4PuWNtOfZvYOKB7oNmFQFDW3mM0gWU5roe2kZ4UDI+6cls0I0zlkiLB9mleWfs gntzX266eROSL9k8kxdBaEudt38M2CblTMmNBuO3XneMa8Ev22OvcxZ41FIP6reB/bzukG08 mE6F2KX+YJhtmqTGQaKn5Wh8ZciKcyW/eQXVvYqqrfaB5ybdLx7noVaHcl3vH4Vrne8est6E KpOqFzDUB0dfppQIAj9v0/4kXyi2sGzxGumw/0X0801NQDeeyJQ4yPzY8LSxEZw9rHfFWyh4 MbRe4aoQ6x1/IrcXnE14XPKGB/gGmc8Yp4P9mrVQ8gzQDqmzDNPBt4fXEUsDcJVNn+kaDakr nEbTDHBe0k3TjkNGJ/uF9LKQUyC3nLElABl/pEmZH5gfmB+AtE5aJ63L64FO75reNb0rBP8U /FPwT3nrp0SlRKVEQWyh2EKxhf4+XkrblLYpbfNe3//h/g/3fwDCCSccdu/evXv37ry/v+Xd dtYEa4I1Ad48fPPwzV8lzg3HNhzbcCzQkpa0hAZbGmxpsCXv/dchr0Neh/x2IvXOiO9HfD/i +7/v2X233d/ewm86senEphOBTWxiU16P+1KWsvS/qce/Wn8WsIAF/NPe9ywS/1P1eDfk4t3n 904tQy1Drb8ayhHYPLB5YHO46LjouOj4x3Fr3619t/ZdoC1taQtFuxXtVrQbEEAAAXlDSt5X fVtMaTGlxX9xofBb55ubm5vbO+9zOjqBDOKFFEY8SJ+Lb6XuIApI7cQ20CJoLMeB9KVWLDcB 5BEB9yP9Qe0hWqgHQDeMHSwGcZpMnMAhksVjkHYzUUoB8ZFkFDoQEdSXA4GiYoA2F6S1VOUR EMNScRCoJK9gMYiStgXZu4Ab+leehUBWlcFyH8gu/CzwSWlI0p3sedEXrJscJrECbGsMP5vH gutX+UdrQzCoirclP5gOe37q7wtybf0oaR5IfpJOewmKU2qquwyu9er3hm/AVMjnW/NKSM9v jc/oCbpSOUMy+0PYYuMN8zmwlnd9IvKB9INSSHcZtJcimDjIHWjxzKkCtm6Z9TOnQfbI7K9S noF1sccW77Zg/8DVzfUSxCCnLqcHeJwzRvi+BBElyqkDQDcXLz4H4yj7k1xAaSUvc/qDrrCt b84cCCzkUyi4JuhGvXlctimQqnVN/hrCPgw2uiaA84bxs9ej4cW2R3Vs+WHlpk0LfmgGA090 3tu5DCS2THiYtRauhyWE3oqA6O9eeM17Aj7bxYqAQpD+IKWxfQgoDZT78gKIC5YGKK3AlKKr Ye4IJc+U+Np8BTIaJv/i/BmMF4NnZMdAqdqigOoNbz5IqP1mIRgTpF/0geA91Muc7wU4VOs1 5R40XVYvo+Ee8JvpFehfCN7cStsU/AJKLMzXVrcH3uhfn7eMgCbnaiUX3AqPIh71lS9AhbHV 55b8AnLX2b/+sB5c6xYz8fV08K8UdMVnLjzVYmZfi4CWO5qu77scDte/OuBeKDSoWKSk3gaP v4wr8bAfeEw3j/M+CMpBXepjGYLb67dZGkJSV10J7+ugDRVTPENBWqveyNkHsktZxnYIbGva IWoDZ/9Ys3p3K7/U+VLnS52HBzzgAXBg1oFZB2ZBf/rT/6/Wn5s6N3VuKsxlLnOBAwcOHDhw AD7//PPPP//87+PbLtgu2C4AXehCFwiYHDA5YDJ4P/J+5P3ot8tlWmNaY1rz++sh3ZBuSP/V LB7vxjpf4AIX/v7t30pgtFXaKm3Vf7F8sDZYG/xXx2+YMkwZBvjgg8+fV/9/t/+peogqooqo AjzkIX91oaTT6XS6P/C/ybuhGX/xbtaXpjSl6f9cfd0Js5ub2z/yPqejkxCAv0glAPgZmRjg joiU2oIUwNdaMZBbmCsEfg9in1wo5wSwRJTnF0CvzSQceMxkDoMYhZ+QgBaEyUtB+l6bpx0B cVoYtSFAB2Ws3AdEgmgjxYO0mNPaYBCfKPmNL0BMzI3PuA5av5xesfVA+sF7qPdLyH16/eHN YBC7vSv69AVHkrpLfxByz6S2zMwFyS71yWkKjuVCseyGDF1G9eS9oFstfy9NAt0j5abBEyR/ eaHuS/CY7f3Sbysos3Jb+MlgWp0TmTUAAr8zFzcOA1eIrrl+CyhBckflCNDHOdnZAwzD5Chp NgQeMdz2LQGuCM8zxl6Qe8bxvf+vkLrWVlp/E5K+cc61RoKtWEq/7GOgfeOy2+uBKVG6YroE hvXSebELPO7IZZVyYGzidNkjQV32oPe1QeBtLzmj+Gnw2RY+zfkRJC3MnGv3BMfpzN45EZDd NEFf5AqU7p6/brNBEPqdd9l8m+HAmuh10Z0g+Zr0tfU7eBGfMOPiPAi45TPYuAIKfhVQ39sC L13aGykKHBaXxk4oRvC5yqfg4uqYxRd9IO5F2oPcBRC2SF/X72sIGRGxzvwpGBfJ9et+A4xX 1ifWhrgJmdWfNIYCfh7RkVOg3KwwY80LELfpTc34q3B7csbyV1XhxeiE2skboMDUQuFBXaD4 D/lPB10H/2L+st8W8K8SsCH3ExAt5a66JCjYpdSPBftByieWT+VE6PC6davyc+HIxAMFlCdg TDTNsg6Huv5VBxZbDx5XlG3On6B0+ZKXgruCXbJfMATCCXG5xcu5YF8ttzb3Av3Xxt7SE9CV cozLHgShL30aBkjwOspWIf46FFzhc873P4YmtHgfzat7dPfo7tEwk5nMBNZWXVt1bVXw3+m/ 038ntJ3RdkbbGXkJyEXnRedFJyzdv3T/0v2/Hbdg54KdC3YGJCQk6JS/U/5O+WF4l+FdhnfJ W+/xuMfjHo+Dly9fvnz5EgrMKzCvwDww9zL3MveC8ITwhPCEvIewTi0+tfjU4r90OHNq0alF pxYBrWlNa4hsH9k+sj2YZphmmGaALcOWYcv4/cfDY5PHJo9NEBwXHBccB8lRyVHJUXCi+4nu J7pDu4R2Ce0S4PCRw0cOHwG60Y1u77/+/1v8u+rx7g4Hu9jFLjDfN98334ewiLCIsIi8IRDv Zn1p2bJly5Yt8+58dOjYoWOHjnnxTvQ40eNEj/+99XVzc3P7R97vUA0ACRUJcEoh6IG9QqIg yDa+07UGMUQa4VEPlG2GJcoaEI+Fl/olqH3IVu+D9ERare0AuabYrXwKbBNpUiaIksoOrRbI o0V112zQFqq9ZBvITeXPJD1o58VE3QZQZmjrnWfBWV80U/0gx/dajcufgagt5jlPgjI1Ykyw F2QViL2VWhaSryblpF8Gta/ruf1XyJmYEp08FZ6PTt6f9RayDurWGDqCctDY0LMABL2QPzbG Qr4gcxGP7qAra5ayZoF8Whf/uh34ZvpNlIPANkEMda0HqYF+onctMFQwrvHaC/bHWk+6gtpS bmDcAoaOxlPGaSBf1Bv0JpBCdSbHSjDE+TwylAVTQ+mzwImQkKUut3QFrYpdSl8InlcMVUUq mGuISlI1ML+Vl6h9QflEnqffCVKNe0ViLkDAIb/SziHg82HUo7gLEBuX8ODNp5A9z1g37Qso V6jUoY61wHea1b/oA7jrHT/k4UpIyszocG0CGHyD1cR9IJ+WPnPsA/9a3se9/cDxyLpZegG+ gww7fVMhO8UxXzggKNN8ylAEwod77o1UIfFJrCH/OjBUCVpt3QyZ8+PPPv0ZogYHBwbFQM+e TV/0bAlHn15btK0IvJycterJeUi8aC+VsQTu98+KvfwjZGdnrTTug4BKPt/mVoPTn5yYEtcH Mn+stNuVCh19m3UL10PQxsAH3p/D6QEXf3z4Elo8aiyV84EXs593fNsZUhamXcqaCroyhjBt J/h19y/tkwoeJwKXKJ6Q9iwx3eoP1+3XJt1pBC++y2z7VID/SP2J4E/Acti55ZkCXod1SbbJ 4Ggo5igy5OxxdMmoBN75tA7BH0D2JWWgiAAqvp9m1ebnNj+3+Rku/3L5l8u/wKEOhzoc6gCz Z8+ePXs2zPeY7zHfA2QP2UP2AMcKxwrHiryHzP7SE/s3PYXtD7Y/2P4gbI7eHL05Gr7Xf6// Xg9PPJ94PvHM60l8N40d17nOddhQY0ONDTWAXvSiF/Qt3bd039LwVZGvinxVBGZFzoqcFQn7 b++/vf923sOB7/S19bX1tf1zx+D/8J89kl3Wd1nfZT2sXr169erVMLvT7E6zO8HW4luLby0O LwJeBLz4bx6ifF/1/7O9r3q8m+bQfsF+wX4Bvpz95ewvZ8PYuLFxY+Mg3418N/LdgD4T+kzo MwEWJi5MXJiYd0djf/j+8P3h8Lz089LPS+fFeTfG/l38P72+b3iDexpANze3f8H7TZz/Yzo6 JybAhKd4CcBeLQHYIQ2jJlBW1NY0EJ5SjJQMorS0XpcDNJPCRU+Q9onFXAD2yrHyVFB/zhr8 ZArY27/Yf8sT5AkB/oU+An2m6alBBddtq872Iei+DytbsgNosv5y4EnQdaCuUgkcEW+X5DaE tMepQ1+dBFz5n4V+C3H74xKTuoH9O/tV7SCIseK4Kwhs31pXYAKfSp7V/GZAwXaFqhVJgcBY v8uRKeDZwfi1jwmkWF0WzcF5TTudewas3tYTGQK4aQnNjoTsbWnRiYBR79PTGAPGONNRuQ3o HumKys1BuiVP0v0I0jEKSy1AaiFOSVVA10fdokYDUdrl3DHg+dJzgDwVPAN8kn08wXU25wTX wTBBhDmagH6RGmM7Buan9kPqQ9BP82gfcBxQlIXph0G78qxf6g1Iye/MJzcGfaKhjWd3UJZZ Wri2QFxf0/rz5YDggMu568Bjl6VysW3g1dj3U68IKNrQdLz+KWjsU/Vm1Xnwulxuo0dbYEu5 E8U3bgY/Dy9H8HmwVUzeIX0HdxrbnV5fg2c+7Ub1kVCrZZ2UR8mQlC8xOrMn5AzIHuvKhue7 s/UXokFt5og2RkDdraVeNOoH4cvj7fnqgY/RJy7oQ0g1JVnjB4LXhdITIz0gq3HOsNjiYOpn umF5Aq5F9tjUPbD9233Vjn8E+Qz584d7Q7G2EX4FF4Frkf1ndSSUVUvPixgDz0u9PPr2LHgu 9f7KUAyMBcwtvMNBv8HVTnSDTCG9ctQDw2O/oqVHQWu5xLh6myC7S0bduIrwanqyav0GXspZ a3O8QfZkoH4amOw5Je0/gOTr1T87C8weZJnC3mPb+s9EcdbgWYNnDYZKsZViK8XC7sm7J++e DM+bPW/2vBkYTUaT0QQt9rTY02IPjBkwZsCYATA2ZmzM2Ji/DxsWFhYWFgZrVq9ZvWY1LCuz rMyyMnDp20vfXvoWpOvSdek6VK5YuWLlijBcGi4Nl6Bkbsnckrl5cboW6lqoayFQP1M/Uz+D ra+2vtr6Cq4fvH7w+sG8/fR+1vtZ72fQ5UiXI12OkDem5F/Uv3z/8v3LQ07vnN45vfOmR0u8 nng98TpM9ZzqOdUTZrWf1X5W+39f/f9s76seQxjCEGD9pvWb1m+CS5cuXbp0CXLv5N7JvQMs YhGLoPvx7se7Hwf5hfxCfgHbtm/bvm07XF9zfc31NeBX2a+yX2XoO7PvzL4zYfiw4cOGDwOa 05zmf359/3Y6Qjc3N7ffS/qPL0YhatSoUaNGjX8+gNVqt9ts/GVWDTwAF3AbCxKIpXhIZ0A+ z4/SB0BnZrnCQVupbrangRQrN5VbgFRQ9jR2B25q/ko90L7THRBNQV2RfO/2ScgdfnrIodcg 4nXhvj3BUCr8VUgGiKJZD1PmgzzAd713fTBOr9yqsxco9aSPde0hM/bM9MvNIbn3qyGxy+Gp X5zuSRJkzkt/peUHx0/qd1oiKDY10PYYDD/KBkN9CGsUsDlgDoSPiFoQ+TmwQ/lMlwvaz/JI aSS4WpDjCAcq2QOd40HurG+k7wF+R6IuFygC8Ueenn65EqTL8jR5MIhb8jTREmzl7TdtS0FE uSzqMpA6iK5yTcCombSZoG6y/2L9CbR56tc8A/sTeSYWePsyd3zmALDeylyY+iX4hhqeSiXA PNHehW1gGqOVNhQBvc33oa8AQULP7BAwWdXl6mA4Pqp0o9fpELNS3vWgIvj0t5fzGg8Z+8SJ DA3SP1b3qKeh0FSvhBpnoYRnqFI+GuSx+im5v4K1uj1NvwkC2pk+Ej3g2k/Pw66tgqh473HV FkJq2tuRr2+A/rGnM18hSNqe6X2nABQqGNrY1RcMn8svAr4E7ogTrlhI3ZT+Jm0UjKrSb9TK AqBfJzfyTIBYrzfrHq6C6Bq3e+xeCPozjs3GNFDLOtabesDzV29rpAkILxLorV0GKd30hZcZ fD/UfVfkAmjf2ForvaB684oFag6CIC//Tzx7QPilfPf9msEx6+krj76HjL4ppV/dgHr+dU+V +wrsfo6C8jFQ/HTrpeVQal/ROfk7wd7cI7sutoSdEScK7oqG0O+C/OzDIG1uRrXcBxBeQ3/J Eg3SGO2ckEBERPqkZkL+S5G9vEvAJKXXd8e/+bOb+f973vWor6mypsqaKnnL3z0cWOpsqbOl zsKNoTeG3hgKQ64PuT7ket5QlvPnzp87fw70G/Qb9Bv+7Nq4ubm5uf1vd/ny5cuXL7/PHmcF gQAyJA9kkOqK60ggfcl1NoLWEYfwBvkeW+WOIIZr4a4uoJSRxnlkgrZNNFXKA4NYrD4Bqavm K6aBVN1xkhvAKq+BBX4AsS8rKWM1WDe//CRhJGjTHe1yVoPUL7ljRiroUvOb31wAaXz+16XO gmf+KvtKLgHb4dTgxNEQ9KHPvMg64Bxu0Cx7QWtlE85k8FvlWTX/T2C+rySqQWAyilLCBbnL rC+yJoHOUz/W+BL0W1Sbugq8M5SeoiSYPg6KC34Opv35Lxb6BpRi/pM96oIol7HFcgGyPrQe zb0L1gr2TTYH6L6VdulOg5pPGi0ygVaSXZoA8gK5lWIB0VYboZsI4qA0SP0KDIuVTKUlBHxp muCTDjkb7BOy+oAu3PldtgnUdbZ+DgW0auYlPp+CwBGTvQAUk/cMwwZAznktxoM2JrOsZx3w n+hXyzMOKmWU+SQqBl5Of/p1saaQODi1RKAvKB5qfWkDJO60dc7sCaaXXjYpFNgnTyu8Hp5l xPeyXocCzeXbtXuBVjd7u+4siJWuqKA9oJ6znchKhLAc/+YVO4I1IDsjswM4akuB5IJ6gN45 2yD3W+domwVOJF6bemYymJ+Yj4TOh6tNHu/8uSaUH19gVYQDjOHWAX5RcL3HncTMLtDgUAXR 6BkkN8qu+DQ/ZByyrr5dCLxueJ8NGgPFq5QKrNUMiuUUXxr2M7y48ux+fGcwDc24bfwacu7F n469BSWul10XmQ7OebapshnyfRt5K8gOt6veUp6WB/0BV0/hCaZHSsGUA+D1hee++BegP2Iu r0yC/Fcd0Q4b2HZ67sABxgG6eGd/cA5XLplnQ/xsx0XHM2Dmn93U/99k2GDYYNgAVwZdGXRl UN4PV2wavmn4puEQGhEaEfpXY3DfPYTYdELTCU0ngD5Vn6pP/bNr4ebm5ub2f5s/3uOca7fb nICGhgvQMKCAFEEqTqAqsVwDMQ5fKoLkxCrbQbuijbK3A/FKmqE/Bco8KZ5CIBVhhTYRRHER JBlAjHBsyP4GrK2vPTrxCKzXH3d4+BZctazFcseAoYJv32AZDNOKDy37Lbhm2b/OXAI+U6s9 aF4D5BJyD0Mu2B+/6vn8LeSMvTXjRjO4dDjNmLsD3mopBdIKQ/4kr5X+zUG3z9HNng2mkdJb pSMYz5mK6SuBMYZ412AIjsr3PKo/BLystrbqeZDlcDXoAUgufW+tJtieXV99fzvknHl5PuEL SC2YMzhnP1iT7I8cZUFbyAwtBxxvHTcct0FUk9aLGKCc6KVVA75yJWqLQQtzPtU8QQzWBSnX gInGksYUsJ6znsyaCxk7En3jp0J29q06d2QIfBg0JuQQeDYPPBy2ALRs370hB8F6QqtvXAYP f/F02duBZYHhgastGJaIe2p30J5bV8tmyDpo/0b1A0vrjJ+1/uDK55qRswXUdGuMcxfYJjnX 2JqALlfvUlaCdtdZ394TXBfUh3IYGKrpY43DgIpKR+EPxsOmMd6HwPOBoZfcA3QfmhaIueAo JR6avEG16TppIaCE6RbKKRC4xfeU8wx4Of0OeS6CCutLzGoyDpQ3rmQtHzyKedLvyVUITA0I NTeC+Fbxtx49h3r5GoTU+BVcr62fBu+F4N2hdc0PwTvWs6tPKchNsw+iKLy5+lLJvApatNX1 6iyUzagyu0IGPLoTs+R1B3jp+6ZarBGSP03yeVYI4val7o8bDYrFJztNA0+TaW7WAZDHpPdx 9QX7Zo8AV38IqOY/zv9LSF3g6pM9BawT5d5ydcgJy1iQkQjfRU/cfCHtz27m/+9Km5c2L20e LDm75OySs3Ch7IWyF8pCVs+snlk98+a7bta0WdNmTWF49eHVh1cH8ybzJvOmP7v0bm5ubm7/ t3jX4/zHE2eHPdf2HKTiUrhUCsQD8VbEAQkkS9UAlTTSQOpMkCgMVGG5cgzEj2KYqzwwRZ4h PQJpoIgUk8C1lEW6AyA30T/X3wJ1eszb4/vhxc6tk7dEQdqvOZ+YtoD5gednPqPAv5dXlMEK ZhHwq7QOPB5WPV3fA8xeZTrXKAxyJHHKDVBX2kxZ98C16nrSze/hqfZkws0+kDtNyxC/gvcP 0vyQW6CeY5khBbynee/xLQIeUcb8Hv3AXMXzhUcsmJ2VE4qNA34IdvjmB7HbVtZ2GXTfWuZl zobcoIfHX+kgZe/LiokxkO1l/cRaCZzdpbaaAsLCcLEAHI8dKxzfgWOwy2j9GuTpBItiwDnt Ij8BkVqUUgG0fVIfRQNSDa+VzaBWEQNJAttF2weW4ZA5+O3j3O2QcTujq+0ZKNtDlwdMATHD JDx/gAynY4+1F6S9cWWld4fUnCSRXhIsuowpmevA9tJSO/Mx2I87NrrSQb+F2/J50Mu6FoZN IJ/X99drYAox6gwvQdos25XaoDj0RfUzQG4s95MrgzxZHidOg5ghSsqRoDVRMygHzs+0r7UC oNWmueoN4p62QzhAHidP1ncFZYqxmOklGIuZHkm1wTDaxxi8AfRNfT38Y8DvecCNgCjQFTKX NC4B5/PkuBftIKOW9ePHoVDEI1KnvwXqDsc9j5rQcFaD/P0bgHmcrquzLTjvyzoxGeRWjkLe RyG3/NsKjxpD7mvpU7kZsFe7Ju0C1SQ6GzvDw1LP21+0gdhi9Xy6C7J65YyVPwB9X9Mm1zCw FjTfip0PjHF8IS0Fq9lZSxkPpl/9Wuhi4PXDtDrphSG1QVIPLsN+x9JW52r+2c3dzc3Nzc3N 7Y94f0M1cqUAaTqIKmKFOAySp1QUA9BT3OFTIJWxdAFRVsoWCkh1hEXUBsKUNdJA4Jg2UFoH IkEU1L4B+XvlubQfdJ9nrY1tAA8PbtNtvwZXP3m+XXSHQo/L1alkglKJ9QZXvgDOgNiNjy+A 7rznRvkK6LuEp0duAjlcP8/rc9Ccrhv2JaB8YqjqORdyh9st+ulQ6HpY06iWYD2kjcpJhYTd b6yOaiAHmw+aN4Bhsz5V6QmGIr5tzXOAgYbOcgK4amT/nHkR9F/57DA+AczpJzOyIWfXo1cv SkPurIQVORo4e6pnRAIIT8mH6aAdVUeKK6BdoKkWDtJRuZLcGuTmrgDtM1BDRaijJEhh0mH5 CMjd5YlyMsjdRLJaCdBrXzAVHPl0s3yPQO4oz1+97kPukKiNzpKQWt23dO4YyKmVvTBtC6R/ Hzcu5gCk70h4kWiAnKc5LW0hIMfKt7Xt4JXgNcY7HAJv+N30/xJM2d5nvQ6CcY9HqGkp6FaZ 8uu3g06RN8rfgrZexHITxBVhFXtByk9rMRV0JaXPpQMgXVCipTuAUZqlnwlKhLyISJBviWVS U9DCtF7KPdBaic9crUAday+k2SFnjz3TegdszayyWglyr78NSmwFYmjqxaRWkF3wbVU/J5g+ 8arlFwLeHxsrOVLAf5XHLP/mcLvj01N2AbXVKIsUDk9/uLPkwiuwOOReHssh3/LQzZ5RUGtL jZMNi8B1v8eTYtaD9YTRqm2EIoWK5QZ9C8aN8iQvC+hS1cQyfcCvjO+GqjXB42xAl8A5cLLU 5Wtb1oGanPllQhcIvOHxpTQCPArILyt/DXd+fHvkcmEIbBrymakVqJtFGfu72Sti/+zm7ubm 5ubm5vY+/PHEeaD4jk1AXemeZAFiaEZz4CHdxcfAD5yR14PIzxJlAEh1tFcuHVBKdFHKAfOl LH4GLZNGlAT9D/r8ujjI+eqex9VYSG12Lzu5EhR4XCmnTiKUGdeifYV54Ls5NL9vA3BW939R dBWI7dqz3KHgapPdK6sBGC+FbZW8QGoiKstZoDVzzLOfAVHR6U8yZB9zPAraB7atWVecVcHZ M7Nj3Deg7bONcM0HS0n1K+ljMAQrDeTdYPyotCPKCyRftrsugqv3y/OvreA4nXQifR5oO7LM rg/AVUu+Jl8B1wTnYa08iHTXUZaDNB6TGAa6hvI+uSs4v9ZStHbAakmVOwMztXusAFFDFNca g+ilbnWNBx7ox3nOhKwG0jyPjyEp21lWs0CqsDbL+gRSF7/ZFVcWkg697vZqP6SJt58ntAft gvqDqyN4XvbfHLAIojyLFinoAg+zn+J1E/TfGk4pR8B1wjVes4Kjp+1rqw5yUzO/z+wAYmz6 SHEF5J1immQEbTsdxG5gjBwr+YAun7JQtxMMyYqPUhiUkkq2ooHOrPjKP4JWQt4nLwK5rZLE LdDl6LZKRjBU0y3UbQQ2m0vpfcAzw2uIVw5oxZR0uSo4M1zLRTWwZ1jruSpD7sWcD3NKgq1K yoGslpCyUJlriAbzWq8t5lQoPqZMw9rhYHzhF+B9GModK3YwvDYEx4ZFh3QH007TDcNAMHY1 DBUzoWJg01X1vMH0pbmZ7hAQyCrqgNKPcHkHGDp4GAMagu2taKl+CL5VzN8bZ0DZzJKde4+F p34vsp6HQW4bh/71cfAKC9R514GCTbxjnyyArKKeuZnXISwiXz2vsoA7bXZzc3Nzc/t/xnvo cWa8mgJ8KA7Lm4FZFJUSALu0mu6g7RFjVB3oVvFW1wgcb6VptASpvTgjgkDuovSWx4KupWuK vBa4/R9hXTWT01NqQuEedTrU+Ayihg8r/nEoSM+8yhvskFvqRf0HZUANs/XK2A3yc/mlKz+Y thfcUW4SaF1c62x+wCb9TWkGaC1e78yYCq4G9n2qCzJ+yp6V3QEyD76dkbIXXNutAbauENzb t5L/dAjaEdDcKwyUH5R8RIB67M3i1FQQ0wq9DFkFynajTecDnKWgLhpEISmfKwqURkyWjKAc 0ebSCySj9EKaAtJR0YkIEJW1WFd9UM5Ls4QBlLXSVPkn0MpIl5SPQWwx7PS4Dfb++i+8FEgZ r45QasLbFbnbLD6QWDf+1YszkLL68duHxyDlRvKDpBOgtDFONuaC/8qIIuFfgefq4DZBrUBO 0MdgBmcny3VbIGQ9S36aGgmObo7BWjlQ6skV9Zlg+sxsM7wFjwDPHV5DwWOGZ3XPjWAc76GY GoOhh3GFMQN0O/UL9KdAJyuV9QkgjVYO4g2iulBFLkjDhUHrCtoldbh2F7Tl2nGXAtoi11VH PxArHJVcQ0Ar4DKoDwC98xdHP9CluD6UrGBA/kz3HLxve5kNs8C1y/uuMRGcLZ02LQ5yRlvC nE3BsjN3e+44ePrLhQ9PVgR7bsSR8CtQ3BU6rG5DCNflnxr4OWgbRYDTCdo110dmJ3j19KxJ NOT0y/G1hoB8Tv5EvgQZ69N6WT4F0wDTUJMDIlcEzPHOAfWca5C2ECp+UO7rEmtBd9e0pkAp uNz3Tvizo2DLVBY5pkDpkOLbim2BGwdjMvd/BzlHHMsfLQf+F/26nJubm5ubm9sf84cTZ11X /Uemj0At5izkbA4Mk76kHrCA9dJckJMZLW8HR3NXS4cRHC+T57/9CAxhxiSTE+SNAQEBd8G1 2eHtqATyM50q1QTDmpI1ik+E4B5RdjUb1M+87F69gclZdxLegmKVuzq/BvWRdVVWV1DCii+r eR3kA6bpvqOA2moBdRKIYLWMvRPk9nlRO7Ew2JZnfWbLB65WtiRtCnBNOu2XDa4TUhlVhjev 4g8lxoIrwJ5gMUJY4cjiBYaCnOTq5VwK+rJMFLtBlItMCv4A9JEhC73Pgthqi7NNB/yyb9m3 ghisnySugu6ReoHF4GrsOKgOACFLD6kHYgCLqQa6Q7o5xi5gsxtXee+EzKWG4+YJkKzZLjoS IfGDN51fToLECvfX3fGGJN/XjldTgFummh6hENi6sHeRqWAuE1jCrxk4SjpLOsdA9rikh6mD QK1mq6Qmg6mJeYjhCvh+E+jr9x34bQhpEHQF/EYG/OzfB3ynek/z6gPmJZ6FTF1AN0P/QtcE lINSMWUciB8ZJJaB1lcMYCnIH4ogKRFEf/bTEhgpOolNoF5Rp2ofAnvoKJoBp7TDwgKuH7Xr 2m5wNVF3qo1B89RuqIdBJDiHO6+Cs511UG4wqJ3sxaz3wPWjetwxCVwp6iIxFQyddQ+kymBa 5LvN2Bt8KvoIkwS539vzuYbC2wGpg5ID4cehm1v81Af8LwR8HLQDQhYEtw8qBZVjKwwo8SuU LV1mX8EFkDk6da90HxwDpfuua/D2VsLJ1KVgmGUI0v8K5T2r+hfJD9Jm3Xi5LShW7bpzHZRY XMTXcATuPL/b3vEJPHl958CdKPA5U35GmaNQTy2zpc8ROPXo0vi9pQH44M9u5G5ubm5ubm7v xx9OnM/UuzDy0iioVa7q/aq1Qb4mbRMJIFaLJO0WEC0Nl1NALi/9pJQFj9UBScHXIKlyQtfk FPAtaFpqvwSGi4ZS0hegrVc92QKGzqGpRUaBeiWrV/Z6ENUcOvtPIC2QXkmHgCy5szEO9MOK NK72NeiXBYnIG0C0/WbuXRBjdZ7650C/3PFaFig37LOEBnKq8sS4Gzy3eyYZboKXp3eDwEbg zBLj8/8IFo/EpXFlIO67pxfubAPrjrTUlDoQ9lNUUMG3YLxpbZ8TBcqG1LA0A+gifVr7PgCt t/OJ6xbILeSKUhMwfCAayVFgX6AJbRfoaigHlAXgaqDV0fqBWgeDbhu44v2O+Q2FVKczUpMg blbykMRvIGHtY/2dCfD66sOQB2vButY1UysAvhujiudrDcbdgeN9fganl3OzOgdSGsfNfjMN 5CfqNcIhuF5QvcDCEJpW6mQ+F4Q2iFwdOgd8f/T39PUFj1PmCaYMMJTWr1Y8QW+QzktBoEhC RxcQV9WmoiJYH7tmqt+B9lj7UmsM0nP5kWwA7ZrrlToRXAM1qzYMtHLigGgOSmPRgnwgDZEa SmVAeSivFr1BqYyQkkG5yDqlOkjI2TKgK6sXhlfgmGxaYT4Mrj5qdVcIiA0ui8MK9tqOabaB 4CpnLWmtAY4h9kXOoaBMUCUtEwwhpkryTfAYb8rx+wCs96ydHSUhrV9m8bT2kFw0yze9HGTP zLGmL4K0q8mV3mZD/Vv1L9W/AYaffJ/6FYCgLkE7/TLBVUMdoc4CXX69Q3GA2sIVL2LBpbiK yz9DKsnGnG8hZ0TGpYQzkOlInPbsW7jwNGd3bG8oMa54ZCk71N5cpmfjzX9283Zzc3Nzc3N7 n/5w4pzdOj3KXhN0o5QsqTi4mqkVND+Qe0qjOQBiPA4xC6Sucj3pKiiNPSWPSDAFBE7ynQTO Lo5bzljwbOo9zi8bXC/Uceo6EOvNN4IGgy7TFO5vAlexrLepLUD/lam0+Soo1cOHlJoP0nPq KcsAHKNzK4H4XOmvvAJRVqqJL4hW2lNtHIi98lxRAQjmM200yCOl0a4O4DVMLms9Ac7RWoRz Lxh3+CfoCoMrxhIe8S281Sekv2wPzuPW5JgaEPxF+JHAKeDV1O9OxGjQ8lt72z8GMVtqpzwA 52bXSudlEKu0VcIC0h1phDgMcn9nV8evIDXQzdEXBnspz1FBIRAban9ki4XYb1+OftwPXmXd fHJjHyQ2f8Or6aDE+ff0bQq+n0WWiYgFpbboKa2H9BJvSiQ5QDdKsysLIXJl5Nzw8lAgrviR Qp9B8NZ8SeGrwbeAb7bXCTBd0R8y7AZ+ZL3SCNRWqqq+AnmOVk9o4JrESGqAfaa6Uc0H2lgR ggFoLPnL34HBotPJ+UA3WOpJLmiB0tfaSHCddW1QuoBtlHpfLQnOTGaKo+Dqon6t9gdnJ80o ToGyVf5KigK9UzosbQO1lPaEQ2CX1GTXDyDKUo0RIEWIHVJlUC7qNpm+BdFH+sRoBuUj/ROP BNDnui7Yx4N+lbWO9T644u3p9nugq6s+dLYGfQdzSSUTDJ+bjvl4QPbW3GT7EHjTOmFPUiTY xtmnOrsBL40NTJ3Bf7HXV15lIDszY0dON7DWtYzJ+QnsCY66Dk/IHWzzd6RB7ivr1tyK8Cb5 7f70tmBZa2mffAh8x/rOVmaAtbg9XG0Bdz98WPneSkjem9LoTSGoR33q/oH29e4HPHJycnJy cqD+lvpb6m/5+/UyCmcUzigMv7T/pf0v7aG3pbeltwXWVVtXbV01GDJkyJAhQ97/F8jatWvX rl37r8f/o9u7ubm5ubn9T/rDifP1n55rd55CVPzDVpFroHLJ8iOLT4acErbJdh9QGrJJzAI2 EC8Og2uO0+K8AX4dfZZ57wb2iFPSV+DIcjZyfQHSSEnhBEjNlXNKBRCBLNM9Ad0Wn0STEfCl saQH7bDaV7WA/BGlHc2AIVJv/UegPRDz1DMgHyJGewNie26B1NZg35aekfwS7K+sZ9LTgKYu V2o7eLT2daln8ZBaK7FHfHvINzvki5Ca4L/Vf06kCple5teexSHdz9VXegCuTm8api8G7yGW wdlW8K8Y5Bt+Aoy7zDV8zaDVVItpa0EKFqGSFaSnjs7acJAX6my+LcAS7dvC+wE8npPVMC0S XmTeO3Z/HTwffWPX1VzITrY9s5QBj9jILflzwdDBr7/nNbBuzryS/Qy0Yjk17d9BuC2ifsQ3 UKRXmTJF4yF//gKv8o8B7xO+Q3yOg9xCOSJPBOkLaRK7QUSqp7WnIDpq/VwFQezmC9qAq5rY I4aDKMMrZoP0RtbLp0B007y14aD9pA3UjOAqxy9cAt1B6RXzQF9bKS21BLFfjHIdBFHacVo0 AWeoOla9AK5McddVCMQz7QbxID1RJ3MAGEy41BXEKyHhDWKMyBLlQbwVTUUBELligrgCYps2 VesD0hyc9APXVfFW8gHRT1lhjAC5rEd5QyLoIwxP7aNAvuf41dYTdHrHJnt1UAIcOxxfg36v uYPBG3If6kboa0G6Nev7bCccbHxYd6oK6D7XnzFvAP0p5aoyEnLHZZ3JeAvpc9NuphQFtaYU 77wNmo9WzpUMritinW4JGK4Y9kiVwRWieXgGgJ/Ov5SXCaQdNFfrQtKltO8yJwI1Kcuqf719 FV1YdGHRhfDTtJ+m/TQN6lasW7FuRZBvybfkW3nrvfvJ7cLzC88vPB8kk2SSTDDwysArA6/8 +75ABlYcWHFgxT9v+383cU1cE9dgd7PdzXY3g67pXdO7pv+ODdewhjVw586dO3fuQExMTExM DDgrOCs4K0BwbHBscCw0fNTwUcNHYLhnuGe4B8/9nvs994Mrq6+svrI6L1z1YdWHVR8GhTMK ZxTOAPWKekW9AhdXXFxxcQW8/vn1z69/zls/f8f8HfN3hNp3a9+tfffvz5e/dazQsULHCkFG dEZ0RjR0Ldy1cNfC//zx+tsLIfeFkZub2/9r/nDi/GJTSp8n5+B0gVvVAixQ6oMSOyMHgC5H fiUvAvGdaCsVBzrzkoaAgxhcoJ7RjJoepPrSQoaB9FD+mgnAHrKlAGA5ZTAB5UV7bQ2IxdJi ZRXgEvPUT0F3j+OiAohDWOQnIO6LDk5v0C/QH/PsCE5Tas8X/SB7wIWip+aAWiipb1JnEDfU 07mV4HmT+8uflYIbnz/88Y0fSNvsDaQY8BWlxnoXAv0L5XTSh6BOxcu7DBicfkr4r6C7qisi nYfMXa5jaW3AsTEjINkC/p7OjdbBYD5h2GC+A1IpNdAwEnSnvSsHL4Ckel4pAQvhwZSEt290 8OzKNelqH3jsee/I9VRw5FecBh34fF1gboEckNN0wdIAyFr+ZnXqLfBVPKqbG0OJArUiK12A gmdLTiqcAEHLAs4G7gH9JP2H+p4gHWAtNUAsUiWtIog0LQEnCKsYJMwgq3zHclCmsUDSQP1K 2sqnQCttufYNiG9EkBYB+uq0lvqAOCKVYQbIZbV7YiCIS2IFO0Ecoo/WFdgu8om1oFSTC4s0 ME2VgpVcsH+hHhHVwSVjFDJoS7RFYg6op9Tx2mPQylFQGIBaYp+mgWgtZkh9gVTasQukX0Rb xoBoLLaLViC+RyYA1PmipsgPtBUpUhJobeT+Bi+QgowHlC9BX14pry8P4pD0Qe4kYKKzrutn kIZIt6kFyi1lj2kGZJ6zFJA/BfttdYLzGngH+R71jgHDPE/VowLYD0qq8j1klkq7mWQGnsj3 5KogdoupagBYu9j2uwZB0sqUczkjwXjeMFB5DV4dfRqbF4H2RuxTfwL+YNLq4+Pj4+MDfhP8 JvhNgNcNXzd83RAKUIACf7Xeu8S53ol6J+qdAFrTmtbw3a3vbn13C4ZUH1J9SPW8RKbm7Zq3 a96GJ75PfJ/4QospLaa0mALRC6IXRC8Aa2lraWtpKJRWKK1QGtzW3dbd1v19AvRb8SsMqDCg wgB40exFsxfN8i4AqlatWrVq1b/fvnFA44DGAXDjxo0bN26AGCwGi8GgrlJXqaug9NnSZ0uf hYqrKq6q+AcuRH6vZzuf7Xy2Ex5tebTl0RZI/yr9q/Svfv/2j8c9Hvd4HMT7x/vH+0PnSZ0n dZ4ESg2lhlIDztvO287b4HLly5UvV4Z61KMecG75ueXnlkOnfZ32ddoHYo1YI9bAPvs++z47 FKYwhYFbt27dunULHP0d/R39oYeph6mHKW/9k1kns05mwc2dN3fe3AlVqEKV/6a8Lya/mPxi MgxOG5w2OI28Hbm5ubm5/R/kPxqg0CCzLnQcvBavriRMgZ8vHjh+5hmYjhhs5q9AqyGasQyI IJ6HIH0lLZYWAyounCAGiKl8D9JycUyqDhJEMADECVFEfADSZGmTEgPyJhGt9QJuU5zVoJWQ FureAI203S5P0HZLfowCtYSlccI8cBxIGHF/JljrvfSLOQLaZ66I9F1AltbJfgxMP3qVMa2H OoNqNazoAbViGrvq+4BxdXBOZCVIaWvb4PkLSC6vBf47wPOF2ctjEuhUr/Fem8GzsnfFyBUg Viv1AgIgc0VmYYsPZHxsOZf9E9gfeoz3qQzJb7zb+1+Fh+fe1H9lgJgNZ8uffgQxO28uvhYG jh7Gox5HwBweeSz0A3DVcDjsKlg/eNs4/R4U/jrKFLIPGlVvPq9Oa6h4tvqtCt9B1I2IYZGl weuFYYrRCkoL7ay2DnRHRTGtOZiWyL3ktaCvQhH5G9BVE19IVUGKFS1YCfyizlWDQfeBdlaN BCWW+dojMH6gdJFHg15mrwgD6XPXXtctcGxy9nd1BesQ5/euNMgd51TU9aCNFaspAMaHersY D7oD0iHXIJA7aQ21aFCmaWdcF0AJErIoBrqrci9yQLkodxc5IJ2XgqQyIF2RxohaIIfRRHQA 3YdyvNQfDFtlnfwY9I2ll1IVMPaS1kvtwTBQ6k4wGOZJ10QHUEKlHtJwUM7rMo0XwSB5PPVe DeZ95lYeb8HjS3mrVBrMm6WVal/w9fCqoa8C3h/rcpQtkFUxJSrlAdgr2bOs0RB6O2xK6AOI PBNRrcg6kO+Iy6beIH/GeuEJun7KLOUy2EY6BmidIL195nTLPVBvqa3VbiA7xHxn5PtrqMWy imUVy4JnO57teLYjb3nmicwTmSfA2d/Z39kfQl+Hvg59/fvjdu7cuXPnznmJXJH0IulF0qFH jx49evQA3ye+T3yf/PPljZwVOStyFrRPaJ/QPgFuf3/7+9vf//b690beG3lvJFRZU2VNlTXQ PbN7ZvdM6Pi249uOb+Hq4KuDrw7+58ths9lsNhs4LzkvOS/9/u28H3k/8n4EZcuWLVu27D+/ 3webH2x+sBmqSdWkahLoRuhG6EaAVFWqKlWF6tWrV69eHUqfK32u9Lm87d79lLj1rPWs9SxY z1nPWc+BfoN+g35D3npPGz9t/LQxVNIqaZU0kNZJ66R1IMuyLMt5y//2fPlb7xLsdw5EHIg4 EJF33I4fP378+HHYErMlZksMbG+0vdH2RhBdJLpIdJG89X7v5/B74+3du3fv3r2QEpUSlRKV F2f//v379++HM2fOnDlzJm/5uwuVk8VOFjtZDBwOh8PhgCNHjhw5cgS2eW/z3uYNhzoc6nCo w2+X+92F350Rd0bcGQF7puyZsmcKPJ/4fOLzibDr+a7nu57DDt8dvjt888r/qMGjBo8a/PPn iZub2/99/nCPs2yQ13kMhIa7Kxrr3obq5srphduD1el4Ym8Lcrx8UjoG0gh2ihwQh8VzURO4 zWUuAnOkadLnIK5rtbXXQAktnizgB/mwlAu0YbQ4AeIxVaV+wGNuisnANnLEddBSpI8kI8jb XAtTfCB1wsEaG38FzXrpq/tlwfR9rS3Va4Ao5t3cdyBISfd73AL8lxovGJZCZhV9Of9m4Nht 1JsSwZnqmOb5DWgRprqGVmCub9CMI0DXQDfTcySon/KtczcYmsg+wgiGhz59A5ZDboDlqaEV WJeZahnrQ+75gD7h38Pdw6/vxZWGex+feXDGCc/Mj758agJnGZ+rHgPBs1hAVf9Pwdk5O9JW AvTbtWjXbSi/qlKLMkDJYRVWl4iD/KaoVflOgsdSXWf9JMg5axluWQ/27mKYWAmGrbryhmgw fak/aCgFjin2evbvQMnFiBcoM+UAPgXNqhm1XcDP0nRRFBxlXYGuHqBNEee5A7aWor9rLYgA 1Sy8wdVci6EcyM+kadpkkPJp+cQmcL4URaWaoNSQCopCYFijbyPSQE5jpPgSlED6iMeg5MjR UgtQW4tG0kBwVlETyQCqikHSHZB2oanLQBlOG/aD4bCusbwQpDRpAvPA9a0ao90FaZYK9UB7 Kj4UtUBrwGPJBHKG1IAEUDtwGS8QF8Q5MkD6RrolR4JazxBs2ABaFz6SPgajyfbAZgXsjun2 74HH5htKUxCZtOUAZBe2NrW8AiNmYXRByCf5VocsBGm/0t3wObwdF/fxo4XgukWw/RCoC+Qj QoVcc+4ptRXY9lhNjgfgkaMMliPeX0Mt8lWRr4p8BVdDr4ZeDQXXN65vXN/Ai5EvRr4YCUX6 F+lfpD8wlKEM/cfxSpcuXbp06bxE7o3+jf6NHhotbrS40eK/2m/3It2LdIczd87cOXPn95c3 4peIXyJ+ATlGjpFjQF2rrlXX/vb6HfJ1yNchHyT8kvBLwi9wv879OvfrQMrRlKMpR0FsFVvF VqAylan8j/ef3Cm5U3KnvERLd1t3W3cbuuZ2ze2aCx4eHh4eHr+9fcj0kOkh0/9qwVrWsvYf 7vYv0rumd03vCvFr4tfEr4Ejm49sPrIZ7BfsF+wXILxteNvwtlB/TP0x9ccAj3nMY6i7qe6m upvg50M/H/r5EBBHHHHQJqxNWJuwvPg5JXJK5JQA35W+K31XAk1pStO89/0a+zX2awzZd7Pv Zt/97XI28mnk08gHnvCEJ0C7iHYR7SLgeNfjXY93Bc8YzxjPGOi1odeGXhtAypQypUy40vBK wysN4XyZ82XOl4Emz5o8a/Lst/dzrs+5Puf6/P54+X3y++T3gTft3rR70w78r/hf8b8Cubm5 ubm5YO9n72fvB6STTjokHEg4kHAA8r/N/zb/W7h27dq1a9cgIiIiIiICWma3zG6ZDfd/vP/j /R/hUv9L/S/1h4bbGm5ruO23y/3uwnJjrY21NtaCLkFdgroEgU+mT6ZPZt6zB+8uPEtQghK/ /zRxc3P7v9Af7nF2XDc8jbfAU8/Yz4+1Ae/iXr29KoF8RUzR9oBkF+fFChC9xCVsQA6veA48 4ClPQf5WuiyNAEddx2tnD7DvcpZy1gNZkyvLb0DsEktFGJBFlogDqRJ+ZADlxDPiQf5MwylD bsaVYqcDQaqfnpVbFaThpVtXdIHPZ03u9toCwZY2hwd+AL6DW0Z1KQHBvav0qpgNoakBa70/ AON4flQGg/qJ6ZSHCsoO3VVTLCh7da/NAuxXNC9rOKi9HOPVs2Bva59kKQK2LpYWGXvAq0Tg 8ODq4PIqeL6UDPcNb75+UxNi1p3dd+Y+POv2qF5ML7Av8t5nfAymxz5V/HqCs3NOSG4keD1R pshNocaomq+r2KHyr3UWV/oZ8vfM3z1fedhnOFT90AtYm7r57o+r4IeRO7ZtXwFrvDZM37AG Tt49f+TMx/DmZNKZuO/AcMTkI9cH2aw7oZsMrmvaafE5EC0v0fUG+a1hrH446D80NddvBo/j hg/0Q8AwhHHSBZAeCG91FpgGyTniMhiayHOkPcBocVUUA7WBWsA1Dqw7XSucg8C60jbPVRHk waKeVBZ8Ms2vletgmq/XSQVAr5cmq+XBUEyaqi4HjxrK9+QH81L5I+ku6LfIUXQHdbf6RN0F jm+cmus6OI+oiVoncE0iS+sHrrm00WLBqYohrgxwXdNGqN3BZVEXi53gaiPaaD+Do52oL5LA lSRGUAzk1zpPfXcwbDV97eEBpifGs6Yt4LGcYFEGTCmmdVJ78A4xxStTIftkepPUR2CZYDme XQ/8joSM8TkIhQsUuFbQB0yV9We9rWCIMU73yARtpjzUVB5yNuUOE/XBNci11zzj/TVU4w/G H4w/QHh8eHx4PMQGxwbHBucN0SgaXTS6aPTvj/euB/Qd7ap2VbsK8jp5nbwub7k0RBoi/Qtj U//RmNq/9a5n8MnTJ0+fPM3r8a08uPLgyv9CT/O7oRXvhnq8S1hzFuUsyln0hz+Of8jlcrlc LrCctpy2nIYuBbsU7FIQ+pzpc6bPGQh8Gfgy8CWcKHai2Iliedu9S/iaT2o+qfkkaBbQLKBZ AFwbfG3wtb86Du+GZPwWsVasFWv/8Xq/5d2Y6UqDKg2qNCjvAosb3OAGVLxc8XLFy/Dqp1c/ vfrp/cd7lwC/S5yTDycfTj6cdydDHi4Pl4fn9cgnzEqYlTAL8uXLly9fPng5+eXkl5OhZK+S vUr2yitHKUspSykLxLWJaxPX5rfL+7cXlhGzImZFzIKTPU/2PNkzb6jMu8S5RfMWzVs0//ef V25ubn++P9zjXK51/u21JoFByA8y/eBN8USPxBZQrFzRLYVuQ1a1nI7ZI0F/XP9QPxIYz2Yq A/0Iog5wUVzmGmR6ZERkHYCAGYGeARbQuonSWhRIW6UIaSSQLi6L2iDuMIZtIO2UV8ue4GqS WSZZAWv92PD46+BMSAu03oTgi/1WDdgF+rPB3SNug3OEPdVuBeOWAkfLLAXxkf1L+zXw71p1 ll8aeEy9sOVJU3hV8+X55NVgG0OUXBNcVRwB9hNg2G/wFhaQ3zqfqVEgHVCj7UtBqiCEtBls J7wOen4Iz18nPUyaAo/sl8ZfOAFPkx+tfvAFZHXxWGa8Cr5JXvW9loOcYm1kvw0+No/WpukQ 8bDosfwDIfSroifzfQOG2/odxqFw+8G9o/d7wL2mMTnP6sDr+NjTb+ygjFC26F+DLVN94fgK 7uhjPnieBYdWHqt1wg+q7K5oKTcOSjQs+rBwLigf6woa6kPiwMTcxLoQ5BX0S9AS0DURT/Wd wTxLr6peEFIqdHZIJ/B8YJ7hXw0cn9gvOb4A5x5XmOsgOD935WidgQZyC+VLUCaKOtIAkAN0 n+oskJaUc8hSCjIbZemTT4JvV++P/ZaDYZdxmSkFuKeY+BZcn7kqun4E52zXOTaD2lUMEBtB Gy2+JhnUfuJzvIH9PNG+Ae0zgbgIWEnnLvApY0QrkGuJj/ga8BRHRVMQhXkgzoFUVqiiLKhD xGOxB4RLnBUxIE+VX0snQCpoLG4aAobvtAxOgNcge0vrMRDJhqJsAgqJIKU0ZN1JfZm8ETyb +Q9yCfBfHNDerxSEHhNnpY2QdDzxytvj4EgRwpIEGQFZhe2VQHul/9jzl/ffYIv1LNazWE+4 ue7mupvr8h4SC5gfMD9g/r8eN6JdRLuIdvBk3pN5T+ZBKUpRCni68+nOpzuBM5zhzL8e/x9J TExMTEyEHsN7DO8xHMwp5hRzCsTFxcXFxQGHOMQh/vLQ3T/qWX93IWE1Wo1WIxhrG2sba0PI 6ZDTIaf/ffV4x3TfdN90H6pGV42uGg2Guoa6hrrAPe5xDyo5KjkqOWDTyE0jN43M2y5lTsqc lDkQFRUVFRUFIkpEiSiInhM9J3pO3nreDb0bejeErD1Ze7L2gB9++P3V/rN7ZPfI7gE+hXwK +RQCBjGIQb+//O8Sbrm33Fvu/V+s8J/H/93Dk5SnPOXfX7yQuJC4kDhIfZz6OPUxvAl5E/Im BMJKhJUIKwHKYeWwcjhvKIpxu3G7cTuYkk3JpmSw3LDcsNyAjdc2Xtt4jbw7BgoKCkjnpHPS OaA3vfkvyvO3F5YtAlsEtgiE1NGpo1NHw9uDbw++PQg3X918dfMVcIQjHIFWtKLVv//0cnNz +xP94cQ5vm7y58+OQ3OPOlHtFDh36/KzyyFg83L1sNeAQrH51KhaoATLvZX9QFdRWWwD7TWb tVGglVWzXHuBRqKv9i1IH4uK8hiQl7BIngbO3a6dzpsgF5CTlBYgRUhRDASckgEz8Nq2xDIK RDfrVXtx8DhVoVz1XNB7hJcpWgO017a7ud1BClBuG0+B+ASLvBxcvqnBlvZgLB3er3AN8O9Y a0qpn8H5Y/ZXtkBIj8xe7BoENDZ+rUsDrZnq42gNTHQWzjwKlFDbqa/AfjSiW8GJ8GJ/9mt7 CXha8FLkhRPwLOJet5vZkDZUX0q/GjxamrJ9TeD6xtnbURLkg/IN6TkoW31+0S+HFzPeLH7Z CeJOJX0anwW2/bbSru4Qvy/x1+QbYCttLeuoAro4uaNSD9QU0cwRCKK1K0PcAFeY0Iv7kLE7 O8r+Pfzy89FDp/rDBcvlzGu1QH4mf6OzQs4vuR/lngO5jjRaKgnm/KZAcy0Qv7BTagM+bXwv epSC7m86eLetBv4+voMCBoKhq76a0Qf0Pxp2GGpD1ojshTnJ4JjlXOFMg7eNUromhsCVKtfq 3hoBqWvSRqX6Q/Dp0BIBr8GUZSpq/hU8c0xbzb5QUSlfvbwLvLoZfb0vgnpT+0JrCVprerIV tLFillYctEGazDYQt0QLUQGkT6QR0inQRmqfas1A+KLyADRPESHqgnZUfMQHIL2kpmgG0lDt R4aANlAEiiRQa1Jd7ACtCetFDsgW4wLDJdBXo4f6I3jUtFa1fQziM8MUOR+Ya2j1lb5glTKT 0uaAnGucqy8CER0LEFoGSh0p+CzyQ/D50nDbvATMH3iU0fuChy50TcQCABr+kVk1/ta7hOp0 z9M9T/eE8vPKzys/j989hOG31K1bt27duhDtFe0V7QV3d97deXcnFC5cuHDhwn/VEz2EIfwb ZkeodrPazWo3YX+d/XX21wHTDNMM04y8Hvbg8ODw4HC41PZS20ttoSY1qfnfxHvXI1mBClT4 6zdKUpKS77/82T2ze2b3BO9t3tu8t0HBggULFiyYNzSgYq2KtSrWyuvBf6h/qH+oh9DWoa1D W+fFebd9SsOUhikNQaSIFJECvuN9x/uO5y8JcJGMIhlFMuBOrTu17tSC+mvqr6m/hrzZPP5z eZEtRbYU2fLP1+fdrBy3a9yucbtG3ljtd25VulXpViWI6hnVM6rn+4/3bqx28NTgqcFT4WGB hwUeFoAOBzoc6HAAdHN1c3Vz4UK/C/0u9IPi2cWzi2fnxfNp5NPIpxE03tF4R+MdENwyuGVw S8g+lX0q+xTEecR5xHn843K/s6vZrma7mkGbJW2WtFkCpW2lbaVtkL9n/p75e8Kel3te7nkJ XOQiF9//+eXm5va/xx9OnEuXK9aq6nTIne14nH0JvMd63DV/Ask74/cnfwr5PEJ8/OMh60Pr UakT3Jxxb8/lxRBU2/dlWGGIqfq6zvkuEOHvX7Zgc4g8n3O6hA4KxBXdXbA9GNfr003jQDyQ crVYcErqY9cs0L8Q6WI/MEq24AWGlfnmhGrgZawzr3EHcLWUA7gPssoD8QtQnDtaMNDemKuk gq6BfxN/QEvXl/IYCuaAEndKjAC/EvFzMjJAa3P28nUnWGO1n6U64HqQ8zY1ACyjs587A8C1 vtCB0m8h+SvPaT6l4NX02/qrx+BFydvzb1gg5bk2mf6gO+b11GseGCxKN7ZC1vTsijkjIL2B esk2COInZLR9WwBcIx0+2gZwVFDLar+AEmeYZrCAWkjtqVpAG+Ts7LKBvEy+gwW0za7lrg6g thJnlTdADor6FFx9nXPVdDBXM9X32gaWGtZQrRmoI5223JFgGmjcY/oOXJlaX9UfsnyzW1h1 oGa62kopkFQm1ZTVENaO+TFjZwfwmeBT0vMclNtfIq7ER6Cu0jZoteHB8xivR2dBN0BvkRuC tbrtA9tZsJLr5TgBmEVJeQhoXZQW8klwnHI8Sd8H4oFroOMTMBQ3puo7QhFHgdeFJ4LfA997 AbNBzFYfaoNBuo0kzoN+udJV1xxcN9WlzqmgdVDfUgBYJFyiDAg7p8UyoLnIIhCkCXiL/qB9 IWbI60G00dLVlSBdpjw1QAtVW6rzQa6nnOMOqPOlMyIL6KdXDH6g76kN1PaCOdY2zFkB+MIQ It8Eba+or1sL1kfpZVIXgJzkvdejP1SbXm9V5YFQ9U21apVuAuekMlQGLUoU5977b7BKdaW6 Uh0+qv5R9Y+q/+P1/3YWjN+aFiy1YGrB1ILQMrZlbMtYMI02jTaNzrsVHmOKMcWY/vX4v3d5 2cyymWUz3/9x+3fb02JPiz0t4CM+4iOghq6GroYOzhU+V/hcYdjqtdVrqxewla1shZBWIa1C WkHjHo17NO6RF6fu6Lqj646G6B7RPaJ7AEUpSlFoYGxgbGDMW6/yoMqDKg/Km4Vj9+7du3fv BrFb7Ba7ISwsLCwsDCpVrFSxUkXgFre49fvrU8+jnkc9DzgbfTb6bDRsS9mWsi0l7/3gV8Gv gl9BvU31NtXbxN+NsX5f8fIn5U/KnwTJc5LnJM8BrxJeJbxKgC5eF6+LB8sSyxLLkrz1CCOM MGjYsGHDhg3hzIdnPjzzYd7QmXdj3Wsvqr2o9iJ+s8f5b1UcWHFgxYGwP3x/+P5wkCZIE6QJ IHWSOkmdoP71+tfrX/9zzj03N7f/WdKlS5cuXbokRI0aNWrUqPGvB9KCXIPUa5CamrYh6SJ4 DDI/9dsHd354+PzkGIh1xTrSekERXdFtpY9DYtfsTs/uwv35zwufDobwFM+N+cPgdeGEKfFH oWVs3UN9i4N3qFc70y3wM/o89y8I/peDZoa8AHWxaCFmgro25dzdR6Cmqdm6qmCYFL6zzAyQ b9qfqxKoMcp0dSwIWSorLwadn7pSegRqH2MbuTDojsvblFtg9Xq44eZNyCy8P/BwHLwdkdg0 cyVkV7QvzX0Kjpe5Ew2RoEssUK6kFdT0SrtLB8Czg4/m3Z4Nt8OO5tszEp5cSRqcYYHcBh5m 33Pge9gzwPMrsHe3brRWgZRCGTNS24OlsyPA+gB07fRZ+vug2rUUcRp0bXTXDW1BmynX1lKA tqpe1AHHTPts5wwQR0V9rRdIEVIt/EEL06JFSRDeIpi9ILJEtCaD/FjuIjUE+ZG8T24P8gV5 gFQNpGnSUqk38KNkpjc4xjneqOXBEK1vo+wHVRJvtNsgjRXNlaYguaQv+BWkUCm/1g9c3iRp WaBLlu26+mAYpL8ozwB1rnpCNAX5oXRMyQ/aFlekOAv8f+y9dXwW17qwfa2ZeSyekBAI7l7c XVrc3bVAgSItUKy4tLQUKxQrTnF3h+LuXpxAICEuj8zM+v54T77s396nbzeFvbvfc3L9kzwz a9bc65aZe+5ZM9OcKVIDyxF7srYBZAfzF2MY5JyQvWTWQxC6PTRjyFrI+mmmg5kLQObXGTdl igFPiuczcwDEOeNqx2yBDIsyfJPhOgiriLV0AKW4MsCcBMZ1Y7V+EaRFNrSMBH21UdHjB6Kj eCN+AHWX8qviBE9N9xizEKjFtYJmKXB28iySl0D2ElaxG7RFVDR7Ap95auhdQB/tKum6BilL 3JoxHJxLjBjyQkIP1wRPF7Do9sGOIZBzYc5c2U5BlSelleLfQ+FOhRfmmwNqlHcT63Vw9LNm cfw/kAgeTzyeeDwR7CvtK+0robQsLUtLuLLkypIrSyDuu7jv4r6DOnXq1KlT5/339z+Nbdu2 bdu2DZo1a9asWbO/Wpp00kknnXQ+NOfOnTt37hyovXr16tWr1/jxqQ9VvCvbjx+fMLMMOK2e cinbQNRSTnnfg0c8H3r/Dlz0v/3b+Q0Q8oOfmScWaq2uPqJqVngtXzV5MQheNHhZ70kheLsg dn5KMEQNTioR2Ru0R2JvdDi8ePBqYeR6MD9OeZvyKeSYm/1hzuzgKchYzQvU/uZA51ywZrcn Bj4B87RawUcB4aNa9e9AMdU8XrOAZ+ILVgFlxSHdAM+8eyPOl4S4Zqf2H70LccU2DNizF6KH /rb7jT+4ncwLqg5Kfa9m2YaCtUyWMfn3Q0DbigWLP4E3Skz8s1/hxmeH9b2N4HHKs+wvv4TY ftrX3s/Af7a3ab8CcopeUd8NMYcTesdWgYRLyV8k1gYmqndEf9AClIfiIdgGWjdpQ0G0F7f0 M6BclzvNFeBp7WlnqKAXNm7rDUDOlKPkMjBOGvf0T4E9qKYA0U5px0GQirxllgf2y6NEgHnD PG3mBVOXDpkDjKlSyE9AjzU26D1BVpDPzd/AckwrKCqBrCqOytsgr8tawglyudHU6AGm1Vxt BoHpRQk6AvvMluY5MKSZxVwDZpzcLteCDJaT2Q9mJnOCWRfMCvK4+RzMc2a4fgRkFjFADYM3 7SJnJZyD6NbRX73dCe76ng4pD8E4pwd5wiHkZMiz0BwQ0f714ggHWJfYttgGgiXM0sjuD89X Pm/9xABltVpFXIGkXCnl3Ovg8vlrW65Oh6jcURejqoBW0LpaWw7eUd4F7e3hTdaoqNiKcP6L yyWuNoSo+W9rR2yEjL9lbB1YALRb6i1HNBCh7FVegZqTAmYfMIabS/UhQLh6T/kZUio4R7mv g3FF72/8ClHL4ucnRIE7X0oN1wvw+cqwi3vg1z2jf9Covzrc/5iQsyFnQ86mva/59NzTc0/P BXO7ud3cDlVjq8ZWjQVbTltOW86/Wtr/PAoWLFiw4L9gCkg66aSTTjr/GYSHh4eHh3+AqRrn f77gd0LAk/U5GlwvBrYhRkLxsRDYzqdlYDS8meh8fusqBK1xK4Gt4enhp7MfH4O4ea5HCQZc mPXk8POqkCXadifQAnm3Bjcufhteq28qJi0CW7h9YNweuFXoTevzflBoTN7ThStCQP8s7twn wTlf+953Ppg+8jNlPajTRCnjDCTnuans6Q6W5Rn65t4BWjm/p4F3wXn6VfXfnOC6/aREhD+I 41qwTyR456vurl0e/DwZU7LsAPvEoI6BnSFmzand1/ODOSpwlP89eKWY2aOXw8N952ufjoIX g576P42HqKEY6jnwCvE6bDeBFeInoUNSi8TyCQ8hMTTZP/E5KF9YZyhzwT7fvsfSHeRoI1y+ AXdHY6rLBxjEAd4CHcxe4hOQD82Cem1QBouPmQVGH/l/5ubO0bIqpUCMNB6Zn4NtsC2f+AnM RFldjYbk+KRE3QQlWZ2BAXIKdZX7YA4xHpgXQXzBJeUBKKvEUn4CT05XnBkJxl1KUgg4xF39 C/BUMk/LeqDF8rPSEhjDalkETA8bZBUQM80z4hKIH8RrAkFEk8UsBPKFzEdVkEXoxzlQSugN RS/Q/CwBxgwwz8kqci4kZkhCPwcRq1+XfL0KvOyOZdb2QM+HJ9VNYB/o1cCrOTz69knWp9fA rbl7myXAecO5MOErSNyUWD24Hbx+GnMqRoHo7xNmxK4C1sUP1hbB40Lhc5/ZoMSJj0S+XRB+ 7Pn05P0Q6RuTO6YGiLrR6/ShoDRVJ8kzoDZQvrL5gvbMsk/egByu0DeZt4LZiTlGDtDCxTBt NNhraCdEXkjQ42bGTgXlK68TjnZwKeFuq0ev4enKZ0VeToJPKRKf96+O9n8C72re1byrQTOa 0Qz+5p//IitZ+RMX1umkk0466aTzP4n3TpydHW2V3Ao8+Tqq85sICOrg3+dMf3g49tm9FB2K nQ9+VCsYDrovNlmfG9z1jaPmRshONr/ctSCTv3Y0A1C3Uem+jTpBjfW1XHUOwtPTT0s/8gPX adfd5IHgJDarURM8PfVDrq9AvyHHuXVQnloe+5YDihs79S9BZBOjXVXBHfQb96fD26R1s3cm Q3Dt9lm75wD7nNw5SzvAtitXJa9EUG9YK6lTgDNKMe0pePpH538ZDYmZL3Y4Nxa0qtZNCRKM g5nvhnWHJw+uLLi6B56Xulnqek54kyNltusgyBkOP5/XYGti/UX9EZJLJDdJfAFvayX8Evsr uC/peYyTIGaIo2otcIc7M7m/BL25Z61RGDyLzPxyGcg9Mk6sAplBmkwE6ZYpZh8QKaItASCi 1fZyHIg2LBNrwNbe9rnqC6K6mZPaIBUz0MgH1jleD5XLoLdwrTLKgJlFf2KEgxau5RZlQK6R 3YyLwKfirhgDxscyWt4BfYlewVwCsj+DaAtikBqkZQKzshwvBSj75QoxEeRmMUN+CbKyOc6s CMzmMF+AiBHZxGvAEJvEDNAXmfFmR1CjGayWA7Ouu77nIKiapTCDQI3TWmq7IKZ/XMakvnC5 /LW5t29CzgXZ7ybYQfaRN60t4G376GfROcBS3jJePQZ+eX2/9s0J7l2evRJISEwqFB8HSZ7E bomnwJgiv2ENOI+5/BPywsk6Z+slzAIxU1ZTx4E8RkG1ICillR+UjPCw1+M74beBmmKiTAFz IreMH+FN5teVIzJDHpG1QWhL8PvC98vQbSAKqCW1CoCu3zU7QIJfZM7oL4CD4ph6GDzt3G89 qW8ZGPxXh3k66aSTTjrppPMheP/Eeb05hgBIGvU20BkHFiMmxX4VbA285weUh5e+ou51D1g+ Cu2hN4AUu7Hp7ReQuOq1JSAcPotrkaHfaPBpat3l3RHEZOaa0yFPr9xNC7og6kn81JdecPl2 QsyeX8B/s2dS2c4QWkAtZv0YXDHuLXoCiOWa3fY1GH1YZniBOtuvp28yBKyq/FmF/WA/XqxO 9XAQZU2rpzzITuYx/TaYGz2FGQnuj1+XuzMO4hrsHLndF9wdYk/omcB3Ybmt1evDK0fS2Ph4 eOa5NOTMeIjYFH07pgIkFxEvlRbg94ujsHcmkP76S6MOJFxIzJCwBFzXjLPmQJCreCHugfAy 75gbQdYTMbQB01cuoB3wkyxBFpAt5H3ZF0Ql9nMbRDVa4gT5lTwqdWCJOQIfMG8xR04H10N9 kJ4I2nNRXPEF0U18hB34Xs+oVwLTYjySW0DeNItxC4S/8kzJB7K3PCs3AJ0oqYSB8ZvMbDYH NlBWvgS1leilCBBRorvcAGZz6U1bMMoaccYZQFJQbgZ1ipJZHQDmN7KNOQnkRrlVTgTxo2gg MoLlkGjLFdD6WhowAMiPyU+gf2OW4i64SroSjQkgH5t9ZU0QecRGpQLcP/BbpRcRoDuNfkYm UEdojdTzoCQo+ZTjEG2JXRzXFbJawuaENIWYcnFvY7OB3tbMINuC+7TroCcGlBS1mNoU3Bnc g1wXgebmGDEdlAfKZXUraD6aULaBMkFUYA2IG2o21QTZUEaILfBmx9t1SbfB8b116ducYB1u Gex1BWwXbFH+WUBatVClJ7jiXTtSmkNK5fjhcdvA2OMVZq0IbCLyrw7ydNJJJ5100knnw/De iXP812/rJ4+FTJcsLYoUg94BjSOHtgfro8BFnupwcOnVAmtngaeTV3vnDfA+Yg9IagIbm50e Oms8dC7sVeSLZ+Dcm7xFnIGz3XfGHLaA1z3vhcEa6NWVXcZkyDso6FKe6/BiftyqiMIQUtB/ 9otr4OMIbB0aDmYjc7ixBJSNop/tNFgmhi3NPQCUH3zrBSYBw5UiUoC84z7iqQmyjHJQOwY4 tTXyLXiSnybdXQLu2W+mxp4CdVTm+AKVwZ0YdNXXBff6/3r8yAZ4sezxrocD4U15PaeZH7Q5 jqm+rUEdw6fyFMTdSkqJPwSJV5ylnIPB0tZmqodAv64XNY6AYlXixUWQbVlrxoBns2e78TVw gKniOajRWm11AJgFjIL6SNAn6SX1QFBsSh8lAFgqh4k5YN43c5sbwHNEjpF7wC3lSgxQHEqo uAL8wjXxK5jrzIfmDhCjZAZRDDwx7pH6CaCFKCn2AuXECdkSjBi52swC6mA1VtkDXBLDZHkw GxmfGaVB1padUMBcZqw2soGaReum7QC5QR4zBSiVxRR2gZZVq63eBzlUhsqOoO4Xt/kB1C+0 2XwNejvjK9kfWCNz4gNGE6OmEQnKZk1TDgBVmGPuAL2PeUlqoERo85WsoAdKj7kXmKafljVA D9Ffm2vgSZun3m/eAg+VLfIliOXKJ2YoWO9Yb6ofg+eBx+0qAMYRo6u5CNRDamNtGchA6W8C YqPRVhkI5lIxlFqgdiNF7gRztPxU+xLkE/OVVCHix6jhseXBL8S3tPdSyPRlUDubHZQs3LR+ Dmp7kUl8CZ6kpBWJP4DWwXrXZ8JfHd7ppJNOOumkk86H5L0T54KDQ8dU3An9ZJtmw0PB2y+w gOMbiOr3+vTb3JCYPTK372242+XpnUf54fXrN94vH4Gy1po3Qw7YZTlX+FBf8Jqi/uI9GGK/ 94x9lgFe1XM3/+0MJP2SGJI8CeITE8++Xgu+ce4t3lMgW+8s1TI1gMDyoUbWZHDtSOng7g68 obvdCeqw4CO5NKB2ysy3+0A5bxwzQkEvrgwTJUA5IB9zGShnFnF6QBvoH+cdC6oaOsenO2S4 Xen7Uq3hrbczW5IFnl+4fPBie4joHe9xZoGUz8VyzQ9sZczxxjNIvpB8JlGH2JTkcfHLwd3U HGV0A7WXHit1kCvlOn4CTxFPhNkVPCMNp5EEykwC1WVAEk+oC8Yez3LjCJhvzBh9B2jjlHPq 5yDClKFiGnjK6h30IiA2U0UUA/HcfCHtIPuKONEHjExyhBwKYiwD5X2QZeiBE+QV0YZWoA4X AQgwc5p75FKQj5VVPOP/vH90I4gdSjNxDsROMYVcIK/rT2UEUFu2ogZobm2TFgRig2IVBYHK TJN3QJQX+YU/mJ+aRc0mIObysVwBxgRqsxI8x5ya7ABmUXlNZgfrKm2lkgvMX80RYiOQVTag DMgVYjy1QT6T82UQ0EfmNi+CuCk3UxRkJnOgPAZmVy4zEzwLzf1GLVBXa59qwSAxe5mdwPxY HjDqg5xnZpcPQH4rW8qcIE/KNfpsUPqIaeZ8YILaWbsKlhKWMgpAjf/zzVy9ov7G3QVsK63b 1GyQcs71nRgE4R+96RLZCrwf2j/ydoGP6RUdtB7csWKCCAIzvyfSdR7MkynHlDtAC1r+1UGe TjrppJNOOul8GN47cc4ps9XN8hOc63Ut8UQjOHb/gu1wdngxMubbcH9wrM1QKWYK+HUI2Oxo DjHKy+Hu2eDT2WuoPQASsjpnvKgGCZvMswlAtua+ffxvgN83/sllEsBnX8ZkRxYQDl5LG5Qd V3xt48tw33Inx4XfIMfzAlPylAB6WA7YWgI19ULO6aDF+odm+hnkNNsi1oI0jQ16dRBlxT0l AZRHcpjRBGRhaTqega1M7q5F60CGRRmD8xjgPTTT3rwz4Prk1T8vGQuvwp+MeXoAYsYahfkE jJ0ihR/AtTJlZNII0IOUUVQHV5KnobEYzE1mNKNAPjW/MJeDWc8MMdeAMVG2l1vBKGWGmq1B fKKUk7eApYynEJh9ZEHzDcitzBMdwIzjjQwFUVCWZS0QQnbqgvShtMwK5BZT2QSiB4VkRZAJ Zj8ZCxwSE3gJSjeZQiRwW3QToSC/Jr/yDZgtseopICeZX1AdKMRAsQaMU3qgvAjqj2oxEQjq S0tV5QHIbbKDiAQGyqGyL7CHRkwGmdu0y91AEyWDXAPmZaOi+QRkFuOE6Awio9ZViQVrKWuI sAHfWs8oT0Gpru+TX4Ixne/MnCCnmG+1NcAZejIDqEJ2MwMYLc3H8hdAlYe1YBDbsYisYPaU pfSBIEfhZg5Q3Iw1soMYI6xaTtAX6i9oA0ph4S9ygyjDp+YnILLLrOanYI7gobgPxnSzlNEC RDFdlyFgquY90RmMH/SBshS4q4luWEBZr9VUMsHb2GjflMHwpoZv8NsY8Jpqj/LaCdaXYo7X CUj+XCwzc4L7QMpBl/9/Bcmd9w/Ue/fu3bt3799xSEgnnXTSSSed/7kUKFCgQIECf377906c j2W7tX7XCnh2JXpx3EDwKmDtrv0E+lPjiNkFRFjsQqsBGUMyvPYvB86vM9pf1oBMndw5CpWA V2EJUyLagfdDa7D1FDxa/+YjYxn4zo8rH6GBpas2X3eAZvMSyT3Avf9hb7ke7q684bWtDWQc lyVBbwjlr1S/2O9rSC6SYk0ZBqpNLeLlANHQa1zm7sALGS6rg1KdYPqBeUxYRGaQ4USbfiA2 aCdDA8DeJfSZdRDEd34+7vFHcLX18VwnysDbb1IyuGMheQ3zxXTw2msL8PIHPZvYJPwhqYTz RooPeBbpi82VINqJJOUMKH8B/J8AAIAASURBVJFqNq0vmO30qe79oFwyW5ixoESqxZWcYDYy H8mTQDYqMRyEItziHjBbTpObABtF+RykKYvKMyC+ExWVMSB7yi6yGWi1LRO0GmAsNPubH4M5 26xnzgC1ksgoQkC5o9xVWoL50gyUL8BsTCm2giXB0sNWEPTyRhY9G5iGMdlsAbSTdkaAKc1W 8g0Ak81MoMQrFdV9oIxRr6mnwMhtdDS6gVpI5BebQWYxU4yyINfLV1wCTLWyuAh8Iyz0BZlM aWJALnAXMQGzqFHN3AsyWrRRVwC3OCqXgzwvP5H9gFK0kitA3jSK4gfiZ5FZLwqil6IoF4EK 8p6yAcxD5gWzJpBVRPEjiJHUNHYBXWWsuRk8HzHH/AjEAblczQQcppB5GsRetasxB+RgbZS2 FIwSRh+xEdT6iiZ9wFwug5UEoLPIyxOwrBQVlNrgKa6PM2wQvT5mUGIpCOkQaE+0gE9vL6xP QVj16WQF/bReXriAzrz4Twj0dNJJJ5100knn/VHetwPnOve+SBcUs+Wwmc2gRJ0SbRIaQ+Zf s5cWv0JEZMoN9zC41++3EREZwbup877mC/KcX6+35yF3g4IF8paDyIjk0rIDmIW5mfwtRC1J vHR/I7y+k9D26RcQXTJ528tzcOX6tZ7HioJ3/+BSeRvBWa5W218RErZGDHg0EBSrbZKlHxhf y4z6SzAPUddeAahDD5ENqEB9eQQoTV2+AKW8uVKMBbMyD8yZwGyme4LgcezZVWejILzpE9/n Voga5l4qPwfta9sjr9rgv8f7Y5+xoC5XflbugukvNZ6ANd6W3TYOlDrKZfURmEvNrcY8UDYo G5WloIVoBbTCoPRXOihHQGTBwjMQ98Q+8RUonyhdla9AZFcLqw6wZLEUtV4C+UxektXAUtxS XMsJ9lP20/ZrYO1maWx1g6267ZI9ARzn7L0dI0FZpezQ+oFaTa2tdQLtpqarT0HsEbkoDcoB 5TN1LTgstnn2MPDaaL9nKwb2OdY71pxgfakOt5wFZYJEaQfsNPKZc0DUNn+QS8GSSd2qjgNp Up2LYETJudwF81vGsB7kYzPEPAUikSpUB6OenknmBLOVK0xGgXnEGK1cB1lFnqMBiFrCrlQC FnGAz4AiLBRvQPwoRqsJIMKFj9gJLGARq4A2dJY3QVQUHwkD5ASzkGwBptUsorQCRVUs1u5g Sda2eJ0BWcHcp9wF441eir3AJDarI4HZ5hoqgbFeL2eGgyH0eNMCHJHPZWMw8nuO6U/A+NkT au4C/YExXO8FUb3fzkosCTFP4sITGwOtpN3VH7Qvla7sBaOmmUkv81eHdzrppJNOOumk8yF5 74qzY5j9on0sxG91TUtoBGHJfOLVBbwnyFf6J5A5PLChPR5CrmkD/RZC9pYZrMpT+G1T/JrX iyHbAHu50p9Dkfkl1mSLgqeln9+79hgSz8Sb3qNAwzLDkhvUe5ZOCYGgnHBtts2CwIN+iv9K iHgcWyi5LuytfqD63GBou7rD9el5IOmpPKI1BKWliJYDQWYVD+U8ICPRSmdgj2grW4FZjray DygHlNZaNHjqx16PKw031Qs9zxaGqCFJIUlLIckjhyk/gFcvRwvvEFD2ylfGafCMc5125QYc YrzYCsoV0VURoMQp1c1w0Oe7b+m3QBknbilOEM200moVoLtsL34EsY444yuQdo7IxkAtuokT YH4hLYSD6WWWkc1A+VFZof4MqqJ6qXVBSGEqp8FQDacxBJRu6k7lJxDbxDHlLKhDLIb2K5iH zFLmGdDHG3X0O6DNVseri8BYZiaZV4DJMj/7wTJBraLEg3imxCuVQamvdFaqgHFTby/dQHkm yyTgN7GCqSCmikHiGmizbS1VHzCeOx+6L4N5WM+kZwalguKtlAMSzO9ENJglRHZREcRsWZKD IEurPdVnoGVSN2oOkEky3swF5GalCAXtpjJK+xjoIpB5gJliuDoKxBzGUBuETRkoO4F4wWvx FEQvdYHIDdZLtuK+fiBXYReVQV1AB6UO4JELEi+BZ6Z7RMpDMGca9RUTGG5+bb4AZbu8zh7A JvrJpmAGmOv0qaCuVztoCSBOy3xKUXAccwyxLwNlvdbYdhcSpiTlN86Be7GnmREAalPVT+wD GSHtniVAm786xNNJJ5100kknnQ/Fe1ec33SLDE3ZAtZA2zR7TwgSwZG5WoDTrkTFXQZLF4rI saCvsy5NOQMRka5vY3JBct/kPCl74HrpV+sP3oP71V+Mvl4L4qPf1pFlwRLlGGe/D16OoLM+ S4FN+gX1PMiORk/jPjzO/8D6PAgSSsVcU3vCy8PGpcfxcH/VoyGLl4DXHftNaz0wv6Gu4QSW cVU9AlwVj6QJZJTL+RFYYbYxN4N1rqWmlgxvht+tfOsaPOv4sMfDz+BtlPuk7gcyUEy3aGDz t71Vm4Jzg7uS+zok19A193Ywc8nrphXcK91lPafAmGoc0O2gnbY8tS4EzzK9orEBpDTOmUvB 1sxSXHkCygmti2YDVVNraBfBMs7S2FIPbIUsn1sCgWtck9WAYpSQ7YGBDKAuiD1iN+tA1pTZ jQfg/CVlRPJb8HTzBLh7gKeo/tLoA7ph5Da2gxqmFlVTQLkpLirTQflc3OEqSIVJ5i0QV5Tx Sk5gjFwjBwFJFGcMiCVKCldB7hShfAnacm27dgr0ieYP5lZQG8vlojrYhllL2qaA2kx7YK0B arDmpf4IsowsLGqCtJgTzeVghjOVXKD+xCBVAe2Z0sziC2ItRZVvwIwxrTQBY4/x3PQHT19P Z30LWFaIvVohsCxRvC2XwbrX+oXXEzC/NRvLwmAW03ea+8A9MOVO4kxwf5b8MKEsJNdMqhs/ DIyPPEv1iuBd21cNSIHMd7NE5i8AgeuClue4BLaO3n0zrAevgICGGT+F4P0hU3PMhIDvgjtm ywOOvv7jg/uCb5XA/pmbQsZjoQvDbGD5xrEqoDB4uuhb1FJg+V4sNxaB1lFU0cb81eH97gyr NazWsFrQ5nCbw20Opy2fnmd6nul5/mrp/vdQpkyZMmXe4Y7F37f/q+z1r9pv3JG4I3FH4KsN X234agNUvVP1TtU7UHlg5YGVB8LAWwNvDbwFL8e9HPdyHMhP5afyU5g1a9asWbOgpl9Nv5p+ UGlFpRWVVkD/pf2X9l8KL168ePHiPSZTva+d/tX8nj3+U/zlj7hS9krZK2Vh8ODBgwcPTvv7 96R+6j51XL/3938rf7Wfvm88/rN+8O/ivSvO2c5lbGu9CZkXZd3pGwThP0bfj7kCz9xP96Uc AaWZOtM5BtyPlRIpX8Pb9rEH/caDd6DSwVEXUn6UTRMbgauOvsnIBsmJnuL23mB/EJ8nLgSU /n4nPPFgdNDmqOPBnWL6mrNAuSA6Jz4B5WOtcdIoeN71bZeQbLD0o11TN82Fdg3K+jqyQfG+ VS90nwiJ652HE3KCdpoWVg1kBlmC5iCaC3+1MshRxl3XI/it9KWyl85DVOcYM7YdJMS7X3EK LMXtNxwLQQ0Rt5SOkHwmpXby5+DqJOeYgUB2JVKrCZZJlkGaDuZUo5EyFWipdBerwDrbOkpb B+Zq8xfzAJhH5XwxELST2ga1DMhRcgp+oIxXRisTQM6S3xurgdM8YxKIM+K46AfmCnODXAtq D7WLEgnWslpd23xQ5ypLtMFgDpHr6AieOH2UsR/UYDWP0gkUN9FiHeiNjNWGN2gDtMdaHVAS VMWaB7QpqpdigJFiPDbiQdQXdlEdOIMh+4N1sFZWGwGyPLf4DpSyoqooCNSS2/AG9YqYqrYD bYS61GwERqBR2egOchhbzKtAFF7yG9BOajFqIxCDxBOWgNnPKCCtICPNnfI4iCpMFBuBODFC +Q3Uy8pTtRS4T3uKuxeA5ai6Q/MHT2XXGecr8Bw1jhjnQLupXdV+AbWGmlf4gFnWbKH/DCwW TzUPKHW0/NpTMPKZq+Ur8L3qW8vHA2ruwLcZ8oK8pq80joClhlXR9oGXjy2HFgfMN4/qJ4GL dPLUAMu3ymSSQF0sZqk5wVrEvtBeAbTKyk2lOCjtxTClNai7lSdiKgBd/7rwfneOxh+NPxoP 5++fv3/+PlCb2tSGDYEbAjcEwnCGM/yvFjKdf+B019NdT/+Np/1V9vpX7Tf1hHv45eGXh19C t27dunXrBpl9Mvtk9oFpXad1ndYVRp8ZfWb0Gejh6eHp4YHV1VZXW10NBp0ddHbQWVA/Uz9T P4Mfkn5I+iEJvl3y7ZJvl8Dc03NPzz39/nr/T+P37PGf4i+/h/6R/pH+EUxNnJo4NRGeuZ+5 n7nBOG+cN86ntfN093T3dIfwceHjwsfBoEqDKg2qBAEPAx4GPPyrR/Gfw1/tpydnn5x9cva7 x+M/6wf/bt674qzftSQ5F8K9xo9eP7HC1el3l97dCaFVs1bxyQ8pl2Tym5cQeTG6hKM8KA9E oG07RK5I6mxehJj+cXn8doKnidEmwwGw9Q78PO4hJFf09ExcBm8PPMuSpEDcqTcTXRPAHGfc lkvA6Z0yVa0MbxJjO8Y1g4gO0aXCx8O9vOGvYgfAikuHm06Jg3Db3V5HJoM9q721bx0ws5n5 9S4g1or9siUoj7SvlKXgfBi5LaIAPHlw6/SttxDTOmWuKxoSaxtTWQjWyo7vbb3BPcaT37gC KT+5F6WEgl6JUiSCscTcYwwFoYibNAHzlNnYBERn1vEAtANaX20lWPppn2oSzDdmRfkb6J/o DfVdYGQygoxGIGvIOrIfmAvNX8x1IJeag8xdIAfIWvwMIrdwi+bAIrqyHhjDdTMJWCTWywrA Umbog0GEsdvQgEfyFcdAdFbmKZlAXaY+VFuAskSdpW4Cy0JtszYT5M9yNxWBzXKpKAGKwWTl OggnJcVuYJRM4TjIAuY4eQfUFUorZRCwEUV5AMYUc6mxDkQHMVBRQHQT3dUbgJtwURUsyyz7 tHqgZFaila5gvWG9bj0J8jleRiyI25SXTUEGmd8a50EP1OP1ayDXms9lffBsMoZ4SkLSEtd0 fT7oy4yx+IH6Rl2nTQA0hPgEPE087fTd4JntWWCcAFlR2o0NoHfXD3nuQ/Kvyc3jN0JEjVeX n7aE6IVRA8PnQnKHhKaRL8FM8BRN3A5JWZJaxp2B+Hrx2ePaQ5JX0oPkL8H5hSvM8wQSCiT1 TgmEBGdilYRREHc1sXtiPHjOG03cu8DWSp1l3vpwgXow+mD0wei0SnDz7M2zN88OTSc2ndh0 Imwfu33s9rFp7WNjY2NjY2HEiBEjRoyABtsbbG+wPa39yE9GfjLyk7R2Y8PHho8NT9u+b7m+ 5fqW+8flvS/1vtT7EnTq1KlTp05wp+qdqneqpq3v1atXr169YPLkyZMnT05bvvPlzpc7X8LX Db5u8HUD2Ldv3759+6BVq1atWrVKG0+jRo0aNWoEy64vu77s+j/qIbUSsur2qturbkP7hPYJ 7RMgMTExMTExrRLROKxxWOOwtEpG6jj/iA8tV1T2qOxR2aGf2k/tp6ZVxlLX31p5a+Wtlb8v z9S3U99OfQtNdjfZ3WQ3zC8+v/j84v/YLrVy83v2elf9vKvcv7fff5aWU1tObTn19ytdERER ERERELI1ZGvIVuhzqc+lPpfStsv8MvPLzC/h9qDbg24PAntle2V75bR46dypc6fOndLiIBVd 13Vd/+fl/D29p+ov9Y5NnTp16tSpkxZvP53/6fxPf3Oi/7P+mqqfOa45rjmutP4XLFiwYMGC f94ef+Qvk/ZM2jNpD+zatWvXrl1p61MTlvrP6z+v/xzeHnh74O2BD2fnVNbUWFNjTQ3ImTNn zpw5IWvWrFmzZv3Hdv9/hbI0pSmd5qelF5ZeWHohNNzecHvD7Wn6fVfe9Tj693ZKTQBTt+tc uHPhzoXhRcYXGV9k/Nf7wfv66Yey65+Nx3/WD/7dvHfi7ClshPtNBE9UtN3SH7wzmG7/lpDx uhehP0Kh0JCtwY/BkdHbEtsXEp4ofV/XB22VtXT0dOBJ4pAoDVyl9Z4JTYBY8X2yE4w5PuXi roHPNrvb8Rq8Q9Xa1iFAKX2bcxfY9vn2dI4E92h3SctbCG8Qfke5CM6vUuY6K4NWy79x8EFY UnHr46GzIGFOeJ/bZ0Ebbvvc+xmYIXofz3HglDZY8Yfouo+LPioLz5++9HtxBGJiU4I9FcB4 o5RXz4AlxXrB0gecie5erteQPMFTzNUERGnhFNNB5jJumK/AUPQ6emEwG9PK3AeymPGl+RiI NeuaA0AZLH4TCohGcoxYDWYe02HmAE5wXrYD85Z5w6gAYojoLgA1Uk0REaAYVKcFyDdGHqMa GOf1GPcp0N+aa8ymILNKj8wODJG5WAmOOjbNHgXWbZa2liCwZrNIazBYW1mKWGuCKGC+lWWB j2URFoLaW+2vtgDxWPleLAYlWimnjAK1uxKk7AF+wY/fwOxvPjL9gMZkoSeY1+UOuQTYJG5w BIgVU6kCGprTmhu0HlpZmx1s9Ww27xRwfOeI9K0CDpejt99NcNTx2ulbB2xjrAW9doJfdZ8j gQXBt4nf46DGYEwwMhhPwbzOXfaD7wr/qUGzQGtjK2PfD7Ioj9gMHh+9vR4KxjmjgOkCM9Ks IiuDMzD5dlI38HztDkixgt7WlSP5U3BuT/gttgO8dkRMeXkLnnz+eMkDOzz+7nm/pxchvEXk wtjpEN/FtdVTCOJWus4RD+EDY3qnVIDIYynNPcEQ0zwpXj8NUUFxXV0HIeWUu6WxH5RHWMx6 Hy5QJ2admHViVvih/Q/tf2gPW59tfbb1GSzsvbD3wt5wvOPxjsc7prWfdmDagWkHIORZyLOQ Z7Dr5a6Xu17Ctufbnm97DmHjw8aHjYdv23zb5ts2MDHLxCwTs6Rtv6j0otKLSv/+8orWitaK Vri48OLCiwvBPdc91z0XoqKioqKi4NrSa0uvLU3b7nLfy30v94VKNyrdqHQD1t5fe3/tffi0 1KelPi2VNp7l15dfX34dfrrw04WfLvyxXtasXrN6zeq0E0bqgTs1Ua++pvqa6mtg5q8zf535 6x/396Hl+jbvt3m/zZs2tWDbtm3btm2DAcsGLBuwDGYUmFFgxv/lbSk1a9SsUbMGLC2/tPzS 8rBq9arVq1b/X/zkd+z1rvp5V7l/b78fitQT+t5se7PtzQaWZZZllmVpCXzE7ojdEbuhSNci XYt0hbJXyl4pewWG+w/3H+4Ph6Yfmn5oOnT3dPd090C2N9neZHsDExpPaDyh8fvLl3qBExAQ EBAQkHYBtjVka8jWEEhon9A+oX1a+/f117KirCgrYMmVJVeWXIEVlVdUXlH53e3xe+3q1atX r149OJDrQK4DudLWnz179uzZs1CwY8GOBTtChk8yfJLhkw9n59QLpDXV11RfUx2G1RxWc1jN 32//ZPOTzU82g9JX6av0hYaNGjZq2CjtQrNRWKOwRmFwvf/1/tf7v7s873oc/XuC6wbXDa4L e5ruabqnKdRaV2tdrXUw/ej0o9OP/uv94O95Vz/9ULxrPL6rH/y7ee/E2T7J09WzD4IW+633 bgLBDr99lm6g5DPXGuUhbpWR5DgCWmPzgawLAaO0/RmygG2xbZVxCZwXlWwR28Fd0rMjNg7c CUnZfDNAjkt+fTMngL2CfKg3AMtviQvUKHBcNHLbSoFlimOjfAoZXmeeZC0OwcEZyurDIMwV NNe7ECSfi7IoVghv6ZyWcgbW3NvQ5qs+QGySjK0OYoFlqFcz0HbJyjSDiAvPG94vCG8LxDRL dELsG32neRrUjBah9QUxQZRTZkNSnpRXCR3AtUJPcE8HMdxoYv4C6NQUq4BfzMGiHKhD+EL5 BOQ1puuXwMhqfqtHgtHW8BibgUWMoiyYjcyOci0oNiVBCQLlK/Exq8DSSxsgqoL8gcNKCVBz axcsfUDcUkaoGcB4YGZnGhBKrDwMorWop1QBhohJ6iQwaskFdAM505yKHYwt+hjPJlDeiO1i J6j91DFqaaAj9bkPoptoIzqDulJ1qTeBLsKPvaD8pFZU+wBPlFhhATFX3KMJKBs4z2JQdXUO Z0Bbr+xVboK4K0uLwaC1sP6oXYXQaVnq5RwOmW9nbpbPC3wn+j8LzgkB64ITM9aBEFemX3NU gZCsYUWy+0HAtYwlQnNBaOPMIblGgf2614TAJAj9MfPsPG1BWaY51DFgHNDnuCaBPsIToZtg fm2c1r8F8xtjt+cQyDXGEfMqmBuYppQEkZs4cwjoSYafXh+8SvjdDzgM1lG2/o7mYNSXFY3q kPQwYX/cNXB/7lyVXBrM6eb3xhqw7LMcsE0ARzOvGoHzwb7MVsQ/M5ifiFaOp5A0Uj9u2wSJ 692ZmA7SX/lcHfThAjX1ADl259idY3fC8uXLly9fnnaAmfH9jO9nfJ/W/nS3091Od4OeZ3ue 7XkWlM+Uz5TPQCwWi8Vi6Da329xuc+FU11NdT/2JW3ipCfClRZcWXVqUVukrq5RVyiqgXdOu adcgelr0tOhpcEW5olxRoEKFChUqVIClFZZWWFoBgjYGbQzaCOuHrx++fjjMvzD/wvwLYP5k /mT+9Pv7b92qdavWrdLGlTrFpOnuprub7k5r1yKyRWSLSDg3/9z8c/P/eFwfWq7UROPv5aq8 vPLyysthfvf53ed3//3+Uk+owcHBwcHBabem35V31c/7yv1H/H2F6umWp1uebvnHcf9DBasU pSgFOxruaLijIfRZ1GdRn0WQ+2Dug7kPwtTmU5tPbf6P+8sxJceUHFOgqldVr6pe8Dzj84zP M8LiK4uvLL7y58eRSuqt8NQKvaZpmqal+UHqhdiftcffU6ZPmT5l+qRV4P+sX/weqRXbR189 +urRVxD/Xfx38d/B7gm7J+yeAE1eNXnV5NWHt/OMDjM6zOgA3bt179a9G2T8OuPXGb/+/f6D NgVtCtqUVsndvGnzps2bYGXllZVXVoa3+9/uf7sfJu2dtHfS3j9h1/c8jjbO3Dhz48x/Y9+o FlEtouByn8t9Lvf59/vBu/rph7Lr3/NH8fiufvDv5r3nONvGa1eV0pB43OVnaQGmv+ZndYFz lv7KSALNbtudNBbkXv2MnAWijHnPOQ+8cmFhHET0N36zfwq2QdrhlMVgm6D8aF0ECVvihuMH 5llXs6TdYExRWnllBt8RYWVtMZBwJ7G0d0V4fdT5Kqkv+D+1r1E3gn89znmfAPuNsKFxkeBs Fd/NNxIudgqf8HIFFOlwoNXSclC1YN2GvbeB+Fz1iOEQnv3+1KehEONMSXZWBddNfaueGxwl fL5yFAHzshwoh4FzqDPG+RB4yjZxBoyycooxFeglxyvPwdwhL8uFIIazkZXAIexyC8hd5krZ GngjGsh1IA4obrEctD5afe0LMOebs2UgqFJrrn0G5hgzydwHop/wEkVBXa1uUFqAedY8K08A Y+UB8oMyggPqt6BkFYriAe2y9lbUBv2tPkp/DqKgmk9NACVZlBEzQZmmHBRvgFfCS70JfCH6 8RpUoZXWsoPyyBDGBWCzfEUwyMNKFvkURHnZV+0HorDwF6dBOU4ZcoKcT4hoAuKJ8Fic4POz /wP/K2A/7y39doKeVT9n3Ie4AXEbXl8F1htRSeXB9WNS2aipICxqFvtLkKfMG3oH0H/QC7in gNpfDYudAL5TfPbZ+4OrZUq/FDsklI//IqYvmJfcJTyzwCiqh7iGgfyY8mY7kBPEVGUlcFWM Uu6AOMprWQ50f+MzEQi2TV4x/ibYFnh97zcSktslE2kB/arh76kOgU/9nBmjIeCbwO6Zg0F8 rebiUxBFNOy3QatoKeMoCTJZFqUuaElaMe0WaHnNWSmfgH7P3SP5KuhtDYUhwJZ3jaj/nh8K /FDghwJw7+G9h/cewvUh14dcHwJLTy49ufQkMJjBDIY5zGEOIEvJUrIUaPu0fdq+f+xPXBKX xCUwn5vPzedARzrS8Z+Xp9iZYmeKnYH7u+/vvr8bLha9WPRiUSi5s+TOkjvBesF6wXoB9rfc 33J/S/Bd5bvKdxUE3g68HXgbPq/0eaXPK0HIvpB9IfvSKqtVqlSpUqUK7GAHO/4v+7fftt+2 3077HZkjMkdkDqi5p+aemnuAMpShDGDFihXENDFNTPvjcaXeMv1Qchk/GT8ZP4HZ0mxp/jff kEy98MlJTnL+N/2lVlbfl3fVz/vK/UfMKTqn6Jyi4Ong6eDpAJ/bPrd9boNXjV81ftUYNm3a tGnTprT2rtOu067TMCZgTMCYADj6+ujro6/Tbv0OujXo1qBbYBtuG24bDud7nu95vmdaRbp7 se7FuheDL7y/8P7CGw5uPbj14FbYFbsrdlcsjGY0o99Dv+KyuCwuAw1pSMP/Zv1/xRtBBBH0 /v76ofzi90hNpGrNqjWr1izY0W5Hux3t4OrSq0uvLoWJX0/8euI/kci8q51TpwId7X60+9Hu MKPMjDIz/pvEK7XdjKczns54Co3mNprbaC6ERIdEh0RDCCGEAEHPg54HPYcXn7347MVn766H D30cVRYri5XFaf3+u/3gXf30Q9n1XeMxlX/WD9b6rvVd6/vu9v2zvHfFOcYr4WOjC5jj1Azu buD5TO9APLzaHjks5TvQf0gSajYIrKSeDv4NQjP4/5boBWq4cV4sgYyHfBr4T4GMDTN8IWaD pZalVlQ/CAkJOmQpDF5dfTPa+oDPaFt9tkPU/KTTMWdBz+jnjlsGIYOzTkuRkOEj/yVehUDZ bh/JDEjMG9eZyeB87fLzDAD3Mce9lFawzv98l/XdYF/RnYFLloKr6qs1j33hZeOnjhdhENfB 7e/JB8m7jW/M8aA2tnS2/Aie7npuzwFwjnSnuIeBLMwQdQ6whk5KeTBtco45HGRvYmVfkD7y gnwIRi0zUm4AJiovlJYgjqo7lC9ALqIoX4LSkgWiJoif5BsegZ5PP6+fB3OI9JWPQV6Vv8oT YKwxppuLAC+SkWBeNI+Z+0D2kr3MHqBOUucqQ0FpqbQVdUEdpU5Q5oHyi1gkuoL6Wg1Xd4Cy T9mnTAPlBzFZ5ANLKctAy7egtVC2q3lBK6JO16JA89KqabVAS9JiLCXAWsl6y7YfLFu0vFY/ kNNEhAgDa1abr1UD7zp+z3yvgXWgfZ89B8gG5jRzBiTmebs04hLQ0zM7qSwo90RWLS8wWd5S noN6gwvufqBUkAuM8WC5r/RSCoK1m+WtqoL3LD974EUIqhV8NeMKyBGaa0iBNxDaPNumvEC2 onnufxQA2S/nnV+qAoRNyzWg+FeQ5U7uOcXnQOYfs88rdBSylckTX7I05NLyLSy1BtTa1lwB FcDnTtDgjC7IV/6jwVVPQWCmML9C98GxOOhtcBJ4B/r1DiwE4mOthaUQGM9Yy5egLtdWqrtB +ie1ijwEiTmjv3/xPaR0ShqcsgeMisYi6f3hArXNd22+a/NdWiW0dUzrmNYx8NXDrx5+9RCu /Xzt52s/p7VPndO2YuCKgSsGpj3VnPp32fJly5ctT0sI/1lSt0+tVBRKKpRUKAk2191cd3Nd KGmWNEuaaRWrlVVWVllZBSreqHij4o20fq5evXr16lXof63/tf7X0qYEpFYe/n/+q8L4R2SZ kGVClglplaaLFy9evHgxrTI5csTIESNH/HE/H1qu1IrL389BvyAvyAsSvs70daavM304P/k9 e72rft5X7tT9/q69mmRpkqVJ2txF6zLrMuvfJACpy1P/pt7STq3QpV64pfrfgZwHch7ImXar O3XK0Lzi84rPKw4/9vixx4890sYf2TyyeWRzyBefLz5f/PvrOfXtHqlTSlLnaqbeoVgkFolF 4m/G/4H89V394F3bpU7ZmG/MN+YbUOtBrQe1HoB2XbuuXf/j/t7VzuserHuw7kFa4pX6N/PO zDsz70zbLvUOW+pDje3yt8vfLj9sfLTx0cZHafKm2rlihYoVKlZ4d72973F056udr3b+TWV+ S8iWkC0hUOpiqYulLv77/eBd/fRD2fVd4/Fd/eDfzXtXnO13QsNjyoJY6antDgXPdY9u7wWJ u13D4iwQ+Jl8ErII8rfKtCDzMAi55dM843dwJ8LS/WUgvI5/0MHMCPZzSkn/DiAmiuTk2vB6 edJLYxho52LLWbdAUKegYdo5cJcNWvN2JIRHPnGknIQMzR11/KZDUgW/yh4FSEjo5fMj+Pb3 c8vZYOsYLOwTwe0V8f2b4RB71lPp9Sw4Wf7+J0cKgLE9KcoyBcLXxVdyroSkVy6H5yKYFpHD XAdade1jbQw4f9ZzuxuDp7hRy/MN6DMpI+aBGGYsMnuBrC82sRXkKjmJeDDnmyONEFBWKjnE LjCbm72MPaCP1L/W54LWX1toGQ1imLgqqoCxwVigzwTyKqY4AkZe9z7zInAdSR1QeospojWI /CJGNATKM4nBYByXTYwMYN6Va+UmkE8oKX4Cc538mFhQ14ov5B1gNZMYCQJxWbwBWVfW4y0Y J/R5+ipQvtTGa2dAuakcFS5gElnFKZCfyGdyDYjJQlELAY+0EGUlaMJS2JoElnm2F45WIO+L BdZvQbknxmnlwTkxKXtiKzA/YrN7O8hSahlrEogoxWVdANom8cQ9GTSralXDQW1lO+S1DER2 yxOrBO9vvHcH9AG1nrbTVgt0KYeYCWB2p7f4CqxvvBf6DQRxBT+lAah9tFZWK9CWHGwH+StB cj0oYWQxbaAplnvWoeAclpKUcAWs+VW73hf8u/j9mvVnMCcw1cgPyjN1uVoM5EhZliNgDDCF rAaindggu4Of9JllvQb6JedA/Tw4X2hh1nPgeBq8OKw7WMIcc3yqghgvhihTgGEfJlC7nup6 qusp6FWyV8leJUGJVCKVSFBXqivVlTBm0ZhFYxaltR+VYVSGURlg6uipo6eOhqZ3m95tejdt feEdhXcU3pH2cMsfUehEoROFTkDH8x3PdzwPv/ALvwCVbla6Wekm3PG+433HGzKHZw7PHA6O WEesIxYis0dmj8yeNrWDEpSgRNrDL6kPE6Y+BV/KLGWWMtP2N2vhrIWzFv7/BfXfZfz48ePH j4dJ30z6ZtI34Nzq3OrcCo5VjlWOVfBlli+zfJnlj8f5oeUa9fGoj0d9nJZorgtbF7YuDLwG ew32GgxjM43NNPZfkDj/vb3GVxxfcXzFf14/f1bu3/OTP2LzqM2jNo8CRjGKUf+4/uy8s/PO zgNqUpOacKPijYo3KsINbnDjv+kvtcJ1d9bdWXdnpZ143b3dvd29obxR3ihvwMgcI3OMzPH+ +k59eGyyPlmfrEP9jPUz1s+Ypq9WO1vtbLUT6EIXunw4f31XP/g9e/xeu8InCp8ofALsleyV 7JX++Skaf9bOOVrkaJGjxT8ut061TrVOTfsdNiFsQtgE6JW/V/5e+eHl65evX76GmSdmnph5 Aiw/Wn60/Jhmh6HTh04fOv3d5X3f4+ijjx99/OjjtIcpg3IG5QzKCd88+ObBNw8guld0r+he /3o/SOVd/fRD2TX1AuyfjceslbNWzvrfzNX+PT/4dyP+z1w2KcuXL1++fPl376D7R2MfFNsL pQLy7ipXF5xR+kX3r3D+7N0Xp6+C/3qvgd6jIVNpv/JZX4H5Wtlr6QpvX7z+JOIi3F34uHhc fQiZmemU5TYUvxnaLsd5eNr0bS+XB/yaU93sB5EttInxQ8HbFjREbwHKTaO8XAgvV8WVctWE wF7iUNYFYD5LHJ98HEKnZR6dIRb8bll3pdyF2BJJDqcLPFu1A7HTIdf1oBIVekP+J0HOOg7Y fmVJ7yXL4GqpZ8WfXIeUAbKDdQmEnc06PlcMJEYnbYzbDM+nvaz3dC8Y+URe7RGYJwyb7AIo 5JY3QLTlFsvADJGmWQjkPnlOdgORUzQTbcE8ZR4wd4KSQx2sVARlrbiqLgR51/hSvgIcoo98 CeZnfCMmg3ncvGWcA+U7nDQCysp1ohmISspFMQKES7mHDpYCGvYGIB6LpfQGZYwSIW+C0ls5 oG4BJVzdapsE2kntodoPtGDtrq0TyCnkMjeAvClTpBPsJ+xXvZ6AVbNl9GoN6guliFoSlIzq YOs5sCRav7BlBiVGe6l2BmO/6Mp2UMqIx5YjwB0zxLwHrghntaTZwC4mGp+Bo7e9i/01mKuM c+4WoI9xjkj5HrQK2g7rYBBlLTutY0D8oK6yzgW5gFVqVzANM8xcDfK0CNYUEM+V5cpeMHeb h/UF4FyW8iyhPSg+7JHxIGvhp3QCT4TZSC0BKRMScsRcAlc/T0rKAAjqFVQx+HPw+cEnMfhr cM11eacUAf2c+Sp5AliWKdvVfWDJ4xgeVBtc0a427tUQ8KUDbSEoB/jRMxZiayS4E78DdYP1 me8zUPMqDYkG5SDX9DyQvUzGOJsPLLEvvbL4+L8/sNNJJ510/iypFcgr6hX1igrft/++/fft //23xP9fJfWOTWoFOZ3/GZw7d+7cuXMfoOL8emZsbtUDZ398GHbnLMjd7qcJoyC4v/d3Xr6g 6L4nlXMQ9cZ6P3IrXEo4F/n2EviUd5wWp8DWUpZXW0OGuQRmmABqPp8c5gTIfdVLtVyBF+ee PY2OA32bdUpSVojrlzzPUx203OYJ7xDwGqJKyzxw53UlyFXgtS1gsDgCiXnE8lfN4bVv7G29 ENh22fr4FAXf4WZ2n6lQdkT+PdVegKHEtrBNgZhs8ccTxoHzS6OMURuUzVpF8TGIXeo5eQZc FtcnnsZgVNSXSQvISK2oKUAuNyeYTUAGy6zyGsjyDJaZwDwnj8loUG+JeaoFyMphmoHMKx8T BfQwe4qDYIyVmw0B1MApAe7K+mImyAsiCBsoA5VjtAIlRHyungCeyjsiBqSvPG0uA1qIUqI8 GB/J7GZWcPSyXfYKAnWq1kNVwTrOPsD7N/D7yf9V8G8gDorPpROU4aKvRQHTanRxrwLTNK6a J8H2m91qXwhaPttQ+zKQT0V7S1NQk9URqgDLWXWr9gnocWZhdyUQLqOO+xOQlaRhVAOlquaj usH7rO9o70QwB3rWGaOAaLOjuwsIwXOGgu2OT8sAD2iZtKZaMKg9tV/sT8E8afwsh4E4KxrL O2C24JicBHp9vZ1RDcyb+oWUQmCudhVOPgLWutLbuAXuR0YgseD62rNQzwGxSvTPMYUgaWby 0ZjMoPWnsRwDuuLsnvQrmJUzPzA7gr24o4DdA/ohtyG3giijbJPzwbMpKXPcWJDTZA91KLzd 66qS5ARzuVlAbw6ih/WidS9YMxuTnZvBGKv/Jl9DQHafGT6lQOuLl3oHWP5Xh3o66aSTzrux e+Luibsnpr1fd+rcqXOnzuX3S/zppPO/iPdOnLO/Dl2uDIC4bs7TEb3A/4C6yqs2ZOigeTtW QowlOWtifXCN0o7rX0BRM3+gjwHJZY0lsh9o8epm+xSwvUm4ZRkNZrkUp6cOBJgB13y+AXuK s5UxGbx9xYwso8C13v75m1fgumbMTjkF7PfUd7QAsZBBMRHgLKd30W6AtlUppikQOCS4TdBJ cN7xuu4cDOaYmEGOqxD8tb81ZzD8evt052OHwX2a+ewFvb3+vTkeLJutRUUbYKFoTQB4phoD 9SCwBjhM71lguekV6BsLeoRnqLwLXMEh/ME+0WH3ugi2YbYb9mJg5jd+03uD54guPWGg3FMn qH1ASHopv4Axz2ivfwbKNeVjmQyWu9ZI3ypgWsUjswywRkaIjaD9ZKljWwW8lXk4AkaQJ8x1 HNTBorRRHLRlFo81P2iRWgVrblC/0qwWDViqCOUrsOS1jPNqDOavSGM/aIOU3dpnIDrRU3YA tZw6Xw0E4zPzop4d+JrHSm8Q48UGrgLbZHX5AmRT2VuvClobrssDoDqsPRylwYiVrZVnIOao TdTzoH/mqe7pDvJHYqgI1s8tQ21FwXHY3s56CVx39Z9kfTCXmQm6BeQg8zsjBJTfREtcIKJ5 YPiB8RFJSncwHho9zfbAOVlV5gKf095BXi9B/qTvML+DiAuR9siREO14O/B1Z3C3dFVNfATm SeOg2QRSLnmymi/AXMphxReiLka2jBgB3nO9BvrnAFt7Rwaf3yDubMI30TnB/rGXx1oSxHN1 on0DeBJcx1w1wTZW9bV0BMtR/VflHCTHeLIkzQev3D6F/VdA3NyEzone4HNZDbBMfedwSied dNL5y2n8qvGrxq+gMY35AG/r+1/Htmfbnm179ldLkc6/ivd/j/OBhAzOLJCjc9C6TIBPflsh r6eQWFKN14NAXaj/pkZBhnAtt3cNCMqR46rxOdjL2zMp9SC4cZawsBMQpVrCYwvB6zyvC1qP Q54HfsWKB0NGNTR/wDLI4PS95zIhQ3tbUmhPUL7mU2t94CFr5U7wvE1pLU+CbazlJ603eOWy NVBngmu3vcqbhRDdNPLu4wPwUaFcD0tuBTFW8aU+PC8ccelhP/B8Zd4wHGDeNqvxM4gvlfpK HJi5zVyiJyhRWif1FQSUCz4VshNCcmVanssHsnTO9SC/H4QdzlE6rw6BHTM+z1oPvJ2BvqHL wWdehs8zPwQ/NeR+tsYQcDy0TE4H+Okh1bIPAP9mGX4MWwE+AQF1Q7zAt1Pg/kxbwDc4oHXo cfC7EngzpAw4KvjeCnwBji982wedBd98gcMyHgavUf4/hOYD6yLv24FbQA1zNPOrBaKEtYN3 DrAesJfwOQDqUWu8Yy5Ya9nuea8CdZzV6fAFGth+8voVzPVKDXUOKOXVI9ZeoLRQX1gsYBtg eWZbA/YX9kjHATBamWfNMBCTtPLajyAqqweVvaBFWMLUHSAiRYQSCPbp9ite48G7uXcmnwSw e3lb/D8F2UNksewCZaDR03wB2lMRSTSw2/zIqYI73JU/riE4M6X0TpwHSdXiFsUOAmeHlLZJ PqA8V5Yrc0BZqe2xjgJjgTnVXRlC2gdcdSyDTPmC8wfWAGWAstymgf2pvZOjA2R6kMMnhxUy Xs12PttoCGgYUD5gF/h5+xX2qQCWF7bHWgYIqBdQKuglBJcM6B5aC6yGcsM8Clo+7aJSAsyr ilvEgjFL9NeHga2Ptba2ApjAaBqDPkb0YiN4hrCT/8WfeE0nnXTS+d9K1jdZ32R981dLkc6/ iveuOFs+178LGAtmq+ijlibwpq1rWco60IIDnSklICE3B4w9YByJ+N51GALLei3UYsG2Tf1F 8YHYsfLU40RwZPDv5XUIkk44p8avhfNLbl64CGhfWieqvcFxwK8Wn4JzfEKc3hj00lTkZ/CO 8nml1ABLHedpr2DwtE9+6k4GV6bANloDsExK9vP5GIIt2jzZHgoUyJqlQkOQg1KGKymg7TWP iirgaqj3NnKAp7B8IQeAo6k6ipcg87NalgJyc04bB9p563K/z8CobG7wvAHP4uTByddBtpaN 5A1QftQGWfuAes760CcLqEvVYo6loPRXW7h0kAP1G0YjEGVoaLQC0UTNSSWwJKorvL1ArpW/ eEqAWd6sYRYFpZ6waIvBTKGoUReYJGorx8CeZP/U1wLCJtebZ8GQfIk38J0oYo4F7aP/89YN daqYJDsAr/FyGSBasUpdBeI2UbI5aM3NZvovYOru+MRZQGPlS+tjUPKqsdoAMCbrYXjAbE1D egGTZD/ZCKgj94sMYFwzGhgZwaigP0wZBEZ9fQfDwH3H88o5BZJnx8VEZwTbLftMW0ewd7P3 cxwDb81/W3BPEH5iujYFlN5mB9dIMIfJXSI3mJdlfz4F2yQ1o3IMksu7qnj6QIw1bktCEuD0 beaYCpbb6i/qAvC54Hs84Ab47w/+IdMVUB1er0MHgfJUC6UhqB/ZhljKgTrXGCkBWVuUklNA maP5WKIAQ+3nGAqewJQlSVvBeS65aYINAif7NvXdBmo+tYi1GySPdX2fvA6MtkSo+0AvoBt8 A2oetZJdgLrMOotCQGFth9YXgE5/dZCnk0466aSTTjofhvdOnF9djv45YT48Hqsejm4D6mbf InwO9i7JdX06gunl7CqPQuJWtyUlDkyn8429A4ROcDzJ4QVR3ybG3L0OearYutrzQHIGraqW FWLHufIancBITOiWfAR8i2br6Z4Ijkb2X1y3Ien4tYnOneCpbC2i6RC6xvdtYD/wak49+3rI 0F5d53UcEp+7+0Y0g+rbSrnq3odcuzMMKbARntjvvLibCVwD5FVTASNUjDAKgbGSVfodkLXM odoBkHnkUFEXcAo/NQ8oH1uWOCqD7KHk0G6BrYRjju998Kzz5HZPA62eNVSrCkpF8UyrD2Yx vVJKHSCACKMh8LWZKEaDckdtJdoC4WK21hO0k9b6jj5gbJAx7AJrHutkiwLyrh5v3AP5s9Ga p6C5tVViJbh/1i8kR4A5Rz63DQFtOkPlzyBbG4NTKoGnnHnd0xvc4/UJzmwg6ikn5DywD7Jt 9ekNzhmusOSRQCclF3VB+5Z2tmggj5bZkxuEt9GVbqDqamZtGBiDDZenHZif6h95HoBanFnm HXB2Ty6a2Bji1sVVeXsYXD1c050FwViuV3PmAmsWS3ttOLimu26KkpAUHDdcGQGuO65xKd3B dCuGbQrQyOzn6Qkp9RPjE1eD70u/k75LwPbUl6BDYFthu2crBZYgSy6LCfoRWcEoDY58jn72 r0Cr5+jq8xj0H+QxskPwg8y1rDPBtSR5j+dz8FT3RDo3gQgXLk9JcLVNqZlYBcwJnBSnQdmk HE9oDa6qKbUTaoBvmcDh/hbw6u8z1ecsJOWLb5x4B8QxI0FfB9oaYSUAXJ+6bNQF96cp5+Me gOlWM5ICvgPVgt6Z/2RQpZNOOumkk046/5G8/+voung1S2wAthR7QccXkBKr9zb3g389W13v 4pBnf856XoXgfubnt6LfgvN08o/qY0hs4QyOuA/WHfaNShjEHk4M0jaD3ihljnEHkh4qRVOy giOfWsT3JIjbz7ck2yG+Q8prjwaeO/o+nxPgshslnBkhe1LATvcjyNK1XIXATaBcdjSJ+RiK 9NYbl30KZRoUGNW2PniV8ikaEgn2U1K/Hw5qqyvdxTPQV+qDxRtQ95vZxU0w2opR7mlgZpXF zL5AG7nGyA5yhbndvA+Wby35tcbgHmD2MYqBWs8+wR4DyjatnuUTEPPN+XIXiI56Zk8s6CeN zuYNMBU5Wb8E6k2Z0dIPLCetv1jzg2ejp58xEdgg9iv9QD/hbqEvAqUNmZQ1YHzqeRm3BNxF U/K7O4LaUX3rNQlEWWs+5RCYZT2Rrq9Ajjdye2qAcZcb5nJQsssU0xesty3rrePBaUnxTfIF PUyvnHwItB7aeksIuNcZV+V34N7h2u3JA9aFmmIbB8plpbh6FozF+lXXIbAXtFxX94EzJrF/ /HRI7JjQJHo8mAv0JcYj0Hu4eyf/BqpLidF+A7MQucVl0Hvohww7iCZyiCcrJM94U/+VBrZQ r7XeT0HZz2DhASPck+KJg6hGb9+m7AKvNp5RRiBosy1V7QGgjFR2asvB1tE2wWoHo59Yqg2D +HKuScYIMAPlb7jBM1ef4MkE2izrdu05iH3G10oFcH/t+VW/D+7+7qHuceCql1I24TCombQ9 tiGgepSMshHoX7ilezC8WvP63psASAqMV2KbgzW/Wk7mAds6+wOf7mCpq4329gJX+ZS7Kd+C 9kztbAOUXeZ5VzmgCfAB3hObTjrppJNOOun89bx34myc01daikPITUdRuwkvYxNaebaApki7 ozmktPL0Ng9ByjcxP1kE+F3xy+2XBI96h2d8/gw8LVMS1S7g6+07T+8AUjWfqCNAPDI6xM4F c4c6Tj0I0d++nKJUhNDPA3+2LwOfGtlWmuVAeZjQ36sn+Laxhidq4Mn9tLg5EdrXbVRx8qeQ 9+cclWpMB7e/npdvQM2l9DMygDgRPcn3BbD77XFPHrD2s5S1PgJjpfpYvgLlhtFF6wxiP4PF KTAfmqM8hyDlcMKFqMqgB7orOwJA6a1EqVFgbtZe2BuA+VQbb/sJ5ESjqiwAtsX22vaSYA1U p1m/gZS8zlbxp0E2Zii+4Llh7DWOgyosvbTsIGaYE9y9wKzlbuu6ATjUtupIcCYnnk+4A2Yj 44H+GKyR9sIyFtyexEdvKoFtvr2a/SX4TPXrEtgL1CNKcctq0EcZDw0buOu41zkLgvrMEqvM BFGaa8YhUOZrS233wdNMOlKug1aHZkp7iG0UvT8iGSx11HjlPJiZzPv6dUhZxCppAbOaOc3I A+o3aoLqC3TmrNIZRBfxEzrohc2RxmlQ/fQL4kvw1NEXGHnBbGru9EwDM9J8IoaAGc4qMRIo QX2xGqw3LHusn4PxiBMyAjxD5FUkqINEA2U6yGSJrAgyXO6Wc8HdxBXjmQtmayXCcIN1tPWc 7THoAe4aZjy4luplYmeAiNC3eMqDUkbtLp6ANkO4tMygTfdvGjQBvAICXKFHgEfmF3IVyBH6 dL0KmAXdPxuTwTHHawMmCDcVPKOB9sqv1iSgsVghtoJvLt9HQd+D55DrvlES4ru8tb8eBsT+ 1SGeTjrppJNOOul8KN774UCtvv2mPArx9Yzxkb1BX+0+7boAMRWjM6V0gxvue8MSc0FSA9sO 6sPbx+56L6dCWObALTIMMhXOcFdZCklvvKYm3wP2sVJ2AqWb6m95AkFdLIc9U8DWTM1vjoMn VRMDYm9CwtikIN0Bro7MdJWEYs9Ch9V6Dv2LtZq57hbkmpg9T60VkPzY+cjjA+6sno/jfoYX j15Uu7YMoprdzhI+FDIm277zKgs2TZ2p2kAZrJziEciHopVxHsRaZZcyB6RmRvAU5G6juT4X tOHqWusz8Nrteyk0HHy+Dvg6pDQ4VO9k77pgvejltowG233bR2oJEEivxDvg+MX/SEAp8Lnv VyWoBXhdcVSz5QRboDZfLwPqEIT8FeJHxH3y9gQklonfGV0VlJ/Vl1o86A30OR4HpJSNL//a AeYevb7nEcgJIlz1A6OV9DdXgT5S7+G8COZ01ssHYC9rv+ioDFp2S23rftCOWw46ToO8qfxi eQvyKxFrkeDu6azqHgd6Hc9AdxlIzJLwKOoSOF+lZIgPheT6zmmJ1UE+E7q5Gsy18r7cAKKx 2CK9gRM0F3vA9DFaGGvBnGwEeXRgvN7FPQyM/p4Rug3MV+YKT3PwHPLMdHUCGWi2EXfBVdoz xV0XrEPsV3z6gbZd+cq6EXgpPWQDdYdWV+sCnvN6T/0HcIe716WMBrO/EaPfA7Mc31ERLL/a RjoiQD1l/ca3JLDffsHyDOylvfL71AKvRQHPMzwH72p++UKygK2nJd5WACwTLK9tPcHl485n /AraAKWJ2ha8Nnk9trcE7zy+LQKjwL96kDW4C3hH+Vf1iwdLG3sT2wnQDsrmnkKgrrZVsnyg j5/8JzM9z/Q80/P84/LU95j+u0j9ktesWbNmzZoFNf1q+tX0S/vyV+qHTV68ePHixYu/Wmv/ 77B69erVq1enfcAg9QuQA28NvDXwFkRlj8oelf3fJ8+/2q9+z5//p/Pvjtd/F1ufbX229RlM fTv17dS3/7j+P82/0/l/g/dOnJ0226j4veDwDTjv/QwsT7xLylaQGGmUizEh6vPoH96uh6yL LIn+5yG2QnxBZT345LDtz5wDvLPbv1MuQv4cwU99osE/1jtFWQQ5e/v2DZ0OWoJWSP0aLFfk Cuti0CZ5XP4FIer863uJjeCjGcHWAl9Cm7vd7009C14zgrUsecH1ozMmcQ6IHDJSLwVx118F ve4FamfPff9roKxJCDMWQKbYzLrfJlAaiwdmJVCfqo9tr0AOMVp7WoAIk9X0T8A+yPbUOhu8 ZwbOCukMfg1Du2X5EWzz/Bb5ZgQ1wfbUdgYsXRxOr/XgeyHQHrIc3N31+UmvINEr7sLrbaBe 8MxP7Axu/+S6cQvANTg5V1w1SC6R+HX8IcAiN5rnwUf3rRo4EtRb6jw2gHLHulxtANYdXi6H H9i/cuz1qwc+KwNjMoaBdx5vH5+TIHvqLmMTyPyin9oNtG1akrofzFpmD09tSBqaNCL+K0hZ 5JLJJSF6/uv+L8rCy3MvCtx/ASlTnU+jD4DrI2fZlIWg7/bsM2qAuck4ZhYF1silbAZ3CXes ewp4SnsU9xUwrEYJPTco/ZQQpRGIysIieoHZlnLiV6C5EqvMAgLEFrEGtKlqf+tGUI+IUcIL POU8lZI/AuWwmlW1gm2vLZf3ddBQK2k1QBQVikgGZb7WSDsCaop9lb0UWB9bu9lDQO2htlBG g6yrH9Abgjgt4zx3wTLelqya4DjgVTzjIDCbKLPVtqC0s863h4M1oyXQPhWMTe5L7ofg/Dpx a9wloLqc63kJlGeUswu4LM5G8UsgeW/yvfiW4DrhvJhQE1yXkiYnvQKzr2dnSizYunt9bfkI gscFvw797q8O7389qZ+8/as5Ofvk7JOz006EPc72ONvjLAxYOmDpgKVwbv65+efmw7dtvm3z bZu/Wtr/fI4dO3bs2LG0C5HqX1T/ovoXMHTt0LVD18Lprqe7nu4KMwrOKDij4F8t7YfjP8Wf 0/lzHGl7pO2RtmkXQNMOTjs47SBcWnhp4aWFae3+t/p3Oh+G906cvU1X34yTIcD0sea4A2Fl /U6FNYRa93KsKVMQ6m2v/rjcWQgaFvhIpEDpb/IeytoZ5H6tjuEGn0fe3wQ9gGd5E2clNYO4 XCnelmZglBHDU3KBslmssydDxuUBBTLVgay3VN+YqtDgSsEdJQZDD98+1+bUA2eg7GBWAeOa +1FKf9DmaDH2E5AyIalYvD84etqXKOcgJvp5vpfFwPaT1W6NgkKDSkWWFmDrof0oPgKtqNhm qQKymRlBBzAiRUP1e1BM7Vf7SlC2KY/EXZAvjWzu38DwdtuTu4Dxq7NuwhvQjzlbJdYEd5bk ZokNQRpGJsty8JrvbQatBFfm5L5J9yAlY/LbOAOM7/SP5FlQWij1rKXBddMYkzIGtEe2Vdpz 8MoTYAlOANsF72e+k8H3QVBc6ENwJAX+EroYLDtsbx066Em6on8K5lDjorEEhGk+Mr8BJhol jIrgdjvXO0eAtZ+thqUmaFe0HZZ48B0XtD24L4TVzOooNBp8h3j/FvolmD/qI1Pqg/GRsdmz AFwD3YGuG+BW3WddzcDYpi/WT4DpkVIvDZ7hehfPJNB9zEMGYHSjpnwORoq+xD0bzJfGJfca UJOUPWImKNfUPZaWoOWyxvqsBt+gDJUyvoZAM/izrBnB2tQ+27cAiEX2mV5fgJrZGmaLAy4a 34kBYO3ER9YRILOJKHUTyEl4qflAfawdtxwHWVIeEfdAOWXk1d+ALOYZ4tGAikZd41dQtygl lAxAnPq5PTeoU603bSrY13ud8B4HIZ9mnJOpEtj7Ob7xDwOfXv4HQyuC/xr/K6EhoERpjbzu grim5rLMA+s12xnv1mCu1UY6coOlsH2jV7UPF6ixsbGxsbFpn0xtsL3B9gbboenEphObTkz7 5Gtqu3379u3btw9atWrVqlUraJ69efbm2aFRo0aNGjWCZdeXXV92/R/383uVp79fPjZ8bPjY 8LTfvS/1vtT70j9ul1rpabK7ye4mu2F+8fnF5xd/9/G3nNpyasupvy+fvbK9sr0ytDnc5nCb w9C5U+dOnTul6SkVXdd1Xf/zdvhn9fP3y2d0mNFhRgdoHNY4rHEYfHfkuyPfHUmzW+p7c+cU mVNkTpG07f+sHd9Xn3ua7mm6p2na78/KfVbus3JQvl/5fuX7wf6p+6fun5r2SeL31efc03NP zz2dZq/OhTsX7lwYXmR8kfFFxn/c7o/86l3j5ff8+V37iYiIiIiIgO6e7p7uHmjWrFmzZs3S 7PpHfrLq9qrbq25D+4T2Ce0T3j+OP7ReExMTExMTYfDgwYMHD07z59Q7Oql6+GfH96H8NZUz njOeMx54Pen1pNeT0r6A+Ff5dzr/M3nvxNk/p/9Br5yQGJl4MmIVuK8k3Y1qA/pF8PwIYwd1 TVpXDj5t3Wh3//UQktHXLyUZ8vbOUjfzMMi8QBvgewYyNfRqYV0BGbJn7GScgleGO9B6G559 nHgvajIoeV2l7/eF+mpZS7sa0LlDH2VuEVCa+5fwEyBKeL5Ri4JoqwaqN0G/JUcZp0D6mZ+6 n0JSP89i5w8Q2+PVm4iRkOP7EqeqvgHvhSE5so8FR4JlrRYK9jyajyUAjM5yhzkfFAfexieg ThT9xAlwPU6u53wLrnzO/fpzkPPNGzhBl64g1waQNr2aZxYY+/Rv3TdByyY2GH2BfdbKjhjQ 7tr9fCzgwKuanwP42HpWOQTWHY4qjuPgE+KXEFQSHBe9dwdMAts4+w8+EWAJl/VEbtDvpvzm mgtilFbe4gF1n7WuowpY8LEFBYH1F58CgSdBDFC3Wb4C9xxztdocLM284v1LgPVXryMZhoGX 1a9f2CnwOeybP2NB8OkQWDqkOHi1DRwXOh+yDMw9qeRXEJKYZUHucAjaGToiux8EbQs9mf1n 8GkXGJWpOlgK2ZJ8AkBJtNT1ngO+df0PhJaHwIUZKmW9Do7ePitCNfB9FJQ32y8Q3Dbr6MLL ITh39rbFNkGQyBSU5zsIzho6Mu8TsLfyPpVxMojaShm1GFhqq8fFp6DMlV7Gr2DsNSoll4SU pykdYz8Dz1cp3eLnArP0Gs5OYAS72yWHgZJVBpg1waihr1eygZmNIPdCMFvIchYF3BXcWY0o 8Kx1/5TUE4y+bnfKJFAKyIJmHRALucs84I4wZTtwF3PtcjcCfYcnSl8NMrvpNueA4q2MkT+C nt+1ydgIqhVvcQm8clgsMuLDBeq0A9MOTDsAIc9CnoU8g10vd73c9RK2Pd/2fNtzCBsfNj5s fFpFde39tffX3odPS31a6tNSabcsl19ffn35dfjpwk8Xfrrw5+WZmGVilolZ0n4vKr2o9KLS /9iuZo2aNWrWgKXll5ZfWh5WrV61etXqD6eXVMpeKXul7BUY7j/cf7g/HJp+aPqh6WkJTLY3 2d5kewMTGk9oPOEv+KJD7eG1h9cenpborB++fvj64dB2etvpbafD0n5L+y3tB2vXrV23dl3a dv9qO/4ez188f/H8b6a0dOvWrVu3bmmJYLt27dq1awd3vO543fF6//0F1w2uG1w3LaGpta7W ulrrYPrR6UenH/3H9n/kV+8aL7/nz+/az/S46XHT4+CTx588/uQxbNu2bdu2bZBtb7a92fb+ 8/pYs3rN6jWr39/+H1qvCxYsWLBgQVoCu/Plzpc7X0L1NdXXVF8DM3+d+evMX//58X1oRm8Z vWX0lrQL1d/j3+3f6fzP4r0fDhRrgw5GLQN7JcuOwDaQvDF2p/sF2F6ywOENuyfuGjHrGJhb nD0SRkK+p5lu1JwO1iTXMvdweKwbJ29OhiK37GOqhkHyN8IdUwmOhl2oHp0LClQMHp1zOHRZ 3aXtVzkh87l8a8vYwN3X863nZ9C7uHfoS0B5pL6Rp0DJQagaDfo6T5gzAMQwM9LwgM8q+/qg apD3bpmfqxYCv31ZvAKLQ1LbyFmuyZChUcB+3wqg1Y36MbkfyHqudS4XyMfmWsqAckMbpg4G MSflsPMIpHyWUDt6Abg91h5eJ8BSTHvFPHCaKTOc60BroF2zXAM1Sl6VOcEcK11GXRC7RLDY CvorvY77V7BYLddsDjC+dK5LWAP6t0mxxhAQuvpUWwfWQfYePj+BGKresRQBNcH2g7Ic9Hv6 Ulc/oKJxw5gOLJC/GblBhCuh2jIw7sm36jhQ8iqnjVEgPuIZh8B4pO8RV0EJtnaUWYC9yhl1 Gphz9NzGPdDuWvtZvwfvbJYNoTPAq4UZGZIESg+Lr9oa8LjnpVwDz2z366TPgfPGZPkZqG6t m+gHcr74RSkDlinKOLEKpFv+ZFwGo7ZURCkAoasVQPrxXOkIen2zLUXAaKF7uXqAraD1pVIU uGl0s5hg5DWcrrJgv6mFaRKML6yH7Q1A2YuvCdg/sdQXc8G4ZF6XdUCXeogZBWYxEWUEgzJJ WWcZBWoZrYAjEFRT3NGug+av1NLjQS/kee0eAmI9X6rhoJVWs1v6gesT1zWjIzij3XcNFZTW SgPLHDBUs4DcDkyVTnEDRGXVY/8exFVLNbMneHvUxvomsBvWLmrMfwVJ2/cP1NPdTnc73Q12 ZtqZaWcmUH5RflF+SVvfrX239t3aQ8OuDbs27ApH8x3NdzQfXO5zuc/lPrA+dn3s+li4d+He hXsXwGxoNjQbAj3pSc9/3QEm9QRrCbYEW4LBU89Tz1MPuMhFLv7+dqkVpqdbnm55uuX3+03l 4sWLFy/+TX85puSYkmMKVN1VdVfVXfBLxl8y/pIRFl9ZfGXxFRjNaEb/64b9DxSfV3xe8Xkg FovFYvF/s3yr2Cq2gqeMp4ynTJp+llZYWmFphfe347vqM1d0ruhc0UAQQQTBoJWDVg5aCdn3 Zd+XfR90/KHjDx1/gCk5puSYkgO2s53t/HkaZ26cufHfvL6xRVSLqBZR8PPYn8f+PBY4yUlO /qO8v+dX7xovv8e79iNLypKyJEzMOjHrxKzAfe5zH+purru57maYwhSm/F/00LpV61atW4Fy W7mt3Ial55eeX3r+z9v/Q+v1aPzR+KPxsO7SukvrLgGd6EQnaBHZIrJFJCydv3T+0vlAE5rQ 5I/H96H89e/j/4/Qi+vF9eL82/w7nf9ZvHfi/Jv1t5ZuDbJG+7Ux2oF9qvKVOQ/OrH9R8PJp ON7qcftjOyDftaAVYWOh0Li8twpvhzfd8Xu1Gq7Uunf+zTzI6sjcXk8CHEk+Tg98VCT/Z3kn QrssbVcMqg+BlsyBpeLBtTVpcvJBMBItb+VZUNqIq9rnIL8xVxn1QSmo5aQXGG2cCcn3gana K+slUA4oa7wPgHHZOev1PPB8n/KlbQIE3w3zzdEFsiVkm5d1Alw0n/wQtReUM25DaQ5mR7OP mQhaHUsZ27cg9nmyexaDmsE+0dIILI2VLiIa+FIuNwCxk0LKM9A0ywz7JlDnOtp6vQVRU+/o EaCMNIeaNhA/O/XkauDJ5XrmnAOmZrbzLAOPTV/p1ECLVzsqq0F/bYabl8BS2dHSuxAoJdWb Wk+QRcxushPod4Qm84OsaBT3LAZ7OdssJRgcE+3t7cNBRkpVdAOs0s/sD85+njkpx0Av5mwo WoNS21rRPgyU8+KuugW0dbRjCliv2CJlOIgdzDdDILZ5wsdJWYFXxhu5ErQrWpT1EChh1kbq AzC+cE5OuQZyl7ndVRSS54pHHATVkOf1rGDZrR7QCoK4LqeaWUB9RQWjNSgPZHmjKKj+6ueO 2+CVrI1Qa4KYpj0xDoFsQKzaCfw/8isSEA3ObHo5boARYmwzH4E1o32DNhfkApnPGAOelu5F pIAryrPC9T047LZxWhMQJ4WpPAB9v2eb0Qe0E2oNsRXU/LYedjuIxzKPfAuis1JGvAHvRFlQ +Q0CJ3of8R0Ozo36S+MQ6OVMp/IVyPz6U1ka1BvqFHMhaBlsR2ylwO+45Zw6EqzSFiQqAPDZ hwhUWUqWkqVA26ft0/b943pxSVwSl8B8bj43n8Ngc7A52ISQfSH7QvalVZKqVKlSpUoV2MEO dvwT+3XPdc91z/3zcluWWZZZlr37dnOKzik6pyh4Ong6eDrA57bPbZ/b4FXjV41fNYZNmzZt 2rQprf35nud7nu8Jt1beWnlrJXQv1r1Y92LwhfcX3l94w8GtB7ce3Aq7YnfF7or9cInzP6uf v0+Y/2h5Kqm3xN/Xju+qz9Rb9o/7PO7zuA9UrFCxQsUKYL9tv22/DYEDAgcEDoA3zd80f9P8 Ayjy71AWK4uVxWl+//f8kV+9a7zQkY50fP9+UqcGqIfUQ+qhv2l3WVwWl/943Kn6TeVD2f9D 6TUyR2SOyBxQc0/NPTX3AGUoQxnAihUriGlimpj2z4/v93hXf31XAjcGbgzc+Nf5dzr/b/Pe ibN7Y9x3lnyQclBrEK+D9WsxLaAE2IcaTYy34Ped9+KcI+BtfuWo4Q83yj1+eCsRMucKvhkw E/yqh37mUw/eLHOH3E6EKgsLlqnXCjoU+DhxcAxYw/yK5I4Az/qU18kPQLmlOkQh0MLkL2pv kD1lNr06mHt4aZwE5Q6zxGVwr/AcSokArzl+EcFPIHLIywyv7oBlnqWF4QvWTl6R9omguC0N HZUgbGX2ill2gddR68vbRyHhhrutrT8Y4+VikQBeb6x5bWUh4Vhcobh5QIxzurM8WIb4f+9I Ape/K4ueG2wt7AFeDYGx4mMygWt2XJk3D8FWz/6Lz2EQW0RW7WvQZlrm2V+BGKz+rD0FG7ZA +0jggdgtyoFYbQwwsoLxvV7BNQHUfEqQGgHubO6aeg6wLdeqaPVA/dZqtZkgP5HfqWuAAsYb vREkDIrVol4CVY2Drj7gOqxXkjfB/sLnsl88aM9s3/u0AEsdi6ZtBa24es96C1hqrtcDQCyR W9zfg/YrGSytwHFcK2MWAltj+0VxHbzueT1TS4IaL8M9uUAOtp5WTXDXcG02ckGKl5Fb+oJ9 lNd933yQctHTljjwrOV75Ri4LupbdW+wtVDzqe1BfaD+bPkY5EJlktwGjhTHIXsTED/Jemo1 0EvKME9d8D/iyGLJAloDtZM1FPTVZndGgngoKigGyNmWFPEpeB7rywkCy4+WmVoimNXNivIX UCY4LllOgKeDZ4OzBKhNtdGqCqKaXC6zg9nUXGkEg8ikvFUlKLnYqRUC72zESANEeUabzcC6 kG+UX8AdpC8x74HrhvmdEQa2p8p9+S14jbRms5b/ryD5+P0DNfXtECsGrhi4YiD0U/up/dS0 9cuWL1u+bDlU2VFlR5UdcGrOqTmn5sC2a9uubbsGGe5kuJPhDpw9e/bs2bN/03EpSlEKuMxl LoPluuW65TpERUVFRUXBgz4P+jzoA6xgBSt+X77Ut1r8USL4z5KlSZYmWf6mYmWdap1qnZr2 O2fOnDlz5kz7fTvqdtTtKJhXfF7xecUhqVtSt6Ru4FfZr7JfZYh0RboiXVB4duHZhWf/ebn+ rH7+LFevXr169eq72/F99VntZLWT1U6mdTery6wus7pAwIKABQELIDJ7ZPbI7FDNWs1azfr+ 49z5auerna+gPe1pD2wJ2RKyJQRKXSx1sdQ7VBJTedd4+XtS/fld+0lamLQwaSHs9d3ru9cX WtCCFsD+lvtb7m8JTGYyk/999v/Qes0yIcuELBNgSvMpzac0T4unl+Nejns5Ds6OODvi7Ahg P/vZ/+f94V399V2pdqfanWp3/n3+nc7/LN47cfa655c7eDZk6eZXMGdBKFkh9JNcdSDwsv9B jy+cM3/b+iQJLo2KbHX7LOibQ2t6bYQgwz3K7Q+F17vnOeKhzraGo2cfhaKB+XpU8gfnEjHO qy+IoeIba1+QkWKhXhdQ5CaSQX4kyjAMRHs5VOkCarAyXS0BepxspiSBo5Vttk8HiHv8+kTs C/jt0rVsZ2Kh4KBSc8q/ATWD9ty2CuR+EPchy65sDbKuAu9A+3L7CVAyp/RzzgKmGQeVeLBE WDLY5oI1wb7JsQGMwpYR6qeglyNCXAZvq888v/Gg7/GEu+uBMVjv78kPjqxe4f5rwTNUj+QH UKpqL9VuoJa3RNITlAHmDDEfRH5lj7IbjDjjml4J3PtdFVMegvpUuaPtAnlJ+svNQKzWSvED uUdMkp+CZ707IrkRcFOJVs6BMdt10d0eZBn5m6gJQrWG+IwGr1degy1+wCq+NbKDucQ93lgC 7uum23gMnsaKt+s6GKf118ZtkNf0ynImmGH0Np+CJdJiagZYe5BfNIfEEQkTk56AUcIIZypY PlcPymagm9w2DfB55j/F/zU4wz2DlWiQCYqhj4TQ3AEL/e+Ar9vWQ8kPlq3aaqUIiBBRVKkO nkvuWfqnoI4go/IJiDXqBUVCUnn3Wn0gWEYoT8y1oAxSy6jTwSgq25tXwPObe6JrCFCWrWp+ 8Ix1n9Z1MDN7Brgag22ibZbWHITdfPr/tfeeYVJV26L2u0Llqs65CU2WHCQZSJJFchIBBcmi gKCogAJKBhVEQIICgiKIBFFyRsk559g0dE6Va4Xvh7e/9uLmbN2wj/ueU++f+cywxhhrzZrV o0eNORerQbxHW/0rUFcpXZSbYCprnCKHgtRJeNcwFpT66lxtG+hThU+1viDc1HuoMkgnpQvy AtB3SyvFcPD+5NrorQ/qZTFE7wTqL3KKcA7kIcYcaTMw9/Es1IJNKpNGTxo9aTS0vdj2YtuL hf0VfqzwY4UfCzcrbaq2qdqmatC3b9++fftC2LWwa2HXoIZWQ6uhQfl95feV3wcz58+cP3M+ DGMYw4Ce5XuW71ke+sztM7fPXGgwosGIBiMebleBnO6Hux/ufhi+5Vu+5fHzw6gfRv0wChjF KEb9sb/gOKmLMy/OvDizMCLl7+/v7+8PddQ6ah0V3iv+XvH3iv/rdvzV5/OoFGy6+qvz+KjP s1vZbmW7lYWMHhk9MnrAj/E/xv8YD75ffb/6fi087m/UmFFjRo0Bvud7vv/X7/N60+tNrzeF lnda3ml5ByKSIpIikmDKlSlXplz56/L+6nop4MHP89zIuZFz/4Ic59POp51PF+baftvp207f doImTZo0adIEpNpSban2f9/8P+7nOm7cuHHjxsFHUz6a8tEU8K71rvWuBcsyyzLLMhiROCJx ROJfl/vP+Gef17/Kf/fnO8j/LITf/nPV9Tp16tSpU+evC3g2qf/oYn2h7vfFT9bcBu/s7X7j tTQ4nXjl9TNzYUn5n7suHwDiBfvbpiZw76f0Bclp8HLDWk832Agd81qX+fAX8H0b6GaeDeIa 22HTJjB8ZbthjwVhsDZY94Hq1X90vgXiduFty0TQXxCWytEgHudFZSuwV0uRrgE5xuLyTcjt lD7wdhRkbU49ltkd1DeVlzKLQ+LIUk2rOMC62tIkaiNIm0xjpb5wrfqBN3Y44SPfR9XnToHL b9xPSZsOxgOmkiEnIGxhQs9iFcHZPPun+6+Ab446S28JBoPtVEgPEBzqlsCPwATN6i8GwmeM EVeC2EKqbpgL2mExQ84Ba8/wVnF3QN3necbdF/LGZhdLPQh6tFoqsAkMp+VlcjEw/GIKsSWD tounxXOgKr703GOgLTBUsp4CeYi4VioBukFrrn8F0mF5jmEQ8AXvCEdBM+kJ2h6QvzYut2gg /qDHKZfAV8ZdNK8aBHL9/b0TQZ4n7TD3AuEJqbxgB6GaOEq7A/JGKd8WAvLLxg3GUqBHa9UC 40CYqY3VboP3Pd9o70LQUvWyqhWUa/4T/oZgv2rtY9oLJmyXQgHltNpIygTL15ZdRhOEDbVG GnqAsDAQ728Axu8MV6R3wPCi1EyoDuZihqtiI5B6iE7CwV818ITeD9zp3lWefJBP6mb1fVCK qWE+Cfzhge2BOmC4KB81WEDtpg2iOdBFWMcO0EeoDkYDx8U3OQQ8rTuUJ8A2zC5FuEE7KTwn VwGphnzFpIO3l3eMOw60jcqmQDUwfmUsK/lB6CruEeuC4hfGCvNB+1lpJPYDQjVrYBYYb5kq S19A1ErrXfssCK0f8YZ5FLz5zvtH3z/3dy/zIEH+MynIVf2rOar/qRTkAFevVr1a9WoQdj3s eth1yJqcNTlrcuFpEgWnNvy7+J/2XIME+U/g0KFDhw4degwRZ1KFsPCTcL7mtQHHq8PM5765 Pr0leGoqZ+znIX+mwauLIO7OHZnaGF6ZGd2szj5oV6X6Dx90hNyzOamu3uANTet0eQ8kHnja 1rgH+Aeoq5VFII7Xk5RcEDVhobE3CLliA2EwCMP1LH0BaPWEKfIiYDKzlZVgsgoNDU+Cb4J0 xZMBuV2P7Np4HFxDNs879QbETh3bZNxd0O9W3ht9FfRPeErcCbHXipVOWgFFK4VvCW8I157P 7OQ8CD5DQPR+BFpJXRFiQb5nvGYxgftE7nNZXcGw0vKERQEpWTovLQa1M62FnmBoJ68x3gP1 E22E9BQwW10dSIbAdtf9zEXgn+vd4a8FlpPmVyxJIKRyz2QA7ZTeQ2sJejgfaMvBPyfwlLcK CB+iSGtBWE+64UdQ5gXOBm4ByXp3/4sgDxHz9VXgPxQ4r4SB2E8cKR4H8bD4q34TxH7GKKMD QhaEnglTgKe0ZwOJwBbpmnkQ+CZ4avn6gD/FN8jVCbQYPcF1GtwrPKk534OlvHWczQ2+tUpV dRCoF7WJ6mywzrRdNo4EqY01zugA42XDWMkK8ieyhyVgXCu9r38H3OYz9Rw4e/gbiu+A9LwQ kAaD6zt/aULBsE/czR0QWvsiAxYwHjecNawGf3Hfd4HvIdDS/4k6FaT3NFUZBtJR6ZSYALbp 1vMhJUBeKD4v9gVfT+9xbydwbfIs9s4GpYM4WJLAv9NdVLWAuYvhW8PLIH3o6+drDIFK6see AaD6GOipBOIseYxpOSiymiQMBKfdGepuC6azxh/MfUD9wT/TnwTWAZb28h7QwoRl5omg/qLu F1eAfMF6SDgBgldeLc/5u5d5kCBB/jvZ59nn2eeBM5YzljMW6F+hf4X+FWBF3RV1V9SF6jHV Y6rHPLqeIEGC/H08suNs+cZU3fUihGT7XogCkpffcwe+hahtcYO18WA6p6VmnoaOzuivax+D NltaHxnrhVu7vYPTNLBeTv/a/TNEFqu04MmioC3QlnIahCR9nN4X1BB9QXZHkOzioTA3sIGL wkXQr+m3xblAqPqjvxNIadaltufgduUbRw5UgbtDJnw8bjWYevz6Y2p30Er49km3QfzUm6i2 AFnBL1eDO+K+tjuywDYnarLjCygnVvGW6gj7Z956MfUA+BN8NX0vQeBZX1HlQzD0Ng8N3w/C /pxlWa+AXtZv9KeA/rPxV8tWoI9eQnoPlOXKOv01UDYoEa4LgE/MFzLBvy57R2ooSL0N0wwW MG20/BReHTyvek97loHlkrWV9RCopdW+2lkwVeMzqT5Im6Tl8s/AG+JV9oK2Uf1AXQ9amuoy 7AehFDfVyiC9LLyv5IJf86dro0Doot0MfAxRz4fE2BLBe9Hzrec7yBdzrVkbgU7q0/7hoKfx g7QGLI1t60PvgFBG2ir2BF1XlnmXgq+1b727P0jNDA2Mz4Ojkr2L5TQIpTS33BvUfdorSklQ mlFBnQO+876reXdB/0hbr30H8lXDeGtbEG4IP5leAsZzVvCD9WfrZgOgXNemioOAGnoTZoI3 wveM/1vQTgj7hL5g2GO8aW0Avma+Tt5B4NniPua5C1nPO9vlVAPTBINNugyGS/IowxDI3uds 6R8J4dsdH1ld4Nho3y82BrWt2NXwHmTvcK71fA8mlxAWiIDABM0ivAv6YSFevgLyRmm09AWY Dpt6yzPA/723r/caiEYhgiPg/1LxBdaD4lYjlSNgb2B8X44C8xXzkFAHSKfE+fJzAIxB/buX eZAg/5msu73u9rrbf7cVj4+BCwYuGLgARtYaWWtkLWhgbWBtYIWKr1R8peIrMGHjhI0TNv77 7fif9lyDBPlP4pEd5ye7hDUs0g9yboiTQ2IgbIatpWMLhFYydQysh+4Vu0S8NRAqVSrZt9ts 0DZF50fthLAnznkPbgdbRnRaeQeYngtbGHEPfOGBHwP9QHpeO+9vBeJkfaq8EMS5HDcdBLWv Pkf/BITKWPztwNjR9J55PbijnWpaPTg1+9OrHydB2YUHO2X4wVb9iZ1lNAj7ylA3JAas1csP Kr0PFE9AUPLBmlm0UdG1YD1ma21yQhFr1K2oTAhraD8RtgOcR1zxedvA1cL5gzsZwnKjG8X3 BGMJ80zrKvA3UiuqIWAeZR5kjQR9r7BVnwXqC/5rfhtYDhjKG14A5RX5bVs5MD9hTQ/EAEXU uv754LvkO+6pDsauhufkTyDQP9BKaQxCD2m53AwM70vD1HRQJDYo34I4RXcKe8FQVY6z+ECP l9prR4EeeitPexAihPbyJDDMMs0wvg7GcYZzxizw9nHey94AqfK911KqgNjb8LxxHch2Q2VT DJjspmnGrSCPkNcbu4J/tPeoezCIqdIJ408guYz3TFFgaCH3FiNAnskV5SIYuprfkm4CHfQj Jg1845UB/rHAKS1W6gq0Ey/or4N/uXe/fzGIn+l18i5DdIuwCLMM4k3VwUAwTJU9pj1g2GDE OgA8/fxdA1YItFQrBO6AXEcZIYpgaC3U1qeBtNUYTzwoPrWfuBL0T7TvA8kgjBITjU0h/JWo /tGNwT/AN1ntBfpxfzf1DqiiuFmqCealpiOmsmCdZ55tiQd9r75UrAWmLYZF0lYw1BQqSamg Xlau+BMhcFzOpjQIt0y/Wl4Bj9W3XykKVpPhJC9CzMbwJ4yDILxZWM/wsqAGAv2UWsDuv3uJ Bwnyn0uRtCJpRdL+biseHzHvx7wf8z4sYQlL/tGAOtThX0iJ/Kv8T3uuQYL8J/HIjnMIcmLs YvCODG2enwZFbhavE+gEHeY9eWdwLsTPKJVZMwrc+4Sx4m0Qy3iWus5A6JnSXatOBm6Icw1b ISD5Yr3zwbBL3GiqA4Hy+WVu7gXxeSuJLUBP4SOpHwizOeR/F3hTjJPvg/dLt9t1G/YXX/rW 1wvA2ivnoygJEha8a2ilQ3bfC1PPlAX0S3XuRoC2X/nA9RlIBy0LzUUgtHLisRI2MF8yVBC3 gRzl6GZ5D8y9LY3tLjDctcx15ILL7eqRuQZsVcKLxA0D40vmySGDIafj/WM3agLvaM8L9cB8 yLbc/gtoZdQd/o9BExknJIFkobKwHRSzuojrEHhLu6+WBT1GHaiEAHcppZcCzMJX0k2Q1+tb hWzQGun7A5+D4BWGaz6QZsq7LOlgWWo8Jr4M3hfconsliMOor2wFcbU8yFYb1BfEwdICUDX/ ePev4B8dsPvehejPinYoVQdMm6T3jPNBkjnq94FUX/MoX4HS0L/EtRqkQcbWajgE0n0fqRvB N88z2mcEtan4kRgKIVUcWL8E/TwLWA3uVPcr3lRQq2t1vCXA9ozpB+kOhKU5Xg8pCYpHe9N3 G+QBej1DDZCOCxlCAKw3TQv1+eB9zrdc9ED67Nytvu5gaWBcqr0L5g6inTPgtfjTvedAj9Z3 CT3BvMoQbXwbyBLPiiNAv65WNn4AmYfTu6fNBYrIJuM0UJ4R2kpPQliaI8r0AYR7bWUid4Mn 4Dd6D0LucXe8egvEKsJczxKQnxS/C/kVPEM8x3zNwNTXMkC+Bko5YYl4GrIOZARydkPY9pAI 230wbxA3az4ocbK4EGYC+1rHOkccuGJd1bx3AOj4dy/yIEGCBAkSJMjj4ZEd57uNnP2MbSA8 M76P2hJ8Kekf3HwRPC/kHMocC/nHhRKeTmBaLdW29AblKp/pn4CUr7dgBjBBreefDOJSsbtx OKi6sj+rBuiD1R/0r0D41PR2WBzoL2JQpgHjtYvaCTBNNZY1r4VDHQ4uPZwNx1472T1zB/TM 6DX35echZOZz2TVNkL6iz8fDmoNLcRbJ7AA5+RsqLH8dHOZn7734Cpgultgetw5y6mY3chWB O+Vye1niIfabuBvRiyC9VV4972Rwd8m33toJ7lddPlctsA9y9Ai9A9bJppu2maBnBDq4eoIa Etil3wdDlMnoeBJ0rxAqzgV9LXH6HFCfVor6r4Chh3GcfBwMTuvgiCGgJ2kfiynANW2ecgk0 f2C1awcEhvhOeS6D/JOhpjgSfFnea+5BoI/3xQs28G+ivOkHsL5uPRxaFOw9bKXFd0ALePY7 K4Ml1X5W2wCu6Ypsbguuqd5u7nNgqCLP9mwAPTQQ44kFabDUVXsS7A7zUHMbYJqUadkIuReE fb5q4BDlxaYJ4B8RGMAH4PW6u3qvgmtw/p70XRC5IzLW+gOYGxsyxQ8gMyZvnXM+5JbJnpfv g7BPQt+0R4IqCu+JDUBdS7T4ChgseduVrqA28zfOvw6mJ623DSMht3ruB+od8HcMjPLVBGaL HdkP8gl5ueFdUM7lj8kbBvIMQ0XDPOATbaneHYxPW1da9oOvij/SmwCmt0kKdATx5cBxLRTk 5not3zwI6WdcIWeAdNXSwTgQAgblmOED0OoIz6tVweC3rRG3QWCJ2luvB96WSrynIphTjCni IPB2y4/J+RVKr046apfgifRKo4p9D3lR2W3FY6DfF14P8fzdyztIkCBBggQJ8jh5ZMe50tXK TYudgeSxZ8+4W0LjH5729FgB8R/VNNddBgwzlbHqoFVTtnAChO+EL8WNwDYhyzAHdIOa6X8J hMliGTET9Hechqw8MIzWm1uPADPFr8TW4D/uLJFfAYRxwly1CGgtAv3YCLcv3xknD4RGhpea 1U+DqLZPlaqQAq4a9yelvAqCkLMzbz+EnSxyskQ8mPJLvFjpKGQ+OavLkvYQL43u0P865FRy WgMvg/Era1TMNCgzueTukmFws+X9qLzKkDsjN8E+EdxH8wLpX4Lla4eteCWw1A4ZES6AYQC3 85pByApHR1kG58+ew24/OMrbbodUAGoI+6UiIO8Orxb+KfjvCNHGz0HdpnzpiwRvpZzdGUNB r6b3UV4G4sUrkgDSTmm80AjErUKUGAriGLNoGgzmCrbr9nUQWtRosaSB9S3LGnMR8Oc733JO BHWef6tnPmQ8mX9MiwNnXf8cbQvoR6Q4sRo4zoZ+Zq4C8m7xfe0GGHZIRfVOwE5q+03gKpu/ UOkIakt9hX4FNFUwGLeB1lVTtV1gaiZvF9OhhLF0yYT7ILfUz2gj4WqXFD2/G0gYhspx4D+r tdLKgv+S/g79Ifyl0F/DwiBrQ04Dd3HI8OQezc8Gy1nzeO1LUC452yn1QLdh1GNAPmYcJ88C PYs0TKD+qM5Qx4Nxn+mwKRS0mZqg1AdDb9NEYzwo7VWL9gwE0rQf9J/B+rI123QXAjvVY8Ik yDic1SJjD9hH2992XATjUcNg4wcgRcl9zRfBI7p7uu4Aiu5QZoG6Sb8trANUdwVXMgTCJL94 D8xV/Fdyl0ElS3FTVAAi71uWOpIhZ2TqAP9VCG0fbXdkw3/r6+mCBAkSJEiQIP9WHv1UjVHe Z25fg+qXSkwoWxQq0ST6xQqgKdZIsR34W2V2zK4P4tfmDaYoEBU+UJJBnSsMUGxgrGXOsb8E 6nLxGX0oqK1zV7pLQ6C2fs/eBywvxIfoGyC/Q94GXxEI1cIuhs0ET2P/j/668MyJhu+VMUN8 h0Q1vAn4lDxDWldQ1dzOOU3AmODSyQWxeUwp82wwfBIeEvM8cN02Pqw8+E/m3s8tB1ETY6fH vQgxW+2fqKVBSo4ZbIkE+9GQ48I6MFYLGxOTCs5L6UVudgBPMU/r+I1gNltWhy8D0e56zeuA sHLGXeYFYBsr/KA0ANmqpqeKIJwTzknVQHvLMzX/fVC/VrdLFhAXa5OkluC7J8xRW4JyTKuu Twf9K/8qXzTIzSwtbb+AUFNLUtygu5VnXNtBLeLZIG0GMV6YaNwOHBFKeeeDXlTLcv0KQl3D Dts4UNeqP/gHQqhqqScXA+s563Vbe7CeNyzV64H1dXlqSASoIwNDfM9D4LR/gvoz2GuFHBKW QITDNNfwGuT18PcTp4P/OU9D/ypIKhGz2CSBEqcslC5D7npXSe8hKBIV87Y1DNwvuycHykBW ca230AXU2740Tw9QVjrzMq5D0a+s/dUG4Fxv2x2yB9KNeV8GOoGWrFRx9gFHDYtoXA6GWoay xgRgPymMAO1HPVooBQFFi9VPQOADJVM8AMJM4aB4FmyHLW3kUhA9MHSIRQazZk60p4OyLpAs DAFd54oP0Aepbs0D/izvLm8SCPsNm5UUyB/pjMobAoJXd2vvgK+O9rOqgFBTbagsBM9pf0/1 Myh5Pf6EaTSEjU58pkQiBHRPJ7EMGF+z9bE8C7YWET+EXPi7l3eQIEGCBAkS5HEiPqoA6abe IE+Ep8821zoowBXbPMOXkBea2udOG9g74cceK8LBtfPOmeQ14B6emZ39Nijl82PzX4L0Wif3 H1kB6tPuL5ypkFsp51UVUJ+ynA39DpQj/l2KFZT76lVLHghL5euCBKFb7JJxO8RlxLYMeR18 9VxlXO+DeMoxJyYD9BLOQ9oaECdkVs78GcRvDMOtXpDmhfQJPQLCc7Zztkqg75L2GiJByPV/ 4mwLpczFM4rthrB7EV9rdcCxzar68iHUEtopJhQk2ZhrHgruqVlTU0aDGitVMU0AzyFhiO09 OD8v+ePs0ZA31Beh1QbTT6F7E6+D3WSbH9EWsjvmD/cCvq9cM/L3QnbLrPSUVuB+2307dwmo p/2DXafA/L4pIDUEa1FjK9qDqarJahkE6mX9uDgelIuBl1wVIPtSbpnk65DvdC10DoGMuznx 6kBIaZfZJa88RC4KibJNAUtZ0/uGvaCf1p70XAThhP6y6ADHAotmfh1CdjqGhk0AQ7T5ScsQ EKOlGo71kFMqb7a4Cpy9cq2+yaCc8i90HQBfD8/bvvfA95J/pTMCrFukbE2B2E9CnrXMA+UH da0eBs4pvrfck8AdrrbRDoNNN76qVwQtjeckO4ij1XA1AgzlhLbiPIh6LdQQng3yLNN6azuw plg/sW4D6VmGy8NBXyQ8TQBMr4qqPARMJQ2vSfNA6CglEgb+3MB19UvwX/d9o1UGrZwfnwSm oXI868HUUnzf8BkYl0pvyCVBaCFMNV4D17W81/zNwJXlaeLcBr4cmut+kEKNG41VQGxjKWX5 BsJuhvSz74SSR0umFS0JWk85I3QDpE3I2+SdAXGvJHaLdIPpjNZXLPp3L+8gQYIECRIkyOPk kSPOxVzWlg1eg4T6JdRaRsgzZa5MTYDLlY7XPDwXMq5HLxcHw0/T955b+zQk5ZqSiy2GenO6 hXUWgN2GsQY70Mi1LzscAlty1qdvAJPziWWVqkJ2u9TEw3tAaqU/YzkPhr2md6rNAH+jwCZF AfqpV/TJIJ8UcgxfgFBV6C9dBOVYyqL0W6D0kX6ypII5PrJMjB2E8nGnEgxg/DosNaQNCFe1 qnptMCTbnjE1g+z5troXJkHG7Ny6xzbDE788cT2iNdw/kN/bPwgcz0R9XSwPskrfXX61Pni3 OLvnPwfmF2zmMBcI8/357rcgt5uvrP4DaEPSnK6NEPKFsb2mQsT7McOjt4I+TwvRKoB5orNh /liIXBE6J6w26CcwiG+A63P/Tc99yD/qbu3/FDwGT2lvTRBSpf7mVqDdob8gglhLb6MOBJfg /SbfCEIbqrIQ4ntGznWMg9BQ02tCA3AN9S7StoHwnthT2A2W7cZ20nXwlQy00vtCzonsvKz+ 4C+pXGQOeD5V4p3fgX5He9M3HeyfGWcoHSBw0ecLFAfPDP8sBkJcvbDh0SfgZt+M5ZlvQHZP 1zztSQh8rRcXvwDLdNPoQGWwpxpfl8sAw9RtykfACGMXqQrkr/BWZAzkNnDP8drBuEyKlH6E uG/DqpvHg5gs7pTqgTLF3MlkAmNl/25/K9AOCht4E8QhSrJQEvRspZo+Hkwuk0hx8LX2TvFN AmmZMFFMgZzueQHXVghUUSfodSEQo61SvgPDBtNRqxW8Z3xprmMQ+kro4fCFoFxW/NrnoIzR NymAuFafbvgZikWHnRKPQqWrZQxJXcHyoaGMbRhIPeTN9uYQkRSRGa7A8eW/9r7UFKrx9Hb2 /93LPEiQIEGCBAnyOHjkiPOTExrP7fg6+D1qZ2URSCcMJosMjIiYL2+CnPbub/JqQ8YYebKr DISEJS7UK0GgUcbH19LB+G5k+ciRwAzPscwhEPVCbDHHDZDqmCcZh0JkpegaT1yAqFVxz5Xq C8pJ5Qd9KAhRbNRrgfi9fo7VoF8VvHwJ2k7QM0D/TC0rhADrbI0cm0C3+ZZor4JhgMFi2ASS OWlB2GJgoz5ZXAd+0X3XPQvKbC8SF/UZ5E/TU/RQcE/MmpHxBRQLjdguVgLDJsfkqOZgruGI CLsOvvHZTdIqgJCgfWScAuYFtvm2FuC54uss/AR5o/W2sgNyPEK0eRp4PlfGCn1A26q1l8aC Ybt5u80D2pvaCDUNXKdcN13dQDqrZvp3QsKL4dH2UCiWHHMl/H0wBrRFPg2kgHo0kA6OauYF tq/BvNG41NAWLDMNh6VdYL4nHzZ0hxst07Izj4Lfpg9UvwJbZ+tkRylwj3O19IbB3VczEjOX Qk4F19m8T8D9grd69hTwzHRHpdcB5btAH2c+uG56GmthIEVLJ7WFUOyZ6G+i0uBc+I2X0yMg uUl2iLcvZPdwDfbMBWGurqjrIdQk1RdXQ8xcW32xHQhrjQ2lUpBlcdaU8sH/TeAH9T2Ijgxr aVkHtkXmAwYLENBf0zZA+tksKa8+ZE/PfddlA29Nj9XzGXi35fvyvwP3JleL3E4gvcgs70eg GrwZ4inQs/X2chvIPutc5GsFmWOcxTytIO1aTv2cXMge6RztXgbZh3Ob53QA4xmjhzlgLCtu FnZByArb08ZPIWyRPdy2BQwBQw7TIHFf8ZSo7RB/K657XASErjWF2+5B0culL5SZD4Ha7qGa Ca55j5svNvy7l3eQIEGCBAkS5HHyyBFnx4mosISaoL2hLyUBRN0YYTgJ6a/n/JD9Ari0O5b7 Nqg5rPydajeh0tdVlzYaBcpx01z5Lkj1tUO6BdRa3jzXD8ABoRPNgZXqcldp0O7n/+x5HsRy Ea0T7oI0ObBKuQ7aL+IqtgIlxVfQwT9LbeZ7FUwj/P38t0BtoxyTvgQ915RvHwbCBnc/eQJw H6TtYFydWCu2AvC9khz4DPytMxrcLQp5/Ryd07KgXPMaxifrwtkj5w4s8EHdtlW+Kv8y2Dvp i2KWw68rvBuK9oacw3cHXSwNnmF5r6euAEub8FcjDoM0KPCWbxZoicoAbSxoY4yXo6tA3pP6 M+r3oLzra+BqAYbr6nfafnC95DnkLgO2TtZFjuMQMldoLB0C68eGdoafQdrBXO0AJB2KnxE5 CFxHfYKyBDyT8pflNIMik2KPRUeAs4I3VK0FYh35Y9kCRZ63f17sFogGHa8Knqnuy85l4Lzv Sc3dAt6jnmUeL5i3mk6YQoGZwl7TJ2C/aF0fYgPLQDlUeBMsc6RqypdgGmf81GqEq1PuXnNO B9cCLcfXHyy7DG+brkP0ppAKpkWQMj516L0wiF7g6G19EezNbW1Dq8G5wJ3x958D04emKPsw cLxgmG4uB7JBSXANAK2LlibugWRT7gilOejJ6jr/TdCq8oKxM+Q0UocEUkATvZ2UVaA9r1xw bQHnFPlbPQNEu1Bd7wHhgeiace9CYIJSnyyQw8X76nlwpFk+FU+BnqsP1BPBuF7epT0FIbfN FoqAuidwy9cDzNvte8JNoK/0b9E7QthPsSXt0RB1ofS+cmvBk63ppj4QnR5fMqYZhBsT1kan wJH4NYN+tcGNtfdfvRMCdPp7FnZOTk5OTg4sWbJkyZIlhe29evXq1asXhIWFhYWF/T22BQkS JEiQIP+v8siOs35ZSNQXgWpz1ckfDVnK/elXYqDEFNVmqQTlJlSVn+0LiUWqbnr6WdB+iGmW WBbEG/4bvgQQr+ohwkJwvn+r1anBYE2P9VYpD7rTPTD/DeAjd//s2sC9iG8TqoJ+SWykZ4L+ jHAPGaR9epqwEvRaJAVOgvdjX7irNwRqXl+RvBW0hVpfukNOX9me9xI4Tt1ZeXEaeDcd63Gs KliefGJniXNgrlxNK30Q9Pve2iET4Mm3inxm8YBvWJONt69BxfIV3m8dCc1n1R3orQWpp6Y+ +V0nOPWle1icB9yfZl65ewLkhpZ0x1tgmmw+FvYL+O7k/5y9CdwTc45kfwwGn8lubAVCcWGe 0APch/Uk+VOwPGd0hZUH7zfqEvZCTgtpidgcfJGBbfSE6I2OF2wCmEzm8rYPIL+NM9d9FwIR 5ommphC60Pq09STEPhPeQU4DbxPfZH0MOMnLz70CUi/hpv4hSLPtJQ1jwHbd3Dr0E/CO9jWy 9Ac6KJ8GqoIYbdCN1yC7s3ub8j0EFvoFYRKwUx4uVoKzn9xMTEuHwBU5TpsFDqNpo6kMMEup k1EO7rZPHy12B/uTlq9NHiBNTPMIkGHK+sn8JYT9GjYleijEGcNTrCMgV86pkXcf/C5/ef0l yBiVe8f5GfjWqifUyxC1IuQXc2MwiaYP9DfA9mZggHgQMjSOyvtAjpPU8EsQvTfkuCkWTGXl xWoW+Fv564o7wPMc29RyIHUzCgYdpM3aUUt10CvrDQM/grpB66zPhPyl7sqqA6RXTbuNiyCv q3OfdwQ4Tpg3GVZCwtqEYzHbQSgvHrAuBbW1Wk2+CPYjsVvjLkFgjGux6x046DvgPmaCk9Vv Nrmh/30Lu2HDhg0bNix0oAsocKRPnjx58uTJv8++IEGCBPmfgtPpcvl8MH36okW//gqXL9+8 mZ3979NXtmxSUng4vP12377PPAN2u81mMv3eHp8vEIApU3bvvnABLl/OyvJ6/532RESYzfDu uw0bli8PdrvJZDAU9nu9mqZpsGdPZmZeHuTmKoqi/PvsCQ2VZVmGBg0iI0NCwGwWRfGR8ysK efRTNba5NrjWgDfffSlnMdhqha2KHQpFm7QqWqciaJM5px+GQFnlbTUV9Hle1XsL6CuG6a1B NQbechnBHB7+amQtkGsWXVi+IkjT7fVCGoG+zRYZPgY0TbUL74DeQ/ieliDM5bwQA1oFuvI9 mNYKDsd0UOvZbOHrIXxz7WoJteHUkbuNvH44Xjvm80uXoOtoKetWONzfVF6/+zEkXC3xTrFw sL1t6hX/KkhlzLPDPgEJvbX/I2j6RhP/qIqgf6Zn0weE9xKO8DZ0rNks7mI7uDlwTevT30BO hOtgTnlwfpDV6F4mhImxZYt+AKYytsiQxeDpkX88excEZnqaaYdAaC3uYwcIvxpmiXYQbwUm WL4GJVSuYvwY3NvMfeV4kFb6PvP0AF+e+jLfQP5CV9vcj8F8SnXkPQfZQzLu3P8RmGf+Orw/ MDPQStkA4gh5kToFzCstq0zrQRhGB/kE6PmBUO9pCOlpuiPVBc0oOWwtQUkXM8zx4I5yj1Gq gauDx+B5BlilDfL2AfF54Yh1C4TlRtyyG8D1RN72HAd47ru/yt0I8aZoQ9S7kJmbUe1KDwjp FLY4qRqEfukYHfsOZN/1dfWfA39OzlvqWch425uVMgPMWy1fmb6GrBP5v3pvg6e9N9aXBEWy 4udEnAHDfkNN62zgJbWjNxrCT4Q+a24E6nh/87z+kBrjCnd1hkxN+EYeAPrHpGkfg9aTUjQB 07cGlzER1IPCc/oRCPysfazNBd/4wGztF1CeVF73dAepkvaZUBP0IbTyiOBYY02ST0KJisWc ZTSI6Bd1MbIWGD72v6KlQ/hP0c7onWC6LS4RQ+HAwbWrjy2DX05fdF7+BNLiFYN25d/3xfAw du/evXv3bjh16tSpU6fgxo0bN27cKOwvUaJEiRIlCscVONhBggQJEuRfY8qU+fP37IHMzLy8 QADKlClVKioKBEEQBOHx6dF1Xdd1SEvLyHA6C/VOmDB8eLNmheMmTNi27exZ8Hg0TRDg6aeL FYuI+M2ex3nfv1kDN25kZjqdhXqnTHnhherVC8ft2JGRkZMDVqskSRJUqxYaarfD47UG9P8T rLp71+Px+Qr1tmoVExMR8fj0PLLj7C7nLJ79FBgvGBeY54CUGzIhfB94nN42nmIgFNNuC6mg rpC3Mg6EJ8QW+miQ4ggxbAR9m/qO+yUwPl/8+4rnwHjEtt1xDdTa/MR1IIZBYlEwmPSe/qcg 8KzgYyNwUG8s5oLuFQ7rd4DW1FHDQLzp32MoBtbyDd+o9Qbkn81K2pINOWWSd/k7QF5Tdrl3 gzqt1JGiVeHXtpfP7c2AZntDwbtKlgAAPERJREFUTpZ7CbxhaUfNR+H+J7ctmQoY6xqWZA2H 7C4pi++fgOxF9wdcSYFTfW+9mBwF1g8cjUJ+AfcLfFWuPXiH3jxwbBPkj8zem94aQm5FRsRs AmN9i9lfBwJOX/Hcl0HqJ7YXhoK9pzUipBUw3WAxDgPjc3KyOBFCc8UF2jkwlDDedhyCuzfy Juix4Ovo+s73EmSd0gcY8kCpZ8yJ0qHI3JCSxo8hc1zWYvdwkBZwS8+BPJf7Z90CvlJqfZ8Z 5BLyEiEdvOW1UtpzILcQQ3LfhHtazjnXHpBEYw1HRTDWMviMDcE0yVDJ8SJYj3PDuw989z1f ZKWCepJpuhVMQ8zbtBBQjqvvaVWgyHOxlcpOhfB6EbG2M+B50XVBngt5KdkXPR3A1UMb5+8E jhr2c5bj4G0cSNbKgLenupUOEPtGzMKo02Cda21tKQJ3HffGZ7shMCjQ33MMOKrPCqyAHIN3 rd8FwhfyK9aGEFis3aYumGdb5hu/AeMBOVs6DspoLVzsCIoxcN9bDGwzDMOF1WD5UnbIpUH+ UVoRfgVyN/pPBzqBfbJxs9gOyg0tWi82FYr1Lza12H0wrBTuSm9CbETk0PBrEBUe+WVUF7j0 5q9Jl7+HdW02ldodCsl3fWVduSB3FLfZ3/o/i2Tr4/1y+K+oVq1atWrVCuszZ86cOXPmPx8X JEiQIEH+Nc6du3IlKwvi4xMTw8Lg5s179/Ly/n367HaLxWAo1PsgZ86kpOTmQunScXFhYXDg wO3bGRn/Pnvi4mw2s7lQ74Okp/v9igIlS9rtBgNcuODxeP6NLwgLD5ckWYb09N8c6MfNIzvO KW9cNV5/BXzW1DtZE6Dajc5rO2aAP8JXNvAK6CdlM9+BdFY7wVEQmgsDhAWgJ4ineAf0i/o5 XyMQS4pR8ueg/SzckROBq1qfQBMQXhIWCW4ITBJeF6eAeFG7KzYAYoWTig7CMH2/eAS0EByy FfhK+CpQBtTy7peVr6HMiIQ3qnwKt1SvZ+9HkBEuH8jfCYkm7aqjPaS8oH4rfw5ZNe/3urcb PnW8ff3TpXDTlGYIfACRY0yT82aCflCZ7RwJmTGuRZ5XwfOFfX3x6hDfvehPSQnA3JDnQzdD +t2o3GKHwHsgvVNyLHjPGJ8z7wFHSOjbIbdBuMUXehKYs8UFAQnCAgZdvQr6e+pVpxNCOxtf FkuBeZcUFoiCq62SX845Cb72Wp61Hqj76Se5QO9ITW0YyD8JnfWzkJqaG+LfDbbGjvLmNiAP kqta+oO3hifT8z6EZsq9VQnEAK8I18FYVu5iOw3mMHO4OQaM8+xbPBkgFKElN0DcJiQLT4Ba VPsw8D3Ylsnp0jUwv2wsFTUdvE/7OuZWBaEtLYyHwZcTeEKZA77tzmfzcyDQ1LTW6gaX0T0j dyLoC4S3lY+guDe8l1ADjC4hUhoP2WbPAu0exHQJ3WHJh9CTpnTtBOQk5S/O7wFuVftcdwNx pBs+BS2b3jQF80VbZWsOWF4xPG04CmpT/YjaFdQYdZvQGdQ++hHxBshrJT1QG0x9zfVlP4Sv D53l6ADe5d4k+TK4P/bV8lUC2xGDXZoIxTfHng09D7HGYsuLvwl6UeFjSwDsB8WuxlOQ9EEp S2JLcAWyb7qnweYXft6w7wbc6ZJ760YdsBTnE28cKLN0hCjg2X/fl8M/oiB3efHixYsXL4be vXv37t27sL+gPZjjHCRIkCCPB0XRNFWF3NzfUjYeXV4g4PWC1+ty/T7Vzm4PC4uLK9RToPdB /H6/PxCA27dzcpzOwvbU1FOnDhworMfGVq361FOPbm+BngK9f7wfVdV1yMhQlH/Uv2PHli1H j8K+fQcO3LgB9eo99VSJEtC4cfPmNWv+dXsK9BTofdw8ctZHtl9tlDEeMgK0zWsD8neCIl0H oau+S4sGSrCKYyBMFFYJW4B0fa9wGISPhWVCdfAXuRryiwmUndl5ObtBvCEnywHQIoVu4pug b8UjlAHhtvA5PYBRQlXtGtCBIUJF0EUq6dVAGCs0F4qBuJxopoFPEd7V10HR8aW/aHgRmibW mt6xJdifNZeLrwmXN2fI58uA2Ww5GZoN+5IPPn2gPNy8aDHfeRv8VmtNzw6wtyj7RelTUK3a C+8/nwOlGlUrU3cQDC3dv1aXLlDPUUGP+Qhi32dV3lywLohpWmQFyP6wnyLbg2dvznOppcDd 093c+z4YG9urh7QHLVMX5WPg6emZ6ZkExiflO4F88OL91P0jnI+/8fr97yDZkv5dxi3wZntG uUqBdM9oMf4MZp/1VVsX4JTglfqCdM7gMe4Fpb+WYdgNef1cVbxWMC02v2BcBGGWkNrWryGq Ykj1kGZgPi5GKIeAQQGfszeE3DGf5WmI/yri07BkiLlh89vrQuLHtu6OpWAUxGb2HPBvUWb6 wyD/29xn8xMh5dD9L5KngOpQewVmQH6IEuZ9Ga4fzZx0chHI9YRb3pnALv1S7mlw/+pf5i8F 945k3si0guFzKdK/E+xPWEtIb0GKMaO4cx44J3lu+3eAr6K3mvd78Mz2bQ44QbnPKmEBSKX4 TJfBGGPcKY8Fe3l7tKk52MqZV9o+ALmGMVMUIdBJ3ytmQubHeVnaHbgy52av9ATI2JidlHkF lB3K956fIPrrqBetyyB+T/FnEq6D+J08xNQSvDv8lbUPwdEw7vnYzpA3zpkmvApb7m0+ciQK Dv9y5asLnSB9b96etA7grJvV6X5r8I/wTLv/w+NfsH+Wgk2Af7b9UalZs2bNmjX/edllR5cd XXb8fc/lcdNxUsdJHScV3t/DnkvBuP8UVjhWOFY4/vy8FZSXR1wecXnE3219IZMyJ2VOyoT5 /ef3n9//r1+f3y2/W343eMr4lPEpY+F93ml5p+Wdln/33f3nfn6C/N+oqqKoKqiqqmrav176 fF6v2w2TJg0Z0rgxrF8/b96AAYXlH6/7Te+D+P0+n98Pfn8goCiF5f79H3/89tuF5YP9j17+ pvdBAgFNA9C039zYB8sDB06dyswEszkyMjGxsP6w8X+2LND7uHnkiLNcp7Q1ZhqYM8JXhs8C fQdPMgb0xnTjNRB2arH+BFC/1W/rb4HQVnzLsBrE54TSUiKIB4XuhuUg7bTHxCwF9V39B+JB 9PCkUh6EpjwnmUE/oI+hIegNMNILiEYQmoPQRXhKfwNoq9fWT4OewWqxB4g/iZrlACgH5WKB WVBUK6o3uAXiahnpMmRmiqMu34LrztS06z/CxfTrZzy1odzKxinPvABnP/mx04n+EDaweAdH CpSPLrO00mZ48Vi3G70qgnWrrZjpedjVeWfp74pB4z0xt/PHQMiJ47naRjhb0f9GqTuQ9ZF2 WJkIvkUZRVIWgLG3NL1oWZBH2J8MjwLfJ/4ZeR9Bji9vRd4McJcNzBA6QvZB7109C0zHDJ8a moDhW2FdoAKIPZSjbgECYV6XnAzmKZafTM9DYJr/FZ8Vcg7lvZR9DmxFLHMsY0B5RrNYzoDz kreI9BEYS8nFjSfBb9TnaEdAOR8Y6rkMtkmGWbZt4GmXvzowBfxf+VpnXQPXh8rNy0ZIPZW2 P2MFSD/LjbkEhmXCVMto8K73ilJn0FdJ0eYw4EuxSn4AXH5/56yTINZiuv0XyCuXPywvGs7e v/G+KwlKHowfFaVCzBnrfkcipDyX9lT+fvB2Jcs/Fiy1GCWvAXMZOZVsCPsmtLJ5EQjfCPNM x0DZK16UloK817Beeh/UuMBd8WfIDc9/JzsTqEmU1Aasg63HrBUhZm5Ie70FqLn+nqZVYGhv 7mJ8AopMCV8bthcibhaT4haAvMlSx3EN1JrewYyE6K/iLZHnQVZtvcN0OPDSL79cqg57E4+2 PvUipDdgQ+An0L4wzoySwfs03e5+CkJ7qalUEbj371i2D6cgZ3nPnj179uz5Y39Bzl2DBg0a NGhQmOv8uIhsFtksshm8/vrrr7/++h/7HZcdlx2X/3ufyd/J2B/H/jj2R7Db7Xa7/e+2ppC6 devWrVsXxi4du3Ts0sL28W3Gtxnf5uHzGPdN3Ddx3/zd1heypvma5muaQ/EOxTsU7wADGMCA v3D99u3bt2/fDoEqgSqBKoXtWzpu6bilI/SlL33/7psM8h+PohQ4sgUu27/GlClvvtm0KZQq VaxYVNQf+x+UX6D3Qfx+jycQAL/fav2vNuH5/b+lUCiKx+NyFbbLssVis4Guq6qiQCDgcuXn /9ZutYIoGgy/34z4oN4HCQR+2xyoqoV5yL9Hli0Wh+OP9YeN/7MU6H3cPLLjnGW9m5DcC+KG h28t8xEIn6rxehYwmNexAD49V7oA4jrxOWE2EOBTKQa0z7UWWh+QWhQdXnYxiAesg6P3ghCh DvbtBW29fkM+DYwUR7MYBIu+Xh8GegqhmEEogYuaQE39Y8EA+hVK6Dbgnm7UfwC9Oee0viB1 kOtICaA8o36u/ALSfcMU6054YndsqQbdISJX/znkJEQFShw2b4fVpxdnbY6DUu0qno5wQfXc aodMDSE55G7suUqQUC/tmLYdIt+0l7Z3gDLVwlZY3gShrdYi4QVIWSinXPoU7iXYN4Q+B3ot wsp+D86l9745J0OePfPnZB+ET4tclLge9JnWmQ4v5FQJdNOqgzrS60g7CYYW8lDxO4hZG1E8 6kUwdCBFHQup+7Ma3KkAoTVCK0Q8C1pR30npIIRGhehhM8G+w3Jb2gHOX9y/uIeDv6X3SP4e EC4bOhljgXS9p+8+uHI8dzzTwDLa9JK8D9RhygSvC9x3vPmuIuDNC7TI9IC2ybjD1wPk9YZW 9qngHuZ+OudZEHPNc6Q2YF1s3sNJkBsI7+mnQUQfY3sK4sKjo6scgfxJrudzrkKRO5GNY6+D 9JW4LL0vJGwOjQqZCFnlMpd4VsLdrzLJ+RlKvRL/pH0TBGKF/EAtECeYZ1gmgDKHLnwC9nim KF4wLRNP6RfB4BTbyVUhc1de04xvIDrBHm+YAnEXo96L+QnM75i/lo9ByjOZ3d3l4ebY1Ob3 hkLZl0ovK3IOHJuKvBtdEgwLjV1sJ8HTPv9aoBdE1YtJitkLIcti5kQ1hBvvnGt11weH3ziR cbIa3L+oV9WPgDpC/izqGjDdH51yEIxzrdPlm2Bqa0mKf/HxL9h/RkFEucCBHj9+/Pjx4wv7 x44dO3bsWEhKSkpKSnr8+gscxNYJrRNaJ/yDAQkkkADaPG2eNg++rPNlnS/rwLp169atWwcZ GRkZGRkQFRUVFRUF7dq1a9euHfQ51OdQn0MgDhIHiYMKI3EFDtMPo34Y9cOowsjcrTW31txa A0ePHj169Gih+oLr4uLi4uLiwLLMssyyDJzlnOWc5WD4xeEXh1+EphFNI5pGgFJFqaJUgWm5 03Kn5cLGohuLbiwKpUuXLl26NHjae9p72gNrWMOaP95uQY550bSiaUXToNGSRksaLXl8dlTX qmvVNbjd4naL2y3g7o93f7z74x/v+0FKbCuxrcQ2KEEJSvyufTzjGf9fzePbvM3bhfYXm1hs YrGJUOfLOl/W+RKyOmV1yuoEO6btmLZj2p+fn2urrq26tgqmlppaamopOHv27NmzZwvVlnup 3EvlXoKh54aeG3oOZu+fvX/2714sVCBvWNqwtGFpD8/tf5CNaRvTNqZBuU/LfVruUzAuMS4x Lvmd41yjb42+NYDjHOf4o3+OPvN95vvMB5vSN6VvSgen0+l0OqHGFzW+qPEFjB83ftz4cRB1 O+p21O1Cfb79vv2+/dB1WtdpXadB3oy8GXkzYMjZIWeHnIWWMS1jWsY8vnX1sHmd2mVql6ld Hv/3xv/rKMpvDqaiPJqjVrr0/+0wt28/fPjq1f9c74P4/T5fQST49xHpypUHDpwwobAeEVGh Qq1aEBfn9f4+B/rGjezszEwwGNzunByoWbNMmaJF4eLFO3du3IC8PKs1KgqMRocjPPyPeh8k EPjN4X/YvxWybDabzX9snzp1ypQNGx5+/3Xq1KxZpAjUr9+48e83Iz6o93HzyKkahnx/aOA2 hFc1LQ0ZCYEkKgtvgF5f+FB4FoRl4grDBuApwStlAiuE3ZiAnsos9zjQhua2SBsDVNBui6eB 1rwjLAOhsdhPdwMyzfTZgEgW0YBBMCMBqeRzC/Tn6aAng1BNqKo7gO94XvkWdEEb4pdA7810 Yw+Q5gmhUnNQeyvnPCchPMlhLX8VylcpObbVdPDelr83NAazWKa1rS/0cLw4oU0zcDTxjIzo D/6794fm7gencO5QajKEzDXcDtsJxZdGBuK6gj5Q7icVgdBhRVeY+kLkcFvlPDtEjrZ/KSWD eWDcznLbwLjfMN6yAtwNshx3JVDbey74nBAyPeTZ0KbgaBlzusgFiK0VdT0mFWLjomKiJ0Ck NzQ0WofSfYuGlz4LET/ZzoTshah9jp6GimDaoQ93fwpSY+/bWZsgKSVygLwHQrsZyihTwWaT PvduBMMayjsTwfqVsZS5IXj7e+yBJMj+NlNN+xw8+907fBpg1hIc34ApTjtaWYOwk6a+JUPA 2shw09IXuKvazQvBsce0t3g+ZDdzBdKHgf9FfRpFIatRajeXAoa39VdDmoB7pTc5vzGUSo05 Wnwe2D6Q08L3gquZb7b3KMQuj0i03gD7btMi0w6ILxfRLjwOEhuEFbV+Dt7m+WcDdnBssKji KDC20D9RkiCj8v1Xb/cF/4/+zakDIDfRsyyjE1xZmVb+VA+4mHAnPHkp5B7IO+suDhWOVThb JAFKdCotlPgOTAdMvUIVcBVz79S+B+sxR6WwphBGzHtRuXDv+q1vs0rB0SePZZ+6DTdK5u9z HwZvfd0j9gXPWM+G3NfB+bnzbloiGLIs96KWgXuKvtH8xeNbqAXHx40bN27cuHEPH1fgOD9s XIEjffPmzZs3bz5cTsH1f/XYugIH5mE/9W8quqnopqKw7MKyC8suFP7EXnZ32d1ld8P03Om5 03ML6wX93wz/Zvg3wx/f80z9KPWj1I+g0+ROkztNhpwdOTtydsD0XdN3Td9VOG7ps0ufXfos rIleE70mGprdaHaj2Y3Cn/bTPkr7KO2jh+vJ3Zm7M3cn5JfNL5tf9l+3Y9nyZcuXLS+0o/mo 5qOaj4KyM8rOKDuj0GH+7yY5OTk5ObnQcX926LNDnx361+VM3jp56+StcHzA8QHHB8CEjRM2 TtgIUztP7Ty1MyTHJscmxxZGxCdOmDhh4u8cgPgN8RviN8B7zd5r9l6zf67vfsL9hPsJcKLW iVonahU6uE3Dm4Y3DYcbTW80vdEUrl69evXq1YfL+bPz95XhK8NXBvjW8a3jWwc0cjRyNHLA pOKTik8qDhcvXrx48SLMqjSr0qxKD9fT7qN2H7X76L/4nDymdfW45vV/C/9qqkZeXlbWvXuF 5YM82P9nUzUCAZ/P5/vNcf4t8vxbeebMF1+MGVNYFrSvXDlqVJ8+hWWvXnXrlikDmzdPmPDa azBr1sCBnTvDli0TJ77+OtSuHRtrsfxRfoHeB/H7f8s1VtXfzuF4sJQkk8ls/mNpsyUmli79 8PLkyatXfb6Hyy3Q+7h5ZMfZuMicYXwCwvuEHoiIAe1NfYLiBiFfCBFSgTRMekNgu15ZWAbC B+Kn0gQQPvFNz50F6qW8OnkhIH4hzDPvBbWfkKGvAqG2/jUzgUr6SCECdDclEAAJAUDPIwMv CHOYIzQA/RskYS7oWeo0jwRiJ88VTy+gl9vnXQeYmK2lgFBdqEIWiPWkt5gK91dmVU+/B+Lu a09dTYexlm6rhr4JVY5VqN/6KlSrV+fFVu2gVdZLTTv1A8O4Ch8nhsNPK3e22rEatrfbm3V6 ExhPBeZoeVCxsSM8vAHEO/QEz3tQym+Kzn0Syj8dc9nYFkKS4vqWEUDaa9nn6A6+zVmvpp0B /zDnRVdvMCbLltCyoD9vMkWegbQNeQO0KnC3Su50XyPI3OYso7aF1O2ZB90ipH+ZPcj1Jdxr kbEl51swHzdXk5wg3PanacNA7sJkdShEZVtfESpD9HfWL8w1wHFOtqllwHrG9IYxHvwxyuvU B+9Q9UZuKuSKgT0nIiHttZya585A1o5Az0vDwVnL97U7FqQ77DDI4G4dCPHMB8Kl/oZ74O7p M+ZUhPztgf3JCyG9X86xmzMg48Ocrz33IGOt05j2HhheCLvu6AshgiM7ags42pm+xg5hhpDD xgogvKxMNY2D/Av5CZ5nwXhCOqN4gKdEO+1A7S7abWtBm21u6hsEQntb/5xkyL0UKJ7eGS7X vxd6LQ7SIz1n7l2EIiNLdQ6bAcUOF2tdug8IihBv7Q/uYvnFA+lgiXUMCnkNQlfH3ImpDOmf JYfm7YMzsUe+PiXAzRdzD+aGgVrXMNxwCuis+YQuwGqhiVAbpBfCU4vGgbJBDo0XQMgShwt/ 4g/4n6XgPOYCx7cgYvTgOc3/jILUjAdznQvkFMgt0PNX5Rc4MKtXr169evUfy3oX6l2odwG2 T90+dfvUwuvGjBkzZswYqP9N/W/qfwOj14xeM/p3EdwHxz8qRdoWaVukbWEEryBymDU5a3LW 5MJxe7rv6b6ne2F96LKhy4YugwFHBxwdcBTCr4dfD7/+77fjwZSaIeYh5iFmeH3x64tfXwwh b4e8HfL243s+f5bQ50KfC30OZvtm+2b7oPW91vda/wvpSQX3XcD0GdNnTJ8B27K3ZW/LhiGm IaYhJlhmXmZeZoa4lLiUuJTC8cbFxsXGxRD7fOzzsc//c32bJ22etPl3OcNNmjRp0qQJNH6n 8TuN3yls39JpS6ct/8VLjP7s/O37Zd8v+34prBekwDS60uhKoyuw6MSiE4tOQI8ePXr06PFH PYnjE8cnjodu+d3yu+UX6smbnjc9b3rhuMe1rh7XvP5v4cFUjT9b7tixZMkbbxSWD/Jg/4PX PzxV47dznAsizg9GngvH/eP2du2efrp6dXA4LJZ/FAnu3r1evapV/yi/QO+DFEacf6s/WBZE nP9q+cILjRpVrPhwuf+uiPMjp2oUnx3Zu9gXYLhpPmp1gLZCz9bKgRDPDf026Fa9q7AZxASm KA2AEcI863fgeypnZt518B/3SKGHwWgw9JB6gNhZvRxYCqzVw+SNwHKxp+4F4VN9Lvmg79cv 8CsI/YQuLAM1Um+jJYDUVSspXAXfgPy3fQIIKR6n9y4IulzWtACkVqZ12hoQnpVFuQXoi7Qj 6igwbPCu9MRCw9Anfe2rQ/h1261SCeAL92d7B4C9W/Sw4iPAYRQalGgIUd4kt/ITRHgi3gx7 Avb02TNs+0ewKvXSgcyKEDPNU0+/AKUuhE20tQVjvLjbGwVFuoaJahNY+4RWiTw4ZjPUKTUQ tN1Zfe+sg8BHeevT9wJvqz31nmCpFtI4/ABoi+R1wmzwP+fvrm0B9/28kek5EIj0heS3A3t1 c0tpMET2sqnmTWA/azhgLQueT/XGehhE1Q1fbJgMEQPCEsNyIe2rjO89S8E2WP7ctQZMG+VM aR+kFcsSUndAwruRfeO6QfoO39DooZD+pa/+lQFgj7TWd4wGfbz0nlmF9DVu7dY6EBbnxcon IOS45bvYoiD9ZP3RvQFsFRytQ+eB2E35IeIzMP4q3jEmgzaVJNdPcKv+3QkZZcH3qjfduRqK No5ZbC8JN/emVdFfAneCsiq9PxTJCW8p94HAHOUL8yFwt/A8FwiH7Pvu/toMiCxj/7bIOXC9 GhhIKbBFmxYYR0GJjjHbyp2AIreLflLyEIS9Hj48fgn4WwUmSw3BXctfwRcKocfCO0TEguNy dMWIjpD9VPoW51K4efpU7Pn1cMeR/WbqANCmGSNDhwLz1FeEt0DrynrfWRArmBqHmUCYqh0J RID2tK9C9gGQ7gd0VwxQ8vEs1AdTK9avX79+/frCiPCfPY+5ILf5QQrkFMh9mN5/RoEDkzQq aVTSqP9ioAcPvzuOSDgmHBOOAc1oRjMQjgvHhd/9NK710/pp/f4o5sF29bB6WD38z+0UB4oD xYG/qy8UF4oL/zhO76f30/sBVqxYf2dnAcc4xjGgM53p/Oef01+1I1A1UDVQtbAuDZQGSgNB sAt2wQ7SKGmUNOqf63vchKwIWRGyAsRR4ijxH+j/s/PzYeKHiR8mQrsv2n3R7gs4/MLhFw6/ AIf6HOpzqA9sTNyYuDERlk1dNnXZVFjFKlb9KwbXoAY1YOP0jdM3/s7hLPiH8UEKUjYG1xhc Y/A/SNn4s/NXkELxh3H/J/XlnyHVlmpLtf+5ngf5V9fVP5vXIP83haka/9iRfZx6fi//Yaka gYDX+/vNgQ/jYf3Llx86dPkyLFt25MiNG/DBBy1bVq0KnTvXrFm6NNSuXa5cUtJv1x879ke9 f9Tzf0ecH+RhqRrjx3fqVLz4w+2/cycvLz8f3O5/LPc/NuJsPuqqJzcBQ1W6S0UB9LncBq4L lYSrIPrk1+TboCJM1tcCw4RD+hFQ3/fOkC6Cr5lUM3YWiIOkhShAGe0sC0AfKrzHDeC8vkKP BD0dDxHAHpycB72rXof5YOgvHZS/A0NT4wxjFZAOORJj6kLyet8EY1G4tDhzlD4Pcqb7iglD QPpRbE0bUDYqu/w7IaRIfPGyP0CoPTqpaEfw/qB43fdB+Exsx0BQ3lIzvUsh8ExgiXc4aCe9 b6rzIKF3XIXqh6HdmtrS0xWh/meVK0TkQdiQEnUMdUFZYxzg+xhKWKJ3RsRAuaiyz4ScgGq6 NTSnBjwx0ihpLSBMiQ4pvgwkwhoXawlqI9+NnLrgis85kjIBuKTVYAqEngj9JXIUxI5J9CXl QuLdoq+XGAKhPluliFIgXDfMkMtD6P7oBREBcJgsU0xfQ+retHY5V+HM9otl0z6C3M3eEP9y sPW2t4jIBvt8m2RrC1V7Jm0tvhjK9IiIKxYFBjttfF9CsfyoQyV+hvKDwrLrvQNFL9kbFv0a bFctFks9KJ1Q4nzlFhBhC+sVeRwiJoSa4iaCPEWSIsqBp6t6zKOAMly35+4Bk2iebu4G4Wvt LxIGCR/HbQzZB6qIy1oNot6M+tnxLTx5pmyZhLMQGm77OLQfSJOFSLkF2EItyZaeYHXbehmt IDYztTUfhtjbYfFJ86FM1+IZZWUof6DCMzWbgj055PvEXyC3m2uyng85Q7wm5T5Y60TmRNYE 0/jI2ZF5kKvf7ZtbBW6dPfbSiROQeiCrz/XDoEaYq1pSQX9FijaeB03RV+mtQCghfE4R4L66 3VsPFJtvnfM+KJXUZ13XQbHynLL78S3UAge2ePHixX//RVLwB//BV2v/WQque9BxKNDz78qF bryy8crGKwvrH236aNNHm2Bf+X3l95WHCRMmTPh9Ll7TJk2bNG1SWC/IwU3dmLoxdSOsaryq 8arGcHfs3bF3xz4+O58Z8syQZ4YU1me+PPPlmS/DAmGBsECA7M7ZnbP/BYf5r1L7RO0TtU8U 1j878NmBzw7A3CNzj8w98t9nx5/lr87Pm7Y3bW/aCnOcqx+pfqT6ERhUe1DtQbXB+qb1Teub f4ywCguFhcLCwlzhghSDh3El9ErolVC4/s71d66/Uyj/wV9GCiLCKWNTxqaMhbNfn/367Nf/ +vN4ZukzS5/53SbMT/Z9su+TfbCz686uO7vCq3NfnfvqXFhxecXlFY+wefZR11WQf43C1Im/ FnFu0mTgwG+/LSwf5MH+P8r5x456IPDbsXAPnnrxIA9r3737ypXU1ML+xYsPHLhy5eHXF5QF ev84rmBz4D9OqZDl31IzHiz37r1+PSUFzp93uTyeP5b5+b+d1/zwVI3/0M2Btl8jx8YtAr2D VMdwCcTljOV9UFL8uwO9wPeEZ5W7CpheCcX+GRiLCaP1M3B2zrXczD4Q2jCpe1JrMI5mhjYM vB8KbcUFIPzMz7oP9Hc4riWDOEPoLh0GoQobhdWgn6UWZcD5mjMv5xqsnrHm7AYL+D5XzRHb odq2p9rU3wZ6EcNddoHUQ06Tz4IYrW1TSoDWTzxh6AW8TC3hcwg85b+hnwXRL7VmO7Be70om CCt4S5wMzBWT1JeBItpg2QqBHqSJb4G4MvGdqiWg8mHxA/t6KPG6acHpWZBVKjw1ZySIF/KO emwgfpL47hMeqDSm0t7ABUhcnZbmnAqnkrJ8yjo4M1e8bH8H7pQ3N0m6A9rNvJ1po8DXKbNp an/Qitq/DN0K9vdCvgxRwPSzpakpEcRP7F/Zz4AWUDr5m0La9pxooR+4innOq7ngmqG/aNgJ YoxcUr0BDNW+1KPgzmtppzO8wCb1NUMohDUPLW45A8qL0hnffii1LaRP8RdATjDMiygKeWdc Hs9i0GcIW33vgnmLNjBsJ9Baa8wAME2S24tfgfESrSLSwNDX1jfnIni+90hZFyHTmNuZL0Ad 65+YfB7KlIqJLR+A0PHSvvhXwLYubAY+UCq5TjkluD8iWXWNhrRezlSXBcwvm1XTaRCbCjvV I+BIM0+29YDQchH1QuaBfazDELYCzB/aZ1oqgi/fV1LYDc4PnIP8Akjvmt4xhUOkGrs4ZgmY O5t3GkZB/sTbvVI/hfQ1N/tdNUFek1ztVmnwYDSEfwbqUMYYXwd9ijZH/e3zN0i9APod/ZBe CbQRxOqVgQghS10Hop1o49vAs7TUq/2fRdL+8S3YgtzjgvOZc3Nzc3NzC+sF5cMiy//s1I0H 9fy7eNnzsudlD/h1v+7XYd2IdSPWjYARGSMyRmRA9K3oW9G3YGCxgcUGFoMegR6BHr/7Qh5u G24bboOZ5pnmmWb4buR3I78bCdG3o29H34Y00kh7DHb2rtK7Su8qcP+F+y/cfwG2TNwycctE KLa72O5iuyFycuTkyMmQuTVza+a/8UU3/fX+en8d7o28N/LeSNiQsiFlQwpUiqgUUSmiMEWh wFH9u/mr81PgwE5fMX3F9BUwwjbCNsIG6iH1kHqocDPmiOIjio/43T+OHdI7pHdIhx+7/djt x26FmwYftomtYFMl5znPeWj1QasPWn3wx1SRgs12n/M5nwNbJm2ZtGUSVPq20reVvuUv07dv 3759+4JzpnOmcyZs3r159+bdsPHWxlsbb0Ftf21/bX/h5sd/lUddV0H+NVT1t1dIP8yR/dfl /tfyCvQ+SCDg9/v9IEm/nZrxMApO1XiQCxfu3v39i1UerD/s+gK9f7Tnt8jvwxInbDa73WIB n09Rfj9i+/aDB5OTQdMCgdTUP173xBNJSWYzVKv25JP/KMBToPdxIxw8ePDgwYO6XqdOnTp1 6vx1AW5cDbJrApcNJ+1dQcjiQ60KaPX8X/gPgS/G3c3jA5sxfG7EIlAv62/5+sD5KVsjj/eA kpF1Rle/DtZXw48bBoF6Xs3Uk4CjqlPfBmzTV6ivgtDT8KShHFxPupt8bjkU3xxTq3RdUPoo 7fQ42JOx13mkOjh/dVnUSKCV4/ui3aFkZilfkV+g/L34dYZksHaxFmU/qOXVFuI9kDoI4zgJ Snl1s3cPiH6hu3wUhNekSuIs0N/W2kv7gDXiJ1oA9OcQhAQQ9+ui8i74azgr5HUAY4qhjboQ 1BdckzPeAG1+xsuZ34Hkipwe1hm8dzI33neAPjl9avobIO2SdVaAN1W640mDrKTrO3PSYfW1 PSXut4Djw7J/ktLBv8Q7Lms2+DPdLbIng1BNHmm5DGFvhtSJ2ASOt0M3mDeCyWF4Tb8HDFS7 +2XwVnSt934Lvmz/9sBnoCzTL2rDwB/rv+pNB99AlyXnAJidlnXWwRCRHflG2FvgveMe4+0K nmLuLOfPkFk1Kye1MajThY3O26C1F162FAVnZ//27HQIyXOsEKuAP829TfgQcuu7c109oVxa /Liin4F8QYyyVIab4Rk37x4FQ115u6UXRK0JU2PbQ+Qe83lTadD26KOULnB30J1h3m2geY2D WAeOCaGSVQDzK/I31psQkxu/waZARPPI4lGZYBhkvhZyDrQPlN2GN8GV6iyv5IM3U90QGA4W Jexc2DEIXRY+J+weiBW1nw07wBl1P+d+Z/B9kz3gTip4fMrnuZMh2+96O3AA8rbpo8K6gl5a nGc+BoEJzJCeA9995X1eg0CvQPdAawgcUFb6ToMyI9DJew5YqN7zTAWpkr7E1xOOpe77dMOp x79wCxzbgtMDChzof5XQ0NDQ0FAYNmzYsGHD/v2Oc5C/RsEvAymtU1qntIY28W3i28QX5ja/ tOelPS/tKaxvbLux7ca2f7fVQYL876By5eefnzYNqlSpWbN8+X9dzjfffPhh69aF9e7dP/jg vzpV4vTpo0cvXIAzZzZuHDmysD06unPnKVPAZCpWLD6+sD05+eOPX3mlsF6kyIgRS5c+vP1B /tk4n+/27Xv3ID39++/ffbewffDgo0dv3IBKlRISrNY/yk1Lu3/fYIATJ+7d+yv/ePj9+flZ WdC6df36oaF/7D97NiXF7YY5c2rWLFHiz8t9GIcOHTp06NBjiDhrqudHb38wfGtsajkCWhvt Y70jyGWN3xqqg7zEpJgTQQ3Rh2vfA0s86/0TwPG5Y79tFxi/sMw39AZxs1RXNIH4hHBReBa0 tryo/gBStJxheB1S87Jnp+TD9TeuLzi0BYq3iesS1wQyv3DXdg8Cp9M0wfQSFFtZZmHFouAv 4n4LN9yacf9l12BIcIf3td8E6xF7WUM26LW0wQwFjuvN9fMgThQWin4Qloid5C9AL6p/oU0B rT8/eLOAiuo6dThIi8UTlpGgHxEHGe+BPNuxLjIKNL/aLhAKegfDNHUlKAstVZ3NQW5ruRP7 PpjDIuubZwM9YxJL9wUmO9rETAbLPcksR0PE4uqzvEfgjdM13jv3Hfy6bM+FEz/Bujn7y6hf wb3XTKdDk0A5lNcpfR9kH8isfP998Oa5N1oWQ/i2sJsR9SHsdGhZuw0sLSJvWfJBf0Zfog4A fYPi9a8GfxXfONN2cA2z1DOcBtN5OVYaBJkXs7/0fg/eZ5XdgXdBPm8cHzgGOUu8fbKHgLWN eY9lItgjLets98B02NLO1xLkNYZx2hZw3ckLcc+EsGIRM8OSIL+23+g7Ajkr8jvm9AbhsDRC 3ATGLwwTDC/D5TE3G17LAdtr1kOGdhC6JayR0Q9Ro4pdLLIeIqeFRIY3hfDbYT5HJzDNMDlD dTCUs223j4OAIbBCGgau8bk/+Z6E/HW+i4HnQTJbcwxjIfxYzNVYCSw7rIccJlBeybvo3QcZ 2Xdu3xoKGWvuVrmwHgLxeuO8eaB9or8jvA/5Se6q2jfg7K7KeTUgkK0V0ZaCv5r6nT4ClG16 B/0JUPcrfdXN4K8eeDMQCfp4bas6FfSTat/AM6AGAk187z/6Qn0YBY5tgaNb4EAXOFi3bt26 devWw68vSMUo2CRYICf4RsH/TAqOndv1za5vdn0D/ehHP4DpTGd64XFtb2a+mflm5t9tbZAg /7vQtN8iw/n5WVn5+WAyWa3/6Jzjv4rf/49zhn0+t9vnK9T7IIHAb2/O0/W8PKcTRPEfb/L7 qykcDxunaR6P1wuK8o/fDOjz/WZndrbbrSgQGmqxyL/zPkuVioryeH47HzokBC5cyMwUBPiv 4+Xw9NMlSsTH/xbJdrsL23NzPR5FKdT7uHlkx1mZ7MrXfwJDvbBvxDhQl/o3qjXBN0ufH1gG xoamJsSA3FpuaEgEz6HAV75mIJ4XlmhzwLDM3NnwDtwfc//2zXWgbFd+9X8PJqSv9J7gOGob Gn4Q8p/K6ZbnA/ur5msRY8BU2rzePhCiwu2bzRHgXO0sckaDKytS2uV+CYkVImdEpYFth+Ul tT6kfJu2118GijUKL2I6BWpTwUcRUEYrJQOHQZgkthUbAUVZKISBsJ378krQbaI7exwItakh VgUiFaf6LCh3na6cp8DQ2N60SGtQKwv31EsgOx3X42qA4aw9LK4yaM8qR5zZoLbxHsyvAMZ6 5nrRP4O6w7Da9iyon2sv6xJoVvll82GwVS9/rP578HzZ8n2e7gPlJpaptuFrWND1h68O14XL W61yqZPgrehqlrEKPAPzr+XGgn9H2sa7Q8A1P2+zeTyEfunIj4qGkOSQFaaDYLtsfcX8HYS+ G/KRQ4Go81G11DTwn/WscT0LBsWWmFcOAruVvmJpUBK9mr4J5E9L5hfrCHl9ct/yamBqYnjD XA2ku+qakFRwG9w1/QvAvt/SXygF8T9GVIw+DXYMzyZMhrTpxlYpr0DILvsB20SI2heyKno3 ODsVfdvTBwyzjNfYDY6UcKutH1iumZ1hX4GxoWy2D4aAX9suPQX+ogETMZCTk/6F9wUIfK3m sBW0X41dzO3B8lXoSMu7YK8avjbieZCK+Q7igtyGN4+nbwBXu6z7yb1BOassTP8YbF3sX2rz wbdFuWJZAN6y/j3+bmAXLUnaIZDWB+a5i4LvQ6WCXhr0+nIF8kG5rfVVQ0F/yhTHh6D01U36 06Ad0zZpIgiXBIPRD4qorJAf4SfXP0uBo1vgSD94jFzBOa4FFOQyV6tWrVq1av9++4I8Hqq+ WvXVqq/CUpayFGAIQxjyqFKDBAnyOHjiiVKlIiLgzp2UlIwMiItLSIiKenwOdAEFDvP9+7/p KdD7IBUrFi8eEQGnT9+6lZkJohgaGhICYWGDBs2f/8fxD2v/Z+N03ePxeEDTcnPz8qBKleLF IyP/eF1oqNEoy7+9mtvvh4SE3xIowsIsFkmCrCxRlCQoXjw0NC8P6tZNTLTZQJIEQfwvduLd uvWb3vx8XZdlyMnxeFQVUlJyc/3+Qr2Pm0dO1bjX4OK7N7ZA5PonphQbAYF0Tye1BCiZamxg FJh6G1sajoMuKy6fDXJH7u56KATyZulfyVWhyOXnqj7TBrI9OZ579cG3XBmmjAZTtvEbsRqc feNywq8pkHtJfS3/ZShTKnp5qa6QoEauqZgLpztdcB7Pg3Pv3/VfuAQXz9w9LdWBKm9W/Kjl C1BnQqXMYqPhiWNRG4SWIJQ0dBSLgbhR36KvAH2K1ky9DXqq2EZIA7GbUNzQGIRUcY/+PKSa sq9fGgDpXbyzbpSFiGER7UJ6gfap05U9BcItJmfFDyB0jqNXuXrga6dVcF8APhBkUQZhFyly LxC/0CICw0CZof+stQFRF6sa3gAS9WgtFYSv9Hn6aVDT9QZCAlCRfVIU2L6wVJEbwarQGX0+ uQvr2h413ugDeoJtetRFcE/2Ng7UA3W9u0Tur6Bf9MzMuwairJ3yLwXre3KeNAPMu+xd7Png sDgs1tkQMsL6kvk0mKebTQYZDCPkUepzoP1KimYAf2n1Y8UL+kmtlNIdtHna6UA3CJiUp1UN PNW8r/tHg7BSThaeB2muECfWBGmasEC4BNoCrYUggMltet+4B7SNQnPtFzBVEZ8xvgSGfPNP 1idBC2eNcA60SYGGYip4K3ubaeXBuddbzB+AwKjA1kAGqPWkRcJbIMUYj9iOg3G8JdyYD9Fl QupagCK+2EG2S3AncP+NjJ8hX8mpkP4FZNdOTbjYGXLz0zz+6aAeY1PgV5DjlDZaEogmcaWp AbDaaJYjQP5QXCcVBf0d3pHeAf8EtSzvgv4J+fpYQKCRcBL0BOEXcQXwgbhFmg+6rJ3Sa4H2 lnBD3Al6hnhOngY/dvt55PfbHv/CDRIkSJAg/xlkZeXkOJ3Qu/c773z9NZw/f+VK2uPYZPEQ KlQoUyYmBhYvnjr15ZchIiIs7PdvJk1Pz811OuGFF0aPXrgQTp68cuUfnRP9uKhWrUyZ+Hj4 6aeJE/v1g+jo0NDf25Od/Vvs+IMPzpxJToa0tN8iz/8uYmKsVlmGDz+sXLlIEQgPfzwO9GNL 1ZDHOb4zroXA9Jy6+W7QX8n+NmcXCONdKS4r6KPLzivVEtTS7j7u5eAsvvncr29DmPnFt9vl g7DPkiAch4SJxleKDoDsQe4qeXY4kXFcOzADLGWNxtCXwLPPtka/BVE7rCXjG4LhHWO58Lqw I21X+J3ecG+E8MPdzuCOkNYFbsDWY7vOf38BfJ38dP0aSiU2Xl+8HlhcpvP0BHW/9rroAeGU eFeYA+JIYY/UEbRcPvQngLyAeuYz4K6d58vqD5dXX+l5vBQoh/XphvmgLzQN13wQfSoiMvki VNxe5HNfEkQnWxsn7gIs4mCDB/RvRLSGwCRhsxgCArQ0tgLhQ726WgH0dfRgA7BdWCpMBDFc uE0x0GbSSQlAQFOKaAdBqOjPzddB3JDR5Dogj9Pmqu+D3Mfc1b4BtBfCSkReAuWXkKoRV0Ht 5Rec34O/v29zfgdQogNjtJoQ2JA1Lesi5DiznpHbg6m+8UPxHTBbTDss7cFUyTDcVBrEcNM8 aQNINyRZPghSXUM5604w7pGbiO3BYA7ZSwCQeU5LAcHLBHEJCCG6pG8Aral+i7KgDNVTtT6g llMiWQT5zZUyvAK+tTl9vLHg7R2YoogQEAMllAugHmUvZ0FeY0o2zwPjUusK21QwdjA3sB6E uFH25calUKNzuZlRa6DGdzVfrjwD4j5LulxqCmx+d+usr0tC6ht5k26WhuoNavratoHVm9bc +3kI6Js9rxpKQtPvqtSqnw5X4s52yCgLx749Vu58BbizKCsiawz4nlcGK13AMta0zNwL5GOG Vw39QKuoFtHfBbWW9qVyAvSvhQHityA217uLoaBd1u9qBtCO6/vUUUC3f9+XQ5AgQYIE+fsp cFzXr58//7XX/m5rCh3XQ4c+//zNN/9uawod19mz//Emvv/XeGTH2TJfmexvBYHlN/PurQci fS08VUB7xlvE/yIYdwttSq4BQl2zXD8DW/zXA0vA9ElMZEg1MCxnmrwRMt9yr80Q4Pj648P3 zYKEmcZtcW+BK9nc3BUOYWnCCEcixG6KK1G8F5w6de3LNBHE0yGDExeAvihzTUooFC1SfniV tpBS43qfK3PhwoKr3msZcGRLUvuIBHiuS8WZ9l4QWBVY5psE8jZThOVZUA9r670pIJwS5piK An31MkI4GD6wTDTtgpgSFbQyQPLhU54rw6DUbikibiXYL7kiLW3hWurm3aviwD63dFq1NiCs EzpKSaDfZr3cHgwjim4v0xXkd6KzSzwN+na9IfOAFUJPskFfqJ9HByGZURwFsaYeLZQCQ0M9 Qf0AhK+1xWpXcH3lfDLzPsivKrs9pUHsZN7t2AByjGV/RDQY8ywXIi+BWMMyx/YjmH4OdYcL oE1x9s+KBS9KrDYXAu/r97Qc0A7pxTUdnM09az3HQXzZ5c+/DIqk7tIvAs11N2dAWCWcESeB cSFPCOdB3yn2oQ/orwqLBBcIDVksJIA+n5/E1aBPEhYSAlp//VllH+hhwntiGdBfE4rKd0FY K22XW4B00nDMcBDkkyENwm6BZZplmu1nMDuMa8wHIS7T6tZ2Qo2mxWtb7FCtVe0qVZ+BuN1l 5RoSKIuEc+ZoCJzUZ7ITGr5b391lHDiLOAON3oWIXgmvlf4coi3dF5bdA/aFjjJlZAi9FNa7 +HtQIbPmtLv9IGlr9a7nhsL37uW3NtwG/3v5Oec8kNwx9evsiqD2FKdJTjA6zJr1KBgSpSWG +SCbpYXiM0A3nGJn0Fep8doZ0AYqx/XPAChHo797mQcJEiRIkCBBHgeP7DhLG+Qj0mnQ3Y76 th9B2BSTFjsKhA5cEDKBSrJfbgK+5Xfirt8AuUvUq+FjQH4/JiL2W/CEBO7nV4e80XnJ9wZB 9a2V69ZdCNH9w6fH2+BA+vnGG0ZDeLSte8wk0NvJ1w1vwrmBx6vv2AXGmda2xRdD8Zm2L8tH Q61tZa8+ZYMLDSJ7lgSE59UvtaehakZZT6QAvtGuZ9PfA+EtT+OslqCtklVbcRCXW/vbfKA3 MuQZfwDpknmjGA0pA0/IVytBytnc9y60A9uC+A9NWRCRGtU4aSaUf7+yr+UQ8JgrVrvrBz05 q9a9IuBbcK/zjR9AT3K9l1MVVCm8vGMtGJ6NiI/OA54QhoVWA87ST5kH+vOcYzRwimRWgtZS +JEPwfeJv4PeDHz5/g04QRsg3zV0Bu/twCL3MsDgPezeDkJe7qrMX8CUb8q+bwNrS/uYMD8U 21IsMSoF2kf3rd+sCtxPv3c7+yW4veJa/N18uN0/Y7CrJ2R+5i4RmAr5J/0LhTrgztHPKSdB aK1G6iMhEKqixYP7hJqudQeeEMbp60GPFvYwD1jLh2SCGCMOFZ8CMcrwgeEHEDZIkYZvQF5n aG1sANIMOUOeCPIIg8f4PhiSxLfk5cB4OvMsGKJVayAdtGkZDe9Xh+eKP9+hVHN4+tk2tC8J 3vfE1lE3wTc/MNYbDfph8QtfMxBjpctiZ5BeNIfZFkHUKLmCJR/0MVQ1L4bEYkX3NhkHAZMy VdkK/kz/Zf9xML5v221uAYHz6uCwtvD0q9XbVfFB/JywjGKvQvJB9zb9Jdh+bsune12QMifz jbu7wGM2nJXXg0VQvjIdB9NKU03jBhAPifvEoyBHGJ6Ufzs+JxhzDhIkSJAgQf6H8Mg5zkGC BAkSJEiQIEGC/E+mIMf5kd8cGCRIkCBBggQJEiTI/waCjnOQIEGCBAkSJEiQIH+CoOMcJEiQ IEGCBAkSJMifIOg4BwkSJEiQIEGCBAnyJwg6zkGCBAkSJEiQIEGC/An+/+PoCnYLBgkSJEiQ IEGCBAkS5I/8f0cgKl0uUMVtAAAAAElFTkSuQmCC --------------090307030509070900000501-- --------------070708080106060402070906-- From nobody Wed Jul 30 06:37:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE6B1A0058 for ; Wed, 30 Jul 2014 06:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 DuV-mWPqIW0t for ; Wed, 30 Jul 2014 06:37:46 -0700 (PDT) Received: from omr-m09.mx.aol.com (omr-m09.mx.aol.com [64.12.143.82]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2AE1A004E for ; Wed, 30 Jul 2014 06:37:45 -0700 (PDT) Received: from mtaout-aan02.mx.aol.com (mtaout-aan02.mx.aol.com [172.27.19.78]) by omr-m09.mx.aol.com (Outbound Mail Relay) with ESMTP id 85981702ACBC9; Wed, 30 Jul 2014 09:37:44 -0400 (EDT) Received: from [10.181.176.18] (unknown [10.181.176.18]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aan02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 1FF69380000A4; Wed, 30 Jul 2014 09:37:44 -0400 (EDT) Message-ID: <53D8F528.5030307@aol.com> Date: Wed, 30 Jul 2014 09:37:44 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Justin Richer , Mike Jones , Phil Hunt , Thomas Broyer References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <53D841D3.6020505@mit.edu> In-Reply-To: <53D841D3.6020505@mit.edu> Content-Type: multipart/alternative; boundary="------------080904020403090301000708" x-aol-global-disposition: G X-AOL-VSS-INFO: 5600.1067/98281 X-AOL-VSS-CODE: clean DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1406727464; bh=y2FwMyIDjleO/i2TumGF6JaQ7qjMl0aXW/IH6fPP4pA=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=RztpARSzvjXwvIn6c4VSyVeDY29Fj8iRz9C11iyIytxKWHhEGly3zqauQRIwnEoKY junUK9fEBylm/B6FEPsyL0EkWk4yJ9k2fmMen3F3ZdVlq32+CYXTWdTXTDI72iK7ny MlZtgz350+rFfKQjvRq7DbUzM7Gk43FiHEqb06Jk= x-aol-sid: 3039ac1b134e53d8f5284173 X-AOL-IP: 10.181.176.18 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6ygghts7SCQWChO2pPyRZg_jH4g Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 13:37:48 -0000 This is a multi-part message in MIME format. --------------080904020403090301000708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit +100 :) On 7/29/14, 8:52 PM, Justin Richer wrote: > Reading through this thread, it appears very clear to me that the use > cases are very well established by a number of existing implementers > who want to work together to build a common standard. I see no reason > to delay the work artificially by creating a use case document when > such a vast array of understanding and interest already exists. Any > use cases and explanations of applications are welcome to be added to > the working group draft as it progresses. > > -- Justin > > > On 7/29/2014 8:16 PM, Mike Jones wrote: >> >> Did you consider standardizing the access token format within that >> deployment so all the parties that needed to could understand it, >> rather requiring an extra round trip to an introspection endpoint so >> as to be able to understand things about it? >> >> I realize that might or might not be practical in some cases, but I >> haven’t heard that alternative discussed, so I thought I’d bring it up. >> >> I also second Phil’s comment that it would be good to understand the >> use cases that this is intended to solve before embarking on a >> particular solution path. >> >> -- Mike >> >> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George >> Fletcher >> *Sent:* Tuesday, July 29, 2014 3:25 PM >> *To:* Phil Hunt; Thomas Broyer >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth >> Token Introspection" as an OAuth Working Group Item >> >> We also have a use case where the AS is provided by a partner and the >> RS is provided by AOL. Being able to have a standardized way of >> validating and getting data about the token from the AS would make >> our implementation much simpler as we can use the same mechanism for >> all Authorization Servers and not have to implement one off solutions >> for each AS. >> >> Thanks, >> George >> >> On 7/28/14, 8:11 PM, Phil Hunt wrote: >> >> Could we have some discussion on the interop cases? >> >> Is it driven by scenarios where AS and resource are separate >> domains? Or may this be only of interest to specific protocols >> like UMA? >> >> From a technique principle, the draft is important and sound. I >> am just not there yet on the reasons for an interoperable standard. >> >> Phil >> >> >> On Jul 28, 2014, at 17:00, Thomas Broyer > > wrote: >> >> Yes. This spec is of special interest to the platform we're >> building for http://www.oasis-eu.org/ >> >> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >> > > wrote: >> >> Hi all, >> >> during the IETF #90 OAuth WG meeting, there was strong >> consensus in >> adopting the "OAuth Token Introspection" >> (draft-richer-oauth-introspection-06.txt) specification as an >> OAuth WG >> work item. >> >> We would now like to verify the outcome of this call for >> adoption on the >> OAuth WG mailing list. Here is the link to the document: >> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >> >> If you did not hum at the IETF 90 OAuth WG meeting, and have >> an opinion >> as to the suitability of adopting this document as a WG work >> item, >> please send mail to the OAuth WG list indicating your opinion >> (Yes/No). >> >> The confirmation call for adoption will last until August 10, >> 2014. If >> you have issues/edits/comments on the document, please send these >> comments along to the list in your response to this Call for >> Adoption. >> >> Ciao >> Hannes & Derek >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> -- >> Thomas Broyer >> /tÉ”.ma.bÊwa.je/ >> >> _______________________________________________ >> 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 > -- George Fletcher --------------080904020403090301000708 Content-Type: multipart/related; boundary="------------000704080604070505010507" --------------000704080604070505010507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit +100 :)
On 7/29/14, 8:52 PM, Justin Richer wrote:
Reading through this thread, it appears very clear to me that the use cases are very well established by a number of existing implementers who want to work together to build a common standard. I see no reason to delay the work artificially by creating a use case document when such a vast array of understanding and interest already exists. Any use cases and explanations of applications are welcome to be added to the working group draft as it progresses.

 -- Justin


On 7/29/2014 8:16 PM, Mike Jones wrote:

Did you consider standardizing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip to an introspection endpoint so as to be able to understand things about it?

 

I realize that might or might not be practical in some cases, but I haven’t heard that alternative discussed, so I thought I’d bring it up.

 

I also second Phil’s comment that it would be good to understand the use cases that this is intended to solve before embarking on a particular solution path.

 

                                                            -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

 

We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS.

Thanks,
George

On 7/28/14, 8:11 PM, Phil Hunt wrote:

Could we have some discussion on the interop cases?

 

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

 

From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

 

Phil


On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:

Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/

 

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


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



 

--
Thomas Broyer
/tÉ”.ma.bÊwa.je/

_______________________________________________
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


--
George Fletcher
--------------000704080604070505010507 Content-Type: image/png; name="XeC" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="XeC" iVBORw0KGgoAAAANSUhEUgAAAWcAAABxEAYAAABZ0L78AAAABmJLR0TIyMjIyMhnRJJpAAAA CXBIWXMAAABIAAAASABGyWs+AACAAElEQVR42uzddYAUV77w/W9VtY67wuDu7u5uQYMEhxAk ENxCggWCk6AJJLgmEDQwuLszOAMzzDBuPa1V5/3jXnb22b25m92wN/d53v78M3R11a/Oqa7T /OrUqdPSpUuXLl26JARubm5ubm5ubm5ubr9J9+4fNWrUqFGjxp9dHDc3Nzc3Nzc3N7f/XS5f vnz58mWQ/+yCuLm5ubm5ubm5uf3fwJ04u7m5ubm5ubm5uf0O7sTZzc3Nzc3Nzc3N7XdwJ85u bm5ubm5ubm5uv4M7cXZzc3Nzc3Nzc3P7HXR/NIDVarfbbP/5QgYc6EgCKZRdUgMQY6QwyQ+0 X5zFHWFAjKWodQOI0pauqeXBVvNt0isv0K8L8Pc7CsbcoKuRM8HV0XzYfAGUzzhvPAbSt6Sz A9TFcjH9a5AO5f6c8RU4O1rTsoaA8Wzw1agfQIy1xVqSwPHxs4O3Z4FYIzdQfgHuub5RB4P2 OntVxlJQD0qjlI6g5aoPzQXB+lHmfGcs5A7LLp15AHKL5kRmD4XcJFs/NQss3o5020WwPLfm z94I9oH2KdaeoH/mvcHPBtIE7xC/NLAkZJzMzIScbzJJ6QGuTtI6uQKIqnTSVQVtpuf3AfnB diA3N/coKP6mwuZ7kDkp3SN9JXicCrkdkQlavPKj10swe3lGee8EYeKpsSLoVxg3ywdA/dJV X/sVagyq9WG5RlBDqlgs/DlopVyLXPdA2iDaEgnCXwoWF0FqjJkgELm4cAEg/R8fpMJ/TEl4 DwkZCGA840E3R1qiDITXVxMfpm6EgxtPd7i0AYRR/9w1CnpNaTKrYWNwTpKXSJGg7RGz8ATf 554rjflAXir5y3tBd9XU3XwcomecSDrYADLyWW1qO3iSkLT44lLwehs8K6cX2B8meCh34WHM m9LP14N0VdfOthmymqZMF1cga2DOWJ/x4H1T95XhDgQv808qcA2K7yqUXXoDWLvZJ+gWQWp4 UmBuKEQ1Cv1GDAXrZ2q2ZTIUPOyRG1kd/PoV+DxyBuQ2tT5N/QL8/D06Bu6Hi41jPv9lF1i/ UbumNIYBES0GzpgDjh/kbsrHUHZL8Y9DN8Pjz5+tyC4PB8dcjF42C7J8rJZr3cGrvTzS1w+S 7ydV9PGG+fcmR62a+Wc3czc3Nzc3N7f34f31OMsINCBTMuEH1EYT50FaKt4IFaTh4qbsC9j0 W8UFcD5MXZLYHIwBPvm8zoPmr32sVQWa6Eqavwb9eVn1OgOan4hRl4OwiBnOQFCuSRGiNnDO 67V/ZzB86R0f+BFok10fOS4A0aKuVhWE7NplbwxOnyS/2L2gfpz7UXpHUIc7m9k+BTE/Myl7 EjiGZR5Ouw7SBeWZOgtEgu6a3B2UtYY7hqFgqG/K1C8AT6fnNfMhMB81r/GoCoaPdRP0r0Dx dKU5PgG9UyjO4WBaZ7qoLwHKB1KYHATyJtcJVwBoFZ2VbEVB6ax+Yq8L+kQmuoLA1EvfRZsE xlQPm9cGkEY66ti7gfdQzyPmySB+Ucs5m0HQmpCuAafBc5nP4TAT6Lz0Ov0teDw8JuflEbBM tVS2aSB/qIwTd0EbIH0hhYA0n12EgUiUArEAIP4mZf4PKiCAolIoAqSa1JE2grO1eOV6Bvlm hXv71YN+lvbdmh6E+gcqJJf5DoJ+CiLACBcHX9ff+RweDnve+l5VyMqfPtDiB1yXF8mdwdCJ sdIKMDfyfhMxCpQwpZRdByFv/b62WsCmZAm9J1TtU2J7u1bglyMlFDkBmUdS9wemge9Qj2qB 5aFQ+8BuRdaAM9tRtKgEWeeyc3kK9wu/UG7rodDC8DpebaCwI8JStjzcmPzgUMZIeGtP35Ix A3T7pRGv64LXDrm68xt4UyPp4NPv4Wa5+zV/mgXaN5bW/oUgLNyjYadtoGtu7KMbBF6nzKN0 UZDkTPom4yXc/fSZ77HLkNkss8+jaHC1zk7LyYG0OwmjMgpB7ijbS1f0n9283dzc3Nzc3N6n P9zj/BdOJARIhYRNCgJxkSdiCWh1pTviS5Ar6ZcqZ0HdaYm3VgKuyN8ZZoM819BeNw+UicpQ 9RKIO3JvURO0gXI/rTRIYWK1bgwIf0049SCNcS60DAGplH6yxyBQvxSfuayglY1v8Kg6aIn2 W85tIN2VF+jWg+GM51D/qeA8aDlrSQbptKugEgcuf2cf5wRwfWpvYP8c1AiluagLhoX6lnoP MGzzMnvXBTnKNtwxA1Dst21twGuB1Eo6CdI52SoZQZ3nmmQvBfpH8iUCwLFdHqP1B/MYD7M5 BhiXnc/yM6iVtKnaDBBLbebsXiBt0oKU5eBULaas8eBZxDDAcxWgYHd9AtoJ66a0LwGDfEUf BdYhOfLb6qBf4nEoOAB8kwKK+M+CzDvptvTF8GLsq8/Tg6Di8dItQn3B9dI1SAPoJ3/CfEAT qdJiQEIWsfxHkvx/JtASBkATsVwB8Ugqy08g3RcrFAtoOWpDbTZYn1BTewXFbAVH5TdDQrfU Q0lloEaPcruLdoGwngGpoUlg09SDrjOQ8WvWPcfX8GBUaqFnP0DaV7afXpeCW1diI+93hJSV loQUb1DvZ8/PTgWfUH3RW+mgT/Hb5FwPjZYW6li+OrjKaQXlBDgz+s6ZJyaQt+m+D6kEUmmS jPHQcGulMo1/hkrzCnpXeQNZdyKPJlyA+l/Wkrr1hPtfxLx9+gYeN3pg2fEangfaNzguQsZL feDzIeA9D9U0E6oVK3u+YTXw/zQyxT8W/FsH+nt3grQlb4dmfgYp6zKNYgU8W/v448QqIBpo R8yTwFYnMyP/HHAlqD7ZCZBRihuvPwWg/p/dyN3c3Nzc3Nzej/eXOMv8RzLmRxYm4IDUlOeg ayFG0ANcwdo1pwGUVeKMuA7KzSLli+WA+rVY4LwFyklnz8wPQXym72/yBfm5liI6g6glt9H1 AamfHM9s0OJypqQroF3M7ZDUEXT79JU8csD2So0VI0Drkzwsvhm4cqwLbBnAVGmFch3kvkoT jgP5DWO974DugXRMXwa893qNVgqDo61jr9QNnIW04WoncC1Si+INhvVipzEVXH20geImaHaC pSngVdSriq432LOsq7K+Bfmac5crBTxLKr/Iz0G+Y75ijAS5oJoulQBprb2GsyFY9zpb2IoA W6TeSguwT87RW26DPlmvZh8CbnucDSoHxm6uXtlDwHnc/opnkOnK/jC1G3hWDuyf+iXoS4dp JQ+D9zzfTX4/w4Nlj+PjW0HJFYV3BJUA3Zc6L9Ee1MniE9kIch3JU/wK4o7IRQEUJLT/4xMU OAGBL4WAGaKueAVyU1lhIOTE5ky21YDLU25WutkFEkpnnI67Bzm1c95oHaHy2wofl5gMph4e DYJC4eWShF7Pe8F31oM/7NwHuqq6g7nbwTVFvzKlDxS5G9g7fxLcn/P8vs9icOxzFbK+Au/r idXvVYSIYP/WpT6HjOP25qk+UGhcwPIG38DrEW9rHpoGH65v5mreC3xS7FsNY6FMVCnPwmsg pnh86mMfeJ0Yvz82HSy3bN9ZesIL69vCRy+Da4OYr0SDf1lrSsJFEFusG8O/hFJ1SucvtwqC AoNG+JwBz191mvUxJG6Mv5aig8RtGSteRcMrOSHi2RwIig27xF3IXP08LG0tcFBvlw5DZqmM k8bOIN/x6eQ5EajOmD+7kbu5ubm5ubm9H+83cZZBPMUl3oBUlkhSQNiYLoeA/Ak9pfkgKnv1 MO8E6RJH9JNAHihbJQfIjw1tIgJBCkCvywIxG192guQSx8Q+0MblxiUvAp7pgrz9QL7kcSng K1D9s7q+HgqSRaqm1gFFDSgXPhO0HxIsLzNBa+pqpE4G5Z6nNSQWuGlSPW6ASMv9Vp0Aopz6 ubwYDFbplRYDUoSWrSWClGMv6LKAK5881LkclAZKeTkddIe1XGUqSC/FEzEXhKTM1A8HTlNL tAJzuuiktQY1ga5ySZB7mR+b7oE8X/lW5wW4rGGiNljbutqqM0FLljYpn4MtwRJsmw+GU7gy 14GyUfcZL8D8zPDU3AXS8qevtRQG3fe81DZCllXqbIwEn8Dgp1ES5Ay1tnFdhtf6ODltLhRr Xax/cEVQU+y/qqEgnkkL8QdswH/1A+sSoAEqmlQIpL18KdaAOKr1EN+B+bhpsdEEzYPrPKm5 Ho40O//L7RGw+/C5tTsOwFHuLT3dDWpcLzq81BbQNZNUXyvkH+FbKCwayuwpXKvickgumjvn 1WV4I6cG/1oTguv7v3YWBscFqaF1GfjXNo80fwyKd/a9zBSIOfl2qKs3WDytpU/fgjLL8xUI vwdx+9Iu30+FgafaftwnBNZGb9X/HAIpPW3rHw2A2rElSnYaBU8+e5F6/wHkVBAHPI9C5CCv vrrLYGuSVcXzNZTyLHqs6q9QaUUBU4m1YP7BqPPMhbfLEmukP4eXJRL33dgDB69fn7T3IIQ8 9NU5y0KDk0WCWkyHiCT/8bUtYPzVVEqqDpmv/btb1sDbCrln42r+G1psZSpTGY7MPTL3yFzY 6b/Tf6c/PGn0pNGTRqCuUlepq6DIV0W+KvIVtD/Q/kD7A9A5pXNK5xRQqivVler/hnK5/beq Vq1atWrVf367yc0nN5/cHLrM7TK3y9y/j3P8+PHjx4+Dn5+fn5/fHy/ns53Pdj7bmfe6YMGC BQsWfP/nzb+7Hm5ubm7/Lu8vcRYIZMAohZACIk48lj4FjjFXjAepj3Jerg5MlCb7BIN2Ve2c swWUHKmOUgsYKdU1jQDxQqRIM4Fm0hnWgrgjbdbOgRRmOOZZDfhE2W4qBtplx5dZPwHztGDx CcgFfEWgJ8iWcE9zKshr9C75NLDJNNNzPUjn5C3mkuD6KuNLy2IQA+1e9oYg9TfGKgkgqfZj rhBQfrVb1c1gD3fkd3qD6rRfc4wGFqlbRXnQTZZKKmaQvtRNlHqC1MeU69UbRIpor70AVwM1 1JUJ5jXqcTkXXLf0hZSFoCzUXVQfgHxUaizpQSuX29XeG9Qnjr3sAeNnuhzzRFBjnJXtIyB7 R/bw1KZgVr0G+TUA3/m+Ts8dkDM9q2P6F0DxlNCXo8A+3VjZ6A2Gl775I7fB07WvIlO/g8Kn Cu8LDgPpB+maqAJcETFyOaAskngFeKDDD7DhwAoINEwgRUh6NBCHxB0EkJ9+8gNQqug+FrPB uceZz3EXAgf6SmolaORVoWHUBrCMNqx6Fg26WtrxmJEgNc5MrpgOVfqX3VmjIvwQ9mvzn65C 6OjQ/qZqUGNE6U/qDobWX5Y9nW8uPC6cOelNEuz56OjF76uCYZxyM6kYWBurgb4z4VbCY8+A B+DXw5DquwZiPJ9Ll/fDiu7bNhscENTd0FGeCtZ+GS8Dd4NaUhGpJyHiTcC6ItGQM9ByLuoI WGRL/fPNwdTeQ5bqwI2Cj5tf2gBP6sQaYoqD3MKc4WGG+BtvbyVshPBUz2eBD6FcSsChptfA t0hQpbi+4O/M177kEtCa6komvYDcduo6ix/oQ8S+h9sgpWxKfOIFAIq9zwa74OSCkwtOws4m O5vsbJK3XO/Su/Qu/pJYP/R46PHQAx52e9jtYTe43vR60+tNYf6w+cPmDwNucIMb7/nbxO13 C5keMj1kOijDleHK8N9ez2OMxxiPMf9z5eq+oPuC7gvyXv8locUPvz/rYLm5ubn9L/L+Emf4 j55MvRB4Aek85xbwEotYA5QjTDKDCNXStDGgLXJ5544EaaJ8yGwBaabxIF+DtFgsVReASCNY BIIwyJV0lUGqau2VlQMumRa5RlBme4z07QtSa79Lvr1Ad13uKvcDsdk1U9sG0p4ilcPKgFRK V1JXCOihbnRZQKkmE18H7Eeds1M+AGd4Zr/sGHClWA67AsFa1Xrd1gdyV1i/yX0FLj9XmsgG aYW0U9cClGXyWXkhGOsZKhr7gyhj6C0NAPsEZ7JzA0hH1Xmu2qCW14orISDV0jqK+iA7pEeu RuAa4hiuSODpY7IZ7eDabt9q3wPaEVdB512Qd+lm6ReCLdb2nXoM7HoRkl0STCd80nVvwFhG f1c3GRRvp2LfDvbB6RPjn4HXVd/5ATvAespa3VQasuZkX7ClgU+md7zhNqh71FniNdAQB3VA FBYztO9BypW2SC+BE9IyKQdEBuHiHqBxm2LAOZq6hoN2RsQqJ0E+zzpjEUjt9DY90wK+xeXZ DgOoH0gNMrIhLSxDpQKo+swR99PhUPbVU4/Pg+m1SU6pA4ZH+rSwgpBePHueeRKcbp10wJoG iUtTv7q1G5Kzne1SzKB2yPlceIHpoVY9rRZoF2yDEm+CuB3cM6QClE+JHFBzPjhOWve4NkFm Z9nl7AAFj0QMrD0MHgc+3hf/I4SFBi7zbwJJA7IXpo2F5GqWsJSWYOiae8wxHaq1Ld29sQns T7ITAr3gbUxmq5juMLVBD9MAX9C10U8yfwKvnckts8pDjOHlsWOn4dcLlyZtuwRN51Tt8sEw 8Flpjw55AsfrXp1xoyZkL9Zee34H7OXr99G0Tp06derUKdj52c7Pdn4GxtrG2sbaMDN+ZvzM eGjybZNvm3wL0jnpnHQOTmeezjydCdNDp4dOD81LgM5az1rPWqEe9aj3P/Md4/Zf2Npga4Ot DcDvjd8bvzd/dmnc3Nzc3H6v9zmPs/Sft/otUgHAQyorugFm7ktzQHpFKaU/qKGOGam1gaEW U9bHIAvSdcdB60tLORyk02IoXwMe0kHlKFDY1ivrIRCns5qfgbLG09u/I0h1dVOMvUE6ShNF BS2fluO8Auoz+a3jAcibtTNsBjY6ZjsmgKiCv/N7cIbYX+XGgFRdPFCngi6/7o6hKdiu5vS0 ZENm3dSsjIVg1yxjHBqIB2qWuAO6CXK6Uh48fAx3zcng+bFhsEcx0LeUesrxoF0SN1kA9FM2 638FXYghzFQYaCt9JC8A12xXhvMD0H+iPyf/CsZGRpPSFLwmmBM874P+V6WQIQDEGnWB2gD0 +5W1sh9o2112ux7sXhaPFBvITvmmywzaQamRdhRsm7J6ph+GtDtxxR7sBTXLsc26F3K+tDx0 vABpi5QptQRtmTivXgTdT0q8shnMBsMoj+qgzJNNxuXAVhEkeYBUTsyXfgFO0ZZcYKAIlT8F lkhDpf6QWSX7QHocmM+bq+MD2QX1IskIGUMdprQL8DLtzdH4peCaJ0/O7QPpc5zFEs9BgU1+ Q/LvA9e03Iq+Ejz4MPbu9WA48vxGq02fwqsZyTueFYImZYptbPQxGCIls28nkO4aZmgNwZTh 20JvBO/qjK16FFxnqJKZANlTndOenIGXKxNaJkVCwyoVLWFXoMR5vyLBMuiOKB/cmgaRoQFX DNFgHGf3DBwJbUvUzmjhAWO9BxUavBQC34R857UGmkypUbDyAZAcXuvEWDjU99Lxg1vg55PR zb75ER4VfmV6vRYKzw2tFngUnux6/PL0aUi0Ja681Qiq3y4+pVQrKHg8YMurZ++vcW3fvn37 9u15r4cNGzZs2DBovqf5nuZ78m6ly8Pl4fJwaPSk0ZNGT2Dizok7J+6EViGtQlqFQM7pnNM5 p/8+fvz++P3x+2Hc1nFbx22Feg/rPaz3EOp51POo5wHjG49vPL4xJLRLaJfQ7r8o4H/2dL/r Ce/YsWPHjh2hZs2aNWvWhA5fdPiiwxewY8KOCTsm5K3/TkZGRkZGRt4t/Hd/H9Z7WO9hPeia 3jW9azpserDpwaYHf7/fzZs3b968Oe94NAtoFtAsAE4WO1nsZLG/j/tuf++t/v9L/LP1UK+o V9Qrvz2UpGnTpk2bNoV7hnuGe4a/P+77ZuybsW8GdC3ctXDXwnmfd7MXzV40ewELTyw8sfAE 2ErbSttK/3a5b8o35Zvy38cZcHnA5QGX4UWzF81eNPvj9f3D55ubm9v/772/Hud3Y2SzgBCQ 6mJnFzCUHqITqJ2llvIikOEpS0C9nfT86WvQXpozQ7qC7GmaI5UFrR4VKQ30Fzek/iBV1Xf0 BCRPwwGpB0iPtS+0l4BdC1B3gWgin9QVADy081JfkNpTRXkIJMqVpQxguBipGwyMVp3aMJC2 efUL2A36QX4ZoXYQH4l+6lbwnxDcJmQnmGemtszID9ph6yprR5ATpSlkAMUd8bZ9oGsjF1XW g83TFSW8IGecvb2zEXDDWcXlD64t2lhHDDgd6mW1KvBUbFWjQSnHND4A6SvlR0MjMOyntbYa sJiDiQBXD8d5fWGgNw1MGeCo5PzeMR+0+WKUoxy4bjmWWkNA+8F52eUL0gldcUNpMHY1Z/ic BduT9BJJfcHyOq1YvAdkrsyKj+gDBQvlaxY4ApRbTNZ/Aa9uZ/jFbYfcTrmt456B3xWPy77z IWiad/miP4OrG/tdISCVFfFyEUBII+gLUl0tmGVgqG7SGfwhalVYQlEvsHwjjomPIPF6zK+v BkNwQb811oJgaOTZN1mDrKC0STY/uLj48cDkXWAcYqyR+Qw8iyttPN+A+aw2Vf81BLUynan8 IYhPlLmSHgJ+8egZ8DV47FMy8h8F9YYry7gCKi+uXLrUY1AipM0Fz8PZAedLnZ8MnbyqJjbv BmVaVD1a8md4YXl9IWsopOS+Ki98we9M6K+Rk8An1OPoYwcYhpmGeKrww6PdzoOn4N7m2FqX D0NGUuYCv+2woe3BjJ0FwN/Pv5N3LyiWGdXadwRow3JqaA4wN/U4EPYcdAf11+xp8GvUlZbH K4E50U/2XQrmGroN/g3+eLMSg8VgMRhu/3D7h9s/AOUpT/m8xPAfaRfRLqJdBLQ71O5Qu0N/ /37uktwluUtgaPTQ6KHRkJiYmJiYCHVG1RlVZxQ4yjrKOsrCyayTWSez8oaAbM/ZnrM9B7y8 vLy8vGDX7l27d+2GBd0WdFvQDfRL9Uv1S6GyVlmrrOUlRgv7L+y/sD/Iu+Xd8m7oSle6/jfl n7Bzws4JOyGhWUKzhGbAj/zIj3nv/5LwS8IvCbB06dKlS5fmXUAUji0cWzgWZu6fuX/mfmAJ S1jy76v/P+ujjz766KOPfnvscMmSJUuWLAlzOs/pPKfzP473r9ZjS9EtRbcUhQKdC3Qu0Bli 98bujd2bFzdfvnz58uUDQwNDA8Nfnc8//fzTzz/9nFc+w0zDTMNMqKJWUauo8LzG8xrPa8CO qB1RO6Ig+1j2sexj8AVf8MV/Uf5p06ZNmzYNIogggrwLwDsj7oy4MwK+cHzh+MIBG9jAhvfw uf2r55ubm5vb++tx1gAJpHy4yAHxLQVoA6I6C6XtIH9IiOsSyBvkfeab4FiYWyh3MojrqskZ AHIP6alUBcQ2EjgMREpVxDSQjssvlCcgnopK4mfQmmjfab8AC0mRckCycI00oI5cW1cIpCLS ckMEaPHaQEkDqZworoWCEiBFGseAMst/vWdroLSHv/oRyJV96hjsYNZCTpoiwbzAvMG1CrxH BfZRksH42OtrrRjYGjhHWYZA+qT08slHwfI8c9LbrqC+FoWcBUBbzTZ1ODiX2Yc4vwLXF+ot 0Q8cA4VJKgvic7mo3BWUm/Ia3XIwf23cYWgLfl94tfMcB75nfFJ9JoCphbGa2RsMw30KBfwE 2npttfQW5N2iJLGgWyffxwPEKld3hw7USvbvs3OA8cpoUz3IuJugfzIQUvem1k2rDi+SXq9L XArHpt798LsWsPnU0X7LtsCy77cf/f4K/BAdPXVHBXg1IGlMYhLoD4gtum9BzRH9pM9Ba60l URRM9XRXdOXgbPDtzKt94GaVuJ6P2wDTXenKz+AZoozyWwNmb88ixs/AUEgfrlghdVr6ppRo UHYr0w1HwHOKvmG+LpA7zTLdcxiEZ5ik/FvBf7vPVH0sGL82d8o5DW2WVZ9QtS+oIdzIvQll jhTt49ceTtQ/F3L9GBw5duXjc6egzszyP/a4CmcH3C709jNY/+XGQ4fHwUv/2EkxE8AYbGzg 5Q1qGfkb+zaosrTEyFZTISXt5aIcFS7m3GxzrinUT62cU+QwBIwKdBVbAuZ+xj2O2WCpYO2Z PhCezXgxKn4qxFhTuj4KhvPXH97YcwoujXjp2jsf7JGipHoGnP2thdKvwctFiXrl1z/erCxL LEssS8BZ3lneWT5veVBQUFBQ0N+vv9iy2LLYkvcw2d/+Xbly5cqVK/PWP5x8OPlwcl7i8cEH H3zwwQewrO+yvsv6wqorq66supK3/N16B784+MXBv8qANj3c9HDTw7zX74aQfFvh2wrfVoAZ oTNCZ4Tmvb+14daGWxv+4/rXHV13dN3RsL/N/jb720CXo12Odjma9/6PD3588ONf9Qi+S8C2 eW/z3uYNQ8QQMUT8dvz3Vf9/VlxcXFxcXF6i+rd/3+3n9/pX63Fk/pH5R+bDnil7puyZ8vdx N27cuHHjRii+qPii4ov+6rjX/bHuj3XzXs9qN6vdrHbwzYBvBnwzIO8OgP6O/o7+Dhydc3TO 0Tlgs9lsf/nBrL/y7iHIXc93Pd/1HJaXWV5meZm89x/UfVD3wV/t79/1uf2j883Nzc3t/Y5x lgEXingOBJGODVDYRzqIF9oxdRmI6WKGowMYZvvMDBkIyudKG7kciMWij/gMpCQpTa4MDBT3 hA3Ec/FIdAOu0UQ+A3KQYiMQmMdGMQiwiWdaRSASoQwCqYioJ1oAD+WP1LGgdaacvBOkVfQQ I4D6GcXjNcjVnve4/xAcuembMuuBpd7rtimfgNZKF+7pDdpXpnTP85D7YXYbdQWI89oYQwGQ DbruxjhwDlOrOl4DGdJ1mxc4TxOi1AHptJ/eqy+kXMiWcnMgOzwrI3UQ2OZkr8o6Dt5fmAZ4 jAWpsrxYLgEmf2WZ7gOQu+lOK41AL6u/uqaDrYfeoS8Erh2sFDfAuMk129ESqKmUIRJEftcr uRPY7zge5U4A06f6hcYoUGK1NOMeyBmZEZ29DXasPvjiwgm4dzXt2vqa4HHKUL3IXVB6qPOj WsHNXvfLXR4PuWNtOfZvYOKB7oNmFQFDW3mM0gWU5roe2kZ4UDI+6cls0I0zlkiLB9mleWfs gntzX266eROSL9k8kxdBaEudt38M2CblTMmNBuO3XneMa8Ev22OvcxZ41FIP6reB/bzukG08 mE6F2KX+YJhtmqTGQaKn5Wh8ZciKcyW/eQXVvYqqrfaB5ybdLx7noVaHcl3vH4Vrne8est6E KpOqFzDUB0dfppQIAj9v0/4kXyi2sGzxGumw/0X0801NQDeeyJQ4yPzY8LSxEZw9rHfFWyh4 MbRe4aoQ6x1/IrcXnE14XPKGB/gGmc8Yp4P9mrVQ8gzQDqmzDNPBt4fXEUsDcJVNn+kaDakr nEbTDHBe0k3TjkNGJ/uF9LKQUyC3nLElABl/pEmZH5gfmB+AtE5aJ63L64FO75reNb0rBP8U /FPwT3nrp0SlRKVEQWyh2EKxhf4+XkrblLYpbfNe3//h/g/3fwDCCSccdu/evXv37ry/v+Xd dtYEa4I1Ad48fPPwzV8lzg3HNhzbcCzQkpa0hAZbGmxpsCXv/dchr0Neh/x2IvXOiO9HfD/i +7/v2X233d/ewm86senEphOBTWxiU16P+1KWsvS/qce/Wn8WsIAF/NPe9ywS/1P1eDfk4t3n 904tQy1Drb8ayhHYPLB5YHO46LjouOj4x3Fr3619t/ZdoC1taQtFuxXtVrQbEEAAAXlDSt5X fVtMaTGlxX9xofBb55ubm5vbO+9zOjqBDOKFFEY8SJ+Lb6XuIApI7cQ20CJoLMeB9KVWLDcB 5BEB9yP9Qe0hWqgHQDeMHSwGcZpMnMAhksVjkHYzUUoB8ZFkFDoQEdSXA4GiYoA2F6S1VOUR EMNScRCoJK9gMYiStgXZu4Ab+leehUBWlcFyH8gu/CzwSWlI0p3sedEXrJscJrECbGsMP5vH gutX+UdrQzCoirclP5gOe37q7wtybf0oaR5IfpJOewmKU2qquwyu9er3hm/AVMjnW/NKSM9v jc/oCbpSOUMy+0PYYuMN8zmwlnd9IvKB9INSSHcZtJcimDjIHWjxzKkCtm6Z9TOnQfbI7K9S noF1sccW77Zg/8DVzfUSxCCnLqcHeJwzRvi+BBElyqkDQDcXLz4H4yj7k1xAaSUvc/qDrrCt b84cCCzkUyi4JuhGvXlctimQqnVN/hrCPgw2uiaA84bxs9ej4cW2R3Vs+WHlpk0LfmgGA090 3tu5DCS2THiYtRauhyWE3oqA6O9eeM17Aj7bxYqAQpD+IKWxfQgoDZT78gKIC5YGKK3AlKKr Ye4IJc+U+Np8BTIaJv/i/BmMF4NnZMdAqdqigOoNbz5IqP1mIRgTpF/0geA91Muc7wU4VOs1 5R40XVYvo+Ee8JvpFehfCN7cStsU/AJKLMzXVrcH3uhfn7eMgCbnaiUX3AqPIh71lS9AhbHV 55b8AnLX2b/+sB5c6xYz8fV08K8UdMVnLjzVYmZfi4CWO5qu77scDte/OuBeKDSoWKSk3gaP v4wr8bAfeEw3j/M+CMpBXepjGYLb67dZGkJSV10J7+ugDRVTPENBWqveyNkHsktZxnYIbGva IWoDZ/9Ys3p3K7/U+VLnS52HBzzgAXBg1oFZB2ZBf/rT/6/Wn5s6N3VuKsxlLnOBAwcOHDhw AD7//PPPP//87+PbLtgu2C4AXehCFwiYHDA5YDJ4P/J+5P3ot8tlWmNaY1rz++sh3ZBuSP/V LB7vxjpf4AIX/v7t30pgtFXaKm3Vf7F8sDZYG/xXx2+YMkwZBvjgg8+fV/9/t/+peogqooqo AjzkIX91oaTT6XS6P/C/ybuhGX/xbtaXpjSl6f9cfd0Js5ub2z/yPqejkxCAv0glAPgZmRjg joiU2oIUwNdaMZBbmCsEfg9in1wo5wSwRJTnF0CvzSQceMxkDoMYhZ+QgBaEyUtB+l6bpx0B cVoYtSFAB2Ws3AdEgmgjxYO0mNPaYBCfKPmNL0BMzI3PuA5av5xesfVA+sF7qPdLyH16/eHN YBC7vSv69AVHkrpLfxByz6S2zMwFyS71yWkKjuVCseyGDF1G9eS9oFstfy9NAt0j5abBEyR/ eaHuS/CY7f3Sbysos3Jb+MlgWp0TmTUAAr8zFzcOA1eIrrl+CyhBckflCNDHOdnZAwzD5Chp NgQeMdz2LQGuCM8zxl6Qe8bxvf+vkLrWVlp/E5K+cc61RoKtWEq/7GOgfeOy2+uBKVG6YroE hvXSebELPO7IZZVyYGzidNkjQV32oPe1QeBtLzmj+Gnw2RY+zfkRJC3MnGv3BMfpzN45EZDd NEFf5AqU7p6/brNBEPqdd9l8m+HAmuh10Z0g+Zr0tfU7eBGfMOPiPAi45TPYuAIKfhVQ39sC L13aGykKHBaXxk4oRvC5yqfg4uqYxRd9IO5F2oPcBRC2SF/X72sIGRGxzvwpGBfJ9et+A4xX 1ifWhrgJmdWfNIYCfh7RkVOg3KwwY80LELfpTc34q3B7csbyV1XhxeiE2skboMDUQuFBXaD4 D/lPB10H/2L+st8W8K8SsCH3ExAt5a66JCjYpdSPBftByieWT+VE6PC6davyc+HIxAMFlCdg TDTNsg6Huv5VBxZbDx5XlG3On6B0+ZKXgruCXbJfMATCCXG5xcu5YF8ttzb3Av3Xxt7SE9CV cozLHgShL30aBkjwOspWIf46FFzhc873P4YmtHgfzat7dPfo7tEwk5nMBNZWXVt1bVXw3+m/ 038ntJ3RdkbbGXkJyEXnRedFJyzdv3T/0v2/Hbdg54KdC3YGJCQk6JS/U/5O+WF4l+FdhnfJ W+/xuMfjHo+Dly9fvnz5EgrMKzCvwDww9zL3MveC8ITwhPCEvIewTi0+tfjU4r90OHNq0alF pxYBrWlNa4hsH9k+sj2YZphmmGaALcOWYcv4/cfDY5PHJo9NEBwXHBccB8lRyVHJUXCi+4nu J7pDu4R2Ce0S4PCRw0cOHwG60Y1u77/+/1v8u+rx7g4Hu9jFLjDfN98334ewiLCIsIi8IRDv Zn1p2bJly5Yt8+58dOjYoWOHjnnxTvQ40eNEj/+99XVzc3P7R97vUA0ACRUJcEoh6IG9QqIg yDa+07UGMUQa4VEPlG2GJcoaEI+Fl/olqH3IVu+D9ERare0AuabYrXwKbBNpUiaIksoOrRbI o0V112zQFqq9ZBvITeXPJD1o58VE3QZQZmjrnWfBWV80U/0gx/dajcufgagt5jlPgjI1Ykyw F2QViL2VWhaSryblpF8Gta/ruf1XyJmYEp08FZ6PTt6f9RayDurWGDqCctDY0LMABL2QPzbG Qr4gcxGP7qAra5ayZoF8Whf/uh34ZvpNlIPANkEMda0HqYF+onctMFQwrvHaC/bHWk+6gtpS bmDcAoaOxlPGaSBf1Bv0JpBCdSbHSjDE+TwylAVTQ+mzwImQkKUut3QFrYpdSl8InlcMVUUq mGuISlI1ML+Vl6h9QflEnqffCVKNe0ViLkDAIb/SziHg82HUo7gLEBuX8ODNp5A9z1g37Qso V6jUoY61wHea1b/oA7jrHT/k4UpIyszocG0CGHyD1cR9IJ+WPnPsA/9a3se9/cDxyLpZegG+ gww7fVMhO8UxXzggKNN8ylAEwod77o1UIfFJrCH/OjBUCVpt3QyZ8+PPPv0ZogYHBwbFQM+e TV/0bAlHn15btK0IvJycterJeUi8aC+VsQTu98+KvfwjZGdnrTTug4BKPt/mVoPTn5yYEtcH Mn+stNuVCh19m3UL10PQxsAH3p/D6QEXf3z4Elo8aiyV84EXs593fNsZUhamXcqaCroyhjBt J/h19y/tkwoeJwKXKJ6Q9iwx3eoP1+3XJt1pBC++y2z7VID/SP2J4E/Acti55ZkCXod1SbbJ 4Ggo5igy5OxxdMmoBN75tA7BH0D2JWWgiAAqvp9m1ebnNj+3+Rku/3L5l8u/wKEOhzoc6gCz Z8+ePXs2zPeY7zHfA2QP2UP2AMcKxwrHiryHzP7SE/s3PYXtD7Y/2P4gbI7eHL05Gr7Xf6// Xg9PPJ94PvHM60l8N40d17nOddhQY0ONDTWAXvSiF/Qt3bd039LwVZGvinxVBGZFzoqcFQn7 b++/vf923sOB7/S19bX1tf1zx+D/8J89kl3Wd1nfZT2sXr169erVMLvT7E6zO8HW4luLby0O LwJeBLz4bx6ifF/1/7O9r3q8m+bQfsF+wX4Bvpz95ewvZ8PYuLFxY+Mg3418N/LdgD4T+kzo MwEWJi5MXJiYd0djf/j+8P3h8Lz089LPS+fFeTfG/l38P72+b3iDexpANze3f8H7TZz/Yzo6 JybAhKd4CcBeLQHYIQ2jJlBW1NY0EJ5SjJQMorS0XpcDNJPCRU+Q9onFXAD2yrHyVFB/zhr8 ZArY27/Yf8sT5AkB/oU+An2m6alBBddtq872Iei+DytbsgNosv5y4EnQdaCuUgkcEW+X5DaE tMepQ1+dBFz5n4V+C3H74xKTuoH9O/tV7SCIseK4Kwhs31pXYAKfSp7V/GZAwXaFqhVJgcBY v8uRKeDZwfi1jwmkWF0WzcF5TTudewas3tYTGQK4aQnNjoTsbWnRiYBR79PTGAPGONNRuQ3o HumKys1BuiVP0v0I0jEKSy1AaiFOSVVA10fdokYDUdrl3DHg+dJzgDwVPAN8kn08wXU25wTX wTBBhDmagH6RGmM7Buan9kPqQ9BP82gfcBxQlIXph0G78qxf6g1Iye/MJzcGfaKhjWd3UJZZ Wri2QFxf0/rz5YDggMu568Bjl6VysW3g1dj3U68IKNrQdLz+KWjsU/Vm1Xnwulxuo0dbYEu5 E8U3bgY/Dy9H8HmwVUzeIX0HdxrbnV5fg2c+7Ub1kVCrZZ2UR8mQlC8xOrMn5AzIHuvKhue7 s/UXokFt5og2RkDdraVeNOoH4cvj7fnqgY/RJy7oQ0g1JVnjB4LXhdITIz0gq3HOsNjiYOpn umF5Aq5F9tjUPbD9233Vjn8E+Qz584d7Q7G2EX4FF4Frkf1ndSSUVUvPixgDz0u9PPr2LHgu 9f7KUAyMBcwtvMNBv8HVTnSDTCG9ctQDw2O/oqVHQWu5xLh6myC7S0bduIrwanqyav0GXspZ a3O8QfZkoH4amOw5Je0/gOTr1T87C8weZJnC3mPb+s9EcdbgWYNnDYZKsZViK8XC7sm7J++e DM+bPW/2vBkYTUaT0QQt9rTY02IPjBkwZsCYATA2ZmzM2Ji/DxsWFhYWFgZrVq9ZvWY1LCuz rMyyMnDp20vfXvoWpOvSdek6VK5YuWLlijBcGi4Nl6Bkbsnckrl5cboW6lqoayFQP1M/Uz+D ra+2vtr6Cq4fvH7w+sG8/fR+1vtZ72fQ5UiXI12OkDem5F/Uv3z/8v3LQ07vnN45vfOmR0u8 nng98TpM9ZzqOdUTZrWf1X5W+39f/f9s76seQxjCEGD9pvWb1m+CS5cuXbp0CXLv5N7JvQMs YhGLoPvx7se7Hwf5hfxCfgHbtm/bvm07XF9zfc31NeBX2a+yX2XoO7PvzL4zYfiw4cOGDwOa 05zmf359/3Y6Qjc3N7ffS/qPL0YhatSoUaNGjX8+gNVqt9ts/GVWDTwAF3AbCxKIpXhIZ0A+ z4/SB0BnZrnCQVupbrangRQrN5VbgFRQ9jR2B25q/ko90L7THRBNQV2RfO/2ScgdfnrIodcg 4nXhvj3BUCr8VUgGiKJZD1PmgzzAd713fTBOr9yqsxco9aSPde0hM/bM9MvNIbn3qyGxy+Gp X5zuSRJkzkt/peUHx0/qd1oiKDY10PYYDD/KBkN9CGsUsDlgDoSPiFoQ+TmwQ/lMlwvaz/JI aSS4WpDjCAcq2QOd40HurG+k7wF+R6IuFygC8Ueenn65EqTL8jR5MIhb8jTREmzl7TdtS0FE uSzqMpA6iK5yTcCombSZoG6y/2L9CbR56tc8A/sTeSYWePsyd3zmALDeylyY+iX4hhqeSiXA PNHehW1gGqOVNhQBvc33oa8AQULP7BAwWdXl6mA4Pqp0o9fpELNS3vWgIvj0t5fzGg8Z+8SJ DA3SP1b3qKeh0FSvhBpnoYRnqFI+GuSx+im5v4K1uj1NvwkC2pk+Ej3g2k/Pw66tgqh473HV FkJq2tuRr2+A/rGnM18hSNqe6X2nABQqGNrY1RcMn8svAr4E7ogTrlhI3ZT+Jm0UjKrSb9TK AqBfJzfyTIBYrzfrHq6C6Bq3e+xeCPozjs3GNFDLOtabesDzV29rpAkILxLorV0GKd30hZcZ fD/UfVfkAmjf2ForvaB684oFag6CIC//Tzx7QPilfPf9msEx6+krj76HjL4ppV/dgHr+dU+V +wrsfo6C8jFQ/HTrpeVQal/ROfk7wd7cI7sutoSdEScK7oqG0O+C/OzDIG1uRrXcBxBeQ3/J Eg3SGO2ckEBERPqkZkL+S5G9vEvAJKXXd8e/+bOb+f973vWor6mypsqaKnnL3z0cWOpsqbOl zsKNoTeG3hgKQ64PuT7ket5QlvPnzp87fw70G/Qb9Bv+7Nq4ubm5uf1vd/ny5cuXL7/PHmcF gQAyJA9kkOqK60ggfcl1NoLWEYfwBvkeW+WOIIZr4a4uoJSRxnlkgrZNNFXKA4NYrD4Bqavm K6aBVN1xkhvAKq+BBX4AsS8rKWM1WDe//CRhJGjTHe1yVoPUL7ljRiroUvOb31wAaXz+16XO gmf+KvtKLgHb4dTgxNEQ9KHPvMg64Bxu0Cx7QWtlE85k8FvlWTX/T2C+rySqQWAyilLCBbnL rC+yJoHOUz/W+BL0W1Sbugq8M5SeoiSYPg6KC34Opv35Lxb6BpRi/pM96oIol7HFcgGyPrQe zb0L1gr2TTYH6L6VdulOg5pPGi0ygVaSXZoA8gK5lWIB0VYboZsI4qA0SP0KDIuVTKUlBHxp muCTDjkb7BOy+oAu3PldtgnUdbZ+DgW0auYlPp+CwBGTvQAUk/cMwwZAznktxoM2JrOsZx3w n+hXyzMOKmWU+SQqBl5Of/p1saaQODi1RKAvKB5qfWkDJO60dc7sCaaXXjYpFNgnTyu8Hp5l xPeyXocCzeXbtXuBVjd7u+4siJWuqKA9oJ6znchKhLAc/+YVO4I1IDsjswM4akuB5IJ6gN45 2yD3W+domwVOJF6bemYymJ+Yj4TOh6tNHu/8uSaUH19gVYQDjOHWAX5RcL3HncTMLtDgUAXR 6BkkN8qu+DQ/ZByyrr5dCLxueJ8NGgPFq5QKrNUMiuUUXxr2M7y48ux+fGcwDc24bfwacu7F n469BSWul10XmQ7OebapshnyfRt5K8gOt6veUp6WB/0BV0/hCaZHSsGUA+D1hee++BegP2Iu r0yC/Fcd0Q4b2HZ67sABxgG6eGd/cA5XLplnQ/xsx0XHM2Dmn93U/99k2GDYYNgAVwZdGXRl UN4PV2wavmn4puEQGhEaEfpXY3DfPYTYdELTCU0ngD5Vn6pP/bNr4ebm5ub2f5s/3uOca7fb nICGhgvQMKCAFEEqTqAqsVwDMQ5fKoLkxCrbQbuijbK3A/FKmqE/Bco8KZ5CIBVhhTYRRHER JBlAjHBsyP4GrK2vPTrxCKzXH3d4+BZctazFcseAoYJv32AZDNOKDy37Lbhm2b/OXAI+U6s9 aF4D5BJyD0Mu2B+/6vn8LeSMvTXjRjO4dDjNmLsD3mopBdIKQ/4kr5X+zUG3z9HNng2mkdJb pSMYz5mK6SuBMYZ412AIjsr3PKo/BLystrbqeZDlcDXoAUgufW+tJtieXV99fzvknHl5PuEL SC2YMzhnP1iT7I8cZUFbyAwtBxxvHTcct0FUk9aLGKCc6KVVA75yJWqLQQtzPtU8QQzWBSnX gInGksYUsJ6znsyaCxk7En3jp0J29q06d2QIfBg0JuQQeDYPPBy2ALRs370hB8F6QqtvXAYP f/F02duBZYHhgastGJaIe2p30J5bV8tmyDpo/0b1A0vrjJ+1/uDK55qRswXUdGuMcxfYJjnX 2JqALlfvUlaCdtdZ394TXBfUh3IYGKrpY43DgIpKR+EPxsOmMd6HwPOBoZfcA3QfmhaIueAo JR6avEG16TppIaCE6RbKKRC4xfeU8wx4Of0OeS6CCutLzGoyDpQ3rmQtHzyKedLvyVUITA0I NTeC+Fbxtx49h3r5GoTU+BVcr62fBu+F4N2hdc0PwTvWs6tPKchNsw+iKLy5+lLJvApatNX1 6iyUzagyu0IGPLoTs+R1B3jp+6ZarBGSP03yeVYI4val7o8bDYrFJztNA0+TaW7WAZDHpPdx 9QX7Zo8AV38IqOY/zv9LSF3g6pM9BawT5d5ydcgJy1iQkQjfRU/cfCHtz27m/+9Km5c2L20e LDm75OySs3Ch7IWyF8pCVs+snlk98+a7bta0WdNmTWF49eHVh1cH8ybzJvOmP7v0bm5ubm7/ t3jX4/zHE2eHPdf2HKTiUrhUCsQD8VbEAQkkS9UAlTTSQOpMkCgMVGG5cgzEj2KYqzwwRZ4h PQJpoIgUk8C1lEW6AyA30T/X3wJ1eszb4/vhxc6tk7dEQdqvOZ+YtoD5gednPqPAv5dXlMEK ZhHwq7QOPB5WPV3fA8xeZTrXKAxyJHHKDVBX2kxZ98C16nrSze/hqfZkws0+kDtNyxC/gvcP 0vyQW6CeY5khBbynee/xLQIeUcb8Hv3AXMXzhUcsmJ2VE4qNA34IdvjmB7HbVtZ2GXTfWuZl zobcoIfHX+kgZe/LiokxkO1l/cRaCZzdpbaaAsLCcLEAHI8dKxzfgWOwy2j9GuTpBItiwDnt Ij8BkVqUUgG0fVIfRQNSDa+VzaBWEQNJAttF2weW4ZA5+O3j3O2QcTujq+0ZKNtDlwdMATHD JDx/gAynY4+1F6S9cWWld4fUnCSRXhIsuowpmevA9tJSO/Mx2I87NrrSQb+F2/J50Mu6FoZN IJ/X99drYAox6gwvQdos25XaoDj0RfUzQG4s95MrgzxZHidOg5ghSsqRoDVRMygHzs+0r7UC oNWmueoN4p62QzhAHidP1ncFZYqxmOklGIuZHkm1wTDaxxi8AfRNfT38Y8DvecCNgCjQFTKX NC4B5/PkuBftIKOW9ePHoVDEI1KnvwXqDsc9j5rQcFaD/P0bgHmcrquzLTjvyzoxGeRWjkLe RyG3/NsKjxpD7mvpU7kZsFe7Ju0C1SQ6GzvDw1LP21+0gdhi9Xy6C7J65YyVPwB9X9Mm1zCw FjTfip0PjHF8IS0Fq9lZSxkPpl/9Wuhi4PXDtDrphSG1QVIPLsN+x9JW52r+2c3dzc3Nzc3N 7Y94f0M1cqUAaTqIKmKFOAySp1QUA9BT3OFTIJWxdAFRVsoWCkh1hEXUBsKUNdJA4Jg2UFoH IkEU1L4B+XvlubQfdJ9nrY1tAA8PbtNtvwZXP3m+XXSHQo/L1alkglKJ9QZXvgDOgNiNjy+A 7rznRvkK6LuEp0duAjlcP8/rc9Ccrhv2JaB8YqjqORdyh9st+ulQ6HpY06iWYD2kjcpJhYTd b6yOaiAHmw+aN4Bhsz5V6QmGIr5tzXOAgYbOcgK4amT/nHkR9F/57DA+AczpJzOyIWfXo1cv SkPurIQVORo4e6pnRAIIT8mH6aAdVUeKK6BdoKkWDtJRuZLcGuTmrgDtM1BDRaijJEhh0mH5 CMjd5YlyMsjdRLJaCdBrXzAVHPl0s3yPQO4oz1+97kPukKiNzpKQWt23dO4YyKmVvTBtC6R/ Hzcu5gCk70h4kWiAnKc5LW0hIMfKt7Xt4JXgNcY7HAJv+N30/xJM2d5nvQ6CcY9HqGkp6FaZ 8uu3g06RN8rfgrZexHITxBVhFXtByk9rMRV0JaXPpQMgXVCipTuAUZqlnwlKhLyISJBviWVS U9DCtF7KPdBaic9crUAday+k2SFnjz3TegdszayyWglyr78NSmwFYmjqxaRWkF3wbVU/J5g+ 8arlFwLeHxsrOVLAf5XHLP/mcLvj01N2AbXVKIsUDk9/uLPkwiuwOOReHssh3/LQzZ5RUGtL jZMNi8B1v8eTYtaD9YTRqm2EIoWK5QZ9C8aN8iQvC+hS1cQyfcCvjO+GqjXB42xAl8A5cLLU 5Wtb1oGanPllQhcIvOHxpTQCPArILyt/DXd+fHvkcmEIbBrymakVqJtFGfu72Sti/+zm7ubm 5ubm5vY+/PHEeaD4jk1AXemeZAFiaEZz4CHdxcfAD5yR14PIzxJlAEh1tFcuHVBKdFHKAfOl LH4GLZNGlAT9D/r8ujjI+eqex9VYSG12Lzu5EhR4XCmnTiKUGdeifYV54Ls5NL9vA3BW939R dBWI7dqz3KHgapPdK6sBGC+FbZW8QGoiKstZoDVzzLOfAVHR6U8yZB9zPAraB7atWVecVcHZ M7Nj3Deg7bONcM0HS0n1K+ljMAQrDeTdYPyotCPKCyRftrsugqv3y/OvreA4nXQifR5oO7LM rg/AVUu+Jl8B1wTnYa08iHTXUZaDNB6TGAa6hvI+uSs4v9ZStHbAakmVOwMztXusAFFDFNca g+ilbnWNBx7ox3nOhKwG0jyPjyEp21lWs0CqsDbL+gRSF7/ZFVcWkg697vZqP6SJt58ntAft gvqDqyN4XvbfHLAIojyLFinoAg+zn+J1E/TfGk4pR8B1wjVes4Kjp+1rqw5yUzO/z+wAYmz6 SHEF5J1immQEbTsdxG5gjBwr+YAun7JQtxMMyYqPUhiUkkq2ooHOrPjKP4JWQt4nLwK5rZLE LdDl6LZKRjBU0y3UbQQ2m0vpfcAzw2uIVw5oxZR0uSo4M1zLRTWwZ1jruSpD7sWcD3NKgq1K yoGslpCyUJlriAbzWq8t5lQoPqZMw9rhYHzhF+B9GModK3YwvDYEx4ZFh3QH007TDcNAMHY1 DBUzoWJg01X1vMH0pbmZ7hAQyCrqgNKPcHkHGDp4GAMagu2taKl+CL5VzN8bZ0DZzJKde4+F p34vsp6HQW4bh/71cfAKC9R514GCTbxjnyyArKKeuZnXISwiXz2vsoA7bXZzc3Nzc/t/xnvo cWa8mgJ8KA7Lm4FZFJUSALu0mu6g7RFjVB3oVvFW1wgcb6VptASpvTgjgkDuovSWx4KupWuK vBa4/R9hXTWT01NqQuEedTrU+Ayihg8r/nEoSM+8yhvskFvqRf0HZUANs/XK2A3yc/mlKz+Y thfcUW4SaF1c62x+wCb9TWkGaC1e78yYCq4G9n2qCzJ+yp6V3QEyD76dkbIXXNutAbauENzb t5L/dAjaEdDcKwyUH5R8RIB67M3i1FQQ0wq9DFkFynajTecDnKWgLhpEISmfKwqURkyWjKAc 0ebSCySj9EKaAtJR0YkIEJW1WFd9UM5Ls4QBlLXSVPkn0MpIl5SPQWwx7PS4Dfb++i+8FEgZ r45QasLbFbnbLD6QWDf+1YszkLL68duHxyDlRvKDpBOgtDFONuaC/8qIIuFfgefq4DZBrUBO 0MdgBmcny3VbIGQ9S36aGgmObo7BWjlQ6skV9Zlg+sxsM7wFjwDPHV5DwWOGZ3XPjWAc76GY GoOhh3GFMQN0O/UL9KdAJyuV9QkgjVYO4g2iulBFLkjDhUHrCtoldbh2F7Tl2nGXAtoi11VH PxArHJVcQ0Ar4DKoDwC98xdHP9CluD6UrGBA/kz3HLxve5kNs8C1y/uuMRGcLZ02LQ5yRlvC nE3BsjN3e+44ePrLhQ9PVgR7bsSR8CtQ3BU6rG5DCNflnxr4OWgbRYDTCdo110dmJ3j19KxJ NOT0y/G1hoB8Tv5EvgQZ69N6WT4F0wDTUJMDIlcEzPHOAfWca5C2ECp+UO7rEmtBd9e0pkAp uNz3Tvizo2DLVBY5pkDpkOLbim2BGwdjMvd/BzlHHMsfLQf+F/26nJubm5ubm9sf84cTZ11X /Uemj0At5izkbA4Mk76kHrCA9dJckJMZLW8HR3NXS4cRHC+T57/9CAxhxiSTE+SNAQEBd8G1 2eHtqATyM50q1QTDmpI1ik+E4B5RdjUb1M+87F69gclZdxLegmKVuzq/BvWRdVVWV1DCii+r eR3kA6bpvqOA2moBdRKIYLWMvRPk9nlRO7Ew2JZnfWbLB65WtiRtCnBNOu2XDa4TUhlVhjev 4g8lxoIrwJ5gMUJY4cjiBYaCnOTq5VwK+rJMFLtBlItMCv4A9JEhC73Pgthqi7NNB/yyb9m3 ghisnySugu6ReoHF4GrsOKgOACFLD6kHYgCLqQa6Q7o5xi5gsxtXee+EzKWG4+YJkKzZLjoS IfGDN51fToLECvfX3fGGJN/XjldTgFummh6hENi6sHeRqWAuE1jCrxk4SjpLOsdA9rikh6mD QK1mq6Qmg6mJeYjhCvh+E+jr9x34bQhpEHQF/EYG/OzfB3ynek/z6gPmJZ6FTF1AN0P/QtcE lINSMWUciB8ZJJaB1lcMYCnIH4ogKRFEf/bTEhgpOolNoF5Rp2ofAnvoKJoBp7TDwgKuH7Xr 2m5wNVF3qo1B89RuqIdBJDiHO6+Cs511UG4wqJ3sxaz3wPWjetwxCVwp6iIxFQyddQ+kymBa 5LvN2Bt8KvoIkwS539vzuYbC2wGpg5ID4cehm1v81Af8LwR8HLQDQhYEtw8qBZVjKwwo8SuU LV1mX8EFkDk6da90HxwDpfuua/D2VsLJ1KVgmGUI0v8K5T2r+hfJD9Jm3Xi5LShW7bpzHZRY XMTXcATuPL/b3vEJPHl958CdKPA5U35GmaNQTy2zpc8ROPXo0vi9pQH44M9u5G5ubm5ubm7v xx9OnM/UuzDy0iioVa7q/aq1Qb4mbRMJIFaLJO0WEC0Nl1NALi/9pJQFj9UBScHXIKlyQtfk FPAtaFpqvwSGi4ZS0hegrVc92QKGzqGpRUaBeiWrV/Z6ENUcOvtPIC2QXkmHgCy5szEO9MOK NK72NeiXBYnIG0C0/WbuXRBjdZ7650C/3PFaFig37LOEBnKq8sS4Gzy3eyYZboKXp3eDwEbg zBLj8/8IFo/EpXFlIO67pxfubAPrjrTUlDoQ9lNUUMG3YLxpbZ8TBcqG1LA0A+gifVr7PgCt t/OJ6xbILeSKUhMwfCAayVFgX6AJbRfoaigHlAXgaqDV0fqBWgeDbhu44v2O+Q2FVKczUpMg blbykMRvIGHtY/2dCfD66sOQB2vButY1UysAvhujiudrDcbdgeN9fganl3OzOgdSGsfNfjMN 5CfqNcIhuF5QvcDCEJpW6mQ+F4Q2iFwdOgd8f/T39PUFj1PmCaYMMJTWr1Y8QW+QzktBoEhC RxcQV9WmoiJYH7tmqt+B9lj7UmsM0nP5kWwA7ZrrlToRXAM1qzYMtHLigGgOSmPRgnwgDZEa SmVAeSivFr1BqYyQkkG5yDqlOkjI2TKgK6sXhlfgmGxaYT4Mrj5qdVcIiA0ui8MK9tqOabaB 4CpnLWmtAY4h9kXOoaBMUCUtEwwhpkryTfAYb8rx+wCs96ydHSUhrV9m8bT2kFw0yze9HGTP zLGmL4K0q8mV3mZD/Vv1L9W/AYaffJ/6FYCgLkE7/TLBVUMdoc4CXX69Q3GA2sIVL2LBpbiK yz9DKsnGnG8hZ0TGpYQzkOlInPbsW7jwNGd3bG8oMa54ZCk71N5cpmfjzX9283Zzc3Nzc3N7 n/5w4pzdOj3KXhN0o5QsqTi4mqkVND+Qe0qjOQBiPA4xC6Sucj3pKiiNPSWPSDAFBE7ynQTO Lo5bzljwbOo9zi8bXC/Uceo6EOvNN4IGgy7TFO5vAlexrLepLUD/lam0+Soo1cOHlJoP0nPq KcsAHKNzK4H4XOmvvAJRVqqJL4hW2lNtHIi98lxRAQjmM200yCOl0a4O4DVMLms9Ac7RWoRz Lxh3+CfoCoMrxhIe8S281Sekv2wPzuPW5JgaEPxF+JHAKeDV1O9OxGjQ8lt72z8GMVtqpzwA 52bXSudlEKu0VcIC0h1phDgMcn9nV8evIDXQzdEXBnspz1FBIRAban9ki4XYb1+OftwPXmXd fHJjHyQ2f8Or6aDE+ff0bQq+n0WWiYgFpbboKa2H9BJvSiQ5QDdKsysLIXJl5Nzw8lAgrviR Qp9B8NZ8SeGrwbeAb7bXCTBd0R8y7AZ+ZL3SCNRWqqq+AnmOVk9o4JrESGqAfaa6Uc0H2lgR ggFoLPnL34HBotPJ+UA3WOpJLmiB0tfaSHCddW1QuoBtlHpfLQnOTGaKo+Dqon6t9gdnJ80o ToGyVf5KigK9UzosbQO1lPaEQ2CX1GTXDyDKUo0RIEWIHVJlUC7qNpm+BdFH+sRoBuUj/ROP BNDnui7Yx4N+lbWO9T644u3p9nugq6s+dLYGfQdzSSUTDJ+bjvl4QPbW3GT7EHjTOmFPUiTY xtmnOrsBL40NTJ3Bf7HXV15lIDszY0dON7DWtYzJ+QnsCY66Dk/IHWzzd6RB7ivr1tyK8Cb5 7f70tmBZa2mffAh8x/rOVmaAtbg9XG0Bdz98WPneSkjem9LoTSGoR33q/oH29e4HPHJycnJy cqD+lvpb6m/5+/UyCmcUzigMv7T/pf0v7aG3pbeltwXWVVtXbV01GDJkyJAhQ97/F8jatWvX rl37r8f/o9u7ubm5ubn9T/rDifP1n55rd55CVPzDVpFroHLJ8iOLT4acErbJdh9QGrJJzAI2 EC8Og2uO0+K8AX4dfZZ57wb2iFPSV+DIcjZyfQHSSEnhBEjNlXNKBRCBLNM9Ad0Wn0STEfCl saQH7bDaV7WA/BGlHc2AIVJv/UegPRDz1DMgHyJGewNie26B1NZg35aekfwS7K+sZ9LTgKYu V2o7eLT2daln8ZBaK7FHfHvINzvki5Ca4L/Vf06kCple5teexSHdz9VXegCuTm8api8G7yGW wdlW8K8Y5Bt+Aoy7zDV8zaDVVItpa0EKFqGSFaSnjs7acJAX6my+LcAS7dvC+wE8npPVMC0S XmTeO3Z/HTwffWPX1VzITrY9s5QBj9jILflzwdDBr7/nNbBuzryS/Qy0Yjk17d9BuC2ifsQ3 UKRXmTJF4yF//gKv8o8B7xO+Q3yOg9xCOSJPBOkLaRK7QUSqp7WnIDpq/VwFQezmC9qAq5rY I4aDKMMrZoP0RtbLp0B007y14aD9pA3UjOAqxy9cAt1B6RXzQF9bKS21BLFfjHIdBFHacVo0 AWeoOla9AK5McddVCMQz7QbxID1RJ3MAGEy41BXEKyHhDWKMyBLlQbwVTUUBELligrgCYps2 VesD0hyc9APXVfFW8gHRT1lhjAC5rEd5QyLoIwxP7aNAvuf41dYTdHrHJnt1UAIcOxxfg36v uYPBG3If6kboa0G6Nev7bCccbHxYd6oK6D7XnzFvAP0p5aoyEnLHZZ3JeAvpc9NuphQFtaYU 77wNmo9WzpUMritinW4JGK4Y9kiVwRWieXgGgJ/Ov5SXCaQdNFfrQtKltO8yJwI1Kcuqf719 FV1YdGHRhfDTtJ+m/TQN6lasW7FuRZBvybfkW3nrvfvJ7cLzC88vPB8kk2SSTDDwysArA6/8 +75ABlYcWHFgxT9v+383cU1cE9dgd7PdzXY3g67pXdO7pv+ODdewhjVw586dO3fuQExMTExM DDgrOCs4K0BwbHBscCw0fNTwUcNHYLhnuGe4B8/9nvs994Mrq6+svrI6L1z1YdWHVR8GhTMK ZxTOAPWKekW9AhdXXFxxcQW8/vn1z69/zls/f8f8HfN3hNp3a9+tfffvz5e/dazQsULHCkFG dEZ0RjR0Ldy1cNfC//zx+tsLIfeFkZub2/9r/nDi/GJTSp8n5+B0gVvVAixQ6oMSOyMHgC5H fiUvAvGdaCsVBzrzkoaAgxhcoJ7RjJoepPrSQoaB9FD+mgnAHrKlAGA5ZTAB5UV7bQ2IxdJi ZRXgEvPUT0F3j+OiAohDWOQnIO6LDk5v0C/QH/PsCE5Tas8X/SB7wIWip+aAWiipb1JnEDfU 07mV4HmT+8uflYIbnz/88Y0fSNvsDaQY8BWlxnoXAv0L5XTSh6BOxcu7DBicfkr4r6C7qisi nYfMXa5jaW3AsTEjINkC/p7OjdbBYD5h2GC+A1IpNdAwEnSnvSsHL4Ckel4pAQvhwZSEt290 8OzKNelqH3jsee/I9VRw5FecBh34fF1gboEckNN0wdIAyFr+ZnXqLfBVPKqbG0OJArUiK12A gmdLTiqcAEHLAs4G7gH9JP2H+p4gHWAtNUAsUiWtIog0LQEnCKsYJMwgq3zHclCmsUDSQP1K 2sqnQCttufYNiG9EkBYB+uq0lvqAOCKVYQbIZbV7YiCIS2IFO0Ecoo/WFdgu8om1oFSTC4s0 ME2VgpVcsH+hHhHVwSVjFDJoS7RFYg6op9Tx2mPQylFQGIBaYp+mgWgtZkh9gVTasQukX0Rb xoBoLLaLViC+RyYA1PmipsgPtBUpUhJobeT+Bi+QgowHlC9BX14pry8P4pD0Qe4kYKKzrutn kIZIt6kFyi1lj2kGZJ6zFJA/BfttdYLzGngH+R71jgHDPE/VowLYD0qq8j1klkq7mWQGnsj3 5KogdoupagBYu9j2uwZB0sqUczkjwXjeMFB5DV4dfRqbF4H2RuxTfwL+YNLq4+Pj4+MDfhP8 JvhNgNcNXzd83RAKUIACf7Xeu8S53ol6J+qdAFrTmtbw3a3vbn13C4ZUH1J9SPW8RKbm7Zq3 a96GJ75PfJ/4QospLaa0mALRC6IXRC8Aa2lraWtpKJRWKK1QGtzW3dbd1v19AvRb8SsMqDCg wgB40exFsxfN8i4AqlatWrVq1b/fvnFA44DGAXDjxo0bN26AGCwGi8GgrlJXqaug9NnSZ0uf hYqrKq6q+AcuRH6vZzuf7Xy2Ex5tebTl0RZI/yr9q/Svfv/2j8c9Hvd4HMT7x/vH+0PnSZ0n dZ4ESg2lhlIDztvO287b4HLly5UvV4Z61KMecG75ueXnlkOnfZ32ddoHYo1YI9bAPvs++z47 FKYwhYFbt27dunULHP0d/R39oYeph6mHKW/9k1kns05mwc2dN3fe3AlVqEKV/6a8Lya/mPxi MgxOG5w2OI28Hbm5ubm5/R/kPxqg0CCzLnQcvBavriRMgZ8vHjh+5hmYjhhs5q9AqyGasQyI IJ6HIH0lLZYWAyounCAGiKl8D9JycUyqDhJEMADECVFEfADSZGmTEgPyJhGt9QJuU5zVoJWQ FureAI203S5P0HZLfowCtYSlccI8cBxIGHF/JljrvfSLOQLaZ66I9F1AltbJfgxMP3qVMa2H OoNqNazoAbViGrvq+4BxdXBOZCVIaWvb4PkLSC6vBf47wPOF2ctjEuhUr/Fem8GzsnfFyBUg Viv1AgIgc0VmYYsPZHxsOZf9E9gfeoz3qQzJb7zb+1+Fh+fe1H9lgJgNZ8uffgQxO28uvhYG jh7Gox5HwBweeSz0A3DVcDjsKlg/eNs4/R4U/jrKFLIPGlVvPq9Oa6h4tvqtCt9B1I2IYZGl weuFYYrRCkoL7ay2DnRHRTGtOZiWyL3ktaCvQhH5G9BVE19IVUGKFS1YCfyizlWDQfeBdlaN BCWW+dojMH6gdJFHg15mrwgD6XPXXtctcGxy9nd1BesQ5/euNMgd51TU9aCNFaspAMaHersY D7oD0iHXIJA7aQ21aFCmaWdcF0AJErIoBrqrci9yQLkodxc5IJ2XgqQyIF2RxohaIIfRRHQA 3YdyvNQfDFtlnfwY9I2ll1IVMPaS1kvtwTBQ6k4wGOZJ10QHUEKlHtJwUM7rMo0XwSB5PPVe DeZ95lYeb8HjS3mrVBrMm6WVal/w9fCqoa8C3h/rcpQtkFUxJSrlAdgr2bOs0RB6O2xK6AOI PBNRrcg6kO+Iy6beIH/GeuEJun7KLOUy2EY6BmidIL195nTLPVBvqa3VbiA7xHxn5PtrqMWy imUVy4JnO57teLYjb3nmicwTmSfA2d/Z39kfQl+Hvg59/fvjdu7cuXPnznmJXJH0IulF0qFH jx49evQA3ye+T3yf/PPljZwVOStyFrRPaJ/QPgFuf3/7+9vf//b690beG3lvJFRZU2VNlTXQ PbN7ZvdM6Pi249uOb+Hq4KuDrw7+58ths9lsNhs4LzkvOS/9/u28H3k/8n4EZcuWLVu27D+/ 3webH2x+sBmqSdWkahLoRuhG6EaAVFWqKlWF6tWrV69eHUqfK32u9Lm87d79lLj1rPWs9SxY z1nPWc+BfoN+g35D3npPGz9t/LQxVNIqaZU0kNZJ66R1IMuyLMt5y//2fPlb7xLsdw5EHIg4 EJF33I4fP378+HHYErMlZksMbG+0vdH2RhBdJLpIdJG89X7v5/B74+3du3fv3r2QEpUSlRKV F2f//v379++HM2fOnDlzJm/5uwuVk8VOFjtZDBwOh8PhgCNHjhw5cgS2eW/z3uYNhzoc6nCo w2+X+92F350Rd0bcGQF7puyZsmcKPJ/4fOLzibDr+a7nu57DDt8dvjt888r/qMGjBo8a/PPn iZub2/99/nCPs2yQ13kMhIa7Kxrr3obq5srphduD1el4Ym8Lcrx8UjoG0gh2ihwQh8VzURO4 zWUuAnOkadLnIK5rtbXXQAktnizgB/mwlAu0YbQ4AeIxVaV+wGNuisnANnLEddBSpI8kI8jb XAtTfCB1wsEaG38FzXrpq/tlwfR9rS3Va4Ao5t3cdyBISfd73AL8lxovGJZCZhV9Of9m4Nht 1JsSwZnqmOb5DWgRprqGVmCub9CMI0DXQDfTcySon/KtczcYmsg+wgiGhz59A5ZDboDlqaEV WJeZahnrQ+75gD7h38Pdw6/vxZWGex+feXDGCc/Mj758agJnGZ+rHgPBs1hAVf9Pwdk5O9JW AvTbtWjXbSi/qlKLMkDJYRVWl4iD/KaoVflOgsdSXWf9JMg5axluWQ/27mKYWAmGrbryhmgw fak/aCgFjin2evbvQMnFiBcoM+UAPgXNqhm1XcDP0nRRFBxlXYGuHqBNEee5A7aWor9rLYgA 1Sy8wdVci6EcyM+kadpkkPJp+cQmcL4URaWaoNSQCopCYFijbyPSQE5jpPgSlED6iMeg5MjR UgtQW4tG0kBwVlETyQCqikHSHZB2oanLQBlOG/aD4bCusbwQpDRpAvPA9a0ao90FaZYK9UB7 Kj4UtUBrwGPJBHKG1IAEUDtwGS8QF8Q5MkD6RrolR4JazxBs2ABaFz6SPgajyfbAZgXsjun2 74HH5htKUxCZtOUAZBe2NrW8AiNmYXRByCf5VocsBGm/0t3wObwdF/fxo4XgukWw/RCoC+Qj QoVcc+4ptRXY9lhNjgfgkaMMliPeX0Mt8lWRr4p8BVdDr4ZeDQXXN65vXN/Ai5EvRr4YCUX6 F+lfpD8wlKEM/cfxSpcuXbp06bxE7o3+jf6NHhotbrS40eK/2m/3It2LdIczd87cOXPn95c3 4peIXyJ+ATlGjpFjQF2rrlXX/vb6HfJ1yNchHyT8kvBLwi9wv879OvfrQMrRlKMpR0FsFVvF VqAylan8j/ef3Cm5U3KnvERLd1t3W3cbuuZ2ze2aCx4eHh4eHr+9fcj0kOkh0/9qwVrWsvYf 7vYv0rumd03vCvFr4tfEr4Ejm49sPrIZ7BfsF+wXILxteNvwtlB/TP0x9ccAj3nMY6i7qe6m upvg50M/H/r5EBBHHHHQJqxNWJuwvPg5JXJK5JQA35W+K31XAk1pStO89/0a+zX2awzZd7Pv Zt/97XI28mnk08gHnvCEJ0C7iHYR7SLgeNfjXY93Bc8YzxjPGOi1odeGXhtAypQypUy40vBK wysN4XyZ82XOl4Emz5o8a/Lst/dzrs+5Puf6/P54+X3y++T3gTft3rR70w78r/hf8b8Cubm5 ubm5YO9n72fvB6STTjokHEg4kHAA8r/N/zb/W7h27dq1a9cgIiIiIiICWma3zG6ZDfd/vP/j /R/hUv9L/S/1h4bbGm5ruO23y/3uwnJjrY21NtaCLkFdgroEgU+mT6ZPZt6zB+8uPEtQghK/ /zRxc3P7v9Af7nF2XDc8jbfAU8/Yz4+1Ae/iXr29KoF8RUzR9oBkF+fFChC9xCVsQA6veA48 4ClPQf5WuiyNAEddx2tnD7DvcpZy1gNZkyvLb0DsEktFGJBFlogDqRJ+ZADlxDPiQf5MwylD bsaVYqcDQaqfnpVbFaThpVtXdIHPZ03u9toCwZY2hwd+AL6DW0Z1KQHBvav0qpgNoakBa70/ AON4flQGg/qJ6ZSHCsoO3VVTLCh7da/NAuxXNC9rOKi9HOPVs2Bva59kKQK2LpYWGXvAq0Tg 8ODq4PIqeL6UDPcNb75+UxNi1p3dd+Y+POv2qF5ML7Av8t5nfAymxz5V/HqCs3NOSG4keD1R pshNocaomq+r2KHyr3UWV/oZ8vfM3z1fedhnOFT90AtYm7r57o+r4IeRO7ZtXwFrvDZM37AG Tt49f+TMx/DmZNKZuO/AcMTkI9cH2aw7oZsMrmvaafE5EC0v0fUG+a1hrH446D80NddvBo/j hg/0Q8AwhHHSBZAeCG91FpgGyTniMhiayHOkPcBocVUUA7WBWsA1Dqw7XSucg8C60jbPVRHk waKeVBZ8Ms2vletgmq/XSQVAr5cmq+XBUEyaqi4HjxrK9+QH81L5I+ku6LfIUXQHdbf6RN0F jm+cmus6OI+oiVoncE0iS+sHrrm00WLBqYohrgxwXdNGqN3BZVEXi53gaiPaaD+Do52oL5LA lSRGUAzk1zpPfXcwbDV97eEBpifGs6Yt4LGcYFEGTCmmdVJ78A4xxStTIftkepPUR2CZYDme XQ/8joSM8TkIhQsUuFbQB0yV9We9rWCIMU73yARtpjzUVB5yNuUOE/XBNci11zzj/TVU4w/G H4w/QHh8eHx4PMQGxwbHBucN0SgaXTS6aPTvj/euB/Qd7ap2VbsK8jp5nbwub7k0RBoi/Qtj U//RmNq/9a5n8MnTJ0+fPM3r8a08uPLgyv9CT/O7oRXvhnq8S1hzFuUsyln0hz+Of8jlcrlc LrCctpy2nIYuBbsU7FIQ+pzpc6bPGQh8Gfgy8CWcKHai2Iliedu9S/iaT2o+qfkkaBbQLKBZ AFwbfG3wtb86Du+GZPwWsVasFWv/8Xq/5d2Y6UqDKg2qNCjvAosb3OAGVLxc8XLFy/Dqp1c/ vfrp/cd7lwC/S5yTDycfTj6cdydDHi4Pl4fn9cgnzEqYlTAL8uXLly9fPng5+eXkl5OhZK+S vUr2yitHKUspSykLxLWJaxPX5rfL+7cXlhGzImZFzIKTPU/2PNkzb6jMu8S5RfMWzVs0//ef V25ubn++P9zjXK51/u21JoFByA8y/eBN8USPxBZQrFzRLYVuQ1a1nI7ZI0F/XP9QPxIYz2Yq A/0Iog5wUVzmGmR6ZERkHYCAGYGeARbQuonSWhRIW6UIaSSQLi6L2iDuMIZtIO2UV8ue4GqS WSZZAWv92PD46+BMSAu03oTgi/1WDdgF+rPB3SNug3OEPdVuBeOWAkfLLAXxkf1L+zXw71p1 ll8aeEy9sOVJU3hV8+X55NVgG0OUXBNcVRwB9hNg2G/wFhaQ3zqfqVEgHVCj7UtBqiCEtBls J7wOen4Iz18nPUyaAo/sl8ZfOAFPkx+tfvAFZHXxWGa8Cr5JXvW9loOcYm1kvw0+No/WpukQ 8bDosfwDIfSroifzfQOG2/odxqFw+8G9o/d7wL2mMTnP6sDr+NjTb+ygjFC26F+DLVN94fgK 7uhjPnieBYdWHqt1wg+q7K5oKTcOSjQs+rBwLigf6woa6kPiwMTcxLoQ5BX0S9AS0DURT/Wd wTxLr6peEFIqdHZIJ/B8YJ7hXw0cn9gvOb4A5x5XmOsgOD935WidgQZyC+VLUCaKOtIAkAN0 n+oskJaUc8hSCjIbZemTT4JvV++P/ZaDYZdxmSkFuKeY+BZcn7kqun4E52zXOTaD2lUMEBtB Gy2+JhnUfuJzvIH9PNG+Ae0zgbgIWEnnLvApY0QrkGuJj/ga8BRHRVMQhXkgzoFUVqiiLKhD xGOxB4RLnBUxIE+VX0snQCpoLG4aAobvtAxOgNcge0vrMRDJhqJsAgqJIKU0ZN1JfZm8ETyb +Q9yCfBfHNDerxSEHhNnpY2QdDzxytvj4EgRwpIEGQFZhe2VQHul/9jzl/ffYIv1LNazWE+4 ue7mupvr8h4SC5gfMD9g/r8eN6JdRLuIdvBk3pN5T+ZBKUpRCni68+nOpzuBM5zhzL8e/x9J TExMTEyEHsN7DO8xHMwp5hRzCsTFxcXFxQGHOMQh/vLQ3T/qWX93IWE1Wo1WIxhrG2sba0PI 6ZDTIaf/ffV4x3TfdN90H6pGV42uGg2Guoa6hrrAPe5xDyo5KjkqOWDTyE0jN43M2y5lTsqc lDkQFRUVFRUFIkpEiSiInhM9J3pO3nreDb0bejeErD1Ze7L2gB9++P3V/rN7ZPfI7gE+hXwK +RQCBjGIQb+//O8Sbrm33Fvu/V+s8J/H/93Dk5SnPOXfX7yQuJC4kDhIfZz6OPUxvAl5E/Im BMJKhJUIKwHKYeWwcjhvKIpxu3G7cTuYkk3JpmSw3LDcsNyAjdc2Xtt4jbw7BgoKCkjnpHPS OaA3vfkvyvO3F5YtAlsEtgiE1NGpo1NHw9uDbw++PQg3X918dfMVcIQjHIFWtKLVv//0cnNz +xP94cQ5vm7y58+OQ3OPOlHtFDh36/KzyyFg83L1sNeAQrH51KhaoATLvZX9QFdRWWwD7TWb tVGglVWzXHuBRqKv9i1IH4uK8hiQl7BIngbO3a6dzpsgF5CTlBYgRUhRDASckgEz8Nq2xDIK RDfrVXtx8DhVoVz1XNB7hJcpWgO017a7ud1BClBuG0+B+ASLvBxcvqnBlvZgLB3er3AN8O9Y a0qpn8H5Y/ZXtkBIj8xe7BoENDZ+rUsDrZnq42gNTHQWzjwKlFDbqa/AfjSiW8GJ8GJ/9mt7 CXha8FLkhRPwLOJet5vZkDZUX0q/GjxamrJ9TeD6xtnbURLkg/IN6TkoW31+0S+HFzPeLH7Z CeJOJX0anwW2/bbSru4Qvy/x1+QbYCttLeuoAro4uaNSD9QU0cwRCKK1K0PcAFeY0Iv7kLE7 O8r+Pfzy89FDp/rDBcvlzGu1QH4mf6OzQs4vuR/lngO5jjRaKgnm/KZAcy0Qv7BTagM+bXwv epSC7m86eLetBv4+voMCBoKhq76a0Qf0Pxp2GGpD1ojshTnJ4JjlXOFMg7eNUromhsCVKtfq 3hoBqWvSRqX6Q/Dp0BIBr8GUZSpq/hU8c0xbzb5QUSlfvbwLvLoZfb0vgnpT+0JrCVprerIV tLFillYctEGazDYQt0QLUQGkT6QR0inQRmqfas1A+KLyADRPESHqgnZUfMQHIL2kpmgG0lDt R4aANlAEiiRQa1Jd7ACtCetFDsgW4wLDJdBXo4f6I3jUtFa1fQziM8MUOR+Ya2j1lb5glTKT 0uaAnGucqy8CER0LEFoGSh0p+CzyQ/D50nDbvATMH3iU0fuChy50TcQCABr+kVk1/ta7hOp0 z9M9T/eE8vPKzys/j989hOG31K1bt27duhDtFe0V7QV3d97deXcnFC5cuHDhwn/VEz2EIfwb ZkeodrPazWo3YX+d/XX21wHTDNMM04y8Hvbg8ODw4HC41PZS20ttoSY1qfnfxHvXI1mBClT4 6zdKUpKS77/82T2ze2b3BO9t3tu8t0HBggULFiyYNzSgYq2KtSrWyuvBf6h/qH+oh9DWoa1D W+fFebd9SsOUhikNQaSIFJECvuN9x/uO5y8JcJGMIhlFMuBOrTu17tSC+mvqr6m/hrzZPP5z eZEtRbYU2fLP1+fdrBy3a9yucbtG3ljtd25VulXpViWI6hnVM6rn+4/3bqx28NTgqcFT4WGB hwUeFoAOBzoc6HAAdHN1c3Vz4UK/C/0u9IPi2cWzi2fnxfNp5NPIpxE03tF4R+MdENwyuGVw S8g+lX0q+xTEecR5xHn843K/s6vZrma7mkGbJW2WtFkCpW2lbaVtkL9n/p75e8Kel3te7nkJ XOQiF9//+eXm5va/xx9OnEuXK9aq6nTIne14nH0JvMd63DV/Ask74/cnfwr5PEJ8/OMh60Pr UakT3Jxxb8/lxRBU2/dlWGGIqfq6zvkuEOHvX7Zgc4g8n3O6hA4KxBXdXbA9GNfr003jQDyQ crVYcErqY9cs0L8Q6WI/MEq24AWGlfnmhGrgZawzr3EHcLWUA7gPssoD8QtQnDtaMNDemKuk gq6BfxN/QEvXl/IYCuaAEndKjAC/EvFzMjJAa3P28nUnWGO1n6U64HqQ8zY1ACyjs587A8C1 vtCB0m8h+SvPaT6l4NX02/qrx+BFydvzb1gg5bk2mf6gO+b11GseGCxKN7ZC1vTsijkjIL2B esk2COInZLR9WwBcIx0+2gZwVFDLar+AEmeYZrCAWkjtqVpAG+Ts7LKBvEy+gwW0za7lrg6g thJnlTdADor6FFx9nXPVdDBXM9X32gaWGtZQrRmoI5223JFgGmjcY/oOXJlaX9UfsnyzW1h1 oGa62kopkFQm1ZTVENaO+TFjZwfwmeBT0vMclNtfIq7ER6Cu0jZoteHB8xivR2dBN0BvkRuC tbrtA9tZsJLr5TgBmEVJeQhoXZQW8klwnHI8Sd8H4oFroOMTMBQ3puo7QhFHgdeFJ4LfA997 AbNBzFYfaoNBuo0kzoN+udJV1xxcN9WlzqmgdVDfUgBYJFyiDAg7p8UyoLnIIhCkCXiL/qB9 IWbI60G00dLVlSBdpjw1QAtVW6rzQa6nnOMOqPOlMyIL6KdXDH6g76kN1PaCOdY2zFkB+MIQ It8Eba+or1sL1kfpZVIXgJzkvdejP1SbXm9V5YFQ9U21apVuAuekMlQGLUoU5977b7BKdaW6 Uh0+qv5R9Y+q/+P1/3YWjN+aFiy1YGrB1ILQMrZlbMtYMI02jTaNzrsVHmOKMcWY/vX4v3d5 2cyymWUz3/9x+3fb02JPiz0t4CM+4iOghq6GroYOzhU+V/hcYdjqtdVrqxewla1shZBWIa1C WkHjHo17NO6RF6fu6Lqj646G6B7RPaJ7AEUpSlFoYGxgbGDMW6/yoMqDKg/Km4Vj9+7du3fv BrFb7Ba7ISwsLCwsDCpVrFSxUkXgFre49fvrU8+jnkc9DzgbfTb6bDRsS9mWsi0l7/3gV8Gv gl9BvU31NtXbxN+NsX5f8fIn5U/KnwTJc5LnJM8BrxJeJbxKgC5eF6+LB8sSyxLLkrz1CCOM MGjYsGHDhg3hzIdnPjzzYd7QmXdj3Wsvqr2o9iJ+s8f5b1UcWHFgxYGwP3x/+P5wkCZIE6QJ IHWSOkmdoP71+tfrX/9zzj03N7f/WdKlS5cuXbokRI0aNWrUqPGvB9KCXIPUa5CamrYh6SJ4 DDI/9dsHd354+PzkGIh1xTrSekERXdFtpY9DYtfsTs/uwv35zwufDobwFM+N+cPgdeGEKfFH oWVs3UN9i4N3qFc70y3wM/o89y8I/peDZoa8AHWxaCFmgro25dzdR6Cmqdm6qmCYFL6zzAyQ b9qfqxKoMcp0dSwIWSorLwadn7pSegRqH2MbuTDojsvblFtg9Xq44eZNyCy8P/BwHLwdkdg0 cyVkV7QvzX0Kjpe5Ew2RoEssUK6kFdT0SrtLB8Czg4/m3Z4Nt8OO5tszEp5cSRqcYYHcBh5m 33Pge9gzwPMrsHe3brRWgZRCGTNS24OlsyPA+gB07fRZ+vug2rUUcRp0bXTXDW1BmynX1lKA tqpe1AHHTPts5wwQR0V9rRdIEVIt/EEL06JFSRDeIpi9ILJEtCaD/FjuIjUE+ZG8T24P8gV5 gFQNpGnSUqk38KNkpjc4xjneqOXBEK1vo+wHVRJvtNsgjRXNlaYguaQv+BWkUCm/1g9c3iRp WaBLlu26+mAYpL8ozwB1rnpCNAX5oXRMyQ/aFlekOAv8f+y9dXwW17qwfa2ZeSyekBAI7l7c XVrc3bVAgSItUKy4tLQUKxQrTnF3h+LuXpxAICEuj8zM+v54T77s396nbzeFvbvfc3L9kzwz a9bc65aZe+5ZM9OcKVIDyxF7srYBZAfzF2MY5JyQvWTWQxC6PTRjyFrI+mmmg5kLQObXGTdl igFPiuczcwDEOeNqx2yBDIsyfJPhOgiriLV0AKW4MsCcBMZ1Y7V+EaRFNrSMBH21UdHjB6Kj eCN+AHWX8qviBE9N9xizEKjFtYJmKXB28iySl0D2ElaxG7RFVDR7Ap95auhdQB/tKum6BilL 3JoxHJxLjBjyQkIP1wRPF7Do9sGOIZBzYc5c2U5BlSelleLfQ+FOhRfmmwNqlHcT63Vw9LNm cfw/kAgeTzyeeDwR7CvtK+0robQsLUtLuLLkypIrSyDuu7jv4r6DOnXq1KlT5/339z+Nbdu2 bdu2DZo1a9asWbO/Wpp00kknnXQ+NOfOnTt37hyovXr16tWr1/jxqQ9VvCvbjx+fMLMMOK2e cinbQNRSTnnfg0c8H3r/Dlz0v/3b+Q0Q8oOfmScWaq2uPqJqVngtXzV5MQheNHhZ70kheLsg dn5KMEQNTioR2Ru0R2JvdDi8ePBqYeR6MD9OeZvyKeSYm/1hzuzgKchYzQvU/uZA51ywZrcn Bj4B87RawUcB4aNa9e9AMdU8XrOAZ+ILVgFlxSHdAM+8eyPOl4S4Zqf2H70LccU2DNizF6KH /rb7jT+4ncwLqg5Kfa9m2YaCtUyWMfn3Q0DbigWLP4E3Skz8s1/hxmeH9b2N4HHKs+wvv4TY ftrX3s/Af7a3ab8CcopeUd8NMYcTesdWgYRLyV8k1gYmqndEf9AClIfiIdgGWjdpQ0G0F7f0 M6BclzvNFeBp7WlnqKAXNm7rDUDOlKPkMjBOGvf0T4E9qKYA0U5px0GQirxllgf2y6NEgHnD PG3mBVOXDpkDjKlSyE9AjzU26D1BVpDPzd/AckwrKCqBrCqOytsgr8tawglyudHU6AGm1Vxt BoHpRQk6AvvMluY5MKSZxVwDZpzcLteCDJaT2Q9mJnOCWRfMCvK4+RzMc2a4fgRkFjFADYM3 7SJnJZyD6NbRX73dCe76ng4pD8E4pwd5wiHkZMiz0BwQ0f714ggHWJfYttgGgiXM0sjuD89X Pm/9xABltVpFXIGkXCnl3Ovg8vlrW65Oh6jcURejqoBW0LpaWw7eUd4F7e3hTdaoqNiKcP6L yyWuNoSo+W9rR2yEjL9lbB1YALRb6i1HNBCh7FVegZqTAmYfMIabS/UhQLh6T/kZUio4R7mv g3FF72/8ClHL4ucnRIE7X0oN1wvw+cqwi3vg1z2jf9Covzrc/5iQsyFnQ86mva/59NzTc0/P BXO7ud3cDlVjq8ZWjQVbTltOW86/Wtr/PAoWLFiw4L9gCkg66aSTTjr/GYSHh4eHh3+AqRrn f77gd0LAk/U5GlwvBrYhRkLxsRDYzqdlYDS8meh8fusqBK1xK4Gt4enhp7MfH4O4ea5HCQZc mPXk8POqkCXadifQAnm3Bjcufhteq28qJi0CW7h9YNweuFXoTevzflBoTN7ThStCQP8s7twn wTlf+953Ppg+8jNlPajTRCnjDCTnuans6Q6W5Rn65t4BWjm/p4F3wXn6VfXfnOC6/aREhD+I 41qwTyR456vurl0e/DwZU7LsAPvEoI6BnSFmzand1/ODOSpwlP89eKWY2aOXw8N952ufjoIX g576P42HqKEY6jnwCvE6bDeBFeInoUNSi8TyCQ8hMTTZP/E5KF9YZyhzwT7fvsfSHeRoI1y+ AXdHY6rLBxjEAd4CHcxe4hOQD82Cem1QBouPmQVGH/l/5ubO0bIqpUCMNB6Zn4NtsC2f+AnM RFldjYbk+KRE3QQlWZ2BAXIKdZX7YA4xHpgXQXzBJeUBKKvEUn4CT05XnBkJxl1KUgg4xF39 C/BUMk/LeqDF8rPSEhjDalkETA8bZBUQM80z4hKIH8RrAkFEk8UsBPKFzEdVkEXoxzlQSugN RS/Q/CwBxgwwz8kqci4kZkhCPwcRq1+XfL0KvOyOZdb2QM+HJ9VNYB/o1cCrOTz69knWp9fA rbl7myXAecO5MOErSNyUWD24Hbx+GnMqRoHo7xNmxK4C1sUP1hbB40Lhc5/ZoMSJj0S+XRB+ 7Pn05P0Q6RuTO6YGiLrR6/ShoDRVJ8kzoDZQvrL5gvbMsk/egByu0DeZt4LZiTlGDtDCxTBt NNhraCdEXkjQ42bGTgXlK68TjnZwKeFuq0ev4enKZ0VeToJPKRKf96+O9n8C72re1byrQTOa 0Qz+5p//IitZ+RMX1umkk0466aTzP4n3TpydHW2V3Ao8+Tqq85sICOrg3+dMf3g49tm9FB2K nQ9+VCsYDrovNlmfG9z1jaPmRshONr/ctSCTv3Y0A1C3Uem+jTpBjfW1XHUOwtPTT0s/8gPX adfd5IHgJDarURM8PfVDrq9AvyHHuXVQnloe+5YDihs79S9BZBOjXVXBHfQb96fD26R1s3cm Q3Dt9lm75wD7nNw5SzvAtitXJa9EUG9YK6lTgDNKMe0pePpH538ZDYmZL3Y4Nxa0qtZNCRKM g5nvhnWHJw+uLLi6B56Xulnqek54kyNltusgyBkOP5/XYGti/UX9EZJLJDdJfAFvayX8Evsr uC/peYyTIGaIo2otcIc7M7m/BL25Z61RGDyLzPxyGcg9Mk6sAplBmkwE6ZYpZh8QKaItASCi 1fZyHIg2LBNrwNbe9rnqC6K6mZPaIBUz0MgH1jleD5XLoLdwrTLKgJlFf2KEgxau5RZlQK6R 3YyLwKfirhgDxscyWt4BfYlewVwCsj+DaAtikBqkZQKzshwvBSj75QoxEeRmMUN+CbKyOc6s CMzmMF+AiBHZxGvAEJvEDNAXmfFmR1CjGayWA7Ouu77nIKiapTCDQI3TWmq7IKZ/XMakvnC5 /LW5t29CzgXZ7ybYQfaRN60t4G376GfROcBS3jJePQZ+eX2/9s0J7l2evRJISEwqFB8HSZ7E bomnwJgiv2ENOI+5/BPywsk6Z+slzAIxU1ZTx4E8RkG1ICillR+UjPCw1+M74beBmmKiTAFz IreMH+FN5teVIzJDHpG1QWhL8PvC98vQbSAKqCW1CoCu3zU7QIJfZM7oL4CD4ph6GDzt3G89 qW8ZGPxXh3k66aSTTjrppPMheP/Eeb05hgBIGvU20BkHFiMmxX4VbA285weUh5e+ou51D1g+ Cu2hN4AUu7Hp7ReQuOq1JSAcPotrkaHfaPBpat3l3RHEZOaa0yFPr9xNC7og6kn81JdecPl2 QsyeX8B/s2dS2c4QWkAtZv0YXDHuLXoCiOWa3fY1GH1YZniBOtuvp28yBKyq/FmF/WA/XqxO 9XAQZU2rpzzITuYx/TaYGz2FGQnuj1+XuzMO4hrsHLndF9wdYk/omcB3Ybmt1evDK0fS2Ph4 eOa5NOTMeIjYFH07pgIkFxEvlRbg94ujsHcmkP76S6MOJFxIzJCwBFzXjLPmQJCreCHugfAy 75gbQdYTMbQB01cuoB3wkyxBFpAt5H3ZF0Ql9nMbRDVa4gT5lTwqdWCJOQIfMG8xR04H10N9 kJ4I2nNRXPEF0U18hB34Xs+oVwLTYjySW0DeNItxC4S/8kzJB7K3PCs3AJ0oqYSB8ZvMbDYH NlBWvgS1leilCBBRorvcAGZz6U1bMMoaccYZQFJQbgZ1ipJZHQDmN7KNOQnkRrlVTgTxo2gg MoLlkGjLFdD6WhowAMiPyU+gf2OW4i64SroSjQkgH5t9ZU0QecRGpQLcP/BbpRcRoDuNfkYm UEdojdTzoCQo+ZTjEG2JXRzXFbJawuaENIWYcnFvY7OB3tbMINuC+7TroCcGlBS1mNoU3Bnc g1wXgebmGDEdlAfKZXUraD6aULaBMkFUYA2IG2o21QTZUEaILfBmx9t1SbfB8b116ducYB1u Gex1BWwXbFH+WUBatVClJ7jiXTtSmkNK5fjhcdvA2OMVZq0IbCLyrw7ydNJJJ5100knnw/De iXP812/rJ4+FTJcsLYoUg94BjSOHtgfro8BFnupwcOnVAmtngaeTV3vnDfA+Yg9IagIbm50e Oms8dC7sVeSLZ+Dcm7xFnIGz3XfGHLaA1z3vhcEa6NWVXcZkyDso6FKe6/BiftyqiMIQUtB/ 9otr4OMIbB0aDmYjc7ixBJSNop/tNFgmhi3NPQCUH3zrBSYBw5UiUoC84z7iqQmyjHJQOwY4 tTXyLXiSnybdXQLu2W+mxp4CdVTm+AKVwZ0YdNXXBff6/3r8yAZ4sezxrocD4U15PaeZH7Q5 jqm+rUEdw6fyFMTdSkqJPwSJV5ylnIPB0tZmqodAv64XNY6AYlXixUWQbVlrxoBns2e78TVw gKniOajRWm11AJgFjIL6SNAn6SX1QFBsSh8lAFgqh4k5YN43c5sbwHNEjpF7wC3lSgxQHEqo uAL8wjXxK5jrzIfmDhCjZAZRDDwx7pH6CaCFKCn2AuXECdkSjBi52swC6mA1VtkDXBLDZHkw GxmfGaVB1padUMBcZqw2soGaReum7QC5QR4zBSiVxRR2gZZVq63eBzlUhsqOoO4Xt/kB1C+0 2XwNejvjK9kfWCNz4gNGE6OmEQnKZk1TDgBVmGPuAL2PeUlqoERo85WsoAdKj7kXmKafljVA D9Ffm2vgSZun3m/eAg+VLfIliOXKJ2YoWO9Yb6ofg+eBx+0qAMYRo6u5CNRDamNtGchA6W8C YqPRVhkI5lIxlFqgdiNF7gRztPxU+xLkE/OVVCHix6jhseXBL8S3tPdSyPRlUDubHZQs3LR+ Dmp7kUl8CZ6kpBWJP4DWwXrXZ8JfHd7ppJNOOumkk86H5L0T54KDQ8dU3An9ZJtmw0PB2y+w gOMbiOr3+vTb3JCYPTK372242+XpnUf54fXrN94vH4Gy1po3Qw7YZTlX+FBf8Jqi/uI9GGK/ 94x9lgFe1XM3/+0MJP2SGJI8CeITE8++Xgu+ce4t3lMgW+8s1TI1gMDyoUbWZHDtSOng7g68 obvdCeqw4CO5NKB2ysy3+0A5bxwzQkEvrgwTJUA5IB9zGShnFnF6QBvoH+cdC6oaOsenO2S4 Xen7Uq3hrbczW5IFnl+4fPBie4joHe9xZoGUz8VyzQ9sZczxxjNIvpB8JlGH2JTkcfHLwd3U HGV0A7WXHit1kCvlOn4CTxFPhNkVPCMNp5EEykwC1WVAEk+oC8Yez3LjCJhvzBh9B2jjlHPq 5yDClKFiGnjK6h30IiA2U0UUA/HcfCHtIPuKONEHjExyhBwKYiwD5X2QZeiBE+QV0YZWoA4X AQgwc5p75FKQj5VVPOP/vH90I4gdSjNxDsROMYVcIK/rT2UEUFu2ogZobm2TFgRig2IVBYHK TJN3QJQX+YU/mJ+aRc0mIObysVwBxgRqsxI8x5ya7ABmUXlNZgfrKm2lkgvMX80RYiOQVTag DMgVYjy1QT6T82UQ0EfmNi+CuCk3UxRkJnOgPAZmVy4zEzwLzf1GLVBXa59qwSAxe5mdwPxY HjDqg5xnZpcPQH4rW8qcIE/KNfpsUPqIaeZ8YILaWbsKlhKWMgpAjf/zzVy9ov7G3QVsK63b 1GyQcs71nRgE4R+96RLZCrwf2j/ydoGP6RUdtB7csWKCCAIzvyfSdR7MkynHlDtAC1r+1UGe TjrppJNOOul8GN47cc4ps9XN8hOc63Ut8UQjOHb/gu1wdngxMubbcH9wrM1QKWYK+HUI2Oxo DjHKy+Hu2eDT2WuoPQASsjpnvKgGCZvMswlAtua+ffxvgN83/sllEsBnX8ZkRxYQDl5LG5Qd V3xt48tw33Inx4XfIMfzAlPylAB6WA7YWgI19ULO6aDF+odm+hnkNNsi1oI0jQ16dRBlxT0l AZRHcpjRBGRhaTqega1M7q5F60CGRRmD8xjgPTTT3rwz4Prk1T8vGQuvwp+MeXoAYsYahfkE jJ0ihR/AtTJlZNII0IOUUVQHV5KnobEYzE1mNKNAPjW/MJeDWc8MMdeAMVG2l1vBKGWGmq1B fKKUk7eApYynEJh9ZEHzDcitzBMdwIzjjQwFUVCWZS0QQnbqgvShtMwK5BZT2QSiB4VkRZAJ Zj8ZCxwSE3gJSjeZQiRwW3QToSC/Jr/yDZgtseopICeZX1AdKMRAsQaMU3qgvAjqj2oxEQjq S0tV5QHIbbKDiAQGyqGyL7CHRkwGmdu0y91AEyWDXAPmZaOi+QRkFuOE6Awio9ZViQVrKWuI sAHfWs8oT0Gpru+TX4Ixne/MnCCnmG+1NcAZejIDqEJ2MwMYLc3H8hdAlYe1YBDbsYisYPaU pfSBIEfhZg5Q3Iw1soMYI6xaTtAX6i9oA0ph4S9ygyjDp+YnILLLrOanYI7gobgPxnSzlNEC RDFdlyFgquY90RmMH/SBshS4q4luWEBZr9VUMsHb2GjflMHwpoZv8NsY8Jpqj/LaCdaXYo7X CUj+XCwzc4L7QMpBl/9/Bcmd9w/Ue/fu3bt3799xSEgnnXTSSSed/7kUKFCgQIECf377906c j2W7tX7XCnh2JXpx3EDwKmDtrv0E+lPjiNkFRFjsQqsBGUMyvPYvB86vM9pf1oBMndw5CpWA V2EJUyLagfdDa7D1FDxa/+YjYxn4zo8rH6GBpas2X3eAZvMSyT3Avf9hb7ke7q684bWtDWQc lyVBbwjlr1S/2O9rSC6SYk0ZBqpNLeLlANHQa1zm7sALGS6rg1KdYPqBeUxYRGaQ4USbfiA2 aCdDA8DeJfSZdRDEd34+7vFHcLX18VwnysDbb1IyuGMheQ3zxXTw2msL8PIHPZvYJPwhqYTz RooPeBbpi82VINqJJOUMKH8B/J8AAIAASURBVJFqNq0vmO30qe79oFwyW5ixoESqxZWcYDYy H8mTQDYqMRyEItziHjBbTpObABtF+RykKYvKMyC+ExWVMSB7yi6yGWi1LRO0GmAsNPubH4M5 26xnzgC1ksgoQkC5o9xVWoL50gyUL8BsTCm2giXB0sNWEPTyRhY9G5iGMdlsAbSTdkaAKc1W 8g0Ak81MoMQrFdV9oIxRr6mnwMhtdDS6gVpI5BebQWYxU4yyINfLV1wCTLWyuAh8Iyz0BZlM aWJALnAXMQGzqFHN3AsyWrRRVwC3OCqXgzwvP5H9gFK0kitA3jSK4gfiZ5FZLwqil6IoF4EK 8p6yAcxD5gWzJpBVRPEjiJHUNHYBXWWsuRk8HzHH/AjEAblczQQcppB5GsRetasxB+RgbZS2 FIwSRh+xEdT6iiZ9wFwug5UEoLPIyxOwrBQVlNrgKa6PM2wQvT5mUGIpCOkQaE+0gE9vL6xP QVj16WQF/bReXriAzrz4Twj0dNJJJ5100knn/VHetwPnOve+SBcUs+Wwmc2gRJ0SbRIaQ+Zf s5cWv0JEZMoN9zC41++3EREZwbup877mC/KcX6+35yF3g4IF8paDyIjk0rIDmIW5mfwtRC1J vHR/I7y+k9D26RcQXTJ528tzcOX6tZ7HioJ3/+BSeRvBWa5W218RErZGDHg0EBSrbZKlHxhf y4z6SzAPUddeAahDD5ENqEB9eQQoTV2+AKW8uVKMBbMyD8yZwGyme4LgcezZVWejILzpE9/n Voga5l4qPwfta9sjr9rgv8f7Y5+xoC5XflbugukvNZ6ANd6W3TYOlDrKZfURmEvNrcY8UDYo G5WloIVoBbTCoPRXOihHQGTBwjMQ98Q+8RUonyhdla9AZFcLqw6wZLEUtV4C+UxektXAUtxS XMsJ9lP20/ZrYO1maWx1g6267ZI9ARzn7L0dI0FZpezQ+oFaTa2tdQLtpqarT0HsEbkoDcoB 5TN1LTgstnn2MPDaaL9nKwb2OdY71pxgfakOt5wFZYJEaQfsNPKZc0DUNn+QS8GSSd2qjgNp Up2LYETJudwF81vGsB7kYzPEPAUikSpUB6OenknmBLOVK0xGgXnEGK1cB1lFnqMBiFrCrlQC FnGAz4AiLBRvQPwoRqsJIMKFj9gJLGARq4A2dJY3QVQUHwkD5ASzkGwBptUsorQCRVUs1u5g Sda2eJ0BWcHcp9wF441eir3AJDarI4HZ5hoqgbFeL2eGgyH0eNMCHJHPZWMw8nuO6U/A+NkT au4C/YExXO8FUb3fzkosCTFP4sITGwOtpN3VH7Qvla7sBaOmmUkv81eHdzrppJNOOumk8yF5 74qzY5j9on0sxG91TUtoBGHJfOLVBbwnyFf6J5A5PLChPR5CrmkD/RZC9pYZrMpT+G1T/JrX iyHbAHu50p9Dkfkl1mSLgqeln9+79hgSz8Sb3qNAwzLDkhvUe5ZOCYGgnHBtts2CwIN+iv9K iHgcWyi5LuytfqD63GBou7rD9el5IOmpPKI1BKWliJYDQWYVD+U8ICPRSmdgj2grW4FZjray DygHlNZaNHjqx16PKw031Qs9zxaGqCFJIUlLIckjhyk/gFcvRwvvEFD2ylfGafCMc5125QYc YrzYCsoV0VURoMQp1c1w0Oe7b+m3QBknbilOEM200moVoLtsL34EsY444yuQdo7IxkAtuokT YH4hLYSD6WWWkc1A+VFZof4MqqJ6qXVBSGEqp8FQDacxBJRu6k7lJxDbxDHlLKhDLIb2K5iH zFLmGdDHG3X0O6DNVseri8BYZiaZV4DJMj/7wTJBraLEg3imxCuVQamvdFaqgHFTby/dQHkm yyTgN7GCqSCmikHiGmizbS1VHzCeOx+6L4N5WM+kZwalguKtlAMSzO9ENJglRHZREcRsWZKD IEurPdVnoGVSN2oOkEky3swF5GalCAXtpjJK+xjoIpB5gJliuDoKxBzGUBuETRkoO4F4wWvx FEQvdYHIDdZLtuK+fiBXYReVQV1AB6UO4JELEi+BZ6Z7RMpDMGca9RUTGG5+bb4AZbu8zh7A JvrJpmAGmOv0qaCuVztoCSBOy3xKUXAccwyxLwNlvdbYdhcSpiTlN86Be7GnmREAalPVT+wD GSHtniVAm786xNNJJ5100kknnQ/Fe1ec33SLDE3ZAtZA2zR7TwgSwZG5WoDTrkTFXQZLF4rI saCvsy5NOQMRka5vY3JBct/kPCl74HrpV+sP3oP71V+Mvl4L4qPf1pFlwRLlGGe/D16OoLM+ S4FN+gX1PMiORk/jPjzO/8D6PAgSSsVcU3vCy8PGpcfxcH/VoyGLl4DXHftNaz0wv6Gu4QSW cVU9AlwVj6QJZJTL+RFYYbYxN4N1rqWmlgxvht+tfOsaPOv4sMfDz+BtlPuk7gcyUEy3aGDz t71Vm4Jzg7uS+zok19A193Ywc8nrphXcK91lPafAmGoc0O2gnbY8tS4EzzK9orEBpDTOmUvB 1sxSXHkCygmti2YDVVNraBfBMs7S2FIPbIUsn1sCgWtck9WAYpSQ7YGBDKAuiD1iN+tA1pTZ jQfg/CVlRPJb8HTzBLh7gKeo/tLoA7ph5Da2gxqmFlVTQLkpLirTQflc3OEqSIVJ5i0QV5Tx Sk5gjFwjBwFJFGcMiCVKCldB7hShfAnacm27dgr0ieYP5lZQG8vlojrYhllL2qaA2kx7YK0B arDmpf4IsowsLGqCtJgTzeVghjOVXKD+xCBVAe2Z0sziC2ItRZVvwIwxrTQBY4/x3PQHT19P Z30LWFaIvVohsCxRvC2XwbrX+oXXEzC/NRvLwmAW03ea+8A9MOVO4kxwf5b8MKEsJNdMqhs/ DIyPPEv1iuBd21cNSIHMd7NE5i8AgeuClue4BLaO3n0zrAevgICGGT+F4P0hU3PMhIDvgjtm ywOOvv7jg/uCb5XA/pmbQsZjoQvDbGD5xrEqoDB4uuhb1FJg+V4sNxaB1lFU0cb81eH97gyr NazWsFrQ5nCbw20Opy2fnmd6nul5/mrp/vdQpkyZMmXe4Y7F37f/q+z1r9pv3JG4I3FH4KsN X234agNUvVP1TtU7UHlg5YGVB8LAWwNvDbwFL8e9HPdyHMhP5afyU5g1a9asWbOgpl9Nv5p+ UGlFpRWVVkD/pf2X9l8KL168ePHiPSZTva+d/tX8nj3+U/zlj7hS9krZK2Vh8ODBgwcPTvv7 96R+6j51XL/3938rf7Wfvm88/rN+8O/ivSvO2c5lbGu9CZkXZd3pGwThP0bfj7kCz9xP96Uc AaWZOtM5BtyPlRIpX8Pb9rEH/caDd6DSwVEXUn6UTRMbgauOvsnIBsmJnuL23mB/EJ8nLgSU /n4nPPFgdNDmqOPBnWL6mrNAuSA6Jz4B5WOtcdIoeN71bZeQbLD0o11TN82Fdg3K+jqyQfG+ VS90nwiJ652HE3KCdpoWVg1kBlmC5iCaC3+1MshRxl3XI/it9KWyl85DVOcYM7YdJMS7X3EK LMXtNxwLQQ0Rt5SOkHwmpXby5+DqJOeYgUB2JVKrCZZJlkGaDuZUo5EyFWipdBerwDrbOkpb B+Zq8xfzAJhH5XwxELST2ga1DMhRcgp+oIxXRisTQM6S3xurgdM8YxKIM+K46AfmCnODXAtq D7WLEgnWslpd23xQ5ypLtMFgDpHr6AieOH2UsR/UYDWP0gkUN9FiHeiNjNWGN2gDtMdaHVAS VMWaB7QpqpdigJFiPDbiQdQXdlEdOIMh+4N1sFZWGwGyPLf4DpSyoqooCNSS2/AG9YqYqrYD bYS61GwERqBR2egOchhbzKtAFF7yG9BOajFqIxCDxBOWgNnPKCCtICPNnfI4iCpMFBuBODFC +Q3Uy8pTtRS4T3uKuxeA5ai6Q/MHT2XXGecr8Bw1jhjnQLupXdV+AbWGmlf4gFnWbKH/DCwW TzUPKHW0/NpTMPKZq+Ur8L3qW8vHA2ruwLcZ8oK8pq80joClhlXR9oGXjy2HFgfMN4/qJ4GL dPLUAMu3ymSSQF0sZqk5wVrEvtBeAbTKyk2lOCjtxTClNai7lSdiKgBd/7rwfneOxh+NPxoP 5++fv3/+PlCb2tSGDYEbAjcEwnCGM/yvFjKdf+B019NdT/+Np/1V9vpX7Tf1hHv45eGXh19C t27dunXrBpl9Mvtk9oFpXad1ndYVRp8ZfWb0Gejh6eHp4YHV1VZXW10NBp0ddHbQWVA/Uz9T P4Mfkn5I+iEJvl3y7ZJvl8Dc03NPzz39/nr/T+P37PGf4i+/h/6R/pH+EUxNnJo4NRGeuZ+5 n7nBOG+cN86ntfN093T3dIfwceHjwsfBoEqDKg2qBAEPAx4GPPyrR/Gfw1/tpydnn5x9cva7 x+M/6wf/bt674qzftSQ5F8K9xo9eP7HC1el3l97dCaFVs1bxyQ8pl2Tym5cQeTG6hKM8KA9E oG07RK5I6mxehJj+cXn8doKnidEmwwGw9Q78PO4hJFf09ExcBm8PPMuSpEDcqTcTXRPAHGfc lkvA6Z0yVa0MbxJjO8Y1g4gO0aXCx8O9vOGvYgfAikuHm06Jg3Db3V5HJoM9q721bx0ws5n5 9S4g1or9siUoj7SvlKXgfBi5LaIAPHlw6/SttxDTOmWuKxoSaxtTWQjWyo7vbb3BPcaT37gC KT+5F6WEgl6JUiSCscTcYwwFoYibNAHzlNnYBERn1vEAtANaX20lWPppn2oSzDdmRfkb6J/o DfVdYGQygoxGIGvIOrIfmAvNX8x1IJeag8xdIAfIWvwMIrdwi+bAIrqyHhjDdTMJWCTWywrA Umbog0GEsdvQgEfyFcdAdFbmKZlAXaY+VFuAskSdpW4Cy0JtszYT5M9yNxWBzXKpKAGKwWTl OggnJcVuYJRM4TjIAuY4eQfUFUorZRCwEUV5AMYUc6mxDkQHMVBRQHQT3dUbgJtwURUsyyz7 tHqgZFaila5gvWG9bj0J8jleRiyI25SXTUEGmd8a50EP1OP1ayDXms9lffBsMoZ4SkLSEtd0 fT7oy4yx+IH6Rl2nTQA0hPgEPE087fTd4JntWWCcAFlR2o0NoHfXD3nuQ/Kvyc3jN0JEjVeX n7aE6IVRA8PnQnKHhKaRL8FM8BRN3A5JWZJaxp2B+Hrx2ePaQ5JX0oPkL8H5hSvM8wQSCiT1 TgmEBGdilYRREHc1sXtiPHjOG03cu8DWSp1l3vpwgXow+mD0wei0SnDz7M2zN88OTSc2ndh0 Imwfu33s9rFp7WNjY2NjY2HEiBEjRoyABtsbbG+wPa39yE9GfjLyk7R2Y8PHho8NT9u+b7m+ 5fqW+8flvS/1vtT7EnTq1KlTp05wp+qdqneqpq3v1atXr169YPLkyZMnT05bvvPlzpc7X8LX Db5u8HUD2Ldv3759+6BVq1atWrVKG0+jRo0aNWoEy64vu77s+j/qIbUSsur2qturbkP7hPYJ 7RMgMTExMTExrRLROKxxWOOwtEpG6jj/iA8tV1T2qOxR2aGf2k/tp6ZVxlLX31p5a+Wtlb8v z9S3U99OfQtNdjfZ3WQ3zC8+v/j84v/YLrVy83v2elf9vKvcv7fff5aWU1tObTn19ytdERER ERERELI1ZGvIVuhzqc+lPpfStsv8MvPLzC/h9qDbg24PAntle2V75bR46dypc6fOndLiIBVd 13Vd/+fl/D29p+ov9Y5NnTp16tSpkxZvP53/6fxPf3Oi/7P+mqqfOa45rjmutP4XLFiwYMGC f94ef+Qvk/ZM2jNpD+zatWvXrl1p61MTlvrP6z+v/xzeHnh74O2BD2fnVNbUWFNjTQ3ImTNn zpw5IWvWrFmzZv3Hdv9/hbI0pSmd5qelF5ZeWHohNNzecHvD7Wn6fVfe9Tj693ZKTQBTt+tc uHPhzoXhRcYXGV9k/Nf7wfv66Yey65+Nx3/WD/7dvHfi7ClshPtNBE9UtN3SH7wzmG7/lpDx uhehP0Kh0JCtwY/BkdHbEtsXEp4ofV/XB22VtXT0dOBJ4pAoDVyl9Z4JTYBY8X2yE4w5PuXi roHPNrvb8Rq8Q9Xa1iFAKX2bcxfY9vn2dI4E92h3SctbCG8Qfke5CM6vUuY6K4NWy79x8EFY UnHr46GzIGFOeJ/bZ0Ebbvvc+xmYIXofz3HglDZY8Yfouo+LPioLz5++9HtxBGJiU4I9FcB4 o5RXz4AlxXrB0gecie5erteQPMFTzNUERGnhFNNB5jJumK/AUPQ6emEwG9PK3AeymPGl+RiI NeuaA0AZLH4TCohGcoxYDWYe02HmAE5wXrYD85Z5w6gAYojoLgA1Uk0REaAYVKcFyDdGHqMa GOf1GPcp0N+aa8ymILNKj8wODJG5WAmOOjbNHgXWbZa2liCwZrNIazBYW1mKWGuCKGC+lWWB j2URFoLaW+2vtgDxWPleLAYlWimnjAK1uxKk7AF+wY/fwOxvPjL9gMZkoSeY1+UOuQTYJG5w BIgVU6kCGprTmhu0HlpZmx1s9Ww27xRwfOeI9K0CDpejt99NcNTx2ulbB2xjrAW9doJfdZ8j gQXBt4nf46DGYEwwMhhPwbzOXfaD7wr/qUGzQGtjK2PfD7Ioj9gMHh+9vR4KxjmjgOkCM9Ks IiuDMzD5dlI38HztDkixgt7WlSP5U3BuT/gttgO8dkRMeXkLnnz+eMkDOzz+7nm/pxchvEXk wtjpEN/FtdVTCOJWus4RD+EDY3qnVIDIYynNPcEQ0zwpXj8NUUFxXV0HIeWUu6WxH5RHWMx6 Hy5QJ2admHViVvih/Q/tf2gPW59tfbb1GSzsvbD3wt5wvOPxjsc7prWfdmDagWkHIORZyLOQ Z7Dr5a6Xu17Ctufbnm97DmHjw8aHjYdv23zb5ts2MDHLxCwTs6Rtv6j0otKLSv/+8orWitaK Vri48OLCiwvBPdc91z0XoqKioqKi4NrSa0uvLU3b7nLfy30v94VKNyrdqHQD1t5fe3/tffi0 1KelPi2VNp7l15dfX34dfrrw04WfLvyxXtasXrN6zeq0E0bqgTs1Ua++pvqa6mtg5q8zf535 6x/396Hl+jbvt3m/zZs2tWDbtm3btm2DAcsGLBuwDGYUmFFgxv/lbSk1a9SsUbMGLC2/tPzS 8rBq9arVq1b/X/zkd+z1rvp5V7l/b78fitQT+t5se7PtzQaWZZZllmVpCXzE7ojdEbuhSNci XYt0hbJXyl4pewWG+w/3H+4Ph6Yfmn5oOnT3dPd090C2N9neZHsDExpPaDyh8fvLl3qBExAQ EBAQkHYBtjVka8jWEEhon9A+oX1a+/f117KirCgrYMmVJVeWXIEVlVdUXlH53e3xe+3q1atX r149OJDrQK4DudLWnz179uzZs1CwY8GOBTtChk8yfJLhkw9n59QLpDXV11RfUx2G1RxWc1jN 32//ZPOTzU82g9JX6av0hYaNGjZq2CjtQrNRWKOwRmFwvf/1/tf7v7s873oc/XuC6wbXDa4L e5ruabqnKdRaV2tdrXUw/ej0o9OP/uv94O95Vz/9ULxrPL6rH/y7ee/E2T7J09WzD4IW+633 bgLBDr99lm6g5DPXGuUhbpWR5DgCWmPzgawLAaO0/RmygG2xbZVxCZwXlWwR28Fd0rMjNg7c CUnZfDNAjkt+fTMngL2CfKg3AMtviQvUKHBcNHLbSoFlimOjfAoZXmeeZC0OwcEZyurDIMwV NNe7ECSfi7IoVghv6ZyWcgbW3NvQ5qs+QGySjK0OYoFlqFcz0HbJyjSDiAvPG94vCG8LxDRL dELsG32neRrUjBah9QUxQZRTZkNSnpRXCR3AtUJPcE8HMdxoYv4C6NQUq4BfzMGiHKhD+EL5 BOQ1puuXwMhqfqtHgtHW8BibgUWMoiyYjcyOci0oNiVBCQLlK/Exq8DSSxsgqoL8gcNKCVBz axcsfUDcUkaoGcB4YGZnGhBKrDwMorWop1QBhohJ6iQwaskFdAM505yKHYwt+hjPJlDeiO1i J6j91DFqaaAj9bkPoptoIzqDulJ1qTeBLsKPvaD8pFZU+wBPlFhhATFX3KMJKBs4z2JQdXUO Z0Bbr+xVboK4K0uLwaC1sP6oXYXQaVnq5RwOmW9nbpbPC3wn+j8LzgkB64ITM9aBEFemX3NU gZCsYUWy+0HAtYwlQnNBaOPMIblGgf2614TAJAj9MfPsPG1BWaY51DFgHNDnuCaBPsIToZtg fm2c1r8F8xtjt+cQyDXGEfMqmBuYppQEkZs4cwjoSYafXh+8SvjdDzgM1lG2/o7mYNSXFY3q kPQwYX/cNXB/7lyVXBrM6eb3xhqw7LMcsE0ARzOvGoHzwb7MVsQ/M5ifiFaOp5A0Uj9u2wSJ 692ZmA7SX/lcHfThAjX1ADl259idY3fC8uXLly9fnnaAmfH9jO9nfJ/W/nS3091Od4OeZ3ue 7XkWlM+Uz5TPQCwWi8Vi6Da329xuc+FU11NdT/2JW3ipCfClRZcWXVqUVukrq5RVyiqgXdOu adcgelr0tOhpcEW5olxRoEKFChUqVIClFZZWWFoBgjYGbQzaCOuHrx++fjjMvzD/wvwLYP5k /mT+9Pv7b92qdavWrdLGlTrFpOnuprub7k5r1yKyRWSLSDg3/9z8c/P/eFwfWq7UROPv5aq8 vPLyysthfvf53ed3//3+Uk+owcHBwcHBabem35V31c/7yv1H/H2F6umWp1uebvnHcf9DBasU pSgFOxruaLijIfRZ1GdRn0WQ+2Dug7kPwtTmU5tPbf6P+8sxJceUHFOgqldVr6pe8Dzj84zP M8LiK4uvLL7y58eRSuqt8NQKvaZpmqal+UHqhdiftcffU6ZPmT5l+qRV4P+sX/weqRXbR189 +urRVxD/Xfx38d/B7gm7J+yeAE1eNXnV5NWHt/OMDjM6zOgA3bt179a9G2T8OuPXGb/+/f6D NgVtCtqUVsndvGnzps2bYGXllZVXVoa3+9/uf7sfJu2dtHfS3j9h1/c8jjbO3Dhz48x/Y9+o FlEtouByn8t9Lvf59/vBu/rph7Lr3/NH8fiufvDv5r3nONvGa1eV0pB43OVnaQGmv+ZndYFz lv7KSALNbtudNBbkXv2MnAWijHnPOQ+8cmFhHET0N36zfwq2QdrhlMVgm6D8aF0ECVvihuMH 5llXs6TdYExRWnllBt8RYWVtMZBwJ7G0d0V4fdT5Kqkv+D+1r1E3gn89znmfAPuNsKFxkeBs Fd/NNxIudgqf8HIFFOlwoNXSclC1YN2GvbeB+Fz1iOEQnv3+1KehEONMSXZWBddNfaueGxwl fL5yFAHzshwoh4FzqDPG+RB4yjZxBoyycooxFeglxyvPwdwhL8uFIIazkZXAIexyC8hd5krZ GngjGsh1IA4obrEctD5afe0LMOebs2UgqFJrrn0G5hgzydwHop/wEkVBXa1uUFqAedY8K08A Y+UB8oMyggPqt6BkFYriAe2y9lbUBv2tPkp/DqKgmk9NACVZlBEzQZmmHBRvgFfCS70JfCH6 8RpUoZXWsoPyyBDGBWCzfEUwyMNKFvkURHnZV+0HorDwF6dBOU4ZcoKcT4hoAuKJ8Fic4POz /wP/K2A/7y39doKeVT9n3Ie4AXEbXl8F1htRSeXB9WNS2aipICxqFvtLkKfMG3oH0H/QC7in gNpfDYudAL5TfPbZ+4OrZUq/FDsklI//IqYvmJfcJTyzwCiqh7iGgfyY8mY7kBPEVGUlcFWM Uu6AOMprWQ50f+MzEQi2TV4x/ibYFnh97zcSktslE2kB/arh76kOgU/9nBmjIeCbwO6Zg0F8 rebiUxBFNOy3QatoKeMoCTJZFqUuaElaMe0WaHnNWSmfgH7P3SP5KuhtDYUhwJZ3jaj/nh8K /FDghwJw7+G9h/cewvUh14dcHwJLTy49ufQkMJjBDIY5zGEOIEvJUrIUaPu0fdq+f+xPXBKX xCUwn5vPzedARzrS8Z+Xp9iZYmeKnYH7u+/vvr8bLha9WPRiUSi5s+TOkjvBesF6wXoB9rfc 33J/S/Bd5bvKdxUE3g68HXgbPq/0eaXPK0HIvpB9IfvSKqtVqlSpUqUK7GAHO/4v+7fftt+2 3077HZkjMkdkDqi5p+aemnuAMpShDGDFihXENDFNTPvjcaXeMv1Qchk/GT8ZP4HZ0mxp/jff kEy98MlJTnL+N/2lVlbfl3fVz/vK/UfMKTqn6Jyi4Ong6eDpAJ/bPrd9boNXjV81ftUYNm3a tGnTprT2rtOu067TMCZgTMCYADj6+ujro6/Tbv0OujXo1qBbYBtuG24bDud7nu95vmdaRbp7 se7FuheDL7y/8P7CGw5uPbj14FbYFbsrdlcsjGY0o99Dv+KyuCwuAw1pSMP/Zv1/xRtBBBH0 /v76ofzi90hNpGrNqjWr1izY0W5Hux3t4OrSq0uvLoWJX0/8euI/kci8q51TpwId7X60+9Hu MKPMjDIz/pvEK7XdjKczns54Co3mNprbaC6ERIdEh0RDCCGEAEHPg54HPYcXn7347MVn766H D30cVRYri5XFaf3+u/3gXf30Q9n1XeMxlX/WD9b6rvVd6/vu9v2zvHfFOcYr4WOjC5jj1Azu buD5TO9APLzaHjks5TvQf0gSajYIrKSeDv4NQjP4/5boBWq4cV4sgYyHfBr4T4GMDTN8IWaD pZalVlQ/CAkJOmQpDF5dfTPa+oDPaFt9tkPU/KTTMWdBz+jnjlsGIYOzTkuRkOEj/yVehUDZ bh/JDEjMG9eZyeB87fLzDAD3Mce9lFawzv98l/XdYF/RnYFLloKr6qs1j33hZeOnjhdhENfB 7e/JB8m7jW/M8aA2tnS2/Aie7npuzwFwjnSnuIeBLMwQdQ6whk5KeTBtco45HGRvYmVfkD7y gnwIRi0zUm4AJiovlJYgjqo7lC9ALqIoX4LSkgWiJoif5BsegZ5PP6+fB3OI9JWPQV6Vv8oT YKwxppuLAC+SkWBeNI+Z+0D2kr3MHqBOUucqQ0FpqbQVdUEdpU5Q5oHyi1gkuoL6Wg1Xd4Cy T9mnTAPlBzFZ5ANLKctAy7egtVC2q3lBK6JO16JA89KqabVAS9JiLCXAWsl6y7YfLFu0vFY/ kNNEhAgDa1abr1UD7zp+z3yvgXWgfZ89B8gG5jRzBiTmebs04hLQ0zM7qSwo90RWLS8wWd5S noN6gwvufqBUkAuM8WC5r/RSCoK1m+WtqoL3LD974EUIqhV8NeMKyBGaa0iBNxDaPNumvEC2 onnufxQA2S/nnV+qAoRNyzWg+FeQ5U7uOcXnQOYfs88rdBSylckTX7I05NLyLSy1BtTa1lwB FcDnTtDgjC7IV/6jwVVPQWCmML9C98GxOOhtcBJ4B/r1DiwE4mOthaUQGM9Yy5egLtdWqrtB +ie1ijwEiTmjv3/xPaR0ShqcsgeMisYi6f3hArXNd22+a/NdWiW0dUzrmNYx8NXDrx5+9RCu /Xzt52s/p7VPndO2YuCKgSsGpj3VnPp32fJly5ctT0sI/1lSt0+tVBRKKpRUKAk2191cd3Nd KGmWNEuaaRWrlVVWVllZBSreqHij4o20fq5evXr16lXof63/tf7X0qYEpFYe/n/+q8L4R2SZ kGVClglplaaLFy9evHgxrTI5csTIESNH/HE/H1qu1IrL389BvyAvyAsSvs70daavM304P/k9 e72rft5X7tT9/q69mmRpkqVJ2txF6zLrMuvfJACpy1P/pt7STq3QpV64pfrfgZwHch7ImXar O3XK0Lzi84rPKw4/9vixx4890sYf2TyyeWRzyBefLz5f/PvrOfXtHqlTSlLnaqbeoVgkFolF 4m/G/4H89V394F3bpU7ZmG/MN+YbUOtBrQe1HoB2XbuuXf/j/t7VzuserHuw7kFa4pX6N/PO zDsz70zbLvUOW+pDje3yt8vfLj9sfLTx0cZHafKm2rlihYoVKlZ4d72973F056udr3b+TWV+ S8iWkC0hUOpiqYulLv77/eBd/fRD2fVd4/Fd/eDfzXtXnO13QsNjyoJY6antDgXPdY9u7wWJ u13D4iwQ+Jl8ErII8rfKtCDzMAi55dM843dwJ8LS/WUgvI5/0MHMCPZzSkn/DiAmiuTk2vB6 edJLYxho52LLWbdAUKegYdo5cJcNWvN2JIRHPnGknIQMzR11/KZDUgW/yh4FSEjo5fMj+Pb3 c8vZYOsYLOwTwe0V8f2b4RB71lPp9Sw4Wf7+J0cKgLE9KcoyBcLXxVdyroSkVy6H5yKYFpHD XAdade1jbQw4f9ZzuxuDp7hRy/MN6DMpI+aBGGYsMnuBrC82sRXkKjmJeDDnmyONEFBWKjnE LjCbm72MPaCP1L/W54LWX1toGQ1imLgqqoCxwVigzwTyKqY4AkZe9z7zInAdSR1QeospojWI /CJGNATKM4nBYByXTYwMYN6Va+UmkE8oKX4Cc538mFhQ14ov5B1gNZMYCQJxWbwBWVfW4y0Y J/R5+ipQvtTGa2dAuakcFS5gElnFKZCfyGdyDYjJQlELAY+0EGUlaMJS2JoElnm2F45WIO+L BdZvQbknxmnlwTkxKXtiKzA/YrN7O8hSahlrEogoxWVdANom8cQ9GTSralXDQW1lO+S1DER2 yxOrBO9vvHcH9AG1nrbTVgt0KYeYCWB2p7f4CqxvvBf6DQRxBT+lAah9tFZWK9CWHGwH+StB cj0oYWQxbaAplnvWoeAclpKUcAWs+VW73hf8u/j9mvVnMCcw1cgPyjN1uVoM5EhZliNgDDCF rAaindggu4Of9JllvQb6JedA/Tw4X2hh1nPgeBq8OKw7WMIcc3yqghgvhihTgGEfJlC7nup6 qusp6FWyV8leJUGJVCKVSFBXqivVlTBm0ZhFYxaltR+VYVSGURlg6uipo6eOhqZ3m95tejdt feEdhXcU3pH2cMsfUehEoROFTkDH8x3PdzwPv/ALvwCVbla6Wekm3PG+433HGzKHZw7PHA6O WEesIxYis0dmj8yeNrWDEpSgRNrDL6kPE6Y+BV/KLGWWMtP2N2vhrIWzFv7/BfXfZfz48ePH j4dJ30z6ZtI34Nzq3OrcCo5VjlWOVfBlli+zfJnlj8f5oeUa9fGoj0d9nJZorgtbF7YuDLwG ew32GgxjM43NNPZfkDj/vb3GVxxfcXzFf14/f1bu3/OTP2LzqM2jNo8CRjGKUf+4/uy8s/PO zgNqUpOacKPijYo3KsINbnDjv+kvtcJ1d9bdWXdnpZ143b3dvd29obxR3ihvwMgcI3OMzPH+ +k59eGyyPlmfrEP9jPUz1s+Ypq9WO1vtbLUT6EIXunw4f31XP/g9e/xeu8InCp8ofALsleyV 7JX++Skaf9bOOVrkaJGjxT8ut061TrVOTfsdNiFsQtgE6JW/V/5e+eHl65evX76GmSdmnph5 Aiw/Wn60/Jhmh6HTh04fOv3d5X3f4+ijjx99/OjjtIcpg3IG5QzKCd88+ObBNw8guld0r+he /3o/SOVd/fRD2TX1AuyfjceslbNWzvrfzNX+PT/4dyP+z1w2KcuXL1++fPl376D7R2MfFNsL pQLy7ipXF5xR+kX3r3D+7N0Xp6+C/3qvgd6jIVNpv/JZX4H5Wtlr6QpvX7z+JOIi3F34uHhc fQiZmemU5TYUvxnaLsd5eNr0bS+XB/yaU93sB5EttInxQ8HbFjREbwHKTaO8XAgvV8WVctWE wF7iUNYFYD5LHJ98HEKnZR6dIRb8bll3pdyF2BJJDqcLPFu1A7HTIdf1oBIVekP+J0HOOg7Y fmVJ7yXL4GqpZ8WfXIeUAbKDdQmEnc06PlcMJEYnbYzbDM+nvaz3dC8Y+URe7RGYJwyb7AIo 5JY3QLTlFsvADJGmWQjkPnlOdgORUzQTbcE8ZR4wd4KSQx2sVARlrbiqLgR51/hSvgIcoo98 CeZnfCMmg3ncvGWcA+U7nDQCysp1ohmISspFMQKES7mHDpYCGvYGIB6LpfQGZYwSIW+C0ls5 oG4BJVzdapsE2kntodoPtGDtrq0TyCnkMjeAvClTpBPsJ+xXvZ6AVbNl9GoN6guliFoSlIzq YOs5sCRav7BlBiVGe6l2BmO/6Mp2UMqIx5YjwB0zxLwHrghntaTZwC4mGp+Bo7e9i/01mKuM c+4WoI9xjkj5HrQK2g7rYBBlLTutY0D8oK6yzgW5gFVqVzANM8xcDfK0CNYUEM+V5cpeMHeb h/UF4FyW8iyhPSg+7JHxIGvhp3QCT4TZSC0BKRMScsRcAlc/T0rKAAjqFVQx+HPw+cEnMfhr cM11eacUAf2c+Sp5AliWKdvVfWDJ4xgeVBtc0a427tUQ8KUDbSEoB/jRMxZiayS4E78DdYP1 me8zUPMqDYkG5SDX9DyQvUzGOJsPLLEvvbL4+L8/sNNJJ510/iypFcgr6hX1igrft/++/fft //23xP9fJfWOTWoFOZ3/GZw7d+7cuXMfoOL8emZsbtUDZ398GHbnLMjd7qcJoyC4v/d3Xr6g 6L4nlXMQ9cZ6P3IrXEo4F/n2EviUd5wWp8DWUpZXW0OGuQRmmABqPp8c5gTIfdVLtVyBF+ee PY2OA32bdUpSVojrlzzPUx203OYJ7xDwGqJKyzxw53UlyFXgtS1gsDgCiXnE8lfN4bVv7G29 ENh22fr4FAXf4WZ2n6lQdkT+PdVegKHEtrBNgZhs8ccTxoHzS6OMURuUzVpF8TGIXeo5eQZc FtcnnsZgVNSXSQvISK2oKUAuNyeYTUAGy6zyGsjyDJaZwDwnj8loUG+JeaoFyMphmoHMKx8T BfQwe4qDYIyVmw0B1MApAe7K+mImyAsiCBsoA5VjtAIlRHyungCeyjsiBqSvPG0uA1qIUqI8 GB/J7GZWcPSyXfYKAnWq1kNVwTrOPsD7N/D7yf9V8G8gDorPpROU4aKvRQHTanRxrwLTNK6a J8H2m91qXwhaPttQ+zKQT0V7S1NQk9URqgDLWXWr9gnocWZhdyUQLqOO+xOQlaRhVAOlquaj usH7rO9o70QwB3rWGaOAaLOjuwsIwXOGgu2OT8sAD2iZtKZaMKg9tV/sT8E8afwsh4E4KxrL O2C24JicBHp9vZ1RDcyb+oWUQmCudhVOPgLWutLbuAXuR0YgseD62rNQzwGxSvTPMYUgaWby 0ZjMoPWnsRwDuuLsnvQrmJUzPzA7gr24o4DdA/ohtyG3giijbJPzwbMpKXPcWJDTZA91KLzd 66qS5ARzuVlAbw6ih/WidS9YMxuTnZvBGKv/Jl9DQHafGT6lQOuLl3oHWP5Xh3o66aSTzrux e+Luibsnpr1fd+rcqXOnzuX3S/zppPO/iPdOnLO/Dl2uDIC4bs7TEb3A/4C6yqs2ZOigeTtW QowlOWtifXCN0o7rX0BRM3+gjwHJZY0lsh9o8epm+xSwvUm4ZRkNZrkUp6cOBJgB13y+AXuK s5UxGbx9xYwso8C13v75m1fgumbMTjkF7PfUd7QAsZBBMRHgLKd30W6AtlUppikQOCS4TdBJ cN7xuu4cDOaYmEGOqxD8tb81ZzD8evt052OHwX2a+ewFvb3+vTkeLJutRUUbYKFoTQB4phoD 9SCwBjhM71lguekV6BsLeoRnqLwLXMEh/ME+0WH3ugi2YbYb9mJg5jd+03uD54guPWGg3FMn qH1ASHopv4Axz2ivfwbKNeVjmQyWu9ZI3ypgWsUjswywRkaIjaD9ZKljWwW8lXk4AkaQJ8x1 HNTBorRRHLRlFo81P2iRWgVrblC/0qwWDViqCOUrsOS1jPNqDOavSGM/aIOU3dpnIDrRU3YA tZw6Xw0E4zPzop4d+JrHSm8Q48UGrgLbZHX5AmRT2VuvClobrssDoDqsPRylwYiVrZVnIOao TdTzoH/mqe7pDvJHYqgI1s8tQ21FwXHY3s56CVx39Z9kfTCXmQm6BeQg8zsjBJTfREtcIKJ5 YPiB8RFJSncwHho9zfbAOVlV5gKf095BXi9B/qTvML+DiAuR9siREO14O/B1Z3C3dFVNfATm SeOg2QRSLnmymi/AXMphxReiLka2jBgB3nO9BvrnAFt7Rwaf3yDubMI30TnB/rGXx1oSxHN1 on0DeBJcx1w1wTZW9bV0BMtR/VflHCTHeLIkzQev3D6F/VdA3NyEzone4HNZDbBMfedwSied dNL5y2n8qvGrxq+gMY35AG/r+1/Htmfbnm179ldLkc6/ivd/j/OBhAzOLJCjc9C6TIBPflsh r6eQWFKN14NAXaj/pkZBhnAtt3cNCMqR46rxOdjL2zMp9SC4cZawsBMQpVrCYwvB6zyvC1qP Q54HfsWKB0NGNTR/wDLI4PS95zIhQ3tbUmhPUL7mU2t94CFr5U7wvE1pLU+CbazlJ603eOWy NVBngmu3vcqbhRDdNPLu4wPwUaFcD0tuBTFW8aU+PC8ccelhP/B8Zd4wHGDeNqvxM4gvlfpK HJi5zVyiJyhRWif1FQSUCz4VshNCcmVanssHsnTO9SC/H4QdzlE6rw6BHTM+z1oPvJ2BvqHL wWdehs8zPwQ/NeR+tsYQcDy0TE4H+Okh1bIPAP9mGX4MWwE+AQF1Q7zAt1Pg/kxbwDc4oHXo cfC7EngzpAw4KvjeCnwBji982wedBd98gcMyHgavUf4/hOYD6yLv24FbQA1zNPOrBaKEtYN3 DrAesJfwOQDqUWu8Yy5Ya9nuea8CdZzV6fAFGth+8voVzPVKDXUOKOXVI9ZeoLRQX1gsYBtg eWZbA/YX9kjHATBamWfNMBCTtPLajyAqqweVvaBFWMLUHSAiRYQSCPbp9ite48G7uXcmnwSw e3lb/D8F2UNksewCZaDR03wB2lMRSTSw2/zIqYI73JU/riE4M6X0TpwHSdXiFsUOAmeHlLZJ PqA8V5Yrc0BZqe2xjgJjgTnVXRlC2gdcdSyDTPmC8wfWAGWAstymgf2pvZOjA2R6kMMnhxUy Xs12PttoCGgYUD5gF/h5+xX2qQCWF7bHWgYIqBdQKuglBJcM6B5aC6yGcsM8Clo+7aJSAsyr ilvEgjFL9NeHga2Ptba2ApjAaBqDPkb0YiN4hrCT/8WfeE0nnXTS+d9K1jdZ32R981dLkc6/ iveuOFs+178LGAtmq+ijlibwpq1rWco60IIDnSklICE3B4w9YByJ+N51GALLei3UYsG2Tf1F 8YHYsfLU40RwZPDv5XUIkk44p8avhfNLbl64CGhfWieqvcFxwK8Wn4JzfEKc3hj00lTkZ/CO 8nml1ABLHedpr2DwtE9+6k4GV6bANloDsExK9vP5GIIt2jzZHgoUyJqlQkOQg1KGKymg7TWP iirgaqj3NnKAp7B8IQeAo6k6ipcg87NalgJyc04bB9p563K/z8CobG7wvAHP4uTByddBtpaN 5A1QftQGWfuAes760CcLqEvVYo6loPRXW7h0kAP1G0YjEGVoaLQC0UTNSSWwJKorvL1ArpW/ eEqAWd6sYRYFpZ6waIvBTKGoUReYJGorx8CeZP/U1wLCJtebZ8GQfIk38J0oYo4F7aP/89YN daqYJDsAr/FyGSBasUpdBeI2UbI5aM3NZvovYOru+MRZQGPlS+tjUPKqsdoAMCbrYXjAbE1D egGTZD/ZCKgj94sMYFwzGhgZwaigP0wZBEZ9fQfDwH3H88o5BZJnx8VEZwTbLftMW0ewd7P3 cxwDb81/W3BPEH5iujYFlN5mB9dIMIfJXSI3mJdlfz4F2yQ1o3IMksu7qnj6QIw1bktCEuD0 beaYCpbb6i/qAvC54Hs84Ab47w/+IdMVUB1er0MHgfJUC6UhqB/ZhljKgTrXGCkBWVuUklNA maP5WKIAQ+3nGAqewJQlSVvBeS65aYINAif7NvXdBmo+tYi1GySPdX2fvA6MtkSo+0AvoBt8 A2oetZJdgLrMOotCQGFth9YXgE5/dZCnk0466aSTTjofhvdOnF9djv45YT48Hqsejm4D6mbf InwO9i7JdX06gunl7CqPQuJWtyUlDkyn8429A4ROcDzJ4QVR3ybG3L0OearYutrzQHIGraqW FWLHufIancBITOiWfAR8i2br6Z4Ijkb2X1y3Ien4tYnOneCpbC2i6RC6xvdtYD/wak49+3rI 0F5d53UcEp+7+0Y0g+rbSrnq3odcuzMMKbARntjvvLibCVwD5FVTASNUjDAKgbGSVfodkLXM odoBkHnkUFEXcAo/NQ8oH1uWOCqD7KHk0G6BrYRjju998Kzz5HZPA62eNVSrCkpF8UyrD2Yx vVJKHSCACKMh8LWZKEaDckdtJdoC4WK21hO0k9b6jj5gbJAx7AJrHutkiwLyrh5v3AP5s9Ga p6C5tVViJbh/1i8kR4A5Rz63DQFtOkPlzyBbG4NTKoGnnHnd0xvc4/UJzmwg6ikn5DywD7Jt 9ekNzhmusOSRQCclF3VB+5Z2tmggj5bZkxuEt9GVbqDqamZtGBiDDZenHZif6h95HoBanFnm HXB2Ty6a2Bji1sVVeXsYXD1c050FwViuV3PmAmsWS3ttOLimu26KkpAUHDdcGQGuO65xKd3B dCuGbQrQyOzn6Qkp9RPjE1eD70u/k75LwPbUl6BDYFthu2crBZYgSy6LCfoRWcEoDY58jn72 r0Cr5+jq8xj0H+QxskPwg8y1rDPBtSR5j+dz8FT3RDo3gQgXLk9JcLVNqZlYBcwJnBSnQdmk HE9oDa6qKbUTaoBvmcDh/hbw6u8z1ecsJOWLb5x4B8QxI0FfB9oaYSUAXJ+6bNQF96cp5+Me gOlWM5ICvgPVgt6Z/2RQpZNOOumkk046/5G8/+voung1S2wAthR7QccXkBKr9zb3g389W13v 4pBnf856XoXgfubnt6LfgvN08o/qY0hs4QyOuA/WHfaNShjEHk4M0jaD3ihljnEHkh4qRVOy giOfWsT3JIjbz7ck2yG+Q8prjwaeO/o+nxPgshslnBkhe1LATvcjyNK1XIXATaBcdjSJ+RiK 9NYbl30KZRoUGNW2PniV8ikaEgn2U1K/Hw5qqyvdxTPQV+qDxRtQ95vZxU0w2opR7mlgZpXF zL5AG7nGyA5yhbndvA+Wby35tcbgHmD2MYqBWs8+wR4DyjatnuUTEPPN+XIXiI56Zk8s6CeN zuYNMBU5Wb8E6k2Z0dIPLCetv1jzg2ejp58xEdgg9iv9QD/hbqEvAqUNmZQ1YHzqeRm3BNxF U/K7O4LaUX3rNQlEWWs+5RCYZT2Rrq9Ajjdye2qAcZcb5nJQsssU0xesty3rrePBaUnxTfIF PUyvnHwItB7aeksIuNcZV+V34N7h2u3JA9aFmmIbB8plpbh6FozF+lXXIbAXtFxX94EzJrF/ /HRI7JjQJHo8mAv0JcYj0Hu4eyf/BqpLidF+A7MQucVl0Hvohww7iCZyiCcrJM94U/+VBrZQ r7XeT0HZz2DhASPck+KJg6hGb9+m7AKvNp5RRiBosy1V7QGgjFR2asvB1tE2wWoHo59Yqg2D +HKuScYIMAPlb7jBM1ef4MkE2izrdu05iH3G10oFcH/t+VW/D+7+7qHuceCql1I24TCombQ9 tiGgepSMshHoX7ilezC8WvP63psASAqMV2KbgzW/Wk7mAds6+wOf7mCpq4329gJX+ZS7Kd+C 9kztbAOUXeZ5VzmgCfAB3hObTjrppJNOOun89bx34myc01daikPITUdRuwkvYxNaebaApki7 ozmktPL0Ng9ByjcxP1kE+F3xy+2XBI96h2d8/gw8LVMS1S7g6+07T+8AUjWfqCNAPDI6xM4F c4c6Tj0I0d++nKJUhNDPA3+2LwOfGtlWmuVAeZjQ36sn+Laxhidq4Mn9tLg5EdrXbVRx8qeQ 9+cclWpMB7e/npdvQM2l9DMygDgRPcn3BbD77XFPHrD2s5S1PgJjpfpYvgLlhtFF6wxiP4PF KTAfmqM8hyDlcMKFqMqgB7orOwJA6a1EqVFgbtZe2BuA+VQbb/sJ5ESjqiwAtsX22vaSYA1U p1m/gZS8zlbxp0E2Zii+4Llh7DWOgyosvbTsIGaYE9y9wKzlbuu6ATjUtupIcCYnnk+4A2Yj 44H+GKyR9sIyFtyexEdvKoFtvr2a/SX4TPXrEtgL1CNKcctq0EcZDw0buOu41zkLgvrMEqvM BFGaa8YhUOZrS233wdNMOlKug1aHZkp7iG0UvT8iGSx11HjlPJiZzPv6dUhZxCppAbOaOc3I A+o3aoLqC3TmrNIZRBfxEzrohc2RxmlQ/fQL4kvw1NEXGHnBbGru9EwDM9J8IoaAGc4qMRIo QX2xGqw3LHusn4PxiBMyAjxD5FUkqINEA2U6yGSJrAgyXO6Wc8HdxBXjmQtmayXCcIN1tPWc 7THoAe4aZjy4luplYmeAiNC3eMqDUkbtLp6ANkO4tMygTfdvGjQBvAICXKFHgEfmF3IVyBH6 dL0KmAXdPxuTwTHHawMmCDcVPKOB9sqv1iSgsVghtoJvLt9HQd+D55DrvlES4ru8tb8eBsT+ 1SGeTjrppJNOOul8KN774UCtvv2mPArx9Yzxkb1BX+0+7boAMRWjM6V0gxvue8MSc0FSA9sO 6sPbx+56L6dCWObALTIMMhXOcFdZCklvvKYm3wP2sVJ2AqWb6m95AkFdLIc9U8DWTM1vjoMn VRMDYm9CwtikIN0Bro7MdJWEYs9Ch9V6Dv2LtZq57hbkmpg9T60VkPzY+cjjA+6sno/jfoYX j15Uu7YMoprdzhI+FDIm277zKgs2TZ2p2kAZrJziEciHopVxHsRaZZcyB6RmRvAU5G6juT4X tOHqWusz8Nrteyk0HHy+Dvg6pDQ4VO9k77pgvejltowG233bR2oJEEivxDvg+MX/SEAp8Lnv VyWoBXhdcVSz5QRboDZfLwPqEIT8FeJHxH3y9gQklonfGV0VlJ/Vl1o86A30OR4HpJSNL//a AeYevb7nEcgJIlz1A6OV9DdXgT5S7+G8COZ01ssHYC9rv+ioDFp2S23rftCOWw46ToO8qfxi eQvyKxFrkeDu6azqHgd6Hc9AdxlIzJLwKOoSOF+lZIgPheT6zmmJ1UE+E7q5Gsy18r7cAKKx 2CK9gRM0F3vA9DFaGGvBnGwEeXRgvN7FPQyM/p4Rug3MV+YKT3PwHPLMdHUCGWi2EXfBVdoz xV0XrEPsV3z6gbZd+cq6EXgpPWQDdYdWV+sCnvN6T/0HcIe716WMBrO/EaPfA7Mc31ERLL/a RjoiQD1l/ca3JLDffsHyDOylvfL71AKvRQHPMzwH72p++UKygK2nJd5WACwTLK9tPcHl485n /AraAKWJ2ha8Nnk9trcE7zy+LQKjwL96kDW4C3hH+Vf1iwdLG3sT2wnQDsrmnkKgrrZVsnyg j5/8JzM9z/Q80/P84/LU95j+u0j9ktesWbNmzZoFNf1q+tX0S/vyV+qHTV68ePHixYu/Wmv/ 77B69erVq1enfcAg9QuQA28NvDXwFkRlj8oelf3fJ8+/2q9+z5//p/Pvjtd/F1ufbX229RlM fTv17dS3/7j+P82/0/l/g/dOnJ0226j4veDwDTjv/QwsT7xLylaQGGmUizEh6vPoH96uh6yL LIn+5yG2QnxBZT345LDtz5wDvLPbv1MuQv4cwU99osE/1jtFWQQ5e/v2DZ0OWoJWSP0aLFfk Cuti0CZ5XP4FIer863uJjeCjGcHWAl9Cm7vd7009C14zgrUsecH1ozMmcQ6IHDJSLwVx118F ve4FamfPff9roKxJCDMWQKbYzLrfJlAaiwdmJVCfqo9tr0AOMVp7WoAIk9X0T8A+yPbUOhu8 ZwbOCukMfg1Du2X5EWzz/Bb5ZgQ1wfbUdgYsXRxOr/XgeyHQHrIc3N31+UmvINEr7sLrbaBe 8MxP7Axu/+S6cQvANTg5V1w1SC6R+HX8IcAiN5rnwUf3rRo4EtRb6jw2gHLHulxtANYdXi6H H9i/cuz1qwc+KwNjMoaBdx5vH5+TIHvqLmMTyPyin9oNtG1akrofzFpmD09tSBqaNCL+K0hZ 5JLJJSF6/uv+L8rCy3MvCtx/ASlTnU+jD4DrI2fZlIWg7/bsM2qAuck4ZhYF1silbAZ3CXes ewp4SnsU9xUwrEYJPTco/ZQQpRGIysIieoHZlnLiV6C5EqvMAgLEFrEGtKlqf+tGUI+IUcIL POU8lZI/AuWwmlW1gm2vLZf3ddBQK2k1QBQVikgGZb7WSDsCaop9lb0UWB9bu9lDQO2htlBG g6yrH9Abgjgt4zx3wTLelqya4DjgVTzjIDCbKLPVtqC0s863h4M1oyXQPhWMTe5L7ofg/Dpx a9wloLqc63kJlGeUswu4LM5G8UsgeW/yvfiW4DrhvJhQE1yXkiYnvQKzr2dnSizYunt9bfkI gscFvw797q8O7389qZ+8/as5Ofvk7JOz006EPc72ONvjLAxYOmDpgKVwbv65+efmw7dtvm3z bZu/Wtr/fI4dO3bs2LG0C5HqX1T/ovoXMHTt0LVD18Lprqe7nu4KMwrOKDij4F8t7YfjP8Wf 0/lzHGl7pO2RtmkXQNMOTjs47SBcWnhp4aWFae3+t/p3Oh+G906cvU1X34yTIcD0sea4A2Fl /U6FNYRa93KsKVMQ6m2v/rjcWQgaFvhIpEDpb/IeytoZ5H6tjuEGn0fe3wQ9gGd5E2clNYO4 XCnelmZglBHDU3KBslmssydDxuUBBTLVgay3VN+YqtDgSsEdJQZDD98+1+bUA2eg7GBWAeOa +1FKf9DmaDH2E5AyIalYvD84etqXKOcgJvp5vpfFwPaT1W6NgkKDSkWWFmDrof0oPgKtqNhm qQKymRlBBzAiRUP1e1BM7Vf7SlC2KY/EXZAvjWzu38DwdtuTu4Dxq7NuwhvQjzlbJdYEd5bk ZokNQRpGJsty8JrvbQatBFfm5L5J9yAlY/LbOAOM7/SP5FlQWij1rKXBddMYkzIGtEe2Vdpz 8MoTYAlOANsF72e+k8H3QVBc6ENwJAX+EroYLDtsbx066Em6on8K5lDjorEEhGk+Mr8BJhol jIrgdjvXO0eAtZ+thqUmaFe0HZZ48B0XtD24L4TVzOooNBp8h3j/FvolmD/qI1Pqg/GRsdmz AFwD3YGuG+BW3WddzcDYpi/WT4DpkVIvDZ7hehfPJNB9zEMGYHSjpnwORoq+xD0bzJfGJfca UJOUPWImKNfUPZaWoOWyxvqsBt+gDJUyvoZAM/izrBnB2tQ+27cAiEX2mV5fgJrZGmaLAy4a 34kBYO3ER9YRILOJKHUTyEl4qflAfawdtxwHWVIeEfdAOWXk1d+ALOYZ4tGAikZd41dQtygl lAxAnPq5PTeoU603bSrY13ud8B4HIZ9mnJOpEtj7Ob7xDwOfXv4HQyuC/xr/K6EhoERpjbzu grim5rLMA+s12xnv1mCu1UY6coOlsH2jV7UPF6ixsbGxsbFpn0xtsL3B9gbboenEphObTkz7 5Gtqu3379u3btw9atWrVqlUraJ69efbm2aFRo0aNGjWCZdeXXV92/R/383uVp79fPjZ8bPjY 8LTfvS/1vtT70j9ul1rpabK7ye4mu2F+8fnF5xd/9/G3nNpyasupvy+fvbK9sr0ytDnc5nCb w9C5U+dOnTul6SkVXdd1Xf/zdvhn9fP3y2d0mNFhRgdoHNY4rHEYfHfkuyPfHUmzW+p7c+cU mVNkTpG07f+sHd9Xn3ua7mm6p2na78/KfVbus3JQvl/5fuX7wf6p+6fun5r2SeL31efc03NP zz2dZq/OhTsX7lwYXmR8kfFFxn/c7o/86l3j5ff8+V37iYiIiIiIgO6e7p7uHmjWrFmzZs3S 7PpHfrLq9qrbq25D+4T2Ce0T3j+OP7ReExMTExMTYfDgwYMHD07z59Q7Oql6+GfH96H8NZUz njOeMx54Pen1pNeT0r6A+Ff5dzr/M3nvxNk/p/9Br5yQGJl4MmIVuK8k3Y1qA/pF8PwIYwd1 TVpXDj5t3Wh3//UQktHXLyUZ8vbOUjfzMMi8QBvgewYyNfRqYV0BGbJn7GScgleGO9B6G559 nHgvajIoeV2l7/eF+mpZS7sa0LlDH2VuEVCa+5fwEyBKeL5Ri4JoqwaqN0G/JUcZp0D6mZ+6 n0JSP89i5w8Q2+PVm4iRkOP7EqeqvgHvhSE5so8FR4JlrRYK9jyajyUAjM5yhzkfFAfexieg ThT9xAlwPU6u53wLrnzO/fpzkPPNGzhBl64g1waQNr2aZxYY+/Rv3TdByyY2GH2BfdbKjhjQ 7tr9fCzgwKuanwP42HpWOQTWHY4qjuPgE+KXEFQSHBe9dwdMAts4+w8+EWAJl/VEbtDvpvzm mgtilFbe4gF1n7WuowpY8LEFBYH1F58CgSdBDFC3Wb4C9xxztdocLM284v1LgPVXryMZhoGX 1a9f2CnwOeybP2NB8OkQWDqkOHi1DRwXOh+yDMw9qeRXEJKYZUHucAjaGToiux8EbQs9mf1n 8GkXGJWpOlgK2ZJ8AkBJtNT1ngO+df0PhJaHwIUZKmW9Do7ePitCNfB9FJQ32y8Q3Dbr6MLL ITh39rbFNkGQyBSU5zsIzho6Mu8TsLfyPpVxMojaShm1GFhqq8fFp6DMlV7Gr2DsNSoll4SU pykdYz8Dz1cp3eLnArP0Gs5OYAS72yWHgZJVBpg1waihr1eygZmNIPdCMFvIchYF3BXcWY0o 8Kx1/5TUE4y+bnfKJFAKyIJmHRALucs84I4wZTtwF3PtcjcCfYcnSl8NMrvpNueA4q2MkT+C nt+1ydgIqhVvcQm8clgsMuLDBeq0A9MOTDsAIc9CnoU8g10vd73c9RK2Pd/2fNtzCBsfNj5s fFpFde39tffX3odPS31a6tNSabcsl19ffn35dfjpwk8Xfrrw5+WZmGVilolZ0n4vKr2o9KLS /9iuZo2aNWrWgKXll5ZfWh5WrV61etXqD6eXVMpeKXul7BUY7j/cf7g/HJp+aPqh6WkJTLY3 2d5kewMTGk9oPOEv+KJD7eG1h9cenpborB++fvj64dB2etvpbafD0n5L+y3tB2vXrV23dl3a dv9qO/4ez188f/H8b6a0dOvWrVu3bmmJYLt27dq1awd3vO543fF6//0F1w2uG1w3LaGpta7W ulrrYPrR6UenH/3H9n/kV+8aL7/nz+/az/S46XHT4+CTx588/uQxbNu2bdu2bZBtb7a92fb+ 8/pYs3rN6jWr39/+H1qvCxYsWLBgQVoCu/Plzpc7X0L1NdXXVF8DM3+d+evMX//58X1oRm8Z vWX0lrQL1d/j3+3f6fzP4r0fDhRrgw5GLQN7JcuOwDaQvDF2p/sF2F6ywOENuyfuGjHrGJhb nD0SRkK+p5lu1JwO1iTXMvdweKwbJ29OhiK37GOqhkHyN8IdUwmOhl2oHp0LClQMHp1zOHRZ 3aXtVzkh87l8a8vYwN3X863nZ9C7uHfoS0B5pL6Rp0DJQagaDfo6T5gzAMQwM9LwgM8q+/qg apD3bpmfqxYCv31ZvAKLQ1LbyFmuyZChUcB+3wqg1Y36MbkfyHqudS4XyMfmWsqAckMbpg4G MSflsPMIpHyWUDt6Abg91h5eJ8BSTHvFPHCaKTOc60BroF2zXAM1Sl6VOcEcK11GXRC7RLDY CvorvY77V7BYLddsDjC+dK5LWAP6t0mxxhAQuvpUWwfWQfYePj+BGKresRQBNcH2g7Ic9Hv6 Ulc/oKJxw5gOLJC/GblBhCuh2jIw7sm36jhQ8iqnjVEgPuIZh8B4pO8RV0EJtnaUWYC9yhl1 Gphz9NzGPdDuWvtZvwfvbJYNoTPAq4UZGZIESg+Lr9oa8LjnpVwDz2z366TPgfPGZPkZqG6t m+gHcr74RSkDlinKOLEKpFv+ZFwGo7ZURCkAoasVQPrxXOkIen2zLUXAaKF7uXqAraD1pVIU uGl0s5hg5DWcrrJgv6mFaRKML6yH7Q1A2YuvCdg/sdQXc8G4ZF6XdUCXeogZBWYxEWUEgzJJ WWcZBWoZrYAjEFRT3NGug+av1NLjQS/kee0eAmI9X6rhoJVWs1v6gesT1zWjIzij3XcNFZTW SgPLHDBUs4DcDkyVTnEDRGXVY/8exFVLNbMneHvUxvomsBvWLmrMfwVJ2/cP1NPdTnc73Q12 ZtqZaWcmUH5RflF+SVvfrX239t3aQ8OuDbs27ApH8x3NdzQfXO5zuc/lPrA+dn3s+li4d+He hXsXwGxoNjQbAj3pSc9/3QEm9QRrCbYEW4LBU89Tz1MPuMhFLv7+dqkVpqdbnm55uuX3+03l 4sWLFy/+TX85puSYkmMKVN1VdVfVXfBLxl8y/pIRFl9ZfGXxFRjNaEb/64b9DxSfV3xe8Xkg FovFYvF/s3yr2Cq2gqeMp4ynTJp+llZYWmFphfe347vqM1d0ruhc0UAQQQTBoJWDVg5aCdn3 Zd+XfR90/KHjDx1/gCk5puSYkgO2s53t/HkaZ26cufHfvL6xRVSLqBZR8PPYn8f+PBY4yUlO /qO8v+dX7xovv8e79iNLypKyJEzMOjHrxKzAfe5zH+purru57maYwhSm/F/00LpV61atW4Fy W7mt3Ial55eeX3r+z9v/Q+v1aPzR+KPxsO7SukvrLgGd6EQnaBHZIrJFJCydv3T+0vlAE5rQ 5I/H96H89e/j/4/Qi+vF9eL82/w7nf9ZvHfi/Jv1t5ZuDbJG+7Ux2oF9qvKVOQ/OrH9R8PJp ON7qcftjOyDftaAVYWOh0Li8twpvhzfd8Xu1Gq7Uunf+zTzI6sjcXk8CHEk+Tg98VCT/Z3kn QrssbVcMqg+BlsyBpeLBtTVpcvJBMBItb+VZUNqIq9rnIL8xVxn1QSmo5aQXGG2cCcn3gana K+slUA4oa7wPgHHZOev1PPB8n/KlbQIE3w3zzdEFsiVkm5d1Alw0n/wQtReUM25DaQ5mR7OP mQhaHUsZ27cg9nmyexaDmsE+0dIILI2VLiIa+FIuNwCxk0LKM9A0ywz7JlDnOtp6vQVRU+/o EaCMNIeaNhA/O/XkauDJ5XrmnAOmZrbzLAOPTV/p1ECLVzsqq0F/bYabl8BS2dHSuxAoJdWb Wk+QRcxushPod4Qm84OsaBT3LAZ7OdssJRgcE+3t7cNBRkpVdAOs0s/sD85+njkpx0Av5mwo WoNS21rRPgyU8+KuugW0dbRjCliv2CJlOIgdzDdDILZ5wsdJWYFXxhu5ErQrWpT1EChh1kbq AzC+cE5OuQZyl7ndVRSS54pHHATVkOf1rGDZrR7QCoK4LqeaWUB9RQWjNSgPZHmjKKj+6ueO 2+CVrI1Qa4KYpj0xDoFsQKzaCfw/8isSEA3ObHo5boARYmwzH4E1o32DNhfkApnPGAOelu5F pIAryrPC9T047LZxWhMQJ4WpPAB9v2eb0Qe0E2oNsRXU/LYedjuIxzKPfAuis1JGvAHvRFlQ +Q0CJ3of8R0Ozo36S+MQ6OVMp/IVyPz6U1ka1BvqFHMhaBlsR2ylwO+45Zw6EqzSFiQqAPDZ hwhUWUqWkqVA26ft0/b943pxSVwSl8B8bj43n8Ngc7A52ISQfSH7QvalVZKqVKlSpUoV2MEO dvwT+3XPdc91z/3zcluWWZZZlr37dnOKzik6pyh4Ong6eDrA57bPbZ/b4FXjV41fNYZNmzZt 2rQprf35nud7nu8Jt1beWnlrJXQv1r1Y92LwhfcX3l94w8GtB7ce3Aq7YnfF7or9cInzP6uf v0+Y/2h5Kqm3xN/Xju+qz9Rb9o/7PO7zuA9UrFCxQsUKYL9tv22/DYEDAgcEDoA3zd80f9P8 Ayjy71AWK4uVxWl+//f8kV+9a7zQkY50fP9+UqcGqIfUQ+qhv2l3WVwWl/943Kn6TeVD2f9D 6TUyR2SOyBxQc0/NPTX3AGUoQxnAihUriGlimpj2z4/v93hXf31XAjcGbgzc+Nf5dzr/b/Pe ibN7Y9x3lnyQclBrEK+D9WsxLaAE2IcaTYy34Ped9+KcI+BtfuWo4Q83yj1+eCsRMucKvhkw E/yqh37mUw/eLHOH3E6EKgsLlqnXCjoU+DhxcAxYw/yK5I4Az/qU18kPQLmlOkQh0MLkL2pv kD1lNr06mHt4aZwE5Q6zxGVwr/AcSokArzl+EcFPIHLIywyv7oBlnqWF4QvWTl6R9omguC0N HZUgbGX2ill2gddR68vbRyHhhrutrT8Y4+VikQBeb6x5bWUh4Vhcobh5QIxzurM8WIb4f+9I Ape/K4ueG2wt7AFeDYGx4mMygWt2XJk3D8FWz/6Lz2EQW0RW7WvQZlrm2V+BGKz+rD0FG7ZA +0jggdgtyoFYbQwwsoLxvV7BNQHUfEqQGgHubO6aeg6wLdeqaPVA/dZqtZkgP5HfqWuAAsYb vREkDIrVol4CVY2Drj7gOqxXkjfB/sLnsl88aM9s3/u0AEsdi6ZtBa24es96C1hqrtcDQCyR W9zfg/YrGSytwHFcK2MWAltj+0VxHbzueT1TS4IaL8M9uUAOtp5WTXDXcG02ckGKl5Fb+oJ9 lNd933yQctHTljjwrOV75Ri4LupbdW+wtVDzqe1BfaD+bPkY5EJlktwGjhTHIXsTED/Jemo1 0EvKME9d8D/iyGLJAloDtZM1FPTVZndGgngoKigGyNmWFPEpeB7rywkCy4+WmVoimNXNivIX UCY4LllOgKeDZ4OzBKhNtdGqCqKaXC6zg9nUXGkEg8ikvFUlKLnYqRUC72zESANEeUabzcC6 kG+UX8AdpC8x74HrhvmdEQa2p8p9+S14jbRms5b/ryD5+P0DNfXtECsGrhi4YiD0U/up/dS0 9cuWL1u+bDlU2VFlR5UdcGrOqTmn5sC2a9uubbsGGe5kuJPhDpw9e/bs2bN/03EpSlEKuMxl LoPluuW65TpERUVFRUXBgz4P+jzoA6xgBSt+X77Ut1r8USL4z5KlSZYmWf6mYmWdap1qnZr2 O2fOnDlz5kz7fTvqdtTtKJhXfF7xecUhqVtSt6Ru4FfZr7JfZYh0RboiXVB4duHZhWf/ebn+ rH7+LFevXr169eq72/F99VntZLWT1U6mdTery6wus7pAwIKABQELIDJ7ZPbI7FDNWs1azfr+ 49z5auerna+gPe1pD2wJ2RKyJQRKXSx1sdQ7VBJTedd4+XtS/fld+0lamLQwaSHs9d3ru9cX WtCCFsD+lvtb7m8JTGYyk/999v/Qes0yIcuELBNgSvMpzac0T4unl+Nejns5Ds6OODvi7Ahg P/vZ/+f94V399V2pdqfanWp3/n3+nc7/LN47cfa655c7eDZk6eZXMGdBKFkh9JNcdSDwsv9B jy+cM3/b+iQJLo2KbHX7LOibQ2t6bYQgwz3K7Q+F17vnOeKhzraGo2cfhaKB+XpU8gfnEjHO qy+IoeIba1+QkWKhXhdQ5CaSQX4kyjAMRHs5VOkCarAyXS0BepxspiSBo5Vttk8HiHv8+kTs C/jt0rVsZ2Kh4KBSc8q/ATWD9ty2CuR+EPchy65sDbKuAu9A+3L7CVAyp/RzzgKmGQeVeLBE WDLY5oI1wb7JsQGMwpYR6qeglyNCXAZvq888v/Gg7/GEu+uBMVjv78kPjqxe4f5rwTNUj+QH UKpqL9VuoJa3RNITlAHmDDEfRH5lj7IbjDjjml4J3PtdFVMegvpUuaPtAnlJ+svNQKzWSvED uUdMkp+CZ707IrkRcFOJVs6BMdt10d0eZBn5m6gJQrWG+IwGr1degy1+wCq+NbKDucQ93lgC 7uum23gMnsaKt+s6GKf118ZtkNf0ynImmGH0Np+CJdJiagZYe5BfNIfEEQkTk56AUcIIZypY PlcPymagm9w2DfB55j/F/zU4wz2DlWiQCYqhj4TQ3AEL/e+Ar9vWQ8kPlq3aaqUIiBBRVKkO nkvuWfqnoI4go/IJiDXqBUVCUnn3Wn0gWEYoT8y1oAxSy6jTwSgq25tXwPObe6JrCFCWrWp+ 8Ix1n9Z1MDN7Brgag22ibZbWHITdfPr/tfeeYVJV26L2u0Llqs65CU2WHCQZSJJFchIBBcmi gKCogAJKBhVEQIICgiKIBFFyRsk559g0dE6Va4Xvh7e/9uLmbN2wj/ueU++f+cywxhhrzZrV o0eNORerQbxHW/0rUFcpXZSbYCprnCKHgtRJeNcwFpT66lxtG+hThU+1viDc1HuoMkgnpQvy AtB3SyvFcPD+5NrorQ/qZTFE7wTqL3KKcA7kIcYcaTMw9/Es1IJNKpNGTxo9aTS0vdj2YtuL hf0VfqzwY4UfCzcrbaq2qdqmatC3b9++fftC2LWwa2HXoIZWQ6uhQfl95feV3wcz58+cP3M+ DGMYw4Ce5XuW71ke+sztM7fPXGgwosGIBiMebleBnO6Hux/ufhi+5Vu+5fHzw6gfRv0wChjF KEb9sb/gOKmLMy/OvDizMCLl7+/v7+8PddQ6ah0V3iv+XvH3iv/rdvzV5/OoFGy6+qvz+KjP s1vZbmW7lYWMHhk9MnrAj/E/xv8YD75ffb/6fi087m/UmFFjRo0Bvud7vv/X7/N60+tNrzeF lnda3ml5ByKSIpIikmDKlSlXplz56/L+6nop4MHP89zIuZFz/4Ic59POp51PF+baftvp207f doImTZo0adIEpNpSban2f9/8P+7nOm7cuHHjxsFHUz6a8tEU8K71rvWuBcsyyzLLMhiROCJx ROJfl/vP+Gef17/Kf/fnO8j/LITf/nPV9Tp16tSpU+evC3g2qf/oYn2h7vfFT9bcBu/s7X7j tTQ4nXjl9TNzYUn5n7suHwDiBfvbpiZw76f0Bclp8HLDWk832Agd81qX+fAX8H0b6GaeDeIa 22HTJjB8ZbthjwVhsDZY94Hq1X90vgXiduFty0TQXxCWytEgHudFZSuwV0uRrgE5xuLyTcjt lD7wdhRkbU49ltkd1DeVlzKLQ+LIUk2rOMC62tIkaiNIm0xjpb5wrfqBN3Y44SPfR9XnToHL b9xPSZsOxgOmkiEnIGxhQs9iFcHZPPun+6+Ab446S28JBoPtVEgPEBzqlsCPwATN6i8GwmeM EVeC2EKqbpgL2mExQ84Ba8/wVnF3QN3necbdF/LGZhdLPQh6tFoqsAkMp+VlcjEw/GIKsSWD tounxXOgKr703GOgLTBUsp4CeYi4VioBukFrrn8F0mF5jmEQ8AXvCEdBM+kJ2h6QvzYut2gg /qDHKZfAV8ZdNK8aBHL9/b0TQZ4n7TD3AuEJqbxgB6GaOEq7A/JGKd8WAvLLxg3GUqBHa9UC 40CYqY3VboP3Pd9o70LQUvWyqhWUa/4T/oZgv2rtY9oLJmyXQgHltNpIygTL15ZdRhOEDbVG GnqAsDAQ728Axu8MV6R3wPCi1EyoDuZihqtiI5B6iE7CwV818ITeD9zp3lWefJBP6mb1fVCK qWE+Cfzhge2BOmC4KB81WEDtpg2iOdBFWMcO0EeoDkYDx8U3OQQ8rTuUJ8A2zC5FuEE7KTwn VwGphnzFpIO3l3eMOw60jcqmQDUwfmUsK/lB6CruEeuC4hfGCvNB+1lpJPYDQjVrYBYYb5kq S19A1ErrXfssCK0f8YZ5FLz5zvtH3z/3dy/zIEH+MynIVf2rOar/qRTkAFevVr1a9WoQdj3s eth1yJqcNTlrcuFpEgWnNvy7+J/2XIME+U/g0KFDhw4degwRZ1KFsPCTcL7mtQHHq8PM5765 Pr0leGoqZ+znIX+mwauLIO7OHZnaGF6ZGd2szj5oV6X6Dx90hNyzOamu3uANTet0eQ8kHnja 1rgH+Aeoq5VFII7Xk5RcEDVhobE3CLliA2EwCMP1LH0BaPWEKfIiYDKzlZVgsgoNDU+Cb4J0 xZMBuV2P7Np4HFxDNs879QbETh3bZNxd0O9W3ht9FfRPeErcCbHXipVOWgFFK4VvCW8I157P 7OQ8CD5DQPR+BFpJXRFiQb5nvGYxgftE7nNZXcGw0vKERQEpWTovLQa1M62FnmBoJ68x3gP1 E22E9BQwW10dSIbAdtf9zEXgn+vd4a8FlpPmVyxJIKRyz2QA7ZTeQ2sJejgfaMvBPyfwlLcK CB+iSGtBWE+64UdQ5gXOBm4ByXp3/4sgDxHz9VXgPxQ4r4SB2E8cKR4H8bD4q34TxH7GKKMD QhaEnglTgKe0ZwOJwBbpmnkQ+CZ4avn6gD/FN8jVCbQYPcF1GtwrPKk534OlvHWczQ2+tUpV dRCoF7WJ6mywzrRdNo4EqY01zugA42XDWMkK8ieyhyVgXCu9r38H3OYz9Rw4e/gbiu+A9LwQ kAaD6zt/aULBsE/czR0QWvsiAxYwHjecNawGf3Hfd4HvIdDS/4k6FaT3NFUZBtJR6ZSYALbp 1vMhJUBeKD4v9gVfT+9xbydwbfIs9s4GpYM4WJLAv9NdVLWAuYvhW8PLIH3o6+drDIFK6see AaD6GOipBOIseYxpOSiymiQMBKfdGepuC6azxh/MfUD9wT/TnwTWAZb28h7QwoRl5omg/qLu F1eAfMF6SDgBgldeLc/5u5d5kCBB/jvZ59nn2eeBM5YzljMW6F+hf4X+FWBF3RV1V9SF6jHV Y6rHPLqeIEGC/H08suNs+cZU3fUihGT7XogCkpffcwe+hahtcYO18WA6p6VmnoaOzuivax+D NltaHxnrhVu7vYPTNLBeTv/a/TNEFqu04MmioC3QlnIahCR9nN4X1BB9QXZHkOzioTA3sIGL wkXQr+m3xblAqPqjvxNIadaltufgduUbRw5UgbtDJnw8bjWYevz6Y2p30Er49km3QfzUm6i2 AFnBL1eDO+K+tjuywDYnarLjCygnVvGW6gj7Z956MfUA+BN8NX0vQeBZX1HlQzD0Ng8N3w/C /pxlWa+AXtZv9KeA/rPxV8tWoI9eQnoPlOXKOv01UDYoEa4LgE/MFzLBvy57R2ooSL0N0wwW MG20/BReHTyvek97loHlkrWV9RCopdW+2lkwVeMzqT5Im6Tl8s/AG+JV9oK2Uf1AXQ9amuoy 7AehFDfVyiC9LLyv5IJf86dro0Doot0MfAxRz4fE2BLBe9Hzrec7yBdzrVkbgU7q0/7hoKfx g7QGLI1t60PvgFBG2ir2BF1XlnmXgq+1b727P0jNDA2Mz4Ojkr2L5TQIpTS33BvUfdorSklQ mlFBnQO+876reXdB/0hbr30H8lXDeGtbEG4IP5leAsZzVvCD9WfrZgOgXNemioOAGnoTZoI3 wveM/1vQTgj7hL5g2GO8aW0Avma+Tt5B4NniPua5C1nPO9vlVAPTBINNugyGS/IowxDI3uds 6R8J4dsdH1ld4Nho3y82BrWt2NXwHmTvcK71fA8mlxAWiIDABM0ivAv6YSFevgLyRmm09AWY Dpt6yzPA/723r/caiEYhgiPg/1LxBdaD4lYjlSNgb2B8X44C8xXzkFAHSKfE+fJzAIxB/buX eZAg/5msu73u9rrbf7cVj4+BCwYuGLgARtYaWWtkLWhgbWBtYIWKr1R8peIrMGHjhI0TNv77 7fif9lyDBPlP4pEd5ye7hDUs0g9yboiTQ2IgbIatpWMLhFYydQysh+4Vu0S8NRAqVSrZt9ts 0DZF50fthLAnznkPbgdbRnRaeQeYngtbGHEPfOGBHwP9QHpeO+9vBeJkfaq8EMS5HDcdBLWv Pkf/BITKWPztwNjR9J55PbijnWpaPTg1+9OrHydB2YUHO2X4wVb9iZ1lNAj7ylA3JAas1csP Kr0PFE9AUPLBmlm0UdG1YD1ma21yQhFr1K2oTAhraD8RtgOcR1zxedvA1cL5gzsZwnKjG8X3 BGMJ80zrKvA3UiuqIWAeZR5kjQR9r7BVnwXqC/5rfhtYDhjKG14A5RX5bVs5MD9hTQ/EAEXU uv754LvkO+6pDsauhufkTyDQP9BKaQxCD2m53AwM70vD1HRQJDYo34I4RXcKe8FQVY6z+ECP l9prR4EeeitPexAihPbyJDDMMs0wvg7GcYZzxizw9nHey94AqfK911KqgNjb8LxxHch2Q2VT DJjspmnGrSCPkNcbu4J/tPeoezCIqdIJ408guYz3TFFgaCH3FiNAnskV5SIYuprfkm4CHfQj Jg1845UB/rHAKS1W6gq0Ey/or4N/uXe/fzGIn+l18i5DdIuwCLMM4k3VwUAwTJU9pj1g2GDE OgA8/fxdA1YItFQrBO6AXEcZIYpgaC3U1qeBtNUYTzwoPrWfuBL0T7TvA8kgjBITjU0h/JWo /tGNwT/AN1ntBfpxfzf1DqiiuFmqCealpiOmsmCdZ55tiQd9r75UrAWmLYZF0lYw1BQqSamg Xlau+BMhcFzOpjQIt0y/Wl4Bj9W3XykKVpPhJC9CzMbwJ4yDILxZWM/wsqAGAv2UWsDuv3uJ Bwnyn0uRtCJpRdL+biseHzHvx7wf8z4sYQlL/tGAOtThX0iJ/Kv8T3uuQYL8J/HIjnMIcmLs YvCODG2enwZFbhavE+gEHeY9eWdwLsTPKJVZMwrc+4Sx4m0Qy3iWus5A6JnSXatOBm6Icw1b ISD5Yr3zwbBL3GiqA4Hy+WVu7gXxeSuJLUBP4SOpHwizOeR/F3hTjJPvg/dLt9t1G/YXX/rW 1wvA2ivnoygJEha8a2ilQ3bfC1PPlAX0S3XuRoC2X/nA9RlIBy0LzUUgtHLisRI2MF8yVBC3 gRzl6GZ5D8y9LY3tLjDctcx15ILL7eqRuQZsVcKLxA0D40vmySGDIafj/WM3agLvaM8L9cB8 yLbc/gtoZdQd/o9BExknJIFkobKwHRSzuojrEHhLu6+WBT1GHaiEAHcppZcCzMJX0k2Q1+tb hWzQGun7A5+D4BWGaz6QZsq7LOlgWWo8Jr4M3hfconsliMOor2wFcbU8yFYb1BfEwdICUDX/ ePev4B8dsPvehejPinYoVQdMm6T3jPNBkjnq94FUX/MoX4HS0L/EtRqkQcbWajgE0n0fqRvB N88z2mcEtan4kRgKIVUcWL8E/TwLWA3uVPcr3lRQq2t1vCXA9ozpB+kOhKU5Xg8pCYpHe9N3 G+QBej1DDZCOCxlCAKw3TQv1+eB9zrdc9ED67Nytvu5gaWBcqr0L5g6inTPgtfjTvedAj9Z3 CT3BvMoQbXwbyBLPiiNAv65WNn4AmYfTu6fNBYrIJuM0UJ4R2kpPQliaI8r0AYR7bWUid4Mn 4Dd6D0LucXe8egvEKsJczxKQnxS/C/kVPEM8x3zNwNTXMkC+Bko5YYl4GrIOZARydkPY9pAI 230wbxA3az4ocbK4EGYC+1rHOkccuGJd1bx3AOj4dy/yIEGCBAkSJMjj4ZEd57uNnP2MbSA8 M76P2hJ8Kekf3HwRPC/kHMocC/nHhRKeTmBaLdW29AblKp/pn4CUr7dgBjBBreefDOJSsbtx OKi6sj+rBuiD1R/0r0D41PR2WBzoL2JQpgHjtYvaCTBNNZY1r4VDHQ4uPZwNx1472T1zB/TM 6DX35echZOZz2TVNkL6iz8fDmoNLcRbJ7AA5+RsqLH8dHOZn7734Cpgultgetw5y6mY3chWB O+Vye1niIfabuBvRiyC9VV4972Rwd8m33toJ7lddPlctsA9y9Ai9A9bJppu2maBnBDq4eoIa Etil3wdDlMnoeBJ0rxAqzgV9LXH6HFCfVor6r4Chh3GcfBwMTuvgiCGgJ2kfiynANW2ecgk0 f2C1awcEhvhOeS6D/JOhpjgSfFnea+5BoI/3xQs28G+ivOkHsL5uPRxaFOw9bKXFd0ALePY7 K4Ml1X5W2wCu6Ypsbguuqd5u7nNgqCLP9mwAPTQQ44kFabDUVXsS7A7zUHMbYJqUadkIuReE fb5q4BDlxaYJ4B8RGMAH4PW6u3qvgmtw/p70XRC5IzLW+gOYGxsyxQ8gMyZvnXM+5JbJnpfv g7BPQt+0R4IqCu+JDUBdS7T4ChgseduVrqA28zfOvw6mJ623DSMht3ruB+od8HcMjPLVBGaL HdkP8gl5ueFdUM7lj8kbBvIMQ0XDPOATbaneHYxPW1da9oOvij/SmwCmt0kKdATx5cBxLRTk 5not3zwI6WdcIWeAdNXSwTgQAgblmOED0OoIz6tVweC3rRG3QWCJ2luvB96WSrynIphTjCni IPB2y4/J+RVKr046apfgifRKo4p9D3lR2W3FY6DfF14P8fzdyztIkCBBggQJ8jh5ZMe50tXK TYudgeSxZ8+4W0LjH5729FgB8R/VNNddBgwzlbHqoFVTtnAChO+EL8WNwDYhyzAHdIOa6X8J hMliGTET9Hechqw8MIzWm1uPADPFr8TW4D/uLJFfAYRxwly1CGgtAv3YCLcv3xknD4RGhpea 1U+DqLZPlaqQAq4a9yelvAqCkLMzbz+EnSxyskQ8mPJLvFjpKGQ+OavLkvYQL43u0P865FRy WgMvg/Era1TMNCgzueTukmFws+X9qLzKkDsjN8E+EdxH8wLpX4Lla4eteCWw1A4ZES6AYQC3 85pByApHR1kG58+ew24/OMrbbodUAGoI+6UiIO8Orxb+KfjvCNHGz0HdpnzpiwRvpZzdGUNB r6b3UV4G4sUrkgDSTmm80AjErUKUGAriGLNoGgzmCrbr9nUQWtRosaSB9S3LGnMR8Oc733JO BHWef6tnPmQ8mX9MiwNnXf8cbQvoR6Q4sRo4zoZ+Zq4C8m7xfe0GGHZIRfVOwE5q+03gKpu/ UOkIakt9hX4FNFUwGLeB1lVTtV1gaiZvF9OhhLF0yYT7ILfUz2gj4WqXFD2/G0gYhspx4D+r tdLKgv+S/g79Ifyl0F/DwiBrQ04Dd3HI8OQezc8Gy1nzeO1LUC452yn1QLdh1GNAPmYcJ88C PYs0TKD+qM5Qx4Nxn+mwKRS0mZqg1AdDb9NEYzwo7VWL9gwE0rQf9J/B+rI123QXAjvVY8Ik yDic1SJjD9hH2992XATjUcNg4wcgRcl9zRfBI7p7uu4Aiu5QZoG6Sb8trANUdwVXMgTCJL94 D8xV/Fdyl0ElS3FTVAAi71uWOpIhZ2TqAP9VCG0fbXdkw3/r6+mCBAkSJEiQIP9WHv1UjVHe Z25fg+qXSkwoWxQq0ST6xQqgKdZIsR34W2V2zK4P4tfmDaYoEBU+UJJBnSsMUGxgrGXOsb8E 6nLxGX0oqK1zV7pLQ6C2fs/eBywvxIfoGyC/Q94GXxEI1cIuhs0ET2P/j/668MyJhu+VMUN8 h0Q1vAn4lDxDWldQ1dzOOU3AmODSyQWxeUwp82wwfBIeEvM8cN02Pqw8+E/m3s8tB1ETY6fH vQgxW+2fqKVBSo4ZbIkE+9GQ48I6MFYLGxOTCs5L6UVudgBPMU/r+I1gNltWhy8D0e56zeuA sHLGXeYFYBsr/KA0ANmqpqeKIJwTzknVQHvLMzX/fVC/VrdLFhAXa5OkluC7J8xRW4JyTKuu Twf9K/8qXzTIzSwtbb+AUFNLUtygu5VnXNtBLeLZIG0GMV6YaNwOHBFKeeeDXlTLcv0KQl3D Dts4UNeqP/gHQqhqqScXA+s563Vbe7CeNyzV64H1dXlqSASoIwNDfM9D4LR/gvoz2GuFHBKW QITDNNfwGuT18PcTp4P/OU9D/ypIKhGz2CSBEqcslC5D7npXSe8hKBIV87Y1DNwvuycHykBW ca230AXU2740Tw9QVjrzMq5D0a+s/dUG4Fxv2x2yB9KNeV8GOoGWrFRx9gFHDYtoXA6GWoay xgRgPymMAO1HPVooBQFFi9VPQOADJVM8AMJM4aB4FmyHLW3kUhA9MHSIRQazZk60p4OyLpAs DAFd54oP0Aepbs0D/izvLm8SCPsNm5UUyB/pjMobAoJXd2vvgK+O9rOqgFBTbagsBM9pf0/1 Myh5Pf6EaTSEjU58pkQiBHRPJ7EMGF+z9bE8C7YWET+EXPi7l3eQIEGCBAkS5HEiPqoA6abe IE+Ep8821zoowBXbPMOXkBea2udOG9g74cceK8LBtfPOmeQ14B6emZ39Nijl82PzX4L0Wif3 H1kB6tPuL5ypkFsp51UVUJ+ynA39DpQj/l2KFZT76lVLHghL5euCBKFb7JJxO8RlxLYMeR18 9VxlXO+DeMoxJyYD9BLOQ9oaECdkVs78GcRvDMOtXpDmhfQJPQLCc7Zztkqg75L2GiJByPV/ 4mwLpczFM4rthrB7EV9rdcCxzar68iHUEtopJhQk2ZhrHgruqVlTU0aDGitVMU0AzyFhiO09 OD8v+ePs0ZA31Beh1QbTT6F7E6+D3WSbH9EWsjvmD/cCvq9cM/L3QnbLrPSUVuB+2307dwmo p/2DXafA/L4pIDUEa1FjK9qDqarJahkE6mX9uDgelIuBl1wVIPtSbpnk65DvdC10DoGMuznx 6kBIaZfZJa88RC4KibJNAUtZ0/uGvaCf1p70XAThhP6y6ADHAotmfh1CdjqGhk0AQ7T5ScsQ EKOlGo71kFMqb7a4Cpy9cq2+yaCc8i90HQBfD8/bvvfA95J/pTMCrFukbE2B2E9CnrXMA+UH da0eBs4pvrfck8AdrrbRDoNNN76qVwQtjeckO4ij1XA1AgzlhLbiPIh6LdQQng3yLNN6azuw plg/sW4D6VmGy8NBXyQ8TQBMr4qqPARMJQ2vSfNA6CglEgb+3MB19UvwX/d9o1UGrZwfnwSm oXI868HUUnzf8BkYl0pvyCVBaCFMNV4D17W81/zNwJXlaeLcBr4cmut+kEKNG41VQGxjKWX5 BsJuhvSz74SSR0umFS0JWk85I3QDpE3I2+SdAXGvJHaLdIPpjNZXLPp3L+8gQYIECRIkyOPk kSPOxVzWlg1eg4T6JdRaRsgzZa5MTYDLlY7XPDwXMq5HLxcHw0/T955b+zQk5ZqSiy2GenO6 hXUWgN2GsQY70Mi1LzscAlty1qdvAJPziWWVqkJ2u9TEw3tAaqU/YzkPhr2md6rNAH+jwCZF AfqpV/TJIJ8UcgxfgFBV6C9dBOVYyqL0W6D0kX6ypII5PrJMjB2E8nGnEgxg/DosNaQNCFe1 qnptMCTbnjE1g+z5troXJkHG7Ny6xzbDE788cT2iNdw/kN/bPwgcz0R9XSwPskrfXX61Pni3 OLvnPwfmF2zmMBcI8/357rcgt5uvrP4DaEPSnK6NEPKFsb2mQsT7McOjt4I+TwvRKoB5orNh /liIXBE6J6w26CcwiG+A63P/Tc99yD/qbu3/FDwGT2lvTRBSpf7mVqDdob8gglhLb6MOBJfg /SbfCEIbqrIQ4ntGznWMg9BQ02tCA3AN9S7StoHwnthT2A2W7cZ20nXwlQy00vtCzonsvKz+ 4C+pXGQOeD5V4p3fgX5He9M3HeyfGWcoHSBw0ecLFAfPDP8sBkJcvbDh0SfgZt+M5ZlvQHZP 1zztSQh8rRcXvwDLdNPoQGWwpxpfl8sAw9RtykfACGMXqQrkr/BWZAzkNnDP8drBuEyKlH6E uG/DqpvHg5gs7pTqgTLF3MlkAmNl/25/K9AOCht4E8QhSrJQEvRspZo+Hkwuk0hx8LX2TvFN AmmZMFFMgZzueQHXVghUUSfodSEQo61SvgPDBtNRqxW8Z3xprmMQ+kro4fCFoFxW/NrnoIzR NymAuFafbvgZikWHnRKPQqWrZQxJXcHyoaGMbRhIPeTN9uYQkRSRGa7A8eW/9r7UFKrx9Hb2 /93LPEiQIEGCBAnyOHjkiPOTExrP7fg6+D1qZ2URSCcMJosMjIiYL2+CnPbub/JqQ8YYebKr DISEJS7UK0GgUcbH19LB+G5k+ciRwAzPscwhEPVCbDHHDZDqmCcZh0JkpegaT1yAqFVxz5Xq C8pJ5Qd9KAhRbNRrgfi9fo7VoF8VvHwJ2k7QM0D/TC0rhADrbI0cm0C3+ZZor4JhgMFi2ASS OWlB2GJgoz5ZXAd+0X3XPQvKbC8SF/UZ5E/TU/RQcE/MmpHxBRQLjdguVgLDJsfkqOZgruGI CLsOvvHZTdIqgJCgfWScAuYFtvm2FuC54uss/AR5o/W2sgNyPEK0eRp4PlfGCn1A26q1l8aC Ybt5u80D2pvaCDUNXKdcN13dQDqrZvp3QsKL4dH2UCiWHHMl/H0wBrRFPg2kgHo0kA6OauYF tq/BvNG41NAWLDMNh6VdYL4nHzZ0hxst07Izj4Lfpg9UvwJbZ+tkRylwj3O19IbB3VczEjOX Qk4F19m8T8D9grd69hTwzHRHpdcB5btAH2c+uG56GmthIEVLJ7WFUOyZ6G+i0uBc+I2X0yMg uUl2iLcvZPdwDfbMBWGurqjrIdQk1RdXQ8xcW32xHQhrjQ2lUpBlcdaU8sH/TeAH9T2Ijgxr aVkHtkXmAwYLENBf0zZA+tksKa8+ZE/PfddlA29Nj9XzGXi35fvyvwP3JleL3E4gvcgs70eg GrwZ4inQs/X2chvIPutc5GsFmWOcxTytIO1aTv2cXMge6RztXgbZh3Ob53QA4xmjhzlgLCtu FnZByArb08ZPIWyRPdy2BQwBQw7TIHFf8ZSo7RB/K657XASErjWF2+5B0culL5SZD4Ha7qGa Ca55j5svNvy7l3eQIEGCBAkS5HHyyBFnx4mosISaoL2hLyUBRN0YYTgJ6a/n/JD9Ari0O5b7 Nqg5rPydajeh0tdVlzYaBcpx01z5Lkj1tUO6BdRa3jzXD8ABoRPNgZXqcldp0O7n/+x5HsRy Ea0T7oI0ObBKuQ7aL+IqtgIlxVfQwT9LbeZ7FUwj/P38t0BtoxyTvgQ915RvHwbCBnc/eQJw H6TtYFydWCu2AvC9khz4DPytMxrcLQp5/Ryd07KgXPMaxifrwtkj5w4s8EHdtlW+Kv8y2Dvp i2KWw68rvBuK9oacw3cHXSwNnmF5r6euAEub8FcjDoM0KPCWbxZoicoAbSxoY4yXo6tA3pP6 M+r3oLzra+BqAYbr6nfafnC95DnkLgO2TtZFjuMQMldoLB0C68eGdoafQdrBXO0AJB2KnxE5 CFxHfYKyBDyT8pflNIMik2KPRUeAs4I3VK0FYh35Y9kCRZ63f17sFogGHa8Knqnuy85l4Lzv Sc3dAt6jnmUeL5i3mk6YQoGZwl7TJ2C/aF0fYgPLQDlUeBMsc6RqypdgGmf81GqEq1PuXnNO B9cCLcfXHyy7DG+brkP0ppAKpkWQMj516L0wiF7g6G19EezNbW1Dq8G5wJ3x958D04emKPsw cLxgmG4uB7JBSXANAK2LlibugWRT7gilOejJ6jr/TdCq8oKxM+Q0UocEUkATvZ2UVaA9r1xw bQHnFPlbPQNEu1Bd7wHhgeiace9CYIJSnyyQw8X76nlwpFk+FU+BnqsP1BPBuF7epT0FIbfN FoqAuidwy9cDzNvte8JNoK/0b9E7QthPsSXt0RB1ofS+cmvBk63ppj4QnR5fMqYZhBsT1kan wJH4NYN+tcGNtfdfvRMCdPp7FnZOTk5OTg4sWbJkyZIlhe29evXq1asXhIWFhYWF/T22BQkS JEiQIP+v8siOs35ZSNQXgWpz1ckfDVnK/elXYqDEFNVmqQTlJlSVn+0LiUWqbnr6WdB+iGmW WBbEG/4bvgQQr+ohwkJwvn+r1anBYE2P9VYpD7rTPTD/DeAjd//s2sC9iG8TqoJ+SWykZ4L+ jHAPGaR9epqwEvRaJAVOgvdjX7irNwRqXl+RvBW0hVpfukNOX9me9xI4Tt1ZeXEaeDcd63Gs KliefGJniXNgrlxNK30Q9Pve2iET4Mm3inxm8YBvWJONt69BxfIV3m8dCc1n1R3orQWpp6Y+ +V0nOPWle1icB9yfZl65ewLkhpZ0x1tgmmw+FvYL+O7k/5y9CdwTc45kfwwGn8lubAVCcWGe 0APch/Uk+VOwPGd0hZUH7zfqEvZCTgtpidgcfJGBbfSE6I2OF2wCmEzm8rYPIL+NM9d9FwIR 5ommphC60Pq09STEPhPeQU4DbxPfZH0MOMnLz70CUi/hpv4hSLPtJQ1jwHbd3Dr0E/CO9jWy 9Ac6KJ8GqoIYbdCN1yC7s3ub8j0EFvoFYRKwUx4uVoKzn9xMTEuHwBU5TpsFDqNpo6kMMEup k1EO7rZPHy12B/uTlq9NHiBNTPMIkGHK+sn8JYT9GjYleijEGcNTrCMgV86pkXcf/C5/ef0l yBiVe8f5GfjWqifUyxC1IuQXc2MwiaYP9DfA9mZggHgQMjSOyvtAjpPU8EsQvTfkuCkWTGXl xWoW+Fv564o7wPMc29RyIHUzCgYdpM3aUUt10CvrDQM/grpB66zPhPyl7sqqA6RXTbuNiyCv q3OfdwQ4Tpg3GVZCwtqEYzHbQSgvHrAuBbW1Wk2+CPYjsVvjLkFgjGux6x046DvgPmaCk9Vv Nrmh/30Lu2HDhg0bNix0oAsocKRPnjx58uTJv8++IEGCBPmfgtPpcvl8MH36okW//gqXL9+8 mZ3979NXtmxSUng4vP12377PPAN2u81mMv3eHp8vEIApU3bvvnABLl/OyvJ6/532RESYzfDu uw0bli8PdrvJZDAU9nu9mqZpsGdPZmZeHuTmKoqi/PvsCQ2VZVmGBg0iI0NCwGwWRfGR8ysK efRTNba5NrjWgDfffSlnMdhqha2KHQpFm7QqWqciaJM5px+GQFnlbTUV9Hle1XsL6CuG6a1B NQbechnBHB7+amQtkGsWXVi+IkjT7fVCGoG+zRYZPgY0TbUL74DeQ/ieliDM5bwQA1oFuvI9 mNYKDsd0UOvZbOHrIXxz7WoJteHUkbuNvH44Xjvm80uXoOtoKetWONzfVF6/+zEkXC3xTrFw sL1t6hX/KkhlzLPDPgEJvbX/I2j6RhP/qIqgf6Zn0weE9xKO8DZ0rNks7mI7uDlwTevT30BO hOtgTnlwfpDV6F4mhImxZYt+AKYytsiQxeDpkX88excEZnqaaYdAaC3uYwcIvxpmiXYQbwUm WL4GJVSuYvwY3NvMfeV4kFb6PvP0AF+e+jLfQP5CV9vcj8F8SnXkPQfZQzLu3P8RmGf+Orw/ MDPQStkA4gh5kToFzCstq0zrQRhGB/kE6PmBUO9pCOlpuiPVBc0oOWwtQUkXM8zx4I5yj1Gq gauDx+B5BlilDfL2AfF54Yh1C4TlRtyyG8D1RN72HAd47ru/yt0I8aZoQ9S7kJmbUe1KDwjp FLY4qRqEfukYHfsOZN/1dfWfA39OzlvqWch425uVMgPMWy1fmb6GrBP5v3pvg6e9N9aXBEWy 4udEnAHDfkNN62zgJbWjNxrCT4Q+a24E6nh/87z+kBrjCnd1hkxN+EYeAPrHpGkfg9aTUjQB 07cGlzER1IPCc/oRCPysfazNBd/4wGztF1CeVF73dAepkvaZUBP0IbTyiOBYY02ST0KJisWc ZTSI6Bd1MbIWGD72v6KlQ/hP0c7onWC6LS4RQ+HAwbWrjy2DX05fdF7+BNLiFYN25d/3xfAw du/evXv3bjh16tSpU6fgxo0bN27cKOwvUaJEiRIlCscVONhBggQJEuRfY8qU+fP37IHMzLy8 QADKlClVKioKBEEQBOHx6dF1Xdd1SEvLyHA6C/VOmDB8eLNmheMmTNi27exZ8Hg0TRDg6aeL FYuI+M2ex3nfv1kDN25kZjqdhXqnTHnhherVC8ft2JGRkZMDVqskSRJUqxYaarfD47UG9P8T rLp71+Px+Qr1tmoVExMR8fj0PLLj7C7nLJ79FBgvGBeY54CUGzIhfB94nN42nmIgFNNuC6mg rpC3Mg6EJ8QW+miQ4ggxbAR9m/qO+yUwPl/8+4rnwHjEtt1xDdTa/MR1IIZBYlEwmPSe/qcg 8KzgYyNwUG8s5oLuFQ7rd4DW1FHDQLzp32MoBtbyDd+o9Qbkn81K2pINOWWSd/k7QF5Tdrl3 gzqt1JGiVeHXtpfP7c2AZntDwbtKlgAAPERJREFUTpZ7CbxhaUfNR+H+J7ctmQoY6xqWZA2H 7C4pi++fgOxF9wdcSYFTfW+9mBwF1g8cjUJ+AfcLfFWuPXiH3jxwbBPkj8zem94aQm5FRsRs AmN9i9lfBwJOX/Hcl0HqJ7YXhoK9pzUipBUw3WAxDgPjc3KyOBFCc8UF2jkwlDDedhyCuzfy Juix4Ovo+s73EmSd0gcY8kCpZ8yJ0qHI3JCSxo8hc1zWYvdwkBZwS8+BPJf7Z90CvlJqfZ8Z 5BLyEiEdvOW1UtpzILcQQ3LfhHtazjnXHpBEYw1HRTDWMviMDcE0yVDJ8SJYj3PDuw989z1f ZKWCepJpuhVMQ8zbtBBQjqvvaVWgyHOxlcpOhfB6EbG2M+B50XVBngt5KdkXPR3A1UMb5+8E jhr2c5bj4G0cSNbKgLenupUOEPtGzMKo02Cda21tKQJ3HffGZ7shMCjQ33MMOKrPCqyAHIN3 rd8FwhfyK9aGEFis3aYumGdb5hu/AeMBOVs6DspoLVzsCIoxcN9bDGwzDMOF1WD5UnbIpUH+ UVoRfgVyN/pPBzqBfbJxs9gOyg0tWi82FYr1Lza12H0wrBTuSm9CbETk0PBrEBUe+WVUF7j0 5q9Jl7+HdW02ldodCsl3fWVduSB3FLfZ3/o/i2Tr4/1y+K+oVq1atWrVCuszZ86cOXPmPx8X JEiQIEH+Nc6du3IlKwvi4xMTw8Lg5s179/Ly/n367HaLxWAo1PsgZ86kpOTmQunScXFhYXDg wO3bGRn/Pnvi4mw2s7lQ74Okp/v9igIlS9rtBgNcuODxeP6NLwgLD5ckWYb09N8c6MfNIzvO KW9cNV5/BXzW1DtZE6Dajc5rO2aAP8JXNvAK6CdlM9+BdFY7wVEQmgsDhAWgJ4ineAf0i/o5 XyMQS4pR8ueg/SzckROBq1qfQBMQXhIWCW4ITBJeF6eAeFG7KzYAYoWTig7CMH2/eAS0EByy FfhK+CpQBtTy7peVr6HMiIQ3qnwKt1SvZ+9HkBEuH8jfCYkm7aqjPaS8oH4rfw5ZNe/3urcb PnW8ff3TpXDTlGYIfACRY0yT82aCflCZ7RwJmTGuRZ5XwfOFfX3x6hDfvehPSQnA3JDnQzdD +t2o3GKHwHsgvVNyLHjPGJ8z7wFHSOjbIbdBuMUXehKYs8UFAQnCAgZdvQr6e+pVpxNCOxtf FkuBeZcUFoiCq62SX845Cb72Wp61Hqj76Se5QO9ITW0YyD8JnfWzkJqaG+LfDbbGjvLmNiAP kqta+oO3hifT8z6EZsq9VQnEAK8I18FYVu5iOw3mMHO4OQaM8+xbPBkgFKElN0DcJiQLT4Ba VPsw8D3Ylsnp0jUwv2wsFTUdvE/7OuZWBaEtLYyHwZcTeEKZA77tzmfzcyDQ1LTW6gaX0T0j dyLoC4S3lY+guDe8l1ADjC4hUhoP2WbPAu0exHQJ3WHJh9CTpnTtBOQk5S/O7wFuVftcdwNx pBs+BS2b3jQF80VbZWsOWF4xPG04CmpT/YjaFdQYdZvQGdQ++hHxBshrJT1QG0x9zfVlP4Sv D53l6ADe5d4k+TK4P/bV8lUC2xGDXZoIxTfHng09D7HGYsuLvwl6UeFjSwDsB8WuxlOQ9EEp S2JLcAWyb7qnweYXft6w7wbc6ZJ760YdsBTnE28cKLN0hCjg2X/fl8M/oiB3efHixYsXL4be vXv37t27sL+gPZjjHCRIkCCPB0XRNFWF3NzfUjYeXV4g4PWC1+ty/T7Vzm4PC4uLK9RToPdB /H6/PxCA27dzcpzOwvbU1FOnDhworMfGVq361FOPbm+BngK9f7wfVdV1yMhQlH/Uv2PHli1H j8K+fQcO3LgB9eo99VSJEtC4cfPmNWv+dXsK9BTofdw8ctZHtl9tlDEeMgK0zWsD8neCIl0H oau+S4sGSrCKYyBMFFYJW4B0fa9wGISPhWVCdfAXuRryiwmUndl5ObtBvCEnywHQIoVu4pug b8UjlAHhtvA5PYBRQlXtGtCBIUJF0EUq6dVAGCs0F4qBuJxopoFPEd7V10HR8aW/aHgRmibW mt6xJdifNZeLrwmXN2fI58uA2Ww5GZoN+5IPPn2gPNy8aDHfeRv8VmtNzw6wtyj7RelTUK3a C+8/nwOlGlUrU3cQDC3dv1aXLlDPUUGP+Qhi32dV3lywLohpWmQFyP6wnyLbg2dvznOppcDd 093c+z4YG9urh7QHLVMX5WPg6emZ6ZkExiflO4F88OL91P0jnI+/8fr97yDZkv5dxi3wZntG uUqBdM9oMf4MZp/1VVsX4JTglfqCdM7gMe4Fpb+WYdgNef1cVbxWMC02v2BcBGGWkNrWryGq Ykj1kGZgPi5GKIeAQQGfszeE3DGf5WmI/yri07BkiLlh89vrQuLHtu6OpWAUxGb2HPBvUWb6 wyD/29xn8xMh5dD9L5KngOpQewVmQH6IEuZ9Ga4fzZx0chHI9YRb3pnALv1S7mlw/+pf5i8F 945k3si0guFzKdK/E+xPWEtIb0GKMaO4cx44J3lu+3eAr6K3mvd78Mz2bQ44QbnPKmEBSKX4 TJfBGGPcKY8Fe3l7tKk52MqZV9o+ALmGMVMUIdBJ3ytmQubHeVnaHbgy52av9ATI2JidlHkF lB3K956fIPrrqBetyyB+T/FnEq6D+J08xNQSvDv8lbUPwdEw7vnYzpA3zpkmvApb7m0+ciQK Dv9y5asLnSB9b96etA7grJvV6X5r8I/wTLv/w+NfsH+Wgk2Af7b9UalZs2bNmjX/edllR5cd XXb8fc/lcdNxUsdJHScV3t/DnkvBuP8UVjhWOFY4/vy8FZSXR1wecXnE3219IZMyJ2VOyoT5 /ef3n9//r1+f3y2/W343eMr4lPEpY+F93ml5p+Wdln/33f3nfn6C/N+oqqKoKqiqqmrav176 fF6v2w2TJg0Z0rgxrF8/b96AAYXlH6/7Te+D+P0+n98Pfn8goCiF5f79H3/89tuF5YP9j17+ pvdBAgFNA9C039zYB8sDB06dyswEszkyMjGxsP6w8X+2LND7uHnkiLNcp7Q1ZhqYM8JXhs8C fQdPMgb0xnTjNRB2arH+BFC/1W/rb4HQVnzLsBrE54TSUiKIB4XuhuUg7bTHxCwF9V39B+JB 9PCkUh6EpjwnmUE/oI+hIegNMNILiEYQmoPQRXhKfwNoq9fWT4OewWqxB4g/iZrlACgH5WKB WVBUK6o3uAXiahnpMmRmiqMu34LrztS06z/CxfTrZzy1odzKxinPvABnP/mx04n+EDaweAdH CpSPLrO00mZ48Vi3G70qgnWrrZjpedjVeWfp74pB4z0xt/PHQMiJ47naRjhb0f9GqTuQ9ZF2 WJkIvkUZRVIWgLG3NL1oWZBH2J8MjwLfJ/4ZeR9Bji9vRd4McJcNzBA6QvZB7109C0zHDJ8a moDhW2FdoAKIPZSjbgECYV6XnAzmKZafTM9DYJr/FZ8Vcg7lvZR9DmxFLHMsY0B5RrNYzoDz kreI9BEYS8nFjSfBb9TnaEdAOR8Y6rkMtkmGWbZt4GmXvzowBfxf+VpnXQPXh8rNy0ZIPZW2 P2MFSD/LjbkEhmXCVMto8K73ilJn0FdJ0eYw4EuxSn4AXH5/56yTINZiuv0XyCuXPywvGs7e v/G+KwlKHowfFaVCzBnrfkcipDyX9lT+fvB2Jcs/Fiy1GCWvAXMZOZVsCPsmtLJ5EQjfCPNM x0DZK16UloK817Beeh/UuMBd8WfIDc9/JzsTqEmU1Aasg63HrBUhZm5Ie70FqLn+nqZVYGhv 7mJ8AopMCV8bthcibhaT4haAvMlSx3EN1JrewYyE6K/iLZHnQVZtvcN0OPDSL79cqg57E4+2 PvUipDdgQ+An0L4wzoySwfs03e5+CkJ7qalUEbj371i2D6cgZ3nPnj179uz5Y39Bzl2DBg0a NGhQmOv8uIhsFtksshm8/vrrr7/++h/7HZcdlx2X/3ufyd/J2B/H/jj2R7Db7Xa7/e+2ppC6 devWrVsXxi4du3Ts0sL28W3Gtxnf5uHzGPdN3Ddx3/zd1heypvma5muaQ/EOxTsU7wADGMCA v3D99u3bt2/fDoEqgSqBKoXtWzpu6bilI/SlL33/7psM8h+PohQ4sgUu27/GlClvvtm0KZQq VaxYVNQf+x+UX6D3Qfx+jycQAL/fav2vNuH5/b+lUCiKx+NyFbbLssVis4Guq6qiQCDgcuXn /9ZutYIoGgy/34z4oN4HCQR+2xyoqoV5yL9Hli0Wh+OP9YeN/7MU6H3cPLLjnGW9m5DcC+KG h28t8xEIn6rxehYwmNexAD49V7oA4jrxOWE2EOBTKQa0z7UWWh+QWhQdXnYxiAesg6P3ghCh DvbtBW29fkM+DYwUR7MYBIu+Xh8GegqhmEEogYuaQE39Y8EA+hVK6Dbgnm7UfwC9Oee0viB1 kOtICaA8o36u/ALSfcMU6054YndsqQbdISJX/znkJEQFShw2b4fVpxdnbY6DUu0qno5wQfXc aodMDSE55G7suUqQUC/tmLYdIt+0l7Z3gDLVwlZY3gShrdYi4QVIWSinXPoU7iXYN4Q+B3ot wsp+D86l9745J0OePfPnZB+ET4tclLge9JnWmQ4v5FQJdNOqgzrS60g7CYYW8lDxO4hZG1E8 6kUwdCBFHQup+7Ma3KkAoTVCK0Q8C1pR30npIIRGhehhM8G+w3Jb2gHOX9y/uIeDv6X3SP4e EC4bOhljgXS9p+8+uHI8dzzTwDLa9JK8D9RhygSvC9x3vPmuIuDNC7TI9IC2ybjD1wPk9YZW 9qngHuZ+OudZEHPNc6Q2YF1s3sNJkBsI7+mnQUQfY3sK4sKjo6scgfxJrudzrkKRO5GNY6+D 9JW4LL0vJGwOjQqZCFnlMpd4VsLdrzLJ+RlKvRL/pH0TBGKF/EAtECeYZ1gmgDKHLnwC9nim KF4wLRNP6RfB4BTbyVUhc1de04xvIDrBHm+YAnEXo96L+QnM75i/lo9ByjOZ3d3l4ebY1Ob3 hkLZl0ovK3IOHJuKvBtdEgwLjV1sJ8HTPv9aoBdE1YtJitkLIcti5kQ1hBvvnGt11weH3ziR cbIa3L+oV9WPgDpC/izqGjDdH51yEIxzrdPlm2Bqa0mKf/HxL9h/RkFEucCBHj9+/Pjx4wv7 x44dO3bsWEhKSkpKSnr8+gscxNYJrRNaJ/yDAQkkkADaPG2eNg++rPNlnS/rwLp169atWwcZ GRkZGRkQFRUVFRUF7dq1a9euHfQ51OdQn0MgDhIHiYMKI3EFDtMPo34Y9cOowsjcrTW31txa A0ePHj169Gih+oLr4uLi4uLiwLLMssyyDJzlnOWc5WD4xeEXh1+EphFNI5pGgFJFqaJUgWm5 03Kn5cLGohuLbiwKpUuXLl26NHjae9p72gNrWMOaP95uQY550bSiaUXToNGSRksaLXl8dlTX qmvVNbjd4naL2y3g7o93f7z74x/v+0FKbCuxrcQ2KEEJSvyufTzjGf9fzePbvM3bhfYXm1hs YrGJUOfLOl/W+RKyOmV1yuoEO6btmLZj2p+fn2urrq26tgqmlppaamopOHv27NmzZwvVlnup 3EvlXoKh54aeG3oOZu+fvX/2714sVCBvWNqwtGFpD8/tf5CNaRvTNqZBuU/LfVruUzAuMS4x Lvmd41yjb42+NYDjHOf4o3+OPvN95vvMB5vSN6VvSgen0+l0OqHGFzW+qPEFjB83ftz4cRB1 O+p21O1Cfb79vv2+/dB1WtdpXadB3oy8GXkzYMjZIWeHnIWWMS1jWsY8vnX1sHmd2mVql6ld Hv/3xv/rKMpvDqaiPJqjVrr0/+0wt28/fPjq1f9c74P4/T5fQST49xHpypUHDpwwobAeEVGh Qq1aEBfn9f4+B/rGjezszEwwGNzunByoWbNMmaJF4eLFO3du3IC8PKs1KgqMRocjPPyPeh8k EPjN4X/YvxWybDabzX9snzp1ypQNGx5+/3Xq1KxZpAjUr9+48e83Iz6o93HzyKkahnx/aOA2 hFc1LQ0ZCYEkKgtvgF5f+FB4FoRl4grDBuApwStlAiuE3ZiAnsos9zjQhua2SBsDVNBui6eB 1rwjLAOhsdhPdwMyzfTZgEgW0YBBMCMBqeRzC/Tn6aAng1BNqKo7gO94XvkWdEEb4pdA7810 Yw+Q5gmhUnNQeyvnPCchPMlhLX8VylcpObbVdPDelr83NAazWKa1rS/0cLw4oU0zcDTxjIzo D/6794fm7gencO5QajKEzDXcDtsJxZdGBuK6gj5Q7icVgdBhRVeY+kLkcFvlPDtEjrZ/KSWD eWDcznLbwLjfMN6yAtwNshx3JVDbey74nBAyPeTZ0KbgaBlzusgFiK0VdT0mFWLjomKiJ0Ck NzQ0WofSfYuGlz4LET/ZzoTshah9jp6GimDaoQ93fwpSY+/bWZsgKSVygLwHQrsZyihTwWaT PvduBMMayjsTwfqVsZS5IXj7e+yBJMj+NlNN+xw8+907fBpg1hIc34ApTjtaWYOwk6a+JUPA 2shw09IXuKvazQvBsce0t3g+ZDdzBdKHgf9FfRpFIatRajeXAoa39VdDmoB7pTc5vzGUSo05 Wnwe2D6Q08L3gquZb7b3KMQuj0i03gD7btMi0w6ILxfRLjwOEhuEFbV+Dt7m+WcDdnBssKji KDC20D9RkiCj8v1Xb/cF/4/+zakDIDfRsyyjE1xZmVb+VA+4mHAnPHkp5B7IO+suDhWOVThb JAFKdCotlPgOTAdMvUIVcBVz79S+B+sxR6WwphBGzHtRuXDv+q1vs0rB0SePZZ+6DTdK5u9z HwZvfd0j9gXPWM+G3NfB+bnzbloiGLIs96KWgXuKvtH8xeNbqAXHx40bN27cuHEPH1fgOD9s XIEjffPmzZs3bz5cTsH1f/XYugIH5mE/9W8quqnopqKw7MKyC8suFP7EXnZ32d1ld8P03Om5 03ML6wX93wz/Zvg3wx/f80z9KPWj1I+g0+ROkztNhpwdOTtydsD0XdN3Td9VOG7ps0ufXfos rIleE70mGprdaHaj2Y3Cn/bTPkr7KO2jh+vJ3Zm7M3cn5JfNL5tf9l+3Y9nyZcuXLS+0o/mo 5qOaj4KyM8rOKDuj0GH+7yY5OTk5ObnQcX926LNDnx361+VM3jp56+StcHzA8QHHB8CEjRM2 TtgIUztP7Ty1MyTHJscmxxZGxCdOmDhh4u8cgPgN8RviN8B7zd5r9l6zf67vfsL9hPsJcKLW iVonahU6uE3Dm4Y3DYcbTW80vdEUrl69evXq1YfL+bPz95XhK8NXBvjW8a3jWwc0cjRyNHLA pOKTik8qDhcvXrx48SLMqjSr0qxKD9fT7qN2H7X76L/4nDymdfW45vV/C/9qqkZeXlbWvXuF 5YM82P9nUzUCAZ/P5/vNcf4t8vxbeebMF1+MGVNYFrSvXDlqVJ8+hWWvXnXrlikDmzdPmPDa azBr1sCBnTvDli0TJ77+OtSuHRtrsfxRfoHeB/H7f8s1VtXfzuF4sJQkk8ls/mNpsyUmli79 8PLkyatXfb6Hyy3Q+7h5ZMfZuMicYXwCwvuEHoiIAe1NfYLiBiFfCBFSgTRMekNgu15ZWAbC B+Kn0gQQPvFNz50F6qW8OnkhIH4hzDPvBbWfkKGvAqG2/jUzgUr6SCECdDclEAAJAUDPIwMv CHOYIzQA/RskYS7oWeo0jwRiJ88VTy+gl9vnXQeYmK2lgFBdqEIWiPWkt5gK91dmVU+/B+Lu a09dTYexlm6rhr4JVY5VqN/6KlSrV+fFVu2gVdZLTTv1A8O4Ch8nhsNPK3e22rEatrfbm3V6 ExhPBeZoeVCxsSM8vAHEO/QEz3tQym+Kzn0Syj8dc9nYFkKS4vqWEUDaa9nn6A6+zVmvpp0B /zDnRVdvMCbLltCyoD9vMkWegbQNeQO0KnC3Su50XyPI3OYso7aF1O2ZB90ipH+ZPcj1Jdxr kbEl51swHzdXk5wg3PanacNA7sJkdShEZVtfESpD9HfWL8w1wHFOtqllwHrG9IYxHvwxyuvU B+9Q9UZuKuSKgT0nIiHttZya585A1o5Az0vDwVnL97U7FqQ77DDI4G4dCPHMB8Kl/oZ74O7p M+ZUhPztgf3JCyG9X86xmzMg48Ocrz33IGOt05j2HhheCLvu6AshgiM7ags42pm+xg5hhpDD xgogvKxMNY2D/Av5CZ5nwXhCOqN4gKdEO+1A7S7abWtBm21u6hsEQntb/5xkyL0UKJ7eGS7X vxd6LQ7SIz1n7l2EIiNLdQ6bAcUOF2tdug8IihBv7Q/uYvnFA+lgiXUMCnkNQlfH3ImpDOmf JYfm7YMzsUe+PiXAzRdzD+aGgVrXMNxwCuis+YQuwGqhiVAbpBfCU4vGgbJBDo0XQMgShwt/ 4g/4n6XgPOYCx7cgYvTgOc3/jILUjAdznQvkFMgt0PNX5Rc4MKtXr169evUfy3oX6l2odwG2 T90+dfvUwuvGjBkzZswYqP9N/W/qfwOj14xeM/p3EdwHxz8qRdoWaVukbWEEryBymDU5a3LW 5MJxe7rv6b6ne2F96LKhy4YugwFHBxwdcBTCr4dfD7/+77fjwZSaIeYh5iFmeH3x64tfXwwh b4e8HfL243s+f5bQ50KfC30OZvtm+2b7oPW91vda/wvpSQX3XcD0GdNnTJ8B27K3ZW/LhiGm IaYhJlhmXmZeZoa4lLiUuJTC8cbFxsXGxRD7fOzzsc//c32bJ22etPl3OcNNmjRp0qQJNH6n 8TuN3yls39JpS6ct/8VLjP7s/O37Zd8v+34prBekwDS60uhKoyuw6MSiE4tOQI8ePXr06PFH PYnjE8cnjodu+d3yu+UX6smbnjc9b3rhuMe1rh7XvP5v4cFUjT9b7tixZMkbbxSWD/Jg/4PX PzxV47dznAsizg9GngvH/eP2du2efrp6dXA4LJZ/FAnu3r1evapV/yi/QO+DFEacf6s/WBZE nP9q+cILjRpVrPhwuf+uiPMjp2oUnx3Zu9gXYLhpPmp1gLZCz9bKgRDPDf026Fa9q7AZxASm KA2AEcI863fgeypnZt518B/3SKGHwWgw9JB6gNhZvRxYCqzVw+SNwHKxp+4F4VN9Lvmg79cv 8CsI/YQuLAM1Um+jJYDUVSspXAXfgPy3fQIIKR6n9y4IulzWtACkVqZ12hoQnpVFuQXoi7Qj 6igwbPCu9MRCw9Anfe2rQ/h1261SCeAL92d7B4C9W/Sw4iPAYRQalGgIUd4kt/ITRHgi3gx7 Avb02TNs+0ewKvXSgcyKEDPNU0+/AKUuhE20tQVjvLjbGwVFuoaJahNY+4RWiTw4ZjPUKTUQ tN1Zfe+sg8BHeevT9wJvqz31nmCpFtI4/ABoi+R1wmzwP+fvrm0B9/28kek5EIj0heS3A3t1 c0tpMET2sqnmTWA/azhgLQueT/XGehhE1Q1fbJgMEQPCEsNyIe2rjO89S8E2WP7ctQZMG+VM aR+kFcsSUndAwruRfeO6QfoO39DooZD+pa/+lQFgj7TWd4wGfbz0nlmF9DVu7dY6EBbnxcon IOS45bvYoiD9ZP3RvQFsFRytQ+eB2E35IeIzMP4q3jEmgzaVJNdPcKv+3QkZZcH3qjfduRqK No5ZbC8JN/emVdFfAneCsiq9PxTJCW8p94HAHOUL8yFwt/A8FwiH7Pvu/toMiCxj/7bIOXC9 GhhIKbBFmxYYR0GJjjHbyp2AIreLflLyEIS9Hj48fgn4WwUmSw3BXctfwRcKocfCO0TEguNy dMWIjpD9VPoW51K4efpU7Pn1cMeR/WbqANCmGSNDhwLz1FeEt0DrynrfWRArmBqHmUCYqh0J RID2tK9C9gGQ7gd0VwxQ8vEs1AdTK9avX79+/frCiPCfPY+5ILf5QQrkFMh9mN5/RoEDkzQq aVTSqP9ioAcPvzuOSDgmHBOOAc1oRjMQjgvHhd/9NK710/pp/f4o5sF29bB6WD38z+0UB4oD xYG/qy8UF4oL/zhO76f30/sBVqxYf2dnAcc4xjGgM53p/Oef01+1I1A1UDVQtbAuDZQGSgNB sAt2wQ7SKGmUNOqf63vchKwIWRGyAsRR4ijxH+j/s/PzYeKHiR8mQrsv2n3R7gs4/MLhFw6/ AIf6HOpzqA9sTNyYuDERlk1dNnXZVFjFKlb9KwbXoAY1YOP0jdM3/s7hLPiH8UEKUjYG1xhc Y/A/SNn4s/NXkELxh3H/J/XlnyHVlmpLtf+5ngf5V9fVP5vXIP83haka/9iRfZx6fi//Yaka gYDX+/vNgQ/jYf3Llx86dPkyLFt25MiNG/DBBy1bVq0KnTvXrFm6NNSuXa5cUtJv1x879ke9 f9Tzf0ecH+RhqRrjx3fqVLz4w+2/cycvLz8f3O5/LPc/NuJsPuqqJzcBQ1W6S0UB9LncBq4L lYSrIPrk1+TboCJM1tcCw4RD+hFQ3/fOkC6Cr5lUM3YWiIOkhShAGe0sC0AfKrzHDeC8vkKP BD0dDxHAHpycB72rXof5YOgvHZS/A0NT4wxjFZAOORJj6kLyet8EY1G4tDhzlD4Pcqb7iglD QPpRbE0bUDYqu/w7IaRIfPGyP0CoPTqpaEfw/qB43fdB+Exsx0BQ3lIzvUsh8ExgiXc4aCe9 b6rzIKF3XIXqh6HdmtrS0xWh/meVK0TkQdiQEnUMdUFZYxzg+xhKWKJ3RsRAuaiyz4ScgGq6 NTSnBjwx0ihpLSBMiQ4pvgwkwhoXawlqI9+NnLrgis85kjIBuKTVYAqEngj9JXIUxI5J9CXl QuLdoq+XGAKhPluliFIgXDfMkMtD6P7oBREBcJgsU0xfQ+retHY5V+HM9otl0z6C3M3eEP9y sPW2t4jIBvt8m2RrC1V7Jm0tvhjK9IiIKxYFBjttfF9CsfyoQyV+hvKDwrLrvQNFL9kbFv0a bFctFks9KJ1Q4nzlFhBhC+sVeRwiJoSa4iaCPEWSIsqBp6t6zKOAMly35+4Bk2iebu4G4Wvt LxIGCR/HbQzZB6qIy1oNot6M+tnxLTx5pmyZhLMQGm77OLQfSJOFSLkF2EItyZaeYHXbehmt IDYztTUfhtjbYfFJ86FM1+IZZWUof6DCMzWbgj055PvEXyC3m2uyng85Q7wm5T5Y60TmRNYE 0/jI2ZF5kKvf7ZtbBW6dPfbSiROQeiCrz/XDoEaYq1pSQX9FijaeB03RV+mtQCghfE4R4L66 3VsPFJtvnfM+KJXUZ13XQbHynLL78S3UAge2ePHixX//RVLwB//BV2v/WQque9BxKNDz78qF bryy8crGKwvrH236aNNHm2Bf+X3l95WHCRMmTPh9Ll7TJk2bNG1SWC/IwU3dmLoxdSOsaryq 8arGcHfs3bF3xz4+O58Z8syQZ4YU1me+PPPlmS/DAmGBsECA7M7ZnbP/BYf5r1L7RO0TtU8U 1j878NmBzw7A3CNzj8w98t9nx5/lr87Pm7Y3bW/aCnOcqx+pfqT6ERhUe1DtQbXB+qb1Teub f4ywCguFhcLCwlzhghSDh3El9ErolVC4/s71d66/Uyj/wV9GCiLCKWNTxqaMhbNfn/367Nf/ +vN4ZukzS5/53SbMT/Z9su+TfbCz686uO7vCq3NfnfvqXFhxecXlFY+wefZR11WQf43C1Im/ FnFu0mTgwG+/LSwf5MH+P8r5x456IPDbsXAPnnrxIA9r3737ypXU1ML+xYsPHLhy5eHXF5QF ev84rmBz4D9OqZDl31IzHiz37r1+PSUFzp93uTyeP5b5+b+d1/zwVI3/0M2Btl8jx8YtAr2D VMdwCcTljOV9UFL8uwO9wPeEZ5W7CpheCcX+GRiLCaP1M3B2zrXczD4Q2jCpe1JrMI5mhjYM vB8KbcUFIPzMz7oP9Hc4riWDOEPoLh0GoQobhdWgn6UWZcD5mjMv5xqsnrHm7AYL+D5XzRHb odq2p9rU3wZ6EcNddoHUQ06Tz4IYrW1TSoDWTzxh6AW8TC3hcwg85b+hnwXRL7VmO7Be70om CCt4S5wMzBWT1JeBItpg2QqBHqSJb4G4MvGdqiWg8mHxA/t6KPG6acHpWZBVKjw1ZySIF/KO emwgfpL47hMeqDSm0t7ABUhcnZbmnAqnkrJ8yjo4M1e8bH8H7pQ3N0m6A9rNvJ1po8DXKbNp an/Qitq/DN0K9vdCvgxRwPSzpakpEcRP7F/Zz4AWUDr5m0La9pxooR+4innOq7ngmqG/aNgJ YoxcUr0BDNW+1KPgzmtppzO8wCb1NUMohDUPLW45A8qL0hnffii1LaRP8RdATjDMiygKeWdc Hs9i0GcIW33vgnmLNjBsJ9Baa8wAME2S24tfgfESrSLSwNDX1jfnIni+90hZFyHTmNuZL0Ad 65+YfB7KlIqJLR+A0PHSvvhXwLYubAY+UCq5TjkluD8iWXWNhrRezlSXBcwvm1XTaRCbCjvV I+BIM0+29YDQchH1QuaBfazDELYCzB/aZ1oqgi/fV1LYDc4PnIP8Akjvmt4xhUOkGrs4ZgmY O5t3GkZB/sTbvVI/hfQ1N/tdNUFek1ztVmnwYDSEfwbqUMYYXwd9ijZH/e3zN0i9APod/ZBe CbQRxOqVgQghS10Hop1o49vAs7TUq/2fRdL+8S3YgtzjgvOZc3Nzc3NzC+sF5cMiy//s1I0H 9fy7eNnzsudlD/h1v+7XYd2IdSPWjYARGSMyRmRA9K3oW9G3YGCxgcUGFoMegR6BHr/7Qh5u G24bboOZ5pnmmWb4buR3I78bCdG3o29H34Y00kh7DHb2rtK7Su8qcP+F+y/cfwG2TNwycctE KLa72O5iuyFycuTkyMmQuTVza+a/8UU3/fX+en8d7o28N/LeSNiQsiFlQwpUiqgUUSmiMEWh wFH9u/mr81PgwE5fMX3F9BUwwjbCNsIG6iH1kHqocDPmiOIjio/43T+OHdI7pHdIhx+7/djt x26FmwYftomtYFMl5znPeWj1QasPWn3wx1SRgs12n/M5nwNbJm2ZtGUSVPq20reVvuUv07dv 3759+4JzpnOmcyZs3r159+bdsPHWxlsbb0Ftf21/bX/h5sd/lUddV0H+NVT1t1dIP8yR/dfl /tfyCvQ+SCDg9/v9IEm/nZrxMApO1XiQCxfu3v39i1UerD/s+gK9f7Tnt8jvwxInbDa73WIB n09Rfj9i+/aDB5OTQdMCgdTUP173xBNJSWYzVKv25JP/KMBToPdxIxw8ePDgwYO6XqdOnTp1 6vx1AW5cDbJrApcNJ+1dQcjiQ60KaPX8X/gPgS/G3c3jA5sxfG7EIlAv62/5+sD5KVsjj/eA kpF1Rle/DtZXw48bBoF6Xs3Uk4CjqlPfBmzTV6ivgtDT8KShHFxPupt8bjkU3xxTq3RdUPoo 7fQ42JOx13mkOjh/dVnUSKCV4/ui3aFkZilfkV+g/L34dYZksHaxFmU/qOXVFuI9kDoI4zgJ Snl1s3cPiH6hu3wUhNekSuIs0N/W2kv7gDXiJ1oA9OcQhAQQ9+ui8i74azgr5HUAY4qhjboQ 1BdckzPeAG1+xsuZ34Hkipwe1hm8dzI33neAPjl9avobIO2SdVaAN1W640mDrKTrO3PSYfW1 PSXut4Djw7J/ktLBv8Q7Lms2+DPdLbIng1BNHmm5DGFvhtSJ2ASOt0M3mDeCyWF4Tb8HDFS7 +2XwVnSt934Lvmz/9sBnoCzTL2rDwB/rv+pNB99AlyXnAJidlnXWwRCRHflG2FvgveMe4+0K nmLuLOfPkFk1Kye1MajThY3O26C1F162FAVnZ//27HQIyXOsEKuAP829TfgQcuu7c109oVxa /Liin4F8QYyyVIab4Rk37x4FQ115u6UXRK0JU2PbQ+Qe83lTadD26KOULnB30J1h3m2geY2D WAeOCaGSVQDzK/I31psQkxu/waZARPPI4lGZYBhkvhZyDrQPlN2GN8GV6iyv5IM3U90QGA4W Jexc2DEIXRY+J+weiBW1nw07wBl1P+d+Z/B9kz3gTip4fMrnuZMh2+96O3AA8rbpo8K6gl5a nGc+BoEJzJCeA9995X1eg0CvQPdAawgcUFb6ToMyI9DJew5YqN7zTAWpkr7E1xOOpe77dMOp x79wCxzbgtMDChzof5XQ0NDQ0FAYNmzYsGHD/v2Oc5C/RsEvAymtU1qntIY28W3i28QX5ja/ tOelPS/tKaxvbLux7ca2f7fVQYL876By5eefnzYNqlSpWbN8+X9dzjfffPhh69aF9e7dP/jg vzpV4vTpo0cvXIAzZzZuHDmysD06unPnKVPAZCpWLD6+sD05+eOPX3mlsF6kyIgRS5c+vP1B /tk4n+/27Xv3ID39++/ffbewffDgo0dv3IBKlRISrNY/yk1Lu3/fYIATJ+7d+yv/ePj9+flZ WdC6df36oaF/7D97NiXF7YY5c2rWLFHiz8t9GIcOHTp06NBjiDhrqudHb38wfGtsajkCWhvt Y70jyGWN3xqqg7zEpJgTQQ3Rh2vfA0s86/0TwPG5Y79tFxi/sMw39AZxs1RXNIH4hHBReBa0 tryo/gBStJxheB1S87Jnp+TD9TeuLzi0BYq3iesS1wQyv3DXdg8Cp9M0wfQSFFtZZmHFouAv 4n4LN9yacf9l12BIcIf3td8E6xF7WUM26LW0wQwFjuvN9fMgThQWin4Qloid5C9AL6p/oU0B rT8/eLOAiuo6dThIi8UTlpGgHxEHGe+BPNuxLjIKNL/aLhAKegfDNHUlKAstVZ3NQW5ruRP7 PpjDIuubZwM9YxJL9wUmO9rETAbLPcksR0PE4uqzvEfgjdM13jv3Hfy6bM+FEz/Bujn7y6hf wb3XTKdDk0A5lNcpfR9kH8isfP998Oa5N1oWQ/i2sJsR9SHsdGhZuw0sLSJvWfJBf0Zfog4A fYPi9a8GfxXfONN2cA2z1DOcBtN5OVYaBJkXs7/0fg/eZ5XdgXdBPm8cHzgGOUu8fbKHgLWN eY9lItgjLets98B02NLO1xLkNYZx2hZw3ckLcc+EsGIRM8OSIL+23+g7Ajkr8jvm9AbhsDRC 3ATGLwwTDC/D5TE3G17LAdtr1kOGdhC6JayR0Q9Ro4pdLLIeIqeFRIY3hfDbYT5HJzDNMDlD dTCUs223j4OAIbBCGgau8bk/+Z6E/HW+i4HnQTJbcwxjIfxYzNVYCSw7rIccJlBeybvo3QcZ 2Xdu3xoKGWvuVrmwHgLxeuO8eaB9or8jvA/5Se6q2jfg7K7KeTUgkK0V0ZaCv5r6nT4ClG16 B/0JUPcrfdXN4K8eeDMQCfp4bas6FfSTat/AM6AGAk187z/6Qn0YBY5tgaNb4EAXOFi3bt26 devWw68vSMUo2CRYICf4RsH/TAqOndv1za5vdn0D/ehHP4DpTGd64XFtb2a+mflm5t9tbZAg /7vQtN8iw/n5WVn5+WAyWa3/6Jzjv4rf/49zhn0+t9vnK9T7IIHAb2/O0/W8PKcTRPEfb/L7 qykcDxunaR6P1wuK8o/fDOjz/WZndrbbrSgQGmqxyL/zPkuVioryeH47HzokBC5cyMwUBPiv 4+Xw9NMlSsTH/xbJdrsL23NzPR5FKdT7uHlkx1mZ7MrXfwJDvbBvxDhQl/o3qjXBN0ufH1gG xoamJsSA3FpuaEgEz6HAV75mIJ4XlmhzwLDM3NnwDtwfc//2zXWgbFd+9X8PJqSv9J7gOGob Gn4Q8p/K6ZbnA/ur5msRY8BU2rzePhCiwu2bzRHgXO0sckaDKytS2uV+CYkVImdEpYFth+Ul tT6kfJu2118GijUKL2I6BWpTwUcRUEYrJQOHQZgkthUbAUVZKISBsJ378krQbaI7exwItakh VgUiFaf6LCh3na6cp8DQ2N60SGtQKwv31EsgOx3X42qA4aw9LK4yaM8qR5zZoLbxHsyvAMZ6 5nrRP4O6w7Da9iyon2sv6xJoVvll82GwVS9/rP578HzZ8n2e7gPlJpaptuFrWND1h68O14XL W61yqZPgrehqlrEKPAPzr+XGgn9H2sa7Q8A1P2+zeTyEfunIj4qGkOSQFaaDYLtsfcX8HYS+ G/KRQ4Go81G11DTwn/WscT0LBsWWmFcOAruVvmJpUBK9mr4J5E9L5hfrCHl9ct/yamBqYnjD XA2ku+qakFRwG9w1/QvAvt/SXygF8T9GVIw+DXYMzyZMhrTpxlYpr0DILvsB20SI2heyKno3 ODsVfdvTBwyzjNfYDY6UcKutH1iumZ1hX4GxoWy2D4aAX9suPQX+ogETMZCTk/6F9wUIfK3m sBW0X41dzO3B8lXoSMu7YK8avjbieZCK+Q7igtyGN4+nbwBXu6z7yb1BOassTP8YbF3sX2rz wbdFuWJZAN6y/j3+bmAXLUnaIZDWB+a5i4LvQ6WCXhr0+nIF8kG5rfVVQ0F/yhTHh6D01U36 06Ad0zZpIgiXBIPRD4qorJAf4SfXP0uBo1vgSD94jFzBOa4FFOQyV6tWrVq1av9++4I8Hqq+ WvXVqq/CUpayFGAIQxjyqFKDBAnyOHjiiVKlIiLgzp2UlIwMiItLSIiKenwOdAEFDvP9+7/p KdD7IBUrFi8eEQGnT9+6lZkJohgaGhICYWGDBs2f/8fxD2v/Z+N03ePxeEDTcnPz8qBKleLF IyP/eF1oqNEoy7+9mtvvh4SE3xIowsIsFkmCrCxRlCQoXjw0NC8P6tZNTLTZQJIEQfwvduLd uvWb3vx8XZdlyMnxeFQVUlJyc/3+Qr2Pm0dO1bjX4OK7N7ZA5PonphQbAYF0Tye1BCiZamxg FJh6G1sajoMuKy6fDXJH7u56KATyZulfyVWhyOXnqj7TBrI9OZ579cG3XBmmjAZTtvEbsRqc feNywq8pkHtJfS3/ZShTKnp5qa6QoEauqZgLpztdcB7Pg3Pv3/VfuAQXz9w9LdWBKm9W/Kjl C1BnQqXMYqPhiWNRG4SWIJQ0dBSLgbhR36KvAH2K1ky9DXqq2EZIA7GbUNzQGIRUcY/+PKSa sq9fGgDpXbyzbpSFiGER7UJ6gfap05U9BcItJmfFDyB0jqNXuXrga6dVcF8APhBkUQZhFyly LxC/0CICw0CZof+stQFRF6sa3gAS9WgtFYSv9Hn6aVDT9QZCAlCRfVIU2L6wVJEbwarQGX0+ uQvr2h413ugDeoJtetRFcE/2Ng7UA3W9u0Tur6Bf9MzMuwairJ3yLwXre3KeNAPMu+xd7Png sDgs1tkQMsL6kvk0mKebTQYZDCPkUepzoP1KimYAf2n1Y8UL+kmtlNIdtHna6UA3CJiUp1UN PNW8r/tHg7BSThaeB2muECfWBGmasEC4BNoCrYUggMltet+4B7SNQnPtFzBVEZ8xvgSGfPNP 1idBC2eNcA60SYGGYip4K3ubaeXBuddbzB+AwKjA1kAGqPWkRcJbIMUYj9iOg3G8JdyYD9Fl QupagCK+2EG2S3AncP+NjJ8hX8mpkP4FZNdOTbjYGXLz0zz+6aAeY1PgV5DjlDZaEogmcaWp AbDaaJYjQP5QXCcVBf0d3pHeAf8EtSzvgv4J+fpYQKCRcBL0BOEXcQXwgbhFmg+6rJ3Sa4H2 lnBD3Al6hnhOngY/dvt55PfbHv/CDRIkSJAg/xlkZeXkOJ3Qu/c773z9NZw/f+VK2uPYZPEQ KlQoUyYmBhYvnjr15ZchIiIs7PdvJk1Pz811OuGFF0aPXrgQTp68cuUfnRP9uKhWrUyZ+Hj4 6aeJE/v1g+jo0NDf25Od/Vvs+IMPzpxJToa0tN8iz/8uYmKsVlmGDz+sXLlIEQgPfzwO9GNL 1ZDHOb4zroXA9Jy6+W7QX8n+NmcXCONdKS4r6KPLzivVEtTS7j7u5eAsvvncr29DmPnFt9vl g7DPkiAch4SJxleKDoDsQe4qeXY4kXFcOzADLGWNxtCXwLPPtka/BVE7rCXjG4LhHWO58Lqw I21X+J3ecG+E8MPdzuCOkNYFbsDWY7vOf38BfJ38dP0aSiU2Xl+8HlhcpvP0BHW/9rroAeGU eFeYA+JIYY/UEbRcPvQngLyAeuYz4K6d58vqD5dXX+l5vBQoh/XphvmgLzQN13wQfSoiMvki VNxe5HNfEkQnWxsn7gIs4mCDB/RvRLSGwCRhsxgCArQ0tgLhQ726WgH0dfRgA7BdWCpMBDFc uE0x0GbSSQlAQFOKaAdBqOjPzddB3JDR5Dogj9Pmqu+D3Mfc1b4BtBfCSkReAuWXkKoRV0Ht 5Rec34O/v29zfgdQogNjtJoQ2JA1Lesi5DiznpHbg6m+8UPxHTBbTDss7cFUyTDcVBrEcNM8 aQNINyRZPghSXUM5604w7pGbiO3BYA7ZSwCQeU5LAcHLBHEJCCG6pG8Aral+i7KgDNVTtT6g llMiWQT5zZUyvAK+tTl9vLHg7R2YoogQEAMllAugHmUvZ0FeY0o2zwPjUusK21QwdjA3sB6E uFH25calUKNzuZlRa6DGdzVfrjwD4j5LulxqCmx+d+usr0tC6ht5k26WhuoNavratoHVm9bc +3kI6Js9rxpKQtPvqtSqnw5X4s52yCgLx749Vu58BbizKCsiawz4nlcGK13AMta0zNwL5GOG Vw39QKuoFtHfBbWW9qVyAvSvhQHityA217uLoaBd1u9qBtCO6/vUUUC3f9+XQ5AgQYIE+fsp cFzXr58//7XX/m5rCh3XQ4c+//zNN/9uawod19mz//Emvv/XeGTH2TJfmexvBYHlN/PurQci fS08VUB7xlvE/yIYdwttSq4BQl2zXD8DW/zXA0vA9ElMZEg1MCxnmrwRMt9yr80Q4Pj648P3 zYKEmcZtcW+BK9nc3BUOYWnCCEcixG6KK1G8F5w6de3LNBHE0yGDExeAvihzTUooFC1SfniV tpBS43qfK3PhwoKr3msZcGRLUvuIBHiuS8WZ9l4QWBVY5psE8jZThOVZUA9r670pIJwS5piK An31MkI4GD6wTDTtgpgSFbQyQPLhU54rw6DUbikibiXYL7kiLW3hWurm3aviwD63dFq1NiCs EzpKSaDfZr3cHgwjim4v0xXkd6KzSzwN+na9IfOAFUJPskFfqJ9HByGZURwFsaYeLZQCQ0M9 Qf0AhK+1xWpXcH3lfDLzPsivKrs9pUHsZN7t2AByjGV/RDQY8ywXIi+BWMMyx/YjmH4OdYcL oE1x9s+KBS9KrDYXAu/r97Qc0A7pxTUdnM09az3HQXzZ5c+/DIqk7tIvAs11N2dAWCWcESeB cSFPCOdB3yn2oQ/orwqLBBcIDVksJIA+n5/E1aBPEhYSAlp//VllH+hhwntiGdBfE4rKd0FY K22XW4B00nDMcBDkkyENwm6BZZplmu1nMDuMa8wHIS7T6tZ2Qo2mxWtb7FCtVe0qVZ+BuN1l 5RoSKIuEc+ZoCJzUZ7ITGr5b391lHDiLOAON3oWIXgmvlf4coi3dF5bdA/aFjjJlZAi9FNa7 +HtQIbPmtLv9IGlr9a7nhsL37uW3NtwG/3v5Oec8kNwx9evsiqD2FKdJTjA6zJr1KBgSpSWG +SCbpYXiM0A3nGJn0Fep8doZ0AYqx/XPAChHo797mQcJEiRIkCBBHgeP7DhLG+Qj0mnQ3Y76 th9B2BSTFjsKhA5cEDKBSrJfbgK+5Xfirt8AuUvUq+FjQH4/JiL2W/CEBO7nV4e80XnJ9wZB 9a2V69ZdCNH9w6fH2+BA+vnGG0ZDeLSte8wk0NvJ1w1vwrmBx6vv2AXGmda2xRdD8Zm2L8tH Q61tZa8+ZYMLDSJ7lgSE59UvtaehakZZT6QAvtGuZ9PfA+EtT+OslqCtklVbcRCXW/vbfKA3 MuQZfwDpknmjGA0pA0/IVytBytnc9y60A9uC+A9NWRCRGtU4aSaUf7+yr+UQ8JgrVrvrBz05 q9a9IuBbcK/zjR9AT3K9l1MVVCm8vGMtGJ6NiI/OA54QhoVWA87ST5kH+vOcYzRwimRWgtZS +JEPwfeJv4PeDHz5/g04QRsg3zV0Bu/twCL3MsDgPezeDkJe7qrMX8CUb8q+bwNrS/uYMD8U 21IsMSoF2kf3rd+sCtxPv3c7+yW4veJa/N18uN0/Y7CrJ2R+5i4RmAr5J/0LhTrgztHPKSdB aK1G6iMhEKqixYP7hJqudQeeEMbp60GPFvYwD1jLh2SCGCMOFZ8CMcrwgeEHEDZIkYZvQF5n aG1sANIMOUOeCPIIg8f4PhiSxLfk5cB4OvMsGKJVayAdtGkZDe9Xh+eKP9+hVHN4+tk2tC8J 3vfE1lE3wTc/MNYbDfph8QtfMxBjpctiZ5BeNIfZFkHUKLmCJR/0MVQ1L4bEYkX3NhkHAZMy VdkK/kz/Zf9xML5v221uAYHz6uCwtvD0q9XbVfFB/JywjGKvQvJB9zb9Jdh+bsune12QMifz jbu7wGM2nJXXg0VQvjIdB9NKU03jBhAPifvEoyBHGJ6Ufzs+JxhzDhIkSJAgQf6H8Mg5zkGC BAkSJEiQIEGC/E+mIMf5kd8cGCRIkCBBggQJEiTI/waCjnOQIEGCBAkSJEiQIH+CoOMcJEiQ IEGCBAkSJMifIOg4BwkSJEiQIEGCBAnyJwg6zkGCBAkSJEiQIEGC/An+/+PoCnYLBgkSJEiQ IEGCBAkS5I/8f0cgKl0uUMVtAAAAAElFTkSuQmCC --------------000704080604070505010507-- --------------080904020403090301000708-- From nobody Wed Jul 30 06:43:06 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133721A0064 for ; Wed, 30 Jul 2014 06:43:05 -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 6mbhktl83FMo for ; Wed, 30 Jul 2014 06:43:01 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F881A0068 for ; Wed, 30 Jul 2014 06:43:01 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id 10so910704lbg.12 for ; Wed, 30 Jul 2014 06:42:59 -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=z3/T/MjpKOUb02bT5HAqiM4b1I49hSL+n9Afbq7Mjfk=; b=GU94Y+NgX8D0Uz8bgiGW32BIM4l0VOVKv6qWPABLdrAGFxmAR7Gia//gqZp1CTAGq0 vYGwHWq6xtEGisP4nc+xQfZIcdkXreFJsXd63qHZbA9MYA/2LLIHp8gAQuKPV+EzYo4N Uu11IVF/SfzatbXuh0vtsaUwLlJWDV+DB5RtGDDQIlhyRg6Rfw/1wG/w20UsmC5vJH5N CrKAkoBLE1N1MUsDXgslppaNC4m331eL5n/8aTdOVe2Le+eaxjmyccGNKmYfxWo78Vok hRwPtt2nt2xvEmmfyqolZI7fAPxuBUOF+hBuzetdArpiqalhfqRLBQXWJfvFA+b44Ed4 Hlug== MIME-Version: 1.0 X-Received: by 10.152.30.71 with SMTP id q7mr4860238lah.56.1406727779568; Wed, 30 Jul 2014 06:42:59 -0700 (PDT) Received: by 10.112.135.106 with HTTP; Wed, 30 Jul 2014 06:42:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Jul 2014 22:42:59 +0900 Message-ID: From: Takahiko Kawasaki To: Brian Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JyXqU3bz64wrYlChxPJyvVU6T1E Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Standardized error responses from protected resource endpoints 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, 30 Jul 2014 13:43:05 -0000 Thank you very much. It is the specification for token_type=bearer but really useful. I'm ashamed of having forgotten the content of RFC 6750 although I had read it once before. Best Regards, Takahiko Kawasaki 2014-07-30 21:23 GMT+09:00 Brian Campbell : > Take a look at RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer > Token Usage" - particularly section 3: > http://tools.ietf.org/html/rfc6750#section-3 which describes using the > "WWW-Authenticate" response header field in response to a request with > an invalid/insufficient/missing/etc token. > > On Tue, Jul 29, 2014 at 8:10 PM, Takahiko Kawasaki wrote: >> Hello, >> >> I have a question. Is there any standardized specification about >> error responses from protected resource endpoints? >> >> "RFC 6749, 7.2. Error Response" says "the specifics of such error >> responses are beyond the scope of this specification", but I'm >> wondering if OAuth WG has done something for that. >> >> >From error responses, I'd like to know information about: >> >> (1) Usability (active or expired? (or not exist?)) >> (2) Refreshability (associated usable refresh token exists?) >> (3) Sufficiency (usable but lacking necessary permissions?) >> >> For example, I'm expecting an error response like below with >> "400 Bad Request" or "403 Forbidden". >> >> { >> "error":"...", >> "error_description":"...", >> "error_uri":"...", >> "usable": true, >> "refreshable": true, >> "sufficient": false >> } >> >> >> Best Regards, >> Takahiko Kawasaki >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Jul 30 07:15:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09181A008C for ; Wed, 30 Jul 2014 07:15:15 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 eMlZWT09Zwxg for ; Wed, 30 Jul 2014 07:15:07 -0700 (PDT) Received: from omr-d10.mx.aol.com (omr-d10.mx.aol.com [205.188.108.134]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9BA1A0092 for ; Wed, 30 Jul 2014 07:15:02 -0700 (PDT) Received: from mtaout-aaj02.mx.aol.com (mtaout-aaj02.mx.aol.com [172.27.3.206]) by omr-d10.mx.aol.com (Outbound Mail Relay) with ESMTP id 28E777003F60C; Wed, 30 Jul 2014 10:15:01 -0400 (EDT) Received: from [10.181.176.18] (unknown [10.181.176.18]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aaj02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id A13EA38000087; Wed, 30 Jul 2014 10:15:00 -0400 (EDT) Message-ID: <53D8FDE4.9030303@aol.com> Date: Wed, 30 Jul 2014 10:15:00 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , "oauth@ietf.org" References: <53D68967.7000206@gmx.net> In-Reply-To: <53D68967.7000206@gmx.net> Content-Type: multipart/alternative; boundary="------------080209000406030304020609" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1406729701; bh=/rH34adQRRH2uEcWXG+wG/F/k3+qbQ06NVRVEng0KCs=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=dbltSy6TrcuNqneYDETQMGrMrN1LrwTAwhxjN7utRZUv2bOG09ibUX40lqyd+ujxa jXV1w7Q8m8SZj3RvHvzC0AMZbcDcNCuQwsue71HTrDVNJ4uuHk9Nm1Jiz2HOxTcPgh tWoAmJ16XuYVTFL3p9OD6p8DfRbKS4T44nhJYNI8= x-aol-sid: 3039ac1b03ce53d8fde43ee1 X-AOL-IP: 10.181.176.18 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3LmSer9RprKuICysZwDIR5z1_OI Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Symmetric Proof of Posession for Code Extension" as an OAuth Working Group Item 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, 30 Jul 2014 14:15:16 -0000 This is a multi-part message in MIME format. --------------080209000406030304020609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yes, I support add this as a WG work item. On 7/28/14, 1:33 PM, Hannes Tschofenig wrote: > Hi all, > > during the IETF #90 OAuth WG meeting, there was strong consensus in > adopting the "OAuth Symmetric Proof of Posession for Code Extension" > (draft-sakimura-oauth-tcse-03.txt) specification as an OAuth WG work item. > > We would now like to verify the outcome of this call for adoption on the > OAuth WG mailing list. Here is the link to the document: > http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ > > If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion > as to the suitability of adopting this document as a WG work item, > please send mail to the OAuth WG list indicating your opinion (Yes/No). > > The confirmation call for adoption will last until August 10, 2014. If > you have issues/edits/comments on the document, please send these > comments along to the list in your response to this Call for Adoption. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080209000406030304020609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes, I support add this as a WG work item.
On 7/28/14, 1:33 PM, Hannes Tschofenig wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Symmetric Proof of Posession for Code Extension"
(draft-sakimura-oauth-tcse-03.txt) specification as an OAuth WG work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek




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

--------------080209000406030304020609-- From nobody Wed Jul 30 07:20:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48561A00AB for ; Wed, 30 Jul 2014 07:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F291OXulSSg6 for ; Wed, 30 Jul 2014 07:19:54 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026F71A009E for ; Wed, 30 Jul 2014 07:19:53 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id cm18so1333806qab.32 for ; Wed, 30 Jul 2014 07:19:53 -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=bmrJSGVjU5wTHt+AXtmjKmqglwt2MeY4pipnz3G3x1A=; b=N3LkfHC/KVetFhySaH3IMzP4UhAfz9qfpBn83jTriwabgImyOQahfm2DXnD2EIDUqx wLFhLvdWmiBNeOajd8hyemfWk5bmh0nhrbw80BPdccGokBfTAO91/127e0Al1rGjQ3Dk MTBkxSKLINbEzvOVhiRI1H31F+Cc7nJ604IkFo0bOggG4MACWg8DwsXSWAZ87/ZmNm6p tHA4X0LQ4/uG6M3K+AyWAowU3leP17ASJmF5jQlKUUBrnRJ4BY+OLTwN6KJUkY6b23VM 8lHLkkuIWnmGxm9j6+OtKUUKEE/JOO2JhS5RqNsiqbtas6A1g1/wsqvGIN+hD4XtPc2y Oc5g== X-Gm-Message-State: ALoCoQke2xk9pNod9FDFd0UN6XQZI+inT82yBBiWgx1rcnqFHs0KOG+zgRAqOvrpBtYszHMPkj7/ X-Received: by 10.224.40.145 with SMTP id k17mr7713905qae.4.1406729992999; Wed, 30 Jul 2014 07:19:52 -0700 (PDT) Received: from [192.168.1.216] ([190.22.79.243]) by mx.google.com with ESMTPSA id g1sm3299069qas.7.2014.07.30.07.19.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 07:19:51 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5559CF96-C1D8-45DD-85B1-163464BD83BF"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <53D8DF80.4010301@gmail.com> Date: Wed, 30 Jul 2014 10:20:08 -0400 Message-Id: <9F7C6EC9-065E-4901-B6A3-A00875675439@ve7jtb.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <53D841D3.6020505@mit.edu> <311A2204-E968-4657-BD27-58DCD072542A@oracle.com> <53D8A2A0.5040205@gmail.com> <9AF95517-3415-4A3C-A2FB-3BBDFC49E218@ve7jtb.com> <53D8DC2A.6030503@gmail.com> <7189BB03-0962-4B62-A82B-052E70B0A7DF@ve7jtb.com> <53D8DF80.4010301@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SNK68vW9OKRskcfjtMBSHWTRa3k Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 14:19:57 -0000 --Apple-Mail=_5559CF96-C1D8-45DD-85B1-163464BD83BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No worries. Some of the people in the F2F piling on with discussion derailed Hannes = original question. > during the IETF #90 OAuth WG meeting, there was strong > consensus in > adopting the "OAuth Token Introspection" > (draft-richer-oauth-introspection-06.txt) specification as an > OAuth WG > work item. >=20 > We would now like to verify the outcome of this call for > adoption on the > OAuth WG mailing list. Here is the link to the document: > = http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >=20 > If you did not hum at the IETF 90 OAuth WG meeting, and have > an opinion > as to the suitability of adopting this document as a WG work > item, > please send mail to the OAuth WG list indicating your opinion > (Yes/No). >=20 > The confirmation call for adoption will last until August 10, > 2014. If > you have issues/edits/comments on the document, please send = these > comments along to the list in your response to this Call for > Adoption. People not in the room commenting and asking questions is expected. = People who expressed opinions in the room should avoid double counting = by making it clear they hummed in the room, as our AD may not know = everyone's face and name. I don't know how I became the process monitor. Normally I am the = trouble maker. I believe what passed for consensus in the room was that this ork is in = scope for the WG and this document can serve as a starting point, but = that there are things that need to be added. I think Phil would like a use case document to flesh out peoples = understanding. Others who have been working on this longer are hesitant = that doing a use case document without adopting Justin's document as a = starting point, will stall the process. We can however adopt Justin's doc and in parallel add a use case section = as part of the doc or as a separate doc. So if you were not in the F2F hum you need to express an opinion on if = draft-richer-oauth-introspection-06.txt should be adopted by the WG = item. John B. (PS I was in the room and hummed in favour of adopting this as a work = item) On Jul 30, 2014, at 8:05 AM, Sergey Beryozkin = wrote: > Hi John > On 30/07/14 14:59, John Bradley wrote: >> No, that those of us who we're fallowing the instructions not to = comment if our hum was recorded in the room, should not hold back given = the nature of the thread has changed. >>=20 >> It was also an indication to the char that the original intent of the = thread to judge consensus is impacted by some people who previously = hummed piling on the thread. >>=20 > I think I understand, thanks for the clarifications, though it appears = to be more subtle to me that various OAuth2 technical ambiguities :-) >> I am more than fine with discussion. It probably should have been a = different thread though. >>=20 > Thanks, sorry for the noise anyway >=20 > Sergey >> John B. >> Sent from my iPhone >>=20 >>> On Jul 30, 2014, at 7:51 AM, Sergey Beryozkin = wrote: >>>=20 >>>> On 30/07/14 14:42, John Bradley wrote: >>>> This request for only those not at the F2F to add to the hum has = gone a bit off the rails. >>> Meaning you see too much feedback, is it bad, even if some of it may = be off topic ? >>>> For those not in the room there was discussion that the draft = needed a method to deal with: >>>> - Multiple AS >>>> - Supporting the PoP specs >>>> - stopping clients or other interceptors of the token from = introspecting it. >>>>=20 >>>> Justin stated that his implementation already had a number of those = features. >>>>=20 >>>> I offered to help get those into the spec as part of my support for = making this a WG item. >>>>=20 >>>> Yes if AS and RS are monolithic and there is only one software = vendor, then this is not needed. >>> Why not ? What is wrong with standardizing an introspection process = which even RS & AS from the same vendor may want to use as opposed to = every vendor inventing its own protocol ? >>>=20 >>> This is why I thought focusing on the RS to 3rd party only diverts = from the idea which I 'read' in the thread (may be I'm wrong), i.e, = standardizing on the RS-to-AS communication, which may not have been = considered, >>>=20 >>> Cheers, Sergey >>>=20 >>>>=20 >>>> On the other hand there is evidence that is not the case. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>> Sent from my iPad >>>>=20 >>>>> On Jul 30, 2014, at 3:45 AM, Sergey Beryozkin = wrote: >>>>>=20 >>>>> +1. >>>>>=20 >>>>> I've understood from what Justin said the idea is to introduce a = standard way for RS to communicate to AS about the tokens issued by the = AS. I think it is a good idea, I'd only not focus on the RS-to-3rd party = AS communications because it complicates it a bit. >>>>>=20 >>>>> Clearly it would be of help to implementers of OAuth2 filters = protecting RS, having a new lengthy process to collect the cases seems = to be a very administrative idea to me >>>>>=20 >>>>> Thanks, Sergey >>>>>=20 >>>>>> On 30/07/14 03:54, Phil Hunt wrote: >>>>>> -100 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> On Jul 29, 2014, at 17:52, Justin Richer >>>>> > wrote: >>>>>>=20 >>>>>>> Reading through this thread, it appears very clear to me that = the use >>>>>>> cases are very well established by a number of existing = implementers >>>>>>> who want to work together to build a common standard. I see no = reason >>>>>>> to delay the work artificially by creating a use case document = when >>>>>>> such a vast array of understanding and interest already exists. = Any >>>>>>> use cases and explanations of applications are welcome to be = added to >>>>>>> the working group draft as it progresses. >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 7/29/2014 8:16 PM, Mike Jones wrote: >>>>>>>>=20 >>>>>>>> Did you consider standardizing the access token format within = that >>>>>>>> deployment so all the parties that needed to could understand = it, >>>>>>>> rather requiring an extra round trip to an introspection = endpoint so >>>>>>>> as to be able to understand things about it? >>>>>>>>=20 >>>>>>>> I realize that might or might not be practical in some cases, = but I >>>>>>>> haven=E2=80=99t heard that alternative discussed, so I thought = I=E2=80=99d bring it up. >>>>>>>>=20 >>>>>>>> I also second Phil=E2=80=99s comment that it would be good to = understand the >>>>>>>> use cases that this is intended to solve before embarking on a >>>>>>>> particular solution path. >>>>>>>>=20 >>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of = *George >>>>>>>> Fletcher >>>>>>>> *Sent:* Tuesday, July 29, 2014 3:25 PM >>>>>>>> *To:* Phil Hunt; Thomas Broyer >>>>>>>> *Cc:* oauth@ietf.org >>>>>>>> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of = "OAuth >>>>>>>> Token Introspection" as an OAuth Working Group Item >>>>>>>>=20 >>>>>>>> We also have a use case where the AS is provided by a partner = and the >>>>>>>> RS is provided by AOL. Being able to have a standardized way of >>>>>>>> validating and getting data about the token from the AS would = make >>>>>>>> our implementation much simpler as we can use the same = mechanism for >>>>>>>> all Authorization Servers and not have to implement one off = solutions >>>>>>>> for each AS. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> George >>>>>>>>=20 >>>>>>>> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>>>>>>>=20 >>>>>>>> Could we have some discussion on the interop cases? >>>>>>>>=20 >>>>>>>> Is it driven by scenarios where AS and resource are separate >>>>>>>> domains? Or may this be only of interest to specific = protocols >>>>>>>> like UMA? >>>>>>>>=20 >>>>>>>> =46rom a technique principle, the draft is important and = sound. I >>>>>>>> am just not there yet on the reasons for an interoperable = standard. >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jul 28, 2014, at 17:00, Thomas Broyer >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>> Yes. This spec is of special interest to the platform = we're >>>>>>>> building for http://www.oasis-eu.org/ >>>>>>>>=20 >>>>>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>>>>>> >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> during the IETF #90 OAuth WG meeting, there was strong >>>>>>>> consensus in >>>>>>>> adopting the "OAuth Token Introspection" >>>>>>>> (draft-richer-oauth-introspection-06.txt) specification = as an >>>>>>>> OAuth WG >>>>>>>> work item. >>>>>>>>=20 >>>>>>>> We would now like to verify the outcome of this call for >>>>>>>> adoption on the >>>>>>>> OAuth WG mailing list. Here is the link to the document: >>>>>>>> = http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>>>>>>=20 >>>>>>>> If you did not hum at the IETF 90 OAuth WG meeting, and = have >>>>>>>> an opinion >>>>>>>> as to the suitability of adopting this document as a WG = work >>>>>>>> item, >>>>>>>> please send mail to the OAuth WG list indicating your = opinion >>>>>>>> (Yes/No). >>>>>>>>=20 >>>>>>>> The confirmation call for adoption will last until = August 10, >>>>>>>> 2014. If >>>>>>>> you have issues/edits/comments on the document, please = send these >>>>>>>> comments along to the list in your response to this Call = for >>>>>>>> Adoption. >>>>>>>>=20 >>>>>>>> Ciao >>>>>>>> Hannes & Derek >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Thomas Broyer >>>>>>>> /t=C9=94.ma.b=CA=81wa.je/ = >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>>=20 >>>>>>>> OAuth mailing list >>>>>>>>=20 >>>>>>>> OAuth@ietf.org >>>>>>>>=20 >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 --Apple-Mail=_5559CF96-C1D8-45DD-85B1-163464BD83BF 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 SIb3DQEJBTEPFw0xNDA3MzAxNDIwMDlaMCMGCSqGSIb3DQEJBDEWBBQlDz3lCTsp2+y9kA5zp4i+ 38HsyTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAS9gopMXUffACEbjHz3TrSOobhu+jMxbp8RD4OdwOgdxwjJFwA9fbN ax32ceLTulgoNhhi4qDdCKVHKq6V5Fc+jO2K76iOodycDPMRhabDu3N8EMWWwGXYZlEOtRVS4nwH S59KbYXxim6U7ZRaoNFsutP+1M6dc5q45xb3a8Ti106V2gcTSOW8MTdahLzeOWXkdrC1FwL3Qpth sUvLEvwPU1DOnzAch4g5dyxRvrtc7OoSBOQ6LHNsJUSxNHaWrJU33DuzdTiKzCnwEINHLlRSZ+Ds ROcXLvmEZSBcJZdITuJBMANigbyo/ASTsS+wbRUsRzFXhsGd6TIeWuqM0O1XAAAAAAAA --Apple-Mail=_5559CF96-C1D8-45DD-85B1-163464BD83BF-- From nobody Wed Jul 30 07:33:25 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972151A00FC for ; Wed, 30 Jul 2014 07:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NyD8RgmZVPG for ; Wed, 30 Jul 2014 07:33:04 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBAE1A00DF for ; Wed, 30 Jul 2014 07:32:58 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) with Microsoft SMTP Server (TLS) id 15.0.995.11; Wed, 30 Jul 2014 14:32:55 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0995.011; Wed, 30 Jul 2014 14:32:55 +0000 From: Anthony Nadalin To: John Bradley , Sergey Beryozkin Thread-Topic: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item Thread-Index: AQHPqooP8wIKNi1N/E+X2zjP/3sagZu2KzcAgAAC6YCAAXSXAIAAHzgAgAAKF4CAAACigIAAcsMAgABCDQCAAAKLAIAAAncAgAABgwCAACWpAIAAA5MY Date: Wed, 30 Jul 2014 14:32:55 +0000 Message-ID: <0b4a995ea28e40bc87fd4deab0e7dc8b@BLUPR03MB309.namprd03.prod.outlook.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <53D841D3.6020505@mit.edu> <311A2204-E968-4657-BD27-58DCD072542A@oracle.com> <53D8A2A0.5040205@gmail.com> <9AF95517-3415-4A3C-A2FB-3BBDFC49E218@ve7jtb.com> <53D8DC2A.6030503@gmail.com> <7189BB03-0962-4B62-A82B-052E70B0A7DF@ve7jtb.com> <53D8DF80.4010301@gmail.com>, <9F7C6EC9-065E-4901-B6A3-A00875675439@ve7jtb.com> In-Reply-To: <9F7C6EC9-065E-4901-B6A3-A00875675439@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.137.122.135] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(189002)(479174003)(51704005)(377454003)(199002)(51914003)(164054003)(53754006)(19625215002)(83072002)(74502001)(76482001)(2656002)(46102001)(76176999)(21056001)(33646002)(54356999)(86612001)(87936001)(74316001)(16236675004)(93886003)(86362001)(4396001)(50986999)(15202345003)(15975445006)(19580405001)(92566001)(74662001)(101416001)(31966008)(81542001)(107046002)(80022001)(81342001)(106116001)(105586002)(106356001)(85852003)(85306003)(95666004)(20776003)(79102001)(66066001)(19580395003)(99396002)(76576001)(83322001)(64706001)(77982001)(19617315012)(99286002)(108616002)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB309; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_0b4a995ea28e40bc87fd4deab0e7dc8bBLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LVAx4JpA3TLDJD2vlqz0kywZnkg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 14:33:10 -0000 --_000_0b4a995ea28e40bc87fd4deab0e7dc8bBLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9obiB0aGlzIGlzIGZvciB0aGUgcGVvcGxlIHRoYXQgZGlkIG5vdCBodW0gIGF0IHRoZSBmYWNl IHRvIGZhY2UgYW5kIG5vdCBqdXN0IGZvciB0aGUgcGVvcGxlIG5vdCAgYXQgdGhlIGZhY2UgdG8g ZmFjZS4NCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmUNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpGcm9tOiBKb2huIEJyYWRsZXk8bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29t Pg0KU2VudDog4oCONy/igI4zMC/igI4yMDE0IDc6MjAgQU0NClRvOiBTZXJnZXkgQmVyeW96a2lu PG1haWx0bzpzYmVyeW96a2luQGdtYWlsLmNvbT4NCkNjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86 b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBDb25maXJtYXRpb246IENh bGwgZm9yIEFkb3B0aW9uIG9mICJPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uIiBhcyBhbiBPQXV0 aCBXb3JraW5nIEdyb3VwIEl0ZW0NCg0KTm8gd29ycmllcy4NCg0KU29tZSBvZiB0aGUgcGVvcGxl IGluIHRoZSBGMkYgcGlsaW5nIG9uIHdpdGggZGlzY3Vzc2lvbiBkZXJhaWxlZCAgSGFubmVzIG9y aWdpbmFsIHF1ZXN0aW9uLg0KPiAgZHVyaW5nIHRoZSBJRVRGICM5MCBPQXV0aCBXRyBtZWV0aW5n LCB0aGVyZSB3YXMgc3Ryb25nDQo+ICAgICAgICBjb25zZW5zdXMgaW4NCj4gICAgICAgIGFkb3B0 aW5nIHRoZSAiT0F1dGggVG9rZW4gSW50cm9zcGVjdGlvbiINCj4gICAgICAgIChkcmFmdC1yaWNo ZXItb2F1dGgtaW50cm9zcGVjdGlvbi0wNi50eHQpIHNwZWNpZmljYXRpb24gYXMgYW4NCj4gICAg ICAgIE9BdXRoIFdHDQo+ICAgICAgICB3b3JrIGl0ZW0uDQo+DQo+ICAgICAgICBXZSB3b3VsZCBu b3cgbGlrZSB0byB2ZXJpZnkgdGhlIG91dGNvbWUgb2YgdGhpcyBjYWxsIGZvcg0KPiAgICAgICAg YWRvcHRpb24gb24gdGhlDQo+ICAgICAgICBPQXV0aCBXRyBtYWlsaW5nIGxpc3QuIEhlcmUgaXMg dGhlIGxpbmsgdG8gdGhlIGRvY3VtZW50Og0KPiAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVjdGlvbi8NCj4NCj4gICAgICAg IElmIHlvdSBkaWQgbm90IGh1bSBhdCB0aGUgSUVURiA5MCBPQXV0aCBXRyBtZWV0aW5nLCBhbmQg aGF2ZQ0KPiAgICAgICAgYW4gb3Bpbmlvbg0KPiAgICAgICAgYXMgdG8gdGhlIHN1aXRhYmlsaXR5 IG9mIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQgYXMgYSBXRyB3b3JrDQo+ICAgICAgICBpdGVtLA0K PiAgICAgICAgcGxlYXNlIHNlbmQgbWFpbCB0byB0aGUgT0F1dGggV0cgbGlzdCBpbmRpY2F0aW5n IHlvdXIgb3Bpbmlvbg0KPiAgICAgICAgKFllcy9ObykuDQo+DQo+ICAgICAgICBUaGUgY29uZmly bWF0aW9uIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgbGFzdCB1bnRpbCBBdWd1c3QgMTAsDQo+ICAg ICAgICAyMDE0LiAgSWYNCj4gICAgICAgIHlvdSBoYXZlIGlzc3Vlcy9lZGl0cy9jb21tZW50cyBv biB0aGUgZG9jdW1lbnQsIHBsZWFzZSBzZW5kIHRoZXNlDQo+ICAgICAgICBjb21tZW50cyBhbG9u ZyB0byB0aGUgbGlzdCBpbiB5b3VyIHJlc3BvbnNlIHRvIHRoaXMgQ2FsbCBmb3INCj4gICAgICAg IEFkb3B0aW9uLg0KDQpQZW9wbGUgbm90IGluIHRoZSByb29tIGNvbW1lbnRpbmcgYW5kIGFza2lu ZyBxdWVzdGlvbnMgaXMgZXhwZWN0ZWQuICAgUGVvcGxlIHdobyBleHByZXNzZWQgb3BpbmlvbnMg aW4gdGhlIHJvb20gc2hvdWxkIGF2b2lkIGRvdWJsZSBjb3VudGluZyBieSBtYWtpbmcgaXQgY2xl YXIgdGhleSBodW1tZWQgaW4gdGhlIHJvb20sIGFzIG91ciBBRCBtYXkgbm90IGtub3cgZXZlcnlv bmUncyBmYWNlIGFuZCBuYW1lLg0KDQpJIGRvbid0IGtub3cgaG93IEkgYmVjYW1lIHRoZSBwcm9j ZXNzIG1vbml0b3IuICAgTm9ybWFsbHkgSSBhbSB0aGUgdHJvdWJsZSBtYWtlci4NCg0KSSBiZWxp ZXZlIHdoYXQgcGFzc2VkIGZvciBjb25zZW5zdXMgaW4gdGhlIHJvb20gd2FzIHRoYXQgdGhpcyBv cmsgaXMgaW4gc2NvcGUgZm9yIHRoZSBXRyBhbmQgdGhpcyBkb2N1bWVudCBjYW4gc2VydmUgYXMg YSBzdGFydGluZyBwb2ludCwgYnV0IHRoYXQgdGhlcmUgYXJlIHRoaW5ncyB0aGF0IG5lZWQgdG8g YmUgYWRkZWQuDQoNCkkgdGhpbmsgUGhpbCB3b3VsZCBsaWtlIGEgdXNlIGNhc2UgZG9jdW1lbnQg dG8gZmxlc2ggb3V0IHBlb3BsZXMgdW5kZXJzdGFuZGluZy4gIE90aGVycyB3aG8gaGF2ZSBiZWVu IHdvcmtpbmcgb24gdGhpcyBsb25nZXIgYXJlIGhlc2l0YW50IHRoYXQgZG9pbmcgYSB1c2UgY2Fz ZSBkb2N1bWVudCB3aXRob3V0IGFkb3B0aW5nIEp1c3RpbidzIGRvY3VtZW50IGFzIGEgc3RhcnRp bmcgcG9pbnQsIHdpbGwgc3RhbGwgdGhlIHByb2Nlc3MuDQoNCldlIGNhbiBob3dldmVyIGFkb3B0 IEp1c3RpbidzIGRvYyBhbmQgaW4gcGFyYWxsZWwgYWRkIGEgdXNlIGNhc2Ugc2VjdGlvbiBhcyBw YXJ0IG9mIHRoZSBkb2Mgb3IgYXMgYSBzZXBhcmF0ZSBkb2MuDQoNClNvIGlmIHlvdSB3ZXJlIG5v dCBpbiB0aGUgRjJGIGh1bSB5b3UgbmVlZCB0byBleHByZXNzIGFuIG9waW5pb24gb24gaWYgZHJh ZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDYudHh0IHNob3VsZCBiZSBhZG9wdGVkIGJ5 IHRoZSBXRyBpdGVtLg0KDQpKb2huIEIuDQooUFMgSSB3YXMgaW4gdGhlIHJvb20gYW5kIGh1bW1l ZCBpbiBmYXZvdXIgb2YgYWRvcHRpbmcgdGhpcyBhcyBhIHdvcmsgaXRlbSkNCg0KT24gSnVsIDMw LCAyMDE0LCBhdCA4OjA1IEFNLCBTZXJnZXkgQmVyeW96a2luIDxzYmVyeW96a2luQGdtYWlsLmNv bT4gd3JvdGU6DQoNCj4gSGkgSm9obg0KPiBPbiAzMC8wNy8xNCAxNDo1OSwgSm9obiBCcmFkbGV5 IHdyb3RlOg0KPj4gTm8sICB0aGF0IHRob3NlIG9mIHVzIHdobyB3ZSdyZSBmYWxsb3dpbmcgdGhl IGluc3RydWN0aW9ucyBub3QgdG8gY29tbWVudCBpZiBvdXIgaHVtIHdhcyByZWNvcmRlZCBpbiB0 aGUgcm9vbSwgc2hvdWxkIG5vdCBob2xkIGJhY2sgZ2l2ZW4gdGhlIG5hdHVyZSBvZiB0aGUgdGhy ZWFkIGhhcyBjaGFuZ2VkLg0KPj4NCj4+IEl0IHdhcyBhbHNvIGFuIGluZGljYXRpb24gdG8gdGhl IGNoYXIgdGhhdCB0aGUgb3JpZ2luYWwgaW50ZW50IG9mIHRoZSB0aHJlYWQgdG8ganVkZ2UgY29u c2Vuc3VzIGlzIGltcGFjdGVkIGJ5IHNvbWUgcGVvcGxlIHdobyBwcmV2aW91c2x5IGh1bW1lZCBw aWxpbmcgb24gdGhlIHRocmVhZC4NCj4+DQo+IEkgdGhpbmsgSSB1bmRlcnN0YW5kLCB0aGFua3Mg Zm9yIHRoZSBjbGFyaWZpY2F0aW9ucywgdGhvdWdoIGl0IGFwcGVhcnMgdG8gYmUgbW9yZSBzdWJ0 bGUgdG8gbWUgdGhhdCB2YXJpb3VzIE9BdXRoMiB0ZWNobmljYWwgYW1iaWd1aXRpZXMgOi0pDQo+ PiBJIGFtIG1vcmUgdGhhbiBmaW5lIHdpdGggZGlzY3Vzc2lvbi4gIEl0IHByb2JhYmx5IHNob3Vs ZCBoYXZlIGJlZW4gYSBkaWZmZXJlbnQgdGhyZWFkIHRob3VnaC4NCj4+DQo+IFRoYW5rcywgc29y cnkgZm9yIHRoZSBub2lzZSBhbnl3YXkNCj4NCj4gU2VyZ2V5DQo+PiBKb2huIEIuDQo+PiBTZW50 IGZyb20gbXkgaVBob25lDQo+Pg0KPj4+IE9uIEp1bCAzMCwgMjAxNCwgYXQgNzo1MSBBTSwgU2Vy Z2V5IEJlcnlvemtpbiA8c2JlcnlvemtpbkBnbWFpbC5jb20+IHdyb3RlOg0KPj4+DQo+Pj4+IE9u IDMwLzA3LzE0IDE0OjQyLCBKb2huIEJyYWRsZXkgd3JvdGU6DQo+Pj4+IFRoaXMgcmVxdWVzdCBm b3Igb25seSB0aG9zZSBub3QgYXQgdGhlIEYyRiB0byBhZGQgdG8gdGhlIGh1bSBoYXMgZ29uZSBh IGJpdCBvZmYgdGhlIHJhaWxzLg0KPj4+IE1lYW5pbmcgeW91IHNlZSB0b28gbXVjaCBmZWVkYmFj aywgaXMgaXQgYmFkLCBldmVuIGlmIHNvbWUgb2YgaXQgbWF5IGJlIG9mZiB0b3BpYyA/DQo+Pj4+ IEZvciB0aG9zZSBub3QgaW4gdGhlIHJvb20gdGhlcmUgd2FzIGRpc2N1c3Npb24gdGhhdCB0aGUg ZHJhZnQgbmVlZGVkIGEgbWV0aG9kIHRvIGRlYWwgd2l0aDoNCj4+Pj4gLSBNdWx0aXBsZSBBUw0K Pj4+PiAtIFN1cHBvcnRpbmcgdGhlIFBvUCBzcGVjcw0KPj4+PiAtIHN0b3BwaW5nIGNsaWVudHMg b3Igb3RoZXIgaW50ZXJjZXB0b3JzIG9mIHRoZSB0b2tlbiBmcm9tIGludHJvc3BlY3RpbmcgaXQu DQo+Pj4+DQo+Pj4+IEp1c3RpbiBzdGF0ZWQgdGhhdCBoaXMgaW1wbGVtZW50YXRpb24gYWxyZWFk eSBoYWQgYSBudW1iZXIgb2YgdGhvc2UgZmVhdHVyZXMuDQo+Pj4+DQo+Pj4+IEkgb2ZmZXJlZCB0 byBoZWxwIGdldCB0aG9zZSBpbnRvIHRoZSBzcGVjIGFzIHBhcnQgb2YgbXkgc3VwcG9ydCBmb3Ig bWFraW5nIHRoaXMgYSBXRyBpdGVtLg0KPj4+Pg0KPj4+PiBZZXMgaWYgQVMgYW5kIFJTIGFyZSBt b25vbGl0aGljIGFuZCB0aGVyZSBpcyBvbmx5IG9uZSBzb2Z0d2FyZSB2ZW5kb3IsIHRoZW4gdGhp cyBpcyBub3QgbmVlZGVkLg0KPj4+IFdoeSBub3QgPyBXaGF0IGlzIHdyb25nIHdpdGggc3RhbmRh cmRpemluZyBhbiBpbnRyb3NwZWN0aW9uIHByb2Nlc3Mgd2hpY2ggZXZlbiBSUyAmIEFTIGZyb20g dGhlIHNhbWUgdmVuZG9yIG1heSB3YW50IHRvIHVzZSBhcyBvcHBvc2VkIHRvIGV2ZXJ5IHZlbmRv ciBpbnZlbnRpbmcgaXRzIG93biBwcm90b2NvbCA/DQo+Pj4NCj4+PiBUaGlzIGlzIHdoeSBJIHRo b3VnaHQgZm9jdXNpbmcgb24gdGhlIFJTIHRvIDNyZCBwYXJ0eSBvbmx5IGRpdmVydHMgZnJvbSB0 aGUgaWRlYSB3aGljaCBJICdyZWFkJyBpbiB0aGUgdGhyZWFkIChtYXkgYmUgSSdtIHdyb25nKSwg aS5lLCBzdGFuZGFyZGl6aW5nIG9uIHRoZSBSUy10by1BUyBjb21tdW5pY2F0aW9uLCB3aGljaCBt YXkgbm90IGhhdmUgYmVlbiBjb25zaWRlcmVkLA0KPj4+DQo+Pj4gQ2hlZXJzLCBTZXJnZXkNCj4+ Pg0KPj4+Pg0KPj4+PiBPbiB0aGUgb3RoZXIgaGFuZCB0aGVyZSBpcyBldmlkZW5jZSB0aGF0IGlz IG5vdCB0aGUgY2FzZS4NCj4+Pj4NCj4+Pj4gSm9obiBCLg0KPj4+Pg0KPj4+Pg0KPj4+PiBTZW50 IGZyb20gbXkgaVBhZA0KPj4+Pg0KPj4+Pj4gT24gSnVsIDMwLCAyMDE0LCBhdCAzOjQ1IEFNLCBT ZXJnZXkgQmVyeW96a2luIDxzYmVyeW96a2luQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4+Pg0KPj4+ Pj4gKzEuDQo+Pj4+Pg0KPj4+Pj4gSSd2ZSB1bmRlcnN0b29kIGZyb20gd2hhdCBKdXN0aW4gc2Fp ZCB0aGUgaWRlYSBpcyB0byBpbnRyb2R1Y2UgYSBzdGFuZGFyZCB3YXkgZm9yIFJTIHRvIGNvbW11 bmljYXRlIHRvIEFTIGFib3V0IHRoZSB0b2tlbnMgaXNzdWVkIGJ5IHRoZSBBUy4gSSB0aGluayBp dCBpcyBhIGdvb2QgaWRlYSwgSSdkIG9ubHkgbm90IGZvY3VzIG9uIHRoZSBSUy10by0zcmQgcGFy dHkgQVMgY29tbXVuaWNhdGlvbnMgYmVjYXVzZSBpdCBjb21wbGljYXRlcyBpdCBhIGJpdC4NCj4+ Pj4+DQo+Pj4+PiBDbGVhcmx5IGl0IHdvdWxkIGJlIG9mIGhlbHAgdG8gaW1wbGVtZW50ZXJzIG9m IE9BdXRoMiBmaWx0ZXJzIHByb3RlY3RpbmcgUlMsIGhhdmluZyBhIG5ldyBsZW5ndGh5IHByb2Nl c3MgdG8gY29sbGVjdCB0aGUgY2FzZXMgc2VlbXMgdG8gYmUgYSB2ZXJ5IGFkbWluaXN0cmF0aXZl IGlkZWEgdG8gbWUNCj4+Pj4+DQo+Pj4+PiBUaGFua3MsIFNlcmdleQ0KPj4+Pj4NCj4+Pj4+PiBP biAzMC8wNy8xNCAwMzo1NCwgUGhpbCBIdW50IHdyb3RlOg0KPj4+Pj4+IC0xMDANCj4+Pj4+Pg0K Pj4+Pj4+IFBoaWwNCj4+Pj4+Pg0KPj4+Pj4+IE9uIEp1bCAyOSwgMjAxNCwgYXQgMTc6NTIsIEp1 c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdQ0KPj4+Pj4+IDxtYWlsdG86anJpY2hlckBtaXQu ZWR1Pj4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+Pj4gUmVhZGluZyB0aHJvdWdoIHRoaXMgdGhyZWFk LCBpdCBhcHBlYXJzIHZlcnkgY2xlYXIgdG8gbWUgdGhhdCB0aGUgdXNlDQo+Pj4+Pj4+IGNhc2Vz IGFyZSB2ZXJ5IHdlbGwgZXN0YWJsaXNoZWQgYnkgYSBudW1iZXIgb2YgZXhpc3RpbmcgaW1wbGVt ZW50ZXJzDQo+Pj4+Pj4+IHdobyB3YW50IHRvIHdvcmsgdG9nZXRoZXIgdG8gYnVpbGQgYSBjb21t b24gc3RhbmRhcmQuIEkgc2VlIG5vIHJlYXNvbg0KPj4+Pj4+PiB0byBkZWxheSB0aGUgd29yayBh cnRpZmljaWFsbHkgYnkgY3JlYXRpbmcgYSB1c2UgY2FzZSBkb2N1bWVudCB3aGVuDQo+Pj4+Pj4+ IHN1Y2ggYSB2YXN0IGFycmF5IG9mIHVuZGVyc3RhbmRpbmcgYW5kIGludGVyZXN0IGFscmVhZHkg ZXhpc3RzLiBBbnkNCj4+Pj4+Pj4gdXNlIGNhc2VzIGFuZCBleHBsYW5hdGlvbnMgb2YgYXBwbGlj YXRpb25zIGFyZSB3ZWxjb21lIHRvIGJlIGFkZGVkIHRvDQo+Pj4+Pj4+IHRoZSB3b3JraW5nIGdy b3VwIGRyYWZ0IGFzIGl0IHByb2dyZXNzZXMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0tIEp1c3Rpbg0K Pj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gNy8yOS8yMDE0IDg6MTYgUE0sIE1pa2UgSm9u ZXMgd3JvdGU6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRGlkIHlvdSBjb25zaWRlciBzdGFuZGFyZGl6 aW5nIHRoZSBhY2Nlc3MgdG9rZW4gZm9ybWF0IHdpdGhpbiB0aGF0DQo+Pj4+Pj4+PiBkZXBsb3lt ZW50IHNvIGFsbCB0aGUgcGFydGllcyB0aGF0IG5lZWRlZCB0byBjb3VsZCB1bmRlcnN0YW5kIGl0 LA0KPj4+Pj4+Pj4gcmF0aGVyIHJlcXVpcmluZyBhbiBleHRyYSByb3VuZCB0cmlwIHRvIGFuIGlu dHJvc3BlY3Rpb24gZW5kcG9pbnQgc28NCj4+Pj4+Pj4+IGFzIHRvIGJlIGFibGUgdG8gdW5kZXJz dGFuZCB0aGluZ3MgYWJvdXQgaXQ/DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSSByZWFsaXplIHRoYXQg bWlnaHQgb3IgbWlnaHQgbm90IGJlIHByYWN0aWNhbCBpbiBzb21lIGNhc2VzLCBidXQgSQ0KPj4+ Pj4+Pj4gaGF2ZW7igJl0IGhlYXJkIHRoYXQgYWx0ZXJuYXRpdmUgZGlzY3Vzc2VkLCBzbyBJIHRo b3VnaHQgSeKAmWQgYnJpbmcgaXQgdXAuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSSBhbHNvIHNlY29u ZCBQaGls4oCZcyBjb21tZW50IHRoYXQgaXQgd291bGQgYmUgZ29vZCB0byB1bmRlcnN0YW5kIHRo ZQ0KPj4+Pj4+Pj4gdXNlIGNhc2VzIHRoYXQgdGhpcyBpcyBpbnRlbmRlZCB0byBzb2x2ZSBiZWZv cmUgZW1iYXJraW5nIG9uIGENCj4+Pj4+Pj4+IHBhcnRpY3VsYXIgc29sdXRpb24gcGF0aC4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiAtLSBNaWtlDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gKkZyb206Kk9BdXRo IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqR2VvcmdlDQo+ Pj4+Pj4+PiBGbGV0Y2hlcg0KPj4+Pj4+Pj4gKlNlbnQ6KiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0 IDM6MjUgUE0NCj4+Pj4+Pj4+ICpUbzoqIFBoaWwgSHVudDsgVGhvbWFzIEJyb3llcg0KPj4+Pj4+ Pj4gKkNjOiogb2F1dGhAaWV0Zi5vcmcNCj4+Pj4+Pj4+ICpTdWJqZWN0OiogUmU6IFtPQVVUSC1X R10gQ29uZmlybWF0aW9uOiBDYWxsIGZvciBBZG9wdGlvbiBvZiAiT0F1dGgNCj4+Pj4+Pj4+IFRv a2VuIEludHJvc3BlY3Rpb24iIGFzIGFuIE9BdXRoIFdvcmtpbmcgR3JvdXAgSXRlbQ0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+IFdlIGFsc28gaGF2ZSBhIHVzZSBjYXNlIHdoZXJlIHRoZSBBUyBpcyBwcm92 aWRlZCBieSBhIHBhcnRuZXIgYW5kIHRoZQ0KPj4+Pj4+Pj4gUlMgaXMgcHJvdmlkZWQgYnkgQU9M LiBCZWluZyBhYmxlIHRvIGhhdmUgYSBzdGFuZGFyZGl6ZWQgd2F5IG9mDQo+Pj4+Pj4+PiB2YWxp ZGF0aW5nIGFuZCBnZXR0aW5nIGRhdGEgYWJvdXQgdGhlIHRva2VuIGZyb20gdGhlIEFTIHdvdWxk IG1ha2UNCj4+Pj4+Pj4+IG91ciBpbXBsZW1lbnRhdGlvbiBtdWNoIHNpbXBsZXIgYXMgd2UgY2Fu IHVzZSB0aGUgc2FtZSBtZWNoYW5pc20gZm9yDQo+Pj4+Pj4+PiBhbGwgQXV0aG9yaXphdGlvbiBT ZXJ2ZXJzIGFuZCBub3QgaGF2ZSB0byBpbXBsZW1lbnQgb25lIG9mZiBzb2x1dGlvbnMNCj4+Pj4+ Pj4+IGZvciBlYWNoIEFTLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4+IEdl b3JnZQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE9uIDcvMjgvMTQsIDg6MTEgUE0sIFBoaWwgSHVudCB3 cm90ZToNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICBDb3VsZCB3ZSBoYXZlIHNvbWUgZGlzY3Vzc2lv biBvbiB0aGUgaW50ZXJvcCBjYXNlcz8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICBJcyBpdCBkcml2 ZW4gYnkgc2NlbmFyaW9zIHdoZXJlIEFTIGFuZCByZXNvdXJjZSBhcmUgc2VwYXJhdGUNCj4+Pj4+ Pj4+ICAgIGRvbWFpbnM/IE9yIG1heSB0aGlzIGJlIG9ubHkgb2YgaW50ZXJlc3QgdG8gc3BlY2lm aWMgcHJvdG9jb2xzDQo+Pj4+Pj4+PiAgICBsaWtlIFVNQT8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAg ICBGcm9tIGEgdGVjaG5pcXVlIHByaW5jaXBsZSwgdGhlIGRyYWZ0IGlzIGltcG9ydGFudCBhbmQg c291bmQuIEkNCj4+Pj4+Pj4+ICAgIGFtIGp1c3Qgbm90IHRoZXJlIHlldCBvbiB0aGUgcmVhc29u cyBmb3IgYW4gaW50ZXJvcGVyYWJsZSBzdGFuZGFyZC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICBQ aGlsDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgIE9uIEp1bCAyOCwgMjAxNCwgYXQg MTc6MDAsIFRob21hcyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbQ0KPj4+Pj4+Pj4gICAgPG1h aWx0bzp0LmJyb3llckBnbWFpbC5jb20+PiB3cm90ZToNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAg ICAgWWVzLiBUaGlzIHNwZWMgaXMgb2Ygc3BlY2lhbCBpbnRlcmVzdCB0byB0aGUgcGxhdGZvcm0g d2UncmUNCj4+Pj4+Pj4+ICAgICAgICBidWlsZGluZyBmb3IgaHR0cDovL3d3dy5vYXNpcy1ldS5v cmcvDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgIE9uIE1vbiwgSnVsIDI4LCAyMDE0IGF0IDc6 MzMgUE0sIEhhbm5lcyBUc2Nob2ZlbmlnDQo+Pj4+Pj4+PiAgICAgICAgPGhhbm5lcy50c2Nob2Zl bmlnQGdteC5uZXQNCj4+Pj4+Pj4+ICAgICAgICA8bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdt eC5uZXQ+PiB3cm90ZToNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgICAgSGkgYWxsLA0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+ICAgICAgICBkdXJpbmcgdGhlIElFVEYgIzkwIE9BdXRoIFdHIG1lZXRpbmcs IHRoZXJlIHdhcyBzdHJvbmcNCj4+Pj4+Pj4+ICAgICAgICBjb25zZW5zdXMgaW4NCj4+Pj4+Pj4+ ICAgICAgICBhZG9wdGluZyB0aGUgIk9BdXRoIFRva2VuIEludHJvc3BlY3Rpb24iDQo+Pj4+Pj4+ PiAgICAgICAgKGRyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLTA2LnR4dCkgc3BlY2lm aWNhdGlvbiBhcyBhbg0KPj4+Pj4+Pj4gICAgICAgIE9BdXRoIFdHDQo+Pj4+Pj4+PiAgICAgICAg d29yayBpdGVtLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAgICBXZSB3b3VsZCBub3cgbGlrZSB0 byB2ZXJpZnkgdGhlIG91dGNvbWUgb2YgdGhpcyBjYWxsIGZvcg0KPj4+Pj4+Pj4gICAgICAgIGFk b3B0aW9uIG9uIHRoZQ0KPj4+Pj4+Pj4gICAgICAgIE9BdXRoIFdHIG1haWxpbmcgbGlzdC4gSGVy ZSBpcyB0aGUgbGluayB0byB0aGUgZG9jdW1lbnQ6DQo+Pj4+Pj4+PiAgICAgICAgaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVjdGlvbi8N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgICAgSWYgeW91IGRpZCBub3QgaHVtIGF0IHRoZSBJRVRG IDkwIE9BdXRoIFdHIG1lZXRpbmcsIGFuZCBoYXZlDQo+Pj4+Pj4+PiAgICAgICAgYW4gb3Bpbmlv bg0KPj4+Pj4+Pj4gICAgICAgIGFzIHRvIHRoZSBzdWl0YWJpbGl0eSBvZiBhZG9wdGluZyB0aGlz IGRvY3VtZW50IGFzIGEgV0cgd29yaw0KPj4+Pj4+Pj4gICAgICAgIGl0ZW0sDQo+Pj4+Pj4+PiAg ICAgICAgcGxlYXNlIHNlbmQgbWFpbCB0byB0aGUgT0F1dGggV0cgbGlzdCBpbmRpY2F0aW5nIHlv dXIgb3Bpbmlvbg0KPj4+Pj4+Pj4gICAgICAgIChZZXMvTm8pLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ ICAgICAgICBUaGUgY29uZmlybWF0aW9uIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgbGFzdCB1bnRp bCBBdWd1c3QgMTAsDQo+Pj4+Pj4+PiAgICAgICAgMjAxNC4gIElmDQo+Pj4+Pj4+PiAgICAgICAg eW91IGhhdmUgaXNzdWVzL2VkaXRzL2NvbW1lbnRzIG9uIHRoZSBkb2N1bWVudCwgcGxlYXNlIHNl bmQgdGhlc2UNCj4+Pj4+Pj4+ICAgICAgICBjb21tZW50cyBhbG9uZyB0byB0aGUgbGlzdCBpbiB5 b3VyIHJlc3BvbnNlIHRvIHRoaXMgQ2FsbCBmb3INCj4+Pj4+Pj4+ICAgICAgICBBZG9wdGlvbi4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgICAgQ2lhbw0KPj4+Pj4+Pj4gICAgICAgIEhhbm5lcyAm IERlcmVrDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4gICAgICAgIE9BdXRo IG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4gICAgICAgIE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1 dGhAaWV0Zi5vcmc+DQo+Pj4+Pj4+PiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g ICAgICAgIC0tDQo+Pj4+Pj4+PiAgICAgICAgVGhvbWFzIEJyb3llcg0KPj4+Pj4+Pj4gICAgICAg IC90yZQubWEuYsqBd2EuamUvIDxodHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8+DQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+Pj4+PiAgICAgICAgT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+ Pj4+PiAgICAgICAgT0F1dGhAaWV0Zi5vcmcgPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+Pj4+ Pj4+ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiAgICBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICBPQXV0aEBp ZXRmLm9yZyAgPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBP QXV0aEBpZXRmLm9yZw0KPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aA0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+ Pj4+IE9BdXRoQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4+IE9BdXRo QGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQo+Pj4NCg0K --_000_0b4a995ea28e40bc87fd4deab0e7dc8bBLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+Sm9obiB0aGlzIGlzIGZvciB0aGUgcGVv cGxlIHRoYXQgZGlkIG5vdCBodW0mbmJzcDsgYXQgdGhlIGZhY2UgdG8gZmFjZSBhbmQgbm90IGp1 c3QgZm9yIHRoZSBwZW9wbGUgbm90Jm5ic3A7IGF0IHRoZSBmYWNlIHRvIGZhY2UuPGJyPg0KPGJy Pg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0 ciI+DQo8aHI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBm b250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbToNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJl Zj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj5Kb2huIEJyYWRsZXk8L2E+PC9zcGFuPjxicj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTox MXB0OyBmb250LXdlaWdodDpib2xkIj5TZW50Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij7igI43L+KAjjMwL+KAjjIw MTQgNzoyMCBBTTwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxz YW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+VG86DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjEx cHQiPjxhIGhyZWY9Im1haWx0bzpzYmVyeW96a2luQGdtYWlsLmNvbSI+U2VyZ2V5IEJlcnlvemtp bjwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z ZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPkNjOg0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij48 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjwvc3Bhbj48 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNp emU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+UmU6IFtPQVVU SC1XR10gQ29uZmlybWF0aW9uOiBDYWxsIGZvciBBZG9wdGlvbiBvZiAmcXVvdDtPQXV0aCBUb2tl biBJbnRyb3NwZWN0aW9uJnF1b3Q7IGFzIGFuIE9BdXRoIFdvcmtpbmcgR3JvdXAgSXRlbTwvc3Bh bj48YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPk5vIHdvcnJpZXMuPGJy Pg0KPGJyPg0KU29tZSBvZiB0aGUgcGVvcGxlIGluIHRoZSBGMkYgcGlsaW5nIG9uIHdpdGggZGlz Y3Vzc2lvbiBkZXJhaWxlZCZuYnNwOyBIYW5uZXMgb3JpZ2luYWwgcXVlc3Rpb24uPGJyPg0KJmd0 OyZuYnNwOyBkdXJpbmcgdGhlIElFVEYgIzkwIE9BdXRoIFdHIG1lZXRpbmcsIHRoZXJlIHdhcyBz dHJvbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNvbnNlbnN1cyBpbjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgYWRvcHRpbmcgdGhlICZxdW90O09BdXRoIFRva2VuIEludHJvc3BlY3Rpb24mcXVv dDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChk cmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVjdGlvbi0wNi50eHQpIHNwZWNpZmljYXRpb24gYXMg YW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9B dXRoIFdHPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB3b3JrIGl0ZW0uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdlIHdvdWxkIG5vdyBsaWtlIHRvIHZlcmlmeSB0aGUgb3V0Y29t ZSBvZiB0aGlzIGNhbGwgZm9yPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBhZG9wdGlvbiBvbiB0aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoIFdHIG1haWxpbmcgbGlzdC4gSGVyZSBpcyB0 aGUgbGluayB0byB0aGUgZG9jdW1lbnQ6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLyI+DQpodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJpY2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLzwvYT48YnI+ DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgSWYgeW91IGRpZCBub3QgaHVtIGF0IHRoZSBJRVRGIDkwIE9BdXRoIFdHIG1lZXRpbmcsIGFu ZCBoYXZlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBhbiBvcGluaW9uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBhcyB0byB0aGUgc3VpdGFiaWxpdHkgb2YgYWRvcHRpbmcgdGhpcyBkb2N1bWVudCBh cyBhIFdHIHdvcms8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGl0ZW0sPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBwbGVhc2Ugc2VuZCBtYWlsIHRvIHRoZSBPQXV0aCBXRyBsaXN0IGluZGljYXRpbmcg eW91ciBvcGluaW9uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAoWWVzL05vKS48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGNvbmZpcm1hdGlvbiBjYWxsIGZvciBhZG9wdGlv biB3aWxsIGxhc3QgdW50aWwgQXVndXN0IDEwLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAxNC4mbmJzcDsgSWY8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHlvdSBoYXZlIGlzc3Vlcy9lZGl0cy9j b21tZW50cyBvbiB0aGUgZG9jdW1lbnQsIHBsZWFzZSBzZW5kIHRoZXNlPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb21tZW50cyBhbG9uZyB0byB0 aGUgbGlzdCBpbiB5b3VyIHJlc3BvbnNlIHRvIHRoaXMgQ2FsbCBmb3I8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFkb3B0aW9uLjxicj4NCjxicj4N ClBlb3BsZSBub3QgaW4gdGhlIHJvb20gY29tbWVudGluZyBhbmQgYXNraW5nIHF1ZXN0aW9ucyBp cyBleHBlY3RlZC4mbmJzcDsmbmJzcDsgUGVvcGxlIHdobyBleHByZXNzZWQgb3BpbmlvbnMgaW4g dGhlIHJvb20gc2hvdWxkIGF2b2lkIGRvdWJsZSBjb3VudGluZyBieSBtYWtpbmcgaXQgY2xlYXIg dGhleSBodW1tZWQgaW4gdGhlIHJvb20sIGFzIG91ciBBRCBtYXkgbm90IGtub3cgZXZlcnlvbmUn cyBmYWNlIGFuZCBuYW1lLjxicj4NCjxicj4NCkkgZG9uJ3Qga25vdyBob3cgSSBiZWNhbWUgdGhl IHByb2Nlc3MgbW9uaXRvci4mbmJzcDsmbmJzcDsgTm9ybWFsbHkgSSBhbSB0aGUgdHJvdWJsZSBt YWtlci48YnI+DQo8YnI+DQpJIGJlbGlldmUgd2hhdCBwYXNzZWQgZm9yIGNvbnNlbnN1cyBpbiB0 aGUgcm9vbSB3YXMgdGhhdCB0aGlzIG9yayBpcyBpbiBzY29wZSBmb3IgdGhlIFdHIGFuZCB0aGlz IGRvY3VtZW50IGNhbiBzZXJ2ZSBhcyBhIHN0YXJ0aW5nIHBvaW50LCBidXQgdGhhdCB0aGVyZSBh cmUgdGhpbmdzIHRoYXQgbmVlZCB0byBiZSBhZGRlZC48YnI+DQo8YnI+DQpJIHRoaW5rIFBoaWwg d291bGQgbGlrZSBhIHVzZSBjYXNlIGRvY3VtZW50IHRvIGZsZXNoIG91dCBwZW9wbGVzIHVuZGVy c3RhbmRpbmcuJm5ic3A7IE90aGVycyB3aG8gaGF2ZSBiZWVuIHdvcmtpbmcgb24gdGhpcyBsb25n ZXIgYXJlIGhlc2l0YW50IHRoYXQgZG9pbmcgYSB1c2UgY2FzZSBkb2N1bWVudCB3aXRob3V0IGFk b3B0aW5nIEp1c3RpbidzIGRvY3VtZW50IGFzIGEgc3RhcnRpbmcgcG9pbnQsIHdpbGwgc3RhbGwg dGhlIHByb2Nlc3MuPGJyPg0KPGJyPg0KV2UgY2FuIGhvd2V2ZXIgYWRvcHQgSnVzdGluJ3MgZG9j IGFuZCBpbiBwYXJhbGxlbCBhZGQgYSB1c2UgY2FzZSBzZWN0aW9uIGFzIHBhcnQgb2YgdGhlIGRv YyBvciBhcyBhIHNlcGFyYXRlIGRvYy48YnI+DQo8YnI+DQpTbyBpZiB5b3Ugd2VyZSBub3QgaW4g dGhlIEYyRiBodW0geW91IG5lZWQgdG8gZXhwcmVzcyBhbiBvcGluaW9uIG9uIGlmIGRyYWZ0LXJp Y2hlci1vYXV0aC1pbnRyb3NwZWN0aW9uLTA2LnR4dCBzaG91bGQgYmUgYWRvcHRlZCBieSB0aGUg V0cgaXRlbS48YnI+DQo8YnI+DQpKb2huIEIuPGJyPg0KKFBTIEkgd2FzIGluIHRoZSByb29tIGFu ZCBodW1tZWQgaW4gZmF2b3VyIG9mIGFkb3B0aW5nIHRoaXMgYXMgYSB3b3JrIGl0ZW0pPGJyPg0K PGJyPg0KT24gSnVsIDMwLCAyMDE0LCBhdCA4OjA1IEFNLCBTZXJnZXkgQmVyeW96a2luICZsdDtz YmVyeW96a2luQGdtYWlsLmNvbSZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBIaSBKb2huPGJy Pg0KJmd0OyBPbiAzMC8wNy8xNCAxNDo1OSwgSm9obiBCcmFkbGV5IHdyb3RlOjxicj4NCiZndDsm Z3Q7IE5vLCZuYnNwOyB0aGF0IHRob3NlIG9mIHVzIHdobyB3ZSdyZSBmYWxsb3dpbmcgdGhlIGlu c3RydWN0aW9ucyBub3QgdG8gY29tbWVudCBpZiBvdXIgaHVtIHdhcyByZWNvcmRlZCBpbiB0aGUg cm9vbSwgc2hvdWxkIG5vdCBob2xkIGJhY2sgZ2l2ZW4gdGhlIG5hdHVyZSBvZiB0aGUgdGhyZWFk IGhhcyBjaGFuZ2VkLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEl0IHdhcyBhbHNvIGFu IGluZGljYXRpb24gdG8gdGhlIGNoYXIgdGhhdCB0aGUgb3JpZ2luYWwgaW50ZW50IG9mIHRoZSB0 aHJlYWQgdG8ganVkZ2UgY29uc2Vuc3VzIGlzIGltcGFjdGVkIGJ5IHNvbWUgcGVvcGxlIHdobyBw cmV2aW91c2x5IGh1bW1lZCBwaWxpbmcgb24gdGhlIHRocmVhZC48YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7IEkgdGhpbmsgSSB1bmRlcnN0YW5kLCB0aGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9u cywgdGhvdWdoIGl0IGFwcGVhcnMgdG8gYmUgbW9yZSBzdWJ0bGUgdG8gbWUgdGhhdCB2YXJpb3Vz IE9BdXRoMiB0ZWNobmljYWwgYW1iaWd1aXRpZXMgOi0pPGJyPg0KJmd0OyZndDsgSSBhbSBtb3Jl IHRoYW4gZmluZSB3aXRoIGRpc2N1c3Npb24uJm5ic3A7IEl0IHByb2JhYmx5IHNob3VsZCBoYXZl IGJlZW4gYSBkaWZmZXJlbnQgdGhyZWFkIHRob3VnaC48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7 IFRoYW5rcywgc29ycnkgZm9yIHRoZSBub2lzZSBhbnl3YXk8YnI+DQomZ3Q7IDxicj4NCiZndDsg U2VyZ2V5PGJyPg0KJmd0OyZndDsgSm9obiBCLjxicj4NCiZndDsmZ3Q7IFNlbnQgZnJvbSBteSBp UGhvbmU8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgT24gSnVsIDMwLCAyMDE0LCBh dCA3OjUxIEFNLCBTZXJnZXkgQmVyeW96a2luICZsdDtzYmVyeW96a2luQGdtYWlsLmNvbSZndDsg d3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgT24gMzAvMDcv MTQgMTQ6NDIsIEpvaG4gQnJhZGxleSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMg cmVxdWVzdCBmb3Igb25seSB0aG9zZSBub3QgYXQgdGhlIEYyRiB0byBhZGQgdG8gdGhlIGh1bSBo YXMgZ29uZSBhIGJpdCBvZmYgdGhlIHJhaWxzLjxicj4NCiZndDsmZ3Q7Jmd0OyBNZWFuaW5nIHlv dSBzZWUgdG9vIG11Y2ggZmVlZGJhY2ssIGlzIGl0IGJhZCwgZXZlbiBpZiBzb21lIG9mIGl0IG1h eSBiZSBvZmYgdG9waWMgPzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgRm9yIHRob3NlIG5vdCBpbiB0 aGUgcm9vbSB0aGVyZSB3YXMgZGlzY3Vzc2lvbiB0aGF0IHRoZSBkcmFmdCBuZWVkZWQgYSBtZXRo b2QgdG8gZGVhbCB3aXRoOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgLSBNdWx0aXBsZSBBUzxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgLSBTdXBwb3J0aW5nIHRoZSBQb1Agc3BlY3M8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IC0gc3RvcHBpbmcgY2xpZW50cyBvciBvdGhlciBpbnRlcmNlcHRvcnMgb2YgdGhl IHRva2VuIGZyb20gaW50cm9zcGVjdGluZyBpdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgSnVzdGluIHN0YXRlZCB0aGF0IGhpcyBpbXBsZW1lbnRhdGlvbiBh bHJlYWR5IGhhZCBhIG51bWJlciBvZiB0aG9zZSBmZWF0dXJlcy48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSSBvZmZlcmVkIHRvIGhlbHAgZ2V0IHRob3NlIGlu dG8gdGhlIHNwZWMgYXMgcGFydCBvZiBteSBzdXBwb3J0IGZvciBtYWtpbmcgdGhpcyBhIFdHIGl0 ZW0uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFllcyBpZiBB UyBhbmQgUlMgYXJlIG1vbm9saXRoaWMgYW5kIHRoZXJlIGlzIG9ubHkgb25lIHNvZnR3YXJlIHZl bmRvciwgdGhlbiB0aGlzIGlzIG5vdCBuZWVkZWQuPGJyPg0KJmd0OyZndDsmZ3Q7IFdoeSBub3Qg PyBXaGF0IGlzIHdyb25nIHdpdGggc3RhbmRhcmRpemluZyBhbiBpbnRyb3NwZWN0aW9uIHByb2Nl c3Mgd2hpY2ggZXZlbiBSUyAmYW1wOyBBUyBmcm9tIHRoZSBzYW1lIHZlbmRvciBtYXkgd2FudCB0 byB1c2UgYXMgb3Bwb3NlZCB0byBldmVyeSB2ZW5kb3IgaW52ZW50aW5nIGl0cyBvd24gcHJvdG9j b2wgPzxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgVGhpcyBpcyB3aHkgSSB0 aG91Z2h0IGZvY3VzaW5nIG9uIHRoZSBSUyB0byAzcmQgcGFydHkgb25seSBkaXZlcnRzIGZyb20g dGhlIGlkZWEgd2hpY2ggSSAncmVhZCcgaW4gdGhlIHRocmVhZCAobWF5IGJlIEknbSB3cm9uZyks IGkuZSwgc3RhbmRhcmRpemluZyBvbiB0aGUgUlMtdG8tQVMgY29tbXVuaWNhdGlvbiwgd2hpY2gg bWF5IG5vdCBoYXZlIGJlZW4gY29uc2lkZXJlZCw8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7IENoZWVycywgU2VyZ2V5PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbiB0aGUgb3RoZXIgaGFuZCB0aGVyZSBp cyBldmlkZW5jZSB0aGF0IGlzIG5vdCB0aGUgY2FzZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgSm9obiBCLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQgZnJvbSBteSBpUGFk PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBKdWwg MzAsIDIwMTQsIGF0IDM6NDUgQU0sIFNlcmdleSBCZXJ5b3praW4gJmx0O3NiZXJ5b3praW5AZ21h aWwuY29tJmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmIzQzOzEuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSSd2ZSB1bmRlcnN0b29kIGZyb20gd2hhdCBKdXN0aW4gc2FpZCB0 aGUgaWRlYSBpcyB0byBpbnRyb2R1Y2UgYSBzdGFuZGFyZCB3YXkgZm9yIFJTIHRvIGNvbW11bmlj YXRlIHRvIEFTIGFib3V0IHRoZSB0b2tlbnMgaXNzdWVkIGJ5IHRoZSBBUy4gSSB0aGluayBpdCBp cyBhIGdvb2QgaWRlYSwgSSdkIG9ubHkgbm90IGZvY3VzIG9uIHRoZSBSUy10by0zcmQgcGFydHkg QVMgY29tbXVuaWNhdGlvbnMgYmVjYXVzZSBpdCBjb21wbGljYXRlcw0KIGl0IGEgYml0Ljxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENsZWFybHkg aXQgd291bGQgYmUgb2YgaGVscCB0byBpbXBsZW1lbnRlcnMgb2YgT0F1dGgyIGZpbHRlcnMgcHJv dGVjdGluZyBSUywgaGF2aW5nIGEgbmV3IGxlbmd0aHkgcHJvY2VzcyB0byBjb2xsZWN0IHRoZSBj YXNlcyBzZWVtcyB0byBiZSBhIHZlcnkgYWRtaW5pc3RyYXRpdmUgaWRlYSB0byBtZTxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcywgU2Vy Z2V5PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IE9uIDMwLzA3LzE0IDAzOjU0LCBQaGlsIEh1bnQgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IC0xMDA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBoaWw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIEp1bCAyOSwgMjAxNCwgYXQgMTc6NTIs IEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSI+bWFpbHRvOmpyaWNo ZXJAbWl0LmVkdTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZWFkaW5nIHRocm91Z2ggdGhp cyB0aHJlYWQsIGl0IGFwcGVhcnMgdmVyeSBjbGVhciB0byBtZSB0aGF0IHRoZSB1c2U8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNhc2VzIGFyZSB2ZXJ5IHdlbGwgZXN0YWJsaXNo ZWQgYnkgYSBudW1iZXIgb2YgZXhpc3RpbmcgaW1wbGVtZW50ZXJzPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB3aG8gd2FudCB0byB3b3JrIHRvZ2V0aGVyIHRvIGJ1aWxkIGEgY29t bW9uIHN0YW5kYXJkLiBJIHNlZSBubyByZWFzb248YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRvIGRlbGF5IHRoZSB3b3JrIGFydGlmaWNpYWxseSBieSBjcmVhdGluZyBhIHVzZSBj YXNlIGRvY3VtZW50IHdoZW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN1Y2gg YSB2YXN0IGFycmF5IG9mIHVuZGVyc3RhbmRpbmcgYW5kIGludGVyZXN0IGFscmVhZHkgZXhpc3Rz LiBBbnk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVzZSBjYXNlcyBhbmQgZXhw bGFuYXRpb25zIG9mIGFwcGxpY2F0aW9ucyBhcmUgd2VsY29tZSB0byBiZSBhZGRlZCB0bzxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIHdvcmtpbmcgZ3JvdXAgZHJhZnQgYXMg aXQgcHJvZ3Jlc3Nlcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0gSnVzdGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMjkvMjAxNCA4OjE2IFBNLCBNaWtl IEpvbmVzIHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERpZCB5b3UgY29uc2lkZXIgc3RhbmRh cmRpemluZyB0aGUgYWNjZXNzIHRva2VuIGZvcm1hdCB3aXRoaW4gdGhhdDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRlcGxveW1lbnQgc28gYWxsIHRoZSBwYXJ0aWVzIHRo YXQgbmVlZGVkIHRvIGNvdWxkIHVuZGVyc3RhbmQgaXQsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgcmF0aGVyIHJlcXVpcmluZyBhbiBleHRyYSByb3VuZCB0cmlwIHRvIGFu IGludHJvc3BlY3Rpb24gZW5kcG9pbnQgc288YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBhcyB0byBiZSBhYmxlIHRvIHVuZGVyc3RhbmQgdGhpbmdzIGFib3V0IGl0Pzxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IEkgcmVhbGl6ZSB0aGF0IG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBwcmFj dGljYWwgaW4gc29tZSBjYXNlcywgYnV0IEk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBoYXZlbuKAmXQgaGVhcmQgdGhhdCBhbHRlcm5hdGl2ZSBkaXNjdXNzZWQsIHNvIEkg dGhvdWdodCBJ4oCZZCBicmluZyBpdCB1cC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGFsc28gc2Vj b25kIFBoaWzigJlzIGNvbW1lbnQgdGhhdCBpdCB3b3VsZCBiZSBnb29kIHRvIHVuZGVyc3RhbmQg dGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdXNlIGNhc2VzIHRoYXQg dGhpcyBpcyBpbnRlbmRlZCB0byBzb2x2ZSBiZWZvcmUgZW1iYXJraW5nIG9uIGE8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXJ0aWN1bGFyIHNvbHV0aW9uIHBhdGguPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgLS0gTWlrZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpGcm9tOipPQXV0 aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnPC9hPl0gKk9uIEJlaGFsZiBPZiAqR2VvcmdlPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRmxldGNoZXI8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAqU2VudDoqIFR1ZXNkYXksIEp1bHkgMjksIDIwMTQgMzoyNSBQTTxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpUbzoqIFBoaWwgSHVudDsgVGhvbWFz IEJyb3llcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpDYzoqIG9hdXRo QGlldGYub3JnPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlN1YmplY3Q6 KiBSZTogW09BVVRILVdHXSBDb25maXJtYXRpb246IENhbGwgZm9yIEFkb3B0aW9uIG9mICZxdW90 O09BdXRoPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG9rZW4gSW50cm9z cGVjdGlvbiZxdW90OyBhcyBhbiBPQXV0aCBXb3JraW5nIEdyb3VwIEl0ZW08YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBXZSBhbHNvIGhhdmUgYSB1c2UgY2FzZSB3aGVyZSB0aGUgQVMgaXMgcHJvdmlkZWQg YnkgYSBwYXJ0bmVyIGFuZCB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBSUyBpcyBwcm92aWRlZCBieSBBT0wuIEJlaW5nIGFibGUgdG8gaGF2ZSBhIHN0YW5kYXJkaXpl ZCB3YXkgb2Y8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB2YWxpZGF0aW5n IGFuZCBnZXR0aW5nIGRhdGEgYWJvdXQgdGhlIHRva2VuIGZyb20gdGhlIEFTIHdvdWxkIG1ha2U8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvdXIgaW1wbGVtZW50YXRpb24g bXVjaCBzaW1wbGVyIGFzIHdlIGNhbiB1c2UgdGhlIHNhbWUgbWVjaGFuaXNtIGZvcjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFsbCBBdXRob3JpemF0aW9uIFNlcnZlcnMg YW5kIG5vdCBoYXZlIHRvIGltcGxlbWVudCBvbmUgb2ZmIHNvbHV0aW9uczxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZvciBlYWNoIEFTLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBHZW9yZ2U8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBPbiA3LzI4LzE0LCA4OjExIFBNLCBQaGlsIEh1bnQgd3JvdGU6PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQ291bGQgd2UgaGF2ZSBzb21lIGRp c2N1c3Npb24gb24gdGhlIGludGVyb3AgY2FzZXM/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsgSXMgaXQgZHJpdmVuIGJ5IHNjZW5hcmlvcyB3aGVyZSBBUyBhbmQgcmVzb3Vy Y2UgYXJlIHNlcGFyYXRlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsgZG9tYWlucz8gT3IgbWF5IHRoaXMgYmUgb25seSBvZiBpbnRlcmVzdCB0 byBzcGVjaWZpYyBwcm90b2NvbHM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyBsaWtlIFVNQT88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBGcm9tIGEgdGVjaG5pcXVlIHByaW5jaXBsZSwgdGhlIGRyYWZ0IGlzIGltcG9y dGFudCBhbmQgc291bmQuIEk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBhbSBqdXN0IG5vdCB0aGVyZSB5ZXQgb24gdGhlIHJlYXNvbnMgZm9y IGFuIGludGVyb3BlcmFibGUgc3RhbmRhcmQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsgUGhpbDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIEp1bCAyOCwgMjAxNCwgYXQgMTc6 MDAsIFRob21hcyBCcm95ZXIgJmx0O3QuYnJveWVyQGdtYWlsLmNvbTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWls dG86dC5icm95ZXJAZ21haWwuY29tIj5tYWlsdG86dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDsm Z3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFllcy4gVGhpcyBzcGVjIGlzIG9mIHNwZWNpYWwgaW50ZXJlc3QgdG8g dGhlIHBsYXRmb3JtIHdlJ3JlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnVpbGRpbmcgZm9yIDxh IGhyZWY9Imh0dHA6Ly93d3cub2FzaXMtZXUub3JnLyI+aHR0cDovL3d3dy5vYXNpcy1ldS5vcmcv PC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IE9uIE1vbiwgSnVsIDI4LCAyMDE0IGF0IDc6MzMgUE0sIEhhbm5lcyBUc2Nob2Zl bmlnPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2hhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2Zl bmlnQGdteC5uZXQiPm1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDsmZ3Q7 IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEhpIGFsbCw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkdXJpbmcgdGhlIElFVEYgIzkwIE9BdXRoIFdHIG1l ZXRpbmcsIHRoZXJlIHdhcyBzdHJvbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25zZW5zdXMg aW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhZG9wdGluZyB0aGUgJnF1b3Q7T0F1dGggVG9rZW4g SW50cm9zcGVjdGlvbiZxdW90Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChkcmFmdC1yaWNoZXIt b2F1dGgtaW50cm9zcGVjdGlvbi0wNi50eHQpIHNwZWNpZmljYXRpb24gYXMgYW48YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBPQXV0aCBXRzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdvcmsgaXRlbS48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBXZSB3b3VsZCBub3cgbGlrZSB0byB2ZXJpZnkgdGhlIG91dGNvbWUgb2YgdGhpcyBjYWxs IGZvcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFkb3B0aW9uIG9uIHRoZTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IE9BdXRoIFdHIG1haWxpbmcgbGlzdC4gSGVyZSBpcyB0aGUgbGluayB0byB0aGUg ZG9jdW1lbnQ6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVjdGlvbi8iPg0KaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVj dGlvbi88L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSWYgeW91IGRpZCBub3QgaHVtIGF0IHRoZSBJRVRGIDkwIE9BdXRoIFdH IG1lZXRpbmcsIGFuZCBoYXZlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW4gb3Bpbmlvbjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzIHRvIHRoZSBzdWl0YWJpbGl0eSBvZiBhZG9wdGluZyB0aGlz IGRvY3VtZW50IGFzIGEgV0cgd29yazxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGl0ZW0sPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgcGxlYXNlIHNlbmQgbWFpbCB0byB0aGUgT0F1dGggV0cgbGlzdCBp bmRpY2F0aW5nIHlvdXIgb3Bpbmlvbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChZZXMvTm8pLjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFRoZSBjb25maXJtYXRpb24gY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBsYXN0IHVudGlsIEF1 Z3VzdCAxMCw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDE0LiZuYnNwOyBJZjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHlvdSBoYXZlIGlzc3Vlcy9lZGl0cy9jb21tZW50cyBvbiB0aGUgZG9jdW1l bnQsIHBsZWFzZSBzZW5kIHRoZXNlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29tbWVudHMgYWxv bmcgdG8gdGhlIGxpc3QgaW4geW91ciByZXNwb25zZSB0byB0aGlzIENhbGwgZm9yPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgQWRvcHRpb24uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2lhbzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEhhbm5lcyAmYW1wOyBEZXJlazxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgT0F1dGhAaWV0Zi5vcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+ bWFpbHRvOk9BdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhvbWFzIEJyb3llcjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC90yZQubWEuYsqBd2EuamUvICZsdDs8YSBocmVmPSJodHRwOi8veG4t LW5uYS5tYS54bi0tYndhLXh4Yi5qZS8iPmh0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhiLmpl LzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBPQXV0aEBpZXRmLm9yZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIj5tYWlsdG86T0F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyBPQXV0aEBpZXRmLm9yZyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIj5tYWlsdG86T0F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+ PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoQGll dGYub3JnPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJy Pg0KJmd0OyZndDsmZ3Q7IDxicj4NCjxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_0b4a995ea28e40bc87fd4deab0e7dc8bBLUPR03MB309namprd03pro_-- From nobody Wed Jul 30 09:14:09 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CBE1A0137 for ; Wed, 30 Jul 2014 09:14:05 -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 mL1at1NPmCQx for ; Wed, 30 Jul 2014 09:14:00 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A768E1A0250 for ; Wed, 30 Jul 2014 09:13:59 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id j5so1866065qga.1 for ; Wed, 30 Jul 2014 09:13:58 -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=bsKnlEQ3LtFHSjf7prOCFM8nGPiQqwv7henCTgzH2iQ=; b=hvVqBWJQU3f6ZIldHJ/0KN/z80QX7/O1hJdWYX5b+UeRgZ0eE1dm6/dlifRxIH99Bo NfvEjrlvBmarpibe0S6g7NpevzAJA7MXD6tEEh8ejq3FmjemYVhow72GPCTkqCMiX3w/ Vyox2ffr8XsKe4MH9ecGGsyhAWXNFCJF7Pjw5Iii1uJ4clgHw/acYkzVBoJnIHidQu9e 9Q3O6d36YsNQTfuw3OzanlKTup8j20upPbho7rGu9ApPimIcK7ZwVtuz3L5wrlwT3vrP Kw2QgGwqSGqh1uzwFftAIzvlpC9hO/VtULBFhfT32MoAxqo7msuvTRNcSUovUi2v/6Rp HcFQ== X-Gm-Message-State: ALoCoQmuYOqNqk1fDY8+UcVFa1brTW4Bxt7H5EjRrQAna755P82X89d5/Wl93qaYCy1n9qC/dIcq X-Received: by 10.224.88.3 with SMTP id y3mr175961qal.65.1406736838187; Wed, 30 Jul 2014 09:13:58 -0700 (PDT) Received: from [192.168.1.216] ([190.22.2.211]) by mx.google.com with ESMTPSA id u42sm2945528qga.46.2014.07.30.09.13.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 09:13:55 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_22221617-7E57-489C-A1DD-AA6ACE968C9A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <0b4a995ea28e40bc87fd4deab0e7dc8b@BLUPR03MB309.namprd03.prod.outlook.com> Date: Wed, 30 Jul 2014 12:14:24 -0400 Message-Id: <861917D8-B9AD-4E82-A216-C58E40CEA468@ve7jtb.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <53D841D3.6020505@mit.edu> <311A2204-E968-4657-BD27-58DCD072542A@oracle.com> <53D8A2A0.5040205@gmail.com> <9AF95517-3415-4A3C-A2FB-3BBDFC49E218@ve7jtb.com> <53D8DC2A.6030503@gmail.com> <7189BB03-0962-4B62-A82B-052E70B0A7DF@ve7jtb.com> <53D8DF80.4010301@gmail.com>, <9F7C6EC9-065E-4901-B6A3-A00875675439@ve7jtb.com> <0b4a995ea28e40bc87fd4deab0e7dc8b@BLUPR03MB309.namprd03.prod.outlook.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/yDBcdCk_mk9EMXY8uRz7e3IIEnI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 16:14:06 -0000 --Apple-Mail=_22221617-7E57-489C-A1DD-AA6ACE968C9A Content-Type: multipart/alternative; boundary="Apple-Mail=_EF4039F5-97F4-4CCA-ABC9-60F654B10DB8" --Apple-Mail=_EF4039F5-97F4-4CCA-ABC9-60F654B10DB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Interesting point. I defer to your greater hum experience:) On Jul 30, 2014, at 10:32 AM, Anthony Nadalin = wrote: > John this is for the people that did not hum at the face to face and = not just for the people not at the face to face. >=20 > Sent from my Windows Phone > From: John Bradley > Sent: =E2=80=8E7/=E2=80=8E30/=E2=80=8E2014 7:20 AM > To: Sergey Beryozkin > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth = Token Introspection" as an OAuth Working Group Item >=20 > No worries. >=20 > Some of the people in the F2F piling on with discussion derailed = Hannes original question. > > during the IETF #90 OAuth WG meeting, there was strong > > consensus in > > adopting the "OAuth Token Introspection" > > (draft-richer-oauth-introspection-06.txt) specification as an > > OAuth WG > > work item. > >=20 > > We would now like to verify the outcome of this call for > > adoption on the > > OAuth WG mailing list. Here is the link to the document: > > = http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ > >=20 > > If you did not hum at the IETF 90 OAuth WG meeting, and have > > an opinion > > as to the suitability of adopting this document as a WG work > > item, > > please send mail to the OAuth WG list indicating your opinion > > (Yes/No). > >=20 > > The confirmation call for adoption will last until August 10, > > 2014. If > > you have issues/edits/comments on the document, please send = these > > comments along to the list in your response to this Call for > > Adoption. >=20 > People not in the room commenting and asking questions is expected. = People who expressed opinions in the room should avoid double counting = by making it clear they hummed in the room, as our AD may not know = everyone's face and name. >=20 > I don't know how I became the process monitor. Normally I am the = trouble maker. >=20 > I believe what passed for consensus in the room was that this ork is = in scope for the WG and this document can serve as a starting point, but = that there are things that need to be added. >=20 > I think Phil would like a use case document to flesh out peoples = understanding. Others who have been working on this longer are hesitant = that doing a use case document without adopting Justin's document as a = starting point, will stall the process. >=20 > We can however adopt Justin's doc and in parallel add a use case = section as part of the doc or as a separate doc. >=20 > So if you were not in the F2F hum you need to express an opinion on if = draft-richer-oauth-introspection-06.txt should be adopted by the WG = item. >=20 > John B. > (PS I was in the room and hummed in favour of adopting this as a work = item) >=20 > On Jul 30, 2014, at 8:05 AM, Sergey Beryozkin = wrote: >=20 > > Hi John > > On 30/07/14 14:59, John Bradley wrote: > >> No, that those of us who we're fallowing the instructions not to = comment if our hum was recorded in the room, should not hold back given = the nature of the thread has changed. > >>=20 > >> It was also an indication to the char that the original intent of = the thread to judge consensus is impacted by some people who previously = hummed piling on the thread. > >>=20 > > I think I understand, thanks for the clarifications, though it = appears to be more subtle to me that various OAuth2 technical = ambiguities :-) > >> I am more than fine with discussion. It probably should have been = a different thread though. > >>=20 > > Thanks, sorry for the noise anyway > >=20 > > Sergey > >> John B. > >> Sent from my iPhone > >>=20 > >>> On Jul 30, 2014, at 7:51 AM, Sergey Beryozkin = wrote: > >>>=20 > >>>> On 30/07/14 14:42, John Bradley wrote: > >>>> This request for only those not at the F2F to add to the hum has = gone a bit off the rails. > >>> Meaning you see too much feedback, is it bad, even if some of it = may be off topic ? > >>>> For those not in the room there was discussion that the draft = needed a method to deal with: > >>>> - Multiple AS > >>>> - Supporting the PoP specs > >>>> - stopping clients or other interceptors of the token from = introspecting it. > >>>>=20 > >>>> Justin stated that his implementation already had a number of = those features. > >>>>=20 > >>>> I offered to help get those into the spec as part of my support = for making this a WG item. > >>>>=20 > >>>> Yes if AS and RS are monolithic and there is only one software = vendor, then this is not needed. > >>> Why not ? What is wrong with standardizing an introspection = process which even RS & AS from the same vendor may want to use as = opposed to every vendor inventing its own protocol ? > >>>=20 > >>> This is why I thought focusing on the RS to 3rd party only diverts = from the idea which I 'read' in the thread (may be I'm wrong), i.e, = standardizing on the RS-to-AS communication, which may not have been = considered, > >>>=20 > >>> Cheers, Sergey > >>>=20 > >>>>=20 > >>>> On the other hand there is evidence that is not the case. > >>>>=20 > >>>> John B. > >>>>=20 > >>>>=20 > >>>> Sent from my iPad > >>>>=20 > >>>>> On Jul 30, 2014, at 3:45 AM, Sergey Beryozkin = wrote: > >>>>>=20 > >>>>> +1. > >>>>>=20 > >>>>> I've understood from what Justin said the idea is to introduce a = standard way for RS to communicate to AS about the tokens issued by the = AS. I think it is a good idea, I'd only not focus on the RS-to-3rd party = AS communications because it complicates it a bit. > >>>>>=20 > >>>>> Clearly it would be of help to implementers of OAuth2 filters = protecting RS, having a new lengthy process to collect the cases seems = to be a very administrative idea to me > >>>>>=20 > >>>>> Thanks, Sergey > >>>>>=20 > >>>>>> On 30/07/14 03:54, Phil Hunt wrote: > >>>>>> -100 > >>>>>>=20 > >>>>>> Phil > >>>>>>=20 > >>>>>> On Jul 29, 2014, at 17:52, Justin Richer >>>>>> > wrote: > >>>>>>=20 > >>>>>>> Reading through this thread, it appears very clear to me that = the use > >>>>>>> cases are very well established by a number of existing = implementers > >>>>>>> who want to work together to build a common standard. I see no = reason > >>>>>>> to delay the work artificially by creating a use case document = when > >>>>>>> such a vast array of understanding and interest already = exists. Any > >>>>>>> use cases and explanations of applications are welcome to be = added to > >>>>>>> the working group draft as it progresses. > >>>>>>>=20 > >>>>>>> -- Justin > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>> On 7/29/2014 8:16 PM, Mike Jones wrote: > >>>>>>>>=20 > >>>>>>>> Did you consider standardizing the access token format within = that > >>>>>>>> deployment so all the parties that needed to could understand = it, > >>>>>>>> rather requiring an extra round trip to an introspection = endpoint so > >>>>>>>> as to be able to understand things about it? > >>>>>>>>=20 > >>>>>>>> I realize that might or might not be practical in some cases, = but I > >>>>>>>> haven=E2=80=99t heard that alternative discussed, so I = thought I=E2=80=99d bring it up. > >>>>>>>>=20 > >>>>>>>> I also second Phil=E2=80=99s comment that it would be good to = understand the > >>>>>>>> use cases that this is intended to solve before embarking on = a > >>>>>>>> particular solution path. > >>>>>>>>=20 > >>>>>>>> -- Mike > >>>>>>>>=20 > >>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of = *George > >>>>>>>> Fletcher > >>>>>>>> *Sent:* Tuesday, July 29, 2014 3:25 PM > >>>>>>>> *To:* Phil Hunt; Thomas Broyer > >>>>>>>> *Cc:* oauth@ietf.org > >>>>>>>> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of = "OAuth > >>>>>>>> Token Introspection" as an OAuth Working Group Item > >>>>>>>>=20 > >>>>>>>> We also have a use case where the AS is provided by a partner = and the > >>>>>>>> RS is provided by AOL. Being able to have a standardized way = of > >>>>>>>> validating and getting data about the token from the AS would = make > >>>>>>>> our implementation much simpler as we can use the same = mechanism for > >>>>>>>> all Authorization Servers and not have to implement one off = solutions > >>>>>>>> for each AS. > >>>>>>>>=20 > >>>>>>>> Thanks, > >>>>>>>> George > >>>>>>>>=20 > >>>>>>>> On 7/28/14, 8:11 PM, Phil Hunt wrote: > >>>>>>>>=20 > >>>>>>>> Could we have some discussion on the interop cases? > >>>>>>>>=20 > >>>>>>>> Is it driven by scenarios where AS and resource are = separate > >>>>>>>> domains? Or may this be only of interest to specific = protocols > >>>>>>>> like UMA? > >>>>>>>>=20 > >>>>>>>> =46rom a technique principle, the draft is important and = sound. I > >>>>>>>> am just not there yet on the reasons for an interoperable = standard. > >>>>>>>>=20 > >>>>>>>> Phil > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> On Jul 28, 2014, at 17:00, Thomas Broyer = >>>>>>>> > wrote: > >>>>>>>>=20 > >>>>>>>> Yes. This spec is of special interest to the platform = we're > >>>>>>>> building for http://www.oasis-eu.org/ > >>>>>>>>=20 > >>>>>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig > >>>>>>>> >>>>>>>> > wrote: > >>>>>>>>=20 > >>>>>>>> Hi all, > >>>>>>>>=20 > >>>>>>>> during the IETF #90 OAuth WG meeting, there was strong > >>>>>>>> consensus in > >>>>>>>> adopting the "OAuth Token Introspection" > >>>>>>>> (draft-richer-oauth-introspection-06.txt) = specification as an > >>>>>>>> OAuth WG > >>>>>>>> work item. > >>>>>>>>=20 > >>>>>>>> We would now like to verify the outcome of this call = for > >>>>>>>> adoption on the > >>>>>>>> OAuth WG mailing list. Here is the link to the = document: > >>>>>>>> = http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ > >>>>>>>>=20 > >>>>>>>> If you did not hum at the IETF 90 OAuth WG meeting, = and have > >>>>>>>> an opinion > >>>>>>>> as to the suitability of adopting this document as a = WG work > >>>>>>>> item, > >>>>>>>> please send mail to the OAuth WG list indicating your = opinion > >>>>>>>> (Yes/No). > >>>>>>>>=20 > >>>>>>>> The confirmation call for adoption will last until = August 10, > >>>>>>>> 2014. If > >>>>>>>> you have issues/edits/comments on the document, please = send these > >>>>>>>> comments along to the list in your response to this = Call for > >>>>>>>> Adoption. > >>>>>>>>=20 > >>>>>>>> Ciao > >>>>>>>> Hannes & Derek > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> _______________________________________________ > >>>>>>>> OAuth mailing list > >>>>>>>> OAuth@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> -- > >>>>>>>> Thomas Broyer > >>>>>>>> /t=C9=94.ma.b=CA=81wa.je/ = > >>>>>>>>=20 > >>>>>>>> _______________________________________________ > >>>>>>>> OAuth mailing list > >>>>>>>> OAuth@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> _______________________________________________ > >>>>>>>>=20 > >>>>>>>> OAuth mailing list > >>>>>>>>=20 > >>>>>>>> OAuth@ietf.org > >>>>>>>>=20 > >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> _______________________________________________ > >>>>>>>> OAuth mailing list > >>>>>>>> OAuth@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>=20 > >>>>>>=20 > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>=20 > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>> --Apple-Mail=_EF4039F5-97F4-4CCA-ABC9-60F654B10DB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Interesting point.  I defer to your greater hum = experience:)

On Jul 30, 2014, at 10:32 AM, Anthony = Nadalin <tonynad@microsoft.com> = wrote:

John this is for the people that did not hum  at = the face to face and not just for the people not  at the face to = face.

Sent from my Windows Phone
From: John Bradley
Sent: =E2=80=8E7/=E2=80=8E30/=E2=80=8E2014 7:20 AM
To: Sergey = Beryozkin
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token = Introspection" as an OAuth Working Group = Item

No worries.

Some of the people in the F2F piling on with = discussion derailed  Hannes original question.
>  during = the IETF #90 OAuth WG meeting, there was = strong
>        consensus = in
>        adopting the "OAuth = Token Introspection"
>        = (draft-richer-oauth-introspection-06.txt) specification as = an
>        OAuth = WG
>        work = item.
> 
>        We = would now like to verify the outcome of this call = for
>        adoption on = the
>        OAuth WG mailing = list. Here is the link to the = document:
>        http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/
= > 
>        If you did = not hum at the IETF 90 OAuth WG meeting, and = have
>        an = opinion
>        as to the = suitability of adopting this document as a WG = work
>        = item,
>        please send mail = to the OAuth WG list indicating your = opinion
>        = (Yes/No).
> 
>        = The confirmation call for adoption will last until August = 10,
>        2014.  = If
>        you have = issues/edits/comments on the document, please send = these
>        comments along = to the list in your response to this Call = for
>        = Adoption.

People not in the room commenting and asking questions = is expected.   People who expressed opinions in the room = should avoid double counting by making it clear they hummed in the room, = as our AD may not know everyone's face and name.

I don't know how = I became the process monitor.   Normally I am the trouble = maker.

I believe what passed for consensus in the room was that = this ork is in scope for the WG and this document can serve as a = starting point, but that there are things that need to be = added.

I think Phil would like a use case document to flesh out = peoples understanding.  Others who have been working on this longer = are hesitant that doing a use case document without adopting Justin's = document as a starting point, will stall the process.

We can = however adopt Justin's doc and in parallel add a use case section as = part of the doc or as a separate doc.

So if you were not in the = F2F hum you need to express an opinion on if = draft-richer-oauth-introspection-06.txt should be adopted by the WG = item.

John B.
(PS I was in the room and hummed in favour of = adopting this as a work item)

On Jul 30, 2014, at 8:05 AM, Sergey = Beryozkin <sberyozkin@gmail.com> = wrote:

> Hi John
> On 30/07/14 14:59, John Bradley = wrote:
>> No,  that those of us who we're fallowing the = instructions not to comment if our hum was recorded in the room, should = not hold back given the nature of the thread has = changed.
>> 
>> It was also an indication to the = char that the original intent of the thread to judge consensus is = impacted by some people who previously hummed piling on the = thread.
>> 
> I think I understand, thanks for the = clarifications, though it appears to be more subtle to me that various = OAuth2 technical ambiguities :-)
>> I am more than fine with = discussion.  It probably should have been a different thread = though.
>> 
> Thanks, sorry for the noise = anyway
> 
> Sergey
>> John B.
>> Sent = from my iPhone
>> 
>>> On Jul 30, 2014, at = 7:51 AM, Sergey Beryozkin <sberyozkin@gmail.com> = wrote:
>>> 
>>>> On 30/07/14 14:42, John = Bradley wrote:
>>>> This request for only those not at = the F2F to add to the hum has gone a bit off the rails.
>>> = Meaning you see too much feedback, is it bad, even if some of it may be = off topic ?
>>>> For those not in the room there was = discussion that the draft needed a method to deal = with:
>>>> - Multiple AS
>>>> - Supporting = the PoP specs
>>>> - stopping clients or other = interceptors of the token from introspecting = it.
>>>> 
>>>> Justin stated that his = implementation already had a number of those = features.
>>>> 
>>>> I offered to = help get those into the spec as part of my support for making this a WG = item.
>>>> 
>>>> Yes if AS and RS are = monolithic and there is only one software vendor, then this is not = needed.
>>> Why not ? What is wrong with standardizing an = introspection process which even RS & AS from the same vendor may = want to use as opposed to every vendor inventing its own protocol = ?
>>> 
>>> This is why I thought focusing = on the RS to 3rd party only diverts from the idea which I 'read' in the = thread (may be I'm wrong), i.e, standardizing on the RS-to-AS = communication, which may not have been = considered,
>>> 
>>> Cheers, = Sergey
>>> 
>>>> 
>>>>= On the other hand there is evidence that is not the = case.
>>>> 
>>>> John = B.
>>>> 
>>>> 
>>>>= Sent from my iPad
>>>> 
>>>>> On = Jul 30, 2014, at 3:45 AM, Sergey Beryozkin <sberyozkin@gmail.com> = wrote:
>>>>> 
>>>>> = +1.
>>>>> 
>>>>> I've = understood from what Justin said the idea is to introduce a standard way = for RS to communicate to AS about the tokens issued by the AS. I think = it is a good idea, I'd only not focus on the RS-to-3rd party AS = communications because it complicates it a = bit.
>>>>> 
>>>>> Clearly it = would be of help to implementers of OAuth2 filters protecting RS, having = a new lengthy process to collect the cases seems to be a very = administrative idea to = me
>>>>> 
>>>>> Thanks, = Sergey
>>>>> 
>>>>>> On = 30/07/14 03:54, Phil Hunt wrote:
>>>>>> = -100
>>>>>> 
>>>>>> = Phil
>>>>>> 
>>>>>> On = Jul 29, 2014, at 17:52, Justin Richer <jricher@mit.edu
>>>>>= ;> <mailto:jricher@mit.edu>> = wrote:
>>>>>> 
>>>>>>> = Reading through this thread, it appears very clear to me that the = use
>>>>>>> cases are very well established by a = number of existing implementers
>>>>>>> who want = to work together to build a common standard. I see no = reason
>>>>>>> to delay the work artificially by = creating a use case document when
>>>>>>> such a = vast array of understanding and interest already exists. = Any
>>>>>>> use cases and explanations of = applications are welcome to be added to
>>>>>>> = the working group draft as it = progresses.
>>>>>>> 
>>>>>&= gt;> -- = Justin
>>>>>>> 
>>>>>>&g= t; 
>>>>>>>> On 7/29/2014 8:16 PM, Mike = Jones = wrote:
>>>>>>>> 
>>>>>&g= t;>> Did you consider standardizing the access token format within = that
>>>>>>>> deployment so all the parties = that needed to could understand it,
>>>>>>>> = rather requiring an extra round trip to an introspection endpoint = so
>>>>>>>> as to be able to understand = things about = it?
>>>>>>>> 
>>>>>>&= gt;> I realize that might or might not be practical in some cases, = but I
>>>>>>>> haven=E2=80=99t heard that = alternative discussed, so I thought I=E2=80=99d bring it = up.
>>>>>>>> 
>>>>>>&= gt;> I also second Phil=E2=80=99s comment that it would be good to = understand the
>>>>>>>> use cases that this = is intended to solve before embarking on = a
>>>>>>>> particular solution = path.
>>>>>>>> 
>>>>>>= ;>> -- = Mike
>>>>>>>> 
>>>>>>= >> *From:*OAuth [mailto:oauth-bounces@ietf.org] = *On Behalf Of *George
>>>>>>>> = Fletcher
>>>>>>>> *Sent:* Tuesday, July 29, = 2014 3:25 PM
>>>>>>>> *To:* Phil Hunt; Thomas = Broyer
>>>>>>>> *Cc:* oauth@ietf.org
>>>>>&= gt;>> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of = "OAuth
>>>>>>>> Token Introspection" as an = OAuth Working Group = Item
>>>>>>>> 
>>>>>>= >> We also have a use case where the AS is provided by a partner = and the
>>>>>>>> RS is provided by AOL. Being = able to have a standardized way of
>>>>>>>> = validating and getting data about the token from the AS would = make
>>>>>>>> our implementation much simpler = as we can use the same mechanism for
>>>>>>>> = all Authorization Servers and not have to implement one off = solutions
>>>>>>>> for each = AS.
>>>>>>>> 
>>>>>>&= gt;> Thanks,
>>>>>>>> = George
>>>>>>>> 
>>>>>&g= t;>> On 7/28/14, 8:11 PM, Phil Hunt = wrote:
>>>>>>>> 
>>>>>&g= t;>>    Could we have some discussion on the = interop = cases?
>>>>>>>> 
>>>>>&g= t;>>    Is it driven by scenarios where AS and = resource are = separate
>>>>>>>>    domains? = Or may this be only of interest to specific = protocols
>>>>>>>>    like = UMA?
>>>>>>>> 
>>>>>>= >>    =46rom a technique principle, the draft is = important and sound. = I
>>>>>>>>    am just not = there yet on the reasons for an interoperable = standard.
>>>>>>>> 
>>>>>= ;>>>    = Phil
>>>>>>>> 
>>>>>>= >> 
>>>>>>>>    On = Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com
>>>&= gt;>>>>    <mailto:t.broyer@gmail.com>> = wrote:
>>>>>>>> 
>>>>>&g= t;>>        Yes. This spec is = of special interest to the platform = we're
>>>>>>>>     &nb= sp;  building for http://www.oasis-eu.org/
>>= >>>>>> 
>>>>>>>> &n= bsp;      On Mon, Jul 28, 2014 at 7:33 PM, = Hannes = Tschofenig
>>>>>>>>    &nbs= p;   <hannes.tschofenig@gmx.net>>>>>>>>       = ; <mailto:hannes.tschofenig@gmx.net= >> = wrote:
>>>>>>>> 
>>>>>&g= t;>>        Hi = all,
>>>>>>>> 
>>>>>>= >>        during the IETF #90 = OAuth WG meeting, there was = strong
>>>>>>>>     &n= bsp;  consensus = in
>>>>>>>>      =   adopting the "OAuth Token = Introspection"
>>>>>>>>    =     (draft-richer-oauth-introspection-06.txt) = specification as = an
>>>>>>>>      =   OAuth = WG
>>>>>>>>      =   work = item.
>>>>>>>> 
>>>>>>= ;>>        We would now like to = verify the outcome of this call = for
>>>>>>>>      = ;  adoption on = the
>>>>>>>>      = ;  OAuth WG mailing list. Here is the link to the = document:
>>>>>>>>     = ;   http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/
= >>>>>>>> 
>>>>>>>>=         If you did not hum at the = IETF 90 OAuth WG meeting, and = have
>>>>>>>>     &nbs= p;  an = opinion
>>>>>>>>     &= nbsp;  as to the suitability of adopting this document as a WG = work
>>>>>>>>     &nbs= p;  = item,
>>>>>>>>     &nb= sp;  please send mail to the OAuth WG list indicating your = opinion
>>>>>>>>     &= nbsp;  = (Yes/No).
>>>>>>>> 
>>>>>= ;>>>        The confirmation = call for adoption will last until August = 10,
>>>>>>>>      = ;  2014.  = If
>>>>>>>>      =   you have issues/edits/comments on the document, please send = these
>>>>>>>>     &nb= sp;  comments along to the list in your response to this Call = for
>>>>>>>>      = ;  = Adoption.
>>>>>>>> 
>>>>>= ;>>>        = Ciao
>>>>>>>>     &nbs= p;  Hannes & = Derek
>>>>>>>> 
>>>>>>= ;>> 
>>>>>>>>    = ;    = _______________________________________________
>>>>>>= ;>>        OAuth mailing = list
>>>>>>>>     &nbs= p;  OAuth@ietf.org <mailto:OAuth@ietf.org>
>>&g= t;>>>>>        https://www.ietf.org/= mailman/listinfo/oauth
>>>>>>>> 
&g= t;>>>>>>> 
>>>>>>>>&n= bsp;
>>>>>>>>     &nbs= p;  = --
>>>>>>>>      =   Thomas = Broyer
>>>>>>>>     &n= bsp;  /t=C9=94.ma.b=CA=81wa.je/ <http://xn--nna.ma.xn--bwa-xxb.j= e/>
>>>>>>>> 
>>>>&g= t;>>>        = _______________________________________________
>>>>>>= ;>>        OAuth mailing = list
>>>>>>>>     &nbs= p;  OAuth@ietf.org <mailto:OAuth@ietf.org>
>>&g= t;>>>>>        https://www.ietf.org/= mailman/listinfo/oauth
>>>>>>>> 
&g= t;>>>>>>> 
>>>>>>>>&n= bsp;
>>>>>>>> 
>>>>>>= >>    = _______________________________________________
>>>>>>= ;>> 
>>>>>>>>    = OAuth mailing = list
>>>>>>>> 
>>>>>>= >>    OAuth@ietf.org  <mailto:OAuth@ietf.org>
>>&g= t;>>>>> 
>>>>>>>> &nbs= p;  https://www.ietf.org/= mailman/listinfo/oauth
>>>>>>>> 
&g= t;>>>>>>> 
>>>>>>>>&n= bsp;
>>>>>>>> = _______________________________________________
>>>>>>= ;>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>&= gt;>> https://www.ietf.org/= mailman/listinfo/oauth
>>>>>> 
>>&g= t;>>> 
>>>>>> = _______________________________________________
>>>>>>= ; OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>&= gt; https://www.ietf.org/= mailman/listinfo/oauth
>>>>> 
>>>&g= t;> = _______________________________________________
>>>>> = OAuth mailing list
>>>>> OAuth@ietf.org
>>>>>&= nbsp;https://www.ietf.org/= mailman/listinfo/oauth
>>>

= --Apple-Mail=_EF4039F5-97F4-4CCA-ABC9-60F654B10DB8-- --Apple-Mail=_22221617-7E57-489C-A1DD-AA6ACE968C9A 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 SIb3DQEJBTEPFw0xNDA3MzAxNjE0MjRaMCMGCSqGSIb3DQEJBDEWBBSaRHLBJfTVi8SVe6Tmn20K dGQZzjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCvTftVR1AQYVkG2mIcaMYdicbcTSMJn0qJOkHxuu1+MWp7QXalBtSE qeAuaU30vSIXjKl0HKbyqKpCXKASEB97WynTMLNM8B5DdFIJ0rE6jhHcrvjYczu4F4aPWf8nQYNh ytCxSdgMpvc2VQ4ZiG8IyfjUTW4gidhKrXRS9MT4eHSaEJ6q8ANZ20Y/Lt6XUgYSjonHa8V65FTI MsTSkq88VJEfOTFF2vTCiDCH0OeulqZLVMfCrGbKx9FskpxIHzIWEW5FCQu6obgq9ZDBPbS6H2kc Q6FWxgpGNjcwRVBHjEppNq36BKFxt3QG5cny/VCFmwE1R+KcGGI5dqfi+7wBAAAAAAAA --Apple-Mail=_22221617-7E57-489C-A1DD-AA6ACE968C9A-- From nobody Wed Jul 30 09:24:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628421A02BE for ; Wed, 30 Jul 2014 09:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 EHA2qv3l_HH4 for ; Wed, 30 Jul 2014 09:24:08 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E491A028A for ; Wed, 30 Jul 2014 09:24:08 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6UGO3Ab011437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jul 2014 16:24:03 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6UGO2q4006275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2014 16:24:02 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6UGO2Ra022121; Wed, 30 Jul 2014 16:24:02 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 Jul 2014 09:24:01 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_98FC4052-FEFE-47E2-9AA6-D348C5944663" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <53D8FDE4.9030303@aol.com> Date: Wed, 30 Jul 2014 09:23:59 -0700 Message-Id: <6555337E-F08F-4D40-95A6-70889E6D55BA@oracle.com> References: <53D68967.7000206@gmx.net> <53D8FDE4.9030303@aol.com> To: George Fletcher X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ZQACp99pkU7_92ytwU4bzfkvdu4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Symmetric Proof of Posession for Code Extension" as an OAuth Working Group Item 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, 30 Jul 2014 16:24:10 -0000 --Apple-Mail=_98FC4052-FEFE-47E2-9AA6-D348C5944663 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 +1 Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 30, 2014, at 7:15 AM, George Fletcher wrote: > Yes, I support add this as a WG work item. > > On 7/28/14, 1:33 PM, Hannes Tschofenig wrote: >> Hi all, >> >> during the IETF #90 OAuth WG meeting, there was strong consensus in >> adopting the "OAuth Symmetric Proof of Posession for Code Extension" >> (draft-sakimura-oauth-tcse-03.txt) specification as an OAuth WG work item. >> >> We would now like to verify the outcome of this call for adoption on the >> OAuth WG mailing list. Here is the link to the document: >> http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ >> >> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion >> as to the suitability of adopting this document as a WG work item, >> please send mail to the OAuth WG list indicating your opinion (Yes/No). >> >> The confirmation call for adoption will last until August 10, 2014. If >> you have issues/edits/comments on the document, please send these >> comments along to the list in your response to this Call for Adoption. >> >> Ciao >> Hannes & Derek >> >> >> >> _______________________________________________ >> 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=_98FC4052-FEFE-47E2-9AA6-D348C5944663 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 +1


On Jul 30, 2014, at 7:15 AM, George Fletcher = <gffletch@aol.com> = wrote:

=20 =20
Yes, I support add this = as a WG work item.
On 7/28/14, 1:33 PM, Hannes = Tschofenig wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Symmetric Proof of Posession for Code Extension"
(draft-sakimura-oauth-tcse-03.txt) specification as an OAuth WG work =
item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http:/=
/datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek




_______________________________________________
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=_98FC4052-FEFE-47E2-9AA6-D348C5944663-- From nobody Wed Jul 30 13:24:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6481A036F for ; Wed, 30 Jul 2014 13:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts2vaNFSMAhw for ; Wed, 30 Jul 2014 13:24:49 -0700 (PDT) Received: from na6sys009bog018.obsmtp.com (na6sys009bog018.obsmtp.com [74.125.150.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991681A0326 for ; Wed, 30 Jul 2014 13:24:48 -0700 (PDT) Received: from mail-ig0-f171.google.com ([209.85.213.171]) (using TLSv1) by na6sys009bob018.postini.com ([74.125.148.12]) with SMTP ID DSNKU9lUjwlZ/jPfAEKvPP6qecLMPDROUyeM@postini.com; Wed, 30 Jul 2014 13:24:48 PDT Received: by mail-ig0-f171.google.com with SMTP id l13so8026826iga.16 for ; Wed, 30 Jul 2014 13:24:47 -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:content-transfer-encoding; bh=VlCGUGeVmgnV5vdyqxaFTCTyTwpJT5HoMOuN/YANVx4=; b=ZcQomD8/pFYUWP9WmLc8UKuBo/LgixO+j3GtNzYCXubye91mAStTxZzSm4wl2AsS8z F1gB6xRlgx9xBBrtP56MI3ArnwsZ3pwEQViKJRtR4Zw2itgCujyIxnIKW8SI14nntjpv 34MRCK43EuaKRdQGLQpkd16fC8bUUREGslTPXcI4bFLfB9sdg/2SomysNxiuGOyTxHec QwNmG7jYjSncvYVPwZnrIRiYiiCDTEUNxWT28pN64krBKOvFwYcyLcNWcHTbCCZ0dLjl Vttl5/Ja+cqmwByhoNbLvAPBeE0rYwzk20+M5wxTFUl2AUhiTBDJ/6xGZg/ZO8oJx6ZM Fm5Q== X-Gm-Message-State: ALoCoQmi9KwtJlXVnIdWxjFP8WBDhesItqMV1x6idVYP+0vWcC8ReFevD4jtJ3J9OFkuo4t/wb1pS77lFXgm4JKpkF2fIs/F7dHmhQtxsjnuWQyC5B5S0SG75uKiZE+8fPDPpP/hL2W1 X-Received: by 10.42.82.6 with SMTP id b6mr8477236icl.51.1406751887566; Wed, 30 Jul 2014 13:24:47 -0700 (PDT) X-Received: by 10.42.82.6 with SMTP id b6mr8477219icl.51.1406751887423; Wed, 30 Jul 2014 13:24:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.233.170 with HTTP; Wed, 30 Jul 2014 13:24:17 -0700 (PDT) In-Reply-To: <861917D8-B9AD-4E82-A216-C58E40CEA468@ve7jtb.com> References: <53D6895F.4050104@gmx.net> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <53D841D3.6020505@mit.edu> <311A2204-E968-4657-BD27-58DCD072542A@oracle.com> <53D8A2A0.5040205@gmail.com> <9AF95517-3415-4A3C-A2FB-3BBDFC49E218@ve7jtb.com> <53D8DC2A.6030503@gmail.com> <7189BB03-0962-4B62-A82B-052E70B0A7DF@ve7jtb.com> <53D8DF80.4010301@gmail.com> <9F7C6EC9-065E-4901-B6A3-A00875675439@ve7jtb.com> <0b4a995ea28e40bc87fd4deab0e7dc8b@BLUPR03MB309.namprd03.prod.outlook.com> <861917D8-B9AD-4E82-A216-C58E40CEA468@ve7jtb.com> From: Brian Campbell Date: Wed, 30 Jul 2014 14:24:17 -0600 Message-ID: To: John Bradley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jH6RLnXA0V2z6RVDxmDty9Yxwlc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item 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, 30 Jul 2014 20:24:51 -0000 Will the minutes of the meeting be made available? Those might provide a little more context to those of us who were unable to attend. On Wed, Jul 30, 2014 at 10:14 AM, John Bradley wrote: > Interesting point. I defer to your greater hum experience:) > > On Jul 30, 2014, at 10:32 AM, Anthony Nadalin wro= te: > > John this is for the people that did not hum at the face to face and not > just for the people not at the face to face. > > Sent from my Windows Phone > ________________________________ > From: John Bradley > Sent: =E2=80=8E7/=E2=80=8E30/=E2=80=8E2014 7:20 AM > To: Sergey Beryozkin > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token > Introspection" as an OAuth Working Group Item > > No worries. > > Some of the people in the F2F piling on with discussion derailed Hannes > original question. >> during the IETF #90 OAuth WG meeting, there was strong >> consensus in >> adopting the "OAuth Token Introspection" >> (draft-richer-oauth-introspection-06.txt) specification as an >> OAuth WG >> work item. >> >> We would now like to verify the outcome of this call for >> adoption on the >> OAuth WG mailing list. Here is the link to the document: >> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >> >> If you did not hum at the IETF 90 OAuth WG meeting, and have >> an opinion >> as to the suitability of adopting this document as a WG work >> item, >> please send mail to the OAuth WG list indicating your opinion >> (Yes/No). >> >> The confirmation call for adoption will last until August 10, >> 2014. If >> you have issues/edits/comments on the document, please send these >> comments along to the list in your response to this Call for >> Adoption. > > People not in the room commenting and asking questions is expected. Peo= ple > who expressed opinions in the room should avoid double counting by making= it > clear they hummed in the room, as our AD may not know everyone's face and > name. > > I don't know how I became the process monitor. Normally I am the troubl= e > maker. > > I believe what passed for consensus in the room was that this ork is in > scope for the WG and this document can serve as a starting point, but tha= t > there are things that need to be added. > > I think Phil would like a use case document to flesh out peoples > understanding. Others who have been working on this longer are hesitant > that doing a use case document without adopting Justin's document as a > starting point, will stall the process. > > We can however adopt Justin's doc and in parallel add a use case section = as > part of the doc or as a separate doc. > > So if you were not in the F2F hum you need to express an opinion on if > draft-richer-oauth-introspection-06.txt should be adopted by the WG item. > > John B. > (PS I was in the room and hummed in favour of adopting this as a work ite= m) > > On Jul 30, 2014, at 8:05 AM, Sergey Beryozkin wrot= e: > >> Hi John >> On 30/07/14 14:59, John Bradley wrote: >>> No, that those of us who we're fallowing the instructions not to comme= nt >>> if our hum was recorded in the room, should not hold back given the nat= ure >>> of the thread has changed. >>> >>> It was also an indication to the char that the original intent of the >>> thread to judge consensus is impacted by some people who previously hum= med >>> piling on the thread. >>> >> I think I understand, thanks for the clarifications, though it appears t= o >> be more subtle to me that various OAuth2 technical ambiguities :-) >>> I am more than fine with discussion. It probably should have been a >>> different thread though. >>> >> Thanks, sorry for the noise anyway >> >> Sergey >>> John B. >>> Sent from my iPhone >>> >>>> On Jul 30, 2014, at 7:51 AM, Sergey Beryozkin >>>> wrote: >>>> >>>>> On 30/07/14 14:42, John Bradley wrote: >>>>> This request for only those not at the F2F to add to the hum has gone= a >>>>> bit off the rails. >>>> Meaning you see too much feedback, is it bad, even if some of it may b= e >>>> off topic ? >>>>> For those not in the room there was discussion that the draft needed = a >>>>> method to deal with: >>>>> - Multiple AS >>>>> - Supporting the PoP specs >>>>> - stopping clients or other interceptors of the token from >>>>> introspecting it. >>>>> >>>>> Justin stated that his implementation already had a number of those >>>>> features. >>>>> >>>>> I offered to help get those into the spec as part of my support for >>>>> making this a WG item. >>>>> >>>>> Yes if AS and RS are monolithic and there is only one software vendor= , >>>>> then this is not needed. >>>> Why not ? What is wrong with standardizing an introspection process >>>> which even RS & AS from the same vendor may want to use as opposed to = every >>>> vendor inventing its own protocol ? >>>> >>>> This is why I thought focusing on the RS to 3rd party only diverts fro= m >>>> the idea which I 'read' in the thread (may be I'm wrong), i.e, standar= dizing >>>> on the RS-to-AS communication, which may not have been considered, >>>> >>>> Cheers, Sergey >>>> >>>>> >>>>> On the other hand there is evidence that is not the case. >>>>> >>>>> John B. >>>>> >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On Jul 30, 2014, at 3:45 AM, Sergey Beryozkin >>>>>> wrote: >>>>>> >>>>>> +1. >>>>>> >>>>>> I've understood from what Justin said the idea is to introduce a >>>>>> standard way for RS to communicate to AS about the tokens issued by = the AS. >>>>>> I think it is a good idea, I'd only not focus on the RS-to-3rd party= AS >>>>>> communications because it complicates it a bit. >>>>>> >>>>>> Clearly it would be of help to implementers of OAuth2 filters >>>>>> protecting RS, having a new lengthy process to collect the cases see= ms to be >>>>>> a very administrative idea to me >>>>>> >>>>>> Thanks, Sergey >>>>>> >>>>>>> On 30/07/14 03:54, Phil Hunt wrote: >>>>>>> -100 >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> On Jul 29, 2014, at 17:52, Justin Richer >>>>>> > wrote: >>>>>>> >>>>>>>> Reading through this thread, it appears very clear to me that the >>>>>>>> use >>>>>>>> cases are very well established by a number of existing implemente= rs >>>>>>>> who want to work together to build a common standard. I see no >>>>>>>> reason >>>>>>>> to delay the work artificially by creating a use case document whe= n >>>>>>>> such a vast array of understanding and interest already exists. An= y >>>>>>>> use cases and explanations of applications are welcome to be added >>>>>>>> to >>>>>>>> the working group draft as it progresses. >>>>>>>> >>>>>>>> -- Justin >>>>>>>> >>>>>>>> >>>>>>>>> On 7/29/2014 8:16 PM, Mike Jones wrote: >>>>>>>>> >>>>>>>>> Did you consider standardizing the access token format within tha= t >>>>>>>>> deployment so all the parties that needed to could understand it, >>>>>>>>> rather requiring an extra round trip to an introspection endpoint >>>>>>>>> so >>>>>>>>> as to be able to understand things about it? >>>>>>>>> >>>>>>>>> I realize that might or might not be practical in some cases, but= I >>>>>>>>> haven=E2=80=99t heard that alternative discussed, so I thought I= =E2=80=99d bring it >>>>>>>>> up. >>>>>>>>> >>>>>>>>> I also second Phil=E2=80=99s comment that it would be good to und= erstand >>>>>>>>> the >>>>>>>>> use cases that this is intended to solve before embarking on a >>>>>>>>> particular solution path. >>>>>>>>> >>>>>>>>> -- Mike >>>>>>>>> >>>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Georg= e >>>>>>>>> Fletcher >>>>>>>>> *Sent:* Tuesday, July 29, 2014 3:25 PM >>>>>>>>> *To:* Phil Hunt; Thomas Broyer >>>>>>>>> *Cc:* oauth@ietf.org >>>>>>>>> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAu= th >>>>>>>>> Token Introspection" as an OAuth Working Group Item >>>>>>>>> >>>>>>>>> We also have a use case where the AS is provided by a partner and >>>>>>>>> the >>>>>>>>> RS is provided by AOL. Being able to have a standardized way of >>>>>>>>> validating and getting data about the token from the AS would mak= e >>>>>>>>> our implementation much simpler as we can use the same mechanism >>>>>>>>> for >>>>>>>>> all Authorization Servers and not have to implement one off >>>>>>>>> solutions >>>>>>>>> for each AS. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> George >>>>>>>>> >>>>>>>>> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>>>>>>>> >>>>>>>>> Could we have some discussion on the interop cases? >>>>>>>>> >>>>>>>>> Is it driven by scenarios where AS and resource are separate >>>>>>>>> domains? Or may this be only of interest to specific protocols >>>>>>>>> like UMA? >>>>>>>>> >>>>>>>>> From a technique principle, the draft is important and sound. = I >>>>>>>>> am just not there yet on the reasons for an interoperable >>>>>>>>> standard. >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>> On Jul 28, 2014, at 17:00, Thomas Broyer >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Yes. This spec is of special interest to the platform we'r= e >>>>>>>>> building for http://www.oasis-eu.org/ >>>>>>>>> >>>>>>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> during the IETF #90 OAuth WG meeting, there was strong >>>>>>>>> consensus in >>>>>>>>> adopting the "OAuth Token Introspection" >>>>>>>>> (draft-richer-oauth-introspection-06.txt) specification as >>>>>>>>> an >>>>>>>>> OAuth WG >>>>>>>>> work item. >>>>>>>>> >>>>>>>>> We would now like to verify the outcome of this call for >>>>>>>>> adoption on the >>>>>>>>> OAuth WG mailing list. Here is the link to the document: >>>>>>>>> >>>>>>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>>>>>>> >>>>>>>>> If you did not hum at the IETF 90 OAuth WG meeting, and ha= ve >>>>>>>>> an opinion >>>>>>>>> as to the suitability of adopting this document as a WG wo= rk >>>>>>>>> item, >>>>>>>>> please send mail to the OAuth WG list indicating your >>>>>>>>> opinion >>>>>>>>> (Yes/No). >>>>>>>>> >>>>>>>>> The confirmation call for adoption will last until August >>>>>>>>> 10, >>>>>>>>> 2014. If >>>>>>>>> you have issues/edits/comments on the document, please sen= d >>>>>>>>> these >>>>>>>>> comments along to the list in your response to this Call f= or >>>>>>>>> Adoption. >>>>>>>>> >>>>>>>>> Ciao >>>>>>>>> Hannes & Derek >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Thomas Broyer >>>>>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> >>>>>>>>> OAuth mailing list >>>>>>>>> >>>>>>>>> OAuth@ietf.org >>>>>>>>> >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Thu Jul 31 13:45:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B341A00FE; Thu, 31 Jul 2014 13:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.751 X-Spam-Level: *** X-Spam-Status: No, score=3.751 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 g3KEkN4Bj8OA; Thu, 31 Jul 2014 13:45:35 -0700 (PDT) Received: from BLU004-OMC3S27.hotmail.com (blu004-omc3s27.hotmail.com [65.55.116.102]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1661A0084; Thu, 31 Jul 2014 13:45:34 -0700 (PDT) Received: from BLU406-EAS215 ([65.55.116.72]) by BLU004-OMC3S27.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Thu, 31 Jul 2014 13:45:33 -0700 X-TMN: [n6bdp8fP2u95Bax19U1oCbp6uJE+lGkp] X-Originating-Email: [panca70@outlook.com] Message-ID: Content-Type: multipart/mixed; boundary="===============1565433240==" MIME-Version: 1.0 X-Client-ID: 327 X-Mailer: BlackBerry Email (10.2.1.3175) Date: Fri, 1 Aug 2014 03:45:15 +0700 From: Panca Agus Ananda To: oauth-request@ietf.org, oauth@ietf.org X-OriginalArrivalTime: 31 Jul 2014 20:45:33.0979 (UTC) FILETIME=[600836B0:01CFAD00] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7ygMPOI8nLGo93pqTyCVnpM-Ts8 Subject: [OAUTH-WG] Getting Started for BBM for Windows Phone Beta 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, 31 Jul 2014 20:45:38 -0000 --===============1565433240== Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
http://blogs.b= lackberry.com/2014/07/windows-phone-how-to/

Dikirim dar= i ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
<= /html> --===============1565433240== Content-Type: text/x-vcard; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Panca.vcf" QkVHSU46VkNBUkQNClZFUlNJT046My4wDQpQUk9ESUQ6LS8vUmVzZWFyY2ggSW4gTW90aW9uLy9S SU0gQXBwLy9FTg0KVUlEOjg2MDgwMTRjLTE4ZjMtMTFlNC04NWVjLTkzZDgyMGU2ODMwYQ0KRU1B SUw7VFlQRT1XT1JLOmp1bGlhbmRlcmkxM0BnbWFpbC5jb20NCkZOOlBhbmNhDQpOOjtQYW5jYTs7 Ow0KUEhPVE87VFlQRT1KUEVHO0VOQ09ESU5HPUI6LzlqLzRBQVFTa1pKUmdBQkFRRUFTd0JMQUFE LzJ3QkRBQWdHQmdjR0JRZ0hCd2NKQ1FnS0RCUU5EQXNMREJrU0V3OFVIUm9mSGgwYUhCd2dKQzRu SUNJc0l4d2NLRGNwTERBeE5EUTBIeWM1UFRneVBDNHpOREwvMndCREFRa0pDUXdMREJnTkRSZ3lJ UndoTWpJeU1qSXlNakl5TWpJeU1qSXlNakl5TWpJeU1qSXlNakl5TWpJeU1qSXlNakl5TWpJeU1q SXlNakl5TWpJeU1qTC93QUFSQ0FYWUJkd0RBU0lBQWhFQkF4RUIvOFFBSHdBQUFRVUJBUUVCQVFF QUFBQUFBQUFBQUFFQ0F3UUZCZ2NJQ1FvTC84UUF0UkFBQWdFREF3SUVBd1VGQkFRQUFBRjlBUUlE QUFRUkJSSWhNVUVHRTFGaEJ5SnhGREtCa2FFSUkwS3h3UlZTMGZBa00ySnlnZ2tLRmhjWUdSb2xK aWNvS1NvME5UWTNPRGs2UTBSRlJrZElTVXBUVkZWV1YxaFpXbU5rWldabmFHbHFjM1IxZG5kNGVY cURoSVdHaDRpSmlwS1RsSldXbDVpWm1xS2pwS1dtcDZpcHFyS3p0TFcydDdpNXVzTER4TVhHeDhq Snl0TFQxTlhXMTlqWjJ1SGk0K1RsNXVmbzZlcng4dlAwOWZiMytQbjYvOFFBSHdFQUF3RUJBUUVC QVFFQkFRQUFBQUFBQUFFQ0F3UUZCZ2NJQ1FvTC84UUF0UkVBQWdFQ0JBUURCQWNGQkFRQUFRSjNB QUVDQXhFRUJTRXhCaEpCVVFkaGNSTWlNb0VJRkVLUm9iSEJDU016VXZBVlluTFJDaFlrTk9FbDhS Y1lHUm9tSnlncEtqVTJOemc1T2tORVJVWkhTRWxLVTFSVlZsZFlXVnBqWkdWbVoyaHBhbk4wZFha M2VIbDZnb09FaFlhSGlJbUtrcE9VbFphWG1KbWFvcU9rcGFhbnFLbXFzck8wdGJhM3VMbTZ3c1BF eGNiSHlNbkswdFBVMWRiWDJObmE0dVBrNWVibjZPbnE4dlAwOWZiMytQbjYvOW9BREFNQkFBSVJB eEVBUHdEdzlldFRwVlR6Z0tVWE9LdE93aUtaL01rWS9oVE1VcllKSkZHMG1wWXhLS2VJbU5POGg4 OXFMQVE5NmN0VEMyYW5DMllVSk1CaW1uaWtNVERtbkFZRlVJa1VWS2d4VUJrQ2lnWElGVmNSTmNT K1ZIbkdRZTFacHdXUGFyTXNvbVhCNHF2c05UTFZqRXhSVDFpWnFjTFp5TzFSWUNIdlVpNXFRV2tu SFNwaGFITlVvc0NKVFVpbW5mWm1GSjViSzFYWVE3dG1wVUZSaW5OS0ZvQW5VWU5RWHN3UUNNcUND TTBuMmtDb3JobG5UZ2ZNTzlOdlFDblJpcFBJZjJwd3RuUHBXVm1NaHBRY0dweFp5SDBweTJNbTc1 c1k5YWZLeDNHcjFxWlQycVFXaHAzMmNqdFZwTWthcDVxUmVUVVlSbFBOU0t3WHJWQ0pWSE5TcnhW VTNDanBRTGxlL05PNFdLbC9ONXMrM0F3dnBWU3JFc08rUXNnQUZNRnM1OUt4YTFLUkZSVmdXY3A0 NHAzMkNiMi9PaFJZWEk0VDJxeXZGT2dzV1FFdDFxWVd4Rldvc1ExV3FWVG1tK1FSU3FNY1ZhUWlR RG1wRnFMekF2ZW0vYUZxa3dKNTVQSnQzY2RRSzU1dm1aajZtdGVlWHpiZDBIVnVLei9za250V1U5 V05GZkZMakZXUlpTbjBwUnA4eDlLejVXTzVWQnczMHJRaTVBTlJmMmJQaitIODZ2cGJFS0I3VnBD QU5qRk5TZzBlUmlneGtWb2tTT0hXcEZGTUhGSzBvWHZWQVRBVm1hdE1keXc0NCs5bXJnbkFxbmV3 L2FXRHA5N0dLbWIwMEJHWmlreFZyN0ROMjIwNGFkTWY3djUxaHlzcTVVeFZpMGNMSnNQUTFLTk1u UGRmenFXMzAxMG1Ca3dWOWpUVUdEWk90U3FhY0xmRkw1UkZicU5pUVUwOFV3REJwNE9LWWg0RkRu Wkd4SFlacVB6Um1rYVVNcFU4QWpGTUxHRmNUQ2VRdUVDazljVkZpcmphZkp2SVRsZTFBMHU1Ym90 Y3ppN2xvcDRvclRYUWRRWVpFTEVldUtrVHd6cUw0SVJSOVdBcWVVZHlHeWtFaWtBWUMxZVU0cTda K0hibU9IYTRSVzduT2F1TDRmbHp5NjQ5aFcwV2tpR1pRcDliSThPbi9ucTMvZkgvQU5lcG8vRDZC Y09YSjlRY1ZYT2dzWUlwUlhScm9FSUk0WSt4UFdwbDBTRHZFdjYwZTBRY3B5RjNMNUZ1ejdkMk8x Yys3QjNMQk1aN1Y2bU5GdHlwVXhJUWV4WE5PR2lXZ3gvb3NJeDNFUzFsT1hNVXREeWdJVDBRL2xU dktmOEF1TitWZXRKcGNFYTRTSkZCOUJpcGhacmpIYjYxRmhua2tOcGN1L3lXMGo0NmdLYTI3U3l2 WllRLzJTVWRzYlRYb0lza0hhbkMwakhZVlVYWVJ3d3Nib2RZWkIvd0dwVjA2N1AvQUN5L1d1MUZ0 R093cHdnUWRxdjJqRnluR2pTcnpIM0Yvd0MreFNmMlZlZjg4LzFGZHA1S2VsS0lrSGFqMnNnc2Nn dWhYTHJrdWkreHovaFVWMTRadkpvaWlTd2pQYzd2OEs3WUlvN1VvVWVocE9iWTdIbkk4RTN2ZWVM OWY4S0I0SXZEL3dBdDR2eU5lajdCL2ROR3ovWk5aZ2VkandQZGQ3aFB3V3JkcjROa3QzM201Sk9N WUMvL0FGNjdyWWY3cHBmTFA5dy9sVEE1RWVHMkgvTFkvd0RmUC8xNmNQRHJmODlqL3dCOC93RDE2 Nnp5ei9jUDVVZVdmN2pWZlBJVmpsUjRlR2ZtbGY4QUJSL2pTLzhBQ1BKL3oxay83NUgrTmRSNVov NTVuOHFQTFA4QWNQNVV1ZVFXT1dQaDFNY1N5Wi8zUi9qVVQrSEgvaGwvTmE2N1lmN2pmbFJzeC9D YU9lUVdQUEx2d2ZmVHlsMWxpeDBHYzFYL0FPRUt2LzhBbnRCLzQ5L2hYcFd6L1pOR3hmN3BxWHFN ODBid1hxQUdROExIMEdmOEtoazhKYW9uM1VqYjZOWHFHMWZTa0tvUmpGRmtNODlzdEcxR09JUnl3 aGR2QStjVmFPbFhpamxCL3dCOWl1MjhwUFNrTUtWY1p0RXRIRHRZM0svOHNpZnB6VGZzVnlla0Vo LzREWGNmWjA5QlNmWms5QlZlMVl1VTRacks2SFdDWC92bW9IaWxVbFdSZ1IySXJ2amFJZXdwRFpw NlVlMEh5bm0xM3ZqZ0xCR1BicFdLVllkUVJYc1RXU01wVThqMHF2SnBGdEkyWGhqWStwVUdzNU83 dU5Ia3RINFY2cStoMmJESDJXREgvWE5mOEtyeStHTlBkaXpXMGZQcHgvS3BzTTgydDVQSm5WOFpQ cFhSeHNIUU1QMHJvSDhKNmMyTVd5akhvemY0MHErSFlJMTJJR0MrZ05hVTVjdTVMMU1BaW1FVnZ5 YUNQNEdaZnFjMUUyZ0VEL1d0L3dCOC93RDE2MTU0azJaaWRxalkxcm5RcmorK2crdWFnYlJib01j QlQ3NXhSeko5UjJNdHVhekx1VDV5aFhwM3JvbjBxNVU4eFpQK3ljMW1YdWkzUG1ieEd5azljakZS TlhXZzBZMUZYanBOeU9vRk4vc3lmL1ovT3N1Ump1VThWZTA2NEVjb2pDRExuRzZtZjJkTVBUODZz V1Z0OW5tM3lnSDBxb3BwZ3pWUDVVMDFINXd4U2VhRDNyb3VReFdwcDRGT0p6U01wSTRwQVJNYWli bXJQazhVaHQ4MG1oM01TYVRleDR4ZzRxT3RHZlRuYVFzZ0czMHpVWDltVGorNytkWU9EdVVtVTZN VmIvcytZZWxNK3hTKzM1MHVWanVpN3Bsd0NSQ0VBQUdjK3RhQkZabG5EOW1ZdTUrWThERlhQdEMx dEI2RUVqQ21FWXBCTXBPS0NjMVFER05RdlV4UW5wUjluSnBXQXBTSENrK2xVVHljMXNTMmhaQ1B5 cWtkT25IOTM4NnlsRmxKbFRGRld2N1BtQTZpbW15bEhwVWNySGNycWRyQTQ5NjZDR1R6b0VmR053 eldNTFI5M2JGYU1jeXd4TEdPaWpGYVU5Q1dXR3FOaFRmdEttbEVxc0sxdUlZYWpacWxJeUtZSVdO U0JYYzVxck54eFdrYlltb0pyS1J5Tm1NZDZoeEdtVUtNVlord1RlMzUwaHM1QjZWbnlsRmZGVzlP bDJUN1A3MVJHMmNjY1U2Q05vcGxjNHdLYVRURWE3VkV5MUVib2U5SjlvVTF0eklrVThWRy9GU013 TlJzcGJwVWpJbVBGUk5tcmYyWWtVMDJoTlMwMkJubnJTWXEwYktUUEdNVTAya2c5S25sWXlDaXBU YnVQU20rVTFUWmp1YWRyTjVrQTZBanNLYzNTcVVFZ2dYa0RKNzFMOXBCclpQU3hJOHJtb3p4U2la VzRwRHpTQkVUR29tTlQrVVdQRkJ0bXBXR1V6UUt0TmFFcngxcVA3TElQU281UUljVVkrdFN0YnV2 cFRUR3dvNVJpUnNJMjNiYzRyVERiNHdlbVJXWUZ3UjZWYSswaFFCVlJkaEVqQ28yNDdVMDNBTkc4 TXRPNGhLalk4Vko5S2FJaTFTTWdKb0ZUL1p5ZTFJYlpoMHBXQWhvcVR5SDcwMHhzS0xERzRvNEhh Z2dpa3hudlNBV2lpaWdRcTA4ZGFSYWVBS3BBT0hhcFZOUkNuclZDSjA1cVpSeFVNWFdyQzFhRU5a T2VhcHlERG10RWpqTlo4dk1qVVRHVTJKM2RhVE5LM1UwbU9hd0tIam1ucXRNVHRVeTFTRXh5akZT SWNjVXdEdlRoMXFoRXltcGxxdXZXckVZcTBBL2FLamtYRVo0cWRSVEorSTIrbFcxb0lvOXFxc3hC UE5XajBxaTNCTllTS1E1VGsxS29xRlR6VTZVa0JJcTFJdkhGTlduOTZ0Q0hxY1ZLcHpVQTYxS2xX Qk90UEs4VTFPbFNDclFtVjVWd3ZTcWMvQ2lyODMzS3o3bmxCVVRCRmN2elRsNXFIdlVxZGF4VEdU cUtlbzVwcUNwZ0sxUWh3cVZUVVFwd1BOVUJNdFNENlZHbFNyMXEwSmlGZldxN2pEVmJ4a1ZXbCs5 U2tCUWtmREdtQnNtaVlZYW1MMXJGbEU2YzFNcTFGSDBxZGFwSVE5UmowcDY4VTBDbEhXckFsV25p bzFOU0tLb1E3RkREaW5Da2JnVlFpcTV3cHFtWHEzSU1vYW9IaHF4a1VTS2FtV3E2ZGFzb0tTQWVv cVFDaUtONUdDb2hZK3dyUWgwZThsSStUWVA5cXJ1a0JUQnB3TmJjSGh0eUFaSkNmVUFmMXJRaDBD Q01mY3p6MVk1cGUwU0N4eTRVbm9DYW1Xem5kUVJDK0QzeHhYWXg2YWlkRkMvUVlxVmJORjdWTHFk ZzVUajEwZTVjZ1lWZmZPZjVWS3ZoeVIvdnpZUCt5dWE2OFFvRDB6OUtldHV4SHl4dFVPYlpTUnlr WGhtSUw4N1NNZlhPUDBxNUg0ZnRsVUR5UVQ2a211a0ZsTTM4R1ByVWk2ZkpubGxGSzdBd1UwbUZR QjVNZjhBM3lLc0xaS294MjlLMjAwelBWMlAwV3BsMGoxU1FqMVBGSzRHQ0xSQjJwNHQwSFlWdnJw YUQrQlB4ZXAwMHNmd292NElUL1NnRG14RXZZWnA2d2s5RVkvaFhUalRDT29JL3dDQWdmenB4czQw SHp5S3Yxa1VVZzFPWkZ0SWVrVFU4V2N4NkppdHlTVFRJYytiZTJ5L1diLzYxVkpkYzhPd1ozNnJh L2djL3dCYUFLQXNwajJVZmpUaFlTZjNsRlNQNHc4THA5MitMbi9wbkZtbWY4SnJvcC8xTnJxTTJm N2tCLzhBaWFMZ09HbnQvZjhBMHB3MDRuK0pqOUZwRjhVdEoveDdlR3RZbS83Wk1LbFhWdkVFMlBz L2dtL1BvWk1qK1pvdUFEVFBhUS9oU2pUUVA0Vy9FMDlmK0UzbS93QlQ0TmpRZjlOWkZxWk5OK0kw djNORDB5RC9BSHBSUU1nR25wL2RIL2ZkT0duTDJRZm5tcmErSGZpWEovRnBFSC9BaWFlUEJ2eEZs LzFtdWFiSC91b3hvQXFqVFBTTC93QWRKcDQwcDg4UW44SXovaFZyL2hYdmphWC9BRnZpeTNUL0FI SURUeDhML0VqL0FPdDhaeWovQUhMZWdDcU5La3pqeVQvM3hUdjdLbEgvQUN6UDVDclErRTJwTi9y ZkdXb0gvZGpBcDQrRDViL1crSzlXYjZFQ2dDbi9BR1UrT242cVA2MERUVzdsUi93SmY4YXZENE5X Ui8xbmlIV1cvd0Myb0ZQWDRNYU4vSHEyc1A4QTl2RklET09uRWZ4eC93RGZ4YVBzQ2Z4VFJqL3Rx dGFnK0RIaDBmZXU5VmI2M1JwNCtEWGhqdStvdDlicHFBTWMyVVEvNWVJZisvb3BQc2tQL1B6Qi93 Qi92L3JWdUQ0TitFeDFqdlQ5YnBxWC9oVG5oSC9uMnV6L0FOdlRVQVlmMlcyLzUrb1ArLzMvQU5h ayt6VzMvUDNiL3dEZjcvNjFidytEdmc4Zjh1ZHovd0NCTFV2L0FBcDd3ZjhBOCtkeC93Q0JEVUFZ SDJhMS93Q2ZxMy83L2Y4QTFxWDdMYmRycURQL0FGMi8rdFc5L3dBS2U4SGovbHp1UC9BaHFUL2hU M2cvL24wdVIvMjh0UUJnaXpoUC9MekIvd0IvaC9oU2l4alAvTGVIL3Y2SzJ6OEhmQ1hhM3V4OUxw cVEvQnp3cWVpWHcrbDAxQUdNZE9YK0dXSS85dFZvR21FL3hwK0VpLzQxckg0TitHYy9MSnFTL1M2 TlJuNE0rSC80YjNWbCtsMGFBTTA2VS9ZZy93REExL3hvL3NtWEhBeitLLzQxZlB3YTBnZmMxaldV L3dDM2pOTVB3ZXRSL3EvRWVzci9BTnRRYVlGSCt5SmYrZVovSUdtZjJSTnorNVAvQUh3YXZuNFJ5 ci9xdkZtckw5Y0dtSDRWNnNuK3E4WjN3LzNvZ2Y2MEFVVHBNbmVFL3dEZnMxRTJtRURKaXgvd0Vp dEUvRFh4UkgvcXZHVG4vZnQ2VC9oQlBITWYrcThWV3IvNzhCb0F5enB3SDhDajhhVCt6aG5HMzht clNQaFQ0alJmYzFqUzVmOEFlUmxxTnRGK0pVWTVUUjUvK0I0L25RQm4vd0JtbnNqL0FJVTA2YTNw SVB3cTYxcDhRb3Z2K0h0Tm1IK3hLdFJHYnhsRHpONEwzZThVaTBDS2hzR0hkaCtGTU5rMzkvOEFT clRhM3JNUC9IeDRMMUpBUDdtVC9Xb2o0c2hUUDJudy9yRVByKzVZMFhBZ05tNDZGYVEya283S2Ft LzRUUHcvL3dBdG83NkgvcnBiL3dEMk5TcDRxOEt5L3dETVFSRC9BTGNlS0xnVWpiU0QrRDhxWVlI SFdNMXN4Nm40ZW4vMVdxV2grcmJmNjFhU0hUNXY5VmVXN2Y3cy93RDlhZ0RtVEY2b1IrRk1NU2Vs ZFovWlN2OEFjZkk5blUvMXBqYU0vb1QvQU1Bei9LbmNOVGxEYm9lMU1Ob2g3Q3VtazBkaDFSZnhV clVEYVY2SXAvM1hvQTV4N0ZISEl6OWFyeWFSQzR3WTAvNzVBcnBtMHB4azdKQitGUXRZTVA0aVBx S0xnY3JMNGZ0MzZSN2Y5MDFVbThOSVQrN2QwOWY0djhLN0ZyT1FkTUdtTmJPUDRQeXBxVEE0U1h3 MWNLeDh1VlN2cXdJTlUyMGEvaUJQbEFnZWpmMHIwTm9mVlNLWVlFUGFuenNEem9XMXhFcE1zTWk1 L3ZMVGt5SHdhOUFOa2hPUU1WWGwwbUtUT1kxT2UrM21xVlFWamk2Q09LNmFYUVlXUENGZm9hb3k2 QklCOGovOTlDdEZVaVR5bUtlbE1OWFp0THZJaC9xaXcvMmVhb3VySWNNcEI5Nkxyb0EzdFVUQ3BP MU5JNG9HUU54VVJOVE9LcnNhemJHS0g0eFZtRTVRMVJ6elYyMzRTaUlGeU5lS2ZqRk5qKzZLa3Jk SWtqTlJrNHFScWhiclVzWWhPYWpZZTFPTkpTWVdJR0ZSTWVLc09LcnlERlpzWkVXeFRrZmtZcUpx V01aWWMxS2VvR2tuSkZXQXRWNC92TFZ4ZVJtdG9pWTBqaW9qeDFxWTFBL2VtQTF1bFJHbkUwMnBZ RVRDb1dHS3NzT0toY2NWREdWMk5ORFlwWHFNMW1ORnVBNWJHYXVRcm1xRnI5NnRHMzcxcEFUSmR0 Tkl4VXhIRlF0V3JFUk1halk4VTUrdFJFMW14alQwcUpscVh0VEdxV0JBd3hVWk5TdlVMZGF6WTBP RGNkYXN4bktyVk1WY2hIeXJUanVETHFKOHZUOGFjVndLZEg5MENsYmdWdWlTQnVPdFJFMUxJTzlW MnFXTWF4eWFqWVpwNXBEMHFCa0pHS2lOVE5VVENvWUNVNU03aFRhZEg5OFVrTXNZNXEyc1k0cXAv RVByV2duSzFyQWtZVndLaGJwVTdkS3J2Vk1DTmpVWkdUVG00cHRaakkyR0RUQ09hbGFvejFwQU5w TzlMUlVqSHJVZ3FKVFR3ZWFwQ0gwNWFhS2tVVlNFVFJkUlZoYXJ4MCtXUVJ4OHR0SjZHckVQa3VJ b3lVTDgrbFU1VDg1NXFySTVrWXMzSnB1VDZtczNNcXdyZmVOSlJSM3FCajA3Vk10UXJVcW1xUWlT bEZOQnA2MVNFU0oxcXluRlYxNE5XRXoxclJDSk53UlN6SEFGUVBjUnlvK3hnZUtyWGx6a0ZVZjJJ cWdPQndjVk1wanNYODFSWS9NYVRuMU5CNU5adDNHT1VacWRLZ1hpcGxvUU1uV25qclVTbXBGcTBJ Y090U3A5S1lvcVZSelZpSms2VTZTVklVM3VjTG5HYVlwd3VUV2JmM0lsS29oK1hxUjcwMjdEdGN2 UE1ra1pLTUNPbFVyaGdGSE5VUVNCako5YU1udWMxazUzSHlqeHpVcVZBcHhVNlZDQXNKVTRxdXBx WlRXcUVQNzA0RG1taW5yVkNKVXFWYWlXaWFkSUV5NXg2VmV5Qm9WN3VDSmlydmh2U29tZFhJWlc0 UFNzZWFkNTJ5NXppbUJqNm1zWFVIWXN6dXU4ak5JdldxM1E1cWVKcy9Xb3ZjZGkxSFU2MVhRWXFk VFdxMkpKYWNCVFFhY0t0QVBXcFZxSUNwRnFrSWN6aU5DNzhBVkNMeUNWZ2lPQ1RWWFVibnlzUnhu NS93Q0llMVY5UDBpLzFTYkZyQzVHZnZuZ0Q4YXpsVXNOUkxrMGlwR2NuRlU0WTVMcVlKQkc4akhz b3pYYTZUOFBsQUQzN3RLZjdnNFd1dnRORXQ3T1BaRkVxTDZLTVZtNVhIWTg2c2ZDbDlNUTAySWxQ YnFhNkt5OEtRUkFGd1pHOVdycjF0MFVZQXA0dDI5TVVyc1ppUmFYRkV1RlFLUFFEQXF5bHFpOXEx NDdBdjhBd3MzOHF0UmFlRDAyL3dEQVJ1cFhBdzFnWThLaHFWYk4yNjRXdG1ZV2RtcGE1bmlqVWY4 QVBTUUwrZ3JJdVBHZmg2MWJaRmNHNGsvdTIwVzQvd0JhVndKWTlNTDlBN2ZRVllUUzFCNVZCL3ZO VkNQWDljMU00MG53cmV6RHM5ejhxL3JWK0x3LzhSdFJ4bit6dE1qUHA4eC9TZ1paajBzRDIvM1V4 L1BGRHcydHVNelR4b0IvZmxDLzQwNlA0VjZ2ZWM2cjRzdTJ6MVMzVFlLMGJiNE9lR1k4TmRmYkx4 dittODVOSURuWjlmOEFEdG4vQUszVXJVSDBVN3Y2MVNieHhvUWJiYkxlWFRla01ILzFxOU5zdkFQ aGZUOGVSb3RvQ083SnVQNjF1UWFkWjJ3eEJhd1JqL1pqQW9BOGFUeEpxVjMvQU1lSGhUVkpnZWhr QlVWWWpqOGVYWnpiK0ZyVzNCN3p5Q3ZaUWdIUVlwMjBVQWVScDRZK0k5MTkrNzB1ekIvdTViRlRy OE4vRmR6L0FNZm5pM3kvYUNDdlZjVXZ0UUI1aW53aDh6L2o4OFQ2ckw2aFdDVlppK0RYaHNmOGZF Mm8zQi82YVhKcjBYRkdLQU9KZytFL2cyRWcvd0JrQ1Erc2tqTi9XdFMzOENlRjdiL1ZhRllqM01R TmRIaWlnRE9oMFBTcmYvVTZkYUovdXdyL0FJVmNTMmhUN2tNYS9SUUtsb29BUUtCMm94N1U2aWdC dUtYQW9wYUFFeFJTMFVBSlJpbG80b0FURkdLS0tBREZHS1UwbEFDWTRwY1VVZDZBREZHS1NqdlFB VVlvNzBVQUdLVEZMUlFBbEdLS0tBREZKaWxwT0tBREZKaWxvb0FURkdLTVVVQUdLVG1scE9LQURG Smlsby9HZ0JNVW0wZWxPcEtBRXhTRmM5Um1uVWxBRUwyc0VuMzRZMitxQTFTbTBEU2JnZnZ0TXMz K3NLLzRWcDk2VEZBSE9YSGdQd3ZjNTh6UXJJL1NQRlpzM3dxOEl5NTI2WjVSOVlwV1d1MXBNYzBB ZWV5ZkNMUWV0dGVhcGJmN2x5ZjYxWGY0VjNNWE5uNHExT1Aya3cxZWxZcE1VQWVZdDRGOFoyby8w VHhWRktQU2VESDhxZ2ZSZmlOYmY5QXE5SDEyL3dBNjlWeFNZb0E4aWVmeG5hZjhmZmhDT1VkemJ5 TFZaL0ZVbHZ4cUhoclZiYjFJUm1GZXpGUjZVMG9DT1JrVUFlTlIrTXZERXAyelRUVzdlazhPUDZD cjBGOTRmdmNmWjlTdFd6L3Q3ZjhBR3ZUTGpTckM3R0xpeXQ1UWY3OFNtc084K0huaFcreVpkR3Qx WTk0eHNQNlVBYzBOTWltR1labGNmN0VpdC9oVU11ak9PMzVvUldoUDhJdER5V3NMdlViSnUzbFhC SUg0R3FqL0FBODhTMlBPbCtLNUhBNkpkUmJ2MUZBRkJ0TGYrRk4zKzQyYXJQWk9od2R5bjNGWDVi TDRoV0grdTAvVHRVUWQ0MnczNjFUazhWVDJYeTZ4NGIxR3o5WFJTNi8xRk1DQTI3anNEOUtZMFBx dUswTGJ4SDRaMUZ0cVgwU1NmM0psMk4vVCtWYVM2YkJPdTYzbEREMWpjT1A2R2dSekxXaU4ycXRO cE1Vd3d5Qmg3ak5kUEpwRWdiQ21OajZINVQrUnFwTFp6UWNTUnVuMUZPNEhHM1hoV0Z3VEhtTSsz U3NXODhPM3R1Q1VIbUtQVHJYcFFVY1VwdGtmdG1xVW1nc2p4bWVLU0Zpc2lNckRzUlZOeGl2WmJ6 UUxlOGoyeXhLeTQ3aXVRMVh3Skl1NlN5ZkgvVE52OGFmTmNWamhDNFZzRTFldHlObldxVi9wOTNZ ekZMcUY0Mjl4d2FyQmlCMU5RcFdIWTNWdTRVYllYK2JwaXJWY3ZrZzd1L1d0cXl1aEt1MTVOejlj VnRDcGNscXhiTlF0VXg3MUd3eFZzQ0kwaHB4QnBocE1CamRLcnlWTTFRdlVNWlhiaWlKMURpbXlO Z2tWRldSVmpZV1JVK1pqd085V0licUdSZ2lQa211ZnljWXlha2huZUZ2bE9QWE5XcGsyT2hhb0hw OGNpeXhCbFBCcHJDdHJpSVc0cHRQYW1WQURXcUY2bFkxQzVxUmxkK3RSR3BYNE5RazVySjdqUlp0 VyticlYyTzRpaWJEdGlzbmtkRFIxcWxLd1dPaFNWSlYzSWNyNjB4KzlVTE84MmtySzN5NDRBRlhq eU0xc3BYUkpDL1dvalV6Q295S2xnUjB4cWVhamFvWXlKNmdiclV6R29XcUdOQUt1UkViVjVxbUtN bjFvVHNNMkV1WWd3VGY4MVROMHJCQkt0dUhVYzFyUTNDeW9CbkxZNXJhTTdrMkI2Z2FyRDFBd29Z aUkwSHBTa1UwOFZER2lOdXRSTlVyVkVhaGpFcHlmZkZObzdVaGxuUElOWElaNDJPME44MVpWT2pj eHZsVGc5S3VMc0ZrYXpkNnJ2VDQ1VmtqNE9jZGFZMVcyU1FOVFIwcDdDbW5pb0dOYW82ZXhxTW5t cEFYWTNwU2JHOUt0aXBWVVZYTGNDaUVZSHBSZ2cxb2VXQ09sUnRFTUdueTJFUURnMUx1VmFoWTdW TlFsaWFWeDJMd2xVZDZiTVVsVVpZOFZTQk5PSHB6UnpCWURHd3BSRXhwd0hOU0wwcFd1QkVZWG9F TFZiVTVGU0tBYWZLQlNFYitsTHNZZHEwQW9QYWxaQUIwcXVRUlFRYzFNbmVsbGpDNHgzcUdSeXVN VXRnc1dRNkR2VDFtVWQ2ekN4ejFwVkpQT2FPY0xFOXhFcnR1VEdlNHFEeVh6aW5nYzFLbzVwYmdW L3M3MHB0WkJ6aXJRNjFNcHBxQUZKWUdIYW5MRS9wVjlRS2tDZzlxcFFBenRqZWxTSjBxNnlBOXFy eUtGYkFwMnNLNHFZQTVwd2tVZDZxU3lGVzI5cWgzblBXbHpXR2FnbFNzKzR0eTBwZE1ITk5ISjYx SUtUZHdLNHRwUGFuZlpKZmFyU0NwbE5Ma0M1UVcwa3o4d3FVUXZqcFY1Y1ZJcWowcXZaaGNvckU0 N0duWUsxZjJERk1aQVIwcXVVbTVBdldwZHlpb2o4b05WV2tKSjVvYnNVYUFsV216N0o0V1RkZ1Zu aGo2MUlNNDYwdWE0RlkyY2dQYWdXY3A5S3VyelVxamlwNUF1Wi8yR2IwRlN4V2pKejFyUVduZ0Ny VUF1VWhFM3BUZ2pBOUt2QlI2VXBVZWxWeUVzcUprZGFrV2xrWEZReVB0WGlrTXNCMXpVMXRETGR6 Q09DTm5ZOWhWbncvNFp2ZGNsVndwUzJ6ODBoL3BYckdpZUZyVFM0Z0lvc0h1VDFxWE93MGppdEw4 QUpQT3QxZjVkditlWSs2SzdlMTBpRzJRS3NhcVBRREZhOGl4V3kvTWNHcWhra256NVkyb09wTlpO aklpaVI4VTFZMmxiQ0tUVTBvdGJHRXoza3lJZzZ2S2RvL0xxYXdtOFdTYWxOOWo4TTZWUHFrdWNl WnQyd3IrUFNsY0RkanN1TXMzQTY3ZjhlbFVML3dBUWFIby9GemVSZVovY2ovZU9mOC9TcGJiNGUr SnRlSWs4UjYwYlNBLzh1dGx4eDZGcTdEUlBoNzRiMExEMjJuUnZOM2xtK2RqK0pwRFBQb3RlMXZX bTIrSC9BQTNjVExuaWU3RzFQMXJTZzhDZU05WHdkVzEyS3dpUC9MSzBUSi9PdlYwalJGMnFvVURz QlQ4VUFlZldId2c4T3dNSHZ6ZGFqTC9ldVpTUitWZGRZZUhOSTB0QXRscHR0QmorNUdNMXFVdEFE UWdIQUhGS0FLV2xvQVRGTGlpaWdBeFMwbExRQVVVVVVBQXBhS0tBQ2lrcGFBQ2lpaWdBcGFTbG9B S0tTaWdCY2V0RkZKUUFVdEhXaWdBcEtLS0FGN1VsRkZBQlJSUlFBVVVVZDZBQ2twZTFKUUFVVVVV QUhlaWlrb0FLS0tLQUNrcGFTZ0Fvb3BLQUNpaWlnQTcwbExTVUFGRkZKelFBVVVVVUFGSWFLTzlB QlNVdEpRQWMwVVVVQUpSUlIyb0FTaWlpZ0Fvb29vQVRGSlMwQ2dCTVVtT0tXaWdCQ0theUt3d1ZC SG9hZlNVQVltcGVFOUIxVlNMM1NyV1VudjVZQi9NVnpGMThKOUtWakpwRi9mNmJKMkVVdTVmeU5l aFVZb0E4dGw4T2VQTkhVL1pieXoxZUFmOEFMT1liSFA4QVNxUjhYemFZd2gxN1JiM1RUM2RVM1Iv MUZldTQ5YVpMREhNaFNTTkhROVF3eUtBUE9yUzcwWFdvdzlwTmJ5ay84OG0yUCtYVCtWRXVrT2pm NlBOa25va255bjhPeC9DdGZWL2hyNGQxTjJtanRtc2JrOGlhemJ5em42ZEs1NmZ3MTR6OFBCanA5 M0ZyZG1QK1dGd05zbVA1R2dCMitTMmZaY1JNcmZURldGV0tkZmx3YXo3VHhmWVRUQ3cxV0NYVExy cDVGMm55WjlqL0FJR3RLWFRrSytkYXliQWVoM2JrUC9BdTM0MHhHZnFQaDYxMUNCb3BvbGRXSGNW NXY0ZytITTl0dW0wM0xJUCtXVGRmd3IxZU84bHRaUEt2SXlQOXF0SklJTHVMY2hERDJwZ2ZNTDZm Y1J1VWROckRzYXVXbHF0dXdrTG5kakJGZTArSmZBOXZxVWJTUnI1YzRCMnVQNjE1THJHa1hlalhq Vzl5aEg5MWgwWWV0WEd3aHZtTDYwMHVwNzFRTDRwb2xPZXRYemlzeSt4NHFKdUJUSXBDV3gycXdp aGlhZTRiRmNveDdVd3hNZTFhQVhIYWdxTVVjb1hNaVcwZHpsUnpVZjJLYjBGYkJ3S1l4NHFlUWR6 Sit4eWpyaW5SMmJ1L3pIQTlhdm5wVUxDcDVFRnl4RVZoakNiczQ3MC96Vjlhb3RrVkdXeFZjMWhH Z1dVbnJVYmRhcGlRK3RXa2JjdENsY0xFYkFsdUthWTI5RFYyT01iZWxTYkFCMnA4dHdNdG9XUGFv amFTZGhXdVZGTU9CUzVFTXlqYXlqc0tRMjhnOUswV3FKK2Fqa0FodHJjcklIYzRBcThaVjlhcE5r ZERVVEhIZW1uWUdqUU1pK3ROSkJIRlo0YzFLc2gzWW81cmhZbFBTbzlyTjBCcWRWM01CVmhZd0tk cmdaeGpiMHBoZ2M5cTFTZ0ZNWUNqa0M1bUMza1Bha01EaXRBbkZSTjNOVHkyQzVURUxrOXMxY3R5 a01lTThtb1dIT2FZZWxMWWU1ZE1pVTB5S2FvRmo2MEJxSE1MRnh4M3FKK29wSTJMQ3A0b3cyZmFu dUd4V0tNZTFOOHB2U3RJUmowcENvQTZVK1FETU1iOWdhVVJQak9LdkhGUnNlTUNwNVF1VlBMYWdJ VFU1NXFJclUyQkZtTmtqWEEvR2xNaTFUUEFwdFZ6QVc5NE5NYnJ4VUFKRlBVNUdhTGdJMU4yTWUx VzBqeU4xVEJCanBSeTNDNVhXckVkVjE2MVlpcWtJbUZKSXZ5bjZVOVJUSnZ1MWZRUm5QOEFjTlEx TS8zS2hyQmxvVHZVaTFIM3FSYVFFZ0ZQQXBCVHFzUXExTWxRanJVeVUwSXNKeUtrMjFISDBGU2l0 VUlxWFBBWEZVWitncTljODdmclZHZm9LeW1ORU5QVHBUS2VuYXN4azZpcFFLaVNwUldpMkVGUFhy VE85UFdtaEV5VllXcThkV0VyUkFPSXFwUHhKK0ZYRDA5S3B6LzZ6OEtjdGdLRngvckQ5S2lIV3Bi bi9XTjlLaVVjMXpzb2xUclU2MUFuV3JDMVNFU0NuQ21pblZZaVJhbVNvRnFkT2xVZ3NTaWtZY1Vv cEdJeFZpS1V2Q3RpczlqMnJRazZOV2MvM3F3bnVVaDYxT2dxQktzSlNReVpSVWdwaTAvdldpSkhE clQxTlJqclVncWdKbHAvYW1MMHAxV2hNaW1IRmRQNFo4RXlhc1V1TDBNa0haT2hiMFAwcWZ3djRW L3RLUmJxNlUrVG41VTZaNmZwWHJWbFp4V3NBQUFWVkgwQXJDY3VpS1JGWWFWRFp3aEVSVUE3QVlw dDNmcXJlVmJqYy9UTk12TDU3cGpEYm5FWSs4M1RQLzFxek5VMVhUL0R0bDU5MjVETndrWS8xa2g5 QU8xWkRMWGtxb2FhNmNZWGxpeHdGK3AvcFdBL2lXNjFXOE9uK0U3QnIrNFhocmxoaUdMOGFzYVY0 UjF2eHl5WG5pQnBOTzBmckZZUm5hOGc3YnZTdlZOSzBpeDBhelMwc0xhT0NGUndxTGlrTTREU2Zo V2J5Wkw3eGJmeWFqY1ozZloxTzJGUHc3MTZKWTZkYWFkYnJCWjIwVUVhakFXTmRvcTFpbG9BQU8x RkxSUUFVdEdLTVVBRkxTVXRBQlNqcFNVb29BUTB0RkZBQlMwbEZBQzk2S1NselFBVVVVVUFGTFNV VUFMUlNVdEFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJTVXRKUUFkcUQwb29vQUtL S0tBQ2lpaWdCTzFGRkZBQlJSU1VBTFNVVVk5NkFDa29vb0FLS0tLQUROSlJTYzBBTFNVdWFTZ0Fv b3BLQUEwWW9vb0FEU2Q2S0tBRHZSUlNVQUZGRkpRQVVVVVVBSEh2U1V0SlFBVVVVbEFCUWFLU2dC YVNpaWdBb29wS0FGcEtLS0FFeFJqdFMwVUFadXJhSHB1dVd4dDlTczRibU0vMzE1SDBQYXVFdS9B ZXMrSFhOejRTMUJwWUJ5ZFB1MnlDUFJXcjB6dFNZb0E4cjA3eEphWHR3ZE0xUzJiVGRSSERXMXdN SzN1cC9xSzBHczdpeWw4MnhaczlUR2VUajIvdkN1czhRZUdkTDhTV25rYWpiSzVIS1NyOHNrWjlW YXVBdW90WjhDTUk5Uzh6Vk5CM2ZMZHFQM2x2NmJzZnpvQTZqVGRUZzFBZVZLQkhQOEEzVDBiNlZX MTd3eGE2dGF2SE5DR3lNQTQ1WDZWVWVHMjFLM1M4dEowWVA4QU1rNkhodlp2USsvOHEwdEoxbGpK OWgxRDVKUWRxdTNHZlkwd1BBL0ZuaGU1OE8zbUNOMXRJV01iRHFBRDBQdnlLNXZwWDFOcmVpVytv MmtrTXNhdWpqQkI3MTg3ZUxmRFZ4NGUxTjBLTjlsWmo1VDljai9HbmNSa1crZk1yUWhISnJQdHZ2 Q3RDSGl0b0NaUDJwcmRLY2VtYWEzU3RDU0Zxak5TTlVaNjFEM0hZYmppbzJGU2RxWTNTa0JBOVYz TldINlZXYnJXYkdob2FyMEgrcnFnT3RYNHZ1VVFHeS9HUGtwNTZVeUw3bFBQU3Qxc1NRdjNxRmpV ejFDd3FXQXcwd2luVWhxQUltR0tydU9hc1BVRDFMR2lFbW5JVHVGTk5QaSs5K05RaWpSaCsrTTFj eHhWS0w3NHE4T0JXOFNHUnRVRDlhc01PS3JQVFlFVFV6dFRtRk43Vm13R2tjVkU0cVZxaWVwWTBR bnJTVXJkYVNvS0pvRDFxOWFqSWI2MVFnNm1yOXIwT0sxZ1N5d1JnVkMvQXF3MVFTVm94RlppYWpO U04xcU0xa01URk5JcDNhbXQxcERJVzYwbE9hbTFBd3FST2xSMUluM2FhQXZXNmdvUGVwY2UxUld4 K1VmV3BqMXJlSkpSVVZZakdLaFhpcFZQTlFnSmk0UkM1N1ZRKzJTRnp2d1JWbVRFa1pUTlVYaVpm cFNrMzBDd0Z3VnhUS1hZYUNDS3pHTjcxSXRNeHpTanJRQk1HcDROUWc4MUtPbFdEMkhxT2FtUVV4 QnhVcTlhcENKazRGUlhzN3dvcGpPQ2V0UERZcXRjdythUzRZL1NxYjBGWWdhN0xxQXd5dzV6VVR5 YjhjWW84bHdlUlNlVS9wV1R1V05GUFNqWVJTZ0VHa0s1S3RTZzFDQ2FlcCthcVFpVHZUd0NLWUtt VmZXclFoOFl4VTY5S2hYaXBWZkZXZ0tlb1R1a3FxcmNEbjhhaGE5OHpCS25PS1c1dFdMRjFiY1Qy OUtyL1o1UFNzbTNjb2JMSjVqbHVsQzlhWDdPNFBJcHdRaXBzdzBISjFxZFRVSzVGU0RpclNFVEEw OFZFcDVxWlJtcUVPVVZPbFJxS2tCeFZnU0Z0aWxqMEhOWXYyK1FTdXluNVdPU0RXcktGbGpLTjBO WlV0aTZFQkRtb25mb01XUzkzZzRRalByVmRXTE55YWY5bGw5S1ZMWmdjdHhpc3ZlWTlCeUNwMHBn VEZPWE5Xa0JPcHFVVlhGVEwwcXlTUUNucUthbzRxUVZRRDE2VnRlSDlIZlZMd0Z1SVZPV1ByN1Zr MnR1OTFjcERIeVdOZXE2RHA4ZGxiSWlMZ0FmblNuS3kwQkkzOU10WTdhQlVBQUNqRkYzZE5jdjVF SnhHUHZHb3BwaUZFYVp5ZlNxbXFhbmJlSGRIZTl1QnVicEhHT3NrbllDdWNvaTEzWElQRDFyR2lS dGNYMHgyMjlzdjNuYjFQOEFuaXRMd2Q0Qm0rMkw0ZzhVTUxyVkg1amhibExjZWdIclI0QThIM0gy aHZFL2lCUE0xVzUrYUtOdWx1bllEM3IwZ0NrTUZYQTRHS2NLU2xvQUJTMGxMUUF0Rko3MHRBQzBV bExRQVVVVVVBTFJTVXZlZ0FvRkZGQUMwVVVVQUZMU1VVQUxSUlJRQVVWeW5pLzRoYUg0TlZZNzJS cHJ4bDNMYXc4dmoxUG9QclhtRjc4ZnRTZHo5aDBhMmpUdDUwaFkvcFFCNzFSWHp1Zmp2NGxQU3ow NGY4QmIvR2ovQUlYcjRtLzU5TlAvQU8rRy93QWFBUG9taytsZk8vOEF3dlh4Ti96NmFkLzN5MytO S1BqcjRsQjVzOVAvQU8rRy93QWFBUG9mTkxYZ0Z0OGU5YVJ4OW8wcXlsWHZzWmxQOWE3cndyOFlk QjhRM1VkbGRvK20zY2hDcUpUbU5qNkJ2OGFBUFJhS1Nsb0FLS085SXpLcWxtT0FPU1RRQXRGYzlx SGpIU3JBOHloc2Z4RmdvL00xaXkvRkRSb3pqN1RhajZ6VUFkM1NWNS8vQU1MVzBiUC9BQjkyZi9m eWovaGEyamY4L2xwLzM4b0E5QW9yei84QTRXdG8zL1AzYWY4QWZ5ay80V3RvMy9QM2FmOEFmeWdE MEh0UlhuMy9BQXRYUnY4QW44dFArL2xIL0MxZEcvNSs3VC92NVFCNkRtaXZQdjhBaGF1amY4L2Rw LzM4by80V3JvMy9BRCtXbi9meWdEMENpdlAvQVBoYXVqZjgvbHAvMzhvLzRXcm8zL1A1YWY4QWZ5 Z0QwQ2l2UHY4QWhhdWkvd0RQM2FmOS9LUCtGcTZOL3dBL2xwLzM4b0E5QW9yei93RDRXcm92L1A1 YWY5L0tQK0ZxYU4vejkybi9BSDhvQTlBcEs0RC9BSVdwb3Y4QXorV24vZnlqL2hhbWkvOEFQNWFm OS9LQU8vb3JnUDhBaGFtaS93RFA1YWY5L0tUL0FJV3BvdjhBeitXbi9meWdEdjZLNEgvaGFlaS84 L2xwL3dCL0tGK0tlaW4vQUpmTFAvdjdRQjMxQjYxeGx2OEFFZlI1bUFGemFuNlRDdWhzTmNzOVFD K1UrTjNUbklQNDBBYVJwS0tLQUVvb29vQUtLS1NnQW94bWl2TGZpajQ5bTB5UnRCMGVYeTdvcURj enIxakIvaFgzeFFCMnVzZU12RCtoT1k3L0FGS0pKdjhBbmtoM1ArUXJIZytLbmhLYVRZYjZTTC9h a2haUi9Ldm43WVhabmRtWjJPU3hPU2Z4cHdpRkFIMVZaWDlucVZ1dHhaWE1keEMzUjQyM0NySFN2 bURRZGYxSHd2cUMzbW5URlFQOVpFVDhraStoSDlhK2pQRCt1VzNpTFJiZlU3VGhKUmhrUFZHSDNs UDBvQTA2TTBVYzBBSlJSU1VBRkZGRkFDVVVVVUFGRkZGQUJTVVVkNkFDaWlpZ0E3MFVVVUFGSlMw bEFCaW81WWtsaWFPUlF5TU1GV0dRUlVsRkFIbVdzK0c3dndiY3k2djRmaWVmU1hPNjcwNGM3QjNl TWYwcWNOWjYxcHNONVp5cThMZ2VWSm43bit5M3QvS3ZSQ3ZyelhtM2lEU204RmFtK3QyRVJiUTdw c2FoYWdaRUxIL2xvbzlQVVVBYk9pYXEwaC9zKzl5SmwrVlMzVSt4OTZxZUt2RDF0ck9ueVcwNkhZ M1BIVWZTb0wyM1dXT080dG4zL0x2aWtVNTNwMTYrby9VZlN0ZlRyNGFqWmZPUjV5Zks0L3JURWZN K3AyTjFvR3B5V3R6RzN5azdTUmpjTTR5S3FOcU1nLzFYeS9XdlpmaVA0Vy90V3c4NjJpVTNVUnlH N2xlNHJ4WDdGTUdJSzRxazMwQTJMTzQ4K0hKT1hIM3NWTTNTcXRsYmkyVnN2bmRWZ210NDdFa2JD bzJGU2tpbU1PS0FJKzFSc2FlZWxRc2Ntb2JBWTlWbUhOV1dCeFVSVElxR2hvckZzZEtzUjNZUmNG U2FZYmRpUGw1cEJheS8zYW16UTdvc1EzOG5uTHZiRWVlbGEyNEZjamtWaXhXVE1mbitYMHJVakN4 UmhGcldEZlVURmZyVUxDcGlSaW1IQnFtSWdJeFRXTlN2MHFCK0tsZ01ZMUE5U3RVWkh0V2JLUkVh Ulcybm1wQ2hwdmtPVzRGVHFNbCsxa2ZjNGIxcTFwOXdYTEl4K1kvTm1xUGtTZWxYTGExVkdEbHVh dU43a3N2c2FydUtrTENtTldyRVFNS2IycVZoVVRjWnJON2dNSnFKelRtUHBURzVxV05FUnBLY1Zw TnA2VkZpaDBiN0RUMm5iRzFUZ1p6K05NOHA2RmliSXFsZENOYUdUZkFyazVKRk5rcUszWHlWSzdz NXA1SXJWYkNJV0ZSRVlxYzFHdzQ3VkxBanBqVS90VVJOUXhqR3BLVTBuNTFJQlNoOERGSjNwZGpk YUFKVXVIWGFGNEZhSVlFWnpXV3NaSndjVmNRN0VDazlLMFFGUHpHcFBNYjFwdEZaNmpIaDI5YVhK UEZOVVU4RG1xUWlSZlNwTnF0MnFJVklwcWhEaENwN1U4VzYrbExIelU2aXFVUUtyUWVncU1ydDRO WDJXcVVvdzVva3JBUXRNZWc0eFRQT2JQV21OOTQwbFpYWXlZU3VlOU8zdVQxcUphbFVVd0hJU08x U3BqbW1BWXB5aXFRaVVSb2UxS0lFN0xTTFU2VmFRaVA3T3VPbFJ0RnRKSTdWZEF5TVZIS3VJMits UGxBcDlzMHhwdU9EVCsxVW1ibXM1YUZFNG5iMXA2eXQ2MVdYbXBWcVV3SmQ3bnZUMDZVeFJVaTFv aEVxZ011RFRoR2g3Vkd2MXFWVFZDRkVDSG9LWHlGQTZWS2xQSXFrZ0taaTI4MHhuQ0FHclVvd2xV TGh0cUNvbG9BR2RoM3BQUGYxcXRuTlNLT2FoTVpZRXJudlRzc1NDVFVhQ3BsRlVBOWUxU2JWYnFL anA2bXJFT0VTZWxPRUs5aFRsTlNMMXAydUJBMEE5S1p0Mm5GV3l2RlY1Umh4UllSQzgyTWdWRjlv YjFxR1Z2M2pmV3BMSzNhOHZZWUZ6ODdBRWpzTzVyTnlLTzU4R1dCS2ZiSk9USnd2c0s5QmhZSW9H YXhOS2dXM3QwUlZ3b0dBSzJZZ1h4N25Bck42akx0ckdHWXlTSGFvR1N4L2hIYy8wcks4SzZjZkhY aTE5Y3VVem91bXY1ZGxHUjhza2c2dlVQaTI0dVBzVm5vR25FaS8xYVFSREhWSS93Q0kvbC9NMTZu NGYwZTMwSFJiWFRiVk5zVUNCZnFlNXFSbWtxNEZQSEZKaWxvQVdpaWpOQUJTMGxMUUF2YWlrb29B V2xwS1dnQW9vb29BTzFMU1V0QUJTOXFTak5BQzk2S0tQeG9BS0tLS0FDcTJvWGlhZHBsM2ZPTXJi d3ZNUjY3VkovcFZxcTk5YVIzK24zTm5MeEhjUlBFeDltWEg5YUFQamJVdFN1ZFoxSzQxSzlrTWx4 Y09aSFluMTdmUWRLcTRxOXJPajNuaC9WN25TNytNcFBidVVPZjRoMllleHFqUUFvcFFhYjdVdjBv QWZSVFFjVXVhQUZwTVVab0FabUNxQ1dQQUE3MEFmVW53bzEyZnhCNEN0SnJweTl6YnUxckk1NnR0 eHRKL0FpdTByai9oZjRlbThOZUJiUzB1MDJYY3pOY3pJZjRTM1JUOUFGcnNLQUR0WEcvRWpXWk5I OE91OFpBSkdmbU9BU1NGVUUrbTRqUDBycysxY2o4UmZEemVJdkM5emF4L2ZaTURQVE9ReTU5c2dV QWVjV0dpWEkxUy9NeDB5NzArNXN5dGhyZDI2dXIzSlVZMkFuYUJ1M0RiampGU2YyVmZwcCtuNlV1 dGFGSHEra3lOY2F4bUdQSWd5Q3VmbDUyanI5UldVZ3N0VmluOEwzSGgrV3pzdEVnYThzWXBMblpK TlB3V1FrL2VESFBUc0swbjFJbXpzOWEvNFJPMmZWTmVkN1hWRTg4L0xEa0RPUDRkdzV6L0FMTkFG NXBjWHVyNm5IcnVpSnBXcnh0Qm9ZTUtZV2JnRCtIakhJT2ZVVkUxcnFhMnVtYWYvYjJqTHFPak8w K3VaaVRQbGJnUm41ZWNMd2ZjaW81SWRPKzE2bG80OE1XOG1tNkFqM09rdWJqL0FGOHBJT0NmNHQz WEgremlvMnZ3MXZZNnFmQ3RzMm9lSW1lRFdCNS8zSTl3R2Nmdzd2dmY4Qm9BdU5KSjlwMWUrWFh0 Rld4MXBXaTBITVNmTEprRCs3eGo3cDl6VVpnMUJZZEx0UDdlMFlYZWlNMHV2WmlUN200WXo4dk9G K1g2bW9uU3c4L1U5T0hoaTJheThPcTAyak45by8xOGhZSHJuNXQzM3Y4QWdPS2phOGphT3d2ajRX dHpkZUpHYUxXUjUvOEFxMDNEbi9aejkvOEFDZ0MwenorWnE5d3V2YU1MZldzcG9IN3BQbGJkL3U4 WUh5L1dtZVhlcU5LaE92YVA1bWhrdHIzN3BPUnU3L0x6eDh2MXFGdnNZZlVyVWVHTGN3ZUc5ejZN ZnRIK3ViZm4vZ1dmdi9oaW1HZUZocDh4OE1XL21lSlNWMW45L3dENm9iLy9BQjMrL1FCWVkzWkdx dU5lMGNEV3pqUWYzU2NmTi91OGNmTDlhTVhZazBvSFhkSDI2SVArSjkrNlRuNXUvd0F2UEh5Lzcx Vmk5c1A3UVVlRjROdmhzNTBZZWY4QTY3NTg1LzJ2NzlHKzNMNmVENFl0OGVKT2RaYnovd0RWZk5u L0FJRC9BSDZBSmNYNWgxUlJyMmtHWFdtQjBMOTBuM2QzYjVlT1BsK3RQRFhBdWRMa2JYZElOdG95 N2RkQWpUbHQzUDhBRHprZkw5UlZUem9SSGZ5and2YjcvRGpCZEdYenY5WU4vWC9heDkrbEgyWnB0 UHRqNGFnV0h4RUZmV0g4L3dEMUxicy84Qng5NzhhQUpSSHFaZzFLMS90dlNXdmRaWVNhSUJFbity M2M0K1hqSzhEM0ZQV2FVWE9sM2phM3BMYWZwQ0xGcmVJaythWEpCN2M1NkQzQnFxTHNLbDlmand6 QXQzNGVaWWRJWHp2dnB1Ni83VzBmTitOS2tObjV1bmFaL3dBSTVBbGxyeXJQcXppZi9VeUJpY1ov aDIvZS9HZ0I0aDFVMnVvV1A5dDZVMnBhczZ6YVBpTk1tTGNjNCtYakk0SDBOVExjTjl0MHpVRzF2 U1cwclM0MWcxakVTWWFia0h0MzR4OURWSmIwckJlYXF2aGlCTC9RV1czMHBCTjk2UGNSbkg4VzBj NTk2ZWx0WS9hZFAwZi9BSVIyQk5PMXRGdWRUa0UvK3BsNU9NL3c3ZlQvQUdxQUZGdnE1c0w3VFRy ZWxQckdweUxQcGVJMHlZY2tuSHk4YmgwK2hxd2x5UnFHbmFvK3RhUytqYWRFdHZxbUlsdzAvUTl1 NXhqNlZSVy9kYlc2MW9lR0lFMVBSWFcxMDVCTDk2TEpHY2Z4YlIzL0FOcXBZN093KzJXR2hmOEFD T3d4NlhxMGEzZW9TZmFQOVROZ25HZTIzMC8ycUFCYlhWenB0M3BKMXZTbTF1L2xXNDAvRWFaTnZ5 VGo1ZU1qa2ZRMVlTN1Vhblk2dSt0YVMyaFdNSzIrb1lpWEQzR0RuQXgzT0NQcFZCTlFsV3l1ZGUv NFJtQk5XMHAxdExDTVM4R0hrWjI5OW8vOUNxZExEVC90MWw0ZVBoNkdQUjlSaVc4dlpQdEgrcW13 ZmwzZHRwNC80RlFBMWJQV0RwVnpveDF2U20xNjdsVzV0Q3NhWit6OVQvRHhucVBZVlpGMUNkVnRO WmZXTklidy9iUWkydXdJa3cxeHRPY0RIYzRQMEZVRTFHWWFkTjRpL3dDRVloVFdkUGtXeXRZZk4v NVlZSXp0NzdSOHVmZXJDNmZwMzlvV25odi9BSVI2Rk5GdklsdmJtWDdSL3E1OXArWGQ3SDVjZTlB Rlk2UHFNbWtUNkcrcDZNL2lDNG5GekJpR1BKdDhaUDhBRDM2L1FVczl6cUhoalhSck9tclpwb1Zy QW4yaDRaUDNWMUpnYjFDNXdHenV4ajJwcDFDWnRLbjhSTjRYaFhXYmVUN0JEQ0pmK1dHM2J1eDdE NWMrOVFRNkVMOXYrRUowZlRETHBrd2p1cmk5YWJmOW1tSUc3SkhIeWpLN2UvNDBBZlFjVEs4U09q YmtaUXluMUJHUlQ2amhSWW9FalFFSWlxaUE5bEF3S2ZRQVVVVVVBSlJSUlFBak1JMFp6MFVialh5 bGYzY21wYXBkWDh6RnBMaVpwQ1Q3bXZxeGtEcXlIN3JEYWErVkwreWswM1ZMcXhtWGJKYnl0R1Fm WTBBUUJIbExCQVNGRzQ0cS9Ob3M4R25tK1YxWkZkVWNBOHFTTWlvYkc2VzBsbDNwdlNSQ2h4V2tk WGhIaHlleUc1cDdpUldZSCtGUWMvNFVBWS8zMDNWNmw4RXI5eExxMm1zMll0cVhDRDBQM1cvcFhs d0cyUEJyMUg0SjZlL242dHFUREVlMUxkVDZuTzQvMG9BOWNveFJSUUFVbExTVUFGSlMwaG9BTzFG RkZBQlJSU1VBRkhGRkZBQlNkNldpZ0FwS0tLQUR0UlJSUUFVVWZqUlFBbFJ6UXh6d3ZETWl2SElw VmtJeUdCcVNqRkFIbVZoYVNlRzljbDhMVHV3dEpRYmpTcHp6dEE2eC9WZjVWTUpHMDdVRm5WZGti a3E2RCtFL3hEK285aUs2UHh0b2NtdGFHWHN6czFLeWNYTm5KM0VpODQraEhGYzhsekZyMmkyMnBR cnRGMGdESi96em1YamIrZTVmKythYUJtbmZJdHhDY2NnaXZFUEdXa25UZFdhV05jUlRIY01Eb2U0 cjJIVExqemJYeVhQelI4ZmhYTitOTktXKzAyUUFmT28zS2ZjVlVYWmlQSHQ3anZURE93NzA5eGpq SE5RUFdqWWgzMmhoM3A2ejg4MVRQQnB5TjgxVGNDOE9jQ3BGZ0dPUlRZeGxoVnNMV2lWeVNBd3Bq cFRURWdIU3JCcUpxZGhrZXhWNkNtTjFwN1ZIVXNDSnlRM0hhbUdSeDNOU3N0UXVLa1lobmNIclFK Mko2MUN4cVBPRFVYR1hoSUgrdFNDUGVhcTI1eStLdndMMXE0NmlFRUM0NlVoZ1RIU3JPTUNtTjBx N0FWekVvcENBbzRGUFkxR1R4VXRBUnQwcU1NeWpnMUllbFJ0VWdOTXpqdlRmUGJ1YWE0cUpxaTQw V0ZuUGVwUWR3cWtEanJWdVBsQlZKM0N4TWtIY2pyVC9BTE92cFV5TDhncHhIR0t0SkVsVXdwNlUw eHFPMVRQd0tnWTByREd1YWlZOGludFRXR2FsZ01Mc09jMHd5dDZtbFlWRWFsc1pKNXpldE9FdTdp b2FkR1BuRkpNWlA3VklzSFBJcG1QbUZYVlhnVm9rU1Z6YnI2VTB3cU8xVzJGVjNwdEFSRkZIYW1O MXA3VkdSa1ZBeU5zZzlhVGUzclQyRlJrVkxBU2s3MHRIZWtNZXRTZDZqV3BCVklURnhUbHB2ZW5n WU5VSW5pNmlyS21xMGRXVnJSQ0hOOTJxRXYzelY1eUZUTEhBck9rZEN4dzJhVTJORlZ2dkdrcFd4 bWtyQjdqSG9LbVhyVVNWS3RVZ0gwcTBnTkt0VUlsWHJWbU9xeTlhc3gxYUVUTDBxS2YvQUZiL0FF cVFkS2h1WkkxVmxMZ0VqdlZ5WVdLbUtvc09hdWVZbjk2cWJIa2lzSkZJVmVLblNvRnFkS1NCa3kw L3ZURnA0NjFvaVJ3NjFJbldvd09ha1RyVEFzSjBxVVZFblNwT2dyUkFSVGZjclB1QmxCOWF1enp3 Z0ZUSU4zcFZDZVJDbzJzRDlLaWJRMFZSMXFWT3RSRHIzcVZCeldLR1dVcVVDb1VxWUd0VVNPNzA0 ZGFhQlRnT2FwQVNwVXk5YWhVVk10V2dIOXFxeS9mcXc3cEd1NTIycjYxU2x1SVMvRXFrVVNhRWls TVBtUDFyb3ZCdGw1dDNKY25vdnlMa2QrLytmZXVjbFpXWWhUbXZRdkNWbjluMHlISXd6L08zNDlQ MHhYT3l6cW9Gd3FyVzFZd2lTVlFmdWpyOU8vOEFuM3JKdGx6S1BibXJPc2FoL1l2aFBVTlFCL2Vl WDVjWHV6Zi9BSzEvS29BbThCVy8vQ1JlTjlXOFNTamRiMmgreFduNGZlWVY2c0JpdVgrSDJpZjJC NE0wK3paUUpUSDVzcDlYYmsvenJxaFNHRkxSUlFBVXRGSGFnQXBhU2xvQUtVVWxMUUFVVVVVQUZM UlJRQVVkcUtLQUY3VVVVVUFMUlFhQlFBVVVVVUFGSFhwUlJRQnozaW53VG9maStCVjFTMS9mSU1K Y1JIYkl2NDl4OWE4MHZmMmZnWEpzTmR3bllUdzgvbUs5dG96UUI0SWYyZjhBVmUydDJmOEEzdzFI L0NnTlYvNkRWbC8zdzFlOTU0b3pRQjRKL3dBS0ExWC9BS0RWbi8zdzMrRkgvQ2dOVi82RFZuLzN3 MytGZTk1b3pRQjRiYmZzL1hCWWZhZGVqQzkvS2hKUDYxM1hoWDRWZUhmQzl3bDJzYjN0Nm5LelhI SVUrcXIwcnVLS0FDaWlpZ0FveHhpaWlnRFB2ZEMwelVVMlhsamJ6cjJFa1lZRDg2eEpmaHY0Um1Z bDlCczhuMFFyL0kxMWRGQUhHSDRWZUREL0FNd0szLzc3Zi9Hai9oVlBnei9vQlcvL0FIMi8rTmRu UlFCeG4vQ3FmQmYvQUVBYmYvdnAvd0RHai9oVlhndi9BS0FOdi8zMi93RGpYWjBsQUhHZjhLcThG LzhBUUN0LysrMy9BTWFYL2hWWGd2OEE2QU52L3dCOXYvalhaVWZoUUJ4di9DcXZCZjhBMEFiZi92 dC84YVArRlZlQy93RG9BMi8vQUgyLytOZGxSUUJ4bi9DcXZCZi9BRUFiZi92dC93REdqL2hWWGd2 L0FLQU52LzMyL3dEalhaMFVBY1ovd3Fyd1gvMEFiZjhBNzdmL0FCby80Vlg0TC82QU52OEE5OXYv QUkxMlZGQUhHLzhBQ3EvQmYvUUJ0LzhBdnQvOGFQOEFoVmZndnAvWU52OEE5OXYvQUkxMk5IMW9B NDcvQUlWWDRNLzZBTnYvQU45di9qU2Y4S3M4RjlQN0J0LysrMy94cnNxS0FPTi80Vlo0TC82QU52 OEE5OXYvQUkwZjhLczhGLzhBUUJ0LysrMy9BTWE3S2tvQTQ3L2hWbmd2L29BMi93RDMyLzhBalNy OEx2QmlIalFiYjhXZi9HdXdvb0E1cTM4QWVGTFpnMFdnV0lZZHpIdS9tYTNiZXp0clNFUTI4RVVN UzlFalFLby9BVlAyb29BS1NqTkZBQlNVdEpRQVVVVVVBSlhsL3dBVC9BYzJwU05yMmt4YjdrSmk1 Z1hySUIwWWUrSzlScEJ3Y2lnRDVNVTU0WWRLZXVCMEZmUit0ZUIvRHV2U3ROZTZhZ3VHNnpRTVkz UDFJNi9qV1BCOEpmQ3NVbTk0YnVZZjNKTGc0L1RGQUhqV2g2RmYrSmRTV3gwNk1zMy9BQzBrUDNZ eDZzYStpZkQyaDIzaHpSYmZUTFhsSWhsblBWMlBWalZyVDlOc2RKdFJiYWZhUTIwSS9naVhINSt0 V3FBRW9vN1VVQUZKUlJRQVVsTDlLU2dBb29vb0FLU2lpZ0Fvb29vQVNpaWlnQlJTVWQ2VTBBSlIz b29vQU1VbEwzb05BQ1VVQ2lnQk9sZWR4V1EwbnhkcTJoZmN0dFFqL3RHengvQStRSkFQeDJ0WG90 Y1o4UVkvc1VHbWVJbzErYlM3dFdseDNnZjVISDY1L0NoQVk0YnlOUldURzBTakxEKzZjNFlmZ3dO VGFoR0pJVzRwK3RXL2xUeTdlUUc4eFNQUnV2NnJuL2dWTkQrZGJxZWVSVklSNGw0aXNoWmF4UEdC aEdPNWZ4ckVrNlYzbmo2eTJ0RmRBZERzYXVEazZWZlFSWGFuUkQ1aFRXNHBVWUt3eWFrTEdsSDk0 VmNYcFdmSFBFR1hMZ1ZlamRXWEtuSTlhM2d5UldxQjZuTlFQM3BzWkVhYlRpS2JVQU5hb1hOVE5V TDFMR1ZucUk5YWxmMHFNaXNudU5GaTJIelZvMi9lczIzZFZiazRxL2J6UmJzYnh1UFFWckFSY0k0 cUY2bUpxSjYxRVZuNjFHYWxjYzFFZXRac0J2YW1HbjlxWXhxV01oZW9HNjFPOVFzT2F6WTBJS3VS ZmNVVlRxMUc2aFI4MU9JR25IMHBXcHNMbzY1VmdmV25OWFF0aVNCeFZkcXNTY1ZYWVZtd0l6UWVs S1JpbW5wVURSRzNXb21xVnFpYXBZeEJUby92aW0wNURoaFNHV1A0aFY5T2xad2RkdzVyUmpLbE1n NUhyV3NHU3hHRlZucXkzU3E3MVRBZ2Jpa3B6RE5Ock1ZMXFqcVJ1dFJuclNzQTJpcHZJelMvWnFW Z0lWUE5TQTgxSjltT0tZWW1XblpnT0hXcFZITlJLY2NtbkdZRHBURVdGNHFaVFZBWE9LZDlwSnEx SUxGaTRVU3BqSkI3VlJNQkJQemZsVXJURmpRT1JVeTFBcmJDRFNZNXE0WXd5MG4yYk5UeWpLNjFJ cHFYN0tRYVg3T1JUNVdBMVRVaWM5S2pWR1hyVWlrS1BlcXNJbFVZcVpEaXFYMmdDbkM3eHhUdUZp K0NCV2ZQYUZwQ3l2OEE5OWMwL3dDMDB6ekN6VTI3b0NEN01ldTZtR1BGV3hUakNDT0tqbHVOTW9n SE5TcnhWZ1d1ZWxPK3lFR2psQWhWcWxYbWxOc1J6U0tDdldxc0lsUVpxUlJ6VUlrQ0xTZmFSVHVJ dXFhZVdBcWdMcnRqOWFYN1Q3VlhNZ3NRejJSTWpQdkF5YzRxQnJVcHprSDZWYjh3c2ZiNjA4RGR3 ZWxSeWp1VUNtUC9BSzlPUVZjK3pBMGZaYzB1UUxrSzFJdFMvWnFhWWlwNlZWbUE1ZWxTcUtpWGpG S1psV25jUllIQnFRZldxUXVSVHZ0VlVwQllsdTR2dEVCaUJ3VFdhZE9jSEhtS2F1bWZJb1Zpd3FX a3hsUzJzV2U1U0hJTE93VUg2MTZ0cDBRU0ViVkNxQndCMnJoZEh0aE5xVVpLNUNaYitnL1VpdlFy Wk5zUTRyT1NzeG1sYUw4cFk5elVQaUtBNm5ySGhqdzh2UzR1ZnRNNC93QmxmbS9tYXQya1cveTRo L0dRdjVuRlRlSEkvd0MxZmk5ZjNPTXhhYlpMRXZvR2JrMURHZXFScUZVQWNBY1ZKVFZwYVFEdTFG SlFLQUZwYVNsb0FLV2tvOXFBRm9vb29BS1dpaWdCZTlGSlNpZ0Fvb29vQVdpa3BhQUNsNlVsRkFD MFVsTFFBVVVVVUFGTFNVVUFMUlJSUUFDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29wS0FGelJSU1VB RkZGRkFCUlIrTkhTZ0JEUzBVWm9BS1NpaWdBb29wS0FDaWxwS0FDaWlnMEFKUlJSUUFsRkxTVUFG RkhOSlFBVUhwUlJRQVVsRkZBQlJSU1VBRkZGRkFDVVVVVUFGSlNta29BS0tLS0FDa3BhU2dBcEtL S0FDZzBVbEFCUlJSUUFDaWlpZ0JLS0tLQUNpaWp2UUFVVWxGQUFLTVVVVUFBb3hSUlFBVlIxalQ0 OVYwVzkwK1FaUzRnZU1qNmppcjFJZURRQjVycGN6Nmw0UjBxYVU1dUZqYXluOWZNVDVlZitCUnIr ZEpadm1GbDlLbHM0alozbml2VEZIL0h0ZXJmUWowVjFELzhBb1NHb0ZBaXU1a1g3dVR0L1BpbWhI T2VNclg3UnBGeU1aSVRjUHc1cnlSL1N2Y3RWakR3TU1BNUZlT1hGajVWeEpGbjdqRmZ5TlhIVURM MmswaGdMc01ZcS93RFpjY1U0UWhhcmtGY29qVDJKeHZGYWNFYVF4aEZQQXFFbmIvOEFycHF6a2Rl YXBhQ0xoUEZSdFVIMm5GSWJvVStaQVNFY1ZHYUJPckdqT1RTdUJHNXhVVEhJcWZ5aTdlMUgyVW1s WmpLTERJcG9UMnEvOWt4U2ZacWpsQzVTVzNMOXdLbnQ3UXJLcmx4OHZhcHpHRTZVaGNyME5Vb2dY ZDFOWTFVKzA0cFB0UXErWVJPd3FOaHhUUHRRTktKVmFwYkhZWWVsUk5VekxrY1VpMjViclUyQXF0 VVJCcS85a1B2U2ZaTVV1UVpTQ1ZJTGRpTTVBcXlJQU92YWdqRkxsQWx0WXZKakl6bmNjOFZZTFpG VUJLVmIycDMybXRFN0NzV0g1cUlpb3Z0V2VNVWh1QlV0aFlWaGcxRzNIZXBHWU5qRk1LbHNjVWdS RWFqWVZiK3pFMGh0VFUyR1ZNVTRLU2NWUDltNXAzbGhhTEFRZVQ3aXIxdW9pVEFPVCtsVnMwTE1W TlVuWVJlWmhVTFlxdWJtajdUNjArWUxEMkZSbmlqenN0U0U3alUzR01ZMUdUVXV3czFPTnVhVm1C S3BxWkJtcTY5YXNSMWFFUzdCVWJwaFRVeWlrbDRVL1NydG9JelhIeTVxR3BuKzRhaHJCbElNODA1 YVozcVJhQmp3T2FrRk5BcHdGVWhNa1UxTWhxdUttU3FRaWRSVGltYUU1RlNnY1ZvaEZLY1lBN1ZV bU9BS3VYV01MVktmb0t5a01oM2MwNGMwekhOUFdvS0pWRlNLS2F0U2dWYUpZVktwelVYZW5xYXBD TENtcFZHYWdTckNWYUFDb1BhcTA0eEorRlhPMVZMam1YOEtHQlJtT0pNWnFMUFBXbjNBL2VIbnRV UTYxZ3lpWmFrVVZFbFdGcWtKamxGU3FjR21DbkFjMWFFU3JVcWlvRk5UcDBxMEJKZ1UwcmdVOENo dW1Lb0NpL0N0VlJuOTZ0eWo1V3JQYmcxaElhSHExVExVQ0NyQ0NoQXlSUlVxOFV4UlVnNjFvaEc5 NFppMzNVc21mdTRYSDE1L3BYZFJKaEJYSitGSVI1QmZIek0vNmNmL0FGNjdDTWZkRlpUM0tOYlRG M1g4WG91Vy9JSC9BT3RVL3dBSjQvdE0vaUxWVHliblVHVlNmN3E4VlhzWlBKVzd1Q2VJYlptei9u NlZyZkIrM01YZ0MwbGI3MXhKSk1UNjVhb0dkK0J4UzBsTFNBS1drOTZYNlVBRkZGRkFDMFVkNktB Rm9wS1dnQmFLUVV2MW9BS1hGSlMwQUZGRkZBQlJSUlFBdEZKUzBBRkxTVXRBQlJRYUtBQ2lpaWdB cGUzRkpSUUF0RkpSUUF0RkZjNU40MzBXR1o0V2U0TEl4VWxZc2pJb0E2T2lxZW02cFo2dGIvYUxL YnpJd2RyY1lLbjBJckdieDFvaU95RjdnN1NRU0lzaWdEcGFLcWFmcU5wcWxxTG15bDh5UE8zcGdn K2hGVzZBQ2tvb29BS0tLS0FETkZGRkFCUjBvN1VsQUM5cVNpaWdBcEtXa29BS0tXazRvQUtLS1Nn QmNVbEdLS0FDaWtvb0FYRkpSUlFBVWxIYWlnQTdVVVVuYWdBb29vb0FTaWlpZ0FwS1dpZ0JLS0tL QUNrcGFTZ0FvbzdVbEFCUjJvbzVvQVNpanZSUUFtS0tLS0FDaWlpZ0JLS09hS0FDaWlpZ0Fvbzcw VUFGSlMwaG9BS0tLS0FDaWlpZ0FwRDYwdEpRQnhOOUdMZjRtT3ArNXFHa0VIM2FKeC9SaldLd0tU UWs5VEdvUDFIeW45VnJvUEZTK1Q0dzhMWFE0M3l6MnJIL0FINGpnZm1CV0xmcHN1RC9BTE1zZy84 QUh0My9BTE5UUUZhN1VOQ2E4czF5SHlkV200d0d3dy9LdlZac0dNMTV6NHNpMlhzY245NEZmeS8v QUYxcFQzRTlqbldOUkU0cDdWRzFhc2tZUlViQ3BjY1V4aGlwQXJ0eFVUSEJxYVRwVmRxelpRcXZW dUkvSjYxUXoycTlBTVIwNENaZGpYSzlLZnRBb2pPVnB4clpFa1RZcU5qVWoxQXhxUmpXNXFOeFR6 VFRVc0NGaHhVTFZPMVFQN1ZER2lQT090U0kzekNvalN4OHNQclVKak5DUDcrS3RoZWFyUS82d1Zk cmVKSkd3NHFGanhVekNxNzAyQXhqVVo1cFdwTzFReGtUTFViREFxWmhVVFZER1FrNG9Cb2JyU1ZB eWVFNTNWYmdYS3QzNXFuQjNxL2E5RDlhMWdTeVRiZ1UxdUJVeEZRdjByUmdRczN0VVRITk9hb3pX YkFURlJrVkpqaW1NTVZMR1JHa3B6Q20xQXdxUlB1MUhVaWZkcG9HVzRreWxUQk9LWmIvQUhBS214 NzFzaVNndWM5S3N4ZEtnVVZQSHhVb0N3dlNteWpLL2hRRGdVMTMrVTRxK2dqUGs0VTFEVTBuM1RV R2UxWU1wQjNxVlJVZFBXa01sQnAxTUZQRldJY090VEpVUUdLbVNxUWl3ZzRxVWRLaFhQcFVoYkhX dEVJclhRKzdWR2Z0VjY1T1F0VVp4bkhOWlRHUVU5YVpqRlBXc3lpZGFsRlFxYWtVMWFKWTd2VDFw bFNLUGFyUWlXT3JDVlhTcDFxMEJKMnFwY0RFbjRWWkxZcXJPY3lmaFRsc0JRdUNQTVAwcUpSelUw NHkvd0NGUkFZYXVkbEVpY0dyQzFBdldwbDlLcENKUlRxWURUeFZvUTllRFU2VkNvcVphdEFTaWxi cHhUUlFUeFZMWVJTbDREVm5NZm1yUmxHVmJOVUN0WVRLRlNyQ1ZYV3AwT0RTUUZoYWVPdFJLYWtX dFVJN3Z3dkhqVDRlT2NFLytQR3VtVmNNS3gvRDhXMndnd1ArV2EveXJiSTJpc1h1VUY3TDluOEth OVAwSzIyMzlHL3hydS9oOWJmWmZBdWpRNHgvb3FFL2p6WG5IaU4vTCtIbXRObjc3aFAvQUVIL0FC cjFydzlENUdnYWZGMDJXOFkvOGRGUU0xUjBvb29vQVdpaWlnQmFLS0tBRm9vb29BQlMwbExRQVVV VVVBTFJSUlFBdEhla3BhQUNpaWlnQXBhU2lnQmFCUlJRQVV0SlMwQUZGRkZBQjNvb29vQUtLS0tB R3lCL0tmeWgrODJuYm4xN1Y1b2ZBT3VNeExmWnNucVRMLzhBV3JzL0ZsNjFoNGJ1cFkzS1NOaU5H QndRU2Y4QTlkZVlwck9wbzRaTlJ1dDMvWFZxQVBTTkI4UFRhRm8xM0NzcXkzazRKeU9GRFl3b3Jr QjRBMXM0Qit6RDNNdi9BTmF1bDF2VXIyMjhDUlQzRHRGZlRKR2pNdnlrRThuOUJYQXg2MXFxU0tZ OVJ1dC9iOTZUejlLQVBSZE5zVThIZUc3bWFaL1BkZjNzbXpnRThBS0t6RitJMXZ1RzdUWlF2dEtD ZjVWdDMybTNtdmVHWUxhZWI3UGNTTEcweEtaNUhKR1ByV0JIOE9NUG1iVXZrenpzaXdmenpRQjJk bmRRMzFuRGRRRW1LVmR5NXJMOFErSTR2RDR0dzl1MDdUYnVGZmJnREgrTmF0cGF4V05wRmF3THRp aVhZbzlxODQ4ZjNQbmErc0lPUkJDcTQ5enovaFFCcmY4QUN4b2YrZ1pKL3dCL1IvaFZ5dzhlNmJk VExGY3d5MnU3Z08zekwrT09sR20rRHRGZlM3VjdxQXRPMFN0SWZPWWNrZW1hNDN4UllhZnAycnRC cDB2bVJiQVdHN2R0YjB6L0FKNjBBZXBhamZSNmRwczk4NDNwRW0vQVAzdlNzdlFQRkNhL2N6UXgy Y2tJaVRlV1p3M2ZHS3d0Ym5sdHZoM3Axdk1TSnA5aTRQWGFQbS9sdHExOE83WHk5TXVyb2ptV1VL UG9vL3hOQUhaVWxjMXIvakcxMGlacldDUDdUZEw5OFp3cWZVK3Z0WE9ENGhhbnYvNDlyUGIvQUhj Ti9qUUI2UlJXSjRkOFJ3YS9DNEVmazNNZUM4ZWNqQjdnMVgxL3hmYTZOS2JhRlB0TjJQdktHd3Fm VSt2dFFCMGRKWG5JK0lXcDcrYmEwMittR3ovT3VwOFArS0xiWGN3N1BJdTFYSmpKeUdIcXBvQW04 UWEvSG9GdkRJOEJtTXJsUW9iYmdBZGFsMFBWZjdhMDRYZ2dhQlM1VUt6YnM0NzF4ZnhDdVJKcTF2 YkE4UXc3ajlXUCtBcnByQzZ0ZkRuaEt6ZThmWmlJTnRIM25adm13UHpvQTZDdWUxN3hWRG9WNUhi RzJhZG1UZWNQdHh6eFdKWmVMOWMxYS84QXMybjJOc2R4eU53YjVGOVdPYXdQRXMwMTc0am5SM1Y1 Vkt3WlFZWElHT0I5YUFPay93Q0ZpUS85QXlUL0FMK2ovQ3RMUy9HdW02amNMYnlKSmF5dWNMNW5L ayttNFU1ZkJ1Z3BHQThCeUYrWmpPUnorZGVlNjFhMnRyckZ4YjZmSVpZVllCR3prNTlNL1hpZ0Qy VEZKV1hlYXRCb21rUVRhZzU4enkxWFl2M25mSE9LNUM0K0lOODBoTnZhVzhjZllQbGovU2dEMFA2 MFZ4K2krT1lyeTRTMzFDRmJkbk8xWlVQeVo5ODlLNjUyU05HZDJDcW95U1QwRkFDKzFGY1JxWGov QUdUTW1tMnl1aW5IbXpIcjlBSzBkSzhVK1pvTXVxYXFJNGtXWHk0MWlCeS9IdWFBT2wvT2l1Qm44 ZjNrczRTMHNvVVZtMnI1akZqK21LbnN2R0dvdnJrVmhkUTI2cVovSmNxR0JIT1BXZ0R0NlNtWEU4 ZHJieVR6TnRpalVzeDloWEhhVjRyMVhXTlhTMXQ3ZTNXSm0zTVNwSlZQVTg5YUFPMG9vb3hRQWxG RkZBQlNVdEhhZ0JLS0tLQUNrb29vQUtLS0tBRW9vb0ZBQmlrcGFTZ0FveFJSUUFVbExTVUFGRkZG QUJSUlJRQWxGRkZBQlJSUlFBVVVVVUFGSGFpa29BNUx4Nys2ZzBPNy93Q2ZmVjdjNTlBemJmNjFr NjBteTh1Qi9kbUIvTkYvK0pOYS93QVNSandaUE4zaHVJSmMvd0M3SXByTzhSTGpVcm5IZnkyLzlE Rk1ES1k1U3VGOFlSREVjbmNOdC9UL0FPdFhjL3cxeUhpK0xkWmx2N3JCdjZmMXE0ZkVKN0hDdFVa cVZxWVJXekpHWjRwalU2bU1ha0NHU3F6L0FFcXk5VjJGWnNhSXgxcS9DY3gxVEMxY2hYQ1lvZ012 eExoYWVhWkUzeTA4bXQwU1F2VUxWTTFSc0trQ0UwaHB6VXhqaXBZRWJWQTlUTWFnYzFER2lJOWFk R2NFZldreG1uSW56VkZobWhGL3JPS3ZEZ1ZSaU9KQlZzTlhSSFlrRzZWV2ZnMVlicFVMak5EQXJt bTlxa1phWjBxR01ZMVJOVWpHb21xR0NJbTYwbEtSU0NvS0pZT3BxL2FENVcrdFVZUmdtcnRzY0sz MXJTQkxMWnFDVHBVdWMxRTlhQ0t6Q296VXJWR2FnWTJtdFRqd09LWTFTeGtiVTJsTkpVQUZTSjBx T3BFKzdUUXkvYkQ1Vit0U21vSUd4R0ttSEl6VzNRbGxNU0tLY0prOWFwZDZNYzFsekRzWHZQWDFx TnA4OUtyRDBwd0hOUG1BbEkzQ21OQ1IwcVJUaXBRZmVpMXdLbmxQNlU0Uk9PMVhsd2UxU0JBZTFO UUM1bTdXSGFwRjZWY2FJR3F6THRZME9OaER3UUJrbWxXUlIzcW16bkpIYW1iam1seldLTlB6MEg4 VkJ1Rkk2MW5BNXA0RlBtSkxCa0w4WnBubDd3ZmFrUVk3VktuR2FOd0s1aFk5cVVRdjJGWEZOU3FL cmtDNVE4cDg5S1VBaHNWbzdCanB6VVVrWUNzY1VjdGd1VitsVEJsWHJVSTZWWFp5ZUtWN0JZMEJL Zzcwb25UKzlXWUdwNG9Vd3NhRFRyanJ6VVcvZWMxWEF6L1dwa0dCVDVyZ0kwTzRFOTZqOGhpZnUx YlE4VklLZkxjQ2lJSEhhbmlOODlLdnFLVXFQU21vQ0tDZzdzVk12V3BKRUFHZWxWNVcyaklwYkRK L01VSHJUaE1nNm1zMW56UXB6UnpoWTFQT1QxcGpURFBCcWt0U0tPYWZNSW1JM1ZHMEI5S2tIYXBB YzBXdUJVRURlbE9FTGp0VjFSVW0ybnlBWjRSd09sU3BuRldpbFFNdUdwMnNCNm5vOFBsMjZKMDJx QldqTGxWSDFxdnBxNWl6Vm01eUVIMXJuS016eFQveVQ2NFgvbnBmSXYxK1pSL1N2YU5QVFpZd0w2 UnFQMHJ4YnhSejRJdFYvdjZvZy84QUlsZTIyd3hBZy8yUlVqSnhSU1V0QUMwVWZuUlFBdEZGRkFC Uzk2U2wrbEFCUlJSUUF1UGVpaWlnQmFLTzlGQUJRS0tLQUZvb29vQUtLS0tBRm9wS1dnQW9vb29B T2xMU1VVQUxSUjJvb0FLS0tLQUk1b0liaE5rMFNTcDEydW9ZVkZIcDlsRTRlT3p0MGNkQ3NTZzFa b29Bdy9FZXQ2YnBRZ2oxQzFOejV1NWxYYXJZeDM1K3RVZEk4VGVIN3ZVSTRJTEVXMDduYkd4aFVa UHBrZEtiNG84TDMydTZqSFBEY1FSeFJ4YkFyN3M1enowRlZ0RThDUFk2akZkM3QxSEo1TGJsamlC NVlkTWswQVYvaUpkdUo3SzFqZGwycTBqYlRqcndQNVZnZUcvN1VrMXkyK3h2T1NKRkxuSjI3Yzg3 dndyMXNxcE9XVU1mVWlsQUFHQUFCN1VBR09hOGQxUnBkWThUWFBrRHpKSjV5a1l6MTdEOUJYcjhn WXhPRTRZcWR2MXh4WGtPaFhjT2s2OUZjMzZTYllHYmNxREozNEk2VUFXSDhJK0lFVm1ObTVBN0xJ cFA1WnFQdzEvWjhldHhSYXJiczRaOXE3amdJK2Y0aDM1cnI1dmlGcHFSa3cyMXpJL1lPQW8vUE5j WnA4RnhyM2lKTnFmUExONXNoVWNLTjJTYUFOLzRpM082K3M3UUhpT015RWU3SEg4aFhVK0dMWVdY aGV6Unpzekg1cm5wamQ4MmE0SHhvenY0cnV4SURoZGlqL2Qyai82OWRMNGgxZTF2L0NNeWFWTVpG ajhwWlFGSUtwNkg4cUFNVzhid2paM1plTVh1b1NCOXpmdkJzWSs1NzB6VS9GNlgybnlXVnZwTnRC RXk3Y241aXYwNEdLZzhMVGFGQk5NMnRKdWZqeWk2bGtIcndPOVdmRS9pRFQ3NjJXeDBxMlNPQU1I ZVFSQk4zb0I3VUFKNE9rYXhUVjlTSFMzdFRqM1luaitWVWZEZWwvMjlyZ1M1ZG1qQU1zeHp5M1BU UHVUWFNlRmRMTjE0TDFCRUE4eTdMcXYvQUFFY2ZyWE1lSDlXYlFOWDgrV0ppbURGTW5RNC93QWNp Z0QwcWZ3NXBFOW9iWTJFQ0pqQVpFMnN2dm11ZDByd1JlYWJxMXRlQy9oS3hTYmlBcHl5OXgrVlNh cDQ4czFzeU5MV1I3bHVBMHNlQW4rTko0YThRYXhxSXU3eThlUDdGYlJNekZZd3VYeDB6UUJ5ZmlT NkYzNGx2WmZ2SUpkZ0hzdkg5S0d1Si9FdXVRSmVYSWlXUnhHaC9oalhzQUtkNGMweE5jMXhZYmpk NVpEU3k3VHlmYjh6Vi94cG9xYVZxTVZ4YXA1VnRNdnloT2lNT3VQMFA1MEFkOXArbldlZzJEUjJ5 YlVSUzd1ZnZQZ2RUWGswTnZkYXpxVEpiUitiY1RPMG1NL2lhOUV0ZFNmWGZCZHhKRWMzZmtQRzRI WGVGL3FLNHJ3cnFsbm8rcFBkM2lTTVBLS0lJMUJPVDEvUVVBSlA0VzEyM2hlVjdPUW9veTIxd3gv TE5XL0JKMDMrMkVqdTROOXczK29jbjVBMys3NjhjR3Q2NytJRmtzRGl6dHAzbUl3dm1ZVUEvblhN K0VyR2ErOFJRU0lwMlFQNXNqZGgvd0RyTkFDK01MMTczeEZjSXh6SEFmS1JUMngxL00xZjB2eEpv ZW1XYVFybzd5UGo5NUxKdFl1ZS9YK1ZVZkZ0bTloNG1tbGRNeHpzSmt6MGIxSDUxdVE2ajRMa3Ro TExZUnhTNCthTHltSkI5dTFBSEo2emRXVjlmbWV3dEd0WW1YNW8rUHZlb3grRmRYcitxUy84SU5w eXM1RXQyaXE1N3Nxam44K0t6cmJVOU92dFFTMHMvREZtNWtmYW01em5IcWFkNDhrU08vdExHRlFr VnZCd3E5Qm4vd0NzS0FMM2dqUXJXZXhmVWJxRlptWnlrU3VNaFFPcHgvbnBXWjQ0blQrMWtzWUVX T0czUUh5MFhhTnpjazRINFYzSGgyMSt5ZUg3R0U4SHlnemZWdWY2MTU1Si93QVRueGtjY3JOZDQv NENEL2dLQU83MFh3OVlhZnA4QWUxaWt1TnFzOGtpQmp1L3BpdUYxOWZzUGpDZHh4aTRXVWZqaHE5 VVBXdk9QSHNIbDY1RkwybGdYOHdTS0FML0FJODFrTUYwcUIrT0pKeVAvSFYvcldyNFAwYit5OU04 K1pjWE55QXpaNnF2WWYxcmxQQytsdnJtdE5jM1daSVlTSkpTZjQyN0wvbjByMDJnQW83MGxGQUFh S0tLQUVvb29vQUtNVVVVQUpSUlJRQWxIMW9ORkFCbWlpaWdCS0tLS0FDa3BhU2dCYzBsRkZBQlJS UlFBbExTVVVBRkZGRkFCUlJSUUFVVVVDZ0FvTkZCb0E1YjRqSnUrSCtzL3dDekJ1L0lnMWxhNlMx d0g3UGJ4dCtwL3dEaXEzUEhhN3ZBZXRqL0FLYzMvbFdCcWpib2JNLzM3R00vK2dmNDBBWmcrN1hM ZUxoL3hMSmZ3UDY1cnFSOTJ1WjhXeEI5SXVNOWtMZmtLcFBVUjU1NWlIdlNaVmhuTloyL25yVXFT YzF0emlzeXd3cUVxeFBTcDE1SXFkVUE3VTByaUtCaGM5QlRQSWZyaXRNakZNUHJSeUFVVnR6dTVG U2hOZ3dLbVBGUnNlYVZyREJaZ09DY1ZKNTZudlZWeHptb200cGMxaFdMeG1UMXB2bUo2MW5rbW1o em1sempzYURIamlvSEJwSW5KNHF6R29icnpUV29GUXh1ZTFJWVg5SzBnbkhTa0lvNUF1Wm5rUDZW SXNIUE5YRzRxTm00cGN0Z3VSZzdhZXM2OUNhaWJwVVJHS1Y3QVcvUFQxNHBETWg3MVJKSUZNM0VV dWNMRjh1cDZHb3ozcXFyNHF3cDNLS2Q3aFlqS3NXd090SjViSHRWNUl4d2U5U2JBTzFISmNETE1M LzNhQkMyZWhyUllWRVRpamtzQkFJOW40MDRTRk9CM29jNXFOdWFXd3l6OW9VZDZRem9mNHFwdFVa TkhPRmk4WkVQZW1zUVY0TlVnYWtSc3NCUzVnSlQwcU1xeDRBcWJITlRwSFR0Y1JSTVQrbE44dC9T dE1vQlVaSEZISU1wTEVjOUtjVjI4Vk9UaW9tNU5LMWd1S3NtM0E3VktKMUhlcXJETk0vT2xld0NV VVVuZXBHeVJhZUJURnA5VWhEaFVpbW82ZXRNUlBIVmhhcnhWWld0WWlGSTR6VkdiL1dHcnpmZHFo TGtNYVV4b3B0OTQwbEszM2pTVmc5eGoxcVpSVUtkcW1XcVFEd01VNFUzdFNyVmlKVnF6SDZWV1Fa cXluRldoRW9IRk1tQUViVkl0UlhIK3JiNlZWdEFLUis3Vkp1dFhlMVVtNjFoTXBBdk5UcFVDOFZP bEpBeVpSVHhURnhUKzlhSVE1U1FjVktwcUVkYWxUclZDTENkS2t4VWFkS2tGYUlDS1lmSldmY241 QjlhMEovdVZuM0gzQldjd0ttYWxTb2U5U3BXS0tMQ1ZLQlVhR3BSV3FKSENuZzgxR090UFVjMHdK a3FWYWlUcFVxOWEwUU1kaXEwdkQxYTdWVmwrK0tURWoxN1MxL2NyOUtudlJoRit0TjBwZjhBUjAr bFNhZ01SeC83MWN4WmorSlArUlEwd2YzdFdULzBhYTl1ZzRpVWUxZUkrSWpud2xwSC9ZV1Qvd0JH dFh0MFArckgwcVJrdExTVXRBQlMwbExRQVVVVXRBQlJSUlFBdEZGRkFDMFVVbEFDMHRKUzBBRkZG RkFCUzBsTFFBVVVVVUFMM3BLS1B6b0FXaWtwY1VBRkZGRkFCUlJSUUFDaWlpZ0JlbEFwTzFGQUMw VW5haWdBNzBVVVVBRlltcStGTksxZWN6elJ2Rk0zM3BJVzI3dnFPbGJkRkFIS3I4UDlJREFtVzdZ ZW04RCtsYjJuYVZZNlRDWXJLM1dJTjk0OVdiNm1ybEZBR0xyZmhteDF4MWttOHlLZFJ0RXNmWEhv UjNwZEc4TjJtajJkemE3MnVVdUQrODgxUnlNWXhXelJRQnlNL3dBUHROa21MdzNOeENuOXdZWUQ2 RTFZYndMbzV0VWhIbnF5c1dNb2NiMit2SFN1bXBLQUtXazZYRG85Z0xPM2VSbzFZc0RJY25tcU9y K0ZOTjFpWXp5SzhOd2Vza1J4dStvNzF0MFVBY2pCOFB0TmprRFMzVnhNdjl6aFFmeXJvWmRLdFgw bDlNaVR5TFpsMllpNElIZXJ0SlFCamFONFpzdENua210bmxkNUUyZnZDRGdaenh4VnpWZEx0dFlz VGFYTzRKdURCa1BLa1ZkN1VVQVpHaStIcmJRcEpXdFpyaGhLQnVXUmdSeDM2ZGFyYWg0TjBqVUoy bUtTUU94eTNrdGdIM3hYUWNVbmVnRGw0L0FXa0krWGU2Y2VoY0FIOGhYUVdkamE2ZGJpQzBoV0tN YzRVZGZjK3RXS0tBS21vNlphYXRiR0M4aUVpOVFlaFUreHJtejhQZFBNbVZ2YmtKL2R3cC9XdXVv b0F6ZEowSFQ5RlZ2c2tYN3h1R2xjNVkvalZMVXZDTmhxbW9TWGx4TGNlWStNaFdBSEg0VnYwVUFO MkFSN0I4bzI3Ump0V0ZwbmhIVDlMdjB2SVpMaDVVemdTTUNPZndyZW9vQU90ZVplTE5ST3M2NHR0 YWpla0o4bVBIOGJFOC9yL0t2UmIrR2E1c1pvTGVieVpaRjJpUWpPMnVmMEx3Y21qNmdMeVc1Rnc2 QStXTm0zYTNyMW9BMTlFMHROSDB1SzFYQmY3MHJEK0pqMS93QUswS0tLQUVvb29vQUtTaWlnQW9v b29BS1NpaWdBcE9sSFNqTkFCUlJSUUFVbExTVUFGRkZGQUJTVXRKUUFVVVVkNkFFcGFLS0FFeFJS M29vQUtLS0tBQ2lpaWdBb29vb0FLU2lpZ0RDOGFEUGduV2dmK2ZLVC93QkJybWIzblR0TmIxMDZQ K1VWZFQ0d0dmQnV0ZjhBWG5ML0FPZzF5MTBmK0pScFk5ZE5qL2xGUUJuajd0Yzk0cEgvQUJLTHYv cmsvd0Q2Q2E2RWRLNTd4VnhvOTEvMXlmOEE5Qk5VSThoYWxRL01LYTFMRDk2bUZ6VGkrOHRXd0tw eGo1eFZ3Y0N1aU94TmhHcUY2bWFvSG9BaUpwdE9OTnFBR3NLaGVwbTZWQy9TcFkwVjNxT3BHcU05 YXpLUlBiSDVzVm8yL1ExbjIyTjM0Vm9XL2V0SUVzc0VWRTFTbnBVVDFxeEVMMUNUVXIxRWF6WURU VEdGUHBqZGFsaklYRlF0MXFaNmdicldiR2dCcTVEOXdWVEZYSXZ1clZSQm1qR0J0RksxSkgwRks5 Ym9rZ2VvR3FkNnJ0VU1ZdzlLYWVsT05OUFNvQWphb202MUszV29tcUdOQ1U2UDc0cHRPaisrS0VO bGorSVZmVWZMVkQrSVZvUjlLMWlTTllWWGVyRGRLclBUWUVUR21VNXFiV1l4RFVaNjFJYWpwV0Fi UmlseFNHcHNNY3BxUVZFS2VEelRFeVFVOVJUVkZTamlxUWlTT3JDMVhWaFVnY0N0RTBGaVluaXFF dkx0VTdTZ0hPZUtyczI1c2lsSjNCRlJ2dkdrcVJvejFwbXc1ckt4UTVhbVUxQ0JnMDhkYVltVERt bkxVYUVHcFl4a21xUWlSUHBWaEtoR0trVmhWb1JPS1pNUVkyK2xOOHdBVkhKSUNwR2FwdlFMRmM5 RFZKaFYwZWxWMmpJckdTS1JFb3FaS2J0STdVNWFTVEFtV3BCVUlxVkt0Q0hxTTFLZ3BxRGlwQWNH ckVTcDBxVHRVSVlDbkZ4aXJUQUpqOGxaMXlNb0RWeDNCR0tyU0x2R0JVUzFHaWppcFVGT0tIMG9D bjByS3pHU3BVb05RS0NLa0JxMFNUQVU5UlRCMnFZREZXZ0hKeFVvcUlHbmhoVklHU0U4VldtKzlV ak9CVUxObHFIc0pIdE9sTC9veWZTbDFRWWpqLzNxZnBJLzBWUDkwVTNWK0lvLzk0MXpGbUo0Z0gv RkphTi8yRmsvOUd0WHQ4WDNCOUs4UTEvL0FKRkhSZjhBc0xwLzZOYXZiNHZ1Q3BHUzB0SlNpZ0Fw YVNsb0FLVVVsRkFDMFVVVUFMUnpSUlFBZHFXa3BhQUNpaWlnQmFLS1NnQmFLS0tBRm83MFVVQUZG RkZBQlMwbEZBQzBkcVNpZ0JhS0tLQUNpaWlnQmFTaWlnQW9vb29BS0tLS0FDaWlpZ0FvcEtLQUNq dFJSUUFVVVVVQUgwb29vb0FTaWlpZ0Fvb29vQU8xSlJSUUFVbExTVUFIYWlpaWdBcEtVMGxBQlJS U2Q2QUZwS0tLQUQ2VW1hS0tBQ2lpaWdCS0tLS0FDajhhT2FTZ0Fvb3BLQUNpaWlnQW9vb29BU2lp aWdBNHBPMUxSUUFsRkgwb29BS0tLS0FFb29vb0FLS0tLQUNpakZIMG9BS0tLS0FDa29vb0FLS08x RkFHTDR2L0FPUk4xbi9yeWwvOUJOY3JjLzhBSUowbi9zR3gvd0FvcTZyeGQveUp1cy85ZVV2L0FL Q2E1VzQvNUJPay93RFlPai85QmlvQW9MOTJ1ZThWL3dESUd1dit1VC8rZ211aEhBNHJudkZYL0lJ dWYrdWJmK2dtcUVlUWtacFVYNWhVaFE1NlZJa1JKSEZVa0l0UmNNS3Q1cWtEdElOV0ZjSG5OYlJK SHRVVEROUExBMDAwMkJBUmltMU1SbW9tR0R4VTJHTVkxQTlTT2VhaVlacUdORUxWSDNxWW9mU2tX TTU2Vm14anJZWWV0R0E5ZUtxUlJsVG1yRWJoZURXa1JNdG1vMnBQTUZKdUZhaUluRlFrVlliQnFO MTRyTmdRbW8yTlNOMHFFMUl4ajlhZ2JyVXhCUGFtN0NmV3MybU5FZU9LdVEvY0ZRTEdUMEhOV1ZY Q2lxaUJlalB5aW5OVmRKQWU5UDhBTUZiSmtqWHFCdnBVN0VIdlVaRlN4a0JGTlBTcEhHS2liakZR TVkxUXQxcVEwd3JVTkFKVG8vdmltN1Q2VklpSElPT0tMQVRmeGlyNm5pcy92VmhaQm5nMXBGaUoy TlYzRlBNZ05OSkZOZ1FNS1pVekROUk53YWtZdzlLWWFWanppbTQrdFNCYUNLZTFQRVNlbWFZcHFl UG1yc0laNUF4bkZSdEJ4bXJvcHJyOHBwOG9GSE9CVVpsSnB6L2RxR3MyTkQvTmFsRWpldFJkNmtX a01mdUo0N1U5YWFCVHdLb1JLTU1CeFRoR3A3Vkd0VEpWSVFvaFQrN1FZRi91MU1vcVRHUlYyUUdl OGV3OUtZMG13Y1ZhdVJ3S29UOUZxSmFBS1ptOWFCSzNyVUZQV291T3hNSGYxcHlrbHFhdFNBVlZ4 TWZVb0NuZ2lvYWtXcVFFZ2pVOXFlSVUvdTBpVk10V3RRSVRBdnBVSlRZMkt2WUpxcmNERW40VU5D SUhsMjhWRjV6WjYwMmM0a05SRDcxWXRzb3NDVit1YWVKSHFCT3RUcUthWWh5NTNWTW81cU1DbnJW b1JLRVU5cWNzYWVsTVU4MU10V2dFOGxmU21OQXZYSFNyQW9aZUtkZ0tlY1pxRnBqNjFMTHdyVlJa cXlrN0RKL1BiSFduTEkzclZaZXRUb0tTWUV1NWo2MDllbE5XbmdWb2hIdU9rai9SRStncHV0ZjZx TC9lUDhxazBnWnM0ei9zaW85YkdJWWY5NC95ckFvd3RlLzVGSFJmK3dzbi9vMXE5d2krNEs4TzEz L2tVTkcvN0M2LytqV3IzR0w3aTFJeVdsRkpTMEFZL2l2VnA5RDhOWG1vMnlSdk5EczJpVUVxY3Vx ODRJN05YbWYvQUF0blgvOEFuMTAzL3YxSi93REYxM3Z4RS81RVBVdisyWC9vMUs4SG9BN3YvaGJH di84QVBycHYvZnFUL3dDTG8vNFd6ci8vQUQ2NmIvMzZrLzhBaTY0U2tOQUhlZjhBQzJkZi93Q2ZY VFArL1VuL0FNWFNmOExhMS84QTU5ZE4vd0MvVW4veGRjSWFiUUIzdi9DMjlmNi9aZE0vNzlTZi9G MGY4TGMxL3dENTlkTS83OVNmL0Yxd1ZKUUIzdjhBd3R6eEIvejY2Wi8zNmsvK0xvLzRXOTRnL3dD ZlhUUCsvVW4vQU1YWEFVbmFnRHZ6OFgvRUgvUHJwbi9mcVQvNHVrLzRXLzRoL3dDZlRUUCsvVW4v QU1YWEFVbEFIb0gvQUF1RHhEL3o2YVovMzZrLytPVW4vQzRmRVA4QXo2YVgvd0IrcFA4QTQ1WG45 Tk5BSG9QL0FBdUx4RVArWFRTLysvVW4vd0FYU2Y4QUM0L0VQL1BucGY4QTM2ay8rT1Y1NmVsSWFB UFF2K0Z5ZUl2K2ZQUy8rL1VuL3dBWFIvd3VYeEYvejU2WC93QitaUDhBNDVYbmxOb0E5RS80WE40 ai93Q2ZQU3YrL01uL0FNY3B2L0M1L0VmL0FENTZWLzM1ay84QWk2ODdOSlFCNkwvd3VqeEgvd0Er ZWxmOStaUC9BSTVTZjhMcDhTZjgrZWxmOStaUC9qbGVjOXFiUUI2UC93QUxxOFNmOCtXay93RGZt VC80NVRUOGEvRW4vUG5wUC9mbVQvNDVYbk5NTkFIcEgvQzdQRW8vNWN0Si93Qy9Nbi94eWsvNFhk NGwvd0NmTFNmKy9Nbi9BTWNyemVtbWdEMG4vaGQvaVgvbnkwbi9BTDh5Zi9IS1EvSER4Ti96NWFU L0FOK1pQL2psZWFtbW1nRDB2L2hlSGliL0FKOHRJLzc4eWY4QXh5ay80WGw0bS81OGRJLzc4eWYv QUJ5dk5EVFRRQjZaL3dBTHo4VC9BUFBqcEgvZm1ULzQ1U2Y4TDA4VC93RFBqcEgvQUg1ay93RGps ZVpHbW5yUUI2Yi9BTUwxOFRqL0FKY2RJLzc4eWY4QXh5a1B4MjhUL3dEUGpvLy9BSDVsL3dEamxl WkdtbWdEMDcvaGUvaWovbngwZi92ekwvOEFIS1EvSGZ4Ui93QStHai85K1pmL0FJNVhtRk5OQUhx SC9DK2ZGSC9QaG8vL0FINWwvd0RqbEovd3ZueFIvd0ErR2ovOStaZi9BSTVYbHhwS0FQVWYrRjll S2Y4QW53MGYvdnpML3dESEtUL2hmZmluL253MGIvdnpMLzhBSEs4dU5OTkFIcVgvQUF2enhWL3o0 YVAvQU4rWmYvamxJZmo1NHEvNThORy83OHkvL0hLOHNwRFFCNm4vQU1MOThWZjgrR2pmOStaZi9q bEovd0FMKzhWZHJEUnYrL012L3dBY3J5czBsQUhxbi9DL3ZGWC9BRDRhTi8zNWwvOEFqbEovd3Y4 QThWZjlBL1J2Ky9Ndi93QWNyeXVtbWdEMWIvaGYvaXYvQUtCK2pmOEFmbVgvQU9PVW4vRFFIaXYv QUtCK2pmOEFmbVgvQU9PVjVVYWJRQjZ0L3dBTkErSy8rZ2Zvdi9mbVgvNDVTZjhBRFFQaXYvb0g2 TC8zNWwvK09WNVRTVUFlcmY4QURRWGl2L29INkwvMzVsLytPVWY4TkErSy93RG9INkwvQU4rWmYv amxlVVVob0E5WS93Q0dndkZuL1FQMFgvdnpMLzhBSEtUL0FJYUM4Vi85QS9SZisvTXYvd0Fjcnlp aWdEMWYvaG9IeFgvMEQ5Ri83OHkvL0hLUCtHZ2ZGZjhBMEQ5Ri93Qy9NdjhBOGNyeWlpZ0QxZjhB NGFCOFYvOEFRUDBYL3Z6TC93REhLUDhBaG9IeFgvMEQ5Ri83OHkvL0FCeXZLS0tBUFYvK0dnZkZm L1FQMFgvdnpMLzhjby80YUI4Vi93RFFQMFgvQUw4eS93RHh5dktLS0FQVi93RGhvSHhYL3dCQS9S ZisvTXYvQU1jcFArR2dQRmYvQUVEOUcvNzh5LzhBeHl2S2FLQVBWdjhBaG9EeFgvMEQ5Ry83OHkv L0FCeWovaG9EeFgvMEQ5Ri83OHkvL0hLOHBvb0E5Vy80WC80ci93Q2dmbzMvQUg1bC93RGpsSC9D L3dEeFgvMEQ5Ry83OHkvL0FCeXZLYUtBUFZ2K0YvOEFpdjhBNkIramY5K1pmL2psSC9DLy9GWC9B RUQ5Ry83OHkvOEF4eXZLYUtBUFZ2OEFoZjhBNHEvNkIramY5K1pmL2psSi93QUwvd0RGWC9RUDBi L3Z6TC84Y3J5cWlnRDFYL2hmL2lyL0FLQitqZjhBZm1YL0FPT1VmOEwvQVBGWC9RUDBiL3Z6TC84 QUhLOHFvb0E5Vi80WC93Q0t2K2dmbzMvZm1YLzQ1Ui93djd4Vi93QStHamY5K1pmL0FJNVhsVkZB SHF2L0FBdjd4Vi8wRDlHLzc4eS8vSEtQK0YvZUt2OEFvSDZOL3dCK1pmOEE0NVhsVkZBSHF2OEF3 djN4Vi96NGFOLzM1bC8rT1VmOEw5OFZmOCtHamY4QWZtWC9BT09WNVZSUUI2ci9BTUw5OFZmOCtH amY5K1pmL2psSi93QUw5OFZmOCtHamY5K1pmL2psZVYwVUFlcS84TDk4VmY4QVBobzMvZm1YL3dD T1VuL0MvZkZYL1BobzMvZm1YLzQ1WGxkRkFIcW4vQy9mRlgvUGhvMy9BSDVsL3dEamxIL0MvUEZY L1BobzMvZm1YLzQ1WGxkRkFIcW4vQy9QRlgvUGhvMy9BSDVsL3dEamxIL0MvUEZYL1BobzMvZm1Y LzQ1WGxkRkFIcW4vQy9QRlgvUGhvMy9BSDVsL3dEamxIL0MvZkZYL1BobzMvZm1YLzQ1WGxkRkFI cW4vQy9mRlgvUGhvMy9BSDVsL3dEamxIL0MvUEZQL1FQMGIvdnpMLzhBSEs4cm9vQStpZmhqOFRk WjhhZUpiblR0UnRyQ0tHT3phY0czamRXM0IwWCtKeU1mTWE5VzdWODZmQUwvQUpIdTkvN0Jrbi9v Mkt2b3VnQW9vb29BeGZGMy9JbmF6LzE1Uy84QW9Kcmxibi9rRTZUL0FOZzJQLzBHS3VxOFhmOEFJ bmF6L3dCZVV2OEE2Q2E1VzUvNUJPay85ZzJQL3dCQmlvQW9qcFhQK0poblRaeC9zTi9LdWdyQThT LzhnNmIvQUhXL2xWSVI1b1kxeDBwTUFEZ1U5cWpKcm9zU1J0MHFMY3k5RFUxUnNLa0NNeU1CMXB2 bnNCMW9jVlhZMURZeXlrNTlhbURic0dzOE5nMWNnTzVLYVl5ZFlnM3pZcVR5UjZWSkd2eTA4aXRF aVVWekVvSFNtR05QU3BucUZqU3NBMStuSEZRc0trTk1hcFl5SXV3NzAweXY2MDVoVUw5S2k0SWY1 N2V0UFdZazFVcHlOODFLNHk2QnVJcVpZUjZVeUlmdkJWekdLMWloRmN3cU8xTk1TRHNLc01PS2hi aWl3RWVGWG5GUk4xTlBZMHcxTEVRbktuZzBoZGdPdFNFY1ZDOVEyVUo1ekR2U2laczlhaU5JS203 QXRCeS80VklrZTg1cXZBZXRYclpjcTMxclNPb2hCQ3ZwU0dKQjJxMWpGUlBWdEFRTWllbE1iQVhG T1kxR2FoZ043VkdjcjBxUTB4cWtFTUxzTzlKNWorcHBEU1ZOeGovTWIxcCs3Y00xRFVpZmRvUXlW SXQzelZMNUFQYW53TG1NVk1NNDZWcHlrbEpldFdJcXJyMXF4SHhRZ0xDamlteThMK0ZPV215OHJW OUJHYko5dzFEVXovY05RMWd5a0ozcVZhaTcxSXRJWk1CVHFZRFRoVmlIQ3BrcUVDcGtxa0lzcDBG U2djVkVsU2c4Vm9oRlM1UFNxRS9SYXZYUTZWUm43Vm5JWkRUMHBsUFdza01uU3BSVVMxS0RXaUVI ZW5yVE85UFVWUzNFVEoxcXdsVjA0cXduU3RFQkoyNHFsY2Y2ejhLdVpxbmNmNno4S0pBVUxrZnZE VVM5YWx1UDlZYWlGYzczS0prcWRhcnBWaGZyVklSSUtjT3ROQXAzZXJFUFhyVTZWQ29xWkt0QVNp aHFBYUc2VlhRUlJsR1ZhczVoaHEwWmZ1dFdlMzNxd2tVaHlWWVFWWFhpckNHa2daT3RQNzFHdFA2 MXFoSHVtampObkgvdWlvdGVHSVlmOTgveXFmUmgvb2NYKzZLaDhRLzZtRC9mUDhxd0tPZTF6L2tU OUYvN0M2LytqV3IzS0w3Z3J3M1cvd0RrVHRGLzdDeS8ram1yM0tMN2kxSXlXaWlpZ0RtZmlIL3lJ ZXBmOXN2L0FFYWxlRDE3eDhSRC93QVVKcVgvQUd5LzlHcFhnOUFCU1V0SjJvQUtTbE5KUUFsSlMw bEFEVFNHbFBTaWdCdEpTMGxBQ1UwMDZtbWdCcDZVaHBUMHBEUUFsTnAxTm9BYWFRMHBwRFFBMm0w Nm0wQUpUVFRxYWFBR21tbW5HbW1nQnBwcHB4cHBvQVEwMDA0MDAwQU5OTk5PTk5OQUNHbW1uR21t Z0J0Tk5PcHBvQWFhU2xOSlFBMDBocFRTR2dCdElhV2tOQURUU1VwcEtBRXBwcDFOTkFDR2twVFNV QUpTVXRKUUFsSWFXa05BQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVV QUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRkZBQlJS UlFCNnA4QXYrUjd2Zit3Wkovd0NqWXEraTYrZFBnRi95UGQ3L0FOZ3lULzBiRlgwWFFBVVVVVUFZ dmk3L0FKRTNXZjhBcnlsLzlCTmNyYy84Z25TZit3Ykgvd0NneFYxWGk3L2tUZFovNjhwZi9RVFhL M1AvQUNDZEovN0JzZjhBNkRGUUJScm4vRXYvQUNEWi93RGNiK1ZkQlhQK0pmOEFrR3ovQU80Mzhx cGJpUE5XcU0vV3BXRlJHdWdrVEZNYW45cVkxU0JCSlZaNnN5ZEtyTldjaWhnSE5YNFJpT3FJOWF2 UW5NZEVCTXZ4SDVha2FtUkRDOWFjMWJva2hlb1c2Vk05UXNLbGpJNlE5S1VqRk5OUXdHTlZlU3Ay cUJ4bW9ZMFFtblJqTERQclRTS2RIdzQrdFQxR2FNWCtzRlhoeUtwUS93Q3NGWGVncm9qc1NNYnBW WjZzdFZaNkdCQzFKMnB6VTN0VUF4cDZWQzFTc2FpYW9ZMFF0MXBLVnV0SlVGRTBIZXIxcDMrdFVZ TzlYN1hnTjlhMWdTeXlhZ2ZwVXhOUXlkSzBZaXMxUm1wR0JxTWlzbU1USEZOYW5kcVkxSmpJMkZO cHpVMm9BS2tUcFVkU0owcG9iTDFzZmxBOTZueFVGdVBrQnFmTmJvbGxKUnpVeUhGVS9QeFFKeldT WTdHaHVHS1k3NVdxZ25OTkxzeHF1WUxBNE93MURpcklwVENDYWl3RlduS2FzaTJGTDlsbzVRSVFl YWtGQnR5S0FNWUZPd0VpaXBVcXVaUW9wUHRCcWt4R2dwcFdiSGVzOFhKcGZ0QnF1WUxFODV6aXFr d3ppbnEyNnBGWGNwelV2VVpTSXdhVmZ4cTM5bkZQRnFDTTFQSUZ5c3BxUlR6VXYyWEhTbW1Jb2Zh cXNJTzlUSXRRMHJUYlJnVXdMU2pGU2c0TlovMm9pbEYwVFQ1Z3N6UUxDcXMzTW40VkY5b1k4VUtj am1qbXVLeERNdVpPbFJiY0dyNGpETDcwbjJZWjRxSEVkeW12V3BsTlRpMUZMOW13S2Fpd0kxUE5T cjFwbmxGVDdVNE1GcWhFcTFLdFUvdE9LQmRjMVZ3TCthUm02MVNGeWMwR1V0M281Z0hQME5VMlQy cTZvcFRBRzVxWEc0eWdvK3RUTDFxeUxVR25DMUFvVVFJUWFsV2cyK09sQUczakZVa0k5NTBjWXM0 LzkwVlg4UmNXOEgrK2Y1VmEwWVpzb3ovc2lxdmlRWXQ3Zi9mUDhxd0tPZDF2L2tUdEUvN0N5LzhB bzVxOXlpKzRLOE0xci9rVGRGLzdDNi8ram1yM09MN2dxUmt0RkZGQUhNZkVUL2tROVQra1gvbzFL OElyM2Y0aWY4aUhxZjBpL3dEUnFWNFAyb0FXa3BhUTBBSWVsRkI2VVVBTm9wYVNnQnA2VUdnOUtE UUEya3BhU2dCdElhZFRUUUEwOUtRMHA2VWhvQVNtbW5VMmdCcHBLVTBsQURhYlRxYlFBbE5OT3Bw b0FhYWFhY2FhYUFHbW1tbkdtbWdCRFRUVGpUVFFBMDAwMDQwMDBBSWFhYWNhYWFBRzAwMDZtbWdC cHBLVTBsQURUU0dsTklhQUcwaHBhUTBBTk5KU21rb0FTbW1uVTAwQUlhU2xOSlFBbEpTMGxBQ1Vo cGFRMEFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZG QUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUhxbndDL3dD Ujd2Zit3WkovNk5pcjZMcjUxK0FQL0k5M3YvWU1rLzhBUnNWZlJWQUJSUlJRQmkrTHYrUk4xbi9y eWwvOUJOY3JjZjhBSUowbi9zSFIvd0RvTVZkVjR1LzVFM1dmK3ZLWC93QkJOY3JjL3dESUowbi9B TEIwZi9vTVZBRkdzTHhHdS9UNVY2WkJINlZ1MWthN0M4bW55YkYzTmpqNjFTRWVYTlViQ3BibUM2 dEZEWEVXd0gvYUIvbFZjU2h1TTF2ZE1td0hnVkV4cVVqUEFvRUdldEFGUjZpWVo2Vm9mWlFhVDdL dFR5REtDeDFiaUdFeFVua0tEbWtQV2psc0Z5eEcyRnArYzFSOHdvYVB0SkZWeldGWXR0VVpHYXJt NitsSjlwcGN5QWtiZ2NWRzFPTHEvU21sQzFJWkN4NHFKdlNydjJiTkgyUUNwNVJtZnR5YWVxNFlZ cTRiWVVDSlZIU2x5QUVadzRKcTBHejFxa2VLUVRzdFdwV0pMekhJcUpxckc2SXBQdEpOSE1PeEt5 MUdlS1FUaWxKeU9LUVdJbU5SdFU0aExVNzdOeFV0REtKR2FRS2F2RzFBcHYyY0NseWdRd2dqZHhW eUZzS2FpWlF1QUtZVzJ0eFRXZ0YvZGtVeHVsVkJjRVUwM0p6VmM0ckZodWxSTjB6VWYyaW5DVU1Q ZXB1TVNvMnFRanJRc0pZVXR3SzVwS3RmWnFRMjJLWEtCV3FST0JVdmtnVTFsdzFDUXl4RTJFSE5U SzR4V2Z2S25pbDg5cXZtc0lob29vcklZcWlucUtSYWtGVWhEaDFxUUhtb2hUMXFnTENjMUtvcUdP cksxYUpHc21hcHlEYTVGYUI0R2FvVGN5R2lReW14NU5OelN0OTQwbFlGRDFxUUNtSlVxMVNFeHlq RlNKeFRBS1Zhb1JPcHFkQlZaZXRXWTZ0Q0g0NHFLUlAzYlZPb3BzL0ViZlNyZXdGRHArVlZTM3JW ckhGVVdITllTWlE0SG1wVkZSSlV5ZGFTQWtWYWtVWXBxMC92V2lFUFU0cVZUbW9SMXFSS3BDTENp bmxRUlRVNkNuaXRFRElaVndsVVorRkhhdENjL0pXZGNES0FWbklDdVdKTk9VODFDS2xUazFpbU1u VVZLb3BpVktCV3FBY1BhcEZOUjk2Y090VWhFNjA4Q29rTlRMVm9BSzFYa0dHcTMycXJOOTZreEk5 MzBYaXhpLzNCVmJ4TC93QWUxdjhBNzUvbFZuUkIvb01mKzZLcmVKc0MydC8rdWgvbFhLV2Mzck9Q K0VOMFQvc0xyLzZPYXZjNHZ1RDZWNFpyUC9JbTZKLzJGbC85SE5YdWNYM0JTR1MwVWxMelFCekh4 RS81RVBVLysyWC9BS05TdkNLOTMrSWYvSWlhbC8yeS93RFJxVjRSUUFZb294NzBVQUpTVUhwUlFB bEpTMGxBRFQwb05Cb05BRGFTbHBLQUVwcHAxTk5BRFQwcERUalRUUUFsTk5PcHRBRFRTR2xOSWFB RzAyblUyZ0JLYWFkVFRRQTAwMDA0MDAwQU5OTk5PTk5OQUNHbW1uR21tZ0JwcHBweHBwb0FRMDAw NDAwMEFOcHBwMU5OQURUU1VwcEtBR21rTkthUTBBTnBEUzBob0FhYVNsTkpRQWxOTk9wcG9BUTBs S2FTZ0JLU2xwS0FFcERTMGhvQUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FD aWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29v QUtLS0tBUFZQZ0QveVBkNy9BTmd5VC8wYkZYMFhYenA4QXY4QWtlNzMvc0d5ZitqWXEraTZBQ2lp aWdERjhYZjhpYnJQL1hsTC93Q2dtdVZ1UCtRVHBQOEEyRG8vL1FZcTZyeGQvd0FpYnJQL0FGNXkv d0RvSnJsTHIva0U2VC8yRG8vNVJVQVVxdDZXak5xVUlUYnUrYkc3cDBOVXZ4cTlwREZkVWhJNjgv eXFuc0k1SDRxMjBpMkNTU0NJYmVRVXpuN3lqdjhBV3ZKa2Y1cTlqK0xaM2FMbi9QMzByeGlNWllV NHNMR2pIeXdxenRxdkZ3d3EyT2E2STdFalNPS2phcFdxQis5REFZeDk2ak5PSnB0UXdJM0dlS2lZ Vk93cUYrbFN4bGRqaW1oc0dsZnJVWjlLekdXb0RselY2QVZuMm8rZXRLM1BXdElDYUpRdUtZNHFZ aW9ueDJyVmlJV1BGUnNlS2MzV29pYXpZRFRVYmRLazdVeGhVc1pBM0ZSazFLNHFFOEdzMk5DaHNW YmlPVkZVZ0t1UkQ1RkZVZ1plVkJ0Rk9LNEZPajZBVXJldGJyWWxGZGhpb21OU3lWWFk5cWhnTmFv MkdhZWFROUt6R2lGcWpKcVZxaWJyVXNvU25wOThVeW5SL2ZGQ0JrLzhRcTZxZE9LcC93QVFyUVEv TFdzU1JqQVZDMVdHcXM5TmdSc2FqT1RUbTRwbUt6WXhqQ21FYzFLUlVaNjByQU5wTzlMUlVqSHJV Z3FJR25nODFTRVBwd3BvcVJSVkNKb3VvcXl0VmtHS25VMW9oRWg2R3FFdjN6Vnd0VktVL09hbVkw VTIrOGFTbFlEY2FUNjFpOXhraWRxbFdvVXFWVFZJR1NVNGRhWUtjdFVoRXExWWpxQlJVNmNWYUVU TFRKLzlXLzBwd09CVWNyWmpiNlZZRk05UHdxa3g1cTcvQUlWVFljMWhNb0VxWktoWHJVcTBrREox cDQ2MUVwcVVWYUVLT3RTcDFwaWlwVkZXSW1UcFVvcUphZm5GV2dHVEQ1S3o3amhCelY2VWt4MVJ1 QmxCVVRCYkZQSE5TSjFwdTNGUFhyV0tRK2hZU3BSVUNtcGxOYUlRL3ZUZ09hYlVpaXJBZWdxWmV0 UnFLa1dxUU1kemlxMHYzNnNFMVdrNWVoN0NSN3pvbi9IakYvdWlxM2lmL2ozdC93RGZQOHF0YUdQ OUJpLzNSVlh4Ui94N1crZjc1L2xYS1djMXJQOEF5Sm1pZjloZGYvUnoxN25GOXdWNFhySC9BQ0pt aWY4QVlYWC9BTkhQWHVrUStVVWhrbEtLU2xvQTVqNGlmOGlIcVgvYkwvMGFsZUVWN3Y4QUVUL2tS TlMvN1pmK2pVcndpZ0FwTzFMUWFBR25wUlNta29BU2twYVNnQkRUYVh0U0dnQktTbDlhU2dCRFRU VHUxTlBTZ0JwNlVocFQwcERRQWxOcDFOb0FhYVEwcHBLQUc5cWJUcWJRQWxOTk9wcG9BYWFhYWNh YWFBR21tbW5HbW1nQkRUVFRqVFRRQTAwMDA0MDAwQUlhYWFjYWFhQUcwMDA2bW1nQnBwS1UwbEFE VFNHbE5JYUFHMGhwYVEwQU5OSlNta29BU21tblUwMEFJYVNsTkpRQWxKUzBsQUNVaHBhUTBBRkZG RkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFV VVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFIcW53Qy93Q1I3dmYrd2JK LzZOaXI2THI1MCtBWC9JOTN2L1lNay84QVJzVmZSZEFCUlJSUUJpK0x2K1JPMW4vcnlsLzlCTmNy ZGY4QUlKMGovc0d4L3dEb01WZFY0dS81RTNXZit2S1gvd0JCTmNwYy93RElLMGovQUxCMGYvb01W QUZDcm1rLzhoS0g4ZjVWVHE1cFgvSVNoSDEvbFZNUnpmeFkvd0NRSi9uKytsZU5SSERnVjdOOFZ4 blJSL24rTks4YlJQbUJORVFMOGYzbHE0dkFxbkhuY0t0QTEweDJKRmFvSHFZbW95S0FJQ0tiVWpD b3pVTUJyZEtoY2NWSXhxSitsU3hrRDljVkYzcVZoVE51YXpZMFQyMzNxMExmdldmYmpEMWZnYkdh MGdKbG85S2hlbjV5S1kxYWlJSDYxRVJVekNveldiQWo3VXcxSWVsUk1haGpJbnFCdXRUT2FpSXp6 VU1hRUhBcTVGOTFhcUJhdHhEQ2lxaU0wbytsRGRLWWpZVVU1anhXeVpCREpWZHFzTlVMQ3BZRVJw RDBwV0ZOWTRxQm9qYW9tNjFLMVFtb1l3cDBmM3hUUlRrUHo0b0dXUDRoVjlCeFdlUHZDcnluZ1Zy RWtWcXJ2VmhqVUQwMkJBd3pUYWUxTVBGUU1hMVIwOWpVZWFnQi9sTlNlUzlXbHFSUlZjdHd1VXZL WWV0RzFnZWxhT3lvM2o0cDh0aFhLdzRxVHpGQnFKajhwTlE3czgxTjdETGduVVU3N1N2clZEUE5P Rk5TQ3hjYTRIWTB6ZHZPYWhBcVVVN2dJME9RU0taNURlbFdWTlNLT2MwS053S2dnY2RxWHluSGFy NFhQYWxaTUNueUNLQ2c1UGFwVUlHYzA2WmR2U3E4amJRS05nc1dCTWc3MDRUcDYxbjdxVUdsekRz YVAyaGFqYWJjY0RwVllkYWVvNXA4d2lUMnBHdHpqaWw3MU9wbzNBcWZabUhHS2NMZHgycTRPdFNn WnBxQUdmNWJnOUtjbjNhdWxLcnlMdGJBcDh0aFhGUWdMelNpWlBXcWtyNGJiVVc2cDVobWlKMTlh ZDlvWDFyT0JxUURQRlZ6Qll0R2JjTVUwcnZxTlJpcDBPS0JFRFc3RTBuMmRzOUt1QTgxSW96VDVR dVVSQTRwMjFsNmlyMjJtc3VldUtmSUJYWGlwTjZyMXFKdUFUNlZXZVRQV3Bic012OEFuSUQxcGZ0 Q1o2MW1ocWV2clFwQll2dE9NY1ZIbmR6VUsxTXZTcUVlKzZIeFl4ZjdnL2xWWHhUeGIyLysrZjVW YjBUL0FJOFlmOXdmeXFwNHFIK2pXeC82YUgrVllGSE02eC95Sm1pZjloZGYvUnoxN3BGOXdWNFhx LzhBeUplaWY5aGRmL1J6MTduRjl3Vkl5V2lpakZBSE0vRVAva1JOUy83WmYralVyd2l2ZC9pSC93 QWlKcVgvQUd5LzlHcFhoRkFCU0dscEtBRW9vb29BU2twYVNnQnRJYVU5S0RRQTJrNzB0SlFBbE5Q U25VMDBBTlBTa05PTk5OQUNVMm5VMmdCdEpTbWtvQWJUYWRUYUFFcHBwMU5OQURUVFRUalRUUUEw MDAwNDAwMEFJYWFhY2FhYUFHbW1tbkdtbWdCRFRUVGpUVFFBMm1tblUwMEFOTkpTbWtvQWFhUTBw cERRQTJrTkxTR2dCcHBLVTBsQUNVMDA2bW1nQkRTVXBwS0FFcEtXa29BU2tOTFNHZ0Fvb29vQUtL S0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdB b29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQTlVK0FYL0k5M3Y4QTJEWlAvUnNW ZlJmNDE4NmZBTC9rZTczL0FMQnNuL28yS3ZvdWdBb05GQm9BeGZGMy9JbmF6LzE1Uy84QW9Kcmxi bi9rRmFSLzJEWS8vUVlxNnJ4ZC93QWlkclAvQUY1Uy93RG9KcmxMci9rRjZQOEE5ZzJQL3dCQmlv QW9WYzByL2tKUmZqL0txZFhOSy81Q1VYNC95cW1JNS80cEx2MGxWK3YvQUtFbGVSckRqa2l2WC9p Yi93QWc1UHgvOUNXdktHUEZhUVdnbVJmZE9hY3M0OWFhUmtWQ3d4VlhzSXNtZGZXazg5Y1ZTYW84 NHBPUUdqNWlzT3RNYnJWSlh4VnBDU0JTVHVNWXlNemNVbmt1ZTFYSTErWE5TYmNWWExjUm1tMmJQ U2dXekR0V2dhakpvNUxESy9sYkQwcGZNMlU5elVMMHRoRTYzQzQ2MEdkUFdxYlZHVFU4dzdGMHpK UnVWZ2NWbjc2a1I4SDYwY3c3RTU2VkhzY2pwVXlMbGdLc2hCVDVia21lYmR5T2xOK3p0NlZwa1lw alVjZzdsRmJjanJUOXUwWUZUc2VLaE5JTGlwUHRJVW1wRGNMVlZoVWJjQ2x6V0F1R2RDT3ROODFE M3FpVFFEUzVoMkxqa2RxaVlFc0tTTnQyUlZpRk4yYXJjQ3Q1VCtsSVlIUGF0SUxUV281QU03eUd6 MHA2eGJSbkZXV3FOdnVtbHkyQWo2VTlaL1UwekhGUk1QU2xjUmErMExqclRUT3ZhcWg0RkpSekRz V3ZNVTB4dnZWQjNxUlRsZWFTZHdzSVFTZUtQS2YwTldvaytYZFV1elBwVmN0d0s2bXJFZk5WMHF4 RlRRaWRSVFpGK1UwNWFTWDd2NTFiMkVac24zS2hxYVQ3dFExZzl5a0hlbnJVZmVwRnBEWklCelQ4 VWkwNnJFT1UxS2hxRVZLbFVoRmxCa1ZLRjRxS1BweFU0clVSU3V1aTFSblAzY1ZmdWh3S29Uamhh eW1ORU5QV21VOUt5R1RyVWdGUnBVb3JRUWQ2a0JwbmVuTDFwaUprcXduTlY0NnNKV2lBY1JWU2NZ ay9Dcm5hcWR4L3JQd3B5MkFvWEhFaCtsUmpyVWx6L3JEOUtpWHJYTzl5aVZldFRxS2dYclZoYXBD WklCVGgxcG9wd3Exc0lrVTFNdFFMVTZkcXBBVEFVMWh4U2loK2xhZEJXS012UjZvTWNWZmsrNjFa ei9lcm5tVWg2ODFQR0tnU3JDVWtNbVVWSU9PS1l0UDcxb2lUM3JRVG14aUgrd0tyK0t2K1BXMi82 NkgrVlRhQi93QWVjWCs2S2k4VmY4ZWx0LzEwUDhxeEtPWTFmL2tTOUUvN0M2LytqbnIzT0w3b3J3 dlYvd0RrUzlFLzdDNi8ram5yM1NMN29xUmtuMHBhQlJRQnpQeEQvd0NSRTFML0FMWmYralVyd2l2 ZC9pSC9BTWlKcVgwaS93RFJxVjRSUUFVaHBhVHRRQWRxU2xQU2tvQVNrcGFTZ0JwNlVHZzlLUTBB SlNkNldrNzBBSlRUVGpUVDBvQWFlbElhVTlLUTlLQUVwdE9OTm9BYWUxSWZhbHBLQUcwMm5VMmdC RFRUVHFhYUFHbW1tbkdtbWdCcHBwcHhwcG9BUTAwMDQwMDBBTk5OTk9OTk5BQ0dtbW5HbW1nQnRO Tk9wcG9BYWFTbE5KUUEwMGhwVFNHZ0J0SWFXa05BRFRTVXBwS0FFcHBwMU5OQUNHa3BUU1VBSlNV dEpRQWxJYVdrTkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZG RkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUI2 cDhBditSN3ZmOEFzR3lmK2pZcStpL3hyNTArQVgvSTkzdi9BR0RaUC9Sc1ZmUlZBQzBsTFJRQmkr THYrUk8xbi9yeWwvOEFRYTVPNi81QmVqLzlnNlAvQU5CaXJyUEYzL0ltNnovMTVTLytnMXlkMy95 RE5HLzdCc2YvQUtERlFCUnE1cFgvQUNFb3Z4L2xWUE5YTksvNUNVWDQvd0FxcGlNSDRtLzhneFB4 L3dEUWtyeVpqWHJQeE4vNUJpZmovd0NoSlhreDYxZFBZVEc0NHBoR09LZjJwamRLc1JCSjdWWFkx WWs2VldiTlpzb1FNUlYyRDdocWdQdlZvUS9jb2dEMkwwZjNhZVJ4VElSbGFlZWxkQ0lJV3FKalVy MUMzV29ZeGhwakRpblVoRlNCRXdxdS9yVmg2Z2VvWTBRbk5PalB6RDYwMDA2TDczNDFCUnBRakVn cTRCVktJL3ZCVjRkSzZJN0VER0ZRT2FuYXF6ME1DSmpUZTFLMU43VkFEV0ZSTUttYW9XcUJvaFBV MGxLM1drcVNpYUU5YXZXdUNHK3RVWU85WHJYb2ZyV2xORXNza0RIU29YNHFjOFZCSjByUmlLN0dv eWFlMVJtczJNVDZVdzAvdFRXcVdNaGFrcFc2MGxRTUtrVDd0UjFJbjNhYUF2VzR6R0tsSXFLMkh5 ajYxTVJ6VzhTV1VWRldJcWhGU3FRS2xETEFwSkdHdzB6ek1DbzNrRzNtbTNvS3hVa0h5bW9hc01N cVJWY2dpc21ob1R2VWkwekZPQU5KREpnYWRtb1FhbFdxRVBBcVpCVEZHRnFSU00xUzNFV0U5alVt Y1ZBckFkNlV2NlZwZXdyRWQxMFdxTngycTNLNGJ2bkZWcEZ5QldjdFJvcTFJdEJYMEZLRklQU3M3 RkV5MUlLaEdjMUlwNUFxMEpqNmV2Rk5xVlJWSkVqMHF3blNvRnArNEExb2dKalZTZm1UOEtuWjZy U01DMlIwcFNZRks0SDcwbjJxSWRhc3lvUzJjY1ZEczU2VmkwVXRoeVZZV29GRlNLY1UwREp4VGgx cU5UbXBWR1RWb2tlbzVxWktqVVlwNm1yUUV5MEU4VXdOanZUV2Z0VFRFVnB1VmJGWjVVNXJRYmtH cXpSa2RxeWtpaUpldFR4MUdGUHBVaTVwSkFUcWFlRHpVS2tpcEY1cTBJOTgwQWY2REgvdWlvUEZY L0hyYmY4QVhRL3lxZlFQK1BHTC9kRlFlS3YrUFcyLzY2SCtWWWxITWF2L0FNaVhvbi9ZWEgvbzU2 OTBpKzZLOEwxYi9rU3RFLzdDNC84QVJ6MTdwRjkwVkl5VWRLS1Nsb0E1ajRoLzhpSnFmMGkvOUdw WGhOZTcvRVAvQUpFVFV2OEF0bC82TlN2Q0tBQ2lpa29BS1NsTkpRQWxKUzBsQURhUTBwNlVob0FT azcwdEpRQW5hbW1uVTAwQU5QU2tOT05OTkFDVTJuVTJnQnBwS1UwbEFEYWJUdWNVMmdCS2FhZFRU UUEwMDAwNDAwMEFOTk5OT05OTkFDR21tbkdtbWdCcHBwcHhwcG9BUTAwMDQwMDBBTnBwcDFOTkFE VFNVcHBLQUdta05LYVEwQU5wRFMwaG9BYWFTbE5KUUFsTk5PcHBvQVEwbEthU2dCS1NscEtBRXBE UzBob0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29vb0FLS0tL QUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29vb0FLS0tLQVBWUGdGL3lQ ZDcvQU5nMlQvMGJGWDBYWHpwOEF2OEFrZTczL3NHeWYrallxK2lxQUNsb3pTVUFZM2k3L2tUdFov NjhwZjhBMEUxeVY1L3lETkcvN0J5ZitneFYxdmk3L2tUdFovNjhwZjhBMEUxeU41L3lEZEYvN0J5 ZitneFVBVWF2YVYveUVZdngvbFZISXE3cEovNG1VWDQveXFtSXd2aWIvd0FneFB4LzlDU3ZKalhy UHhNSC9FdFQ4ZjhBMEpLOG9ZY2NWcFQyRTl5T28ycDU2VkN4OUtwZ01mcFZkaFU3WnFNcm5wV2Rn SVFEbXIwR2ZMTlFMR2NkS3NvdTFhY1ZZQzlHZmxHS2MxUVJ1TVlxUXNDSzF1S3d4K3RSTUtsSkJG TUlCNXBNQ0UweHFsY1lGUXVjVklFYkdvWHFWdldvbUZReG9oT2FkR3AzRDYwdXptcFVRN3VCVXBE TGtQRW5OWE04VlFRN1d6VmxYRmJSRTBTTlZkK3BxVXNEVWJVMklnYW0xS1JVUjcxRDBBWXhxSnFj VFREeUtobElpYnJTVTdIdFNiZWFtd3lXRHZWNjFZS0d6NjFUaUczTldJbUM1clNMc0psMG5pb1pL QTRwckVHcnVtS3hDd3FJMU9RS2pjWXpVTUNQdFRXcDNhb21OUXhqRzYwbEtSU2ZXa0FWSW4zYWp4 bXBWWEFvUXk3Ym5FWXFhcWtiZ0ppcGcvRmJKazJNOHlONjBlWXc3MHlpc2JsRW5tTWU1b0JKTk5V VThDbmNDUmV0U2JGYnFLaUZTS2Fva2VzQytsTyt6cWUxT2pOVGdWYVFGUnJjRGpGUmJTcHJRSzVx bEtNT2NVcEt3RVR5OXFaNXpEdlViZmVOSU9LeXVNbUVyK3RPOHhqM05STFVxaXFUQWNuWHZVeVZH QmluS2FwQ0pSRWhwd2dUMHBxbXAwRlVrSVo1QzRxSjRkcHlCeFYwQ281bHdoSXB0QVUrMU1lZHUx UFA5S3BzOVp0MktKeE8zclRoSythcktlYWxYclNUQWwzc2U5U0owOXFqVVZLdFVoRWlnRmNIb2Fj SVVOUnJVcW1yc0FvaFQwcGZKWDBxVkJUOGNWWEtKc3B0RUY1cHBmWU0xWmxHRXFoY3RoUjlhbVdn Q200YjFwUFBZOTZyWnpUMXJPNHl3Sm45YWNHWnV0UnFLbVVZcTB3SHIycVhhRDJxSVU5VFZDSGlK UFNsOGxNOUtjdFNDcVNBaE1JcUlydEpGWFN0VnBSaDZHdEJJOTIwRC9qeGkvM1JVSGl2L2oxdHYr dWgvbFUrZ2Y4QUhqSC9BTG9xRHhYeGEyMlArZWgvbFhNV2N4cTMvSWw2Si8yRngvNlBldmRJdnVD dkM5Vy81RXJSUCt3dVAvUjcxN25GOXdWSXlYbWlpaWdEbWZpSC93QWlKcVgvQUd5LzlHcFhoTmU3 ZkVQL0FKRVRVdjhBdGwvNk5TdkNhQUNrTkxTR2dCTzFKU25wUjJvQVNrcGFiUUFoNlVocFQwcEtB RXBLV2tvQWFlbEllbEwycERRQWhwcHB4cHBvQVNtMDZtMEFOTklhV2tOQURhYlRxYlFBaHBwcDFO TkFEVFRUVGpUVFFBMDAwMDQwMDBBSWFhYWNhYWFBR21tbW5HbW1nQkRUVFRqVFRRQTJtbW5VMDBB Tk5KU21rb0FhYVEwcHBEUUEya05MU0dnQnBwS1UwbEFDVTAwNm1tZ0JEU1VwcEtBRXBLV2tvQVNr TkxTR2dBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29v b0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29vb0E5VStBWC9J OTN2L1lOay84QVJzVmZSZkZmT253Qy93Q1I3dmYrd2JKLzZOaXI2TG9BTVVtS0tYclFCaStMditS TzFuL3J5bC85Qk5jamUvOEFJTjBYL3NISi93Q2d4VjEzaTcva1R0Wi82OHBmL1FhNUMrLzVCdWlm OWc5UC9RWXFBS0ZYdEkvNUNVWDQvd0FxbzFlMGova0p4ZmovQUNOVXhHRDhVbTI2U3Avejk5Szhp V1lrNEo2MTZ6OFZ1TkVIK2Y0MHJ4eEcrWVZVSFlHWGdNbkZQU0ZSMUZKSHl5MVp4V3FSUFVoOGxP NHBwaVFkcXNIcFVUMVZnSTlpZzVGTWJyVG1OTU5TQkVTVmZJT0tiNXJqaW5zS2ljVkZ4aUdkd2V0 SjU3WjYxRTFSL25VM0dYMWszOFpweXg3K3g0cXRibkwxZnQxNjFjZFJBSUZJNUZKNUNlbFdkdUtq ZjJxckNLNWhRZHFSbFZSeFQyTlJzYWtDTnVsUjdtWHZVaHFOcWxzWTB6T0IxTk44OXZXa1lWQ2Fp NHl5azVIVTFKbmNNMVNCd0t0eEhLS2FwTzRXSmtnR2NucFQvSVgwcWRFTzBVcEF4V2xoRlV3SlRm TFZlMVRQVURFMUxRRFh4NlZFL2FwQ2FZM0lxUVF3eU9QV21lYTNUTk9hb21xV3loL212NjA5WkMz RlFVNlA3NHBKZ1Q0N1ZJa0FIVWNVd0Q1aFYxVjZWb2xja2c4bGZTbW1KTWRLdE1LZ2M5YWJRRU93 TFRHKzlUMk5NeFVzWkd4eHlPdElIYjFwekNveU9hbGpFcE85TFJVZ1BXbmdlbE1XcEJWSVRGRk9Y clRhZXRVaEU4WGFySzFXaTZpcksxb2hEbSs3V2ZNZm5OWHowNHFoS1BuTktZMFUyNm1rcFcrOGFT c0h1TWVncWRhaFRwVXExU0FmU2lrQnB5MVMzRVNKMXhWbEtyTDFxeEhWb1JPdUtqbis0MzBxUmFq bis0MzBxK2dGSEZVbTYxZDdWUmJyV0VpaHlWTW5Xb1VxWmV0SkFUTFR4MXBpMC92V2lKRkhXcFVx SWRhbFNxQXNKMHFVVkVuU3BSV2lFeUdiN2xaOXdQbEdhMEp4aEt6N2o3Z3JPWXluM3FaRHpVTlNv TUdzVVVXVUZTZ1ZFbFNpdFVTeHc2MDVldE43MDRkYW9DVkttV29rcVZhdEFQNHhWV1g3OVdUeFZh WDc0cE1SN3Q0Zi93Q1BHUDhBM1JVSGl6L2oxdGYrdWgvbFUvaC8vanhqL3dCMFZCNHQvd0NQUzIv NjZIK1ZjeFp6R3EvOGlUb24vWVhIL285Njl6aSs0SzhNMVgva1NkRC9BT3d1UC9SNzE3cEY5d1ZJ eVNpaWlnRG1maUgvQU1pSnFYMGkvd0RScVY0VFh1M3hELzVFVFV2KzJYL28xSzhKb0FLVHRTNHBE UUFHa29QU2tvQUtTbHBLQUducFNHbHBLQUVwS1drb0FUdFRUVHFhYUFFTk5OS2VsSWFBRzlxU25I cFRhQUdta05LYVNnQnROcDFOb0FTbW1uVTAwQU5OTk5PTk5OQURUVFRUalRUUUFocHBweHBwb0Fh YWFhY2FhYUFFTk5OT05OTkFEYWFhZFRUUUEwMGxLYVNnQnBwRFNta05BRGFRMHRJYUFHbWtwVFNV QUpUVFRxYWFBRU5KU21rb0FTa3BhU2dCS1EwdElhQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29v QUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lp aWdBb29vb0FLS0tLQUNpaWlnRDFYNEJmOEFJOTN2L1lNay93RFJzVmZST0srZGZnRi95UGQ5L3dC ZzJULzBiRlgwVm1nQXBhUVVkS0FNYnhkL3lKMnMvd0RYbEwvNkRYSDZoL3lEOUQvN0I2ZitnUlYy SGk3L0FKRTdXZjhBcnlsLzlCcmp0Ui81QitoZjlnOWYvUUlxQUtPY2NWZDBjNTFTTDhmNUdxUFNy MmovQVBJVWkvSCtWVTloSFA4QXhYLzVBWS9IL3dCRFN2R29oOHdyMkg0c1NLTkpSQ2NNd09CL3dO SzhlaVB6Q2lJV05LUDd5MWJISXpWT1A3d3E0dkF4WFRIWWxpR29IcWRxZ2Z2UXdJalRlMU9OTnFH QTFxaGVwbXFGNmtaWGVvajFxVjZoNzFtTkZxMis5V2hiOTZ6N2I3MWFGdjNyU0FtV1R4VUwxS2Fp ZnBXckVRTjFxSTFLL1dvaldiQWJUV3AvYW8ycVdNaGVvVzYxTTlRc09helkwSUt1UmZkRlV4NzFj aSs2S3FJTTBZK2xLMUpIMEZLMWJyWWtydjBxQnFuazRxQnF6WUREU2RxRFFlbFNORVRkYWlhcFdx SnFoakVwMGYzeFRhZEg5OFVoc3NmeEN0Q1BwV2YvQUJDcjZkSzNnU0kzZXF6L0FFcXkxVjNvWUVE VWxLMUoyck1ZMXVsUm5yVWpWSFNBYUtLZjVKUGFsOGh2U2xZWTFlbFBCbzhsaDJwTnBCcHBDWktL ZW9wZzR3VFQvTVZhb1JNbkZUS2FxQ2RhZDlvV3FVZ3NXaTJPbFU1U1M3R2xhZlBRMHpKYm1sSjNB cXNPVHhTZDZzdERrWkE2MHp5R05SeWpHTFVpbWxFRCtsTDVMK2xPd0RsNXFSZWxSSXBGU29RT3RV a0lrVWMxWVQ2MVY4NVJUMXVGcWtGaTNtbzVXSmphb1RjRDhLamFiZHdPbFBtQWJWTmw1TlhCU05C L2RxR3JnaW9veFVxbW4vWnoycHdnWWRxbXd3VnVha0hXbUNGeDJwNkRIV3FRaVJSbXBFOTZqVmdC enhUaE1vTldyQVdWcVRJcW9MaGFYN1FLcm1RckVrcHlsVWJnWlVacVpwZHhJN1VtemZVUzFBb0Zj R25wVmcyeG8rek42VkNpTzQxVFVxbWtGdTlMc2RUMHEwbUlreHpUMUZNWGpyVW5tS3ZlcVFFcWpG U0NxM25ybnJUaGNMVkpnV0MxVjVUbGhTTk9PMU0zRnVhRzdoWTk3OFBEL1FZdjkwVkI0dUgraTIz L0FGMFA4cXMrSDEyMlVZNzdSVmJ4Zi94NjJ2OEExMFA4cTVpamw5Vi81RW5RL3dEc0xqLzBlOWU2 UmZjRmVGNnIvd0FpVG9mL0FHRjEvd0RSNzE3bkY5MFZJeVdpaWlnRG1maUgvd0FpTHFYL0FHeS85 R3BYaFdLOTM4ZmpQZ2ZVaC8xeS93RFJxVjRkNWRCU1Z5REJveFZqeS9Ta01kSzQrVXJrVW1PS3Nt T2s4dWk0Y3BXd2FNR3AvTG84dWk0Y3BXSXBDRFZqWlNGS0xpNVN2ZzBtRFU1U21GYWR3NVNIRk5O VEZhWVJTRllqTk5OUElwcDZVeERPMUpUalRhQUdta3BUU1VBTnB0T3B0QURUMHBEVHFhYUFHbW1t blUwMEFOTk5weHBwb0FRMDAwNDAwMEFOTk5OT05OTkFDR21tbkdtbWdCdE5OT3Bwb0FhYVNsTkpR QTAwaHBUU0dnQnRJYVdrTkFEVFNZcVRHYUF0SzRFV0tUYWFuQ1U0UjB1WWRpcnROSnROWEJGU2lL bHpqc1V0aHBOalZmRUZIa2UxTDJnY3BuN0dvS042VmY4QUlvTUh0UzlvSEtaK3crbEd3K2xhSGtl eG84ajJOSHRFSEtaK3crbEd3K2xhSGtleG84ajJvOW9IS1oreHFOamVsYUhrVWhocCswRGxNL2Fh TnBxK1lhWVlxT2NPVXA3VFJnMVpNZUthVXF1WVZpREZKVXBXbWxhZHdzTW9wU0tTbUlLS0tLQUNp aWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9wY1Vv Rk93SHFYd0QvNUhxOS83QnNuL28yS3ZvcXZuYjRCakhqbTkvN0Jzbi9vMkt2b21rQVVVVVVBWTNp Ny9rVHRaLzY4cGY4QTBFMXh1cEgvQUVEUWYrd2V2L29FVmRsNHUvNUU3V2YrdktYL0FOQk5jWHFm L0hqb0gvWGd2L29FVkFGS3J1a2NhbkYvd0wrVlVxdWFWL3lFNHY4QWdYOHFwN0NPSStMVjBKTHVH MlZ4dWpVWlgvZXlmL1pSK2RlYkluekN1eDhmTTkxNG1ueU9GYzdUN2NML0FPeS9yWE5MQmc4MVVZ NkFQUTRZVmF6NzFVenRPYWNrL0hOYlJkaVN5VHhVVFV6N1F0SVoxOWFHRmdhb3pUL01ROFpwaCs5 VXNaR3h4VVRtcFdRczNGSVlHSXFXbUlxTU0wMExWcjdPM3BRYllqRlR5akk3Y0FQbXRDQnUxVnhF RXBSTHNOWEhRQzdtbXQwcUQ3UUJTZmFGcStZVmhXRlJrWkZLWmw5YU53WWNHb2JHUkhwaW8ycVJo bnBUQkV6ZHFtd0VMVkVSelZvMjdlbE4rek42VlBLTXJiZUt0eERDQ2hZQ0R5S2RqYmtVMGdMcU44 b3B6R3FTelk0UFFVLzdRSzBURlprcmpJcUJoU21kVFRQTlVuRlMyRmhqVTFxa1lqdFVUQWtpcFlK RWJWRWVhc2VTeDdVMHdONlZOaWlFVTVPSEZTQzNhbkxGdDVQV2l3RGdmbTRxNnI4RE5VYWVrM3Iy cTA3RWx3bW9IRk1OeUtRenFhYllXR3RVWnFUekZQY1V4dXRRTVlUVE0wNHFTZUtQSmIwcEFXQWVh bVVWWFhyVmlQbXJRaCt3WXFONC9sNXF3b3BKUUFwK2xWWURPWTRXb09hbWs0V29heVkwRk9XbTA5 YVNHT0M4OUtsSFRGTkFwMk9hcENaSXRUTHlhcnFhbVNxUWljQ2xhUGpJNHBVNUZTQVpGYUN1VXAx QzR4eFZXVTRIV3J0MTBHS296OXF6bVVSWnB3NXFPbnJXYVl5VlJVaWptbXJVaWlyUkxGcVpUVVhl bnJWSVJPcHFRRE5RcFZoS3RBeHJKVmVSUUhIYXJtS3FYSCtzL0NoZ1ZKV3crTzFRN3VhZGNjU242 VkVPdFlObEV3NjVxUWMxRWxUcUtwQ0hvT2VsVExnSGlvMXA0NjFhRVNnMUt0UUtlYW1TckFmdHBw VHJVZ0ZCR0IwcXJDS0xjQW1xclBWdWJvMVp4T0RXRWlrU0syVFVnNjFDdFR4MElaSUZxVlJnVTFS VHh4V2lFZlFPZ3Ivb01SN2xSVlB4Zi94NjJ2OEExMFA4cXU2Ri93QWVFUDhBdUQrVlVmRi8vSHBh L3dEWFEveXJBWnkrcS84QUlrNkgvd0JoY2Y4QW85Njl6aSs0SzhNMVgva1NkRC83QzYvK2ozcjNP TDdncVJrbEtLU2xvQTUzeDRNK0N0UkgvWFAvQU5HcFhpdmwxN2Q0MFhmNFJ2MS82NS8rakZyeUlX M3RXYzNablJTaHpSTS95NlF4MXBmWnFRMjFUekkxOWtadmwwbXl0UDdMN1VmWnZham1EMlJsN0tU eXpXcDlsOXFQc250UnpEOWl6S01mdFRTbGEvMlQycGpXbnRTNXc5aXpJS1ZHVXJXYTE5cWlhMjlx YWtRNlRNcGxxTmx4MnJTZTNxRjRLcFNNM0JtZVJUR0ZYR2hxRjQ4VlZ5SEVxbnBTVk1Vd0tZVnBr V0lxU25rVXcweERhYjNwMU5vQVEwdzArbUdnQkRUVFRqVFRRQTAwMDA0MDAwQUlhYWFjYWFhQUdt bW1uR21tZ0JEVFRUalRUUUEybW1uVTAwQU5OSlNta29BYWFRMC9iUnRwQVIwaEZUaU9wQkRudFNj aDJLd0ZPVmF1TGJWT2xwbnRXVXFpUlNpWjZwVWdqOXEwMHN2YXJDV0dlMVl5cm9wUU1rUkgwcDRp OXEyMDAvMnFWZE4vMmF4ZUlSYXBtRXNIdFR2STlxMzEwMy9acVFhYi9zMW04U2l2WnM1c1cvdFI5 bjlxNlVhYi9zMHY5bWY3TlQ5WlEvWm5NK1I3VWZaL2F1bS9zei9acGY3TC93Qm1sOVpRZXpaelAy ZjJwUHMvdFhVRFMvOEFacHcwbi9abyt0SWZzbWNxYmYycHB0L2F1dE9rL3dDelREcFArelFzVWc5 a3prekI3VkUwUHRYV3RwWEgzYXJTYVhqK0d0STRsRXVtemxXaTlxaWFPdWxrMDdIOE5WSkxESGF0 NDEwUTZaZ010UkZjVnRTV2VPMVZYdGNkcTNqVlJtNG1ZUlRhdk5CaW9HaXhXcWtpYkZlaXBTbUtZ UmlxdUliUlJpaW1BVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRk9Bb0Fi UzA0TFQxanFsRVZ5T25BVk1zVlNyRG1yVk5rT2FQU2ZnS0NQSEY3LzJEWlA4QTBiRlgwTitkZUFm QXlMWjQwdkQvQU5RNS93RDBaSFh2OVRPTm1WQjNRVVVmalJVRkdONHUvd0NSTzFuL0FLOHBmL1FU WEZhcHhaZUgvd0Ryd1gvMENPdTE4WGY4aWRyUC9YbEwvd0NnbXVKMWIvano4UGY5ZUMvK2k0NkFL V1Q3VkhOcXE2TW4yOTRtbFdQK0JlQ2M4VS9OV3RPUlpOUWpWbERLUTNCSEhTcVlqeXZYTC84QXRE VXBMblk4ZThzZGo5Vnl4UFA1MWxNMWJQaWxRbmlDN3h3TjdjZmlSL1NzUTF1dGlSaDVxSmhVMU1Z WXBBVjI5S2lKeFV6MVdhb2JLSHErS3R4dHVTczhIdFY2QVlqb2d4TXVSb050UDI0RkxIamFPS2Nh MlNKSWlLakp4VWoxQXhxV01heHFKaG1wRFRUVU1aQXd3S2lQU3AycUJ6aXBZRGQyS2VqbmR4VUI1 cHlaM0Q2MU45Um1naWdzS3NoY0hwVUVQRWxYTWNWdEhZa2pJeFVUR3BtRlFQVFlER2FvalRtcHRR QkV3RlJzTUNwbUZSTUtobEVST0tBMUlldEoycVJrOFJMWnF6Q21jOFZWZy9pcS9iRElQMXJTQW1T Yk1DbU53S25JcUZ4Z1ZvMFNSRTFFeDROT1kxR1RXYkdONXFNakZTZHFZYWtaRWFTbk5UYWdZZDZs VTVYbnJVVlNKOTJtZ1paalRLNXhVd1Rpa3QrWXhVMlBhdGtpU2l2V3JFVlFLS25qNHBJQ3d0Tm0r NytGQTRwc2hHMDFYUVJueWZkTlExTTQrU29hd1pTRTcxSXRSOTZrVTBoa3dwYVl0T0hXckVQRlNw VWExS25XcVFpekgwcVZhaFUxSmtBVm90aEZhNjdWUW42Q3I5eWVGcWhPT0ZyT1pSRFQwNlV5bnBX WXlkS2xGUkxVZ3FpV0wzcHk5YWIzcVJhdENKWTZzSlVDQ3BsTmFJQ1R0Vk80L3dCWitGVzg0RlZM am1UOEtKQVVibi9XRWUxUXIxcVdjWmtQMHFJREJyblpSS25CcXd0VjA2MU9wcWtKa29wd3BnelR3 S3RDSHIxcWRLZ1dwMHEwQktLVitsTkZESGlxNkNLVXZScXpuKzlXakx5clZua1ZoTW9jbFdJeFZk ZXRUcFFnTEMwNm8xcVFHckVmUVdoZjhlRVArNFA1VlI4WWY4ZWxyLzEwUDhxdmFGL3g0US83Zy9s Vkh4ai9BTWVsci8xMFA4cXhLT1cxWC9rU2RELzdDNC85SHZYdWtYM1I5SzhMMVQva1NORC9BT3d1 UC9SNzE3cEY5d1ZJeVNscEtXZ0RHOFZydjhNM2krb1Qvd0JEV3ZOQmIrMWVuZUpqdDhPM1pQOEFz ZjhBb2ExNTM1cTk4VnpWbjd4NmVDaW5CMzdsYjdON1VuMmJzQlZ2emw5cVBOV3NiczdPU0pVK3pV djJiMnEwSlZwd2xXbGRqVUlsVDdMN1VvdGZhcm9rV25obE5MbVphcHhLSDJUMnFON1QycldETDZV eDhHbHpzcjJVVEdhMTlxcnZiZTFiYklPMVY1SS9hcVV6TjBVWVVsdngwcXJKQmp0VzVKRDdWVWtn clJTT2VkSXhYaXhWYVNQRmJFbHY3VlZrdHpXaWtjMHFSa3NsUU91SzBwTGZGVlpJU00xb3BHRXFi S1JGUmtWWWFLb21URlVZdUpDYWJUeXVLWVJpcUlFTk5OT3Bwb0FhYWFhY2FhYUFHbW1tbkdtbWdC RFRUVGpUVFFBMDAybkdtbWdCRFRUVGpUVFFBMm1tblVZb0FZYVFVL1lhVlk4MHJnTkFwd1dwbGdK cWRMUW1zcFRTS1NJbzRxc3BEbXJFTm1mU3RDS3dKN1Z5MUt5UnBHSlNpdHMxY2l0TTlxdncyQkhh cjhObmp0WEZVeEJ0R21aOFZsN1ZjaXNNOXEwb3JYQTZWYmppQzQ0cmhuaUdiS21aMFduKzFUcnAz dFdySHRIYXBsa1FkaFhOS3ZJMVVFWlM2ZDdWS05OLzJhMUZuUWRoVHhkUitnckoxWmw4aU1rYWIy MjA0YWJuK0d0VVhjZm9LY0x5UDBGVDdXWStTSmxEVFA4QVpwdzB6L1pyVkYzSDZDcEJkUitncVhW bVBraVpLNlhuK0dwVjByL1pyWWp1WXoyRldJNTR6L0NLemRlWlNoRXdqcFArelViYVQvczExSG1J UjkwVTBsRDJGUjlZbVY3TkhLUHBYSDNhb3phWmorR3UxWkVLL2RGVVo0Vk9mbHJXbmlaRU9ramg1 dE94L0RXZk5ZWTdWMjg5cUQyck1uc3V2RmQxUEVzeGxTT0ttczhkcXo1YlhIYXV5bnNNOXF6SjlP UFBGZDlQRW5QS2tjbExiNDdWU2xpeFhUejJCSGFzMmV4UHBYZlRySm1Fb0dFNllxQmxyV2x0Q0tw eVFFVjF3cUptVFJSSXBLbWFJaW95bUszVEpzTW9wU01VbE1RVVVVVUFGRkZGQUJSUlJRQVVVVVVB RkZGRkFCUlJUZ0tBRTcwOVJtZ0ptcDBpcTR4WkxZMVZ6VXlSMUpIQWF0UjJ4cnBoU2JNSlZDRklx c0pEVmlPMnF6SGJWMTA2QnpUcW5kL0JhTFo0dXV6ei93QWVELzhBb3lPdmM2OFkrRU1ZVHhWZGY5 ZVQvd0RvYVY3UFhGaTQ4dFN4MTRkM2hjS0tLSzVUY3h2RjMvSW5hei8xNVMvK2dtdUgxZml6OE8v OWVDLytpNDY3ZnhkL3lKdXMvd0RYbEwvNkNhNGZXUDhBajA4T2Y5ZUEvd0RSY2RBRk9ybWxmOGhT TDZOL0kxUnE3cFAvQUNGSXZvMzhxcGlQTVBGbkhpQzYvd0I5di9RbXJDSnJmOFdEL2lvTHIvZmIv d0JDYXNJaXQxc2llb3ltUFQrMVJ0U0FoZnBWWnV0V1hxdXdyS1EwUmpyV2hEOXlxSVhtcnNBeEhW UkdYNFI4dFBQU214dDhncHg2VnNpU0Y2aGFwM0ZRc0trQ0trTk9OTWFwWURHcXRJS3NNYWdmcFdi R2lFMDZQN3crdElSVG8xSVlWUFVab3hmNndWZEhTcVVKQWs1cTJHcm9oc1NJM1NxejFZYmpOUU5R d0lHcHZhcEdwbFF4aldxRnVsU3NhaGVvQkVUZGFTbGJxYVFWQlJMQjFOWDdYK0w2MVJnNzFldFd3 R3JXQkxMUnFCK25lcFNjMUMzU3RHSXJ2VVpxVmhVUkZac1luYW10VHNVeHFrWkcxTnBUU1ZBQlVp ZmRxT3BFKzdUUTJYcmI3cS9XcDZndDJBakZUWnJaYkVzcGdpcEE0SGVxRzVpYU56Vm5jZGpSRW94 MXFONXVNVlRER2xHYzBjd05FcEdRYWhLRVZPcHFVQlNlbEZyZ2lsdE5PQ24wcThzWVBhbmlKU2VC VDVBS0F6VWdxeThJTlFGZHJZelJZQ1JlQnpUd3dxbTBwd1Y3VXplZldqbXNGalREcU80cFRJTWRh ekE3RTlhZUdZMCtZVml6Skp2NmRLaGROd3BFRlRSOFp6UnVCVThyMm9Da0hvYTBBcW1uaU5QU2hR QzVRR2FrWE9SVjN5VngwcUo0Z3VXRlBrc0Z5TWRhbUF3T2FnUFhJcUpwbUlwWHNCZkRLTzlQRWdI ZXNyelc5YWVIYnVhZk1GalNhWVk2MVhadDdacXZrbXBFSHkwNzNBWkpGazdoVVhsSFBTcnlmZHhU MVJmU2x5M0M1UUNFZHFlQTFhQWpYMHBmS1VkcWZJQlRRMUt2V25ORUZ5YWhkeWd6UnNCWkJBcHdZ Vm5OTWZXanpHUFVtaFNDeHFlWUJUR2xBRlVBN0h2VHdTYWZOY1JLZm1GUVBDUjBGV0ZxVVlQVVVX dUJRRWJEc2FlcW5waXI0VmM5S1h5eG5wVDVBS1FCRlNMVmxvbElxRXJ0YW5hd0gwRG9RLzRsOFA4 QXVEK1ZVZkdIL0hwYS93RFhRL3lxL29JenA4UCs0S29lTVJpMHRmOEFybzM4cTVpamx0Vi81RW5R L3dEc0xqLzBlOWU2UmZkRmVGNm9QK0tJMFA4QTdDNC85SHZYdWNYM1FLUXlXbHBLS0FNWHhjZHZo YTlQL1hQL0FORFd2TFRjWTcxNmQ0MmJiNFF2ei8xei93RFJpMTQ2MHhyR3BHN096RHo1WW1wOW85 LzFwUHRIdldYNXhvODQ0cU9VMzlxYXd1UGVwRm45Nnhsbk5USk5VOGhVYXByck5VNlMxanBONzFh amw5Nmh4TjRWRFVSODAvTlVZNVI2MVlWd2U5WnRIVkdWeVhHYWF5VTlTRFVtQWFnMVN1VW1pelVM d1ZwR01HbW1JWXA4d3ZabU85djdWV2UycmNhRVZDMElxbE15ZEU1NlcyeDJxakxBZWE2T2VBZHF6 WjRPdGF4bWN0U2lZTWtXS3FTUjRyWW1oeFZHV1BHYTJqSTRwMDdHWTZrVkVSVnFWTVZYS2tWcW1j aldwRVJURFVqQ296Vkltd2hwcHAxTk5BaHBwcHB4cHBvQVEwMDA0MDJnQnBwdE9OTk5BQ0dtMDQw bUtBRzA0Q2pGUFJDYWxzQVZNMU5GRmswNUlpZTFYTGUzWW5wV0U1MkxTRmh0ODQ0cS9EYVo3VlBi V3BPT0sxN2F6emppdk9xMTdHOElGUzNzYzQ0clV0OVB6ajVhMExXekhIRmJGdFpweFhsVnNUWTZv VWpHVFQ4ZHFuU3l4MnJmTnFncHBoakhldUo0aHMzOW1ZLzJiYXZTbzJUYld0SXNZWHJXYmNPZ3p6 VGhKeUUxWXJNKzJvV3VNZDZqdUoxWCtLczZhNUhyWFZDbmN6Y2krMTNqdlVSdnZlc1dhN3gzcW05 NmZXdWlPR3VaKzBPbE9vZjdWTi90SC9hcmwydlQ2MHo3Y2M5YTArcWk5cWRldW9mN1ZUTHFIKzFY SHBmSDFxZEw0OGMxbkxDalZRN1NHK3ozcS9EZWU5Y1hiM3Z2V25iM3ZUbXVTcGh6V05RNjVMbkk2 MVpTWFBldWNndXdmNHExTGU0VTQrYXVHZEt4dkdWeldVNUZOYVBOTmhrVWpyVmxkaDcxeXU2TlZx VW10czlxclMyZWUxYnF4cWFVMjZHaFZyQnlIS3lXR2Y0YXBUNmJ4OTJ1ek5xaHF2TlpKdHJhR0th SWRJOC91ZE94bmlzaTUwL0dlSzlBdWJKZWF4cnF5SFBGZWpSeFJ6enBIQlhObmpQRlpOeGJZSjRy dHJ5enhuaXNDOHRTTThWNjlDdmM1SjA3SEx2RlZaMHhXeE5ic004VlFtaUk3VjZsT2R6bmFNNWh6 VGNWTTZuTlJsYTZFek93eWlsSXhTVlFnb29vb0FLS0tLQUNpaWlnQW9vcGFBRkFxVlZwaURtck1j Wk5hUVZ5Sk1FanpWMkdITk1paU9SeFduYndWMjBhVjJjdFNvSkRiWjdWZGp0ZmFyTnZiOUt2cGJp dldwWWZRNEoxaWhIYSsxV0Z0c0RwVjlJRnFieWxDMTJRdzZSelNxczZYNFZ4N1BFMXljZjh1YmYr aHBYcnRlVi9EUlF2aVc0eC93QStqZjhBb2FWNnBYenVaeHRYdDVIczRGM3BCUlJSWG5IWVkzaTcv a1R0Wi82OHBmOEEwRTF3MnM4V25odi9BSzhCL3dDaTQ2N254ZC95SjJzLzllVXYvb0pyaGRhLzQ5 UERYL1hpUC9SY2RBRkd0RFExM2F2Q1BadjVWbjlxMC9EM090US9SdjVVd1BPdkdOaXlhbmRYVzhi ZlBlUGIvd0FDei83TlhMa2NWM254RUczVEpHSFg3ZkwvQURGZWNKTWNZT2EyaTlDYkVwNzFFY21w d054eFVxeEtPMVZhNGpQS01lMU1NWlBhdFV4cU8xTUtMNlV1UURPV0hKNkdyQ3J0R0tuSUFGUnRT NWJESG8rQmpOU2VZQ090VW40YW95N0FVYzFoV05Bc1BXbUVqSFdzOHl0NjBnbE9lcG81aDJMcjlP S2hjMEpLWDYxS2tlODVvM0Fxa0U5cVl5TjZWcGlJWTZVaGpYMEZISUJsK1dUMnFSSWoxcThVVWRx WTJNR2x5MkFqVnRwOWhVNnlBOTZyTjBxSWtqdlFuWURRTGoxcU1zdnJWRXlNTzlNTXJZNjBPWVdM eEFOUk4xTlYxbUk3MU1EdUdhVjdoWVlhWXdPS3VwQ0JodTlQTUsrbEhMY0RMMkU5cUJIejByU01h QWRLWVZBcE9BeXNxN090VFJ5Yk9uZWtmMHFKcU5nTG9rSHJUUzZrOWFvRW4xcHBrSTZHbnpoWXZF Zzk2allEYWFxZVkzclVpU0UvTFM1Z0htb2ljOUtsSXFaSVI2VVd1SW9rSDBwTUgwclNNUUhhbWxG OUtPUWFLQVVudFVnWGF0VGtLS2piclN0WVkrT1RBeFVvbHdPdFVtNjBtNXFWeERhS0tUdlVqSHFL a0FwaTFJS3BDWW82MUlEVVkvR25yVFFFOGRXRkZWNHFzcldxRUJYcVJWS1VZY2lyemZkcWhMOTQw cGdpbTMzalNmV2xiN3hwS3dLdVBXcFZITlJKMHFaYXBDWThjVTVldE54U3JWQ0psTldFNXFzbldy TWZXdElzUklCVEpWeEczMHFVZEtpbi93Qlcvd0JLcDdBVXowcWlUelYzMStsVVdyQ1JTSEwxcVZC VVNWTXRDQWxVVkl0TVVVOGRhdENIclVpR29oMXFST3RVSXNMVW1LalRwVWdyUkF5S1lZU3FGd2NJ S3Z6ZmNxaE9QM1lyT1lJcWJxa1Rtb3FrU3NTaWRNVk1CVVNkS21BclZFamhUMU5NNzA0ZGFwQVRL YzgxS0tpU3BWcTBBNGlxMG93OVdqMHpWV1g3OUppUjlBYUIvd0FnK0gvY0ZVUEdmL0hwYWY4QVhR L3lxL29QL0lQaC93QndWUThabi9STFgvcm9mNVZ5bG5LNnAveUpHaC85aGNmK2ozcjNPTDdvcnd6 VS93RGtSOUQvQU93dVAvUjcxN25GOXdVaGt0RkZGQUhPK096andYcUo5by8vQUVhdGVLbVN2YVBp QWNlQjlTUC9BRnkvOUdwWGhubWU5UzBhUmxaRnJmUVhxcnY5NkM5TGxIekZvU1ZJc3Z2VkR6TVV2 bSs5SEtVcG1rczFXSTU2eGhOVXlUKzlRNEdrS3B1UjNIdlZxT2YzckFTNDk2dVF6NXh6V1VvSFZU ckcvRkxudlZsWDRySGdsNmMxZmplc0pJOUNuTzVjRFpwMVFJMVRqcFdiT21Jd2ltTU0xS1JUU3RL NDdGT1ZLb3l4WnpXczZacXM4VlVwV01wMDdtSE5CVkNhSHJYUXpRY1ZuVHdWdEdaeVZLUnowME5W SGp4VzFQQ2VhejVZOGMxMFJrZWZVcDJNMTF4VUJGWEpWcXFSV3FPU1NJalRUVDJGTU5VWmpUVFRU alRhQUdta3BUL1drb0FhYWFhY2FhYUFFNzA0TFRlOVRJTTBteDJFVkt0d1E1cHFKV2xhUTV4WE5V cVdSY1lpd1d1Y2NWcDIxanowcWUwdGM0NHJjdGJMcHhYazE4Ulk2WVU3bFcyc3VuRmJOdFpjZEt0 VzFsMDRyWXQ3TDVlbGVQWHhKMXdwbWJGYmJlMVhJazIxYU52dHFKbDIxeHVwekdxallqbWt4V2ZO YzQ3MU5keWJjMWczbHp0enpXOUduekV5bFludUwzQTYxajNOL3dCZWFwWGQ5akl6V0xkWDN2WHFV Y0tjczZwZnViLy9BR3F6NUw0SCtLc2E1djhBM3FtMTdudlhxVThMb2M3cW14SmQ1NzFYYTU5Nnlt dTg5NmlOejcxMExEMkk1elZOeDcwMDNIUFdzcjdUNzBodVBlcjlpTG5ObGJuM3FSYnIzckMrMCs5 T0YxNzFMb0RVenA0YnpIZXRDRy94M3Jqbzd6SGVyS1grUDRxNTU0VzVhcUhkVzJvYy9lcll0Yi9w elhuZHJxSHpmZXJkczcvT09hOCt2aExHOEtwNkJiWHVSMXJUaHVjOTY0cTB2YzQ1cmJ0Ym5PT2E4 ZXRoN0hYQ1oxY00yZTlXUTFZOXJMbkZhS1Btdk5xUXN6cGk3bGtHbXlMbGFFTlNZeXRZN0ZtYk5E bnRXZFBhNUI0cmZhTE5RUGE1SFN0NFZiRU9GempMeXo2OFZnM2xsMTRydnJxejY4VmlYVmtlY0N2 VG9ZZzVxbE00QzVzc1o0ckl1YmJHZUs3bTlzc1o0cm5yMjJ4bml2YXcrSXVjZFNtY2pOQ1ExVm1U RmJGekRoaldmS21PMWV0VG5jNVpSS0RqRk5xYVVZcUd1bE15RW9wVFNVd0NpaWlnQW9vb29BY0JU d3ROVVZPaTFwRkV0aXhSNU5hRU1HYWhnankxYTl0RG5GZHRDbGM1YXM3QkRiZTFhTUZ2anRVMXZi WkhTcnNkdml2WW80ZXg1MVNyY2JCRmpGV2dtS2ZIRmlwR1RGZWhDRmtja3BYWkVPS0hmQzBOeFZh WjhMMW9sS3lCUnVkcDhNSDNlS0xrZjlPYmYraHBYck5lTy9DaDkzaTI2SC9Uay84QTZHbGV4Vjhy bU11YXUyZTlnMWFrRkZGRmNCMUdMNHUvNUU3V2YrdktYLzBFMXd1dC93REhyNGEvNjhSLzZLanJ1 L0Z2L0luYXovMTVTLzhBb0pyZzljLzQ5L0RIL1hqL0FPMG82QUtWYW5oMy9rTncvUnYvQUVFMWwx cWVIZjhBa053L1J2OEEwRTFURWNkOFNPTkhtLzYvNWY4QTBJVjVmRy96RGl2VVBpUi95QnB2K3Y4 QWwvOEFRaFhsMFAzcUVETktQN3kxYkMxVGorOEt1cjByb2pzU01ZVkU5VE5VRDB3STJOTXB4cHRR QXhoVUxpcDJxRjZsanVWMk5NNzA5cWpKeFdiR1dMYy9QV2hBT3RaOXQ5N1B0ViszclNBbVdDS1kv RlNHb25yVVJDNXFJbXBIcUkxbXdHbnBVYkNwTzFNYXBHUXNNVkVhbGVvVzYxbXhvVE9LdVJmZFdx YSs5WFk4YlZ4VlJHeStpL0tLY1JnVWtmUVVyMXVpQ0NTb0dOVHYwcUJxaGpJelRTT0tjZXRJZWxa Z1JNS2liclVyVkUxU3hvU25SL2ZGTnAwZjN4UU5saitJVmVWUmlxUE80VmZqSEZhd0pFWWZsVURu bXAycXM5TmdSTWFiaWxha3JNWXhoVE1WSTFSMGdHMFVDaWtNZXRQRlJEaW5xZWFCTWtwNjAxUlVp aXJRaVdPckMxQXRTQnNWb2dzU2svTFZDYi9XR3JUT00xVWM1YzFNbUNSVWI3eHBNMDlsTzQwekhO WldHUFNwbHFGZUtlRFRBbUZPVVV4VG1wRXFrSWVsV1k2Z1VZTlRMd2EwUWljVkhQOEE2dHZwUzdz Q29aWCtRaW13MUt4cWszV3JvOUtxc3ZOWlNLUTFldFRKVVFYQjZVOWVEU1FGaGFlT3RRZzFLcHlL cENIZ2MxSW5GTlFjVktvcTBJbFRwVWdxSmVCVGkyS3RNQnMzM0RXZmMvY1hGWFpHRzJxa3k1VVZF OVJvcFk1cVZLUXBTcU1Wa01zSlVvTlYxelVpbm5GV2lTWUROT0E1cHE5S2tVVmFBa1FWS3RScmlu aXJRRHllS3J6ZmZGU2sxQTV5MUppUjlBNkNQK0pmRC91Q3MveG54YVduL1hRL3lyUTBIL2p3aC8z QldmNDAvd0NQTzAvNjZ0L0t1VXM1WFUvK1JIMEwvc0xEL3dCSHZYdWtYM0JYaGVwLzhpUG9YL1lX SC9vOTY5MGkrNktReVdpazcwVUFjMThRditSRjFML3RsLzZOU3ZDcTkxK0lYL0lpNmwvMnkvOEFS cVY0VlFBVUdpZzBBSlNVdmFtMEFIMHA2bW1Vb09LUTB5WldxM0MrTVZuN3FuamZGUTBiUWxZMm9a ZmVyOFUvdldESExqdlYyR2Ztc0pRTytsVnNic2NtYXRvM0ZaRUV1YTBJbitXdWFTUFNwVHVXYzB1 YWp6VGdhZzZFRFZFMVNtbUVVaGxlVWNWUW5qclRkZUtxeVI1cW9zeXFRdVlzME5aMDhPTTEwRWtQ V3M2ZUhyVzhKSEZWcEhQenhkYW92SGl0cTRpNjFueVI0elhUR1I1bFNuWXoyV29XNHEzSXVLcXY5 NnRVYzBsWVlhYWFjYWFhWkEwOTZRMHBwS0FHbWpiU2luQVpOSzREUW1XcTNGRm1vMFQ1aFdsYlE1 ckdyT3hjVUVOdGsxc1dWcjA0cHR0Ylp4eFc1Wld2VGl2S3hGZlE2WVFKN0sxNmNWdlcxdGdEaW83 SzE2Y1Z0eFcyRkhGZURpSytwMjA0RWNFZUswSXpoS2hFZTJuazRXdlBtK1kzU3NSVFM0clBudWNk NmRkUzR6V0xkM09NNE5kRkdsY2lVaEw2NnpubXVhdnJycnpWaSt1K3ZOYzVlM1hYbXZadzFBNUtr eUM2dWNzZWF5TG1YUGVrdUxuTEhtcVVrdWE5dWxTc2NjcFhJTGhzMVdOU3lObW9xN0lyUXlZMDBs TFNWUWhLUTB0SWFBQ2lpaWdCeTFLcHFFVTRHazBPNWR0bncxYlZyUGpITmM3RStEVitHZkhldVd0 VHVhUloxMXBkNEk1cm9MSzc2YzF3TnZkNFljMTBGamQ5T2E4bkVZZlE2cWRROUFzcnJweld4RmNa NzF4bGpkZE9hM2JlNHpqbXZCcjBiTTdxY3pvNHBNMWJWc3JXUmJTWnhXbEdmbHJ6cWtiSFRGazRO S2VsTUJwMVlsbEtkTTVyTm5nem10cDB6VlY0TTF2VG5ZaVVUbGI2MTY4VnpWOWFkZUs3Njh0YzU0 cm5yMjA2OFY2dUdybkxVcG5uOTNaL01lS3liaTJ4MnJ0Ynl6NVBGWUYzYll6WHZZZXZjNEtsT3h5 dHhIaXF4V3RXN2p4bXFETGl2V3B5dWpsa3RTc1JUYWxZVkZXcUlDaWlpbUFZcGNVQ2xBelRFU3hM bXJzVU9haHQweldwYnhaeHhYWlFwM09lcE93dHZiODFyMjBXTVZIQmI5SzBvSWNZcjJNUFJzZWRW cVhMTnVtQlZ0VnBzTWVCVTZyWHJVNFdSd1NlbzVCVEpUaXBWRlY3azRyU1dpSVdyS3NzdUt6NTUr RHpUN21YR2F5TGlmazgxNWRlclk3YWRPNTZIOEg1Ti9qRzc1LzVjSC85R1IxN1p6WGhQd1ZrMytO Ynovc0h2LzZNanIzYXZuY1ZMbXFYUFpvSzBMQlJSUlhNYkdONHUvNUU3V2YrdktYL0FOQk5jRHIz L0h2NFkvNjh2L2FVZGQ5NHUvNUU3V2YrdktYL0FOQk5jRHIzL0h0NFgvNjh2L2FVZEFGTWRLMWZE My9JYmgramYrZzFsTDkwVnArSHVOYmhQczM4cXBpT1ArSlAvSUlrSHJmeS93QXhYbHljR3ZSZmlE ZXJPdHpaZ0RNVjdJeE80ZDhkcTRGSStSeFRpZ0xrWDNscTJLcHB3UWFzQnEzaVNPUFNvbnFVbmlv MnFtZ0lDS2JVcEdhalBXb2FBWTFRdjBxUnpnNHFGdWFoaklXcVBHYWxLOTZhRjVyT3d5UzI0ZjhB Q3RLMzZWUmhYRFp4VnVGc1ZwQVRMWGFvbXAyN05OSnJVUkEvV29pS25hbzJIRlpzQ1B0VWJmV250 VVRHcEdSdlVMZFRVclV6Ym1vYUdoZ3E1RDkwVldWZU9sV2tHMVJWUkJtaEg5MFVyVkNqZktNVThz TWRhMVRKSTNxQnFuWTFFd3FXTWhJcEQwcDdERlJNYWdZeHFpYW5tbUVWQUNVNlA3NHB1S2ZHUG5G Q0dUL3hpdEJPQldmL0FCVmFWODRyV0xKSkdxdS9lcG1PYWlhbXdJR3B0U01LalBCcUdNYTNXb3ox cDdkYWpxR0JZRUlOTDltV25LYW5TdExDSy8yWUNtTkNSMEZhR01qcFRIVENrVStVQ25uSFdtbWM0 cEgrNmFock51dzBUZmFXcGZQWTk2Z3B5aWk0eVV5TWVLY3ZTbUtLa0ZNUThvSEF6U2kzVTBpbXBr cXJYRVJpMFh0U20yQUJxMG9OUEs1RlZ5Z1ozbGxEMDRvRGhPdFdMbmdDcVUvUVZMMEFrKzBHbEZ5 OVV5YWV0U3BETFF1RzZVbTh1M1BTbzFGU3FLYVloM2VwVEdyZHFpcVJUVkFIMlpQZW5DMVVkS2tR MU10VWtGeXExc0FPS1lGMm5GWDl0Vlp4aVQ4S0dyQ3VSZWJzR085TSsxTm1vcHppVDhLaTZ0V2JZ eTRMcDhVdm5zZUtxcGlwbEZOTUNRTVdibXBWQXpVYWlucWVhdENIR0JEUUxWVFQxUE5TclZXdUJG OW1XbW1IQjQ3VmJGSVZ3S09VQ29EanJTTlBqcFN5REN0VkF0VU4yR1hCZE5TaTVZMVRYclV5Q2xj Q2Z6bU5PVDd0UnF0U0tLb1I5QzZEenA4UCs0UDVWbmVOZitQTzAvNjZ0LzZEV2g0ZlArZ3hmN2dx aDQxLzQ4N1QvcnEzL29OWWxITGFuL3lJK2gvOWhjZitqM3IzT1A3b3J3elUvd0RrUjlEL0FPd3VQ L1I3MTduRjkwVkl5U2xwS1dnRG1maUYvd0FpTHFYL0FHeS85R3BYaE5lN2ZFTC9BSkVYVXY4QXRs LzZOU3ZDcUFDa29vTkFCVGFXa29BS2JUcVNnQktlcHhVZmFuS2FUR2l3ajFhZ2srYnJWQUdwNFg1 ck5vM3B5MU55M2tyVWhrK1dzQ0NTdEdHWGpyWE5PSjZsQ29hNnZVeW5OWjhVbWNWY2liTmM3UjZG T1Z5YWtvelNWQnNJdzRxRmxGVEdveUtBS3pvTUdzKzRqclZaZURWS1pLdUxNcWtib3c3aUxyeFda TkZqTmIwMFdjMW0zRVdLNllTUE1yVWpEblRHYW91UG1yV3VFeG1zeVJjTlhUQm5tVlkySURUVFVo Rk1OYUdBdzBsS2FDS0FFVUdwa1NtUmpKcTNGSG5GWnpkaWtoSW9zdUsyck9EcFZTQ0hMQ3Q2eWc2 VjUrSXE2RzlPSmFzN2JPT0szN08yeGppcTlqYmRPSzNMZTN4aml2QXhGWTdxY0MxWndnWTRyWUNL SXh4Vk8yanhpcnpjUml2SHF5dXpxaWl1K0JWYVdRQlRVa3pZclB1SmNLZWFjSTNFMlo5N04xNXJu TDY0eG5tdE8vbXhtdVp2NSt2TmV4aGFSeTFKRkc4dU01NXJuN3lVODgxZHVaczk2eDdsODVyM3NQ VHNjTTVHZk01M25tb1N4Tk9rNWFvelhwcGFHQWhOTnBUU1V4Q1VsTFNVQUpTR2xwRFFBVVVVVUFG RkZGQURsT0tsVno2MUNLY0RTYUdtWElwR0RqbXQ2eG5JeHpYTlJ0aGhXdGFTNHh6WEpYaGRHa0dk blkzT01jMTBkbmM1eHpYRFdsempITmI5amM1eHpYaFltaWQxT1ozRm5NRGl0bUtUNUJYSjJNK2Nj MTBFRXVVRmVEaUtkbWQ5T1JxSzFTcWFweHZtclNIaXVLU3NiSWZTYlI2VXRGUmNvcVhVWUlQRllk M2JnNTRyb1pseldkUERtdW1qUGxNNXh1Y2plMnZCNHJtYisyeG5pdlFMeTErUThWeXVvMjMzdUs5 bkNWamlxMHpncitIR2F5Wkk4VjAyb3dZeldMTkZpdnBLRlM2UE9uSFV5cEZ4VmVyc3lZTlZDT2E3 b1BRd1kyaWlnZGFzUTRDbmhhRkZUS3RhS056T1RzV2JST2xiZHJIMHJNdEU2VnVXa2ZTdlZ3bE00 YThpL0RIOG9xN0VncU9KUGxGV28xeFh1MG9XUExuSW5qSEZTVTFCeFRxNjB0REJpaXFWNDJNMWJ6 VkM5YnJVVlg3cGROYW1KZVBqTllkeEo4eDVyVXZYNjFnM0QvT2ErY3hjOVQxNkVUMHY0R3RueHhl ZjlnNS8vUmtkZS84QUZmUGZ3SWJQam04LzdCMG4vbzJLdm9TdkhxTzhqMFlLeUNpaWlvS01YeGQv eUoycy93RFhsTC82RFhBZUlQOEFVZUZ2K3ZML0FOcFIxNkI0dS81RTdXZit2S1gvQU5CTmVmOEFp SC9qMzhLLzllWC9BTFNTZ0NvdkMxb2FLY2F0Q1I2Ti9LczBkS3Y2Ti95Rll2bzM4cXBpUE5mRjZl WjRqdW1ibjUyLzlDYXNQWXE1SXJkOFdmOEFJd1hYKyszL0FLRTFZUnJhS1ZpUmhPQnhVWWxaYWtO Uk1QU2dCVGNNS2I5cGFvbkdLaFkxRGtPeGNGd2Fma0hrVm5odnlxNUVRVTRwcDNHU0NIZWNtbCt6 REhlckVhblpUeUswNVNVVlBzeUNtK1FvcXkvRlJNYVZoa1pYQTRxTnlRYWtKcU54VXNCUFBaYWFi cHFZd3FGeGlwdUJZKzFObW5MTm5yVkhQTlBSZ1dITkpNWmN4bmdmclRsdHdUM29pR1hGWEF0YUpF bFEyb3pUZnN5aXJqZEtoWTBORElmSlZlVFRDT2NWSXhxTTgxTEFqM3NoNHBmUGJGTllWR3c0cUd3 SkRjc2FRWEJOVnpTQ2xkakxtOE5pazJGeU1Db29lZDNXcnRzTWcvV3FqcUlpRnR6UWJaUWF1NHhV YlZUaUJVTUNqdlJzVkY0cVJqVWJVckFNeHhUUklVNlU0OUtZd3hVM0JDK2V3cHBuYzFHYVNwdU1t RXpFODBwTzdtb085U0o5MmhESGlQY2M5cWY5bkZUUXBsQlV3WGl0RkVrcHIxcXhIVlphc3gwUkFz S09LYkx3dkhwVGxwc28rWDhLdGlNMlQ3aHFHcG4rNGFockJsSVR2VXExRjNxUmFReVVDblk1cG9O T3F4RGxxWktoRlRKbXFRaXluUVZLT2xRcDBGVEE4Vm9oRlM2UFNxRS9SYXYzUFFHcUUvUVZsUGNa RGlucDBwbWFlbFpyY1pPdFNnVkV0U2cxb2hCM3A2OWFaM3A2MDBJbVRyVmhLcnBWaE9sYUlDVHRW TzQvMW40VmI3VlR1UDhBV1k5cWN0Z0tGeVAzamZTb2wrOGZyVXR5ZjNoK2xSRHJYTzl5aVpNWnFk YXJwVmhhcENKQlR1OU5GT0hXckVQWHJVeWRCVUs5YW1Ub0t0QVRDaHVCUUtHSEZWMEVVcGZ1dFdh d3cxYU12Q3RXYzNKNHJDWlNIcFZpUGdWWFRyVmhEU1FNblduMUd0UHJSQ1BvSHc4YzJVUi8yUlZM eHIveDUybi9BRjFiL3dCQnE1NGQvd0NQR0gvZEZVL0d2L0huYWY4QVhWdi9BRUdzQ2psZFQvNUVm US8rd3VQL0FFZTllNlJmZEZlR2FuL3lKR2hmOWhZZitqM3IzT0w3b3BESktYTkpSUUJ6WHhDLzVF WFV2cEYvNk5TdkNlMWU2L0VML2tSZFMra1gvbzFLOEwrbEFCU1VVZHFBQTAybHBLQUU3VWxPcHRB Q0hwUlFhS0FRb05TUnRnMURUMFBOUzBVbWFFTW52VjZLWHBXVkcxVzRuNlZqSkhiU21iY0VtY1Zw UU5uRllsdTlhdHUzU3VXYVBXb1N1WGpTY1VtZUtNMWdkeUZOTUlwYzBHa01ZUnhWYVJCVms5S2dr Rk5Da2lqSkhXYmN4ZGExcEIxcWhjcjFyYUxPU3JEUTUrNlRHYXlKbE80MXZYU2RheUowK2F1eURQ R3J3S1RDb202MVlkY1ZBNHhXeU9PU0dVbUtjQlM3YzBFRG9SeldqQkhuRlZJRTVyV3RvdWxjdGFW aldDTE50RGxoZ1YwVmhCMHJOdEllUlhRMk1XTVY0MktxSFhUaWE5aGJqaXRtT0FDcWxqSGpGYXFK aXZucTg5VHZoRUk0OFlxYVhoS0ZHS1NmN2xjbDdzMXNabHcyS3lMcVRDbXRLNlBXc1c4YmcxMjBZ bUUyWWVvUzR6WExhaE4xcmYxQi92Vnl1b3Y5NnZvTUhBNGFyTXlhWW1zK1ZzNXFhUjZxT2E5dUVi SEkyUU9lYWpOUGJxYVlhNkRNUTBsS2FTZ0JLU2xwS0FFcERTMGhvQUtLS0tBQ2lpaWdBb3pSUlFB NVd3d3EvQkppczhkYXNSTmlvbXJvcUp0d1hHSzN0UHVlbk5jbkhKaXR2VHB1bk5lYmlLV2h2VGxx ZDNwODVPSzZhMWx5Z3JpdE9sKzd6WFQya3Z5aXZtOFZUc3owcVVqb0lYNlZvUW5Jckh0M3ppdFNB OFY1RlZXT3VETE5GTnpTMXptZzFobW9taUJxYzAwaXFUc0JuM1Z1UEtOY25xZHYxcnRia2Z1alhM NmxIbk5kMkVuWm5QVmljQnFjR00xejl4RmpOZGxxTUdjOFZ6bDFEak5mVVlXcm9lWlVpYzVjSmpO WjdEazFzWGNlTTFsdXZ6R3ZacFN1ampraUEwRHJUaUthUHZWdWlDZU1lMVdZMHFLSmF1eEptdXVu QzV6elpidEU2Y1Z1MmlkS3k3Vk1Zclp0VjZWN09GZ2ViWGthVVNmS0tuVmFqakh5aXBscjJvSTg1 c2tYaWtOS09sTVkxb1NOSnJQdm02MWRZMW5YeDYxelYzN3ByUytJNTYrYkdhNStkLzNocmN2ajE1 ckFtKythK1l4ajFQY3c2MFBUdmdLYytPcjMvc0d5ZitqWXEraUsrZHZnSC95UFY3LzJEWlAvQUVi RlgwVHpYbk02MEZHYUtLUXpHOFhmOGlkclAvWGxMLzZDYTgvOFJmNmp3ci8xNWY4QXRKSzlBOFhm OGlkclAvWGxMLzZEWG52aVBpSHdwLzE1ZiswVW9BcUwwcS9vL0dxeGZSdjVWUVhwUnV2VVlIVGlC ZGRGSlhjQU81eDlNMVRFY0o0cy93Q1JndWY5OXY4QTBKcXdUV3JycG5PclRpNU82WU9kN2JkdVRu UFR0MXJMTmJMWkVqY1V4cWYycGpVQVFTZXhxcy9Xckw5S3JOV2JLUTBacTlBTVIxUkZYb1RtT2lB bWFNUnlsS2FiRU1MVGowcmRFa0wxQzFUUDNxRnFsakk2UTB1TVVocVFJMnF2SlU3MUE0cUdORUpw MFl5dyt0TlBGT2orOStOUXR4bWpEOThWZUhUbXFVWCtzSE5YUnhYUkhZa2phcTcxWlk4VldlaGdS TlRlMUthVHRXYkFZd3FKdmFwVzZWRTNTcEdRdDFwQlN0MXBLa29tZzcxZnREdzMxcWhCM3E5YWRH K3RhUUpaYVBTb0pLblBTb0hyUmlLN1ZFYWthb3pXVEdKVFRUdTFOUFNrTWlhbTA1cWJVQUZTSjky bzZrVDd0TkRMMXQ5MGZXcHlPYWd0eDhvUHZVK2EzUkxLS2ptcDB3S3ErY0JUaGNLS3pUSFl2QnFZ Ny9LYXJDNUdLWTBwWVlGVnpDc01mbGFocXhqUFdrTUhwV2JRMFFVNVRVbjJkcWQ5bmNVV0dOV3BB TzlNTVRMelR4OTJtaEQxRlRJTVZEdUNqclNpNFVWVnhGdFRUeTJLcGZhbHpTbTVCRlZ6QllmY0ho YXB6RG9LbTh3djFvOHZ6QjA2VkwxR1V0cHA2OFZPYmNucFNpMWVwNVJqRk5TS2VsQXQzNjB1d3Ex T3dtT3FWQjdWRjJxUXlLbFVoRXlpcGxxb0xsUjBOS0xwYXE0V1piTFlxdE1jeVUwM0dUVEEyN21o dTRpdk11WlByeFVPUG1xK1l0d3ozcVA3TWM4VkhLTWdXcGxOT0ZxMU9GdXdIZWhSQVZUVWc2MUVG S21wVjYxUUVpaXBWNHF2NTZDbEZ5dnJWWEN6TFlwck5WZjdTS2FaODhEb2FkeFdFazVEVlNaS3ZZ elRUQm5wV2JWeGxKUmlwMDRxVVd4cFJiTlFvZ0lwcVZhWjVMTFRsNEZXaEgwRDRkLzQ4SWY5MFZU OGJmOEFIbmFmOWRXLzlCcTU0ZC80OElmOXdWVDhiZjhBSG5hZjlkVC9BQ3JuS09WMVAva1NORC83 QzYvK2ozcjNTTDdvcnd2VS93RGtSOUQvQU93dXYvbzk2OXppKzZEU0dTVXRKUzBBY3o4UXYrUkYx TC90bC82TlN2QzY5MStJWC9JaTZsOUl2L1JxVjRWUUFVaHBhUTBBSWVsSlRqU1VBSlNVdE5vQVNr TkxTVUFKVGxwdEE2MERUSjBhckViOGlxaW5pcEVQekNzNUkyZ3phdG42VnNXemRLd2JadWxiRnMz U3VTb2oxOE5JMHdhY0RVQ3Q2R3BGTmN6UjZjV1NVSHBTZlNrcVRRUTlLaGNWTlViVUlHaXM0cWpj cldnM1NxZHdLdUpoVVdoaVhLZGF5WjA1TmJsd3ZXc3FkT1RYWEJuazE0R1pJdFU1QldqTXRVSlJp dW1KNXRSV0dDbmhhYW81cWRWNXBTWm1pYTJUbXRxMGl6aXN5MFRtdCt6ajZWNStJa2IwMGFOcEQw cm9MS0xwV2JaeGRLM2JTUEdLOEhFMUR1cHhOYXlqNlZwQk1WVnRCakZYalhpVkhxZGtWb05BcU80 NFNwYWh1UHVWa3R5bVl0MmV0WVY0M0JyYXZPOVlONmVHcjFNT2Nzem5OUmY3MWNucUwvZXJwdFJQ V3VUMUU5YStqd2FQUHFzeVdhb1dOS3hxTW12WlNPVzR3MDAwNm1tcUVJYVNsTkpRQWxKUzBsQUNV aHBhUTBBRkZGRkFCUlJSUUFVVVVVQUZTcTNGUlVvb0FzTEppdGpUcHZ1MWdBMXE2ZTJNVnoxb2U2 WEI2bmI2ZEw5M211cHNwZmxGY1RwOG5TdW5zcGVBSytheGRNOUdsSTZxMWZPSzJyWnVLNXV6bDZW dTJyOFY0TmVKMzAyWHhUeFVJYXBGTmNkamREelNVVVVnSXB4bU0xejEvSG5OZEZOL3F6V0xlSm5O ZE9IZG1aMUVjaGZ3WnpYT1hzR00xMmQ1Rm5OYzNmeGRhOS9DMURncXhPUHZZOFpyR2tYREd1aXYw eG1zR1ZmbU5mUlllV2g1OVJGUmhVWSs5VXppb2g5OFYyd01HWFlGclJnVHBWRzNGYTF1dlN2VXc4 Ym5EV1pkdGt4aml0YTNYR0tvUUxXbkFPbGUzaDQyUE1xc3ZJUGxGU0NtSjkwVThWNlVUa1k3dFVi VkoycU5oVlNKUkN4ck92VDFyUllWbTNxOWE1Sy93bTlMYzUyOTcxZ3pmZk5iMTZPdFlNMytzTmZN WXZjOXpEN0hwdndEL3dDUjZ2Zit3YkovNk5pcjZJL092bmY0Qi84QUk5WHYvWU5rL3dEUnNWZlJP SzRHZFlVVVVVZ01YeGQveUoycy93RFhsTC82Q2E4KzhSLzZud3AvMTVmKzBVcjBIeGQveUoycy93 RFhsTC82Q2E4KzhSLzZud3AvMTVmKzBVb0FxTDkycitqRE9xeFlQWnY1Vm5xZmxyUjBRZjhBRTFp K2pmeXFtSTg0OFlRK1Y0aXVCNnN6ZitQTlhQc0s3SDRqMjMyWFhGbjV4TXY0ZjU2MXgyOVdyYUw5 MG5xUjlLalkxSXdKNlV3Uk0xRFFFRDFDdzlxdW0yWWltL1pXcWVWakthcnhWMkpjSlF0dmo3M1Nu NHhRbFlDekczeWluazFURTJ4c2RxZDlwWEZhSmlzVE5VVENtL2FrcHBuUTFOd0E4VkcxU013SXFO aHVJQXBESVhOUk4wcXo1REVVaHRYcWJYR1VpTW1ucXZ6VloreWtVOVlRcHlhWEtBK0xoODFhREdx VzdITkt0eDYxb25Za3VNYWhhby90UzQ1cHB1VUpvdU93ckNvenhUMWxWamltTWVhbGhZaVkxR3hx WFlXTkJ0Mk5UWVpWSW9BejBxejltYkZJTGNqclU4ckFaQ090WGJjNFUxQVUyZEtQTTJIaXFqb0l2 N2hpbzNxdjlvd2FRM0sxWE1GaHpDbzI2VUdkVFFYVXA3MU54aktZYWZUQkd6ZHFUQWlha3FmeUc5 S2I5bmFsWVpFS2tUcFRoQWFVamFjVVdBc3d2aEFLbUJ5S29DUXFhZUxuNjFha0lxNG9vb3JJWW9G UEE1cEZxUUNxUW1LT3RUQTFGM3A0TlVJblNwUU0xREhWaGNWYUFZeUROVlhHR1BGYUdPTTFRbS8x alVTQXFNeDNFVTNORGZlTkpXSXg2aXBBS1luU3BWcG9HT1VZcVNNNHBnRk9IRlVoRTZuSnFWUUQy cUJLc1IxYUVPMjhWRkl1RWJqdFZrVkhNQUkyK2xXOWdLUCtGVm1ZbXJKRlVXeUNheGtVUEI1cVJl dFFvZldwMHhVb0I0RlNxTVUxUUtmM3EwSWtRNHFWVFVBNjFLbldyRVRnVXBVWXBFNlZLQlZvQ3RJ dUZ6Vldac0w2VmVtLzFkWjF5RHNHS2lZRURQNlVxazVxTHZ6VXFIbXNybEVxam1wVngzcHFDcFFL MFFod3FWVFVYdFQxTlVoRXkwOENvMU5TclZnSXkxQTR3YXRZNHF0S1AzZ3BQWVNQZlBEdi9IaEQv dUNxZmpiL0FJODdUL3JxMzhxdWVIZitQQ0gvQUhSVlB4dC94NTJmL1hWdjVWeWxuSzZsL3dBaVBv WC9BR0ZsL3dEUjcxN25GOTBWNFpxZi9JajZILzJGaC82UGV2YzQvdWlrTWtwY1VncGFBT1orSVEv NG9YVXYrMlgvQUtOU3ZDNjkwK0lYL0lpNmwvMnkvd0RScVY0WFFBZHFUdFNpa29BS2JTOXFLQUVw S1drb0FhZWxJYVUwbEFDVURyUlNEclFBOFU5RDh3TlIwNVR5S2xtaWVwcDI3ZEsxcmQrbFlrQjZW cVFOaXVXYVBUdzhqV1I2blExUmphcmNScm1rajFhY2kwT2xKU0RwUldUT2xDVXhoVDZZYUJzaGFx czQ2MWJJcXZNT3RVakthME1xNFdzdWRPdGJFeTlhenAxNjEwUVo1MWFKanpyV2JNT2ExcmdkYXlw K3RkY0R5YTZzTlFWYVJhcnhpcmthMU0yWVJMbG1uelYwVmpGbkZZdGtuelYwbGhIMHJ5Y1hJNnFT Tml6aTRGYk5zbUtwMmNYeUN0V0ZNVjg5WG5xZDhFWHJZWXhWczFYZ0dNVk9hODJlNTBJS2d1ZnUx Tm1vYm43bFRIY1poWGg2MXo5NmVEVy9lOTY1Njk2R3ZXdzZPV29jeHFKKzlYSjZpZXZOZFhxUGV1 UzFIK0t2cE1HZWRWTWNtb3lhY2FiWHNJNVJLYWFkVFRRQWhwS1UwbEFDVWxMU1VBSlNHbHBEUUFV VVVVQUZGRkZBQlJSUlFBVVVVVUFMV2pZbkdLemF2V1p4aXM2aTkwcU81MUZqSmpGZEhaUzlPYTVH MGZwWFFXTXZTdkR4Vk03YVRPd3NwT2xkRFp2eFhKV01uU3Vsc24rV3ZuTVRDeDZOSm13alZPcHFs RzFXb3pYbXlPbEU5RkpSbXN5aHNuM0t5N2xNaXRWL3UxUW1YTmFVM1ltU01HNWh6bml1YjFHTEdh N0dlTE9hNXZVNHNacjE4TFUxT1NySFE0YlVVNjF6a3EvTWE2dlUweG11WW1YNWpYMVdGbDdwNWRW YWxHUVZYSEwxYWxGVnYrV2xlbFRPYVJvMnc2VnNXcTlLeWJYdFczYWpwWHRZVkhtMTJhRUsxb1Fp cWNRcTlEWHQwVWVaVVpiVDd0UEZOWDd0T0ZkeU9aN2poVFdwMUlSVkNJU3RaMTh2V3RVaXM2K0hX dWV1dmROYVQ5NDVlK0hXdWZuKythNksvWHJpdWZuSDd3MTh0akY3eDdtSGVoNlo4QS8rUjZ2Zit3 Ykovd0NqWXEraDYrZC9nSVArSzZ2Zit3Ykovd0NqWXEraU1WNXpPMUMwVVVVZ01YeGQvd0FpZHJQ L0FGNVMvd0RvSnJ6N3hKL3FmQ2YvQUY1ZiswWTY5QjhYZjhpZHJQOEExNVMvK2dtdlBmRXYrbzhL ZjllWC90RktBS2FmZHJUMElmOEFFM2kramZ5ck1UN2dyVTBIL2tNUmZSdjVWVEVjNThXSVI5a3Rw TWtZWW5nWnoyLzltcnl0SHkxZXYvRlpmK0pMbjBHZi9IMHJ4dVA3d3B4WUdpdkpBcXlFNTlxclJE NWxxNEJrVjBSMkpHRmVNMHh1S2xhb1g2MEFNWThWRWFlVFRLbGdST01tb21BRldHRlF1S2hqSUdO TkQ4MFBVZFozR1c0VzNOaXJrSzdzMVF0Z2QzNFZwVzNBTmFRRXlRS0FLYTJBS2xJcUo2MXNJaUp3 S2padUtjeHFJbXMyQWg2VkN3eFVwNlV4aFVzWkMzMXFJbXBYRlFucldiWTBQVnZ6cXluSys5VXF1 UWo1VnFrRExpcDB3S2VWd0tkSDkwQ2xZVnVsb1RjaGJpb1NhbGs3MUF4cUdNYXg1RlJNTTA4MDA5 S2daRVJVWjYxSzFSTjFxR01Tbm9jdUJUS2RIOThVQXlmSElxMGtmcFZiK0lWb0owcldKSkdWd0tp WTFPMVYzcHNDTW1vMkdhZXhwbFpzWkd3NXFNam1wbTYxSGlrQTJrNzB0RlNNZXRTQ29sTlNDcVFo d3A0NjB3VklvcWhFMFZXVnF0SHhWaFRXaUVQT2R0Wjh2M3pWNHRpcVVwekkxS1kwVW0rOGFTbGJx YVNzSHVNa1ExS3RRcFVxbXFRRW5TbkRyVGMwNWVhdENKRjYxWmpxdXRUcFZvUk9Lam4vQU5XNDlx Y09LWk0zN3MvU3E2QVVqVkZ1cHE5Vk5seVRXTWloRkZUcFVDOEdwbHFVREoxcC9lbzFOU0QxcTBJ VWRhbFRpbzFGU3FLc1JPblNwUUtpU3BNNHEwQkZOOXlzKzQrNEswSmpsS3o3a1pVVkV3S2ZmOGFs UWMwM2JnMDlldFlvb3NKaXBSVUNHcGhXaUVQNzA0ZGFiVDFxeEVxVkt2V29sNjFLS3RBeDJhclMv ZnhWbnZWYVU1ZWt4STk4OE8vOGVFUCs0S3ArTnY4QWp6dFArdXJmeXEzNGQvNDhJZjhBZEZWUEcz L0huYWY5ZFcvOUJybExPVjFQbndQb2YvWVdIL285Njl6aSs2SzhNMVAvQUpFZlF2OEFzTHIvQU9q M3IzT0w3b3BESktVVWxIYWdEbXZpRi95SXVwZjlzdjhBMGFsZUYxN3A4UXYrUkYxTC90bC82TlN2 QzZBQ2twYVEwQUJwdEthVHRRQVUyblUzRkFDVWxMU0dnQktTbHBLQVF2YWxYclRSVGgxcVdVbVhZ VDByUmhicFdWRWF2eE5XRTBkOUdScXd0VjJFMW1RdFdoQWE1Wm85V2l5K3YzYUtSZnVpbHJCbmV0 aHROTk9wcHBER0hwVmVVVllOUVNpcVJNdGpQbUZaODY4R3RPVVZRdUY0elcwV2NOVkdMY2pyV1Jj RG10cTZIV3NhNTYxMjB6eHNRaEloMHEvQ0twUWl0Q0VWRlU1b21uWXJ6WFQ2ZW5UaXVkc0YrYXVx MDVPbGVIakpIWlJSdldjZnlWb3hyVUZuSCs3cThpVjg1VmxxZWpGRTBReFVsTVFVK3VXUm9nNHFD NSs1VTFRM1AzS1Vkd1poWG5ldWV2ZWhyb2J6dlhQM3Zldld3NXkxRGxkUi9pcmxOUzcxMXVvL3hW eWVwZDYrbHdaNTFVd3lLYlR6VFRYcm81UnROTk9wcHBnSWFTbE5KUUFsSlMwbEFDVWhwYVEwQUZG RkZBQlJSUlFBVVVVVUFGRkZGQUJWdTFOVktzVzV4VXoyR3R6Y3RueGl0dXlrK1lWemtENHJYc1pQ bUZlWFhoZEhWVFoyV252OTJ1b3NXNEZjZHAwblN1cXNINEZmTjR5SjZORm01RWF1eEdzMkZxdndt dkdtanNpV3UxRkhhaXNEUVJ1bFZaRnEwZWxSTXRWRmtzejVZOGcxeldxUjR6WFhPbWMxeldyUi9l cjBNTEwzakNxdERnZFZYclhMVGo1alhYNnN1TjFjbmNMOHpWOWZnMzdwNUZaYW1iS0txLzhBTFFW Y2xGVXovckJYcTBqbGthZHIycmF0ZTFZbHIycmF0ZTFlN2hUeTY1cXcxZWk3VlFoTlg0VDByMjZK NWxRdUwwcDRwaS9kRlBGZHFPWWRSUUtNVllDVm4zdzYxbzRxamVqcldOWmU2WFQrSTVpK1hyWFB6 cis4TmRKZXIxckF1RitjMTh4aTQ2bnQ0ZDZIb253R0dQSE43LzJEWlA4QTBiRlgwTlh6MzhDUmp4 emUvd0RZTmsvOUd4VjlDVjVVMXFkMGRnb29vcVNqRjhXLzhpZHJQL1hsTC82Q2E4OThTLzZud24v MTUvOEF0Rks5QzhXLzhpZHJQL1hsTC82Q2E4ODhTLzZud24vMTUvOEF0RktBS3FmY0ZhV2cvd0RJ WWkramZ5ck5UN2dyVDBIL0FKREVYMGIrVlV4R1Q4VnYrUUdmOTMvMmRLOFppKzlYczN4VkgvRWpQ MC85blN2R1kxK1lVUkJtbEVQbVdyaThDcWNmRENyV2E2WTdFZzFRUDNxWTFHd29BZ05OcVJxak5T QTFxaGNjVkt4cUZ6V2JHUVBVUnFWczB6R2FoalJOYTlhMGJmak5aOXVNTldoYm5CUEJyU0FtV1Qw cUY2a3ptbzJyVVJBL1dvalV6Q295S3pZRWZhbU5UelRHcUdNaGVvVzYxTTVxRTgxREdoQjBxNUY5 MFZUQXE1RndxMVVSbWpHUGxwV3BzYmZLT2FWanhXeUlJWE5WMnF3OVFzS2xnUkdrUFNsYmltazRx R01qYW9tNjFLeHFKcWhqRXAwZjN4VFJUa1B6aWdaWS9pRlgwKzdWQWNzS3ZLMkI3VnJFa0c3MVhl ckJOVjNwc0NCcVNudFRPbFpqR3RVWnA3R21VbUFGVDZVbTArbFd4ZzFJcUE5cWZLQlJBSTdVNFp6 Vi93QW9ZNlZFOFEyMCtVVnlKZXRTQWdWQ1R0WE5SczdIdlN2WVplVjE5YWVKZ085Wm00K3RLQ2ZX bnpCWTBIbUdldFFFN2ptb0J6MXFWZU1VWHVBeDR1QzNhbWVXZlNyaThpcEFvOUtPVzRpZ0ZQcFR3 R3pWOFJyNlV2bGdkcWZJQlNUbXBreHpSSkdFeGp2VVR1VUgxbzJDeFpES09jMDhTcU85WmhrUHJT aGllOUxtQ3hxZWFNZGFqZVhPVnFrTSt0UFVjMVhNQko3VkUwUnhuRlREclV5blBhaTF3S0lqSTdV b1J2U3RBQUh0VHhHcDdVY2dHZUF3NHhVcUhpcmJSREZWM1FJMkJUNWJBT1RHMnBBeWp2Vk9TUXFT dWFpOHdnOEUwdWF3R21zZ0hlbkdSVDNyTERFbnJUd1Q2MVNrRmk0OHVSdHFKMDNqRk1RYzFNdjNx VzRpcVlUNlVlVXc3VmZYclQxVWVsSElNendqRHRUeGtZelYvd0FzSHRUR2lCenhWY2dya0lIU3BS Z1ZFZmx6aXE3U2s5NlRkaG1nSFgxcGQ2K3RaZ2tQcWFjR1ByVFVnc2FKbEE3MUN6Ymptb0J6VWlE RkRrSStndkR2L0hoRC91Q3FmamIvQUk4clQvcnEzL29OWGZENDIyTVEvd0JrVlM4YmY4ZVZwLzEx Yi8wR3VjbzVYVS8rUkkwTC9zTEQvd0JIdlh1Y1gzUlhobXBmOGlQb1gvWVdIL285Njl6ais2S1F5 U2lpaWdEbXZpRi95SXVwZjlzdi9ScVY0WFh1bnhCLzVFWFV2KzJYL28xSzhMb0FLUTBVR2dCS1R0 UzBVQU5wS2RUYUFFcEtVMGxBQ2Q2U2xwS0FDZ2RxU2dVaGxtTTFjamJGVVVOV1Vhc3BJNnFUTlMz YXRTM05ZMXMzRmExc2E1YWlQV3c3TkpmdUNsN1VpZmRGS2E1WHVlbXRoS2JUdTFOTkhVcERUVUVn cWVvWktZbVU1UnpWQ2NmTFdoSUtwWEErV3RZbkpWUmlYUTYxaVhOYmwyT3RZbDExcnRwbmlZa1dB ZEswb0t6WUIwclRnRloxamxnYkZndnpWMWVuTDkydVgwOGNpdXQwMWZ1MTRHTlozVVVkTFpyKzdx Mm9xR3pYOTNWb0xpdm02ajFQUml0QUFwYUtLeVpRbFEzSDNhbXFHZjd0RWR3TU83SFdzRzlIRFYw RjJPdFlWNE9EWHFZYzVhaHl1b3Ixcmt0Ulg3MWRocUM5YTVUVVYrOVgwdURaNTlWR0F5MUdSVmho VUxEM3IyRXprc1JVMDA0OWFhYW9RaHBLVTBsQUNVbExTVUFKU0dscERRQVVVVVVBRkZGRkFCUlJS UUFVVVVVQUZUUW1vYWtqT0tVaG8wSW14V3BaU2ZPS3hZM3hXaFpQKzhyanF3ME5ZczdYVFg2VjF1 bnR3SzRuVEg2VjJHbk53SytheHNUMDZMTitBMW93VmxXNTZWcVc5ZURWUjNRTG9vb3BLNVRVRFRE VHpUU0tFQkV5OEg2VnpXckQ3MWRTVjRybWRYWDcxZG1GZnZtTlZhSEJhdVB2VnlWeDk0MTErcmo3 MWNoY2ZlYXZzc0Y4SjQ5YmN6cHFwSC9XVmRtcWtmdml2WXBISEkwYlk5SzJMWTlLeGJjOUsxclk5 SzluRE04NnNqWWhOYUVKNlZsd0d0S0E5Szl1aEk4eW9pK3ZTcEJVYWRCVWdyMEluSXh3cGFRVXRX U3dxbGVET2F1VlZ1aG5OUlYrRXVHNXoxNG1jMWgzRWZ6R3VqdWt6bXNlNGk1TmZQNHFucWVyUWtk dDhEVng0NHZQK3diSi93Q2pJcStnSzhFK0NTNDhiWG4vQUdEbi93RFJrZGU5WXJ4S3l0STlTbTd4 Rm9vb1BTc2l6RjhYZjhpZHJQOEExNVMvK2dtdlBQRXYrbzhLZjllWC90R092US9GMy9JbmF6LzE1 Uy8rZzE1NzRsLzFQaFAvQUs4di9hS1VBVTArNEsxTkIvNURFWDBiK1ZaYWZjRmFtZy84aGlMNk4v S3FZakwrS1F6bzRIcVAvWjByeUZJU0RraXZZUGlaL3dBZzFPL1gvd0JDU3ZLVzZWY0ZvSmthOEhq dFV5eWc5NmdQU29qeFdsN0NMeGtVOTZhWFdzOW1JSEJwaGtZVkxtQm9FZzFHMzNxcUxNMmM1cXdw M0xtaTl4akh6dXFNb3g3VmVTTWZlNzFKNWFnZEJUNUxpTW94TVQwb0VURHRXbVZIcFRDTURwUzVM REtpUjdEazlhbFY5aHB6bW9YSEZMWVJiRXE0em1rTHFmNHFvRWtWR1dJN21uekRSb0ZsUGVtbkdE VkR6VDB6VWlTdHVxZVlkaVZ1QlVSQlByVTZMdWJGVHJFRjdVK1c0ak9LTWUxTjhvLzNhMVNnSGFt RUQwcGNnR2NzSlBhcDFVS0ttUEhRVkUxTzFndVN4emZ3bW5tVWV0VVRrSE5NSjk2U2tPeGZMcWU5 TUpVMVIzRWQ2UU9jOWFYTUZpMjRxSnVvRkNPWDRQYXBrajM4MHJYRVZpcDlLWVViMHJURVl4MHBy SXVNWTYwK1FhTTNZM29hZXNlTU1hdVl4MnBqbmlqbHNCSFVxeTgvU29UME5SRWVsSzloRjd6aDYw d3VwNzFSUEhlamNmV2puSFl0a3FlbFJzT2FnREVHcEF4SXpTdmNCRzYwekI5RFZwSWdRR3hVd2lC SFNueTNHUUthc1IxWFhyVmlMdFZJa25GTmtYNVRUbEZKTnd2NTFZak5mN2hxR3BYKzdVVllNdEJU MUZSOTZrV2tESkF0UEFwQlRxc1E1VFVxR29SVXlWU0VXRUdSVW0zaW80K2dxWVZvSXFYSTRGVVp6 d0t2WFBSYW9UOUZyT1kwUTkrdFBTbVU5T2xaRkU2MUlCVWFWS0swSllkNmtVKzlNNzhVNWFhRVRw VTZEak5WMEhOV0U2Vm9nSEVWVW5HSlB3cTZlbFVwK1pQd3B5MkFvWEJ4S2ZwVVE2MUxjajk0ZnBV STYxenZjb21UbXAwRlFKVmhhcENZOENuaW1pblZZaVJUNzFNblNvRnFkTzFXZ0pSaWtaZURTaWh1 bkZXSW95OEszMHFnV3EvSjkxcXptKzlXRTJVaDYxUEdLZ1NyRWRKREpsRlBGTkhhbjk2dEVuMEQ0 ZjhBK1BHSC9kRlVmRzMvQUI1V24vWFZ2L1FhditIaGpUNGY5d1ZROGJmOGVkbi9BTmRXL3dEUWF3 S09WMVAvQUpFZlF2OEFzTEQvQU5Idlh1Y1gzUlhobXBmOGlQb1gvWVdYL3dCSHZYdVVYM1JTR1Mw ZHFLS0FPYStJWC9JaTZsOUl2L1JxVjRYelh1ZnhCLzVFWFV2KzJYL28xSzhNb0FLUTB0Qm9BYjJw S1drb0FLYlRxYlFBbEpTbnBTR2dCS1EwdmVrb0FRMGxCNlVkNkFKVXFkVFZaZUttVTFtemVETksx UFN0bTE3VmgycDZWdFd2YXVXcWV0aFdheWZkRkI0cEkvdUNsTmNaNjYyRU5OTk9waDYwRmdhaGs3 MUxVTXROQ2JLMGhxamNINWF0eW1xTTUrVTFyRTQ2ck1pN1BXc1M2NjF0WFI2MWlYUFd1Mm1lSmlS OXYyclVnNjFsVzlha0ZaVmpsZ2Jtbm41aFhXNmFmdTF5R25uNWhYV2FhZVZyd01hanZvblhXWi9k VlpxbFpuOTNWb0d2bTZpMVBSanNPb3BLV3Npa0pVVS8zZndxV29wL3U4VTF1QmpYUTYxaVhhOEd0 NjVGWTEydkJyMGFET2VhT1UxQk90Y3BxS2ZlcnNkUVQ3MWN0cUNkYStqd2NqejZxT2JkTVZYY1Zm bFNxY2dyMllNNDJpcWFhYWVldE1OYklnUTBsS2FTZ0JLU2xwS0FFcERTMGhvQUtLS0tBQ2lpaWdB b29vb0FLS0tLQUNuTFRhVUdnQ2RXcTdaTis5ck9CcTNaTis5NjFsVVh1bHhlcDJtbU4wcnNkTlB5 am11SjB0dWxkbnBoK1VWOHhqa2VuUVowTnVlbGExdldQYkhwV3ZiZHErZHJvOUNCZW9vSFNpdU0y QTAzTktlbE1KcHBBS1c0cm05WFAzcTMyYml1YTFadnZjMTE0V1B2bVZWNkhFYXVldGNoY2ZlTmRa cXgrOVhKWEgzbXI3TEJMM1R4cTI1bnpWU2I3OVhacXBOOSt2WXBISEl1UUd0T0I4RVZrUk5pcjBU NHIwNk1ySEZVaWJ0dS9TdFMzYXNHMms2VnNXemRLOW5EelBOclJOZEQ4dFNBMUJHZmxGU3FhOWFM T0JvbEZMVFJTMXFpR0ZWNXhtckZReWpOVFBZY2R6S25UTlpWeEYxcmRtVE5aOXhGeFhtVjZkenRw U3NkVDhGMDIrTmJ6L3NIdi82TWpyM1d2RWZnNm0zeGxkLzllRC8rakk2OXVyNXJGcTFROXZEdThB eFJSU1Z6R3hqZUx2OEFrVHRaL3dDdktYLzBHdlBmRXY4QXFQQ24vWGwvN1JTdlF2RjMvSW5hei8x NVMvOEFvTmVlK0pmOVQ0VC9BT3ZML3dCb3BRQlRUN2dyVTBIL0FKREVYMGIrVlphZmRGYW1nLzhB SVlpK2pmeXFoR2I4VGY4QWtHcCtQL29TVjVPVFhySHhOR2ROWDJCLzlDU3ZKejFxNmV3bU43Vkd3 cVR0VEdxeEVEaXE3bm1yRW5RMVdicldiS0VEVmRnT1VxaDNGYUVJK1NuQUhzWG8xd3RQSTRwa1BL ODFJZWxib2dnZW9tTlN2VUxWREdNSnpUQ0tjYVExSUVMQ29INHF3OVY1S2hqUkVhZEczekRudlRU VG92dlo5NmhGR2xDTXVLdVlxbEYvckJWNGRLNkk3RU1qWVZBNTVOVHRWZDZHQkV4cHA2VXJkS2Iy cUFHa2NWRTRxVnFpYnBVRFJDMUpTdDFwS2dvbWc3MWV0UnVEZldxRUhVMWZ0ZjR2cldzQk1zRmFp Y1lxZHZTb0pPbGFNa3JzYWpKcDdkYWpOWnNZbmFtRVUvdFRUVWpJV3BLVnFTb0dGU0o5Mm82a1Q3 dE5BWHJkY3hqM3FYRlIyMzNWK3RTa2MxdWlTaW9xeEZVUUZTS2NWQ0FzQTAyUWphYWJ2d0tqZHdW SXFyNkFWSEh5bW9hbVlmTFVKR0t5WTBKM3FSYVozNlU1YVZoa3dQTk96VVFOU0RtcVFoNEZUSlRF SFNwVkdLcENKMDZWSm5pb1FjVXBmM3JRVmlLNTZMVkNmK0VWY25iSUZWcFYzWXhXY3hvclU5S1Fp bkFZck1vbVdwUlVBTlNLYXNUSDk2ZXZCcGc2MU1vOXFwSWtlbldyQ1ZDdkJxUUhGV2dKQ2FxVC93 Q3MvQ3AyYkFxdEljdU1VUzJBcFhIK3NQMHFMdlZpVkNYSnh4VVczbnBXRFJRNUtzTFVDMUlwcTBJ bkZPRlJLZWFsWHJWQ0hyVTZEaW8xV3BGcTBCS0tDZmxwdTdBcGpQMTVxcjJFVnBlUTJLenlPYTBX NUJxb3lZckdTdVdpTk9Lc0lhaEMrMVNMeFVwQTlpd3BxUWRhZ1U0cVZUbkZhSWsraHRCLzVCOFAr NFA1Vm5lTmovb1ZuLzExYi8wR3RIUWYrUWZEL3VEK1ZadmpiL2p6cy84QXJxMy9BS0RXQlJ5MnBm OEFJajZGbi9vTEwvNlBldmNvdnVpdkROUi81RWJRdit3c1AvUjcxN25IOTBVaGtuYWxwTzFMUUJ6 UHhCLzVFWFV2KzJYL0FLTlN2REs5eitJUC9JaTZsLzJ5L3dEUnFWNFpRQVVsTFNHZ0FOTnBmcFNV QUgwcHZTbHBLQUVwS1U5S1EwQUozcE85TFNVQU5wS2NlbEpRQTRkcWxXb2xxUmFobXNTL2FtdHkw N1ZoV3ZhdHkwcmtxbnJZUTE0L3VDbFBTa2orNEtVMXlIc3gyR21tMDQ5S1pRVUlhaGxxVW1xOHhv Uk1tVlpUVkM0UEZXNW1yUG5iZzF2QkhEVmtadDBldFkxejFyVnVUMXJKdU90ZGxNOGJFTWZCV2xC V1pEV2pDYXpxblBBM0xBL01LNnZUbSs3WEgyTGNpdXEwNStsZURqVWQxRTYrelllWFZzR3MyemY5 M1YxV3I1eXBIVTlDSllGT3FOVFQ4MXpzMFd3VkZOOTJwRFVjdjNhUzNBeTdoZWF5YnBlRFczT3Vh ekxoUGxOZDFGMk1aSTVTL1RyWEw2aEgxcnNyK1ByWE1haEYxcjM4Sk00YXFPV21TcUVxOWEyYmlQ R2F5cDF4bXZjcFNPS1NNNXV0TU5TUDk0MUdhNnpFUTBsS2FTZ0JLU2xwS0FFcERTMGhvQUtLS0tB Q2lpaWdBb29vb0FLS0tLQUNpaWlnQmFzMlIvZTFWcXpaL3dDdHFaL0N4eDNPeDBzL2RyczlNUEFy aTlMN1YyZW1kQjlLK1l4NTZkQTZLMlBBcll0dTFZMXQwRmJGdDJyNXl1ZWxUTDlMU0NpdUUzQTlL aGM0cVZ1bFZaV3hWUlFtTmQrRHpYTmFxMzNxMjVaTUExemVxU2ZlcjBjTEQzam5xdlE1RFZUOTZ1 VXVEOHhycHRVYjcxY3RPZm1OZlhZTmU2ZVJXZXBUbXFrLzNxdHkxVGI3MWVyVE9TUktocXlqMVRV NHFaV3hYWENSaEpHemF2MHJidFg2VnpkcS9Jclp0Wk9uTmV2aGFoNTFlQjBNVERhS3NLUldaRko4 b3EzRzllM1RtZWJLQmRXbmNWRWg0cCthNmtZdER1S2pjWnA5TllVTVJXZEtxVHgvTFdneTFYbVRL MXoxSVhSdEJuUmZDTk52akM3L0FPdkYvd0QwT092YU1WNDk4S2syK0xiby93RFRrLzhBNkdsZXcx OGxtQ3RXYVBvTUk3MGhLS0tPMWNKMG1ONHUvd0NSTzFuL0FLOHBmL1FUWG52aVgvVStFLzhBcnkv OW9wWG9YaTMvQUpFN1dmOEFyeWwvOUJOZWVlSmY5VDRVL3dDdkwvMmlsQUZSUHVDdFBRZitReEY5 Ry9sV1luM0JXcG9IL0lZaStqZnlxaEdkOFMvK1FZUG9mL1EwcnlZMTZ6OFN6L3hMVTl3Zi9Ra3J5 aGh4V2xQWVRJKzFNYW5FNEZSTWFvUkhKMHFzMVdHNXFObHllbFp0RFJDQlY2QUVKVmRVNDZWYWpH RXB4RzlpOUdSdHB4NlZERytGeG1wQ2VLMnVTUnYzcUZoVTV4VVpxV0JDZUJURFVqVkU1eFVnUnVh Z2VwbXFJalByV2JHaUUwNk5UdUgxcGR2TlNJaDNEaWtpaTdEL0FLeXJnUEZVVU9IelZsWHpXMGRp QjdWWGs2bXBtTlJOVEFnWVV6dFV6TFVUY1pxR0F3OUtpYW5NY1V4cWdwRVRkYVRtbkVFMGdGVFla TEFPdFg3UWdLM0hlcVVTNEpxekN3VUhOYVEwRXk0VFVNbEtHRk5ibXRMM0ZZZ1lWR1JVNXhVVENz MmdJelREVHpVYkdvWXhqVTJuR20wZ0NwRSs3VVk1NlZLb0lXaGJnWHJjNGpGU0dxMGJoVkFxVU54 V3lZckZBeXNUM284MXZXbzZLeHVVU2lWdldqY1RURkZQQXBpYUpGcCt4V3FNVklwOTZZaFJBcCts Tyt6TDZWSkdhbkF6V2lRRkpyY2VsTTI0T0swQ250VktVWWtOS1NzQkcwcENrRHJUZlBiMXFKajh4 cHZlczdqTEhudWU5T0V6RGlvRnFWUlRUQWNoNTVOU3AwcU1ERlBXcVFoL2tyVGhicDZVTFU2Q3Fz SWgrekxURER0Sk9Ldll6VWNxNFJ2cFQ1UUtsTmFjN2VLVWZkcW16VkRkaWl6OW9hbEU3azlhcXJ5 YWxXcHVCTjVyRVlweWRLWW9xVmVLb1JJb0RKZ2lnUXJTS2FrVTFkZ0VGdWhwMzJkUlV5MC9IR0ty bEV5a1lkbk5KdTI4MVpsR0Z6Vks0UHlpcGFzQXB1R0hlayswdFZRdGswOWV0Wjh3eTBKM05CZG03 MUdvcVZSVjNBa1hyVC9MVnVvcGdxUlRUUWdFQzlLWDdPdFNMMXFRQ3JTQmxjd0RGTTI3VGlycEZW WkIrOHBOYUFmUVdnZjhnK0gvQUhCL0tzN3h0L3g1MmY4QTExYitWYU9nL3dESVBoLzNGck84Yi84 QUhuWi85ZFcvbFhNVWNwcVAvSWphRC8yRmwvOEFSNzE3bkY5MFY0WnFQL0lqYUQvMkZoLzZQZXZj NHZ1aWtNa3BhU2lnRG12aUQveUl1cGY5c3Y4QTBhbGVHVjduOFFmK1JGMUw2UmYralVyd3lnQXBE UzBsQUNVbExTVUFKUlJSMm9BYWFROUtVMGxBQ1VsTDNwUFdnQkRUYWQycE85QURsNlZJdFJqclVx aW9ackV2V25hdHkwckV0UjByYnRPMWN0VTliQ0d0SGpZS0RRbjNCUWE0ejJZN0NIcFREVHpVYlVE WXcxV21OVGsxVm5OVWpPYjBLVXg2MW5UdDFxM08zV3MyZDY2SUk4MnRJcDNCckxuNjFmbWFzK2F1 cUI1VlpqNGF2UW1zK00xY2lOUlVSakUyckZzR3VvMDl1bGNqWk44d3JwYkIrbk5lTmpJblpTWjE5 bS95Vm9SdFdMWnlmTFduQzlmT1ZvYW5vUVpveG1wS2hoT1RVOWNNdHpkQ0dtUDBxUTB4K2xTTXBT cm1xTThlVk5hVWkxVmxUNVRYUkNWak5vNWkrajYxek4vRjFyc0wyUHJYTjMwWFhpdlp3c3pqcXhP VHVvOFpyRnVseG11bHZJc1pyQXZFeG12b01QSzV3MUVZY24zalVacWFVZk9haUlyMGtjbzAwbEth U21BbEpTMGxBQ1VocGFRMEFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUF2ZXJGbi9yYXI0cXpa RDk3VXorRmpqdWRmcGZVVjJlbWRCWEc2V1B1MTJlbWo1Ulh6R1BQVW9IUVczYXRpMjdWajIzYXRl MjdWODVYUFNwbWgyb29IU2l1RTJHdjkycUV6WXE5Sjl5c3E1ZkdhMnBLN0lrVlo1TVpybTlTZnJX dGN5NEI1cm5OUmx6bm12WXd0UFU0NnNqbk5UYnJYTlRINWpXN3FMOWE1MlZ2bU5mVVlXUHVubFZY cVY1S3F2MXF4SWFydDk2dlJnWU1BYWNHcGxGYUprTkdoYlBqRmE5dEowckNnT0swb0pNWXIwTVBV c2NsYUIwTUVuQXE5QzlZVUUzU3RHQ2Jwelh0VUtwNWxTbWJjUjRxVE5VSVp1T3RXRmt6WHB3bXJI RktKWkZCcU5XcCthMVJMUWJhamtUNWFrcEgrN1EwQ1owdnd3VGI0cHVUL3dCT2JmOEFvYVY2emoz cnl2NGFEL2lwcmovcnpiLzBOSzlVeDcxOGRtcXRpV2ZSWUIzb2hRYVB6cGE4MDdERjhXLzhpZHJQ L1hsTC93Q2dtdlBmRXY4QXFQQ24vWGwvN1JTdlF2RnYvSW5hei8xNVMvOEFvSnJ6M3hML0FLbndu LzE1ZiswVW9BcG9Qa0ZhZWcvOGhpTDZOL0tzeFB1Q3RUUWYrUXhGOUcvbFZQWVJsL0ZFN2RKVnZR RS8rUHBYa3F6YnVEWHEvd0FWV3hvdjRFZitQcFhqaU55S3FEQmw3dmoxcHkyNDcwa2ZMREZXZ0sx U0pJUHM2MDAyNmVuRldUakZSTlRzQkVJMVU1SGFtdHdhZXhxTTFJRVRPeXZrVWVld0ZLd3FKK0tt NHh4dVg5YVQ3UzJlcHF1MU1CeFU4d3krSlBNbzh2ZWFndHlDMVhvRjVOVkhVa2FMZGNVZlowNllx empGTWFyc01ybUJCU2JRdlFVOWpVWk5TQkczU21CMldwRGlvbXFRQTNEMDM3UzlNWVZDZUtpNHky dHdhZG5JcWtHcTVIeW9xa3dzT1NISnpqaW4vWjE3aXJLTHhUbUdCeFYyRVZQczZDbW1GS25icFVM RTBtZ0dTZEFLaWJxS2UxTk5TQ0VNcmltK2UvcnhTTlVScWJsRXZudFRoTHU0cXZpblJqNXhSY0Nl bnJDTThqaW1qN3dxNkY0RldsY2tyZloxOUthWUZxMmVsUXZUc0JENVNyelRHNjA5alRDTTFJeU1r aHMwb2xiMW9ZVXpGU01iU2Q2V2lwQWV0U0FWR3RTRHJWSVRGcHdOTjcwOENxRVR4VlpYOGFyUmRS VmxhMFFoeCs3V2ZMOTgxb0hwaXFFb3hJYVV4b3BOOTQwbmVsYjd4cEt3ZTR4NjFPdFFJT0ttV3FR RDZVVWdOT0ZVaEVpMVpTcXlkYXNwV2tSRXdxT2YvVnQ5S2tXbzV4KzdiNlZUMkFvbXFMQVpxOGFv dDFOWVNLUXExT2xRS00xT2xKQXlaYWVPdE1Xbjk2dEVqaDFxUktpQTVxVktzQ3duU3BSVVNEaXBS Vm9USVovdVZuM0FHd1Zvemo1S3pyZzRRZGFtWXlwM3FWRHpVTlNvTUhOWUlwYkZsQlVvRlJKVW9y VkVzZDNwdzYwMENuQWMxUUVxVk12V29rRlNyMXEwQS90eFZXWDc5V3UxVlpSODRwUzJFajZCMEQv a0h3LzdpMW5lTnY4QWp6cy8rdXJmK2cxbzZEL3lENFQvQUxBL2xXYjQzLzQ4N1A4QTY2dC9LdVVz NVhVZitSRzBML3NMTC82UGV2YzR2dWl2RE5SLzVFYlF2K3dzdi9vOTY5emkrNktReVNscEtLQU9h K0lJL3dDS0YxTC9BTFpmK2pVcnd5dmMvaUQvQU1pTHFYL2JMLzBhbGVHVUFGSlMwaG9BVHRSUjJw S0FEdFRhWDFwS0FFTklhV2tvQVNrcGFTZ0JEVGFkU1VBUFdwVkhGUktLblZhemtiUVJkdFIwcmF0 ZTFZOXFPbGJOcU1WeTFEMXNLalVUL1ZpbE5JdjNCUlhJZXl0Z1BTb21xUTlLaGMweE5rYkdxZHdh c3UxVXJrMWNUQ285RFB1RzYxbFROeWF2M0xkYXlabTVOZFVFZVRYa1F5dFZLV3JFalZWa3JvaWVk VVk2T3JVYlZVVTFPaHFab2hHclp0ODFkSFl2MHJsYlIvbXJvTE9UR0s4dkZRT21renJMT1Q1Uld2 YnZYTjJjdkE1cmJ0Wk00cjU3RVFQUXBzM2JjOUt0VlN0V3ppcm1hOG1vdFRxaUthYTFMbWtyTmJs a1RMVUVrZnltclJGTWNmS2FwTVRSejE3SDFybmIyTHJYVjNpZGF3THlQclhxWWFaeTFFY2pmUll6 WE4zcWRhN0MvaTYxekYvRjFyNkhDelBQcW81aVlmT2FoSXEzUEVmTU5WbVhGZTFGNkhFMFJHbTA5 aGltVlloS1NscEtBRXBEUzBob0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDbEZKVGxGQUM0cTFaRDk3 VmNMVnl5VDk3V2RSKzZWRmFuVjZXUHUxMldtamdWeUdtSjByc3ROWGdWOHhqbWVwUU4yMjdWcjIz YXNtMkhTdGUzN1Y4OVhQU3BsNGRLS1ROR2E0amJRWk45dzFpWGo0eld4TzM3czF6MS9Kak5kV0dq ZG1WUm1SZVRZelhPWDB1YzgxcVgwM1htdWN2SmM1cjZIQzB6emFzakp2M3ptc0tSaHVOYWw0K2Mx alNOOHhyNkdoR3lQT3FNWTVxQnV0U3NhaU5kY1RJU2lpaXFFVFJ0aXJjY21Lb3FhbFZxMmhLeG5P TnpXaG01NjFvd1RlOVlFVDgxb1FTNHIwS0ZVNHFsTTZHR2JqclZ5T1ROWWNNM3ZWK0tldlhwVlRn cVV6V2piTlRnMW54VENySW1IclhvVTVxeHlTaXl3RFNucFVJbEZQOEFNRmFwb2l6T3crR3E0OFIz SC9YbzMvb2FWNmpYbDN3Mk83eEZjZjhBWG8zL0FLR2xlcFlyNUhPUDk1Zm9mUVpmL0JFb3BhU3ZM TzR4dkZ2L0FDSjJzLzhBWGxML0FPZzE1NTRsL3dCVDRVLzY4LzhBMmlsZWgrTHYrUk8xbi9yeWwv OEFRVFhubmlYL0FGUGhQL3J6L3dEYUtVQVZFKzZLMDlCNDFpTDZOL0tzeEI4bzVyVDBLUklkV2lk NUVSUUcrWnlBT252VlBZUmovRmIvQUpBZ1ArZnZKWGpjUSthdll2aW5kUVQ2S1JGUERLY2MrVzRi SHpwNlY0N0h3d29RR25HY010WEJ5S3BSL2VXcmk4Q3VtT3hMRWFvWHFacWdmdlFCRWMwMm5IaW0x SURXcUY4Vk0xUXZVTVpXZjJxUHZVajlhanhXWTBXTGI3MWFWdjNyTnR2dlZvMjQ0TmFRRXl5UlVM MU1UVVRpdFdJclAxcU0xSzQ1cUkxbXdHbnBURFQrMU1icFVzWkM5UXQxcVo2aGJxYXpZMElLdVEv ZFdxWUZYSXZ1clZSQTBvdnVpaDZJK0ZvWTF1dGlTQ1ROVjJxeEo5YXJ0VU1ZdzBoKzdTbWtQU29Z SWphb1c2MUsxUk4xcUdNUVU2UDc0cHRPaisrS0VNc0Q3NHJRVDd0Wi93REVLMEVHRnJXQkkxaDFx dTlXV3FzOU5nUU5UYWUxTnhXWXhwcGg2MDg4VkdldEt3RGVsSGFwZklOS0lHUGVsWUNJVklwcHdn YWtNWlhtbllCNHFRQ294eFRqTXExUWlkT0ttVTFTRnhqcFMvYXFwU0N4ZFp1YXB5SExuclRXbko2 VVp5S0c3Z1ZpUG1QRk43MWJNVzRjVW4yWW5waXMzRW9nVTFJcHA0dFdCNjA3N09SelRzSVJUbXBF cU5WSTYxSWpCUWMweEVxam1wa3ptcW4yZ0RtbEYwUFNyVEN4ZXpnVkhJMlkyK2xWeGRlMU1NcFov YW56QUhXcWhUazhWYzdVTkRrREZSYTRJcEx3YWxVMVA5bXBSYk5TVVJqRk5TTHlhVHlHRktvSTYx VmhFaWlwVnFKWFZWcEJjcm1xQXVMVHljVlMrMUQwbyswNXFsS3dyRmlRa29lYW96ajVLa0VwWnZh bmhRM0JHUlV2VVpubGNVNWVEVm8yMmFVV3BxT1FDSlQ2Vkt0TDltT2FERXkxU1RFUEZTcUtpSEZL WlF0VWhsaFJUeFZRWEtpbkM2RlZjVmkwV3FDUS9NS1laODBnTzZrMkZqNkYwRC9rSHcvN2cvbFdi NDMvQU9QS3ovNjZ0L0t0TFFQK1FmRC9BTGkveXJOOGIvOEFIbFovOWRXL2xYTVVjcnFQL0lqYUYv MkZsLzhBUjcxN25IOTBWNFpxUC9JamFGLzJGbC85SHZYdVVYM1JTR1MwVVVVQWMxOFFmK1JGMUw2 UmYralVyd3l2Yy9pRC93QWlMcVgvQUd5LzlHcFhobEFCU0dscERRQWg2VWxLYVR0UUFVMm5VMmdC S1R0U21rTkFDVWxMU1VBSmlqRkhhbEFwRFJJZ3F3aTFGR0t0eHJtc3BNNnFTTE5zdkFyV3RoMHJP dDE2VnFXNHhpdVdvZXJoMFgxKzZLV2tYN29vUDQxem5xTFlRMUE1cVltcTBoOTZFVElnYzFSdUdx MUkxWjF5OWJRUngxWmFHZmN0MXJLbWI1alYrNWJyMXJLbGI1elhYVFI0OWVReHo3MUF4cDdOVVo2 MXNqamt4UlVpdFVJcGM0cE5DVE5DMmZtdHkwazZWemx1MkRXdmJTZEs0Y1JDNXZUWjFGcEwwNXJm czVNNHJrYlNYNWhYUldNdlRtdkN4Vk03cVVqcTdOdW1LdjVySXNYSEhOYWdZZXRlQlZqcWQ4SG9T aWltcWFkWE95d3FOaHdha3ByZERTR1pWMHZXc1c2anptdWd1RnpXVmNSWnpYZFJsWXdtamxiK0xy WEwzOFhXdTF2NGV0Y3hmdzlhOTNDVkRocXhPT3VZc09lS295SlczZFFuY2VLekpveUs5K2xPNk9H VVROa0dLanFlWVlOUWZoWFVqSVNrcGFTbUlTa05MU0dnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtr UVpxTTFORU0wbU5FeUpWNnlqL2VkS3J4SWEwN0tJK1owcmxxeTBOSUxVNkxUVSs3WFg2Y3ZBcm1O TmpQRmRicDZjQ3ZtY2JJOVNnald0eGpGYXR1T2xaMEM5SzBvQlhnMW1kOEMwZWxNTFlwekhpb0hj RHZYUEZHdHlPNWZFWnJtZFJrNjF1M1VnOG84MXl1cFNqbm12UndrTHM1cTBqQjFDYkdlYTUrNmx6 bm1yK3BUZGVhd2JpV3ZxTU5TMFBLcXlLbDAvV3N0anlhdDNENXpWQmp5YTllbEd5T09iQW1tSHJT L1drcllnS0tLS1lDZzA4R282WE5OTVZpZEd3YXVSU1lyTlZzVk1qa1Z0VG5Zem5DNXJ4VFlxN0ZQ NzFncExWdUthdTZsWE9XZEk2Q0tmM3Ewcy92V0RGUDBxMmsvdlhvMHNRY2M2UnNyTjcxTXN2dldR azN2VmxKZmV1dUZZd2RNOUYrR0RidkVseC8xNXQvNkdsZXIvblhrUHdwZmQ0bXVQOEFyemIvQU5E U3ZYcStmelIzcjNQV3dLdFNGcEtPMUxYbkhZWXZpNy9rVHRaLzY4cGYvUVRYbm5pWC9VK0Uvd0Ry eS84QWFLVjZINHUvNUU3V2YrdktYLzBHdlBmRXYrcDhLZjhBWGwvN1Jqb0FwcDkwVkJlM01WcmJT eVRXcVhVYW9XYUNSdHF0OVQrdjRWT2crV3NuWGVkUHVGOVluSC9qcHFoSElhN3JObmYyNWp0Tk50 N0xkd2ZLa0xidVFmNlZ6NkpoaFZ2N0xnMDVZQXRhS0FyaXB3UWF0QnFxRTdhUlp5SzBUc0l1RTFF MktoTnpTZmFWb3VnSGtWR2FVVHF4cENjbjJxYmpJMk9EVVRHcGpHek5SOW1wV0FwTUtSVnlhdW0w UFdrK3pZcU9VQ0dBWWVyMEp3RFVSakNDbUZ5cEJGVXRBTCs0SHZURzZWV0Z6aW1tNkE2aXI1Z3NT c0tqWVVuMmdIdFNpUU5rVklXR0dvV05Ta1pwQkN6Vk5nS3pWSGlydjJaalRUYTRxZVFaVUMxYWo0 VVU1YmJCNW9JSXpUVWJBWEVmQ2ptbnNjMVFFeFUwNzdUaXRGSVZpZCtSVVRDbUc2Rk4rMEJxbTRB d3hUR3A3TURqRk1aU3hBcVJrUlBGUm5yVm43T1NhVDdLYWx4R1ZxY25FZ3FiN09SVHZLQ3JudlFr SU0vTUt1SytCVkkwTE1WNjFTZGhGNW1GUXNLaCswMGh1QWVDS2ZNRmh4NlZHZURTK2NwcHJFRTFJ eGpWSG42MUxzTEhJQnBmSWFpd0V5bXBrSE5WMTYxWWpxa0prdXlvblRqcFZoYVNYaGZ3cW5zQm1P Zmx6VVBhcG4rNVVOWXNhRDJwd3BuZXBGb0dPVVZLdE5BNXAyS29USkZOU3B6VUNtcGtxa0luVVU0 cm50UW5JcVVEaXRFSXBUamFCVlNac2JhdTNYOFByVkNjZmRyT1l5TXRTcjFwbFBTczdqSlZIclVp am1tcU0xS0JWaUNwa05ROTZrVTFTRVRxY252VWdHYWhTckNEaXRFREVaUGFxMG93K0t2ZHFwM0gr dC9Da3dLVXpZZjhLaXp6VHJnZnZEOUtpSFdzR3lpVWRhbFVWRWxXRnFrSWNveFVpbm1taW5kNnNS S3BxVlJVQzlhblRwVm9CNEZJeS9LUmluaWhqeFZXRVVYNERWVVo2dHlqNVdyUGJnMWhJcEQxUE5T cU9haFNyQ0NoREpGRlNLTURGTlVWYXN4L3BzQS82YUwvQURxMEk5KzBIL2tIdy83Zy9sV2I0NDRz N1A4QTY2dC9LdExRZitRZkQvdUQrVlp2amovanlzLyt1cC9sV0F6bGRSLzVFWFFmK3dzUC9SNzE3 bEg5MFY0YnFQOEF5STJnL3dEWVdIL285Njl5ais3U0dTZDZYNjBsTFFCelh4Qi81RVhVdisyWC9v MUs4TXIzUDRnLzhpTHFYL2JML3dCR3BYaGxBQ1VHaWcwQUoycEtXa29BU2t4UzBsQUNHa05MMnBE UUFsSlMwZ29BVURpbEE1b0FwNnJ6VXMwaWllSk0xZmlqcXRBbGFVRWVjVnp6WjMwWUVzTWVPMVg0 VnhVTWNlQlZxTmE1cE05V2xDeE9QdTAwbWwvaHFOeldSMTlCck54VlNWNm1adUtvenZ5YXVLTWFr dENHYVNzNmVUclVzOG5XczZhU3VtRVR6SzFRZ3VIem1zNlEvTlZxWnV0VW5QTmRNVWVaVmtNTk5O S2FhYXRHQWxHYURUU2FBSjRUelduQkpqRlpFYllOWElueFhQVmpjMGl6ZXRwc01PYTZHeG42YzF4 MEUzekRtdDZ5bjZjMTVXSnBhSFZUa2R0WXo5T2ExNDVzOTY1U3luNmMxdFFUWnh6WHoySXBhbm9V NUczRythc2pwV2RBMmNWb0w5MFY1dFJXT21MRnBEME5MU0dzaWlwS3Vhb1RSMXB1dWFydkhtdG9T c1EwYzVmUWRhNXErdCt0ZHJlUTlhNSs4dCt0ZXJocXB5MUlIRTNkdHllS3hybURHYTYrOHR1dkZZ RjVCak5lOWg2MXpocVFPWnVJOFZVSzRyVHU0OFZSWmNWNjlPV2h5U1JXSXB0U01LanJVZ1NrTkxT R2dBb29vb0FLS0tLQUNpaWlnQW9vcGFBREZXcmRNNHFzQlYrMFhPS3pxT3lLaXRTOWJ3NTdWc1dW dDh3NHF0Wnc1eFcvWlczU3ZKeEZXeDEwNEdqcDhHTVYxRmhGd0t5YkdER0s2T3ppd3RmT1l1cGM5 S2pFc3hKaXIwUXhVQ0ppckNERmVWTjNPdElXWnNDczZlYkZXN3BzQ3NPN214bm10S05PNU0zWVpk M1h5SG11WDFHNHpubXI5NWM4SG11YnZyak9lYTl2Q1VOVGhxMURLMUNiT2VheFpucTFmVFp6V1hK SlgwZENuYUo1dFNXcEZNMmFxSHJVOGpacUExMnhSZ3dOSlJSVmlDaWlpZ0Fvb29vQVVVNEdtVW9O Tk93RXltcDBlcVlOUFY4VnJHZGpOeE5GSmFzSk43MWxDV3BWbTk2NklWckdNcVpzSlA3MVlTZjNy RldlcGxuOTY2b1lnd2xTUFd2Zy9MNW5pdTZHZitYRi93RDBOSzlwNDlhOEorQ2N1L3hqZGovcUh2 OEErakk2OTJyaHhjK2VwYzZzUEhsaFlPYU0wZHFLNVRjeHZGMy9BQ0oycy84QVhsTC9BT2dtdlBQ RXYrcDhKLzhBWG4vN1JTdlEvRnVQK0VPMW5IL1BsTC82RFhubmliL1UrRS8rdlA4QTlvcFFCVVQ3 b0ZaT3QvOEFIcE4vMXpiK1ZheUQ1UldUcmY4QXg2VGY3amZ5cTF1STRWcWpKcHpHbzJyZGtqRHpV YkNwZTFOYXBBcnR4VUxIQnFhVDJxdXhyTmpRNVg0NjFiUnR5Vm5BODFmZ0JFZEVXRExzYTRVVS9i eFJGOTJuTU85Ym9sRVI0cU5qaXBIcUJxa1kxc21vbkZQTklha1pBd3FKdWxUdlVEbkZRd0k5eHpV aXY4MVJIMnBZeGx2eHFVeG1oR012aXJRWG1xOEovZUNydkZieEpJbUZSTnhVekRpb0hvWURHYW9q elRtTk03Vm14M0kyRlJNS25ZVkU0cVJrSjRvQngwb2JxYVFWSXllRTVCelZxQVpCeU0xVWc3MWZ0 TVliNjFjU1NVTFRHNEZUbW9KSzBBaFkvV29tUEJwN0dvaWFoZ0llbFJrQ3BPMU1OU01qSXB0SzFK VUREQnFSZnVWSFVpZmRwb0dXNFZ5Z3FVSnhUYmY3aTFPQld5SktDMVlqcUJSaXA0NmxBV0ZwazMz Zndwd1BGTWQvbE5XOWhHZko5dzFEVXovZE5RaXNHVWhPOVNLS2o3MUl0SVpNUGFscGltbmpyVmlI RHJVcVZHdFRKVklSWWo2VktPbFJLZUtmdXdLMFFpcmRaNHFqUDJxL2RFa0NxTTQ2Vm5JWkJUMXBt S2V0WjJLSjBxVVZDcHFSYXNsanU5UFdtVklvcWtJbGpxd2xRSUttV3JpQkoyNzFUdVA5WitGVzky S3FUOHlVNUFVTG5pUS9Tb1IxcWVkY3lFMUZqQnJCbExZa1NyQzFBbFRLYWFFeVVDbkNtS2FrWDNx MEljdldwMDZWQ3RUSlZvQ1VVUDBwS0dhcVd3aWxKamExWnovZXJTbEdWYXM4cHpXRWloVXF5bFZs NE5Ub2FTQXNMVm16L3dDUDJEL3JvdjhBT3FnTldyUC9BSS9JUCt1aS93QTYwRWZRR2cvOGcrSC9B SEIvS3N6eHdQOEFRN1AvQUs2dC9LdFBRUDhBa0h3LzdnL2xXWjQ0L3dDUE96LzY2dC9Lc0NqbGRS LzVFYlF2K3dzUC9SNzE3bEg5MFY0YnFQOEF5STJoZjloWmYvUjcxN2xGOTBmU2tNa3BhU2lnRG0v aUQveUkycGY5c3Y4QTBhbGVHZEs5eitJSC9JajZsOUl2L1JxVjRZYUJnYVNscE8xQWhLU2xwTzFB QlRhZFNVQU5OSlMwVUFOeFNxdEtCVDBYbWtVa0tzZFNwRnp6VWtjZFdvNHF5bEk2cWRPNHNFWFN0 T0JLZ2hpclFoVHZYTE9SNmxDblllcTFJdkZHM0ZKV0xaM0pXSHMyQlZlUjZjN1lGVTVYcHhRcHpz RWt2QnFoUEwxNXBaWmFvVFM5ZWEyaEU0cXRVaW5rNE5VSkdxV2FTcVR2WFRHSjVkU1kyUTlhck4x cVZ6VUpyVkhMSmpUVFRUalRUVEpHbWtOT05OTkFBdFRvMVZ4VDFiRlRKRFJlaGZEam10cTBteGl1 Y1I4TlduYnpZNzF4MTZkMGJRbFk2Nnp1Y1k1cmJ0Ym5welhHVzF6akhOYlZuYzlPYThURVVEdHB6 T3p0YmpweldySE5sUlhLMmMvVG10cUdiS2l2RHIwck03cWN6VUQwK3FjYjV4VnBEeFhES05qWk1S aFRHV3BTS2FSU0daMTBtYzFpM1VPYzEwVXlack5uaHptdXFqVXNaVGljbmVXM0I0cm5yMjE2OFYz RjFiZktlS3dMMjE2OFY3T0dybkhWZ2NKZTJ1RDByTWt0OFYxdDVhOWVLeDU3ZkdhOTJqWHVqaG5B NTZTTEZWeW5OYXM4V0tvT3ZKcnZoTzZNR2l0aW1tcFdXb3oxclVnU2lpaWdBb29vb0FLS0tXZ0Fx Ulk4MHhmdlZkaGp6VVNkaHBFYXdaclVzYmJweFNRd1pyWnNiYnB4WEhXcldSdENHcGJzclhweFhS V2R0d09LcTJOcjA0cm9iVzJ3bzRyNS9GVnowYVVDVzBoeGl0eTFUQzFUZ2h4aXRPRk1MWGkxcDNP Mm5Hd3U3YlNlZmlvcG0yNXFoTlBqdldVYWZNVzVXSnJ5NjRQTmM5ZTNYWG1wcnk2NjgxenQ3ZGRl YTlQRFljNWF0UWl2THJPZWF3YnVmT2VhZmRYV1dQTlpOeFBuUE5lL2g2Rmp6Nmt5cmR2bk5VR2JO UzNFbWMxV0o0cjFxY2JJNUpQVVJxanB4Tk5yVkVCUlJSVEFLS0tLQUNpaWlnQW9vb29BS0JSUlFB NFU0R21Vb05VbUt4TUQzcVJXeFZjR2xEVm9wRU9KNng4Q216NDF2UDhBc0hQL0FPaklxK2dLK2V2 Z0syZkhGNlArb2JKLzZNaXI2RzVxSnU3S2lySVQ2VVVmU2lvS01ieGIvd0FpZHJQL0FGNVMvd0Rv SnJ6enhOL3FmQ2YvQUY1LyswWTY5RDhXL3dESW5hei9BTmVVdi9vSnJ6enhOL3FmQ24vWG4vN1JT Z0NtbWR0Wld0Zjhla3YrNDM4cTFrKzRLeWRiL3dDUFNYL2NiK1ZXaEhCc0tqTlN0VVpyZGtqTzFN YnBUNmpZMUlFTW5wVlpxc3VhcnNLelkwUmdjMWZoKzVWTUthdVFydGpvZ012eEE3YWtOUnh0OHRQ SjRyY2tpZW9HcVo2aUlxUUlxUTA0MHhxbGdSdFZlUVZPeHFGNmhqUkNhZEY5NGZXa3htbkl2empQ YW9TMUdhRVArc0ZYaDBxakVjT0t1QnMxMFIySkVZOFZXZXJEZEtnY1VNQ0JxVHRUMkZNNkNvWXhq ZEtpYnBVakdvbXFHTWliclNVcEZJQlVESm9POVhyWG8zMXFqQU90WGJac0J2cldrQ1dXelVEMUp1 elViL2pXckVWbXFNMU0xUkdzMk1iMnBwcDJNMHcxTEdSdFRhVTBsUUFWSW5TbzZrVDd0TkRMMXY4 QWRGV0tyUU5pTVZOdTk2MlJMS1ljQ3BCTW83MVFCb3JQbUhZMFBQWHNhamFZRGlxZ3B3WG1qbUJv bEs3cWpNUkhRVktwcVVHaTF3UlQ4dC9TbkNOaDJxOG9CcVRZQ2Fya0F6dHBIWTFLdlNyVFJBbnBW ZGwyc2FUVmdIakFGT0VpanZWTjVDVGltYnptbGV3R21zeWp2UTA2a2RhelZPT2xQR1Nhcm1FV1hs OHc0cU14N3g5S0ZxUk9LTndLM2tuMHBSRTM5MnJ3eG1wRkFvNUF1VUJHNDdVcWdodWVLMFBMR0tp a2pHMG4wcXVXd1hJTzFUQWhldFFqMXFCM0o3OFZON0RzWHhLb1BXbmlaZldzb01UOUtlcElQV21w aFkwV21YMXFGbjN0bW9BS2xYZ1U3M0pFYUxkelVSZ2ZQSXEybjNhbEZMbHVNb0NGaDJwNFJoMnEr Qm5pbDJjZEtwUUFvcm5kNlZNbldueVJqR1JWZVI5aThVYkFXZHlyM3B5eXI2MW1HVDNwUTVOTG5D eHFlY3ZyVFRPQm5ITlVRVDcwOERKcDh3aVlqY01WQzBHT2dOVENwVm90Y0NpSUQvZHA0aWJIU3J3 RlBDalBTbW9BVUFyRHRWdXgvd0NQdUQvcm92OEFPcEdUMnB0c20yK2cvd0N1aS96b2FzZ1BmdEEv NUI4UCs0UDVWbStPUCtQS3ovNjZ0L0t0TFFQK1FmRC9BTGcvbFdiNDQvNDhyUDhBNjZ0L0t1Y281 WFVmK1JHMEgvc0xMLzZQZXZjb3Z1MTRicVAvQUNJMmcvOEFZV0gvQUtQZXZjby91aWtNa29vb29B NXp4OE0rQ05SSHRILzZOU3ZEMmpOZTZlTjEzZURyOGY4QVhQOEE5R0xYakx3MUxkbWF3cHVVVFAy R2tLR3JoaXBqUjBjeUIweXJ0TklWcXdZL2FtbEtkeGNoWHdhTnRUYktVUjBYRGtLMncwb1ExWkVk U0xGVTh4U3BsUVJtcFlvam1yU3dWTkhCVU9SdENpN2pJb2pWNktLaUtIRlcwajRybm5JOUNsU0NO QUt1UmdDb1F1S2tCeFdMTzZDc1NNUUtpWndLYkkrS3F5UzR6elNVUnluWWtsa0dLb1R5OWVhSlp1 T3RVSlpmZXRZUU9TclZHVFM4bXFVc21hZExKNzFVZDY2WXhQT3FWTGtjckdxeE5TdWNpb1NhMVJ5 U1kxalREVGo2MDAxUm1OTk5OT05OTkFEVFNVcHBLQUdtak5CcEtBSEtmbXE1QzVGVVIxcWRHeFdj MWNwTTFvWmlPOWJGbGNkT2E1cU9URmFOclBqSE5jRmVsZEc4SkhhV1Z5T09hM2JlNkcwYzF3OXJk WXh6V3piWG52WGg0akRuZFRxSFl3WENtdEdLWlN0Y25iM2ZUbXRhM3VjanJYa1ZxRmpzaE0ydzRO TGtWbnBMbXJLTm11T1VMR3lZNlFBMVZrakJxMDNOUk11YVVXSm1aY1FqWWF3cnkzem5pdXBsanl0 WmR4YjU3VjIwS3RqR2NUakx5MDY4VmlYVm9lZUs3aTR0TTlxeUxpeTY4VjdGREVXT09kTTRPNnRH NXJNa3RYeWE3ZTVzT3ZGWmt0anowcjFxV0swT1NkSTVKN1o2cnRBMmE2ZVd5eDJxbkphWVBTdXlH SXVaT21ZWGt0U2VVMWE3V3VPMVJ0YisxYktxVHlHWjViVWVVMWFJZ3A0dDZQYWk1RE1FTFU4VzdH dE5MYlBhcktXZWUxUTY5aCt6TVpMWjl3clN0clZ1SzBJckhKSEZhbHRZOU9LNXF1SjBOWVVpbGJX YmNjVnUyVnBqSEZUMjFqMCtXdGEzczhZNHJ5YStKdWRkT2tTMlZ2MHJlZ2lVSUtwVzBHM0hGYVNq YWdyeEs4K1puYlRqWW1qMmlyS3lvcTFtTkp0cUY3cmFEelhQN055TmVheFp1cmhSbXNXNnVnTzlS M2Q1MTVyRHU3M3J6WG9ZZkRuUFVxa2w3ZDllYTU2OHVNNTVwMXpkNXp6V1JjM0djODE3ZUhvV09H cFV1VjdtWWx1dFVKSkNhZE5KbHFyTzFldkNGa2NjbVJ5TVRVVk9jMHl1aEdZVVVVVXdDaWlpZ0Fv b29vQUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnRDFUNEIvOGoxZS85ZzJUL3dCR3hWOUUxODdm QVA4QTVIdSsvd0N3YkovNk5pcjZKb0FLS0tLQU1ieGNQK0tPMW4vcnlsLzlCTmVlZUp1SWZDZi9B RjUvKzBVcjBQeGQvd0FpZHJQL0FGNVMvd0RvSnJ6dnhOL3FmQ2VmK2ZQL0FOb3BRQlVYN29ySzF2 OEE0OUpmOXh2NVZxSjkwR3NqWCtOUHVQOEFyazMvQUtDYW9Sd3BkZldrT01jVm4rWWZXcEVsSVBl dHVZVm1UbjJxSWhqVTZqSkh2VXlvQWVCVHRjUlFNVEhxS1o1REhzYTFkZ0ZSbWx5QVo0Z1BURlRx dTBZcVluSGFvejFvNWJESEpLQjhwT0tmNXkrdFZISHpWRXhOSE5ZQytaVjlhWVhVOTZvRjhVMFNI UGVwNXdzWDI2VkM5SkZJV09LbmpUY2FlNEZYWXg3R21HRnY3cHJVQ1k2aWtLaWprQXkvSWJQM2Fl c09UelYxc1V4angwcGN0Z0lnZG5OVExNUFdvVDB4MHFFakZGN0FYVE1wNzBobFgrOVdleHhUTjVw YzRXTkFsVDBOUnQxd0txcklSM3F3RHVVVVh1RmlJZ2s4Q21tTnZTcjBjWUE2Vko1WTYwY3R3TXd4 TjZVaXdzRDByU1lDbzJPS1hJQldXUFlLa1NUeXo5YUhxSmhrMGJETFFuWDFwREt2clZJNUZSa25Q ZWptQ3hlTWlrNHpUV3dWcW1DYWZHNTNZN1VyZ1MxSHllbFM0NXhVNlJBZHFkcmlLSmpiMHBDakR0 V2w1WUZSc0JSeURLSWpZbnBVbTNhS21QU28yNjByV0M0cXk0R000cVlUQWQ2cU5UZW5lbHpXQWJS UlNkNmtaSXRQQTVwaTA4VlNFeHdxUlRVWXA2MVNBbmpxd283MVhpNjFaVVZvaENsZU0xUm0rKzFY MjRVMW55L2VOS1lJcHRuY2FURkszM2pTVmdNZXRUS09haFRwVXkxU0FlQjZVNGNVMGRLVmFwQ0pW TldJNnJvTTFZanJSQ0pnS1pNdUltK2xTTDBxS2Y4QTFiL1NxZXdGSTlNVlNKNTVxNzYxUmJ2V0Vp a09CcVZCVUs4MU9ucFNReVpSVHgxcGkwL3ZWb2tlcHFSVG1vaDFxUk90V2hGaE9ncVFWR25TcFJX aUFobSs0YXo3bklSYTBKdnVWUW4rNEt6bUJUenpVcVZEM3FWT29yRW9zSUtsQzFHblNwUldxSkhD bnFhWjNwdzYxU0FtU3BSMXFKT2xTcjFxMEE3Rk1oR05RdHgvMDBYK2RTSDd0UncvOGhDQS93RFRS ZjUwcGJDUjczb0gvSVBoL3dCd2Z5ck44Y0QvQUVPei93Q3VyZnlyUzBEL0FKQjhQKzRLemZISC9I bFovd0RYVnY1Vnlsbks2ai95STJoZjloWmYvUjcxN2xIOTBWNGJxUDhBeUkyaGY5aFlmK2ozcjNL UDdvcERKS0tLS0FNUHhndTd3cGZEL3JuL0FPakZyeVY0YTllOFZLRDRadkIvdWY4QW9hMTVlMFZj OVYya2VsaEljMU4rcGx0RlVMeDRyVWFHb1doOXFsU0xsU013eDB3cFdpWWZhbUdDcjVqTDJKbjdP YWNzZFcvSTlxZXNOSE1DcEZRUmNWTXNWV0JEVDFqeFdia2F4cEVhUTFPa05LcTFLT0t6Yk9tRUVo eVJDckN4OFZYRDRwM200RlE3blRGcEVwQUZNTFlxQjV2ZW9IbTk2T1VUcUpFc3NtS29UUzR6elJM TjE1cWxMTDFyV01EbHFWUkpacXB5eTlUUkkvTlZuYXRveE9DcFV1TWtrcUF0VG1OUkU1clZJNXBT RVkxR2Y2MDgwdzFSbUlhYWFjYWFhQUdtbW1uR21tZ0JwcERTbWtvQWFhYWFjYWJRQW5lbkJxWWFN MG1CTXNtS3R3ejR4V2ZtcFkyeFdVNDNMVE55QzV4am10TzJ2T2V0YzNISmpITlhiZWZCNjF3MWFL WnZDWjJWcmQ5T2EyN1c1NEhOY1JiWFdNYzFyMjk3akhOZVBYd3gyVTZoMmNFd1BldEdHUUh2WEhR WC92V3BCZjhBVDVxOG10aDJkY0toMCtRZTlKZ2V0WXkzMmU5VExkNTcxeHVqSkczT2pSWkFWcXBM Q0RTQzR5T3RJWk0wbEZvTHBsV1cxQnJPbnN4eld5ZWFyU1I1cmVGUm9pVVVjM1BZZzlxeTU3RDJy ckpMZlBhcVUxcDdWM1U4UTBZU3BuSHoyV08xWjAxbnowcnNwclBQYXFFdGp6MHJ2cDRrNTVVamtu dGZhcXNsc2ZTdXNld1BwVmFUVC84QVpycmhpVVpPa2MwdHNmU3BGdHZhdDhhZjdVOFdIK3pWdkZJ U3BHSkZhODlLdlEyZWUxYVVkamp0VnVPMHgyckNwaVM0MGlqRFk1STRyVnRySWNWSkhiNHEzR3Uy dUdwV2JONHdKN2F6RmFDV3FyNlZUamsyMU1ibkhldUdmTTJieHNpK2tTaW55YlZUcldVYnpIZW9a ci81ZnZWbXFNbXkrZElzM0VvWFBOWlZ4ZFl6elZhNXZ1dk5ZOXplWnp6WGZSd3pPZXBVSnJ1ODY4 MWgzZDUxNXBMbTZ6bm1zbTVteUR6WHNVTVBZNHFsUUpiclBlcU1zK2FZOGxWM2JOZW5DbWtjemtO ZVRKcGhha2JyVGE2RWpLNEUwbEZGVUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVV VVVBRkZGRkFIcW53RC81SHE5LzdCc24vQUtOaXI2SndhK2R2Z0gveVBWNy9BTmcyVC8wYkZYMFRR QVVVdEpRQmplTGYrUk8xbi9yeWwvOEFRVFhuZmliL0FGUGhQL3J6L3dEYU1kZWllTGYrUk8xbi9y eWwvd0RRVFhuZmliL1UrRS8rdlA4QTlvcFFCVFQ3b3JJOFFmOEFJUHVQK3VUL0FQb0pyWVQ3b3JI OFFmOEFJT3VmK3VUL0FQb0pxeEhsN0dsUmprWXByZGFkRDk2Z0xtakVQbUZYQmlxY1orY1ZjSEly b2pzU0kxUXRVelZBOURBakpwaHB4cHRRd0dzS2djVk8yYWhjVkxHVjI2MHpOT2JyVEt6R2llM09a UHdyU2dIRloxc1BtcS9iOTYwZ0psbkZSTnhVcDZWRTlhaUlYcUpqVWoxRWF6WUNIcFVUVkoycGpW SXlGeFVKTlRQVUxkYXpZMEptcmtQM0JWTVZjaSs2S3FJTTBZd05vcFNLU1BvS1ZxM1JKQTlRTlU3 OUtydFVNQmhwcDZVNDBoNmNWQTBSTlVUZGFsYW9tcUdVSUtkSDk4VTJuUi9mRkFNcy93QVFxK29C RlovOFlyUWo2VnJBa2F3cXU1NjFaYXFyOWFiQWlZMHluTlRlMVF4aUdveU9ha05SMUlEYUtQem8v Q2tNY3RTQ29nS2VEUUprbmVuaW1MVXlpclFpU09yQzFYVTRxVU9CMXEwMEZpVW5pcUV2MzJxdzBv QjYxV2M1WTBwTzRKRlJ2dkdrcDdJY25pbTROWldLSEx4VXkxQ3RQQnhUUWlZVTRERlJxYzFLZ3pW SkNKRUhOV0UvblVLOFZLRFdpRVRDbzV1WTIrbEc4QWRhaWtjRlNNOG1tMkJYTlVXSEpxOVZka0k1 eFdVaWtSTDE2Vk90UmhlZWxQRlNNbVdwQnpVQUpGVEp5TWl0RVNQVVZLb3BpRGlwVnFrSWxUcFVt YWlCeFNsZ0t0T3dDVGZjTlo5ejl3VmNkd1JpcTBveXZTb2xxQ0tPS2tRVXBRanRTcXBGWldLZXhN bFNpb0JuMHFSU2F0RWt3RlBVVXhlZ3FWUnhWb0I2VktLalduWnhWb0NUUEZNaC93Q1FoQi8xMFgr ZElXR0tMWTV2NFA4QXJvdjg2bVd3STk4MEgva0h3Lzdnck44Y2Y4ZVZuLzExYitWYVdnLzhnK0gv QUhCL0tzM3h4L3g1V2Y4QTExYitWY3hSeXVvLzhpTm9QL1lXWC8wZTllNHgvZEZlSGFqL0FNaU5v WC9ZV1gvMGU5ZTR4L2RwREpLV2twYUFNcnhNTStIYnNmN24vb2ExNXkwVmVqZUptMitIYnMvN24v b2ExNTBaeFhIaVBpUFp5KzNzbmZ1UXREVWJRMU9acVkwd3JKWE94cUpXTUZOTUZUbVVVbm1pbmRt ZkxFcitSUUlmYXB2TnBQTm8xRGxpTUVOSVk4Vko1MU1hYjZVYWo5MGFWSXBEeFNOTFVUeTBXSmNr aHpOZ1ZFMHVLaWVVZXRWbms5NnRSTXBWYkU3emU5VjNtOTZnZVNxN3ZXaWdjOHFwTEpOVldTV21N MVF1ZWEwVVRtblVZTS9OUk0xSTNXbUd0RWpCeUVKcGhwM2FtMHlCRDBwcHBUVFRRQWhwcHB4cHBv QWFmV21tbkdtbWdCcHBEU21rTkFEVFRUVGpUYUFFTk5wVFNHZ0JNMDVXeFRLU2xZWlpXVEZUUlQ0 UFdxR2ZlbktjR3M1UVRHbWJjVjFqdlY2Rzl4M3JuVWYzcWRKTWQ2NWFsQk0yak02eUMrOTYwWUwv QU42NCtHZkhlcjBWemp2WG4xY01qb2pVT3lpdnMveFZlaXU4OTY0K0c3eGptdEdDOHgzcnpxdUdO NDFUckk3akk2MVpTVE5jMURmZTlYb3I4ZXRjRlREczNqVU45T2Fkc3pXWkZxQTlhblhVVjlhNVpV NUkyVWtXVEJtbzVMWFBha1hVUjZpaHRSWDJxVkdhSzkwcXlXZnRWVjdIMnE4Mm9EMUZRdGZEMnJh TG1RMUV6M3NQYW9IMC93RDJhMG12bDlxaWE5WDJyYU02aERVU2dOUC9BTm1sK3dlMVhQdGc5cVB0 bzlxdm5xQzVZbFVXT08xUEZwanRVeHZSN1V3M29wWG13dEVUN1BnVTFseFExOE1kcXFTM285YXFN Wk1UYUp5KzJxOHR4anZWT1c5SHJWR2E4OTY2SVVHektVeTlMZVk3MVNuditNYnF6WnJyUGVzK2E1 ejNydXBZWXdsVkwxeGZlOVpjOTU3MVZtbXozcWhMSm52WG8wc09rYzhxaGFsdXM5NnBTelp6elVM TlVMR3V5Rk5JeGNoNWVveTFNL0UwbGJwRVhGSnBLS0tZZ29vb29BS0tLS0FDaWlpZ0Fvb29vQUtL S0tBQ2lpbHhRQWxGT0Mwb1NuWVZ4dEpVZ2lwM2ttbnlNT1pFTkxVMzJlbkMyTlY3T1F1ZEhwZndE LzVIcTlQL0FGRFpQL1JzVmZSWGF2bnY0RVJGUEc5NGYrb2Mvd0Q2TmlyNkQvR3BsR3pzeHAzQ2lp aXBHWTNpNy9rVHRaLzY4cGYvQUVHdk8vRS8rcDhKL3dEWG4vN1JTdlJQRnY4QXlKK3Mvd0RYbEwv NkRYbmZpZjhBMVBoUC9yei9BUGFLVUFVMCs0S3lQRUgvQUNEcm4vcmsvd0Q2Q2ExMCs0S3lOZjhB K1FmY2Y5Y24vd0RRVFZDUEwyRkxHRHVHS2VVSk5QU01ramlyNVFMY1gzbHE0RFZKZUdITldGY0h2 V3NTU1JxaGVuazU3MDF2ZW1CQzFNN1ZLUm1vMkdLaGdSdFVUKzFQYzgxRTJUVWpSQS9YcFRLbUs1 cEFoejByT3d4MXZrTldqYm5yVk9KQ3JkS3N4TnQ2MXJGQ1piUFNvbW9EOFVoSU5hQ0lXcUk1cWRz Vkd3cUdCRWFZMVBQU29tTlFNamFvVzYxTXdwbXpJcUdob2pxNUQ5eGFnV01udFZoUnRVVTRqTkNN L0tLVnFyeHlBZ2MxSnVIcld5Wk5oa25GUU5VN2M4MUdRQ2FsZ1FFVTA4Q251TVZHL0ZRQXhxaWFu bW1FR29ZMEpUby92aW00TlBqVTdnY2NVREovNGhWOUQ4b3FoL0ZWaEpCNjFwRjJKSm1xdXdxVXVQ V296Vk5nUU5US21ZVkV3d2NWRmhqQ1JpbVVySG1tMURBc2lKU2FlSVZwcW1wNCthdElSSDVDK2xN ZUhISUZYUUthNi9LYXJsQW8vZEdhWVpqbWxmN3BxR3M3alEvelc5YWNKVzlhaTcwOWFWeGo5ekdu citOTkZQSFhOVUlrQ2hsMjlxY3NLMHhUVXlWVmhBSUVKNlVHM1dwMUhlbmxjaXJVUU04eGVXYVRm c3F4Y0RBWEZVcCtncUhvQXBuTkFtZjFxdlQxcUxqSnhLNTcwNEVsczB4YWtXcXVBNGZlcWJhckRt b2FrVTFTSkhpRktjTGRjOUtWS21VVlZndVYydHhVV3p5emlyNUdhcXpqRW40VTJyQVFOTHNHQjFx UHoyRk1uT0pEVVhVMWsyVVdoTzU3MDRTTlZkUFNwMXBwZ09Vbk5UcUFUelVZRk9IRlVTU2VXcDdV NFFwbnBTS2FsV3FTQVo1QytsTmFEMHF5QlFWNDRxdVVDa0R0cGp6a0hpbnk4QnMxUkxWbEoyR1dQ dERlOVBFeis5VkZxZEtGSUNYZXpWYXNmK1B1RFA4QXowWCtkVmxGV3JNZjZaQi8xMFgrZFYwRWUv NkIvd0FnK0gvY0g4cXpmSEgvQUI1MmYvWFZ2NVZwYUFQK0pmRC9BTGdyTjhjZjhlVm4vd0JkVy9s V0JSeXVvLzhBSWk2RC93QmhaZjhBMGU5ZTR4ZmRGZUhhai95STJnLzloWmYvQUVlOWU0eC9kRkla SlJSUm1nREY4WE5zOExYcmY5Yy8vUmkxNVo1OWVuZU56dDhIMzUvNjUvOEFveEs4ZTg0MWpVamRu ZGhxbkxHeHBHZW1tYXMvelRSNXRaOGh2N1l2ZWQ3MDB6VlNNdE44MDArUVh0aThacVR6ZmVxUG1V bm0wdVFYdFM5NTJPOU1hZmpyVkl5KzlNYVUwK1FQYkZzemU5UnRONzFVTWhxTXlHcVVETjFpdzB2 dlVMeVZBem1vMmMxU2laU3FrclNWQzcwd3NhalkxYVJrNWppMVJzYVFtbW1uWWk0aHBwcFRTR21T Tk5OcDFOb0FTbUduMHcwQUlhYWFkVFRRQTAwMDA0MDAwQU5OTlBlbkdrb0FhYWFhY2FiUUFocHBw VFNHZ0J0SlMwMDBBRkFOSWFiUUJLR3hUeEppcTJUU2JpS2x4S3VhS1RWWlM0eDNySERtbmlWcXhs U3VVcEcvSGQ0NzFiaXZjZDY1bFptSGVwMHVHOWE1NTRkTTBWUTZ1Tyt4M3EzSHFHTzljZ2wwM3JV eTNqZXRjazhJalZWVHNvOVN4L0ZVeTZsL3RWeHEzcmV0UEY2M3JYUExCbzFWWTdJYW4vdFVwMUwv QUdxNDhYeit0TyszTjYxbjlTUlh0anF6cVA4QXRWRzJvZjdWY3Q5dGIxb042M3JRc0dnOXNkTWIv d0QycWFiL0FONjVyN1lmNzFIMncrdFY5VUY3VTZUN2Q3MG4yNzNybS90WjlhVDdXZlduOVZGN1U2 UTMzdlVadi84QWFybmpkbjFxSnJ0dldxV0VGN1U2SnIvL0FHcXJTWDMrMVdFMTIzclVEM1RldGF4 d2lKZFUyWkwzM3FwTGVlOVpMM0xldFYydUdycGhoa1pPb2FVdDFudlZPUzV6M3FrOHpWQTByWnJw aFJzWk9aY2ttejNxczcxQ1hOTUxHdDR3c1EyU0ZxWVRUYzBWYVFyaFJSUlRFRkZGRkFCUlJSUUFV VVVVQUZGRkZBQlJSUzRvQVNpbHhSdE5Pd0FLZUJTS2g5S2xXTTFVWXNsc1FMVXFwN1U1WW1xeEhD YTZJVTdtTXBrYXhWS3NGV1k0VFZsSWZhdXVGQzV6eXFsSmJmMnFSYmIyclFTRVZNc0lycWhoa1l1 c2RuOEZZZkw4WTNaLzZjSEgva1NPdmRhOFkrRVNCZkZkMWovbnhmOEE5RFN2WnE4ckd3NUt0anV3 MHVhRndvb29ya09neHZGMy9JbmF6LzE1Uy84QW9OZWQrSi85UjRUL0FPdlAvd0JveDE2SjR0LzVF N1dmK3ZLWC93QkJOZWQrSi84QVVlRS8rdlAvQU5veDBBVTArNEt5OWJBTm5LUDlodjVHdFJQdUNz dld2K1BXWC9jYitScTF1STRJd29PMUp0QUhGUGFveWEzSkdIcFVJWmw2Vk5VVENwQWFabkZOODlx YTR4VUxHb2NoMkxLM0J6eWVLbERidWF6dzNOWElUbU9tbmNaT3NPN25GUDhBSVhIU3BZMU8ybmtj Vm9rU1Z2SlQwcHBpUWRxbWVvbU5Ld0RINlZDNXdhbEp6VWJDcFl5UHpYQTYwMHp1TzlLd3FGK0to c0VQKzBObXBGbnp3VFZQTlBSL21IMXBKanNYTnU0NEZTTEF1T2xKRU15Q3JZWEZheFJKWDhoQjJw cGhRVlphb0c0b3NNajJLdlNvMjZtbnNhWWFsb1RJc2xUa2RhUXlzQm5OT05Sc0tobExZUFBidVRR Sm16MU5RbWtIRks0RnZ6TjlPVk4vMHFDRG5OWGJaY2hxdU9vbUlJRlBha01DaXJSR0tqY1ZUaUJY TUtEdFRTQUZJRlBZMUVUVWdOeHhpbzhsT2xTSHBUR3FXQ0dtVnFUelg5YWFhU3BLSkJLd1BOTzNi aG1vYWtUN3ROTUNSWXQzSnFYeVJVa0M1akZUQUFEcFZxSkpSVWMxWmk3VldYclZtS2lJRmhhYkx3 djRVNFUyWGxmd3Ezc0l6WkI4cHFHcHBDTmxRMWd5a0ozcVZhaTcxSXRJWk1CUzAwR25WWWh3cVZL aUZUSlZJUlpqNkNwUlVLZEttQjRyUmJDS2x6MnFoUDBXcjkwT2xVSisyS3ptTWhwNmRLWlQwckla T2xTaW9scVVWYUVMM3B5MHp2VDFxa0ltanF3bFY0eGlyQ2RLMGlBODlLcDNIK3MvQ3JsVTdqL1dm aFRrQlF1UDlZMzBxSmV0UzNQK3NQMHFJY0d1ZDdsRXlkYW5XcTZWWVdxUWlRVTREbW1pbmQ2dENI clU2VkF0VHAwcTBCTUtSdWxBb2JPS3JvSW95L2RhczVoODFhTTNScXoyNjFoSXBEa3F4SFZaT3RX WXp4UWdaT3RXYlRIMjJEL3JvdjhBT3F5MVl0T2IyRC9yb3Y4QU9yRWZRR2dmOGcrSC9jRlpmamtm NkhaLzlkVy9sV25vSC9JUGgvM0IvS3MzeHoveDVXZi9BRjFiL3dCQnJBbzVYVWYrUkcwTC9zTEQv d0JIdlh1TWZUOEs4TzFIL2tSdEMvN0N5LzhBbzk2OXhqKzZLUXlTaWpORkFIUGVPK1BCV29uL0FL NS8ralVyeGJmWHMzajg0OEQ2aWY4QXJsLzZOU3ZFTjlTMGFSbFlzK1pSNWxWdDlHK2x5bGM1WTMr OUp2OEFlcSsrazMwY291Y3NiK0tidnFEZlRkOVBsRG5KeS92VFMxUTc2YVdvNVE1eVV0VEMxTTNV aGFpd25JVW5qdlRDZUtDYWFUVHNUY1EwdzBwcERUSkcwbEx4U1VBTnBLV2tOQURhYlRxYlFBaHBo cC9hbW1nQnBwcHB4cHBvQWFhYWFjYWFhQUdtbW1uR2tOQURUVFRUalRUUUFocHBweHBwb0FiVGFk VFRRQTAwbEthU2dCcHBEU21rTkFDVXVlYWIzcENhVmdKUTFQVjZyN3FOOVM0akxna3A0bDk2b2Va UjV0UTZaWE1hUW05NlVUKzladm5Vbm4xUHNoOHhxQzQ5Nlg3UjZHc243UjdtajdSUzlpUG5OWDdR ZldrTng3MWsvYVBlZzNGTDJJYzVyZmFQZWo3Ujcxa2ZhS1B0RkhzUTV6VyswZTlIMmozckorMGZX ajdSOWFmc1E1elZOeDcwd3orOVp2bjBlZjcwZXlEbUw1bTk2amFXcVhuVW5tMVNwazh4WmFTbzJl b1RKU2JxMFVCWEhzYWpKcE0wbFZZUXRKUlJURUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVV VVVBS0JUZ0tBS2VGcTBpV3hWVE5USkZtbGlUTlhJb3MxMDA2VnpDYzdFS1c5VHBiKzFYSTdlck1k dFhkVHd4eXpyRkZMYjJxd2x0V2dsdFU2MjFka01NYzhxeFJTM3FZUTRxOHR1S1ZvY1YwcWhZeGRX NVNFZUtkakZXR1RGUk1NVStXd3IzTzUrRW4vQUNOVjEvMTVQLzZHbGV5VjQxOEpQK1JzdXY4QXJ4 Zi9BTkRqcjJYaXZuY3cvakhzWVA4QWhCUlJSWENkUmplTGYrUk8xbi9yeWwvOUJOZWQrSi85VDRU L0FPdlAvd0JvcFhvbmkzL2tUdFovNjhwZi9RVFhuZmlmL1VlRlArdlAvd0JvcFFCVGorNEt5OWEv NDlKZjl4djVWcUo5d1ZsYTEveDZTLzdqZnlxMXVJNFJxaU5TdFVacmRramFZdzRwMU5ibXBBZ2Zw Vlp2clZtVHBWWnF6WlNHRHJWK0FZanFoNzFmZ09ZNmNOd05DRS9MVG1wc1l3dE9QU3RrUVF2VUxB MU0vZW9XcVdNanBEU2tZNXBEVXNDTnFyU0RtckRkS2dlczJORUpwMFErWVo5YWFhV1A3dyt0U3R4 bWxGL3JCaXJ3KzdWS0hCa0ZYZTFkRUNSalZYZXJEZEtydUtHQkEzMHB2YW5OVGUxUUZoclZFOVN0 VVRWREdpRnV0SlN0MXBNMUJSTEIxTlg3WE9HK3RVWU85WDdYbzMxcldCTExKNXFDVHBVNXFDVHBX akVWbjYxR2FsYW9pS3pZeEthYWNlbE5hcEdSTlRhYzFOcUFDcEUrN1VkU0o5Mm1obDYyenNBOTZu eFVGdndnTlRaK3Rib2xsSlJ6VTZjZHFwK2R6VHZ0SkhRVm1tT3pMKzdpbzNmNWFxL2FDUlRUSXpI RlBtQm9SaDh0UTFZR1R4U21BSHBVQWl0VGxOV0JiVWZacU9VWkdEelR4UVlDdEtCaW5ZUklvcVpC elZjeUJmclNmYWFwTVJlVTRwNWJpcUF1alFiazFYTUZpYWM1QXFwTU9CVWdjc2VhY3FCeHpVdlVD bGpCcHkxYSt6aWxGcm1wNUJrS21wRlBOUDhBc3VLUXhGR3FraEMxS2dxTURtbGFVTDA2MHdMSzFL cHFqOXF4U2k2elRVZ3N5OFdxck4vcktqTnlXb1Z0M0pwdDNFVjV4bVRwMnFMYnpWL3l3NDVwdjJY bmlvNVJsVmFsVTFPTFNsK3pVS0xBYWhxUWRhajh2YWFrVTdUVkNKRnFWZUtxRzRBcFJkWTZVN2dY UWVhUXNLcWk2cHJURnZwVmN3RG41RFZTWkt1Z1pvTUNtb2NiaktLcnowcVplS25GcU0wNFd2YWhS QWpCcTNZODNrSC9BRjBYK2RWemI3YXNXSXhld0QvcG92OEFPcTZBZS82Qi93QWcrSC9jSDhxemZI UC9BQjVXZi9YVnY1VnBhRC95RDRmOXdmeXJOOGNqL1FyTC9ycTMvb05jNHpsZFIvNUVYUVQvQU5S WmYvUjcxN2hIOTBWNGZxSC9BQ0l1Zy84QVlXWC9BTkh2WHVNZjNSU0dTYzBVVWZXZ0RtdmlEL3lJ MnBmOXN2OEEwYWxlSFY3ajhRZitSRzFML3RsLzZOU3ZEcUFERkpTMGhvQVEwbExSUUEyaWlrb0FR MGhwYVNnQnZORkx6U1VBTlBTa05PcHA2VUFOcERTbWtQU2dCdmFrcFQwcEtBR250VGFjYWJRQTJr NzA2bTBBTjlhYWFmVFRRQTAwMDA0MDAwQU5OTk5PTk5OQUNHbTA0MDAwQU5OTk5PTk5OQURUU0du R21tZ0J0Tk5PcHBvQWFhU2xOSlFBMDBocFRTR2dCdElhV2tOQURUU1VwcEtBRXBwcDFOTkFDR2tw VFNVQUpTVXRKUUFsSWFXa05BQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFV VVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZLS0FERk9DMEFVOUY1cTFHNUxZOUk4MVlTRFBhblF4NXEv RERtdTJsUnVjMVNwWWlpdDZ1d3dlMVRSVzlYWW9LOU9qaHpocVZTS09IaXJDUlk3Vk9zT0JVcXhW NkVLTmprbFVJMVRGS2VLbUNZRlY1T0sxY2JJelR1TDVtTzlSdlA3MVdsa3gzcXE4L3ZYTk90WTNq VHVXM3VQZjlhZ2U0OTZwUFA3MVhhNDk2NDZtSU9pTkU5UStEc3UveGZkai9BS2NIL3dEUTByMjJ2 QnZnbEx2OGFYZy82aDcvQVBveU92ZWE4WEZTNXFsejA2RWVXRmdvb29ybU5qRzhXLzhBSW5hei93 QmVVdjhBNkNhODY4VC9BT284Si84QVhuLzdSU3ZSZkZ2L0FDSjJzLzhBWGxML0FPZ212Ty9GQS9j ZUUvOEFyei85b3BRQlRUN2dyTDFyL2oxbC93Qnh2NUd0U1A3Z3JLMXc3YktZK2tiSDlEVnJjUndy Q295T0taOXBGT0VvYXQ3b213MDlLaVkxS3k1Tk5XRGRVZ1YzcUJobXIvMmJOSjlsQTRxZVZqS0lR NDZWYmlHRTRxUVc0QnpRUmc0N1VjdGdMRWJmTFR5UWFwZVpzTkw5cHErWVJhYkdLaFlWQ2JyRko5 cHpTdUZoN0NvMk5QTHFSeFRDcGZvS1F5Rmp4VVRjMWMrekUrdEo5azRxZVZnVU52dFQwWERDcmYy WUNsRVNyemlseUJjZEZ3NHEwR3FreHdNOTZRWEJIV3RFN0NMckdvbUhGUUc2cHYycWptSFlrWmFq TkFuRE56UVNEbkZTRmlOalVUVk9JaXhwZnN4cWVVWlNJelFCVncydEo5bnhVOG95R0VZelZ5M2JB TlJGTnVNVTNjVWJpcldnbVg5MlJ4VWJkS3EvYVNLUTNKcDh3ckV4RlJzT0tZTG4xcGZNRExVM0dO UFNveWFmNjBMQ1g2MHJBUWtVMzhLdGZaamltbTJwY295dlVpZmRxUVFBYzBqQUE4VVdBc1JQaU9w Zy9BcWdIS24ycHd1RFZxUWl2aWt4UzBWa01jb3B3SE5JdFNDcVFod3FSV3FJVTlhb1JZV3BRS2hq cXd1S3RBTlpQYXFrZ3d4Rlh6d00xUWxPWkRSSUNveDVOTnBXKzhhVEZZM0dQVVZJRnpURTZWS3RO QXh5akZTSlRNVTVhb1JNcDU3MU1nelZkZXRXSTZ0Q0pNVkZLdjdzMVlVVXlmaU5oN1ZiMkFvVlVM OG1yZUtvc09UV0VpaHluTlNxS2hUaXAwb1FNZUY1cVZSaW1xS2YzcTBJZXB4VXFubW9SMXFWS3BN Uk9vNHA1WGltTFVvclJBVjVWd3ZTcWM1d29xL1A5eXM2NUdVRlp6QWdMZWxLcDVxS3BFNjFqY29u VVZLb0ZNU3BWRmFyWVE0VktwcUx2VGgxcWt4RTQ2MDhmalVTZldwbHEwQWhXa2c0MUNEai9sb3Y4 NmxxT0htL2cvNjZML09sTFlTUGZOQS81QjhQKzRQNVZtZU9mK1BLeS82NnQvNkRXbG9IL0lQaC93 QndmeXJNOGMvOGVWbi9BTmRXL2xYS1djdHFIL0lpNkQvMkZsLzlIdlh1RWYzYThQMUgva1JkQi83 Q3kvOEFvOTY5eGo2Q2tNZlMwZ29vQTV2NGcvOEFJamFsL3dCc3YvUnFWNGRYdVB4Qi93Q1JHMUwv QUxaZitqVXJ3NmdBcE8xRkI2VUFKU1VwNkdpZ0J0RkxTVUFOTklhVS9Xa29BU2twYVNnQkRUVFRx YWFBR21rTkxTSHBRQWhwcHBhU2dCcHBEU21rTkFES1NuVTN2UUEybW52VDZhYUFHbW1tbkdtbWdC cHBwcHhwcG9BYWFTbkdtbWdCcHB0T05OTkFDR21tbE5JYUFHMDAwNm1tZ0JwcEtVMGxBRFRTR2xO SWFBRzBocGFRMEFOTkpTbWtvQVNtbW5VMDBBSWFTbE5KUUFsSlMwbEFDVWhwYVEwQUZGRkZBQlJS UlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVTVSbWtx U01acHgzRXg2eDFQSENjMCtLUE5Yb1lLN3FWRzV6VHFXQzNoclR0NGFaREJXakRGN1Y2K0hvSG4x YW9SeFlxMUdsS3NlS21WSzlPblRzY1VwQ2hRQlNGZ0tld3d0VnBIeFdzbnltYVZ5UnBBQlZHZVVV a3MyS3o1NXZldU90WDBPaWxUR3p5OWVhejNsOTZXZVdxVFNWNDFhdHFlalRwNkVqeWU5Vm1jK3RJ ejFFV3JoblV1ZFVZSHFYd0piUGppOS83QnIvK2pZcStnNitlUGdLYytPYjMvc0d5ZitqWXEraDY1 cHU3Tm82SUtLS1BvYWtveHZGdi9JbjZ6LzE1Uy84QW9KcnpyeFIveDcrRS93RHJ6LzhBYUtWNkw0 dC81RTdXZit2S1gvMEUxNTE0by80OS9DZi9BRjUvKzBVb0FxUi9jRlpHdi84QUlQdVArdVQvQVBv SnJYais0S3lOZi81QjF6LzF5ZjhBOUJOV3hIbUpibW5vM3pkYWhhbGpHNXhRZ05KT1dGV1F1S3J4 SERDclk1cm9pU05JOUtqYXBUVUwwQVJzYWpOT2FtMURBamNacUZ4VmhoVUwxTEdRRTRwb2FsZnJV WGVzN2pMVURibXE5QXZlcysyQTMvaFdsYm10SUNaS0Z3UGFtTUttUFNvbk5haUlTY1ZHVFRuUE5S RTFtd0dtb21GVGRxallWSXlCcWpKcVZ4VUpyTnNhRkJ3S3R4OG9LcEFacTVFTUlLcUlGNUUrVVlw eFVBVTZQN29GSzFib2tnZmlvV05TeVZYYW9ZeHJHbzJHYWVhUnVsUUNJV0ZSbmlwV3FKdXRReWhC NjA1UHZpbTA2UDc0b0JrL05YQW1RS3FkR3JRVTVGYXhKR0VjVkMxV0d4VlovYW13STJOUmtacHpV MnN4a2JEbW1FYzFLd3FNMGdHMG5lbG94VWpIcUtrRlJxYWVEelZJQjFQV21DcEZGVVN5YUtySzFX anF3dGFJUTl2dTFueWo1elY0dHhWS1kvdkdwVEdpazMzalNVcmZlTkpXRDNHUFR0VTYxQWxTcWFw QVNVNWFhT2FjdFVoRWlWWmpxdXRUb2EwUWlkYWp1UHVOOUtjS1pNUjVaK2xWMEFwZHFwUDFxN1ZJ cnlheG1VSXRXRTlxZ0ZUSlVvQ2RhZjNxTmFrSE5XaENqclVxVkdvNzFLb3F4RTZkS2xGUkowcVRP S3RBeUtiN2xaOXg5d1ZvVEhLR3MrNUJLREZSTUNuM3FWQnpUZHVLZXZXc1VpaXdsU2lvRU5URDFy UkNIOTZjT3RNRlNMVmlKVXFWZXRSTFVvcTBESG5wVWNQL0FCL3dmOWRGL25UODB5RTV2NE1mODlG L25TbHNKYm52ZWcvOGcrSC9BSEIvS3N6eHp4WldmL1hWdi9RYTA5Qi81QjhQKzRLelBIWC9BQjVX Zi9YVnYvUWE1U3psdFFIL0FCUXVnLzhBWVdYL0FOSHZYdU1mM1JYaDJvLzhpTm9QL1lXWC93Qkh2 WHVFWDNhUXlTbDVwS1dnRG12aUIveUkycGY5c3Y4QTBhbGVIVjdqOFFQK1JHMUxuL25sL3dDalVy dzZnQXBLV2tOQUNjMGxMU2RxQUVvcGFTZ0JwcEtVMGhvQVNrcGFTZ0JLYWVsTFNHZ0J0SWFVMGhv QVEwMm5HbW1nQnBwRFNta05BRGUxTnBhVHZRQTMxcHBwNXBwb0FhYWFhZFRUUUEwMDAwNDAwMEFO TklhVTBob0FhYWFhY2FiUUFocHBweHBwb0FiVFRUcWFhQUdta3BUU1VBTk5JYVUwaG9BYlNHbHBE UUEwMGxLYVNnQkthYWRUVFFBaHBLVTBsQUNVbExTVUFKU0dscERRQVVVVVVBRkZGRkFCUlJSUUFV VVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBTFJTVTlSVFNCaUFWUEF2TklxWnEx Yng4MXRUcDZtVTVhRnkzanppdFNDSGlxdHRIMHJWZ2o0cjNNTlNQTHJUSklvUlYyS01Db28wcTFH SzlhbEN4d1RrT0NVOExSUzVycHNZakplRnJOdUd4V2hPZmxySXVuNjF6WWlWamVpcnNwenk0clBt bHFTNGs1cWhLK2E4R3ZWUFRwVXlLYVNxeGMwK1ZxcmsxNWRTYnVkMEk2Q2xxYVRSVFRXTFpxa2Vx ZkFQL2tlcjMvc0d5ZitqWXEraWErZGZnSC9BTWoxZS84QVlOay85R3hWOUZVaGhSUlJRQmplTGY4 QWtUdFovd0N2S1gvMEUxNTE0by80OS9DZi9Ybi9BTzBVcjBYeGFQOEFpanRaL3dDdktYLzBFMTUx NG8vNDkvQ2YvWG4vQU8wVW9BcVIvY0ZaR3Y4QS9JT3VmK3VUL3dEb0pyWGovd0JXS3g5Zi93Q1Fk Yy85Y24vOUJOV0k4dmFuUS9lelNOU29wenhUNmlOR1A3d3E0dkFxcEY5NWF0WnJhSWdhb0hxWTFF OU1DRTAybnRUS2hnTmJOUXYwcVZxaGMxTEdRUFVKNjVxWjgxR0JucFdZMFQydytiOEswTGZxYXo3 Y0VQV2pic09hMHBpWlpQU29YcVFtbzJyVmlJSDYxRWFtYW9pS3pZRE8xTWFubW1OVU1aQzlRdDFx WnFoYnJVTWFCYXR4ZmRGVXdQU3JrUUlWYzFVUm1qRjA0cFdwcU5oUlRtT1JXeUlJSktydFZoNmdh cFlFWnBEMHBUVFR4M3FCb2phb21xVnFpYW9ZeEtkSDk4VXlueC9mRkF5eC9GV2hHUGxyUC9pcThy QVZyQWtHNlZXZXJMR3E3VTJCQTFJS2N3cG5Tc3hpTlVkUFkweWt3RUlPZWxKZzFjQ3FhZUkxUGFq bEFwQlNLY090WGZKR09sUnRDTVZYTFlMa1MxTU9LaHlGWE5SR1FudWFWd0w2c29OUEVpaXN3T2ZX bERIMXBxWVdORjVjVlhadHh6VUFKTlNyUnpYQWplUHFhWnNQcFZ3WVpSVHdpazR4UzViaUtJVWp0 VHVSVjhSTDZVclJLQm5HYXJrQXBwelV5VWp4Q1BwVWJPVUhIZWpZTEZvRUNucXdyTU1yZXRLSlg5 ZUtPWUxHcDVneDFxSjVRY3JWTU1mV25MMXA4d0VuYW9Iakk3VlBVd3czVVVyWEFvQ00rbFBWVzlL dnFpK2xQOHBjOENueUFVQmtWS2h5S3ROQ3ZwVURwc09CVDViQU9UcFVvSUhlcWNrcFVGS2k4MXM5 VFJld0dtR0hyVHQ0STYxbUNSL1duQm1QZWpuRll1TytSaW9IVGV0TlhyVTZkYWU0Rkl4SDBvQ0VZ NHJRQ2crbFBFYStsTGtHVUFwcDY1QnE5NVl4MHBqUkE5cWZLSzVFTzFTZ1lxSThjOFZBMHhQclJz TXZnajFwMjRldFpZbFByVWl5TWU5SE9JMERJQU8xSmJObStoUC9BRTBYK2RVd1NhczJJLzB5RC9y b3Y4NmJkd1BvSFFQK1FmRC9BTGcvbFdaNDUvNDhiTS85TlcvOUJyVDBEL2tIdy83Z3JMOGRjV05u L3dCZFcvbFhPVWN2cVA4QXlJMmcvd0RZV1gvMGU5ZTRSL2Rydy9VUCtSRjBIL3NMTC82UGV2Y0kv dTBoa2xGRkZBSE5mRUQvQUpFYlV2OEF0bC82TlN2RDY5dytJSC9JajZsLzJ5LzlHcFhoOUFCU0dq dFFlbEFDVW5iRk9OTm9BS2JTMFVBTnhTR2xOSlFBbEpTMGxBRGFRMHRJYUFHbWtOS2VsSWFBR25w U1U0MDNGQURUMnBLVTBob0FiVGFkVGFBRzAwMCttR2dCS2FhY2FhYUFHbW1tbkdtbWdCcHBEU21r TkFEVFRUVGpUYUFHbWtOT05OTkFEYWFhZFRUUUEwMGxLYVNnQnBwRFNta05BRGFRMHRJYUFHbWtw VFNVQUpUVFRxYWFBRU5KU21rb0FTa3BhU2dCS1EwdElhQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fv b29vQUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQXFXTVZGVmlJVmNGZGt5Mko0MHpWMjNqNXFH RkswTGRLOUtoVE9Lck11VzhmU3RTQ1BpcWR1dGFVSStXdmN3OU04dXJJa1JLbVJhYW9xUmE5Q0tP WnNVaW0wNDB3bXFKUkZjSENWaVhiWXpXdmN0OHRZVjRldGVkakphSFhoMFpOeko4MVVuZXByby9O VlJxK2FxeWR6MmFjZEJydFVlYVZxWlhJMmRLUXRKUlJValBVL2dIL3dBajFlLzlnMlQvQU5HeFY5 RlY4Ni9BUC9rZXIzL3NHeWYrallxK2lxQUNpaWlnREc4Vy93REluYXovQU5lVXYvb0pyenJ4Ui94 NytFLyt2UDhBOW9wWG92aTMva1Q5Wi82OHBmOEEwRTE1ejRvLzQ5L0NuL1huL3dDMFVvQXF4L2NG Wkd2ZjhnKzQvd0N1VC84QW9KclhqKzRLeXRhLzQ5SnMvd0J4djVWU0VlWitXYzlLa1NMTENydXdB ZEtRNHhpdGxDd2lOVHRQMHFaWkEzZXE3VkVTeTA3MkVYaTZudlRTUlZCcEdGTTgxdlUwdWNDK1FE VVo5cXJKTVJnNTZWTUczQ2xlNHhqbm1veUNlMVhZNGdUdXAvbEFDamx1QmxsRG5wU0NNNTZWcG1N WTZVMHFCMm81YkJjcXBIc09lYW5qZlpRL1RGUXVLTmdMbm1EMXBDd1BlcUJZZ1lCcU15TU85SE9C b0VnMHg4WXFqNXJaNm1wRm1PY0hOTG1DeEllbFJIbnBVd1hjMktuU0ZSUW8zQXptVTAzeXo2VnFH SmU0cGhqWDBwY2dHZWtXY0RCcXdvd01WTmdEcFVUZDZMV0M1TWtvT0JUL0FEQjYxUU9RZURUZDdB ZGFmTllkaStXRlJuQjZWUzh4dldrRHRuclM1cmhZdE9NVkUzSFdsUnQ5U0pIdk9mU3BFVm1CcGhW dlN0SVFyNlVoalVEcFQ1Qm96ZHBxUkl6bk5XeWkrbE1iQVhGTGxBakhGVHBLRFVIYW95Q09ob1Rz SXZHUWV0TUpGVWl4cE56ZXRQbUhZdG5GUk9NR29RNUZTQnR3elN1QTFxWmcrbFdVaTNmTlVvaVU5 aFJ5M0dScWFuajVxdXZXckVYYXFSSk9CMnBzaWZMVDFwc3hJWDg2dDdDTTJUN3BxR3BwQjhsUTFn eTBIZW5xS2o3MUl0QU1rQTVwNEZJdnZUcXBDSEthbFExQ0ttU3FRaXdneUtrMjVxT09waFdpRVZM a1lBcWpPZWxYcnIrR3FFL1FWbk1wRU5QV21VOU9sWmpKbHhVcWlvMHFVVlpMQWRha1U4MUgzcDY5 YVlpWktzSUtyb09hc0owclJBS1Zxck9NU2ZoVndqamlxZHgvclB3cHkyQW8zQnhJZnBVWFUxTGMv ZlAwcUZldGM3S0psUE5UTFVLZGFuV3FRbVBGUEhXbWluRHJWaUpGTlRMaW9GNjFPbFdnSlFCU010 S0tHNlZmUVZpakx3RzQ3VlFMVmZsSHl0bXM5dUdyQ1pTSEthblRtb0VxZU9wUU1uVVZacy8rUDJE L0FLNkwvT3E2MVp0UCtQMkQvcm92ODYwRWUvYUFQK0pmRC91RCtWWm5qcm14cy84QXJxMzhxMDlB L3dDUWZEL3VEK1ZaZmpySDJHelAvVFZ2NVZnVWN2cUgvSWphQ1A4QXFMTC9BT2ozcjNDUDd0ZUg2 aC95SXVnLzloWmYvUjcxN2hIOTBVaGtsRkZHS0FPYStJSC9BQ0kycGY4QWJMLzBhbGVIODE3aDhR Qi94UStwZjlzdi9ScVY0ZlFBVWhwYURRQTN0U1V0SlFBVTJuVTJnQktTbFBTa05BQ2Q2U2w3MGxB Q1UwMHA2VWhvQVEwMDlLY2FhYUFFcHRMVGFBRU5JZUtXa05BRGFiU25wU1VBTjdVMDA2bW1nQkRU VFRqVFRRQTAwMDA0MDAwQU5OSWFVMGhvQWFhYlRqVFRRQWhwcHBUU0dnQnROTk9wcG9BYWFTbE5K UUEwMGhwVFNHZ0J0SWFXa05BRFRTVXBwS0FFcHBwMU5OQUNHa3BUU1VBSlNVdEpRQWxJYVdrTkFC UlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUF0V29C bXFncTdianBXdEplOFJVMk5DQmVsYU1FZFU3Y1ZxUXIwcjNNUEE4dXRJdFFMV2hFdnkxVWhGWG94 eFhzVVZZODZveDRGUEZORk9GZFNNUkdxRmpVclZBd1ByVXlIRXIzRGZMV0pkbnJXeGNBN2F4THNk YTh2R2JIZGgwWTF5Zm1xb1RWcTVIelZWYXZtNnZ4SHMwOWlNMDJuR20xenMxUVVVVVVobnFmd0Qv NUhxOS83QnNuL0FLTmlyNktyNTErQWYvSTlYdjhBMkRaUC9Sc1ZmUlZBQlJSUlFCamVMZjhBa1R0 Wi93Q3ZLWC8wRTE1MTRvLzQ5L0NmL1huL0FPMFVyMFh4Yi95SjJzLzllVXYvQUtEWG5YaWovVWVF L3dEcnovOEFhS1VBVkkvOVdLeXRhLzQ5WmY4QWNiK1Zhc2YrckZaV3RmOEFIcEwvQUxqZnlxMXVJ NFZqVVJOU05VUnJja1FqaW8yRlNkcVkyTVZJRURpcTdHckVuU3F6Vm15aEEyS3V3SE1acWdPdFg0 ZnVVUUI3RitOZmxwNUhGTWkrNVVqVjBJZ2dmaW9tTlRQVURDb1l4aDVwakNuOXFhYWtDRmhVTGlw M3FCNmhqUkVUaW5JM3pENjAwOWFXSWZOK05RVWFVSXpKVnNEaXFjUEVncThQdTEwUjJJSTI5YWhm clU3VldmclF3STJOTU5LMU43Vm13R0VjVkd3eFVyZEtpZXBZMFF0MTRwTVVwNjBsU1VUUWQ2dld5 N2xiNjFSZzcxZXRlaCt0YVFFeXh0eFVMakFxdzFRU2RLMFpKWFkxRWFrYW96V1RHSlRDS2YycHJk YVF5SmhnMDJuTjFwdFFNS2tUN3RSMUluM2FhQXZXNjVqRlM0eFVWc2ZsWDYxTWV0Ym9rb3JWaVBp b1ZGU3J4VUlDd3RKSmphYWFHNHFOMzROVUJUazRTb2FtWVpVOFZEakZaTWFFNzFJdE1wd3BJWk1Q U25Db2dha0ZVSWVLbVNtSUtrV3JRaWVQZ1ZNRGdWQXBwV2FyMkZZaHVmNGFwVGpHMnJjN1p4Vlda U2NkNnptTkZlbnBTYmVhVWNWbVVUcFVvcUFHcEZQTldTUDcwOWV0TXFaQjYxU0VQVHJWaGFnV3BS eFZvQ1VuaXFjLytzL0NyQmJpcTBweTlPV3dGRzQvMWgrbFJMd2FubVVsODRxUGJnMXp0RkxZY25X ckMxQXZGU0thcEF5WVU4VkdwcVZSbXJKSExVNmRLaUE5YWxXclFFb29QU201cHJOZ2NtcUVWWmZ1 dFdldzVyUWZrTjcxVVpDTzFZeUtReGVLbmpOUktwcVJlT09hU0c5aXdwcXphZjhBSDVCLzEwWCtk VTFOWExIL0FJKzRQK3VpL3dBNnNSNy9BS0IveUQ0Zjl3ZnlyTDhkZjhlTm4vMTFiLzBHdFRRUCtR ZkQvdUQrVlpmanIvanlzLzhBcnEzL0FLRFdBemx0US81RWJRZit3c3YvQUtQZXZjWS91aXZEdFEv NUViUWVmK1lzdi9vOTY5d2orN1NHU2lpZ2RhS0FPYStJSC9JajZsLzJ5LzhBUnFWNGZYdUh4QS81 RWZVdisyWC9BS05TdkQ2QUNrcGFRMEFCcHRMOUtTZ0ErbE42VXRKUUFsSlNucFNHZ0JPOUozcGFT Z0J0SWFjZWxOTkFDR21tbkdtbWdCS2JTbnBTVUFOcEQwcGFRMEFNTkpUcWJRQWhwcHBlMUlhQUdt bW1uR21tZ0JwcHRPTk5OQURUL1drTk9QU21tZ0JwcHRPTk5vQWFldElhY2FhYUFHMDAwNm1tZ0Jw cEtVMGxBRFRTR2xOSWFBRzBocGFRMEFOTkpTbWtvQVNtbW5VMDBBSWFTbE5KUUFsSlMwbEFDVWhw YVEwQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRkZB QlYyMjdWU0ZYcmJ0VzFINGlLbXhyV3c2VnFRanBXWmJWcVFqZ1Y3MkdQSnJibDJFR3JzZlNxY1ZY WStsZXZTUFBxRHhUeFRSVGhYU2pKaldGUnN0U2tVMHJTYXVDS1Z5dnkxaDNhOWE2SzVYNWF3cnhl dGViakk2SFpoMmM5ZEQ1cXFFVmV1bCthcWJDdm1hcTk0OXFtOUNCcWJUMnBsY3JSdWdvb29wRFBW UGdGL3lQVjcvd0JnMlQvMGJGWDBUaXZuWDRCLzhqMWUvd0RZTmsvOUd4VjlGVUFGRkZGQUdONHQv d0NSTzFuL0FLOHBmL1FUWG5YaWovVWVFLzhBcnovOW9wWG92aTcvQUpFN1dmOEFyeWwvOUJOZWRl S1A5UjRUL3dDdlAvMmlsQUZTUC9WaXNyV3YrUFdYL2NiK1Zha1grckZaZXMvOGVzdis0MzhxcENP RVlWR2FtYW8yRmRCSkhVYmMxSWVLaFkxSUVjblNxellxdzFSRVo3Vm14b2lBNXE5Qjl5cTZwVnFN WVVVNEliMkwwWEMwOXFnamI1YWtMWkZicGtrYjk2aGFwMnFOaG1wWUVCNHBDYWthb1hxR0F4elZk Nm1icFVUQ3MyTkVKcDBmM2g5YVhiejBwNkp6MHBKRkY2SG1RVmRCcWdoMnRtcklibXQ0a01lMVYz SEpxWW1vbW9ZRURVenRVekNvaldiQVkzU29tcDdHbzI1N1ZJMFJIclNVcEZBQjYxTmlpV0FkYXZX dlJ2clZLSVlCTldvR0F6V2tDUzRUeFVMODB1N0lwcmRLMEN4QTMwcUkxTzFSTU9EV2JRRE8xTmFu Vkd4cVdNWTFOcFRTVklCVWlmZHFQOEtrVDd0Q0F2Vy9DQ3BqOWFyUk5oTVZKdjhBZXRreFdLUG5I TkhudlVYYWlzYmxFd25ZMGIyUFdvMUZPQTVwM0UwU2pCTk84cFdOTXFSVFRFQXRnYVVXbzdWTWxU QmF0UkFwTmI0NlVnQlU0cThWcW5KOTlxVFZnR3RMdFVnZmVwZ3VHelVMSG1tOTZqbUdXaGN1YVh6 Mk5WMXFWUlR1QTlXSkpCcVJBQ0Rtb3dNVTljMVNFTzhoRFRsdGxOT1ExT25OVllDdUxVVXhvZGpa SFNyK00xSEt1SXo5S2ZLSmxTa2FjZ2NVVlVMWXpVTjJLTFAybHZXbkM1YjBxbXZXcFZwY3dFL25P VGluTHlLalVWS3ZGVWhEMVFNdk5BdDE3VUtjVktwcXJBUi9abHBmc3k0cXd0U0VacWxHNGlqNVd6 bWpkc05XWlJoT2xVWnpoUWFoNkFQYTRJTko5cGJOVkMyZUtjb3lhbm1HVy90TEdsTWpNT2FoVVZL b3Frd0pGcDVpVnpUQlVpbXFzSVQ3T3VhUHN5NTRxWmFrQXAyQmxacmZqaXBMTWJieUgvcm92ODZs STY5YWJCL3gvUWY5ZEYvblEwQjc1b1AvQUNENFIvc0QrVlpuam9mNkZaLzlkVy9sV25vSC9JUGgv d0J3ZnlyTThkZjhlVm4vQU5kVy9sWE1VY3RxSC9JaTZELzJGbC85SHZYdDhmM2E4UTFEL2tSZEIv N0N5LzhBbzk2OXZqNlVoa2xMU1VVQWMzOFFQK1JIMUwvdGwvNk5TdkQ2OXcrSUgvSWo2bC8yeS84 QVJxVjRmUUFVaHBhU2dCS1NscEtBRW9vbzdVQU5OSWVsS2FTZ0JLU2w3MG5yUUFocHBwM2FtbnBR QWhwcHBUU0dnQnZha3B4cHBvQWJTR2xOTlBlZ0JLYlMrdEpRQWhwaHAzYW1tZ0JLYWFjYWFhQUdt bW1uR21tZ0JwcERTbWtvQWFhYlRqVGFBR21rTk9OTk5BRGFhYWRUVFFBMDBsS2FTZ0JwcERTbWtO QURhUTB0SWFBR21rcFRTVUFKVFRUcWFhQUVOSlNta29BU2twYVNnQktRMHRJYUFDaWlpZ0Fvb29v QUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0FxN2JkcXBWZHQrMWJV ZmlJcWJHdmJIcFdwQ2VCV1RibnBXbkNlQlh1NGRuazFqUmlOWFl6eFZDRTFkalBGZXZSUFBxRXdw d3BncDRycVJreGFTbHBLWWlHNEh5MWkzU2RhMjVobGF5N2hNNXJpeFVibzZhRE9kdVl1YW95UjRy YXVJczFueXg0N1Y4N1hwYW5yVXBtWTY0cUhGV3BseFZiRmViTldaMnhlZzJpbE5KV1paNnA4QS84 QWtlcjMvc0d5ZitqWXEraWErZHZnSC95UFY3LzJEWlAvQUViRlgwVFFBVVVVVUFZM2kzL2tUdFov NjhwZi9RVFhuUGlmL1VlRlArdlAvd0JvcFhvM2kzL2tUdFovNjhwZi9RVFhuWGlqL2ozOEovOEFY bi83UlNnQ25IL3F4V1RyaHhaVG4wamIrUnJXai8xWXJJMS9qVDdqL3JrLy9vSnFoSG4zMm9pbkxO dUhXcUJKelQwZmtWb3BDUmQ2OFVxd1o2MFIvZUZXZ0swU0VWVGJxS1Q3TXVLdHNLalBGSEtCQUlV V2tJd2FlMVJtcEFqTGxXNG8rME1LSEZSTUttNHg1dW1wUHRKSnFzeHhUQTJPbFR6RE5EZnZQSFNr TVpmcG1vSURsdXRYb0FUazFhMUpJeGJERkliWmF1YmNkcVkxVnlnVlBzeWlsRWFxRFVyR295YWta RTNBNHBvbGRhZWVsUk5VM0JDbTVZVW4ycHNjMUMxUkUxTGtNdUxjWjYwcE9SbXFRTlc0dnVERk5P NFdITER1WUU1eFR6YWpwMnF5aWtnVTVsd0t2bEpLUnRrRkhrS0tzT1RVTEdsWWR4anFCVVRFakdL ZXhwckNwQVR6MkZJYmxxWTFSbXB1VVRmYURUaEx1R0tyQ25KOThVWEFtSTlxY2tHZW9wQndSVjBM a0NyU3VTVlBzb0gwcERicUt2R29HelQ1UUsvbEFVakRuaW5zVFVaNTYxSXhwWXFlS1BQYjNvWVZH UlUzR0pTZDZXaXBBZXRTQVZHdFNDcVFtTFRscHZlbnJWQ0o0dTFXVng3MVdpNmlySzFvaERqMEpy UGw1YzFvSHBWQ1VZa2FsUFlhS2JmZU5ONzByZmVOSmlzSHVNa1NwbHFGT2xTclZJQjlPV21nMDRW U0VTTDFxekdLckwxcXpIV2lFVExpbzU4K1czcGlwRnBrNC9kdDlLcDdBVU1WUlljOWF2VlNicWF3 a1VLbFRKVUNWT2xKQVRMVCs5TVduOTYwUkk0ZGFrU29nT2FsU21nTENkS2tGUm9PS2tGYW9HUnpm Y3JPdVJsQm4xclJuR0VyT3VEOGdyT1lGVFBOU29lYWhxVkJ6V0tHV1VIRlNxS2lTcFFhMVFoM2Vu TFRRS2NCelZBU3BVeTFFZ3FWUlZvQjFNaDV2NFArdWkvenFUdFVjUEYvQi8xMFgrZEtXd2ozdlFm K1FmRC9BTGcvbFdYNDYvNDhiUDhBNjZ0LzZEV3BvQS80bDhQKzRQNVZsK09zZlliUC9ycTMvb05j cFp5K29mOEFJamFEL3dCaFpmOEEwZTllM3gvZHJ4RFVQK1JHMEgvc0xMLzZQZXZiNC91NXBESktL S0tBT2IrSUgvSWo2ai8yeS84QVJxVjRmWHVIeEEvNUViVXYrMlgvQUtOU3ZENkFDa3BhUTBBSjJv bzdVbEFCMnB0TDYwbEFDR2tOTFNVQUpTVXRKUUFocHBwMU5OQUNHbW1sUGFrUFNnQnA2VWhweDZV MmdCcHBEUzAwMEFKVGFkVGFBRXBocHhwcG9BUTAwMDQ5S2FhQUdtbW1uR21tZ0JwcEtVMGhvQWFh YWFjYWFhQUVOTk5PTk5OQURhYWFkVFRRQTAwbEthU2dCcHBEU21rTkFEYVEwdElhQUdta3BUU1VB SlRUVHFhYUFFTkpTbWtvQVNrcGFTZ0JLUTB0SWFBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9vb29B S0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBRlc0RGpGVktzUkhGYVUzWmtUMk5XQjYwNFpLeElu eFYrM2s5NjlmRDFEejZzRGNoZXI4UitXc2kzZnBXbkNmbHIyNkU3bm1WWTJMUU5QRlJLYWtGZHNX YzdIMFlvb3FoRWNvNHFoTW1jMW91TWlxN3BrVmpVanpHa0hZeHBvYzFuVHcxMEVrUEZaODhOZVhY b0hiU3FIT1R3MVRNUnJjbmg2MVFraXhYaTFxTm1lbFRxYUdjVnhUVHhWbVJLcmtjMXd6alk2b3U1 Nmo4QS8rUjZ2Zit3Ykovd0NqWXEraXNWODYvQVAvQUpIcTkvN0Jzbi9vMkt2b3FvS0NpaWlnREc4 Vy93REluYXovQU5lVXYvb0pyem54Ui94NytGUCt2UDhBOW9wWG8zaTMva1R0Wi82OHBmOEEwRTE1 ejRvLzQ5L0NuL1huL3dDMFVvQXFSZjZzVmthLy93QWcrNS82NVA4QStnbXRlUDdnckkxLy9rSDNQ L1hKL3dEMEUxUWp5OXNVc1ErWVpwRzYwc1p3MU1EU2orOHRYRjZWVGk1WmF1RGdWMFIySllqVkEv V3AycUIrOURBaUpwdE9hbTFBRFdxRjhWTTFRdlVzWlhmclVSNjFJOVJtczJORmkySHpWcFcyZWF6 TFUvUDM2VnAyNHJTbUpvc0VjVkM5VEU4VkU0clZpS3o5YWpKcVZ4elVSck5nTlBTbUVVL3RUR3FX TWhlb1QxcVo2aGFzMk5DREJxNUVNS3RVNnVSZmNGT0lNMG96OG9GRENrajZDbE5kQ1doSlhmTlFO VmlTcTdDb1lFWjVvUFNpZzlLekdpTnFoYnJVelZDM1dwWXhLZEg5OFUyblIvZkZDR3l3T0dxK25J cWgxYXRCQmdWckVrYTJlYXJ1YXN0Vlo2YkFoYjYwekZQYW1pc3hqU01DbUhyVDJxT2xZQnZTaXBQ Sk5Ia3QwcFdBWXBxUmV0QWhiMG9LbGUxTklHU0RGU0tPYWpYclRqSUZPS29SWVRpcGxOVWhPQnpU dnRJcXJoWXRsOFZUbDVjKzlJWjgwbWM4ME4zQXFzUG1OSlZwb2R3NHB2MmRxamxHUkxVaW1uQzNZ VTR3TU9hRW1BS2MxSWxSS0NEVXFIQ25OTVJLbzVxZE9LcWVjb05PRnlvK3RXbUZpNkR4VWNySHlt cXY5cEFwalRGamp0VDVnRS93cXB0NjFib2VEUFNzMnJnaW1CZzFLbkZTaTJOS0xkaFFrTVJUVWc1 cHBoWVU1QmdWU0VTS0tsV29sY0JlYVh6MXpWWEF0S2FmbmlxWXVWRk9Od0NLcFNGWWxtYksxUnVC bFJVcGxMdGdVdTNkd2FsNmdaNVhCcDZWWk50NlVDMmFvNVJqRk9LbFhta0Z1NE5LWXl1S2FURVND cEZGUnFSVHpLcTFhR1RMVWc0cXFMaGFkOXBYMXFyaUxKYW13SE4vYi84QVhSZjUxWE53Q2VLa3My M1hrSi82YUwvT2hnZS82RC95RDRmOXdWbCtPdjhBanhzLyt1cC9sV3BvUC9JUGgvM0JXWDQ2L3dD UEt6LzY2bi8wR3VVbzViVVArUkcwSC9zTEwvNlBldmNJL3VpdkQ5Ui81RWJRZit3c3Yvbzk2OXdq KzZLUXlTaWtwY1VBYzM4UU1mOEFDRDZsL3dCc3YvUnFWNGZYdC94QS93Q1JIMUwvQUxaZitqVXJ4 Q2dBcERTMGhvQVE5S1NsTkoyb0FLYlRxYlFBbEoycFRTR2dCS1NscEtBRXBwNlU0OUthYUFHbnBT R2xOSWFBRU5OcFQwcEtBR21tbnZUalRUUUFsTnB4cHRBRFRUVFQ2WWFBRU5OTk9OTk5BRFRUVFRq VFRRQTAwaHBUU0dnQnBwdE9OTk5BQ0dtMDQwMDBBTnBwcDFOTkFEVFNVcHBLQUdta05LYVEwQU5w RFMwaG9BYWFTbE5KUUFsTk5PcHBvQVEwbEthU2dCS1NscEtBRXBEUzBob0FLS0tLQUNpaWlnQW9v b29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNwVU5SVTVhcUltVzBhcmx1 L05acXRWcTNmbXV1bFBVNTZrTkRmdG40RmEwRC9MWFAyOG5TdFdDVGl2ZHcxUThxdkExVWFwbE5V STNxMUcxZXBUbGM0cFJMR2FLYm1sRmIzTTdDbm1tRmFmU1Voa2JJTVZRbmpCclJJNHF0SW1heHF3 dWk0T3hpVHc5YXpwb1R6WFFTdzVxcEpiZTFlVld3OXp1cFZiSE9Td042VlRlQnMxMHNscDdWVmV6 NTZWNWRYQ003cWVJTzArQXNaWHh6ZWsvd0RRTmsvOUd4VjlENDk2OEcrQ1VQbCtOTHcvOVE5Ly9S a2RlODE1MVdISkt4MlU1Y3l1RkZGRlpsbU40dC81RTdXZit2S1gvd0JCTmVjK0tQOEFqMzhKL3dE WG4vN1JqcjBieGIveUoycy85ZVV2L29KcnpueFIvd0FlL2hUL0FLOC8vYUtVQVZJL3VMOUt5TmYv QU9RZmNmOEFYSi8vQUVFMXJ4LzZzVmxhNE0yVTQ5WTIva2FvUjVlUm1uS256RGlyWDJZMDlZZHZX dEZFUTZQaGxGV2cyYXFaMjhpbFdmMXJSYUNMUjZWRXdxUDdTdmVrTnd2V2k2Q3dyQ282ZDVxazBo NjhVbU1pYzRxSmlhbUtGbTRwRGJzYWhwaUtiQ21CY25wVjAyelVndGpVOG95TzNHR05Yb0RqTlFl V0VQRktIS0VISEZXdEFMdWMwMXVsVnZ0SUZIMmxhcm1DdzloVVREaWczQzBvZFdGUzJGaUkxRzFT Tm5IRk5FVE5VMkFydHpVUkJxNGJkNmI5bWFwNVJsWUx4MHExRU1JS1VRWUZPeHQ0cHBBWEZmNVJU aWMxUldiYWNHbm01QXExSVZpVithaFlZcERjcVJUZk9VMHJoWVJoVWJWSXhCSXBqTGsxSUpFYlZF d3F4NUxlbE5OdXhOVFlvZ0ZPaisrS2wrenRUbGkyZ2s5YUxBTC9BQkRGWFZmQXFqMk5PU2ZIV3JU c1NYR05RdUtpKzBVaG5VMDJ3c0RDbUhpbmVhcHBqSEpxQmpXcVBpbmxkeDRvOGhxV29GaFR6VXlE TlYxNjFZanEwSWtLREZST21FUEZXRkZKTHdwcTJnTTVpUWhxSE5TeWZjTlExZ3hvS2NLYjNwNjBE SEJlYWxGTkFwMktvVEpWcVJLZ1UxTWxXaEU2cnpTc3ZGS25TcEFLdElSU25VTGpGVlpTVnhqcFYy NjdWUW42TFdjeWtSazVOT1VtbzZldFpwakpRT2FrVWMwMWFsQXEwU3c3MU1wcUh2VWltcVFpWmFs QXpVS1ZZU3RFREdsS3J5Z0s0eFYzSEZWTGovV2ZoU1lGS1pzU0VacUxkelRyai9Xc2FpSFdzR3lp WlRVcWpOUXBWaGFwTVE1VkZTcndhWUtkM3EwSW1VMUt0UUxVeWRxdEFQeDNwcFhyVWdvYmdWVmhG Ri91dFZRdlZ1WG8xWjUrOVdNaWtTSzNOU3J5YWdVYzFZUVVrREhxUGFyZGtNWGtIL1hSZjUxWFVW YXMvd0RqOGcvNjZML090RUk5KzBIL0FKQjBQKzRQNVZsK092OEFqeXMvK3V6ZitnMXFhQi95RDRm OXhmNVZsK092K1BLei93Q3V4LzhBUWE1eWpsdFIvd0NSRzBIL0FMQ3cvd0RSNzE3aEgwcnhEVWYr UkgwSC9zTEwvd0NqM3IyK1BwU0dTVVVsTFFCemZ4QS81RWZVdisyWC9vMUs4UHIzRDRnZjhpUHFQ MGkvOUdwWGg5QUNVR2lnMEFKMnBLV2tvQVNreFMwbEFDR2tOTDJwRFFBbEpTMGxBRGNVaDZVdEll bEFEVFNHbE5JYUFFN1UybmRxYWFBRzAybkdtbnBRQW5hbW1sN1VsQUNHbUdubW1HZ0JEVFRUajBw cG9BYWFhZmFuR21tZ0JwcERTbWtOQURUVGFjYWFhQUdta05PTk5OQURhYWFkVFRRQTAwbEthU2dC cHBEU21rTkFEYVEwdElhQUdta3BUU1VBSlRUVHFhYUFFTkpTbWtvQVNrcGFTZ0JLUTB0SWFBQ2lp aWdBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb0Jvb29B ZG1wNFg1cXRVa1p3YXVEMUprdERZdDVPbGFjRXRZTVVtS3ZSVFk3MTZ1SHEyUFBxMDdtL0RKVjZK cXdZWi9lcjhOeDcxN0ZDdWp6NmxKbXdEVGdhb0pObnZVNlNacnZqVVRPWndzV3FTbUJ1S1VHdGJr V0hVeGt6VDZLTFhDOWlCb2MxRTF2bXJkTklyTjAweWxKbEZyWE5ReVdneFdrUlVicnhXTTZNV2FS cU02WDRSUStYNHZ1ai8wNHY4QStoeDE3VFhrSHdyVEhpcTVQL1RrMy9vYVY2L2l2bE15ankxMmoz Y0U3MHJoUlJSWEFkWmplTGYrUlAxbi9yeWwvd0RRVFhuUGlqL2ozOEtmOWVmL0FMUmpyMGJ4Yi95 SjJzLzllVXYvQUtDYTg1OFQvd0RIdjRUL0FPdlAvd0JvcFFCVGovMVlyTTFyL2oxbC93Qnh2NVZw eC82c1ZtYTEvd0Flc3Y4QXVOL0kxU0VjTWFqWTA1alViZWxkREpHRVpGUkZjVk5qaW1NTVZJRmRo VVJPS21rNlZXYW9iS0hoNnR4bktpczhWZWdIN3VpTEV5NUd1VXFUR0JSRmpiVGpXeVJKRXdxTThW STlRTWNWSXhyODFFd3FRbk5OYW9ZeUJoeFVST0tuYW9IT0tsZ00zYzFJakhkVUxVc2VTdyt0VGNa b1JqTGdHcktwZzFCRC9yQlYzdFc4RVNSRlFCVVRWTTlRUFF3R0Z1S2lOT05NN1ZEWTdrYkNvbUdL bllWRTlRTWhKb0JvYnJTVk54azhSTFpxM0N1UWVLcHdkNnYydlJ2cldrQk1rMjRwcllBcVlpb1g0 clJva2hKcU51ZXRPWTFFYXpZeEtpWWNWTFREVWpJaUJTWXB6VTJvR0ZTcDBxS3BFKzdUVzRNdFJw bE9sVEt1Ri94cHR2OEE2dkZUNHJaSWtvTDFxeEZVQ2lwNCtLbEFXRnBrMzNmd3BWTkk3Y0dyNkNN NS91R29hbWsrN1VQU3NHVWhPOVNLS1pUMVBGQXlZVXRNV25EclZDSGlwa3FKYW1UNlZTRVdJK2xU RHBVS0duNUFGYUlSV3VSOTM4YW9UOUZxL2NuaGFvVDloV2N5a1EwOWFaam1ucldZK2hPbFNpb1ZP S2tCcWlXTzcwOWFaVWkxYUVTeDFZU29FRlRMV2tRSk8xVTdqL1dmaFZ2T0txWEhNbjRVU0FvM09Q TVAwcUVkYWx1RnpJYWlBd2MxenNwYkVxQ3JDaXE2OWFuVW1xUW1TZ1U0VXdWSUt0Q0hMMXFkT2xR clV5VmFBbEZEVUNrWnNDcTZDS1V2M1dyT1kvTldqTHlHcWdWckNSUXFkYXNwVlphblNsRUN3dFdM VC9qOWcvNjZML09xeW1yTm1mOEFUWVArdWkvenJRUjcvb1AvQUNENGY5eGY1VmxlT3Y4QWp4cy8r dXJmK2cxcTZEL3lEb2Y5eGY1VmxlT3YrUEt6L3dDdXJmOEFvTllGSEw2aC93QWlOb1AvQUdGbC93 RFI3MTdoSDkydkQ5UUgvRkRhRC8yRmwvOEFSNzE3aEg5MmtNZUtXa29GQUhOL0VEL2tSdFMvN1pm K2pVcnhDdmIvQUlnZjhpUHFYL2JML3dCR3BYaDlBQ21rcGFUdFFBbEpUcWJpZ0FwdE9wS0FHbWtO TDJwTzFBQ2V0SlMwbEFDZHFhYWRUVFFBMDBocFRTR2dCRDBwdExTR2dCcHBEU21rTkFEYWJUcWJR QWxNTlBQU21HZ0JEVFRUalRUUUEwMDAwNDAyZ0JwcERTbWtOQURUVFRUalRUUUEwMGhwVFNHZ0J0 Tk5PcHBvQWFhU25HbTBBTk5JYVUwaG9BYlNHbHBEUUEwMGxPTk5vQVNtbW5VMDBBSWFTbkdtMEFK U1V0SlFBbElhV2tOQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFG RkZGQUJSUlJRQVVVVVVBRk9CeFRhS0FKMWt4VTZUWTcxU3BWUE5heHFORU9DWnNSVDFlaG5IcldK RWF1eEd2Um8xbWNkU21qY2huejNxOUZKbkZZa0I2VnB3R3ZXb1ZHeno2c0RVVnVCVHdhcm9lQlV5 MTZjV2NUSmgwcGFhdE9yVWhoaWt4UzBVd0drVTByVWxJYVZoblcvREJOdmlhNFAvVG0zL29hVjZ6 WGxmd3ovd0NSanVQK3ZSdi9BRU5LOVVyNC9PRmJFdjVIMEdYYTBRb29vcnl6dU1ieGIveUoycy85 ZVV2L0FLQ2E4NThVY1cvaFQvcnovd0RhS1Y2TDR0LzVFN1dmK3ZLWC93QkJOZWRlSitiZnduLzE1 LzhBdEdPbWdLY2YrcldzeldmK1BXWC9BSEcvbFduSC9xMXJNMW4vQUk5WnY5eHY1VTBJNE4rS2pK cVpxaklyb1pJenRUR3A5UnRVc0NHVHBWWnFzdWFyc0t6WTBSL3hWb1EvNnVxSVUxY2dHMUtJb1pv UkQ1YWVhYkczeTA0bml0MFNSUHhVRFZNOVJFVklFVklhY2FZMVN3R05WYVFWWVkxQTlReG9oTk9p NGI4YVFpbFJQbUgxcUJtbEYvckJWMGRLb3duOTVWemRtdWlPeEkxNnJ2VmhxZ2NVTUNCcVR0VDJG TXFHTVkxUk5VckdvWDZWQXlKdXRKUTFBcUJrc0hVMWZ0ZWpmV3FNQTYxZXRqaFcrdGFRSlphTlFQ VXBOUlAwclZpS3o5YWpOU3NLak5ac1kzdFRUVGlLWTFTeGtiVTJsTkpVQUZTSjBxT3BFKzdtbWhs NjNIeWo2MVB6VmVCc1JpcHdlT3RiZENXVXdRS2VyanNhbzVveldkeDJORHpnQlRIbTRxbUNhY092 ZWptQ3c4ak5SR05nZWxXRnAvVTBXdUNLbXh2U2xDc08xWGxVSHRUeEdEMnA4Z0ZBWkI2Vkl0V1do WDd1TVZBeTdXeFJhd0VpZ0RyVHc0SEdhcHRJVHhVWmM1Nm1pOWdzelVFb0hHYVZwaGpyV1lHUHJU aGswK1lWaXk4aGZpb25qM2pOSWd3YW1qNG8zQXFtSTloUXFONkdyNEFQYXBGUmZTamtDNVFDdG5w VGx5RHpXaDVROUtoa2lBRE4zcDhvWElmZXBoZ1ZGVURTRWpHYVY3QVh3eWp2VC9NVWQ2eXhJVDNw eXNjOWFPY0xHa1pRQndhZ1p0N1pxdjE3MUtnd0txOXdHdkZrNXFFeEhQU3J5ZE1VOEw5S1hMY0Nn RVlkcWVGWWRxMEFnUGFsOHBRT2xQa0FvcWVjVk12V25QR0Z5UlVMdVVHUlJzQllCVWQ2ZXJMNjFt bVUrdElKR1BRMGM0V05VU0w2MDE1UUJqTlVBeFBlbnJ5YWZOY1JNZVFjMUEwUnowcWNWS09hTFhB b2lKaDJwNFJ2U3J3WDJwK3dlbE5RQW9BTU8xV3JML2o4Zy82NkwvT3BHakI3VVdxNHZvQi8wMFgr ZE8xa0I3N29QL0lQaC8zQi9Lc3J4MS94NVdYL0FGMWIvd0JCclYwSC9rSFEvd0M0UDVWbGVPditQ S3ovQU91cmYrZzF6RkhMNmgveUkyZy85aFpmL1I3MTdmSDkydkVOUS81RWJRY2Y5QlpmL1I3MTdm SDkya01sNXBLS0tBS09zYVZCcmVrejZkY3ZJa00yM2MwUkFZWVlOeGtIdUs1VC9oVk9pLzhBUDlx Zi9meVAvd0NJcnVhS0FPRi80VlRvbi9QOXFmOEEzOGovQVBpS1gvaFZPaWY4L3dCcWYvZnlQLzRp dTY3MFVBY0ovd0FLcDBUL0FKL3RULzcrUi84QXhGSC9BQXFqUk1mOGYycC85L0kvL2lLN3J2UzBB Y0ovd3FqUlArZjdVLzhBdjVIL0FQRVVmOEtuMFA4QTUvdFQvd0Mva2Y4QThSWGQwdEFIQi84QUNw OUQvd0NmN1UvKy9rZi9BTVJTZjhLbTBQcDl1MVAvQUwreC93RHhGZDdSM29BNEwvaFV1aC84L3dC cWYvZnlQLzRpai9oVXVoZjgvd0JxZi9meVAvNGl1OUZBb0E0RS9DVFF2K2YzVlA4QXY1SC9BUEc2 UCtGUjZGL3ovYXAvMzhqL0FQamRkOTZVZDZBT0IvNFZIb09QK1AzVlArL2tmL3h1ay80VkZvUC9B RC9hcC8zOWovOEFqZGQrYVA4QUdnRHovd0Q0VkJvT1ArUDdWUDhBdjdIL0FQRzZUL2hUK2cvOC93 QnFuL2YyUC80M1hvSTZVVUFlZkg0UDZCL3ovYXAvMzlqL0FQaUtRL0IzUVA4QW4vMVgvdjdIL3dE RzY5Q29vQTg5UHdjMEQvbi9BTlYvNyt4Ly9FVW4vQ20vRC84QXovNnIvd0IvWS84QTQzWG9mZWln RHp2L0FJVTE0ZjhBK2Y4QTFYL3Y3SC84Ym8vNFV6NGUvd0NmL1Z2Ky9zZi9BTWJyMFdrb0E4Ni80 VXo0ZTczK3JmOEFmMlAvQU9OMGY4S1k4UGY4L3dCcTMvZjJQLzQzWG90QW9BODUvd0NGTCtIditm OEExYi92N0gvOFJTZjhLVzhPL3dEUC9xMy9BSDlqL3dEamRla0Nrb0E4NC80VXI0ZC81LzhBVnY4 QXY3SC9BUEc2VC9oU25oei9BSi85Vy83K3gvOEF4dXZTS0tBUE52OEFoU2Zoei9uL0FOVy83K3gv L0c2UCtGSmVIUDhBbi8xZi92N0gvd0RHNjlKSFNpZ0R6WC9oU1hodi9uLzFmL3Y3SC84QUc2UCtG SStHOC84QUgvcS8vZjJQL3dDTjE2VlFPbEFIbW4vQ2tQRFgvUDhBNnY4QTkvWS8vamRKL3dBS1A4 TmY4LzhBcS84QTM5ai9BUGpkZW1DazcwQWVhZjhBQ2p2RFgvUC9BS3YvQU4vWS93RDQzU2Y4S044 TkgvbC8xZjhBNyt4Ly9HNjlON1VkNkFQTWo4RGZEUDhBei82eC93Qi9ZdjhBNDNTZjhLTThNLzhB UC9ySC9mNkwvd0NOMTZkUlFCNWgvd0FLTDhNLzgvOEFySC9mNkwvNDNTZjhLSzhNZjgvK3NmOEFm NkwvQU9OMTZmUlFCNWgvd29yd3gvei9BT3NmOS9vdi9qZEgvQ2lmREgvUC9ySC9BSCtpL3dEamRl bjk2S0FQTHo4Q2ZDLy9BRUVOWS83L0FFWC9BTWJvL3dDRkVlR1ArZjhBMWovdjlGLzhicjFEdlJR QjVmOEE4S0g4TC84QVAvckgvZjZML3dDTjBuL0NoL0MvL1A4QTZ4LzMraS8rTjE2aDNwYUFQTGYr RkRlRi93RG4vd0JZL3dDLzBYL3h1Zy9BYnd2L0FNLytzZjhBZjZML0FPTjE2bDNwS0FQTHYrRkMr RnYrZ2hySC9mNkwvd0NOMG4vQ2hmQzMvUDhBNngvMytpLytOMTZsUjJvQTh0LzRVTDRXL3dDZi9X UCsvd0JGL3dERzZQOEFoUXZoYi9uL0FOWS83L1JmL0c2OVNvb0E4dC80VUw0Vy93Q2YvV1ArL3dC Ri93REc2WC9oUXZoYi9uLzFqL3Y5Ri84QUc2OVJvUFdnRHkzL0FJVUw0Vy81L3dEV1ArLzBYL3h1 ai9oUXZoYi9BSi85WS83L0FFWC9BTWJyMUtpZ0R5My9BSVVMNFcvNS93RFdQKy8wWC94dWovaFEz aGIvQUovOVkvNy9BRVgvQU1icjFHbG9BOHQvNFVMNFcvNS85WS83L1JmL0FCdWovaFF2aGIvb0lh eC8zK2kvK04xNmxTVUFlWGY4S0Y4TGY4LytzZjhBZjZML0FPTjBmOEtGOExmOC93RHJIL2Y2TC80 M1hxUGFpZ0R5Ny9oUTNoYi9BSi85WS83L0FFWC9BTWJvL3dDRkMrRnYrZjhBMWovdjlGLzhicjFJ MFVBZVcvOEFDaGZDMy9QL0FLeC8zK2kvK04wRDREZUZ2K2YvQUZqL0FML1JmL0c2OVJwUlFCNWIv d0FLRzhMZjgvOEFySC9mNkwvNDNSL3dvYnd0L3dBLytzZjkvb3YvQUkzWHFWRkFIbHYvQUFvYnd0 L3ovd0NzZjkvb3YvamRIL0NoZkMzL0FELzZ4LzMraS84QWpkZXBVVUFlVy84QUNoZkMzL1AvQUt4 LzMraS8rTjBmOEtGOExmOEFQL3JIL2Y2TC93Q04xNmxSUUI1ZC93QUtGOExmOC84QXJIL2Y2TC80 M1Ivd29Yd3Qvd0EvK3NmOS9vdi9BSTNYcU5Bb0E4dS80VUw0Vy81LzlZLzcvUmYvQUJ1Z2ZBWHdz UDhBbC8xai92OEFSZjhBeHV2VWFYdFFCNWt2d0w4TUwwdjlYLzcvQUVmL0FNYnFSZmduNGJYcGU2 ci9BTi9ZL3dENDNYcE5GV3B5V3pKNUl2Yzg5VDROK0hrNlh1cWY5L1kvL2pkVEo4SnRCVHBkNmwv MzhqLytJcnZhSzFXS3F4MmtRNkZON280Z2ZDN1JBUDhBajYxRC92NG4vd0FSVHg4TWRHSFM2djhB L3Y0bi93QVJYYVVDcit2WWorZGtmVmFQOHB4ZytHbWpEcGMzL3dEMzhULzRtbC80VnJvLy9QemZm OS9FL3dEaWE3S2luL2FHSi9uWXZxbEQrVTQ3L2hXdWpmOEFQMWZmOS9FLytKby80VnBvL3dEejlY Ly9BSDhUL3dDSnJzYVdqKzBNVC9PeC9WS0g4cHh2L0N0ZEcvNStyLzhBNytKLzhUUi93clRSditm cSsvNytKLzhBRTEyTkxSL2FHSi9uWWZVNkg4cHoraGVFTlA4QUQ5NjkxYVRYTHU4WmpJbFpTTUVn OWxIcFhRVVVWejFLczZzdWFidXphRUl3Vm9xeUNpaWlzeWpHOFcvOGlkclAvWGxML3dDZ212T1BF LzhBeDcrRS93RHJ6LzhBYUtWNlA0dC81RTdXZit2S1gvMEUxNXg0bi80OS9DZi9BRjUvKzBVb0Fx eC82c1ZsYTF4YXpmN2pmeU5hc2Y4QXF4V1JyM0ZqY2Y4QVhKLy9BRUUxUzNFY09XWDFwQ1BTczh5 c0QxcVJKaUsyNXJpc3ljamlvRGsxWUEzRUNwVmlBNHhUdGNSbmxXeDBwaGlKNXdhMVRHbzdVMGdl bEhJQm5MQ1QyeFU2cnRBRlRuaW8yNjB1V3d4NlM0R0tmNWc5YXB0dzNlb3l4SGVqbXNLeGZMcjYw emNwNzFubHlPOUlzakU0SnFlY2RpOCtNVkM5RWNoWTRxVkVEbm1udUJWS2s5alRDaDlLMHhHTWNp anl4NlVjZ0dYNVo0NHFSSVNXcTZWQTdVeGp4UzViQVJxZHBGVHJLRDNxczNTb2p4ME5GN0FYaklw NzAwc3ZyVkJtOXpUUE5ZZDZYT0ZqUU9EMHFKdXBxcXNwSE5XRk80Q2k5d3NSTm50VFNyRmVsWGtp QTZVL3lsOUtPVzRHWDVaUFkwTEVjOURXa3lLTzFSbmlseURLeW9VcWFPVFp4NjBqbk5SUHpSc0Jj RW85YVJwRjlhb0U0NzB3dDlhZk9GaThXWDFwalkyNXFwdlByVDBrSnd0TG11QkpVUnlhbXh6ZzFN c1FIU2kxeEZFcWZTazJ0NlZwR0pSVEdVQ2x5REtHd250VW9RcXVLbU9CVWJmZW81YkJjZWttQmlw aE5nZGFwTjF6VERuM291QWxGRkozcUJqMUZTQVV3ZHFlS3BDSEFjMUlEVEJUaDFwb0xFOGRXRnF2 RjFxeXRhb1FwR1JWQ1VZYzFmYjd0VUplV05LWUZOdnZHa3BXKzhhU3NIdVVQV3BsRlFwMHFaYXBD WThERk9IV205cVVWUWlaT2FzSUtycDFxeEgxclNMRVNqcFVjeS91MitsU3IwcUs0NGpmNlZYUUNr ZW1LcGsxYzVxaTNXc0pGSWN2TlRKVUMxT3RJR1NxS2tIcFRFcC9ldEVJY0RpcFVOUWpyVXFVeEZo T2xTWXFOT2xTQ3RVQkZNQnROWjl3Y0tLMEp2dVZRbkh5Vm5OQWlvVHpUMHFMdlVxVmlVV0VHZTFT Z1lxT1BwVXdyVkVpaW5xY0dveDFwNDYxU0FtV3BWcUpPbFNyVm9CeEZNaDR2N2YvQUs2TC9PcEQw elVjUC9IL0FBZjlkRi9uU2V3a2U5NkQvd0FnK0gvY0g4cXl2SFgvQUI1V2YvWFZ2L1FhMWRCLzVC OFArNFA1VmxlT3YrUEt6LzY2dC82RFhLV2N2cUgvQUNJMmcvOEFZV1gvQU5Idlh0OGYzYThRMUgv a1I5Qi83Q3kvK2ozcjIrUDd0SVpKUlJSUUFVdEpSUUF1S0tTbG9BS0tLS0FDaWlpZ0FwYVNpZ0Jh S1NpZ0JhTzlGRkFCUlJSUUFVVVVVQUZGRkZBQjNvb29vQUtLS0tBQ2dVVVVBRkZGRkFCUlJSUUFV VVVVQUZGRkZBQ1VHbG9vQUtLU2lnQmMwbEZGQUJSM29vK2xBQlJSUlFBZDZLS1NnQW9vb29BS0tL RFFBZHFLS0tBQ2lpaWdBb1BXaWlnQW9vb29BS0tLU2dCZTFKUzlxU2dBbzdVVXRBQjJvb29vQUtL S0tBQ2p2UlJRQVVVVXZhZ0JLTzFHS0RRQVk0b28vR2lnQmFLS0tBRXBlOUZGQUJSUlJRQUNsN1Vs TGlnQktXaWlnQW9vb29BTVV0RkpRQXRGSlMwQUZGSlMwQVkzaTMva1Q5Wi82OHBmL1FUWG5IaWYv ajI4Si84QVhuLzdSU3ZSL0Z2L0FDSitzLzhBWGxML0FPZ212T1BFL3dEeDdlRS8rdlAvQU5vcFFC Vmovd0JXS3lOZi93Q1FmYy85Y24va2ExNHY5V0t5TmY4QStRZmMvd0RYSi84QTBFMVFqekVtbFJ2 bUZNYWxoR1dwaGMwNCtXRld3dFZJODd4VndIaXVpT3hJMXFoYXBtcUI2QUkyTk1weHB0UXdHc0to Y1ZNM1NvWDZWTEdpdS9XbytRYWUzV21WbXlpeGJuNTYwTGNDcysySHpWZnQrOWFRSlpaSUhwVVQ0 cVU5T0tpZXRSRUxuazFFVFVqMUVhellEVFViQ3BLWTFTeGtMQ29UVXoxQzNXczJOQ0E4VmNpNVZh cGlya1gzUlZSQm1naS9LS2N3cEk2VnEzUktJSHFCcW5mcFZkcWhqR0drSTRwVFNIcFVBUk5VVGRh bGFvbXFHTkNVNlA3NHBvcDBmM3hRTmxqK0lWZlJlS29jN3hWK1A3dUsxaVNJd3F1NXF5MVZucHlB aFkweW50VE1WQXhwRk1JcVE4Q282aGdOb3hSUlFNZXRQRlJqaW5BODBDWktEVGhUVkdhbEFxa0JK SFZoZlNvRjRxVlRpdFVLeElUeGlxRXZEdFZsbjcxVlk3bXFaTUNvMzNqU1U5bE9TYVpqbXNyRkQw cVphaFVWSU9LWWlVZGFWYWFuTlNJTTFTRVBUclZsS2dVVkt0YUlST0RUSmptTnZwUnVHS2lrYktz TTgwN2hxVnowL0NxTERtcnZ0VlprUHBXTWlrUnFLblNvd09hZXZXa0JPdFBIV29WT0tsWG1yUWg0 SE5TSnhUVUhGU0tLc1JNblNwQlVLbkZQTGNjVmEwQWJOOXcxbjNQM0JWeVJzakZWcFZKWEZSTFVh S09PYWtTbFpQYWxWY1ZsWmpKa3FZRVZYVTFJcDVxMFNUQVU0RG1tanRVZ0ZXZ0pFNlZLS2lXcE0x YUFmVElmK1FoQi93QmRGL25RV3B0dWMzOEgvWFJmNTBwYkFqMzNRY2YyZkQvdUQrVlpYanYvQUk4 YlAvcnEzOHExTkEvNUI4UCs0UDVWbCtPditQS3pIL1RWdjVWeWxITDZqL3lJK2cvOWhaZi9BRWU5 ZTN4OExYaCtwRUw0RjBFbmdEVlYvd0RSNzE3aEg5MzJwREpLS1NqbWdCYUtTbG9BS0I3VVVVQUZM U1VVQUxSU2RxV2dBb3BLV2dBb3BLV2dBcGMwbEg1VUFMUlNVVUFMUlNVdWFBQ2lpa29BWHRTVXZh a29BV2lrcGFBQ2lrcGFBQ2lpak5BQlJTVVVBTFNVVVVBSEZGTFNVQUZGSDQwVUFGRkZGQUJSUlJR QVVVbEZBQzhVbEZGQUJSUlJRQWZTaWlqdlFBVVVVbEFDMFVsRkFDMGQ2U2lnQmFCU1VVQUZMU1VV QUZIMG9vb0FLS0tLQUNscEtLQUNpaWlnQlJTVVVVQUxRS1RpaWdCVFJTVVVBTFJSK05GQUJSMm9v b0FXaWtwYUFDaWtvNW9BV2lpaWdBRkxTVVVBTFNVVXRBQlJSUm1nQW9vb29BS0tLT2FBRm83MFVV QVkzaTMvQUpFN1dmOEFyeWwvOUJOZWNlSi8rUGJ3cC8xNS93RHRGSzlHOFhrTDROMW9rZ0Q3Rkwv NkRYbkhpYi9qMjhKLzllZi9BTFJTZ0dWb3grN0ZaR3ZmOGcrNS93Q3VULzhBb0pyV2kvMVlySjE3 L2tIM0gvWEovd0QwRTFRanpCaFNvQ0dGT0tWSkhIOHc0cWtnTGtYM3htcmRVMStVaXJBYk5iUkpI SGlvbnFSalRDTWlxQWdJcHRTa1ZHd3dhaXdER3FGNmU1NXFKNmhqUkEvV21WS3dwQWhyT3d4OXQ5 NDFvMi9TcVVLRU5WdUpzRTFyQVRMUnFKcVVObWtKclFSQS9Xb2lLc0VaNlZFeTRGWnNDSTB4alQy NlZFeHFSa2IxQzNXcFRUQ3VhelkwTUZYSWZ1clZkVXF5Z0txS3FJMmFFZjNSU3RVS1NEQUZQTGNW c21UWWplb0dxZHFpWVZMQWhJcHA2VTl1T0tqYW9HTWFvbXA3VXdnMURRQ1U2UDc0cHVLZWdPNFVJ WlAvQUJpcjZuQzFRSEpxeWorOWF4SkpXeFZkNmxMWkZSbnBUWUVEVXlwbUZSTU1Hb0dOWTFIU3Nl Y1Uyb1lGa1JLZWFjSUVwRk5UcHpXbGhFUDJkZWFZMEdCeFY0TFRYWEMwK1VDbm5hS1kweHp4US8z YWh4V2JkaG9sODlxY0oyUGVvTzlQVVVyakpESXhOT1hrVXdEbXBCVkNIN0ZaZHA2VTRRS2UxTkJx WktxMXdFK3pKUWJaYXNMVHlNNHF1VVJuK1dVTklKQWdQYXJGeU9sVXB1MVM5QUhmYUdwUmN2MnFy VDFxZVpqTFBudFFHSmFtS0tlb3AzRVNkYWsyS3d3YWlxVlRWQUw5blUwNFdxVTVLbVVlMVVvaUt6 VzZnZEtqQ0ZPRFY4cjZWVm40ay9DaHF3RVJsQ2pIZW8vdExDbzV6aVEvU29jNU5adGxGc1hEMDRU dm5OVmw5Nm5VQ21tSWNwSmFwbEhOUmdWSXZGVWhEdkpROXFYN09ocFZOU3JWMkFqK3pyNlV4b01I aXJZcEdIRlBsQXFmZHBqWEJIU25TSDVXcWl6Vm0zWVphRnkxT0U3R3Fpbm1wa3BLUUUzbXMzV3JO anplUWY4QVhSZjUxVkM4MWJzdUx5RC9BSzZML09yNkNQYzlHdTVZdFBqQ1djOCtGSCtwVXRXWjRv bm0xSmJlSmJhYTNLRW45L0V3eitsZFg0TC9BT1FaK0kvOUJGYk91eVBGWXdPamJXRXVNL2hYT1dl SWEvRnFOMTRYdDlDc3RPdVpMaTNuOC83UXE0UTVabTQ3L3dBVmRmcFBqN3hQQllSeGFqNFZ1Slow VUswc1RZRGUrSzZnWDkxL3oyUDVVdjIrNnovcmpTQXhmK0ZoYXY4QTlDamZmOTlDai9oWWVzZjlD ZmYvQVBmUXJhL3RDNi81N0dsL3RDNy9BT2V4b0F4UCtGaDZ4LzBLTjkvMzBLUCtGaDZ4L3dCQ2hm Zjk5Q3R2KzBMdi9uczFML2FOMy96M2FnREQvd0NGaDZ4LzBLRi8vd0I5Q2ovaFlXc2Y5Q2hmL3dE ZlEveHJjL3RHNy81N3RSL2FONS96M2FnREQvNFdGckgvQUVLRjkvMzBLUDhBaFllcy93RFFvWDMv QUgwSzNmN1N2UDhBbnUzNlVmMmxlZjhBUGR2MG9Bd3YrRmg2eC8wS0YvOEE5OUNsL3dDRmhheGov a1VML3dETVZ1ZjJuZWY4L0RVdjlwM3YvUHcxQUdEL0FNTEQxai9vVUwvL0FMNkgrTkwvQU1MRDFq SC9BQ0tGL3dEOTlEL0d0MyswNzMvbjVhaisxTDMvQUorR29Bd3YrRmhheDI4SDMvNWlnZkVMV1A4 QW9UNy9BUE1WdS8ycGUvOEFQdzlML2F0OS93QS9MVUFZUC9Dd3RaNmY4SWhmL21LUCtGaDZ4LzBL Ri84QW1LM3Y3VnZ2K2ZsNlA3VnZ2K2ZsNkFNSC9oWWVzZjhBUW4zL0FQMzBLUDhBaFllc2Y5Q2Zm L21LM3Y3V3YvOEFuNWVqKzFyL0FQNStYb0F3ZitGaDZ6MjhIMy81aWsvNFdIclAvUW4zL3dDQkZk Qi9hOS8vQU0vTDBmMnZmLzhBUDA5QUdBUGlIclBYL2hENy93RDc2RkgvQUFzUFdmOEFvVDcvQVBN VnYvMnZmLzhBUDA5SDlyMy9BUHo4dlFCZ2Y4TEQxbi9vVDlRL01VZjhMRDFqL29UNy93RE1WdjhB OXI2aDJ1bm8vdGUvL3dDZmw2QU1BZkVQV1A4QW9UNy9BUE1VZjhMRDFqL29UNy84eFcvL0FHdnFI L1AwOUg5c2FoL3o5U1VBWUgvQ3d0WS82RSsvL01VaCtJZXNqL21UNy84QU1WMEg5c2FoL3dBL1Qw ZjJ4cUgvQUQ5U1VBYy8vd0FMRDFuL0FLRS9VUDBwZitGaGF6LzBKK29mcFcvL0FHeHFIL1AxSlIv YkdvLzgvVWxBR0Ivd3NUV1Ivd0F5ZnFINWlrLzRXSHJQL1FuYWgrWXJvUDdaMUQvbjZrby90alVl MTNKUUJ6Ly9BQXNUV2Y4QW9UdFEvTVVmOExFMWovb1R0US9TdC84QXRuVVIvd0F2Y2xIOXNham4v ajdrb0F3UCtGaWF6LzBKK29mbUtQOEFoWW1zZjlDZHFQNlZ2LzJ6cVgvUDNKUi9iT28vOC9jbEFH Qi93c1RXUCtoTzFEOUtUL2hZdXNmOUNkcVA2VnYvQU50YWwveitTVWYyMXFYL0FEOXlVQVlIL0N4 ZFkvNkUvVVAwby80V0xySC9BRUoyb2ZwVzkvYldwZjhBUDNKUi9iV3BmOC9rbEFHRC93QUxGMWov QUtFN1VQMHBQK0ZqYXdQK1pQMUg5SzN6cmVwZjgva2xIOXQ2bC96K1NVQVlIL0N4dFgvNkU3VWYw by80V05xLy9RbjZqVzkvYmVwZjgva241MG45dDZuL0FNL2t2NTBBWVgvQ3h0Vy82RTdVYVA4QWhZ K3Ivd0RRbjZqVzcvYmVwZjhBUDVKUWRjMVAvbjhrL09nREIvNFdQcS8vQUVKK28vbFIvd0FMSDFi L0FLRS9VZnlyZC90dlUvOEFuOWwvT2tPdWFuL3oreTBBWWY4QXdzZlZ2K2hQMUdqL0FJV1JxMy9R bjZqK1ZiaDF6VSsxN0xTZjI1cW4vUDdMUUJoLzhMSTFiL29UdFMvS2svNFdUcXYvQUVKMnBmbFc1 L2J1cWY4QVA3SitkSDl1NnAveit5Zm5RQmlmOExKMVgvb1R0Uy9Lay80V1Zxby81azdVdnlyYy90 M1ZQK2YyWDg2VCszZFUvd0NmMlg4NkFNVC9BSVdWcXY4QTBKMnAvbFNmOExLMVgvb1R0VC9LdHY4 QXQ3VlArZjJYODZQN2UxVC9BSi9aZnpvQXhmOEFoWldxL3dEUW5hbC8zelNmOExMMVgvb1R0Uy83 NXJiL0FMZDFUL245bC9PaiszdFU2ZmJwZnpvQXhQOEFoWmVxZjlDZHFmOEEzelIvd3N6VkIvekoy cC85ODF0LzI5cXYvUDhBUy9uUi9idXFIL2wrbS9PZ0RFLzRXWnFuL1FuYW4vM3pSL3dzelZQK2hP MVAvdm10ciszZFZISDI2Yjg2UDdlMVgvbitsL09nREYvNFdacW4vUW5hbi8zelIvd3N6VS8raE8x UC92bXRrNjlxdi9QOU4rZEExM1ZmK2Y2Yjg2QU1iL2habXFmOUNkcWYvZk5IL0N6TlUvNkU3VS8r K2EydjdlMVgvbi9tL09tLzI3cXYvUDhBVGZuUUJqZjhMTjFQL29UdFUvNzVwUjhUZFQvNkU3VS8r K2EyUnJ1cS93RFAvTitkTC9idXFmOEFQOUwrZEFHSi93QUxOMVAvQUtFN1UvOEF2aWwvNFdicWYv UW5hcC8zelcxL2J1cWY4LzAzNTBoMTNWZitmNlg4NkFNWC9oWm1wLzhBUW5hbi93QjgwdjhBd3N6 VS93RG9UdFUvNzVyYS90M1ZmK2YyWDg2UDdkMVQvbjltL09nREYvNFdicWYvQUVKMnAvOEFmRkgv QUFzM1UvOEFvVHRUL3dDK2EydjdkMVQvQUovWnZ6by90elZQK2Y2Yjg2QU1YL2hadXAvOUNkcWYv Zk5IL0N6ZFQvNkU3VS8rK2EydjdjMVQvbittL3dDK3FQN2MxVC9uK20vNzZvQXhmK0ZuYW4vMEoy cC85ODBmOExPMVAvb1R0VC83NXJiL0FMZDFUL24rbS83NnBQN2MxVC9uK20vNzZvQXhmK0ZuYWwv MEoycC85ODBmOExPMVAvb1R0VC83NXJiL0FMYzFUL24rbS83Nm8vdHpWUDhBbittL09nREUvd0NG bmFuL0FOQ2JxZjhBM3pSL3dzN1Uvd0RvVHRUL0FPK2EyLzdjMVQvbjltLzc2by90elUvK2YyYi9B TDZvQXhQK0ZuYW4vd0JDZHFmL0FIelIvd0FMTzFQL0FLRTdVLzhBdm10diszTlQvd0NmNmI4Nlgr M05ULzUvWnY4QXZxZ0RELzRXZHFmL0FFSjJwLzhBZk5BK0orcC85Q2RxZi9mTmJuOXQ2bi96K3pm OTlVdjl0Nm4vQU0vczMvZlZBR0Yvd3MvVlAraE8xVC92bWovaForcC85Q2Jxbi9mTmJ2OEFiZXA1 L3dDUDJiL3ZxbC90dlV2K2YyYi9BTDZvQXdmK0ZuNm4vd0JDZHFmL0FIelIvd0FMUDFQL0FLRTdV LzhBdm10NysydFMvd0NmMmIvdnFqKzJkUy81L1p2KytxQU1IL2haK3AvOUNkcWYvZk5IL0N6OVQv NkU3VS8rK2EzL0FPMmRTLzUvWnY4QXZxay90blV2K2YyYi92cWdEQi80V2ZxZi9RbmFuLzN6Ui93 cy9VLytoTzFQL3ZtdC93RHRuVXYrZjJiL0FMNnBmN1oxSC9uOG0vNzZvQTUvL2hhR3AvOEFRbmFu L3dCODBmOEFDejlUL3dDaE8xUC9BTDVyb1A3WTFML244bS83Nm8vdGpVZitmeVgvQUw2b0E4NzhZ K04vRlBpSFJwdExzdkROM2FRenJzbGtkR1ppdm9NQ29yelYyMXBOSmovczY5czIwMkR5M004Sklr T3hWNDI1L3VrODE2Vi9iR29qL2w4bS93QytxUDdZMUgvbjltLzc2b0E4K3RJNUpseEhEY1B6ejVk dEkyUC9BQjJxM2lEVFpZZEpubWtKWDVDQ2pveU1NZzlqWHIxbEk4c0xTT3haMmZMTWVwT0JYQ2ZF Yi9qeXVmOEFya3YvQUxOVFc0SGlua0lLQWlxS2thb3llSzZTQmpIamlvL01aZWhwK0tqWVZJQjlv Y0NtbTZhbzNHS2hZODk2aHNkaTJ0eVNlZWxQM2J1ZTFaKzd0VjJFZ3BUVHVNa1dMY2NucFR2c3kx UEd2eTA4cjYxcFlrcUczU2p5RUZUdnhVSlBGS3dER1VEcFVUa2lwU2FqZXBZeG5uT0tRM0QrdE5Z Y1ZFd05UY0VUZmFYcDZ6NTYxU3pqclRrWUZxVnhsekc3aW5yYmcwUmY2d0NyWVdyU3VTVmZzeVUw MnlDcmJBVkMzRk54U0dRK1dxOUtZMVBZMHcxTEFqM3NyWkZJWjNBelNzS2lZY1ZEWXgvMmg2UVhE WnFBMGc0cFhZRnpmdjhBd28yRnpuSEFxR0U5YXUyd3lwK3RWSFVRejdNRFNmWmxGWENNVkUzU3Jz QldNQ2lrWlFGd0JValZHYWxnTXBtOWxQR2FlYVkxSUVKNXpEdlI1ejFHYVNvdU1rRXh6elR5Mjdt b0trVDd0Q0dQRVc0NXhUL0lGVFFMbEJVb0hBclJSSkthMVppcXN2V3JNVkVRTEMwMlhLajhLY3RO bDVXcllqTmNmS2FocVovdUdvYXhaU0U3MUt0UmQ2a1drTWxBcDlNQnB3TlVJY3RUSlVJcVpLcENM S2RCVW9GUXAwcVlIaXRFSXFYSjZWUW42Q3I5MTJxaFAyck9ZeUducFRNMDlheUdUcFVvRlJMVW9y UkNEdlQxcG5lbnJWTGNSTW5XckNWWFFWWVRwV2tRSk8zU3FkenpKK0ZXKzFVN2ovV2ZoUklDaGNE OTRmcFVTL2VxYTQvMWgrbFFyd2E1M3VVVEp3YW5YMnF1bldyQzFTRVNDbkRyVFJUaDFxeEQxUE5U SjBGUXIxcWRPZ3EwQktLVmpnVWdvYnBWZEJGR1laRGZTczVoZzFwUzlHck9ibHF3a1VoeVZZakdL cnB3YXNJYUVESnhWbTAvNC9ZUCt1aS96cXN0V2JQL0FJL1lQK3VpL3dBNnRDUGQ5QTFxTFN0UFh6 SVhrVmdEbE8zRlI2LzQ3c2JpM2h0N2Z5NDNWOXovQUdpVlY3ZHF0NkJ4cDhQKzRLeXZIWS8wU3pm djVqRFA0VmhZczV5NytKbGpaM0xXekJKSkY2bUxMcitCRk4vNFdiYi9BUFBuTi8zNWF0ejRLYURw OXgvd2tXcjNGckZOY3JlL1o0M2RjN0YrOGNmWEkvS3ZXdnNkci96N1JmOEFmQXBBZUUvOExOZy81 ODV2Ky9MVWY4TE5nLzU4cHY4QXZ5MWU3aXh0RC95N1JmOEFmQW8vcyt6UC9MdEYvd0I4Q2dEd2ov aFowSC9QblA4QTkrV28vd0NGblFmOCtjMy9BSDVhdmQvN05zai9BTXUwWC9mQXBQN0xzVC95Nnhm OThDZ0R3bi9oWjF2L0FNK2MzL2ZscVA4QWhaMEgvUG5OL3dCK1dyM2lQVExBai9qeWczRC9BR0JR Mm5XYTlMTzMvd0MrQlFCNFAvd3M2My81ODV2Ky9MVXh2aW5aeGo1N2VSZnJFd3IzWnJhMlhwWjIv d0QzN0ZZdmlUU2RQdjhBUUwxSnJHM09JbVlFUmpJb0E4aUh4WHNHT0VpWW4wRWJWSi93czZEL0FK ODV2Ky9MVnY4QXdMOFA2ZVBEdXA2ak5heFNYSnZtZ1YzWEpWRlVjRDhUWHEvMksxLzU5WWYrK0JR QjRWL3dzNkQvQUo4NS93RHZ5MUgvQUFzNkQvbnpuLzc4dFh1b3NiTS84dTBQL2ZJby9zK3pQL0x0 RC8zd0tBUEN2K0ZuUWY4QVBuUC9BTitXcFA4QWhaMXYvd0ErYzMvZmxxOTIvc3l5L3dDZldML3Zn VUhTcklqL0FJOVlmKytCUUI0Vi93QUxQdHYrZk9iL0FMOHRSL3dzNjMvNTg1LysvTFY3eEhwbW5z dkZsQUNPdnlDaHRPczE2V2NIL2ZBb0E4SC9BT0ZuUWY4QVBuUC9BTitXcU4vaXJaUm5Ed092MWpZ VjdzMXJiTC95NTIvL0FIN0ZjMTQyMGZUci93QUo2aDV0aGI3a2lMS3dRQWlnRHkxZml0WU9kcVF1 eDlCRzFTZjhMT2c3V2MvL0FINWF1cStCK2hhY3ZnRmRTZTBpa3VybTZrRFNPdVR0WEFBK2xlbWZZ N1QvQUo5WWYrK0JRQjRWL3dBTE9nLzU4NS8rL0xVZjhMT3Qvd0Ruem4vNzh0WHUzMkd6L3dDZmFI L3ZnVW45bjJaLzVkWWYrK0JRQjRWL3dzNjMvd0NmS2Y4QTc4dFNmOExQdC84QW56bi9BTy9MVjd0 L1p0a2V0ckQvQU44Q2c2WFk5clNFL3dEQUJRQjRWL3dzKzMvNTg1LysvTFVmOExPdC93RG56bi83 OHRYdkthWHA3TGxiS0QvdmdVamFkWnIwczdmL0FMNEZBSGczL0N6b0IveTV6LzhBZmxxWTN4VXNV SUR3U0w5WTJyM1pyVzJYajdIYi93RGZzVnhmeE4wYlQ3dndQcUVyV1VDeXhKdVIwUUFnODBBZWVy OFZiR1J0c2NEc2ZRUnNhZjhBOExPZy93Q2ZLZjhBNzh0WGRmQi9RdE90dmh6cDE1OWpoYTV1akpK Skl5QWx2bUlINkN1OCt4Mm4vUHJEL3dCOENnRHduL2hac0gvUGxQOEE5K1dvL3dDRm5RZjgrVS8v QUg1YXZkL3NObi96NncvOThDait6N1AvQUo5WWYrK0JRQjRQL3dBTE90LytmS2YvQUw4dFIvd3M2 RC9ueW4vNzh0WHUvd0RadGtmK1hXSC9BTDRGSWRNc2UxcENmYllLQVBDUCtGblFmOCtVL3dEMzVh bC80V2JCL3dBK1Z4LzM1YXZmRTB2VG5YY3RsQi8zd0tSdE9zMTZXY0gvQUh3S0FQQXo4VG9QK2ZL Zi92MDFSTjhWYkpEaDdkMStxR3ZmSHRiVWY4dWR2LzM3RmVkL0dEUjdDYndMYzNZc29JNTRTQ3Jv Z0JvQTRoZmluWnlOaU8ya2Y2UmsxSi93c3lIL0FKOFovd0R2eTFlbC9EUFFkT3NmaDlvc3EyY0pt dUxZVFN1eWdsbVlrMTF3dExUL0FKOUlQKytCUUI0Si93QUxNaHovQU1lTngvMzZhbC80V1pEL0FN K054LzM2YXZldnNWbWYrWFdIL3ZrVWZZTE0vd0RMckQvM3dLQVBCRDhUWWY4QW54bi9BTy9UVWgr SmtQOEF6NHovQVBmcHE5Ny9BTE5zVC95NlEvOEFmQW9PbVdJNSt4d0gyMkNnRHdUL0FJV1pEL3o0 ei84QWZwcVArRmx4ZjgrRS93RDM1YXZvSk5LMDVsRExaUWY5OENtdHB0a3ZTenQvKy9Zb0ErZmo4 UzRoL3dBdU0zL2ZwcWlQeFRzMU8xN2RsUHVwcjZBYTB0Ui95NTIvL2ZzVjVYOGNOSHNQK0VQUy9q czRZcmlPWlFIUk1IR1IvalFCeWFmRkcxYy9KYXlOOUVKcC93RHdzcVAvQUo4Si93RHYwMWV1ZUQ5 QzA3Uy9DT2p4dzJVQVpyT09SMktETE1Sa2sxdWkxdGovQU11MFAvZkFvQThGUHhLai93Q2ZDZjhB NzlOU0g0bFIvd0RQaE4vMzZhdmZEWTJwL3dDWGFML3ZrVTMrejdQUE50RGdmN0FvQThGLzRXVkgv d0ErRTMvZnBxUCtGa3gvOUErZi92MDFlOWZZN0VmOHVOdC8zN0ZIMmF6SFN5dC8rL1lvQThFLzRX U24vUVBuL3dDL2JVZjhMSlQvQUtCOC93RDM3YXZlVERhai9senQvd0R2MktUWmJqL2x6dC8rL1lv QThHLzRXU2cvNWg4My9mdHFpUHhSdFZiRDJ6S2ZUYWE5OElnLzU4N2IvdjJLOG0rT1drMlowT3cx Q0cwaGh1UFA4c3ZHdTNJb0E1NWZpZEJKOXl6a2I2S1RUeDhTRi82QjgvOEEzN2F2YjlJMFRUZEsw bXl0YmF4dDFWYmVQK0FjbmFNMWZGcmJIL2wyaC83NEZBSGdKK0pDL3dEUU9uLzc5dFNmOExKWC9v SHpmOThOWHY1c2JVLzh1MFgvQUh3S2FMQ3p6azIwSkEvMkJRQjRGL3dzbFQvekRwLysrR28vNFdR di9RTm4vd0MvYlY3L0FQWXJFZjhBTGhiL0FQZnNVaHRiTWRMSzIvNzlpZ0R3SC9oWksvOEFRTm4v QU8vYlVmOEFDeUYvNkIwLy9mdHE5ODhtMUgvTG5iLzkreFNGTGNmOHVkdi9BTit4UUI0Si93QUxK VWY4dzZmL0FMNGFvdjhBaGFkcUNRMW93UDQxNzhWdC93RG56dHYrL1FyeHo0MTZKWW04MEs1aHRJ b1pMaWNReUdKZHU0RS8vV29BeDArSjBNZ3pIWVNNUFpTYWQvd3NsUDhBb0czSC9mRFY3ekJwR25h YkdscmJXRnVrY2FoUU5nOUtuRnJiSC9sMWgvNzRGQUh6L3dEOExLVC9BS0JzL3dEM3cxSC9BQXNw ZitnWlAvM3cxZS9teXRUL0FNdTBYL2ZBcEYwK3pKeWJTRWowMkNnRHdEL2haU2Y5QXlmL0FMNE5P LzRXVW4vUU5uLzc0YXZvRDdEWWovbHh0LzhBdmdVMzdKWmpwWlcvL2ZzVUFlQS84TEtYL29HWEgv ZkRVZjhBQ3lrLzZCbHgvd0I4Tlh2cGd0Ui95NTIvL2ZzVTB4Mnc2V2R2L3dCK3hRQjRJZmlXbmZU Wngvd0JxaS80V3BaanJadUs5K0tXNTYyZHNSLzF6RmVNZkZUdy9ZTjQ5OE50RmFSUkxleXJITXFM Z044eS93RDE2QU14ZmlkQzR5bW56TVBVS1RTLzhMTFQvb0dYSC9mQnIzdGRPc0xKbWdnc2JkVVE3 VkFqSFFWSUxhMlAvTHJEL3dCOENnRHdIL2haYUQvbUdYSC9BSHlhVC9oWmEvOEFRTW4vQU8rV3Iz ODJWcDN0b2Y4QXZnVWlhZlprNWEwZ0k5Q2dvQThDSHhNVC9vRjNIL2ZKby80V1duL1FMdVArK0RY MEI5Z3NCL3k0Vy84QTN4U0d6c2gwc2JmL0FMOWlnRHdIL2haa2YvUUx1UDhBdmswZjhMTmovd0Nn VmNmOThtdmZEYjJnL3dDWE8zLzc5aW0rVmJEL0FKYzdmL3YyS0FQQlQ4VG9sR1RwZHdCN3Fhai9B T0ZzV1gvUG0rYTk3YU8yUEJzN1lqL3JrSzhaOForRzlPUHhxOFBXOGRwRWtGODZHV0pWd3JFZTFB R2N2eFJoY1pYVFoySHNwcDMvQUFzNU1mOEFJS3VQKytXcjNoYkt4dHlZb3JHM1ZGT0IrN0hTcGZz dHFmOEFsMGcvNzRGQUhnWC9BQXM2UC9vRlhIL2ZMVW4vQUFzK1BQOEF5Q3JqL3ZrLzRWNzRiSzAv NTlvZisrQlNwcDFrZVdzNENQUW9LQVBBeDhUNHYrZ1ZjZjhBZkpwZitGbnhmOUFxNS83NE5lL2Yy ZllEL2x4dC93RHZpayt4V1EvNWNyZi9BTDlpZ0R3UC9oYUVYL1FLdWY4QXZrLzRVZjhBQ3o0ditn VmMvd0RmSnIzczJ0b09sbmIvQVBmc1V3dzJ3LzVjN2Y4QTc5aWdEd1p2aWxDZ3kybDNBSHVDS3Rh ZDhSN2JVbWRZcmVPTjBHU0pwZ21mcG5yWHRqUld6REJzN1lqL0FLNWl2Qy9HZWtXbWsvRndmWW9F Z2pudFRLeVJqQURjZ21nRHNOUDhlV3kyK3g0SWkrYy9KZEpqcFdGNDExaVBVTklubVV4cTdCVkVZ azNISHJ4OWFnais1N21zVHhCL3g1eWZUK3RVbHFJNDFxaU5TdFVacm9aSTNGTWFuOXFZMUlDQ1Rw VlordFdYeGlxelZreWtNSDNxdndERWZzYW9nYzFlZ09VK2xFQk0wSWlTb3A1cGtTNFhGT05ib2to ZW9XcVorOVF0VXZjWkdhUTB1TVVocVdCRzFWM3FkdWxRT0t6WTBRdFN4akxmalNIaW5SOE1QclVy Y1pwUW5FbFhBT0twdy82d1ZkNlYwUjJKR04wcXMvV3JMZEtyUFF3SVd6U2RxVTBsWnNCakNvbXFV OUtpYXBZeUZ1dEpTdDFwS2tvbWc3MWZ0Q2NOOWFvUWZ4VmZ0UnczMXJTQkxMSnFCNm1OUXZXakVW MnFJMUkxUm1zMk1TbW1uZHFhZWxTTWlhbTA1cWJVQUZTSjkybzZrVDd0TkRMOXNma0E5NmxOUTIv Q0ErOVRkYTNXeExLYWptcGtPRFZVVGdVdjJqMnJOTWRpL3U0cUozK1dxMzJqaW1HVWtBVlhNRFFq L2ROUTFZQzdxREQ2Vm0wQ0srS2N0Uy9aMnBSYnNLTE1ZMEhtcEJTR0ZsN1VvR09LYVFpUlJVcWRh aDNoUlNDNUFxN2lMeW1uRjhjWnFrTHFnM1AxcHFRV0pMaHNnVlRtSFNwUklXT0RUbFFQVXZVWlJJ NXA2OFZaK3pVZlpUMXFlVVpHcHFSVHpUaGJzS1FJUTM0VTdDWTZwVkdLaUFwNWtDaXFRaWRhbVUx U0Z5QlRoZEE5S3Jtc0ZtWFN3SGVxczNNbE1OeG1tcTI3azBPVnhGZVpjeVZGdHdhdmVVSFgzcHYy WG1zM0VaV1hGVEtha0ZxMmV0T0ZzMU5SWURWT2FsQTVxSUtWYXBWT0RWQ0pGcVZhcmVjb29GMEFl OVVtZ0xvTk5MY1ZXKzBnbW10TVQwcDh3Q3Z5R3FpeWUxWGdNMGpXK2VsUTFjWlNVWXFaRGlwaGEv blR2c3hGSlJBWURWdXg1dklQK3VpL3pxdVlHWHRWaXhHTHlBSC9BSjZML09yc0k5LzBFZjhBRXZo LzNCL0tzcngzL3dBZU5uLzExYi8wR3RYUWYrUWZEL3VEK1ZaWGp2OEE0OGJQL3JxMzhxNXlpNzhF Qmp3OTRnLzdDemYrZ3JYcFlyelg0SWY4aTk0Zy93Q3dzMy9vSXIwck8zNWp3Qnp6U0djUjhUUEU2 NlQ0Um4vc3pVVVRVSG1TSmZKbFV5SnpsdW5Ub2Z6ckQ4WitKTDdUUEEyZ1dkaHJUTnExeTBhejNF VTZzLzNmbTNIdDh6RDhxd3ZIUGhYUTA4YmFSWjZkSTVsMVc0YVc3Y3poZ29aeG5IOTMrS285VDhF K0hrK0p1bStIckNTWDdESkY1dDA3VGhqL0FCSEFidHdCK2RBSHVOazBiMmNYbDNDM0FWUXBsVncy NGdjOGlyQTVySjhPYUJZZUdkSVRUdE1NaHRnN1NLWkgzSExkZWExeFFBMXZrSWNkdXRUN1ZkUVIz cUx0aW13dnNEb2Y0ZVI5S0FHU3hZcksxaGNhTmZIL0FLWU5XOGNTSldQcnFiZER2LzhBcmlhQU9F K0Ivd0R5STk5LzJGSmY1TFhvTjdkTFkyRnhlUEhKSXNFYlNNa1l5eENqSkE5Njg5K0Ivd0R5Sk4v L0FOaE9YK1MxNlRqT1FSa2RPYUFQQi9FL3hWOFFhZzhVMmxMTnBOZ2QzbE50RFBOanFTeEdPUFFk Szl1MFdhUzUwTFQ1NW5MeXlXMGJ1eDdzVkJKcnlMNDVxcVhlaUlpS3FMQkxoVkdBUG1XdldmRC9B UHlMZWwvOWVjUC9BS0F0QUdtS1drSFdsb0FhVDViYngwNzFaS2hoa1lxQWpJcElwTnNaVS93SDlL QUd5eGUxYy80cVhiNFcxUFAvQUR4TmRSeEl1YTUzeGd1M3dwcVgvWEkwQWN2OEUvOEFrbGxsL3dC Zk0vOEE2Rlc3NDIxblY5QzBIN1ZvMWdMMjVhUlk4SExlWG5nTnRITGM4ZmpXRDhFLytTWFdmL1h6 Ti82RlhvQ25Cb0E4Y3ZGK0xkdlpTYXJOY2xFUmZNYUNQeXl5cjErNWovNjlkYjhOZkhNM2k2enVM ZS9TTmIrMTJzelJqQ3lxZWpZN0hJNXFMNGhmRUN6OFBXVStsMlRyUHE4eUZOcThpRU1NYm05K2VG cW44SXZDRjVvTmpjNnBxVVpodUx4RldPRnVHV01jNVlkaVRRQjZXT0tXa3BSUUFCdktjUDhBd25o cXNsUXc3VldZWkJGSkhNVmk1UEtuYlFBU3hWeVB4RFhiNEQxWC9ya2Y1R3UxQldSYzF4L3hKWGI0 RDFUL0FLNUgrUm9BcS9Ddi9rbDJoZjhBWE4vL0FFTTFvZU1iM1hyRFFqTjRkczQ3cStNaXBzWmR4 VlR4dUM5K2NWbmZDbi9rbDJoLzdqLytobXV3WHJRQjQ3cUsvRmpTYkNUVnJpK1Zvb2wzeXhSdEc1 UmUrVngvS3V5K0hQaktYeGhwRTV1NGtqdmJWMVdVeDhLNElPR0E3ZER4WEllT2ZFdmpxTzMxV3pP a2VScEJlU0w3V2tCSk1XY0E3c25HUjN4WFIvQ1cyMEszOE5TdHBGMjl6Y1BJRGVHUk5qSStPRjIr bm9lOUFIb0ZMVFJUaFFBSS9sU2cvd0FMZGF0TW9JcW95N2xJb1djckdwSjZIYWFBRmxpcmdmaTJ1 MzRjNmovbnRYb2dZU0ptdlA4QTR3cnQrSGQveDJvQTFQQVgvSk8vRHY4QTE0eDBuamJ4TW5oUHcz TmYvSzF5eDhxM1E5REllNTloeWZ3bzhBLzhrNzhQZjllTWRjTDhWTTZwNDI4TjZHeFBrc1ZaaC92 dnRQNkxRQjNQZ0k2MC9oSzBuMTY1TTkzUCs5WGN1R1dOdnVnK3A3L2pYUzBnQ3FBcThLT0FCNlV0 QURxUHhwS1dnQjBUK1ZKZy9kYXJKQWJpcWJydVVpajdSdFZHUGZnMEFQbGk5cTh3K09BMi9EOS8r dXkvekZlcUJsa1RJcnkzNDdESGdKaC8wMVgvQU5DV2dEczlDR2ZEV2ovOWVNUC9BS0NLMUVqeldm NGNYZDRZMGY4QTY4b3YvUVJXM0hIUUJYYU1LdFZ5YzFhdlcyZ0lPcDVOVTZBQTB3MHBOTlBTZ0Jy VnhmeEZ2OWIwZlM3WFZkSW5Dd1cwd2E2aTI1M3FlbVQvQUhmWDYxMmhxaHJGbW1vYUxmV2NnQldh M2RQL0FCMDRvQWowalZMZlc5SHR0U3R2OVZPZ2JhZjRUM1g4RG11RStOdi9BQ0tObC8xOUNuL0J5 N2VUdzdlMmJuUDJlNURMN2JsL3hGUi9HMy9rVWJIL0FLK2hRQjZzaTV0N2YvcmhILzZDS21TT2x0 MDNXMXQvMXhqL0FQUVJWdU9MaWdDc3liVkpxQTFZdTIyc0VIMU5WcUFBMHcwNDB3MEFOTk1OUE5N SW9BYWE4djhBak4xOE0vOEFYOG44NjlRTmVYL0dYNy9obi9yK1QvMEkwQWV2enIvcERmaFNySFUw aVptUDRWTEhFTVVBVlhUYXRNRlMzSnhJRUhiclVYU2dBTlJtbkdtbWdCamRhWVJUbTZjZmg5YThq ZSsrTEc5dHRtKzNQSDdtTHBRQjZ1UlhtUHhNSC9GZGVEUCt2cFAvQUVJVjMraUcvZlE3SjlWWGJx QmlCbkdBTVAzNmNWd0h4TS81SHp3Wi93QmZhZjhBb1FvQTljblgvU3BQOTZsVk0xTEttYmgrUDRx bVNMaWdDb3lZRktPbE9uSTgzYU8xTit0QUNHbUduR21IRkFGYSt1VXNyRzR1M0JaSUltbElIVWhS bitsWW5oWHhaWitMcktlNnM0SjRVaGtFYkNiR1NTTTlxNUR4dGRlUGwxTFZJdFB0bmJRL0xJM2lL TS91OW56OG5uKzlYRStEWi9Ha09uM0k4S3d0SmJHVWVhVlJHK2ZieDk3Mm9BK2dDSzh4OFgvOGx3 OEhmNzM5SzlIc0RjTnAxc2JzWXVURXZtai9BRzlvM2ZybXZOL0YzL0pjdkIzKzkvU2dEMWwxL2ZQ L0FMMVBWS2VVek0zMXFkSXVLQUtySmlwQU1Da2s1bE9QNGFNNG9BWk5MSEJFOHNyaElrVXM3TndG QTZtdk9JOVk4UytQcmlZNkJjalJ0QWlZcDl1Wk15ejQ2N1IvbjYxcS9GZThsdFBoN2Y4QWtrcVpt amdKSDkxbTUvbCt0YzE0M2FhdzBId3Y0TjBwL3M2WDZva3JweGxmbEg2bGlUUUJjVHduY2tTUzZi OFI3MTdtRVpjeVRxNkwvdkRkd0t2ZUdmRkdvcnJYL0NOK0pWaEdvTW5tV3QzQmp5N3BQYnRuL0Ex eC93QVJ2QjJpZUhkTjBxMTBlS1dPL3VwdklMZWFTWmx3TWxoL3ZGYTZEeHJZeDZicVBnYTF0QUJj d1hhd0p0Nm1NQlEzK2ZlZ0QwSWl2R3ZpUi95VmF5LzY4Vy9tYTluSTVyeG40ay84bFdzdit2RnY1 bWdDR1A4QTFZckU4UWY4ZWNuMHJiVC9BRllyQzhSTnRzWldQcC9Xclc0amtHRlJrVTM3UXRLSlF3 NHJlNU5oaDRxTmpVaEdhYUltYXBBcnR6VVRMbXJ2MlltbW0xSXFYRVpTQ0dyY0l3bFBGdGcwdU52 Rk5Sc0JhUnNLS2NUeFZQemRyZTFMOXBBNjFmTUt4WWFvbUZNKzFEMHB2MmhTYVYwQXJERlJPY1ZL ekJxaVpkeDR6VWpJMjZWQzFXL3N6R20vWkNlYWx4R1VzWnA2TGhoVm43TGpyVDFnQTYxS2lBNkk0 Y1ZhRFpOVXM3UmtkYVZaOGRhMFRzU1cyTlJOMHFFM1FGSjlwQnAzSFlWaHhURHhTaVpUU0huTlN3 c1JNYWpZMU41WlkwRzJidFUyR1ZDS1FDclgyWTB2MmZGTGxDNUZCeHVxN2JuQU5RRkF2U2tMbE1E c2FwYUNMKzdpbzI2VlgrMFVodXNVK1lMRHlLamFrKzBLYUM2c01pcHVNYlVacVQxcG9pWmpnVWdJ VFNWT2JkcVQ3T3dwV0dRMUluM2FjSWNIbWxLN1RnVVdBc1F0aU9wd3dJclBFaFUrMVA4QXRIMXEx S3dpdGpOR0JSUldReFFPYWtBcHFpcEFLcENZNGZTcFZOUTk2ZU90VUluVVpxWlZxR0tyQzFhQWF5 VlVjWVkxb0hwVkNYNzVva2dLYkg1c2RxYlN0OTQwbFkzR1BXcEFPYVlsU3JUUU1jb3gwcVJDUUtZ S2N0VUltVTgxTWd6VmRldFdVeUswUWgrM2lvcEZ4R3h4VmhSVEorSW0rbFU5Z0tIdjdWVlpzbXJa cWkrYzFoSmxJY3A1cVJhaVdwa3hRZ1k4Q3BGR09LUlFNZEtmM3EwSWtVMUtwNXFBZGFsU3FFVHFL Y1Y0cHFkS2xGV2dLMHE0V3FrekVMVitmN2xaMXdCc0ZSTUNBdFNxYzFGVWk4bXNyakpsRlNxS1ln N1ZNb3hWb1E0ZEtsVnFpRk9CNXEwQk92TlBGUm9hbFdyUUNGYVMzQUdvVy84QTEwWCtkUzhZcU9I L0FKQ0VIL1hSZjUwcGJBZTlhRC95RDRmOXdmeXJMOGQvOGVObi93QmRXLzhBUWExZEJIL0V2aC8z Qi9Lc3J4My9BTWVObi8xMWIvMEd1VW92ZkEvL0FKRjd4Qi8yRm0vOUJXdlJycUJMdTBtdHBNK1hO RzBiWTY0WVlQOEFPdk9mZ2gveUwzaUQvc0xOL3dDZ3JYcGY1MGhuaEduZUFkSDFENG4zL2gyR1M2 L3MyeWczU1A1Zzh6ZmhlK1BWdjBvOEsrQWRIOFJlTHRmc0RMZGpTOVBmeTRuUnh2WnQyM2s0L3dC bHE5dmcwK3l0cnFXNmd0SUlyaWIvQUZrcVJoV2YvZVBlaXowNncwL3pXdExPM3R2TU82VXhSaGR4 OVd4MW9BZHA5bEhwdW0yMWpDWE1WdkVzU2x6a2tBWTVxMEt5WlBFdWdRekdHVFd0UFNRZndtNVRq OWEwNHBZcDRsbGdrU1NOdWpvd1lIOFJRQktLaGsrV1ZENi9LYWtGUlhBL2RFanFPYUFHV3MvemxD ZVJ4VUhpTC9rQVh4LzZaR29DL2w2azNvM0lxWFh6bnc1ZWY5Y3FBT0ErQi84QXlKZC8vd0JoT1Qr UXIwcXZOZmdmL3dBaVpxSC9BR0VwUDVDdlNxQVBHZmp0L3dBZnVqZjljSnYvQUVKYTlZOFAvd0RJ dDZWLzE1dy8rZ0NycGhpbDVlSkhJL3ZLR3A0QVhBQUFIVEZBRHFVVUJlT2hwQjZVQU9GUXlERW4r OE50VEZTUFVWRFB3Z2IwT2FBR1dWeGtsQ2VsWjNqVC9rVXRRLzY1R25JL2s2bElnNmJxajhaSFBn Kysvd0N1Wm9BNVQ0Si84a3ZzL3dEcjVtLzlDclUrSS9paVR3dDRYYWEyWUxlM0wrUkF4L2hPTXMz NENzcjRKZjhBSk1MVC9yNW0vd0RRcTcyYTF0N2tBWEZ2Rk1GNUFrUU1CK2RBSHpuNEo4UmFCb09v eTZwcmRsYzZqZjc5MEozS1ZROTJPNDh0WHJ2aGo0bmFYNHIxdE5MdGJPN2htYU5wTjhwWEh5OWVo cnFmN0kwdy93RE1Nc3YvQUFIWC9DcGJmVGJHM2tFdHZZMjhMampmRkNxbjh3S0FMUXBSUUZQb2FD TVVBTFVFb3d6RCs4djZpcHFpbTQyTjZOUUJGWVhPNzVjMWcvRXova1F0Uy82NXQvNkNhdlc3bUcv ZVBPTU1henZpVWMrQWRRLzY1dC82Q2FBS2Z3cC81SmZvbis0Ly9vWnFmeDM0bjFId3JwMXRkMkdt TmVJMHY3OXpuWkdnOWNjZ25zZWxWL2hSL3dBa3YwWC9BSEgvQVBRelhaREhUcUQyTkFIbE9xZkdm U2JuUWJtRzIwMjUrMXp3dEhzbEsrV3U0WUpKenlQd3BmZ25vZC9aUWFocXR6RzhWdGNva1VJY1lM N1NTV3g2VjZPTkQwZ1QrZjhBMlZZK2IxMy9BR2RNL3dBcTB0cDlNZlNnQXBSU2JTTzFGQURxclRn aFpBTzY3dnhGV0tpbCs4aDdad2Z4b0FpMCs1M3J0elhKZkdUL0FKSjVlLzdwcmJzbk1WMHllally QitNTForSGw1L3VHZ0RUOEFmOEFKTy9EL3dEMTVKWERmRkhPbWVQZkRXc3VQM0tsUXg5TmttVCtq VjNIdy84QStTZCtILzhBcnlTbWVQUEMvd0R3bGZobVd6aXdMeUkrYmJNZjc0SDNjLzdRNC9LZ0Rx T0R5cHlwNkgxcGE1bndGY2F0UDRTdFUxcXpsdHJ1RWVUKzkrOUlxOEsyUDAvQ3VuMm4wTkFBS1dr Mm4wTktWSUhRMEFGVkxvWWhsQTdmT0t0Q29abHl5ais4Q3RBRWVuWFc5Y1Z3SHgzT2ZBcC82Nkwv QU9oTFhWYWZLVXVDbnZpdVErT1p6NEZQKyt2L0FLRXRBSGZlRmhud3RvLy9BRjV4ZitnaXVnalhp c0x3bi95S3VrZjllY1gvQUtDSzN5UWtMTjZDZ0RHdXBQTXVuOUFjVkZUYzVKUHJSbWdCVFRUU2tI SFExSG1nQU5VOVZ1MHNOSXZidVJzTERBN244RnE1dE9PaHJpL2lQRHJPb2FQYmFUcEZvOGkza3dT NGxVOElvNUFQc2ZYMm9BeVBnNWF2SG9GL2R1TUxQY2hWOTlxOC93RG9WTitOdi9JcFdYL1gwUDZW M09oNlJEb09pV3Vtd2NyQW1DMzk1dXJOK0pyaHZqYi9BTWlsWmY4QVgwS0FQWTdSYzJ0c2YrbUtm K2dpcnlMaGFxV0kvd0JEdHY4QXJpbi9BS0NLdFRONWNEdDZLYUFNZVovTW5kdmVtMHdHbEpvQU0x eTNqaWZ4TkJZV3A4THhHUzRNcEV3Q0syRTIvd0MxNzExQkhmbW1aeFFCNUo5ditMUi81YzIvNzhS VlBwMTE4VUgxUzBGNWJzdHFaVkV4OHFJZkp1RzdwN1Y2b2VuU21INlVBSTNYaXZNUGpML3JQRFAv QUYvSi93Q2hHdlRqWG1IeGsvMW5obi9yK1QvMEkwQWUyN2N5ZmxVNnJoYzB4UjgvNVV0eTNsMnNq RCs3UUJsTTIrUm45VFFUVEY0RkthQUEwdzBwcEdCSFkwQU5OTlAwRkxUVFFBMDE1ajhUUCtSOThH ZjlmU2YraEN2VGpYbUh4TC81SDN3Wi93QmZTZjhBb1FvQTlyS1ptYjYxT0J0UW4wcGdIN3h2clNY amJMUno2OFVBWm9iY1MzcWMwdWFhdkFvSm9BQ2FhYVhyVE1nNUNuSjlqUUJYdjdZWHVuWE5tWDJD ZUpvdDJNNDNLUm45YXdQQm5oRlBCMWhjMnNkNDkxNThvazN0R0V4aGNZNjEwcHBwb0FTdk1QRjMv SmN2QitUL0FCZjByMDQxNWg0dC93Q1M1K0QvQVBlL3BRQjdNcVprYjYxWWJDUkZ2UVpwcUw4NSt0 SmZOdHRTUDczRkFGQk9lVDM1cHhOTkZGQUdGNHowTnZFZmhPLzB5TC9YU0p1aXovZlU1SDU5UHhy enBVSGovUmRMaGh2azA3eFhvcDhzeFRuYVcyNDVIL2ZJUDF6WHNSVStocm12RVBnYlFmRWN3dWIy MGFPNy93Q2ZtM2Z5NUQ5VDMvR2dEajlUK0gvaXZVdnMrczMrdVFUNjNheXE4TWJKdGdSVjU5T3Vj SHBXejRkOFAzdDlydjhBd2tYaURWTFRVTDYzRFF3UTJmTU51ZjR2K0JjL3JURitGZWprZ1hHcGF4 Y1Ivd0RQT1M3NFA2VjFHazZMcHVnV1gyTFRMVkxlRE80cXVTV2IxSlBVMEFYdWxlTS9Fbi9rcTFu L0FOZUxmek5lelY0ejhTZitTcldmL1hpMzh6UUJDbjNCWFA4QWlmOEE1QmsvKzcvV3VnVC9BRlly bnZFLy9JTG4vd0IzK3RVSTgvM0duby96QTFDMUxIa3RWWEEwRkdXRldnbUtyeEQ1bHEyQm10NDdF alNPS2piaXBUMHFGcUdBeGp4VVI5YWV4cGxRMkJFNHFKaGlyRENvWHhVc1pBVGltN2ptbGZyVVdl YXp1TXR3TmxzVmNnWE9UVkMyQjMxcFc1NHJTQW1TQmNDbXNLbUlxSjYxRVFzY1ZHeDRwem5tb2lh ellEVFVUVk4ycU1pcFl5QnVsTUpxUnhVSjYxRFkwT0RZcTFIeW9xbGpOWEllRVdtZ1pkVlBsR0tk dHdLZkg5MENocTNTMEp1UU1NVkV4cVdTb0dxR01ZeHBqWXpUalNIcFdZSWhJcU05YWxhb21ITlN5 aEtlaCtjVXluUi9mRkNCay84QUZWeFk2cUQ3d3JRVDd0YXdKSXlvQXFKcXNOVlp6UXdJeWNWRzNQ V25OVE8xUXhqR0ZNeFVocGxJQnRKM3BhS2tZOWFrSFdvbHFRR3FRaDFQV21WSW9xaEUwVldWcXRI eFZoVFdpRU9iN3RVWmZ2R3JwYkZVWmptUnFVeG9wdDk0MGxLMzNqU2Q2d2U0eDZWTW9xRktsVTFT QWs2VTRVMGMwNWFwQ0pGNjFZanFCYW5UanRXaUVUTDBway8rcmY2VTRjVXlaLzNiQ3E2QVV1b3Fr M1UxZDY1cW15ODFqTXBDS0tuU29WNjFLdldwUU1uV245NmpXcEI2MWFFS001cVZPS2pVVktnNzFZ aWRPbFNDbzFOU1p4Vm9DT2Y3bFoxeDl3Vm9USEtWbjNDN2tGUk1Gc1UrOVNvT2FidHhUMXhtc1Vp aXduclVvcUZEVXExb2hEKzlPSFdtMDlSVmlKVXFWYWpVVklLdEF4L2FvNGYrUCtEL0FLNkwvT25F NHBzSnpmMi8vWFJmNTBwYkFlOWFEL3lENGY4QWNIOHF5L0hmL0hqWi93RFhWdjVWcWFEL0FNZytI L2NGWmZqdi9qeHMvd0RycTMvb05jcFJlK0NIL0l2ZUlQOEFzTE4vNkN0ZWxWNXI4RWYrUmU4UWY5 aFp2L1FWcjBta01jT1RYaEhqdnhacW5pL3hNZkR1aVBKOWpFMzJkSTQyMi9hSHpnc3gvdTllUGJO ZTMzanRIWVhMcDk5WVhaY2V1MDE0UDhHbzQ1ZkhZa2w1ZExXVjB6L2U0Qi9RbWdEb3JYNEdSR3pY N1pyYnJka2NpR0FGRlA0bkpybHQvaUw0UytKMWg4N3piWi9uOHNIOXpjeDU1NDdOL0kxOUQxNWQ4 Y1lZbThQNlhPY2VhbDB5S2Y4QVpLblA4aFFCNlhwMm9XK3E2WmJYOXErNjN1STFrUW4wTlR5Y29S bXVKK0VrcnlmRHl5RDVJamxsUmMvM2Q1cnRqMG9BeHJySzNNRCtxZ2ZseFUrdG5QaHE3LzY1R29i NGNRTjZPeTFOckkvNHBtNy9BT3VSb0E0UDRILzhpWnFIL1lTay9rSzlMRmVhZkEvL0FKRXpVUDhB c0pTZnlGZWxVQWVhZkdtRzRYUTlPdjdhYVdJdzNCaWN4dVY0WWNkUGRhNkw0WjZrZFQ4QjZkTExJ enlRN29KR1pzbjVXUFg4TVUvNGlhZi9BR2w0QzFXSUxsNDR2UFg2b2QzOHMxNTM4T05mL3MzNGZl S0VMNGUxVXp4L1YxMi8raEFVQWNkcXZpaS9sOFhYV3FSWDF5SS90aGxTTVN0dDJoK0JqUG9LK2cv RStzTFplQ3RSMVdGOFpzekpFUjZzdUYvOUNGZUUyZmg3enZoVHFHczdNeVIzOFlVLzdBWGEzNnYr bGRQNGgxLzdUOER0SGkzNWxua1cxZm5raUxPZjVMVEF2ZkJJWDEzUHF0OWQzbHpQSEdrY0NDV1Zu RzQ4bnI5QlhyY296RTMwcmhmaEJZZll2QWNVN0REM2M3emZobmFQL1FhN3B2dW1rQmpYUjI2aEcv OEFlUUdtK0xqbndkZW4vcG1hZGVqOTdiTjlWL1dtK0xCL3hSdDcvd0JjelFCeTN3Uy81SmphL3dE WHpOLzZGWG9RcnozNEpmOEFKTUxYL3I1bS93RFFxOUNGQUMxNFY4WXJ5NnQvR3FKQmQzRVNmWTR6 dGpsWlIxYnNLOTFyd1Q0ejgrTjQvd0RyemovOUNhZ0RTaStGUGkyU0pKRjhSeGdNb1lmdjV1NHJz dkFIZy9XL0M5N2V6YXRxaTNzYzBTcEdxeXUyMGhzNSthdU5pK01tdXhRcEgvd2o5dVFpaGMvdk93 cnZQQVBqQzg4WDJkN05lV0VkbTF2SXFLcUZ2bXlNNSthZ0RzTTFIT013dFR4VFg1UnZwUUJpM0Iy NnJuKzhBMzZWUStJM1BnQy8vd0N1VGY4QW9KcS9lREY1YnQ2cGo5YW9mRVVIL2hYMS93RDljbS85 Qk5BRlg0VC9BUEpNTkYvM0gvOEFRelhaQ3VOK0UvOEF5Uy9SZjl4Ly9RelhaQ2dCeS9lSDFyNXAw KzAxYnhGNHlsMGkxMVdlQ1NXNG0ydTh6N1YybGoyK2xmU3EvZUgxcjVzOE82emErSHZpSTJxWG9r TnZEY1Q3aEV1NXVkd0dCK05BRzlyWGdyeHA0VDA5OVhnMXlXZUtENXBEQmNTQmtIcmh1dGQ3OE1m R2R4NHEwcTRnMUFocit6Szc1RkdQTlEvZGJIcndRYTVyeFo4VzlMMUh3OWQ2ZnBWdGN0TmRSR0pw SjFDcWlucWVweWNWZitEWGh5ODB2VDczVmIySjRmdG0xSVkzR0NVWG5jUjdrL3BRQjZqVVUvOEFx aWZUbW41cGt2TWJVQVlzdjd2VjVQZHQzNTFoZkZ6bjRkWG4rNGEzYnRmK0puRTM5NUZyQytMZ3g4 T2J6L2NOQUdyOFAvOEFrbmZoL3dENjhrcm9oWE8vRC84QTVKM29IL1hrbGRHS0FCdVZJSEdSWGpV bndvOFY3bmRmRWNZWGx2OEFYeTE3TFNTSDkwLys0ZjVVQWZOSGhpdzF2eFJyUDltV2VzVHd5K1cw bStXZVRiaGZwWHEzZ2Z3UDRnOE8rSURmYXByQ1hkdDVMUitXSnBHK1k0d2NOeFhDZkI3L0FKSDgv d0RYck4vU3ZmcUFIVkZPY0lHOURtbjB5Ym1KdnBRQmdrZVZxMHE5UG5ya3ZqY2YrS0UvNEd2L0FL RXRkZmRER3NaL3ZCVCtsY2g4Ymhqd0gvd05mL1Fsb0E5RjhKZjhpcnBIL1huRi93Q2dpdGk5YlpZ eWZURlkvaEwvQUpGWFNQOEFyemkvOUJGYWVwdHRzc2VyQ2dESEI1cGMwd0dqTkFIaVBpdGRWOERl TjRieTN1cnFTeWVUN1JBanlzeWxjL05HY250eitZcjJDTFdMS1hSVjFnVEFXSmc4L2Y2TGpQNTFt ZU5mRHFlSi9Ec3Rtb0gycVA4QWUyekhzNDdmUTlQeHJ4RmZFZXBRK0ZKZkMrMXdqWEc0L3dCNVIz angvdmMwQWIrZ0RVZkgzanVhNW11TGlPeFYvUG1SSldWVmpIM1U0OWVQMXIyM3B3QmdlbGMzNEg4 T0R3ejRkaWdrVUM4bS9lM0ovd0Jyc3Y4QXdFVjBWQUMxNXQ4YlArUlNzdjhBcjZGZWtWNXg4YlAr UlNzdit2b1VBZTBXUC9IbmIvOEFYSlAvQUVFVTdVRzIyVCsrQlRiSC9qenQvd0Rya24vb05NMVZz VzZEMWFnRExCcFI5NFV3R2xVL01QclFCNFo0THZidVg0cFJ4U1hkdzhYbjNIeU5LeEhSdTFlNDU1 cndid1IveVZXUC9yNHVQNU5YdkhlZ0R3elRycTVQeGdXSTNNNWkvdFNRYkRJMjNHVzR4WHVSTmVE NmIveVdSZjhBc0tTZnphdmRqUUFHdk1makgvclBEUDhBMS9wLzZFYTlOcnpMNHgvZjhNLzlmNmYr aEdnRDNKUHZWRHFUWXRjZjNtQXFaZnZWVTFWdmtqWDN6UUJRQm9KcG9OSm1nQmE4TCtITjdkemZF YU9PYTd1Skk4VC9BQ1BLekRvZTJhOXlKcndYNGEvOGxKaitseC9JMEFlOGswM05CTkptZ0Fyekg0 bGY4ajc0TS82K2svOEFRaFhwcE5lWmZFci9BSkgzd1ovMTlKLzZFS0FQY1FQblAxcXZxYllnUmZW cXNML3JEOWFwYW8zenhENm1nQ29LcTZscU50cE9tM0dvWGo3TGUzUXU1OXZRZTU2Vk9EWEFmR0s1 ZUx3V2tLRWhaN3BGZkhvQVcvbUJRQndzK3QrTFBpVnJUMlduUEpCYWo1dklqazJSeEo2dXc2bi9B RGlyVjE4TFBGT2wyNXZMSFVZN2llTWJqSGJ5dWpuL0FIZld1dCtEdG5GQjRRbHVsVWViY1hUYjI5 bHdGSDg2OUF6anJRQjVaOE9maUJlWDErdWc2NUlaSm4rVzN1SDRjc1A0RzkvUTE2aVRYZ0hqV05k SitLRTB0cjhoRnhGY0RiMlk3V1A2NXIzMG5KejYwQUJyekh4Yi93QWx6OEhmNzM5SzlOTmVaZUxQ K1M1ZUR2OEFlL3BRQjdjbjNqVmZVbStXTmZmTldJL3ZHcVdwSE02RDBXZ0NBZEtSemhHLzNUU1pw cm45Mi84QXVtZ0Q1dDhPMmV0ZUtkZU9tVzJzWEVNakIzM3l6dmpDL1ExdWEzNGU4WitCWVUxUk5a bGxnREJYa2huZGdwUFRjcmRqV2I4T3RYc05EOGFmYmRTdUJiMjRpbFh6R0JQSjZEaXV2K0lueEIw VFUvRFUyazZWT2J1VzRaZDdoQ3FJb1lOMzZuaW1CMkhnUHhTL2l2dzk5cHVGVmJ5Qi9LbjJkR09N aGdPMlJYVEUxNTU4SHRObnN2Qzl4ZHpvVVc4bjh5SUhqS3F1TjM0bk5lZzBnRnpYalh4Si93Q1Ny V1gvQUY0dC9NMTdIWGpueEkvNUt0WmY5ZUxmek5BRUVmM0JYUDhBaWova0dULzd2OWE2QlA4QVZp dWY4VDg2WlA4QTd2OEFXcUVlZHRUb3Z2Q2c4MHFKeUJWV0EwSS92TFZ4ZWxVNHpobHEyR3JkYkVn MVFQM3FacWpZVUFRR20xSTFSMURBYTJhaGNjVkt4cUZ6VXNaQTlSR3BXRlI0ck1hTEZ0OTZ0QzNI SjRyUHR4aDYwSUc3VnBBVExKNlZDOVNaeUtqYXRYc0lnZnJVUnFaaFVaRlpzQ1B0VFdweEhGUnRV TWFJbnFGdXRUT2FoYmsxREdJS3VSZmRGVXdLdVJjSXRWRVpveC9kRksxTlJ2bEZLeDRyWkVFTG1x N1ZZZm1vR0ZTd0k4VWg2Y1U0OFV3bW9ZMFJ0VVRZcVZxaGJtb1l3cDBmM3hUUlRrNGNVRExIOFFy UWorN1dlRDh3cThHNEZheEpCdTlWM3F3eHFCNmJBcnRUZTFTTlVack1ZaDZWSFR5YVpTWUFVYjBv Mk42VmJHRFQxVVUrVUxsRUt3N1U3QkI1cS81UXgwcU40aGlueWl1UUNwUVZYaklxRW5DazFFV1kw cmpMd2xVZDZlSjFIZXN6SnB5MEtZV0w3VGoxcUV0dU9haEE2MUl1TVUyN2dOYUlnWkZSK1VjOUt1 S1JpcEZBejBvNWJpS0lqWUg3cHAyMWdlbGFBVE5LWXdCMHBxQU1vcHlhbGo2R2xrakNkS2hrY3FC aWpZTEZvTW83MDhTcUI5NnN3dWFBeHpTNWdzYW5uTGpyVWJ6QS9MMXFtTTA5Ujh3cXVZQ1RQSGVv bmhJNXhVdzYxTXB6U3RjQ2lJV0g4TlBFVGVocThvQnA0VDJwcUFHZnRZZGpVaUhpcmhqRlFTTHNi RlBsc0FxWTI4MDhNb1BXcWNybFd4MjYxRnZPYVhOWURURXFqdlMrY3BIV3N3RTVxUVpwOHdGdHBj amJVYkp2R0tZb09hbVRpamNSV2FBNTZVZ2hZZncxZkZQQ2lueURLQ28vcFQrVnhWL1lQU21OR0RU NUJYSUY3VktDQlVST0FUNlZXZVVrMHIyR1h4SXVldFA4MVIzckxFbWFlckdsekJZMEdtSFkwdHFk OTlCLzEwWCtkVWxxNXA0LzA2My9BT3VxL3dBNnErZ3JIdjJnL3dESVBoLzNCV1g0Ny80OGJQOEE2 NnQvS3RYUXYrUENIL2NIOHF5dkhmOEF4NDJmL1hWdjVWemxGMzRJL3dESXZlSVArd3MzL29LMTZU WG12d1IvNUY3eEIvMkZtLzhBUVJYcFhha01YQUl3d3lEd1JYenRkUlh2d3orSW91QkNXZ2prWjR1 d21nYnNEOUQrWXI2SXJPMW5RdE04UTJYMlRWTFNPNGl6bFNlR1ErcXQxRkFHVGFmRWJ3bGQyWXVQ N1loZzR5WXBzcTYrMk1meXJ5YjRoK0xQK0UzMXV6MC9Sb1pKYldGaWtBMi9OTkkzOFdQeUFyc3Iv d0NDdWp0Rk85aGYzcVM3R01VY2pLeTdzZktDY1p4WEtmQ2k0bTBqeHJOWVhHa1NUM0RxWW5rRVda TFZoMUo5RjdIOEtBUFkvQ21pL3dEQ08rRjdEU3lRWklZLzNwSFF1Zm1iOVRXelRhS0FNMjhYTVEv MlpmNlZMclF4NFp1eC93Qk1qUk91NUpCNk9wcGRjR1BEbDJQK21Kb0E0RDRIL3dESW1haC8yRXBQ NUN2U2E4MitCLzhBeUplb2Y5aE9ULzBFVjZUUUEyZUZMbTNsdDNHVWxSa1lIMEl4WHlzMDF6by85 cWFYbmFzcDhpWWY5YzN6L05hK3JLOHkxNzRRUjYxcjE1cVNhdjhBWjB1cFRJWWZzKzdibnJ6dTlh QU5YUWZEKy80T3JwUlQ5NWRXTWtwSCsyMldIL3N0ZUN5YWhjUzZUYjZhMytxZ2xrbFFmN1RoUWY4 QTBHdnErQ0pMZUNLRkJoSTFWRkhzQml2THg4R1locll2djdYL0FOSEZ6NTNrZlovNGQyN2J1M2Zo UUI2SjRmc0JwZmgzVGJBREhrVzBhRWUrMFovWE5hQm9KeWMwVUFaZDR1VmhQcEt3cVB4Y01lRGI3 L3JsVm1kZHlmU1VmeXFEeGdNZUQ3OGY5TXFBT1MrQ2YvSkw3VC9yNW0vOUNyMEd2UDhBNEovOGt2 dEQvd0JQTTMvb1ZlZ1VBTFhndnhuSC9GYlIvd0RYbEgvTnE5NXJndkdmdzEvNFM3VzAxTCsxUHN1 MkZZdkw4amYwSk9jN2g2MEFkaGFhanAvMkszLzB5MXo1U2NlY3Y5MGU5V283cTJuSldDZUdRamtp T1JXUDZWNUgvd0FLTS82ajMva3Ivd0RaVjB2Z2Y0Yy84SWJxMDk5L2FmMnJ6WWZLMmVUc3g4d09j NVBwUUIzbEIrN1NVVUFaVjJ1WHRUNkZoK3RaM3hIR1BoOWYvd0RYSS84QW9KclhuVEloUDkyVTFs ZkVrZjhBRkFhai93QmNqL0kwQVVmaFIveVMvUmY5eC84QTBNMTJOY2Y4S1IveGEvUlA5eC8vQUVN MTJGQUNyOTRmV3ZuYndmWTJ1by9GRmJXOXQ0N2kzZTR1TjhjaTVVNDNkcStpUndjMTU5b1B3eC9z UHhhbXUvMnI1MjJTU1R5ZkkyNTNaNHp1N1pvQTRyNG1lRmYrRVUxdTExdlI0aEJaeXVwVlVIeXd6 TDdlaDYvblhyZmhMeEpENHI4UFFhbEhoWnZ1WEVZL2drSFVmVHVQclZyWE5IdHRmMFc1MHU2SDdx WmNCdTZOL0N3OXdhNWJ3VDRBdS9CdW95ekpyUXViYWROc3R1WUNvWWo3ckE3dUNLQU83cHJmZE5G QjZVQVpOMHVicTFQK3pqOWF3ZmkrdVBoemVmN3BycEprekpiSDBaaFhPL0dIajRkWHYrN1FCb2VB UCtTZCtILyt2Sks2S3VkOEFEL2kzbmgvL3J5U3Vpb0FLYkovcW4vM1QvS25VakRjckw2Z2lnRHdU NFAvQVBJLy93RGJyTi9TdmZhNER3ZjhORDRVOFFmMnAvYXYybjkwOGZsK1J0Kzlqbk80MTMxQUMw MlQ3amZTbHBHKzZhQU1pNlhPcFc3ZXNZcmp2amtNZUEvK0JyLzZFdGR4S21icTFiL1pJL1d1SytP b3g0RS80R3YvQUtFdEFIZmVFLzhBa1ZkSS93Q3ZPTC8wRVZvYXVjUVJqL2FyUDhLZjhpdm8vd0Qx NXhmK2dpcm1zSDVZeDlhQU1zSGlnbW1nMFVBTG12Q3J0Vi80WEtSdFhIOXFyeGpqcUs5enpYQ3pm RHN5ZU16NGgvdFBIK2xDNDhqeWZUSEc3UDhBU2dEdWpTVVVZb0FLODQrTm4vSW8yWC9YMEs5R3J6 bjQxLzhBSW8yWC9YMFA2VUFlMFdQL0FCNlczL1hKUC9RUlVHcm5pSWZVMUxZbi9SYmIvcmluL29J cXRxNS9lUmovQUdhQUtGQU9DS2Jta3pRQjRIcGQxSDRYK0tMVGFobU9LRzhsV1JzZmRWczRiNmZN RFh0ayt2NlBiV1p2SmRUdEJiZ2J0NG1VNUh0anJXSDRzOEJhZDRwa0YwWkh0TDVSdDgrTlFRNDdi aDMrdGNjdndZdVJKODJ0UWhNOVJiblA4NkFNVHdtVzF2NHFSWGtDTUkydXBMbzVIUk9UL1Vmblh1 MWM5NFc4SDZiNFV0M0Zwdmx1WlFCTGNTZmViMkhvSzZDZ0FyelA0eGZmOE1mOWY2ZitoVjZaWG1m eGorLzRaLzYvay84QVFxQVBjaysvVkhWbS9lUmoyTlhFUDcwL2hXZnFoLzBsZjkyZ0NwbWtKcHVh TTBBQnJ3ajRhLzhBSlNFK2svOEFJMTd0bXVEOE5mRG4vaEhmRWk2di9hbm40RWc4dnlOdjN2ZlB2 UUIzZWFRMG1hS0FDdk5QaVYveVBuZ3ovcjZUL3dCQ0ZlbFY1cDhTY2Y4QUNlZURQK3ZwUC9RaFFn UGNWLzFyZldzL1V6bTRVZWkxZFQvWHYvdlZuYWlmOUxQc29vQXI1cmsvaVJvMDJ0K0RMbUszVGZQ YnN0d2lqcTIzcUIrQk5kWG1tNXhRQjQvOEovRjFscHNNMmlhbE9zQ3lTZWJieXlIQzdpTU1wUGJv TVY2ZnFPdjZUcFZrMTNlWDl2SEVvenhJQ1c5Z0Ixcmt2RW53czByV3JxUzhzcG0wKzRrTzUxUmQw YkgxMjl2d3JBdC9ndEw1dyswYTNHSTgvd0RMSzNPNzlUUUJ6bW5KUDQ4K0pQMmtSTUlwTGdUeVov NVp3cVJqUDRBRDZtdmZpY21zYnc5NGEwend4WkcyMDZJaG13WlpYT1hrUHVmNlZyMEFIMHJ6VHha L3lYTHdkL3ZmMHIwcXZOUEZuL0pjZkIvKzkvU2dEMjJQN3grdFVMODV1ejdLS3V3bjV6OWF6cnc1 dkgvQ2dCbWFaSWYzYi83cG96VFhHNUdYT01qRkFIenY0QjBPdzhSZUxUWWFpanZibUtSOEkrMDVI VG12WGJMNGJlRk5QbUVxYWI1ektjajdSS3pqOGp4V2I0UytIQjhMNjkvYWgxVDdUKzdaUExFTzM3 M2ZPVFhkazBBS0FGVUtvQ3FCZ0FjQVVoTkpuMHBLQUY3MTQ3OFNmK1NyV1gvWGkzOWE5Z3pYajN4 Si93Q1NxMlgvQUY0bit0QUVTZmNGWUhpVVowMllBZHY2MXZKOXdWaTY5L3g1eWZTclc0anovd0Fr NSs3VWlRZXVSaXJoVUNtc2VLMTViRWtRNE9SVXF5cjNOUW5wVUpHS0wyQXVtVWV0SVpGeDFxZ3hx TXVSUzV3TkhLbW8yNjlhcUxLUjA2MVlSdHdvVHVNWStjOFV3bzU3VmRqajR6am1wTmdwOHR4R1dZ V1A4Sm9FQi91MXBrQVZHUlM1QmxSSTluYXBsY0lhVnpVTFViQ1phRXkrdElaVi92VlJPUUtqWnFY TVZZMERJdnJUVGdqam1zL2VjMUlrbUc0NzB1YTRXSm02VkVRVDBGVHFNc0JWaFl3RDBxdVc0ak9N Ym50VGZKUHBXb1VGTUlIcFM1QXVaNlFNVDBxWUx0WEZUTnhVVGQ2VnJCY2ZITm5nbnBVdm5ML2Vx aXdwaEpGSE1CZk1pLzNxWVdVOTZvRnNVQno2MHVZZGkzSU9haWZnaWlObWZyVTBVWWJPUjBvV29p dHRZOXFhWTJQWTFwQ01lbElWQXB1bU5HYjVURHRUMWp4emlyYllxTnZ1MHVXd0VlT2FtV2JuQnFI dFVSR09sSzRpNzV3ejFwcGtYMXFpYU0rOVBtSFl0bGxOUnQxcURQTlNLMlJTVHVBMXMwbTAxYVNN RVpxVVJpbnlqSUZOV0krYXJwVmlLbWlTZFJUWkY0L0NuclRaZUZxM3NJelgvd0JYVU5UUDl5b2F3 ZTVhRTcxSXRSOTZrV2dHU0FVOENrRk9xaENxYW1RMUNPdFRKVklSWVFaRlNoY2lvNHh4VW9yVkNL bHlPRnFoUDJxL2NuZ1ZRbjdWbE1hSWFlbldtVTlLeUtKMXFRQ28wcVVWb1N3NzA5VFRPOVBYbW1J bVNyQ2pOVjQrS3NKMEZhSUJ4RlZKL3dEV2ZoVnc5S3B6L3dDcy9DbkxZQ2pjWkVoK2xRZzgxTmNm NncvU29SMXJuZTR5VmFuVVZBZ3F3b3FrQThVOGRhYUtjSzBFU0xVeWRLZ1hyVTZkS3BBU2dVTU9L QlN0MHF4RkNYbzFVQ2VhMEpQdXRXYytOMWM4eWtPWG1wMEJxQktzSlNReVpSVnF4NHY3Zi9ycXY4 NnJMVm15L3dDUCszLzY2ci9NVm9TZSs2QzZHd2krWVoyRHZXVDQ3a2oreDJhN3huelNjRSsxYXZo dlNMUFV0TkJ1VmtPTUFiSkNuWWVsV05WOElhYmJSeFRMUGVLck50SytadjhBNTFnV2N0OEhQRTJs NmFQRU9sWDkzSGJYRWw2TGlKWkcyK1l2M1RqUDBINTE2a05lMG9qSXZvZisreFhuVjc0RjhOWDhw bW0rME5NMzNuYU5HSnF0L3dBSzY4TWVzLzhBMzRqcEFlbi9BTnU2WC96K3cvOEFmWW8vdDNTLytm MkgvdnNWNWgvd3Jud3ovZXVQKy9FZEwvd3JydzEyZTRIL0FHd1NnRDA3KzNkTEgvTDdELzMyS2F1 cjZNa3NrcVQyeXlTWTN1dTBGc2RNbnZYbWYvQ3V2RFg5KzQvNzhSMGY4SzY4TS84QVBTNC83OFIw QWVualhOTTZmYkl2Kyt4VHY3YjAzL244aS83N0ZlWGY4SzY4TmY4QVBXNC83OFIwZjhLNjhOLzg5 cmovQU1CMC93QWFBUFNtMWpUZDBoYThpQ25HTXNPZWF6L0ZuaXZSTEx3emVPK3BXK1RFVlVCeGxq WEMvd0RDdXZEZmVhNC84QjAveHBSOE9mQ3hQek5jSC90aEhRQlgrQ1hpclNiWFFOUjA2OHZJb0xr M3BtUkhjRGNyS09tZmNWNm1OZjBvOUw2SC92c1Y1dko4T3ZDTGdiVXVWLzdaUm1tLzhLNThLLzNy a2Y4QWJDT2dEMHYrM3RLLzUvWWYrK3hSL2IybC93RFA3RC8zMks4MC93Q0ZjK0ZmNzF6L0FOK0k2 WC9oWFBoWCsvZGY5K0k2QVBTLzdkMHYvbjloL3dDK3hTLzI3cG4vQUQrdy93RGZZcnpQL2hYWGhZ Zjh0THYvQUw4UjBmOEFDdWZDM2FTNi93Qy9FZEFIcG45dWFaL3orUmY5OWlsL3R2VFQvd0F2a1gv ZllyekgvaFhQaGY4QTU2M2YvZ1BIUy84QUN1ZkRIL1BhNy84QUFlUC9BQm9BOUdiVjlOdzVhOGhB M0E4dUt4ZmlCNHIwUzA4SDNvL3RDQnBKSTlxSXJnc3hya2g4T2ZER2VacnMvd0RidkgvalQxK0hI aExjQzdYWngvMHdqb0FUNExlS3RJdC9BNDB1NnZZb2J1QzZrYnk1R0NrcTJDQ0s5Si90L1N2K2Y2 SC9BTDdGZWNQOE9mQnpINVV1MS83WXhtbS84SzQ4SmYzcnYvdnhIUUI2VC9iMmxmOEFQN0QvQU45 aWorM3RMLzUvWXY4QXZzVjV0L3dyandsL2V2UCsvRWRIL0N1ZkNlUDlaZWY5K0k2QVBTdjdlMHYv QUovb2YrK3hSL2J1bUgvbDhoLzc3RmViZjhLNThKLzg5THovQUw4UjBuL0N1ZkNuL1BTOC93Qy9F ZEFIcGY4QWJtbWRyeUwvQUw3RkwvYldtbi9sOGkvNzdGZVovd0RDdWZDdi9QVzgvd0RBZU9qL0FJ Vng0Vy81N1huL0FJRHgvd0NOQUhvaDFmVGNmTmVSRDk1bmx4NlZ6SHhVOFZhUEY0SXZMZU8vZ2t1 SjEyUnhvNEpKd2UzNDFoRDRjZUZ1ODE0Ui93QmU4ZjhBalRsK0hIZzhNQzV1MkhwNU1Zb0F0L0NU eFpvMy9DdnJEVDU3K0dLN3RXa1I0bmNCc2JpUWYxcnZCcjJsSHBldy93RGZZcnptVDRjZURHYktM ZG9QVHlvelNmOEFDdVBDSDk2OC93Qy9NZEFIby84QWJ1bC84L3NQL2ZZby90M1Mvd0RuOWgvNzdG ZWNmOEs0OEkvMzd6L3Z4SFIvd3Jud2wvejB2ZjhBdnpIUUI2Ui9idWwvOC9zUC9mWW8vdHpUUCtm MkwvdnNWNXYvQU1LNDhKZjg5YjMvQUw4eDBuL0N1UENYL1BXOS93Qy9FZEFIcFA4QWJlbWY4L2tY L2ZZcDM5dGFiai9qOGkvNzdGZVovd0RDdVBDZi9QYTgvd0MvRWRKL3dyandyL3oydlA4QXdIai9B TWFBUFF6cTJtZ3hGN3lFWWtKNWNWeGZ4bThVYVFmQmNsakJmUXpYTTUyckhHNEordFVCOE9QQ3Y4 VTE2ZjhBdDNqcDZmRGp3YXJaZjdhL3Q1VVlvQTJ2aHQ0dTBTYndEcEZzMS9DbHpiUWVUTEd6Z01w QjlLNjMrM3RLL3dDZjJIL3ZzVjV3L3dBTi9Cak5sQmVyN2VUR2FUL2hXL2c4ZngzMy9mbU9nRDBq KzNkTDdYc1AvZllvL3QzUy93RG45aC83N0ZlYmY4SzM4SC8zNzcvdnpIUi93cmp3aC96MHYvOEF2 ekhRQjZUL0FHN3BmL1A5RC8zMktYKzNOTHp4ZXcvOTlpdk5EOE9QQ1A4QXoxdi9BUHZ4SFNmOEsz OEpEcE5mZjkrSTZBUFRQN2Iwei9uOGkvNzdGS2RaMDBqL0FJL0l2Kyt4WG1QL0FBcmp3bWYrVzkv L0FOK0k2YWZoeDRWN1hGOS8zNGovQU1hQVBSanErbUNTQXZlUXJ0TGRYRmVkL0hQeExwTng0Wmgw NjB2WVpyaVNRTnNqWU1RTWc1UDVVZytISGhUK0s0dno5SUk2Zkg4T1BCaXRsL3Q3L3dEYktNVUFk cDRGOFg2SmVlRWRKSzM4UWtpdFk0NVVMaktNb3dRUld6cWV0YWRPeWVYZVJFQmY3NHJ5OS9oeDRO M0VvOSttZittVVZNUHc0OEs5cnEvSC9iQ1AvR2dEMFA4QXRTdy81KzRmKyt4U2YycllmOC9jUC9m WXJ6My9BSVZ2NFUvNSt0US83OFIvNDBmOEs0OEpZLzQrZFIvNzh4MEFlZy8ycllmOC9jUC9BSDJL VCsxYkQvbjdoLzc3RmVmZjhLMzhJLzhBUGZVZisvTVZIL0N0L0NIL0FEMzFIL3Z6RlFCNkQvYXRo L3o5dy84QWZZcFA3VXNQK2Z1SC92c1Y1OS93cmZ3aC93QTk5Uy83OVJVZjhLMzhILzhBUGZVdisv VVZBSG9QOXI2ZXE4M2tJLzdhQ3ZMZmpSNGkwMjYwYXcwK3p1NHA1eE41anJHNE8wZStLMFQ4Ti9C MmY5ZHFmL2ZxS2xqK0hIZ2xDZDUxSi84QWdFYTBBZW1lSHZHT2hhbHBGbGN3YWhDUTF2R0dHOFpW dHZJTldOUjFuVHBwZ1V2SWlBdlhlSzhvYjRiK0R0eEtUNmt2MGlqcU0vRGZ3ci96KzZsai9yaEgv alFCNmIvYWxoL3o5dy85OWlrT3E2Zi9BTS9rUC9mWXJ6TWZEZndvUCtYelUvOEF2ekgvQUkwdi9D dC9DZmU4MU0vOXNZNkFQU3Y3VjAvL0FKKzRmKyt4Ui9hMWgveitRLzhBZllyelQvaFczaEgvQUor dFQvNzlSVXYvQUFyYndoL3o4NnAvMzZpb0E5Si90V3cvNSs0disreFNmMnRZZjgvY1AvZndWNXQv d3Jmd2gvejg2cC8zNmlvLzRWdDRQLzUrTlUvNzlSVUFla0hWOU9YNzE1Q1ArMmdyeVg0eGVKdE51 YnpSSUxPNmp1SHRaZk9sOHB0MjNCclMvd0NGYmVEajF1TlVQL2JPS254L0Rqd1NvSVp0VWNuL0FH WWhpZ0QxblR2RjJoYWhCSGRXK293UEhJaXNDSEhwVEwvV05PbXVDeVhrUkdBTTd4WGtyZkRYd2Y4 QXdYT3FMLzJ5aXBuL0FBcmJ3djhBOC8ycWY5K1kvd0RHZ0QxVCsxZFAvd0NmeUgvdnNVMDZ0cCtQ K1B5SC92c1Y1ZC93clh3cjN2TlVQL2JHUC9Hai9oV3ZoTTlielZQKy9VZEFIcUg5cmFmL0FNL2tQ L2ZZcFA3VzAvOEE1L0lmKyt4WG1QOEF3clh3bC96OTZyLzM2aXBmK0ZhK0VmOEFuNjFYL3YzRlFC NmIvYXVuL3dEUDVELzM4Rk4vdGJUL0FQbjhoLzcrQ3ZOUCtGYStFUDhBbjYxYi92M0ZSL3dyVHdm L0FNL09xLzhBZnVLZ0QwcHRZMDFSbHIyQUQza0ZlUmZFenhWcGtuanJ3N0phM1VjMFZoSWtrN3h0 dUMvTVBUNkd0UDhBNFZwNFA3M0dxbi90bkZUMCtHM2dwVklaOVZadlhiRU1VQWV2MmZpblJMc2Vm QnFNRHhTZk1yQnhpcTkzcStueTNEdXQ1RnQ0L2pGZVNINForRWY0THJWRi93QzJVVk4vNFZuNFkv NS90VHgvMXhqL0FNYUFQVmpxMm4vOC9rUC9BSDJLYWRXMC93RDUvSVArK3hYbGcrR25oYnZlNm9m KzJVZEgvQ3MvQ2ZUN1pxbi9BSDZpb0E5Uy90ZlR2K2Z5RC92NEtUKzE5UDhBK2Z5RC92c1Y1ZjhB OEswOEpmOEFQNXFuL2Z1S2ovaFduaEwvQUorOVYvNzl4VUFlbi8ydHAvOEF6K1EvOS9CU2YydnAv d0R6K1FmOS9CWG1YL0NzL0NQL0FEOWFyLzN4RlIvd3JQd2gvd0EvT3EvOThSVUFlbHRyT21JTXRm VzRIcVpWcnlMeGY0dDBvL0dQUWIrSzdqa3RMQmtFMHlObFZ6MTU5cTAvK0ZaZUR6L3k4NnIvQU44 UlU4ZkRQd1dJOXBiVkMzOTdFWDhzVUFldjJ2aVhScGYza2VvUU1qZk1yQnhnaXEwK3I2ZTl3N2k4 aHdUL0FIeFhrcCtHUGhMK0M3MVJmKzJVZE5Id3g4TS84LzhBcWY4QTM1ai9BTWFBUFdQN1cwNy9B Si9JUCsreFRUcStuZjhBUDdCLzM4RmVWZjhBQ3NmQy93RHorNnAvMzZqcGYrRlllRmNmOGZtcWY5 K282QVBVanErbmY4L3NIL2Z3VW45cjZkMCsyUWY5L0JYbC93RHdyRHdwL3dBL2VxZjkrNDZYL2hX SGhQOEE1KzlVL3dDK0lxQVBUanEybmY4QVA1Qi8zOEZKL2EybmY4L2tIL2Z3VjVsL3dyRHduL3o5 YXIvM3hIUi93cS93bC96ODZwLzN4RlFCNlkyczZZZ3k5OWJxUFV5Z1Y0ejR2MXF5MXo0ckNXd25X ZTN0N1h5aktoeXBibk9EK05iWC9DcnZDSi81ZU5VLzc0aXJRc1BBZmhiVGxiN05jYXZHNzhPeU5H dTc4TVVBWVVSQmo0NStsWXV2QWl6azRQU3ZUYkx3YnBtMTMrMWFqS203NUE5eHQ0d091MnVZOGZX a1ZscE04RVBtZVdBckFPNVlqazl6OUtwYmlQS1dOUk1ha2Jpb3pXNUkzdFViQ3BPMU1ha0JBOVYy TldINlZXYXMyVUlEVjJBL3V6VkR1SzBJZnVVUUI3RjZNRGJUeUJUSWZ1MUllbGRDSUlINjFFeHFW Nmhhb1pRd25OTUlwMUlha1JDNHFCNnNQVUQxREdpRW1ub2ZtSDFwaHA4WDNoOWFnbzBZY2J4Vnph S294ZjZ3VmZIU3VpT3hBeHNWWGM4bXJEVlhmcWFHQkN4cHZhbGFtOXFnQnBIRlJNS2xhb25xQm9o YnJTVXJkYVNvS0pvRDFxOWFqT2ZyVkdEdlY2MTZINjFyQVRMQldvbjRxYzFCSjByUmtsZGpVWk5Q YnJVWnJKakVOTUlwOU5OSmpJbTYwMm5QMXB0UU1La1Q3dFIxSW4zYWFBdlFMbU5hbHg3VkhiZmRY NjFLYTNSSlJVVllpcUVWS3B4VW9Dd3RKSVJzTk04ekFxTnBBVk5OdlFDcko5dzFCMHFkaGxUam1v U0RXVFEwTjcxSXRNd2FjS1Zoa3dQTlB6VUlPS2tYbXFRaDZpcGtGTVFjVklwcWtJc1I4Q3BNNEZR SzJLVm40NHJRVmlPNjVBcWhPT0JWdVp3Y0NxOHE1QXJPWTBWcWVsQlRtbEF3YXpzVVRMVWdxRVp6 VWlubXJFUHA2MHdkYW1VVlNFUFNyQ2RLaFhpbmc0TldoRXBOVkovOVorRlRsdVBTcTBqQXRrVVNZ Rk80L3dCWWZwVUk0TldaVUpmUGJGUTdlYXhhS1d3NWV0VHJVSXFSY2ltZ1pPS2NPdFJxY21wVkdh dGFramxxZEtqQXhUMXF3SmhRVHhUQTJLYXpjR3F1SXJ5L2RhczRqbXRGdVFhcXRIN1ZsSkZJaVhy VThkUmhha1dwU0d5ZFRWcXkvd0NQKzMvNjZyL01WU1U0cTdwLy9IOWI4LzhBTFZmNWlySlBvcndZ Vi9zN2J1RzdJT1B3RmFmaVdlRzMwNjM4NlZFM1M4YmpqUEJyazlPMHVLOTArTGZOS2gyRGxOdjlR YXcvRStrejZYSEJMRHFrN3BJeFhiSkZHMjN2eDh0WVdMT21Hb1dSL3dDWHFML3ZxbC90Q3kvNStv disrcTgwOEllRGRZOGZhcnFzOG1zeldsbFpTQ0ptaitVczNPQUZIQTRHVFhhajRJREgvSXphbWY4 QWdkSURWL3RDeS81K292OEF2cWorMExML0FKK292KytxeXY4QWhTUHA0bDFQL3Y1U0g0SUgvb1pO Uy83N29BMS83UXN2K2ZxTC92cWorMExML242aS93QytxeC8rRklQL0FOREpxWC9meWtQd1FsSC9B RE1lby84QWZkQUd6L2FGbC96OVIvOEFmVkg5b1dmL0FEOHgvd0RmVlk0K0JzcDUvd0NFbXZzZjc1 by80VWU0NitKNzhmOEFBNkFOaiswTEwvbjZpLzc2by90Q3kvNStvLzhBdnFzYi9oU1dPdmlqVVA4 QXZzMW1hMzhIcnV3MHU0dTdQeExlU3ZFbTdZN0dnRHJQN1FzditmcUwvdnFqKzBMUC9uNmovd0Mr cTh2K0h2Z0xWL0cxdGVYazJ0WFZyYTIwdmtmSzVKWnNaUDREaXU1SHdRR1ArUmwxTFA4QXYwQWEv d0RhRm4vejlSLzk5VXYyK3ovNStvdisrcXgvK0ZJZjlUSnFYL2ZkQitDQjdlSk5TLzcrVUFhLzlv V2YvUDFGL3dCOVVmMmhaZjhBUDFIL0FOOVZqLzhBQ2tIL0FPaGoxSC92dW1uNElTLzlESHFIL2Zk QUcyTCt6LzUrWS84QXZxayszMmYvQUQ4eGY5OVZqajRHVEgvbVpyNy9BTCtVbi9Dam5IWHhQZjhB L2ZkQUcxOXZzLzhBbjZpLzc2byszMlgvQUQ5UmY5OVZpLzhBQ2tjZGZGR29mOTltc1R4TjhKTDdS OUZ1TlFzdkVkM09ZVjNHTjNOQUhhL2I3UDhBNStvdisrcVB0OWwvejlSZjk5VjVyOFBmaDNxbmpQ UjMxYTUxeTZ0Ylh6V2lqQ3VTV0k2bm50elhaLzhBQ2tCLzBNMnBmOTkwQWEvMit5LzUrWXYrK3FQ dDluL3o4eC85OVZqL0FQQ2tQK3BsMUwvdnVrLzRVZ2YraGsxTC92dWdEWiszMlgvUHpILzMxUjl2 c3NmOGZNWC9BSDFXTC93cEIvOEFvWk5SL3dDKzZRL0JDWC9vWk5RSC9BNkFOejdmWmY4QVB6Ri8z MVI5dnMvK2ZxUC9BTDZyRi80VVpOLzBNdDkvMzhvLzRVYy9meFBmai9nZEFHMS9hRmwvejlSZjk5 VWZiN1AvQUorby93RHZxc1QvQUlVampyNG8xRC92czF6bmpINFc2aDRjMEtmVkxUeERkWEN3akxv N2tjVUFkOTl2cytuMnFQOEE3Nm8rMzJYL0FEOHhmOTlWNTc0RStHV3BlTFBEMFdzM212WGR0RE03 TEVxT2NrS2NaTmRWL3dBS1FYL29adFMvNzdvQTJQdDlsL3o4eGY4QWZWSDIrei81K1kvKytxeC8r RklEL29aZFIvNzdwUDhBaFNCLzZHVFVmKys2QU5uN2ZaLzgvTWYvQUgxUjl2c3YrZm1ML3Zxc1Qv aFNELzhBUXlhai93QjkwaCtCOG4vUXlhZ1BxOUFHNTl2cy93RG41aS83Nm8rMzJmOEF6OHgvOTlW akQ0RnpmOURMZmY4QWZ5ay80VWM0NitKNzhmOEFBNkFObjdmWi93RFB6Ri8zMVI5dnMvOEFuNmov QU8rcXhUOEVjZjhBTTBhZ1ArQm11VDhkZkRYVWZDV2lOcWxycjkxY3hJd0RxemtFVUFlamZiclAv bjVpL3dDK3FUN2ZaLzhBUHpIL0FOOVZ4SGczNFQ2aDRpOE9XbXIzM2lDOHQxdWwzeHh4dWZ1NTdt dWgvd0NGSEovME0rbzUvd0IrZ0RXKzMyZi9BRDh4L3dEZlZIMjZ6LzUrWS84QXZxc2ovaFJ3L3dD aGwxRS84RHBQK0ZIZW5pVFVQKys2QU5mN2RaLzgvTWYvQUgxUjl2cytuMm1ML3Zxc2MvQTV2K2hq MUQvdnVtLzhLT2ZQL0l4MzQvNEhRQnMvYnJNZjh2TVgvZlZJYjZ6L0FPZm1ML3Zxc3IvaFJFMy9B RU1sOS8zM1FmZ1lSMThTMzMvZmRBR3I5dnMvK2ZtTC92cWsrM1daNlhNWC9mVlpSK0J5ai9tWjc4 ZjhETmNUOFFQaDdxUGd6VFk5UmcxdTR1b0dmYTI1eUNLQVBTL3Q5bi96OHgvOTlVbjIrejZmYVkv KytxNUR3MzhINzNWTkRzOVJ2dkVGM0ExMUVzeXh4c2VGUFN0ai9oU0NkdkVtb2Y4QWZkQUd2OXVz L3dEbjVqLzc2cHYyK3ovNStZdisrNnlmK0ZJRC9vWXRRUDhBd0ttLzhLUXlmK1JoMUQvdnFnRFkr MzJmL1B6Ri93QjkwbjI2ei81K1kvOEF2dXN2L2hSbzcrSkx6L3Zxai9oUnNmOEEwTXQ2UCtCVUFh bjIrei81K1l2Kys2YWIrei81K1kvKytxemYrRkhRai9tWnI3L3Zxai9oU0ZzT3ZpYSsvd0MrcUFO TDdmWi84L01YL2ZWSWI2elAvTDFGL3dCOVZuSDRJV24vQUVNOS93RDk5VndYeEM4Q1gzZ21HM3Vv TlludTdhWnRtU3hCVTBBZW0vYnJQL242aS83NnBQdDFuL3o4eGY4QWZRckEwbjRKM0Z6cHR0Y1gv aUM2aWxtaVdRcEdlQnVHYXZmOEtOaTdlSXI4L3dEQXFBTkg3ZFovOC9NWC9mVko5dnMvK2ZtTC92 b1ZubjRHcC8wTUYvOEFuVGYrRkdvV3dOZnZ2em9BMHZ0OW4vejh4ZjhBZlZIMjZ6LzUrWXYrKzZ6 L0FQaFJLRHI0anUvKytxWC9BSVVWRDM4U1hnLzRGUUJmKzMyZi9QekYvd0I5Q2tOL1ovOEFQekYv MzJLcGY4S0x0LzhBb1pMMy92cWsvd0NGRzJvLzVtVzkvT2dDOTl2cy93RG41aS83NkZIMit6LzUr WXYrK3hWRS9BNno3ZUpiMzg2ODg4ZStCci93WmVXYVJhcExkUTNaMm8rNGdocUFQVWZ0OW4vejh4 Zjk5aWo3ZlovOC9NWC9BSDJLeUxQNEdTRzNqTjc0aHVrbUtnc3FIZ0hGV0Q4Q29PM2lHOVA0MEFY L0FMZFovd0RQekYvMzBLRGYyUS81ZW9mKytoV2Yvd0FLS2lIL0FESDc3ODZRZkFxTm13TmV2ZnhO QUdrTCt6LzUrb3YrK2hSOXVzLytmbUwvQUw2RlVQOEFoUTBmL1F3M1EralVmOEtIaC82R0s4Lzc2 b0F2L2JiUC9uNGkvd0MraFI5dXMvOEFuNWkvNzdGVVArRkUyM2Z4SGVmblIvd291MC82R085L09n Qy85dXMvK2ZxTC92c1V2MjZ6L3dDZnFML3ZzVm5OOERMTUQ1ZkV0NkQ5YTg1OFkrQ05SOExlSkxI U285U2t1RXZpcXd5YmlPU1FPZnpvQTlYKzNXZi9BRDlSZjk5aWwrMjJmL1B6Ri8zMEt5SVBnU0Fn RjE0aXUxbC9pVlR3RFV2L0FBb20zN2VJYjAvalFCcGZiYlQvQUorWXYrK3hTZmJyUC9uNmkvNzdG WnArQk1JLzVqOTcrZElQZ1RFeHdOZXZQcVRRQnFmYmJQOEE1K1l2Kyt4Uy9iYlQvbjVpL3dDK2hX WVBnTEgvQU5ERGRmZzFPSHdHaEgvTXczZjUwQWFQMnkwLzUrWXYrK3hTL2JiUE9mdE1YL2ZZck1Q d0l0dS9pTzgvT2ovaFJObjM4U1h2NTBBYW4yMnovd0NmcUwvdnNVdjIyMC81K1l2Kyt4V1Ezd0tz OGZMNGx2QTN2WG5PdStCOVUwWHh6WitHMDFGNWZ0Ykw1VW9ZaklQdFFCNjc5dHRQK2ZtTC92c1V2 MjIwL3dDZm1ML3ZzVml4ZkFoQXVKL0VkM3ZIREFldFNmOEFDaUxmdDRodlQrTkFHdDl0dE1mOGZN WC9BSDJLUHQxcC93QS9VUDhBMzJLeHo4Q1lSL3pIcjM4NkYrQThUbmpYcndmVTBBYkl2YlAvQUor WXYrK3hTL2JMVC9uNWkvNzdGWTQrQWNZLzVtRzYvd0MrcWQvd29XRWRmRVYzL3dCOVVBYS8yeTAv NStZdisreFI5dHRQK2ZtTC92c1ZqLzhBQ2g3WWRmRWQ1K2RML3dBS0lzeC96TWQ3K2RBR3Y5c3RQ K2ZtTC92c1U3N1phWS80K1l2Kyt4V0kvd0FDYlRIeStKYjBIM3JnWnZEK28rRmZHMDJnM042Sm8y ajh4SlNpdmxlY1lEWndhQVBkOVBuZ2EwM0xOR1J1Nmh4NkN1QitJenBKWTNCUjFZQlVCS25QYzFp UVdraURMWE80ZW4yZU1ELzBHcW12WFUzOWxTVzdPREZ3Y0JGWCtRRlZGYW9SeExWR1JVeDZWR3dy b1pKSFRHcHg2VkNXcVdBeVNxN0NwMi9Hb3l1ZTFadERSQ0JWNkQvVjFYQ0gwcTJpN1U2VTRxdzNz WElzQk9LZXhxQ054dHFUZHgxclc1TmhqMUMzMHFZMHdqTkpnUTlCVEdxVnhnVkM1eFVnUnNhZ2Vw anp6VVRDczJORUpwOFlPNGZXbDI1TlNLaDNEaWtrTXVSY1NDcm1hb0lkckFtckt2bnZXOFJORWpW WGs2MUtXelViVU1SQTFOcVZoVVRWREFZMVJQVG1OUnRVTXBFYlUwVTgwQktrWkpBT3RYclU0Qit0 VW9sSzVxMUM0VU1LMGpvSmx3bmlvWktBL3JUV09lbFhjVmlGaFVSelU1eFViampOUUJIVENhZmlv bU5ReGpXcHRLYVNrQVZJblNvOFZLcTRYbWhBWHJjNFFWTHg2MVVqa0FYR2FtRW1LMlRGWXovTmFq ekg5YVozb3JHNVJJSldvM0VuclRWRlBBNXAzRTBTQWMrbFNiRmFvaFVpbXFFT0VDK2xQK3pyMkZP U3AxcTBnS2h0MUZSN2RwcSt5NXFsS01TR2xKV0FqZVhIQzB6em05YWlZODBnck81Uk9KbjlhZDVy NTYxQ3RTS0thWWg2OWFtVHBVUUZQUW1xUWlRUkxUeENtT1JTS2MxTWdxa2hFZjJkY2RLamVIYjh3 NkNyb0hGUnlnaU5xcXdGU21QY05UdTM0VlVacXpic1VUZWUxT1daODlhckwxcVZhbTRFdm1PZXBx Uk9sUnFLa1dxUWlWQUN2UE5POGxEVEZOU3FlMVhZQkJBbnBUdklYRlNvS2VSeFZjb215bTBRWGtV MHRzR2FzeWpDZEtvM0JBVWZXcGVnQTF3dzcwZ3VHcXNUazhVNWF6dU10Q1o2ZHVadTlSS0ttVVZh RVBYdFVteFdxTVZJdFVnRkVLZWxPOGxmU25MVWdGVWtCQVlSanBUN0liYiszSC9UVmY1aXBjVWx1 TWFqYmY4QVhSZi9BRUtrMW9DUGV0Qy80OElmOTBmeXJLOGRmOGVWbi8xMGIrVmF1aGY4ZUVQKzZQ NVZsZU92K1BLei93Q3VyZnlybUtMbndRVURRZkVMZHpxcmYrZ2l2VE1WNXI4RVArUmU4UWY5aFp2 L0FFRmE5SlpsampaM09GVUZtUG9LUXhXWlVSbmRncXFNc1NlQUtnc2RTc05UamFUVDd5M3VrUTdX YUdRT0ZQb2NWd0ZwOFhQRDJxMnQzYVhpemFmSzBja2FtUWIwYklJSHpEcCtJcm1QaGw0eTBMd2o0 WHZsMU9lVDdUTGRia2dpVGM3S0VBejZEOFRRQjdqVGhYUGVEL0ZkdDR3MG1TL3RvWklCSE0wVFJ5 RUVqR0NEeDZnMTBJb0FhdnlQZy9kUDg2ZThXYWE2NzFJcVNHVGZGejFYZzBBVXBJOFZtYXV1Tkd2 dit1RFZ2U3hnaXNiVzAyNkpmZjhBWEJxQU9JK0J3eDRJdnlPK3FTLytnclhwQXJ6ZjRILzhpUmZm OWhPWCtTMTZPOGlSUnRMSzRTTkFXZHljQUFkVG1nRE04UmVJYkR3dnBMNmpxTHNJZ3dSVWpHWGRq MlVWbCtGdmlEcFBpM1VKYkt3aHU0NVk0dk5Zem9vR01nZGlmV3VRdEVmNG5lTHA5Vm5SditFYjBu Y3R2R3c0bWt4bkordlUrMkJXSjhFaC93QVZmZm4vQUtjMi93RFExb0E5M0ZMU0Nsb0FJenRmWWZ1 dDBwN3hWRzY3bFByMnFhS1VQR0NldlEvV2dDakpIaXNQeFN1UEN1cDUvd0NlQnJxSll3UmtWenZp MWR2aFRVai9BTk1UUUJ6UHdUR1BoWlpZNzNVLy9vVmR6ZFhNZGxaVDNVeFBsUXh0SStPdUZHVC9B Q3JoZmduL0FNa3RzdjhBcjVuL0FQUXEydmlKZWZZZkFHc1Nic004UGxMOVdJWCt0QUhQRDQxK0c4 RC9BRVRVUi93QlAvaXEzL0N2eEEwbnhkZnpXZW53M1NTd3hlYXhtUlFOdVFPeFByWGwzZ2Z4WjRS OFArSC9BTE5yR21tOHZKSjJkbSt6SklGWGdLTXNmYXZXL0NtcGVHTlp0M3ZmRDBWdEd5L0pLSTRC Rkl2c3cveUtBT2pGTDJwb3BhQUhRdGh2TFBROUtmSkhrWnFGaGtjZFIwcWRKZzZLZldnQ25KSGl1 VStJSy84QUZCNnIvd0Jjai9JMTIwa1lLNUZjZDhSbDIrQTlVLzY1SCtSb0FyL0NrWStGdWhZLzU1 dWYvSHpYV1N6Ulc4THpUeUxGRkdwWjNjNENqMUpya3ZoVno4THRELzY1di82R2E1djQyNnZOYjZW WWFWRTVWYmxtbGxBL2lWY1lINW45S0FOZTcrTVBoVzF1V2hqYTh1RlU0OHlLSDVUOU1rVjFIaDN4 UnBQaW0xZTQwcWRwVmpJV1JIUXF5RTlNaXVBMGpVdmgzNFIwbTMwNjgrejNkODBTdGRTQzI4ODd5 TWtGc1lHT21CNlYzZmhVZUhXMHQ1dkRJdHhaelNsM0VHUjgvZkk2ajZVQWJvcGNaRkpTaWdCMERj K1czWHRVa2tXYXJ1Q0J1SFVjMVlFd1lLZjcxQUZTU0xGY0o4V1Yvd0NMYzZqWG8waUJoWG4zeGZY YjhPZFFIdFFCcStBaGo0ZCtIUU9QOUJTdWhybnZBWC9KUFBEMy9YakhYUS9YaWdEbjlmOEFHbWor R2RTc3JIVTVKRWU2VXNySW00SU00RzdIUEo5UFN1aUJCd2E4UjAxZitFKytNa2w0UnYwK3hmZU05 UExqNFFmOENibXZidTlBRGhTNHlNVWdwUlFCSkErZjNiZFJUM2l5S3JObFNIWHF0V0JNdVIvZEl5 S0FLa2tlSzgwK055NCtIejUvNTdyL0FERmVyT2dZWkZlV2ZITWJmQUxEL3Bxdjh4UUIyV2hyand6 bzRIYXhoLzhBUVJXa2kxUjhQcnU4TTZQL0FOZVVYL29JcllqaTlxQUlkbUJVYmNWYXVNUlIrNTZW Uzk2QUEwdzA0bW1tZ0JqVm55NnZwa0YxOWxtMUcxanVNaGZLYVpRMlQwR0swRFhuR3QvRGk4MVR4 bzJ1cHFGdkhFWjQ1ZktLRXRoZHZHZitBMEFlZ212TnZqY29QaEd5L3dDdm9WNlUzTEU0cnpYNDIv OEFJbzJYL1gwS0FQVkVURnZiRHQ1RWYvb0lxVlZwWWt6YjIzL1hHUDhBOUJGV1k0czBBUWJEaW1k S3NYR0kweDNOVmFBQTAwMHBOTU5BRFRXZTJyNll0MzlrT29Xb3VkMnp5VE11L2Q2WTY1clFOZWNU L0RpOGw4Zkh4Ri9hRnVJZnRpM1BsYkR1d08yYUFQUVRYbC94bVVFK0dzLzgvd0F2OHpYcUpyeS80 eTlmRFgvWDhuODZBUFhiZ2Y2UWV2YitWQ3JVMHlablArZTFQaml6UUJBVklwQndLbW5Hd0JlNXFJ ZEtBRU5SbW5tbUdnQmhxb2I2eisxRzBGM0I5cC81NCtZdS93QmZ1OWFudUo0YlMza3VMaVFSd3hL WGR6MFZSeVRYa253OWhsOFIvRURWZkZEeGxZRUw3Q1IvRTNDajhGRkFIck5lWGZFNUFmSFhnM1Av QUQ5S1AvSGhYcUpyekg0bS93REkrZURQK3ZwUC9RaFFCNjFPUDlLay93QjQwS3RTekptNWsvM3Fr U0xpZ0NBcWNVcWpBNHFTWWJTRnBsQUNHbUduR21ubnBRQlV1YjZ6dEdSYm02Z2daL3VpU1JWM2ZU TlIzTjlaMmJJbDFkd1FNLzNSSklxbHZwbXZLUEV6RHh2OFdyRFM3VDk3YldCQ3lPT1I4cmJwRCtl Rit0SjRoY2VOL2k1WldGb2ZNdExBaFpIWGtZVnR6bjgvbG9BOWNJcnpEeGdvUHh3OEgrN0N2VVc1 SnJ6RHhmOEE4bHg4SGY3MzlLQVBWbkg3NS84QWVOT1ZhZXlmdm4vM3FtU0tnQ3VRYWxSZG9va0dI QzBvb0FRMHcwNDB3MEFNUDQxR2FrTk1Jb0FqSXJ4bjRrS0I4VnJNK3RpZjVtdmFNVjR6OFNmK1Ny V1gvWGszOWFBSzhmOEFxeFdGNGtPM1RwaVA3djhBV3QyTWZ1eFdCNG4vQU9RWFAvdS8xcWhIRGZh R3FSWmlldFVpZWFWVyticlYzRVg4YmppbnJBbzdVMkxxS3RiUldpUWlFd0tLYjVLWTZWWUlxTmpW V0FoS0tPZ3ByZGFjMmFaVVBjQ05tS3R4VERNL3JVakNvWEZTMk1ET3c3MGduWW5xYWhjMHdIRlRj WmVXVHpPRFRnaGVxMXVjdlYrQWNkS3VPb2hCYnJTR0JmU3JPS1kxWFlSWE1LRHRTRlZVY0Nuc2Fq SnFHQkczVDFxUGV5OFpxUTFHdzlLbTR4RE00NzAzejI5YVkvV29tcUxqTEt6bjFxVE80VlNVNEZX NHo4b3Frd3NTcERrNWFuL1oxeFU2TDhvTk9JNHE3Q0toZ1NtK1VxMU85UU1hVFFEWDZWQytkd3hV aE5OSTZWSUlZWldIZWtNemV0RENvalV0bEQvT2JOU0pMdStVMVgrbE9qKytNMGt3SjZla0E2OXFh Qjh3cTZGRmFKRWxmeUZwclFyNlZiWVlGUU4xTk93RVBsZ2MweHV0UFkwdzFOaGtaNE9SU0dSdldu R282a1lsSjNwYUtrQjYwOFV4YWtGVWhNVVU5YVlLZXRVSW5pcXl1S3JSVllXclFoNSs2YW9TL2Zh cjUrNmFvUzhPMUU5aG9wTjk0MGxLMzNqU1ZnOXhqMHFaYWhTcGxxa0EvRktNMERGS0twQ0pFNjFa VG1xeTFZanEwSW5BcU9mL0FGYmZTcEZxT2Y4QTFiL1NyNkFVYXBOMXE4ZTlVVzZtc0pGSUZxZEtn WHRVNlVrQk1vcDQ2MHhhZjNxMEljT3RTSlVRNjFLbFdJc0owcVFWR25TcEJWb1RJNS91R3M2NFhL aXRHZjdsWjF4d29xSmpLblExSW5KcVB2eFVpRG1zVU1zcFVvRlJKVW9yVkNIRHJUbHBvcHd6bXFB bVNwVnFKT2xTcjFxMERIOXFaYjg2amIvOWRGLzlDcDFOdHVOUnQvOEFycXY4NlV0aExjOTYwTC9q d2gvM0IvS3NyeDEveDVXZi9YVnY1VnE2RnpZUS93QzRLeXZIWC9IalovOEFYVnYvQUVHdVlzdmZC RC9rWHZFSC9ZV2Ivd0JCV3ZTNjgwK0NIL0l2ZUlQK3dzMy9BS0N0ZWwxSXp5YjR0M21qbG9kRXM5 S3RyblhycGwvZUpFUE1pQlBISTZzMzh2d3JtYlBSb2ZoNTR4czR2RlZoYlh0aGRSS2ZPWk55eE4z SXoxMm5nKzNOZTVUYVBwdHhxbHZxYzFsQzk5YjVFVTVYNWx6UzZubzJuYXlzQzZsWnhYS3dTK2JH SkJrSzMrZTFBRnUyanQ0NEVGcWtTUWxRVUVTZ0xqdGpGU2ltcUFCZ0FBRGpqcFMwQU83MUZuWk1S L2VINmlwYWhuK1VLLzhBZFlVQVN3VENRWXpXZjRoWEdoWDMvWEkwUlMrVmVPaFA4VkhpRTU4UFhw SC9BRHlOQUhBZkE3L2tTci8vQUxDY3Y4bHJTK0tzZXNYUGhSTFBScmU0bmE0bkNUcmJvV2J5OEU5 dTJjVm1mQTcvQUpFeS93RCt3bEovSVY2VU9LQVBHdEk4UytNOUIwS0hTclB3VXlXMFVaWEpnbHl4 UDNtUHVldGNuOFBkWTFYUmZFTWsya2FiOXZsbFR5cFUyczNsb1hYTGZMNlY5Sk9OOGJwMDNLVnpY RytEdmgzYStEdFZudjdmVWJpNWVXRXhGSkkxVUQ1Z2M4ZlNnRHRqd2NVdE1HS2RRQTZvU2RqT283 amNLbDcxRk44ckkzdmcvalFCSmJ6aVJjZDZ4ZkdZeDRUMUgvcmthc1dzdmwzVHhrOURWZnhvYytF Yi93RDY1bWdEay9nbC93QWt1cy8rdm1iL0FOQ3JyOWR1OUlzdEprazExb0ZzR0tvd25YY3BKUEhG Y2Y4QUJML2tsOXAvMTh6ZitoVjFuaUh3M3B2aWpUaFphbkV6UnEyOUhSdHJJM3FEUUF6K3ovQzM5 aEZUYmFXTks4djVpRlRadC8zcThpK0VSWlBpTGNwWWx6WkdDYmRudkdHK1FuOUs2Qi9nZlptVENh N2RMQm5PeG9WSi9uaXU3OEwrRWRLOEpXYndhZEc3U1NZODJlVTVlVEhyN2UxQUhRS3U1Z09tYW8z TTl3bHUxM0dFOGtLV1VIK0lDcnFuYWMxaVgybFhNNU1jTnlVZ2JQeStnUFhGQUdsWjNhM2NLeXFN QmhuSHBVcmtvcmowK1lmMXFLeXRFczdkSVUrNm94VXNvK1pQUS9MK2RBRXR0UDVxVnkveE1HUEFX cC85Y3ovSTFwMkV4V1prSjZHc3Y0bUVId0ZxUC9YSnYvUVRRQlMrRlA4QXlTL1JQOXgvL1F6WElm SEt6bDNhUGZLcE1ZRWtKUG8zREQrdjVWMTN3by81SmZvdis0Ly9BS0dhNkxXdEZzZkVHbFM2YnFN WG1XOG5vY0ZUMlpUMk5DQTVqUi9DSGcrNzhDd1NKWVd6MjB0cjVqM2JjeUJ0dkxiK29JT2Z5cmkv Z2ZMT3ZpRFZZSTJaclEyd1p2VGNHd3ArdU0xcFA4R0xwUTl0YmVKNWtzSGJKaGFNOC9WUTIwMTNu aFB3bHAzaERUbXRiSGZKSklRMDA4bjNwRDIrZzlxQU9ncHdwdEFvQWRWZDI4dU54L2NPNzhLbjdW RE11V3gvZVVyUUJOYXppV01jNXJpUGpKZ2ZEdSsrbGREcDA1V1FvVFhPL0dJNStIbDcvdW1nRFM4 QW5Qdzc4UDhBL1hrbFFmRVBYZjdBOEdYazZQdHVKeDluaHgxM053VCtBelUzZ0RuNGQ2Qi8xNXBY bmZ4UHVKL0V2anJTL0Mxb1cyeGxRM3B2ZnEzNEwvV2dEcFBnNW9YOW0rRlgxS1ZNVGFnKzVTZXZs cnd2NW5KcjBXb0xTMWhzYk9HMHQxMnd3SXNhQWRsQXdLbW9BZFNpbTBvb0FVMVdtWXBDZittYmZv YXNWWHVWTEIxSDhTRWZqUUJZdGJnU29PYzE1dDhkL3dEa1JELzEwWC8wSmE3TFRiakQ3YzF4WHgx T2ZBeC8zMS85Q1dnRHZQREEzZUZ0SC82ODR2OEEwRVZ2UngxaCtGQm53cm8vL1huRi93Q2dpdWhV YlZ6UUJsWDc3cDluWmFyVWp2dmxaczlTYVNnQU5OTkJwcE5BQWZyWEY2cDhSYkRTL0V4MEtTd3Vu bkVxUmVZckx0eTJNZS9ldXpOYy9lK0ROQnY5WE9xM05rWHZTNnY1bm1zUG1YR09NNDdVQWJwR0Rq TmVhL0czL2tVckwvcjZGZWtubXZOdmpiL3lLVmwvMTlDZ0QyRzFUTnJiZjljVS93RFFSVjJOT0ty MlF6WjIzL1hKUC9RUlZ3L0loUG9LQU1tN2ZmY0VEb3ZGUlUzZHVZdDY4MGhOQUNrMHcwcHBwb0FR MXhrdnhGc0kvRm4vQUFqeHNibzNIMmtXL203bDJidlgxeFhaR3ZMVjBGOVgrTU10N0ZZU1d0bFlz czBzcm95K2RJT2pEUFhMZW5aYUFQVHpYbC94bEh6K0d2OEFyK1QvQU5DTmVubXZNUGpIL3JQRFAv WDhuOHpRQjdVeVpsL0tyQ0pnVTBMOC93Q1ZTT1JIQ3plZ29BeTUyM3p0am9PS1lUVEZPUm4xcFNh QUNtbWxOTU5BRkRXdEp0ZGQwbWZUYnpmNUV3dzNsdHRJN2o5YVpvdWpXZmgvU1lkT3NJOWtNWTZu cTdkMmIxTmFKcGhvQWFhOHgrSm4vSSsrRFA4QXI3VC9BTkNGZW5Hdk1maVgvd0FqNzRNLzYray85 Q0ZBSHM3Sm1kejcxT2tlQlNiZjNyZlduek41VnU3ZWdvQXpYYmZNN2RzNEZKbW1Kd0tjVDZVQUlU VWJxR1ZsUFJoanJUalRTYUFPZThQK0RkSThNQzgrd1J5RnJvbmU4cjdtQy8zQWZTanc1NFMwcnd0 OXBPblJ2dnVIM1BKSzI1Z3ZaYytncmZOTk5BRFRYbC9pNy9rdVhnLy9BSHY2VjZnVFhsL2kzL2t1 WGcvL0FIdjZVQWV5Qk15SDYxWlZNTDBwcXI4NSt0T3VUNWRzNTlzVUFVTjI1MmYxTkdhYW93dUtE UUFHa05INDAwK3hvQVEwdzA0MDAwQU43MTR4OFN2K1NyV1AvWGszOWE5bnJ4bjRsZjhBSlZyTC9y eWIrWm9BcnA5d1ZnZUovd0RrRnovN3Y5YTMwLzFZckE4VGY4Z3VmL2QvclZDUFBHTkVZeTlJMUxG OThVeEkwNHNibEZYQjBxbEg5NFZjWGdWMFIyRUkxUXRVelZBL2VoZ1JOVGFjYWJVZ05QU29aS21h b1g2VkRHVm5xTW1wSHFNK3RaalJZdGg4K2ZhdEczTloxdDk3OEswYmV0S1ltV1NPS2hlcGowcUo2 MVlpdTlSR3BYcUlpczJBMm1OVW5hbzJxV01pZW9HNjFNOVF0MXJOalFnL3BWeUlmSXRVeFZ5TDdv cHhCbWxIOTJocUl5QW96UTFkQzJKSUhxdTJhc1BVRFZER1JtazdVVUhwVU1FUnRVTGRjVk0xUXQx cUdNU25SL2ZGTnAwZjN4U1F5eC9FSzBFd1JXZi9BQkNyNmNMaXRvRWlOakZWbi9HckxkS3J2VFlF TFV6dFQycGxaakVQU296MXFROU1WR2V0SUJ0RlNlU2M4VW9nYWxZWXhhZU90S0lHSFNrMkZUelRW MElrSDBwNmltQTRweGxVR21JblRpcHhWSVhBRk8rMVZha0ZpMld3YXB5OHVhUnJqUFRyU1ozVW03 Z1ZXSHpHa3djMWFhSGNPT0RTZlp5VFVXR1FyeFVxbW5mWm1vOGhoUlpqRlhtcEZIRlJJQ0tsUTdR YW9rbFFWTXRWUmNLS1VYUzFTWUYwSEFxT1ZzeG5tb1B0UXFOcGl6WUhTcTV0QkM5dndxbXk1SnE0 T2xJMEdlbFp0WEdWRkdLa1hpcGZzcHpUaGJOUzVXTzQwSG1wRjVwdmtzdE9VWXFrSWtVVktvNXFK V1ZWNW9Gd29OV21JdEx4VW1jQ3FmMmxjOURTL2FRUlZjd0UwclpURlVweGxCVC9BRFN4SXAyemYx cVhxTXp5dUQwcDZkZWxXamIwbjJWdTFaOGdERk5TcWVhUHM3Q2xNVEpnMWFRaDRxUlJVWTRwL21x dldxQW1XbmcxVyswclMvYVZxazBCWnoxcExiL2tJMi8vQUYxWCtZcXVad1J4VXRpZDEvYm4vcHF2 OHhTYkE5KzBML2tIdy83Z3JKOGRmOGVObVA4QXBxMzhxMXRDNHNJdWY0QldUNDYvNDhiUC9ycTMv b05jeFJmK0NIL0l2ZUlQK3dzMy9vSzE2VlhtbndRLzVGN3hCLzJGbS84QVFSWHBWSVk2bEhKeG1t MWkrTU5aR2dlRTlSMUFOaVJJaXNYL0FGMGI1Vi9VMEFjTHF2eHBTdzFhN3RMZlJ4Y3d3U3RHczMy amJ2Mm5HY2JhOU4wdlVJZFYwcTAxQzNPWXJtSlpWOXNqcFh6eG92aEJ0UytIZXQ2NlVMVDI4aStR ZTVWZVpQMFlmOTgxNlA4QUJmV3Z0dmhpZlM1SHpKWVMvS0NmK1diY2o4anVvQTlMelRKaHVpWWUx TG1odnVtZ0RJbmJiZm8vOTVBYW4xdzU4T1huL1hJMVd2Qmg3WnZxdjYxUHJQOEF5TE4zL3dCY3FB T0QrQjMvQUNKbW9mOEFZU2sva0s5THJ6UDRILzhBSW02aC93QmhLVCtRcjBzVUFPckU4VStLOU44 SmFhTHUvWjNlUTdZWUkvdnlOL1FEMXJhcnhUNDQyOXlOWjB1NVlNYlZyZG8xUFlPR3l3L0lpZ0My ZmpQckVtWjdmdzBodGY3NWVSdi9BQjRERmRaNE4rSnVtK0xMc2FlOXRKWjZnd0xMR1R2UjhkY04v aUtuOExlUC9ER3FhZmEya0YxRFl6TEdxZlpKL3dCM2pBeGhmNFNLMjdUdzdvOWxyRTJzV2RqRERl VHg3SGtqR0FSMTZkT2ZYdmlnRFdGUjNITUxVL05OZmxEOUtBTWVadG1wNTdNQTFOOFh0bndmZmY4 QVhPaTlHTG0zYjFYSDVHbStMUDhBa1RiMy9yblFCeS93Uy81SmhhLzlmTTMvQUtGWG9RcnozNEpm OGt4dGYrdm1iLzBLdlFxQUZKMnF4OUJtdklHK09FcXV5LzJBaHdTUCtQay8vRTE2Ni84QXEzLzNU L0t2QVBoS2lOOFJGRG9yRHlKK0NNaWdEcUxYNDVRR1lMZWFISWlIcVlad3hINEVDdlJ0QjhSYVg0 bHNQdG1sWElsUUhEb1J0ZU0rakwycGRXOE82UHJsbTlyZjZmYnlJd3h1Q0JYWDNWdW9OZUdlSDU3 bndCOFR6WU5NelFDNUZyUDZTUnNmbFlqMTVCcDZBZlJBcU9maUluMDVwL1EweVhtTmg3VWdNaGo1 V3F1QndDMmFvZkVnNThBNmgvMXliLzBFMWR1dU5SaWIrOGkxUStJMy9KUDcvd0Q2NU4vNkNhQUt2 d24vQU9TWDZML3VQLzZHYTdJVnh2d24vd0NTWDZOL3VQOEEraG11eHpRQTZ1QThhZkV0L0NPdWpU UnBhM1FNQ3krWVp0blhQR01lMWQ5WGdueGxIL0ZjcC8xNXhmemFnRGQvNFhrNDYrSHdQKzNuL3dD eHJ0ZkFuamIvQUlUUzN2WmZzSDJUN0s2cmdTNzkyNEUrZzlLMjdWdE5ObkJrMlgrcVgrNTZDcmNJ dHdwYTJXRUE5VEVCajlLQUo4MUZNY0tHOUNEVDgxSFB6RTMwb0F4a1BsYXBLblREVmgvRjQ1K0hk NS91R3R5NStYVnMvd0I0S2YwckIrTG4vSk9yei9jTkFHcjhQLzhBa25lZ2Y5ZVNWdXZaMnN0MUZk U1cwVDNFT2ZMbFpCdlRQQndhd3ZoLy93QWs3MEQvQUs4a3JvNkFIVngzaTc0ajZSNFVtTm50ZTkx REdUYnhOZ0ovdk4yK2xiM2lIVlA3RThPMytwZ1phM2daMUI2YnY0ZjF4WGlYdzA4TngrTHZFdDNl NnZtNXQ3Zjk5TXJuL1hTT2VBM3R3VCtBb0EyVitPTjhKZHo2RmJHSFBhZGdmenhpdlFmQ1hqelNQ RnlGTFV2YjNxRGM5ckxqZGoxVS93QVFyZS9zeXdlMU5xYkMxYTN4anl2SlhaajZZckMwUHdEb25o N1dyblZiRzNZVFMvNnRXNVdCZjRnbjEvOEFyVUFkUFVjdkRJZjlvVTdOUnovNmxqK05BR0hBZkt2 M1RQUnlLNUw0NEhQZ1QvZ2Evd0RvUzExdHdObXN5WS9pT2E1SDQzZjhpSC93TmY4QTBKYUFQUlBD WC9JcWFSLzE1eGYrZ2l0eTRmeTdTUnZSVFdKNFMvNUZUU1Ardk9ML0FOQkZhdW90dHNXSHJnVUFZ dzRwUnlhWURTcjk0ZldnRGc5SStKUDlyZUxWMEwreS9Lek5KRjUzbmJ2dTU1eGoycnVxOEM4TTNW dFkvRkVYTjNNa0VDWGMrNlNSdG9IMzY5a1BpM3c0UCtZNVlmOEFmOWFBT2I4US9FZDlDOFVOb3k2 WWt3Vm94NXBtMi9leDJ4NzEzWjRPSzhEOGEzdHRxSHhGYTVzNTQ1NFdrZzJ5UnRrSDd1YTk3Yjd4 b0FTdk4vamIvd0FpbFpmOWZRL25YbzllY2ZHei9rVXJML3I2SDg2QVBhTEVmNkhiZjljay93RFFS VXQ0Mnl6a1B0aW83SC9qeXQvK3VTZitnaW02bTJMUUFkMkZBR1VPS0NhYURRVFFBcE5jZDQzOGNI d2ZMWm9MQVhYMmhXYkpsMmJkdVBZK3RkZm12SWZqVnpkYVAvMXpsL210Q0E5UDBiVVA3VzBXeTFF eCtWOXBoV1habk8zUGJOWENlS3hmQi9IZzNSLyt2U1ArVmJHYUFDdk1makgvQUt6d3ovMS9KLzZF YTlOSnJ6TDR4LzZ6d3ovMS9wLzZFYUFQY2xIelV5L2JaWnY3OFZJdjN2d3FycWpZZ1JmVnFBTThV ak5oU2ZRWnBBYWE1L2RzUFkwQWNMNFYrSlAvQUFrL2lIK3l2N0wrei9JN2VaNTI3N3Z0aXQ3eFg0 b3MvQ21rRzh1ZjNrem5iQkFHd1pHL3dIYzE0djhBRDdWTFBSZkYwMm9YMG5sMjhOdk1XUGNuc0I3 bXRHd3ROUStLbmpDVzd1M01PblFZM0tyZjZ1UCtGRi8yamprL1gycGdlaitEZkZlb2VMSTVidDlK U3pzVStWWmpLV01qZHdCZ2NEMXJxVFVOcmEyOWphUld0ckVrTUVLaEVST0FCVXBwQUlhOHgrSmYv SS9lRGY4QXI2VC9BTkNGZW0xNWw4U3YrUjk4R2Y4QVgwbi9BS0VLQVBjUVAzamZXb2RRYkZxUi9l WUNwaC9yRyt0Vk5VYkN4TDc1b0FwZzBacG9QRkptZ0RnZkV2eEwvd0NFZjhVTm9vMHJ6OEdNZWI1 MjM3d0hiSHZYZXR4WGdmeEc1K0tFbis5Yi93QWxyM3BqeWFBQTAwMFpwQ2FBRUpyekh4Yi9BTWx6 OEgvNzM5SzlOcnpMeFoveVhMd2YvdmYwb0E5dVFmTWFoMUU0Z1JmVmhVMGYzalZUVW0vZVJMOVRR QlhIU3M3WGRhdFBEK2pYT3AzcllpaFg3bzZ1MzhLajZtcjRQdlhqK3ZYTTN4TjhjUmFIWXlNTkUw OXQwOHE5R3h3emYreXIrSm9BWnBkLzhUL0Uxb2RVMDY2aWhzNXBHOHRXOHRBQm5vdVZ5UU9tZmFy bjltZkZzLzhBTVR0eC93QnRJLzhBNG10djRnejY5b0doV0UzaGxFaHNiRmdabGpHU3Fyd29JL3Vl dFo4L3hmMDMvaEZoZVF4ZjhUZHZrK3lIN3F0ajd4UDkzOWUxQUZSdEorTEFVazZ2YmdBWi93QmFu L3hOYVh3cjEzVmRkc05UZlZieDdwNFoxVkN3QTJqYWM5QlZ6NGUzSGlPNjhPM0Yzcjc3bG5MUzJ4 Y1lrMmtFbkk3TDZWaC9CZjhBNUJ1c2Y5ZktmK2dtZ0QwNnZHZmlWL3lWYXkvNjhtL3JYc3VhOGEr SlhQeFZzdjhBcnliK3RBRUNmY0ZZSGliL0FKQmsvd0R1L3dCYTMwKzRLd3ZFYTd0UG1YMi9yVklS NTJ5NU5QUlBtSEZXamFudlRsZzJqTmFLQWgwZkRDcklhcXZUbWxXYkhXdEV4RnJ0VVRDby90SXBw dVZORndIRVZHZXRPODFXNEZJZXRJQ0ZqZzFHeHFVb1dOSDJjbW9zTXBzS1lGelYzN0thUVd1RG50 VThvRWR1TVBWNkE0elVQbGhlbEp2MlZTMERjdmJzaW10MHF0OXBHS1EzSys5WHpDc1NNS2liaWcz Q0drOHhXSEZJWXhxalkxSXd5S1o1TE5VV0FnYm1vaUt1ZlpteFRmc3hxWEZqS3dYak5Xb2hoUlNy YjQ2OUtkamJ4UWxZQzJwK1duazhWUldiYWNIcFRqY2dWb3BDc1RPTTFFVnBwdVZJcFBQUTByZ05Z WXBqR3BHSVBUcFVUZ2tqRlQxR1JzYWpibXJIMmRxUHN4SXFiREsxT1Q3NHFYN09SVGhFRlhORmhD L3hDcml2d0twZmpUbG14MXFrN0NMakdvV3FMN1NLUTNBcHVTQ3dyQ296eFR2TlZxWTFTTWF4NU5S azgwOHF6SGlnd3Q2MGdMQ21wa0JOUUwxcWVLclFpVFpVYnhqdlZoUlNTWVZmd05VMEl6V09CbjFx QS9XcHBCOGxRMWl5a0ZLdEozcDYwa01lQlVnNllwcWluVllpVlRVcTgxWFUxTkh4Vm9ST29wU3ZJ eFNwelVvRldrSW96RGI3VldtSkFHS3VYWGJpcU0vUVZuSXBFUmFsV21kL2FucFdZRXFqbXBGR0NL WXRTcUt0Q0ZxWkdOUTk2a1UweEU2bXBRS2dTckNkSzBRQ012dFZhVUFTY1ZkN1ZUbi9BTlorRkRB cHpFaHNkcWl5YzA2NC93QllmcFVRNjFnMlVUTDFxVlJVSzFZVVZTRXh5akZTTDFwcWluRHJWb1JN cHFWZmFxNjFPblNyUUR3T0thVjRPYWtBb2JnVlZoRkYrQWFxTStmclZ1WGxXck9QQnhXRW1VaVVO elVpMUNsV0l4eFFoajFXcmxnTVgxdi9BTmRWL25WZFJWcXgvd0NQKzMvNjZyL01WWko3N29ZLzBD TC9BSEJXVDQ2NXNyUC9BSzZ0L3dDZzFxNkgvd0FnK0gvY0g4cXlmSFgvQUI1V2YvWFZ2L1Fhd0tM L0FNRVArUmU4UWY4QVlXYi9BTkJXdlNxODErQ1AvSXZlSVA4QXNMTi82Q3RlazlxUXhhOGkrTjJz NGowN1JJMzY1dXBnUCsrVS93RFpxOWNGZUV5NmJlK05QaXlaTHF4dVYwNXJuQmFTSmxYeVkrMmZm SDYwQWJQaHI0aitGZEY4STJ1aVRXMSs0V0VwUHRpWERzMmQvd0RGN211VitHV3N4YUw0OWhSWkdG bGVGclhMOGNFL0lUK0lINTE3UWZBdmhVNS80cCt3L3dDL2RlVWZFL3drZEY4UVdsM29OZzhWdE5F R0NXMGJNSTVGUHQwenhRQjd6UWF6ZEIxRnRYMEd5djNSNDVKb1ZaMFliU3JmeERIMXpXaFFCbDNx NWlRLzNaU0tsMWtmOFV6ZC93RFhLaTZYTWIrMG9OUDFzWThOM1kvNlltZ0RnUGdmL3dBaVpxSC9B R0VwUDVDdlNhODIrQi8vQUNKZW9mOEFZVGsva0s5Sm9BV3FtcWFUWWEzWVBZNmpiUjNGdS9KUit4 OVFlb1AwcTNYbW54RzB2eGdkYXROYjBHYVNTQzFUQ1EyMzM0Mi9pSlgrSUgvSW9BcGExOEVyZVRl K2k2bThSN1EzUTNMOU53NS9NVmovQUErOFFhejRaOFpKNFgxUjVHZ2tsTnUwTHR1OG1Uc3luMFA5 YWtqK0xQaTZCUHM4MmpRUGNkTnh0NUZPZmRRYXVlQlBDV3VhdjR1LzRTenhGQzhHMlF6SXNpN1ds a0k0TzNzb29BOWl6U0hwaWlnMEFaRjZQK1BjK2pzS2I0dEgvRkdYdi9YS3JGeXVZMC8yWnFoOFhq L2lqcjcvQUs1VUFjbjhFLzhBa21GcC93QmZNMy9vVmVnMTUvOEFCUDhBNUpmYWY5Zk0zL29WZWdV QUkvOEFxMi8zVFhnWHdrLzVLTXYvQUZ4bnIzMXgrN2IvQUhUWHpWb00vaUR3dnJyYW5ZNlRPOHlp UkFKcldRcmh2cFFCOU1EazE4N2VLWkYxL3dDTGNxV1A3d1NYc1VDRmUrM2FwUDZHdGU4OFovRVB4 QkExamE2Wk5iK1lOckcydEhWaVA5NXVsZE44T1BoeE5vRndOWTFuYjl2Q2tRd0tkd2h6MVluKzkv S2dEMDAvZU5OYjdwRkZCb0F5THRmMzlxM3NSK3RaL3dBUnhqNGYzLzhBMXliL0FOQk5hbHd1NzdP ZlNSaFdiOFNCL3dBVy93QlEvd0N1Ui84QVFUUUJTK0ZIL0pMOUYvM0gvd0RRelhZMXgzd3Avd0NT WDZKL3VQOEEraG11eG9BSzhGK012L0k4Si8xNXgvemF2ZXVLOE4rTDJuWDExNDBTUzJzN2laUHNj WTNSeE13emx1NEZBR2hGOEVHa2hqbEd2QWIxRGY4QUhyNmpQOTZ2UXZCWGhjK0VORE9tdGRpNnpN MHZtQk5uVURqR1Q2VnQyb0lzNE04RVJLUC9BQjBWTm1nQmFaSnlqYzlxV2tiN3BvQXlMdGY5T3Rt OVVGWVB4ZUdQaHplZjdocm83aE16V2grby9XdWYrTUF4OE9iei9kb0EwUGgvL3dBazc4UC9BUFhr bGRIWE8rQVArU2QrSC84QXJ5U3Vpb0E1M3g1YXZlZUJOWmhpQkwvWnl3QTc3U0cvcFhudndPdm9V dTlXc0dZQ1dWSTVrSDk0TGtIL0FOQ0ZleGxReWxXQVpUd1FlaEZlRmVKL0FtdStFZGMvdGZ3NHM4 bG9ybVNKN2NicElNL3dzdmRmMDlhQVBSL0huaFRVL0ZNZGt1bWFtTEUyNWN1U3pqZm5HUHUvU3ZK SVlkVzBENGpXV2ozT3EzRTdRMzBLdVZtZmEyU3A2RStoclpoK0tIamU1UVdzR213eVhKK1hlbG01 ZlAwemlzeFBEL2lXMThiNk5mYTNiVHlYTjNjeFhFajdTNVViOGZNUndPblRzS0FQb1k5VFVjdk1U ZlNuSHFjVWpmY09QU2dER3VsLzRtc1RmM2tXdVA4QWpnTWVBaC92ci82RXRkcmNKbTl0VDZwajlh NDM0NkRIZ1A4QTRHdi9BS0V0QUhmK0V2OEFrVmRJei96NXhmOEFvSXJSMVU0dFVIcTFaM2hQand0 cEgvWGxGLzZDS3U2dVQ1Y1krdEFHV0RTcWZtSDFwZ29CK2NjOTZBUG5uVE5JaDEveC9KcGx4SkpI RlBkVEJuanhrWUxIdjlLOUIvNFU3b3YvQUVFZFEvOEFIUDhBNG11VjhKMk41SDhVVW1lMXVGaSsx VG5lMFRBZnhkNjl0b0ErZXZFR2l3ZUh2R3E2YmJTeVNSUlN3a1BKalBPMDlxK2htKzhhOFM4ZGFm ZXpmRWQ1b2JPNGtpM3dmT2tURWRGNzRyMnRqOHhvQUs4NCtOZi9BQ0tWbC8xOUQrbGVqWnhYblB4 ci93Q1JSc3Yrdm9VQWUwV0ovd0JEdHY4QXJrbi9BS0NLaTFkdjNjUTk4MUpZbi9SYmIvcmluL29J cXZxN2ZORVBZbWdET0JvelNDa3pRQXVhOGorTkgvSDFwSC9YT1grYTE2ZnFtcFcya2FiUHFGNHhX M2hYYzVVWk9NNDRIZXZGZmlQNG5zZkZHbzJLNlY1c3NjRWJMdlpDdTVtSTRBL0NnRDF2d2dUL0FN SWJvLzhBMTZSL3lyWXJPOFAyY21uK0hkTnM1dUpZYlpFY2VoMjgxb1VBTFhtWHhpLzFuaG4vQUsv MC93RFFqWHBsZVovR0w3M2huL3IvQUUvblFCN21uM3FvNnMzTVMvVTFjVC9XZmxXZnFwL2ZvUFJh QUtZTk5rUDd0LzhBZFA4QUtqTk1rUDd0djkwL3lvQSthZEIwRzQ4UytJWTlNdG1WR2tkbVoyNktn KzgxYnRsUGUvRFR4NDhVKzU3Y0haTGpnVFFOMGJIcU92MUJGWGZoZlpYbHY0Njh5YTBuaWo4bWI1 M2laUm42bXUzK0pmaGYrMzlEKzJXc2U2L3NnV1FBY3lSL3hML1VVd096aW1pdUlJNTRIRWtVaWgw ZFR3eW5vYWRtdk52aFhxOStscStoYWpiWE1ZakcrMWtsaVpSdDdwa2o4UitOZWo1cEFCTmVhZkVy L2tmUEJuL1gwbi9vUXIwcXZOUGlUL3lQbmd6L0FLK2svd0RRaFFnUGNWLzFyZldxT3FOKytqSG90 WEZQNzUvcldkcVIvd0JLSHN0QUZmdFJtbTU0cENhQVBCdmlKL3lWQi84QWZ0LzVMWHZUSDVqWGcv eEd0TDV2aUZjM050WjNFb1R5V1ZsaVpnU0ZIcFdrZmlWNDBQOEF6Qkl2L0FPWC9HZ0QyTTBocm4v QnVyNmpyZmg5YjNWYmNXOTBaWFV4ckdVK1VkRGcxdlpvQVd2TS9Gbi9BQ1hMd2QvdmYwcjBxdk5Q Rm4vSmN2QjMrOS9TZ0QyNlA3NSt0VWRRYk4wUFphdVJINTIrdFo5NmMzai9BRUZBRk8rdEV2OEFU N2l6ZVNTTlo0MmpMeG5ETGtZeUs4citIZDIzZzN4VmYrRXRWalNPUzRrRFFYQUdQTVlENVJuMFpl bnZYck9lSzRiNGwrRlgxN1NWMUt3VWpWTEViNHluV1JPcFg2anFLQU5IeHY0eXRmQ1dtY29zOTlj S3l3UU4wUHF6ZjdQODY4Wi80UlBYN2JSby9GUnNvL0pFdm5lVXlad3VjN2luOXpQNmUxZDFaK09m Q2ZpRFJOUC9BT0VyQS90QzBjTVZNVE1HY2Z4Y0RvM0dRYTZGdmlmNFJJS20vY2dqR1BzNzR4K1ZN QzM0VDhYV3ZpM1JaSjQwOG02aFhiY1FBY0tjZFZQOTAxeXZ3WC81Qm1zZjlmS2YrZ21ybW5lTnZB ZWkyVTl0cGtyUVJ6TzBqS3R1L0x0K0g1ZWxVZmd1YzZWcXg2ZjZRbi9vSnBBZW41NXJ4ejRrL3dE SlZiTC9BSzhXL3JYc09hOGUrSklQL0MxYkhIL1BpZjVtbWdLNmZjRll1dmY4ZWN2MHJhVC9BRlly RjE3L0FJOUpQcFZMY1J5TFZHVHhUMk5STlc3SkdIcFViRDBxWEZNWVZJRmRzMUV4eFV6MVhhczJV dGh5dmlyY1p5bFo0emtWZWdHSThVUllNdXhyOHRQMjhVUmtGUlRqVzZJSWowcU5qVWoxQTFTeGpX T2FpY1ZJVFREVWpJV0hGUk1jQ3AzcUIrS2hqR1pwNk1jMUNUVGs1WWZXcFRBMEVIemdWYUM4MVho T0pCeFYwQVlyZU94SkV3eFVUZEttYW9ITkRBWVd4VVI1cHpHbWRxaGpJMkZSTng2MU93cUZxaGpJ aWFBYUQxcEttNEU4VGJnYXRRS0NEa1pxbkIzclF0T2pmV3RJQ0pBZ3hUV0dLbklxQ1N0R0loWTFF eHlEVDJxSW1zMnhpR295T0trUFNtRVZMR1JHaytwcHpVMnBHRlNxY3JVVlBUcFFnTGNLamFEVTRR RVV5M0EyTDlhbXdlMzg2MlNKS0tWWWpxQkJ6VTZIRlNnTEMwMmI3djRVb05OZDhEODZ0N0NNNS91 bW9hbWY3bFE0ckJsSVR2VWkwekhOUFUwaGt3cDFNRk9xeERoMXFaTzFSTFV5VlNFV0VxVmFoVTFK dXdLMFFpdGRkcW96OXF2WExaQTRxak9PbFpUS0lLZWxNd2MwOVJpb1FFNjFLS2hVMUl0V0pqdTlQ V21WSW9xa0lsU3JDVlhUZzFPdFdnSmUxVXAvOWIrRlc5MktxVGtHVE5EMkFvWEgzengycUVkYW51 Qm1RL1FWRUY1ckZsRWlWWVdvRjROVEthYUVTaW5EclRGTlBBNXF4RDE2MU9uU29WcVpPS3RBU2lo K2xJRFFXNHFoRktUb2F6bSs5V2pMeXIvU3FCV3NKbENwVmxLckwxcWRPS1NBc0xWcXgvNC83ZjhB NjZyL0FERlZGTldySC9qK3QvOEFycXY4eFdnajMzUXNIVDRlZjRCV1Q0Ni80OHJQSC9QVnYvUWF2 YUpGcWNtbm9iS0dLWUtBQ0pIMlZTOFJhYnIyb2lDRzQwMW9nckZrTVJFbTc5YXhMTGZ3UWNIUS9F U1orWmRVSng5VkgrRmVsL2pYaFdrYUg0MThKYWhlM0dpUnlmWnIwcTBzTTBPOE13NXp3ZU9wcmZI aUg0aGdjNlhHZiszZVQvNHFwQTlXcDI3UEZlVC9BUENRL0VML0FLQk1mL2ZpVC9HbC93Q0VpK0lQ L1FKai93REFlVC9HZ0QxYWxWaXZRNHJ5ai9oSXZpRi8wQ1UvOEI1UDhhWC9BSVNQNGcvOUFoUCsv RW4rTkFIcTJjMFY1U1BFbnhBSFhSMS84QjVLZC93azNqL3ZveW4vQUxZU1VBZWxPdTd6UjdxYWJy NTJlSGJ6UEg3azE1cWZFZmowazdOR1VGdXY3aVExUzFtLytJK3Q2YkxZZlkvczhjbzJzMGRvMjdI MUpvQTEvZ2E2djRMMUVBOU5Ua3ovQU44aXZTcThFOEw2QjQvOEZ4elJhYkU3UVhEQjNpa3RpdzNB WXp3YzVycGhybnhHQTUwbU0vOEFidEovalFCNnJRT0s4ci90MzRpLzlBaFAvQWVUL0dsL3QzNGkv d0RRSFgvd0hrL3hvQTlVeWM1b1BOZVYvd0J2ZkVUL0FLQTYvd0RnUEovalMvMi84US8rZ012L0FJ RHlmNDBBZXBVdGVXRHhCOFErK2lnLzl1OG4rTk9IaUw0Z2Q5RUgvZ1BKUUI2TTY3bGNla2ltcW5q TWhQQitvWk9BSWE0SCszdkg1enMwVUFrNUorenlHczd4Qko4U1BFbW1QcDBsazBFRXZEbUswYkpI cGttZ0RvL2drUTN3dnRRRHlMcVlIL3ZxdlFhOEs4TWFKOFEvQnRtOW5ZVzd5V3NqK1o1VWxzV0N0 MEpHRHgwcm9oclB4STc2T3AvN2RwUDhhQVBVNlhjZld2TFA3YStJL3dEMEJsLzhCcFA4YVA3YStJ NC81Z3EvK0E4bitOQUhxbWVLYjFyeTMrMi9pTi8wQlIvNER5ZjQwdjhBYm54RkgvTUVIL2dQSi9q UUI2alJYbC85dmZFUWRkRUgvZ1BKUi93a0h4Q0hYUWgvNER5VUFlaXVtNEw3UzFqZkV4bFR3QnFS Si81WkgrUnJrZjdjK0lKNFRROXZPNy9qM2tySjhUVy94SDhXNmNkTnVMSjRiWi92TEhhc0MzNGsw QWR0OEoyRC9DN1JTcDZMSXAvNzdOZGxYaVBoclMvaVA0UjA4YWJhV3NrdG9ybDBqa3RtYmFUMXdR MWJnMWY0bEFmOGdaZi9BQUdrL3dBYUFQVXFVTmp2WGx2OXMvRW4vb0NqL3dBQnBQOEFHaisyZmlR T3VpRC9BTUJwUDhhQVBVYUs4djhBN2ErSkgvUUVIL2dQSi9qU2YyMzhSdjhBb0JqL0FNQjVQOGFB UFVhUStsZVlmMjc4UlIxMEwveVhrcGY3ZitJUTY2RG4vdDNrb0E5Q1pOelFIKzdJd3JtUGpJd1g0 ZDN1VDFHS3dEcmZ4Q2JhSTlDSXdkMy9BQjd5ZGF4ZkZXbS9FYnhwWnJZWGxsSkRiQnR4amp0bVhj ZmNrMEFlbGZENWcvdzU4UEZUeDlpUVYwZGVMZUg3UDRsK0dOTWoweUMwZWUxaHlJMWx0V0pVRTV3 Q0c2VnJqVi9pWC8wQkYvOEFBYVQvQU9Lb0E5Uzk2QWNWNWQvYkh4Sy82QWcvOEJwUDhhUDdhK0pJ L3dDWUdQOEF3SGsveG9BOVJ6UzV3T00xNWIvYlh4SS82QVgvQUpMU2Y0MG45dWZFY2Y4QU1DLzhs cFA4YUFQVWZ4cEQwcnpEKzN2aUtQOEFtQS8rUzhsSi93QUpEOFErL2g4LytBOGxBSG9oVGRQYW4w M0Q5YTRiNDhNRjhDZ1o1TXFqL3dBZUZVVHJueEVabDh2UUNOdlQvUnBLNS94WG92eEc4Y1J4Mjkv WVN4d1JuY3NjZHNWQlBxU1RRQjdYNFNZUDRWMFpsT1ZObEZ6L0FNQkZXOVlQTVE5alhqZWhTL0Uz dzVwa0duTHBzbHpEYnBzaU1scytWVWRCa0htdENYeEg4UkpTUE44UEZpQmovajNrb0E5QUZHYTg2 L3R6NGdrY2VIVC9BT0E4bEovYlB4RVAvTXVuL3dBQjVLQVBSaXhJeG1tNXJ6disxL2lMamp3NGYv QWVUL0drL3RiNGpmOEFRdW4vQU1CNVA4YUFQUlF4SGVrcnpyKzFmaVAvQU5DNS93Q1M4bitOSDlx ZkVqSC9BQ0xuL2t2Si9qUUI2TC9Pdk4vamRJcWVFN0FFOG01RktkVStKUjZlSGNmOXU4bitOYzE0 bDhNL0VUeGw1S1grbXpMRkJrcEhIYkZGeWUvSjVvQStpdFBiZGFXcEhRd1JrZjhBZklxdnE1L2ZJ UDhBWnJ4N1N0VitLT2pXRU5tK2tTM0t3SUkwZDdaODdRT000UE5XWmZGSHhGbGJNbmhweTNUUDJl U2dEMGZOSGF2TlArRWgrSWg2ZUdXLzhCNUtQN2YrSTNid3kzL2dQSlFCNkZmV05ycWRuSlozc0t6 MjhuRHh0ME5aZW5lRC9EMmszUXViUFNvSTUxNVdRNVlyOU54T0s1RCszZmlRZitaWWIvd0hrby90 djRrbi9tV0cvd0RBZVQvR2dEMHFrcnpYKzIvaVQvMExCLzhBQWVUL0FCb090ZkVydDRZUC9nUEov alFCNlYrTmVZL0dXUlVmdzBDZWw0cmYrUFU1dFkrSmhISGhvai90MmsveHJsZkVmaGI0amVMN2lL ZlVOTHVWK3pqRWFKQnNDKy9KelFCOU14bjk0Y0hzUDVWbjZvZjlMeDZLSzhnc1BFSHhVMCsxamht ME9XNWFOUXZtdGJPQ1FQWEJ4VXIrTFBpTkkyNS9DMGhiMSt6eVVBZW0wWnJ5L3dENFNiNGlucDRX Zi93SGtvLzRTTDRrSHA0WGIvd0hrb0E5UUxFakdlS1puQnJ6RStJZmlWLzBLemYrQThsSDl2OEF4 TC82Rlp2L0FBSGtvQTlPTEU5NlN2TXY3ZStKZi9RcnQvNER5ZjQwZjI3OFRQOEFvVnovQU9BOG4r TkFIcGxlWS9FeVZVOGUrRFF4SEZ5aFAvZmEwamEzOFRpUGw4TWtmOXUwaC9yWEthNzRVK0kzaWZV NHRVdmRNdTFtdDhlVUk0Tmdqd2NqQUpvQStuVVAra1A5YXpkUU9ieC93cnlPMjhUZkZTMWlWWnZE OGt6Z1lNaHRwQVc5emcwcitMdmlLN0ZtOExTRmoxUDJlU2dEMUxQRklUWGx2L0NVL0Vjbmp3cy8v Z1BKU2Y4QUNTL0VvOVBDci84QWdQSlFCNm51SUhXazNuMVA1MTViL3dBSkg4UzhaLzRSWnY4QXdI a28vd0NFaCtKWi93Q1pXYi93R2tvQTlRTFo2NXBLOHcvdC93Q0pmL1FyTi80RHlmNDBuOXYvQUJN LzZGYy8rQThuK05BSHAvNDE1bDR0bFZmamo0UXljYldYUHRtbzIxMzRua2ZMNFpLbjErelNmNDF5 ZXArRlBpUHJHdlI2L2NhZmVMZXdzcGlaSU51emIwd3VhQVBwMkgvV3Y5YXpiczV1NVByL0FFcnlh SHhWOFVyWkI1dmgyU1IvNG4relNEZCtHYUQ0ditJck1UL3dpc21TZVQ5bmtvQTlVcE00cnlyL0FJ U3I0am5wNFdmL0FNQjVLQjRuK0pSLzVsWnYvQWVTZ0R0cGZCWGhpYVY1WDBTekx1eFpqczZrMHov aENQQzQ2YUZaL3dEZkZjWi93a3Z4TFA4QXpLemYrQThsSi93a2Z4TXgvd0Fpc2Y4QXdIa29BN1Qv QUlRbnd3UCtZSFpmOSs2ME5PMGpUdEhqa1RUYktHMVdRN25XSmNiajYxNTUvd0FKRjhUTWY4aXNm L0FkL3dER20vOEFDUS9FMy9vVmovMzRrL3hvQTlTcnh6NGpPRDhXTFJRZVZzRG45YTBHMTc0b0ZU czhOYlQ2L1puUDlhd0kvQ2ZqZlVOZm0xN1Y5SnZacm1SZHFoSXdvVWRNYmM5S0VCYVQvVmlzWFh2 K1BTWDZWMDlyb091eXM2TnBNc1pSdHJlYktxWU9NOTZ6UEZla3RZYVRLMDZ0SE9OdVUzaHhnbjFB cWx1STg3YW96VWpjMHdqaXVoa2pLWTFQcU5qVXNDR1RwVlpxc3VjbXE3Q3MyTVlPdFhvZnVWU0M1 cTdDdTJPaUMxQXZ4ZmRwNXBrYi9LS2VXRmJvbXhFOVFOMHFaK2FpWVZMR1JVaHB4Rk1hcFlFYjFB NHFaalVMVkRHaUUwNkw3dyt0SVJUbzErZGZyVUROQ0wvV0Nydys3VktJNGtGVzkyYTZJN0VpTjBx dTlUdFVEaWhnUU4xcE8xT1lVMm9ZeGpkS2lhcEdxTnVsUXhrSjYwbEszV2tGUU1tZzcxZXRlamZX cU1JNjFldFd3ckQzclNHeExMUnFDVHBVcE9haGV0UkZkdmVvelVyVkdhell4dmFtdFRqN1V4cWta RzFOcFRTVkFCVWlmZHFPcEUrN1RReTliL2RIMXFlb0lHeEdCVXVhMlJKVUJBcDRrQTcxUnlmVTBa UHFhenVPeG9DWVk2MUc4M3B6Vk1FMDRENXFPWUxFaEdhak1aSEZURHJVbzVvc0lwK1dld05LRUlO WDFVSHRUL0xVOXFmSU16d0NPMVNMVnBvUVFhZ1pkckVVY3RnSERqclVnZFIzRlVua3prVXpjYzBy MkN4cGlaUjNwVE1NZGF6QVQ2MDhaOWFybUN4WmVYZVFLalpONCtsSWd4M3FXUGlsdUlyR0k5Y1VD TnM5S3ZnQTlxZXFnOXFmS0Z6UENIUFNucVR1cS81UXh3S2lraVhhV3gwcDJBaEZUREE5cWhxRnBT YVd3RjhPQjNwNGxBNzFsQnlhY0diTkhNRmpUYVVldFFNKzlzMVhHVDNxUktxOXdHdkhrN3FpOG81 NlZkUThZcVFBSHFLWExjQ2dJeU8xUENrSHBXZ0ZCN1V2bDQ3ZDZhZ0lvcWNIbXBsNjRwenhnRE9L aWQ5Z3pUMkFuQlVkNmNKQUQxRlpyU2s5NkE1TkpUR2FvbEdPdE5hVUFWUkRHbmpKeDFwOHdpVmh1 cUJvVDZWWUhGU0E1b3RjWlFXSnZTcEJHUjJxOG9IcFQ5bzlLYWdJb0FNTzFYTlAvd0NQMjMvNjZy L09uR1BJcGJSY2FqYmovcHF2ODZHcklFZlJYZzMvQUpCZjRqK1ZhMnZFalRvY1pINzBkUG9hNURS ZFIxRFQ5UFg3SlptNVZnQ1J4NmY3d3FqNGk4YjZpWW9iZWZTcnF5QWJkdThqZnY0K3RjNVowUWtj Znh0LzMxUytZLzhBZmY4QTc2TmVYZjhBQ3c5Um4xRjdMVGJDNnZKRTY3WWdENzhZNHE5L3drM2kv d0Q2RnU5Lzc1V2tCNkY1ai84QVBSdisralI1ai84QVBSdisralhubi9DVGVMditoY3ZmKytWcFAr RW84Vy85QzdlLzk4clFCNko1ai8zMi93QytxWHpIei9ySC93QytxODVQaW54WVArWmR2UDhBdmxh UStLL0ZZLzVsKzcvNzVXZ0QwZnpKUCtlai93RGZSbzgyVC9ubzMvZlJyemovQUlTM3hWLzBMOTMr UzBmOEpYNHJQL012WG4vZkswQWVqK2JKL3dBOUgvNzZvODJUL25vLy9mUnJ6bi9oS3ZGaC93Q1pl dlArK1ZxQzY4YitJN0tNeVhPaDNjYURxektPUDBvQTlOODJUL25vL3dEMzBhUE5rLzU2UC8zMVhs Tmo4UjlXMU9VeDJHbDNGdzZqSkVhaHNmWGl0TC9oSi9GeC93Q1pjdlArK1ZvQTlFODJUL25vL3dE MzBhUE5rL3Z2L3dCOUd2T3o0bjhXL3dEUXQzdi9BSHl0Si93bFBpMy9BS0Z5OC83NVdnRDBYelpQ K2VqL0FQZlJwZk9rL3dDZWovOEFmUnJ6ai9oS3ZGZi9BRUx0NS8zeXRKL3dsbmlyL29YN3Yvdmxh QVBSL05rLzU2UC9BTjlHbDgyVC9uby8vZlJyemNlTGZGSi81bCs3L0phUCtFczhWLzhBUXZYbi9m SzBBZWtlYkovejBmOEE3Nk5KNXNuL0FEMWYvdm8xNTBQRlhpdy84eTdlZjk4clZXNzhkK0lOUGo4 eTcwUzZoUWRXWkJqK1ZBSHFIbXlmODlYL0FPK2pTZWJKL3dBOUgvNzZOZVYySHhGMW5WV1lhZnBG emNiZnZlV29iSDZWb2Y4QUNUK0x2K2hidlA4QXZsYUFQUmZOay81NlAvMzBhVHpaUCtlai93RGZS cnp2L2hLUEZvNitHN3ovQUw1RkgvQ1UrTGYraGN2UCsrUlFCNkw1c24vUFIvOEF2bzBlZEovejBm OEE3Nk5lYy84QUNWK0t4L3pMdDMvM3l0Ti80UzN4VVA4QW1YcnY4bG9BOUk4Nlgvbm8vd0QzMGFQ T2wvNTZQLzMwYTgzSGk3eFNmK1pldXZ5V2wvNFN6eFgvQU5DN2QvOEFmSW9BOUg4NlgvbnEvd0Qz MGFQT2wvNTZ2LzMwYTg1LzRTcnhaLzBMdDUvM3lLcDN2ai9YZE9UZmVhTmN3SjZ1b3gvS2dEMUx6 WlArZWovOTlHanpaUDhBbm8vL0FIMGE4dHNQaURybXFxV3NOR3ViaFY0SlJRUVB4eFY3L2hLUEYz L1F0M24vQUh5S0FQUlBPay81NnY4QTk5R2w4NlQvQUo2di93QjlHdk9qNG84V2ovbVc3ei92a1Vu L0FBbFhpMGY4eTNlZjk4aWdEMGJ6cGY4QW5vLy9BSDBhVHpaUCtlai9BUGZScnpuL0FJU3p4WC8w THQzK1FwcDhXK0t2K2hldXZ5RkFIcEhteWY4QVBSLysralI1c3Y4QXowZi9BTDZOZWNmOEpkNHAv d0NoZXV2eUZBOFcrS3owOE8zZjVDZ0QwZnpwZitlai93RGZSbzgyVC9uby93RDMwYTg1L3dDRXI4 V2Y5QzVlZjk4aXFONzhROWIwd0JyN1I3aUFIdTZnRCtWQUhxZm15ZjhBUFIvKytqUytiSi96MGY4 QTc2TmVYV1BqM1g5VGo4MncwUzVuanpqZWlnajg2dS84SlA0dS93Q2hidlArK1JRQjZINXNuL1BS L3dEdm8wZWRKL3oxZi92czE1MGZGSGk0Zjh5M2VmOEFmSW8vNFNyeGIvMExkNS8zeUtBUFJmTmsv d0Nlai84QWZScFBOay81NnY4QTk5R3ZPajRyOFdmOUM1ZC85OGltbnhiNHJIL012WFA1Q2dEMGN5 eS84OVgvQU8ralNlZEovd0E5SC83Nk5lY2Y4SmI0cS82RjY2L0lVdjhBd2xYaXovb1hicjhoUUI2 TjUwby81YXYvQU45R2s4NlhQK3RmL3ZvMTUzL3dsWGkzL29YTHIvdmtWbjN2eEYxblRXQXZ0Sm5n ejAzcUJuOUtBUFUvT2wvNTZ2OEE5OUdqenBmK2VyLzk5R3ZNYlB4ejRpMUdJVFdlaVhNMFo2T3Fj R3JYL0NUK0x2OEFvWEx2L3ZrVUFlaCtkTC96MWsvNzZOSG5TLzhBUFIvKytqWG5YL0NVZUxmK2hk dXYrK1JTSHhUNHRIL012WEkvNENLQVBSUE9sLzU2UC8zMGFQTmwvd0Nlai84QWZScnpvZUt2Rm4v UXYzSC9BSHlLWC9oSi9GcC81bDY1L3dDK1JRQjZINTB2L1BTVC92bzBubXlmODlIL0FPK2pYbnYv QUFrdmk4OVBEdDEvM3lLQjRqOFlIL21YTHIvdmdVQWVoZWRMM2tmL0FMNk5KNXN2L1BWLysralhu NThSZU1NZjhpNWRmOThpc3U5K0llczZiSUk3N1RKYmRqMEVpN2MwQWVwK2RML3oxay83N05KNTB2 OEF6MWYvQUw2TmViMnZqRHhQZlFyTmE2RmNTeHNNaGxUZzFQOEE4Skg0dy82RjY1SC9BQUVVQWVn K2RML3oxZjhBNzZOSjUwdi9BRDFmL3ZvMTU5L3drbmkvL29YcmovdmtVMCtKZkY0LzVnRndQK0FD Z0QwTHpwZitlci85OUdqelpQOEFuby8vQUgwYTg4SGlYeGNmK1lET2YrQWlsLzRTVHhoLzBMMC8v ZklvQTlDODJUL25vLzhBMzBhUE9rLzU2UDhBOTlHdlB2OEFoSXZHSjZlSHJqL3Zpai9oSVBHWC9R dTNIL2ZGQUhvSG5TLzg5SC83Nk5IblNmOEFQUi8rK2pYbjUxL3hualAvQUFqdHovM3hXWGQvRVRX ZFBsOG05MDVvSlA3c2k3VFFCNnA1c24vUFIvOEF2czBlZEwvejBmOEE3Nk5lYzIvaXJ4WGRSTEpC b053Nk1NZytYMXFYL2hJZkdRLzVsNjQvNzRvQTlDODJYL25vL3dEMzBhVHpaZjhBbnBKLzMyYTgr LzRTTHhqL0FOQy9QLzN4VFQ0azhZRC9BSmdFdy80QUtBUFEvTmsvNTZQL0FOOUdqelpQK2VqL0FQ ZlpyendlSmZHSC9RQW0vd0MrUlMvOEpINHgvd0NoZm4vNzVvQTlDODJUSCtzZi92bzBlYkovejBm L0FMNk5lZmp4RjR5UC9NdXovd0RmRkgvQ1FlTSszaDJmL3ZpZ0QwRHpaUDhBbm8vL0FIMGFYelpQ K2VqL0FQZlJyejQrSWZHYWpKOE8zR1A5eXNxNStJK3NXYzV0N3JUdkttL3VNdURRQjZ0NXNuOTkv d0R2cWw4MlQvbm8vd0QzMGE4NWg4VStMNTR3OFBoK2RsUE9mTHFUL2hJL0dmOEEwTHMvL2ZGQUhv UmxrLzU2UC8zMGFUelpQK2VqL3dEZlJyejMvaEpmR1gvUXZUZjk4VTArSmZHSS93Q1pmbEgvQUFD Z0QwVVN5ZjhBUFIvKytqUjVqOU43Zjk5R3ZPeDRuOFluL21YNVQvd0duZjhBQ1MrTXYraGRtLzc1 b0E5QzgyVCsrLzhBMzBhWHpIejk5djhBdm8xNTcvd2tualB0NGNtLzc0cFI0aThhZjlDM04vM3hR QjZGNWovODlIL00wdm1QL3dBOUcvNzZOZWVONGs4YUtNbnczUGovQUhLeVpmaVpyRUZ4OW1sMDda UG5CalpjSFAwb0E5WjN2L3owYi92bzBlWS85OS8rK2pYblVmaXJ4aEtvWlBEc3hVOUQ1ZE8vNFNi eG4vMExrMy9mRkFIb25tUC9BSDIvNzZvOHgvNzdmOTlHdk8vK0VvOFovd0RRdVMvOThVMCtLZkdZ L3dDWmVrLzc0b0E5SDh4Lzc3Zm5TK1kvOTl2KytxODRIaXJ4ai8wTDBoLzREVGg0bzhaLzlDM0wv d0I4MEFlaStZLzk5dnpwZk1mKyszNW12T3g0bjhhZjlDM0wvd0I4MGY4QUNUZU5mK2hhbS83NG9B OUU4eC83N2ZtYU43LzMyL092T204VWVORVhKOE5UWUgvVE9xMWg4UmRSdXJxUzBudERCY0oveXpF SmMrL0dSaWdEMld6L0FOUVQvdGRmd0ZjQjhTZitQRzQvM1UvOUNOTFkrT2RRRU96N0VTYy9mTnVS MjlOd3JFOFo2eC9hR2czQmwzaWM3ZjhBbG50QUFQMU5OYmdlZTdoaW1ua1ZRODFzOWFsU1VqM3Jm bXVSWWxQQXFMazFPdkpGVEtnRk8xd005bzJQYW1lVWNkSzFkZzlLWXlqMHBlekF6MWhQVEJxWlYy akZUbmlvajFwY3RnSHJLQU50U2VhTWRhcHVPYWlKSTcwK2F3eStaRjlhYVdIcldlWFlkNlFTbjFx ZVlMRjVoeFVMNW9qazNuRlRSeDdqVDNBcUZDZTFOTVo5SzBoRU1kS1VvQlE0QVpQbEhQUTFJa1hj OFZlSUdPbE1icFU4b1hJMU8wNXFaWlFlOVYycUU4ZHpUdllDK1pSNjAwdVBXczhzUU90TTNrZDZY T0JvRWc5S2liclZZU0VjMU9weXVhTDNBak9TY0FacHBVa2RLdkpDQnlQU3BQTFVEcFJ5M0M1bEdO dlNoWWlPMWFiS093cU04ZHFYSU1yS213VkxISjVaK3RJNXpVVDg0bzJBdWVhUFdrTXFudlZBNTlh WVdQclJ6Qll2TXltbU4wcXB1UHZUMGNrNDdVdWE0V0hucFVmSnFYdUtzTENCeUtkcmlLQlErbEpz YkhUaXRJeEtPMU1JR09sTGtHVVFoUFkwOEx0R0tuTlJ0MXpTc0E5SmRvMm1wQk1BT3RVMkhQZW01 SXA4d1dRbEZGSjNxQmoxRlNBYzB4YWVLcENZNFZJcHFNVThVeEluak9hc0tLcnhkUlZoYTFRRGl0 VUpmOVkySzBEOTJzK1Q3N1VwN0FpbTNVMG5mTkszM2pTVmdVUFdwbEZRcDBxWmF0Q1k4Q25MU0Rw U2pyVEVTcWFuanF1dldyQ1ZwRUNZTHhVY3d4RzMwcVZhanVQOVcvMHFuc0lwRWZMVkZqeWF2ZHFv dDFOWVRLUW9OVEpWZGV0VHBTU0FtVVZJT0tZb3AvZXRFSWNEaXBVUE5RanJVcWRhWWl3bFNBY0Nv MDZWSUswUUVVd3dsWjl5Y0lNZXRhRTMzS29Uaktpb21CVXp6VWkxRjNxUlB2VmlobGhCVXFyaW8x cVlWcWhDaW5nMHp2VGgxcWtCTXRTZ1ZFblNwVjYxYUFkaW9jZjZSSDlSVS9hcTUvNCtFK3RLV3dJ OTYwQS82QkQvQUxnck44Yy84ZWRwL3dCZFcvbFdob0gvQUI1UmY3Z3JQOGNmOGVWbi93QmRXLzhB UWE1aWliNEgyTUsyZmlXK01TbVo5UUVXOGpuYUJuSC9BSTlYcWUxZjdvL0t2Ti9nbC95TC9pRC9B TENyZitnTFhwSXFSaHNUdWkwdmx4bitCZnlvcDFBRFJERWYrV2EvbFMvWjRpUDlXdFBGS0tBSTBS RGxUR200ZjdORFJnZEVUL3Ztbk9DUG5YcXRUZ0xJZ1lkRFFCbk9XWHN2NVZsYTlFbDFvTjlITkdq TDVMSGxSVzdMRldUckNZMGErLzY0TlFCd0h3SnNMZUh3bnFkeUlrODJUVVdUY1J6dFZSZ2ZyWHFK MktNc0VBN2s5Szg0K0IvL0FDSkY5LzJFNWY1TFhiNjlwS2E5b1Y1cFR6TkNsekhzTWlESlhuMG9B djhBbVczOStIL3ZvVTRmWjI2ZVdmeEZlVkg0SFdJNU92M2Fqcmt3cngrdGNiNEYwWVhmeE90NGRM bmtuc3JHNE14dUhHM2RHdmZBOVQwK3RBSDBTSW9qL3dBczFvTnZFZjhBbG12NVUrbG9BYkdrYlpI bElHSCt6U05HRjZJdi9mTkt4S01ISGJxS3M0VjBCSFEwQVp6bGw2QmZ5cm4vQUJqQWwzNFMxSkpv MFlDTEl5dlN1b21pcm4vRlM3ZkN1cGNmOHNUUUJ5dndPc29JZmhyRGNDRlBObXU1Uzc0NU9EdC9w WG93QS91citWY0I4Rk9maFpaZjlmTTMvb2RYUGlocjE5NGY4SStkcHptS2U0bVdEemw2eHFRU1NQ ZmlnRHN5SXcyMWdnYjBOT01hWjVSZnlyeFR3MThNazhUK0dJdGJ1ZGZ1aGVYQVprd2R5b1FTUG1K T2UzNFZvL0J6eEhxbDNmWHVpWHR3OTFid1JlYkZKSTI0eGtOdHh1OURtZ0QxbnlvLytlYTBwZ2k3 UnBuNlU0ZEtkUUFrY2Nici9xa0REcjh0SThXT2lLUCtBMEUrVzRrSFR2Vm9oV0ZBR2M1WmVnWDhx NUQ0bFc2WGZnTFV2TlJHS1I1VTdlUnhYYnl4ZTFjaDhRMTIrQTlWL3dDdVIva2FBS1h3aXM0TGI0 WWFSSWtTYjV2TWtkc2NrbHpYYjhkMVg4cTVENFYvOGt1MEwvcm0vd0Q2R2F4L2kzNHJ2ZEIwMjEw L1RwV2dudk56UE1uM2xqWHN2b1NUMTlxQVBSL2tMYk1KdTlPOUxzVCs0djVWNHpGOEpMOS9EcWFv bXQzQTFob1JPc1l6dHpqZHQzWjNaOS9XdWorRS9pKzY4UTZkYzZkcVVwbHZMTGF5eXQ5NTR6d04z dUR4UUI2SjVVWi9nWDhxUXd4OW8xejlLZlNpZ0IwY2NUcmtSeDU3L0xUWGlDOUVYL3Zta0RlVklI L2hQQnEyUXJVQVpybGw3RDhxNEg0d1cwZHg4UGJ5UjQwTHhrRlR0NUZlanl4ZWxjRDhYRjIvRG5V YUFORDRjV2tObjhPZEI4cUpGWjdSWGNnY2trazVycUN5cXBkd3FxT3BQQUZjOTREL0FPU2VlSHYr dkdPc3Z4djRIdXZGOTVaRk5Ya3RMT05XV2VIbGczb1ZYcG5xT2ZhZ0RzWWJtMHVDVmhtdDVXSFVS dXJZL0twdHFaKzR2NVY4L3dEamJ3T253L1d4MUhUTlpuYWFTVXFBY0pJcEF6dVhiMjdWN1Y0WHY3 alZmQzJtWDk0dUxpZTNWNU9NWmJIWDhldjQwQWEzbHAvY1g4cVR5bytxeHBuNlUrbG9Ba2ppaGRN ckZHUCtBaW1QRUY2SW4vZk5JaitWS0QvQTNCcTBjTngzb0F6bTNEc28vQ3ZML2pqYlJ5ZUJoTzBh ZWJITXVHQzg5UlhyRXNRcnpENDREYjhQM0gvVFpmNXJRQjFmaGUwaHN2Q1dpeFF4SW8rd3hFNFhx U29PYTJBQWY0UitWVWRCWFBoblIvOEFyeGgvOUJGYXFSMEFSZVVoNm9LYjVhQTVLQ3JqSnNUSnFt VGswQUx1QTUySi93QjhpbW1RL3dCMVArK1JTR21tZ0JUTTQ2YmYrK2FyTnFrQ3plU2J1M0V1ZHZs bDEzWjlNVklhOFF2TGNmOEFDOUF1T3VvSS9UL1pCb3NCN2VibVgxSDVWNVg4ZExkSi9EVmhjc2kr YXR4dDNBWVArZWE5UE5lYmZHMy9BSkZDeS82K2gvU2dEMDJ4dG9yTFRiS0NDSkVSTGVNWUEvMlJW b0RQVlYvS2hFekJiZjhBWENQL0FOQkZUSkhRQkY1YW4rQVVnalJUbllLc3VnUk0xWHptZ0JjZ2Z3 Si8zeUthWkNQNFYvNzVvTlJtZ0J4bFlmM2Z5cGhuZjFINVVocGhvQVUzRW45NzlLOGorTnRwRlBQ NGVtYU5kOGx5STJJSFVFLy9BRnE5WUlyekQ0eTlmRFAvQUYvSi9NMEFlc21GTFVpR0dORVJWVUFC ZmFuRG5xcS9sVXM2ZnYycHlSMEFRK1dwL2dYOHFGalFIT3dWUElnUmMxRUtBRkpVZndKLzN6VFMr UDRVL3dDK2FEVERRQUdWaC9kLzc1cGhtZjFINVVHbU5RQXB1SlBVZmxYa0h4VjArR2Z4L3dDRkhh TmN6enFrbUI5NGJscjFzOUs4dytKbi9JOStEQi8wOUovNkVLQVBXWkFzTXp4eElpSXB3QUZwUnox VmZ5cDg2LzZWSi92R25KSG1nQ01vdjkwVUpHZ09kaW42aXBYVGFLYUJRQXAyOW8wLzc1Rk5MWTZL di9mSXBKWkVpamVTUndxSXBabVBSUU9wcnp2VWZpcFkzRnJORDRmc3IrN3ZwUDNkcTV0OFJzeE9B YytsQUhlRFVMWnJwclZMbTNOeW95MElkZDQvNEQxcDVtY2VuNVY1RmMrRnYrRVcxWHdqZFN6UEpy TjNxT2J5NTNINWkyTXI5T1NLNm54SDRzbXNsL3RIUjViZThzTk91VEJxc0FIN3hCMHl2MG9BN0V6 djZqOHE4ZzhhYWJieS9ISHd2bUZNWERMNWdDOE5qLzhBWFhyRU0wZHpieDNFTGg0cFZEb3c3Z2pJ cnpUeGYveVhId2QvdmYwRkFIcXhPeVJsUkVVQThBTFR3YzlWWDhxSFg5OC8rOGFrU09nQ01xdjl3 VStPTkFkMnhmeEZLNll4VGdCaWdBTzBkSTQvKytSVFMyUDRVLzc1cFRURFFBaGtZZGwvNzVwaG1m Mi9LbE5Sa1VBQm5rOVIrVmVJZkVDMGl0dmk1SExFaW9aN1BjMjBZeWVSL2hYdHBGZU4vRWYvQUpL cGFmOEFYaWY1bWdDc24zQldCNG4vQU9RWFAvdS8xcm9FKzdYUCtKLytRWlAvQUx2OWFvUjU0eDcw cU1kd3ByVTZJZk9LWUdqSDk1YXRoYXFSZmVGWFY2VjBRSkd0VVRIRlN0VUQwWEFZeHFNMDQwMm9Z REdGUXZVN2UxUXYwcVdNcnR4VWVjVkk5UkhyV1kwV0xZL1ArRmFNQXlLenJiNzFhTnYzclNBbVdN VkcxU25wVVQxcXhFRG1vbU5QZnJVWnJOZ05QU28yRlNVeHFrWkE0eFVSTlRPS2dOWnNhQUhpcmtY M1JWTVZjais2S3BBelFqSHlpbFlVa1gzUlRtcmRiRWtEOFZBeHFkNnJ0MXJOb1l3bmltbnBTMEhw VWpJbXFKcW1hb1c2MURHSjJwMGYzeFRhZEg5OFVJQ3gvRUt2cU9Lb0Q3NHJRajZWckFrYXdxdTV4 VmxxcXZUa0JHeHFQclQycHRaakdFVXdpcEdxT2tBMmp2UlJVMkdQV3BCVUttbmc4MDBKa2xQV21E RlNnVmFFU3gxWVdvRXFaVGc1eldpQWtQSzRyUGxHSkdGWEM5VTVEbHpTa0NLYmZlTkpTc1BtTkoz eFdBeDZkS21Xb1ZOU0thcE1DVVU0VXhhZW95S3BDSkY2MVlqcUZSelV5OFZvaEU2MHlmOEExYi9T amRnZGFqa2JNYkQycW5zSXFucFZGdXBxOVZNcnlhd2tXaHE1OUttU29nS2tYZzBrTXNMVCs5UkEx SXZKcTBTT0hXcFVwaWlwVkZXSW1UcFVncUphZVRXaTBBWk45dzFuM0p4R0t2U3Q4bFU1MTNJQldj eG9wZDZrUWMwaFQycHlpc3JBeXd0U2cxWFUxS3BxMElsRk9IV21pcEZGV2dKRTZWS3RSclR3YXRB eVR0VmM1KzBSL1VWS1d4VVFPYmlQNmlsTFlTUGQ5Qk9MR0wvZEZVUEd4elpXbi9YVnYvUWF2YUYv eDR4ZjdncWg0MDVzN1QvcnEzL29OY3hacGZCSC9rWC9BQkIvMkZXLzlBV3ZTcTgxK0NYL0FDQVBF SC9ZVmIvMEJhOUtxUmlpbHBCMXBhQUhEcFNpdVo4VStOZE44SXlXYWFoRmN5RzczZVg1Q2c0eGpy a2oxcmR1YjZ6c0lsbHZMcUcyalk0RHl5QkFUNlpOQUZxbVJQNVpkUFQ1aFNveXlJcm93WkdHVlpU a0VleHFLWDVaVWIxK1UwQVdjaVJheU5lVEdoMzMvWEUxWnRwc1NzaFBRMUY0aC81QUY2ZittUm9B OC84QWdlZitLSnYvQVBzSnkveVd2U1JYbXZ3T1AvRkYzLzhBMkVwUDVDdlN4UUJ3dnhXOFRmMkY0 WE5sYnliYjNVTXhMZzhySC9HMzlQeHB2d2o4TmYySjRXRi9PbUx2VWNTSEk1V0wrQmZ4Ni9qWEw2 cDRXOFErTlBpUWx6cW1tWEZyb3lQc1Y1TVlFSzl1dlZ2L0FHYXZaVlZWVUtxaFVVWUFIWWVsQURo VHFiUzBBT1BJcGtibEZaUDdwNCtsT3FHUVlsSG93SzBBV2d5eUxtdWY4WXJ0OEo2bC93QmNqV2pa WEh6RkNlbFVQR21QK0VTMUQvcmthQU9UK0NmL0FDUzZ6LzYrWnY4QTBLdEg0a2F2cEdsK0ZYaTFl MCsyTGROc2h0dyswczQ1M2J2NGR2cldiOEUvK1NYMm4vWHpOLzZGVnY0bCtFTHJ4Wm9rSDlubFRl V2psMGpZNEVpa2ZNdWV4NEdLRUI1em92Z1h4bGQrRnBiM1NyeHJhenZGTHJZQzVaV21Uc2ZUL0d1 bytEdXM2V2pYT2hycHEyV3FLdTk1ZHhKbTI4RUhQSUs1NmRLb2FSNHg4Y2VIZEhpMFovQ3M4ODF1 bmxRek5ESndvNloyOE5pcjN3eDhGNnphYS9QNGsxeUpyZVIwZlpFLzMzWno4ek1PdzYvblFCNnpT aW0wb29BY1JrVXlPVXBIZy93SEg0VStxOG8rZGgvZlVqOGFBTG9aWlZyai9pVXUzd0hxbi9YTS93 QWpXOVlYR1R0SnJEK0p2L0loNmwvMXpiLzBFMEFVZmhUL0FNa3YwVC9ybS84QTZHYXAvRkR3WGQr S2RQdHJuVFFyM3RwdUhsTTIzekVPTWdIMUdLdWZDai9rbCtpZjdqLytobXIzak84OFJXT2pwTjRh czF1cm9TZ3lnZ05pTWRjTDN6UWdPSTBqVWZpZSttUjZLdWtwYkNPTVJmMmhjcHRNYUFkYzV3U0Iz eFdWOEU0My93Q0VzMUpsYmNpMmhETjYvT01mMXE5cVBqVHg3cmxpK2xXbmhpVzBubVV4eVN4d3la d2V1TjNDL1d1dytISGd4L0NHanltN1pHMUM2S3ROc09SR28rNm9QZnZRQjJ2MHBSVFJTMEFLd0RL UjYwd1RGWWhucXAybW4xV25IK3NYKzh1UjlSUUJmVjFsVHRYQWZHSVkrSGQvOUs2elRybmNOcE5j cDhaUCtTZVh2KzZhQU5Id0NjL0R2dytmK25KSzF0V3VwTERSYjY4aFVOTEJidklpbm9TRkpGWkhn REgvQUFydncvOEE5ZVNWb2VJYnU2MC93NXFOM1lwdnVvWUdlSmRtN0xmN3ZlZ0R5andMNFdrOGZY bHo0aDhUM1UxeXNVb2pGdTN5aHpqZCtDODlCWHRTSWtjYW9paFVVQlZWUmdBZWxjWjhPZkVHdCtJ YkMvbDF5M0VFc015ckVCYm1MS2xjazRQV3UxRkFDaWxwdE9vQUdYY3BGTU01UkVZOVI4cHArYXFY SS9keWdkY2J4K0ZBR2lrZ2tUTmVYL0hZWThCc1ArbXEvd0RvUzEzbW5YTzRBRTF3WHgzT2ZBeC82 NkwvQU9oTFFCM0hodGMrRjlIL0FPdktMLzBFVnVSeDFqZUZSbndycEgvWG5GLzZDSzZHTmNDZ0RQ djMyN1l4OVRWS3BMcVR6TG1ROXM0cUltZ0FOTlB0UVRUU2ZlZ0JEWGtkMWJPZmp6Q2RoMitZajV4 eC9xcTlicno2NThSZUpVK0pDNlVsdC94S1B0Q29aUHNwUHlsUVQ4LzFvQTcwL2pYbS93QWJmK1JS c2Y4QXI2RmVrVjV0OGJmK1JTc3Yrdm9VQWV2VzZiclcyUDhBMHhUL0FOQkZYSTR1S2hzMXpaMjMv WEZQL1FSVjVRQUtBTTI5WUJ4R08zSnF0U3l2NWs3djZtbW5wUUFoTk5OS1RUVFFBMDF6dDM0MTBD ejFvNlJQZU90OEpGaThzUk1SdWJHQm5HTzlkRWE4ZTFiU1lkVytNOGNXbkdSMmlranVMMXljcWhY QklINEJSOVRRQjY2ZUs4ditNdjhBclBEUC9YOG4vb1JyMUJ1dGVYL0dUL1dlR2Y4QXIrVC9BTkNO QUhzN3BtWS9oVThjZUJSdHpKK1ZUZ0JWb0F6YnBzeTdCL0QxcUttbDk4ak5ucWMwRTBBQnBwb05O TkFFTjFjUldsck5jenR0aWhRdTV4bkNnWk5ZR2srTi9EMnZhZ3RocHQ0ODF3eXN3VXhNdkE2OGtW czZuYW0vMHU3czFmWVo0WGlERVoyN2xJeml1RThIZkRXZnd2cjhlcHlhbkhjS3NUSjVheEZUOHc5 YzBBZWdHdk1QaVoveVBuZ3dmOVBTZitoQ3ZUNjh3K0puL0krZURNLzgvYWYraENnRDJTUk0zRC83 MVRwRnhTbGN6TjlhbjRSQ3g3Q2dETm5iTTIzc3RNcHFuZGx2WG1sTkFHZDRnNThONnAvMTZTLytn R3VkK0cxOWFKNEEwYUEzVUN5K1d5K1daVkRaM3R4ak5kZ3dEQXF3eXBHQ0Qzcmg5WCtGM2gyNnNy bit6ck1XTiszenczQ08zN3R4eU9NOUtBSS9pRC95SHZCLy9ZVS8rSnJJdko3T1R4UjQzdTROdjlu UjZYNU4wdys0OCtPbjFxbC9hbXIrSWRhOE02VGY2ZGNMcStsMzI2OGtNZjd0a1hIejd2Y0N1MjhS K0ZmN2VlMnRVblMyMHczQm52NElrdzl5MzhPV0gwNW9BazhFeHl4ZUI5R1dmSWtGcXZCOU8zNlZ4 dmk3L2t1WGc3L2UvcFhwNFZVVUlpaFZVWUFYZ0FWNWg0dS81TGw0UC8zdjZVQWV3bVBNcmZXckNS WUZJcTVrSjk2bmZFY0xONkNnRFBrT1pqNkx4UWZTbUowejNOTG1nQU5OSnBTYVlhQUVOTU5QeG4v NjFNUEZBRGE4YitJdy93Q0xxV24vQUY0bitacjJROWE4ZCtJb3o4VTdZZjhBVGlmNW1nQ3JHUGty bnZGQS93Q0paUDhBN3Y4QVd1aWovd0JYWFBlS1ArUWJPUDhBWi9yVkNQT21GTEh3NHB4VWswOVU1 cXJBWFkvdkNyaTlLcG9jTUtzZzVyZUpBNXFoZXBTYWpOREJFQnB0U01LWVJVakdOVUwxSXg1cUZq VU1aQzFSRVZLUm1rQzg5S3pHaVMyKzkrRmFOdlZHQVliOEt1d3NCbXRJQ1phTlF2VHQxTlk4VnFJ Z2NjMUVSVTdWR3dyTm9DS21OVHptb21xUmtibW9XNjFLM1NveURXYkdob3E1RjkxYXFoZmFyVVl3 Z3FvZ3pSais2S1UxRXJZVVUvT1JXNlpKRTlWMnF3K0tpWVZER1E0NzBoNlU1cVl4eHhVREkyOXFp YnJVckdvbXlUVU1CS2RIOThVMm54Zzd4UWdKL3dDSVZvSnd2V3M4ZmVGVzFmcHpXc1JEMnF1OVRr NXFGcWJBcnRUYWxZWnFNMUF4clZHVHpUelVaNjFEQWw4aW5DM05TS2FtVG1yc0lyZlp6NjAwd2xh ME52dFRIVEFQRlBsQXFBN2FEUGp0VEh6dHFIdFVYc05Ga1hPTzFPKzFHcWxPV2ptWXlkcHkxS09S VWFpcEY0cGlZNHhCbHdEU2ZaaDBwNE5USnpWSlhFVi9zdEtMWWlycWoycHpJQ0tmSWd1WndRcWVh ZXJCZXRUVGpBWGlxVXh4dHBiQVRmYU1kQlRoZGRzVlJ6VGxxZVlkaTc5cFBTbUdRdTNvS2lVVklv cXJpSkI2VXJRaHVsTnFaVDNwb0NMN0xtbEZwNzFaVWlwQjlLcmxDNVQrellIV2tWZHZCcThWelZh WWZQNlVtckNHK1lxTDcwMzdWZzFYbE9KS2l6bHFseUtMNHVpZTFPRnp6VkZhbVVVY3pFUytZV2Iy cVJWQk9LaVVWSXRVaEFiWUUwZlpNMUtwNXFWYXF3RmY3S1JTR0ZsT2F1aW1zdlhpbnlnVmdjVUdj Q2trNk5WRXY3MURkaGw0WElwMzJuUGFzOVNTZXRUSlM1Z0xKbnpUNFNXbFgvZUZRS3RUd2o5Nm4r OEtzUjd6b0ovMEdML2NIOHFvK00rYk8xLzY2dC9LcnVoWUZsRi91aXFQakg1clcxSC9BRTBiK1ZZ RkdwOEUrTkI4UWY4QVlWYi9BTkFXdlNlSzgzK0NveG9YaUQvc0tuLzBCYTlIcVJuTmVLOVM4VTJj OXBiK0d0Smd2RE1yRjU1bndzUkdPRHlQWDFybEpmSG5pendwcTFwYitNTk1zeFozUndKclhxQm5C SUlKQnhucFI4UVBFK3J4K01kUDhNYWZxSDlsMjg0ak10Mk9EOHpFZGV3SDlhNUQ0bWFKRG9qYWZD ZkVONXExMDVacEV1WmcvbGpqQkE3WjUvS21CMFh4d3dicncrUnlNeUhQNHBUUGpaYzZzOE5yYVMy YUxvNFpYanVRZm1hWFljcjE2QWUxSjhhUCtaYS8zRy85a3JUK040ejRUMDBnWi8wdi93QmtOSURm OEJhbjRudkxlS0RXdEhoc3JHTzBqK3pUbzJUSndBTThuK0htdXZ1T1lqNmptczd3NWN3WEhodlN6 RE5ISVBzY1gzR0IvaEFyU2ZsRDlLQU0xMzh2VWo2TmhxazE4N3ZEZDUvMXlOVmJ2aWUzYjFYSDVH cDlhT2ZEVjMvMXlOQUhDZkEvL2tUTlEvN0NVbjhoWHBRcnpUNEgvd0RJbWFoLzJFcFA1Q3ZTaFFB K3NxODhUNkRwMTI5cmU2dloyOXdtTjBVa29WaGtaSEZhZGNUNGgrR0dqZUpOYW4xVzd1NzJPYWJh R1dObDJqYUFCMUh0UUJ2anhqNFlQVFh0UC84QUFoYW10dkUyZzNkeEhCYmF6WXl6U0hha2FUcVdZ K2dGZVcrS3ZodDRWOExhRk5xVjFxT29saDhzTVc5TXlTSG92M2Z6OXF3ZmhSNFh1ZFg4VHc2cWN4 MlduU0NScE1mZmsvaFFmek5BSDBOVVZ4eEh1SDhKelQ4MHlYbU52cFFCbWIvSzFLUmUyY2lvL0dM WjhIMzMvWE0wbDBjWDBURCtKVnB2aTA1OEhYMy9BRnpQOHFBT1grQ1gvSk1MVC9yNW0vOEFRcTlD RmVlZkJML2ttRnIvQU5mTTMvb1ZlaENnQjRKNlZrd2VLZEF1cnhiT0hXTE43bG4yQ0ZaUnZMZW1Q V3RTdkZQaTE0V2swclZZdkUrbWd4eHpTRHpqSC95em0vaGY4Y2ZtUGVnRDIwZWxaemVJOUNXN05x ZFhzaGNoL0xNWG5ydTNkTnVQWE5jYmNmRW1BZkRRYTVHNmpVNUI5bFdMKzdjWTVQMEErYXVZK0VI aE5yNi9meFBxQ2w0NG5JdHQvd0RITC9FLzRmeitsQUh0bFJUbmJ0Yis2YWZtbzUrWVdIdFFCbHd0 NU9vU0owdzFaL3hLYmQ0QjFEL3JrMy9vSnEzYy9McWdiKzhxdCtsVVBpTno0QXYvQVByazMvb0pv QXJmQ2Y4QTVKZm92KzYvL29acnN4WEdmQ2YvQUpKZm92OEF1UDhBK2htdXhvQWZta2VSSW8ya21k VWpYa3M1d0IrSm9GZUJlTXZFT3ArUFBGZzBQU21kckpadkpnaFU0RWpBOHUzdDErZ29BOWVmeDU0 VGltOGw5ZnN0NE9EaDhqOHh4VzVhM2x0Zlc0dUxPNGluaGJwSkU0WlQrSXJ5MjArQituaXpVWG1z WFRYSkhKaFJRZ1BzRHlhWjRSOEMrSmZDZmpwRnRyd05wQlF2Tk9QdVNyL2NLOW5vQTlielVVdkRJ ZjhBYXhVbFJULzZvKzFBR1RhUDVWNjhmbzJLd3ZqQTJmaDNlZjdoclptK1RXSDl5R3JEK0xoLzR0 M2VmN2hvQTFmaC93RDhrNzhQL3dEWGtsZEdPSzV2NGY4QS9KUE5BLzY4a3JvNkFHWGQzQloycjNO NU1zTUVZM1BJNXdGSHFhcmFkcm1sYXcwaTZacU52ZHRHQVhFTWdiYm4xcWE4czR0UXNMaXluR1lw NG1qY2V4R0s4SStHMXpMNForSkxhWGRFcDVyU1dVdWY3d1B5L3FQMW9BK2dhejIxN1Iwdi9zRGFw YUM4M2hQSU15NzkzcGoxcXhkM1VWaFpYRjVNY1JRUnRJNTlsR2E4TytGOWxKNGkrSVZ6cmx5Tnd0 OTkweFAvQUQwY2tML00vbFFCNzFVTW95Ni83WHkvblVsUlRjSm4wSU5BR05ZeUdPNUtIc2E1SDQ1 SFBnVS83Ni8raExYVk1QSzFhVmY5dXVTK04zUGdQL2dhL3dEb1MwQWVpZUUvK1JWMGovcnppLzhB UVJXK3gyUXMzb00xZytFditSVTBqL3J6aS84QVFSV3ZldHNzWkQ2akZBR0tEazUvR2x6VEJRVFFC blhQaUxSYk80ZTN1ZFZzNFprT0hqZVpWWlQ3aW9WOFZlSHBHQ3JyVmdXUGJ6MXJ4YnhiYVIzL0FN VnJxMGxMQ09lOWppY3IxQVlLRGl1dTFyNFI2VmJhVGRYRmpmWFN6d3hOSXZuRldSdG96ZzhESFNn RDA1WkVrakR4dXJvM0tzcHlEK05MdTR4bml2SXZnM3FWMGIyKzAweU8xb0lSTXFrOFJ0dXh4Nlp6 K2xldG1nQkRYbS94dC81Rk95LzYraFhvOWViL0FCcy81Rkt5L3dDdm9VQWUwV0kvME8yLzY0cC82 Q0tzenQ1ZHZJM29wcXZZL3dESG5iZjljay85QkZMcUxiYkpoNjRGQUdRdkZLVFRRYVJqd2ZwUUJu d2VJZEZ1cmxMYTIxV3psbmM3VmpTWlN6SDZWb0UxOHJCcDRiOTdtMkxyTEJLWkE2ZFV3M0JyNks4 SStJNHZFL2grRytVaGJoZjNkeEdQNFpCL1E5UlFCY2wxL1I0dFEvcytUVXJaYjNlRThneWZQdVBR WXE0SVlrbWFaWW8xbGNZZHdvRE5qcGs5NjhSMWYva3RnNS81aU1QOGxyM0J1cG9BUTE1ajhZLzla NFovNi9rL21hOU5yekw0eC82end6LzEvSi82RWFBUGNWSHpmbFJkUHN0Skc2Y1U1T3Y0VkJxYll0 UXY5NWhRQm1MMHFyZTZwcCttQkRmM3R2YWgvdUdhUUx1K21hc0ExNVQ4YnZtdHRHLzY2Uy95V2dE MCt6MUt4MUtKcExDN2h1VVZ0ck5FNFlBK25GVFpyeEg0UGF2OWg4UlQ2Vkt4V085ajNJRC9BTTlG R1IrYTVyMnhtVlFXZHNLT1NUMkZBR2RmK0lkRzB1NCt6MytwMjF0TnQzZVhKSnRPUFdyTnJlVzEv YXBkV2s2VDI4Z3lra1p5RzdkYStiUEZPcXZyM2lTLzFQa3hTUzdZL1pCd28vSVY3ajhPL3dEa1Fk SkgvVE52L1Eyb0E2YzE1aDhTL3dEa2ZmQm4vWDBuL29RcjA0MTVqOFN2K1IrOEdmOEFYMG4vQUtF S0FQY0FQM2pmV20zcmJMTi9VOFZJUDlZMzFxcnFiWWlSZlZxQUtRNG9KcGc2VVVBUVgxL1o2YmF0 YzMxMUZiUUwxa2xjS0s0dlRQaWRwZDU0bXY3QzR1TE8zMCtML2oydS9NSTg0OGV2QXJpZkZVMy9B QWxIeFlUUjlWdTJ0OU9obkZ1dUd3RkdNayt4WThaOXhVMmsrQk5IMWJ4cjRrMFp4Y1EyOWtGK3ps SlBtWEo3NTYwOUFQWmttam5pV1dGMWtqWVpWMGJjQ1BZMEd1YzhGZUZ2K0VSMGlTeWE3YTVlU1pw QzNSUU9nMnIyNDYrNXJvU2FRQWE4dzhXLzhseThILzczOUs5Tkpyekx4Yi95WFB3Zi92ZjBvQTl0 UWZPZnJUYjV0dHFSL2VJRlNKOTQxVjFKdjlVdnZtZ0NxT2xLVFRRZUtUclFBcE5OSnJNdGZFR2wz K3NYR2xXZDBzOTFieCtaTjVmS3B6akc3MTlxMGFBUE9makxjVDIzaDNUMnQ1NVlXTjNnbU55cFB5 SDBycFBBcnZKNEcwZDVIWjVHdHdTem5jVHllcHJsUGpXNi93RENQYWFoWWJqZGs0LzRBZjhBR3Vx OERLVThDNktEd2ZzcTBBZEJYai94REdmaWpCLzE0LzFOZXYxNUQ4UVJuNG9RL3dEWGovN01hQUtp ZmNGWUhpUlEybnlyNmordGRBbjNLd3ZFUC9IbkpWcmNUT0creWlsRVFYdFV4cGhQRmJXSkl6d09L Ulp5dlVVVkd3b0FrTnpqdFRmdFFQYXE3akZSTWFoeUdYaGNBMEU1NlZRVnpWdUk1VDFvVHVOb2Q1 UmR2YWo3TDcxYWpIeTlLazI0Rlh5a29vRzB4M28rekRnMWFiaW8yTkxsR1JsUW80eFViTVVPUlVq R28zR2FURUw5cElHS1B0V0tnWWVsUk53S200eTBia1pwUktHRlVNKzlQUnlXQXBjdzdGc2pkU0xB VFQ0eGxoNlZiQysyS3RLNUpSTnFlOUlMWEhGWDJIRlFzY1UzRkRLd3R3RFJqQnhVak5VWnFRR2lZ cTNQcFRoYzhacU5nS2lZVkZ3c1RtNnBQdE5WRG1nSEZMbVk3RnhuM0RpbWxTNUdLamg3ODFidHdN RSs5VXRSTmtQMlludlRmczN2V2h0eFRHcXVVTGxFMitEVGhHRUdhbFkxR3hxYldBWVIzcEZsWmV0 TC9EVEdwWEdQKzBuRko5cHoycUEwbjQwcnNDY1RaT0tDUWFncVJmdTBKZ08yRmo3VXYyWStwcXhD dVkrbFRLb0FxbEc0aW1sV1l1Z3F1dldyRWROQVdGcHNoQ3IwN0duTFRaaDh2NFZiRVpyL0FIVFVO VFNmY05RMWd5a0ozcVZhaTcxSXRJWktCVHFRVTZyV3doVk5UUjFDT3RUSjJxa0lzcHlLbEE0cUpP bFNyN1ZvaEZXNk9kdFo4L1JhdjNQWTFRbjZMV1V4a05QU21VOUt6R1RLS2xBNHFOZXRTaXRFSU85 UFgwcG5lbnJWTGNSTWxXRkZWMHF3bFdnSk8xVTdqL1cvaFZ2dFZPNC8xbjRVU0FvWEkvZU45QlVT NHpVMXovckcrbFFqclhPOXl1aE1tTTFPdFYwNjFZV3JRbVNDbEhCcEJTOTZzUklwcWRPMVYxcXds VWdKUlN0MHBCUS9TckVVWmVWYjZWbk53YTBaT2pWbnQ5NnVlZTVTSEpWaEtycDFxeW5haEF5WmFs aC8xcS83d3FKYWxpLzF5Zjd3clZDUGRkRC9BT1BHTC9kRlUvRjNOcmJmOWREL0FDcTNvWnhaeC83 b3FuNHM1dGJiL3JvZjVWZ1VhL3dZR05EOFFmOEFZVVAvQUtBdGVpMTUxOEd1TkU4UWY5aFQvd0Jr V3ZSS2taaGVKUEJ1aStLeEYvYWR1NWxpRzFKb24yT0I2WjdqNjFrZjhLcDhKZllVdFRaemZLMjh5 aWMrWXh4amx2VDJydEtXZ0RuOWM4RjZQNGppc1UxRVhMaXlYYkVVbDJudDE5ZnVpcit1YURwL2lM U20wM1VvakpBU0dCVnRyS3c2RUgxclJvb0E1bndyNEUwbndoY1hGeHAwdDI3em9FYno1QXd3RG5n QUN1blBTa29vQXliMGZMQ2ZSMkZUNnlQK0tadS8rdVZNdWx6RC91eTFMclF4NFp1Lyt1VkFIQS9B L3dENUV6VVArd2xKL0lWNlZtdk5mZ2YvQU1pWHFIL1lUay9rSzlKb0FXbVhGekRaMnN0emN5ckZC RWhlU1JqZ0tvNzA2dkZ2aTc0eGU2dkg4TldUTWx2YnNEZE1PUE1mcUYrZzQvR2l3R05yR29hbDhV L0cwVnBZaGt0VkpXQlc2UlJqNzBqZTU2L2tLOTEwVFI3UFFOSXQ5TXNVMnd3cmpQZG03c2ZjMTVm OFB2RVBnendsbzM3N1V0MnAzSURYTWdnZjVmUkFjZEIrcHJzN2Y0bGVFcm00aXQ0ZFRMU3lzRVZm SWNaWW5BSFNnRHJjMGpmZE5IU2tQU2dESXZCODFxMzFYOWFiNHNIL0FCUnQ3LzF6cWE2WEtRbjBs SXFQeGNNZURiNy9BSzVVSURsUGdsL3lUQzEvNitadi9RcTlCcno3NEovOGt2dFArdm1iL3dCQ3Iw SDBvQVdzM3hDdW12NGR2MTFnZ2FmNUxlY1Q2ZTN2MHg3NHJScnhiNHRlS24xVFVVOE02YXpTUlJT QVhHei9BSmFUWjRUOFA1bjJvQTh4VHkvT1ZYYVVXdm1jNDY3ZlhIVGRpdnF2UlVzSXREc1UwcmIv QUdlSVY4Z3IzWDErdnJYQ1QvREtML2hXbzBoRVQrMTQvd0RTdk4vdlRZNVRQcGo1Znd6V0o4SVBG ald0eTNoZlVHS2htWnJYZi9DLzhVZjQ5ZnJtZ0QyU2tmN2pVZmpTSG9hQU1lOEgrbFd6ZXFZL1dx SHhGR1BoL2Y4QS9YSnYvUVRXbmRLUzFxZjlwaCt0Wi94SEdQaC9mLzhBWEkvK2dtZ0NsOEtPUGhm b3YrNC8vb1pyc2E0NzRVLzhrdjBUL2NmL0FORE5kalFCQmZGMTAyNlpQdmlCeXVQWGFhOEwrREN4 dDQzWjVNR1JiT1FwbjF5dWYwelh2WkdlQ01qdUsrZDlac3RSK0cvajFidTJUTUt5bVcyWnZ1U3hO MVEvaHgrRkFIMFZtak5jQmFmRjd3dlBhQ1c0ZTd0cHNmTkNZU3h6N0VjSDlLejlGK0tVK3Y4QWpp MzA2eTAyUTZaTXBUcG1RSC9ubzNZTDJ4UUI2ZjhBU21TOHh0OUtXa2I3cG9BeHJzZjhUS0Z2N3lM V0Y4WEJqNGMzbis0YTZLNVROemFIL1pJL1dzSDR2TC94Ym04LzNEUUJvZUFPUGgzb0gvWGtsZEhY TytBdVBoNzRmLzY4a3JvYUFGNUZlRS9GalQ1TkU4Y1crczJ3Mmk2VloxWWY4OVVJei9KVCtOZTY1 OTY0VDR0YVAvYWZneDdxTmN6V0Vnbkhyc1BEZjBQNFVBUS9FcnhKRzN3M2htdG4rYlZ4R3E0UDhK RzUvd0REOGFtK0VPai9BTm0rRFJlU0ppYS9rTTNQOXdmS3Y5VCtOZU5yZVgzaU9MUXZENHlWdDNO dkQvMjBmcitBL2xYMHphV3NWalpRV2NJMnhRUnJHZ0hvQmlnQ2VtVGN4TlQ2Ykp6RzMwb0F4YnBj YXdEL0FIbFUvcFhJZkc1Y2VCUCtCTC82RUs3TzRUT28yN2VzWXJqL0FJNHJqd0ovd0lmK2hDZ0Qw SHdsL3dBaXJwSC9BRjV4ZitnaXRMVTJ4WmdlckNzenduL3lLdWtEL3B6aS93RFFSVjdWMnhER1Bm OEFwUUJsaWt6U0E4VWhOQUhnZmk4M0krS040YkwvQUkrL3RrZms1eDkvQzdmMXhXNXJWdjhBRTYr MDJhRzlqZHJZcis5UzM4c0ZsN2o1ZVQ5S3gvRXM4ZHQ4V3ByaVo5a01kL0U3dWY0VkczTmVuM1B4 SThLMjhiU3JxZm5NT1FrVWJGbS9TbUJ6UHdxMWpRNDFrMHFHMWx0dFRrRzUzbGZkNTIzc0R4akg5 MnZUYThKOEVRM0d0ZkVhTy90NFRIRXR3OTFManBHcHp4K3VLOTFwQUZlY2ZHdm53bFpmOWZRcjBh dk9maldmK0tTc3Yrdm9VQWUwMkovME8yLzY1Si82Q0tqMVpzUVJyNnRUckgvajB0dit1U2YrZ2lv TlhQOEFxaG4xTkFHZURTTWZsUDBwdWFSdnVuNkdnRHdyNGEya0YvNHl2TE81akVrRTFyT2pvZTRK RlQ2UGMzSHcwOGVTMkY0N0hUcGlFZHV6Um43ai9VZC94cFBoWC95UHMzL1hDYitZcnZQaU40WC9B T0VpMEl6MnlBMzltQzhXT3JyL0FCSi9VZTlBSEE2c3dmNDFLNnNHQnY0U0NPaEdGNXIyOG12bTd3 eEk4bmpEU0hrWm1iN1ZFTXNlY0FnRDlLK2tDZWFBQ3ZNdmpGL3JQREgvQUYvcC93Q2hHdlRLOHor TVgzL0RQL1grbi9vVkFIdWEvZXFucXpmTEVQY21yU0g1Nm82czM3Mk1mN0pvQXBnOFY1VDhiVC9v MmovNzh2OEFKYTlUelhsUHhyUCtqNlAvQUwwdjhsb1FITStJYlNYdy9MNFg4UldnMitiYVF5RWov bnBHQm44MXhYcFhqenhIRmErQVh2TFdUNXRSaldLQWc5bkdTZndYTlptdDZQOEEyejhIN0lJdTZl MXM0cmlML2dLL01QOEF2bk5lWjJsemZlS1A3QjhOOG1PQ1JvMFAreXpaSi9CYUFMZXFhTi9abnc3 MGE1ZGNUWDExSk9mWFp0QVQ5TW44YTljK0htUCtFQjBuL3JtMy9vYlZ5dnhpaGp0OUUwV0NFYlk0 NVhSRkhZQlFCWFVmRHcvOFVIcFgvWE52L1Eyb0E2Zk5lWi9Fci9rZmZCbi9BRjlwL3dDaEN2U3Mx NXI4U3Y4QWtmUEJuL1gybi9vUW9BOXhIK3NiNjFSMVEvdkloN0UxY1UvdlcrdFoycEgvQUVwUjZM UUJBRFNacHRKK05BSEErT3ZodXZpVzdPcDZkY0piMzdLQklrZytTWEhBT1IwUGJOZVlhYmUrSlBC K3I2aEpaNy9OdFdFTjZTdm14OWVBeDlPT3RkOWZmRSsrMEx4YmVXZXJhVEl0Z0gyeEtCdGtBSDhR N01HNjF5OWw0MjArd3UvRmx6OW1rbS90YklnallBREIzZmUvT25xQjZoNEw4WHcrTHRMZVlSZVRl UUVMUEVEa2M5R1gyUE5kR1RYbTN3ZzBPNjAvVGJ6VXJxTjQxdk5xd3E0d1dWYy9OajN6WHBGSUFy elB4Wi95WFB3Zi92ZjByMHNtdk5QRm4vSmN2QjMrOS9TZ0QyNUQ4eHFqcUxadUVHZWkxY2pQekg2 MW4zNXpkbjJVVUFSQTE1RDhVdGY4V1dzcldZdDJzZElmNVZ1TGR0M25mN3pmdy83djg2OWN6VWM4 TVZ6QThFOFNTeE9NUEhJdTRNUHBRQjgzK0Q5YTEzUTd5NWwwQzArMHpTUkJKRjhneTRYT1J3UGV1 dC80VHY0aW5wbzUvd0RCZTllZzZENE4wN3cxcmQ1cUdtR1NPSzZpQ05iazVWRHV6bFQxeDdWMGhj K3RBSGh2L0NQZU5QSDJyd3phMUZMYld5ZktaSlU4cFkxNzdFN2sxN1ZiVzhWbmFRMnNDN1lZVVdO QjZLQmdWS1dwdWFBSFpyeVh4OE0vRTZNLzlPQS85Q05lcjE1VjQ4R2ZpYW4vQUY0RC93QkNhZ0Nr bytXc0x4RU1XY2xiNEh5OUt3ZkVRLzBLU3JXNG5zY1UxUkdwV3FNMXV5UnVLWTFQN1V4cWtDQ1Nx elZaazZWV2FzMk5EUjZWZWdHSTZvRHJXaEQ5eWlBM3NYNGpsUlR6VEloOGxPTmRDSVc1QzlRdFV6 MUMxUTl4akRUVFMwaHFHQkcxVjVLbmVxOGdxR05FUnAwWXl3K3ROTk9pKzkrTlNNMG9UaHhWd0RJ cWxGL3JCVjRjQ3VpR3hKR3dxQjZzTWVLclBRd0lUU2RxVTBsWnNCakNvbXFWdWxSTjBxUm9oYnJT VXJkVFNWQlJOQi9GViswT0ZiNjFRZy9pcTlhamh2cldzQ1MwUlVFblNwelVFblN0R0lyc2FpTlNO VVpyTmpFcGpVK210VWpJbXB0T2FtMUF3cVJCOHRSMUluM2FhQXZXL3dCeGZyVTJLaHR1RVg2MVBX OGRpU2lvNXFkT0tyaHdEVHhNdmVvVEF1QTRwanVjZm5VSG5pbzNtejBwdVFFTGpLbW91bFQ0M2NV d3hFVm0wTkVWUFUwdmxOU2lKeDYwckRIcWFmVWUxaDFxUmZ1MVFoNmlwa0ZSQWdkYWVKVjlhb1Ja VTFKdXhWUVRvS1UzQzRxMUlWZ3VUOTJxYzQ0U3BqSnZwcGozMUV0U2tVOGM5S2V2V3BUQXhvRUQ1 ck93UFlWVFVxOFZHSW05RFRnQ0dBTldrSWZVaURpbUNwUTZyVklDUlJVeThWV0VxMDRUcFZwaXNX UzJLcTNITW40VUdkYWozYmptazJCVnVCbVEvU29nT2F1UEZ2Qk5SK1EyYXpjUmthOFZPcHBvZ2ZQ U25pSmdPbE8xZ0hxYWVPVFVTOEhCcVpmZXFRaDZpcGw0cUVPcTA0U3A2MWEwQXNDa0xjVkY1Nmpv YVkwL0hGRndJNU9WYk5VV1NyMk0valRHZzlPbFp5VnhsUmVLblE0cGZzN0NuQ0Z4NjBrckFPVTFQ RC9yVS8zaFVIbHNPMVR3Wjh4UFhjS3RDUGN0RS80OUkvOEFkRlZ2RlBOdGJmOEFYUS95cCtrM01V TnBHWlhXTVkvak9NMVg4UTNNTnhEQ3NNZ2tLdVNkblBhc1NqZCtEcEg5amVJUjMvdFQvd0JrV3ZR cThYK0huakhUL0MxL3IybWF5WkxkYm00anVJSlNoS0g1Y0VFZ2NkcTlBSHhCOE1zTWpVNGYrK3Fr WjFGTFhNZjhKLzRhL3dDZ25ELzMxUy84Sjk0Yi93Q2duQi8zMVFCMDFHYTVrZVBQRFovNWljSC9B SDNUaDQ3OE9mOEFRVGcvNzdGQUhTVVZ6ZzhjK0hUL0FNeE9EL3ZzVTRlTnZEeDZhbmIvQVBmd1VB YXNxN2xsSCsycHBkZDQ4T1huL1hFMWh0NHo4UHFaR2JVb01IR01PRFdaNHIrSS9oeUx3N2RSMjk2 Ymk0ZUlva1VTbGlUUUJuL0Evd0Q1RXZVUCt3bkovSmE5SnJ3ejRRZU9OTTBEUmIvVE5ZTXR0Skxk ZmFJbmFOdHJBZ0FqT092RmVsTDhRdkRKSEdweGZuUUIxTmNwcVh3NDhNNnZxVnhxRjVhVFBjenZ2 a1lUc29KK2xTZjhMQThOZjlCT0wvdnFqL2hZSGhyL0FLQ2NQL2ZWQUZBL0Nid2dmK1hPNC84QUFs cWZiL0N6d3JhM1VWeEZiWElraWRYVW00WThnNUZYUjQrOE4vOEFRU2gvNzZwZitFOThOLzhBUVNo Lzc2b0E2WW5KcE8xYzRQSGZoekgvQUNFb1ArKzZVZU9QRHAvNWlVSC9BSDJLQU5XVmR5SDJsSDhx ZzhZY2VENzhmOU1xeTI4YStIVkRsOVNod1dCR0d6V0g0NitJMmdQNFd1N1d3dVd1cnFaTmlSeElU ejcwQVNmQlAva2w5cC8xOHpmK2hWMzllSy9DWHgzcE9oZUV2N0cxWjVMV2VPNGVSR2VOdHJLMk8r UFd2UWg4UXZESi93Q1lsRitkQUhVTU1xVnlSa1l5RGcxeStuZkR6dzFwV3F4Nm5iV2NodTQzTHE4 czdQOEFOL2V3ZS9OTC93QUxBOE5mOUJLTC92cWovaFAvQUEwZitZbkQvd0I5VUFkUUNldGNwZmZE bnczZjZ0SnFqMjg4VjNKTDVwZUNjb0EvOTREdDYxTC9BTUo5NGIvNkNjUC9BSDFTL3dEQ2VlSEQv d0F4T0gvdnVnRHBRTUFkL2MwSHBYTi84SjE0ZFA4QXpFb1ArKzZjUEcvaDQvOEFNU2cvNzdGQUdu S201WXZhVTFsL0VyandCcVAvQUZ5UC9vSnFGdkd2aDVCOCtwUS9mM2NObXVYK0pueEMwUzk4SVhP bmFaTzkxZDNDN1ZXTkNjY2RTYUFPZytGUC9KTDlFLzNIL3dEUXpYWVY1RDhNUGlEbzJtZUNyUFI5 VWtrdHJxMVp4KzhqYkRLV3lNSEZkc1BpSDRaUC9NU2kvT2dEcUtxNmxwZGhyRm0xcHFOcEZjd056 c2tYT0Q2ajBOWVErSUhoby84QU1TaS9PbEhqN3cyZitZbEQvd0I5VUFaVW53aDhKdkx2RVY0aTV6 c1c0T1AxR2E2YlJQRG1qK0hZR2kwcXhqdDkzMzMrODdmVmp6V2VQSFhoMC84QU1TaC83NnB3OGIr SHowMUdIL3Z1Z0RvczBoUEZZQThaYUNmK1lqRC9BTjkwdi9DWGFHZitZaEIvMzJLQU5PUk56V3g5 SFlWejN4ZVhQdzd2Z1A3aC9sVjMvaExOQ1FKdXY0dmxZdHcyZUs1TDRwZU10SzFUd3ZKcG1tTzl6 Y1RIYis3UWtLUGMwQWRkNElHM3dCb0Evd0NuSkszYzE1NTRJOGI2VEI0UTAzVDcyUjdlNnRZdktk WkVJemc4RUhIcFhSanhub1IvNWY0L3pvQTZETlIzRUVWM2F6VzA2QjRaa01icWU2a1lOWWYvQUFt V2hmOEFQL0YrZEwvd21PaGRyK0wvQUw2b0FyYVI4UGZEZWlhbERxRmphU3JjdzVNWmVabUE0eDBO ZFZtdWYvNFRIUS8rZ2hGLzMxUi93bU9oZjlCQ0gvdnFnRG9NMGpkRFdEL3dtT2cvOUJHRC92c1Vm OEpob0pIL0FDRVlQKyt4UUJveUp1dWJSdllqOWE0cjQ2REhnUS83NC84QVFscmRieGo0ZmphRXZx TVB5azV3MmE4KytNdmpUU3RjMEdMUzlJa2t1cFdjTTVqUWxWQVByK0ZBSHNIaFgva1dOSXgwK3hS ZitnaXJtc0hpSWZXdUE4RmZFblFENFkwMkM4dVRiWFZ2YnJGTEhLQ3VHVVk3OXEzTC93QWIrSHJs a01lcVcrQU83aWdDOWlqbXNQOEE0Uy9RQU9kVHQvOEF2c1UwK01mRDQvNWlsdjhBOTlVQVZkVCtI L2g3VnRSbXY3eUNkcmladHpsWjJVWnhqcFZaUGhqNFZScy9ZNW05bXVHeFdrZkdYaDREL2tLUWY5 OTAzL2hOUEQzL0FFRklQKys2QU5UVHRLc05JdHZzMm4ya1Z0RjNFYTR6OVQxTldxd0Q0MjhPai9t S1FmOEFmVkovd20vaDdIL0lUZy83Nm9BNkROZWMvR3YvQUpGR3kvNitoL1N1ay80VG53NG95ZFVn L3dDK3E4MStMWGpEVHRkMHV5MDdTWGU0YU9YekpIVkR0WDBHY1VBZlJkaWY5RnR2K3VLZitnaXEy cm45N0dQOW11UDhQZkZMdzFkYVRhUE5lQzNtV0ZFbGltK1ZsWURCSE5YYjd4eDRjdVpBeWFyYmJj WTVrRkFHa0RTSG1zSStNdkRvL3dDWXRiZjkvQlRUNDA4T0EvOEFJV3R2Ky9nb0FibzNndlJOQTFG cit3aGxTNFpXVXM4cFlZYnJ4WFFBNE5jK2ZHL2hzZjhBTVd0LysreFRUNDQ4Ti84QVFXdHYrKzZB R0w0RThQSnJBMVJMTjB1aE41NEt5c0ZENXo5M3BYUjVybmYrRTY4TmY5QmEyLzc3cEQ0NzhOZjlC ZTIvNzZvQTZPdk0vakVmbThNai9wK1Qvd0JDcnAyOGZlR1Y2NnRiL2cxZVhmRlR4bnArdVhta3g2 U1h1RXM1UE5ra0NrRGRuZ0NnRDZhUS92VCtGWitxSC9TUVA5bXVXMHo0cStGYjIzam5Pb0pDekt1 Nk9VN1dVNDVCQnFTODhkZUc1NXpJdXJXd1hBeG1VVUFiRlluaUR3dHBYaWRZRjFPT1Z4QnVLZVhJ VTY5ZjVWQ2ZHM2hzZjh4aTEvNytDbW54eDRiL0FPZ3hhLzhBZndVQWJOcFp3V09udzJNS243UEZH SWxWem41UU1ZTllla2VCOUEwTFVsMUN3dFhTNVVNcXM4cFlMbnJnVXA4YytHaC96RjdiL3ZzVWg4 ZGVHUi96RjdiL0FMN29BdWE3NGMwenhIRERGcWNMeXBDeFpOc2hYQkl4MnEzcHVuVzJrYWREWVdT RkxlRWJVVXR1STV6MS9Hc2IvaE8vRE9mK1F4YmY5OTBuL0NlZUdmOEFvTDIzL2ZkQUhSMTVyOFNU L3dBVjU0TS82K2svOUNGZEkzai9BTU1JTW5WN2Y4R3pYbHZ4RDhiMk9xZU1ORXZOTDgyNHR0TmRa SGNJUnVJWUVnZmxRQjlPSWYzNy93QzlXYnFEWnZEOUJYT1dYeFQ4SjNhaWRkVGpRUHp0a08xbDlp RFRibngxNGFtbmR4cTlxQWVuN3dVQWJtYWFUWFAvQVBDYitHaC96RjdiL3Y0S2FmSFBobi9vTVcz L0FIMktBTmkrMDZ4MU9IeWIremd1b3gvRExHRy9LdU84TWVBWWRKMTNWYnkvc3JDVzNsbDNXU0Fi L0tYSjdFY2NZclhQanZ3eC93QkJlMi83N3BENDg4TS85QmkyL3dDKzZBT2kvU2tOYzMvd25uaGov b01XMy9mZEgvQ2VlR1ArZ3hiZjk5MEFkSFhtdml6L0FKTGo0Ty8zdjZWMGovRUR3c2d5ZFl0L3di TmVXZUt2SFZoZC9GUFI5YXNoTk5ZYWV5Ym5DRWJ1Zm13S0FQcHFJL3ZHL3dCNnMyOE9ieVQ4S3dM UDRtK0ZKaDVxNnJBRmJrQm4ya2ZVR281dkhIaHQ1bmYrMkxRYmovejFGQUc5bW01ckFQamZ3MFAr WXhhZjkvUlRENDU4TS84QVFZdGYrL2dvQTZITkptdWRQanJ3eC8wR0xYL3Y0S2FmSFhobi9vTVd2 L2Z5Z0RvczBtYTUwK08vREgvUVl0ZisrNlErUFBESC9RWnRmKys2QU9qelhsdmprQS9Fb2Y4QVhn di9BS0UxZFkveEE4S3hqTGF4YjQ5bXpYbkdvZUpMUHhOOFFMMi9zbVkyY1Zza0tTT051NzVqa2dI NjAwQm9xTUxYUCtJeGl5bHJlV1dJOENSUCsraFdMNG1oa1hTcEp5djdyKytHQkI1cWx1SjdIRE5V YkNuR1JmV2t5cEhGYjdra1ZNWTA5dTlSN0dib0tsZ1JQelZkaFZzeE42VTN5R1Bhb2FHVlZYSXE1 Q01KU0xBUjI0cVVMdDQ3VUtOZ0xjYmZMVGllS3FyS0ZPTzFQODhZclZNVmg3RGlvV0ZPTXlZNjB3 eXFlOUs0RER4VEdxUnlEMHFKd2NWSXlOalVMOGlwekd4N1Uwd3Y2R29hR1ZTS2NpL01QclUzMmR2 U3BFZ3huTkpSQW5oTzJTclFhcU9kdk5TQ2YxclJNa3N0MHFGaG1rTTYwd3pJZWxPOXdzTllVeXBO Nm5wVWJjNXFHT3hHMVJOMHFRaGljVTB4UDcxTFF5QWlrcWZ5SHhRSVdxYkFKQjBOWHJkc0EvV3F3 VFlEVGxrS0hIWTFhMEVYOTJhaGVveE9LUXpLUlY4d0NNS2lJcVF5S2FZMkNwSXFkQUdHbU1hZjYx SHRKcVdNak5KbjJxVHltTko1VENwc01abjJxUlB1MGdpYlBTbjdjREZOSUMzQTJJMXFiTlVVbDI4 SHBVZ3VBQldpbFlWa1V1YUtLS3hHS0tlQnpUVkZTQWMxU1FtUFU0cVVHb3U5UEJxa0luVUExSUVC cUtPckNpckM1RThlVGpIRlZuQURFVm9tcUUzK3NhaVFGVm5KYkhhbTdxUnZ2R2s3MWl4anh6VHdL WXZTcGxGTkFPVGlwSXppbUNuTFZJVEoxd2FrVUROUW9hc0pWb1F1d1lxS1NNYlMyT2FzQVUyWVlp YjZWYldnRkdvQzVQV3B6VkppYzFpOUNoNFlrOTZlTWsxQ3RUcFVwc0dQVVZLb3hUVkZQRldoTWtR NHFSZXRRZzFLbldyRVNnVThwZ2NDa1RrVklCeFZwQVZwSXdCdXhWYVZpcThWZW1HSTZ6cm43Z3g2 MUV0QUlqSms5YUFjbW9jMUlsWlhLNkU0NTZVOVJUVkhGU2dZclJFangycVZhaUZQQnFnSmhUZ0JU RnFVQ3FRRFN1ZU1WR01MT25wbXJCRlZwUmhxSkxRU1BvVHdoYVcxenBuNyszaW02RDk0Z2JzUFdy MnMrSE5FaGhodUYwMkpXMzdTSXpzQjQ5cXh2Qm11YVhhNlJFTHJVTGVGbVJXL2VTQWZ3aXRueEQ0 aTBkZE9nQ1g4RXhhWEk4bHcvR1BhdVZtaGx5YUpvVW9HN1N3Q082eWtHb3YrRWMwRC9vSFAvd0NC RFZEL0FNSkhwWS81Ym44UlIvd2ttbFkvMTUvS2tCTC9BTUk1b0gvUU9mOEE4Q0dwZitFYzhQOEEv UU5rL3dEQWhxaC80U1RTL3dEbnVmeW8vd0NFazByL0FKNy9BS1VBVGY4QUNPZUgvd0RvR3lmK0JE VW4vQ09lSC84QW9HeWYrQkxWRi93a21sZjg5LzBvL3dDRWswci9BSjcvQUtVQVRmOEFDTitIL3dE b0hTZitCTFVuL0NOK0g4ZjhnNlgvQU1DVy93QUtpLzRTVFN2K2UvNlVmOEpKcFgvUGVnQ1VlR3ZE NC81aDB2OEE0RXQvaFRsOFBlSGxQL0lNYy9XNWFvUCtFazByL252U2Y4SkpwWC9QZjlLQUxqNkg0 ZWYvQUpoRzMvZG5ZVXovQUlSN3c5LzBDMy84Q21xdC93QUpMcFEvNWVQMG9QaVhTZjhBbjVvQXMv OEFDUGVIZitnVS93RDRGTlNmOEk5NGQvNkJVbi9nVTFWLytFbTBuL241by80U1hTZitmbWdDei93 ajNoMy9BS0Jjbi9nVTFIL0NPK0hjZjhncVQvd0thcTMvQUFrMmsvOEFQelIvd2t1bGY4L05BRmov QUlSM3c3LzBDNWYvQUFLYWovaEhQRHYvQUVESmYvQXB2OEtyL3dEQ1M2VC9BTS9Jby80U1hTZitm bWdDY2VIUERnLzVoa3AvN2VtL3dxUmRBOE9LZitRUTdleHVtcXAvd2t1bGY4L0lvLzRTWFNmK2Zt Z0M4K2llSEpEbit4dHYrNWNzS1ovWUhodi9BS0JEL3dEZ1UxVlArRWwwbi9uNUZIL0NTNlYvejhp Z0MzL1lIaHYvQUtCRC93RGdVMUg5Z2VHLytnUS8vZ1UxVlA4QWhKZEsvd0NmbWovaEp0Si81K2FB TFgvQ1ArRy8rZ1RKL3dDQlRVZjhJLzRiL3dDZ1RKLzRGTlZYL2hKZEsvNStCUi93a3VrLzgvSW9B cy84STk0Yi93Q2dUSi80RnRRZkR2aHovb0ZTL3dEZ1czK0ZWdjhBaEpkSngveDhpai9oSmRKLzUr UlFCWkhoM3czL0FOQXFVLzhBYjIzK0ZQVFF2RGFObit4bWIvZXVtSXFuL3dBSk5wUC9BRDhpai9o SmRKLzUrYUFMMG1pZUc1R3ovWW0zL2N1WEZOL3NEdzMvQU5BZC93RHdLZXFmL0NTYVYvejhpbC80 U1RTdW4ya1VBWFA3QThOLzlBZC8vQXA2VWFCNGIvNkE3ZjhBZ1UxVkI0ajByL241RlNEeERwZi9B RDhpZ0N5UEQvaHovb0VQL3dDQlRVNGVIL0R2YlNYL0FQQXBxcmpYOUxQL0FDOENwVjE3VE1mOGZB b0FsSGg3dzkvMENwUC9BQUthbmp3LzRmOEErZ1pKL3dDQlRWR05jMDMvQUo3aW5qVzlPLzU3MEFQ WHcvNGZIL01Na1A4QTI4dFVzZWk2QkcyZjdJM2V6WERHb1JyZW5mOEFQY1V2OXQ2ZC93QTl4UUJP K2phQXh6L1pHMzZYREFVMyt4TkI3YVUzL2dRMVIvMjNwMy9QY1VmMjNwLy9BRDNGQUVoMFBRUCtn VTMvQUlFdFNIUTlBLzZCVGY4QWdTMU0vdHZUditlNHBQN2IwNy9udUtBSEhRdkQvd0QwQ20vOENX cHAwRHc5L3dCQXAvOEF3S2FqKzJ0Ty93Q2U0cHAxclR2K2U0b0FhZkQzaDMvb0ZQOEErQlRWRzNo enc3LzBDcFAvQUFLYXBEcmVtLzhBUHdLWWRiMDMvbnVLQUdmOEk1NGNIL01KbFAxdW1wMGVoZUdv bXovWWUvOEEzN3B6VFRyZW0vOEFQd0tZZGQwenZjQ2dCWDBEdzB4Si9zUXIvdTNUaW9UNGE4TWsv d0RJSWwvOEMycHgxN1RQK2ZrVXc2L3BmL1B5S0FEL0FJUnZ3ei8wQjVQL0FBTGVsLzRSend4LzBC cFAvQXg2Wi9iK2wvOEFQeUtQN2Ywdi9uNUZBRC8rRWQ4TWY5QVdUL3dNZWovaEhmREgvUUZmL3dB REhwbjl2NlYvejhpay93Q0VnMHIvQUorUlFCSi93ajNoai9vQ04vNEZ2U2Y4STk0WS93Q2dHMy9n WEpURDRnMHIvbjVXbS84QUNRYVYvd0EvSzBBUy93RENQZUYvK2dHMy9nVzlPajBMd3ZIL0FNeSty Zjc5MUlhcm54QnBRLzVlUlRENGgwci9BSitsb0FtZnc3NFdjLzhBSUNZZlM4a3FFK0dQQytjalJw Znd2Ry93cHA4UjZTUCtYcGFZZkVta2Y4L1MwQVAvQU9FWjhMRC9BSmdzbi9nYTlIL0NOZUZCL3dB d1NUL3dOZW9XOFM2UC93QS9hMHcrSnRINmZhMW9Bcy84STM0Vi93Q2dFLzhBNEdTVW4vQ04rRTgv OGdGdi9BeVNxdjhBd2sramovbDdXay80U2pSLytmdGFBTGYvQUFqZmhUL29BdC80R3lVdi9DT2VG RC96QUQvNEd5VlQvd0NFbjBmR2Z0aTRvLzRTalJ4L3krTFFCYi80Unp3cC93QkFBLzhBZ2JKVXNl ZytGSXdSL3dBSTRqWi92M1VoeFdmL0FNSlJvMy9QNHRIL0FBbEdqZjhBUDRsQUZwdkRYaFJ2K1lD dytsN0pVZjhBd2l2aFgvb0RUZjhBZ2EvK0ZRZjhKVG8zL1A0dEE4VWFOL3orTFFCWS93Q0VXOEtm OUFTUS93RGI2OUtQQy9oTWY4d04vd0R3Tmtxdi93QUpSbzMvQUQrcFIvd2xPamY4L2lVQVdmOEFo R1BDZi9RQmMvOEFiN0pTL3dEQ00rRS8rZ0MzL2daSlZYL2hLTkcvNS9Vby93Q0VvMGIvQUovRW9B dGY4SXo0VC82QUxmOEFnWkpTL3dEQ00rRS8rZ0MzL2diSlZUL2hLZEYvNS9VcFI0bzBVbi9qOVNn QzEvd2pQaFByL1lKLzhESktrVHc5NFRSQ3YvQ09JMmU3WFVoTlVmOEFoS05GL3dDZjFLWC9BSVNu UmY4QW45am9Bc3Q0WDhKdC93QXdKaDlMMlNvLytFUzhLLzhBUUhtLzhEWHFML2hLTkUvNS9vNlEr S2RFSC9MOGxBRXc4SitGQi96QlpELzIrdlR2K0VWOEo5UDdEZjhBOERaS2dIaXJSUDhBbitqby93 Q0VwMFQvQUovby93QTZBSi8rRVY4SmY5QUovd0R3TmtwMy9DTGVFLzhBb0JOLzRHeVZYSGluUk1m OGYwZEwvd0FKVm9uL0FEL1IwQVdQK0VXOEovOEFRQlAvQUlHU1VmOEFDSytFL3dEb0FuL3dNa3F1 UEZXaWY4LzBmNTB2L0NWNkovei9BRWRBRmovaEZmQ2YvUUJQL2daSlVnOE4rRkJIcy80UjJNKzV1 cE0venFuL0FNSlZvbi9QL0hUaDRwMFVqaStqb0FsYnduNFRiL21Cc1BwZXlVei9BSVE3d3IvMEI1 Zi9BQU1lbS84QUNVNkovd0EvMGY1MGY4SlRvbi9QOUhRQThlRVBDZy81Z3NoLzdmWHB3OEkrRS84 QW9DUC9BT0JrbFIvOEpUb24vUDhBeC9uUy93RENVNkovei9SL25RQklQQ1hoUC9vQnQvNEdTVWY4 SWw0VC93Q2dHMy9nWkpVZi9DVTZKL3ovQU1mNTB2OEF3bE9pL3dEUC9IK2RBRW4vQUFpWGhQOEE2 QVovOERKS1VlRXZDZjhBMEF6L0FPQmtsUkR4VG9uL0FEL3gvblMvOEpUb24vUC9BQi9uUUJKL3dp WGhUL29CL3dEazVKL2pWaVB3NzRXaWoySjRlaSt2MmlUSi9ITlUvd0RoS2RFLzUvNC96cHc4VWFL UnhmeDBBYk5qNGEwS1BmSkhwVnZ5M3lpUWVadEdCeGxxNDM0a3d3MitqM1NRUlJ4SnRRN1kxMmpx ZlQ4SzY2MThVNkVsdHVmVmJaTXQwWjhIb08xY1I4UnRWc2IzUXJpUzB1VWxWekdpNFBYNXZTbWdQ SWQ5UFNRNUdEVURHbGp6dUZXbVNhSzhrQ3AxVEhTb0kvdkxWd0FWdEZDSXl2SEZOSXhVcHFGODVw c0JoTlJ0MXA1TlJtcFlFVGprMUcyUlV6Q29YcUdNaVpxUVBUWDYwek9LaTR5NUU1WnNWWmpVRTgx UnRzbDYwYmZ2VndFeDRRVU1vQTZWTGp2VWJkSzFhRVF0VEdiaWxjODFHVFdiWURHNlZDM3RVeDZV eGhVc1pDeE5SN3FrZW9UV2JHaVJYSTVxeWh5dFVSVnlMN29xa0RMYXhnY2djMC9aZ2M5YWZIOTBZ cFdGYktPaEpDMkFNVkV4cVNTb0NhbGpHdlVUalBlbm1rUFNvQkVKR0tZVFVqVkUzV29aUVpPYWVq SE9PYWpwMGYzeFFnTEhjVllXUDBxdi9FSzBGQTJqRmF4UkJFVXdPbFJNTVZaYXF6ME5ESTJxSnV0 UFkwdzgxTFl4akNtR3BUVVo2MUlEYVR2UzBWSXg2MUpVYW1uaXFRaHdwNjB3Y1U5UlZDSjR1b3F5 dFZveHpWaFRpdEVJZTMzYXo1ZnZtcnhhcVV4ekkxS2V3eW0zM2pUYVZ2dlVsWVBjWTlhbVVWQ3RU S2FwQVBwUjFwQlRscWtJa1RyVmxPMVYwcWRLMFFpZGV0Unovd0NyZjZVOGNWSE0zN3R2cFZNQ2tl OVVtNjFkNjlLcE1EazFqSW9GcWRLZ1RpcDFxVUJNdFA3MUd0U0NyUWhSMXFWS2pXcFZGV0luVHBV b3FKS2t6aXJRbVJUZmNyUHVPZ3JRbVB5R3M2NUdVR0tpWXlyM3FST3RNeGcxSXZXc1VVV0VxVVZD aHFVSDJyUkVqKzlPSFdtaW5yVm9DVk9sU3JVUzFLS3BBUDdWVmwrOW1yT2VLclRjdHhReEk5UzhN MmxuZGFGWlBOWjI3TTBLNUpqVW5wOUtuMVRTckNGRWVHMWpRazRPMFlGVnZCcjU4UDJuYkNFWStq R3RiVlBtdDAvMzY1bVdYZkRYZ1R3dHEraUplNmxvMGQxY3ZMSXJTTkt5OEsyQU9ENlZxLzhBQ3NQ QkgvUXV4ZjhBZitUL0FCcTM0SFAvQUJUZTMrN2RTai8wRS8xcm84Vkl6a2YrRlgrQ1AraGVpLzcv QUwvNDBuL0NydkJQL1FBai93Qy96LzQxMStLS0FPTy80VmI0S1A4QXpBa0gvYlpxVC9oVmZnci9B S0FpL3dEZjVxN0xGR0tBT04vNFZWNEwvd0NnS3Y4QTM5YWsvd0NGVmVEUCtnTXYvZjFxN09qRkFI R2Y4S3E4R2Y4QVFHSC9BSDlhbngvQ3p3VUhYZG9hTnozbWF1d3hRTUJoOWFBUEVQQXZ3cDB6eEpQ cmQvZmwwdExiVVpiV0NDTmlPRlAvQU5jQ3UxLzRVbjRTL3dDZVUzL2ZkWHZoYzJ5MThWMmhIelE2 L09md2JCRmR3S0FQT2Y4QWhTZmhQL25sTC8zM1NmOEFDa3ZDbi9QS1gvdnF2U0tVVUFlYmY4S1I4 Sy84ODVmKys2VC9BSVVoNFgvdVMvOEFmVmVsMVgxQy90dEswNjR2N3lVUjI4Q0YzWStuK05BSG5S K0IvaG5zc24vZlZKL3dvL3cxbm56QVByWG9XajZ0YWE3cEZ2cWRoSnZ0NTEzRFBWVDNVK2hCcThR R0dLQVBNaDhEUERBNithYVgvaFNYaEplcVRIOGE5T2hPY3h0MUhUNlVTdzBBZVh0OEYvQi85eWYv QUw2cnp6NG4vRFhUUEN1bFJhanBra3BSbjJzci93Q2Zldm9lU1BGZVpmSEJjZUJVL3dDdXcvbUtB SzNoNzRJNkMyaVdVK3BQTExjendKSytHd0FXR2NmcldyL3dwUHdsL3dBOHB2OEF2cXUrc1A4QWtF MkdQK2ZXTC8wRVZXMXJYTk84TzZlYjdWTGtRd2c3VjdzN2VpanVhQU9LL3dDRkplRS8rZWN2L2ZW Si93QUtSOEtuK0NYL0FMNnFhMStNbmhpZTZFTWlYMXVoT1BPa2lHMGZYQkpGZWdRelJYTUVjOEVp eXd5S0dSME9Rd1BRaWl3SG5IL0NrUEMzOXlYL0FMNnBQK0ZIK0dPeXlmOEFmVmVtVW9vQTh4LzRV ZjRhL3V5Zm5UaytCdmhoaG45NVhwdElHOHQ5L3dERDBOQUhtMy9Dai9DaTlVbFA0MGY4S1c4SUwv eXptL092VW1qRExrVlZraUlvQThyMUQ0SytHR3M1amFtZU9WVUpYbjBGY044Ti9oelorSWRTMWM2 akkvMmZUNUJFRkIrOHhKL3dyNkVrVEVVdi9YTnY1VjUzOEpWQ3Q0cjk3OWY2MEFYVStFM2hWUnhG TC8zMVVxL0Nyd3dPa1VuNTEyUUdLZUJRQnhvK0Z2aHdEaU9UODZjUGhkNGU3TEorZGRtQlNpZ0Rp eDhML0Q0UEljVS8vaFdYaDcvcHBYWW5wVGNVQWNnUGhsNGU5SktYL2hXZmg3MGtycjZLQU9RLzRW bjRlOUhwZitGYWVIdlNTdXVvb0E1SC9oV25oLzhBMjZRL0RQdytmNzlkZlJRQng1K0dQaC8vQUth VTAvQy93OGYrZWxkbCtGRkFIR0g0VytIVC9mcHArRlhoczlwSzdXakZBSER0OEtmRFI3U1V3L0Nm d3o2U1YzQkZOSW9BNGIvaFUvaG4vcHBSL3dBS244TS85Tks3Y3JTWW9BNG4vaFUvaGdkcEtYL2hW UGhqMGtydE50R1ByUUJ4Zi9DcVBESHBKUi93cWp3eDZTVjJtS0tBT0svNFZQNFk5SkthZmhMNFdQ OEFESlhiWW94UUJ3emZDTHdxZTBsSC9DbWZDckRQN3pGZHZpcmFqQ0xRQjUyZmd0NFQ3ckxUVDhG dkNQZEp2enIwVWltR2dEejMvaFRIZy84QTU1ei9BSjB4L2d2NFBaU29XNFUrb2F2UWlLYVJRQjgy bjRidy93REMyWXZDaXp2OWxrK2ZmM0M0Si9wWHFFZndXOEpJb1YxblpoMzMxVUEvNHlTdEQvMDV2 LzZDMWVvaGZtb0E4OS80VXQ0U1BTS2IvdnVtbjRLZUZ1MFV2L2ZkZWtvbFBaZHEwQWVaZjhLUzhM bnFKRi9ITklQZ240VkhWcGZ5cjBjbkp6VERRQjUzL3dBS1Y4SitzMUwvQU1LWDhJanRQWG9ScHBv QTREL2hUUGc4Znd6L0FKMGY4S2E4Ry8zTGo4NjcwajYwMDBBY0gvd3B2d2IvQU04N2ovdnF1SCtK Znd3MGp3NzRlT3I2UkxNQWpxcnh2NzE3a2E0bjR1ZjhrMnZmK3VpZnpGQUhQK0VQZzVvVjk0WjAv VWRUZVY1cnVGWnNLM1ROYi84QXdwZndnZWtVMy9mVmRaNFdYL2lpdEEvNjhJdjVWc29sQUhuSitD bmhUK0dPYi92cW0vOEFDa3ZEQjZKS1ArQlY2WUU0cGpIbmlnRHpiL2hTUGhiKy9KK1ZML3dwTHdv T3BscjBidFZMVk5SdHRIMHk0djcxOWx2QWhkajNQc1BjOUtBT0cvNFVyNFNIL1BhbC93Q0ZMK0Qv QU83T2Z4cnR0TTFLMTFqUzdmVWJLVGZienB1VTl4N0gzRldhQU9BLzRVeDRPSDhGeCtkSC9DbXZC djhBenp1UHpydlRUY1VBY0czd2I4R2xTUEx1QWZVTlhHVzN3MjBqU3ZpM1phTmN4bTkwdTZ0cEpW amtZZzVDazl2d3IyNGl1R3ZTSnZqcHBzWS81WWFaS3gvSEFvQTBqOEpQQkxkTkdVZjl0Vy94cFA4 QWhVUGd2L29FRC92NjFkd280cDFBSERENFErQy8rZ1FQKy9yVW8rRVhnci9vRHIvMzlhdTVBOTZL QU9IL0FPRlJlQ2YrZ012L0FIOWFuRDRSK0NmK2dJaC83YXQvalhiZ1V1S0FPSUh3ajhFZjlBT1Av djYvK05ML0FNS2s4RC85QUdQL0FML1AvalhiVVVBY1VQaEw0SC82QUVaLzdiU2Y0MWgrSS9CK2cr R1pMYit4dFBTMDg5VzgwSzdOdTJrWTZuM05lcFlyaC9INUJ1N0ZjOUltUDYvL0FGcVlNNGsyOFI2 eG9mOEFnSXJqL0hFY1VXbGpiR2lzMHFqSVVaNkd1Mnh4WEVlUFQvb0VLNS81Ymc0LzRDMU5DWjU4 M1duUW41eFNOaWhGdzFPd2pTakh6TFZ4ZWxWSXVHV3JZTmJ4MkVJMVFQM3FjKzlSTUtZRUJwdFBZ VXlvQWExUXYwcVZqVVRtb1l5dTlRbnJVelZHUnpVRFJZdGZ2Vm9XL1Uxblc0eEorRmFWdWZsclNB bVdEMHFKNmVXelViVnFJZ2ZyVVJxWmhVUkZac0JwcGhweHBqR29ZeUdRVkFhblkxQzNXb1kwSUt1 eGZkRlVnTWlya1ErUVZVUm1qRjBwemRLYWgrVVVySGl0a1FRU1ZYYXJEMUF3cVdCR2FROUtVOFUw bmlvZTR5TnFpYXBXTlJOVU1ZbE9qKytLYlRvL3ZpaERMR1BtcStnK1dxSVBOWGxiaXRZRWlOVlo2 c3QzcXU0cHNDQnFiVDJwbFpqRUlxTTFJeHFNbm1rQTM4Nk1WYkNLZTFQRVNlbEhLQlNIQjZVNEht cnZrRHFCVWJRY1UrV3dEQjFxVURGUWs3UlVabFk5NkxnWGxJSGVwTitLekJLOU8zdC9lcXVZVmkr MHRWMk81cWdCSlBVMUl2UVV1YTR5TjQ4VkhzT2F2TGdpbkNOVDJwY29paW81cDR5RFY0UXA2VXBn VURwVktEQXFMbk5TcFNOSDVaNHBqU2VXS1d3RnBjVTlXck44NCt0S0pYendhZk1GalUzOFZGSkp4 dDlhcEIyOWFlcHl3enpUNWdIOXFnYVBIYXJBNjFLQUc2aWsxY0NnRTlxZXVhdkxHcDdVL3dBaGZT bW9BVVJrR3BVNlZZTUtqdFVUSnNiRkZyQU9RZkxVb3dLcVBMdE8zRlJlYytldEhOWUxHbUdBcHhm anJXV0pISjYwOFNONjFYTUt4YmtmNWNWQkltNWFhcE83bXBWR0tXNEZRcDdVQlNPMWFHMVQycHl4 SWUxSElNb3FDS2tVNDdWYzhsZlNtTkNEMEhTbW9pSXhVb0ZRazdCVVRURTk2TmdMeTAvT0t6Qk8v clRoSy9yVDVobWdYcUZtM05VRzVqVDFCeFJlNGowdndUTG5SSWx6eXJNUC9Iai9BSTEwRjk4MXYv d0lWeVBnbWIvUVhUZDkyVThlbkFyclovbWhhc1h1VWpxL0FqWjBhNlQrN2RFL21pLzRWMUZjajRE ZkNhakQ3eHlEL3dBZUgrRmRmaXBHSlJTNG9wQUppaWxvL0NnQk1lOUxpakh0UlFBWXBNVTdGSmln RGp2QmpHdytKZmpQU24rVVhRaDFDSWVvSXd4L00xM2xlZCtKNVI0YitJWGh6eE9mbHRKaTJsM3Jl aXZ5aFAwT2Z5cjBWbDJzUlFBbExTVVVBT0hOZVNlTWRRdWZIL2k2RHdmbzhoRmhiUHZ2WjE1R1I5 NC9SZWc5V05kRDhUdkdYL0NOYUtMS3pmR3FYcWxZOGRZMDZGLzZELzYxTDhMdEkwclNOQlpiUyt0 YnpVcHRzbDY4TW9rS0UvZFRqc09mcWMwQWMzNGR1Wi9obDQzazhPNmpLemFKcURiN1dkK2lrOEsz L3NyZmdhOWY2R3VPK0kyamFYcm5oczIxL2VXMW5kcVMxbk5QSUVIbUFmZHlleEhINVZuL0FBcjhZ LzI1cFowZS9renFkaXUzY1d6NTBRNERlNVhvZndvQTc5OGpEcjk1ZWFzcktycXA3TUtyOXFoTEdO SkIvZCtZZlR2UUJabWl5SzhwK09vMitCMEgvVFlmekZlcTI4d21qOVRYbDN4N0dQQmFmOWRSL3dD aENnRDBMVHYrUVBZZjllc1gvb0lyeGI0cTNFMnMvRUt6MFFPUkRFSW9sQS92U0hsdnlJcjJqVFAr UU5wLy9YckYvd0NnaXZGZmlaRytqL0UrMDFXUlQ1TW5rWENuMTJFQmgrbjYwQWR2NDY4RmFMSDRD dWxzdFBnZ21zSXZNaGxSQUgrWHFDM1U1R2V0VlBncnFjdDE0WnU3Q1J5d3M1eDVlZXl1TTQvTUg4 NjNmSCtzMlVIdysxQzVTZU4wdklQTHR5R3o1aGYwL0RtdWIrQ0ZqSkZvT3BYckRDWEZ3cUlmWFl2 UDZ0VEE5U29GSEZGSUJ3cENNakJvb05BRWx0SmhTamRWL2xVeEFkZUtwSDVKVmJzZmxOTGIzQkVw alk4ZzRvQUxoTnNFdis0MzhxODMrRkl3L2lrZjlQNi8xcjA2N0graVRIL3BtMzhxOHorRll4SjRu LzYvaC9XZ0QwQUNuQVVncDJLQUZwUlJTaWdBYnBUYWVlbE1vQUtLS1hGQUNZb3hTMFVBR0tLclhP bzJOazRTN3ZiZTNkaHVDeXlxaEk5ZWFuUmtrUlhSZ3lNTXF3T1FSN1VBT294UlJRQW1LS1dpZ0Jw cHBGUHB0QURDS1Fpbm1tMEFNeFJpbVRUdzIwVFMzRXNjTWE5WGtZS0IrSnB0dmVXdDRwYTB1WWJo Vk9HTVVnY0Q4cUFKYUtYRkppZ0F4NzBoRkxSM29BYjNxMkI4b0ZWbEh6Z1ZiTkFEQ0tqTlNHbUdn Q05xWmlwR3Bob0E4eVRuOXBLMC93Q3ZOLzhBMEZxOVlXUG12S0kvK1RrclQvcnpmLzBGcTlpamo1 b0Fha1dCVlM1Yk1td2RxMDVNUlFzL29Ld3BabzRZM25ua1dPTkFXZDNPQW85NkFKRHhUVFhLZjhM TThJbTY4aisxaG5PTjVpYlovd0I5WXEvZitNTkIwMjR0SUxxL1ZHdTFEMjdLak1raWs0QkRBWTYw QWJacHBxdHFlcFdtajZmTmYzOHZsVzBJeTc0empuSFFmV3NlWHh2b0VPaFI2ekpjeWl3bGxNU1Nl UTJXWWRlTVo3SG1nRGZOTnJsOVErSXZoalRab29acjUzZVJGZkVVUmJhR0dSdTlPdlNwZFY4ZWVI Tkl0N2FhYSs4MFhLQ1NKWUYzc3kvM3NkdnhvQTZFMXhQeGQvNUp0ZWY5ZEYvblhUNlByZW5hL1lD OTAyZnpZYzdUa2JTcmVoSGF1WStMMy9KTjd6L3JvdjhBT2dEc1BDYTd2Qk9nZjllRVg4cTNZNHF5 UEJxYnZCR2cvd0RYakYvNkRYU1J4OFVBVTdqRWFlNXFwVXQzSnZ1Q0I5MWVLaDlhQUN2SnZGTjVQ OFFmR01QaGJUSlNOTXMzMzNrNmRDUnd4L0RvUGV1ZytKbmkvd0Q0UjdSL3NObEpqVTd4U3FFSG1L UG9XL29QL3JWSjhOOUkwM1J0QU1WcGVXMTNmU2JYdkpJWlJKdFk5RXlPdy9VNW9BNW53MWR6L0R2 eGpMNGExT1VuU3J4dDlyTzNSU2VoOXMvZFB2WHF4NHJqL2lQcFdsYXY0ZkVOL2VXMW5lSnVlemxu a0NaWWRWNTdIL0NxZnd6OFgvMjdwUjB5OWt6cVZtdU1rLzYyUG9HOXlPaG9BN3MwMmxwS0FCVjNP cStwcmdQRGhHcmZHZnhEcUs1TWRsYXBhZys3TnUvcFhhYXBxRU9rYVJlYWpjTUZqdDRtY2srdUs1 ajRSYWROSDRabTFpNlVpNTFlNWU3YlBVS2VFL1RuOGFBUFFWRk9GQUhGTGlnQXh4UzBVdEFDVXRG THpRQWxMUmlsb0FTdUQ4ZEhPcVFML2RoSC9vVFYzdGVkK01YRDY5SVA3cXF2L2pvL3hwb0RteU9P MWNCNDljRVdzZnF6TitXUDhhOUNrNFExNTc0dVpaTHlKQ003Vkp6OVQvOEFXcTRxN0V6aWZMT2Vs U3h4WllWZUtMNkNta0FBNHJUa0pJMU8xaFZoWHpWYnNhaTNNdlEwWHNCZkxERk1KRlVXbFlEZzB6 ejNIZWpuQXZzS2lPTTFXRTdkYzFPRzNya1VyM0dST2VhaklKN1ZkU0hQekhrMC93QWdZbzViZ1pi Sms5S1FKZzlLMURFZzdVd292cFM1QXVWWW85cHppckVUN2VLSDZWQy90VDJBdWh4VFMxVVM3RHZU RE0vclJ6Z1h6aW8ySEZVdlBiUFdwRm1QU2x6WEN3ODlLaWJtcGd1NGdDcGxnQTdVY3R3TTlsTk0y WnJVOGhSMnBwaVgwcGNnR2NzWnF3b0tyVStGWHRVVGUxRnJCY21qbHlLazh3WTYxbm5JWW5KcHBk c2RhZk1GalFZNXFNNE5Vdk5iSFdrRXB6MXFlWUxGaHhVYmNFVXF5Ynh6VDBqOHpuMG9zQlhQTlJr R3RJUXFlMUlZVkhhaHdZMFp1MnBJMDV6VnN4cU8xTllBTDBwY29FZmVyQ3lBOTZybnBVZVdYcFJl d0Y4eVpxTmlEVkl1dzcwbm1NZTlITUZpMndGUk1NR29oSTNjMC9kdTVwWEFhM3BURG1yS3haRzd0 VWdoWEhUODZmS0F4VFU4Zk5WMHF4RlZJUk1CbW81aHNqTFl6aXBnS2JOd3RXOWdNeG15dlNvcW5m N2xRVmd5Z3B5aW1kNmtXZ0NRQ25nVWdwMVVKamxPS2xRMUNPdFRKVklSWVFacCszaW14OUtsQXJS Q0tGMCsxZ05oUHZWU1Y4a2NZcS9kZEZxaFAwRlp6S1JEVDBwbFBUcFdmVVpNbzVxUlZwaTFLS3Nr T2hxUlR6MXFQdlQxNjB4RTZWT29xdW5XckNWb2dZcFhKcWhQTGlUSGx0V2ovQ2FwM0grdHo3VVNX Z0dmSytYKzZSVVlKelV0d1AzaCtsUkwxckJsRXlWTW9xQk90V0Zxa0llQlR4VFJUaFdnaVJUVXkx QXZXcDFxa0JLQnhVY3plVkdYMmx2WVZJS0c2VlFyR1k4L1VlVzQrdFZTMWFFblExbk53eHJubHVV aHluSnFkQnpVQ1ZZU2hBeVpWcDRGTlduOTYwUWpwL0JzK3k1bmpKeGtLMzg2NzdPNkw4Szh2OFBU K1RxeWM0M2dyL244cTlLdDMzUkNzNTdsSFJlQ1pQTDFxV0luaVczWWZpcERmNDEzZjRHdk4vRDh3 dGRmc3BTY0w1dXh2bzN5L3dCYTlLMjQ0OUtoakc0b3hTNFByUzRwQU54UzRwY1VVQUppakZMUmln Qk1VWXBjVVVBWS9pYlFvUEV2aDI4MG1maFo0OEkrUHVPT1ZiOENLelBoejRsbTFmU3BkRzFiTWV2 YVFmczkxRzNWMUhDdVBYSS96elhWWXJoZkd2aG5VRjFPRHhiNFl3bXVXYTRsaEhTN2k3b2ZmSCtl QlFCNkhtaXViOEllTXRPOFhhYjUxdWZKdTR2bHViU1E0ZUYrNEk5UGV1ai9BRG9BNS9WUEEzaHpX OVFlKzFIVC90RnpKZ001bWNjRG9PRFhJL0N1MWhzZkUzaTYxdDAyUXczQ3h4cG43cWhwQUJYcHdQ TmVVandoNDgwcnhCcTk5b041WVFSWDl3MGgzT0NXWGNTdlZlT3RBRnY0eFFwY3I0YmhrR1Vrdnlq RDFCMml1bTAzNGUrR3RHMU9MVU5QczVZTG1Gc282M0QvQUpFWjVGY1JmK0V2aUZybDVwN2F6YzZm UERhWEN5cUVrVlNPUm5vdlBBcjEwdGxqUUE3TlJTajk0djhBdFpXblpxSzRPSTgraHpRQlUwMmNw TTBaUFExd2Z4N09mQnlmNzYvK2hDdXpIN3ZWNUFPaGJQNTF4WHgzL3dDUk1qLzMxLzhBUWhRQjZI cGYvSUYwL3dENjlZdi9BRUVWbitKL0N1bStMTk5GcGZxNnNoM1JUeDREeHQ3ZjFGWDlLLzVBdW4v OWVzWC9BS0NLdGlnRHltMytDTVgyaEJkYTlQTGFLZjhBVnBEdGJIcGtrZ2ZsWHArbmFmYTZUcDhG aFpSQ0cyaFhhaUQrZjFxeG1pZ0IyYXcvR0hpTmZDdmh1NDFUeVJOS3BXT0tNbkFaMjZaOXU5YlJP Rko5Qm12SlBISGlOUEZmd3BPb3BiRzNDNmtzWGxsdDMzZDNPZnhvQXpkQStNT3Mvd0J0UXByQ1cw MWpOSUVjUlJiR2pCUDNnZStQZXZjT00xOGh3ZjhBSHpEL0FOZEYvblgwOUY0bGlmeG5KNGErek9K WTdOYm56OXcyOXZseCtQV2dEYms1UTFRbmxNZDhyZE42ZzFlWThWbDZod3NMK2haYUFOaWFUZHAw eC82Wm4rVmVjL0MzL1crSi93RHI5SDlhN3hIM2FYTWY5ZzF3Znd1LzF2aWIvcjlIOWFBUFFCMXA0 cG9wdzYwQUtLVWVsSUtXZ0JhWlQ2WVJ6UUF1S0tCUlFBVVVVVUFlSC9ISlFmRU9tNS81ODIvOURO ZXZlR3gveFMrbGY5ZWNQL29Bcmd2aWg0SzF6eFJyRmxjYVZieFN4Ulc1amN2TXFmTnVKNkdzQ0x3 bjhVNElVaGh2NWtqalVLaUxxQzRVRG9PdEFIdDJLWEZlSi84QUNNZkZiL29JM0gvZ3dYL0dqL2hH UGl2L0FOQkc0LzhBQmd2K05BSHRtS1RGZUtmOEl4OFZ2K2dqY2Y4QWd3WC9BQm8vNFJqNHIvOEFR UnVQL0JnditOQUh0ZUtRaXZGZitFWStLLzhBMEViai93QUdLLzQwaDhNL0ZZZjh4RzQvOEdDLzQw QWUwa1UzRmVNZjhJejhWZjhBb0kzSC9nd1gvR20vOEkxOFZQOEFvSTNIL2dlditOQUhjL0ZCYy9E elUvVDkzLzZHdGM5OEV4alF0VngvejlML0FPZ1ZnWG5nMzRsYWhhdmJYbHpKUGJ2OTZPUytVcTM2 MTJ2d3k4TmFuNFowdS90OVZoamlrbW5WMENTQjhqYmp0UUIzRkZGSlFBVUdpa29BZkVNeWlySnFD QWRUVXhOQURUVERUelREUUF3MDAwNDAwMEFlWlJIL0FJeVR0UDhBcjBrLzlCYXZhWTFyeFdML0FK T1R0UDhBcjFmL0FOQmF2Ykk2QUsycFBzdGd2OTQ0cmgvSFdrWHV1K0Q3MncwOC93Q2t2dFlJVGp6 QXJaSy9qWFlhcy83eU5QUUUxekhpYXcxWFV0RGt0dEYxQVdONFdWaEtSMUEvaHovRDlhQVBJOU0x N1Q5RTA1TkM4VmVEMDJLQ3JYQWkyVEgvQUdqbnFmY05YVC9FVFNiRFZ2aDlZYXJvb0gyZXhWV2hL REI4bHNLUitCeCt0UWFybzN4RjhTYWVOSDFXUFRSYmIxTFhPVnljZCtPZnlBcnVyRFI3SFNQQ3NP aDNFeXRhcmJ0Qzd5RUx2eUR1UDZrMEFlY2VNdkVjbXY4QWdmdzdZV3piN3ZVV1h6Vkg5NVBreC8z MS9LcjN4TjAyTFJ2aDNwR213L2N0NTBUNm5ZMjQvbm11ZStGK2pDLzhZTmNsekxaNlh1ZU5qMExF a0pqOVdyMFA0aCtITC94Um9jRm5weGhFc2R3SkNaWDJqRzBqMDk2QU9mdnZER2tXbndoZWRMS0py cjdHbHliaGwvZWJ6dE9kM1h2akZKOE52RG1sWGZndWU4dkxPSzVtdUhrUm1sVU1WVmVBRjlQWGl1 cjFEUTd1NitIemFIR1loZUd5U0RKYjVOd0M1NS9DbStDOUJ2UEQvaFZkTXZHaWE0RHlObUp0eS9O MDdVQWNmOEdDUkZyS1pPMFBFY2Y5OVZ1ZkY3L2ttOTUvMTBYK2RIdys4SmFoNFZHby9iNUxkdnRM SVU4bHkzVGQxeUI2MG54ZC93Q1NiM24vQUYwWCtkQUhlK0NCbndQb1gvWGpGLzZEWFFzUkhFVzlC bXVmOEQ0LzRRZlF2K3ZHTC8wRVZzNmcreXlmMVBGQUdRRGs1UFU4MHVhWUQ2VXVhQU9kMVB3SjRl MXJVNUwvQUZDMGxudVpNQm1NN2o2QURQU3VXK0ZGdkZhYWw0bnQ0VjJ4Ulhhb2c5RkJjQVY2VURn ZzE1VGJlRlBIbWo2cHFrK2pYTmpCRmUzRFNuYzRKSTNFcjFYanJRQmQrSzBFZDFxSGhpM21YZEZK ZUZIWDFVbE0xMUZoNEk4TzZScUVkN1lhZjVOekVUc2tFcm5IYjFyaTUvQ2ZqclY5VjAyNDFxOHNa NGJPNFdVQlhDa0RjQ2VpODlLOVNKK1kwQUxTQVpPQlNBWk9BT2E0bnhyNDJiVEpVOFArSGwrMitJ YnI1RVNQa1E1L2lQcFFCbWVPTHVUeGo0bXMvQXVseUV3cXdtMU9aRHdpRCtINi93RDFxOVV0TGFP MXRvcmVGQWtVYUJFVmVpZ2NDdVc4QWVDMDhKNlc3WEVuMmpWYnR2TnZMazhsbS91ajJGZGlCaWdB Rk94UmlseFFBbEdLV2x4UUFtT0tNVXRMUUFsTFJTNG9BUURKeFhtR3Z5ZmFOYXVIQjRMdC9QOEF3 cjB5ZVR5TGVTWS84czBMZmtLOHFtRys4YytoeCtWTkFVcmtiWXptdk12RU12bWF0SU9NSUFvL24v V3ZTOVRiWkMzMHJ5VzVrTXR4Skl3d1dZc2NWclRXcExLekdvaWFrYW9qVmlFN1ZHd3FUdFRHNlVB UU9NQ3E3R3JEOUtyTldUS0JYcXdrK0YrNFRqMHFwM0ZhRVAzT21LSXNDN0V2eUNwQ09LYkR5dnRU elc2SUlHNHFOalVqMUMxU3hqRDBwakNuOXFhYWtDSmhWZCtEVmg2cnlDb1kwUjdxY3JZWUhyVERU b3Z2ZmpVTGNvdVJTWmtVYkQrRmFJVEZVNGppU3J5OUs2STdFTWpZVkM1NXFkcXJ5ZGFHQkV4cG5X bGJwU2RxZ0NNamlvMkZTdFVUVkJTSVc0TklLRzZtZ1ZER1NSTmpOWHJUNTFQR01HcWNIVnF2V3ZH ZnJXc05STmsrM0ZST01DckI3MUJKMHJSa2xkalViR250VVpySmpFNXBqQ245cWExSVpDMUpTdFNW QXdwNm41ZWxNcVJQdVUwQmR0eHVpRlM0Rk10dnVyOWFsUFd0NGtsQmV0V1lxaFVWTXB4VUlHV0Ix cHNuS242VTBOZ1V4MzRQMHF1Z2lrLzNLaHFaL3Vtb1QxckZsSVR2VWkxSDNwNDYwV0dUQTA0ZEtp RlNpcUVPRlRKVEVHYWtVWU5VaEU2ZEtsN1ZDcHhUaStCeFdseEVOempDL1UxUW40MjFkbk9RS3FU RE9LemtORmVucFRjVTVlS3pHVHBVb3FBR3BGUE5VSWs3MDVlRFRPYW1VVlFoNlZZU29GSGFwVk9L MFZnSmFxVC9BT3MvQ3B5M3BWZVk1ZjhBQ2lRRkM0LzFoK2xSS09UVmlaY3luZzlLaUNuTllQY29j bldyQzFBb3FSVFZSRXljZHFjT3RScWFsVVpOV0ljdldwMHFKUlVxOFZhQWxGRGRLYnV4VFMxWGNS VmwrNjFaN2NtdEYrVmFxYko3VmhJdERFcWVPb2xCN1ZLdkZKQXl3dE9xRUhGVEtjaXJSSk5iU0dH NGprSEcxZ2VLOU8wNlhmQXBIY1Y1ZUIzcnVmRE4zNXRraTU1VDVUL244cW1hNmpSMU1aSUlaVHlE eFhxOEV3dXJhRzVYcExHci9tT2YxelhrMFBKSXIwTHdwYytmbzNrazVlQjhmOEJia2ZydXJKbEcx aWpGT3hSaWtBM0ZINFU3RkppZ0JNVVlwMktLQUV4NzBZb3hTMEFOb0lwMktNVUFjUDRvOEJEVU5S R3U2QmRuU3Rmai93Q1cwWS9kei83TWk5L3IrZWFxNlg4UnB0THUwMG54dFl0cFY4ZmxXNXhtM245 MWJ0WG9PMnFtb2FiWjZwYVBhMzFyRGN3UDk2T1ZRd1A1MEFXYmU1aHVvbGxnbFdTTmhsV1ZzZzFM bXZPcGZoeFBwRXJYSGcvWExuU21KejlrbS9mVzdmOEFBVHl2NjBMNHA4WmFCOHV2ZUdUZXdyMXU5 SmZ6UjlTaCtZVUFlaTU5YVROY2RwbnhPOEs2aS9sSFVVdHAraGl1Z1ltQjlQbXJxWUwyMXVVRHd6 cEloNkZXQkZBRmpOUno4d3Q5S2ZrSG9SVFpPVWI2VUFaN0puVkltL3ZJdGNQOGVSandaSC92ci82 RUs5QWlqM1hGcy84QXNZL1d1QitQZVA4QWhERUgvVFZmL1FoUUI2QnBmR2phZi8xNnhmOEFvSXEx VmJUZU5IMC8vcjFpL3dEUVJWbWdCYVB4cEtNMEFPNyt0ZVBYVnBaK0ZwOVY4TCtJMGxUdzVxa3h1 TEsralhQa3Y3L1RqOHZldlhxNTN4WEpya2xzTFRTZENzdFNqa1hNaHZaVkVZOXRoNjBBZVgyZmhq d2JvTjVIcXVwZUxMYlVMV0ZoSkhhMnlaZVVqb0dBSnJ0L0ExcGZhdHJ1cGVNdFN0MnRqZktJYk9C K3F3anYrZy9XdVEwTHdkNHUwTFZwdFEvNFJqU2JzeU51RWM4aWxZK2MvSnp4L3dEV3IyQ3dudWJp eGlsdkxUN0pjTXZ6d2J3K3cvN3c2MEFXU2FvWDR6YW4vWmtIOHF1R3F0eXU2M21IcHROQUUwUC9B Q0M1ai9zR3VIK0Z2TXZpYi9yOUg5YTd1Rk1hUk4vMXpQOEFLdUQrRmYzL0FCUC9BTmZvb0E5QkZP cG9OTG1nQndwYzB6ZFNiaFFCSmtVSG1vdDFKNW1LQUpxTTFDSmNVNFNvZStLQUpCUlNaSHJTMEFG RkdhS0FDaWlpZ0Fvb29vQU0waE5GQm9BYlRhY2FaUUFFMDAwcHBLQUNrb3pTRTBBRkFHVGlqR2Fl cEM5S0FKVkcxUUtVbW95OU5MVUFQSnBwTk4zVW02Z0J4cHBvelNab0E4eWovd0NUazdQL0FLOVgv d0RRV3IyeVBwWGlTOGZ0S1dmL0FGNnYvd0NndFh0Y1pvQXlOVGZkZXNQUUFWVkJ4VWw2MmJ5VS93 QzFVR2FBSGsxZ2VLUENWaDR0Z2dqdjViaVB5R1prTUxBY24xeURXNFRTWm9BeS9EL2g3VHZET25H eTA1R0NzMitTU1JzdTdlcHJWemltNXBNMEFPelNacHRGQUMxeFh4Yy81SnZlZjlkRi9uWGFWeFh4 Yy81SnZlLzlkRS9uUWdPOThFSC9BSW9mUWY4QXJ4aS85QnJVMVJ2M0NMNnRXUDRLUC9GRTZELzE0 UmYrZzFwNm9lSWg5VFFCUUJvelRSOWFPUFdnQlNhVE5WTHpVN0N3akwzbDVCQWc2bVNRTFhLWHZ4 UjhPUXpmWjdCN2pWYm4rR0d4aU1oUDQ5S0FPMXpWVFV0VHNOSHRXdWRTdklyV0ZmNHBIeCtWY2NM L0FPSWZpTTdkTzBtMzBDMGIvbDR2bTN5NDlRZzZmalZ2VFBoUllOZExmZUpMNjYxNitIT2Jsc1JL ZlpLQU1pNThXNi80M2tmVHZCRm85dlpFN0pkWHVWMnFCMzJWMTNnendGcDNoR0Y1RUxYZXBUY3oz czNMdWY2Q3VvdDdXRzJoV0tDSkk0MUdGUkZ3b0hzS3NBVUFOQzA2bEFwY2U5QUNZcGNVWXBjVUFK UzRveFM0b0FURkxSaWxvQVNseFM0b29BeXZFTTR0OUlrNXdYT1B5NVA4cTg2aFVrczU2MTFuaks3 KzViS2Vnd2ZxZVQrbTJ1YldQeTdjRTlUelRRamx2RmR4NU9tem5HU1YyL254WG1UZEs3RHh4ZWd5 UjJvT1NmbllmeS9yWEhFMTBVMW9TeUpxaU5UdFViREZPd2hocU5xZDBxSmoycWJqSTM2VldhckRj MUV5NXJKalJFS3ZRSDkyYXFoS3VSTHRXcWlnWmVqNFhpbkhIYW9ZMitXcE04VnNoV0kzcUZoVTdW R1JVc0NBMGhwN0FZcUpzMURBWStLZ2VwV05STU0xREtSQ2FkR2NNUHJSdDVxUkUrY2ZXa2tNdXcv NndWZUZVSXp0a0ZXdDliUklZNXU5VjNxWmpVVEROTmdRTlRPMVNzS2pOWnNCalZDL1dwV09LaVkr OVN5a1JFVWdwU00wQmFnWkxCMWFyOXJqQit0VVllQ2F0d0hDbjYxcEhRa3VFOWFna3AyNm1OV3Q3 aXN5dXdOTU5UTUtpWVZtME1aMnByVTZvMk5RTVkxTnBUU1ZJQlVpZmRxT3BFenRwb0MvYmNJUHJV cHo2MVdpYkNWTUc0SEpyWk1SUTgvbWxGd1JVRkZZM0tKL1BOSVhMWTYxR3ZOUEE1cDNFU0RrMHBo RFUwVktwcWhYR2kyQnBmc3VPbFRKelU2ajZWYWlGeWkxdVFwcEFOdUtsdUoyaGx4czQ5YXF0Y014 Sks5YWlXZ3lacHRvNHBvdVNEVmNuTkpVOHdGc1hUVXYyaGp4VlphbFVVMHdZOVd5ZWFrVlF3TlJn VTlPS3BDRit6cVJ4U2kwRlNLYW1RWnAydUJXRnBUVEZ0YXI0WElyTmt2R3l5YkFSbnJRMVlGcVAv Q25OY1lYcFZUN1MyZnVDbTd5VHpVOHc3RnNYUnBmdFRWU1VtcFY2MHVZR2l6OW9ZMEtjMUdvcVJS VkNKQWdaZW5OSjltV2xVNHFWVG1yU0FpRm9LWDdNS3RLS1dUNUkyUFhBelRzckNLWGtsVzcwNE1F Nm5GVlRxRHNNYkYvQ28zdW1jWTIxbnpKRHNYVGM0b0YzN1ZRREZoVDE2MGN3V0xuMms5czBHWm1x RlJVcWlxdXdKQnoxcHhoVnFhT0trVTFRaGd0aFRoYWdkS21YazAvRk93RlUyNUhTa0EyZ2ptaTl1 VGJNaWhjaGhtcVRhZzVPZGkxTW1rTXZtWFlPT3RiUGhmVVBMMVR5RzZTRGo2ai93Q3RtdVQrMU16 OHFPYW1nbmFDNFNaT0dSZ3k1OWFseXZvRnJIdGtEWkNzSzZyd3JlQzIxUVJzMkk1eHNQNDlEK2VL NGJSTDFMK3lpbWpQeXV1ZXZRK2xiOXV4VXFSbksxbU05VEl4UmlxMm0zZzFEVDQ3ak9YeHRrLzN2 L3I5YXRZcVJpWW9wMktURkFDVWZoUzRveFFBbUtNVTZpZ0JNVW1LZGlqRkFEY1VFVTdGR0tBR2Jh YVVxWEZKdEZBR1RxZWdhVnJLYk5TMDIwdXgvd0JOb2xZajhldGN0TjhLUER5dTBtbXZxT2xTSG5O amVNby9JNXJ2dHRKdG9BOC9IZzd4VFlFSFRQR3R5NmorQyt0VmwvOEFIaGcwNy9pNDlubFdHaGFn bnM4a0xIOHdSWGU3YVFybWdEaEU4UytON1FwNXZndnpWWHZiMzBiL0FPRmNKOFM5UThhK01MYUcw SGhEVUxTMWlPOXNSbVFzZndyM2JZTzRwNnJ0NkRGQUhsK2kvRmUydE5JdExYWHRKMUxUN20zaFdK eTFxNVJpb3hrY1pyYXQvaXo0UG4vNWkwY1o5SkZaZjVpdTJJSnFyTnB0bmNqRTluYlMvd0RYU0ZX L21LQU1hMzhlK0Y3b2dSYTNaTWZUN1F2K05hY090NlpjRDl6ZXdQOEE3c2dOVWJqd1Y0WXVqbWJ3 OXBqbjEreW9QNUNzeWY0V2VESnp6b01DSDFpZDAvazFBSFZyY3dPUGxrQi9HbmlST3pyK2RjT2Zo TjRaUWY2T2RUdFQvd0JNYitRZnp6VFArRll4UkhOcjRwOFNRZTMyd09QMVdnRHZkeW4rSVVoNjF3 WjhDNjlGL3dBZXZqclZGOXByZU9Ta0hodnh6QWYzWGpDMm1IL1RiVGdQL1FXb0E3czFDeTdoTXZx bGNYOWkrSThIM05SMEM0SCszREtuOHFCTjhSbzgvd0RFdjBLVmlNWlM2a1grYTBBZCtGMjZSTC8x emIrVmVkZkNoZzMvQUFsQkIvNWZoL1dwTHkvK0prOWhKYVE2THBjWmRDdm1MZUJzZmdjVnp2aERS UEhuZ3U0dXovWXEzc0YzaHBWVzRUTzRkR0J6N21nRDE3ZFJ2cmtsOFI2NnYrdThJNm92KzRVZitS cC8vQ1ZYSy82N3c1clNmOXV1ZjVHZ0RxTjFHNnVZL3dDRXl0bC8xdW02dEgvdldUMGY4SnRwSSsr THhQOEFmdFpCL1NnRHBTMU5MVnpvOGNhQWZ2WGpML3ZST1A2VTlmR2ZoNC84eE9FZlhJL3BRQnZF L1drckdYeFpvRGROVnR2Kys2a1h4TG9qZE5WdFArL29vQTFlUlM3bTlUV2N1djZRM1RVclEvOEFi WmFrR3NhWWVsL2JIL3RxdEFGM2UvOEFlTkw1ci8zalZNYW5wNTZYbHVmKzJxMDRYOW1lbDFEL0FO L0JRQmE4NS83MUw1OG45NnF2MnkxUC9MeEVmK0JpbCsxVzMvUGVQL3ZzVUFXZlBrOVRSNThucWFy L0FHbTMvd0NlMGY4QTMyS1g3UkIvejFUL0FMNkZBRS9ueWV0SjV6K3RRZmFZUCtleWY5OUNqN1Zi L3dEUGFQOEE3NkZBRS9tdjYwbm1OVUJ1N1VmOHQ0LysreFRUZldZNjNNWC9BSDhGQUZuZS9yU2Iy OWFxSFU3QmV0NUFQKzJxMUcyczZZdlcvdGgvMjJYL0FCb0F2YnpTN3F5bThRYU1uM3RUdEI5WjEv eHFCL0ZlZ1IvZTFpeUgvYmRmOGFBTnpmUzc2NXAvRy9oaVA3MnQySS83YkxWZC9pSDRUVHJydG4r RDVvQTYzelBlamZYRnQ4VHZDQ2Y4eG1JLzdxc2Y2VkNmaW40Vi9ndlpYLzNMYVEvK3kwQWQxdnBO OWNLUGlmb2Ivd0NwaDFPWC9jc1pEL1NqL2hZMXUzK3AwRHhCTi91YWU5QUhkNzZVTlhDRHgzcU1u K284R2VJWCt0cnQvbWFHOFdlS25IK2plQk5USjdlZElrWS9uUUJuQmdQMms3UG5yYXYvQU9ndFh0 TVIrV3ZtK1h3eDhUYjN4c3ZpeUxTWWJhOFJ3MGFQUEh0VVl4dFB6YzhaL092UW9kWCtKdTBidEIw dEQzemZmNEEwQWRoT2QxdzUvd0JzMUhrWXJqbS80V1RPZUxQUUlNOTNua2YrUzBnMHI0alRmNnpX TkR0Lyt1ZHRJMzh6UUIyTkdSNjF4My9DSmVOcHorKzhhSkdQU0RUbC9xMVBIdzkxaVlZdXZIR3NO LzF5ampqb0E2MHNCL0ZVYnp3cDk2UlI5V3JsMStGTnBJYzNYaUx4RmNmNzE5dEg2TFVxL0NId3Ez TThOOWNuL3B0ZXlIK1JvQTE1dGIwdTN6NTEvYlJqL2FtVVZteitPdkM5c2NTYTVaQStnbVUveXF6 Yi9DN3daYi9jOFAycmY5ZE56L3pOYWx0NE44TjJtUHMrZzZiR2ZVV3FmNFVBY2hOOFUvQ1VSd3Vw K2MzcEZFNy9BTWhYSWVQUEdFL2pEUVA3RjBEUk5VdUJKSUdlWTJyQVlIb0s5eWgwKzB0eGlHMWdq LzNJd3Y4QUtyS3J0NlVBZVA4QWd6eFg0MzBydzlhYVhjK0ROUW1OcEg1VVVvQWozS09tZDNldDZU eEQ0K3YySGwrRUlvT3dhNnYwR1B3VUd2UWl1ZTFOMkQwb0E4Nit3L0VtK1B6M3VoNmFoLzU1cEpL dy9QQXBQK0ZlNjVmZy93QnIrTnRUa0I2cFp4ckFQejVyMFlKVGd0QUhCV2Z3bDhLUVNpYTV0SjlR bUg4ZDdPMG42ZFAwcnI5UDBpdzB5SVJXTm5iMjBmOEFkaGlDRDlLMEF0THRvQVlxWTZVNExUc1V1 S0FFeFM0cGNVWW9BU2x4NlV1S01VQUppbHhTZ1VZb0FNVVVZcGFBRXhTNG94UzRvQVRGSTdwRkcw am5DSUN6SDJGT3hXSjRsMUFXbGo1UVB6dHlmNkQ4K2Y4QWdOQUhJNm5NMm9hdXdKNk1kMzE2bi9E OEtnMUIxaWhQYmlyT213WWllNGZrdHdEL0FGcmovSDJ0RFQ5TmRJMnhQTDhpWVBJOVQxendPL3Jp cVFqelBYOVQrMjYxY3lxZDBZYlloRFpHQjZmWHJXWWJuaW1NS2diak9LMXZaQ0xQMnJqbW5MTUdy UExmTlRmdERBOUFjVlBPQnBiY2lrRUdhcEMvZFRuWU9LdldWeTF5V3lnR1BTcVRUQ3dmWlFWcFBz d0ZYQ0FCVWJHcjVCRmNRS3BwQ01WSXhxTTFJRERJVWJpajdTYVJoVUxESFNwYkdURzZQU2srMCsx VkhOUjd5dk5UekJZMGZNM0RpbWxOL1RPS3BMY012TzBIOGFtUytaUDRCK2RQbXVPeForeWpGSjls V3JrZk1ZWWpxTTBqZEswNVNibE0yd0ZLSWxYSnFaalViR3BhR1JIZ1Vpek10T1BTb21GVGNCNXVq U2ZhbXF1K1JVWk5MbVl5NHMrNDgwcDVGVWcyQmluaWNqakFvNWdzV0ZoM0hrMDgybzZab3RyZ3pT N0NvQXhWd3JnVlNqY1JSK3lqRko5bUFxMDN0VVRHaG9DSndGd0JUQ3hVakJwN1ZHdzZjVklJZDU3 Q2tOMGFpSXBocFhLSnpjbWp6ZHkxV0ZPRGJXQnBjd0UrT0tGaHljSHBVWG1ucmlydHEvbkJtSXh0 OUtwYWlJZnMyT3ROTnNLdnNBQlVEMDNGQ3VWdklDbWtZWVBIU3BHTlJ0elVqRTNsVFMvYUdGTklx TTlhVnhpVW5lbG9xUUhyVWdGUnJVZ3FrSVVVNWFhUFNuanJWQ1pQRjFxeW5XcTBYVVZaV3RFSVpj UmVhRkdCdDdudldlOENxeEF6K05hcCs3aXMrVVljMHBqUlRJd2FTbGI3eHBLd0dQUVZNdFFwVXkx U0FmajBwVjYwQ2xGVUlrU3JFZFYxcXhIV2lFVEFmclZLYXpWZzd5Y04yMjFlV281eCs3ZjZWVWxk QVpuMmRlNU5WandhdmtZcWkzM2pXRWtVaFZOVEpVQzlhblNwUUV5aW5pbUxUeDFyVkVqaFVpVkVP dFNwVkFXRTZWSVJsVGprK2hxTk9sU2lyUVhNNlRUMEM3eVNHUFlWVmx0MVJRVnpXdE1Qa3JQdVB1 alByV2NvcER1VTg4MUtoNXFFZGFsUWMxa2hsbEtsQXFKS21GYW9rVWRhY3BwbzYwNFp6VkFTcFVx OWFpV3BWcWtER1hGc2x5bUhINGlxRDZmR3B4dU5hdmFxc3YzNlVvb1NNcDRWalk0b1htcEp2dkdv MXJGcXhSMlhnalZURGNHeGxiNVcrYVBQWTl4L1d2VGJjNXd3cndxM2tlR1ZKVU9IUmd5bjBJcjE3 d3pxOGVwMktTamh2dXV2bzFKb1ozZmh6VWhZM2ZreW45eEx3ZmIwUCtmZXUxSXdjVjVxcThBcng5 SzdEdy9xb3VZVnRabXhLZ3doUGYyL3o5S2tadFlveFRzVVlwQU5veFM0cGNVQU5veFRxS0FHNG94 VHNVVUFKaWt4VHNVWW9BYmlqRk94UmlnQnVLTVU3RkdLQUc0cE50UHhSaWdCbTJseFRzVVlvQWJp akZPeFJpZ0J1UGFqYlRzVVlvQWJ0OTZidHFURkdLQUk5dEp0cVRGR0tBSXR0R3lwTnRLQlFBMVZw K00wb0ZLQlFBbTBlbEtGOXFjQlNnVUFKZzBoWDNOUEFvb0FpTVN0MVVINmlvMnM3WnZ2VzhKK3NZ TldjVVlvQXBOcFZnLzNyRzFQMWdYL0FBcUp0QjBwdXVtV1ovN1lKL2hXbGozb29BeVc4TmFJM1hT TEUvOEFidXYrRlJud25vQjY2UFkvOStWcmJ6U2NVQVlSOEhlSFQxMFd5L0NPbUh3VjRjUC9BREJy VDhFcm9LTVVBYzZmQS9oby93RE1IdHYxL3dBYWIvd2d2aHIvQUtCRUg1dC9qWFNZb3hRQnpYL0ND ZUd2K2dURC93QjlOL2pSL3dBSUg0YS82Qk1QL2ZUZjQxMHVLVEZBSE5mOElINFovd0NnVEYvMzAz K05ML3dnZmhuL0FLQk1QL2ZUZjQxMHVLTVVBYzEvd2duaG4vb0QyLzV0L2pRUEF2aG4vb0RXMzVI L0FCcnBjVW1LQU9jLzRRYnd6LzBCTFA4QUZLVWVDUERJL3dDWUZZL2pFRFhRNHBNVUFZQThHZUd4 MDBMVC93RHdIWC9Dbmp3bDRlWHBvbW5EL3QxVC9DdHlreFFCa0w0YTBSUHU2UHA0K2xxbitGU3Jv bW1KOTNUYk1mUzNUL0N0TEZHS0FLYTZmYXA5eTFnWDZSS1A2VktJRVg3cUtQb01WUFJpZ0NMWitI NDB1ejFxVEZHS0FJL0xIb0tVSUIvQ0treDlhTVVBTnh4MHBwV3BNVVlvQWkyZTFBV3BkdnRRRm9B akMwN2JUOFVZb0FidHBRdE94UmlnQk1VdUtXakZBQ1lveFRzVVVBTnhSdHAyS1hGQUROdExpbllv b0FURkxpbHhSaWdBeFNZcGNVdUtBRXhTNG94UzBBSUJSaWx4UmlnQXhSUzRvNzBBSmlseFM0b3g3 VUFGR0tYRkhiMG9BamxsU0NGcFpQdXI2ZC9hdlB0Um5sMW5WZGluSzdza2pwN24rbGF2aVhXZk1J dHJkajdZL24rUGIvNjlWYkswRmhhRjVCaVZ4bHZiMnBnUlg4cVdsdHRYaFZYQXJ3VHhicS85c2Ex STZQdWdpeWtlRHdmVnV2YzkvVEZkMThSdkVxdzI3NmJDV00wNmZNUjBWRHdmejVGZVUxcENQVWxr YkRpb0g0cWQrbFFTVlRBcnQxSE5Jc1FkdWFWdUtkRWNNS3pBblN4UWtEYzFhTnRiSmJwaEJ6NjFC SDk0VmRYZ1Z2RklRMDFDL1NwbXFCNllFVEdtMDQwMnBZRFdxRjZtYnBVTDFER1YycUkxSzlSSHJX WTBTd3dySWNFMWJ0N0dNdms1T0RtcTlyOTc4SzByY2MxY0ZjVExCR0Y0cUY2bE5SUFd3aUIrdFJF MUkrY21veldiQWFlbE1OUDdVeHFsaklYcUE5YW5lb0c2MW14b0FNMVlTQldYdlZjRUNya1gzVnBv QzNhMi9sT05vR09wSnFkdWxKSDkybGJ2WFFsb1NRUFZkalZoNnJ0VVBjWXdtazdVYzRvUFNvQkVi VkMxVE5VTFZER0pTcU56QWRxU25SL2ZGQXlRUWpPQ2F2MjhZalVqSEhyM3FwL0VLMEVIeTFwQWth M2ZJcXU1cXkxVlhwc0NKalRLZTFNcUJpSHBVWkhOU0hwaW82UURhS2s4cHM0RkhsUFUyWURGTlNE TklJV3BkakwxcWhqeDFxVUFrMUd0UDh4VnFoRTZERlRLYXFDZGFkOW9IYXE1a0l0bCthcFM4dTFE M0hYRlI1eWMwbTdnVm0rOGFUdlZsb2NnNDYwM3lHcUxESTFxVlRRSUhCNlU0Uk5UU0FjT1RUbHFO Y2cxTEhnQTAwSWxVVk9sVlJNdFBGeW9xMHdMZWNWSEszN3RxaCswcVIxcUl6YmlSemlxY2dFN2Zo Vk5sNjFjRkkwQkk0ckpxNElxTDFxVlRVZ3QyOURTaUJ3ZWxMbFl3QnFRYzAzeW1ITk9VRURwVm9r a1VWS281cU1IQ1VDWk05YWR4bHBhazNZRlV4Y0tPOU84OWF0U0ZZa2xPVXFqY0xsQjlhbE11ODQ3 VUZOL0ZTOVJsRGJpbnJWZzI1OUtCYk5tcytVWTFUVXEwZ2dZVXV4aFZMUVJJS2tVVkdvcCs5VnFy aUpSVWdPS3JDWlBXbmVlbnJWcGdXQ2FyU2ZmcEdtR09LYm5kelNiQ3hUbFg1NllCZzFkTVc3bW96 YnRXYmlNalRyV3hvR3N2bzJvQ1lBdEczeXlLUFQxK29yTUVMQ2w4dGgyb3NCN3pwbDVIZFFKSWpo bFlaQkI2aXRFQjRKRmxqT01WNHo0VThTUzZOY0xiM0RNMW94Lzc5bjFIdC9uNit4V0Y1RmRRcXlz R1Zod1FldFExWWFPMDBqVmt2NGxTUTRtSEhQOFgvMTYxTVZ3R3lTMmtFc0pycDlLMXVPNFVSM0Ri WEg4Ui9yL0FJMU5obXhSaW5Zb3hTQWJpaW5VWW9BYmlseFMwbUtBRXhSaW5ZK3RHS0FHNHBjVXVL TVVBSmlreFRzVVlvQVRGSmluVVVBTnhTNHBjVWRLQUV4UmlseFJpZ0JNVVlwY1VZb0FURkdLWEZH S0FHNG94VHNVWW9BYmlseFM0TkdLQUVGS0tNVXRBQ2lsRkppbG9BVVVVQ2x4UUFZcE1VdEdLQURG SmluWXBNVUFGSmdVN21qRkFEYVhGR0tNVUFKUlM0cGNjVUFOb3hUc1VZb0FiaWluWXBNVUFKaWtw MUpRQTAwbE9wTVVBSlNZcDJLS0FHMFlwY1V1S0FFeFNZcDJLTVVBSmlqRkxpbHhRQW1PYU1VdUtN VUFKaWpGTGlseFFBM0ZHS2RSK0ZBQ1lveFMwdUtBRW9wYU1VQUdLUHBTNG9vQVNqRk9veFFBbUtN VXVLTVVBR0tNZTlMUmlnQktYRkZMakZBQ1VVdEdLQUNqRkxpakZBQlJTNG94UUFtS01IMXBjVXVL QUV4UmlseFNNVlJTN3NGVWNrbmlnQmNWemZpRFhVZ2lNTUJEYnZ5Yi93Q3gvblROZDhRTEdyVzhI SlBiMS8zdmIyL09zV3pzbmxrKzJYdVdKK1lLM2Y2LzRVQU8wMnlZc2I2NnlYYmxRMzh6V1A0dzhT dzZOcDd6UGx5VHRSRi9pYnNQL3IxWjhUZUpyVFJiQ1M0dUpkcWpoUU9ySDBGZUZhOXIwMnU2bEpj U3lNWWd4RVNIamF2MDlmV3JqRzRtVTc2N2x2NzJhN25PWkpXM0hucDdmU3FwcDVJSTYxRzNQU3Ro V0dPZUtoZXJIbE9lMU5NREVWTFFGUWpQclRrWEJGV1BzN1ZJa0dPdFR5Z1BqKzh0V3QxVkR4K0ZP U1lkNjFRaXllbFJNS1o5b1gxcFBQVDFvdUFNS2pOU2VZcGJBcU05ZTlKaFpqR1Bhb1dOU2xTejhV M3lYSTZWQXlxd3pUQXZOV3piUDZVQzJhcDVRSTdkY01hMExjOVJWY1I3S1VTYkRWUjBEY3U1elRH cUVYSzBuMmhEM3ErWVZoekROUk1NVXBtU2plckRpcEdSSHBVYkdwR3B2bHN3NlZJRmRxaUl6NjFi TnUvcFRmczcrbFM0NmpLd1hJcTNFTUlLRmdJUE5PeGpJcHBBeTZqWVVVNG5pcVN6WU9EMHAvMmtZ clJTRllrZm1vU09LRGNLYWFaVkpxV3dHTlRXNHFSc2NWRXdKSXhVc0NOajdWRzNKcWN3dDJwdmtQ anBVdERSRCtkUGpIemluK1ExTzhyYU05NkxBTy9pcTZqOENxTlBTYkI1cTR1d2k0eHFCcVo5b1gz cHBtUTlLR3dzQkZSbmluK2FwNHBqZGFrWXhqVVpOUEtrdHhTZVU5SUN5cHlhbFVacUZUelU4Zk5X a0laY1A1SUh5NXpWTXl1M1d0S1pESkF5cjFyTldGMmJidElwU1ZoamQ3WTY0b3lUU3NoQTZVMGRL Z1lVNWFiM3A2aWdCd0dUVXE4WXBnRlBBcWhFaW1wVUdUVUNtcGtxMEluVmFvejNMN3RvWGFjOWF2 cHpWVy9qWXNyTEdEbnVLSkxzQlM4MlE5NlR6SHgxcC8yZVRhR3hqUHJUR2pLL2VySjNSUWdmaW5B NXFQRlNMUUJLS2tVZk5UVnFRQ3FSSXVPYW1VMUQzcVJUVm9ST3VLZmpna2pJcUpEVmhLdEFaTTk0 N09kbnlxT0toODZYKzlWcS9oL2YvSkdjYmNuRlZ6YVNqR1JqSXpXTFR1VWhobWt4OTZuTElTYVpK R3lNUWUxQ1ZOd3VUcWVha0ZScDFxZFJWb1RIS0tsVTROTUFwdzYxYUVUTDFwNmlvVk5UcDBGV2dJ N3FUeUlESUJ6OTJzcjdWTWVOL0ZiY2tZbGpaQ001SEZZcTJVenltTGJqMzdWRTB4b2I5cG1QRzZr KzBPQ1N4SnB6V2tpQTdzY1ZDdjNoa1ZscVVXdytjVThkZTlRcG5OVG9LcENZOVJ6VXE5S2FvcC90 V2lKSGcwOFZFS2VEVEFrQXoxck52YnA0NXRpY1k3MXBMME5VdFJ0eTZpUkZ5UjFwVFdtZzBVUHRV eC9qTmRWNFA4YVRhSGNMYlhyczlreDY5VEdmVWVvOXE1WkxhVnhrREdQV21Td1BGZ056bjBySFVv K205TzFHQzhnUjQzVjBkY2dxY2hoNjFaYUhhd2toT0NPUmc4aXZucnd6NG92dkQ4b0NzMHRxZnZR TTNBOTE5RC9PdmFQRC9pbXkxaTJXUzNtQlBHNUR3eW4wSW9FZGxwbXVQYjRpbSs1NzhEOEQyL2w5 SzZXM3VJcmxjeE5ranFwNmo4SzRjK1hNTWpBUHFLZEJjVFdqQW94S3IwR2VuMFBha003dkgwb3JF c2RmU1FoSnVXL0p2eTZOK0g1VnRSU3hUcnVpa0RBZGNkUjlSMnBBTGlpbllveFFBM0ZMaWx4Umln QnRHS2RSaWdCdUtNVTdGR0tBRXh4UmlseFJpZ0JNVVlwY1VVQUppakZMUmlnQk1VWXBjVVlvQWJp akZPeFJpZ0J1S1dseFJpZ0JNVVlwY1VtS0FFeFNnY1V1S0tBRXAxR0tLQUZvRkFwYUFFcGFVVVlv QVNpbG94UUFsTDJveFJRQWZoUlJSUUFVZDZLS0FDa3BhTVVBSitGSlRzVWxBQ1lwS1dpZ0JLTVV1 UGVpZ0JwRkdLWEZHS0FFeFM0cGNVWW9BVEZHS1hGTGlnQnVLTVU2a3hRQWxMaWx4UlFBbUtNVXVL WEh0UUEzRkxpakh2UzRvQVRGR0tXbHhRQTJscGNVWW9BVEI5YU1VdUtYRkFDWW9wY1VZb0FURkxp bHhSaWdCS1hGR0tYRkFDWW94UzRwY1VBTnhTNHBjVVlvQVRGR0tXbHhRQW1LTVV0R0tBREZHS2ps bmlnSDd4OEhIUWNrL2hYUGFuNG9qaXpIYjVMZjdCeWZ4YnQrRkFHN2RYc05vakdSaHVBenRCNmZY MHJrTlU4UVRYc25rMnVUNkVEZ2Y3ditKck9rZTcxSnQwejdJczUyOXY4QTY5U3Exdll4WVhBUGNu dlRBZGEyS1c1ODY0SWFYcnoyckw4U2VLTFhSN0dTNG5rd3E5QU9ySDBIdldCNHE4ZDIybElZb2lK N25PUEtWc0ZmZHZUZy9qK3RlUGFwcVYxcTk0OTFlU2I1RzZEc285QjdWU2pjUlA0aThRM1hpRytG emNEWXFncWthc2NLTTUvUHB6N0NzS1dWZ1FGNHFWcXJ5akl5S0crZ0FMbWJzMUw5cW1IOGROU0I1 UHUwOTdhVkJ5dTc2VWxjWmRzcnA1bkVaWFBxMVhpTVZWMDJCNDRtTGpHNDFjYXVpRzJwREl6VFNh VmpVWm9BYTNOUk1LbXFOaFVnUU5VYk5qaXBaT2xWbXJOc3BiRGZPY1p3YVg3VEwvZU5Sa2MxS2x0 STY1QUErdFRxTUJjektjN3ExcmFYejRBNUFCNlZrSmJ5dSswS2VUMTdWdVJ4TEZHRVVZd08xYTAw eVdOWVZHVGlwSHFCcW9RMXptb25HYWtKcHBxV01nWVZFVHhVN2lvSDRxR01qTDRvRXJyME5OTklC azRGUmRqSlBQZjFxZTJ1WDg1VmI1ZzN5MUNMV1ExYTArM084dTZmS09CbXFpbmNUTHhVQ29tNDVx WmhVRDFxeVJqR29qVG1OTnFXeGtURHZVVFZPd3FKaHhVTVpEbkZHNzBvUFhGSlVhakhlWTJldEw1 ajQ2MGlvVzZVcGljZEFUVFZ3THRyTDVvMnNQbTlhbVlZcGJhTUpicjh1Q1J6US9TdGt0Q1NGcWlZ OEduc2FqSnFXQTAxR1JVbk5NWVZMR1JHa3BXcEtnWUFrRVU3ZWFiVGdwSW9BQTdBNUhhcktURXI5 ejlLckNOdHd3Q2EwMGpJUUFxb0k3Q3RJaUtpZGFzUlZYVVZZanFrSXNMVFpqbGNleG9CcEhiQTll RFZDTTZUN25wVU5TdVBsTlJWZ3lrSjNxUmFaVDFOQXlZVTRWR090UEJxa0ljT3RUSjJxSmFsU3FR aXpHT0tsSDlldFFvZlNwTjJCV3FFVnJuamIvdkdxRS9RVmZ1V3p0eDcxUW01QzlheW1VUTA5T2xN L0NucFdReWRLbEZRcWFrQnEwU083MDlhWlVpMWFFU3BWaE9sVjBGVHJtclFFdVJpcVZ3UDNuNFZi M1lxcE9jeWZoVFlGQzUvMWpmU29SMXFlNEdaRDlLaUE1ckI3bEVpQ3JDMVhUclU2bW1oRW9wd3Bx bW5EclZvUTlldFRwMHFGUlV5VlNBbEZEL2RwQlNsdUtzQ2pKOTFxem0rL1dqTHlyMW5zcEZZVEdP U3JDVlhTcGs0TkpBeXd0T05SZzAvcldpRU9GT0hXbWdVOVJUQWtYRktQcFNDbFA2VllpR1UvajdW VW4rN1Z5VS9MVk80R2NFVm5JcEZVY21yZGpkM0ZqY0xQYXpQRkt2OFNuL09mcFZYRlBYcldhQTlR OFBmRU5HQ1E2bis2bEp4NWcrNGZUNmZ5cjBHMDFPRzZqVjBrVmxZWkJCeURYem1PdGF1bGE5cUdr TVBzczU4di9uay93QXlmbDIvQ2psR2ZRQkNQMDZWUEJlejI3S1ZjbmIweWNFZmpYbTJqZkVLMHVD c1Y1bTJrOVdPVVA0OXZ4cnM3ZlVvYmhBeU9DRDBJTlRZRHNMYnhId0JOZy83M0IvUG9mMHJhdDlR dHJqQVdUYXgvaGY1Znk5Zndyejd6VlBTbngzRFIvY2NxRDI3SDhLVmhucEdLTVZ3OXJyZHpiOEs1 d095OVA4QXZrOGZ5cll0dkZFVGZMTWd6L3NuYWZ5UEg2MHJBZEJpakZVNGRWc1pzWW5DRTlwUGwv OEFyVmRHQ01nNUhxS0FFeFJpbHhSaWdCTVVtS2RpakhOQURjVXVLWEZBRkFDWXBNVTd2UmlnQk1V WXBjVVlvQWJpbHhTNG9vQVRGR0tYRkppZ0JNY1VZcDFHS0FFeFNVN0ZHS0FFeFJpbG9vQVNscGNV WW9BS0tLWEZBQmlrcGNVVUFHS0tLS0FERkZGRkFCaWt4UzBZb0FNWXBLWEZGQUNZcE85TFJpZ0JN VVl3S1drNzBBSjJveFRzVVlvQWJpbHhTL2hSaWdCTVVZcDJLTVVBSmptakZMaWpGQUNZb3BjVVVB SmlseFJpbHhRQW1LTVV1S01VQUdLU25Zb3hRQW1LTVV0R0tBRXhTNHBjVVVBSlJTNG94UUFtS1hG TGlpZ0JLTVV1S1dnQk1VWXBhS0FFcGNVWW94UUFVVU1RaTduWUtQVW5pcWMycTJVQ2ttYmZqKzUv ajBvQXVZcGNjZGE1dTY4V1FKeENBVDdEY2Y2Q3NPNzhRM2wwY0E0SCsxODM2ZFAwcDJBN1dmVWJX M1VreWhzZGRwNC9QcFdCZitLMEdWdHVUL3NkUCsrai9RZmpYTHlOTk8yNmFWbVArMGMwQjRvdVRq UHJSWUN6UGQzbDhXM3VVUTlod0Q5ZldtSkZEQU56Zk0zdldaZmExYldjVFBMTWthTDFabTJpdUQx ajRoNXpIcHNaa1A4QXoxaytWZTNicWUvcCtOVWxjUjZGcWV2V3VuV3J6VFNoSTBHV0o3VjVqNGo4 ZjNGL3Z0OU5MUlJFRldtUERIbitIMCt2WG50aXVVMURVTHZWTGd6WGN6T2M1VmMvS3ZzbzdWVUFx bEFCWFpuWm5kbVoyTzRzeHlTZldvajBwNXBqSGlyRVF2VVJxVnFadHpXVEJia3R2OTZyOFBVMVJn WEQxZWhQV3RJSUdXT3ROYnBTNTlLYWExNkVrVGU5TXFSaFRNVkxHTk5NYW5VeHFrQ0dUcFZacXN5 VlhZVmt4b2pBNXJRaSs1VkVMeFYyRmNSNHB4R3kvRHd2U25tbVJ2d09LZVRYUXRpU0Y2aGJwVXox RXdxR0JGU0duSDZVMWppcFlFYjFXa0hPYXNNYWdjNUZac2FJVFRvc2J2eHBNVXFLZHc3Y2lwVzR6 U2kvMWxYQjkzOGFwUkhFbFhBMWRFZGhDUDNxdTlUdFVEaWhpSUc2MGxPWVUyb1l4amRLaWFwR3FK czFER1JOMXBLVTBncUJrMEhlcjFyM3FqQUR6VjYxT0ZiNjFwQVRMUnFDU3BTYzFFOWFza3JOVVpx VmhVWkZac1kzdFRXcHhwakdvR1J0VGFVMGxTQVZJbjNhanFSTTdhYVF5L2JmNnNWTnhVRnUyRVg2 MUxuaXRrUVZCZ1ZJcmdkTVZSM042MGJqNjFtcEZXTkh6ZTJhaWFZQWZXcVlKOWFVQTVvNXhXSkdH VnFJb1IycWRhbEFCN1VXdU5GTGFmU2xVSDBxK3FMNlV5NHhGR01MOTZqbEFyRE9ha1dvVEs1Tkht T085SzR5NG85YWtVaXM4eXVSak5IbUh1YWZNS3hxQnd0S1pBZTlaZ2MrdE95ZldxNWdzV1pKUE13 UFNvWFF1T08xQ0NwVTcwdHhGVFlmU2xDa2RxdnFxbnRVZ2lVOXFmSUZ6T0FOU0wxcEpwOE1VUk5w WGpOUSthK2M1cWRobHZITlRLS3ovUGtvKzBTSGdtbnpDc2FZSUhlcEJJQjNyS0VySHZUZzdldFZ6 QlkwMmxHTTFYZGc3WkhwVmNFbjFxUkJpbmU0RFpJaWN0N1ZDWXlUMHE4bjNjVklGSHBTNUxnWjZx UWNZcDR6Vi9ZbU9jWXJPbXV5WlAzWEFINjBPTmdKbFBOVEw5NnM3N1RKbjcxSDJxYlBXa3BwQlkx aGdVOVdHZXRZd3VaUWNscW5FcFBjMVhPRmpVM2oxcGpTZ1ZSRHNlOU9ISjYwK2E0aVpobXF6UmRz VmFYMXFUZzBPTndLQWpJN1U0S2ZTcjRRVkZjeUpicG5BM0hwUzViREs0eUttVHBXY2J1WTk4ZmhT QzZsSDhYNlZQT2gyTmRlYVVFQ3NqN1hML2YvQUVxU0c0ZHdWSi9HcVUwS3hxWkFvTGpIV3FBa1k5 NmVHSjcxWE1LeE83WjRxRjBMaWxVR25yU1lGUXhuTktGeDJxNWptamFNOUtYS01xZ0duWnFPN25N VW14QmcrdFZ2dFVwNTNWTGFReS9pcmxqcVY1cHpadExtU0x1UUR3Znc2VmlmYXBmV2srMVMrdEhP Z3N6MGpTL2lCTWpoTCtFRVovMWtSL29hN093OFFXdDRtNktaWEhCd0R5SzhLV1hlS21pbWtpY1BH N0l3T1FRY1VySUQ2Qlc3alljTlVnbno3aXZGckh4WnFWbW9WbkU2aisvMS9PdWxzdkhkcytGblY0 ajc4aWxZRDBaYmpaOTEyVDZIaXJFT3EzTnVRWVppdis2ZHY4cTVDMThSV2wwb01jNk51NXdHNS9L cnlYc2I5R3BXQTdPRHhkZlE0RW0yUWY3YTUvVVlyU3QvR3RzM0Z4YnN2dkcrZjBPSzgrRnlwNlBS NTJlK2FWZ1BWSVBFdWt6Zjh2WGxuMGtVcldsRGNXOXd1WVo0cEIvc09EWGpIbWVuRko1cm9jcTdB K29vc005dDIwWUZlUFFlSU5WdGY5VGYzQ2owTGJoK3RhRUhqdldvZnZ2Qk1QOEFwcEhqK1ZGZ1BV S1hGY0JEOFNKUi93QWZHbUkzdkZML0FJMW9RL0ViU1gvMTl0ZHcvd0RBUXcvU2tCMTJLTVZnd2VO ZkRzLy9BREVValBwS3BXdE9EVjlNdWgrNDFDMmsra3EwQVc4VVlwVjJ1TXF3WWV4elM3Y1VBSmlq RkxqM294UUEzRkdLZGlreFFBbUtNVTdGSmlnQk1VWXAyT0tNVUFKUlM0cE1VQUZGTFJRQW5hbDRw Y1VVQUpSUzRvb0FTaWx4UlFBbUtLS0tBREZGRkZBQ1VVdUtLQUV4UmluWXBPYUFFeFJpbllveFFB M0ZMaWxveFFBbEZMUlFBbEdLWEZMaWdCTVVZcGNVWW9BVEZGT3hSaWdCdUtYRkdLV2dCTVVZcGFY RkFEY1V1S01VdUtBRW9BcFFQU2hpcURMc0ZIcVRpZ0JNVXRVYmpXOUp0ZjhBWDZsYXgvV1Zhekp2 Ry9oMkhQOEF4TUJLZlNKR2FnRG9jVVZ4ODN4RzB0ZjlSYTNjdnVWQ2lzK2I0anpOL3dBZStuUnA3 eVNGdjVDZ0QwREZMaml2THB2SE9zemZja2hoSC9UT01mMXpXZk5yK3AzUCt1dlptOWk1QS9TbllE MXVhNnRyY1ptdUlvLzk5d0t6NXZFbWx3Zjh2QmsvM0Z6K3ZTdkt2dERzZVpHcFBNenlUays1b3NC NkpjZU5MWmNpR0hKLzJtei9BQy94ck11UEdGM0tQM1h5RC9aQVgvRTF4L25BZHhTRzVRRGx2MW9z aEc1TnJGNWNObDVjSDE2bjh6VlZwV2xPWGRtUCswYzFrUHFNU2M3aFdUZWVMckMyVGQ5cFZ1Q1FF TzRuOHFhUUhXR1JWNmtWQTk5RkgxYXZPTC94NDdLUmFRa2tqaHBEajlQL0FLOWM1ZTY5cU45a1NY THFoejhpZktNSHR4MXFsRmdlcDZqNHQwK3h5c3R6R3JnNDJENWorUTVyamRTOGYzRSs5TEdMWVA4 QW5wSjE2ZjNhNHJyM0pwdlRwVDVSRis3djduVUpmTXVwM2xZZE05QjlCMEhTcS9GVml4cGp6YkJu clZYc0JjcERXYjlwbEI2MHYycWIxcWVkRHNYbTYwd2dtcW4ycVVkNnMyVndacFBMY1pQVUdtcEpn QlRQWTBDUG5wVi9ZQjJwdUIxeFQ1UkZlT1BCelU2TnNOS3hCRlJ2MHA3QVdRd28zREhXcVJaaDNw aGR2V256V0VYaWFaV1pKY3NPRkordE5GM01QNDZsekhZMFQwcUk1TlUvdGMzOTZsVzdsWCtMOUtu bUhZbllVenl5YTBJTVRSQ1FqOEtjVVVkcXJrdUl6bGlKNHhWaFYycmp2VTVBR01WRzFITFlMajBr R052ZXBONFBlcVRjSGlveXhIUTArYXdHZ3pEMnBoMjFRTXJBZGFnTnhKdTROVHpnYVRqQTZWQzlW RGRURWRhVDdSSjYwdVlMRTdBK25GTUtFOWpTd1hXSlAzb3l2cldqNWE0NEE5YUVyZ1pmbCsxUFdF NXE4VkE3VTFzQWU5UGtzQkdyQldCcWRaUWU5Vm02VkVTUjNvdllEUU1nUEdhWXhIclZCblByVVps WURnMGM0RjhqUFNvbTcxVUV6cjNOSjU4bnJVdVFXSm16MHBoQklwZ21jY2lydHN5VEFnajVxUzFH VXRoOUtGVEJyVGFOZlNveUZIWVUrUUNza1pUOGFtU1FSOFk1SnBIUFBTb242OFVMUUM4SlI2MDFu QjcxUUxIRk1NaDlhT2NMRjVpRDNxTmh4VlR6R3BmTmZHTTB1WVZpWTlLaWFrOHhzVUJ5RG1rTWFR ZlNqQjlLdVFoWkZKQzRwN0lvN1Vjb0ZBS1Nha0NFREZXTUtPMVJ1ZWFkckFQU1FBQmFsRXdBeG1x VGZlcHVUNzBjMWdHMFVVbmVvR1BXcEFPYVl0UHFraERoVWltbUNuTFRRYUU4WnpSZFI3NGNqcXZO RVZXVXdPY2Mxb2xvSXhQU2l0UjdLTXliL3dDSCs3VldTSkZjZ0FZck53c081Vm9wVDk0MGxRTWV0 U3FLaVRwVXkxYUVQSEZPV20wcTAwSW1XckVmVVZXVHJWbVByV2lFWjk1QXNibGxMRmp5UmppcW1N VnZPbm1Sc25UUGZ2VlpyS0tLRmdSdVBxYWlWUHFNeXFLdWVVaC9ocW93d2F6YXNVT1dwVUZRcFU2 VTBKc2xVVklLWW9wL2VyUWg2bXBGTlFqclVxZGF0Q0p3dTVDRHhuSXpXUmQydjJaMUhMQWpyV3du U25TUkpOR1VjWkg4cWJqZER2WTUzclIrZGF4c0lvb215Ti91UlZhZUtNTDhveDlLeGNHaDNLWUdU VmhLaEF4eG5OVEpVb055ZEJ4VXFyVWFkS2xyWkNIQ25xZWFZS2V0VUlsV21YTnVzOFJ6MVhwVDA2 VktLcTF3T2JaV0RFRUhpay9BMXUzRmhGTzRjOEVlZzYxRkphMjZ2Z1JqOHF3ZE5sWE1lcG9Sam1u enhJSk1xTUFkaFNLTVVyQVRvTTFNb3FKT2xUQ3JTRUtCelRoUlFLc1FvcDRwb3A0SEZOQVorb1JZ WVMvUVZuOUs2QmtEcHRZWkJxcWxoRkh1Skc3UFlqcFdVNmVvN21UOWNpZ0RKclNlM2lDbkNBZlNx b1FJeDcxRGpZZHgwYTdSeFV3RlJyMXFWUlZJUW9GT3dLQUtXckFGSlU1VWtIMnE5YmF0ZlcyMFIz TDdSd0FUa1ZSRktCelJZUjBWdDR0dkk4Q1pGY2VvNE5YYmZ4M2E3dHM2eVJIUHB1RmNsaW9aclpa ZWVBZlVVbkhzTTlMdGZGRmhjbkVkeWhQb1d4V2dtcFJPQVF3SU5lUm0yakNqNVJTQjVZR1V3VFNS NC91dGlwNVJuc2EzU04zRlBFcU42VjVKQnIycFE5TGtzUDhBYUdhMFlmRmQ0aWdPaU1mWHBTc0I2 VDhoNzBiVjdOWERSZUx3TWI0WDl5RFY2THhaYUZnQzdMbnVWcFdBNmtvMlB2QTFFYmZQT3hEOUt5 SXZFZG01QUZ3bVQ3MWRqMWFHVGdTS1QvdlVBWFVhNHQrWXBiaUkvd0RUT1ZoVnlIeEJybHQvcXRX dlY5bWZkL01WbUxmeG4rTDlha0YwaDcwV0Ezb2ZIWGlTSC9tSVJ5ZjlkWUFmNVZlaStKV3R4NDh5 MnNKUjlHV3VWODZOdlNqOXkzWVVXQTdlTDRwWEEvMTJqeHQvMXp1UDhSVjJMNHBXSi8xMmxYaWY3 aFZ2NjE1MzVjUjdmclNlUkdlNUZLeUE5UWorSm5oOS93RFdMZXhmNzBCUDhxdHgvRUx3dEoxMUx5 Lyt1a2JML1N2SS9zNDdTRVVodDIvNTZmblJaRFBhWXZHSGh1YjdtdFdmUFl5WXE3RnJXa3pmNnJV clIvcE10ZUROYUZ1dmx0OVJVVGFlbmVHSS9nS0xBZlE2WE51LzNKNG0ramcxS05wNk5YemlMRUww aHgvdXRqK3RTTEhjUmZjbHUwLzNKM0g5YUxBZlJlMmt4WHoybDVxY1orVFV0VFQ2WERWT211NjlI OXpYTlNIMWt6L01VV0E5OXdQV2pqMXJ3aGZGZmlXUDd1dlhSLzNrUS8wcVpmRzNpbE9tczUvMzdk VFJZRDNIRkdLOFVYeC80cVQvQUppRnMzKzlhai9HcFYrSTNpa2Y4dHRQYjYyNS93QWFRSHMxRmVP cjhTL0VvNnBwamY4QWJOaC9XcEI4VVBFUTYybW1IL3ZzVUFldllvcnlRZkZMWC84QW9INmNmK0J2 Uy84QUMxTmMvd0NnWnB4Lzdhdi9BSVVBZXRVWXJ5Yi9BSVdwcm4vUUswLy9BTC9OL2hSL3d0WFhQ K2dUcC84QTMrYi9BQXAyQTlaeFM0cnlYL2hhdXVmOUFuVC9BUHYrMytGSC9DMWRjLzZCV24vOS9t L3dvc0I2MWlqRmVTLzhMVDEwL3dETU0wNGY5dFgvQU1LYWZpbDRnN2FmcG8vNEc5SUQxekZHSzhn YjRuK0l6MHRkTFg4SE5SbjRsK0p6MFhURitrVEgrdEFIc2VLTWU5ZU1OOFJ2RlJIL0FCOGFldjB0 ei9qVVRlUHZGamY4eEsyVC9kdFIvalJZRDIzSHZSajNyd3h2R25pcCt1dGxmOXkzUVZDM2lueEsv d0I3WDd6L0FJQ2lyL1NuWUQzcmJSdHI1L2ZXdGRsKy9ybXBuNlM0L2tLZ2U1MUtYbVRVOVRmNjNM VXJBZlF4MnFPVGo4YWllNnRvL3YzRVMvVndLK2VXaGxrKy9KY3YvdnpzZjYwejdCR2VzSVArODJh ZGdQZjVkZDBlSC9XNnBacDlaMXFsTDQwOE13L2YxdXoraXlidjVWNGV0aEd2U0dJZmdLbFcyMjlO aS9RVVdBOWZrK0l2aGFQcHFKay82NXhNMzlLcXlmRTdRVi8xVWQvTC91d1kvblhsdmtuL0FKNlV2 a3JqbHpSWkFlaXkvRk96SCtwMGk4Zi9BSDNWZjYxVGwrS1YwZjhBVTZORXYvWFM0ei9JVnd3ampI ZjlhWEVRUFQ5YUxBZFZMOFNkZWsvMWNPbncvd0RBV2MvenFsTDQzOFNUL3dETVNXTWVrVUNqK2Vh d3ZNaUhvS2FiaU1keFRzSTBaZGMxcTUvMTJyMzdld2wyajlLcE9KSnVaWkpwVDZ5U3MzOHpVSnZV SDhWUnRxQ0RxMzYwV0FzckFxOUVVZmhVb1hIZXNpVFc3Wk01bVFZLzJxcFNlSjdKU1I1NDQ5S0xB ZExrRHZTYjBYdlhHeWVMNE5wS0xJeDlNVlNsOFhTbFQ1Y0dENnMxT3pBNy93QzBJTzlOYTlqWCtL dk5adkV0L0xqYXlKOUJtcU0ycTM4eCtlNmtIKzZkdjhxT1VEMUdiV0xlQmQwa3FJUFZteFdWZCtN OU50c2czU3NRTTRqK2IrVmVadXpOMVluNm1vV1RjUlJZRWR4ZGZFS0wvbDN0cFpQVXNkditOWWR6 NDExYWZIbG1PSC9kWFA4QU9zbU9DTWc1UUdwQmJ4SEkyanBpamxBU1RVTDdVSDIzVjNNNmxzNEo0 ejlLblZkaWhldU9LU0dBUXFWeVQ5YWt4V2tZMkUyTUlwS2VSVGNVeENVMGppbjBoSEZJWkV3cUNS ZHdBOUtzdFVCcVdNcWRLS21aTnpWYWhnaUs4b0NhaFJ1RnpQeDdWb2FiRGxqS2VNWldwdnNFVW0w ajVjZFFCMXE0cUJGQ2dBS08xYVJwdENiRUlxTW1wRFREMXJSaUdVbUtjZXROTklaR3dxRnVLbmJw VmVTb2tCVmxYQnpVZlNwMjRwSW8xTDg4MW1VUTlzMG9Vc2NET2ExVXRvU3cvZHJ6N1ZOYldVVUVt OGZNZjlvVmFwM0Zja2hqOHFCVS9Pa2Z2VXpWQzliYkt4SkV4N1V3MDQwMm9iQVl3cUY2bmFvWDZW TEdWM3FBakJxZDZoWVpOWnNhRW9xeGJ4cXg1R2F0aXppbVhieXBIY1UxQzRGYXh0MW5rTy9PMWVm cldvd0FIRk9qaVdHTUtneDNwcjF0Q1BLaVNGelVUR3BIcUkxTEFRMUV3cVNtTlVzWkN3eFVMVk05 UU4xck5qUWQ2S0FCVnVPTk5vTzJoSzR5cC9uaXRPMXRmS0FmZDFIU25RV2NheWIrdit6Vmw2MWpD eExaQS9GUU1hbmZwVmRxY2dHRTAwaW5HbW5wV1l5TmhVVFZLM1dvbXFXTVNqcFJUazVZQWppa0Ey bFhrZ2Z5NjFNRVhjUGxxN0RiSWt2bUtjWUhTclVSRFlJaEZHY0hJYjFwSElxdzFWbnJSaUltTlJu bW5OVGFnWWg2VkdSejNxUnFqTlNBMmlpaXBHUFduaWlpcVFtT3A2MFVVMEs1UEZWbGFLSzFRRGow eFZDYkhtR2lpbE1aU2I3eHBLS0t4WUQwNlZNdEZGTkFQcFZvb3FrSmt5ZGFuU2lpdElpSndham41 amY2VVVWVEFvbnZWRnFLS3hrVUt2V3Awb29wSUdTclVnb29xMElVZGFtU2lpcVFpZE9sU0NpaXJR RVUvd0J3MW4zUENxUlJSV2N4b3FZNXFSS0tLeUdXRXFZVVVWcWhEaFQxRkZGVllSS2xTaWlpclFE dWxWWnZ2MFVVcE1TM002YmxqVWE5YUtLd2U1WllqTlRMUlJWSVE4VXVLS0tzQndGUFdpaW1oRHNV MWhSUlZDUlZrKzRhcGtjMFVWaklwRGxGU3JSUlNRRHdLZGlpaXE2QUdLVUNpaW1BN0ZKUlJUUWhy Q3E4b29vcVdORVlGUFVVVVZBeDRGT3hSUlZpWVlweTVVNVVrZlNpaW5aQVNwYzNDSEt6U0FqL0FH cW5YVmI2TWpGd3grdEZGRmtDTEVmaUMvVWpMcVIvdTFZVHhSZEwxaVEvUTBVVkxTQW5YeGVWNGVC dW5acW5pOFl3RWZPa2luNlpvb3FiRExjZml1elk4eWxmcXBxWmZGRm1mK1c0SDF5S0tLVmdMRWV2 MmpnYlowNS8ycW5UV2JjNEFtanlmOXFpaWtCTU5SalA4V2FldCtucUtLS0FIQzlqL3ZVNFhrZnJS UlFBOFhDTjNwMjlEM0ZGRkFCbU0vM1RTWWgvdXIrVkZGTUEyd24rRmZ5bzJRLzNGb29vQVR5NGY3 aTBlWEIvZFdpaWdCUExnL3VMUjVjSDkwVVVVZ0R5NFA3by9PbDh1RCs2S0tLQURaQi9kRkcySCs2 dEZGQUFGaEg4SzB1SXV5citWRkZNQmYzUTdMK1ZHNk1mM1IrRkZGSUJwbWpIcFNmYWtIZWlpbUEz N1loL2lwcHZVSDhWRkZJQ0p0VGhWdHBkZDNwbm1odFJqSDhRRkZGTUN1ZGF0aC95MmovNzZGUXll SWJTTVpOd25wdzJhS0tMQVYyOFQyWS81YkQ4QWFxdDR0dHYrbW41VVVVMGd1VjVQRnlaK1NGMkhx VGlxc3ZpMllqOTNCZy83VFVVVVdRRlYvRk44d0lWSTF6MzVxdC93a0dwT2NHWUQ2S0tLS0xCY2Fk UXZHNjNNdjhBMzFVRFNTTVNXa1lrK3JVVVZkaFhFQW9Jb29waUc0b3hSUlFNS1lhS0tsZ1J0VE1j OUtLS2tDZUVkYW5RZk5SUlZvQ1RGQkZGRld0aERTS2JpaWlwWUJpa1BTaWlraGpHcUFpaWlwWTBN QTVxNUFQa05GRkMzQXV4RDVSVDhVVVZ2RWdZYWpORkZUTGNZMmtORkZJcXhFM1NvWk9sRkZReEVE RE5MR01FVVVWSFVacFJmZUZXL3BSUlc4ZGlHSTFRdlJSVEJFSnB0RkZRTWExUXZSUlVzWlhhbzZL S3pZMFQyMytzL0N0R0RGRkZheEZJc0dvbm9vclFSQTFSRVVVVm1BMGltTlJSVXNaQzlRc09UUlJX YkdoT2xYSWZ1TG1paW5EY1pveC9kRkszU2lpdWdnZ2s0cUJoUlJVTVpHZldrUFNpaW9zTWlhb1c2 MFVWREFLZEg5OGRhS0tRMldQNHhWOWVsRkZieEpZTjNxczlGRkVnSUdwdmFpaW9HSWVsUms4MFVW TEEvOWs9DQpURUw7VFlQRT1DRUxMOjA4MTI3MTExMTE1NQ0KVVJMOmh0dHA6Ly9wYW5jYS5ibG9n c3BvdC5jb20ucGFuY2Eud29yZHByZXNzLmNvbQ0KWC1SSU0tUElOOjJBRTNGNEM0DQpFTkQ6VkNB UkQNCg== --===============1565433240==-- From nobody Thu Jul 31 17:24:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93D01A031B; Thu, 31 Jul 2014 17:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.359 X-Spam-Level: **** X-Spam-Status: No, score=4.359 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_NONE=-0.0001, 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 UPIXU8D1eZx1; Thu, 31 Jul 2014 17:24:04 -0700 (PDT) Received: from BLU004-OMC3S24.hotmail.com (blu004-omc3s24.hotmail.com [65.55.116.99]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E2671A0319; Thu, 31 Jul 2014 17:24:03 -0700 (PDT) Received: from BLU406-EAS34 ([65.55.116.72]) by BLU004-OMC3S24.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Thu, 31 Jul 2014 17:24:02 -0700 X-TMN: [HSk1nVJ5w7BlHlF3OelGS5T2ow37iNG2] X-Originating-Email: [panca70@outlook.com] Message-ID: Content-Type: multipart/mixed; boundary="===============1715613763==" MIME-Version: 1.0 X-Client-ID: 345 X-Mailer: BlackBerry Email (10.2.1.3175) Date: Fri, 1 Aug 2014 07:23:46 +0700 From: Panca Agus Ananda To: oauth-request@ietf.org, oauth@ietf.org X-OriginalArrivalTime: 01 Aug 2014 00:24:02.0635 (UTC) FILETIME=[E56661B0:01CFAD1E] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/O8yGg-uGFKT1sIj-Q3AurEMTxFo Subject: [OAUTH-WG] Sent via Readability: Pinterest 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, 01 Aug 2014 00:24:06 -0000 --===============1715613763== Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
I've shared th= e following article with you from Readability.

---

"Pinterest= "

Read more with Readability: http://rdd.me/4dtuhtjx

He used = Pinterest to find his stride Join Pinterest to find (and save!) all the thi= ngs that inspire you.

---

Original URL: https://www.pinterest= .com/

Dikirim dari ponsel cerdas BlackBerry 10 saya= dengan jaringan Telkomsel.
--===============1715613763== Content-Type: text/x-vcard; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Panca.vcf" QkVHSU46VkNBUkQNClZFUlNJT046My4wDQpQUk9ESUQ6LS8vUmVzZWFyY2ggSW4gTW90aW9uLy9S SU0gQXBwLy9FTg0KVUlEOjExN2ZiODY0LTE5MTItMTFlNC04MjgzLTI1OTQ0NjY3OTg0Zg0KRU1B SUw7VFlQRT1XT1JLOmp1bGlhbmRlcmkxM0BnbWFpbC5jb20NCkZOOlBhbmNhDQpOOjtQYW5jYTs7 Ow0KUEhPVE87VFlQRT1KUEVHO0VOQ09ESU5HPUI6LzlqLzRBQVFTa1pKUmdBQkFRRUFTd0JMQUFE LzJ3QkRBQWdHQmdjR0JRZ0hCd2NKQ1FnS0RCUU5EQXNMREJrU0V3OFVIUm9mSGgwYUhCd2dKQzRu SUNJc0l4d2NLRGNwTERBeE5EUTBIeWM1UFRneVBDNHpOREwvMndCREFRa0pDUXdMREJnTkRSZ3lJ UndoTWpJeU1qSXlNakl5TWpJeU1qSXlNakl5TWpJeU1qSXlNakl5TWpJeU1qSXlNakl5TWpJeU1q SXlNakl5TWpJeU1qTC93QUFSQ0FYWUJkd0RBU0lBQWhFQkF4RUIvOFFBSHdBQUFRVUJBUUVCQVFF QUFBQUFBQUFBQUFFQ0F3UUZCZ2NJQ1FvTC84UUF0UkFBQWdFREF3SUVBd1VGQkFRQUFBRjlBUUlE QUFRUkJSSWhNVUVHRTFGaEJ5SnhGREtCa2FFSUkwS3h3UlZTMGZBa00ySnlnZ2tLRmhjWUdSb2xK aWNvS1NvME5UWTNPRGs2UTBSRlJrZElTVXBUVkZWV1YxaFpXbU5rWldabmFHbHFjM1IxZG5kNGVY cURoSVdHaDRpSmlwS1RsSldXbDVpWm1xS2pwS1dtcDZpcHFyS3p0TFcydDdpNXVzTER4TVhHeDhq Snl0TFQxTlhXMTlqWjJ1SGk0K1RsNXVmbzZlcng4dlAwOWZiMytQbjYvOFFBSHdFQUF3RUJBUUVC QVFFQkFRQUFBQUFBQUFFQ0F3UUZCZ2NJQ1FvTC84UUF0UkVBQWdFQ0JBUURCQWNGQkFRQUFRSjNB QUVDQXhFRUJTRXhCaEpCVVFkaGNSTWlNb0VJRkVLUm9iSEJDU016VXZBVlluTFJDaFlrTk9FbDhS Y1lHUm9tSnlncEtqVTJOemc1T2tORVJVWkhTRWxLVTFSVlZsZFlXVnBqWkdWbVoyaHBhbk4wZFha M2VIbDZnb09FaFlhSGlJbUtrcE9VbFphWG1KbWFvcU9rcGFhbnFLbXFzck8wdGJhM3VMbTZ3c1BF eGNiSHlNbkswdFBVMWRiWDJObmE0dVBrNWVibjZPbnE4dlAwOWZiMytQbjYvOW9BREFNQkFBSVJB eEVBUHdEdzlldFRwVlR6Z0tVWE9LdE93aUtaL01rWS9oVE1VcllKSkZHMG1wWXhLS2VJbU5POGg4 OXFMQVE5NmN0VEMyYW5DMllVSk1CaW1uaWtNVERtbkFZRlVJa1VWS2d4VUJrQ2lnWElGVmNSTmNT K1ZIbkdRZTFacHdXUGFyTXNvbVhCNHF2c05UTFZqRXhSVDFpWnFjTFp5TzFSWUNIdlVpNXFRV2tu SFNwaGFITlVvc0NKVFVpbW5mWm1GSjViSzFYWVE3dG1wVUZSaW5OS0ZvQW5VWU5RWHN3UUNNcUND TTBuMmtDb3JobG5UZ2ZNTzlOdlFDblJpcFBJZjJwd3RuUHBXVm1NaHBRY0dweFp5SDBweTJNbTc1 c1k5YWZLeDNHcjFxWlQycVFXaHAzMmNqdFZwTWthcDVxUmVUVVlSbFBOU0t3WHJWQ0pWSE5TcnhW VTNDanBRTGxlL05PNFdLbC9ONXMrM0F3dnBWU3JFc08rUXNnQUZNRnM1OUt4YTFLUkZSVmdXY3A0 NHAzMkNiMi9PaFJZWEk0VDJxeXZGT2dzV1FFdDFxWVd4Rldvc1ExV3FWVG1tK1FSU3FNY1ZhUWlR RG1wRnFMekF2ZW0vYUZxa3dKNTVQSnQzY2RRSzU1dm1aajZtdGVlWHpiZDBIVnVLei9za250V1U5 V05GZkZMakZXUlpTbjBwUnA4eDlLejVXTzVWQnczMHJRaTVBTlJmMmJQaitIODZ2cGJFS0I3VnBD QU5qRk5TZzBlUmlneGtWb2tTT0hXcEZGTUhGSzBvWHZWQVRBVm1hdE1keXc0NCs5bXJnbkFxbmV3 L2FXRHA5N0dLbWIwMEJHWmlreFZyN0ROMjIwNGFkTWY3djUxaHlzcTVVeFZpMGNMSnNQUTFLTk1u UGRmenFXMzAxMG1Ca3dWOWpUVUdEWk90U3FhY0xmRkw1UkZicU5pUVUwOFV3REJwNE9LWWg0RkRu Wkd4SFlacVB6Um1rYVVNcFU4QWpGTUxHRmNUQ2VRdUVDazljVkZpcmphZkp2SVRsZTFBMHU1Ym90 Y3ppN2xvcDRvclRYUWRRWVpFTEVldUtrVHd6cUw0SVJSOVdBcWVVZHlHeWtFaWtBWUMxZVU0cTda K0hibU9IYTRSVzduT2F1TDRmbHp5NjQ5aFcwV2tpR1pRcDliSThPbi9ucTMvZkgvQU5lcG8vRDZC Y09YSjlRY1ZYT2dzWUlwUlhScm9FSUk0WSt4UFdwbDBTRHZFdjYwZTBRY3B5RjNMNUZ1ejdkMk8x Yys3QjNMQk1aN1Y2bU5GdHlwVXhJUWV4WE5PR2lXZ3gvb3NJeDNFUzFsT1hNVXREeWdJVDBRL2xU dktmOEF1TitWZXRKcGNFYTRTSkZCOUJpcGhacmpIYjYxRmhua2tOcGN1L3lXMGo0NmdLYTI3U3l2 WllRLzJTVWRzYlRYb0lza0hhbkMwakhZVlVYWVJ3d3Nib2RZWkIvd0dwVjA2N1AvQUN5L1d1MUZ0 R093cHdnUWRxdjJqRnluR2pTcnpIM0Yvd0MreFNmMlZlZjg4LzFGZHA1S2VsS0lrSGFqMnNnc2Nn dWhYTHJrdWkreHovaFVWMTRadkpvaWlTd2pQYzd2OEs3WUlvN1VvVWVocE9iWTdIbkk4RTN2ZWVM OWY4S0I0SXZEL3dBdDR2eU5lajdCL2ROR3ovWk5aZ2VkandQZGQ3aFB3V3JkcjROa3QzM201Sk9N WUMvL0FGNjdyWWY3cHBmTFA5dy9sVEE1RWVHMkgvTFkvd0RmUC8xNmNQRHJmODlqL3dCOC93RDE2 Nnp5ei9jUDVVZVdmN2pWZlBJVmpsUjRlR2ZtbGY4QUJSL2pTLzhBQ1BKL3oxay83NUgrTmRSNVov NTVuOHFQTFA4QWNQNVV1ZVFXT1dQaDFNY1N5Wi8zUi9qVVQrSEgvaGwvTmE2N1lmN2pmbFJzeC9D YU9lUVdQUEx2d2ZmVHlsMWxpeDBHYzFYL0FPRUt2LzhBbnRCLzQ5L2hYcFd6L1pOR3hmN3BxWHFN ODBid1hxQUdROExIMEdmOEtoazhKYW9uM1VqYjZOWHFHMWZTa0tvUmpGRmtNODlzdEcxR09JUnl3 aGR2QStjVmFPbFhpamxCL3dCOWl1MjhwUFNrTUtWY1p0RXRIRHRZM0svOHNpZnB6VGZzVnlla0Vo LzREWGNmWjA5QlNmWms5QlZlMVl1VTRacks2SFdDWC92bW9IaWxVbFdSZ1IySXJ2amFJZXdwRFpw NlVlMEh5bm0xM3ZqZ0xCR1BicFdLVllkUVJYc1RXU01wVThqMHF2SnBGdEkyWGhqWStwVUdzNU83 dU5Ia3RINFY2cStoMmJESDJXREgvWE5mOEtyeStHTlBkaXpXMGZQcHgvS3BzTTgydDVQSm5WOFpQ cFhSeHNIUU1QMHJvSDhKNmMyTVd5akhvemY0MHErSFlJMTJJR0MrZ05hVTVjdTVMMU1BaW1FVnZ5 YUNQNEdaZnFjMUUyZ0VEL1d0L3dCOC93RDE2MTU0azJaaWRxalkxcm5RcmorK2crdWFnYlJib01j QlQ3NXhSeko5UjJNdHVhekx1VDV5aFhwM3JvbjBxNVU4eFpQK3ljMW1YdWkzUG1ieEd5azljakZS TlhXZzBZMUZYanBOeU9vRk4vc3lmL1ovT3N1Ump1VThWZTA2NEVjb2pDRExuRzZtZjJkTVBUODZz V1Z0OW5tM3lnSDBxb3BwZ3pWUDVVMDFINXd4U2VhRDNyb3VReFdwcDRGT0p6U01wSTRwQVJNYWli bXJQazhVaHQ4MG1oM01TYVRleDR4ZzRxT3RHZlRuYVFzZ0czMHpVWDltVGorNytkWU9EdVVtVTZN VmIvcytZZWxNK3hTKzM1MHVWanVpN3Bsd0NSQ0VBQUdjK3RhQkZabG5EOW1ZdTUrWThERlhQdEMx dEI2RUVqQ21FWXBCTXBPS0NjMVFER05RdlV4UW5wUjluSnBXQXBTSENrK2xVVHljMXNTMmhaQ1B5 cWtkT25IOTM4NnlsRmxKbFRGRld2N1BtQTZpbW15bEhwVWNySGNycWRyQTQ5NjZDR1R6b0VmR053 eldNTFI5M2JGYU1jeXd4TEdPaWpGYVU5Q1dXR3FOaFRmdEttbEVxc0sxdUlZYWpacWxJeUtZSVdO U0JYYzVxck54eFdrYlltb0pyS1J5Tm1NZDZoeEdtVUtNVlord1RlMzUwaHM1QjZWbnlsRmZGVzlP bDJUN1A3MVJHMmNjY1U2Q05vcGxjNHdLYVRURWE3VkV5MUVib2U5SjlvVTF0eklrVThWRy9GU013 TlJzcGJwVWpJbVBGUk5tcmYyWWtVMDJoTlMwMkJubnJTWXEwYktUUEdNVTAya2c5S25sWXlDaXBU YnVQU20rVTFUWmp1YWRyTjVrQTZBanNLYzNTcVVFZ2dYa0RKNzFMOXBCclpQU3hJOHJtb3p4U2la VzRwRHpTQkVUR29tTlQrVVdQRkJ0bXBXR1V6UUt0TmFFcngxcVA3TElQU281UUljVVkrdFN0YnV2 cFRUR3dvNVJpUnNJMjNiYzRyVERiNHdlbVJXWUZ3UjZWYSswaFFCVlJkaEVqQ28yNDdVMDNBTkc4 TXRPNGhLalk4Vko5S2FJaTFTTWdKb0ZUL1p5ZTFJYlpoMHBXQWhvcVR5SDcwMHhzS0xERzRvNEhh Z2dpa3hudlNBV2lpaWdRcTA4ZGFSYWVBS3BBT0hhcFZOUkNuclZDSjA1cVpSeFVNWFdyQzFhRU5a T2VhcHlERG10RWpqTlo4dk1qVVRHVTJKM2RhVE5LM1UwbU9hd0tIam1ucXRNVHRVeTFTRXh5akZT SWNjVXdEdlRoMXFoRXltcGxxdXZXckVZcTBBL2FLamtYRVo0cWRSVEorSTIrbFcxb0lvOXFxc3hC UE5XajBxaTNCTllTS1E1VGsxS29xRlR6VTZVa0JJcTFJdkhGTlduOTZ0Q0hxY1ZLcHpVQTYxS2xX Qk90UEs4VTFPbFNDclFtVjVWd3ZTcWMvQ2lyODMzS3o3bmxCVVRCRmN2elRsNXFIdlVxZGF4VEdU cUtlbzVwcUNwZ0sxUWh3cVZUVVFwd1BOVUJNdFNENlZHbFNyMXEwSmlGZldxN2pEVmJ4a1ZXbCs5 U2tCUWtmREdtQnNtaVlZYW1MMXJGbEU2YzFNcTFGSDBxZGFwSVE5UmowcDY4VTBDbEhXckFsV25p bzFOU0tLb1E3RkREaW5Da2JnVlFpcTV3cHFtWHEzSU1vYW9IaHF4a1VTS2FtV3E2ZGFzb0tTQWVv cVFDaUtONUdDb2hZK3dyUWgwZThsSStUWVA5cXJ1a0JUQnB3TmJjSGh0eUFaSkNmVUFmMXJRaDBD Q01mY3p6MVk1cGUwU0N4eTRVbm9DYW1Xem5kUVJDK0QzeHhYWXg2YWlkRkMvUVlxVmJORjdWTHFk ZzVUajEwZTVjZ1lWZmZPZjVWS3ZoeVIvdnpZUCt5dWE2OFFvRDB6OUtldHV4SHl4dFVPYlpTUnlr WGhtSUw4N1NNZlhPUDBxNUg0ZnRsVUR5UVQ2a211a0ZsTTM4R1ByVWk2ZkpubGxGSzdBd1UwbUZR QjVNZjhBM3lLc0xaS294MjlLMjAwelBWMlAwV3BsMGoxU1FqMVBGSzRHQ0xSQjJwNHQwSFlWdnJw YUQrQlB4ZXAwMHNmd292NElUL1NnRG14RXZZWnA2d2s5RVkvaFhUalRDT29JL3dDQWdmenB4czQw SHp5S3Yxa1VVZzFPWkZ0SWVrVFU4V2N4NkppdHlTVFRJYytiZTJ5L1diLzYxVkpkYzhPd1ozNnJh L2djL3dCYUFLQXNwajJVZmpUaFlTZjNsRlNQNHc4THA5MitMbi9wbkZtbWY4SnJvcC8xTnJxTTJm N2tCLzhBaWFMZ09HbnQvZjhBMHB3MDRuK0pqOUZwRjhVdEoveDdlR3RZbS83Wk1LbFhWdkVFMlBz L2dtL1BvWk1qK1pvdUFEVFBhUS9oU2pUUVA0Vy9FMDlmK0UzbS93QlQ0TmpRZjlOWkZxWk5OK0kw djNORDB5RC9BSHBSUU1nR25wL2RIL2ZkT0duTDJRZm5tcmErSGZpWEovRnBFSC9BaWFlUEJ2eEZs LzFtdWFiSC91b3hvQXFqVFBTTC93QWRKcDQwcDg4UW44SXovaFZyL2hYdmphWC9BRnZpeTNUL0FI SURUeDhML0VqL0FPdDhaeWovQUhMZWdDcU5La3pqeVQvM3hUdjdLbEgvQUN6UDVDclErRTJwTi9y ZkdXb0gvZGpBcDQrRDViL1crSzlXYjZFQ2dDbi9BR1UrT242cVA2MERUVzdsUi93SmY4YXZENE5X Ui8xbmlIV1cvd0Myb0ZQWDRNYU4vSHEyc1A4QTl2RklET09uRWZ4eC93RGZ4YVBzQ2Z4VFJqL3Rx dGFnK0RIaDBmZXU5VmI2M1JwNCtEWGhqdStvdDlicHFBTWMyVVEvNWVJZisvb3BQc2tQL1B6Qi93 Qi92L3JWdUQ0TitFeDFqdlQ5YnBxWC9oVG5oSC9uMnV6L0FOdlRVQVlmMlcyLzUrb1ArLzMvQU5h ayt6VzMvUDNiL3dEZjcvNjFidytEdmc4Zjh1ZHovd0NCTFV2L0FBcDd3ZjhBOCtkeC93Q0JEVUFZ SDJhMS93Q2ZxMy83L2Y4QTFxWDdMYmRycURQL0FGMi8rdFc5L3dBS2U4SGovbHp1UC9BaHFUL2hU M2cvL24wdVIvMjh0UUJnaXpoUC9MekIvd0IvaC9oU2l4alAvTGVIL3Y2SzJ6OEhmQ1hhM3V4OUxw cVEvQnp3cWVpWHcrbDAxQUdNZE9YK0dXSS85dFZvR21FL3hwK0VpLzQxckg0TitHYy9MSnFTL1M2 TlJuNE0rSC80YjNWbCtsMGFBTTA2VS9ZZy93REExL3hvL3NtWEhBeitLLzQxZlB3YTBnZmMxaldV L3dDM2pOTVB3ZXRSL3EvRWVzci9BTnRRYVlGSCt5SmYrZVovSUdtZjJSTnorNVAvQUh3YXZuNFJ5 ci9xdkZtckw5Y0dtSDRWNnNuK3E4WjN3LzNvZ2Y2MEFVVHBNbmVFL3dEZnMxRTJtRURKaXgvd0Vp dEUvRFh4UkgvcXZHVG4vZnQ2VC9oQlBITWYrcThWV3IvNzhCb0F5enB3SDhDajhhVCt6aG5HMzht clNQaFQ0alJmYzFqUzVmOEFlUmxxTnRGK0pVWTVUUjUvK0I0L25RQm4vd0JtbnNqL0FJVTA2YTNw SVB3cTYxcDhRb3Z2K0h0Tm1IK3hLdFJHYnhsRHpONEwzZThVaTBDS2hzR0hkaCtGTU5rMzkvOEFT clRhM3JNUC9IeDRMMUpBUDdtVC9Xb2o0c2hUUDJudy9yRVByKzVZMFhBZ05tNDZGYVEya283S2Ft LzRUUHcvL3dBdG83NkgvcnBiL3dEMk5TcDRxOEt5L3dETVFSRC9BTGNlS0xnVWpiU0QrRDhxWVlI SFdNMXN4Nm40ZW4vMVdxV2grcmJmNjFhU0hUNXY5VmVXN2Y3cy93RDlhZ0RtVEY2b1IrRk1NU2Vs ZFovWlN2OEFjZkk5blUvMXBqYU0vb1QvQU1Bei9LbmNOVGxEYm9lMU1Ob2g3Q3VtazBkaDFSZnhV clVEYVY2SXAvM1hvQTV4N0ZISEl6OWFyeWFSQzR3WTAvNzVBcnBtMHB4azdKQitGUXRZTVA0aVBx S0xnY3JMNGZ0MzZSN2Y5MDFVbThOSVQrN2QwOWY0djhLN0ZyT1FkTUdtTmJPUDRQeXBxVEE0U1h3 MWNLeDh1VlN2cXdJTlUyMGEvaUJQbEFnZWpmMHIwTm9mVlNLWVlFUGFuenNEem9XMXhFcE1zTWk1 L3ZMVGt5SHdhOUFOa2hPUU1WWGwwbUtUT1kxT2UrM21xVlFWamk2Q09LNmFYUVlXUENGZm9hb3k2 QklCOGovOTlDdEZVaVR5bUtlbE1OWFp0THZJaC9xaXcvMmVhb3VySWNNcEI5Nkxyb0EzdFVUQ3BP MU5JNG9HUU54VVJOVE9LcnNhemJHS0g0eFZtRTVRMVJ6elYyMzRTaUlGeU5lS2ZqRk5qKzZLa3Jk SWtqTlJrNHFScWhiclVzWWhPYWpZZTFPTkpTWVdJR0ZSTWVLc09LcnlERlpzWkVXeFRrZmtZcUpx V01aWWMxS2VvR2tuSkZXQXRWNC92TFZ4ZVJtdG9pWTBqaW9qeDFxWTFBL2VtQTF1bFJHbkUwMnBZ RVRDb1dHS3NzT0toY2NWREdWMk5ORFlwWHFNMW1ORnVBNWJHYXVRcm1xRnI5NnRHMzcxcEFUSmR0 Tkl4VXhIRlF0V3JFUk1halk4VTUrdFJFMW14alQwcUpscVh0VEdxV0JBd3hVWk5TdlVMZGF6WTBP RGNkYXN4bktyVk1WY2hIeXJUanVETHFKOHZUOGFjVndLZEg5MENsYmdWdWlTQnVPdFJFMUxJTzlW MnFXTWF4eWFqWVpwNXBEMHFCa0pHS2lOVE5VVENvWUNVNU03aFRhZEg5OFVrTXNZNXEyc1k0cXAv RVByV2duSzFyQWtZVndLaGJwVTdkS3J2Vk1DTmpVWkdUVG00cHRaakkyR0RUQ09hbGFvejFwQU5w TzlMUlVqSHJVZ3FKVFR3ZWFwQ0gwNWFhS2tVVlNFVFJkUlZoYXJ4MCtXUVJ4OHR0SjZHckVQa3VJ b3lVTDgrbFU1VDg1NXFySTVrWXMzSnB1VDZtczNNcXdyZmVOSlJSM3FCajA3Vk10UXJVcW1xUWlT bEZOQnA2MVNFU0oxcXluRlYxNE5XRXoxclJDSk53UlN6SEFGUVBjUnlvK3hnZUtyWGx6a0ZVZjJJ cWdPQndjVk1wanNYODFSWS9NYVRuMU5CNU5adDNHT1VacWRLZ1hpcGxvUU1uV25qclVTbXBGcTBJ Y090U3A5S1lvcVZSelZpSms2VTZTVklVM3VjTG5HYVlwd3VUV2JmM0lsS29oK1hxUjcwMjdEdGN2 UE1ra1pLTUNPbFVyaGdGSE5VUVNCako5YU1udWMxazUzSHlqeHpVcVZBcHhVNlZDQXNKVTRxdXBx WlRXcUVQNzA0RG1taW5yVkNKVXFWYWlXaWFkSUV5NXg2VmV5Qm9WN3VDSmlydmh2U29tZFhJWlc0 UFNzZWFkNTJ5NXppbUJqNm1zWFVIWXN6dXU4ak5JdldxM1E1cWVKcy9Xb3ZjZGkxSFU2MVhRWXFk VFdxMkpKYWNCVFFhY0t0QVBXcFZxSUNwRnFrSWN6aU5DNzhBVkNMeUNWZ2lPQ1RWWFVibnlzUnhu NS93Q0llMVY5UDBpLzFTYkZyQzVHZnZuZ0Q4YXpsVXNOUkxrMGlwR2NuRlU0WTVMcVlKQkc4akhz b3pYYTZUOFBsQUQzN3RLZjdnNFd1dnRORXQ3T1BaRkVxTDZLTVZtNVhIWTg2c2ZDbDlNUTAySWxQ YnFhNkt5OEtRUkFGd1pHOVdycjF0MFVZQXA0dDI5TVVyc1ppUmFYRkV1RlFLUFFEQXF5bHFpOXEx NDdBdjhBd3MzOHF0UmFlRDAyL3dEQVJ1cFhBdzFnWThLaHFWYk4yNjRXdG1ZV2RtcGE1bmlqVWY4 QVBTUUwrZ3JJdVBHZmg2MWJaRmNHNGsvdTIwVzQvd0JhVndKWTlNTDlBN2ZRVllUUzFCNVZCL3ZO VkNQWDljMU00MG53cmV6RHM5ejhxL3JWK0x3LzhSdFJ4bit6dE1qUHA4eC9TZ1paajBzRDIvM1V4 L1BGRHcydHVNelR4b0IvZmxDLzQwNlA0VjZ2ZWM2cjRzdTJ6MVMzVFlLMGJiNE9lR1k4TmRmYkx4 dittODVOSURuWjlmOEFEdG4vQUszVXJVSDBVN3Y2MVNieHhvUWJiYkxlWFRla01ILzFxOU5zdkFQ aGZUOGVSb3RvQ083SnVQNjF1UWFkWjJ3eEJhd1JqL1pqQW9BOGFUeEpxVjMvQU1lSGhUVkpnZWhr QlVWWWpqOGVYWnpiK0ZyVzNCN3p5Q3ZaUWdIUVlwMjBVQWVScDRZK0k5MTkrNzB1ekIvdTViRlRy OE4vRmR6L0FNZm5pM3kvYUNDdlZjVXZ0UUI1aW53aDh6L2o4OFQ2ckw2aFdDVlppK0RYaHNmOGZF Mm8zQi82YVhKcjBYRkdLQU9KZytFL2cyRWcvd0JrQ1Erc2tqTi9XdFMzOENlRjdiL1ZhRllqM01R TmRIaWlnRE9oMFBTcmYvVTZkYUovdXdyL0FJVmNTMmhUN2tNYS9SUUtsb29BUUtCMm94N1U2aWdC dUtYQW9wYUFFeFJTMFVBSlJpbG80b0FURkdLS0tBREZHS1UwbEFDWTRwY1VVZDZBREZHS1NqdlFB VVlvNzBVQUdLVEZMUlFBbEdLS0tBREZKaWxwT0tBREZKaWxvb0FURkdLTVVVQUdLVG1scE9LQURG Smlsby9HZ0JNVW0wZWxPcEtBRXhTRmM5Um1uVWxBRUwyc0VuMzRZMitxQTFTbTBEU2JnZnZ0TXMz K3NLLzRWcDk2VEZBSE9YSGdQd3ZjNTh6UXJJL1NQRlpzM3dxOEl5NTI2WjVSOVlwV1d1MXBNYzBB ZWV5ZkNMUWV0dGVhcGJmN2x5ZjYxWGY0VjNNWE5uNHExT1Aya3cxZWxZcE1VQWVZdDRGOFoyby8w VHhWRktQU2VESDhxZ2ZSZmlOYmY5QXE5SDEyL3dBNjlWeFNZb0E4aWVmeG5hZjhmZmhDT1VkemJ5 TFZaL0ZVbHZ4cUhoclZiYjFJUm1GZXpGUjZVMG9DT1JrVUFlTlIrTXZERXAyelRUVzdlazhPUDZD cjBGOTRmdmNmWjlTdFd6L3Q3ZjhBR3ZUTGpTckM3R0xpeXQ1UWY3OFNtc084K0huaFcreVpkR3Qx WTk0eHNQNlVBYzBOTWltR1labGNmN0VpdC9oVU11ak9PMzVvUldoUDhJdER5V3NMdlViSnUzbFhC SUg0R3FqL0FBODhTMlBPbCtLNUhBNkpkUmJ2MUZBRkJ0TGYrRk4zKzQyYXJQWk9od2R5bjNGWDVi TDRoV0grdTAvVHRVUWQ0MnczNjFUazhWVDJYeTZ4NGIxR3o5WFJTNi8xRk1DQTI3anNEOUtZMFBx dUswTGJ4SDRaMUZ0cVgwU1NmM0psMk4vVCtWYVM2YkJPdTYzbEREMWpjT1A2R2dSekxXaU4ycXRO cE1Vd3d5Qmg3ak5kUEpwRWdiQ21OajZINVQrUnFwTFp6UWNTUnVuMUZPNEhHM1hoV0Z3VEhtTSsz U3NXODhPM3R1Q1VIbUtQVHJYcFFVY1VwdGtmdG1xVW1nc2p4bWVLU0Zpc2lNckRzUlZOeGl2WmJ6 UUxlOGoyeXhLeTQ3aXVRMVh3Skl1NlN5ZkgvVE52OGFmTmNWamhDNFZzRTFldHlObldxVi9wOTNZ ekZMcUY0Mjl4d2FyQmlCMU5RcFdIWTNWdTRVYllYK2JwaXJWY3ZrZzd1L1d0cXl1aEt1MTVOejlj VnRDcGNscXhiTlF0VXg3MUd3eFZzQ0kwaHB4QnBocE1CamRLcnlWTTFRdlVNWlhiaWlKMURpbXlO Z2tWRldSVmpZV1JVK1pqd085V0licUdSZ2lQa211ZnljWXlha2huZUZ2bE9QWE5XcGsyT2hhb0hw OGNpeXhCbFBCcHJDdHJpSVc0cHRQYW1WQURXcUY2bFkxQzVxUmxkK3RSR3BYNE5RazVySjdqUlp0 VyticlYyTzRpaWJEdGlzbmtkRFIxcWxLd1dPaFNWSlYzSWNyNjB4KzlVTE84MmtySzN5NDRBRlhq eU0xc3BYUkpDL1dvalV6Q295S2xnUjB4cWVhamFvWXlKNmdiclV6R29XcUdOQUt1UkViVjVxbUtN bjFvVHNNMkV1WWd3VGY4MVROMHJCQkt0dUhVYzFyUTNDeW9CbkxZNXJhTTdrMkI2Z2FyRDFBd29Z aUkwSHBTa1UwOFZER2lOdXRSTlVyVkVhaGpFcHlmZkZObzdVaGxuUElOWElaNDJPME44MVpWT2pj eHZsVGc5S3VMc0ZrYXpkNnJ2VDQ1VmtqNE9jZGFZMVcyU1FOVFIwcDdDbW5pb0dOYW82ZXhxTW5t cEFYWTNwU2JHOUt0aXBWVVZYTGNDaUVZSHBSZ2cxb2VXQ09sUnRFTUdueTJFUURnMUx1VmFoWTdW TlFsaWFWeDJMd2xVZDZiTVVsVVpZOFZTQk5PSHB6UnpCWURHd3BSRXhwd0hOU0wwcFd1QkVZWG9F TFZiVTVGU0tBYWZLQlNFYitsTHNZZHEwQW9QYWxaQUIwcXVRUlFRYzFNbmVsbGpDNHgzcUdSeXVN VXRnc1dRNkR2VDFtVWQ2ekN4ejFwVkpQT2FPY0xFOXhFcnR1VEdlNHFEeVh6aW5nYzFLbzVwYmdW L3M3MHB0WkJ6aXJRNjFNcHBxQUZKWUdIYW5MRS9wVjlRS2tDZzlxcFFBenRqZWxTSjBxNnlBOXFy eUtGYkFwMnNLNHFZQTVwd2tVZDZxU3lGVzI5cWgzblBXbHpXR2FnbFNzKzR0eTBwZE1ITk5ISjYx SUtUZHdLNHRwUGFuZlpKZmFyU0NwbE5Ma0M1UVcwa3o4d3FVUXZqcFY1Y1ZJcWowcXZaaGNvckU0 N0duWUsxZjJERk1aQVIwcXVVbTVBdldwZHlpb2o4b05WV2tKSjVvYnNVYUFsV216N0o0V1RkZ1Zu aGo2MUlNNDYwdWE0RlkyY2dQYWdXY3A5S3VyelVxamlwNUF1Wi8yR2IwRlN4V2pKejFyUVduZ0Ny VUF1VWhFM3BUZ2pBOUt2QlI2VXBVZWxWeUVzcUprZGFrV2xrWEZReVB0WGlrTXNCMXpVMXRETGR6 Q09DTm5ZOWhWbncvNFp2ZGNsVndwUzJ6ODBoL3BYckdpZUZyVFM0Z0lvc0h1VDFxWE93MGppdEw4 QUpQT3QxZjVkditlWSs2SzdlMTBpRzJRS3NhcVBRREZhOGl4V3kvTWNHcWhra256NVkyb09wTlpO aklpaVI4VTFZMmxiQ0tUVTBvdGJHRXoza3lJZzZ2S2RvL0xxYXdtOFdTYWxOOWo4TTZWUHFrdWNl WnQyd3IrUFNsY0RkanN1TXMzQTY3ZjhlbFVML3dBUWFIby9GemVSZVovY2ovZU9mOC9TcGJiNGUr SnRlSWs4UjYwYlNBLzh1dGx4eDZGcTdEUlBoNzRiMExEMjJuUnZOM2xtK2RqK0pwRFBQb3RlMXZX bTIrSC9BQTNjVExuaWU3RzFQMXJTZzhDZU05WHdkVzEyS3dpUC9MSzBUSi9PdlYwalJGMnFvVURz QlQ4VUFlZldId2c4T3dNSHZ6ZGFqTC9ldVpTUitWZGRZZUhOSTB0QXRscHR0QmorNUdNMXFVdEFE UWdIQUhGS0FLV2xvQVRGTGlpaWdBeFMwbExRQVVVVVVBQXBhS0tBQ2lrcGFBQ2lpaWdBcGFTbG9B S0tTaWdCY2V0RkZKUUFVdEhXaWdBcEtLS0FGN1VsRkZBQlJSUlFBVVVVZDZBQ2twZTFKUUFVVVVV QUhlaWlrb0FLS0tLQUNrcGFTZ0Fvb3BLQUNpaWlnQTcwbExTVUFGRkZKelFBVVVVVUFGSWFLTzlB QlNVdEpRQWMwVVVVQUpSUlIyb0FTaWlpZ0Fvb29vQVRGSlMwQ2dCTVVtT0tXaWdCQ0theUt3d1ZC SG9hZlNVQVltcGVFOUIxVlNMM1NyV1VudjVZQi9NVnpGMThKOUtWakpwRi9mNmJKMkVVdTVmeU5l aFVZb0E4dGw4T2VQTkhVL1pieXoxZUFmOEFMT1liSFA4QVNxUjhYemFZd2gxN1JiM1RUM2RVM1Iv MUZldTQ5YVpMREhNaFNTTkhROVF3eUtBUE9yUzcwWFdvdzlwTmJ5ay84OG0yUCtYVCtWRXVrT2pm NlBOa25va255bjhPeC9DdGZWL2hyNGQxTjJtanRtc2JrOGlhemJ5em42ZEs1NmZ3MTR6OFBCanA5 M0ZyZG1QK1dGd05zbVA1R2dCMitTMmZaY1JNcmZURldGV0tkZmx3YXo3VHhmWVRUQ3cxV0NYVExy cDVGMm55WjlqL0FJR3RLWFRrSytkYXliQWVoM2JrUC9BdTM0MHhHZnFQaDYxMUNCb3BvbGRXSGNW NXY0ZytITTl0dW0wM0xJUCtXVGRmd3IxZU84bHRaUEt2SXlQOXF0SklJTHVMY2hERDJwZ2ZNTDZm Y1J1VWROckRzYXVXbHF0dXdrTG5kakJGZTArSmZBOXZxVWJTUnI1YzRCMnVQNjE1THJHa1hlalhq Vzl5aEg5MWgwWWV0WEd3aHZtTDYwMHVwNzFRTDRwb2xPZXRYemlzeSt4NHFKdUJUSXBDV3gycXdp aGlhZTRiRmNveDdVd3hNZTFhQVhIYWdxTVVjb1hNaVcwZHpsUnpVZjJLYjBGYkJ3S1l4NHFlUWR6 Sit4eWpyaW5SMmJ1L3pIQTlhdm5wVUxDcDVFRnl4RVZoakNiczQ3MC96Vjlhb3RrVkdXeFZjMWhH Z1dVbnJVYmRhcGlRK3RXa2JjdENsY0xFYkFsdUthWTI5RFYyT01iZWxTYkFCMnA4dHdNdG9XUGFv amFTZGhXdVZGTU9CUzVFTXlqYXlqc0tRMjhnOUswV3FKK2Fqa0FodHJjcklIYzRBcThaVjlhcE5r ZERVVEhIZW1uWUdqUU1pK3ROSkJIRlo0YzFLc2gzWW81cmhZbFBTbzlyTjBCcWRWM01CVmhZd0tk cmdaeGpiMHBoZ2M5cTFTZ0ZNWUNqa0M1bUMza1Bha01EaXRBbkZSTjNOVHkyQzVURUxrOXMxY3R5 a01lTThtb1dIT2FZZWxMWWU1ZE1pVTB5S2FvRmo2MEJxSE1MRnh4M3FKK29wSTJMQ3A0b3cyZmFu dUd4V0tNZTFOOHB2U3RJUmowcENvQTZVK1FETU1iOWdhVVJQak9LdkhGUnNlTUNwNVF1VlBMYWdJ VFU1NXFJclUyQkZtTmtqWEEvR2xNaTFUUEFwdFZ6QVc5NE5NYnJ4VUFKRlBVNUdhTGdJMU4yTWUx VzBqeU4xVEJCanBSeTNDNVhXckVkVjE2MVlpcWtJbUZKSXZ5bjZVOVJUSnZ1MWZRUm5QOEFjTlEx TS8zS2hyQmxvVHZVaTFIM3FSYVFFZ0ZQQXBCVHFzUXExTWxRanJVeVUwSXNKeUtrMjFISDBGU2l0 VUlxWFBBWEZVWitncTljODdmclZHZm9LeW1ORU5QVHBUS2VuYXN4azZpcFFLaVNwUldpMkVGUFhy VE85UFdtaEV5VllXcThkV0VyUkFPSXFwUHhKK0ZYRDA5S3B6LzZ6OEtjdGdLRngvckQ5S2lIV3Bi bi9XTjlLaVVjMXpzb2xUclU2MUFuV3JDMVNFU0NuQ21pblZZaVJhbVNvRnFkT2xVZ3NTaWtZY1Vv cEdJeFZpS1V2Q3RpczlqMnJRazZOV2MvM3F3bnVVaDYxT2dxQktzSlNReVpSVWdwaTAvdldpSkhE clQxTlJqclVncWdKbHAvYW1MMHAxV2hNaW1IRmRQNFo4RXlhc1V1TDBNa0haT2hiMFAwcWZ3djRW L3RLUmJxNlUrVG41VTZaNmZwWHJWbFp4V3NBQUFWVkgwQXJDY3VpS1JGWWFWRFp3aEVSVUE3QVlw dDNmcXJlVmJqYy9UTk12TDU3cGpEYm5FWSs4M1RQLzFxek5VMVhUL0R0bDU5MjVETndrWS8xa2g5 QU8xWkRMWGtxb2FhNmNZWGxpeHdGK3AvcFdBL2lXNjFXOE9uK0U3QnIrNFhocmxoaUdMOGFzYVY0 UjF2eHl5WG5pQnBOTzBmckZZUm5hOGc3YnZTdlZOSzBpeDBhelMwc0xhT0NGUndxTGlrTTREU2Zo V2J5Wkw3eGJmeWFqY1ozZloxTzJGUHc3MTZKWTZkYWFkYnJCWjIwVUVhakFXTmRvcTFpbG9BQU8x RkxSUUFVdEdLTVVBRkxTVXRBQlNqcFNVb29BUTB0RkZBQlMwbEZBQzk2S1NselFBVVVVVUFGTFNV VUFMUlNVdEFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJTVXRKUUFkcUQwb29vQUtL S0tBQ2lpaWdCTzFGRkZBQlJSU1VBTFNVVVk5NkFDa29vb0FLS0tLQUROSlJTYzBBTFNVdWFTZ0Fv b3BLQUEwWW9vb0FEU2Q2S0tBRHZSUlNVQUZGRkpRQVVVVVVBSEh2U1V0SlFBVVVVbEFCUWFLU2dC YVNpaWdBb29wS0FGcEtLS0FFeFJqdFMwVUFadXJhSHB1dVd4dDlTczRibU0vMzE1SDBQYXVFdS9B ZXMrSFhOejRTMUJwWUJ5ZFB1MnlDUFJXcjB6dFNZb0E4cjA3eEphWHR3ZE0xUzJiVGRSSERXMXdN SzN1cC9xSzBHczdpeWw4MnhaczlUR2VUajIvdkN1czhRZUdkTDhTV25rYWpiSzVIS1NyOHNrWjlW YXVBdW90WjhDTUk5Uzh6Vk5CM2ZMZHFQM2x2NmJzZnpvQTZqVGRUZzFBZVZLQkhQOEEzVDBiNlZX MTd3eGE2dGF2SE5DR3lNQTQ1WDZWVWVHMjFLM1M4dEowWVA4QU1rNkhodlp2USsvOHEwdEoxbGpK OWgxRDVKUWRxdTNHZlkwd1BBL0ZuaGU1OE8zbUNOMXRJV01iRHFBRDBQdnlLNXZwWDFOcmVpVytv MmtrTXNhdWpqQkI3MTg3ZUxmRFZ4NGUxTjBLTjlsWmo1VDljai9HbmNSa1crZk1yUWhISnJQdHZ2 Q3RDSGl0b0NaUDJwcmRLY2VtYWEzU3RDU0Zxak5TTlVaNjFEM0hZYmppbzJGU2RxWTNTa0JBOVYz TldINlZXYnJXYkdob2FyMEgrcnFnT3RYNHZ1VVFHeS9HUGtwNTZVeUw3bFBQU3Qxc1NRdjNxRmpV ejFDd3FXQXcwd2luVWhxQUltR0tydU9hc1BVRDFMR2lFbW5JVHVGTk5QaSs5K05RaWpSaCsrTTFj eHhWS0w3NHE4T0JXOFNHUnRVRDlhc01PS3JQVFlFVFV6dFRtRk43Vm13R2tjVkU0cVZxaWVwWTBR bnJTVXJkYVNvS0pvRDFxOWFqSWI2MVFnNm1yOXIwT0sxZ1N5d1JnVkMvQXF3MVFTVm94RlppYWpO U04xcU0xa01URk5JcDNhbXQxcERJVzYwbE9hbTFBd3FST2xSMUluM2FhQXZXNmdvUGVwY2UxUld4 K1VmV3BqMXJlSkpSVVZZakdLaFhpcFZQTlFnSmk0UkM1N1ZRKzJTRnp2d1JWbVRFa1pUTlVYaVpm cFNrMzBDd0Z3VnhUS1hZYUNDS3pHTjcxSXRNeHpTanJRQk1HcDROUWc4MUtPbFdEMkhxT2FtUVV4 QnhVcTlhcENKazRGUlhzN3dvcGpPQ2V0UERZcXRjdythUzRZL1NxYjBGWWdhN0xxQXd5dzV6VVR5 YjhjWW84bHdlUlNlVS9wV1R1V05GUFNqWVJTZ0VHa0s1S3RTZzFDQ2FlcCthcVFpVHZUd0NLWUtt VmZXclFoOFl4VTY5S2hYaXBWZkZXZ0tlb1R1a3FxcmNEbjhhaGE5OHpCS25PS1c1dFdMRjFiY1Qy OUtyL1o1UFNzbTNjb2JMSjVqbHVsQzlhWDdPNFBJcHdRaXBzdzBISjFxZFRVSzVGU0RpclNFVEEw OFZFcDVxWlJtcUVPVVZPbFJxS2tCeFZnU0Z0aWxqMEhOWXYyK1FTdXluNVdPU0RXcktGbGpLTjBO WlV0aTZFQkRtb25mb01XUzkzZzRRalByVmRXTE55YWY5bGw5S1ZMWmdjdHhpc3ZlWTlCeUNwMHBn VEZPWE5Xa0JPcHFVVlhGVEwwcXlTUUNucUthbzRxUVZRRDE2VnRlSDlIZlZMd0Z1SVZPV1ByN1Zr MnR1OTFjcERIeVdOZXE2RHA4ZGxiSWlMZ0FmblNuS3kwQkkzOU10WTdhQlVBQUNqRkYzZE5jdjVF SnhHUHZHb3BwaUZFYVp5ZlNxbXFhbmJlSGRIZTl1QnVicEhHT3NrbllDdWNvaTEzWElQRDFyR2lS dGNYMHgyMjlzdjNuYjFQOEFuaXRMd2Q0Qm0rMkw0ZzhVTUxyVkg1amhibExjZWdIclI0QThIM0gy aHZFL2lCUE0xVzUrYUtOdWx1bllEM3IwZ0NrTUZYQTRHS2NLU2xvQUJTMGxMUUF0Rko3MHRBQzBV bExRQVVVVVVBTFJTVXZlZ0FvRkZGQUMwVVVVQUZMU1VVQUxSUlJRQVVWeW5pLzRoYUg0TlZZNzJS cHJ4bDNMYXc4dmoxUG9QclhtRjc4ZnRTZHo5aDBhMmpUdDUwaFkvcFFCNzFSWHp1Zmp2NGxQU3ow NGY4QmIvR2ovQUlYcjRtLzU5TlAvQU8rRy93QWFBUG9taytsZk8vOEF3dlh4Ti96NmFkLzN5MytO S1BqcjRsQjVzOVAvQU8rRy93QWFBUG9mTkxYZ0Z0OGU5YVJ4OW8wcXlsWHZzWmxQOWE3cndyOFlk QjhRM1VkbGRvK20zY2hDcUpUbU5qNkJ2OGFBUFJhS1Nsb0FLS085SXpLcWxtT0FPU1RRQXRGYzlx SGpIU3JBOHloc2Z4RmdvL00xaXkvRkRSb3pqN1RhajZ6VUFkM1NWNS8vQU1MVzBiUC9BQjkyZi9m eWovaGEyamY4L2xwLzM4b0E5QW9yei84QTRXdG8zL1AzYWY4QWZ5ay80V3RvMy9QM2FmOEFmeWdE MEh0UlhuMy9BQXRYUnY4QW44dFArL2xIL0MxZEcvNSs3VC92NVFCNkRtaXZQdjhBaGF1amY4L2Rw LzM4by80V3JvMy9BRCtXbi9meWdEMENpdlAvQVBoYXVqZjgvbHAvMzhvLzRXcm8zL1A1YWY4QWZ5 Z0QwQ2l2UHY4QWhhdWkvd0RQM2FmOS9LUCtGcTZOL3dBL2xwLzM4b0E5QW9yei93RDRXcm92L1A1 YWY5L0tQK0ZxYU4vejkybi9BSDhvQTlBcEs0RC9BSVdwb3Y4QXorV24vZnlqL2hhbWkvOEFQNWFm OS9LQU8vb3JnUDhBaGFtaS93RFA1YWY5L0tUL0FJV3BvdjhBeitXbi9meWdEdjZLNEgvaGFlaS84 L2xwL3dCL0tGK0tlaW4vQUpmTFAvdjdRQjMxQjYxeGx2OEFFZlI1bUFGemFuNlRDdWhzTmNzOVFD K1UrTjNUbklQNDBBYVJwS0tLQUVvb29vQUtLS1NnQW94bWl2TGZpajQ5bTB5UnRCMGVYeTdvcURj enIxakIvaFgzeFFCMnVzZU12RCtoT1k3L0FGS0pKdjhBbmtoM1ArUXJIZytLbmhLYVRZYjZTTC9h a2haUi9Ldm43WVhabmRtWjJPU3hPU2Z4cHdpRkFIMVZaWDlucVZ1dHhaWE1keEMzUjQyM0NySFN2 bURRZGYxSHd2cUMzbW5URlFQOVpFVDhraStoSDlhK2pQRCt1VzNpTFJiZlU3VGhKUmhrUFZHSDNs UDBvQTA2TTBVYzBBSlJSU1VBRkZGRkFDVVVVVUFGRkZGQUJTVVVkNkFDaWlpZ0E3MFVVVUFGSlMw bEFCaW81WWtsaWFPUlF5TU1GV0dRUlVsRkFIbVdzK0c3dndiY3k2djRmaWVmU1hPNjcwNGM3QjNl TWYwcWNOWjYxcHNONVp5cThMZ2VWSm43bit5M3QvS3ZSQ3ZyelhtM2lEU204RmFtK3QyRVJiUTdw c2FoYWdaRUxIL2xvbzlQVVVBYk9pYXEwaC9zKzl5SmwrVlMzVSt4OTZxZUt2RDF0ck9ueVcwNkhZ M1BIVWZTb0wyM1dXT080dG4zL0x2aWtVNTNwMTYrby9VZlN0ZlRyNGFqWmZPUjV5Zks0L3JURWZN K3AyTjFvR3B5V3R6RzN5azdTUmpjTTR5S3FOcU1nLzFYeS9XdlpmaVA0Vy90V3c4NjJpVTNVUnlH N2xlNHJ4WDdGTUdJSzRxazMwQTJMTzQ4K0hKT1hIM3NWTTNTcXRsYmkyVnN2bmRWZ210NDdFa2JD bzJGU2tpbU1PS0FJKzFSc2FlZWxRc2Ntb2JBWTlWbUhOV1dCeFVSVElxR2hvckZzZEtzUjNZUmNG U2FZYmRpUGw1cEJheS8zYW16UTdvc1EzOG5uTHZiRWVlbGEyNEZjamtWaXhXVE1mbitYMHJVakN4 UmhGcldEZlVURmZyVUxDcGlSaW1IQnFtSWdJeFRXTlN2MHFCK0tsZ01ZMUE5U3RVWkh0V2JLUkVh Ulcybm1wQ2hwdmtPVzRGVHFNbCsxa2ZjNGIxcTFwOXdYTEl4K1kvTm1xUGtTZWxYTGExVkdEbHVh dU43a3N2c2FydUtrTENtTldyRVFNS2IycVZoVVRjWnJON2dNSnFKelRtUHBURzVxV05FUnBLY1Zw TnA2VkZpaDBiN0RUMm5iRzFUZ1p6K05NOHA2RmliSXFsZENOYUdUZkFyazVKRk5rcUszWHlWSzdz NXA1SXJWYkNJV0ZSRVlxYzFHdzQ3VkxBanBqVS90VVJOUXhqR3BLVTBuNTFJQlNoOERGSjNwZGpk YUFKVXVIWGFGNEZhSVlFWnpXV3NaSndjVmNRN0VDazlLMFFGUHpHcFBNYjFwdEZaNmpIaDI5YVhK UEZOVVU4RG1xUWlSZlNwTnF0MnFJVklwcWhEaENwN1U4VzYrbExIelU2aXFVUUtyUWVncU1ydDRO WDJXcVVvdzVva3JBUXRNZWc0eFRQT2JQV21OOTQwbFpYWXlZU3VlOU8zdVQxcUphbFVVd0hJU08x U3BqbW1BWXB5aXFRaVVSb2UxS0lFN0xTTFU2VmFRaVA3T3VPbFJ0RnRKSTdWZEF5TVZIS3VJMits UGxBcDlzMHhwdU9EVCsxVW1ibXM1YUZFNG5iMXA2eXQ2MVdYbXBWcVV3SmQ3bnZUMDZVeFJVaTFv aEVxZ011RFRoR2g3Vkd2MXFWVFZDRkVDSG9LWHlGQTZWS2xQSXFrZ0taaTI4MHhuQ0FHclVvd2xV TGh0cUNvbG9BR2RoM3BQUGYxcXRuTlNLT2FoTVpZRXJudlRzc1NDVFVhQ3BsRlVBOWUxU2JWYnFL anA2bXJFT0VTZWxPRUs5aFRsTlNMMXAydUJBMEE5S1p0Mm5GV3l2RlY1Umh4UllSQzgyTWdWRjlv YjFxR1Z2M2pmV3BMSzNhOHZZWUZ6ODdBRWpzTzVyTnlLTzU4R1dCS2ZiSk9USnd2c0s5QmhZSW9H YXhOS2dXM3QwUlZ3b0dBSzJZZ1h4N25Bck42akx0ckdHWXlTSGFvR1N4L2hIYy8wcks4SzZjZkhY aTE5Y3VVem91bXY1ZGxHUjhza2c2dlVQaTI0dVBzVm5vR25FaS8xYVFSREhWSS93Q0kvbC9NMTZu NGYwZTMwSFJiWFRiVk5zVUNCZnFlNXFSbWtxNEZQSEZKaWxvQVdpaWpOQUJTMGxMUUF2YWlrb29B V2xwS1dnQW9vb29BTzFMU1V0QUJTOXFTak5BQzk2S0tQeG9BS0tLS0FDcTJvWGlhZHBsM2ZPTXJi d3ZNUjY3VkovcFZxcTk5YVIzK24zTm5MeEhjUlBFeDltWEg5YUFQamJVdFN1ZFoxSzQxSzlrTWx4 Y09aSFluMTdmUWRLcTRxOXJPajNuaC9WN25TNytNcFBidVVPZjRoMllleHFqUUFvcFFhYjdVdjBv QWZSVFFjVXVhQUZwTVVab0FabUNxQ1dQQUE3MEFmVW53bzEyZnhCNEN0SnJweTl6YnUxckk1NnR0 eHRKL0FpdTByai9oZjRlbThOZUJiUzB1MDJYY3pOY3pJZjRTM1JUOUFGcnNLQUR0WEcvRWpXWk5I OE91OFpBSkdmbU9BU1NGVUUrbTRqUDBycysxY2o4UmZEemVJdkM5emF4L2ZaTURQVE9ReTU5c2dV QWVjV0dpWEkxUy9NeDB5NzArNXN5dGhyZDI2dXIzSlVZMkFuYUJ1M0RiampGU2YyVmZwcCtuNlV1 dGFGSHEra3lOY2F4bUdQSWd5Q3VmbDUyanI5UldVZ3N0VmluOEwzSGgrV3pzdEVnYThzWXBMblpK TlB3V1FrL2VESFBUc0swbjFJbXpzOWEvNFJPMmZWTmVkN1hWRTg4L0xEa0RPUDRkdzV6L0FMTkFG NXBjWHVyNm5IcnVpSnBXcnh0Qm9ZTUtZV2JnRCtIakhJT2ZVVkUxcnFhMnVtYWYvYjJqTHFPak8w K3VaaVRQbGJnUm41ZWNMd2ZjaW81SWRPKzE2bG80OE1XOG1tNkFqM09rdWJqL0FGOHBJT0NmNHQz WEgremlvMnZ3MXZZNnFmQ3RzMm9lSW1lRFdCNS8zSTl3R2Nmdzd2dmY4Qm9BdU5KSjlwMWUrWFh0 Rld4MXBXaTBITVNmTEprRCs3eGo3cDl6VVpnMUJZZEx0UDdlMFlYZWlNMHV2WmlUN200WXo4dk9G K1g2bW9uU3c4L1U5T0hoaTJheThPcTAyak45by8xOGhZSHJuNXQzM3Y4QWdPS2phOGphT3d2ajRX dHpkZUpHYUxXUjUvOEFxMDNEbi9aejkvOEFDZ0MwenorWnE5d3V2YU1MZldzcG9IN3BQbGJkL3U4 WUh5L1dtZVhlcU5LaE92YVA1bWhrdHIzN3BPUnU3L0x6eDh2MXFGdnNZZlVyVWVHTGN3ZUc5ejZN ZnRIK3ViZm4vZ1dmdi9oaW1HZUZocDh4OE1XL21lSlNWMW45L3dENm9iLy9BQjMrL1FCWVkzWkdx dU5lMGNEV3pqUWYzU2NmTi91OGNmTDlhTVhZazBvSFhkSDI2SVArSjkrNlRuNXUvd0F2UEh5Lzcx Vmk5c1A3UVVlRjROdmhzNTBZZWY4QTY3NTg1LzJ2NzlHKzNMNmVENFl0OGVKT2RaYnovd0RWZk5u L0FJRC9BSDZBSmNYNWgxUlJyMmtHWFdtQjBMOTBuM2QzYjVlT1BsK3RQRFhBdWRMa2JYZElOdG95 N2RkQWpUbHQzUDhBRHprZkw5UlZUem9SSGZ5and2YjcvRGpCZEdYenY5WU4vWC9heDkrbEgyWnB0 UHRqNGFnV0h4RUZmV0g4L3dEMUxicy84Qng5NzhhQUpSSHFaZzFLMS90dlNXdmRaWVNhSUJFbity M2M0K1hqSzhEM0ZQV2FVWE9sM2phM3BMYWZwQ0xGcmVJaythWEpCN2M1NkQzQnFxTHNLbDlmand6 QXQzNGVaWWRJWHp2dnB1Ni83VzBmTitOS2tObjV1bmFaL3dBSTVBbGxyeXJQcXppZi9VeUJpY1ov aDIvZS9HZ0I0aDFVMnVvV1A5dDZVMnBhczZ6YVBpTk1tTGNjNCtYakk0SDBOVExjTjl0MHpVRzF2 U1cwclM0MWcxakVTWWFia0h0MzR4OURWSmIwckJlYXF2aGlCTC9RV1czMHBCTjk2UGNSbkg4VzBj NTk2ZWx0WS9hZFAwZi9BSVIyQk5PMXRGdWRUa0UvK3BsNU9NL3c3ZlQvQUdxQUZGdnE1c0w3VFRy ZWxQckdweUxQcGVJMHlZY2tuSHk4YmgwK2hxd2x5UnFHbmFvK3RhUytqYWRFdHZxbUlsdzAvUTl1 NXhqNlZSVy9kYlc2MW9lR0lFMVBSWFcxMDVCTDk2TEpHY2Z4YlIzL0FOcXBZN093KzJXR2hmOEFD T3d4NlhxMGEzZW9TZmFQOVROZ25HZTIzMC8ycUFCYlhWenB0M3BKMXZTbTF1L2xXNDAvRWFaTnZ5 VGo1ZU1qa2ZRMVlTN1Vhblk2dSt0YVMyaFdNSzIrb1lpWEQzR0RuQXgzT0NQcFZCTlFsV3l1ZGUv NFJtQk5XMHAxdExDTVM4R0hrWjI5OW8vOUNxZExEVC90MWw0ZVBoNkdQUjlSaVc4dlpQdEgrcW13 ZmwzZHRwNC80RlFBMWJQV0RwVnpveDF2U20xNjdsVzV0Q3NhWit6OVQvRHhucVBZVlpGMUNkVnRO WmZXTklidy9iUWkydXdJa3cxeHRPY0RIYzRQMEZVRTFHWWFkTjRpL3dDRVloVFdkUGtXeXRZZk4v NVlZSXp0NzdSOHVmZXJDNmZwMzlvV25odi9BSVI2Rk5GdklsdmJtWDdSL3E1OXArWGQ3SDVjZTlB Rlk2UHFNbWtUNkcrcDZNL2lDNG5GekJpR1BKdDhaUDhBRDM2L1FVczl6cUhoalhSck9tclpwb1Zy QW4yaDRaUDNWMUpnYjFDNXdHenV4ajJwcDFDWnRLbjhSTjRYaFhXYmVUN0JEQ0pmK1dHM2J1eDdE NWMrOVFRNkVMOXYrRUowZlRETHBrd2p1cmk5YWJmOW1tSUc3SkhIeWpLN2UvNDBBZlFjVEs4U09q YmtaUXluMUJHUlQ2amhSWW9FalFFSWlxaUE5bEF3S2ZRQVVVVVVBSlJSUlFBak1JMFp6MFVialh5 bGYzY21wYXBkWDh6RnBMaVpwQ1Q3bXZxeGtEcXlIN3JEYWErVkwreWswM1ZMcXhtWGJKYnl0R1Fm WTBBUUJIbExCQVNGRzQ0cS9Ob3M4R25tK1YxWkZkVWNBOHFTTWlvYkc2VzBsbDNwdlNSQ2h4V2tk WGhIaHlleUc1cDdpUldZSCtGUWMvNFVBWS8zMDNWNmw4RXI5eExxMm1zMll0cVhDRDBQM1cvcFhs d0cyUEJyMUg0SjZlL242dHFUREVlMUxkVDZuTzQvMG9BOWNveFJSUUFVbExTVUFGSlMwaG9BTzFG RkZBQlJSU1VBRkhGRkZBQlNkNldpZ0FwS0tLQUR0UlJSUUFVVWZqUlFBbFJ6UXh6d3ZETWl2SElw VmtJeUdCcVNqRkFIbVZoYVNlRzljbDhMVHV3dEpRYmpTcHp6dEE2eC9WZjVWTUpHMDdVRm5WZGti a3E2RCtFL3hEK285aUs2UHh0b2NtdGFHWHN6czFLeWNYTm5KM0VpODQraEhGYzhsekZyMmkyMnBR cnRGMGdESi96em1YamIrZTVmKythYUJtbmZJdHhDY2NnaXZFUEdXa25UZFdhV05jUlRIY01Eb2U0 cjJIVExqemJYeVhQelI4ZmhYTitOTktXKzAyUUFmT28zS2ZjVlVYWmlQSHQ3anZURE93NzA5eGpq SE5RUFdqWWgzMmhoM3A2ejg4MVRQQnB5TjgxVGNDOE9jQ3BGZ0dPUlRZeGxoVnNMV2lWeVNBd3Bq cFRURWdIU3JCcUpxZGhrZXhWNkNtTjFwN1ZIVXNDSnlRM0hhbUdSeDNOU3N0UXVLa1lobmNIclFK Mko2MUN4cVBPRFVYR1hoSUgrdFNDUGVhcTI1eStLdndMMXE0NmlFRUM0NlVoZ1RIU3JPTUNtTjBx N0FWekVvcENBbzRGUFkxR1R4VXRBUnQwcU1NeWpnMUllbFJ0VWdOTXpqdlRmUGJ1YWE0cUpxaTQw V0ZuUGVwUWR3cWtEanJWdVBsQlZKM0N4TWtIY2pyVC9BTE92cFV5TDhncHhIR0t0SkVsVXdwNlUw eHFPMVRQd0tnWTByREd1YWlZOGludFRXR2FsZ01Mc09jMHd5dDZtbFlWRWFsc1pKNXpldE9FdTdp b2FkR1BuRkpNWlA3VklzSFBJcG1QbUZYVlhnVm9rU1Z6YnI2VTB3cU8xVzJGVjNwdEFSRkZIYW1O MXA3VkdSa1ZBeU5zZzlhVGUzclQyRlJrVkxBU2s3MHRIZWtNZXRTZDZqV3BCVklURnhUbHB2ZW5n WU5VSW5pNmlyS21xMGRXVnJSQ0hOOTJxRXYzelY1eUZUTEhBck9rZEN4dzJhVTJORlZ2dkdrcFd4 bWtyQjdqSG9LbVhyVVNWS3RVZ0gwcTBnTkt0VUlsWHJWbU9xeTlhc3gxYUVUTDBxS2YvQUZiL0FF cVFkS2h1WkkxVmxMZ0VqdlZ5WVdLbUtvc09hdWVZbjk2cWJIa2lzSkZJVmVLblNvRnFkS1NCa3kw L3ZURnA0NjFvaVJ3NjFJbldvd09ha1RyVEFzSjBxVVZFblNwT2dyUkFSVGZjclB1QmxCOWF1enp3 Z0ZUSU4zcFZDZVJDbzJzRDlLaWJRMFZSMXFWT3RSRHIzcVZCeldLR1dVcVVDb1VxWUd0VVNPNzA0 ZGFhQlRnT2FwQVNwVXk5YWhVVk10V2dIOXFxeS9mcXc3cEd1NTIycjYxU2x1SVMvRXFrVVNhRWls TVBtUDFyb3ZCdGw1dDNKY25vdnlMa2QrLytmZXVjbFpXWWhUbXZRdkNWbjluMHlISXd6L08zNDlQ MHhYT3l6cW9Gd3FyVzFZd2lTVlFmdWpyOU8vOEFuM3JKdGx6S1BibXJPc2FoL1l2aFBVTlFCL2Vl WDVjWHV6Zi9BSzEvS29BbThCVy8vQ1JlTjlXOFNTamRiMmgreFduNGZlWVY2c0JpdVgrSDJpZjJC NE0wK3paUUpUSDVzcDlYYmsvenJxaFNHRkxSUlFBVXRGSGFnQXBhU2xvQUtVVWxMUUFVVVVVQUZM UlJRQVVkcUtLQUY3VVVVVUFMUlFhQlFBVVVVVUFGSFhwUlJRQnozaW53VG9maStCVjFTMS9mSU1K Y1JIYkl2NDl4OWE4MHZmMmZnWEpzTmR3bllUdzgvbUs5dG96UUI0SWYyZjhBVmUydDJmOEEzdzFI L0NnTlYvNkRWbC8zdzFlOTU0b3pRQjRKL3dBS0ExWC9BS0RWbi8zdzMrRkgvQ2dOVi82RFZuLzN3 MytGZTk1b3pRQjRiYmZzL1hCWWZhZGVqQzkvS2hKUDYxM1hoWDRWZUhmQzl3bDJzYjN0Nm5LelhI SVUrcXIwcnVLS0FDaWlpZ0FveHhpaWlnRFB2ZEMwelVVMlhsamJ6cjJFa1lZRDg2eEpmaHY0Um1Z bDlCczhuMFFyL0kxMWRGQUhHSDRWZUREL0FNd0szLzc3Zi9Hai9oVlBnei9vQlcvL0FIMi8rTmRu UlFCeG4vQ3FmQmYvQUVBYmYvdnAvd0RHai9oVlhndi9BS0FOdi8zMi93RGpYWjBsQUhHZjhLcThG LzhBUUN0LysrMy9BTWFYL2hWWGd2OEE2QU52L3dCOXYvalhaVWZoUUJ4di9DcXZCZjhBMEFiZi92 dC84YVArRlZlQy93RG9BMi8vQUgyLytOZGxSUUJ4bi9DcXZCZi9BRUFiZi92dC93REdqL2hWWGd2 L0FLQU52LzMyL3dEalhaMFVBY1ovd3Fyd1gvMEFiZjhBNzdmL0FCby80Vlg0TC82QU52OEE5OXYv QUkxMlZGQUhHLzhBQ3EvQmYvUUJ0LzhBdnQvOGFQOEFoVmZndnAvWU52OEE5OXYvQUkxMk5IMW9B NDcvQUlWWDRNLzZBTnYvQU45di9qU2Y4S3M4RjlQN0J0LysrMy94cnNxS0FPTi80Vlo0TC82QU52 OEE5OXYvQUkwZjhLczhGLzhBUUJ0LysrMy9BTWE3S2tvQTQ3L2hWbmd2L29BMi93RDMyLzhBalNy OEx2QmlIalFiYjhXZi9HdXdvb0E1cTM4QWVGTFpnMFdnV0lZZHpIdS9tYTNiZXp0clNFUTI4RVVN UzlFalFLby9BVlAyb29BS1NqTkZBQlNVdEpRQVVVVVVBSlhsL3dBVC9BYzJwU05yMmt4YjdrSmk1 Z1hySUIwWWUrSzlScEJ3Y2lnRDVNVTU0WWRLZXVCMEZmUit0ZUIvRHV2U3ROZTZhZ3VHNnpRTVkz UDFJNi9qV1BCOEpmQ3NVbTk0YnVZZjNKTGc0L1RGQUhqV2g2RmYrSmRTV3gwNk1zMy9BQzBrUDNZ eDZzYStpZkQyaDIzaHpSYmZUTFhsSWhsblBWMlBWalZyVDlOc2RKdFJiYWZhUTIwSS9naVhINSt0 V3FBRW9vN1VVQUZKUlJRQVVsTDlLU2dBb29vb0FLU2lpZ0Fvb29vQVNpaWlnQlJTVWQ2VTBBSlIz b29vQU1VbEwzb05BQ1VVQ2lnQk9sZWR4V1EwbnhkcTJoZmN0dFFqL3RHengvQStRSkFQeDJ0WG90 Y1o4UVkvc1VHbWVJbzErYlM3dFdseDNnZjVISDY1L0NoQVk0YnlOUldURzBTakxEKzZjNFlmZ3dO VGFoR0pJVzRwK3RXL2xUeTdlUUc4eFNQUnV2NnJuL2dWTkQrZGJxZWVSVklSNGw0aXNoWmF4UEdC aEdPNWZ4ckVrNlYzbmo2eTJ0RmRBZERzYXVEazZWZlFSWGFuUkQ1aFRXNHBVWUt3eWFrTEdsSDk0 VmNYcFdmSFBFR1hMZ1ZlamRXWEtuSTlhM2d5UldxQjZuTlFQM3BzWkVhYlRpS2JVQU5hb1hOVE5V TDFMR1ZucUk5YWxmMHFNaXNudU5GaTJIelZvMi9lczIzZFZiazRxL2J6UmJzYnh1UFFWckFSY0k0 cUY2bUpxSjYxRVZuNjFHYWxjYzFFZXRac0J2YW1HbjlxWXhxV01oZW9HNjFPOVFzT2F6WTBJS3VS ZmNVVlRxMUc2aFI4MU9JR25IMHBXcHNMbzY1VmdmV25OWFF0aVNCeFZkcXNTY1ZYWVZtd0l6UWVs S1JpbW5wVURSRzNXb21xVnFpYXBZeEJUby92aW0wNURoaFNHV1A0aFY5T2xad2RkdzVyUmpLbE1n NUhyV3NHU3hHRlZucXkzU3E3MVRBZ2Jpa3B6RE5Ock1ZMXFqcVJ1dFJuclNzQTJpcHZJelMvWnFW Z0lWUE5TQTgxSjltT0tZWW1XblpnT0hXcFZITlJLY2NtbkdZRHBURVdGNHFaVFZBWE9LZDlwSnEx SUxGaTRVU3BqSkI3VlJNQkJQemZsVXJURmpRT1JVeTFBcmJDRFNZNXE0WXd5MG4yYk5UeWpLNjFJ cHFYN0tRYVg3T1JUNVdBMVRVaWM5S2pWR1hyVWlrS1BlcXNJbFVZcVpEaXFYMmdDbkM3eHhUdUZp K0NCV2ZQYUZwQ3l2OEE5OWMwL3dDMDB6ekN6VTI3b0NEN01ldTZtR1BGV3hUakNDT0tqbHVOTW9n SE5TcnhWZ1d1ZWxPK3lFR2psQWhWcWxYbWxOc1J6U0tDdldxc0lsUVpxUlJ6VUlrQ0xTZmFSVHVJ dXFhZVdBcWdMcnRqOWFYN1Q3VlhNZ3NRejJSTWpQdkF5YzRxQnJVcHprSDZWYjh3c2ZiNjA4RGR3 ZWxSeWp1VUNtUC9BSzlPUVZjK3pBMGZaYzB1UUxrSzFJdFMvWnFhWWlwNlZWbUE1ZWxTcUtpWGpG S1psV25jUllIQnFRZldxUXVSVHZ0VlVwQllsdTR2dEVCaUJ3VFdhZE9jSEhtS2F1bWZJb1Zpd3FX a3hsUzJzV2U1U0hJTE93VUg2MTZ0cDBRU0ViVkNxQndCMnJoZEh0aE5xVVpLNUNaYitnL1VpdlFy Wk5zUTRyT1NzeG1sYUw4cFk5elVQaUtBNm5ySGhqdzh2UzR1ZnRNNC93QmxmbS9tYXQya1cveTRo L0dRdjVuRlRlSEkvd0MxZmk5ZjNPTXhhYlpMRXZvR2JrMURHZXFScUZVQWNBY1ZKVFZwYVFEdTFG SlFLQUZwYVNsb0FLV2tvOXFBRm9vb29BS1dpaWdCZTlGSlNpZ0Fvb29vQVdpa3BhQUNsNlVsRkFD MFVsTFFBVVVVVUFGTFNVVUFMUlJSUUFDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29wS0FGelJSU1VB RkZGRkFCUlIrTkhTZ0JEUzBVWm9BS1NpaWdBb29wS0FDaWxwS0FDaWlnMEFKUlJSUUFsRkxTVUFG RkhOSlFBVUhwUlJRQVVsRkZBQlJSU1VBRkZGRkFDVVVVVUFGSlNta29BS0tLS0FDa3BhU2dBcEtL S0FDZzBVbEFCUlJSUUFDaWlpZ0JLS0tLQUNpaWp2UUFVVWxGQUFLTVVVVUFBb3hSUlFBVlIxalQ0 OVYwVzkwK1FaUzRnZU1qNmppcjFJZURRQjVycGN6Nmw0UjBxYVU1dUZqYXluOWZNVDVlZitCUnIr ZEpadm1GbDlLbHM0alozbml2VEZIL0h0ZXJmUWowVjFELzhBb1NHb0ZBaXU1a1g3dVR0L1BpbWhI T2VNclg3UnBGeU1aSVRjUHc1cnlSL1N2Y3RWakR3TU1BNUZlT1hGajVWeEpGbjdqRmZ5TlhIVURM MmswaGdMc01ZcS93RFpjY1U0UWhhcmtGY29qVDJKeHZGYWNFYVF4aEZQQXFFbmIvOEFycHF6a2Rl YXBhQ0xoUEZSdFVIMm5GSWJvVStaQVNFY1ZHYUJPckdqT1RTdUJHNXhVVEhJcWZ5aTdlMUgyVW1s WmpLTERJcG9UMnEvOWt4U2ZacWpsQzVTVzNMOXdLbnQ3UXJLcmx4OHZhcHpHRTZVaGNyME5Vb2dY ZDFOWTFVKzA0cFB0UXErWVJPd3FOaHhUUHRRTktKVmFwYkhZWWVsUk5VekxrY1VpMjViclUyQXF0 VVJCcS85a1B2U2ZaTVV1UVpTQ1ZJTGRpTTVBcXlJQU92YWdqRkxsQWx0WXZKakl6bmNjOFZZTFpG VUJLVmIycDMybXRFN0NzV0g1cUlpb3Z0V2VNVWh1QlV0aFlWaGcxRzNIZXBHWU5qRk1LbHNjVWdS RWFqWVZiK3pFMGh0VFUyR1ZNVTRLU2NWUDltNXAzbGhhTEFRZVQ3aXIxdW9pVEFPVCtsVnMwTE1W TlVuWVJlWmhVTFlxdWJtajdUNjArWUxEMkZSbmlqenN0U0U3alUzR01ZMUdUVXV3czFPTnVhVm1C S3BxWkJtcTY5YXNSMWFFUzdCVWJwaFRVeWlrbDRVL1NydG9JelhIeTVxR3BuKzRhaHJCbElNODA1 YVozcVJhQmp3T2FrRk5BcHdGVWhNa1UxTWhxdUttU3FRaWRSVGltYUU1RlNnY1ZvaEZLY1lBN1ZV bU9BS3VYV01MVktmb0t5a01oM2MwNGMwekhOUFdvS0pWRlNLS2F0U2dWYUpZVktwelVYZW5xYXBD TENtcFZHYWdTckNWYUFDb1BhcTA0eEorRlhPMVZMam1YOEtHQlJtT0pNWnFMUFBXbjNBL2VIbnRV UTYxZ3lpWmFrVVZFbFdGcWtKamxGU3FjR21DbkFjMWFFU3JVcWlvRk5UcDBxMEJKZ1UwcmdVOENo dW1Lb0NpL0N0VlJuOTZ0eWo1V3JQYmcxaElhSHExVExVQ0NyQ0NoQXlSUlVxOFV4UlVnNjFvaEc5 NFppMzNVc21mdTRYSDE1L3BYZFJKaEJYSitGSVI1QmZIek0vNmNmL0FGNjdDTWZkRlpUM0tOYlRG M1g4WG91Vy9JSC9BT3RVL3dBSjQvdE0vaUxWVHliblVHVlNmN3E4VlhzWlBKVzd1Q2VJYlptei9u NlZyZkIrM01YZ0MwbGI3MXhKSk1UNjVhb0dkK0J4UzBsTFNBS1drOTZYNlVBRkZGRkFDMFVkNktB Rm9wS1dnQmFLUVV2MW9BS1hGSlMwQUZGRkZBQlJSUlFBdEZKUzBBRkxTVXRBQlJRYUtBQ2lpaWdB cGUzRkpSUUF0RkpSUUF0RkZjNU40MzBXR1o0V2U0TEl4VWxZc2pJb0E2T2lxZW02cFo2dGIvYUxL YnpJd2RyY1lLbjBJckdieDFvaU95RjdnN1NRU0lzaWdEcGFLcWFmcU5wcWxxTG15bDh5UE8zcGdn K2hGVzZBQ2tvb29BS0tLS0FETkZGRkFCUjBvN1VsQUM5cVNpaWdBcEtXa29BS0tXazRvQUtLS1Nn QmNVbEdLS0FDaWtvb0FYRkpSUlFBVWxIYWlnQTdVVVVuYWdBb29vb0FTaWlpZ0FwS1dpZ0JLS0tL QUNrcGFTZ0FvbzdVbEFCUjJvbzVvQVNpanZSUUFtS0tLS0FDaWlpZ0JLS09hS0FDaWlpZ0Fvbzcw VUFGSlMwaG9BS0tLS0FDaWlpZ0FwRDYwdEpRQnhOOUdMZjRtT3ArNXFHa0VIM2FKeC9SaldLd0tU UWs5VEdvUDFIeW45VnJvUEZTK1Q0dzhMWFE0M3l6MnJIL0FINGpnZm1CV0xmcHN1RC9BTE1zZy84 QUh0My9BTE5UUUZhN1VOQ2E4czF5SHlkV200d0d3dy9LdlZac0dNMTV6NHNpMlhzY245NEZmeS8v QUYxcFQzRTlqbldOUkU0cDdWRzFhc2tZUlViQ3BjY1V4aGlwQXJ0eFVUSEJxYVRwVmRxelpRcXZW dUkvSjYxUXoycTlBTVIwNENaZGpYSzlLZnRBb2pPVnB4clpFa1RZcU5qVWoxQXhxUmpXNXFOeFR6 VFRVc0NGaHhVTFZPMVFQN1ZER2lQT090U0kzekNvalN4OHNQclVKak5DUDcrS3RoZWFyUS82d1Zk cmVKSkd3NHFGanhVekNxNzAyQXhqVVo1cFdwTzFReGtUTFViREFxWmhVVFZER1FrNG9Cb2JyU1ZB eWVFNTNWYmdYS3QzNXFuQjNxL2E5RDlhMWdTeVRiZ1UxdUJVeEZRdjByUmdRczN0VVRITk9hb3pX YkFURlJrVkpqaW1NTVZMR1JHa3B6Q20xQXdxUlB1MUhVaWZkcG9HVzRreWxUQk9LWmIvQUhBS214 NzFzaVNndWM5S3N4ZEtnVVZQSHhVb0N3dlNteWpLL2hRRGdVMTMrVTRxK2dqUGs0VTFEVTBuM1RV R2UxWU1wQjNxVlJVZFBXa01sQnAxTUZQRldJY090VEpVUUdLbVNxUWl3ZzRxVWRLaFhQcFVoYkhX dEVJclhRKzdWR2Z0VjY1T1F0VVp4bkhOWlRHUVU5YVpqRlBXc3lpZGFsRlFxYWtVMWFKWTd2VDFw bFNLUGFyUWlXT3JDVlhTcDFxMEJKMnFwY0RFbjRWWkxZcXJPY3lmaFRsc0JRdUNQTVAwcUpSelUw NHkvd0NGUkFZYXVkbEVpY0dyQzFBdldwbDlLcENKUlRxWURUeFZvUTllRFU2VkNvcVphdEFTaWxi cHhUUlFUeFZMWVJTbDREVm5NZm1yUmxHVmJOVUN0WVRLRlNyQ1ZYV3AwT0RTUUZoYWVPdFJLYWtX dFVJN3Z3dkhqVDRlT2NFLytQR3VtVmNNS3gvRDhXMndnd1ArV2EveXJiSTJpc1h1VUY3TDluOEth OVAwSzIyMzlHL3hydS9oOWJmWmZBdWpRNHgvb3FFL2p6WG5IaU4vTCtIbXRObjc3aFAvQUVIL0FC cjFydzlENUdnYWZGMDJXOFkvOGRGUU0xUjBvb29vQVdpaWlnQmFLS0tBRm9vb29BQlMwbExRQVVV VVVBTFJSUlFBdEhla3BhQUNpaWlnQXBhU2lnQmFCUlJRQVV0SlMwQUZGRkZBQjNvb29vQUtLS0tB R3lCL0tmeWgrODJuYm4xN1Y1b2ZBT3VNeExmWnNucVRMLzhBV3JzL0ZsNjFoNGJ1cFkzS1NOaU5H QndRU2Y4QTlkZVlwck9wbzRaTlJ1dDMvWFZxQVBTTkI4UFRhRm8xM0NzcXkzazRKeU9GRFl3b3Jr QjRBMXM0Qit6RDNNdi9BTmF1bDF2VXIyMjhDUlQzRHRGZlRKR2pNdnlrRThuOUJYQXg2MXFxU0tZ OVJ1dC9iOTZUejlLQVBSZE5zVThIZUc3bWFaL1BkZjNzbXpnRThBS0t6RitJMXZ1RzdUWlF2dEtD ZjVWdDMybTNtdmVHWUxhZWI3UGNTTEcweEtaNUhKR1ByV0JIOE9NUG1iVXZrenpzaXdmenpRQjJk bmRRMzFuRGRRRW1LVmR5NXJMOFErSTR2RDR0dzl1MDdUYnVGZmJnREgrTmF0cGF4V05wRmF3THRp aVhZbzlxODQ4ZjNQbmErc0lPUkJDcTQ5enovaFFCcmY4QUN4b2YrZ1pKL3dCL1IvaFZ5dzhlNmJk VExGY3d5MnU3Z08zekwrT09sR20rRHRGZlM3VjdxQXRPMFN0SWZPWWNrZW1hNDN4UllhZnAycnRC cDB2bVJiQVdHN2R0YjB6L0FKNjBBZXBhamZSNmRwczk4NDNwRW0vQVAzdlNzdlFQRkNhL2N6UXgy Y2tJaVRlV1p3M2ZHS3d0Ym5sdHZoM3Axdk1TSnA5aTRQWGFQbS9sdHExOE83WHk5TXVyb2ptV1VL UG9vL3hOQUhaVWxjMXIvakcxMGlacldDUDdUZEw5OFp3cWZVK3Z0WE9ENGhhbnYvNDlyUGIvQUhj Ti9qUUI2UlJXSjRkOFJ3YS9DNEVmazNNZUM4ZWNqQjdnMVgxL3hmYTZOS2JhRlB0TjJQdktHd3Fm VSt2dFFCMGRKWG5JK0lXcDcrYmEwMittR3ovT3VwOFArS0xiWGN3N1BJdTFYSmpKeUdIcXBvQW04 UWEvSG9GdkRJOEJtTXJsUW9iYmdBZGFsMFBWZjdhMDRYZ2dhQlM1VUt6YnM0NzF4ZnhDdVJKcTF2 YkE4UXc3ajlXUCtBcnByQzZ0ZkRuaEt6ZThmWmlJTnRIM25adm13UHpvQTZDdWUxN3hWRG9WNUhi RzJhZG1UZWNQdHh6eFdKWmVMOWMxYS84QXMybjJOc2R4eU53YjVGOVdPYXdQRXMwMTc0am5SM1Y1 Vkt3WlFZWElHT0I5YUFPay93Q0ZpUS85QXlUL0FMK2ovQ3RMUy9HdW02amNMYnlKSmF5dWNMNW5L ayttNFU1ZkJ1Z3BHQThCeUYrWmpPUnorZGVlNjFhMnRyckZ4YjZmSVpZVllCR3prNTlNL1hpZ0Qy VEZKV1hlYXRCb21rUVRhZzU4enkxWFl2M25mSE9LNUM0K0lOODBoTnZhVzhjZllQbGovU2dEMFA2 MFZ4K2krT1lyeTRTMzFDRmJkbk8xWlVQeVo5ODlLNjUyU05HZDJDcW95U1QwRkFDKzFGY1JxWGov QUdUTW1tMnl1aW5IbXpIcjlBSzBkSzhVK1pvTXVxYXFJNGtXWHk0MWlCeS9IdWFBT2wvT2l1Qm44 ZjNrczRTMHNvVVZtMnI1akZqK21LbnN2R0dvdnJrVmhkUTI2cVovSmNxR0JIT1BXZ0R0NlNtWEU4 ZHJieVR6TnRpalVzeDloWEhhVjRyMVhXTlhTMXQ3ZTNXSm0zTVNwSlZQVTg5YUFPMG9vb3hRQWxG RkZBQlNVdEhhZ0JLS0tLQUNrb29vQUtLS0tBRW9vb0ZBQmlrcGFTZ0FveFJSUUFVbExTVUFGRkZG QUJSUlJRQWxGRkZBQlJSUlFBVVVVVUFGSGFpa29BNUx4Nys2ZzBPNy93Q2ZmVjdjNTlBemJmNjFr NjBteTh1Qi9kbUIvTkYvK0pOYS93QVNSandaUE4zaHVJSmMvd0M3SXByTzhSTGpVcm5IZnkyLzlE Rk1ES1k1U3VGOFlSREVjbmNOdC9UL0FPdFhjL3cxeUhpK0xkWmx2N3JCdjZmMXE0ZkVKN0hDdFVa cVZxWVJXekpHWjRwalU2bU1ha0NHU3F6L0FFcXk5VjJGWnNhSXgxcS9DY3gxVEMxY2hYQ1lvZ012 eExoYWVhWkUzeTA4bXQwU1F2VUxWTTFSc0trQ0UwaHB6VXhqaXBZRWJWQTlUTWFnYzFER2lJOWFk R2NFZldreG1uSW56VkZobWhGL3JPS3ZEZ1ZSaU9KQlZzTlhSSFlrRzZWV2ZnMVlicFVMak5EQXJt bTlxa1phWjBxR01ZMVJOVWpHb21xR0NJbTYwbEtSU0NvS0pZT3BxL2FENVcrdFVZUmdtcnRzY0sz MXJTQkxMWnFDVHBVdWMxRTlhQ0t6Q296VXJWR2FnWTJtdFRqd09LWTFTeGtiVTJsTkpVQUZTSjBx T3BFKzdUUXkvYkQ1Vit0U21vSUd4R0ttSEl6VzNRbGxNU0tLY0prOWFwZDZNYzFsekRzWHZQWDFx TnA4OUtyRDBwd0hOUG1BbEkzQ21OQ1IwcVJUaXBRZmVpMXdLbmxQNlU0Uk9PMVhsd2UxU0JBZTFO UUM1bTdXSGFwRjZWY2FJR3F6THRZME9OaER3UUJrbWxXUlIzcW16bkpIYW1iam1seldLTlB6MEg4 VkJ1Rkk2MW5BNXA0RlBtSkxCa0w4WnBubDd3ZmFrUVk3VktuR2FOd0s1aFk5cVVRdjJGWEZOU3FL cmtDNVE4cDg5S1VBaHNWbzdCanB6VVVrWUNzY1VjdGd1VitsVEJsWHJVSTZWWFp5ZUtWN0JZMEJL Zzcwb25UKzlXWUdwNG9Vd3NhRFRyanJ6VVcvZWMxWEF6L1dwa0dCVDVyZ0kwTzRFOTZqOGhpZnUx YlE4VklLZkxjQ2lJSEhhbmlOODlLdnFLVXFQU21vQ0tDZzdzVk12V3BKRUFHZWxWNVcyaklwYkRK L01VSHJUaE1nNm1zMW56UXB6UnpoWTFQT1QxcGpURFBCcWt0U0tPYWZNSW1JM1ZHMEI5S2tIYXBB YzBXdUJVRURlbE9FTGp0VjFSVW0ybnlBWjRSd09sU3BuRldpbFFNdUdwMnNCNm5vOFBsMjZKMDJx QldqTGxWSDFxdnBxNWl6Vm01eUVIMXJuS016eFQveVQ2NFgvbnBmSXYxK1pSL1N2YU5QVFpZd0w2 UnFQMHJ4YnhSejRJdFYvdjZvZy84QUlsZTIyd3hBZy8yUlVqSnhSU1V0QUMwVWZuUlFBdEZGRkFC Uzk2U2wrbEFCUlJSUUF1UGVpaWlnQmFLTzlGQUJRS0tLQUZvb29vQUtLS0tBRm9wS1dnQW9vb29B T2xMU1VVQUxSUjJvb0FLS0tLQUk1b0liaE5rMFNTcDEydW9ZVkZIcDlsRTRlT3p0MGNkQ3NTZzFa b29Bdy9FZXQ2YnBRZ2oxQzFOejV1NWxYYXJZeDM1K3RVZEk4VGVIN3ZVSTRJTEVXMDduYkd4aFVa UHBrZEtiNG84TDMydTZqSFBEY1FSeFJ4YkFyN3M1enowRlZ0RThDUFk2akZkM3QxSEo1TGJsamlC NVlkTWswQVYvaUpkdUo3SzFqZGwycTBqYlRqcndQNVZnZUcvN1VrMXkyK3h2T1NKRkxuSjI3Yzg3 dndyMXNxcE9XVU1mVWlsQUFHQUFCN1VBR09hOGQxUnBkWThUWFBrRHpKSjV5a1l6MTdEOUJYcjhn WXhPRTRZcWR2MXh4WGtPaFhjT2s2OUZjMzZTYllHYmNxREozNEk2VUFXSDhJK0lFVm1ObTVBN0xJ cFA1WnFQdzEvWjhldHhSYXJiczRaOXE3amdJK2Y0aDM1cnI1dmlGcHFSa3cyMXpJL1lPQW8vUE5j WnA4RnhyM2lKTnFmUExONXNoVWNLTjJTYUFOLzRpM082K3M3UUhpT015RWU3SEg4aFhVK0dMWVdY aGV6Unpzekg1cm5wamQ4MmE0SHhvenY0cnV4SURoZGlqL2Qyai82OWRMNGgxZTF2L0NNeWFWTVpG ajhwWlFGSUtwNkg4cUFNVzhid2paM1plTVh1b1NCOXpmdkJzWSs1NzB6VS9GNlgybnlXVnZwTnRC RXk3Y241aXYwNEdLZzhMVGFGQk5NMnRKdWZqeWk2bGtIcndPOVdmRS9pRFQ3NjJXeDBxMlNPQU1I ZVFSQk4zb0I3VUFKNE9rYXhUVjlTSFMzdFRqM1luaitWVWZEZWwvMjlyZ1M1ZG1qQU1zeHp5M1BU UHVUWFNlRmRMTjE0TDFCRUE4eTdMcXYvQUFFY2ZyWE1lSDlXYlFOWDgrV0ppbURGTW5RNC93QWNp Z0QwcWZ3NXBFOW9iWTJFQ0pqQVpFMnN2dm11ZDByd1JlYWJxMXRlQy9oS3hTYmlBcHl5OXgrVlNh cDQ4czFzeU5MV1I3bHVBMHNlQW4rTko0YThRYXhxSXU3eThlUDdGYlJNekZZd3VYeDB6UUJ5ZmlT NkYzNGx2WmZ2SUpkZ0hzdkg5S0d1Si9FdXVRSmVYSWlXUnhHaC9oalhzQUtkNGMweE5jMXhZYmpk NVpEU3k3VHlmYjh6Vi94cG9xYVZxTVZ4YXA1VnRNdnloT2lNT3VQMFA1MEFkOXArbldlZzJEUjJ5 YlVSUzd1ZnZQZ2RUWGswTnZkYXpxVEpiUitiY1RPMG1NL2lhOUV0ZFNmWGZCZHhKRWMzZmtQRzRI WGVGL3FLNHJ3cnFsbm8rcFBkM2lTTVBLS0lJMUJPVDEvUVVBSlA0VzEyM2hlVjdPUW9veTIxd3gv TE5XL0JKMDMrMkVqdTROOXczK29jbjVBMys3NjhjR3Q2NytJRmtzRGl6dHAzbUl3dm1ZVUEvblhN K0VyR2ErOFJRU0lwMlFQNXNqZGgvd0RyTkFDK01MMTczeEZjSXh6SEFmS1JUMngxL00xZjB2eEpv ZW1XYVFybzd5UGo5NUxKdFl1ZS9YK1ZVZkZ0bTloNG1tbGRNeHpzSmt6MGIxSDUxdVE2ajRMa3Ro TExZUnhTNCthTHltSkI5dTFBSEo2emRXVjlmbWV3dEd0WW1YNW8rUHZlb3grRmRYcitxUy84SU5w eXM1RXQyaXE1N3Nxam44K0t6cmJVOU92dFFTMHMvREZtNWtmYW01em5IcWFkNDhrU08vdExHRlFr VnZCd3E5Qm4vd0NzS0FMM2dqUXJXZXhmVWJxRlptWnlrU3VNaFFPcHgvbnBXWjQ0blQrMWtzWUVX T0czUUh5MFhhTnpjazRINFYzSGgyMSt5ZUg3R0U4SHlnemZWdWY2MTU1Si93QVRueGtjY3JOZDQv NENEL2dLQU83MFh3OVlhZnA4QWUxaWt1TnFzOGtpQmp1L3BpdUYxOWZzUGpDZHh4aTRXVWZqaHE5 VVBXdk9QSHNIbDY1RkwybGdYOHdTS0FML0FJODFrTUYwcUIrT0pKeVAvSFYvcldyNFAwYit5OU04 K1pjWE55QXpaNnF2WWYxcmxQQytsdnJtdE5jM1daSVlTSkpTZjQyN0wvbjByMDJnQW83MGxGQUFh S0tLQUVvb29vQUtNVVVVQUpSUlJRQWxIMW9ORkFCbWlpaWdCS0tLS0FDa3BhU2dCYzBsRkZBQlJS UlFBbExTVVVBRkZGRkFCUlJSUUFVVVVDZ0FvTkZCb0E1YjRqSnUrSCtzL3dDekJ1L0lnMWxhNlMx d0g3UGJ4dCtwL3dEaXEzUEhhN3ZBZXRqL0FLYzMvbFdCcWpib2JNLzM3R00vK2dmNDBBWmcrN1hM ZUxoL3hMSmZ3UDY1cnFSOTJ1WjhXeEI5SXVNOWtMZmtLcFBVUjU1NWlIdlNaVmhuTloyL25yVXFT YzF0emlzeXd3cUVxeFBTcDE1SXFkVUE3VTByaUtCaGM5QlRQSWZyaXRNakZNUHJSeUFVVnR6dTVG U2hOZ3dLbVBGUnNlYVZyREJaZ09DY1ZKNTZudlZWeHptb200cGMxaFdMeG1UMXB2bUo2MW5rbW1o em1sempzYURIamlvSEJwSW5KNHF6R29icnpUV29GUXh1ZTFJWVg5SzBnbkhTa0lvNUF1Wm5rUDZW SXNIUE5YRzRxTm00cGN0Z3VSZzdhZXM2OUNhaWJwVVJHS1Y3QVcvUFQxNHBETWg3MVJKSUZNM0VV dWNMRjh1cDZHb3ozcXFyNHF3cDNLS2Q3aFlqS3NXd090SjViSHRWNUl4d2U5U2JBTzFISmNETE1M LzNhQkMyZWhyUllWRVRpamtzQkFJOW40MDRTRk9CM29jNXFOdWFXd3l6OW9VZDZRem9mNHFwdFVa TkhPRmk4WkVQZW1zUVY0TlVnYWtSc3NCUzVnSlQwcU1xeDRBcWJITlRwSFR0Y1JSTVQrbE44dC9T dE1vQlVaSEZISU1wTEVjOUtjVjI4Vk9UaW9tNU5LMWd1S3NtM0E3VktKMUhlcXJETk0vT2xld0NV VVVuZXBHeVJhZUJURnA5VWhEaFVpbW82ZXRNUlBIVmhhcnhWWld0WWlGSTR6VkdiL1dHcnpmZHFo TGtNYVV4b3B0OTQwbEszM2pTVmc5eGoxcVpSVUtkcW1XcVFEd01VNFUzdFNyVmlKVnF6SDZWV1Fa cXluRldoRW9IRk1tQUViVkl0UlhIK3JiNlZWdEFLUis3Vkp1dFhlMVVtNjFoTXBBdk5UcFVDOFZP bEpBeVpSVHhURnhUKzlhSVE1U1FjVktwcUVkYWxUclZDTENkS2t4VWFkS2tGYUlDS1lmSldmY241 QjlhMEovdVZuM0gzQldjd0ttYWxTb2U5U3BXS0tMQ1ZLQlVhR3BSV3FKSENuZzgxR090UFVjMHdK a3FWYWlUcFVxOWEwUU1kaXEwdkQxYTdWVmwrK0tURWoxN1MxL2NyOUtudlJoRit0TjBwZjhBUjAr bFNhZ01SeC83MWN4WmorSlArUlEwd2YzdFdULzBhYTl1ZzRpVWUxZUkrSWpud2xwSC9ZV1Qvd0JH dFh0MFArckgwcVJrdExTVXRBQlMwbExRQVVVVXRBQlJSUlFBdEZGRkFDMFVVbEFDMHRKUzBBRkZG RkFCUzBsTFFBVVVVVUFMM3BLS1B6b0FXaWtwY1VBRkZGRkFCUlJSUUFDaWlpZ0JlbEFwTzFGQUMw VW5haWdBNzBVVVVBRlltcStGTksxZWN6elJ2Rk0zM3BJVzI3dnFPbGJkRkFIS3I4UDlJREFtVzdZ ZW04RCtsYjJuYVZZNlRDWXJLM1dJTjk0OVdiNm1ybEZBR0xyZmhteDF4MWttOHlLZFJ0RXNmWEhv UjNwZEc4TjJtajJkemE3MnVVdUQrODgxUnlNWXhXelJRQnlNL3dBUHROa21MdzNOeENuOXdZWUQ2 RTFZYndMbzV0VWhIbnF5c1dNb2NiMit2SFN1bXBLQUtXazZYRG85Z0xPM2VSbzFZc0RJY25tcU9y K0ZOTjFpWXp5SzhOd2Vza1J4dStvNzF0MFVBY2pCOFB0TmprRFMzVnhNdjl6aFFmeXJvWmRLdFgw bDlNaVR5TFpsMllpNElIZXJ0SlFCamFONFpzdENua210bmxkNUUyZnZDRGdaenh4VnpWZEx0dFlz VGFYTzRKdURCa1BLa1ZkN1VVQVpHaStIcmJRcEpXdFpyaGhLQnVXUmdSeDM2ZGFyYWg0TjBqVUoy bUtTUU94eTNrdGdIM3hYUWNVbmVnRGw0L0FXa0krWGU2Y2VoY0FIOGhYUVdkamE2ZGJpQzBoV0tN YzRVZGZjK3RXS0tBS21vNlphYXRiR0M4aUVpOVFlaFUreHJtejhQZFBNbVZ2YmtKL2R3cC9XdXVv b0F6ZEowSFQ5RlZ2c2tYN3h1R2xjNVkvalZMVXZDTmhxbW9TWGx4TGNlWStNaFdBSEg0VnYwVUFO MkFSN0I4bzI3Ump0V0ZwbmhIVDlMdjB2SVpMaDVVemdTTUNPZndyZW9vQU90ZVplTE5ST3M2NHR0 YWpla0o4bVBIOGJFOC9yL0t2UmIrR2E1c1pvTGVieVpaRjJpUWpPMnVmMEx3Y21qNmdMeVc1Rnc2 QStXTm0zYTNyMW9BMTlFMHROSDB1SzFYQmY3MHJEK0pqMS93QUswS0tLQUVvb29vQUtTaWlnQW9v b29BS1NpaWdBcE9sSFNqTkFCUlJSUUFVbExTVUFGRkZGQUJTVXRKUUFVVVVkNkFFcGFLS0FFeFJS M29vQUtLS0tBQ2lpaWdBb29vb0FLU2lpZ0RDOGFEUGduV2dmK2ZLVC93QkJybWIzblR0TmIxMDZQ K1VWZFQ0d0dmQnV0ZjhBWG5ML0FPZzF5MTBmK0pScFk5ZE5qL2xGUUJuajd0Yzk0cEgvQUJLTHYv cmsvd0Q2Q2E2RWRLNTd4VnhvOTEvMXlmOEE5Qk5VSThoYWxRL01LYTFMRDk2bUZ6VGkrOHRXd0tw eGo1eFZ3Y0N1aU94TmhHcUY2bWFvSG9BaUpwdE9OTnFBR3NLaGVwbTZWQy9TcFkwVjNxT3BHcU05 YXpLUlBiSDVzVm8yL1ExbjIyTjM0Vm9XL2V0SUVzc0VWRTFTbnBVVDFxeEVMMUNUVXIxRWF6WURU VEdGUHBqZGFsaklYRlF0MXFaNmdicldiR2dCcTVEOXdWVEZYSXZ1clZSQm1qR0J0RksxSkgwRks5 Ym9rZ2VvR3FkNnJ0VU1ZdzlLYWVsT05OUFNvQWphb202MUszV29tcUdOQ1U2UDc0cHRPaisrS0VO bGorSVZmVWZMVkQrSVZvUjlLMWlTTllWWGVyRGRLclBUWUVUR21VNXFiV1l4RFVaNjFJYWpwV0Fi UmlseFNHcHNNY3BxUVZFS2VEelRFeVFVOVJUVkZTamlxUWlTT3JDMVhWaFVnY0N0RTBGaVluaXFF dkx0VTdTZ0hPZUtyczI1c2lsSjNCRlJ2dkdrcVJvejFwbXc1ckt4UTVhbVUxQ0JnMDhkYVltVERt bkxVYUVHcFl4a21xUWlSUHBWaEtoR0trVmhWb1JPS1pNUVkyK2xOOHdBVkhKSUNwR2FwdlFMRmM5 RFZKaFYwZWxWMmpJckdTS1JFb3FaS2J0STdVNWFTVEFtV3BCVUlxVkt0Q0hxTTFLZ3BxRGlwQWNH ckVTcDBxVHRVSVlDbkZ4aXJUQUpqOGxaMXlNb0RWeDNCR0tyU0x2R0JVUzFHaWppcFVGT0tIMG9D bjByS3pHU3BVb05RS0NLa0JxMFNUQVU5UlRCMnFZREZXZ0hKeFVvcUlHbmhoVklHU0U4VldtKzlV ak9CVUxObHFIc0pIdE9sTC9veWZTbDFRWWpqLzNxZnBJLzBWUDkwVTNWK0lvLzk0MXpGbUo0Z0gv RkphTi8yRmsvOUd0WHQ4WDNCOUs4UTEvL0FKRkhSZjhBc0xwLzZOYXZiNHZ1Q3BHUzB0SlNpZ0Fw YVNsb0FLVVVsRkFDMFVVVUFMUnpSUlFBZHFXa3BhQUNpaWlnQmFLS1NnQmFLS0tBRm83MFVVQUZG RkZBQlMwbEZBQzBkcVNpZ0JhS0tLQUNpaWlnQmFTaWlnQW9vb29BS0tLS0FDaWlpZ0FvcEtLQUNq dFJSUUFVVVVVQUgwb29vb0FTaWlpZ0Fvb29vQU8xSlJSUUFVbExTVUFIYWlpaWdBcEtVMGxBQlJS U2Q2QUZwS0tLQUQ2VW1hS0tBQ2lpaWdCS0tLS0FDajhhT2FTZ0Fvb3BLQUNpaWlnQW9vb29BU2lp aWdBNHBPMUxSUUFsRkgwb29BS0tLS0FFb29vb0FLS0tLQUNpakZIMG9BS0tLS0FDa29vb0FLS08x RkFHTDR2L0FPUk4xbi9yeWwvOUJOY3JjLzhBSUowbi9zR3gvd0FvcTZyeGQveUp1cy85ZVV2L0FL Q2E1VzQvNUJPay93RFlPai85QmlvQW9MOTJ1ZThWL3dESUd1dit1VC8rZ211aEhBNHJudkZYL0lJ dWYrdWJmK2dtcUVlUWtacFVYNWhVaFE1NlZJa1JKSEZVa0l0UmNNS3Q1cWtEdElOV0ZjSG5OYlJK SHRVVEROUExBMDAwMkJBUmltMU1SbW9tR0R4VTJHTVkxQTlTT2VhaVlacUdORUxWSDNxWW9mU2tX TTU2Vm14anJZWWV0R0E5ZUtxUlJsVG1yRWJoZURXa1JNdG1vMnBQTUZKdUZhaUluRlFrVlliQnFO MTRyTmdRbW8yTlNOMHFFMUl4ajlhZ2JyVXhCUGFtN0NmV3MybU5FZU9LdVEvY0ZRTEdUMEhOV1ZY Q2lxaUJlalB5aW5OVmRKQWU5UDhBTUZiSmtqWHFCdnBVN0VIdlVaRlN4a0JGTlBTcEhHS2liakZR TVkxUXQxcVEwd3JVTkFKVG8vdmltN1Q2VklpSElPT0tMQVRmeGlyNm5pcy92VmhaQm5nMXBGaUoy TlYzRlBNZ05OSkZOZ1FNS1pVekROUk53YWtZdzlLWWFWanppbTQrdFNCYUNLZTFQRVNlbWFZcHFl UG1yc0laNUF4bkZSdEJ4bXJvcHJyOHBwOG9GSE9CVVpsSnB6L2RxR3MyTkQvTmFsRWpldFJkNmtX a01mdUo0N1U5YWFCVHdLb1JLTU1CeFRoR3A3Vkd0VEpWSVFvaFQrN1FZRi91MU1vcVRHUlYyUUdl OGV3OUtZMG13Y1ZhdVJ3S29UOUZxSmFBS1ptOWFCSzNyVUZQV291T3hNSGYxcHlrbHFhdFNBVlZ4 TWZVb0NuZ2lvYWtXcVFFZ2pVOXFlSVUvdTBpVk10V3RRSVRBdnBVSlRZMkt2WUpxcmNERW40VU5D SUhsMjhWRjV6WjYwMmM0a05SRDcxWXRzb3NDVit1YWVKSHFCT3RUcUthWWh5NTNWTW81cU1DbnJW b1JLRVU5cWNzYWVsTVU4MU10V2dFOGxmU21OQXZYSFNyQW9aZUtkZ0tlY1pxRnBqNjFMTHdyVlJa cXlrN0RKL1BiSFduTEkzclZaZXRUb0tTWUV1NWo2MDllbE5XbmdWb2hIdU9rai9SRStncHV0ZjZx TC9lUDhxazBnWnM0ei9zaW85YkdJWWY5NC95ckFvd3RlLzVGSFJmK3dzbi9vMXE5d2krNEs4TzEz L2tVTkcvN0M2LytqV3IzR0w3aTFJeVdsRkpTMEFZL2l2VnA5RDhOWG1vMnlSdk5EczJpVUVxY3Vx ODRJN05YbWYvQUF0blgvOEFuMTAzL3YxSi93REYxM3Z4RS81RVBVdisyWC9vMUs4SG9BN3YvaGJH di84QVBycHYvZnFUL3dDTG8vNFd6ci8vQUQ2NmIvMzZrLzhBaTY0U2tOQUhlZjhBQzJkZi93Q2ZY VFArL1VuL0FNWFNmOExhMS84QTU5ZE4vd0MvVW4veGRjSWFiUUIzdi9DMjlmNi9aZE0vNzlTZi9G MGY4TGMxL3dENTlkTS83OVNmL0Yxd1ZKUUIzdjhBd3R6eEIvejY2Wi8zNmsvK0xvLzRXOTRnL3dD ZlhUUCsvVW4vQU1YWEFVbmFnRHZ6OFgvRUgvUHJwbi9mcVQvNHVrLzRXLzRoL3dDZlRUUCsvVW4v QU1YWEFVbEFIb0gvQUF1RHhEL3o2YVovMzZrLytPVW4vQzRmRVA4QXo2YVgvd0IrcFA4QTQ1WG45 Tk5BSG9QL0FBdUx4RVArWFRTLysvVW4vd0FYU2Y4QUM0L0VQL1BucGY4QTM2ay8rT1Y1NmVsSWFB UFF2K0Z5ZUl2K2ZQUy8rL1VuL3dBWFIvd3VYeEYvejU2WC93QitaUDhBNDVYbmxOb0E5RS80WE40 ai93Q2ZQU3YrL01uL0FNY3B2L0M1L0VmL0FENTZWLzM1ay84QWk2ODdOSlFCNkwvd3VqeEgvd0Er ZWxmOStaUC9BSTVTZjhMcDhTZjgrZWxmOStaUC9qbGVjOXFiUUI2UC93QUxxOFNmOCtXay93RGZt VC80NVRUOGEvRW4vUG5wUC9mbVQvNDVYbk5NTkFIcEgvQzdQRW8vNWN0Si93Qy9Nbi94eWsvNFhk NGwvd0NmTFNmKy9Nbi9BTWNyemVtbWdEMG4vaGQvaVgvbnkwbi9BTDh5Zi9IS1EvSER4Ti96NWFU L0FOK1pQL2psZWFtbW1nRDB2L2hlSGliL0FKOHRJLzc4eWY4QXh5ay80WGw0bS81OGRJLzc4eWYv QUJ5dk5EVFRRQjZaL3dBTHo4VC9BUFBqcEgvZm1ULzQ1U2Y4TDA4VC93RFBqcEgvQUg1ay93RGps ZVpHbW5yUUI2Yi9BTUwxOFRqL0FKY2RJLzc4eWY4QXh5a1B4MjhUL3dEUGpvLy9BSDVsL3dEamxl WkdtbWdEMDcvaGUvaWovbngwZi92ekwvOEFIS1EvSGZ4Ui93QStHai85K1pmL0FJNVhtRk5OQUhx SC9DK2ZGSC9QaG8vL0FINWwvd0RqbEovd3ZueFIvd0ErR2ovOStaZi9BSTVYbHhwS0FQVWYrRjll S2Y4QW53MGYvdnpML3dESEtUL2hmZmluL253MGIvdnpMLzhBSEs4dU5OTkFIcVgvQUF2enhWL3o0 YVAvQU4rWmYvamxJZmo1NHEvNThORy83OHkvL0hLOHNwRFFCNm4vQU1MOThWZjgrR2pmOStaZi9q bEovd0FMKzhWZHJEUnYrL012L3dBY3J5czBsQUhxbi9DL3ZGWC9BRDRhTi8zNWwvOEFqbEovd3Y4 QThWZjlBL1J2Ky9Ndi93QWNyeXVtbWdEMWIvaGYvaXYvQUtCK2pmOEFmbVgvQU9PVW4vRFFIaXYv QUtCK2pmOEFmbVgvQU9PVjVVYWJRQjZ0L3dBTkErSy8rZ2Zvdi9mbVgvNDVTZjhBRFFQaXYvb0g2 TC8zNWwvK09WNVRTVUFlcmY4QURRWGl2L29INkwvMzVsLytPVWY4TkErSy93RG9INkwvQU4rWmYv amxlVVVob0E5WS93Q0dndkZuL1FQMFgvdnpMLzhBSEtUL0FJYUM4Vi85QS9SZisvTXYvd0Fjcnlp aWdEMWYvaG9IeFgvMEQ5Ri83OHkvL0hLUCtHZ2ZGZjhBMEQ5Ri93Qy9NdjhBOGNyeWlpZ0QxZjhB NGFCOFYvOEFRUDBYL3Z6TC93REhLUDhBaG9IeFgvMEQ5Ri83OHkvL0FCeXZLS0tBUFYvK0dnZkZm L1FQMFgvdnpMLzhjby80YUI4Vi93RFFQMFgvQUw4eS93RHh5dktLS0FQVi93RGhvSHhYL3dCQS9S ZisvTXYvQU1jcFArR2dQRmYvQUVEOUcvNzh5LzhBeHl2S2FLQVBWdjhBaG9EeFgvMEQ5Ry83OHkv L0FCeWovaG9EeFgvMEQ5Ri83OHkvL0hLOHBvb0E5Vy80WC80ci93Q2dmbzMvQUg1bC93RGpsSC9D L3dEeFgvMEQ5Ry83OHkvL0FCeXZLYUtBUFZ2K0YvOEFpdjhBNkIramY5K1pmL2psSC9DLy9GWC9B RUQ5Ry83OHkvOEF4eXZLYUtBUFZ2OEFoZjhBNHEvNkIramY5K1pmL2psSi93QUwvd0RGWC9RUDBi L3Z6TC84Y3J5cWlnRDFYL2hmL2lyL0FLQitqZjhBZm1YL0FPT1VmOEwvQVBGWC9RUDBiL3Z6TC84 QUhLOHFvb0E5Vi80WC93Q0t2K2dmbzMvZm1YLzQ1Ui93djd4Vi93QStHamY5K1pmL0FJNVhsVkZB SHF2L0FBdjd4Vi8wRDlHLzc4eS8vSEtQK0YvZUt2OEFvSDZOL3dCK1pmOEE0NVhsVkZBSHF2OEF3 djN4Vi96NGFOLzM1bC8rT1VmOEw5OFZmOCtHamY4QWZtWC9BT09WNVZSUUI2ci9BTUw5OFZmOCtH amY5K1pmL2psSi93QUw5OFZmOCtHamY5K1pmL2psZVYwVUFlcS84TDk4VmY4QVBobzMvZm1YL3dD T1VuL0MvZkZYL1BobzMvZm1YLzQ1WGxkRkFIcW4vQy9mRlgvUGhvMy9BSDVsL3dEamxIL0MvUEZY L1BobzMvZm1YLzQ1WGxkRkFIcW4vQy9QRlgvUGhvMy9BSDVsL3dEamxIL0MvUEZYL1BobzMvZm1Y LzQ1WGxkRkFIcW4vQy9QRlgvUGhvMy9BSDVsL3dEamxIL0MvZkZYL1BobzMvZm1YLzQ1WGxkRkFI cW4vQy9mRlgvUGhvMy9BSDVsL3dEamxIL0MvUEZQL1FQMGIvdnpMLzhBSEs4cm9vQStpZmhqOFRk WjhhZUpiblR0UnRyQ0tHT3phY0czamRXM0IwWCtKeU1mTWE5VzdWODZmQUwvQUpIdTkvN0Jrbi9v Mkt2b3VnQW9vb29BeGZGMy9JbmF6LzE1Uy84QW9Kcmxibi9rRTZUL0FOZzJQLzBHS3VxOFhmOEFJ bmF6L3dCZVV2OEE2Q2E1VzUvNUJPay85ZzJQL3dCQmlvQW9qcFhQK0poblRaeC9zTi9LdWdyQThT LzhnNmIvQUhXL2xWSVI1b1kxeDBwTUFEZ1U5cWpKcm9zU1J0MHFMY3k5RFUxUnNLa0NNeU1CMXB2 bnNCMW9jVlhZMURZeXlrNTlhbURic0dzOE5nMWNnTzVLYVl5ZFlnM3pZcVR5UjZWSkd2eTA4aXRF aVVWekVvSFNtR05QU3BucUZqU3NBMStuSEZRc0trTk1hcFl5SXV3NzAweXY2MDVoVUw5S2k0SWY1 N2V0UFdZazFVcHlOODFLNHk2QnVJcVpZUjZVeUlmdkJWekdLMWloRmN3cU8xTk1TRHNLc01PS2hi aWl3RWVGWG5GUk4xTlBZMHcxTEVRbktuZzBoZGdPdFNFY1ZDOVEyVUo1ekR2U2laczlhaU5JS203 QXRCeS80VklrZTg1cXZBZXRYclpjcTMxclNPb2hCQ3ZwU0dKQjJxMWpGUlBWdEFRTWllbE1iQVhG T1kxR2FoZ043VkdjcjBxUTB4cWtFTUxzTzlKNWorcHBEU1ZOeGovTWIxcCs3Y00xRFVpZmRvUXlW SXQzelZMNUFQYW53TG1NVk1NNDZWcHlrbEpldFdJcXJyMXF4SHhRZ0xDamlteThMK0ZPV215OHJW OUJHYko5dzFEVXovY05RMWd5a0ozcVZhaTcxSXRJWk1CVHFZRFRoVmlIQ3BrcUVDcGtxa0lzcDBG U2djVkVsU2c4Vm9oRlM1UFNxRS9SYXZYUTZWUm43Vm5JWkRUMHBsUFdza01uU3BSVVMxS0RXaUVI ZW5yVE85UFVWUzNFVEoxcXdsVjA0cXduU3RFQkoyNHFsY2Y2ejhLdVpxbmNmNno4S0pBVUxrZnZE VVM5YWx1UDlZYWlGYzczS0prcWRhcnBWaGZyVklSSUtjT3ROQXAzZXJFUFhyVTZWQ29xWkt0QVNp aHFBYUc2VlhRUlJsR1ZhczVoaHEwWmZ1dFdlMzNxd2tVaHlWWVFWWFhpckNHa2daT3RQNzFHdFA2 MXFoSHVtampObkgvdWlvdGVHSVlmOTgveXFmUmgvb2NYKzZLaDhRLzZtRC9mUDhxd0tPZTF6L2tU OUYvN0M2LytqV3IzS0w3Z3J3M1cvd0RrVHRGLzdDeS8ram1yM0tMN2kxSXlXaWlpZ0RtZmlIL3lJ ZXBmOXN2L0FFYWxlRDE3eDhSRC93QVVKcVgvQUd5LzlHcFhnOUFCU1V0SjJvQUtTbE5KUUFsSlMw bEFEVFNHbFBTaWdCdEpTMGxBQ1UwMDZtbWdCcDZVaHBUMHBEUUFsTnAxTm9BYWFRMHBwRFFBMm0w Nm0wQUpUVFRxYWFBR21tbW5HbW1nQnBwcHB4cHBvQVEwMDA0MDAwQU5OTk5PTk5OQUNHbW1uR21t Z0J0Tk5PcHBvQWFhU2xOSlFBMDBocFRTR2dCdElhV2tOQURUU1VwcEtBRXBwcDFOTkFDR2twVFNV QUpTVXRKUUFsSWFXa05BQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVV QUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRkZBQlJS UlFCNnA4QXYrUjd2Zit3Wkovd0NqWXEraTYrZFBnRi95UGQ3L0FOZ3lULzBiRlgwWFFBVVVVVUFZ dmk3L0FKRTNXZjhBcnlsLzlCTmNyYy84Z25TZit3Ykgvd0NneFYxWGk3L2tUZFovNjhwZi9RVFhL M1AvQUNDZEovN0JzZjhBNkRGUUJScm4vRXYvQUNEWi93RGNiK1ZkQlhQK0pmOEFrR3ovQU80Mzhx cGJpUE5XcU0vV3BXRlJHdWdrVEZNYW45cVkxU0JCSlZaNnN5ZEtyTldjaWhnSE5YNFJpT3FJOWF2 UW5NZEVCTXZ4SDVha2FtUkRDOWFjMWJva2hlb1c2Vk05UXNLbGpJNlE5S1VqRk5OUXdHTlZlU3Ay cUJ4bW9ZMFFtblJqTERQclRTS2RIdzQrdFQxR2FNWCtzRlhoeUtwUS93Q3NGWGVncm9qc1NNYnBW WjZzdFZaNkdCQzFKMnB6VTN0VUF4cDZWQzFTc2FpYW9ZMFF0MXBLVnV0SlVGRTBIZXIxcDMrdFVZ TzlYN1hnTjlhMWdTeXlhZ2ZwVXhOUXlkSzBZaXMxUm1wR0JxTWlzbU1USEZOYW5kcVkxSmpJMkZO cHpVMm9BS2tUcFVkU0owcG9iTDFzZmxBOTZueFVGdVBrQnFmTmJvbGxKUnpVeUhGVS9QeFFKeldT WTdHaHVHS1k3NVdxZ25OTkxzeHF1WUxBNE93MURpcklwVENDYWl3RlduS2FzaTJGTDlsbzVRSVFl YWtGQnR5S0FNWUZPd0VpaXBVcXVaUW9wUHRCcWt4R2dwcFdiSGVzOFhKcGZ0QnF1WUxFODV6aXFr d3ppbnEyNnBGWGNwelV2VVpTSXdhVmZ4cTM5bkZQRnFDTTFQSUZ5c3BxUlR6VXYyWEhTbW1Jb2Zh cXNJTzlUSXRRMHJUYlJnVXdMU2pGU2c0TlovMm9pbEYwVFQ1Z3N6UUxDcXMzTW40VkY5b1k4VUtj am1qbXVLeERNdVpPbFJiY0dyNGpETDcwbjJZWjRxSEVkeW12V3BsTlRpMUZMOW13S2Fpd0kxUE5T cjFwbmxGVDdVNE1GcWhFcTFLdFUvdE9LQmRjMVZ3TCthUm02MVNGeWMwR1V0M281Z0hQME5VMlQy cTZvcFRBRzVxWEc0eWdvK3RUTDFxeUxVR25DMUFvVVFJUWFsV2cyK09sQUczakZVa0k5NTBjWXM0 LzkwVlg4UmNXOEgrK2Y1VmEwWVpzb3ovc2lxdmlRWXQ3Zi9mUDhxd0tPZDF2L2tUdEUvN0N5LzhB bzVxOXlpKzRLOE0xci9rVGRGLzdDNi8ram1yM09MN2dxUmt0RkZGQUhNZkVUL2tROVQra1gvbzFL OElyM2Y0aWY4aUhxZjBpL3dEUnFWNFAyb0FXa3BhUTBBSWVsRkI2VVVBTm9wYVNnQnA2VUdnOUtE UUEya3BhU2dCdElhZFRUUUEwOUtRMHA2VWhvQVNtbW5VMmdCcHBLVTBsQURhYlRxYlFBbE5OT3Bw b0FhYWFhY2FhYUFHbW1tbkdtbWdCRFRUVGpUVFFBMDAwMDQwMDBBSWFhYWNhYWFBRzAwMDZtbWdC cHBLVTBsQURUU0dsTklhQUcwaHBhUTBBTk5KU21rb0FTbW1uVTAwQUlhU2xOSlFBbEpTMGxBQ1Vo cGFRMEFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZG QUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUhxbndDL3dD Ujd2Zit3WkovNk5pcjZMcjUxK0FQL0k5M3YvWU1rLzhBUnNWZlJWQUJSUlJRQmkrTHYrUk4xbi9y eWwvOUJOY3JjZjhBSUowbi9zSFIvd0RvTVZkVjR1LzVFM1dmK3ZLWC93QkJOY3JjL3dESUowbi9B TEIwZi9vTVZBRkdzTHhHdS9UNVY2WkJINlZ1MWthN0M4bW55YkYzTmpqNjFTRWVYTlViQ3BibUM2 dEZEWEVXd0gvYUIvbFZjU2h1TTF2ZE1td0hnVkV4cVVqUEFvRUdldEFGUjZpWVo2Vm9mWlFhVDdL dFR5REtDeDFiaUdFeFVua0tEbWtQV2psc0Z5eEcyRnArYzFSOHdvYVB0SkZWeldGWXR0VVpHYXJt NitsSjlwcGN5QWtiZ2NWRzFPTHEvU21sQzFJWkN4NHFKdlNydjJiTkgyUUNwNVJtZnR5YWVxNFlZ cTRiWVVDSlZIU2x5QUVadzRKcTBHejFxa2VLUVRzdFdwV0pMekhJcUpxckc2SXBQdEpOSE1PeEt5 MUdlS1FUaWxKeU9LUVdJbU5SdFU0aExVNzdOeFV0REtKR2FRS2F2RzFBcHYyY0NseWdRd2dqZHhW eUZzS2FpWlF1QUtZVzJ0eFRXZ0YvZGtVeHVsVkJjRVUwM0p6VmM0ckZodWxSTjB6VWYyaW5DVU1Q ZXB1TVNvMnFRanJRc0pZVXR3SzVwS3RmWnFRMjJLWEtCV3FST0JVdmtnVTFsdzFDUXl4RTJFSE5U SzR4V2Z2S25pbDg5cXZtc0lob29vcklZcWlucUtSYWtGVWhEaDFxUUhtb2hUMXFnTENjMUtvcUdP cksxYUpHc21hcHlEYTVGYUI0R2FvVGN5R2lReW14NU5OelN0OTQwbFlGRDFxUUNtSlVxMVNFeHlq RlNKeFRBS1Zhb1JPcHFkQlZaZXRXWTZ0Q0g0NHFLUlAzYlZPb3BzL0ViZlNyZXdGRHArVlZTM3JW ckhGVVdITllTWlE0SG1wVkZSSlV5ZGFTQWtWYWtVWXBxMC92V2lFUFU0cVZUbW9SMXFSS3BDTENp bmxRUlRVNkNuaXRFRElaVndsVVorRkhhdENjL0pXZGNES0FWbklDdVdKTk9VODFDS2xUazFpbU1u VVZLb3BpVktCV3FBY1BhcEZOUjk2Y090VWhFNjA4Q29rTlRMVm9BSzFYa0dHcTMycXJOOTZreEk5 MzBYaXhpLzNCVmJ4TC93QWUxdjhBNzUvbFZuUkIvb01mKzZLcmVKc0MydC8rdWgvbFhLV2Mzck9Q K0VOMFQvc0xyLzZPYXZjNHZ1RDZWNFpyUC9JbTZKLzJGbC85SE5YdWNYM0JTR1MwVWxMelFCekh4 RS81RVBVLysyWC9BS05TdkNLOTMrSWYvSWlhbC8yeS93RFJxVjRSUUFZb294NzBVQUpTVUhwUlFB bEpTMGxBRFQwb05Cb05BRGFTbHBLQUVwcHAxTk5BRFQwcERUalRUUUFsTk5PcHRBRFRTR2xOSWFB RzAyblUyZ0JLYWFkVFRRQTAwMDA0MDAwQU5OTk5PTk5OQUNHbW1uR21tZ0JwcHBweHBwb0FRMDAw NDAwMEFOcHBwMU5OQURUU1VwcEtBR21rTkthUTBBTnBEUzBob0FhYVNsTkpRQWxOTk9wcG9BUTBs S2FTZ0JLU2xwS0FFcERTMGhvQUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FD aWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29v QUtLS0tBUFZQZ0QveVBkNy9BTmd5VC8wYkZYMFhYenA4QXY4QWtlNzMvc0d5ZitqWXEraTZBQ2lp aWdERjhYZjhpYnJQL1hsTC93Q2dtdVZ1UCtRVHBQOEEyRG8vL1FZcTZyeGQvd0FpYnJQL0FGNXkv d0RvSnJsTHIva0U2VC8yRG8vNVJVQVVxdDZXak5xVUlUYnUrYkc3cDBOVXZ4cTlwREZkVWhJNjgv eXFuc0k1SDRxMjBpMkNTU0NJYmVRVXpuN3lqdjhBV3ZKa2Y1cTlqK0xaM2FMbi9QMzByeGlNWllV NHNMR2pIeXdxenRxdkZ3d3EyT2E2STdFalNPS2phcFdxQis5REFZeDk2ak5PSnB0UXdJM0dlS2lZ Vk93cUYrbFN4bGRqaW1oc0dsZnJVWjlLekdXb0RselY2QVZuMm8rZXRLM1BXdElDYUpRdUtZNHFZ aW9ueDJyVmlJV1BGUnNlS2MzV29pYXpZRFRVYmRLazdVeGhVc1pBM0ZSazFLNHFFOEdzMk5DaHNW YmlPVkZVZ0t1UkQ1RkZVZ1plVkJ0Rk9LNEZPajZBVXJldGJyWWxGZGhpb21OU3lWWFk5cWhnTmFv MkdhZWFROUt6R2lGcWpKcVZxaWJyVXNvU25wOThVeW5SL2ZGQ0JrLzhRcTZxZE9LcC93QVFyUVEv TFdzU1JqQVZDMVdHcXM5TmdSc2FqT1RUbTRwbUt6WXhqQ21FYzFLUlVaNjByQU5wTzlMUlVqSHJV Z3FJR25nODFTRVBwd3BvcVJSVkNKb3VvcXl0VmtHS25VMW9oRWg2R3FFdjN6Vnd0VktVL09hbVkw VTIrOGFTbFlEY2FUNjFpOXhraWRxbFdvVXFWVFZJR1NVNGRhWUtjdFVoRXExWWpxQlJVNmNWYUVU TFRKLzlXLzBwd09CVWNyWmpiNlZZRk05UHdxa3g1cTcvQUlWVFljMWhNb0VxWktoWHJVcTBrREox cDQ2MUVwcVVWYUVLT3RTcDFwaWlwVkZXSW1UcFVvcUphZm5GV2dHVEQ1S3o3amhCelY2VWt4MVJ1 QmxCVVRCYkZQSE5TSjFwdTNGUFhyV0tRK2hZU3BSVUNtcGxOYUlRL3ZUZ09hYlVpaXJBZWdxWmV0 UnFLa1dxUU1kemlxMHYzNnNFMVdrNWVoN0NSN3pvbi9IakYvdWlxM2lmL2ozdC93RGZQOHF0YUdQ OUJpLzNSVlh4Ui94N1crZjc1L2xYS1djMXJQOEF5Sm1pZjloZGYvUnoxN25GOXdWNFhySC9BQ0pt aWY4QVlYWC9BTkhQWHVrUStVVWhrbEtLU2xvQTVqNGlmOGlIcVgvYkwvMGFsZUVWN3Y4QUVUL2tS TlMvN1pmK2pVcndpZ0FwTzFMUWFBR25wUlNta29BU2twYVNnQkRUYVh0U0dnQktTbDlhU2dCRFRU VHUxTlBTZ0JwNlVocFQwcERRQWxOcDFOb0FhYVEwcHBLQUc5cWJUcWJRQWxOTk9wcG9BYWFhYWNh YWFBR21tbW5HbW1nQkRUVFRqVFRRQTAwMDA0MDAwQUlhYWFjYWFhQUcwMDA2bW1nQnBwS1UwbEFE VFNHbE5JYUFHMGhwYVEwQU5OSlNta29BU21tblUwMEFJYVNsTkpRQWxKUzBsQUNVaHBhUTBBRkZG RkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFV VVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFIcW53Qy93Q1I3dmYrd2JK LzZOaXI2THI1MCtBWC9JOTN2L1lNay84QVJzVmZSZEFCUlJSUUJpK0x2K1JPMW4vcnlsLzlCTmNy ZGY4QUlKMGovc0d4L3dEb01WZFY0dS81RTNXZit2S1gvd0JCTmNwYy93RElLMGovQUxCMGYvb01W QUZDcm1rLzhoS0g4ZjVWVHE1cFgvSVNoSDEvbFZNUnpmeFkvd0NRSi9uKytsZU5SSERnVjdOOFZ4 blJSL24rTks4YlJQbUJORVFMOGYzbHE0dkFxbkhuY0t0QTEweDJKRmFvSHFZbW95S0FJQ0tiVWpD b3pVTUJyZEtoY2NWSXhxSitsU3hrRDljVkYzcVZoVE51YXpZMFQyMzNxMExmdldmYmpEMWZnYkdh MGdKbG85S2hlbjV5S1kxYWlJSDYxRVJVekNveldiQWo3VXcxSWVsUk1haGpJbnFCdXRUT2FpSXp6 VU1hRUhBcTVGOTFhcUJhdHhEQ2lxaU0wbytsRGRLWWpZVVU1anhXeVpCREpWZHFzTlVMQ3BZRVJw RDBwV0ZOWTRxQm9qYW9tNjFLMVFtb1l3cDBmM3hUUlRrUHo0b0dXUDRoVjlCeFdlUHZDcnluZ1Zy RWtWcXJ2VmhqVUQwMkJBd3pUYWUxTVBGUU1hMVIwOWpVZWFnQi9sTlNlUzlXbHFSUlZjdHd1VXZL WWV0RzFnZWxhT3lvM2o0cDh0aFhLdzRxVHpGQnFKajhwTlE3czgxTjdETGduVVU3N1N2clZEUE5P Rk5TQ3hjYTRIWTB6ZHZPYWhBcVVVN2dJME9RU0taNURlbFdWTlNLT2MwS053S2dnY2RxWHluSGFy NFhQYWxaTUNueUNLQ2c1UGFwVUlHYzA2WmR2U3E4amJRS05nc1dCTWc3MDRUcDYxbjdxVUdsekRz YVAyaGFqYWJjY0RwVllkYWVvNXA4d2lUMnBHdHpqaWw3MU9wbzNBcWZabUhHS2NMZHgycTRPdFNn WnBxQUdmNWJnOUtjbjNhdWxLcnlMdGJBcDh0aFhGUWdMelNpWlBXcWtyNGJiVVc2cDVobWlKMTlh ZDlvWDFyT0JxUURQRlZ6Qll0R2JjTVUwcnZxTlJpcDBPS0JFRFc3RTBuMmRzOUt1QTgxSW96VDVR dVVSQTRwMjFsNmlyMjJtc3VldUtmSUJYWGlwTjZyMXFKdUFUNlZXZVRQV3Bic012OEFuSUQxcGZ0 Q1o2MW1ocWV2clFwQll2dE9NY1ZIbmR6VUsxTXZTcUVlKzZIeFl4ZjdnL2xWWHhUeGIyLysrZjVW YjBUL0FJOFlmOXdmeXFwNHFIK2pXeC82YUgrVllGSE02eC95Sm1pZjloZGYvUnoxN3BGOXdWNFhx LzhBeUplaWY5aGRmL1J6MTduRjl3Vkl5V2lpakZBSE0vRVAva1JOUy83WmYralVyd2l2ZC9pSC93 QWlKcVgvQUd5LzlHcFhoRkFCU0dscEtBRW9vb29BU2twYVNnQnRJYVU5S0RRQTJrNzB0SlFBbE5Q U25VMDBBTlBTa05PTk5OQUNVMm5VMmdCdEpTbWtvQWJUYWRUYUFFcHBwMU5OQURUVFRUalRUUUEw MDAwNDAwMEFJYWFhY2FhYUFHbW1tbkdtbWdCRFRUVGpUVFFBMm1tblUwMEFOTkpTbWtvQWFhUTBw cERRQTJrTkxTR2dCcHBLVTBsQUNVMDA2bW1nQkRTVXBwS0FFcEtXa29BU2tOTFNHZ0Fvb29vQUtL S0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdB b29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQTlVK0FYL0k5M3Y4QTJEWlAvUnNW ZlJmNDE4NmZBTC9rZTczL0FMQnNuL28yS3ZvdWdBb05GQm9BeGZGMy9JbmF6LzE1Uy84QW9Kcmxi bi9rRmFSLzJEWS8vUVlxNnJ4ZC93QWlkclAvQUY1Uy93RG9KcmxMci9rRjZQOEE5ZzJQL3dCQmlv QW9WYzByL2tKUmZqL0txZFhOSy81Q1VYNC95cW1JNS80cEx2MGxWK3YvQUtFbGVSckRqa2l2WC9p Yi93QWc1UHgvOUNXdktHUEZhUVdnbVJmZE9hY3M0OWFhUmtWQ3d4VlhzSXNtZGZXazg5Y1ZTYW84 NHBPUUdqNWlzT3RNYnJWSlh4VnBDU0JTVHVNWXlNemNVbmt1ZTFYSTErWE5TYmNWWExjUm1tMmJQ U2dXekR0V2dhakpvNUxESy9sYkQwcGZNMlU5elVMMHRoRTYzQzQ2MEdkUFdxYlZHVFU4dzdGMHpK UnVWZ2NWbjc2a1I4SDYwY3c3RTU2VkhzY2pwVXlMbGdLc2hCVDVia21lYmR5T2xOK3p0NlZwa1lw alVjZzdsRmJjanJUOXUwWUZUc2VLaE5JTGlwUHRJVW1wRGNMVlZoVWJjQ2x6V0F1R2RDT3ROODFE M3FpVFFEUzVoMkxqa2RxaVlFc0tTTnQyUlZpRk4yYXJjQ3Q1VCtsSVlIUGF0SUxUV281QU03eUd6 MHA2eGJSbkZXV3FOdnVtbHkyQWo2VTlaL1UwekhGUk1QU2xjUmErMExqclRUT3ZhcWg0RkpSekRz V3ZNVTB4dnZWQjNxUlRsZWFTZHdzSVFTZUtQS2YwTldvaytYZFV1elBwVmN0d0s2bXJFZk5WMHF4 RlRRaWRSVFpGK1UwNWFTWDd2NTFiMkVac24zS2hxYVQ3dFExZzl5a0hlbnJVZmVwRnBEWklCelQ4 VWkwNnJFT1UxS2hxRVZLbFVoRmxCa1ZLRjRxS1BweFU0clVSU3V1aTFSblAzY1ZmdWh3S29Uamhh eW1ORU5QV21VOUt5R1RyVWdGUnBVb3JRUWQ2a0JwbmVuTDFwaUprcXduTlY0NnNKV2lBY1JWU2NZ ay9Dcm5hcWR4L3JQd3B5MkFvWEhFaCtsUmpyVWx6L3JEOUtpWHJYTzl5aVZldFRxS2dYclZoYXBD WklCVGgxcG9wd3Exc0lrVTFNdFFMVTZkcXBBVEFVMWh4U2loK2xhZEJXS012UjZvTWNWZmsrNjFa ei9lcm5tVWg2ODFQR0tnU3JDVWtNbVVWSU9PS1l0UDcxb2lUM3JRVG14aUgrd0tyK0t2K1BXMi82 NkgrVlRhQi93QWVjWCs2S2k4VmY4ZWx0LzEwUDhxeEtPWTFmL2tTOUUvN0M2LytqbnIzT0w3b3J3 dlYvd0RrUzlFLzdDNi8ram5yM1NMN29xUmtuMHBhQlJRQnpQeEQvd0NSRTFML0FMWmYralVyd2l2 ZC9pSC9BTWlKcVgwaS93RFJxVjRSUUFVaHBhVHRRQWRxU2xQU2tvQVNrcGFTZ0JwNlVHZzlLUTBB SlNkNldrNzBBSlRUVGpUVDBvQWFlbElhVTlLUTlLQUVwdE9OTm9BYWUxSWZhbHBLQUcwMm5VMmdC RFRUVHFhYUFHbW1tbkdtbWdCcHBwcHhwcG9BUTAwMDQwMDBBTk5OTk9OTk5BQ0dtbW5HbW1nQnRO Tk9wcG9BYWFTbE5KUUEwMGhwVFNHZ0J0SWFXa05BRFRTVXBwS0FFcHBwMU5OQUNHa3BUU1VBSlNV dEpRQWxJYVdrTkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZG RkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUI2 cDhBditSN3ZmOEFzR3lmK2pZcStpL3hyNTArQVgvSTkzdi9BR0RaUC9Sc1ZmUlZBQzBsTFJRQmkr THYrUk8xbi9yeWwvOEFRYTVPNi81QmVqLzlnNlAvQU5CaXJyUEYzL0ltNnovMTVTLytnMXlkMy95 RE5HLzdCc2YvQUtERlFCUnE1cFgvQUNFb3Z4L2xWUE5YTksvNUNVWDQvd0FxcGlNSDRtLzhneFB4 L3dEUWtyeVpqWHJQeE4vNUJpZmovd0NoSlhreDYxZFBZVEc0NHBoR09LZjJwamRLc1JCSjdWWFkx WWs2VldiTlpzb1FNUlYyRDdocWdQdlZvUS9jb2dEMkwwZjNhZVJ4VElSbGFlZWxkQ0lJV3FKalVy MUMzV29ZeGhwakRpblVoRlNCRXdxdS9yVmg2Z2VvWTBRbk5PalB6RDYwMDA2TDczNDFCUnBRakVn cTRCVktJL3ZCVjRkSzZJN0VER0ZRT2FuYXF6ME1DSmpUZTFLMU43VkFEV0ZSTUttYW9XcUJvaFBV MGxLM1drcVNpYUU5YXZXdUNHK3RVWU85WHJYb2ZyV2xORXNza0RIU29YNHFjOFZCSjByUmlLN0dv eWFlMVJtczJNVDZVdzAvdFRXcVdNaGFrcFc2MGxRTUtrVDd0UjFJbjNhYUF2VzR6R0tsSXFLMkh5 ajYxTVJ6VzhTV1VWRldJcWhGU3FRS2xETEFwSkdHdzB6ek1DbzNrRzNtbTNvS3hVa0h5bW9hc01N cVJWY2dpc21ob1R2VWkwekZPQU5KREpnYWRtb1FhbFdxRVBBcVpCVEZHRnFSU00xUzNFV0U5alVt Y1ZBckFkNlV2NlZwZXdyRWQxMFdxTngycTNLNGJ2bkZWcEZ5QldjdFJvcTFJdEJYMEZLRklQU3M3 RkV5MUlLaEdjMUlwNUFxMEpqNmV2Rk5xVlJWSkVqMHF3blNvRnArNEExb2dKalZTZm1UOEtuWjZy U01DMlIwcFNZRks0SDcwbjJxSWRhc3lvUzJjY1ZEczU2VmkwVXRoeVZZV29GRlNLY1UwREp4VGgx cU5UbXBWR1RWb2tlbzVxWktqVVlwNm1yUUV5MEU4VXdOanZUV2Z0VFRFVnB1VmJGWjVVNXJRYmtH cXpSa2RxeWtpaUpldFR4MUdGUHBVaTVwSkFUcWFlRHpVS2tpcEY1cTBJOTgwQWY2REgvdWlvUEZY L0hyYmY4QVhRL3lxZlFQK1BHTC9kRlFlS3YrUFcyLzY2SCtWWWxITWF2L0FNaVhvbi9ZWEgvbzU2 OTBpKzZLOEwxYi9rU3RFLzdDNC84QVJ6MTdwRjkwVkl5VWRLS1Nsb0E1ajRoLzhpSnFmMGkvOUdw WGhOZTcvRVAvQUpFVFV2OEF0bC82TlN2Q0tBQ2lpa29BS1NsTkpRQWxKUzBsQURhUTBwNlVob0FT azcwdEpRQW5hbW1uVTAwQU5QU2tOT05OTkFDVTJuVTJnQnBwS1UwbEFEYWJUdWNVMmdCS2FhZFRU UUEwMDAwNDAwMEFOTk5OT05OTkFDR21tbkdtbWdCcHBwcHhwcG9BUTAwMDQwMDBBTnBwcDFOTkFE VFNVcHBLQUdta05LYVEwQU5wRFMwaG9BYWFTbE5KUUFsTk5PcHBvQVEwbEthU2dCS1NscEtBRXBE UzBob0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29vb0FLS0tL QUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29vb0FLS0tLQVBWUGdGL3lQ ZDcvQU5nMlQvMGJGWDBYWHpwOEF2OEFrZTczL3NHeWYrallxK2lxQUNsb3pTVUFZM2k3L2tUdFov NjhwZjhBMEUxeVY1L3lETkcvN0J5ZitneFYxdmk3L2tUdFovNjhwZjhBMEUxeU41L3lEZEYvN0J5 ZitneFVBVWF2YVYveUVZdngvbFZISXE3cEovNG1VWDQveXFtSXd2aWIvd0FneFB4LzlDU3ZKalhy UHhNSC9FdFQ4ZjhBMEpLOG9ZY2NWcFQyRTl5T28ycDU2VkN4OUtwZ01mcFZkaFU3WnFNcm5wV2Rn SVFEbXIwR2ZMTlFMR2NkS3NvdTFhY1ZZQzlHZmxHS2MxUVJ1TVlxUXNDSzF1S3d4K3RSTUtsSkJG TUlCNXBNQ0UweHFsY1lGUXVjVklFYkdvWHFWdldvbUZReG9oT2FkR3AzRDYwdXptcFVRN3VCVXBE TGtQRW5OWE04VlFRN1d6VmxYRmJSRTBTTlZkK3BxVXNEVWJVMklnYW0xS1JVUjcxRDBBWXhxSnFj VFREeUtobElpYnJTVTdIdFNiZWFtd3lXRHZWNjFZS0d6NjFUaUczTldJbUM1clNMc0psMG5pb1pL QTRwckVHcnVtS3hDd3FJMU9RS2pjWXpVTUNQdFRXcDNhb21OUXhqRzYwbEtSU2ZXa0FWSW4zYWp4 bXBWWEFvUXk3Ym5FWXFhcWtiZ0ppcGcvRmJKazJNOHlONjBlWXc3MHlpc2JsRW5tTWU1b0JKTk5V VThDbmNDUmV0U2JGYnFLaUZTS2Fva2VzQytsTyt6cWUxT2pOVGdWYVFGUnJjRGpGUmJTcHJRSzVx bEtNT2NVcEt3RVR5OXFaNXpEdlViZmVOSU9LeXVNbUVyK3RPOHhqM05STFVxaXFUQWNuWHZVeVZH QmluS2FwQ0pSRWhwd2dUMHBxbXAwRlVrSVo1QzRxSjRkcHlCeFYwQ281bHdoSXB0QVUrMU1lZHUx UFA5S3BzOVp0MktKeE8zclRoSythcktlYWxYclNUQWwzc2U5U0owOXFqVVZLdFVoRWlnRmNIb2Fj SVVOUnJVcW1yc0FvaFQwcGZKWDBxVkJUOGNWWEtKc3B0RUY1cHBmWU0xWmxHRXFoY3RoUjlhbVdn Q200YjFwUFBZOTZyWnpUMXJPNHl3Sm45YWNHWnV0UnFLbVVZcTB3SHIycVhhRDJxSVU5VFZDSGlK UFNsOGxNOUtjdFNDcVNBaE1JcUlydEpGWFN0VnBSaDZHdEJJOTIwRC9qeGkvM1JVSGl2L2oxdHYr dWgvbFUrZ2Y4QUhqSC9BTG9xRHhYeGEyMlArZWgvbFhNV2N4cTMvSWw2Si8yRngvNlBldmRJdnVD dkM5Vy81RXJSUCt3dVAvUjcxN25GOXdWSXlYbWlpaWdEbWZpSC93QWlKcVgvQUd5LzlHcFhoTmU3 ZkVQL0FKRVRVdjhBdGwvNk5TdkNhQUNrTkxTR2dCTzFKU25wUjJvQVNrcGFiUUFoNlVocFQwcEtB RXBLV2tvQWFlbEllbEwycERRQWhwcHB4cHBvQVNtMDZtMEFOTklhV2tOQURhYlRxYlFBaHBwcDFO TkFEVFRUVGpUVFFBMDAwMDQwMDBBSWFhYWNhYWFBR21tbW5HbW1nQkRUVFRqVFRRQTJtbW5VMDBB Tk5KU21rb0FhYVEwcHBEUUEya05MU0dnQnBwS1UwbEFDVTAwNm1tZ0JEU1VwcEtBRXBLV2tvQVNr TkxTR2dBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29v b0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29vb0E5VStBWC9J OTN2L1lOay84QVJzVmZSZkZmT253Qy93Q1I3dmYrd2JKLzZOaXI2TG9BTVVtS0tYclFCaStMditS TzFuL3J5bC85Qk5jamUvOEFJTjBYL3NISi93Q2d4VjEzaTcva1R0Wi82OHBmL1FhNUMrLzVCdWlm OWc5UC9RWXFBS0ZYdEkvNUNVWDQvd0FxbzFlMGova0p4ZmovQUNOVXhHRDhVbTI2U3Avejk5Szhp V1lrNEo2MTZ6OFZ1TkVIK2Y0MHJ4eEcrWVZVSFlHWGdNbkZQU0ZSMUZKSHl5MVp4V3FSUFVoOGxP NHBwaVFkcXNIcFVUMVZnSTlpZzVGTWJyVG1OTU5TQkVTVmZJT0tiNXJqaW5zS2ljVkZ4aUdkd2V0 SjU3WjYxRTFSL25VM0dYMWszOFpweXg3K3g0cXRibkwxZnQxNjFjZFJBSUZJNUZKNUNlbFdkdUtq ZjJxckNLNWhRZHFSbFZSeFQyTlJzYWtDTnVsUjdtWHZVaHFOcWxzWTB6T0IxTk44OXZXa1lWQ2Fp NHl5azVIVTFKbmNNMVNCd0t0eEhLS2FwTzRXSmtnR2NucFQvSVgwcWRFTzBVcEF4V2xoRlV3SlRm TFZlMVRQVURFMUxRRFh4NlZFL2FwQ2FZM0lxUVF3eU9QV21lYTNUTk9hb21xV3loL212NjA5WkMz RlFVNlA3NHBKZ1Q0N1ZJa0FIVWNVd0Q1aFYxVjZWb2xja2c4bGZTbW1KTWRLdE1LZ2M5YWJRRU93 TFRHKzlUMk5NeFVzWkd4eHlPdElIYjFwekNveU9hbGpFcE85TFJVZ1BXbmdlbE1XcEJWSVRGRk9Y clRhZXRVaEU4WGFySzFXaTZpcksxb2hEbSs3V2ZNZm5OWHowNHFoS1BuTktZMFUyNm1rcFcrOGFT c0h1TWVncWRhaFRwVXExU0FmU2lrQnB5MVMzRVNKMXhWbEtyTDFxeEhWb1JPdUtqbis0MzBxUmFq bis0MzBxK2dGSEZVbTYxZDdWUmJyV0VpaHlWTW5Xb1VxWmV0SkFUTFR4MXBpMC92V2lKRkhXcFVx SWRhbFNxQXNKMHFVVkVuU3BSV2lFeUdiN2xaOXdQbEdhMEp4aEt6N2o3Z3JPWXluM3FaRHpVTlNv TUdzVVVXVUZTZ1ZFbFNpdFVTeHc2MDVldE43MDRkYW9DVkttV29rcVZhdEFQNHhWV1g3OVdUeFZh WDc0cE1SN3Q0Zi93Q1BHUDhBM1JVSGl6L2oxdGYrdWgvbFUvaC8vanhqL3dCMFZCNHQvd0NQUzIv NjZIK1ZjeFp6R3EvOGlUb24vWVhIL285Njl6aSs0SzhNMVgva1NkRC9BT3d1UC9SNzE3cEY5d1ZJ eVNpaWlnRG1maUgvQU1pSnFYMGkvd0RScVY0VFh1M3hELzVFVFV2KzJYL28xSzhKb0FLVHRTNHBE UUFHa29QU2tvQUtTbHBLQUducFNHbHBLQUVwS1drb0FUdFRUVHFhYUFFTk5OS2VsSWFBRzlxU25I cFRhQUdta05LYVNnQnROcDFOb0FTbW1uVTAwQU5OTk5PTk5OQURUVFRUalRUUUFocHBweHBwb0Fh YWFhY2FhYUFFTk5OT05OTkFEYWFhZFRUUUEwMGxLYVNnQnBwRFNta05BRGFRMHRJYUFHbWtwVFNV QUpUVFRxYWFBRU5KU21rb0FTa3BhU2dCS1EwdElhQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29v QUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lp aWdBb29vb0FLS0tLQUNpaWlnRDFYNEJmOEFJOTN2L1lNay93RFJzVmZST0srZGZnRi95UGQ5L3dC ZzJULzBiRlgwVm1nQXBhUVVkS0FNYnhkL3lKMnMvd0RYbEwvNkRYSDZoL3lEOUQvN0I2ZitnUlYy SGk3L0FKRTdXZjhBcnlsLzlCcmp0Ui81QitoZjlnOWYvUUlxQUtPY2NWZDBjNTFTTDhmNUdxUFNy MmovQVBJVWkvSCtWVTloSFA4QXhYLzVBWS9IL3dCRFN2R29oOHdyMkg0c1NLTkpSQ2NNd09CL3dO SzhlaVB6Q2lJV05LUDd5MWJISXpWT1A3d3E0dkF4WFRIWWxpR29IcWRxZ2Z2UXdJalRlMU9OTnFH QTFxaGVwbXFGNmtaWGVvajFxVjZoNzFtTkZxMis5V2hiOTZ6N2I3MWFGdjNyU0FtV1R4VUwxS2Fp ZnBXckVRTjFxSTFLL1dvaldiQWJUV3AvYW8ycVdNaGVvVzYxTTlRc09helkwSUt1UmZkRlV4NzFj aSs2S3FJTTBZK2xLMUpIMEZLMWJyWWtydjBxQnFuazRxQnF6WUREU2RxRFFlbFNORVRkYWlhcFdx SnFoakVwMGYzeFRhZEg5OFVoc3NmeEN0Q1BwV2YvQUJDcjZkSzNnU0kzZXF6L0FFcXkxVjNvWUVE VWxLMUoyck1ZMXVsUm5yVWpWSFNBYUtLZjVKUGFsOGh2U2xZWTFlbFBCbzhsaDJwTnBCcHBDWktL ZW9wZzR3VFQvTVZhb1JNbkZUS2FxQ2RhZDlvV3FVZ3NXaTJPbFU1U1M3R2xhZlBRMHpKYm1sSjNB cXNPVHhTZDZzdERrWkE2MHp5R05SeWpHTFVpbWxFRCtsTDVMK2xPd0RsNXFSZWxSSXBGU29RT3RV a0lrVWMxWVQ2MVY4NVJUMXVGcWtGaTNtbzVXSmphb1RjRDhLamFiZHdPbFBtQWJWTmw1TlhCU05C L2RxR3JnaW9veFVxbW4vWnoycHdnWWRxbXd3VnVha0hXbUNGeDJwNkRIV3FRaVJSbXBFOTZqVmdC enhUaE1vTldyQVdWcVRJcW9MaGFYN1FLcm1RckVrcHlsVWJnWlVacVpwZHhJN1VtemZVUzFBb0Zj R25wVmcyeG8rek42VkNpTzQxVFVxbWtGdTlMc2RUMHEwbUlreHpUMUZNWGpyVW5tS3ZlcVFFcWpG U0NxM25ybnJUaGNMVkpnV0MxVjVUbGhTTk9PMU0zRnVhRzdoWTk3OFBEL1FZdjkwVkI0dUgraTIz L0FGMFA4cXMrSDEyMlVZNzdSVmJ4Zi94NjJ2OEExMFA4cTVpamw5Vi81RW5RL3dEc0xqLzBlOWU2 UmZjRmVGNnIvd0FpVG9mL0FHRjEvd0RSNzE3bkY5MFZJeVdpaWlnRG1maUgvd0FpTHFYL0FHeS85 R3BYaFdLOTM4ZmpQZ2ZVaC8xeS93RFJxVjRkNWRCU1Z5REJveFZqeS9Ta01kSzQrVXJrVW1PS3Nt T2s4dWk0Y3BXd2FNR3AvTG84dWk0Y3BXSXBDRFZqWlNGS0xpNVN2ZzBtRFU1U21GYWR3NVNIRk5O VEZhWVJTRllqTk5OUElwcDZVeERPMUpUalRhQUdta3BUU1VBTnB0T3B0QURUMHBEVHFhYUFHbW1t blUwMEFOTk5weHBwb0FRMDAwNDAwMEFOTk5OT05OTkFDR21tbkdtbWdCdE5OT3Bwb0FhYVNsTkpR QTAwaHBUU0dnQnRJYVdrTkFEVFNZcVRHYUF0SzRFV0tUYWFuQ1U0UjB1WWRpcnROSnROWEJGU2lL bHpqc1V0aHBOalZmRUZIa2UxTDJnY3BuN0dvS042VmY4QUlvTUh0UzlvSEtaK3crbEd3K2xhSGtl eG84ajJOSHRFSEtaK3crbEd3K2xhSGtleG84ajJvOW9IS1oreHFOamVsYUhrVWhocCswRGxNL2Fh TnBxK1lhWVlxT2NPVXA3VFJnMVpNZUthVXF1WVZpREZKVXBXbWxhZHdzTW9wU0tTbUlLS0tLQUNp aWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9wY1Vv Rk93SHFYd0QvNUhxOS83QnNuL28yS3ZvcXZuYjRCakhqbTkvN0Jzbi9vMkt2b21rQVVVVVVBWTNp Ny9rVHRaLzY4cGY4QTBFMXh1cEgvQUVEUWYrd2V2L29FVmRsNHUvNUU3V2YrdktYL0FOQk5jWHFm L0hqb0gvWGd2L29FVkFGS3J1a2NhbkYvd0wrVlVxdWFWL3lFNHY4QWdYOHFwN0NPSStMVjBKTHVH MlZ4dWpVWlgvZXlmL1pSK2RlYkluekN1eDhmTTkxNG1ueU9GYzdUN2NML0FPeS9yWE5MQmc4MVVZ NkFQUTRZVmF6NzFVenRPYWNrL0hOYlJkaVN5VHhVVFV6N1F0SVoxOWFHRmdhb3pUL01ROFpwaCs5 VXNaR3h4VVRtcFdRczNGSVlHSXFXbUlxTU0wMExWcjdPM3BRYllqRlR5akk3Y0FQbXRDQnUxVnhF RXBSTHNOWEhRQzdtbXQwcUQ3UUJTZmFGcStZVmhXRlJrWkZLWmw5YU53WWNHb2JHUkhwaW8ycVJo bnBUQkV6ZHFtd0VMVkVSelZvMjdlbE4rek42VlBLTXJiZUt0eERDQ2hZQ0R5S2RqYmtVMGdMcU44 b3B6R3FTelk0UFFVLzdRSzBURlprcmpJcUJoU21kVFRQTlVuRlMyRmhqVTFxa1lqdFVUQWtpcFlK RWJWRWVhc2VTeDdVMHdONlZOaWlFVTVPSEZTQzNhbkxGdDVQV2l3RGdmbTRxNnI4RE5VYWVrM3Iy cTA3RWx3bW9IRk1OeUtRenFhYllXR3RVWnFUekZQY1V4dXRRTVlUVE0wNHFTZUtQSmIwcEFXQWVh bVVWWFhyVmlQbXJRaCt3WXFONC9sNXF3b3BKUUFwK2xWWURPWTRXb09hbWs0V29heVkwRk9XbTA5 YVNHT0M4OUtsSFRGTkFwMk9hcENaSXRUTHlhcnFhbVNxUWljQ2xhUGpJNHBVNUZTQVpGYUN1VXAx QzR4eFZXVTRIV3J0MTBHS296OXF6bVVSWnB3NXFPbnJXYVl5VlJVaWptbXJVaWlyUkxGcVpUVVhl bnJWSVJPcHFRRE5RcFZoS3RBeHJKVmVSUUhIYXJtS3FYSCtzL0NoZ1ZKV3crTzFRN3VhZGNjU242 VkVPdFlObEV3NjVxUWMxRWxUcUtwQ0hvT2VsVExnSGlvMXA0NjFhRVNnMUt0UUtlYW1TckFmdHBw VHJVZ0ZCR0IwcXJDS0xjQW1xclBWdWJvMVp4T0RXRWlrU0syVFVnNjFDdFR4MElaSUZxVlJnVTFS VHh4V2lFZlFPZ3Ivb01SN2xSVlB4Zi94NjJ2OEExMFA4cXU2Ri93QWVFUDhBdUQrVlVmRi8vSHBh L3dEWFEveXJBWnkrcS84QUlrNkgvd0JoY2Y4QW85Njl6aSs0SzhNMVgva1NkRC83QzYvK2ozcjNP TDdncVJrbEtLU2xvQTUzeDRNK0N0UkgvWFAvQU5HcFhpdmwxN2Q0MFhmNFJ2MS82NS8rakZyeUlX M3RXYzNablJTaHpSTS95NlF4MXBmWnFRMjFUekkxOWtadmwwbXl0UDdMN1VmWnZham1EMlJsN0tU eXpXcDlsOXFQc250UnpEOWl6S01mdFRTbGEvMlQycGpXbnRTNXc5aXpJS1ZHVXJXYTE5cWlhMjlx YWtRNlRNcGxxTmx4MnJTZTNxRjRLcFNNM0JtZVJUR0ZYR2hxRjQ4VlZ5SEVxbnBTVk1Vd0tZVnBr V0lxU25rVXcweERhYjNwMU5vQVEwdzArbUdnQkRUVFRqVFRRQTAwMDA0MDAwQUlhYWFjYWFhQUdt bW1uR21tZ0JEVFRUalRUUUEybW1uVTAwQU5OSlNta29BYWFRMC9iUnRwQVIwaEZUaU9wQkRudFNj aDJLd0ZPVmF1TGJWT2xwbnRXVXFpUlNpWjZwVWdqOXEwMHN2YXJDV0dlMVl5cm9wUU1rUkgwcDRp OXEyMDAvMnFWZE4vMmF4ZUlSYXBtRXNIdFR2STlxMzEwMy9acVFhYi9zMW04U2l2WnM1c1cvdFI5 bjlxNlVhYi9zMHY5bWY3TlQ5WlEvWm5NK1I3VWZaL2F1bS9zei9acGY3TC93Qm1sOVpRZXpaelAy ZjJwUHMvdFhVRFMvOEFacHcwbi9abyt0SWZzbWNxYmYycHB0L2F1dE9rL3dDelREcFArelFzVWc5 a3prekI3VkUwUHRYV3RwWEgzYXJTYVhqK0d0STRsRXVtemxXaTlxaWFPdWxrMDdIOE5WSkxESGF0 NDEwUTZaZ010UkZjVnRTV2VPMVZYdGNkcTNqVlJtNG1ZUlRhdk5CaW9HaXhXcWtpYkZlaXBTbUtZ UmlxdUliUlJpaW1BVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRk9Bb0Fi UzA0TFQxanFsRVZ5T25BVk1zVlNyRG1yVk5rT2FQU2ZnS0NQSEY3LzJEWlA4QTBiRlgwTitkZUFm QXlMWjQwdkQvQU5RNS93RDBaSFh2OVRPTm1WQjNRVVVmalJVRkdONHUvd0NSTzFuL0FLOHBmL1FU WEZhcHhaZUgvd0Ryd1gvMENPdTE4WGY4aWRyUC9YbEwvd0NnbXVKMWIvano4UGY5ZUMvK2k0NkFL V1Q3VkhOcXE2TW4yOTRtbFdQK0JlQ2M4VS9OV3RPUlpOUWpWbERLUTNCSEhTcVlqeXZYTC84QXRE VXBMblk4ZThzZGo5Vnl4UFA1MWxNMWJQaWxRbmlDN3h3TjdjZmlSL1NzUTF1dGlSaDVxSmhVMU1Z WXBBVjI5S2lKeFV6MVdhb2JLSHErS3R4dHVTczhIdFY2QVlqb2d4TXVSb050UDI0RkxIamFPS2Nh MlNKSWlLakp4VWoxQXhxV01heHFKaG1wRFRUVU1aQXd3S2lQU3AycUJ6aXBZRGQyS2VqbmR4VUI1 cHlaM0Q2MU45Um1naWdzS3NoY0hwVUVQRWxYTWNWdEhZa2pJeFVUR3BtRlFQVFlER2FvalRtcHRR QkV3RlJzTUNwbUZSTUtobEVST0tBMUlldEoycVJrOFJMWnF6Q21jOFZWZy9pcS9iRElQMXJTQW1T Yk1DbU53S25JcUZ4Z1ZvMFNSRTFFeDROT1kxR1RXYkdONXFNakZTZHFZYWtaRWFTbk5UYWdZZDZs VTVYbnJVVlNKOTJtZ1paalRLNXhVd1Rpa3QrWXhVMlBhdGtpU2l2V3JFVlFLS25qNHBJQ3d0Tm0r NytGQTRwc2hHMDFYUVJueWZkTlExTTQrU29hd1pTRTcxSXRSOTZrVTBoa3dwYVl0T0hXckVQRlNw VWExS25XcVFpekgwcVZhaFUxSmtBVm90aEZhNjdWUW42Q3I5eWVGcWhPT0ZyT1pSRFQwNlV5bnBX WXlkS2xGUkxVZ3FpV0wzcHk5YWIzcVJhdENKWTZzSlVDQ3BsTmFJQ1R0Vk80L3dCWitGVzg0RlZM am1UOEtKQVVibi9XRWUxUXIxcVdjWmtQMHFJREJyblpSS25CcXd0VjA2MU9wcWtKa29wd3BnelR3 S3RDSHIxcWRLZ1dwMHEwQktLVitsTkZESGlxNkNLVXZScXpuKzlXakx5clZua1ZoTW9jbFdJeFZk ZXRUcFFnTEMwNm8xcVFHckVmUVdoZjhlRVArNFA1VlI4WWY4ZWxyLzEwUDhxdmFGL3g0US83Zy9s Vkh4ai9BTWVsci8xMFA4cXhLT1cxWC9rU2RELzdDNC85SHZYdWtYM1I5SzhMMVQva1NORC9BT3d1 UC9SNzE3cEY5d1ZJeVNscEtXZ0RHOFZydjhNM2krb1Qvd0JEV3ZOQmIrMWVuZUpqdDhPM1pQOEFz ZjhBb2ExNTM1cTk4VnpWbjd4NmVDaW5CMzdsYjdON1VuMmJzQlZ2emw5cVBOV3NiczdPU0pVK3pV djJiMnEwSlZwd2xXbGRqVUlsVDdMN1VvdGZhcm9rV25obE5MbVphcHhLSDJUMnFON1QycldETDZV eDhHbHpzcjJVVEdhMTlxcnZiZTFiYklPMVY1SS9hcVV6TjBVWVVsdngwcXJKQmp0VzVKRDdWVWtn clJTT2VkSXhYaXhWYVNQRmJFbHY3VlZrdHpXaWtjMHFSa3NsUU91SzBwTGZGVlpJU00xb3BHRXFi S1JGUmtWWWFLb21URlVZdUpDYWJUeXVLWVJpcUlFTk5OT3Bwb0FhYWFhY2FhYUFHbW1tbkdtbWdC RFRUVGpUVFFBMDAybkdtbWdCRFRUVGpUVFFBMm1tblVZb0FZYVFVL1lhVlk4MHJnTkFwd1dwbGdK cWRMUW1zcFRTS1NJbzRxc3BEbXJFTm1mU3RDS3dKN1Z5MUt5UnBHSlNpdHMxY2l0TTlxdncyQkhh cjhObmp0WEZVeEJ0R21aOFZsN1ZjaXNNOXEwb3JYQTZWYmppQzQ0cmhuaUdiS21aMFduKzFUcnAz dFdySHRIYXBsa1FkaFhOS3ZJMVVFWlM2ZDdWS05OLzJhMUZuUWRoVHhkUitnckoxWmw4aU1rYWIy MjA0YWJuK0d0VVhjZm9LY0x5UDBGVDdXWStTSmxEVFA4QVpwdzB6L1pyVkYzSDZDcEJkUitncVhW bVBraVpLNlhuK0dwVjByL1pyWWp1WXoyRldJNTR6L0NLemRlWlNoRXdqcFArelViYVQvczExSG1J UjkwVTBsRDJGUjlZbVY3TkhLUHBYSDNhb3phWmorR3UxWkVLL2RGVVo0Vk9mbHJXbmlaRU9ramg1 dE94L0RXZk5ZWTdWMjg5cUQyck1uc3V2RmQxUEVzeGxTT0ttczhkcXo1YlhIYXV5bnNNOXF6SjlP UFBGZDlQRW5QS2tjbExiNDdWU2xpeFhUejJCSGFzMmV4UHBYZlRySm1Fb0dFNllxQmxyV2x0Q0tw eVFFVjF3cUptVFJSSXBLbWFJaW95bUszVEpzTW9wU01VbE1RVVVVVUFGRkZGQUJSUlJRQVVVVVVB RkZGRkFCUlJUZ0tBRTcwOVJtZ0ptcDBpcTR4WkxZMVZ6VXlSMUpIQWF0UjJ4cnBoU2JNSlZDRklx c0pEVmlPMnF6SGJWMTA2QnpUcW5kL0JhTFo0dXV6ei93QWVELzhBb3lPdmM2OFkrRU1ZVHhWZGY5 ZVQvd0RvYVY3UFhGaTQ4dFN4MTRkM2hjS0tLSzVUY3h2RjMvSW5hei8xNVMvK2dtdUgxZml6OE8v OWVDLytpNDY3ZnhkL3lKdXMvd0RYbEwvNkNhNGZXUDhBajA4T2Y5ZUEvd0RSY2RBRk9ybWxmOGhT TDZOL0kxUnE3cFAvQUNGSXZvMzhxcGlQTVBGbkhpQzYvd0I5di9RbXJDSnJmOFdEL2lvTHIvZmIv d0JDYXNJaXQxc2llb3ltUFQrMVJ0U0FoZnBWWnV0V1hxdXdyS1EwUmpyV2hEOXlxSVhtcnNBeEhW UkdYNFI4dFBQU214dDhncHg2VnNpU0Y2aGFwM0ZRc0trQ0trTk9OTWFwWURHcXRJS3NNYWdmcFdi R2lFMDZQN3crdElSVG8xSVlWUFVab3hmNndWZEhTcVVKQWs1cTJHcm9oc1NJM1NxejFZYmpOUU5R d0lHcHZhcEdwbFF4aldxRnVsU3NhaGVvQkVUZGFTbGJxYVFWQlJMQjFOWDdYK0w2MVJnNzFldFd3 R3JXQkxMUnFCK25lcFNjMUMzU3RHSXJ2VVpxVmhVUkZac1luYW10VHNVeHFrWkcxTnBUU1ZBQlVp ZmRxT3BFKzdUUTJYcmI3cS9XcDZndDJBakZUWnJaYkVzcGdpcEE0SGVxRzVpYU56Vm5jZGpSRW94 MXFONXVNVlRER2xHYzBjd05FcEdRYWhLRVZPcHFVQlNlbEZyZ2lsdE5PQ24wcThzWVBhbmlKU2VC VDVBS0F6VWdxeThJTlFGZHJZelJZQ1JlQnpUd3dxbTBwd1Y3VXplZldqbXNGalREcU80cFRJTWRh ekE3RTlhZUdZMCtZVml6Skp2NmRLaGROd3BFRlRSOFp6UnVCVThyMm9Da0hvYTBBcW1uaU5QU2hR QzVRR2FrWE9SVjN5VngwcUo0Z3VXRlBrc0Z5TWRhbUF3T2FnUFhJcUpwbUlwWHNCZkRLTzlQRWdI ZXNyelc5YWVIYnVhZk1GalNhWVk2MVhadDdacXZrbXBFSHkwNzNBWkpGazdoVVhsSFBTcnlmZHhU MVJmU2x5M0M1UUNFZHFlQTFhQWpYMHBmS1VkcWZJQlRRMUt2V25ORUZ5YWhkeWd6UnNCWkJBcHdZ Vm5OTWZXanpHUFVtaFNDeHFlWUJUR2xBRlVBN0h2VHdTYWZOY1JLZm1GUVBDUjBGV0ZxVVlQVVVX dUJRRWJEc2FlcW5waXI0VmM5S1h5eG5wVDVBS1FCRlNMVmxvbElxRXJ0YW5hd0gwRG9RLzRsOFA4 QXVEK1ZVZkdIL0hwYS93RFhRL3lxL29JenA4UCs0S29lTVJpMHRmOEFybzM4cTVpamx0Vi81RW5R L3dEc0xqLzBlOWU2UmZkRmVGNm9QK0tJMFA4QTdDNC85SHZYdWNYM1FLUXlXbHBLS0FNWHhjZHZo YTlQL1hQL0FORFd2TFRjWTcxNmQ0MmJiNFF2ei8xei93RFJpMTQ2MHhyR3BHN096RHo1WW1wOW85 LzFwUHRIdldYNXhvODQ0cU9VMzlxYXd1UGVwRm45Nnhsbk5USk5VOGhVYXByck5VNlMxanBONzFh amw5Nmh4TjRWRFVSODAvTlVZNVI2MVlWd2U5WnRIVkdWeVhHYWF5VTlTRFVtQWFnMVN1VW1pelVM d1ZwR01HbW1JWXA4d3ZabU85djdWV2UycmNhRVZDMElxbE15ZEU1NlcyeDJxakxBZWE2T2VBZHF6 WjRPdGF4bWN0U2lZTWtXS3FTUjRyWW1oeFZHV1BHYTJqSTRwMDdHWTZrVkVSVnFWTVZYS2tWcW1j aldwRVJURFVqQ296Vkltd2hwcHAxTk5BaHBwcHB4cHBvQVEwMDA0MDJnQnBwdE9OTk5BQ0dtMDQw bUtBRzA0Q2pGUFJDYWxzQVZNMU5GRmswNUlpZTFYTGUzWW5wV0U1MkxTRmh0ODQ0cS9EYVo3VlBi V3BPT0sxN2F6emppdk9xMTdHOElGUzNzYzQ0clV0OVB6ajVhMExXekhIRmJGdFpweFhsVnNUWTZv VWpHVFQ4ZHFuU3l4MnJmTnFncHBoakhldUo0aHMzOW1ZLzJiYXZTbzJUYld0SXNZWHJXYmNPZ3p6 VGhKeUUxWXJNKzJvV3VNZDZqdUoxWCtLczZhNUhyWFZDbmN6Y2krMTNqdlVSdnZlc1dhN3gzcW05 NmZXdWlPR3VaKzBPbE9vZjdWTi90SC9hcmwydlQ2MHo3Y2M5YTArcWk5cWRldW9mN1ZUTHFIKzFY SHBmSDFxZEw0OGMxbkxDalZRN1NHK3ozcS9EZWU5Y1hiM3Z2V25iM3ZUbXVTcGh6V05RNjVMbkk2 MVpTWFBldWNndXdmNHExTGU0VTQrYXVHZEt4dkdWeldVNUZOYVBOTmhrVWpyVmxkaDcxeXU2TlZx VW10czlxclMyZWUxYnF4cWFVMjZHaFZyQnlIS3lXR2Y0YXBUNmJ4OTJ1ek5xaHF2TlpKdHJhR0th SWRJOC91ZE94bmlzaTUwL0dlSzlBdWJKZWF4cnF5SFBGZWpSeFJ6enBIQlhObmpQRlpOeGJZSjRy dHJ5enhuaXNDOHRTTThWNjlDdmM1SjA3SEx2RlZaMHhXeE5ic004VlFtaUk3VjZsT2R6bmFNNWh6 VGNWTTZuTlJsYTZFek93eWlsSXhTVlFnb29vb0FLS0tLQUNpaWlnQW9vcGFBRkFxVlZwaURtck1j Wk5hUVZ5Sk1FanpWMkdITk1paU9SeFduYndWMjBhVjJjdFNvSkRiWjdWZGp0ZmFyTnZiOUt2cGJp dldwWWZRNEoxaWhIYSsxV0Z0c0RwVjlJRnFieWxDMTJRdzZSelNxczZYNFZ4N1BFMXljZjh1YmYr aHBYcnRlVi9EUlF2aVc0eC93QStqZjhBb2FWNnBYenVaeHRYdDVIczRGM3BCUlJSWG5IWVkzaTcv a1R0Wi82OHBmOEEwRTF3MnM4V25odi9BSzhCL3dDaTQ2N254ZC95SjJzLzllVXYvb0pyaGRhLzQ5 UERYL1hpUC9SY2RBRkd0RFExM2F2Q1BadjVWbjlxMC9EM090US9SdjVVd1BPdkdOaXlhbmRYVzhi ZlBlUGIvd0FDei83TlhMa2NWM254RUczVEpHSFg3ZkwvQURGZWNKTWNZT2EyaTlDYkVwNzFFY21w d054eFVxeEtPMVZhNGpQS01lMU1NWlBhdFV4cU8xTUtMNlV1UURPV0hKNkdyQ3J0R0tuSUFGUnRT NWJESG8rQmpOU2VZQ090VW40YW95N0FVYzFoV05Bc1BXbUVqSFdzOHl0NjBnbE9lcG81aDJMcjlP S2hjMEpLWDYxS2tlODVvM0Fxa0U5cVl5TjZWcGlJWTZVaGpYMEZISUJsK1dUMnFSSWoxcThVVWRx WTJNR2x5MkFqVnRwOWhVNnlBOTZyTjBxSWtqdlFuWURRTGoxcU1zdnJWRXlNTzlNTXJZNjBPWVdM eEFOUk4xTlYxbUk3MU1EdUdhVjdoWVlhWXdPS3VwQ0JodTlQTUsrbEhMY0RMMkU5cUJIejByU01h QWRLWVZBcE9BeXNxN090VFJ5Yk9uZWtmMHFKcU5nTG9rSHJUUzZrOWFvRW4xcHBrSTZHbnpoWXZF Zzk2allEYWFxZVkzclVpU0UvTFM1Z0htb2ljOUtsSXFaSVI2VVd1SW9rSDBwTUgwclNNUUhhbWxG OUtPUWFLQVVudFVnWGF0VGtLS2piclN0WVkrT1RBeFVvbHdPdFVtNjBtNXFWeERhS0tUdlVqSHFL a0FwaTFJS3BDWW82MUlEVVkvR25yVFFFOGRXRkZWNHFzcldxRUJYcVJWS1VZY2lyemZkcWhMOTQw cGdpbTMzalNmV2xiN3hwS3dLdVBXcFZITlJKMHFaYXBDWThjVTVldE54U3JWQ0psTldFNXFzbldy TWZXdElzUklCVEpWeEczMHFVZEtpbi93Qlcvd0JLcDdBVXowcWlUelYzMStsVVdyQ1JTSEwxcVZC VVNWTXRDQWxVVkl0TVVVOGRhdENIclVpR29oMXFST3RVSXNMVW1LalRwVWdyUkF5S1lZU3FGd2NJ S3Z6ZmNxaE9QM1lyT1lJcWJxa1Rtb3FrU3NTaWRNVk1CVVNkS21BclZFamhUMU5NNzA0ZGFwQVRL YzgxS0tpU3BWcTBBNGlxMG93OVdqMHpWV1g3OUppUjlBYUIvd0FnK0gvY0ZVUEdmL0hwYWY4QVhR L3lxL29QL0lQaC93QndWUThabi9STFgvcm9mNVZ5bG5LNnAveUpHaC85aGNmK2ozcjNPTDdvcnd6 VS93RGtSOUQvQU93dVAvUjcxN25GOXdVaGt0RkZGQUhPK096andYcUo5by8vQUVhdGVLbVN2YVBp QWNlQjlTUC9BRnkvOUdwWGhubWU5UzBhUmxaRnJmUVhxcnY5NkM5TGxIekZvU1ZJc3Z2VkR6TVV2 bSs5SEtVcG1rczFXSTU2eGhOVXlUKzlRNEdrS3B1UjNIdlZxT2YzckFTNDk2dVF6NXh6V1VvSFZU ckcvRkxudlZsWDRySGdsNmMxZmplc0pJOUNuTzVjRFpwMVFJMVRqcFdiT21Jd2ltTU0xS1JUU3RL NDdGT1ZLb3l4WnpXczZacXM4VlVwV01wMDdtSE5CVkNhSHJYUXpRY1ZuVHdWdEdaeVZLUnowME5W SGp4VzFQQ2VhejVZOGMxMFJrZWZVcDJNMTF4VUJGWEpWcXFSV3FPU1NJalRUVDJGTU5VWmpUVFRU alRhQUdta3BUL1drb0FhYWFhY2FhYUFFNzA0TFRlOVRJTTBteDJFVkt0d1E1cHFKV2xhUTV4WE5V cVdSY1lpd1d1Y2NWcDIxanowcWUwdGM0NHJjdGJMcHhYazE4Ulk2WVU3bFcyc3VuRmJOdFpjZEt0 VzFsMDRyWXQ3TDVlbGVQWHhKMXdwbWJGYmJlMVhJazIxYU52dHFKbDIxeHVwekdxallqbWt4V2ZO YzQ3MU5keWJjMWczbHp0enpXOUduekV5bFludUwzQTYxajNOL3dCZWFwWGQ5akl6V0xkWDN2WHFV Y0tjczZwZnViLy9BR3F6NUw0SCtLc2E1djhBM3FtMTdudlhxVThMb2M3cW14SmQ1NzFYYTU5Nnlt dTg5NmlOejcxMExEMkk1elZOeDcwMDNIUFdzcjdUNzBodVBlcjlpTG5ObGJuM3FSYnIzckMrMCs5 T0YxNzFMb0RVenA0YnpIZXRDRy94M3Jqbzd6SGVyS1grUDRxNTU0VzVhcUhkVzJvYy9lcll0Yi9w elhuZHJxSHpmZXJkczcvT09hOCt2aExHOEtwNkJiWHVSMXJUaHVjOTY0cTB2YzQ1cmJ0Ym5PT2E4 ZXRoN0hYQ1oxY00yZTlXUTFZOXJMbkZhS1Btdk5xUXN6cGk3bGtHbXlMbGFFTlNZeXRZN0ZtYk5E bnRXZFBhNUI0cmZhTE5RUGE1SFN0NFZiRU9GempMeXo2OFZnM2xsMTRydnJxejY4VmlYVmtlY0N2 VG9ZZzVxbE00QzVzc1o0ckl1YmJHZUs3bTlzc1o0cm5yMjJ4bml2YXcrSXVjZFNtY2pOQ1ExVm1U RmJGekRoaldmS21PMWV0VG5jNVpSS0RqRk5xYVVZcUd1bE15RW9wVFNVd0NpaWlnQW9vb29BY0JU d3ROVVZPaTFwRkV0aXhSNU5hRU1HYWhnankxYTl0RG5GZHRDbGM1YXM3QkRiZTFhTUZ2anRVMXZi WkhTcnNkdml2WW80ZXg1MVNyY2JCRmpGV2dtS2ZIRmlwR1RGZWhDRmtja3BYWkVPS0hmQzBOeFZh WjhMMW9sS3lCUnVkcDhNSDNlS0xrZjlPYmYraHBYck5lTy9DaDkzaTI2SC9Uay84QTZHbGV4Vjhy bU11YXUyZTlnMWFrRkZGRmNCMUdMNHUvNUU3V2YrdktYLzBFMXd1dC93REhyNGEvNjhSLzZLanJ1 L0Z2L0luYXovMTVTLzhBb0pyZzljLzQ5L0RIL1hqL0FPMG82QUtWYW5oMy9rTncvUnYvQUVFMWwx cWVIZjhBa053L1J2OEEwRTFURWNkOFNPTkhtLzYvNWY4QTBJVjVmRy96RGl2VVBpUi95QnB2K3Y4 QWwvOEFRaFhsMFAzcUVETktQN3kxYkMxVGorOEt1cjByb2pzU01ZVkU5VE5VRDB3STJOTXB4cHRR QXhoVUxpcDJxRjZsanVWMk5NNzA5cWpKeFdiR1dMYy9QV2hBT3RaOXQ5N1B0ViszclNBbVdDS1kv RlNHb25yVVJDNXFJbXBIcUkxbXdHbnBVYkNwTzFNYXBHUXNNVkVhbGVvVzYxbXhvVE9LdVJmZFdx YSs5WFk4YlZ4VlJHeStpL0tLY1JnVWtmUVVyMXVpQ0NTb0dOVHYwcUJxaGpJelRTT0tjZXRJZWxa Z1JNS2liclVyVkUxU3hvU25SL2ZGTnAwZjN4UU5saitJVmVWUmlxUE80VmZqSEZhd0pFWWZsVURu bXAycXM5TmdSTWFiaWxha3JNWXhoVE1WSTFSMGdHMFVDaWtNZXRQRlJEaW5xZWFCTWtwNjAxUlVp aXJRaVdPckMxQXRTQnNWb2dzU2svTFZDYi9XR3JUT00xVWM1YzFNbUNSVWI3eHBNMDlsTzQwekhO WldHUFNwbHFGZUtlRFRBbUZPVVV4VG1wRXFrSWVsV1k2Z1VZTlRMd2EwUWljVkhQOEE2dHZwUzdz Q29aWCtRaW13MUt4cWszV3JvOUtxc3ZOWlNLUTFldFRKVVFYQjZVOWVEU1FGaGFlT3RRZzFLcHlL cENIZ2MxSW5GTlFjVktvcTBJbFRwVWdxSmVCVGkyS3RNQnMzM0RXZmMvY1hGWFpHRzJxa3k1VVZF OVJvcFk1cVZLUXBTcU1Wa01zSlVvTlYxelVpbm5GV2lTWUROT0E1cHE5S2tVVmFBa1FWS3RScmlu aXJRRHllS3J6ZmZGU2sxQTV5MUppUjlBNkNQK0pmRC91Q3MveG54YVduL1hRL3lyUTBIL2p3aC8z QldmNDAvd0NQTzAvNjZ0L0t1VXM1WFUvK1JIMEwvc0xEL3dCSHZYdWtYM0JYaGVwLzhpUG9YL1lX SC9vOTY5MGkrNktReVdpazcwVUFjMThRditSRjFML3RsLzZOU3ZDcTkxK0lYL0lpNmwvMnkvOEFS cVY0VlFBVUdpZzBBSlNVdmFtMEFIMHA2bW1Vb09LUTB5WldxM0MrTVZuN3FuamZGUTBiUWxZMm9a ZmVyOFUvdldESExqdlYyR2Ztc0pRTytsVnNic2NtYXRvM0ZaRUV1YTBJbitXdWFTUFNwVHVXYzB1 YWp6VGdhZzZFRFZFMVNtbUVVaGxlVWNWUW5qclRkZUtxeVI1cW9zeXFRdVlzME5aMDhPTTEwRWtQ V3M2ZUhyVzhKSEZWcEhQenhkYW92SGl0cTRpNjFueVI0elhUR1I1bFNuWXoyV29XNHEzSXVLcXY5 NnRVYzBsWVlhYWFjYWFhWkEwOTZRMHBwS0FHbWpiU2luQVpOSzREUW1XcTNGRm1vMFQ1aFdsYlE1 ckdyT3hjVUVOdGsxc1dWcjA0cHR0Ylp4eFc1Wld2VGl2S3hGZlE2WVFKN0sxNmNWdlcxdGdEaW83 SzE2Y1Z0eFcyRkhGZURpSytwMjA0RWNFZUswSXpoS2hFZTJuazRXdlBtK1kzU3NSVFM0clBudWNk NmRkUzR6V0xkM09NNE5kRkdsY2lVaEw2NnpubXVhdnJycnpWaSt1K3ZOYzVlM1hYbXZadzFBNUtr eUM2dWNzZWF5TG1YUGVrdUxuTEhtcVVrdWE5dWxTc2NjcFhJTGhzMVdOU3lObW9xN0lyUXlZMDBs TFNWUWhLUTB0SWFBQ2lpaWdCeTFLcHFFVTRHazBPNWR0bncxYlZyUGpITmM3RStEVitHZkhldVd0 VHVhUloxMXBkNEk1cm9MSzc2YzF3TnZkNFljMTBGamQ5T2E4bkVZZlE2cWRROUFzcnJweld4RmNa NzF4bGpkZE9hM2JlNHpqbXZCcjBiTTdxY3pvNHBNMWJWc3JXUmJTWnhXbEdmbHJ6cWtiSFRGazRO S2VsTUJwMVlsbEtkTTVyTm5nem10cDB6VlY0TTF2VG5ZaVVUbGI2MTY4VnpWOWFkZUs3Njh0YzU0 cm5yMjA2OFY2dUdybkxVcG5uOTNaL01lS3liaTJ4MnJ0Ynl6NVBGWUYzYll6WHZZZXZjNEtsT3h5 dHhIaXF4V3RXN2p4bXFETGl2V3B5dWpsa3RTc1JUYWxZVkZXcUlDaWlpbUFZcGNVQ2xBelRFU3hM bXJzVU9haHQweldwYnhaeHhYWlFwM09lcE93dHZiODFyMjBXTVZIQmI5SzBvSWNZcjJNUFJzZWRW cVhMTnVtQlZ0VnBzTWVCVTZyWHJVNFdSd1NlbzVCVEpUaXBWRlY3azRyU1dpSVdyS3NzdUt6NTUr RHpUN21YR2F5TGlmazgxNWRlclk3YWRPNTZIOEg1Ti9qRzc1LzVjSC85R1IxN1p6WGhQd1ZrMytO Ynovc0h2LzZNanIzYXZuY1ZMbXFYUFpvSzBMQlJSUlhNYkdONHUvNUU3V2YrdktYL0FOQk5jRHIz L0h2NFkvNjh2L2FVZGQ5NHUvNUU3V2YrdktYL0FOQk5jRHIzL0h0NFgvNjh2L2FVZEFGTWRLMWZE My9JYmgramYrZzFsTDkwVnArSHVOYmhQczM4cXBpT1ArSlAvSUlrSHJmeS93QXhYbHljR3ZSZmlE ZXJPdHpaZ0RNVjdJeE80ZDhkcTRGSStSeFRpZ0xrWDNscTJLcHB3UWFzQnEzaVNPUFNvbnFVbmlv MnFtZ0lDS2JVcEdhalBXb2FBWTFRdjBxUnpnNHFGdWFoaklXcVBHYWxLOTZhRjVyT3d5UzI0ZjhB Q3RLMzZWUmhYRFp4VnVGc1ZwQVRMWGFvbXAyN05OSnJVUkEvV29pS25hbzJIRlpzQ1B0VWJmV250 VVRHcEdSdlVMZFRVclV6Ym1vYUdoZ3E1RDkwVldWZU9sV2tHMVJWUkJtaEg5MFVyVkNqZktNVThz TWRhMVRKSTNxQnFuWTFFd3FXTWhJcEQwcDdERlJNYWdZeHFpYW5tbUVWQUNVNlA3NHB1S2ZHUG5G Q0dUL3hpdEJPQldmL0FCVmFWODRyV0xKSkdxdS9lcG1PYWlhbXdJR3B0U01LalBCcUdNYTNXb3ox cDdkYWpxR0JZRUlOTDltV25LYW5TdExDSy8yWUNtTkNSMEZhR01qcFRIVENrVStVQ25uSFdtbWM0 cEgrNmFock51dzBUZmFXcGZQWTk2Z3B5aWk0eVV5TWVLY3ZTbUtLa0ZNUThvSEF6U2kzVTBpbXBr cXJYRVJpMFh0U20yQUJxMG9OUEs1RlZ5Z1ozbGxEMDRvRGhPdFdMbmdDcVUvUVZMMEFrKzBHbEZ5 OVV5YWV0U3BETFF1RzZVbTh1M1BTbzFGU3FLYVloM2VwVEdyZHFpcVJUVkFIMlpQZW5DMVVkS2tR MU10VWtGeXExc0FPS1lGMm5GWDl0Vlp4aVQ4S0dyQ3VSZWJzR085TSsxTm1vcHppVDhLaTZ0V2JZ eTRMcDhVdm5zZUtxcGlwbEZOTUNRTVdibXBWQXpVYWlucWVhdENIR0JEUUxWVFQxUE5TclZXdUJG OW1XbW1IQjQ3VmJGSVZ3S09VQ29EanJTTlBqcFN5REN0VkF0VU4yR1hCZE5TaTVZMVRYclV5Q2xj Q2Z6bU5PVDd0UnF0U0tLb1I5QzZEenA4UCs0UDVWbmVOZitQTzAvNjZ0LzZEV2g0ZlArZ3hmN2dx aDQxLzQ4N1QvcnEzL29OWWxITGFuL3lJK2gvOWhjZitqM3IzT1A3b3J3elUvd0RrUjlEL0FPd3VQ L1I3MTduRjkwVkl5U2xwS1dnRG1maUYvd0FpTHFYL0FHeS85R3BYaE5lN2ZFTC9BSkVYVXY4QXRs LzZOU3ZDcUFDa29vTkFCVGFXa29BS2JUcVNnQktlcHhVZmFuS2FUR2l3ajFhZ2srYnJWQUdwNFg1 ck5vM3B5MU55M2tyVWhrK1dzQ0NTdEdHWGpyWE5PSjZsQ29hNnZVeW5OWjhVbWNWY2liTmM3UjZG T1Z5YWtvelNWQnNJdzRxRmxGVEdveUtBS3pvTUdzKzRqclZaZURWS1pLdUxNcWtib3c3aUxyeFda TkZqTmIwMFdjMW0zRVdLNllTUE1yVWpEblRHYW91UG1yV3VFeG1zeVJjTlhUQm5tVlkySURUVFVo Rk1OYUdBdzBsS2FDS0FFVUdwa1NtUmpKcTNGSG5GWnpkaWtoSW9zdUsyck9EcFZTQ0hMQ3Q2eWc2 VjUrSXE2RzlPSmFzN2JPT0szN08yeGppcTlqYmRPSzNMZTN4aml2QXhGWTdxY0MxWndnWTRyWUNL SXh4Vk8yanhpcnpjUml2SHF5dXpxaWl1K0JWYVdRQlRVa3pZclB1SmNLZWFjSTNFMlo5N04xNXJu TDY0eG5tdE8vbXhtdVp2NSt2TmV4aGFSeTFKRkc4dU01NXJuN3lVODgxZHVaczk2eDdsODVyM3NQ VHNjTTVHZk01M25tb1N4Tk9rNWFvelhwcGFHQWhOTnBUU1V4Q1VsTFNVQUpTR2xwRFFBVVVVVUFG RkZGQURsT0tsVno2MUNLY0RTYUdtWElwR0RqbXQ2eG5JeHpYTlJ0aGhXdGFTNHh6WEpYaGRHa0dk blkzT01jMTBkbmM1eHpYRFdsempITmI5amM1eHpYaFltaWQxT1ozRm5NRGl0bUtUNUJYSjJNK2Nj MTBFRXVVRmVEaUtkbWQ5T1JxSzFTcWFweHZtclNIaXVLU3NiSWZTYlI2VXRGUmNvcVhVWUlQRllk M2JnNTRyb1pseldkUERtdW1qUGxNNXh1Y2plMnZCNHJtYisyeG5pdlFMeTErUThWeXVvMjMzdUs5 bkNWamlxMHpncitIR2F5Wkk4VjAyb3dZeldMTkZpdnBLRlM2UE9uSFV5cEZ4VmVyc3lZTlZDT2E3 b1BRd1kyaWlnZGFzUTRDbmhhRkZUS3RhS056T1RzV2JST2xiZHJIMHJNdEU2VnVXa2ZTdlZ3bE00 YThpL0RIOG9xN0VncU9KUGxGV28xeFh1MG9XUExuSW5qSEZTVTFCeFRxNjB0REJpaXFWNDJNMWJ6 VkM5YnJVVlg3cGROYW1KZVBqTllkeEo4eDVyVXZYNjFnM0QvT2ErY3hjOVQxNkVUMHY0R3RueHhl ZjlnNS8vUmtkZS84QUZmUGZ3SWJQam04LzdCMG4vbzJLdm9TdkhxTzhqMFlLeUNpaWlvS01YeGQv eUoycy93RFhsTC82RFhBZUlQOEFVZUZ2K3ZML0FOcFIxNkI0dS81RTdXZit2S1gvQU5CTmVmOEFp SC9qMzhLLzllWC9BTFNTZ0NvdkMxb2FLY2F0Q1I2Ti9LczBkS3Y2Ti95Rll2bzM4cXBpUE5mRjZl WjRqdW1ibjUyLzlDYXNQWXE1SXJkOFdmOEFJd1hYKyszL0FLRTFZUnJhS1ZpUmhPQnhVWWxaYWtO Uk1QU2dCVGNNS2I5cGFvbkdLaFkxRGtPeGNGd2Fma0hrVm5odnlxNUVRVTRwcDNHU0NIZWNtbCt6 REhlckVhblpUeUswNVNVVlBzeUNtK1FvcXkvRlJNYVZoa1pYQTRxTnlRYWtKcU54VXNCUFBaYWFi cHFZd3FGeGlwdUJZKzFObW5MTm5yVkhQTlBSZ1dITkpNWmN4bmdmclRsdHdUM29pR1hGWEF0YUpF bFEyb3pUZnN5aXJqZEtoWTBORElmSlZlVFRDT2NWSXhxTTgxTEFqM3NoNHBmUGJGTllWR3c0cUd3 SkRjc2FRWEJOVnpTQ2xkakxtOE5pazJGeU1Db29lZDNXcnRzTWcvV3FqcUlpRnR6UWJaUWF1NHhV YlZUaUJVTUNqdlJzVkY0cVJqVWJVckFNeHhUUklVNlU0OUtZd3hVM0JDK2V3cHBuYzFHYVNwdU1t RXpFODBwTzdtb085U0o5MmhESGlQY2M5cWY5bkZUUXBsQlV3WGl0RkVrcHIxcXhIVlphc3gwUkFz S09LYkx3dkhwVGxwc28rWDhLdGlNMlQ3aHFHcG4rNGFockJsSVR2VXExRjNxUmFReVVDblk1cG9O T3F4RGxxWktoRlRKbXFRaXluUVZLT2xRcDBGVEE4Vm9oRlM2UFNxRS9SYXYzUFFHcUUvUVZsUGNa RGlucDBwbWFlbFpyY1pPdFNnVkV0U2cxb2hCM3A2OWFaM3A2MDBJbVRyVmhLcnBWaE9sYUlDVHRW TzQvMW40VmI3VlR1UDhBV1k5cWN0Z0tGeVAzamZTb2wrOGZyVXR5ZjNoK2xSRHJYTzl5aVpNWnFk YXJwVmhhcENKQlR1OU5GT0hXckVQWHJVeWRCVUs5YW1Ub0t0QVRDaHVCUUtHSEZWMEVVcGZ1dFdh d3cxYU12Q3RXYzNKNHJDWlNIcFZpUGdWWFRyVmhEU1FNblduMUd0UHJSQ1BvSHc4YzJVUi8yUlZM eHIveDUybi9BRjFiL3dCQnE1NGQvd0NQR0gvZEZVL0d2L0huYWY4QVhWdi9BRUdzQ2psZFQvNUVm US8rd3VQL0FFZTllNlJmZEZlR2FuL3lKR2hmOWhZZitqM3IzT0w3b3BESktYTkpSUUJ6WHhDLzVF WFV2cEYvNk5TdkNlMWU2L0VML2tSZFMra1gvbzFLOEwrbEFCU1VVZHFBQTAybHBLQUU3VWxPcHRB Q0hwUlFhS0FRb05TUnRnMURUMFBOUzBVbWFFTW52VjZLWHBXVkcxVzRuNlZqSkhiU21iY0VtY1Zw UU5uRllsdTlhdHUzU3VXYVBXb1N1WGpTY1VtZUtNMWdkeUZOTUlwYzBHa01ZUnhWYVJCVms5S2dr Rk5Da2lqSkhXYmN4ZGExcEIxcWhjcjFyYUxPU3JEUTUrNlRHYXlKbE80MXZYU2RheUowK2F1eURQ R3J3S1RDb202MVlkY1ZBNHhXeU9PU0dVbUtjQlM3YzBFRG9SeldqQkhuRlZJRTVyV3RvdWxjdGFW aldDTE50RGxoZ1YwVmhCMHJOdEllUlhRMk1XTVY0MktxSFhUaWE5aGJqaXRtT0FDcWxqSGpGYXFK aXZucTg5VHZoRUk0OFlxYVhoS0ZHS1NmN2xjbDdzMXNabHcyS3lMcVRDbXRLNlBXc1c4YmcxMjBZ bUUyWWVvUzR6WExhaE4xcmYxQi92Vnl1b3Y5NnZvTUhBNGFyTXlhWW1zK1ZzNXFhUjZxT2E5dUVi SEkyUU9lYWpOUGJxYVlhNkRNUTBsS2FTZ0JLU2xwS0FFcERTMGhvQUtLS0tBQ2lpaWdBb3pSUlFB NVd3d3EvQkppczhkYXNSTmlvbXJvcUp0d1hHSzN0UHVlbk5jbkhKaXR2VHB1bk5lYmlLV2h2VGxx ZDNwODVPSzZhMWx5Z3JpdE9sKzd6WFQya3Z5aXZtOFZUc3owcVVqb0lYNlZvUW5Jckh0M3ppdFNB OFY1RlZXT3VETE5GTnpTMXptZzFobW9taUJxYzAwaXFUc0JuM1Z1UEtOY25xZHYxcnRia2Z1alhM NmxIbk5kMkVuWm5QVmljQnFjR00xejl4RmpOZGxxTUdjOFZ6bDFEak5mVVlXcm9lWlVpYzVjSmpO WjdEazFzWGNlTTFsdXZ6R3ZacFN1ampraUEwRHJUaUthUHZWdWlDZU1lMVdZMHFLSmF1eEptdXVu QzV6elpidEU2Y1Z1MmlkS3k3Vk1Zclp0VjZWN09GZ2ViWGthVVNmS0tuVmFqakh5aXBscjJvSTg1 c2tYaWtOS09sTVkxb1NOSnJQdm02MWRZMW5YeDYxelYzN3ByUytJNTYrYkdhNStkLzNocmN2ajE1 ckFtKythK1l4ajFQY3c2MFBUdmdLYytPcjMvc0d5ZitqWXEraUsrZHZnSC95UFY3LzJEWlAvQUVi RlgwVHpYbk02MEZHYUtLUXpHOFhmOGlkclAvWGxMLzZDYTgvOFJmNmp3ci8xNWY4QXRKSzlBOFhm OGlkclAvWGxMLzZEWG52aVBpSHdwLzE1ZiswVW9BcUwwcS9vL0dxeGZSdjVWUVhwUnV2VVlIVGlC ZGRGSlhjQU81eDlNMVRFY0o0cy93Q1JndWY5OXY4QTBKcXdUV3JycG5PclRpNU82WU9kN2JkdVRu UFR0MXJMTmJMWkVqY1V4cWYycGpVQVFTZXhxcy9Xckw5S3JOV2JLUTBacTlBTVIxUkZYb1RtT2lB bWFNUnlsS2FiRU1MVGowcmRFa0wxQzFUUDNxRnFsakk2UTB1TVVocVFJMnF2SlU3MUE0cUdORUpw MFl5dyt0TlBGT2orOStOUXR4bWpEOThWZUhUbXFVWCtzSE5YUnhYUkhZa2phcTcxWlk4VldlaGdS TlRlMUthVHRXYkFZd3FKdmFwVzZWRTNTcEdRdDFwQlN0MXBLa29tZzcxZnREdzMxcWhCM3E5YWRH K3RhUUpaYVBTb0pLblBTb0hyUmlLN1ZFYWthb3pXVEdKVFRUdTFOUFNrTWlhbTA1cWJVQUZTSjky bzZrVDd0TkRMMXQ5MGZXcHlPYWd0eDhvUHZVK2EzUkxLS2ptcDB3S3ErY0JUaGNLS3pUSFl2QnFZ Ny9LYXJDNUdLWTBwWVlGVnpDc01mbGFocXhqUFdrTUhwV2JRMFFVNVRVbjJkcWQ5bmNVV0dOV3BB TzlNTVRMelR4OTJtaEQxRlRJTVZEdUNqclNpNFVWVnhGdFRUeTJLcGZhbHpTbTVCRlZ6QllmY0ho YXB6RG9LbTh3djFvOHZ6QjA2VkwxR1V0cHA2OFZPYmNucFNpMWVwNVJqRk5TS2VsQXQzNjB1d3Ex T3dtT3FWQjdWRjJxUXlLbFVoRXlpcGxxb0xsUjBOS0xwYXE0V1piTFlxdE1jeVUwM0dUVEEyN21o dTRpdk11WlByeFVPUG1xK1l0d3ozcVA3TWM4VkhLTWdXcGxOT0ZxMU9GdXdIZWhSQVZUVWc2MUVG S21wVjYxUUVpaXBWNHF2NTZDbEZ5dnJWWEN6TFlwck5WZjdTS2FaODhEb2FkeFdFazVEVlNaS3ZZ elRUQm5wV2JWeGxKUmlwMDRxVVd4cFJiTlFvZ0lwcVZhWjVMTFRsNEZXaEgwRDRkLzQ4SWY5MFZU OGJmOEFIbmFmOWRXLzlCcTU0ZC80OElmOXdWVDhiZjhBSG5hZjlkVC9BQ3JuS09WMVAva1NORC83 QzYvK2ozcjNTTDdvcnd2VS93RGtSOUQvQU93dXYvbzk2OXppKzZEU0dTVXRKUzBBY3o4UXYrUkYx TC90bC82TlN2QzY5MStJWC9JaTZsOUl2L1JxVjRWUUFVaHBhUTBBSWVsSlRqU1VBSlNVdE5vQVNr TkxTVUFKVGxwdEE2MERUSjBhckViOGlxaW5pcEVQekNzNUkyZ3phdG42VnNXemRLd2JadWxiRnMz U3VTb2oxOE5JMHdhY0RVQ3Q2R3BGTmN6UjZjV1NVSHBTZlNrcVRRUTlLaGNWTlViVUlHaXM0cWpj cldnM1NxZHdLdUpoVVdoaVhLZGF5WjA1TmJsd3ZXc3FkT1RYWEJuazE0R1pJdFU1QldqTXRVSlJp dW1KNXRSV0dDbmhhYW81cWRWNXBTWm1pYTJUbXRxMGl6aXN5MFRtdCt6ajZWNStJa2IwMGFOcEQw cm9MS0xwV2JaeGRLM2JTUEdLOEhFMUR1cHhOYXlqNlZwQk1WVnRCakZYalhpVkhxZGtWb05BcU80 NFNwYWh1UHVWa3R5bVl0MmV0WVY0M0JyYXZPOVlONmVHcjFNT2Nzem5OUmY3MWNucUwvZXJwdFJQ V3VUMUU5YStqd2FQUHFzeVdhb1dOS3hxTW12WlNPVzR3MDAwNm1tcUVJYVNsTkpRQWxKUzBsQUNV aHBhUTBBRkZGRkFCUlJSUUFVVVVVQUZTcTNGUlVvb0FzTEppdGpUcHZ1MWdBMXE2ZTJNVnoxb2U2 WEI2bmI2ZEw5M211cHNwZmxGY1RwOG5TdW5zcGVBSytheGRNOUdsSTZxMWZPSzJyWnVLNXV6bDZW dTJyOFY0TmVKMzAyWHhUeFVJYXBGTmNkamREelNVVVVnSXB4bU0xejEvSG5OZEZOL3F6V0xlSm5O ZE9IZG1aMUVjaGZ3WnpYT1hzR00xMmQ1Rm5OYzNmeGRhOS9DMURncXhPUHZZOFpyR2tYREd1aXYw eG1zR1ZmbU5mUlllV2g1OVJGUmhVWSs5VXppb2g5OFYyd01HWFlGclJnVHBWRzNGYTF1dlN2VXc4 Ym5EV1pkdGt4aml0YTNYR0tvUUxXbkFPbGUzaDQyUE1xc3ZJUGxGU0NtSjkwVThWNlVUa1k3dFVi VkoycU5oVlNKUkN4ck92VDFyUllWbTNxOWE1Sy93bTlMYzUyOTcxZ3pmZk5iMTZPdFlNMytzTmZN WXZjOXpEN0hwdndEL3dDUjZ2Zit3YkovNk5pcjZJL092bmY0Qi84QUk5WHYvWU5rL3dEUnNWZlJP SzRHZFlVVVVVZ01YeGQveUoycy93RFhsTC82Q2E4KzhSLzZud3AvMTVmKzBVcjBIeGQveUoycy93 RFhsTC82Q2E4KzhSLzZud3AvMTVmKzBVb0FxTDkycitqRE9xeFlQWnY1Vm5xZmxyUjBRZjhBRTFp K2pmeXFtSTg0OFlRK1Y0aXVCNnN6ZitQTlhQc0s3SDRqMjMyWFhGbjV4TXY0ZjU2MXgyOVdyYUw5 MG5xUjlLalkxSXdKNlV3Uk0xRFFFRDFDdzlxdW0yWWltL1pXcWVWakthcnhWMkpjSlF0dmo3M1Nu NHhRbFlDekczeWluazFURTJ4c2RxZDlwWEZhSmlzVE5VVENtL2FrcHBuUTFOd0E4VkcxU013SXFO aHVJQXBESVhOUk4wcXo1REVVaHRYcWJYR1VpTW1ucXZ6VloreWtVOVlRcHlhWEtBK0xoODFhREdx VzdITkt0eDYxb25Za3VNYWhhby90UzQ1cHB1VUpvdU93ckNvenhUMWxWamltTWVhbGhZaVkxR3hx WFlXTkJ0Mk5UWVpWSW9BejBxejltYkZJTGNqclU4ckFaQ090WGJjNFUxQVUyZEtQTTJIaXFqb0l2 N2hpbzNxdjlvd2FRM0sxWE1GaHpDbzI2VUdkVFFYVXA3MU54aktZYWZUQkd6ZHFUQWlha3FmeUc5 S2I5bmFsWVpFS2tUcFRoQWFVamFjVVdBc3d2aEFLbUJ5S29DUXFhZUxuNjFha0lxNG9vb3JJWW9G UEE1cEZxUUNxUW1LT3RUQTFGM3A0TlVJblNwUU0xREhWaGNWYUFZeUROVlhHR1BGYUdPTTFRbS8x alVTQXFNeDNFVTNORGZlTkpXSXg2aXBBS1luU3BWcG9HT1VZcVNNNHBnRk9IRlVoRTZuSnFWUUQy cUJLc1IxYUVPMjhWRkl1RWJqdFZrVkhNQUkyK2xXOWdLUCtGVm1ZbXJKRlVXeUNheGtVUEI1cVJl dFFvZldwMHhVb0I0RlNxTVUxUUtmM3EwSWtRNHFWVFVBNjFLbldyRVRnVXBVWXBFNlZLQlZvQ3RJ dUZ6Vldac0w2VmVtLzFkWjF5RHNHS2lZRURQNlVxazVxTHZ6VXFIbXNybEVxam1wVngzcHFDcFFL MFFod3FWVFVYdFQxTlVoRXkwOENvMU5TclZnSXkxQTR3YXRZNHF0S1AzZ3BQWVNQZlBEdi9IaEQv dUNxZmpiL0FJODdUL3JxMzhxdWVIZitQQ0gvQUhSVlB4dC94NTJmL1hWdjVWeWxuSzZsL3dBaVBv WC9BR0ZsL3dEUjcxN25GOTBWNFpxZi9JajZILzJGaC82UGV2YzQvdWlrTWtwY1VncGFBT1orSVEv NG9YVXYrMlgvQUtOU3ZDNjkwK0lYL0lpNmwvMnkvd0RScVY0WFFBZHFUdFNpa29BS2JTOXFLQUVw S1drb0FhZWxJYVUwbEFDVURyUlNEclFBOFU5RDh3TlIwNVR5S2xtaWVwcDI3ZEsxcmQrbFlrQjZW cVFOaXVXYVBUdzhqV1I2blExUmphcmNScm1rajFhY2kwT2xKU0RwUldUT2xDVXhoVDZZYUJzaGFx czQ2MWJJcXZNT3RVakthME1xNFdzdWRPdGJFeTlhenAxNjEwUVo1MWFKanpyV2JNT2ExcmdkYXlw K3RkY0R5YTZzTlFWYVJhcnhpcmthMU0yWVJMbG1uelYwVmpGbkZZdGtuelYwbGhIMHJ5Y1hJNnFT Tml6aTRGYk5zbUtwMmNYeUN0V0ZNVjg5WG5xZDhFWHJZWXhWczFYZ0dNVk9hODJlNTBJS2d1ZnUx Tm1vYm43bFRIY1poWGg2MXo5NmVEVy9lOTY1Njk2R3ZXdzZPV29jeHFKKzlYSjZpZXZOZFhxUGV1 UzFIK0t2cE1HZWRWTWNtb3lhY2FiWHNJNVJLYWFkVFRRQWhwS1UwbEFDVWxMU1VBSlNHbHBEUUFV VVVVQUZGRkZBQlJSUlFBVVVVVUFMV2pZbkdLemF2V1p4aXM2aTkwcU81MUZqSmpGZEhaUzlPYTVH MGZwWFFXTXZTdkR4Vk03YVRPd3NwT2xkRFp2eFhKV01uU3Vsc24rV3ZuTVRDeDZOSm13alZPcHFs RzFXb3pYbXlPbEU5RkpSbXN5aHNuM0t5N2xNaXRWL3UxUW1YTmFVM1ltU01HNWh6bml1YjFHTEdh N0dlTE9hNXZVNHNacjE4TFUxT1NySFE0YlVVNjF6a3EvTWE2dlUweG11WW1YNWpYMVdGbDdwNWRW YWxHUVZYSEwxYWxGVnYrV2xlbFRPYVJvMnc2VnNXcTlLeWJYdFczYWpwWHRZVkhtMTJhRUsxb1Fp cWNRcTlEWHQwVWVaVVpiVDd0UEZOWDd0T0ZkeU9aN2poVFdwMUlSVkNJU3RaMTh2V3RVaXM2K0hX dWV1dmROYVQ5NDVlK0hXdWZuKythNksvWHJpdWZuSDd3MTh0akY3eDdtSGVoNlo4QS8rUjZ2Zit3 Ykovd0NqWXEraDYrZC9nSVArSzZ2Zit3Ykovd0NqWXEraU1WNXpPMUMwVVVVZ01YeGQvd0FpZHJQ L0FGNVMvd0RvSnJ6N3hKL3FmQ2YvQUY1ZiswWTY5QjhYZjhpZHJQOEExNVMvK2dtdlBmRXYrbzhL ZjllWC90RktBS2FmZHJUMElmOEFFM2kramZ5ck1UN2dyVTBIL2tNUmZSdjVWVEVjNThXSVI5a3Rw TWtZWW5nWnoyLzltcnl0SHkxZXYvRlpmK0pMbjBHZi9IMHJ4dVA3d3B4WUdpdkpBcXlFNTlxclJE NWxxNEJrVjBSMkpHRmVNMHh1S2xhb1g2MEFNWThWRWFlVFRLbGdST01tb21BRldHRlF1S2hqSUdO TkQ4MFBVZFozR1c0VzNOaXJrSzdzMVF0Z2QzNFZwVzNBTmFRRXlRS0FLYTJBS2xJcUo2MXNJaUp3 S2padUtjeHFJbXMyQWg2VkN3eFVwNlV4aFVzWkMzMXFJbXBYRlFucldiWTBQVnZ6cXluSys5VXF1 UWo1VnFrRExpcDB3S2VWd0tkSDkwQ2xZVnVsb1RjaGJpb1NhbGs3MUF4cUdNYXg1RlJNTTA4MDA5 S2daRVJVWjYxSzFSTjFxR01Tbm9jdUJUS2RIOThVQXlmSElxMGtmcFZiK0lWb0owcldKSkdWd0tp WTFPMVYzcHNDTW1vMkdhZXhwbFpzWkd3NXFNam1wbTYxSGlrQTJrNzB0RlNNZXRTQ29sTlNDcVFo d3A0NjB3VklvcWhFMFZXVnF0SHhWaFRXaUVQT2R0Wjh2M3pWNHRpcVVwekkxS1kwVW0rOGFTbGJx YVNzSHVNa1ExS3RRcFVxbXFRRW5TbkRyVGMwNWVhdENKRjYxWmpxdXRUcFZvUk9Lam4vQU5XNDlx Y09LWk0zN3MvU3E2QVVqVkZ1cHE5Vk5seVRXTWloRkZUcFVDOEdwbHFVREoxcC9lbzFOU0QxcTBJ VWRhbFRpbzFGU3FLc1JPblNwUUtpU3BNNHEwQkZOOXlzKzQrNEswSmpsS3o3a1pVVkV3S2ZmOGFs UWMwM2JnMDlldFlvb3NKaXBSVUNHcGhXaUVQNzA0ZGFiVDFxeEVxVkt2V29sNjFLS3RBeDJhclMv ZnhWbnZWYVU1ZWt4STk4OE8vOGVFUCs0S3ArTnY4QWp6dFArdXJmeXEzNGQvNDhJZjhBZEZWUEcz L0huYWY5ZFcvOUJybExPVjFQbndQb2YvWVdIL285Njl6aSs2SzhNMVAvQUpFZlF2OEFzTHIvQU9q M3IzT0w3b3BESktVVWxIYWdEbXZpRi95SXVwZjlzdjhBMGFsZUYxN3A4UXYrUkYxTC90bC82TlN2 QzZBQ2twYVEwQUJwdEthVHRRQVUyblUzRkFDVWxMU0dnQktTbHBLQVF2YWxYclRSVGgxcVdVbVhZ VDByUmhicFdWRWF2eE5XRTBkOUdScXd0VjJFMW1RdFdoQWE1Wm85V2l5K3YzYUtSZnVpbHJCbmV0 aHROTk9wcHBER0hwVmVVVllOUVNpcVJNdGpQbUZaODY4R3RPVVZRdUY0elcwV2NOVkdMY2pyV1Jj RG10cTZIV3NhNTYxMjB6eHNRaEloMHEvQ0twUWl0Q0VWRlU1b21uWXJ6WFQ2ZW5UaXVkc0YrYXVx MDVPbGVIakpIWlJSdldjZnlWb3hyVUZuSCs3cThpVjg1VmxxZWpGRTBReFVsTVFVK3VXUm9nNHFD NSs1VTFRM1AzS1Vkd1poWG5ldWV2ZWhyb2J6dlhQM3Zldld3NXkxRGxkUi9pcmxOUzcxMXVvL3hW eWVwZDYrbHdaNTFVd3lLYlR6VFRYcm81UnROTk9wcHBnSWFTbE5KUUFsSlMwbEFDVWhwYVEwQUZG RkZBQlJSUlFBVVVVVUFGRkZGQUJWdTFOVktzVzV4VXoyR3R6Y3RueGl0dXlrK1lWemtENHJYc1pQ bUZlWFhoZEhWVFoyV252OTJ1b3NXNEZjZHAwblN1cXNINEZmTjR5SjZORm01RWF1eEdzMkZxdndt dkdtanNpV3UxRkhhaXNEUVJ1bFZaRnEwZWxSTXRWRmtzejVZOGcxeldxUjR6WFhPbWMxeldyUi9l cjBNTEwzakNxdERnZFZYclhMVGo1alhYNnN1TjFjbmNMOHpWOWZnMzdwNUZaYW1iS0txLzhBTFFW Y2xGVXovckJYcTBqbGthZHIycmF0ZTFZbHIycmF0ZTFlN2hUeTY1cXcxZWk3VlFoTlg0VDByMjZK NWxRdUwwcDRwaS9kRlBGZHFPWWRSUUtNVllDVm4zdzYxbzRxamVqcldOWmU2WFQrSTVpK1hyWFB6 cis4TmRKZXIxckF1RitjMTh4aTQ2bnQ0ZDZIb253R0dQSE43LzJEWlA4QTBiRlgwTlh6MzhDUmp4 emUvd0RZTmsvOUd4VjlDVjVVMXFkMGRnb29vcVNqRjhXLzhpZHJQL1hsTC82Q2E4OThTLzZud24v MTUvOEF0Rks5QzhXLzhpZHJQL1hsTC82Q2E4ODhTLzZud24vMTUvOEF0RktBS3FmY0ZhV2cvd0RJ WWkramZ5ck5UN2dyVDBIL0FKREVYMGIrVlV4R1Q4VnYrUUdmOTMvMmRLOFppKzlYczN4VkgvRWpQ MC85blN2R1kxK1lVUkJtbEVQbVdyaThDcWNmRENyV2E2WTdFZzFRUDNxWTFHd29BZ05OcVJxak5T QTFxaGNjVkt4cUZ6V2JHUVBVUnFWczB6R2FoalJOYTlhMGJmak5aOXVNTldoYm5CUEJyU0FtV1Qw cUY2a3ptbzJyVVJBL1dvalV6Q295S3pZRWZhbU5UelRHcUdNaGVvVzYxTTVxRTgxREdoQjBxNUY5 MFZUQXE1RndxMVVSbWpHUGxwV3BzYmZLT2FWanhXeUlJWE5WMnF3OVFzS2xnUkdrUFNsYmltazRx R01qYW9tNjFLeHFKcWhqRXAwZjN4VFJUa1B6aWdaWS9pRlgwKzdWQWNzS3ZLMkI3VnJFa0c3MVhl ckJOVjNwc0NCcVNudFRPbFpqR3RVWnA3R21VbUFGVDZVbTArbFd4ZzFJcUE5cWZLQlJBSTdVNFp6 Vi93QW9ZNlZFOFEyMCtVVnlKZXRTQWdWQ1R0WE5SczdIdlN2WVplVjE5YWVKZ085Wm00K3RLQ2ZX bnpCWTBIbUdldFFFN2ptb0J6MXFWZU1VWHVBeDR1QzNhbWVXZlNyaThpcEFvOUtPVzRpZ0ZQcFR3 R3pWOFJyNlV2bGdkcWZJQlNUbXBreHpSSkdFeGp2VVR1VUgxbzJDeFpES09jMDhTcU85WmhrUHJT aGllOUxtQ3hxZWFNZGFqZVhPVnFrTSt0UFVjMVhNQko3VkUwUnhuRlREclV5blBhaTF3S0lqSTdV b1J2U3RBQUh0VHhHcDdVY2dHZUF3NHhVcUhpcmJSREZWM1FJMkJUNWJBT1RHMnBBeWp2Vk9TUXFT dWFpOHdnOEUwdWF3R21zZ0hlbkdSVDNyTERFbnJUd1Q2MVNrRmk0OHVSdHFKMDNqRk1RYzFNdjNx VzRpcVlUNlVlVXc3VmZYclQxVWVsSElNendqRHRUeGtZelYvd0FzSHRUR2lCenhWY2dya0lIU3BS Z1ZFZmx6aXE3U2s5NlRkaG1nSFgxcGQ2K3RaZ2tQcWFjR1ByVFVnc2FKbEE3MUN6Ymptb0J6VWlE RkRrSStndkR2L0hoRC91Q3FmamIvQUk4clQvcnEzL29OWGZENDIyTVEvd0JrVlM4YmY4ZVZwLzEx Yi8wR3VjbzVYVS8rUkkwTC9zTEQvd0JIdlh1Y1gzUlhobXBmOGlQb1gvWVdIL285Njl6ais2S1F5 U2lpaWdEbXZpRi95SXVwZjlzdi9ScVY0WFh1bnhCLzVFWFV2KzJYL28xSzhMb0FLUTBVR2dCS1R0 UzBVQU5wS2RUYUFFcEtVMGxBQ2Q2U2xwS0FDZ2RxU2dVaGxtTTFjamJGVVVOV1Vhc3BJNnFUTlMz YXRTM05ZMXMzRmExc2E1YWlQV3c3TkpmdUNsN1VpZmRGS2E1WHVlbXRoS2JUdTFOTkhVcERUVUVn cWVvWktZbVU1UnpWQ2NmTFdoSUtwWEErV3RZbkpWUmlYUTYxaVhOYmwyT3RZbDExcnRwbmlZa1dB ZEswb0t6WUIwclRnRloxamxnYkZndnpWMWVuTDkydVgwOGNpdXQwMWZ1MTRHTlozVVVkTFpyKzdx Mm9xR3pYOTNWb0xpdm02ajFQUml0QUFwYUtLeVpRbFEzSDNhbXFHZjd0RWR3TU83SFdzRzlIRFYw RjJPdFlWNE9EWHFZYzVhaHl1b3Ixcmt0Ulg3MWRocUM5YTVUVVYrOVgwdURaNTlWR0F5MUdSVmho VUxEM3IyRXprc1JVMDA0OWFhYW9RaHBLVTBsQUNVbExTVUFKU0dscERRQVVVVVVBRkZGRkFCUlJS UUFVVVVVQUZUUW1vYWtqT0tVaG8wSW14V3BaU2ZPS3hZM3hXaFpQKzhyanF3ME5ZczdYVFg2VjF1 bnR3SzRuVEg2VjJHbk53SytheHNUMDZMTitBMW93VmxXNTZWcVc5ZURWUjNRTG9vb3BLNVRVRFRE VHpUU0tFQkV5OEg2VnpXckQ3MWRTVjRybWRYWDcxZG1GZnZtTlZhSEJhdVB2VnlWeDk0MTErcmo3 MWNoY2ZlYXZzc0Y4SjQ5YmN6cHFwSC9XVmRtcWtmdml2WXBISEkwYlk5SzJMWTlLeGJjOUsxclk5 SzluRE04NnNqWWhOYUVKNlZsd0d0S0E5Szl1aEk4eW9pK3ZTcEJVYWRCVWdyMEluSXh3cGFRVXRX U3dxbGVET2F1VlZ1aG5OUlYrRXVHNXoxNG1jMWgzRWZ6R3VqdWt6bXNlNGk1TmZQNHFucWVyUWtk dDhEVng0NHZQK3diSi93Q2pJcStnSzhFK0NTNDhiWG4vQUdEbi93RFJrZGU5WXJ4S3l0STlTbTd4 Rm9vb1BTc2l6RjhYZjhpZHJQOEExNVMvK2dtdlBQRXYrbzhLZjllWC90R092US9GMy9JbmF6LzE1 Uy8rZzE1NzRsLzFQaFAvQUs4di9hS1VBVTArNEsxTkIvNURFWDBiK1ZaYWZjRmFtZy84aGlMNk4v S3FZakwrS1F6bzRIcVAvWjByeUZJU0RraXZZUGlaL3dBZzFPL1gvd0JDU3ZLVzZWY0ZvSmthOEhq dFV5eWc5NmdQU29qeFdsN0NMeGtVOTZhWFdzOW1JSEJwaGtZVkxtQm9FZzFHMzNxcUxNMmM1cXdw M0xtaTl4akh6dXFNb3g3VmVTTWZlNzFKNWFnZEJUNUxpTW94TVQwb0VURHRXbVZIcFRDTURwUzVM REtpUjdEazlhbFY5aHB6bW9YSEZMWVJiRXE0em1rTHFmNHFvRWtWR1dJN21uekRSb0ZsUGVtbkdE VkR6VDB6VWlTdHVxZVlkaVZ1QlVSQlByVTZMdWJGVHJFRjdVK1c0ak9LTWUxTjhvLzNhMVNnSGFt RUQwcGNnR2NzSlBhcDFVS0ttUEhRVkUxTzFndVN4emZ3bW5tVWV0VVRrSE5NSjk2U2tPeGZMcWU5 TUpVMVIzRWQ2UU9jOWFYTUZpMjRxSnVvRkNPWDRQYXBrajM4MHJYRVZpcDlLWVViMHJURVl4MHBy SXVNWTYwK1FhTTNZM29hZXNlTU1hdVl4MnBqbmlqbHNCSFVxeTgvU29UME5SRWVsSzloRjd6aDYw d3VwNzFSUEhlamNmV2puSFl0a3FlbFJzT2FnREVHcEF4SXpTdmNCRzYwekI5RFZwSWdRR3hVd2lC SFNueTNHUUthc1IxWFhyVmlMdFZJa25GTmtYNVRUbEZKTnd2NTFZak5mN2hxR3BYKzdVVllNdEJU MUZSOTZrV2tESkF0UEFwQlRxc1E1VFVxR29SVXlWU0VXRUdSVW0zaW80K2dxWVZvSXFYSTRGVVp6 d0t2WFBSYW9UOUZyT1kwUTkrdFBTbVU5T2xaRkU2MUlCVWFWS0swSllkNmtVKzlNNzhVNWFhRVRw VTZEak5WMEhOV0U2Vm9nSEVWVW5HSlB3cTZlbFVwK1pQd3B5MkFvWEJ4S2ZwVVE2MUxjajk0ZnBV STYxenZjb21UbXAwRlFKVmhhcENZOENuaW1pblZZaVJUNzFNblNvRnFkTzFXZ0pSaWtaZURTaWh1 bkZXSW95OEszMHFnV3EvSjkxcXptKzlXRTJVaDYxUEdLZ1NyRWRKREpsRlBGTkhhbjk2dEVuMEQ0 ZjhBK1BHSC9kRlVmRzMvQUI1V24vWFZ2L1FhditIaGpUNGY5d1ZROGJmOGVkbi9BTmRXL3dEUWF3 S09WMVAvQUpFZlF2OEFzTEQvQU5Idlh1Y1gzUlhobXBmOGlQb1gvWVdYL3dCSHZYdVVYM1JTR1Mw ZHFLS0FPYStJWC9JaTZsOUl2L1JxVjRYelh1ZnhCLzVFWFV2KzJYL28xSzhNb0FLUTB0Qm9BYjJw S1drb0FLYlRxYlFBbEpTbnBTR2dCS1EwdmVrb0FRMGxCNlVkNkFKVXFkVFZaZUttVTFtemVETksx UFN0bTE3VmgycDZWdFd2YXVXcWV0aFdheWZkRkI0cEkvdUNsTmNaNjYyRU5OTk9waDYwRmdhaGs3 MUxVTXROQ2JLMGhxamNINWF0eW1xTTUrVTFyRTQ2ck1pN1BXc1M2NjF0WFI2MWlYUFd1Mm1lSmlS OXYyclVnNjFsVzlha0ZaVmpsZ2Jtbm41aFhXNmFmdTF5R25uNWhYV2FhZVZyd01hanZvblhXWi9k VlpxbFpuOTNWb0d2bTZpMVBSanNPb3BLV3Npa0pVVS8zZndxV29wL3U4VTF1QmpYUTYxaVhhOEd0 NjVGWTEydkJyMGFET2VhT1UxQk90Y3BxS2ZlcnNkUVQ3MWN0cUNkYStqd2NqejZxT2JkTVZYY1Zm bFNxY2dyMllNNDJpcWFhYWVldE1OYklnUTBsS2FTZ0JLU2xwS0FFcERTMGhvQUtLS0tBQ2lpaWdB b29vb0FLS0tLQUNuTFRhVUdnQ2RXcTdaTis5ck9CcTNaTis5NjFsVVh1bHhlcDJtbU4wcnNkTlB5 am11SjB0dWxkbnBoK1VWOHhqa2VuUVowTnVlbGExdldQYkhwV3ZiZHErZHJvOUNCZW9vSFNpdU0y QTAzTktlbE1KcHBBS1c0cm05WFAzcTMyYml1YTFadnZjMTE0V1B2bVZWNkhFYXVldGNoY2ZlTmRa cXgrOVhKWEgzbXI3TEJMM1R4cTI1bnpWU2I3OVhacXBOOSt2WXBISEl1UUd0T0I4RVZrUk5pcjBU NHIwNk1ySEZVaWJ0dS9TdFMzYXNHMms2VnNXemRLOW5EelBOclJOZEQ4dFNBMUJHZmxGU3FhOWFM T0JvbEZMVFJTMXFpR0ZWNXhtckZReWpOVFBZY2R6S25UTlpWeEYxcmRtVE5aOXhGeFhtVjZkenRw U3NkVDhGMDIrTmJ6L3NIdi82TWpyM1d2RWZnNm0zeGxkLzllRC8rakk2OXVyNXJGcTFROXZEdThB eFJSU1Z6R3hqZUx2OEFrVHRaL3dDdktYLzBHdlBmRXY4QXFQQ24vWGwvN1JTdlF2RjMvSW5hei8x NVMvOEFvTmVlK0pmOVQ0VC9BT3ZML3dCb3BRQlRUN2dyVTBIL0FKREVYMGIrVlphZmRGYW1nLzhB SVlpK2pmeXFoR2I4VGY4QWtHcCtQL29TVjVPVFhySHhOR2ROWDJCLzlDU3ZKejFxNmV3bU43Vkd3 cVR0VEdxeEVEaXE3bm1yRW5RMVdicldiS0VEVmRnT1VxaDNGYUVJK1NuQUhzWG8xd3RQSTRwa1BL ODFJZWxib2dnZW9tTlN2VUxWREdNSnpUQ0tjYVExSUVMQ29INHF3OVY1S2hqUkVhZEczekRudlRU VG92dlo5NmhGR2xDTXVLdVlxbEYvckJWNGRLNkk3RU1qWVZBNTVOVHRWZDZHQkV4cHA2VXJkS2Iy cUFHa2NWRTRxVnFpYnBVRFJDMUpTdDFwS2dvbWc3MWV0UnVEZldxRUhVMWZ0ZjR2cldzQk1zRmFp Y1lxZHZTb0pPbGFNa3JzYWpKcDdkYWpOWnNZbmFtRVUvdFRUVWpJV3BLVnFTb0dGU0o5Mm82a1Q3 dE5BWHJkY3hqM3FYRlIyMzNWK3RTa2MxdWlTaW9xeEZVUUZTS2NWQ0FzQTAyUWphYWJ2d0tqZHdW SXFyNkFWSEh5bW9hbVlmTFVKR0t5WTBKM3FSYVozNlU1YVZoa3dQTk96VVFOU0RtcVFoNEZUSlRF SFNwVkdLcENKMDZWSm5pb1FjVXBmM3JRVmlLNTZMVkNmK0VWY25iSUZWcFYzWXhXY3hvclU5S1Fp bkFZck1vbVdwUlVBTlNLYXNUSDk2ZXZCcGc2MU1vOXFwSWtlbldyQ1ZDdkJxUUhGV2dKQ2FxVC93 Q3MvQ3AyYkFxdEljdU1VUzJBcFhIK3NQMHFMdlZpVkNYSnh4VVczbnBXRFJRNUtzTFVDMUlwcTBJ bkZPRlJLZWFsWHJWQ0hyVTZEaW8xV3BGcTBCS0tDZmxwdTdBcGpQMTVxcjJFVnBlUTJLenlPYTBX NUJxb3lZckdTdVdpTk9Lc0lhaEMrMVNMeFVwQTlpd3BxUWRhZ1U0cVZUbkZhSWsraHRCLzVCOFAr NFA1Vm5lTmovb1ZuLzExYi8wR3RIUWYrUWZEL3VEK1ZadmpiL2p6cy84QXJxMy9BS0RXQlJ5MnBm OEFJajZGbi9vTEwvNlBldmNvdnVpdkROUi81RWJRdit3c1AvUjcxN25IOTBVaGtuYWxwTzFMUUJ6 UHhCLzVFWFV2KzJYL0FLTlN2REs5eitJUC9JaTZsLzJ5L3dEUnFWNFpRQVVsTFNHZ0FOTnBmcFNV QUgwcHZTbHBLQUVwS1U5S1EwQUozcE85TFNVQU5wS2NlbEpRQTRkcWxXb2xxUmFobXNTL2FtdHkw N1ZoV3ZhdHkwcmtxbnJZUTE0L3VDbFBTa2orNEtVMXlIc3gyR21tMDQ5S1pRVUlhaGxxVW1xOHhv Uk1tVlpUVkM0UEZXNW1yUG5iZzF2QkhEVmtadDBldFkxejFyVnVUMXJKdU90ZGxNOGJFTWZCV2xC V1pEV2pDYXpxblBBM0xBL01LNnZUbSs3WEgyTGNpdXEwNStsZURqVWQxRTYrelllWFZzR3MyemY5 M1YxV3I1eXBIVTlDSllGT3FOVFQ4MXpzMFd3VkZOOTJwRFVjdjNhUzNBeTdoZWF5YnBlRFczT3Vh ekxoUGxOZDFGMk1aSTVTL1RyWEw2aEgxcnNyK1ByWE1haEYxcjM4Sk00YXFPV21TcUVxOWEyYmlQ R2F5cDF4bXZjcFNPS1NNNXV0TU5TUDk0MUdhNnpFUTBsS2FTZ0JLU2xwS0FFcERTMGhvQUtLS0tB Q2lpaWdBb29vb0FLS0tLQUNpaWlnQmFzMlIvZTFWcXpaL3dDdHFaL0N4eDNPeDBzL2RyczlNUEFy aTlMN1YyZW1kQjlLK1l4NTZkQTZLMlBBcll0dTFZMXQwRmJGdDJyNXl1ZWxUTDlMU0NpdUUzQTlL aGM0cVZ1bFZaV3hWUlFtTmQrRHpYTmFxMzNxMjVaTUExemVxU2ZlcjBjTEQzam5xdlE1RFZUOTZ1 VXVEOHhycHRVYjcxY3RPZm1OZlhZTmU2ZVJXZXBUbXFrLzNxdHkxVGI3MWVyVE9TUktocXlqMVRV NHFaV3hYWENSaEpHemF2MHJidFg2VnpkcS9Jclp0Wk9uTmV2aGFoNTFlQjBNVERhS3NLUldaRko4 b3EzRzllM1RtZWJLQmRXbmNWRWg0cCthNmtZdER1S2pjWnA5TllVTVJXZEtxVHgvTFdneTFYbVRL MXoxSVhSdEJuUmZDTk52akM3L0FPdkYvd0QwT092YU1WNDk4S2syK0xiby93RFRrLzhBNkdsZXcx OGxtQ3RXYVBvTUk3MGhLS0tPMWNKMG1ONHUvd0NSTzFuL0FLOHBmL1FUWG52aVgvVStFLzhBcnkv OW9wWG9YaTMvQUpFN1dmOEFyeWwvOUJOZWVlSmY5VDRVL3dDdkwvMmlsQUZSUHVDdFBRZitReEY5 Ry9sV1luM0JXcG9IL0lZaStqZnlxaEdkOFMvK1FZUG9mL1EwcnlZMTZ6OFN6L3hMVTl3Zi9Ra3J5 aGh4V2xQWVRJKzFNYW5FNEZSTWFvUkhKMHFzMVdHNXFObHllbFp0RFJDQlY2QUVKVmRVNDZWYWpH RXB4RzlpOUdSdHB4NlZERytGeG1wQ2VLMnVTUnYzcUZoVTV4VVpxV0JDZUJURFVqVkU1eFVnUnVh Z2VwbXFJalByV2JHaUUwNk5UdUgxcGR2TlNJaDNEaWtpaTdEL0FLeXJnUEZVVU9IelZsWHpXMGRp QjdWWGs2bXBtTlJOVEFnWVV6dFV6TFVUY1pxR0F3OUtpYW5NY1V4cWdwRVRkYVRtbkVFMGdGVFla TEFPdFg3UWdLM0hlcVVTNEpxekN3VUhOYVEwRXk0VFVNbEtHRk5ibXRMM0ZZZ1lWR1JVNXhVVENz MmdJelREVHpVYkdvWXhqVTJuR20wZ0NwRSs3VVk1NlZLb0lXaGJnWHJjNGpGU0dxMGJoVkFxVU54 V3lZckZBeXNUM284MXZXbzZLeHVVU2lWdldqY1RURkZQQXBpYUpGcCt4V3FNVklwOTZZaFJBcCts Tyt6TDZWSkdhbkF6V2lRRkpyY2VsTTI0T0swQ250VktVWWtOS1NzQkcwcENrRHJUZlBiMXFKajh4 cHZlczdqTEhudWU5T0V6RGlvRnFWUlRUQWNoNTVOU3AwcU1ERlBXcVFoL2tyVGhicDZVTFU2Q3Fz SWgrekxURER0Sk9Ldll6VWNxNFJ2cFQ1UUtsTmFjN2VLVWZkcW16VkRkaWl6OW9hbEU3azlhcXJ5 YWxXcHVCTjVyRVlweWRLWW9xVmVLb1JJb0RKZ2lnUXJTS2FrVTFkZ0VGdWhwMzJkUlV5MC9IR0ty bEV5a1lkbk5KdTI4MVpsR0Z6Vks0UHlpcGFzQXB1R0hlayswdFZRdGswOWV0Wjh3eTBKM05CZG03 MUdvcVZSVjNBa1hyVC9MVnVvcGdxUlRUUWdFQzlLWDdPdFNMMXFRQ3JTQmxjd0RGTTI3VGlycEZW WkIrOHBOYUFmUVdnZjhnK0gvQUhCL0tzN3h0L3g1MmY4QTExYitWYU9nL3dESVBoLzNGck84Yi84 QUhuWi85ZFcvbFhNVWNwcVAvSWphRC8yRmwvOEFSNzE3bkY5MFY0WnFQL0lqYUQvMkZoLzZQZXZj NHZ1aWtNa3BhU2lnRG12aUQveUl1cGY5c3Y4QTBhbGVHVjduOFFmK1JGMUw2UmYralVyd3lnQXBE UzBsQUNVbExTVUFKUlJSMm9BYWFROUtVMGxBQ1VsTDNwUFdnQkRUYWQycE85QURsNlZJdFJqclVx aW9ackV2V25hdHkwckV0UjByYnRPMWN0VTliQ0d0SGpZS0RRbjNCUWE0ejJZN0NIcFREVHpVYlVE WXcxV21OVGsxVm5OVWpPYjBLVXg2MW5UdDFxM08zV3MyZDY2SUk4MnRJcDNCckxuNjFmbWFzK2F1 cUI1VlpqNGF2UW1zK00xY2lOUlVSakUyckZzR3VvMDl1bGNqWk44d3JwYkIrbk5lTmpJblpTWjE5 bS95Vm9SdFdMWnlmTFduQzlmT1ZvYW5vUVpveG1wS2hoT1RVOWNNdHpkQ0dtUDBxUTB4K2xTTXBT cm1xTThlVk5hVWkxVmxUNVRYUkNWak5vNWkrajYxek4vRjFyc0wyUHJYTjMwWFhpdlp3c3pqcXhP VHVvOFpyRnVseG11bHZJc1pyQXZFeG12b01QSzV3MUVZY24zalVacWFVZk9haUlyMGtjbzAwbEth U21BbEpTMGxBQ1VocGFRMEFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUF2ZXJGbi9yYXI0cXpa RDk3VXorRmpqdWRmcGZVVjJlbWRCWEc2V1B1MTJlbWo1Ulh6R1BQVW9IUVczYXRpMjdWajIzYXRl MjdWODVYUFNwbWgyb29IU2l1RTJHdjkycUV6WXE5Sjl5c3E1ZkdhMnBLN0lrVlo1TVpybTlTZnJX dGN5NEI1cm5OUmx6bm12WXd0UFU0NnNqbk5UYnJYTlRINWpXN3FMOWE1MlZ2bU5mVVlXUHVubFZY cVY1S3F2MXF4SWFydDk2dlJnWU1BYWNHcGxGYUprTkdoYlBqRmE5dEowckNnT0swb0pNWXIwTVBV c2NsYUIwTUVuQXE5QzlZVUUzU3RHQ2Jwelh0VUtwNWxTbWJjUjRxVE5VSVp1T3RXRmt6WHB3bXJI RktKWkZCcU5XcCthMVJMUWJhamtUNWFrcEgrN1EwQ1owdnd3VGI0cHVUL3dCT2JmOEFvYVY2emoz cnl2NGFEL2lwcmovcnpiLzBOSzlVeDcxOGRtcXRpV2ZSWUIzb2hRYVB6cGE4MDdERjhXLzhpZHJQ L1hsTC93Q2dtdlBmRXY4QXFQQ24vWGwvN1JTdlF2RnYvSW5hei8xNVMvOEFvSnJ6M3hML0FLbndu LzE1ZiswVW9BcG9Qa0ZhZWcvOGhpTDZOL0tzeFB1Q3RUUWYrUXhGOUcvbFZQWVJsL0ZFN2RKVnZR RS8rUHBYa3F6YnVEWHEvd0FWV3hvdjRFZitQcFhqaU55S3FEQmw3dmoxcHkyNDcwa2ZMREZXZ0sx U0pJUHM2MDAyNmVuRldUakZSTlRzQkVJMVU1SGFtdHdhZXhxTTFJRVRPeXZrVWVld0ZLd3FKK0tt NHh4dVg5YVQ3UzJlcHF1MU1CeFU4d3krSlBNbzh2ZWFndHlDMVhvRjVOVkhVa2FMZGNVZlowNllx empGTWFyc01ybUJCU2JRdlFVOWpVWk5TQkczU21CMldwRGlvbXFRQTNEMDM3UzlNWVZDZUtpNHky dHdhZG5JcWtHcTVIeW9xa3dzT1NISnpqaW4vWjE3aXJLTHhUbUdCeFYyRVZQczZDbW1GS25icFVM RTBtZ0dTZEFLaWJxS2UxTk5TQ0VNcmltK2UvcnhTTlVScWJsRXZudFRoTHU0cXZpblJqNXhSY0Nl bnJDTThqaW1qN3dxNkY0RldsY2tyZloxOUthWUZxMmVsUXZUc0JENVNyelRHNjA5alRDTTFJeU1r aHMwb2xiMW9ZVXpGU01iU2Q2V2lwQWV0U0FWR3RTRHJWSVRGcHdOTjcwOENxRVR4VlpYOGFyUmRS VmxhMFFoeCs3V2ZMOTgxb0hwaXFFb3hJYVV4b3BOOTQwbmVsYjd4cEt3ZTR4NjFPdFFJT0ttV3FR RDZVVWdOT0ZVaEVpMVpTcXlkYXNwV2tSRXdxT2YvVnQ5S2tXbzV4KzdiNlZUMkFvbXFMQVpxOGFv dDFOWVNLUXExT2xRS00xT2xKQXlaYWVPdE1Xbjk2dEVqaDFxUktpQTVxVktzQ3duU3BSVVNEaXBS Vm9USVovdVZuM0FHd1Zvemo1S3pyZzRRZGFtWXlwM3FWRHpVTlNvTUhOWUlwYkZsQlVvRlJKVW9y VkVzZDNwdzYwMENuQWMxUUVxVk12V29rRlNyMXEwQS90eFZXWDc5V3UxVlpSODRwUzJFajZCMEQv a0h3LzdpMW5lTnY4QWp6cy8rdXJmK2cxbzZEL3lENFQvQUxBL2xXYjQzLzQ4N1A4QTY2dC9LdVVz NVhVZitSRzBML3NMTC82UGV2YzR2dWl2RE5SLzVFYlF2K3dzdi9vOTY5emkrNktReVNscEtLQU9h K0lJL3dDS0YxTC9BTFpmK2pVcnd5dmMvaUQvQU1pTHFYL2JMLzBhbGVHVUFGSlMwaG9BVHRSUjJw S0FEdFRhWDFwS0FFTklhV2tvQVNrcGFTZ0JEVGFkU1VBUFdwVkhGUktLblZhemtiUVJkdFIwcmF0 ZTFZOXFPbGJOcU1WeTFEMXNLalVUL1ZpbE5JdjNCUlhJZXl0Z1BTb21xUTlLaGMweE5rYkdxZHdh c3UxVXJrMWNUQ285RFB1RzYxbFROeWF2M0xkYXlabTVOZFVFZVRYa1F5dFZLV3JFalZWa3JvaWVk VVk2T3JVYlZVVTFPaHFab2hHclp0ODFkSFl2MHJsYlIvbXJvTE9UR0s4dkZRT21renJMT1Q1Uld2 YnZYTjJjdkE1cmJ0Wk00cjU3RVFQUXBzM2JjOUt0VlN0V3ppcm1hOG1vdFRxaUthYTFMbWtyTmJs a1RMVUVrZnltclJGTWNmS2FwTVRSejE3SDFybmIyTHJYVjNpZGF3THlQclhxWWFaeTFFY2pmUll6 WE4zcWRhN0MvaTYxekYvRjFyNkhDelBQcW81aVlmT2FoSXEzUEVmTU5WbVhGZTFGNkhFMFJHbTA5 aGltVlloS1NscEtBRXBEUzBob0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDbEZKVGxGQUM0cTFaRDk3 VmNMVnl5VDk3V2RSKzZWRmFuVjZXUHUxMldtamdWeUdtSjByc3ROWGdWOHhqbWVwUU4yMjdWcjIz YXNtMkhTdGUzN1Y4OVhQU3BsNGRLS1ROR2E0amJRWk45dzFpWGo0eld4TzM3czF6MS9Kak5kV0dq ZG1WUm1SZVRZelhPWDB1YzgxcVgwM1htdWN2SmM1cjZIQzB6emFzakp2M3ptc0tSaHVOYWw0K2Mx alNOOHhyNkdoR3lQT3FNWTVxQnV0U3NhaU5kY1RJU2lpaXFFVFJ0aXJjY21Lb3FhbFZxMmhLeG5P TnpXaG01NjFvd1RlOVlFVDgxb1FTNHIwS0ZVNHFsTTZHR2JqclZ5T1ROWWNNM3ZWK0tldlhwVlRn cVV6V2piTlRnMW54VENySW1IclhvVTVxeHlTaXl3RFNucFVJbEZQOEFNRmFwb2l6T3crR3E0OFIz SC9YbzMvb2FWNmpYbDN3Mk83eEZjZjhBWG8zL0FLR2xlcFlyNUhPUDk1Zm9mUVpmL0JFb3BhU3ZM TzR4dkZ2L0FDSjJzLzhBWGxML0FPZzE1NTRsL3dCVDRVLzY4LzhBMmlsZWgrTHYrUk8xbi9yeWwv OEFRVFhubmlYL0FGUGhQL3J6L3dEYUtVQVZFKzZLMDlCNDFpTDZOL0tzeEI4bzVyVDBLUklkV2lk NUVSUUcrWnlBT252VlBZUmovRmIvQUpBZ1ArZnZKWGpjUSthdll2aW5kUVQ2S1JGUERLY2MrVzRi SHpwNlY0N0h3d29RR25HY010WEJ5S3BSL2VXcmk4Q3VtT3hMRWFvWHFacWdmdlFCRWMwMm5IaW0x SURXcUY4Vk0xUXZVTVpXZjJxUHZVajlhanhXWTBXTGI3MWFWdjNyTnR2dlZvMjQ0TmFRRXl5UlVM MU1UVVRpdFdJclAxcU0xSzQ1cUkxbXdHbnBURFQrMU1icFVzWkM5UXQxcVo2aGJxYXpZMElLdVEv ZFdxWUZYSXZ1clZSQTBvdnVpaDZJK0ZvWTF1dGlTQ1ROVjJxeEo5YXJ0VU1ZdzBoKzdTbWtQU29Z SWphb1c2MUsxUk4xcUdNUVU2UDc0cHRPaisrS0VNc0Q3NHJRVDd0Wi93REVLMEVHRnJXQkkxaDFx dTlXV3FzOU5nUU5UYWUxTnhXWXhwcGg2MDg4VkdldEt3RGVsSGFwZklOS0lHUGVsWUNJVklwcHdn YWtNWlhtbllCNHFRQ294eFRqTXExUWlkT0ttVTFTRnhqcFMvYXFwU0N4ZFp1YXB5SExuclRXbko2 VVp5S0c3Z1ZpUG1QRk43MWJNVzRjVW4yWW5waXMzRW9nVTFJcHA0dFdCNjA3N09SelRzSVJUbXBF cU5WSTYxSWpCUWMweEVxam1wa3ptcW4yZ0RtbEYwUFNyVEN4ZXpnVkhJMlkyK2xWeGRlMU1NcFov YW56QUhXcWhUazhWYzdVTkRrREZSYTRJcEx3YWxVMVA5bXBSYk5TVVJqRk5TTHlhVHlHRktvSTYx VmhFaWlwVnFKWFZWcEJjcm1xQXVMVHljVlMrMUQwbyswNXFsS3dyRmlRa29lYW96ajVLa0VwWnZh bmhRM0JHUlV2VVpubGNVNWVEVm8yMmFVV3BxT1FDSlQ2Vkt0TDltT2FERXkxU1RFUEZTcUtpSEZL WlF0VWhsaFJUeFZRWEtpbkM2RlZjVmkwV3FDUS9NS1laODBnTzZrMkZqNkYwRC9rSHcvN2cvbFdi NDMvQU9QS3ovNjZ0L0t0TFFQK1FmRC9BTGkveXJOOGIvOEFIbFovOWRXL2xYTVVjcnFQL0lqYUYv MkZsLzhBUjcxN25IOTBWNFpxUC9JamFGLzJGbC85SHZYdVVYM1JTR1MwVVVVQWMxOFFmK1JGMUw2 UmYralVyd3l2Yy9pRC93QWlMcVgvQUd5LzlHcFhobEFCU0dscERRQWg2VWxLYVR0UUFVMm5VMmdC S1R0U21rTkFDVWxMU1VBSmlqRkhhbEFwRFJJZ3F3aTFGR0t0eHJtc3BNNnFTTE5zdkFyV3RoMHJP dDE2VnFXNHhpdVdvZXJoMFgxKzZLV2tYN29vUDQxem5xTFlRMUE1cVltcTBoOTZFVElnYzFSdUdx MUkxWjF5OWJRUngxWmFHZmN0MXJLbWI1alYrNWJyMXJLbGI1elhYVFI0OWVReHo3MUF4cDdOVVo2 MXNqamt4UlVpdFVJcGM0cE5DVE5DMmZtdHkwazZWemx1MkRXdmJTZEs0Y1JDNXZUWjFGcEwwNXJm czVNNHJrYlNYNWhYUldNdlRtdkN4Vk03cVVqcTdOdW1LdjVySXNYSEhOYWdZZXRlQlZqcWQ4SG9T aWltcWFkWE95d3FOaHdha3ByZERTR1pWMHZXc1c2anptdWd1RnpXVmNSWnpYZFJsWXdtamxiK0xy WEwzOFhXdTF2NGV0Y3hmdzlhOTNDVkRocXhPT3VZc09lS295SlczZFFuY2VLekpveUs5K2xPNk9H VVROa0dLanFlWVlOUWZoWFVqSVNrcGFTbUlTa05MU0dnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtr UVpxTTFORU0wbU5FeUpWNnlqL2VkS3J4SWEwN0tJK1owcmxxeTBOSUxVNkxUVSs3WFg2Y3ZBcm1O TmpQRmRicDZjQ3ZtY2JJOVNnald0eGpGYXR1T2xaMEM5SzBvQlhnMW1kOEMwZWxNTFlwekhpb0hj RHZYUEZHdHlPNWZFWnJtZFJrNjF1M1VnOG84MXl1cFNqbm12UndrTHM1cTBqQjFDYkdlYTUrNmx6 bm1yK3BUZGVhd2JpV3ZxTU5TMFBLcXlLbDAvV3N0anlhdDNENXpWQmp5YTllbEd5T09iQW1tSHJT L1drcllnS0tLS1lDZzA4R282WE5OTVZpZEd3YXVSU1lyTlZzVk1qa1Z0VG5Zem5DNXJ4VFlxN0ZQ NzFncExWdUthdTZsWE9XZEk2Q0tmM3Ewcy92V0RGUDBxMmsvdlhvMHNRY2M2UnNyTjcxTXN2dldR azN2VmxKZmV1dUZZd2RNOUYrR0RidkVseC8xNXQvNkdsZXIvblhrUHdwZmQ0bXVQOEFyemIvQU5E U3ZYcStmelIzcjNQV3dLdFNGcEtPMUxYbkhZWXZpNy9rVHRaLzY4cGYvUVRYbm5pWC9VK0Uvd0Ry eS84QWFLVjZINHUvNUU3V2YrdktYLzBHdlBmRXYrcDhLZjhBWGwvN1Jqb0FwcDkwVkJlM01WcmJT eVRXcVhVYW9XYUNSdHF0OVQrdjRWT2crV3NuWGVkUHVGOVluSC9qcHFoSElhN3JObmYyNWp0Tk50 N0xkd2ZLa0xidVFmNlZ6NkpoaFZ2N0xnMDVZQXRhS0FyaXB3UWF0QnFxRTdhUlp5SzBUc0l1RTFF MktoTnpTZmFWb3VnSGtWR2FVVHF4cENjbjJxYmpJMk9EVVRHcGpHek5SOW1wV0FwTUtSVnlhdW0w UFdrK3pZcU9VQ0dBWWVyMEp3RFVSakNDbUZ5cEJGVXRBTCs0SHZURzZWV0Z6aW1tNkE2aXI1Z3NT c0tqWVVuMmdIdFNpUU5rVklXR0dvV05Ta1pwQkN6Vk5nS3pWSGlydjJaalRUYTRxZVFaVUMxYWo0 VVU1YmJCNW9JSXpUVWJBWEVmQ2ptbnNjMVFFeFUwNzdUaXRGSVZpZCtSVVRDbUc2Rk4rMEJxbTRB d3hUR3A3TURqRk1aU3hBcVJrUlBGUm5yVm43T1NhVDdLYWx4R1ZxY25FZ3FiN09SVHZLQ3JudlFr SU0vTUt1SytCVkkwTE1WNjFTZGhGNW1GUXNLaCswMGh1QWVDS2ZNRmh4NlZHZURTK2NwcHJFRTFJ eGpWSG42MUxzTEhJQnBmSWFpd0V5bXBrSE5WMTYxWWpxa0prdXlvblRqcFZoYVNYaGZ3cW5zQm1P Zmx6VVBhcG4rNVVOWXNhRDJwd3BuZXBGb0dPVVZLdE5BNXAyS29USkZOU3B6VUNtcGtxa0luVVU0 cm50UW5JcVVEaXRFSXBUamFCVlNac2JhdTNYOFByVkNjZmRyT1l5TXRTcjFwbFBTczdqSlZIclVp am1tcU0xS0JWaUNwa05ROTZrVTFTRVRxY252VWdHYWhTckNEaXRFREVaUGFxMG93K0t2ZHFwM0gr dC9Da3dLVXpZZjhLaXp6VHJnZnZEOUtpSFdzR3lpVWRhbFVWRWxXRnFrSWNveFVpbm1taW5kNnNS S3BxVlJVQzlhblRwVm9CNEZJeS9LUmluaWhqeFZXRVVYNERWVVo2dHlqNVdyUGJnMWhJcEQxUE5T cU9haFNyQ0NoREpGRlNLTURGTlVWYXN4L3BzQS82YUwvQURxMEk5KzBIL2tIdy83Zy9sV2I0NDRz N1A4QTY2dC9LdExRZitRZkQvdUQrVlp2amovanlzLyt1cC9sV0F6bGRSLzVFWFFmK3dzUC9SNzE3 bEg5MFY0YnFQOEF5STJnL3dEWVdIL285Njl5ais3U0dTZDZYNjBsTFFCelh4Qi81RVhVdisyWC9v MUs4TXIzUDRnLzhpTHFYL2JML3dCR3BYaGxBQ1VHaWcwQUoycEtXa29BU2t4UzBsQUNHa05MMnBE UUFsSlMwZ29BVURpbEE1b0FwNnJ6VXMwaWllSk0xZmlqcXRBbGFVRWVjVnp6WjMwWUVzTWVPMVg0 VnhVTWNlQlZxTmE1cE05V2xDeE9QdTAwbWwvaHFOeldSMTlCck54VlNWNm1adUtvenZ5YXVLTWFr dENHYVNzNmVUclVzOG5XczZhU3VtRVR6SzFRZ3VIem1zNlEvTlZxWnV0VW5QTmRNVWVaVmtNTk5O S2FhYXRHQWxHYURUU2FBSjRUelduQkpqRlpFYllOWElueFhQVmpjMGl6ZXRwc01PYTZHeG42YzF4 MEUzekRtdDZ5bjZjMTVXSnBhSFZUa2R0WXo5T2ExNDVzOTY1U3luNmMxdFFUWnh6WHoySXBhbm9V NUczRythc2pwV2RBMmNWb0w5MFY1dFJXT21MRnBEME5MU0dzaWlwS3Vhb1RSMXB1dWFydkhtdG9T c1EwYzVmUWRhNXErdCt0ZHJlUTlhNSs4dCt0ZXJocXB5MUlIRTNkdHllS3hybURHYTYrOHR1dkZZ RjVCak5lOWg2MXpocVFPWnVJOFZVSzRyVHU0OFZSWmNWNjlPV2h5U1JXSXB0U01LanJVZ1NrTkxT R2dBb29vb0FLS0tLQUNpaWlnQW9vcGFBREZXcmRNNHFzQlYrMFhPS3pxT3lLaXRTOWJ3NTdWc1dW dDh3NHF0Wnc1eFcvWlczU3ZKeEZXeDEwNEdqcDhHTVYxRmhGd0t5YkdER0s2T3ppd3RmT1l1cGM5 S2pFc3hKaXIwUXhVQ0ppckNERmVWTjNPdElXWnNDczZlYkZXN3BzQ3NPN214bm10S05PNU0zWVpk M1h5SG11WDFHNHpubXI5NWM4SG11YnZyak9lYTl2Q1VOVGhxMURLMUNiT2VheFpucTFmVFp6V1hK SlgwZENuYUo1dFNXcEZNMmFxSHJVOGpacUExMnhSZ3dOSlJSVmlDaWlpZ0Fvb29vQVVVNEdtVW9O Tk93RXltcDBlcVlOUFY4VnJHZGpOeE5GSmFzSk43MWxDV3BWbTk2NklWckdNcVpzSlA3MVlTZjNy RldlcGxuOTY2b1lnd2xTUFd2Zy9MNW5pdTZHZitYRi93RDBOSzlwNDlhOEorQ2N1L3hqZGovcUh2 OEErakk2OTJyaHhjK2VwYzZzUEhsaFlPYU0wZHFLNVRjeHZGMy9BQ0oycy84QVhsTC9BT2dtdlBQ RXYrcDhKLzhBWG4vN1JTdlEvRnVQK0VPMW5IL1BsTC82RFhubmliL1UrRS8rdlA4QTlvcFFCVVQ3 b0ZaT3QvOEFIcE4vMXpiK1ZheUQ1UldUcmY4QXg2VGY3amZ5cTF1STRWcWpKcHpHbzJyZGtqRHpV YkNwZTFOYXBBcnR4VUxIQnFhVDJxdXhyTmpRNVg0NjFiUnR5Vm5BODFmZ0JFZEVXRExzYTRVVS9i eFJGOTJuTU85Ym9sRVI0cU5qaXBIcUJxa1kxc21vbkZQTklha1pBd3FKdWxUdlVEbkZRd0k5eHpV aXY4MVJIMnBZeGx2eHFVeG1oR012aXJRWG1xOEovZUNydkZieEpJbUZSTnhVekRpb0hvWURHYW9q elRtTk03Vm14M0kyRlJNS25ZVkU0cVJrSjRvQngwb2JxYVFWSXllRTVCelZxQVpCeU0xVWc3MWZ0 TVliNjFjU1NVTFRHNEZUbW9KSzBBaFkvV29tUEJwN0dvaWFoZ0llbFJrQ3BPMU1OU01qSXB0SzFK VUREQnFSZnVWSFVpZmRwb0dXNFZ5Z3FVSnhUYmY3aTFPQld5SktDMVlqcUJSaXA0NmxBV0ZwazMz Zndwd1BGTWQvbE5XOWhHZko5dzFEVXovZE5RaXNHVWhPOVNLS2o3MUl0SVpNUGFscGltbmpyVmlI RHJVcVZHdFRKVklSWWo2VktPbFJLZUtmdXdLMFFpcmRaNHFqUDJxL2RFa0NxTTQ2Vm5JWkJUMXBt S2V0WjJLSjBxVVZDcHFSYXNsanU5UFdtVklvcWtJbGpxd2xRSUttV3JpQkoyNzFUdVA5WitGVzky S3FUOHlVNUFVTG5pUS9Tb1IxcWVkY3lFMUZqQnJCbExZa1NyQzFBbFRLYWFFeVVDbkNtS2FrWDNx MEljdldwMDZWQ3RUSlZvQ1VVUDBwS0dhcVd3aWxKamExWnovZXJTbEdWYXM4cHpXRWloVXF5bFZs NE5Ub2FTQXNMVm16L3dDUDJEL3JvdjhBT3FnTldyUC9BSS9JUCt1aS93QTYwRWZRR2cvOGcrSC9B SEIvS3N6eHdQOEFRN1AvQUs2dC9LdFBRUDhBa0h3LzdnL2xXWjQ0L3dDUE96LzY2dC9Lc0NqbGRS LzVFYlF2K3dzUC9SNzE3bEg5MFY0YnFQOEF5STJoZjloWmYvUjcxN2xGOTBmU2tNa3BhU2lnRG0v aUQveUkycGY5c3Y4QTBhbGVHZEs5eitJSC9JajZsOUl2L1JxVjRZYUJnYVNscE8xQWhLU2xwTzFB QlRhZFNVQU5OSlMwVUFOeFNxdEtCVDBYbWtVa0tzZFNwRnp6VWtjZFdvNHF5bEk2cWRPNHNFWFN0 T0JLZ2hpclFoVHZYTE9SNmxDblllcTFJdkZHM0ZKV0xaM0pXSHMyQlZlUjZjN1lGVTVYcHhRcHpz RWt2QnFoUEwxNXBaWmFvVFM5ZWEyaEU0cXRVaW5rNE5VSkdxV2FTcVR2WFRHSjVkU1kyUTlhck4x cVZ6VUpyVkhMSmpUVFRUalRUVEpHbWtOT05OTkFBdFRvMVZ4VDFiRlRKRFJlaGZEam10cTBteGl1 Y1I4TlduYnpZNzF4MTZkMGJRbFk2Nnp1Y1k1cmJ0Ym5welhHVzF6akhOYlZuYzlPYThURVVEdHB6 T3p0YmpweldySE5sUlhLMmMvVG10cUdiS2l2RHIwck03cWN6VUQwK3FjYjV4VnBEeFhES05qWk1S aFRHV3BTS2FSU0daMTBtYzFpM1VPYzEwVXlack5uaHptdXFqVXNaVGljbmVXM0I0cm5yMjE2OFYz RjFiZktlS3dMMjE2OFY3T0dybkhWZ2NKZTJ1RDByTWt0OFYxdDVhOWVLeDU3ZkdhOTJqWHVqaG5B NTZTTEZWeW5OYXM4V0tvT3ZKcnZoTzZNR2l0aW1tcFdXb3oxclVnU2lpaWdBb29vb0FLS0tXZ0Fx Ulk4MHhmdlZkaGp6VVNkaHBFYXdaclVzYmJweFNRd1pyWnNiYnB4WEhXcldSdENHcGJzclhweFhS V2R0d09LcTJOcjA0cm9iVzJ3bzRyNS9GVnowYVVDVzBoeGl0eTFUQzFUZ2h4aXRPRk1MWGkxcDNP Mm5Hd3U3YlNlZmlvcG0yNXFoTlBqdldVYWZNVzVXSnJ5NjRQTmM5ZTNYWG1wcnk2NjgxenQ3ZGRl YTlQRFljNWF0UWl2THJPZWF3YnVmT2VhZmRYV1dQTlpOeFBuUE5lL2g2Rmp6Nmt5cmR2bk5VR2JO UzNFbWMxV0o0cjFxY2JJNUpQVVJxanB4Tk5yVkVCUlJSVEFLS0tLQUNpaWlnQW9vb29BS0JSUlFB NFU0R21Vb05VbUt4TUQzcVJXeFZjR2xEVm9wRU9KNng4Q216NDF2UDhBc0hQL0FPaklxK2dLK2V2 Z0syZkhGNlArb2JKLzZNaXI2RzVxSnU3S2lySVQ2VVVmU2lvS01ieGIvd0FpZHJQL0FGNVMvd0Rv SnJ6enhOL3FmQ2YvQUY1LyswWTY5RDhXL3dESW5hei9BTmVVdi9vSnJ6enhOL3FmQ24vWG4vN1JT Z0NtbWR0Wld0Zjhla3YrNDM4cTFrKzRLeWRiL3dDUFNYL2NiK1ZXaEhCc0tqTlN0VVpyZGtqTzFN YnBUNmpZMUlFTW5wVlpxc3VhcnNLelkwUmdjMWZoKzVWTUthdVFydGpvZ012eEE3YWtOUnh0OHRQ SjRyY2tpZW9HcVo2aUlxUUlxUTA0MHhxbGdSdFZlUVZPeHFGNmhqUkNhZEY5NGZXa3htbkl2empQ YW9TMUdhRVArc0ZYaDBxakVjT0t1QnMxMFIySkVZOFZXZXJEZEtnY1VNQ0JxVHRUMkZNNkNvWXhq ZEtpYnBVakdvbXFHTWliclNVcEZJQlVESm9POVhyWG8zMXFqQU90WGJac0J2cldrQ1dXelVEMUp1 elViL2pXckVWbXFNMU0xUkdzMk1iMnBwcDJNMHcxTEdSdFRhVTBsUUFWSW5TbzZrVDd0TkRMMXY4 QWRGV0tyUU5pTVZOdTk2MlJMS1ljQ3BCTW83MVFCb3JQbUhZMFBQWHNhamFZRGlxZ3B3WG1qbUJv bEs3cWpNUkhRVktwcVVHaTF3UlQ4dC9TbkNOaDJxOG9CcVRZQ2Fya0F6dHBIWTFLdlNyVFJBbnBW ZGwyc2FUVmdIakFGT0VpanZWTjVDVGltYnptbGV3R21zeWp2UTA2a2RhelZPT2xQR1Nhcm1FV1hs OHc0cU14N3g5S0ZxUk9LTndLM2tuMHBSRTM5MnJ3eG1wRkFvNUF1VUJHNDdVcWdodWVLMFBMR0tp a2pHMG4wcXVXd1hJTzFUQWhldFFqMXFCM0o3OFZON0RzWHhLb1BXbmlaZldzb01UOUtlcElQV21w aFkwV21YMXFGbjN0bW9BS2xYZ1U3M0pFYUxkelVSZ2ZQSXEybjNhbEZMbHVNb0NGaDJwNFJoMnEr Qm5pbDJjZEtwUUFvcm5kNlZNbldueVJqR1JWZVI5aThVYkFXZHlyM3B5eXI2MW1HVDNwUTVOTG5D eHFlY3ZyVFRPQm5ITlVRVDcwOERKcDh3aVlqY01WQzBHT2dOVENwVm90Y0NpSUQvZHA0aWJIU3J3 RlBDalBTbW9BVUFyRHRWdXgvd0NQdUQvcm92OEFPcEdUMnB0c20yK2cvd0N1aS96b2FzZ1BmdEEv NUI4UCs0UDVWbStPUCtQS3ovNjZ0L0t0TFFQK1FmRC9BTGcvbFdiNDQvNDhyUDhBNjZ0L0t1Y281 WFVmK1JHMEgvc0xMLzZQZXZjb3Z1MTRicVAvQUNJMmcvOEFZV0gvQUtQZXZjby91aWtNa29vb29B NXp4OE0rQ05SSHRILzZOU3ZEMmpOZTZlTjEzZURyOGY4QVhQOEE5R0xYakx3MUxkbWF3cHVVVFAy R2tLR3JoaXBqUjBjeUIweXJ0TklWcXdZL2FtbEtkeGNoWHdhTnRUYktVUjBYRGtLMncwb1ExWkVk U0xGVTh4U3BsUVJtcFlvam1yU3dWTkhCVU9SdENpN2pJb2pWNktLaUtIRlcwajRybm5JOUNsU0NO QUt1UmdDb1F1S2tCeFdMTzZDc1NNUUtpWndLYkkrS3F5UzR6elNVUnluWWtsa0dLb1R5OWVhSlp1 T3RVSlpmZXRZUU9TclZHVFM4bXFVc21hZExKNzFVZDY2WXhQT3FWTGtjckdxeE5TdWNpb1NhMVJ5 U1kxalREVGo2MDAxUm1OTk5OT05OTkFEVFNVcHBLQUdtak5CcEtBSEtmbXE1QzVGVVIxcWRHeFdj MWNwTTFvWmlPOWJGbGNkT2E1cU9URmFOclBqSE5jRmVsZEc4SkhhV1Z5T09hM2JlNkcwYzF3OXJk WXh6V3piWG52WGg0akRuZFRxSFl3WENtdEdLWlN0Y25iM2ZUbXRhM3VjanJYa1ZxRmpzaE0ydzRO TGtWbnBMbXJLTm11T1VMR3lZNlFBMVZrakJxMDNOUk11YVVXSm1aY1FqWWF3cnkzem5pdXBsanl0 WmR4YjU3VjIwS3RqR2NUakx5MDY4VmlYVm9lZUs3aTR0TTlxeUxpeTY4VjdGREVXT09kTTRPNnRH NXJNa3RYeWE3ZTVzT3ZGWmt0anowcjFxV0swT1NkSTVKN1o2cnRBMmE2ZVd5eDJxbkphWVBTdXlH SXVaT21ZWGt0U2VVMWE3V3VPMVJ0YisxYktxVHlHWjViVWVVMWFJZ3A0dDZQYWk1RE1FTFU4VzdH dE5MYlBhcktXZWUxUTY5aCt6TVpMWjl3clN0clZ1SzBJckhKSEZhbHRZOU9LNXF1SjBOWVVpbGJX YmNjVnUyVnBqSEZUMjFqMCtXdGEzczhZNHJ5YStKdWRkT2tTMlZ2MHJlZ2lVSUtwVzBHM0hGYVNq YWdyeEs4K1puYlRqWW1qMmlyS3lvcTFtTkp0cUY3cmFEelhQN055TmVheFp1cmhSbXNXNnVnTzlS M2Q1MTVyRHU3M3J6WG9ZZkRuUFVxa2w3ZDllYTU2OHVNNTVwMXpkNXp6V1JjM0djODE3ZUhvV09H cFV1VjdtWWx1dFVKSkNhZE5KbHFyTzFldkNGa2NjbVJ5TVRVVk9jMHl1aEdZVVVVVXdDaWlpZ0Fv b29vQUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnRDFUNEIvOGoxZS85ZzJUL3dCR3hWOUUxODdm QVA4QTVIdSsvd0N3YkovNk5pcjZKb0FLS0tLQU1ieGNQK0tPMW4vcnlsLzlCTmVlZUp1SWZDZi9B RjUvKzBVcjBQeGQvd0FpZHJQL0FGNVMvd0RvSnJ6dnhOL3FmQ2VmK2ZQL0FOb3BRQlVYN29ySzF2 OEE0OUpmOXh2NVZxSjkwR3NqWCtOUHVQOEFyazMvQUtDYW9Sd3BkZldrT01jVm4rWWZXcEVsSVBl dHVZVm1UbjJxSWhqVTZqSkh2VXlvQWVCVHRjUlFNVEhxS1o1REhzYTFkZ0ZSbWx5QVo0Z1BURlRx dTBZcVluSGFvejFvNWJESEpLQjhwT0tmNXkrdFZISHpWRXhOSE5ZQytaVjlhWVhVOTZvRjhVMFNI UGVwNXdzWDI2VkM5SkZJV09LbmpUY2FlNEZYWXg3R21HRnY3cHJVQ1k2aWtLaWprQXkvSWJQM2Fl c09UelYxc1V4angwcGN0Z0lnZG5OVExNUFdvVDB4MHFFakZGN0FYVE1wNzBobFgrOVdleHhUTjVw YzRXTkFsVDBOUnQxd0txcklSM3F3RHVVVVh1RmlJZ2s4Q21tTnZTcjBjWUE2Vko1WTYwY3R3TXd4 TjZVaXdzRDByU1lDbzJPS1hJQldXUFlLa1NUeXo5YUhxSmhrMGJETFFuWDFwREt2clZJNUZSa25Q ZWptQ3hlTWlrNHpUV3dWcW1DYWZHNTNZN1VyZ1MxSHllbFM0NXhVNlJBZHFkcmlLSmpiMHBDakR0 V2w1WUZSc0JSeURLSWpZbnBVbTNhS21QU28yNjByV0M0cXk0R000cVlUQWQ2cU5UZW5lbHpXQWJS UlNkNmtaSXRQQTVwaTA4VlNFeHdxUlRVWXA2MVNBbmpxd283MVhpNjFaVVZvaENsZU0xUm0rKzFY MjRVMW55L2VOS1lJcHRuY2FURkszM2pTVmdNZXRUS09haFRwVXkxU0FlQjZVNGNVMGRLVmFwQ0pW TldJNnJvTTFZanJSQ0pnS1pNdUltK2xTTDBxS2Y4QTFiL1NxZXdGSTlNVlNKNTVxNzYxUmJ2V0Vp a09CcVZCVUs4MU9ucFNReVpSVHgxcGkwL3ZWb2tlcHFSVG1vaDFxUk90V2hGaE9ncVFWR25TcFJX aUFobSs0YXo3bklSYTBKdnVWUW4rNEt6bUJUenpVcVZEM3FWT29yRW9zSUtsQzFHblNwUldxSkhD bnFhWjNwdzYxU0FtU3BSMXFKT2xTcjFxMEE3Rk1oR05RdHgvMDBYK2RTSDd0UncvOGhDQS93RFRS ZjUwcGJDUjczb0gvSVBoL3dCd2Z5ck44Y0QvQUVPei93Q3VyZnlyUzBEL0FKQjhQKzRLemZISC9I bFovd0RYVnY1Vnlsbks2ai95STJoZjloWmYvUjcxN2xIOTBWNGJxUDhBeUkyaGY5aFlmK2ozcjNL UDdvcERKS0tLS0FNUHhndTd3cGZEL3JuL0FPakZyeVY0YTllOFZLRDRadkIvdWY4QW9hMTVlMFZj OVYya2VsaEljMU4rcGx0RlVMeDRyVWFHb1doOXFsU0xsU013eDB3cFdpWWZhbUdDcjVqTDJKbjdP YWNzZFcvSTlxZXNOSE1DcEZRUmNWTXNWV0JEVDFqeFdia2F4cEVhUTFPa05LcTFLT0t6Yk9tRUVo eVJDckN4OFZYRDRwM200RlE3blRGcEVwQUZNTFlxQjV2ZW9IbTk2T1VUcUpFc3NtS29UUzR6elJM TjE1cWxMTDFyV01EbHFWUkpacXB5eTlUUkkvTlZuYXRveE9DcFV1TWtrcUF0VG1OUkU1clZJNXBT RVkxR2Y2MDgwdzFSbUlhYWFjYWFhQUdtbW1uR21tZ0JwcERTbWtvQWFhYWFjYWJRQW5lbkJxWWFN MG1CTXNtS3R3ejR4V2ZtcFkyeFdVNDNMVE55QzV4am10TzJ2T2V0YzNISmpITlhiZWZCNjF3MWFL WnZDWjJWcmQ5T2EyN1c1NEhOY1JiWFdNYzFyMjk3akhOZVBYd3gyVTZoMmNFd1BldEdHUUh2WEhR WC92V3BCZjhBVDVxOG10aDJkY0toMCtRZTlKZ2V0WXkzMmU5VExkNTcxeHVqSkczT2pSWkFWcXBM Q0RTQzR5T3RJWk0wbEZvTHBsV1cxQnJPbnN4eld5ZWFyU1I1cmVGUm9pVVVjM1BZZzlxeTU3RDJy ckpMZlBhcVUxcDdWM1U4UTBZU3BuSHoyV08xWjAxbnowcnNwclBQYXFFdGp6MHJ2cDRrNTVVamtu dGZhcXNsc2ZTdXNld1BwVmFUVC84QVpycmhpVVpPa2MwdHNmU3BGdHZhdDhhZjdVOFdIK3pWdkZJ U3BHSkZhODlLdlEyZWUxYVVkamp0VnVPMHgyckNwaVM0MGlqRFk1STRyVnRySWNWSkhiNHEzR3Uy dUdwV2JONHdKN2F6RmFDV3FyNlZUamsyMU1ibkhldUdmTTJieHNpK2tTaW55YlZUcldVYnpIZW9a ci81ZnZWbXFNbXkrZElzM0VvWFBOWlZ4ZFl6elZhNXZ1dk5ZOXplWnp6WGZSd3pPZXBVSnJ1ODY4 MWgzZDUxNXBMbTZ6bm1zbTVteUR6WHNVTVBZNHFsUUpiclBlcU1zK2FZOGxWM2JOZW5DbWtjemtO ZVRKcGhha2JyVGE2RWpLNEUwbEZGVUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVV VVVBRkZGRkFIcW53RC81SHE5LzdCc24vQUtOaXI2SndhK2R2Z0gveVBWNy9BTmcyVC8wYkZYMFRR QVVVdEpRQmplTGYrUk8xbi9yeWwvOEFRVFhuZmliL0FGUGhQL3J6L3dEYU1kZWllTGYrUk8xbi9y eWwvd0RRVFhuZmliL1UrRS8rdlA4QTlvcFFCVFQ3b3JJOFFmOEFJUHVQK3VUL0FQb0pyWVQ3b3JI OFFmOEFJT3VmK3VUL0FQb0pxeEhsN0dsUmprWXByZGFkRDk2Z0xtakVQbUZYQmlxY1orY1ZjSEly b2pzU0kxUXRVelZBOURBakpwaHB4cHRRd0dzS2djVk8yYWhjVkxHVjI2MHpOT2JyVEt6R2llM09a UHdyU2dIRloxc1BtcS9iOTYwZ0psbkZSTnhVcDZWRTlhaUlYcUpqVWoxRWF6WUNIcFVUVkoycGpW SXlGeFVKTlRQVUxkYXpZMEptcmtQM0JWTVZjaSs2S3FJTTBZd05vcFNLU1BvS1ZxM1JKQTlRTlU3 OUtydFVNQmhwcDZVNDBoNmNWQTBSTlVUZGFsYW9tcUdVSUtkSDk4VTJuUi9mRkFNcy93QVFxK29C RlovOFlyUWo2VnJBa2F3cXU1NjFaYXFyOWFiQWlZMHluTlRlMVF4aUdveU9ha05SMUlEYUtQem8v Q2tNY3RTQ29nS2VEUUprbmVuaW1MVXlpclFpU09yQzFYVTRxVU9CMXEwMEZpVW5pcUV2MzJxdzBv QjYxV2M1WTBwTzRKRlJ2dkdrcDdJY25pbTROWldLSEx4VXkxQ3RQQnhUUWlZVTRERlJxYzFLZ3pW SkNKRUhOV0UvblVLOFZLRFdpRVRDbzV1WTIrbEc4QWRhaWtjRlNNOG1tMkJYTlVXSEpxOVZka0k1 eFdVaWtSTDE2Vk90UmhlZWxQRlNNbVdwQnpVQUpGVEp5TWl0RVNQVVZLb3BpRGlwVnFrSWxUcFVt YWlCeFNsZ0t0T3dDVGZjTlo5ejl3VmNkd1JpcTBveXZTb2xxQ0tPS2tRVXBRanRTcXBGWldLZXhN bFNpb0JuMHFSU2F0RWt3RlBVVXhlZ3FWUnhWb0I2VktLalduWnhWb0NUUEZNaC93Q1FoQi8xMFgr ZElXR0tMWTV2NFA4QXJvdjg2bVd3STk4MEgva0h3Lzdnck44Y2Y4ZVZuLzExYitWYVdnLzhnK0gv QUhCL0tzM3h4L3g1V2Y4QTExYitWY3hSeXVvLzhpTm9QL1lXWC8wZTllNHgvZEZlSGFqL0FNaU5v WC9ZV1gvMGU5ZTR4L2RwREpLV2twYUFNcnhNTStIYnNmN24vb2ExNXkwVmVqZUptMitIYnMvN24v b2ExNTBaeFhIaVBpUFp5KzNzbmZ1UXREVWJRMU9acVkwd3JKWE94cUpXTUZOTUZUbVVVbm1pbmRt ZkxFcitSUUlmYXB2TnBQTm8xRGxpTUVOSVk4Vko1MU1hYjZVYWo5MGFWSXBEeFNOTFVUeTBXSmNr aHpOZ1ZFMHVLaWVVZXRWbms5NnRSTXBWYkU3emU5VjNtOTZnZVNxN3ZXaWdjOHFwTEpOVldTV21N MVF1ZWEwVVRtblVZTS9OUk0xSTNXbUd0RWpCeUVKcGhwM2FtMHlCRDBwcHBUVFRRQWhwcHB4cHBv QWFmV21tbkdtbWdCcHBEU21rTkFEVFRUVGpUYUFFTk5wVFNHZ0JNMDVXeFRLU2xZWlpXVEZUUlQ0 UFdxR2ZlbktjR3M1UVRHbWJjVjFqdlY2Rzl4M3JuVWYzcWRKTWQ2NWFsQk0yak02eUMrOTYwWUwv QU42NCtHZkhlcjBWemp2WG4xY01qb2pVT3lpdnMveFZlaXU4OTY0K0c3eGptdEdDOHgzcnpxdUdO NDFUckk3akk2MVpTVE5jMURmZTlYb3I4ZXRjRlREczNqVU45T2Fkc3pXWkZxQTlhblhVVjlhNVpV NUkyVWtXVEJtbzVMWFBha1hVUjZpaHRSWDJxVkdhSzkwcXlXZnRWVjdIMnE4Mm9EMUZRdGZEMnJh TG1RMUV6M3NQYW9IMC93RDJhMG12bDlxaWE5WDJyYU02aERVU2dOUC9BTm1sK3dlMVhQdGc5cVB0 bzlxdm5xQzVZbFVXT08xUEZwanRVeHZSN1V3M29wWG13dEVUN1BnVTFseFExOE1kcXFTM285YXFN Wk1UYUp5KzJxOHR4anZWT1c5SHJWR2E4OTY2SVVHektVeTlMZVk3MVNuditNYnF6WnJyUGVzK2E1 ejNydXBZWXdsVkwxeGZlOVpjOTU3MVZtbXozcWhMSm52WG8wc09rYzhxaGFsdXM5NnBTelp6elVM TlVMR3V5Rk5JeGNoNWVveTFNL0UwbGJwRVhGSnBLS0tZZ29vb29BS0tLS0FDaWlpZ0Fvb29vQUtL S0tBQ2lpbHhRQWxGT0Mwb1NuWVZ4dEpVZ2lwM2ttbnlNT1pFTkxVMzJlbkMyTlY3T1F1ZEhwZndE LzVIcTlQL0FGRFpQL1JzVmZSWGF2bnY0RVJGUEc5NGYrb2Mvd0Q2TmlyNkQvR3BsR3pzeHAzQ2lp aXBHWTNpNy9rVHRaLzY4cGYvQUVHdk8vRS8rcDhKL3dEWG4vN1JTdlJQRnY4QXlKK3Mvd0RYbEwv NkRYbmZpZjhBMVBoUC9yei9BUGFLVUFVMCs0S3lQRUgvQUNEcm4vcmsvd0Q2Q2ExMCs0S3lOZjhB K1FmY2Y5Y24vd0RRVFZDUEwyRkxHRHVHS2VVSk5QU01ramlyNVFMY1gzbHE0RFZKZUdITldGY0h2 V3NTU1JxaGVuazU3MDF2ZW1CQzFNN1ZLUm1vMkdLaGdSdFVUKzFQYzgxRTJUVWpSQS9YcFRLbUs1 cEFoejByT3d4MXZrTldqYm5yVk9KQ3JkS3N4TnQ2MXJGQ1piUFNvbW9EOFVoSU5hQ0lXcUk1cWRz Vkd3cUdCRWFZMVBQU29tTlFNamFvVzYxTXdwbXpJcUdob2pxNUQ5eGFnV01udFZoUnRVVTRqTkNN L0tLVnFyeHlBZ2MxSnVIcld5Wk5oa25GUU5VN2M4MUdRQ2FsZ1FFVTA4Q251TVZHL0ZRQXhxaWFu bW1FR29ZMEpUby92aW00TlBqVTdnY2NVREovNGhWOUQ4b3FoL0ZWaEpCNjFwRjJKSm1xdXdxVXVQ V296Vk5nUU5US21ZVkV3d2NWRmhqQ1JpbVVySG1tMURBc2lKU2FlSVZwcW1wNCthdElSSDVDK2xN ZUhISUZYUUthNi9LYXJsQW8vZEdhWVpqbWxmN3BxR3M3alEvelc5YWNKVzlhaTcwOWFWeGo5ekdu citOTkZQSFhOVUlrQ2hsMjlxY3NLMHhUVXlWVmhBSUVKNlVHM1dwMUhlbmxjaXJVUU04eGVXYVRm c3F4Y0RBWEZVcCtncUhvQXBuTkFtZjFxdlQxcUxqSnhLNTcwNEVsczB4YWtXcXVBNGZlcWJhckRt b2FrVTFTSkhpRktjTGRjOUtWS21VVlZndVYydHhVV3p5emlyNUdhcXpqRW40VTJyQVFOTHNHQjFx UHoyRk1uT0pEVVhVMWsyVVdoTzU3MDRTTlZkUFNwMXBwZ09Vbk5UcUFUelVZRk9IRlVTU2VXcDdV NFFwbnBTS2FsV3FTQVo1QytsTmFEMHF5QlFWNDRxdVVDa0R0cGp6a0hpbnk4QnMxUkxWbEoyR1dQ dERlOVBFeis5VkZxZEtGSUNYZXpWYXNmK1B1RFA4QXowWCtkVmxGV3JNZjZaQi8xMFgrZFYwRWUv NkIvd0FnK0gvY0g4cXpmSEgvQUI1MmYvWFZ2NVZwYUFQK0pmRC9BTGdyTjhjZjhlVm4vd0JkVy9s V0JSeXVvLzhBSWk2RC93QmhaZjhBMGU5ZTR4ZmRGZUhhai95STJnLzloWmYvQUVlOWU0eC9kRkla SlJSUm1nREY4WE5zOExYcmY5Yy8vUmkxNVo1OWVuZU56dDhIMzUvNjUvOEFveEs4ZTg0MWpVamRu ZGhxbkxHeHBHZW1tYXMvelRSNXRaOGh2N1l2ZWQ3MDB6VlNNdE44MDArUVh0aThacVR6ZmVxUG1V bm0wdVFYdFM5NTJPOU1hZmpyVkl5KzlNYVUwK1FQYkZzemU5UnRONzFVTWhxTXlHcVVETjFpdzB2 dlVMeVZBem1vMmMxU2laU3FrclNWQzcwd3NhalkxYVJrNWppMVJzYVFtbW1uWWk0aHBwcFRTR21T Tk5OcDFOb0FTbUduMHcwQUlhYWFkVFRRQTAwMDA0MDAwQU5OTlBlbkdrb0FhYWFhY2FiUUFocHBw VFNHZ0J0SlMwMDBBRkFOSWFiUUJLR3hUeEppcTJUU2JpS2x4S3VhS1RWWlM0eDNySERtbmlWcXhs U3VVcEcvSGQ0NzFiaXZjZDY1bFptSGVwMHVHOWE1NTRkTTBWUTZ1Tyt4M3EzSHFHTzljZ2wwM3JV eTNqZXRjazhJalZWVHNvOVN4L0ZVeTZsL3RWeHEzcmV0UEY2M3JYUExCbzFWWTdJYW4vdFVwMUwv QUdxNDhYeit0TyszTjYxbjlTUlh0anF6cVA4QXRWRzJvZjdWY3Q5dGIxb042M3JRc0dnOXNkTWIv d0QycWFiL0FONjVyN1lmNzFIMncrdFY5VUY3VTZUN2Q3MG4yNzNybS90WjlhVDdXZlduOVZGN1U2 UTMzdlVadi84QWFybmpkbjFxSnJ0dldxV0VGN1U2SnIvL0FHcXJTWDMrMVdFMTIzclVEM1RldGF4 d2lKZFUyWkwzM3FwTGVlOVpMM0xldFYydUdycGhoa1pPb2FVdDFudlZPUzV6M3FrOHpWQTByWnJw aFJzWk9aY2ttejNxczcxQ1hOTUxHdDR3c1EyU0ZxWVRUYzBWYVFyaFJSUlRFRkZGRkFCUlJSUUFV VVVVQUZGRkZBQlJSUzRvQVNpbHhSdE5Pd0FLZUJTS2g5S2xXTTFVWXNsc1FMVXFwN1U1WW1xeEhD YTZJVTdtTXBrYXhWS3NGV1k0VFZsSWZhdXVGQzV6eXFsSmJmMnFSYmIyclFTRVZNc0lycWhoa1l1 c2RuOEZZZkw4WTNaLzZjSEgva1NPdmRhOFkrRVNCZkZkMWovbnhmOEE5RFN2WnE4ckd3NUt0anV3 MHVhRndvb29ya09neHZGMy9JbmF6LzE1Uy84QW9OZWQrSi85UjRUL0FPdlAvd0JveDE2SjR0LzVF N1dmK3ZLWC93QkJOZWQrSi84QVVlRS8rdlAvQU5veDBBVTArNEt5OWJBTm5LUDlodjVHdFJQdUNz dld2K1BXWC9jYitScTF1STRJd29PMUp0QUhGUGFveWEzSkdIcFVJWmw2Vk5VVENwQWFabkZOODlx YTR4VUxHb2NoMkxLM0J6eWVLbERidWF6dzNOWElUbU9tbmNaT3NPN25GUDhBSVhIU3BZMU8ybmtj Vm9rU1Z2SlQwcHBpUWRxbWVvbU5Ld0RINlZDNXdhbEp6VWJDcFl5UHpYQTYwMHp1TzlLd3FGK0to c0VQKzBObXBGbnp3VFZQTlBSL21IMXBKanNYTnU0NEZTTEF1T2xKRU15Q3JZWEZheFJKWDhoQjJw cGhRVlphb0c0b3NNajJLdlNvMjZtbnNhWWFsb1RJc2xUa2RhUXlzQm5OT05Sc0tobExZUFBidVRR Sm16MU5RbWtIRks0RnZ6TjlPVk4vMHFDRG5OWGJaY2hxdU9vbUlJRlBha01DaXJSR0tqY1ZUaUJY TUtEdFRTQUZJRlBZMUVUVWdOeHhpbzhsT2xTSHBUR3FXQ0dtVnFUelg5YWFhU3BLSkJLd1BOTzNi aG1vYWtUN3ROTUNSWXQzSnFYeVJVa0M1akZUQUFEcFZxSkpSVWMxWmk3VldYclZtS2lJRmhhYkx3 djRVNFUyWGxmd3Ezc0l6WkI4cHFHcHBDTmxRMWd5a0ozcVZhaTcxSXRJWk1CUzAwR25WWWh3cVZL aUZUSlZJUlpqNkNwUlVLZEttQjRyUmJDS2x6MnFoUDBXcjkwT2xVSisyS3ptTWhwNmRLWlQwckla T2xTaW9scVVWYUVMM3B5MHp2VDFxa0ltanF3bFY0eGlyQ2RLMGlBODlLcDNIK3MvQ3JsVTdqL1dm aFRrQlF1UDlZMzBxSmV0UzNQK3NQMHFJY0d1ZDdsRXlkYW5XcTZWWVdxUWlRVTREbW1pbmQ2dENI clU2VkF0VHAwcTBCTUtSdWxBb2JPS3JvSW95L2RhczVoODFhTTNScXoyNjFoSXBEa3F4SFZaT3RX WXp4UWdaT3RXYlRIMjJEL3JvdjhBT3F5MVl0T2IyRC9yb3Y4QU9yRWZRR2dmOGcrSC9jRlpmamtm NkhaLzlkVy9sV25vSC9JUGgvM0IvS3MzeHoveDVXZi9BRjFiL3dCQnJBbzVYVWYrUkcwTC9zTEQv d0JIdlh1TWZUOEs4TzFIL2tSdEMvN0N5LzhBbzk2OXhqKzZLUXlTaWpORkFIUGVPK1BCV29uL0FL NS8ralVyeGJmWHMzajg0OEQ2aWY4QXJsLzZOU3ZFTjlTMGFSbFlzK1pSNWxWdDlHK2x5bGM1WTMr OUp2OEFlcSsrazMwY291Y3NiK0tidnFEZlRkOVBsRG5KeS92VFMxUTc2YVdvNVE1eVV0VEMxTTNV aGFpd25JVW5qdlRDZUtDYWFUVHNUY1EwdzBwcERUSkcwbEx4U1VBTnBLV2tOQURhYlRxYlFBaHBo cC9hbW1nQnBwcHB4cHBvQWFhYWFjYWFhQUdtbW1uR2tOQURUVFRUalRUUUFocHBweHBwb0FiVGFk VFRRQTAwbEthU2dCcHBEU21rTkFDVXVlYWIzcENhVmdKUTFQVjZyN3FOOVM0akxna3A0bDk2b2Va UjV0UTZaWE1hUW05NlVUKzladm5Vbm4xUHNoOHhxQzQ5Nlg3UjZHc243UjdtajdSUzlpUG5OWDdR ZldrTng3MWsvYVBlZzNGTDJJYzVyZmFQZWo3Ujcxa2ZhS1B0RkhzUTV6VyswZTlIMmozckorMGZX ajdSOWFmc1E1elZOeDcwd3orOVp2bjBlZjcwZXlEbUw1bTk2amFXcVhuVW5tMVNwazh4WmFTbzJl b1RKU2JxMFVCWEhzYWpKcE0wbFZZUXRKUlJURUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVV VVVBS0JUZ0tBS2VGcTBpV3hWVE5USkZtbGlUTlhJb3MxMDA2VnpDYzdFS1c5VHBiKzFYSTdlck1k dFhkVHd4eXpyRkZMYjJxd2x0V2dsdFU2MjFka01NYzhxeFJTM3FZUTRxOHR1S1ZvY1YwcWhZeGRX NVNFZUtkakZXR1RGUk1NVStXd3IzTzUrRW4vQUNOVjEvMTVQLzZHbGV5VjQxOEpQK1JzdXY4QXJ4 Zi9BTkRqcjJYaXZuY3cvakhzWVA4QWhCUlJSWENkUmplTGYrUk8xbi9yeWwvOUJOZWQrSi85VDRU L0FPdlAvd0JvcFhvbmkzL2tUdFovNjhwZi9RVFhuZmlmL1VlRlArdlAvd0JvcFFCVGorNEt5OWEv NDlKZjl4djVWcUo5d1ZsYTEveDZTLzdqZnlxMXVJNFJxaU5TdFVacmRramFZdzRwMU5ibXBBZ2Zw Vlp2clZtVHBWWnF6WlNHRHJWK0FZanFoNzFmZ09ZNmNOd05DRS9MVG1wc1l3dE9QU3RrUVF2VUxB MU0vZW9XcVdNanBEU2tZNXBEVXNDTnFyU0RtckRkS2dlczJORUpwMFErWVo5YWFhV1A3dyt0U3R4 bWxGL3JCaXJ3KzdWS0hCa0ZYZTFkRUNSalZYZXJEZEtydUtHQkEzMHB2YW5OVGUxUUZoclZFOVN0 VVRWREdpRnV0SlN0MXBNMUJSTEIxTlg3WE9HK3RVWU85WDdYbzMxcldCTExKNXFDVHBVNXFDVHBX akVWbjYxR2FsYW9pS3pZeEthYWNlbE5hcEdSTlRhYzFOcUFDcEUrN1VkU0o5Mm1obDYyenNBOTZu eFVGdndnTlRaK3Rib2xsSlJ6VTZjZHFwK2R6VHZ0SkhRVm1tT3pMKzdpbzNmNWFxL2FDUlRUSXpI RlBtQm9SaDh0UTFZR1R4U21BSHBVQWl0VGxOV0JiVWZacU9VWkdEelR4UVlDdEtCaW5ZUklvcVpC elZjeUJmclNmYWFwTVJlVTRwNWJpcUF1alFiazFYTUZpYWM1QXFwTU9CVWdjc2VhY3FCeHpVdlVD bGpCcHkxYSt6aWxGcm1wNUJrS21wRlBOUDhBc3VLUXhGR3FraEMxS2dxTURtbGFVTDA2MHdMSzFL cHFqOXF4U2k2elRVZ3N5OFdxck4vcktqTnlXb1Z0M0pwdDNFVjV4bVRwMnFMYnpWL3l3NDVwdjJY bmlvNVJsVmFsVTFPTFNsK3pVS0xBYWhxUWRhajh2YWFrVTdUVkNKRnFWZUtxRzRBcFJkWTZVN2dY UWVhUXNLcWk2cHJURnZwVmN3RG41RFZTWkt1Z1pvTUNtb2NiaktLcnowcVplS25GcU0wNFd2YWhS QWpCcTNZODNrSC9BRjBYK2RWemI3YXNXSXhld0QvcG92OEFPcTZBZS82Qi93QWcrSC9jSDhxemZI UC9BQjVXZi9YVnY1VnBhRC95RDRmOXdmeXJOOGNqL1FyTC9ycTMvb05jNHpsZFIvNUVYUVQvQU5S WmYvUjcxN2hIOTBWNGZxSC9BQ0l1Zy84QVlXWC9BTkh2WHVNZjNSU0dTYzBVVWZXZ0RtdmlEL3lJ MnBmOXN2OEEwYWxlSFY3ajhRZitSRzFML3RsLzZOU3ZEcUFERkpTMGhvQVEwbExSUUEyaWlrb0FR MGhwYVNnQnZORkx6U1VBTlBTa05PcHA2VUFOcERTbWtQU2dCdmFrcFQwcEtBR250VGFjYWJRQTJr NzA2bTBBTjlhYWFmVFRRQTAwMDA0MDAwQU5OTk5PTk5OQUNHbTA0MDAwQU5OTk5PTk5OQURUU0du R21tZ0J0Tk5PcHBvQWFhU2xOSlFBMDBocFRTR2dCdElhV2tOQURUU1VwcEtBRXBwcDFOTkFDR2tw VFNVQUpTVXRKUUFsSWFXa05BQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFV VVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZLS0FERk9DMEFVOUY1cTFHNUxZOUk4MVlTRFBhblF4NXEv RERtdTJsUnVjMVNwWWlpdDZ1d3dlMVRSVzlYWW9LOU9qaHpocVZTS09IaXJDUlk3Vk9zT0JVcXhW NkVLTmprbFVJMVRGS2VLbUNZRlY1T0sxY2JJelR1TDVtTzlSdlA3MVdsa3gzcXE4L3ZYTk90WTNq VHVXM3VQZjlhZ2U0OTZwUFA3MVhhNDk2NDZtSU9pTkU5UStEc3UveGZkai9BS2NIL3dEUTByMjJ2 QnZnbEx2OGFYZy82aDcvQVBveU92ZWE4WEZTNXFsejA2RWVXRmdvb29ybU5qRzhXLzhBSW5hei93 QmVVdjhBNkNhODY4VC9BT284Si84QVhuLzdSU3ZSZkZ2L0FDSjJzLzhBWGxML0FPZ212Ty9GQS9j ZUUvOEFyei85b3BRQlRUN2dyTDFyL2oxbC93Qnh2NUd0U1A3Z3JLMXc3YktZK2tiSDlEVnJjUndy Q295T0taOXBGT0VvYXQ3b213MDlLaVkxS3k1Tk5XRGRVZ1YzcUJobXIvMmJOSjlsQTRxZVZqS0lR NDZWYmlHRTRxUVc0QnpRUmc0N1VjdGdMRWJmTFR5UWFwZVpzTkw5cHErWVJhYkdLaFlWQ2JyRko5 cHpTdUZoN0NvMk5QTHFSeFRDcGZvS1F5Rmp4VVRjMWMrekUrdEo5azRxZVZnVU52dFQwWERDcmYy WUNsRVNyemlseUJjZEZ3NHEwR3FreHdNOTZRWEJIV3RFN0NMckdvbUhGUUc2cHYycWptSFlrWmFq TkFuRE56UVNEbkZTRmlOalVUVk9JaXhwZnN4cWVVWlNJelFCVncydEo5bnhVOG95R0VZelZ5M2JB TlJGTnVNVTNjVWJpcldnbVg5MlJ4VWJkS3EvYVNLUTNKcDh3ckV4RlJzT0tZTG4xcGZNRExVM0dO UFNveWFmNjBMQ1g2MHJBUWtVMzhLdGZaamltbTJwY295dlVpZmRxUVFBYzBqQUE4VVdBc1JQaU9w Zy9BcWdIS24ycHd1RFZxUWl2aWt4UzBWa01jb3B3SE5JdFNDcVFod3FSV3FJVTlhb1JZV3BRS2hq cXd1S3RBTlpQYXFrZ3d4Rlh6d00xUWxPWkRSSUNveDVOTnBXKzhhVEZZM0dQVVZJRnpURTZWS3RO QXh5akZTSlRNVTVhb1JNcDU3MU1nelZkZXRXSTZ0Q0pNVkZLdjdzMVlVVXlmaU5oN1ZiMkFvVlVM OG1yZUtvc09UV0VpaHluTlNxS2hUaXAwb1FNZUY1cVZSaW1xS2YzcTBJZXB4VXFubW9SMXFWS3BN Uk9vNHA1WGltTFVvclJBVjVWd3ZTcWM1d29xL1A5eXM2NUdVRlp6QWdMZWxLcDVxS3BFNjFqY29u VVZLb0ZNU3BWRmFyWVE0VktwcUx2VGgxcWt4RTQ2MDhmalVTZldwbHEwQWhXa2c0MUNEai9sb3Y4 NmxxT0htL2cvNjZML09sTFlTUGZOQS81QjhQKzRQNVZtZU9mK1BLeS82NnQvNkRXbG9IL0lQaC93 QndmeXJNOGMvOGVWbi9BTmRXL2xYS1djdHFIL0lpNkQvMkZsLzlIdlh1RWYzYThQMUgva1JkQi83 Q3kvOEFvOTY5eGo2Q2tNZlMwZ29vQTV2NGcvOEFJamFsL3dCc3YvUnFWNGRYdVB4Qi93Q1JHMUwv QUxaZitqVXJ3NmdBcE8xRkI2VUFKU1VwNkdpZ0J0RkxTVUFOTklhVS9Xa29BU2twYVNnQkRUVFRx YWFBR21rTkxTSHBRQWhwcHBhU2dCcHBEU21rTkFES1NuVTN2UUEybW52VDZhYUFHbW1tbkdtbWdC cHBwcHhwcG9BYWFTbkdtbWdCcHB0T05OTkFDR21tbE5JYUFHMDAwNm1tZ0JwcEtVMGxBRFRTR2xO SWFBRzBocGFRMEFOTkpTbWtvQVNtbW5VMDBBSWFTbE5KUUFsSlMwbEFDVWhwYVEwQUZGRkZBQlJS UlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVTVSbWtx U01acHgzRXg2eDFQSENjMCtLUE5Yb1lLN3FWRzV6VHFXQzNoclR0NGFaREJXakRGN1Y2K0hvSG4x YW9SeFlxMUdsS3NlS21WSzlPblRzY1VwQ2hRQlNGZ0tld3d0VnBIeFdzbnltYVZ5UnBBQlZHZVVV a3MyS3o1NXZldU90WDBPaWxUR3p5OWVhejNsOTZXZVdxVFNWNDFhdHFlalRwNkVqeWU5Vm1jK3RJ ejFFV3JoblV1ZFVZSHFYd0piUGppOS83QnIvK2pZcStnNitlUGdLYytPYjMvc0d5ZitqWXEraDY1 cHU3Tm82SUtLS1BvYWtveHZGdi9JbjZ6LzE1Uy84QW9KcnpyeFIveDcrRS93RHJ6LzhBYUtWNkw0 dC81RTdXZit2S1gvMEUxNTE0by80OS9DZi9BRjUvKzBVb0FxUi9jRlpHdi84QUlQdVArdVQvQVBv SnJYais0S3lOZi81QjF6LzF5ZjhBOUJOV3hIbUpibW5vM3pkYWhhbGpHNXhRZ05KT1dGV1F1S3J4 SERDclk1cm9pU05JOUtqYXBUVUwwQVJzYWpOT2FtMURBamNacUZ4VmhoVUwxTEdRRTRwb2FsZnJV WGVzN2pMVURibXE5QXZlcysyQTMvaFdsYm10SUNaS0Z3UGFtTUttUFNvbk5haUlTY1ZHVFRuUE5S RTFtd0dtb21GVGRxallWSXlCcWpKcVZ4VUpyTnNhRkJ3S3R4OG9LcEFacTVFTUlLcUlGNUUrVVlw eFVBVTZQN29GSzFib2tnZmlvV05TeVZYYW9ZeHJHbzJHYWVhUnVsUUNJV0ZSbmlwV3FKdXRReWhC NjA1UHZpbTA2UDc0b0JrL05YQW1RS3FkR3JRVTVGYXhKR0VjVkMxV0d4VlovYW13STJOUmtacHpV MnN4a2JEbW1FYzFLd3FNMGdHMG5lbG94VWpIcUtrRlJxYWVEelZJQjFQV21DcEZGVVN5YUtySzFX anF3dGFJUTl2dTFueWo1elY0dHhWS1kvdkdwVEdpazMzalNVcmZlTkpXRDNHUFR0VTYxQWxTcWFw QVNVNWFhT2FjdFVoRWlWWmpxdXRUb2EwUWlkYWp1UHVOOUtjS1pNUjVaK2xWMEFwZHFwUDFxN1ZJ cnlheG1VSXRXRTlxZ0ZUSlVvQ2RhZjNxTmFrSE5XaENqclVxVkdvNzFLb3F4RTZkS2xGUkowcVRP S3RBeUtiN2xaOXg5d1ZvVEhLR3MrNUJLREZSTUNuM3FWQnpUZHVLZXZXc1VpaXdsU2lvRU5URDFy UkNIOTZjT3RNRlNMVmlKVXFWZXRSTFVvcTBESG5wVWNQL0FCL3dmOWRGL25UODB5RTV2NE1mODlG L25TbHNKYm52ZWcvOGcrSC9BSEIvS3N6eHp4WldmL1hWdi9RYTA5Qi81QjhQKzRLelBIWC9BQjVX Zi9YVnYvUWE1U3psdFFIL0FCUXVnLzhBWVdYL0FOSHZYdU1mM1JYaDJvLzhpTm9QL1lXWC93Qkh2 WHVFWDNhUXlTbDVwS1dnRG12aUIveUkycGY5c3Y4QTBhbGVIVjdqOFFQK1JHMUxuL25sL3dDalVy dzZnQXBLV2tOQUNjMGxMU2RxQUVvcGFTZ0JwcEtVMGhvQVNrcGFTZ0JLYWVsTFNHZ0J0SWFVMGhv QVEwMm5HbW1nQnBwRFNta05BRGUxTnBhVHZRQTMxcHBwNXBwb0FhYWFhZFRUUUEwMDAwNDAwMEFO TklhVTBob0FhYWFhY2FiUUFocHBweHBwb0FiVFRUcWFhQUdta3BUU1VBTk5JYVUwaG9BYlNHbHBE UUEwMGxLYVNnQkthYWRUVFFBaHBLVTBsQUNVbExTVUFKU0dscERRQVVVVVVBRkZGRkFCUlJSUUFV VVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBTFJTVTlSVFNCaUFWUEF2TklxWnEx Yng4MXRUcDZtVTVhRnkzanppdFNDSGlxdHRIMHJWZ2o0cjNNTlNQTHJUSklvUlYyS01Db28wcTFH SzlhbEN4d1RrT0NVOExSUzVycHNZakplRnJOdUd4V2hPZmxySXVuNjF6WWlWamVpcnNwenk0clBt bHFTNGs1cWhLK2E4R3ZWUFRwVXlLYVNxeGMwK1ZxcmsxNWRTYnVkMEk2Q2xxYVRSVFRXTFpxa2Vx ZkFQL2tlcjMvc0d5ZitqWXEraWErZGZnSC9BTWoxZS84QVlOay85R3hWOUZVaGhSUlJRQmplTGY4 QWtUdFovd0N2S1gvMEUxNTE0by80OS9DZi9Ybi9BTzBVcjBYeGFQOEFpanRaL3dDdktYLzBFMTUx NG8vNDkvQ2YvWG4vQU8wVW9BcVIvY0ZaR3Y4QS9JT3VmK3VUL3dEb0pyWGovd0JXS3g5Zi93Q1Fk Yy85Y24vOUJOV0k4dmFuUS9lelNOU29wenhUNmlOR1A3d3E0dkFxcEY5NWF0WnJhSWdhb0hxWTFF OU1DRTAybnRUS2hnTmJOUXYwcVZxaGMxTEdRUFVKNjVxWjgxR0JucFdZMFQydytiOEswTGZxYXo3 Y0VQV2pic09hMHBpWlpQU29YcVFtbzJyVmlJSDYxRWFtYW9pS3pZRE8xTWFubW1OVU1aQzlRdDFx WnFoYnJVTWFCYXR4ZmRGVXdQU3JrUUlWYzFVUm1qRjA0cFdwcU5oUlRtT1JXeUlJSktydFZoNmdh cFlFWnBEMHBUVFR4M3FCb2phb21xVnFpYW9ZeEtkSDk4VXlueC9mRkF5eC9GV2hHUGxyUC9pcThy QVZyQWtHNlZXZXJMR3E3VTJCQTFJS2N3cG5Tc3hpTlVkUFkweWt3RUlPZWxKZzFjQ3FhZUkxUGFq bEFwQlNLY090WGZKR09sUnRDTVZYTFlMa1MxTU9LaHlGWE5SR1FudWFWd0w2c29OUEVpaXN3T2ZX bERIMXBxWVdORjVjVlhadHh6VUFKTlNyUnpYQWplUHFhWnNQcFZ3WVpSVHdpazR4UzViaUtJVWp0 VHVSVjhSTDZVclJLQm5HYXJrQXBwelV5VWp4Q1BwVWJPVUhIZWpZTEZvRUNucXdyTU1yZXRLSlg5 ZUtPWUxHcDVneDFxSjVRY3JWTU1mV25MMXA4d0VuYW9Iakk3VlBVd3czVVVyWEFvQ00rbFBWVzlL dnFpK2xQOHBjOENueUFVQmtWS2h5S3ROQ3ZwVURwc09CVDViQU9UcFVvSUhlcWNrcFVGS2k4MXM5 VFJld0dtR0hyVHQ0STYxbUNSL1duQm1QZWpuRll1TytSaW9IVGV0TlhyVTZkYWU0Rkl4SDBvQ0VZ NHJRQ2crbFBFYStsTGtHVUFwcDY1QnE5NVl4MHBqUkE5cWZLSzVFTzFTZ1lxSThjOFZBMHhQclJz TXZnajFwMjRldFpZbFByVWl5TWU5SE9JMERJQU8xSmJObStoUC9BRTBYK2RVd1NhczJJLzB5RC9y b3Y4NmJkd1BvSFFQK1FmRC9BTGcvbFdaNDUvNDhiTS85TlcvOUJyVDBEL2tIdy83Z3JMOGRjV05u L3dCZFcvbFhPVWN2cVA4QXlJMmcvd0RZV1gvMGU5ZTRSL2Rydy9VUCtSRjBIL3NMTC82UGV2Y0kv dTBoa2xGRkZBSE5mRUQvQUpFYlV2OEF0bC82TlN2RDY5dytJSC9JajZsLzJ5LzlHcFhoOUFCU0dq dFFlbEFDVW5iRk9OTm9BS2JTMFVBTnhTR2xOSlFBbEpTMGxBRGFRMHRJYUFHbWtOS2VsSWFBR25w U1U0MDNGQURUMnBLVTBob0FiVGFkVGFBRzAwMCttR2dCS2FhY2FhYUFHbW1tbkdtbWdCcHBEU21r TkFEVFRUVGpUYUFHbWtOT05OTkFEYWFhZFRUUUEwMGxLYVNnQnBwRFNta05BRGFRMHRJYUFHbWtw VFNVQUpUVFRxYWFBRU5KU21rb0FTa3BhU2dCS1EwdElhQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fv b29vQUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQXFXTVZGVmlJVmNGZGt5Mko0MHpWMjNqNXFH RkswTGRLOUtoVE9Lck11VzhmU3RTQ1BpcWR1dGFVSStXdmN3OU04dXJJa1JLbVJhYW9xUmE5Q0tP WnNVaW0wNDB3bXFKUkZjSENWaVhiWXpXdmN0OHRZVjRldGVkakphSFhoMFpOeko4MVVuZXByby9O VlJxK2FxeWR6MmFjZEJydFVlYVZxWlhJMmRLUXRKUlJValBVL2dIL3dBajFlLzlnMlQvQU5HeFY5 RlY4Ni9BUC9rZXIzL3NHeWYrallxK2lxQUNpaWlnREc4Vy93REluYXovQU5lVXYvb0pyenJ4Ui94 NytFLyt2UDhBOW9wWG92aTMva1Q5Wi82OHBmOEEwRTE1ejRvLzQ5L0NuL1huL3dDMFVvQXF4L2NG Wkd2ZjhnKzQvd0N1VC84QW9KclhqKzRLeXRhLzQ5SnMvd0J4djVWU0VlWitXYzlLa1NMTENydXdB ZEtRNHhpdGxDd2lOVHRQMHFaWkEzZXE3VkVTeTA3MkVYaTZudlRTUlZCcEdGTTgxdlUwdWNDK1FE VVo5cXJKTVJnNTZWTUczQ2xlNHhqbm1veUNlMVhZNGdUdXAvbEFDamx1QmxsRG5wU0NNNTZWcG1N WTZVMHFCMm81YkJjcXBIc09lYW5qZlpRL1RGUXVLTmdMbm1EMXBDd1BlcUJZZ1lCcU15TU85SE9C b0VnMHg4WXFqNXJaNm1wRm1PY0hOTG1DeEllbFJIbnBVd1hjMktuU0ZSUW8zQXptVTAzeXo2VnFH SmU0cGhqWDBwY2dHZWtXY0RCcXdvd01WTmdEcFVUZDZMV0M1TWtvT0JUL0FEQjYxUU9RZURUZDdB ZGFmTllkaStXRlJuQjZWUzh4dldrRHRuclM1cmhZdE9NVkUzSFdsUnQ5U0pIdk9mU3BFVm1CcGhW dlN0SVFyNlVoalVEcFQ1Qm96ZHBxUkl6bk5XeWkrbE1iQVhGTGxBakhGVHBLRFVIYW95Q09ob1Rz SXZHUWV0TUpGVWl4cE56ZXRQbUhZdG5GUk9NR29RNUZTQnR3elN1QTFxWmcrbFdVaTNmTlVvaVU5 aFJ5M0dScWFuajVxdXZXckVYYXFSSk9CMnBzaWZMVDFwc3hJWDg2dDdDTTJUN3BxR3BwQjhsUTFn eTBIZW5xS2o3MUl0QU1rQTVwNEZJdnZUcXBDSEthbFExQ0ttU3FRaXdneUtrMjVxT09waFdpRVZM a1lBcWpPZWxYcnIrR3FFL1FWbk1wRU5QV21VOU9sWmpKbHhVcWlvMHFVVlpMQWRha1U4MUgzcDY5 YVlpWktzSUtyb09hc0owclJBS1Zxck9NU2ZoVndqamlxZHgvclB3cHkyQW8zQnhJZnBVWFUxTGMv ZlAwcUZldGM3S0psUE5UTFVLZGFuV3FRbVBGUEhXbWluRHJWaUpGTlRMaW9GNjFPbFdnSlFCU010 S0tHNlZmUVZpakx3RzQ3VlFMVmZsSHl0bXM5dUdyQ1pTSEthblRtb0VxZU9wUU1uVVZacy8rUDJE L0FLNkwvT3E2MVp0UCtQMkQvcm92ODYwRWUvYUFQK0pmRC91RCtWWm5qcm14cy84QXJxMzhxMDlB L3dDUWZEL3VEK1ZaZmpySDJHelAvVFZ2NVZnVWN2cUgvSWphQ1A4QXFMTC9BT2ozcjNDUDd0ZUg2 aC95SXVnLzloWmYvUjcxN2hIOTBVaGtsRkZHS0FPYStJSC9BQ0kycGY4QWJMLzBhbGVIODE3aDhR Qi94UStwZjlzdi9ScVY0ZlFBVWhwYURRQTN0U1V0SlFBVTJuVTJnQktTbFBTa05BQ2Q2U2w3MGxB Q1UwMHA2VWhvQVEwMDlLY2FhYUFFcHRMVGFBRU5JZUtXa05BRGFiU25wU1VBTjdVMDA2bW1nQkRU VFRqVFRRQTAwMDA0MDAwQU5OSWFVMGhvQWFhYlRqVFRRQWhwcHBUU0dnQnROTk9wcG9BYWFTbE5K UUEwMGhwVFNHZ0J0SWFXa05BRFRTVXBwS0FFcHBwMU5OQUNHa3BUU1VBSlNVdEpRQWxJYVdrTkFC UlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUF0V29C bXFncTdianBXdEplOFJVMk5DQmVsYU1FZFU3Y1ZxUXIwcjNNUEE4dXRJdFFMV2hFdnkxVWhGWG94 eFhzVVZZODZveDRGUEZORk9GZFNNUkdxRmpVclZBd1ByVXlIRXIzRGZMV0pkbnJXeGNBN2F4THNk YTh2R2JIZGgwWTF5Zm1xb1RWcTVIelZWYXZtNnZ4SHMwOWlNMDJuR20xenMxUVVVVVVobnFmd0Qv NUhxOS83QnNuL0FLTmlyNktyNTErQWYvSTlYdjhBMkRaUC9Sc1ZmUlZBQlJSUlFCamVMZjhBa1R0 Wi93Q3ZLWC8wRTE1MTRvLzQ5L0NmL1huL0FPMFVyMFh4Yi95SjJzLzllVXYvQUtEWG5YaWovVWVF L3dEcnovOEFhS1VBVkkvOVdLeXRhLzQ5WmY4QWNiK1Zhc2YrckZaV3RmOEFIcEwvQUxqZnlxMXVJ NFZqVVJOU05VUnJja1FqaW8yRlNkcVkyTVZJRURpcTdHckVuU3F6Vm15aEEyS3V3SE1acWdPdFg0 ZnVVUUI3RitOZmxwNUhGTWkrNVVqVjBJZ2dmaW9tTlRQVURDb1l4aDVwakNuOXFhYWtDRmhVTGlw M3FCNmhqUkVUaW5JM3pENjAwOWFXSWZOK05RVWFVSXpKVnNEaXFjUEVncThQdTEwUjJJSTI5YWhm clU3VldmclF3STJOTU5LMU43Vm13R0VjVkd3eFVyZEtpZXBZMFF0MTRwTVVwNjBsU1VUUWQ2dld5 N2xiNjFSZzcxZXRlaCt0YVFFeXh0eFVMakFxdzFRU2RLMFpKWFkxRWFrYW96V1RHSlRDS2YycHJk YVF5SmhnMDJuTjFwdFFNS2tUN3RSMUluM2FhQXZXNjVqRlM0eFVWc2ZsWDYxTWV0Ym9rb3JWaVBp b1ZGU3J4VUlDd3RKSmphYWFHNHFOMzROVUJUazRTb2FtWVpVOFZEakZaTWFFNzFJdE1wd3BJWk1Q U25Db2dha0ZVSWVLbVNtSUtrV3JRaWVQZ1ZNRGdWQXBwV2FyMkZZaHVmNGFwVGpHMnJjN1p4Vlda U2NkNnptTkZlbnBTYmVhVWNWbVVUcFVvcUFHcEZQTldTUDcwOWV0TXFaQjYxU0VQVHJWaGFnV3BS eFZvQ1VuaXFjLytzL0NyQmJpcTBweTlPV3dGRzQvMWgrbFJMd2FubVVsODRxUGJnMXp0RkxZY25X ckMxQXZGU0thcEF5WVU4VkdwcVZSbXJKSExVNmRLaUE5YWxXclFFb29QU201cHJOZ2NtcUVWWmZ1 dFdldzVyUWZrTjcxVVpDTzFZeUtReGVLbmpOUktwcVJlT09hU0c5aXdwcXphZjhBSDVCLzEwWCtk VTFOWExIL0FJKzRQK3VpL3dBNnNSNy9BS0IveUQ0Zjl3ZnlyTDhkZjhlTm4vMTFiLzBHdFRRUCtR ZkQvdUQrVlpmanIvanlzLzhBcnEzL0FLRFdBemx0US81RWJRZit3c3YvQUtQZXZjWS91aXZEdFEv NUViUWVmK1lzdi9vOTY5d2orN1NHU2lpZ2RhS0FPYStJSC9JajZsLzJ5LzhBUnFWNGZYdUh4QS81 RWZVdisyWC9BS05TdkQ2QUNrcGFRMEFCcHRMOUtTZ0ErbE42VXRKUUFsSlNucFNHZ0JPOUozcGFT Z0J0SWFjZWxOTkFDR21tbkdtbWdCS2JTbnBTVUFOcEQwcGFRMEFNTkpUcWJRQWhwcHBlMUlhQUdt bW1uR21tZ0JwcHRPTk5OQURUL1drTk9QU21tZ0JwcHRPTk5vQWFldElhY2FhYUFHMDAwNm1tZ0Jw cEtVMGxBRFRTR2xOSWFBRzBocGFRMEFOTkpTbWtvQVNtbW5VMDBBSWFTbE5KUUFsSlMwbEFDVWhw YVEwQUZGRkZBQlJSUlFBVVVVVUFGRkZGQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRkZB QlYyMjdWU0ZYcmJ0VzFINGlLbXhyV3c2VnFRanBXWmJWcVFqZ1Y3MkdQSnJibDJFR3JzZlNxY1ZY WStsZXZTUFBxRHhUeFRSVGhYU2pKaldGUnN0U2tVMHJTYXVDS1Z5dnkxaDNhOWE2SzVYNWF3cnhl dGViakk2SFpoMmM5ZEQ1cXFFVmV1bCthcWJDdm1hcTk0OXFtOUNCcWJUMnBsY3JSdWdvb29wRFBW UGdGL3lQVjcvd0JnMlQvMGJGWDBUaXZuWDRCLzhqMWUvd0RZTmsvOUd4VjlGVUFGRkZGQUdONHQv d0NSTzFuL0FLOHBmL1FUWG5YaWovVWVFLzhBcnovOW9wWG92aTcvQUpFN1dmOEFyeWwvOUJOZWRl S1A5UjRUL3dDdlAvMmlsQUZTUC9WaXNyV3YrUFdYL2NiK1Zha1grckZaZXMvOGVzdis0MzhxcENP RVlWR2FtYW8yRmRCSkhVYmMxSWVLaFkxSUVjblNxellxdzFSRVo3Vm14b2lBNXE5Qjl5cTZwVnFN WVVVNEliMkwwWEMwOXFnamI1YWtMWkZicGtrYjk2aGFwMnFOaG1wWUVCNHBDYWthb1hxR0F4elZk Nm1icFVUQ3MyTkVKcDBmM2g5YVhiejBwNkp6MHBKRkY2SG1RVmRCcWdoMnRtcklibXQ0a01lMVYz SEpxWW1vbW9ZRURVenRVekNvaldiQVkzU29tcDdHbzI1N1ZJMFJIclNVcEZBQjYxTmlpV0FkYXZX dlJ2clZLSVlCTldvR0F6V2tDUzRUeFVMODB1N0lwcmRLMEN4QTMwcUkxTzFSTU9EV2JRRE8xTmFu Vkd4cVdNWTFOcFRTVklCVWlmZHFQOEtrVDd0Q0F2Vy9DQ3BqOWFyUk5oTVZKdjhBZXRreFdLUG5I TkhudlVYYWlzYmxFd25ZMGIyUFdvMUZPQTVwM0UwU2pCTk84cFdOTXFSVFRFQXRnYVVXbzdWTWxU QmF0UkFwTmI0NlVnQlU0cThWcW5KOTlxVFZnR3RMdFVnZmVwZ3VHelVMSG1tOTZqbUdXaGN1YVh6 Mk5WMXFWUlR1QTlXSkpCcVJBQ0Rtb3dNVTljMVNFTzhoRFRsdGxOT1ExT25OVllDdUxVVXhvZGpa SFNyK00xSEt1SXo5S2ZLSmxTa2FjZ2NVVlVMWXpVTjJLTFAybHZXbkM1YjBxbXZXcFZwY3dFL25P VGluTHlLalVWS3ZGVWhEMVFNdk5BdDE3VUtjVktwcXJBUi9abHBmc3k0cXd0U0VacWxHNGlqNVd6 bWpkc05XWlJoT2xVWnpoUWFoNkFQYTRJTko5cGJOVkMyZUtjb3lhbm1HVy90TEdsTWpNT2FoVVZL b3Frd0pGcDVpVnpUQlVpbXFzSVQ3T3VhUHN5NTRxWmFrQXAyQmxacmZqaXBMTWJieUgvcm92ODZs STY5YWJCL3gvUWY5ZEYvblEwQjc1b1AvQUNENFIvc0QrVlpuam9mNkZaLzlkVy9sV25vSC9JUGgv d0J3ZnlyTThkZjhlVm4vQU5kVy9sWE1VY3RxSC9JaTZELzJGbC85SHZYdDhmM2E4UTFEL2tSZEIv N0N5LzhBbzk2OXZqNlVoa2xMU1VVQWMzOFFQK1JIMUwvdGwvNk5TdkQ2OXcrSUgvSWo2bC8yeS84 QVJxVjRmUUFVaHBhU2dCS1NscEtBRW9vbzdVQU5OSWVsS2FTZ0JLU2w3MG5yUUFocHBwM2FtbnBR QWhwcHBUU0dnQnZha3B4cHBvQWJTR2xOTlBlZ0JLYlMrdEpRQWhwaHAzYW1tZ0JLYWFjYWFhQUdt bW1uR21tZ0JwcERTbWtvQWFhYlRqVGFBR21rTk9OTk5BRGFhYWRUVFFBMDBsS2FTZ0JwcERTbWtO QURhUTB0SWFBR21rcFRTVUFKVFRUcWFhQUVOSlNta29BU2twYVNnQktRMHRJYUFDaWlpZ0Fvb29v QUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0FxN2JkcXBWZHQrMWJV ZmlJcWJHdmJIcFdwQ2VCV1RibnBXbkNlQlh1NGRuazFqUmlOWFl6eFZDRTFkalBGZXZSUFBxRXdw d3BncDRycVJreGFTbHBLWWlHNEh5MWkzU2RhMjVobGF5N2hNNXJpeFVibzZhRE9kdVl1YW95UjRy YXVJczFueXg0N1Y4N1hwYW5yVXBtWTY0cUhGV3BseFZiRmViTldaMnhlZzJpbE5KV1paNnA4QS84 QWtlcjMvc0d5ZitqWXEraWErZHZnSC95UFY3LzJEWlAvQUViRlgwVFFBVVVVVUFZM2kzL2tUdFov NjhwZi9RVFhuUGlmL1VlRlArdlAvd0JvcFhvM2kzL2tUdFovNjhwZi9RVFhuWGlqL2ozOEovOEFY bi83UlNnQ25IL3F4V1RyaHhaVG4wamIrUnJXai8xWXJJMS9qVDdqL3JrLy9vSnFoSG4zMm9pbkxO dUhXcUJKelQwZmtWb3BDUmQ2OFVxd1o2MFIvZUZXZ0swU0VWVGJxS1Q3TXVLdHNLalBGSEtCQUlV V2tJd2FlMVJtcEFqTGxXNG8rME1LSEZSTUttNHg1dW1wUHRKSnFzeHhUQTJPbFR6RE5EZnZQSFNr TVpmcG1vSURsdXRYb0FUazFhMUpJeGJERkliWmF1YmNkcVkxVnlnVlBzeWlsRWFxRFVyR295YWta RTNBNHBvbGRhZWVsUk5VM0JDbTVZVW4ycHNjMUMxUkUxTGtNdUxjWjYwcE9SbXFRTlc0dnVERk5P NFdITER1WUU1eFR6YWpwMnF5aWtnVTVsd0t2bEpLUnRrRkhrS0tzT1RVTEdsWWR4anFCVVRFakdL ZXhwckNwQVR6MkZJYmxxWTFSbXB1VVRmYURUaEx1R0tyQ25KOThVWEFtSTlxY2tHZW9wQndSVjBM a0NyU3VTVlBzb0gwcERicUt2R29HelQ1UUsvbEFVakRuaW5zVFVaNTYxSXhwWXFlS1BQYjNvWVZH UlUzR0pTZDZXaXBBZXRTQVZHdFNDcVFtTFRscHZlbnJWQ0o0dTFXVng3MVdpNmlySzFvaERqMEpy UGw1YzFvSHBWQ1VZa2FsUFlhS2JmZU5ONzByZmVOSmlzSHVNa1NwbHFGT2xTclZJQjlPV21nMDRW U0VTTDFxekdLckwxcXpIV2lFVExpbzU4K1czcGlwRnBrNC9kdDlLcDdBVU1WUlljOWF2VlNicWF3 a1VLbFRKVUNWT2xKQVRMVCs5TVduOTYwUkk0ZGFrU29nT2FsU21nTENkS2tGUm9PS2tGYW9HUnpm Y3JPdVJsQm4xclJuR0VyT3VEOGdyT1lGVFBOU29lYWhxVkJ6V0tHV1VIRlNxS2lTcFFhMVFoM2Vu TFRRS2NCelZBU3BVeTFFZ3FWUlZvQjFNaDV2NFArdWkvenFUdFVjUEYvQi8xMFgrZEtXd2ozdlFm K1FmRC9BTGcvbFdYNDYvNDhiUDhBNjZ0LzZEV3BvQS80bDhQKzRQNVZsK09zZlliUC9ycTMvb05j cFp5K29mOEFJamFEL3dCaFpmOEEwZTllM3gvZHJ4RFVQK1JHMEgvc0xMLzZQZXZiNC91NXBESktL S0tBT2IrSUgvSWo2ai8yeS84QVJxVjRmWHVIeEEvNUViVXYrMlgvQUtOU3ZENkFDa3BhUTBBSjJv bzdVbEFCMnB0TDYwbEFDR2tOTFNVQUpTVXRKUUFocHBwMU5OQUNHbW1sUGFrUFNnQnA2VWhweDZV MmdCcHBEUzAwMEFKVGFkVGFBRXBocHhwcG9BUTAwMDQ5S2FhQUdtbW1uR21tZ0JwcEtVMGhvQWFh YWFjYWFhQUVOTk5PTk5OQURhYWFkVFRRQTAwbEthU2dCcHBEU21rTkFEYVEwdElhQUdta3BUU1VB SlRUVHFhYUFFTkpTbWtvQVNrcGFTZ0JLUTB0SWFBQ2lpaWdBb29vb0FLS0tLQUNpaWlnQW9vb29B S0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBRlc0RGpGVktzUkhGYVUzWmtUMk5XQjYwNFpLeElu eFYrM2s5NjlmRDFEejZzRGNoZXI4UitXc2kzZnBXbkNmbHIyNkU3bm1WWTJMUU5QRlJLYWtGZHNX YzdIMFlvb3FoRWNvNHFoTW1jMW91TWlxN3BrVmpVanpHa0hZeHBvYzFuVHcxMEVrUEZaODhOZVhY b0hiU3FIT1R3MVRNUnJjbmg2MVFraXhYaTFxTm1lbFRxYUdjVnhUVHhWbVJLcmtjMXd6alk2b3U1 Nmo4QS8rUjZ2Zit3Ykovd0NqWXEraXNWODYvQVAvQUpIcTkvN0Jzbi9vMkt2b3FvS0NpaWlnREc4 Vy93REluYXovQU5lVXYvb0pyem54Ui94NytGUCt2UDhBOW9wWG8zaTMva1R0Wi82OHBmOEEwRTE1 ejRvLzQ5L0NuL1huL3dDMFVvQXFSZjZzVmthLy93QWcrNS82NVA4QStnbXRlUDdnckkxLy9rSDNQ L1hKL3dEMEUxUWp5OXNVc1ErWVpwRzYwc1p3MU1EU2orOHRYRjZWVGk1WmF1RGdWMFIySllqVkEv V3AycUIrOURBaUpwdE9hbTFBRFdxRjhWTTFRdlVzWlhmclVSNjFJOVJtczJORmkySHpWcFcyZWF6 TFUvUDM2VnAyNHJTbUpvc0VjVkM5VEU4VkU0clZpS3o5YWpKcVZ4elVSck5nTlBTbUVVL3RUR3FX TWhlb1QxcVo2aGFzMk5DREJxNUVNS3RVNnVSZmNGT0lNMG96OG9GRENrajZDbE5kQ1doSlhmTlFO VmlTcTdDb1lFWjVvUFNpZzlLekdpTnFoYnJVelZDM1dwWXhLZEg5OFUyblIvZkZDR3l3T0dxK25J cWgxYXRCQmdWckVrYTJlYXJ1YXN0Vlo2YkFoYjYwekZQYW1pc3hqU01DbUhyVDJxT2xZQnZTaXBQ Sk5Ia3QwcFdBWXBxUmV0QWhiMG9LbGUxTklHU0RGU0tPYWpYclRqSUZPS29SWVRpcGxOVWhPQnpU dnRJcXJoWXRsOFZUbDVjKzlJWjgwbWM4ME4zQXFzUG1OSlZwb2R3NHB2MmRxamxHUkxVaW1uQzNZ VTR3TU9hRW1BS2MxSWxSS0NEVXFIQ25OTVJLbzVxZE9LcWVjb05PRnlvK3RXbUZpNkR4VWNySHlt cXY5cEFwalRGamp0VDVnRS93cXB0NjFib2VEUFNzMnJnaW1CZzFLbkZTaTJOS0xkaFFrTVJUVWc1 cHBoWVU1QmdWU0VTS0tsV29sY0JlYVh6MXpWWEF0S2FmbmlxWXVWRk9Od0NLcFNGWWxtYksxUnVC bFJVcGxMdGdVdTNkd2FsNmdaNVhCcDZWWk50NlVDMmFvNVJqRk9LbFhta0Z1NE5LWXl1S2FURVND cEZGUnFSVHpLcTFhR1RMVWc0cXFMaGFkOXBYMXFyaUxKYW13SE4vYi84QVhSZjUxWE53Q2VLa3My M1hrSi82YUwvT2hnZS82RC95RDRmOXdWbCtPdjhBanhzLyt1cC9sV3BvUC9JUGgvM0JXWDQ2L3dD UEt6LzY2bi8wR3VVbzViVVArUkcwSC9zTEwvNlBldmNJL3VpdkQ5Ui81RWJRZit3c3Yvbzk2OXdq KzZLUXlTaWtwY1VBYzM4UU1mOEFDRDZsL3dCc3YvUnFWNGZYdC94QS93Q1JIMUwvQUxaZitqVXJ4 Q2dBcERTMGhvQVE5S1NsTkoyb0FLYlRxYlFBbEoycFRTR2dCS1NscEtBRXBwNlU0OUthYUFHbnBT R2xOSWFBRU5OcFQwcEtBR21tbnZUalRUUUFsTnB4cHRBRFRUVFQ2WWFBRU5OTk9OTk5BRFRUVFRq VFRRQTAwaHBUU0dnQnBwdE9OTk5BQ0dtMDQwMDBBTnBwcDFOTkFEVFNVcHBLQUdta05LYVEwQU5w RFMwaG9BYWFTbE5KUUFsTk5PcHBvQVEwbEthU2dCS1NscEtBRXBEUzBob0FLS0tLQUNpaWlnQW9v b29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb29vb0FLS0tLQUNwVU5SVTVhcUltVzBhcmx1 L05acXRWcTNmbXV1bFBVNTZrTkRmdG40RmEwRC9MWFAyOG5TdFdDVGl2ZHcxUThxdkExVWFwbE5V STNxMUcxZXBUbGM0cFJMR2FLYm1sRmIzTTdDbm1tRmFmU1Voa2JJTVZRbmpCclJJNHF0SW1heHF3 dWk0T3hpVHc5YXpwb1R6WFFTdzVxcEpiZTFlVld3OXp1cFZiSE9Td042VlRlQnMxMHNscDdWVmV6 NTZWNWRYQ003cWVJTzArQXNaWHh6ZWsvd0RRTmsvOUd4VjlENDk2OEcrQ1VQbCtOTHcvOVE5Ly9S a2RlODE1MVdISkt4MlU1Y3l1RkZGRlpsbU40dC81RTdXZit2S1gvd0JCTmVjK0tQOEFqMzhKL3dE WG4vN1JqcjBieGIveUoycy85ZVV2L29KcnpueFIvd0FlL2hUL0FLOC8vYUtVQVZJL3VMOUt5TmYv QU9RZmNmOEFYSi8vQUVFMXJ4LzZzVmxhNE0yVTQ5WTIva2FvUjVlUm1uS256RGlyWDJZMDlZZHZX dEZFUTZQaGxGV2cyYXFaMjhpbFdmMXJSYUNMUjZWRXdxUDdTdmVrTnd2V2k2Q3dyQ282ZDVxazBo NjhVbU1pYzRxSmlhbUtGbTRwRGJzYWhwaUtiQ21CY25wVjAyelVndGpVOG95TzNHR05Yb0RqTlFl V0VQRktIS0VISEZXdEFMdWMwMXVsVnZ0SUZIMmxhcm1DdzloVVREaWczQzBvZFdGUzJGaUkxRzFT Tm5IRk5FVE5VMkFydHpVUkJxNGJkNmI5bWFwNVJsWUx4MHExRU1JS1VRWUZPeHQ0cHBBWEZmNVJU aWMxUldiYWNHbm01QXExSVZpVithaFlZcERjcVJUZk9VMHJoWVJoVWJWSXhCSXBqTGsxSUpFYlZF d3F4NUxlbE5OdXhOVFlvZ0ZPaisrS2wrenRUbGkyZ2s5YUxBTC9BQkRGWFZmQXFqMk5PU2ZIV3JU c1NYR05RdUtpKzBVaG5VMDJ3c0RDbUhpbmVhcHBqSEpxQmpXcVBpbmxkeDRvOGhxV29GaFR6VXlE TlYxNjFZanEwSWtLREZST21FUEZXRkZKTHdwcTJnTTVpUWhxSE5TeWZjTlExZ3hvS2NLYjNwNjBE SEJlYWxGTkFwMktvVEpWcVJLZ1UxTWxXaEU2cnpTc3ZGS25TcEFLdElSU25VTGpGVlpTVnhqcFYy NjdWUW42TFdjeWtSazVOT1VtbzZldFpwakpRT2FrVWMwMWFsQXEwU3c3MU1wcUh2VWltcVFpWmFs QXpVS1ZZU3RFREdsS3J5Z0s0eFYzSEZWTGovV2ZoU1lGS1pzU0VacUxkelRyai9Xc2FpSFdzR3lp WlRVcWpOUXBWaGFwTVE1VkZTcndhWUtkM3EwSW1VMUt0UUxVeWRxdEFQeDNwcFhyVWdvYmdWVmhG Ri91dFZRdlZ1WG8xWjUrOVdNaWtTSzNOU3J5YWdVYzFZUVVrREhxUGFyZGtNWGtIL1hSZjUxWFVW YXMvd0RqOGcvNjZML090RUk5KzBIL0FKQjBQKzRQNVZsK092OEFqeXMvK3V6ZitnMXFhQi95RDRm OXhmNVZsK092K1BLei93Q3V4LzhBUWE1eWpsdFIvd0NSRzBIL0FMQ3cvd0RSNzE3aEgwcnhEVWYr UkgwSC9zTEwvd0NqM3IyK1BwU0dTVVVsTFFCemZ4QS81RWZVdisyWC9vMUs4UHIzRDRnZjhpUHFQ MGkvOUdwWGg5QUNVR2lnMEFKMnBLV2tvQVNreFMwbEFDR2tOTDJwRFFBbEpTMGxBRGNVaDZVdEll bEFEVFNHbE5JYUFFN1UybmRxYWFBRzAybkdtbnBRQW5hbW1sN1VsQUNHbUdubW1HZ0JEVFRUajBw cG9BYWFhZmFuR21tZ0JwcERTbWtOQURUVGFjYWFhQUdta05PTk5OQURhYWFkVFRRQTAwbEthU2dC cHBEU21rTkFEYVEwdElhQUdta3BUU1VBSlRUVHFhYUFFTkpTbWtvQVNrcGFTZ0JLUTB0SWFBQ2lp aWdBb29vb0FLS0tLQUNpaWlnQW9vb29BS0tLS0FDaWlpZ0Fvb29vQUtLS0tBQ2lpaWdBb0Jvb29B ZG1wNFg1cXRVa1p3YXVEMUprdERZdDVPbGFjRXRZTVVtS3ZSVFk3MTZ1SHEyUFBxMDdtL0RKVjZK cXdZWi9lcjhOeDcxN0ZDdWp6NmxKbXdEVGdhb0pObnZVNlNacnZqVVRPWndzV3FTbUJ1S1VHdGJr V0hVeGt6VDZLTFhDOWlCb2MxRTF2bXJkTklyTjAweWxKbEZyWE5ReVdneFdrUlVicnhXTTZNV2FS cU02WDRSUStYNHZ1ai8wNHY4QStoeDE3VFhrSHdyVEhpcTVQL1RrMy9vYVY2L2l2bE15ankxMmoz Y0U3MHJoUlJSWEFkWmplTGYrUlAxbi9yeWwvd0RRVFhuUGlqL2ozOEtmOWVmL0FMUmpyMGJ4Yi95 SjJzLzllVXYvQUtDYTg1OFQvd0RIdjRUL0FPdlAvd0JvcFFCVGovMVlyTTFyL2oxbC93Qnh2NVZw eC82c1ZtYTEvd0Flc3Y4QXVOL0kxU0VjTWFqWTA1alViZWxkREpHRVpGUkZjVk5qaW1NTVZJRmRo VVJPS21rNlZXYW9iS0hoNnR4bktpczhWZWdIN3VpTEV5NUd1VXFUR0JSRmpiVGpXeVJKRXdxTThW STlRTWNWSXhyODFFd3FRbk5OYW9ZeUJoeFVST0tuYW9IT0tsZ00zYzFJakhkVUxVc2VTdyt0VGNa b1JqTGdHcktwZzFCRC9yQlYzdFc4RVNSRlFCVVRWTTlRUFF3R0Z1S2lOT05NN1ZEWTdrYkNvbUdL bllWRTlRTWhKb0JvYnJTVk54azhSTFpxM0N1UWVLcHdkNnYydlJ2cldrQk1rMjRwcllBcVlpb1g0 clJva2hKcU51ZXRPWTFFYXpZeEtpWWNWTFREVWpJaUJTWXB6VTJvR0ZTcDBxS3BFKzdUVzRNdFJw bE9sVEt1Ri94cHR2OEE2dkZUNHJaSWtvTDFxeEZVQ2lwNCtLbEFXRnBrMzNmd3BWTkk3Y0dyNkNN NS91R29hbWsrN1VQU3NHVWhPOVNLS1pUMVBGQXlZVXRNV25EclZDSGlwa3FKYW1UNlZTRVdJK2xU RHBVS0duNUFGYUlSV3VSOTM4YW9UOUZxL2NuaGFvVDloV2N5a1EwOWFaam1ucldZK2hPbFNpb1ZP S2tCcWlXTzcwOWFaVWkxYUVTeDFZU29FRlRMV2tRSk8xVTdqL1dmaFZ2T0txWEhNbjRVU0FvM09Q TVAwcUVkYWx1RnpJYWlBd2MxenNwYkVxQ3JDaXE2OWFuVW1xUW1TZ1U0VXdWSUt0Q0hMMXFkT2xR clV5VmFBbEZEVUNrWnNDcTZDS1V2M1dyT1kvTldqTHlHcWdWckNSUXFkYXNwVlphblNsRUN3dFdM VC9qOWcvNjZML09xeW1yTm1mOEFUWVArdWkvenJRUjcvb1AvQUNENGY5eGY1VmxlT3Y4QWp4cy8r dXJmK2cxcTZEL3lEb2Y5eGY1VmxlT3YrUEt6L3dDdXJmOEFvTllGSEw2aC93QWlOb1AvQUdGbC93 RFI3MTdoSDkydkQ5UUgvRkRhRC8yRmwvOEFSNzE3aEg5MmtNZUtXa29GQUhOL0VEL2tSdFMvN1pm K2pVcnhDdmIvQUlnZjhpUHFYL2JML3dCR3BYaDlBQ21rcGFUdFFBbEpUcWJpZ0FwdE9wS0FHbWtO TDJwTzFBQ2V0SlMwbEFDZHFhYWRUVFFBMDBocFRTR2dCRDBwdExTR2dCcHBEU21rTkFEYWJUcWJR QWxNTlBQU21HZ0JEVFRUalRUUUEwMDAwNDAyZ0JwcERTbWtOQURUVFRUalRUUUEwMGhwVFNHZ0J0 Tk5PcHBvQWFhU25HbTBBTk5JYVUwaG9BYlNHbHBEUUEwMGxPTk5vQVNtbW5VMDBBSWFTbkdtMEFK U1V0SlFBbElhV2tOQUJSUlJRQVVVVVVBRkZGRkFCUlJSUUFVVVVVQUZGRkZBQlJSUlFBVVVVVUFG RkZGQUJSUlJRQVVVVVVBRk9CeFRhS0FKMWt4VTZUWTcxU3BWUE5heHFORU9DWnNSVDFlaG5IcldK RWF1eEd2Um8xbWNkU21qY2huejNxOUZKbkZZa0I2VnB3R3ZXb1ZHeno2c0RVVnVCVHdhcm9lQlV5 MTZjV2NUSmgwcGFhdE9yVWhoaWt4UzBVd0drVTByVWxJYVZoblcvREJOdmlhNFAvVG0zL29hVjZ6 WGxmd3ovd0NSanVQK3ZSdi9BRU5LOVVyNC9PRmJFdjVIMEdYYTBRb29vcnl6dU1ieGIveUoycy85 ZVV2L0FLQ2E4NThVY1cvaFQvcnovd0RhS1Y2TDR0LzVFN1dmK3ZLWC93QkJOZWRlSitiZnduLzE1 LzhBdEdPbWdLY2YrcldzeldmK1BXWC9BSEcvbFduSC9xMXJNMW4vQUk5WnY5eHY1VTBJNE4rS2pK cVpxaklyb1pJenRUR3A5UnRVc0NHVHBWWnFzdWFyc0t6WTBSL3hWb1EvNnVxSVUxY2dHMUtJb1pv UkQ1YWVhYkczeTA0bml0MFNSUHhVRFZNOVJFVklFVklhY2FZMVN3R05WYVFWWVkxQTlReG9oTk9p NGI4YVFpbFJQbUgxcUJtbEYvckJWMGRLb3duOTVWemRtdWlPeEkxNnJ2VmhxZ2NVTUNCcVR0VDJG TXFHTVkxUk5VckdvWDZWQXlKdXRKUTFBcUJrc0hVMWZ0ZWpmV3FNQTYxZXRqaFcrdGFRSlphTlFQ VXBOUlAwclZpS3o5YWpOU3NLak5ac1kzdFRUVGlLWTFTeGtiVTJsTkpVQUZTSjBxT3BFKzdtbWhs NjNIeWo2MVB6VmVCc1JpcHdlT3RiZENXVXdRS2VyanNhbzVveldkeDJORHpnQlRIbTRxbUNhY092 ZWptQ3c4ak5SR05nZWxXRnAvVTBXdUNLbXh2U2xDc08xWGxVSHRUeEdEMnA4Z0ZBWkI2Vkl0V1do WDd1TVZBeTdXeFJhd0VpZ0RyVHc0SEdhcHRJVHhVWmM1Nm1pOWdzelVFb0hHYVZwaGpyV1lHUHJU aGswK1lWaXk4aGZpb25qM2pOSWd3YW1qNG8zQXFtSTloUXFONkdyNEFQYXBGUmZTamtDNVFDdG5w VGx5RHpXaDVROUtoa2lBRE4zcDhvWElmZXBoZ1ZGVURTRWpHYVY3QVh3eWp2VC9NVWQ2eXhJVDNw eXNjOWFPY0xHa1pRQndhZ1p0N1pxdjE3MUtnd0txOXdHdkZrNXFFeEhQU3J5ZE1VOEw5S1hMY0Nn RVlkcWVGWWRxMEFnUGFsOHBRT2xQa0FvcWVjVk12V25QR0Z5UlVMdVVHUlJzQllCVWQ2ZXJMNjFt bVUrdElKR1BRMGM0V05VU0w2MDE1UUJqTlVBeFBlbnJ5YWZOY1JNZVFjMUEwUnowcWNWS09hTFhB b2lKaDJwNFJ2U3J3WDJwK3dlbE5RQW9BTU8xV3JML2o4Zy82NkwvT3BHakI3VVdxNHZvQi8wMFgr ZE8xa0I3N29QL0lQaC8zQi9Lc3J4MS94NVdYL0FGMWIvd0JCclYwSC9rSFEvd0M0UDVWbGVPditQ S3ovQU91cmYrZzF6RkhMNmgveUkyZy85aFpmL1I3MTdmSDkydkVOUS81RWJRY2Y5QlpmL1I3MTdm SDkya01sNXBLS0tBS09zYVZCcmVrejZkY3ZJa00yM2MwUkFZWVlOeGtIdUs1VC9oVk9pLzhBUDlx Zi9meVAvd0NJcnVhS0FPRi80VlRvbi9QOXFmOEEzOGovQVBpS1gvaFZPaWY4L3dCcWYvZnlQLzRp dTY3MFVBY0ovd0FLcDBUL0FKL3RULzcrUi84QXhGSC9BQXFqUk1mOGYycC85L0kvL2lLN3J2UzBB Y0ovd3FqUlArZjdVLzhBdjVIL0FQRVVmOEtuMFA4QTUvdFQvd0Mva2Y4QThSWGQwdEFIQi84QUNw OUQvd0NmN1UvKy9rZi9BTVJTZjhLbTBQcDl1MVAvQUwreC93RHhGZDdSM29BNEwvaFV1aC84L3dC cWYvZnlQLzRpai9oVXVoZjgvd0JxZi9meVAvNGl1OUZBb0E0RS9DVFF2K2YzVlA4QXY1SC9BUEc2 UCtGUjZGL3ovYXAvMzhqL0FQamRkOTZVZDZBT0IvNFZIb09QK1AzVlArL2tmL3h1ay80VkZvUC9B RC9hcC8zOWovOEFqZGQrYVA4QUdnRHovd0Q0VkJvT1ArUDdWUDhBdjdIL0FQRzZUL2hUK2cvOC93 QnFuL2YyUC80M1hvSTZVVUFlZkg0UDZCL3ovYXAvMzlqL0FQaUtRL0IzUVA4QW4vMVgvdjdIL3dE RzY5Q29vQTg5UHdjMEQvbi9BTlYvNyt4Ly9FVW4vQ20vRC84QXovNnIvd0IvWS84QTQzWG9mZWln RHp2L0FJVTE0ZjhBK2Y4QTFYL3Y3SC84Ym8vNFV6NGUvd0NmL1Z2Ky9zZi9BTWJyMFdrb0E4Ni80 VXo0ZTczK3JmOEFmMlAvQU9OMGY4S1k4UGY4L3dCcTMvZjJQLzQzWG90QW9BODUvd0NGTCtIditm OEExYi92N0gvOFJTZjhLVzhPL3dEUC9xMy9BSDlqL3dEamRla0Nrb0E4NC80VXI0ZC81LzhBVnY4 QXY3SC9BUEc2VC9oU25oei9BSi85Vy83K3gvOEF4dXZTS0tBUE52OEFoU2Zoei9uL0FOVy83K3gv L0c2UCtGSmVIUDhBbi8xZi92N0gvd0RHNjlKSFNpZ0R6WC9oU1hodi9uLzFmL3Y3SC84QUc2UCtG SStHOC84QUgvcS8vZjJQL3dDTjE2VlFPbEFIbW4vQ2tQRFgvUDhBNnY4QTkvWS8vamRKL3dBS1A4 TmY4LzhBcS84QTM5ai9BUGpkZW1DazcwQWVhZjhBQ2p2RFgvUC9BS3YvQU4vWS93RDQzU2Y4S044 TkgvbC8xZjhBNyt4Ly9HNjlON1VkNkFQTWo4RGZEUDhBei82eC93Qi9ZdjhBNDNTZjhLTThNLzhB UC9ySC9mNkwvd0NOMTZkUlFCNWgvd0FLTDhNLzgvOEFySC9mNkwvNDNTZjhLSzhNZjgvK3NmOEFm NkwvQU9OMTZmUlFCNWgvd29yd3gvei9BT3NmOS9vdi9qZEgvQ2lmREgvUC9ySC9BSCtpL3dEamRl bjk2S0FQTHo4Q2ZDLy9BRUVOWS83L0FFWC9BTWJvL3dDRkVlR1ArZjhBMWovdjlGLzhicjFEdlJR QjVmOEE4S0g4TC84QVAvckgvZjZML3dDTjBuL0NoL0MvL1A4QTZ4LzMraS8rTjE2aDNwYUFQTGYr RkRlRi93RG4vd0JZL3dDLzBYL3h1Zy9BYnd2L0FNLytzZjhBZjZML0FPTjE2bDNwS0FQTHYrRkMr RnYrZ2hySC9mNkwvd0NOMG4vQ2hmQzMvUDhBNngvMytpLytOMTZsUjJvQTh0LzRVTDRXL3dDZi9X UCsvd0JGL3dERzZQOEFoUXZoYi9uL0FOWS83L1JmL0c2OVNvb0E4dC80VUw0Vy93Q2YvV1ArL3dC Ri93REc2WC9oUXZoYi9uLzFqL3Y5Ri84QUc2OVJvUFdnRHkzL0FJVUw0Vy81L3dEV1ArLzBYL3h1 ai9oUXZoYi9BSi85WS83L0FFWC9BTWJyMUtpZ0R5My9BSVVMNFcvNS93RFdQKy8wWC94dWovaFEz aGIvQUovOVkvNy9BRVgvQU1icjFHbG9BOHQvNFVMNFcvNS85WS83L1JmL0FCdWovaFF2aGIvb0lh eC8zK2kvK04xNmxTVUFlWGY4S0Y4TGY4LytzZjhBZjZML0FPTjBmOEtGOExmOC93RHJIL2Y2TC80 M1hxUGFpZ0R5Ny9oUTNoYi9BSi85WS83L0FFWC9BTWJvL3dDRkMrRnYrZjhBMWovdjlGLzhicjFJ MFVBZVcvOEFDaGZDMy9QL0FLeC8zK2kvK04wRDREZUZ2K2YvQUZqL0FML1JmL0c2OVJwUlFCNWIv d0FLRzhMZjgvOEFySC9mNkwvNDNSL3dvYnd0L3dBLytzZjkvb3YvQUkzWHFWRkFIbHYvQUFvYnd0 L3ovd0NzZjkvb3YvamRIL0NoZkMzL0FELzZ4LzMraS84QWpkZXBVVUFlVy84QUNoZkMzL1AvQUt4 LzMraS8rTjBmOEtGOExmOEFQL3JIL2Y2TC93Q04xNmxSUUI1ZC93QUtGOExmOC84QXJIL2Y2TC80 M1Ivd29Yd3Qvd0EvK3NmOS9vdi9BSTNYcU5Bb0E4dS80VUw0Vy81LzlZLzcvUmYvQUJ1Z2ZBWHdz UDhBbC8xai92OEFSZjhBeHV2VWFYdFFCNWt2d0w4TUwwdjlYLzcvQUVmL0FNYnFSZmduNGJYcGU2 ci9BTi9ZL3dENDNYcE5GV3B5V3pKNUl2Yzg5VDROK0hrNlh1cWY5L1kvL2pkVEo4SnRCVHBkNmwv MzhqLytJcnZhSzFXS3F4MmtRNkZON280Z2ZDN1JBUDhBajYxRC92NG4vd0FSVHg4TWRHSFM2djhB L3Y0bi93QVJYYVVDcit2WWorZGtmVmFQOHB4ZytHbWpEcGMzL3dEMzhULzRtbC80VnJvLy9QemZm OS9FL3dEaWE3S2luL2FHSi9uWXZxbEQrVTQ3L2hXdWpmOEFQMWZmOS9FLytKby80VnBvL3dEejlY Ly9BSDhUL3dDSnJzYVdqKzBNVC9PeC9WS0g4cHh2L0N0ZEcvNStyLzhBNytKLzhUUi93clRSditm cSsvNytKLzhBRTEyTkxSL2FHSi9uWWZVNkg4cHoraGVFTlA4QUQ5NjkxYVRYTHU4WmpJbFpTTUVn OWxIcFhRVVVWejFLczZzdWFidXphRUl3Vm9xeUNpaWlzeWpHOFcvOGlkclAvWGxML3dDZ212T1BF LzhBeDcrRS93RHJ6LzhBYUtWNlA0dC81RTdXZit2S1gvMEUxNXg0bi80OS9DZi9BRjUvKzBVb0Fx eC82c1ZsYTF4YXpmN2pmeU5hc2Y4QXF4V1JyM0ZqY2Y4QVhKLy9BRUUxUzNFY09XWDFwQ1BTczh5 c0QxcVJKaUsyNXJpc3ljamlvRGsxWUEzRUNwVmlBNHhUdGNSbmxXeDBwaGlKNXdhMVRHbzdVMGdl bEhJQm5MQ1QyeFU2cnRBRlRuaW8yNjB1V3d4NlM0R0tmNWc5YXB0dzNlb3l4SGVqbXNLeGZMcjYw emNwNzFubHlPOUlzakU0SnFlY2RpOCtNVkM5RWNoWTRxVkVEbm1udUJWS2s5alRDaDlLMHhHTWNp anl4NlVjZ0dYNVo0NHFSSVNXcTZWQTdVeGp4UzViQVJxZHBGVHJLRDNxczNTb2p4ME5GN0FYaklw NzAwc3ZyVkJtOXpUUE5ZZDZYT0ZqUU9EMHFKdXBxcXNwSE5XRk80Q2k5d3NSTm50VFNyRmVsWGtp QTZVL3lsOUtPVzRHWDVaUFkwTEVjOURXa3lLTzFSbmlseURLeW9VcWFPVFp4NjBqbk5SUHpSc0Jj RW85YVJwRjlhb0U0NzB3dDlhZk9GaThXWDFwalkyNXFwdlByVDBrSnd0TG11QkpVUnlhbXh6ZzFN c1FIU2kxeEZFcWZTazJ0NlZwR0pSVEdVQ2x5REtHd250VW9RcXVLbU9CVWJmZW81YkJjZWttQmlw aE5nZGFwTjF6VERuM291QWxGRkozcUJqMUZTQVV3ZHFlS3BDSEFjMUlEVEJUaDFwb0xFOGRXRnF2 RjFxeXRhb1FwR1JWQ1VZYzFmYjd0VUplV05LWUZOdnZHa3BXKzhhU3NIdVVQV3BsRlFwMHFaYXBD WThERk9IV205cVVWUWlaT2FzSUtycDFxeEgxclNMRVNqcFVjeS91MitsU3IwcUs0NGpmNlZYUUNr ZW1LcGsxYzVxaTNXc0pGSWN2TlRKVUMxT3RJR1NxS2tIcFRFcC9ldEVJY0RpcFVOUWpyVXFVeEZo T2xTWXFOT2xTQ3RVQkZNQnROWjl3Y0tLMEp2dVZRbkh5Vm5OQWlvVHpUMHFMdlVxVmlVV0VHZTFT Z1lxT1BwVXdyVkVpaW5xY0dveDFwNDYxU0FtV3BWcUpPbFNyVm9CeEZNaDR2N2YvQUs2TC9PcEQw elVjUC9IL0FBZjlkRi9uU2V3a2U5NkQvd0FnK0gvY0g4cXl2SFgvQUI1V2YvWFZ2L1FhMWRCLzVC OFArNFA1VmxlT3YrUEt6LzY2dC82RFhLV2N2cUgvQUNJMmcvOEFZV1gvQU5Idlh0OGYzYThRMUgv a1I5Qi83Q3kvK2ozcjIrUDd0SVpKUlJSUUFVdEpSUUF1S0tTbG9BS0tLS0FDaWlpZ0FwYVNpZ0Jh S1NpZ0JhTzlGRkFCUlJSUUFVVVVVQUZGRkZBQjNvb29vQUtLS0tBQ2dVVVVBRkZGRkFCUlJSUUFV VVVVQUZGRkZBQ1VHbG9vQUtLU2lnQmMwbEZGQUJSM29vK2xBQlJSUlFBZDZLS1NnQW9vb29BS0tL RFFBZHFLS0tBQ2lpaWdBb1BXaWlnQW9vb29BS0tLU2dCZTFKUzlxU2dBbzdVVXRBQjJvb29vQUtL S0tBQ2p2UlJRQVVVVXZhZ0JLTzFHS0RRQVk0b28vR2lnQmFLS0tBRXBlOUZGQUJSUlJRQUNsN1Vs TGlnQktXaWlnQW9vb29BTVV0RkpRQXRGSlMwQUZGSlMwQVkzaTMva1Q5Wi82OHBmL1FUWG5IaWYv ajI4Si84QVhuLzdSU3ZSL0Z2L0FDSitzLzhBWGxML0FPZ212T1BFL3dEeDdlRS8rdlAvQU5vcFFC Vmovd0JXS3lOZi93Q1FmYy85Y24va2ExNHY5V0t5TmY4QStRZmMvd0RYSi84QTBFMVFqekVtbFJ2 bUZNYWxoR1dwaGMwNCtXRld3dFZJODd4VndIaXVpT3hJMXFoYXBtcUI2QUkyTk1weHB0UXdHc0to Y1ZNM1NvWDZWTEdpdS9XbytRYWUzV21WbXlpeGJuNTYwTGNDcysySHpWZnQrOWFRSlpaSUhwVVQ0 cVU5T0tpZXRSRUxuazFFVFVqMUVhellEVFViQ3BLWTFTeGtMQ29UVXoxQzNXczJOQ0E4VmNpNVZh cGlya1gzUlZSQm1naS9LS2N3cEk2VnEzUktJSHFCcW5mcFZkcWhqR0drSTRwVFNIcFVBUk5VVGRh bGFvbXFHTkNVNlA3NHBvcDBmM3hRTmxqK0lWZlJlS29jN3hWK1A3dUsxaVNJd3F1NXF5MVZucHlB aFkweW50VE1WQXhwRk1JcVE4Q282aGdOb3hSUlFNZXRQRlJqaW5BODBDWktEVGhUVkdhbEFxa0JK SFZoZlNvRjRxVlRpdFVLeElUeGlxRXZEdFZsbjcxVlk3bXFaTUNvMzNqU1U5bE9TYVpqbXNyRkQw cVphaFVWSU9LWWlVZGFWYWFuTlNJTTFTRVBUclZsS2dVVkt0YUlST0RUSmptTnZwUnVHS2lrYktz TTgwN2hxVnowL0NxTERtcnZ0VlprUHBXTWlrUnFLblNvd09hZXZXa0JPdFBIV29WT0tsWG1yUWg0 SE5TSnhUVUhGU0tLc1JNblNwQlVLbkZQTGNjVmEwQWJOOXcxbjNQM0JWeVJzakZWcFZKWEZSTFVh S09PYWtTbFpQYWxWY1ZsWmpKa3FZRVZYVTFJcDVxMFNUQVU0RG1tanRVZ0ZXZ0pFNlZLS2lXcE0x YUFmVElmK1FoQi93QmRGL25RV3B0dWMzOEgvWFJmNTBwYkFqMzNRY2YyZkQvdUQrVlpYanYvQUk4 YlAvcnEzOHExTkEvNUI4UCs0UDVWbCtPditQS3pIL1RWdjVWeWxITDZqL3lJK2cvOWhaZi9BRWU5 ZTN4OExYaCtwRUw0RjBFbmdEVlYvd0RSNzE3aEg5MzJwREpLS1NqbWdCYUtTbG9BS0I3VVVVQUZM U1VVQUxSU2RxV2dBb3BLV2dBb3BLV2dBcGMwbEg1VUFMUlNVVUFMUlNVdWFBQ2lpa29BWHRTVXZh a29BV2lrcGFBQ2lrcGFBQ2lpak5BQlJTVVVBTFNVVVVBSEZGTFNVQUZGSDQwVUFGRkZGQUJSUlJR QVVVbEZBQzhVbEZGQUJSUlJRQWZTaWlqdlFBVVVVbEFDMFVsRkFDMGQ2U2lnQmFCU1VVQUZMU1VV QUZIMG9vb0FLS0tLQUNscEtLQUNpaWlnQlJTVVVVQUxRS1RpaWdCVFJTVVVBTFJSK05GQUJSMm9v b0FXaWtwYUFDaWtvNW9BV2lpaWdBRkxTVVVBTFNVVXRBQlJSUm1nQW9vb29BS0tLT2FBRm83MFVV QVkzaTMvQUpFN1dmOEFyeWwvOUJOZWNlSi8rUGJ3cC8xNS93RHRGSzlHOFhrTDROMW9rZ0Q3Rkwv NkRYbkhpYi9qMjhKLzllZi9BTFJTZ0dWb3grN0ZaR3ZmOGcrNS93Q3VULzhBb0pyV2kvMVlySjE3 L2tIM0gvWEovd0QwRTFRanpCaFNvQ0dGT0tWSkhIOHc0cWtnTGtYM3htcmRVMStVaXJBYk5iUkpI SGlvbnFSalRDTWlxQWdJcHRTa1ZHd3dhaXdER3FGNmU1NXFKNmhqUkEvV21WS3dwQWhyT3d4OXQ5 NDFvMi9TcVVLRU5WdUpzRTFyQVRMUnFKcVVObWtKclFSQS9Xb2lLc0VaNlZFeTRGWnNDSTB4alQy NlZFeHFSa2IxQzNXcFRUQ3VhelkwTUZYSWZ1clZkVXF5Z0txS3FJMmFFZjNSU3RVS1NEQUZQTGNW c21UWWplb0dxZHFpWVZMQWhJcHA2VTl1T0tqYW9HTWFvbXA3VXdnMURRQ1U2UDc0cHVLZWdPNFVJ WlAvQUJpcjZuQzFRSEpxeWorOWF4SkpXeFZkNmxMWkZSbnBUWUVEVXlwbUZSTU1Hb0dOWTFIU3Nl Y1Uyb1lGa1JLZWFjSUVwRk5UcHpXbGhFUDJkZWFZMEdCeFY0TFRYWEMwK1VDbm5hS1kweHp4US8z YWh4V2JkaG9sODlxY0oyUGVvTzlQVVVyakpESXhOT1hrVXdEbXBCVkNIN0ZaZHA2VTRRS2UxTkJx WktxMXdFK3pKUWJaYXNMVHlNNHF1VVJuK1dVTklKQWdQYXJGeU9sVXB1MVM5QUhmYUdwUmN2MnFy VDFxZVpqTFBudFFHSmFtS0tlb3AzRVNkYWsyS3d3YWlxVlRWQUw5blUwNFdxVTVLbVVlMVVvaUt6 VzZnZEtqQ0ZPRFY4cjZWVm40ay9DaHF3RVJsQ2pIZW8vdExDbzV6aVEvU29jNU5adGxGc1hEMDRU dm5OVmw5Nm5VQ21tSWNwSmFwbEhOUmdWSXZGVWhEdkpROXFYN09ocFZOU3JWMkFqK3pyNlV4b01I aXJZcEdIRlBsQXFmZHBqWEJIU25TSDVXcWl6Vm0zWVphRnkxT0U3R3Fpbm1wa3BLUUUzbXMzV3JO anplUWY4QVhSZjUxVkM4MWJzdUx5RC9BSzZML09yNkNQYzlHdTVZdFBqQ1djOCtGSCtwVXRXWjRv bm0xSmJlSmJhYTNLRW45L0V3eitsZFg0TC9BT1FaK0kvOUJGYk91eVBGWXdPamJXRXVNL2hYT1dl SWEvRnFOMTRYdDlDc3RPdVpMaTNuOC83UXE0UTVabTQ3L3dBVmRmcFBqN3hQQllSeGFqNFZ1Slow VUswc1RZRGUrSzZnWDkxL3oyUDVVdjIrNnovcmpTQXhmK0ZoYXY4QTlDamZmOTlDai9oWWVzZjlD ZmYvQVBmUXJhL3RDNi81N0dsL3RDNy9BT2V4b0F4UCtGaDZ4LzBLTjkvMzBLUCtGaDZ4L3dCQ2hm Zjk5Q3R2KzBMdi9uczFML2FOMy96M2FnREQvd0NGaDZ4LzBLRi8vd0I5Q2ovaFlXc2Y5Q2hmL3dE ZlEveHJjL3RHNy81N3RSL2FONS96M2FnREQvNFdGckgvQUVLRjkvMzBLUDhBaFllcy93RFFvWDMv QUgwSzNmN1N2UDhBbnUzNlVmMmxlZjhBUGR2MG9Bd3YrRmg2eC8wS0YvOEE5OUNsL3dDRmhheGov a1VML3dETVZ1ZjJuZWY4L0RVdjlwM3YvUHcxQUdEL0FNTEQxai9vVUwvL0FMNkgrTkwvQU1MRDFq SC9BQ0tGL3dEOTlEL0d0MyswNzMvbjVhaisxTDMvQUorR29Bd3YrRmhheDI4SDMvNWlnZkVMV1A4 QW9UNy9BUE1WdS8ycGUvOEFQdzlML2F0OS93QS9MVUFZUC9Dd3RaNmY4SWhmL21LUCtGaDZ4LzBL Ri84QW1LM3Y3VnZ2K2ZsNlA3VnZ2K2ZsNkFNSC9oWWVzZjhBUW4zL0FQMzBLUDhBaFllc2Y5Q2Zm L21LM3Y3V3YvOEFuNWVqKzFyL0FQNStYb0F3ZitGaDZ6MjhIMy81aWsvNFdIclAvUW4zL3dDQkZk Qi9hOS8vQU0vTDBmMnZmLzhBUDA5QUdBUGlIclBYL2hENy93RDc2RkgvQUFzUFdmOEFvVDcvQVBN VnYvMnZmLzhBUDA5SDlyMy9BUHo4dlFCZ2Y4TEQxbi9vVDlRL01VZjhMRDFqL29UNy93RE1WdjhB OXI2aDJ1bm8vdGUvL3dDZmw2QU1BZkVQV1A4QW9UNy9BUE1VZjhMRDFqL29UNy84eFcvL0FHdnFI L1AwOUg5c2FoL3o5U1VBWUgvQ3d0WS82RSsvL01VaCtJZXNqL21UNy84QU1WMEg5c2FoL3dBL1Qw ZjJ4cUgvQUQ5U1VBYy8vd0FMRDFuL0FLRS9VUDBwZitGaGF6LzBKK29mcFcvL0FHeHFIL1AxSlIv YkdvLzgvVWxBR0Ivd3NUV1Ivd0F5ZnFINWlrLzRXSHJQL1FuYWgrWXJvUDdaMUQvbjZrby90alVl MTNKUUJ6Ly9BQXNUV2Y4QW9UdFEvTVVmOExFMWovb1R0US9TdC84QXRuVVIvd0F2Y2xIOXNham4v ajdrb0F3UCtGaWF6LzBKK29mbUtQOEFoWW1zZjlDZHFQNlZ2LzJ6cVgvUDNKUi9iT28vOC9jbEFH Qi93c1RXUCtoTzFEOUtUL2hZdXNmOUNkcVA2VnYvQU50YWwveitTVWYyMXFYL0FEOXlVQVlIL0N4 ZFkvNkUvVVAwby80V0xySC9BRUoyb2ZwVzkvYldwZjhBUDNKUi9iV3BmOC9rbEFHRC93QUxGMWov QUtFN1VQMHBQK0ZqYXdQK1pQMUg5SzN6cmVwZjgva2xIOXQ2bC96K1NVQVlIL0N4dFgvNkU3VWYw by80V05xLy9RbjZqVzkvYmVwZjgva241MG45dDZuL0FNL2t2NTBBWVgvQ3h0Vy82RTdVYVA4QWhZ K3Ivd0RRbjZqVzcvYmVwZjhBUDVKUWRjMVAvbjhrL09nREIvNFdQcS8vQUVKK28vbFIvd0FMSDFi L0FLRS9VZnlyZC90dlUvOEFuOWwvT2tPdWFuL3oreTBBWWY4QXdzZlZ2K2hQMUdqL0FJV1JxMy9R bjZqK1ZiaDF6VSsxN0xTZjI1cW4vUDdMUUJoLzhMSTFiL29UdFMvS2svNFdUcXYvQUVKMnBmbFc1 L2J1cWY4QVA3SitkSDl1NnAveit5Zm5RQmlmOExKMVgvb1R0Uy9Lay80V1Zxby81azdVdnlyYy90 M1ZQK2YyWDg2VCszZFUvd0NmMlg4NkFNVC9BSVdWcXY4QTBKMnAvbFNmOExLMVgvb1R0VC9LdHY4 QXQ3VlArZjJYODZQN2UxVC9BSi9aZnpvQXhmOEFoWldxL3dEUW5hbC8zelNmOExMMVgvb1R0Uy83 NXJiL0FMZDFUL245bC9PaiszdFU2ZmJwZnpvQXhQOEFoWmVxZjlDZHFmOEEzelIvd3N6VkIvekoy cC85ODF0LzI5cXYvUDhBUy9uUi9idXFIL2wrbS9PZ0RFLzRXWnFuL1FuYW4vM3pSL3dzelZQK2hP MVAvdm10ciszZFZISDI2Yjg2UDdlMVgvbitsL09nREYvNFdacW4vUW5hbi8zelIvd3N6VS8raE8x UC92bXRrNjlxdi9QOU4rZEExM1ZmK2Y2Yjg2QU1iL2habXFmOUNkcWYvZk5IL0N6TlUvNkU3VS8r K2EydjdlMVgvbi9tL09tLzI3cXYvUDhBVGZuUUJqZjhMTjFQL29UdFUvNzVwUjhUZFQvNkU3VS8r K2EyUnJ1cS93RFAvTitkTC9idXFmOEFQOUwrZEFHSi93QUxOMVAvQUtFN1UvOEF2aWwvNFdicWYv UW5hcC8zelcxL2J1cWY4LzAzNTBoMTNWZitmNlg4NkFNWC9oWm1wLzhBUW5hbi93QjgwdjhBd3N6 VS93RG9UdFUvNzVyYS90M1ZmK2YyWDg2UDdkMVQvbjltL09nREYvNFdicWYvQUVKMnAvOEFmRkgv QUFzM1UvOEFvVHRUL3dDK2EydjdkMVQvQUovWnZ6by90elZQK2Y2Yjg2QU1YL2hadXAvOUNkcWYv Zk5IL0N6ZFQvNkU3VS8rK2EydjdjMVQvbittL3dDK3FQN2MxVC9uK20vNzZvQXhmK0ZuYW4vMEoy cC85ODBmOExPMVAvb1R0VC83NXJiL0FMZDFUL24rbS83NnBQN2MxVC9uK20vNzZvQXhmK0ZuYWwv MEoycC85ODBmOExPMVAvb1R0VC83NXJiL0FMYzFUL24rbS83Nm8vdHpWUDhBbittL09nREUvd0NG bmFuL0FOQ2JxZjhBM3pSL3dzN1Uvd0RvVHRUL0FPK2EyLzdjMVQvbjltLzc2by90elUvK2YyYi9B TDZvQXhQK0ZuYW4vd0JDZHFmL0FIelIvd0FMTzFQL0FLRTdVLzhBdm10diszTlQvd0NmNmI4Nlgr M05ULzUvWnY4QXZxZ0RELzRXZHFmL0FFSjJwLzhBZk5BK0orcC85Q2RxZi9mTmJuOXQ2bi96K3pm OTlVdjl0Nm4vQU0vczMvZlZBR0Yvd3MvVlAraE8xVC92bWovaForcC85Q2Jxbi9mTmJ2OEFiZXA1 L3dDUDJiL3ZxbC90dlV2K2YyYi9BTDZvQXdmK0ZuNm4vd0JDZHFmL0FIelIvd0FMUDFQL0FLRTdV LzhBdm10NysydFMvd0NmMmIvdnFqKzJkUy81L1p2KytxQU1IL2haK3AvOUNkcWYvZk5IL0N6OVQv NkU3VS8rK2EzL0FPMmRTLzUvWnY4QXZxay90blV2K2YyYi92cWdEQi80V2ZxZi9RbmFuLzN6Ui93 cy9VLytoTzFQL3ZtdC93RHRuVXYrZjJiL0FMNnBmN1oxSC9uOG0vNzZvQTUvL2hhR3AvOEFRbmFu L3dCODBmOEFDejlUL3dDaE8xUC9BTDVyb1A3WTFML244bS83Nm8vdGpVZitmeVgvQUw2b0E4NzhZ K04vRlBpSFJwdExzdkROM2FRenJzbGtkR1ppdm9NQ29yelYyMXBOSmovczY5czIwMkR5M004Sklr T3hWNDI1L3VrODE2Vi9iR29qL2w4bS93QytxUDdZMUgvbjltLzc2b0E4K3RJNUpseEhEY1B6ejVk dEkyUC9BQjJxM2lEVFpZZEpubWtKWDVDQ2pveU1NZzlqWHIxbEk4c0xTT3haMmZMTWVwT0JYQ2ZF Yi9qeXVmOEFya3YvQUxOVFc0SGlua0lLQWlxS2thb3llSzZTQmpIamlvL01aZWhwK0tqWVZJQjlv Y0NtbTZhbzNHS2hZODk2aHNkaTJ0eVNlZWxQM2J1ZTFaKzd0VjJFZ3BUVHVNa1dMY2NucFR2c3kx UEd2eTA4cjYxcFlrcUczU2p5RUZUdnhVSlBGS3dER1VEcFVUa2lwU2FqZXBZeG5uT0tRM0QrdE5Z Y1ZFd05UY0VUZmFYcDZ6NTYxU3pqclRrWUZxVnhsekc3aW5yYmcwUmY2d0NyWVdyU3VTVmZzeVUw MnlDcmJBVkMzRk54U0dRK1dxOUtZMVBZMHcxTEFqM3NyWkZJWjNBelNzS2lZY1ZEWXgvMmg2UVhE WnFBMGc0cFhZRnpmdjhBd28yRnpuSEFxR0U5YXUyd3lwK3RWSFVRejdNRFNmWmxGWENNVkUzU3Jz QldNQ2lrWlFGd0JValZHYWxnTXBtOWxQR2FlYVkxSUVKNXpEdlI1ejFHYVNvdU1rRXh6elR5Mjdt b0trVDd0Q0dQRVc0NXhUL0lGVFFMbEJVb0hBclJSSkthMVppcXN2V3JNVkVRTEMwMlhLajhLY3RO bDVXcllqTmNmS2FocVovdUdvYXhaU0U3MUt0UmQ2a1drTWxBcDlNQnB3TlVJY3RUSlVJcVpLcENM S2RCVW9GUXAwcVlIaXRFSXFYSjZWUW42Q3I5MTJxaFAyck9ZeUducFRNMDlheUdUcFVvRlJMVW9y UkNEdlQxcG5lbnJWTGNSTW5XckNWWFFWWVRwV2tRSk8zU3FkenpKK0ZXKzFVN2ovV2ZoUklDaGNE OTRmcFVTL2VxYTQvMWgrbFFyd2E1M3VVVEp3YW5YMnF1bldyQzFTRVNDbkRyVFJUaDFxeEQxUE5U SjBGUXIxcWRPZ3EwQktLVmpnVWdvYnBWZEJGR1laRGZTczVoZzFwUzlHck9ibHF3a1VoeVZZakdL cnB3YXNJYUVESnhWbTAvNC9ZUCt1aS96cXN0V2JQL0FJL1lQK3VpL3dBNnRDUGQ5QTFxTFN0UFh6 SVhrVmdEbE8zRlI2LzQ3c2JpM2h0N2Z5NDNWOXovQUdpVlY3ZHF0NkJ4cDhQKzRLeXZIWS8wU3pm djVqRFA0VmhZczV5NytKbGpaM0xXekJKSkY2bUxMcitCRk4vNFdiYi9BUFBuTi8zNWF0ejRLYURw OXgvd2tXcjNGckZOY3JlL1o0M2RjN0YrOGNmWEkvS3ZXdnNkci96N1JmOEFmQXBBZUUvOExOZy81 ODV2Ky9MVWY4TE5nLzU4cHY4QXZ5MWU3aXh0RC95N1JmOEFmQW8vcyt6UC9MdEYvd0I4Q2dEd2ov aFowSC9QblA4QTkrV28vd0NGblFmOCtjMy9BSDVhdmQvN05zai9BTXUwWC9mQXBQN0xzVC95Nnhm OThDZ0R3bi9oWjF2L0FNK2MzL2ZscVA4QWhaMEgvUG5OL3dCK1dyM2lQVExBai9qeWczRC9BR0JR Mm5XYTlMTzMvd0MrQlFCNFAvd3M2My81ODV2Ky9MVXh2aW5aeGo1N2VSZnJFd3IzWnJhMlhwWjIv d0QzN0ZZdmlUU2RQdjhBUUwxSnJHM09JbVlFUmpJb0E4aUh4WHNHT0VpWW4wRWJWSi93czZEL0FK ODV2Ky9MVnY4QXdMOFA2ZVBEdXA2ak5heFNYSnZtZ1YzWEpWRlVjRDhUWHEvMksxLzU5WWYrK0JR QjRWL3dzNkQvQUo4NS93RHZ5MUgvQUFzNkQvbnpuLzc4dFh1b3NiTS84dTBQL2ZJby9zK3pQL0x0 RC8zd0tBUEN2K0ZuUWY4QVBuUC9BTitXcFA4QWhaMXYvd0ErYzMvZmxxOTIvc3l5L3dDZldML3Zn VUhTcklqL0FJOVlmKytCUUI0Vi93QUxQdHYrZk9iL0FMOHRSL3dzNjMvNTg1LysvTFY3eEhwbW5z dkZsQUNPdnlDaHRPczE2V2NIL2ZBb0E4SC9BT0ZuUWY4QVBuUC9BTitXcU4vaXJaUm5Ed092MWpZ VjdzMXJiTC95NTIvL0FIN0ZjMTQyMGZUci93QUo2aDV0aGI3a2lMS3dRQWlnRHkxZml0WU9kcVF1 eDlCRzFTZjhMT2c3V2MvL0FINWF1cStCK2hhY3ZnRmRTZTBpa3VybTZrRFNPdVR0WEFBK2xlbWZZ N1QvQUo5WWYrK0JRQjRWL3dBTE9nLzU4NS8rL0xVZjhMT3Qvd0Ruem4vNzh0WHUzMkd6L3dDZmFI L3ZnVW45bjJaLzVkWWYrK0JRQjRWL3dzNjMvd0NmS2Y4QTc4dFNmOExQdC84QW56bi9BTy9MVjd0 L1p0a2V0ckQvQU44Q2c2WFk5clNFL3dEQUJRQjRWL3dzKzMvNTg1LysvTFVmOExPdC93RG56bi83 OHRYdkthWHA3TGxiS0QvdmdVamFkWnIwczdmL0FMNEZBSGczL0N6b0IveTV6LzhBZmxxWTN4VXNV SUR3U0w5WTJyM1pyVzJYajdIYi93RGZzVnhmeE4wYlQ3dndQcUVyV1VDeXhKdVIwUUFnODBBZWVy OFZiR1J0c2NEc2ZRUnNhZjhBOExPZy93Q2ZLZjhBNzh0WGRmQi9RdE90dmh6cDE1OWpoYTV1akpK Skl5QWx2bUlINkN1OCt4Mm4vUHJEL3dCOENnRHduL2hac0gvUGxQOEE5K1dvL3dDRm5RZjgrVS8v QUg1YXZkL3NObi96NncvOThDait6N1AvQUo5WWYrK0JRQjRQL3dBTE90LytmS2YvQUw4dFIvd3M2 RC9ueW4vNzh0WHUvd0RadGtmK1hXSC9BTDRGSWRNc2UxcENmYllLQVBDUCtGblFmOCtVL3dEMzVh bC80V2JCL3dBK1Z4LzM1YXZmRTB2VG5YY3RsQi8zd0tSdE9zMTZXY0gvQUh3S0FQQXo4VG9QK2ZL Zi92MDFSTjhWYkpEaDdkMStxR3ZmSHRiVWY4dWR2LzM3RmVkL0dEUjdDYndMYzNZc29JNTRTQ3Jv Z0JvQTRoZmluWnlOaU8ya2Y2UmsxSi93c3lIL0FKOFovd0R2eTFlbC9EUFFkT3NmaDlvc3EyY0pt dUxZVFN1eWdsbVlrMTF3dExUL0FKOUlQKytCUUI0Si93QUxNaHovQU1lTngvMzZhbC80V1pEL0FN K054LzM2YXZldnNWbWYrWFdIL3ZrVWZZTE0vd0RMckQvM3dLQVBCRDhUWWY4QW54bi9BTy9UVWgr SmtQOEF6NHovQVBmcHE5Ny9BTE5zVC95NlEvOEFmQW9PbVdJNSt4d0gyMkNnRHdUL0FJV1pEL3o0 ei84QWZwcVArRmx4ZjgrRS93RDM1YXZvSk5LMDVsRExaUWY5OENtdHB0a3ZTenQvKy9Zb0ErZmo4 UzRoL3dBdU0zL2ZwcWlQeFRzMU8xN2RsUHVwcjZBYTB0Ui95NTIvL2ZzVjVYOGNOSHNQK0VQUy9q czRZcmlPWlFIUk1IR1IvalFCeWFmRkcxYy9KYXlOOUVKcC93RHdzcVAvQUo4Si93RHYwMWV1ZUQ5 QzA3Uy9DT2p4dzJVQVpyT09SMktETE1Sa2sxdWkxdGovQU11MFAvZkFvQThGUHhLai93Q2ZDZjhB NzlOU0g0bFIvd0RQaE4vMzZhdmZEWTJwL3dDWGFML3ZrVTMrejdQUE50RGdmN0FvQThGLzRXVkgv d0ErRTMvZnBxUCtGa3gvOUErZi92MDFlOWZZN0VmOHVOdC8zN0ZIMmF6SFN5dC8rL1lvQThFLzRX U24vUVBuL3dDL2JVZjhMSlQvQUtCOC93RDM3YXZlVERhai9senQvd0R2MktUWmJqL2x6dC8rL1lv QThHLzRXU2cvNWg4My9mdHFpUHhSdFZiRDJ6S2ZUYWE5OElnLzU4N2IvdjJLOG0rT1drMlowT3cx Q0cwaGh1UFA4c3ZHdTNJb0E1NWZpZEJKOXl6a2I2S1RUeDhTRi82QjgvOEEzN2F2YjlJMFRUZEsw bXl0YmF4dDFWYmVQK0FjbmFNMWZGcmJIL2wyaC83NEZBSGdKK0pDL3dEUU9uLzc5dFNmOExKWC9v SHpmOThOWHY1c2JVLzh1MFgvQUh3S2FMQ3p6azIwSkEvMkJRQjRGL3dzbFQvekRwLysrR28vNFdR di9RTm4vd0MvYlY3L0FQWXJFZjhBTGhiL0FQZnNVaHRiTWRMSzIvNzlpZ0R3SC9oWksvOEFRTm4v QU8vYlVmOEFDeUYvNkIwLy9mdHE5ODhtMUgvTG5iLzkreFNGTGNmOHVkdi9BTit4UUI0Si93QUxK VWY4dzZmL0FMNGFvdjhBaGFkcUNRMW93UDQxNzhWdC93RG56dHYrL1FyeHo0MTZKWW04MEs1aHRJ b1pMaWNReUdKZHU0RS8vV29BeDArSjBNZ3pIWVNNUFpTYWQvd3NsUDhBb0czSC9mRFY3ekJwR25h YkdscmJXRnVrY2FoUU5nOUtuRnJiSC9sMWgvNzRGQUh6L3dEOExLVC9BS0JzL3dEM3cxSC9BQXNw ZitnWlAvM3cxZS9teXRUL0FNdTBYL2ZBcEYwK3pKeWJTRWowMkNnRHdEL2haU2Y5QXlmL0FMNE5P LzRXVW4vUU5uLzc0YXZvRDdEWWovbHh0LzhBdmdVMzdKWmpwWlcvL2ZzVUFlQS84TEtYL29HWEgv ZkRVZjhBQ3lrLzZCbHgvd0I4Tlh2cGd0Ui95NTIvL2ZzVTB4Mnc2V2R2L3dCK3hRQjRJZmlXbmZU Wngvd0JxaS80V3BaanJadUs5K0tXNTYyZHNSLzF6RmVNZkZUdy9ZTjQ5OE50RmFSUkxleXJITXFM Z044eS93RDE2QU14ZmlkQzR5bW56TVBVS1RTLzhMTFQvb0dYSC9mQnIzdGRPc0xKbWdnc2JkVVE3 VkFqSFFWSUxhMlAvTHJEL3dCOENnRHdIL2haYUQvbUdYSC9BSHlhVC9oWmEvOEFRTW4vQU8rV3Iz ODJWcDN0b2Y4QXZnVWlhZlprNWEwZ0k5Q2dvQThDSHhNVC9vRjNIL2ZKby80V1duL1FMdVArK0RY MEI5Z3NCL3k0Vy84QTN4U0d6c2gwc2JmL0FMOWlnRHdIL2haa2YvUUx1UDhBdmswZjhMTmovd0Nn VmNmOThtdmZEYjJnL3dDWE8zLzc5aW0rVmJEL0FKYzdmL3YyS0FQQlQ4VG9sR1RwZHdCN3Fhai9B T0ZzV1gvUG0rYTk3YU8yUEJzN1lqL3JrSzhaOForRzlPUHhxOFBXOGRwRWtGODZHV0pWd3JFZTFB R2N2eFJoY1pYVFoySHNwcDMvQUFzNU1mOEFJS3VQKytXcjNoYkt4dHlZb3JHM1ZGT0IrN0hTcGZz dHFmOEFsMGcvNzRGQUhnWC9BQXM2UC9vRlhIL2ZMVW4vQUFzK1BQOEF5Q3JqL3ZrLzRWNzRiSzAv NTlvZisrQlNwcDFrZVdzNENQUW9LQVBBeDhUNHYrZ1ZjZjhBZkpwZitGbnhmOUFxNS83NE5lL2Yy ZllEL2x4dC93RHZpayt4V1EvNWNyZi9BTDlpZ0R3UC9oYUVYL1FLdWY4QXZrLzRVZjhBQ3o0ditn VmMvd0RmSnIzczJ0b09sbmIvQVBmc1V3dzJ3LzVjN2Y4QTc5aWdEd1p2aWxDZ3kybDNBSHVDS3Rh ZDhSN2JVbWRZcmVPTjBHU0pwZ21mcG5yWHRqUld6REJzN1lqL0FLNWl2Qy9HZWtXbWsvRndmWW9F Z2pudFRLeVJqQURjZ21nRHNOUDhlV3kyK3g0SWkrYy9KZEpqcFdGNDExaVBVTklubVV4cTdCVkVZ azNISHJ4OWFnais1N21zVHhCL3g1eWZUK3RVbHFJNDFxaU5TdFVacm9aSTNGTWFuOXFZMUlDQ1Rw VlordFdYeGlxelZreWtNSDNxdndERWZzYW9nYzFlZ09VK2xFQk0wSWlTb3A1cGtTNFhGT05ib2to ZW9XcVorOVF0VXZjWkdhUTB1TVVocVdCRzFWM3FkdWxRT0t6WTBRdFN4akxmalNIaW5SOE1QclVy Y1pwUW5FbFhBT0twdy82d1ZkNlYwUjJKR04wcXMvV3JMZEtyUFF3SVd6U2RxVTBsWnNCakNvbXFV OUtpYXBZeUZ1dEpTdDFwS2tvbWc3MWZ0Q2NOOWFvUWZ4VmZ0UnczMXJTQkxMSnFCNm1OUXZXakVW MnFJMUkxUm1zMk1TbW1uZHFhZWxTTWlhbTA1cWJVQUZTSjkybzZrVDd0TkRMOXNma0E5NmxOUTIv Q0ErOVRkYTNXeExLYWptcGtPRFZVVGdVdjJqMnJOTWRpL3U0cUozK1dxMzJqaW1HVWtBVlhNRFFq L2ROUTFZQzdxREQ2Vm0wQ0srS2N0Uy9aMnBSYnNLTE1ZMEhtcEJTR0ZsN1VvR09LYVFpUlJVcWRh aDNoUlNDNUFxN2lMeW1uRjhjWnFrTHFnM1AxcHFRV0pMaHNnVlRtSFNwUklXT0RUbFFQVXZVWlJJ NXA2OFZaK3pVZlpUMXFlVVpHcHFSVHpUaGJzS1FJUTM0VTdDWTZwVkdLaUFwNWtDaXFRaWRhbVUx U0Z5QlRoZEE5S3Jtc0ZtWFN3SGVxczNNbE1OeG1tcTI3azBPVnhGZVpjeVZGdHdhdmVVSFgzcHYy WG1zM0VaV1hGVEtha0ZxMmV0T0ZzMU5SWURWT2FsQTVxSUtWYXBWT0RWQ0pGcVZhcmVjb29GMEFl OVVtZ0xvTk5MY1ZXKzBnbW10TVQwcDh3Q3Z5R3FpeWUxWGdNMGpXK2VsUTFjWlNVWXFaRGlwaGEv blR2c3hGSlJBWURWdXg1dklQK3VpL3pxdVlHWHRWaXhHTHlBSC9BSjZML09yc0k5LzBFZjhBRXZo LzNCL0tzcngzL3dBZU5uLzExYi8wR3RYUWYrUWZEL3VEK1ZaWGp2OEE0OGJQL3JxMzhxNXlpNzhF Qmp3OTRnLzdDemYrZ3JYcFlyelg0SWY4aTk0Zy93Q3dzMy9vSXIwck8zNWp3Qnp6U0djUjhUUEU2 NlQ0Um4vc3pVVVRVSG1TSmZKbFV5SnpsdW5Ub2Z6ckQ4WitKTDdUUEEyZ1dkaHJUTnExeTBhejNF VTZzLzNmbTNIdDh6RDhxd3ZIUGhYUTA4YmFSWjZkSTVsMVc0YVc3Y3poZ29aeG5IOTMrS285VDhF K0hrK0p1bStIckNTWDdESkY1dDA3VGhqL0FCSEFidHdCK2RBSHVOazBiMmNYbDNDM0FWUXBsVncy NGdjOGlyQTVySjhPYUJZZUdkSVRUdE1NaHRnN1NLWkgzSExkZWExeFFBMXZrSWNkdXRUN1ZkUVIz cUx0aW13dnNEb2Y0ZVI5S0FHU3hZcksxaGNhTmZIL0FLWU5XOGNTSldQcnFiZER2LzhBcmlhQU9F K0Ivd0R5STk5LzJGSmY1TFhvTjdkTFkyRnhlUEhKSXNFYlNNa1l5eENqSkE5Njg5K0Ivd0R5Sk4v L0FOaE9YK1MxNlRqT1FSa2RPYUFQQi9FL3hWOFFhZzhVMmxMTnBOZ2QzbE50RFBOanFTeEdPUFFk Szl1MFdhUzUwTFQ1NW5MeXlXMGJ1eDdzVkJKcnlMNDVxcVhlaUlpS3FMQkxoVkdBUG1XdldmRC9B UHlMZWwvOWVjUC9BS0F0QUdtS1drSFdsb0FhVDViYngwNzFaS2hoa1lxQWpJcElwTnNaVS93SDlL QUd5eGUxYy80cVhiNFcxUFAvQUR4TmRSeEl1YTUzeGd1M3dwcVgvWEkwQWN2OEUvOEFrbGxsL3dC Zk0vOEE2Rlc3NDIxblY5QzBIN1ZvMWdMMjVhUlk4SExlWG5nTnRITGM4ZmpXRDhFLytTWFdmL1h6 Ti82RlhvQ25Cb0E4Y3ZGK0xkdlpTYXJOY2xFUmZNYUNQeXl5cjErNWovNjlkYjhOZkhNM2k2enVM ZS9TTmIrMTJzelJqQ3lxZWpZN0hJNXFMNGhmRUN6OFBXVStsMlRyUHE4eUZOcThpRU1NYm05K2VG cW44SXZDRjVvTmpjNnBxVVpodUx4RldPRnVHV01jNVlkaVRRQjZXT0tXa3BSUUFCdktjUDhBd25o cXNsUXc3VldZWkJGSkhNVmk1UEtuYlFBU3hWeVB4RFhiNEQxWC9ya2Y1R3UxQldSYzF4L3hKWGI0 RDFUL0FLNUgrUm9BcS9Ddi9rbDJoZjhBWE4vL0FFTTFvZU1iM1hyRFFqTjRkczQ3cStNaXBzWmR4 VlR4dUM5K2NWbmZDbi9rbDJoLzdqLytobXV3WHJRQjQ3cUsvRmpTYkNUVnJpK1Zvb2wzeXhSdEc1 UmUrVngvS3V5K0hQaktYeGhwRTV1NGtqdmJWMVdVeDhLNElPR0E3ZER4WEllT2ZFdmpxTzMxV3pP a2VScEJlU0w3V2tCSk1XY0E3c25HUjN4WFIvQ1cyMEszOE5TdHBGMjl6Y1BJRGVHUk5qSStPRjIr bm9lOUFIb0ZMVFJUaFFBSS9sU2cvd0FMZGF0TW9JcW95N2xJb1djckdwSjZIYWFBRmxpcmdmaTJ1 MzRjNmovbnRYb2dZU0ptdlA4QTR3cnQrSGQveDJvQTFQQVgvSk8vRHY4QTE0eDBuamJ4TW5oUHcz TmYvSzF5eDhxM1E5REllNTloeWZ3bzhBLzhrNzhQZjllTWRjTDhWTTZwNDI4TjZHeFBrc1ZaaC92 dnRQNkxRQjNQZ0k2MC9oSzBuMTY1TTkzUCs5WGN1R1dOdnVnK3A3L2pYUzBnQ3FBcThLT0FCNlV0 QURxUHhwS1dnQjBUK1ZKZy9kYXJKQWJpcWJydVVpajdSdFZHUGZnMEFQbGk5cTh3K09BMi9EOS8r dXkvekZlcUJsa1RJcnkzNDdESGdKaC8wMVgvQU5DV2dEczlDR2ZEV2ovOWVNUC9BS0NLMUVqeldm NGNYZDRZMGY4QTY4b3YvUVJXM0hIUUJYYU1LdFZ5YzFhdlcyZ0lPcDVOVTZBQTB3MHBOTlBTZ0Jy VnhmeEZ2OWIwZlM3WFZkSW5Dd1cwd2E2aTI1M3FlbVQvQUhmWDYxMmhxaHJGbW1vYUxmV2NnQldh M2RQL0FCMDRvQWowalZMZlc5SHR0U3R2OVZPZ2JhZjRUM1g4RG11RStOdi9BQ0tObC8xOUNuL0J5 N2VUdzdlMmJuUDJlNURMN2JsL3hGUi9HMy9rVWJIL0FLK2hRQjZzaTV0N2YvcmhILzZDS21TT2x0 MDNXMXQvMXhqL0FQUVJWdU9MaWdDc3liVkpxQTFZdTIyc0VIMU5WcUFBMHcwNDB3MEFOTk1OUE5N SW9BYWE4djhBak4xOE0vOEFYOG44NjlRTmVYL0dYNy9obi9yK1QvMEkwQWV2enIvcERmaFNySFUw aVptUDRWTEhFTVVBVlhUYXRNRlMzSnhJRUhiclVYU2dBTlJtbkdtbWdCamRhWVJUbTZjZmg5YThq ZSsrTEc5dHRtKzNQSDdtTHBRQjZ1UlhtUHhNSC9GZGVEUCt2cFAvQUVJVjMraUcvZlE3SjlWWGJx QmlCbkdBTVAzNmNWd0h4TS81SHp3Wi93QmZhZjhBb1FvQTljblgvU3BQOTZsVk0xTEttYmgrUDRx bVNMaWdDb3lZRktPbE9uSTgzYU8xTit0QUNHbUduR21IRkFGYSt1VXNyRzR1M0JaSUltbElIVWhS bitsWW5oWHhaWitMcktlNnM0SjRVaGtFYkNiR1NTTTlxNUR4dGRlUGwxTFZJdFB0bmJRL0xJM2lL TS91OW56OG5uKzlYRStEWi9Ha09uM0k4S3d0SmJHVWVhVlJHK2ZieDk3Mm9BK2dDSzh4OFgvOGx3 OEhmNzM5SzlIc0RjTnAxc2JzWXVURXZtai9BRzlvM2ZybXZOL0YzL0pjdkIzKzkvU2dEMWwxL2ZQ L0FMMVBWS2VVek0zMXFkSXVLQUtySmlwQU1Da2s1bE9QNGFNNG9BWk5MSEJFOHNyaElrVXM3TndG QTZtdk9JOVk4UytQcmlZNkJjalJ0QWlZcDl1Wk15ejQ2N1IvbjYxcS9GZThsdFBoN2Y4QWtrcVpt amdKSDkxbTUvbCt0YzE0M2FhdzBId3Y0TjBwL3M2WDZva3JweGxmbEg2bGlUUUJjVHduY2tTUzZi OFI3MTdtRVpjeVRxNkwvdkRkd0t2ZUdmRkdvcnJYL0NOK0pWaEdvTW5tV3QzQmp5N3BQYnRuL0Ex eC93QVJ2QjJpZUhkTjBxMTBlS1dPL3VwdklMZWFTWmx3TWxoL3ZGYTZEeHJZeDZicVBnYTF0QUJj d1hhd0p0Nm1NQlEzK2ZlZ0QwSWl2R3ZpUi95VmF5LzY4Vy9tYTluSTVyeG40ay84bFdzdit2RnY1 bWdDR1A4QTFZckU4UWY4ZWNuMHJiVC9BRllyQzhSTnRzWldQcC9Xclc0amtHRlJrVTM3UXRLSlF3 NHJlNU5oaDRxTmpVaEdhYUltYXBBcnR6VVRMbXJ2MlltbW0xSXFYRVpTQ0dyY0l3bFBGdGcwdU52 Rk5Sc0JhUnNLS2NUeFZQemRyZTFMOXBBNjFmTUt4WWFvbUZNKzFEMHB2MmhTYVYwQXJERlJPY1ZL ekJxaVpkeDR6VWpJMjZWQzFXL3N6R20vWkNlYWx4R1VzWnA2TGhoVm43TGpyVDFnQTYxS2lBNkk0 Y1ZhRFpOVXM3UmtkYVZaOGRhMFRzU1cyTlJOMHFFM1FGSjlwQnAzSFlWaHhURHhTaVpUU0huTlN3 c1JNYWpZMU41WlkwRzJidFUyR1ZDS1FDclgyWTB2MmZGTGxDNUZCeHVxN2JuQU5RRkF2U2tMbE1E c2FwYUNMKzdpbzI2VlgrMFVodXNVK1lMRHlLamFrKzBLYUM2c01pcHVNYlVacVQxcG9pWmpnVWdJ VFNWT2JkcVQ3T3dwV0dRMUluM2FjSWNIbWxLN1RnVVdBc1F0aU9wd3dJclBFaFUrMVA4QXRIMXEx S3dpdGpOR0JSUldReFFPYWtBcHFpcEFLcENZNGZTcFZOUTk2ZU90VUluVVpxWlZxR0tyQzFhQWF5 VlVjWVkxb0hwVkNYNzVva2dLYkg1c2RxYlN0OTQwbFkzR1BXcEFPYVlsU3JUUU1jb3gwcVJDUUtZ S2N0VUltVTgxTWd6VmRldFdVeUswUWgrM2lvcEZ4R3h4VmhSVEorSW0rbFU5Z0tIdjdWVlpzbXJa cWkrYzFoSmxJY3A1cVJhaVdwa3hRZ1k4Q3BGR09LUlFNZEtmM3EwSWtVMUtwNXFBZGFsU3FFVHFL Y1Y0cHFkS2xGV2dLMHE0V3FrekVMVitmN2xaMXdCc0ZSTUNBdFNxYzFGVWk4bXNyakpsRlNxS1ln N1ZNb3hWb1E0ZEtsVnFpRk9CNXEwQk92TlBGUm9hbFdyUUNGYVMzQUdvVy84QTEwWCtkUzhZcU9I L0FKQ0VIL1hSZjUwcGJBZTlhRC95RDRmOXdmeXJMOGQvOGVObi93QmRXLzhBUWExZEJIL0V2aC8z Qi9Lc3J4My9BTWVObi8xMWIvMEd1VW92ZkEvL0FKRjd4Qi8yRm0vOUJXdlJycUJMdTBtdHBNK1hO RzBiWTY0WVlQOEFPdk9mZ2gveUwzaUQvc0xOL3dDZ3JYcGY1MGhuaEduZUFkSDFENG4zL2gyR1M2 L3MyeWczU1A1Zzh6ZmhlK1BWdjBvOEsrQWRIOFJlTHRmc0RMZGpTOVBmeTRuUnh2WnQyM2s0L3dC bHE5dmcwK3l0cnFXNmd0SUlyaWIvQUZrcVJoV2YvZVBlaXowNncwL3pXdExPM3R2TU82VXhSaGR4 OVd4MW9BZHA5bEhwdW0yMWpDWE1WdkVzU2x6a2tBWTVxMEt5WlBFdWdRekdHVFd0UFNRZndtNVRq OWEwNHBZcDRsbGdrU1NOdWpvd1lIOFJRQktLaGsrV1ZENi9LYWtGUlhBL2RFanFPYUFHV3MvemxD ZVJ4VUhpTC9rQVh4LzZaR29DL2w2azNvM0lxWFh6bnc1ZWY5Y3FBT0ErQi84QXlKZC8vd0JoT1Qr UXIwcXZOZmdmL3dBaVpxSC9BR0VwUDVDdlNxQVBHZmp0L3dBZnVqZjljSnYvQUVKYTlZOFAvd0RJ dDZWLzE1dy8rZ0NycGhpbDVlSkhJL3ZLR3A0QVhBQUFIVEZBRHFVVUJlT2hwQjZVQU9GUXlERW4r OE50VEZTUFVWRFB3Z2IwT2FBR1dWeGtsQ2VsWjNqVC9rVXRRLzY1R25JL2s2bElnNmJxajhaSFBn Kysvd0N1Wm9BNVQ0Si84a3ZzL3dEcjVtLzlDclUrSS9paVR3dDRYYWEyWUxlM0wrUkF4L2hPTXMz NENzcjRKZjhBSk1MVC9yNW0vd0RRcTcyYTF0N2tBWEZ2Rk1GNUFrUU1CK2RBSHpuNEo4UmFCb09v eTZwcmRsYzZqZjc5MEozS1ZROTJPNDh0WHJ2aGo0bmFYNHIxdE5MdGJPN2htYU5wTjhwWEh5OWVo cnFmN0kwdy93RE1Nc3YvQUFIWC9DcGJmVGJHM2tFdHZZMjhMampmRkNxbjh3S0FMUXBSUUZQb2FD TVVBTFVFb3d6RCs4djZpcHFpbTQyTjZOUUJGWVhPNzVjMWcvRXova1F0Uy82NXQvNkNhdlc3bUcv ZVBPTU1henZpVWMrQWRRLzY1dC82Q2FBS2Z3cC81SmZvbis0Ly9vWnFmeDM0bjFId3JwMXRkMkdt TmVJMHY3OXpuWkdnOWNjZ25zZWxWL2hSL3dBa3YwWC9BSEgvQVBRelhaREhUcUQyTkFIbE9xZkdm U2JuUWJtRzIwMjUrMXp3dEhzbEsrV3U0WUpKenlQd3BmZ25vZC9aUWFocXR6RzhWdGNva1VJY1lM N1NTV3g2VjZPTkQwZ1QrZjhBMlZZK2IxMy9BR2RNL3dBcTB0cDlNZlNnQXBSU2JTTzFGQURxclRn aFpBTzY3dnhGV0tpbCs4aDdad2Z4b0FpMCs1M3J0elhKZkdUL0FKSjVlLzdwcmJzbk1WMHllally QitNTForSGw1L3VHZ0RUOEFmOEFKTy9EL3dEMTVKWERmRkhPbWVQZkRXc3VQM0tsUXg5TmttVCtq VjNIdy84QStTZCtILzhBcnlTbWVQUEMvd0R3bGZobVd6aXdMeUkrYmJNZjc0SDNjLzdRNC9LZ0Rx T0R5cHlwNkgxcGE1bndGY2F0UDRTdFUxcXpsdHJ1RWVUKzkrOUlxOEsyUDAvQ3VuMm4wTkFBS1dr Mm4wTktWSUhRMEFGVkxvWWhsQTdmT0t0Q29abHl5ais4Q3RBRWVuWFc5Y1Z3SHgzT2ZBcC82Nkwv QU9oTFhWYWZLVXVDbnZpdVErT1p6NEZQKyt2L0FLRXRBSGZlRmhud3RvLy9BRjV4ZitnaXVnalhp c0x3bi95S3VrZjllY1gvQUtDSzN5UWtMTjZDZ0RHdXBQTXVuOUFjVkZUYzVKUHJSbWdCVFRUU2tI SFExSG1nQU5VOVZ1MHNOSXZidVJzTERBN244RnE1dE9PaHJpL2lQRHJPb2FQYmFUcEZvOGkza3dT NGxVOElvNUFQc2ZYMm9BeVBnNWF2SG9GL2R1TUxQY2hWOTlxOC93RG9WTitOdi9JcFdYL1gwUDZW M09oNlJEb09pV3Vtd2NyQW1DMzk1dXJOK0pyaHZqYi9BTWlsWmY4QVgwS0FQWTdSYzJ0c2YrbUtm K2dpcnlMaGFxV0kvd0JEdHY4QXJpbi9BS0NLdFRONWNEdDZLYUFNZVovTW5kdmVtMHdHbEpvQU0x eTNqaWZ4TkJZV3A4THhHUzRNcEV3Q0syRTIvd0MxNzExQkhmbW1aeFFCNUo5ditMUi81YzIvNzhS VlBwMTE4VUgxUzBGNWJzdHFaVkV4OHFJZkp1RzdwN1Y2b2VuU21INlVBSTNYaXZNUGpML3JQRFAv QUYvSi93Q2hHdlRqWG1IeGsvMW5obi9yK1QvMEkwQWUyN2N5ZmxVNnJoYzB4UjgvNVV0eTNsMnNq RCs3UUJsTTIrUm45VFFUVEY0RkthQUEwdzBwcEdCSFkwQU5OTlAwRkxUVFFBMDE1ajhUUCtSOThH ZjlmU2YraEN2VGpYbUh4TC81SDN3Wi93QmZTZjhBb1FvQTlyS1ptYjYxT0J0UW4wcGdIN3h2clNY amJMUno2OFVBWm9iY1MzcWMwdWFhdkFvSm9BQ2FhYVhyVE1nNUNuSjlqUUJYdjdZWHVuWE5tWDJD ZUpvdDJNNDNLUm45YXdQQm5oRlBCMWhjMnNkNDkxNThvazN0R0V4aGNZNjEwcHBwb0FTdk1QRjMv SmN2QitUL0FCZjByMDQxNWg0dC93Q1M1K0QvQVBlL3BRQjdNcVprYjYxWWJDUkZ2UVpwcUw4NSt0 SmZOdHRTUDczRkFGQk9lVDM1cHhOTkZGQUdGNHowTnZFZmhPLzB5TC9YU0p1aXovZlU1SDU5UHhy enBVSGovUmRMaGh2azA3eFhvcDhzeFRuYVcyNDVIL2ZJUDF6WHNSVStocm12RVBnYlFmRWN3dWIy MGFPNy93Q2ZtM2Z5NUQ5VDMvR2dEajlUK0gvaXZVdnMrczMrdVFUNjNheXE4TWJKdGdSVjU5T3Vj SHBXejRkOFAzdDlydjhBd2tYaURWTFRVTDYzRFF3UTJmTU51ZjR2K0JjL3JURitGZWprZ1hHcGF4 Y1Ivd0RQT1M3NFA2VjFHazZMcHVnV1gyTFRMVkxlRE80cXVTV2IxSlBVMEFYdWxlTS9Fbi9rcTFu L0FOZUxmek5lelY0ejhTZitTcldmL1hpMzh6UUJDbjNCWFA4QWlmOEE1QmsvKzcvV3VnVC9BRlly bnZFLy9JTG4vd0IzK3RVSTgvM0duby96QTFDMUxIa3RWWEEwRkdXRldnbUtyeEQ1bHEyQm10NDdF alNPS2piaXBUMHFGcUdBeGp4VVI5YWV4cGxRMkJFNHFKaGlyRENvWHhVc1pBVGltN2ptbGZyVVdl YXp1TXR3TmxzVmNnWE9UVkMyQjMxcFc1NHJTQW1TQmNDbXNLbUlxSjYxRVFzY1ZHeDRwem5tb2lh ellEVFVUVk4ycU1pcFl5QnVsTUpxUnhVSjYxRFkwT0RZcTFIeW9xbGpOWEllRVdtZ1pkVlBsR0tk dHdLZkg5MENocTNTMEp1UU1NVkV4cVdTb0dxR01ZeHBqWXpUalNIcFdZSWhJcU05YWxhb21ITlN5 aEtlaCtjVXluUi9mRkNCay84QUZWeFk2cUQ3d3JRVDd0YXdKSXlvQXFKcXNOVlp6UXdJeWNWRzNQ V25OVE8xUXhqR0ZNeFVocGxJQnRKM3BhS2tZOWFrSFdvbHFRR3FRaDFQV21WSW9xaEUwVldWcXRI eFZoVFdpRU9iN3RVWmZ2R3JwYkZVWmptUnFVeG9wdDk0MGxLMzNqU2Q2d2U0eDZWTW9xRktsVTFT QWs2VTRVMGMwNWFwQ0pGNjFZanFCYW5UanRXaUVUTDBway8rcmY2VTRjVXlaLzNiQ3E2QVV1b3Fr M1UxZDY1cW15ODFqTXBDS0tuU29WNjFLdldwUU1uV245NmpXcEI2MWFFS001cVZPS2pVVktnNzFZ aWRPbFNDbzFOU1p4Vm9DT2Y3bFoxeDl3Vm9USEtWbjNDN2tGUk1Gc1UrOVNvT2FidHhUMXhtc1Vp aXduclVvcUZEVXExb2hEKzlPSFdtMDlSVmlKVXFWYWpVVklLdEF4L2FvNGYrUCtEL0FLNkwvT25F NHBzSnpmMi8vWFJmNTBwYkFlOWFEL3lENGY4QWNIOHF5L0hmL0hqWi93RFhWdjVWcWFEL0FNZytI L2NGWmZqdi9qeHMvd0RycTMvb05jcFJlK0NIL0l2ZUlQOEFzTE4vNkN0ZWxWNXI4RWYrUmU4UWY5 aFp2L1FWcjBta01jT1RYaEhqdnhacW5pL3hNZkR1aVBKOWpFMzJkSTQyMi9hSHpnc3gvdTllUGJO ZTMzanRIWVhMcDk5WVhaY2V1MDE0UDhHbzQ1ZkhZa2w1ZExXVjB6L2U0Qi9RbWdEb3JYNEdSR3pY N1pyYnJka2NpR0FGRlA0bkpybHQvaUw0UytKMWg4N3piWi9uOHNIOXpjeDU1NDdOL0kxOUQxNWQ4 Y1lZbThQNlhPY2VhbDB5S2Y4QVpLblA4aFFCNlhwMm9XK3E2WmJYOXErNjN1STFrUW4wTlR5Y29S bXVKK0VrcnlmRHl5RDVJamxsUmMvM2Q1cnRqMG9BeHJySzNNRCtxZ2ZseFUrdG5QaHE3LzY1R29i NGNRTjZPeTFOckkvNHBtNy9BT3VSb0E0UDRILzhpWnFIL1lTay9rSzlMRmVhZkEvL0FKRXpVUDhB c0pTZnlGZWxVQWVhZkdtRzRYUTlPdjdhYVdJdzNCaWN4dVY0WWNkUGRhNkw0WjZrZFQ4QjZkTExJ enlRN29KR1pzbjVXUFg4TVUvNGlhZi9BR2w0QzFXSUxsNDR2UFg2b2QzOHMxNTM4T05mL3MzNGZl S0VMNGUxVXp4L1YxMi8raEFVQWNkcXZpaS9sOFhYV3FSWDF5SS90aGxTTVN0dDJoK0JqUG9LK2cv RStzTFplQ3RSMVdGOFpzekpFUjZzdUYvOUNGZUUyZmg3enZoVHFHczdNeVIzOFlVLzdBWGEzNnYr bGRQNGgxLzdUOER0SGkzNWxua1cxZm5raUxPZjVMVEF2ZkJJWDEzUHF0OWQzbHpQSEdrY0NDV1Zu RzQ4bnI5QlhyY296RTMwcmhmaEJZZll2QWNVN0REM2M3emZobmFQL1FhN3B2dW1rQmpYUjI2aEcv OEFlUUdtK0xqbndkZW4vcG1hZGVqOTdiTjlWL1dtK0xCL3hSdDcvd0JjelFCeTN3Uy81SmphL3dE WHpOLzZGWG9RcnozNEpmOEFKTUxYL3I1bS93RFFxOUNGQUMxNFY4WXJ5NnQvR3FKQmQzRVNmWTR6 dGpsWlIxYnNLOTFyd1Q0ejgrTjQvd0RyemovOUNhZ0RTaStGUGkyU0pKRjhSeGdNb1lmdjV1NHJz dkFIZy9XL0M5N2V6YXRxaTNzYzBTcEdxeXUyMGhzNSthdU5pK01tdXhRcEgvd2o5dVFpaGMvdk93 cnZQQVBqQzg4WDJkN05lV0VkbTF2SXFLcUZ2bXlNNSthZ0RzTTFIT013dFR4VFg1UnZwUUJpM0Iy NnJuKzhBMzZWUStJM1BnQy8vd0N1VGY4QW9KcS9lREY1YnQ2cGo5YW9mRVVIL2hYMS93RDljbS85 Qk5BRlg0VC9BUEpNTkYvM0gvOEFRelhaQ3VOK0UvOEF5Uy9SZjl4Ly9RelhaQ2dCeS9lSDFyNXAw KzAxYnhGNHlsMGkxMVdlQ1NXNG0ydTh6N1YybGoyK2xmU3EvZUgxcjVzOE82emErSHZpSTJxWG9r TnZEY1Q3aEV1NXVkd0dCK05BRzlyWGdyeHA0VDA5OVhnMXlXZUtENXBEQmNTQmtIcmh1dGQ3OE1m R2R4NHEwcTRnMUFocit6Szc1RkdQTlEvZGJIcndRYTVyeFo4VzlMMUh3OWQ2ZnBWdGN0TmRSR0pw SjFDcWlucWVweWNWZitEWGh5ODB2VDczVmIySjRmdG0xSVkzR0NVWG5jUjdrL3BRQjZqVVUvOEFx aWZUbW41cGt2TWJVQVlzdjd2VjVQZHQzNTFoZkZ6bjRkWG4rNGEzYnRmK0puRTM5NUZyQytMZ3g4 T2J6L2NOQUdyOFAvOEFrbmZoL3dENjhrcm9oWE8vRC84QTVKM29IL1hrbGRHS0FCdVZJSEdSWGpV bndvOFY3bmRmRWNZWGx2OEFYeTE3TFNTSDkwLys0ZjVVQWZOSGhpdzF2eFJyUDltV2VzVHd5K1cw bStXZVRiaGZwWHEzZ2Z3UDRnOE8rSURmYXByQ1hkdDVMUitXSnBHK1k0d2NOeFhDZkI3L0FKSDgv d0RYck4vU3ZmcUFIVkZPY0lHOURtbjB5Ym1KdnBRQmdrZVZxMHE5UG5ya3ZqY2YrS0UvNEd2L0FL RXRkZmRER3NaL3ZCVCtsY2g4Ymhqd0gvd05mL1Fsb0E5RjhKZjhpcnBIL1huRi93Q2dpdGk5YlpZ eWZURlkvaEwvQUpGWFNQOEFyemkvOUJGYWVwdHRzc2VyQ2dESEI1cGMwd0dqTkFIaVBpdGRWOERl TjRieTN1cnFTeWVUN1JBanlzeWxjL05HY250eitZcjJDTFdMS1hSVjFnVEFXSmc4L2Y2TGpQNTFt ZU5mRHFlSi9Ec3Rtb0gycVA4QWUyekhzNDdmUTlQeHJ4RmZFZXBRK0ZKZkMrMXdqWEc0L3dCNVIz angvdmMwQWIrZ0RVZkgzanVhNW11TGlPeFYvUG1SSldWVmpIM1U0OWVQMXIyM3B3QmdlbGMzNEg4 T0R3ejRkaWdrVUM4bS9lM0ovd0Jyc3Y4QXdFVjBWQUMxNXQ4YlArUlNzdjhBcjZGZWtWNXg4YlAr UlNzdit2b1VBZTBXUC9IbmIvOEFYSlAvQUVFVTdVRzIyVCsrQlRiSC9qenQvd0Rya24vb05NMVZz VzZEMWFnRExCcFI5NFV3R2xVL01QclFCNFo0THZidVg0cFJ4U1hkdzhYbjNIeU5LeEhSdTFlNDU1 cndid1IveVZXUC9yNHVQNU5YdkhlZ0R3elRycTVQeGdXSTNNNWkvdFNRYkRJMjNHVzR4WHVSTmVE NmIveVdSZjhBc0tTZnphdmRqUUFHdk1makgvclBEUDhBMS9wLzZFYTlOcnpMNHgvZjhNLzlmNmYr aEdnRDNKUHZWRHFUWXRjZjNtQXFaZnZWVTFWdmtqWDN6UUJRQm9KcG9OSm1nQmE4TCtITjdkemZF YU9PYTd1Skk4VC9BQ1BLekRvZTJhOXlKcndYNGEvOGxKaitseC9JMEFlOGswM05CTkptZ0Fyekg0 bGY4ajc0TS82K2svOEFRaFhwcE5lWmZFci9BSkgzd1ovMTlKLzZFS0FQY1FQblAxcXZxYllnUmZW cXNML3JEOWFwYW8zenhENm1nQ29LcTZscU50cE9tM0dvWGo3TGUzUXU1OXZRZTU2Vk9EWEFmR0s1 ZUx3V2tLRWhaN3BGZkhvQVcvbUJRQndzK3QrTFBpVnJUMlduUEpCYWo1dklqazJSeEo2dXc2bi9B RGlyVjE4TFBGT2wyNXZMSFVZN2llTWJqSGJ5dWpuL0FIZld1dCtEdG5GQjRRbHVsVWViY1hUYjI5 bHdGSDg2OUF6anJRQjVaOE9maUJlWDErdWc2NUlaSm4rVzN1SDRjc1A0RzkvUTE2aVRYZ0hqV05k SitLRTB0cjhoRnhGY0RiMlk3V1A2NXIzMG5KejYwQUJyekh4Yi93QWx6OEhmNzM5SzlOTmVaZUxQ K1M1ZUR2OEFlL3BRQjdjbjNqVmZVbStXTmZmTldJL3ZHcVdwSE02RDBXZ0NBZEtSemhHLzNUU1pw cm45Mi84QXVtZ0Q1dDhPMmV0ZUtkZU9tVzJzWEVNakIzM3l6dmpDL1ExdWEzNGU4WitCWVUxUk5a bGxnREJYa2huZGdwUFRjcmRqV2I4T3RYc05EOGFmYmRTdUJiMjRpbFh6R0JQSjZEaXV2K0lueEIw VFUvRFUyazZWT2J1VzRaZDdoQ3FJb1lOMzZuaW1CMkhnUHhTL2l2dzk5cHVGVmJ5Qi9LbjJkR09N aGdPMlJYVEUxNTU4SHRObnN2Qzl4ZHpvVVc4bjh5SUhqS3F1TjM0bk5lZzBnRnpYalh4Si93Q1Ny V1gvQUY0dC9NMTdIWGpueEkvNUt0WmY5ZUxmek5BRUVmM0JYUDhBaWova0dULzd2OWE2QlA4QVZp dWY4VDg2WlA4QTd2OEFXcUVlZHRUb3Z2Q2c4MHFKeUJWV0EwSS92TFZ4ZWxVNHpobHEyR3JkYkVn MVFQM3FacWpZVUFRR20xSTFSMURBYTJhaGNjVkt4cUZ6VXNaQTlSR3BXRlI0ck1hTEZ0OTZ0QzNI SjRyUHR4aDYwSUc3VnBBVExKNlZDOVNaeUtqYXRYc0lnZnJVUnFaaFVaRlpzQ1B0VFdweEhGUnRV TWFJbnFGdXRUT2FoYmsxREdJS3VSZmRGVXdLdVJjSXRWRVpveC9kRksxTlJ2bEZLeDRyWkVFTG1x N1ZZZm1vR0ZTd0k4VWg2Y1U0OFV3bW9ZMFJ0VVRZcVZxaGJtb1l3cDBmM3hUUlRrNGNVRExIOFFy UWorN1dlRDh3cThHNEZheEpCdTlWM3F3eHFCNmJBcnRUZTFTTlVack1ZaDZWSFR5YVpTWUFVYjBv Mk42VmJHRFQxVVUrVUxsRUt3N1U3QkI1cS81UXgwcU40aGlueWl1UUNwUVZYaklxRW5DazFFV1kw cmpMd2xVZDZlSjFIZXN6SnB5MEtZV0w3VGoxcUV0dU9haEE2MUl1TVUyN2dOYUlnWkZSK1VjOUt1 S1JpcEZBejBvNWJpS0lqWUg3cHAyMWdlbGFBVE5LWXdCMHBxQU1vcHlhbGo2R2xrakNkS2hrY3FC aWpZTEZvTW83MDhTcUI5NnN3dWFBeHpTNWdzYW5uTGpyVWJ6QS9MMXFtTTA5Ujh3cXVZQ1RQSGVv bmhJNXhVdzYxTXB6U3RjQ2lJV0g4TlBFVGVocThvQnA0VDJwcUFHZnRZZGpVaUhpcmhqRlFTTHNi RlBsc0FxWTI4MDhNb1BXcWNybFd4MjYxRnZPYVhOWURURXFqdlMrY3BIV3N3RTVxUVpwOHdGdHBj amJVYkp2R0tZb09hbVRpamNSV2FBNTZVZ2hZZncxZkZQQ2lueURLQ28vcFQrVnhWL1lQU21OR0RU NUJYSUY3VktDQlVST0FUNlZXZVVrMHIyR1h4SXVldFA4MVIzckxFbWFlckdsekJZMEdtSFkwdHFk OTlCLzEwWCtkVWxxNXA0LzA2My9BT3VxL3dBNnErZ3JIdjJnL3dESVBoLzNCV1g0Ny80OGJQOEE2 NnQvS3RYUXYrUENIL2NIOHF5dkhmOEF4NDJmL1hWdjVWemxGMzRJL3dESXZlSVArd3MzL29LMTZU WG12d1IvNUY3eEIvMkZtLzhBUVJYcFhha01YQUl3d3lEd1JYenRkUlh2d3orSW91QkNXZ2prWjR1 d21nYnNEOUQrWXI2SXJPMW5RdE04UTJYMlRWTFNPNGl6bFNlR1ErcXQxRkFHVGFmRWJ3bGQyWXVQ N1loZzR5WXBzcTYrMk1meXJ5YjRoK0xQK0UzMXV6MC9Sb1pKYldGaWtBMi9OTkkzOFdQeUFyc3Iv d0NDdWp0Rk85aGYzcVM3R01VY2pLeTdzZktDY1p4WEtmQ2k0bTBqeHJOWVhHa1NUM0RxWW5rRVda TFZoMUo5RjdIOEtBUFkvQ21pL3dEQ08rRjdEU3lRWklZLzNwSFF1Zm1iOVRXelRhS0FNMjhYTVEv MlpmNlZMclF4NFp1eC93Qk1qUk91NUpCNk9wcGRjR1BEbDJQK21Kb0E0RDRIL3dESW1haC8yRXBQ NUN2U2E4MitCLzhBeUplb2Y5aE9ULzBFVjZUUUEyZUZMbTNsdDNHVWxSa1lIMEl4WHlzMDF6by85 cWFYbmFzcDhpWWY5YzN6L05hK3JLOHkxNzRRUjYxcjE1cVNhdjhBWjB1cFRJWWZzKzdibnJ6dTlh QU5YUWZEKy80T3JwUlQ5NWRXTWtwSCsyMldIL3N0ZUN5YWhjUzZUYjZhMytxZ2xrbFFmN1RoUWY4 QTBHdnErQ0pMZUNLRkJoSTFWRkhzQml2THg4R1locll2djdYL0FOSEZ6NTNrZlovNGQyN2J1M2Zo UUI2SjRmc0JwZmgzVGJBREhrVzBhRWUrMFovWE5hQm9KeWMwVUFaZDR1VmhQcEt3cVB4Y01lRGI3 L3JsVm1kZHlmU1VmeXFEeGdNZUQ3OGY5TXFBT1MrQ2YvSkw3VC9yNW0vOUNyMEd2UDhBNEovOGt2 dEQvd0JQTTMvb1ZlZ1VBTFhndnhuSC9GYlIvd0RYbEgvTnE5NXJndkdmdzEvNFM3VzAxTCsxUHN1 MkZZdkw4amYwSk9jN2g2MEFkaGFhanAvMkszLzB5MXo1U2NlY3Y5MGU5V283cTJuSldDZUdRamtp T1JXUDZWNUgvd0FLTS82ajMva3Ivd0RaVjB2Z2Y0Yy84SWJxMDk5L2FmMnJ6WWZLMmVUc3g4d09j NVBwUUIzbEIrN1NVVUFaVjJ1WHRUNkZoK3RaM3hIR1BoOWYvd0RYSS84QW9KclhuVEloUDkyVTFs ZkVrZjhBRkFhai93QmNqL0kwQVVmaFIveVMvUmY5eC84QTBNMTJOY2Y4S1IveGEvUlA5eC8vQUVN MTJGQUNyOTRmV3ZuYndmWTJ1by9GRmJXOXQ0N2kzZTR1TjhjaTVVNDNkcStpUndjMTU5b1B3eC9z UHhhbXUvMnI1MjJTU1R5ZkkyNTNaNHp1N1pvQTRyNG1lRmYrRVUxdTExdlI0aEJaeXVwVlVIeXd6 TDdlaDYvblhyZmhMeEpENHI4UFFhbEhoWnZ1WEVZL2drSFVmVHVQclZyWE5IdHRmMFc1MHU2SDdx WmNCdTZOL0N3OXdhNWJ3VDRBdS9CdW95ekpyUXViYWROc3R1WUNvWWo3ckE3dUNLQU83cHJmZE5G QjZVQVpOMHVicTFQK3pqOWF3ZmkrdVBoemVmN3BycEprekpiSDBaaFhPL0dIajRkWHYrN1FCb2VB UCtTZCtILyt2Sks2S3VkOEFEL2kzbmgvL3J5U3Vpb0FLYkovcW4vM1QvS25VakRjckw2Z2lnRHdU NFAvQVBJLy93RGJyTi9TdmZhNER3ZjhORDRVOFFmMnAvYXYybjkwOGZsK1J0Kzlqbk80MTMxQUMw MlQ3amZTbHBHKzZhQU1pNlhPcFc3ZXNZcmp2amtNZUEvK0JyLzZFdGR4S21icTFiL1pJL1d1SytP b3g0RS80R3YvQUtFdEFIZmVFLzhBa1ZkSS93Q3ZPTC8wRVZvYXVjUVJqL2FyUDhLZjhpdm8vd0Qx NXhmK2dpcm1zSDVZeDlhQU1zSGlnbW1nMFVBTG12Q3J0Vi80WEtSdFhIOXFyeGpqcUs5enpYQ3pm RHN5ZU16NGgvdFBIK2xDNDhqeWZUSEc3UDhBU2dEdWpTVVVZb0FLODQrTm4vSW8yWC9YMEs5R3J6 bjQxLzhBSW8yWC9YMFA2VUFlMFdQL0FCNlczL1hKUC9RUlVHcm5pSWZVMUxZbi9SYmIvcmluL29J cXRxNS9lUmovQUdhQUtGQU9DS2Jta3pRQjRIcGQxSDRYK0tMVGFobU9LRzhsV1JzZmRWczRiNmZN RFh0ayt2NlBiV1p2SmRUdEJiZ2J0NG1VNUh0anJXSDRzOEJhZDRwa0YwWkh0TDVSdDgrTlFRNDdi aDMrdGNjdndZdVJKODJ0UWhNOVJiblA4NkFNVHdtVzF2NHFSWGtDTUkydXBMbzVIUk9UL1Vmblh1 MWM5NFc4SDZiNFV0M0Zwdmx1WlFCTGNTZmViMkhvSzZDZ0FyelA0eGZmOE1mOWY2ZitoVjZaWG1m eGorLzRaLzYvay84QVFxQVBjaysvVkhWbS9lUmoyTlhFUDcwL2hXZnFoLzBsZjkyZ0NwbWtKcHVh TTBBQnJ3ajRhLzhBSlNFK2svOEFJMTd0bXVEOE5mRG4vaEhmRWk2di9hbm40RWc4dnlOdjN2ZlB2 UUIzZWFRMG1hS0FDdk5QaVYveVBuZ3ovcjZUL3dCQ0ZlbFY1cDhTY2Y4QUNlZURQK3ZwUC9RaFFn UGNWLzFyZldzL1V6bTRVZWkxZFQvWHYvdlZuYWlmOUxQc29vQXI1cmsvaVJvMDJ0K0RMbUszVGZQ YnN0d2lqcTIzcUIrQk5kWG1tNXhRQjQvOEovRjFscHNNMmlhbE9zQ3lTZWJieXlIQzdpTU1wUGJv TVY2ZnFPdjZUcFZrMTNlWDl2SEVvenhJQ1c5Z0Ixcmt2RW53czByV3JxUzhzcG0wKzRrTzUxUmQw YkgxMjl2d3JBdC9ndEw1dyswYTNHSTgvd0RMSzNPNzlUUUJ6bW5KUDQ4K0pQMmtSTUlwTGdUeVov NVp3cVJqUDRBRDZtdmZpY21zYnc5NGEwend4WkcyMDZJaG13WlpYT1hrUHVmNlZyMEFIMHJ6VHha L3lYTHdkL3ZmMHIwcXZOUEZuL0pjZkIvKzkvU2dEMjJQN3grdFVMODV1ejdLS3V3bjV6OWF6cnc1 dkgvQ2dCbWFaSWYzYi83cG96VFhHNUdYT01qRkFIenY0QjBPdzhSZUxUWWFpanZibUtSOEkrMDVI VG12WGJMNGJlRk5QbUVxYWI1ektjajdSS3pqOGp4V2I0UytIQjhMNjkvYWgxVDdUKzdaUExFTzM3 M2ZPVFhkazBBS0FGVUtvQ3FCZ0FjQVVoTkpuMHBLQUY3MTQ3OFNmK1NyV1gvWGkzOWE5Z3pYajN4 Si93Q1NxMlgvQUY0bit0QUVTZmNGWUhpVVowMllBZHY2MXZKOXdWaTY5L3g1eWZTclc0anovd0Fr NSs3VWlRZXVSaXJoVUNtc2VLMTViRWtRNE9SVXF5cjNOUW5wVUpHS0wyQXVtVWV0SVpGeDFxZ3hx TXVSUzV3TkhLbW8yNjlhcUxLUjA2MVlSdHdvVHVNWStjOFV3bzU3VmRqajR6am1wTmdwOHR4R1dZ V1A4Sm9FQi91MXBrQVZHUlM1QmxSSTluYXBsY0lhVnpVTFViQ1phRXkrdElaVi92VlJPUUtqWnFY TVZZMERJdnJUVGdqam1zL2VjMUlrbUc0NzB1YTRXSm02VkVRVDBGVHFNc0JWaFl3RDBxdVc0ak9N Ym50VGZKUHBXb1VGTUlIcFM1QXVaNlFNVDBxWUx0WEZUTnhVVGQ2VnJCY2ZITm5nbnBVdm5ML2Vx aXdwaEpGSE1CZk1pLzNxWVdVOTZvRnNVQno2MHVZZGkzSU9haWZnaWlObWZyVTBVWWJPUjBvV29p dHRZOXFhWTJQWTFwQ01lbElWQXB1bU5HYjVURHRUMWp4emlyYllxTnZ1MHVXd0VlT2FtV2JuQnFI dFVSR09sSzRpNzV3ejFwcGtYMXFpYU0rOVBtSFl0bGxOUnQxcURQTlNLMlJTVHVBMXMwbTAxYVNN RVpxVVJpbnlqSUZOV0krYXJwVmlLbWlTZFJUWkY0L0NuclRaZUZxM3NJelgvd0JYVU5UUDl5b2F3 ZTVhRTcxSXRSOTZrV2dHU0FVOENrRk9xaENxYW1RMUNPdFRKVklSWVFaRlNoY2lvNHh4VW9yVkNL bHlPRnFoUDJxL2NuZ1ZRbjdWbE1hSWFlbldtVTlLeUtKMXFRQ28wcVVWb1N3NzA5VFRPOVBYbW1J bVNyQ2pOVjQrS3NKMEZhSUJ4RlZKL3dEV2ZoVnc5S3B6L3dDcy9DbkxZQ2pjWkVoK2xRZzgxTmNm NncvU29SMXJuZTR5VmFuVVZBZ3F3b3FrQThVOGRhYUtjSzBFU0xVeWRLZ1hyVTZkS3BBU2dVTU9L QlN0MHF4RkNYbzFVQ2VhMEpQdXRXYytOMWM4eWtPWG1wMEJxQktzSlNReVpSVnF4NHY3Zi9ycXY4 NnJMVm15L3dDUCszLzY2ci9NVm9TZSs2QzZHd2krWVoyRHZXVDQ3a2oreDJhN3huelNjRSsxYXZo dlNMUFV0TkJ1VmtPTUFiSkNuWWVsV05WOElhYmJSeFRMUGVLck50SytadjhBNTFnV2N0OEhQRTJs NmFQRU9sWDkzSGJYRWw2TGlKWkcyK1l2M1RqUDBINTE2a05lMG9qSXZvZisreFhuVjc0RjhOWDhw bW0rME5NMzNuYU5HSnF0L3dBSzY4TWVzLzhBMzRqcEFlbi9BTnU2WC96K3cvOEFmWW8vdDNTLytm MkgvdnNWNWgvd3Jud3ovZXVQKy9FZEwvd3JydzEyZTRIL0FHd1NnRDA3KzNkTEgvTDdELzMyS2F1 cjZNa3NrcVQyeXlTWTN1dTBGc2RNbnZYbWYvQ3V2RFg5KzQvNzhSMGY4SzY4TS84QVBTNC83OFIw QWVualhOTTZmYkl2Kyt4VHY3YjAzL244aS83N0ZlWGY4SzY4TmY4QVBXNC83OFIwZjhLNjhOLzg5 cmovQU1CMC93QWFBUFNtMWpUZDBoYThpQ25HTXNPZWF6L0ZuaXZSTEx3emVPK3BXK1RFVlVCeGxq WEMvd0RDdXZEZmVhNC84QjAveHBSOE9mQ3hQek5jSC90aEhRQlgrQ1hpclNiWFFOUjA2OHZJb0xr M3BtUkhjRGNyS09tZmNWNm1OZjBvOUw2SC92c1Y1dko4T3ZDTGdiVXVWLzdaUm1tLzhLNThLLzNy a2Y4QWJDT2dEMHYrM3RLLzUvWWYrK3hSL2IybC93RFA3RC8zMks4MC93Q0ZjK0ZmNzF6L0FOK0k2 WC9oWFBoWCsvZGY5K0k2QVBTLzdkMHYvbjloL3dDK3hTLzI3cG4vQUQrdy93RGZZcnpQL2hYWGhZ Zjh0THYvQUw4UjBmOEFDdWZDM2FTNi93Qy9FZEFIcG45dWFaL3orUmY5OWlsL3R2VFQvd0F2a1gv ZllyekgvaFhQaGY4QTU2M2YvZ1BIUy84QUN1ZkRIL1BhNy84QUFlUC9BQm9BOUdiVjlOdzVhOGhB M0E4dUt4ZmlCNHIwUzA4SDNvL3RDQnBKSTlxSXJnc3hya2g4T2ZER2VacnMvd0RidkgvalQxK0hI aExjQzdYWngvMHdqb0FUNExlS3RJdC9BNDB1NnZZb2J1QzZrYnk1R0NrcTJDQ0s5Si90L1N2K2Y2 SC9BTDdGZWNQOE9mQnpINVV1MS83WXhtbS84SzQ4SmYzcnYvdnhIUUI2VC9iMmxmOEFQN0QvQU45 aWorM3RMLzUvWXY4QXZzVjV0L3dyandsL2V2UCsvRWRIL0N1ZkNlUDlaZWY5K0k2QVBTdjdlMHYv QUovb2YrK3hSL2J1bUgvbDhoLzc3RmViZjhLNThKLzg5THovQUw4UjBuL0N1ZkNuL1BTOC93Qy9F ZEFIcGY4QWJtbWRyeUwvQUw3RkwvYldtbi9sOGkvNzdGZVovd0RDdWZDdi9QVzgvd0RBZU9qL0FJ Vng0Vy81N1huL0FJRHgvd0NOQUhvaDFmVGNmTmVSRDk1bmx4NlZ6SHhVOFZhUEY0SXZMZU8vZ2t1 SjEyUnhvNEpKd2UzNDFoRDRjZUZ1ODE0Ui93QmU4ZjhBalRsK0hIZzhNQzV1MkhwNU1Zb0F0L0NU eFpvMy9DdnJEVDU3K0dLN3RXa1I0bmNCc2JpUWYxcnZCcjJsSHBldy93RGZZcnptVDRjZURHYktM ZG9QVHlvelNmOEFDdVBDSDk2OC93Qy9NZEFIby84QWJ1bC84L3NQL2ZZby90M1Mvd0RuOWgvNzdG ZWNmOEs0OEkvMzd6L3Z4SFIvd3Jud2wvejB2ZjhBdnpIUUI2Ui9idWwvOC9zUC9mWW8vdHpUUCtm MkwvdnNWNXYvQU1LNDhKZjg5YjMvQUw4eDBuL0N1UENYL1BXOS93Qy9FZEFIcFA4QWJlbWY4L2tY L2ZZcDM5dGFiai9qOGkvNzdGZVovd0RDdVBDZi9QYTgvd0MvRWRKL3dyandyL3oydlA4QXdIai9B TWFBUFF6cTJtZ3hGN3lFWWtKNWNWeGZ4bThVYVFmQmNsakJmUXpYTTUyckhHNEordFVCOE9QQ3Y4 VTE2ZjhBdDNqcDZmRGp3YXJaZjdhL3Q1VVlvQTJ2aHQ0dTBTYndEcEZzMS9DbHpiUWVUTEd6Z01w QjlLNjMrM3RLL3dDZjJIL3ZzVjV3L3dBTi9Cak5sQmVyN2VUR2FUL2hXL2c4ZngzMy9mbU9nRDBq KzNkTDdYc1AvZllvL3QzUy93RG45aC83N0ZlYmY4SzM4SC8zNzcvdnpIUi93cmp3aC96MHYvOEF2 ekhRQjZUL0FHN3BmL1A5RC8zMktYKzNOTHp4ZXcvOTlpdk5EOE9QQ1A4QXoxdi9BUHZ4SFNmOEsz OEpEcE5mZjkrSTZBUFRQN2Iwei9uOGkvNzdGS2RaMDBqL0FJL0l2Kyt4WG1QL0FBcmp3bWYrVzkv L0FOK0k2YWZoeDRWN1hGOS8zNGovQU1hQVBSanErbUNTQXZlUXJ0TGRYRmVkL0hQeExwTng0Wmgw NjB2WVpyaVNRTnNqWU1RTWc1UDVVZytISGhUK0s0dno5SUk2Zkg4T1BCaXRsL3Q3L3dEYktNVUFk cDRGOFg2SmVlRWRKSzM4UWtpdFk0NVVMaktNb3dRUld6cWV0YWRPeWVYZVJFQmY3NHJ5OS9oeDRO M0VvOSttZittVVZNUHc0OEs5cnEvSC9iQ1AvR2dEMFA4QXRTdy81KzRmKyt4U2YycllmOC9jUC9m WXJ6My9BSVZ2NFUvNSt0US83OFIvNDBmOEs0OEpZLzQrZFIvNzh4MEFlZy8ycllmOC9jUC9BSDJL VCsxYkQvbjdoLzc3RmVmZjhLMzhJLzhBUGZVZisvTVZIL0N0L0NIL0FEMzFIL3Z6RlFCNkQvYXRo L3o5dy84QWZZcFA3VXNQK2Z1SC92c1Y1OS93cmZ3aC93QTk5Uy83OVJVZjhLMzhILzhBUGZVdisv VVZBSG9QOXI2ZXE4M2tJLzdhQ3ZMZmpSNGkwMjYwYXcwK3p1NHA1eE41anJHNE8wZStLMFQ4Ti9C MmY5ZHFmL2ZxS2xqK0hIZ2xDZDUxSi84QWdFYTBBZW1lSHZHT2hhbHBGbGN3YWhDUTF2R0dHOFpW dHZJTldOUjFuVHBwZ1V2SWlBdlhlSzhvYjRiK0R0eEtUNmt2MGlqcU0vRGZ3ci96KzZsai9yaEgv alFCNmIvYWxoL3o5dy85OWlrT3E2Zi9BTS9rUC9mWXJ6TWZEZndvUCtYelUvOEF2ekgvQUkwdi9D dC9DZmU4MU0vOXNZNkFQU3Y3VjAvL0FKKzRmKyt4Ui9hMWgveitRLzhBZllyelQvaFczaEgvQUor dFQvNzlSVXYvQUFyYndoL3o4NnAvMzZpb0E5Si90V3cvNSs0disreFNmMnRZZjgvY1AvZndWNXQv d3Jmd2gvejg2cC8zNmlvLzRWdDRQLzUrTlUvNzlSVUFla0hWOU9YNzE1Q1ArMmdyeVg0eGVKdE51 YnpSSUxPNmp1SHRaZk9sOHB0MjNCclMvd0NGYmVEajF1TlVQL2JPS254L0Rqd1NvSVp0VWNuL0FH WWhpZ0QxblR2RjJoYWhCSGRXK293UEhJaXNDSEhwVEwvV05PbXVDeVhrUkdBTTd4WGtyZkRYd2Y4 QXdYT3FMLzJ5aXBuL0FBcmJ3djhBOC8ycWY5K1kvd0RHZ0QxVCsxZFAvd0NmeUgvdnNVMDZ0cCtQ K1B5SC92c1Y1ZC93clh3cjN2TlVQL2JHUC9Hai9oV3ZoTTlielZQKy9VZEFIcUg5cmFmL0FNL2tQ L2ZZcFA3VzAvOEE1L0lmKyt4WG1QOEF3clh3bC96OTZyLzM2aXBmK0ZhK0VmOEFuNjFYL3YzRlFC NmIvYXVuL3dEUDVELzM4Rk4vdGJUL0FQbjhoLzcrQ3ZOUCtGYStFUDhBbjYxYi92M0ZSL3dyVHdm L0FNL09xLzhBZnVLZ0QwcHRZMDFSbHIyQUQza0ZlUmZFenhWcGtuanJ3N0phM1VjMFZoSWtrN3h0 dUMvTVBUNkd0UDhBNFZwNFA3M0dxbi90bkZUMCtHM2dwVklaOVZadlhiRU1VQWV2MmZpblJMc2Vm QnFNRHhTZk1yQnhpcTkzcStueTNEdXQ1RnQ0L2pGZVNINForRWY0THJWRi93QzJVVk4vNFZuNFkv NS90VHgvMXhqL0FNYUFQVmpxMm4vOC9rUC9BSDJLYWRXMC93RDUvSVArK3hYbGcrR25oYnZlNm9m KzJVZEgvQ3MvQ2ZUN1pxbi9BSDZpb0E5Uy90ZlR2K2Z5RC92NEtUKzE5UDhBK2Z5RC92c1Y1ZjhB OEswOEpmOEFQNXFuL2Z1S2ovaFduaEwvQUorOVYvNzl4VUFlbi8ydHAvOEF6K1EvOS9CU2YydnAv d0R6K1FmOS9CWG1YL0NzL0NQL0FEOWFyLzN4RlIvd3JQd2gvd0EvT3EvOThSVUFlbHRyT21JTXRm VzRIcVpWcnlMeGY0dDBvL0dQUWIrSzdqa3RMQmtFMHlObFZ6MTU5cTAvK0ZaZUR6L3k4NnIvQU44 UlU4ZkRQd1dJOXBiVkMzOTdFWDhzVUFldjJ2aVhScGYza2VvUU1qZk1yQnhnaXEwK3I2ZTl3N2k4 aHdUL0FIeFhrcCtHUGhMK0M3MVJmKzJVZE5Id3g4TS84LzhBcWY4QTM1ai9BTWFBUFdQN1cwNy9B Si9JUCsreFRUcStuZjhBUDdCLzM4RmVWZjhBQ3NmQy93RHorNnAvMzZqcGYrRlllRmNmOGZtcWY5 K282QVBVanErbmY4L3NIL2Z3VW45cjZkMCsyUWY5L0JYbC93RHdyRHdwL3dBL2VxZjkrNDZYL2hX SGhQOEE1KzlVL3dDK0lxQVBUanEybmY4QVA1Qi8zOEZKL2EybmY4L2tIL2Z3VjVsL3dyRHduL3o5 YXIvM3hIUi93cS93bC96ODZwLzN4RlFCNlkyczZZZ3k5OWJxUFV5Z1Y0ejR2MXF5MXo0ckNXd25X ZTN0N1h5aktoeXBibk9EK05iWC9DcnZDSi81ZU5VLzc0aXJRc1BBZmhiVGxiN05jYXZHNzhPeU5H dTc4TVVBWVVSQmo0NStsWXV2QWl6azRQU3ZUYkx3YnBtMTMrMWFqS203NUE5eHQ0d091MnVZOGZX a1ZscE04RVBtZVdBckFPNVlqazl6OUtwYmlQS1dOUk1ha2Jpb3pXNUkzdFViQ3BPMU1ha0JBOVYy TldINlZXYXMyVUlEVjJBL3V6VkR1SzBJZnVVUUI3RjZNRGJUeUJUSWZ1MUllbGRDSUlINjFFeHFW Nmhhb1pRd25OTUlwMUlha1JDNHFCNnNQVUQxREdpRW1ub2ZtSDFwaHA4WDNoOWFnbzBZY2J4Vnph S294ZjZ3VmZIU3VpT3hBeHNWWGM4bXJEVlhmcWFHQkN4cHZhbGFtOXFnQnBIRlJNS2xhb25xQm9o YnJTVXJkYVNvS0pvRDFxOWFqT2ZyVkdEdlY2MTZINjFyQVRMQldvbjRxYzFCSjByUmtsZGpVWk5Q YnJVWnJKakVOTUlwOU5OSmpJbTYwMm5QMXB0UU1La1Q3dFIxSW4zYWFBdlFMbU5hbHg3VkhiZmRY NjFLYTNSSlJVVllpcUVWS3B4VW9Dd3RKSVJzTk04ekFxTnBBVk5OdlFDcko5dzFCMHFkaGxUam1v U0RXVFEwTjcxSXRNd2FjS1Zoa3dQTlB6VUlPS2tYbXFRaDZpcGtGTVFjVklwcWtJc1I4Q3BNNEZR SzJLVm40NHJRVmlPNjVBcWhPT0JWdVp3Y0NxOHE1QXJPWTBWcWVsQlRtbEF3YXpzVVRMVWdxRVp6 VWlubXJFUHA2MHdkYW1VVlNFUFNyQ2RLaFhpbmc0TldoRXBOVkovOVorRlRsdVBTcTBqQXRrVVNZ Rk80L3dCWWZwVUk0TldaVUpmUGJGUTdlYXhhS1d3NWV0VHJVSXFSY2ltZ1pPS2NPdFJxY21wVkdh dGFramxxZEtqQXhUMXF3SmhRVHhUQTJLYXpjR3F1SXJ5L2RhczRqbXRGdVFhcXRIN1ZsSkZJaVhy VThkUmhha1dwU0d5ZFRWcXkvd0NQKzMvNjZyL01WU1U0cTdwLy9IOWI4LzhBTFZmNWlySlBvcndZ Vi9zN2J1RzdJT1B3RmFmaVdlRzMwNjM4NlZFM1M4YmpqUEJyazlPMHVLOTArTGZOS2gyRGxOdjlR YXcvRStrejZYSEJMRHFrN3BJeFhiSkZHMjN2eDh0WVdMT21Hb1dSL3dDWHFML3ZxbC90Q3kvNStv disrcTgwOEllRGRZOGZhcnFzOG1zeldsbFpTQ0ptaitVczNPQUZIQTRHVFhhajRJREgvSXphbWY4 QWdkSURWL3RDeS81K292OEF2cWorMExML0FKK292KytxeXY4QWhTUHA0bDFQL3Y1U0g0SUgvb1pO Uy83N29BMS83UXN2K2ZxTC92cWorMExML242aS93QytxeC8rRklQL0FOREpxWC9meWtQd1FsSC9B RE1lby84QWZkQUd6L2FGbC96OVIvOEFmVkg5b1dmL0FEOHgvd0RmVlk0K0JzcDUvd0NFbXZzZjc1 by80VWU0NitKNzhmOEFBNkFOaiswTEwvbjZpLzc2by90Q3kvNStvLzhBdnFzYi9oU1dPdmlqVVA4 QXZzMW1hMzhIcnV3MHU0dTdQeExlU3ZFbTdZN0dnRHJQN1FzditmcUwvdnFqKzBMUC9uNmovd0Mr cTh2K0h2Z0xWL0cxdGVYazJ0WFZyYTIwdmtmSzVKWnNaUDREaXU1SHdRR1ArUmwxTFA4QXYwQWEv d0RhRm4vejlSLzk5VXYyK3ovNStvdisrcXgvK0ZJZjlUSnFYL2ZkQitDQjdlSk5TLzcrVUFhLzlv V2YvUDFGL3dCOVVmMmhaZjhBUDFIL0FOOVZqLzhBQ2tIL0FPaGoxSC92dW1uNElTLzlESHFIL2Zk QUcyTCt6LzUrWS84QXZxayszMmYvQUQ4eGY5OVZqajRHVEgvbVpyNy9BTCtVbi9Dam5IWHhQZjhB L2ZkQUcxOXZzLzhBbjZpLzc2byszMlgvQUQ5UmY5OVZpLzhBQ2tjZGZGR29mOTltc1R4TjhKTDdS OUZ1TlFzdkVkM09ZVjNHTjNOQUhhL2I3UDhBNStvdisrcVB0OWwvejlSZjk5VjVyOFBmaDNxbmpQ UjMxYTUxeTZ0Ylh6V2lqQ3VTV0k2bm50elhaLzhBQ2tCLzBNMnBmOTkwQWEvMit5LzUrWXYrK3FQ dDluL3o4eC85OVZqL0FQQ2tQK3BsMUwvdnVrLzRVZ2YraGsxTC92dWdEWiszMlgvUHpILzMxUjl2 c3NmOGZNWC9BSDFXTC93cEIvOEFvWk5SL3dDKzZRL0JDWC9vWk5RSC9BNkFOejdmWmY4QVB6Ri8z MVI5dnMvK2ZxUC9BTDZyRi80VVpOLzBNdDkvMzhvLzRVYy9meFBmai9nZEFHMS9hRmwvejlSZjk5 VWZiN1AvQUorby93RHZxc1QvQUlVampyNG8xRC92czF6bmpINFc2aDRjMEtmVkxUeERkWEN3akxv N2tjVUFkOTl2cytuMnFQOEE3Nm8rMzJYL0FEOHhmOTlWNTc0RStHV3BlTFBEMFdzM212WGR0RE03 TEVxT2NrS2NaTmRWL3dBS1FYL29adFMvNzdvQTJQdDlsL3o4eGY4QWZWSDIrei81K1kvKytxeC8r RklEL29aZFIvNzdwUDhBaFNCLzZHVFVmKys2QU5uN2ZaLzgvTWYvQUgxUjl2c3YrZm1ML3Zxc1Qv aFNELzhBUXlhai93QjkwaCtCOG4vUXlhZ1BxOUFHNTl2cy93RG41aS83Nm8rMzJmOEF6OHgvOTlW akQ0RnpmOURMZmY4QWZ5ay80VWM0NitKNzhmOEFBNkFObjdmWi93RFB6Ri8zMVI5dnMvOEFuNmov QU8rcXhUOEVjZjhBTTBhZ1ArQm11VDhkZkRYVWZDV2lOcWxycjkxY3hJd0RxemtFVUFlamZiclAv bjVpL3dDK3FUN2ZaLzhBUHpIL0FOOVZ4SGczNFQ2aDRpOE9XbXIzM2lDOHQxdWwzeHh4dWZ1NTdt dWgvd0NGSEovME0rbzUvd0IrZ0RXKzMyZi9BRDh4L3dEZlZIMjZ6LzUrWS84QXZxc2ovaFJ3L3dD aGwxRS84RHBQK0ZIZW5pVFVQKys2QU5mN2RaLzgvTWYvQUgxUjl2cytuMm1ML3Zxc2MvQTV2K2hq MUQvdnVtLzhLT2ZQL0l4MzQvNEhRQnMvYnJNZjh2TVgvZlZJYjZ6L0FPZm1ML3Zxc3IvaFJFMy9B RU1sOS8zM1FmZ1lSMThTMzMvZmRBR3I5dnMvK2ZtTC92cWsrM1daNlhNWC9mVlpSK0J5ai9tWjc4 ZjhETmNUOFFQaDdxUGd6VFk5UmcxdTR1b0dmYTI1eUNLQVBTL3Q5bi96OHgvOTlVbjIrejZmYVkv KytxNUR3MzhINzNWTkRzOVJ2dkVGM0ExMUVzeXh4c2VGUFN0ai9oU0NkdkVtb2Y4QWZkQUd2OXVz L3dEbjVqLzc2cHYyK3ovNStZdisrNnlmK0ZJRC9vWXRRUDhBd0ttLzhLUXlmK1JoMUQvdnFnRFkr MzJmL1B6Ri93QjkwbjI2ei81K1kvOEF2dXN2L2hSbzcrSkx6L3Zxai9oUnNmOEEwTXQ2UCtCVUFh bjIrei81K1l2Kys2YWIrei81K1kvKytxemYrRkhRai9tWnI3L3Zxai9oU0ZzT3ZpYSsvd0MrcUFO TDdmWi84L01YL2ZWSWI2elAvTDFGL3dCOVZuSDRJV24vQUVNOS93RDk5VndYeEM4Q1gzZ21HM3Vv TlludTdhWnRtU3hCVTBBZW0vYnJQL242aS83NnBQdDFuL3o4eGY4QWZRckEwbjRKM0Z6cHR0Y1gv aUM2aWxtaVdRcEdlQnVHYXZmOEtOaTdlSXI4L3dEQXFBTkg3ZFovOC9NWC9mVko5dnMvK2ZtTC92 b1ZubjRHcC8wTUYvOEFuVGYrRkdvV3dOZnZ2em9BMHZ0OW4vejh4ZjhBZlZIMjZ6LzUrWXYrKzZ6 L0FQaFJLRHI0anUvKytxWC9BSVVWRDM4U1hnLzRGUUJmKzMyZi9QekYvd0I5Q2tOL1ovOEFQekYv MzJLcGY4S0x0LzhBb1pMMy92cWsvd0NGRzJvLzVtVzkvT2dDOTl2cy93RG41aS83NkZIMit6LzUr WXYrK3hWRS9BNno3ZUpiMzg2ODg4ZStCci93WmVXYVJhcExkUTNaMm8rNGdocUFQVWZ0OW4vejh4 Zjk5aWo3ZlovOC9NWC9BSDJLeUxQNEdTRzNqTjc0aHVrbUtnc3FIZ0hGV0Q4Q29PM2lHOVA0MEFY L0FMZFovd0RQekYvMzBLRGYyUS81ZW9mKytoV2Yvd0FLS2lIL0FESDc3ODZRZkFxTm13TmV2ZnhO QUdrTCt6LzUrb3YrK2hSOXVzLytmbUwvQUw2RlVQOEFoUTBmL1F3M1EralVmOEtIaC82R0s4Lzc2 b0F2L2JiUC9uNGkvd0MraFI5dXMvOEFuNWkvNzdGVVArRkUyM2Z4SGVmblIvd291MC82R085L09n Qy85dXMvK2ZxTC92c1V2MjZ6L3dDZnFML3ZzVm5OOERMTUQ1ZkV0NkQ5YTg1OFkrQ05SOExlSkxI U285U2t1RXZpcXd5YmlPU1FPZnpvQTlYKzNXZi9BRDlSZjk5aWwrMjJmL1B6Ri8zMEt5SVBnU0Fn RjE0aXUxbC9pVlR3RFV2L0FBb20zN2VJYjAvalFCcGZiYlQvQUorWXYrK3hTZmJyUC9uNmkvNzdG WnArQk1JLzVqOTcrZElQZ1RFeHdOZXZQcVRRQnFmYmJQOEE1K1l2Kyt4Uy9iYlQvbjVpL3dDK2hX WVBnTEgvQU5ERGRmZzFPSHdHaEgvTXczZjUwQWFQMnkwLzUrWXYrK3hTL2JiUE9mdE1YL2ZZck1Q d0l0dS9pTzgvT2ovaFJObjM4U1h2NTBBYW4yMnovd0NmcUwvdnNVdjIyMC81K1l2Kyt4V1Ezd0tz OGZMNGx2QTN2WG5PdStCOVUwWHh6WitHMDFGNWZ0Ykw1VW9ZaklQdFFCNjc5dHRQK2ZtTC92c1V2 MjIwL3dDZm1ML3ZzVml4ZkFoQXVKL0VkM3ZIREFldFNmOEFDaUxmdDRodlQrTkFHdDl0dE1mOGZN WC9BSDJLUHQxcC93QS9VUDhBMzJLeHo4Q1lSL3pIcjM4NkYrQThUbmpYcndmVTBBYkl2YlAvQUor WXYrK3hTL2JMVC9uNWkvNzdGWTQrQWNZLzVtRzYvd0MrcWQvd29XRWRmRVYzL3dCOVVBYS8yeTAv NStZdisreFI5dHRQK2ZtTC92c1ZqLzhBQ2g3WWRmRWQ1K2RML3dBS0lzeC96TWQ3K2RBR3Y5c3RQ K2ZtTC92c1U3N1phWS80K1l2Kyt4V0kvd0FDYlRIeStKYjBIM3JnWnZEK28rRmZHMDJnM042Sm8y ajh4SlNpdmxlY1lEWndhQVBkOVBuZ2EwM0xOR1J1Nmh4NkN1QitJenBKWTNCUjFZQlVCS25QYzFp UVdraURMWE80ZW4yZU1ELzBHcW12WFUzOWxTVzdPREZ3Y0JGWCtRRlZGYW9SeExWR1JVeDZWR3dy b1pKSFRHcHg2VkNXcVdBeVNxN0NwMi9Hb3l1ZTFadERSQ0JWNkQvVjFYQ0gwcTJpN1U2VTRxdzNz WElzQk9LZXhxQ054dHFUZHgxclc1TmhqMUMzMHFZMHdqTkpnUTlCVEdxVnhnVkM1eFVnUnNhZ2Vw anp6VVRDczJORUpwOFlPNGZXbDI1TlNLaDNEaWtrTXVSY1NDcm1hb0lkckFtckt2bnZXOFJORWpW WGs2MUtXelViVU1SQTFOcVZoVVRWREFZMVJQVG1OUnRVTXBFYlUwVTgwQktrWkpBT3RYclU0Qit0 VW9sSzVxMUM0VU1LMGpvSmx3bmlvWktBL3JUV09lbFhjVmlGaFVSelU1eFViampOUUJIVENhZmlv bU5ReGpXcHRLYVNrQVZJblNvOFZLcTRYbWhBWHJjNFFWTHg2MVVqa0FYR2FtRW1LMlRGWXovTmFq ekg5YVozb3JHNVJJSldvM0VuclRWRlBBNXAzRTBTQWMrbFNiRmFvaFVpbXFFT0VDK2xQK3pyMkZP U3AxcTBnS2h0MUZSN2RwcSt5NXFsS01TR2xKV0FqZVhIQzB6em05YWlZODBnck81Uk9KbjlhZDVy NTYxQ3RTS0thWWg2OWFtVHBVUUZQUW1xUWlRUkxUeENtT1JTS2MxTWdxa2hFZjJkY2RLamVIYjh3 NkNyb0hGUnlnaU5xcXdGU21QY05UdTM0VlVacXpic1VUZWUxT1daODlhckwxcVZhbTRFdm1PZXBx Uk9sUnFLa1dxUWlWQUN2UE5POGxEVEZOU3FlMVhZQkJBbnBUdklYRlNvS2VSeFZjb215bTBRWGtV MHRzR2FzeWpDZEtvM0JBVWZXcGVnQTF3dzcwZ3VHcXNUazhVNWF6dU10Q1o2ZHVadTlSS0ttVVZh RVBYdFVteFdxTVZJdFVnRkVLZWxPOGxmU25MVWdGVWtCQVlSanBUN0liYiszSC9UVmY1aXBjVWx1 TWFqYmY4QVhSZi9BRUtrMW9DUGV0Qy80OElmOTBmeXJLOGRmOGVWbi8xMGIrVmF1aGY4ZUVQKzZQ NVZsZU92K1BLei93Q3VyZnlybUtMbndRVURRZkVMZHpxcmYrZ2l2VE1WNXI4RVArUmU4UWY5aFp2 L0FFRmE5SlpsampaM09GVUZtUG9LUXhXWlVSbmRncXFNc1NlQUtnc2RTc05UamFUVDd5M3VrUTdX YUdRT0ZQb2NWd0ZwOFhQRDJxMnQzYVhpemFmSzBja2FtUWIwYklJSHpEcCtJcm1QaGw0eTBMd2o0 WHZsMU9lVDdUTGRia2dpVGM3S0VBejZEOFRRQjdqVGhYUGVEL0ZkdDR3MG1TL3RvWklCSE0wVFJ5 RUVqR0NEeDZnMTBJb0FhdnlQZy9kUDg2ZThXYWE2NzFJcVNHVGZGejFYZzBBVXBJOFZtYXV1Tkd2 dit1RFZ2U3hnaXNiVzAyNkpmZjhBWEJxQU9JK0J3eDRJdnlPK3FTLytnclhwQXJ6ZjRILzhpUmZm OWhPWCtTMTZPOGlSUnRMSzRTTkFXZHljQUFkVG1nRE04UmVJYkR3dnBMNmpxTHNJZ3dSVWpHWGRq MlVWbCtGdmlEcFBpM1VKYkt3aHU0NVk0dk5Zem9vR01nZGlmV3VRdEVmNG5lTHA5Vm5SditFYjBu Y3R2R3c0bWt4bkordlUrMkJXSjhFaC93QVZmZm4vQUtjMi93RFExb0E5M0ZMU0Nsb0FJenRmWWZ1 dDBwN3hWRzY3bFByMnFhS1VQR0NldlEvV2dDakpIaXNQeFN1UEN1cDUvd0NlQnJxSll3UmtWenZp MWR2aFRVai9BTk1UUUJ6UHdUR1BoWlpZNzNVLy9vVmR6ZFhNZGxaVDNVeFBsUXh0SStPdUZHVC9B Q3JoZmduL0FNa3RzdjhBcjVuL0FQUXEydmlKZWZZZkFHc1Nic004UGxMOVdJWCt0QUhQRDQxK0c4 RC9BRVRVUi93QlAvaXEzL0N2eEEwbnhkZnpXZW53M1NTd3hlYXhtUlFOdVFPeFByWGwzZ2Z4WjRS OFArSC9BTE5yR21tOHZKSjJkbSt6SklGWGdLTXNmYXZXL0NtcGVHTlp0M3ZmRDBWdEd5L0pLSTRC Rkl2c3cveUtBT2pGTDJwb3BhQUhRdGh2TFBROUtmSkhrWnFGaGtjZFIwcWRKZzZLZldnQ25KSGl1 VStJSy84QUZCNnIvd0Jjai9JMTIwa1lLNUZjZDhSbDIrQTlVLzY1SCtSb0FyL0NrWStGdWhZLzU1 dWYvSHpYV1N6Ulc4THpUeUxGRkdwWjNjNENqMUpya3ZoVno4THRELzY1di82R2E1djQyNnZOYjZW WWFWRTVWYmxtbGxBL2lWY1lINW45S0FOZTcrTVBoVzF1V2hqYTh1RlU0OHlLSDVUOU1rVjFIaDN4 UnBQaW0xZTQwcWRwVmpJV1JIUXF5RTlNaXVBMGpVdmgzNFIwbTMwNjgrejNkODBTdGRTQzI4ODd5 TWtGc1lHT21CNlYzZmhVZUhXMHQ1dkRJdHhaelNsM0VHUjgvZkk2ajZVQWJvcGNaRkpTaWdCMERj K1czWHRVa2tXYXJ1Q0J1SFVjMVlFd1lLZjcxQUZTU0xGY0o4V1Yvd0NMYzZqWG8waUJoWG4zeGZY YjhPZFFIdFFCcStBaGo0ZCtIUU9QOUJTdWhybnZBWC9KUFBEMy9YakhYUS9YaWdEbjlmOEFHbWor R2RTc3JIVTVKRWU2VXNySW00SU00RzdIUEo5UFN1aUJCd2E4UjAxZitFKytNa2w0UnYwK3hmZU05 UExqNFFmOENibXZidTlBRGhTNHlNVWdwUlFCSkErZjNiZFJUM2l5S3JObFNIWHF0V0JNdVIvZEl5 S0FLa2tlSzgwK055NCtIejUvNTdyL0FERmVyT2dZWkZlV2ZITWJmQUxEL3Bxdjh4UUIyV2hyand6 bzRIYXhoLzhBUVJXa2kxUjhQcnU4TTZQL0FOZVVYL29JcllqaTlxQUlkbUJVYmNWYXVNUlIrNTZW Uzk2QUEwdzA0bW1tZ0JqVm55NnZwa0YxOWxtMUcxanVNaGZLYVpRMlQwR0swRFhuR3QvRGk4MVR4 bzJ1cHFGdkhFWjQ1ZktLRXRoZHZHZitBMEFlZ212TnZqY29QaEd5L3dDdm9WNlUzTEU0cnpYNDIv OEFJbzJYL1gwS0FQVkVURnZiRHQ1RWYvb0lxVlZwWWt6YjIzL1hHUDhBOUJGV1k0czBBUWJEaW1k S3NYR0kweDNOVmFBQTAwMHBOTU5BRFRXZTJyNll0MzlrT29Xb3VkMnp5VE11L2Q2WTY1clFOZWNU L0RpOGw4Zkh4Ri9hRnVJZnRpM1BsYkR1d08yYUFQUVRYbC94bVVFK0dzLzgvd0F2OHpYcUpyeS80 eTlmRFgvWDhuODZBUFhiZ2Y2UWV2YitWQ3JVMHlablArZTFQaml6UUJBVklwQndLbW5Hd0JlNXFJ ZEtBRU5SbW5tbUdnQmhxb2I2eisxRzBGM0I5cC81NCtZdS93QmZ1OWFudUo0YlMza3VMaVFSd3hL WGR6MFZSeVRYa253OWhsOFIvRURWZkZEeGxZRUw3Q1IvRTNDajhGRkFIck5lWGZFNUFmSFhnM1Av QUQ5S1AvSGhYcUpyekg0bS93REkrZURQK3ZwUC9RaFFCNjFPUDlLay93QjQwS3RTekptNWsvM3Fr U0xpZ0NBcWNVcWpBNHFTWWJTRnBsQUNHbUduR21ubnBRQlV1YjZ6dEdSYm02Z2daL3VpU1JWM2ZU TlIzTjlaMmJJbDFkd1FNLzNSSklxbHZwbXZLUEV6RHh2OFdyRFM3VDk3YldCQ3lPT1I4cmJwRCtl Rit0SjRoY2VOL2k1WldGb2ZNdExBaFpIWGtZVnR6bjgvbG9BOWNJcnpEeGdvUHh3OEgrN0N2VVc1 SnJ6RHhmOEE4bHg4SGY3MzlLQVBWbkg3NS84QWVOT1ZhZXlmdm4vM3FtU0tnQ3VRYWxSZG9va0dI QzBvb0FRMHcwNDB3MEFNUDQxR2FrTk1Jb0FqSXJ4bjRrS0I4VnJNK3RpZjVtdmFNVjR6OFNmK1Ny V1gvWGszOWFBSzhmOEFxeFdGNGtPM1RwaVA3djhBV3QyTWZ1eFdCNG4vQU9RWFAvdS8xcWhIRGZh R3FSWmlldFVpZWFWVyticlYzRVg4YmppbnJBbzdVMkxxS3RiUldpUWlFd0tLYjVLWTZWWUlxTmpW V0FoS0tPZ3ByZGFjMmFaVVBjQ05tS3R4VERNL3JVakNvWEZTMk1ET3c3MGduWW5xYWhjMHdIRlRj WmVXVHpPRFRnaGVxMXVjdlYrQWNkS3VPb2hCYnJTR0JmU3JPS1kxWFlSWE1LRHRTRlZVY0Nuc2Fq SnFHQkczVDFxUGV5OFpxUTFHdzlLbTR4RE00NzAzejI5YVkvV29tcUxqTEt6bjFxVE80VlNVNEZX NHo4b3Frd3NTcERrNWFuL1oxeFU2TDhvTk9JNHE3Q0toZ1NtK1VxMU85UU1hVFFEWDZWQytkd3hV aE5OSTZWSUlZWldIZWtNemV0RENvalV0bEQvT2JOU0pMdStVMVgrbE9qKytNMGt3SjZla0E2OXFh Qjh3cTZGRmFKRWxmeUZwclFyNlZiWVlGUU4xTk93RVBsZ2MweHV0UFkwdzFOaGtaNE9SU0dSdldu R282a1lsSjNwYUtrQjYwOFV4YWtGVWhNVVU5YVlLZXRVSW5pcXl1S3JSVllXclFoNSs2YW9TL2Zh cjUrNmFvUzhPMUU5aG9wTjk0MGxLMzNqU1ZnOXhqMHFaYWhTcGxxa0EvRktNMERGS0twQ0pFNjFa VG1xeTFZanEwSW5BcU9mL0FGYmZTcEZxT2Y4QTFiL1NyNkFVYXBOMXE4ZTlVVzZtc0pGSUZxZEtn WHRVNlVrQk1vcDQ2MHhhZjNxMEljT3RTSlVRNjFLbFdJc0owcVFWR25TcEJWb1RJNS91R3M2NFhL aXRHZjdsWjF4d29xSmpLblExSW5KcVB2eFVpRG1zVU1zcFVvRlJKVW9yVkNIRHJUbHBvcHd6bXFB bVNwVnFKT2xTcjFxMERIOXFaYjg2amIvOWRGLzlDcDFOdHVOUnQvOEFycXY4NlV0aExjOTYwTC9q d2gvM0IvS3NyeDEveDVXZi9YVnY1VnE2RnpZUS93QzRLeXZIWC9IalovOEFYVnYvQUVHdVlzdmZC RC9rWHZFSC9ZV2Ivd0JCV3ZTNjgwK0NIL0l2ZUlQK3dzMy9BS0N0ZWwxSXp5YjR0M21qbG9kRXM5 S3RyblhycGwvZUpFUE1pQlBISTZzMzh2d3JtYlBSb2ZoNTR4czR2RlZoYlh0aGRSS2ZPWk55eE4z SXoxMm5nKzNOZTVUYVBwdHhxbHZxYzFsQzk5YjVFVTVYNWx6UzZubzJuYXlzQzZsWnhYS3dTK2JH SkJrSzMrZTFBRnUyanQ0NEVGcWtTUWxRVUVTZ0xqdGpGU2ltcUFCZ0FBRGpqcFMwQU83MUZuWk1S L2VINmlwYWhuK1VLLzhBZFlVQVN3VENRWXpXZjRoWEdoWDMvWEkwUlMrVmVPaFA4VkhpRTU4UFhw SC9BRHlOQUhBZkE3L2tTci8vQUxDY3Y4bHJTK0tzZXNYUGhSTFBScmU0bmE0bkNUcmJvV2J5OEU5 dTJjVm1mQTcvQUpFeS93RCt3bEovSVY2VU9LQVBHdEk4UytNOUIwS0hTclB3VXlXMFVaWEpnbHl4 UDNtUHVldGNuOFBkWTFYUmZFTWsya2FiOXZsbFR5cFUyczNsb1hYTGZMNlY5Sk9OOGJwMDNLVnpY RytEdmgzYStEdFZudjdmVWJpNWVXRXhGSkkxVUQ1Z2M4ZlNnRHRqd2NVdE1HS2RRQTZvU2RqT283 amNLbDcxRk44ckkzdmcvalFCSmJ6aVJjZDZ4ZkdZeDRUMUgvcmthc1dzdmwzVHhrOURWZnhvYytF Yi93RDY1bWdEay9nbC93QWt1cy8rdm1iL0FOQ3JyOWR1OUlzdEprazExb0ZzR0tvd25YY3BKUEhG Y2Y4QUJML2tsOXAvMTh6ZitoVjFuaUh3M3B2aWpUaFphbkV6UnEyOUhSdHJJM3FEUUF6K3ovQzM5 aEZUYmFXTks4djVpRlRadC8zcThpK0VSWlBpTGNwWWx6WkdDYmRudkdHK1FuOUs2Qi9nZlptVENh N2RMQm5PeG9WSi9uaXU3OEwrRWRLOEpXYndhZEc3U1NZODJlVTVlVEhyN2UxQUhRS3U1Z09tYW8z TTl3bHUxM0dFOGtLV1VIK0lDcnFuYWMxaVgybFhNNU1jTnlVZ2JQeStnUFhGQUdsWjNhM2NLeXFN QmhuSHBVcmtvcmowK1lmMXFLeXRFczdkSVUrNm94VXNvK1pQUS9MK2RBRXR0UDVxVnkveE1HUEFX cC85Y3ovSTFwMkV4V1prSjZHc3Y0bUVId0ZxUC9YSnYvUVRRQlMrRlA4QXlTL1JQOXgvL1F6WElm SEt6bDNhUGZLcE1ZRWtKUG8zREQrdjVWMTN3by81SmZvdis0Ly9BS0dhNkxXdEZzZkVHbFM2YnFN WG1XOG5vY0ZUMlpUMk5DQTVqUi9DSGcrNzhDd1NKWVd6MjB0cjVqM2JjeUJ0dkxiK29JT2Z5cmkv Z2ZMT3ZpRFZZSTJaclEyd1p2VGNHd3ArdU0xcFA4R0xwUTl0YmVKNWtzSGJKaGFNOC9WUTIwMTNu aFB3bHAzaERUbXRiSGZKSklRMDA4bjNwRDIrZzlxQU9ncHdwdEFvQWRWZDI4dU54L2NPNzhLbjdW RE11V3gvZVVyUUJOYXppV01jNXJpUGpKZ2ZEdSsrbGREcDA1V1FvVFhPL0dJNStIbDcvdW1nRFM4 QW5Qdzc4UDhBL1hrbFFmRVBYZjdBOEdYazZQdHVKeDluaHgxM053VCtBelUzZ0RuNGQ2Qi8xNXBY bmZ4UHVKL0V2anJTL0Mxb1cyeGxRM3B2ZnEzNEwvV2dEcFBnNW9YOW0rRlgxS1ZNVGFnKzVTZXZs cnd2NW5KcjBXb0xTMWhzYk9HMHQxMnd3SXNhQWRsQXdLbW9BZFNpbTBvb0FVMVdtWXBDZittYmZv YXNWWHVWTEIxSDhTRWZqUUJZdGJnU29PYzE1dDhkL3dEa1JELzEwWC8wSmE3TFRiakQ3YzF4WHgx T2ZBeC8zMS85Q1dnRHZQREEzZUZ0SC82ODR2OEEwRVZ2UngxaCtGQm53cm8vL1huRi93Q2dpdWhV YlZ6UUJsWDc3cDluWmFyVWp2dmxaczlTYVNnQU5OTkJwcE5BQWZyWEY2cDhSYkRTL0V4MEtTd3Vu bkVxUmVZckx0eTJNZS9ldXpOYy9lK0ROQnY5WE9xM05rWHZTNnY1bm1zUG1YR09NNDdVQWJwR0Rq TmVhL0czL2tVckwvcjZGZWtubXZOdmpiL3lLVmwvMTlDZ0QyRzFUTnJiZjljVS93RFFSVjJOT0ty MlF6WjIzL1hKUC9RUlZ3L0loUG9LQU1tN2ZmY0VEb3ZGUlUzZHVZdDY4MGhOQUNrMHcwcHBwb0FR MXhrdnhGc0kvRm4vQUFqeHNibzNIMmtXL203bDJidlgxeFhaR3ZMVjBGOVgrTU10N0ZZU1d0bFlz czBzcm95K2RJT2pEUFhMZW5aYUFQVHpYbC94bEh6K0d2OEFyK1QvQU5DTmVubXZNUGpIL3JQRFAv WDhuOHpRQjdVeVpsL0tyQ0pnVTBMOC93Q1ZTT1JIQ3plZ29BeTUyM3p0am9PS1lUVEZPUm4xcFNh QUNtbWxOTU5BRkRXdEp0ZGQwbWZUYnpmNUV3dzNsdHRJN2o5YVpvdWpXZmgvU1lkT3NJOWtNWTZu cTdkMmIxTmFKcGhvQWFhOHgrSm4vSSsrRFA4QXI3VC9BTkNGZW5Hdk1maVgvd0FqNzRNLzYray85 Q0ZBSHM3Sm1kejcxT2tlQlNiZjNyZlduek41VnU3ZWdvQXpYYmZNN2RzNEZKbW1Kd0tjVDZVQUlU VWJxR1ZsUFJoanJUalRTYUFPZThQK0RkSThNQzgrd1J5RnJvbmU4cjdtQy8zQWZTanc1NFMwcnd0 OXBPblJ2dnVIM1BKSzI1Z3ZaYytncmZOTk5BRFRYbC9pNy9rdVhnLy9BSHY2VjZnVFhsL2kzL2t1 WGcvL0FIdjZVQWV5Qk15SDYxWlZNTDBwcXI4NSt0T3VUNWRzNTlzVUFVTjI1MmYxTkdhYW93dUtE UUFHa05INDAwK3hvQVEwdzA0MDAwQU43MTR4OFN2K1NyV1AvWGszOWE5bnJ4bjRsZjhBSlZyTC9y eWIrWm9BcnA5d1ZnZUovd0RrRnovN3Y5YTMwLzFZckE4VGY4Z3VmL2QvclZDUFBHTkVZeTlJMUxG OThVeEkwNHNibEZYQjBxbEg5NFZjWGdWMFIyRUkxUXRVelZBL2VoZ1JOVGFjYWJVZ05QU29aS21h b1g2VkRHVm5xTW1wSHFNK3RaalJZdGg4K2ZhdEczTloxdDk3OEswYmV0S1ltV1NPS2hlcGowcUo2 MVlpdTlSR3BYcUlpczJBMm1OVW5hbzJxV01pZW9HNjFNOVF0MXJOalFnL3BWeUlmSXRVeFZ5TDdv cHhCbWxIOTJocUl5QW96UTFkQzJKSUhxdTJhc1BVRFZER1JtazdVVUhwVU1FUnRVTGRjVk0xUXQx cUdNU25SL2ZGTnAwZjN4U1F5eC9FSzBFd1JXZi9BQkNyNmNMaXRvRWlOakZWbi9HckxkS3J2VFlF TFV6dFQycGxaakVQU296MXFROU1WR2V0SUJ0RlNlU2M4VW9nYWxZWXhhZU90S0lHSFNrMkZUelRW MElrSDBwNmltQTRweGxVR21JblRpcHhWSVhBRk8rMVZha0ZpMld3YXB5OHVhUnJqUFRyU1ozVW03 Z1ZXSHpHa3djMWFhSGNPT0RTZlp5VFVXR1FyeFVxbW5mWm1vOGhoUlpqRlhtcEZIRlJJQ0tsUTdR YW9rbFFWTXRWUmNLS1VYUzFTWUYwSEFxT1ZzeG5tb1B0UXFOcGl6WUhTcTV0QkM5dndxbXk1SnE0 T2xJMEdlbFp0WEdWRkdLa1hpcGZzcHpUaGJOUzVXTzQwSG1wRjVwdmtzdE9VWXFrSWtVVktvNXFK V1ZWNW9Gd29OV21JdEx4VW1jQ3FmMmxjOURTL2FRUlZjd0UwclpURlVweGxCVC9BRFN4SXAyemYx cVhxTXp5dUQwcDZkZWxXamIwbjJWdTFaOGdERk5TcWVhUHM3Q2xNVEpnMWFRaDRxUlJVWTRwL21x dldxQW1XbmcxVyswclMvYVZxazBCWnoxcExiL2tJMi8vQUYxWCtZcXVad1J4VXRpZDEvYm4vcHF2 OHhTYkE5KzBML2tIdy83Z3JKOGRmOGVObVA4QXBxMzhxMXRDNHNJdWY0QldUNDYvNDhiUC9ycTMv b05jeFJmK0NIL0l2ZUlQK3dzMy9vSzE2VlhtbndRLzVGN3hCLzJGbS84QVFSWHBWSVk2bEhKeG1t MWkrTU5aR2dlRTlSMUFOaVJJaXNYL0FGMGI1Vi9VMEFjTHF2eHBTdzFhN3RMZlJ4Y3d3U3RHczMy amJ2Mm5HY2JhOU4wdlVJZFYwcTAxQzNPWXJtSlpWOXNqcFh6eG92aEJ0UytIZXQ2NlVMVDI4aStR ZTVWZVpQMFlmOTgxNlA4QUJmV3Z0dmhpZlM1SHpKWVMvS0NmK1diY2o4anVvQTlMelRKaHVpWWUx TG1odnVtZ0RJbmJiZm8vOTVBYW4xdzU4T1huL1hJMVd2Qmg3WnZxdjYxUHJQOEF5TE4zL3dCY3FB T0QrQjMvQUNKbW9mOEFZU2sva0s5THJ6UDRILzhBSW02aC93QmhLVCtRcjBzVUFPckU4VStLOU44 SmFhTHUvWjNlUTdZWUkvdnlOL1FEMXJhcnhUNDQyOXlOWjB1NVlNYlZyZG8xUFlPR3l3L0lpZ0My ZmpQckVtWjdmdzBodGY3NWVSdi9BQjRERmRaNE4rSnVtK0xMc2FlOXRKWjZnd0xMR1R2UjhkY04v aUtuOExlUC9ER3FhZmEya0YxRFl6TEdxZlpKL3dCM2pBeGhmNFNLMjdUdzdvOWxyRTJzV2RqRERl VHg3SGtqR0FSMTZkT2ZYdmlnRFdGUjNITUxVL05OZmxEOUtBTWVadG1wNTdNQTFOOFh0bndmZmY4 QVhPaTlHTG0zYjFYSDVHbStMUDhBa1RiMy9yblFCeS93Uy81SmhhLzlmTTMvQUtGWG9RcnozNEpm OGt4dGYrdm1iLzBLdlFxQUZKMnF4OUJtdklHK09FcXV5LzJBaHdTUCtQay8vRTE2Ni84QXEzLzNU L0t2QVBoS2lOOFJGRG9yRHlKK0NNaWdEcUxYNDVRR1lMZWFISWlIcVlad3hINEVDdlJ0QjhSYVg0 bHNQdG1sWElsUUhEb1J0ZU0rakwycGRXOE82UHJsbTlyZjZmYnlJd3h1Q0JYWDNWdW9OZUdlSDU3 bndCOFR6WU5NelFDNUZyUDZTUnNmbFlqMTVCcDZBZlJBcU9maUluMDVwL1EweVhtTmg3VWdNaGo1 V3F1QndDMmFvZkVnNThBNmgvMXliLzBFMWR1dU5SaWIrOGkxUStJMy9KUDcvd0Q2NU4vNkNhQUt2 d24vQU9TWDZML3VQLzZHYTdJVnh2d24vd0NTWDZOL3VQOEEraG11eHpRQTZ1QThhZkV0L0NPdWpU UnBhM1FNQ3krWVp0blhQR01lMWQ5WGdueGxIL0ZjcC8xNXhmemFnRGQvNFhrNDYrSHdQKzNuL3dD eHJ0ZkFuamIvQUlUUzN2WmZzSDJUN0s2cmdTNzkyNEUrZzlLMjdWdE5ObkJrMlgrcVgrNTZDcmNJ dHdwYTJXRUE5VEVCajlLQUo4MUZNY0tHOUNEVDgxSFB6RTMwb0F4a1BsYXBLblREVmgvRjQ1K0hk NS91R3R5NStYVnMvd0I0S2YwckIrTG4vSk9yei9jTkFHcjhQLzhBa25lZ2Y5ZVNWdXZaMnN0MUZk U1cwVDNFT2ZMbFpCdlRQQndhd3ZoLy93QWs3MEQvQUs4a3JvNkFIVngzaTc0ajZSNFVtTm50ZTkx REdUYnhOZ0ovdk4yK2xiM2lIVlA3RThPMytwZ1phM2daMUI2YnY0ZjF4WGlYdzA4TngrTHZFdDNl NnZtNXQ3Zjk5TXJuL1hTT2VBM3R3VCtBb0EyVitPTjhKZHo2RmJHSFBhZGdmenhpdlFmQ1hqelNQ RnlGTFV2YjNxRGM5ckxqZGoxVS93QVFyZS9zeXdlMU5xYkMxYTN4anl2SlhaajZZckMwUHdEb25o N1dyblZiRzNZVFMvNnRXNVdCZjRnbjEvOEFyVUFkUFVjdkRJZjlvVTdOUnovNmxqK05BR0hBZkt2 M1RQUnlLNUw0NEhQZ1QvZ2Evd0RvUzExdHdObXN5WS9pT2E1SDQzZjhpSC93TmY4QTBKYUFQUlBD WC9JcWFSLzE1eGYrZ2l0eTRmeTdTUnZSVFdKNFMvNUZUU1Ardk9ML0FOQkZhdW90dHNXSHJnVUFZ dzRwUnlhWURTcjk0ZldnRGc5SStKUDlyZUxWMEwreS9Lek5KRjUzbmJ2dTU1eGoycnVxOEM4TTNW dFkvRkVYTjNNa0VDWGMrNlNSdG9IMzY5a1BpM3c0UCtZNVlmOEFmOWFBT2I4US9FZDlDOFVOb3k2 WWt3Vm94NXBtMi9leDJ4NzEzWjRPSzhEOGEzdHRxSHhGYTVzNTQ1NFdrZzJ5UnRrSDd1YTk3Yjd4 b0FTdk4vamIvd0FpbFpmOWZRL25YbzllY2ZHei9rVXJML3I2SDg2QVBhTEVmNkhiZjljay93RFFS VXQ0Mnl6a1B0aW83SC9qeXQvK3VTZitnaW02bTJMUUFkMkZBR1VPS0NhYURRVFFBcE5jZDQzOGNI d2ZMWm9MQVhYMmhXYkpsMmJkdVBZK3RkZm12SWZqVnpkYVAvMXpsL210Q0E5UDBiVVA3VzBXeTFF eCtWOXBoV1habk8zUGJOWENlS3hmQi9IZzNSLyt2U1ArVmJHYUFDdk1makgvQUt6d3ovMS9KLzZF YTlOSnJ6TDR4LzZ6d3ovMS9wLzZFYUFQY2xIelV5L2JaWnY3OFZJdjN2d3FycWpZZ1JmVnFBTThV ak5oU2ZRWnBBYWE1L2RzUFkwQWNMNFYrSlAvQUFrL2lIK3l2N0wrei9JN2VaNTI3N3Z0aXQ3eFg0 b3MvQ21rRzh1ZjNrem5iQkFHd1pHL3dIYzE0djhBRDdWTFBSZkYwMm9YMG5sMjhOdk1XUGNuc0I3 bXRHd3ROUStLbmpDVzd1M01PblFZM0tyZjZ1UCtGRi8yamprL1gycGdlaitEZkZlb2VMSTVidDlK U3pzVStWWmpLV01qZHdCZ2NEMXJxVFVOcmEyOWphUld0ckVrTUVLaEVST0FCVXBwQUlhOHgrSmYv SS9lRGY4QXI2VC9BTkNGZW0xNWw4U3YrUjk4R2Y4QVgwbi9BS0VLQVBjUVAzamZXb2RRYkZxUi9l WUNwaC9yRyt0Vk5VYkN4TDc1b0FwZzBacG9QRkptZ0RnZkV2eEwvd0NFZjhVTm9vMHJ6OEdNZWI1 MjM3d0hiSHZYZXR4WGdmeEc1K0tFbis5Yi93QWxyM3BqeWFBQTAwMFpwQ2FBRUpyekh4Yi9BTWx6 OEgvNzM5SzlOcnpMeFoveVhMd2YvdmYwb0E5dVFmTWFoMUU0Z1JmVmhVMGYzalZUVW0vZVJMOVRR QlhIU3M3WGRhdFBEK2pYT3AzcllpaFg3bzZ1MzhLajZtcjRQdlhqK3ZYTTN4TjhjUmFIWXlNTkUw OXQwOHE5R3h3emYreXIrSm9BWnBkLzhUL0Uxb2RVMDY2aWhzNXBHOHRXOHRBQm5vdVZ5UU9tZmFy bjltZkZzLzhBTVR0eC93QnRJLzhBNG10djRnejY5b0doV0UzaGxFaHNiRmdabGpHU3Fyd29JL3Vl dFo4L3hmMDMvaEZoZVF4ZjhUZHZrK3lIN3F0ajd4UDkzOWUxQUZSdEorTEFVazZ2YmdBWi93QmFu L3hOYVh3cjEzVmRkc05UZlZieDdwNFoxVkN3QTJqYWM5QlZ6NGUzSGlPNjhPM0Yzcjc3bG5MUzJ4 Y1lrMmtFbkk3TDZWaC9CZjhBNUJ1c2Y5ZktmK2dtZ0QwNnZHZmlWL3lWYXkvNjhtL3JYc3VhOGEr SlhQeFZzdjhBcnliK3RBRUNmY0ZZSGliL0FKQmsvd0R1L3dCYTMwKzRLd3ZFYTd0UG1YMi9yVklS NTJ5NU5QUlBtSEZXamFudlRsZzJqTmFLQWgwZkRDcklhcXZUbWxXYkhXdEV4RnJ0VVRDby90SXBw dVZORndIRVZHZXRPODFXNEZJZXRJQ0ZqZzFHeHFVb1dOSDJjbW9zTXBzS1lGelYzN0thUVd1RG50 VThvRWR1TVBWNkE0elVQbGhlbEp2MlZTMERjdmJzaW10MHF0OXBHS1EzSys5WHpDc1NNS2liaWcz Q0drOHhXSEZJWXhxalkxSXd5S1o1TE5VV0FnYm1vaUt1ZlpteFRmc3hxWEZqS3dYak5Xb2hoUlNy YjQ2OUtkamJ4UWxZQzJwK1duazhWUldiYWNIcFRqY2dWb3BDc1RPTTFFVnBwdVZJcFBQUTByZ05Z WXBqR3BHSVBUcFVUZ2tqRlQxR1JzYWpibXJIMmRxUHN4SXFiREsxT1Q3NHFYN09SVGhFRlhORmhD L3hDcml2d0twZmpUbG14MXFrN0NMakdvV3FMN1NLUTNBcHVTQ3dyQ296eFR2TlZxWTFTTWF4NU5S azgwOHF6SGlnd3Q2MGdMQ21wa0JOUUwxcWVLclFpVFpVYnhqdlZoUlNTWVZmd05VMEl6V09CbjFx QS9XcHBCOGxRMWl5a0ZLdEozcDYwa01lQlVnNllwcWluVllpVlRVcTgxWFUxTkh4Vm9ST29wU3ZJ eFNwelVvRldrSW96RGI3VldtSkFHS3VYWGJpcU0vUVZuSXBFUmFsV21kL2FucFdZRXFqbXBGR0NL WXRTcUt0Q0ZxWkdOUTk2a1UweEU2bXBRS2dTckNkSzBRQ012dFZhVUFTY1ZkN1ZUbi9BTlorRkRB cHpFaHNkcWl5YzA2NC93QllmcFVRNjFnMlVUTDFxVlJVSzFZVVZTRXh5akZTTDFwcWluRHJWb1JN cHFWZmFxNjFPblNyUUR3T0thVjRPYWtBb2JnVlZoRkYrQWFxTStmclZ1WGxXck9QQnhXRW1VaVVO elVpMUNsV0l4eFFoajFXcmxnTVgxdi9BTmRWL25WZFJWcXgvd0NQKzMvNjZyL01WWko3N29ZLzBD TC9BSEJXVDQ2NXNyUC9BSzZ0L3dDZzFxNkgvd0FnK0gvY0g4cXlmSFgvQUI1V2YvWFZ2L1Fhd0tM L0FNRVArUmU4UWY4QVlXYi9BTkJXdlNxODErQ1AvSXZlSVA4QXNMTi82Q3RlazlxUXhhOGkrTjJz NGowN1JJMzY1dXBnUCsrVS93RFpxOWNGZUV5NmJlK05QaXlaTHF4dVYwNXJuQmFTSmxYeVkrMmZm SDYwQWJQaHI0aitGZEY4STJ1aVRXMSs0V0VwUHRpWERzMmQvd0RGN211VitHV3N4YUw0OWhSWkdG bGVGclhMOGNFL0lUK0lINTE3UWZBdmhVNS80cCt3L3dDL2RlVWZFL3drZEY4UVdsM29OZzhWdE5F R0NXMGJNSTVGUHQwenhRQjd6UWF6ZEIxRnRYMEd5djNSNDVKb1ZaMFliU3JmeERIMXpXaFFCbDNx NWlRLzNaU0tsMWtmOFV6ZC93RFhLaTZYTWIrMG9OUDFzWThOM1kvNlltZ0RnUGdmL3dBaVpxSC9B R0VwUDVDdlNhODIrQi8vQUNKZW9mOEFZVGsva0s5Sm9BV3FtcWFUWWEzWVBZNmpiUjNGdS9KUit4 OVFlb1AwcTNYbW54RzB2eGdkYXROYjBHYVNTQzFUQ1EyMzM0Mi9pSlgrSUgvSW9BcGExOEVyZVRl K2k2bThSN1EzUTNMOU53NS9NVmovQUErOFFhejRaOFpKNFgxUjVHZ2tsTnUwTHR1OG1Uc3luMFA5 YWtqK0xQaTZCUHM4MmpRUGNkTnh0NUZPZmRRYXVlQlBDV3VhdjR1LzRTenhGQzhHMlF6SXNpN1ds a0k0TzNzb29BOWl6U0hwaWlnMEFaRjZQK1BjK2pzS2I0dEgvRkdYdi9YS3JGeXVZMC8yWnFoOFhq L2lqcjcvQUs1VUFjbjhFLzhBa21GcC93QmZNMy9vVmVnMTUvOEFCUDhBNUpmYWY5Zk0zL29WZWdV QUkvOEFxMi8zVFhnWHdrLzVLTXYvQUZ4bnIzMXgrN2IvQUhUWHpWb00vaUR3dnJyYW5ZNlRPOHlp UkFKcldRcmh2cFFCOU1EazE4N2VLWkYxL3dDTGNxV1A3d1NYc1VDRmUrM2FwUDZHdGU4OFovRVB4 QkExamE2Wk5iK1lOckcydEhWaVA5NXVsZE44T1BoeE5vRndOWTFuYjl2Q2tRd0tkd2h6MVluKzkv S2dEMDAvZU5OYjdwRkZCb0F5THRmMzlxM3NSK3RaL3dBUnhqNGYzLzhBMXliL0FOQk5hbHd1NzdP ZlNSaFdiOFNCL3dBVy93QlEvd0N1Ui84QVFUUUJTK0ZIL0pMOUYvM0gvd0RRelhZMXgzd3Avd0NT WDZKL3VQOEEraG11eG9BSzhGK012L0k4Si8xNXgvemF2ZXVLOE4rTDJuWDExNDBTUzJzN2laUHNj WTNSeE13emx1NEZBR2hGOEVHa2hqbEd2QWIxRGY4QUhyNmpQOTZ2UXZCWGhjK0VORE9tdGRpNnpN MHZtQk5uVURqR1Q2VnQyb0lzNE04RVJLUC9BQjBWTm1nQmFaSnlqYzlxV2tiN3BvQXlMdGY5T3Rt OVVGWVB4ZUdQaHplZjdocm83aE16V2grby9XdWYrTUF4OE9iei9kb0EwUGgvL3dBazc4UC9BUFhr bGRIWE8rQVArU2QrSC84QXJ5U3Vpb0E1M3g1YXZlZUJOWmhpQkwvWnl3QTc3U0cvcFhudndPdm9V dTlXc0dZQ1dWSTVrSDk0TGtIL0FOQ0ZleGxReWxXQVpUd1FlaEZlRmVKL0FtdStFZGMvdGZ3NHM4 bG9ybVNKN2NicElNL3dzdmRmMDlhQVBSL0huaFRVL0ZNZGt1bWFtTEUyNWN1U3pqZm5HUHUvU3ZK SVlkVzBENGpXV2ozT3EzRTdRMzBLdVZtZmEyU3A2RStoclpoK0tIamU1UVdzR213eVhKK1hlbG01 ZlAwemlzeFBEL2lXMThiNk5mYTNiVHlYTjNjeFhFajdTNVViOGZNUndPblRzS0FQb1k5VFVjdk1U ZlNuSHFjVWpmY09QU2dER3VsLzRtc1RmM2tXdVA4QWpnTWVBaC92ci82RXRkcmNKbTl0VDZwajlh NDM0NkRIZ1A4QTRHdi9BS0V0QUhmK0V2OEFrVmRJei96NXhmOEFvSXJSMVU0dFVIcTFaM2hQand0 cEgvWGxGLzZDS3U2dVQ1Y1krdEFHV0RTcWZtSDFwZ29CK2NjOTZBUG5uVE5JaDEveC9KcGx4SkpI RlBkVEJuanhrWUxIdjlLOUIvNFU3b3YvQUVFZFEvOEFIUDhBNG11VjhKMk41SDhVVW1lMXVGaSsx VG5lMFRBZnhkNjl0b0ErZXZFR2l3ZUh2R3E2YmJTeVNSUlN3a1BKalBPMDlxK2htKzhhOFM4ZGFm ZXpmRWQ1b2JPNGtpM3dmT2tURWRGNzRyMnRqOHhvQUs4NCtOZi9BQ0tWbC8xOUQrbGVqWnhYblB4 ci93Q1JSc3Yrdm9VQWUwV0ovd0JEdHY4QXJrbi9BS0NLaTFkdjNjUTk4MUpZbi9SYmIvcmluL29J cXZxN2ZORVBZbWdET0JvelNDa3pRQXVhOGorTkgvSDFwSC9YT1grYTE2ZnFtcFcya2FiUHFGNHhX M2hYYzVVWk9NNDRIZXZGZmlQNG5zZkZHbzJLNlY1c3NjRWJMdlpDdTVtSTRBL0NnRDF2d2dUL0FN SWJvLzhBMTZSL3lyWXJPOFAyY21uK0hkTnM1dUpZYlpFY2VoMjgxb1VBTFhtWHhpLzFuaG4vQUsv MC93RFFqWHBsZVovR0w3M2huL3IvQUUvblFCN21uM3FvNnMzTVMvVTFjVC9XZmxXZnFwL2ZvUFJh QUtZTk5rUDd0LzhBZFA4QUtqTk1rUDd0djkwL3lvQSthZEIwRzQ4UytJWTlNdG1WR2tkbVoyNktn KzgxYnRsUGUvRFR4NDhVKzU3Y0haTGpnVFFOMGJIcU92MUJGWGZoZlpYbHY0Njh5YTBuaWo4bWI1 M2laUm42bXUzK0pmaGYrMzlEKzJXc2U2L3NnV1FBY3lSL3hML1VVd096aW1pdUlJNTRIRWtVaWgw ZFR3eW5vYWRtdk52aFhxOStscStoYWpiWE1ZakcrMWtsaVpSdDdwa2o4UitOZWo1cEFCTmVhZkVy L2tmUEJuL1gwbi9vUXIwcXZOUGlUL3lQbmd6L0FLK2svd0RRaFFnUGNWLzFyZldxT3FOKytqSG90 WEZQNzUvcldkcVIvd0JLSHN0QUZmdFJtbTU0cENhQVBCdmlKL3lWQi84QWZ0LzVMWHZUSDVqWGcv eEd0TDV2aUZjM050WjNFb1R5V1ZsaVpnU0ZIcFdrZmlWNDBQOEF6Qkl2L0FPWC9HZ0QyTTBocm4v QnVyNmpyZmg5YjNWYmNXOTBaWFV4ckdVK1VkRGcxdlpvQVd2TS9Gbi9BQ1hMd2QvdmYwcjBxdk5Q Rm4vSmN2QjMrOS9TZ0QyNlA3NSt0VWRRYk4wUFphdVJINTIrdFo5NmMzai9BRUZBRk8rdEV2OEFU N2l6ZVNTTlo0MmpMeG5ETGtZeUs4citIZDIzZzN4VmYrRXRWalNPUzRrRFFYQUdQTVlENVJuMFpl bnZYck9lSzRiNGwrRlgxN1NWMUt3VWpWTEViNHluV1JPcFg2anFLQU5IeHY0eXRmQ1dtY29zOTlj S3l3UU4wUHF6ZjdQODY4Wi80UlBYN2JSby9GUnNvL0pFdm5lVXlad3VjN2luOXpQNmUxZDFaK09m Q2ZpRFJOUC9BT0VyQS90QzBjTVZNVE1HY2Z4Y0RvM0dRYTZGdmlmNFJJS20vY2dqR1BzNzR4K1ZN QzM0VDhYV3ZpM1JaSjQwOG02aFhiY1FBY0tjZFZQOTAxeXZ3WC81Qm1zZjlmS2YrZ21ybW5lTnZB ZWkyVTl0cGtyUVJ6TzBqS3R1L0x0K0g1ZWxVZmd1YzZWcXg2ZjZRbi9vSnBBZW41NXJ4ejRrL3dE SlZiTC9BSzhXL3JYc09hOGUrSklQL0MxYkhIL1BpZjVtbWdLNmZjRll1dmY4ZWN2MHJhVC9BRlly RjE3L0FJOUpQcFZMY1J5TFZHVHhUMk5STlc3SkdIcFViRDBxWEZNWVZJRmRzMUV4eFV6MVhhczJV dGh5dmlyY1p5bFo0emtWZWdHSThVUllNdXhyOHRQMjhVUmtGUlRqVzZJSWowcU5qVWoxQTFTeGpX T2FpY1ZJVFREVWpJV0hGUk1jQ3AzcUIrS2hqR1pwNk1jMUNUVGs1WWZXcFRBMEVIemdWYUM4MVho T0pCeFYwQVlyZU94SkV3eFVUZEttYW9ITkRBWVd4VVI1cHpHbWRxaGpJMkZSTng2MU93cUZxaGpJ aWFBYUQxcEttNEU4VGJnYXRRS0NEa1pxbkIzclF0T2pmV3RJQ0pBZ3hUV0dLbklxQ1N0R0loWTFF eHlEVDJxSW1zMnhpR295T0trUFNtRVZMR1JHaytwcHpVMnBHRlNxY3JVVlBUcFFnTGNLamFEVTRR RVV5M0EyTDlhbXdlMzg2MlNKS0tWWWpxQkJ6VTZIRlNnTEMwMmI3djRVb05OZDhEODZ0N0NNNS91 bW9hbWY3bFE0ckJsSVR2VWkwekhOUFUwaGt3cDFNRk9xeERoMXFaTzFSTFV5VlNFV0VxVmFoVTFK dXdLMFFpdGRkcW96OXF2WExaQTRxak9PbFpUS0lLZWxNd2MwOVJpb1FFNjFLS2hVMUl0V0pqdTlQ V21WSW9xa0lsU3JDVlhUZzFPdFdnSmUxVXAvOWIrRlc5MktxVGtHVE5EMkFvWEgzengycUVkYW51 Qm1RL1FWRUY1ckZsRWlWWVdvRjROVEthYUVTaW5EclRGTlBBNXF4RDE2MU9uU29WcVpPS3RBU2lo K2xJRFFXNHFoRktUb2F6bSs5V2pMeXIvU3FCV3NKbENwVmxLckwxcWRPS1NBc0xWcXgvNC83ZjhB NjZyL0FERlZGTldySC9qK3QvOEFycXY4eFdnajMzUXNIVDRlZjRCV1Q0Ni80OHJQSC9QVnYvUWF2 YUpGcWNtbm9iS0dLWUtBQ0pIMlZTOFJhYnIyb2lDRzQwMW9nckZrTVJFbTc5YXhMTGZ3UWNIUS9F U1orWmRVSng5VkgrRmVsL2pYaFdrYUg0MThKYWhlM0dpUnlmWnIwcTBzTTBPOE13NXp3ZU9wcmZI aUg0aGdjNlhHZiszZVQvNHFwQTlXcDI3UEZlVC9BUENRL0VML0FLQk1mL2ZpVC9HbC93Q0VpK0lQ L1FKai93REFlVC9HZ0QxYWxWaXZRNHJ5ai9oSXZpRi8wQ1UvOEI1UDhhWC9BSVNQNGcvOUFoUCsv RW4rTkFIcTJjMFY1U1BFbnhBSFhSMS84QjVLZC93azNqL3ZveW4vQUxZU1VBZWxPdTd6UjdxYWJy NTJlSGJ6UEg3azE1cWZFZmowazdOR1VGdXY3aVExUzFtLytJK3Q2YkxZZlkvczhjbzJzMGRvMjdI MUpvQTEvZ2E2djRMMUVBOU5Ua3ovQU44aXZTcThFOEw2QjQvOEZ4elJhYkU3UVhEQjNpa3RpdzNB WXp3YzVycGhybnhHQTUwbU0vOEFidEovalFCNnJRT0s4ci90MzRpLzlBaFAvQWVUL0dsL3QzNGkv d0RRSFgvd0hrL3hvQTlVeWM1b1BOZVYvd0J2ZkVUL0FLQTYvd0RnUEovalMvMi84US8rZ012L0FJ RHlmNDBBZXBVdGVXRHhCOFErK2lnLzl1OG4rTk9IaUw0Z2Q5RUgvZ1BKUUI2TTY3bGNla2ltcW5q TWhQQitvWk9BSWE0SCszdkg1enMwVUFrNUorenlHczd4Qko4U1BFbW1QcDBsazBFRXZEbUswYkpI cGttZ0RvL2drUTN3dnRRRHlMcVlIL3ZxdlFhOEs4TWFKOFEvQnRtOW5ZVzd5V3NqK1o1VWxzV0N0 MEpHRHgwcm9oclB4STc2T3AvN2RwUDhhQVBVNlhjZld2TFA3YStJL3dEMEJsLzhCcFA4YVA3YStJ NC81Z3EvK0E4bitOQUhxbWVLYjFyeTMrMi9pTi8wQlIvNER5ZjQwdjhBYm54RkgvTUVIL2dQSi9q UUI2alJYbC85dmZFUWRkRUgvZ1BKUi93a0h4Q0hYUWgvNER5VUFlaXVtNEw3UzFqZkV4bFR3QnFS Si81WkgrUnJrZjdjK0lKNFRROXZPNy9qM2tySjhUVy94SDhXNmNkTnVMSjRiWi92TEhhc0MzNGsw QWR0OEoyRC9DN1JTcDZMSXAvNzdOZGxYaVBoclMvaVA0UjA4YWJhV3NrdG9ybDBqa3RtYmFUMXdR MWJnMWY0bEFmOGdaZi9BQUdrL3dBYUFQVXFVTmp2WGx2OXMvRW4vb0NqL3dBQnBQOEFHaisyZmlR T3VpRC9BTUJwUDhhQVBVYUs4djhBN2ErSkgvUUVIL2dQSi9qU2YyMzhSdjhBb0JqL0FNQjVQOGFB UFVhUStsZVlmMjc4UlIxMEwveVhrcGY3ZitJUTY2RG4vdDNrb0E5Q1pOelFIKzdJd3JtUGpJd1g0 ZDN1VDFHS3dEcmZ4Q2JhSTlDSXdkMy9BQjd5ZGF4ZkZXbS9FYnhwWnJZWGxsSkRiQnR4amp0bVhj ZmNrMEFlbGZENWcvdzU4UEZUeDlpUVYwZGVMZUg3UDRsK0dOTWoweUMwZWUxaHlJMWx0V0pVRTV3 Q0c2VnJqVi9pWC8wQkYvOEFBYVQvQU9Lb0E5Uzk2QWNWNWQvYkh4Sy82QWcvOEJwUDhhUDdhK0pJ L3dDWUdQOEF3SGsveG9BOVJ6UzV3T00xNWIvYlh4SS82QVgvQUpMU2Y0MG45dWZFY2Y4QU1DLzhs cFA4YUFQVWZ4cEQwcnpEKzN2aUtQOEFtQS8rUzhsSi93QUpEOFErL2g4LytBOGxBSG9oVGRQYW4w M0Q5YTRiNDhNRjhDZ1o1TXFqL3dBZUZVVHJueEVabDh2UUNOdlQvUnBLNS94WG92eEc4Y1J4Mjkv WVN4d1JuY3NjZHNWQlBxU1RRQjdYNFNZUDRWMFpsT1ZObEZ6L0FNQkZXOVlQTVE5alhqZWhTL0Uz dzVwa0duTHBzbHpEYnBzaU1scytWVWRCa0htdENYeEg4UkpTUE44UEZpQmovajNrb0E5QUZHYTg2 L3R6NGdrY2VIVC9BT0E4bEovYlB4RVAvTXVuL3dBQjVLQVBSaXhJeG1tNXJ6disxL2lMamp3NGYv QWVUL0drL3RiNGpmOEFRdW4vQU1CNVA4YUFQUlF4SGVrcnpyKzFmaVAvQU5DNS93Q1M4bitOSDlx ZkVqSC9BQ0xuL2t2Si9qUUI2TC9Pdk4vamRJcWVFN0FFOG01RktkVStKUjZlSGNmOXU4bitOYzE0 bDhNL0VUeGw1S1grbXpMRkJrcEhIYkZGeWUvSjVvQStpdFBiZGFXcEhRd1JrZjhBZklxdnE1L2ZJ UDhBWnJ4N1N0VitLT2pXRU5tK2tTM0t3SUkwZDdaODdRT000UE5XWmZGSHhGbGJNbmhweTNUUDJl U2dEMGZOSGF2TlArRWgrSWg2ZUdXLzhCNUtQN2YrSTNid3kzL2dQSlFCNkZmV05ycWRuSlozc0t6 MjhuRHh0ME5aZW5lRC9EMmszUXViUFNvSTUxNVdRNVlyOU54T0s1RCszZmlRZitaWWIvd0hrby90 djRrbi9tV0cvd0RBZVQvR2dEMHFrcnpYKzIvaVQvMExCLzhBQWVUL0FCb090ZkVydDRZUC9nUEov alFCNlYrTmVZL0dXUlVmdzBDZWw0cmYrUFU1dFkrSmhISGhvai90MmsveHJsZkVmaGI0amVMN2lL ZlVOTHVWK3pqRWFKQnNDKy9KelFCOU14bjk0Y0hzUDVWbjZvZjlMeDZLSzhnc1BFSHhVMCsxamht ME9XNWFOUXZtdGJPQ1FQWEJ4VXIrTFBpTkkyNS9DMGhiMSt6eVVBZW0wWnJ5L3dENFNiNGlucDRX Zi93SGtvLzRTTDRrSHA0WGIvd0hrb0E5UUxFakdlS1puQnJ6RStJZmlWLzBLemYrQThsSDl2OEF4 TC82Rlp2L0FBSGtvQTlPTEU5NlN2TXY3ZStKZi9RcnQvNER5ZjQwZjI3OFRQOEFvVnovQU9BOG4r TkFIcGxlWS9FeVZVOGUrRFF4SEZ5aFAvZmEwamEzOFRpUGw4TWtmOXUwaC9yWEthNzRVK0kzaWZV NHRVdmRNdTFtdDhlVUk0Tmdqd2NqQUpvQStuVVAra1A5YXpkUU9ieC93cnlPMjhUZkZTMWlWWnZE OGt6Z1lNaHRwQVc5emcwcitMdmlLN0ZtOExTRmoxUDJlU2dEMUxQRklUWGx2L0NVL0Vjbmp3cy8v Z1BKU2Y4QUNTL0VvOVBDci84QWdQSlFCNm51SUhXazNuMVA1MTViL3dBSkg4UzhaLzRSWnY4QXdI a28vd0NFaCtKWi93Q1pXYi93R2tvQTlRTFo2NXBLOHcvdC93Q0pmL1FyTi80RHlmNDBuOXYvQUJN LzZGYy8rQThuK05BSHAvNDE1bDR0bFZmamo0UXljYldYUHRtbzIxMzRua2ZMNFpLbjErelNmNDF5 ZXArRlBpUHJHdlI2L2NhZmVMZXdzcGlaSU51emIwd3VhQVBwMkgvV3Y5YXpiczV1NVByL0FFcnlh SHhWOFVyWkI1dmgyU1IvNG4relNEZCtHYUQ0ditJck1UL3dpc21TZVQ5bmtvQTlVcE00cnlyL0FJ U3I0am5wNFdmL0FNQjVLQjRuK0pSLzVsWnYvQWVTZ0R0cGZCWGhpYVY1WDBTekx1eFpqczZrMHov aENQQzQ2YUZaL3dEZkZjWi93a3Z4TFA4QXpLemYrQThsSi93a2Z4TXgvd0Fpc2Y4QXdIa29BN1Qv QUlRbnd3UCtZSFpmOSs2ME5PMGpUdEhqa1RUYktHMVdRN25XSmNiajYxNTUvd0FKRjhUTWY4aXNm L0FkL3dER20vOEFDUS9FMy9vVmovMzRrL3hvQTlTcnh6NGpPRDhXTFJRZVZzRG45YTBHMTc0b0ZU czhOYlQ2L1puUDlhd0kvQ2ZqZlVOZm0xN1Y5SnZacm1SZHFoSXdvVWRNYmM5S0VCYVQvVmlzWFh2 K1BTWDZWMDlyb091eXM2TnBNc1pSdHJlYktxWU9NOTZ6UEZla3RZYVRLMDZ0SE9OdVUzaHhnbjFB cWx1STg3YW96VWpjMHdqaXVoa2pLWTFQcU5qVXNDR1RwVlpxc3VjbXE3Q3MyTVlPdFhvZnVWU0M1 cTdDdTJPaUMxQXZ4ZmRwNXBrYi9LS2VXRmJvbXhFOVFOMHFaK2FpWVZMR1JVaHB4Rk1hcFlFYjFB NHFaalVMVkRHaUUwNkw3dyt0SVJUbzErZGZyVUROQ0wvV0Nydys3VktJNGtGVzkyYTZJN0VpTjBx dTlUdFVEaWhnUU4xcE8xT1lVMm9ZeGpkS2lhcEdxTnVsUXhrSjYwbEszV2tGUU1tZzcxZXRlamZX cU1JNjFldFd3ckQzclNHeExMUnFDVHBVcE9haGV0UkZkdmVvelVyVkdhell4dmFtdFRqN1V4cWta RzFOcFRTVkFCVWlmZHFPcEUrN1RReTliL2RIMXFlb0lHeEdCVXVhMlJKVUJBcDRrQTcxUnlmVTBa UHFhenVPeG9DWVk2MUc4M3B6Vk1FMDRENXFPWUxFaEdhak1aSEZURHJVbzVvc0lwK1dld05LRUlO WDFVSHRUL0xVOXFmSU16d0NPMVNMVnBvUVFhZ1pkckVVY3RnSERqclVnZFIzRlVua3prVXpjYzBy MkN4cGlaUjNwVE1NZGF6QVQ2MDhaOWFybUN4WmVYZVFLalpONCtsSWd4M3FXUGlsdUlyR0k5Y1VD TnM5S3ZnQTlxZXFnOXFmS0Z6UENIUFNucVR1cS81UXh3S2lraVhhV3gwcDJBaEZUREE5cWhxRnBT YVd3RjhPQjNwNGxBNzFsQnlhY0diTkhNRmpUYVVldFFNKzlzMVhHVDNxUktxOXdHdkhrN3FpOG81 NlZkUThZcVFBSHFLWExjQ2dJeU8xUENrSHBXZ0ZCN1V2bDQ3ZDZhZ0lvcWNIbXBsNjRwenhnRE9L aWQ5Z3pUMkFuQlVkNmNKQUQxRlpyU2s5NkE1TkpUR2FvbEdPdE5hVUFWUkRHbmpKeDFwOHdpVmh1 cUJvVDZWWUhGU0E1b3RjWlFXSnZTcEJHUjJxOG9IcFQ5bzlLYWdJb0FNTzFYTlAvd0NQMjMvNjZy L09uR1BJcGJSY2FqYmovcHF2ODZHcklFZlJYZzMvQUpCZjRqK1ZhMnZFalRvY1pINzBkUG9hNURS ZFIxRFQ5UFg3SlptNVZnQ1J4NmY3d3FqNGk4YjZpWW9iZWZTcnF5QWJkdThqZnY0K3RjNVowUWtj Znh0LzMxUytZLzhBZmY4QTc2TmVYZjhBQ3c5Um4xRjdMVGJDNnZKRTY3WWdENzhZNHE5L3drM2kv d0Q2RnU5Lzc1V2tCNkY1ai84QVBSdisralI1ai84QVBSdisralhubi9DVGVMditoY3ZmKytWcFAr RW84Vy85QzdlLzk4clFCNko1ai8zMi93QytxWHpIei9ySC93QytxODVQaW54WVArWmR2UDhBdmxh UStLL0ZZLzVsKzcvNzVXZ0QwZnpKUCtlai93RGZSbzgyVC9ubzMvZlJyemovQUlTM3hWLzBMOTMr UzBmOEpYNHJQL012WG4vZkswQWVqK2JKL3dBOUgvNzZvODJUL25vLy9mUnJ6bi9oS3ZGaC93Q1pl dlArK1ZxQzY4YitJN0tNeVhPaDNjYURxektPUDBvQTlOODJUL25vL3dEMzBhUE5rLzU2UC8zMVhs Tmo4UjlXMU9VeDJHbDNGdzZqSkVhaHNmWGl0TC9oSi9GeC93Q1pjdlArK1ZvQTlFODJUL25vL3dE MzBhUE5rL3Z2L3dCOUd2T3o0bjhXL3dEUXQzdi9BSHl0Si93bFBpMy9BS0Z5OC83NVdnRDBYelpQ K2VqL0FQZlJwZk9rL3dDZWovOEFmUnJ6ai9oS3ZGZi9BRUx0NS8zeXRKL3dsbmlyL29YN3Yvdmxh QVBSL05rLzU2UC9BTjlHbDgyVC9uby8vZlJyemNlTGZGSi81bCs3L0phUCtFczhWLzhBUXZYbi9m SzBBZWtlYkovejBmOEE3Nk5KNXNuL0FEMWYvdm8xNTBQRlhpdy84eTdlZjk4clZXNzhkK0lOUGo4 eTcwUzZoUWRXWkJqK1ZBSHFIbXlmODlYL0FPK2pTZWJKL3dBOUgvNzZOZVYySHhGMW5WV1lhZnBG emNiZnZlV29iSDZWb2Y4QUNUK0x2K2hidlA4QXZsYUFQUmZOay81NlAvMzBhVHpaUCtlai93RGZS cnp2L2hLUEZvNitHN3ovQUw1RkgvQ1UrTGYraGN2UCsrUlFCNkw1c24vUFIvOEF2bzBlZEovejBm OEE3Nk5lYy84QUNWK0t4L3pMdDMvM3l0Ti80UzN4VVA4QW1YcnY4bG9BOUk4Nlgvbm8vd0QzMGFQ T2wvNTZQLzMwYTgzSGk3eFNmK1pldXZ5V2wvNFN6eFgvQU5DN2QvOEFmSW9BOUg4NlgvbnEvd0Qz MGFQT2wvNTZ2LzMwYTg1LzRTcnhaLzBMdDUvM3lLcDN2ai9YZE9UZmVhTmN3SjZ1b3gvS2dEMUx6 WlArZWovOTlHanpaUDhBbm8vL0FIMGE4dHNQaURybXFxV3NOR3ViaFY0SlJRUVB4eFY3L2hLUEYz L1F0M24vQUh5S0FQUlBPay81NnY4QTk5R2w4NlQvQUo2di93QjlHdk9qNG84V2ovbVc3ei92a1Vu L0FBbFhpMGY4eTNlZjk4aWdEMGJ6cGY4QW5vLy9BSDBhVHpaUCtlai9BUGZScnpuL0FJU3p4WC8w THQzK1FwcDhXK0t2K2hldXZ5RkFIcEhteWY4QVBSLysralI1c3Y4QXowZi9BTDZOZWNmOEpkNHAv d0NoZXV2eUZBOFcrS3owOE8zZjVDZ0QwZnpwZitlai93RGZSbzgyVC9uby93RDMwYTg1L3dDRXI4 V2Y5QzVlZjk4aXFONzhROWIwd0JyN1I3aUFIdTZnRCtWQUhxZm15ZjhBUFIvKytqUytiSi96MGY4 QTc2TmVYV1BqM1g5VGo4MncwUzVuanpqZWlnajg2dS84SlA0dS93Q2hidlArK1JRQjZINXNuL1BS L3dEdm8wZWRKL3oxZi92czE1MGZGSGk0Zjh5M2VmOEFmSW8vNFNyeGIvMExkNS8zeUtBUFJmTmsv d0Nlai84QWZScFBOay81NnY4QTk5R3ZPajRyOFdmOUM1ZC85OGltbnhiNHJIL012WFA1Q2dEMGN5 eS84OVgvQU8ralNlZEovd0E5SC83Nk5lY2Y4SmI0cS82RjY2L0lVdjhBd2xYaXovb1hicjhoUUI2 TjUwby81YXYvQU45R2s4NlhQK3RmL3ZvMTUzL3dsWGkzL29YTHIvdmtWbjN2eEYxblRXQXZ0Sm5n ejAzcUJuOUtBUFUvT2wvNTZ2OEE5OUdqenBmK2VyLzk5R3ZNYlB4ejRpMUdJVFdlaVhNMFo2T3Fj R3JYL0NUK0x2OEFvWEx2L3ZrVUFlaCtkTC96MWsvNzZOSG5TLzhBUFIvKytqWG5YL0NVZUxmK2hk dXYrK1JTSHhUNHRIL012WEkvNENLQVBSUE9sLzU2UC8zMGFQTmwvd0Nlai84QWZScnpvZUt2Rm4v UXYzSC9BSHlLWC9oSi9GcC81bDY1L3dDK1JRQjZINTB2L1BTVC92bzBubXlmODlIL0FPK2pYbnYv QUFrdmk4OVBEdDEvM3lLQjRqOFlIL21YTHIvdmdVQWVoZWRMM2tmL0FMNk5KNXN2L1BWLysralhu NThSZU1NZjhpNWRmOThpc3U5K0llczZiSUk3N1RKYmRqMEVpN2MwQWVwK2RML3oxay83N05KNTB2 OEF6MWYvQUw2TmViMnZqRHhQZlFyTmE2RmNTeHNNaGxUZzFQOEE4Skg0dy82RjY1SC9BQUVVQWVn K2RML3oxZjhBNzZOSjUwdi9BRDFmL3ZvMTU5L3drbmkvL29YcmovdmtVMCtKZkY0LzVnRndQK0FD Z0QwTHpwZitlci85OUdqelpQOEFuby8vQUgwYTg4SGlYeGNmK1lET2YrQWlsLzRTVHhoLzBMMC8v ZklvQTlDODJUL25vLzhBMzBhUE9rLzU2UDhBOTlHdlB2OEFoSXZHSjZlSHJqL3Zpai9oSVBHWC9R dTNIL2ZGQUhvSG5TLzg5SC83Nk5IblNmOEFQUi8rK2pYbjUxL3hualAvQUFqdHovM3hXWGQvRVRX ZFBsOG05MDVvSlA3c2k3VFFCNnA1c24vUFIvOEF2czBlZEwvejBmOEE3Nk5lYzIvaXJ4WGRSTEpC b053Nk1NZytYMXFYL2hJZkdRLzVsNjQvNzRvQTlDODJYL25vL3dEMzBhVHpaZjhBbnBKLzMyYTgr LzRTTHhqL0FOQy9QLzN4VFQ0azhZRC9BSmdFdy80QUtBUFEvTmsvNTZQL0FOOUdqelpQK2VqL0FQ ZlpyendlSmZHSC9RQW0vd0MrUlMvOEpINHgvd0NoZm4vNzVvQTlDODJUSCtzZi92bzBlYkovejBm L0FMNk5lZmp4RjR5UC9NdXovd0RmRkgvQ1FlTSszaDJmL3ZpZ0QwRHpaUDhBbm8vL0FIMGFYelpQ K2VqL0FQZlJyejQrSWZHYWpKOE8zR1A5eXNxNStJK3NXYzV0N3JUdkttL3VNdURRQjZ0NXNuOTkv d0R2cWw4MlQvbm8vd0QzMGE4NWg4VStMNTR3OFBoK2RsUE9mTHFUL2hJL0dmOEEwTHMvL2ZGQUhv UmxrLzU2UC8zMGFUelpQK2VqL3dEZlJyejMvaEpmR1gvUXZUZjk4VTArSmZHSS93Q1pmbEgvQUFD Z0QwVVN5ZjhBUFIvKytqUjVqOU43Zjk5R3ZPeDRuOFluL21YNVQvd0duZjhBQ1MrTXYraGRtLzc1 b0E5QzgyVCsrLzhBMzBhWHpIejk5djhBdm8xNTcvd2tualB0NGNtLzc0cFI0aThhZjlDM04vM3hR QjZGNWovODlIL00wdm1QL3dBOUcvNzZOZWVONGs4YUtNbnczUGovQUhLeVpmaVpyRUZ4OW1sMDda UG5CalpjSFAwb0E5WjN2L3owYi92bzBlWS85OS8rK2pYblVmaXJ4aEtvWlBEc3hVOUQ1ZE8vNFNi eG4vMExrMy9mRkFIb25tUC9BSDIvNzZvOHgvNzdmOTlHdk8vK0VvOFovd0RRdVMvOThVMCtLZkdZ L3dDWmVrLzc0b0E5SDh4Lzc3Zm5TK1kvOTl2KytxODRIaXJ4ai8wTDBoLzREVGg0bzhaLzlDM0wv d0I4MEFlaStZLzk5dnpwZk1mKyszNW12T3g0bjhhZjlDM0wvd0I4MGY4QUNUZU5mK2hhbS83NG9B OUU4eC83N2ZtYU43LzMyL092T204VWVORVhKOE5UWUgvVE9xMWg4UmRSdXJxUzBudERCY0oveXpF SmMrL0dSaWdEMld6L0FOUVQvdGRmd0ZjQjhTZitQRzQvM1UvOUNOTFkrT2RRRU96N0VTYy9mTnVS MjlOd3JFOFo2eC9hR2czQmwzaWM3ZjhBbG50QUFQMU5OYmdlZTdoaW1ua1ZRODFzOWFsU1VqM3Jm bXVSWWxQQXFMazFPdkpGVEtnRk8xd005bzJQYW1lVWNkSzFkZzlLWXlqMHBlekF6MWhQVEJxWlYy akZUbmlvajFwY3RnSHJLQU50U2VhTWRhcHVPYWlKSTcwK2F3eStaRjlhYVdIcldlWFlkNlFTbjFx ZVlMRjVoeFVMNW9qazNuRlRSeDdqVDNBcUZDZTFOTVo5SzBoRU1kS1VvQlE0QVpQbEhQUTFJa1hj OFZlSUdPbE1icFU4b1hJMU8wNXFaWlFlOVYycUU4ZHpUdllDK1pSNjAwdVBXczhzUU90TTNrZDZY T0JvRWc5S2liclZZU0VjMU9weXVhTDNBak9TY0FacHBVa2RLdkpDQnlQU3BQTFVEcFJ5M0M1bEdO dlNoWWlPMWFiS093cU04ZHFYSU1yS213VkxISjVaK3RJNXpVVDg0bzJBdWVhUFdrTXFudlZBNTlh WVdQclJ6Qll2TXltbU4wcXB1UHZUMGNrNDdVdWE0V0hucFVmSnFYdUtzTENCeUtkcmlLQlErbEpz YkhUaXRJeEtPMU1JR09sTGtHVVFoUFkwOEx0R0tuTlJ0MXpTc0E5SmRvMm1wQk1BT3RVMkhQZW01 SXA4d1dRbEZGSjNxQmoxRlNBYzB4YWVLcENZNFZJcHFNVThVeEluak9hc0tLcnhkUlZoYTFRRGl0 VUpmOVkySzBEOTJzK1Q3N1VwN0FpbTNVMG5mTkszM2pTVmdVUFdwbEZRcDBxWmF0Q1k4Q25MU0Rw U2pyVEVTcWFuanF1dldyQ1ZwRUNZTHhVY3d4RzMwcVZhanVQOVcvMHFuc0lwRWZMVkZqeWF2ZHFv dDFOWVRLUW9OVEpWZGV0VHBTU0FtVVZJT0tZb3AvZXRFSWNEaXBVUE5RanJVcWRhWWl3bFNBY0Nv MDZWSUswUUVVd3dsWjl5Y0lNZXRhRTMzS29Uaktpb21CVXp6VWkxRjNxUlB2VmlobGhCVXFyaW8x cVlWcWhDaW5nMHp2VGgxcWtCTXRTZ1ZFblNwVjYxYUFkaW9jZjZSSDlSVS9hcTUvNCtFK3RLV3dJ OTYwQS82QkQvQUxnck44Yy84ZWRwL3dCZFcvbFdob0gvQUI1UmY3Z3JQOGNmOGVWbi93QmRXLzhB UWE1aWliNEgyTUsyZmlXK01TbVo5UUVXOGpuYUJuSC9BSTlYcWUxZjdvL0t2Ti9nbC95TC9pRC9B TENyZitnTFhwSXFSaHNUdWkwdmx4bitCZnlvcDFBRFJERWYrV2EvbFMvWjRpUDlXdFBGS0tBSTBS RGxUR200ZjdORFJnZEVUL3Ztbk9DUG5YcXRUZ0xJZ1lkRFFCbk9XWHN2NVZsYTlFbDFvTjlITkdq TDVMSGxSVzdMRldUckNZMGErLzY0TlFCd0h3SnNMZUh3bnFkeUlrODJUVVdUY1J6dFZSZ2ZyWHFK MktNc0VBN2s5Szg0K0IvL0FDSkY5LzJFNWY1TFhiNjlwS2E5b1Y1cFR6TkNsekhzTWlESlhuMG9B djhBbVczOStIL3ZvVTRmWjI2ZVdmeEZlVkg0SFdJNU92M2Fqcmt3cngrdGNiNEYwWVhmeE90NGRM bmtuc3JHNE14dUhHM2RHdmZBOVQwK3RBSDBTSW9qL3dBczFvTnZFZjhBbG12NVUrbG9BYkdrYlpI bElHSCt6U05HRjZJdi9mTkt4S01ISGJxS3M0VjBCSFEwQVp6bGw2QmZ5cm4vQUJqQWwzNFMxSkpv MFlDTEl5dlN1b21pcm4vRlM3ZkN1cGNmOHNUUUJ5dndPc29JZmhyRGNDRlBObXU1Uzc0NU9EdC9w WG93QS91citWY0I4Rk9maFpaZjlmTTMvb2RYUGlocjE5NGY4SStkcHptS2U0bVdEemw2eHFRU1NQ ZmlnRHN5SXcyMWdnYjBOT01hWjVSZnlyeFR3MThNazhUK0dJdGJ1ZGZ1aGVYQVprd2R5b1FTUG1K T2UzNFZvL0J6eEhxbDNmWHVpWHR3OTFid1JlYkZKSTI0eGtOdHh1OURtZ0QxbnlvLytlYTBwZ2k3 UnBuNlU0ZEtkUUFrY2Nici9xa0REcjh0SThXT2lLUCtBMEUrVzRrSFR2Vm9oV0ZBR2M1WmVnWDhx NUQ0bFc2WGZnTFV2TlJHS1I1VTdlUnhYYnl4ZTFjaDhRMTIrQTlWL3dDdVIva2FBS1h3aXM0TGI0 WWFSSWtTYjV2TWtkc2NrbHpYYjhkMVg4cTVENFYvOGt1MEwvcm0vd0Q2R2F4L2kzNHJ2ZEIwMjEw L1RwV2dudk56UE1uM2xqWHN2b1NUMTlxQVBSL2tMYk1KdTlPOUxzVCs0djVWNHpGOEpMOS9EcWFv bXQzQTFob1JPc1l6dHpqZHQzWjNaOS9XdWorRS9pKzY4UTZkYzZkcVVwbHZMTGF5eXQ5NTR6d04z dUR4UUI2SjVVWi9nWDhxUXd4OW8xejlLZlNpZ0IwY2NUcmtSeDU3L0xUWGlDOUVYL3Zta0RlVklI L2hQQnEyUXJVQVpybGw3RDhxNEg0d1cwZHg4UGJ5UjQwTHhrRlR0NUZlanl4ZWxjRDhYRjIvRG5V YUFORDRjV2tObjhPZEI4cUpGWjdSWGNnY2trazVycUN5cXBkd3FxT3BQQUZjOTREL0FPU2VlSHYr dkdPc3Z4djRIdXZGOTVaRk5Ya3RMT05XV2VIbGczb1ZYcG5xT2ZhZ0RzWWJtMHVDVmhtdDVXSFVS dXJZL0twdHFaKzR2NVY4L3dEamJ3T253L1d4MUhUTlpuYWFTVXFBY0pJcEF6dVhiMjdWN1Y0WHY3 alZmQzJtWDk0dUxpZTNWNU9NWmJIWDhldjQwQWEzbHAvY1g4cVR5bytxeHBuNlUrbG9Ba2ppaGRN ckZHUCtBaW1QRUY2SW4vZk5JaitWS0QvQTNCcTBjTngzb0F6bTNEc28vQ3ZML2pqYlJ5ZUJoTzBh ZWJITXVHQzg5UlhyRXNRcnpENDREYjhQM0gvVFpmNXJRQjFmaGUwaHN2Q1dpeFF4SW8rd3hFNFhx U29PYTJBQWY0UitWVWRCWFBoblIvOEFyeGgvOUJGYXFSMEFSZVVoNm9LYjVhQTVLQ3JqSnNUSnFt VGswQUx1QTUySi93QjhpbW1RL3dCMVArK1JTR21tZ0JUTTQ2YmYrK2FyTnFrQ3plU2J1M0V1ZHZs bDEzWjlNVklhOFF2TGNmOEFDOUF1T3VvSS9UL1pCb3NCN2VibVgxSDVWNVg4ZExkSi9EVmhjc2kr YXR4dDNBWVArZWE5UE5lYmZHMy9BSkZDeS82K2gvU2dEMDJ4dG9yTFRiS0NDSkVSTGVNWUEvMlJW b0RQVlYvS2hFekJiZjhBWENQL0FOQkZUSkhRQkY1YW4rQVVnalJUbllLc3VnUk0xWHptZ0JjZ2Z3 Si8zeUthWkNQNFYvNzVvTlJtZ0J4bFlmM2Z5cGhuZjFINVVocGhvQVUzRW45NzlLOGorTnRwRlBQ NGVtYU5kOGx5STJJSFVFLy9BRnE5WUlyekQ0eTlmRFAvQUYvSi9NMEFlc21GTFVpR0dORVJWVUFC ZmFuRG5xcS9sVXM2ZnYycHlSMEFRK1dwL2dYOHFGalFIT3dWUElnUmMxRUtBRkpVZndKLzN6VFMr UDRVL3dDK2FEVERRQUdWaC9kLzc1cGhtZjFINVVHbU5RQXB1SlBVZmxYa0h4VjArR2Z4L3dDRkhh TmN6enFrbUI5NGJscjFzOUs4dytKbi9JOStEQi8wOUovNkVLQVBXWkFzTXp4eElpSXB3QUZwUnox VmZ5cDg2LzZWSi92R25KSG1nQ01vdjkwVUpHZ09kaW42aXBYVGFLYUJRQXAyOW8wLzc1Rk5MWTZL di9mSXBKWkVpamVTUndxSXBabVBSUU9wcnp2VWZpcFkzRnJORDRmc3IrN3ZwUDNkcTV0OFJzeE9B YytsQUhlRFVMWnJwclZMbTNOeW95MElkZDQvNEQxcDVtY2VuNVY1RmMrRnYrRVcxWHdqZFN6UEpy TjNxT2J5NTNINWkyTXI5T1NLNm54SDRzbXNsL3RIUjViZThzTk91VEJxc0FIN3hCMHl2MG9BN0V6 djZqOHE4ZzhhYWJieS9ISHd2bUZNWERMNWdDOE5qLzhBWFhyRU0wZHpieDNFTGg0cFZEb3c3Z2pJ cnpUeGYveVhId2QvdmYwRkFIcXhPeVJsUkVVQThBTFR3YzlWWDhxSFg5OC8rOGFrU09nQ01xdjl3 VStPTkFkMnhmeEZLNll4VGdCaWdBTzBkSTQvKytSVFMyUDRVLzc1cFRURFFBaGtZZGwvNzVwaG1m Mi9LbE5Sa1VBQm5rOVIrVmVJZkVDMGl0dmk1SExFaW9aN1BjMjBZeWVSL2hYdHBGZU4vRWYvQUpL cGFmOEFYaWY1bWdDc24zQldCNG4vQU9RWFAvdS8xcm9FKzdYUCtKLytRWlAvQUx2OWFvUjU0eDcw cU1kd3ByVTZJZk9LWUdqSDk1YXRoYXFSZmVGWFY2VjBRSkd0VVRIRlN0VUQwWEFZeHFNMDQwMm9Z REdGUXZVN2UxUXYwcVdNcnR4VWVjVkk5UkhyV1kwV0xZL1ArRmFNQXlLenJiNzFhTnYzclNBbVdN VkcxU25wVVQxcXhFRG1vbU5QZnJVWnJOZ05QU28yRlNVeHFrWkE0eFVSTlRPS2dOWnNhQUhpcmtY M1JWTVZjais2S3BBelFqSHlpbFlVa1gzUlRtcmRiRWtEOFZBeHFkNnJ0MXJOb1l3bmltbnBTMEhw VWpJbXFKcW1hb1c2MURHSjJwMGYzeFRhZEg5OFVJQ3gvRUt2cU9Lb0Q3NHJRajZWckFrYXdxdTV4 VmxxcXZUa0JHeHFQclQycHRaakdFVXdpcEdxT2tBMmp2UlJVMkdQV3BCVUttbmc4MDBKa2xQV21E RlNnVmFFU3gxWVdvRXFaVGc1eldpQWtQSzRyUGxHSkdGWEM5VTVEbHpTa0NLYmZlTkpTc1BtTkoz eFdBeDZkS21Xb1ZOU0thcE1DVVU0VXhhZW95S3BDSkY2MVlqcUZSelV5OFZvaEU2MHlmOEExYi9T amRnZGFqa2JNYkQycW5zSXFucFZGdXBxOVZNcnlhd2tXaHE1OUttU29nS2tYZzBrTXNMVCs5UkEx SXZKcTBTT0hXcFVwaWlwVkZXSW1UcFVncUphZVRXaTBBWk45dzFuM0p4R0t2U3Q4bFU1MTNJQldj eG9wZDZrUWMwaFQycHlpc3JBeXd0U2cxWFUxS3BxMElsRk9IV21pcEZGV2dKRTZWS3RSclR3YXRB eVR0VmM1KzBSL1VWS1d4VVFPYmlQNmlsTFlTUGQ5Qk9MR0wvZEZVUEd4elpXbi9YVnYvUWF2YUYv eDR4ZjdncWg0MDVzN1QvcnEzL29OY3hacGZCSC9rWC9BQkIvMkZXLzlBV3ZTcTgxK0NYL0FDQVBF SC9ZVmIvMEJhOUtxUmlpbHBCMXBhQUhEcFNpdVo4VStOZE44SXlXYWFoRmN5RzczZVg1Q2c0eGpy a2oxcmR1YjZ6c0lsbHZMcUcyalk0RHl5QkFUNlpOQUZxbVJQNVpkUFQ1aFNveXlJcm93WkdHVlpU a0VleHFLWDVaVWIxK1UwQVdjaVJheU5lVEdoMzMvWEUxWnRwc1NzaFBRMUY0aC81QUY2ZittUm9B OC84QWdlZitLSnYvQVBzSnkveVd2U1JYbXZ3T1AvRkYzLzhBMkVwUDVDdlN4UUJ3dnhXOFRmMkY0 WE5sYnliYjNVTXhMZzhySC9HMzlQeHB2d2o4TmYySjRXRi9PbUx2VWNTSEk1V0wrQmZ4Ni9qWEw2 cDRXOFErTlBpUWx6cW1tWEZyb3lQc1Y1TVlFSzl1dlZ2L0FHYXZaVlZWVUtxaFVVWUFIWWVsQURo VHFiUzBBT1BJcGtibEZaUDdwNCtsT3FHUVlsSG93SzBBV2d5eUxtdWY4WXJ0OEo2bC93QmNqV2pa WEh6RkNlbFVQR21QK0VTMUQvcmthQU9UK0NmL0FDUzZ6LzYrWnY4QTBLdEg0a2F2cEdsK0ZYaTFl MCsyTGROc2h0dyswczQ1M2J2NGR2cldiOEUvK1NYMm4vWHpOLzZGVnY0bCtFTHJ4Wm9rSDlubFRl V2psMGpZNEVpa2ZNdWV4NEdLRUI1em92Z1h4bGQrRnBiM1NyeHJhenZGTHJZQzVaV21Uc2ZUL0d1 bytEdXM2V2pYT2hycHEyV3FLdTk1ZHhKbTI4RUhQSUs1NmRLb2FSNHg4Y2VIZEhpMFovQ3M4ODF1 bmxRek5ESndvNloyOE5pcjN3eDhGNnphYS9QNGsxeUpyZVIwZlpFLzMzWno4ek1PdzYvblFCNnpT aW0wb29BY1JrVXlPVXBIZy93SEg0VStxOG8rZGgvZlVqOGFBTG9aWlZyai9pVXUzd0hxbi9YTS93 QWpXOVlYR1R0SnJEK0p2L0loNmwvMXpiLzBFMEFVZmhUL0FNa3YwVC9ybS84QTZHYXAvRkR3WGQr S2RQdHJuVFFyM3RwdUhsTTIzekVPTWdIMUdLdWZDai9rbCtpZjdqLytobXIzak84OFJXT2pwTjRh czF1cm9TZ3lnZ05pTWRjTDN6UWdPSTBqVWZpZSttUjZLdWtwYkNPTVJmMmhjcHRNYUFkYzV3U0Iz eFdWOEU0My93Q0VzMUpsYmNpMmhETjYvT01mMXE5cVBqVHg3cmxpK2xXbmhpVzBubVV4eVN4d3la d2V1TjNDL1d1dytISGd4L0NHanltN1pHMUM2S3ROc09SR28rNm9QZnZRQjJ2MHBSVFJTMEFLd0RL UjYwd1RGWWhucXAybW4xV25IK3NYKzh1UjlSUUJmVjFsVHRYQWZHSVkrSGQvOUs2elRybmNOcE5j cDhaUCtTZVh2KzZhQU5Id0NjL0R2dytmK25KSzF0V3VwTERSYjY4aFVOTEJidklpbm9TRkpGWkhn REgvQUFydncvOEE5ZVNWb2VJYnU2MC93NXFOM1lwdnVvWUdlSmRtN0xmN3ZlZ0R5andMNFdrOGZY bHo0aDhUM1UxeXNVb2pGdTN5aHpqZCtDODlCWHRTSWtjYW9paFVVQlZWUmdBZWxjWjhPZkVHdCtJ YkMvbDF5M0VFc015ckVCYm1MS2xjazRQV3UxRkFDaWxwdE9vQUdYY3BGTU01UkVZOVI4cHArYXFY SS9keWdkY2J4K0ZBR2lrZ2tUTmVYL0hZWThCc1ArbXEvd0RvUzEzbW5YTzRBRTF3WHgzT2ZBeC82 NkwvQU9oTFFCM0hodGMrRjlIL0FPdktMLzBFVnVSeDFqZUZSbndycEgvWG5GLzZDSzZHTmNDZ0RQ djMyN1l4OVRWS3BMcVR6TG1ROXM0cUltZ0FOTlB0UVRUU2ZlZ0JEWGtkMWJPZmp6Q2RoMitZajV4 eC9xcTlicno2NThSZUpVK0pDNlVsdC94S1B0Q29aUHNwUHlsUVQ4LzFvQTcwL2pYbS93QWJmK1JS c2Y4QXI2RmVrVjV0OGJmK1JTc3Yrdm9VQWV2VzZiclcyUDhBMHhUL0FOQkZYSTR1S2hzMXpaMjMv WEZQL1FSVjVRQUtBTTI5WUJ4R08zSnF0U3l2NWs3djZtbW5wUUFoTk5OS1RUVFFBMDF6dDM0MTBD ejFvNlJQZU90OEpGaThzUk1SdWJHQm5HTzlkRWE4ZTFiU1lkVytNOGNXbkdSMmlranVMMXljcWhY QklINEJSOVRRQjY2ZUs4ditNdjhBclBEUC9YOG4vb1JyMUJ1dGVYL0dUL1dlR2Y4QXIrVC9BTkNO QUhzN3BtWS9oVThjZUJSdHpKK1ZUZ0JWb0F6YnBzeTdCL0QxcUttbDk4ak5ucWMwRTBBQnBwb05O TkFFTjFjUldsck5jenR0aWhRdTV4bkNnWk5ZR2srTi9EMnZhZ3RocHQ0ODF3eXN3VXhNdkE2OGtW czZuYW0vMHU3czFmWVo0WGlERVoyN2xJeml1RThIZkRXZnd2cjhlcHlhbkhjS3NUSjVheEZUOHc5 YzBBZWdHdk1QaVoveVBuZ3dmOVBTZitoQ3ZUNjh3K0puL0krZURNLzgvYWYraENnRDJTUk0zRC83 MVRwRnhTbGN6TjlhbjRSQ3g3Q2dETm5iTTIzc3RNcHFuZGx2WG1sTkFHZDRnNThONnAvMTZTLytn R3VkK0cxOWFKNEEwYUEzVUN5K1d5K1daVkRaM3R4ak5kZ3dEQXF3eXBHQ0Qzcmg5WCtGM2gyNnNy bit6ck1XTiszenczQ08zN3R4eU9NOUtBSS9pRC95SHZCLy9ZVS8rSnJJdko3T1R4UjQzdTROdjlu UjZYNU4wdys0OCtPbjFxbC9hbXIrSWRhOE02VGY2ZGNMcStsMzI2OGtNZjd0a1hIejd2Y0N1MjhS K0ZmN2VlMnRVblMyMHczQm52NElrdzl5MzhPV0gwNW9BazhFeHl4ZUI5R1dmSWtGcXZCOU8zNlZ4 dmk3L2t1WGc3L2UvcFhwNFZVVUlpaFZVWUFYZ0FWNWg0dS81TGw0UC8zdjZVQWV3bVBNcmZXckNS WUZJcTVrSjk2bmZFY0xONkNnRFBrT1pqNkx4UWZTbUowejNOTG1nQU5OSnBTYVlhQUVOTU5QeG4v NjFNUEZBRGE4YitJdy93Q0xxV24vQUY0bitacjJROWE4ZCtJb3o4VTdZZjhBVGlmNW1nQ3JHUGty bnZGQS93Q0paUDhBN3Y4QVd1aWovd0JYWFBlS1ArUWJPUDhBWi9yVkNQT21GTEh3NHB4VWswOVU1 cXJBWFkvdkNyaTlLcG9jTUtzZzVyZUpBNXFoZXBTYWpOREJFQnB0U01LWVJVakdOVUwxSXg1cUZq VU1aQzFSRVZLUm1rQzg5S3pHaVMyKzkrRmFOdlZHQVliOEt1d3NCbXRJQ1phTlF2VHQxTlk4VnFJ Z2NjMUVSVTdWR3dyTm9DS21OVHptb21xUmtibW9XNjFLM1NveURXYkdob3E1RjkxYXFoZmFyVVl3 Z3FvZ3pSais2S1UxRXJZVVUvT1JXNlpKRTlWMnF3K0tpWVZER1E0NzBoNlU1cVl4eHhVREkyOXFp YnJVckdvbXlUVU1CS2RIOThVMm54Zzd4UWdKL3dDSVZvSnd2V3M4ZmVGVzFmcHpXc1JEMnF1OVRr NXFGcWJBcnRUYWxZWnFNMUF4clZHVHpUelVaNjFEQWw4aW5DM05TS2FtVG1yc0lyZlp6NjAwd2xh ME52dFRIVEFQRlBsQXFBN2FEUGp0VEh6dHFIdFVYc05Ga1hPTzFPKzFHcWxPV2ptWXlkcHkxS09S VWFpcEY0cGlZNHhCbHdEU2ZaaDBwNE5USnpWSlhFVi9zdEtMWWlycWoycHpJQ0tmSWd1WndRcWVh ZXJCZXRUVGpBWGlxVXh4dHBiQVRmYU1kQlRoZGRzVlJ6VGxxZVlkaTc5cFBTbUdRdTNvS2lVVklv cXJpSkI2VXJRaHVsTnFaVDNwb0NMN0xtbEZwNzFaVWlwQjlLcmxDNVQrellIV2tWZHZCcThWelZh WWZQNlVtckNHK1lxTDcwMzdWZzFYbE9KS2l6bHFseUtMNHVpZTFPRnp6VkZhbVVVY3pFUytZV2Iy cVJWQk9LaVVWSXRVaEFiWUUwZlpNMUtwNXFWYXF3RmY3S1JTR0ZsT2F1aW1zdlhpbnlnVmdjVUdj Q2trNk5WRXY3MURkaGw0WElwMzJuUGFzOVNTZXRUSlM1Z0xKbnpUNFNXbFgvZUZRS3RUd2o5Nm4r OEtzUjd6b0ovMEdML2NIOHFvK00rYk8xLzY2dC9LcnVoWUZsRi91aXFQakg1clcxSC9BRTBiK1ZZ RkdwOEUrTkI4UWY4QVlWYi9BTkFXdlNlSzgzK0NveG9YaUQvc0tuLzBCYTlIcVJuTmVLOVM4VTJj OXBiK0d0Smd2RE1yRjU1bndzUkdPRHlQWDFybEpmSG5pendwcTFwYitNTk1zeFozUndKclhxQm5C SUlKQnhucFI4UVBFK3J4K01kUDhNYWZxSDlsMjg0ak10Mk9EOHpFZGV3SDlhNUQ0bWFKRG9qYWZD ZkVONXExMDVacEV1WmcvbGpqQkE3WjUvS21CMFh4d3dicncrUnlNeUhQNHBUUGpaYzZzOE5yYVMy YUxvNFpYanVRZm1hWFljcjE2QWUxSjhhUCtaYS8zRy85a3JUK040ejRUMDBnWi8wdi93QmtOSURm OEJhbjRudkxlS0RXdEhoc3JHTzBqK3pUbzJUSndBTThuK0htdXZ1T1lqNmptczd3NWN3WEhodlN6 RE5ISVBzY1gzR0IvaEFyU2ZsRDlLQU0xMzh2VWo2TmhxazE4N3ZEZDUvMXlOVmJ2aWUzYjFYSDVH cDlhT2ZEVjMvMXlOQUhDZkEvL2tUTlEvN0NVbjhoWHBRcnpUNEgvd0RJbWFoLzJFcFA1Q3ZTaFFB K3NxODhUNkRwMTI5cmU2dloyOXdtTjBVa29WaGtaSEZhZGNUNGgrR0dqZUpOYW4xVzd1NzJPYWJh R1dObDJqYUFCMUh0UUJ2anhqNFlQVFh0UC84QUFoYW10dkUyZzNkeEhCYmF6WXl6U0hha2FUcVdZ K2dGZVcrS3ZodDRWOExhRk5xVjFxT29saDhzTVc5TXlTSG92M2Z6OXF3ZmhSNFh1ZFg4VHc2cWN4 MlduU0NScE1mZmsvaFFmek5BSDBOVVZ4eEh1SDhKelQ4MHlYbU52cFFCbWIvSzFLUmUyY2lvL0dM WjhIMzMvWE0wbDBjWDBURCtKVnB2aTA1OEhYMy9BRnpQOHFBT1grQ1gvSk1MVC9yNW0vOEFRcTlD RmVlZkJML2ttRnIvQU5mTTMvb1ZlaENnQjRKNlZrd2VLZEF1cnhiT0hXTE43bG4yQ0ZaUnZMZW1Q V3RTdkZQaTE0V2swclZZdkUrbWd4eHpTRHpqSC95em0vaGY4Y2ZtUGVnRDIwZWxaemVJOUNXN05x ZFhzaGNoL0xNWG5ydTNkTnVQWE5jYmNmRW1BZkRRYTVHNmpVNUI5bFdMKzdjWTVQMEErYXVZK0VI aE5yNi9meFBxQ2w0NG5JdHQvd0RITC9FLzRmeitsQUh0bFJUbmJ0Yis2YWZtbzUrWVdIdFFCbHd0 NU9vU0owdzFaL3hLYmQ0QjFEL3JrMy9vSnEzYy9McWdiKzhxdCtsVVBpTno0QXYvQVByazMvb0pv QXJmQ2Y4QTVKZm92KzYvL29acnN4WEdmQ2YvQUpKZm92OEF1UDhBK2htdXhvQWZta2VSSW8ya21k VWpYa3M1d0IrSm9GZUJlTXZFT3ArUFBGZzBQU21kckpadkpnaFU0RWpBOHUzdDErZ29BOWVmeDU0 VGltOGw5ZnN0NE9EaDhqOHh4VzVhM2x0Zlc0dUxPNGluaGJwSkU0WlQrSXJ5MjArQituaXpVWG1z WFRYSkhKaFJRZ1BzRHlhWjRSOEMrSmZDZmpwRnRyd05wQlF2Tk9QdVNyL2NLOW5vQTlielVVdkRJ ZjhBYXhVbFJULzZvKzFBR1RhUDVWNjhmbzJLd3ZqQTJmaDNlZjdoclptK1RXSDl5R3JEK0xoLzR0 M2VmN2hvQTFmaC93RDhrNzhQL3dEWGtsZEdPSzV2NGY4QS9KUE5BLzY4a3JvNkFHWGQzQloycjNO NU1zTUVZM1BJNXdGSHFhcmFkcm1sYXcwaTZacU52ZHRHQVhFTWdiYm4xcWE4czR0UXNMaXluR1lw NG1qY2V4R0s4SStHMXpMNForSkxhWGRFcDVyU1dVdWY3d1B5L3FQMW9BK2dhejIxN1Iwdi9zRGFw YUM4M2hQSU15NzkzcGoxcXhkM1VWaFpYRjVNY1JRUnRJNTlsR2E4TytGOWxKNGkrSVZ6cmx5Tnd0 OTkweFAvQUQwY2tML00vbFFCNzFVTW95Ni83WHkvblVsUlRjSm4wSU5BR05ZeUdPNUtIc2E1SDQ1 SFBnVS83Ni8raExYVk1QSzFhVmY5dXVTK04zUGdQL2dhL3dEb1MwQWVpZUUvK1JWMGovcnppLzhB UVJXK3gyUXMzb00xZytFditSVTBqL3J6aS84QVFSV3ZldHNzWkQ2akZBR0tEazUvR2x6VEJRVFFC blhQaUxSYk80ZTN1ZFZzNFprT0hqZVpWWlQ3aW9WOFZlSHBHQ3JyVmdXUGJ6MXJ4YnhiYVIzL0FN VnJxMGxMQ09lOWppY3IxQVlLRGl1dTFyNFI2VmJhVGRYRmpmWFN6d3hOSXZuRldSdG96ZzhESFNn RDA1WkVrakR4dXJvM0tzcHlEK05MdTR4bml2SXZnM3FWMGIyKzAweU8xb0lSTXFrOFJ0dXh4Nlp6 K2xldG1nQkRYbS94dC81Rk95LzYraFhvOWViL0FCcy81Rkt5L3dDdm9VQWUwV0kvME8yLzY0cC82 Q0tzenQ1ZHZJM29wcXZZL3dESG5iZjljay85QkZMcUxiYkpoNjRGQUdRdkZLVFRRYVJqd2ZwUUJu d2VJZEZ1cmxMYTIxV3psbmM3VmpTWlN6SDZWb0UxOHJCcDRiOTdtMkxyTEJLWkE2ZFV3M0JyNks4 SStJNHZFL2grRytVaGJoZjNkeEdQNFpCL1E5UlFCY2wxL1I0dFEvcytUVXJaYjNlRThneWZQdVBR WXE0SVlrbWFaWW8xbGNZZHdvRE5qcGs5NjhSMWYva3RnNS81aU1QOGxyM0J1cG9BUTE1ajhZLzla NFovNi9rL21hOU5yekw0eC82end6LzEvSi82RWFBUGNWSHpmbFJkUHN0Skc2Y1U1T3Y0VkJxYll0 UXY5NWhRQm1MMHFyZTZwcCttQkRmM3R2YWgvdUdhUUx1K21hc0ExNVQ4YnZtdHRHLzY2Uy95V2dE MCt6MUt4MUtKcExDN2h1VVZ0ck5FNFlBK25GVFpyeEg0UGF2OWg4UlQ2Vkt4V085ajNJRC9BTTlG R1IrYTVyMnhtVlFXZHNLT1NUMkZBR2RmK0lkRzB1NCt6MytwMjF0TnQzZVhKSnRPUFdyTnJlVzEv YXBkV2s2VDI4Z3lra1p5RzdkYStiUEZPcXZyM2lTLzFQa3hTUzdZL1pCd28vSVY3ajhPL3dEa1Fk SkgvVE52L1Eyb0E2YzE1aDhTL3dEa2ZmQm4vWDBuL29RcjA0MTVqOFN2K1IrOEdmOEFYMG4vQUtF S0FQY0FQM2pmV20zcmJMTi9VOFZJUDlZMzFxcnFiWWlSZlZxQUtRNG9KcGc2VVVBUVgxL1o2YmF0 YzMxMUZiUUwxa2xjS0s0dlRQaWRwZDU0bXY3QzR1TE8zMCtML2oydS9NSTg0OGV2QXJpZkZVMy9B QWxIeFlUUjlWdTJ0OU9obkZ1dUd3RkdNayt4WThaOXhVMmsrQk5IMWJ4cjRrMFp4Y1EyOWtGK3ps SlBtWEo3NTYwOUFQWmttam5pV1dGMWtqWVpWMGJjQ1BZMEd1YzhGZUZ2K0VSMGlTeWE3YTVlU1pw QzNSUU9nMnIyNDYrNXJvU2FRQWE4dzhXLzhseThILzczOUs5Tkpyekx4Yi95WFB3Zi92ZjBvQTl0 UWZPZnJUYjV0dHFSL2VJRlNKOTQxVjFKdjlVdnZtZ0NxT2xLVFRRZUtUclFBcE5OSnJNdGZFR2wz K3NYR2xXZDBzOTFieCtaTjVmS3B6akc3MTlxMGFBUE9makxjVDIzaDNUMnQ1NVlXTjNnbU55cFB5 SDBycFBBcnZKNEcwZDVIWjVHdHdTem5jVHllcHJsUGpXNi93RENQYWFoWWJqZGs0LzRBZjhBR3Vx OERLVThDNktEd2ZzcTBBZEJYai94REdmaWpCLzE0LzFOZXYxNUQ4UVJuNG9RL3dEWGovN01hQUtp ZmNGWUhpUlEybnlyNmordGRBbjNLd3ZFUC9IbkpWcmNUT0creWlsRVFYdFV4cGhQRmJXSkl6d09L Ulp5dlVVVkd3b0FrTnpqdFRmdFFQYXE3akZSTWFoeUdYaGNBMEU1NlZRVnpWdUk1VDFvVHVOb2Q1 UmR2YWo3TDcxYWpIeTlLazI0Rlh5a29vRzB4M28rekRnMWFiaW8yTkxsR1JsUW80eFViTVVPUlVq R28zR2FURUw5cElHS1B0V0tnWWVsUk53S200eTBia1pwUktHRlVNKzlQUnlXQXBjdzdGc2pkU0xB VFQ0eGxoNlZiQysyS3RLNUpSTnFlOUlMWEhGWDJIRlFzY1UzRkRLd3R3RFJqQnhVak5VWnFRR2lZ cTNQcFRoYzhacU5nS2lZVkZ3c1RtNnBQdE5WRG1nSEZMbVk3RnhuM0RpbWxTNUdLamg3ODFidHdN RSs5VXRSTmtQMlludlRmczN2V2h0eFRHcXVVTGxFMitEVGhHRUdhbFkxR3hxYldBWVIzcEZsWmV0 TC9EVEdwWEdQKzBuRko5cHoycUEwbjQwcnNDY1RaT0tDUWFncVJmdTBKZ08yRmo3VXYyWStwcXhD dVkrbFRLb0FxbEc0aW1sV1l1Z3F1dldyRWROQVdGcHNoQ3IwN0duTFRaaDh2NFZiRVpyL0FIVFVO VFNmY05RMWd5a0ozcVZhaTcxSXRJWktCVHFRVTZyV3doVk5UUjFDT3RUSjJxa0lzcHlLbEE0cUpP bFNyN1ZvaEZXNk9kdFo4L1JhdjNQWTFRbjZMV1V4a05QU21VOUt6R1RLS2xBNHFOZXRTaXRFSU85 UFgwcG5lbnJWTGNSTWxXRkZWMHF3bFdnSk8xVTdqL1cvaFZ2dFZPNC8xbjRVU0FvWEkvZU45QlVT NHpVMXovckcrbFFqclhPOXl1aE1tTTFPdFYwNjFZV3JRbVNDbEhCcEJTOTZzUklwcWRPMVYxcXds VWdKUlN0MHBCUS9TckVVWmVWYjZWbk53YTBaT2pWbnQ5NnVlZTVTSEpWaEtycDFxeW5haEF5WmFs aC8xcS83d3FKYWxpLzF5Zjd3clZDUGRkRC9BT1BHTC9kRlUvRjNOcmJmOWREL0FDcTNvWnhaeC83 b3FuNHM1dGJiL3JvZjVWZ1VhL3dZR05EOFFmOEFZVVAvQUtBdGVpMTUxOEd1TkU4UWY5aFQvd0Jr V3ZSS2taaGVKUEJ1aStLeEYvYWR1NWxpRzFKb24yT0I2WjdqNjFrZjhLcDhKZllVdFRaemZLMjh5 aWMrWXh4amx2VDJydEtXZ0RuOWM4RjZQNGppc1UxRVhMaXlYYkVVbDJudDE5ZnVpcit1YURwL2lM U20wM1VvakpBU0dCVnRyS3c2RUgxclJvb0E1bndyNEUwbndoY1hGeHAwdDI3em9FYno1QXd3RG5n QUN1blBTa29vQXliMGZMQ2ZSMkZUNnlQK0tadS8rdVZNdWx6RC91eTFMclF4NFp1Lyt1VkFIQS9B L3dENUV6VVArd2xKL0lWNlZtdk5mZ2YvQU1pWHFIL1lUay9rSzlKb0FXbVhGekRaMnN0emN5ckZC RWhlU1JqZ0tvNzA2dkZ2aTc0eGU2dkg4TldUTWx2YnNEZE1PUE1mcUYrZzQvR2l3R05yR29hbDhV L0cwVnBZaGt0VkpXQlc2UlJqNzBqZTU2L2tLOTEwVFI3UFFOSXQ5TXNVMnd3cmpQZG03c2ZjMTVm OFB2RVBnendsbzM3N1V0MnAzSURYTWdnZjVmUkFjZEIrcHJzN2Y0bGVFcm00aXQ0ZFRMU3lzRVZm SWNaWW5BSFNnRHJjMGpmZE5IU2tQU2dESXZCODFxMzFYOWFiNHNIL0FCUnQ3LzF6cWE2WEtRbjBs SXFQeGNNZURiNy9BSzVVSURsUGdsL3lUQzEvNitadi9RcTlCcno3NEovOGt2dFArdm1iL3dCQ3Iw SDBvQVdzM3hDdW12NGR2MTFnZ2FmNUxlY1Q2ZTN2MHg3NHJScnhiNHRlS24xVFVVOE02YXpTUlJT QVhHei9BSmFUWjRUOFA1bjJvQTh4VHkvT1ZYYVVXdm1jNDY3ZlhIVGRpdnF2UlVzSXREc1UwcmIv QUdlSVY4Z3IzWDErdnJYQ1QvREtML2hXbzBoRVQrMTQvd0RTdk4vdlRZNVRQcGo1Znd6V0o4SVBG ald0eTNoZlVHS2htWnJYZi9DLzhVZjQ5ZnJtZ0QyU2tmN2pVZmpTSG9hQU1lOEgrbFd6ZXFZL1dx SHhGR1BoL2Y4QS9YSnYvUVRXbmRLUzFxZjlwaCt0Wi94SEdQaC9mLzhBWEkvK2dtZ0NsOEtPUGhm b3YrNC8vb1pyc2E0NzRVLzhrdjBUL2NmL0FORE5kalFCQmZGMTAyNlpQdmlCeXVQWGFhOEwrREN4 dDQzWjVNR1JiT1FwbjF5dWYwelh2WkdlQ01qdUsrZDlac3RSK0cvajFidTJUTUt5bVcyWnZ1U3hO MVEvaHgrRkFIMFZtak5jQmFmRjd3dlBhQ1c0ZTd0cHNmTkNZU3h6N0VjSDlLejlGK0tVK3Y4QWpp MzA2eTAyUTZaTXBUcG1RSC9ubzNZTDJ4UUI2ZjhBU21TOHh0OUtXa2I3cG9BeHJzZjhUS0Z2N3lM V0Y4WEJqNGMzbis0YTZLNVROemFIL1pJL1dzSDR2TC94Ym04LzNEUUJvZUFPUGgzb0gvWGtsZEhY TytBdVBoNzRmLzY4a3JvYUFGNUZlRS9GalQ1TkU4Y1crczJ3Mmk2VloxWWY4OVVJei9KVCtOZTY1 OTY0VDR0YVAvYWZneDdxTmN6V0Vnbkhyc1BEZjBQNFVBUS9FcnhKRzN3M2htdG4rYlZ4R3E0UDhK RzUvd0REOGFtK0VPai9BTm0rRFJlU0ppYS9rTTNQOXdmS3Y5VCtOZU5yZVgzaU9MUXZENHlWdDNO dkQvMjBmcitBL2xYMHphV3NWalpRV2NJMnhRUnJHZ0hvQmlnQ2VtVGN4TlQ2Ykp6RzMwb0F4YnBj YXdEL0FIbFUvcFhJZkc1Y2VCUCtCTC82RUs3TzRUT28yN2VzWXJqL0FJNHJqd0ovd0lmK2hDZ0Qw SHdsL3dBaXJwSC9BRjV4ZitnaXRMVTJ4WmdlckNzenduL3lLdWtEL3B6aS93RFFSVjdWMnhER1Bm OEFwUUJsaWt6U0E4VWhOQUhnZmk4M0krS040YkwvQUkrL3RrZms1eDkvQzdmMXhXNXJWdjhBRTYr MDJhRzlqZHJZcis5UzM4c0ZsN2o1ZVQ5S3gvRXM4ZHQ4V3ByaVo5a01kL0U3dWY0VkczTmVuM1B4 SThLMjhiU3JxZm5NT1FrVWJGbS9TbUJ6UHdxMWpRNDFrMHFHMWx0dFRrRzUzbGZkNTIzc0R4akg5 MnZUYThKOEVRM0d0ZkVhTy90NFRIRXR3OTFManBHcHp4K3VLOTFwQUZlY2ZHdm53bFpmOWZRcjBh dk9maldmK0tTc3Yrdm9VQWUwMkovME8yLzY1Si82Q0tqMVpzUVJyNnRUckgvajB0dit1U2YrZ2lv TlhQOEFxaG4xTkFHZURTTWZsUDBwdWFSdnVuNkdnRHdyNGEya0YvNHl2TE81akVrRTFyT2pvZTRK RlQ2UGMzSHcwOGVTMkY0N0hUcGlFZHV6Um43ai9VZC94cFBoWC95UHMzL1hDYitZcnZQaU40WC9B T0VpMEl6MnlBMzltQzhXT3JyL0FCSi9VZTlBSEE2c3dmNDFLNnNHQnY0U0NPaEdGNXIyOG12bTd3 eEk4bmpEU0hrWm1iN1ZFTXNlY0FnRDlLK2tDZWFBQ3ZNdmpGL3JQREgvQUYvcC93Q2hHdlRLOHor TVgzL0RQL1grbi9vVkFIdWEvZXFucXpmTEVQY21yU0g1Nm82czM3Mk1mN0pvQXBnOFY1VDhiVC9v MmovNzh2OEFKYTlUelhsUHhyUCtqNlAvQUwwdjhsb1FITStJYlNYdy9MNFg4UldnMitiYVF5RWov bnBHQm44MXhYcFhqenhIRmErQVh2TFdUNXRSaldLQWc5bkdTZndYTlptdDZQOEEyejhIN0lJdTZl MXM0cmlML2dLL01QOEF2bk5lWjJsemZlS1A3QjhOOG1PQ1JvMFAreXpaSi9CYUFMZXFhTi9abnc3 MGE1ZGNUWDExSk9mWFp0QVQ5TW44YTljK0htUCtFQjBuL3JtMy9vYlZ5dnhpaGp0OUUwV0NFYlk0 NVhSRkhZQlFCWFVmRHcvOFVIcFgvWE52L1Eyb0E2Zk5lWi9Fci9rZmZCbi9BRjlwL3dDaEN2U3Mx NXI4U3Y4QWtmUEJuL1gybi9vUW9BOXhIK3NiNjFSMVEvdkloN0UxY1UvdlcrdFoycEgvQUVwUjZM UUJBRFNacHRKK05BSEErT3ZodXZpVzdPcDZkY0piMzdLQklrZytTWEhBT1IwUGJOZVlhYmUrSlBC K3I2aEpaNy9OdFdFTjZTdm14OWVBeDlPT3RkOWZmRSsrMEx4YmVXZXJhVEl0Z0gyeEtCdGtBSDhR N01HNjF5OWw0MjArd3UvRmx6OW1rbS90YklnallBREIzZmUvT25xQjZoNEw4WHcrTHRMZVlSZVRl UUVMUEVEa2M5R1gyUE5kR1RYbTN3ZzBPNjAvVGJ6VXJxTjQxdk5xd3E0d1dWYy9OajN6WHBGSUFy elB4Wi95WFB3Zi92ZjByMHNtdk5QRm4vSmN2QjMrOS9TZ0QyNUQ4eHFqcUxadUVHZWkxY2pQekg2 MW4zNXpkbjJVVUFSQTE1RDhVdGY4V1dzcldZdDJzZElmNVZ1TGR0M25mN3pmdy83djg2OWN6VWM4 TVZ6QThFOFNTeE9NUEhJdTRNUHBRQjgzK0Q5YTEzUTd5NWwwQzArMHpTUkJKRjhneTRYT1J3UGV1 dC80VHY0aW5wbzUvd0RCZTllZzZENE4wN3cxcmQ1cUdtR1NPSzZpQ05iazVWRHV6bFQxeDdWMGhj K3RBSGh2L0NQZU5QSDJyd3phMUZMYld5ZktaSlU4cFkxNzdFN2sxN1ZiVzhWbmFRMnNDN1lZVVdO QjZLQmdWS1dwdWFBSFpyeVh4OE0vRTZNLzlPQS85Q05lcjE1VjQ4R2ZpYW4vQUY0RC93QkNhZ0Nr bytXc0x4RU1XY2xiNEh5OUt3ZkVRLzBLU3JXNG5zY1UxUkdwV3FNMXV5UnVLWTFQN1V4cWtDQ1Nx elZaazZWV2FzMk5EUjZWZWdHSTZvRHJXaEQ5eWlBM3NYNGpsUlR6VEloOGxPTmRDSVc1QzlRdFV6 MUMxUTl4akRUVFMwaHFHQkcxVjVLbmVxOGdxR05FUnAwWXl3K3ROTk9pKzkrTlNNMG9UaHhWd0RJ cWxGL3JCVjRjQ3VpR3hKR3dxQjZzTWVLclBRd0lUU2RxVTBsWnNCakNvbXFWdWxSTjBxUm9oYnJT VXJkVFNWQlJOQi9GViswT0ZiNjFRZy9pcTlhamh2cldzQ1MwUlVFblNwelVFblN0R0lyc2FpTlNO VVpyTmpFcGpVK210VWpJbXB0T2FtMUF3cVJCOHRSMUluM2FhQXZXL3dCeGZyVTJLaHR1RVg2MVBX OGRpU2lvNXFkT0tyaHdEVHhNdmVvVEF1QTRwanVjZm5VSG5pbzNtejBwdVFFTGpLbW91bFQ0M2NV d3hFVm0wTkVWUFUwdmxOU2lKeDYwckRIcWFmVWUxaDFxUmZ1MVFoNmlwa0ZSQWdkYWVKVjlhb1Ja VTFKdXhWUVRvS1UzQzRxMUlWZ3VUOTJxYzQ0U3BqSnZwcGozMUV0U2tVOGM5S2V2V3BUQXhvRUQ1 ck93UFlWVFVxOFZHSW05RFRnQ0dBTldrSWZVaURpbUNwUTZyVklDUlJVeThWV0VxMDRUcFZwaXNX UzJLcTNITW40VUdkYWozYmptazJCVnVCbVEvU29nT2F1UEZ2Qk5SK1EyYXpjUmthOFZPcHBvZ2ZQ U25pSmdPbE8xZ0hxYWVPVFVTOEhCcVpmZXFRaDZpcGw0cUVPcTA0U3A2MWEwQXNDa0xjVkY1Nmpv YVkwL0hGRndJNU9WYk5VV1NyMk0valRHZzlPbFp5VnhsUmVLblE0cGZzN0NuQ0Z4NjBrckFPVTFQ RC9yVS8zaFVIbHNPMVR3Wjh4UFhjS3RDUGN0RS80OUkvOEFkRlZ2RlBOdGJmOEFYUS95cCtrM01V TnBHWlhXTVkvak9NMVg4UTNNTnhEQ3NNZ2tLdVNkblBhc1NqZCtEcEg5amVJUjMvdFQvd0JrV3ZR cThYK0huakhUL0MxL3IybWF5WkxkYm00anVJSlNoS0g1Y0VFZ2NkcTlBSHhCOE1zTWpVNGYrK3Fr WjFGTFhNZjhKLzRhL3dDZ25ELzMxUy84Sjk0Yi93Q2duQi8zMVFCMDFHYTVrZVBQRFovNWljSC9B SDNUaDQ3OE9mOEFRVGcvNzdGQUhTVVZ6ZzhjK0hUL0FNeE9EL3ZzVTRlTnZEeDZhbmIvQVBmd1VB YXNxN2xsSCsycHBkZDQ4T1huL1hFMWh0NHo4UHFaR2JVb01IR01PRFdaNHIrSS9oeUx3N2RSMjk2 Ymk0ZUlva1VTbGlUUUJuL0Evd0Q1RXZVUCt3bkovSmE5SnJ3ejRRZU9OTTBEUmIvVE5ZTXR0Skxk ZmFJbmFOdHJBZ0FqT092RmVsTDhRdkRKSEdweGZuUUIxTmNwcVh3NDhNNnZxVnhxRjVhVFBjenZ2 a1lUc29KK2xTZjhMQThOZjlCT0wvdnFqL2hZSGhyL0FLQ2NQL2ZWQUZBL0Nid2dmK1hPNC84QUFs cWZiL0N6d3JhM1VWeEZiWElraWRYVW00WThnNUZYUjQrOE4vOEFRU2gvNzZwZitFOThOLzhBUVNo Lzc2b0E2WW5KcE8xYzRQSGZoekgvQUNFb1ArKzZVZU9QRHAvNWlVSC9BSDJLQU5XVmR5SDJsSDhx ZzhZY2VENzhmOU1xeTI4YStIVkRsOVNod1dCR0d6V0g0NitJMmdQNFd1N1d3dVd1cnFaTmlSeElU ejcwQVNmQlAva2w5cC8xOHpmK2hWMzllSy9DWHgzcE9oZUV2N0cxWjVMV2VPNGVSR2VOdHJLMk8r UFd2UWg4UXZESi93Q1lsRitkQUhVTU1xVnlSa1l5RGcxeStuZkR6dzFwV3F4Nm5iV2NodTQzTHE4 czdQOEFOL2V3ZS9OTC93QUxBOE5mOUJLTC92cWovaFAvQUEwZitZbkQvd0I5VUFkUUNldGNwZmZE bnczZjZ0SnFqMjg4VjNKTDVwZUNjb0EvOTREdDYxTC9BTUo5NGIvNkNjUC9BSDFTL3dEQ2VlSEQv d0F4T0gvdnVnRHBRTUFkL2MwSHBYTi84SjE0ZFA4QXpFb1ArKzZjUEcvaDQvOEFNU2cvNzdGQUdu S201WXZhVTFsL0VyandCcVAvQUZ5UC9vSnFGdkd2aDVCOCtwUS9mM2NObXVYK0pueEMwUzk4SVhP bmFaTzkxZDNDN1ZXTkNjY2RTYUFPZytGUC9KTDlFLzNIL3dEUXpYWVY1RDhNUGlEbzJtZUNyUFI5 VWtrdHJxMVp4KzhqYkRLV3lNSEZkc1BpSDRaUC9NU2kvT2dEcUtxNmxwZGhyRm0xcHFOcEZjd056 c2tYT0Q2ajBOWVErSUhoby84QU1TaS9PbEhqN3cyZitZbEQvd0I5VUFaVW53aDhKdkx2RVY0aTV6 c1c0T1AxR2E2YlJQRG1qK0hZR2kwcXhqdDkzMzMrODdmVmp6V2VQSFhoMC84QU1TaC83NnB3OGIr SHowMUdIL3Z1Z0RvczBoUEZZQThaYUNmK1lqRC9BTjkwdi9DWGFHZitZaEIvMzJLQU5PUk56V3g5 SFlWejN4ZVhQdzd2Z1A3aC9sVjMvaExOQ1FKdXY0dmxZdHcyZUs1TDRwZU10SzFUd3ZKcG1tTzl6 Y1RIYis3UWtLUGMwQWRkNElHM3dCb0Evd0NuSkszYzE1NTRJOGI2VEI0UTAzVDcyUjdlNnRZdktk WkVJemc4RUhIcFhSanhub1IvNWY0L3pvQTZETlIzRUVWM2F6VzA2QjRaa01icWU2a1lOWWYvQUFt V2hmOEFQL0YrZEwvd21PaGRyK0wvQUw2b0FyYVI4UGZEZWlhbERxRmphU3JjdzVNWmVabUE0eDBO ZFZtdWYvNFRIUS8rZ2hGLzMxUi93bU9oZjlCQ0gvdnFnRG9NMGpkRFdEL3dtT2cvOUJHRC92c1Vm OEpob0pIL0FDRVlQKyt4UUJveUp1dWJSdllqOWE0cjQ2REhnUS83NC84QVFscmRieGo0ZmphRXZx TVB5azV3MmE4KytNdmpUU3RjMEdMUzlJa2t1cFdjTTVqUWxWQVByK0ZBSHNIaFgva1dOSXgwK3hS ZitnaXJtc0hpSWZXdUE4RmZFblFENFkwMkM4dVRiWFZ2YnJGTEhLQ3VHVVk3OXEzTC93QWIrSHJs a01lcVcrQU83aWdDOWlqbXNQOEE0Uy9RQU9kVHQvOEF2c1UwK01mRDQvNWlsdjhBOTlVQVZkVCtI L2g3VnRSbXY3eUNkcmladHpsWjJVWnhqcFZaUGhqNFZScy9ZNW05bXVHeFdrZkdYaDREL2tLUWY5 OTAzL2hOUEQzL0FFRklQKys2QU5UVHRLc05JdHZzMm4ya1Z0RjNFYTR6OVQxTldxd0Q0MjhPai9t S1FmOEFmVkovd20vaDdIL0lUZy83Nm9BNkROZWMvR3YvQUpGR3kvNitoL1N1ay80VG53NG95ZFVn L3dDK3E4MStMWGpEVHRkMHV5MDdTWGU0YU9YekpIVkR0WDBHY1VBZlJkaWY5RnR2K3VLZitnaXEy cm45N0dQOW11UDhQZkZMdzFkYVRhUE5lQzNtV0ZFbGltK1ZsWURCSE5YYjd4eDRjdVpBeWFyYmJj WTVrRkFHa0RTSG1zSStNdkRvL3dDWXRiZjkvQlRUNDA4T0EvOEFJV3R2Ky9nb0FibzNndlJOQTFG cit3aGxTNFpXVXM4cFlZYnJ4WFFBNE5jK2ZHL2hzZjhBTVd0LysreFRUNDQ4Ti84QVFXdHYrKzZB R0w0RThQSnJBMVJMTjB1aE41NEt5c0ZENXo5M3BYUjVybmYrRTY4TmY5QmEyLzc3cEQ0NzhOZjlC ZTIvNzZvQTZPdk0vakVmbThNai9wK1Qvd0JDcnAyOGZlR1Y2NnRiL2cxZVhmRlR4bnArdVhta3g2 U1h1RXM1UE5ra0NrRGRuZ0NnRDZhUS92VCtGWitxSC9TUVA5bXVXMHo0cStGYjIzam5Pb0pDekt1 Nk9VN1dVNDVCQnFTODhkZUc1NXpJdXJXd1hBeG1VVUFiRlluaUR3dHBYaWRZRjFPT1Z4QnVLZVhJ VTY5ZjVWQ2ZHM2hzZjh4aTEvNytDbW54eDRiL0FPZ3hhLzhBZndVQWJOcFp3V09udzJNS243UEZH SWxWem41UU1ZTllla2VCOUEwTFVsMUN3dFhTNVVNcXM4cFlMbnJnVXA4YytHaC96RjdiL3ZzVWg4 ZGVHUi96RjdiL0FMN29BdWE3NGMwenhIRERGcWNMeXBDeFpOc2hYQkl4MnEzcHVuVzJrYWREWVdT RkxlRWJVVXR1STV6MS9Hc2IvaE8vRE9mK1F4YmY5OTBuL0NlZUdmOEFvTDIzL2ZkQUhSMTVyOFNU L3dBVjU0TS82K2svOUNGZEkzai9BTU1JTW5WN2Y4R3pYbHZ4RDhiMk9xZU1ORXZOTDgyNHR0TmRa SGNJUnVJWUVnZmxRQjlPSWYzNy93QzlXYnFEWnZEOUJYT1dYeFQ4SjNhaWRkVGpRUHp0a08xbDlp RFRibngxNGFtbmR4cTlxQWVuN3dVQWJtYWFUWFAvQVBDYitHaC96RjdiL3Y0S2FmSFBobi9vTVcz L0FIMktBTmkrMDZ4MU9IeWIremd1b3gvRExHRy9LdU84TWVBWWRKMTNWYnkvc3JDVzNsbDNXU0Fi L0tYSjdFY2NZclhQanZ3eC93QkJlMi83N3BENDg4TS85QmkyL3dDKzZBT2kvU2tOYzMvd25uaGov b01XMy9mZEgvQ2VlR1ArZ3hiZjk5MEFkSFhtdml6L0FKTGo0Ty8zdjZWMGovRUR3c2d5ZFl0L3di TmVXZUt2SFZoZC9GUFI5YXNoTk5ZYWV5Ym5DRWJ1Zm13S0FQcHFJL3ZHL3dCNnMyOE9ieVQ4S3dM UDRtK0ZKaDVxNnJBRmJrQm4ya2ZVR281dkhIaHQ1bmYrMkxRYmovejFGQUc5bW01ckFQamZ3MFAr WXhhZjkvUlRENDU4TS84QVFZdGYrL2dvQTZITkptdWRQanJ3eC8wR0xYL3Y0S2FmSFhobi9vTVd2 L2Z5Z0RvczBtYTUwK08vREgvUVl0ZisrNlErUFBESC9RWnRmKys2QU9qelhsdmprQS9Fb2Y4QVhn di9BS0UxZFkveEE4S3hqTGF4YjQ5bXpYbkdvZUpMUHhOOFFMMi9zbVkyY1Zza0tTT051NzVqa2dI NjAwQm9xTUxYUCtJeGl5bHJlV1dJOENSUCsraFdMNG1oa1hTcEp5djdyKytHQkI1cWx1SjdIRE5V YkNuR1JmV2t5cEhGYjdra1ZNWTA5dTlSN0dib0tsZ1JQelZkaFZzeE42VTN5R1Bhb2FHVlZYSXE1 Q01KU0xBUjI0cVVMdDQ3VUtOZ0xjYmZMVGllS3FyS0ZPTzFQODhZclZNVmg3RGlvV0ZPTXlZNjB3 eXFlOUs0RER4VEdxUnlEMHFKd2NWSXlOalVMOGlwekd4N1Uwd3Y2R29hR1ZTS2NpL01QclUzMmR2 U3BFZ3huTkpSQW5oTzJTclFhcU9kdk5TQ2YxclJNa3N0MHFGaG1rTTYwd3pJZWxPOXdzTllVeXBO Nm5wVWJjNXFHT3hHMVJOMHFRaGljVTB4UDcxTFF5QWlrcWZ5SHhRSVdxYkFKQjBOWHJkc0EvV3F3 VFlEVGxrS0hIWTFhMEVYOTJhaGVveE9LUXpLUlY4d0NNS2lJcVF5S2FZMkNwSXFkQUdHbU1hZjYx SHRKcVdNak5KbjJxVHltTko1VENwc01abjJxUlB1MGdpYlBTbjdjREZOSUMzQTJJMXFiTlVVbDI4 SHBVZ3VBQldpbFlWa1V1YUtLS3hHS0tlQnpUVkZTQWMxU1FtUFU0cVVHb3U5UEJxa0luVUExSUVC cUtPckNpckM1RThlVGpIRlZuQURFVm9tcUUzK3NhaVFGVm5KYkhhbTdxUnZ2R2s3MWl4anh6VHdL WXZTcGxGTkFPVGlwSXppbUNuTFZJVEoxd2FrVUROUW9hc0pWb1F1d1lxS1NNYlMyT2FzQVUyWVlp YjZWYldnRkdvQzVQV3B6VkppYzFpOUNoNFlrOTZlTWsxQ3RUcFVwc0dQVVZLb3hUVkZQRldoTWtR NHFSZXRRZzFLbldyRVNnVThwZ2NDa1RrVklCeFZwQVZwSXdCdXhWYVZpcThWZW1HSTZ6cm43Z3g2 MUV0QUlqSms5YUFjbW9jMUlsWlhLNkU0NTZVOVJUVkhGU2dZclJFangycVZhaUZQQnFnSmhUZ0JU RnFVQ3FRRFN1ZU1WR01MT25wbXJCRlZwUmhxSkxRU1BvVHdoYVcxenBuNyszaW02RDk0Z2JzUFdy MnMrSE5FaGhodUYwMkpXMzdTSXpzQjQ5cXh2Qm11YVhhNlJFTHJVTGVGbVJXL2VTQWZ3aXRueEQ0 aTBkZE9nQ1g4RXhhWEk4bHcvR1BhdVZtaGx5YUpvVW9HN1N3Q082eWtHb3YrRWMwRC9vSFAvd0NC RFZEL0FNSkhwWS81Ym44UlIvd2ttbFkvMTUvS2tCTC9BTUk1b0gvUU9mOEE4Q0dwZitFYzhQOEEv UU5rL3dEQWhxaC80U1RTL3dEbnVmeW8vd0NFazByL0FKNy9BS1VBVGY4QUNPZUgvd0RvR3lmK0JE VW4vQ09lSC84QW9HeWYrQkxWRi93a21sZjg5LzBvL3dDRWswci9BSjcvQUtVQVRmOEFDTitIL3dE b0hTZitCTFVuL0NOK0g4ZjhnNlgvQU1DVy93QUtpLzRTVFN2K2UvNlVmOEpKcFgvUGVnQ1VlR3ZE NC81aDB2OEE0RXQvaFRsOFBlSGxQL0lNYy9XNWFvUCtFazByL252U2Y4SkpwWC9QZjlLQUxqNkg0 ZWYvQUpoRzMvZG5ZVXovQUlSN3c5LzBDMy84Q21xdC93QUpMcFEvNWVQMG9QaVhTZjhBbjVvQXMv OEFDUGVIZitnVS93RDRGTlNmOEk5NGQvNkJVbi9nVTFWLytFbTBuL241by80U1hTZitmbWdDei93 ajNoMy9BS0Jjbi9nVTFIL0NPK0hjZjhncVQvd0thcTMvQUFrMmsvOEFQelIvd2t1bGY4L05BRmov QUlSM3c3LzBDNWYvQUFLYWovaEhQRHYvQUVESmYvQXB2OEtyL3dEQ1M2VC9BTS9Jby80U1hTZitm bWdDY2VIUERnLzVoa3AvN2VtL3dxUmRBOE9LZitRUTdleHVtcXAvd2t1bGY4L0lvLzRTWFNmK2Zt Z0M4K2llSEpEbit4dHYrNWNzS1ovWUhodi9BS0JEL3dEZ1UxVlArRWwwbi9uNUZIL0NTNlYvejhp Z0MzL1lIaHYvQUtCRC93RGdVMUg5Z2VHLytnUS8vZ1UxVlA4QWhKZEsvd0NmbWovaEp0Si81K2FB TFgvQ1ArRy8rZ1RKL3dDQlRVZjhJLzRiL3dDZ1RKLzRGTlZYL2hKZEsvNStCUi93a3VrLzgvSW9B cy84STk0Yi93Q2dUSi80RnRRZkR2aHovb0ZTL3dEZ1czK0ZWdjhBaEpkSngveDhpai9oSmRKLzUr UlFCWkhoM3czL0FOQXFVLzhBYjIzK0ZQVFF2RGFObit4bWIvZXVtSXFuL3dBSk5wUC9BRDhpai9o SmRKLzUrYUFMMG1pZUc1R3ovWW0zL2N1WEZOL3NEdzMvQU5BZC93RHdLZXFmL0NTYVYvejhpbC80 U1RTdW4ya1VBWFA3QThOLzlBZC8vQXA2VWFCNGIvNkE3ZjhBZ1UxVkI0ajByL241RlNEeERwZi9B RDhpZ0N5UEQvaHovb0VQL3dDQlRVNGVIL0R2YlNYL0FQQXBxcmpYOUxQL0FDOENwVjE3VE1mOGZB b0FsSGg3dzkvMENwUC9BQUthbmp3LzRmOEErZ1pKL3dDQlRWR05jMDMvQUo3aW5qVzlPLzU3MEFQ WHcvNGZIL01Na1A4QTI4dFVzZWk2QkcyZjdJM2V6WERHb1JyZW5mOEFQY1V2OXQ2ZC93QTl4UUJP K2phQXh6L1pHMzZYREFVMyt4TkI3YVUzL2dRMVIvMjNwMy9QY1VmMjNwLy9BRDNGQUVoMFBRUCtn VTMvQUlFdFNIUTlBLzZCVGY4QWdTMU0vdHZUditlNHBQN2IwNy9udUtBSEhRdkQvd0QwQ20vOENX cHAwRHc5L3dCQXAvOEF3S2FqKzJ0Ty93Q2U0cHAxclR2K2U0b0FhZkQzaDMvb0ZQOEErQlRWRzNo enc3LzBDcFAvQUFLYXBEcmVtLzhBUHdLWWRiMDMvbnVLQUdmOEk1NGNIL01KbFAxdW1wMGVoZUdv bXovWWUvOEEzN3B6VFRyZW0vOEFQd0tZZGQwenZjQ2dCWDBEdzB4Si9zUXIvdTNUaW9UNGE4TWsv d0RJSWwvOEMycHgxN1RQK2ZrVXc2L3BmL1B5S0FEL0FJUnZ3ei8wQjVQL0FBTGVsLzRSend4LzBC cFAvQXg2Wi9iK2wvOEFQeUtQN2Ywdi9uNUZBRC8rRWQ4TWY5QVdUL3dNZWovaEhmREgvUUZmL3dB REhwbjl2NlYvejhpay93Q0VnMHIvQUorUlFCSi93ajNoai9vQ04vNEZ2U2Y4STk0WS93Q2dHMy9n WEpURDRnMHIvbjVXbS84QUNRYVYvd0EvSzBBUy93RENQZUYvK2dHMy9nVzlPajBMd3ZIL0FNeSty Zjc5MUlhcm54QnBRLzVlUlRENGgwci9BSitsb0FtZnc3NFdjLzhBSUNZZlM4a3FFK0dQQytjalJw Znd2Ry93cHA4UjZTUCtYcGFZZkVta2Y4L1MwQVAvQU9FWjhMRC9BSmdzbi9nYTlIL0NOZUZCL3dB d1NUL3dOZW9XOFM2UC93QS9hMHcrSnRINmZhMW9Bcy84STM0Vi93Q2dFLzhBNEdTVW4vQ04rRTgv OGdGdi9BeVNxdjhBd2sramovbDdXay80U2pSLytmdGFBTGYvQUFqZmhUL29BdC80R3lVdi9DT2VG RC96QUQvNEd5VlQvd0NFbjBmR2Z0aTRvLzRTalJ4L3krTFFCYi80Unp3cC93QkFBLzhBZ2JKVXNl ZytGSXdSL3dBSTRqWi92M1VoeFdmL0FNSlJvMy9QNHRIL0FBbEdqZjhBUDRsQUZwdkRYaFJ2K1lD dytsN0pVZjhBd2l2aFgvb0RUZjhBZ2EvK0ZRZjhKVG8zL1A0dEE4VWFOL3orTFFCWS93Q0VXOEtm OUFTUS93RGI2OUtQQy9oTWY4d04vd0R3Tmtxdi93QUpSbzMvQUQrcFIvd2xPamY4L2lVQVdmOEFo R1BDZi9RQmMvOEFiN0pTL3dEQ00rRS8rZ0MzL2daSlZYL2hLTkcvNS9Vby93Q0VvMGIvQUovRW9B dGY4SXo0VC82QUxmOEFnWkpTL3dEQ00rRS8rZ0MzL2diSlZUL2hLZEYvNS9VcFI0bzBVbi9qOVNn QzEvd2pQaFByL1lKLzhESktrVHc5NFRSQ3YvQ09JMmU3WFVoTlVmOEFoS05GL3dDZjFLWC9BSVNu UmY4QW45am9Bc3Q0WDhKdC93QXdKaDlMMlNvLytFUzhLLzhBUUhtLzhEWHFML2hLTkUvNS9vNlEr S2RFSC9MOGxBRXc4SitGQi96QlpELzIrdlR2K0VWOEo5UDdEZjhBOERaS2dIaXJSUDhBbitqby93 Q0VwMFQvQUovby93QTZBSi8rRVY4SmY5QUovd0R3TmtwMy9DTGVFLzhBb0JOLzRHeVZYSGluUk1m OGYwZEwvd0FKVm9uL0FEL1IwQVdQK0VXOEovOEFRQlAvQUlHU1VmOEFDSytFL3dEb0FuL3dNa3F1 UEZXaWY4LzBmNTB2L0NWNkovei9BRWRBRmovaEZmQ2YvUUJQL2daSlVnOE4rRkJIcy80UjJNKzV1 cE0venFuL0FNSlZvbi9QL0hUaDRwMFVqaStqb0FsYnduNFRiL21Cc1BwZXlVei9BSVE3d3IvMEI1 Zi9BQU1lbS84QUNVNkovd0EvMGY1MGY4SlRvbi9QOUhRQThlRVBDZy81Z3NoLzdmWHB3OEkrRS84 QW9DUC9BT0JrbFIvOEpUb24vUDhBeC9uUy93RENVNkovei9SL25RQklQQ1hoUC9vQnQvNEdTVWY4 SWw0VC93Q2dHMy9nWkpVZi9DVTZKL3ovQU1mNTB2OEF3bE9pL3dEUC9IK2RBRW4vQUFpWGhQOEE2 QVovOERKS1VlRXZDZjhBMEF6L0FPQmtsUkR4VG9uL0FEL3gvblMvOEpUb24vUC9BQi9uUUJKL3dp WGhUL29CL3dEazVKL2pWaVB3NzRXaWoySjRlaSt2MmlUSi9ITlUvd0RoS2RFLzUvNC96cHc4VWFL UnhmeDBBYk5qNGEwS1BmSkhwVnZ5M3lpUWVadEdCeGxxNDM0a3d3MitqM1NRUlJ4SnRRN1kxMmpx ZlQ4SzY2MThVNkVsdHVmVmJaTXQwWjhIb08xY1I4UnRWc2IzUXJpUzB1VWxWekdpNFBYNXZTbWdQ SWQ5UFNRNUdEVURHbGp6dUZXbVNhSzhrQ3AxVEhTb0kvdkxWd0FWdEZDSXl2SEZOSXhVcHFGODVw c0JoTlJ0MXA1TlJtcFlFVGprMUcyUlV6Q29YcUdNaVpxUVBUWDYwek9LaTR5NUU1WnNWWmpVRTgx UnRzbDYwYmZ2VndFeDRRVU1vQTZWTGp2VWJkSzFhRVF0VEdiaWxjODFHVFdiWURHNlZDM3RVeDZV eGhVc1pDeE5SN3FrZW9UV2JHaVJYSTVxeWh5dFVSVnlMN29xa0RMYXhnY2djMC9aZ2M5YWZIOTBZ cFdGYktPaEpDMkFNVkV4cVNTb0NhbGpHdlVUalBlbm1rUFNvQkVKR0tZVFVqVkUzV29aUVpPYWVq SE9PYWpwMGYzeFFnTEhjVllXUDBxdi9FSzBGQTJqRmF4UkJFVXdPbFJNTVZaYXF6ME5ESTJxSnV0 UFkwdzgxTFl4akNtR3BUVVo2MUlEYVR2UzBWSXg2MUpVYW1uaXFRaHdwNjB3Y1U5UlZDSjR1b3F5 dFZveHpWaFRpdEVJZTMzYXo1ZnZtcnhhcVV4ekkxS2V3eW0zM2pUYVZ2dlVsWVBjWTlhbVVWQ3RU S2FwQVBwUjFwQlRscWtJa1RyVmxPMVYwcWRLMFFpZGV0Unovd0NyZjZVOGNWSE0zN3R2cFZNQ2tl OVVtNjFkNjlLcE1EazFqSW9GcWRLZ1RpcDFxVUJNdFA3MUd0U0NyUWhSMXFWS2pXcFZGV0luVHBV b3FKS2t6aXJRbVJUZmNyUHVPZ3JRbVB5R3M2NUdVR0tpWXlyM3FST3RNeGcxSXZXc1VVV0VxVVZD aHFVSDJyUkVqKzlPSFdtaW5yVm9DVk9sU3JVUzFLS3BBUDdWVmwrOW1yT2VLclRjdHhReEk5UzhN MmxuZGFGWlBOWjI3TTBLNUpqVW5wOUtuMVRTckNGRWVHMWpRazRPMFlGVnZCcjU4UDJuYkNFWStq R3RiVlBtdDAvMzY1bVdYZkRYZ1R3dHEraUplNmxvMGQxY3ZMSXJTTkt5OEsyQU9ENlZxLzhBQ3NQ QkgvUXV4ZjhBZitUL0FCcTM0SFAvQUJUZTMrN2RTai8wRS8xcm84Vkl6a2YrRlgrQ1AraGVpLzcv QUwvNDBuL0NydkJQL1FBai93Qy96LzQxMStLS0FPTy80VmI0S1A4QXpBa0gvYlpxVC9oVmZnci9B S0FpL3dEZjVxN0xGR0tBT04vNFZWNEwvd0NnS3Y4QTM5YWsvd0NGVmVEUCtnTXYvZjFxN09qRkFI R2Y4S3E4R2Y4QVFHSC9BSDlhbngvQ3p3VUhYZG9hTnozbWF1d3hRTUJoOWFBUEVQQXZ3cDB6eEpQ cmQvZmwwdExiVVpiV0NDTmlPRlAvQU5jQ3UxLzRVbjRTL3dDZVUzL2ZkWHZoYzJ5MThWMmhIelE2 L09md2JCRmR3S0FQT2Y4QWhTZmhQL25sTC8zM1NmOEFDa3ZDbi9QS1gvdnF2U0tVVUFlYmY4S1I4 Sy84ODVmKys2VC9BSVVoNFgvdVMvOEFmVmVsMVgxQy90dEswNjR2N3lVUjI4Q0YzWStuK05BSG5S K0IvaG5zc24vZlZKL3dvL3cxbm56QVByWG9XajZ0YWE3cEZ2cWRoSnZ0NTEzRFBWVDNVK2hCcThR R0dLQVBNaDhEUERBNithYVgvaFNYaEplcVRIOGE5T2hPY3h0MUhUNlVTdzBBZVh0OEYvQi85eWYv QUw2cnp6NG4vRFhUUEN1bFJhanBra3BSbjJzci93Q2Zldm9lU1BGZVpmSEJjZUJVL3dDdXcvbUtB SzNoNzRJNkMyaVdVK3BQTExjendKSytHd0FXR2NmcldyL3dwUHdsL3dBOHB2OEF2cXUrc1A4QWtF MkdQK2ZXTC8wRVZXMXJYTk84TzZlYjdWTGtRd2c3VjdzN2VpanVhQU9LL3dDRkplRS8rZWN2L2ZW Si93QUtSOEtuK0NYL0FMNnFhMStNbmhpZTZFTWlYMXVoT1BPa2lHMGZYQkpGZWdRelJYTUVjOEVp eXd5S0dSME9Rd1BRaWl3SG5IL0NrUEMzOXlYL0FMNnBQK0ZIK0dPeXlmOEFmVmVtVW9vQTh4LzRV ZjRhL3V5Zm5UaytCdmhoaG45NVhwdElHOHQ5L3dERDBOQUhtMy9Dai9DaTlVbFA0MGY4S1c4SUwv eXptL092VW1qRExrVlZraUlvQThyMUQ0SytHR3M1amFtZU9WVUpYbjBGY044Ti9oelorSWRTMWM2 akkvMmZUNUJFRkIrOHhKL3dyNkVrVEVVdi9YTnY1VjUzOEpWQ3Q0cjk3OWY2MEFYVStFM2hWUnhG TC8zMVVxL0Nyd3dPa1VuNTEyUUdLZUJRQnhvK0Z2aHdEaU9UODZjUGhkNGU3TEorZGRtQlNpZ0Rp eDhML0Q0UEljVS8vaFdYaDcvcHBYWW5wVGNVQWNnUGhsNGU5SktYL2hXZmg3MGtycjZLQU9RLzRW bjRlOUhwZitGYWVIdlNTdXVvb0E1SC9oV25oLzhBMjZRL0RQdytmNzlkZlJRQng1K0dQaC8vQUth VTAvQy93OGYrZWxkbCtGRkFIR0g0VytIVC9mcHArRlhoczlwSzdXakZBSER0OEtmRFI3U1V3L0Nm d3o2U1YzQkZOSW9BNGIvaFUvaG4vcHBSL3dBS244TS85Tks3Y3JTWW9BNG4vaFUvaGdkcEtYL2hW UGhqMGtydE50R1ByUUJ4Zi9DcVBESHBKUi93cWp3eDZTVjJtS0tBT0svNFZQNFk5SkthZmhMNFdQ OEFESlhiWW94UUJ3emZDTHdxZTBsSC9DbWZDckRQN3pGZHZpcmFqQ0xRQjUyZmd0NFQ3ckxUVDhG dkNQZEp2enIwVWltR2dEejMvaFRIZy84QTU1ei9BSjB4L2d2NFBaU29XNFUrb2F2UWlLYVJRQjgy bjRidy93REMyWXZDaXp2OWxrK2ZmM0M0Si9wWHFFZndXOEpJb1YxblpoMzMxVUEvNHlTdEQvMDV2 LzZDMWVvaGZtb0E4OS80VXQ0U1BTS2IvdnVtbjRLZUZ1MFV2L2ZkZWtvbFBaZHEwQWVaZjhLUzhM bnFKRi9ITklQZ240VkhWcGZ5cjBjbkp6VERRQjUzL3dBS1Y4SitzMUwvQU1LWDhJanRQWG9ScHBv QTREL2hUUGc4Znd6L0FKMGY4S2E4Ry8zTGo4NjcwajYwMDBBY0gvd3B2d2IvQU04N2ovdnF1SCtK Znd3MGp3NzRlT3I2UkxNQWpxcnh2NzE3a2E0bjR1ZjhrMnZmK3VpZnpGQUhQK0VQZzVvVjk0WjAv VWRUZVY1cnVGWnNLM1ROYi84QXdwZndnZWtVMy9mVmRaNFdYL2lpdEEvNjhJdjVWc29sQUhuSitD bmhUK0dPYi92cW0vOEFDa3ZEQjZKS1ArQlY2WUU0cGpIbmlnRHpiL2hTUGhiKy9KK1ZML3dwTHdv T3BscjBidFZMVk5SdHRIMHk0djcxOWx2QWhkajNQc1BjOUtBT0cvNFVyNFNIL1BhbC93Q0ZMK0Qv QU83T2Z4cnR0TTFLMTFqUzdmVWJLVGZienB1VTl4N0gzRldhQU9BLzRVeDRPSDhGeCtkSC9DbXZC djhBenp1UHpydlRUY1VBY0czd2I4R2xTUEx1QWZVTlhHVzN3MjBqU3ZpM1phTmN4bTkwdTZ0cEpW amtZZzVDazl2d3IyNGl1R3ZTSnZqcHBzWS81WWFaS3gvSEFvQTBqOEpQQkxkTkdVZjl0Vy94cFA4 QWhVUGd2L29FRC92NjFkd280cDFBSERENFErQy8rZ1FQKy9yVW8rRVhnci9vRHIvMzlhdTVBOTZL QU9IL0FPRlJlQ2YrZ012L0FIOWFuRDRSK0NmK2dJaC83YXQvalhiZ1V1S0FPSUh3ajhFZjlBT1Av djYvK05ML0FNS2s4RC85QUdQL0FML1AvalhiVVVBY1VQaEw0SC82QUVaLzdiU2Y0MWgrSS9CK2cr R1pMYit4dFBTMDg5VzgwSzdOdTJrWTZuM05lcFlyaC9INUJ1N0ZjOUltUDYvL0FGcVlNNGsyOFI2 eG9mOEFnSXJqL0hFY1VXbGpiR2lzMHFqSVVaNkd1Mnh4WEVlUFQvb0VLNS81Ymc0LzRDMU5DWjU4 M1duUW41eFNOaWhGdzFPd2pTakh6TFZ4ZWxWSXVHV3JZTmJ4MkVJMVFQM3FjKzlSTUtZRUJwdFBZ VXlvQWExUXYwcVZqVVRtb1l5dTlRbnJVelZHUnpVRFJZdGZ2Vm9XL1Uxblc0eEorRmFWdWZsclNB bVdEMHFKNmVXelViVnFJZ2ZyVVJxWmhVUkZac0JwcGhweHBqR29ZeUdRVkFhblkxQzNXb1kwSUt1 eGZkRlVnTWlya1ErUVZVUm1qRjBwemRLYWgrVVVySGl0a1FRU1ZYYXJEMUF3cVdCR2FROUtVOFUw bmlvZTR5TnFpYXBXTlJOVU1ZbE9qKytLYlRvL3ZpaERMR1BtcStnK1dxSVBOWGxiaXRZRWlOVlo2 c3QzcXU0cHNDQnFiVDJwbFpqRUlxTTFJeHFNbm1rQTM4Nk1WYkNLZTFQRVNlbEhLQlNIQjZVNEht cnZrRHFCVWJRY1UrV3dEQjFxVURGUWs3UlVabFk5NkxnWGxJSGVwTitLekJLOU8zdC9lcXVZVmkr MHRWMk81cWdCSlBVMUl2UVV1YTR5TjQ4VkhzT2F2TGdpbkNOVDJwY29paW81cDR5RFY0UXA2VXBn VURwVktEQXFMbk5TcFNOSDVaNHBqU2VXS1d3RnBjVTlXck44NCt0S0pYendhZk1GalUzOFZGSkp4 dDlhcEIyOWFlcHl3enpUNWdIOXFnYVBIYXJBNjFLQUc2aWsxY0NnRTlxZXVhdkxHcDdVL3dBaGZT bW9BVVJrR3BVNlZZTUtqdFVUSnNiRkZyQU9RZkxVb3dLcVBMdE8zRlJlYytldEhOWUxHbUdBcHhm anJXV0pISjYwOFNONjFYTUt4YmtmNWNWQkltNWFhcE83bXBWR0tXNEZRcDdVQlNPMWFHMVQycHl4 SWUxSElNb3FDS2tVNDdWYzhsZlNtTkNEMEhTbW9pSXhVb0ZRazdCVVRURTk2TmdMeTAvT0t6Qk8v clRoSy9yVDVobWdYcUZtM05VRzVqVDFCeFJlNGowdndUTG5SSWx6eXJNUC9Iai9BSTEwRjk4MXYv d0lWeVBnbWIvUVhUZDkyVThlbkFyclovbWhhc1h1VWpxL0FqWjBhNlQrN2RFL21pLzRWMUZjajRE ZkNhakQ3eHlEL3dBZUgrRmRmaXBHSlJTNG9wQUppaWxvL0NnQk1lOUxpakh0UlFBWXBNVTdGSmln RGp2QmpHdytKZmpQU24rVVhRaDFDSWVvSXd4L00xM2xlZCtKNVI0YitJWGh6eE9mbHRKaTJsM3Jl aXZ5aFAwT2Z5cjBWbDJzUlFBbExTVVVBT0hOZVNlTWRRdWZIL2k2RHdmbzhoRmhiUHZ2WjE1R1I5 NC9SZWc5V05kRDhUdkdYL0NOYUtMS3pmR3FYcWxZOGRZMDZGLzZELzYxTDhMdEkwclNOQlpiUyt0 YnpVcHRzbDY4TW9rS0UvZFRqc09mcWMwQWMzNGR1Wi9obDQzazhPNmpLemFKcURiN1dkK2lrOEsz L3NyZmdhOWY2R3VPK0kyamFYcm5oczIxL2VXMW5kcVMxbk5QSUVIbUFmZHlleEhINVZuL0FBcjhZ LzI1cFowZS9renFkaXUzY1d6NTBRNERlNVhvZndvQTc5OGpEcjk1ZWFzcktycXA3TUtyOXFoTEdO SkIvZCtZZlR2UUJabWl5SzhwK09vMitCMEgvVFlmekZlcTI4d21qOVRYbDN4N0dQQmFmOWRSL3dD aENnRDBMVHYrUVBZZjllc1gvb0lyeGI0cTNFMnMvRUt6MFFPUkRFSW9sQS92U0hsdnlJcjJqVFAr UU5wLy9YckYvd0NnaXZGZmlaRytqL0UrMDFXUlQ1TW5rWENuMTJFQmgrbjYwQWR2NDY4RmFMSDRD dWxzdFBnZ21zSXZNaGxSQUgrWHFDM1U1R2V0VlBncnFjdDE0WnU3Q1J5d3M1eDVlZXl1TTQvTUg4 NjNmSCtzMlVIdysxQzVTZU4wdklQTHR5R3o1aGYwL0RtdWIrQ0ZqSkZvT3BYckRDWEZ3cUlmWFl2 UDZ0VEE5U29GSEZGSUJ3cENNakJvb05BRWx0SmhTamRWL2xVeEFkZUtwSDVKVmJzZmxOTGIzQkVw alk4ZzRvQUxoTnNFdis0MzhxODMrRkl3L2lrZjlQNi8xcjA2N0graVRIL3BtMzhxOHorRll4SjRu LzYvaC9XZ0QwQUNuQVVncDJLQUZwUlJTaWdBYnBUYWVlbE1vQUtLS1hGQUNZb3hTMFVBR0tLclhP bzJOazRTN3ZiZTNkaHVDeXlxaEk5ZWFuUmtrUlhSZ3lNTXF3T1FSN1VBT294UlJRQW1LS1dpZ0Jw cHBGUHB0QURDS1Fpbm1tMEFNeFJpbVRUdzIwVFMzRXNjTWE5WGtZS0IrSnB0dmVXdDRwYTB1WWJo Vk9HTVVnY0Q4cUFKYUtYRkppZ0F4NzBoRkxSM29BYjNxMkI4b0ZWbEh6Z1ZiTkFEQ0tqTlNHbUdn Q05xWmlwR3Bob0E4eVRuOXBLMC93Q3ZOLzhBMEZxOVlXUG12S0kvK1RrclQvcnpmLzBGcTlpamo1 b0Fha1dCVlM1Yk1td2RxMDVNUlFzL29Ld3BabzRZM25ua1dPTkFXZDNPQW85NkFKRHhUVFhLZjhM TThJbTY4aisxaG5PTjVpYlovd0I5WXEvZitNTkIwMjR0SUxxL1ZHdTFEMjdLak1raWs0QkRBWTYw QWJacHBxdHFlcFdtajZmTmYzOHZsVzBJeTc0empuSFFmV3NlWHh2b0VPaFI2ekpjeWl3bGxNU1Nl UTJXWWRlTVo3SG1nRGZOTnJsOVErSXZoalRab29acjUzZVJGZkVVUmJhR0dSdTlPdlNwZFY4ZWVI Tkl0N2FhYSs4MFhLQ1NKWUYzc3kvM3NkdnhvQTZFMXhQeGQvNUp0ZWY5ZEYvblhUNlByZW5hL1lD OTAyZnpZYzdUa2JTcmVoSGF1WStMMy9KTjd6L3JvdjhBT2dEc1BDYTd2Qk9nZjllRVg4cTNZNHF5 UEJxYnZCR2cvd0RYakYvNkRYU1J4OFVBVTdqRWFlNXFwVXQzSnZ1Q0I5MWVLaDlhQUN2SnZGTjVQ OFFmR01QaGJUSlNOTXMzMzNrNmRDUnd4L0RvUGV1ZytKbmkvd0Q0UjdSL3NObEpqVTd4U3FFSG1L UG9XL29QL3JWSjhOOUkwM1J0QU1WcGVXMTNmU2JYdkpJWlJKdFk5RXlPdy9VNW9BNW53MWR6L0R2 eGpMNGExT1VuU3J4dDlyTzNSU2VoOXMvZFB2WHF4NHJqL2lQcFdsYXY0ZkVOL2VXMW5lSnVlemxu a0NaWWRWNTdIL0NxZnd6OFgvMjdwUjB5OWt6cVZtdU1rLzYyUG9HOXlPaG9BN3MwMmxwS0FCVjNP cStwcmdQRGhHcmZHZnhEcUs1TWRsYXBhZys3TnUvcFhhYXBxRU9rYVJlYWpjTUZqdDRtY2srdUs1 ajRSYWROSDRabTFpNlVpNTFlNWU3YlBVS2VFL1RuOGFBUFFWRk9GQUhGTGlnQXh4UzBVdEFDVXRG THpRQWxMUmlsb0FTdUQ4ZEhPcVFML2RoSC9vVFYzdGVkK01YRDY5SVA3cXF2L2pvL3hwb0RteU9P MWNCNDljRVdzZnF6TitXUDhhOUNrNFExNTc0dVpaTHlKQ003Vkp6OVQvOEFXcTRxN0V6aWZMT2Vs U3h4WllWZUtMNkNta0FBNHJUa0pJMU8xaFZoWHpWYnNhaTNNdlEwWHNCZkxERk1KRlVXbFlEZzB6 ejNIZWpuQXZzS2lPTTFXRTdkYzFPRzNya1VyM0dST2VhaklKN1ZkU0hQekhrMC93QWdZbzViZ1pi Sms5S1FKZzlLMURFZzdVd292cFM1QXVWWW85cHppckVUN2VLSDZWQy90VDJBdWh4VFMxVVM3RHZU RE0vclJ6Z1h6aW8ySEZVdlBiUFdwRm1QU2x6WEN3ODlLaWJtcGd1NGdDcGxnQTdVY3R3TTlsTk0y WnJVOGhSMnBwaVgwcGNnR2NzWnF3b0tyVStGWHRVVGUxRnJCY21qbHlLazh3WTYxbm5JWW5KcHBk c2RhZk1GalFZNXFNNE5Vdk5iSFdrRXB6MXFlWUxGaHhVYmNFVXF5Ynh6VDBqOHpuMG9zQlhQTlJr R3RJUXFlMUlZVkhhaHdZMFp1MnBJMDV6VnN4cU8xTllBTDBwY29FZmVyQ3lBOTZybnBVZVdYcFJl d0Y4eVpxTmlEVkl1dzcwbm1NZTlITUZpMndGUk1NR29oSTNjMC9kdTVwWEFhM3BURG1yS3haRzd0 VWdoWEhUODZmS0F4VFU4Zk5WMHF4RlZJUk1CbW81aHNqTFl6aXBnS2JOd3RXOWdNeG15dlNvcW5m N2xRVmd5Z3B5aW1kNmtXZ0NRQ25nVWdwMVVKamxPS2xRMUNPdFRKVklSWVFacCszaW14OUtsQXJS Q0tGMCsxZ05oUHZWU1Y4a2NZcS9kZEZxaFAwRlp6S1JEVDBwbFBUcFdmVVpNbzVxUlZwaTFLS3Nr T2hxUlR6MXFQdlQxNjB4RTZWT29xdW5XckNWb2dZcFhKcWhQTGlUSGx0V2ovQ2FwM0grdHo3VVNX Z0dmSytYKzZSVVlKelV0d1AzaCtsUkwxckJsRXlWTW9xQk90V0Zxa0llQlR4VFJUaFdnaVJUVXkx QXZXcDFxa0JLQnhVY3plVkdYMmx2WVZJS0c2VlFyR1k4L1VlVzQrdFZTMWFFblExbk53eHJubHVV aHluSnFkQnpVQ1ZZU2hBeVpWcDRGTlduOTYwUWpwL0JzK3k1bmpKeGtLMzg2NzdPNkw4Szh2OFBU K1RxeWM0M2dyL244cTlLdDMzUkNzNTdsSFJlQ1pQTDFxV0luaVczWWZpcERmNDEzZjRHdk4vRDh3 dGRmc3BTY0w1dXh2bzN5L3dCYTlLMjQ0OUtoakc0b3hTNFByUzRwQU54UzRwY1VVQUppakZMUmln Qk1VWXBjVVVBWS9pYlFvUEV2aDI4MG1maFo0OEkrUHVPT1ZiOENLelBoejRsbTFmU3BkRzFiTWV2 YVFmczkxRzNWMUhDdVBYSS96elhWWXJoZkd2aG5VRjFPRHhiNFl3bXVXYTRsaEhTN2k3b2ZmSCtl QlFCNkhtaXViOEllTXRPOFhhYjUxdWZKdTR2bHViU1E0ZUYrNEk5UGV1ai9BRG9BNS9WUEEzaHpX OVFlKzFIVC90RnpKZ001bWNjRG9PRFhJL0N1MWhzZkUzaTYxdDAyUXczQ3h4cG43cWhwQUJYcHdQ TmVVandoNDgwcnhCcTk5b041WVFSWDl3MGgzT0NXWGNTdlZlT3RBRnY0eFFwY3I0YmhrR1Vrdnlq RDFCMml1bTAzNGUrR3RHMU9MVU5QczVZTG1Gc282M0QvQUpFWjVGY1JmK0V2aUZybDVwN2F6YzZm UERhWEN5cUVrVlNPUm5vdlBBcjEwdGxqUUE3TlJTajk0djhBdFpXblpxSzRPSTgraHpRQlUwMmNw TTBaUFExd2Z4N09mQnlmNzYvK2hDdXpIN3ZWNUFPaGJQNTF4WHgzL3dDUk1qLzMxLzhBUWhRQjZI cGYvSUYwL3dENjlZdi9BRUVWbitKL0N1bStMTk5GcGZxNnNoM1JUeDREeHQ3ZjFGWDlLLzVBdW4v OWVzWC9BS0NLdGlnRHltMytDTVgyaEJkYTlQTGFLZjhBVnBEdGJIcGtrZ2ZsWHArbmFmYTZUcDhG aFpSQ0cyaFhhaUQrZjFxeG1pZ0IyYXcvR0hpTmZDdmh1NDFUeVJOS3BXT0tNbkFaMjZaOXU5YlJP Rko5Qm12SlBISGlOUEZmd3BPb3BiRzNDNmtzWGxsdDMzZDNPZnhvQXpkQStNT3Mvd0J0UXByQ1cw MWpOSUVjUlJiR2pCUDNnZStQZXZjT00xOGh3ZjhBSHpEL0FOZEYvblgwOUY0bGlmeG5KNGErek9K WTdOYm56OXcyOXZseCtQV2dEYms1UTFRbmxNZDhyZE42ZzFlWThWbDZod3NMK2haYUFOaWFUZHAw eC82Wm4rVmVjL0MzL1crSi93RHI5SDlhN3hIM2FYTWY5ZzF3Znd1LzF2aWIvcjlIOWFBUFFCMXA0 cG9wdzYwQUtLVWVsSUtXZ0JhWlQ2WVJ6UUF1S0tCUlFBVVVVVUFlSC9ISlFmRU9tNS81ODIvOURO ZXZlR3gveFMrbGY5ZWNQL29Bcmd2aWg0SzF6eFJyRmxjYVZieFN4Ulc1amN2TXFmTnVKNkdzQ0x3 bjhVNElVaGh2NWtqalVLaUxxQzRVRG9PdEFIdDJLWEZlSi84QUNNZkZiL29JM0gvZ3dYL0dqL2hH UGl2L0FOQkc0LzhBQmd2K05BSHRtS1RGZUtmOEl4OFZ2K2dqY2Y4QWd3WC9BQm8vNFJqNHIvOEFR UnVQL0JnditOQUh0ZUtRaXZGZitFWStLLzhBMEViai93QUdLLzQwaDhNL0ZZZjh4RzQvOEdDLzQw QWUwa1UzRmVNZjhJejhWZjhBb0kzSC9nd1gvR20vOEkxOFZQOEFvSTNIL2dlditOQUhjL0ZCYy9E elUvVDkzLzZHdGM5OEV4alF0VngvejlML0FPZ1ZnWG5nMzRsYWhhdmJYbHpKUGJ2OTZPUytVcTM2 MTJ2d3k4TmFuNFowdS90OVZoamlrbW5WMENTQjhqYmp0UUIzRkZGSlFBVUdpa29BZkVNeWlySnFD QWRUVXhOQURUVERUelREUUF3MDAwNDAwMEFlWlJIL0FJeVR0UDhBcjBrLzlCYXZhWTFyeFdML0FK T1R0UDhBcjFmL0FOQmF2Ykk2QUsycFBzdGd2OTQ0cmgvSFdrWHV1K0Q3MncwOC93Q2t2dFlJVGp6 QXJaSy9qWFlhcy83eU5QUUUxekhpYXcxWFV0RGt0dEYxQVdONFdWaEtSMUEvaHovRDlhQVBJOU0x N1Q5RTA1TkM4VmVEMDJLQ3JYQWkyVEgvQUdqbnFmY05YVC9FVFNiRFZ2aDlZYXJvb0gyZXhWV2hL REI4bHNLUitCeCt0UWFybzN4RjhTYWVOSDFXUFRSYmIxTFhPVnljZCtPZnlBcnVyRFI3SFNQQ3NP aDNFeXRhcmJ0Qzd5RUx2eUR1UDZrMEFlY2VNdkVjbXY4QWdmdzdZV3piN3ZVV1h6Vkg5NVBreC8z MS9LcjN4TjAyTFJ2aDNwR213L2N0NTBUNm5ZMjQvbm11ZStGK2pDLzhZTmNsekxaNlh1ZU5qMExF a0pqOVdyMFA0aCtITC94Um9jRm5weGhFc2R3SkNaWDJqRzBqMDk2QU9mdnZER2tXbndoZWRMS0py cjdHbHliaGwvZWJ6dE9kM1h2akZKOE52RG1sWGZndWU4dkxPSzVtdUhrUm1sVU1WVmVBRjlQWGl1 cjFEUTd1NitIemFIR1loZUd5U0RKYjVOd0M1NS9DbStDOUJ2UEQvaFZkTXZHaWE0RHlObUp0eS9O MDdVQWNmOEdDUkZyS1pPMFBFY2Y5OVZ1ZkY3L2ttOTUvMTBYK2RIdys4SmFoNFZHby9iNUxkdnRM SVU4bHkzVGQxeUI2MG54ZC93Q1NiM24vQUYwWCtkQUhlK0NCbndQb1gvWGpGLzZEWFFzUkhFVzlC bXVmOEQ0LzRRZlF2K3ZHTC8wRVZzNmcreXlmMVBGQUdRRGs1UFU4MHVhWUQ2VXVhQU9kMVB3SjRl MXJVNUwvQUZDMGxudVpNQm1NN2o2QURQU3VXK0ZGdkZhYWw0bnQ0VjJ4Ulhhb2c5RkJjQVY2VURn ZzE1VGJlRlBIbWo2cHFrK2pYTmpCRmUzRFNuYzRKSTNFcjFYanJRQmQrSzBFZDFxSGhpM21YZEZK ZUZIWDFVbE0xMUZoNEk4TzZScUVkN1lhZjVOekVUc2tFcm5IYjFyaTUvQ2ZqclY5VjAyNDFxOHNa NGJPNFdVQlhDa0RjQ2VpODlLOVNKK1kwQUxTQVpPQlNBWk9BT2E0bnhyNDJiVEpVOFArSGwrMitJ YnI1RVNQa1E1L2lQcFFCbWVPTHVUeGo0bXMvQXVseUV3cXdtMU9aRHdpRCtINi93RDFxOVV0TGFP MXRvcmVGQWtVYUJFVmVpZ2NDdVc4QWVDMDhKNlc3WEVuMmpWYnR2TnZMazhsbS91ajJGZGlCaWdB Rk94UmlseFFBbEdLV2x4UUFtT0tNVXRMUUFsTFJTNG9BUURKeFhtR3Z5ZmFOYXVIQjRMdC9QOEF3 cjB5ZVR5TGVTWS84czBMZmtLOHFtRys4YytoeCtWTkFVcmtiWXptdk12RU12bWF0SU9NSUFvL24v V3ZTOVRiWkMzMHJ5VzVrTXR4Skl3d1dZc2NWclRXcExLekdvaWFrYW9qVmlFN1ZHd3FUdFRHNlVB UU9NQ3E3R3JEOUtyTldUS0JYcXdrK0YrNFRqMHFwM0ZhRVAzT21LSXNDN0V2eUNwQ09LYkR5dnRU elc2SUlHNHFOalVqMUMxU3hqRDBwakNuOXFhYWtDSmhWZCtEVmg2cnlDb1kwUjdxY3JZWUhyVERU b3Z2ZmpVTGNvdVJTWmtVYkQrRmFJVEZVNGppU3J5OUs2STdFTWpZVkM1NXFkcXJ5ZGFHQkV4cG5X bGJwU2RxZ0NNamlvMkZTdFVUVkJTSVc0TklLRzZtZ1ZER1NSTmpOWHJUNTFQR01HcWNIVnF2V3ZH ZnJXc05STmsrM0ZST01DckI3MUJKMHJSa2xkalViR250VVpySmpFNXBqQ245cWExSVpDMUpTdFNW QXdwNm41ZWxNcVJQdVUwQmR0eHVpRlM0Rk10dnVyOWFsUFd0NGtsQmV0V1lxaFVWTXB4VUlHV0Ix cHNuS242VTBOZ1V4MzRQMHF1Z2lrLzNLaHFaL3Vtb1QxckZsSVR2VWkxSDNwNDYwV0dUQTA0ZEtp RlNpcUVPRlRKVEVHYWtVWU5VaEU2ZEtsN1ZDcHhUaStCeFdseEVOempDL1UxUW40MjFkbk9RS3FU RE9LemtORmVucFRjVTVlS3pHVHBVb3FBR3BGUE5VSWs3MDVlRFRPYW1VVlFoNlZZU29GSGFwVk9L MFZnSmFxVC9BT3MvQ3B5M3BWZVk1ZjhBQ2lRRkM0LzFoK2xSS09UVmlaY3luZzlLaUNuTllQY29j bldyQzFBb3FSVFZSRXljZHFjT3RScWFsVVpOV0ljdldwMHFKUlVxOFZhQWxGRGRLYnV4VFMxWGNS VmwrNjFaN2NtdEYrVmFxYko3VmhJdERFcWVPb2xCN1ZLdkZKQXl3dE9xRUhGVEtjaXJSSk5iU0dH NGprSEcxZ2VLOU8wNlhmQXBIY1Y1ZUIzcnVmRE4zNXRraTU1VDVUL244cW1hNmpSMU1aSUlaVHlE eFhxOEV3dXJhRzVYcExHci9tT2YxelhrMFBKSXIwTHdwYytmbzNrazVlQjhmOEJia2ZydXJKbEcx aWpGT3hSaWtBM0ZINFU3RkppZ0JNVVlwMktLQUV4NzBZb3hTMEFOb0lwMktNVUFjUDRvOEJEVU5S R3U2QmRuU3Rmai93Q1cwWS9kei83TWk5L3IrZWFxNlg4UnB0THUwMG54dFl0cFY4ZmxXNXhtM245 MWJ0WG9PMnFtb2FiWjZwYVBhMzFyRGN3UDk2T1ZRd1A1MEFXYmU1aHVvbGxnbFdTTmhsV1ZzZzFM bXZPcGZoeFBwRXJYSGcvWExuU21KejlrbS9mVzdmOEFBVHl2NjBMNHA4WmFCOHV2ZUdUZXdyMXU5 SmZ6UjlTaCtZVUFlaTU5YVROY2RwbnhPOEs2aS9sSFVVdHAraGl1Z1ltQjlQbXJxWUwyMXVVRHd6 cEloNkZXQkZBRmpOUno4d3Q5S2ZrSG9SVFpPVWI2VUFaN0puVkltL3ZJdGNQOGVSandaSC92ci82 RUs5QWlqM1hGcy84QXNZL1d1QitQZVA4QWhERUgvVFZmL1FoUUI2QnBmR2phZi8xNnhmOEFvSXEx VmJUZU5IMC8vcjFpL3dEUVJWbWdCYVB4cEtNMEFPNyt0ZVBYVnBaK0ZwOVY4TCtJMGxUdzVxa3h1 TEsralhQa3Y3L1RqOHZldlhxNTN4WEpya2xzTFRTZENzdFNqa1hNaHZaVkVZOXRoNjBBZVgyZmhq d2JvTjVIcXVwZUxMYlVMV0ZoSkhhMnlaZVVqb0dBSnJ0L0ExcGZhdHJ1cGVNdFN0MnRqZktJYk9C K3F3anYrZy9XdVEwTHdkNHUwTFZwdFEvNFJqU2JzeU51RWM4aWxZK2MvSnp4L3dEV3IyQ3dudWJp eGlsdkxUN0pjTXZ6d2J3K3cvN3c2MEFXU2FvWDR6YW4vWmtIOHF1R3F0eXU2M21IcHROQUUwUC9B Q0M1ai9zR3VIK0Z2TXZpYi9yOUg5YTd1Rk1hUk4vMXpQOEFLdUQrRmYzL0FCUC9BTmZvb0E5QkZP cG9OTG1nQndwYzB6ZFNiaFFCSmtVSG1vdDFKNW1LQUpxTTFDSmNVNFNvZStLQUpCUlNaSHJTMEFG RkdhS0FDaWlpZ0Fvb29vQU0waE5GQm9BYlRhY2FaUUFFMDAwcHBLQUNrb3pTRTBBRkFHVGlqR2Fl cEM5S0FKVkcxUUtVbW95OU5MVUFQSnBwTk4zVW02Z0J4cHBvelNab0E4eWovd0NUazdQL0FLOVgv d0RRV3IyeVBwWGlTOGZ0S1dmL0FGNnYvd0NndFh0Y1pvQXlOVGZkZXNQUUFWVkJ4VWw2MmJ5VS93 QzFVR2FBSGsxZ2VLUENWaDR0Z2dqdjViaVB5R1prTUxBY24xeURXNFRTWm9BeS9EL2g3VHZET25H eTA1R0NzMitTU1JzdTdlcHJWemltNXBNMEFPelNacHRGQUMxeFh4Yy81SnZlZjlkRi9uWGFWeFh4 Yy81SnZlLzlkRS9uUWdPOThFSC9BSW9mUWY4QXJ4aS85QnJVMVJ2M0NMNnRXUDRLUC9GRTZELzE0 UmYrZzFwNm9lSWg5VFFCUUJvelRSOWFPUFdnQlNhVE5WTHpVN0N3akwzbDVCQWc2bVNRTFhLWHZ4 UjhPUXpmWjdCN2pWYm4rR0d4aU1oUDQ5S0FPMXpWVFV0VHNOSHRXdWRTdklyV0ZmNHBIeCtWY2NM L0FPSWZpTTdkTzBtMzBDMGIvbDR2bTN5NDlRZzZmalZ2VFBoUllOZExmZUpMNjYxNitIT2Jsc1JL ZlpLQU1pNThXNi80M2tmVHZCRm85dlpFN0pkWHVWMnFCMzJWMTNnendGcDNoR0Y1RUxYZXBUY3oz czNMdWY2Q3VvdDdXRzJoV0tDSkk0MUdGUkZ3b0hzS3NBVUFOQzA2bEFwY2U5QUNZcGNVWXBjVUFK UzRveFM0b0FURkxSaWxvQVNseFM0b29BeXZFTTR0OUlrNXdYT1B5NVA4cTg2aFVrczU2MTFuaks3 KzViS2Vnd2ZxZVQrbTJ1YldQeTdjRTlUelRRamx2RmR4NU9tem5HU1YyL254WG1UZEs3RHh4ZWd5 UjJvT1NmbllmeS9yWEhFMTBVMW9TeUpxaU5UdFViREZPd2hocU5xZDBxSmoycWJqSTM2VldhckRj MUV5NXJKalJFS3ZRSDkyYXFoS3VSTHRXcWlnWmVqNFhpbkhIYW9ZMitXcE04VnNoV0kzcUZoVTdW R1JVc0NBMGhwN0FZcUpzMURBWStLZ2VwV05STU0xREtSQ2FkR2NNUHJSdDVxUkUrY2ZXa2tNdXcv NndWZUZVSXp0a0ZXdDliUklZNXU5VjNxWmpVVEROTmdRTlRPMVNzS2pOWnNCalZDL1dwV09LaVkr OVN5a1JFVWdwU00wQmFnWkxCMWFyOXJqQit0VVllQ2F0d0hDbjYxcEhRa3VFOWFna3AyNm1OV3Q3 aXN5dXdOTU5UTUtpWVZtME1aMnByVTZvMk5RTVkxTnBUU1ZJQlVpZmRxT3BFenRwb0MvYmNJUHJV cHo2MVdpYkNWTUc0SEpyWk1SUTgvbWxGd1JVRkZZM0tKL1BOSVhMWTYxR3ZOUEE1cDNFU0RrMHBo RFUwVktwcWhYR2kyQnBmc3VPbFRKelU2ajZWYWlGeWkxdVFwcEFOdUtsdUoyaGx4czQ5YXF0Y014 Sks5YWlXZ3lacHRvNHBvdVNEVmNuTkpVOHdGc1hUVXYyaGp4VlphbFVVMHdZOVd5ZWFrVlF3TlJn VTlPS3BDRit6cVJ4U2kwRlNLYW1RWnAydUJXRnBUVEZ0YXI0WElyTmt2R3l5YkFSbnJRMVlGcVAv Q25OY1lYcFZUN1MyZnVDbTd5VHpVOHc3RnNYUnBmdFRWU1VtcFY2MHVZR2l6OW9ZMEtjMUdvcVJS VkNKQWdaZW5OSjltV2xVNHFWVG1yU0FpRm9LWDdNS3RLS1dUNUkyUFhBelRzckNLWGtsVzcwNE1F Nm5GVlRxRHNNYkYvQ28zdW1jWTIxbnpKRHNYVGM0b0YzN1ZRREZoVDE2MGN3V0xuMms5czBHWm1x RlJVcWlxdXdKQnoxcHhoVnFhT0trVTFRaGd0aFRoYWdkS21YazAvRk93RlUyNUhTa0EyZ2ptaTl1 VGJNaWhjaGhtcVRhZzVPZGkxTW1rTXZtWFlPT3RiUGhmVVBMMVR5RzZTRGo2ai93Q3RtdVQrMU16 OHFPYW1nbmFDNFNaT0dSZ3k1OWFseXZvRnJIdGtEWkNzSzZyd3JlQzIxUVJzMkk1eHNQNDlEK2VL NGJSTDFMK3lpbWpQeXV1ZXZRK2xiOXV4VXFSbksxbU05VEl4UmlxMm0zZzFEVDQ3ak9YeHRrLzN2 L3I5YXRZcVJpWW9wMktURkFDVWZoUzRveFFBbUtNVTZpZ0JNVW1LZGlqRkFEY1VFVTdGR0tBR2Jh YVVxWEZKdEZBR1RxZWdhVnJLYk5TMDIwdXgvd0JOb2xZajhldGN0TjhLUER5dTBtbXZxT2xTSG5O amVNby9JNXJ2dHRKdG9BOC9IZzd4VFlFSFRQR3R5NmorQyt0VmwvOEFIaGcwNy9pNDlubFdHaGFn bnM4a0xIOHdSWGU3YVFybWdEaEU4UytON1FwNXZndnpWWHZiMzBiL0FPRmNKOFM5UThhK01MYUcw SGhEVUxTMWlPOXNSbVFzZndyM2JZTzRwNnJ0NkRGQUhsK2kvRmUydE5JdExYWHRKMUxUN20zaFdK eTFxNVJpb3hrY1pyYXQvaXo0UG4vNWkwY1o5SkZaZjVpdTJJSnFyTnB0bmNqRTluYlMvd0RYU0ZX L21LQU1hMzhlK0Y3b2dSYTNaTWZUN1F2K05hY090NlpjRDl6ZXdQOEE3c2dOVWJqd1Y0WXVqbWJ3 OXBqbjEreW9QNUNzeWY0V2VESnp6b01DSDFpZDAvazFBSFZyY3dPUGxrQi9HbmlST3pyK2RjT2Zo TjRaUWY2T2RUdFQvd0JNYitRZnp6VFArRll4UkhOcjRwOFNRZTMyd09QMVdnRHZkeW4rSVVoNjF3 WjhDNjlGL3dBZXZqclZGOXByZU9Ta0hodnh6QWYzWGpDMm1IL1RiVGdQL1FXb0E3czFDeTdoTXZx bGNYOWkrSThIM05SMEM0SCszREtuOHFCTjhSbzgvd0RFdjBLVmlNWlM2a1grYTBBZCtGMjZSTC8x emIrVmVkZkNoZzMvQUFsQkIvNWZoL1dwTHkvK0prOWhKYVE2THBjWmRDdm1MZUJzZmdjVnp2aERS UEhuZ3U0dXovWXEzc0YzaHBWVzRUTzRkR0J6N21nRDE3ZFJ2cmtsOFI2NnYrdThJNm92KzRVZitS cC8vQ1ZYSy82N3c1clNmOXV1ZjVHZ0RxTjFHNnVZL3dDRXl0bC8xdW02dEgvdldUMGY4SnRwSSsr THhQOEFmdFpCL1NnRHBTMU5MVnpvOGNhQWZ2WGpML3ZST1A2VTlmR2ZoNC84eE9FZlhJL3BRQnZF L1drckdYeFpvRGROVnR2Kys2a1h4TG9qZE5WdFArL29vQTFlUlM3bTlUV2N1djZRM1RVclEvOEFi WmFrR3NhWWVsL2JIL3RxdEFGM2UvOEFlTkw1ci8zalZNYW5wNTZYbHVmKzJxMDRYOW1lbDFEL0FO L0JRQmE4NS83MUw1OG45NnF2MnkxUC9MeEVmK0JpbCsxVzMvUGVQL3ZzVUFXZlBrOVRSNThucWFy L0FHbTMvd0NlMGY4QTMyS1g3UkIvejFUL0FMNkZBRS9ueWV0SjV6K3RRZmFZUCtleWY5OUNqN1Zi L3dEUGFQOEE3NkZBRS9tdjYwbm1OVUJ1N1VmOHQ0LysreFRUZldZNjNNWC9BSDhGQUZuZS9yU2Iy OWFxSFU3QmV0NUFQKzJxMUcyczZZdlcvdGgvMjJYL0FCb0F2YnpTN3F5bThRYU1uM3RUdEI5WjEv eHFCL0ZlZ1IvZTFpeUgvYmRmOGFBTnpmUzc2NXAvRy9oaVA3MnQySS83YkxWZC9pSDRUVHJydG4r RDVvQTYzelBlamZYRnQ4VHZDQ2Y4eG1JLzdxc2Y2VkNmaW40Vi9ndlpYLzNMYVEvK3kwQWQxdnBO OWNLUGlmb2Ivd0NwaDFPWC9jc1pEL1NqL2hZMXUzK3AwRHhCTi91YWU5QUhkNzZVTlhDRHgzcU1u K284R2VJWCt0cnQvbWFHOFdlS25IK2plQk5USjdlZElrWS9uUUJuQmdQMms3UG5yYXYvQU9ndFh0 TVIrV3ZtK1h3eDhUYjN4c3ZpeUxTWWJhOFJ3MGFQUEh0VVl4dFB6YzhaL092UW9kWCtKdTBidEIw dEQzemZmNEEwQWRoT2QxdzUvd0JzMUhrWXJqbS80V1RPZUxQUUlNOTNua2YrUzBnMHI0alRmNnpX TkR0Lyt1ZHRJMzh6UUIyTkdSNjF4My9DSmVOcHorKzhhSkdQU0RUbC9xMVBIdzkxaVlZdXZIR3NO LzF5ampqb0E2MHNCL0ZVYnp3cDk2UlI5V3JsMStGTnBJYzNYaUx4RmNmNzE5dEg2TFVxL0NId3Ez TThOOWNuL3B0ZXlIK1JvQTE1dGIwdTN6NTEvYlJqL2FtVVZteitPdkM5c2NTYTVaQStnbVUveXF6 Yi9DN3daYi9jOFAycmY5ZE56L3pOYWx0NE44TjJtUHMrZzZiR2ZVV3FmNFVBY2hOOFUvQ1VSd3Vw K2MzcEZFNy9BTWhYSWVQUEdFL2pEUVA3RjBEUk5VdUJKSUdlWTJyQVlIb0s5eWgwKzB0eGlHMWdq LzNJd3Y4QUtyS3J0NlVBZVA4QWd6eFg0MzBydzlhYVhjK0ROUW1OcEg1VVVvQWozS09tZDNldDZU eEQ0K3YySGwrRUlvT3dhNnYwR1B3VUd2UWl1ZTFOMkQwb0E4Nit3L0VtK1B6M3VoNmFoLzU1cEpL dy9QQXBQK0ZlNjVmZy93QnIrTnRUa0I2cFp4ckFQejVyMFlKVGd0QUhCV2Z3bDhLUVNpYTV0SjlR bUg4ZDdPMG42ZFAwcnI5UDBpdzB5SVJXTm5iMjBmOEFkaGlDRDlLMEF0THRvQVlxWTZVNExUc1V1 S0FFeFM0cGNVWW9BU2x4NlV1S01VQUppbHhTZ1VZb0FNVVVZcGFBRXhTNG94UzRvQVRGSTdwRkcw am5DSUN6SDJGT3hXSjRsMUFXbGo1UVB6dHlmNkQ4K2Y4QWdOQUhJNm5NMm9hdXdKNk1kMzE2bi9E OEtnMUIxaWhQYmlyT213WWllNGZrdHdEL0FGcmovSDJ0RFQ5TmRJMnhQTDhpWVBJOVQxendPL3Jp cVFqelBYOVQrMjYxY3lxZDBZYlloRFpHQjZmWHJXWWJuaW1NS2diak9LMXZaQ0xQMnJqbW5MTUdy UExmTlRmdERBOUFjVlBPQnBiY2lrRUdhcEMvZFRuWU9LdldWeTF5V3lnR1BTcVRUQ3dmWlFWcFBz d0ZYQ0FCVWJHcjVCRmNRS3BwQ01WSXhxTTFJRERJVWJpajdTYVJoVUxESFNwYkdURzZQU2srMCsx VkhOUjd5dk5UekJZMGZNM0RpbWxOL1RPS3BMY012TzBIOGFtUytaUDRCK2RQbXVPeForeWpGSjls V3JrZk1ZWWpxTTBqZEswNVNibE0yd0ZLSWxYSnFaalViR3BhR1JIZ1Vpek10T1BTb21GVGNCNXVq U2ZhbXF1K1JVWk5MbVl5NHMrNDgwcDVGVWcyQmluaWNqakFvNWdzV0ZoM0hrMDgybzZab3RyZ3pT N0NvQXhWd3JnVlNqY1JSK3lqRko5bUFxMDN0VVRHaG9DSndGd0JUQ3hVakJwN1ZHdzZjVklJZDU3 Q2tOMGFpSXBocFhLSnpjbWp6ZHkxV0ZPRGJXQnBjd0UrT0tGaHljSHBVWG1ucmlydHEvbkJtSXh0 OUtwYWlJZnMyT3ROTnNLdnNBQlVEMDNGQ3VWdklDbWtZWVBIU3BHTlJ0elVqRTNsVFMvYUdGTklx TTlhVnhpVW5lbG9xUUhyVWdGUnJVZ3FrSVVVNWFhUFNuanJWQ1pQRjFxeW5XcTBYVVZaV3RFSVpj UmVhRkdCdDdudldlOENxeEF6K05hcCs3aXMrVVljMHBqUlRJd2FTbGI3eHBLd0dQUVZNdFFwVXkx U0FmajBwVjYwQ2xGVUlrU3JFZFYxcXhIV2lFVEFmclZLYXpWZzd5Y04yMjFlV281eCs3ZjZWVWxk QVpuMmRlNU5WandhdmtZcWkzM2pXRWtVaFZOVEpVQzlhblNwUUV5aW5pbUxUeDFyVkVqaFVpVkVP dFNwVkFXRTZWSVJsVGprK2hxTk9sU2lyUVhNNlRUMEM3eVNHUFlWVmx0MVJRVnpXdE1Qa3JQdVB1 alByV2NvcER1VTg4MUtoNXFFZGFsUWMxa2hsbEtsQXFKS21GYW9rVWRhY3BwbzYwNFp6VkFTcFVx OWFpV3BWcWtER1hGc2x5bUhINGlxRDZmR3B4dU5hdmFxc3YzNlVvb1NNcDRWalk0b1htcEp2dkdv MXJGcXhSMlhnalZURGNHeGxiNVcrYVBQWTl4L1d2VGJjNXd3cndxM2tlR1ZKVU9IUmd5bjBJcjE3 d3pxOGVwMktTamh2dXV2bzFKb1ozZmh6VWhZM2ZreW45eEx3ZmIwUCtmZXUxSXdjVjVxcThBcng5 SzdEdy9xb3VZVnRabXhLZ3doUGYyL3o5S2tadFlveFRzVVlwQU5veFM0cGNVQU5veFRxS0FHNG94 VHNVVUFKaWt4VHNVWW9BYmlqRk94UmlnQnVLTVU3RkdLQUc0cE50UHhSaWdCbTJseFRzVVlvQWJp akZPeFJpZ0J1UGFqYlRzVVlvQWJ0OTZidHFURkdLQUk5dEp0cVRGR0tBSXR0R3lwTnRLQlFBMVZw K00wb0ZLQlFBbTBlbEtGOXFjQlNnVUFKZzBoWDNOUEFvb0FpTVN0MVVINmlvMnM3WnZ2VzhKK3NZ TldjVVlvQXBOcFZnLzNyRzFQMWdYL0FBcUp0QjBwdXVtV1ovN1lKL2hXbGozb29BeVc4TmFJM1hT TEUvOEFidXYrRlJud25vQjY2UFkvOStWcmJ6U2NVQVlSOEhlSFQxMFd5L0NPbUh3VjRjUC9BREJy VDhFcm9LTVVBYzZmQS9oby93RE1IdHYxL3dBYWIvd2d2aHIvQUtCRUg1dC9qWFNZb3hRQnpYL0ND ZUd2K2dURC93QjlOL2pSL3dBSUg0YS82Qk1QL2ZUZjQxMHVLVEZBSE5mOElINFovd0NnVEYvMzAz K05ML3dnZmhuL0FLQk1QL2ZUZjQxMHVLTVVBYzEvd2duaG4vb0QyLzV0L2pRUEF2aG4vb0RXMzVI L0FCcnBjVW1LQU9jLzRRYnd6LzBCTFA4QUZLVWVDUERJL3dDWUZZL2pFRFhRNHBNVUFZQThHZUd4 MDBMVC93RHdIWC9Dbmp3bDRlWHBvbW5EL3QxVC9DdHlreFFCa0w0YTBSUHU2UHA0K2xxbitGU3Jv bW1KOTNUYk1mUzNUL0N0TEZHS0FLYTZmYXA5eTFnWDZSS1A2VktJRVg3cUtQb01WUFJpZ0NMWitI NDB1ejFxVEZHS0FJL0xIb0tVSUIvQ0treDlhTVVBTnh4MHBwV3BNVVlvQWkyZTFBV3BkdnRRRm9B akMwN2JUOFVZb0FidHBRdE94UmlnQk1VdUtXakZBQ1lveFRzVVVBTnhSdHAyS1hGQUROdExpbllv b0FURkxpbHhSaWdBeFNZcGNVdUtBRXhTNG94UzBBSUJSaWx4UmlnQXhSUzRvNzBBSmlseFM0b3g3 VUFGR0tYRkhiMG9BamxsU0NGcFpQdXI2ZC9hdlB0Um5sMW5WZGluSzdza2pwN24rbGF2aVhXZk1J dHJkajdZL24rUGIvNjlWYkswRmhhRjVCaVZ4bHZiMnBnUlg4cVdsdHRYaFZYQXJ3VHhicS85c2Ex STZQdWdpeWtlRHdmVnV2YzkvVEZkMThSdkVxdzI3NmJDV00wNmZNUjBWRHdmejVGZVUxcENQVWxr YkRpb0g0cWQrbFFTVlRBcnQxSE5Jc1FkdWFWdUtkRWNNS3pBblN4UWtEYzFhTnRiSmJwaEJ6NjFC SDk0VmRYZ1Z2RklRMDFDL1NwbXFCNllFVEdtMDQwMnBZRFdxRjZtYnBVTDFER1YycUkxSzlSSHJX WTBTd3dySWNFMWJ0N0dNdms1T0RtcTlyOTc4SzByY2MxY0ZjVExCR0Y0cUY2bE5SUFd3aUIrdFJF MUkrY21veldiQWFlbE1OUDdVeHFsaklYcUE5YW5lb0c2MW14b0FNMVlTQldYdlZjRUNya1gzVnBv QzNhMi9sT05vR09wSnFkdWxKSDkybGJ2WFFsb1NRUFZkalZoNnJ0VVBjWXdtazdVYzRvUFNvQkVi VkMxVE5VTFZER0pTcU56QWRxU25SL2ZGQXlRUWpPQ2F2MjhZalVqSEhyM3FwL0VLMEVIeTFwQWth M2ZJcXU1cXkxVlhwc0NKalRLZTFNcUJpSHBVWkhOU0hwaW82UURhS2s4cHM0RkhsUFUyWURGTlNE TklJV3BkakwxcWhqeDFxVUFrMUd0UDh4VnFoRTZERlRLYXFDZGFkOW9IYXE1a0l0bCthcFM4dTFE M0hYRlI1eWMwbTdnVm0rOGFUdlZsb2NnNDYwM3lHcUxESTFxVlRRSUhCNlU0Uk5UU0FjT1RUbHFO Y2cxTEhnQTAwSWxVVk9sVlJNdFBGeW9xMHdMZWNWSEszN3RxaCswcVIxcUl6YmlSemlxY2dFN2Zo Vk5sNjFjRkkwQkk0ckpxNElxTDFxVlRVZ3QyOURTaUJ3ZWxMbFl3QnFRYzAzeW1ITk9VRURwVm9r a1VWS281cU1IQ1VDWk05YWR4bHBhazNZRlV4Y0tPOU84OWF0U0ZZa2xPVXFqY0xsQjlhbE11ODQ3 VUZOL0ZTOVJsRGJpbnJWZzI1OUtCYk5tcytVWTFUVXEwZ2dZVXV4aFZMUVJJS2tVVkdvcCs5VnFy aUpSVWdPS3JDWlBXbmVlbnJWcGdXQ2FyU2ZmcEdtR09LYm5kelNiQ3hUbFg1NllCZzFkTVc3bW96 YnRXYmlNalRyV3hvR3N2bzJvQ1lBdEczeXlLUFQxK29yTUVMQ2w4dGgyb3NCN3pwbDVIZFFKSWpo bFlaQkI2aXRFQjRKRmxqT01WNHo0VThTUzZOY0xiM0RNMW94Lzc5bjFIdC9uNit4V0Y1RmRRcXlz R1Zod1FldFExWWFPMDBqVmt2NGxTUTRtSEhQOFgvMTYxTVZ3R3lTMmtFc0pycDlLMXVPNFVSM0Ri WEg4Ui9yL0FJMU5obXhSaW5Zb3hTQWJpaW5VWW9BYmlseFMwbUtBRXhSaW5ZK3RHS0FHNHBjVXVL TVVBSmlreFRzVVlvQVRGSmluVVVBTnhTNHBjVWRLQUV4UmlseFJpZ0JNVVlwY1VZb0FURkdLWEZH S0FHNG94VHNVWW9BYmlseFM0TkdLQUVGS0tNVXRBQ2lsRkppbG9BVVVVQ2x4UUFZcE1VdEdLQURG SmluWXBNVUFGSmdVN21qRkFEYVhGR0tNVUFKUlM0cGNjVUFOb3hUc1VZb0FiaWluWXBNVUFKaWtw MUpRQTAwbE9wTVVBSlNZcDJLS0FHMFlwY1V1S0FFeFNZcDJLTVVBSmlqRkxpbHhRQW1PYU1VdUtN VUFKaWpGTGlseFFBM0ZHS2RSK0ZBQ1lveFMwdUtBRW9wYU1VQUdLUHBTNG9vQVNqRk9veFFBbUtN VXVLTVVBR0tNZTlMUmlnQktYRkZMakZBQ1VVdEdLQUNqRkxpakZBQlJTNG94UUFtS01IMXBjVXVL QUV4UmlseFNNVlJTN3NGVWNrbmlnQmNWemZpRFhVZ2lNTUJEYnZ5Yi93Q3gvblROZDhRTEdyVzhI SlBiMS8zdmIyL09zV3pzbmxrKzJYdVdKK1lLM2Y2LzRVQU8wMnlZc2I2NnlYYmxRMzh6V1A0dzhT dzZOcDd6UGx5VHRSRi9pYnNQL3IxWjhUZUpyVFJiQ1M0dUpkcWpoUU9ySDBGZUZhOXIwMnU2bEpj U3lNWWd4RVNIamF2MDlmV3JqRzRtVTc2N2x2NzJhN25PWkpXM0hucDdmU3FwcDVJSTYxRzNQU3Ro V0dPZUtoZXJIbE9lMU5NREVWTFFGUWpQclRrWEJGV1BzN1ZJa0dPdFR5Z1BqKzh0V3QxVkR4K0ZP U1lkNjFRaXllbFJNS1o5b1gxcFBQVDFvdUFNS2pOU2VZcGJBcU05ZTlKaFpqR1Bhb1dOU2xTejhV M3lYSTZWQXlxd3pUQXZOV3piUDZVQzJhcDVRSTdkY01hMExjOVJWY1I3S1VTYkRWUjBEY3U1elRH cUVYSzBuMmhEM3ErWVZoekROUk1NVXBtU2plckRpcEdSSHBVYkdwR3B2bHN3NlZJRmRxaUl6NjFi TnUvcFRmczcrbFM0NmpLd1hJcTNFTUlLRmdJUE5PeGpJcHBBeTZqWVVVNG5pcVN6WU9EMHAvMmtZ clJTRllrZm1vU09LRGNLYWFaVkpxV3dHTlRXNHFSc2NWRXdKSXhVc0NOajdWRzNKcWN3dDJwdmtQ anBVdERSRCtkUGpIemluK1ExTzhyYU05NkxBTy9pcTZqOENxTlBTYkI1cTR1d2k0eHFCcVo5b1gz cHBtUTlLR3dzQkZSbmluK2FwNHBqZGFrWXhqVVpOUEtrdHhTZVU5SUN5cHlhbFVacUZUelU4Zk5X a0laY1A1SUh5NXpWTXl1M1d0S1pESkF5cjFyTldGMmJidElwU1ZoamQ3WTY0b3lUU3NoQTZVMGRL Z1lVNWFiM3A2aWdCd0dUVXE4WXBnRlBBcWhFaW1wVUdUVUNtcGtxMEluVmFvejNMN3RvWGFjOWF2 cHpWVy9qWXNyTEdEbnVLSkxzQlM4MlE5NlR6SHgxcC8yZVRhR3hqUHJUR2pLL2VySjNSUWdmaW5B NXFQRlNMUUJLS2tVZk5UVnFRQ3FSSXVPYW1VMUQzcVJUVm9ST3VLZmpna2pJcUpEVmhLdEFaTTk0 N09kbnlxT0toODZYKzlWcS9oL2YvSkdjYmNuRlZ6YVNqR1JqSXpXTFR1VWhobWt4OTZuTElTYVpK R3lNUWUxQ1ZOd3VUcWVha0ZScDFxZFJWb1RIS0tsVTROTUFwdzYxYUVUTDFwNmlvVk5UcDBGV2dJ N3FUeUlESUJ6OTJzcjdWTWVOL0ZiY2tZbGpaQ001SEZZcTJVenltTGJqMzdWRTB4b2I5cG1QRzZr KzBPQ1N4SnB6V2tpQTdzY1ZDdjNoa1ZscVVXdytjVThkZTlRcG5OVG9LcENZOVJ6VXE5S2FvcC90 V2lKSGcwOFZFS2VEVEFrQXoxck52YnA0NXRpY1k3MXBMME5VdFJ0eTZpUkZ5UjFwVFdtZzBVUHRV eC9qTmRWNFA4YVRhSGNMYlhyczlreDY5VEdmVWVvOXE1WkxhVnhrREdQV21Td1BGZ056bjBySFVv K205TzFHQzhnUjQzVjBkY2dxY2hoNjFaYUhhd2toT0NPUmc4aXZucnd6NG92dkQ4b0NzMHRxZnZR TTNBOTE5RC9PdmFQRC9pbXkxaTJXUzNtQlBHNUR3eW4wSW9FZGxwbXVQYjRpbSs1NzhEOEQyL2w5 SzZXM3VJcmxjeE5ranFwNmo4SzRjK1hNTWpBUHFLZEJjVFdqQW94S3IwR2VuMFBha003dkgwb3JF c2RmU1FoSnVXL0p2eTZOK0g1VnRSU3hUcnVpa0RBZGNkUjlSMnBBTGlpbllveFFBM0ZMaWx4Umln QnRHS2RSaWdCdUtNVTdGR0tBRXh4UmlseFJpZ0JNVVlwY1VVQUppakZMUmlnQk1VWXBjVVlvQWJp akZPeFJpZ0J1S1dseFJpZ0JNVVlwY1VtS0FFeFNnY1V1S0tBRXAxR0tLQUZvRkFwYUFFcGFVVVlv QVNpbG94UUFsTDJveFJRQWZoUlJSUUFVZDZLS0FDa3BhTVVBSitGSlRzVWxBQ1lwS1dpZ0JLTVV1 UGVpZ0JwRkdLWEZHS0FFeFM0cGNVWW9BVEZHS1hGTGlnQnVLTVU2a3hRQWxMaWx4UlFBbUtNVXVL WEh0UUEzRkxpakh2UzRvQVRGR0tXbHhRQTJscGNVWW9BVEI5YU1VdUtYRkFDWW9wY1VZb0FURkxp bHhSaWdCS1hGR0tYRkFDWW94UzRwY1VBTnhTNHBjVVlvQVRGR0tXbHhRQW1LTVV0R0tBREZHS2ps bmlnSDd4OEhIUWNrL2hYUGFuNG9qaXpIYjVMZjdCeWZ4YnQrRkFHN2RYc05vakdSaHVBenRCNmZY MHJrTlU4UVRYc25rMnVUNkVEZ2Y3ditKck9rZTcxSnQwejdJczUyOXY4QTY5U3Exdll4WVhBUGNu dlRBZGEyS1c1ODY0SWFYcnoyckw4U2VLTFhSN0dTNG5rd3E5QU9ySDBIdldCNHE4ZDIybElZb2lK N25PUEtWc0ZmZHZUZy9qK3RlUGFwcVYxcTk0OTFlU2I1RzZEc285QjdWU2pjUlA0aThRM1hpRytG emNEWXFncWthc2NLTTUvUHB6N0NzS1dWZ1FGNHFWcXJ5akl5S0crZ0FMbWJzMUw5cW1IOGROU0I1 UHUwOTdhVkJ5dTc2VWxjWmRzcnA1bkVaWFBxMVhpTVZWMDJCNDRtTGpHNDFjYXVpRzJwREl6VFNh VmpVWm9BYTNOUk1LbXFOaFVnUU5VYk5qaXBaT2xWbXJOc3BiRGZPY1p3YVg3VEwvZU5Sa2MxS2x0 STY1QUErdFRxTUJjektjN3ExcmFYejRBNUFCNlZrSmJ5dSswS2VUMTdWdVJ4TEZHRVVZd08xYTAw eVdOWVZHVGlwSHFCcW9RMXptb25HYWtKcHBxV01nWVZFVHhVN2lvSDRxR01qTDRvRXJyME5OTklC azRGUmRqSlBQZjFxZTJ1WDg1VmI1ZzN5MUNMV1ExYTArM084dTZmS09CbXFpbmNUTHhVQ29tNDVx WmhVRDFxeVJqR29qVG1OTnFXeGtURHZVVFZPd3FKaHhVTVpEbkZHNzBvUFhGSlVhakhlWTJldEw1 ajQ2MGlvVzZVcGljZEFUVFZ3THRyTDVvMnNQbTlhbVlZcGJhTUpicjh1Q1J6US9TdGt0Q1NGcWlZ OEduc2FqSnFXQTAxR1JVbk5NWVZMR1JHa3BXcEtnWUFrRVU3ZWFiVGdwSW9BQTdBNUhhcktURXI5 ejlLckNOdHd3Q2EwMGpJUUFxb0k3Q3RJaUtpZGFzUlZYVVZZanFrSXNMVFpqbGNleG9CcEhiQTll RFZDTTZUN25wVU5TdVBsTlJWZ3lrSjNxUmFaVDFOQXlZVTRWR090UEJxa0ljT3RUSjJxSmFsU3FR aXpHT0tsSDlldFFvZlNwTjJCV3FFVnJuamIvdkdxRS9RVmZ1V3p0eDcxUW01QzlheW1VUTA5T2xN L0NucFdReWRLbEZRcWFrQnEwU083MDlhWlVpMWFFU3BWaE9sVjBGVHJtclFFdVJpcVZ3UDNuNFZi M1lxcE9jeWZoVFlGQzUvMWpmU29SMXFlNEdaRDlLaUE1ckI3bEVpQ3JDMVhUclU2bW1oRW9wd3Bx bW5EclZvUTlldFRwMHFGUlV5VlNBbEZEL2RwQlNsdUtzQ2pKOTFxem0rL1dqTHlyMW5zcEZZVEdP U3JDVlhTcGs0TkpBeXd0T05SZzAvcldpRU9GT0hXbWdVOVJUQWtYRktQcFNDbFA2VllpR1UvajdW VW4rN1Z5VS9MVk80R2NFVm5JcEZVY21yZGpkM0ZqY0xQYXpQRkt2OFNuL09mcFZYRlBYcldhQTlR OFBmRU5HQ1E2bis2bEp4NWcrNGZUNmZ5cjBHMDFPRzZqVjBrVmxZWkJCeURYem1PdGF1bGE5cUdr TVBzczU4di9uay93QXlmbDIvQ2psR2ZRQkNQMDZWUEJlejI3S1ZjbmIweWNFZmpYbTJqZkVLMHVD c1Y1bTJrOVdPVVA0OXZ4cnM3ZlVvYmhBeU9DRDBJTlRZRHNMYnhId0JOZy83M0IvUG9mMHJhdDlR dHJqQVdUYXgvaGY1Znk5Zndyejd6VlBTbngzRFIvY2NxRDI3SDhLVmhucEdLTVZ3OXJyZHpiOEs1 d095OVA4QXZrOGZ5cll0dkZFVGZMTWd6L3NuYWZ5UEg2MHJBZEJpakZVNGRWc1pzWW5DRTlwUGwv OEFyVmRHQ01nNUhxS0FFeFJpbHhSaWdCTVVtS2RpakhOQURjVXVLWEZBRkFDWXBNVTd2UmlnQk1V WXBjVVlvQWJpbHhTNG9vQVRGR0tYRkppZ0JNY1VZcDFHS0FFeFNVN0ZHS0FFeFJpbG9vQVNscGNV WW9BS0tLWEZBQmlrcGNVVUFHS0tLS0FERkZGRkFCaWt4UzBZb0FNWXBLWEZGQUNZcE85TFJpZ0JN VVl3S1drNzBBSjJveFRzVVlvQWJpbHhTL2hSaWdCTVVZcDJLTVVBSmptakZMaWpGQUNZb3BjVVVB SmlseFJpbHhRQW1LTVV1S01VQUdLU25Zb3hRQW1LTVV0R0tBRXhTNHBjVVVBSlJTNG94UUFtS1hG TGlpZ0JLTVV1S1dnQk1VWXBhS0FFcGNVWW94UUFVVU1RaTduWUtQVW5pcWMycTJVQ2ttYmZqKzUv ajBvQXVZcGNjZGE1dTY4V1FKeENBVDdEY2Y2Q3NPNzhRM2wwY0E0SCsxODM2ZFAwcDJBN1dmVWJX M1VreWhzZGRwNC9QcFdCZitLMEdWdHVUL3NkUCsrai9RZmpYTHlOTk8yNmFWbVArMGMwQjRvdVRq UHJSWUN6UGQzbDhXM3VVUTlod0Q5ZldtSkZEQU56Zk0zdldaZmExYldjVFBMTWthTDFabTJpdUQx ajRoNXpIcHNaa1A4QXoxaytWZTNicWUvcCtOVWxjUjZGcWV2V3VuV3J6VFNoSTBHV0o3VjVqNGo4 ZjNGL3Z0OU5MUlJFRldtUERIbitIMCt2WG50aXVVMURVTHZWTGd6WGN6T2M1VmMvS3ZzbzdWVUFx bEFCWFpuWm5kbVoyTzRzeHlTZldvajBwNXBqSGlyRVF2VVJxVnFadHpXVEJia3R2OTZyOFBVMVJn WEQxZWhQV3RJSUdXT3ROYnBTNTlLYWExNkVrVGU5TXFSaFRNVkxHTk5NYW5VeHFrQ0dUcFZacXN5 VlhZVmt4b2pBNXJRaSs1VkVMeFYyRmNSNHB4R3kvRHd2U25tbVJ2d09LZVRYUXRpU0Y2aGJwVXox RXdxR0JGU0duSDZVMWppcFlFYjFXa0hPYXNNYWdjNUZac2FJVFRvc2J2eHBNVXFLZHc3Y2lwVzR6 U2kvMWxYQjkzOGFwUkhFbFhBMWRFZGhDUDNxdTlUdFVEaWhpSUc2MGxPWVUyb1l4amRLaWFwR3FK czFER1JOMXBLVTBncUJrMEhlcjFyM3FqQUR6VjYxT0ZiNjFwQVRMUnFDU3BTYzFFOWFza3JOVVpx VmhVWkZac1kzdFRXcHhwakdvR1J0VGFVMGxTQVZJbjNhanFSTTdhYVF5L2JmNnNWTnhVRnUyRVg2 MUxuaXRrUVZCZ1ZJcmdkTVZSM042MGJqNjFtcEZXTkh6ZTJhaWFZQWZXcVlKOWFVQTVvNXhXSkdH VnFJb1IycWRhbEFCN1VXdU5GTGFmU2xVSDBxK3FMNlV5NHhGR01MOTZqbEFyRE9ha1dvVEs1Tkht T085SzR5NG85YWtVaXM4eXVSak5IbUh1YWZNS3hxQnd0S1pBZTlaZ2MrdE95ZldxNWdzV1pKUE13 UFNvWFF1T08xQ0NwVTcwdHhGVFlmU2xDa2RxdnFxbnRVZ2lVOXFmSUZ6T0FOU0wxcEpwOE1VUk5w WGpOUSthK2M1cWRobHZITlRLS3ovUGtvKzBTSGdtbnpDc2FZSUhlcEJJQjNyS0VySHZUZzdldFZ6 QlkwMmxHTTFYZGc3WkhwVmNFbjFxUkJpbmU0RFpJaWN0N1ZDWXlUMHE4bjNjVklGSHBTNUxnWjZx UWNZcDR6Vi9ZbU9jWXJPbXV5WlAzWEFINjBPTmdKbFBOVEw5NnM3N1RKbjcxSDJxYlBXa3BwQlkx aGdVOVdHZXRZd3VaUWNscW5FcFBjMVhPRmpVM2oxcGpTZ1ZSRHNlOU9ISjYwK2E0aVpobXF6UmRz VmFYMXFUZzBPTndLQWpJN1U0S2ZTcjRRVkZjeUpicG5BM0hwUzViREs0eUttVHBXY2J1WTk4ZmhT QzZsSDhYNlZQT2gyTmRlYVVFQ3NqN1hML2YvQUVxU0c0ZHdWSi9HcVUwS3hxWkFvTGpIV3FBa1k5 NmVHSjcxWE1LeE83WjRxRjBMaWxVR25yU1lGUXhuTktGeDJxNWptamFNOUtYS01xZ0duWnFPN25N VW14QmcrdFZ2dFVwNTNWTGFReS9pcmxqcVY1cHpadExtU0x1UUR3Znc2VmlmYXBmV2srMVMrdEhP Z3N6MGpTL2lCTWpoTCtFRVovMWtSL29hN093OFFXdDRtNktaWEhCd0R5SzhLV1hlS21pbWtpY1BH N0l3T1FRY1VySUQ2Qlc3alljTlVnbno3aXZGckh4WnFWbW9WbkU2aisvMS9PdWxzdkhkcytGblY0 ajc4aWxZRDBaYmpaOTEyVDZIaXJFT3EzTnVRWVppdis2ZHY4cTVDMThSV2wwb01jNk51NXdHNS9L cnlYc2I5R3BXQTdPRHhkZlE0RW0yUWY3YTUvVVlyU3QvR3RzM0Z4YnN2dkcrZjBPSzgrRnlwNlBS NTJlK2FWZ1BWSVBFdWt6Zjh2WGxuMGtVcldsRGNXOXd1WVo0cEIvc09EWGpIbWVuRko1cm9jcTdB K29vc005dDIwWUZlUFFlSU5WdGY5VGYzQ2owTGJoK3RhRUhqdldvZnZ2Qk1QOEFwcEhqK1ZGZ1BV S1hGY0JEOFNKUi93QWZHbUkzdkZML0FJMW9RL0ViU1gvMTl0ZHcvd0RBUXcvU2tCMTJLTVZnd2VO ZkRzLy9BREVValBwS3BXdE9EVjlNdWgrNDFDMmsra3EwQVc4VVlwVjJ1TXF3WWV4elM3Y1VBSmlq RkxqM294UUEzRkdLZGlreFFBbUtNVTdGSmlnQk1VWXAyT0tNVUFKUlM0cE1VQUZGTFJRQW5hbDRw Y1VVQUpSUzRvb0FTaWx4UlFBbUtLS0tBREZGRkZBQ1VVdUtLQUV4UmluWXBPYUFFeFJpbllveFFB M0ZMaWxveFFBbEZMUlFBbEdLWEZMaWdCTVVZcGNVWW9BVEZGT3hSaWdCdUtYRkdLV2dCTVVZcGFY RkFEY1V1S01VdUtBRW9BcFFQU2hpcURMc0ZIcVRpZ0JNVXRVYmpXOUp0ZjhBWDZsYXgvV1Zhekp2 Ry9oMkhQOEF4TUJLZlNKR2FnRG9jVVZ4ODN4RzB0ZjlSYTNjdnVWQ2lzK2I0anpOL3dBZStuUnA3 eVNGdjVDZ0QwREZMaml2THB2SE9zemZja2hoSC9UT01mMXpXZk5yK3AzUCt1dlptOWk1QS9TbllE MXVhNnRyY1ptdUlvLzk5d0t6NXZFbWx3Zjh2QmsvM0Z6K3ZTdkt2dERzZVpHcFBNenlUays1b3NC NkpjZU5MWmNpR0hKLzJtei9BQy94ck11UEdGM0tQM1h5RC9aQVgvRTF4L25BZHhTRzVRRGx2MW9z aEc1TnJGNWNObDVjSDE2bjh6VlZwV2xPWGRtUCswYzFrUHFNU2M3aFdUZWVMckMyVGQ5cFZ1Q1FF TzRuOHFhUUhXR1JWNmtWQTk5RkgxYXZPTC94NDdLUmFRa2tqaHBEajlQL0FLOWM1ZTY5cU45a1NY THFoejhpZktNSHR4MXFsRmdlcDZqNHQwK3h5c3R6R3JnNDJENWorUTVyamRTOGYzRSs5TEdMWVA4 QW5wSjE2ZjNhNHJyM0pwdlRwVDVSRis3djduVUpmTXVwM2xZZE05QjlCMEhTcS9GVml4cGp6YkJu clZYc0JjcERXYjlwbEI2MHYycWIxcWVkRHNYbTYwd2dtcW4ycVVkNnMyVndacFBMY1pQVUdtcEpn QlRQWTBDUG5wVi9ZQjJwdUIxeFQ1UkZlT1BCelU2TnNOS3hCRlJ2MHA3QVdRd28zREhXcVJaaDNw aGR2V256V0VYaWFaV1pKY3NPRkordE5GM01QNDZsekhZMFQwcUk1TlUvdGMzOTZsVzdsWCtMOUtu bUhZbllVenl5YTBJTVRSQ1FqOEtjVVVkcXJrdUl6bGlKNHhWaFYycmp2VTVBR01WRzFITFlMajBr R052ZXBONFBlcVRjSGlveXhIUTArYXdHZ3pEMnBoMjFRTXJBZGFnTnhKdTROVHpnYVRqQTZWQzlW RGRURWRhVDdSSjYwdVlMRTdBK25GTUtFOWpTd1hXSlAzb3l2cldqNWE0NEE5YUVyZ1pmbCsxUFdF NXE4VkE3VTFzQWU5UGtzQkdyQldCcWRaUWU5Vm02VkVTUjNvdllEUU1nUEdhWXhIclZCblByVVps WURnMGM0RjhqUFNvbTcxVUV6cjNOSjU4bnJVdVFXSm16MHBoQklwZ21jY2lydHN5VEFnajVxUzFH VXRoOUtGVEJyVGFOZlNveUZIWVUrUUNza1pUOGFtU1FSOFk1SnBIUFBTb242OFVMUUM4SlI2MDFu QjcxUUxIRk1NaDlhT2NMRjVpRDNxTmh4VlR6R3BmTmZHTTB1WVZpWTlLaWFrOHhzVUJ5RG1rTWFR ZlNqQjlLdVFoWkZKQzRwN0lvN1Vjb0ZBS1Nha0NFREZXTUtPMVJ1ZWFkckFQU1FBQmFsRXdBeG1x VGZlcHVUNzBjMWdHMFVVbmVvR1BXcEFPYVl0UHFraERoVWltbUNuTFRRYUU4WnpSZFI3NGNqcXZO RVZXVXdPY2Mxb2xvSXhQU2l0UjdLTXliL3dDSCs3VldTSkZjZ0FZck53c081Vm9wVDk0MGxRTWV0 U3FLaVRwVXkxYUVQSEZPV20wcTAwSW1XckVmVVZXVHJWbVByV2lFWjk1QXNibGxMRmp5UmppcW1N VnZPbm1Sc25UUGZ2VlpyS0tLRmdSdVBxYWlWUHFNeXFLdWVVaC9ocW93d2F6YXNVT1dwVUZRcFU2 VTBKc2xVVklLWW9wL2VyUWg2bXBGTlFqclVxZGF0Q0p3dTVDRHhuSXpXUmQydjJaMUhMQWpyV3du U25TUkpOR1VjWkg4cWJqZER2WTUzclIrZGF4c0lvb215Ti91UlZhZUtNTDhveDlLeGNHaDNLWUdU VmhLaEF4eG5OVEpVb055ZEJ4VXFyVWFkS2xyWkNIQ25xZWFZS2V0VUlsV21YTnVzOFJ6MVhwVDA2 VktLcTF3T2JaV0RFRUhpay9BMXUzRmhGTzRjOEVlZzYxRkphMjZ2Z1JqOHF3ZE5sWE1lcG9Sam1u enhJSk1xTUFkaFNLTVVyQVRvTTFNb3FKT2xUQ3JTRUtCelRoUlFLc1FvcDRwb3A0SEZOQVorb1JZ WVMvUVZuOUs2QmtEcHRZWkJxcWxoRkh1Skc3UFlqcFdVNmVvN21UOWNpZ0RKclNlM2lDbkNBZlNx b1FJeDcxRGpZZHgwYTdSeFV3RlJyMXFWUlZJUW9GT3dLQUtXckFGSlU1VWtIMnE5YmF0ZlcyMFIz TDdSd0FUa1ZSRktCelJZUjBWdDR0dkk4Q1pGY2VvNE5YYmZ4M2E3dHM2eVJIUHB1RmNsaW9aclpa ZWVBZlVVbkhzTTlMdGZGRmhjbkVkeWhQb1d4V2dtcFJPQVF3SU5lUm0yakNqNVJTQjVZR1V3VFNS NC91dGlwNVJuc2EzU04zRlBFcU42VjVKQnIycFE5TGtzUDhBYUdhMFlmRmQ0aWdPaU1mWHBTc0I2 VDhoNzBiVjdOWERSZUx3TWI0WDl5RFY2THhaYUZnQzdMbnVWcFdBNmtvMlB2QTFFYmZQT3hEOUt5 SXZFZG01QUZ3bVQ3MWRqMWFHVGdTS1QvdlVBWFVhNHQrWXBiaUkvd0RUT1ZoVnlIeEJybHQvcXRX dlY5bWZkL01WbUxmeG4rTDlha0YwaDcwV0Ezb2ZIWGlTSC9tSVJ5ZjlkWUFmNVZlaStKV3R4NDh5 MnNKUjlHV3VWODZOdlNqOXkzWVVXQTdlTDRwWEEvMTJqeHQvMXp1UDhSVjJMNHBXSi8xMmxYaWY3 aFZ2NjE1MzVjUjdmclNlUkdlNUZLeUE5UWorSm5oOS93RFdMZXhmNzBCUDhxdHgvRUx3dEoxMUx5 Lyt1a2JML1N2SS9zNDdTRVVodDIvNTZmblJaRFBhWXZHSGh1YjdtdFdmUFl5WXE3RnJXa3pmNnJV clIvcE10ZUROYUZ1dmx0OVJVVGFlbmVHSS9nS0xBZlE2WE51LzNKNG0ramcxS05wNk5YemlMRUww aHgvdXRqK3RTTEhjUmZjbHUwLzNKM0g5YUxBZlJlMmt4WHoybDVxY1orVFV0VFQ2WERWT211NjlI OXpYTlNIMWt6L01VV0E5OXdQV2pqMXJ3aGZGZmlXUDd1dlhSLzNrUS8wcVpmRzNpbE9tczUvMzdk VFJZRDNIRkdLOFVYeC80cVQvQUppRnMzKzlhai9HcFYrSTNpa2Y4dHRQYjYyNS93QWFRSHMxRmVP cjhTL0VvNnBwamY4QWJOaC9XcEI4VVBFUTYybW1IL3ZzVUFldllvcnlRZkZMWC84QW9INmNmK0J2 Uy84QUMxTmMvd0NnWnB4Lzdhdi9BSVVBZXRVWXJ5Yi9BSVdwcm4vUUswLy9BTC9OL2hSL3d0WFhQ K2dUcC84QTMrYi9BQXAyQTlaeFM0cnlYL2hhdXVmOUFuVC9BUHYrMytGSC9DMWRjLzZCV24vOS9t L3dvc0I2MWlqRmVTLzhMVDEwL3dETU0wNGY5dFgvQU1LYWZpbDRnN2FmcG8vNEc5SUQxekZHSzhn YjRuK0l6MHRkTFg4SE5SbjRsK0p6MFhURitrVEgrdEFIc2VLTWU5ZU1OOFJ2RlJIL0FCOGFldjB0 ei9qVVRlUHZGamY4eEsyVC9kdFIvalJZRDIzSHZSajNyd3h2R25pcCt1dGxmOXkzUVZDM2lueEsv d0I3WDd6L0FJQ2lyL1NuWUQzcmJSdHI1L2ZXdGRsKy9ybXBuNlM0L2tLZ2U1MUtYbVRVOVRmNjNM VXJBZlF4MnFPVGo4YWllNnRvL3YzRVMvVndLK2VXaGxrKy9KY3YvdnpzZjYwejdCR2VzSVArODJh ZGdQZjVkZDBlSC9XNnBacDlaMXFsTDQwOE13L2YxdXoraXlidjVWNGV0aEd2U0dJZmdLbFcyMjlO aS9RVVdBOWZrK0l2aGFQcHFKay82NXhNMzlLcXlmRTdRVi8xVWQvTC91d1kvblhsdmtuL0FKNlV2 a3JqbHpSWkFlaXkvRk96SCtwMGk4Zi9BSDNWZjYxVGwrS1YwZjhBVTZORXYvWFM0ei9JVnd3ampI ZjlhWEVRUFQ5YUxBZFZMOFNkZWsvMWNPbncvd0RBV2MvenFsTDQzOFNUL3dETVNXTWVrVUNqK2Vh d3ZNaUhvS2FiaU1keFRzSTBaZGMxcTUvMTJyMzdld2wyajlLcE9KSnVaWkpwVDZ5U3MzOHpVSnZV SDhWUnRxQ0RxMzYwV0FzckFxOUVVZmhVb1hIZXNpVFc3Wk01bVFZLzJxcFNlSjdKU1I1NDQ5S0xB ZExrRHZTYjBYdlhHeWVMNE5wS0xJeDlNVlNsOFhTbFQ1Y0dENnMxT3pBNy93QzBJTzlOYTlqWCtL dk5adkV0L0xqYXlKOUJtcU0ycTM4eCtlNmtIKzZkdjhxT1VEMUdiV0xlQmQwa3FJUFZteFdWZCtN OU50c2czU3NRTTRqK2IrVmVadXpOMVluNm1vV1RjUlJZRWR4ZGZFS0wvbDN0cFpQVXNkditOWWR6 NDExYWZIbG1PSC9kWFA4QU9zbU9DTWc1UUdwQmJ4SEkyanBpamxBU1RVTDdVSDIzVjNNNmxzNEo0 ejlLblZkaWhldU9LU0dBUXFWeVQ5YWt4V2tZMkUyTUlwS2VSVGNVeENVMGppbjBoSEZJWkV3cUNS ZHdBOUtzdFVCcVdNcWRLS21aTnpWYWhnaUs4b0NhaFJ1RnpQeDdWb2FiRGxqS2VNWldwdnNFVW0w ajVjZFFCMXE0cUJGQ2dBS08xYVJwdENiRUlxTW1wRFREMXJSaUdVbUtjZXROTklaR3dxRnVLbmJw VmVTb2tCVmxYQnpVZlNwMjRwSW8xTDg4MW1VUTlzMG9Vc2NET2ExVXRvU3cvZHJ6N1ZOYldVVUVt OGZNZjlvVmFwM0Zja2hqOHFCVS9Pa2Z2VXpWQzliYkt4SkV4N1V3MDQwMm9iQVl3cUY2bmFvWDZW TEdWM3FBakJxZDZoWVpOWnNhRW9xeGJ4cXg1R2F0aXppbVhieXBIY1UxQzRGYXh0MW5rTy9PMWVm cldvd0FIRk9qaVdHTUtneDNwcjF0Q1BLaVNGelVUR3BIcUkxTEFRMUV3cVNtTlVzWkN3eFVMVk05 UU4xck5qUWQ2S0FCVnVPTk5vTzJoSzR5cC9uaXRPMXRmS0FmZDFIU25RV2NheWIrdit6Vmw2MWpD eExaQS9GUU1hbmZwVmRxY2dHRTAwaW5HbW5wV1l5TmhVVFZLM1dvbXFXTVNqcFJUazVZQWppa0Ey bFhrZ2Z5NjFNRVhjUGxxN0RiSWt2bUtjWUhTclVSRFlJaEZHY0hJYjFwSElxdzFWbnJSaUltTlJu bW5OVGFnWWg2VkdSejNxUnFqTlNBMmlpaXBHUFduaWlpcVFtT3A2MFVVMEs1UEZWbGFLSzFRRGow eFZDYkhtR2lpbE1aU2I3eHBLS0t4WUQwNlZNdEZGTkFQcFZvb3FrSmt5ZGFuU2lpdElpSndham41 amY2VVVWVEFvbnZWRnFLS3hrVUt2V3Awb29wSUdTclVnb29xMElVZGFtU2lpcVFpZE9sU0NpaXJR RVUvd0J3MW4zUENxUlJSV2N4b3FZNXFSS0tLeUdXRXFZVVVWcWhEaFQxRkZGVllSS2xTaWlpclFE dWxWWnZ2MFVVcE1TM002YmxqVWE5YUtLd2U1WllqTlRMUlJWSVE4VXVLS0tzQndGUFdpaW1oRHNV MWhSUlZDUlZrKzRhcGtjMFVWaklwRGxGU3JSUlNRRHdLZGlpaXE2QUdLVUNpaW1BN0ZKUlJUUWhy Q3E4b29vcVdORVlGUFVVVVZBeDRGT3hSUlZpWVlweTVVNVVrZlNpaW5aQVNwYzNDSEt6U0FqL0FH cW5YVmI2TWpGd3grdEZGRmtDTEVmaUMvVWpMcVIvdTFZVHhSZEwxaVEvUTBVVkxTQW5YeGVWNGVC dW5acW5pOFl3RWZPa2luNlpvb3FiRExjZml1elk4eWxmcXBxWmZGRm1mK1c0SDF5S0tLVmdMRWV2 MmpnYlowNS8ycW5UV2JjNEFtanlmOXFpaWtCTU5SalA4V2FldCtucUtLS0FIQzlqL3ZVNFhrZnJS UlFBOFhDTjNwMjlEM0ZGRkFCbU0vM1RTWWgvdXIrVkZGTUEyd24rRmZ5bzJRLzNGb29vQVR5NGY3 aTBlWEIvZFdpaWdCUExnL3VMUjVjSDkwVVVVZ0R5NFA3by9PbDh1RCs2S0tLQURaQi9kRkcySCs2 dEZGQUFGaEg4SzB1SXV5citWRkZNQmYzUTdMK1ZHNk1mM1IrRkZGSUJwbWpIcFNmYWtIZWlpbUEz N1loL2lwcHZVSDhWRkZJQ0p0VGhWdHBkZDNwbm1odFJqSDhRRkZGTUN1ZGF0aC95MmovNzZGUXll SWJTTVpOd25wdzJhS0tMQVYyOFQyWS81YkQ4QWFxdDR0dHYrbW41VVVVMGd1VjVQRnlaK1NGMkhx VGlxc3ZpMllqOTNCZy83VFVVVVdRRlYvRk44d0lWSTF6MzVxdC93a0dwT2NHWUQ2S0tLS0xCY2Fk UXZHNjNNdjhBMzFVRFNTTVNXa1lrK3JVVVZkaFhFQW9Jb29waUc0b3hSUlFNS1lhS0tsZ1J0VE1j OUtLS2tDZUVkYW5RZk5SUlZvQ1RGQkZGRld0aERTS2JpaWlwWUJpa1BTaWlraGpHcUFpaWlwWTBN QTVxNUFQa05GRkMzQXV4RDVSVDhVVVZ2RWdZYWpORkZUTGNZMmtORkZJcXhFM1NvWk9sRkZReEVE RE5MR01FVVVWSFVacFJmZUZXL3BSUlc4ZGlHSTFRdlJSVEJFSnB0RkZRTWExUXZSUlVzWlhhbzZL S3pZMFQyMytzL0N0R0RGRkZheEZJc0dvbm9vclFSQTFSRVVVVm1BMGltTlJSVXNaQzlRc09UUlJX YkdoT2xYSWZ1TG1paW5EY1pveC9kRkszU2lpdWdnZ2s0cUJoUlJVTVpHZldrUFNpaW9zTWlhb1c2 MFVWREFLZEg5OGRhS0tRMldQNHhWOWVsRkZieEpZTjNxczlGRkVnSUdwdmFpaW9HSWVsUms4MFVW TEEvOWs9DQpURUw7VFlQRT1DRUxMOjA4MTI3MTExMTE1NQ0KVVJMOmh0dHA6Ly9wYW5jYS5ibG9n c3BvdC5jb20ucGFuY2Eud29yZHByZXNzLmNvbQ0KWC1SSU0tUElOOjJBRTNGNEM0DQpFTkQ6VkNB UkQNCg== --===============1715613763==--



On Wed, Jun 11, 2014 at 6:20 PM, Pedro Felix <= pmhsfelix@gmail.co= m> wrote:
Hi,

In t= he context of RFC 7009, I've a question regarding revocation of access = tokens.

I've a scenario where the revocation of an access t= oken may have different behaviors

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

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

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

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

I don't get it.

If you send the refresh token for revocation, then the access toke= n should also be revoked (as it's issued from the refresh token; you ca= n just consider the access token returned by the token endpoint as issued f= rom the refresh token returned at the same time) .
If you send the access token for revocation, then only the access toke= n will be revoked.

Did I miss something?


--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
--047d7b34385a9d69c304fe0fd43f-- From nobody Mon Jul 14 02:42:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147E81A0383 for ; Mon, 14 Jul 2014 02:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54ZronM6ZBGB for ; Mon, 14 Jul 2014 02:42:18 -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 CA6B71A0382 for ; Mon, 14 Jul 2014 02:42:17 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MNIAz-1XCyQX0Y2L-006wrf; Mon, 14 Jul 2014 11:42:12 +0200 Message-ID: <53C3A5F2.908@gmx.net> Date: Mon, 14 Jul 2014 11:42:10 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Campbell , John Bradley References: <53BBDF5B.3020904@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA0841@TK5EX14MBXC294.redmond.corp.microsoft.com> <2CAA155D-E87E-4465-9110-C142D7085A56@ve7jtb.com> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XXkAtLTQPmDnuDkmT0XI78svgdJeE3eh9" X-Provags-ID: V03:K0:C9K6oARcPohYX1beiv6vIk9AP2boM4cZOQzmOKJUh3bryYW0TUK CexDZZ8i0pc4f6fMyzhzY9zSspcI0ECTN0JSyuLEW3Szx0SFhIbbgHIv2y6qFYfmwTycRm+ 8H721KjWO3xp383ApuCLyZKXs64zXMxG6IhRwn1i+Qj4GFRYtMirzJLuOGoig0SCocxJMb7 Lp5Enj876IQOUY8UzPssg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kvkVI6unWsuJBmVxl0wwfkchuZg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri 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, 14 Jul 2014 09:42:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XXkAtLTQPmDnuDkmT0XI78svgdJeE3eh9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What about the following text: jwks_uri .... ..... "The public key(s) referenced by jwks_uri (or contained in the jwks) can be used in a variety of use cases. For example, the AS can use the indicated public key to verify a request to the token endpoint that utilizes the JWT assertion profile as described in Section 4.2 of [I-D.ietf-oauth-assertions]. Another use case is for the AS to use the public key of a client to encrypt a symmetric proof-of-possession key sent to the client, as described in Section 4.2 of [I-D.bradley-oauth-pop-key-distribution]." Ciao Hannes On 07/08/2014 09:43 PM, Brian Campbell wrote: > +1 to John's #3. The others could maybe be described in somewhat > abstract terms as examples of those "higher level protocols that use > signing or encryption." >=20 > On Tue, Jul 8, 2014 at 12:33 PM, John Bradley wrote= : >> In Connect these public keys are used to: >> 1 verify the signature of request objects (Signed Requests), something= not in OAuth yet, and part of what the description calls higher level pr= otocols. >> 2 encrypt the responses from the user_info endpoint or id_token (also = not part of OAuth directly at this point) >> >> 3 validate requests to the token endpoint authenticated by the JWT ass= ertion profile I think this is legitimate OAuth use. >> >> Whew for the PoP specs: >> 4 used to encrypt the symmetric proof key in a JWK sent to the client= http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01#p= age-7 >> 5 used to provide a PoP key for the client to the AS as part of regist= ration rather than passing the JWK on each request to the token endpoint.= >> >> So the keys in the JWK can be used a number of ways by the AS. >> >> I think we could reference 3 and 4 as examples to be safe. >> >> John B. >> >> >> On Jul 8, 2014, at 3:04 PM, Mike Jones w= rote: >> >>> Was there specific language that had been discussed to be added for t= his? If not, could someone please create some? >>> >>> Thanks, >>> -- Mike >>> >>> -----Original Message----- >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tscho= fenig >>> Sent: Tuesday, July 08, 2014 5:09 AM >>> To: oauth@ietf.org >>> Subject: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri >>> >>> Hi all, >>> >>> in my earlier review I had noted that the semantic of the fields is u= nderspecified, i.e., it is not clear what these fields are used for. >>> >>> In private conversations I was told that an informal reference to a p= otential use case will be added. I don't see such reference with version = -18. >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --XXkAtLTQPmDnuDkmT0XI78svgdJeE3eh9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTw6XyAAoJEGhJURNOOiAtjLUIAIK3OEVspKM+qU7T46l36fFV kIf8JXuPJp3BaxGjCzfQRvQmmDXtgAGzDfshf2ELX40s8CUPePMxVvxY/+Qh2o0m rB5HggzTca9RYOXJV3i2Zy3yfdQ79p7EZaNuL9mc9TBWPdMTn6/IqW0nS+6AD4ZU qYDAyvDW+LggI4xV0i2kEMKHAcwmoOS6RFVIw7jE3OeWbHroe5zi0+PX6Wl04M9a Q+CXu2mtojI7m0xgWT2Ia/UVb+NUO1Ns7nJBRhv1SCBBcs89Zkc4DkNHzX6hyM+/ KS+CNmMIdKcyT+K8KG0BQkeD6nINin5m15upLgXIz+/weDqAZdIFHA1BVIfM578= =HmSG -----END PGP SIGNATURE----- --XXkAtLTQPmDnuDkmT0XI78svgdJeE3eh9-- From nobody Mon Jul 14 04:25:05 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21A91A03BC for ; Mon, 14 Jul 2014 04:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yCzk5yVUUel for ; Mon, 14 Jul 2014 04: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 5A27A1A03B5 for ; Mon, 14 Jul 2014 04:24:57 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M5Lmp-1WMd4M2S23-00zXAu; Mon, 14 Jul 2014 13:24:53 +0200 Message-ID: <53C3BE02.3040402@gmx.net> Date: Mon, 14 Jul 2014 13:24:50 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Bradley , Michael Jones References: <53BBDFA0.8010306@gmx.net> <53BBE932.6000808@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA07A1@TK5EX14MBXC294.redmond.corp.microsoft.com> <2681D9B8-FE2F-4182-BA27-6C06A427F0AD@ve7jtb.com> In-Reply-To: <2681D9B8-FE2F-4182-BA27-6C06A427F0AD@ve7jtb.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aKkSO7aauQJkaCdBebQNEE4mftk3BUnde" X-Provags-ID: V03:K0:pvuFiygKG42Ju7lzDG+CMoA57Tp2U8YgM+Hi/zW4AoWjQo625S1 7pMB0WnYrg6T7puCxSfedFwVg11xYD/vT20lH8oPbVKjeJYKBxaNZSGkmuWCmv5URj875J3 ojizVImkm5Kyh7a6pu13rJBQrXZu0VTbTDL/JRY9yhdjuYGDL1qUDs7sRcEAN9V8Tb81usN 07cb9BdKs4Jfk4HRScEUg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/C8I_VjdQA8clbW-3j8KFb_iQ9DM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri 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, 14 Jul 2014 11:25:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aKkSO7aauQJkaCdBebQNEE4mftk3BUnde Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Here is the text from the OpenID Connect spec (as provided by Nat): > policy_uri > OPTIONAL. URL that the Relying Party Client provides to the End-User > to read about the how the profile data will be used. The value of > this field MUST point to a valid web page. The OpenID Provider > SHOULD display this URL to the End-User if it is given. If desired, > representation of this Claim in different languages and scripts is > represented as described in Section 2.1 > . Here is the draft -18 text: > policy_uri > URL that points to a human-readable Policy document for the > client. The authorization server SHOULD display this URL to the > end-user if it is given. The policy usually describes how an end- > user's data will be used by the client. The value of this field > MUST point to a valid web page. The value of this field MAY be > internationalized, as described in Section 2.2 . Here is the suggested new text: " policy_uri OPTIONAL. URL that the Deployment Organization provides to the end user to read about the privacy policy. A privacy policy is a statement that describes how the Deployment Organization collects, uses, retains and discloses personal information. The value of this field MUST point to a valid web page. The Deployment Organization SHOULD display this URL to the end user. Information for displaying a privacy policy in different languages and scripts can be found in Section 2.2. " Ciao Hannes On 07/08/2014 09:05 PM, John Bradley wrote: > I am OK with clarifying the description as privacy/data protection > policy. I don't think it needs privacy in the parameter name. > On Jul 8, 2014, at 2:59 PM, Mike Jones > wrote: >=20 >> I agree with Nat=92s assessment. I=92m fine updating the textual >> description of the parameter, but we should not consider breaking >> changes to the parameter names at this point. >> =20 >> Do you have specific wording in mind, Hannes? >> =20 >> -- Mike >> =20 >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Nat Sakim= ura >> *Sent:* Tuesday, July 08, 2014 6:26 AM >> *To:* Hannes Tschofenig >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: policy_uri >> =20 >> I am not against using the term "Privacy Policy" in the description.=20 >> Depending on the jurisdiction and language, direct translation of such= =20 >> can be "Data Protection Policy", "Personal Data Protection Policy", et= c.,=20 >> instead so just dodging it by avoiding the label would be more >> politically neutral,=20 >> but it could be fine after all. =20 >> =20 >> I am not fine with changing the parameter name though.=20 >> Slight variation in the parameter between the specs generally do not >> help the developers.=20 >> =20 >> Nat >> >> =20 >> >> 2014-07-08 21:50 GMT+09:00 Hannes Tschofenig >> >: >> For example, even Facebook calls this stuff "Privacy Policy URL". >> >> On 07/08/2014 02:43 PM, Nat Sakimura wrote: >> > policy_uri came down from OpenID Connect Dynamic Client Registraiton= 1.0 >> > [1]. >> > >> > It goes: >> > >> > policy_uri >> > OPTIONAL. URL that the Relying Party Client provides to the End-= User >> > to read about the how the profile data will be used. The value o= f >> > this field MUST point to a valid web page. The OpenID Provider >> > SHOULD display this URL to the End-User if it is given. If desir= ed, >> > representation of this Claim in different languages and scripts = is >> > represented as described in Section 2.1 >> > =20 >> . >> > >> > It is clearly privacy related. In fact, it used to be a part of Open= ID >> > Connect Core in which the RP had to send it to obtain the permission= =2E It >> > is optional only because in certain enterprise type setting, it is >> > unnecessary. In the consumer case, I regard it as essential. In any >> > case, this is something a trust framework should set as its rule, an= d >> > not the protocol itself. >> > >> > The draft -18 text goes: >> > >> > policy_uri >> > URL that points to a human-readable Policy document for the >> > client. The authorization server SHOULD display this URL to t= he >> > end-user if it is given. The policy usually describes how an = end- >> > user's data will be used by the client. The value of this fie= ld >> > MUST point to a valid web page. The value of this field MAY b= e >> > internationalized, as described in Section 2.2 >> . >> > >> > >> > It has been converted to be a bit vague. I would +1 to tighten it up= =2E >> > Note that there is tos_uri to describe the Terms of Service by the >> > client and poicy_uri is not intended for this purpose but only for t= he >> > service/client's privacy policy. >> > >> > BTW, I just found that a lot of text are more or less the duplicate = or >> > re-statement of [1]. IMHO, it should try to refer the original docum= ent >> > where possible as it is a referable standard, and put [1] in the >> > Reference section as well. >> > >> > Best, >> > >> > Nat >> > >> > [1] http://openid.net/specs/openid-connect-registration-1_0.html >> > >> > >> > 2014-07-08 21:10 GMT+09:00 Hannes Tschofenig >> >> > = >>: >> > >> > Hi all, >> > >> > two earlier reviews I have noticed that the policy_uri meta-data= >> > attribute is not correctly specified. I offered a suggestion and= >> in both >> > cases my request was ignored. >> > >> > Maybe there is a reason to reject my request but I am uncertain >> about >> > the relationship with another meta-data attribute, the >> terms-of-service >> > attribute. >> > >> > Here is what I said in my last review: >> > http://www.ietf.org/mail-archive/web/oauth/current/msg12879.html= >> > >> > " >> > policy_uri: In my previous review I argued that the right >> terminology >> > here is privacy notice and you can even re-use the IAPP terminol= ogy. >> > Unless the policy URI has nothing to do with privacy I would >> prefer this >> > terminology change. If you disagree I would prefer to have a >> > description about what policy means in this context. >> > " >> > >> > Could you guys explain? >> > >> > Ciao >> > Hannes >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org > > >> >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > >> > -- >> > Nat Sakimura (=3Dnat) >> > Chairman, OpenID Foundation >> > http://nat.sakimura.org/ >> > @_nat_en >> >> >> >> =20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --aKkSO7aauQJkaCdBebQNEE4mftk3BUnde Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTw74CAAoJEGhJURNOOiAt//UH/2q44UXpq2ojVQbFIUlzuS1J YCoh0tBbfXgf82Ka8hVsgmsbQEbfWqs1BSaJ04LWegyGtkRBdlLSj3TTuU47sWP9 Ljs3lftnW/d3pa8OdUfQUQs5rbioD8Ebv4Yf8iETGSMYwurAEMtDL92Ju/nWPLgF AoG/5J/SMEKdEcarcTqWb/dg+akO8p6YPLc9YXMD3OzJWLl+sl2u1NSicb1l5kQ4 EH9QEHlywfiMmKdB61iamHPYWt8jODdAJxpu/odCikVx9/kssqDaI44uyvRoVljA tmbYUaYoWkU8NoZr83LPVT7B5umhjO0DoL1AOVEigzmlQppML05khFrolf+3iUo= =li6F -----END PGP SIGNATURE----- --aKkSO7aauQJkaCdBebQNEE4mftk3BUnde-- From nobody Mon Jul 14 06:47:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F751A058E for ; Mon, 14 Jul 2014 06:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR1NWTNDKUOA for ; Mon, 14 Jul 2014 06:47:39 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFE81A0545 for ; Mon, 14 Jul 2014 06:47:38 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0ML7NR-1X6PUH0apN-000NHu for ; Mon, 14 Jul 2014 15:47:36 +0200 Message-ID: <53C3DF76.1030902@gmx.net> Date: Mon, 14 Jul 2014 15:47:34 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="H4heGLl6IfMXbtlOo5AHorUtVA9e3Ieef" X-Provags-ID: V03:K0:HmbVKCOy7sYBwiOzNGoxCJMdiR6MXNmldfzROslon1kRzMkPUms wfIf8yRbluFEqjQA79EaP8NkC8s16U527sno+8PrjobsJOpLdXYhPIJUvIOxzjhZdwFtIAY hyf2QCkgedR6nR/EqTlghpZypvb0JXmIxluQrVqKcUd3CiQGF+e08Hy1I3RwvJwLXz4FtPo vknyd2d6/PizDQ2ymjFFw== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/omUUvPFE5mJIgOdwt7Cy5dyQatI Subject: [OAUTH-WG] Dynamic Client Registration: Summary 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, 14 Jul 2014 13:47:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H4heGLl6IfMXbtlOo5AHorUtVA9e3Ieef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here is a short summary of the recent conversations regarding the dynamic client registration draft. In a nutshell, we will have to put the document on the agenda for the meeting. Items discussed on the list: * IPR confirmation Include a statement indicating that this specification is a derivative work from the OpenID Connect Dynamic Registration specification, see http://www.ietf.org/mail-archive/web/oauth/current/msg13081.html Btw, only Maciej's confirmation is missing. * Update of the IANA consideration section - change controller: http://www.ietf.org/mail-archive/web/oauth/current/msg13049.html (a plain nit) - application_type: http://www.ietf.org/mail-archive/web/oauth/current/msg13054.html (pending on the issue below) * jwks / jwks_uri Add clarifying text as discussed in this email list thread (after discussion): http://www.ietf.org/mail-archive/web/oauth/current/msg13052.html * policy_uri Add clarifying text as discussed in this email list thread (after discussion): http://www.ietf.org/mail-archive/web/oauth/current/msg13053.html * application_type Discussion raised triggered on the mailing list (see http://www.ietf.org/mail-archive/web/oauth/current/msg13054.html). Justin raised concerns about the value of this parameter. Suggestion to discuss this issue at the IETF meeting. * client_secret_expires_at Brian raised a concern about the usefulness of the client_secret_expires_at, see http://www.ietf.org/mail-archive/web/oauth/current/msg13095.html Suggestion to discuss this issue at the IETF meeting. Ciao Hannes --H4heGLl6IfMXbtlOo5AHorUtVA9e3Ieef Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTw993AAoJEGhJURNOOiAtOJcIAIuvNjkXWe3ubFubjX/tTTNP 907WyOI9hxkkCDzNmhpzzS9WoofYnQjf2ADC7qzoxrT3BYVjolU6woSEFLOQR3do TZnIMf8ZDMVb3VAsE8b4Eo+oxFDeijTAuJbmFk1teyfNOa5DEWEoY74Fb4rDyyZD f/LNjIbbcSkS5v1w1Fn2MnXC9KiQPQXd3FxmPUK4W7PlJairQzaXsx3+RlI0dxHo yQhhf1/2HcG4XwVoJHnsMJ5B/M6TamCqQhBiXPr68MspI5/vgOxlvUwdlJRjGquF R+ycVCLCJ9iQBaO0ZpUttwD9v2nLxEDBXiDhOOWyUz/ZnGyINoOWAmD7uh3Wta4= =/klg -----END PGP SIGNATURE----- --H4heGLl6IfMXbtlOo5AHorUtVA9e3Ieef-- From nobody Mon Jul 14 08:57:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9811A0AB5; Mon, 14 Jul 2014 08:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8DwHDAPGZaM; Mon, 14 Jul 2014 08:57:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE081A0AB0; Mon, 14 Jul 2014 08:57:17 -0700 (PDT) Received: from DM2PR03CA010.namprd03.prod.outlook.com (10.141.52.158) by BL2PR03MB097.namprd03.prod.outlook.com (10.255.230.15) with Microsoft SMTP Server (TLS) id 15.0.985.8; Mon, 14 Jul 2014 15:57:15 +0000 Received: from BN1AFFO11FD058.protection.gbl (2a01:111:f400:7c10::154) by DM2PR03CA010.outlook.office365.com (2a01:111:e400:2414::30) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Mon, 14 Jul 2014 15:57:14 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD058.mail.protection.outlook.com (10.58.53.73) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Mon, 14 Jul 2014 15:57:14 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0195.002; Mon, 14 Jul 2014 15:56:36 +0000 From: Mike Jones To: "jose@ietf.org" , "oauth@ietf.org" , "scim@ietf.org" Thread-Topic: OpenID Meeting at IETF 90 Thread-Index: Ac+ffDHCYP2TSxQERm6q/OBVg43Xpw== Date: Mon, 14 Jul 2014 15:56:34 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA8D1D@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADA8D1DTK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(448002)(199002)(189002)(85326001)(66066001)(15975445006)(229853001)(19300405004)(6806004)(99396002)(19625215002)(86612001)(77982001)(55846006)(107886001)(104016003)(33656002)(83072002)(107046002)(85306003)(92566001)(81542001)(86362001)(64706001)(80022001)(50986999)(87936001)(2656002)(79102001)(4396001)(97736001)(31966008)(85852003)(84676001)(84326002)(15202345003)(71186001)(20776003)(512954002)(74502001)(74662001)(81342001)(16236675004)(19580395003)(68736004)(83322001)(76482001)(81156004)(77096002)(26826002)(106466001)(92726001)(2201001)(46102001)(69596002)(44976005)(54356999)(95666004)(21056001)(19617315012); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB097; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02723F29C4 Received-SPF: PermError (: domain of microsoft.com used an invalid SPF mechanism) Authentication-Results: spf=permerror (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/D-2MUo2UQzTwhcy0jSb5zjsguWc Subject: [OAUTH-WG] OpenID Meeting at IETF 90 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, 14 Jul 2014 15:57:20 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADA8D1DTK5EX14MBXC294r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There will be an OpenID meeting at IETF 90 on Sunday from 1-4. If you're i= nterested, please register at http://openid-ietf-90.eventbrite.com/. -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439ADA8D1DTK5EX14MBXC294r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There will be an OpenID m= eeting at IETF 90 on Sunday from 1-4.  If you’re interested, ple= ase register at http://openid-ietf= -90.eventbrite.com/.

 <= /p>

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

 <= /p>

--_000_4E1F6AAD24975D4BA5B16804296739439ADA8D1DTK5EX14MBXC294r_-- From nobody Mon Jul 14 09:17:45 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778F41A0AE1 for ; Mon, 14 Jul 2014 09:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8qcqiX1t6O3 for ; Mon, 14 Jul 2014 09:17:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632C11A0ADB for ; Mon, 14 Jul 2014 09:17:28 -0700 (PDT) Received: from BN3PR0301CA0065.namprd03.prod.outlook.com (25.160.152.161) by BL2PR03MB259.namprd03.prod.outlook.com (10.255.231.20) with Microsoft SMTP Server (TLS) id 15.0.974.11; Mon, 14 Jul 2014 16:17:26 +0000 Received: from BY2FFO11FD037.protection.gbl (2a01:111:f400:7c0c::153) by BN3PR0301CA0065.outlook.office365.com (2a01:111:e400:401e::33) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Mon, 14 Jul 2014 16:17:26 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD037.mail.protection.outlook.com (10.1.14.222) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Mon, 14 Jul 2014 16:17:25 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Mon, 14 Jul 2014 16:16:48 +0000 From: Mike Jones To: Hannes Tschofenig , Brian Campbell , John Bradley Thread-Topic: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri Thread-Index: AQHPmqVztwmu7slI2ES6e+cx7tPPAZuWiUVwgAAIbYCAAALJgIAIxf4AgABtOkA= Date: Mon, 14 Jul 2014 16:16:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA8D92@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53BBDF5B.3020904@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA0841@TK5EX14MBXC294.redmond.corp.microsoft.com> <2CAA155D-E87E-4465-9110-C142D7085A56@ve7jtb.com> <53C3A5F2.908@gmx.net> In-Reply-To: <53C3A5F2.908@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(479174003)(377454003)(53754006)(55885003)(164054003)(189002)(24454002)(199002)(51704005)(13464003)(80022001)(81542001)(66066001)(50466002)(81342001)(26826002)(77096002)(95666004)(4396001)(99396002)(97736001)(47776003)(97756001)(76176999)(23726002)(93886003)(64706001)(20776003)(50986999)(54356999)(85306003)(74502001)(2656002)(107046002)(87936001)(84676001)(33656002)(15202345003)(15975445006)(106116001)(106466001)(46102001)(46406003)(21056001)(81156004)(86362001)(6806004)(85852003)(76482001)(44976005)(104016003)(83072002)(74662001)(92726001)(83322001)(68736004)(31966008)(19580405001)(92566001)(55846006)(69596002)(19580395003)(77982001)(86612001)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB259; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02723F29C4 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/m1bf1DrzvB9Nrxc9f20Fm0OvXKg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri 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, 14 Jul 2014 16:17:43 -0000 I'd rather that we stayed with working group drafts in the examples. So I = would counter-propose the following text: "The public key(s) referenced by "jwks_uri" (or contained in the "jwks") ca= n be used in a variety of use cases. For example, the signature of a JWT [I= -D.ietf-json-web-token] signed by the client can be verified by the authori= zation server using these keys. Another example is that the authorization = server can use the indicated public keys to verify a request to the token e= ndpoint that utilizes the JWT assertion profile as described in Section 4.2= of [I-D.ietf-oauth-assertions]." -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, July 14, 2014 2:42 AM To: Brian Campbell; John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri What about the following text: jwks_uri .... ..... "The public key(s) referenced by jwks_uri (or contained in the jwks) can be= used in a variety of use cases. For example, the AS can use the indicated = public key to verify a request to the token endpoint that utilizes the JWT = assertion profile as described in Section 4.2 of [I-D.ietf-oauth-assertions= ]. Another use case is for the AS to use the public key of a client to encr= ypt a symmetric proof-of-possession key sent to the client, as described in= Section 4.2 of [I-D.bradley-oauth-pop-key-distribution]." Ciao Hannes On 07/08/2014 09:43 PM, Brian Campbell wrote: > +1 to John's #3. The others could maybe be described in somewhat > abstract terms as examples of those "higher level protocols that use=20 > signing or encryption." >=20 > On Tue, Jul 8, 2014 at 12:33 PM, John Bradley wrote: >> In Connect these public keys are used to: >> 1 verify the signature of request objects (Signed Requests), something n= ot in OAuth yet, and part of what the description calls higher level protoc= ols. >> 2 encrypt the responses from the user_info endpoint or id_token (also=20 >> not part of OAuth directly at this point) >> >> 3 validate requests to the token endpoint authenticated by the JWT asser= tion profile I think this is legitimate OAuth use. >> >> Whew for the PoP specs: >> 4 used to encrypt the symmetric proof key in a JWK sent to the=20 >> client=20 >> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-0 >> 1#page-7 >> 5 used to provide a PoP key for the client to the AS as part of registra= tion rather than passing the JWK on each request to the token endpoint. >> >> So the keys in the JWK can be used a number of ways by the AS. >> >> I think we could reference 3 and 4 as examples to be safe. >> >> John B. >> >> >> On Jul 8, 2014, at 3:04 PM, Mike Jones wro= te: >> >>> Was there specific language that had been discussed to be added for thi= s? If not, could someone please create some? >>> >>> Thanks, >>> -- Mike >>> >>> -----Original Message----- >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes=20 >>> Tschofenig >>> Sent: Tuesday, July 08, 2014 5:09 AM >>> To: oauth@ietf.org >>> Subject: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri >>> >>> Hi all, >>> >>> in my earlier review I had noted that the semantic of the fields is und= erspecified, i.e., it is not clear what these fields are used for. >>> >>> In private conversations I was told that an informal reference to a pot= ential use case will be added. I don't see such reference with version -18. >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Mon Jul 14 09:19:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B501A0AC2 for ; Mon, 14 Jul 2014 09:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dP7VqsESNa_r for ; Mon, 14 Jul 2014 09:18:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F391B1A0AC8 for ; Mon, 14 Jul 2014 09:18:55 -0700 (PDT) Received: from BN3PR0301CA0082.namprd03.prod.outlook.com (25.160.152.178) by BL2PR03MB340.namprd03.prod.outlook.com (10.141.68.24) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 14 Jul 2014 16:18:54 +0000 Received: from BN1AFFO11FD059.protection.gbl (2a01:111:f400:7c10::133) by BN3PR0301CA0082.outlook.office365.com (2a01:111:e400:401e::50) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Mon, 14 Jul 2014 16:18:54 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD059.mail.protection.outlook.com (10.58.53.74) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Mon, 14 Jul 2014 16:18:54 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0195.002; Mon, 14 Jul 2014 16:18:12 +0000 From: Mike Jones To: Hannes Tschofenig , John Bradley Thread-Topic: [OAUTH-WG] Dynamic Client Registration: policy_uri Thread-Index: AQHPmqWY5AtEKQRGw0O3kUVR/CP4H5uWH0WAgAAB9gCAAAmsgIAAXNkAgAACIgCACO1GAIAAUcuw Date: Mon, 14 Jul 2014 16:18:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA8DBE@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53BBDFA0.8010306@gmx.net> <53BBE932.6000808@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA07A1@TK5EX14MBXC294.redmond.corp.microsoft.com> <2681D9B8-FE2F-4182-BA27-6C06A427F0AD@ve7jtb.com> <53C3BE02.3040402@gmx.net> In-Reply-To: <53C3BE02.3040402@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(377424004)(55885003)(199002)(24454002)(15454003)(51704005)(13464003)(189002)(53754006)(479174003)(377454003)(76176999)(31966008)(69596002)(85852003)(46406003)(50466002)(46102001)(15202345003)(15395725005)(97736001)(6806004)(77982001)(83322001)(80022001)(50986999)(19580405001)(74502001)(104016003)(81542001)(44976005)(81342001)(33656002)(83072002)(54356999)(307094003)(84676001)(74662001)(106116001)(55846006)(66066001)(97756001)(23726002)(68736004)(92566001)(87936001)(77096002)(20776003)(26826002)(93886003)(47776003)(92726001)(86362001)(107046002)(79102001)(2656002)(64706001)(106466001)(19580395003)(15975445006)(76482001)(99396002)(4396001)(81156004)(21056001)(86612001)(85306003)(95666004); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB340; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02723F29C4 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/90AjIfWsJ8UiT0u10-LvFgIglSk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri 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, 14 Jul 2014 16:18:59 -0000 Fine with me. (I might change "the privacy policy" to "the site's privacy = policy".) -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Monday, July 14, 2014 4:25 AM To: John Bradley; Mike Jones Cc: Nat Sakimura; oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri Here is the text from the OpenID Connect spec (as provided by Nat): > policy_uri > OPTIONAL. URL that the Relying Party Client provides to the End-User > to read about the how the profile data will be used. The value of > this field MUST point to a valid web page. The OpenID Provider > SHOULD display this URL to the End-User if it is given. If desired, > representation of this Claim in different languages and scripts is > represented as described in Section 2.1 > . Here is the draft -18 text: > policy_uri > URL that points to a human-readable Policy document for the > client. The authorization server SHOULD display this URL to the > end-user if it is given. The policy usually describes how an end- > user's data will be used by the client. The value of this field > MUST point to a valid web page. The value of this field MAY be > internationalized, as described in Section 2.2 . Here is the suggested new text: " policy_uri OPTIONAL. URL that the Deployment Organization provides to the end user to read about the privacy policy. A privacy policy is a statement that describes how the Deployment Organization collects, uses, retains and discloses personal information. The value of this field MUST point to a valid web page. The Deployment Organization SHOULD display this URL to the end user. Information for displaying a privacy policy in different languages and scripts can be found in Section 2.2. " Ciao Hannes On 07/08/2014 09:05 PM, John Bradley wrote: > I am OK with clarifying the description as privacy/data protection > policy. I don't think it needs privacy in the parameter name. > On Jul 8, 2014, at 2:59 PM, Mike Jones > wrote: >=20 >> I agree with Nat's assessment. I'm fine updating the textual=20 >> description of the parameter, but we should not consider breaking=20 >> changes to the parameter names at this point. >> =20 >> Do you have specific wording in mind, Hannes? >> =20 >> -- Mike >> =20 >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Nat=20 >> Sakimura >> *Sent:* Tuesday, July 08, 2014 6:26 AM >> *To:* Hannes Tschofenig >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: policy_uri >> =20 >> I am not against using the term "Privacy Policy" in the description.=20 >> Depending on the jurisdiction and language, direct translation of=20 >> such can be "Data Protection Policy", "Personal Data Protection=20 >> Policy", etc., instead so just dodging it by avoiding the label would=20 >> be more politically neutral, but it could be fine after all. >> =20 >> I am not fine with changing the parameter name though.=20 >> Slight variation in the parameter between the specs generally do not=20 >> help the developers. >> =20 >> Nat >> >> =20 >> >> 2014-07-08 21:50 GMT+09:00 Hannes Tschofenig=20 >> >: >> For example, even Facebook calls this stuff "Privacy Policy URL". >> >> On 07/08/2014 02:43 PM, Nat Sakimura wrote: >> > policy_uri came down from OpenID Connect Dynamic Client=20 >> > Registraiton 1.0 [1]. >> > >> > It goes: >> > >> > policy_uri >> > OPTIONAL. URL that the Relying Party Client provides to the End-Us= er >> > to read about the how the profile data will be used. The value of >> > this field MUST point to a valid web page. The OpenID Provider >> > SHOULD display this URL to the End-User if it is given. If desired= , >> > representation of this Claim in different languages and scripts is >> > represented as described in Section 2.1 >> > =20 >> . >> > >> > It is clearly privacy related. In fact, it used to be a part of=20 >> > OpenID Connect Core in which the RP had to send it to obtain the=20 >> > permission. It is optional only because in certain enterprise type=20 >> > setting, it is unnecessary. In the consumer case, I regard it as=20 >> > essential. In any case, this is something a trust framework should=20 >> > set as its rule, and not the protocol itself. >> > >> > The draft -18 text goes: >> > >> > policy_uri >> > URL that points to a human-readable Policy document for the >> > client. The authorization server SHOULD display this URL to the >> > end-user if it is given. The policy usually describes how an en= d- >> > user's data will be used by the client. The value of this field >> > MUST point to a valid web page. The value of this field MAY be >> > internationalized, as described in Section 2.2 >> . >> > >> > >> > It has been converted to be a bit vague. I would +1 to tighten it up. >> > Note that there is tos_uri to describe the Terms of Service by the=20 >> > client and poicy_uri is not intended for this purpose but only for=20 >> > the service/client's privacy policy. >> > >> > BTW, I just found that a lot of text are more or less the duplicate=20 >> > or re-statement of [1]. IMHO, it should try to refer the original=20 >> > document where possible as it is a referable standard, and put [1]=20 >> > in the Reference section as well. >> > >> > Best, >> > >> > Nat >> > >> > [1] http://openid.net/specs/openid-connect-registration-1_0.html >> > >> > >> > 2014-07-08 21:10 GMT+09:00 Hannes Tschofenig >> >> > >>= : >> > >> > Hi all, >> > >> > two earlier reviews I have noticed that the policy_uri meta-data >> > attribute is not correctly specified. I offered a suggestion=20 >> > and >> in both >> > cases my request was ignored. >> > >> > Maybe there is a reason to reject my request but I am uncertain >> about >> > the relationship with another meta-data attribute, the >> terms-of-service >> > attribute. >> > >> > Here is what I said in my last review: >> > =20 >> > http://www.ietf.org/mail-archive/web/oauth/current/msg12879.html >> > >> > " >> > policy_uri: In my previous review I argued that the right >> terminology >> > here is privacy notice and you can even re-use the IAPP terminolog= y. >> > Unless the policy URI has nothing to do with privacy I would >> prefer this >> > terminology change. If you disagree I would prefer to have a >> > description about what policy means in this context. >> > " >> > >> > Could you guys explain? >> > >> > Ciao >> > Hannes >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org > > >> >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > >> > -- >> > Nat Sakimura (=3Dnat) >> > Chairman, OpenID Foundation >> > http://nat.sakimura.org/ >> > @_nat_en >> >> >> >> =20 >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Mon Jul 14 10:45:20 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900221A8BAF for ; Mon, 14 Jul 2014 10:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39LuN0Lnrndn for ; Mon, 14 Jul 2014 10:45:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84CC31A0AF9 for ; Mon, 14 Jul 2014 10:45:17 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LsCdj-1WQur506Jz-013yzl; Mon, 14 Jul 2014 19:45:08 +0200 Message-ID: <53C41721.7020607@gmx.net> Date: Mon, 14 Jul 2014 19:45:05 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mike Jones , Brian Campbell , John Bradley References: <53BBDF5B.3020904@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA0841@TK5EX14MBXC294.redmond.corp.microsoft.com> <2CAA155D-E87E-4465-9110-C142D7085A56@ve7jtb.com> <53C3A5F2.908@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA8D92@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA8D92@TK5EX14MBXC294.redmond.corp.microsoft.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KxlREa47Ntv2OhNsAEPdfn39DLkKFP3bV" X-Provags-ID: V03:K0:22ep6RfQpUDUwu12F/Dqlp/La4H3z6M4QDgv+kJLaznzLAsKY94 zDAb87m8tbBRkaPDcvpWGJ6gBVYJHU3wG0Z6tELQqgCq/FZisbtvHV4BK9xjPKMjOa7Frk6 0zyOr7NDiQNf9Y89JGeGBVLyZMJxf3MbWTo6jpLa5anCk65gfJZQ3hSAPTD1q/km636pej+ qOa2Ou+Ih5c+J4zOG8edg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5vvbfB7ZGqX0Pi79WNHOdHcI1t4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri 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, 14 Jul 2014 17:45:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KxlREa47Ntv2OhNsAEPdfn39DLkKFP3bV Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mike, sticking with working group document is fine. However, the first example does not make sense to me. [maybe my brain is a bit empty at the moment] When is a JWT signed by the client and then sent to the Authorization Server other than in the Assertion draft that I mention in the second example? Ciao Hannes On 07/14/2014 06:16 PM, Mike Jones wrote: > I'd rather that we stayed with working group drafts in the examples. > So I would counter-propose the following text: >=20 > "The public key(s) referenced by "jwks_uri" (or contained in the > "jwks") can be used in a variety of use cases. For example, the > signature of a JWT [I-D.ietf-json-web-token] signed by the client can > be verified by the authorization server using these keys. Another > example is that the authorization server can use the indicated public > keys to verify a request to the token endpoint that utilizes the JWT > assertion profile as described in Section 4.2 of > [I-D.ietf-oauth-assertions]." >=20 > -- Mike >=20 > -----Original Message----- From: OAuth > [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: > Monday, July 14, 2014 2:42 AM To: Brian Campbell; John Bradley Cc: > oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration: > jwks / jwks_uri >=20 > What about the following text: >=20 > jwks_uri >=20 > .... http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18> ..... >=20 > "The public key(s) referenced by jwks_uri (or contained in the jwks) > can be used in a variety of use cases. For example, the AS can use > the indicated public key to verify a request to the token endpoint > that utilizes the JWT assertion profile as described in Section 4.2 > of [I-D.ietf-oauth-assertions]. Another use case is for the AS to use > the public key of a client to encrypt a symmetric proof-of-possession > key sent to the client, as described in Section 4.2 of > [I-D.bradley-oauth-pop-key-distribution]." >=20 >=20 > Ciao Hannes >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 07/08/2014 09:43 PM, Brian Campbell wrote: >> +1 to John's #3. The others could maybe be described in somewhat=20 >> abstract terms as examples of those "higher level protocols that >> use signing or encryption." >>=20 >> On Tue, Jul 8, 2014 at 12:33 PM, John Bradley >> wrote: >>> In Connect these public keys are used to: 1 verify the signature >>> of request objects (Signed Requests), something not in OAuth yet, >>> and part of what the description calls higher level protocols. 2 >>> encrypt the responses from the user_info endpoint or id_token >>> (also not part of OAuth directly at this point) >>>=20 >>> 3 validate requests to the token endpoint authenticated by the >>> JWT assertion profile I think this is legitimate OAuth use. >>>=20 >>> Whew for the PoP specs: 4 used to encrypt the symmetric proof key >>> in a JWK sent to the client=20 >>> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-0= >>> >>>=20 1#page-7 >>> 5 used to provide a PoP key for the client to the AS as part of >>> registration rather than passing the JWK on each request to the >>> token endpoint. >>>=20 >>> So the keys in the JWK can be used a number of ways by the AS. >>>=20 >>> I think we could reference 3 and 4 as examples to be safe. >>>=20 >>> John B. >>>=20 >>>=20 >>> On Jul 8, 2014, at 3:04 PM, Mike Jones >>> wrote: >>>=20 >>>> Was there specific language that had been discussed to be added >>>> for this? If not, could someone please create some? >>>>=20 >>>> Thanks, -- Mike >>>>=20 >>>> -----Original Message----- From: OAuth >>>> [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig=20 >>>> Sent: Tuesday, July 08, 2014 5:09 AM To: oauth@ietf.org=20 >>>> Subject: [OAUTH-WG] Dynamic Client Registration: jwks / >>>> jwks_uri >>>>=20 >>>> Hi all, >>>>=20 >>>> in my earlier review I had noted that the semantic of the >>>> fields is underspecified, i.e., it is not clear what these >>>> fields are used for. >>>>=20 >>>> In private conversations I was told that an informal reference >>>> to a potential use case will be added. I don't see such >>>> reference with version -18. >>>>=20 >>>> Ciao Hannes >>>>=20 >>>> _______________________________________________ OAuth mailing >>>> list OAuth@ietf.org=20 >>>> 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=20 >> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --KxlREa47Ntv2OhNsAEPdfn39DLkKFP3bV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTxBchAAoJEGhJURNOOiAtgukH/3fYmBV3VV2s2x5E+sbKBJqu Cko/fq6dQtQsRAyYJJywpyPs4I9cz9zz2mMclFi/c9M8/qpb6bzXHy/veHtoMkqp rj8WeA56hOj1YHOEqd1KuYeqIqV1s7BVwUgEAi8qVomJ6h4ytRHzfXJt9laAFuZ0 bfsEdRrbXIeOSytDLNR9EAwy/qpiEfNX6oQSGJ2EnDdHHrG88A8hC71AckC/4MZg 9XGsK7Zy9z8YDlDof8ZMzt8HcQ4wNZcjhNDGlnT6HOI7RnGrtrEVc5IPkzy6lB3D WLu0ycUMX5Mht6IdSMFCNnhlTG0X5wIKxdeXuEY5ozbuhE4FBAqYEPB9Mwt+gB8= =BlTU -----END PGP SIGNATURE----- --KxlREa47Ntv2OhNsAEPdfn39DLkKFP3bV-- From nobody Mon Jul 14 10:56:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20571A8BB7 for ; Mon, 14 Jul 2014 10:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeHVKrZLC6d3 for ; Mon, 14 Jul 2014 10:56:00 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6441A854D for ; Mon, 14 Jul 2014 10:56:00 -0700 (PDT) Received: from BLUPR03CA030.namprd03.prod.outlook.com (10.141.30.23) by DM2PR03MB351.namprd03.prod.outlook.com (10.141.54.22) with Microsoft SMTP Server (TLS) id 15.0.980.8; Mon, 14 Jul 2014 17:55:57 +0000 Received: from BL2FFO11FD045.protection.gbl (2a01:111:f400:7c09::130) by BLUPR03CA030.outlook.office365.com (2a01:111:e400:879::23) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Mon, 14 Jul 2014 17:55:57 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD045.mail.protection.outlook.com (10.173.161.207) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Mon, 14 Jul 2014 17:55:56 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0195.002; Mon, 14 Jul 2014 17:55:46 +0000 From: Mike Jones To: Hannes Tschofenig , Brian Campbell , John Bradley Thread-Topic: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri Thread-Index: AQHPmqVztwmu7slI2ES6e+cx7tPPAZuWiUVwgAAIbYCAAALJgIAIxf4AgABtOkCAABmygIAAAC0A Date: Mon, 14 Jul 2014 17:55:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA9143@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53BBDF5B.3020904@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA0841@TK5EX14MBXC294.redmond.corp.microsoft.com> <2CAA155D-E87E-4465-9110-C142D7085A56@ve7jtb.com> <53C3A5F2.908@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA8D92@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C41721.7020607@gmx.net> In-Reply-To: <53C41721.7020607@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(53754006)(55885003)(24454002)(479174003)(377454003)(13464003)(164054003)(51704005)(189002)(199002)(54356999)(69596002)(85852003)(50466002)(31966008)(80022001)(55846006)(6806004)(74502001)(2656002)(84676001)(97756001)(19580395003)(79102001)(97736001)(19580405001)(44976005)(74662001)(99396002)(93886003)(81342001)(86362001)(77096002)(20776003)(104016003)(95666004)(68736004)(47776003)(46406003)(23726002)(21056001)(50986999)(4396001)(106466001)(81156004)(76482001)(77982001)(106116001)(87936001)(66066001)(92726001)(46102001)(26826002)(83072002)(15202345003)(83322001)(92566001)(81542001)(86612001)(15975445006)(76176999)(85306003)(64706001)(107046002)(33656002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR03MB351; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02723F29C4 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lCQM73xg-EP7gfIWniT-RSnjFXk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri 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, 14 Jul 2014 17:56:03 -0000 One example is when used as a signed request to the authorization server, a= s is done in http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05. -- Mike -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Monday, July 14, 2014 10:45 AM To: Mike Jones; Brian Campbell; John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri Hi Mike, sticking with working group document is fine. However, the first example does not make sense to me. [maybe my brain is a bit empty at the moment] When is a JWT signed by the client and then sent to the Authorization Serve= r other than in the Assertion draft that I mention in the second example? Ciao Hannes On 07/14/2014 06:16 PM, Mike Jones wrote: > I'd rather that we stayed with working group drafts in the examples. > So I would counter-propose the following text: >=20 > "The public key(s) referenced by "jwks_uri" (or contained in the > "jwks") can be used in a variety of use cases. For example, the=20 > signature of a JWT [I-D.ietf-json-web-token] signed by the client can=20 > be verified by the authorization server using these keys. Another=20 > example is that the authorization server can use the indicated public=20 > keys to verify a request to the token endpoint that utilizes the JWT=20 > assertion profile as described in Section 4.2 of=20 > [I-D.ietf-oauth-assertions]." >=20 > -- Mike >=20 > -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig Sent: > Monday, July 14, 2014 2:42 AM To: Brian Campbell; John Bradley Cc: > oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration: > jwks / jwks_uri >=20 > What about the following text: >=20 > jwks_uri >=20 > .... http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18> ..... >=20 > "The public key(s) referenced by jwks_uri (or contained in the jwks)=20 > can be used in a variety of use cases. For example, the AS can use the=20 > indicated public key to verify a request to the token endpoint that=20 > utilizes the JWT assertion profile as described in Section 4.2 of=20 > [I-D.ietf-oauth-assertions]. Another use case is for the AS to use the=20 > public key of a client to encrypt a symmetric proof-of-possession key=20 > sent to the client, as described in Section 4.2 of=20 > [I-D.bradley-oauth-pop-key-distribution]." >=20 >=20 > Ciao Hannes >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 07/08/2014 09:43 PM, Brian Campbell wrote: >> +1 to John's #3. The others could maybe be described in somewhat >> abstract terms as examples of those "higher level protocols that use=20 >> signing or encryption." >>=20 >> On Tue, Jul 8, 2014 at 12:33 PM, John Bradley >> wrote: >>> In Connect these public keys are used to: 1 verify the signature of=20 >>> request objects (Signed Requests), something not in OAuth yet, and=20 >>> part of what the description calls higher level protocols. 2 encrypt=20 >>> the responses from the user_info endpoint or id_token (also not part=20 >>> of OAuth directly at this point) >>>=20 >>> 3 validate requests to the token endpoint authenticated by the JWT=20 >>> assertion profile I think this is legitimate OAuth use. >>>=20 >>> Whew for the PoP specs: 4 used to encrypt the symmetric proof key in=20 >>> a JWK sent to the client >>> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution- >>> 0 >>> >>>=20 1#page-7 >>> 5 used to provide a PoP key for the client to the AS as part of=20 >>> registration rather than passing the JWK on each request to the=20 >>> token endpoint. >>>=20 >>> So the keys in the JWK can be used a number of ways by the AS. >>>=20 >>> I think we could reference 3 and 4 as examples to be safe. >>>=20 >>> John B. >>>=20 >>>=20 >>> On Jul 8, 2014, at 3:04 PM, Mike Jones =20 >>> wrote: >>>=20 >>>> Was there specific language that had been discussed to be added for=20 >>>> this? If not, could someone please create some? >>>>=20 >>>> Thanks, -- Mike >>>>=20 >>>> -----Original Message----- From: OAuth=20 >>>> [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig >>>> Sent: Tuesday, July 08, 2014 5:09 AM To: oauth@ietf.org >>>> Subject: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri >>>>=20 >>>> Hi all, >>>>=20 >>>> in my earlier review I had noted that the semantic of the fields is=20 >>>> underspecified, i.e., it is not clear what these fields are used=20 >>>> for. >>>>=20 >>>> In private conversations I was told that an informal reference to a=20 >>>> potential use case will be added. I don't see such reference with=20 >>>> version -18. >>>>=20 >>>> Ciao Hannes >>>>=20 >>>> _______________________________________________ OAuth mailing list=20 >>>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ OAuth mailing list=20 >>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ OAuth mailing list=20 >> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From nobody Mon Jul 14 10:57:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E5C1AD62A for ; Mon, 14 Jul 2014 10:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgqYTjyiog6Z for ; Mon, 14 Jul 2014 10:57:39 -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 8B1141ABB90 for ; Mon, 14 Jul 2014 10:57:39 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MHnzh-1X87Xz3rx7-003fEY; Mon, 14 Jul 2014 19:57:31 +0200 Message-ID: <53C41A08.7010203@gmx.net> Date: Mon, 14 Jul 2014 19:57:28 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mike Jones , Brian Campbell , John Bradley References: <53BBDF5B.3020904@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA0841@TK5EX14MBXC294.redmond.corp.microsoft.com> <2CAA155D-E87E-4465-9110-C142D7085A56@ve7jtb.com> <53C3A5F2.908@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA8D92@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C41721.7020607@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA9143@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA9143@TK5EX14MBXC294.redmond.corp.microsoft.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Dern3JkVHMQLGrvBcl8cCTMAjuo2vQOcB" X-Provags-ID: V03:K0:YBmvOyGE3yqZLwH3LKkXkB4/jd35R2V579Ccx6eWyLeBUF9L7kh C6rwpzu81+NDwIuX4cxHTEAwXDFxvfMgpJOFEcLMKIo2JlNzWpjYzvpw9RLWV4Z7gnBZ8cm ziDWMUPxi4xPWUYF2gxONYi81l/K6DLInBMgvpCxB8wlxAizM08kUxFBhljPjZ3/yApPTFk mIHxjxbu86QL9wClCQToQ== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TqBu_YWuHzF6f3gUd59mIeCgaos Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri 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, 14 Jul 2014 17:57:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Dern3JkVHMQLGrvBcl8cCTMAjuo2vQOcB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That would then be a reference to an individual draft ;-) On 07/14/2014 07:55 PM, Mike Jones wrote: > One example is when used as a signed request to the authorization serve= r, as is done in http://tools.ietf.org/html/draft-sakimura-oauth-requrl-0= 5. --Dern3JkVHMQLGrvBcl8cCTMAjuo2vQOcB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEbBAEBCgAGBQJTxBoIAAoJEGhJURNOOiAtX/0H91nqj3yJwwgn6T28iKM2Shyi uagTq42QjD44KaChwLc9AwD4Lqy++HIYky3UgYVT1GSV43qJaeb2ydJ6u1oF1tiU ptYHDJyn6YRLp5TSA+r3TE26TTpQgBwBVZpCQJ8EBHUqwIPR/xS9pL/74djYFzuw /HiHkKm89Gc80zegmBNDfqA9otokIeV3GRkZ+4OP8YZTcZEwsTFKx3lktznjD4qK JKf+KDkQDkomDBReSR+yRbslDQO0xO1bMH63mNyVZddTOdizI1hu6fgS9lrTJ/J4 e89o/cIkKrZqzpInUfj2Q44QlLATcVGpPkettykYxf8ejyuRizyEwo7+lHFiWg== =zBzD -----END PGP SIGNATURE----- --Dern3JkVHMQLGrvBcl8cCTMAjuo2vQOcB-- From nobody Mon Jul 14 10:59:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7591AD62A for ; Mon, 14 Jul 2014 10:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCqqlz08KvDI for ; Mon, 14 Jul 2014 10:59:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED611A0B0C for ; Mon, 14 Jul 2014 10:59:13 -0700 (PDT) Received: from BY2PR03CA032.namprd03.prod.outlook.com (10.242.234.153) by BY1PR0301MB1174.namprd03.prod.outlook.com (25.160.195.145) with Microsoft SMTP Server (TLS) id 15.0.985.8; Mon, 14 Jul 2014 17:59:11 +0000 Received: from BN1AFFO11FD039.protection.gbl (2a01:111:f400:7c10::132) by BY2PR03CA032.outlook.office365.com (2a01:111:e400:2c2c::25) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Mon, 14 Jul 2014 17:59:11 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD039.mail.protection.outlook.com (10.58.52.243) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Mon, 14 Jul 2014 17:59:10 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0195.002; Mon, 14 Jul 2014 17:59:02 +0000 From: Mike Jones To: Hannes Tschofenig , Brian Campbell , John Bradley Thread-Topic: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri Thread-Index: AQHPmqVztwmu7slI2ES6e+cx7tPPAZuWiUVwgAAIbYCAAALJgIAIxf4AgABtOkCAABmygIAAAC0AgAADSQCAAAAjIA== Date: Mon, 14 Jul 2014 17:59:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADA9190@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53BBDF5B.3020904@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA0841@TK5EX14MBXC294.redmond.corp.microsoft.com> <2CAA155D-E87E-4465-9110-C142D7085A56@ve7jtb.com> <53C3A5F2.908@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA8D92@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C41721.7020607@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA9143@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C41A08.7010203@gmx.net> In-Reply-To: <53C41A08.7010203@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(979002)(6009001)(438002)(199002)(189002)(13464003)(55885003)(24454002)(377454003)(479174003)(79102001)(46406003)(77096002)(64706001)(76176999)(47776003)(50986999)(20776003)(15975445006)(4396001)(31966008)(104016003)(97756001)(86612001)(54356999)(99396002)(80022001)(84676001)(95666004)(44976005)(69596002)(85306003)(68736004)(106466001)(81156004)(15202345003)(19580405001)(97736001)(19580395003)(106116001)(83322001)(93886003)(81542001)(46102001)(92566001)(81342001)(83072002)(107046002)(85852003)(86362001)(74662001)(87936001)(2656002)(92726001)(21056001)(55846006)(33656002)(66066001)(77982001)(6806004)(50466002)(74502001)(23726002)(76482001)(26826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:BY1PR0301MB1174; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 02723F29C4 Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/czgEC7aZnc4xfPAX6UZ8PRZaJPU Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri 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, 14 Jul 2014 17:59:16 -0000 I'm not suggesting that we reference it. We reference JWT using the langua= ge I already provided. I was just giving you another example of a signed J= WT sent to the authorization server, since you couldn't think of any off th= e top of your head. -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Monday, July 14, 2014 10:57 AM To: Mike Jones; Brian Campbell; John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri That would then be a reference to an individual draft ;-) On 07/14/2014 07:55 PM, Mike Jones wrote: > One example is when used as a signed request to the authorization server,= as is done in http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05. From nobody Mon Jul 14 11:36:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A124A1A0027 for ; Mon, 14 Jul 2014 11:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGqftofEHf-w for ; Mon, 14 Jul 2014 11:36:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C021A002B for ; Mon, 14 Jul 2014 11:36:53 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LtaDM-1WNq3c2mwe-010y8g; Mon, 14 Jul 2014 20:36:44 +0200 Message-ID: <53C4233B.7090403@gmx.net> Date: Mon, 14 Jul 2014 20:36:43 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mike Jones , Brian Campbell , John Bradley References: <53BBDF5B.3020904@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA0841@TK5EX14MBXC294.redmond.corp.microsoft.com> <2CAA155D-E87E-4465-9110-C142D7085A56@ve7jtb.com> <53C3A5F2.908@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA8D92@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C41721.7020607@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA9143@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C41A08.7010203@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA9190@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA9190@TK5EX14MBXC294.redmond.corp.microsoft.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1bU6RW3RlG3lu2jhNrsJS4FdetFB0VO3j" X-Provags-ID: V03:K0:oBMJbwTTv0KMMmmK/hGtdUxlYL4oIUgW3tt9ZHvV9/O8Efxu3iy 6gntiyKZitKwLrdaWjx86XfG1HwqPCY1F9TAfq5DAsRuKnW9yh30VE1iFEN61Tc9bXZUyKB wcjEYFxRThaIaMd1I+i1lIM2vE/injas4zuhvq7SBMJdo+/yeDHENGX43vzw3WCfbWnhXs8 0bWl8Js1a13HYBmQkNrlg== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/i8qN0UamAUrhyXr2Kq0HPj9pHq8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri 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, 14 Jul 2014 18:36:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1bU6RW3RlG3lu2jhNrsJS4FdetFB0VO3j Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mike, there is no problem referencing an individual draft particularly when that reference gives some hint about how the stuff is used (particularly when the referenced document might be a working group draft at the time when the dynamic client registration document gets published as an RFC). In this specific case I haven't even thought about that draft-sakimura-oauth-requrl-05... Ciao Hannes On 07/14/2014 07:59 PM, Mike Jones wrote: > I'm not suggesting that we reference it. We reference JWT using the la= nguage I already provided. I was just giving you another example of a si= gned JWT sent to the authorization server, since you couldn't think of an= y off the top of your head. >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: Monday, July 14, 2014 10:57 AM > To: Mike Jones; Brian Campbell; John Bradley > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri >=20 > That would then be a reference to an individual draft ;-) >=20 > On 07/14/2014 07:55 PM, Mike Jones wrote: >> One example is when used as a signed request to the authorization serv= er, as is done in http://tools.ietf.org/html/draft-sakimura-oauth-requrl-= 05. >=20 --1bU6RW3RlG3lu2jhNrsJS4FdetFB0VO3j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTxCM7AAoJEGhJURNOOiAtHQYH/2GS76bbI7Udk7KgfIChpmp0 Ha0exU50u7/Bn0ehJhyjWLnn7Zq+Y1fH0w+xCXwl0Z5MqlI4/vVAwBL4I+1Cqi6k gAnByVlWUR7vyi/m4xYK3Y8CBYMF1CyXAqctoguJRKPMvS0pomH/99WuLdrM9Kx0 9iMSCI9kYfajZLBa+xL3W8Htqw9TQ2aJ5sYRaGmcgJhBaIpsjcm5uDVEl+LgGNxt wmS39vA5KdFAescAvpUhb0wbTU7J05pEF2fn81+JdcvuLTfWMoP65Ky1MqTcTFlv lrs3Oji634IvrOCI6UgcUS4CHTwmqTnuZR2+orvKT5x3XJ7q9HqQkzO4vfzLOsQ= =fofG -----END PGP SIGNATURE----- --1bU6RW3RlG3lu2jhNrsJS4FdetFB0VO3j-- From nobody Mon Jul 14 13:26:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25061A0AF1 for ; Mon, 14 Jul 2014 13:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMxR5pwjjoap for ; Mon, 14 Jul 2014 13:26:48 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED46A1A0ACE for ; Mon, 14 Jul 2014 13:26:47 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id i8so4104029qcq.34 for ; Mon, 14 Jul 2014 13:26:47 -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=ODmIOfIUTr7jPqSDc8B4BdCFXdbqBoCAdy5ztxrezUA=; b=Vv8vkpJhqfn9iC1fcSFvDhqT016GgdHSuBpGHRJ9KUBbTI6aFvhFKNqq1rqxAa5Kll 353RRfmBTcgbgrq65FvLfW2PlEQ5eVT7qZ+NXGZQZ7gIEGBeZzZf9hw94JMXSe4nFkLq Dve/Id33HD5HNH+MPONeeCW/tuKrNRD2Nr5JR5FclJYdupnX/IMZCvw+5HJyHPckFgV9 e1dtwGWyPfBIQiD8B2zavo251yWcMGDFb2kI7AzMMZcKr5WYJFlu1knqNI5MyoJikDUh a69kEIdAVwgjjDCtoUJfJdvYDtDNBp8dOWA8GdzZr0d1bBeOPSmoq+lrD1LkVlHuwP2I sOWw== X-Gm-Message-State: ALoCoQl1cY15sg3brVoQFW/bg01P+IOxZWuNGA0hafRQHu6kmXQW05nNnb3K/djTR2tJDq7cijhn X-Received: by 10.224.138.9 with SMTP id y9mr23511999qat.22.1405369606899; Mon, 14 Jul 2014 13:26:46 -0700 (PDT) Received: from [192.168.0.200] ([201.188.2.251]) by mx.google.com with ESMTPSA id u42sm12155063qga.46.2014.07.14.13.26.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 13:26:45 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <53C4233B.7090403@gmx.net> Date: Mon, 14 Jul 2014 16:26:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <892A37A1-BFA9-4EEE-818F-B98D9496CE61@ve7jtb.com> References: <53BBDF5B.3020904@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA0841@TK5EX14MBXC294.redmond.corp.microsoft.com> <2CAA155D-E87E-4465-9110-C142D7085A56@ve7jtb.com> <53C3A5F2.908@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA8D92@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C41721.7020607@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA9143@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C41A08.7010203@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA9190@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C4233B.7090403@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ADyhXL1MSCdHNGAG4AesneTMBrk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri 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, 14 Jul 2014 20:26:49 -0000 If we can reference individual drafts then = https://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution/= is an example of encryption to the client by the AS in sec 4.2. If we want to reference an encryption example. I think signing is = covered by the assertion reference. John B. On Jul 14, 2014, at 2:36 PM, Hannes Tschofenig = wrote: > Hi Mike, >=20 > there is no problem referencing an individual draft particularly when > that reference gives some hint about how the stuff is used = (particularly > when the referenced document might be a working group draft at the = time > when the dynamic client registration document gets published as an = RFC). >=20 > In this specific case I haven't even thought about that > draft-sakimura-oauth-requrl-05... >=20 > Ciao > Hannes >=20 > On 07/14/2014 07:59 PM, Mike Jones wrote: >> I'm not suggesting that we reference it. We reference JWT using the = language I already provided. I was just giving you another example of a = signed JWT sent to the authorization server, since you couldn't think of = any off the top of your head. >>=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 >> Sent: Monday, July 14, 2014 10:57 AM >> To: Mike Jones; Brian Campbell; John Bradley >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri >>=20 >> That would then be a reference to an individual draft ;-) >>=20 >> On 07/14/2014 07:55 PM, Mike Jones wrote: >>> One example is when used as a signed request to the authorization = server, as is done in = http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05. >>=20 >=20 From nobody Mon Jul 14 17:02:51 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C441B27BF for ; Mon, 14 Jul 2014 17:02:48 -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 dPQ2mBfTl9Tr for ; Mon, 14 Jul 2014 17:02:45 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8212B1B27BE for ; Mon, 14 Jul 2014 17:02:44 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id hz20so3486748lab.28 for ; Mon, 14 Jul 2014 17:02:42 -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=4+MuQFELVEEfrw79MHQQhjtxdbwfmV+pRaId37qPkTM=; b=KCl12YogY8Ww3iFPogtzXAz6tuRmB949MIUh3zSBsccTOhU4Hs7CcwOO+n7PPvrWJW U8oQd9pAsyqy1Yt7Rtofz2M8+uNLAuqvkI7RX8z5V0rMjct+ouX6PU9p2VxYwi2TTbsn 6L824ug5uxfoIoQjRLlD5jeo10I9auEk1y2/vBJGEnaFijPlaUq989PlOQ4QxuJBvphA AbcWNbcw6m4jkqZqkFE7R8b8u6s3v2w1KxUsAjop+tTm0YRyq3vi5gfP0Jrg5RUFRXLL y1ejpqFllgtV3YUOGcrXjC/a41wnseKJhFHt5Leaz2MoWGMHMNeqcwiQGj+0pWBFWJgo ALKg== MIME-Version: 1.0 X-Received: by 10.152.180.36 with SMTP id dl4mr12873938lac.26.1405382562750; Mon, 14 Jul 2014 17:02:42 -0700 (PDT) Received: by 10.112.156.231 with HTTP; Mon, 14 Jul 2014 17:02:42 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA8DBE@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53BBDFA0.8010306@gmx.net> <53BBE932.6000808@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA07A1@TK5EX14MBXC294.redmond.corp.microsoft.com> <2681D9B8-FE2F-4182-BA27-6C06A427F0AD@ve7jtb.com> <53C3BE02.3040402@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA8DBE@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Tue, 15 Jul 2014 09:02:42 +0900 Message-ID: From: Nat Sakimura To: Mike Jones Content-Type: multipart/alternative; boundary=001a11345aa26d288404fe30201a Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/o8y2z-5U5_tU8VwgVNSCBjuqBH8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri 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, 15 Jul 2014 00:02:48 -0000 --001a11345aa26d288404fe30201a Content-Type: text/plain; charset=UTF-8 Actually, it may be the API's privacy policy so that it can state more specific purpose than the site's. So, we should not constrain it to be "site's". Also, I might prefer "personal data" instead of "personal information" but that might be just me. Nat 2014-07-15 1:18 GMT+09:00 Mike Jones : > Fine with me. (I might change "the privacy policy" to "the site's privacy > policy".) > > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, July 14, 2014 4:25 AM > To: John Bradley; Mike Jones > Cc: Nat Sakimura; oauth@ietf.org > Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri > > Here is the text from the OpenID Connect spec (as provided by Nat): > > > policy_uri > > OPTIONAL. URL that the Relying Party Client provides to the End-User > > to read about the how the profile data will be used. The value of > > this field MUST point to a valid web page. The OpenID Provider > > SHOULD display this URL to the End-User if it is given. If desired, > > representation of this Claim in different languages and scripts is > > represented as described in Section 2.1 > > > < > http://openid.bitbucket.org/openid-connect-registration-1_0.html#LanguagesAndScripts > >. > > > Here is the draft -18 text: > > > policy_uri > > URL that points to a human-readable Policy document for the > > client. The authorization server SHOULD display this URL to the > > end-user if it is given. The policy usually describes how an end- > > user's data will be used by the client. The value of this field > > MUST point to a valid web page. The value of this field MAY be > > internationalized, as described in Section 2.2 > . > > > Here is the suggested new text: > > " > policy_uri > OPTIONAL. URL that the Deployment Organization provides to the end > user to read about the privacy policy. A privacy policy is a > statement that describes how the Deployment Organization collects, > uses, retains and discloses personal information. > > The value of this field MUST point to a valid web page. The > Deployment Organization SHOULD display this URL to the end user. > Information for displaying a privacy policy in different languages > and scripts can be found in Section 2.2. > " > > Ciao > Hannes > > > On 07/08/2014 09:05 PM, John Bradley wrote: > > I am OK with clarifying the description as privacy/data protection > > policy. I don't think it needs privacy in the parameter name. > > On Jul 8, 2014, at 2:59 PM, Mike Jones > > wrote: > > > >> I agree with Nat's assessment. I'm fine updating the textual > >> description of the parameter, but we should not consider breaking > >> changes to the parameter names at this point. > >> > >> Do you have specific wording in mind, Hannes? > >> > >> -- Mike > >> > >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Nat > >> Sakimura > >> *Sent:* Tuesday, July 08, 2014 6:26 AM > >> *To:* Hannes Tschofenig > >> *Cc:* oauth@ietf.org > >> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: policy_uri > >> > >> I am not against using the term "Privacy Policy" in the description. > >> Depending on the jurisdiction and language, direct translation of > >> such can be "Data Protection Policy", "Personal Data Protection > >> Policy", etc., instead so just dodging it by avoiding the label would > >> be more politically neutral, but it could be fine after all. > >> > >> I am not fine with changing the parameter name though. > >> Slight variation in the parameter between the specs generally do not > >> help the developers. > >> > >> Nat > >> > >> > >> > >> 2014-07-08 21:50 GMT+09:00 Hannes Tschofenig > >> >: > >> For example, even Facebook calls this stuff "Privacy Policy URL". > >> > >> On 07/08/2014 02:43 PM, Nat Sakimura wrote: > >> > policy_uri came down from OpenID Connect Dynamic Client > >> > Registraiton 1.0 [1]. > >> > > >> > It goes: > >> > > >> > policy_uri > >> > OPTIONAL. URL that the Relying Party Client provides to the > End-User > >> > to read about the how the profile data will be used. The value of > >> > this field MUST point to a valid web page. The OpenID Provider > >> > SHOULD display this URL to the End-User if it is given. If > desired, > >> > representation of this Claim in different languages and scripts is > >> > represented as described in Section 2.1 > >> > > >> < > http://openid.bitbucket.org/openid-connect-registration-1_0.html#LanguagesAndScripts > >. > >> > > >> > It is clearly privacy related. In fact, it used to be a part of > >> > OpenID Connect Core in which the RP had to send it to obtain the > >> > permission. It is optional only because in certain enterprise type > >> > setting, it is unnecessary. In the consumer case, I regard it as > >> > essential. In any case, this is something a trust framework should > >> > set as its rule, and not the protocol itself. > >> > > >> > The draft -18 text goes: > >> > > >> > policy_uri > >> > URL that points to a human-readable Policy document for the > >> > client. The authorization server SHOULD display this URL to the > >> > end-user if it is given. The policy usually describes how an > end- > >> > user's data will be used by the client. The value of this field > >> > MUST point to a valid web page. The value of this field MAY be > >> > internationalized, as described in Section 2.2 > >> . > >> > > >> > > >> > It has been converted to be a bit vague. I would +1 to tighten it up. > >> > Note that there is tos_uri to describe the Terms of Service by the > >> > client and poicy_uri is not intended for this purpose but only for > >> > the service/client's privacy policy. > >> > > >> > BTW, I just found that a lot of text are more or less the duplicate > >> > or re-statement of [1]. IMHO, it should try to refer the original > >> > document where possible as it is a referable standard, and put [1] > >> > in the Reference section as well. > >> > > >> > Best, > >> > > >> > Nat > >> > > >> > [1] http://openid.net/specs/openid-connect-registration-1_0.html > >> > > >> > > >> > 2014-07-08 21:10 GMT+09:00 Hannes Tschofenig > >> > >> > >>>: > >> > > >> > Hi all, > >> > > >> > two earlier reviews I have noticed that the policy_uri meta-data > >> > attribute is not correctly specified. I offered a suggestion > >> > and > >> in both > >> > cases my request was ignored. > >> > > >> > Maybe there is a reason to reject my request but I am uncertain > >> about > >> > the relationship with another meta-data attribute, the > >> terms-of-service > >> > attribute. > >> > > >> > Here is what I said in my last review: > >> > > >> > http://www.ietf.org/mail-archive/web/oauth/current/msg12879.html > >> > > >> > " > >> > policy_uri: In my previous review I argued that the right > >> terminology > >> > here is privacy notice and you can even re-use the IAPP > terminology. > >> > Unless the policy URI has nothing to do with privacy I would > >> prefer this > >> > terminology change. If you disagree I would prefer to have a > >> > description about what policy means in this context. > >> > " > >> > > >> > Could you guys explain? > >> > > >> > Ciao > >> > Hannes > >> > > >> > > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org >> > > >> > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > > >> > > >> > > >> > -- > >> > Nat Sakimura (=nat) > >> > Chairman, OpenID Foundation > >> > http://nat.sakimura.org/ > >> > @_nat_en > >> > >> > >> > >> > >> -- > >> Nat Sakimura (=nat) > >> Chairman, OpenID Foundation > >> http://nat.sakimura.org/ > >> @_nat_en > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11345aa26d288404fe30201a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Actually, it may be the API's privacy policy so that i= t can state more specific purpose than the site's.
So, we should no= t constrain it to be "site's". =C2=A0

Also= , I might prefer "personal data" instead of "personal inform= ation" but=C2=A0
that might be just me.=C2=A0

Nat
<= /div>


2014-07-= 15 1:18 GMT+09:00 Mike Jones <Michael.Jones@microsoft.com>= ;:
Fine with me. =C2=A0(I might change "th= e privacy policy" to "the site's privacy policy".)

-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
Sent: Monday, July 14, 2014 4:25 AM
To: John Bradley; Mike Jones
Cc: Nat Sakimura; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri

Here is the text from the OpenID Connect spec (as provided by Nat):

> policy_uri
> =C2=A0 OPTIONAL. URL that the Relying Party Client provides to the End= -User
> =C2=A0 =C2=A0to read about the how the profile data will be used. The = value of
> =C2=A0 =C2=A0this field MUST point to a valid web page. The OpenID Pro= vider
> =C2=A0 =C2=A0SHOULD display this URL to the End-User if it is given. I= f desired,
> =C2=A0 =C2=A0representation of this Claim in different languages and s= cripts is
> =C2=A0 =C2=A0represented as described in Section 2.1
>
<http://openid.bitbucket.org/ope= nid-connect-registration-1_0.html#LanguagesAndScripts>.


Here is the draft -18 text:

> policy_uri
> =C2=A0 =C2=A0URL that points to a human-readable Policy document for t= he
> =C2=A0 =C2=A0client. =C2=A0The authorization server SHOULD display thi= s URL to the
> =C2=A0 =C2=A0end-user if it is given. =C2=A0The policy usually describ= es how an end-
> =C2=A0 =C2=A0user's data will be used by the client. =C2=A0The val= ue of this field
> =C2=A0 =C2=A0MUST point to a valid web page. =C2=A0The value of this f= ield MAY be
> =C2=A0 =C2=A0internationalized, as described in Section 2.2
<http://tools.ietf.org/html/draft-ietf-oauth-dyn-r= eg-18#section-2.2>.


Here is the suggested new text:

"
policy_uri
=C2=A0 =C2=A0OPTIONAL. URL that the Deployment Organization provides to the= end
=C2=A0 =C2=A0user to read about the privacy policy. A privacy policy is a =C2=A0 =C2=A0statement that describes how the Deployment Organization colle= cts,
=C2=A0 =C2=A0uses, retains and discloses personal information.

=C2=A0 =C2=A0The value of this field MUST point to a valid web page. The =C2=A0 =C2=A0Deployment Organization SHOULD display this URL to the end use= r.
=C2=A0 =C2=A0Information for displaying a privacy policy in different langu= ages
=C2=A0 =C2=A0and scripts can be found in Section 2.2.
"

Ciao
Hannes


On 07/08/2014 09:05 PM, John Bradley wrote:
> I am OK with clarifying the description as privacy/data protection
> policy. =C2=A0 I don't think it needs privacy in the parameter nam= e.
> On Jul 8, 2014, at 2:59 PM, Mike Jones <Michael.Jones@microsoft.com
> <mailto:Michael.Jone= s@microsoft.com>> wrote:
>
>> I agree with Nat's assessment. =C2=A0I'm fine updating the= textual
>> description of the parameter, but we should not consider breaking<= br> >> changes to the parameter names at this point.
>>
>> Do you have specific wording in mind, Hannes?
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mi= ke
>>
>> *From:* OAuth [mailto:oa= uth-bounces@ietf.org] *On Behalf Of *Nat
>> Sakimura
>> *Sent:* Tuesday, July 08, 2014 6:26 AM
>> *To:* Hannes Tschofenig
>> *Cc:* oauth@ietf.org <mai= lto:oauth@ietf.org>
>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: policy_uri<= br> >>
>> I am not against using the term "Privacy Policy" in the = description.
>> Depending on the jurisdiction and language, direct translation of<= br> >> such can be "Data Protection Policy", "Personal Dat= a Protection
>> Policy", etc., instead so just dodging it by avoiding the lab= el would
>> be more politically neutral, but it could be fine after all.
>>
>> I am not fine with changing the parameter name though.
>> Slight variation in the parameter between the specs generally do n= ot
>> help the developers.
>>
>> Nat
>>
>>
>>
>> 2014-07-08 21:50 GMT+09:00 Hannes Tschofenig
>> <hannes.tschofenig= @gmx.net <mailto:hannes= .tschofenig@gmx.net>>:
>> For example, even Facebook calls this stuff "Privacy Policy U= RL".
>>
>> On 07/08/2014 02:43 PM, Nat Sakimura wrote:
>> > policy_uri came down from OpenID Connect Dynamic Client
>> > Registraiton 1.0 [1].
>> >
>> > It goes:
>> >
>> > policy_uri
>> > =C2=A0 =C2=A0 OPTIONAL. URL that the Relying Party Client pro= vides to the End-User
>> > =C2=A0 =C2=A0 to read about the how the profile data will be = used. The value of
>> > =C2=A0 =C2=A0 this field MUST point to a valid web page. The = OpenID Provider
>> > =C2=A0 =C2=A0 SHOULD display this URL to the End-User if it i= s given. If desired,
>> > =C2=A0 =C2=A0 representation of this Claim in different langu= ages and scripts is
>> > =C2=A0 =C2=A0 represented as described in Section 2.1
>> >
>> <http://openid.bitbucke= t.org/openid-connect-registration-1_0.html#LanguagesAndScripts>.
>> >
>> > It is clearly privacy related. In fact, it used to be a part = of
>> > OpenID Connect Core in which the RP had to send it to obtain = the
>> > permission. It is optional only because in certain enterprise= type
>> > setting, it is unnecessary. In the consumer case, I regard it= as
>> > essential. In any case, this is something a trust framework s= hould
>> > set as its rule, and not the protocol itself.
>> >
>> > The draft -18 text goes:
>> >
>> > policy_uri
>> > =C2=A0 =C2=A0 =C2=A0 URL that points to a human-readable Poli= cy document for the
>> > =C2=A0 =C2=A0 =C2=A0 client. =C2=A0The authorization server S= HOULD display this URL to the
>> > =C2=A0 =C2=A0 =C2=A0 end-user if it is given. =C2=A0The polic= y usually describes how an end-
>> > =C2=A0 =C2=A0 =C2=A0 user's data will be used by the clie= nt. =C2=A0The value of this field
>> > =C2=A0 =C2=A0 =C2=A0 MUST point to a valid web page. =C2=A0Th= e value of this field MAY be
>> > =C2=A0 =C2=A0 =C2=A0 internationalized, as described in Secti= on 2.2
>> <http://tools.ietf.org/html/draft-ietf-oa= uth-dyn-reg-18#section-2.2>.
>> >
>> >
>> > It has been converted to be a bit vague. I would +1 to tighte= n it up.
>> > Note that there is tos_uri to describe the Terms of Service b= y the
>> > client and poicy_uri is not intended for this purpose but onl= y for
>> > the service/client's privacy policy.
>> >
>> > BTW, I just found that a lot of text are more or less the dup= licate
>> > or re-statement of [1]. IMHO, it should try to refer the orig= inal
>> > document where possible as it is a referable standard, and pu= t [1]
>> > in the Reference section as well.
>> >
>> > Best,
>> >
>> > Nat
>> >
>> > [1] http://openid.net/specs/openid-connect-re= gistration-1_0.html
>> >
>> >
>> > 2014-07-08 21:10 GMT+09:00 Hannes Tschofenig
>> <hannes.tschofenig= @gmx.net <mailto:hannes= .tschofenig@gmx.net>
>> > <mailto:hanne= s.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>>>:
>> >
>> > =C2=A0 =C2=A0 Hi all,
>> >
>> > =C2=A0 =C2=A0 two earlier reviews I have noticed that the pol= icy_uri meta-data
>> > =C2=A0 =C2=A0 attribute is not correctly specified. I offered= a suggestion
>> > and
>> in both
>> > =C2=A0 =C2=A0 cases my request was ignored.
>> >
>> > =C2=A0 =C2=A0 Maybe there is a reason to reject my request bu= t I am uncertain
>> about
>> > =C2=A0 =C2=A0 the relationship with another meta-data attribu= te, the
>> terms-of-service
>> > =C2=A0 =C2=A0 attribute.
>> >
>> > =C2=A0 =C2=A0 Here is what I said in my last review:
>> >
>> > http://www.ietf.org/mail-archive/web/oaut= h/current/msg12879.html
>> >
>> > =C2=A0 =C2=A0 "
>> > =C2=A0 =C2=A0 policy_uri: In my previous review I argued that= the right
>> terminology
>> > =C2=A0 =C2=A0 here is privacy notice and you can even re-use = the IAPP terminology.
>> > =C2=A0 =C2=A0 Unless the policy URI has nothing to do with pr= ivacy I would
>> prefer this
>> > =C2=A0 =C2=A0 terminology change. If you disagree I would pre= fer to have a
>> > =C2=A0 =C2=A0 description about what policy means in this con= text.
>> > =C2=A0 =C2=A0 "
>> >
>> > =C2=A0 =C2=A0 Could you guys explain?
>> >
>> > =C2=A0 =C2=A0 Ciao
>> > =C2=A0 =C2=A0 Hannes
>> >
>> >
>> > =C2=A0 =C2=A0 _______________________________________________=
>> > =C2=A0 =C2=A0 OAuth mailing list
>> > =C2=A0 =C2=A0 OAuth@ietf.or= g <mailto:OAuth@ietf.org> &= lt;mailto:OAuth@ietf.org
>> <mailto:OAuth@ietf.org>= ;>
>>
>> > =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/oauth<= br> >> >
>> >
>> >
>> >
>> > --
>> > Nat Sakimura (=3Dnat)
>> > Chairman, OpenID Foundation
>> > http:/= /nat.sakimura.org/
>> > @_nat_en
>>
>>
>>
>>
>> --
>> Nat Sakimura (=3Dnat)
>> Chairman, OpenID Foundation
>> http://nat.= sakimura.org/
>> @_nat_en
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>




--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en
--001a11345aa26d288404fe30201a-- From nobody Tue Jul 15 07:38:54 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0677C1B2828 for ; Tue, 15 Jul 2014 07:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dR6meNQrrzbX for ; Tue, 15 Jul 2014 07:38:51 -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 0C3B91B27EC for ; Tue, 15 Jul 2014 07:38:51 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LpKKr-1Wb0NY0iaj-00f9O9 for ; Tue, 15 Jul 2014 16:38:49 +0200 Message-ID: <53C53CF8.6090707@gmx.net> Date: Tue, 15 Jul 2014 16:38:48 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5IM145dT2Hq7Kfj13SPvGcb4JnveMllAL" X-Provags-ID: V03:K0:RtlCluAaepGqlhdWZbGCJffCkU6cM14rcZuH8toX2nbIHTIft8y CIHWIooyIJ3yCFuURJwynY4wPG94MMQ5PFAdrmjhOXwnlgcMHctTTecgc93nz52uNN2ctVR 00QZ9MyZtFwvC2OOJZtC/1p5YetK/Kvt09DqGGm04KXoTIfSXYgzj+Oi6+fb6aDNhEcMQjK lv6whHK77gu7OdzBqp4qA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/i0d0aYhWeCrD8WQee_4P-FJ5qgQ Subject: [OAUTH-WG] OAuth Use Cases 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, 15 Jul 2014 14:38:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5IM145dT2Hq7Kfj13SPvGcb4JnveMllAL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, due to lack of interest and progress we deleted the 'OAuth use case' document from the milestone list (after consultation with our area director). Text with relevant use cases will be copied to the working group Wiki page. The text is not lost. We would like to thank the original authors for their effort. Ciao Hannes & Derek --5IM145dT2Hq7Kfj13SPvGcb4JnveMllAL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTxTz4AAoJEGhJURNOOiAtd3QIAJst9s2VAdwY1Hi45Ls6Fe5u k8VFK+5z7aVWzmc2PmvM+EeH8vxfg0qR3g8S65V2bfB2m8vN9hl/1idH1Y8qdl06 kPIadR6nTX//3bzu2L0WtqwR7JIlXoD127VdcZ+jrgLcNKWf6b3hwKLSEy5B3uxz VMSXFZkmBRNMtWqZ86hITiGBgGOIzktHB0fiMEnyFMvNC93Lg9bRVIvLqwz/mt1j mMo9AMHYhEcx0V07BbziTY4tU8SSjwKsBbesD6kEE6u26PRDwRROtP3hSpS7qVx7 5wB24wOPsLNJ1wzNieDN5dKhqMwVypqraoXOKnZduIVHfNopKNEZyQEyl3JHWMs= =p3yq -----END PGP SIGNATURE----- --5IM145dT2Hq7Kfj13SPvGcb4JnveMllAL-- From nobody Tue Jul 15 07:42:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FC71B2875 for ; Tue, 15 Jul 2014 07:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovKy5Ap-OWby for ; Tue, 15 Jul 2014 07:42:50 -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 4DEC91B27EC for ; Tue, 15 Jul 2014 07:42:50 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M0PdN-1WHHZF1zvJ-00uX5D for ; Tue, 15 Jul 2014 16:42:48 +0200 Message-ID: <53C53DE7.1020503@gmx.net> Date: Tue, 15 Jul 2014 16:42:47 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nqGeGAgLGqf2lt6fmkVCB3knNQJMH2LB5" X-Provags-ID: V03:K0:AE8PmVogQ9/Eepj5Xnb0C8AL9SXtt/KW4PB/GMsarAlMQMKmPw/ NytLSrVz2IHKcq32JYmnr4jynpXuPuVpV8tOA5Pv0rYH6ub/Sdym1VYcIKLTCsyTdKK39nE t+g9mgPj94QFOXTWWtp3TA4WO4aMnJRRvrSdKJdiRA/7+h1yIG3/OBC3OC2c4kNHANRrCpb imkFn/e0qhtiGOYZPYWLA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/R4mz2ykK4j6wP7sPnqij72qb9Es Subject: [OAUTH-WG] Final Agenda for the IETF#90 OAuth Meeting 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, 15 Jul 2014 14:42:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nqGeGAgLGqf2lt6fmkVCB3knNQJMH2LB5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ** Please send us slides as soon as possible ** Web Authorization Protocol (OAuth) ---------------------------------- THURSDAY, July 24, 2014 1520-1720 EDT Manitoba (MM) - Welcome & Agenda Bashing (Chairs, 10min) (includes status update of the current WG documents in IESG processing)= - Dynamic Client Registration (Justin, 10min) http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ - Proof-of-Possession Security (Hannes, 15min) http://datatracker.ietf.org/doc/draft-richer-oauth-signed-http-request/ http://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution/= http://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/ http://datatracker.ietf.org/doc/draft-jones-oauth-proof-of-possession/ - Token Introspection (Justin, 15min) http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ - OAuth Symmetric Proof of Possession for Code Extension (Nat, 15min) http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - Providing User Authentication Information to OAuth 2.0 Clients (Mike, 15min) http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c/ - OAuth 2.0 Token Exchange (Mike, 15min) http://tools.ietf.org/html/draft-jones-oauth-token-exchange-01 - Request by JWS ver.1.0 for OAuth 2.0 (Nat, 15min) http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05 - Summary & Next Steps (Chairs, 10min) --nqGeGAgLGqf2lt6fmkVCB3knNQJMH2LB5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTxT3nAAoJEGhJURNOOiAtxo8H/0Ny4x5HEarSfgcfeySRthmA sJ4JI1BCubcyzTYYVFy5dY4cuwPZq7t/jNYUteM2hQxcsPdwNb5oOAnG11P30RiQ F6Z1stHmus8RCJD9D52TdTwF17bslKuuIzJz9uZryLyunmjymroKzaCISCQC4D8H H8SrvRw66Fv7QpLROVzmedPv3e/4yRJvh7rksZp6uHK4cVh504+BnZb4Hv+PeTCk BU8jATSiI0NaqptL6spKmD5fXqjb7v+ON7dYp4oQn+NK2YS6KTw/WFlyvS0L6/3W +pmpThi6+N5JRzMy5vQigpk0SMDVLMxwzlcr1FgHcn7ONWyJSSiHVQCSjcuVpi0= =wNV0 -----END PGP SIGNATURE----- --nqGeGAgLGqf2lt6fmkVCB3knNQJMH2LB5-- From nobody Tue Jul 15 09:12:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749A71B28CF for ; Tue, 15 Jul 2014 09:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huYdG7f5lJWf for ; Tue, 15 Jul 2014 09:12:02 -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 80F671B287F for ; Tue, 15 Jul 2014 09:12:02 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LjIBr-1WZPXr2ket-00dY5U for ; Tue, 15 Jul 2014 18:12:00 +0200 Message-ID: <53C552D0.4080902@gmx.net> Date: Tue, 15 Jul 2014 18:12:00 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k7SD6Rkvr5qS2VsDQ875rLPKTe05V1l6v" X-Provags-ID: V03:K0:YrO3MyOq1x9VokycXgA5ZZp7tj1bBzSFV3xUlX1ZoVp3ohSpta2 uzsMQvRgEHh33oxBFp66Mpp+4wTuu9OI9+8FLNi0n3lsLy7zK1lgACxY1DAqNy7AaePO1yM 2dYwTQmxDYb3YQPeXqsJh3MWA7jXAhPUfVpCCHcU7pCs9wiva0W7wpV2VMCcYTPU40KFjkY ZNzdMqfs8uOmncSaoCm3Q== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LeL3Yvx7xI33COtwpz79bPcyAio Subject: [OAUTH-WG] OAuth Proof-of-Possession Work 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, 15 Jul 2014 16:12:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --k7SD6Rkvr5qS2VsDQ875rLPKTe05V1l6v Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, Kathleen just confirmed the milestone update and as part of our work on the security part (which we called "proof-of-possession"). We replaced one milestone (containing one document, namely the MAC token spec) with one milestone for the proof-of-possession work (now containing a number of documents). We have been discussing this work for a while and now we will hopefully manage to conclude the work. If you haven't paid attention then you might want to take a quick look at my summary presentation from the last Internet Identity Workshop, see http://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx. In any case, there are still a number of open issues that need to get resolved as well. Needless to say that these documents are input to the working group and will change based on the consensus of the group. Ciao Hannes --k7SD6Rkvr5qS2VsDQ875rLPKTe05V1l6v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTxVLQAAoJEGhJURNOOiAtciUIAJjyA51Sm33oL9l6/RPVhXmg +xYwwvV4l9XlouLnGzAk+kznIV/LrCdafay8Qsb+6Oxe73+t9J32lNXNmP1DbMgY Nx//XMOg0iQa1zbjOB+okNhTuzAvg0opPE3uMEV3u6PGGOIHQ4uQPC9z5ZXG7LZC rO918N6PqDvqbvslThxNewHHA74xslLcbCL2KzPhdSaN/g0WgcWx5cx4ahgrEfcT WJpcHQvjsp4XnEeQ6hHiOhsfcNm632WlDgMYIc8VA5ZUsWn5jlqcoIdsNJWEdqNJ 7/mg3APGsW0iGY9k4Ly2C8lRm7QE9tuNetaJvdXNeQXaHXPslmfm5+zNCgRGlWM= =FB0I -----END PGP SIGNATURE----- --k7SD6Rkvr5qS2VsDQ875rLPKTe05V1l6v-- From nobody Tue Jul 15 11:01:34 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59E71A0AFE for ; Tue, 15 Jul 2014 11:01:32 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 P9wWFwH87Tc1 for ; Tue, 15 Jul 2014 11:01:31 -0700 (PDT) Received: from nm2-vm5.access.bullet.mail.bf1.yahoo.com (nm2-vm5.access.bullet.mail.bf1.yahoo.com [216.109.114.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A901A0AE3 for ; Tue, 15 Jul 2014 11:01:30 -0700 (PDT) Received: from [66.196.81.156] by nm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jul 2014 18:01:30 -0000 Received: from [66.196.81.133] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jul 2014 18:01:29 -0000 Received: from [127.0.0.1] by omp1009.access.mail.bf1.yahoo.com with NNFMP; 15 Jul 2014 18:01:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 806737.24021.bm@omp1009.access.mail.bf1.yahoo.com Received: (qmail 74285 invoked by uid 60001); 15 Jul 2014 18:01:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1405447289; bh=0NdOtW4kMuOw9hCLS00ncQSkByZK3pjnzqmIhkzgwgs=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Lb9hFt5/5tpErSUCBHssMkCjoZrfPKyRMXgYuvsruGKqytarG6aw3LBJclVhaZD3XmvhltwqlOwhogPo4SDsD7afPNiYMPdSe/po7Qm3Go3946irCBttF4nxhrvflZ3765kGhKK2hrRlOJ3PxoLoyOgSMq+rdJ/kvojXfhE7ebA= X-YMail-OSG: XH7jV9YVM1lM6zpYHIsK98vOTK3OUUx7EGWaKfx0Yse7XiX Z76FW1UJBvZ39PcyfqfqGBscyvsYn64gK8usL9bBF5RIKUIx2IYrk2Z3o7Lv ecNDvEFL44xljYRso7HL8DgmVoFukAuauIPCdjft7RBMLGQZPAxZaUp2yEXU QrkPr.zGrI.AKRi1MxFDhuZPcmtuI5FyMr1Z1X7gthxIlT8xwxx1lZjd2SrV UPb5q2ILsM5vFV6BLLjC7iz6Ml6wIjnUX4tREef2KjmSSCcT97kC5nHxj4zm wJf67AfrjT9HBigdIilAlczZJjyqd36P5MjXGGYNFA.5YRFSMc84mRYBQKVW tXZoim3B1IDYxvzFi3cboV9kuTcLc4i2p14I_MMGg3tZjS2.sEpr91w5gf39 NGbjFd2mHxhfbCRixyxCsOgXyTFdi___EDP2lRADLXcTD0lma5MqnSQlQXT4 .mIe53kCGJve.Kcu42IoYvZ9jT7j3yEVMqPgm6Ge5T0PDR9n3WLPacQlWfWr lKaqddKqw.ReTIOz1NrCoPixzTTdlPp_UzFVvJt58r485wGX2UnTVEeiZ_Bw GUoa2MEV9viKVhswPzGoV4A3NgMDxA0hKcNiGopDbjfhb4UFCYibVJO6jdiA Yk3FXKuZvBKaRbtHGpTYBHHb5El75JBTiso_HBrFjEdhE0zWVGlXV1jECGtW NWFTiSksNTMl90lR_cUzEXNt34CxL0paEK0yUhqwSmXqLjABcYeg2eJvxUk2 rj.n.pfuidJWrJT_NtL19E9jpVe45rVZGJI.5FRqkg85G7fN3DOGjA5B37Xg KLWeIa85wtL1Cthpi1j6nOoXHtwe.ZVWoHt0aX_E- Received: from [70.36.254.127] by web181205.mail.ne1.yahoo.com via HTTP; Tue, 15 Jul 2014 11:01:29 PDT X-Rocket-MIMEInfo: 002.001, SSd2ZSBpbXBsZW1lbnRlZCByZWdpc3RyYXRpb24gYXMgcGFydCBvZiBPcGVuSUQgQ29ubmVjdC4KCnNlcnZlciAtwqBodHRwczovL2Nvbm5lY3Qub3BlbmlkNC51cy9hYm9wCmNsaWVudCAtIGh0dHBzOi8vY29ubmVjdC5vcGVuaWQ0LnVzL2FicnAKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PgpUbzogIm9hdXRoQGlldGYub3JnIiA8b2F1dGhAaWV0Zi5vcmc.IApTZW50OiBUdWVzZGF5LCBKdWx5IDgBMAEBAQE- X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailWebService/0.8.194.680 References: <53BBE813.3000006@gmx.net> Message-ID: <1405447289.37219.YahooMailNeo@web181205.mail.ne1.yahoo.com> Date: Tue, 15 Jul 2014 11:01:29 -0700 From: Edmund Jay To: Hannes Tschofenig , "oauth@ietf.org" In-Reply-To: <53BBE813.3000006@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1067797826-645670888-1405447289=:37219" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CeW57qF6TZmzaza8TYW830-TRAw Subject: Re: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Edmund Jay List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 18:01:32 -0000 ---1067797826-645670888-1405447289=:37219 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I've implemented registration as part of OpenID Connect.=0A=0Aserver -=A0ht= tps://connect.openid4.us/abop=0Aclient - https://connect.openid4.us/abrp=0A= =0A=0A=0A________________________________=0A From: Hannes Tschofenig =0ATo: "oauth@ietf.org" =0ASent: Tues= day, July 8, 2014 5:46 AM=0ASubject: [OAUTH-WG] Shepherd Writeup for Dynami= c Client Registration Draft=0A =0A=0AHi all,=0A=0AI am working on the sheph= erd writeup for the dynamic client registration=0Adraft.=0A=0AYou can find = the latest draft here:=0Ahttps://github.com/hannestschofenig/tschofenig-ids= /blob/master/shepherd-writeups/Writeup_OAuth_DynamicClientRegistration.txt= =0A=0AAs you can see it is still incomplete.=0A=0AI would need information = about the implementation status.=0A=0ACiao=0AHannes=0A=0A__________________= _____________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps= ://www.ietf.org/mailman/listinfo/oauth ---1067797826-645670888-1405447289=:37219 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I've implemented registration as part of OpenID Co= nnect.

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: "oauth@ietf.org" <oauth@ietf.= org>
Sent: Tuesday= , July 8, 2014 5:46 AM
Subject: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft

Hi all,

I am working o= n the shepherd writeup for the dynamic client registration
draft.
You can find the latest draft here:
https://github.com/hannestscho= fenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_DynamicCli= entRegistration.txt

As you can see it is still incomplete.
I would need information about the implementation status.

Ciao
= Hannes

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

<= br>
---1067797826-645670888-1405447289=:37219-- From nobody Tue Jul 15 12:04:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6663E1A0A8E for ; Tue, 15 Jul 2014 12:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2U055q9qBKA for ; Tue, 15 Jul 2014 12:04:42 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A137D1A001C for ; Tue, 15 Jul 2014 12:04:42 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB312.namprd03.prod.outlook.com (10.141.48.28) with Microsoft SMTP Server (TLS) id 15.0.985.8; Tue, 15 Jul 2014 19:04:34 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0985.008; Tue, 15 Jul 2014 19:04:34 +0000 From: Anthony Nadalin To: Edmund Jay , Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft Thread-Index: AQHPoFbU+6SXZ434d0Gu1QHC1KXiYJuhfkCQ Date: Tue, 15 Jul 2014 19:04:33 +0000 Message-ID: <362a4dcbd09342fd9da64bc62345b73b@BLUPR03MB309.namprd03.prod.outlook.com> References: <53BBE813.3000006@gmx.net> <1405447289.37219.YahooMailNeo@web181205.mail.ne1.yahoo.com> In-Reply-To: <1405447289.37219.YahooMailNeo@web181205.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.119] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-prvs: 027367F73D x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(53754006)(377454003)(74502001)(54356999)(83322001)(19300405004)(86612001)(20776003)(16236675004)(81342001)(66066001)(19580405001)(106356001)(74662001)(15202345003)(19609705001)(86362001)(19625215002)(33646002)(15975445006)(81542001)(4396001)(77982001)(74316001)(107046002)(92566001)(95666004)(85852003)(107886001)(87936001)(105586002)(50986999)(80022001)(64706001)(76576001)(76482001)(99396002)(31966008)(83072002)(106116001)(2656002)(85306003)(21056001)(99286002)(79102001)(101416001)(46102001)(19617315012)(76176999)(19580395003)(108616002)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB312; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_362a4dcbd09342fd9da64bc62345b73bBLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JRt8HVGq294dN0cd15tbbGpbeYY Subject: Re: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft 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, 15 Jul 2014 19:04:45 -0000 --_000_362a4dcbd09342fd9da64bc62345b73bBLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is your implementation from the OpenID Connect specification of from the IE= TF specification From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Edmund Jay Sent: Tuesday, July 15, 2014 11:01 AM To: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Dr= aft I've implemented registration as part of OpenID Connect. server - https://connect.openid4.us/abop client - https://connect.openid4.us/abrp ________________________________ From: Hannes Tschofenig > To: "oauth@ietf.org" > Sent: Tuesday, July 8, 2014 5:46 AM Subject: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft Hi all, I am working on the shepherd writeup for the dynamic client registration draft. You can find the latest draft here: https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-wri= teups/Writeup_OAuth_DynamicClientRegistration.txt As you can see it is still incomplete. I would need information about the implementation status. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_362a4dcbd09342fd9da64bc62345b73bBLUPR03MB309namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is your implementation fr= om the OpenID Connect specification of from the IETF specification

 

From: OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of Edmund Jay
Sent: Tuesday, July 15, 2014 11:01 AM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registra= tion Draft

 

I've implemented registration as part of OpenID Connect.=

 

 

 

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: "oauth@ietf.org"= <oauth@ietf.org>
Sent: Tuesday, July 8, 2014 5:46 AM
Subject: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration= Draft


Hi all,

I am working on the shepherd writeup for the dynamic client registration draft.

You can find the latest draft here:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepher= d-writeups/Writeup_OAuth_DynamicClientRegistration.txt

As you can see it is still incomplete.

I would need information about the implementation status.

Ciao
Hannes

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

--_000_362a4dcbd09342fd9da64bc62345b73bBLUPR03MB309namprd03pro_-- From nobody Tue Jul 15 12:15:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BA41B2921 for ; Tue, 15 Jul 2014 12:15:53 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 37ftO6kXAJtr for ; Tue, 15 Jul 2014 12:15:52 -0700 (PDT) Received: from nm27-vm2.access.bullet.mail.gq1.yahoo.com (nm27-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D041A007D for ; Tue, 15 Jul 2014 12:15:52 -0700 (PDT) Received: from [216.39.60.174] by nm27.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jul 2014 19:15:52 -0000 Received: from [216.39.60.162] by tm10.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jul 2014 19:15:52 -0000 Received: from [127.0.0.1] by omp1028.access.mail.gq1.yahoo.com with NNFMP; 15 Jul 2014 19:15:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 73251.94177.bm@omp1028.access.mail.gq1.yahoo.com Received: (qmail 59528 invoked by uid 60001); 15 Jul 2014 19:15:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1405451751; bh=rGLFID2TAAWxKddJHBQaOT8JqcVFvjI24CBCh3FgDDs=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=JN6ESdPUQTgWGZ3YG00e/8lgl0mb39qWdiWCNEr27b7HrhZPSuSyv5CVK1QnDS2bGyb87AcwatqNy5tGNsf5V31gdCsox1LtaqxRNVYCNnxQrrqWOgr8FplREBrfnMkIZfeYEVdoE4c3t1mKQAgLahhoZyiTRhQKbxHM1qXRRwQ= X-YMail-OSG: gmh6CGsVM1lp_2NfM9cJxDaAPA9JIPoE2Hg.RFfopSgZg3u zbmra6EiMZL1v3z1D2S1PR5BLBddekFYr_ACGiCMgjNU9JBG3.9xPW99IAid AovellX4RF_kR4j6nOUiV2y6iyGrCY1.pyDQEVClwot.YcUQMiM3Glt8U3gk qV6wkZyeWk3k9xmH39ajin4Ji.9rJ8MvtEryvkcO6YgZjluW2necgM_aN1NN fnM2UFCVg_nP1Oi2aw2EixhA_88U5_3WTe6uh4qUSMiQ3xtlRQvnxRicWwaL qtV3HSCZD627SMITrgtGLW89XRTVduPUYAyeiQU7bFwOrjr64IzmGUZDvrFX aSLt7q5zBXDnOnUMacNBzZnaDjRRCJMsT1GoG3IPUWh6_EnyNycN83SP13yj 35JUg01RuH4urR.zEP6g1lrOuaRlvgJYYFmqZVJL_bOqds4_79d9DrgzSlnS w2rkriBN3q9xAZl9tHRzH76qL364vV38ihBUzePqaooABqiygTugJcgudEpz ax_cSBWhTF0Ut.cxWpxRpH91a8nW6a3bzcVXHMcWQeJ9dSjMXeU0TETLLzZV CrpssL0a_xdx9h6p49xgn95NJy3j.f72v5cBdpqeYf.OeRNm2azRcprCe2m3 cvdAtCpRGbAqyvZ3efKM3.1xToEbdfwBrEPefvOanFOfJ5j_R_15LlVXzl2U 3SIZtgBDpOvv2oOZ8mHHIcwcgZawWbzttxuIca3dhAdPA71oLsZP92XN7y6B GGH1o5Fxgtbnz8wp4zHS7uyuC76PtCISfVVzPRZ9fO1UCcRxIcN_MjmdWHQ2 PnjcJKtwc.7A5jhVyoAiJ1w.RsrDM9vTXBDHg3vQ- Received: from [70.36.254.127] by web181201.mail.ne1.yahoo.com via HTTP; Tue, 15 Jul 2014 12:15:51 PDT X-Rocket-MIMEInfo: 002.001, SXQgaXMgZnJvbSB0aGUgT3BlbklEIENvbm5lY3Qgc3BlYywgYnV0IEkgYmVsaWV2ZSB0aGUgT3BlbklEIENvbm5lY3Qgc3BlYyBpcyBzaW1pbGFyIGVub3VnaCB0aGF0IGl0IGlzIGNvbXBsaWFudCB3aXRoIHRoZSBPQXV0aCB2ZXJzaW9uLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT4KVG86IEVkbXVuZCBKYXkgPGVqYXlAbWdpMS5jb20.OyBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ20BMAEBAQE- X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailWebService/0.8.194.680 References: <53BBE813.3000006@gmx.net> <1405447289.37219.YahooMailNeo@web181205.mail.ne1.yahoo.com> <362a4dcbd09342fd9da64bc62345b73b@BLUPR03MB309.namprd03.prod.outlook.com> Message-ID: <1405451751.73352.YahooMailNeo@web181201.mail.ne1.yahoo.com> Date: Tue, 15 Jul 2014 12:15:51 -0700 From: Edmund Jay To: Anthony Nadalin , Hannes Tschofenig , "oauth@ietf.org" In-Reply-To: <362a4dcbd09342fd9da64bc62345b73b@BLUPR03MB309.namprd03.prod.outlook.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-106228746-226021424-1405451751=:73352" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7X3SbAqlpwrDowupQRrzaStkx5w Subject: Re: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Edmund Jay List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 19:15:54 -0000 ---106228746-226021424-1405451751=:73352 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It is from the OpenID Connect spec, but I believe the OpenID Connect spec i= s similar enough that it is compliant with the OAuth version.=0A=0A=0A_____= ___________________________=0A From: Anthony Nadalin =0ATo: Edmund Jay ; Hannes Tschofenig ; "oauth@ietf.org" =0ASent: Tuesday, July 15, 2014 1= 2:04 PM=0ASubject: RE: [OAUTH-WG] Shepherd Writeup for Dynamic Client Regis= tration=09Draft=0A =0A=0A=0AIs your implementation from the OpenID Connect = specification of from the IETF specification=0A=A0=0A=0A=0AFrom:OAuth [mail= to:oauth-bounces@ietf.org] On Behalf Of Edmund Jay=0ASent: Tuesday, July 15= , 2014 11:01 AM=0ATo: Hannes Tschofenig; oauth@ietf.org=0ASubject: Re: [OAU= TH-WG] Shepherd Writeup for Dynamic Client Registration Draft=0A=A0=0AI've = implemented registration as part of OpenID Connect.=0A=A0=0Aserver -=A0http= s://connect.openid4.us/abop=0Aclient - https://connect.openid4.us/abrp=0A= =A0=0A=A0=0A=0A________________________________=0A =0AFrom:Hannes Tschofeni= g =0ATo: "oauth@ietf.org" =0ASe= nt: Tuesday, July 8, 2014 5:46 AM=0ASubject: [OAUTH-WG] Shepherd Writeup fo= r Dynamic Client Registration Draft=0A=0AHi all,=0A=0AI am working on the s= hepherd writeup for the dynamic client registration=0Adraft.=0A=0AYou can f= ind the latest draft here:=0Ahttps://github.com/hannestschofenig/tschofenig= -ids/blob/master/shepherd-writeups/Writeup_OAuth_DynamicClientRegistration.= txt=0A=0AAs you can see it is still incomplete.=0A=0AI would need informati= on about the implementation status.=0A=0ACiao=0AHannes=0A=0A_______________= ________________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Aht= tps://www.ietf.org/mailman/listinfo/oauth ---106228746-226021424-1405451751=:73352 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It is from the OpenID Connect spec, but I believe = the OpenID Connect spec is similar enough that it is compliant with the OAu= th version.

From: Anthony Nadalin <tonynad@microso= ft.com>
To: Edmund = Jay <ejay@mgi1.com>; Hannes Tschofenig <hannes.tschofenig@gmx.net&= gt;; "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, July 15, 2014 12:04 PM
Subject: RE: [OAUTH-WG] Shepherd Writeup= for Dynamic Client Registration=09Draft

<= div>=0A
=0A
Is your implementation from= the OpenID Connect specification of from the IETF specification =0A
&= nbsp;
=0A


=0A=0A
From: OAuth [mailto= :oauth-bounces@ietf.org]=0AOn Behalf Of Edmund Jay
=0ASent: Tuesday, July 15, 2014 11:01 AM
=0ATo= : Hannes Tschofenig; oauth@ietf.org
=0ASubject: Re: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft
=0A
=0A
=0A
 = ;
=0A
=0A
=0A
I've implemented regist= ration as part of OpenID Connect.
=0A
=0A
=0A
 
=0A
=0A=0A=0A
=0A=
&n= bsp;
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A<= span style=3D"">=0A
= =0A
=0A
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
=0ATo: "oauth@ietf.o= rg" <oauth@ietf.org&g= t;=0A
=0ASent: Tuesday, July 8, 2014 5:46 AM
=0ASubject: [OAUTH-WG] Shepherd Writeup for Dynamic Cli= ent Registration Draft
=0A
=0A=0A

=0AHi all,
=0A
=0AI am working on the shepherd writeup for th= e dynamic client registration
=0Adraft.
=0A
=0AYou can find the latest draft here:
=0Ahttps://github.com/hannestscho= fenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_DynamicCli= entRegistration.txt
=0A
=0AAs you c= an see it is still incomplete.
=0A
=0AI= would need information about the implementation status.
= =0A
=0ACiao
=0AHannes
=0A
=0A_______________________________________________=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A
=0A
=0A
=0A
= =0A
=0A
=0A
=0A


---106228746-226021424-1405451751=:73352-- From nobody Tue Jul 15 12:17:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4DF1B2928 for ; Tue, 15 Jul 2014 12:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 0YkDfr4Ljaa6 for ; Tue, 15 Jul 2014 12:17:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E00031B2924 for ; Tue, 15 Jul 2014 12:17:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 706BD1F03CD; Tue, 15 Jul 2014 15:17:45 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 62F001F070A; Tue, 15 Jul 2014 15:17:45 -0400 (EDT) Received: from [10.146.15.61] (10.140.19.249) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 15 Jul 2014 15:17:45 -0400 Message-ID: <53C57E35.5000401@mitre.org> Date: Tue, 15 Jul 2014 15:17:09 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , "oauth@ietf.org" References: <53BBE813.3000006@gmx.net> In-Reply-To: <53BBE813.3000006@gmx.net> Content-Type: multipart/alternative; boundary="------------050000030908070100060502" X-Originating-IP: [10.140.19.249] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/E6lKwalUTyKf2anx3_79LdseRlk Subject: Re: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft 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, 15 Jul 2014 19:17:48 -0000 --------------050000030908070100060502 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I've implemented the core dynamic registration draft and the management protocol draft (including read, update, and delete), both client side and server side, in MITREid Connect: https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server We've been running this code in production at a number of organizations for several years, with dynamic registration being available (and used) for well over a year in all instances. Our implementation includes support for initial access tokens (through a server configuration/extension), but it does not include an implementation of software statements. And since it was asked on another thread: our implementation is also compliant with the OpenID Connect dynamic registration specification, since the two protocols are completely wire compatible by design. We have had both OpenID Connect and plain-OAuth clients use it. We've also implemented the client-side of dynamic registration as part of this library: https://github.com/jumbojett/OpenID-Connect-PHP/ -- Justin On 07/08/2014 08:46 AM, Hannes Tschofenig wrote: > Hi all, > > I am working on the shepherd writeup for the dynamic client registration > draft. > > You can find the latest draft here: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_DynamicClientRegistration.txt > > As you can see it is still incomplete. > > I would need information about the implementation status. > > Ciao > Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050000030908070100060502 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I've implemented the core dynamic registration draft and the management protocol draft (including read, update, and delete), both client side and server side, in MITREid Connect:

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server

We've been running this code in production at a number of organizations for several years, with dynamic registration being available (and used) for well over a year in all instances.

Our implementation includes support for initial access tokens (through a server configuration/extension), but it does not include an implementation of software statements.

And since it was asked on another thread: our implementation is also compliant with the OpenID Connect dynamic registration specification, since the two protocols are completely wire compatible by design. We have had both OpenID Connect and plain-OAuth clients use it.

We've also implemented the client-side of dynamic registration as part of this library:

https://github.com/jumbojett/OpenID-Connect-PHP/

 -- Justin


On 07/08/2014 08:46 AM, Hannes Tschofenig wrote:
Hi all,

I am working on the shepherd writeup for the dynamic client registration
draft.

You can find the latest draft here:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_DynamicClientRegistration.txt

As you can see it is still incomplete.

I would need information about the implementation status.

Ciao
Hannes




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

--------------050000030908070100060502-- From nobody Tue Jul 15 12:47:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0C71A0027 for ; Tue, 15 Jul 2014 12:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KjVDd9NN_1d for ; Tue, 15 Jul 2014 12:47:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCAF1A0054 for ; Tue, 15 Jul 2014 12:47:01 -0700 (PDT) Received: from BLUPR03CA033.namprd03.prod.outlook.com (10.141.30.26) by CY1PR0301MB0732.namprd03.prod.outlook.com (25.160.159.150) with Microsoft SMTP Server (TLS) id 15.0.985.8; Tue, 15 Jul 2014 19:46:59 +0000 Received: from BY2FFO11FD051.protection.gbl (2a01:111:f400:7c0c::125) by BLUPR03CA033.outlook.office365.com (2a01:111:e400:879::26) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Tue, 15 Jul 2014 19:46:58 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD051.mail.protection.outlook.com (10.1.15.188) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Tue, 15 Jul 2014 19:46:58 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0195.002; Tue, 15 Jul 2014 19:46:47 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: Dynamic Client Registration: IPR Confirmation Thread-Index: AQHPmqNjTLUtygPATEaoV9K+QkTus5uWWTqAgAAPVUaAAJbWEIAKle1g Date: Tue, 15 Jul 2014 19:46:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADAB98C@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53BBDBEE.703@gmx.net>, <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADAB98CTK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(448002)(51704005)(199002)(189002)(377454003)(24454002)(55885003)(66066001)(87936001)(16297215004)(55846006)(15395725005)(44976005)(19300405004)(99396002)(76482001)(16236675004)(84326002)(86612001)(104016003)(93886003)(46102001)(85326001)(79102001)(19625215002)(4396001)(26826002)(15975445006)(71186001)(20776003)(69596002)(74662001)(15202345003)(77982001)(92566001)(106466001)(107046002)(81342001)(76176999)(107886001)(81156004)(54356999)(106116001)(83322001)(80022001)(85852003)(92726001)(64706001)(95666004)(68736004)(86362001)(21056001)(2656002)(33656002)(19580405001)(50986999)(84676001)(19580395003)(74502001)(85306003)(77096002)(31966008)(19617315012)(97736001)(81542001)(6806004)(83072002); DIR:OUT; SFP:; SCL:1; SRVR:CY1PR0301MB0732; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 027367F73D Received-SPF: PermError (: domain of microsoft.com used an invalid SPF mechanism) Authentication-Results: spf=permerror (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/mmOwfRRz_lrol40BFRCq3KsBo8k Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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, 15 Jul 2014 19:47:06 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439ADAB98CTK5EX14MBXC294r_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable So that the working group has concrete language to consider, propose the fo= llowing language to the OAuth Dynamic Client Registration specification: Portions of this specification are derived from the OpenID Connect Dynamic = Registration [OpenID.Registration] specification. This was done so that im= plementations of this specification and OpenID Connect Dynamic Registration= can be compatible with one another. -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, July 08, 2014 7:15 PM To: Phil Hunt; Hannes Tschofenig Cc: Maciej Machulak; oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation Thinking about this some more, there is one IPR issue that we need to addre= ss before publication. This specification is a derivative work from the Op= enID Connect Dynamic Registration specification http://openid.net/specs/ope= nid-connect-registration-1_0.html. Large portions of the text were copied = wholesale from that spec to this one, so that the two would be compatible. = (This is good thing =96 not a bad thing.) This is easy to address from an IPR perspective =96 simply acknowledge that= this spec is a derivative work and provide proper attribution. The OpenID= copyright in the spec at http://openid.net/specs/openid-connect-registrati= on-1_0.html#Notices allows for this resolution. It says: Copyright (c) 2014 The OpenID Foundation. The OpenID Foundation (OIDF) grants to any Contributor, developer, implemen= ter, or other interested party a non-exclusive, royalty free, worldwide cop= yright license to reproduce, prepare derivative works from, distribute, per= form and display, this Implementers Draft or Final Specification solely for= the purposes of (i) developing specifications, and (ii) implementing Imple= menters Drafts and Final Specifications based on such documents, provided t= hat attribution be made to the OIDF as the source of the material, but that= such attribution does not indicate an endorsement by the OIDF. Let=92s add the reference and acknowledgment in the next version. -- Mike From: Mike Jones Sent: Tuesday, July 08, 2014 10:06 AM To: Phil Hunt; Hannes Tschofenig Cc: John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org Subject: RE: Dynamic Client Registration: IPR Confirmation I likewise do not hold any IPR on these specs. ________________________________ From: Phil Hunt Sent: =FD7/=FD8/=FD2014 9:11 AM To: Hannes Tschofenig Cc: Mike Jones; John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org Subject: Re: Dynamic Client Registration: IPR Confirmation I confirm I have no IPR disclosures on this document. Phil > On Jul 8, 2014, at 4:54, Hannes Tschofenig > wrote: > > Hi Phil, John, Maciej, Justin, Mike, > > I am working on the shepherd writeup for the dynamic client registration > document and 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? > > Ciao > Hannes > > --_000_4E1F6AAD24975D4BA5B16804296739439ADAB98CTK5EX14MBXC294r_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

So that the working group= has concrete language to consider, propose the following language to the O= Auth Dynamic Client Registration specification:

 <= /p>

Portions of this specification are derived from th= e OpenID Connect Dynamic Registration [OpenID.Registration] specification.&= nbsp; This was done so that implementations of this specification and OpenID Connect Dynamic Registration can be compatible with one another= .

 <= /p>

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

 <= /p>

From: OAuth [m= ailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, July 08, 2014 7:15 PM
To: Phil Hunt; Hannes Tschofenig
Cc: Maciej Machulak; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmatio= n

 

Thinking about this some = more, there is one IPR issue that we need to address before publication.&nb= sp; This specification is a derivative work from the OpenID Connect Dynamic Registration specification http://openid.net/specs/openid-connect-registration-1_0.html.  Lar= ge portions of the text were copied wholesale from that spec to this one, s= o that the two would be compatible.  (This is good thing =96 not a bad= thing.)

 <= /p>

This is easy to address f= rom an IPR perspective =96 simply acknowledge that this spec is a derivativ= e work and provide proper attribution.  The OpenID copyright in the spec at http://openid.net/specs/openid-connect-registration-1_0.html#Notices al= lows for this resolution.  It says:

 <= /p>

Copyright (c) 2014 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contrib= utor, developer, implementer, or other interested party a non-exclusive, ro= yalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Imple= menters Draft or Final Specification solely for the purposes of (i) develop= ing specifications, and (ii) implementing Implementers Drafts and Final Spe= cifications based on such documents, provided that attribution be made to the OIDF as the source of the materia= l, but that such attribution does not indicate an endorsement by the OIDF.<= o:p>

Let=92s add the reference= and acknowledgment in the next version.

 <= /p>

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

 <= /p>

From: Mike Jon= es
Sent: Tuesday, July 08, 2014 10:06 AM
To: Phil Hunt; Hannes Tschofenig
Cc: John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org
Subject: RE: Dynamic Client Registration: IPR Confirmation

 

I likewise do not hold any IPR on these= specs.

I confirm I have no= IPR disclosures on this document.

Phil

> On Jul 8, 2014, at 4:54, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
> Hi Phil, John, Maciej, Justin, Mike,
>
> I am working on the shepherd writeup for the dynamic client registrati= on
> document and one item in the template requires me to indicate whether<= br> > each document author has confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 7= 8
> and BCP 79 have already been filed.
>
> Could you please confirm?
>
> Ciao
> Hannes
>
>

--_000_4E1F6AAD24975D4BA5B16804296739439ADAB98CTK5EX14MBXC294r_-- From nobody Tue Jul 15 13:04:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BCF1A0085 for ; Tue, 15 Jul 2014 13:04:11 -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 VP-X-kdmqdEC for ; Tue, 15 Jul 2014 13:04:10 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4891A0061 for ; Tue, 15 Jul 2014 13:04:09 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id p9so3871959lbv.26 for ; Tue, 15 Jul 2014 13:04:08 -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=AYdEwTN6ZwfViFQ5OXC1O4xYU14ECkHbTlEKIHw3mRw=; b=e4kx9Ke8xe06XRQZhfhm+Oo/yOiOTXc6iLGLMVxlDEMF8LTicwbQFQx9vMlLMcuKvg bOTNPPDUUspaL5k8IgkcxtPSwSbEaacD4Pzzw7zeZLCs+RaPEejm+eSozkWQlQ6nVq5B 0Tqv4BKl3IcLybEkkAFOZoc5mmIsaHq1+o8Wp+UbHr+UXYF1v7MX7D1rf9hwwCH/XsFY lbKg5nBIdZYtZ1yoAFRmSexmEqbBf2JohVi8EkrUHBP/4fMROsFQxFbzjwdp3b5R9/O3 E+R/FIwvBgPiNvFwOU7/2WbBrIa4LQlYFivW0vVw7tlp/cx6yz8ZlbFbKtrbH5Ak0enD liJA== MIME-Version: 1.0 X-Received: by 10.152.216.228 with SMTP id ot4mr21010990lac.40.1405454648087; Tue, 15 Jul 2014 13:04:08 -0700 (PDT) Received: by 10.112.207.73 with HTTP; Tue, 15 Jul 2014 13:04:08 -0700 (PDT) Date: Tue, 15 Jul 2014 16:04:08 -0400 Message-ID: From: Kathleen Moriarty To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a11345ee40c186504fe40e90c Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fzqKOM6K4w1zI-_aFotABzCWbrc Subject: [OAUTH-WG] AD Review of http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer 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, 15 Jul 2014 20:04:12 -0000 --001a11345ee40c186504fe40e90c Content-Type: text/plain; charset=UTF-8 Hello, I just finished my review of http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer. The draft looks great, thank you for all of your efforts on it! I did notice that there were no privacy considerations pointing back to RFC6973, could that text be added? The draft came after the Oauth framework publication (refernced in the security considerations), so I am guessing that is why this was missed as there are privacy considerations in the oauth assertion draft (I competed that review as well and the draft looked great. I don't have any comments to add prior to progressing the draft). Thank you. -- Best regards, Kathleen --001a11345ee40c186504fe40e90c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I just finished my review of=C2= =A0http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer. =C2=A0= The draft looks great, thank you for all of your efforts on it!

I did notice that there were no privacy considerations = pointing back to RFC6973, could that text be added? =C2=A0The draft came af= ter the Oauth framework publication (refernced in the security consideratio= ns), so I am guessing that is why this was missed as there are privacy cons= iderations in the oauth assertion draft (I competed that review as well and= the draft looked great. =C2=A0I don't have any comments to add prior t= o progressing the draft).

Thank you.

--

Best regards,
Kathleen
--001a11345ee40c186504fe40e90c-- From nobody Wed Jul 16 02:03:51 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CE81B29AD for ; Wed, 16 Jul 2014 02:03:49 -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 9CyPRloVfdn5 for ; Wed, 16 Jul 2014 02:03:48 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD95C1B2AA4 for ; Wed, 16 Jul 2014 02:03:47 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so575584wes.36 for ; Wed, 16 Jul 2014 02:03:46 -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=ICHgLQtPfonTj14DGh27QY1cYC93am94gsZV7011gUk=; b=DdqM64vywxoWCpSlF6A9gVmAg3KEazejQopEO+2G28PsjYek9PckX6Bfb/U8hRebcV 0jICoP19q+/osm0+9yB/4cWRXMzmpjBix04O2sZtlYIk+VzbsjDqbgWKTeOD83Pn6UpB roawuu+PUg5FkFnmVpLvH0btnxOmlmuc3VOEN5tWIyQxeWPiwvsUPb4ZRNvqxnXfvN3J Ah8Rrux96s3eY18jCB4zIqpIQDskS1iq3iqrImQySGQPTyJzF/isriSqLRQzJM1tW1G2 98hWK3ERNAT/jULU/Cm/NjxtN8iDH10qSEDZT3D9RdxDLp+4g3W/a8iSx0FOpl1EsUDV qj+w== MIME-Version: 1.0 X-Received: by 10.194.7.36 with SMTP id g4mr34347136wja.37.1405501426281; Wed, 16 Jul 2014 02:03:46 -0700 (PDT) Received: by 10.194.18.198 with HTTP; Wed, 16 Jul 2014 02:03:46 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53BBDBEE.703@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> Date: Wed, 16 Jul 2014 11:03:46 +0200 Message-ID: From: Maciej Machulak To: Mike Jones Content-Type: multipart/alternative; boundary=047d7b450a7c3eb68904fe4bcdfb Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/UGcAj-dFgzbpvRCfWQt9pgKDmgM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 16 Jul 2014 09:03:49 -0000 --047d7b450a7c3eb68904fe4bcdfb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, My apologies for a late reply. Same here, no IPR disclosures to make regarding these documents. Kind regards, Maciej On 8 July 2014 19:06, Mike Jones wrote: > I likewise do not hold any IPR on these specs. > ------------------------------ > From: Phil Hunt > Sent: =E2=80=8E7/=E2=80=8E8/=E2=80=8E2014 9:11 AM > > To: Hannes Tschofenig > Cc: Mike Jones ; John Bradley > ; Justin Richer ; Maciej Machulak > ; oauth@ietf.org > Subject: Re: Dynamic Client Registration: IPR Confirmation > > I confirm I have no IPR disclosures on this document. > > Phil > > > On Jul 8, 2014, at 4:54, Hannes Tschofenig > wrote: > > > > Hi Phil, John, Maciej, Justin, Mike, > > > > I am working on the shepherd writeup for the dynamic client registratio= n > > document and 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? > > > > Ciao > > Hannes > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Maciej Machulak email: maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) --047d7b450a7c3eb68904fe4bcdfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

My apologies for a late reply. Same= here,=C2=A0no IPR disclosures to make regarding these documents.

Kind regards,
Maciej


On 8 Ju= ly 2014 19:06, Mike Jones <Michael.Jones@microsoft.com> wrote:
I likewise do = not hold any IPR on these specs.
From: Phil Hunt Sent: =E2=80= =8E7/=E2=80=8E8/=E2=80=8E2014 9:11 AM

To: Hannes Tschofenig<= /a>
Cc: Mike Jones; John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org
Subject: Re: Dy= namic Client Registration: IPR Confirmation

I confirm I have no IPR disclosures on this document.

Phil

> On Jul 8, 2014, at 4:54, Hannes Tschofenig <hannes.tschofenig@gmx.net> w= rote:
>
> Hi Phil, John, Maciej, Justin, Mike,
>
> I am working on the shepherd writeup for the dynamic client registrati= on
> document and one item in the template requires me to indicate whether<= br> > each document author has confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 7= 8
> and BCP 79 have already been filed.
>
> Could you please confirm?
>
> Ciao
> Hannes
>
>

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




--
Maciej M= achulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 767 (UK)
mob= ile: +48 602 45 31 66 (PL)
--047d7b450a7c3eb68904fe4bcdfb-- From nobody Wed Jul 16 03:17:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FBE1B2B06 for ; Wed, 16 Jul 2014 03:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbB4lcGEk2ka for ; Wed, 16 Jul 2014 03:17:13 -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 30CF11A037B for ; Wed, 16 Jul 2014 03:17:13 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LreCz-1WQqrJ0AaD-013Mmc; Wed, 16 Jul 2014 12:17:08 +0200 Message-ID: <53C65120.4020302@gmx.net> Date: Wed, 16 Jul 2014 12:17:04 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mike Jones , "oauth@ietf.org" References: <53BBDBEE.703@gmx.net>, <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADAB98C@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADAB98C@TK5EX14MBXC294.redmond.corp.microsoft.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="T965wMSfuWHfgOEa1lUIp5JTuO5LNwQJ2" X-Provags-ID: V03:K0:bfnN+Ppa5bi43I8kfRsB2miiKJG8khaW9jEZRAhEUg+uuvZMaPZ RllfYnyTtPx4wD8shHElkycb09EbWIjcshWiBqxbjOikeBfWIi616X0TUn4L3uZ+fehQyy3 ioOiP8t5g9Evsmve5+DYM9rbHs6tcoEtjhhRfMUdn1ou4aBybnJ2Sea1mz/TjbPjCCA9jdg SCI+TezYkk63slOn5LJ3Q== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7V2ErPaIL7XKm1OzrikeqeZyCeA Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 16 Jul 2014 10:17:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T965wMSfuWHfgOEa1lUIp5JTuO5LNwQJ2 Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: quoted-printable Thanks, Mike. This is a useful addition and reflects the relationship between the two efforts. Please add it to the next draft version. Ciao Hannes On 07/15/2014 09:46 PM, Mike Jones wrote: > So that the working group has concrete language to consider, propose th= e > following language to the OAuth Dynamic Client Registration specificati= on: >=20 > =20 >=20 > Portions of this specification are derived from the OpenID Connect > Dynamic Registration [OpenID.Registration] specification. This was don= e > so that implementations of this specification and OpenID Connect Dynami= c > Registration can be compatible with one another. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Mike Jones > *Sent:* Tuesday, July 08, 2014 7:15 PM > *To:* Phil Hunt; Hannes Tschofenig > *Cc:* Maciej Machulak; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation= >=20 > =20 >=20 > Thinking about this some more, there is one IPR issue that we need to > address before publication. This specification is a derivative work > from the OpenID Connect Dynamic Registration specification > http://openid.net/specs/openid-connect-registration-1_0.html. Large > portions of the text were copied wholesale from that spec to this one, > so that the two would be compatible. (This is good thing =96 not a bad= > thing.) >=20 > =20 >=20 > This is easy to address from an IPR perspective =96 simply acknowledge > that this spec is a derivative work and provide proper attribution. Th= e > OpenID copyright in the spec at > http://openid.net/specs/openid-connect-registration-1_0.html#Notices > allows for this resolution. It says: >=20 > =20 >=20 > Copyright (c) 2014 The OpenID Foundation. >=20 > The OpenID Foundation (OIDF) grants to any Contributor, developer, > implementer, or other interested party a non-exclusive, royalty free, > worldwide copyright license to reproduce, prepare derivative works from= , > distribute, perform and display, this Implementers Draft or Final > Specification solely for the purposes of (i) developing specifications,= > and (ii) implementing Implementers Drafts and Final Specifications base= d > on such documents, provided that attribution be made to the OIDF as the= > source of the material, but that such attribution does not indicate an > endorsement by the OIDF. >=20 > Let=92s add the reference and acknowledgment in the next version. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > *From:*Mike Jones > *Sent:* Tuesday, July 08, 2014 10:06 AM > *To:* Phil Hunt; Hannes Tschofenig > *Cc:* John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org > > *Subject:* RE: Dynamic Client Registration: IPR Confirmation >=20 > =20 >=20 > I likewise do not hold any IPR on these specs. >=20 > -----------------------------------------------------------------------= - >=20 > *From: *Phil Hunt > *Sent: *=FD7/=FD8/=FD2014 9:11 AM > *To: *Hannes Tschofenig > *Cc: *Mike Jones ; John Bradley > ; Justin Richer ; > Maciej Machulak ; oauth@ietf.org > > *Subject: *Re: Dynamic Client Registration: IPR Confirmation >=20 > I confirm I have no IPR disclosures on this document. >=20 > Phil >=20 >> On Jul 8, 2014, at 4:54, Hannes Tschofenig > wrote: >>=20 >> Hi Phil, John, Maciej, Justin, Mike, >>=20 >> I am working on the shepherd writeup for the dynamic client registrati= on >> document and 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 7= 8 >> and BCP 79 have already been filed. >>=20 >> Could you please confirm? >>=20 >> Ciao >> Hannes >>=20 >>=20 >=20 --T965wMSfuWHfgOEa1lUIp5JTuO5LNwQJ2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTxlEgAAoJEGhJURNOOiAt6UwH/3CPHviOkCvUaXWvcr+dKWWc G4bt1pOOEWcbpC+hcj81WnzsUeR8LMN1N/HoHy8OD9xpnv6PUd5y/FqPY/nV/H4Y o22uoqwUWjBp+uGzBNDsYOJ0EkP9wl1udAbtPRY1CEdU0Wj3Km0l4sa1e351cjc4 QPVqBC+fNpOYQN9dZZb0g6KjaYz78ss5uiPR4ZZGt6XU8oJAxfBWj7vwGjyPfQW3 L+RbBZBqwBuz0EFM7hu74VJdXZb9e2FNnGNlM/RGJeB04RkKe4WbjgLzTCX5h22i WKa8iK/Pq5TgfSZLTR43UiANlVR7Q/T/cPPe3dZybVvzj9AHboXs+X040OCo934= =6uIL -----END PGP SIGNATURE----- --T965wMSfuWHfgOEa1lUIp5JTuO5LNwQJ2-- From nobody Wed Jul 16 04:41:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFB11B283B for ; Wed, 16 Jul 2014 04:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1FbQVPVrSeH for ; Wed, 16 Jul 2014 04:41:30 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EA61A0535 for ; Wed, 16 Jul 2014 04:41:29 -0700 (PDT) X-AuditID: 12074423-f79bf6d000007580-ce-53c664e8478e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 7C.59.30080.8E466C35; Wed, 16 Jul 2014 07:41:28 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s6GBfRSC002750; Wed, 16 Jul 2014 07:41:27 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6GBfPJj023063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 16 Jul 2014 07:41:26 -0400 Message-ID: <53C664DC.50907@mit.edu> Date: Wed, 16 Jul 2014 07:41:16 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , Mike Jones , "oauth@ietf.org" References: <53BBDBEE.703@gmx.net>, <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADAB98C@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C65120.4020302@gmx.net> In-Reply-To: <53C65120.4020302@gmx.net> Content-Type: multipart/alternative; boundary="------------000402050901040403060209" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR4hTV1n2RcizYYM1JOYulO++xWuyd9onF 4uTbV2wOzB6LN+1n81iy5CeTR+uOv+wBzFFcNimpOZllqUX6dglcGffOfGQu2JNbceHjQrYG xv0RXYycHBICJhKLn25ngbDFJC7cW8/WxcjFISQwm0mib9d6VghnI6PEpAl3mUGqhARuM0ms 7FQCsXkFVCS+/OtmB7FZBFQldpz+wgZiswHZ81feYgKxRQWiJO5c6meFqBeUODnzCQvIUBGB CYwSe2ZdAmsWFnCV+D19B9Tq90wSO1YcALuJU0Bd4uC1XjCbWSBMYtLT96wTGPlnIRk2C0lq FiMHkG0t8W13EURYXmL72znMELa2xKres0zI4gsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbp munlZpbopaaUbmIEhTu7i/IOxj8HlQ4xCnAwKvHwbgg5GizEmlhWXJl7iFGSg0lJlLfD4liw EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFeB3+gHG9KYmVValE+TEqag0VJnPettVWwkEB6Yklq dmpqQWoRTFaGg0NJglcRGNdCgkWp6akVaZk5JQhpJg5OkOE8QMOXJYMMLy5IzC3OTIfIn2JU lBLn/ZAElBAASWSU5sH1wtLRK0ZxoFeEeXlBVvAAUxlc9yugwUxAg8trDoMMLklESEk1MCYc Zshn3Bb/+vj6iXcSnlbI/7/zWpjh0r6ru1JknZW9z00V1q8Ql9h67t6zpc6znh6fNPvql+Jn k1PS4i1CZCeYfhb02fpXYrMvQ098ZOsWHoPFU4JuLfgb+PbOLOmjDx6/YDuwPHDa8z7rmYzf d74qt3ZZ7rlq9sNopkv7jisnsQnKHXoaf2e/EktxRqKhFnNRcSIAxZlJKiIDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/bYl680Dr7OdTAV3ZyIgPStydPnM Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 16 Jul 2014 11:41:34 -0000 This is a multi-part message in MIME format. --------------000402050901040403060209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I thought I had sent this note already, but I don't see it in the archives or in my 'sent' folder: If we're going to point to OpenID Connect (which I'm fine with), then we should clarify that portions were also taken from the UMA specification. In fact, draft -00 actually *was* the UMA specification text entirely. This is also what the OpenID Connect registration specification was (loosely) based on when it was started. In reality, the relationship between these three documents from three different SBO's is more complicated: they all grew up together and effectively merged to become wire-compatible with each other. There were a number of changes that were discussed here in the IETF that OpenID Connect adopted, and a number of changes that were discussed at OIDF that were adopted here. OIDC also extends the IETF draft with a set of OIDC-specific metadata fields and editorial language that makes it fit more closely in the OIDC landscape, but make no mistake: they're the same protocol. In the case of UMA, it's a straight normative reference to the IETF document now because we were able to incorporate those use cases and parameters directly. The trouble is, I'm not sure how to concisely state that all that in the draft text, but it's not as simple as "we copied OpenID", which is what the text below seems to say. -- Justin On 7/16/2014 6:17 AM, Hannes Tschofenig wrote: > Thanks, Mike. > > This is a useful addition and reflects the relationship between the two > efforts. > > Please add it to the next draft version. > > Ciao > Hannes > > On 07/15/2014 09:46 PM, Mike Jones wrote: >> So that the working group has concrete language to consider, propose the >> following language to the OAuth Dynamic Client Registration specification: >> >> >> >> Portions of this specification are derived from the OpenID Connect >> Dynamic Registration [OpenID.Registration] specification. This was done >> so that implementations of this specification and OpenID Connect Dynamic >> Registration can be compatible with one another. >> >> >> >> -- Mike >> >> >> >> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Mike Jones >> *Sent:* Tuesday, July 08, 2014 7:15 PM >> *To:* Phil Hunt; Hannes Tschofenig >> *Cc:* Maciej Machulak; oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation >> >> >> >> Thinking about this some more, there is one IPR issue that we need to >> address before publication. This specification is a derivative work >> from the OpenID Connect Dynamic Registration specification >> http://openid.net/specs/openid-connect-registration-1_0.html. Large >> portions of the text were copied wholesale from that spec to this one, >> so that the two would be compatible. (This is good thing -- not a bad >> thing.) >> >> >> >> This is easy to address from an IPR perspective -- simply acknowledge >> that this spec is a derivative work and provide proper attribution. The >> OpenID copyright in the spec at >> http://openid.net/specs/openid-connect-registration-1_0.html#Notices >> allows for this resolution. It says: >> >> >> >> Copyright (c) 2014 The OpenID Foundation. >> >> The OpenID Foundation (OIDF) grants to any Contributor, developer, >> implementer, or other interested party a non-exclusive, royalty free, >> worldwide copyright license to reproduce, prepare derivative works from, >> distribute, perform and display, this Implementers Draft or Final >> Specification solely for the purposes of (i) developing specifications, >> and (ii) implementing Implementers Drafts and Final Specifications based >> on such documents, provided that attribution be made to the OIDF as the >> source of the material, but that such attribution does not indicate an >> endorsement by the OIDF. >> >> Let's add the reference and acknowledgment in the next version. >> >> >> >> -- Mike >> >> >> >> *From:*Mike Jones >> *Sent:* Tuesday, July 08, 2014 10:06 AM >> *To:* Phil Hunt; Hannes Tschofenig >> *Cc:* John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org >> >> *Subject:* RE: Dynamic Client Registration: IPR Confirmation >> >> >> >> I likewise do not hold any IPR on these specs. >> >> ------------------------------------------------------------------------ >> >> *From: *Phil Hunt >> *Sent: *?7/?8/?2014 9:11 AM >> *To: *Hannes Tschofenig >> *Cc: *Mike Jones ; John Bradley >> ; Justin Richer ; >> Maciej Machulak ; oauth@ietf.org >> >> *Subject: *Re: Dynamic Client Registration: IPR Confirmation >> >> I confirm I have no IPR disclosures on this document. >> >> Phil >> >>> On Jul 8, 2014, at 4:54, Hannes Tschofenig > wrote: >>> >>> Hi Phil, John, Maciej, Justin, Mike, >>> >>> I am working on the shepherd writeup for the dynamic client registration >>> document and 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? >>> >>> Ciao >>> Hannes >>> >>> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000402050901040403060209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I thought I had sent this note already, but I don't see it in the archives or in my 'sent' folder:

If we're going to point to OpenID Connect (which I'm fine with), then we should clarify that portions were also taken from the UMA specification. In fact, draft -00 actually *was* the UMA specification text entirely. This is also what the OpenID Connect registration specification was (loosely) based on when it was started.

In reality, the relationship between these three documents from three different SBO's is more complicated: they all grew up together and effectively merged to become wire-compatible with each other. There were a number of changes that were discussed here in the IETF that OpenID Connect adopted, and a number of changes that were discussed at OIDF that were adopted here. OIDC also extends the IETF draft with a set of OIDC-specific metadata fields and editorial language that makes it fit more closely in the OIDC landscape, but make no mistake: they're the same protocol. In the case of UMA, it's a straight normative reference to the IETF document now because we were able to incorporate those use cases and parameters directly.

The trouble is, I'm not sure how to concisely state that all that in the draft text, but it's not as simple as "we copied OpenID", which is what the text below seems to say.

 -- Justin

On 7/16/2014 6:17 AM, Hannes Tschofenig wrote:
Thanks, Mike.

This is a useful addition and reflects the relationship between the two
efforts.

Please add it to the next draft version.

Ciao
Hannes

On 07/15/2014 09:46 PM, Mike Jones wrote:

So that the working group has concrete language to consider, propose the
following language to the OAuth Dynamic Client Registration specification:

 

Portions of this specification are derived from the OpenID Connect
Dynamic Registration [OpenID.Registration] specification.  This was done
so that implementations of this specification and OpenID Connect Dynamic
Registration can be compatible with one another.

 

                                                            -- Mike

 

*From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Mike Jones
*Sent:* Tuesday, July 08, 2014 7:15 PM
*To:* Phil Hunt; Hannes Tschofenig
*Cc:* Maciej Machulak; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation

 

Thinking about this some more, there is one IPR issue that we need to
address before publication.  This specification is a derivative work
from the OpenID Connect Dynamic Registration specification
http://openid.net/specs/openid-connect-registration-1_0.html.  Large
portions of the text were copied wholesale from that spec to this one,
so that the two would be compatible.  (This is good thing – not a bad
thing.)

 

This is easy to address from an IPR perspective – simply acknowledge
that this spec is a derivative work and provide proper attribution.  The
OpenID copyright in the spec at
http://openid.net/specs/openid-connect-registration-1_0.html#Notices
allows for this resolution.  It says:

 

Copyright (c) 2014 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contributor, developer,
implementer, or other interested party a non-exclusive, royalty free,
worldwide copyright license to reproduce, prepare derivative works from,
distribute, perform and display, this Implementers Draft or Final
Specification solely for the purposes of (i) developing specifications,
and (ii) implementing Implementers Drafts and Final Specifications based
on such documents, provided that attribution be made to the OIDF as the
source of the material, but that such attribution does not indicate an
endorsement by the OIDF.

Let’s add the reference and acknowledgment in the next version.

 

                                                            -- Mike

 

*From:*Mike Jones
*Sent:* Tuesday, July 08, 2014 10:06 AM
*To:* Phil Hunt; Hannes Tschofenig
*Cc:* John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org
<mailto:oauth@ietf.org>
*Subject:* RE: Dynamic Client Registration: IPR Confirmation

 

I likewise do not hold any IPR on these specs.

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

*From: *Phil Hunt <mailto:phil.hunt@oracle.com>
*Sent: *‎7/‎8/‎2014 9:11 AM
*To: *Hannes Tschofenig <mailto:hannes.tschofenig@gmx.net>
*Cc: *Mike Jones <mailto:Michael.Jones@microsoft.com>; John Bradley
<mailto:ve7jtb@ve7jtb.com>; Justin Richer <mailto:jricher@mitre.org>;
Maciej Machulak <mailto:m.p.machulak@ncl.ac.uk>; oauth@ietf.org
<mailto:oauth@ietf.org>
*Subject: *Re: Dynamic Client Registration: IPR Confirmation

I confirm I have no IPR disclosures on this document.

Phil


On Jul 8, 2014, at 4:54, Hannes Tschofenig <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:

Hi Phil, John, Maciej, Justin, Mike,

I am working on the shepherd writeup for the dynamic client registration
document and 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?

Ciao
Hannes




      

      

      

      

      

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


    

    

  


--------------000402050901040403060209--


From nobody Wed Jul 16 04:45:03 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF871B28FB for ; Wed, 16 Jul 2014 04:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofYPGvkdB4Nb for ; Wed, 16 Jul 2014 04:44:58 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD30D1A0535 for ; Wed, 16 Jul 2014 04:44:57 -0700 (PDT)
Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LjqLx-1WanmM3efJ-00bpMP; Wed, 16 Jul 2014 13:44:52 +0200
Message-ID: <53C665B0.7040708@gmx.net>
Date: Wed, 16 Jul 2014 13:44:48 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Justin Richer , Mike Jones ,  "oauth@ietf.org" 
References: <53BBDBEE.703@gmx.net>,  <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADAB98C@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C65120.4020302@gmx.net> <53C664DC.50907@mit.edu>
In-Reply-To: <53C664DC.50907@mit.edu>
X-Enigmail-Version: 1.5.2
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mN3Kpt4S4WTURJ6l8qw3khnh0H36VCqhp"
X-Provags-ID: V03:K0:AfUZbLeYordWEbCB6vFF7IezT4+7NT8RbEOUPhqT0T6qjyejTR5 GHyTPODa1Suwa6k7itoovgebnRQ5Y2uAYiJUkPhB19ZXfiadWR61HObKS6TlnYva/USDxeC TjZsdbkl0xrnf00YzS9rZ41ckW3MQE4tN43ZaNbfmECPwDpcXbxBs6jrB1aripS4iqpjGrZ kcN06skPBlcZKSpkei5NA==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DleHfMiZ5-CpZ7S9dVEwwuBQn24
Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 16 Jul 2014 11:45:01 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--mN3Kpt4S4WTURJ6l8qw3khnh0H36VCqhp
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Interesting background information. Maybe we should then extend the note
Mike provided to also clarify the relationship with the UMA work (both
in terms to IPR, copyright, and attribution-wise).

It would also make sense to state the relationship in the introduction
to highlight the compatibility, which I believe is a big accomplishment.

Ciao
Hannes

On 07/16/2014 01:41 PM, Justin Richer wrote:
> I thought I had sent this note already, but I don't see it in the
> archives or in my 'sent' folder:
>=20
> If we're going to point to OpenID Connect (which I'm fine with), then w=
e
> should clarify that portions were also taken from the UMA specification=
=2E
> In fact, draft -00 actually *was* the UMA specification text entirely.
> This is also what the OpenID Connect registration specification was
> (loosely) based on when it was started.
>=20
> In reality, the relationship between these three documents from three
> different SBO's is more complicated: they all grew up together and
> effectively merged to become wire-compatible with each other. There wer=
e
> a number of changes that were discussed here in the IETF that OpenID
> Connect adopted, and a number of changes that were discussed at OIDF
> that were adopted here. OIDC also extends the IETF draft with a set of
> OIDC-specific metadata fields and editorial language that makes it fit
> more closely in the OIDC landscape, but make no mistake: they're the
> same protocol. In the case of UMA, it's a straight normative reference
> to the IETF document now because we were able to incorporate those use
> cases and parameters directly.
>=20
> The trouble is, I'm not sure how to concisely state that all that in th=
e
> draft text, but it's not as simple as "we copied OpenID", which is what=

> the text below seems to say.
>=20
>  -- Justin
>=20
> On 7/16/2014 6:17 AM, Hannes Tschofenig wrote:
>> Thanks, Mike.
>>
>> This is a useful addition and reflects the relationship between the tw=
o
>> efforts.
>>
>> Please add it to the next draft version.
>>
>> Ciao
>> Hannes
>>
>> On 07/15/2014 09:46 PM, Mike Jones wrote:
>>> So that the working group has concrete language to consider, propose =
the
>>> following language to the OAuth Dynamic Client Registration specifica=
tion:
>>>
>>> =20
>>>
>>> Portions of this specification are derived from the OpenID Connect
>>> Dynamic Registration [OpenID.Registration] specification.  This was d=
one
>>> so that implementations of this specification and OpenID Connect Dyna=
mic
>>> Registration can be compatible with one another.
>>>
>>> =20
>>>
>>>                                                             -- Mike
>>>
>>> =20
>>>
>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Mike Jone=
s
>>> *Sent:* Tuesday, July 08, 2014 7:15 PM
>>> *To:* Phil Hunt; Hannes Tschofenig
>>> *Cc:* Maciej Machulak; oauth@ietf.org
>>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmati=
on
>>>
>>> =20
>>>
>>> Thinking about this some more, there is one IPR issue that we need to=

>>> address before publication.  This specification is a derivative work
>>> from the OpenID Connect Dynamic Registration specification
>>> http://openid.net/specs/openid-connect-registration-1_0.html.  Large
>>> portions of the text were copied wholesale from that spec to this one=
,
>>> so that the two would be compatible.  (This is good thing =E2=80=93 n=
ot a bad
>>> thing.)
>>>
>>> =20
>>>
>>> This is easy to address from an IPR perspective =E2=80=93 simply ackn=
owledge
>>> that this spec is a derivative work and provide proper attribution.  =
The
>>> OpenID copyright in the spec at
>>> http://openid.net/specs/openid-connect-registration-1_0.html#Notices
>>> allows for this resolution.  It says:
>>>
>>> =20
>>>
>>> Copyright (c) 2014 The OpenID Foundation.
>>>
>>> The OpenID Foundation (OIDF) grants to any Contributor, developer,
>>> implementer, or other interested party a non-exclusive, royalty free,=

>>> worldwide copyright license to reproduce, prepare derivative works fr=
om,
>>> distribute, perform and display, this Implementers Draft or Final
>>> Specification solely for the purposes of (i) developing specification=
s,
>>> and (ii) implementing Implementers Drafts and Final Specifications ba=
sed
>>> on such documents, provided that attribution be made to the OIDF as t=
he
>>> source of the material, but that such attribution does not indicate a=
n
>>> endorsement by the OIDF.
>>>
>>> Let=E2=80=99s add the reference and acknowledgment in the next versio=
n.
>>>
>>> =20
>>>
>>>                                                             -- Mike
>>>
>>> =20
>>>
>>> *From:*Mike Jones
>>> *Sent:* Tuesday, July 08, 2014 10:06 AM
>>> *To:* Phil Hunt; Hannes Tschofenig
>>> *Cc:* John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org
>>> 
>>> *Subject:* RE: Dynamic Client Registration: IPR Confirmation
>>>
>>> =20
>>>
>>> I likewise do not hold any IPR on these specs.
>>>
>>> ---------------------------------------------------------------------=
---
>>>
>>> *From: *Phil Hunt 
>>> *Sent: *=E2=80=8E7/=E2=80=8E8/=E2=80=8E2014 9:11 AM
>>> *To: *Hannes Tschofenig 
>>> *Cc: *Mike Jones ; John Bradley
>>> ; Justin Richer ;=

>>> Maciej Machulak ; oauth@ietf.org
>>> 
>>> *Subject: *Re: Dynamic Client Registration: IPR Confirmation
>>>
>>> I confirm I have no IPR disclosures on this document.
>>>
>>> Phil
>>>
>>>> On Jul 8, 2014, at 4:54, Hannes Tschofenig > wrote:
>>>>
>>>> Hi Phil, John, Maciej, Justin, Mike,
>>>>
>>>> I am working on the shepherd writeup for the dynamic client registra=
tion
>>>> document and one item in the template requires me to indicate whethe=
r
>>>> 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?
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


--mN3Kpt4S4WTURJ6l8qw3khnh0H36VCqhp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTxmWwAAoJEGhJURNOOiAtIq4H/2We8Q/jcldk20kqZ5AJ9GkY
yLKYacf9EB0SiBOjhJfr9ea/WNtNkTYAaOB66IOuoyuO8W0UbRg5Y3mkCLk7xxuI
x6IJU1AA2URChqZDeNIQzktWqrDznIQ7VM9BY8ooEgYhyqoupeF6EiIUwMTylQru
oNVQ5XFxJkNXvThbbxqJWeX2OCxPUW6GQc9z3it/Egejf9fLxPNAYfQsHjk4O4eJ
QnVxzBdbAOunLyFgD6LjdOvU6bQietUsMIWb4XNfFuYQCjIoEDvaHHycbjry1KvB
ZOrcvNuJrW/PdDJfLviYKjItlAR1FbpxLTGmqaX9Xuk/I4sCmuwFrf81+umenqs=
=rb52
-----END PGP SIGNATURE-----

--mN3Kpt4S4WTURJ6l8qw3khnh0H36VCqhp--


From nobody Wed Jul 16 04:51:30 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADF01B2B15 for ; Wed, 16 Jul 2014 04:51:26 -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 2PfHDAenvT6V for ; Wed, 16 Jul 2014 04:51:23 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB2C1B29D3 for ; Wed, 16 Jul 2014 04:51:22 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id f8so4682874wiw.5 for ; Wed, 16 Jul 2014 04:51:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0CqOtewJdu+c3FwrMMY6BGR/T4oyD/DCYFgr92HJ/6I=; b=MFZsfUQ/vjWZcTyo9o4ed2QLAexQVxrhxP69r1xb6ndS4PKCMSWElAL13BS2WtCZPz mQJzTyoQ11+SGNg2OtU7aIzlIguZN5xHzLyox88jxi1CetPAaHM/NRa6tDdsfNPe10Lg l6v+cHd8tSoOos+iW//6/BEBm2VKeFUqjp5gQtBcSnmRreHw3ICXgw8yPqBXFkePkp2Q wDSxRYzSk1wamMMXe2kuNEXTN7kuPFfIe30a1+v0M0oRXThLMZU96nl4z7zwIBj+SdCf CSBnOXf2C/r0jCZAKKDOJjs9ExDPiT69MmOUiJwAl/1COrxP+Lri1cQOuw2K/4dlBt3w huRw==
MIME-Version: 1.0
X-Received: by 10.180.206.144 with SMTP id lo16mr12843480wic.52.1405511477837;  Wed, 16 Jul 2014 04:51:17 -0700 (PDT)
Received: by 10.194.18.198 with HTTP; Wed, 16 Jul 2014 04:51:17 -0700 (PDT)
In-Reply-To: <53C665B0.7040708@gmx.net>
References: <53BBDBEE.703@gmx.net>  <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADAB98C@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C65120.4020302@gmx.net> <53C664DC.50907@mit.edu> <53C665B0.7040708@gmx.net>
Date: Wed, 16 Jul 2014 13:51:17 +0200
Message-ID: 
From: Maciej Machulak 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a11c3843a5d4dec04fe4e245c
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5jdUqpY-rvqEFjNsjPy9Ke09D4k
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 16 Jul 2014 11:51:26 -0000

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

Hi,

Yes, I agree - I think the note should mention UMA. As Justin proposed,
there should be a normative reference to an IETF document.

Kind regards,
Maciej


On 16 July 2014 13:44, Hannes Tschofenig  wrote:

> Interesting background information. Maybe we should then extend the note
> Mike provided to also clarify the relationship with the UMA work (both
> in terms to IPR, copyright, and attribution-wise).


> It would also make sense to state the relationship in the introduction
> to highlight the compatibility, which I believe is a big accomplishment.
>
> Ciao
> Hannes
>
> On 07/16/2014 01:41 PM, Justin Richer wrote:
> > I thought I had sent this note already, but I don't see it in the
> > archives or in my 'sent' folder:
> >
> > If we're going to point to OpenID Connect (which I'm fine with), then w=
e
> > should clarify that portions were also taken from the UMA specification=
.
> > In fact, draft -00 actually *was* the UMA specification text entirely.
> > This is also what the OpenID Connect registration specification was
> > (loosely) based on when it was started.
> >
> > In reality, the relationship between these three documents from three
> > different SBO's is more complicated: they all grew up together and
> > effectively merged to become wire-compatible with each other. There wer=
e
> > a number of changes that were discussed here in the IETF that OpenID
> > Connect adopted, and a number of changes that were discussed at OIDF
> > that were adopted here. OIDC also extends the IETF draft with a set of
> > OIDC-specific metadata fields and editorial language that makes it fit
> > more closely in the OIDC landscape, but make no mistake: they're the
> > same protocol. In the case of UMA, it's a straight normative reference
> > to the IETF document now because we were able to incorporate those use
> > cases and parameters directly.
> >
> > The trouble is, I'm not sure how to concisely state that all that in th=
e
> > draft text, but it's not as simple as "we copied OpenID", which is what
> > the text below seems to say.
> >
> >  -- Justin
> >
> > On 7/16/2014 6:17 AM, Hannes Tschofenig wrote:
> >> Thanks, Mike.
> >>
> >> This is a useful addition and reflects the relationship between the tw=
o
> >> efforts.
> >>
> >> Please add it to the next draft version.
> >>
> >> Ciao
> >> Hannes
> >>
> >> On 07/15/2014 09:46 PM, Mike Jones wrote:
> >>> So that the working group has concrete language to consider, propose
> the
> >>> following language to the OAuth Dynamic Client Registration
> specification:
> >>>
> >>>
> >>>
> >>> Portions of this specification are derived from the OpenID Connect
> >>> Dynamic Registration [OpenID.Registration] specification.  This was
> done
> >>> so that implementations of this specification and OpenID Connect
> Dynamic
> >>> Registration can be compatible with one another.
> >>>
> >>>
> >>>
> >>>                                                             -- Mike
> >>>
> >>>
> >>>
> >>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Mike Jone=
s
> >>> *Sent:* Tuesday, July 08, 2014 7:15 PM
> >>> *To:* Phil Hunt; Hannes Tschofenig
> >>> *Cc:* Maciej Machulak; oauth@ietf.org
> >>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmati=
on
> >>>
> >>>
> >>>
> >>> Thinking about this some more, there is one IPR issue that we need to
> >>> address before publication.  This specification is a derivative work
> >>> from the OpenID Connect Dynamic Registration specification
> >>> http://openid.net/specs/openid-connect-registration-1_0.html.  Large
> >>> portions of the text were copied wholesale from that spec to this one=
,
> >>> so that the two would be compatible.  (This is good thing =E2=80=93 n=
ot a bad
> >>> thing.)
> >>>
> >>>
> >>>
> >>> This is easy to address from an IPR perspective =E2=80=93 simply ackn=
owledge
> >>> that this spec is a derivative work and provide proper attribution.
>  The
> >>> OpenID copyright in the spec at
> >>> http://openid.net/specs/openid-connect-registration-1_0.html#Notices
> >>> allows for this resolution.  It says:
> >>>
> >>>
> >>>
> >>> Copyright (c) 2014 The OpenID Foundation.
> >>>
> >>> The OpenID Foundation (OIDF) grants to any Contributor, developer,
> >>> implementer, or other interested party a non-exclusive, royalty free,
> >>> worldwide copyright license to reproduce, prepare derivative works
> from,
> >>> distribute, perform and display, this Implementers Draft or Final
> >>> Specification solely for the purposes of (i) developing specification=
s,
> >>> and (ii) implementing Implementers Drafts and Final Specifications
> based
> >>> on such documents, provided that attribution be made to the OIDF as t=
he
> >>> source of the material, but that such attribution does not indicate a=
n
> >>> endorsement by the OIDF.
> >>>
> >>> Let=E2=80=99s add the reference and acknowledgment in the next versio=
n.
> >>>
> >>>
> >>>
> >>>                                                             -- Mike
> >>>
> >>>
> >>>
> >>> *From:*Mike Jones
> >>> *Sent:* Tuesday, July 08, 2014 10:06 AM
> >>> *To:* Phil Hunt; Hannes Tschofenig
> >>> *Cc:* John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org
> >>> 
> >>> *Subject:* RE: Dynamic Client Registration: IPR Confirmation
> >>>
> >>>
> >>>
> >>> I likewise do not hold any IPR on these specs.
> >>>
> >>>
> ------------------------------------------------------------------------
> >>>
> >>> *From: *Phil Hunt 
> >>> *Sent: *=E2=80=8E7/=E2=80=8E8/=E2=80=8E2014 9:11 AM
> >>> *To: *Hannes Tschofenig 
> >>> *Cc: *Mike Jones ; John Bradley
> >>> ; Justin Richer ;
> >>> Maciej Machulak ; oauth@ietf.org
> >>> 
> >>> *Subject: *Re: Dynamic Client Registration: IPR Confirmation
> >>>
> >>> I confirm I have no IPR disclosures on this document.
> >>>
> >>> Phil
> >>>
> >>>> On Jul 8, 2014, at 4:54, Hannes Tschofenig  > wrote:
> >>>>
> >>>> Hi Phil, John, Maciej, Justin, Mike,
> >>>>
> >>>> I am working on the shepherd writeup for the dynamic client
> registration
> >>>> document and one item in the template requires me to indicate whethe=
r
> >>>> 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?
> >>>>
> >>>> Ciao
> >>>> Hannes
> >>>>
> >>>>
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


--=20
Maciej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)

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


Hi,

Yes, I agree - I think the note sho=
uld mention UMA. As Justin proposed, there should be a normative reference =
to an IETF document.

Kind regards,
Macie=
j




On 16 July 20=
14 13:44, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:


Interesting background information. Maybe we=
 should then extend the note

Mike provided to also clarify the relationship with the UMA work (both

in terms to IPR, copyright, and attribution-wise).



It would also make sense to state the relationship in the introduction

to highlight the compatibility, which I believe is a big accomplishment.


Ciao

Hannes




On 07/16/2014 01:41 PM, Justin Richer wrote:

> I thought I had sent this note already, but I don't see it in the<=
br>
> archives or in my 'sent' folder:

>

> If we're going to point to OpenID Connect (which I'm fine with=
), then we

> should clarify that portions were also taken from the UMA specificatio=
n.

> In fact, draft -00 actually *was* the UMA specification text entirely.=


> This is also what the OpenID Connect registration specification was
> (loosely) based on when it was started.

>

> In reality, the relationship between these three documents from three<=
br>
> different SBO's is more complicated: they all grew up together and=


> effectively merged to become wire-compatible with each other. There we=
re

> a number of changes that were discussed here in the IETF that OpenID
> Connect adopted, and a number of changes that were discussed at OIDF
> that were adopted here. OIDC also extends the IETF draft with a set of=


> OIDC-specific metadata fields and editorial language that makes it fit=


> more closely in the OIDC landscape, but make no mistake: they're t=
he

> same protocol. In the case of UMA, it's a straight normative refer=
ence

> to the IETF document now because we were able to incorporate those use=


> cases and parameters directly.

>

> The trouble is, I'm not sure how to concisely state that all that =
in the

> draft text, but it's not as simple as "we copied OpenID"=
, which is what

> the text below seems to say.

>

> =C2=A0-- Justin

>

> On 7/16/2014 6:17 AM, Hannes Tschofenig wrote:

>> Thanks, Mike.

>>

>> This is a useful addition and reflects the relationship between th=
e two

>> efforts.

>>

>> Please add it to the next draft version.

>>

>> Ciao

>> Hannes

>>

>> On 07/15/2014 09:46 PM, Mike Jones wrote:

>>> So that the working group has concrete language to consider, p=
ropose the

>>> following language to the OAuth Dynamic Client Registration sp=
ecification:

>>>

>>>

>>>

>>> Portions of this specification are derived from the OpenID Con=
nect

>>> Dynamic Registration [OpenID.Registration] specification. =C2=
=A0This was done

>>> so that implementations of this specification and OpenID Conne=
ct Dynamic

>>> Registration can be compatible with one another.

>>>

>>>

>>>

>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -=
- Mike

>>>

>>>

>>>

>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Mike Jones

>>> *Sent:* Tuesday, July 08, 2014 7:15 PM

>>> *To:* Phil Hunt; Hannes Tschofenig

>>> *Cc:* Maciej Machulak; oauth=
@ietf.org

>>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR Con=
firmation

>>>

>>>

>>>

>>> Thinking about this some more, there is one IPR issue that we =
need to

>>> address before publication. =C2=A0This specification is a deri=
vative work

>>> from the OpenID Connect Dynamic Registration specification

>>> http://openid.net/specs/openid-connect-registr=
ation-1_0.html. =C2=A0Large

>>> portions of the text were copied wholesale from that spec to t=
his one,

>>> so that the two would be compatible. =C2=A0(This is good thing=
 =E2=80=93 not a bad

>>> thing.)

>>>

>>>

>>>

>>> This is easy to address from an IPR perspective =E2=80=93 simp=
ly acknowledge

>>> that this spec is a derivative work and provide proper attribu=
tion. =C2=A0The

>>> OpenID copyright in the spec at

>>> http://openid.net/specs/openid-connect=
-registration-1_0.html#Notices

>>> allows for this resolution. =C2=A0It says:

>>>

>>>

>>>

>>> Copyright (c) 2014 The OpenID Foundation.

>>>

>>> The OpenID Foundation (OIDF) grants to any Contributor, develo=
per,

>>> implementer, or other interested party a non-exclusive, royalt=
y free,

>>> worldwide copyright license to reproduce, prepare derivative w=
orks from,

>>> distribute, perform and display, this Implementers Draft or Fi=
nal

>>> Specification solely for the purposes of (i) developing specif=
ications,

>>> and (ii) implementing Implementers Drafts and Final Specificat=
ions based

>>> on such documents, provided that attribution be made to the OI=
DF as the

>>> source of the material, but that such attribution does not ind=
icate an

>>> endorsement by the OIDF.

>>>

>>> Let=E2=80=99s add the reference and acknowledgment in the next=
 version.

>>>

>>>

>>>

>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -=
- Mike

>>>

>>>

>>>

>>> *From:*Mike Jones

>>> *Sent:* Tuesday, July 08, 2014 10:06 AM

>>> *To:* Phil Hunt; Hannes Tschofenig

>>> *Cc:* John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org

>>> <mailto:oauth@ietf.org>

>>> *Subject:* RE: Dynamic Client Registration: IPR Confirmation
>>>

>>>

>>>

>>> I likewise do not hold any IPR on these specs.

>>>

>>> --------------------------------------------------------------=
----------

>>>

>>> *From: *Phil Hunt <mailto:phil.hunt@oracle.com>

>>> *Sent: *=E2=80=8E7/=E2=80=8E8/=E2=80=8E2014 9:11 AM

>>> *To: *Hannes Tschofenig <mailto:hannes.tschofenig@gmx.net>

>>> *Cc: *Mike Jones <mailto:Michael.Jones@microsoft.com>; John Bradley

>>> <mailto:ve7jtb@ve7jtb.=
com>; Justin Richer <mailto:=
jricher@mitre.org>;

>>> Maciej Machulak <mailto:m.p.machulak@ncl.ac.uk>; oa=
uth@ietf.org

>>> <mailto:oauth@ietf.org>

>>> *Subject: *Re: Dynamic Client Registration: IPR Confirmation
>>>

>>> I confirm I have no IPR disclosures on this document.

>>>

>>> Phil

>>>

>>>> On Jul 8, 2014, at 4:54, Hannes Tschofenig <hannes.tschofenig@gmx.net <mailto:=
hannes.tschofenig@gmx.net&=
gt;> wrote:


>>>>

>>>> Hi Phil, John, Maciej, Justin, Mike,

>>>>

>>>> I am working on the shepherd writeup for the dynamic clien=
t registration

>>>> document and one item in the template requires me to indic=
ate whether

>>>> each document author has confirmed that any and all approp=
riate IPR

>>>> disclosures required for full conformance with the provisi=
ons of BCP 78

>>>> and BCP 79 have already been filed.

>>>>

>>>> Could you please confirm?

>>>>

>>>> Ciao

>>>> Hannes

>>>>

>>>>

>>

>>

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org

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

>





_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





-- 
Maciej M=
achulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 767 (UK)
mob=
ile: +48 602 45 31 66 (PL)



--001a11c3843a5d4dec04fe4e245c--


From nobody Wed Jul 16 04:53:14 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C051B29D3 for ; Wed, 16 Jul 2014 04:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.252
X-Spam-Level: 
X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER5otZwBYOPS for ; Wed, 16 Jul 2014 04:53:07 -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 8775D1B283B for ; Wed, 16 Jul 2014 04:53:07 -0700 (PDT)
X-AuditID: 12074422-f79be6d000007518-fe-53c667a29d98
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 68.2B.29976.2A766C35; Wed, 16 Jul 2014 07:53:06 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s6GBr5Yk003035; Wed, 16 Jul 2014 07:53:06 -0400
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6GBr3NG026022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 16 Jul 2014 07:53:05 -0400
Message-ID: <53C66797.1040509@mit.edu>
Date: Wed, 16 Jul 2014 07:52:55 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Hannes Tschofenig , Mike Jones , "oauth@ietf.org" 
References: <53BBDBEE.703@gmx.net>,  <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADAB98C@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C65120.4020302@gmx.net> <53C664DC.50907@mit.edu> <53C665B0.7040708@gmx.net>
In-Reply-To: <53C665B0.7040708@gmx.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrLso/ViwwekTRhZLd95jtdg77ROL xcm3r9gcmD0Wb9rP5rFkyU8mj9Ydf9kDmKO4bFJSczLLUov07RK4Mnp2X2AruGVRseLVK/YG xme6XYycHBICJhKT30xjh7DFJC7cW8/WxcjFISQwm0liU8sHFghnI6PEhP2P2SGc20wSp5ev AmvhFVCTeHbgKhOIzSKgKtH6fhYbiM0GZM9feQssLioQJXHnUj8rRL2gxMmZT8CmighMYJTY M+sS2CBhAVeJ39N3QO1ezCxxYtE8sA5OAXWJfxceMoPYzAJmEl1buxghbHmJ5q2zmScwCsxC MngWkrJZSMoWMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXVy80s0UtNKd3ECAphdhelHYw/ DyodYhTgYFTi4d0QcjRYiDWxrLgy9xCjJAeTkihvh8WxYCG+pPyUyozE4oz4otKc1OJDjBIc zEoivA7+QDnelMTKqtSifJiUNAeLkjjvW2urYCGB9MSS1OzU1ILUIpisDAeHkgQvQxpQo2BR anpqRVpmTglCmomDE2Q4D9Dwv6kgw4sLEnOLM9Mh8qcYFaXEebeDJARAEhmleXC9sBTzilEc 6BVh3ncgVTzA9ATX/QpoMBPQ4PKawyCDSxIRUlINjO2Pog/wNX2Vfbq3vkUmnPXgAp78PKPg uEbDlBjfqZbXLhyfO0NB4duizee37nBL07q+4cMm/4hdfgcmlMy5M4PVyH6x8dnjTHz/pSN/ a3SKz9gpf7p69qRprmsirk2WXynyQf7jPZbqSZzNhtqNK3uF3Ge7njn6NbHiRVdP14RYk5Wl Vq9OXFNiKc5INNRiLipOBADKuUTpDAMAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/0fld8A6BDjcfaKABuVZlAYRCqlU
Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 16 Jul 2014 11:53:10 -0000

I like the idea of adding some of the text in the introduction, as I 
agree the compatibility is an important (and hard-won) accomplishment. I 
think taking Mike's text, expanding it, and putting it in the 
introduction might serve the overall purpose just fine:

Portions of this specification are derived from the OpenID Connect
Dynamic Registration [OpenID.Registration] specification and from
the User Managed Access [UMA] specification.  This was done
so that implementations of these three specifications will be
compatible with one another.


These are both informative references, so we can reference the ID for UMA.

  -- Justin

On 7/16/2014 7:44 AM, Hannes Tschofenig wrote:
> Interesting background information. Maybe we should then extend the note
> Mike provided to also clarify the relationship with the UMA work (both
> in terms to IPR, copyright, and attribution-wise).
>
> It would also make sense to state the relationship in the introduction
> to highlight the compatibility, which I believe is a big accomplishment.
>
> Ciao
> Hannes
>
> On 07/16/2014 01:41 PM, Justin Richer wrote:
>> I thought I had sent this note already, but I don't see it in the
>> archives or in my 'sent' folder:
>>
>> If we're going to point to OpenID Connect (which I'm fine with), then we
>> should clarify that portions were also taken from the UMA specification.
>> In fact, draft -00 actually *was* the UMA specification text entirely.
>> This is also what the OpenID Connect registration specification was
>> (loosely) based on when it was started.
>>
>> In reality, the relationship between these three documents from three
>> different SBO's is more complicated: they all grew up together and
>> effectively merged to become wire-compatible with each other. There were
>> a number of changes that were discussed here in the IETF that OpenID
>> Connect adopted, and a number of changes that were discussed at OIDF
>> that were adopted here. OIDC also extends the IETF draft with a set of
>> OIDC-specific metadata fields and editorial language that makes it fit
>> more closely in the OIDC landscape, but make no mistake: they're the
>> same protocol. In the case of UMA, it's a straight normative reference
>> to the IETF document now because we were able to incorporate those use
>> cases and parameters directly.
>>
>> The trouble is, I'm not sure how to concisely state that all that in the
>> draft text, but it's not as simple as "we copied OpenID", which is what
>> the text below seems to say.
>>
>>   -- Justin
>>
>> On 7/16/2014 6:17 AM, Hannes Tschofenig wrote:
>>> Thanks, Mike.
>>>
>>> This is a useful addition and reflects the relationship between the two
>>> efforts.
>>>
>>> Please add it to the next draft version.
>>>
>>> Ciao
>>> Hannes
>>>
>>> On 07/15/2014 09:46 PM, Mike Jones wrote:
>>>> So that the working group has concrete language to consider, propose the
>>>> following language to the OAuth Dynamic Client Registration specification:
>>>>
>>>>   
>>>>
>>>> Portions of this specification are derived from the OpenID Connect
>>>> Dynamic Registration [OpenID.Registration] specification.  This was done
>>>> so that implementations of this specification and OpenID Connect Dynamic
>>>> Registration can be compatible with one another.
>>>>
>>>>   
>>>>
>>>>                                                              -- Mike
>>>>
>>>>   
>>>>
>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Mike Jones
>>>> *Sent:* Tuesday, July 08, 2014 7:15 PM
>>>> *To:* Phil Hunt; Hannes Tschofenig
>>>> *Cc:* Maciej Machulak; oauth@ietf.org
>>>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
>>>>
>>>>   
>>>>
>>>> Thinking about this some more, there is one IPR issue that we need to
>>>> address before publication.  This specification is a derivative work
>>>> from the OpenID Connect Dynamic Registration specification
>>>> http://openid.net/specs/openid-connect-registration-1_0.html.  Large
>>>> portions of the text were copied wholesale from that spec to this one,
>>>> so that the two would be compatible.  (This is good thing – not a bad
>>>> thing.)
>>>>
>>>>   
>>>>
>>>> This is easy to address from an IPR perspective – simply acknowledge
>>>> that this spec is a derivative work and provide proper attribution.  The
>>>> OpenID copyright in the spec at
>>>> http://openid.net/specs/openid-connect-registration-1_0.html#Notices
>>>> allows for this resolution.  It says:
>>>>
>>>>   
>>>>
>>>> Copyright (c) 2014 The OpenID Foundation.
>>>>
>>>> The OpenID Foundation (OIDF) grants to any Contributor, developer,
>>>> implementer, or other interested party a non-exclusive, royalty free,
>>>> worldwide copyright license to reproduce, prepare derivative works from,
>>>> distribute, perform and display, this Implementers Draft or Final
>>>> Specification solely for the purposes of (i) developing specifications,
>>>> and (ii) implementing Implementers Drafts and Final Specifications based
>>>> on such documents, provided that attribution be made to the OIDF as the
>>>> source of the material, but that such attribution does not indicate an
>>>> endorsement by the OIDF.
>>>>
>>>> Let’s add the reference and acknowledgment in the next version.
>>>>
>>>>   
>>>>
>>>>                                                              -- Mike
>>>>
>>>>   
>>>>
>>>> *From:*Mike Jones
>>>> *Sent:* Tuesday, July 08, 2014 10:06 AM
>>>> *To:* Phil Hunt; Hannes Tschofenig
>>>> *Cc:* John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org
>>>> 
>>>> *Subject:* RE: Dynamic Client Registration: IPR Confirmation
>>>>
>>>>   
>>>>
>>>> I likewise do not hold any IPR on these specs.
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> *From: *Phil Hunt 
>>>> *Sent: *‎7/‎8/‎2014 9:11 AM
>>>> *To: *Hannes Tschofenig 
>>>> *Cc: *Mike Jones ; John Bradley
>>>> ; Justin Richer ;
>>>> Maciej Machulak ; oauth@ietf.org
>>>> 
>>>> *Subject: *Re: Dynamic Client Registration: IPR Confirmation
>>>>
>>>> I confirm I have no IPR disclosures on this document.
>>>>
>>>> Phil
>>>>
>>>>> On Jul 8, 2014, at 4:54, Hannes Tschofenig > wrote:
>>>>>
>>>>> Hi Phil, John, Maciej, Justin, Mike,
>>>>>
>>>>> I am working on the shepherd writeup for the dynamic client registration
>>>>> document and 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?
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth


From nobody Wed Jul 16 05:35:07 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADBF1B2849 for ; Wed, 16 Jul 2014 05:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ey4lPwgzMRh for ; Wed, 16 Jul 2014 05:35:03 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429E21B2836 for ; Wed, 16 Jul 2014 05:35:03 -0700 (PDT)
Received: from DM2PR03CA010.namprd03.prod.outlook.com (10.141.52.158) by BLUPR03MB615.namprd03.prod.outlook.com (10.255.124.43) with Microsoft SMTP Server (TLS) id 15.0.985.8; Wed, 16 Jul 2014 12:35:01 +0000
Received: from BL2FFO11FD012.protection.gbl (2a01:111:f400:7c09::123) by DM2PR03CA010.outlook.office365.com (2a01:111:e400:2414::30) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Wed, 16 Jul 2014 12:35:00 +0000
Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD012.mail.protection.outlook.com (10.173.161.18) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 16 Jul 2014 12:35:00 +0000
Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0195.002; Wed, 16 Jul 2014 12:34:49 +0000
From: Mike Jones 
To: Justin Richer , Hannes Tschofenig , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
Thread-Index: AQHPmqNjTLUtygPATEaoV9K+QkTus5uWWTqAgAAPVUaAAJbWEIAKle1ggADzlQCAABeGAIAAAP0AgAACRICAAAIDwA==
Date: Wed, 16 Jul 2014 12:34:49 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADCB3B3@TK5EX14MBXC294.redmond.corp.microsoft.com>
References: <53BBDBEE.703@gmx.net>,  <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADAB98C@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C65120.4020302@gmx.net> <53C664DC.50907@mit.edu> <53C665B0.7040708@gmx.net> <53C66797.1040509@mit.edu>
In-Reply-To: <53C66797.1040509@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.37]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(199002)(164054003)(189002)(13464003)(55885003)(479174003)(377454003)(24454002)(51704005)(86362001)(15395725005)(76176999)(15202345003)(74662001)(80022001)(106116001)(19580395003)(106466001)(81156004)(95666004)(107046002)(99396002)(83072002)(31966008)(92726001)(92566001)(23676002)(93886003)(50986999)(54356999)(76482001)(104016003)(85852003)(2656002)(2171001)(55846006)(77982001)(87936001)(6806004)(86612001)(81342001)(84676001)(26826002)(69596002)(66066001)(64706001)(79102001)(50466002)(15975445006)(107886001)(85306003)(46102001)(4396001)(77096002)(97736001)(68736004)(33656002)(83322001)(44976005)(74502001)(20776003)(81542001)(47776003)(21056001)(19580405001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB615; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; 
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0274272F87
Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; 
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/mRUUBqDQjJe5wnf-BoXkkKH7yfo
Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 16 Jul 2014 12:35:06 -0000

SSBkaXNhZ3JlZSB3aXRoIG9uZSBhc3BlY3Qgb2YgSnVzdGluJ3MgY2hhcmFjdGVyaXphdGlvbiBv
ZiB0aGUgaGlzdG9yeSBvZiB0aGUgc3BlYyBhbmQgaGF2ZSBkYXRhIHRvIGJhY2sgdXAgbXkgZGlz
YWdyZWVtZW50LiAgVGhlIE9wZW5JRCBDb25uZWN0IER5bmFtaWMgUmVnaXN0cmF0aW9uIFNwZWNp
ZmljYXRpb24gd2FzIG5vdCBiYXNlZCBvbiBkcmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctMDAgb3Ig
dGhlIFVNQSBzcGVjaWZpY2F0aW9uLiAgSXQgd2FzIGNyZWF0ZWQgaW5kZXBlbmRlbnRseSBieSBK
b2huIEJyYWRsZXkgaW4gSnVuZSAyMDExIGJhc2VkIHVwb24gT3BlbklEIENvbm5lY3Qgd29ya2lu
ZyBncm91cCBkaXNjdXNzaW9ucyB0aGF0IHByZWRhdGVkIGRyYWZ0LWlldGYtb2F1dGgtZHluLXJl
Zy0wMCwgYW5kIGZvciB3aGljaCB0aGVyZSBhcmUgd29ya2luZyBncm91cCBub3RlcyBkb2N1bWVu
dGluZyB0aGUgT3BlbklEIENvbm5lY3Qgd29ya2luZyBncm91cCBkZWNpc2lvbnMgcHJpb3IgdG8g
dGhlIElFVEYgLTAwIGRyYWZ0LiAgWWVzLCB0aGVyZSdzIHBsZW50eSBvZiBldmlkZW5jZSB0aGF0
IHRoZSBJRVRGIC0wMSBkcmFmdCBjb3BpZWQgdGV4dCBmcm9tIHRoZSBlYXJseSBPcGVuSUQgQ29u
bmVjdCBkcmFmdCAoaW5jbHVkaW5nIGluIHRoZSBjaGFuZ2UgaGlzdG9yeSksIGJ1dCB0aGUgQ29u
bmVjdCBhdXRob3JzIHdlcmUgY2FyZWZ1bCB0byBmb2xsb3cgdGhlIE9wZW5JRCBGb3VuZGF0aW9u
J3MgSVBSIHByb2Nlc3MgYW5kIG5vdCBpbmNvcnBvcmF0ZSBjb250cmlidXRpb25zIGZyb20gdGhp
cmQgcGFydGllcyB3aG8gaGFkbid0IHNpZ25lZCBhbiBPcGVuSUQgSVBSIENvbnRyaWJ1dGlvbiBB
Z3JlZW1lbnQgc3RhdGluZyB0aGF0IHRoZSBPcGVuSUQgRm91bmRhdGlvbiB3YXMgZnJlZSB0byB1
c2UgdGhlaXIgY29udHJpYnV0aW9ucy4gIChUaGlzIGZpbGxzIHRoZSBzYW1lIHJvbGUgYXMgdGhl
IElFVEYgTm90ZSB3ZWxsLCBidXQgd2l0aCBhIHNpZ25lZCBhZ3JlZW1lbnQsIGFuZCBlbnN1cmVz
IHRoYXQgYWxsIGRldmVsb3BlcnMgY2FuIHVzZSB0aGUgcmVzdWx0aW5nIHNwZWNpZmljYXRpb25z
IHdpdGhvdXQgSVBSIGNvbmNlcm5zIGJhc2VkIG9uIElQUiB0aGF0IG1heSBiZSBoZWxkIGJ5IHRo
ZSBjb250cmlidXRvcnMuKSAgVGhlIE9wZW5JRCBDb25uZWN0IER5bmFtaWMgUmVnaXN0cmF0aW9u
IGRyYWZ0IGRpZG4ndCBjb3B5IGZyb20gdGhlIFVNQSBkcmFmdCBvciB0aGUgSUVURiBkcmFmdCBk
ZXJpdmVkIGZyb20gaXQsIHNvIGFzIHRvIG1haW50YWluIHRoZSBJUFIgaW50ZWdyaXR5IG9mIHRo
ZSBPcGVuSUQgZG9jdW1lbnQuICBUaGUgY29weWluZyBhbGwgd2VudCBpbiB0aGUgb3RoZXIgZGly
ZWN0aW9uLg0KDQpJZiBwb3J0aW9ucyBvZiB0aGUgVU1BIGRyYWZ0IHJlbWFpbmVkIGZyb20gLTAw
IGluIHRoZSBjdXJyZW50IGRyYWZ0cywgSSdkIGJlIGZpbmUgd2l0aCB0aGUgVU1BIGF0dHJpYnV0
aW9uLCBidXQgaW4gcHJhY3RpY2UgdGhleSBkb24ndC4gIFRoZSBVTUEgY29udGVudCB3YXMgcmVw
bGFjZWQgd2l0aCB0aGUgT3BlbklEIENvbm5lY3QgY29udGVudC4gIChJIGJlbGlldmUgdGhhdCBl
dmVudHVhbGx5IFVNQSBkZWNpZGVkIHRvIGRyb3AgdGhlaXIgb2xkIGRyYWZ0IGFuZCBtb3ZlIHRv
IHJlZ2lzdHJhdGlvbiBtZWNoYW5pc21zIHRoYXQgd2VyZSBjb21wYXRpYmxlIHdpdGggQ29ubmVj
dCBhcyB3ZWxsLCBhbmQgc3RvcHBlZCB1c2luZyB0aGVpciBwcmV2aW91cyByZWdpc3RyYXRpb24g
ZGF0YSBmb3JtYXRzLikNCg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCkZyb206IEp1c3RpbiBSaWNoZXIgW21haWx0bzpqcmljaGVyQE1JVC5FRFVdIA0KU2VudDog
V2VkbmVzZGF5LCBKdWx5IDE2LCAyMDE0IDQ6NTMgQU0NClRvOiBIYW5uZXMgVHNjaG9mZW5pZzsg
TWlrZSBKb25lczsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIER5bmFt
aWMgQ2xpZW50IFJlZ2lzdHJhdGlvbjogSVBSIENvbmZpcm1hdGlvbg0KDQpJIGxpa2UgdGhlIGlk
ZWEgb2YgYWRkaW5nIHNvbWUgb2YgdGhlIHRleHQgaW4gdGhlIGludHJvZHVjdGlvbiwgYXMgSSBh
Z3JlZSB0aGUgY29tcGF0aWJpbGl0eSBpcyBhbiBpbXBvcnRhbnQgKGFuZCBoYXJkLXdvbikgYWNj
b21wbGlzaG1lbnQuIEkgdGhpbmsgdGFraW5nIE1pa2UncyB0ZXh0LCBleHBhbmRpbmcgaXQsIGFu
ZCBwdXR0aW5nIGl0IGluIHRoZSBpbnRyb2R1Y3Rpb24gbWlnaHQgc2VydmUgdGhlIG92ZXJhbGwg
cHVycG9zZSBqdXN0IGZpbmU6DQoNClBvcnRpb25zIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBhcmUg
ZGVyaXZlZCBmcm9tIHRoZSBPcGVuSUQgQ29ubmVjdCBEeW5hbWljIFJlZ2lzdHJhdGlvbiBbT3Bl
bklELlJlZ2lzdHJhdGlvbl0gc3BlY2lmaWNhdGlvbiBhbmQgZnJvbSB0aGUgVXNlciBNYW5hZ2Vk
IEFjY2VzcyBbVU1BXSBzcGVjaWZpY2F0aW9uLiAgVGhpcyB3YXMgZG9uZSBzbyB0aGF0IGltcGxl
bWVudGF0aW9ucyBvZiB0aGVzZSB0aHJlZSBzcGVjaWZpY2F0aW9ucyB3aWxsIGJlIGNvbXBhdGli
bGUgd2l0aCBvbmUgYW5vdGhlci4NCg0KDQpUaGVzZSBhcmUgYm90aCBpbmZvcm1hdGl2ZSByZWZl
cmVuY2VzLCBzbyB3ZSBjYW4gcmVmZXJlbmNlIHRoZSBJRCBmb3IgVU1BLg0KDQogIC0tIEp1c3Rp
bg0KDQpPbiA3LzE2LzIwMTQgNzo0NCBBTSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+IElu
dGVyZXN0aW5nIGJhY2tncm91bmQgaW5mb3JtYXRpb24uIE1heWJlIHdlIHNob3VsZCB0aGVuIGV4
dGVuZCB0aGUgDQo+IG5vdGUgTWlrZSBwcm92aWRlZCB0byBhbHNvIGNsYXJpZnkgdGhlIHJlbGF0
aW9uc2hpcCB3aXRoIHRoZSBVTUEgd29yayANCj4gKGJvdGggaW4gdGVybXMgdG8gSVBSLCBjb3B5
cmlnaHQsIGFuZCBhdHRyaWJ1dGlvbi13aXNlKS4NCj4NCj4gSXQgd291bGQgYWxzbyBtYWtlIHNl
bnNlIHRvIHN0YXRlIHRoZSByZWxhdGlvbnNoaXAgaW4gdGhlIGludHJvZHVjdGlvbiANCj4gdG8g
aGlnaGxpZ2h0IHRoZSBjb21wYXRpYmlsaXR5LCB3aGljaCBJIGJlbGlldmUgaXMgYSBiaWcgYWNj
b21wbGlzaG1lbnQuDQo+DQo+IENpYW8NCj4gSGFubmVzDQo+DQo+IE9uIDA3LzE2LzIwMTQgMDE6
NDEgUE0sIEp1c3RpbiBSaWNoZXIgd3JvdGU6DQo+PiBJIHRob3VnaHQgSSBoYWQgc2VudCB0aGlz
IG5vdGUgYWxyZWFkeSwgYnV0IEkgZG9uJ3Qgc2VlIGl0IGluIHRoZSANCj4+IGFyY2hpdmVzIG9y
IGluIG15ICdzZW50JyBmb2xkZXI6DQo+Pg0KPj4gSWYgd2UncmUgZ29pbmcgdG8gcG9pbnQgdG8g
T3BlbklEIENvbm5lY3QgKHdoaWNoIEknbSBmaW5lIHdpdGgpLCB0aGVuIA0KPj4gd2Ugc2hvdWxk
IGNsYXJpZnkgdGhhdCBwb3J0aW9ucyB3ZXJlIGFsc28gdGFrZW4gZnJvbSB0aGUgVU1BIHNwZWNp
ZmljYXRpb24uDQo+PiBJbiBmYWN0LCBkcmFmdCAtMDAgYWN0dWFsbHkgKndhcyogdGhlIFVNQSBz
cGVjaWZpY2F0aW9uIHRleHQgZW50aXJlbHkuDQo+PiBUaGlzIGlzIGFsc28gd2hhdCB0aGUgT3Bl
bklEIENvbm5lY3QgcmVnaXN0cmF0aW9uIHNwZWNpZmljYXRpb24gd2FzDQo+PiAobG9vc2VseSkg
YmFzZWQgb24gd2hlbiBpdCB3YXMgc3RhcnRlZC4NCj4+DQo+PiBJbiByZWFsaXR5LCB0aGUgcmVs
YXRpb25zaGlwIGJldHdlZW4gdGhlc2UgdGhyZWUgZG9jdW1lbnRzIGZyb20gdGhyZWUgDQo+PiBk
aWZmZXJlbnQgU0JPJ3MgaXMgbW9yZSBjb21wbGljYXRlZDogdGhleSBhbGwgZ3JldyB1cCB0b2dl
dGhlciBhbmQgDQo+PiBlZmZlY3RpdmVseSBtZXJnZWQgdG8gYmVjb21lIHdpcmUtY29tcGF0aWJs
ZSB3aXRoIGVhY2ggb3RoZXIuIFRoZXJlIA0KPj4gd2VyZSBhIG51bWJlciBvZiBjaGFuZ2VzIHRo
YXQgd2VyZSBkaXNjdXNzZWQgaGVyZSBpbiB0aGUgSUVURiB0aGF0IA0KPj4gT3BlbklEIENvbm5l
Y3QgYWRvcHRlZCwgYW5kIGEgbnVtYmVyIG9mIGNoYW5nZXMgdGhhdCB3ZXJlIGRpc2N1c3NlZCAN
Cj4+IGF0IE9JREYgdGhhdCB3ZXJlIGFkb3B0ZWQgaGVyZS4gT0lEQyBhbHNvIGV4dGVuZHMgdGhl
IElFVEYgZHJhZnQgd2l0aCANCj4+IGEgc2V0IG9mIE9JREMtc3BlY2lmaWMgbWV0YWRhdGEgZmll
bGRzIGFuZCBlZGl0b3JpYWwgbGFuZ3VhZ2UgdGhhdCANCj4+IG1ha2VzIGl0IGZpdCBtb3JlIGNs
b3NlbHkgaW4gdGhlIE9JREMgbGFuZHNjYXBlLCBidXQgbWFrZSBubyBtaXN0YWtlOiANCj4+IHRo
ZXkncmUgdGhlIHNhbWUgcHJvdG9jb2wuIEluIHRoZSBjYXNlIG9mIFVNQSwgaXQncyBhIHN0cmFp
Z2h0IA0KPj4gbm9ybWF0aXZlIHJlZmVyZW5jZSB0byB0aGUgSUVURiBkb2N1bWVudCBub3cgYmVj
YXVzZSB3ZSB3ZXJlIGFibGUgdG8gDQo+PiBpbmNvcnBvcmF0ZSB0aG9zZSB1c2UgY2FzZXMgYW5k
IHBhcmFtZXRlcnMgZGlyZWN0bHkuDQo+Pg0KPj4gVGhlIHRyb3VibGUgaXMsIEknbSBub3Qgc3Vy
ZSBob3cgdG8gY29uY2lzZWx5IHN0YXRlIHRoYXQgYWxsIHRoYXQgaW4gDQo+PiB0aGUgZHJhZnQg
dGV4dCwgYnV0IGl0J3Mgbm90IGFzIHNpbXBsZSBhcyAid2UgY29waWVkIE9wZW5JRCIsIHdoaWNo
IA0KPj4gaXMgd2hhdCB0aGUgdGV4dCBiZWxvdyBzZWVtcyB0byBzYXkuDQo+Pg0KPj4gICAtLSBK
dXN0aW4NCj4+DQo+PiBPbiA3LzE2LzIwMTQgNjoxNyBBTSwgSGFubmVzIFRzY2hvZmVuaWcgd3Jv
dGU6DQo+Pj4gVGhhbmtzLCBNaWtlLg0KPj4+DQo+Pj4gVGhpcyBpcyBhIHVzZWZ1bCBhZGRpdGlv
biBhbmQgcmVmbGVjdHMgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSANCj4+PiB0d28gZWZm
b3J0cy4NCj4+Pg0KPj4+IFBsZWFzZSBhZGQgaXQgdG8gdGhlIG5leHQgZHJhZnQgdmVyc2lvbi4N
Cj4+Pg0KPj4+IENpYW8NCj4+PiBIYW5uZXMNCj4+Pg0KPj4+IE9uIDA3LzE1LzIwMTQgMDk6NDYg
UE0sIE1pa2UgSm9uZXMgd3JvdGU6DQo+Pj4+IFNvIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFz
IGNvbmNyZXRlIGxhbmd1YWdlIHRvIGNvbnNpZGVyLCANCj4+Pj4gcHJvcG9zZSB0aGUgZm9sbG93
aW5nIGxhbmd1YWdlIHRvIHRoZSBPQXV0aCBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gc3Bl
Y2lmaWNhdGlvbjoNCj4+Pj4NCj4+Pj4gICANCj4+Pj4NCj4+Pj4gUG9ydGlvbnMgb2YgdGhpcyBz
cGVjaWZpY2F0aW9uIGFyZSBkZXJpdmVkIGZyb20gdGhlIE9wZW5JRCBDb25uZWN0IA0KPj4+PiBE
eW5hbWljIFJlZ2lzdHJhdGlvbiBbT3BlbklELlJlZ2lzdHJhdGlvbl0gc3BlY2lmaWNhdGlvbi4g
IFRoaXMgd2FzIA0KPj4+PiBkb25lIHNvIHRoYXQgaW1wbGVtZW50YXRpb25zIG9mIHRoaXMgc3Bl
Y2lmaWNhdGlvbiBhbmQgT3BlbklEIA0KPj4+PiBDb25uZWN0IER5bmFtaWMgUmVnaXN0cmF0aW9u
IGNhbiBiZSBjb21wYXRpYmxlIHdpdGggb25lIGFub3RoZXIuDQo+Pj4+DQo+Pj4+ICAgDQo+Pj4+
DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAtLSANCj4+Pj4gTWlrZQ0KPj4+Pg0KPj4+PiAgIA0KPj4+Pg0KPj4+PiAqRnJv
bToqT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpN
aWtlIA0KPj4+PiBKb25lcw0KPj4+PiAqU2VudDoqIFR1ZXNkYXksIEp1bHkgMDgsIDIwMTQgNzox
NSBQTQ0KPj4+PiAqVG86KiBQaGlsIEh1bnQ7IEhhbm5lcyBUc2Nob2ZlbmlnDQo+Pj4+ICpDYzoq
IE1hY2llaiBNYWNodWxhazsgb2F1dGhAaWV0Zi5vcmcNCj4+Pj4gKlN1YmplY3Q6KiBSZTogW09B
VVRILVdHXSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb246IElQUiANCj4+Pj4gQ29uZmlybWF0
aW9uDQo+Pj4+DQo+Pj4+ICAgDQo+Pj4+DQo+Pj4+IFRoaW5raW5nIGFib3V0IHRoaXMgc29tZSBt
b3JlLCB0aGVyZSBpcyBvbmUgSVBSIGlzc3VlIHRoYXQgd2UgbmVlZCANCj4+Pj4gdG8gYWRkcmVz
cyBiZWZvcmUgcHVibGljYXRpb24uICBUaGlzIHNwZWNpZmljYXRpb24gaXMgYSBkZXJpdmF0aXZl
IA0KPj4+PiB3b3JrIGZyb20gdGhlIE9wZW5JRCBDb25uZWN0IER5bmFtaWMgUmVnaXN0cmF0aW9u
IHNwZWNpZmljYXRpb24gDQo+Pj4+IGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25u
ZWN0LXJlZ2lzdHJhdGlvbi0xXzAuaHRtbC4gIA0KPj4+PiBMYXJnZSBwb3J0aW9ucyBvZiB0aGUg
dGV4dCB3ZXJlIGNvcGllZCB3aG9sZXNhbGUgZnJvbSB0aGF0IHNwZWMgdG8gDQo+Pj4+IHRoaXMg
b25lLCBzbyB0aGF0IHRoZSB0d28gd291bGQgYmUgY29tcGF0aWJsZS4gIChUaGlzIGlzIGdvb2Qg
dGhpbmcgDQo+Pj4+IOKAkyBub3QgYSBiYWQNCj4+Pj4gdGhpbmcuKQ0KPj4+Pg0KPj4+PiAgIA0K
Pj4+Pg0KPj4+PiBUaGlzIGlzIGVhc3kgdG8gYWRkcmVzcyBmcm9tIGFuIElQUiBwZXJzcGVjdGl2
ZSDigJMgc2ltcGx5IA0KPj4+PiBhY2tub3dsZWRnZSB0aGF0IHRoaXMgc3BlYyBpcyBhIGRlcml2
YXRpdmUgd29yayBhbmQgcHJvdmlkZSBwcm9wZXIgDQo+Pj4+IGF0dHJpYnV0aW9uLiAgVGhlIE9w
ZW5JRCBjb3B5cmlnaHQgaW4gdGhlIHNwZWMgYXQgDQo+Pj4+IGh0dHA6Ly9vcGVuaWQubmV0L3Nw
ZWNzL29wZW5pZC1jb25uZWN0LXJlZ2lzdHJhdGlvbi0xXzAuaHRtbCNOb3RpY2UNCj4+Pj4gcyBh
bGxvd3MgZm9yIHRoaXMgcmVzb2x1dGlvbi4gIEl0IHNheXM6DQo+Pj4+DQo+Pj4+ICAgDQo+Pj4+
DQo+Pj4+IENvcHlyaWdodCAoYykgMjAxNCBUaGUgT3BlbklEIEZvdW5kYXRpb24uDQo+Pj4+DQo+
Pj4+IFRoZSBPcGVuSUQgRm91bmRhdGlvbiAoT0lERikgZ3JhbnRzIHRvIGFueSBDb250cmlidXRv
ciwgZGV2ZWxvcGVyLCANCj4+Pj4gaW1wbGVtZW50ZXIsIG9yIG90aGVyIGludGVyZXN0ZWQgcGFy
dHkgYSBub24tZXhjbHVzaXZlLCByb3lhbHR5IA0KPj4+PiBmcmVlLCB3b3JsZHdpZGUgY29weXJp
Z2h0IGxpY2Vuc2UgdG8gcmVwcm9kdWNlLCBwcmVwYXJlIGRlcml2YXRpdmUgDQo+Pj4+IHdvcmtz
IGZyb20sIGRpc3RyaWJ1dGUsIHBlcmZvcm0gYW5kIGRpc3BsYXksIHRoaXMgSW1wbGVtZW50ZXJz
IA0KPj4+PiBEcmFmdCBvciBGaW5hbCBTcGVjaWZpY2F0aW9uIHNvbGVseSBmb3IgdGhlIHB1cnBv
c2VzIG9mIChpKSANCj4+Pj4gZGV2ZWxvcGluZyBzcGVjaWZpY2F0aW9ucywgYW5kIChpaSkgaW1w
bGVtZW50aW5nIEltcGxlbWVudGVycyANCj4+Pj4gRHJhZnRzIGFuZCBGaW5hbCBTcGVjaWZpY2F0
aW9ucyBiYXNlZCBvbiBzdWNoIGRvY3VtZW50cywgcHJvdmlkZWQgDQo+Pj4+IHRoYXQgYXR0cmli
dXRpb24gYmUgbWFkZSB0byB0aGUgT0lERiBhcyB0aGUgc291cmNlIG9mIHRoZSBtYXRlcmlhbCwg
DQo+Pj4+IGJ1dCB0aGF0IHN1Y2ggYXR0cmlidXRpb24gZG9lcyBub3QgaW5kaWNhdGUgYW4gZW5k
b3JzZW1lbnQgYnkgdGhlIE9JREYuDQo+Pj4+DQo+Pj4+IExldOKAmXMgYWRkIHRoZSByZWZlcmVu
Y2UgYW5kIGFja25vd2xlZGdtZW50IGluIHRoZSBuZXh0IHZlcnNpb24uDQo+Pj4+DQo+Pj4+ICAg
DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAtLSANCj4+Pj4gTWlrZQ0KPj4+Pg0KPj4+PiAgIA0KPj4+Pg0KPj4+
PiAqRnJvbToqTWlrZSBKb25lcw0KPj4+PiAqU2VudDoqIFR1ZXNkYXksIEp1bHkgMDgsIDIwMTQg
MTA6MDYgQU0NCj4+Pj4gKlRvOiogUGhpbCBIdW50OyBIYW5uZXMgVHNjaG9mZW5pZw0KPj4+PiAq
Q2M6KiBKb2huIEJyYWRsZXk7IEp1c3RpbiBSaWNoZXI7IE1hY2llaiBNYWNodWxhazsgb2F1dGhA
aWV0Zi5vcmcgDQo+Pj4+IDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQo+Pj4+ICpTdWJqZWN0Oiog
UkU6IER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbjogSVBSIENvbmZpcm1hdGlvbg0KPj4+Pg0K
Pj4+PiAgIA0KPj4+Pg0KPj4+PiBJIGxpa2V3aXNlIGRvIG5vdCBob2xkIGFueSBJUFIgb24gdGhl
c2Ugc3BlY3MuDQo+Pj4+DQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gLS0tLS0NCj4+Pj4NCj4+Pj4g
KkZyb206ICpQaGlsIEh1bnQgPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCj4+Pj4gKlNl
bnQ6ICrigI43L+KAjjgv4oCOMjAxNCA5OjExIEFNDQo+Pj4+ICpUbzogKkhhbm5lcyBUc2Nob2Zl
bmlnIDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4NCj4+Pj4gKkNjOiAqTWlrZSBK
b25lcyA8bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IEpvaG4gQnJhZGxleSAN
Cj4+Pj4gPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT47IEp1c3RpbiBSaWNoZXIgDQo+Pj4+IDxt
YWlsdG86anJpY2hlckBtaXRyZS5vcmc+OyBNYWNpZWogTWFjaHVsYWsgDQo+Pj4+IDxtYWlsdG86
bS5wLm1hY2h1bGFrQG5jbC5hYy51az47IG9hdXRoQGlldGYub3JnIA0KPj4+PiA8bWFpbHRvOm9h
dXRoQGlldGYub3JnPg0KPj4+PiAqU3ViamVjdDogKlJlOiBEeW5hbWljIENsaWVudCBSZWdpc3Ry
YXRpb246IElQUiBDb25maXJtYXRpb24NCj4+Pj4NCj4+Pj4gSSBjb25maXJtIEkgaGF2ZSBubyBJ
UFIgZGlzY2xvc3VyZXMgb24gdGhpcyBkb2N1bWVudC4NCj4+Pj4NCj4+Pj4gUGhpbA0KPj4+Pg0K
Pj4+Pj4gT24gSnVsIDgsIDIwMTQsIGF0IDQ6NTQsIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMu
dHNjaG9mZW5pZ0BnbXgubmV0IDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdy
b3RlOg0KPj4+Pj4NCj4+Pj4+IEhpIFBoaWwsIEpvaG4sIE1hY2llaiwgSnVzdGluLCBNaWtlLA0K
Pj4+Pj4NCj4+Pj4+IEkgYW0gd29ya2luZyBvbiB0aGUgc2hlcGhlcmQgd3JpdGV1cCBmb3IgdGhl
IGR5bmFtaWMgY2xpZW50IA0KPj4+Pj4gcmVnaXN0cmF0aW9uIGRvY3VtZW50IGFuZCBvbmUgaXRl
bSBpbiB0aGUgdGVtcGxhdGUgcmVxdWlyZXMgbWUgdG8gDQo+Pj4+PiBpbmRpY2F0ZSB3aGV0aGVy
IGVhY2ggZG9jdW1lbnQgYXV0aG9yIGhhcyBjb25maXJtZWQgdGhhdCBhbnkgYW5kIA0KPj4+Pj4g
YWxsIGFwcHJvcHJpYXRlIElQUiBkaXNjbG9zdXJlcyByZXF1aXJlZCBmb3IgZnVsbCBjb25mb3Jt
YW5jZSB3aXRoIA0KPj4+Pj4gdGhlIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkgaGF2
ZSBhbHJlYWR5IGJlZW4gZmlsZWQuDQo+Pj4+Pg0KPj4+Pj4gQ291bGQgeW91IHBsZWFzZSBjb25m
aXJtPw0KPj4+Pj4NCj4+Pj4+IENpYW8NCj4+Pj4+IEhhbm5lcw0KPj4+Pj4NCj4+Pj4+DQo+Pj4N
Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+
IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+IE9BdXRoQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo=


From nobody Wed Jul 16 05:54:31 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9981B2B53 for ; Wed, 16 Jul 2014 05:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.252
X-Spam-Level: 
X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuAyFhfWAstx for ; Wed, 16 Jul 2014 05:54:25 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC55C1B2AFC for ; Wed, 16 Jul 2014 05:54:22 -0700 (PDT)
X-AuditID: 12074423-f79bf6d000007580-13-53c675fdf42e
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id D5.5C.30080.DF576C35; Wed, 16 Jul 2014 08:54:21 -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 s6GCsKen004804; Wed, 16 Jul 2014 08:54:21 -0400
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6GCsIaP009729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 16 Jul 2014 08:54:19 -0400
Message-ID: <53C675F1.9080102@mit.edu>
Date: Wed, 16 Jul 2014 08:54:09 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Mike Jones , Hannes Tschofenig , "oauth@ietf.org" 
References: <53BBDBEE.703@gmx.net>,  <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADAB98C@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C65120.4020302@gmx.net> <53C664DC.50907@mit.edu> <53C665B0.7040708@gmx.net> <53C66797.1040509@mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADCB3B3@TK5EX14MBXC294.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADCB3B3@TK5EX14MBXC294.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6novu39FiwwaEFMhZLd95jtdg77ROL xcm3r9gcmD0Wb9rP5rFkyU8mj9Ydf9kDmKO4bFJSczLLUov07RK4Mj48ucVY8Dy2omHTX7YG xufeXYwcHBICJhLz/4t1MXICmWISF+6tZ+ti5OIQEpjNJNHd94EZwtnIKPHkwBpWCOc2k8ST RxNZQVp4BdQk1n7ZwwgyiUVAVWLSIQWQMBuQOX/lLSYQW1QgSuLOpX6ockGJkzOfsIDMERGY wCgxf+ZcRpCEsICrxO/pO6BWT2aReHBqMRtIglMgUaL10XIWEJtZwEyia2sXI4StLbFs4Wvm CYwCs5AMnoWkbBaSsgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfRyM0v0UlNKNzGCw9dF eQfjn4NKhxgFOBiVeHg3hBwNFmJNLCuuzD3EKMnBpCTK22FxLFiILyk/pTIjsTgjvqg0J7X4 EKMEB7OSCK+DP1CONyWxsiq1KB8mJc3BoiTO+9baKlhIID2xJDU7NbUgtQgmK8PBoSTBm1kC 1ChYlJqeWpGWmVOCkGbi4AQZzgM0fBJIDW9xQWJucWY6RP4Uo6KUOO/ZYqCEAEgiozQPrheW Xl4xigO9IsxbA9LOA0xNcN2vgAYzAQ0urzkMMrgkESEl1cC4sKEmqnN50e8FpxjLJvOGHI5r 2rtT8dd0D9eZ8r3uZ7j6U1ZcXPJ+1U+xazZbJ8V+tl20W36l503/KWdUTbirn3SVvf7sqlhT 41FqedjbNr1E8s0XsfwHh+9uKNv7NXDyB4burxXLee3vBE4QKZESj9RctrS9T2P3jF/vbDx1 zGYdv3C6LyNTiaU4I9FQi7moOBEA4P937woDAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/QTuJyA_hUGmQcvhuMtqGrh9RpLE
Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 16 Jul 2014 12:54:29 -0000

It's quite true that the OIDC draft predates -00 of the IETF draft, and=20
I'm sorry if that was unclear from what I said as I was not intending to =

misrepresent the history. And it's true that the UMA draft predates both =

of these by a fair whack and at the very least provided inspiration in=20
how to accomplish this task, and in fact draft -00 was a straight copy=20
of UMA. As Mike mentions below, draft -01 (when I took over the editor=20
role) incorporates a lot of text from the OIDF draft alongside the UMA=20
text, which is why that document has eight authors on it.

However it's not true that information didn't flow both ways, or that=20
everything from UMA was eventually expunged. It's fairly clear if you=20
look at the document history that there was a lot of back and forth. The =

JSON formatting in the IETF draft, for example, exists in -00 and came=20
from UMA, was switched to form encoding from in -01 (from OIDC), and=20
with lots of discussion here in the WG (both before and after the=20
change) was switched back to JSON in -05. At that time, there was a=20
discussion in the OIDF working group of whether to adopt the JSON=20
formatting as well in order to maintain compatibility, and OIDF decided=20
to do so. There were other instances where parameter names and other=20
ideas began in the IETF and moved to OIDF's spec, like changing=20
"issued_at" to the more clear "client_id_issued_at". These were breaking =

changes and not entered into lightly, and I was there for those=20
discussions and still contend that OIDF made the right call.

If the OIDF wants to frame that decision as "we decided independently to =

do a thing for the greater good" as opposed to "we adopted ideas from=20
outside", then it's free to do so for whatever legal protection reasons=20
it likes. It's perfectly fine with me that the OIDF represent itself and =

its documents how it sees best. But it's not OK with me to discount or=20
misrepresent the history and provenance of the ideas and components of=20
this IETF document in the IETF and I'd like to include the modified=20
statement I posted below in the introduction text of the next revision.

  -- Justin

On 7/16/2014 8:34 AM, Mike Jones wrote:
> I disagree with one aspect of Justin's characterization of the history =
of the spec and have data to back up my disagreement.  The OpenID Connect=
 Dynamic Registration Specification was not based on draft-ietf-oauth-dyn=
-reg-00 or the UMA specification.  It was created independently by John B=
radley in June 2011 based upon OpenID Connect working group discussions t=
hat predated draft-ietf-oauth-dyn-reg-00, and for which there are working=
 group notes documenting the OpenID Connect working group decisions prior=
 to the IETF -00 draft.  Yes, there's plenty of evidence that the IETF -0=
1 draft copied text from the early OpenID Connect draft (including in the=
 change history), but the Connect authors were careful to follow the Open=
ID Foundation's IPR process and not incorporate contributions from third =
parties who hadn't signed an OpenID IPR Contribution Agreement stating th=
at the OpenID Foundation was free to use their contributions.  (This fill=
s the same role as the IETF Note well, but with a signed agreement, and e=
nsures that all developers can use the resulting specifications without I=
PR concerns based on IPR that may be held by the contributors.)  The Open=
ID Connect Dynamic Registration draft didn't copy from the UMA draft or t=
he IETF draft derived from it, so as to maintain the IPR integrity of the=
 OpenID document.  The copying all went in the other direction.
>
> If portions of the UMA draft remained from -00 in the current drafts, I=
'd be fine with the UMA attribution, but in practice they don't.  The UMA=
 content was replaced with the OpenID Connect content.  (I believe that e=
ventually UMA decided to drop their old draft and move to registration me=
chanisms that were compatible with Connect as well, and stopped using the=
ir previous registration data formats.)
>
> 				-- Mike
>
> -----Original Message-----
> From: Justin Richer [mailto:jricher@MIT.EDU]
> Sent: Wednesday, July 16, 2014 4:53 AM
> To: Hannes Tschofenig; Mike Jones; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
>
> I like the idea of adding some of the text in the introduction, as I ag=
ree the compatibility is an important (and hard-won) accomplishment. I th=
ink taking Mike's text, expanding it, and putting it in the introduction =
might serve the overall purpose just fine:
>
> Portions of this specification are derived from the OpenID Connect Dyna=
mic Registration [OpenID.Registration] specification and from the User Ma=
naged Access [UMA] specification.  This was done so that implementations =
of these three specifications will be compatible with one another.
>
>
> These are both informative references, so we can reference the ID for U=
MA.
>
>    -- Justin
>
> On 7/16/2014 7:44 AM, Hannes Tschofenig wrote:
>> Interesting background information. Maybe we should then extend the
>> note Mike provided to also clarify the relationship with the UMA work
>> (both in terms to IPR, copyright, and attribution-wise).
>>
>> It would also make sense to state the relationship in the introduction=

>> to highlight the compatibility, which I believe is a big accomplishmen=
t.
>>
>> Ciao
>> Hannes
>>
>> On 07/16/2014 01:41 PM, Justin Richer wrote:
>>> I thought I had sent this note already, but I don't see it in the
>>> archives or in my 'sent' folder:
>>>
>>> If we're going to point to OpenID Connect (which I'm fine with), then=

>>> we should clarify that portions were also taken from the UMA specific=
ation.
>>> In fact, draft -00 actually *was* the UMA specification text entirely=
=2E
>>> This is also what the OpenID Connect registration specification was
>>> (loosely) based on when it was started.
>>>
>>> In reality, the relationship between these three documents from three=

>>> different SBO's is more complicated: they all grew up together and
>>> effectively merged to become wire-compatible with each other. There
>>> were a number of changes that were discussed here in the IETF that
>>> OpenID Connect adopted, and a number of changes that were discussed
>>> at OIDF that were adopted here. OIDC also extends the IETF draft with=

>>> a set of OIDC-specific metadata fields and editorial language that
>>> makes it fit more closely in the OIDC landscape, but make no mistake:=

>>> they're the same protocol. In the case of UMA, it's a straight
>>> normative reference to the IETF document now because we were able to
>>> incorporate those use cases and parameters directly.
>>>
>>> The trouble is, I'm not sure how to concisely state that all that in
>>> the draft text, but it's not as simple as "we copied OpenID", which
>>> is what the text below seems to say.
>>>
>>>    -- Justin
>>>
>>> On 7/16/2014 6:17 AM, Hannes Tschofenig wrote:
>>>> Thanks, Mike.
>>>>
>>>> This is a useful addition and reflects the relationship between the
>>>> two efforts.
>>>>
>>>> Please add it to the next draft version.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> On 07/15/2014 09:46 PM, Mike Jones wrote:
>>>>> So that the working group has concrete language to consider,
>>>>> propose the following language to the OAuth Dynamic Client Registra=
tion specification:
>>>>>
>>>>>   =20
>>>>>
>>>>> Portions of this specification are derived from the OpenID Connect
>>>>> Dynamic Registration [OpenID.Registration] specification.  This was=

>>>>> done so that implementations of this specification and OpenID
>>>>> Connect Dynamic Registration can be compatible with one another.
>>>>>
>>>>>   =20
>>>>>
>>>>>                                                               --
>>>>> Mike
>>>>>
>>>>>   =20
>>>>>
>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Mike
>>>>> Jones
>>>>> *Sent:* Tuesday, July 08, 2014 7:15 PM
>>>>> *To:* Phil Hunt; Hannes Tschofenig
>>>>> *Cc:* Maciej Machulak; oauth@ietf.org
>>>>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR
>>>>> Confirmation
>>>>>
>>>>>   =20
>>>>>
>>>>> Thinking about this some more, there is one IPR issue that we need
>>>>> to address before publication.  This specification is a derivative
>>>>> work from the OpenID Connect Dynamic Registration specification
>>>>> http://openid.net/specs/openid-connect-registration-1_0.html.
>>>>> Large portions of the text were copied wholesale from that spec to
>>>>> this one, so that the two would be compatible.  (This is good thing=

>>>>> =E2=80=93 not a bad
>>>>> thing.)
>>>>>
>>>>>   =20
>>>>>
>>>>> This is easy to address from an IPR perspective =E2=80=93 simply
>>>>> acknowledge that this spec is a derivative work and provide proper
>>>>> attribution.  The OpenID copyright in the spec at
>>>>> http://openid.net/specs/openid-connect-registration-1_0.html#Notice=

>>>>> s allows for this resolution.  It says:
>>>>>
>>>>>   =20
>>>>>
>>>>> Copyright (c) 2014 The OpenID Foundation.
>>>>>
>>>>> The OpenID Foundation (OIDF) grants to any Contributor, developer,
>>>>> implementer, or other interested party a non-exclusive, royalty
>>>>> free, worldwide copyright license to reproduce, prepare derivative
>>>>> works from, distribute, perform and display, this Implementers
>>>>> Draft or Final Specification solely for the purposes of (i)
>>>>> developing specifications, and (ii) implementing Implementers
>>>>> Drafts and Final Specifications based on such documents, provided
>>>>> that attribution be made to the OIDF as the source of the material,=

>>>>> but that such attribution does not indicate an endorsement by the O=
IDF.
>>>>>
>>>>> Let=E2=80=99s add the reference and acknowledgment in the next vers=
ion.
>>>>>
>>>>>   =20
>>>>>
>>>>>                                                               --
>>>>> Mike
>>>>>
>>>>>   =20
>>>>>
>>>>> *From:*Mike Jones
>>>>> *Sent:* Tuesday, July 08, 2014 10:06 AM
>>>>> *To:* Phil Hunt; Hannes Tschofenig
>>>>> *Cc:* John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org
>>>>> 
>>>>> *Subject:* RE: Dynamic Client Registration: IPR Confirmation
>>>>>
>>>>>   =20
>>>>>
>>>>> I likewise do not hold any IPR on these specs.
>>>>>
>>>>> -------------------------------------------------------------------=

>>>>> -----
>>>>>
>>>>> *From: *Phil Hunt 
>>>>> *Sent: *=E2=80=8E7/=E2=80=8E8/=E2=80=8E2014 9:11 AM
>>>>> *To: *Hannes Tschofenig 
>>>>> *Cc: *Mike Jones ; John Bradley=

>>>>> ; Justin Richer
>>>>> ; Maciej Machulak
>>>>> ; oauth@ietf.org
>>>>> 
>>>>> *Subject: *Re: Dynamic Client Registration: IPR Confirmation
>>>>>
>>>>> I confirm I have no IPR disclosures on this document.
>>>>>
>>>>> Phil
>>>>>
>>>>>> On Jul 8, 2014, at 4:54, Hannes Tschofenig > wrote:
>>>>>>
>>>>>> Hi Phil, John, Maciej, Justin, Mike,
>>>>>>
>>>>>> I am working on the shepherd writeup for the dynamic client
>>>>>> registration document and 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?
>>>>>>
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth



From nobody Wed Jul 16 06:54:29 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910FF1B27D7 for ; Wed, 16 Jul 2014 06:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgnPXRjqcssm for ; Wed, 16 Jul 2014 06:54:25 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A8B1B288A for ; Wed, 16 Jul 2014 06:54:24 -0700 (PDT)
Received: from BY2PR03CA029.namprd03.prod.outlook.com (10.242.234.150) by BLUPR03MB565.namprd03.prod.outlook.com (10.141.77.15) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 16 Jul 2014 13:54:23 +0000
Received: from BY2FFO11FD033.protection.gbl (2a01:111:f400:7c0c::141) by BY2PR03CA029.outlook.office365.com (2a01:111:e400:2c2c::22) with Microsoft SMTP Server (TLS) id 15.0.990.7 via Frontend Transport; Wed, 16 Jul 2014 13:54:22 +0000
Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD033.mail.protection.outlook.com (10.1.14.218) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 16 Jul 2014 13:54:22 +0000
Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.103]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0195.002; Wed, 16 Jul 2014 13:54:12 +0000
From: Mike Jones 
To: Justin Richer , Hannes Tschofenig , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
Thread-Index: AQHPmqNjTLUtygPATEaoV9K+QkTus5uWWTqAgAAPVUaAAJbWEIAKle1ggADzlQCAABeGAIAAAP0AgAACRICAAAIDwIAADxmAgAACZHA=
Date: Wed, 16 Jul 2014 13:54:12 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439ADCB58E@TK5EX14MBXC294.redmond.corp.microsoft.com>
References: <53BBDBEE.703@gmx.net>,  <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADAB98C@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C65120.4020302@gmx.net> <53C664DC.50907@mit.edu> <53C665B0.7040708@gmx.net> <53C66797.1040509@mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADCB3B3@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C675F1.9080102@mit.edu>
In-Reply-To: <53C675F1.9080102@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.37]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(164054003)(199002)(13464003)(55885003)(51704005)(24454002)(189002)(377454003)(479174003)(55846006)(95666004)(79102001)(86612001)(81342001)(87936001)(2171001)(85852003)(44976005)(77982001)(4396001)(2656002)(106466001)(80022001)(106116001)(81156004)(93886003)(47776003)(64706001)(20776003)(66066001)(21056001)(86362001)(99396002)(54356999)(76176999)(50986999)(15395725005)(92726001)(92566001)(6806004)(50466002)(83072002)(31966008)(26826002)(83322001)(15202345003)(19580405001)(104016003)(19580395003)(107886001)(107046002)(69596002)(68736004)(81542001)(97736001)(76482001)(46102001)(77096002)(74662001)(74502001)(85306003)(33656002)(15975445006)(23676002)(84676001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB565; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en; 
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0274272F87
Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; 
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/bkmweZMaNw8c1SmvA8WdNvJwGdY
Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 16 Jul 2014 13:54:28 -0000

T0sgLSBsb29raW5nIGJhY2sgYXQgdGhlIHBhcmFtZXRlciBuYW1lIGNoYW5nZSBleGFtcGxlLCBJ
IGFncmVlIHRoYXQgdGhpcyB3YXMgZmlyc3QgZGlzY3Vzc2VkIGluIHRoZSBPQXV0aCBXRyBhbmQg
d2FzIGFkb3B0ZWQgYnkgYm90aCBzcGVjcyBhdCBhYm91dCB0aGUgc2FtZSB0aW1lLCBzbyBJIGFn
cmVlIHRoYXQgdGhhdCdzIGFuIGV4YW1wbGUgb2YgaW5mb3JtYXRpb24gZmxvd2luZyBpbiB0aGUg
b3RoZXIgZGlyZWN0aW9uLiAgKEkgZG91YnQgdGhhdCBhbnlvbmUgd2lsbCBhc3NlcnQgSVBSIGFi
b3V0IGEgcGFyYW1ldGVyIG5hbWUgY2hhbmdlLCBzbyBJIHN1c3BlY3QgdGhhdCBpbnN0YW5jZSB3
YXMgaW5ub2N1b3VzLikgIFdoZW4gc29tZSBvZiB0aGUgc2FtZSBwZW9wbGUgd2VyZSBpbiB0d28g
d29ya2luZyBncm91cHMgZG9pbmcgaGlnaGx5IHJlbGF0ZWQgdGhpbmdzLCBJIHN1cHBvc2Ugc29t
ZSBvZiB0aGF0IHdhcyBib3VuZCB0byBoYXBwZW4sIGRlc3BpdGUgdGhlIGJlc3Qgb2YgaW50ZW50
aW9ucy4gIEhvd2V2ZXIsIGl0J3Mgc3RpbGwgbXkgYXNzZXJ0aW9uIHRoYXQgdGhlIGNvcmUgaW52
ZW50aW9ucyBpbiBDb25uZWN0IFJlZ2lzdHJhdGlvbiB3ZXJlIGluZGVwZW5kZW50bHkgZGV2ZWxv
cGVkLCBzeW50YXggdHdlYWtzIG1hZGUgbGF0ZXIgZm9yIGNvbXBhdGliaWxpdHkgcmVhc29ucyBh
c2lkZS4NCg0KQmUgdGhhdCBhcyBpdCBtYXksIGFuZCBoYXZpbmcgdGhvdWdodCBhYm91dCBpdCBz
b21lIG1vcmUsIEknbSBub3QgZ29pbmcgdG8gc3RhbmQgaW4gdGhlIHdheSBvZiBhY2tub3dsZWRn
aW5nIFVNQSBpbiB0aGUgT0F1dGggUmVnaXN0cmF0aW9uIHNwZWMgaWYgcGVvcGxlIGJlbGlldmUg
dGhhdCB0aGF0J3MgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvLiAgUGVvcGxlIHdobyBrbm93IG1lIGtu
b3cgdGhhdCBJJ20gYWxsIGluIGZhdm9yIG9mIGdpdmluZyBjcmVkaXQgd2hlcmUgY3JlZGl0IGlz
IGR1ZS4gIEknZCB0aG91Z2h0IHRoYXQgYWxsIHRoZSBVTUEgY29udGVudCBoYWQgYmVlbiByZXBs
YWNlZCwgYnV0IGlmIEknbSB3cm9uZyBhYm91dCB0aGF0LCBzbyBiZSBpdC4NCg0KV2hhdCB3b3Vs
ZCBiZSB0aGUgcmlnaHQgcmVmZXJlbmNlIGZvciB0aGUgVU1BIHJlZ2lzdHJhdGlvbiBzcGVjaWZp
Y2F0aW9uIGluIHRoZSBhY2tub3dsZWRnZW1lbnQ/DQoNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKdXN0aW4gUmljaGVyIFttYWlsdG86anJpY2hlckBN
SVQuRURVXSANClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxNiwgMjAxNCA1OjU0IEFNDQpUbzogTWlr
ZSBKb25lczsgSGFubmVzIFRzY2hvZmVuaWc7IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTog
W09BVVRILVdHXSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb246IElQUiBDb25maXJtYXRpb24N
Cg0KSXQncyBxdWl0ZSB0cnVlIHRoYXQgdGhlIE9JREMgZHJhZnQgcHJlZGF0ZXMgLTAwIG9mIHRo
ZSBJRVRGIGRyYWZ0LCBhbmQgSSdtIHNvcnJ5IGlmIHRoYXQgd2FzIHVuY2xlYXIgZnJvbSB3aGF0
IEkgc2FpZCBhcyBJIHdhcyBub3QgaW50ZW5kaW5nIHRvIG1pc3JlcHJlc2VudCB0aGUgaGlzdG9y
eS4gQW5kIGl0J3MgdHJ1ZSB0aGF0IHRoZSBVTUEgZHJhZnQgcHJlZGF0ZXMgYm90aCBvZiB0aGVz
ZSBieSBhIGZhaXIgd2hhY2sgYW5kIGF0IHRoZSB2ZXJ5IGxlYXN0IHByb3ZpZGVkIGluc3BpcmF0
aW9uIGluIGhvdyB0byBhY2NvbXBsaXNoIHRoaXMgdGFzaywgYW5kIGluIGZhY3QgZHJhZnQgLTAw
IHdhcyBhIHN0cmFpZ2h0IGNvcHkgb2YgVU1BLiBBcyBNaWtlIG1lbnRpb25zIGJlbG93LCBkcmFm
dCAtMDEgKHdoZW4gSSB0b29rIG92ZXIgdGhlIGVkaXRvcg0Kcm9sZSkgaW5jb3Jwb3JhdGVzIGEg
bG90IG9mIHRleHQgZnJvbSB0aGUgT0lERiBkcmFmdCBhbG9uZ3NpZGUgdGhlIFVNQSB0ZXh0LCB3
aGljaCBpcyB3aHkgdGhhdCBkb2N1bWVudCBoYXMgZWlnaHQgYXV0aG9ycyBvbiBpdC4NCg0KSG93
ZXZlciBpdCdzIG5vdCB0cnVlIHRoYXQgaW5mb3JtYXRpb24gZGlkbid0IGZsb3cgYm90aCB3YXlz
LCBvciB0aGF0IGV2ZXJ5dGhpbmcgZnJvbSBVTUEgd2FzIGV2ZW50dWFsbHkgZXhwdW5nZWQuIEl0
J3MgZmFpcmx5IGNsZWFyIGlmIHlvdSBsb29rIGF0IHRoZSBkb2N1bWVudCBoaXN0b3J5IHRoYXQg
dGhlcmUgd2FzIGEgbG90IG9mIGJhY2sgYW5kIGZvcnRoLiBUaGUgSlNPTiBmb3JtYXR0aW5nIGlu
IHRoZSBJRVRGIGRyYWZ0LCBmb3IgZXhhbXBsZSwgZXhpc3RzIGluIC0wMCBhbmQgY2FtZSBmcm9t
IFVNQSwgd2FzIHN3aXRjaGVkIHRvIGZvcm0gZW5jb2RpbmcgZnJvbSBpbiAtMDEgKGZyb20gT0lE
QyksIGFuZCB3aXRoIGxvdHMgb2YgZGlzY3Vzc2lvbiBoZXJlIGluIHRoZSBXRyAoYm90aCBiZWZv
cmUgYW5kIGFmdGVyIHRoZQ0KY2hhbmdlKSB3YXMgc3dpdGNoZWQgYmFjayB0byBKU09OIGluIC0w
NS4gQXQgdGhhdCB0aW1lLCB0aGVyZSB3YXMgYSBkaXNjdXNzaW9uIGluIHRoZSBPSURGIHdvcmtp
bmcgZ3JvdXAgb2Ygd2hldGhlciB0byBhZG9wdCB0aGUgSlNPTiBmb3JtYXR0aW5nIGFzIHdlbGwg
aW4gb3JkZXIgdG8gbWFpbnRhaW4gY29tcGF0aWJpbGl0eSwgYW5kIE9JREYgZGVjaWRlZCB0byBk
byBzby4gVGhlcmUgd2VyZSBvdGhlciBpbnN0YW5jZXMgd2hlcmUgcGFyYW1ldGVyIG5hbWVzIGFu
ZCBvdGhlciBpZGVhcyBiZWdhbiBpbiB0aGUgSUVURiBhbmQgbW92ZWQgdG8gT0lERidzIHNwZWMs
IGxpa2UgY2hhbmdpbmcgImlzc3VlZF9hdCIgdG8gdGhlIG1vcmUgY2xlYXIgImNsaWVudF9pZF9p
c3N1ZWRfYXQiLiBUaGVzZSB3ZXJlIGJyZWFraW5nIGNoYW5nZXMgYW5kIG5vdCBlbnRlcmVkIGlu
dG8gbGlnaHRseSwgYW5kIEkgd2FzIHRoZXJlIGZvciB0aG9zZSBkaXNjdXNzaW9ucyBhbmQgc3Rp
bGwgY29udGVuZCB0aGF0IE9JREYgbWFkZSB0aGUgcmlnaHQgY2FsbC4NCg0KSWYgdGhlIE9JREYg
d2FudHMgdG8gZnJhbWUgdGhhdCBkZWNpc2lvbiBhcyAid2UgZGVjaWRlZCBpbmRlcGVuZGVudGx5
IHRvIGRvIGEgdGhpbmcgZm9yIHRoZSBncmVhdGVyIGdvb2QiIGFzIG9wcG9zZWQgdG8gIndlIGFk
b3B0ZWQgaWRlYXMgZnJvbSBvdXRzaWRlIiwgdGhlbiBpdCdzIGZyZWUgdG8gZG8gc28gZm9yIHdo
YXRldmVyIGxlZ2FsIHByb3RlY3Rpb24gcmVhc29ucyBpdCBsaWtlcy4gSXQncyBwZXJmZWN0bHkg
ZmluZSB3aXRoIG1lIHRoYXQgdGhlIE9JREYgcmVwcmVzZW50IGl0c2VsZiBhbmQgaXRzIGRvY3Vt
ZW50cyBob3cgaXQgc2VlcyBiZXN0LiBCdXQgaXQncyBub3QgT0sgd2l0aCBtZSB0byBkaXNjb3Vu
dCBvciBtaXNyZXByZXNlbnQgdGhlIGhpc3RvcnkgYW5kIHByb3ZlbmFuY2Ugb2YgdGhlIGlkZWFz
IGFuZCBjb21wb25lbnRzIG9mIHRoaXMgSUVURiBkb2N1bWVudCBpbiB0aGUgSUVURiBhbmQgSSdk
IGxpa2UgdG8gaW5jbHVkZSB0aGUgbW9kaWZpZWQgc3RhdGVtZW50IEkgcG9zdGVkIGJlbG93IGlu
IHRoZSBpbnRyb2R1Y3Rpb24gdGV4dCBvZiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KICAtLSBKdXN0
aW4NCg0KT24gNy8xNi8yMDE0IDg6MzQgQU0sIE1pa2UgSm9uZXMgd3JvdGU6DQo+IEkgZGlzYWdy
ZWUgd2l0aCBvbmUgYXNwZWN0IG9mIEp1c3RpbidzIGNoYXJhY3Rlcml6YXRpb24gb2YgdGhlIGhp
c3Rvcnkgb2YgdGhlIHNwZWMgYW5kIGhhdmUgZGF0YSB0byBiYWNrIHVwIG15IGRpc2FncmVlbWVu
dC4gIFRoZSBPcGVuSUQgQ29ubmVjdCBEeW5hbWljIFJlZ2lzdHJhdGlvbiBTcGVjaWZpY2F0aW9u
IHdhcyBub3QgYmFzZWQgb24gZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVnLTAwIG9yIHRoZSBVTUEg
c3BlY2lmaWNhdGlvbi4gIEl0IHdhcyBjcmVhdGVkIGluZGVwZW5kZW50bHkgYnkgSm9obiBCcmFk
bGV5IGluIEp1bmUgMjAxMSBiYXNlZCB1cG9uIE9wZW5JRCBDb25uZWN0IHdvcmtpbmcgZ3JvdXAg
ZGlzY3Vzc2lvbnMgdGhhdCBwcmVkYXRlZCBkcmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctMDAsIGFu
ZCBmb3Igd2hpY2ggdGhlcmUgYXJlIHdvcmtpbmcgZ3JvdXAgbm90ZXMgZG9jdW1lbnRpbmcgdGhl
IE9wZW5JRCBDb25uZWN0IHdvcmtpbmcgZ3JvdXAgZGVjaXNpb25zIHByaW9yIHRvIHRoZSBJRVRG
IC0wMCBkcmFmdC4gIFllcywgdGhlcmUncyBwbGVudHkgb2YgZXZpZGVuY2UgdGhhdCB0aGUgSUVU
RiAtMDEgZHJhZnQgY29waWVkIHRleHQgZnJvbSB0aGUgZWFybHkgT3BlbklEIENvbm5lY3QgZHJh
ZnQgKGluY2x1ZGluZyBpbiB0aGUgY2hhbmdlIGhpc3RvcnkpLCBidXQgdGhlIENvbm5lY3QgYXV0
aG9ycyB3ZXJlIGNhcmVmdWwgdG8gZm9sbG93IHRoZSBPcGVuSUQgRm91bmRhdGlvbidzIElQUiBw
cm9jZXNzIGFuZCBub3QgaW5jb3Jwb3JhdGUgY29udHJpYnV0aW9ucyBmcm9tIHRoaXJkIHBhcnRp
ZXMgd2hvIGhhZG4ndCBzaWduZWQgYW4gT3BlbklEIElQUiBDb250cmlidXRpb24gQWdyZWVtZW50
IHN0YXRpbmcgdGhhdCB0aGUgT3BlbklEIEZvdW5kYXRpb24gd2FzIGZyZWUgdG8gdXNlIHRoZWly
IGNvbnRyaWJ1dGlvbnMuICAoVGhpcyBmaWxscyB0aGUgc2FtZSByb2xlIGFzIHRoZSBJRVRGIE5v
dGUgd2VsbCwgYnV0IHdpdGggYSBzaWduZWQgYWdyZWVtZW50LCBhbmQgZW5zdXJlcyB0aGF0IGFs
bCBkZXZlbG9wZXJzIGNhbiB1c2UgdGhlIHJlc3VsdGluZyBzcGVjaWZpY2F0aW9ucyB3aXRob3V0
IElQUiBjb25jZXJucyBiYXNlZCBvbiBJUFIgdGhhdCBtYXkgYmUgaGVsZCBieSB0aGUgY29udHJp
YnV0b3JzLikgIFRoZSBPcGVuSUQgQ29ubmVjdCBEeW5hbWljIFJlZ2lzdHJhdGlvbiBkcmFmdCBk
aWRuJ3QgY29weSBmcm9tIHRoZSBVTUEgZHJhZnQgb3IgdGhlIElFVEYgZHJhZnQgZGVyaXZlZCBm
cm9tIGl0LCBzbyBhcyB0byBtYWludGFpbiB0aGUgSVBSIGludGVncml0eSBvZiB0aGUgT3BlbklE
IGRvY3VtZW50LiAgVGhlIGNvcHlpbmcgYWxsIHdlbnQgaW4gdGhlIG90aGVyIGRpcmVjdGlvbi4N
Cj4NCj4gSWYgcG9ydGlvbnMgb2YgdGhlIFVNQSBkcmFmdCByZW1haW5lZCBmcm9tIC0wMCBpbiB0
aGUgY3VycmVudCBkcmFmdHMsIA0KPiBJJ2QgYmUgZmluZSB3aXRoIHRoZSBVTUEgYXR0cmlidXRp
b24sIGJ1dCBpbiBwcmFjdGljZSB0aGV5IGRvbid0LiAgVGhlIA0KPiBVTUEgY29udGVudCB3YXMg
cmVwbGFjZWQgd2l0aCB0aGUgT3BlbklEIENvbm5lY3QgY29udGVudC4gIChJIGJlbGlldmUgDQo+
IHRoYXQgZXZlbnR1YWxseSBVTUEgZGVjaWRlZCB0byBkcm9wIHRoZWlyIG9sZCBkcmFmdCBhbmQg
bW92ZSB0byANCj4gcmVnaXN0cmF0aW9uIG1lY2hhbmlzbXMgdGhhdCB3ZXJlIGNvbXBhdGlibGUg
d2l0aCBDb25uZWN0IGFzIHdlbGwsIGFuZCANCj4gc3RvcHBlZCB1c2luZyB0aGVpciBwcmV2aW91
cyByZWdpc3RyYXRpb24gZGF0YSBmb3JtYXRzLikNCj4NCj4gCQkJCS0tIE1pa2UNCj4NCj4gLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSnVzdGluIFJpY2hlciBbbWFpbHRvOmpy
aWNoZXJATUlULkVEVV0NCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDE2LCAyMDE0IDQ6NTMgQU0N
Cj4gVG86IEhhbm5lcyBUc2Nob2ZlbmlnOyBNaWtlIEpvbmVzOyBvYXV0aEBpZXRmLm9yZw0KPiBT
dWJqZWN0OiBSZTogW09BVVRILVdHXSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb246IElQUiBD
b25maXJtYXRpb24NCj4NCj4gSSBsaWtlIHRoZSBpZGVhIG9mIGFkZGluZyBzb21lIG9mIHRoZSB0
ZXh0IGluIHRoZSBpbnRyb2R1Y3Rpb24sIGFzIEkgYWdyZWUgdGhlIGNvbXBhdGliaWxpdHkgaXMg
YW4gaW1wb3J0YW50IChhbmQgaGFyZC13b24pIGFjY29tcGxpc2htZW50LiBJIHRoaW5rIHRha2lu
ZyBNaWtlJ3MgdGV4dCwgZXhwYW5kaW5nIGl0LCBhbmQgcHV0dGluZyBpdCBpbiB0aGUgaW50cm9k
dWN0aW9uIG1pZ2h0IHNlcnZlIHRoZSBvdmVyYWxsIHB1cnBvc2UganVzdCBmaW5lOg0KPg0KPiBQ
b3J0aW9ucyBvZiB0aGlzIHNwZWNpZmljYXRpb24gYXJlIGRlcml2ZWQgZnJvbSB0aGUgT3BlbklE
IENvbm5lY3QgRHluYW1pYyBSZWdpc3RyYXRpb24gW09wZW5JRC5SZWdpc3RyYXRpb25dIHNwZWNp
ZmljYXRpb24gYW5kIGZyb20gdGhlIFVzZXIgTWFuYWdlZCBBY2Nlc3MgW1VNQV0gc3BlY2lmaWNh
dGlvbi4gIFRoaXMgd2FzIGRvbmUgc28gdGhhdCBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlc2UgdGhy
ZWUgc3BlY2lmaWNhdGlvbnMgd2lsbCBiZSBjb21wYXRpYmxlIHdpdGggb25lIGFub3RoZXIuDQo+
DQo+DQo+IFRoZXNlIGFyZSBib3RoIGluZm9ybWF0aXZlIHJlZmVyZW5jZXMsIHNvIHdlIGNhbiBy
ZWZlcmVuY2UgdGhlIElEIGZvciBVTUEuDQo+DQo+ICAgIC0tIEp1c3Rpbg0KPg0KPiBPbiA3LzE2
LzIwMTQgNzo0NCBBTSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+PiBJbnRlcmVzdGluZyBi
YWNrZ3JvdW5kIGluZm9ybWF0aW9uLiBNYXliZSB3ZSBzaG91bGQgdGhlbiBleHRlbmQgdGhlIA0K
Pj4gbm90ZSBNaWtlIHByb3ZpZGVkIHRvIGFsc28gY2xhcmlmeSB0aGUgcmVsYXRpb25zaGlwIHdp
dGggdGhlIFVNQSB3b3JrIA0KPj4gKGJvdGggaW4gdGVybXMgdG8gSVBSLCBjb3B5cmlnaHQsIGFu
ZCBhdHRyaWJ1dGlvbi13aXNlKS4NCj4+DQo+PiBJdCB3b3VsZCBhbHNvIG1ha2Ugc2Vuc2UgdG8g
c3RhdGUgdGhlIHJlbGF0aW9uc2hpcCBpbiB0aGUgDQo+PiBpbnRyb2R1Y3Rpb24gdG8gaGlnaGxp
Z2h0IHRoZSBjb21wYXRpYmlsaXR5LCB3aGljaCBJIGJlbGlldmUgaXMgYSBiaWcgYWNjb21wbGlz
aG1lbnQuDQo+Pg0KPj4gQ2lhbw0KPj4gSGFubmVzDQo+Pg0KPj4gT24gMDcvMTYvMjAxNCAwMTo0
MSBQTSwgSnVzdGluIFJpY2hlciB3cm90ZToNCj4+PiBJIHRob3VnaHQgSSBoYWQgc2VudCB0aGlz
IG5vdGUgYWxyZWFkeSwgYnV0IEkgZG9uJ3Qgc2VlIGl0IGluIHRoZSANCj4+PiBhcmNoaXZlcyBv
ciBpbiBteSAnc2VudCcgZm9sZGVyOg0KPj4+DQo+Pj4gSWYgd2UncmUgZ29pbmcgdG8gcG9pbnQg
dG8gT3BlbklEIENvbm5lY3QgKHdoaWNoIEknbSBmaW5lIHdpdGgpLCANCj4+PiB0aGVuIHdlIHNo
b3VsZCBjbGFyaWZ5IHRoYXQgcG9ydGlvbnMgd2VyZSBhbHNvIHRha2VuIGZyb20gdGhlIFVNQSBz
cGVjaWZpY2F0aW9uLg0KPj4+IEluIGZhY3QsIGRyYWZ0IC0wMCBhY3R1YWxseSAqd2FzKiB0aGUg
VU1BIHNwZWNpZmljYXRpb24gdGV4dCBlbnRpcmVseS4NCj4+PiBUaGlzIGlzIGFsc28gd2hhdCB0
aGUgT3BlbklEIENvbm5lY3QgcmVnaXN0cmF0aW9uIHNwZWNpZmljYXRpb24gd2FzDQo+Pj4gKGxv
b3NlbHkpIGJhc2VkIG9uIHdoZW4gaXQgd2FzIHN0YXJ0ZWQuDQo+Pj4NCj4+PiBJbiByZWFsaXR5
LCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlc2UgdGhyZWUgZG9jdW1lbnRzIGZyb20gDQo+
Pj4gdGhyZWUgZGlmZmVyZW50IFNCTydzIGlzIG1vcmUgY29tcGxpY2F0ZWQ6IHRoZXkgYWxsIGdy
ZXcgdXAgdG9nZXRoZXIgDQo+Pj4gYW5kIGVmZmVjdGl2ZWx5IG1lcmdlZCB0byBiZWNvbWUgd2ly
ZS1jb21wYXRpYmxlIHdpdGggZWFjaCBvdGhlci4gDQo+Pj4gVGhlcmUgd2VyZSBhIG51bWJlciBv
ZiBjaGFuZ2VzIHRoYXQgd2VyZSBkaXNjdXNzZWQgaGVyZSBpbiB0aGUgSUVURiANCj4+PiB0aGF0
IE9wZW5JRCBDb25uZWN0IGFkb3B0ZWQsIGFuZCBhIG51bWJlciBvZiBjaGFuZ2VzIHRoYXQgd2Vy
ZSANCj4+PiBkaXNjdXNzZWQgYXQgT0lERiB0aGF0IHdlcmUgYWRvcHRlZCBoZXJlLiBPSURDIGFs
c28gZXh0ZW5kcyB0aGUgSUVURiANCj4+PiBkcmFmdCB3aXRoIGEgc2V0IG9mIE9JREMtc3BlY2lm
aWMgbWV0YWRhdGEgZmllbGRzIGFuZCBlZGl0b3JpYWwgDQo+Pj4gbGFuZ3VhZ2UgdGhhdCBtYWtl
cyBpdCBmaXQgbW9yZSBjbG9zZWx5IGluIHRoZSBPSURDIGxhbmRzY2FwZSwgYnV0IG1ha2Ugbm8g
bWlzdGFrZToNCj4+PiB0aGV5J3JlIHRoZSBzYW1lIHByb3RvY29sLiBJbiB0aGUgY2FzZSBvZiBV
TUEsIGl0J3MgYSBzdHJhaWdodCANCj4+PiBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIHRoZSBJRVRG
IGRvY3VtZW50IG5vdyBiZWNhdXNlIHdlIHdlcmUgYWJsZSB0byANCj4+PiBpbmNvcnBvcmF0ZSB0
aG9zZSB1c2UgY2FzZXMgYW5kIHBhcmFtZXRlcnMgZGlyZWN0bHkuDQo+Pj4NCj4+PiBUaGUgdHJv
dWJsZSBpcywgSSdtIG5vdCBzdXJlIGhvdyB0byBjb25jaXNlbHkgc3RhdGUgdGhhdCBhbGwgdGhh
dCBpbiANCj4+PiB0aGUgZHJhZnQgdGV4dCwgYnV0IGl0J3Mgbm90IGFzIHNpbXBsZSBhcyAid2Ug
Y29waWVkIE9wZW5JRCIsIHdoaWNoIA0KPj4+IGlzIHdoYXQgdGhlIHRleHQgYmVsb3cgc2VlbXMg
dG8gc2F5Lg0KPj4+DQo+Pj4gICAgLS0gSnVzdGluDQo+Pj4NCj4+PiBPbiA3LzE2LzIwMTQgNjox
NyBBTSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+Pj4+IFRoYW5rcywgTWlrZS4NCj4+Pj4N
Cj4+Pj4gVGhpcyBpcyBhIHVzZWZ1bCBhZGRpdGlvbiBhbmQgcmVmbGVjdHMgdGhlIHJlbGF0aW9u
c2hpcCBiZXR3ZWVuIHRoZSANCj4+Pj4gdHdvIGVmZm9ydHMuDQo+Pj4+DQo+Pj4+IFBsZWFzZSBh
ZGQgaXQgdG8gdGhlIG5leHQgZHJhZnQgdmVyc2lvbi4NCj4+Pj4NCj4+Pj4gQ2lhbw0KPj4+PiBI
YW5uZXMNCj4+Pj4NCj4+Pj4gT24gMDcvMTUvMjAxNCAwOTo0NiBQTSwgTWlrZSBKb25lcyB3cm90
ZToNCj4+Pj4+IFNvIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIGNvbmNyZXRlIGxhbmd1YWdl
IHRvIGNvbnNpZGVyLCANCj4+Pj4+IHByb3Bvc2UgdGhlIGZvbGxvd2luZyBsYW5ndWFnZSB0byB0
aGUgT0F1dGggRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIHNwZWNpZmljYXRpb246DQo+Pj4+
Pg0KPj4+Pj4gICAgDQo+Pj4+Pg0KPj4+Pj4gUG9ydGlvbnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9u
IGFyZSBkZXJpdmVkIGZyb20gdGhlIE9wZW5JRCBDb25uZWN0IA0KPj4+Pj4gRHluYW1pYyBSZWdp
c3RyYXRpb24gW09wZW5JRC5SZWdpc3RyYXRpb25dIHNwZWNpZmljYXRpb24uICBUaGlzIA0KPj4+
Pj4gd2FzIGRvbmUgc28gdGhhdCBpbXBsZW1lbnRhdGlvbnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9u
IGFuZCBPcGVuSUQgDQo+Pj4+PiBDb25uZWN0IER5bmFtaWMgUmVnaXN0cmF0aW9uIGNhbiBiZSBj
b21wYXRpYmxlIHdpdGggb25lIGFub3RoZXIuDQo+Pj4+Pg0KPj4+Pj4gICAgDQo+Pj4+Pg0KPj4+
Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAtLSANCj4+Pj4+IE1pa2UNCj4+Pj4+DQo+Pj4+PiAgICANCj4+Pj4+DQo+Pj4+PiAq
RnJvbToqT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9m
ICpNaWtlIA0KPj4+Pj4gSm9uZXMNCj4+Pj4+ICpTZW50OiogVHVlc2RheSwgSnVseSAwOCwgMjAx
NCA3OjE1IFBNDQo+Pj4+PiAqVG86KiBQaGlsIEh1bnQ7IEhhbm5lcyBUc2Nob2ZlbmlnDQo+Pj4+
PiAqQ2M6KiBNYWNpZWogTWFjaHVsYWs7IG9hdXRoQGlldGYub3JnDQo+Pj4+PiAqU3ViamVjdDoq
IFJlOiBbT0FVVEgtV0ddIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbjogSVBSIA0KPj4+Pj4g
Q29uZmlybWF0aW9uDQo+Pj4+Pg0KPj4+Pj4gICAgDQo+Pj4+Pg0KPj4+Pj4gVGhpbmtpbmcgYWJv
dXQgdGhpcyBzb21lIG1vcmUsIHRoZXJlIGlzIG9uZSBJUFIgaXNzdWUgdGhhdCB3ZSBuZWVkIA0K
Pj4+Pj4gdG8gYWRkcmVzcyBiZWZvcmUgcHVibGljYXRpb24uICBUaGlzIHNwZWNpZmljYXRpb24g
aXMgYSBkZXJpdmF0aXZlIA0KPj4+Pj4gd29yayBmcm9tIHRoZSBPcGVuSUQgQ29ubmVjdCBEeW5h
bWljIFJlZ2lzdHJhdGlvbiBzcGVjaWZpY2F0aW9uIA0KPj4+Pj4gaHR0cDovL29wZW5pZC5uZXQv
c3BlY3Mvb3BlbmlkLWNvbm5lY3QtcmVnaXN0cmF0aW9uLTFfMC5odG1sLg0KPj4+Pj4gTGFyZ2Ug
cG9ydGlvbnMgb2YgdGhlIHRleHQgd2VyZSBjb3BpZWQgd2hvbGVzYWxlIGZyb20gdGhhdCBzcGVj
IHRvIA0KPj4+Pj4gdGhpcyBvbmUsIHNvIHRoYXQgdGhlIHR3byB3b3VsZCBiZSBjb21wYXRpYmxl
LiAgKFRoaXMgaXMgZ29vZCANCj4+Pj4+IHRoaW5nIOKAkyBub3QgYSBiYWQNCj4+Pj4+IHRoaW5n
LikNCj4+Pj4+DQo+Pj4+PiAgICANCj4+Pj4+DQo+Pj4+PiBUaGlzIGlzIGVhc3kgdG8gYWRkcmVz
cyBmcm9tIGFuIElQUiBwZXJzcGVjdGl2ZSDigJMgc2ltcGx5IA0KPj4+Pj4gYWNrbm93bGVkZ2Ug
dGhhdCB0aGlzIHNwZWMgaXMgYSBkZXJpdmF0aXZlIHdvcmsgYW5kIHByb3ZpZGUgcHJvcGVyIA0K
Pj4+Pj4gYXR0cmlidXRpb24uICBUaGUgT3BlbklEIGNvcHlyaWdodCBpbiB0aGUgc3BlYyBhdCAN
Cj4+Pj4+IGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LXJlZ2lzdHJhdGlv
bi0xXzAuaHRtbCNOb3RpYw0KPj4+Pj4gZSBzIGFsbG93cyBmb3IgdGhpcyByZXNvbHV0aW9uLiAg
SXQgc2F5czoNCj4+Pj4+DQo+Pj4+PiAgICANCj4+Pj4+DQo+Pj4+PiBDb3B5cmlnaHQgKGMpIDIw
MTQgVGhlIE9wZW5JRCBGb3VuZGF0aW9uLg0KPj4+Pj4NCj4+Pj4+IFRoZSBPcGVuSUQgRm91bmRh
dGlvbiAoT0lERikgZ3JhbnRzIHRvIGFueSBDb250cmlidXRvciwgZGV2ZWxvcGVyLCANCj4+Pj4+
IGltcGxlbWVudGVyLCBvciBvdGhlciBpbnRlcmVzdGVkIHBhcnR5IGEgbm9uLWV4Y2x1c2l2ZSwg
cm95YWx0eSANCj4+Pj4+IGZyZWUsIHdvcmxkd2lkZSBjb3B5cmlnaHQgbGljZW5zZSB0byByZXBy
b2R1Y2UsIHByZXBhcmUgZGVyaXZhdGl2ZSANCj4+Pj4+IHdvcmtzIGZyb20sIGRpc3RyaWJ1dGUs
IHBlcmZvcm0gYW5kIGRpc3BsYXksIHRoaXMgSW1wbGVtZW50ZXJzIA0KPj4+Pj4gRHJhZnQgb3Ig
RmluYWwgU3BlY2lmaWNhdGlvbiBzb2xlbHkgZm9yIHRoZSBwdXJwb3NlcyBvZiAoaSkgDQo+Pj4+
PiBkZXZlbG9waW5nIHNwZWNpZmljYXRpb25zLCBhbmQgKGlpKSBpbXBsZW1lbnRpbmcgSW1wbGVt
ZW50ZXJzIA0KPj4+Pj4gRHJhZnRzIGFuZCBGaW5hbCBTcGVjaWZpY2F0aW9ucyBiYXNlZCBvbiBz
dWNoIGRvY3VtZW50cywgcHJvdmlkZWQgDQo+Pj4+PiB0aGF0IGF0dHJpYnV0aW9uIGJlIG1hZGUg
dG8gdGhlIE9JREYgYXMgdGhlIHNvdXJjZSBvZiB0aGUgDQo+Pj4+PiBtYXRlcmlhbCwgYnV0IHRo
YXQgc3VjaCBhdHRyaWJ1dGlvbiBkb2VzIG5vdCBpbmRpY2F0ZSBhbiBlbmRvcnNlbWVudCBieSB0
aGUgT0lERi4NCj4+Pj4+DQo+Pj4+PiBMZXTigJlzIGFkZCB0aGUgcmVmZXJlbmNlIGFuZCBhY2tu
b3dsZWRnbWVudCBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KPj4+Pj4NCj4+Pj4+ICAgIA0KPj4+Pj4N
Cj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgLS0gDQo+Pj4+PiBNaWtlDQo+Pj4+Pg0KPj4+Pj4gICAgDQo+Pj4+Pg0KPj4+
Pj4gKkZyb206Kk1pa2UgSm9uZXMNCj4+Pj4+ICpTZW50OiogVHVlc2RheSwgSnVseSAwOCwgMjAx
NCAxMDowNiBBTQ0KPj4+Pj4gKlRvOiogUGhpbCBIdW50OyBIYW5uZXMgVHNjaG9mZW5pZw0KPj4+
Pj4gKkNjOiogSm9obiBCcmFkbGV5OyBKdXN0aW4gUmljaGVyOyBNYWNpZWogTWFjaHVsYWs7IG9h
dXRoQGlldGYub3JnIA0KPj4+Pj4gPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCj4+Pj4+ICpTdWJq
ZWN0OiogUkU6IER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbjogSVBSIENvbmZpcm1hdGlvbg0K
Pj4+Pj4NCj4+Pj4+ICAgIA0KPj4+Pj4NCj4+Pj4+IEkgbGlrZXdpc2UgZG8gbm90IGhvbGQgYW55
IElQUiBvbiB0aGVzZSBzcGVjcy4NCj4+Pj4+DQo+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IC0NCj4+
Pj4+IC0tLS0tDQo+Pj4+Pg0KPj4+Pj4gKkZyb206ICpQaGlsIEh1bnQgPG1haWx0bzpwaGlsLmh1
bnRAb3JhY2xlLmNvbT4NCj4+Pj4+ICpTZW50OiAq4oCONy/igI44L+KAjjIwMTQgOToxMSBBTQ0K
Pj4+Pj4gKlRvOiAqSGFubmVzIFRzY2hvZmVuaWcgPG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0Bn
bXgubmV0Pg0KPj4+Pj4gKkNjOiAqTWlrZSBKb25lcyA8bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj
cm9zb2Z0LmNvbT47IEpvaG4gDQo+Pj4+PiBCcmFkbGV5IDxtYWlsdG86dmU3anRiQHZlN2p0Yi5j
b20+OyBKdXN0aW4gUmljaGVyIA0KPj4+Pj4gPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz47IE1h
Y2llaiBNYWNodWxhayANCj4+Pj4+IDxtYWlsdG86bS5wLm1hY2h1bGFrQG5jbC5hYy51az47IG9h
dXRoQGlldGYub3JnIA0KPj4+Pj4gPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCj4+Pj4+ICpTdWJq
ZWN0OiAqUmU6IER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbjogSVBSIENvbmZpcm1hdGlvbg0K
Pj4+Pj4NCj4+Pj4+IEkgY29uZmlybSBJIGhhdmUgbm8gSVBSIGRpc2Nsb3N1cmVzIG9uIHRoaXMg
ZG9jdW1lbnQuDQo+Pj4+Pg0KPj4+Pj4gUGhpbA0KPj4+Pj4NCj4+Pj4+PiBPbiBKdWwgOCwgMjAx
NCwgYXQgNDo1NCwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQg
PG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+
PiBIaSBQaGlsLCBKb2huLCBNYWNpZWosIEp1c3RpbiwgTWlrZSwNCj4+Pj4+Pg0KPj4+Pj4+IEkg
YW0gd29ya2luZyBvbiB0aGUgc2hlcGhlcmQgd3JpdGV1cCBmb3IgdGhlIGR5bmFtaWMgY2xpZW50
IA0KPj4+Pj4+IHJlZ2lzdHJhdGlvbiBkb2N1bWVudCBhbmQgb25lIGl0ZW0gaW4gdGhlIHRlbXBs
YXRlIHJlcXVpcmVzIG1lIHRvIA0KPj4+Pj4+IGluZGljYXRlIHdoZXRoZXIgZWFjaCBkb2N1bWVu
dCBhdXRob3IgaGFzIGNvbmZpcm1lZCB0aGF0IGFueSBhbmQgDQo+Pj4+Pj4gYWxsIGFwcHJvcHJp
YXRlIElQUiBkaXNjbG9zdXJlcyByZXF1aXJlZCBmb3IgZnVsbCBjb25mb3JtYW5jZSANCj4+Pj4+
PiB3aXRoIHRoZSBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5IGhhdmUgYWxyZWFkeSBi
ZWVuIGZpbGVkLg0KPj4+Pj4+DQo+Pj4+Pj4gQ291bGQgeW91IHBsZWFzZSBjb25maXJtPw0KPj4+
Pj4+DQo+Pj4+Pj4gQ2lhbw0KPj4+Pj4+IEhhbm5lcw0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gT0F1dGgg
bWFpbGluZyBsaXN0DQo+Pj4+IE9BdXRoQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQo=


From nobody Wed Jul 16 07:12:41 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BE21B287B for ; Wed, 16 Jul 2014 07:12:40 -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 uBYNNMO5eh-s for ; Wed, 16 Jul 2014 07:12:36 -0700 (PDT)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BEDE1B28AB for ; Wed, 16 Jul 2014 07:12:34 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id q58so1003949wes.35 for ; Wed, 16 Jul 2014 07:12:32 -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=M+tXDDCOQKu2irEteyV1XrQJS+sFMdm17Rz0HQyjgpU=; b=vaJrjzkCn5k4v5+uVaTC3PL0gSnmfhCu/osGW58Ar+cCzo29X6y2mlbyW+uJDLIKVz zxhBSirZQVa6TYh+NfhiHm6BbxtUd1yA7QCcLCjAZid6FG4KeawODa9YkCjhgqo7qKlQ CS8O66uTnoPqGtvgB6gQCJJBydB0+ii/Wz4jGaSA7UqW/vsPMM5LEPpS8r4LzRKQVpkv kMZdmRo5rsyiIoizW0vYIvcvvg8xfsiUJVJnNvLITLyQ98sTA+zYUSa0pfFWmea9J6iY AtdhQaQws/CD7haGdn5m77Rf9ZaOYipIizKJ4IPgQsBK6bACP6wdWqAB9uirbbRwJx0U DZgw==
MIME-Version: 1.0
X-Received: by 10.194.122.73 with SMTP id lq9mr3852413wjb.133.1405519952059; Wed, 16 Jul 2014 07:12:32 -0700 (PDT)
Received: by 10.194.18.198 with HTTP; Wed, 16 Jul 2014 07:12:31 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADCB58E@TK5EX14MBXC294.redmond.corp.microsoft.com>
References: <53BBDBEE.703@gmx.net>  <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADAB98C@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C65120.4020302@gmx.net> <53C664DC.50907@mit.edu> <53C665B0.7040708@gmx.net> <53C66797.1040509@mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADCB3B3@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C675F1.9080102@mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADCB58E@TK5EX14MBXC294.redmond.corp.microsoft.com>
Date: Wed, 16 Jul 2014 16:12:31 +0200
Message-ID: 
From: Maciej Machulak 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=089e012284f877a50704fe501dc4
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/O5fjtXdpp97oGeNxxJLDrOpsxMw
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 16 Jul 2014 14:12:40 -0000

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

Mike,

See comments below:

On 16 July 2014 15:54, Mike Jones  wrote:

> OK - looking back at the parameter name change example, I agree that this
> was first discussed in the OAuth WG and was adopted by both specs at abou=
t
> the same time, so I agree that that's an example of information flowing i=
n
> the other direction.  (I doubt that anyone will assert IPR about a
> parameter name change, so I suspect that instance was innocuous.)  When
> some of the same people were in two working groups doing highly related
> things, I suppose some of that was bound to happen, despite the best of
> intentions.  However, it's still my assertion that the core inventions in
> Connect Registration were independently developed, syntax tweaks made lat=
er
> for compatibility reasons aside.
>
> Be that as it may, and having thought about it some more, I'm not going t=
o
> stand in the way of acknowledging UMA in the OAuth Registration spec if
> people believe that that's the right thing to do.  People who know me kno=
w
> that I'm all in favor of giving credit where credit is due.  I'd thought
> that all the UMA content had been replaced, but if I'm wrong about that, =
so
> be it.
>

That is fine - if the content has been removed then just don't give the
credit - I'm fine both ways.


>
> What would be the right reference for the UMA registration specification
> in the acknowledgement?
>

This is the latest doc that was ever produced, as far as I am aware of:
http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-03

Kind regards,
Maciej


>
>                                 -- Mike
>
> -----Original Message-----
> From: Justin Richer [mailto:jricher@MIT.EDU]
> Sent: Wednesday, July 16, 2014 5:54 AM
> To: Mike Jones; Hannes Tschofenig; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
>
> It's quite true that the OIDC draft predates -00 of the IETF draft, and
> I'm sorry if that was unclear from what I said as I was not intending to
> misrepresent the history. And it's true that the UMA draft predates both =
of
> these by a fair whack and at the very least provided inspiration in how t=
o
> accomplish this task, and in fact draft -00 was a straight copy of UMA. A=
s
> Mike mentions below, draft -01 (when I took over the editor
> role) incorporates a lot of text from the OIDF draft alongside the UMA
> text, which is why that document has eight authors on it.
>
> However it's not true that information didn't flow both ways, or that
> everything from UMA was eventually expunged. It's fairly clear if you loo=
k
> at the document history that there was a lot of back and forth. The JSON
> formatting in the IETF draft, for example, exists in -00 and came from UM=
A,
> was switched to form encoding from in -01 (from OIDC), and with lots of
> discussion here in the WG (both before and after the
> change) was switched back to JSON in -05. At that time, there was a
> discussion in the OIDF working group of whether to adopt the JSON
> formatting as well in order to maintain compatibility, and OIDF decided t=
o
> do so. There were other instances where parameter names and other ideas
> began in the IETF and moved to OIDF's spec, like changing "issued_at" to
> the more clear "client_id_issued_at". These were breaking changes and not
> entered into lightly, and I was there for those discussions and still
> contend that OIDF made the right call.
>
> If the OIDF wants to frame that decision as "we decided independently to
> do a thing for the greater good" as opposed to "we adopted ideas from
> outside", then it's free to do so for whatever legal protection reasons i=
t
> likes. It's perfectly fine with me that the OIDF represent itself and its
> documents how it sees best. But it's not OK with me to discount or
> misrepresent the history and provenance of the ideas and components of th=
is
> IETF document in the IETF and I'd like to include the modified statement =
I
> posted below in the introduction text of the next revision.
>
>   -- Justin
>
> On 7/16/2014 8:34 AM, Mike Jones wrote:
> > I disagree with one aspect of Justin's characterization of the history
> of the spec and have data to back up my disagreement.  The OpenID Connect
> Dynamic Registration Specification was not based on
> draft-ietf-oauth-dyn-reg-00 or the UMA specification.  It was created
> independently by John Bradley in June 2011 based upon OpenID Connect
> working group discussions that predated draft-ietf-oauth-dyn-reg-00, and
> for which there are working group notes documenting the OpenID Connect
> working group decisions prior to the IETF -00 draft.  Yes, there's plenty
> of evidence that the IETF -01 draft copied text from the early OpenID
> Connect draft (including in the change history), but the Connect authors
> were careful to follow the OpenID Foundation's IPR process and not
> incorporate contributions from third parties who hadn't signed an OpenID
> IPR Contribution Agreement stating that the OpenID Foundation was free to
> use their contributions.  (This fills the same role as the IETF Note well=
,
> but with a signed agreement, and ensures that all developers can use the
> resulting specifications without IPR concerns based on IPR that may be he=
ld
> by the contributors.)  The OpenID Connect Dynamic Registration draft didn=
't
> copy from the UMA draft or the IETF draft derived from it, so as to
> maintain the IPR integrity of the OpenID document.  The copying all went =
in
> the other direction.
> >
> > If portions of the UMA draft remained from -00 in the current drafts,
> > I'd be fine with the UMA attribution, but in practice they don't.  The
> > UMA content was replaced with the OpenID Connect content.  (I believe
> > that eventually UMA decided to drop their old draft and move to
> > registration mechanisms that were compatible with Connect as well, and
> > stopped using their previous registration data formats.)
> >
> >                               -- Mike
> >
> > -----Original Message-----
> > From: Justin Richer [mailto:jricher@MIT.EDU]
> > Sent: Wednesday, July 16, 2014 4:53 AM
> > To: Hannes Tschofenig; Mike Jones; oauth@ietf.org
> > Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
> >
> > I like the idea of adding some of the text in the introduction, as I
> agree the compatibility is an important (and hard-won) accomplishment. I
> think taking Mike's text, expanding it, and putting it in the introductio=
n
> might serve the overall purpose just fine:
> >
> > Portions of this specification are derived from the OpenID Connect
> Dynamic Registration [OpenID.Registration] specification and from the Use=
r
> Managed Access [UMA] specification.  This was done so that implementation=
s
> of these three specifications will be compatible with one another.
> >
> >
> > These are both informative references, so we can reference the ID for
> UMA.
> >
> >    -- Justin
> >
> > On 7/16/2014 7:44 AM, Hannes Tschofenig wrote:
> >> Interesting background information. Maybe we should then extend the
> >> note Mike provided to also clarify the relationship with the UMA work
> >> (both in terms to IPR, copyright, and attribution-wise).
> >>
> >> It would also make sense to state the relationship in the
> >> introduction to highlight the compatibility, which I believe is a big
> accomplishment.
> >>
> >> Ciao
> >> Hannes
> >>
> >> On 07/16/2014 01:41 PM, Justin Richer wrote:
> >>> I thought I had sent this note already, but I don't see it in the
> >>> archives or in my 'sent' folder:
> >>>
> >>> If we're going to point to OpenID Connect (which I'm fine with),
> >>> then we should clarify that portions were also taken from the UMA
> specification.
> >>> In fact, draft -00 actually *was* the UMA specification text entirely=
.
> >>> This is also what the OpenID Connect registration specification was
> >>> (loosely) based on when it was started.
> >>>
> >>> In reality, the relationship between these three documents from
> >>> three different SBO's is more complicated: they all grew up together
> >>> and effectively merged to become wire-compatible with each other.
> >>> There were a number of changes that were discussed here in the IETF
> >>> that OpenID Connect adopted, and a number of changes that were
> >>> discussed at OIDF that were adopted here. OIDC also extends the IETF
> >>> draft with a set of OIDC-specific metadata fields and editorial
> >>> language that makes it fit more closely in the OIDC landscape, but
> make no mistake:
> >>> they're the same protocol. In the case of UMA, it's a straight
> >>> normative reference to the IETF document now because we were able to
> >>> incorporate those use cases and parameters directly.
> >>>
> >>> The trouble is, I'm not sure how to concisely state that all that in
> >>> the draft text, but it's not as simple as "we copied OpenID", which
> >>> is what the text below seems to say.
> >>>
> >>>    -- Justin
> >>>
> >>> On 7/16/2014 6:17 AM, Hannes Tschofenig wrote:
> >>>> Thanks, Mike.
> >>>>
> >>>> This is a useful addition and reflects the relationship between the
> >>>> two efforts.
> >>>>
> >>>> Please add it to the next draft version.
> >>>>
> >>>> Ciao
> >>>> Hannes
> >>>>
> >>>> On 07/15/2014 09:46 PM, Mike Jones wrote:
> >>>>> So that the working group has concrete language to consider,
> >>>>> propose the following language to the OAuth Dynamic Client
> Registration specification:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Portions of this specification are derived from the OpenID Connect
> >>>>> Dynamic Registration [OpenID.Registration] specification.  This
> >>>>> was done so that implementations of this specification and OpenID
> >>>>> Connect Dynamic Registration can be compatible with one another.
> >>>>>
> >>>>>
> >>>>>
> >>>>>                                                               --
> >>>>> Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Mike
> >>>>> Jones
> >>>>> *Sent:* Tuesday, July 08, 2014 7:15 PM
> >>>>> *To:* Phil Hunt; Hannes Tschofenig
> >>>>> *Cc:* Maciej Machulak; oauth@ietf.org
> >>>>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR
> >>>>> Confirmation
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thinking about this some more, there is one IPR issue that we need
> >>>>> to address before publication.  This specification is a derivative
> >>>>> work from the OpenID Connect Dynamic Registration specification
> >>>>> http://openid.net/specs/openid-connect-registration-1_0.html.
> >>>>> Large portions of the text were copied wholesale from that spec to
> >>>>> this one, so that the two would be compatible.  (This is good
> >>>>> thing =E2=80=93 not a bad
> >>>>> thing.)
> >>>>>
> >>>>>
> >>>>>
> >>>>> This is easy to address from an IPR perspective =E2=80=93 simply
> >>>>> acknowledge that this spec is a derivative work and provide proper
> >>>>> attribution.  The OpenID copyright in the spec at
> >>>>> http://openid.net/specs/openid-connect-registration-1_0.html#Notic
> >>>>> e s allows for this resolution.  It says:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Copyright (c) 2014 The OpenID Foundation.
> >>>>>
> >>>>> The OpenID Foundation (OIDF) grants to any Contributor, developer,
> >>>>> implementer, or other interested party a non-exclusive, royalty
> >>>>> free, worldwide copyright license to reproduce, prepare derivative
> >>>>> works from, distribute, perform and display, this Implementers
> >>>>> Draft or Final Specification solely for the purposes of (i)
> >>>>> developing specifications, and (ii) implementing Implementers
> >>>>> Drafts and Final Specifications based on such documents, provided
> >>>>> that attribution be made to the OIDF as the source of the
> >>>>> material, but that such attribution does not indicate an endorsemen=
t
> by the OIDF.
> >>>>>
> >>>>> Let=E2=80=99s add the reference and acknowledgment in the next vers=
ion.
> >>>>>
> >>>>>
> >>>>>
> >>>>>                                                               --
> >>>>> Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>> *From:*Mike Jones
> >>>>> *Sent:* Tuesday, July 08, 2014 10:06 AM
> >>>>> *To:* Phil Hunt; Hannes Tschofenig
> >>>>> *Cc:* John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org
> >>>>> 
> >>>>> *Subject:* RE: Dynamic Client Registration: IPR Confirmation
> >>>>>
> >>>>>
> >>>>>
> >>>>> I likewise do not hold any IPR on these specs.
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> -
> >>>>> -----
> >>>>>
> >>>>> *From: *Phil Hunt 
> >>>>> *Sent: *=E2=80=8E7/=E2=80=8E8/=E2=80=8E2014 9:11 AM
> >>>>> *To: *Hannes Tschofenig 
> >>>>> *Cc: *Mike Jones ; John
> >>>>> Bradley ; Justin Richer
> >>>>> ; Maciej Machulak
> >>>>> ; oauth@ietf.org
> >>>>> 
> >>>>> *Subject: *Re: Dynamic Client Registration: IPR Confirmation
> >>>>>
> >>>>> I confirm I have no IPR disclosures on this document.
> >>>>>
> >>>>> Phil
> >>>>>
> >>>>>> On Jul 8, 2014, at 4:54, Hannes Tschofenig <
> hannes.tschofenig@gmx.net > wrote:
> >>>>>>
> >>>>>> Hi Phil, John, Maciej, Justin, Mike,
> >>>>>>
> >>>>>> I am working on the shepherd writeup for the dynamic client
> >>>>>> registration document and 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?
> >>>>>>
> >>>>>> Ciao
> >>>>>> Hannes
> >>>>>>
> >>>>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



--=20
Maciej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)

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


Mike,

See comments below:

On 16 July 2014 15:54, Mi=
ke Jones <Michael.Jones@microsoft.com> wrote:


OK - looking back at the parameter name change example, I =
agree that this was first discussed in the OAuth WG and was adopted by both=
 specs at about the same time, so I agree that that's an example of inf=
ormation flowing in the other direction. =C2=A0(I doubt that anyone will as=
sert IPR about a parameter name change, so I suspect that instance was inno=
cuous.) =C2=A0When some of the same people were in two working groups doing=
 highly related things, I suppose some of that was bound to happen, despite=
 the best of intentions. =C2=A0However, it's still my assertion that th=
e core inventions in Connect Registration were independently developed, syn=
tax tweaks made later for compatibility reasons aside.




Be that as it may, and having thought about it some more, I'm not going=
 to stand in the way of acknowledging UMA in the OAuth Registration spec if=
 people believe that that's the right thing to do. =C2=A0People who kno=
w me know that I'm all in favor of giving credit where credit is due. =
=C2=A0I'd thought that all the UMA content had been replaced, but if I&=
#39;m wrong about that, so be it.



That is fine - if the content has been rem=
oved then just don't give the credit - I'm fine both ways.
=C2=A0




What would be the right reference for the UMA registration specification in=
 the acknowledgement?

This is the lates=
t doc that was ever produced, as far as I am aware of:



Kind regards,
Maciej
=C2=A0





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



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

From: Justin Richer [mailto:jricher@MIT.=
EDU]


Sent: Wednesday, July 16, 2014 5:54=
 AM

To: Mike Jones; Hannes Tschofenig; oauth@=
ietf.org

Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation



It's quite true that the OIDC draft predates -00 of the IETF draft, and=
 I'm sorry if that was unclear from what I said as I was not intending =
to misrepresent the history. And it's true that the UMA draft predates =
both of these by a fair whack and at the very least provided inspiration in=
 how to accomplish this task, and in fact draft -00 was a straight copy of =
UMA. As Mike mentions below, draft -01 (when I took over the editor


role) incorporates a lot of text from the OIDF draft alongside the UMA text=
, which is why that document has eight authors on it.



However it's not true that information didn't flow both ways, or th=
at everything from UMA was eventually expunged. It's fairly clear if yo=
u look at the document history that there was a lot of back and forth. The =
JSON formatting in the IETF draft, for example, exists in -00 and came from=
 UMA, was switched to form encoding from in -01 (from OIDC), and with lots =
of discussion here in the WG (both before and after the


change) was switched back to JSON in -05. At that time, there was a discuss=
ion in the OIDF working group of whether to adopt the JSON formatting as we=
ll in order to maintain compatibility, and OIDF decided to do so. There wer=
e other instances where parameter names and other ideas began in the IETF a=
nd moved to OIDF's spec, like changing "issued_at" to the mor=
e clear "client_id_issued_at". These were breaking changes and no=
t entered into lightly, and I was there for those discussions and still con=
tend that OIDF made the right call.




If the OIDF wants to frame that decision as "we decided independently =
to do a thing for the greater good" as opposed to "we adopted ide=
as from outside", then it's free to do so for whatever legal prote=
ction reasons it likes. It's perfectly fine with me that the OIDF repre=
sent itself and its documents how it sees best. But it's not OK with me=
 to discount or misrepresent the history and provenance of the ideas and co=
mponents of this IETF document in the IETF and I'd like to include the =
modified statement I posted below in the introduction text of the next revi=
sion.




=C2=A0 -- Justin



On 7/16/2014 8:34 AM, Mike Jones wrote:

> I disagree with one aspect of Justin's characterization of the his=
tory of the spec and have data to back up my disagreement. =C2=A0The OpenID=
 Connect Dynamic Registration Specification was not based on draft-ietf-oau=
th-dyn-reg-00 or the UMA specification. =C2=A0It was created independently =
by John Bradley in June 2011 based upon OpenID Connect working group discus=
sions that predated draft-ietf-oauth-dyn-reg-00, and for which there are wo=
rking group notes documenting the OpenID Connect working group decisions pr=
ior to the IETF -00 draft. =C2=A0Yes, there's plenty of evidence that t=
he IETF -01 draft copied text from the early OpenID Connect draft (includin=
g in the change history), but the Connect authors were careful to follow th=
e OpenID Foundation's IPR process and not incorporate contributions fro=
m third parties who hadn't signed an OpenID IPR Contribution Agreement =
stating that the OpenID Foundation was free to use their contributions. =C2=
=A0(This fills the same role as the IETF Note well, but with a signed agree=
ment, and ensures that all developers can use the resulting specifications =
without IPR concerns based on IPR that may be held by the contributors.) =
=C2=A0The OpenID Connect Dynamic Registration draft didn't copy from th=
e UMA draft or the IETF draft derived from it, so as to maintain the IPR in=
tegrity of the OpenID document. =C2=A0The copying all went in the other dir=
ection.


>

> If portions of the UMA draft remained from -00 in the current drafts,<=
br>
> I'd be fine with the UMA attribution, but in practice they don'=
;t. =C2=A0The

> UMA content was replaced with the OpenID Connect content. =C2=A0(I bel=
ieve

> that eventually UMA decided to drop their old draft and move to

> registration mechanisms that were compatible with Connect as well, and=


> stopped using their previous registration data formats.)

>

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

>

> -----Original Message-----

> From: Justin Richer [mailto:jricher=
@MIT.EDU]

> Sent: Wednesday, July 16, 2014 4:53 AM

> To: Hannes Tschofenig; Mike Jones; o=
auth@ietf.org

> Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation<=
br>
>

> I like the idea of adding some of the text in the introduction, as I a=
gree the compatibility is an important (and hard-won) accomplishment. I thi=
nk taking Mike's text, expanding it, and putting it in the introduction=
 might serve the overall purpose just fine:


>

> Portions of this specification are derived from the OpenID Connect Dyn=
amic Registration [OpenID.Registration] specification and from the User Man=
aged Access [UMA] specification. =C2=A0This was done so that implementation=
s of these three specifications will be compatible with one another.


>

>

> These are both informative references, so we can reference the ID for =
UMA.

>

> =C2=A0 =C2=A0-- Justin

>

> On 7/16/2014 7:44 AM, Hannes Tschofenig wrote:

>> Interesting background information. Maybe we should then extend th=
e

>> note Mike provided to also clarify the relationship with the UMA w=
ork

>> (both in terms to IPR, copyright, and attribution-wise).

>>

>> It would also make sense to state the relationship in the

>> introduction to highlight the compatibility, which I believe is a =
big accomplishment.

>>

>> Ciao

>> Hannes

>>

>> On 07/16/2014 01:41 PM, Justin Richer wrote:

>>> I thought I had sent this note already, but I don't see it=
 in the

>>> archives or in my 'sent' folder:

>>>

>>> If we're going to point to OpenID Connect (which I'm f=
ine with),

>>> then we should clarify that portions were also taken from the =
UMA specification.

>>> In fact, draft -00 actually *was* the UMA specification text e=
ntirely.

>>> This is also what the OpenID Connect registration specificatio=
n was

>>> (loosely) based on when it was started.

>>>

>>> In reality, the relationship between these three documents fro=
m

>>> three different SBO's is more complicated: they all grew u=
p together

>>> and effectively merged to become wire-compatible with each oth=
er.

>>> There were a number of changes that were discussed here in the=
 IETF

>>> that OpenID Connect adopted, and a number of changes that were=


>>> discussed at OIDF that were adopted here. OIDC also extends th=
e IETF

>>> draft with a set of OIDC-specific metadata fields and editoria=
l

>>> language that makes it fit more closely in the OIDC landscape,=
 but make no mistake:

>>> they're the same protocol. In the case of UMA, it's a =
straight

>>> normative reference to the IETF document now because we were a=
ble to

>>> incorporate those use cases and parameters directly.

>>>

>>> The trouble is, I'm not sure how to concisely state that a=
ll that in

>>> the draft text, but it's not as simple as "we copied =
OpenID", which

>>> is what the text below seems to say.

>>>

>>> =C2=A0 =C2=A0-- Justin

>>>

>>> On 7/16/2014 6:17 AM, Hannes Tschofenig wrote:

>>>> Thanks, Mike.

>>>>

>>>> This is a useful addition and reflects the relationship be=
tween the

>>>> two efforts.

>>>>

>>>> Please add it to the next draft version.

>>>>

>>>> Ciao

>>>> Hannes

>>>>

>>>> On 07/15/2014 09:46 PM, Mike Jones wrote:

>>>>> So that the working group has concrete language to con=
sider,

>>>>> propose the following language to the OAuth Dynamic Cl=
ient Registration specification:

>>>>>

>>>>>

>>>>>

>>>>> Portions of this specification are derived from the Op=
enID Connect

>>>>> Dynamic Registration [OpenID.Registration] specificati=
on. =C2=A0This

>>>>> was done so that implementations of this specification=
 and OpenID

>>>>> Connect Dynamic Registration can be compatible with on=
e another.

>>>>>

>>>>>

>>>>>

>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 --

>>>>> Mike

>>>>>

>>>>>

>>>>>

>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Mike

>>>>> Jones

>>>>> *Sent:* Tuesday, July 08, 2014 7:15 PM

>>>>> *To:* Phil Hunt; Hannes Tschofenig

>>>>> *Cc:* Maciej Machulak; oauth@ietf.org

>>>>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration:=
 IPR

>>>>> Confirmation

>>>>>

>>>>>

>>>>>

>>>>> Thinking about this some more, there is one IPR issue =
that we need

>>>>> to address before publication. =C2=A0This specificatio=
n is a derivative

>>>>> work from the OpenID Connect Dynamic Registration spec=
ification

>>>>> http://openid.net/specs/openid-connect=
-registration-1_0.html.

>>>>> Large portions of the text were copied wholesale from =
that spec to

>>>>> this one, so that the two would be compatible. =C2=A0(=
This is good

>>>>> thing =E2=80=93 not a bad

>>>>> thing.)

>>>>>

>>>>>

>>>>>

>>>>> This is easy to address from an IPR perspective =E2=80=
=93 simply

>>>>> acknowledge that this spec is a derivative work and pr=
ovide proper

>>>>> attribution. =C2=A0The OpenID copyright in the spec at=


>>>>> http://openid.net/specs/openid-c=
onnect-registration-1_0.html#Notic


>>>>> e s allo=
ws for this resolution. =C2=A0It says:

>>>>>

>>>>>

>>>>>

>>>>> Copyright (c) 2014 The OpenID Foundation.

>>>>>

>>>>> The OpenID Foundation (OIDF) grants to any Contributor=
, developer,

>>>>> implementer, or other interested party a non-exclusive=
, royalty

>>>>> free, worldwide copyright license to reproduce, prepar=
e derivative

>>>>> works from, distribute, perform and display, this Impl=
ementers

>>>>> Draft or Final Specification solely for the purposes o=
f (i)

>>>>> developing specifications, and (ii) implementing Imple=
menters

>>>>> Drafts and Final Specifications based on such document=
s, provided

>>>>> that attribution be made to the OIDF as the source of =
the

>>>>> material, but that such attribution does not indicate =
an endorsement by the OIDF.

>>>>>

>>>>> Let=E2=80=99s add the reference and acknowledgment in =
the next version.

>>>>>

>>>>>

>>>>>

>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 --

>>>>> Mike

>>>>>

>>>>>

>>>>>

>>>>> *From:*Mike Jones

>>>>> *Sent:* Tuesday, July 08, 2014 10:06 AM

>>>>> *To:* Phil Hunt; Hannes Tschofenig

>>>>> *Cc:* John Bradley; Justin Richer; Maciej Machulak; oauth@ietf.org

>>>>> <mailto:oauth@iet=
f.org>

>>>>> *Subject:* RE: Dynamic Client Registration: IPR Confir=
mation

>>>>>

>>>>>

>>>>>

>>>>> I likewise do not hold any IPR on these specs.

>>>>>

>>>>> ------------------------------------------------------=
------------

>>>>> -

>>>>> -----

>>>>>

>>>>> *From: *Phil Hunt <mailto:phil.hunt@oracle.com>

>>>>> *Sent: *=E2=80=8E7/=E2=80=8E8/=E2=80=8E2014 9:11 AM
>>>>> *To: *Hannes Tschofenig <mailto:hannes.tschofenig@gmx.net>

>>>>> *Cc: *Mike Jones <mailto:Michael.Jones@microsoft.com>; John

>>>>> Bradley <mailto:ve7jtb@ve7jtb.com>; Justin Richer

>>>>> <mailto:jriche=
r@mitre.org>; Maciej Machulak

>>>>> <mailto:m=
.p.machulak@ncl.ac.uk>; oauth@ietf=
.org

>>>>> <mailto:oauth@iet=
f.org>

>>>>> *Subject: *Re: Dynamic Client Registration: IPR Confir=
mation

>>>>>

>>>>> I confirm I have no IPR disclosures on this document.<=
br>
>>>>>

>>>>> Phil

>>>>>

>>>>>> On Jul 8, 2014, at 4:54, Hannes Tschofenig <hannes.tschofenig@gmx.net <=
;mailto:hannes.tschofenig@gmx.=
net>> wrote:


>>>>>>

>>>>>> Hi Phil, John, Maciej, Justin, Mike,

>>>>>>

>>>>>> I am working on the shepherd writeup for the dynam=
ic client

>>>>>> registration document and one item in the template=
 requires me to

>>>>>> indicate whether each document author has confirme=
d that any and

>>>>>> all appropriate IPR disclosures required for full =
conformance

>>>>>> with the provisions of BCP 78 and BCP 79 have alre=
ady been filed.

>>>>>>

>>>>>> Could you please confirm?

>>>>>>

>>>>>> Ciao

>>>>>> Hannes

>>>>>>

>>>>>>

>>>> _______________________________________________

>>>> OAuth mailing list

>>>> OAuth@ietf.org

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





_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





-- 
=
Maciej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 767 (UK=
)

mobile: +48 602 45 31 66 (PL)



--089e012284f877a50704fe501dc4--


From nobody Wed Jul 16 08:45:29 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF1C1B28CD for ; Wed, 16 Jul 2014 08:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.85
X-Spam-Level: 
X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 iD0bnpoyI_8Z for ; Wed, 16 Jul 2014 08:45:16 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F20451A0654 for ; Wed, 16 Jul 2014 08:45:15 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7A0511F1071; Wed, 16 Jul 2014 11:45:15 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 67D141F108A; Wed, 16 Jul 2014 11:45:15 -0400 (EDT)
Received: from [10.146.15.61] (10.140.19.249) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 16 Jul 2014 11:45:15 -0400
Message-ID: <53C69DE6.30001@mitre.org>
Date: Wed, 16 Jul 2014 11:44:38 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Maciej Machulak , Mike Jones 
References: <53BBDBEE.703@gmx.net>  <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADAB98C@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C65120.4020302@gmx.net> <53C664DC.50907@mit.edu> <53C665B0.7040708@gmx.net> <53C66797.1040509@mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADCB3B3@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C675F1.9080102@mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADCB58E@TK5EX14MBXC294.redmond.corp.microsoft.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020705050308060608060908"
X-Originating-IP: [10.140.19.249]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Zvq2Ns_-CURT2LlpMjyCjrgJL4w
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 16 Jul 2014 15:45:24 -0000

--------------020705050308060608060908
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Since it's an information reference, I would like to reference the 
as-of-now-current ID for UMA:

http://tools.ietf.org/html/draft-hardjono-oauth-umacore-09

  -- Justin

On 07/16/2014 10:12 AM, Maciej Machulak wrote:
> Mike,
>
> See comments below:
>
> On 16 July 2014 15:54, Mike Jones  > wrote:
>
>     OK - looking back at the parameter name change example, I agree
>     that this was first discussed in the OAuth WG and was adopted by
>     both specs at about the same time, so I agree that that's an
>     example of information flowing in the other direction.  (I doubt
>     that anyone will assert IPR about a parameter name change, so I
>     suspect that instance was innocuous.)  When some of the same
>     people were in two working groups doing highly related things, I
>     suppose some of that was bound to happen, despite the best of
>     intentions.  However, it's still my assertion that the core
>     inventions in Connect Registration were independently developed,
>     syntax tweaks made later for compatibility reasons aside.
>
>     Be that as it may, and having thought about it some more, I'm not
>     going to stand in the way of acknowledging UMA in the OAuth
>     Registration spec if people believe that that's the right thing to
>     do.  People who know me know that I'm all in favor of giving
>     credit where credit is due.  I'd thought that all the UMA content
>     had been replaced, but if I'm wrong about that, so be it.
>
>
> That is fine - if the content has been removed then just don't give 
> the credit - I'm fine both ways.
>
>
>     What would be the right reference for the UMA registration
>     specification in the acknowledgement?
>
>
> This is the latest doc that was ever produced, as far as I am aware of:
> http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-03
>
> Kind regards,
> Maciej
>
>
>                                     -- Mike
>
>     -----Original Message-----
>     From: Justin Richer [mailto:jricher@MIT.EDU ]
>     Sent: Wednesday, July 16, 2014 5:54 AM
>     To: Mike Jones; Hannes Tschofenig; oauth@ietf.org
>     
>     Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
>
>     It's quite true that the OIDC draft predates -00 of the IETF
>     draft, and I'm sorry if that was unclear from what I said as I was
>     not intending to misrepresent the history. And it's true that the
>     UMA draft predates both of these by a fair whack and at the very
>     least provided inspiration in how to accomplish this task, and in
>     fact draft -00 was a straight copy of UMA. As Mike mentions below,
>     draft -01 (when I took over the editor
>     role) incorporates a lot of text from the OIDF draft alongside the
>     UMA text, which is why that document has eight authors on it.
>
>     However it's not true that information didn't flow both ways, or
>     that everything from UMA was eventually expunged. It's fairly
>     clear if you look at the document history that there was a lot of
>     back and forth. The JSON formatting in the IETF draft, for
>     example, exists in -00 and came from UMA, was switched to form
>     encoding from in -01 (from OIDC), and with lots of discussion here
>     in the WG (both before and after the
>     change) was switched back to JSON in -05. At that time, there was
>     a discussion in the OIDF working group of whether to adopt the
>     JSON formatting as well in order to maintain compatibility, and
>     OIDF decided to do so. There were other instances where parameter
>     names and other ideas began in the IETF and moved to OIDF's spec,
>     like changing "issued_at" to the more clear "client_id_issued_at".
>     These were breaking changes and not entered into lightly, and I
>     was there for those discussions and still contend that OIDF made
>     the right call.
>
>     If the OIDF wants to frame that decision as "we decided
>     independently to do a thing for the greater good" as opposed to
>     "we adopted ideas from outside", then it's free to do so for
>     whatever legal protection reasons it likes. It's perfectly fine
>     with me that the OIDF represent itself and its documents how it
>     sees best. But it's not OK with me to discount or misrepresent the
>     history and provenance of the ideas and components of this IETF
>     document in the IETF and I'd like to include the modified
>     statement I posted below in the introduction text of the next
>     revision.
>
>       -- Justin
>
>     On 7/16/2014 8:34 AM, Mike Jones wrote:
>     > I disagree with one aspect of Justin's characterization of the
>     history of the spec and have data to back up my disagreement.  The
>     OpenID Connect Dynamic Registration Specification was not based on
>     draft-ietf-oauth-dyn-reg-00 or the UMA specification.  It was
>     created independently by John Bradley in June 2011 based upon
>     OpenID Connect working group discussions that predated
>     draft-ietf-oauth-dyn-reg-00, and for which there are working group
>     notes documenting the OpenID Connect working group decisions prior
>     to the IETF -00 draft.  Yes, there's plenty of evidence that the
>     IETF -01 draft copied text from the early OpenID Connect draft
>     (including in the change history), but the Connect authors were
>     careful to follow the OpenID Foundation's IPR process and not
>     incorporate contributions from third parties who hadn't signed an
>     OpenID IPR Contribution Agreement stating that the OpenID
>     Foundation was free to use their contributions.  (This fills the
>     same role as the IETF Note well, but with a signed agreement, and
>     ensures that all developers can use the resulting specifications
>     without IPR concerns based on IPR that may be held by the
>     contributors.)  The OpenID Connect Dynamic Registration draft
>     didn't copy from the UMA draft or the IETF draft derived from it,
>     so as to maintain the IPR integrity of the OpenID document.  The
>     copying all went in the other direction.
>     >
>     > If portions of the UMA draft remained from -00 in the current
>     drafts,
>     > I'd be fine with the UMA attribution, but in practice they
>     don't.  The
>     > UMA content was replaced with the OpenID Connect content.  (I
>     believe
>     > that eventually UMA decided to drop their old draft and move to
>     > registration mechanisms that were compatible with Connect as
>     well, and
>     > stopped using their previous registration data formats.)
>     >
>     >                               -- Mike
>     >
>     > -----Original Message-----
>     > From: Justin Richer [mailto:jricher@MIT.EDU
>     ]
>     > Sent: Wednesday, July 16, 2014 4:53 AM
>     > To: Hannes Tschofenig; Mike Jones; oauth@ietf.org
>     
>     > Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR
>     Confirmation
>     >
>     > I like the idea of adding some of the text in the introduction,
>     as I agree the compatibility is an important (and hard-won)
>     accomplishment. I think taking Mike's text, expanding it, and
>     putting it in the introduction might serve the overall purpose
>     just fine:
>     >
>     > Portions of this specification are derived from the OpenID
>     Connect Dynamic Registration [OpenID.Registration] specification
>     and from the User Managed Access [UMA] specification.  This was
>     done so that implementations of these three specifications will be
>     compatible with one another.
>     >
>     >
>     > These are both informative references, so we can reference the
>     ID for UMA.
>     >
>     >    -- Justin
>     >
>     > On 7/16/2014 7:44 AM, Hannes Tschofenig wrote:
>     >> Interesting background information. Maybe we should then extend the
>     >> note Mike provided to also clarify the relationship with the
>     UMA work
>     >> (both in terms to IPR, copyright, and attribution-wise).
>     >>
>     >> It would also make sense to state the relationship in the
>     >> introduction to highlight the compatibility, which I believe is
>     a big accomplishment.
>     >>
>     >> Ciao
>     >> Hannes
>     >>
>     >> On 07/16/2014 01:41 PM, Justin Richer wrote:
>     >>> I thought I had sent this note already, but I don't see it in the
>     >>> archives or in my 'sent' folder:
>     >>>
>     >>> If we're going to point to OpenID Connect (which I'm fine with),
>     >>> then we should clarify that portions were also taken from the
>     UMA specification.
>     >>> In fact, draft -00 actually *was* the UMA specification text
>     entirely.
>     >>> This is also what the OpenID Connect registration
>     specification was
>     >>> (loosely) based on when it was started.
>     >>>
>     >>> In reality, the relationship between these three documents from
>     >>> three different SBO's is more complicated: they all grew up
>     together
>     >>> and effectively merged to become wire-compatible with each other.
>     >>> There were a number of changes that were discussed here in the
>     IETF
>     >>> that OpenID Connect adopted, and a number of changes that were
>     >>> discussed at OIDF that were adopted here. OIDC also extends
>     the IETF
>     >>> draft with a set of OIDC-specific metadata fields and editorial
>     >>> language that makes it fit more closely in the OIDC landscape,
>     but make no mistake:
>     >>> they're the same protocol. In the case of UMA, it's a straight
>     >>> normative reference to the IETF document now because we were
>     able to
>     >>> incorporate those use cases and parameters directly.
>     >>>
>     >>> The trouble is, I'm not sure how to concisely state that all
>     that in
>     >>> the draft text, but it's not as simple as "we copied OpenID",
>     which
>     >>> is what the text below seems to say.
>     >>>
>     >>>    -- Justin
>     >>>
>     >>> On 7/16/2014 6:17 AM, Hannes Tschofenig wrote:
>     >>>> Thanks, Mike.
>     >>>>
>     >>>> This is a useful addition and reflects the relationship
>     between the
>     >>>> two efforts.
>     >>>>
>     >>>> Please add it to the next draft version.
>     >>>>
>     >>>> Ciao
>     >>>> Hannes
>     >>>>
>     >>>> On 07/15/2014 09:46 PM, Mike Jones wrote:
>     >>>>> So that the working group has concrete language to consider,
>     >>>>> propose the following language to the OAuth Dynamic Client
>     Registration specification:
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> Portions of this specification are derived from the OpenID
>     Connect
>     >>>>> Dynamic Registration [OpenID.Registration] specification.  This
>     >>>>> was done so that implementations of this specification and
>     OpenID
>     >>>>> Connect Dynamic Registration can be compatible with one another.
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>>                             --
>     >>>>> Mike
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org
>     ] *On Behalf Of *Mike
>     >>>>> Jones
>     >>>>> *Sent:* Tuesday, July 08, 2014 7:15 PM
>     >>>>> *To:* Phil Hunt; Hannes Tschofenig
>     >>>>> *Cc:* Maciej Machulak; oauth@ietf.org 
>     >>>>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR
>     >>>>> Confirmation
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> Thinking about this some more, there is one IPR issue that
>     we need
>     >>>>> to address before publication.  This specification is a
>     derivative
>     >>>>> work from the OpenID Connect Dynamic Registration specification
>     >>>>> http://openid.net/specs/openid-connect-registration-1_0.html.
>     >>>>> Large portions of the text were copied wholesale from that
>     spec to
>     >>>>> this one, so that the two would be compatible.  (This is good
>     >>>>> thing -- not a bad
>     >>>>> thing.)
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> This is easy to address from an IPR perspective -- simply
>     >>>>> acknowledge that this spec is a derivative work and provide
>     proper
>     >>>>> attribution.  The OpenID copyright in the spec at
>     >>>>>
>     http://openid.net/specs/openid-connect-registration-1_0.html#Notic
>     >>>>> e s allows for this resolution.  It says:
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> Copyright (c) 2014 The OpenID Foundation.
>     >>>>>
>     >>>>> The OpenID Foundation (OIDF) grants to any Contributor,
>     developer,
>     >>>>> implementer, or other interested party a non-exclusive, royalty
>     >>>>> free, worldwide copyright license to reproduce, prepare
>     derivative
>     >>>>> works from, distribute, perform and display, this Implementers
>     >>>>> Draft or Final Specification solely for the purposes of (i)
>     >>>>> developing specifications, and (ii) implementing Implementers
>     >>>>> Drafts and Final Specifications based on such documents,
>     provided
>     >>>>> that attribution be made to the OIDF as the source of the
>     >>>>> material, but that such attribution does not indicate an
>     endorsement by the OIDF.
>     >>>>>
>     >>>>> Let's add the reference and acknowledgment in the next version.
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>>                             --
>     >>>>> Mike
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> *From:*Mike Jones
>     >>>>> *Sent:* Tuesday, July 08, 2014 10:06 AM
>     >>>>> *To:* Phil Hunt; Hannes Tschofenig
>     >>>>> *Cc:* John Bradley; Justin Richer; Maciej Machulak;
>     oauth@ietf.org 
>     >>>>> >
>     >>>>> *Subject:* RE: Dynamic Client Registration: IPR Confirmation
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> I likewise do not hold any IPR on these specs.
>     >>>>>
>     >>>>>
>     ------------------------------------------------------------------
>     >>>>> -
>     >>>>> -----
>     >>>>>
>     >>>>> *From: *Phil Hunt      >
>     >>>>> *Sent: *?7/?8/?2014 9:11 AM
>     >>>>> *To: *Hannes Tschofenig      >
>     >>>>> *Cc: *Mike Jones      >; John
>     >>>>> Bradley      >; Justin Richer
>     >>>>> >;
>     Maciej Machulak
>     >>>>>      >; oauth@ietf.org
>     
>     >>>>> >
>     >>>>> *Subject: *Re: Dynamic Client Registration: IPR Confirmation
>     >>>>>
>     >>>>> I confirm I have no IPR disclosures on this document.
>     >>>>>
>     >>>>> Phil
>     >>>>>
>     >>>>>> On Jul 8, 2014, at 4:54, Hannes Tschofenig
>     
>          >> wrote:
>     >>>>>>
>     >>>>>> Hi Phil, John, Maciej, Justin, Mike,
>     >>>>>>
>     >>>>>> I am working on the shepherd writeup for the dynamic client
>     >>>>>> registration document and 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?
>     >>>>>>
>     >>>>>> Ciao
>     >>>>>> Hannes
>     >>>>>>
>     >>>>>>
>     >>>> _______________________________________________
>     >>>> OAuth mailing list
>     >>>> OAuth@ietf.org 
>     >>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> -- 
> Maciej Machulak
> email: maciej.machulak@gmail.com 
> mobile: +44 7999 606 767 (UK)
> mobile: +48 602 45 31 66 (PL)
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    Since it's an information reference, I would like to reference the
    as-of-now-current ID for UMA:

    

    http://tools.ietf.org/html/draft-hardjono-oauth-umacore-09

    

     -- Justin

    

    
On 07/16/2014 10:12 AM, Maciej Machulak
      wrote:

    

    

      
      
Mike,
        


        

        
See comments below:

        


          
On 16 July 2014 15:54, Mike Jones <Michael.Jones@microsoft.com>
            wrote:

            
OK
              - looking back at the parameter name change example, I
              agree that this was first discussed in the OAuth WG and
              was adopted by both specs at about the same time, so I
              agree that that's an example of information flowing in the
              other direction.  (I doubt that anyone will assert IPR
              about a parameter name change, so I suspect that instance
              was innocuous.)  When some of the same people were in two
              working groups doing highly related things, I suppose some
              of that was bound to happen, despite the best of
              intentions.  However, it's still my assertion that the
              core inventions in Connect Registration were independently
              developed, syntax tweaks made later for compatibility
              reasons aside.

              

              Be that as it may, and having thought about it some more,
              I'm not going to stand in the way of acknowledging UMA in
              the OAuth Registration spec if people believe that that's
              the right thing to do.  People who know me know that I'm
              all in favor of giving credit where credit is due.  I'd
              thought that all the UMA content had been replaced, but if
              I'm wrong about that, so be it.

            

            


            

            
That is fine - if the content has been removed then
              just don't give the credit - I'm fine both ways.

            
 

            


              What would be the right reference for the UMA registration
              specification in the acknowledgement?

            

            


            

            
This is the latest doc that was ever produced, as far
              as I am aware of:

            
            


            

            
Kind regards,

            
Maciej

            
 

            

              


                                                -- Mike

                

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

                From: Justin Richer [mailto:jricher@MIT.EDU]

              

              

                
Sent: Wednesday, July 16, 2014 5:54 AM

                  To: Mike Jones; Hannes Tschofenig; oauth@ietf.org

                  Subject: Re: [OAUTH-WG] Dynamic Client Registration:
                  IPR Confirmation

                  

                  It's quite true that the OIDC draft predates -00 of
                  the IETF draft, and I'm sorry if that was unclear from
                  what I said as I was not intending to misrepresent the
                  history. And it's true that the UMA draft predates
                  both of these by a fair whack and at the very least
                  provided inspiration in how to accomplish this task,
                  and in fact draft -00 was a straight copy of UMA. As
                  Mike mentions below, draft -01 (when I took over the
                  editor

                  role) incorporates a lot of text from the OIDF draft
                  alongside the UMA text, which is why that document has
                  eight authors on it.

                  

                  However it's not true that information didn't flow
                  both ways, or that everything from UMA was eventually
                  expunged. It's fairly clear if you look at the
                  document history that there was a lot of back and
                  forth. The JSON formatting in the IETF draft, for
                  example, exists in -00 and came from UMA, was switched
                  to form encoding from in -01 (from OIDC), and with
                  lots of discussion here in the WG (both before and
                  after the

                  change) was switched back to JSON in -05. At that
                  time, there was a discussion in the OIDF working group
                  of whether to adopt the JSON formatting as well in
                  order to maintain compatibility, and OIDF decided to
                  do so. There were other instances where parameter
                  names and other ideas began in the IETF and moved to
                  OIDF's spec, like changing "issued_at" to the more
                  clear "client_id_issued_at". These were breaking
                  changes and not entered into lightly, and I was there
                  for those discussions and still contend that OIDF made
                  the right call.

                  

                  If the OIDF wants to frame that decision as "we
                  decided independently to do a thing for the greater
                  good" as opposed to "we adopted ideas from outside",
                  then it's free to do so for whatever legal protection
                  reasons it likes. It's perfectly fine with me that the
                  OIDF represent itself and its documents how it sees
                  best. But it's not OK with me to discount or
                  misrepresent the history and provenance of the ideas
                  and components of this IETF document in the IETF and
                  I'd like to include the modified statement I posted
                  below in the introduction text of the next revision.

                  

                    -- Justin

                  

                  On 7/16/2014 8:34 AM, Mike Jones wrote:

                  > I disagree with one aspect of Justin's
                  characterization of the history of the spec and have
                  data to back up my disagreement.  The OpenID Connect
                  Dynamic Registration Specification was not based on
                  draft-ietf-oauth-dyn-reg-00 or the UMA specification.
                   It was created independently by John Bradley in June
                  2011 based upon OpenID Connect working group
                  discussions that predated draft-ietf-oauth-dyn-reg-00,
                  and for which there are working group notes
                  documenting the OpenID Connect working group decisions
                  prior to the IETF -00 draft.  Yes, there's plenty of
                  evidence that the IETF -01 draft copied text from the
                  early OpenID Connect draft (including in the change
                  history), but the Connect authors were careful to
                  follow the OpenID Foundation's IPR process and not
                  incorporate contributions from third parties who
                  hadn't signed an OpenID IPR Contribution Agreement
                  stating that the OpenID Foundation was free to use
                  their contributions.  (This fills the same role as the
                  IETF Note well, but with a signed agreement, and
                  ensures that all developers can use the resulting
                  specifications without IPR concerns based on IPR that
                  may be held by the contributors.)  The OpenID Connect
                  Dynamic Registration draft didn't copy from the UMA
                  draft or the IETF draft derived from it, so as to
                  maintain the IPR integrity of the OpenID document.
                   The copying all went in the other direction.

                  >

                  > If portions of the UMA draft remained from -00 in
                  the current drafts,

                  > I'd be fine with the UMA attribution, but in
                  practice they don't.  The

                  > UMA content was replaced with the OpenID Connect
                  content.  (I believe

                  > that eventually UMA decided to drop their old
                  draft and move to

                  > registration mechanisms that were compatible with
                  Connect as well, and

                  > stopped using their previous registration data
                  formats.)

                  >

                  >                               -- Mike

                  >

                  > -----Original Message-----

                  > From: Justin Richer [mailto:jricher@MIT.EDU]

                  > Sent: Wednesday, July 16, 2014 4:53 AM

                  > To: Hannes Tschofenig; Mike Jones; oauth@ietf.org

                  > Subject: Re: [OAUTH-WG] Dynamic Client
                  Registration: IPR Confirmation

                  >

                  > I like the idea of adding some of the text in the
                  introduction, as I agree the compatibility is an
                  important (and hard-won) accomplishment. I think
                  taking Mike's text, expanding it, and putting it in
                  the introduction might serve the overall purpose just
                  fine:

                  >

                  > Portions of this specification are derived from
                  the OpenID Connect Dynamic Registration
                  [OpenID.Registration] specification and from the User
                  Managed Access [UMA] specification.  This was done so
                  that implementations of these three specifications
                  will be compatible with one another.

                  >

                  >

                  > These are both informative references, so we can
                  reference the ID for UMA.

                  >

                  >    -- Justin

                  >

                  > On 7/16/2014 7:44 AM, Hannes Tschofenig wrote:

                  >> Interesting background information. Maybe we
                  should then extend the

                  >> note Mike provided to also clarify the
                  relationship with the UMA work

                  >> (both in terms to IPR, copyright, and
                  attribution-wise).

                  >>

                  >> It would also make sense to state the
                  relationship in the

                  >> introduction to highlight the compatibility,
                  which I believe is a big accomplishment.

                  >>

                  >> Ciao

                  >> Hannes

                  >>

                  >> On 07/16/2014 01:41 PM, Justin Richer wrote:

                  >>> I thought I had sent this note already,
                  but I don't see it in the

                  >>> archives or in my 'sent' folder:

                  >>>

                  >>> If we're going to point to OpenID Connect
                  (which I'm fine with),

                  >>> then we should clarify that portions were
                  also taken from the UMA specification.

                  >>> In fact, draft -00 actually *was* the UMA
                  specification text entirely.

                  >>> This is also what the OpenID Connect
                  registration specification was

                  >>> (loosely) based on when it was started.

                  >>>

                  >>> In reality, the relationship between
                  these three documents from

                  >>> three different SBO's is more
                  complicated: they all grew up together

                  >>> and effectively merged to become
                  wire-compatible with each other.

                  >>> There were a number of changes that were
                  discussed here in the IETF

                  >>> that OpenID Connect adopted, and a number
                  of changes that were

                  >>> discussed at OIDF that were adopted here.
                  OIDC also extends the IETF

                  >>> draft with a set of OIDC-specific
                  metadata fields and editorial

                  >>> language that makes it fit more closely
                  in the OIDC landscape, but make no mistake:

                  >>> they're the same protocol. In the case of
                  UMA, it's a straight

                  >>> normative reference to the IETF document
                  now because we were able to

                  >>> incorporate those use cases and
                  parameters directly.

                  >>>

                  >>> The trouble is, I'm not sure how to
                  concisely state that all that in

                  >>> the draft text, but it's not as simple as
                  "we copied OpenID", which

                  >>> is what the text below seems to say.

                  >>>

                  >>>    -- Justin

                  >>>

                  >>> On 7/16/2014 6:17 AM, Hannes Tschofenig
                  wrote:

                  >>>> Thanks, Mike.

                  >>>>

                  >>>> This is a useful addition and
                  reflects the relationship between the

                  >>>> two efforts.

                  >>>>

                  >>>> Please add it to the next draft
                  version.

                  >>>>

                  >>>> Ciao

                  >>>> Hannes

                  >>>>

                  >>>> On 07/15/2014 09:46 PM, Mike Jones
                  wrote:

                  >>>>> So that the working group has
                  concrete language to consider,

                  >>>>> propose the following language to
                  the OAuth Dynamic Client Registration specification:

                  >>>>>

                  >>>>>

                  >>>>>

                  >>>>> Portions of this specification
                  are derived from the OpenID Connect

                  >>>>> Dynamic Registration
                  [OpenID.Registration] specification.  This

                  >>>>> was done so that implementations
                  of this specification and OpenID

                  >>>>> Connect Dynamic Registration can
                  be compatible with one another.

                  >>>>>

                  >>>>>

                  >>>>>

                  >>>>>                                  
                                              --

                  >>>>> Mike

                  >>>>>

                  >>>>>

                  >>>>>

                  >>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org]
                  *On Behalf Of *Mike

                  >>>>> Jones

                  >>>>> *Sent:* Tuesday, July 08, 2014
                  7:15 PM

                  >>>>> *To:* Phil Hunt; Hannes
                  Tschofenig

                  >>>>> *Cc:* Maciej Machulak; oauth@ietf.org

                  >>>>> *Subject:* Re: [OAUTH-WG] Dynamic
                  Client Registration: IPR

                  >>>>> Confirmation

                  >>>>>

                  >>>>>

                  >>>>>

                  >>>>> Thinking about this some more,
                  there is one IPR issue that we need

                  >>>>> to address before publication.
                   This specification is a derivative

                  >>>>> work from the OpenID Connect
                  Dynamic Registration specification

                  >>>>> http://openid.net/specs/openid-connect-registration-1_0.html.

                  >>>>> Large portions of the text were
                  copied wholesale from that spec to

                  >>>>> this one, so that the two would
                  be compatible.  (This is good

                  >>>>> thing – not a bad

                  >>>>> thing.)

                  >>>>>

                  >>>>>

                  >>>>>

                  >>>>> This is easy to address from an
                  IPR perspective – simply

                  >>>>> acknowledge that this spec is a
                  derivative work and provide proper

                  >>>>> attribution.  The OpenID
                  copyright in the spec at

                  >>>>> http://openid.net/specs/openid-connect-registration-1_0.html#Notic

                

              

              

                
>>>>> e s allows for this
                  resolution.  It says:

                  >>>>>

                  >>>>>

                  >>>>>

                  >>>>> Copyright (c) 2014 The OpenID
                  Foundation.

                  >>>>>

                  >>>>> The OpenID Foundation (OIDF)
                  grants to any Contributor, developer,

                  >>>>> implementer, or other interested
                  party a non-exclusive, royalty

                  >>>>> free, worldwide copyright license
                  to reproduce, prepare derivative

                  >>>>> works from, distribute, perform
                  and display, this Implementers

                  >>>>> Draft or Final Specification
                  solely for the purposes of (i)

                  >>>>> developing specifications, and
                  (ii) implementing Implementers

                  >>>>> Drafts and Final Specifications
                  based on such documents, provided

                  >>>>> that attribution be made to the
                  OIDF as the source of the

                  >>>>> material, but that such
                  attribution does not indicate an endorsement by the
                  OIDF.

                  >>>>>

                  >>>>> Let’s add the reference and
                  acknowledgment in the next version.

                  >>>>>

                  >>>>>

                  >>>>>

                  >>>>>                                  
                                              --

                  >>>>> Mike

                  >>>>>

                  >>>>>

                  >>>>>

                  >>>>> *From:*Mike Jones

                  >>>>> *Sent:* Tuesday, July 08, 2014
                  10:06 AM

                  >>>>> *To:* Phil Hunt; Hannes
                  Tschofenig

                  >>>>> *Cc:* John Bradley; Justin
                  Richer; Maciej Machulak; oauth@ietf.org

                  >>>>> <mailto:oauth@ietf.org>

                  >>>>> *Subject:* RE: Dynamic Client
                  Registration: IPR Confirmation

                  >>>>>

                  >>>>>

                  >>>>>

                  >>>>> I likewise do not hold any IPR on
                  these specs.

                  >>>>>

                  >>>>>
                  ------------------------------------------------------------------

                  >>>>> -

                  >>>>> -----

                  >>>>>

                  >>>>> *From: *Phil Hunt <mailto:phil.hunt@oracle.com>

                  >>>>> *Sent: *‎7/‎8/‎2014 9:11 AM

                  >>>>> *To: *Hannes Tschofenig
                  <mailto:hannes.tschofenig@gmx.net>

                  >>>>> *Cc: *Mike Jones <mailto:Michael.Jones@microsoft.com>;
                  John

                  >>>>> Bradley <mailto:ve7jtb@ve7jtb.com>;
                  Justin Richer

                  >>>>> <mailto:jricher@mitre.org>;
                  Maciej Machulak

                  >>>>> <mailto:m.p.machulak@ncl.ac.uk>;
                  oauth@ietf.org

                  >>>>> <mailto:oauth@ietf.org>

                  >>>>> *Subject: *Re: Dynamic Client
                  Registration: IPR Confirmation

                  >>>>>

                  >>>>> I confirm I have no IPR
                  disclosures on this document.

                  >>>>>

                  >>>>> Phil

                  >>>>>

                  >>>>>> On Jul 8, 2014, at 4:54,
                  Hannes Tschofenig <hannes.tschofenig@gmx.net
                  <mailto:hannes.tschofenig@gmx.net>>
                  wrote:

                  >>>>>>

                  >>>>>> Hi Phil, John, Maciej,
                  Justin, Mike,

                  >>>>>>

                  >>>>>> I am working on the shepherd
                  writeup for the dynamic client

                  >>>>>> registration document and 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?

                  >>>>>>

                  >>>>>> Ciao

                  >>>>>> Hannes

                  >>>>>>

                  >>>>>>

                  >>>>
                  _______________________________________________

                  >>>> OAuth mailing list

                  >>>> OAuth@ietf.org

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

                  

                  

                  _______________________________________________

                  OAuth mailing list

                  OAuth@ietf.org

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

                

              

            

          

          

          

          


          

          -- 

          Maciej Machulak

          email: maciej.machulak@gmail.com

          mobile: +44 7999 606 767 (UK)

          mobile: +48 602 45 31 66 (PL)
        

      

      

      

      

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


    

    

  


--------------020705050308060608060908--


From nobody Wed Jul 16 09:23:33 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F861A0012 for ; Wed, 16 Jul 2014 09:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 991Ba1vsGYZs for ; Wed, 16 Jul 2014 09:23:24 -0700 (PDT)
Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167061A000B for ; Wed, 16 Jul 2014 09:23:23 -0700 (PDT)
Received: by mail-qg0-f50.google.com with SMTP id q108so933831qgd.37 for ; Wed, 16 Jul 2014 09:23:23 -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=yrtHOinZcX8sbbtm7+pixS7unOjNbbbwt2LVWd0y3U4=; b=SXfX+hK0p77ipHAgnLs64ixmTYouM3Rm2qTjAqNy8d/cvJM+LbHL/uxZl8xhKm9wVl 6hjA7QHXm1GawMi0/fvu5yBrMkLB+p5TdEs1fRwgkYwOOVImiVi84NRMl/ae7k+x6o2L A6HsjaO1x1csh2ZVIOKf1+6aD8U9uQgdnw3gAjHAwrWZbXNu3Q/8LfkdkFY4raiJcgq1 PBDEimVduwt1opZW4wU6S/qUO9m+PMUnvbtW0pA660VzArOZWurVtip3EbyUzDAsCS2+ ixJ7P2NFcq2m7sgWs6VqikJO5YDXNT8ZuXhS1GP11ANwmsyPsNfDZtCjNLYCYF3gst9I LnJw==
X-Gm-Message-State: ALoCoQlBQd54rpDs21wuBRQgnWLaXW5r0nyN4l5lzUt0FEjNehWs2Ld7I+eE21SnJjNGXDLlkGIn
X-Received: by 10.229.226.135 with SMTP id iw7mr4430596qcb.13.1405527802988; Wed, 16 Jul 2014 09:23:22 -0700 (PDT)
Received: from [192.168.1.216] ([190.22.58.217]) by mx.google.com with ESMTPSA id k6sm17797089qge.2.2014.07.16.09.23.16 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 09:23:20 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Bradley 
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADCB58E@TK5EX14MBXC294.redmond.corp.microsoft.com>
Date: Wed, 16 Jul 2014 12:24:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <18D669AD-69D2-465D-92C6-4B944ED45941@ve7jtb.com>
References: <53BBDBEE.703@gmx.net>,  <4E1F6AAD24975D4BA5B16804296739439ADA02B7@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADA1766@TK5EX14MBXC294.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439ADAB98C@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C65120.4020302@gmx.net> <53C664DC.50907@mit.edu> <53C665B0.7040708@gmx.net> <53C66797.1040509@mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADCB3B3@TK5EX14MBXC294.redmond.corp.microsoft.com> <53C675F1.9080102@mit.edu> <4E1F6AAD24975D4BA5B16804296739439ADCB58E@TK5EX14MBXC294.redmond.corp.microsoft.com>
To: Michael Jones 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Elj5pkmSsApvJi6YD83y3r8kmbE
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Dynamic Client Registration: 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: Wed, 16 Jul 2014 16:23:29 -0000

May/June of 2010 OpenID Connect and OpenID artifact binding merged to =
crate a spec based on top of OAuth 2.

Aug 2010 there was a ID called "OAuth Dynamic Client Registration =
Protocol" http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00 that =
included discovery (XRD) published by Eve, Maciej and Chriatian that was =
used by UMA. =20
=20
The early model largely used a pull model to validate the identity of =
the client registering. eg The AS pulled down a file of JSON in a effort =
to validate an identity for the UMA client.
It did have amongst several methods one that was a client push.

Around May of 2011 I did the initial Connect dynamic client registration =
posting a JSON object with values to a registration endpoint and getting =
back a client_id and secret.
We went back and forth several times on Key value vs JSON requests over =
the spec's development.

In there initial forms it is true that the client winds up with a =
client_id and client secret, but I don't think they were in any way wire =
compatible.
Looking at it the parameter name "redirect_uri" (taken from the OAuth =
spec is the same but the values are different one is a string and the =
other an array of strings.

At a Connect WG meeting at IIW (fall 2011) with Eve who I believe is or =
was a Connect WG member from PayPal and I came up with making the =
registration endpoint OAuth protected with an initial acces token to =
provide the possibility of identifying the registrant, as that was part =
of the UMA use case.   That enabled UMA to I believe drop the pull =
registration and align more with Connect registration, as well as adopt =
Connect semantics in some other parts of UMA for compatibility. =20

That was added to the Connect in Oct/Nov 2011.  There were lots of other =
things like client secret key rotation that were in the Connect version =
but were taken out and moved to a management draft in the end and not =
put in the final connect version.

In May of 2012 Justin, Eve, Thomas & Mache published a 00 ID that was a =
copy of the UMA .

That was updated over I think 18 versions to get to what we have now.   =
Including input from Phil/Tony on software statements.

So in the way of the IETF a number of groups with initial documents =
covering similar use cases came together in a working group and a =
document was produced that satisfied multiple use cases so that adoption =
and interoperability of OAuth 2 could happen.

Yes one of the inputs is the 00 draft that was used by UMA before I =
think they migrated to the connect version.   I don't know what the UMA =
specs currently reference.

I think referencing the earlier ID  and giving credit to the earlier =
authors is fair. =20

John B.


On Jul 16, 2014, at 9:54 AM, Mike Jones  =
wrote:

> OK - looking back at the parameter name change example, I agree that =
this was first discussed in the OAuth WG and was adopted by both specs =
at about the same time, so I agree that that's an example of information =
flowing in the other direction.  (I doubt that anyone will assert IPR =
about a parameter name change, so I suspect that instance was =
innocuous.)  When some of the same people were in two working groups =
doing highly related things, I suppose some of that was bound to happen, =
despite the best of intentions.  However, it's still my assertion that =
the core inventions in Connect Registration were independently =
developed, syntax tweaks made later for compatibility reasons aside.
>=20
> Be that as it may, and having thought about it some more, I'm not =
going to stand in the way of acknowledging UMA in the OAuth Registration =
spec if people believe that that's the right thing to do.  People who =
know me know that I'm all in favor of giving credit where credit is due. =
 I'd thought that all the UMA content had been replaced, but if I'm =
wrong about that, so be it.
>=20
> What would be the right reference for the UMA registration =
specification in the acknowledgement?
>=20
> 				-- Mike
>=20
> -----Original Message-----
> From: Justin Richer [mailto:jricher@MIT.EDU]=20
> Sent: Wednesday, July 16, 2014 5:54 AM
> To: Mike Jones; Hannes Tschofenig; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
>=20
> It's quite true that the OIDC draft predates -00 of the IETF draft, =
and I'm sorry if that was unclear from what I said as I was not =
intending to misrepresent the history. And it's true that the UMA draft =
predates both of these by a fair whack and at the very least provided =
inspiration in how to accomplish this task, and in fact draft -00 was a =
straight copy of UMA. As Mike mentions below, draft -01 (when I took =
over the editor
> role) incorporates a lot of text from the OIDF draft alongside the UMA =
text, which is why that document has eight authors on it.
>=20
> However it's not true that information didn't flow both ways, or that =
everything from UMA was eventually expunged. It's fairly clear if you =
look at the document history that there was a lot of back and forth. The =
JSON formatting in the IETF draft, for example, exists in -00 and came =
from UMA, was switched to form encoding from in -01 (from OIDC), and =
with lots of discussion here in the WG (both before and after the
> change) was switched back to JSON in -05. At that time, there was a =
discussion in the OIDF working group of whether to adopt the JSON =
formatting as well in order to maintain compatibility, and OIDF decided =
to do so. There were other instances where parameter names and other =
ideas began in the IETF and moved to OIDF's spec, like changing =
"issued_at" to the more clear "client_id_issued_at". These were breaking =
changes and not entered into lightly, and I was there for those =
discussions and still contend that OIDF made the right call.
>=20
> If the OIDF wants to frame that decision as "we decided independently =
to do a thing for the greater good" as opposed to "we adopted ideas from =
outside", then it's free to do so for whatever legal protection reasons =
it likes. It's perfectly fine with me that the OIDF represent itself and =
its documents how it sees best. But it's not OK with me to discount or =
misrepresent the history and provenance of the ideas and components of =
this IETF document in the IETF and I'd like to include the modified =
statement I posted below in the introduction text of the next revision.
>=20
>  -- Justin
>=20
> On 7/16/2014 8:34 AM, Mike Jones wrote:
>> I disagree with one aspect of Justin's characterization of the =
history of the spec and have data to back up my disagreement.  The =
OpenID Connect Dynamic Registration Specification was not based on =
draft-ietf-oauth-dyn-reg-00 or the UMA specification.  It was created =
independently by John Bradley in June 2011 based upon OpenID Connect =
working group discussions that predated draft-ietf-oauth-dyn-reg-00, and =
for which there are working group notes documenting the OpenID Connect =
working group decisions prior to the IETF -00 draft.  Yes, there's =
plenty of evidence that the IETF -01 draft copied text from the early =
OpenID Connect draft (including in the change history), but the Connect =
authors were careful to follow the OpenID Foundation's IPR process and =
not incorporate contributions from third parties who hadn't signed an =
OpenID IPR Contribution Agreement stating that the OpenID Foundation was =
free to use their contributions.  (This fills the same role as the IETF =
Note well, but with a signed agreement, and ensures that all developers =
can use the resulting specifications without IPR concerns based on IPR =
that may be held by the contributors.)  The OpenID Connect Dynamic =
Registration draft didn't copy from the UMA draft or the IETF draft =
derived from it, so as to maintain the IPR integrity of the OpenID =
document.  The copying all went in the other direction.
>>=20
>> If portions of the UMA draft remained from -00 in the current drafts,=20=

>> I'd be fine with the UMA attribution, but in practice they don't.  =
The=20
>> UMA content was replaced with the OpenID Connect content.  (I believe=20=

>> that eventually UMA decided to drop their old draft and move to=20
>> registration mechanisms that were compatible with Connect as well, =
and=20
>> stopped using their previous registration data formats.)
>>=20
>> 				-- Mike
>>=20
>> -----Original Message-----
>> From: Justin Richer [mailto:jricher@MIT.EDU]
>> Sent: Wednesday, July 16, 2014 4:53 AM
>> To: Hannes Tschofenig; Mike Jones; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
>>=20
>> I like the idea of adding some of the text in the introduction, as I =
agree the compatibility is an important (and hard-won) accomplishment. I =
think taking Mike's text, expanding it, and putting it in the =
introduction might serve the overall purpose just fine:
>>=20
>> Portions of this specification are derived from the OpenID Connect =
Dynamic Registration [OpenID.Registration] specification and from the =
User Managed Access [UMA] specification.  This was done so that =
implementations of these three specifications will be compatible with =
one another.
>>=20
>>=20
>> These are both informative references, so we can reference the ID for =
UMA.
>>=20
>>   -- Justin
>>=20
>> On 7/16/2014 7:44 AM, Hannes Tschofenig wrote:
>>> Interesting background information. Maybe we should then extend the=20=

>>> note Mike provided to also clarify the relationship with the UMA =
work=20
>>> (both in terms to IPR, copyright, and attribution-wise).
>>>=20
>>> It would also make sense to state the relationship in the=20
>>> introduction to highlight the compatibility, which I believe is a =
big accomplishment.
>>>=20
>>> Ciao
>>> Hannes
>>>=20
>>> On 07/16/2014 01:41 PM, Justin Richer wrote:
>>>> I thought I had sent this note already, but I don't see it in the=20=

>>>> archives or in my 'sent' folder:
>>>>=20
>>>> If we're going to point to OpenID Connect (which I'm fine with),=20
>>>> then we should clarify that portions were also taken from the UMA =
specification.
>>>> In fact, draft -00 actually *was* the UMA specification text =
entirely.
>>>> This is also what the OpenID Connect registration specification was
>>>> (loosely) based on when it was started.
>>>>=20
>>>> In reality, the relationship between these three documents from=20
>>>> three different SBO's is more complicated: they all grew up =
together=20
>>>> and effectively merged to become wire-compatible with each other.=20=

>>>> There were a number of changes that were discussed here in the IETF=20=

>>>> that OpenID Connect adopted, and a number of changes that were=20
>>>> discussed at OIDF that were adopted here. OIDC also extends the =
IETF=20
>>>> draft with a set of OIDC-specific metadata fields and editorial=20
>>>> language that makes it fit more closely in the OIDC landscape, but =
make no mistake:
>>>> they're the same protocol. In the case of UMA, it's a straight=20
>>>> normative reference to the IETF document now because we were able =
to=20
>>>> incorporate those use cases and parameters directly.
>>>>=20
>>>> The trouble is, I'm not sure how to concisely state that all that =
in=20
>>>> the draft text, but it's not as simple as "we copied OpenID", which=20=

>>>> is what the text below seems to say.
>>>>=20
>>>>   -- Justin
>>>>=20
>>>> On 7/16/2014 6:17 AM, Hannes Tschofenig wrote:
>>>>> Thanks, Mike.
>>>>>=20
>>>>> This is a useful addition and reflects the relationship between =
the=20
>>>>> two efforts.
>>>>>=20
>>>>> Please add it to the next draft version.
>>>>>=20
>>>>> Ciao
>>>>> Hannes
>>>>>=20
>>>>> On 07/15/2014 09:46 PM, Mike Jones wrote:
>>>>>> So that the working group has concrete language to consider,=20
>>>>>> propose the following language to the OAuth Dynamic Client =
Registration specification:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Portions of this specification are derived from the OpenID =
Connect=20
>>>>>> Dynamic Registration [OpenID.Registration] specification.  This=20=

>>>>>> was done so that implementations of this specification and OpenID=20=

>>>>>> Connect Dynamic Registration can be compatible with one another.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>                                                              --=20=

>>>>>> Mike
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Mike=20=

>>>>>> Jones
>>>>>> *Sent:* Tuesday, July 08, 2014 7:15 PM
>>>>>> *To:* Phil Hunt; Hannes Tschofenig
>>>>>> *Cc:* Maciej Machulak; oauth@ietf.org
>>>>>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR=20
>>>>>> Confirmation
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Thinking about this some more, there is one IPR issue that we =
need=20
>>>>>> to address before publication.  This specification is a =
derivative=20
>>>>>> work from the OpenID Connect Dynamic Registration specification=20=

>>>>>> http://openid.net/specs/openid-connect-registration-1_0.html.
>>>>>> Large portions of the text were copied wholesale from that spec =
to=20
>>>>>> this one, so that the two would be compatible.  (This is good=20
>>>>>> thing =E2=80=93 not a bad
>>>>>> thing.)
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> This is easy to address from an IPR perspective =E2=80=93 simply=20=

>>>>>> acknowledge that this spec is a derivative work and provide =
proper=20
>>>>>> attribution.  The OpenID copyright in the spec at=20
>>>>>> =
http://openid.net/specs/openid-connect-registration-1_0.html#Notic
>>>>>> e s allows for this resolution.  It says:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Copyright (c) 2014 The OpenID Foundation.
>>>>>>=20
>>>>>> The OpenID Foundation (OIDF) grants to any Contributor, =
developer,=20
>>>>>> implementer, or other interested party a non-exclusive, royalty=20=

>>>>>> free, worldwide copyright license to reproduce, prepare =
derivative=20
>>>>>> works from, distribute, perform and display, this Implementers=20
>>>>>> Draft or Final Specification solely for the purposes of (i)=20
>>>>>> developing specifications, and (ii) implementing Implementers=20
>>>>>> Drafts and Final Specifications based on such documents, provided=20=

>>>>>> that attribution be made to the OIDF as the source of the=20
>>>>>> material, but that such attribution does not indicate an =
endorsement by the OIDF.
>>>>>>=20
>>>>>> Let=E2=80=99s add the reference and acknowledgment in the next =
version.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>                                                              --=20=

>>>>>> Mike
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> *From:*Mike Jones
>>>>>> *Sent:* Tuesday, July 08, 2014 10:06 AM
>>>>>> *To:* Phil Hunt; Hannes Tschofenig
>>>>>> *Cc:* John Bradley; Justin Richer; Maciej Machulak; =
oauth@ietf.org=20
>>>>>> 
>>>>>> *Subject:* RE: Dynamic Client Registration: IPR Confirmation
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> I likewise do not hold any IPR on these specs.
>>>>>>=20
>>>>>> =
------------------------------------------------------------------
>>>>>> -
>>>>>> -----
>>>>>>=20
>>>>>> *From: *Phil Hunt 
>>>>>> *Sent: *=E2=80=8E7/=E2=80=8E8/=E2=80=8E2014 9:11 AM
>>>>>> *To: *Hannes Tschofenig 
>>>>>> *Cc: *Mike Jones ; John=20
>>>>>> Bradley ; Justin Richer=20
>>>>>> ; Maciej Machulak=20
>>>>>> ; oauth@ietf.org=20
>>>>>> 
>>>>>> *Subject: *Re: Dynamic Client Registration: IPR Confirmation
>>>>>>=20
>>>>>> I confirm I have no IPR disclosures on this document.
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>>> On Jul 8, 2014, at 4:54, Hannes Tschofenig =
> wrote:
>>>>>>>=20
>>>>>>> Hi Phil, John, Maciej, Justin, Mike,
>>>>>>>=20
>>>>>>> I am working on the shepherd writeup for the dynamic client=20
>>>>>>> registration document and one item in the template requires me =
to=20
>>>>>>> indicate whether each document author has confirmed that any and=20=

>>>>>>> all appropriate IPR disclosures required for full conformance=20
>>>>>>> with the provisions of BCP 78 and BCP 79 have already been =
filed.
>>>>>>>=20
>>>>>>> Could you please confirm?
>>>>>>>=20
>>>>>>> Ciao
>>>>>>> Hannes
>>>>>>>=20
>>>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From richard.t.snowden@gmail.com  Thu Jul 17 01:47:14 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8CB1A0109 for ; Thu, 17 Jul 2014 01:47:14 -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 ji9q5RLURhCe for ; Thu, 17 Jul 2014 01:47:12 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EA61A00F3 for ; Thu, 17 Jul 2014 01:47:12 -0700 (PDT)
Received: by mail-ig0-f170.google.com with SMTP id h3so5407740igd.1 for ; Thu, 17 Jul 2014 01:47:11 -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=Y55Q/YWvAS2muHRNMXDmp14R3ko47wsvsd4HSOkcrJs=; b=LDcrXXvbrqO+1H9cKw8sq20CaxxRIpB5ucuTFcRjHq0TkKfQ2wcd5oFNmR/50P85hm GIGGYQzOyWqnbZIKznHvwJkG1Egg8y8hHIWNTEfQmsf5y2SCScByJL2Oq94ZWSZWp0Jo dHPeyA1b/3jP7apaQKejbqKG5s/MuXpsOYJvOtid5bCK5xAOA4dl2YShRZDKU4snTfX/ V9sQ4TmISyImrY2h7UuLnCCULDN7DjU6R/lYeBgzOf5fIV7vyZdhSIYuX6cenH0EWTF/ h8DGs9eP9MdHBQYZf9GuzbsAFwsQD/muGDKAUncYgXOputAGaFHT8Jbcyx3B3V15FISV UgkA==
MIME-Version: 1.0
X-Received: by 10.60.155.231 with SMTP id vz7mr43699392oeb.56.1405586831784; Thu, 17 Jul 2014 01:47:11 -0700 (PDT)
Received: by 10.60.56.162 with HTTP; Thu, 17 Jul 2014 01:47:11 -0700 (PDT)
Date: Thu, 17 Jul 2014 10:47:11 +0200
Message-ID: 
From: Richard Snowden 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=047d7bd7668ecf425b04fe5faffe
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HWBGES_OuidOCJc73dLS6hJ2GYQ
Subject: [OAUTH-WG] Authorization Server
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, 17 Jul 2014 08:52:55 -0000

--047d7bd7668ecf425b04fe5faffe
Content-Type: text/plain; charset=UTF-8

Hi there,

after viewing some tutorials and running some samples code I understood the
client side of OAuth 2.0.

Using existing Authorization Server seems to be not too complicated.

Question is: How to implement my own Authorization Server?

Since many companies have their own User/Privilege system, LDAP based (e.g.
Active Directory), etc. - they must have their own Authorization Server.

Is there a framework, libraries, etc. for that? Or do I have to write the
code from scratch?

cheers,
Richard

--047d7bd7668ecf425b04fe5faffe
Content-Type: text/html; charset=UTF-8


Hi there,

after viewing some tutorials and running some samples code I understood the client side of OAuth 2.0.

Using existing Authorization Server seems to be not too complicated.



Question is: How to implement my own Authorization Server?

Since many companies have their own User/Privilege system, LDAP based (e.g. Active Directory), etc. - they must have their own Authorization Server.


Is there a framework, libraries, etc. for that? Or do I have to write the code from scratch?

cheers,
Richard


--047d7bd7668ecf425b04fe5faffe--


From nobody Thu Jul 17 17:12:45 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB9E1A00E2 for ; Thu, 17 Jul 2014 17:12:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.521
X-Spam-Level: 
X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 bt7QZ5cHkKJ8 for ; Thu, 17 Jul 2014 17:12:42 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A182A1A00DF for ; Thu, 17 Jul 2014 17:12:41 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id ho1so6602wib.16 for ; Thu, 17 Jul 2014 17:12:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:subject:date:to; bh=5kY2SprLgEPRJsYmPuKZ7QXUePAizW2SWRFrWCFSGEQ=; b=xjZcdmATK4OdUMt4vpkhWb1SlLrTZ8NFQI2GLd98eSgKWL8/iGjC59DR1PBu9xBCXy yoeDafFiCm7B1CnB0la8XeM/WMXi6QHKjawPLdQy6phEI/ZL3ff6v8OFrp/ahmHHNcEF MZ1Fq2IqTHtILk7FmytStrMnhVC2yA77j9yKyqPYX91F4I/zP7YVG01QVTsf8ZAHnIsy LR219xMw01An3WTJenIDDune2jBqJJAvjqt1y2SSNfChA3CJfDXWHVnaBAOiCPIL24Ct 5MiiyPL0+IzbkDnFBT77u1v4Our93fJRkST/nnr+bhQ9TReqqoasRjxyXU9NXItThlsw lEsg==
X-Received: by 10.194.59.49 with SMTP id w17mr818461wjq.135.1405642360003; Thu, 17 Jul 2014 17:12:40 -0700 (PDT)
Received: from [192.168.0.102] ([41.151.146.144]) by mx.google.com with ESMTPSA id fs3sm121973wic.20.2014.07.17.17.12.38 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jul 2014 17:12:38 -0700 (PDT)
From: Buhake Sindi 
X-Google-Original-From: Buhake Sindi 
References: 
In-Reply-To: 
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <25A4CB78-88B7-45D7-B5E1-C25734BDAF59@gmail.com>
X-Mailer: iPad Mail (9B206)
Date: Fri, 18 Jul 2014 02:12:40 +0200
To: Richard Snowden 
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jX1BPpuUyY3LN98SxUT8iqm1foM
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Authorization Server
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, 18 Jul 2014 00:12:43 -0000

Hi Richard,

I had the same dilemma. Most write their own Authorization server. Pretty so=
on, once I complete it officially, my company will release a Java library to=
 configure an OAuth Authorization server (as many have written me emails req=
uesting of such library). I don't know if there is an existing one yet, prob=
ably Spring Framework has?


Kind Regards,



Buhake Sindi
www.sindi.co.za


On 17 Jul 2014, at 10:47, Richard Snowden  wrot=
e:

> Hi there,
>=20
> after viewing some tutorials and running some samples code I understood th=
e client side of OAuth 2.0.
>=20
> Using existing Authorization Server seems to be not too complicated.
>=20
> Question is: How to implement my own Authorization Server?
>=20
> Since many companies have their own User/Privilege system, LDAP based (e.g=
. Active Directory), etc. - they must have their own Authorization Server.
>=20
> Is there a framework, libraries, etc. for that? Or do I have to write the c=
ode from scratch?
>=20
> cheers,
> Richard
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jul 17 17:16:07 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003561A00E2 for ; Thu, 17 Jul 2014 17:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 CCXimvn5LlKw for ; Thu, 17 Jul 2014 17:15:59 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAEA41A00DF for ; Thu, 17 Jul 2014 17:15:58 -0700 (PDT)
X-AuditID: 1209190e-f79946d000007db1-7b-53c8673dc2e8
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 1C.F9.32177.D3768C35; Thu, 17 Jul 2014 20:15:57 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s6I0Fv1O021603; Thu, 17 Jul 2014 20:15:57 -0400
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6I0FtXS025436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Jul 2014 20:15:56 -0400
Message-ID: <53C8672F.1080800@mit.edu>
Date: Thu, 17 Jul 2014 20:15:43 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Richard Snowden , oauth@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030504070401090603030108"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hTV1rVNPxFsMO2fhcXJt6/YLHoap7E6 MHnsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBn3T05nKZigXLH04SqmBsYeqS5GTg4JAROJ 1W+fMEPYYhIX7q1n62Lk4hASmM0k8bnxOiNIQkhgI6PEvKPlEInbTBKbt91gAUnwCqhJrG/q YQOxWQRUJaYu2gZmswHZ81feYgKxRQWiJO5c6meFqBeUODnzCViviICjxJpFL4E2c3AIC+hI 9F8OgdgVIHH0/A12EJtTIFBiY2Mj2EhmgTCJq1MmMk1g5J+FZNIsJKlZQJOYBawlvu0uggjL S2x/O4cZwtaWWNV7lglZfAEj2ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdY73czBK91JTSTYzg oJbk28H49aDSIUYBDkYlHt4H144HC7EmlhVX5h5ilORgUhLlrYw8ESzEl5SfUpmRWJwRX1Sa k1p8iFGCg1lJhDf7PlA5b0piZVVqUT5MSpqDRUmc9621VbCQQHpiSWp2ampBahFMVoaDQ0mC tyoNaKhgUWp6akVaZk4JQpqJgxNkOA/Q8IupQDW8xQWJucWZ6RD5U4yKUuK8wiDNAiCJjNI8 uF5Y0nnFKA70ijBvAEgVDzBhwXW/AhrMBDRYuhzk6uKSRISUVAOjbuistMBTwWUrHC8bq4h/ bKt16LJbfqA+9O325/yL7eQzN7058Nv2x7zbPtd7/89/dWjpgsDn8q4PDq7Nlvax47529tWV r9e9za+d2L7fZFIif4W8csyWt1WXQgL6s1tdbHRtPFfNyYp8L/OoXr+Rn1+g4BGDV23wext1 RV0umW3qnElWGveVWIozEg21mIuKEwG59HyWFQMAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/0VJWw5fCBS8Ey6wzrzs8p6FUa5Y
Subject: Re: [OAUTH-WG] Authorization Server
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, 18 Jul 2014 00:16:01 -0000

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

Richard,

Many people implement their own servers and tie it closely to their 
protected resource API. There are a number of general purpose 
authorization servers and libraries out there, though, including an open 
source one written in Java that I maintain:

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/

It's based on Spring and Spring Security, and it also includes OpenID 
Connect support. Additionally, it implements JWT bearer tokens, 
revocation, introspection, dynamic registration, and it has an admin 
interface.

  -- Justin

On 7/17/2014 4:47 AM, Richard Snowden wrote:
> Hi there,
>
> after viewing some tutorials and running some samples code I 
> understood the client side of OAuth 2.0.
>
> Using existing Authorization Server seems to be not too complicated.
>
> Question is: How to implement my own Authorization Server?
>
> Since many companies have their own User/Privilege system, LDAP based 
> (e.g. Active Directory), etc. - they must have their own Authorization 
> Server.
>
> Is there a framework, libraries, etc. for that? Or do I have to write 
> the code from scratch?
>
> cheers,
> Richard
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    
Richard, 

      

      Many people implement their own servers and tie it closely to
      their protected resource API. There are a number of general
      purpose authorization servers and libraries out there, though,
      including an open source one written in Java that I maintain:

      

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/

      

      It's based on Spring and Spring Security, and it also includes
      OpenID Connect support. Additionally, it implements JWT bearer
      tokens, revocation, introspection, dynamic registration, and it
      has an admin interface.

      

       -- Justin

      

      On 7/17/2014 4:47 AM, Richard Snowden wrote:

    

    

      
      

        

          

            

              

                
Hi there,

                  

                

                after viewing some tutorials and running some samples
                code I understood the client side of OAuth 2.0.

              

              


                Using existing Authorization Server seems to be not too
                complicated.

              

              


              

              Question is: How to implement my own Authorization Server?

              

            

            Since many companies have their own User/Privilege system,
            LDAP based (e.g. Active Directory), etc. - they must have
            their own Authorization Server.

            

          

          Is there a framework, libraries, etc. for that? Or do I have
          to write the code from scratch?

          

          cheers,

        

        Richard

      

      

      

      

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


    

    

  


--------------030504070401090603030108--


From nobody Fri Jul 18 21:53:00 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624321A03F6 for ; Fri, 18 Jul 2014 21:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level: 
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPTLMEbs0tnR for ; Fri, 18 Jul 2014 21:52:56 -0700 (PDT)
Received: from na3sys009aog136.obsmtp.com (na3sys009aog136.obsmtp.com [74.125.149.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942801A03FD for ; Fri, 18 Jul 2014 21:52:56 -0700 (PDT)
Received: from mail-ie0-f180.google.com ([209.85.223.180]) (using TLSv1) by na3sys009aob136.postini.com ([74.125.148.12]) with SMTP ID DSNKU8n5qHdCNPGvh0Hyg8MtXXp+KIBcb1OT@postini.com; Fri, 18 Jul 2014 21:52:56 PDT
Received: by mail-ie0-f180.google.com with SMTP id at20so5324651iec.11 for ; Fri, 18 Jul 2014 21:52:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xcjCMTHMNr1zZt02SR1KjzXqPmFLambClW0PMjwffu4=; b=cQ48dkW/Mvo9+g9dvLyx3qCVe5EpEBSxuLuKdwWDL5q9N9bQJHOWp9LkdFaivv24mp Cs//ALRKz4aQY+MDeqVwHyBQ4UAgvPAhk9JUO6fBU+JwUkJv46Y/Ugl14rBNze2MyTv5 nBDdZhoMs0Gs6LjqtwmVgFW9Cdy8FEoieolbYBSWceqG50NAWnsoa4dOH43GMoRPtGH/ jH6m14mNBK6YIlGYBVWBLPpZ69X/IBbbRNUyCEcERLzNL9Zzchud+pS4Ag6DSRxB4aaz 2D2cR4w4mNuVoHIXTHd+/FsSthc0G2TSqqZ316LBGqNBTXDGhRMMlXdDFAzyh10k++F/ PG7w==
X-Gm-Message-State: ALoCoQkNHoFtiv/oVtPCwg+DEcchE8Igqq5wf3F9BzaAivNfTBzpB5teZJ9QAbXSzlJEV2wubGIZ8u1hyrFip3D0Kw7SyHLQK8+RVSzwSxbDmzxJZ8kjrOBAlI2+nQkRn9HHXx2Shi75
X-Received: by 10.50.164.201 with SMTP id ys9mr47123261igb.40.1405745575892; Fri, 18 Jul 2014 21:52:55 -0700 (PDT)
X-Received: by 10.50.164.201 with SMTP id ys9mr47123245igb.40.1405745575713; Fri, 18 Jul 2014 21:52:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.233.170 with HTTP; Fri, 18 Jul 2014 21:52:25 -0700 (PDT)
In-Reply-To: 
References: 
From: Brian Campbell 
Date: Fri, 18 Jul 2014 22:52:25 -0600
Message-ID: 
To: Kathleen Moriarty 
Content-Type: multipart/alternative; boundary=089e0149c1deaf857a04fe84a5e9
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wEmHytar8GmuNyWvvgMH-lHKxag
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-jwt-bearer-09
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, 19 Jul 2014 04:52:58 -0000

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

Sorry for the slow response on this Kathleen, my day job has been keeping
me busy recently. And, honestly, I was kind of hopeful someone would
volunteer some text in the meantime. But that didn't happen so how about
the following?

A JWT may contain privacy-sensitive information and, to prevent disclosure
of such information to unintended parties, should only be transmitted over
encrypted channels, such as TLS. In cases where it=E2=80=99s desirable to p=
revent
disclosure of certain information the client, the JWT may be be encrypted
to the authorization server.

Deployments should determine the minimum amount of information necessary to
complete the exchange and include only such claims in the JWT. In some
cases the "sub" (subject) claim can be a value representing an anonymous or
pseudonymous user as described in Section 6.3.1 of the Assertion Framework
for OAuth 2.0 Client Authentication and Authorization Grants [
http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3.1].


On Thu, Jul 3, 2014 at 3:26 PM, Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

>
> Hello,
>
> I just read through draft-ietf-oauth-jwt-bearer-09 and it looks good.  Th=
e
> only question/comment I have is that I don't see any mention of privacy
> considerations in the referenced security sections.  COuld you add
> something?  It is easily addressed by section 10.8 of RFC6749, but there =
is
> no mention of privacy considerations.  I'm sure folks could generate grea=
t
> stories about who accessing what causing privacy considerations to be
> important.
>
> Thanks & have a nice weekend!
>
> --
>
> Best regards,
> Kathleen
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


Sorry for the slow response on this Kathleen, my day =
job has been keeping me busy recently. And, honestly, I was kind of hopeful=
 someone would volunteer some text in the meantime. But that didn't hap=
pen so how about the following?




A JWT may contain privacy-se=
nsitive information and, to prevent disclosure of such information to unint=
ended parties, should only be transmitted over encrypted channels, such as =
TLS. In cases where it=E2=80=99s desirable to prevent disclosure of certain=
 information the client, the JWT may be be encrypted to the authorization s=
erver. 



Deployments should determine the minimum amount of information necessar=
y to complete the exchange and include only such claims in the JWT. In some=
 cases the "sub" (subject) claim can be a value representing an a=
nonymous or pseudonymous user as described in Section 6.3.1 of the Assertio=
n Framework for OAuth 2.0 Client Authentication and Authorization Grants [<=
a href=3D"http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section=
-6.3.1">http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6=
.3.1]. 





O=
n Thu, Jul 3, 2014 at 3:26 PM, Kathleen Moriarty <kathleen.=
moriarty.ietf@gmail.com> wrote:




Hello,

I just read through draft-ietf-oauth-jwt-b=
earer-09 and it looks good. =C2=A0The only question/comment I have is that =
I don't see any mention of privacy considerations in the referenced sec=
urity sections. =C2=A0COuld you add something? =C2=A0It is easily addressed=
 by section 10.8 of RFC6749, but there is no mention of privacy considerati=
ons. =C2=A0I'm sure folks could generate great stories about who access=
ing what causing privacy considerations to be important.





Thanks & have a nice weekend!

-- 

Best regards,
Kathleen




_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





--089e0149c1deaf857a04fe84a5e9--


From nobody Fri Jul 18 23:45:39 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7393A1A0A74 for ; Fri, 18 Jul 2014 23:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 HLPVfu1oqFr3 for ; Fri, 18 Jul 2014 23:45:35 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCEE1A08EC for ; Fri, 18 Jul 2014 23:45:35 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6J6jW0S028547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 19 Jul 2014 06:45:33 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6J6jWBI026021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jul 2014 06:45:32 GMT
Received: from ubhmt110.oracle.com (ubhmt110.oracle.com [156.151.24.15]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6J6jVl1026015; Sat, 19 Jul 2014 06:45:31 GMT
Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 18 Jul 2014 23:45:31 -0700
References:  
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-9D870270-C6D7-41E3-A9B2-179B6FC306AB
Content-Transfer-Encoding: 7bit
Message-Id: <7DDBCE8B-4B39-432E-8925-B0C6D762A54C@oracle.com>
X-Mailer: iPhone Mail (11D257)
From: Phil Hunt 
Date: Fri, 18 Jul 2014 23:45:29 -0700
To: Brian Campbell 
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/M82JEjKabMT_E8lzQeyPHyzesss
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-jwt-bearer-09
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, 19 Jul 2014 06:45:37 -0000

--Apple-Mail-9D870270-C6D7-41E3-A9B2-179B6FC306AB
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Should that be encrypted for the intended audience (aud) of the JWT which ma=
y be the AS and/or the resource server?

Phil

> On Jul 18, 2014, at 21:52, Brian Campbell  wro=
te:
>=20
> Sorry for the slow response on this Kathleen, my day job has been keeping m=
e busy recently. And, honestly, I was kind of hopeful someone would voluntee=
r some text in the meantime. But that didn't happen so how about the followi=
ng?
>=20
> A JWT may contain privacy-sensitive information and, to prevent disclosure=
 of such information to unintended parties, should only be transmitted over e=
ncrypted channels, such as TLS. In cases where it=E2=80=99s desirable to pre=
vent disclosure of certain information the client, the JWT may be be encrypt=
ed to the authorization server.=20
>=20
> Deployments should determine the minimum amount of information necessary t=
o complete the exchange and include only such claims in the JWT. In some cas=
es the "sub" (subject) claim can be a value representing an anonymous or pse=
udonymous user as described in Section 6.3.1 of the Assertion Framework for O=
Auth 2.0 Client Authentication and Authorization Grants [http://tools.ietf.o=
rg/html/draft-ietf-oauth-assertions-16#section-6.3.1].
>=20
>=20
>> On Thu, Jul 3, 2014 at 3:26 PM, Kathleen Moriarty  wrote:
>>=20
>> Hello,
>>=20
>> I just read through draft-ietf-oauth-jwt-bearer-09 and it looks good.  Th=
e only question/comment I have is that I don't see any mention of privacy co=
nsiderations in the referenced security sections.  COuld you add something? =
 It is easily addressed by section 10.8 of RFC6749, but there is no mention o=
f privacy considerations.  I'm sure folks could generate great stories about=
 who accessing what causing privacy considerations to be important.
>>=20
>> Thanks & have a nice weekend!
>>=20
>> --=20
>>=20
>> Best regards,
>> Kathleen
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-9D870270-C6D7-41E3-A9B2-179B6FC306AB
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Should that be encrypted for the inten=
ded audience (aud) of the JWT which may be the AS and/or the resource server=
?

Phil

On Jul 18, 2014, at 21:52, Brian Campbell <bcampbell@pingidentity.com&g=
t; wrote:

=
Sorry for the slow response on this Kathleen, my day job has been keeping me=
 busy recently. And, honestly, I was kind of hopeful someone would volunteer=
 some text in the meantime. But that didn't happen so how about the followin=
g?




A JWT may contain privacy-sen=
sitive information and, to prevent disclosure of such information to uninten=
ded parties, should only be transmitted over encrypted channels, such as TLS=
. In cases where it=E2=80=99s desirable to prevent disclosure of certain inf=
ormation the client, the JWT may be be encrypted to the authorization server=
. 



Deployments should determine the minimum amount of information necessary=
 to complete the exchange and include only such claims in the JWT. In some c=
ases the "sub" (subject) claim can be a value representing an anonymous or p=
seudonymous user as described in Section 6.3.1 of the Assertion Framework fo=
r OAuth 2.0 Client Authentication and Authorization Grants [http://t=
ools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3.1]. 





On=
 Thu, Jul 3, 2014 at 3:26 PM, Kathleen Moriarty <kathleen.mor=
iarty.ietf@gmail.com> wrote:




H=
ello,

I just read through draft-ietf-oauth-jwt-bear=
er-09 and it looks good.  The only question/comment I have is that I do=
n't see any mention of privacy considerations in the referenced security sec=
tions.  COuld you add something?  It is easily addressed by sectio=
n 10.8 of RFC6749, but there is no mention of privacy considerations.  =
I'm sure folks could generate great stories about who accessing what causing=
 privacy considerations to be important.





Thanks & have a nice weekend!

-- 
<=
br>
Best regards,
Kathleen




_______________________________________________

OAuth mailing list

OAuth@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/oauth





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

--Apple-Mail-9D870270-C6D7-41E3-A9B2-179B6FC306AB--


From nobody Sat Jul 19 01:25:29 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206851B27D5 for ; Sat, 19 Jul 2014 01:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Level: 
X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCau6m2HX0vm for ; Sat, 19 Jul 2014 01:25:26 -0700 (PDT)
Received: from na3sys009aog132.obsmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F7F1B27E5 for ; Sat, 19 Jul 2014 01:25:25 -0700 (PDT)
Received: from mail-ie0-f170.google.com ([209.85.223.170]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKU8ordYeLu6DKyL3fQNlJFzd8O94sbuBv@postini.com; Sat, 19 Jul 2014 01:25:25 PDT
Received: by mail-ie0-f170.google.com with SMTP id rl12so5408642iec.1 for ; Sat, 19 Jul 2014 01:25:25 -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=Rh237GAy+aqDtVPSPonxE66VEIuUu+O3AJqUVIHPZSg=; b=DkteE97chdXIlQqoTVUaVILshRRuagHzswR71s95+bL40wkcjU/XJXoWvfO3HHz/Sj Fu4qNdjIH3zpXbxrIX6LT0WUOlQaMLTs1RTzDe8mgK826QoslT4fFPfDuwK7T8U8EDc5 pTHAMQNv06YNTy3aCUSej7jtjdViE4W2QvATN+nFuACtaHrFDxKKNvxIAZb5eyzy3CwP dD3rP5DVXRXif/wFmLXzrx5uWgMfZdwDOpMNKL2TSLjryBLS7ZQpfDvArhQGkcZMQaQ3 j/3y3rulGmba8OzTLFUYkk61IbolBM2GACCnzdh2M4hgddVupvfowcjiUNQr5+9tq/tw +7Pw==
X-Gm-Message-State: ALoCoQlsd95+os90O9tyQ4HD5I+howiEfRCRPXCvHCilNJZhCMYO29+PFnMvMb60cFn5nQPj2DqKIbH/Z+V5YORViLPGCwY7IupLbVFZ5uZoimf+9vCKMBT6S+gUex02bOzlBoKtRq6b
X-Received: by 10.50.41.6 with SMTP id b6mr17872862igl.40.1405758325122; Sat, 19 Jul 2014 01:25:25 -0700 (PDT)
X-Received: by 10.50.41.6 with SMTP id b6mr17872842igl.40.1405758324992; Sat, 19 Jul 2014 01:25:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.233.170 with HTTP; Fri, 18 Jul 2014 22:00:50 -0700 (PDT)
In-Reply-To: 
References: 
From: Brian Campbell 
Date: Fri, 18 Jul 2014 23:00:50 -0600
Message-ID: 
To: Kathleen Moriarty 
Content-Type: multipart/alternative; boundary=089e011614149a0bda04fe879d1c
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fCyTpt3wqo8BwVVOd1S30UfpJ3U
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] AD Review of http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer
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, 19 Jul 2014 08:25:28 -0000

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

How about the following (which is intentionally similar to the text I just
put forth for your request for privacy consideration in
draft-ietf-oauth-jwt-bearer-09)?

A SAML Assertion may contain privacy-sensitive information and, to prevent
disclosure of such information to unintended parties, should only be
transmitted over encrypted channels, such as TLS. In cases where it=E2=80=
=99s
desirable to prevent disclosure of certain information the client, the
Subject and/or individual attributes of a SAML Assertion may be encrypted
to the authorization server.

Deployments should determine the minimum amount of information necessary to
complete the exchange and include only that information in an Assertion
(typically by limiting what information is included in an
 or omitting it altogether). In some cases
the Subject can be a value representing an anonymous or pseudonymous user
as described in Section 6.3.1 of the Assertion Framework for OAuth 2.0
Client Authentication and Authorization Grants
[*http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3.1
*]=
.


On Tue, Jul 15, 2014 at 2:04 PM, Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

> Hello,
>
> I just finished my review of
> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer.  The draft
> looks great, thank you for all of your efforts on it!
>
> I did notice that there were no privacy considerations pointing back to
> RFC6973, could that text be added?  The draft came after the Oauth
> framework publication (refernced in the security considerations), so I am
> guessing that is why this was missed as there are privacy considerations =
in
> the oauth assertion draft (I competed that review as well and the draft
> looked great.  I don't have any comments to add prior to progressing the
> draft).
>
> Thank you.
>
> --
>
> Best regards,
> Kathleen
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


How about the following (which is intentionally similar to=
 the text I just put forth for your request for privacy consideration in dr=
aft-ietf-oauth-jwt-bearer-09)?

A SAML Assertion=C2=A0may contain privacy-sensit=
ive information and,=C2=A0to prevent disclosure of such=C2=A0information to=
 unintended parties,=C2=A0should=C2=A0only be transmitted over=C2=A0encrypt=
ed channels, such as TLS.=C2=A0In cases where it=E2=80=99s desirable to pre=
vent=C2=A0disclosure of=C2=A0certain=C2=A0information=C2=A0the client, the =
Subject and/or individual attributes of a=C2=A0SAML=C2=A0Assertion may be e=
ncrypted to the authorization server.=C2=A0






Deployments should=C2=A0determine the minim=
um amount of=C2=A0information=C2=A0necessary to complete the=C2=A0exchange =
and include only that information in an=C2=A0Assertion (typically by limiti=
ng what information is included in an <AttributeStatement> or omittin=
g it altogether).=C2=A0In some cases the=C2=A0Subject=C2=A0can be a value r=
epresenting an=C2=A0anonymous or=C2=A0pseudonymous user as described in Sec=
tion 6.3.1 of the Assertion Framework for OAuth 2.0 Client Authentication a=
nd Authorization Grants [http://tools.ietf.org/html/draft-iet=
f-oauth-assertions-16#section-6.3.1].



On Tue, Jul 15, 2014 at 2:04 PM, Kathleen Moriarty <=
;kath=
leen.moriarty.ietf@gmail.com> wrote:



Hello,

I=
 just finished my review of=C2=A0http://datatracker.ietf.o=
rg/doc/draft-ietf-oauth-saml2-bearer. =C2=A0The draft looks great, than=
k you for all of your efforts on it!





I did notice that there were no privacy considerations =
pointing back to RFC6973, could that text be added? =C2=A0The draft came af=
ter the Oauth framework publication (refernced in the security consideratio=
ns), so I am guessing that is why this was missed as there are privacy cons=
iderations in the oauth assertion draft (I competed that review as well and=
 the draft looked great. =C2=A0I don't have any comments to add prior t=
o progressing the draft).





Thank you.

-- 

Best regards,<=
/div>
Kathleen




_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





--089e011614149a0bda04fe879d1c--


From nobody Sat Jul 19 05:36:54 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3E61B27F9 for ; Sat, 19 Jul 2014 05:36:51 -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 7BAeHWH1dhR5 for ; Sat, 19 Jul 2014 05:36:49 -0700 (PDT)
Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F0A1B27F2 for ; Sat, 19 Jul 2014 05:36:48 -0700 (PDT)
Received: by mail-pa0-f45.google.com with SMTP id eu11so7009722pac.4 for ; Sat, 19 Jul 2014 05:36:48 -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=Ob0iQgUixVjAP5vQr4FUHchMx3XsCqN0xRqufM5t8hY=; b=RDDnSoURK7xhS2G7r85Ha8VD0Bmj7UJ73eGbkHE3CuK13UuaI+SEkEfFjlr/hrjp4Q WDkQaJ/m2s/O60CC+RghoQc/nAC69pUGb96Y5ruzPrgyVzsSf5QgjyBe2sMkILNgQ3Aj U07vd0EjMwPM0TsPfIpYqLHJgjClcM7hfKbVINpN5IT1RLCrBkfVxCbHLipd+aSpy7ur uBzd7cgr7jq3Jk6bQks+88BxTt4upT1v/Rv+pE9yeNDpThREAdczymz8R94zm55snu+L N/aQGNsRellfRF03s+6MBLG+Tt92tRuneHkK0+SrIirHCDRo043WS5j/XA61dr5KNivO MH0Q==
X-Gm-Message-State: ALoCoQkzjuJKCApvRN7dmtMdI81kqJMu4ihwZzaOOAJfjubTK2cUyENYYDnNKJ50sV0GqUV6sCa0
X-Received: by 10.68.222.136 with SMTP id qm8mr1295878pbc.92.1405773408420; Sat, 19 Jul 2014 05:36:48 -0700 (PDT)
Received: from [10.71.6.108] (soln-sr3455.solutionip.com. [70.233.112.2]) by mx.google.com with ESMTPSA id wp3sm8488922pbc.67.2014.07.19.05.36.46 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Jul 2014 05:36:47 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_20C450FE-6F4B-401C-99E1-9B22586281E1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Bradley 
In-Reply-To: <7DDBCE8B-4B39-432E-8925-B0C6D762A54C@oracle.com>
Date: Sat, 19 Jul 2014 05:37:00 -0700
Message-Id: <1452B71B-DB68-477E-BFE0-0765387B2934@ve7jtb.com>
References:   <7DDBCE8B-4B39-432E-8925-B0C6D762A54C@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9KEvTuP8QY2-O0yA9TjEPY7pHgM
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-jwt-bearer-09
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, 19 Jul 2014 12:36:51 -0000

--Apple-Mail=_20C450FE-6F4B-401C-99E1-9B22586281E1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

While a JWT might generically have many different audiences like =
resource servers, this profile is about sending it to the token endpoint =
at an AS for authentication or authorization.

I think adding something about the RS will confuse people.  =20

I think Brian's text is fine.

John B.

On Jul 18, 2014, at 11:45 PM, Phil Hunt  wrote:

> Should that be encrypted for the intended audience (aud) of the JWT =
which may be the AS and/or the resource server?
>=20
> Phil
>=20
> On Jul 18, 2014, at 21:52, Brian Campbell  =
wrote:
>=20
>> Sorry for the slow response on this Kathleen, my day job has been =
keeping me busy recently. And, honestly, I was kind of hopeful someone =
would volunteer some text in the meantime. But that didn't happen so how =
about the following?
>>=20
>> A JWT may contain privacy-sensitive information and, to prevent =
disclosure of such information to unintended parties, should only be =
transmitted over encrypted channels, such as TLS. In cases where it=92s =
desirable to prevent disclosure of certain information the client, the =
JWT may be be encrypted to the authorization server.=20
>>=20
>> Deployments should determine the minimum amount of information =
necessary to complete the exchange and include only such claims in the =
JWT. In some cases the "sub" (subject) claim can be a value representing =
an anonymous or pseudonymous user as described in Section 6.3.1 of the =
Assertion Framework for OAuth 2.0 Client Authentication and =
Authorization Grants =
[http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3.1].=

>>=20
>>=20
>> On Thu, Jul 3, 2014 at 3:26 PM, Kathleen Moriarty =
 wrote:
>>=20
>> Hello,
>>=20
>> I just read through draft-ietf-oauth-jwt-bearer-09 and it looks good. =
 The only question/comment I have is that I don't see any mention of =
privacy considerations in the referenced security sections.  COuld you =
add something?  It is easily addressed by section 10.8 of RFC6749, but =
there is no mention of privacy considerations.  I'm sure folks could =
generate great stories about who accessing what causing privacy =
considerations to be important.
>>=20
>> Thanks & have a nice weekend!
>>=20
>> --=20
>>=20
>> Best regards,
>> Kathleen
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_20C450FE-6F4B-401C-99E1-9B22586281E1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

While =
a JWT might generically have many different audiences like resource =
servers, this profile is about sending it to the token endpoint at an AS =
for authentication or authorization.

I think adding =
something about the RS will confuse people. =
  

I think Brian's text is =
fine.

John B.

On Jul =
18, 2014, at 11:45 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:

Should that be encrypted for the =
intended audience (aud) of the JWT which may be the AS and/or the =
resource server?

Phil

On Jul 18, 2014, at 21:52, =
Brian Campbell <bcampbell@pingidentity.com&=
gt; wrote:

Sorry for the slow response on this Kathleen, my day =
job has been keeping me busy recently. And, honestly, I was kind of =
hopeful someone would volunteer some text in the meantime. But that =
didn't happen so how about the following?




A JWT may contain =
privacy-sensitive information and, to prevent disclosure of such =
information to unintended parties, should only be transmitted over =
encrypted channels, such as TLS. In cases where it=92s desirable to =
prevent disclosure of certain information the client, the JWT may be be =
encrypted to the authorization server. 



Deployments should determine the minimum amount of information =
necessary to complete the exchange and include only such claims in the =
JWT. In some cases the "sub" (subject) claim can be a value representing =
an anonymous or pseudonymous user as described in Section 6.3.1 of the =
Assertion Framework for OAuth 2.0 Client Authentication and =
Authorization Grants [http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6=
.3.1]. 





On Thu, Jul 3, 2014 at 3:26 PM, Kathleen Moriarty =
<kathleen.moriarty.ietf@gmail.com> =
wrote:




Hello,

I just read =
through draft-ietf-oauth-jwt-bearer-09 and it looks good.  The only =
question/comment I have is that I don't see any mention of privacy =
considerations in the referenced security sections.  COuld you add =
something?  It is easily addressed by section 10.8 of RFC6749, but =
there is no mention of privacy considerations.  I'm sure folks =
could generate great stories about who accessing what causing privacy =
considerations to be important.





Thanks & have a nice weekend!

-- 

Best regards,
Kathleen




_______________________________________________

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=_20C450FE-6F4B-401C-99E1-9B22586281E1--


From nobody Sat Jul 19 07:09:22 2014
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5611B2833 for ; Sat, 19 Jul 2014 07:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level: 
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmUchQKychYh for ; Sat, 19 Jul 2014 07:09:10 -0700 (PDT)
Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2591B282F for ; Sat, 19 Jul 2014 07:09:09 -0700 (PDT)
Received: from mail-ie0-f173.google.com ([209.85.223.173]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKU8p8BbHQk0EW3oPTbU3sdJbtyUJ82Ewq@postini.com; Sat, 19 Jul 2014 07:09:09 PDT
Received: by mail-ie0-f173.google.com with SMTP id tr6so5439691ieb.4 for ; Sat, 19 Jul 2014 07:09:08 -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=VqUVubBbUgnYhr428kItXPbKVgW2Y4aGxoaza9zuwJg=; b=gW4I3s+B1Kkn0m3uVSgTAB+Hd93N313NTo7BRJ1D+ZM7oBNHDa+GL1DGZuUZOMuKlP Me3o2/BbhWWAEE6x25cYy6v02yWg50DwAAzPs/kvW3IyC0oGrU7PppYUMof3sv4Z8diS TxgaUTGuebPoS13wbpGW4uaDJtAJRhaOBr5bIs8vgt9Y08wCgj4c+9z8PFok+V+/C7Xl XaQQyaqFpVlec7I8HWV7yONqfBpocHV3VH9SNtkIXk8mACLGs3Tk0rXY1Z/IsWiE78Bl 45EyKvOcHff+CdFPtbDTxXcCCk0LZ49ycESfF9atYxHPn5SZO0JnIajPVNLbzRsDKpR0 AyVQ==
X-Gm-Message-State: ALoCoQlFBkHUpaqpub+qpVdcRpL1YOMFxvNCJk8L/XgX/Sdqz2cbb+kDSTpUwIfKy96nbI5hstspltzbGquD20w+JKI0F8a+mjDA8XArWRJ4Wop5AA3df0+gyf1P/yLoxshdZDNMKwx2
X-Received: by 10.50.138.72 with SMTP id qo8mr12663178igb.2.1405778948926; Sat, 19 Jul 2014 07:09:08 -0700 (PDT)
X-Received: by 10.50.138.72 with SMTP id qo8mr12663159igb.2.1405778948767; Sat, 19 Jul 2014 07:09:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.233.170 with HTTP; Sat, 19 Jul 2014 07:08:38 -0700 (PDT)
In-Reply-To: <1452B71B-DB68-477E-BFE0-0765387B2934@ve7jtb.com>
References:   <7DDBCE8B-4B39-432E-8925-B0C6D762A54C@oracle.com> <1452B71B-DB68-477E-BFE0-0765387B2934@ve7jtb.com>
From: Brian Campbell 
Date: Sat, 19 Jul 2014 08:08:38 -0600
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=001a1134c792e0236604fe8c6ac1
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/d2jSUYZFlLQKmuCQcoyi1rJWcVw
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-jwt-bearer-09
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, 19 Jul 2014 14:09:12 -0000

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

I agree that mentioning the RS in this context is only likely to cause
confusion.

This draft is only about sending a JWT to the token endpoint at an AS as an
authorization grant or as client authentication.


On Sat, Jul 19, 2014 at 6:37 AM, John Bradley  wrote:

> While a JWT might generically have many different audiences like resource
> servers, this profile is about sending it to the token endpoint at an AS
> for authentication or authorization.
>
> I think adding something about the RS will confuse people.
>
> I think Brian's text is fine.
>
> John B.
>
> On Jul 18, 2014, at 11:45 PM, Phil Hunt  wrote:
>
> Should that be encrypted for the intended audience (aud) of the JWT which
> may be the AS and/or the resource server?
>
> Phil
>
> On Jul 18, 2014, at 21:52, Brian Campbell 
> wrote:
>
> Sorry for the slow response on this Kathleen, my day job has been keeping
> me busy recently. And, honestly, I was kind of hopeful someone would
> volunteer some text in the meantime. But that didn't happen so how about
> the following?
>
> A JWT may contain privacy-sensitive information and, to prevent disclosur=
e
> of such information to unintended parties, should only be transmitted ove=
r
> encrypted channels, such as TLS. In cases where it=E2=80=99s desirable to=
 prevent
> disclosure of certain information the client, the JWT may be be encrypted
> to the authorization server.
>
> Deployments should determine the minimum amount of information necessary
> to complete the exchange and include only such claims in the JWT. In some
> cases the "sub" (subject) claim can be a value representing an anonymous =
or
> pseudonymous user as described in Section 6.3.1 of the Assertion Framewor=
k
> for OAuth 2.0 Client Authentication and Authorization Grants [
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3.1].
>
>
> On Thu, Jul 3, 2014 at 3:26 PM, Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com> wrote:
>
>>
>> Hello,
>>
>> I just read through draft-ietf-oauth-jwt-bearer-09 and it looks good.
>>  The only question/comment I have is that I don't see any mention of
>> privacy considerations in the referenced security sections.  COuld you a=
dd
>> something?  It is easily addressed by section 10.8 of RFC6749, but there=
 is
>> no mention of privacy considerations.  I'm sure folks could generate gre=
at
>> stories about who accessing what causing privacy considerations to be
>> important.
>>
>> Thanks & have a nice weekend!
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> _______________________________________________
>> 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
>
>
>

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


I agree that mentioning the RS in this context is only lik=
ely to cause confusion. 

This draft is only about sending a JWT to t=
he token endpoint at an AS as an authorization grant or as client authentic=
ation.






On Sat,=
 Jul 19, 2014 at 6:37 AM, John Bradley <ve7jtb@ve7jtb.com> w=
rote:



While a =
JWT might generically have many different audiences like resource servers, =
this profile is about sending it to the token endpoint at an AS for authent=
ication or authorization.



I think adding something about the RS will confuse people. =
=C2=A0=C2=A0

I think Brian's text is fine.

John B.

On Jul 18, 2014, at 11:45 PM, Phil Hunt <phil.hunt@oracle.com> wrote:



Should that be encrypt=
ed for the intended audience (aud) of the JWT which may be the AS and/or th=
e resource server?

Phil

On Jul 18, 2014, at 21:52, Bri=
an Campbell <bcampbell@pingidentity.com> wrote:



Sorry for the slo=
w response on this Kathleen, my day job has been keeping me busy recently. =
And, honestly, I was kind of hopeful someone would volunteer some text in t=
he meantime. But that didn't happen so how about the following?






A JWT may contain privacy-se=
nsitive information and, to prevent disclosure of such information to unint=
ended parties, should only be transmitted over encrypted channels, such as =
TLS. In cases where it=E2=80=99s desirable to prevent disclosure of certain=
 information the client, the JWT may be be encrypted to the authorization s=
erver. 





Deployments should determine the minimum amount of information necessar=
y to complete the exchange and include only such claims in the JWT. In some=
 cases the "sub" (subject) claim can be a value representing an a=
nonymous or pseudonymous user as described in Section 6.3.1 of the Assertio=
n Framework for OAuth 2.0 Client Authentication and Authorization Grants [<=
a href=3D"http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section=
-6.3.1" target=3D"_blank">http://tools.ietf.org/html/draft-ietf-oauth-asser=
tions-16#section-6.3.1]. 







O=
n Thu, Jul 3, 2014 at 3:26 PM, Kathleen Moriarty <kathleen.=
moriarty.ietf@gmail.com> wrote:






Hello,

I just read through draft-ietf-oauth-jwt-b=
earer-09 and it looks good. =C2=A0The only question/comment I have is that =
I don't see any mention of privacy considerations in the referenced sec=
urity sections. =C2=A0COuld you add something? =C2=A0It is easily addressed=
 by section 10.8 of RFC6749, but there is no mention of privacy considerati=
ons. =C2=A0I'm sure folks could generate great stories about who access=
ing what causing privacy considerations to be important.







Thanks & have a nice weekend!

-- 

Best re=
gards,
Kathleen




_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://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